Unbeschreibliche Architekturen

Eine bekannte Binsenweisheit lautet, dass zur Dokumentation architektonischer Entwürfe eine Sprache notwendig ist. Seit zwei Jahrzehnten gilt die UML als bewährtes Mittel für diesen Zweck. Sind also UML und SysML die ultimativen Antworten auf die Frage aller Fragen? Mitnichten.

Wenige dürften sich noch daran erinnern, dass vor der UML eine Inflation von Modellierungssprachen herrschte. Irgendwann taten sich dann die "drei Amigos" Rumbaugh, Jacobson, und Booch zusammen, um der Vielfalt ein Ende zu bereiten. Geboren war die "Einfalt" in Gestalt der Unified Modeling Language.

Neben der Etablierung als standardisierte Modellierungssprache hat die UML weitere Vorteile wie ein Meta-Modell und die OCL (Object Constraint Language) zur Beschreibung von Einschränkungen. Des Weiteren existieren heute zahlreiche konkurrierende Werkzeuge, was jedenfalls in der Steinzeit von objektorientierter Analyse und Design nicht der Fall war.

Leider eignet sich die UML trotz aller Bemühungen nur bedingt zur Kommunikation der Projektbeteiligten, weil die Sprache für Nichtinformatiker bisweilen schwer durchschaubar ist. Im Übrigen habe ich auch schon Informatiker beim Enträtseln von UML-Diagrammen angetroffen. Abgesehen davon nutzen viele Projekte nur die Spitze des UML-Eisberges, weil sie die UML-Werkzeuge ausschließlich zum Malen einsetzen, nicht aber zur halbwegs formalen Spezifikation, geschweige denn zum Roundtrip-Engineering. Das könnte an der Trägheit unserer Spezies liegen. Oder schlicht daran, dass der gefühlte Nutzen kleiner ist als der Aufwand.

Was also sind die Alternativen?

Seit einer gefühlten Ewigkeit existiert eine Gemeinschaft von Informatikern, die statt UML & Co. sogenannte Architekturbeschreibungssprachen (ADL = Architecture Description Language) bevorzugt. Darunter sind Sprachen zu verstehen, die generische Abstraktionen für Komponente oder Kommunikationskanal anbieten. Es gibt – überspitzt ausgedrückt – allerdings mehr Architekturbeschreibungssprachen als damit realisierte Systeme. Für das Verfassen theoretischer Abhandlungen machen diese Sprachen aber durchaus Sinn.

Am anderen Ende des Spektrums befinden sich domänenspezifische Sprachen, die speziell auf die jeweilige Domäne angepasste Beschreibungsmöglichkeiten offerieren. Eine DSL kann sogar Basis eines generativen Ansatzes liegen, muss es aber nicht. Freilich lohnen sich DSLs eher bei Mehrfachnutzung, nicht aber für singuläre Lösungen. Die daraus resultierenden Vorteile sind Nachverfolgbarkeit und Produktivitätssteigerung. Dafür ist der Erstellungsaufwand nicht unerheblich. Schließlich entwerfen Entwickler zunächst die DSL und dann auf dieser Basis die Beschreibung der eigentlichen Lösungsarchitektur. Leider gibt es zahlreiche DSLs, deren Urheber nur über rudimentäres Wissen zu Sprachdesign verfügen. Dementsprechend fragil, komplex und mehrdeutig sind die Elaborate.

Offensichtlich haben also alle Beschreibungssprachen ihre Stärken und Schwächen.

Was also tun?

Da Architekturdokumente ein Mittel zur Kommunikation darstellen, wäre es auch denkbar, die Problemdomäne und die Lösungsdomäne mit anderen Sprachmitteln zu beschreiben, zum Beispiel die Lösungsdomäne mit UML und die Problemdomäne mit einer passenden DSL. Dann ist allerdings eine Abbildung von der Problemdomäne auf die Lösungsdomäne notwendig. Die MDA (Model Driven Architecture) der OMG (Object Management Group) verfolgt diesen Weg.

Zusätzlich bietet es sich an, komplexe Domänen mittels Domain Driven Design in Subdomänen zu unterteilen und die Beziehung der Subdomänen zu spezifizieren – Eric Evans lässt grüßen. Dann könnten für jede Subdomäne sogar eigene, dafür aber kleinere Modellierungssprachen zum Einsatz kommen. Sofern sich die Grenzen zwischen den Subdomänen auf eindeutige und überschaubar wenige Punkte beschränken, dürfte dieser Ansatz gangbar sein. Das passiert übrigens in ähnlicher Form bereits bei Systementwicklungen mit mehreren Gewerken (Mechatronik, Elektronik ...). Die Sprachauswahl für Subdomänen und deren Nutzung geschieht durch die entsprechenden Domänenexperten.

Wir vergessen gelegentlich, dass sich die UML grundsätzlich sogar zur Definition von DSLs eignen würde, was viele wegen der damit verbundenen Mühen scheuen. Im Detail wegen der Aufwände für eigene Diagrammelemente sowie wegen der Aufwände zur Metamodellierung, Generierung und Modellverifikation.

Möglich ist auch die pragmatische Verwendung eigener (informeller) Sprachmittel während der Erarbeitung der Architektur, während die anschließende Dokumentation mit formalen Modellierungssprachen geschehen könnte.

Es zeigt sich insgesamt, dass es nicht die Sprache für alle Probleme geben kann. In Projekten erweist es sich andererseits, dass viele Probleme aus der unzureichenden Kommunikation von Architekturen herrühren, weshalb eine formalere Spezifikation nötig ist. Die jeweils ideale Sprache hängt von verschiedenen Faktoren ab, beispielsweise von der Zielgruppe der Spezifikation, von der Domäne, vom Aufwands-/Nutzen-Verhältnis. Aber Achtung! "One size fits all" ist in diesem Zusammenhang genauso wenig hilfreich wie ein "Best-Of-Breed-Ansatz". ()