Architektur Zentrierung

Was ist Architektur

Die Architektur spielt im Entwicklungsprozess eine ähnliche Rolle wie beim Bau eines Gebäudes. Bevor mit dem Bau eines Gebäudes begonnen wird, erstellt der Architekt einen "Plan", welcher ein konsistentes Gesamtbild des zu bauenden Gebäudes aus unterschiedlichen Blickwinkeln (Bsp: Strom, Heizung etc) enthält. Ausgehend von den Nutzungsanforderungen erstellt er in Absprache mit dem Auftraggeber erst einmal eine "Grobarchitektur", welche die Raumaufteilung enthält. Diese Grobarchitektur übergibt er dann z.B. dem Statiker, dem Sanitär-Spezialisten, dem Elektro-Installateur sowie einem Bauingenieur. Diese Spezialisten erzeugen spezifische Pläne für ihre Bedürfnisse und besprechen diese mit dem Architekten. Der Architekt löst allfällige Konflikte (z.B. zu wenig Platz für Stromkabel und Wasserkabel). Schliesslich baut der Architekt die wichtigsten Ergebnisse wieder in einen Gesamtplan bzw. eben die Architektur ein.

Die Architektur vermittelt ein Gesamtbild des gesamten Gebäudes mit allen wichtigen Aspekten. Viele Details werden also zwecks Übersichtlichkeit und Verständlichkeit in der Architektur weggelassen. Mit der Architektur stellt der Architekt sicher, dass vor dem eigentlichen Bau ein konsistentes Bild des zu bauenden Gebäudes vorliegt. Für die Spezialisten ist die Architektur eine Art "Masterplan", welches die Richtlinien für weitere Detailpläne vorgibt.

Eine gute Erklärung für Architektur liefert auch die Parabel "die Blinden und der Elefant": 3 Blinde begegnen einem Elefanten, "erfahren" diesen aber unterschiedlich, nämlich als grosse Schlange (Rüssel), als Seil (Schwanz) oder als kleinen Baum (Bein).

Was ist die Systemarchitektur

Die Systemarchitektur entspricht sinngemäss der Architektur eines Gebäudes. Sie zeigt das zu bauende Gesamtsystem aus allen für das zu bauende System relevanten (statischen und dynamischen) Aspekten.

AdeNet/VM definiert Systemarchitektur wie folgt:

Komprimierter Masterbauplan ( „Koordinationsplan“) des Gesamtsystems, welcher das System aus unterschiedlichen Sichten (Use-Cases, Daten, Verhalten) beschreibt. Dieses Dokument beschreibt auch die wesentlichen Schlüsselmechanismen, die wichtigsten Risiken sowie Abgrenzungen zu vorhandenen Systemen. Alle Projektbeteiligten sollten in der Systemarchitektur sehen, wie und wo ihr Beitrag oder ihre Sicht (z.B. Installation bei einem Internetprovider oder Integration in eine bestehende Umgebung) hereinpasst. Die Systemarchitektur beleuchtet also alle technisch/konzeptionellen Aspekte, welche regulative Wirkung haben und auf die Kosten, die Dauer oder die Anforderungen einen Einfluss haben können bzw. welche zur Klärung potentieller Missverständnisse dienen können. Das Dokument Systemarchitektur wird im Rahmen der Systemanalyse erstellt und bis zum Abschluss des Systemdesigns fortlaufend nachgeführt.

● Funktionale Sicht: Übersicht über das Prozess- und Use-Case Modell. Architektonisch relevante Prozesse und/oder Use-Cases können hier im Detail aufgeführt werden. Deren Beschreibung wird allerdings hier nicht wiederholt.

● Logische Sicht: Die wichtigsten Analyse bzw. Design-Klassen, welche für die Realisierung der architektonisch relevanten Use-Cases notwendig sind bzw. deren Use-Case Realisierungen. Organisation der Analyse/Design-Klassen in Pakete und allenfalls Layers.

● Datenmodell-Sicht: Physisches Datenmodell ("Tabellen"), insbesondere deren Zugehörigkeit zu einzelnen Subsystemen.

● Deployment-Sicht: Welche Rechnern mit welcher Konfiguration werden benötigt, wie läuft die Kommunikation (Internet, Intranet, Protokolle etc), auf welchen Rechnern laufen welche Teile des Systems.

● Zusatzanforderungen: Informationssicherheit- und Datenschutz, weitere nichtfunktionalen Anforderungen.

Zusammenhang zwischen Architektur und Anforderungen

Die nachstehende Abbildung zeigt den Stellenwert der Architektur auf. Sie leitet sich zwar primär von den Anforderungen ab, kann aber durch Berücksichtigung von Rahmenbedingungen sowie Erfahrungen die Anforderungen selber beeinflussen. So entstehen "machbare" Anforderungen und nicht "Traumsysteme"….

Kritische Use-Cases als Grundlage von Iterationen sowie der Systemarchitektur

Kritische Use-Cases sind solche, die nötig sind, damit die Systemarchitektur zu grossen Teilen soweit stabil ist, dass im Anschluss daran auf "breiter Front" (und ohne grosses Risiko) mit der Realisierung begonnen werden kann. Die nachstehende Abbildung zeigt die Kriterien für kritische Use-Cases" auf:

Bereits in der Konzeptphase (innerhalb der Analyse-Disziplin) werden Use-Cases mit Hilfe dieses Schemas priorisiert. Diese Priorisierung verfolgt einen doppelten Zweck:

● Die kritischen Use-Cases werden in der Konzeptphase früh detailliert und allenfalls in einer ersten "Rohform" implementiert.

● Die architektonisch relevanten Use-Cases bilden die Basis zur Erstellung der Systemarchitektur.

Hinweis: Der in RUP verwendete Begriff „architektonisch relevant“ wurde hier in Annäherung an den HERMES-Begriff „kritische Teilsysteme“ durch den Begriff „kritisch“ ersetzt.