Effizienz kann durch geschicktes Weglassen unnötiger Arbeit (Dokumentation, nicht benötigte Funktionalität, etc.) verbessert werden, aber auch durch die effizientere Erstellung der Implementierung.

Die Qualität des entwickelten Produkts ist nicht notwendigerweise im Fokus aller Techniken einer agilen Methode. Bestimmte Elemente einer agilen Methode, wie zum Beispiel die Konzentration auf die Einfachheit des Entwurfs und die umfassende Entwicklung automatisierter Tests, unterstützen die Verbesserung der Qualität. Andere Vorgaben, die von manchen agilen Methoden getroffen werden, wie etwa das Fehlen detaillierter Spezifikationen und Reviews, stehen einer Verwendung für hochkritische Systeme eher entgegen, so dass dafür ein alternativer Prozess oder eine geeignete Erweiterung zu wählen ist.

Unterstützung der Agilität durch verbesserte Techniken

Die Verbesserung der Agilität eines Projekts kann neben einer Neugestaltung der Aktivitäten insbesondere durch Erhöhung der Effizienz der einzelnen Entwickler erreicht werden. Dabei sind Effizienzsteigerungen bei der Erstellung von Modellen, der Implementierung und von Tests von Interesse. Besonders wirksam ist es, wenn die Implementierung und die Tests möglichst effizient oder sogar vollständig automatisch aus Modellen hergeleitet werden können. Eine solche automatische Generierung ist dann von Interesse, wenn die benutzte Quellsprache für die Modelle eine kompaktere Darstellung erlaubt, als es die Implementierung selbst könnte.

Prämisse für diese Einsatzform von Modellen ist die schnellere Erstellung aufgrund größerer Kompaktheit, die aber dennoch eine vollständige Beschreibung des Systems erlaubt. Die UML ist in der im UML-Standard [OMG10] angebotenen Form dafür nicht ausreichend. Deshalb ist die UML/P so erweitert worden, dass sie eine vollständige Programmiersprache beinhaltet.

Einsatzformen für Modelle

Modelle, aus denen Code generiert wird, erfordern einen hohen Detaillierungsgrad. Dafür entfällt die aufwendige Aktivität der sonst üblichen Codierung. Die detaillierte Modellierung und die Implementierung verschmelzen zu einer einzigen Tätigkeit. Codegenerierung ist also ein wichtiges Hilfsmittel für den erfolgreichen Einsatz von Modellen. Dadurch wird ein ähnliches Ziel wie in XP erreicht, bei dem Entwurfs- und Modellierungsvorgänge grundsätzlich im Code repräsentiert werden.

Es gibt jedoch neben der Codegenerierung noch weitere Ziele für die Modelle eingesetzt werden können. Für die Kommunikation zwischen Entwicklern reichen abstrakte und relativ informelle Modelle aus. Abstraktion bedeutet, dass Details ausgelassen werden können, die zur Darstellung des kommunizierten Sachverhalts nicht von Interesse sind. Informalität bedeutet, dass die sprachliche Korrektheit des dargestellten Modells nicht präzise eingehalten werden muss. Beispielsweise können Diagramme auf Papier durchaus intuitive, aber nicht notwendigerweise zur Sprache gehörige notationelle Elemente nutzen, wenn die Entwickler sich über deren Bedeutung soweit wie notwendig einig sind. Außerdem muss bei informellen Diagrammen die Konsistenz des Diagramms mit dem modellierten Sachverhalt sowie anderen Diagrammen nicht vollständig gegeben sein.

Modelle können darüber hinaus zur Dokumentation des Systems eingesetzt werden. Dokumentation ist eine in Schriftform gebrachte und damit für längeren Gebrauch vorgesehene Form der Kommunikation. Damit sind je nach Ziel der Dokumentation ein höherer Detaillierungsgrad, größere Formalität und Konsistenz sinnvoll. Für ein knappes Dokument zur Übersicht der Architektur eines Systems und eine Einführung in wesentliche Entscheidungen, die zu dieser Architektur führten, ist die Detaillierung niedrig, aber Formalität und Konsistenz innerhalb des Modells und mit der Implementierung wichtig. Für eine vollständige Dokumentation ist es ideal, die Übereinstimmung der Dokumentation mit dem implementierten System dadurch zu erreichen, dass die Implementierung und soweit möglich auch Tests aus den Modellen der Dokumentation generiert werden.

In einem Projekt, das sich auf die UML/P zur Modellierung und zur Implementierung stützt, ist also zwischen

• Implementierungs-Modellen,
• Testmodellen,
• Modellen zur Dokumentation und
• Modellen zur Kommunikation

zu unterscheiden. Für alle Zwecke lässt sich die UML/P einsetzen, obwohl diese Modelle unterschiedliche Charakteristika besitzen. Ein wesentlicher Vorteil besteht aber darin, dass zwischen Spezifikation, Implementierung und Testfällen keine Notationsbrüche stattfinden. Die UML/P bietet die Möglichkeit, sowohl für detaillierte, als auch für abstrakte und unvollständige Modellbildungen verwendet zu werden.

Bearbeitung von Modellen

Wenn ein Modell ausschließlich zur Kommunikation dient, liegt es typischerweise nur als informelle Zeichnung vor. Ein Modell, das durch ein Werkzeug erstellt wurde, besitzt eine formale Repräsentation der Syntax³ und kann daher zur werkzeuggestützten Weiterbearbeitung dienen. Die Syntax der UML/P ist deshalb in den Anhängen A, Band 1, B, Band 1 und C, Band 1 definiert.

Als eine der wesentlichen Techniken für den Einsatz von Modellen wurde bereits die Codegenerierung identifiziert. Sie besitzt zwei Varianten. Zum einen kann der Produktionscode generiert werden. Zum anderen kann Testcode generiert werden.

Die Notwendigkeit zur Adaption von Software aufgrund sich ändernder Bedingungen erfordert es außerdem, dass auch Techniken zur Transformation beziehungsweise für das Refactoring dieser Modelle zur Verfügung stehen. Die systematische, bei jedem Schritt durch automatisierte Tests und Invarianten überprüfte Adaption von Modellen auf neue und geänderte Funktionalitäten erlaubt diese bereits aus XP bekannte dynamische Anpassung. Da ein Modell nach den aufgestellten Anforderungen kompakter und damit leichter verständlich ist als der Code, wird die Anpassung von Modellen ebenfalls erleichtert. Zum Beispiel können strukturelle Anpassungen, die im Code über viele Dateien verstreut waren, innerhalb eines Klassendiagramms bearbeitet werden. Die Notwendigkeit der frühen Entwicklung und Fixierung einer adäquaten Architektur nimmt, wie bereits im XP-Ansatz beobachtet, weiter ab. Umgekehrt steigt die Flexibilität zur Einarbeitung neuer Funktionalität und damit die Agilität des Projekts weiter an.

Als wesentliche Techniken im Umgang mit Modellen können daher

• die Generierung des Produktionscodes,
• die Generierung des Testcodes und
• das Refactoring von Modellen

identifiziert werden [Rum02]. Darüber hinaus sind verschiedene Techniken zur Analyse von Modellen, wie zum Beispiel die Erreichbarkeit von Zuständen in Statecharts, von Interesse. Hilfreich zur effizienten Erstellung von Tests ist auch die Ableitung von Testfällen aus OCL-Bedingungen oder Statecharts.

Spezielle Techniken, wie zum Beispiel zur Generierung von Datenbanktabellen, einer einfachen graphischen Oberfläche aus Datenmodellen oder zur Migration von zum alten Modell konformen Datenbeständen in ein neues Modell, sind ebenfalls wichtig und von einem geeignet parametrisierten Codegenerator zu unterstützen. Solche Techniken werden allerdings in diesem Buch nicht weiter vertieft.

Weitere sinnvolle Prinzipien und Praktiken

Für die Komplettierung einer Vorgehensweise sind projektspezifisch weitere Prinzipien und Praktiken zu wählen. Für kleine Projekte lässt sich zum Beispiel die folgende, vor allem an XP angelehnte Liste identifizieren:

• Viele, kleine Iterationen und Releases,
• Einfachheit,
• schnelles Feedback,
• permanenter Dialog mit dem ständig verfügbaren Kunden,
• tägliche kurze interne Treffen zur Abstimmung,
• Review nach jeder Iteration zur Prozessoptimierung,
• Tests vor der Implementierung entwickeln („Test-First“),
• Pair Programming als Lern- und Review-Technik,
• gemeinsamer Besitz der Modelle,
• kontinuierliche Integration und
• Modellierungsstandards als Vorgabe für Form und Kommentierung der Modelle ähnlich den Codierungsstandards.

Die Entwicklung von Tests vor einer Implementierung nach dem in Abschnitt 2.3.2 diskutierten Test-First-Ansatz lässt sich hervorragend auf UML/P übertragen. Sequenzdiagramme, die eine wesentliche Komponente von Tests sind, werden zunächst als Beschreibungen für Anwendungsfälle modelliert und können dann mit vertretbarem Aufwand in Testfälle transformiert werden. Ähnliches gilt für Objektdiagramme, die als Beispiele für Datensätze bei der Anforderungserfassung erstellt werden können.

Ein projektweiter Modellierungsstandard ist notwendig, um die Lesbarkeit eines erstellten Modells, das von allen Projektbeteiligten bei Bedarf angepasst und erweitert werden kann, sicherzustellen.

Analog zur Verwendung einer Programmiersprache ist es notwendig, dass die mit UML/P modellierenden Entwickler die benutzte Sprache beherrschen. Eine eventuell notwendige Lernphase kann durch Pair Programming, das jetzt besser als „paarweise Modellierung“ zu bezeichnen ist, unterstützt werden.

Qualität, Ressourcen und Projektziele

Die Effekte der in diesem Abschnitt skizzierten Vorgehensweise können anhand des in Abschnitt 2.2 diskutierten Wertesystems und der unter anderem ebenfalls in XP verwendeten vier Kriterien (Zeitverbrauch, Kosten, Qualität und Zielfokussierung) erörtert werden.

Kommunikation

ist anhand von UML/P-Modellen besser zu bewerkstelligen als anhand von Implementierungscode, wenn davon ausgegangen wird, dass die Kommunikationspartner UML beherrschen.

Einfachheit

der Software wird aus zwei Gründen noch besser unterstützt. Zum einen ist es aufgrund der leichten Änderbarkeit noch unwichtiger, Strukturen für potentiell notwendige, zukünftige Funktionalität vorzubereiten und dadurch frühzeitig eventuell ungenutzte Komplexität einzubauen. Zum anderen können nicht mehr notwendige Elemente durch Refactoring-Schritte aus dem Modell noch leichter entfernt werden. Es bleibt jedoch notwendig, dass die Entwickler selbst unnötige Komplexität und überflüssige Funktionalität erkennen.⁴

Feedback

ist durch die größere Effizienz der Entwicklung und die daraus resultierenden noch kürzeren Iterationen gesichert.

Eigenverantwortung und Courage

müssen und können den Entwicklern wie in XP erhalten bleiben.

Die vier wesentlichen Variablen des Projektmanagements werden ebenfalls adressiert:

Zeitverbrauch

Zeitliche Einsparungen und insbesondere die frühzeitige Verfügbarkeit erster Fassungen („Time-To-Market“) ist nicht nur für Internet-Applikationen wesentlich. Die gesteigerte Effizienz der Entwicklung und die höhere Wiederverwendbarkeit technischer Anteile führen diesbezüglich zu einer Optimierung.

Kosten

sinken aufgrund gesteigerter Effizienz und des daraus resultierenden reduzierten Zeit- und Personalaufwands. Aufgrund gesunkenen Personalaufwands können außerdem Managementelemente weggelassen werden, so dass der verwendete Prozess leichtgewichtiger und damit weitere Einsparungen möglich werden.

Qualität

Die Qualität des Produkts wird durch die kompakte und damit übersichtlichere Darstellung des Systems, durch die leichtere Modellierung von Testfällen und durch den nicht mehr vorhandenen Bruch zwischen Modellierungs- und Implementierungssprache positiv beeinflusst. Ob die Qualität des resultierenden Systems den Ansprüchen genügt, kann durch Konzentration auf weitere Aspekte, wie dem Test-Überdeckungsgrad, zusätzlichen Modell-Reviews und der aktiven Einbindung des Kunden gesteuert werden.

Zielfokussierung

Um sicherzustellen, dass das System in der vom Anwender gewünschten Form implementiert wird, ist die aktive Einbindung des Anwenders wichtig. Die Verwendung der UML/P hat darauf keinen Einfluss, denn es ist davon auszugehen, dass einem Anwender im Normalfall kaum UML-Diagramme zur Diskussion vorgelegt werden können.

Probleme der agilen, UML-basierten Softwareentwicklung

Neben den diskutierten Vorteilen hat die skizzierte Vorgehensweise auch einige Nachteile, die beachtet werden sollten:

• Der Vorteil, dass nahezu dieselbe Notation für die abstrakte Modellierung und die Implementierung verwendet werden kann, kann sich als Bumerang erweisen. Frühere Ansätze zur Modellierung essentieller Eigenschaften, wie etwa SDL [IT07b, IT07a] oder Algebraische Spezifikationen [EM85,  BFG⁺93], wurden aufgrund ihrer Ausführbarkeit in der Praxis vor allem als High-Level-Programmiersprachen eingesetzt. Dasselbe wird nun für eine Teilsprache der UML vorgeschlagen.⁵ Beim Einsatz der UML/P zur Spezifikation kann dies dazu führen, dass für die Spezifikation unnötige Details ausgefüllt werden, weil ein späterer Einsatz als Implementierung bereits vorweg genommen wird. Dieses Phänomen ist auch als „Überspezifikation“ oder „Overengineering“ bekannt.
• Der Lernaufwand für die Verwendung der UML/P ist als groß einzuschätzen. UML/P ist syntaktisch deutlich reichhaltiger als Java, so dass sich hier ein schrittweises Vorgehen empfiehlt. Zunächst ist der Einsatz zur Strukturbeschreibung mit Klassen- und Objektdiagrammen interessant. Als nächstes können Sequenzdiagramme zur Testfallmodellierung und darauf basierend OCL zur Definition von Bedingungen, Invarianten und Methodenspezifikationen erlernt werden. Die Verwendung von Statecharts zur Verhaltensmodellierung erfordert am meisten Übung.
  Ähnlich wie in Java ist jedoch nicht nur die Beherrschung der Syntax, sondern insbesondere die Verwendung von Modellierungsstandards und Entwurfsmustern sinnvoll, die ebenfalls erlernt werden müssen.
• Derzeit existiert noch wenig Werkzeugunterstützung, die alle Aspekte der gewünschten Codegenerierung vollständig abdeckt. Insbesondere ist die Effizienz der Codegenerierung wesentlich zur schnellen Erstellung des Systems, die wiederum effiziente Durchführung von Tests und das daraus resultierende Feedback ermöglicht.
  Jedoch arbeiten eine Reihe von Werkzeugherstellern an der Realisierung einer solchen Vision und können bereits gute Erfolge vorzeigen.