Systemarchitektur mit der UML - Kleine Anpassungen, großer Nutzen

Tipps und Tricks mit UML

Stefan Queins, Anja Ranft

Auf dem Gebiet der Softwareentwicklung wird in den Bereichen Analyse und Architektur bereits überwiegend die UML (Unified Modelling Language) zur graphischen Darstellung eingesetzt. Nun liegt vor allem für Hersteller von kombinierten Hardware- und Softwaresystemen die Frage nahe, ob sich nicht die gleiche Notation zur Analyse und Architektur der Hardware-Elemente ihrer Systeme einsetzten lässt.

In diesem Artikel wird gezeigt, dass der Einsatz der UML in der Systementwicklung durchaus auch für die Modellierung von Hardware-Elementen möglich und auch sinnvoll ist, wenn man einige kleinere Anpassungen berücksichtigt.

Die UML (Unified Modelling Language) ist zwar heutzutage auf dem Gebiet der Softwareentwicklung die gängigste Modellierungssprache (vgl. [Rupp, C.; Queins, S.; Zengler B., u.a.: UML 2 glasklar, Hanser, 2007] und [Starke, G.: Effektive Software-Architekturen, Hanser, 2002]) doch wenn es um die Darstellung von hardwarelastigen Systemen geht, eher ein Ausnahmefall. Dabei wäre es doch nahe liegend, vor allem bei Systemen, die sowohl Software- als auch Hardware-Anteile besitzen, ein und dieselbe Notation zur Dokumentation von Ergebnissen aus den Analyse- und Designphasen zu verwenden. Zum einen ließen sich dadurch so manche „sprachlichen“ Probleme und Missverständnisse vermeiden und zum anderen könnte man so ein gemeinsames Werkzeug zur Erstellung und Verwaltung der Ergebnisse verwenden.

Betrachtet man nun die Entwicklungsprozesse im Bereich reiner Softwaresysteme und bei Systemen mit Software- und Hardwareanteilen, fällt schnell auf, dass diese sich in methodischer Hinsicht durchaus ähneln.

Die aus der Softwareentwicklung bekannten Workflow Analyse, Architektur und Design finden sich auch bei der Systementwicklung wieder, wenn auch in etwas anderer Form. In der Analysephase bestehen wenige Unterschiede zwischen der System- und der reinen Softwarebetrachtung. In beiden Fällen gilt es, die Anforderungen zu ermitteln und sie mithilfe von fachlichem Domainwissen bis zu der benötigten Detailtiefe zu beschreiben.

Unterschiede zwischen System- und Softwarearchitektur

Vergleichen wir die System- mit der Softwarearchitektur, ergeben sich auch hier einige Gemeinsamkeiten. Bei beiden Disziplinen wird eine Zerlegung des Ganzen in kleinere, überschaubare Teile durchgeführt. Für die so gefundenen Komponenten müssen deren Aufgaben und Zusammenspiel festgelegt werden. Hierbei werden sowohl statische als auch dynamische Aspekte betrachtet, die die Struktur des Systems und den Ablauf der geforderten Funktionalitäten definieren.

Betrachten wir die Tätigkeiten jedoch etwas genauer, stellen wir Unterschiede fest. Zunächst einmal haben wir in der Systemarchitektur keine Artefakte oder Prozesse, welche wir auf unsere Systemlandschaft verteilen müssen. Es werden also keine Prozess- oder Verteilungssichten benötigt, wie wir sie aus der reinen Softwarearchitektur kennen. Je nach Art der Systemzerlegung werden Sie aber möglicherweise eine Gruppierung der Systemkomponenten zu räumlichen Komponenten (Schränke, Einsteckkarte, etc.) benötigen.

Ein weiterer Unterschied zeigt sich bei der Art der Komponenten, aus denen ein System besteht. In der Softwarearchitektur werden natürlich nur reine Softwarekomponenten benötigt. In der Systemarchitektur ist nun noch zusätzlich eine Möglichkeit zur Unterscheidung von Software- und verschiedenen Hardware-Komponenten notwendig. Die Komponentenbildung unterliegt außerdem anderen Gesichtspunkten. So kann für die Zerlegung eines Systems ein wichtiges Kriterium die Beauftragung durch externe Lieferanten sein, was bei der Softwarearchitektur eher selten der Fall ist.

Diese Unterschiede lassen leicht erahnen, dass auch typische Architekturmuster aus der Softwarearchitektur wie z.B. das Schichtenmodell, Pipes & Filter etc. [siehe auch: Buschmann, F.: Pattern-orientierte Software-Architektur, Addison-Wesley GmbH, 1998], nicht ohne weiteres in die Systemarchitektur übertragen werden können.

Geschrieben von
Stefan Queins, Anja Ranft
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.