Inhalt
4. Evaluierung von MDA-Tools
Dieses Kapitel beschäftigt sich mit dem Einsatz von Entwicklungstools zur Model Driven Architecture (MDA) im Softwareentwicklungsprozess. Nach einer allgemeinen Erläuterung der MDA-Idee werden zwei MDA-Plugins für Eclipse vorgestellt, welche im Verlauf der Entwicklung der Messengeranwendung zum Einsatz kamen. Zum Ende des Kapitels wird ein Resümee über den Nutzen dieser MDA-Tools bei der Erstellung der Messengeranwendung gezogen.
4.1 Die Verwendung von MDA-Tools im Softwareentwicklungsprozess
" ... if we build buildings the way we built software, we would be unable to connect them, change them or even redecorate them easily to fit new uses; and worse, they would constantly be falling down." [omg1]
Softwareentwicklung vs. Architektur
Legt man diesen Vergleich zu Grunde, wurde Software in der Vergangenheit nur unzureichend geplant bzw. die Planung nur unzureichend umgesetzt.
Um diese Lücke zwischen der Planung und der Implementierung bzw. der Implementierung und der Dokumentation zu schließen, wurde von der Object Management Group (OMG) die Entwicklung des MDA-Standards vorangetrieben. Heute wird die Definition von Softwaremodellen in UML bzw. UML 2.0 vorgenommen, sofern sich das Softwaredesign nicht nur im Kopf des Entwicklers befindet. Ebenfalls werden bereits die Datenspeicherung und die Entwicklung der Anwendungsarchitekturen mit Hilfe entsprechender Tools automatisiert. Ziel der Model Driven Architectur ist es nun, die einzelnen Teile miteinander zu verbinden und somit eine übergreifende Umgebung für den ganzen Softwareentwicklungsprozess zur Verfügung zu stellen. Insbesondere geht es dabei auch darum, heute schon zu planen was in der Zukunft kommen wird. Somit ist MDA als ein neuer evolutionärer Schritt in der Entwicklung von Softwaresystemen zu sehen.
Schlagworte der MDA: implementation, integration, maintenance, testing and simulation.
Man wird sich jetzt sicher fragen, ob es nicht bereits solche Tools auf dem Markt gab, die diese Schlagworte umsetzten. Man kann diese Frage bejahen, denn es existierten bereits Compiler, die Datenmodelle wie UML in höhere Programmiersprachen wie Java oder C/C++ umsetzten können. OMG wollte dieses Ziel jedoch mit einem MDA-Architekturframework als Standardmodell erreichen.
Von der OMG gab es bereits ein Framework für verteilte Systeme - CORBA. Seit 2001 ist nun auch das zweite Framework von OMG erhältlich - das MDA Framework. Dieses Framework wird jedoch nicht für die Implementierung von Softwaresystemen, sondern für den Gebrauch von Softwareentwicklungsmodellen eingesetzt. Die Idee hinter dem MDA-Framework ist die Trennung der Spezifikation der Anwendung von den Details der Implementierung. Daraus resultiert die Herstellung von Plattformunabhängigkeit eines Softwaresystems.
Auf den Punkt gebracht verfolgt das MDA-Framework die folgenden Ziele: Portabilität, Interoperabilität, Wiederverwendung.
Aufbau des MDA-Frameworks
| |
Abb. 17 |
Die MDA-Architektur geht von einem mehrschichtigen System aus. Insbesondere setzt es sich mit den Bereichen understanding, design, construction, deployment, operation, maintenance und modification auseinander. Dabei wird der Fokus auf verschiedene Sichten gelegt. Zum einen gibt es ein Modell mit dem Fokus auf der Systemumwelt - das so genannte Computation Independent Model (CMI). Zum anderen das Platform Independent Model (PIM) mit dem Fokus auf dem plattformunabhängigen Betrieb des Systems und als letztes noch das Platform Specific Model mit dem Fokus auf dem Betrieb des Systems in Hinsicht auf eine spezielle Plattform. Der Übergang zwischen den einzelnen Modellen geschieht mittels Mapping. (siehe Abb. 17)
Aus einem plattformunabhängigen Modell kann man direkt den Code mittels einer direkten Transformation erzeugen. Wählt man den Weg über das plattformspezifische Modell, so wird in diesem das Modell mittels Meta Object Facility (MOF) definiert. Dabei wird ein model repository verwendet um das Modell zu spezifizieren und zu manipulieren.
Jedes MDA-Modell passt zu einer der fünf vorgegeben Spezifikationen. Diese sind:
- Service Specification (Domain-Specification; cross-domain; middleware services)
- Data Model Specification
- Language Specification
- Mapping Specification
- Network Protocol Spezification
MDA-Tools in der Studienarbeit
Die in der Studienarbeit verwendeten MDA-Plugins für Eclipse - OMONDO® UML und objectiF® - arbeiten beide auf der Stufe der plattformunabhängigen Modelle. Mittels direkter Transformation werden die im UML-Paketdiagramm angelegten Klassen, Methoden und Variablen in Java-Code umgewandelt und dem Entwicklerteam zur Verfügung gestellt. Ein weiterer Vorteil der MDA-Entwicklung ist die automatische Anpassung des Modells bei durchgeführten Codeänderungen. Somit steht zu jedem Zeitpunkt des Projekts eine aktuelle Dokumentation der Anwendung zur Verfügung. Infolge dessen ist ein wunder Punkt des Softwareentwicklungszyklus geschlossen worden.
4.2 Vorstellung verschiedener MDA-Tools
Bei der Auswahl der beiden hier vorgestellten MDA-Tools war entscheidend, dass sie als Eclipse-Plugin vorliegen und dass eine kostenlose Testversion erhältlich ist.
4.2.1 OMONDO® UML
Das Programm OMONDO® UML der OMONDO® Company, einem Mitglied der Eclipse-Entwicklergemeinde, ist ein Tool zur modellgetriebenen Softwareentwicklung, welches direkt in die Eclipseoberfläche integriert ist. Nach Herstellerangaben handelt es sich bei OMONDO® UML um eines der meist erfolgreichen Eclipse-Plugins und um das führende UML Eclipse-Plugin, welches zur Zeit auf dem Markt ist.
Mit Hilfe von OMONDO® UML soll der Entwickler unabhängig von einer technischen Implementierung sein Modell planen und später in Quellcode umsetzten können. Dies erreicht OMONDO® durch die Integration von offiziellen Standards wie zum Beispiel dem UML 2.0 OMG/IBM Standard, dem EclipseUML2 open soure metadata Standard oder der Verwendung von XMI Schemas.
OMONDO® UML unterstützt ein bidirektionales Modell auf Bytecodeebene, was die wechselseitige Verwendung von Modellentwicklung und Codeentwicklung zulässt. So stellt es für den Entwickler keinen Unterschied dar, ob er seine Änderungen am Code durchführt oder die entsprechenden Änderungen im Modell vorgenommen werden. OMONDO® UML aktualisiert das entsprechende Gegenstück bei Änderungen automatisch. Damit wird es dem Entwickler überlassen, ob er weiterhin im Code entwickelt und die Modelle lediglich zu Dokumentationszwecken verwendet, oder ob er sich der modernen modellbasierten Softwareentwicklung anschließt, welche von OMONDO® UML unterstützt wird. Dank dieser Unterstützung sind unter anderem Paket- und Klassendiagramme, Sequenzdiagramme sowie Zustandsdiagramme automatisch in der Entwicklungsumgebung Eclipse erzeugbar oder per Hand erstell- bzw. anpassbar. Durch seine Multiuserfähigkeit ist OMONDO® UML für den Einsatz in Entwicklerteams geeignet.
Es gibt eine kostenlose Free-Edition mit eingeschränkten Funktionalitäten und die mächtigere Studio-Edition, welche 20 Tage mit allen Funktionalitäten testbar ist.
4.2.2 objectiF®
Das Programm objectiF® stammt von der Firma microTOOL GmbH in Berlin. Neben dem hier verwendeten Plugin für Eclipse (Java) existiert eine weitere Plugin-Version für Visual Studio.NET (C#; VisualBasic.NET). Es ist auch eine Enterprise Edition zu beziehen, welche alle diese Sprachen in einem vereint.
Bei objectiF® handelt es sich um ein Entwicklungstool, welches für den Einsatz im kompletten Entwicklungsteam gedacht ist und über alle Entwicklungsphasen hinweg eingesetzt werden kann. So ist es durch seine Trennung in die Phasen Requirements, Design und Implementation für viele verschiedene Projektgruppen interessant. Angefangen beim business consultant, über den Systemanalytiker und den Softwarearchitekten hin zum Designer und letztendlich zum Programmierer. Ein Vorteil von objectiF® ist die Verwendung der standardisierten und weit verbreiteten Sprache UML. Im Gegensatz zu OMONDO® lässt sich objectiF® als eigenständiges Programm starten und ist nicht direkt in die Eclipseoberfläche integriert. Dadurch wird die Synchronisation nur zu vom Benutzer definierten Zeitpunkten durchgeführt und nicht parallel zur Änderung am Code oder im Modell.
objectiF® unterstützt folgende UML-Diagrammarten:
- UseCase-Diagramme
- Aktivitätsdiagramme
- Paketdiagramme
- Klassendiagramme
- Sequenzdiagramme
Insbesondere durch die UseCase-Diagramme stellt objectiF® ein effektives Kommunikationsinstrument für die Entwicklung und die formale Beschreibung der Anforderungen in einem Projekt dar. Auch eine textuelle Beschreibung und somit eine aktuelle und ausführliche Dokumentation wird von diesem Tool unterstützt. Dies wird mit Worddokumentvorlagen realisiert.
Ein weiteres Einsatzgebiet von objectiF® ist die Integration von JUnit-Tests. Durch die JUnit-Unterstützung ist eine automatische Generierung von JUnit-Testklassen zur Codekontrolle aus objectiF® möglich.
Gerade diese Möglichkeit der parallelen oder abwechselnden Arbeit in objectiF® und Eclipse und die Möglichkeit beide Sichten auf Wunsch jederzeit synchron zu halten, fördern die Mächtigkeit und den Einsatznutzen von objectiF®. Diese wird noch erweitert durch die Möglichkeit, Klassen direkt aus einer textuellen Beschreibung in Microsoft Word erzeugen zu lassen. Darüber hinaus können im Klassendiagramm Relationen zwischen Klassen festgelegt werden und die Implementierung des entsprechenden Java-Codes gestartet werden. Im Bereich der Use Cases steht eine Unterstützung von "look & feel" in der Prototypenerstellung zur Verfügung. Im sich anschließenden Aktivitätsdiagramm lassen sich die Details eines Use Cases einfach visualisieren. Dabei lassen sich die Aktivitäten in Form von swimlanes definieren.
objectiF® versteht es, die Brücke zwischen Analyse und Design mit Hilfe seiner Klassendiagramme und Use Cases zu schließen. Durch die richtige Verwendung von objectiF® wird das Projekt von Anfang bis Ende begleitet, wobei der Code stets dem Model und das Model stets dem Code entspricht.
4.3 Der Nutzen von MDA-Tools bei der Erstellung der Messengeranwendung
4.3.1 OMONDO® UML
Produktiv verwendet wurde OMONDO® bei relativ wenigen Aspekten der Erstellung der Messengerapplikation. Das war hauptsächlich in der Entwurfsphase. Der Entwurf wurde als Klassendiagramm erstellt und bei Änderungen, die sich durch Diskussionen zwangsläufig ergaben, angepasst. Auch die Sequenzdiagramme wurden in diesem Zeitraum mit dem grafischen Editor von OMONDO® erstellt. Hierbei wird der Entwickler insofern unterstützt, dass vorhandene Klassen per "Drag&Drop" und Methodenaufrufe per Auswahl aus einer Liste der vorhandenen Methoden eingefügt werden können. Am Ende der Entwurfsphase entstand daraus der Quellcode aller Klassen, Interfaces und Methodenrümpfe mit den entsprechenden Paketen.
Weiterhin wurde OMONDO® bei späteren Änderungen eingesetzt. Da es in seinen Diagrammen jedoch zum Großteil nur die Refactoring-Funktionen von Eclipse anbietet, macht es keinen Unterschied, ob diese im Quellcode oder beispielsweise im Klassendiagramm verwendet werden. Der Vorteil ist, dass - egal wo man die Änderungen durchführt - die Diagramme immer auf dem gleichen Stand wie der Code und daher stets automatisch aktuell sind. Hieraus ergibt sich aber gleich einer der Nachteile an der Installation von OMONDO®. Das Überwachen und Übertragen aller Änderungen nimmt Rechenzeit in Anspruch, was die Reaktionszeit von Eclipse in einigen Fällen auf störende Weise deutlich verlängert.
Ein Schwachpunkt des Plugins ist seine Dokumentation. Es wird ein Hilfeteil in das Hilfesystem von Eclipse integriert. Dieser ist auch in HTML-Struktur im Installationsverzeichnis verborgen und als PDF online verfügbar. Allerdings deckt diese Hilfe nicht alles ab, was OMONDO® anscheinend zu leisten vermag, und ist nicht immer intuitiv strukturiert. Auf der offiziellen OMONDO®-Homepage ist zusätzlich ein Bereich für Tutorials vorgesehen, der allerdings noch wenig gefüllt ist. Dass die Software nur auf Englisch verfügbar ist, sollte für erfahrene Softwareentwickler keine Schwierigkeiten darstellen.
In der Free-Edition wurden einige Fehler und fehlende Funktionen gefunden, die in der Studio-Edition korrigiert wurden. Beispielsweise erstellt die Studio-Edition in Methodenrümpfen bei Bedarf ein zum Rückgabeparameter der Methode passendes return-Statement, was die Free-Edition nicht tut. Dieses Versäumnis führt leider zu unnötigen Compilerfehlern. Die Free-Edition zeigt beim Erstellen von Diagrammen mehr Eigenleben. Das bedeutet, Diagrammelemente werden eigensinnig neu angeordnet oder lassen sich nicht wie gewünscht manuell anordnen. Auch traten nicht reproduzierbare sporadische Abstürze von Eclipse bei Verwendung des Diagrammeditors in der Free-Edition auf. In der Studio-Edition wurden diese nicht beobachtet.
Beim Drucken von Diagrammen auf dem Testrechner trat das Problem auf, dass alle Symbole, die üblicherweise vor den Namen von Klassen und Methoden dargestellt sind, fehlten. Dies wurde unabhängig vom gewählten Drucker beobachtet. Ein Workaround zu diesem Problem ist der Export von Diagrammen als Grafikdatei. Diese Funktion arbeitete stets einwandfrei.
| |
Abb. 18 | |
| |
Abb. 19 |
Auch das Gebiet Reengineering wird von OMONDO® abgedeckt. Zunächst kann man sich ein Paketdiagramm generieren lassen, das eine erste Übersicht gibt. Es werden alle Pakete aufgeführt einschließlich der Abhängigkeiten untereinander (siehe Abb. 18).
Ausgehend von dem Paketdiagramm lassen sich nun Klassendiagramme erzeugen. Hierfür wird im Kontextmenü eines Packages in dem vorhandenen Diagramm der entsprechende Punkt ausgewählt. Die Klassen des Packages (gegebenenfalls auch eine Auswahl davon) werden nun als Basis für das Klassendiagramm hergenommen. Man kann angeben, ob Vererbungen, Abhängigkeiten oder Assoziationen im Diagramm berücksichtigt werden sollen und bis zu welchem Umfang dies geschehen soll. Über die Angaben ?Scope? und ?Level? können die Details beispielsweise auf alle Klassen eingeschränkt werden, die direkten Bezug zu einer der ausgewählten Klasse haben. Eine großzügigere Einstellung weitet die Auswahl bis zu allen Klassen innerhalb des ganzen Projekts aus.
Es besteht immer die Möglichkeit, per Kontextmenü von einem bestehenden Diagramm ein neues abhängig von der Auswahl generieren zu lassen. In obigem Beispiel wurde das Klassendiagramm ausgehend von dem Paketdiagramm auf diese Weise erstellt. Falls schon ein entsprechendes Diagramm besteht, kann auf gleichem Wege zu diesem navigiert werden. Ebenso kann man sich so den jeweils dazugehörigen Quellcode öffnen lassen.
Im Gegensatz zur Free-Edition erkennt die Studio-Edition beim Reverse- Engineering auch Assoziationen. Als Beispiel wird die Klasse MainGui angeführt, die in einer HashMap Referenzen auf Instanzen der Klasse ChatGui hält (siehe Abb. 19). Durch Doppelklick auf den Assoziationspfeil können die detaillierten Optionen der Assoziation eingesehen und verändert werden. Die Optionen geben unter anderem an, welche Art der Collection bei Mehrfachbeziehungen verwendet wird. Da die Optionen für jedes Assoziationsende getrennt einstellbar sind, sind auch n:m- Beziehungen problemlos möglich. Änderungen in dem so erstellen Diagramm werden wiederum im Quellcode abgebildet.
Die Studio-Edition beherrscht auch Reengineering von Sequenzdiagrammen. Diese Funktion scheint jedoch nur in Einzelfällen wirklich brauchbar zu sein. Es werden alle Methodenaufrufe innerhalb einer ausgewählten Methode in das Diagramm aufgenommen. Das hat zur Folge, dass im Diagramm beispielsweise jede Verkettung von Strings als Benutzung eines StringBufferObjekts erscheint oder auch Verwendung von Iteratoren angezeigt wird. Dadurch erreicht ein solches Diagramm schnell erhebliche Ausmaße und wird unübersichtlich. Nacharbeiten werden nötig, die möglicherweise mehr Aufwand erzeugen als ein manuelles Erstellen des Sequenzdiagramms. Änderungen in einem bestehenden Sequenzdiagramm wirken sich nicht mehr auf den dazugehörigen Quellcode aus.
4.3.2 objectiF®
Das MDA-Tool objectiF® in der Version 5.0 - Personal Edition - kam erst recht spät im Softwareentwicklungszyklus zum Einsatz, da man sich in erster Linie für den begleitenden Einsatz von OMONDO® entschieden hatte. Somit wurde von objectiF® nicht der volle Leistungsumfang getestet und eingesetzt, sondern nur der Teil, der sich mit einem Reengineering zu Dokumentationszwecken und dem Thema JUnits für Modultests beschäftigt.
Einsatz im Bereich JUnits
Die Generierung von JUnit Testklassen geschieht mit dem Aufruf JUnit tests --> Create Test Class ... . Danach können für die einzelnen Klassenmethoden Testprozeduren ausgewählt werden, bevor die Testklasse erstellt wird. Nach entsprechenden Anpassungen im automatisch generierten Testcode kann eine entsprechende Aktualisierung des Eclipse Workspace vorgenommen werden. Aus Eclipse heraus lässt sich dann der entsprechende JUnit-Test starten und auswerten.
Dokumentation
| |
Abb. 22 |
Mit Hilfe von objectiF® wurden verschiedene Diagrammarten zu Dokumentationszwecken erstellt. Insbesondere sind hier Paket-, Klassen- und Sequenzdiagramme zu nennen.
Bei der Erstellung von Paketdiagrammen wird zwischen zwei Arten von einfügbaren Klassen unterschieden. Zum Einen können neue Klassen erstellt, zum Anderen bereits bestehende Klassen übernommen werden. Beziehungen zwischen bestehenden Klassen können auf Wunsch angezeigt werden, neue Beziehungen per Hand hinzugefügt werden. Ein mittels objectiF® erstelltes Paketdiagramm der Chatanwendung ist der Abb. 5 zu entnehmen.
Genauso wie die Erstellung von Paketdiagrammen verläuft, so funktioniert auch die Erstellung von Klassendiagrammen. Auch hier kann zwischen dem Einfügen existierender Klassen und dem Erstellen neuer Klassen ausgewählt werden. Wie bei OMONDO® auch, lassen sich Assoziationen zwischen Klassen grafisch darstellen. Per Hand ist einer Assoziation eine Rolle und eine Richtung zuweisbar. In der in Abb. 22 dargestellten Assoziation zwischen der MainGUI und der ChatGUI ist die 1:n Assoziation "besitzt" dargestellt. Eine Instanz der Klasse MainGUI hält über das Attribut chatWins vom Typ HashMap kein, ein oder mehrere Instanzen der ChatGUI.
| |
Abb. 23 |
Ein weiterer Einsatzbereich von objectiF® im Rahmen der Softwaredokumentation war die Erstellung von Sequenzdiagrammen. Leider müssen diese per Hand gezeichnet werden und können nicht aus dem Code erzeugt werden. Jedoch besteht die Möglichkeit, die Instanzen auf die vorhandenen Klassen abzustimmen und auch die Messageaufrufe aus einer Liste der in der entsprechenden Klasse definierten Methoden auszuwählen. Die Abfolge der einzelnen Messageaufrufe muss allerdings weiterhin von Hand vorgenommen werden und kann nicht automatisch erzeugt werden.