model-dr iven developmenta l l e s u m l , o d e r ?

MODELLGETRIEBENESOFTWAREENTWICKLUNG:ALLES UML, ODER?

dazu bieten beispielsweise Tagged Values –das sind Schlüssel/Wert-Paare, von denenbeliebig viele jedem UML-Modellelementzugeordnet werden können. Darüber hin-aus hat man bei der Erstellung eines sol-chen Modells keine Möglichkeit, dasEndergebnis direkt grafisch zu prüfen.Verbessern lässt sich diese Situation nurdurch Abstraktion, die durch stark stan-dardisierte Dialogbeschreibungen erreichtwerden kann.

Allerdings lassen sich nicht für alleAnwendungsbereiche Dialoge derart stan-dardisieren. Daher haben sich für dieErstellung grafischer BenutzeroberflächenGUI Builder durchgesetzt – Spezialwerk-zeuge, die eine Bearbeitung im WYSI-

Bei modellgetriebener Softwareentwicklung werden aus kompakten Modellbeschreibun-gen lauffähige Softwareprogramme generiert. Solche Modellbeschreibungen werdenmeist mit Hilfe der Unified Modeling Language (UML) erstellt. Eine Beschränkung aufdie UML ist aber nicht sinnvoll, da es auch andere direkt nutzbare Modellquellen gibt.Solche stellt dieser Artikel anhand von Beispielen aus dem Bereich grafischer Benutzer-schnittstellen vor. Insbesondere eine Kombination aus UML- und GUI-Modell erweistsich als sehr nützlich.

1 2

Wolfgang Neuhaus(E-Mail: Wolfgang.Neuhaus@itemis.de)ist Geschäftsführer und Gründer der ite-mis GmbH & Co. KG, einem innovativenBeratungshaus für objektorientierteSoftwareentwicklung. Seine Spezialgebietesind objektorientierte Vorgehensmodelle,Softwarearchitektur und MDA. Darüberhinaus ist er Mitbegründer derArchitecture Management Group(www.architecture-management-group.de).

Boris Holzer(E-Mail: boris.holzer@itemis.de) istSenior Berater und Coach bei der itemisGmbH & Co. KG. Seine Schwerpunktesind die Konzeption J2EE basierterSysteme, modellgetriebene generativeSoftwareentwicklung und das Coachingvon Entwicklungsteams. Zuletzt führteer die im Artikel geschilderte Lösungbei der Continentale Versicherung ein.

die autoren

Die Praxis hingegen zeigt, dass dieseBeschränkung die Sicht auf pragmatische,direkt nutzbare Modellquellen verstellt.Schlimmer noch: für einige Anwendungs-bereiche eignet sich die UML in der heuti-gen Form nicht besonders gut. Und dasführt zu Modellen, die nicht optimal aufdas betrachtete Problem zugeschnittensind.

Dieser Artikel verdeutlicht diese Proble-matik anhand von Beispielen aus demBereich grafischer Benutzerschnittstellen.Nach einer Einleitung wird ein Lö-sungsansatz diskutiert und anhand vonBeispielen vertieft. Ziel ist es, eineEntwicklungsmethodik aufzuzeigen, die ineinem „best of breed”-Ansatz dieKombination unterschiedlicher Beschrei-bungssprachen erlaubt.

ProblemstellungSehen wir uns zunächst einmal die grund-sätzliche Problematik anhand eines Bei-spiels an: Das UML-Klassendiagramm inAbbildung 1 ist der Versuch, den HTML-Dialog aus Abbildung 2 zu beschreiben.Im Diagramm sind allerdings nur struktu-relle Eigenschaften wie Eingabefelder,Auswahllisten oder Funktionsknöpfe be-schrieben. Für eine vollständige Beschrei-bung fehlen weitere, rein für das Layoutnotwendige Informationen wie Farben,Größen, Zeichensätze, Grafiken oderPositionen.

Obwohl es sich um einen sehr einfachenDialog handelt, wird das Klassen-diagramm bereits sehr unübersichtlich,wenn man versucht, diese Informationenzusätzlich unterzubringen. Möglichkeiten

Modellgetriebene Softwareentwicklunggewinnt immer mehr an Bedeutung undwird zunehmend öffentlich diskutiert –nicht zuletzt lesen Sie deshalb gerade dieseSonderausgabe zum Thema. Aus kompak-ten Modellbeschreibungen sollen bei dermodellgetriebenen Softwareentwicklung(teil-)automatisch lauffähige Software-programme generiert werden. Häufigjedoch wird die Diskussion über dieBeschreibungssprache von Modellen aufdie Nutzung der Unified ModelingLanguage (UML) reduziert – unter ande-rem weil auch die Object ManagementGroup (OMG) mit ihren MDA-Spezifi-kationen diese Sicht prägt.

www.objektspektrum.de

v o n w o l f g a n g n e u h a u s u n db o r i s h o l z e r

Abb. 1: UML-Klassendiagramm für diein Abb. 2 dargestellte Kundensuche

www.s igs-datacom.deModel-dr iven Development 1/04

model-dr iven developmenta l l e s u m l , o d e r ?

WYG-Modus erlauben. Mit ihnen lässtsich der statische Teil einer Benutzer-oberfläche sehr gut und effizient beschrei-ben. Leider fehlt diesen Werkzeugen in derRegel aber eine adäquate Unterstützungzur Beschreibung der dynamischen Aspek-te – also der Navigationsfolge und derBeschreibung der dazu notwendigenZustandsübergänge. Gerade in diesemBereich bietet die UML mit Aktivitäts-und Zustandsdiagrammen gute Hilfs-mittel, um eine übersichtliche und kom-pakte Beschreibung für die dynamischenAspekte erreichen zu können. Abbildung 3zeigt ein einfaches Beispiel.

In vielen Projekten haben wir die Erfah-rung gemacht, dass solche Diagrammeauch mit fachseitigen Ansprechpartnerndiskutiert werden können. Gemeinsam mitSkizzen zu den einzelnen Dialogen entstehtein sehr detailliertes und vollständiges Bildder späteren Anwendung. Ideal wäre esalso, diese beiden Beschreibungsformenfür Statik und Dynamik kombiniert nut-zen zu können, um daraus die Präsen-

tationsschicht einer Anwendung generie-ren zu können.

UML-Modell undGUI-Modell kombiniertDamit diese Kombination gelingen kann,müssen einige Randbedingungen beachtetwerden. Der verwendete GUI Builder soll-te ein maschinenlesbares Speicherformatfür die Dialogbeschreibung unterstützen.In unserem Beispiel haben wir für dieBeschreibung der Dialoge den CasabacGUI Builder verwendet (siehe Abb. 4). Erschreibt alle für die statische Beschreibungnotwendigen Informationen in eine XML-Datei. Um diese Informationen nun mitden dynamischen Informationen aus der„UML-Welt“ verbinden zu können, brau-chen wir noch zwei Dinge: Einen Parser,der das Speicherformat lesen kann, undeinen Generator, der UML-Modell undGUI-Beschreibung parallel einlesen undtransformieren kann. Dies führt zu einemZusammenspiel unterschiedlicher Tools,

das in Abbildung 5 skizziert ist. Jetzt fehltnoch der Bezug zwischen den beidenModellen. Hier gibt es unterschiedlicheMöglichkeiten, die wir im nächstenAbschnitt diskutieren wollen.

Für die Kombination der beiden Weltenmüssen wir uns zunächst einmal mit denMetamodellen der gewählten Sprachenbeschäftigen. Da wir uns zur Beschreibungder Dynamik für die „UML-Welt“ ent-schieden haben, ist das Metamodell dasder UML für Zustandsdiagramme. Ab-bildung 6 zeigt einen Ausschnitt daraus.Das Metamodell der Casabac-Dialogerepräsentiert die unterschiedlichen Wid-get-Typen, die Casabac unterstützt. Ab-bildung 7 zeigt auch daraus einenAusschnitt.

In den Tools – UML-Werkzeug und GUIBuilder – werden Instanzen dieser Meta-modelle erzeugt und bearbeitet.Anschließend werden sie in unterschied-lichen Formaten exportiert: XMI undCasabac-XML. Diese Exportformate stel-len jeweils eine konkrete Syntax zuRepräsentation der Modelle dar. ModerneMDSD-Generatoren arbeiten nicht direktauf der konkreten Syntax – beispielsweisemit XSL/XSLT –, sondern erzeugenzunächst selber eine Repräsentation dereingelesenen konkreten Syntax in Formeines instanzierten Metamodells. DieTransformation in den Quellcode erfolgtdann durch Schablonen, die ausschließlichauf das instanzierte Metamodell zugreifen.Damit wird die Transformation von derkonkreten Syntax entkoppelt. Abbildung 8zeigt die Arbeitsweise eines solchen Ge-nerators.

Damit bei der Generierung die richtigeSteuerungsinformation zur passendenMaske zugeordnet werden kann, muss dieInformation über die Zuordnung iminstanzierten Metamodell vorhanden sein.Damit der Instanziator die Metamodell-instanzen richtig „verheiraten“ kann,muss in den Modellen eine der drei folgen-den Varianten verwendet werden:

1) Gleiche/redundante Modellelemente inbeiden Modellen,

2) Proxys als Stellvertreter für Modell-elemente oder

3) Referenzen auf Modellelemente.

Bei Variante 1 werden in beiden zu verbin-denden Modellen redundante, gleicheModellelemente gepflegt und erst bei derInstanzierung der Metamodellinstanzen zueinem Element zusammengefügt. Damitkönnen in beiden Modellen (unter-

Abb. 2: HTML-Dialog zur Kundensuche

Abb. 3: Beispiel eines Zustandsdiagramms

model-dr iven developmenta l l e s u m l , o d e r ?

3 4 www.objektspektrum.de

schiedliche) Assoziationen zu weiterenModellelementen aufgebaut werden, diesomit die Verbindung zwischen beidenModellen darstellen. Dieser Weg ist fürunsere Zielsetzung, UML-Modelle mitGUI-Modellen zu verschmelzen, nicht gutgeeignet, da es bedeuten würde, entwederim Casabac GUI Builder UML-Elementeanlegen zu müssen, oder im UML-Werk-zeug Casabac Controls beschreiben zukönnen. Für beide Wege wäre eine spezifi-sche Erweiterung des jeweiligen Werk-zeugs notwendig.

Variante 2 funktioniert ähnlich, mitdem einen Unterschied, dass statt gleicherModellelemente Stellvertreter (Proxys)genutzt werden. Auch diese werden bei

der Metamodellinstanzierung durch dietatsächlichen Modellelemente aus demjeweils anderen Modell ersetzt. DieserWeg würde im UML-Werkzeug noch ohnespezifische Erweiterung funktionieren, daman beispielsweise speziell ausgezeichneteKlassen als Stellvertreter verwenden könn-te. Im Casabac GUI Builder müssten wirallerdings auch dafür wieder eine spezifi-sche Erweiterung des Werkzeugs vorneh-men.

Die am einfachsten umzusetzendeVariante ist damit die Variante 3 – die

Referenzierung. Referenzen können belie-bige, eindeutig identifizierende Merkmalevon Modellelementen sein – beispielsweiseeindeutige Namen oder Modell-IDs. Wiebei Fremdschlüsseln in relationalenDatenbanken können so Verweise aufModellelemente definiert werden. Da fürdiesen Weg keine spezifische Werkzeug-anpassung erforderlich ist, haben wir unsfür Referenzen entschieden und verwen-den dazu feste Namenskonventionen.

Unabhängig von der Wahl der Variantezur Verbindung der Modelle ist die

Abb. 4: Beschreibung der Dialoge mit Hilfe des GUI Builders Casabac

Abb. 5: Zusammenspiel der Werkzeuge

Abb. 6: Zustandsautomat des Metamodells

www.s igs-datacom.deModel-dr iven Development 1/04

model-dr iven developmenta l l e s u m l , o d e r ?

Validierung dieser Zuordnung von zentra-ler Bedeutung. Da wir unterschiedlicheTools kombinieren und keine durchgängi-ge Bearbeitung aller Modellinformationenin einem Werkzeug verwenden, müssenFehler bei der Zuordnung vor der Gene-rierung überprüft und gemeldet werden.Fehlermeldungen sollten „sprechend“sein, damit falsche Zuordnungen schnellidentifiziert werden können. So kannbereits vor der Generierung sichergestelltwerden, dass es keine falschen Referenzengibt, die zu einer fehlerhaften Generierungund damit zu nicht lauffähigenProgrammen führen. Letztlich sichern wirso die „referenzielle Integrität“.

Die notwendigeGenerator-TechnologieEin MDSD-Generator, mit dem man denskizzierten Lösungsansatz beschreitenwill, sollte also folgende Eigenschaftenhaben:

� ein flexibles, programmierbares Meta-modell,

� eine Möglichkeit zur parallelenInstanzierung des Metamodells ausunterschiedlichen Modellquellen,

� eine Unterstützung zur Validierungvon Modellierungsrichtlinien,

� eine Transformation auf Basis desinstanzierten Metamodells.

Das flexible, programmierbare Meta-modell benötigen wir, um dem Generatordie Sprachelemente (siehe Abb. 6 und 7)bekannt zu machen und um die Trans-formation von der konkreten Syntax tren-nen zu können.

Die parallele Instanziierung des Meta-modells aus unterschiedlichen Modell-quellen verwenden wir, um sowohl dasUML-Modell mit den dynamischenAspekten wie auch die GUI-Beschreibungmit den statischen Aspekten verarbeiten zukönnen. Um die Zuordnung prüfen zukönnen, setzen wir die Validierung derModellierungsrichtlinien – in unserem Falldie Referenzen auf Modellelemente – ein.Die Transformation muss dann letztlichauf das instanzierte Metamodell zugreifenkönnen.

Das von uns eingesetzte open GeneratorFramework unterstützt diese Eigen-schaften, ist als Opensource verfügbar undauf Source Forge zu finden. Eine detail-lierte Darstellung der Arbeitsweise mitdem open Generator Framework für dieVerbindung von UML-Modell undCasabac-GUI zeigt Abbildung 9. Wir ver-wenden dort einen Kompositum-Instan-ziator, der die Instanzierung einesMetamodells aus mehreren Modellquellenunterstützt – in unserem Fall aus der XMI-Datei, die die UML-Information enthält,und der Casabac-XML-Datei für dieMasken.

Mit diesem Handwerkszeug sind wir inder Lage, die Informationen aus beidenTools – UML-Werkzeug und Casabac GUIBuilder – einzulesen und über Generator-Schablonen in ausführbaren Programm-code zu transformieren. Diese Werkzeug-kombination erlaubt es uns nun, sowohldie grafische Darstellung und Strukturunserer HTML-Dialoge wie auch dieAblaufsteuerung in einer effektiven Formzu beschreiben und die Präsentations-schicht einer Anwendung vollständig dar-aus zu generieren.

FazitWas haben wir jetzt erreicht? Wir sind inder Lage, die jeweiligen Vorteile entspre-chender Spezialwerkzeuge zur Beschrei-bung unterschiedlicher Aspekte einerAnwendung nutzen und miteinander kom-binieren zu können. Dabei entstehen keineEinschränkungen für die Generierung, dadurch die Entkopplung von Transforma-tion und konkreter Syntax die Generator-Schablonen nichts von den Modellquellen„wissen“ müssen. Dadurch wird eine pro-blembezogene, gezieltere Werkzeug-

Abb. 7: Metamodell der Casabac-Dialoge

Abb. 8: MDSD-Generator-Framework

model-dr iven developmenta l l e s u m l , o d e r ?

5 www.objektspektrum.de

unterstützung ermöglicht, die die modell-getriebene, generative Softwareent-wicklung von der Beschränkung auf UMLals Modellierungssprache befreit. Auch fürMigrationsprojekte ist dieser Ansatz eineChance, vorhandene Informationsquellenwie bestehenden Quellcode oder Daten-bankschemata als Modellquellen bei derGenerierung mit berücksichtigen und ver-werten zu können.

Aber auch die Nachteile wollen wirnicht verschweigen. Denn die fehlende

Durchgängigkeit in der Werkzeugunter-stützung führt zum einen zu wenigerKomfort in der Bedienung, zum anderenzu einer erhöhten Fehleranfälligkeit bei

der Referenzierung. Unserer Erfahrungnach überwiegen jedoch die Vorteile,wenn man die Nachteile durch eine inten-sive Validierung ausgleicht.

Abb. 9: Arbeitsweise mit dem open Generator Framework für die Verbindung von UML-Modell und Casabac-GUI

LinksOpen Generator Framework, siehe: http://sourceforge.net/projects/architecturwareInformationen zu Casabac, siehe: http://www.casabac.deWeitere MDSD/MDA-Publikationen, siehe:http://www.itemis.de/publikationen.phpMDA Informationen der OMG, siehe: http://www.omg.org/mdaEine sehr lesenswerte Einordnung des Themas: http://www.voelter.de/data/articles/MDSD.pdf