Konzept: Systemarchitektur
Eine Systemarchitektur ist eine Darstellung eines Systems, in der es eine Zuordnung der Funktionalität zu Hardware- und Softwarekomponenten, eine Zuordnung der Softwarearchitektur zur Hardwarearchitektur und Benutzerinteraktionen mit diesen Komponenten gibt.
Beziehungen
Hauptbeschreibung

Einführung

Der Begriff Architektur wird heutzutage häufig nicht mehr in seiner traditionellen Bedeutung von Gebäude verwendet, und es gibt viele Definitionen von "Architektur" (im Kontext von Systemen) und "Systemarchitektur". Beispiel:

"Systems architecture: the fundamental and unifying system structure defined in terms of system elements, interfaces, processes, constraints, and behaviors." 
[Referenzdefinition der INCOSE Systems Architecture Working Group von INCOSE 1996 in Boston, MA, 8. Jul 1996]

"System architecture comprises the major physical properties, style, structure, interactions, and purpose of a system."
[Process for System Architecture and Requirements Engineering, Derek Hatley, Peter Hruschka, Imtiaz Pirbhai, Dorset House Publishing 2000]

"Architecture: the concepts and rules that define the structure, semantic behavior, and relationships among the parts of a system; a plan of something to be constructed. It includes the elements that comprise the thing, the relationships among those elements, the constraints that affect those relationships, a focus on the parts of the thing, and a focus on the thing as a whole."
[Architecting with RM-ODP, Janis Putman, Prentice Hall PTR 2001. Diese Veröffentlichung verweist auf ISO/IEC 10746-2: Information Technology - Open Distributed Processing - Reference Model: Foundations als Quelle]

"Architecture: the structure of components in a program/system, their interrelationships, and the principles and guidelines governing their design and evolution over time."
[DoD 5000.59-P, "Modeling and Simulation Master Plan," October 1995]

An architecture is "the structure of components, their relationships, and the principles and guidelines governing their design and evolution over time."
[IEEE STD 610.12, geringfügig erweitert vom Integrated Architectures Panel (IAP) der C4ISR Integration Task Force (ITF) in DoD Architecture Framework, Version 1.0]

Es werden unterschiedliche Wörter und Konstruktionen verwendet, und nicht alle Definitionen decken exakt dieselben Aspekte ab, aber es gibt weitreichende Überlappungen. Diese Definitionen zeigen, dass es bei der Systemarchitektur um Folgendes geht:

  • die Struktur des Systems mit Elementen, Komponenten und Teilen,
  • die Beziehungen zwischen diesen Elementen,
  • die Vorgaben, die sich auf die Elemente und ihre Beziehungen auswirken,
  • das Verhalten, das das System an den Tag legt, und die Interaktionen, die zwischen den Elementen stattfinden, um dieses Verhalten zu erbringen,
  • die Prinzipien, Regeln und die Begründung, die für das System in seiner jetzigen Form verantwortlich sind (und seine Weiterentwicklung steuern),
  • die physischen und logischen Merkmale und Eigenschaften des Systems,
  • den Zweck des Systems.

Die vollständige Vermittlung all dieser Aspekte setzt ein reichhaltiges und möglicherweise komplexes Informationsset voraus, aber man muss daran denken, dass nicht alle Stakeholder alle Aspekte gleichzeitig sehen und verstehen müssen. Durch die Idee der Blickpunkte können diese verschiedenen Problemstellungen getrennt werden. Auf diese Weise kann einer bestimmten Kategorie von Stakeholdern genau und nur das präsentiert werden, was sie für eine effektive Teilnahme am Projekt benötigen. Aus der Perspektive eines bestimmten Blickpunkts können Sie das System auch in verschiedenen "Auflösungen" anzeigen. Eine geringe Auflösung entspricht einem hohen Abstraktionsgrad und eine hohe Auflösung einer konkreten Spezifikation (von Teilen usw.) für die Implementierung.

Blickpunkte

Definition: "...a form of abstraction achieved using a selected set of architectural concepts and structuring rules, in order to focus on particular concerns within a system" [ISO/IEC 10746-2: Information Technology - Open Distributed Processing - Reference Model: Foundations]. Die folgende Tabelle listet die Blickpunkte auf, die ausgewählt werden, um die verschiedenen Problemstellungen zu erfassen. Diese Blickpunkte sind an denen ausgerichtet, die in ISO/IEC 10746-1: Information technology - Open Distributed Processing - Reference Model: Overview angegeben sind.

Blickpunkt Problemstellung Auswirkung
Mitarbeiter Rollen und Zuständigkeiten der Organisation und der Systemmitarbeiter (und den Richtlinien, die sich auf diese auswirken). Mitarbeiteraktivitäten, Interkation zwischen Benutzer und System. Personenbezogene Leistungsspezifikation und personenbezogene Faktoren.
Informationen Die Arten der vom System behandelten Informationen und die Vorgaben zur Verwendung und Interpretation dieser Informationen. Informationsintegrität, Kapazitätseinschränkungen.
Zugänglichkeit und Aktualität der Informationen.
Logisch Die Zerlegung des Systems in eine Reihe von Subsystemen, die an Schnittstellen interagieren und kollaborieren, um die Systemservices bereitzustellen. System erbringt das gewünschte Verhalten.
System ist erweiterbar, anpassbar und verwaltbar.
Assets sind wiederverwendbar.
Verteilung/Physisch Die für die Unterstützung der Systemfunktionalität und -verteilung erforderliche Infrastruktur. Angemessenheit der physischen Merkmale des Systems für die Funktionalität und die nicht funktionalen Anforderungen.
Prozess Parallelität, Skalierbarkeit, Leistung, Durchsatz, Zuverlässigkeit. Angemessenheit von Systemreaktion, -durchsatz und -fehlertoleranz.

Allgemeine Systemstandpunkte.

Dies sind einige der üblichen Blickpunkte für softwareintensive Systeme. Viele Systemarchitekturen erfordern zusätzliche, domänenspezifische Blickpunkte. Beispiele hierfür sind risikobezogene, sicherheitsbezogene und mechanische Blickpunkte. Blickpunkte stellen unterschiedliche Problembereiche dar, die in der Systemarchitektur und im Design berücksichtigt werden müssen. Wenn es System-Stakeholder oder -experten gibt, deren Anliegen wichtig für die Gesamtarchitektur sind, besteht wahrscheinlich ein Bedarf an Arbeitsergebnissen für diese Blickpunkte, um die Designentscheidungen zu erfassen.  

Es ist wichtig, ein Systemarchitekturteam mit Mitarbeitern auszustatten, die fähig sind, sich um die verschiedenen Blickpunkte zu kümmern. Das Team kann sich aus Geschäftsanalytikern und Benutzern zusammensetzen, die primär für den Mitarbeiterstandpunkt zuständig sind, Softwarearchitekten, die für den logischen Blickpunkt verantwortlich sind, Entwickler, die sich mit dem physischen Blickpunkt beschäftigen, und Experten für domänenspezifische Blickpunkte.

Abstraktionsebenen

Zusätzlich zu Blickpunkten benötigt eine Systemarchitektur Abstraktionsebenen. Während der Entwicklung der Architektur wandelt sie sich von einer generellen, abstrakten Spezifikation zu einer spezifischeren, detaillierten Spezifikation. RUP identifiziert vier Architekturebenen, die in der folgenden Tabelle beschrieben sind.

Modellebene Beschreibt
Kontext Das System und seine Akteure.
Analyse Erste Partitionierung des Systems zur Etablierung des konzeptionellen Ansatzes.
Design Realisierung des Analysemodells in Hardware, Software und Mitarbeiter.
Implementierung Realisierung des Designmodells in bestimmten Konfigurationen.

Architekturstufen in RUP

Das Design durchläuft diese Stufen vom abstrakten bis hin zum physischen Modell. Das Kontextmodell erfasst alle externen Entitäten (Akteure), die mit dem System interagieren. Bei diesen Akteuren kann Akteure handeln, die nicht aus dem Unternehmen stammen, das das System einsetzt, oder um interne Akteure des Unternehmens. In beiden Fällen kann es sich um Mitarbeiter oder andere Systeme handeln. Auf Analyseebene spiegeln die Partitionen nicht die Auswahl von Hardware, Software und Personen wider, sondern die Designansätze in Bezug auf die Aufteilung, was das System tun muss und wie die Arbeit verteilt werden muss. Auf Designebene werden die Entscheidungen in Bezug auf die erforderlichen Hardware- und Softwarekomponenten und Mitarbeiterrollen getroffen. Auf Implementierungsebene werden bestimmte Hardware- und Softwaretechnologien für die Implementierung des Designs getroffen. Beispielsweise kann auf Designebene ein Datenserver angegeben werden. Auf Implementierungsebene wird entschieden, dass eine bestimmte Plattform für die Ausführung einer bestimmten Datenbankanwendung verwendet wird.

Modelle und Diagramme

Ein Modell ist eine Darstellung eines Systems, die sich in der Regel einen bestimmten Problembereich bezieht. Ein System wird gewöhnlich durch eine Reihe von Modellen dargestellt, weil es mehrere Aspekte für die Entwicklung oder Verwendung des Systems gibt. Jedes Modell kann mit verschiedenen Abstraktionsebenen erstellt werden. Ein Modell kann eher allgemein sein und Details verbergen oder kapseln, oder eher spezifisch und mehr Details und explizite Designentscheidungen offen legen.

Ein Blickpunkt ist, wie der Name schon sagt, eine theoretische "Position", aus der verschiedene Aspekte oder Probleme des Systems unter Anwendung von Konzepten und Regeln als konzeptionelle Filter sichtbar gemacht werden. Normalerweise reicht es (für das Verständnis) nicht aus, das echte System zu untersuchen. Es müssen Modelle erstellt werden, um die Probleme darzustellen und zu beschreiben.

Sichten sind Projektionen von Modellen, die die Entitäten zeigen, die von einem bestimmten Blickpunkt aus relevant sind. Diese Projektionen werden gewöhnlich durch Diagramme veranschaulicht.

Die Schnittmenge von Blickpunkt und Abstraktion bzw. Spezifik auf Modellebene enthält (oder zumindest identifiziert) Sichten auf eine oder mehrere Modelle, die für diesen Blickpunkt bzw. diese Problemstellung auf dieser Abstraktionsebene von Bedeutung sind.

Die Systemarchitektur wird anschließend in verschiedenen Modellen (und Diagramme, die diese visualisieren) erfasst, die die Architektur von verschiedenen Blickpunkten und Ebenen aus beschreiben. Wie in der folgenden Tabelle mit Modell-Frameworks beschrieben, gibt es nicht für jede Kombination von Blickpunkt und Ebene ein Modell bzw. Diagramm. Auf der Implementierungsebene erfasst ein einzelnes Modell die Realisierung der Hardware- und Softwarekomponenten für jede Systemkonfiguration.

Modellebene Blickpunkte
Mitarbeiter Logisch Informationen Verteilung/Physisch Prozess
Kontext UML-Organisationssicht Systemkontextdiagramm Unternehmensdatensicht Unternehmenslokalitätssicht Geschäftsprozesssicht
Analyse Generalisierte Systemmitarbeitersicht Subsystemsicht Systemdatensicht Systemlokalitätssicht Systemprozesssicht
Design Systemmitarbeitersicht Subsystemklassensichten

Softwarekomponentensichten

Systemdatenschema Deskriptorknotensicht Detaillierte Prozesssicht
Implementierung Spezifikationen und Anweisungen für Mitarbeiterrollen Konfigurationen: Deployment-Diagramme mit Software- und Hardwaresystemkomponenten.

Viele der in der Tabelle angegebenen Sichten werden aus UML-Standardmodellen abgeleitet. Auf der Analyseebene des logischen Blickpunkts wird das System in Subsysteme zerlegt, die kollaborieren, um die Benutzeranforderungen zu erfüllen. Für die Subsysteme wird dieselbe Semantik verwendet wie im UML-Standard. Diese Subsysteme wiederum werden in Subsysteme oder (letztendlich) Klassen zerlegt. Die Designebene des logischen Blickpunkts ist die Sicht des detaillierten Klassenmodells. Das Prozessmodell ist ebenfalls ein Standard-UML-Klassenmodell, das sich auf die aktiven Klassen im System konzentriert. Die domänenspezifischen Blickpunkte müssen außerdem Arbeitsergebnissichten für eine oder mehrere der Ebenen haben. Die Projektarbeitsergebnisse in diesem Framework müssen Teil des Entwicklungsfalls des Projekts sein.