Tagungsbericht PDF, 2.4 MB

Bericht 

Workshop Modellierung 2005 in 

Heidelberg 

16.3-18.3.05, 

Internationales Wissenschaftsforum der Universität 

Heidelberg 

1

Vorwort 

Turnusgemäß fand im Jahr 2005 ein Workshop Modellierung mit eingeladenen 

TeilnehmerInnen statt. Es war die erste Veranstaltung des neu gegründeten 

Querschnittsfach-ausschusses (QFA) Modellierung der Gesellschaft für Informatik. 

Teilgenommen haben Mitglieder des QFA-Leitungsgremiums sowie ExpertInnen aus 

Hochschule und Industrie. 

Die Frage nach dem Selbstverständnis des QFA stand naturgemäß im Vordergrund 

des Workshops. "Modellierung in der Informatik" umschreibt das gemeinsame Thema 

nur grob. Die konkreten Fragestellungen und die Vorgehensweisen bei ihrer 

Beantwortung unterscheiden sich erheblich in den verschiedenen im QFA 

repräsentierten Bereichen der Informatik. Dieser Umstand macht die besonderen 

Möglichkeiten des QFA deutlich, in dem Modellierungsinteressierte aus 

verschiedenen Fachgruppen voneinander lernen wollen. 

Um von den unterschiedlichen Sichtweisen, Erkenntnissen und Erfahrungen 

profitieren zu können, sollte die Diskussion auf der Grundlage eines gemeinsamen 

Verständnisses über den Begriff Modellierung stattfinden. Eine Modellierungstheorie 

mit dem Anspruch, anwendungs-bereichsunabhängige Grundlagen der Modellierung 

zu liefern, ist seit vielen Jahren in Entwicklung. Beiträge dazu wurden in früheren 

Modellierungsveranstaltungen vorgestellt und diskutiert. Ein Ziel des Workshops 

Modellierung 2005 war daher die Präzisierung des Selbstverständnisses des QFA 

Modellierung, zusammen mit Anforderungen an gemeinsame Grundlagen bzw. an 

eine Modellierungstheorie. 

Ein Einsatzbereich der Modellierung ist die Entwicklung softwareintensiver Systeme. 

Modellierung ist eine wichtige Aktivität während der Softwareentwicklung. Umgekehrt 

kann man die gesamte Softwareentwicklung stets auch als eine spezifische 

Modellierung auffassen, in der der Code das resultierende Modell ist. 

Softwareentwicklung und Modellierung sind eigenständige Disziplinen, die aber eng 

miteinander verwoben sind. Die Softwareentwicklung wird von einer größeren 

Community getragen und hat eine besser etablierte Begriffswelt als die Modellierung. 

Der Umgang mit Software (Code und Dokumentation) und Entwicklungswerkzeugen, 

Software als Wirtschaftsgut usw. sind allen InformatikerInnen geläufig, 

während entsprechende Begriffe bei Modellen noch nicht etabliert sind. Auch die 

große Zahl von Paradigmen (objektorientiert, aspektorientiert, serviceorientiert , ...) 

bei der Programmierung könnte eine sinnvolle Entsprechung bei der Modellierung 

haben. Auf dem Workshop Modellierung 2005 wurde die Analogie zwischen Software 

und Modellen aufgegriffen und als Vehikel für die gemeinsame Näherung an 

Fragestellungen der Modellierung verwendet. 

Der Workshop wurde in Form eines Open Space durchgeführt. Open Space betont 

minimale Struktur und maximale Selbstverantwortung ähnlich wie in agilen 

Softwareentwicklungs-vorgehensweisen. Am Anfang jedes Tages bestand 

Gelegenheit Arbeitsgruppen zu initiieren, die dazu dienen eine konkrete 

Fragestellung des Initiators zu beantworten. Die Arbeitsgruppen wurden parallel 

durchgeführt. Im Plenum am nächsten Tag wurden die Ergebnisse dann in großem 

Kreis sehr lebhaft diskutiert. Eine weitere Plenumsveranstaltung war eine 

2

Podiumsdiskussion nahe am Motto der Tagung: Auf dem Weg zu einer 

Modellierungstheorie: Was können wir aus einer Gegenüberstellung von 

Softwareentwicklung und Modellierung lernen? 

Die folgenden Arbeitsgruppen wurden während des Workshops initiiert: 

• Theorie der Konzeptuellen Modellierung (Bernhard Thalheim, Roland 

Kaschek, Wolfgang Reisig) 

• Zusatznutzen von Modellen (Matthias Riebisch) 

• Ästhetik und Qualität von Modellen (Ulrich Frank, Bernhard Rumpe, Andreas 

Oberweis) 

• Modellierung in der Lehre (Martin Glinz) 

• Modellierung in der Praxis – eine Bestandsaufnahme (Friederike Nickl, 

Günther Müller-Luschnat) 

• Modellierung vs. Programmierung (Friedrich Steimann, Thomas Kühne) 

• Modelltransformation (Andy Schürr) 

• Aspektorientierte Modellierung (Jan Jürjens) 

• Modellierung von Softwarearchitektur (Wilhelm Hasselbring) 

• Modellbasierte Entwicklung eingebetteter Softwaresysteme (Bernhard Schätz) 

• Modellierung von Datenbankkomponenten (Roland Kaschek, Bernhard 

Thalheim) 

Die Themen spiegeln das breite Spektrum der grundsätzlichen Fragen und der 

Anwendungen bei der Modellierung wieder. Die Ergebnisse sind nachfolgend 

zusammengestellt. 

Aus Sicht der OrganisatorInnen sind die folgenden Beobachtungen bemerkenswert: 

1. Die TeilnehmerInnen hatten wieder ein starkes Bedürfnis Grundsatzfragen der 

Modellierung zu diskutieren. Dies ist ein ganz wichtiger Bestandteil dieses 

Workshops, der auch in Zukunft Raum haben sollte. 

2. Durch die Gegenüberstellung mit der Softwareentwicklung wurde 

insbesondere die Durchgängigkeit von den oft informellen Modellen der 

Domäne über die Systementwurfsmodelle zu den formalen, ausführbaren 

Programmen thematisiert. Die Unterschiedlichkeit der Modelle (und ihrer 

Originale) und die daraus resultierenden unterschiedlichen Aktivitäten bei der 

Modellerstellung und der Modellnutzung sind offensichtlich. Es bestand 

weitgehend Konsens, dass Programmierung als ein Teilthema der 

Modellierung angesehen werden kann. Offen bleibt, inwieweit Durchgängigkeit 

machbar oder sogar (durch Modelltransformation) automatisierbar ist. 

3. Die Organisationsform des OpenSpace hat sich bewährt. Sie ermöglicht den 

IniatorInnen konkrete Fragestellungen anzusprechen, ohne die fertige Lösung 

präsentieren zu müssen. Besonders erfreulich ist, dass daraus auch Ideen für 

längerfristige Arbeitsgruppen erwachsen sind. 

Wir danken allen TeilnehmerInnen für Ihr Engagement. Die Diskussionen im 

frühlingshaften Garten des IWH und die zauberhaften Abende sind uns in sehr 

angenehmer Erinnerung. 

Barbara Paech, Jörg Desel 

März 2005 

3

Inhaltsverzeichnis Seite 

Theorie der Konzeptuellen Modellierung (Bernhard Thalheim, 

Roland Kaschek, Wolfgang Reisig)…………………………………………...5 

Zusatznutzen von Modellen (Matthias Riebisch)…………………………….6 

Ästhetik und Qualität von Modellen (Ulrich Frank, 

Bernhard Rumpe, Andreas Oberweis)………………………………………..9 

Modellierung in der Lehre (Martin Glinz)…………………………………….20 

Modellierung in der Praxis – eine Bestandsaufnahme 

(Friederike Nickl, Günther Müller-Luschnat)………………………………..23 

Modellierung vs. Programmierung (Friedrich Steimann, Thomas Kühne).28 

Modelltransformation (Andy Schürr)………………………………………….30 

Aspektorientierte Modellierung (Jan Jürjens)………………………………..42 

Modellierung von Softwarearchitektur (Wilhelm Hasselbring)……………..47 

Modellbasierte Entwicklung eingebetteter Softwaresysteme 

(Bernhard Schätz)………………………………………………………………48 

Modellierung von Datenbankkomponenten 

(Roland Kaschek, Bernhard Thalheim)………………………………………54 

Podiumsdiskussion (Ulrich Frank)……………………………………………55 

4

Theorie der konzeptuellen Modellierung 

Bernhard Thalheim, Roland Kaschek 

5

Modellierung 2005 


Nutzen und Motivation der 

Modellierung 

Arbeitsgruppe beim 

Workshop Modellierung 2005 

16. März 2005 

Matthias Riebisch 

TU Ilmenau 

Verhältnis von Aufwand und 

Nutzen entscheidet über Erfolg 

Laufender Aufwand 

• Erstellung: 

Modellieren 

• Prüfung: Bewertung, 

Konsistenzprüfung 

• Verstehen 

• Änderungen 

Einmaliger Aufwand 

• Infrastruktur 

bereitstellen und 

betreiben 

• Kenntnisse über 

Modellierung 

erwerben 

• Einbinden in Prozess 

und Organisation 

2 

6

Nutzen von Modellen 

• Prozess des Strukturierens von Problem- und Lösungsraum 

– Klären der wichtigen Begriffe, Abstraktionen der Realität, Ziele 

– Gliedern der Gedanken 

• Kommunikation 

– Schnelleres Verstehen von Konzepten und Lösungen 

– Vervielfachen von Wissen 

– Darstellen der Motivation des Lösungswegs 

– Vermeiden von Fehlern (durch Mißverständisse) 

• Entscheidungsunterstützung 

– Risikobewertung 

– Variantenvergleich 

– Projektsteuerung 

– Basis für Aufwandsschätzung 

• Modellbasierte Prüfungen 

– Frühzeitiger Fehler finden (Unvollständigkeiten, Inkonsistenzen) 

– Zeitverhalten & dyn. Eigenschaften 

– Robustheit 

• Werkzeuggestützte Tests 

• Generierung von Prototypen 

• Ausführbare Modelle, Generieren einer Implementierung 



Risiken bestimmen, welcher 

Aufwand akzeptabel ist 

Nicht-Formal 

Formal 

• Imageverlust eines PKW-Herstellers durch 

Instabilitäten, Rückrufe 

• Ausfall eines Bahnknotenpunktswegen SW- 

Fehlern im Stellwerk 

• Totalverlust eines Raumfahrzeugs 

• Unzufriedenheit der Kunden einer Bank wegen 

Ausfall der Terminals 

• Änderungen an einer Anwendung nicht möglich, 

weil nicht mehr stabilisierbar 

• …. 

3 

4 

7

Verbessern der Kommunikation 

• Verbessern der Verständlichkeit für die 

Beteiligten (Stakeholder) 

• Erfassbarkeit von komplexen Konzepten 

• Ergonomie von Modellen 

• Angemessenheit von Inhalt und Form 

– Graphische / textuelle Darstellung des Modells 

– Geeignetes Beschreibungsmittel / 

Modellierungssprache 

– Geeignete Sichten 


Wie Modellierung motivieren 

• Management 

– langfristigen Nutzen für Unternehmen verstehen 

– Raum für Modellierung schaffen (auch Personal …) 

– Entwickler überzeugen 

• Entwickler können Management überzeugen, Modelle zu 

verwenden 

• Bewusstsein für Qualität der Prozesse und Produkte schaffen – als 

Nutzen quantifizieren 

– Wartbarkeit als Voraussetzung für langfristige Weiterentwicklung 

• Reale Arbeitsteilung 

– Abnahme durch „Kunden“ 

– Offshoring 

• Wiederverwendbarkeit von Konzepten (Code kann seltener 

wiederverwendet werden) 


5 

6 

8

Ästhetik und Qualität von 

Modellen 

Frank, Oberweis, Rumpe 

Teil 

• Zusammenfassung 

• und Vorschlag für eine Weiterführung 

9

Modellqualität 

• Thema von großer Bedeutung in 

Wissenschaft und Praxis 

• Ästhetik als Qualitätskriterium? 

• Ästhetik als Ausdruck der 

Professionalisierung 

• Ästhetikbegriff kaum zu definieren 

• Wahrheit als Qualitätskriterium kaum 

brauchbar 

Qualitätskriterien (überlappend?) 

• syntaktische Korrektheit 

• Angemessenheit 

• Verständlichkeit/Anschaulichkeit 

• Erlernbarkeit 

• Gebrauchstauglichkeit 

• Schönes Layout 

• Operationalisierbarkeit 

• Einfluss der Modellierungssprache 

• ...? 

• Artikel von Ebersberg 

10

Vorschlag: Model Review 

• Messbarkeit fragwürdig? 

• Analogie zur Beurteilung akademischer 

Arbeiten 

• Einreichung von Modellen (in spezifischen 

Kategorien zB UML-Klassendiagramme, 

PN) 

• Vorgabe von Begutachtungskriterien 

• Durchführung und Untersuchung eines 

Begutachtungsprozesses 

• parallel dazu: Vergleich mit OO-Metriken 

Teil 2 

• Mitschrift während der Sitzung 

11

Modellästhetik 

• Eigenschaft des Modells oder des 

Betrachters? 

• Eigenschaft der Repräsentation? 

• Für Praktiker schwieriger Begriff 

• "Einheit von Inhalt und Form", 

Angemessenheit 

• Vermittlung in der Lehre? 

• bestimmte als "gut/schön" empfundene 

Grundmuster in der Darstellung 


• hat etwas mit Professionalisierung zu tun 

• "auf den ersten Blick eine Einschätzung über die 

Qualität zu haben" (nicht genau begründbar) 

• nicht nur abhängig von grafischer Darstellung 

• falsche Assoziationen durch schlechte 

Darstellung 

• Visualisierungstechnik ist noch keine Ästhetik. 

Es gibt Visualisierungstechniken, die Handwerk 

sind. Ästhetik ist mehr, eher Kunst. 

12


• Kultur der Anwendung von Maßen, Maß 

alleine hilft nicht weiter 

• betroffene Personengruppe spielt eine 

Rolle: wie homogen ist die Gruppe? 

• Lesbarkeit vs. Ästhetik 

• Ist der "Kunstaspekt" für uns relevant 

• Modelle, die automatisch generiert werden 

• "Konstrukte werden vergewaltigt" 


• intuitives Verständnis über "gut" und 

"schlecht" ist wichtig. 

"Modellierungskompetenz" / Erfahrung 

• "Muster-Wiedererkennung" 

• in der Lehre: vermitteln durch Zeigen von 

Beispielen 

• wichtig: wie kann man aus einem 

schlechten Modell ein gutes machen? 

• Empirie 

13

Abgrenzung des Begriffs Ästhetik 

• Modellieren ist ähnlich wie Programmieren eine Kunst 

• nicht vollständig objektivierbar 

• Analogie zum Design (besser als Analogie zum 

Programmieren) 

• Einsatzzweck (z.B. Erkenntnisse der Psychologie 

berücksichtigen) 

• subjektive Bewertung: was ist schön, was ist hässlich? 

• gewisse Übereinkunft möglich? 

• Gefahr: subjektiv im Sinne von willkürlich 

• Bewertung sollte intersubjektiv nachvollziehbar sein 

• manches quantitativ bewertbar, manches qualitativ 

Kann man ästhetische Aspekte 

messen? 

• wenn etwas messbar ist, sollte man es auch messen. 

• gibt es Eigenschaften, die man dauerhaft nicht messen kann? 

• man braucht einen Qualitätsbegriff und eine Skala zu unterschiedlichen 

Ausprägungen 

• ist Skala immer sinnvoll? 

• Analogie zu Programmen: Metriken für Programme 

• Systematik der Darstellung 

• Analogie: Modelle in der Geographie (Zweckbezogenheit der Darstellung) 

• Komplexität/Größe von Modellen: nur mit Hilfe von Werkzeugen / in verschiedenen 

Sichten zugänglich. Wenn man immer nur Ausschnitt sieht, stellt sich Frage der 

Ästhetik ganz anders. 

• Kriterien zur Erreichung von Ästhetik / "Faustregeln" 

• Ist Vereinfachung von Modellen zulässig? 

• Komplexität der Modelle in Relation zur Komplexität der dargestellten Realität 

• "objektiv messen" 

• Unabhängigkeit des Ästhetikbegriffs von Modellierungssprache? 

• wie machen das andere Ingenieursdisziplinen? Übertragbarkeit von solchen 

Konzepten scheitert an unterschiedlichen Reifegraden (vgl. Technisches Zeichnen, 

Darstellung technischer Sachverhalte) 

14


• es muss unterschieden werden zwischen 

Ästhetik einer Modellierungssprache und 

Ästhetik eines Modells 

• Beurteilung nicht unabhängig von 

Modellierungssprache 

• Analogie Maschinenbau/Architektur: ein 

realer Gegenstandsbereich, Software ist 

immaterielles Gut 

Verstehbarkeit/Verständlichkeit 

• ist es möglich, das Modell in Teilen zu 

bauen und darzustellen? 

• Aspekte getrennt betrachten? 

• es geht nicht darum, das Modell zu 

verstehen, sondern das modellierte 

Subjekt zu verstehen: Verstehbarkeit des 

Subjektes vs. Verstehbarkeit des Modells 

(ist es dasselbe?) 

15

Qualität 

• relativ definiert 

• relative Vergleichbarkeit von Modellen 

• Qualität eines Modells bemisst sich danach, was 

man damit machen kann: 

Kommunizierbarkeit, Analysierbarkeit, 

Weiterentwickelbarkeit 

• Messbarkeit ist wichtig: kann man Qualität 

absolut messen? 

• Qualitätsmessung durch 

"Mehrheitsentscheidung" 

Qualität 

• inhaltliche Q. (in Bezug auf die Realität) 

und Q. der Repräsentation 

• gibt es eine Korrelation zwischen beiden 

Qualitätsaspekten? 

• ein inhaltlich sinnvolles Modell kann durch 

schlechte Repräsentation 

unlesbar/unverwendbar gemacht werden 

• Kann man von Qualität nur sprechen, 

wenn es eine Messvorschrift gibt? 

16

Bedeutung von Qualität 

• Modelle müssen lesbar sein 

• vgl. Codierungsrichtlinien: so etwas 

braucht man auf Modellierungsebene auch 

• Ansätze in Großunternehmen gibt es 

bereits 

• Qualität der Repräsentation eines Modells 

wird von Werkzeugen nicht gemessen 

syntaktische Korrektheit 

17

Angemessenheit 

• Eignung für Zweck 

• empirisch entscheidbar? 

• Kriterien für Angemessenheit 

• Wie sieht ein Konzept für Angemessenheit aus? 

• wann kann man Angemessenheit sinnvoll 

beurteilen? 

• Angemessenheit heisst nicht, dass Wahrheit 

keine Rolle spielt. 

• Findet man einen Konsens? 

Anschaulichkeit 

18

Transformierbarkeit 

19

Modellierung in der Lehre 

Modellierung 2005, Heidelberg 

Martin Glinz 

www.ifi.unizh.ch/req 

Agenda 

Universität Zürich 

Institut für Informatik 

Grundannahme: Modellierung in der Informatik-Lehre 

Was lehren: Ziele, Inhalte 

Wann und wie lehren: 

Stellung im Curriculum 

Vermittlung und Didaktik 

Modellierung in der Lehre © 2005 by Martin Glinz 2 

20

Ziele und Inhalte 

Grundziel der Modellierung: Komplexe Sachverhalte kommunizierbar, 

verstehbar, analysierbar machen 

Generische Lernziele 

Modellierungstechniken in konkreten Problemsituationen 

anwenden 

Zu einem gegebenen Problem eine adäquate 

Modellierungstechnik auswählen 

Modellbildung als kreativen Prozess verstehen und anwenden 

Modelle lesen, interpretieren und analysieren 

Modelle integrieren und harmonisieren 

Wieviel Theorie? Welche Theorie? 

Metamodelle – wann und in welchem Umfang? 


Wann und wie lehren: Stellung im Curriculum 

Modellierung im Informatik-Unterricht der Hochschulen 

kleine Bestandesaufnahme, wer was macht 

keine vertiefte Diskussion 

Nicht diskutiert: 

Weiterbildung 

Modellierungs-Lehre unterhalb des Hochschulniveaus 


21

Wann und wie lehren: Vermittlung und Didaktik 

Modelle müssen erfahrbar sein: Fallstudien, Werkzeuge, Übungen, 

Praktika 

Das Motivationsproblem: Lösung sucht Problem 

Das Größenparadoxon: 

Realistische Probleme sind für die Lehre zu groß 

Lehrbare Probleme machen die Notwendigkeit nicht erfahrbar 

Das Prüfungsparadoxon: Prüfbarkeit vs. Adäquatheit 

Modelle exakt spezifizierbarer Probleme vs. Modelle von Problemen, 

die in einen Realwelt-Kontext eingebettet sind 

Kreativität vs. Abbildungstreue 

Medieneinsatz und e-Lehre 


Konkrete (kleine) Schritte 

Folien zu Modellierungslehrveranstaltungen sich gegenseitig zur 

Verfügung stellen (>> Webseiten des QFA Modellierung?) 

Austausch von Fallstudien 

... 

... 


22


Sitzung „Modellierung in der Praxis“ 

Moderatoren: Friederike Nickl (Sepis), 

Günther Müller-Luschnat (F.A.S.T) 

Da wir Moderatoren zwei der wenigen Teilnehmer an der Modellierung 2005 aus der Praxis 

waren, wurden wir gebeten, ein dementsprechendes Thema für diese Veranstaltung beizusteuern. 

Nach einigen Überlegungen entschieden wir uns für eine (natürlich nicht repräsentative) Bestandsaufnahme 

zur Situation der Modellierung in der Praxis. Auf der einen Seite aus dem 

Grund, dass uns hierüber keine bestehende Untersuchung bekannt war, zum anderen, weil wir 

das Gefühl hatten, dass die Situation in der Praxis nicht besonders rosig aussieht und wir dies 

den hochakademischen sonstigen Themen gegenüber stellen wollten. 

Vorausschickend ist zu konstatieren, dass es uns (leider) gelungen ist, das Plenum des 

Workshops auf den Boden der Tatsachen zurück zu holen. 

10 Workshop-Besucher nahmen an dieser 1,5 std. Arbeitssitzung teil. Der überwiegende Anteil 

bestand aus Praxisvertretern. Die teilnehmenden Vertreter aus dem akademischen Bereich 

schilderten ihre Erfahrungen bei Projekten, die sie in Unternehmen durchgeführt hatten. 

Alle Teilnehmer beantworteten reihum folgende Fragen:. 

Einsatz der Modellierung in der Praxis 

• in welchen Phasen ? 

• zu welchem Zweck ? 

• mit welchen Techniken ? 

• mit welchen Werkzeugen ? 

• mit welchen Erfahrungen ? 

• wo besteht Handlungsbedarf für Forschung/Toolhersteller ? 

In welchen Phasen? 

In der Praxis wird entweder in den sehr frühen Phasen der IT-Entwicklung modelliert oder 

auch kurz vor der Codierung, im letzteren Fall meist, um Code-Teile aus den Modellen generieren 

zu können. In den dazwischen liegenden Phasen wird nur sehr sparsam modelliert. Insbesondere 

gibt es nur sehr selten eine durch ein Metamodell integrierte Modelllandschaft über 

alle Phasen hinweg. 

Zu welchem Zweck ? 

Als Zweck der Modellierung wird meist die Kommunikation der Entwickler mit den Fachanwendern 

angegeben. Auch die Unterstützung durch Modellierungstechniken bei der Strukturierung 

des fachlichen Inhalts wird erwähnt. Wie bereits oben angeführt, ist der Zweck der 

Modellierung in den späteren Phasen meist alleine die aus den Modellen heraus mögliche 

Generierung. 

Mit welchen Techniken ? 

In der Anforderungsanalyse und für das fachliche Feinkonzept werden in der Hauptsache die 

Modelle, die die Statik des Systems beschreiben (vor allem Klassenmodelle), verwendet. 

Auch die eher informelle Beschreibung der Use Cases hat sich etabliert. 

In den technischen Phasen werden meist proprietäre Modelle verwendet (nur sehr selten 

UML), um daraus Code zu generieren. 

Mit welchen Werkzeugen ? 

Erstaunlich oft werden keine datenbankbasierten Modellierungswerkzeuge verwendet, sondern 

reine Zeichenwerkzeuge (wie z.B. Powerpoint) oder auch Visio. 

Mit welchen Erfahrungen ? 

23

Ein klares Ergebnis dieser Arbeitsgruppe war leider die Tatsache, dass die Modellierung in 

der Praxis oft sehr viele negative Aspekte aufweist. Als hauptsächliche Mankos wurden angeführt: 

• Die Modellierung ist keine Vorgabe des Unternehmens, daher wird sie meist kaum gesteuert 

und damit auch nicht zielgerichtet eingesetzt. 

• Modelle werden kaum gepflegt. 

• In keinem der betrachteten Unternehmen gab es eine durchgängige (alle Phasen umfassende) 

Modellierungslandschaft. Modelle wurden nur punktuell, nicht miteinander vernetzt, 

eingesetzt. 

• Auch die negativen Erfahrungen mit bestehenden Modellierungssprachen (unklare Semantik, 

zu schwergewichtig) wurden immer wieder angeführt. 

Glücklicherweise standen diesen Mankos auch ein paar positive Erfahrungen gegenüber, die 

allerdings unserer Meinung nach den negativen Gesamteindruck nicht aufheben können: 

• Gute Erfahrungen wurden mit dem Einsatz domänenspezifischer Modellierungssprachen 

gemacht. 

• Im Bereich der Workflow-Management-Anwendungen gibt es Beispiele für die Durchgängigkeit 

der Modellierung. 

• Auch die Möglichkeit der guten Kommunikation mit dem Kunden / Fachabteilung durch 

informelle Modelle wie z.B. Use-Cases wurde hervorgehoben. 

• Wie oben bereits öfter erwähnt, scheint auch die Möglichkeit der Generierung aus Modellen 

zu guten Erfahrungen geführt zu haben. 

Wo besteht Handlungsbedarf für Forschung/Toolhersteller ? 

Wie aus den Erfahrungen ableitbar, wurde der größte Handlungsbedarf darin gesehen, heterogene 

Modellierungslandschaften zu vernetzen, um z.B. Konsistenzen zu prüfen. Hierzu passt 

der Wunsch, die Lücke zwischen informellen und formellen Modellierungstechniken zu 

schließen. Auch die Anwendung von geeigneten Modellierungstechniken für unterschiedliche 

Hard- und Software-Situationen (Host-Systeme, Standard-Software, Individual-Software,...) 

wurde als erforschungswert angesehen. Viel ist auch noch zu tun, um die Modelle wartbarer 

zu machen und die Validierung der Modelle zu unterstützen. 

Fazit: 

Die Anwendung von Modellierungstechniken in der Praxis ist noch lange nicht so weit, wie 

die Teilnehmer es sich optimal vorstellen könnten. Unternehmensführungen sowie die die 

Modellierungstechniken zu verwendenden Mitarbeiter müssen überzeugt und motiviert werden, 

dass Modellierung für sie viele Vorteile hat (und nicht nur Arbeit macht!). 

Die grundlegenden Techniken und Verfahren für die Modellierung sind im Großen und Ganzen 

vorhanden, müssen jedoch zum Einsatz gebracht werden. 

Dennoch ist auch noch (siehe Handlungsbedarf) im akademischen Bereich viel zu tun, um die 

Modellierung umfassend einsetzbarer und effizienter zu machen. 

24

Modellierung in der Praxis 

Bestandsaufnahme der Modellierungspraxis 

Günther Müller-Luschnat, FAST GmbH 

Friederike Nickl, Sepis GmbH 

Vorgehensweise im Workshop 

• Ursprünglich angedacht: 

Strukturierte Diskussion an Hand eines Fragebogens 

Zu aufwändig und zeitraubend 

• Beschränkung auf folgende Fragen für jeden der Teilnehmer: 

Einsatz der Modellierung in der Praxis 

– in welchem Phasen ? 

– zu welchem Zweck ? 

– mit welchen Techniken ? 

– mit welchen Erfahrungen ? 

– wo besteht Handlungsbedarf für Forschung/Toolhersteller ? 

25


In welchem Phasen ? 

Meist in sehr frühen Phasen oder sehr späten (Codenahen) 

Phasen (zur Generierung). Dazwischen wird die 

Modellierung sehr sparsam angewendet, insbesondere 

keine Verbindung zwischen Phasen. 

Zu welchem Zweck ? 

In frühen Phasen zur Kommunikation oder/und zur 

Strukturierung, in späten Phasen zur Generierung 

Mit welchen Techniken ? 

Meist die statischen Modelle (Klassenmodelle) oder 

sehr informelle (Use-Case-Diagramme) 

Generierung meist nicht aus Standardmodellen (UML), 

sondern aus proprietären Modellen 

Mit welchen Werkzeugen? 

Pragmatische Anwendung: Oft Powerpoint, Visio 


Mit welchen Erfahrungen ? 

+ Einsatz domänenspez. Sprachen 

+ Generierung aus Modellen 

+ Einsatz informeller Modelle in der Kommunikation mit den 

Kunden 

+ Wegwerfmodelle im Sinne von Prototyping 

+ Durchgängigkeit der Modellierung im WfM-Bereich 

(Generierung) 

- Modellierung zum Selbstzweck (zu detailliert, nicht 

zielgerichtet, nicht umsetzbar) 

- Unklare Semantik bestehender Modellierungssprachen 

- Nur Punktueller Einsatz 

- Keine Durchgängigkeit 

- Modellierung ist keine Unternehmensvorgabe 

- Modelle werden kaum gepflegt (auch bei langlebigen Systemen) 

- UML zu schwergewichtig 

26


Wo besteht Handlungsbedarf für Forschung/Toolhersteller ? 

• Modellierungsmittel für heterogene Landschaften (Unterschiedliche 

Host-Systeme, Standard-Software, Ind.-Software,...) 

• Validierung von Modellen (z.B. durch Ausführbarkeit) 

• Vernetzung von Modellen (incl. Konsistenzprüfung) 

• Sichten auf Modelle 

• Modelle wartbarer machen 

• Komponentenmodellierung 

• Lücke zwischen informellen und formalen Modellierungstechniken 

schließen 

• Regeln zur Beschreibung der Modellierungsidee (Design-Regeln) 

27

2 

Modellierung 

versus 

Programmierung 

Thomas Kühne 

TU Darmstadt 

Friedrich Steimann 

FernUniversität Hagen 

Modellierung vs Programmierung 

Programmierung 

Modellierung 

28

3 

4 


Wunsch 

» Kontinuität, Durchgängikeit 

» homogene Notation 

(unvermeidlicher) Bruch? 

» IC(Assembler) > IC(Model) 

» IC(Assembler) = IC(Model) + IC(Transformation) 

Unterscheidung 

» Mod \ Prog 

» Mod Prog 


Abgrenzungskriterien für Mod \ Prog 

» Berechenbarkeit 

» Unvollständigkeit 

» Intention 

Kriterien für Artefakte in der Schnittmenge 

» Abstammung, Compiler 

» Zweck 

… vieles Interessantes mehr 

29

www.es.tu-darmstadt.de 


1 

2 

25.04.2005 

25.04.2005 

Arbeitsgruppe 

Modell-Transformations 

Modell Transformations-Ansätze: Ansätze: 

Nutzungsszenarien, Klassifikation, Werkzeuge, ... 

Andy Schürr + 13 weitere Teilnehmer 

Fachgebiet Echtzeitsysteme 

Fachbereich Elektrotechnik und Informationstechnik 

Technische Universität Darmstadt 

Diskussionsthemen 


Gestern: 

• braucht man Transformationssprachen (Standards?) 

• Einsatzszenarien für Transformationsansätze 

• Eingrenzung des Begriffs „Modelltransformation“ 

• Eigenschaften von Transformationssprachen 

Heute!: 

• Klassifikation von Modelltransformations-Ansätzen 

Zukunft?: 

• Gründung eines AKs für Dokumentation, Vergleich, ... 


30



3 

4 

25.04.2005 

Braucht man Transformationssprachen 

• Nein, da man alles direkt programmieren kann 

• Ja, in vielen verschiedenen Szenarien 

• Standardisierung von Sprachen heute (noch) sinnlos 

•... 

25.04.2005 

Einsatzszenarien 


• Verfeinerungskonzept, Anreicherung, ... von Modellen 

• Mischung, Verweben von Aspekten/Facetten 

• Modellevolution (Schemaevolution, Refactoring, ... ) 

• Komposition wiederverwendbarer Teilmodelle 

• Konfiguration von Modellen (z.B. für Produktlinien) 

• Modellintegration (von Sichten, Abstraktionsebenen) 

• Definition von Sichten, Extraktion von Teilmodellen 

• Generierung von Testfällen, Code, GUIs, ... 

• Referenzmodellübersetzung 

• Übersetzung zwischen verschiedenen Notationen 

• Verifikation von Modelleigenschaften 


31



5 

6 

25.04.2005 

Was sind Modelltransformationen 

• nur vollautomatische Manipulation von Modellen – nein 

(auch interaktive Steuerung mit einbezogen) 

• nur auf einer Modellierungsebene (wie DB-Bereich) - nein 

(Unterschied Transformation und Mapping) 

• sind Parser, Pretty-Printer Transformatoren – ja 

(ModellText-Transformationen, TextText-Trafos) 

• sind Layoutoperationen Transformationen – ja 

(da sehr praxisrelevant und Grenzziehung schwierig) 

Modellre- Modell 

präsentation 

CodeCodefragmente 

Fragment 

25.04.2005 

Repr.- 

Grammatik 

Modell- 

Parser 

Code- 

Generator 

Text- 

Templates 

„Forward“ Forward“-MDA MDA-Ansatz Ansatz 

Meta- 

Modell 

Meta- 

Objekte 

Modell- 

Übersetzer 

Meta- 

Objekte 

Meta- 

Modell 


AnalyseCodeergebnisse Fragment 

Modell- 

Analysator 

Modell- 

Transformator 

Spezifikation 

Spezifikation 


Level 1 

(PIM) 

Level 2 

(PSM) 

32

7 

25.04.2005 



Spezifikation 

Code- 

Fragment 

Modell 

„Reverse“ 

Reverse“-MDA 

MDA-Ansatz 

Ansatz 

Modellre- 

präsentation 

Repr.- 

Generator 

Meta- 

Objekte 

Modell- 

Transformator 

Modell- 

Analysator 

Modell- 

Übersetzer 

Meta- 

Objekte 

Code- 

Parser 

Code- 

fragmente 

Level 1 

(PIM) 

Level 2 

(PSM) 

Repr.- 

Grammatik 

Repr.- 

Templates 

Meta- 

Modell 

Spezifikation 

Meta- 

Modell 

8 

25.04.2005 



Spezifikation 

Code- 

Fragment 

Modell 

Modellintegration 

Modellintegration 

Modellre- 

präsentation 

Modell- 

Parser 

Meta- 

Objekte 

Modell- 

Transformator 

Modell- 

Analysator 

Konsistenz- 

Prüfer 

Meta- 

Objekte 

Modell- 

Parser 

Modellre- 

präsentation 

Level 1 

Level 2 

Repr.- 

Grammatik 

Repr.- 

Grammatik 

Meta- 

Modell 

Spezifikation 

Meta- 

Modell 

33



9 

10 

25.04.2005 

Kritik an Abbildungen 

• Layoutaspekte werden meist ignoriert 

• Integration/Manipulation von höchstens 2 Modellen 

• ist Integration wirklich der Vergleich 2er Modelle oder 

Abbildung in ein gemeinsames Modell ? 

25.04.2005 

Weitere Aspekte 


• Modelltransformations-Forschung ignoriert Know-How: 

• Datenbank-Community 

• Compilerbau-Community 

• [formale Grundlagen] 

• auf welcher Meta-Ebene bewegen sich 

• Modelltransformationen 

• Transformationsregeln 

• Transformationssprachen 

• Konzepte der / Kalküle für Modelltransformationen 


34



11 

12 

25.04.2005 

Diskussionsthemen 

Gestern: 

• braucht man Transformationssprachen (Standards?) 

• Einsatzszenarien für Transformationsansätze 

• Eingrenzung des Begriffs „Modelltransformation“ 

• Eigenschaften von Transformationssprachen 

Heute!: 

• Klassifikation von Modelltransformations-Ansätzen 

Zukunft?: 

• Gründung eines AKs für Dokumentation, Vergleich, ... 

25.04.2005 


Obligate OMG-Anforderungen 

OMG Anforderungen an Trafo-Sprache 

Trafo Sprache 

• eignet sich auch als „ad-hoc“-Anfragesprache 

• erlaubt Definition von Sichten auf Modellen 

• Transformationen auf 1 Modell und zwischen 2! Modellen 

• erlaubt automatische Generierung von Zielmodellen 

• deklarativer Ansatz: inkrementelle Änderungspropagation 

• Syntax der Transformationssprache mit MOF definiert 

• operiert auf MOF-Instanzen 


35



13 

14 

25.04.2005 

Optionale OMG-Anforderungen 

OMG Anforderungen an Trafo-Sprache 

Trafo Sprache 

• unterstützt bidirektionale Modelltransformationen 

• erzeugt Traceability-Relationships zwischen Modellen 

• hat Konzepte für generische, wiederverwendbare, 

spezialisierbare Transformationen (Bibliotheken) 

• erlaubt Verwendung von Transaktionsmechanismen 

• Einbezug zusätzlicher Informationsquellen zur Steuerung 

von Transformationen 

• erlaubt Berechnung abgeleiteter Daten in einem Modell 

25.04.2005 


Klassifikation nach Czarnecki 

Eigenschaften von Transformationsansätzen: 

• Aufbau von Transformationsregeln 

• Einschränkung der Anwendbarkeit einer Regel (Scope) 

• Beziehungen zwischen Quelle und Ziel 

• Regelanwendungsstrategie (nichtdet., parallel, ... ) 

• Regelsteuerung (Metaregeln) 

• Strukturierung von Regelmengen 

• Traceability 

• Bidirektionalität 


36



15 

16 

25.04.2005 

Klassifikation nach Czarnecki 

Kategorien von Transformationen 

• Modell auf Text abbilden 

• Visitor-based 

• Template-based 

•... 

• Modell auf Modell abbilden 

• API-Programmierung 

• relational 

• Graphtransformationen 

• XSLT 

• hybrid 

25.04.2005 

Fehlende Aspekte 

• Formale Eigenschaften von Transformationen: 

• semantikerhaltend 

• ... 



37


17 

25.04.2005 

Folienfriedhof - erfolgreiche Trafo-Ansätze 

Trafo Ansätze 

• Compiler-Bau, Code-Generierung 

• Schemaintegration, Schemaevolution im DB-Bereich 

• im Verifikationsbereich 

• Dokumentationsgenerierung 


38

Prof. Dr. B. Rumpe 

Software Systems 

Engineering 

TU Braunschweig 

Seite 1 

bei/04.11.09 



Engineering 


Seite 2 

bei/04.11.09 

IDL 

Kern der MDA: 

PIM, PSM und Transformationen 

Plattform Independent Model (PIM) 

• abstrakt, unabhängig von Details wie Middleware etc. 

Plattform Specific Model (PSM) (oft gleich Code) 

• Technologie-abhängig, Plattform-Optimierungen, etc. 

Platform Independent Model 

(PIM) 

transformation 

Platform Specific Model 

(PSM) 

Beispiele für PIM→PSM-Transformationen 

PIM: UML Model 

interface Car 

{ 

}; 

Car 

color : Color 

type : CarType 

ower : Person 

Java 

class Car 

{ private Color color; 

public Color 

getColor() { 

... 

}; 

DTD 

 

J2EE 

SQL-Tables 

JDBC-Codes 

Invariants 

Objects 

m-c-33: Car 

color = Green 

type = BMW 

ower = Felix 

bs-k-9: Car 

color = Blue 

type = VW 

ower = John 

39



Engineering 


Seite 3 

bei/04.11.09 



Engineering 


Seite 4 

bei/04.11.09 

Formen von Transformationen 

Ein PIM für mehrere Platformen 

Mehrere PIM auf eine Platform 


(PIM 1) 


(PSM 1) 

Evolution von 

Modellen 

0 platform dependency 

+ 

Abstraction Spectrum 

Platform depencency 

- 


(PSM 1) 


(PIM) 


(PIM 2) 

single transformation 

used several times 


(PSM 2) 


(PSM 2) 

Model 

(PIM) 

Fusion von Modellen 


MDA bei THALES (Paris) 

PSM 

CODE 

PIM 

PIM 

Analysis Models 

Hintereinanderschaltung 

von 

Transformationen 

Model 1 

(PIM 1) 

Might contain implicit information 

related to a type of platform but none 

explicit information (architecural style) 

PSM 

CODE 

Model 1 + 2 

(PSM) 

A PSM contains some 

explicit information 

related to the target platform 

No more model but code 

fusing 



(PIM) 

Model 2 

(PIM 2) 

transformation 1 

„PSM 1“ = „PIM 2“ 

transformation 2 


(PSM 2) 

PIM scope 

PIM requires no 

change at all to 

be deployed on 

another platform 

PSM scope 

PSM is dedicated 

to a specific 

platform 

PLATFORM 

scope 

40



Engineering 


Seite 5 

bei/04.11.09 



Engineering 


Seite 6 

bei/04.11.09 

Ziele von MDA 

Wiederverwendung: 

• „Separation of concerns“ in die PIM und die Transformation 

erhöht Wiederverwendung: 

PIM 

• PIM ist weiderverwendbar bei einer Transition zu neuer 

Technologie 

PSM 

• Transformation ist wiederverwendbar für andere Applikationen auf 

diesselbe Plattform 

Produktivität: 

• wird besser durch Wiederverwendung 

Portabilität: 

• leichtere Portierbarkeit der technologieunabhängigen PIM 

Interoperabilität: 

• erzeugung mehrerer PSM für unterschiedliche Plattformen und Bridges 

erhöht die Interoperabilität 

Wartung und Dokumentation: 

• PIM eignet sich als Dokumentation genau so wie als Quelle von 

Evolution 

Different Forms of DSLs 

Wizard 

page MainPage () { 

filename = index.html 

placeHolders { 

header = fragmentCall { include = Header() } 

leftNavigation = fragmentCall { include = LeftNavigation(nil) } 

rightNavigation = fragmentCall { include = RightNavigation() } 

body = fragment { filename = main/main.html 

filterElement = body } 

footer = fragmentCall { include = Footer () } 

} 

} 

Textual DSL 

Configuration tool 

Library in a 

programming language 

Visual DSL 

… 

41

Aspektorientierte Modellierung 

Hintergrund 

Jan Jürjens 

TU München 

Historischer Hintergrund: Objekt-orientierte Programmierung. 

Typische Sichtweise: zB UML 

Struktur (Klassen, Komponenten, Deployment): konkret 

bis abstrakt 

Verhalten (Statecharts, Interaktion, Koordination): 

(relativ) konkrete funktionale Beschreibung, bzgl. 

Struktureinheiten oder deren Interaktion 

Grundidee: Modularisierung 

Was ist mit abstrakter oder nicht-funktionaler Beschreibung 

von Eigenschaften (insbes. Verhalten) ? 

Was mit querschnittsartig über Struktureinheiten 

übergreifende, unhandlich zu modularisierende 

Eigenschaften ? 

42

Aspekt-Orientierte Programmierung 

Erlaubt Beschreibung und Implementierung von 

Querschnittseigenschaften durch neues Konzept: 

Aspekte (Kiczales). 

Entitäten, die über die Struktur anderer Einheiten 

übergreifen 

Entitäten, die durch partielle Information über 

andere Einheiten definiert werden 

Design- und Implementierungsebene. 

Nicht-/Funktional; abstrakt/konkret. 

Geht über traditionelle Modularisierung hinaus. 

Aspekte / concerns 

A-priori Modularisierung problematisch. 

concerns: 

Nicht-Funktionale Anforderungen 

Security (Vertraulichkeit), Benutzbarkeit, 

Performanz, … 

Kernsystem 

Ausnahmebehandlung, Logging, Transaktionen, 

Parallelität 

Sichten: Dynamisch, statisch. 

„Security keine Funktion sondern Eigenschaft“ 

43

concerns sind… 

Systemmerkmale die mit bisherigen Methoden 

nicht gut modelliert werden können 

Querschnittseigenschaft ? Nicht 

notwendigerweise „orthogonal“ ? 

Eigenschaft die hineingewoben werden 

müssen 

AOM = Quantification + Obliviousness 

[Philman et al] 

Beispiele für funktionale Aspekte ? 

Modellierungsansätze 

UML Collaborationsdiagramme 

UML Stereotypen 

Umsetzung eines concerns als Verfeinerung 

(Einsatz ggf. auch Erweiterung) 

Aspektorientierte Meta-Modellierung ? 

Re-Engineering von Aspekten 

Forward-Engineering: Integration von 

Aspekten 

44

Probleme 

AOM bricht Lokalitätsprinzip in 2-dimens. 

graph. Modellierung 

Skalierbarkeit vs. Verständlichkeit vs. 

Interaktion von Aspekten ? 

AspectJ konkret, AOP statt AOM, 

eingeschränkt 

Realisierung 

AspectJ, HyperJ 

Feature-oriented Programming 

Container 

Nicht-funktionale vs. funktionale 

Anforderungen 

Python: Function Declarators 

45

Ad Theoretische Fundierung 

46

Modelling Software Architectures 

Sitzung auf der Modellierung 2005 

W. Hasselbring, Uni Oldenburg 

http://se.informatik.uni-oldenburg.de/ 

Ziel dieser Sitzung war primär eine Diskussion des Zwecks der Modellierung von Software- 

Architekturen. Eine Terminologiediskussion des Begriffs „Software-Architektur“ wurde, 

insbesondere aus Zeitgründen, nicht vorgeschaltet: Am SEI gibt es beispielsweise eine recht 

längliche Auflistung von vorgeschlagenen Definitionen. Eine entsprechende Diskussion hätte 

möglicherweise die ganze Sitzung gefüllt. Stattdessen sei auf den entsprechenden IEEE 

Standard 1471-2000 zur Terminologie der Software-Architekturbeschreibung verwiesen, wo 

z.B. die Konzepte der Viewpoints und Views definiert werden. 

Die Modellierung von Software-Architekturen zielt primär auf die Betrachtung nichtfunktionaler 

Aspekte von Software-Systemen. Ein zentrales Ziel ist die Bewertung der 

Qualität der modellierten Software-Systeme, bevor diese realisiert werden. Die Genauigkeit 

der Bewertungen sollte am später realisierten System überprüft werden, um die zukünftigen 

Vorhersagen zu verbessern. 

Im Gegensatz zur Modellierung von Software-Architekturen wird in der fach-konzeptuellen 

Modellierung primär die Funktionalität eines zu entwickelnden Software-Systems betrachtet. 

Zur Modellierung der Komponenten und deren Beziehungen für ein konkretes System sollte 

beispielsweise auf Vererbung zwischen Komponenten verzichtet werden. Bei der Modellierung 

von Referenzarchitekturen, z.B. für Produktlinien, sind Generalisierungs/Spezialisierungs-Beziehungen 

jedoch sehr sinnvoll. 

Wesentliches Ergebnis der Diskussion ist das nachfolgende Mind-Map. Viele Konzepte 

treffen generell auf die Modellierung zu, die Konzepte mit für die Architekturmodellierung 

spezifischen Anforderungen und Techniken sind durch markiert. 

static 

dynamic Viewpoints 

resource mapping 

Views 

Type 

Metamodel level 

Instance 

Formal 

Semi-formal 

Notation 

Informal 

Standards 

Iterative 

Incremental 

Construction 

Reverse engineering Reconstruction 

Refactoring 

Patterns 

Self-organization Peer-to-peer 

Styles 

Client-server 

Library viewpoints 

Variability Product lines 

Wrapper 

Transformation 

Process 

Reference architectures 

Component adaptation 

Description 

Reuse 

Goal 

Modeling Software 

Architectures 

Documentation 

Communication 

Understanding 

Blueprint 

Strategic IT management 

Design evaluation 

Evolution 

Constraints 

Evaluation 

Migration 

Reconfiguration 

Among stakeholders 

Programming-in-the-large 

Prediction 

Assessment 

Measurement 

Budget 

Ressources 

Existing infrastructure 

Simulation 

Analysis 

Clients 

Architects 

Developers 

Assessors 

Quality attributes (QoS) 

Characteristics 

Metrics 

W. Hasselbring 


47

Modellbasierte Entwicklung eingebetteter Systeme 

Uni Heidelberg 

10. Januar 2005 - 14. Januar 2005 

Diskrepanz Disziplinen „MBEES“ 

• ITG-FG 4 Beschreibungssprachen und Modellierung von 

Schaltungen und Systemen, (Kontakt: Hr. Wolfgang Ecker, Infineon) 

• ITG-FA 6.2 Industrielle Methoden der Software-Entwicklung (FB 6 

Technische Informatik) (Kontakt: Hr. Philip Dellafera, T-Systems) 

• GI-FG 4.4.2 Echtzeitprogrammierung (EP-PEARL, FB ITTN), AK 

Modellierung von Echtzeitsystemen (Kontakt: Fr. Vogel-Heuser, Uni 

Wuppertal) 

• GI-FG 2.1.9 Objektorientierte Softwareentwicklung (OOSE, FB 

Softwaretechnik), AK Modellbasierte Entwicklung/Embedded 

Systems, (Kontakt: Hr. Riebisch, Uni Illmenau) 

• GI-Querschittsausschuss Modellierung (Kontakt: Hr. Andy Schürr) 

48

Diskrepanz Industrie/Universität „MBEES“ 

• AUTOSAR: Offener Architekturstandard für eine E/E-Infrastruktur zur 

Integration von Softwaremodulen 

– Themen: Kommunikationsmodelle, Middleware 

• MSR-MEGMA: Bibliothek-Standards für den modellbasierten Entwurf von 

Steuergerätefunktionen für Kraftfahrzeuge. 

– Themen: Funktionsbausteine, Testfälle 

• HIS: Unterstützung Hersteller-/Zuliefererprozess im Automobilbau 

– Themen: Werkzeugdurchgängigkeit, übergreifende Standards 

• OMG: Domänenspezifische Standards für plattformspezifische und 

plattformunabhängige Spezifikationen 

– Themen: UML-Profile, PIM/PDM-Beschreibungen 

Themenfelder (Auszug MBEES-Workshop) 

• Kombination Regelungstechnik/Informatik 

– Beschreibungsmodelle: Zustandsmaschinen vs. Blockdiagramme 

– Berechnungmodelle: DES vs SDF 

49


• Phasenspezifische Beschreibungstechniken/Modelle: 

– Anforderungsmodelle: Funktion, Szenario 

– Designmodelle: Komponente, (dynamische) Schnittstellen 

– Implementierungsmodelle: Tasks, Deployment 


• Analytische und generative Verfahren: 

– Analytische: z.B. Überprüfung von Design Standards 

– Generative: z.B. Testfallgenerierung 

50

Mögliches Ergebnis der Arbeitsgruppe 

AK-übergreifende “Agenda” für Modellbasierte Entwicklung von Embedded 

Systems: 

1. Spezifische Problemfelder: Welche Themen müssen addressiert werden? 

1. Motivation: Abgleich Industrie/Universität, Integration Disziplinen 

2. Beispiele: Produktlinien, Durchgängigkeit bis zur HAL 

2. Spezifische Modelle: Welche (Informatik-)Modelle sind hier hilfreich? 

1. Motivation: Unterstützung neuer Sichten, Vermittlung in der Ausbildung, 

2. Beispiele: Integrierte CT/DES-Modelle, Funktionsbäume 

3. Spezifische Verfahren: Welche Techniken sind relevant? 

1. Motivation: Transfer vorhandener/Identifikation fehlender Techniken 

2. Beispiele: Design Standard Checker, Timing Analysis, Testfallgenerierung 

51

Ergebnisse der Arbeitsgruppe: 

Modellbasierte Entwicklung eingebetteter Systeme 

Uni Heidelberg 

18. März 2005 

Warum ist die Informatik (noch) nicht „angekommen“? 

• “Außensicht der Informatik”: Bereitstellung von Middleware und OO- 

Prinzipien 

• “Negativ-Image”: Unreflektierter Einsatz (zustandsorientierter) UML- 

Modelle auf regelungstechnische Probleme 

• „Matlab-Add-On“: Tradition der regelungstechnischen Werkzeuge 

und Modelle 

• „No quick wins“: Zugewinn vieler Informatikmethoden nur 

projektübergreifend erfahrbar 

• „Generische vs spezifische Lösungen“: Kaum Bereitstellung von 

Standardlösungen im Embedded-Bereich durch die Informatik 

• „Der blinde Fleck“: Mangelnde Integration von 

regelungstechnischen Ansätzen in die Informatik 

52

Wo hilft die Informatik unmittelbar? 

• Ablösen des Komponenten-Kopie-Ansatzes durch das Prinzips der 

Klasse-Instanz-Beziehung 

• Definition von domänenspezifische Architekturmodellen: 

Schichtenmodelle, Bushierarchien 

• Konstruktion von hybriden Umgebungsmodellen: Abstraktere und 

erweiterte Modelle der Umgebung 

• Definition von Entwurfsebenen: Funktionsarchitektur, logische 

Architektur, technische Architektur 

• Vermittlung von Modellen und Techniken zur Unterstützung der 

Anforderungsanalyse und -definition 

• Vermittlung von Modellen und Techniken zur Beschreibung von 

Varianten und Produktlinien 

Was gehört auf eine „Embedded-Roadmap“ für die Informatik? 

• Integrierte Beschreibung hybrider (regelungstechnischer und 

ereignisgetriebener) Modelle 

• Konstruktion domänenspezifische Bibliotheken wiederverwendbarer 

Komponenten/Funktionen 

• Modelle für Fehler und Fehlerausbreitung bei Software- und 

Hardware/Softwaresystemen 

• Modelle und Techniken für Komposition von Gesamtfunktionen aus 

Einzelfunktionen 

• Modelle für (Schnittstellen-)Verhalten zur Unterstützung der 

Verteilung und Integration 

• Eigenschaftserhaltende Übergänge zwischen den Entwurfsebenen 

53

Komponentenbasierte Modellierung 

Bernhard Thalheim, Roland Kaschek 

54

Software-Entwicklung und Modellierung 

Brigitte Bartsch-Spörl 

Jürgen Ebert 

Martin Glinz 

Johannes Siedersleben 

Elmar Sinz 

Podiumsdiskussion 

Brigitte Bartsch-Spörl: 

Im Unterschied zur Programmierung ermöglicht Modellierung in der Gruppe 

diskutierbare, bewusste Entwurfsentscheidungen – und damit leichter 

erweiterbare und wartbare Systeme. 

Jürgen Ebert: 

• Abgrenzung Modellierungssprache – Programmiersprache macht keinen Sinn. 

• Integration verschiedener Sprachen als Herausforderung 

Martin Glinz: 

• Software-Entwicklung ist Modellierung 

• Modellierung allein nicht genug 

Johannes Siedersleben: 

• Bei größeren Projekten ist Modellierung unumgänglich. 

• Allerdings: Es gibt noch einen erheblichen Forschungsbedarf: insb. Komponentenentwurf 

und Offenheit gegenüber verschiedenen Modellierungsansätzen. 

Elmar Sinz: 

• Die Verwendung grafischer Sprachen in der Softwareentwicklung ist nicht 

gleichzusetzen mit Modellierung. 

• Softwareentwicklung ist mehr als Modellierung. 

55 

1

Thesen: 

- Modellierung passiert: 

Modellierung ist eine zwangsläufig notwendige Vorstufe für die 

Softwareentwicklung von nichttrivialer Funktionalität 

- Modellierung lohnt: 

Modellieren kostet Zeit und Geld – aber Nicht-Modellieren Nicht Modellieren kommt 

auf den Lebenszyklus der Software betrachtet noch viel teurer 

- Modellierung erzeugt Qualität: 

Modellierung ermöglicht in der Gruppe diskutierbare, bewusste 

Entwurfsentscheidungen – und damit leichter erweiterbare und 

wartbare Systeme 

56

Software-Entwicklung und 

Modellierung 

Podiumsdiskussion, Modellierung 2005 

Martin Glinz 

www.ifi.unizh.ch/req 

Universität Zürich 

Institut für Informatik 

Software-Entwicklung ist Modellierung 

Software ist vielfach (immer?) selbst ein Modell 

Anforderungen sind Modelle der Problemstellung 

Architekturen und Entwürfe sind Modelle der Lösung 

Testvorschriften sind Modelle des korrekten Funktionierens des Codes 

usw. 

„Die Artefakte der Software-Entwicklung sind Modelle“ (Jürgen Ebert) 

Aber: die Umkehrung gilt nicht, auch nicht in der Informatik! 

Software-Entwicklung und Modellierung © 2005 by Martin Glinz 2 

57

Schön, und was haben wir nun davon? 

Modellierung liefert 

ein grundlegendes Verständnis der Natur von Software-Artefakten 

eine Reihe grundlegender Sprachen und Methoden zur 

Problembeschreibung und -analyse 

grundlegendes Problemlösungswissen 

konzeptionelle Grundlagen für den Bau von Software-Werkzeugen 

Modellierung liefert nicht 

das notwendige domänenspezifische Wissen 

das notwendige Informatik-Fachwissen 

das notwendige Prozesswissen (Arbeitstechniken und Verfahren) 

das notwendige Führungswissen 

Software-Entwicklung und Modellierung © 2005 by Martin Glinz 3 

58

Modellierung 

und Softwaretechnik 

Jürgen Ebert 

Universität Koblenz-Landau 

© Institut für Softwaretechnik 


Podiumsbeitrag 

hier: 

konservative, 

sprach-orientierte, 

nicht philosophische 

Sicht der Softwaretechnik 



25.04.2005 

Jürgen Ebert 

25.04.2005 

1 

59

Aspekte der Softwaretechnik 

Aspekte der Softwaretechnik 

• Prozesse 

(erfassen Umgang mit Artefakten) 

• Sprachen 

(beschreiben Artefakte) 

• Methoden 

(erstellen oder analysieren Artefakte) 



Sprachen 

Zur Zeit haben wir eine Vielfalt von 

Sprachen im Entwicklungsprozess 

• informell – formal 

• visuell – textuell 

Probleme: 

• Sprachspezifikation 

• Sprachintegration 



Jürgen Ebert 

25.04.2005 

Jürgen Ebert 

25.04.2005 

2 

3 

60

Sprachspezifikation 

Für alle Sprachen muss der fassbare 

formalisierbare Anteil auch formalisiert 

werden. 

Eine Sprache kann mehrere Semantiken 

haben (Notenschlüsselmetapher). 

Beispiel: extensional, intensional 



Sprachintegration 

Ziel: 

• eine Breitbandsprache 

• visuell und textuell 

• multiperspektivisch 

• integriert 



Jürgen Ebert 

25.04.2005 

Jürgen Ebert 

25.04.2005 

4 

5 

61

Zusammenfassung 

Abgrenzung Modellierungssprache – 

Programmiersprache macht keinen Sinn. 

• Manche Artefakte modellieren Teile der 

Domäne (Rekonstruktion), 

• Andere modellieren Ausführungsprozesse 

(Konstruktion). 



Herausforderungen 

Jürgen Ebert 

25.04.2005 

Neue Systemparadigmen (post-OO) 

erfordern neue Sprachen und damit neue 

Modellparadigmen. 

Beispiele 

•Komponenten 

•Aspekte 

•Agenten 

•Services 

•u.v.a.m. 



Jürgen Ebert 

25.04.2005 

6 

7 

62

Herausforderungen 

• Verstehen der Sprachen, die wir haben. 

• Suchen und Erfinden anderer Sprachen. 

• Integration verschiedener Sprachen 

• Transformation von Artefakten innerhalb 

und zwischen Sprachen 



Jürgen Ebert 

25.04.2005 

8 

63

Thesen 

Workshop Modellierung 2005 

Heidelberg 16.-18. März 2005 

Analogie zwischen 

Softwareentwicklung und Modellierung? 

Prof. Dr. Elmar J. Sinz 

Lehrstuhl für Wirtschaftsinformatik, 

insbes. Systementwicklung und Datenbankanwendung 

Otto-Friedrich-Universität Bamberg 

Modellierung versus Systementwicklung 

1. Systementwicklung im Allgemeinen und Softwareentwicklung im 

Speziellen sind mehr als Modellierung. 

2. Modelle (und Modellierung) gehören zu den wichtigsten methodischen 

Hilfsmitteln der Systementwicklung. 

3. Die Anhebung von Spezifikationsebenen und die Verwendung grafischer 

Sprachen in der Softwareentwicklung ist nicht gleichzusetzen mit 

Modellierung. 

Prof. Dr. E. J. Sinz, Universität Bamberg 

64

Modelle und Modelleigenschaften 

Abbildorientierter Modellbegriff 

Modell M=(S O , S M , f) 

Objektsystem 

S O 

Modellabbildung f 

Modell M 

Metamodell 

Modellsystem 

S M 

Anforderungen an das Modellsystem: 

• Das Modellsystem muss formal konsistent und vollständig in 

Bezug auf das Metamodell sein. 

• Das Modellsystem muss struktur- und verhaltenstreu in Bezug 

auf das Objektsystem sein. Dies wird durch die Verwendung 

homomorpher und isomorpher Modellabbildungen erreicht. 


Modelle und Modelleigenschaften 

Konstruktivistisches Modellierungsverständnis 

Klärung der Rolle des modellierenden Subjekts im Rahmen der 

Modellbildung 

Objektsystem 

S O 

Realität 

Kontext 

Perzeption 

Modellabbildung 

Interpretation 

Subjekt 

Modellziele 

Modellsystem 

S M 

Konstruktion 


65

Aufgabenebene 

Aufgabenträgerebene 

Anwendungssysteme als maschinelle Aufgabenträger 

Aufgaben- und Aufgabenträgerebene des IS 

Betriebliches Informationssystem (IS) 

(Teil-) Aufgabe 

nicht-automatisiert 

Mensch-Computer- 

Kommunikation Anwendungssystem 

(AwS) 

Personeller 

Aufgabenträger 


teilautomatisiert 

Info-Bez. 


automatisiert 

Maschineller 

Aufgabenträger 


Modell der Systementwicklungsaufgabe 

Betriebliche Aufgabe 


Sachziel Formalziel 

Vorereignis 

Lösungsverfahren 

Nachereignis 

Aufgabenobjekt 

Ein Aufgabenträger (personell oder 

maschinell) stellt ein Lösungsverfahren 

für eine (nicht-automatisierte 

oder automatisierte) betriebliche 

Aufgabe bereit und führt dieses durch. 

Methodische Grundlagen der Systementwicklung 

Systementwicklungsaufgabe 

Sachziel Formalziel 

Vorereignis 

Lösungsverfahren 

Nachereignis 

Aufgabenobjekt 

• Sachziel: 

Entwicklung eines Softwaresystems, welches 

vorgegebene (inhaltliche und qualitative) 

Anforderungen erfüllt. 

• Formalziel: 

Zeit-, Kosten- und Qualitätsziele für die 

Durchführung der Aufgabe. 

• Aufgabenobjekt: 

Zu entwickelndes Produkt in Form von Modellen 

und Spezifikationen des zu konstruierenden 

Softwaresystems. 

• Vorereignis: 

Auslösung der Aufgabendurchführung in Form 

der Initiierung des Systementwicklungsprojekts. 

• Nachereignis: 

Vorliegen des eingeführten, betriebsbereiten und 

abgenommenen Softwaresystems. 

• Lösungsverfahren: 

Phasenorientierte Durchführung von 

Entwicklungsschritten. 

66

Fachliche Ebenen 

Softwaretechnische Ebenen 

Methodische Grundlagen der Systementwicklung 

Beschreibungsebenen und zugehörige Aktivitäten 

Modell des betrieblichen 

Objektsystems 

Anwendungsmodell 

Softwarearchitektur 

Programme 

Bitte klicken sie auf die 

Folie, um die Animation 

zu starten 

Beschreibungsebene Inhalt 

Aktivität 

Fachliches Modell der 

betrieblichen Diskurswelt 

und ihrer relevanten 

Umwelt. 

Fachliches Modell des 

betrieblichen 

Anwendungssystems. 

Spezifikation der 

Softwarearchitektur des 

betrieblichen 


Spezifikation der 

Programme (Quellcode) 

des betrieblichen 





Analysieren und 

Definieren der fachlichen 

Anforderungen an das 

Anwendungssystem. 

Phase Anforderungsanalyse 

und –definition (A) 

Entwerfen der Struktur der 

Software („Programmieren 

im Großen“). 

Phase Softwaredesign (D) 

Programmieren, d.h. 

Codieren der Programme 

(„Programmieren im 

Kleinen“). 

Phase Realisierung (R) 

Diskussion 

1. Modellierung im Sinne des abbildorientierten Modellbegriffs bezieht sich 

auf Modelle als 3-Tupel M=(So , Sm , f). 

Unterscheidung zwischen Modell und (semi-) formaler 

Spezifikationen eines Systems in einer (grafischen) Notation. 

2. Modellierung im Sinne des konstruktivistischen Modellierungsverständnisses 

bezieht sich auf Modelle, bei denen das Objektsystem S o 

ein Ausschnitt der betrieblichen Realität ist. 

3. Modelle mit realem Objektsystem S o treten in der Systementwicklung 

insbesondere in Form des Modells des betrieblichen Objektsystems und 

des Anwendungsmodells auf. 

4. Modelle mit (semi-) formalem Objektsystem So werden insbesondere 

auf der softwaretechnischen Ebene der Systementwicklung verwendet. 

Aber: Eine (semi-) formale Spezifikationen eines Systems ist 

nicht notwendig ein Bestandteil eines Modells. 

67

Thesen 


1. Systementwicklung im Allgemeinen und Softwareentwicklung im 

Speziellen sind mehr als Modellierung. 

2. Modelle (und Modellierung) gehören zu den wichtigsten methodischen 

Hilfsmitteln der Systementwicklung. 

3. Die Anhebung von Spezifikationsebenen und die Verwendung grafischer 

Sprachen in der Softwareentwicklung ist nicht gleichzusetzen mit 

Modellierung. 


68

Tagungsbericht PDF, 2.4 MB

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?