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.
|