Notation Architekturen im Wandel der Zeit

1 Motivation

Zwei entscheidende Faktoren bei der Entwicklung eines neuen Systems sind die Kosten und die zur Verfügung stehende Zeit. Für beide ist vor dem eigentlichen Projekt eine Abschätzung notwendig, welche auf wenig detaillierten Informationen beruhen. Die Wissenslücken werden meist mit Erfahrungswerten gefüllt. Unter diesen Voraussetzungen wird ein Architekturentwurf erstellt, dessen Güte entscheidend für den Erfolg des Projektes ist. Im Verlauf eines Projektes vervollständigt sich das Bild des zu erstellenden Systems, das Wissen über das System wird detaillierter und es ergeben sich immer wieder neue und angepasste Randbedingungen. Die Architektur muss gegenüber den neuen Randbedingungen validiert und gegebenenfalls angepasst werden. Dazu bedarf es einer guten Dokumentation und der Gewissheit, dass alle Bedingungen bei der Validierung berücksichtigt werden.

Im Projektalltag ist die durchgängige Verwendung einer domänenspezifischen einheitlichen Dokumentationssprache, die einen positiven Einfluss auf das Verständnis und die Verständigung aller Projektbeteiligten hat, selten bis gar nicht vorzufinden. Auch die Unterstützung des Architekten bei der Wahl einer validen Architektur, vor allem unter der Voraussetzung sich häufig ändernden Bedingungen, lässt zu wünschen übrig. Hier wird oftmals die Methode des scharfen Hinsehens für die Validierung der Architektur gegenüber den Anforderungen eingesetzt. Dieses Vorgehen liefert weder belastbare Aussagen noch ist sie besonders effizient beim Erkennen der Auswirkungen von veränderten Anforderungen auf die Architektur. Ein getrübter Blick birgt zudem die Gefahr des Übersehens von wichtigen Entscheidungsfaktoren.

Damit Sie in Ihren Projekten nicht im trüben Fischen müssen, haben sich die SOPHISTen mit diesem Problem beschäftigt. Das Ergebnis ist ein Ansatz, der eine durchgängige Verwendung der UML als Dokumentationssprache ermöglicht und dem Architekten ein Werkzeug an die Hand gibt, welches die Wahl und Validierung der Architektur mit geringem Aufwand ermöglicht.

2 Idee

Die Aufgabe des Architekten ist das Erstellen einer Architektur, welche allen Kundenanforderungen genügt. Um dies sicherzustellen, muss jede Kundenanforderung für eine ausgewählte Architektur validiert werden. Wie der Ansatz den Architekten bei dieser Aufgabe  unterstützt, demonstrieren wir an einem kleinen fiktiven Beispiel. Die Anforderung S-012 an das System lautet: „Das System muss jederzeit den Datenaustausch zwischen Software-Komponenten in maximal 1 Sekunde ermöglichen.“. Der Architekt möchte nun wissen, ob seine getroffene Hardwareauswahl und Zuordnung der Software-Komponenten auf diese der Anforderung S-012 gerecht wird.


Abbildung 1: Validierung einer Architektur

Klicken Sie hier um das Bild zu vergrößern

Abbildung 1 zeigt den Ablauf der Architekturvalidierung mit Hilfe eines UML-Aktivitätsdiagrammes. Der Entscheidungsfaktor im obigen Beispiel ist die Performanz. Ein Validierungsziel ist ein architekturspezifischer Aspekt, dem eine Menge von Anforderungen, sowohl funktional als auch nicht-funktional, zugeordnet sind. Im Beispiel sind das Validierungsziel die verwendeten Kommunikationsmedien; ihm zugeordnet ist die Anforderung S-012. Wie das Validierungsmodell erstellt wird, ist detailliert in Abbildung 2 zu sehen.


Abbildung 2: Erarbeitung der Validierungsmodelle

Klicken Sie hier um das Bild zu vergrößern

Für das Validierungsziel wird ein Validierungsverfahren benötigt. Wenn die Datenbandbreite jedes Kommunikationsmediums größer oder gleich der maximalen Datenaustauschmenge zwischen den Software-Komponenten, die dieses Kommunikationsmedium verwenden, ist, erfüllt die Architektur die Anforderung S-012. Für das Validierungsverfahren werden also folgende Informationen benöti

  • Schnittstellen der Software-Komponenten,
  • Kommunikationsmedien zwischen den Verarbeitungseinheiten,
  • Datenaustauschmenge zwischen den Software-Komponenten (in GBit/s)
    und
  • Datenbandbreite der verwendeten Kommunikationsmedien (in GBit/s).

Die ersten beiden Informationen hat der Architekt bereits im Entwicklungsmodell modelliert. Die beiden letzten Informationen müssen vom Architekten ergänzt werden. Da diese nicht für die weitere Systementwicklung benötigt werden, werden entwicklungs- und validierungsspezifischen Informationen voneinander getrennt modelliert. Mit Hilfe eines UML-Profils mit zwei Stereotypen (validierungsspezifische Notation) können die fehlenden Informationen UML-konform ergänzt werden. Das Validierungsmodell wird aus den validierungsrelevanten Informationen im Entwicklungsmodell erstellt (unvollständiges Validierungsmodell) und mit Hilfe des UML-Profils um die noch fehlenden Informationen ergänzt. Damit endet die Aktivität „Validierungsmodelle erarbeiten“, da im Beispiel nur ein Validierungsziel betrachtet wird.

Der nächste Schritt (siehe Abbildung 1) ist die Architekturvalidierung selbst. Dabei werden die Ergebnisse der Validierungsverfahren mit den zugeordneten Anforderungen verglichen. Falls die Validierung fehlschlägt, ändert der Architekt die betroffenen Validierungsmodelle und führt die Validierung erneut durch. Nach einem positiven Ergebnis werden die für das Entwicklungsmodell relevanten Änderungen aus den Validierungsmodellen übernommen und auf mögliche Anforderungsänderungen gewartet. Die Aktivität „Architektur validieren“ endet mit der Festlegung auf eine valide Architektur.

3 Fazit

Durch die Trennung der für die Validierung relevanten Informationen von denen im Entwicklungsmodell, wird das Entwicklungsmodell frei von validierungsspezifischen Informationen gehalten. Gleichzeitig entsteht eine vollständig in UML gehaltene Dokumentation der Lösungsmöglichkeit für jedes Validierungsziel. Bei auftretenden Veränderungen der Anforderungen können alle dokumentierten Validierungsziele, welche in ihrer Gesamtheit die Designentscheidung bilden, gegenüber den veränderten Anforderungen validiert werden. Der Architekt wird nicht nur bei der Wahl der Architektur, sondern auch bei der Impactanalyse unterstützt und kann sich dabei auf belastbare Aussagen berufen. Der erforderliche Mehraufwand wird durch die Charakteristik des Ansatzes, z.B. die Verwendung einer einheitlichen Dokumentationssprache, auf ein Minimum reduziert. Mit diesem Ansatz kann der Architekt dem Wandel im Projekt gelassen entgegensehen.

Falls Sie noch Fragen oder Anregungen zu diesem Thema haben, würde ich mich über eine Mail an heureka@sophist.de freuen.

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *


7 × fünf =

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>