Architekturmodellierung innerhalb der Unified Modeling Language (UML)


Seminararbeit, 2002
34 Seiten, Note: 2,3

Leseprobe

INHALTSVERZEICHNIS

ABBILDUNGSVERZEICHNIS

1 EINFÜHRUNG

2 ARCHITEKTURMODELLIERUNG
2.1 DIE FÜNF SICHTWEISEN
2.2 MODELLE UND SYSTEME

3 KOMPONENTEN
3.1 AUFBAU VON KOMPONENTEN
3.2 FUNKTION UND ARTEN VON KOMPONENTEN
3.3 GEBRÄUCHLICHE MODELLIERUNGSTECHNIKEN VON KOMPONENTEN

4 KOMPONENTENDIAGRAMM
4.1 AUFGABE UND AUFBAU VON KOMPONENTENDIAGRAMMEN
4.2 ARTEN DER MODELLIERUNG VON KOMPONENTENDIAGRAMMEN
4.2.1 Modellieren von Sourcecode
4.2.2 Modellieren von ausf ü hrbaren Versionen
4.2.3 Modellieren einer physischen Datenbank
4.2.4 Modellieren adaptiver Systeme
4.3 HINWEISE UND TIPPS FÜR DIE MODELLIERUNG VON KOMPONENTENDIAGRAMMEN

5 KNOTEN
5.1 AUFBAU VON KNOTEN
5.2 GEBRÄUCHLICHE MODELLIERUNGSTECHNIKEN VON KNOTEN
5.2.1 Das Modellieren von Prozessoren und Geräten
5.2.2 Das Modellieren der Verteilung von Komponenten

6 EINSATZDIAGRAMME
6.1 AUFGABE UND AUFBAU VON EINSATZDIAGRAMMEN
6.2 ARTEN DER MODELLIERUNG VON EINSATZDIAGRAMMEN
6.2.1 Modellierung eines eingebetteten Systems
6.2.2 Modellierung von Client/Server-Systemen
6.2.3 Modellieren von vollständig verteilten Systemen
6.3 HINWEISE UND TIPPS FÜR DIE ERSTELLUNG VON EINSATZDIAGRAMMEN

7 EIGENES DIAGRAMMBEISPIEL
7.1 BESCHREIBUNG DES BEISPIELSYSTEMS
7.2 KOMPONENTENDIAGRAMM
7.3 EINSATZDIAGRAMM

LITERATURVERZEICHNIS

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

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

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.

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

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Modellieren einer Systemarchitektur

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

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

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

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.

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

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.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Grafische Darstellung einer Komponente

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

In der folgenden Tabelle werden die Gemeinsamkeiten und Unterschiede von Komponenten und Klassen gegenübergestellt:

Tabelle 1: Merkmale von Klassen und Komponenten

Quelle: Eigene Darstellung (in Ahnlehnung an Booch,G. / Rumbaugh, J. / Jacobsen, I., Das UMLBenutzerhandbuch, 1999, S. 392).

Abbildung in dieser Leseprobe nicht enthalten

Insbesondere stellt eine Komponente die physische Implementierung einer Menge anderer, logischer Elemente wie beispielsweise Klassen dar.

Komponenten isoliert betrachtet können allerdings noch kein System abbilden. Erst in Verbindung mit Schnittstellen werden mehrere Komponenten eines Systems im Zusammenhang abgebildet. So verwenden alle komponentenbasierten Betriebssystemfunktionen (wie COM+, CORBA) Schnittstellen als Kleber, um die Komponenten zu verbinden. Dabei realisiert die eine Komponente die Schnittstelle über eine Realisierungsbeziehung. Die zweite Komponente, die die Dienste der Schnittstelle nutzt, wird über eine Abhängigkeitsbeziehung mit der Schnittstelle verbunden.13

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Komponenten und Schnittstellen

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

Die in Abbildung 3 gezeigte Schnittstelle ist für die Komponente „ image.java “ eine Importschnittstelle, da sie von dieser Komponente verwendet wird. Demgegenüber ist dieselbe Schnittstelle für die Komponente „ component.java “ eine Exportschnittstelle, weil die Schnittstelle durch die Komponente realisiert wird.14

3.2 Funktion und Arten von Komponenten

Als integraler Bestandteil zur Abbildung von Systemen haben Komponenten bei der Konstruktion selbiger die Aufgabe den binären Austausch von Systemkomponenten zu ermöglichen. Daraus resultiert, dass Komponenten substituierbar sind. Jede konkrete Komponente kann durch eine beliebige andere ersetzt werden, sofern mindestens die ursprünglichen Schnittstellen durch die ersetzende Komponente realisiert werden.

BOOCH/RUMBAUGH/JACOBSEN fassen die Funktion von Komponenten wie folgt zusammen:

„ Eine Komponente ist ein physischer und austauschbarer Bestandteil eines Systems, der eine Menge von Schnittstellenspezifikationen gen ü gen und f ü r diese Schnittstelle eine Realisierung bietet. “ 15

Aus dieser Beschreibung lassen sich die verschiedenen Funktionen explizit benennen:

- Komponenten sind etwas physisches,
- Komponenten sind austauschbar,
- eine Komponente ist Bestandteil eines Systems, das heißt ein System auf einer Abstraktionsebene kann eine Komponente auf einer höheren Abstraktionsebene sein;
- eine Komponente genügt einer Menge von Schnittstellenspezifikationen und bietet eine Realisierung für eben diese.16

HITZ/KAPPEL unterscheiden drei verschiedene Arten von Komponenten17:

1. Quellcode-Komponenten (auch Entwicklungsergebniskomponenten genannt18 ):

Diese Komponenten sind normalerweise nur während der

Implementierungsphase in der Nutzung. Sie unterstützen die Übersetzung der Modellierungsergebnisse in Sourcecode.

2. Binärcode-Komponenten (auch als Laufzeitkomponenten bezeichnet19 ): Diese Komponenten werden aus einem laufenden System erzeugt und sind für das Binden der Programme relevant.

3. Ausführbare Komponente (auch Einsatzkomponente20 ): Diese Komponenten sind notwendig und hinreichend um ein lauffähiges System bilden zu können. Unterschieden werden beispielsweise auführbarer Code (.exe-Dateien), Bibliotheken (.dll-Dateien) oder Datenbanktabellen.

Die letztgenannte Komponente wird in der Modellierung am häufigsten angewendet und stellt daher die Komponente mit der höchsten praktischen Relevanz dar. Daher wird im folgenden näher auf die Modellierung der Einsatzkomponenten eingegangen.

3.3 Gebräuchliche Modellierungstechniken von Komponenten

Sofern ein System aus mehreren ausführbaren Dateien, Bibliotheken, Tabellen und Dateien besteht, unterstützt die Modellierung von den Komponenten die Entscheidungen über das gesamte System zu visualisieren, zu spezifizieren, zu konstruieren und zu dokumentieren. Weiterhin werden die Versionisierung und das Konfigurationsmangement während der weiteren Entwicklung des Systems unterstützt. BOOCH/RUMBAUGH/JACOBSEN schlagen ein schrittweises Vorgehen bei dem Modellieren von Einsatzkomponenten vor:

1. Man untersuche die Teilung des physischen Systems und unterscheide dabei zwischen den vorrangigen Komponenten (ausführbare Dateien und
Bibliotheken) und nachrangigen Komponenten (Tabellen, Dateien und Dokumente) des Systems.
2. Man modelliere die identifizierten Dinge zu Komponenten. Dabei verwende man die Standardelemente oder führe geeignete Stereotypen für neue Arten von Komponenten ein.
3. Man modelliere die wichtigen Schnittstellen, die notwendig sind um das System zu managen. Weiterhin modelliere man die Beziehungen zwischen diesen ausführbaren Dateien und Bibliotheken, um die Auswirkungen von Änderungen zu visualisieren.21

Betrachtet man das Modellierungsbeispiel in Abbildung 4 so werden hier einige verschiedene Komponenten dargestellt, die auf einem einzelnen PC laufen. Es sind eine ausführbare Datei („ animator.exe “), drei Bibliotheken („ render.dll, raytrce.dll und wrfrme.dll “), eine einfache Datei („ animator.ini “) und eine Datenbanktabelle („ shapes.tbl “) modelliert. Zudem sind noch die Abhängigkeitsbeziehungen zwischen

Abbildung 4: Modellierungsbeispiel für Komponenten

Quelle: Vgl. Booch/Rumbaugh/Jacobsen, Das UML-Benutzerhandbuch, 1999, S. 401.

den verschiedenen Komponenten dargestellt. Die verwendeten Notationen bilden die Standardelemente der UML ab.22

[...]


[1] Vgl. Seemann/Gudenberg, Softwareentwurf mit UML, 2000, S. 2 auch Oesterreich, Die UML Kurzreferenz für die Praxis, 2001, S. VIII.

[2] Vgl. Booch/Rumbaugh/Jacobsen, Das UML-Benutzerhandbuch, 1999, S. 13 f.

[3] 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).

[4] Booch/Rumbaugh/Jacobsen, Das UML-Benutzerhandbuch, 1999, S. 34.

[5] Vgl. Booch/Rumbaugh/Jacobsen, Das UML-Benutzerhandbuch, 1999, S. 35 f.

[6] Booch/Rumbaugh/Jacobsen, Das UML-Benutzerhandbuch, 1999, S. 473.

[7] Vgl. Booch/Rumbaugh/Jacobsen, Das UML-Benutzerhandbuch, 1999, S. 471-473.

[8] Vgl. Booch/Rumbaugh/Jacobsen, Das UML-Benutzerhandbuch, 1999, S. 433.

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

[10] Vgl. Booch/Rumbaugh/Jacobsen, Das UML-Benutzerhandbuch, 1999, S. 432 f.

[11] Vgl. Booch/Rumbaugh/Jacobsen, Das UML-Benutzerhandbuch, 1999, S. 478 f.

[12] Vgl. Booch/Rumbaugh/Jacobsen, Das UML-Benutzerhandbuch, 1999, S. 389 f.

[13] Vgl. Booch/Rumbaugh/Jacobsen, Das UML-Benutzerhandbuch, 1999, S. 394.

[14] Vgl. Booch/Rumbaugh/Jacobsen, Das UML-Benutzerhandbuch, 1999, S. 394.

[15] Booch/Rumbaugh/Jacobsen, Das UML-Benutzerhandbuch, 1999, S. 395.

[16] Vgl. Booch/Rumbaugh/Jacobsen, Das UML-Benutzerhandbuch, 1999, S. 396.

[17] Vgl. Hitz/Kappel, UML @ work, 1999, S. 164, auch vgl. Booch/Rumbaugh/Jacobsen, Das UML- Benutzerhandbuch, 1999, S. 396 f.

[18] Vgl. Booch/Rumbaugh/Jacobsen, Das UML-Benutzerhandbuch, 1999, S. 396.

[19] Vgl. Booch/Rumbaugh/Jacobsen, Das UML-Benutzerhandbuch, 1999, S. 397.

[20] Vgl. Booch/Rumbaugh/Jacobsen, Das UML-Benutzerhandbuch, 1999, S. 397.

[21] Vgl. Booch/Rumbaugh/Jacobsen, Das UML-Benutzerhandbuch, 1999, S. 398-402.

[22] Vgl. Booch/Rumbaugh/Jacobsen, Das UML-Benutzerhandbuch, 1999, S. 399, 401.

Ende der Leseprobe aus 34 Seiten

Details

Titel
Architekturmodellierung innerhalb der Unified Modeling Language (UML)
Hochschule
Universität der Bundeswehr München, Neubiberg  (Wirtschaftsinformatik)
Veranstaltung
UML
Note
2,3
Autor
Jahr
2002
Seiten
34
Katalognummer
V5843
ISBN (eBook)
9783638135818
ISBN (Buch)
9783638639118
Dateigröße
779 KB
Sprache
Deutsch
Schlagworte
Architekturmodellierung, Unified, Modeling, Language
Arbeit zitieren
Bastian Kuhl (Autor), 2002, Architekturmodellierung innerhalb der Unified Modeling Language (UML), München, GRIN Verlag, https://www.grin.com/document/5843

Kommentare

  • Noch keine Kommentare.
Im eBook lesen
Titel: Architekturmodellierung innerhalb der Unified Modeling Language (UML)


Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden