Architekturmodellierung  innerhalb der  

Unified  Modeling Language  I

Inhaltsverzeichnis   

INHALTSVERZEICHNIS   I

ABBILDUNGSVERZEICHNIS   III

1  EINFÜHRUNG  1

2  ARCHITEKTURMODELLIERUNG  2

2.1  DIE FÜNF SICHTWEISEN.  2

2.2  MODELLE UND SYSTEME.  3

3  KOMPONENTEN.  4

3.1  AUFBAU VON KOMPONENTEN  4

3.2  FUNKTION UND ARTEN VON KOMPONENTEN  7

3.3  GEBRÄUCHLICHE MODELLIERUNGSTECHNIKEN VON KOMPONENTEN.  8

4  KOMPONENTENDIAGRAMM  10

4.1  AUFGABE UND AUFBAU VON KOMPONENTENDIAGRAMMEN.  10

4.2  ARTEN DER MODELLIERUNG VON KOMPONENTENDIAGRAMMEN  10

4.2.1  Modellieren von Sourcecode.  10

4.2.2  Modellieren von ausführbaren Versionen.  12

4.2.3  Modellieren einer physischen Datenbank  14

4.2.4  Modellieren adaptiver Systeme  15

4.3  HINWEISE UND TIPPS FÜR DIE MODELLIERUNG VON KOMPONENTENDIAGRAMMEN.  16

5  KNOTEN  17

5.1  AUFBAU VON KNOTEN  17

5.2  GEBRÄUCHLICHE MODELLIERUNGSTECHNIKEN VON KNOTEN.  19

5.2.1  Das Modellieren von Prozessoren und Geräten  19

5.2.2  Das Modellieren der Verteilung von Komponenten.  20

6  EINSATZDIAGRAMME  22

6.1  AUFGABE UND AUFBAU VON EINSATZDIAGRAMMEN.  22

6.2  ARTEN DER MODELLIERUNG VON EINSATZDIAGRAMMEN  22

6.2.1  Modellierung eines eingebetteten Systems.  22

6.2.2  Modellierung von Client/Server-Systemen.  24

6.2.3  Modellieren von vollständig verteilten Systemen.  26

6.3  HINWEISE UND TIPPS FÜR DIE ERSTELLUNG VON EINSATZDIAGRAMMEN.  27

7  EIGENES DIAGRAMMBEISPIEL  28

7.1  BESCHREIBUNG DES BEISPIELSYSTEMS  28

Architekturmodellierung  innerhalb der  

Unified  Modeling Language  II

7.2  KOMPONENTENDIAGRAMM  28

7.3  EINSATZDIAGRAMM  29

LITERATURVERZEICHNIS   30

Architekturmodellierung  innerhalb der  

Unified  Modeling Language  

Abbildungsverzeichnis   

Abbildung  1: Modellieren einer Systemarchitektur.  

Abbildung  2: Grafische Darstellung einer Komponente.  

Abbildung  3: Komponenten und Schnittstellen.  

Abbildung  4: Modellierungsbeispiel für Komponenten.  

Abbildung  5: Modellierung von Sourcecode  

Abbildung  6: Modellierung einer ausführbaren Version  

Abbildung  7: Modellierung einer physischen Datenbank.  

Abbildung  8: Modellierung adaptiver Systeme  

Abbildung  9: Grafische Darstellung eines Knotens.  

Abbildung  10: Varianten der grafische Darstellung von Knoten mit Komponenten  

Abbildung  11:Grafische Darstellung von Verbindungen zwischen Knoten  

Abbildung  12: Stereotypisierte Darstellung von Prozessoren und Geräten  

Abbildung  13: Modellierung der Verteilung von Komponenten  

Abbildung  14: Die Modellierung eines eingebetteten Systems  

Abbildung  15: Modellierung eines Client/Server-Systems  

Abbildung  16: Modellierung eines vollständig verteilten Systems.  

Abbildung  17: Beispiel WebCam Komponentendiagramm  

Abbildung  18: Beispiel WebCam Einsatzdiagramm.  

Tabellenverzeichnis   

Tabelle 1:  Merkmale von Klassen und Komponenten  

Architekturmodellierung innerhalb der

Unified Modeling Language 1

1 Einführung

Die Unified Modeling Language (UML) stellt eine Standardsprache für die Modellierung von Softwareentwürfen dar. Diese Sprache wurde von Jim Rumbaugh, Ivar Jacobsen und Grady Booch im Jahre 1997 in der ersten Version 1.1 veröffentlicht. Mittlerweile existiert die Version 1.4, welche mit Sicherheit nicht die letzte Version sein wird. Die UML kann heute bereits als ein Industriestandard angesehen werden, da heute nahezu alle Entwicklungswerkzeuge und Autoren diese Sprache unterstützen. ¹ Die zentralen Aufgaben der UML sind die Visualisierung, Spezifizierung, Konstruktion und Dokumentation von Softwaresystemen. In diesem Zusammenhang meint Spezifizierung die unzweideutige und vollständige Erstellung von Modellen und die Konstruktion eine direkte Kopplungsmöglichkeit an Programmiersprachen wie C++ oder Java, das heißt eine direkte Abbildbarkeit der UML Modelle auf die Programmiersprachen wird ermöglicht. Dabei ist die UML allerdings nur als ein Teil einer Methode zur Softwareentwicklung zu verstehen. Die UML stellt eine Sprache dar, die prozessunabhängig ist und dementsprechend in einem Entwicklungsprozess eingebunden sein sollte. 2

Die UML kann im Rahmen der möglichen Modellierungsarten (Strukturmodellierung, Verhaltenmodellierung und Architekturmodellierung) sowohl die konzeptionellen als auch physischen Aspekte eines Systems abbilden. Die Modellierung von softwareintensiven Systemen fördert dabei das Verständnis des einzelnen Entwicklers, indem er sich vor der Implementierung Gedanken zur Umsetzung des Problems macht. Weiterhin bildet hat UML eine Art kommunikative Brückenfunktion zwischen den unterschiedlichen Anspruchsgruppen in einem Softwareentwicklungsprojekt. Unter anderem nehmen folgende Personengruppen an einem solchen Prozess teil: Anwender, Analytiker, Entwickler, Systemintegratoren, Tester, technische Autoren,

Projektmanager etc. Diese Personengruppen sprechen zum Teil „unterschiedliche Fachsprachen“. Die UML bietet die Möglichkeit, durch grafische Visualisierung aus den verschiedensten Sichten eine allgemein verständliche Übersetzung spezifischer Aspekte eines Softwaresystems zu erstellen. 3

Die vorliegende Arbeit wird sich mit der Übersetzungsfunktion der UML zwischen Softwareentwicklern und Hardware-Ingenieuren befassen, das heißt die Architekturmodellierung wird einer näheren Betrachtung unterzogen.

¹ Vgl. Seemann/Gudenberg, Softwareentwurf mit UML, 2000, S. 2 auch Oesterreich, Die UML

Kurzreferenz für die Praxis, 2001, S. VIII.

² Vgl. Booch/Rumbaugh/Jacobsen, Das UML-Benutzerhandbuch, 1999, S. 13 f.

³ Vgl. Booch/Rumbaugh/Jacobsen, Das UML-Benutzerhandbuch, 1999, S. 14-16 und vgl. OMG,

http://www.omg.org/gettingstarted/what_is_uml.htm (Stand: 27.01.02).

Architekturmodellierung innerhalb der

Unified Modeling Language 2

Dazu wird im nächstfolgenden Kapitel auf den Begriff Architektur in diesem Zusammenhang eingegangen und allgemeine Aspekte der Systemarchitektur vorgestellt. Das dritte und vierte Kapitel führt den Begriff Komponente und dessen Diagramm ein. Damit werden die softwarebasierten, physischen Aspekte eines Systems modelliert. Im Kapitel fünf und sechs werden Knoten und Einsatzdiagramm dargestellt, um die hardwarebasierten Aspekte in der UML modellieren zu können. In einem abschließenden Teil wird der Versuch unternommen, die beiden Diagramme anhand der Modellierung eines eigenen Beispiels vorzustellen.

2 Architekturmodellierung

2.1 Die fünf Sichtweisen

Die Systemarchitektur beschäftigt sich nicht nur mit dem Verhalten und der Struktur eines Softwaresystems sondern auch mit deren Funktionalität, Leistung, Robustheit, Wiederverwendbarkeit und Verständlichkeit. BOOCH/RUMBAUGH/JACOBSEN fassen die Bedeutung einer Systemarchitektur wie folgt zusammen: „Die Architektur eines Systems ist vielleicht das wichtigste Artefakt, mit dem man diese verschiedenen Standpunkte [Anmerkung des Verfassers: die Standpunkte der unterschiedlichen Anspruchsgruppen vgl. Kap.1] verwalten und mithin die iterative und inkrementelle Entwicklung eines Systems während seines Lebenszyklus kontrollieren kann.“ 4

In der UML lässt sich die Architektur eines Systems am besten durch die fünf ineinander übergreifende Sichten darstellen. Abbildung 1 zeigt eine grafische Illustration dieser fünf Sichten. Jede dieser Sichten kann für sich alleine stehen und sich auf einzelne Aspekte des Systems konzentrieren und diese abbilden. Weiterhin interagieren die fünf Sichten miteinander. Die Einsatzsicht enthält beispielsweise die Komponenten der Implementierungssicht. Die Komponenten der Implementierungssicht wiederum repräsentieren die physische Realisierung von Klassen, Schnittstellen und Kollaborationen. 5

⁴ Booch/Rumbaugh/Jacobsen, Das UML-Benutzerhandbuch, 1999, S. 34.

⁵ Vgl. Booch/Rumbaugh/Jacobsen, Das UML-Benutzerhandbuch, 1999, S. 35 f.

Architekturmodellierung innerhalb der

Unified Modeling Language 3

Quelle: Booch,G. / Rumbaugh, J. / Jacobsen, I., Das UML-Benutzerhandbuch, 1999, S. 35.

2.2 Modelle und Systeme

Die UML wird verwendet um Systeme zu modellieren. Der Systembegriff stellt in diesem Zusammenhang das zu lösende Problem als Ganzes dar. Ein System wird in der Regel in Teilsysteme zerlegt, die nahezu unabhängige Bestandteile des Systems abbilden. Ein Modell ist eine Vereinfachung der Realität und bildet somit eine Abstraktion eines Systems. BOOCH/RUMBAUGH/JACOBSEN charakterisieren die Begriffe und ihren Zusammenhang wie folgt:

„Ein System, möglicherweise in eine Menge von Teilsystemen zerlegt, ist eine organisierte Menge von Elementen, die einem Zweck dient und durch eine Menge von Modellen beschrieben wird, möglicherweise aus verschiedenen Blickwinkeln [Anmerkung des Verfasser: siehe Sichtweisen].“ 6

Modelle visualisieren interessierende Zusammenstellungen dieser Systemabstraktion aus den verschiedenen, in der UML beschriebenen Sichtweisen (siehe Abbildung 1). Alle Projektionen der Modelle in Summe geben die Struktur, das Verhalten und die Architektur des Systems wieder. 7

Modelle und Systeme kommen am häufigsten zur Anwendung, um eine Systemarchitektur zu visualisieren, zu spezifizieren, zu konstruieren und zu dokumentieren. Dabei spielen Struktur- und Verhaltensaspekte sowie die Muster, die diese Sichten Formen, eine Rolle. Da in dieser Arbeit die Architekturmodellierung im

⁶ Booch/Rumbaugh/Jacobsen, Das UML-Benutzerhandbuch, 1999, S. 473.

⁷ Vgl. Booch/Rumbaugh/Jacobsen, Das UML-Benutzerhandbuch, 1999, S. 471-473.

Architekturmodellierung innerhalb der

Unified Modeling Language 4

Vordergrund steht, wird im weiteren Verlauf näher auf die Rolle von Mustern eingegangen und die Struktur- und Verhaltensaspekte werden vernachlässigt. Muster formen letztendlich die Architektur eines Systems. Sie stellen dabei bewährte Lösungen für ein häufig auftretendes Problem im Kontext des Systems dar. Mit Mustern werden sowohl Entwurfsmuster als auch Architekturmuster modelliert. ⁸ Entwurfsmuster stellen Mechanismen dar und werden durch Kollaborationen modelliert. Mittels dieser Mechanismen werden die Interaktionen der Elemente eines Systems auf eine einheitliche Weise festgelegt. Dadurch wird ein System einfach und verständlich, da man das System auf Basis der Mechanismen betrachten kann. ⁹ Modellierte Architekturmuster bezeichnet man als Frameworks. Ein Framework ist ein Architekturmuster, das erweiterbare Vorlagen für einen Bereich zur Verfügung stellt. Man kann sich ein Framework als eine Art Mikroarchitektur vorstellen, die eine Menge von Mechanismen enthält, die zusammenarbeiten um ein häufig auftretendes Problem zu lösen. 10

Um eine Systemarchitektur zu entwickeln, bedarf es einige Zeit und eines iterativen Prozesses. Eine Systemarchitektur kann niemals in einem großen Urknall erstellt werden. Wie man aus den obigen Ausführungen erahnen kann, ist vielmehr ein gut strukturierter Prozess notwendig. Dazu gehört eine schrittweise Verfeinerung der Systemarchitektur, die anwendungsfallorientiert, architekturorientiert sowie

inkrementell erfolgen sollte. 11

In den folgenden Kapiteln werden die Implementierungssicht und die Einsatzsicht mit ihren Diagrammtypen einer näheren Betrachtung unterzogen.

3 Komponenten

3.1 Aufbau von Komponenten

Komponenten modellieren die physischen Aspekte eines Systems. Unter physischen Aspekten werden hier Bits und Bytes verstanden. Eine Komponente stellt demnach einen physischen und austauschbaren Bestandteil eines Systems dar. Komponenten genügen einer Menge von Schnittstellenspezifikationen und realisieren diese. Schnittstellen bilden eine Brücke zwischen den logischen und physischen Modellen.

⁸ Vgl. Booch/Rumbaugh/Jacobsen, Das UML-Benutzerhandbuch, 1999, S. 433.

⁹ Vgl. Booch/Rumbaugh/Jacobsen, Das UML-Benutzerhandbuch, 1999, S. 418 und 427 f.

¹⁰ Vgl. Booch/Rumbaugh/Jacobsen, Das UML-Benutzerhandbuch, 1999, S. 432 f.

¹¹ Vgl. Booch/Rumbaugh/Jacobsen, Das UML-Benutzerhandbuch, 1999, S. 478 f.

Architekturmodellierung innerhalb der

Unified Modeling Language 5

Durch Komponenten können physische Dinge wie:

• ausführbare Dateien,

• Bibliotheken,

• Tabellen,

• Dateien und

• Dokumente

modelliert werden. Diese können sich auf einem Knoten befinden. Eine Komponente stellt eine Zusammenfassung ansonsten logischer Elemente wie Klassen, Schnittstellen und Kollaborationen dar.

Komponenten der UML werden durch viele Programmiersprachen direkt unterstützt, das heißt in UML modellierte und visualisierte Komponenten können in der Implementierungsphase 1 : 1 in den Programmcode transformiert werden. ¹² Eine Komponente besitzt einen Namen, mit dem sie von anderen Komponenten unterschieden wird. Dabei werden zwei Arten von Namen unterschieden. Der einfache Name ohne Zusätze und der qualifizierte Name mit einem Präfix, der den Namen des Pakets angibt, in welchem sich die Komponente befindet. Weiterhin können Komponenten ähnlich wie bei Klassen durch zusätzlich spezifizierende Eigenschaftswerte benannt werden.

Quelle: Booch,G. / Rumbaugh, J. / Jacobsen, I., Das UML-Benutzerhandbuch, 1999, S. 392.

¹² Vgl. Booch/Rumbaugh/Jacobsen, Das UML-Benutzerhandbuch, 1999, S. 389 f.