Unified Modelling Language: UML für die Systemarchitektur Detail - Computerwelt

Computerwelt: Aktuelle IT-News Österreich


25.05.2011 Stefan Queins*

Unified Modelling Language: UML für die Systemarchitektur

Wer die Unified Modeling Language (UML) zur Entwicklung kompletter Systeme einschließlich Hardware verwendet, muss auf einige Anpassungen der Notation achten.

Die UML gilt in der Softwareentwicklung seit einiger Zeit als gängiges Notationsmittel, um die Ergebnisse der Analyse (Was soll meine Software tun?) und Architektur (Wie ist meine Software realisiert?) zu dokumentieren. Nun liegt die Frage nahe, ob und wie sich diese Notation auf einen geänderten Betrachtungsgegenstand, einem System, übertragen lässt, um Erfahrungen und Synergieeffekte, insbesondere zur Nachverfolgbarkeit von Anforderungen, auszunutzen.

Für die Analyse existiert kein wesentlicher Unterschied für die beiden Typen von Betrachtungsgegenständen und damit können die Notationen aus der Softwareanalyse relativ einfach für die Systemanalyse übernommen werden. In der Architektur wird das System ebenso wie die Software eine Zerlegung des Ganzen in kleinere, überschaubare Teile vorgenommen. Für die so gefundenen Komponenten müssen deren Aufgaben und Zusammenspiel festgelegt werden. Zu beachten sind dabei sowohl statische als auch dynamische Aspekte, die die Struktur des Systems und den Ablauf der geforderten Funktionen definieren. Bei genauerer Betrachtung finden sich schnell die ersten Unterschiede zwischen der System- und der Softwarearchitektur.

ARCHITEKTURUNTERSCHIEDE Zunächst einmal gibt es in der Systemarchitektur keine Artefakte oder Prozesse, die man auf eine Systemlandschaft verteilen muss. Es werden also keine Prozess- oder Verteilungssichten benötigt, wie man sie aus der reinen Softwarearchitektur kennt. Je nach Art der Systemzerlegung muss aber möglicherweise eine Gruppierung der Systemkomponenten zu räumlichen Komponenten (Schränke, Einsteckkarte etc.) vorgenommen werden.

Ein weiterer Unterschied zeigt sich in der Art der Komponenten, aus denen ein System besteht. In der Softwarearchitektur werden natürlich nur reine Softwarekomponenten benötigt. In der Systemarchitektur braucht man jedoch eine zusätzliche Möglichkeit, um Software3- und Hardwarekomponenten4 unterscheiden zu können. 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 man bei der Softwarearchitektur eher selten findet. Ebenso lässt sich leicht erahnen, dass typische Muster aus der Softwarearchitektur5 wie das Schichtenmodell oder Pipes and Filter nicht ohne weiteres in die Systemarchitektur übertragen werden können.

Da sich die Unterschiede im Entwurf einer System- und Softwarearchitektur hauptsächlich auf Tätigkeiten beschränken, sich die erzeugten Ergebnisse in ihrer Art aber ähneln, stellt die UML auch für Systeme eine adäquate Möglichkeit dar, einen Großteil dieser Ergebnisse zu dokumentieren. Es geht nicht darum, bewährte Notationen der Hardwareentwicklung wie zum Beispiel Konstruktionszeichnungen abzulösen. Vielmehr bietet die UML in einigen Bereichen eine gewinnbringende Zusatzoption. Dies ist der Fall, wenn es um die Kommunikation der an der Systementwicklung beteiligten Teams geht, um die Nachvollziehbarkeit der Entwicklungsentscheidungen oder um einen leichteren Übergang zur Softwareentwicklung.

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.

KOMPONENTEN IDENTIFIZIEREN Um Komponenten zu identifizieren, wird das System nach und nach vollständig zerlegt und ein hierarchischer Baum von Komponenten erzeugt. So kann das betrachtete System aus Subsystemen aufgebaut sein, die wiederum aus einzelnen Segmenten bestehen. Bis zu welcher Ebene Sie die Zerlegung treiben sollten, ist im Prinzip leicht zu beantworten: Es gilt, Komponenten zu finden, deren Umsetzung die Realisierung anderer Komponenten nicht mehr beeinflusst. Eine Ausnahme bilden hier natürlich die Schnittstellen der Komponenten. Als Randbedingung gilt hierbei natürlich, dass Sie für die Komponenten der untersten Ebene auch eine Abteilung oder externen Zulieferer finden, der diese Komponente für Sie entwickeln kann.

Ein Kriterium bei der Strukturierung des Systems auf den höheren Ebenen kann die räumliche Anordnung der Systemteile sein. Besteht das System zum Beispiel aus mehreren, voneinander getrennten Baugruppen, so können diese die erste Hierarchieebene in der Komponentenzerlegung bilden. Ferner kommen die aus der Softwarearchitektur bekannten Prinzipien für das Schneiden von Komponenten zum Tragen. Das sind zum Beispiel eine hohe Kohäsion, eine geringe Kopplung oder eine überschaubare Anzahl von Komponenten.

Zur Darstellung der Systemkomponenten verwendet man als Notationsmittel die UML-Komponenten. Diese können durch die so genannten Stereotypen zusätzlich klassifiziert werden, die Angabe erfolgt in spitzen Klammern. So lässt sich beispielsweise die Unterscheidung zwischen logischen, das heißt gruppierenden Komponenten beziehungsweise Hard- und Softwarekomponenten über die Stereotypen logical, HW und SW abbilden, oder als weitere mögliche Unterscheidung HW-Elektronik und HW-Mechanik.

Die Wahl der Stereotypen richtet sich häufig nach den Vorgaben an Ihr Projekt. So wird in V-Modell-basierten Projekten der Stereotyp logical häufig durch die Begriffe Subsystem, Segement und Subsegement weiter differenziert.

Diesen Artikel

Bewertung:

Übermittlung Ihrer Stimme...
Noch nicht bewertet. Seien Sie der Erste, der diesen Artikel bewertet!
Klicken Sie auf den Bewertungsbalken, um diesen Artikel zu bewerten.
  Sponsored Links:

IT-News täglich per Newsletter

E-Mail:
Weitere CW-Newsletter

CW Premium Zugang

Whitepaper und Printausgabe lesen.  

kostenlos registrieren

Aktuelle Praxisreports

(c) FotoliaHunderte Berichte über IKT Projekte aus Österreich. Suchen Sie nach Unternehmen oder Lösungen.

Zum Thema

  • SNP AUSTRIA GmbH

    SNP AUSTRIA GmbH Qualitätssicherung, Kaufmännische Software (ERP), Tools, Programmiersprachen, Datenkonvertierung, Übernahme von Softwareprojekten, Systempflege- und Wartung,... mehr
  • Matrix42 AG

    Matrix42 AG Mobile Lösungen und Applikationen, Zugangs- und Zutrittskontrolle, Security Audits, Übernahme von Softwareprojekten, Programmierung, IT-Asset- und Lizenzmanagement, IKT-Consulting,... mehr
  • EASY SOFTWARE GmbH

    EASY SOFTWARE GmbH Schrifterkennung, Mobile Lösungen und Applikationen, Management Informationssysteme (MIS), Dokumentenmanagement und ECM, Business Intelligence und Knowledge Management mehr
  • free-com solutions gmbh

    free-com solutions gmbh Werbewirtschaft, Wasser- und Energieversorgung, Vereine und Verbände, Umweltschutz, Touristik, Personenverkehr, Öffentliche Verwaltung,... mehr

Hosted by:    Security Monitoring by: