Sequenzdiagramme sind die wichtigsten Interaktionsdiagramme und zeigen den zeitlichen Ablauf einer Reihe von Nachrichten (Methodenaufrufen)
zwischen bestimmten Objekten in einer zeitlich begrenzten Situation.
Dabei kann auch das Erzeugen und Entfernen von Objekten enthalten sein.
Sequenzdiagramme legen den Schwerpunkt auf den zeitlichen Nachrichtenverlauf, während andere Diagramme (z.B. Kommunikationsdiagramm) die Zusammenarbeit der Objekte verdeutlichen.
Manchmal verwendete Abkürzungen: 'ref' = Referenz auf bereits definierte Sequenz, 'alt' = Auswahl unter Alternativen,
'opt' = optionale Ausführung, 'par' = parallele Ausführung, 'loop' = iterative Schleife,
'{...}' = Constraint.
| «interface» |
keine Attribute
nur abstrakte Operationen
nicht instanziierbar |
Schnittstellenklassen sind abstrakte Klassen zur Definition funktionaler Schnittstellen.
Sie erleichtern arbeitsteilige Softwareentwicklung ("Design by Contract").
Schnittstellenklassen können von anderen Schnittstellenklassen erben («extend»)
und in konkreten Klassen realisiert werden (Realisierungsbeziehung, «realize»). |
| «type» |
meistens Attribute
meistens abstrakte Operationen
Assoziationen zu anderen Typen |
Typen sind abstrakte Spezifikationen (ähnlich Schnittstellen) von strukturellen Schnittstellen. |
| «entity» |
viele Attribute
viele primitive Operationen (Getter/Setter)
wenige komplexe Operationen |
Entitätsklassen repräsentieren fachlichen Sachverhalt oder Realweltgegenstand (Vertrag, Kunde, Adresse). |
| «control» |
wenige Attribute
transient, kurze Lebensdauer
komplexe Operationen |
Steuerungsklassen dienen Ablauf-, Steuerungs- und Berechnungsvorgängen, meistens stark klassenübergreifend. |
| «boundary» |
keine eigenen Operationen
delegieren Operationsaufrufe weiter
keine fachliche Logik
fast nur abgeleitete oder ableitbare Attribute
keine Persistenz, keine Zustände
oft Singletons |
Schnittstellenobjekte bilden eine Zusammenstellung von Eigenschaften anderer Objekte,
zum Beispiel zur Entkopplung im Sinne von Fassaden. |
| «primitive» |
elementare Klassen und Standardklassen
wenige Attribute
einfache Operationen |
Primitive Klassen werden in Deklarationen von Attributen verwendet.
Sie werden nicht als Klasse im Klassendiagramm dargestellt. |
| «enumeration» |
ähnliche wie bei primitiven Klassen
fast nur in Deklarationen für Attribute |
Enumerationen sind aufzählbare Wertemengen. Können Werte für Auswahllisten repräsentieren. |
| «structure» |
ausschließlich Attributdefinitionen
keine Operationen |
Datenstrukturen werden normalerweise nur zum Datenaustausch mit anderen Systemen verwendet. |
| «utility» |
Klassenattribute
Klassenoperationen |
Sammlungen von globalen Variablen und Funktionen. |
«Stereotyp»
Paketname::Klassenname
{Eigenschaftswerte} |
| ± Attributname : Attributtyp = Initialwert {Zusicherung} |
| ± Methodenname( Parameter:Typ ) {Eigenschaft} |
| KreisBeispiel |
radius {radius>0}
mittelpunkt : Point = (20,30) |
setRadius( rad )
setPosition( pos: Point ) |
|
Klassennotation
Drei Rubriken:
1.) Klassenname (eventuell mit Zusätzen)
2.) Attribute (Eigenschaften / Daten)
3.) Operationen (Methoden)
Vor den Attribut- oder Methodennamen können Sichtbarkeitssymbole stehen:
+ für public, - für private und # für protected.
Klassenattribute und -methoden werden unterstrichen.
Abgeleitete Attribute (automatisch berechnete) werden durch einen vorangestellten Schrägstrich markiert: /abgeleitetesAttr.
Abstrakte Methoden werden entweder kursiv geschrieben oder um den Eigenschaftswert {abstract} ergänzt.
Vor den Methodennamen können Stereotypen angegeben werden (z.B. «constructor»).
Die Notation für Objekte ist ähnlich der Klassennotation.
Statt des Klassennamens wird der unterstrichene Objektname eingesetzt,
eventuell gefolgt von einem Doppelpunkt und dem Namen der instanziierten Klasse
("objektName: Klassenname").
|
|
|
Instanzbeziehung
Der Pfeil ist offen und gestrichelt und zeigt vom Objekt zur Klasse (Objekt "ist abhängig von" Klasse, «instance of»).
Der Objektname wird unterstrichen.
|
|
|
Vererbung (Inheritance)
Der Pfeil ist geschlossen und durchgezogen und zeigt von der abgeleiteten
Unterklasse (= Subklasse) zur
Oberklasse (= Basisklasse = Superklasse).
Die Oberklasse ist eine Generalisierung der Unterklasse
und umgekehrt ist die Unterklasse eine Spezialisierung der Oberklasse
("Oberbegriff"-Beziehung = "Ist-ein"-Beziehung).
|
AbstrakteKlasse
{abstract} |
|
|
Abstrakte Klasse
Abstrakte Klassen werden durch den Eigenschaftswert {abstract} oder durch einen kursiv gesetzten Klassennamen markiert.
Das Aussehen des Vererbungspfeils ändert sich nicht.
Abstrakte Klassen können abstrakte Methoden enthalten, also Methoden deren Funktion noch nicht definiert ist.
Abstrakte Klassen können nicht instanziiert werden, sondern nur als Vererbungsvorlage dienen.
|
|
|
gerichteteAssoziation
|
|
|
|
geordneteAssoziation
|
|
|
|
Abhängigkeit
|
|
|
Assoziation, Aggregation und Komposition
Assoziation stellen Beziehungen zwischen Klassen dar.
Sie werden in Programmiersprachen meistens durch entsprechende Referenzattribute in den beteiligten Klassen realisiert,
bei höherer Multiplizität mit einem Sammlungsobjekt (Collection).
Meistens werden Assoziationen detaillierter als in den gezeigten Abbildungen dargestellt.
An beiden Enden der Verbindungslinie wird meistens die Multiplizität vermerkt, die angibt,
mit wie vielen Objekten diese Beziehung zustande kommen kann. Beispiele: '1', '0..1', '0..*', '5..8', '5,8'.
Es wird unterschieden zwischen Kardinalität (Anzahl der Elemente) und Multiplizität (Bereich erlaubter Kardinalitäten).
Weiter können an den Enden der Verbindungslinie die für die Beziehung relevanten Rollennamen eingetragen sein.
In der Mitte der Verbindungslinie können hinzugefügt werden:
«Stereotyp», Beziehungsname,
Leserichtung in Form eines dreieckigen Pfeils ()
und Eigenschaftswerte in eckigen Klammern ([ ]).
|
|
|
Realisierung/Verfeinerung
|
|
|
|
SchnittstelleXy
o——
|
|
|
Verfeinerungsbeziehungen («refine», «bind») gibt es zum Beispiel bei der Erzeugung (makroartige Textersetzung)
von parametrisierten konkreten Klassen (parameterized Class, bound Element)
aus schablonenartigen parametrisierbaren Klassen (Template).
Realisierungsbeziehungen («realize») gibt es zum Beispiel zu Schnittstellen («interface»).
Oft wird als Kurzschreibweise die Schnittstellenklasse lediglich durch das "Lolli"-Symbol (Kreis mit Stiel) und dem Schnittstellennamen dargestellt.
|
|
|
hat
(Aggregation)
|
|
|
|
hat
(Komposition)
|
|
|
Aggregationen und Kompositionen sind spezielle Assoziationen,
die "Teile/Ganzes"-Beziehungen und "Hat-eine"-Beziehungen darstellen.
Bei der Aggregation können die "Teile" des "Ganzen" auch einzeln existieren,
bei der Komposition nur, wenn auch das "Ganze" existiert (z.B. Rechnungspositionen auf einer Rechnung).
Die Verbindungslinie erhält auf der Seite des "Ganzen" eine Raute,
die bei der Aggregation ungefüllt und bei der Komposition gefüllt ist.
Bei automatischer Codeerzeugung werden Aggregationen und Kompositionen allerdings bei manchen Tools nicht anders als normale Assoziationen behandelt.
|
|
|
Die qualifizierte Assoziation unterteilt die referenzierten Objekte durch qualifizierende Attribute in Partitionen.
Der Qualifizierer ist vergleichbar mit einem Schlüssel (Key) für Dictionaries, assoziative Felder oder Datenbank-Look-up-Tabellen.
Der Qualifizierer könnte zum Beispiel eine Personalnummer sein.
|
|
|
methodeXy(parm)→
|
|
|
Nachrichtenaustausch, Methodenaufruf
Nachrichtenaustausch zwischen Objekten wird durch Methodenaufrufe bewerkstelligt,
deren Namen und Parameter zusammen mit einem Pfeil dargestellt werden.
|
MDA (Model Driven Architecture) ist ein Standard der OMG (http://www.omg.org/mda) und definiert eine
Vorgehensweise beim Softwareentwicklungsprozess unter Verwendung von UML.
MDA unterscheidet zwischen PIM (Platform Independend Model), PSM (Platform Specific Model)
und Code und bietet eine Grundlage für automatische Code-Generierung.
Akteur (Actor, Stakeholder, «actor»):
Geschäftsanwendungsfall (Geschäftsfall, Business Use Case, «business»):
