Start mit Use-Case-Analyse

Der Ausgangspunkt für ein auf der UML 2.0 basierendes Modell der Systemarchitektur ist die vollständige Systemanalyse, aus der die Anforderungen an das System bis zu einer gewissen Tiefe hervorgehen. Eine Technik hierfür ist die Use-Case-Analyse, mit der die funktionalen Anforderungen an ein System ermittelt und dokumentiert werden können. Dieser Ansatz schließt mit ein, dass die Use Cases (typische Interaktionen des Systems mit seiner Umwelt) durch Aktivitätsdiagramme oder, vor allem bei Realtime-Embedded-Systemen, durch Zustandsautomaten detailliert werden. Darüber hinaus bilden die nichtfunktionalen Anforderungen wie Zuverlässigkeit, Sicherheit oder die Einbettung des Systems in seine Umwelt eine wichtige Eingabe in die Systemarchitektur. Auch diese Aspekte werden in der Systemanalyse erhoben und dokumentiert.

In der Praxis wird man kaum eine vollständige Systemanalyse vor den ersten Architekturtätigkeiten erreichen. Normalerweise ergibt sich ein verzahnter Prozess zwischen einer groben Analyse, den ersten Architekturfestlegungen sowie einer Verfeinerung der Analyseergebnisse.

Die Strukturierung eines Systems ist nur eine von mehreren Tätigkeiten, die ein Architekt vorzunehmen hat. Eine zweite ist die Beschreibung der Komponenten innerhalb dieser Struktur, insbesondere die Beschreibung der Aufgaben der einzelnen Komponenten. Die Definition der Schnittstellen zwischen den Komponenten bildet den dritten wichtigen Aspekt in der Architektur. Das Ziel der Systemarchitektur ist es somit, sowohl für die Software- als auch für die Hardwareentwicklung, solche Komponenten zu beschreiben, die möglichst losgelöst von den anderen Komponenten realisiert werden können.

Alle drei Tätigkeiten sind eng miteinander verbunden. Sie beeinflussen sich gegenseitig und liefern Input für die jeweils anderen Tätigkeiten. Aus diesem Grund werden die Tätigkeiten in der Systemarchitektur nicht wasserfallartig ausgeführt, sondern iterativ und eng verzahnt.