Kanonische Architektur-Evolution

Phillip Ghadir

Dr.-Ing. Daniel Lübke

ISO-42010 – ehemals IEEE-1471 – definiert den Begriff Softwarearchitektur mit dem Zusatz (siehe [1]):

… sowie den Prinzipien die für seinen Entwurf und seine Evolution gelten.

Während sich niemand wundert, dass Softwarearchitektur mit Bausteinen, Beziehungen oder auch Schnittstellen zu tun hat, gerät manch einer ins Stocken, was denn diese Prinzipien sein sollen? – Genau dieser Frage möchten wir hier auf den Grund gehen.

Unsere Quintessenz lautet: “Jeder Softwarearchitekt sollte in einem Entwicklungsprojekt sehr genau – und auf unterschiedlichen Detaillierungsgraden – festhalten, wie das System implementiert werden soll.” – Was in diesem Falle “sehr genau” bedeutet, hängt natürlich von den verschiedensten Projektfaktoren (Projektgröße, Kritikalität, Komplexität, Know-how …) ab.

Ein Blick in das Buch “Effektive Softwarearchitekturen” (siehe [2]) zeigt unter anderem, dass Softwarearchitekten neben Strukturen auch Konzepte entwerfen und darüber hinaus auch noch kommunizieren müssen. Die Kenntnis der im System verwendeten Konzepte ist für viele Interessenvertreter höchst relevant, auch wenn für die effektive Kommunikation nicht alle Beteiligten die mit einem Konzept assoziierten Details kennen müssen, sondern nur die an der Umsetzung beteiligten Personen.

Die Idee, dass es Konzepte auf unterschiedlichen Abstraktionsgraden gibt, ist entscheidend für das Verständnis unserer Unterscheidung des Begriffs Konzept in drei Stufen: Stereotyp, Konzept und Konstruktionsregel.

Stereotyp

Vielleicht kennen Sie den Begriff Stereotyp aus der Modellierung – beispielsweise in UML. Disclaimer: Es ist unerheblich, ob sie die UML nützlich oder nutzlos finden und ob sie die UML meiden, wie ein junger Vampir das Sonnenbad mit Weihwasser. Hier geht es lediglich um das allgemeingültige Konzept des Stereotyps. Wir verwenden Stereotyp in der Architekturarbeit als Modellierungskonstrukt, um die Semantik von Bausteinen, Schnittstellen und Beziehungen in Modellen klarer zu definieren.

Die Ausdruckskraft von Stereotypen entsteht dadurch, dass man (in der UML) prinzipiell an jedes Modellierungskonstrukt und an jedes Modellelement eine Menge von Stereotypen anhängen kann, so wie man Tags an Blog-Posts oder Tweets anhängen kann. Durch das Annotieren mit einem Stereotyp verweisen wir auf die mit dem Stereotyp assoziierte Bedeutung.

Die Erweiterung der Semantik erfolgt durch das Annotieren und können mit anderen Erweiterungsmöglichkeiten - wie z.B. Spezialisierung und Erbung - bei Bedarf kombiniert werden.

Beispiel-Stereotyp “Dialog”

Wenn wir modellieren oder mit anderen diskutieren, zeichnen wir gerne Kästchen und Pfeile. Stellen Sie sich vor, einer von uns malt – wie immer übrigens – drei Kästchen. Um zu erklären, dass eines der Kästchen anders ist als die anderen, bietet UML verschiedene Wege an. Der unaufdringlichste und am einfachsten zu verstehende, ist das Annotieren mit einem Stereotyp.

Wir können die Kästen nun so annotieren:

• «Dialog» Kundendetails
• «Dialog» Kundenübersicht
• «Entität» Kunde

Dabei haben wir nun die Stereotypen in «» geschrieben. Genauso gut hätten wir stattdessen andere Symbole zeichnen können. Für Dialoge bietet sich z.B. Bildschirm-Symbol und beispielsweise für Entität einen auf einem Strich liegenden Kreis als Symbol an. Aber da wir halt nur Kästchen zeichnen können …

Das Beispiel zeigt, dass wir als Menschen die Bedeutung der drei Kästen mindestens genauso gut verstanden hätten, wenn wir statt der Stereotypen eine ordentliche Namenskonvention – wie z.B. KundendetailDialog, KundenübersichtDialog und KundeEntität – verwendet hätten.

Der Vorteil von Stereotypen gegenüber solch einer Namenskonvention ist, dass wir bei der Diskussion über die Modellelemente (Kundendetails, Kundenübersicht, Kunde) nur dann die abstrakten Konzepte angeben müssen, wenn es relevant ist. Der Vorteil wird noch deutlicher, wenn wir Stereotypen hinzufügen, die vollkommen unabhängige Aspekte beschreiben:

• «Dialog, Bearbeitung, Audit-Log, 3270-Terminal» Kundendetails
• «Dialog, Bericht, Autorisiert, Web» Kundenübersicht
• «Entität» Kunde

Wir können uns im Modell auf die (fachlichen) Zusammenhänge zwischen den Dialogen und der Entität kümmern, ohne die technischen Facetten vernachlässigen zu müssen.

Eine kleine Anmerkung zu dem Modell: Das obige Beispiel stellt kein allgemeingültiges Modell für das Bearbeiten und Darstellen von “Kunde” dar, sondern dient lediglich dazu, die Verwendung von Stereotypen zu demonstrieren. Tendenziell haben wir in Projekten sehr häufig Stereotypen definiert, die Beziehungen zwischen Modellelementen genauer beschrieben haben. Die Stereotypen «Autorisiert» oder «Audit-Log» könnten dafür Beispiele sein.

Stereotypen – Welten voller Semantik

Mit einem Stereotyp können wir Eigenschaften definieren, die Menge der zulässigen Beziehungen beschränken oder auch gewisse Dinge erzwingen. Wenn wir stereotypisch beschreiben, müssen wir erklären, worauf der Stereotyp anwendbar ist.

Wir haben bereits ein paar Beispiele – wie Dialog oder Entität – gesehen. Wir mögen diese Beispiele, weil sie eine Idee transportieren, die klar formuliert, welche Verantwortung gekapselt wird, ohne dass etwas über die Implementierungsdetails gesagt wird. Das ist eine Stärke der Stereotypisierung, die es uns Softwarearchitekten erlaubt, mit vielen Projektbeteiligten zu sprechen und Konsequenzen zu analysieren, ohne dass diese zwingend wissen müssen, wie das Konzept zur Umsetzung eines Stereotyps in unserer Architektur aussieht.

Häufig beschreiben wir Stereotypen analog zu Glossareinträgen oder direkt im Glossar. Manchmal fördert die bildhafte Darstellung der Zusammenhänge das Verständnis. In vielen Fällen genügt aber die Beschreibung der Bedeutung und die Zuordnung eines grafischen Symbols, mit dem dann unsere Systemmodelle leichter verständlich werden.

Alltagsbeispiel für Stereotypen

Stellen Sie sich vor, wir suchen in unserer Welt nach Konzepten, die wir stereotypisch erfassen wollen. Wir treffen uns in einer Stadt, in der keiner von uns je zuvor war und gehen in ein Restaurant, um dort etwas zu essen.

Obwohl wir nicht die Küche, nicht den Koch und nicht dessen Rezepte kennen, genügt uns in den allermeisten Fällen die Speisekarte. Dort mögen Gerichte wie zum Beispiel “Spaghetti Bolognese”, “Tortellini alla Panna”, “Penne Napoli”, “Gnocchi Quattro Formaggi” stehen.

Diese Namen der Gerichte genügen uns und den meisten unserer Kollegen um zu kommunizieren, was man von dem Gericht erwarten kann. Der Stereotyp “Spaghetti Bolognese” verrät keine Details, aber dennoch kann man sich sicher sein, dass es lange Nudeln mit einer Tomaten-Hackfleisch-Soße gibt. Mit Zwiebeln, al dente, ölig, versalzen? – Keine Ahnung. Aber lange Nudeln, Hackfleisch und Tomatensoße gehören definitiv dazu.

Gäste, Kellner, Restaurantkritiker, Küchenhilfen und Köche teilen eine Vorstellung von diesen stereotypischen Gerichten. Gäste, die ein Gericht – einen Stereotyp – nicht kennen, können bequem von ihren Begleitern, dem Kellner oder praktisch allen anderen auf den aktuellen Kenntnisstand gebracht werden.

Stereotyp ist für uns daher die abstrakteste Form der in der Definition des ISO-42010 erwähnten Prinzipien, mit denen wir klären möchten, wie wir das System entwerfen und umsetzen wollen würden.

Konzepte

Um die Prinzipien zu konkretisieren, braucht man nicht nur eine klare Erwartung, die mit dem Stereotyp formuliert wird. Es braucht dazu einen ebenso klaren Umsetzungsplan, um die durch den Stereotyp beschriebenen funktionalen und qualitativen Eigenschaften realisieren zu können. Dieser Umsetzungsplan gilt schematisch unabhängig von Personen, Raum und Zeit.

Wir sagen in unseren Trainings zu Softwarearchitektur gern: “Konzepte konkretisieren Stereotypen” oder auch “Stereotypen benennen Konzepte”.

Die Softwarearchitektur kann man nicht auf dem Niveau “und hier wird programmiert” definieren. Das geht nicht weit genug, da dann jeder Entwickler “seinen” Teil der tatsächlichen Softwarearchitektur während der Umsetzung definiert.

Alltagsbeispiel für Konzepte

Konzepte können wir uns ebenfalls an der Metapher vom Restaurantbesuch in einer fremden Stadt verdeutlichen. In der Fußgängerzone stehen wir zwischen 3 Restaurants, die alle “Spaghetti Bolognese” anbieten. Der Stereotyp ist uns geläufig. Als Gast “verstehen” wir das Konzept.

Wie allerdings das Gericht zubereitet wird, kann sich in den Restaurants dramatisch unterscheiden. Im Falle der Zubereitung von Gerichten sind Kochrezepte eine Beschreibung eines Konzepts. Wer mehrere Kochbücher vergleicht, wird feststellen, dass es selbst bei einem einfachen Gericht wie “Spaghetti Bolognese” Unterschiede in der Zubereitung gibt.

Das kann bei der Verwendung der Zutaten beginnen, geht weiter über verschiedene Mengenverhältnisse der Zutaten und endet potenziell bei komplett unterschiedlichen Zubereitungsarten.

Das Kochrezept definiert abstrakt den Umsetzungsplan und ist damit ein Konzept im Sinne eines Softwarearchitekten. Es beschreibt konkret ein Prinzip für den Entwurf und die Evolution des Systems, hier das gastronomische Erlebnis.

Manchmal reicht aber auch das nicht aus.

Konstruktionsregeln garantieren Ergebnisse

Mit Konstruktionsregeln gehen wir über den Umsetzungsplan hinaus und definieren exakt, wie ein Element des Systems, das unsere Beteiligten stereotypisch kennen, umgesetzt werden soll.

Während das Konzept noch Implementierungsdetails (wie zum Beispiel konkrete Technologien) bewusst offen lässt, um hier eine Variabilität zu gewinnen, die eine Evolution im Detail erlaubt, ohne die Konzepte in Frage zu stellen, schränkt eine Konstruktionsregel diese Variabilität bewusst weiter ein, um noch mehr Zusicherungen über die tatsächliche Umsetzung ableiten zu können, wenn das System konzeptionell verstanden und konsistent umgesetzt ist.

Die Konstruktionsregeln in unserem Beispiel

Zurück im Restaurant: Die Gäste haben eine Vorahnung, was sie erwartet, wenn sie “Spaghetti Bolognese” bestellen. Der Küchengehilfe weiß, wie viel Zucker er zu den Zwiebel geben muss, wenn er sie zusammen mit mit dem Hackfleisch anbrät.

Alles ist gut. Aber ein neuer Koch in der großen Küche muss in die Lage versetzt werden, das Gericht “Spaghetti Bolognese” genauso zu kochen wie die anderen.

Er muss wissen, auf welcher Flamme, mit welchen Töpfen etc. er das Gericht zubereiten muss. Darüber hinaus erläutern die Regeln im Küchenbetrieb, wie er so kocht, dass er nicht alle anderen aufhält. Es ist geregelt, woher er die Werkzeuge und Zutaten bekommt, genauso wie, wohin er die Abfälle entsorgt und die benutzten Werkzeuge packt. – Dies geht über die Regelungen des Kochrezepts hinaus.

Desweiteren würden die Konstruktionsregeln im Restaurant sicherstellen, wie und mit welchen Zutaten der Teller garniert wird und wie der Kellner die Gerichte aus der Küche abholt und dem Gast am Tisch serviert.

Konstruktionsregeln stellen also nicht nur die Herstellung sondern auch die Einführung in die Produktion sicher.

Evolution erfordert Stabilität und Wandel

Ein Konzept – ganz im Sinne der Architektur-Aufgabe “Konzepte entwerfen” – muss klar sein. Klarheit schaffen wir, indem wir eindeutige Namen finden und dafür sorgen, dass alle Beteiligten verstehen, welche Zusicherungen wir damit verbinden. – Hätten wir bloß in der Gliederung Stereotyp, Konzept, Konstruktionsregel für das Mittlere ein anderes Wort gefunden, wäre natürlich der Effekt weg, dass Sie sich stets fragen müssten, was wir nun wirklich meinen und der Text wäre dadurch deutlich leichter zu konsumieren. Vielleicht machen Sie das einfach in Ihren Systemen richtig! :-)

Stereotypen sind das methodische Hilfsmittel, mit dem wir beliebige Konzepte miteinander und mit unserer Modellierung verbinden können. Stereotypen bieten uns somit eine stabile Basis für den Entwurf der geforderten Funktionalität.

Dank der Abstraktion von den Details können wir im Verlauf der Zeit die Qualität steigern, in dem wir unsere Konstruktionsregeln und Konzepte – in der ISO-42010-Definition Prinzipien genannt – inhaltlich anpassen und verfeinern.

Konstruktionsregeln – ist das nicht Entwicklung?

Ja, klar. Es überrascht doch wohl nicht, dass der Beitrag eines Softwarearchitekten in einem Entwicklungsprojekt tendenziell überflüssig ist, wenn keine Software geliefert wird.

Wenn wir ordentlich Software liefern wollen, müssen wir sicher stellen, dass sie über die nötige Funktionalität und Qualität verfügt. Dabei helfen Planung, Qualitätssicherung durch Prototypen, Tests, Iterationen uvm.

Wenn wir für die Qualität der Software als Architekten aber auch Verantwortung übernehmen wollen, sollten wir dafür sorgen, dass wir wissen, wie etwas realisiert ist. Das funktioniert am Besten, in dem sich alle an der Entwicklung Beteiligten auf Regeln einigen, die einfach befolgt werden können und für die einfach entschieden werden kann, ob sie eingehalten oder gebrochen wurden.

Klare Konstruktionsregeln setzen Energie für die konstruktive Diskussion frei. Man bemerkt schneller, dass ein Konzept fehlt und vergibt schon mal einen Namen. Sobald wir bemerken, dass ein Detail in einer Konstruktionsregel angepasst werden sollte, kann man dies leicht flächendeckend umsetzen und so die Integrität des Systems aufrecht erhalten.

Konzepte aller Abstraktionsstufen

Konzepte im Sinne der Begriffsdefinition Softwarearchitektur helfen uns dabei, Systeme zu entwerfen und umzusetzen, denen man die Intention der Erschaffer ansieht. Es hilft zu erkennen, dass eine gewisse Art von Datenrepräsentation nur für das Lesen gedacht ist, während die Implementierung für den wahlfreien Zugriff auf selbige Daten ganz anderen Regeln folgt.

Wir haben genügend damit zu tun, die inhaltlichen Fragen zu klären. Daher sollten wir so früh es geht, den Fokus auf die essenziellen Themen lenken und vermeiden, über Geschmacksrichtungen zu diskutieren. Hierbei hilft das Definieren und Abstimmen der umsetzungsnahen Konstruktionsregeln, der langfristig gültigen und dennoch recht konkreten Konzepte sowie der eher zeitlosen und tendenziell vollkommen technologieunabhängigen Stereotypen.

Was will man mehr?