Softwaremodelle: Mehr als nur Diagramme

4. März 2014

Mein letzter eXpert Talk am 13.02.2014 war mit dem Thema Softwaremodelle, deren Sinn und Bedeutung sowie geeigneten Tools zur Erstellung und Unterhaltung von Modellen überschrieben. Der eXpert Talk dient innerhalb der SDX dem technischen Austausch unter Kollegen und wird häufig gefolgt von einer Diskussion über die vorgetragenen Themen. Im Rahmen meines Vortrags habe ich zunächst die Grundlagen des modellgetriebenen Ansatzes erläutert und danach beispielhaft unter Verwendung von Sparx Enterprise Architect gezeigt, wie er im Softwareentwicklungsprozess erfolgreich in die Praxis umgesetzt werden kann, aber auch seine Nachteile und Fallstricke dargelegt. Dieser Beitrag soll die Inhalte des Talks kurz zusammenfassen.

Model-Driven Development (MDD)

Bei der modellgetriebenen Softwareentwicklung steht bekanntermaßen das Softwaremodell im Mittelpunkt. Es ist Ausgangspunkt und Richtschnur während des gesamten Softwareentwicklungsprozesses. Dieser Ansatz ist nicht neu. Bereits 2001 wurde Model-Driven Architecture (MDA) von der Object Management Group (OMG) formal ins Leben gerufen. MDA ist sozusagen die Implementierung des modellgetriebenen Ansatzes (MDD) unter Verwendung von Standards, die von der OMG vorgegeben werden. Gemeinsames Ziel ist die modellgetriebene Konzeption und Erstellung komplexer Software, wobei alle Entwickler durch die Konzentration auf das Modell zu einer sorgfältigeren, formaleren und abstrakteren Vorgehensweise beim Design der Anwendung gezwungen sind. Es soll dadurch unter anderem das sogenanntes “wild hacking” unterbunden werden, bei dem zu früh mit der Implementierung, d. h. dem Schreiben von Quellcode, begonnen wird. Somit kann die Produktivität und Softwarequalität erheblich gesteigert sowie gegebenenfalls Mehraufwand vermieden werden.

MDA
Abbildung 1: Schematische Darstellung des Roundtrip-Engineerings in MDA

Der Grundgedanke von MDA ist zunächst sehr theoretisch und kann in der Praxis auch eine Reihe von Nachteilen haben. Beispielsweise wird allen Entwicklern im Team ein hoher Abstraktionsgrad abverlangt, was bei inhomogener Teamzusammensetzung (und dies ist in der Praxis häufig der Fall) zu entsprechenden Problemen führen kann. Zum anderen wird für ein effektives Roundtrip-Engineering (siehe Abbildung 1), d. h. die fortwährende Übernahme von Codeänderungen ins Modell bzw. der Generierung von Code für neue Modellelemente, ein geeignetes Tool benötigt.

Im Laufe der Diskussion, die während des Talks aufkam, ist außerdem schnell klar geworden, dass Entwickler unterschiedliche Vorstellungen von und Erwartungen an MDD bzw. MDD-Tools haben, und dass nicht alle Erwartungen erfüllt werden können. Ich bin außerdem auch auf den empfohlenen Detailgrad von Modellen eingegangen; ein Overengineering (zu detailliertes Modell) sollte generell vermieden werden.

Sparx Enterprise Architect

Relativ zügig sind wir dann in die Demophase eingestiegen, in dessen Verlauf ich anhand eines einfachen Beispiels den Einsatz von Sparx Enterprise Architekt (EA) für MDD zeigen konnte. Anhand des SDX-Bewerbungsprozessen habe ich demonstriert, wie

  1. EA für die Erstellung eines plattformübergreifenden Modells (Platform-Independent Model, PIM), in unserem Fall ein Domänenmodell, verwendet werden kann.
  2. Das plattformübergreifende Modell mit Hilfe von konfigurierbaren Templates in ein plattformspezifisches Modell (Platform-Specific Model, PSM) transformiert werden kann.
  3. Plattformspezifische Details modelliert und Quellcode aus dem PSM generiert werden, auch hier mithilfe konfigurierbarer Templates.
  4. Die Funktionalität von EA durch Scripting und Add-Ins erweiterbar ist.
  5. EA für das Roundtrip-Engineering während des gesamten Softwareentwicklungsprozesses verwendet wird.
  6. Die Dokumentation unter Verwendung von Templates aus dem Modell generiert werden kann.

Zudem habe ich auch die anderen Features und Einsatzmöglichkeiten von EA kurz erläutert und bin auf Fragen eingegangen. Auch Nachteile/Einschränkungen des Tools sind dabei zur Sprache gekommen:

  • Eine effektive Generierung von Code aus Aktivitäts-/Sequenzdiagrammen ist nur eingeschränkt und auch nur am Anfang möglich.
  • Je nach verwendeter Plattform (Programmiersprache) werden nicht UML-konforme Codeelemente gegebenenfalls nicht unterstützt und können zu Problemen beim Reverse-/Forward-Engineering führen.
  • Ein effektives Code-Refactoring ist über EA nicht möglich und sollte deshalb besser in der Entwicklungsumgebung selbst vorgenommen werden.

Fazit

MDD kann unter Verwendung geeigneter Tools durchaus erfolgreich in der Praxis eingesetzt werden, um komplexe Systeme zu modellieren, Code aus Modellen zu erzeugen und Codeänderungen in das Modell zu übernehmen. Ich selbst setze EA für diesen Zweck bereits seit Jahren aktiv ein. Die grundsätzlich andere Herangehensweise an das Softwareprojekt, die der MDD-Ansatz Entwicklern abverlangt, kann jedoch unter Umständen zu Problemen führen. Ebenso müssen wie bei jeder Methode eventuell Kompromisse gemacht werden. MDD eignet sich vor allem in Projekten, bei denen die abzubildende Geschäftslogik einigermaßen komplex ist. Architekturvorgaben werden nicht gemacht und sind von der Anwendung selbst abhängig; MDD als Ansatz kann für die Abbildung einer Vielzahl von Architekturen und Patterns verwendet werden.