| Title: | Einführung in die Unified Modeling Language | ||
|---|---|---|---|
| Abstract: | Diese LU präsentiert eine Übersicht über die verschiedenen Diagrammtypen in der Unified Modeling Language (UML). Dabei wird auf die neue Version 2 referenziert. Außerdem wird ein Überblick über den Erweiterungsmechanismus von UML gegeben. | ||
| Status: |
|
Version: | 7.0 |
| History: |
Acronyme, Wordanführungszeichen done. kein Review vorhanden. Rechtschreibfehler gecheckt (LOD1+LOD2). Graphiken zu groß done. Sourcecode repariert. Unbekannte Character gecheckt. |
||
| Author 1: | Bernhard Tatzmann | E-Mail: | bernhard@isys.uni-klu.ac.at |
|---|---|---|---|
| Author 2: | (empty) | E-Mail: | (empty) |
| Author 3: | (empty) | E-Mail: | (empty) |
| Author 4: | (empty) | E-Mail: | (empty) |
| Author 5: | (empty) | E-Mail: | (empty) |
| Organization: | Universität Klagenfurt - Institut für Informatik-Systeme | ||
Einleitung1Auto
2AutoDiese Lerneinheit soll einen großflächigen Überblick über die bekannteste und meist verbreitete Notationssprache UML472 (Unified Modeling Language) UML04 geben. Außerdem sollen die Grundlagen für die LU UML - Anwendungen und Erweiterungen für die Multimediale Datenmodellierung geschaffen werden. Dazu werden die verschiedenen Diagrammtypen in unterschiedlicher Intensität, sowie der Erweiterungsmechanismus von UML472 beschrieben. Es wird dabei auf die neue Version 2 von UML472 referenziert. Für eine genaue Einführung in die UML472 Syntax und Semantik sei auf HK03 und JRH+03 verwiesen. In UML472 2 wurde die Struktur der Diagramme gegenüber früheren Versionen neu organisiert und in zwei Gruppen eingeteilt: Strukturdiagramm und Verhaltensdiagramm. Außerdem wurden neue Diagramme, wie das Timing-Diagramm und das Interaktionsdiagramm aufgenommen, und bestehende Diagrammtypen umbenannt (siehe Kommunikationsdiagramm). Strukturdiagramme1AutoStrukturdiagramme: Modellierung von Strukturen auf verschiedensten Abstraktionsniveaus
Klassendiagramm
Auto PC
Auto PDA_Phone
AutoModellierbare Beziehungen von Klassen:
Auto PC
Auto PDA_Phone
Paketdiagramm
Auto PC
Auto PDA_Phone
Objektdiagramm
Kompositionsstrukturdiagramm
Komponentendiagramm
Verteilungsdiagramm
2AutoZu den Strukturdiagrammen zählen sechs Diagramme: Klassendiagramm, Paketdiagramm, Objektdiagramm, Kompositionsstrukturdiagramm, Komponentendiagramm und Verteilungsdiagramm. Sie dienen der Modellierung von Strukturen auf verschiedensten Abstraktionsniveaus, wie dem Modellieren von einzelnen Klassen bis hin zur Modellierung komplexer Architekturen. KlassendiagrammKlassendiagramme sind die prominentesten Vertreter der UML472 Diagrammtypen. Sie dienen der Modellierung der statischen Struktur eines Systems. Es können sowohl die internen Eigenschaften der Klassen, wie Attribute und Methoden, als auch ihre externen Beziehungen zu anderen Klassen dargestellt werden. Attribute können innerhalb des rechteckigen Klassensymbols unter dem Klassennamen aufgelistet werden. Dabei kann sowohl die Sichtbarkeit (private, protected, public), wie auch der Datentyp angegeben werden. Im Feld unter den Attributen können die Methoden mit zugehöriger Signatur eingetragen werden. Auto PC
Auto PDA_Phone
AutoZu den modellierbaren Beziehungen von Klassen zählen die einfache Assoziation, Aggregation und Komposition (siehe Konzeptueller Entwurf in der klassischen Datenmodellierung - Entity-Relationship Modell), sowie die Generalisierung und die Abhängigkeitsbeziehung. Die folgende Abbildung zeigt die Syntax der Beziehungstypen. Auto PC
Auto PDA_Phone
PaketdiagrammPaketdiagramme erlauben es, Klassendiagramme beliebig zu abstrahieren, um auch bei größeren Strukturen noch einen Überblick bewahren zu können. Hierfür können Klassen zu Paketen zusammengefasst werden, die zusätzlich noch geschachtelt werden können. Um Pakete wie Klassen spezialisieren zu können, bieten Paketdiagramme wie auch die Klassendiagramme die Möglichkeit der Generalisierung. Dadurch wird es möglich, Pakete in modifizierter Form auch in anderen Projekten zu verwenden. Mit Hilfe von Paketdiagrammen lassen sich auch Schichtenarchitekturen, wie sie z.B. in einer Netzwerkprotokollarchitektur Anwendung finden, modellieren. Hierzu wird einfach jede Schicht durch ein Paket repräsentiert (siehe Abbildung Paketdiagramm des TCP/IP Referenzmodells). Auto PC
Auto PDA_Phone
ObjektdiagrammMit Hilfe von Objektdiagrammen kann ein System zu einem bestimmten Zeitpunkt während der Ausführung dargestellt werden. Hierzu ist es möglich, sowohl Objektinstanzen samt ihren Attributen und den aktuellen Werten, wie auch Links als spezielle Ausprägungen von Assoziationen zu modellieren. KompositionsstrukturdiagrammDas Kompositionsstrukturdiagramm wurde in UML472 2 neu eingeführt und wird auch Architekturdiagramm genannt. Mit ihm ist es möglich, sowohl die interne Struktur eines Classifiers (Überbegriff für verschiedenste UML472 Modellobjekte), wie auch seine Schnittstellen zu anderen Komponenten im System, zu modellieren. Die Notationselemente, die dafür verfügbar sind lauten: Part , Port , Kollaborationstyp und Kollaboration . Das Modellelement Part beschreibt die interne Struktur eines Classifiers. Ports definieren die Schnittstellen zwischen einem Classifier und seiner Umgebung bzw. zwischen einem Classifier und seinen Parts. Mit Hilfe eines Kollaborationstyps lässt sich die Funktionsweise eines Systems darstellen, die dann mit Hilfe einer Kollaboration noch näher beschrieben werden kann. KomponentendiagrammDas Komponentendiagramm stellt die Struktur eines Systems zur Laufzeit dar. Es zeigt sowohl, wie die Komponenten zur Laufzeit organisiert sind, wie auch welche Abhängigkeiten sich daraus ergeben. Dazu sind die folgenden Notationselemente erforderlich: Komponente, Artefakt und Abhängigkeiten . Eine Komponente dient dazu mehrere Modellelemente zusammenzufassen, die gemeinsam eine Aufgabe erfüllen. Artefakte können verwendet werden um verschiedene Informationseinheiten einheitlich darzustellen. Eine Abhängigkeit ist gerichtet und verbindet ein Modellelement mit einem weiteren, dass zur Ausführung des ersten Modellelements nötig ist. VerteilungsdiagrammDas Verteilungsdiagramm stellt eine Verbindung zwischen der Software und der verwendeten Hardware her. Es zeigt, wie die Software auf die Hardwarekomponenten verteilt wird. Ebenso können Kommunikationsbeziehungen zwischen den einzelnen Knoten (Hardwarekomponenten) modelliert werden. Die dafür notwendigen Notationselemente lauten: Knoten, Kommunikationspfad, Verteilungsbeziehung und Einsatzspezifikation . Knoten repräsentieren Hardwareressourcen, die mit Hilfe von Kommunikationspfaden verbunden werden können. Während Verteilungsbeziehungen dazu dienen Artefakte mit Knoten zu verbinden, stellen Einsatzspezifikationen spezielle Arten von Artefakten dar. Verhaltensdiagramme1AutoVerhaltensdiagramme: Zur Modellierung des Zusammenspiels und der Dynamik zwischen den einzelnen Komponenten Anwendungsfalldiagramm
Auto PC
Auto PDA_Phone
Aktivitätsdiagramm
Beispiel für Aktivitätsdiagramm aus JRH+03 PC
Beispiel für Aktivitätsdiagramm aus JRH+03 PDA_Phone
Zustandsautomat
Auto PC
Auto PDA_Phone
Sequenzdiagramm
Auto PC
Auto PDA_Phone
Kommunikationsdiagramm
Kommunikationsdiagramm einer Autovermietung aus JRH+03 PC
Kommunikationsdiagramm einer Autovermietung aus JRH+03 PDA_Phone
Timing Diagramm
Timing Diagramm eines 4-Takt Motors aus JRH+03 PC
Timing Diagramm eines 4-Takt Motors aus JRH+03 PDA_Phone
Interaktionsübersichtsdiagramm
Auto PC
Auto PDA_Phone
2AutoNeben den Strukturdiagrammen, die im vorigen Abschnitt beschrieben wurden, stellt UML472 noch eine weitere Gruppe von Diagrammen zur Verfügung, die Verhaltensdiagramme. Mit ihnen ist es möglich, das Zusammenspiel und die Dynamik zwischen den einzelnen Komponenten zu modellieren. Im Zuge der UML472 2 Umstrukturierungen wurde auch das Use-Case Diagramm in den Kreis der Verhaltensdiagramme aufgenommen und das Timing- sowie das Interaktionsübersichtsdiagramm neu eingeführt. AnwendungsfalldiagrammAnwendungsfalldiagramme (Use-Case Diagramme) sind seit der ersten Version in UML472 enthalten. Ab Version 2 gehören sie zu den Verhaltensdiagrammen. Mit ihrer Hilfe von ihnen lässt sich das äußere funktionale Verhalten von Systemen in bestimmten Anwendungsfällen (Use-Cases) modellieren. In einem Anwendungsfalldiagramm sind die graphischen Darstellungen des Systems, der Use-Cases, des Akteurs, der das System bedient, und auch die Beziehungen zwischen Akteur und Use-Case enthalten. Ein Uses-Case umfasst alle zu einem konkreten Anwendungsfall gehörenden Aktionen. Ein Beispiel wäre z.B. der Use-Case "Seite drucken", der alle Aktionen enthält, die dazu nötig sind: Druck-Icon anklicken, Drucker und Druckqualität auswählen, sowie bestätigen. Use-Cases werden stets von Akteuren ausgelöst und führen zu einem wahrnehmbaren Ergebnis. Außerdem enthalten sie auch mögliche Fehlerfälle. Die notwendigen Notationselemente zur Modellierung von Use-Cases sind: Use-Case , System , Akteur , <<include>>- und <<extend>>-Beziehung . Während eine <<include>>-Beziehung beschreibt, dass ein Use-Case das Verhalten eines anderen importiert, dient eine <<extend>>-Beziehung dazu die Erweiterung eines Use-Cases durch einen anderen darzustellen. Auto PC
Auto PDA_Phone
AktivitätsdiagrammIn einem Aktivitätsdiagramm können komplexe Abläufe modelliert werden. Graphisch werden solche Diagramme durch gerichtete Graphen repräsentiert, wobei die Knoten Aktionen, Aktivitäten, Objekte sowie Kontrollelemente darstellen. Eine Ansammlung aufeinander folgender Aktionen stellt einen Ablauf dar und eine Ansammlung von Abläufen ergibt eine Aktivität, die dann durch ein Diagramm repräsentiert wird. Die folgende Abbildung zeigt eine einfache Anwendung eines Aktivitätsdiagramms aus JRH+03. Beispiel für Aktivitätsdiagramm aus JRH+03 PC
Beispiel für Aktivitätsdiagramm aus JRH+03 PDA_Phone
AutoNeben den angesprochenen gibt es noch eine Reihe weiterer Notationselemente, auf die hier jedoch nicht näher eingegangen wird. Für dies und die Änderungen in den Aktivitätsdiagrammen von UML472 1.x auf UML472 2 sei auf JRH+03 verwiesen. ZustandsautomatZustandsautomaten , oder auch Zustandsdiagramme genannt, stellen eine Erweiterung der Endlichen Automaten dar. Sie gehen auf eine Publikation von David Harel [Har87] zurück und ermöglichen es, das Systemverhalten in beliebig kleine übersichtliche Teile zu zerlegen. Als vereinfachte Annahme kann gelten, dass sich das System zu jedem beliebigen Zeitpunkt in genau einem Zustand befindet und der Übergang in einen anderen Zustand beim Auftreten eines Ereignisses ohne zeitliche Verzögerung erfolgt. Dabei wird zwischen einfachen Zuständen , zusammengesetzten Zuständen sowie Unterzustandsautomatenzuständen unterschieden. Zustände werden im Diagramm mit Hilfe eines Rechteckes mit abgerundeten Ecken (siehe Abbildung Transition) und einer horizontalen Trennung dargestellt. Während der Name des Zustands im oberen Teil positioniert wird, können in der unteren Hälfte Aktivität und innere Transitionen aufgeführt werden, die mit dem Zustand verbunden sind und unter bestimmten Bedingungen ausgeführt werden. Transitionen führen Zustandstransformationen beim Auftreten bestimmter Ereignisse durch und werden durch einen beschrifteten Pfeil repräsentiert (siehe folgende Abbildung). Auto PC
Auto PDA_Phone
AutoWeitere wichtige Notationselemente sind Startzustand, Endzustand, Zustandsautomat, Pseudozustände, Kreuzung, Entscheidung, Terminator usw. Während der Startzustand den Einstieg in den Zustandsautomaten darstellt (ausgefüllter Kreis), definiert der Endzustand (ausgefüllter Kreis umgeben von einem weiteren Kreis) den Abschluss der Abarbeitung des Automaten. Entscheidungen (nicht ausgefüllte Raute) ermöglichen bedingte Verzweigungen. SequenzdiagrammDas Sequenzdiagramm bietet die Möglichkeit den Nachrichtenaustausch zwischen den einzelnen Komponenten zu modellieren. Außerdem erlaubt es die Modellierung von festen Reihenfolgen, sowie zeitlichen und logischen Ablaufbedingungen. Das Sequenzdiagramm ist eines der vier in UML472 2 verfügbaren Diagramme zur Interaktionsmodellierung. Weiters existieren das Kommunikationsdiagramm (früher Kollaborationsdiagramm), sowie die beiden in UML472 2 neu eingeführten Diagrammarten Timing-Diagramm und Interaktionsübersichtsdiagramm, wobei das Sequenzdiagramm das bedeutendste ist. Das Sequenzdiagramm selbst wurde im Zuge der UML472 2 Überarbeitung um einige Funktionen, die bessere Möglichkeiten der Schachtelung und Kontrolle der Nachrichtenabfolgen gewährleisten, erweitert. Im Allgemeinen sind Sequenzdiagramme in zwei Dimensionen aufgebaut. Während die vertikale Achse den Zeitverlauf repräsentiert, werden die einzelnen Kommunikationspartner (i.A. Objekte) von links nach rechts dargestellt. Der Kommunikationsverlauf der einzelnen Komponenten lässt sich also im Diagramm von oben nach unten verfolgen. Die wichtigsten Notationselemente sind Interaktion, Lebenslinie und Nachricht . Die Interaktion bildet den Rahmen des Sequenzdiagramms. Sie beinhaltet mehrere Lebenslinien die den zeitlichen Verlauf eines Classifiers, durch ein Rechteck mit angeschlossener strichlierter Linie, darstellen. Die Nachricht symbolisiert den Informationsfluss zwischen den einzelnen Interaktionsteilnehmern. Die folgende Abbildung zeigt die Darstellung der Komponenten in einem Sequenzdiagramm JRH+03. Auto PC
Auto PDA_Phone
KommunikationsdiagrammDas Kommunikationsdiagramm, das in früheren UML472 Versionen Kollaborationsdiagramm genannt wurde ist ein weiteres Interaktionsdiagramm. Es modelliert die Kommunikation einzelner Teile eines Systems auf einem mittleren Abstraktionsniveau. Dabei ist zu beachten, dass keinerlei Zeitindizes verwendet werden. Der Kommunikationsfluss wird lediglich durch eine Nummerierung angezeigt. Somit lassen sich mit Hilfe des Kommunikationsdiagramms schematische Analysen des Systems erstellen, bei denen es eher auf ein grundlegendes Verständnis als auf exakte Zeitverläufe ankommt. Die Notationselemente sind dementsprechend einfach und beschränken sich lediglich auf Interaktionsrahmen, Lebenslinien und Nachrichten. Im Kommunikationsdiagramm besitzt die Lebenslinie keine strichlierte Linie. Sie stellt lediglich die Kommunikationspartner, mithilfe eines Rechtecks dar. Kommunikationsdiagramm einer Autovermietung aus JRH+03 PC
Kommunikationsdiagramm einer Autovermietung aus JRH+03 PDA_Phone
Timing DiagrammDas Timing Diagramm wurde in UML472 2 neu eingeführt und stellt ein weiteres Interaktionsdiagramm dar. Es spiegelt die Zustandsänderungen von Objekten in Bezug auf den zeitlichen Verlauf wieder. Dabei erinnert es stark an die in der Elektrotechnik verwendeten Diagramme zur Darstellung des Zeitverhaltens digitaler Schaltungen. Timing Diagramm eines 4-Takt Motors aus JRH+03 PC
Timing Diagramm eines 4-Takt Motors aus JRH+03 PDA_Phone
AutoWährend die einzelnen zu betrachtenden Komponenten mit ihren verschiedenen Zuständen übereinander angeordnet werden, wird die Zeitlinie entlang der horizontalen Achse aufgetragen (siehe obige Abbildung). Neben den Zeitverlaufslinien gibt es auch noch ein ähnliches Notationselement mit dem Namen Wertverlaufslinien, das zur Anwendung kommt, wenn viele verschiedene Zustände modelliert werden sollen. Hier wird der Zustand nicht durch die vertikale Lage der Zeitlinie, sondern durch Hinzufügen eines entsprechenden Textes angegeben. Zusätzlich zum Zeitverlauf ist es noch möglich, Nachrichten zwischen den Komponenten, die zu bestimmten Zeitpunkten versendet werden, zu modellieren. Falls Nachrichten zwischen graphisch weit entfernten Objekten modelliert werden sollen, bietet UML472 die Möglichkeit, Sprungmarken einzufügen, um eine bessere Übersichtlichkeit zu bewahren. InteraktionsübersichtsdiagrammDas Interaktionsübersichtsdiagramm wurde ebenfalls in UML472 2 neu eingeführt und stellt eine Mischform eines Aktivitätsdiagramms und eines Interaktionsdiagramms dar. Im Gegensatz zu einem herkömmlichen Aktivitätsdiagramm zeigt es jedoch keine Menge von Aktionen, sondern eine Abfolge von Interaktionen. Im Prinzip dient es der Verknüpfung vieler verschiedener Interaktionen eines großen Systems. Da es sich um eine Mischform anderer Diagramme handelt, stellt es keine neuen Notationselemente zur Verfügung. Auto PC
Auto PDA_Phone
Erweiterungsmechanismus1Stereotype
Auto PC
Auto PDA_Phone
Auto
Auto PC
Auto PDA_Phone
EigenschaftswerteEigenschaftswerte:
2StereotypeUML472 bietet die Möglichkeit, die Sprache mit Hilfe eines Erweiterungsmechanismus benutzerdefiniert anzupassen. Der wichtigste Mechanismus hierfür sind die Stereotype. Stereotype werden in UML472 2 durch das neu eingeführte Beziehungssymbol Erweiterung definiert. Dabei wird das Stereotyp, welches gleich wie eine Klasse durch ein rechteckiges Symbol symbolisiert wird, mit jener Klasse graphisch verbunden (Assoziation mit ausgefüllter Pfeilspitze in Richtung der erweiterten Klasse), die durch das Stereotyp erweitert wird. Innerhalb der graphischen Repräsentation des Stereotyps steht das Schlüsselwort stereotype in doppelten Spitzklammern, sowie der Klassenname des Stereotyps, der üblicherweise mit einem Kleinbuchstaben beginnt. Ein Stereotyp kann auch mit mehreren Klassen durch die Erweiterungs-Beziehung verbunden werden. Bei der erweiterten Klasse wird das Schlüsselwort metaclass hinzugefügt (siehe Abbildung Definition von Stereotypen). Auto PC
Auto PDA_Phone
AutoEine konkrete Instanz wird dann wie eine "normale" Klasse dargestellt, mit Ausnahme der Tatsache, dass der Name des Stereotyps in doppelten Spitzklammern in der Nähe des Klassennamens platziert wird (siehe Abbildung Instanz eines Stereotyps). Auto PC
Auto PDA_Phone
AutoIm Detail handelt es sich bei einem Stereotyp um eine Klasse im UML472 Metamodell (unter der Metamodellierung von UML472 versteht man die Darstellung aller UML472 Konzepte in UML472 selbst), die andere Klassen des Metamodells durch Erweiterungen näher spezifiziert JRH+03. Es ist schon eine Reihe von Stereotypen in UML472 standardmäßig verfügbar. Zur Illustration sei z.B. das Stereotyp focus erwähnt: Klassen die so gekennzeichnet sind, definieren den zentralen Kontrollfluss. Einige Anwendungen des Stereotyp-Erweiterungsmechanismus werden in der LU UML - Anwendungen und Erweiterungen für die Multimediale Datenmodellierung präsentiert. Prinzipiell kann gesagt werden, dass Stereotype immer dann verwendet werden sollten, wenn ein UML472 Modellelement mit einer spezifischen Semantik ausgestattet werden soll. EigenschaftswerteEine alternative Möglichkeit der UML472 Erweiterung bieten Eigenschaftswerte. Sie dienen ebenfalls der näheren Beschreibung von UML472 Modellelementen. Dies wird durch Name-Werte-Paare bewerkstelligt, die durch Beistriche getrennt innerhalb geschwungener Klammern angeschrieben werden (z.B.: {Eigenschaft1=true, Eigenschaft2=false}). Ein prominenter Vertreter einer Erweiterung ist der Eigenschaftswert abstract, der Klassen als nicht instanzierbar deklariert. Eigenschaftswerte werden verwendet, wenn Stereotype zur Beschreibung nicht hinreichend sind JRH+03. Bibliographie2AutoHar87 UML04 HK03 JRH+03 |
| (empty) |