Der ICONIX-Prozess: Mit vier Diagrammen von Anwendungsfall zum Code

Der ICONIX-Prozess ist ein leichtgewichtiger, agiler Ansatz zur modellbasierten Softwareentwicklung. Viele Menschen, die zum ersten Mal mit Modellierung in Berührung kommen, sind überwältigt und oft eingeschüchtert von der Mächtigkeit der ausgewählten Modellierungssprache, oft UML oder SysML. Durchaus verständlich, denn diese Sprachen haben einen erheblichen Umfang, und es scheint für jedes exotische Problem ein Sprach-Feature zu geben, mit dem dieses gelöst werden kann. Aber in den meisten Fällen kommt man mit einer klitzekleinen Teilmenge der Sprache aus. Und hier kommt ICONIX ins Spiel: Der ICONIX-Prozess nutzt nur eine kleine Anzahl von Modellelementen, um vom Anwendungsfall (Use Case) zum Quellcode zu kommen.

ICONIX wird für die Softwareentwicklung eingesetzt, was im folgenden kurz beschrieben wird. Für Leser von diesem Block ist sicherlich die Anpassung von ICONIX für eingebettete Systeme auch interessant, über den ich vielleicht ein andermal schreiben werde.

ICONIX wurde für die Softwareentwicklung entwickelt, es gibt aber inzwischen auch Anpassungen für andere Bereiche, insbesondere für eingebettete Systeme.

Einen Überblick über ICONIX gibt das oben gezeigte Bild. Dies ist an vielen Stellen in der ICONIX-Dokumentation wieder zu finden und damit der Wegweiser durch den Prozess ist.

Scope: Was drin ist – und was nicht

Der ICONIX-Prozess ist in einen statischen und einen dynamischen Teil aufgeteilt, was mit den gestrichelten Linien dargestellt ist. Alles außerhalb dieser Linien ist nicht im Scope. Das bedeutet also, dass man sich schon grundlegende Gedanken über das System gemacht haben sollte.

Außerhalb der gestrichelten Linie sind Storyboard (links), Code und Tests (rechts). Diese werden zwar vom Prozess diskutiert, aber nicht modelliert.

Der Prozess wird von links nach rechts gelebt, von grob (Use Cases, Domänenmodell) nach fein (Sequenzdiagramm, Klassendiagramm). Wie jetzt schon zu erkennen ist, werden dabei vier verschiedene Diagramme aus der UML-Welt eingesetzt (für alle drei statischen Diagramme werden Klassendiagramme benutzt).

Agil und iterativ

Der ICONIX-Prozess ist so konzipiert, dass er oft und schnell durchlaufen werden kann, und damit agiles Arbeiten unterstützt. Man würde also mit einer Handvoll von Anwendungsfällen beginnen, mit diesem den kompletten Prozess durchlaufen, um dann mit der nächsten Handvoll von Anwendungsfällen das ganze zu wiederholen. Im Laufe einer Iteration gibt es ein paar Milestones, die mit einem Review verknüpft sind.

Anforderungen

Je nach Projekt gibt es unterschiedliche Quellen und Formen von Anforderungen. Das im Bild gezeigte GUI-Storyboard ist ein mögliches, dafür eingesetztes Hilfsmittel, aber es gibt natürlich viele andere. Wichtig ist, dass die Anforderungen in der Form von Anwendungsfällen festgehalten werden. Diese benötigen ein Vokabular, und das wird in der Form eines Domänenmodells dokumentiert. Der erste Review ist dann der Anforderungreview.

Analyse und vorläufiges Design

Das Robustheitsdiagramm ist nicht sonderlich bekannt. Es gibt eine Sicht auf die Interaktion von Objekt-Instanzen und verfeinert die Anwendungsfälle. Beim erstellen des Diagramms wird normalerweise auch der Anwendungsfall überarbeitet. Auch das Domänenmodell wird an dieser Stelle verbessert und erweitert, zum Beispiel mit Attributen.

Weiterhin werden in dieser Phase logische Systemfunktionen identifiziert, die für die Realisierung des Anwendungsfalls notwendig sind. Diese werden bei ICONIX als „Controllers“ bezeichnet.

Auch diese Phase endet mit einem Review des vorläufigen Designs beendet (Preliminary Design Review, PDR).

Detailliertes Design

Um das detaillierte Verhalten der Klassen zu dokumentieren, werden Sequenzdiagramme benutzt. Damit wird das Verhalten nicht nur logisch dokumentiert, sondern konkreten Klassen zugeordnet. Das passiert in der Form von Operationen, oder Funktionen, die dem Domänenmodell hinzugefügt werden.  Mit Attributen und Operationen versehen ist unser Domänenmodell plötzlich zu einem Klassenmodell geworden.

Bevor diese Phase ebenfalls mit einem Review abgeschlossen wird, sollte allerdings das Klassenmodell noch einmal überarbeitet und bereinigt werden. Das ist insbesondere daher notwendig, da wir ja – im Gegensatz zum dynamischen Modell – in der gesamten Iteration im selben Diagramm gearbeitet haben.  Der Review wird auch Critical Design Review (CDR) genannt.

Implementierung und Test

An diesem Punkt endet der Prozess, wobei natürlich schon noch auf die folgenden Aktivitäten eingegangen wird. Dazu gehört das Implementieren und Unit-Testen, welches hoffentlich Hand in Hand geht. Darüber hinaus muss auch auf den höheren Ebenen getestet werden, also Integrations-Test und das Testen der Szenarien.

Weiterhin werden Code-Reviews empfohlen. Mit großer Wahrscheinlichkeit kommen bei der Implementierung Probleme auf, die Auswirkungen auf das Modell haben. Diese Änderungen sollten natürlich auch ins Modell eingearbeitet werden.

Und die nächste Runde

Damit ist dann die Iteration abgeschlossen, und die nächsten Runde kann mit den nächsten Anwendungsfällen beginnen.

Tool-Unterstützung, Buch und Schulungen

Damit bin ich am Ende der kurzen ICONIX-Einführung. Für interessierte Leser gibt es die Möglichkeit, ICONIX mit entsprechender Literatur zu vertiefen.  Die erste Anlaufstelle ist die offizielle ICONIX-Webseite. Die Urheber von ICONIX haben auch mehrere lesenswerte Bücher geschrieben. Und sie bieten natürlich entsprechende Schulungen an.

Auch erwähnenswert ist, dass es für die populären Modellierungswerkzeuge Enterprise Architect und MagicDraw Plug-Ins für ICONIX gibt. Ich habe diese allerdings selbst noch nicht ausprobiert und weiß daher nicht, wie effektiv sie sind. Jedenfalls sollte ICONIX auch mit einem generischem UML-Werkzeug zu nutzen sein.  Ich würde mich über Kommentare von Lesern freuen, die hierzu etwas sagen können.