endpunkt uml diagramm

Transcription

Konsistenz und
Werkzeugunterstützung von
Systemspezifikationen in UML
Diplomarbeit von
S TEPHAN S CHUBERT
im Rahmen des Studiengangs
Mathematik mit Studienrichtung Informatik
an der Universität Hannover
Erstgutachter: Prof. Dr. Udo Lipeck
Zweitgutachter: Dipl. Math. Christof Graß-De Iuliis
Hannover, den 25. Juli 1999
Zusammenfassung
Die Unified Modeling Language (UML) ist eine Sprache zur Dokumentation, Analyse,
Entwurf und Spezifikation von Systemen. Ein UML-Modell beschreibt die statischen und
dynamischen Aspekte eines Systems durch mehrere ineinandergreifende Sichten, die aus
verschiedenen Diagrammen bestehen.
In der vorliegenden Arbeit wird vorgestellt, wie mit einem Werkzeug ein UML-Modell
auf Konsistenz überprüft werden kann. Das UML-Metamodell, welches die die Semantik
der UML definiert, wird vorgestellt. Es bildet die Basis für die Identifizierung von Konsistenzbedingungen, die zwischen den Modellelementen eines vom Modellierer erstellten
UML-Modells gelten müssen.
Es wird erläutert, im welchen Rahmen ein Werkzeug den Modellierer bei der Erstellung konsistenter UML-Modelle unterstützen kann. Das kommerzielle UML-Werkzeug
Rational Rose 98 wird vorgestellt und um Konsistenzprüfungen erweitert.
Inhaltsverzeichnis
1
2
Einleitung
1.1 Die Unified Modeling Language . . .
1.2 Historische Entwicklung . . . . . . .
1.3 Ziele der Unified Modeling Language
1.4 Ziele dieser Arbeit . . . . . . . . . .
1.5 Aufbau der Arbeit . . . . . . . . . . .
1.6 Probleme bei der Erstellung der Arbeit
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
8
8
9
11
11
12
Eine Übersicht
2.1 Dinge in der UML . . . . . . . .
2.1.1 Struktur . . . . . . . . . .
Klasse . . . . . . .
Interface . . . . .
Kollaboration . . .
Anwendungsfall .
Aktive Klasse . . .
Komponente . . .
Knoten . . . . . .
2.1.2 Verhalten . . . . . . . . .
Interaktion . . . .
Zustandsautomat .
2.1.3 Gruppierung . . . . . . .
2.1.4 Anmerkungen . . . . . . .
2.2 Beziehungen . . . . . . . . . . .
2.2.1 Abhängigkeit . . . . . . .
2.2.2 Assoziation . . . . . . . .
2.2.3 Generalisierung . . . . . .
2.2.4 Realisierung . . . . . . .
2.3 Diagramme . . . . . . . . . . . .
2.3.1 Anwendungsfalldiagramm
2.3.2 Klassendiagramm . . . . .
2.3.3 Objektdiagramm . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
14
14
15
15
15
16
16
17
17
18
18
18
19
19
20
20
20
21
21
22
23
23
23
23
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
INHALTSVERZEICHNIS
2.4
2.5
2.6
3
2.3.4 Interaktionsdiagramme . . . . .
2.3.5 Zustandsdiagramm . . . . . . .
2.3.6 Aktivitätsdiagramm . . . . . . .
2.3.7 Komponentendiagramm . . . .
2.3.8 Einsatzdiagramm . . . . . . . .
Architektur und Sichten . . . . . . . . .
2.4.1 Anwendungsfallsicht . . . . . .
2.4.2 Logische Sicht . . . . . . . . .
2.4.3 Prozeßsicht . . . . . . . . . . .
2.4.4 Komponentensicht . . . . . . .
2.4.5 Verteilungssicht . . . . . . . . .
Vier-Schichten Metamodell-Architektur
Erweiterungsmechanismen . . . . . . .
2.6.1 Stereotypen . . . . . . . . . . .
2.6.2 Eigenschaftswerte . . . . . . .
2.6.3 Zusicherungen . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Metamodell
3.1 Fundament . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 Kern . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1.1 Backbone . . . . . . . . . . . . . . .
Generalisierung . . . . . . . . . . . . . .
Erweiterung und Einschränkung . . . . .
Deskriptor und Vererbungsmechanismus
Instantiierung . . . . . . . . . . . . . . .
Klasse . . . . . . . . . . . . . . . . . . .
Element . . . . . . . . . . . . . . . . .
PresentationElement . . . . . . . . .
ModelElement . . . . . . . . . . . . . .
Namespace . . . . . . . . . . . . . . . .
Constraint . . . . . . . . . . . . . . .
GeneralizableElement . . . . . . . . .
Classifier . . . . . . . . . . . . . . .
Feature . . . . . . . . . . . . . . . . .
StructuralFeature . . . . . . . . . . .
Attribute . . . . . . . . . . . . . . . .
BehavioralFeature . . . . . . . . . . .
Operation . . . . . . . . . . . . . . . .
Method . . . . . . . . . . . . . . . . . .
Parameter . . . . . . . . . . . . . . . .
3.1.1.2 Klassifizierer . . . . . . . . . . . . . .
Class . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
25
26
30
30
30
31
31
31
31
32
32
33
33
34
34
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
35
35
37
37
38
40
41
41
42
43
45
45
46
47
47
48
49
51
51
52
53
54
54
55
55
INHALTSVERZEICHNIS
3.2
Interface . . . . . . . . . . . . .
DataType . . . . . . . . . . . . . .
Node . . . . . . . . . . . . . . . .
Component . . . . . . . . . . . . .
3.1.1.3 Assoziation und Generalisierung
Relationship . . . . . . . . . . .
Association . . . . . . . . . . . .
AssociationEnd . . . . . . . . . .
AssociationClass . . . . . . . .
Generalization . . . . . . . . . .
Flow . . . . . . . . . . . . . . . .
3.1.1.4 Abhängigkeiten . . . . . . . . .
Dependency . . . . . . . . . . . .
Abstraction . . . . . . . . . . . .
Usage . . . . . . . . . . . . . . . .
Permission . . . . . . . . . . . .
3.1.1.5 Kommentar . . . . . . . . . . .
3.1.2 Erweiterungsmechanismen . . . . . . . . .
Stereotype . . . . . . . . . . . .
Modelelement . . . . . . . . . . .
Constraint . . . . . . . . . . . .
TaggedValue . . . . . . . . . . . .
3.1.3 Datentypen . . . . . . . . . . . . . . . . .
Primitive . . . . . . . . . . . . .
Structure . . . . . . . . . . . . .
Enumeration . . . . . . . . . . . .
ProgrammingLanguageType . . . .
Mapping . . . . . . . . . . . . . .
Name . . . . . . . . . . . . . . . .
LocationReference . . . . . . . .
Multiplicity . . . . . . . . . . .
Expression . . . . . . . . . . . .
Verhaltenselemente . . . . . . . . . . . . . . . . .
3.2.1 Allgemeines Verhalten . . . . . . . . . . .
3.2.1.1 Signale . . . . . . . . . . . . . .
Signal . . . . . . . . . . . . . . .
Exception . . . . . . . . . . . . .
Reception . . . . . . . . . . . . .
3.2.1.2 Aktion . . . . . . . . . . . . . .
Action . . . . . . . . . . . . . . .
ActionSequence . . . . . . . . . .
CreateAction . . . . . . . . . . .
4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
56
56
56
56
57
62
62
63
65
66
66
67
67
68
69
70
71
71
72
73
74
75
75
75
76
76
77
77
77
79
79
79
80
82
82
82
83
83
84
84
86
86
5
INHALTSVERZEICHNIS
3.2.2
3.2.3
DestroyAction . . . . . . . . . . . . . . . . . . . . . .
TerminateAction . . . . . . . . . . . . . . . . . . . . .
CallAction . . . . . . . . . . . . . . . . . . . . . . . .
ReturnAction . . . . . . . . . . . . . . . . . . . . . . .
AssignmentAction . . . . . . . . . . . . . . . . . . . .
SendAction . . . . . . . . . . . . . . . . . . . . . . . .
UninterpretedAction . . . . . . . . . . . . . . . . . .
3.2.1.3 Exemplare und Links . . . . . . . . . . . . . . . . . .
Instance . . . . . . . . . . . . . . . . . . . . . . . . . .
DataValue . . . . . . . . . . . . . . . . . . . . . . . . .
Object . . . . . . . . . . . . . . . . . . . . . . . . . . .
ComponentInstance . . . . . . . . . . . . . . . . . . . .
NodeInstance . . . . . . . . . . . . . . . . . . . . . . .
Linkobject . . . . . . . . . . . . . . . . . . . . . . . .
Stimulus . . . . . . . . . . . . . . . . . . . . . . . . . .
Link . . . . . . . . . . . . . . . . . . . . . . . . . . . .
LinkEnd . . . . . . . . . . . . . . . . . . . . . . . . . .
Kollaborationen . . . . . . . . . . . . . . . . . . . . . . . . . . .
Notation der Rollen in einer Kollaboration . . . . . . . . .
Interaktion . . . . . . . . . . . . . . . . . . . . . . . . .
Botschaften und Stimuli in einem Kollaborationsdiagramm
Sequenzdiagramm . . . . . . . . . . . . . . . . . . . . .
Collaboration . . . . . . . . . . . . . . . . . . . . . .
Interaction . . . . . . . . . . . . . . . . . . . . . . . .
Message . . . . . . . . . . . . . . . . . . . . . . . . . .
ClassifierRole . . . . . . . . . . . . . . . . . . . . . .
AssociationRole . . . . . . . . . . . . . . . . . . . . .
AssociationEndRole . . . . . . . . . . . . . . . . . . .
Zustandsautomaten . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.3.1 Ereignisse . . . . . . . . . . . . . . . . . . . . . . . .
Event . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SignalEvent . . . . . . . . . . . . . . . . . . . . . . . .
CallEvent . . . . . . . . . . . . . . . . . . . . . . . . .
TimeEvent . . . . . . . . . . . . . . . . . . . . . . . . .
ChangeEvent . . . . . . . . . . . . . . . . . . . . . . . .
3.2.3.2 Zustandsautomat . . . . . . . . . . . . . . . . . . . . .
StateMachine . . . . . . . . . . . . . . . . . . . . . . .
CompositeState . . . . . . . . . . . . . . . . . . . . . .
StateVertex . . . . . . . . . . . . . . . . . . . . . . . .
Transition . . . . . . . . . . . . . . . . . . . . . . . .
Guard . . . . . . . . . . . . . . . . . . . . . . . . . . . .
State . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
86
86
86
86
87
87
87
87
89
89
89
89
90
90
90
90
92
92
95
95
97
99
99
100
100
101
101
101
103
103
103
103
104
104
105
106
110
110
110
110
111
INHALTSVERZEICHNIS
.
.
.
.
.
.
.
.
.
.
.
.
.
.
111
111
111
112
113
113
113
116
116
116
117
117
118
118
Werkzeugunterstützung und Konsistenz
4.1 Anforderungen an ein UML-Werkzeug . . . . . . . . . . . . . . . . . . .
4.2 Konsistenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Sinn einer Konsistenzprüfung . . . . . . . . . . . . . . . . . . .
4.2.2 Probleme der (werkzeuggestützten) Konsistenzprüfung . . . . . .
4.2.3 Ein hypothetisches Werkzeug zur Konstruktion konsistenter Modelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.4 Konsistenzprüfung als Informationsproduzent . . . . . . . . . . .
4.3 Rational Rose 98 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1 UML-Modelle in Rational Rose 98 . . . . . . . . . . . . . . . .
4.3.2 Weitere Merkmale von Rational Rose 98 . . . . . . . . . . . . .
4.3.3 Konsistente UML-Modelle und Rational Rose 98 . . . . . . . . .
4.4 Das Werkzeugmetamodell von Rational Rose 98 . . . . . . . . . . . . . .
4.4.1 Die Spitze der Klassenhierarchie . . . . . . . . . . . . . . . . . .
4.4.2 Diagrammarten . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.3 Modellelemente in Klassendiagrammen . . . . . . . . . . . . . .
4.4.4 Modellelemente in Interaktionsdiagrammen . . . . . . . . . . . .
4.4.5 Modellelemente in Zustandsdiagrammen . . . . . . . . . . . . .
4.5 Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5.1 Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5.2 Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5.3 Operationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5.4 Assoziationen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5.5 Spezielle Assoziationen . . . . . . . . . . . . . . . . . . . . . .
4.5.6 Generalisierungen . . . . . . . . . . . . . . . . . . . . . . . . .
4.5.7 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5.8 Realisierungsbeziehungen . . . . . . . . . . . . . . . . . . . . .
119
119
121
124
124
3.2.4
4
SimpleState . . . .
FinalState . . . .
PseudoState . . . .
SyncState . . . . .
SubmachineState .
StubState . . . . .
Aktivitätsgraphen . . . . . .
ActivityGraph . .
SubactivityState
ActionState . . . .
CallState . . . . .
ObjectFlowState .
ClassifierInState
PseudoState . . . .
6
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
125
128
128
128
131
133
134
134
134
137
139
140
142
142
144
147
150
153
155
157
159
7
INHALTSVERZEICHNIS
4.6
4.7
5
4.5.9 Abhängigkeitsbeziehungen . . .
4.5.10 Signale . . . . . . . . . . . . .
4.5.11 Spezifizierung von Rollen . . .
Interaktionsdiagramme . . . . . . . . .
4.6.1 Klassifiziererrollen und Objekte
4.6.2 Assoziationsrollen und Links . .
4.6.3 Botschaften und Stimuli . . . .
4.6.4 Kontrollfluß . . . . . . . . . . .
4.6.5 Verzweigung und Iteration . . .
Zustandsdiagramme . . . . . . . . . . .
4.7.1 Ereignisse . . . . . . . . . . . .
4.7.2 Aktionen . . . . . . . . . . . .
4.7.3 Transitionen . . . . . . . . . .
4.7.4 Zustände . . . . . . . . . . . .
4.7.5 Zustandsautomaten . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
161
162
164
165
165
167
171
175
177
178
179
182
182
184
186
Benutzerschnittstelle zur Konsistenzprüfung
195
5.1 Möglichkeiten von Rose-Script . . . . . . . . . . . . . . . . . . . . . . . 195
5.2 Strukturierung der Konsistenzprüfungen . . . . . . . . . . . . . . . . . . 197
5.3 Konzept der Benutzerschnittstelle . . . . . . . . . . . . . . . . . . . . . 198
A Realisierung der Benutzerschnittstelle
A.1 Das Skript einer Konsistenzprüfung
A.2 Das Skript eines Auswahldialogs . .
A.3 Entwickelte Skripte . . . . . . . . .
A.3.1 Hilfsfunktionen . . . . . . .
A.3.2 Konsistenzprüfungen . . . .
A.3.3 Auswahldialoge . . . . . . .
A.4 Installation . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
202
202
203
203
203
204
208
208
Kapitel 1
Einleitung
Die ersten drei Abschnitte erläutern, was die Unified Modeling Language ist, ihre historischen Wurzeln und die Ziele, die bei der Entwicklung dieser Modellierungssprache
spezifiziert wurden. Anschließend wird das Ziel dieser Arbeit erklärt und ihr Aufbau
beschrieben. Abschließend wird auf die Probleme bei der Erstellung dieser Arbeit hingewiesen.
1.1
Die Unified Modeling Language
Systeme bestehen „aus einer Menge von Elementen, die über Beziehungen zusammenwirken oder interagieren, um ein bestimmtes Ziel oder einen bestimmten Zweck zu erreichen“ ([Sch95], S. 15). Menschen benutzen zum Verständnis komplexer Systeme
das Prinzip der Abstraktion. „Abstraktion im engeren Sinne heißt ein Denkvorgang,
der vom Einzelnen, Zufälligen, Unwesentlichen absieht und das Allgemeine, Notwendige, Wesentliche heraushebt, um zu wissenschaftlich objektiver Erkenntnis zu gelangen“
([Sch91], S. 4). Das Ziel der Abstraktion von einem System ist die Bildung eines Modells
des Systems, die es dem Menschen erlaubt, die Systemelemente und ihr Zusammenwirken zu verstehen. Allgemein ausgedrückt ist die Unified Modeling Language (UML)
eine Sprache, mit der Modelle von Systemen graphisch beschrieben werden können. Primär dient die UML der Dokumentation, Analyse, Entwurf und Spezifikation von Softwaresystemen - speziell von objektorientierten Systemen. UML ist „nur“ eine (visuelle)
Modellierungssprache, aber kein Softwareentwicklungsprozeß oder gar eine visuelle Programmmiersprache. Der Begriff „unified“ (dt. vereinheitlicht) wird durch die historische
Entwicklung der Sprache begründet.
1.2
Historische Entwicklung
Während der neunziger Jahre wurden eine Vielzahl von Methoden für die Systementwicklung von Software veröffentlicht. Drei der populärsten Methoden waren OMT (Ob-
8
9
KAPITEL 1. EINLEITUNG
ject Modeling Technique, James Rumbaugh u.a., siehe [R+ 93]), Booch (Grady Booch)
und OOSE (Object-Oriented Software Engineering, Ivar Jacobson). Jede dieser Methoden hatte eine eigene Notation und eigene Stärken und Schwächen. Die Weiterentwicklung der einzelnen Methoden führte dazu, daß Konzepte anderer Methoden übernommen wurden. Leider hatte jede Methode noch immer ihre eigene Notation. Diese Zeit
wird durch den Begriff „method war“ beschrieben. Z.B. beschreibt ein gefüllter Kreis in
OMT-Notation einen Kardinalitätsindikator, in Booch-Notation jedoch ein Aggregationssymbol. Wie soll eine Klasse dargestellt werden: Als Wolke (Booch) oder als Rechteck
(OMT)? Welche Darstellung ist besser? Eine Situation die unbefriedigend für alle Beteiligten war, denn eine unterschiedliche Syntax und Semantik führt nicht nur bei Softwareentwicklern zu Kommunikationsschwierigkeiten.
Im Oktober 1994 begannen Grady Booch (Rational Software Corporation) und James
Rumbaugh (der von General Electric zu Rational wechselte) mit der Vereinheitlichung der
Booch und OMT Methoden, dessen Entwurf einer Version 0.8 im Oktober 1995 erschien
und „Unified Method“ hieß.
1995 stieß auch Jakobson (OOSE) zu Rational und OOSE wurde in das Projekt aufgenommen (1996, UML 0.9). Mit mehreren Software-Organisationen, die bereit waren
Ressourcen einzubringen, um eine vollständige UML-Definition auszuarbeiten, wurde ein
UML-Konsortium gegründet (UML 1.0). Im Januar 1997 wurde UML 1.0 bei der OMG
(Object Management Group) zur Standardisierung eingereicht. Das Konsortium wurde
erweitert und eine überarbeitete Version (UML 1.1) wurde im Juli 1997 bei der OMG zur
Standardisierung eingereicht und im November 1997 angenommen. In die Vereinheitlichung gingen nicht nur die Konzepte der Booch, OMT und OOSE Methoden ein, sondern
auch „neue“ Konzepte, z.B. die Statecharts von Harel.
Die Weiterentwicklung der UML wurde von der OMG Revision Task Force (RTF)
übernommen, die im Juni 1998 eine redaktionell überarbeitete Version herausbrachte. Im
Herbst 1998 wurde die Version 1.3 mit einigen technischen Klarstellungen veröffentlicht,
deren endgültige Fassung im Juli 1999 fertiggestellt wurde. Es ist zu erwarten, daß die
UML, wie jede „lebende“ Sprache, laufend weiterentwickelt wird.
1.3
Ziele der Unified Modeling Language
Beim Entwurf der UML gab es mehrere Ziele: (siehe [BRJ99b] und [OMG99])
1. Die Benutzung objektorientierter Techniken zur Modellierung von Systemen vom
Konzept bis zu ausführbaren Teilen.
2. Berücksichtigung der Skalierung von komplexen Systemen.
3. Erzeugung einer Modellierungssprache, die sowohl von Menschen als auch von
Maschinen benutzt werden kann.
1.3. ZIELE DER UNIFIED MODELING LANGUAGE
10
4. Die UML sollte den Benutzern eine leicht zugängliche und ausdrucksstarke visuelle Modellierungssprache bieten, mit der sie Modelle entwickeln und austauschen
können.
UML vereinigt eine Menge von allgemeinen bzw. Kern-Konzepten, die in anderen
Methoden und Tools verwendet werden. Benutzer anderer Methoden können somit
relativ leicht umsteigen und ihre Modelle mit erträglichem Aufwand transformieren.
5. Die UML sollte Erweiterungs- und Spezialisierungsmechanismen enthalten.
Es ist (bzw. war) zu erwarten, daß die UML an neue Bedürfnisse oder spezielle
Bereiche angepaßt werden wird. Dabei ist aber nicht gewollt, den Kern von UML
für jedes Gebiet neu zu definieren oder zu implementieren. Der Kern der UML
sollte nicht mehr als notwendig geändert werden müssen. Die Benutzer sollten in
der Lage sein
• Modelle der meisten Anwendungen mit den allgemeinen Konzepten der UML
zu entwerfen, ohne von den Erweiterungsmechanismen Gebrauch zu machen,
• neue Konzepte und Notationen, die durch den Kern nicht abgedeckt werden,
hinzuzufügen,
• Konzepte und Notationen für besondere Anwendungsbereiche zu spezialisieren.
6. Unabhängigkeit von besonderen Programmiersprachen und Entwicklungsprozessen.
Unabhängigkeit bedeutet, daß man sich nicht auf eine bestimmte Programmiersprache oder einen bestimmten Prozeß festlegen wollte, allerdings bei gleichzeitiger
Minimierung der Schwierigkeiten, die UML mit einer bestimmten Programmiersprache oder einem bestimmten Entwicklungsprozeß anzuwenden.
7. Bereitstellung einer formalen Basis für die UML.
8. Interoperabilität der Werkzeuge.
Interoperabilität verlangt, daß Modelle zwischen verschiedenen Werkzeugen ohne
Informationsverlust ausgetauscht werden können. Damit können sich die Hersteller
von Werkzeugen auf spezielle Funktionen ihrer Software konzentrieren anstatt ihre
Ressourcen auf verschiedene Werkzeuge für verschiedene Modellierungssprachen
zu verteilen.
9. Unterstützung höherer Entwicklungskonzepte wie z.B. Kollaborationen, Frameworks, Muster (pattern) und Komponenten.
10. Integration der besten und bewährten Praktiken.
11
1.4
Ziele dieser Arbeit
Systeme zeichnen sich durch Struktur und Verhalten aus und können durch Modelle beschrieben werden. Ein UML-Modell beschreibt die statischen und dynamischen Aspekte
eines Systems durch mehrere ineinandergreifende Sichten.
In der Anwendungsfallsicht wird das System als black-box betrachtet. Sie beschreibt
relativ grob die Funktionen und Abläufe des Systems, ohne auf deren Realisierung einzugehen. Die logische Sicht beschreibt das Systeminnere. Sie spezifiziert die Systemelemente und ihre gegenseitigen Beziehungen, mit denen die Funktionen und Abläufe der
Anwendungsfallsicht umgesetzt werden. Weitere Sichten beschreiben die Nebenläufigkeit und Synchronisationsmeachnismen des Systems, die Realisierung des Systems durch
Komponenten (Quelltexte, ausführbare Dateien u. ä.) und die Verteilung der Komponenten auf die Hardware des Systems.
Die Sichten bestehen aus Diagrammen, die jeweils einen bestimmten Aspekt des Systems beschreiben. Die UML stellt Diagramme zur Verfügung, die teilweise in mehreren Sichten benutzt werden. Klassendiagramme beschreiben Systemelemente und ihre
Beziehungen, während Interaktionsdiagramme die Interaktion der Systemelemente zur
Erreichung eines bestimmten Ziels darstellen. Mit Zustands- (Statecharts) und Aktivitätsdiagrammen (eine Art Flowchart) können jeweils weitere dynamische Aspekte modelliert
werden. Anwendungsfall-, Komponenten- und Verteilungsdiagramme sind weitere Diagramme, die in den jeweiligen Sichten benutzt werden.
Eine Systemspezifikation in UML besteht also aus einer Vielzahl von Diagrammen,
die jeweils einen bestimmten Aspekt des Systems hervorheben. Ein Ziel dieser Arbeit ist
es, die Zusammenhänge zwischen den Diagrammen und Modellelementen eines UMLModells zu finden, anhand derer sich eine Systemspezifikation in UML auf Konsistenz
(Widerspruchsfreiheit) untersuchen läßt.
Verschiedene Werkzeuge für die Modellierung von System mit der UML sind auf dem
CASE-Toolmarkt verfügbar. Rational Rose 98 ist ein UML-Werkzeug der Rational Software Cooperation (s.o.), welches von verschiedenen Instituten der Universität Hannover
eingesetzt wird. Ein weiteres Ziel dieser Arbeit ist die Untersuchung dieses Werkzeugs.
Wie geht Rational Rose 98 mit der Problematik konsistenter Systemspezifikationen um
und welche Zusammenhänge zwischen den Modellelementen werden auf Konsistenz geprüft? Gegebenenfalls soll Rational Rose 98 um weitere Prüfungen erweitert werden.
1.5
Aufbau der Arbeit
In Kapitel 2 wird ein Überblick über den Sprachumfang der UML gegeben. Es werden
die Sprachelemente, Diagramme und Sichten der UML, aus denen ein UML-Modell besteht und die Erweiterungsmechanismen, mit denen der Sprachumfang der UML erweitert
werden kann, kurz vorgestellt.
In Kapitel 3 wird das Metamodell der UML erläutert. Das Metamodell definiert die
1.6. PROBLEME BEI DER ERSTELLUNG DER ARBEIT
12
Semantik der UML formal und bildet die Basis für die Identifizierung von Konsistenzbedingungen in UML-Modellen.
In Kapitel 4 werden einleitend allgemeine Anforderungen an ein UML-Werkzeug aufgestellt. Anschließend wird definiert, wann ein UML-Modell konsistent ist. Es wird
erläutert, welche Probleme bei der Konsistenzprüfung von UML-Modellen zu beachten
sind. Anhand eines hypothetischen Werkzeugs wird erläutert, wie ein Werkzeug dem
Modellierer bei der Erstellung konsistenter UML-Modelle unterstützen kann und welche
Informationen eine Konsistenzprüfung liefern sollte. Die Modellierungsmöglichkeiten
und Konsistenzprüfungen von Rational Rose 98 werden vorgestellt.
Rational Rose 98 besitzt ein eigenes Metamodell, welches das UML-Metamodell teilweise realisiert. Anhand dieses Metamodells wird erläutert, in welchem Rahmen mit Rational Rose 98 UML-Modelle modelliert werden können und welche Konstrukte Rational
Rose 98 semantisch erkennt. Abschließend werden Konsistenzbedingungen zwischen den
Modellelementen der Klassen-, Interaktions- und Zustandsdiagramme identifiziert.
In Kapitel 5 wird die Erweiterung von Rational Rose um eine Benutzerschnittstelle
für Konsistenzprüfungen beschrieben.
1.6
Probleme bei der Erstellung der Arbeit
Die Komplexität und der formale Grad des Metamodells der UML ist größer als zu Beginn der Arbeit erwartet wurde. Daher mußte nicht nur ein weiteres (optionales) Ziel
der Arbeit, Untersuchung und Realisierung einer Codeerzeugung aus UML-Modellen,
gestrichen werden, sondern auch einige Diagrammarten. Behandelt werden Klassen, Interaktions-, Zustands- und Aktivitätsdiagramme, da zwischen den Modellelementen
dieser Diagrammarten Verbindungen existieren, die sich auf Konsistenz untersuchen lassen.
Das UML-Metamodell, und damit auch die Semantik der UML, beinhaltet selbst Inkonsistenzen. Es gab zwar in relativ kurzen Abständen korrigierte und wenig veränderte
Spezifikationen der UML, zwischen April ’99 und Juni ’99 waren es sieben, die einige
Inkonsistenzen beseitigten, aber auch Veränderungen beinhalteten und damit neue Fragen
aufwarfen. Eine Sprachspezifikation umfaßt mittlerweise knapp 800 Seiten, von denen
ungefähr die Hälfe relevant für diese Arbeit ist. Leider sind die Veränderungen zwischen
den Spezifikationsversionen kaum dokumentiert, so daß als Grundlage für diese Arbeit
die Version 1.3 beta R1 vom April 1999 gewählt wurde.
Der formale Grad des Metamodells und die Semantik der Konzepte ist bei „älteren“
Diagrammarten, z.B. Klassen- und Zustandsdiagrammen hinreichend definiert und klar,
während „neuere“ Diagrammarten, z.B. Sequenz- und Kollaborationsdiagramme, diesem
Anspruch (noch) nicht gerecht werden, d.h. das Metamodell ist in diesem Sinne nicht
vollständig.
Die Identifizierung von Konsistenzbedingungen setzt voraus, daß die Semantik der
Konzepte formal klar definiert ist. Dies ist nicht immer der Fall. Dadurch gibt es auch
13
in der benutzten Literatur, die größtenteils die Anwendung der UML beschreibt, Inkonsistenzen. Teilweise hat es den Anschein, als ob die Autoren (verständlicherweise) nach
dem Motto „Problem erkannt – Gefahr gebannt“ verfahren. Diesen Vorwurf muß sich
auch der Autor dieser Arbeit gefallen lassen. Eine Diskussion dieser Problematik würde zu Veränderungsvorschlägen des Metamodells der UML führen, die den Rahmen der
Arbeit sprengen.
Kapitel 2
Eine Übersicht
Die Unified Modeling Language ist eine Sprache zur Visualisierung, Spezifizierung, Konstruktion und Dokumentation der Bestandteile eines software-intensiven Systems. Das
Vokabular und die Grammatik dieser Modellierungssprache zielen auf die konzeptionelle und physische Darstellung von Softwaresystemen. Die graphische Darstellung von
(komplexen) Zusammenhängen erleichtert das Verständnis („ein Bild sagt mehr als tausend Worte“) und die Kommunikation über Grenzen (Programmiersprache, Sprache, Vokabular1 ) hinweg. Die UML ist aber mehr als eine reine Ansammlung von graphischen
Symbolen. Hinter jedem Symbol der UML verbirgt sich eine wohldefinierte Semantik,
so daß ein Entwickler ein Modell erstellen kann, welches ein anderer Entwickler (oder
ein Werkzeug) eindeutig identifizieren kann ([BRJ99a], Seite 15). In diesem Kontext bedeutet Spezifizierung die Erstellung präziser, eindeutiger und vollständiger Modelle. Die
Abbildung solcher Modelle auf eine Programmiersprache ermöglicht (unter bestimmten
Voraussetzungen) Codeerzeugung (forward engineering). Die UML unterstützt die Dokumentation von Softwaresystemen durch Diagramme, die bestimmte Sichten auf ein
System oder Phasen repräsentieren.
Das Vokabular der UML besteht aus Dingen, Beziehungen und Diagrammen (2.1 bis
2.3). Dinge sind die Grundbausteine in einem Modell, Beziehungen verbinden diese Dinge miteinander und Diagramme stellen durch Gruppierung bestimmter Dinge und deren
Beziehungen einen Aspekt des Systems dar. Eine Sicht auf das System besteht aus mehreren Diagrammen (2.4). Die UML ist in ein Schichtenmodell (2.5) eingebettet und besitzt
Erweiterungsmechanismen, mit denen die Sprache selbst, in einem gewissen Rahmen,
erweitert werden kann (2.6).
2.1
Dinge in der UML
In der UML gibt es vier Arten von Dingen, mit denen ein System beschrieben werden
kann: strukturelle Dinge (2.1.1), Dinge, mit denen das Verhalten beschrieben wird (2.1.2),
1
Wittgenstein: „Die Grenzen meiner Sprache sind die Grenzen meiner Welt“
14
15
KAPITEL 2. EINE ÜBERSICHT
Dinge, die der Gruppierung von Dingen dienen(2.1.3) und Anmerkungen (2.1.4).
2.1.1 Struktur
Strukturelle Dinge sind die Substantive der UML. Sie repräsentieren konzeptionelle oder
physische Elemente eines Systems und sind meist statischer Natur. Insgesamt gibt es
sieben Arten von strukturellen Elementen.
Klasse Eine Klasse beschreibt eine Menge von Objekten, die sich durch gleiche Struktur (Attribute und Beziehungen), gleiches Verhalten (Operationen) und die gleiche Semantik auszeichnen.
Eine Klasse wird als Rechteck mit ihrem Namen und optional mit ihren Attributen
und Operationen dargestellt (Abb. 2.1).
Klassenname
Attribut : Typ = Initialwert
Operation(Argumentliste) : Rückgabewert
Abbildung 2.1: Notation einer Klasse
Interface Ein Interface (Schnittstelle) ist eine Sammlung von Operationssignaturen (Name, Argumente, Rückgabetyp), die einen Dienst einer Klasse oder einer Komponente beschreiben. Die Operationen des Interface werden von der Klasse bzw. der Komponente
realisiert. Ein Interface beschreibt somit das extern sichtbare Verhalten einer Klasse bzw.
Komponente.
Ein Interface kann auf zwei Arten dargestellt werden:
1. Das Interface wird als Kreis zusammen mit dem Namen des Interface dargestellt.
Der Kreis wird mit dem Element verbunden, welches die Operationen des Interface
realisiert (Abb. 2.2). Diese Interfacedarstellung wird auch „Lolli“ genannt.
Kunde
name
adresse
speichern()
speicherbar
Abbildung 2.2: Darstellung eines Interface ohne Operationssignatur.
2.1. DINGE IN DER UML
16
2. Alternativ kann ein Interface in einem Klassenrechteck dargestellt werden (Abb.
2.3). Damit sich ein Interface von einer regulären Klasse unterscheidet, wird das
Klassenrechteck mit «interface», einem Stereotyp (siehe Seite 33), markiert. Die
Verbindung zwischen dem Interface und der Klasse wird durch eine Realisierungsbeziehung (siehe Seite 22) hergestellt.
Kunde
name
adresse
speichern()
<<Interface>>
speicherbar
speichern()
Abbildung 2.3: Ausführliche Darstellung eines Interfaces mit Operationssignatur.
Das UML-Interfacekonzept gleicht dem Interfacekonzept von Java. In Java werden
Interfaces ebenfalls durch Klassen realisiert.
Kollaboration Eine Kollaboration definiert einen Kontext für eine Interaktion und besteht aus Rollen, die von Elementen (z.B. Klassen) gespielt werden, und Beziehungen
zwischen den Rollen. Die Rollen und ihre Beziehungen werden benutzt, um ein kooperatives Verhalten darzustellen, das größer ist als die Summe der einzelnen Elemente, d.h. in
einer Kollaboration wird die Bewältigung einer Aufgabe beschrieben, zu der ein einzelnes Element nicht in der Lage ist. Eine Kollaboration hat also nicht nur eine strukturelle,
sondern auch eine verhaltensorientierte Dimension. Kollaborationen stellen die Implementierung von Mustern dar, aus denen ein System gebildet wird.
Dargestellt wird eine Kollaboration als Ellipse mit einer gestrichelten Linie, die normalerweise nur ihren Namen enthält (Abb. 2.4). Diese Darstellung ist meistens ein Platz-
Kollaborationsname
Abbildung 2.4: Kollaborationsnotation
halter für ein Interaktionsdiagramm (Seite 23), welches die notwendige Struktur und das
Verhalten zur Erfüllung der Aufgabe der Kollaboration ausführlicher darstellt.
Anwendungsfall Ein Anwendungsfall ist eine Beschreibung einer Menge von Abläufen, die ein System ausführt und die dem Benutzer (Anwender, aber auch ein externes
System) ein wahrnehmbares Ergebnis liefert. Anwendungsfälle werden benutzt um das
17
Verhalten eines Systems zu strukturieren, ohne auf die Realisierung des Verhaltens einzugehen. Das System wird hierbei als „black box“ betrachtet. Realisiert werden Anwendungsfälle durch Kollaborationen, d.h. durch die Zusammenarbeit mehrerer Elemente.
Ein Anwendungsfall wird als Ellipse mit dem Namen des Anwendungsfalls (Abb.
2.5) in einem Anwendungsfalldiagramm (z.B. Abb. 2.17, Seite 24) dargestellt. Die Abläufe selbst werden z.B. durch strukturierten Text oder mit Hilfe von Interaktions- und
Aktivitätsdiagrammen (Seite 26) spezifiziert.
Bestellung aufnehmen
Abbildung 2.5: Anwendungsfallnotation
Aktive Klasse Eine aktive Klasse ist eine spezielle Klasse, deren Objekte einen Prozeß
oder Thread oder mehrere Prozesse oder Threads besitzen, d.h. ihre Objekte repräsentieren Elemente, die nebenläufig ausgeführt werden können.
Eine aktive Klasse wird wie eine Klasse in einem Klassenrechteck dargestellt, welches
zur Unterscheidung von normalen Klassen fett umrandet wird (Abb. 2.6).
EreignisManager
aussetzen( )
verwerfem( )
Abbildung 2.6: aktive Klasse
Komponente Eine Komponente ist ein physisches und austauschbares Teil eines Systems, welches die physische Gruppierung der Realisierung logischer Elemente (z.B.
Klassen und Kollaborationen) repräsentiert.
Eine Komponente wird als Rechteck mit Streifen dargestellt (Abb. 2.7).
Ereignis
Manager.java
Abbildung 2.7: Komponente
2.1. DINGE IN DER UML
18
Knoten Ein Knoten ist ein physisches Element eines Systems und stellt meist einen
Computer mit Prozessor und Speicher dar. Ein Computer mit mehreren Prozessoren kann
durch mehrere Knoten modelliert werden. Mit Hilfe der Knoten kann z.B. die Topologie
des Rechnernetzes modelliert werden (Abb. 2.8). Den Knoten können Komponenten
zugeordnet werden.
Applikationsserver
Workstations
100 Mb Ethernet
100 Mb Ethernet
switching
Hub
10 Mb Ethernet
100 Mb Ethernet
Datenbankserver
PCs
Abbildung 2.8: Mit Knoten kann die Topologie eines Systems dargestellt werden
2.1.2
Verhalten
Verhaltensweisen beschreiben die dynamischen Aspekte eines Systems. Sie sind die Verben der Sprache. Insgesamt gibt es zwei grundlegende Arten von Verhaltensweisen in
der UML, welche die Dynamik eines Systems beschreiben: Interaktionen und (endliche)
Automaten.
Interaktion Eine Interaktion ist eine Menge von Botschaften (messages), die von Objekten in einem, durch eine Kollaboration bestimmten, Kontext ausgetauscht werden, um
ein bestimmtes Ziel oder einen bestimmten Zweck zu erfüllen. Mit einer Interaktion läßt
sich das Verhalten einer Gruppe von Objekten oder einer Operation spezifizieren. Der
Empfang einer Botschaft führt bei dem empfangenen Objekt zur Ausführung eines Verhaltens. Dies ist meist eine Operation des empfangenden Objekts, die z.B. Beziehungen
zu anderen Objekten modifiziert, Werte verändert oder Botschaften an andere Objekte
verschickt.
Eine Botschaft wird als Pfeil, gerichtet vom Sender zum Empfänger, dargestellt (Abb.
2.9). Die zu übermittelnde Information ist meistens ein Operationsname inklusive optionaler Argumente.
Chart Name : New Sequence Diagram
Chart Filename : C:\Home\Stephan\DA\VUML\seqUntitled4.Vob
Chart Type : UML Sequence Diagram
19
EventManager
«create»
Druckvorschau : Window
display
Abbildung 2.9: Botschaften in einem Sequenzdiagramm
Zustandsautomat Ein Zustandsautomat (endlicher Automat) beschreibt ein Verhalten,
das sowohl die möglichen Folgen von Zuständen eines Objekts spezifiziert, welches dieses in seiner Existenz als Reaktion auf Ereignisse durchläuft, als auch die Reaktion auf
diese Ereignisse. Mit Zustandsautomaten kann das Verhalten einer einzelnen Klasse oder
einer Operation spezifiziert werden.
Zustände werden als Rechtecke mit abgerundeten Ecken dargestellt, die den Namen
des Zustands enthalten (Abb. 2.10). An der Darstellung eines Automaten sind meistens
weitere Elemente beteiligt: Zustandsübergänge (Transitionen) als gerichtete Pfeile, Ereignisse (Auslöser eines Zustandsübergangs) und Aktivitäten als Reaktion auf einen Zustandsübergang.
satt / an den Schreibtisch setzen
essen
arbeiten
hungrig / Essen organisieren
Abbildung 2.10: Vereinfachte Darstellung der Zustände eines Diplomanden während der
Diplomarbeit
Die Zustandsautomaten bzw. Diagramme der UML basieren auf den Statecharts von
Harel. Ein UML-Zustandsautomat kann Zustände besitzen, die selbst als Zustandsautomaten angesehen werden können.
2.1.3
Gruppierung
Zur Organisation eines Modells in überschaubare Gruppen bietet die UML einen Paketmechanismus an. Ein Paket beinhaltet beliebige (logisch zusammengehörende) Modellelemente und kann somit ein Teilsystem darstellen. Die Organisation in Pakete ist allerdings nur rein konzeptionell, für die physische Aufteilung sind Komponenten und Knoten
zuständig.
Dargestellt wird ein Paket als Akte mit Reiter und dem Namen des Pakets. Alternativ
kann auch der Inhalt des Pakets dargestellt werden (Abb. 2.11).
2.2. BEZIEHUNGEN
20
applet
(from java)
+ Applet
+ AppletStub
+ AppletContext
+ AudioClip
Abbildung 2.11: Das Java-Package „applet“
2.1.4
Anmerkungen
Benutzerschnittstelle
siehe GUI.DOC
Abbildung 2.12: Notiz
Die UML kennt eine Hauptart von Anmerkungen: Notizen bzw. Kommentare. Diagramme, aber auch einzelne Modellelemente, können in der UML mit einer Notiz versehen werden.
Eine Notiz wird als Rechteck mit Eselsohr dargestellt (Abb. 2.12), welches weitere
Informationen zu einem oder mehreren Elementen enthält. Eine Notiz kann jede beliebige
Kombination von Text und Graphik enthalten, z.B. eine Web-Adresse (URL) oder ein
Verweis auf ein Dokument. Notizen geben dem Modellierer die Möglichkeit, die Modelle
mit Informationen zu versehen, die sich nicht oder nur schwer in UML ausdrücken lassen.
Der Informationsinhalt selbst hat in der UML allerdings keine Semantik.
2.2
Beziehungen
Es gibt vier Arten von Beziehungen in der UML: Abhängigkeit, Assoziation, Generalisierung und Realisierung. Von diesen Arten existieren weitere Abwandlungen und Spezialisierungen.
2.2.1
Abhängigkeit
Eine Abhängigkeit ist eine semantische Beziehung zwischen zwei Modellelementen, bei
denen sich Änderungen der Spezifikation des unabhängigen Elements auf das abhängige
Element auswirken können. Eine Abhängigkeit wird als gestrichelte Linie dargestellt, die
optional gerichtet und benannt ist (Abb. 2.13).
21
Paket-A
Paket-B
Abbildung 2.13: Paket-A ist abhängig von Paket-B
2.2.2 Assoziation
Eine Assoziation ist eine strukturelle Beziehung zwischen Klassen. Sie beschreibt eine
Menge von Objektbeziehungen, die sich durch eine gemeinsame Struktur und Semantik auszeichnen. Eine Aggregation ist eine spezielle Assoziation, welche eine „GanzesTeile“-Beziehung beschreibt. Eine Assoziation wird als Linie dargestellt, die optional
gerichtet, benannt wird und weitere Beschriftungen, wie z.B. Kardinalität und Rollennamen, enthalten kann (Abb. 2.14).
Person
Person
1..*
Arbeitgeber
Firma
*
Abbildung 2.14: Eine Person (in der Rolle als Angestellter) kann beliebig vielen Firmen
zugeordnet werden. Einer Firma (in der Rolle als Arbeitgeber) muß mindestens ein Angestellter zugeordnet sein. In dieser Beziehung spielt ein
Objekt der Klasse „Person“ die Rolle „Angestellter“ und entsprechend
ein Objekt der Klasse „Firma“ die Rolle „Arbeitgeber“. Der Rollenname
„Arbeitgeber“ wird als Pseudoattribut der Klasse „Person“ bezeichnet,
da der „Arbeitgeber“ als Merkmal einer Person angesehen werden kann.
2.2.3 Generalisierung
Eine Generalisierung (auch Vererbung genannt) ist eine Beziehung einer allgemeinen
und einer spezielleren Spezifikation eines Modellelements, in der Exemplare (Instanzen)
eines spezialisierten Elements (Sub-Element, child) durch Exemplare des verallgemeinerten Elements (Super-Element, parent) substituiert werden können. Das Sub-Element
„erbt“ auf diese Weise die Struktur und das Verhalten des allgemeineren Elements. Das
Sub-Element kann die Struktur und das Verhalten unter der Prämisse der Substituierbarkeit spezialisieren. Dieses Substitutionsprinzip garantiert, daß überall dort, wo ein
Exemplar eines allgemeinen Modellelements erwartet wird, auch ein Exemplar eines spezielleren Modellelements verwendet werden kann.
Dargestellt wird eine Generalisierung als durchgezogene Linie mit einem Dreieck als
Spitze, welches auf das allgemeinere Element zeigt (Abbildung 2.15).
2.2. BEZIEHUNGEN
22
Window
position
open()
close()
move()
display()
MessageBox
FileSelectionBox
Abbildung 2.15: Generalisierung: MessageBox und FileSelectionBox sind Unterklassen
der Klasse Window mit spezielleren Eigenschaften als die Klasse Window, können aber überall dort eingesetzt werden, wo ein Objekt der
Klasse Window erwartet wird.
2.2.4 Realisierung
Eine Realisierung stellt eine semantische Beziehung zwischen Klassifizierern (z.B. Klassen, Interfaces, Komponenten) dar, bei der ein Klassifizierer etwas spezifiziert und der andere diese Spezifikation umsetzt (Vertragscharakter). Realisierungsbeziehungen können
zwischen Interfaces und Klassen/Komponenten oder zwischen Anwendungsfällen und
Kollaborationen existieren.
Dargestellt wird eine Realisierung als gestrichelte Linie mit einem Dreieck als Spitze,
welche auf das spezifizierende Modellelement zeigt (Abb. 2.16).
Kunde
name
adresse
speichern()
<<Interface>>
speicherbar
speichern()
Abbildung 2.16: Realisierung: Die Klasse „Kunde“ realisiert das Interface „speicherbar“.
Eine Realisierung beinhaltet eine Abhängigkeit (die Klasse ist vom Interface abhängig) und eine Übertragung von Eigenschaften zwischen
den beteiligten Elementen (die Klasse „erbt“ die Operationssignaturen
des Interface). Als graphische Darstellung einer Realisierungsbeziehung
ist die Kreuzung der Darstellungen von Abhängigkeits- und Realisierungsbeziehung gewählt worden.
23
2.3
Diagramme
Ein Diagramm wird benutzt, um ein System aus einer bestimmten Sicht und unter einem
bestimmten Aspekt zu betrachten. Einige Diagramme können in verschiedenen Sichten
(siehe 2.4) benutzt werden, so daß sich hieraus Zusammenhänge zwischen den unterschiedlichen Sichten modellieren lassen. In der UML sind die folgenden neun Diagramme definiert.
2.3.1 Anwendungsfalldiagramm
Ein Anwendungsfalldiagramm (use case diagram) zeigt die Beziehungen zwischen Anwendungsfällen (use cases) und Akteuren (actors). Anwendungsfalldiagramme stellen
die statische Anwendungsfallsicht eines Systems dar. Mit Anwendungfalldiagrammen
wird das Systemverhalten organisiert und modelliert. (Abb. 2.17).
Anwendungsfälle beschreiben das Systemverhalten aus der Sicht von Akteuren (meist
Benutzer, aber auch andere Systeme), die sich in der Systemumwelt befinden und diese
Anwendungsfälle benutzen (Abb. 2.17). Anwendungsfälle werden durch Abläufe beschrieben, die angeben was das System machen soll, nicht wie die Anwendungsfälle implementiert werden. Sie dienen primär der Kommunikation zwischen den Endanwendern
bzw. den Experten des Einsatzbereichs des Systems und den Systementwicklern.
2.3.2 Klassendiagramm
Klassendiagramme sind die in einer objektorientierten Modellierung am häufigsten anzutreffenden Diagramme. Ein Klassendiagramm (Abb. 2.18) besteht im wesentlichen aus
einer Menge von Klassen, Interfaces und ihren Beziehungen. Klassendiagramme zeigen
die statische Entwurfssicht des Systems. Klassendiagramme mit aktiven Klassen zeigen
die statische Prozessicht des Systems.
2.3.3 Objektdiagramm
Ein Objektdiagramm ist eine Instantiierung von Modellelementen eines oder mehrerer
Klassendiagramme. Es enthält Objekte und Links (Exemplare einer Klasse bzw. einer
Assoziation) und zeigt eine statische Momentaufnahme des Systems (Abb. 2.19). Objektdiagramme werden benutzt, um Klassen und Beziehungen exemplarisch darzustellen.
2.3.4 Interaktionsdiagramme
Ein Interaktionsdiagramm besteht aus Objekten und zeigt, wie sie miteinander durch Botschaftenaustausch kommunizieren. Die UML bietet zwei semantisch äquivalente Interaktionsdiagramme, die jeweils einen anderen Aspekt hervorheben. Ein Sequenzdiagramm
zeigt den Botschaftenaustausch zwischen den Objekten zeitlich geordnet (Abb. 2.20),
2.3. DIAGRAMME
24
Auftragsbearbeitung
Bestellung
aufnehmen
MA-Bestellannahme
Kunde
Zahlungseingang
überwachen
Datenbank
MA-Rechnungswesen
Waren ausliefern
MA-Lager
Abbildung 2.17: Anwendungsfalldiagramm. Das Rechteck symbolisiert die Systemgrenzen.
25
Kunde
name
aktiveBestellungen( )
abgBestellungen( )
besteller
0..1
aktiveBestellung 0..*
eine Bestellung ist immer einem
Kunden zugeordnet. Entweder
als "besteller" oder als "kunde".
0..1 kunde
0..*
abgBestellung
Bestellung
bestDatum: Date
zustand: Bestellzustand
gesamtPreis( )
1 besteht aus
bestellung
BestPosition
menge: Double
position preis: Double
1..*
bestPos
Diese spezielle Form der Assoziation
heißt Komposition.
Sie ist eine Aggregation, bei der die
Teile (BestPosition) vom Ganzen
existenzabhängig sind.
artikel
0..*
1
Artikel
name
bestNr
info
Abbildung 2.18: Klassendiagramm
während ein Kollaborationsdiagramm die strukturelle Organisation der interagierenden
Objekte hervorhebt (Abb. 2.21). Die semantische Äquivalenz der beiden Interaktionsdiagramme bedeutet nicht, daß beide explizit die gleichen Informationen darstellen. Es gibt
Informationen, die nur in jeweils einem Diagramm dargestellt werden. Z.B. wird in einem
Kollaborationsdiagramm die Rückgabe der Kontrolle an ein Objekt nicht explizit gezeigt.
Die wesentliche semantische Information der beiden Diagramme ist jedoch gleich.
2.3.5 Zustandsdiagramm
Ein Zustandsdiagramm (statechart diagram) zeigt einen endlichen Automaten (siehe Seite 19, Abb. 2.10). Ein Zustandsdiagramm wird meistens benutzt, um die Reaktion einer
Klasse (genauer: der Objekte einer Klasse) auf mögliche Ereignisse zu modellieren. Zustandsdiagramme werden nur für Klassen gezeichnet, die mehrere Zustände haben. Es
ist auch möglich, das dynamische Verhalten eines Systems (oder Teilsystems) oder einer
Operation mit Zustandsdiagrammen zu modellieren.
In der UML kann ein Zustand selbst ein Zustandsautomat sein, d.h. ein Zustand kann
2.3. DIAGRAMME
26
KdObj : Kunde
kunde name = Schubert besteller
abgBestellung
BestObj-1 : Bestellung
bestDatum = 01.03.99
zustand = abgeschlossen
aktiveBestellung
bestDatum = 25.05.1999
zustand = erfassung
besteht aus
: BestPosition
menge = 1
preis = 99.90
: BestPosition
: BestPosition
: Artikel
name = UML - Das Benutzerhandbuch
bestNr = 3-8273-1486-0
Abbildung 2.19: Objektdiagramm auf Basis des Klassendiagramms (Abb. 2.18)
Unterzustände besitzen (Abb. 2.22). Es ist sogar möglich, einen Zustand aus nebenläufigen Zustandsautomaten zusammenzusetzen.
2.3.6
Aktivitätsdiagramm
Ein Aktivitätsdiagramm ist im wesentlichen ein Flußdiagramm, welches auch nebenläufige Flüsse enthalten kann. Ein Aktivitätsdiagramm ist ein Spezialfall eines Zustandsdiagramms, bei dem der Zustandsautomat größtenteils aus sogenannten Aktivitätszuständen
besteht. In einem Aktivitätsdiagramm findet im Gegensatz zu einem Zustandsdiagramm
das Verhalten innerhalb des Zustands und nicht während eines Zustandsübergangs statt2 .
Der Zustandsübergang in einem Aktivitätsdiagramm findet statt, wenn die Aktivität eines
Zustands beendet ist, d.h. die Beendigung der Aktivität stellt das Ereignis dar.
Aktivitätsdiagramme werden benutzt, um die Befehlssequenz einer Operation oder
2 Mit
der UML können auch Zustandsautomaten modelliert werden, die innerhalb eines Zustands eine
Aktivität ausführen
27
: ...
KdObj : Kunde
neueBestellung
«create» Bestellung(KdObj) BestObj-2 : Bestellung
setCurrentDate
setKunde(KdObj)
BestObj-2
addAktiveBestellung(BestObj-2)
Abbildung 2.20: Interaktion in einem Sequenzdiagramm
: ...
1.1.2: setKunde(KdObj)
1.1.1: setCurrentDate
1: neueBestellung
{new}
KdObj : Kunde
{self}
1.1: Bestellung(KdObj)
{self}
1.2: addAktiveBestellung(BestObj-2)
Abbildung 2.21: Darstellung der Interaktion aus Abb. 2.20 in einem Kollaborationsdiagramm. Die zeitliche Folge der Botschaften kann in dieser Diagrammart
durch sogenannte Sequenznummern gekennzeichnet werden.
C
C
C
2.3. DIAGRAMME
28
C
C
C
Bestellung(kunde)
aktiv
Aufnahme
autorisiere
Autorisierung
autorisiert
lieferbar
vollständig
Warten auf
Vollständigkeit
geliefert
Abbruch/BestellungStornieren
abgeschlossen
BestLöschen
Abbildung 2.22: Zustandsautomat, dessen Zustand „aktiv“ ein Zustandsautomat ist.
29
[ja]
Neuer Kunde?
[nein]
[nicht gefunden]
Kundendaten suchen
[gefunden]
Kundendaten erfragen
und eingeben
Kundendaten überprüfen
Abbildung 2.23: Dieses Aktivitätsdiagramm modelliert einen Ablauf, wie er z.B. im Anwendungsfall „Bestellung erfassen“ vorkommen könnte.
2.4. ARCHITEKTUR UND SICHTEN
30
einen Ablauf in einem Anwendungsfall zu modellieren (Abb. 2.23).
2.3.7
Komponentendiagramm
Ein Komponentendiagramm zeigt die Organisation und Abhängigkeiten einer Menge von
Komponenten. Da eine Komponente Klassen realisiert, stellt das Komponentendiagramm
eine Abbildung einer logischen Sicht (Klasse) auf eine physische Sicht (Komponente) dar
(statische Implementierungssicht). Abhängigkeiten zwischen den Komponenten zeigen,
ob sich Änderungen in einer Komponente auf andere Komponenten auswirken können.
2.3.8
Einsatzdiagramm
Ein Einsatzdiagramm (auch Verteilungsdiagramm genannt, engl. deployment diagram),
zeigt die physische Architektur der Hard- und Software (statische Einsatzschicht). In
einem Einsatzdiagramm können Computer und andere Geräte sowie ihre Verbindungen
als Knoten (siehe Seite 18, Abb. 2.8) und Linien visualisiert werden. Mit diesen Knoten
sind häufig (ausführbare) Komponenten assoziiert. Verteilungsdiagramme eignen sich zur
Visualisierung eines verteilten Systems.
2.4
Architektur und Sichten
Die Komplexität der Analyse, Entwicklung, Realisierung, Dokumentation und Tests (kurz:
Systementwicklung) eines nicht trivialen Softwaresystems erfordert die Betrachtung eines Systems aus mehreren Perspektiven (z.B. aus einer Black-Box-Sicht oder aus einer
inneren, strukturellen Sicht). Jede in einen Systementwicklungsprozeß involvierte Person (Analysierer, Designer, Tester, Benutzer, Projektmanager) betrachtet das System zu
unterschiedlichen Zeitpunkten unter einem bestimmten Aspekt (z.B. grob konzeptionell
oder detailliert). Die Architektur ist die Entscheidung über (vgl. [BRJ99b], Seite 31):
• die Organisation eines Softwaresystems
• die Auswahl der strukturellen Elemente und ihrer Schnittstellen, aus denen das System zusammengefügt wird
• das Verhalten und die Zusammenarbeit der Elemente
• die Zusammenfügung dieser Elemente in immer größere Teilsysteme
Eine solche Architektur kann durch ineinandergreifende Sichten beschrieben werden.
Eine Sicht ist eine Abstraktion, die Diagramme enthält. Jedes Diagramm wiederum hebt
einen bestimmten Aspekt hervor. So erhält man ein Bild (Modell) des gesamten Systems.
Die Entwickler der UML hatten die folgenden fünf Sichten im Sinn (vgl. [EP98], Seite
15): Anwendungsfallsicht, logische Sicht, Prozeßsicht, Komponentensicht, Verteilungssicht.
31
2.4.1 Anwendungsfallsicht
Die Anwendungsfallsicht beschreibt die Funktionalität des Systems. Diese Sicht ist für
Kunden, Entwickler und Tester gedacht und wird durch Anwendungsfall-, Interaktions-,
Zustands- und Aktivitätsdiagramme beschrieben. Die Anwendungsfallsicht nimmt unter
den Sichten eine zentrale Stellung ein, da ihr Inhalt die Grundlage für die anderen Sichten
bildet. Ziel der Systementwicklung ist es, die in der Anwendungsfallsicht beschriebene
Funktionalität zu realisieren (neben nicht-funktionalen Eigenschaften). Diese Sicht wird
auch benutzt, um das fertige System anhand der Anforderungen und gewünschten Abläufe zu verifizieren. Die statischen Aspekte dieser Sicht werden durch Anwendungsfalldiagramme und die dynamischen durch Interaktions-, Zustands- und Aktivitätsdiagramme
modelliert.
2.4.2
Logische Sicht
Die logische Sicht (Entwurfssicht) beschreibt wie die in der Anwendungsfallsicht ermittelte Funktionalität zur Verfügung gestellt wird. Diese Sicht ist hauptsächtlich für Entwickler gedacht. Im Gegensatz zur Anwendungsfallsicht zeigt diese Sicht das Innere des
Systems. Sie beschreibt die statische Struktur (Klassen, Objekte und ihre Beziehungen)
und die Kollaboration (Zusammenarbeit) von Systemelementen. Die statische Struktur
wird durch Klassen- und Objektdiagramme beschrieben, die dynamische Sicht wird durch
Zustands-, Aktivitäts- und Interaktionsdiagramme modelliert.
2.4.3
Prozeßsicht
Die Prozeßsicht modelliert mit Hilfe von Prozessen und Threads die Nebenläufigkeit und
Synchronisationsmeachnismen des Systems. Diese Sicht dient primär der Beschreibung
der Performance, Skalierbarkeit und des Durchsatzes des Systems. Die statischen und
dynamischen Aspekte der Sicht werden durch die gleichen Diagramme wie in der logischen Sicht beschrieben, jedoch mit einer Fokussierung auf aktive Klassen, da diese die
Prozesse und Threads darstellen.
2.4.4
Komponentensicht
Die Komponentensicht (Realisierungssicht, Implementationssicht) stellt die Komponenten, aus denen das Systems zusammengestellt wird, und ihre Abhängigkeiten dar. Weiter
beschreibt diese Sicht das Management der Versionsfreigaben (Releases). Die statischen
Merkmale werden in Komponentendiagrammen, die dynamischen Merkmale werden in
Interaktions-, Zustands- und Aktivitätsdiagrammen dargestellt.
2.5. VIER-SCHICHTEN METAMODELL-ARCHITEKTUR
2.4.5
32
Verteilungssicht
Die Verteilungssicht (Einsatzsicht) zeigt die physische Verteilung des Systems. In den
Diagrammen dieser Sicht wird modelliert, wie die Knoten des Systems (Computer und
andere Geräte) verbunden sind und welchen Knoten welche Komponenten zugeordnet
sind. Diese Sicht ist für Entwickler, Tester und Administratoren vorgesehen, und wird
durch Einsatzdiagramme (Verteilungsdiagramme) dargestellt.
2.5
Vier-Schichten Metamodell-Architektur
Die UML ist innerhalb eines vier-Schichten-Modells mit den folgenden Schichten (Abstraktionsebenen) definiert: Meta-Metamodell, Metamodell, Modell und Benutzermodell
(siehe [OMG99], Seite 2-5).
Schicht
MetaMetamodell
Beschreibung
Diese Abstraktionsebene wird
benutzt, um eine Sprache zur
Spezifizierung eines Metamodells zu formalisieren.
Metamodell
Ein Exemplar eines MetaMetamodells. Dieses Exemplar definiert die Sprache zur
Spezifizierung eines Modells.
Anmerkungen
Das Konzept eines „Ding“,
welches alles repräsentiert was
definiert werden kann, wird
spezifiziert. Die Objekte, über
die in dieser Ebene gesprochen
wird heißen z.B. MetaKlasse,
MetaObjekt und MetaAttribut.
Die Semantik dieser Objekte
wird in dieser Schicht festgelegt.
Jedes Konzept dieser Ebene ist
ein Exemplar eines Konzepts
des Meta-Metamodells. Objekte dieser Ebene sind z.B.
Klasse, Attribut, Operation,
Komponente. Mit Hilfe der in
der Meta-Meta-Ebene spezifizierten Sprache wird hier z.B.
festgelegt, was eine Klasse ist.
Auf dieser Abstraktionsebene
wird die UML definiert.
33
Schicht
Modell
Beschreibung
Ein Metamodellexemplar, welches eine Sprache zur Beschreibung eines Informationsbereichs definiert.
Benutzermodell,
Benutzerobjekte,
Benutzerdaten
Exemplar eines Modells. Es
definiert einen spezifischen Informationsbereich.
Anmerkungen
Diese Schicht besteht aus den
UML Modellen. In dieser Ebene befinden sich die vom Benutzer definierten Modellelemente, z.B. Kunde, getKontostand.
Modelle dieser Ebene werden
häufig Objekt- oder Instanzmodelle genannt. Objekte dieser
Ebene sind z.B. „Schmidt“ und
„Müller“.
Das UML-Metamodell wird nicht durch eine Meta-Meta-Sprache beschrieben, sondern durch die UML selbst, natürliche Sprache und formale Sprache (OCL, Objekt Constraint Language).
Diese vierschichtige Architektur ermöglicht eine Verbindung zu anderen vierschichtigen Architekturen der OMG (Object Management Group), z.B. der OMG Meta-ObjectFacility (MOF).
2.6
Erweiterungsmechanismen
Die Erweiterungsmechanismen sind in der Metamodellebene beschrieben und sind somit
Bestandteil der UML, d.h. die Benutzer der UML können diese Mechanismen benutzen,
ohne von der Existenz der Metaebene zu wissen. Drei Erweiterungsmechanismen sind im
Metamodell beschrieben: Stereotypen, Eigenschaftswerte und Zusicherungen.
2.6.1
Stereotypen
Stereotypen bieten die Möglichkeit, das Vokabular der UML zu erweitern. Unter einem
Stereotyp kann man sich einen Metatyp vorstellen, mit dem (Sprach-) Elemente der UML
auf einer höheren Ebene klassifziert werden. Z.B. könnte man Klassen, die zu einer
Benutzerschnittstelle gehören, mit dem Stereotyp «GUI» markieren. «GUI» bezeichnet
dann eine Klasse mit speziellen Eigenschaften (z.B. existieren ihre Objekte nur zur Laufzeit), bestimmter Semantik und eigener Notation (jedes Stereotyp kann durch ein eigenes
Symbol dargestellt werden). Das Stereotyp «GUI» bezeichnet somit eine andere Art einer
Klasse und ist sogesehen eine Erweiterung des Vokabulars der UML. Da ein Stereotyp auf
einem existierenden Sprachelement basiert, welches im Metamodell definiert sein muß,
sind die Erweiterungsmöglichkeiten durch Stereotypen geringer als die Möglichkeiten
gegenüber einer echten Erweiterung des Metamodells.
2.6. ERWEITERUNGSMECHANISMEN
34
In der einfachsten Form wird das Stereotyp in franz. Anführungszeichen in Kombination mit dem Basiselement dargestellt. So wurde in Abb. 2.3 das Interface als Stereotyp
einer Klasse dargestellt. Alternativ kann das Stereotyp durch ein mit dem Stereotypen
assoziierten Symbol dargestellt werden. Im Falle eines Interface ist dies ein „Lolli“ (Abb.
2.2).
2.6.2
Eigenschaftswerte
Mit Eigenschaftswerten (tagged value, gekennzeichneter Wert) kann man den Modellelementen der UML (inklusive den stereotypisierten) neue Eigenschaften hinzufügen. Ein
Eigenschaftswert ist ein Metadatum. Sein Wert bezieht sich auf das Element selbst, nicht
auf seine Instanzen. In der einfachsten Form wird ein Eigenschaftswert als Zeichenkette,
eingeschlossen von geschweiften Klammern, unter dem Namen des entsprechenden Elements dargestellt. Die Zeichenkette besteht aus einem Namen (tag, Markierung), einem
Trennzeichen „= “und einem Wert. Bei Eindeutigkeit ist der Wert ausreichend.
Beispielsweise können Modellelemente mit einer Markierung „Autor“ versehen werden, dessen Wert den Autor des Modellelements bezeichnet:
{ Autor = Schubert }.
2.6.3
Zusicherungen
Mit Zusicherungen (constraints, Einschränkungen) kann man die Semantik von Modellelementen erweitern oder bestehende Regeln ändern. Eine Zusicherung ist eine Bedingung, die eingehalten werden muß, damit das Modell konsistent bleibt. Ein Zusicherung
Person
Geschlecht : {männlich, weiblich}
+Ehemann
0..1
+Ehefrau
0..1
{self.ehefrau.geschlecht=weiblich and self.eheman.geschlecht=männlich}
Abbildung 2.24: Eine Zusicherung, formuliert in OCL (Object Constraint Language)
wird als Zeichenkette, eingeschlossen von geschweiften Klammern, nahe dem entsprechenden Element dargestellt. Die Zusicherung kann einen beliebigen Text enthalten. Zusicherungen können auch als Ersatz für eine graphische Darstellung benutzt werden (z.B.
wenn das verwendete Werkzeug eine graphische Darstellung nicht unterstützt).
Kapitel 3
Metamodell
Das Metamodell der UML besteht aus ca. 90 Metaklassen, ca. 50 Stereotypen und mehr
als 100 Metaassoziationen. Wegen dieser Komplexität ist das Metamodell hierarchisch in
mehrere logische Pakete aufgeteilt (Abb. 3.1), die jeweils zusammengehörige Elemente
enthalten.
Das Foundation-Paket (Fundament) definiert die Basis der UML. Dieses Paket enthält
die wichtigsten strukturellen Elemente (z.B. Klassen), grundlegende Verhaltensmerkmale
(Operationen und Methoden) und Datentypen, die von der UML benutzt werden. Weiter
werden in diesem Paket die Erweiterungsmechanismen der UML definiert.
Weitere Verhaltenselemente werden im Paket Behavioral Elements definiert: Anwendungsfälle, Kollaborationen, Interaktionen, Zustandsautomaten und Aktivitätsgraphen.
Im Paket Model Management wird spezifiziert, wie Modellelemente z.B. in Pakete
organisiert werden.
Im Rahmen dieser Arbeit werden die wesentlichen Pakete und Konzepte des Metamodells beschrieben. So fehlt neben dem Modell-Management-Paket auch das Konzept
der Schablonen (templates), welches z.B. von C++ benutzt wird. Die Anwendungsfälle
(Paket Use Cases) werden nicht detailliert erläutert, da sie wenig bzw. kaum formale Informationen enthalten, die in anderen Diagrammen und Sichten wiederverwendet werden
können. Die vollständige und offizielle Beschreibung befindet sich in [OMG99] bzw. den
nachfolgenden aktuelleren Dokumenten, die auf der Homepage der UML Revision Task
Force (RTF) (http://uml.systemhouse.mci.com) veröffentlicht werden.
In den folgenden Abschnitten wird vor der Definition der Elemente des Metamodells
jeweils erläutert, welche Informationen auf der Metaebene erfaßt werden müssen.
3.1
Fundament
Abbildung 3.2 illustriert das Fundament der UML. Das Kern-Paket (Core Package) definiert die Basis-Konzepte: Klassifizierer (eine Verallgemeinerung von Klassen, Interfaces, Komponenten, Knoten und Datentypen), strukturelle und dynamische Merkmale von
35
3.1. FUNDAMENT
36
Behavioral Elements
Activity Graphs
Model Management
Collaborations
Use Cases
State Machines
Common
Behavior
Foundation
Core
Extension
Mechanisms
Data Types
Abbildung 3.1: Aufteilung des UML-Metamodells in Pakete. Stärker zusammengehörige
Elemente sind in Pakete zusammengefaßt. Das Paket Model Management
enthält keine weiteren Pakete.
37
KAPITEL 3. METAMODELL
Core
Extension
Mechanisms
Data Types
Abbildung 3.2: Pakete des Fundaments und ihre Abhängigkeiten
Klassifizierern (Attribute, Operationen, Methoden) und Beziehungen (Assoziationen, Generalisierungen, Abhängigkeiten) zwischen Modellelementen. Die Erweiterungsmechanismen der UML (Stereotypen, Zusicherungen und Eigenschaftswerte) werden im Paket
Extension Mechanisms definiert. Das Paket Data Types definiert Datentypen (der Metamodellebene), die zur Definition der UML benutzt werden. Exemplare (engl. Instance)
dieser Datentypen werden von den Benutzern der UML auf der Modellebene verwendet.
3.1.1 Kern
In Abschnitt 3.1.1.1 werden abstrakte Metaklassen definiert, die als Basis für weitere
Metaklassen dienen. Abstrakte Metaklassen sind z.B. ModelElement, Feature (Merkmal) und GeneralizableElement. Sie dienen der Zusammenfassung von gemeinsamen
Merkmalen der Sprachelemente der UML. Das Konstrukt „Klassifizierer“ (Klasse, Interface usw.) wird in Abschnitt 3.1.1.2 konkretisiert. In Abschnitt 3.1.1.3 werden Assoziation und Generalisierung, und in Abschnitt 3.1.1.4 werden Abhängigkeitsbeziehungen
definiert.
3.1.1.1
Backbone
In diesem Abschnitt werden zuerst die Begriffe Klasse und Generalisierung erläutert, da
das Metamodell im wesentlichen aus einer Klassenhierarchie besteht.
Vereinfacht ausgedrückt besteht die UML aus Modellelementen, die graphisch dargestellt werden (z.B. Klassen, Beziehungen zwischen Modellelementen, Operationssignaturen). Die folgenden Erläuterungen und Beispiele zeigen die Komplexität der Zusammenhänge zwischen den Modellelementen der UML, die das Metamodell der UML erfassen
muß.
3.1. FUNDAMENT
38
Generalisierung Eine Klasse dient der Deklaration von Attributen, Operationen und
Methoden1 , die die Struktur und das Verhalten von Objekten2 beschreiben. Eine Generalisierung (Abb. 3.3) ist eine Abstraktionsmöglichkeit, die dazu dient, Ähnlichkeiten
zwischen Klassen durch allgemeinere Klassen zu beschreiben und gleichzeitig ihre Unterschiede zu erhalten. Eine Generalisierung ist eine Relation zwischen einer Klasse und
einer oder mehreren spezialisierten Versionen dieser Klasse. Ein Diskriminator ist ein
Attribut einer Generalisierung, welches die durch die Generalisierung abstrahierte Eigenschaft beschreibt. Eine Generalisierungsbeziehung kann weitere Eigenschaften besitzen,
in Abbildung 3.3 z.B. die Zusicherung disjunkt. Die Klasse, die spezialisiert wird, heißt
Oberklasse und jede spezialisierte Klasse heißt Unterklasse. Synonyme für Oberklasse
sind Basisklasse, Vorfahr, Superklasse und (engl.) parent. Synonyme für Unterklasse
sind Nachkomme, Subklasse, Kind bzw. (engl.) child.
Generalisierungsbeziehungen können auch zwischen anderen Modellelementen (z.B.
Interfaces) bestehen. Die Bezeichnungen gelten dabei entsprechend.
In Abbildung 3.3 ist Viereck eine direkte Oberklasse von Parallelogramm und eine Oberklasse von Rechteck und Quadrat. Umgekehrt ist Parallelogramm eine direkte Unterklasse von Viereck. Rechteck und Quadrat sind weitere Unterklassen von
Viereck.
Bei der Modellierung werden Merkmale wie z.B. Attribute, Operationen und die Beteiligung an Assoziatonen, die für eine Gruppe von Klassen gelten, einer Oberklasse zugewiesen und von den einzelnen (Unter-) Klassen gemeinsam genutzt. Die Unterklassen
„erben“ die Merkmale ihrer Oberklassen. Dieser Mechanismus wird Vererbung genannt.
Vererbung und Generalisierung werden häufig synonym verwandt, hier bezeichnet Generalisierung die Relation und Vererbung den Mechanismus. Andere Synonyme für Generalisierung sind Spezialisierung und Erweiterung. So wird z.B. in der Sprache Java das
Schlüsselwort extends zur Angabe der Oberklasse, von der die Unterklasse erbt, benutzt.
Die Begründung für die Benutzung des Terms „Erweiterung“ erfolgt weiter unten.
In Abbildung 3.3 besitzt die Klasse GeomFigur u.a. die Merkmale istSichtbar,
anzeigen und ist mit der Klasse Punkt assoziiert. Alle Unterklassen von GeomFigur
erben diese Merkmale.
Bei dieser Form der Assoziation wird ein Punktobjekt als existenzabhängiges Teil
einer geometrischen Figur angesehen. Dies bedeutet, daß Punkt ein Merkmal von GeomFigur ist.
Viereck kann direkte Exemplare besitzen, d.h. es kann ein konkretes Exemplar der
Klasse existieren, welches nur die Merkmale von Viereck besitzt (siehe auch Instantiierung, Seite 41). Die Operation berechneFläche ist in der Klasse GeomFigur als
abstract gekennzeichnet, da nicht vorgesehen ist, eine Operation zu implementieren,
welche die Fläche aller geometrischen Figuren berechnet. Daher kann es keine direkten
1 Operationen
und Methoden definieren Verhaltensmerkmale, die ein Objekt einer Klasse besitzt. Eine
Operation deklariert die Signatur eines Verhaltensmerkmals, Methoden implementieren das Merkmal.
2 In der UML bezeichnet ein Objekt ein Exemplar einer Klasse.
39
GeomFigur
sichtbar : Boolean
Punkt
x : Integer
+Punkt y : Integer
anzeigen()
{abstract}
entfernen()
{abstract}
bewegeRel(x : Integer, y : Integer)
berechneFläche()
{abstract}
istSichtbar() : Boolean
getX() : Integer
getY() : Integer
Diskriminator
Figurenform
{disjunkt}
Ellipse
Dreieck
Viereck
anzeigen()
entfernen()
berechneFläche()
anzeigen()
entfernen()
berechneFläche()
anzeigen()
entfernen()
berechneFläche()
Zusicherung: Eine Instanz der
Oberklasse "GeomFigur"
kann maximal zu einer
Klasse ihrer direkten
Unterklassen gehören, d.h.
nicht gleichzeitig z.B. ein
Dreieck und ein Viereck sein.
Parallelogramm
Kreis
Rechteck
Raute
Quadrat
Abbildung 3.3: Von unten nach oben betrachtet lagern Unterklassen gemeinsame Merkmale in Oberklassen aus. Von oben nach unten betrachtet erben Unterklassen die Merkmale ihrer Oberklassen. Deshalb wird diese Struktur
auch Vererbungshierarchie genannt.
3.1. FUNDAMENT
40
Exemplare der Klasse GeomFigur geben, die aus diesem Grund als abstrakte Klasse bezeichnet wird. Die Unterklassen von GeomFigur können diese Operation implementieren.
So erbt z.B. die Klasse Viereck die Deklaration der Operation berechneFläche und implementiert diese. Klassen mit dieser Eigenschaft werden konkrete Klassen genannt. Ein
direktes Exemplar einer (konkreten) Klasse ist ein indirektes Exemplar dieser Klasse und
aller Oberklassen dieser Klasse.
Das Grundprinzip, welches bei der Konstruktion von Generalisierungsbeziehungen
angewandt wird, heißt Substitutionsprinzip: Ein Exemplar einer Unterklasse kann überall
dort verwendet werden, wo ein Exemplar einer Oberklasse erwartet wird. Dieses Prinzip ermöglicht es, Methoden für eine Oberklasse zu schreiben und diese Methoden auf
Exemplare der Unterklassen anzuwenden. Nach diesem Prinzip sollte in Abbildung 3.3
z.B. die Operation berechneFläche der Klasse Viereck so implementiert werden, daß
sie auf jede Unterklasseninstanz anwendbar ist.
Eine Unterklasse kann eine Methode einer Oberklasse überschreiben, indem sie eine
Operation mit der gleichen Signatur deklariert. Zwei Operationssignaturen sind gleich,
wenn die Operationen den gleichen Namen, den gleichen Rückgabetyp sowie die gleiche
Anzahl und Reihenfolge von Parametertypen besitzen. So überschreibt z.B. die Methode berechneFläche der Klasse Quadrat die Methode ihrer Oberklasse. Dabei sollte
aber nicht die Signatur der Operation (Anzahl und Argumente einer Operation sowie der
Rückgabetyp) verändert werden. Wird die Methode berechneFläche auf ein Objekt der
Klasse Quadrat angewandt, sorgt ein Mechanismus der Implementationssprache dafür,
daß die „richtige“ Methode auf das Objekts angewandt wird (Polymorphismus). Die Bedingung der Beibehaltung der Signatur eines Merkmals (hier Operation) ermöglicht es,
den Programmcode lokal innerhalb einer Klasse zu optimieren, ohne den restlichen Code zu verändern. Daher sollte ein Merkmal niemals so überschrieben werden, daß eine
Inkonsistenz mit der Signatur oder der Semantik des ursprünglich geerbten Merkmals
entsteht. Eine Unterklasse ist eine Spezialisierung ihrer Oberklasse und sollte in jeder
Hinsicht mit ihr kompatibel sein.
Erweiterung und Einschränkung Eine Unterklasse kann den geerbten Merkmalen
neue Merkmale hinzufügen. Dies wird Erweiterung (Synonym für Spezialisierung, s.o.)
genannt. Die Erweiterung ist konsistent mit dem Substitutionsprinzip. So kann z.B. die
Klasse Kreis um das Merkmal radius erweitert werden.
Eine Unterklasse kann auch Vorfahrensmerkmale begrenzen oder einschränken (spezialisieren)3 . So unterliegen z.B. die markanten Punkte eines Quadrats einer stärkeren
Einschränkung als die eines Rechtecks. Diese Einschränkung ist konsistent innerhalb der
Vererbungshierachie, führt aber zu Problemen, wenn man z.B. eine Methode zur nichtmaßstabsgerechten Veränderung einer Figur einführt. So könnte es eine Methode geben,
mit der man einen Punkt eines Rechtecks verschiebt. Wird diese Methode auf ein Quadrat angewandt, kann das Quadrat seine „Quadrateigenschaft“ verlieren. Daher dürfen
3 In
UML werden Einschränkungen Zusicherungen (constraints) genannt
41
Operationen/Methoden, welche die Einschränkungen einer Klasse verletzen würden, aus
semantischen Gründen nicht zugelassen werden. Eine Einschränkung impliziert, daß eine
Unterklasse unter bestimmten Umständen nicht alle Operationen ihrer Oberklassen erben
kann. Diese Operationen müssen vom Designer spezifiziert werden (vgl.[R+ 93], Seite
78).
Deskriptor und Vererbungsmechanismus Jedes Objekt wird durch einen vollständigen Klassendeskriptor beschrieben. Ein vollständiger Deskriptor enthält eine Beschreibung aller Attribute, Assoziationen und Operationen, die das Exemplar enthält.
In einer objektorientierten Sprache wird die Beschreibung eines Objekts inkrementell aus mehreren Segmenten, entsprechend der Vererbungshierarchie, aufgebaut. Jedes
(generalisierbare) Modellelement enthält eine Liste (Segmentdeskriptor) von Merkmalen
und Beziehungen, die es den geerbten Merkmalen und Beziehungen hinzufügt. Der Vererbungsmechanismus definiert, wie ein Deskriptor aus den Segmentdeskriptoren erzeugt
wird. Jedes Modellelement vererbt Zusicherungen. Klassen vererben u.a. Attribute, Operationen, Methoden und die Teilnahme an Assoziationen. Ein vollständiger Deskriptor
eines Exemplars enthält die Vereinigung des Segment-Deskriptors seiner Klasse mit den
Segment-Deskriptoren der Vorfahrensklassen.
Bei einem Klassifizierer darf kein Attribut in mehr als einem Segment deklariert werden. Eine Methode kann in mehreren Segmenten deklariert werden. Eine Methode eines
Segments überschreibt und ersetzt eine Methode der gleichen Signatur, die durch einen
Vorfahren deklariert wurde. Die Zusicherungen eines vollständigen Deskriptors ergeben
sich entsprechend aus den Zusicherungen der Vorfahren. Sind die Zusicherungen inkonsistent, dann ist es auch das Modell. In jeder Vereinigung der Segmentdeskriptoren einer
Klasse muß zu jeder Methode eine entsprechende Operation existieren. Im Falle einer
konkreten Klasse muß zu jeder Operation des vollständigen Deskriptors eine entsprechende Methode existieren.
Instantiierung Ein Modell dient zur Beschreibung der möglichen Zustände eines Systems und dessen Verhaltens. Der Zustand eines Systems beinhaltet Objekte, Werte und
Links (Verknüpfungen). Eine Instantiierung ist das Erzeugen eines Exemplars (bzw. einer
Instanz). Ein Objekt ist ein Exemplar einer Klasse, ein Wert ist ein Exemplar eines Attributs und ein Link ist ein Exemplar einer Assoziation. Jedes Objekt wird durch einen vollständigen Klassendeskriptor beschrieben. Die Klasse, die diesem Deskriptor entspricht,
ist die direkte Klasse des Objekts. Ebenso hat jeder Link eine direkte Assoziation und
jeder Wert einen direkten Datentyp. Ein Exemplar ist ein direktes Exemplar eines Klassifizierers (z.B. Klasse, Komponente), von dem der vollständige Deskriptor stammt. Ein
Exemplar ist ein indirektes Exemplar dieses Klassifizierers und jeder seiner Vorfahren.
Der Dateninhalt eines Objekts enthält für jedes Attribut des vollständigen Deskriptors
einen Wert. Der Wert muß konsistent zum Typ des Attributs sein.
Der Dateninhalt eines Links enthält eine Liste von Exemplaren, die indirekte Exem-
3.1. FUNDAMENT
42
plare jedes teilnehmenden Klassifizierers des vollständigen Assoziationsdeskriptors sind
(Abb. 3.4).
Quadrat1 : Quadrat
Punkt1 : Punkt
Abbildung 3.4: Visualisierung eines Links. Quadrat1 ist eine indirektes Exemplar von
Quadrat, Rechteck, Parallelogramm, Viereck und GeomFigur
Der Zustand eines Systems ist ein gültiger Systemzustand, wenn jedes Exemplar ein
direktes Exemplar eines Elements des Systemmodells ist und alle Zusicherungen des Modells von den Exemplaren erfüllt werden. Mit den Verhaltenselementen der UML können
Sequenzen gültiger Systemzustände beschrieben werden.
Klasse Eine Klasse deklariert Attribute, Operationen und Methoden, die die Struktur
und das Verhalten von Objekten vollständig beschreiben. Alle Objekte einer Klasse haben
Attributwerte und Operationen, die zum vollständigen Klassendeskriptor passen.
Wenn eine Klasse zur Erzeugung eines neuen Objekts instantiiert wird, wird dieses
Objekt mit einem Attributwert für jedes Attribut aus dem vollständigen Klassendeskriptor
initialisiert. Das Objekt wird ebenfalls mit einer Verbindung zu einer Liste von Methoden
des Klassendeskriptors initialisiert und am Ende wird die Identität des neuen Objekts an
den Erzeuger übermittelt. Die Identität jedes Exemplars in einem wohlgeformten System
ist einmalig und wird automatisch erzeugt.
Wird eine Klasse als root spezifiziert, kann sie keine Unterklasse einer anderen Klasse sein, wird sie als leaf spezifiziert, kann sie keine Oberklasse sein.
Der Gültigkeitsbereich (ownerScope) eines Merkmals einer Klasse gibt an, ob jedes
Objekt einen eigenen Wert für dieses Merkmal besitzt (instance) oder ob es nur einen
Wert des Merkmals für alle Objekte der Klasse gibt (classifier)4 .
Jedes deklarierte Attribut einer Klasse hat eine Sichtbarkeit und einen Typ. Die Sichtbarkeit gibt an, ob das Attribut von Objekten anderer Klassen „gesehen“ und benutzt werden kann. Das Attribut kann für jede Klasse (public), nur für Unterklassen (protected)
oder nur innerhalb der deklarierenden Klasse selbst (private) sichtbar sein.
Der Typ eines Attributs spezifiziert dessen Wertebereich. Ein Attribut kann DefaultWerte deklarieren und festlegen, wie viele Attributwerte mit jedem Attribut verbunden
werden (Kardinalität). Die Modifizierbarkeit der Attributwerte kann angegeben werden. Die Modifizierbarkeit kann uneingeschränkt sein (changeable), unterbunden werden (frozen) oder derart eingeschränkt werden, daß nur noch Attributwerte hinzugefügt
werden können5 (addOnly).
4 classifier
5 Bei
entspricht „static“ in C++.
einer Kardinalität der Attribute > 1.
43
Für jede Operation werden der Name der Operation, die Typen der Parameter, die
Rückgabetypen sowie ihre Sichtbarkeit angegeben. Eine Operation kann die Spezifikation ihrer Effekte beinhalten. Diese Spezifikation kann auf verschiedene Arten beschrieben
werden, z.B. durch Vor- und Nachbedingungen, Pseudo-Code oder (beliebigen) Text. Zu
einer Operation kann angegeben werden, ob ihre Anwendung den Zustand eines Objekts
ändert (isQuery) und ob die Operation in Unterklassen durch eine andere Methode realisiert werden kann.
Eine Methode realisiert eine Operation, besitzt die gleiche Signatur wie die Operation und einen Rumpf, der die Spezifikation realisiert. Jede Methode implementiert eine
Operation, die in der Klasse oder in einem Vorfahren der Klasse deklariert wurde. Eine
Operation kann mehrfach in den Segmentdeskriptoren der Klasse und ihren Vorfahren deklariert werden. Dabei muß die Beschreibung der Operation, mit Ausnahme der Generalisierungseigenschaften (isAbstract, isRoot, isLeaf) und der isQuery-Eigenschaft,
die von Nachkommen verschärft werden darf, mit der Beschreibung in den Segmentdeskriptoren übereinstimmen. Eine Methode, die eine Operation implementiert, muß die
gleiche Signatur (Name, Parameteranzahl, -folge und -typen) wie die Operation besitzen
und die isQuery-Eigenschaft beachten.
Der einer Klasse in einer Assoziation gegenüberliegende Rollenname kann als Pseudoattribut der Klasse angesehen werden. Für dieses Pseudoattribut wird wie bei einem
normalen Attribut eine Sichtbarkeit spezifiziert. Unter Berücksichtigung dieser Sichtbarkeit wird die Assoziation an Unterklassen vererbt.
Ein Interface ist ein generalisierbares Modellelement, welches eine Sammlung von
Operationssignaturen enthält. Eine Klasse kann Interfaces realisieren. Dies bedeutet, daß
jede Operation aus dem vollständigen Deskriptor eines Interfaces für jedes realisierte Interface im vollständigen Deskriptor der Klasse mit der gleichen Signatur existieren muß.
Ein Interface kann durch mehrere Klassen realisiert werden, d.h. die Operationen eines
Interfaces werden in mehreren Klassen mit der gleichen Signatur deklariert und implementiert.
Eine Klasse kann andere Elemente, z.B. Klassen, Interfaces und Assoziationen, enthalten und ist für diese Elemente ein Namensraum. Der Inhalt einer Klasse, der an eine
andere Klasse vererbt wird, hängt von der Sichtbarkeit (public, protected, private)
der enthaltenen Elemente ab.
Im folgenden werden die Klassen des Backbones (Abb. 3.5) vorgestellt und erläutert.
Element Ein Element (Abb. 3.6) ist ein atomarer Bestandteil eines Modells. Im Metamodell ist Element die oberste Metaklasse in der Metaklassenhierarchie. Element ist
eine abstrakte Metaklasse mit zwei direkten Unterklassen: ModelElement und PresentationElement.
StructuralFeature
Attribute
initialValue : Expression
multiplicity : Multiplicity
changeability : ChangeableKind
targetScope : ScopeKind
*
Operation
{ordered}
1
1
+type
Namespace
BehavioralFeature
+owner
0..1
+namespace
*
+ownedElement
+specification
1
isQuery : Boolean
+feature
concurrency : CallConcurrencyKind
isRoot : Boolean
isLeaf : Boolean
isAbstract : Boolean
*
ownerScope : ScopeKind
visibility : VisibilityKind
Feature
ElementOwnership
name : Name
*
Classifier
Method
Parameter
*
defaultValue : Expression
kind : ParameterDirectionKind
{ordered}
+constrainedElement
1..*
body : ProcedureExpression
0..1
1 +type
isRoot : Boolean
isLeaf : Boolean
GeneralizableElement
ModelElement
Element
*
{ordered}
+parameter
Constraint
body : BooleanExpression
*
+constraint
3.1. FUNDAMENT
44
Abbildung 3.5: Backbone: Dieses Diagramm zeigt die allgemeinsten Klassen des Metamodells. Klassen, deren Klassenname kursiv dargestellt werden, sind
abstrakte Klassen. Exemplare konkreter Klassen sind Sprachelemente,
die auf der Modellebene sichtbar sind.
45
Element
ModelElement
name : Name
+subject
*
+presentation
PresentationElement
*
Abbildung 3.6: Element, die allgemeinste Klasse im Metamodell
Jedes Element besitzt den vordefinierten Eigenschaftswert documentation:
Eigenschaftswert
Semantik
documentation
Ein Kommentar, eine Beschreibung oder eine Erläuterung des
Elements
PresentationElement Ein Präsentationselement (Abb. 3.6) repräsentiert ein oder
mehrere Modellelemente, die durch Text oder Graphik dargestellt werden. Die abstrakte
Metaklasse PresentationElement ist die Basis aller Metaklassen, die der Präsentation
dienen. Die (nicht definierten) Unterklassen von PresentationElement sind für die
Benutzung durch ein Werkzeug vorgesehen.
Im folgenden wird mit Pseudoattribut der Rollenname der gegenüberliegenden Klasse
einer Assoziation bezeichnet.
Pseudoattribut
Semantik
subject
Bezeichnet ein Modellelement, welches durch das Präsentationselement dargestellt wird.
ModelElement Ein Modellelement ist eine Abstraktion eines Elements des zu modellierenden Systems. Die abstrakte Metaklasse ModelElement ist die Basis für alle Metaklassen, die der Modellierung dienen.
Attribut
Semantik
name
Name des Modellelements innerhalb seines Namensraums
Pseudoattribut
presentation
Semantik
(Abb. 3.6) Bezeichnet ein Präsentationselement, welches das
Modellelement darstellt.
3.1. FUNDAMENT
Pseudoattribut
namespace
constraint
46
Semantik
(Abb. 3.7) Bezeichnet den Namensraum, der das Modellelement enthält. Jedes Modellelement mit Ausnahme eines „Wurzelelements“ muß entweder zu genau einem Namensraum gehören oder ein Teil eines anderen Modellelements (virtueller
Namensraum) sein.
(Abb. 3.8) Zusicherung, die das Modellelement erfüllen muß,
damit das Modell wohldefiniert ist.
ModelElement
name : Name
+ownedElement
*
ElementOwnership
+namespace
0..1
Namespace
Abbildung 3.7: Namensraum
Namespace Ein Namensraum (Abb. 3.7) ist ein ModelElement und enthält beliebig
viele Modellelemente. Die Namen dieser Modellelemente, ausgenommen Assoziationen
und Generalisierungen, müssen innerhalb ihres Namensraums eindeutig sein.
Jede Assoziation muß eine eindeutige Kombination des Assoziationsnamens und der
beteiligten Klassifizierer sein. Jedes Modellelement gehört zu maximal einem Namensraum.
Die Assoziationsklasse (siehe 3.1.1.3) ElementOwnership in Abb. 3.7 ist eine Eigenschaft der Assoziation zwischen ModelElement und Namespace. Sie gibt an, ob
das Modellelement außerhalb seines Namensraums sichtbar ist (public, protected,
private).
Namespace ist eine abstrakte Metaklasse, deren Unterklassen (z.B. Class) zusätzliche
Einschränkungen bzgl. der Art der enthaltenen Modellelemente besitzen.
Pseudoattribut
Semantik
ownedElement
Modellelemente, die zum Namensraum gehören.
47
Constraint Eine Zusicherung (Abb. 3.8) ist eine an ein Modellelement geheftete Bedingung oder Einschränkung, die durch einen Text (Formalisierungsgrad beliebig)
beschrieben wird (siehe auch 3.1.2 Erweiterungsmechanismen). Im Metamodell ist ei-
ModelElement
name : Name
1..*
+constrainedElement
{ordered}
*
+constraint
Constraint
Abbildung 3.8: Zusicherung
ne Zusicherung ein mit einem Modellelement assoziierter boolescher Ausdruck (body).
Die Zusicherung gilt, wenn der Ausdruck als wahr ausgewertet wird. Ansonsten ist das
Modell nicht wohldefiniert. Zu einer Zusicherung gehört mindestens ein zugesichertes
Element (constraindedElement). Mehrere Modellelemente einer Zusicherung sind geordnet ({ordered}). Ein Modellelement kann mit beliebig vielen Zusicherungen assoziiert sein. Ausnahme: Eine Zusicherung kann nicht auf sich selbst angewandt werden.
Die folgenden Stereotypen einer Zusicherung sind in der UML definiert, weitere können von den Benutzern hinzugefügt werden.
Stereotyp
«invariant»
«postcondition»
«precondition»
Semantik
Eine Zusicherung, die an mehrere Klassifizierer und Beziehungen geheftet wird und immer gelten muß.
(Nachbedingung) Zusicherung, die an eine Operation angeheftet wird und nach der Ausführung der Operation gelten muß.
(Vorbedingung) Zusicherung, die an eine Operation angeheftet
wird und vor der Ausführung der Operation gelten muß.
GeneralizableElement Ein verallgemeinerbares Element (Abb. 3.9) ist ein Modellelement, welches an einer Generalisierungsbeziehung teilnehmen kann (siehe auch
Abb. 3.23, Seite 63).
3.1. FUNDAMENT
48
ModelElement
+ownedElement name : Name
ElementOwnership
*
+namespace
0..1
Namespace
isRoot : Boolean
isLeaf : Boolean
Feature
+feature
Classifier
*
{ordered}
+owner
1
Abbildung 3.9: verallgemeinerbares Element und Klassifizierer
Attribut
isAbstract
isLeaf
isRoot
Semantik
Falls wahr, besitzt das verallgemeinerbare Element keine direkten Exemplare.
(Blatt) Falls wahr, darf das Element nicht weiter spezialisiert
(vererbt) werden.
(Wurzel) Falls wahr, kann das Element keine Spezialisierung
eines anderen Modellelements sein.
Classifier Ein Klassifizierer ist ein Modellelement, welches Verhaltens- und Strukturmerkmale beschreibt (Abb. 3.9, 3.10). Beispiele für Klassifizierer sind Klassen, Interfaces und Komponenten.
Im Metamodell ist ein Klassifizierer ein Namensraum und ein verallgemeinerbares
Element, welches Merkmale (feature) enthalten kann. Als verallgemeinerbares Element
kann es Merkmale und die Teilnahme an Assoziationen (ver-)erben. Ein Klassifizierer
kann in seiner Eigenschaft als Namensraum Klassifizierer (auch verschachtelt) enthalten.
Auf die enthaltenen Klassifizierer können andere Klassifizierer nur unter Berücksichtigung der Sichtbarkeit des Namensraum zugreifen (ElementOwnership).
Kein Verhaltensmerkmal der gleichen Art6 eines Klassifizieres darf die gleiche Signatur besitzen. Rollennamen einer Assoziation des Klassifizierers7 werden als Pseudoattri6 Operationen
7 auf
und Methoden sind verschiedene Arten eines Verhaltensmerkmals
der gegenüberliegenden Seite eines Klassifizierers
49
bute angesehen. Die Menge der Attributnamen, der Pseudoattributnamen und die Namen
der enthaltenen Modellelemente eines Klassifizierers müssen eindeutig sein (hierzu gehören auch geerbte Modellelemente). Zu jeder als nicht-abstrakt spezifizierten Operation
des Klassifizierers muß der Klassifizierer eine Methode mit der spezifizierten Signatur
enthalten.
Mehrere Stereotypen und Eigenschaftswerte eines Klassifizierers sind definiert:
Stereotyp
«metaclass»
«powertype»
«process»
«thread»
«utility»
Eigenschaftswert
persistence
semantics
Semantik
(Metaklasse) Bezeichnet einen Klassifizierer, dessen Exemplare Klassen sind.
(Metatyp) Bezeichnet einen Typ, dessen Exemplare Untertypen eines anderen Klassifizierer sind.
(Prozeß) Ein Klassifizierer, der eine aktive Klasse und einen
Prozeß darstellt. Ein Prozeß kann nebenläufig mit anderen
Prozessen ausgeführt werden und besitzt einen eigenen Kontrollfokus.
Ein Klassifizierer, der eine aktive Klasse und einen Thread darstellt. Ein Thread kann nebenläufig innerhalb eines Prozesses
ausgeführt werden. Ein Thread besitzt einen eigenen Kontrollfokus, aber keinen eigenen Adressraum.
(Dienstklasse, Hilfsmittelklasse) Klassifizierer, dessen Attribute und Operationen alle die Klasse als Gültigkeitsbereich
haben ([BRJ99a], Seite 148). Hilfmittelklassen sind keine
echten Klassen, sondern Sammlungen von globalen Variablen
und Funktionen, die aber in Form einer Klasse notiert werden
([Oes98], Seite 230).
Semantik
Der Wert persistent (lat.: „anhaltend“) besagt, das die Lebensdauer der Exemplare des Klassifizieres über die Laufzeit
des Programms hinausreicht und gespeichert werden sollten.
transient bedeutet nicht persistent.
Spezifiziert die Semantik des Klassifzierers.
Feature Ein Merkmal ist eine Eigenschaft eines Klassifizierers, z.B. ein Attribut oder
eine Operation. Ein Merkmal (Abb. 3.10) hat einen Namen, der zur Identifizierung innerhalb eines Klassifizierers oder eines Exemplars dient. Ein Merkmal gehört zu genau
einem Klassifizierer (owner). Das Attribut ownerScope gibt an, ob jedes Exemplar ei-
3.1. FUNDAMENT
50
nes Klassifizierers eigene Werte für dieses Merkmal hat oder ob es genau einen Wert für
dieses Merkmal gibt, der dann für alle Exemplare des Klassifizierers gilt. Das Attribut
visibility spezifiziert, ob andere Klassifizierer das Merkmal sehen und benutzen oder
erben können. Feature ist eine abstrakte Metaklasse.
Attribut
ownerScope
visibility
Semantik
instance: Jedes Exemplar des Klassifizierers hat seinen eigenen Wert für dieses Merkmal.
classifier: Es gibt nur einen Wert für alle Exemplare eines
Klassifizierers.
public: Jeder andere Klassifizierer (mit Sichtbarkeit auf den
Klassifizierer) kann dieses Merkmal benutzen.
protected: Jeder Nachkomme des Klassifizierers kann dieses
Merkmal benutzen.
private: Nur der Klassifizierer selbst kann das Merkmal benutzen.
ModelElement
name : Name
Classifier
1
+owner
+type
1
Feature
+feature visibility : VisibilityKind
{ordered}
*
*
BehavioralFeature
isQuery : Boolean
StructuralFeature
Attribute
Operation
concurrency : CallConcurrencyKind +specification
isRoot : Boolean
isLeaf : Boolean
1
Abbildung 3.10: Merkmale
*
Method
body : ProcedureExpression
51
StructuralFeature Ein strukturelles Merkmal (Abb. 3.10) ist eine statische Eigenschaft eines Modellelements. Im Metamodell der UML (Version 1.3) ist Attribute
die einzige Unterklasse von StructuralFeature. Ein strukturelles Merkmal besitzt eine Kardinalität (multiplicity), die die Anzahl dieses Merkmals eines Modellelements
angibt, z.B. kann das Merkmal „IP-Adresse“ eines Computers eine Kardinalität > 1 besitzen. Der Wertebereich eines strukturellen Merkmals wird durch einen Typ (type) spezifiziert. Dieser Typ kann z.B. auf der Modellebene eine benutzerdefinierte Klasse oder ein
Exemplar eines in UML definierten Datentyps (siehe 3.1.3) sein. Die Modifizierbarkeit
(changeability) gibt an, ob der Wert des Merkmals verändert werden kann, nachdem
das Exemplar erzeugt wurde. StructuralFeature ist eine abstrakte Metaklasse.
Attribut
Semantik
multiplicity
Gibt die Häufigkeit des Merkmals an.
changeability
changeable: keine Einschränkungen (default)
frozen: Der Wert kann nicht mehr geändert werden, nachdem
das Exemplar instantiiert und der Wert initialisiert wurde. Weitere Werte können nicht hinzugefügt werden.
addOnly: Nur von Bedeutung, wenn die Kardinalität > 1 ist.
Weitere Werte dürfen hinzugefügt werden, aber kein Wert darf
verändert oder entfernt werden.
targetScope
instance: (default) Jeder Wert enthält eine Referenz auf ein
Exemplar des Typs.
classifier: Jeder Wert enthält eine Referenz auf einen Klassifizierer. Auf diese Weise können Metainformationen gespeichert werden.
Pseudoattribut
type
Semantik
Bezeichnet einen durch einen Klassifizierer beschriebenen
Wertebereich des Merkmals. Exemplare des Klassifizierers bilden die Attributwerte. Der Klassifizierer muß eine
Klasse (Class), ein Datentyp (DataType) oder ein Interface
(Interface) sein. Zur Laufzeit kann der aktuelle Typ auch
ein Nachkomme sein. Der aktuelle Typ eines Interfaces ist zur
Laufzeit ein Klassifizierer, der dieses Interface realisiert.
Die Typen sollten im Namensraum des Besitzers des Merkmals
sein.
Attribute Ein Attribut ist ein benanntes Fach innerhalb eines Klassifizierers und beschreibt einen Wertebereich. Im Metamodell ist Attribute ein Teil eines Klassifizierers,
welches einen Namen besitzt (geerbt von ModelElement) und mögliche Zustände, die
Exemplare des Klassifizierers annehmen können, durch einen Wertebereich (type, geerbt
von StructuralFeature) beschreibt.
3.1. FUNDAMENT
Attribut
initialValue
52
Semantik
Ausdruck, der den Wert des Attributs bei seiner Initialisierung
bestimmt.
ModelElement
name : Name
Classifier
+type
1
Parameter
defaultValue : Expression
* kind : ParameterDirectionKind
+parameter *
{ordered}
0..1
BehavioralFeature
isQuery : Boolean
Abbildung 3.11: Parameter
BehavioralFeature Ein Verhaltensmerkmal (Abb. 3.10, 3.11) ist ein dynamisches Merkmal eines Klassifizierers, z.B. eine Operation oder eine Methode. Das Attribut isQuery gibt an, ob die Ausführung/Anwendung des Merkmals den Zustand des
Systems unverändert läßt. Ein Verhaltensmerkmal kann eine geordnete Liste von Parametern besitzen, die das Verhalten des Merkmals beeinflußen können. Die Parameter sollten
unterschiedliche Namen haben und ihre Typen sollten zum Namensraum des Klassifizierers gehören. Ein Verhaltensmerkmal besitzt eine Signatur, die aus dem Namen des
Verhaltensmerkmals und aus der Anzahl, Art und Reihenfolge der Parameter besteht.
BehavioralFeature ist eine abstrakte Metaklasse.
Attribut
Semantik
isQuery
Falls wahr, verändert die Anwendung des Merkmals den Zustand des Klassifizierers nicht, d.h. der Systemzustand bleibt
ebenfalls unverändert. isQuery wird benutzt, um Abfragen
bzw. reine Funktionen, d.h. Funktionen ohne Seiteneffekte, zu
markieren.
53
Pseudoattribut
parameter
Semantik
Geordnete Liste von Parametern.
Zwei Stereotypen eines Verhaltensmerkmals sind in der UML definiert:
Stereotyp
Semantik
«create»
Erzeugt ein Exemplar des Klassifizierers.
«destroy»
Zerstört ein Exemplar des Klassifizierers.
Operation Eine Operation (Abb. 3.10) spezifiziert einen Dienst, der von Exemplaren
eines Klassifizierers ausgeführt bzw. angefordert werden kann. Eine Operation hat eine
Signatur, die aus dem Namen der Operation (geerbt von ModelElement) und Parametern
besteht.
Im Metamodell ist eine Operation ein Verhaltensmerkmal, welches auf die Exemplare
des deklarierenden Klassifizierers angewandt werden kann.
Das Attribut concurrency (Nebenläufigkeit) spezifiziert die Semantik von nebenläufigen Aufrufen des gleichen passiven Exemplars (die die untersuchte Operation enthält).
Aktive Exemplare kontrollieren den Zugriff auf ihre Operationen selbst8 .
Attribut
concurrency
8 Ein
Semantik
sequential: (sequentiell) Aufrufer der Operation müssen außerhalb des Exemplars koordiniert werden. Die Operation darf
während der Ausführung nicht nocheinmal aufgerufen werden.
Dies gilt für die Gesamtheit der sequentiellen Operationen eines Exemplars, d.h. es dürfen auch nicht gleichzeitig zwei
verschiedene sequentielle Operationen aufgerufen werden. Im
Falle simultaner Aufrufe ist die Semantik und Integrität des
Exemplars (und damit des Systems) nicht gewährleistet.
guarded: (überwacht) Gleichzeitige Aufrufe einer Operation
eines Exemplars von nebenläufigen Threads sind zugelassen,
aber nur eine Anforderung wird zu einem Zeitpunkt bearbeitet, die anderen werden bis zur vollständigen Ausführung der
Operation blockiert. Die Verhinderung von Deadlocks liegt
in der Verantwortlichkeit des Systemdesigners. Im Falle der
gleichzeitigen Ausführung sequentieller Operationen müssen
die überwachten Funktionen korrekt ausgeführt werden bzw.
müssen sie sich selbst blockieren.
aktives Exemplar ist ein Exemplar einer aktiven Klasse
3.1. FUNDAMENT
Attribut
isAbstract
isLeaf
isRoot
54
Semantik
concurrent: (nebenläufig) Wie überwachte Operationen, nur
werden die Operationen in diesem Fall sogar nebenläufig ausgeführt. Nebenläufige Operationen müssen so entworfen werden, daß sie im Falle nebenläufiger sequentieller oder überwachter Operationen korrekt ausgeführt werden.
Falls wahr, implementiert der deklarierende Klassifizierer die
Operation nicht. Die Operation muß von einem Nachfahren
implementiert werden.
Falls wahr, kann die Implementation von keinem Nachfahren
überschrieben werden.
Falls wahr, kann die Klasse eine Deklaration dieser Operation
mit der gleichen Signatur nicht erben.
Method Eine Methode (Abb. 3.10) ist die Implementation einer Operation. Im Metamodell ist eine Methode ein benanntes Verhaltensmerkmal eines Klassifizierers und realisiert/implementiert eine Operation (body). Eine Methode wird durch eine Operation spezifiziert (specification). Eine Operation kann mehrere Methoden spezifizieren. Die
Signaturen der Operation und der Methode müssen übereinstimmen. Falls die Operation als „query“ markiert ist, muß die Methode eine reine Funktion (ohne Seiteneffekte)
sein. Die Sichtbarkeit der Methode sollte mit der Sichtbarkeit der Operation übereinstimmen. Eine Operation muß ein (geerbtes) Merkmal des Klassifizierers sein, der dieses
implementiert. Wenn die Operation von den Vorfahren des Besitzers der Methode bereits
überschrieben wurde, muß die Methode die letzte Überschreibung realisieren.
Parameter Parameter (Abb. 3.11) werden zur Spezifikation der Verhaltensmerkmale
von Klassifizierern benutzt. Im Metamodell beschreibt ein Parameter die Deklaration
eines Arguments, welches an eine Operation o.ä. übergeben wird. Jeder Parameter hat
(als Modellelement) einen Namen. type gibt den Typ (ein Klassifizierer) des Parameters
an. Aus Sicht eines Verhaltensmerkmals sind die Parameter geordnet (Liste).
Attribut
Semantik
kind
in: Eingabeparameter, der Wert darf nicht verändert werden.
out: Ausgabeparameter, der Wert kann verändert werden, um
Informationen zum Aufrufer zu liefern.
inout: Ein modifizierbarer Eingabeparameter.
return: Rückgabeparameter.
defaultValue
Ausdruck, dessen Wert genutzt wird, falls kein Argument übergeben wird.
55
Classifier
Class
DataType
isActive : Boolean
+deploymentLocation
Interface
*
Node
*
Component
+resident
+implementation
*
ElementResidence
*
+resident
ModelElement
name : Name
Abbildung 3.12: Klassifizierer
3.1.1.2
Klassifizierer
In diesem Abschnitt werden die Klassifizierer Klasse, Interface, Datentyp, Knoten (node)
und Komponente beschrieben. Es gibt weitere Klassifizierer (z.B. Anwendungsfall), die
in anderen Paketen des Metamodells beschrieben sind.
Class Eine Klasse ist eine Beschreibung einer Menge von Objekten, die sich durch
gemeinsame Attribute, Operationen, Methoden, Beziehungen und Semantik auszeichnen.
Attribut
Semantik
isActive
true: Die Klasse ist eine aktive Klasse, d.h. ein Objekt der
Klasse kontrolliert den Zugriff auf seine Operationen und Attribute selbst. Das Objekt besitzt einen eigenen Kontrollfokus
und ist nebenläufig mit anderen aktiven Objekten.
false: (default) Die Klasse ist keine aktive Klasse.
isAbstract
(geerbt von GeneralizableElement)
true: Die Klasse kann nicht instantiiert werden.
3.1. FUNDAMENT
Stereotyp
«type»
«implementationClass»
56
Semantik
Ein Typ ist eine Klasse, die einen Bereich von Exemplaren
(Wertebereich) zusammen mit Operationen, die auf diese Exemplare anwendbar sind, definiert. Ein Typ kann Attribute und
Assoziationen, aber keine Methoden enthalten.
Bezeichnet eine Klasse, die kein Typ sondern die Implementation einer Klasse in einer Programmiersprache repräsentiert.
Ein Exemplar kann maximal zu einer Implementationsklasse
gehören. Dies ist ein Unterschied zu normalen Klassen, bei
denen ein Exemplar zu mehreren Klassen gehören kann (sowohl statisch, als auch dynamisch).
Interface Der Zweck eines Interface ist die Sammlung von Operationen, die einen
Dienst spezifizieren, der von Klassifizierern angeboten wird. Interfaces bieten einen Weg
zur Charakterisierung von Gruppen von Operationen.
Ein Interface ist eine Sammlung von öffentlichen (public) Operationen. Ein Interface kann nicht direkt instantiiert werden. Instantiierbare Klassifizierer können Interfaces
zur Spezifizierung verschiedener Dienste, die von ihren Exemplaren angeboten werden,
benutzen. Mehrere Klassifizierer können das gleiche Interface realisieren. Ein Interface
kann als generalisierbares Element eine Spezialisierung anderer Interfaces sein und an
Assoziationen teilnehmen, vorausgesetzt, es kann die Assoziation nicht sehen (es kann
nicht vom Interface wegnavigiert werden, siehe 3.1.1.3 AssociationEnd). Z.B. kann eine Klasse mit einem Interface assoziiert sein, die Assoziation darf aber nur von der Klasse
zum Interface navigierbar sein9 .
DataType Ein Datentyp ist ein Typ, dessen Werte keine Identität haben (reine Werte).
Zu den Datentypen gehören primitive Typen (z.B. integer, string) und (benutzerdefinierbare) Aufzählungstypen (z.B. boolean).
Im Metamodell ist DataType ein spezieller Klassifizierer, der nur Operationen, die
reine Funktionen sind, enthalten kann.
Node Ein Knoten ist ein physisches Objekt und repräsentiert Rechenkapazität, im allgemeinen mit Speicher und Prozessfähigkeit. Im Metamodell ist ein Knoten mit einer
Menge von Komponenten assoziiert, die sich auf diesem Knoten befinden (resident).
Component Eine Komponente ist ein physisches, austauschbares Teil eines Systems.
Es repräsentiert ein Bestandteil der Implementation des Systems, z.B. Quelltext, Biliothekscode, ein ausführbares Programm oder ein Skript.
9 Der
Sinn einer solchen Assoziation ist dem Autor verschlossen geblieben.
57
Eine Komponente kann keine anderen Komponenten beinhalten. Eine Komponente
kann nur Datentypen, Interfaces, Klassen, Assoziationen, Abhängigkeiten, Zusicherungen, Signale, Datenwerte und Objekte implementieren (resident). Eine Komponente
kann sich auf einem Knoten (deploymentLocation) befinden.
Für Komponenten sind mehrere Stereotypen vordefiniert:
Stereotyp
«document»
«executable»
«file»
«library»
«table»
3.1.1.3
Semantik
Die Komponente repräsentiert ein Dokument
Die Komponente repräsentiert ein Programm, welches auf einem Knoten ausgeführt werden kann.
Die Komponente repräsentiert ein Dokument, welches Daten
oder Quellcode enthält.
Die Komponente repräsentiert eine (statische oder dynamische) Bibliothek.
Die Komponente repräsentiert eine Tabelle einer Datenbank
Assoziation und Generalisierung
Eine Assoziation deklariert mögliche Verbindungen (links) zwischen Exemplaren von assoziierten Klassifizierern (z.B. Klassen). Die Exemplare einer Assoziation (Links) bilden
eine Menge10 von Tupeln, die aus Referenzen auf die assoziierten Exemplare bestehen.
Eine Assoziation besteht aus mindestens zwei Assoziationsenden, von denen jedes mit
einem Klassifizierer verbunden ist und Zusicherungen definiert, die erfüllt sein müssen,
damit die Beziehung gültig ist. Die Kardinalitätseigenschaft eines Assoziationsendes spezifiziert, wieviele Exemplare eines Klassifizierers an einem gegebenen Assoziationsende
(dasjenige, welches die Kardinalität angibt) mit einem einzigen Exemplar des Klassifizierers an einem anderen Ende assoziiert sein müssen (siehe Abb. 3.13). Eine Kardinalität
ist ein Bereich von nicht-negativen ganzen Zahlen (Integer). Ein Assoziationsende gibt
weiter an, ob die Verbindung zu dem Exemplar navigierbar ist, d.h. ob das Exemplar
durch die Assoziation erreichbar ist (siehe als Beispiel Abb. 3.14).
In einer Assoziation kann die Menge der Merkmale, die eine Klasse in dieser Beziehung benötigt, beschränkt werden. So kann z.B. eine Klasse „Person“ mehrere Schnittstellen realisieren und in einer Assoziation nur die Schnittstellen zur Verfügung stellen,
die sie für die Ausübung dieser Rolle benötigt (Abb. 3.15). Anstelle von Interfaces können auch Typen (Klassen mit dem Stereotyp «type») benutzt werden.
Eine weitere Zusicherung eines Assoziationsendes gibt an, ob die Menge der Links
auf die entsprechenden Exemplare des Assoziationsendes verändert werden dürfen. Möglichkeiten sind:
1. Es existiert keine Zusicherung (changeable), d.h. die Links dürfen beliebig hinzu10 Jedes
Tupel tritt maximal einmal auf (extensionale Auffassung)
3.1. FUNDAMENT
58
Rollenname
+Einwohner
Person
name : String 1..*
+Wohnort
Ort
name
: String
0..*
Kardinalität
Abbildung 3.13: Beispiel einer binären Assoziation: Eine Person kann in der Rolle als
Einwohner mit beliebig vielen Wohnorten assoziiert sein. Ein Wohnort
hat mindestens einen Einwohner. Die Assoziation ist beidseitig navigierbar (nach Konvention des Werkzeugs).
+passwort
Person
name : String
0..1
Passwort
name : String
Abbildung 3.14: Eine gerichtete Assoziation, die nur von Person zu Paßwort navigierbar
ist.
+Vorgesetzer: IManager
1..1
Person
IMitarbeiter
0..*
+Mitarbeiter: IMitarbeiter
IManager
Abbildung 3.15: Spezifizierung von Rollen durch Interfaces
59
gefügt, entfernt und geändert werden.
2. Nachdem die Verbindung initialisiert wurde, können keine Links mehr geändert
oder gelöscht werden (frozen).
3. Neue Links können hinzugefügt werden, dürfen aber nicht mehr verändert werden
(addOnly).
Diese Zusicherungen betreffen nicht die Änderbarkeit der Exemplare selbst, die an das
Link-Ende (Exemplar eines Assoziationsendes) geheftet sind.
Durch eine weitere Zusicherung eines Assoziationsendes kann angegeben werden, ob
die Exemplare an dem Assoziationsende bezüglich eines einzigen Exemplars eines anderen Assoziationsendes auf irgendeine Weise geordnet sein müssen (Abb. 3.16). In diesem
Fall müssen Operationen, die Links einfügen, verändern oder löschen, die Ordnung berücksichtigen. Das Sortieren von Links ist eine Optimierung aus Performancegründen,
Person
name : String
+Wohnort
Ort
0..* name : String
{addOnly,
zeitlich geordnet}
Abbildung 3.16: Die verschiedenen Wohnorte einer Person zeitlich geordnet. Ist die Beziehung zwischen einer Person und einem Wohnort initialisiert, darf sie
nicht mehr entfernt werden. Die Art der Ordnung (z.B. aufsteigend) ist
nicht festgelegt. Vorsicht: eine Person kann nur einmal mit einem Ort
assoziiert werden, d.h. ein Umzug in einen ehemaligen Wohnort kann
in diesem Modell nicht erfaßt werden.
aber kein Beispiel einer logischen Ordnung, da die Sortierung keine zusätzliche Information besitzt. Die Zusicherung „zeitlich geordnet“ in Abbildung 3.16 ist ein Beispiel einer
benutzerdefinierten Zusicherung und fügt der Assoziation weitere Informationen hinzu,
die (auch) Auswirkungen auf die Implementierung haben. Die Angabe einer Zusicherung
„alphanumerisch sortiert“ fügt zwar der Assoziation selbst keine Information hinzu, ist
aber aus einer Implementierungssicht sinnvoll.
In der UML gibt es drei Arten von Assoziationen:
1. gewöhnliche Assoziation
2. Aggregation (beschreibt eine Ganzes-Teile-Hierarchie)
3. Komposition (Aggregation, bei der die Teile vom Ganzen existenzabhängig sind)
Da das Aggregationskonstrukt verschiedene Bedeutungen abhängig vom Anwendungsgebiet hat, präzisiert die UML Assoziation und Komposition genau, läßt aber bei der
Aggregation einen Interpretationsspielraum offen.
3.1. FUNDAMENT
60
Eine Assoziation kann eine Ganzes-Teile-Hierachie darstellen. In diesem Fall wird
das Assoziationsende, welches das Ganze darstellt, gekennzeichnet, und das andere Ende
der Assoziation stellt die Teile der Aggregation dar. Nur binäre Assoziationen können Aggregationen sein. Eine Komposition ist eine strenge Form der Assoziation, die verlangt,
daß ein Exemplar eines Teils (Komponente) zu einem Zeitpunkt nur zu maximal einer
Komposition gehören darf (Abbildung 3.17). Der Besitzer der Komponente kann allerdings ausgetauscht werden. Eine Komposition impliziert eine Übertragung der Semantik
Absatz
Dokument
Satz
0..*
0..*
Abbildung 3.17: Komposition: Die Teile (Komponenten) sind vom Ganzen (Komposition) existenzabhängig
(propagation semantics), d.h. das Verhalten des Ganzen wird auf seine Teile übertragen.
Wird z.B. das Ganze kopiert/gelöscht, so gilt dies auch für seine Teile.
Firma
1..*
0..*
+Arbeitgeber
Person
+Arbeitnehmer
Abbildung 3.18: Aggregation: In diesem Modell werden Arbeitnehmer als Teil einer Firma angesehen.
Eine (normale) Aggregation hat weniger starke Einschränkungen. Die Teile können
zu verschiedenen Aggregaten (dem Ganzen) gehören, die Besitzer der Teile können ebenfalls ausgetauscht werden. Bei dieser Form der Aggregation impliziert das Löschen des
Ganzen nicht das Löschen seiner Teile (Abbildung 3.18).
Beide Arten der Aggregation definieren eine transitive, asymmetrische Beziehung.
Eine Qualifikationsangabe (engl. Qualifier) ist ein Assoziationsattribut, dessen Werte
die Menge der Exemplare am gegenüberliegenden Ende partitionieren. In Abbildung
Bank
+kunde
ktoNr
Person
0..1
Abbildung 3.19: qualifizierte Assoziation: maximal ein Kunde pro Kontonummer und
Bank
3.19 partitioniert ktoNr die Menge der Kunden, die mit einem gegebenen Exemplar von
Bank assoziiert sind. Ein Exemplar bzw. ein Wert von ktoNr selektiert den zugehörigen Kunden (falls einer existiert). In Abbildung 3.21 kann ein Wert von ktoNr mehrere
Kunden selektieren. Da ein Exemplar von Bank nicht mehrfach mit einem Exemplar
61
+kunde
Bank
0..*
0..*
Person
ktoNr : String
Abbildung 3.20: nicht-qualifizierte Assoziation: maximal eine Kontonummer für einen
Kunden pro Bank
Bank
+kunde
ktoNr
Person
0..*
0..*
Abbildung 3.21: qualifizierte Assoziation: mehrere Kunden pro Konto und Bank, allerdings kann ein Kunde nur ein Konto pro Bank haben
von Kunde assoziiert sein kann11 , kann ein Kunde maximal eine Kontonummer pro Bank
haben.
Die Kardinalität der Zielseite (die zu partitionierende Seite) einer qualifizierten Assoziation gibt die Anzahl der Zielexemplare, die durch ein Quellexemplar und einem Wert
der Qualifikationsangabe selektiert werden, an. Gebräuchliche Werte sind:
• „0..1“: Maximal ein Zielexemplar wird durch den Wert der Qualifikationsangabe
selektiert, aber nicht jeder mögliche Wert muß notwendigerweise ein Exemplar selektieren.
• „1“: Jeder mögliche Wert der Qualifikationsangabe selektiert genau ein Zielexemplar, daher muß der Wertebereich der Qualifikationsangabe endlich sein.
• „*“: Der qualifizierende Wert partitioniert die Zielexemplare in Teilmengen. Er
suggeriert eine Implementation, bei der durch einen qualifizierenden Wert auf eine
Teilmenge der Exemplare zugegriffen werden kann.
Die Kardinalität der Qualifikationsangabe ist durch die Annahme gegeben, daß der qualifizierende Wert unterstützt wird. Die reine Kardinalität der Quellseite ohne eine Qualifikationsangabe wird meist mit „0..*“ angenommen, da die Situation, in der die Kardinalität
„1“ ist, durch eine einfache Assoziation modelliert werden sollte.
Es ist erlaubt, beide Seiten einer Assoziation zu qualifizieren (ein seltener Fall). Es ist
möglich, einen Klassifizierer mehrfach zu qualifizieren (mehrere Assoziationen) und eine
Assoziation mit mehreren Qualifikationsangaben an einer Seite zu versehen. Ein Beispiel
ist in [OMG99] (Seite 3-71) angegeben.
Bei einer Assoziation zwischen zwei Klassen kann die Assoziation selbst weitere Eigenschaften haben. Z.B. kann in einer Arbeitnehmer/Arbeitgeber-Beziehung zwischen
11 Eine
Assoziation ist eine Menge von Tupeln.
3.1. FUNDAMENT
62
einer Firma und einer Person eine Stelle sein, die die Eigenschaften der Beziehung zwischen genau einem Arbeitnehmer/Arbeitgeber-Paar beschreibt (Einstellungsdatum, Gehalt, usw.). In der UML kann man diese Situation mit einer Assoziationsklasse modellieren (Abbildung 3.22). Eine Assoziationsklasse ist ein Teil einer Assoziation und modelFirma
+Arbeitgeber
+Arbeitnehmer
Person
1..*
0..*
Stelle
eintrittsDatum
gehalt
Abbildung 3.22: Assoziationsklasse: Stelle ist eine Eigenschaft der Assoziation
liert Merkmale, die zur Assoziation selbst gehören. Eine Assoziationsklasse kann nur an
eine einzige Assoziation geheftet werden.
Abbildung 3.23 zeigt die Klassen des Metamodells, die die Assoziations- und Generalisierungsbeziehungen darstellen.
Relationship Im Metamodell in Abb. 3.23 ist Relationship eine abstrakte Klasse
ohne eigene Semantik, die nur aus technischen Gründen vorhanden ist.
Association Eine Assoziation definiert eine strukturelle Beziehung zwischen Klassifizierern. Ein Exemplar einer Assoziation (Link) ist ein Tupel der entsprechenden Exemplare (bzw. Verweise auf die Exemplare) der Klassifizierer. Eine Assoziation besteht
aus mindestens zwei Assoziationsenden, die die Verbindung zwischen der Assoziation
und den Klassifizierern bilden. Jedes Asssoziationsende spezifiziert eine Menge von Eigenschaften, die erfüllt sein müssen, damit die Beziehung gilt (auf der Modellebene). Die
assoziierten Klassifizierer sollten im Namensraum der Assoziation enthalten sein.
Ein Stereotyp und eine Zusicherung sind definiert:
Stereotyp
Semantik
«implicit»
Die Beziehung ist implizit gegeben und wird nur aus rein
konzeptionellen Gründen dargestellt. Beispielsweise ist eine
Assoziation zwischen zwei Unterklassen implizit, wenn ihre
Oberklassen bereits assoziiert sind.
Zusicherung
xor
Semantik
Wird auf eine Menge von Assoziationen angewandt. Sie fordert, daß genau eine Assoziation für jedes assoziierte Exemplar
gilt (Beispiel: Abb. 3.28, Seite 72).
63
+source
*
ModelElement
name : Name
+target
*
Relationship
+source
+target
*
*
Flow
Generalization
discriminator : Name
+child
+generalization
1
*
1
*
+parent
+specialization
Classifier
+type
AssociationEnd
1
*
+specification
+participant
*
Class
isActive : Boolean
isRoot : Boolean
isLeaf : Boolean
*
Attribute
+qualifier
isNavigable : Boolean
ordering : OrderingKind
aggregation : AggregationKind
2..*
1
Association
+connection
{ordered}
+associationEnd
*
{ordered}
0..1
AssociationClass
Abbildung 3.23: Assoziations-, Generalisierungs- und Flußbeziehungen
AssociationEnd Ein Assoziationsende ist der Endpunkt einer Assoziation und enthält den größten Informationsanteil einer Assoziation. Jedes Assoziationsende ist Teil
genau einer Assoziation. Der Name des Assoziationsendes beschreibt die Rolle, die die
Exemplare des assoziierten Klassifizierers in der Beziehung spielen. Im folgenden werden die Hilfsbezeichnungen aus Abb. 3.24 benutzt.
betrachtetes
Assoziationsende
Quelle
.
Ziel
Abbildung 3.24: Hilfsbezeichnungen für die Erläuterung des Assoziationsendes
3.1. FUNDAMENT
Attribut
name
aggregation
changeability
ordering
isNavigable
multiplicity
targetScope
64
Semantik
Der Rollenname des Assoziationsendes. Er bezeichnet die
Rolle, die der Zielklassifizierer in der Assoziationsbeziehung
spielt. Dieser Rollenname repräsentiert ein Pseudoattribut des
Quell-Klassifizierers, d.h. er kann auf die gleiche Art wie ein
Attribut vom Quell-Klassifizierer benutzt werden (unabhängig
von der Sichtbarkeit, abhängig von der Navigierbarkeit). Daher muß der Rollenname bzgl. der Attribute und anderer Pseudoattribute des Quell-Klassifizierers eindeutig sein.
none: Dies Ende ist keine Aggregation.
aggregate: Der mit diesem Ende assoziierte Klassifizierer
(Ziel) stellt das Ganze der Aggregationsbeziehung dar. Das
Quellende muß den Wert none haben.
composite: Der mit diesem Ende assoziierte Klassifizierer
stellt das Ganze der Kompositionsbeziehung dar. Das Quellende muß den Wert none haben.
Gibt an, ob ein Link vom Quellende aus verändert werden kann (entsprechend der changeability-Eigenschaft von
Attribute). Die Werte von changeability werden als Zusicherungen dargestellt.
changeable: Keine Einschränkungen (Default).
addOnly: Links können von der Quelle hinzugefügt, aber nicht
verändert werden.
frozen: Nachdem das Quellobjekt erzeugt wurde, dürfen keine Links hinzugefügt werden.
unordered: Die Links sind nicht geordnet (Default)
ordered: Die Links sind geordnet (die Ordnung selbst ist aber
nicht definiert)
Zusätzliche Werte (z.B. sorted) werden eventuell in weiteren Versionen definiert. Es besteht die Möglichkeit zusätzliche
Werte als Stereotypen zu definieren, die entsprechende Werkzeuge unterstützen könnten.
true: Ein Exemplar des Quellendes kann auf die assoziierten
Exemplare des Zielendes schließen (zum Ziel navigieren). Die
Navigierbarkeit eines Assoziationsendes ist unabhängig von
der Navigierbarkeit der anderen Assoziationsenden.
false: nicht navigierbar.
(Kardinalität) Bezeichnet die Anzahl der mit einem Quellexemplar assoziierten Zielexemplare.
instance: Der Link verweist auf ein Exemplar (default).
classifier: Der Link verweist auf einen Klassifizierer.
65
Attribut
visibility
Semantik
Gibt die Sichtbarkeit des Assoziationsendes aus der Sicht von
Klassifizierern an, die den Quellklassifizierer „sehen“ können.
public: Andere Klassifizierer können navigieren und den
Rollennamen in Ausdrücken benutzen, d.h. sie können den
Rollennamen wie ein öffentliches Attribut benutzen.
protected: Nachkommen des Quellklassifizierers können navigieren und den Rollennamen in Ausdrücken benutzen.
private: Nur der Quell-Klassifizierer kann navigieren und
den Rollennamen in Ausdrücken benutzen.
Pseudoattribut
type
Semantik
Bezeichnet den Klassifizierer, der mit dem Assoziationsende
verbunden ist. In einem Link kann die Klasse ein Nachkomme der Quellklasse sein, im Falle eines Interfaces kann es die
realisierende Klasse sein.
Bezeichnet optional Klassifizierer, die Operationen spezifizieren, die auf Exemplare angewandt werden können, welche
durch die Assoziation und das Assoziationsende erreicht werden. Diese spezifizierenden Klassifizierer bestimmen die minimale Schnittstelle, die durch den assoziierten Klassifizierer
realisiert werden muß. Dies können Typen (Klassen mit dem
Stereotyp «type») oder Interfaces sein, die Eigenschaften spezifizieren, die ein Exemplar in dieser Beziehung zur Verfügung
stellt (vgl. Abb. 3.15).
Bezeichnet eine optionale Liste von Qualifikationsangaben.
specification
qualifier
Der Klassifizierer eines Assoziationsendes kann kein Interface oder Datentyp (DataType) sein, wenn ein gegenüberliegendes Assoziationsende navigierbar ist, d.h. man kann
nicht von einem Interface oder Datentyp wegnavigieren.
AssociationClass Mit einer Assoziationsklasse werden Eigenschaften einer binären Assoziation modelliert. Dies sind Eigenschaften, die nicht zu den beteiligten Klassifizierern gehören, sondern Eigenschaften der Assoziation selbst sind.
Im Metamodell ist eine AssociationClass eine Unterklasse von Class und Association. Daher kann eine assoziierte Klasse sowohl Merkmale als auch Assoziationsenden haben.
Die Namen der Assoziationsenden und die Namen der strukturellen Merkmale (Attribute) einer Assoziationsklasse dürfen sich nicht überschneiden.
3.1. FUNDAMENT
66
Generalization Eine Generalisierung ist eine Beziehung zwischen einem SuperElement (parent) und einem Sub-Element (child). Im Metamodell ist Generalization
eine Assoziation zwischen (verschiedenen) verallgemeinerbaren Elementen. Exemplare
dieser Metamodellklassen beschreiben eine Vererbungshierarchie auf der Modellebene.
Attribut
Semantik
discriminator
Gibt an, welche Eigenschaft durch die Generalisierungsbeziehung abstrahiert wird.
Stereotyp
«implementation»
Semantik
Bezeichnet eine Generalisierung, bei der das spezialisierte Element die Implementation des allgemeineren Elements erbt,
aber die Implementierung der Interfaces des allgemeineren
Elements weder öffentlich zugängig macht noch deren Unterstützung garantiert. Dies verletzt das Substitutionsprinzip der
Generalisierung. Das Stereotyp kennzeichnet eine „private“
Verererbung, die normalerweise nur in einer Implementationssicht Sinn macht.
Zusicherung
disjoint
Semantik
(disjunkt) Dies ist eine Standardzusicherung der Generalisierung. Exemplare des allgemeineren Elements dürfen maximal
einen der Nachkommen als Typ haben.
(nicht disjunkt, überschneidend) Exemplare des allgemeineren
Elements dürfen den Typ mehrerer (direkter) Nachfahren haben. Dieses wird z.B. modelliert, wenn ein Exemplar einer
Klasse Person sowohl als Kunde als auch als Lieferant in Erscheinung treten kann, d.h. ein Exemplar kann seine Klassenzugehörigkeit dynamisch ändern.
(nicht-vollständig) Dies ist eine Standardbedeutung der Generalisierung. Es sind nicht alle direkten Nachkommen spezifiziert, weitere können hinzugefügt werden.
(vollständig) Alle direkten Nachkommen sind spezifiziert, zusätzliche sind nicht erlaubt.
overlapping
incomplete
complete
Flow Ein Ablauf oder Fluß ist eine gerichtete Beziehung zwischen zwei Versionen
eines Exemplars (zu unterschiedlichen Zeitpunkten) oder zwischen einem Exemplar und
einer Kopie des Exemplars (Abb. 3.25).
Ein Fluß kann auch eine Aktivität (siehe Abb. 3.50, Seite 117) zu oder von einem
Objektflusszustand oder zwei Objektflusszuständen verbinden.
67
Müller : Person
[Mitarbeiter]
<< become >>
Müller : Person
[Manager]
Abbildung 3.25: Ablauf- oder Flußbeziehung zwischen zwei Versionen eines Exemplars
zu unterschiedlichen Zeitpunkten.
Stereotyp
«become»
«copy»
3.1.1.4
Semantik
(wird) bezeichnet eine Ablaufabhängigkeit, dessen Quelle und
Ziel dasselbe Exemplar zu unterschiedlichen Zeitpunkten darstellt. Sie verbindet zwei Versionen eines Exemplars, die sich
bzgl. Wert, Zustand, Ort oder Rolle unterscheiden können.
(kopiert) bezeichnet eine Ablaufabhängigkeit, bei der die
Quelle und das Ziel unterschiedliche Exemplare mit den gleichen Werten, Rollen und dem gleichen Zustand, aber mit einer unterschiedlichen Identität sind. Eine Kopie-Abhängigkeit
von A zu B bedeutet, daß B eine exakte Kopie von A zu einem
Zeitpunkt ist.
Abhängigkeiten
In der UML bezeichnet eine Abhängigkeitsbeziehung eine andere Beziehung als Assoziation, Generalisierung, Ablauf oder Metabeziehung (die Beziehung zwischen einem
Klassifizierer und einem Exemplar). Bei einer Abhängigkeit können sich Veränderungen unabhängiger Elemente auf abhängige Elemente auswirken. Die UML definiert vier
Abhängigkeitsbeziehungen:
• Eine Abstraktion ist eine Abhängigkeitsbeziehung zwischen zwei Elementen, die
das gleiche Konzept repräsentieren.
• Eine Erlaubnis gewährt einem Modellelement den Zugriff auf einen anderen Namensraum (z.B. ein Paket).
• Mit einer Benutzung wird dargestellt, daß ein Modellelement die Gegenwart eines
anderen Modellelements benötigt.
• Eine Bindung ist eine Beziehung zwischen einer Schablone (template) und einem
Modellelement.
Dependency Im Metamodell (Abb. 3.26) ist Dependency eine abstrakte Metaklasse
ohne eigene Semantik, die lediglich eine gerichtete Beziehung von abhängigen Modellelementen (client) zu unabhängigen Modellelementen (supplier) repräsentiert.
3.1. FUNDAMENT
68
Relationship
+client
+clientDependency
Dependency
ModelElement
name : Name
+argument
1..*
*
1..*
*
1..*
+supplier
+supplierDependency
0..1
Binding
Usage
Abstraction
Permission
mapping : MappingExpression
Abbildung 3.26: Die vier Arten der Abhängigkeit in der UML
Abstraction Eine Abstraktion ist eine Abhängigkeitsbeziehung zwischen zwei Elementen, die das gleiche Konzept auf unterschiedlichen Abstraktionsebenen oder aus unterschiedlichen Sichten repräsentieren.
Im Metamodell beinhaltet Abstraction eine Abbildung (mapping) zwischen client
(abhängig) und supplier (unabhängig). Abhängig vom Stereotyp der Abstraktion kann
die Abbildung informal oder formal und die Abhängigkeit gerichtet oder bidirektional
sein.
Die folgenden Stereotypen einer Abstraktion sind in der UML definiert:
Stereotyp
«derive»
Semantik
(ableiten) Eine abgeleitete Abstraktionsabhängigkeit besagt, daß
die abhängigen Elemente aus der Information der unabhängigen
Elemente berechnet werden können. Z.B. kann das Alter einer Person aus dem Geburtsdatum und dem aktuellen Datum berechnet
werden. Die Abbildung spezifiziert die Berechnung (meist formal).
69
Stereotyp
«derive»
(Forts.)
«realize»
«refine»
«trace»
Semantik
Bei dieser Abstraktion sind die beteiligten Elemente nicht notwendigerweise vom gleichen Typ. Das abhängige Element kann implementiert werden, obwohl die Implementation logisch redundant ist.
Effizienz ist meist der Grund für die Implementierung.
(realisiert) Eine Realisierung ist eine Beziehung zwischen einem
spezifizierenden (supplier) und einem implementierenden Modellelement (client), z.B. zwischen einem Interface und einer
Klasse. Das implementierende Element muß die Verhaltensmerkmale des spezifizierenden Elements unterstützen. Das implementierende Element muß die Deklarationen der Verhaltenselemente
entweder erben oder selbst spezifizieren. Die Abbildung beschreibt
die (nicht notwendigerweise berechenbare) Beziehung zwischen
den Modellementen. Realisierungen können zur Modellierung der
schrittweisen Verfeinerung, Optimierung, etc. benutzt werden. Eine Realisierung besitzt eine eigene graphische Notation (Kreuzung
aus Generalisierung und Abhängigkeit), die durch weitere Stereotypen ( (noch) nicht in der UML definiert) genauer beschrieben
werden kann.
(verfeinert) Eine Verfeinerung ist eine Abstraktionsbeziehung zwischen Modellelementen auf unterschiedlichen Abstraktionsebenen,
z.B. Analyse und Design. Die Abbildung beschreibt die (nicht notwendigerweise berechenbare und vollständige) Beziehung. Eine
Beschreibung der Abbildung kann als Kommentar an die Beziehung angeheftet werden. Die Abhängigkeit kann gerichtet oder bidirektional sein. Die Verfeinerung wird zur Modellierung der Übergänge zwischen Analyse und Design (u.ä. Veränderungen) eingesetzt.
(Spur) Eine Spur ist eine Abhängigkeitsbeziehung zwischen Modellelementen, die sich in unterschiedlichen Modellen befinden,
aber das gleiche Konzept repräsentieren. Spuren werden hauptsächlich zur Ermittlung von Anforderungen und Änderungen zwischen Modellen benutzt. Diese Art der Abhängigkeit sollte von
einem Tool unterstützt werden. Da die Richtung der Abhängigkeit
meist bidirektional ist, wird sie meistens ignoriert. Die Abbildung
beschreibt die Beziehung zwischen den Modellelementen meistens
informell.
Usage Benutzung ist eine Abhängigkeitsbeziehung, in der ein Element andere Elemente zur Implementation oder zur Erfüllung seiner Funktionalität benötigt. Auf welche
Weise das abhängige Element das unabhängige benutzt, wird durch das Stereotyp der
3.1. FUNDAMENT
70
Abhängigkeitsbeziehung definiert:
Stereotyp
«call»
«create»
«instantiate»
«send»
Semantik
Call ist eine Benutzt-Abhängigkeit, dessen Quelle und Ziel
Operationen sind. Diese Beziehung kann auch an eine Klasse gerichtet sein, die eine Operation enthält. In diesem Fall
bedeutet die Abhängigkeit, daß eine Operation in der Klasse existiert, die das abhängige Modellelement anwendet. Eine Call-Abhängigkeit spezifiziert, daß die Quelloperation oder
eine Operation in der Quellklasse die Zieloperation oder eine
Operation in der Zielklasse aufruft.
Bezeichnet eine Abhängigkeit, bei der das abhängige Modellelement ein Exemplar des unabhängigen Modellelements erzeugt.
Abhängigkeitsbeziehung zwischen Klassifizierern, die anzeigt,
daß Operationen des abhängigen Elements Exemplare des unabhängigen Elements erzeugen.
Quelle dieser Benutzt-Abhängigkeit ist eine Operation, Ziel ist
ein Signal. Diese Beziehung sagt aus, daß die Quelle (eine
Operation) ein Signal sendet bzw. senden kann. Signale werden im Abschnitt 3.2 Verhaltenselemente erläutert.
Permission Eine Erlaubnis garantiert einem Modellelement den Zugriff auf Elemente in einem anderen Namensraum. Das abhängige Element muß hierbei ein Namensraum, z.B. eine Klasse, sein.
Stereotyp
«access»
«import»
«friend»
Semantik
Abhängigkeit zwischen zwei Namensräumen. Der abhängige Namensraum kann auf die öffentlichen (public) Anteile des
unabhängigen Namensraum zugreifen.
Abhängigkeit zwischen zwei Namensräumen. Der abhängige
Namensraum importiert die öffentlichen Anteile des unabhängigen Namensraum.
Abhängigkeit zwischen einem Modellelement (z.B. Operation, Klasse, Paket) und einem Modellelement in einem anderen
Paket (z.B. Operation, Klasse, Paket). Das abhängige Element
erhält, ohne Berücksichtigung der Sichtbarkeit, Zugriff auf den
unabhängigen Namensraum.
71
3.1.1.5
Kommentar
In der UML kann an jedes Modellelement eine Anmerkung, eine Notiz oder ein Kommentar geheftet werden. Die Notiz selbst hat in der UML keine Semantik, enthält aber
zusätzliche Informationen für den Modellierer.
ModelElement
name : Name
*
+annotatedElement
*
Comment
Abbildung 3.27: Jedes Modellelement kann mit beliebig vielen Kommentaren versehen
werden.
Im Metamodell werden die Kommentare durch die Klasse Comment repräsentiert, die
ein direkter Nachkomme der abstrakten Metaklasse ModelElement ist (Abb. 3.27).
Zwei Stereotypen einer Notiz/eines Kommentars sind vordefiniert:
Stereotyp
«requirement»
«responsibility»
3.1.2
Semantik
Anforderung: gefordertes Merkmal, Eigenschaft oder Verhalten eines Systems.
Verantwortlichkeit: Vertrag oder Verpflichtung eines Elements.
Erweiterungsmechanismen
Die UML besitzt eingebaute Erweiterungsmechanismen, die verschiedenen Zwecken dienen:
• Hinzufügen neuer Arten von Modellelementen.
• Definieren von Standards, die als nicht interessant oder komplex genug angesehen
wurden und deshalb nicht als Meta-Modellelemente definiert wurden.
• Definieren von prozeß- oder sprachabhängigen Erweiterungen.
• Anheften beliebiger Informationen mit bestimmter Semantik an Modellelemente.
Der wichtigste Erweitungsmechanismus ist das Stereotypkonzept. Stereotypen bieten
einen Weg, Elemente der Modellebene zu klassifizieren und ermöglichen das Hinzufügen
3.1. FUNDAMENT
72
„virtueller“ Metaklassen mit neuen Metaattributen und neuer Semantik. Eigenschaftswerte (tagged values) und Zusicherungen (constraints) basieren auf Eigenschaftslisten, die
das Anheften zusätzlicher Eigenschaften und Semantik an Modellelemente ermöglichen.
+extendedElement
+taggedValue
0..1
ModelElement
*
*
1..* {ordered}
+constrainedElement
TaggedValue
tag : Name
value : String
+requiredTag
*
Constraint
+stereotypeConstraint
*
+constraint
*
{xor}
+stereotype
0..1
Stereotype
icon : Geometry
baseClass : Name
0..1 +constrainedStereotype
0..1
Abbildung 3.28: Erweiterungsmechanismen
Stereotype Ein Stereotyp ist ein UML-Modellelement, welches zur Markierung
oder Klassifizierung anderer UML-Elemente benutzt wird. Die stereotypisierten Elemente können als Exemplare neuer „virtueller“ oder „Pseudo-“ Metamodellklassen angesehen werden, die auf bestehenden Metamodellklassen basieren. Stereotypen vergrößern
den Klassifikationsmechanismus, basierend auf der Metamodellklassenhierachie, deshalb
müssen sich die Namen neuer Stereotypen von den Namen der Metamodellelemente oder
anderen Stereotypen unterscheiden. Jedes Modellelement kann durch maximal ein Stereotyp markiert werden. Ein Stereotyp kann als Spezialisierung anderer Stereotypen konstruiert werden. Ein Stereotyp kann zusätzliche Eigenschaftswerte und Zusicherungen
sowie eine neue graphische Notation definieren. Die durch das Stereotyp markierten Modellelemente erhalten diese Eigenschaftswerte, Zusicherungen und Notation. Ein stereotypisiertes Modellelement erhält die Attribute, Assoziationen und Operationen seiner
Basisklasse (aus dem Metamodell) und kann zusätzliche zur Basisklasse konsistente Zusicherungen definieren, eine andere Bedeutung haben sowie eigene Eigenschaftswerte
definieren. Exemplare stereotypisierter Elemente haben die gleiche Struktur (Attribute, Assoziationen) und das gleiche Verhalten (Operationen) wie ein vergleichbares nichtstereotypisiertes Element. Ein Stereotyp kann benutzt werden, um eine unterschiedliche
Bedeutung oder Benutzung zweier Elemente mit identischer Struktur zu indizieren.
73
Im Metamodell (Abb. 3.28) ist die Metaklasse Stereotype eine Unterklasse von
GeneralizableElement. Eigenschaftswerte und Zusicherungen eines Stereotyps werden auf alle durch das Stereotyp markierte Modellelement angewandt. Ein Stereotyp
kann optional ein Icon spezifizieren, welches zur Darstellung von Elementen des Stereotyps benutzt werden kann. Falls ein Stereotyp ein Untertyp eines anderen Stereotypen ist,
erbt es alle Eigenschaftswerte und Zusicherungen des Supertyps, wobei beide Stereotypen
die gleiche Basisklasse haben müssen.
Attribut
Semantik
baseClass
Spezifiziert den Namen einer Klasse aus dem Metamodell der
UML, auf das das Stereotyp angewandt wird, z.B. Class,
Association oder Constraint.
icon
Geometrische Beschreibung des Icons, welches zur Darstellung der durch das Stereotyp markierten Elemente benutzt
wird (optional).
Pseudottribut
extendedElement
constraint
stereotypeConstraint
requiredTag
Semantik
Bezeichnet die durch das Stereotyp klassifizierten Modellelemente. Jedes dieser Modellelemente muß von der Art des
durch baseClass spezifizierten UML-Modellelements sein.
(geerbt von ModelElement) Zusicherung, die auf das Stereotyp selbst angewandt wird.
Bezeichnet die Zusicherungen, die auf die stereotypisierten
Elemente angewandt werden.
Ein Eigenschaftswert (s.u.) ist ein Tupel bestehend aus einer
Markierung und einem Wert. requiredTag gibt die Markierungen an, die ein stereotypisiertes Element haben muß. Der
Wert gibt den Defaultwert des Eigenschaftswertes an. Falls der
Wert nicht spezifiziert ist, muß ein stereotypisiertes Element
den Wert setzen.
Die Namen der Eigenschaftswerte eines Stereotypen dürfen weder mit dem MetaAttribut-Namensraum (Meta-Ebene) der Basisklasse, noch mit den Markierungen der geerbten Stereotypen kollidieren.
Modelelement Jedes Modellelement kann beliebige Eigenschaftswerte und Zusicherungen besitzen. Ein Modellelement darf maximal ein Stereotyp, dessen Basisklasse
(baseclass) mit der UML-Klasse des Modellelements (z.B. Klasse) übereinstimmen
muß, besitzen. Die Markierung durch ein Stereotyp kann das Modellelement implizit
mit Zusicherungen versehen und die Angabe von Eigenschaftswerten erfordern.
3.1. FUNDAMENT
Pseudottribut
stereotype
constraint
taggedValue
74
Semantik
Bezeichnet maximal einen Stereotyp, der die UMLBasisklasse des Modellelements erweitert bzw.
weiter
spezifiziert. Das Stereotyp verändert nicht die Struktur
der Basisklasse, kann aber zusätzliche Eigenschaftswerte
und Zusicherungen definieren, deren Semantik auf das
stereotypisierte Element übertragen wird.
Zusicherung, die für die Exemplare des Modellelements erfüllt
sein muß. Ein Modellelement kann mehrere Zusicherungen
besitzen. Die Zusicherung wird ausgewertet, wenn das System
in einem stabilen Zustand ist (z.B. nicht innerhalb einer atomaren Operation).
Ein Eigenschaftswert, der an das Modellelement geheftet wird.
Die Markierung (tag) ist der Name12 der Eigenschaft, der
Wert ist beliebig. Die Interpretation des Eigenschaftswertes liegt außerhalb des Bereichs der UML. Ein Modellelement kann mehrere Eigenschaftswerte besitzen, die Markierung muß dabei eindeutig sein.
Die mit einem Modellelement assoziierten Markierungen (der Eigenschaftswerte) (direkt oder indirekt durch ein Stereotyp) müssen sich von den mit dem Modellelement assoziierten Metaattributen unterscheiden (man kann Eigenschaftswerte als Pseudo-Metaattribute interpretieren). Falls ein Stereotyp einen Eigenschaftswert erfordert, aber nicht
spezifiziert, muß das stereotypisierte Modellelement den Wert festlegen.
Constraint Das Konzept der Zusicherungen (engl. constraints) erlaubt die Spezifizierung neuer Semantiken für ein Modellelement. Die Spezifizierung kann durch eine
speziell entworfene Sprache für Zusicherungen (z.B. OCL, Object Constraint Language),
eine Programmiersprache, mathematische Notation oder eine natürliche Sprache formuliert werden. Wenn Zusicherungen durch ein Werkzeug weitergehend unterstützt werden
sollen, muß das Werkzeug die Syntax und Semantik der Sprache verstehen.
Im Metamodell kann eine Zusicherung direkt an Modellelemente geheftet werden
(constrainedElement), d.h. die Zusicherung wird auf die Exemplare der Modellelemente angewandt (z.B. Exemplare der Klasse Kunde). Eine Zusicherung kann ebenfalls an ein Stereotyp geheftet werden (constrainedStereotype), d.h. die Zusicherung
wird dann auf alle mit diesem Stereotyp markierten Elemente angewandt. Bezeichnet
constrainedElement ein Stereotyp, dann wird die Zusicherung auf das Stereotyp selbst
angewandt.
12 taggedValue
ist nicht als Unterklasse von ModelElement definiert, d.h. es kann weder den Namen von
ModelElement erben, noch Zusicherungen besitzen.
75
Attribut
body
Semantik
Ein boolescher Ausdruck, der die Zusicherung definiert. Damit das Modell wohldefiniert ist, muß der Ausdruck den Wert
„wahr“ ergeben, wenn er für ein Exemplar des zugesicherten
Elements (constrainedElement) ausgewertet wird. Der Ausdruck wird nur ausgewertet, wenn sich das System in einem
stabilen Zustand befindet.
TaggedValue Ein Eigenschaftswert (tagged value) ist ein (Markierung, Wert)-Paar,
welches als zusätzliche Information an ein Modellelement geheftet werden kann. Ein Modellelement kann mehrere Eigenschaftswerte besitzen, zu einem Namen einer Markierung
darf es aber nur einen Wert geben. Die Interpretation einer Markierung liegt außerhalb
des Bereichs der UML, sie muß durch Benutzer- oder Werkzeugkonventionen festgelegt
werden. Beispiele für Eigenschaftswerte sind Autor und Versionnummer, die durch ein
Werkzeug automatisiert werden könnten.
Attribut
Semantik
tag
(Marke, Markierung) Name, der die angeheftete Eigenschaft
beschreibt. Eine Markierung ist ein Pseudoattribut eines Modellelements. Ein Modellelement darf maximal einen markierten Wert pro Namen besitzen.
value
Ein (beliebiger) Wert. Aus Gründen der einheitlichen Manipulation durch Tools muß der Wert als String ausgedrückt werden. Der Wertebereich hängt von der Interpretation der Markierung ab.
3.1.3
Datentypen
Im Metamodell werden die Datentypen zur Deklarierung der Typen der Attribute der
Metaklassen benutzt. Die Datentypen, die von den Anwendern der UML benutzt werden,
sind die Exemplare der Datentyp-Metaklasse (Abb. 3.29 und 3.30).
Primitive
terstruktur.
Ein primitiver Datentyp ist ein einfacher Datentyp ohne relevante Un-
primitiver Datentyp Semantik
Integer
Im Metamodell ist ein Integer ein Element der (unendlichen)
Menge der ganzen Zahlen.
UnlimitedInteger Datentyp, dessen Wertebereich die natürlichen Zahlen inklusive des Wertes „unbegrenzt“ (unlimited) umfaßt.
3.1. FUNDAMENT
76
primitiver Datentyp Semantik
String
Im Metamodell definiert String eine beliebig lange Zeichenkette.
Time
Im Metamodell definiert Time einen Wert, der einen absoluten
oder relativen Moment in Raum und Zeit repräsentiert. Der
Wert hat eine entsprechende Darstellung als String.
DataType
Primitive
Structure
Enumeration
ProgrammingLanguageType
type : TypeExpression
1
{ordered}
1..*
+literal
EnumerationLiteral
name : Name
Abbildung 3.29: Datentypen (1)
Structure Eine Struktur ist ein spezieller Datentyp, der eine feste Anzahl von benannten Teilen hat (vergleichbar einem „Record“).
Enumeration Eine Aufzählung (enumeration) ist ein Datentyp, dessen Wertebereich
eine Liste von definierbaren Werten (EnumerationLiteral) ist. Diese Liste definiert
Atome (d.h. Elemente ohne Unterstruktur), die auf Gleichheit untersucht werden können.
Aufzählung
AggregationKind
Boolean
Semantik
Werte sind none, aggregate und composite. Diese
Werte bezeichnen die Art der Aggregation einer
Assoziation.
Werte sind true und false.
77
Aufzählung
CallConcurrencyKind
ChangeableKind
MessageDirectionKind
OperationDirectionKind
OrderingKind
ParameterDirectionKind
PseudostateKind
VisibilityKind
Semantik
Werte sind sequential, guarded und concurrent.
Sie indizieren die Semantik der Nebenläufigkeit
einer Operation.
Werte sind changeable, frozen und addOnly. Sie
spezifizieren, ob ein AssociationEnd, LinkEnd
oder AttributLink (Verweis auf ein Exemplar)
verändert werden kann.
Werte sind activation und return. Sie spezifizieren die Richtung einer Botschaft. (wird in UML
Version 1.3 final nicht mehr benutzt)
Werte sind provide und require. Sie geben an,
ob eine Operation von einem Klassifizierer unterstützt oder seine Gegenwart verlangt wird. (wird
in UML Version 1.3 final nicht mehr benutzt)
Gibt die Art der Ordnung der Exemplare an einem Assoziationsende an.
Werte sind in, out, inout und return. Sie geben
an, ob ein Parameter als Eingabe- und/oder Ausgabeparameter benutzt wird.
Werte sind initial, deepHistory, shallowHistory,
join, fork, branch, junction und final. Beschreibt
die möglichen Pseudo-Zustände eines Zustandsautomaten.
Werte sind public, protected und private. Sie geben an, ob die Elemente eines Namensraums von
außen sichtbar sind.
ProgrammingLanguageType Ein Programmiersprachentyp beschreibt einen Typ
in der Syntax einer bestimmten Programmiersprache. Dieser Typ kann zur programmiersprachenspezifischen Deklarierung von Attributen, Parametern und lokalen Variablen benutzt werden TypeExpression ist ein String, der diesen Typ definiert.
Mapping Eine Abbildung ist ein Ausdruck, der zur Abbildung von Modellelementen
benutzt wird (siehe 3.1.1.4 Abhängigkeiten, 67). Aus Gründen der Austauschbarkeit sollte dieser als String repräsentiert werden.
Name Im Metamodell definiert Name ein Token, welches zur Benennung von Modellelementen benutzt wird. Jeder Name hat eine entsprechende Darstellung als String.
3.1. FUNDAMENT
78
Expression
<<primitive>>
Integer
<<enumeration>>
AggregationKind
<<primitive>>
UnlimitedInteger
<<enumeration>>
Boolean
<<primitive>>
String
<<enumeration>>
CallConcurrencyKind
<<primitive>>
Time
<<enumeration>>
ChangeableKind
LocationReference
<<enumeration>>
MessageDirectionKind
Multiplicity
language : Name
body : String
Mapping
body : String
Name
body : String
+range
1
<<enumeration>>
OperationDirectionKind
<<enumeration>>
OrderingKind
<<enumeration>>
ParameterDirectionKind
<<enumeration>>
ScopeKind
<<enumeration>>
PseudostateKind
<<enumeration>>
VisibilityKind
Abbildung 3.30: Datentypen (2)
1..*
MultiplicityRange
lower : Integer
upper : UnlimitedInteger
79
LocationReference Ein Ortsverweis (LocationReference) bezeichnet eine Position innerhalb einer Verhaltenssequenz für die Einfügung eines erweiterten Anwendungsfalls. Dies kann z.B. eine Code-Zeile oder ein Zustand eines Zustandsautomaten
sein.
Multiplicity Im Metamodell definiert eine Kardinalität eine Menge von nichtnegativen ganzen Zahlen (Integer). Eine Menge, die nur die Null enthält ({0}), ist keine
gültige Kardinalität. Jede Kardinalität hat (mindestens) eine entsprechende Darstellung
als String. Ein Kardinalitätsbereich (MultiplicityRange) definiert einen Bereich ganzer
Zahlen (Integer). Dabei darf die obere Grenze nicht unter der unteren Grenze liegen. Die
untere Grenze muß ein nicht-negativer Integer sein, die obere Grenze kann den speziellen
Wert „unlimited“ annehmen.
Expression
language : Name
body : String
ActionExpression
BooleanExpression
ArgListsExpression
MappingExpression
IterationExpression
ProcedureExpression
ObjectSetExpression
TypeExpression
TimeExpression
Abbildung 3.31: Ausdrücke
Expression Ein Ausdruck (Abb. 3.31) wird zu einer eventuell leeren Menge von
Exemplaren ausgewertet, wenn er in einem Kontext ausgeführt wird. Ein Ausdruck verändert nicht die Umgebung, in der er ausgewertet wird. Ein Ausdruck besteht aus einem
Namen, der die Interpretationssprache (language) angibt, mit der der Ausdruck ausgewertet wird, und einem String, der den eigentlichen Ausdruck enthält (body).
Ausdruck
ActionExpression
ArgListsExpression
BooleanExpression
IterationExpression
Semantik
Die Auswertung führt zur Ausführung einer Aktion.
Die Auswertung ergibt eine eine Menge von Listen, die aus Objekten bestehen.
Boolescher Ausdruck, dessen Auswertung true
oder false ergibt.
Die Auswertung ergibt ein Iterationskonstrukt in
der durch language spezifizierten Sprache.
3.2. VERHALTENSELEMENTE
Ausdruck
MappingExpression
ObjectSetExpression
ProcedureExpression
TimeExpression
TypeExpression
3.2
80
Semantik
Die Auswertung ergibt eine Abbildung.
Die Auswertung ergibt eine Menge von Exemplaren. ObjectSetExpressions werden zur Bezeichnung der Zielexemplare einer Aktion benutzt. Der Ausdruck kann aus dem reservierten Wort „all“ bestehen, wenn er als Ziel einer
Sende-Aktion (siehe 3.2.1.2) benutzt wird. Die
Auswertung enthält dann alle Exemplare, die das
Signal empfangen können.
Die Auswertung ergibt ein Exemplar einer Prozedur.
Die Auswertung ergibt ein Exemplar von Time.
Ein String, der einen Typ in einer Programmiersprache darstellt.
Verhaltenselemente
Die UML enthält Verhaltenselemente, mit denen funktionale und dynamische Aspekte
eines Systems dargestellt werden können (Abb. 3.32).
Eine Kollaboration (Paket Collaborations) bezeichnet eine Gruppe von Objekten,
die spezielle Rollen ausüben und zusammenarbeiten, um ein Verhalten zu zeigen, das
mehr ist als die Summe seiner Einzelteile. Eine Kollaboration definiert einen Kontext,
in dem Objekte Botschaften austauschen, um eine bestimmte Aufgabe zu erfüllen. Der
Botschaftenaustausch zwischen den Objekten kann in der UML durch zwei verschiedene Interaktionsdiagramme dargestellt werden: Kollaborationsdiagramm und Sequenzdiagramm.
Ein Kollaborationsdiagramm zeigt die strukturellen Beziehungen zwischen den Objekten (Kollaboration), auf deren Basis der Botschaftenaustausch (die Interaktion) stattfindet. Die Botschaften werden zwischen den beteiligten Objekten gruppiert, d.h. die
Beziehungen und die Kommunikation zwischen den Objekten wird in den Vordergrund
gestellt. Der zeitliche Ablauf der Interaktion rückt in den Hintergrund, kann aber durch
Nummerierung der Botschaften gekennzeichnet werden
Sequenzdiagramme beschreiben ein Szenario, in dem die Interaktion von Objekten
zeitlich geordnet dargestellt wird. Im Gegensatz zum Kollaborationsdiagramm stellt ein
Sequenzdiagramm den zeitlichen Ablauf in den Vordergrund, ohne die strukturellen Beziehungen zu zeigen.
Beide Arten der Interaktionsdiagramme heben den Kontrollfluß zwischen Objekten
hervor.
Ein Zustandsdiagramm (statechart) ist die graphische Darstellung eines endlichen Au-
81
Activity Graphs
Collaborations
Use Cases
State Machines
Common
Behavior
Abbildung 3.32: Paketübersicht der Verhaltenselemente
tomaten (Paket StateMaschines). Mit endlichen Automaten kann das Verhalten von
Objekten (oder Systemen) modelliert werden, bei denen das Verhalten von ihrer Vergangenheit abhängt. Objekte können auf Ereignisse wie z.B. Signalereignisse, die asynchron
auftreten, oder Operationsaufrufe (meist synchron) reagieren. Wenn ein Ereignis eintritt,
kann findet eine Reaktion statt, die vom aktuellen Zustand des Objekts abhängt. Endliche
Automaten werden z.B. benutzt, um die Aufrufreihenfolge von Operationen auf einem
Objekt einzuschränken. Mit ihnen wird modelliert, wann eine Operation angewandt wird
(dynamisches Modell). Zustandsdiagramme zeigen den Kontrollfluß von Zustand zu Zustand, d.h. den Kontrollfluß innerhalb eines Objekts oder auch eines Systems.
Ein Aktivitätsdiagramm (Paket ActivityGraphs) zeigt den Kontrollfluß von Aktivität zu Aktivität. Aktivitätsdiagramme sind spezielle Zustandsdiagramme, deren Zustände größtenteils Aktivitätszustände sind. Ein Aktivitätsdiagramm ist im wesentlichen ein
Flußdiagramm (flowchart), welches auch nebenläufige Flüsse enthalten kann. Aktivitätsdiagramme werden zur Beschreibung komplexer Operationen oder zur Verfeinerung von
Anwendungsfällen eingesetzt.
Das Paket CommonBehavior enhält die Infrastruktur für die abhängigen Pakete aus
Abb. 3.32. Das Paket definiert Objekte, Links und andere Exemplare zur Modellierung
struktureller Beziehungen, und Signale und Aktionen (z.B. Operationsaufrufe), die von
den abhängigen Paketen benötigt werden.
3.2.1
82
Allgemeines Verhalten
Im Inneren des Systems kommunizieren Objekte miteinander durch das Versenden von
Botschaften. Das sendende Objekt (sender) verschickt eine Botschaft, das empfangende
Objekt (receiver) empfängt eine Botschaft. Eine Botschaft benutzt einen Link als Kommunikationskanal, über den die Botschaft zwischen den Objekten ausgetauscht wird. Eine
Botschaft kann durch Argumente näher spezifiziert werden. Eine konkrete Botschaft (ein
Exemplar einer Botschaft) wird in der UML Stimulus genannt.
Es gibt zwei grundsätzliche Arten von Botschaften:
1. Ein Signal ist eine Botschaft zwischen einem auslösenden Objekt und allen Objekten, die dieses Signal zu diesem Zeitpunkt empfangen können. Bei den Empfängern
führt der Empfang des Signals zu einer Zustandsveränderung.
2. Ein Operationsaufruf ist eine Botschaft zwischen einem Sender (dem Aufrufer)
und einem festgelegten Empfänger, der die gewünschte Operation ausführt.
Bei einem synchronen Botschaftenaustausch wartet der Sender bis der Empfänger die
Nachricht verarbeitet hat, bei asynchroner Kommunikation wartet der Sender nicht und
kann parallel weiter arbeiten. Bei sequentieller Verarbeitung ist nur ein Objekt zu einem
Zeitpunkt aktiv, während bei einer parallelen Verarbeitung mehrere Objekte zu einem
Zeitpunkt aktiv (nebenläufig) sind. Eine parallele Verarbeitung kann vorliegen, wenn das
System auf mehrere Knoten (Prozessoren) verteilt ist. Eine pseudoparallele Verarbeitung
mit Hilfe von Prozessen oder Threads auf einem Prozessor wird ebenfalls als parallel
angesehen.
Zwischen Exemplaren können verschiedene Arten von Requests (Bitten oder Aufforderungen) existieren. Die Metadarstellung der Signale, die eine Reaktion bei den Empfängern asynchron „triggern“, wird in Abschnitt 3.2.1.1 erläutert. Die Definition von
Operationsaufrufen und anderen Requests, z.B. das Erzeugen (create) oder Zerstören (destroy) von Exemplaren wird in Abschnitt 3.2.1.2 erläutert. Abschnitt 3.2.1.3 beschreibt
die Exemplare von Klassifizierern, Attributen, Assoziationen, Botschaften, Komponenten
und Knoten.
3.2.1.1 Signale
Signal Ein Signal ist die Spezifikation eines Stimulus (Anreiz) zur asynchronen Kommunikation zwischen Exemplaren.
Signale werden als Klassen mit dem Stereotyp «signal» modelliert. Die Attribute
dieser Klasse sind die Parameter des modellierten Signals.
Im Metamodell (Abb. 3.33) ist Signal eine Unterklasse von Klassifizierer (also auch
generalisierbar), die Parameter werden als Attribute (geerbt von Classifier) dargestellt.
Die Instantiierung eines Signals ergibt dann eine konkrete Botschaft (Stimulus), die zu
83
Classifier
+signal
Signal
+raisedSignal
+context
*
*
1
BehavioralFeature
Exception
0..*
+reception
Reception
isPolymorphic : Boolean
specification : String
Abbildung 3.33: Signal, Ausnahme und Empfang
einem (Signal-) Ereignis beim Empfänger führt. Ein Signal kann mit einem Verhaltensmerkmal des Senders (context) und mit einem Verhaltensmerkmal des Empfängers
(reception) assoziiert sein.
Exception Eine Ausnahme ist ein Signal, welches von Klassifizierern typischerweise
zur Behandlung von Fehlern abgesandt wird.
Im Metamodell ist Exception eine Unterklasse von Signal und kann mit den Verhaltensmerkmalen (context), und damit mit den Klassifizierern, die dieses Signal absetzen
können, assoziiert sein.
Reception Ein Empfang ist eine Deklaration eines Klassifizierers, auf den Empfang
eines Signals (signal) vorbereitet zu sein und entsprechend zu reagieren. Die Reaktion
auf den Empfang wird durch einen String (specification) zusammenfassend beschrieben. Detailliert beschrieben wird die Reaktion auf den Empfang des Signals, die zu einer
Zustandsveränderung (des Exemplars) des Klassifizierers führen muß, durch einen Zustandsautomaten.
Im Metamodell ist Reception eine Unterklasse von Verhaltensmerkmal (BehavioralFeature), d.h. es erbt die Attribute isAbstract, isLeaf und isRoot. Falls das
Attribut isPolymorphic den Wert false besitzt, ist die Reaktion auf den Empfang immer
84
gleich, z.B. wenn das empfangende Exemplar nur in einem Zustand das Signal empfangen kann, also so gesehen keine Vergangenheit hat). Ansonsten kann das Verhalten vom
Zustand des empfangenden Exemplars abhängen.
3.2.1.2
Aktion
Eine Aktion ist eine ausführbare, atomare Verarbeitung, die zu einer Zustandsveränderung des Systems führt. Die verschiedenen Arten einer Aktion (Abb. 3.34) sind das
Senden eines Signals (SendAction), der Aufruf einer Operation (CallAction), das Erzeugen (CreateAction), die Selbstzerstörung (TerminateAciton) und das Zerstören
(DestroyAction) eines Exemplars, die Zuweisung eines Wertes (AssignmentAction)
und die Rückgabe (ReturnAction) eines Wertes.
Action Eine Aktion kann den oder die Empfänger einer Botschaft (targetSetExpression), deren Argumente (actual) und die Art der Kommunikation (isAsynchronous)
spezifizieren. Das Attribut recurrence ist ein Iterationsausdruck, der angibt, wie die
Empfänger abgearbeitet werden bzw. wie oft die Botschaft abgeschickt wird. Action ist
eine abstrakte Metaklasse.
Das Ausführen einer Aktion bedeutet die Auswertung der Metaattribute und führt
meistens zum Versenden eines Stimulus oder mehrerer Stimuli.
Attribut
isAsynchronous
recurrence
target
script
Pseudoattribut
actual
Semantik
Gibt an, ob die Botschaft (bzw. der Stimulus) asynchron ist
oder nicht.
Iterationsausdruck, der angibt, wie oft die Aktion ausgeführt
wird.
Ein TargetSetExpression, der zu einer eventuell leeren Menge
von Exemplaren, die die Empfänger der Botschaft (der Stimuli) sind, ausgewertet wird. In der UML ist nicht definiert, ob
die Aktion sequentiell oder parallel auf ihre Ziele angewandt
wird.
Ein Ausdruck, der die Auswirkungen der Aktion beschreibt.
Semantik
Eine Argumentliste, die Ausdrücke zur Bestimmung der zur
Ausführungszeit der Aktion zu benutzenden Argumente (Exemplare) enthält.
Classifier
1
+instantiation
0..*
Abbildung 3.34: Aktionen
AssignmentAction
+action
+operation
Operation
1
*
CallAction
0..1
CreateAction
ActionSequence
{ordered}
ModelElement
ReturnAction
Action
Argument
Signal
1
*
+signal
TerminateAction
+actual
{ordered}
SendAction
0..1
*
value : Expression
UninterpretedAction
DestroyAction
85
86
ActionSequence Eine Aktionssequenz ist eine geordnete Folge von Aktionen, die
sequentiell als atomare Einheit ausgeführt wird. Sie wird benutzt, um eine Aktion eines
Zustands oder einer Transition in einem Zustandsautomaten zu beschreiben.
CreateAction Eine Erzeuge-Aktion ist eine Aktion, die ein Exemplar eines Klassifizierers erzeugt. Im Metamodell ist CreateAction eine Unterklasse von Action, die
mit genau einem Klassifizierer assoziiert ist. Eine Erzeuge-Aktion hat kein durch target
angegebenes Ziel bzw. Empfänger. Der zu instantiierende Klassifizierer wird durch das
Pseudoattribut instantiation angegeben.
DestroyAction Eine Zerstöre-Aktion führt zur Zerstörung eines Exemplars. Das betreffende Exemplar wird durch das target-Attribut der Aktion spezifiziert. Eine ZerstöreAktion hat keine Argumente.
TerminateAction Eine Terminiere-Aktion führt zur Selbstzerstörung eines Exemplars. Das Ziel dieser Anweisung ist implizit das Exemplar, welches die Aktion ausführt,
d.h. es gibt kein explizites Ziel.
CallAction Eine Aufruf-Aktion ist eine Aktion, die eine Operation eines Exemplars
aufruft. Der Aufruf kann synchron oder asynchron sein. Das Exemplar oder die Menge
von Exemplaren wird durch das Attribut target, die Argumente werden durch das (geerbte) Pseudoattribut actual und die aufzurufende Operation wird durch das Pseudoattribut operation spezifiziert. Die Anzahl der Argumente muß mit der Anzahl der Parameter der Operation übereinstimmen. Die Übereinstimmung der Typen der Argumente mit
den Typen der Parameter wird nicht gefordert! Dies ermöglicht die Argumentübergabe
an eine Operation auf verschiedene Arten (siehe Seite 174) .
ReturnAction Eine Rückgabe-Aktion ist eine Aktion, die dem Aufrufer einen Wert
zurückliefert. Im Metamodell werden die Werte durch die von Action geerbten Argumente repräsentiert. Eine Rückgabe-Aktion hat kein explizites Ziel, das implizite Ziel
dieser Aktion ist das aktivierende Exemplar, welches, z.B. durch einen Operationsaufruf, eine Folge von Aktionen aktiviert hat, die durch die Rückgabe-Aktion abgeschlossen
wird.
AssignmentAction Eine Zuweisungs-Aktion ist eine Aktion, die einem Link oder
einem Attributlink (Exemplar eines Attributs) einen Wert zuweist. Im Metamodell wird
das zugewiesene Exemplar (der Wert) durch das Argument der Aktion spezifiziert.
87
Eine Zuweisungs-Aktion besitzt die (nicht explizit dargestellten) Pseudoattribute association und attribute (siehe Abb. 3.36)13 . Sie bezeichnen die Assoziation, welcher
ein Link bzw. das Attribut, welchem ein Attributlink zugewiesen wird.
SendAction Eine Sende-Aktion sendet ein Signal. Ein Signal ist immer asynchron.
Das Signal kann an bestimmte Empfänger oder an eine Menge unbestimmter Empfänger gesandt werden (via target). Hat target den Wert all, wird das Signal an alle
Objekte, die das Signal empfangen können, gesandt. Ist das Signal z.B. eine Ausnahme (exception), wird der Empfänger durch den Mechanismus des Laufzeitsystems bestimmt14 .
+signal
SendAction
*
Signal
1
Abbildung 3.35: Sende-Aktion
Im Metamodell (Abb. 3.35) ist SendAction mit dem zu sendenen Signal assoziiert,
die Argumente werden durch das von Action geerbte Pseudoattribut actual spezifiziert.
Die Ausführung einer Sende-Aktion instantiiert ein Signal mit den angegebenen Parametern (Stimulus).
Die Anzahl der Argumente muß mit der Anzahl der Parameter (Attribute) des Signals
übereinstimmen. Auch hier wird wieder nur die Übereinstimmung der Anzahl der Argumente und Parameter gefordert.
UninterpretedAction Eine nichtinterpretierte Aktion ist eine Aktion, die nicht
explizit in der UML definiert ist. Sie ist vorgesehen für sprachspezifische Anweisungen,
die nicht den anderen Aktionen zugeordnet werden können.
3.2.1.3
Exemplare und Links
Dieser Abschnitt beschreibt Modellelemente (Abb. 3.36), die für eine exemplarische Darstellung von Struktur- und Verhaltensaspekten benötigt werden.
Instance Ein Exemplar (Instanz) definiert ein „Ding“, auf welches Operationen angewendet werden können und einen Zustand hat, der die Auswirkungen der Operation
speichert.
Im Metamodell ist Instance mit mindestens einem Klassifizierer (classifier) verbunden, welcher Struktur und Verhalten des Exemplars deklariert. Ein Exemplar kann
13 Vermutlich
sind hier die Pseudoattribute des Arguments der Zuweisungsaktion gemeint. Dies geht aus
der Dokumentation nicht hervor ([OMG99], Seite 2-86)
14 Siehe [OMG99], Seite 2.91
Classifier
Attribute
DataValue
1..*
+classifier
1
+attribute
*
*
+slot
0..1
*
1
*
*
0..1
+argument
{ordered}
Instance
+resident
+resident
+value
ComponentInstance
1
0..*
AttributeLink
*
*
*
1
1 +sender
NodeInstance
+receiver
*
Stimulus
+dispatchAction
Action
recurrence : IterationExpression
target : ObjectSetExpression
isAsynchronous : Boolean
script : ActionExpression
1
*
0..1
+communication
LinkObject
Object
+instance
1
*
ModelElement
1
1
+association
Association
1
*
Link
2..*
+connection
*
AssociationEnd
1
*
LinkEnd
+associationEnd
{ordered} 2 .. *
+connection
+linkEnd
88
Abbildung 3.36: Metamodell: Exemplare und Links
89
eine Menge von Attributen und Attributwerten besitzen. Im Metamodell besitzt ein Exemplar Attributlinks (slot, Fach), die auf die Attribute und Attributwerte verweisen.
Ähnlich wie Klassifizierer mit Assoziationsenden zur Darstellung einer Assoziation
verbunden sein können, werden ihre Exemplare mit den entsprechenden Link-Enden (Exemplar eines Assoziationsendes) zur Darstellung eines Links verbunden. Ein Exemplar
kann auch als Sender und Empfänger von Stimuli, d.h. konkreter Botschaften, dargestellt
werden. Instance ist eine abstrakte Metaklasse, für die ein Eigenschaftswert vordefiniert
ist:
Eigenschaftswert
Semantik
persistent
Wird der Wert der Eigenschaft mit „persistent“ gekennzeichnet, dann wird der Zustand des Exemplars nicht zerstört wenn
das Exemplar zerstört wird, d.h. der Zustand wird gespeichert.
Wird der Wert mit „transitory“ gekennzeichnet, dann wird der
Zustand mit dem Exemplar zerstört.
DataValue Ein Datenwert ist ein Exemplar ohne Identität. Im Metamodell ist DataValue ein Nachkomme von Instance, welches seinen Zustand nicht ändern kann, d.h.
alle auf einen Datenwert anwendbare Operationen sind reine Funktionen (keine Seiteneffekte) oder Abfragen (Query). Datenwerte werden als Attributwerte (value) benutzt.
Ein Datenwert wird von genau einem Klassifizierer (ein DataType) erzeugt und hat keine
Attributlinks, d.h. keine Attribute.
Object Ein Objekt ist ein Exemplar einer Klasse. Im Metamodell ist Object eine
Unterklasse von Instance. Ein Objekt ist das Exemplar mindestens einer Klasse. Die
Klassenzugehörigkeit eines Objekts kann dynamisch modifiziert werden, d.h. die Merkmale eines Objekts können sich währernd seiner Lebensdauer ändern. Jeder Klassifizierer
(classifier) eines Objekts muß ein Exemplar der Metaklasse Class sein.
ComponentInstance Ein Komponentenexemplar ist ein Exemplar einer Komponente und kann mehrere Zustände haben. Im Metamodell kann eine Komponenteninstanz mit Exemplaren assoziiert sein (resident), die Exemplare innerhalb einer Komponente repräsentieren. Ein Komponentenexemplar kann von genau einer Komponente
(classifier) erzeugt werden.
NodeInstance Ein Knotenexemplar ist ein Exemplar eines Knotens und kann Komponentenexemplare enthalten (resident). Jedes Komponentenexemplar, das sich auf
einem Knotenexemplar befindet, muß ein Exemplar einer Komponente sein, die sich auf
dem entsprechenden Knoten befindet. Der Klassifizierer eines Knotenexemplars muß ein
90
Exemplar der Metaklasse Node sein15 .
Linkobject Ein Linkobjekt ist ein Exemplar einer Assoziationsklasse. Im Metamodell ist ein Linkobjekt eine Verbindung zwischen Exemplaren, wobei die Verbindung
selbst Attributwerte besitzen kann und auf die Verbindung Operationen angewendet werden können. LinkObject ist ein Nachkomme von Object und Link. Ein Klassifizierer
des Linkobjekts muß mit der entsprechenden Assoziation übereinstimmen, die Assoziation muß ein Exemplar der Metaklasse AssociationClass sein16 .
Stimulus Ein Stimulus (Abb. 3.37) beschreibt eine Kommunikation zwischen zwei
Exemplaren.
Pseudoattribut
receiver
sender
argument
Semantik
Ein Exemplar, welches den Stimulus empfängt.
Ein Exemplar, welches den Stimulus sendet.
Eine Folge von Exemplaren, die die Argumente der konkreten
Nachricht sind.
communicationLink Ein Link, der zur Kommunikation genutzt wird.
dispatchAction
Eine Aktion, die bei ihrer Ausführung den Stimulus abschickt.
Die Anzahl der Argumente muß mit der Anzahl der Argumente der Aktion übereinstimmen. Die Aktion muß eine Sende-Aktion, eine Aufruf-Aktion, eine Erzeuge-Aktion
oder eine Zerstöre-Aktion sein.
Link Ein Link (Abb. 3.37) bezeichnet eine Verbindung zwischen Exemplaren. Im
Metamodell ist ein Link ein Exemplar einer Assoziation (association). Ein Link besitzt
eine (geordnete) Menge von Link-Enden (connection), die den Assoziationsenden der
Assoziation entsprechen müssen. Es darf keine Links einer Assoziation geben, die die
gleichen Instanzen auf die gleiche Art verbinden, d.h. jedes Tupel (als Exemplar einer
Assoziation) ist eindeutig.
LinkEnd Ein Link-Ende (Abb. 3.37) ist ein Exemplar eines Assoziationsendes, d.h.
ein Endpunkt eines Links. Im Metamodell ist LinkEnd der Teil des Links, der den Link
mit einem Exemplar (instance) verbindet. Ein Link-Ende entspricht genau einem Assoziationsende (associationEnd) der Assoziation des Links. Der Typ des Exemplars des
Link-Endes muß mit dem Typ des Assoziationsendes übereinstimmen.
15 Weitere Unterklassen von Node im Metamodell können so in weiteren Versionen der UML hinzugefügt
werden.
16 In weiteren Versionen werden eventuell Unterklassen von AssociationClass eingeführt.
91
Action
ModelElement
+dispatchAction
name : Name
1
*
*
*
*
2 .. *
{ordered}
1
0..1
*
+association
1
Association
* +sender 1
Instance
LinkEnd
+linkEnd
*
*
*
{ordered}
+argument
+connection
Link
+communicationLink
Stimulus
+receiver 1
1
+associationEnd 1
+connection
AssociationEnd
2..*
+instance
1
Abbildung 3.37: Link und Stimulus
Links bilden eine Verbindung zwischen Exemplaren, über die in Kollaborationsdiagrammen Stimuli verschickt werden (communicationLink). Es sind mehrere Zusicherungen für Link-Enden definiert, die in Kollaborationsdiagrammen verwendet werden:
Zusicherung
association
destroyed
new
transient
global
local
parameter
self
Semantik
Das mit dem Link-Ende assoziierte Exemplar ist durch eine
Assoziation sichtbar.
Das Exemplar wird während der Ausführung (in dem modellierten Kontext) zerstört.
Das Exemplar wird während der Ausführung erzeugt.
Das Exemplar wird während der Ausführung erzeugt und zerstört.
Das Exemplar ist sichtbar, da es in einem globalen Bereich
(scope) relativ zum Link liegt (globale Variable).
Das Exemplar ist sichtbar, da es in einem lokalen Bereich (scope) relativ zum Link liegt (lokale Variable).
Das Exemplar ist sichtbar, da es ein Parameter relativ zum Link
ist.
Das Exemplar ist sichtbar, da es der Absender eines Requests
an sich selbst ist.
3.2.2
92
Kollaborationen
Eine Kollaboration bezeichnet „[...] Gruppen von Objekten, die spezielle Rollen ausüben
und zusammenarbeiten, um ein Verhalten zu zeigen, das mehr ist als die Summe seiner
Einzelteile. Diese Rollen repräsentieren prototypische Instanzen von Klassen, Schnittstellen, Komponenten, Knoten und Anwendungsfällen“17 . Eine Kollaboration definiert einen
strukturellen Kontext als Basis für eine Interaktion zwischen den beteiligten Objekten.
Eine Interaktion von Modellelementen wird in der UML durch Interaktionsdiagramme dargestellt, von denen es zwei Versionen gibt: Sequenzdiagramme und Kollaborationsdiagramme. Ein Sequenzdiagramm hebt den zeitlichen Ablauf von Kommunikationen
zwischen Objekten hervor, ohne die strukturellen Beziehungen zwischen den Objekten zu
zeigen (Abb. 3.38) . Ein Kollaborationsdiagramm enthält die strukturellen Beziehungen
zwischen den beteiligten Modellelementen (die Kollaboration) und darauf aufbauend die
Interaktion zwischen den Modellelementen, wobei der zeitliche Ablauf durch sogenannte
Sequenznummern notiert wird.
Ein Kollaborationsdiagramm kann auf zwei verschiedenen Ebenen bzw. durch zwei
verschiedene Sichten auf die Zusammenarbeit der Modellelemente dargestellt werden.
Ein Kollaborationsdiagramm der Spezifikationsebene (Abb. 3.39) enthält Klassifiziererund Assoziationsrollen zur Darstellung des Strukturaspekts sowie Botschaften (messages)
zwischen den Klassifiziererrollen zur Spezifikation der Kommunikation. Die Rollen sind
Einschränkungen der Eigenschaften der Klassifizierer und Assoziationen, so daß nur die
für die Zusammenarbeit benötigten Merkmale gezeigt werden.
Eine Kollaboration auf einer exemplarischen Ebene kann als Instantiierung der Spezifikationsebene aufgefaßt werden. Ein Diagramm dieser Ebene enthält Exemplare von
Klassifizierern (meist Objekte), Links und Stimuli. Ein Kollaborationsdiagramm der (exemplarischen Ebene) ist semantisch äquivalent zu einem Sequenzdiagramm, da beide aus
den gleichen Informationen im Metamodell abgeleitet werden. Das bedeutet aber nicht,
daß beide Diagramme explizit die gleiche Information darstellen18 . Auf der exemplarischen Ebene kann die Erzeugung, Benutzung oder Zerstörung von Objekten bzw. Links
explizit gezeigt werden (Abb. 3.38).
Notation der Rollen in einer Kollaboration Eine Klassifiziererrolle dient zur Einschränkung der in der Kollaboration benötigten Merkmale einer Klasse und wird in einem
Klassenrechteck dargestellt. Das Klassenrechteck enthält, neben optionalen Attributen
und Operationen, eine Zeichenkette nach dem folgenden Muster:
/ Klassifiziererrolle : Klassifizierername
Eine Assoziationsrolle wird mit der normalen Assoziationslinie gezeigt. Die optionale
Benennung der Assoziationsrolle folgt der Syntax für die Klassifiziererrolle. Die Notation
für die Assoziationsendrollen entspricht der Notation für die Assoziationsenden.
17 [BRJ99a],
18 vgl.
Seite 231
[BRJ99a], Seite 282
93
3 UML Notation
ob3:C3
ob4:C4
op()
ob1:C1
[x>0] foo(x)
ob2:C2
[x<0] bar(x)
doit(z)
doit(w)
more()
Abbildung 3.38: Visualisierung einer Interaktion durch ein Sequenzdiagramm. Die vertiFigure 3-48 Sequence Diagram with Focus of Control, Conditional, Recursion,
kal gestricheltenCreation,
Linien
die Lebenslinien der Objekte. Die diese Liandsind
Destruction.
nien überlagernden Rechtecke kennzeichnen den Kontroll- oder Steuerungsfokus der Objekte. Sie geben an, wann ein Objekt innerhalb des
Programmablaufs die Kontrolle erhält. Eine Botschaft bzw. ein Stimulus an ein Objektrechteck stellt die Erzeugung eines Objekts, ein Kreuz
am Ende der UML
Lebenslinie
eines Objekts innerhalb der Se3-98
V1.3 beta R1 die Zerstörung
April 1999
quenz dar. Alternative Abläufe werden durch Botschaften dargestellt,
die eine Bedingung enthalten und deren Pfeile den gleichen Startpunkt
besitzen. (entnommen aus [OMG99], Seite 3-98)
94
Assoziationsendrolle
Klassifiziererrolle
/Leiter:Person
Projektleiter
Gruppenleiter
leitet
1
Mitarbeiter
*
/Mitarbeiter:Person
Teilnehmer
1
verantwortlich für +Projekt
*
Projekt
*
Projekt
*
Kardinalität
Assoziationsrolle
Abbildung 3.39: Kollaboration auf der Spezifikationsebene ohne Interaktion. Hinweise
auf Kollaborationsdiagramme auf der Spezifikationsebene fanden sich
nur in der offiziellen UML-Dokumentation ([OMG99], Seite 3-111).
Ein Beispiel einer Interaktion im Kontext einer solchen Kollaboration
ist selbst dort nicht vorhanden.
...
UML-Tool : Projekt
1: NamenBeteiligter()
/Mitarbeiter : Person
1.1* [i=1..n]: name := name()
1.2: name := name()
Multiobjekt
/Leiter : Person
Abbildung 3.40: Kollaboration auf der exemplarischen Ebene. Der Stern „*“ der Botschaft/des Stimulus 1.1 kennzeichnet eine Iteration. Es ist leider nicht
visuell erkennbar, welche Botschaften innerhalb der Iteration bearbeitet werden. Erweiterte Modellierungsmöglichkeiten wie Verzweigungen und Iterationen lassen Interaktionsdiagramme unübersichtlich (siehe auch Abb. 3.38) werden.
Chart Nam
Chart File
Chart Typ
95
Ein Objekt, welches die durch eine Klassifiziererrolle definierte Rolle spielt, wird
durch eine Objektbox (siehe Abb. 3.40), meistens ohne Attributanteile, dargestellt. Der
Namensanteil der Objektbox wird nach dem folgenden Muster dargestellt:
Objektname / Klassifiziererrolle : Klassifizierername
Der Objektname ist optional, d.h. eine Objektbox ohne Objektnamen wird als anonymes Objekt der Klasse angesehen. Die Klassifiziererrolle kann weggelassen werden,
falls von den Objekten der Basisklasse nur eine Rolle innerhalb der Kollaboration gespielt
wird.
Interaktion Eine Interaktion ist eine Spezifikation des Verhaltens von Objekten in einem Kontext (Kollaboration), um eine bestimmte Aufgabe zu erfüllen. Hierauf aufbauend können mögliche Interaktionsfolgen spezifiziert werden. Die Interaktionsfolge kann
durch eine einzelne Beschreibung, die Bedingungen und Verzweigungen enthält, oder
durch mehrere Beschreibungen, die jeweils einen bestimmten Pfad enthalten, spezifiziert
werden.
Eine Kommunikation wird durch eine Botschaft (message) spezifiziert, die Senderund Empfängerrollen sowie eine Aktion enthält, welche die Kommunikation initiiert. Die
Aktion gibt die Art der Kommunikation (z.B. Operationsaufruf) zusammen mit Argumentausdrücken an, welche die zu sendenden Parameter bestimmen. Als Folge der Ausführung der Aktion werden ein oder mehrere Stimuli entsprechend der Botschaft abgesetzt. Ein Stimulus enthält Referenzen auf die Sender- und Empfängerobjekte sowie eine
Folge von Objektreferenzen als Resultat der Auswertung der Argumentausdrücke.
Interaktionen werden durch Sequenz- oder Kollaborationsdiagramme dargestellt. Sequenzdiagramme (Abb. 3.38) zeigen den Verhaltensaspekt einer Kollaboration inklusive
der zeitlichen Folge der Botschaften/Stimuli. Kollaborationsdiagramme zeigen den vollständigen Kontext einer Interaktion, der zeitliche Ablauf ist aber in einem Sequenzdiagramm visuell leichter zu erfassen.
Botschaften und Stimuli in einem Kollaborationsdiagramm Ein Stimulus ist die
Kommunikation von einem Objekt zu einem anderen, während eine Botschaft die Spezifikation der Kommunikation ist.
Die Darstellungsart eines Pfeils entlang einer Assoziationslinie oder eines Links gibt
die Art der Kommunikation, z.B. synchron oder asynchron, an. Die Pfeile in Abb. 3.40
bezeichnen (verschachtelte) Operationsaufrufe. Dabei muß die verschachtelte Sequenz
(angegeben durch Sequenznummern) vollständig beendet werden, bevor die äußere Sequenz fortgesetzt werden kann.
In der Nähe des Pfeils wird die Botschaft (bzw. der Stimulus) angegeben. Die Botschaft hat die folgende Syntax ([OMG99], Seite 3-123):
Vorgänger Bedingung Sequenzausdruck Rückgabewert :=
Botschaftsname Argumentliste
96
Vorgänger ist eine durch Kommata getrennte Liste von Sequenznummern (siehe Sequenzausdruck) ohne Verzweigungsbedingung oder Iterationsausdruck, gefolgt von einem Slash (/). Dies bedeutet, daß die durch die Sequenznummern bezeichneten Botschaften vor dem Absetzen dieser Botschaft bearbeitet worden sein müssen. Die implizit durch
die Sequenznummer gegebenen Vorgänger (1.2.3 ist Vorgänger von 1.2.4) müssen hierbei
nicht explizit angegeben werden. Vorgänger werden benutzt, um nebenläufige Threads zu
synchronisieren.
Die Bedingung ist in [OMG99] nicht definiert. Nach [Alh98], Seite 183, ist die Bedingung eine in eckige Klammern gefaßte boolesche Bedingung, deren Erfüllung den
Versand der Botschaft ermöglicht.
Der Sequenzausdruck besteht aus einer durch Punkte getrennten Liste von Sequenztermen gefolgt von einem Doppelpunkt:
Sequenzterm . ... :
Jeder Term stellt eine Verschachtelungsebene innerhalb der gesamten Interaktion dar.
Jeder Sequenzterm hat die folgende Syntax:
[integer | name ] [recurrence]
integer ist eine positive Zahl, die die sequentielle Ordnung der Botschaft innerhalb
der nächst höheren Ebene repräsentiert (Botschaft 1.2.4 folgt Botschaft 1.2.3).
name ist ein String und repräsentiert einen nebenläufigen Thread. Botschaften, die
sich in dem Namen auf dieser Ebene unterscheiden (z.B. 1.2.3.a und 1.2.3.b) sind nebenläufig innerhalb dieser Verschachtelungsebene.
recurrence ist eine Bedingungsklausel ([ Bedingungsklausel ] ) oder eine Iterationsklausel (* [ Iterationsklausel ]). Die Form der Bedingungsklausel und der Iterationsklausel ist nicht von der UML vorgegeben. Eine Iteration gibt die Wiederholungshäufigkeit
der Botschaft an, z.B. [i = 1..n]. Die Botschaften werden sequentiell ausgeführt. Mit
„∗k“ kann die nebenläufige Ausführung spezifiziert werden. recurrence wird auf das
recurrence-Attribut der mit der Botschaft assoziierten Aktion (Action), z.B. ein Operationsaufruf, abgebildet.
Eine Bedingungsklausel gibt an, daß die Ausführung der Botschaft vom Wahrheitswert der Bedingungsklausel abhängt. Beispiel: [x < y]. Bedingungsklauseln werden benutzt, um bedingte Verzweigungen zu realisieren.
Der Rückgabewert besteht aus einer Liste von Bezeichnern, die die Rückgabewerte
am Ende der Kommunikation repräsentieren. Diese Bezeichner können als Argumente in
nachfolgenden Botschaften benutzt werden.
Der Botschaftsname ist der Name des Ereignisses, welches im Zielobjekt passiert.
Dies ist meist das Ereignis eines Requests, eine Operation auszuführen. Falls diese Botschaft als Operationsaufruf implementiert wird, ist der Botschaftenname der Name der
Operation und die Klasse des Empfängers der Botschaft muß diese Operation deklarieren
oder erben.
Die Argumentliste besteht aus einer geklammerten und durch Kommata getrennten
Liste von Argumenten (Aktualparameter). Jedes Argument ist entweder eine Objektreferenz oder ein Pseudocodeausdruck. Die Ausdrücke können Rückgabewerte vorheriger
97
Botschaften und Navigationsausdrücke ausgehend vom Quellobjekt benutzen. Navigationsausdrücke bestehen aus Attributen und Links des Quellobjekts und aus Attributen und
Links anderer Objekte, die durch die Links des Quellobjekts erreichbar sind. Auch hier
wird die Syntax der Ausdrücke nicht in der UML definiert.
Sequenzdiagramm Ein Sequenzdiagramm hat zwei Dimensionen. Die vertikale Dimension repräsentiert den zeitlichen Ablauf, die horizontale Dimension die beteiligten
Objekte. Syntax und Semantik der Botschaften entsprechen den Botschaften in den Kollaborationsdiagrammen. Verschiedene zusätzliche Informationen, z.B. Zeitmarken und
...
UML-Tool : Projekt
1: NamenBeteiligter()
/Mitarbeiter : Person
/Leiter : Person
1.1* [i=1..n]:
name := name()
1.2: name := name()
Beteiligte
Abbildung 3.41: Interaktion aus Abb. 3.40 in einem Sequenzdiagramm. Die Sequenznummern werden üblicherweise nicht dargestellt, da die Folge der Botschaften implizit gegeben ist.
Aktionsbeschreibungen, können am Rand des Diagramms oder in der Nähe der Pfeile
dargestellt werden.
Die Interaktionen der Kollaborations- und Sequenzdiagramme werden auf die gleichen Klassen des Metamodells abgebildet. Deshalb werden die beiden Interaktionsdiagramme als semantisch äquivalent angesehen, obwohl jede Diagrammart Modellelemente
darstellen kann, die die andere Diagrammart nicht darstellen kann.
Das Metamodellpaket Collaborations (Abb. 3.42) besteht u.a. aus der Klasse Collaboration, die aus einer Komposition von Rollen (AssociationRole, ClassifierRole) und Interaktionen (Interaction) besteht. Interaction beinhaltet eine Menge
von halbgeordneten Botschaften (Message), die jeweils mit einer Aktion assoziiert sind.
Klassen, die auf eine Kollaboration der exemplarischen Ebene schließen lassen, sind
in diesem Paket nicht vorhanden.
Abbildung 3.42: Kollaboration
AssociationEnd
+base
0..1
*
+/connection
0..1
+availableQualifier
Attribute
*
*
AssociationEndRole
collaborationMultiplicity : Multiplicity
2..*
+connection
2..*
*
1
+base
0..1
+/ownedElement
AssociationRole
1
Association
*
1
*
Feature
+communication
Connection
+constrainingElement
*
+/type
*
*
1
*
1
*
+message
+sender
1
*
+interaction
+context
Message
1..*
1
Interaction
*
1
ClassifierRole
+receiver
+availableContents
+availableFeature
*
ModelElement
*
*
Collaboration
Namespace
*
1..*
*
*
0..1
1
{xor}
Action
+/ownedElement
1
+action
*
+activator
*
+predecessor
*
*
+represented
Classifier
0..1
0..1
+represented
Operation
1
Classifier
Operation
+base
98
99
Collaboration Eine Kollaboration beschreibt, wie eine Operation (representedOperation) oder ein Klassifizierer (representedClassifier) (z.B. ein Anwendungsfall) durch die Benutzung von Klassifizierern und Assoziationen auf eine bestimmte Weise realisiert wird. Die Kollaboration definiert Rollen, die von Exemplaren und Links
gespielt werden, und Interaktionen, die die Kommunikationen zwischen den Exemplaren
definieren, während sie ihre Rollen spielen.
Eine Kollaboration spezifiert eine Sicht auf eine Gruppe von Klassifizierern. Diese
Sicht beschreibt die benötigten Beziehungen zwischen den Exemplaren der entsprechenden Rollen der Klassifizierern sowie die benötigten Merkmale und enthaltenen Modellelemente dieser Klassifizierer.
Verschiedene Kollaborationen können verschiedene Sichten auf die gleichen Klassifizierer beschreiben. Eine Kollaboration kann Modellelemente beinhalten, meistens Klassifizierer und Generalisierungen, die zur Darstellung der strukturellen Anforderungen zur
Erfüllung der Aufgabe der Kollaboration benutzt werden.
Eine Kollaboration ist ein verallgemeinerbares Element, d.h. sie kann eine Aufgabe
spezifizieren, die eine Spezialisierung der Aufgabe einer anderen Kollaboration ist.
Pseudoattribut
ownedElement
interaction
constrainingElement
Semantik
(geerbt von Namespace) Rollen, die durch die Kollaboration definiert sind. Dies sind ClassifierRoles und
AssociationRoles.
Bezeichnet die Interaktionen, die innerhalb der Kollaboration
definiert sind.
Modellelemente, die den Modellelementen der Kollaboration
weitere Bedingungen hinzufügen (z.B. Generalisierungen, Zusicherungen).
Die Klassifizierer der Klassifiziererrollen, die Assoziationen der Assoziationsrollen
und die zugesicherten Modellelemente (constrainingElement) müssen zum Namensraum der Kollaboration gehören. Falls eine Klassifizierer- oder Assoziationsrolle keinen
Namen hat, sollte sie die einzige ihres Basisklassifizierers bzw. ihrer Basisassoziation
sein. Eine Kollaboration (im strukturellen Sinne) kann nur Klassifiziererrollen, Assoziationsrollen sowie die Generalisierungen und Zusicherungen zwischen ihnen enthalten.
Interaction Eine Interaktion spezifiziert die Kommunikation zwischen Modellelementen zur Erfüllung einer bestimmten Aufgabe. Jede Interaktion ist im Kontext
(context) einer Kollaboration definiert, d.h. auch für ein Sequenzdiagramm muß zumindest implizit ein Kontext existieren.
Im Metamodell enthält eine Interaktion Botschaften (Message), die die Kommunikation zwischen Exemplaren, entsprechend der Rollen ihrer Klassifizierer, spezifiziert.
100
Alle zu sendenen Signale müssen im Namensraum der Kollaboration, zu dem die
Interaktion gehört, enthalten sein.
Message Eine Botschaft (Nachricht) spezifiziert eine bestimmte Kommunikation zwischen Rollen von Exemplaren in einer Interaktion.
Pseudoattribut
sender
receiver
action
activator
communicationConnection
predecessor
Semantik
Die Rolle des Exemplars, welches die Kommunikation initiiert
und möglicherweise eine Antwort erhält.
Die Rolle des Exemplars, welches die Botschaft empfängt und
auf sie reagiert.
Die Aktion, welche einen Stimulus entsprechend der Botschaft zum Senden veranlaßt.
Auf diese Aktion werden der Botschaftsname, Argumente, Iterationsausdrücke und
(Verzweigungs-)Bedingungen des Pfeils in einem Interaktionsdiagramm abgebildet.
Eine Botschaft, deren Empfang das Verhalten, welches zum
Abschicken dieser Botschaft führt, aktiviert. Dies ist die Botschaft, die eine Kommunikationssequenz innerhalb eines Objekts initiiert. Diese Botschaft muß in der gleichen Interaktion
enthalten sein.
Die Assoziationsrolle bzw. der Link, der zur Kommunikation
benutzt wird.
Eine Menge von Botschaften, deren vollständige Ausführung
die Ausführung dieser Botschaft ermöglicht. Diese Botschaften müssen in der gleichen Interaktion enthalten sein und den
gleichen Aktivierer (activator) besitzen.
Der Sender und der Empfänger müssen an der Kollaboration, welche den Kontext
definiert, teilnehmen. Ihre Rollen müssen durch die Kommunikationsverbindung (communicationConnection) verbunden sein.
ClassifierRole Eine Klassifiziererrolle ist eine bestimmte Rolle, die von einem
Teilnehmer einer Kollaboration gespielt wird. Sie spezifiziert eine eingeschränkte Sicht
auf die Merkmale eines Klassifizierers, die dazu dient, nicht benötigte Merkmale auszublenden bzw. einem Kommunikationspartner nicht zur Verfügung zu stellen. Die Klassifiziererrolle und ihre Merkmale werden in einem Klassenrechteck dargestellt.
Im Metamodell ist ClassifierRole Teil einer Kollaboration. availableFeature
spezifiziert die, in der Kollaboration zur Verfügung stehenden, Merkmale des Basisklassifizierers (base). availableContents spezifiziert eine Teilmenge des Inhalts des Mo-
101
dellelements des Basisklassifizierers. Das Attribut multiplicity gibt die Anzahl der
Exemplare an, die diese Rolle in der Kollaboration spielen.
AssociationRole Eine Assoziationsrolle ist eine bestimmte Benutzung einer Assoziation in einer Kollaboration.
Im Metamodell ist eine Assoziationsrolle eine eingeschränkte Sicht auf eine Assoziation (base) in einer Kollaboration. AssociationRole ist eine Komposition von Assoziationsendrollen (connection) entsprechend den Assoziationsenden der Assoziation.
Auch hier gibt das Attribut multiplicity die Anzahl der Exemplare an, die diese Rolle
in der Kollaboration spielen.
AssociationEndRole Eine Assoziationsendrolle ist der Endpunkt einer Assoziation in einer Kollaboration.
Das Attribut collaborationMultiplicity19 gibt die Anzahl der Link-Enden an,
die diese Rolle in der Kollaboration spielen, base bezeichnet die zugehörige Assoziation
und availableQualifier gibt die in der Kollaboration benutzten Qualifizierer an.
3.2.3 Zustandsautomaten
Zustandsautomaten (endliche Automaten) bzw. Zustandsdiagramme (statecharts) werden zur Modellierung des dynamischen Verhaltens von Modellelementen eingesetzt. Bei
diesen Elementen handelt es sich meist um Klassen bzw. deren Objekte, bei denen die
Reaktion auf ein Ereignis, z.B. ein Operationsaufruf, von der Vergangenheit des Objekts
abhängt.
Ein Zustandsautomat ist eine hypothetische Maschine, die sich in jedem Zeitpunkt in
einer Menge endlicher Zustände, auch Konfiguration genannt, befindet. Abhängig von
der Konfiguration, welche die relevante Vergangenheit eines modellierten Elements darstellt, können Ereignisse spezifiziert werden, auf die der Zustandsautomat (und damit das
Element) reagiert oder nicht reagiert. Die Reaktion des Automaten kann aus einer Aktion
und einer Zustandsveränderung (Transition) bestehen.
Abbildung 3.43 zeigt beispielsweise einen Zustandsautomaten einer Klimaanlage.
Durch diese Art der Modellierung kann die Aufrufreihenfolge der Operationen auf einem Objekt eingeschränkt werden, die ein Objekt während seiner Lebensdauer ausführen
kann.
In den beiden folgenden Abschnitten werden die Metamodellklassen der Ereignisse
und Zustandsautomaten erläutert. Aktionen und ihre Metamodellklassen sind bereits behandelt worden (siehe Seite 84).
19 Ein
Attribut mit dem Namen multiplicity ist bereits in AssociationEnd deklariert.
102
Transitionen ohne Ereignis
werden "triggerless"
genannt
Startzustand
Endzustand
Zeitereignis/
Aktion
after( 1 hour ) / selfTest()
shutDown
Ereignis (Parameter)
tooCold( desiredTemp )
Idle
atTemp
Transition
tooHot( desiredTemp )
atTemp
Heating
Cooling
tooHot( desiredTemp )
Activating
ready / turnOn()
TooCold( desiredTemp )
Ereignis/Aktion
Zustand
Abbildung 3.43: Zustandsautomat einer Klimaanlage
Active
103
3.2.3.1
Ereignisse
Es gibt vier Arten von Ereignissen, auf die ein Zustandsautomat reagieren kann: Signal-,
Aufruf-, Änderungs- und Zeitereignisse (Abb. 3.44).
ModelElement
Parameter
{ordered}
+parameters
*
SignalEvent
Event
0..1
CallEvent
TimeEvent
when : TimeExpression
+occurrence
*
1
Signal
+occurrence
ChangeEvent
changeExpression : BooleanExpression
*
1
Operation
Abbildung 3.44: Metamodell der Ereignisse
Event Ein Ereignis ist eine Spezifikation eines wahrnehmbaren Vorkommens. Ein
Ereignis besitzt einen Namen (geerbt von ModelElement) und kann durch Parameter
(parameter) spezifiziert werden. Event ist eine abstrakte Metaklasse.
SignalEvent Ein Signal-Ereignis bezeichnet den (asynchronen) Empfang eines Signals und ist im Metamodell mit diesem Signal assoziiert.
CallEvent Ein Aufruf-Ereignis repräsentiert den Empfang (reception) eines Requests,
eine Operation (operation) auszuführen.
Zwei Stereotypen eines Aufruf-Ereignisses sind definiert:
Stereotyp
«destroy»
«create»
104
Semantik
Eine Aufforderung an das empfangende Exemplar, sich zu zerstören.
Das empfangende Exemplar wurde gerade erzeugt. Dies ist das
einzige Ereignis, das an eine initiale Transition auf der obersten Ebene eines Zustandsautomaten geheftet werden kann.
TimeEvent Ein Zeit-Ereignis modelliert das Erreichen eines bestimmten Zeitpunkts
(deadline), der durch einen Zeitausdruck (timeExpression) spezifiziert wird.
Bei der Interpretation des Laufzeitverhaltens des Zustandsautomaten stimmt der Zeitpunkt des Auftretens des Ereignisses mit dem Empfang des Ereignisses überein. Ein Ereignis hat sogesehen keine zeitliche Dimension. Der modellierte Zeitpunkt (when) kann
absolut oder relativ (ein Timer) sein. Bei einem relativen Zeitpunkt ohne eine explizite
Startzeit beginnt der Timer mit der Aktivierung des Ausgangszustands der entsprechenden Transition. Das Zeitereignis findet nur statt, wenn beim Erreichen der Deadline der
Ausgangszustand noch aktiviert ist.
Zeitereignisse werden durch das Schlüsselwort after dargestellt, z.B. after (2 seconds) und after (10 seconds since exit from State A). Andere „Zeitereignisse“, wie z.B.
when (date = 1. Jan. 2000) sind Änderungsereignisse (s.u., [OMG99], Seite 2-134 und
Seite 3-136). Die Wahl des Attributnamens when der Metamodellklasse TimeEvent ist
verwirrend.
ChangeEvent Ein Änderungs-Ereignis (change event) ist ein Ereignis, welches durch
eine Veränderung des Systemszustands, d.h. eine Änderung von Attributwerten oder
Links, ausgelöst werden kann.
Ein Änderungsereignis wird durch das Schlüsselwort when, gefolgt von einem booleschen Ausdruck (changeExpression), modelliert. Bei der Interpretation des Laufzeitverhaltens wird dieser boolesche Ausdruck fortlaufend ausgewertet. Falls die Auswertung
den Wert wahr ergibt, findet das Änderungsereignis statt.
Ein Änderungsereignis unterscheidet sich von einer Bedingung (guard) einer Transition (s.u.), die nur ausgewertet wird, wenn ein Ereignis stattfindet. Der boolesche Ausdruck
eines Änderungs-Ereignisses wird solange fortlaufend ausgewertet, bis er wahr wird. Das
Ereignis bleibt bis zu seiner Bearbeitung bestehen, d.h. die Bearbeitung des Ereignisses wird unabhängig vom Wert des booleschen Ausdrucks zum Bearbeitungszeitpunkt
durchgeführt.
Mit when formulierte „Zeitereignisse“ sind formal Änderungsereignisse. Läßt sich
der Modellierer vom üblichen Sprachgebrauch leiten, kann dieses leicht zu Änderungsereignissen der Art when (23:49PM) führen (Beispiel: [BRJ99a], Seite 317, Abb. 20-4),
welches semantisch eher als Zeitereignis und nicht als Änderungsereignis (23:49PM ist
kein boolescher Ausdruck) interpretiert wird.
105
3.2.3.2
Zustandsautomat
Aktionen sind ausführbare, atomare Verarbeitungen, die den Zustand des Systems verändern. Die Dauer einer Aktion, z.B. ein Operationsaufruf, wird als vernachlässigbar
interpretiert. Eine Aktivität ist eine Folge von Aktionen und bezeichnet eine nicht-atomare
Ausführung innerhalb eines Zustands eines Zustandsautomaten. Eine Aktivität kann durch
ein Ereignis unterbrochen werden. Dies ist meistens eine Art Interrupt auf einer höheren
Ebene des Zustandsautomaten.
Ein Zustand ist eine Bedingung oder eine Situation während der Existenz eines Objekts. Während sich das Objekt in einem Zustand befindet, dem sogenannten aktiven
Zustand, kann das Objekt Aktionen und Aktivitäten ausführen oder auf ein bestimmtes
Ereignis warten.
Ein Transition ist eine gerichtete Beziehung zwischen Zuständen. Tritt ein bestimmtes
Ereignis ein und ist eine optionale Bedingung erfüllt, „feuert“ die Transition, d.h. ein
Zustandsübergang wird ausgeführt. Eine Transition besteht aus fünf Teilen:
1. Der Ereignis-Trigger bezeichnet ein Ereignis, dessen Empfang es dem Zustandsautomaten ermöglicht, eine Transition durchzuführen.
2. Eine optionale Bedingung (engl. guard condition, auch Wächterbedingung genannt) ist ein boolescher Ausdruck, der beim Empfang des Ereignis-Triggers ausgewertet wird. Falls der Ausdruck zum Wert wahr ausgewertet wird, wird die Transition durchgeführt. Wird keine Transition des Zustandsautomaten durch das Ereignis
„getriggert“, gilt das Ereignis als bearbeitet.
3. Der Quell-Zustand (Ausgangszustand) bezeichnet den Zustand, der vor dem Feuern
der Transition aktiv sein muß.
4. Der Ziel-Zustand (Folgezustand) bezeichnet den Zustand, der nach dem Feuern der
Transition aktiviert wird.
5. Eine Aktion, die beim Feuern der Transition, d.h. vor der Aktivierung des Folgezustands, ausgeführt wird.
Ein Zustand kann mehrere Bestandteile besitzen:
1. Ein Zustand kann einen Namen besitzen. Zustände ohne Namen sind anonyme
Zustände.
2. Entry- und Exit-Aktionen, die beim Eintritt in den Zustand (der Aktivierung des
Zustands) bzw. beim Verlassen des Zustands (seiner Deaktivierung) ausgeführt
werden.
3. Eine interne Transition ist eine Transition, bei der der Zustand nicht verlassen wird.
Insbesondere werden bei internen Transitionen die Entry- und Exit-Aktionen nicht
ausgeführt.
106
4. Ein Zustand kann Unterzustände besitzen. Dies sind Zustände, die einen Zustandsautomaten oder mehrere nebenläufige Zustandstandsautomaten innerhalb eines Zustandsautomaten repräsentieren. Der Zustand „Heating“ in Abb. 3.43 ist ein Beispiel eines Zustands, der Unterzustände besitzt. Abb. 3.46 zeigt einen Zustand, der
nebenläufige Zustandsautomaten besitzt.
5. Normalerweise ignoriert ein Zustandsautomat Ereignisse, auf die er nicht durch eine Transition reagieren kann. Die ignorierten Ereignisse gelten dann als verarbeitet.
In der UML können zu einem Zustand Ereignisse spezifiziert werden, auf die in diesem Zustand nicht reagiert wird, die aber in anderen Zuständen verarbeitet werden
sollen. Diese Ereignisse werden verzögerte Ereignisse (deferred events) genannt
(siehe [BRJ99a], Seite 337). Die Verzögerung eines Ereignisses bedeutet, daß das
Ereignis nicht stattgefunden hat. Ein verzögertes Ereignis ereignet sich erst bei der
Aktivierung eines Zustands, der dieses Ereignis nicht verzögert.
Falls nicht anders festgelegt, beginnt der Zustandsautomat eines Unterzustands in seinem Anfangszustand. In manchen Situationen (z.B. bei einem Interrupt auf einer höheren
Ebene) ist es wünschenswert, die Konfiguration eines komplexen Zustands (Kompositionszustand) zu speichern, damit dieser bei der nächsten Aktivierung wiederhergestellt
werden kann. Dazu bietet die UML das Konzept der Erinnerungszustände (history-states)
an. Ein Erinnerungszustand ist ein Pseudozustand, der es einem Zustand ermöglicht, sich
seinen letzten aktiven Unterzustand zu merken (siehe Abb. 3.45).
Ist eine Reaktivierung eines Kompositionszustands in seiner vorherigen Konfiguration
erwünscht, wird dies durch eine Transition zum Erinnerungszustand modelliert. Bei der
erstmaligen Aktivierung besitzt der Kompositionszustand keine Vergangenheit und die
vom Erinnerungszustand ausgehende Transition wird ausgeführt (siehe Abb. 3.45).
Durch die Verschachtelung von Zuständen ergibt sich ein Baum von Zuständen. Die
Knoten des Baums sind Kompositionszustände, die Blätter sind einfache Zustände oder
Pseudozustände. In der UML sind zwei Arten von Erinnerungszuständen definiert: flache
und tiefe Erinnerungszustände. Ein flacher Erinnerungszustand (shallow history) speichert den letzen direkten aktiven Unterzustand eines Kompositionszustands (den aktiven
Zustand der nächsten Ebene des Baum). Flache Erinnerungszustände werden, wie in
Abb. 3.45, durch H dargestellt. Ein tiefer Erinnerungszustand (deep history) speichert
die aktiven Zustände des gesamten Teilbaums des Kompositionszustands. Tiefe Erinnerungszustände werden durch „H ∗ “ dargestellt.
Kompositionszustände können nebenläufige Bereiche enthalten, die jeweils einen Zustandsautomaten enthalten, die nebenläufig ausgeführt werden (siehe Abb. 3.46 und 4.62,
Seite 189).
Im folgenden werden die Metamodellklassen der Zustandsautomaten der UML (Abb.
3.47) erläutert.
StateMachine Ein Zustandsautomat ist ein Modellelement, welches die mögliche
Dynamik eines Modellelements (context) beschreibt. Dieses Modellelement ist entwe-
107
BackingUp
Command
H
query
Collecting
flacher Erinnerungszustand
(shallow history):
speichert den letzten
aktiven Zustand von
"BackingUp"
Startzustand der
ersten Aktivierung von
"BackingUp"
Copying
CleaningUp
Abbildung 3.45: Erinnerungszustände speichern den letzen aktiven Zustand eines Kompositionszustands (hier: BackingUp), der bei erneuter Aktivierung zur
Wiederherstellung der letzten Konfiguration des Kompositionszustands
genutzt wird. Das Beispiel zeigt den Zustandsautomaten eines BackupProgramms ohne Endzustand, welches z.B. für die Datensicherung eines
Netzwerks eingesetzt wird. Ein Systemoperator kann das Programm zu
Informationszwecken unterbrechen. Danach setzt das Programm seine
Tätigkeit, ausgehend von der letzten Konfiguration, fort.
108
Vorbereitung
RadioAn
RadioAus
ComputerAus
RadioAn
ComputerAn
ComputerAn
Arbeit
when(istGenug)
Abbildung 3.46: Der Zustand „Vorbereitung“ besteht aus zwei nebenläufigen Bereichen.
Der Zustand „Arbeit“ wird aktiviert, wenn beide Zustandsautomaten der
nebenläufigen Bereiche ihren Endzustand erreicht haben.
StateVertex
Pseudostate
kind : PseudostateKind
1
0..1
+container
*
SubmachineState
CompositeState
isConcurent : Boolean
1
SimpleState
State
+top
*
*
0..1
*
+incoming
1
+target
*
0..1
StateMachine
+outgoing
0..1
*
0..1
+source
StubState
referenceState : Name
SynchState
bound : UnlimitedInteger
1..*
+subvertex
+submachine
1
+behavior
+context
ModelElement
FinalState
0..1
0..*
0..1
0..1
+internal
+transition
+doActivity
0..1
+exit
0..1
+entry
0..1
Transition
0..*
+deferrableEvent
+effect
*
+guard
Action
0..1
0..1
1
0..1
Guard
expression : BooleanExpression
Event
0..1
+trigger
109
Abbildung 3.47: Metamodell des Zustandsautomaten
110
der ein Klassifizierer oder ein Verhaltenselement. Ein Modellelement kann durch mehrere
Zustandsautomaten beschrieben werden.
Ein Zustandsautomat setzt sich aus Zuständen zusammen, die Aktionen, Transitionen
und Bedingungen enthalten können. Ein Zustandsautomat kann neben Kompositionszuständen auch Zustände enthalten, die andere Zustandsautomaten repräsentieren (siehe
SubmachineState, Seite 113), die irgendwo im Modell spezifiziert sind.
top bezeichnet die Wurzel (Top-Level-Zustand) im Baum der Zustände eines Zustandsautomaten. Ein Zustandsautomat besitzt genau einen Top-Level-Zustand, der ein
Kompositionszustand (siehe CompositeState) sein muß. Der Top-Level-Zustand kann
keine Quelle einer Transition sein und kann in keinem anderen (Kompositions-) Zustand
enthalten sein. Wenn ein Zustandsautomat ein Verhaltensmerkmal beschreibt, kann er,
mit Ausnahme der initialen Transition, keinen Trigger vom Typ CallEvent enthalten.
CompositeState Ein Kompositionszustand ist ein Zustand, der einen oder mehrere
Unterknoten (Unterzustände) enthält. Ein Zustand (StateVertex) kann zu maximal einem Kompositionszustand gehören (Semantik einer Komposition). Jeder in einem Kompositionszustand enthaltende Zustand heißt Unterzustand des Kompositionszustands. Er
heißt direkter Unterzustand, wenn er in keinem weiteren Zustand enthalten ist. Ansonsten wird er transitiv verschachtelter Unterzustand genannt. Ein Kompositionszustand
kann maximal einen Anfangszustand, einen flachen und einen tiefen Erinnerungszustand
besitzen.
Falls das boolesche Attribut isConcurrent wahr ist, besteht der Kompositionszustand aus zwei oder mehreren direkten nebenläufigen Bereichen (auch Regionen genannt).
StateVertex Ein Zustandsknoten ist eine abstrakte Metaklasse, die einen Zustand
eines Zustandsautomaten bzw. einen Knoten eines Zustandsdiagramms darstellt. Diese
Knoten können Quelle und Ziel einer Transition sowie Teil eines Kompositionszustands
(container) sein.
Transition Eine Transition ist eine gerichtete Beziehung zwischen einem Quellzustandsknoten (source) und einem Zielzustandsknoten (target). trigger bezeichnet ein
Ereignis (optional), das zum „Feuern“ der Transition führen kann, wenn eine optional
gegebene boolesche Bedingung (guard) erfüllt ist.
Transitionen ohne Ereignisse werden „triggerless“ genannt. effect ist eine optionale
Aktion, die während der Transition ausgeführt wird.
Guard Eine Bedingung (Wächterbedingung) ist ein boolescher Ausdruck, der an eine
Transition geheftet ist und das Feuern der Transition kontrolliert. Der Ausdruck wird ausgewertet, wenn das mit der Transition assoziierte Ereignis (trigger) eintritt. Wenn die
Auswertung den Wert wahr ergibt, wird die Aktion (effect) ausgeführt und der Folge-
111
zustand aktiviert. Die booleschen Ausdrücke der Transitionen sollten reine Funktionen,
d.h. ohne Seiteneffekte, sein.
State Ein Zustand ist eine abstrakte Metaklasse, die eine Situation repräsentiert, in
der eine (meist implizite) Bedingung gilt (z.B. Warten auf ein Ereignis, Ausführen einer
Aktivität).
Pseudoattribut
stateMachine
internal
entry
exit
doActivity
deferrableEvent
SimpleState
Semantik
Zustandsautomat, zu dem der Zustand gehören kann.
Bezeichnet eine Transition, die zum Zustand selbst gehört (interne Transition). Die Ausführung dieser Transition führt nicht
zur Anwendung der Entry- und Exitaktionen, d.h. diese Transition führt nicht zu einer Zustandsveränderung des Zustandsautomaten.
Bezeichnet eine Aktion, die bei der Aktivierung des Zustands
ausgeführt wird (Eintrittsaktion).
Bezeichnet eine Aktion, die bei der Deaktivierung des Zustands ausgeführt wird (Austrittsaktion).
Bezeichnet eine Aktivität (Action kann eine Sequenz von Aktionen sein), die ausgeführt wird, wenn der Zustand aktiviert
ist.
Bezeichnet Ereignisse, die verzögert werden, wenn dieser Zustand aktiv ist.
Ein einfacher Zustand bezeichnet einen Zustand ohne Unterzustände.
FinalState Ein End-Zustand ist ein spezieller Zustand, der angibt, daß sein Container (ein Kompositionszustand) verarbeitet ist. Ist dieser Kompositionszustand der TopZustand des Zustandsautomaten, dann ist der Zustandsautomat vollständig verarbeitet.
Ein End-Zustand besitzt keine ausgehenden Transitionen.
PseudoState Ein Pseudozustand ist ein Hilfszustand, der aus technischen Gründen
benötigt wird. Die folgenden sieben Arten eines Pseudozustands (Attribut: kind) sind
definiert:
• initial: Ein Initialpseudozustand ist der Anfangszustand eines Zustandsautomaten bzw. eines Kompositionszustands. Ein Kompositionszustand hat maximal einen
Anfangszustand.
112
• deepHistory: (tiefer Erinnerungszustand) Eine Notation, die die letzte aktive Konfiguration des Kompositionszustands repräsentiert, der diesen Pseudozustand enthält (H ∗ ). Ein Kompositionszustand hat maximal einen solchen Knoten. Eine Transition kann diesen Knoten als Quelle mit einem Initialzustand als Ziel verbinden.
Diese Transition wird ausgeführt, wenn der Kompositionszustand erstmalig aktiviert wird.
• shallowHistory: (flacher Erinnerungszustand) Repräsentiert den letzten aktiven
direkten Unterzustand des umschließenden Kompositionszustands, jedoch nicht die
verschachtelten Unterzustände (H). Ein Kompositionszustand kann maximal einen
solchen Knoten haben.
• join: Dient der Zusammenfassung (Synchronisation) mehrerer Transitionen aus
nebenläufigen Bereichen. Diese Transitionen dürfen keine Bedingungen (guards)
haben. In Abb. 4.63 auf Seite 190 ist ein Beispiel angegeben.
• fork: Dient der Aufspaltung einer Transition in mehrere Transitionen, die verschiedene Ziele haben (Nebenläufigkeit). Transitionen, die von diesem Knoten wegführen dürfen keine Bedingungen (guards) haben. In Abb. 4.63 auf Seite 190 ist ein
Beispiel angegeben.
• junction: Knoten, die der Verknüpfung mehrerer Transitionen dienen. Sie werden
zur Konstruktion komplexer Transitionspfade zwischen Zuständen benutzt. Dieser
Knoten kann benutzt werden, um mehrere eingehende Transitionen in eine einzige
ausgehende Transition zu vereinen. Dies wird „mischen“ (merge) genannt. Andererseits kann der Knoten zur Aufspaltung einer eingehenden Transition in mehrere ausgehende Transitionen mit verschiedenen Bedingungen (guards) benutzt werden. Dies wird statisch bedingte Verzweigung (static conditional branch) genannt.
Ausgehende Transitionen, deren Bedingungen als falsch bewertet werden, werden
deaktiviert. Die vordefinierte Bedingung else kann für maximal eine Transition
benutzt werden. Sie wird als wahr bewertet, wenn alle anderen Bedingungen nicht
zutreffen. In Abb. 4.66 auf Seite 193 ist ein Beispiel angegeben.
• choice: Auswahlknoten, mit dem eine dynamisch bedingte Verzweigung realisiert
werden kann. Beim Erreichen des Knotens werden die Bedingungen der ausgehenden Transitionen ausgewertet. Wenn mehrere Bedingungen gültig sind, wird eine
der gültigen Transitionen durch eine Funktion ausgewählt. Falls keine Bedingung
gilt, ist das Modell nicht wohldefiniert. In Abb. 4.67 auf Seite 193 ist ein Beispiel
angegeben.
SyncState Ein Synchronisationszustand ist ein Knoten, der zur Synchronisation nebenläufiger Regionen eines Zustandsautomaten benutzt wird. In Abb. 4.64, auf Seite
191 ist ein Beispiel angegeben. Ein Synchronisationszustand wird nicht wie ein Zustand
113
(State) auf einen booleschen Wert (aktiv, nicht aktiv), sondern auf einen Integer (bound)
abgebildet. Ein Synchronisationszustand wird zusammen mit fork und join benutzt, um
sicherzustellen, daß eine Region einen bestimmten Zustand oder bestimmte Zustände verläßt, bevor ein anderer Bereicht einen oder mehrere bestimmte Zustände aktivieren kann.
bound ist ein positiver Integer oder der Wert „unlimited“, der den Unterschied zwischen
der Anzahl der „gefeuerten“ eingehenden und ausgehenden Transitionen spezifiziert. Alle
eingehenden Transitionen müssen aus dem gleichen Bereich kommen und alle ausgehenden Transitionen müssen ihr Ziel ebenfalls in einem Bereich haben.
SubmachineState Ein Unterautomatenzustand ist eine syntaktische Annehmlichkeit, die Wiederbenutzung und Modularität ermöglicht. Er stellt eine notationelle Abkürzung eines Zustandsautomaten (submaschine) dar, die eine makroähnliche Expansion
der Abkürzung durch den Zustandsautomaten ermöglicht. Der eingesetzte Zustandsautomat heißt referenzierter Zustandsautomat. Der Zustandsautomat, der den Unterautomaten
enthält heißt Containerzustandsautomat. Effektiv repräsentiert ein Unterautomatenzustand einen Aufruf des assoziierten Zustandsautomaten.
In einem Zustandsdiagramm wird der referenzierte Zustandsautomat nicht vollständig
dargestellt. Transitionen in einen Unterautomatenzustand hinein oder aus ihm heraus,
werden durch Stummelzustände (StubState) dargestellt (Beispiel: Abb. 4.68, Seite 194).
StubState Ein Stummelzustand kann innerhalb eines Unterzustandsautomaten auftreten und repräsentiert einen Unterknoten eines referenzierten Zustandsautomaten (referenceState). Er kann als Quelle oder Ziel einer Transition dienen, die einen Zustandsknoten eines Zustandsautomaten mit einem Unterzustandsknoten des referenzierten
Zustandsautomanten verbindet.
3.2.4 Aktivitätsgraphen
Mit Aktivitätsgraphen bzw. Aktivitätsdiagrammen kann funktionales Verhalten von Modellelementen beschrieben werden. Sie werden zur Ablaufbeschreibung komplexer Operationen (flowchart) und zur Verfeinerung (von Operationen) von Anwendungsfällen (workflow) eingesetzt.
Aktivitätsdiagramme sind spezielle Zustandsdiagramme. Ein Aktivitätsdiagramm stellt
nicht den Klassifizierer, der Aktionen ausführt, sondern die Reihenfolge und die Bedingungen der Aktionen in den Vordergrund. Die meisten Zustände eines Aktivitätsgraphen
sind Aktivitätszustände, die sich dadurch auszeichnen, daß sie eine Aktivität ausführen
und die Vervollständigung dieser Aktivität einen Zustandsübergang (Transition) auslöst.
Eine Aktivität hat mindestens eine ausgehende Transition. Mehrere ausgehende Transitionen werden zur Fallunterscheidung benutzt. Aktivitätsdiagramme können nebenläufige Aktivitäten beschreiben. Für parallele Aktivitäten gilt, daß ihre Reihenfolge irrelevant
ist. Abbildung 3.48 zeigt ein Aktivitätsdiagramm mit den wichtigsten Modellelementen.
114
Entscheidung
[keine Cola]
[kein Kaffee]
Bestimme Getränk
Bedingung
[Kaffee gefunden]
[Cola gefunden]
Kaffeepulver in
Filter einfüllen
Behälter mit
Wasser auffüllen
Tassen
holen
Coladosen
holen
Filter in Maschine
einsetzen
Maschine anschalten
Kaffee filtern
Synchronisationsbalken
Aktivität
Kaffee
einschenken
Getränk
trinken
Abbildung 3.48: Nebenbeschäftigung der (Java) Programmierer
Ch
Ch
Ch
Abbildung 3.49: Metamodell: Aktivitätsgraph
1
+inState
*
ActionState
State
CallState
ObjectFlowState
*
*
Parameter
+parameter
+state
*
0..*
+partition
0..1
+context
isSynch : Boolean
1
*
+behavior
SimpleState
ActivityGraph
isDynamic : Boolean
dynamicArguments : ArgListsExpression
dynamicMultiplicity : Multiplicity
isDynamic : Boolean
dynamicArguments : ArgListsExpression
dynamicMultiplicity : Multiplicity
SubactivityState
SubmachineState
isConcurent : Boolean
CompositeState
+top
0..1
StateMachine
+type
1
Partition
*
*
Classifier
*
1
+contents
ClassifierInState
ModelElement
+type
0..*
115
116
Die Metamodellklassen eines Aktivitätsdiagramms sind überwiegend Spezialisierungen der Metamodellklassen eines Zustandsautomaten (Abb. 3.49).
ActivityGraph Ein Aktivitätsgraph spezifiziert das Verhalten eines Pakets, eines
Klassifizierers oder eines Verhaltensmerkmals (context) (Abb. 3.49).
Eine Partition (partition) teilt die Zustände (contents) eines Aktivitätsgraphen in
Gruppen auf. Diese Gruppen werden auch Schwimmbahnen (swimlanes) genannt. Die
Partitionierung entspricht häufig den organisatorischen Einheiten in einem Geschäftsmodell (z.B. Einkauf, Verkauf, usw.). Partitionen haben keinen Einfluß auf die dynamische
Semantik eines Modells, sie sind ein Hilfsmittel zum besseren Verständnis.
SubactivityState Ein Unteraktivitätszustand repräsentiert die Ausführung einer
nicht-atomaren Folge von Schritten, die „einige“ Zeit in Anspruch nimmt. Ein Unteraktivitätszustand ist ein Unterautomatenzustand, der einen verschachtelten Aktivitätsgraphen
ausführt.
Attribut
isDynamic
dynamicArguments
dynamicMultiplicity
Pseudoattribut
submaschine
Semantik
Boolescher Ausdruck, der angibt, ob die Aktivität nebenläufig
ausgeführt werden kann.
Bestimmt die Anzahl der parallelen Ausführungen der Untermaschinen des Zustands. Der Wert muß eine Menge von
Listen von Objekten sein, die jeweils Argumente für eine
Ausführung enthält. Dieser Ausdruck wird ignoriert, wenn
isDynamic den Wert „false“ hat.
Eine Kardinalität, die die Anzahl der parallelen Ausführungen
der Aktionen des Zustands beschränkt. Wird ignoriert, wenn
Semantik
Geerbt von SubmaschineState. Bezeichnet den referenzierten Aktivitätsgraphen innerhalb des Unteraktivitätszustand.
Der Aktivitätsgraph muß einen Anfangszustand und einen
Endzustand haben.
ActionState Ein Aktionszustand bezeichnet die Ausführung einer atomaren Aktion,
typischerweise den Aufruf einer Operation.
Ein Aktionszustand ist ein einfacher Zustand mit einer Eintrittsaktion (Entry),dessen
einzige ausgehende Transition durch die Vervollständigung der Eintrittsaktion getriggert
wird. Ein Aktionszustand kann mehrere Aktionen als Teil seiner Eintrittsaktion, aber
117
keine Exit-Aktionen, interne Transitionen oder do-Aktivitäten haben.
Attribut
Semantik
isDynamic
Boolescher Ausdruck, der angibt, ob die (Eintritts-) Aktionen
nebenläufig ausgeführt werden können.
dynamicArguments Bestimmt zur Laufzeit die Anzahl der parallelen Ausführungen
der Aktionen des Zustands. Der Wert muß eine Menge von
Listen von Objekten ergeben. Jede Liste dient als Argument
für eine parallele Ausführung. Dieser Ausdruck wird ignoriert,
wenn isDynamic den Wert „false“ hat.
dynamicEine Kardinalität, die die Anzahl der parallelen Ausführungen
Multiplicity
der Aktionen des Zustands beschränkt. Wird ignoriert, wenn
Pseudoattribut
Entry
Semantik
Geerbt von State. Bezeichnet die Eintrittsaktionen.
CallState Ein Aufrufzustand ist ein Aktionszustand mit genau einer Aufrufaktion
als Eintrittsaktion. Aufrufzustände dienen der notationellen Vereinfachung.
ObjectFlowState Ein Objektflußzustand definiert einen Objektfluß zwischen Aktionen in einem Aktivitätsgraph (siehe Abb. 3.50). Er bezeichnet die Verfügbarkeit eines
Exemplars eines Klassifizierers, möglicherweise in einem bestimmten Zustand. Die Verfügbarkeit ist meistens das Resultat einer Operation.
Aktivität1
Aktivität2
Objekt
[Zustand]
Abbildung 3.50: Als Resultat der Aktivität1 befindet sich das Objekt in dem angegebenen
Zustand. Aktivität2 setzt den Zustand des Objekts voraus.
Die Generierung eines Objekts durch eine Aktion eines Aktionszustands kann als Objektfluß modelliert werden, der durch die Vervollständigung des Aktionszustands getriggert wird. Die Benutzung des Objekts in einem nachgeordneten Aktionszustand kann als
ausgehende Transition des Objektflußzustands, die eine eingehende Transition des Aktionszustands ist, modelliert werden.
118
Attribut
isSynch
Semantik
Boolescher Ausdruck, der angibt, ob ein Objektflußzustand als
Synchronisationszustand benutzt wird.
Pseudoattribut
type
Semantik
Bezeichnet den Klassifizierer des Objekts. Der Klassifizierer
kann vom Typ ClassifierInState sein (s.u.), d.h. der Zustand kann spezifiziert werden.
Ein- oder Ausgabeparameter des Objekts. Die Parameter müssen einen Typ und eine Richtung (direction) haben, die kompatibel mit dem Klassifizierer (type) sind.
parameter
Stereotyp
«signalflow»
Semantik
Wird zur Hervorhebung benutzt, wenn der Typ des Objektflußzustands ein Signal ist.
ClassifierInState Ein ClassifierInState bezeichnet einen Klassifizierer (type),
der sich in einem bestimmten Zustand (inState) befindet. Diese Art eines Klassifizierers
kann auch in statischen strukturellen Diagrammen und Kollaborationen benutzt werden,
um z.B. Objekte zu zeigen, die nur dann von Bedeutung sind, wenn sich die Objekte in
bestimmten Zuständen befinden.
PseudoState (siehe auch Seite 111.) In Aktivitätsgraphen können ein- und ausgehende Transitionen der Pseudozustände fork und join jeden Zustandsknoten (StateVertex) als Quelle bzw. Ziel haben. Anders als in Zustandsautomaten ist die Benutzung
von fork und join in Kombination mit Kompositionszuständen nicht beschränkt.
Kapitel 4
Werkzeugunterstützung und Konsistenz
Dieses Kapitel beschreibt neben allgemeinen Anforderungen an ein UML-Werkzeug die
Möglichkeiten, in welchem Rahmen ein Werkzeug Konsistenz (Widerspruchsfreiheit) sicherstellen bzw. Konsistenzprüfungen ermöglichen kann, um sowohl Widersprüche als
auch Unvollständigkeiten in einer Systemspezifikation in UML zu verhindern oder zu
entdecken.
Als Beispiel für ein existierendes Werkzeug wird Rational Rose 98 vorgestellt. Rational Rose enthält selbst nur wenige Möglichkeiten zur Konsistenzprüfung, bietet aber die
Möglichkeit, Konsistenzprüfungen und Vervollständigungen von Modellen durch Skripte
zu realisieren.
Es wird erläutert, wie Ausschnitte von UML-Diagrammen (Klassen-, Interaktionsund Zustandsdiagramme) auf die Metamodellklassen der UML abgebildet werden und
welche Konsistenzbedingungen zwischen den Modellelementen existieren (ohne Anspruch
auf Vollständigkeit).
Die Skriptsprache von Rational Rose 98 (kurz: Rose) läßt auf ein eigenes realisiertes „Metamodell“ der UML schließen, welches von Rose benutzt wird. Die Abbildung
von Ausschnitten aus Diagrammen auf die Rose-Metamodellklassen zeigt, welche Konsistenzprüfungen sich durch Skripte in Rose realisieren lassen.
4.1
Anforderungen an ein UML-Werkzeug
Die Benutzung der UML zur Modellierung eines Softwaresystems benötigt die Unterstützung durch ein Werkzeug. In realen Entwicklungsprojekten führen bereits wenige Anwendungsfälle zu vielen verschiedenen Diagrammen, die teilweise selbst relativ komplex
sind. Veränderungen in einem Diagramm führen zu weiteren Veränderungen in abhängigen Diagrammen. So führt z.B. ein Operationsaufruf einer nichtvorhandenen Operation in
einem Interaktionsdiagramm zu einer Inkonsistenz, wenn die Klasse des Empfangsobjekts
diese Operation nicht deklariert. Wird der Name einer Klasse in einem Diagramm geändert, muß der Name auch in anderen Diagrammen geändert werden. Kosten werden also
119
4.1. ANFORDERUNGEN AN EIN UML-WERKZEUG
120
nicht nur durch das zeitaufwendige Neuzeichnen von Diagrammen, sondern auch durch
die „Synchronisation“ der Diagramme untereinander zur Sicherstellung eines konsistenten Systementwurfs verursacht, die ohne Werkzeugunterstützung jeden wirtschaftlichen
Rahmen sprengen würden.
Ein UML-Werkzeug sollte die folgenden Merkmale unterstützen:
• Zeichnen von Diagrammen: Ein Werkzeug sollte nicht nur das reine Zeichnen
aller Diagramme in ihrer gesamten Komplexität ermöglichen, sondern die Notation der Diagrammelemente verstehen und unterstützen, ohne die Freiheit des Modellierers einzuschränken. So sollte z.B. im Falle zweier assoziierter Klassen das
Verschieben einer Klasse nicht dazu führen, daß die Verbindungslinie zwischen den
Klassen mitten durch eine andere Klasse verläuft.
Das Werkzeug sollte die Semantik der UML zumindest soweit verstehen, daß eine
grundsätzlich falsche Benutzung von Modellelementen nicht möglich ist und vor
einer inkonsistenten Benutzung gewarnt wird.
Das Werkzeug sollte Änderungen an der Spezifikation eines Modellelements in einem Diagramm automatisch für das gesamte Modell durchführen.
• Fachlexikon: Das Werkzeug sollte die zentrale Speicherung von Fachbegriffen
des Anwendungsbereichs unterstützen, damit Kommunikationsstörungen zwischen
Entwicklern und Anwendern bzw. Fachbereichsexperten minimiert werden.
• Navigation: Das Werkzeug sollte die Navigation durch das Modell erleichtern, z.B.
sollte man ein Modellelement durch verschiedene Diagramme verfolgen können.
• Mehrbenutzerunterstützung: Das Programm sollte mehreren Benutzern die Arbeit an einem Modell ermöglichen, ohne daß sie sich gegenseitig behindern.
• Konsistenzprüfung: Da ein UML-Modell nicht zu jedem Zeitpunkt der Modellierung konsistent sein kann, sollte das Werkzeug eine dem Entwicklungsstand angepaßte Konsistenzprüfung auf Wunsch des Benutzers ermöglichen. Je früher Inkonsistenzen aufgedeckt werden, desto geringer sind die Fehlerbeseitigungskosten.
• Codeerzeugung: Das Werkzeug sollte aus den (mühsam gesammelten) Informationen des Modells Codefragmente in der gewünschten Implementationssprache
erzeugen können. Auch hier ist eine Konsistenzprüfung vor der Codeerzeugung
sinnvoll.
• Reverse-Engineering: Da die UML auch zur Dokumentation bestehender Systeme
genutzt werden kann, sollte das Werkzeug aus vorhandenem Code Modelle erzeugen können. Dies ermöglicht zusammen mit der Codeerzeugung das sogenannte
Round-Trip-Engineering, d.h. Veränderungen in der tatsächlichen Realisierung
des Systems können in dem UML-Modell des Systems erfaßt werden.
121
KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
• Dokumentation: Das Werkzeug sollte die Dokumentation von Modellelementen,
auch durch externe Dokumente, ermöglichen und auf Wunsch alle zu einem Modellelement gehörenden Informationen generieren, d.h. z.B. in welchen Diagrammen
und mit welchen anderen Modellelementen ein Modellelement benutzt wird.
• Wiederverwendbarkeit: Ein Vorteil des objektorientierten Ansatzes, sei es nun
der Entwurf oder die Implementierung in einer objektorientierten Sprache, ist die
Wiederverwendbarkeit von bestehenden objektorientierten Systemen. Deshalb sollte das Werkzeug nicht nur in der Lage sein, Teile von Modellen aus früheren Projekten zu importieren, sondern im Falle des Imports von Komponenten auch deren
Realisierung.
Zur Unterstützung der Wiederverwendbarkeit ist eine Datenbank vorhandener (und
bewährter) Modelle sinnvoll. In diesem Zusammenhang ist auch eine Analyseund Entwurfsmusterdatenbank wünschenswert. Diese Muster (patterns) stellen (abstrakte) Lösungen für häufig auftretene Probleme dar, die bereits verifiziert sind und
sich in der Praxis bewährt haben.
• Anpassungsfähigkeit und Erweiterbarkeit: Das Werkzeug sollte an die Anforderungen spezieller Einsatzgebiete, z.B. Geschäftsprozeßmodellierung oder Modellierung von Echtzeitsystemen angepaßt oder erweitert werden können.
• Schnittstellen zu anderen Werkzeugen: Das Werkzeug sollte Schnittstellen zu
anderen in einer Systementwicklung eingesetzten Werkzeugen, z.B. Programmierumgebung (Editor, Compiler, Debugger), Projektmanagement, Konfigurations- und
Versionsmanagement, besitzen.
• Interoperabilität mit anderen UML-Werkzeugen: Das Werkzeug sollte UMLModelle exportieren und von anderen Werkzeugen importieren können.
4.2
Konsistenz
Das UML-Metamodell definiert Modellelemente in Form von abstrakten und konkreten
Metamodellklassen, Regeln zur Verwendung der Modellelemente und die daraus resultierende Semantik und Bedingungen, welche die Verwendungsmöglichkeiten auf Grund der
Spezifikation der Modellelemente einschränken. So sind z.B. Klassen generalisierbare
Modellelemente, die durch Attribute und Operationen spezifiziert und durch Generalisierungen miteinander verbunden werden können, falls bestimmte Bedingungen, z.B. die
mehrfache Deklaration eines Attributs in einer Klasse und einer Oberklasse, nicht verletzt
werden. Es gibt Modellelemente, deren Existenz die Existenz anderer Modellelemente
voraussetzt. So setzt z.B. eine Botschaft, die eine Operation auf einem Objekt aufruft,
voraus, daß das Objekt auf einer existierenden Klasse basiert, welche die aufzurufende
Operation deklariert hat.
4.2. KONSISTENZ
122
Bei der Modellierung eines Systems mit der UML wird das System üblicherweise
durch mehrere ineinandergreifende Sichten (Anwendungsfallsicht, logische Sicht, usw.)
beschrieben. Jede Sicht besteht meist aus mehreren Diagrammen und Diagrammarten,
die wiederum selbst aus Modellelementen bestehen.
Semantik
Graphische Darstellung und Systemspezifikation
UML-Metamodell
UML Notation
Guide der OMG
Modellebene
Metamodellebene
(in UML-Notation dargestellt)
Besteht aus:
• abstrakten Metaklassen (ModelElement, Classifier, Relationship usw.),
• konkreten Metaklassen (Class, Attribute, Association usw.), deren Exemplare (Modellelemente) eine
graphische Darstellung besitzen und/oder zur Spezifikation
eines Modells benutzt werden
• Generalisierungen und Assoziationen zwischen den Metaklassen.
•
•
Erläutert die graphische Darstellung der semantischen Konzepte (forward mapping to notation).
Beschreibt verschiedene Optionen zur Darstellung von Modellinformationen (Auslassung
von Informationen bis hin zu
alternativen Darstellungen, läßt
Freiraum für Werkzeuge)
Das Metamodell definiert die Semantik der Metaklassen, mögliche und notwendige Beziehungen zwischen Modellelementen
sowie Bedingungen an die Spezifikation der Modellelemente,
die auch von der Beziehung zu anderen Modellelementen abSemantik und
hängen können.
Bedingungen
Exemplar von
Metamodellexemplar
•
•
beschreibt
Notation
UML-Modell
(formales, i.a. nicht sichtbares UML-Modell)
(graphische Darstellung)
Besteht aus Exemplaren der konkreten Metaklassen (z.B.
der Klasse „Person“ und dem Attribut „name“).
Kann als Objektdiagramm dargestellt werden, deren Objekte und Links auf den Klassen bzw. Assoziationen des
Metamodells basieren.
Besteht aus verschiedenen, ineinandergreifenden Sichten auf ein System.
Die Sichten bestehen aus Diagrammen, die Elemente eines Systems und ihre gegenseitigen Beziehungen spezifizieren und darstellen.
Abbildung 4.1: Metamodell, Metamodellexemplar und die Sicht des Benutzers auf das
Modell.
Formal kann ein solches UML-Modell auch durch ein Metamodellexemplar (Modell)
beschrieben werden (siehe Abb. 4.1), bei der die Modellelemente des UML-Modells
Instantiierungen der Metamodellklassen sind. In UML-Notation wäre dies ein einziges
Objektdiagramm, dessen Objekte und Links auf den Klassen und Assoziationen des Metamodells basieren (siehe Abb. 4.2). Ein solches Metamodellexemplar wird bereits durch
die Verwendung weniger Modellelemente so unübersichtlich, daß niemand ernsthaft versuchen wird, ein Metamodellexemplar eines UML-Modells mit mehreren Diagrammen
darzustellen.
123
Abbildung 4.2: Die Klasse „Person“ als Metamodellexemplar.
4.2. KONSISTENZ
124
Diagramme und Sichten eines UML-Modells, die die Zusammenhänge zwischen Modellelementen darstellen, zeigen eine Sicht auf einen Ausschnitt des Metamodellexemplars.
Ein UML-Modell ist konsistent bzw. widerspruchsfrei zum UML-Metamodell, wenn
ein durch die Diagramme und Sichten beschriebenes Metamodellexemplar existiert. In
diesem Fall sind die Bedingungen des Metamodells erfüllt, d.h. die Sichten auf das Metamodellexemplar bzw. auf das System widersprechen sich nicht.
Da ein UML-Modell aus ineinandergreifenden Sichten und Diagrammen besteht, reicht
es nicht aus, jedes einzelne Diagramm auf Einhaltung der Bedingungen des Metamodells
zu überprüfen, d.h. eine Überprüfung eines UML-Modells auf Einhaltung der Bedingungen des Metamodells muß notwendigerweise auf einem äquivalenten diagrammübergreifenden Metamodellexemplar basieren.
4.2.1
Sinn einer Konsistenzprüfung
Wie jedes Projekt steht ein Softwareentwicklungsprojekt unter Kostendruck. Betrachtet
man die Fehlererkennungs- und -beseitigungskosten ([Bal98], Seite 286) einer Softwareentwicklung, so ist offensichtlich, daß Wert auf Fehlervermeidung und, da sich Fehler nie
ganz ausschließen lassen, auf eine frühzeitige Fehlererkennung gelegt werden muß. Hier
kann ein Werkzeug helfen, indem es eine inkonsistente Verwendung von Modellelementen nicht erlaubt oder auf eine inkonsistente Verwendung hinweist. Eine werkzeugunterstützte Konsistenzprüfung zu einem vom Benutzer bestimmten Zeitpunkt hilft, Fehler
zu entdecken, die selbst von einem aufmerksamen Leser bzw. Kritiker des Modells aufgrund der Komplexität des Modells leicht übersehen werden können. Daher ist auch die
Überprüfung „einfacher“ Konsistenzbedingungen nicht zu unterschätzen.
4.2.2
Probleme der (werkzeuggestützten) Konsistenzprüfung
Eine vollständige und werkzeuggestützte Sicherstellung oder Prüfung der Konsistenz von
UML-Modellen ist aus mehreren Gründen nicht möglich:
1. In der praktischen Anwendung der UML ist es üblich, daß ein Modellierer nicht nur
wohlgeformte Modelle entwickelt, sondern zur Vereinfachung bestimmte Elemente
ausläßt, die eventuell zu einer Konsistenzprüfung notwendig sind (Modellunvollständigkeit).
2. Während der gesamten Lebensdauer eines Modells unterliegt das Modell fortlaufenden Veränderungen, so daß Konsistenz nicht zu jedem Zeitpunkt möglich ist.
Deshalb muß ein Werkzeug Inkonsistenzen zulassen und eine Konsistenzprüfung
zu einem vom Benutzer bestimmten Zeitpunkt unterstützen.
3. Eine werkzeuggestützte Konsistenzprüfung setzt voraus, daß das Werkzeug Syntax
und Semantik der UML versteht. Die Definition der UML überläßt dem Model-
125
lierer in vielen Situationen die Wahl, in welcher Form (natürliche Sprache, Pseudocode, OCL) er Informationen in einem Modell hinterlegt. Dies erhöht die Ausdrucksstärke der Sprache auf Kosten der Möglichkeiten einer werkzeuggestützten
Konsistenzprüfung.
4. Das UML-Metamodell beschreibt die Semantik der UML, aus denen sich weitere,
nicht explizit im Metamodell formulierte, Konsistenzbedingungen ableiten lassen.
Bevor diese geprüft werden können, müssen sie jedoch erst identifiziert werden
(Vollständigkeitsproblem).
5. Die Rückabbildung eines UML-Modells auf ein Metamodellexemplar bzw. auf die
Metamodellklassen ist nicht durchgängig hinreichend formal definiert. Für Interaktionsdiagramme der exemplarischen Ebene existieren keine entsprechenden Metamodellklassen im Kontext einer Kollaboration, während für die, in der verwendeten Literatur mit Ausnahme von [OMG99] nicht erwähnten, Interaktionsdiagramme der Spezifikationsebene Metamodellklassen existieren (Unvollständigkeit des
UML-Metamodells).
6. Die Umsetzung eines UML-Modells in eine Programmiersprache impliziert weitere
Konsistenzbedingungen, z.B. unterstützt Java keine Mehrfachvererbung, die zwar
außerhalb der hier benutzten Definition von konsistenten UML-Modellen liegen,
aber dennoch von einem Werkzeug unterstützt werden sollten.
4.2.3
Ein hypothetisches Werkzeug zur Konstruktion konsistenter
Modelle
Das UML-Metamodell ist ein logisches Modell, anhand dessen die Semantik der UML
erläutert wird, aber kein physisches Modell, welches die Implementation eines Werkzeugs
beschreibt. Ein Werkzeug, welches die Konsistenz von UML-Modellen unterstützen und
prüfen soll, muß das logische UML-Metamodell auf irgendeine Weise implementieren.
Das UML-Metamodell kann als konzeptionelle Basis für ein Metamodell eines Werkzeugs dienen (Abb. 4.3). Dabei muß das UML-Metamodell an implementationsspezifische Details angepaßt und u.a. um Metamodellklassen, die der Darstellung der Modellelemente dienen (die Metamodellklasse PresentationElement ist bereits im Metamodell
vorhanden), erweitert werden. Die Darstellungsmöglichkeiten eines Werkzeugs wird i.a.
eine Teilmenge der in [OMG99] angegebenen Möglichkeiten sein.
Ein Werkzeug kann die Konstruktion von konsistenten Modellen auf mehrere Arten
unterstützen:
• Inkonsistenzvermeidung: Das Werkzeug vermeidet die Verletzung von Konsistenzbedingungen, indem es eine Verletzung bestimmter Bedingungen nicht zuläßt (z.B.
die inkonsistente Modellierung einer Generalisierung zwischen einer Klasse und
einem Interface).
Metamodellebene
Modellebene
•
•
•
beschreibt
Besteht aus Exemplaren der konkreten Metaklassen (z.B.
der Klasse „Person“ und dem Attribut „name“).
Kann als Objektdiagramm dargestellt werden, deren Objekte und Links auf den Klassen bzw. Assoziationen des
Metamodells basieren.
(formales, i.a. nicht sichtbares UML-Modell)
Metamodellexemplar
Werkzeug
Ein UML-Modell wird intern auf eine
Datenbank abgebildet, die auf die Einhaltung von Konsistenzbedingungen geprüft
werden kann.
(Datenbank)
werkzeuginternes
Modell
Ausprägung
von
beinhaltet das konzeptionelle UMLMetamodell auf eine Weise, so daß
das Werkzeug die Semantik der
UML versteht.
Erweitert das UML-Metamodell um
Metaklassen, die zur Visualisierung
der Modellelemente benutzt werden
(siehe Kapitel 3, PresentationElement)
die Metaklassen repräsentieren ein
physisches Datenbankschema
i.a. wird die Notation durch das
Werkzeug beschränkt
•
•
•
Werkzeug-Metamodell
beschreibt
Besteht aus verschiedenen, ineinandergreifenden Sichten auf ein System.
Die Sichten bestehen aus Diagrammen, die Elemente eines Systems und ihre gegenseitigen Beziehungen spezifizieren und darstellen
(graphische Darstellung)
UML-Modell
Notation
Erläutert die graphische Darstellung der semantischen Konzepte (forward mapping to notation).
Beschreibt verschiedene Optionen zur Darstellung von Modellinformationen (Auslassung
von Informationen bis hin zu
alternativen Darstellungen, läßt
Freiraum für Werkzeuge)
Das Metamodell definiert die Semantik der Metaklassen, mögliche und notwendige Beziehungen zwischen Modellelementen
sowie Bedingungen an die Spezifikation der Modellelemente,
die auch von der Beziehung zu anderen Modellelementen abSemantik und
hängen können.
Bedingungen
Exemplar von
Besteht aus:
• abstrakten Metaklassen (ModelElement, Classifier, Relationship usw.),
• konkreten Metaklassen (Class, Attribute, Association usw.), deren Exemplare (Modellelemente) eine
graphische Darstellung besitzen und/oder zur Spezifikation
eines Modells benutzt werden
• Generalisierungen und Assoziationen zwischen den Metaklassen.
•
UML Notation
Guide der OMG
UML-Metamodell
(in UML-Notation dargestellt)
Graphische Darstellung und Systemspezifikation
Semantik
4.2. KONSISTENZ
126
Abbildung 4.3: Ein hypothetisches Werkzeug (Erweiterung von Abb. 4.1)
127
• Konsistenzunterstützung: Das Werkzeug unterstützt die Modellierung konsistenter
Modelle, indem es in Situationen, in denen die Spezifikation eines Modellelementes
auf anderen Modellelementen basiert (z.B. basiert ein Objekt auf einer Klasse), eine
konsistente Auswahl der Möglichkeiten anbietet.
• Konsistenzprüfung auf Anforderung: Das Werkzeug bietet die Möglichkeit, das
konstruierte Modell, zu einem vom Benutzter bestimmten Zeitpunkt, auf die Verletzung von Konsistenzbedingungen zu prüfen.
Da ein Werkzeug auch das Erstellen inkonsistenter Modelle zulassen muß, sollten
die Konsistenzbedingungen, deren Verletzung in jedem Fall vermieden werden sollte,
sorgfältig ausgewählt werden. Zu der Kategorie der vermeidbaren Inkonsistenzen gehört die falsche Verwendung von Modellelementen, z.B. die Modellierung einer Generalisierungsbeziehung zwischen einer Klasse und einem Interface. Betrachtet man das
Werkzeug-Metamodell als physisches Datenbankschema, so könnte die Einhaltung bestimmter Konsistenzbedingungen durch die Realisierung als Integritätsbedingungen einer
Datenbank gesichert werden (z.B. darf ein Attribut nur einmal in einer Klasse deklariert
werden).
Diese Art der Realisierung kann zu Problemen führen, wenn das Werkzeug inkonsistente Modelle anderer Werkzeuge importieren können soll. Ein weiteres Problem ergibt
sich, wenn ein Modellelement aus dem Modell entfernt werden soll, von dem andere
Modellelemente abhängen. Z.B. basiert ein Operationsaufruf in einem Interaktionsdiagramm auf einem Objekt, dessen Klasse die entsprechende Operation deklariert. Bei
einem Werkzeug, welches eine Verletzung dieser Konsistenzbedingung vermeidet, würde
das Entfernen der Operation aus der Klasse entweder nicht möglich sein oder zu einem
kaskadierenden Löschen von Modellelementen führen. Beide Möglichkeiten sind im Sinne der Benutzerfreundlichkeit nicht akzeptabel.
Ein Werkzeug, welches in bestimmten Situationen eine konsistente Auswahl von Möglichkeiten anbietet, sollte in dieser Situation auch die konsistente Erweiterung der Möglichkeiten anbieten, d.h. die Erzeugung weiterer Modellelemente, auf denen die Spezifikation basiert, ermöglichen. Beispielsweise, wenn in einem Interaktionsdiagramm eine
Operation auf einem Objekt aufgerufen werden soll, werden die Operationen der Klasse
des Objekts zur Auswahl angeboten. Hat die Klasse die gewünschte Operation jedoch
noch nicht deklariert, sollte aus diesem Kontext heraus die Deklaration der gewünschten
Operation möglich sein.
Ein mit dem Werkzeug erstelltes UML-Modell beschreibt immer ein werkzeuginternes Modell, während nur ein konsistentes UML-Modell ein existierendes Metamodellexemplar beschreibt. Genügt das werkzeuginterne Modell den Konsistenzbedingungen, so
beschreibt das mit dem Werkzeug erstellte UML-Modell ein existierendes Metamodellexemplar und ist in diesem Sinne konsistent. Dazu müssen die Konsistenzbedingungen
überprüft werden, deren Verletzung nicht vom Werkzeug vermieden wird.
4.3. RATIONAL ROSE 98
4.2.4
128
Konsistenzprüfung als Informationsproduzent
Wird das Modell auf die Einhaltung von Konsistenzbedingungen geprüft und eine Inkonsistenz festgestellt, sollte das Werkzeug die folgenden Informationen liefern:
• die verletzte Konsistenzbedingung,
• Modellelemente, die für die Inkonsistenz verantwortlich sind und
• Maßnahmen zur Behebung der Inkonsistenz vorschlagen.
Bei einer Systemspezifikation mit der UML werden Modelle mit unterschiedlichen
Spezifikationsgraden erstellt. Bei einem konzeptionellen Modell ist das Modell noch
unvollständig, z.B. sind Attribute und Operationen noch nicht vollständig spezifiziert,
während dies bei implementationsspezifischen Modellen nicht mehr der Fall sein sollte. Anhand der überprüften Konsistenzbedingung sollte der Benutzer feststellen können,
ob es sich um eine inkonsistente Verwendung von Modellelementen, eine inkonsistente
Spezifikation von Modellelementen oder um eine Inkonsistenz auf Grund einer Modellunvollständigkeit handelt.
4.3
Rational Rose 98
Rational Rose 98 ist ein kommerzielles UML-Werkzeug der Rational Software Cooperation (siehe www.rational.com), also der Firma, bei der Booch, Rumbaugh und Jacobson die
ersten UML-Versionen entwickelt haben. Rational Rose 98 (im folgenden Rose genannt)
basiert auf der UML-Version 1.11 und ist verfügbar für MS-Windows und kommerzielle
Unix-Systeme. Die Unix-Version scheint eine Portierung der Windows-Version zu sein,
die über einen geringeren Leistungsumfang verfügt (4.3.2) und merkbar längere Antwortzeiten besitzt.
4.3.1
UML-Modelle in Rational Rose 98
In Rose können Anwendungsfall-, Sequenz-, Kollaborations-, Klassen-, Zustands-, Komponenten- und Einsatzdiagramme modelliert werden. Rose unterstützt keine Objekt- und
Aktivitätsdiagramme. Für die Windowsversion existiert zwar eine Erweiterung, mit der
auch Aktivitätsdiagramme modelliert werden können, aber Rose erkennt nicht die Semantik des Diagramms und die mit dieser Erweitung erstellten Aktivitätsdiagramme können
nicht in Nachfolgeversionen von Rose übernommen werden, falls diese (echte) Aktivitätsdiagramme unterstützen sollten.
Ein UML-Modell wird in Rose durch Sichten (siehe auch Abschnitt 2.4) und Pakete
strukturiert (Abb. 4.4).
1 Version
1.1 ist der direkte Vorgänger von Version 1.3
129
Abbildung 4.4: Rational Rose 98: Im linken Bereich wird der strukturelle Aufbau des
Modells durch Pakete dargestellt. Im rechten Bereich werden Diagramme
in größenveränderbaren Fenstern dargestellt. Modellelemente können per
„Drag and Drop“ aus dem rechten Bereich in ein Diagramm übernommen
werden.
130
Die Anwendungsfallsicht (use case view) besteht aus Akteuren und Anwendungsfälle, die in Anwendungsfalldiagrammen dargestellt und durch Pakete weiter strukturiert
werden können. Anwendungsfälle können durch Sequenz-, Kollaborations- und Klassendiagramme weiter spezifiziert werden, d.h. sie befinden sich in der Baumstruktur (linker
Bereich in Abb. 4.4) unterhalb eines Anwendungsfalls. Akteure, die in Rose ähnlich wie
Klassen behandelt werden, können durch Attribute und Operationen sowie durch maximal
ein Zustandsdiagramm spezifiziert werden.
Die logische Sicht (logical view) kann ebenfalls durch Pakete strukturiert werden. Die
logische Sicht besteht aus Klassendiagrammen, in denen neben Klassen, Interfaces, Akteuren und Beziehungen auch Pakete und Paketabhängigkeiten dargestellt werden können.
Jede Klasse kann durch maximal ein Zustandsdiagramm spezifiziert werden. In Rose können in der logischen Sicht auch Anwendungfall-, Sequenz- und Kollaborationsdiagramme
modelliert werden. Dabei kann aus einem Sequenzdiagramm ein entsprechendes Kollaborationsdiagramm erzeugt werden (sowie umgekehrt), bei denen sich Veränderungen in
einem Diagramm auch auf das entsprechende andere Diagramm übertragen.
Die Komponentensicht (component view) in Rose besteht aus Komponentendiagrammen und kann durch Pakete weiter struktriert werden. Für die Komponenten existieren
eine Reihe vordefinierter Stereotypen, deren graphische Darstellung durch ein eigenes
Icon unterstützt wird. Den Komponenten können Klassen und Interfaces zugeordnet werden. Diese Information wird z.B. bei der Codeerzeugung für Java genutzt. Die dynamischen Diagramme der Komponentensicht (Interaktionsdiagramme, Zustandsdiagramme
und Aktivitätsdiagramme) fehlen in der Komponentensicht von Rose.
Die Einsatzsicht (deployment view) in Rose besteht aus genau einem Einsatz- bzw.
Verteilungsdiagramm. Eine Verbindung zu den Komponenten kann nicht spezifiziert werden.
In Rose kann jedes Diagramm mit einer Notiz, entweder als reiner Text oder in Form
eines Rechtecks mit einem Eselsohr (siehe Abb. 2.12, Seite 20) versehen werden, wobei
die letztere Möglichkeit mit einem Modellelement verknüpft werden kann. Die meisten
Modellelemente können in Rose durch einen beliebigen Text dokumentiert werden (der
in dem kleinen Fenster links unten in Abb. 4.4 angezeigt wird, wenn das Modellelement
selektiert ist). Für ausführlichere Dokumentationen können in der Baumstruktur vorhandene Modellelemente2 mit Dateien und Internetadressen verknüpft werden.
Klassifizierer (Klassen, Interfaces, usw.), teilweise auch andere Modellelemente, werden nur einmal im Modell angelegt, können aber in mehreren Diagrammen verwendet
werden. Daher kann die Änderung der Spezifikation eines Modellelements auch zur Änderung der Darstellung in anderen Diagrammen führen. Bei einigen Modellelementen
kann die im Diagramm dargestellte Information diagrammabhängig selektiert werden.
Dabei kann z.B. bei Klassen sowohl der Detailliertheitsgrad von Operationen (nur der
Operationsname oder die ganze Operationssignatur) als auch der Umfang der darzustellenden Informationen (Attribute und Operationen können einzelnd ausgeblendet werden)
2 Beziehungen
zwischen Modellelementen werden nicht angezeigt.
131
eingestellt werden.
Weitere Editionsmerkmale:
• Akteure und Interfaces können wahlweise durch ihr Icon oder durch ihre Standarddarstellung visualisiert werden.
• Die Größenanpassung von zweidimensionalen Modellelementen (Klassen, Komponenten, usw.) kann wahlweise von Rose automatisch oder manuell vom Benutzer
vorgenommen werden.
• Die Diagramme sind in der Größe veränderbar (Zoom).
• Rose kann die Anordnung von Modellelementen in einem Diagramm „optimieren“
(Menü Tools, Layout Diagram). Diese Funktion ist allerding mit Bedacht anzuwenden, da die „Optimierung“ nicht rückgängig gemacht werden kann.
• Werden Modellelemente aus der Modellübersicht (linker Bereich in Abb. 4.4) in ein
Diagramm übernommen und existiert eine Beziehung zwischen diesen Elementen,
so wird diese im Diagramm dargestellt.
• Modellelemente können auf zwei Arten aus dem Diagramm entfernt werden. Wird
das Modellelement nur aus dem Diagramm entfernt, dann existiert es noch im Modell und wird, mit Ausnahme von Beziehungen, in der Modellübersicht angezeigt.
Die zweite Möglichkeit besteht aus dem Entfernen des Modellelements aus dem
Modell. Das Löschen von Beziehungen (Assoziationen, Generalisierungen, usw.)
aus einem Diagramm kann zu Problemen führen, wenn die Beziehung in keinem
Diagramm dargestellt wird. Da die Beziehung auch nicht in der Übersicht angezeigt wird, ist sie für den Modellierer visuell nicht mehr zu erfassen, obwohl sie
weiterhin im Modell vorhanden ist.
• Ausgehend von einem Modellelement kann zu den Diagrammen gewechselt werden, in denen das Modellelement vorhanden ist oder zur Spezifikation anderer Modellelemente gewechselt werden, die mit diesem Element verbunden sind. Auf diese Weise kann die Verwendung eines Modellelements im Modell verfolgt und eine
nicht mehr sichtbare Beziehung entdeckt werden.
• Teilweise können die Diagramme auch in Booch- oder OMT-Notation (re-) transformiert werden.
4.3.2 Weitere Merkmale von Rational Rose 98
Rose unterstützt mehrere Programmiersprachen, d.h. die UML-Modelle können sprachspezifisch erweitert werden und aus den UML-Modellen kann Code erzeugt werden. Teilweise ist sogar ein Round-Trip-Engineering möglich. Bei der Modellierung können meh-
132
rere Sprachen gleichzeitig unterstützt werden. Rose unterstützt u.a. C++, Java, Smalltalk, Ada, Visual Basic, Oracle 8 und kann auch IDL (Interface Definition Language) für
CORBA-Anwendungen (Common Object Request Broker Architecture) und DDL (Data
Description Language) für Datenbankanwendungen erzeugen.
In der Unix-Version fehlt u.a. die Unterstützung für Visual Basic, Smalltalk und
Oracle 8, während die Windows-Version weitergehende Visual C++ (Microsoft) Unterstützung bietet und andere Produkte von Microsoft integriert (z.B. MS Repository, MS
Visual Source Safe).
Rose unterstützt mehrere Benutzer nebenläufig, indem jedem Benutzer ein privater
Arbeitsbereich zugestanden wird und sich Modellveränderungen in diesem Bereich nicht
global auswirken. Erst der Umweg über ein Konfigurations-Management und KontrollSystem (CMVS, z.B. Rational ClearCase oder Microsoft SourceSafe) machen die Änderungen für andere sichtbar. Ein Werkzeug zur graphischen Darstellung von Unterschieden
zwischen zwei Modellen ist im Lieferumfang enthalten (Visual Differencing Tool).
Rose besitzt ein Interface (Rose Extensibility Interface , REI), welches den Zugriff
auf die Anwendung Rose selbst, die Diagramme und die Modellelemente eines RoseUML-Modells ermöglicht (Abb. 4.5). Dieses Interface kann von Rose Script3 zur Automatisierung manueller Rose-Funktionen genutzt werden. Sogenannte „Rose Automation
objects“ können das Interface ebenfalls nutzen und eröffnen die Möglichkeit per OLE
(Object Linking And Embedding) Funktionen anderer Anwendungen aus Rose heraus
auszuführen oder umgekehrt Rose-Funktionen aus anderen Anwendungen heraus auszuführen. Dabei dient Rose entweder als Controller oder als Server.
Rose
Application
Rose
Script
Rose
Diagrams
Extensibility
Interface
Model
Elements
Rose
Automation
Abbildung 4.5: Rose Extensibility Interface (REI)
3 Die
Rose Scripting Language ist eine erweiterte Version der Summit BasicScriptlanguage
(www.summsoft.com) und hat Ähnlichkeiten zu MS Visual Basic.
133
4.3.3 Konsistente UML-Modelle und Rational Rose 98
Rose unterstützt die Konstruktion von konsistenten UML-Modellen auf alle in Abschnitt
4.2.3, Seite 125 genannten Arten: Inkonsistenzvermeidung, Konsistenzunterstützung und
Konsistenzprüfung auf Anforderung.
Einige Inkonsistenzen, die auf Grund der Modellierung falscher Beziehungen entstehen würden, werden von Rose zurückgewiesen. Inkonsistenzen, die sich durch die Spezifikation der Modellelemente ergeben, werden nicht verhindert. So ist es z.B. möglich, in
einer Klasse einen Attributnamen mehrfach zu verwenden.
An Stellen, an denen die Spezifikation eines Modellelements auf einem anderen Modellelement basiert, bietet Rose eine (meist!) konsistente Auswahl an, ermöglicht teilweise eine konsistente Erweiterung der Möglichkeiten, indem das gewünschte Basiselement
aus diesem Kontext heraus erstellt werden kann, und ermöglicht teilweise eine Spezifikation von Modellelementen durch beliebigen Text, ohne einen Bezug zu einem Basiselement herzustellen. Zu einer Komponente kann angegeben werden, welche Klassen
und Interfaces sie realisiert. Hier stellt Rose eine Liste von Klassen bzw. Interfaces zur
Verfügung, die aber nicht aus diesem Kontext (Spezifikation einer Komponente) heraus
erweitert werden kann. Soll in einem Interaktionsdiagramm eine Operation auf einem
Objekt aufgerufen werden, bietet Rose als Auswahl die Operationen der Klasse des Objekts an (inklusive geerbter öffentlicher Operationen. Alternativ kann aus diesem Kontext
heraus die Klasse um die gewünschte Operation erweitert werden oder ein beliebiger Text
als Repräsentant für eine nicht existierende Operation angegeben werden.
Rose besitzt nur wenige Konsistenzprüfungen, die auf Anforderung durchgeführt werden können. Der Menüpunkt „Check Model“ aus dem Menü „Tools“ untersucht das Modell auf nicht auflösbare Referenzen. Es ist möglich, daß ein Modellelement (z.B. ein
Objekt) ein anderes Element (z.B. eine Klasse) referenziert, welches jedoch nicht existiert. In diesem Fall kann die Referenz nicht aufgelöst werden. Dieser Befehl überprüft
mehrere Konsistenzbedingungen, deren Überprüfung auch einzelnd (diagrammabhängig)
ausgeführt werden kann.
Teilweise kann vor der Codeerzeugung ein sprachabhängiger Syntaxcheck durchgeführt werden, der weitere, aber leider nicht alle, Fehler bzw. Inkonsistenzen entdeckt.
Z.B. wird die mehrfache Deklaration eines Attributs weder von Rose als Inkonsistenz der
UML, noch als syntaktischer Fehler von Java entdeckt. Der Fehler wird erst entdeckt,
wenn der Java-Compiler den Code übersetzt.
Mit Hilfe von Rose Script können weitere Konsistenzprüfungen auf Anforderung realisiert werden (siehe Kapitel 5). Da die Konsistenzprüfungen auf der Basis des werkzeuginternen Modells durchgeführt werden, wird im nächsten Abschnitt das Werkzeugmetamodell von Rose kurz vorgestellt. Anhand dieses Modells ist erkennbar, welche Informationen ein Modellierer in einem Rose-UML-Modell spezifzieren kann und welche
Informationen Rose semantisch erkennt.
4.4. DAS WERKZEUGMETAMODELL VON RATIONAL ROSE 98
4.4
134
Das Werkzeugmetamodell von Rational Rose 98
Aus der Dokumentation von Rose Script kann auf eine Klassenhierarchie geschlossen
werden, deren Klassen von Rose Script genutzt werden können, um Informationen der
UML-Modelle in Rose zu überprüfen und die Modelle zu verändern. In diesem Abschnitt
werden die wichtigsten zu diesem Zweck notwendigen Klassen mit einer Auswahl ihrer
Attribute und Operationen vorgestellt. Aus den Namen der Attribute und Operationen
kann teilweise auf Assoziationen zwischen den Klassen geschlossen werden, die nicht
dokumentiert sind und hier auch nicht explizit dargestellt werden. Modellelemente, die
in Anwendungsfall-, Komponenten- und Verteilungsdiagramme benutzt werden, werden
nicht erläutert, da sie im Rahmen dieser Arbeit nicht behandelt werden.
Da diese Klassen ebenfalls von Rose genutzt werden, geben die folgenden Abschnitte
auch einen Einblick auf die Spezifikationsmöglichkeiten von UML-Modellen in Rose.
4.4.1
Die Spitze der Klassenhierarchie
Die Klasse RoseObject ist die allgemeinste Klasse in der Klassenhierachie (Abb. 4.6).
Sie stellt Operationen zur Verfügung, mit denen z.B. überprüft werden kann, ob ein Objekt zu einer bestimmten Klasse gehört oder auch als Objekt einer bestimmten anderen
Klasse angesehen werden kann. Die Klasse Element ist mit der UML-Metamodellklasse
ModelElement vergleichbar. Das Attribut name kennzeichnet den Namen eines Elements,
Model und Application bezeichnen das Modell bzw. die Anwendung (Rose), zu der das
Element gehört.
Die Klasse RoseItem (und deren Unterklassen) stellen die Datensicht auf die Spezifikation eines Modellelements dar, während die Klasse RoseItemView (und deren Unterklassen) für die graphische Darstellung eines Modellelements und dessen Spezifikation
zuständig sind. Ein RoseItem kann ein Stereotyp besitzen, intern in Rose dokumentiert und mit einer externen Datei oder Internetadresse verknüpft werden. Die Operation
OpenSpecification öffnet ein Dialogfenster in Rose zur Spezifikation des Modellelements.
Die Datensicht auf ein Modellelement wird in den Diagrammen jeweils durch eine
Sicht (RoseItemView) dargestellt. Dadurch ist es möglich, die darzustellende Information in einem Diagramm dem Zweck des Diagramms anzupassen. Jedes Diagramm
(Diagram) kann in Rose durch beliebigen Text dokumentiert und mit graphisch dargestellten Notizen versehen werden.
4.4.2
Diagrammarten
In Rose können die graphisch dargestellten Modellelemente z.B. mit der Maus selektiert werden. Diese Information kann durch ein Roseskript abgefragt werden (Operation
GetSelectedItems, siehe Abb. 4.7) und wird später bei der Realisierung von Konsistenzprüfungen benutzt, um die Prüfungen auf einen Teilbereich des Modells einzu-
135
RoseObject
CanTypeCast()
IdentifyClass()
IsClass()
TypeCast()
Element
Name
Application
Model
RoseItemView
Item
ParentDiagram
ParentView
SubViews
XPosition
YPosition
IsSelected()
HasItem()
HasParentView()
RoseItem
Documentation
Stereotype
ExternalDocuments
LocalizedStereotype
AddExternalDocument()
DeleteExternalDocument()
GetRoseItem()
OpenSpecification()
Diagram
Documentation
Items
ItemViews
Activate()
AddNoteView()
IsActive()
Exists()
RemoveNoteView()
Abbildung 4.6: Die Spitze der Klassenhierarchie von Rose
136
schränken. Die Operation Activate der Klasse Diagram stellt das entsprechende Diagramm in einem Fenster von Rose dar. Diese Operation wird später benutzt, um Modellelemente sichtbar darzustellen, die eventuell für eine Verletzung einer Konsistenzbedingung verantwortlich sind.
Diagram
Activate()
GetSelectedItems()
ClassDiagram
ScenarioDiagram
StateDiagram
ParentCategory
Parent
InstanceViews
AddInstance()
AddInstanceView()
CreateMessage()
DeleteInstance()
GetDiagramType()
GetMessages()
GetSelectedLinks()
GetSelectedMessages()
GetSelectedObjects()
RemoveInstanceView()
DeploymentDiagram
AddDevice()
AddProcessor()
GetDevices()
GetProcessors()
RemoveDevice()
RemoveProcessor()
AddAssociation()
AddCategory()
AddClass()
AddUseCase()
GetAssociations()
GetCategories()
GetClasses()
GetClassView()
GetSelectedCategories()
GetSelectedClasses()
GetUseCases()
IsUseCaseDiagram()
RemoveAssociation()
RemoveCategory()
RemoveClass()
RemoveUseCase()
AddStateView()
GetSelectedStates()
GetSelectedStateViews()
GetSelectedTransitions()
GetStateView()
GetStateViews()
RemoveStateView()
ModuleDiagram
ParentSubsystem
AddModule()
AddSubsystem()
GetModules()
GetSelectedModules()
GetSelectedSubsystems()
GetSubsystems()
Abbildung 4.7: Die Diagrammklassen von Rose
Die fünf Unterklassen von Diagram dienen der internen Darstellung der sieben möglichen Diagrammarten in Rose. Die Klasse ClassDiagram ist für Klassen- und Anwendungsfalldiagramme verantwortlich. Sequenz- und Kollaborationsdiagramme, die als
(weitgehend) äquivalent angesehen werden können, werden intern durch die Klasse ScenarioDiagram dargestellt. Zustands-, Komponenten- und Verteilungsdiagramme werden
durch die Klassen StateDiagram, ModuleDiagram und DeploymentDiagram repräsentiert.
Die meisten Diagrammklassen besitzen Operationen, mit denen auf selektierte Modellelemente differenzierter zugegriffen werden kann, als dies mit der Operation GetSelectedItems möglich ist.
137
Das Attribut Parent der Klasse StateDiagram bezeichnet die Klasse, zu der das
Zustandsdiagramm gehört. Wie bereits oben erwähnt, wird in Rose ein UML-Modell
mittels Sichten (use case view, logical view, usw.) und Paketen strukturiert. Das Attribut
ParentCategory gibt die Sicht bzw. das Paket an, zu der das Klassen- bzw. Anwendungsfalldiagramm gehört. In Klassen- und Anwendungsfalldiagrammen können Paketabhängigkeiten modelliert werden. Ein Diagramm, welches nur Pakete enthält wird auch
Paketdiagramm genannt.
4.4.3 Modellelemente in Klassendiagrammen
Die Darstellung von Klassen, Interfaces und anderen in Klassendiagrammen von Rose
verwendbaren Modellelementen werden durch Unterklassen von RoseItemView (Abb.
4.6) repräsentiert. Die Klassen, die für die Spezifikation dieser Modellelemente verantwortlich sind, sind Unterklassen von RoseItem und werden in diesem Abschnitt erläutert
(siehe Abb. 4.8).
Die Klasse Class repräsentiert nicht nur Klassen, sondern auch Modellelemente, die
als Klassen mit einem bestimmten Stereotyp, z.B. «Interface», dargestellt werden können.
Rose erkennt die beiden Klassifizierer Interface und Akteur anhand ihrer Stereotypen und
kann sie auch mit ihrem Icon darstellen. Während die Spezifikation von Akteuren gegenüber Klassen eingeschränkt ist, wird ein Interface semantisch nicht als solches erfaßt,
d.h. für Rose gibt es, bis auf die Darstellung, keinen Unterschied zwischen einer beliebigen stereotypisierten Klasse und einem Interface. Mit Hilfe der Funktionen der Klasse
Class können mit Rose Script u.a. Beziehungen zu anderen Klassen hinzugefügt, entfernt und ermittelt werden. Die Attribute und Operationen der Klasse werden durch die
Attribute Attributes und Operations gespeichert. Diese Attribute repräsentieren sogenannte Collections (Sammlungen), über die auf die Attribute und Operationen einer
Klasse zugegriffen werden kann. Damit sind alle Informationen, die der Benutzer im
Modell spezifiziert, prinzipiell auch in Rose Script verfügbar und veränderbar. Klassen
können als abstrakt markiert werden, ihre Sichtbarkeit (public, protected, private), Kardinalität und Nebenläufigkeit kann angegeben werden. StateMaschine bezeichnet das
einzige, falls vorhandene, Zustandsdiagramm der Klasse, welches auch von Rose Script
erzeugt werden kann (Operation CreateStateMaschine).
Umgekehrt „kennen“ auch Attribute und Operationen ihre Klasse (Attribut ParentClass). Die Parameter einer Operation (Attribut Parameters vom Typ collection) werden durch die Klasse Parameters repräsentiert.
Assoziations-, Realisierungs-, Abhängigkeits- und Generalisierungsbeziehungen werden durch die Klassen Association, RealizeRelation, ClassDependency und InheritRelation repräsentiert. Die Klasse Role ist vergleichbar mit der Klasse AssociationEnd des UML-Metamodells. Sie repräsentiert die Informationen, die an den Enden
einer Assoziation spezifiziert wird. Die Rollen bzw. Assoziationsenden einer Assoziation können über die Attribute Role1 bzw. Role2 erreicht werden. Ob es sich bei einem
Assoziationsende um die erste oder zweite Rolle der Assoziation handelt, ist irrelevant.
Class
AddAssociation()
AddAttribute()
AddClassDependency()
AddInheritRel()
AddOperation()
AddRealizeRel()
CreateStateMaschine()
DeleteAssociation()
DeleteAttribute()
DeleteClassDependency()
DeleteInheritRel()
DeleteNestedClass()
DeleteOperation()
DeleteRealize()
DeleteStateMaschine()
GetAssociateRoles()
GetAssociations()
GetClassDependencies()
GetInheritRelations()
GetLinkAssociation()
GetRealizeRelations()
GetRoles()
GetSubclasses()
GetSuperclasses()
IsALinkClass()
Abstract
Attributes
Operations
ExportControl
Cardinality
Concurrency
StateMaschine
RoseItem
Role
AddKey()
DeleteKey()
GetClassName()
Class
Constraints
Association
ExportControl
Friend
Containment
Cardinality
Aggregate
Static
Navigable
Keys
Association
AddParameter()
DeleteParameter()
RemoveAllParameters()
InheritRelation
ExportControl
FriendshipRequired
Virtual
ClassDependency
ClientCardinality
SupplierCardinality
ExportControl
RealizeRelation
GetContextClass()
GetSupplierClass()
Const
InitValue
Type
Operation
Concurrency
Exceptions
ExportControlProperty
Parameters
ParentClass
Postconditions
Proconditions
ReturnType
Semantics
Parameter
GetCorrespondingRole()
GetOtherRole()
SetLinkClassName()
Derived
LinkClass
Role1
Role2
Roles
GetContextClass()
GetSupplierClass()
ClassRelation
HasClient()
HasSupplier()
GetClient()
GetSupplier()
Relation
SupplierName
Attribute
ContainmentProperty
Derived
InitValue
ParentClass
Static
Type
OpenSpecification()
Stereotype
138
Abbildung 4.8: Die Rose-Metaklassen für die in einem Klassendiagramm vorkommenden Modellelemente.
139
4.4.4 Modellelemente in Interaktionsdiagrammen
In Rose können Kollaborationsdiagramme nur auf der exemplarischen Ebene modelliert
werden. Sequenz- und Kollaborationsdiagramme der exemplarischen Ebene bestehen aus
Objekten (Exemplaren), Links und Botschaften (bzw. Stimuli). Diese Modellelemente
werden in Rose für beide Diagrammarten durch die gleichen Klassen repräsentiert (Abb.
4.9).
RoseItem
Stereotype
OpenSpecification()
ObjectInstance
ClassName
Links
MultipleInstances
Persistence
Link
LinkRole1
LinkRole2
LinkRole1Visibility
LinkRole2Visibility
AddLink()
DeleteLink()
GetClass()
IsClass()
AddMessageTo()
AssignAssociation()
DeleteMessage()
GetMessages()
UnAssignAssociation()
Message
Frequency
Synchronization
GetSenderObject()
GetReceiverObject()
IsMessageToSelf()
IsOperation()
GetOperation()
GetLink()
Abbildung 4.9: Die Rose-Metaklassen für die in den Sequenz- und Kollaborationsdiagrammen vorkommenden Modellelemente.
Die Klasse eines Objekts (ObjectInstance) wird als String gespeichert (Attribut
ClassName). Falls der Benutzer in Rose eine Klasse für das Objekt ausgewählt hat, kann
diese Klasse mit der Operation GetClass ermittelt werden. Das Attribut Links enthält
eine Sammlung (Collection) der mit dem Objekt verbundenen Links.
Die durch einen Link verbundenen Objekte in einem Kollaborationsdiagramm werden
durch die Attribute LinkRole1 bzw. LinkRole2 repräsentiert. Im Gegenstatz zu den
Rollen-Attributen einer Assoziation verweisen diese Attribute nicht auf die Link-Enden
eines Links. Zu einem Link-Ende kann jedoch die Sichtbarkeit spezifiziert und durch
Rose Script abgefragt werden. Ein Link kann einer bestehenden Assoziation zugeordnet
sein und kennt die Botschaften, die über diese Verbindung verschickt werden.
Eine Botschaft (Message) kann mit einer Operation verknüpft sein (IsOperation,
GetOperation), kennt das Sender- und das Empfängerobjekt, sowie den zugehörigen
Link. Die Reihenfolge der Botschaften kann von Rose Script nicht ermittelt werden. Die
140
Reihenfolge kann in Rose nicht explizit spezifiziert werden. In einem Interaktionsdiagramm ergibt sich die Reihenfolge der Botschaften implizit durch die Anordnung entlang
der vertikalen Achse des Diagramms. In einem Kollaborationsdiagramm wird die Reihenfolge durch die Reihenfolge der Erstellung der Botschaften vorgegeben.
4.4.5
Modellelemente in Zustandsdiagrammen
Zustandsdiagramme (Statecharts) enthalten einen Zustandsautomaten, der aus Zuständen,
Ereignissen, Transitionen und Aktionen als mögliche Reaktionen auf Ereignisse besteht.
Für diese Modellelemente enthält das Werkzeugmetamodell von Rose die entsprechenden
Klassen (Abb. 4.10).
Die Klasse StateMaschine verweist auf das Zustandsdiagramm (StateDiagram),
die zugehörige Klasse (ParentClass) sowie auf die, im Zustandsautomaten vorhandenen, Zustände und Transistionen. Zustandsautomaten (Statecharts) können weitere verschachtelte Zustände enthalten. Die Operationen der Klasse StateMaschine ermöglichen wahlweise den Zugriff auf die Zustände und Transitionen der obersten Ebene oder
aller Zustände und Transistionen des Zustandsautomaten.
Diese Auswahlmöglichkeit besteht auch bei den Zuständen (State). Z.B. kennzeichnet das Attribut Substates die unmittelbaren Unterzustände eines Zustands, während
die Operation GetAllSubstates alle Unterzustände des Zustands liefert. Ein Zustand
„kennt“ die mit ihm verbundenen Transitionen und kann einen Erinnerungs-Zustand enthalten. Ein Zustand kann Entry- und Exit-Aktionen enthalten, sowie anhaltende Aktionen,
die solange ausgeführt werden, wie der Zustand aktiv ist (GetDoActions). Die Zustände
in Rose können auch interne Transitionen, die auf Grund benutzerdefinierter Ereignisse
„feuern“ können, enthalten. Verzögerte Ereignisse können spezifiziert werden, indem die
Aktion auf das zu verzögernde (benutzerdefinierte) Ereignis als „defer“ spezifiziert wird.
In Rose besteht eine Aktion (Action) aus drei Teilen:
1. Der Name (Attribut Name der Klasse Element) ist ein String, der die Aktion beschreibt. Dies sollte der Name einer Operation, eines Signals oder einer Ausnahme
sein. Rose bietet dem Modellierer jedoch keine Auswahl von Möglichkeiten an,
daher fehlt auch eine Beziehung zu einer entsprechenden Operation o.ä.
2. Das Attribut Argument ist ein String, der die Argumente der Aktion speichert.
3. Das Attribut Target ist ebenfalls ein String, der nur zur Verfügung steht wenn es
sich um eine Sende-Aktion handelt. Es sollte eine Klasse bzw. ein Objekt bezeichnen, die dieses Signal empfängt. Auch hier bietet Rose keine Auswahlmöglichkeit
bzw. eine Verbindung zum entsprechenden Element an.
Sende-Aktionen werden von Rose anders als Aufruf-Aktionen dargestellt. Dies ist
in UML Version 1.3 nicht mehr der Fall.
141
Element
Name
RoseItem
Stereotype
Statemaschine
Diagram
ParentClass
States
Event
Arguments
GuardCondition
OpenSpecification()
GetAction()
AddState()
DeleteState()
GetAllStates()
GetAllTransitions()
GetTransitions()
RelocateState()
State
History
ParentState
ParentStateMaschine
StateKind
SubStates
Transitions
AddDoAction()
AddEntryAction()
AddExitAction()
AddState()
AddTransition()
AddUserDefinedEvent()
DeleteAction()
DeleteState()
DeleteTransition()
DeleteUserDefinedEvent()
GetAllSubstates()
GetDoActions()
GetEntryActions()
GetExitActions()
GetUserDefinedEvents()
RelocateState()
Relation
SupplierName
Action
Arguments
Target
HasClient()
HasSupplier()
GetClient()
GetSupplier()
Transition
GetSendAction()
GetSourceState()
GetTargetState()
GetTriggerAction()
GetTriggerEvent()
RedirectTo()
Abbildung 4.10: Die Rose-Metaklassen für die in einem Zustandsdiagramm vorkommenden Modellelemente.
4.5. KLASSENDIAGRAMM
142
Transitionen (Klasse Transition) „kennen“ ihren Ausgangs- und Folgezustand, sowie das dazugehörige Ereignis und die Aktion auf das Ereignis.
Das Attribut GuardCondition der Klasse Event kennzeichnet eine Bedingung, die
das „Feuern“ ihrer Transition überwacht. Von einem benutzerdefiniertem Ereignis, welches zu einem Zustand gehört, kann auf die zugehörige Aktion geschlossen werden (GetAction).
4.5
Klassendiagramm
Klassendiagramme gehören zu den wichtigsten und am meisten verwendeten Diagrammen einer objektorientierten Systementwicklung. Sie spezifizieren die strukturelle und
logische Basis für die Realisierung des Systems, auf der die Spezifikation und die Realisierung des Systemverhaltens aufbaut.
In diesem Abschnitt wird erläutert, wie die graphische Darstellung der Modellelemente eines Klassendiagramms ein Metamodellexemplar der UML bzw. ein Rose-Metamodellexemplar beschreibt. Der Vergleich der Metamodellexemplare zeigt, in welchem
Ausmaß Rose die Semantik der UML erkennt und welche Konsistenzbedingungen, die
im Metamodell der UML definiert sind bzw. sich aus dem Metamodell ableiten lassen,
mit Hilfe der Skript-Sprache von Rose überprüft werden können.
4.5.1
Klassen
Eine Klasse wird in einem Rechteck dargestellt, welches üblicherweise horizontal in drei
Bestandteile zerlegt wird. Der obere Teil ist für den Klassennamen, Eigenschaftswerte,
Zusicherungen sowie für einen Stereotyp vorgesehen. Im mittleren Teil werden die Attribute und im unteren Teil die Operationen dargestellt. Abb. 4.11 zeigt eine abstrakte Klasse ohne Attribut- und Operationsanteile mit einem Stereotyp. Abstrakte Klassen können
durch die Zusicherung {abstract} oder durch einen kursiv geschriebenen Klassennamen
dargestellt werden.
<<Stereotyp>>
Klassenname
Abbildung 4.11: Abstrakte Klasse mit einem Stereotyp
Die Abbildung der Klasse aus Abb. 4.11 auf ein Metamodellexemplar zeigt Abb. 4.12.
Die entsprechenden Metamodellausschnitte befinden sich in Abb. 3.5, Seite 44 (Klasse)
und Abb. 3.28, Seite 72 (Erweiterungsmechanismen).
Die Abbildung der Klasse aus Abb. 4.11 auf die interne Datenstruktur von Rose zeigt
Abb. 4.13.
143
: Class
name = Klassenname
isRoot = false
isLeaf = false
isAbstract = true
isActive = false
: Stereotype
extendedElement
stereotype
name = Stereotyp
icon
baseClass = Class
Abbildung 4.12: Darstellung einer stereotypisierten Klasse als Metamodellexemplar
: Class
Name = Klassenname
Stereotype = Stereotyp
Abstract = true
Cardinality = n
Concurrency = Sequential
Abbildung 4.13: Eine stereotypisierte Klasse aus Sicht der Skriptsprache von Rational
Rose.
Die folgenden Informationen zu einer Klasse in den Abbildungen 4.12 und 4.13 entsprechen einander:
UML
name
isAbstract
isActive
Rose
Name
Abstract
Concurrency
stereotype
Stereotype
Bemerkung
Concurrency kann in Rose die Werte Sequential, Guarded, Active und Synchronous annehmen.
In Rose ist „Stereotype“ ein Attribut der Klasse RoseItem. Es ist möglich, einen Stereotyp
aus einer Liste auszuwählen oder einen neuen Stereotyp zu erstellen. Es ist nicht möglich, den Namen eines Stereotyps zu ändern
(nicht zu verwechseln mit der Möglichkeit,
einen anderen Stereotyp für ein Modellelement (RoseItem) auszuwählen).
Die im Metamodell angegebenen Eigenschaften isRoot und isLeaf einer Klasse
können in Rose nicht in jedem Fall angegeben werden. Die Java-Erweiterung von Rose
ermöglicht das Setzen eines booleschen Wertes für die „Final“-Eigenschaft einer Klasse
(vergleichbar mit isLeaf), die bei der Codeerzeugung berücksichtigt wird.
Konsistenzbedingungen für Klassen existieren im Zusammenhang mit anderen Modellelementen und werden in den entsprechenden Abschnitten behandelt.
4.5.2
144
Attribute
Attribute werden im Klassenrechteck mit der folgenden Syntax notiert:
Sichtbarkeit Attributname ’[’ Kardinalität ’]’ ’:’ Typ
’=’ Initialwert ’{’ Eigenschafts-String ’}’
• Die Sichtbarkeit der Attribute wird mit ’+’ (öffentlich), ’#’ (geschützt) und ’-’ (privat) angegeben.
• Der Eigenschafts-String dient der Notierung von Zusicherungen und Eigenschaftswerten.
• Bei Klassenattributen (Attribute, deren Wert für alle Objekte einer Klasse gelten)
wird die gesamte Deklaration unterstrichen dargestellt.
• Abgeleitete Attribute werden gekennzeichnet, indem den Attributnamen ein Slash
(’/’) vorangestellt wird.
• Attribute können mit einem Stereotyp markiert werden.
Bei der Darstellung von Attributen muß nicht immer die vollständige Deklaration der
Attribute dargestellt werden (Abb. 4.14). Es liegt in der Verantwortung des Werkzeugs,
bestimmte Eigenschaften darzustellen bzw. für Default-Werte für bestimmte Eigenschaften, z.B. die Sichtbarkeit, zu sorgen. Rose ermöglicht es, einzelne Attribute und Operationen einer Klasse in einem Klassendiagramm auszublenden und den Detailliertheitsgrad
der Darstellung von Attributen und Operationen festzulegen.
Klassenname
Attributname : Typ = Initialwert
Abbildung 4.14: Attribut ohne Darstellung der Sichtbarkeit. Zusicherungen, z.B. frozen,
können an das Attribut angeheftet werden.
Die Abbildung des Attributs aus Abb. 4.14 auf ein Metamodellexemplar ist in Abb.
4.15 angegeben. Der Ausschnitt des Metamodells befindet sich in Abb. 3.10, Seite 50.
Eine Zusicherung würde gegebenenfalls mit einem Link an das Attribut geheftet werden.
Die Abbildung des Attributs aus Abb. 4.14 auf die interne Datenstruktur von Rose ist
in Abb. 4.16 angegeben.
Die folgenden Informationen eines Attribut aus den Abbildungen 4.15 und 4.16 entsprechen einander:
145
: Class
name = Klassenname
isRoot = false
isLeaf = false
isAbstract = false
isActive = false
: Attribute
owner
name = AttributName
ownerScope = instance
feature
visibilityKind = public
initialValue = Initialwert
multiplicity = 1
changeability = changeable
targetScope = instance
: Class
type
name = Typ
isRoot = false
isLeaf = false
isAbstract = false
isActive = false
Abbildung 4.15: Darstellung eines Attributs als Metamodellexemplar unter Auslassung
der Zugehörigkeit zu einem Namensraum. Es wird angenommen, daß
ein Werkzeug sinnvolle Defaultwerte für nicht-spezifizierte Eigenschaften setzt.
Anstelle von Class als Typ kann auch ein DataType benutzt werden.
: Class
Name = Klassenname
Abstract = false
Attributes
: Attribute
Name = AttributName
Static = false
ExportControlProperty = PublicAccess
InitValue = Initialwert
Derived = false
Type = Typ
ParentClass
Abbildung 4.16: Klasse und Attribut aus Sicht der Skriptsprache von Rational Rose. Die
Parameter „Attributes“ und „ParentClass“ lassen auf eine Assoziation
zwischen den Metaklassen „Class“ und „Attribute“ schließen. Das Attribut „Attributes“ der Metaklasse „Class“ enthält eine Sammlung (collection) von Referenzen auf die Attribute der Klasse.
Chart Name : Attrib
Chart Filename : A
Chart Type : UML O
UML
name
ownerScope
visibilityKind
initialValue
type
Rose
Name
Static
InitValue
Type
146
Bemerkung
instance entspricht Static = false
public entspricht PublicAccess
In Rose ist Typ ein Attribut der Klasse
Attribute.
Die folgenden Informationen können nicht aus Abb. 4.16 extrahiert bzw. nicht in
einem Rose-Modell hinterlegt werden:
• Die Kardinalität eines Attributs kann nicht direkt angegeben werden4 .
• targetScope kann nicht angegeben werden.
• Zusicherungen können nicht direkt angegeben werden.
Die Eigenschaft „Derived“ ist eine Zusicherung an ein Attribut, die Rose direkt unterstützt. Eine Klasse kann als „persistent“ oder „transient“ spezifiziert werden.
Es ergeben sich folgende Konsistenzbedingungen und Möglichkeiten, diese Bedingungen in Rose zu überprüfen:
• Attribut-1: Kein Attribut darf mehrfach innerhalb einer Klasse deklariert werden
([OMG99], Seite 2-47).
Rose findet keine Verletzung dieser Bedingung, eine Überprüfung kann jedoch realisiert werden.
• Attribut-2: Die Deklarations eines Attributs sollte eines Typen beinhalten.
• Attribut-3: Der Typ des Attributs sollte im Modell (genauer: im Namensraum des
Attributs) existieren (Vollständigkeitsbedingung).
Als Typen eines Attributs kommen die Klassifizierer Class und DataType in Frage. Diese gehören in Rose zur Klasse Class. Mit der Skript-Sprache von Rose
läßt sich überprüfen, ob eine Klasse mit dem Namen des Typs existiert und gegebenenfalls die fehlende Klasse im Modell erzeugen (d.h. nicht, daß es auch ein
Klassendiagramm gibt, welches die Klasse enthält).
• Attribut-4: Ein vorhandender Defaultwert sollte aus dem Wertebereich des Typs
sein.
4 Indirekt
können weitere Informationen immer als Notiz im Diagramm oder als Dokumentation zu
einem Modellelement vermerkt werden.
147
Eine Überprüfung dieser Bedingung setzt voraus, daß das Werkzeug den Wertebereich kennt. Dies ließe sich z.B. für Basistypen realisieren, deren Semantik bzw.
Wertebereich allgemein anerkannt ist.
4.5.3 Operationen
Operationen werden im unteren Bereich des Klassenrechtecks der deklarierenden Klasse
mit der folgenden Syntax notiert:
Sichtbarkeit Operationsname (Parameterliste): Rückgabetyp { Eigenschafts-String }
• Die Sichtbarkeit entspricht der Sichtbarkeit von Attributen. Zusätzliche Arten von
Sichtbarkeiten können definiert werden. Sie sollten durch Werkzeugkonventionen
oder im Eigenschafts-String dargestellt werden.
• Der Rückgabetyp ist eine sprachabhängige Spezifikation des Typs (oder der Typen,
[OMG99], Seite 3-43) des Rückgabewertes der Operation.
• Die Parameterliste ist eine durch Kommata getrennte Liste von formalen Parametern, die durch die folgende Syntax spezifiziert wird:
Art Name : Typ-Ausdruck = Default-Wert
mit
– Art ist in, out, inout. Default ist in.
– Name bezeichnet den Namen des Parameters.
– Der Typ-Ausdruck ist die (sprachabhängige) Spezifikation eines Typen.
– Der Default-Wert ist ein optionaler Wert-Ausdruck für den Parameter.
– Der Eigenschafts-String indiziert Eigenschaftswerte und Zusicherungen. Dazu gehören die Eigenschaften isQuery und abstract sowie die Spezifikation
von Eigenschaften, die die Nebenläufigkeit der Operation betreffen.
• Klassenoperationen (class scoped) werden unterstrichen dargestellt.
• Methoden oder Algorithmen einer Operation können als Notiz an die Operation
geheftet werden.
• Operationen können mit einem Stereotypen markiert werden, der vor der Operationssignatur einschließlich der Sichtbarkeit notiert wird.
Bei der Darstellung einer Operation müssen nicht alle spezifizierten Eigenschaften
einer Operation dargestellt werden ([OMG99]). Abb. 4.17 zeigt ein Beispiel, welches im
folgenden benutzt wird.
148
Klassenname
Operationsname(Parametername : Parametertyp = Default-Wert) : Rückgabetyp
Abbildung 4.17: Beispielhafte Notation einer Operation
: Class
name = Klassenname
Aus Sicht der Operation
sind die Parameter geordnet.
Der Typ eines Parameters
könnte auch ein "DataTyp" sein
owner
feature
: Operation
name = Operationsname
visibilityKind = public
concurrency = sequential
ownerScope = instance
isQuery = false
isRoot = false
isLeaf = false
isAbstract = false
: Parameter
name = Parametername
kind = inout
defaultValue = Default-Wert
: Parameter
name = ?
kind = return
defaultValue = ?
type
: Class
name = Parametertyp
: Class
name = Rückgabetyp
type
Abbildung 4.18: Metamodellexemplar der Operation aus Abb. 4.17. Der Wert des Attributs „kind“ dient der Unterscheidung zwischen einem Parameter und
einem Rückgabetyp. Da Rückgabetypen wie Parameter behandelt werden, kann eine Operation mehrere Rückgabetypen besitzen.
Konzeptionell vorhanden
: Class
Name = Klassenname
Operations
: Operation
name = Operationsname
ExportControlProperty = PublicAccess
Concurrency = sequential
Stereotype
ReturnType = Rückgabetyp
Parameters
ParentClass
Konzeptionell vorhanden
: Parameter
name = Parametername
Type = Parametertyp
InitValue = Default-Wert
Const = false
Abbildung 4.19: Interne Darstellung der Operation aus Abb. 4.17. Eine Klasse kennt ihre
Operationen, eine Operation kennt ihre Klasse und ihre Parameter, aber
ein Parameter kennt seine Operation nicht.
Chart Name
Chart Filena
Chart Type :
149
Die Abbildung der Operation aus Abb. 4.17 auf ein Metamodellexemplar der UML
ist in Abb. 4.18 dargestellt. Stereotypen und Zusicherungen einer Operation würden
gegebenfalls mit einem Link an die Operation geheftet werden.
Die Abbildung der Operation aus Abb. 4.17 auf ein Metamodellexemplar von Rose in
Abb. 4.19 dargestellt.
Die folgenden Informationen aus den Abbildungen 4.18 und 4.19 entsprechen einander:
UML
Rose
Bemerkung
name
Name
visibilityKind
ExportControlpublic (UML) entspricht PublicAccess (RoProperty
se)
concurrency
Concurrency
defaultValue
InitValue
Rückgabetyp
ReturnType
In Rose ist ein Rückgabetyp kein Parameter,
sondern ein Attribut einer Operation. Es kann
nur ein Rückgabetyp angegeben werden.
Die folgenden Informationen können nicht aus Abb. 4.19 extrahiert bzw. in einem
Rose-Modell hinterlegt werden:
• Eine dem Attribut ownerScope der Metamodellklasse Operation entsprechende
Information kann nur mit einer sprachspezifischen Erweiterung von Rose im Modell notiert werden. Z.B. enthält die Java-Erweiterung die entsprechende boolesche
Eigenschaft Static.
• Weitere einstellbare Eigenschaften der Java-Erweiterung sind Abstract und Final
(entsprechend den booleschen Attributen abstract und isLeaf des Metamodells).
• Die Eigenschaften isQuery und isRoot können nicht angegeben werden.
• Die Art des Parameters kann nicht angegeben werden.
Es ergeben sich folgende Konsistenzbedingungen für Operationen:
• Operation-1: In einer Klasse darf keine Operationssignatur mehrfach deklariert
werden. Genauer: Kein Verhaltensmerkmal der gleichen Art (Operation, Methode,
Empfangserklärung für ein Signal) darf die gleiche Signatur in einem Klassifizierer
haben ([OMG99], Seite 2-47).
• Operation-2: Die Parameternamen einer Operation müssen eindeutig sein ([OMG99],
Seite 2-45).
• Operation-3: Die Typen der Parameter sollten im Modell existieren (Vollständigkeitsbedingung). Genauer: Die Typen der Parameter sollten im Namensraum des
Klassifizierers der Operation enthalten sein ([OMG99], Seite 2-45).
150
• Operation-4: Die Klasse einer abstrakten Operation muß abstrakt sein ([OMG99],
Seite 2-46), da eine Klasse mit einer abstrakten Operation keine direkten Exemplare
besitzen kann.
Eine Verletzung dieser Bedingungen wird von Rose nicht entdeckt. Die Überprüfung
dieser Bedingungen läßt sich in Rose jedoch realisieren.
4.5.4
Assoziationen
Eine binäre Assoziation zwischen Klassen wird als Linie zwischen den Klassen modelliert. Die Assoziation kann optional benannt und mit einem Stereotyp und Zusicherungen
versehen werden. Die Rollennamen der Klassen (optional mit Sichtbarkeit), die Kardinalität und Zusicherungen (z.B. ordered) werden an den Enden der Linie dargestellt
(Abb. 4.20). N-äre Assoziationen werden mit Hilfe eines weiteren Symbols dargestellt
[OMG99], können jedoch in Rose nicht modelliert werden.
A
-Rollenname-A
1..1
<<Stereotyp>>
Assoziationsname
{Assoziationszusicherung}
#Rollenname-B
B
2..4
Abbildung 4.20: Beispielhafte Notation einer Assoziation mit Rollennamen und Spezifikation der Sichtbarkeit der Rollennamen.
Die Abbildung der Assoziation aus Abb. 4.20 auf ein Metamodellexemplar ist in Abb.
4.21 dargestellt. Stereotypen und Zusicherungen einer Assoziation oder eines Assoziationsendes würden gegebenenfalls mit einem Link an das entsprechende Objekt geheftet
werden.
Abb. 4.22 zeigt die Darstellung des Metamodellexemplars von Rose der Abb. 4.20.
Die folgenden Informationen aus den Abbildungen 4.21 und 4.22 entsprechen einander:
UML
Rose
Bemerkung
name
Name
isNavigable
Navigable
aggregation
Aggregate
In Rose ist Aggregate ein boolescher Wert,
der zwischen normaler Assoziation und Aggregation unterscheidet.
targetScope
Static
targetScope = instance entspricht Static = false.
multiplicity
Cardinality
visibility
ExportControl
151
Chart Name :
Chart Filenam
Chart Type : U
: AssociationEnd
: Class
name = A
type
name = Rollenname-A
isNavigable = true
aggregation = none
multiplicity = 1..1
visibility = private
ordering = unordered
connection
: Association
name = Assoziationsname
: AssociationEnd
: Class
name = B
type
name = Rollenname-B
isNavigable = true
aggregation = none
multiplicity = 2..4
visibility = protected
ordering = unordered
connection
Abbildung 4.21: Metamodellexemplar der Assoziation aus Abb. 4.20 ohne Berücksichtigung des Stereotypen und der Zusicherung.
Rose besitzt die folgenden Einschränkungen:
• Rollen (Assoziationsenden) können in Rose nicht mit einem Stereotyp markiert
oder mit einer Zusicherung verbunden werden, obwohl Abb. 4.22 das Gegenteil andeutet (Genauer: Die normale Benutzerschnittstelle bietet dazu keine Möglichkeit).
In Rose können Zusicherungen zu einer Assoziation angegeben werden, obwohl die
Existenz eines Attributs „Constraints“ nicht dokumentiert und auch nicht durch die
Skript-Sprache zugänglich ist.
• In Rose können nur binäre Assoziationen modelliert werden.
Für Assoziationen gelten die folgenden Konsistenzbedingungen:
• Assoziation-1: Jede Assoziation muß eine eindeutige Kombination von Assoziationsname und assoziierten Klassifizierern sein ([OMG99], Seite 2-44). D.h. bei
mehreren Assoziationen zwischen zwei Klassifizierern muß ein Assoziationsname
existieren.
• Assoziation-2: Eine Assoziation sollte mindestens in eine Richtung navigierbar
sein (Vollständigkeitsbedingung).
• Assoziation-3: Ein navigierbares Assoziationsende sollte einen Rollennamen besitzen (Vollständigkeitsbedingung).
152
: Role
Name = Rollenname-A
Navigable = true
Aggregate = false
Static = false
Cardinality = 1..1
ExportControl = PrivateAccess
Class
Stereotype
Constraints
Association
Keys
Containment = undefined
: Class
Name = A
Association
: Role
Name = Rollenname-B
Navigable = true
Aggregate = false
Static = false
Cardinality = 2..4
ExportControl = ProtectedAccess
Stereotype
Constraints
Association
Keys
Containment = undefined
Class
Name = Assoziationsname
Derived = false
Stereotype = Stereotyp
Role1
Role2
Roles
LinkClass
: Class
Name = B
Abbildung 4.22: Interne Darstellung der Assoziation aus Abb. 4.20 in Rose. Die Attribute
„Role1“ und „Role2“ der Klasse Association verweisen auf die Assoziationsenden der Assoziation. Das Attribut „Roles“ ist eine Sammlung
(Collection) der Assoziationsenden, deren Benutzung dem Autor in der
Skript-Sprache nicht möglich war. Das Attribut deutet jedoch an, daß
Rose auch n-äre Assoziationen unterstützen könnte.
153
• Assoziation-4: Die durch eine Assoziation verbundenen Klassifizierer sollten zum
Namensraum der Assoziation gehören ([OMG99], Seite 2-44).
• Rolle-1: Der einer Klasse gegenüberliegende Rollenname (Pseudoattribut) muß
eindeutig in der Menge aller Attribute und Pseudoattribute der Klasse sein ([OMG99],
Seite 2-44).
• Rolle-2: Ein navigierbares Assoziationsende sollte einen Rollennamen besitzen
(Vollständigkeitsbedingung).
Ein navigierbares Assoziationsende deutet eine Realisierung an, bei der ein Objekt
mit Hilfe eines Pseudoattributs auf assoziierte Objekte zugreifen kann, d.h. Attribute und Operationen aufrufen kann. Bei der Java-Codeerzeugung benutzt Rose diese
Rollennamen und verwendet sie als Attributnamen für Klassen (Pseudoattribute).
Verletzungen dieser Bedingungen werden von Rose nicht entdeckt.
4.5.5
Spezielle Assoziationen
Aggregation, Komposition, qualifizierte Assoziation und Assoziationsklassen sind spezielle Assoziationen.
Eine Aggregationen und Kompositionen beschreiben eine Ganzes-Teile-Beziehung.
Im Metamodellexemplar wird das Ganze in einer Aggregations- bzw. Kompositionsbeziehung durch das Attribut aggregation der Klasse AssociationEnd (die mit der Klasse
verbunden ist, die das Ganze repräsentiert), festgelegt. Eine Aggregation in Rose ist gekennzeichnet durch das Wertepaar Aggregate = true und Containment = ByReference
oder Unspecified, eine Komposition wird durch Aggregate = true und Containment
= ByValue gekennzeichnet.
Im Metamodellexemplar werden qualifizierende Attribute mit dem Assoziationsende
verbunden, an dem das Attribut notiert wird. In Rose gibt das Attribut Keys der Klasse
Role eine Sammlung (collection) von Attributen an, die die Exemplare des Assoziationsendes partitionieren (dies ist ein anderes (!) Assoziationsende als im Metamodell).
Eine Assoziationsklasse stellt sich im Metamodellexemplar ähnlich wie in Abb. 4.20
angegeben dar, nur mit dem Unterschied, daß die Assoziation nicht durch ein Exemplar
von Association, sondern durch ein Exemplar von AssociationClass repräsentiert
wird. In Rose kennzeichnet das Attribut LinkClass gegebenenfalls die Klasse, die die
Merkmale (Attribute) der Assoziationsklasse repräsentiert. In [OMG99] ist nicht ausgeschlossen, daß eine Assoziationsklasse auch Verhaltensmerkmale besitzen darf.
Für die speziellen Assoziationen gelten weitere Konsistenzbedingungen:
• Aggregation-1: Nur eine binäre Assoziation kann eine Aggregations- oder Kompositionsbeziehung sein ([OMG99], Seite 2-44).
Diese Bedingung wird von Rose trivialerweise eingehalten, da die Möglichkeit zur
Modellierung n-ärer Assoziationen fehlt.
154
• Aggregation-2: Nur ein Assoziationsende kann eine Aggregation bzw. Komposition kennzeichnen ([OMG99], Seite 2-44).
Diese Bedingung wird von Rose eingehalten.
• Komposition-1: Ein „Teil“ kann nur zu genau einem Ganzen gehören, d.h. die
maximale Kardinalität des Assoziationsendes, welches das Ganze kennzeichnet,
beträgt maximal 1 ([OMG99], Seite 2-45).
ModelElement
TaggedValue
0..1
Stereotype
0..1
Abbildung 4.23: Kompositionen mit der Kardinalität 0..1: Ein Eigenschaftswert (TaggedValue) gehört entweder zu einem Modellelement oder zu einem Stereotyp.
Beträgt die Kardinalität 0..1, kann die Klasse des „Teils“ an mehreren Kompositionsbeziehungen als „Teil“, jeweils mit der Kardinalität 0..1, teilnehmen (siehe Abb.
4.23). Eine Kardinalität von genau 1 schließt die Teilnahme als „Teil“ an weiteren
Kompositionsbeziehungen aus.
• Qualifikationsangabe-1: Nur eine binäre Assoziation kann qualifiziert werden.
• Qualifikationsangabe-2: Der Name des qualifizierenden Attributs sollte nicht der
Name eines Attributs der Klasse sein, deren Objekte über die Qualifikationsangabe
auf verbundene Objekte zugreifen.
Das Attribut, welches die Assoziation qualifiziert, ist eine Eigenschaft der Assoziation (vgl. [BRJ99a], Seite 165). Eine Qualifikationsangabe impliziert eine Realisierung, bei der über einen Wert auf eine Menge von Exemplaren (meistens genau
ein Exemplar) zugegriffen werden kann.
• Assoziationsklasse-1: Die Namen der Assoziationsenden (Rollenname) und die
Attributnamen der Assoziationsklasse müssen eindeutig sein ([OMG99], Seite 244).
• Assoziationsklasse-2: Eine Assoziationsklasse kann nicht zwischen sich selbst und
irgendeinem Modellelement definiert werden ([OMG99], Seite 2-44), d.h. eine assoziierte Klasse kann nicht die Assoziationsklasse der Assoziation sein (Abb. 4.24).
Diese Konsistenzbedingung wird von Rose eingehalten.
• Assoziationsklasse-3: Eine Assoziationsklasse kann nicht mit mehr als einer Assoziation verknüpft werden (vgl. [BRJ99a], Seite 168), da sie selbst eine Assoziation
ist.
155
Class 1
Class 2
Abbildung 4.24: Beispiel für eine inkonsistente Modellierung einer Assoziationsklasse.
4.5.6 Generalisierungen
Generalisierungsbeziehungen können nicht nur zwischen Klassen (Abb. 4.25), sondern
auch zwischen Interfaces (siehe Abschnitt 4.5.7), Signalen (siehe Abschnitt 4.5.10) und
Kollaborationen existieren. Eine Generalisierung kann benannt werden und einen Diskriminator besitzen, der das Abstraktionsmerkmal der Generalisierung beschreibt.
Oberklasse
Generalisierungsname
Unterklasse
Abbildung 4.25: Einfache Generalisierungsbeziehung ohne Diskriminator
Die Abbildungen 4.26 und 4.27 zeigen die Darstellung von Abb. 4.25 als Metamodellexemplare.
In Rose kann nur eine Generalisierung zwischen genau zwei Klassifizierern benannt
und mit einem Stereotyp markiert werden. In Rose kann sogar die Sichtbarkeit der Generalisierungsbeziehung spezifiziert werden, die im Metamodell nicht vorgesehen ist. Besitzt eine Oberklasse zwei Unterklassen, dann kann diese Beziehung durch eine Generalisierungsbeziehung mit einem Vorfahren und zwei Nachkommen modelliert werden.
Rose unterstützt diese Möglichkeit, jedoch kann die Generalisierungsbeziehung in diesem Fall nicht spezifiziert werden, d.h. der Name, ein Stereotyp und die Sichtbarkeit
kann nicht angegeben werden. In Rose fehlt die Möglichkeit, einen Diskriminator anzugeben ebenso wie die Möglichkeit, Zusicherungen für die Generalisierungsbeziehung
(disjoint/overlapping und incomplete/complete), die sich meist auf mehrere Generalisierungen beziehen, zu spezifizieren.
Es gibt nicht nur Konsistenzbedingungen für die Modellelemente, die durch die Generalisierung verbunden sind, sondern auch für deren Inhalte. So werden u.a. die Attribute,
156
: Class
name = Oberklasse
parent
specialization
: Generalization
name = Generalisierungsname
discriminator
generalization
child
: Class
name = Unterklasse
Abbildung 4.26: Darstellung von Abb. 4.25 als UML-Metamodellexemplar.
: Class
Name = Oberklasse
: InheritRelation
Name = Generalisierungsname
Stereotype
SupplierName
ExportControl
: Class
Name = Unterklasse
Abbildung 4.27: Darstellung von Abb. 4.25 als Rose-Metamodellexemplar.
Operationen und Assoziationen einer Klasse abhängig von der spezifizierten Sichtbarkeit
vererbt.
• Generalisierung-1: Klassifizierer, die als Root (Wurzel) gekennzeichnet sind, dürfen keine Vorfahren besitzen ([OMG99], Seite 2-51).
• Generalisierung-2: Klassifizierer, die als Leaf (Blatt) gekennzeichnet sind, dürfen
keine Nachkommen besitzen ([OMG99], Seite 2-51).
In Rose kann diese Eigenschaft in der Java-Erweiterung (Eigenschaft Final) spezifiziert werden.
• Generalisierung-3: Ein Klassifizierer darf kein Unter- bzw. Oberklassifizierer von
sich selbst sein, d.h. ein Graph, der die Vererbungshierachie darstellt, mit Klassifizierern als Knoten und Generalisierungen als Kanten, darf keine Zykel besitzen
(vgl. [OMG99], Seite 2-51).
157
• Generalisierung-4: Die an einer Generalisierung beteiligten Modellelemente müssen von der gleichen Art sein, d.h. sie müssen die gleiche konkrete Metamodellklasse besitzen (vgl. [OMG99], Seite 2-52).
Klassen, Interfaces, Signale und Komponenten sind unterschiedliche (konkrete)
Metamodellklassen.
• Generalisierung-5: Die durch eine Generalisierung verbundenen Modellelemente
müssen im gleichen Namensraum enthalten sein (vgl. [OMG99], Seite 2-51).
• Attribut-5: Attribut- und Pseudoattributnamen einer Klasse (inklusive geerbter)
müssen eindeutig sein, d.h. sie dürfen in den Unterklassen nicht redefiniert bzw.
überschrieben werden.
Diese Bedingung umfäßt die Bedingungen Attribut-1 und Rolle-1.
• Operation-5: Konkrete Nachkommen einer abstrakten Klassen sollten deren abstrakte Operationen realisieren, d.h. Operationen mit der gleichen Signatur als
nicht-abstrakt deklarieren (Vollständigkeitsbedingung).
4.5.7 Interfaces
Interfaces (Schnittstellen) dienen der Spezifikation eines Dienstes, der von einer Klasse
oder einer Komponente angeboten bzw. unterstützt wird. Interfaces können als Klasse
mit dem Stereotyp «Interface» (ausführliche Form, Abb. 4.28) oder mit dem speziellen
Interfacesymbol (siehe Abb. 2.2, Seite 15) dargestellt werden.
<<Interface>>
Interfacename
Abbildung 4.28: Darstellung eines Interface als stereotypisierte Klasse ohne Operationen.
Die Abbildungen 4.29 und 4.30 zeigen die entsprechenden Metamodellexemplare der
Abb. 4.28.
: Interface
name = Interfacename
isAbstract = false
isRoot = false
isLeaf = false
Abbildung 4.29: Abb. 4.28 als Instantiierung der Metmodellklasse Interface.
158
: Class
Name = Interfacename
Stereotype = Interface
Abstract = false
Attributes
Operations = (Referenzen)
ExportControl
Cardinality
Concurrency
StateMaschine
Abbildung 4.30: Interne Sicht von Rose auf Abb. 4.28.
Im Metamodell (Abb. 3.12, Seite 55 und Abb. 4.29) wird zwischen Interface und
Klasse unterschieden. In Rose kann ein Interface nur anhand des Stereotypen von einer
Klasse unterschieden werden (Abb. 4.30).
Die folgenden Konsistenzbedingungen für Interfaces gelten allgemein:
• Interface-1: Ein Interface darf nur Operationen enthalten ([OMG99], Seite 2-52).
Zu den Operationen gehören auch „Signaloperationen“, siehe Abschnitt 4.5.10 Signale.
• Interface-2: Ein Interface darf keine Modellelemente enthalten ([OMG99], Seite
2-52).
• Interface-3: Alle Operationen eines Interfaces müssen „public“ ([OMG99], Seite
2-52) sein.
• Interface-4: Die Operationen eines Interfaces und das Interface selbst sind implizit
abstrakt.
Ob diese Eigenschaft gesetzt oder nicht beachtet werden sollte, ist in [OMG99]
nicht angegeben.
• Interface-5: Interfaces sollten mindestens eine Operation deklarieren oder erben
(Vollständigkeitsbedingung).
• Interface-6: In einer Interfacehierarchie sollte jede Operationssignatur eindeutig
sein ([OMG99], Seite 2-47).
• Interface-7: Das mit einem Interface gegenüberliegende Assoziationsende darf
nicht navigierbar sein ([OMG99], Seite 2-45).
Da in Rose Interfaces alle Merkmale einer Klasse mit Ausnahme eines Stereotypen
besitzen können, sind weitere Bedingungen zu überprüfen:
• Interface-8: Interfaces sollten nicht „aktiv“ sein (Attribut Concurrency).
159
• Interface-9: Die Kardinalität sollte entweder nicht beachtet werden oder „1“sein.
• Interface-10: Ein Interface sollte keinen Zustandsautomaten besitzen.
Die Verletzung von Konsistenzbedingungen in diesem Abschnitt wird von Rose nicht
verhindert oder entdeckt.
4.5.8
Realisierungsbeziehungen
Realisierungsbeziehungen treten üblicherweise zwischen Interfaces und Klassen (Abb.
4.31) bzw. Komponenten auf. Es kann jedoch auch die Realisierung eines Anwendungsfalls durch eine Kollaboration modelliert werden (in Rose nicht möglich). Die InstantiierealisierendeKlasse
Operation()
<<Interface>>
Interfacename
Operation()
Abbildung 4.31: Die Klasse realisiert die Operation des Interfaces.
rung von Abb. 4.31 als Metamodellexemplar (Abb. 4.32) zeigt, daß die Operationsobjekte, als „Teil“ einer Komposition, eine eigene Identität besitzen.
Im Metamodell der UML (siehe Abb. 3.26, Seite 68) ist eine Realisierung eine stereotypisierte Abstraktion (Abhängigkeit). Die Metadarstellung von Abb. 4.31 in Abb.
4.33 zeigt, daß sich die Entwickler von Rose nach der Notation gerichtet haben und eine Realisierungsbeziehung folgerichtig nicht mit einem Stereotyp markiert werden kann.
Eine Realisierungsbeziehung kann nicht näher spezifiziert werden, d.h. sie kann weder
benannt werden, noch kann die im Metamodell vorgesehene Beschreibung der Abhängigkeitsbeziehung (mapping) spezifiziert werden.
Für Realisierungsbeziehungen sind folgende Konsistenzbedingungen zu beachten:
• Interface-11: Ein Interface sollte von einer Klasse oder einer Komponente realisiert werden.
• Interface-12: Interfaces realisieren keine anderen Elemente, d.h. ein Interface
in einer Realisierungsbeziehung muß das spezifizierende Element (Metamodell:
supplier) sein.
• Operation-13: Klassen, die Interfaces realisieren, müssen alle Operationen des
Interfaces (mit der gleichen Signatur) deklarieren (Vollständigkeitsbedingung).
Die Verletzung von Konsistenzbedingungen in diesem Abschnitt wird von Rose nicht
verhindert oder entdeckt.
160
: Interface
name = Interfacename
: Operation
owner
feature name = Operation
supplier
supplierDependency
: Abstraction
: Stereotype
name = realize
name
mapping = (MappingExpression)
clientDependency
client
: Class
name = realisierendeKlasse
owner
feature
: Operation
name = Operation
Abbildung 4.32: Instantiierung von Abb. 4.31 als Metamodellexemplar. Die Objekte besitzen die notwendigen Methoden zur Identifizierung der Realisierungsbeziehung und der beteiligten Modellelemente.
: Class
Name = Interfacename
Stereotyp = Interface
: Operation
: RealizeRelation
Name = (kann nicht gesetzt werden)
Stereotype = (kann nicht gesetzt werden)
SupplierName = InterfaceName
: Class
Name = realisierendeKlasse
: Operation
Abbildung 4.33: Interne Sicht von Rose auf Abb. 4.31.
161
4.5.9 Abhängigkeitsbeziehungen
Neben Realisierungsbeziehungen gibt es noch weitere Abhängigkeitsbeziehungen (siehe
Abb. 3.26, Seite 68).
Die folgenden Konsistenzbedingungen für Abhängigkeitsbeziehungen und Einschränkungen für Rose existieren (ohne Vollständigkeitsanspruch): (siehe auch [BRJ99a])
• Abhängigkeit-1: Eine mit «derive» markierte Abhängigkeitsbeziehung ist eine Beziehung zwischen zwei Attributen oder zwei Assoziationen.
Abhängigkeiten zwischen Attributen können in Rose nicht semantisch korrekt modelliert werden. Ein Attribut kann zwar als abgeleitet (boolesches Attribut derived
der Klasse Attribute) markiert werden, aber eine Beziehung zu einem oder mehreren unabhängigen Attributen und eine (berechenbare) Abbildung kann nicht spezifiziert werden. Es besteht jedoch die Möglichkeit, diese Informationen als Dokumentation zum Attribut zu hinterlegen.
Abhängigkeiten zwischen zwei Assoziationen können in Rose modelliert werden.
Zu dieser Abhängigkeit können jedoch keine weiteren Informationen hinterlegt
werden.
• Abhängigkeit-2: Bei einer mit «instanceOf» markierten Abhängigkeitsbeziehung
ist die Quelle ein Exemplar und das Ziel eine Klasse oder die Quelle ist eine Klasse
und das Ziel ist eine Metaklasse.
In Rose können in Klassendiagrammen keine Objekte plaziert werden.
Es können in Rose Abhängigkeitsbeziehungen zwischen Klassen modelliert und
mit einem Stereotypen markiert werden. Die zweite Möglichkeit einer «instanceOf»-Abhängigkeit kann überprüft werden: Die unabhängige Klasse muß das Stereotyp oder den Typ «MetaClass» besitzen.
• Abhängigkeit-3: Eine mit «refine» markierte Abhängigkeitsbeziehung ist eine Beziehung zwischen Klassen.
Diese Abhängigkeit kann in Rose (mit Stereotyp) modelliert werden.
• Abhängigkeit-4: Eine mit «access», «import» oder «friend» markierte Abhängigkeitsbeziehung ist eine Beziehung zwischen Namensräumen (meist Paketen).
In Rose können Abhängigkeiten zwischen Paketen zwar modelliert, aber nicht stereotypisiert werden. Rose ermöglicht die Überprüfung von Zugriffsverletzungen
(Menü Report - Show Access Violations). Hierbei wird überprüft, ob sich die Klassen eines Klasssendiagramms im gleichen Paket wie das Diagramm befinden oder
durch eine modellierte Abhängigkeit zwischen Paketen verfügbar sind.
4.5.10
162
Signale
Signale, die in Zustandsautomaten und Aktivitätsdiagrammen benutzt werden, können in
Klassendiagrammen deklariert werden.
Die Existenz eines Signals kann in Klassendiagrammen modelliert werden. Dabei
wird ein Signal als Klasse mit dem Stereotyp «signal» modelliert (Abb. 4.34). Optionale
Parameter des Signals werden als Attribute im Klassenrechteck dargestellt.
Klassenname
<<signal>>
SignalName
<<send>>
Operation()
<<signal>> SignalName()
Abbildung 4.34: Eine Klasse mit dem Stereotyp «signal» spezifiziert ein Signal, eine
«send»-Abhängigkeit gibt die Verwendung eines Signals an und eine
mit «signal» markierte Operation erklärt den Empfang eines Signals.
Eine modellierte «send»-Abhängigkeit zwischen einer Operation und einem Signal
bedeutet, daß die Operation das Signal senden kann. Diese Abhängigkeit kann in Rose
nicht spezifiziert werden. Die Darstellung in Abb. 4.34, die mit Rose erstellt wurde,
visualisiert zwar diese Abhängigkeit, aber es ist aus der internen Sicht von Rose eine
Abhängigkeit zwischen Klassen.
Möchte man explizit modellieren, daß Objekte einer Klasse ein bestimmtes Signal
empfangen können (siehe auch Metamodell, Abb. 3.33, Seite 83), so kann dies durch
die Deklarierung einer gleichnamigen Operation mit dem Stereotyp «signal» angegeben
werden (Abb. 4.34).
Bemerkungen:
• Auch Interfaces können den Empfang von Signalen deklarieren.
• Signale werden in Rose intern wie Klassen behandelt.
Im Metamodell sind Ausnahmen (Exceptions) als spezielle Signale definiert, die typischerweise Fehlersituationen signalisieren. Der Sender der Ausnahme bricht seine Ausführung ab und der Empfänger der Ausnahme wird ausgeführt ([OMG99], Seite 2-97).
Ausnahmen werden entsprechend den Signalen als Klassen mit dem Stereotyp «Exception» modelliert. Die Ausnahmen, die eine Operation auslösen kann, können durch
eine «send»-Abhängigkeit spezifiziert oder in der Spezifikation der Operation formuliert
werden. Letzteres wird von Rose unterstützt, indem zu einer Operation ein beliebiger
Text zur Spezifizierung der Ausnahmen eingegeben werden kann (Attribut exceptions
der Klasse Operation).
163
Für Signale können die folgenden Konsistenzbedingungen identifiziert werden:
• Signal-1: Zu einer Operation mit dem Stereotyp «Signal» sollte ein gleichnamiges
Signal existieren (Vollständigkeitsbedingung)
• Signal-2: Die Anzahl der Argumente der „Signaloperation“ sollte mit der Anzahl
der Argumente (Attribute) des Signals übereinstimmen (vgl. [OMG99], Seite 2-95
SendAction).
• Signal-3: Die Parameternamen und -typen einer „Signaloperation“ sollten mit den
Attributnamen und -typen übereinstimmen.
Die Reihenfolge der Parameter kann nicht vorgeschrieben werden, da die Attribute
eines Signal (einer Klasse) nicht geordnet sind.
• Signal-4: Eine Klasse, die ein Signal empfangen kann, sollte einen Zustandsautomaten besitzen, der die Reaktion auf den Empfang des Signals spezifiziert (Vollständigkeitsbedingung).
• Signal-5: Eine Klasse, die ein Signal empfangen kann, sollte eine aktive Klasse
sein.
• Signal-6: Zu einer mit «send» markierten Abhängigkeitsbeziehung zwischen einer
Operation und einem Signal (d.h. die Operation kann das Signal senden), sollte
in einem Aktivitätsdiagramm der Operation (falls vorhanden) die Verwendung des
Signals spezifiziert werden (Vollständigkeitsbedingung).
Die Spezifikation dieser Abhängigkeit ist in Rose nicht möglich.
• Signal-7: Besitzt der Klassifizierer, der ein Signal sendet, einen Zustandsautomaten, so sollte dort das Senden des Signals ebenfalls modelliert sein (Vollständigkeitsbedingung).
• Signal-8: Signale dürfen keine Operationen besitzen (in [OMG99] auf Seite 3-136
„versteckt“)5 .
• Signal-9: Zu einem Signal sollte eine „Signaloperation“ existieren.
Die offizielle Dokumentation der UML ([OMG99]) sowie die benutzte Literatur lassen noch einige Fragen unbeantwortet:
• Welche Bedeutung hat die Sichtbarkeit der Merkmale eines Signals?
• Da Signale generalisierbare Modellelemente sind, können „Signalhierarchien“ modelliert werden (Beispiel: siehe [BRJ99a], Seite 321).
– Wie funktioniert in diesem Fall der Vererbungsmechanismus?
5 Nach
[BRJ99a], Seite 315, können Signale Operationen besitzen!
164
– Wenn eine Klasse ein bestimmtes Signal empfangen kann, kann es dann auch
ein Sub-Signal empfangen?
Nach dem Prinzip der Substituierbarkeit müßte eine Klasse auch Sub-Signale
empfangen können. Nach [Alh98], Seite 199, kann ein Sub-Signal auch Transitionen, die durch ein Super-Signal spezifiziert sind, triggern.
4.5.11
Spezifizierung von Rollen
Rollen in einer Assoziationsbeziehung können durch Schnittstellen oder Typen näher spezifiziert werden (Abb. 4.35, vgl. [BRJ99a], Seite 182 ff). Typen sind mit «type» stereo-
+Vorgesetzer: IManager
1..1
Person
IMitarbeiter
0..*
+Mitarbeiter: IMitarbeiter
IManager
Abbildung 4.35: Spezifizierung von Rollen durch Interfaces
typisierte Klassen, die sich von Interfaces dahingehend unterscheiden, daß die Definition
eines Typs Attribute enthalten kann. Die Typen in Abb. 4.36 repräsentieren verschiedene
Rollen, die ein Objekt der Klasse Person im Laufe der Zeit spielen kann.
<<type>>
Bewerber
<<type>>
Mitarbeiter
<<type>>
Pensionär
Person
Abbildung 4.36: Typen, die potentielle Rollen der Klasse Person darstellen.
Die Benutzung von Interfaces oder Typen zur Spezifizierung einer Rolle in einer Assoziation wird im Metamodell durch das Attribut specification der Klasse Association-
165
End spezifiziert. Ein Assoziationsende kann durch mehrere Typen und Interfaces spezifiziert werden.
Konsistenzbedingungen:
• Rolle-3: Wird eine Rolle durch Interfaces oder Typen näher spezifiziert, dann muß
die Klasse der Rolle dieses Interface oder diesen Typen realisieren.
Der Zugriff auf die Merkmale einer Klasse über die Assoziation wird dann auf die
durch die Rolle spezifizierten Merkmale beschränkt.
• Typ-1: Der Vorfahr eines Typen muß ein Typ sein ([OMG99], Seite 2-56).
• Typ-2: Typen besitzen keine Methoden ([OMG99], Seite 2-56), d.h. ebenso wie
Interfaces sind die Operationen implizit abstrakt.
4.6
Interaktionsdiagramme
Interaktionsdiagramme werden benutzt, um den Ablauf der Kommunikation zwischen
Objekten zur Erfüllung einer bestimmten Aufgabe anhand von Botschaften zu spezifizieren. Die beiden Interaktionsdiagramme der UML, Kollaborations- und Sequenzdiagramm, sind semantisch äquivalent, da sie auf den gleichen Klassen des UML-Metamodells
(Abb. 3.42, Seite 98) basieren.
Ein Kollaborationsdiagramm hebt den strukturellen Kontext der Interaktion hervor,
während die Reihenfolge der Botschaften nur durch Nummern gekennzeichnet in den
Hintergrund rückt. Ein Kollaborationsdiagramm der Spezifikationsebene besteht aus Klassifizierer- und Assoziationsrollen, die Objekte und Links repräsentieren, und Botschaften,
während ein Kollaborationsdiagramm der exemplarischen Ebene Objekte, Links und Stimuli enthält.
Sequenzdiagramme existieren nur auf einer exemplarischen Ebene. Sie heben die Reihenfolge der Botschaften bzw. Stimuli hervor ohne den strukturellen Kontext zu zeigen.
In Rose können Kollaborationsdiagramme nicht auf einer Spezifikationsebene modelliert werden. Kollaborationsdiagramme der exemplarischen Ebene und Interaktionsdiagramme werden in Rose intern auf die selben Klassen abgebildet (Abb. 4.45). Dies
ermöglicht die Generierung eines Kollaborationsdiagramms aus einem Sequenzdiagramm
(oder umgekehrt), wobei sich Änderungen eines Diagramms automatisch auf das andere
übertragen.
4.6.1
Klassifiziererrollen und Objekte
Klassifiziererrollen und Objekte in Interaktionsdiagrammen repräsentieren Sender oder
Empfänger von Botschaften bzw. Stimuli. Neben der Klassenzugehörigkeit einer Klassifiziererrolle oder eines Objekts können Attribute oder Attributwerte dargestellt werden
(Abb. 4.37 und 4.38).
4.6. INTERAKTIONSDIAGRAMME
166
/Mitarbeiter:Person
optionale Merkmale der Klasse 'Person'
Abbildung 4.37: Spezifikationsebene: Eine Klassifiziererrolle wird mit dem Namen der
Rolle und der Klasse sowie optional weiteren Merkmalen der Klasse,
die in der Kollaboration benötigt werden, dargestellt.
Schubert/Mitarbeiter : Person
Abbildung 4.38: Exemplarische Ebene: Der Namensanteil eines Objekts in einem Interaktionsdiagramm besteht aus einem Objektnamen, einer Klassifiziererrolle und dem Namen der Klasse des Objekts. Optional können weitere
Merkmale des Objekts dargestellt werden.
Im Metamodell (Abb. 3.42, Seite 98) ist eine Klassifiziererrolle (ClassifierRole)
mit genau einem Basisklassifizierer (Pseudoattribut base) assoziiert. Eine entsprechende
Metaklasse für Objekte, die eine Rolle in einer Kollaboration spielen, z.B. ObjectRole,
ist im Paket Kollaboration nicht angegeben. Die Semantik läßt sich jedoch übertragen:
Ein Objekt muß mit genau einem Klassifizierer assoziiert sein (vgl. Abb. 3.36, Seite 88,
dort ist ein Objekt mit mindestens einem Klassifizierer assoziiert).
Die Abbildung einer Klassifiziererrolle (Abb. 4.37) auf das Metamodell der UML
bzw. auf ein Metamodell eines Werkzeugs ist auf (mindestens) zwei Arten möglich:
1. Der Rollenname und der Klassenname wird auf das Attribut name der Metamodellklasse ClassifierRole abgebildet (Abb. 4.37).
: ClassifierRole
name = Mitarbeiter:Person
Abbildung 4.39: Instantiierung von Abb. 4.39. Geeignet für ein Werkzeug, welches die
Modellierung von Klassifiziererrollen zuläßt, ohne die Existenz der Basisklasse zu fordern.
Bei dieser Art der Abbildung muß die folgende Konsistenzbedingung überprüft
werden:
• Inter-1: Es muß eine Klasse mit dem Namen der Klasse (hier „Person“) existieren. Diese Klasse muß die optional dargestellten Merkmale besitzen. Dies
gilt entsprechend für Objekte in Interaktionsdiagrammen.
167
Eine werkzeugunterstützte Überprüfung dieser Bedingung erfordert die eindeutige
Identifizierung des Rollen- und Klassennamens.
2. Es wird nur der Rollenname auf das Attribut name der Metamodellklasse abgebildet. Der Name der Klasse ist implizit der Name der Basisklasse der Klassifiziererrolle (Abb. 4.40). Läßt das Werkzeug in diesem Fall nur die Darstellung vorhan: ClassifierRole
name = Mitarbeiter
: Class
base name = Person
Abbildung 4.40: Alternative, semantisch korrekte Instantiierung von Abb. 4.37. Bei dieser Art der Instantiierung muß eine Klasse mit dem Namen „Person“
existieren.
dener Merkmale der Basisklasse zu, wird die oben genannte Konsistenzbedingung
aktiv unterstützt.
Im folgenden wird von dieser Art der Abbildung auf das Metamodell ausgegangen.
4.6.2
Assoziationsrollen und Links
Eine Interaktion zwischen Objekten setzt voraus, daß das Sendeobjekt das Empfangsobjekt „kennt“. Dies wird in einem Kollaborationsdiagramm durch eine Assoziationsrolle
bzw. einen Link dargestellt. Bei einem Botschaftenaustausch zwischen Objekten wird
dieser Link zur Kommunikation genutzt. Eine Assoziation zwischen Klassifiziererrollen
bzw. ein Link zwischen Objekten basiert auf einer Assoziation zwischen Klassen.
Das Klassendiagramm in Abb. 4.41 zeigt die Basisklassifizierer und die Basisassoziation für die Kollaborationsdiagramme in Abb. 4.42 und Abb. 4.43. Abb. 4.44 zeigt die
Zusammenhänge zwischen dem Klassendiagramm (Abb. 4.41) und dem Kollaborationsdiagramm der Spezifikationsebene (Abb. 4.43).
Die folgenden Konsistenzbedingungen sind zu überprüfen (siehe Abb. 4.44):
• Inter-2: Zu einer Assoziationsrolle muß eine entsprechende Basisassoziation (base)
zwischen den Basisklassifizierern der Klassifiziererrollen existieren (vgl. [OMG99],
S. 2-104). Dies kann auch eine geerbte Assoziation sein. Dies läßt sich auf die
exemplarische Ebene übertragen: Zu einem Link zwischen Objekten muß eine (geerbte) Assoziation zwischen den Klassen der Objekte existieren.
Ein Link kennzeichnet eine Kommunikationsverbindung, über die ein Objekt eine
Botschaft an ein anderes Objekt schicken kann. Damit Objekte, deren Basisklassen
nicht assoziiert sind, Botschaften austauschen können, gibt es Ausnahmen von der
Bedingung Inter-2 (siehe Abschnitt 4.6.3).
Bei aktiver Konsistenzunterstützung kann der Name der Assoziation übernommen
werden.
168
<<type>>
Mitarbeiter
<<type>>
Manager
Person
+Leiter:Manager
0..1
*
+MA:Mitarbeiter
leitet
Abbildung 4.41: Die Rollen einer Person werden durch Typen spezifiziert. Die Abbildungen 4.42 und 4.43 zeigen die Benutzung dieser Information in Kollaborationsdiagrammen.
leitet
/Mitarbeiter:Person
/Manager:Person
0..1
*
Abbildung 4.42: Verwendung der Typen aus Abb. 4.41 als Klassifiziererrollen in einem
Kollaborationsdiagramm der Spezifikationsebene.
Müller/Mitarbeiter :
Person
leitet
Schmidt/Manager :
Person
Abbildung 4.43: Verwendung der Typen aus Abb. 4.41 als Rollen für Objekte in einem
Kollaborationsdiagramm der exemplarischen Ebene.
Abbildung 4.44: Instantiierung der Abbildungen 4.41 und 4.42. Eine Klassifiziererrolle basiert auf einer Klasse. Eine Assoziationsrolle zwischen Klassifiziererrollen basiert auf einer Assoziation zwischen den entsprechenden
Klassen.
type
type
: AssociationEndRole
name
collaborationMultiplicity = 0..1
: AssociationRole
name
multiplicity
: AssociationEndRole
name
collaborationMultiplicity = *
Chart Name : New Object Diagram
Chart Filename : KollaborationBespielMeta.Vob
Chart Type : UML Object Diagram
: ClassifierRole
name = Manager
: ClassifierRole
name = Mitarbeiter
: Class
name = Manager
: Class
name = Mitarbeiter
specification
participant
specification
participant
: AssociationEnd
name = Leiter
base multiplicity = 0..1
base
: Association
name = leitet
AssociationEnd
name = MA
base multiplicity = *
type
base
: Class
name = Person
type
base
169
170
• Inter-3: Optionale Qualifizierer einer Assoziationsendrolle müssen eine Teilmenge
der Qualifizierer des Basisassoziationsendes sein (vgl. [OMG99], S. 2-104).
• Inter-4: Eine Assoziationsendrolle (bzw. ein Link-Ende) darf nur navigierbar sein,
wenn auch das entsprechende Basisassoziationsende navigierbar ist (vgl. [OMG99],
S. 2-104).
Bemerkungen:
• Weitere Bedingungen sind in [OMG99] nicht spezifiziert.
• Der Unterschied zwischen collaborationMultiplicity und multiplicity einer Assoziationsendrolle ist nicht klar definiert.
• Ein Beispiel für einen „echten“ Rollennamen einer Assoziation ist in [OMG99]
nicht angegeben, auch aus der weiteren UML-Literatur ist dem Autor kein Beispiel
bekannt.
Weitere sinnvolle Konsistenzbedingungen:
• Der Name der Klassifiziererrolle sollte der Name des entsprechenden Assoziationsendes oder der Name des Klassifizierers sein, der das Assoziationsende spezifiziert,
d.h. der Name eines Typen oder Interfaces.
• Wird das Assoziationsende spezifiziert, sollten die dargestellten Merkmale der Klassifiziererrolle eine Teilmenge der Merkmale des spezifizierenden Klassifizierers
sein.
• Die Kardinalität einer Assoziationsendrolle sollte eine Einschränkung der Kardinalität des Basisassoziationsendes sein oder mit ihr übereinstimmen.
Offene Frage: In welcher Modellierungssituation sollte man die Kardinalität einschränken?
• Die Sichtbarkeit einer Assoziationsendrolle darf nicht erweitert werden.
• Eine Assoziationsendrolle darf nur dann eine Aggregation/Komposition kennzeichnen, wenn dies auch für das Basisassoziationsende gilt.
Die Kardinalität einer Assoziationsrolle gibt die Anzahl der Links an, die diese Rolle
in der Kollaboration spielen. In [OMG99] ist kein Beispiel angegeben, das zeigt, wann die
Kardinalität einer Assoziationsrolle modelliert wird. Eine Notation für die Kardinalität
einer Assoziationsrolle ist ebenfalls nicht definiert.
Objekte und Links in Interaktionsdiagrammen werden in Rose auf die Klasse ObjectInstance bzw. Link abgebildet (Abb. 4.45).
Bei der Modellierung von Objekten in Interaktionsdiagrammen kann in Rose der Klassenname des Objekts aus den vorhandenen Klassen gewählt werden. Die Eingabe eines
171
Element
Name
RoseItem
Stereotype
ObjectInstance
Class
0..1
ClassName
Links
MultipleInstances
Persistence
Association
Link
0..1
AddLink()
DeleteLink()
GetClass()
IsClass()
+Receiver
LinkRole1
LinkRole2
LinkRole1Visibility
LinkRole2Visibility
AddMessageTo()
AssignAssociation()
DeleteMessage()
GetMessages()
UnAssignAssociation()
0..1
Operation
Message
Frequency
Synchronization
GetSenderObject()
GetReceiverObject()
IsMessageToSelf()
IsOperation()
GetOperation()
GetLink()
+Sender
Abbildung 4.45: Metadarstellung der Objekte, Links und Botschaften (Message) in Rose.
beliebigen Klassennamens ist nicht möglich. Multi-Objekte (Attribut MultipleInstances) repräsentieren die Existenz mehrerer Objekte. Die Bedingung Inter-1 kann von Rose
geprüft werden (Menü: Report - Show unresolved Objects).
Nach dem gleichen Schema kann in Kollaborationsdiagrammen eine benannte(!) Basisassoziation eines Links ausgewählt werden. Dabei werden die Rollen- und Qualifizierernamen der Assoziationsenden sowie der Assoziationsname übernommen. Die Rollenund Qualifizierernamen werden an den Link-Enden und der Assoziationsname, der durch
einen Linknamen erweitert werden kann, als Name des Links dargestellt. Unter den auswählbaren Assoziationen befinden sich neben den geerbten Assoziationen der Basisklassen auch Assoziationen zwischen den Oberklassen der Basisklassen, die nicht vererbt
werden (die Sichtbarkeit der Assoziationsenden ist private). Verletzungen der Bedingung Inter-2 werden nicht identifiziert, zusätzliche Qualifizierer können nicht hinzugefügt werden (eine Verletzung von Inter-3 wird verhindert). Die Navigierbarkeit von Links
(Inter-4) kann nicht spezifiziert werden.
4.6.3 Botschaften und Stimuli
Die Spezifikation einer Botschaft besteht aus der Angabe eines Senders und eines oder
mehrerer Empfänger. Der eigentliche Inhalt der Botschaft besteht aus einer Aktion (meistens ein Operationsaufruf) und optionalen Parametern.
172
{ordered}
Feature
+feature
BehavioralFeature
Reception
+reception
+context
*
0..*
1
*
Operation
1
+raisedSignal
+operation
1 +signal
1
+signal 1
SendAction
DestroyAction
ReturnAction
+actualArgument
Action
{ordered} *
0..1
1..*
+classifier
+instantiation
0..*
*
CallAction
CreateAction
Argument
value : Expression
+predecessor
Message
+action
1
+dispatchAction
Classifier
Signal
*
TerminateAction
+owner
*
*
*
+activator
1
*
0..1
*
+communicationLink
Stimulus
*
{ordered}
* +argument
*
1 +sender
Link
0..1
*
*
1
+receiver
Instance
*
Abbildung 4.46: Die Ausführung einer Aktion erzeugt einen Stimulus, welcher die
Sende- und Empfangsinstanz referenziert, einen Link zur Kommunikation benutzt und eventuell Argumente enthält.
173
Die Ausführung der Aktion erzeugt eine entsprechende Anzahl von Stimuli, die jeweils über einen Link (communicationLink) von einem Sendeexemplar zu einem Empfangsexemplar versandt werden (Metadarstellung siehe Abb. 4.46). Ein Link gibt an, daß
der Sender den Empfänger „sieht“ bzw. seine „Adresse kennt“. Der Empfang des Stimuli
führt beim Empfänger zur Ausführung eines Verhaltens entsprechend der Aktion.
Der Kommunikationslink kann in speziellen Fällen (auf der Metaebene) fehlen, obwohl er im Kollaborationsdiagramm dargestellt wird. Dies gilt sowohl für die Spezifikationsebene, in der eine Assoziationsrolle einen oder mehrere Links repräsentiert, als
auch für die exemplarische Ebene. In den folgenden Fällen kann ein Link bzw. eine
Assoziation als Basis für eine Kommunikation zwischen Sender und Empfänger fehlen:
• Dem Sender wurde eine Referenz auf das Empfangsexemplar als Parameter übergeben. In diesem Fall kann das Link-Ende des Empfängers mit «parameter» markiert
werden.
• Der Empfänger der Botschaft/des Stimuli ist global oder lokal sichtbar. Dann kann
das Link-Ende mit «global» oder «local» markiert werden.
• Der Sender und der Empfänger repräsentieren das gleiche Objekt. Dann kann das
Linkende mit «self» markiert werden.
Rose ermöglicht die Spezifizierung der Link-Enden, indem dem Sender und dem
Empfänger einer Botschaft eine Sichtbarkeit zugeordnet wird (Attribut LinkRole1Visibility bzw. LinkRole2Visibility der Klasse Link). Zur Verfügung stehen u.a. die
Werte „Parameters“, „Global“ und „Local“. Mit diesen Informationen kann die Bedingung Inter-2 neu formuliert werden:
• Inter-2’: Zu einem Link zwischen Objekten muß entweder eine (geerbte) Assoziation zwischen den Basisklassen existieren oder der Link muß mit Parameter, Global
oder Local markiert sein oder die beiden Link-Enden verweisen auf das gleiche Objekt (self).
Im Metamodell (Abb. 4.46) werden Operationsaufrufe einer Botschaft auf die Klasse
CallAction abgebildet. Für einen Operationsaufruf gilt die folgende Konsistenzbedingung:
• Inter-5: Der Name der Operation muß mit dem Namen einer Operation des Empfangsobjekt übereinstimmen bzw. muß die Klasse des Empfangsobjekts die Operation deklariert oder geerbt haben.
Bei der Spezifikation einer Botschaft ermöglicht Rose die Auswahl einer vom Empfänger
angebotenen Operation (inklusive geerbter öffentlicher Operationen). Alternativ kann ein
beliebiger Text als Botschaft eingegeben werden. Dieser Text referenziert aus der Sicht
von Rose keine Operation und ist in diesem Sinne nicht konsistent. Anstelle eines Textes,
174
1: Reservierung(long, double)
: Artikel
Lager
: Artikel
Reservierung
Abbildung 4.47: Notation einer Botschaft im Kollaborationsdiagramm, die einen Operationsaufruf spezifiziert. Die Argumente werden in diesem Fall durch die
Parametertypen der Operation repräsentiert.
der eine Operation bzw. eine „Signaloperation“ repräsentieren sollte, ist es möglich, aus
einem Interaktionsdiagramm heraus eine Klasse um die gewünschte Operation zu erweitern. Im Falle einer referenzierten Operation stellt Rose die Operationsignatur in der Nähe
eines Pfeils dar (Abb. 4.47), der die Richtung der Botschaft kennzeichnet. Rose bietet die
Möglichkeit, die Bedingung Inter-3 auf Anforderung zu prüfen. Dabei wird festgestellt,
ob eine vorhandene Operation der Klasse des Empfangsobjekts referenziert wird.
Wird eine in einem Interaktionsdiagramm referenzierte Operation aus der Klasse des
Empfangsobjekts gelöscht, wird der Operationsname inklusive Parametertypen intern als
Text gespeichert, d.h. die entsprechende Botschaft wird nicht aus dem Interaktionsdiagramm gelöscht. Rose warnt nicht vor der Löschung der Operation, obwohl sie eine
Inkonsistenz zur Folge hat.
Das Senden eines Signals wird im Metamodell auf die Klasse SendSignal abgebildet.
Für das Senden eines Signals gilt die folgende Konsistenzbedingung:
• Inter-6: Der Empfänger muß den Empfang des Signals erklärt haben.
Da in Rose nicht zwischen Sende- und Aufrufaktionen unterschieden werden kann,
werden Signale wie Operationen behandelt. In Rose wird das Stereotyp einer Operation
nicht dargestellt, d.h. man kann visuell nicht zwischen Operationen und Signalen unterscheiden.
Die Darstellung der Argumente einer Botschaft einer CallAction oder SendAction
ist auf drei Arten möglich:
1. Die Argumente sind Referenzen auf Objekte, die im Diagramm enthalten sind.
Dann werden die Argumente auf die Argumente des Stimulus abgebildet (Pseudoattribut argument der Klasse Stimulus).
2. Ein Argumentausdruck, dessen Auswertung die Aktualargumente bestimmt, wird
auf die Argumente der mit dem Stimulus assoziierten Aktion abgebildet (Pseudoattribut actualArgument der Klasse Argument).
3. Die Typen der Argumente werden zusammen mit den Namen der Operation/des
Signals dargestellt. Dann werden die Argumente auf die Parameter-Typen der Operation bzw. die Attributtypen des Signals abgebildet.
175
Rose unterstützt nur die letzte Möglichkeit der Argumentdarstellung semantisch korrekt, die anderen Möglichkeiten können zwar genutzt werden (eine Nachricht kann ein
beliebiger Text sein), führen jedoch (aus der Sicht von Rose) zu inkonsistenten Modellen.
Weitere Arten von Aktionen in Interaktionsdiagrammen sind Rückgabe-, Erzeuge-,
Zerstöre-, Terminiere-Aktionen (siehe Abb. 4.46). Zuweisungsaktionen können nicht in
Interaktionsdiagrammen benutzt werden. Rückgabeaktionen werden nur in Sequenzdiagrammen gezeigt. Die anderen Aktionsarten besitzen in Sequenzdiagrammen eine eigene
graphische Notation (siehe Abb. 3.38, Seite 93). Die Modellierung dieser Aktionsarten
wird von Rose nicht unterstützt. Da die Stereotypen der Operationen in den Interaktionsdiagrammen nicht angezeigt werden, ist auch die alternative Darstellungsart mit Hilfe von
Stereotypen in Rose nicht möglich.
Der Rückgabewert einer Rückgabeaktion wird auf das Argument der Aktion abgebildet. Eine Rückgabeaktion setzt einen vorherigen Operationsaufruf voraus (Konsistenzbedingung siehe 4.6.4 Kontrollfluß).
Der Empfänger der Botschaft einer Erzeuge-Aktion ist das Objekt, welches durch den
Empfang der Botschaft bzw. des Stimuli erzeugt wurde. Eine Erzeuge-Aktion besitzt
kein explizites Ziel (target), da das Ziel implizit der Empfänger der Botschaft ist. Da im
Metamodell eine Erzeuge-Aktion mit genau einem Klassifizierer assoziiert ist, muß die
folgende Konsistenzbedingung berücksichtigt werden:
• Inter-7: Der Empfänger der Botschaft einer Erzeuge-Aktion muß ein Objekt der
Klasse sein, mit der die Aktion assoziiert ist.
Die Botschaft einer Zerstöre-Aktion führt zur Zerstörung des Empfangsobjekts. Die
Botschaft einer Terminiere-Aktion, die zur Selbstzerstörung eines Objekts führt, muß die
folgende Konsistenzbedingung erfüllen:
• Inter-8: Der Empfänger und der Sender einer Botschaft einer Terminiere-Aktion
müssen übereinstimmen.
4.6.4
Kontrollfluß
Wenn ein Sender einem Empfänger eine Botschaft sendet, kann der Empfänger auf den
Empfang der Botschaft reagieren, indem er selbst wiederum eine Botschaft schickt usw.
Die Botschaften bilden eine sequentiell zeitlich geordnete Folge (Kontrollfluß), die immer zu einem Prozess oder Thread gehört. Die Folge der Botschaften wird visuell durch
Sequenznummern (siehe Abschnitt 3.2.2) dargestellt.
Man unterscheidet zwischen flachen und prozedualen bzw. verschachtelten Kontrollflüssen (siehe [BRJ99a], Seite 240 ff). Bei flachen Kontrollflüssen, die meist im Kontext
von Anwendungsfällen modelliert werden, wird die Kontrolle von einem Objekt zum
nächsten weitergegeben, während bei prozedualen Kontrollflüssen (Abb. 4.48) die Kontrolle an den Aufrufer einer Operation zurückgegeben wird.
Object 1
176
Object 2
Object 3
Object 4
1:
1.1:
1.2:
Abbildung 4.48: Prozedualer Kontrollfluß
+activator 0..1
*
Message
* +predecessor
*
Abbildung 4.49: Reihenfolge der Botschaften/Stimuli
Die Reihenfolge der Botschaften wird im Metamodell auf die Pseudoattribute predecessor (Vorgänger) und activator (Aktivierer) abgebildet (Abb. 4.49). In Abb. 4.48
ist Botschaft 1.1 der Vorgänger von Botschaft 1.2. Der Aktivierer einer Botschaft ist
die Botschaft, dessen Empfang zum Senden der Botschaft führt. In Abb. 4.48 aktiviert
Botschaft 1 die Botschaften 1.1 und 1.2.
Wenn X eine beliebige Sequenznummer ist, gilt allgemein:
• X.i ist Vorgänger von X.i+1
• Aktivierer von X.i ist X.
Die Botschaften 1, 1.1 und 1.2 repräsentieren Operationsaufrufe (ausgefüllte Pfeilspitze). Ein Operationsaufruf aktiviert eine (verschachtelte) Folge, die durch eine Rückgabebotschaft (Rückgabe-Aktion) abgeschlossen wird. Die Rückgabebotschaft bzw. die
Rückgabe der Kontrolle an den Aufrufer ist implizit vorhanden, auch wenn sie nicht explizit dargestellt wird. Im Falle eines Operationsaufrufs lassen sich auf diese Weise Rückschlüsse auf die Implementierung der Operation ziehen (zumindest auf die Reihenfolge
weiterer Operationsaufrufe).
Für eine Rückgabebotschaft lassen sich die folgenden Konsistenzbedingungen formulieren (vgl. [OMG99], Seite 3-101):
• Inter-9: Eine Rückgabebotschaft setzt eine aktivierende Botschaft voraus.
177
• Inter-10: Eine Rückgabebotschaft ist die letzte Botschaft in einer Vorgängerkette.
4.6.5
Verzweigung und Iteration
In den Interaktionsdiagrammen können auch auch Verzweigungen (siehe Abb. 3.38, Seite
93) und Iterationen (Abb. 4.50) modelliert werden.
Falls ein Interaktionsdiagramm Iterationsausdrücke beinhaltet, kann die Reihenfolge der Botschaften nicht mehr konsistent auf das Metamodell abgebildet werden. Abb.
4.50 zeigt die typische Verwendung eines Iterationsausdrucks in einem (exemplarischen)
Kollaborationsdiagramm.
Chart Name : New
Chart Filename : c
Chart Type : UML
b : Bestellung
1.1* [i=1..*]: bpos := gibBestellPosition(i)
«parameter»
Object 1
: ArtikelReservierung
: ArtikelLager
1.1.3: reserviere(artikel, anzahl)
1: reserviere(b)
1.1.1: artikel := gibArtikel()
1.1.2: anzahl := gibAnzahl
«local»
bpos : BestellPosition
Abbildung 4.50: Iteration in einem Kollaborationsdiagramm, vgl. [Oes98], Seite 305.
Die Botschaft, die die Iteration initiiert, wird um einen Iterationsausdruck erweitert. Die Sequenznummern der Botschaften innerhalb der
Iteration besitzen eine Stelle mehr.
Botschaft 1.1 liefert iterativ eine bestimmte Bestellposition, die von den Botschaften in der untergeordneten Ebene benutzt wird. Abbildung 4.51 zeigt die gleiche Interaktion in einem Sequenzdiagramm inklusive der Sequenznummern. Die Reihenfolge
der Botschaften entsprechend der oben genannten Bedingungen stimmt leider nicht mehr
Chart Name : Reservierung
Chart Filename : seqUntitled2.Vob
Chart Type : UML Sequence Diagram
4.7. ZUSTANDSDIAGRAMME
...
178
1: reserviere(b)
b : Bestellung
bPos : BestellPosition
: ArtikelLager
«parameter»
1.1* [i=1..n]: gibBestellPos(i)
bPos
1.1.1: artikel := gibArtikel()
1.1.2: gibMenge()
menge
1.2:
1.1.3: reserviere(artikel, anzahl)
Abbildung 4.51: Interaktion aus Abb. 4.50 in einem Sequenzdiagramm.
mit den Sequenznummern überein. Wenn im Sequenzdiagramm die problematischen Sequenznummern in 1.1, 1.2, 1.3 und 1.4 verändert werden, so stimmt dies zwar mit den o.a.
Bedingungen überein, jedoch ist die Verschachtelung der Botschaften nicht mehr sichtbar.
Das Problem ist die Botschaft mit dem Iterationsausdruck, die auf mehrere Stimuli des
Metamodells abgebildet werden müßte. In [Oes98] ist auf Seite 308 die gleiche Situation
wie in Abb. 4.50 in einem Sequenzdiagramm modelliert. Im Unterschied zu Abb. 4.51
fehlt dort allerdings der Iterationsausdruck.
In [Alh98] wird eine Iteration in Sequenzdiagrammen durch ein Rechteck markiert,
welches die Botschaften innerhalb der Iteration umfaßt. Bei dieser Modellierungsart gehört die Iteration nicht mehr zu einer Botschaft, und die zur Iteration gehörenden Botschaften sind visuell leicht zu erkennen (Abb. 4.52). Leider ist diese Modellierungsweise
nicht in [OMG99] angegeben und läßt sich auch nicht auf ein Metamodellexemplar abbilden.
4.7
Zustandsdiagramme
Ein Zustandsdiagramm (Statechart) enthält einen Zustandsautomaten, der aus Zuständen,
Transitionen, Ereignissen und Aktionen besteht. Zustandsdiagramme werden zur Modellierung des Verhaltens von Modellelementen eingesetzt. Bei diesen Modellelementen
handelt es sich meistens um Klassen. Die Definition der UML erlaubt jedoch auch, das
Verhalten von anderen Modellelementen (z.B. Operationen) mit Zustandsdiagrammen zu
modellieren.
In diesem Abschnitt werden zuerst die elementaren Bestandteile eines Zustandsauto-
179
...
b : Bestellung
bpos : Bestellposition
: ArtikelLager
reserviere(b)
i = 1..n
gibBestellPos(i)
bPos
artikel := gibArtikel
menge := gibMenge
reserviere(artikel, anzahl)
Abbildung 4.52: Darstellung einer Iteration in einem Sequenzdiagramm nach [Alh98],
Seite 176.
maten (Ereignisse, Aktionen, Transitionen und Zustände) behandelt. Abschließend wird
erläutert, wie aus diesen Bestandteilen Zustandsautomaten konstruiert werden können.
4.7.1 Ereignisse
Auf Signal, Aufruf-, Zeit- und Änderungsereignisse kann ein Zustandsautomat durch
Transitionen und Aktionen reagieren. Entry-, Exit- und Do-Ereignisse sind spezielle,
zu einem Zustand gehörende Ereignisse, die nicht zu einer Transition führen. Sie werden
in Abschnitt 4.7.4 behandelt.
Signal- und Aufrufereignisse werden mit der gleichen Syntax in Zustandsdiagrammen
dargestellt:
Ereignis-Name ’(’ Parameterliste ’)’
Eine Parameterliste ist eine durch Kommata getrennte Liste von Parametern, in der
der Parameter aus einem Parameternamen ([Alh98], Seite 198) besteht oder in der Form
Parametername ’:’ Typ-Ausdruck dargestellt wird ([OMG99], Seite 3-136).
Ein Signal- oder Aufrufereignis wird auf ein SignalEvent bzw. auf ein CallEvent
abgebildet, das mit dem entsprechenden Signal bzw. mit der entsprechenden Operation
verbunden ist (Abb. 4.53). Die Parameterliste des Ereignisses wird auf die Parameter
des Ereignisses abgebildet, die im Metamodell als existenzabhängige Teile des Ereignisses definiert sind, d.h. die Parameter einer Operation und die Parameter eines AufrufEreignisses sind unterschiedliche Objekte des Metamodellexemplars
Aus Abb. 4.53 lassen sich die folgenden Konsistenzbedingungen für Signal- und
180
ModelElement
Parameter
{ordered}
+parameters
*
SignalEvent
Event
0..1
CallEvent
TimeEvent
when : TimeExpression
+occurrence
*
+occurrence
1
ChangeEvent
changeExpression : BooleanExpression
*
1
Operation
Signal
Abbildung 4.53: Ereignisse im Metamodell
Aufruf-Ereignisse ableiten:
• Ereignis-1: Der Name eines Signal- oder Aufrufereignisses muß mit dem Namen
eines Signal oder einer Operation übereinstimmen.
Gehört das Ereignis zum Zustandsdiagramm einer Klasse, sollte die Klasse den
Empfang des Signals bzw. die Operation deklariert haben.
• Ereignis-2: Die Anzahl der Parameter eines Signal- oder Aufrufereignisses müssen mit der Anzahl der Attribute des Signals bzw. mit der Parameteranzahl der
Operation übereinstimmen.
Gehört das Ereignis zum Zustandsdiagramm einer Klasse, dann sollte die Reihenfolge der Parameter des Signals bzw. der Operation mit der Reihenfolge der Parameter des Ereignisses übereinstimmen.
Bemerkung: Es läßt sich anhand der Notation nicht zwischen Signal- und Aufrufereignissen unterscheiden. Wenn das Zustandsdiagramm das Verhalten einer Klasse spezifiziert, ist das Signal als Operation mit dem Stereotyp «signal» deklariert (Ereignis-1).
Zur Überprüfung der Konsistenzbedingung Ereignis-2 muß dann nicht mehr zwischen
Signal- und Aufrufereignissen unterschieden werden. Eine visuelle Unterscheidung zwischen Signal- und Aufrufereignis ist nicht unbedingt notwendig, da das empfange Objekt
den Unterschied „kennt“.
181
Ein Zeitereignis wird durch das Schlüsselwort after, gefolgt von einem Zeitausdruck
(TimeExpression) dargestellt, z.B. after (10 sec.), und auf ein TimeEvent abgebildet.
Ein Änderungsereignis wird durch das Schlüsselwort when, gefolgt von einem booleschen Ausdruck (ChangeExpression) dargestellt, z.B. when (antwort = 42), und auf ein
ChangeEvent abgebildet.
Im Metamodell ist etwas verwirrend als Attributname für den Zeitausdruck eines Zeitereignisses when angegeben. Ein Ereignis der Art when (datum = 1. Jan. 2000) kann
zwar als Zeitereignis mit einem absoluten Zeitpunkt interpretiert werden, wird aber entsprechend des Schlüsselworts auf ein Änderungsereignis abgebildet (vgl. [OMG99], Seite
3-136).
Die Spezifizierung von Zeit- und Änderungsereignissen sollte zum entsprechenden
Typ des Ausdruck passen. Da eine Syntax dieser Ausdrücke nicht definiert ist, kann
eine derartige Konsistenzbedingung auf der Basis des UML-Metamodells nicht durch ein
Werkzeug überprüft werden.
Aus dem Metamodell folgt:
• Ereignis-3: Zeit- und Änderungsereignisse dürfen keine Parameter besitzen.
Element
Name
Event
Arguments
Abbildung 4.54: Die Klasse Event des Rose-Metamodells. Event besitzt keine Operation, die gegebenenfalls eine Operationssignatur o.ä. der Klasse liefert,
dessen Verhalten vom Zustandsdiagramm spezifiziert wird.
In Rose wird ein Ereignis auf die Klasse Event abgebildet (Abb. 4.54). Der Ereignisname und die Parameter werden in verschiedenen Attributen gespeichert. In Rose wird
nicht zwischen verschiedenen Ereignisarten unterschieden, der Ereignisname ist lediglich
ein String. Da in Rose ein Zustandsdiagramm immer das Verhalten einer Klasse spezifiziert, ist eine Unterscheidung zwischen Signal- und Aufrufereignis nicht notwendig, Zeitund Änderungsereignisse können anhand der Schlüsselworte after und when von Signalund Aufrufereignissen unterschieden werden, falls kein Signal oder eine Operation der
Klasse mit dem Namen after bzw. when existiert.
4.7.2
182
Aktionen
Aktionen und Aktivitäten kennzeichnen die Reaktion eines Zustandsautomaten auf ein
Ereignis. Eine Aktion ist eine ausführbare atomare Verarbeitung, typischerweise ein
Operationsaufruf oder das Senden eines Signals. Eine Aktion kann aber auch ein Ausdruck sein, der Attribute, Links und Parameter eines Ereignisses beinhaltet oder die Erzeugung/Zerstörung eines Objekts kennzeichnet. Eine Aktion eines Zustandsautomaten
gehört entweder zu einer Transition (4.7.3) oder zu einem Zustand (4.7.4).
Eine Aktion wird in der folgenden Form notiert:
Ereignis-Signatur ’[’ Bedingung ’]’ ’/’ Aktionsausdruck
Anhand der Notation kann nicht unterschieden werden, ob es sich um eine AufrufAktion, eine Sende-Aktion oder eine andere Aktion handelt (siehe Abb. 4.55). Die Notation des Aktionsausdrucks hängt von der gewählten Sprache für die Aktionsausdrücke
ab ([OMG99], Seite 3-138). Da eine Aktion immer eine beliebige Aktionsart sein kann,
können Konsistenzbedingungen an eine Aktion nur dann identifiziert werden, wenn klar
ist, um welche Art es sich bei der Aktion handelt:
• Aktion-1: Falls es sich um eine Aufruf-Aktion handelt, wird eine Operation auf
einem Objekt einer Klasse aufgerufen. Diese Klasse sollte die Operation deklariert
haben und sich im Sichtbarkeitsbereich des Eigentümers des Zustandsautomaten
befinden. Diese Bedingung gilt im übertragenden Sinne auch für das Senden eines
Signals.
• Aktion-2: Die Anzahl der Parameter eines Operationsaufrufs (eines Signals) sollte
mit der Deklaration der Operation (des Signals) übereinstimmen.
• Aktion-3: Der Aktionsausdruck sollte nur Merkmale aus dem Sichtbarkeitsbereich
des Eigentümers des Zustandsdiagramms und sprachabhängige Konstrukte beinhalten. Hieraus können sich weitere Konsistenzbedingungen ergeben, deren Überprüfung schwieriger zu realisieren ist.
Ein Werkzeug, welches den Modellierer bei der Erstellung konsistenter Modelle unterstützt, sollte die Möglichkeit bieten, die Aktionsart einer Aktion zu spezifizieren. In
diesem Fall erkennt das Werkzeug die Semantik einer Aktion und eine Konsistenzprüfung
ist möglich. Die Überprüfung auf konsistente Aktionen ist wichtig, da die Aktionsausdrücke häufig Verhaltensmerkmale (Operationen, Signale) anderer Modellelemente benutzen, und somit eine Verbindung zu anderen Diagrammen (eventuell Sichten) darstellen.
4.7.3
Transitionen
Eine Transition (Zustandsübergang) ist eine Beziehung zwischen Zuständen. Eine Transition besitzt mindestens einen Ausgangszustand (source), mindestens einen Folgezustand
183
(target), und jeweils optional ein Ereignis, eine Bedingung und eine Aktion (Abb. 4.55).
Ausgangszustand
Ereignis( Argument )[ Bedingung ] / Aktion
Folgezustand
Abbildung 4.55: Notation einer Transition mit Ereignis, Ereignisargumenten, einer Bedingungung und einer Aktion. Die Art der Aktion ist nicht erkennbar.
: Guard
expression = Ausdruck
guard
: State
name = Ausgangszustand
source
outgoing
: Transition
trigger
: Event
name = Ereignis
effect
: CallAction
incoming
target
: Parameter
name = Argument
: State
name = Folgezustand
: Operation
name = Aktion
Abbildung 4.56: Metamodellexemplar der Transition aus Abb. 4.55. Auf der Metaebene
ist erkennbar, daß „Aktion“ eine Operation ist.
Abb. 4.56 zeigt das entsprechende Metamodellexemplar von Abb. 4.55. Alle Informationen, die zu einer Transition spezifiziert werden können, sind sichtbar und die
Semantik ist klar. Semantisch gibt es sogar noch eine Verbindung von der Operation zu
einer Klasse. Ein Werkzeug, welches die Semantik von Aktionen versteht, könnte die
Konsistenzbedingungen aus Abschnitt 4.7.2 Aktionen überprüfen.
Abb. 4.57 zeigt, daß in Rose der Ausgangs- und Folgezustand, das Ereignis, die
Bedingung und die Aktion einer Transition spezifiziert werden kann, aber Rose die weiterreichende Semantik des Ereignisses (siehe 4.7.1) oder der Aktion nicht erkennt.
In früheren UML-Versionen konnte anhand der Notation noch zwischen Sende-Aktionen und anderen Aktionen unterschieden werden. Rose unterstützt diese Art der Notation.
Die Rose-Metaklasse Transition enthält die Operation GetSendAction, die ein Objekt
184
: State
Name = Ausgangszustand
: Event
Name = Ereignis
Arguments = Argument
GuardCondition = Bedingung
: Transition
: Action
name = Aktion
: State
Name = Folgezustand
Abbildung 4.57: Interne Darstellung Transition aus Abb. 4.55 in Rose.
der Klasse Action liefert (siehe Abb. 4.10). Zu einer solchen Sende-Aktion werden die
Aktion, die Argumente und das Ziel der Aktion auf jeweils eigene Attribute des AktionsObjekts abgebildet. Dadurch kann die Semantik einer Sende-Aktion genauer spezifiziert
werden.
Im Metamodell der UML ist eine Konsistenzbedingung für die Bedingung (guard)
angegeben ([OMG99], Seite 2-136):
• Transition-1: Die Auswertung der Bedingung einer Transition sollte nicht zu Seiteneffekten führen.
4.7.4
Zustände
„Ein Zustand ist ein Umstand oder eine Situation im Leben eines Objekts, während dem es
einer Bedingung genügt, eine Aktivität ausführt oder auf ein Ereignis wartet“ ([BRJ99a],
Seite 328).
Ein Zustand besitzt meistens einen Namen, der den Zustand von anderen Zuständen
unterscheidet. Ein Zustand ohne Namen wird „anonymer“ Zustand genannt.
Ein Zustand kann interne Transitionen enthalten. Falls eine interne Transition gefeuert
wird, findet kein Zustandsübergang statt. Insbesondere wird der Zustand nicht verlassen,
wie dies bei den sogenannten Selbsttransitionen der Fall ist, deren Ausgangs- und Folgezustand übereinstimmen.
entry, exit und do sind vordefinierte Ereignisse. Das Eintrittsereignis (entry) wird
beim Eintritt in den Zustand, das Austrittsereignis (exit) wird beim Verlassen des Zustands
ausgelöst. do wird fortlaufend ausgelöst, solange der Zustand aktiv ist.
185
Die mit einem do-Ereignis verbundene Aktion ist eine Aktivität, d.h. eine nichtatomare Folge von Aktionen. Eine Aktion kann als Aktionssequenz (Metamodellklasse
ActionSequence, siehe Abb. 3.34, Seite 85) spezifiziert werden, d.h. ebenso wie eine
Aktivität aus mehreren Aktionen bestehen. Der Unterschied zwischen einer atomaren
Aktion und einer nicht-atomaren Aktivität bezieht sich auf das Laufzeitverhalten des Zustandsautomaten: eine Aktivität kann durch ein Ereignis unterbrochen werden, während
eine Aktion immer bis zu Ende ausgeführt wird.
Neben den vordefinierten Ereignissen kann ein Zustand benutzerdefinierte Ereignisse
beinhalten. Zu jedem dieser Ereignisse kann eine Aktion bzw. eine Aktivität spezifiziert
werden. Abb. 4.58 zeigt die Darstellung eines Zustands mit internen Transitionen.
Zustandsname
exit: Austrittsaktion
do: anhaltendeAktivität
on verzögern: defer
entry: Eintrittsereignis
on Ereignis( Argument )[ Bedingung ]: Aktion
Abbildung 4.58: Notation eines Zustands.
Das entsprechende Metamodellexemplar (Abb. 4.59) ist wesentlich komplexer, da es
die Semantik der Aktionen beinhaltet, die visuell aus Abb. 4.58 nicht zu erfassen sind.
Die Rose-Metaklasse State besitzt die Operationen GetEntryActions, GetExitActions, GetDoActions und GetUserDefinedEvents, mit denen die entsprechenden
Aktionen bzw. Ereignisse ermittelt werden können (siehe Abb. 4.10). Die Art einer
Aktion kann jedoch nicht ermittelt werden (siehe Abschnitt 4.7.2).
Die Spezifikation der Ereignisse in Zuständen müssen (mindestens) zwei Bedingungen genügen:
• Ereignis-4: Jeder Ereignisname kann mehrfach in einem Zustand benutzt werden,
wenn die Bedingung (guard) eindeutig ist. ([OMG99], Seite 3-132)
• Ereignis-5: Die Aktionen der Eintritts-, Austritts- und do-Ereignisse können nicht
durch eine Bedingung verhindert werden.
Im Metamodell der UML (Abb. 3.47, Seite 109) sind diese Aktionen existenzabhänge Teile (Komposition) eines Zustands und nicht mit einer Bedingung verbunden.
In Rose kann die Konsistenzbedingung Ereignis-5 nicht verletzt werden. Eine Verletzung der Bedingung Ereignis-4 wird nicht entdeckt, es können sogar die vordefinierten
Ereignisse mehrfach spezifiziert werden.
186
: Operation
name = verzögern
entry
: CallEvent
deferableEvent
: SimpleState
name = Zustandsname
internal
: CallAction
: Operation
name = Eintrittsaktion
: SendAction
: Signal
name = Austrittsaktion
exit
doActivity
: Action
nicht näher
spezifizierte Aktivität
: Transition
trigger
: Parameter
name = Argument
: CallEvent
Operation
name = Ereignis
guard
: Guard
expression = Bedingung
effect
: CallEvent
: Operation
name = Aktion
Abbildung 4.59: Metamodellexemplar des Zustands aus Abb. 4.58.
4.7.5
Zustandsautomaten
Die Zustandsautomaten der UML sind rekursiv aufgebaut (Abb. 4.60). Jeder Zustandsautomat besteht aus einem Top-Level-Zustand, der weitere Zustände enthalten kann. Der
Top-Level-Zustand wird nicht im Zustandsdiagramm dargestellt. Die im Top-Level-Zustand enthaltenden Zustände können Kompositionszustände, die wiederum Kompositionszustände enthalten können, oder „einfache“ Zustände sein, die keine weiteren Zustände enthalten. Ein Kompositionszustand kann Anfangs- und Endzustände sowie weitere
Pseudozustände, z.B. flache und tiefe Erinnerungszustände beinhalten.
Ein Kompositionszustand repräsentiert einen Zustandsautomaten innerhalb eines Zustandsautomaten. Z.B. enthält der Kompositionszustand B-Ebene1 in Abb. 4.61 einen
Anfangs-, einen End- und den Kompositionszustand C-Ebene2, der wiederum weitere
Zustände enthält. Auf diese Weise können nicht nur flache Zustandsautomaten konstruiert
werden, sondern auch Zustandsautomaten, deren Zustände sich auf mehreren Ebenen befinden. Die Modellierung der Transitionen ist dabei nicht nur auf eine Ebene beschränkt:
Eine Transition kann zwischen Zuständen, die sich auf mehreren Ebenen befinden, modelliert werden (Abb. 4.61).
Das Metamodellexemplar von Abb. 4.61 ist zu komplex, so daß es hier ausgespart
wird. Diese Art von Zustandsautomaten kann mit Rose modelliert werden. Die Rose-
Chart Name : Ne
Chart Filename
Chart Type : UM
187
StateMachine
0..1
+top 1..1
State
0..*
+container
CompositeState
0..1
Abbildung 4.60: Rekursiver Aufbau eines Zustandsautomaten (vereinfachte Darstellung,
siehe auch 3.47, Seite 109)
.
B-Ebene1
C-Ebene2
D-Ebene3
A-Ebene1
E-Ebene3
Abbildung 4.61: Beispiel eines Zustandsautomaten mit mehreren verschachtelten
(Kompositions-) Zuständen (B und C).
188
Metaklasse State (Abb. 4.10, Seite 141) besitzt die Attribute Substates und StateKind,
die die Unterzustände eines Zustands bzw. die Art des Zustands (Start-, Endzustand oder
normaler Zustand) liefern. Flache und tiefe Erinnerungszustände können zwar modelliert,
aber nicht korrekt von Rose-Script ermittelt werden.
Für Zustandsautomaten, einfache Zustände, Kompositions- und Pseudozustände sind
in [OMG99], Seite 2-135 ff, mehrere Konsistenzbedingungen definiert:
• Zustandsautomat-1: Ein Zustandsautomat gehört entweder zu einem Klassifizierer oder einem Verhaltensmerkmal.
• Zustandsautomat-2: Wenn ein Zustandsautomat ein Verhaltensmerkmal beschreibt,
kann er keine Ereignistrigger vom Typ Aufruf-Ereignis besitzen. Ausgenommen
ist der Ereignistrigger der ausgehenden Transition des Anfangszustands des TopLevel-Zustands.
• Zustandsautomat-3: Ein Top-Level-Zustand ist immer ein Kompositionszustand.
• Zustandsautomat-4: Ein Top-Level-Zustand kann kein Ausgangszustand einer
Transition sein.
• Zustand-1: Ein Kompositionszustand kann maximal einen Anfangszustand besitzen.
• Zustand-2: Ein Kompositionszustand kann maximal einen flachen oder tiefen Erinnerungszustand besitzen.
• Transition-2: Ein Anfangszustand kann maximal eine ausgehende Transition besitzen.
• Transition-3: Ein Anfangszustand kann keine eingehende Transition besitzen.
• Transition-4: Ein Endzustand kann keine ausgehende Transition besitzen.
• Transition-5: Ein Erinnerungszustand kann maximal eine ausgehende Transition
besitzen.
• Transition-6: Transitionen, die von Pseudozuständen (z.B. Anfangs- und Erinnerungszuständen, siehe Abschnitt 3.2.3) ausgehen, dürfen keine Ereignistrigger besitzen. Ausnahme: Die ausgehende Transition des Anfangszustands des Top-LevelZustands.
• Transition-7: Die ausgehende Transition des Anfangszustands des Top-Level-Zustands kann einen Ereignistrigger mit dem Stereotyp «create» besitzen. Falls der
Zustandsautomat ein Verhaltensmerkmal spezifiziert, kann diese Transition ein Aufruf-Ereignis besitzen.
189
• Transition-8: Der Folgezustand eines Erinnerungszustands sollte sich im gleichen
Kompositionszustand befinden6 .
In Rose gehört ein Zustandsdiagramm immer zu genau einer Klasse. Top-LevelZustände können in Rose nicht explizit modelliert werden und werden auch nicht angezeigt. In Rose ist der Top-Level-Zustand der Zustandsautomat (Rose-Metaklasse Statemachine) selbst. In Rose kann ein Kompositionszustand nur einen Anfangszustand enthalten, der keine eingehenden Transitionen besitzen kann. Die Modellierung von einem
Endzustand ausgehender Transitionen ist ebenfalls nicht möglich. Bei der Spezifikation
von Transitionen wird in Rose nicht weiter zwischen Zuständen und Pseudozuständen unterschieden: Eine Transition kann immer einen Ereignistrigger, eine Bedingung und eine
Aktion besitzen, und Ausgangs- und Folgezustände können sich in beliebigen Ebenen des
Zustandsautomaten befinden.
Ein nebenläufiger Kompositionszustand kann zwei oder mehrere Kompositionszustände, genannt Bereiche oder Regionen, besitzen (siehe Abb. 4.62). Diese Bereiche sind
wieder Kompositionszustände. Zustandsautomaten mit nebenläufigen Bereichen
könnenEvents
3.77
mit Rose nicht modelliert werden. Diese gilt auch für die weiteren in diesem Abschnitt
vorgestellten Arten von Zustandsautomaten.
Taking Class
Incomplete
Lab1
lab done
Lab2
lab
done
Passed
Term
Project
project done
Final
Test
pass
fail
Failed
Figure 3-63 Concurrent
Substates
Abbildung 4.62: Nebenläufiger
Kompositionszustand
(Incomplete) mit drei Bereichen.
(Entnommen aus [OMG99], Seite 3-135)
3.76.4 Mapping
6 Nicht
explizit in [OMG99] gefordert.
A state symbol maps into a S tate. I f the sy mbol h as no sub diagrams in it, it m aps into a
Sim pleState. If it is tiled by dashed lines in to regio ns, then it maps into a CompositeState with
the isConcurrent value true; otherwise, it maps into a CompositeState with the isConcurrent
value false.
An initial p seudostate symbol map into a Pseudostate of kind initial. A final state s ymbol maps
to a final state.
3.77 Events
190
Für nebenläufige Kompositionszustände sind in [OMG99], Seite 2-135 ff, die folgenden Konsistenzbedingungen definiert:
• Zustand-3: Ein nebenläufiger Kompositionszustand muß mindestens zwei Kompositionszustände (Bereiche) besitzen.
• Zustand-4: Ein nebenläufiger Kompositionszustand kann nur Kompositionszustände als direkte Unterzustände enthalten.
3 UML
Notation
Mehrere Transitionen in nebenläufige Bereiche hinein oder aus ihnen heraus, können
mit den Pseudozuständen fork und join modelliert werden (Abb. 4.63). Diese Transitionen
werdenExample
auch nebenläufige (concurrent) Transitionen genannt.
3.79.3
Process
A1
A2
Setup
Cleanup
B1
B2
Abbildung 4.63: Die senkrechten Balken werden auf die Pseudozustände fork und join
Figure 3-65 Concurrent
Transitions
abgebildet.
Sie dienen
der Synchronisation von nebenläufigen Bereichen. Die von einem Synchronisationsbalken ausgehenden Transitionen
3.79.4 Mapping
werden erst gefeuert, wenn alle eingehenden Transitionen ausgeführt
wurden. (Entnommen aus [OMG99], Seite 3-140)
A bar with multiple transition arrows leaving it maps into a fork pseudostate. A bar with
multiple transitio n arrows enter ing it m aps in to a jo in p seudostate. T he transitions
Für diese Pseudozustände
sind
weitere
correspondingund
to thnebenläufigen
e incoming and Transitionen
outgoing arrows
attach
to th eKonsistenzbepseudostate as if it were a
dingungen definiertregular
([OMG99],
2-136
ff): incoming and multiple outgoing arrows, then it maps into a
state. If Seite
a bar has
multiple
join conn ected to a fork p seudostate by a sing le transition with n o attac hments.
• Zustand-5: Ein fork-Pseudozustand muß mindestens zwei ausgehende und genau
eine eingehende Transition besitzen.
3.80 Transitions to and from Composite States
• Zustand-6: Ein join-Pseudozustand muß mindestens zwei eingehende und genau
eine Semantics
ausgehende Transition besitzen.
3.80.1
• Transition-9:
Eine vondrawn
einem
ausgehende
kei- n to its initial
A transition
to fork-Pseudozustand
the boundary of a composite
state is e Transition
quivalent to darf
a transitio
nen Ereignistrigger
keine
Bedingung
point (orund
to a co
mplex
transition toenthalten.
the initial p oint of each of its co ncurrent regions, if it is
concurrent). The e ntry action is always p erformed when a state is en tered from outside.
• Transition-10: Eine in einem join-Pseudozustand eingehende Transition darf keiA transition from a composite state indicates a transition that applies to each of the states within
nen Ereignistrigger
und keine Bedingung enthalten.
the state region (at any depth). It is “inherited” by the nested states. Inherited transitions can be
m
asked
y the presence of nested
transitio
ns with
the sam e trigger. eingehenTransition-11:
DerbAusgangszustand
einer
in einen
join-Pseudozustand
•
den Transition darf kein Pseudozustand sein.
3.80.2 Notation
A transition drawn to a composite state boundary indicates a transition to the composite state.
This is equivalent to a tra nsition to th e initial ps eudostate within the composite state r egion.
The initial p seudostate m ust b e present. If the state is a c oncurrent com posite state, then th e
transition ind icates a transitio n to the initial p seudostate of eac h of its con current sub states.
Transitions may be d rawn d irectly to states within a composite state regio n at any nestin g
dep th. All e ntry actions are perf ormed for any state s that ar e entered o n any transition. On a
transition within a concurrent com posite state, transitio n arrows from the synchronization bar
3.83 Synch States
191
3.83 Synch States
• Transition-12: Der Folgezustand eines fork-Pseudozustands darf kein Pseudozustand Semantics
sein.
3.83.1
A synch
is for synchronizing einer
concurrent
regionsjoin-Pseudozustand
of a state machine. It is used
in
• Transition-13:
Derstate
Ausgangszustand
in einen
eingehenconjunction with f orks and joins to insur e that on e region leaves a p articular state o r states
den Transition
muß ein Unterzustand eines nebenläufigen Kompositionszustands
before another region can enter a particular state o r states. T he firing of outgoing tran sitions
sein, d.h. es from
mußa synch
ein Zustand
Bereichs
sein.a bound on the difference between the number
state can beines
e limited
by specifying
of times o utgoing and in coming transitio ns have fir ed.
• Transition-14: Die Folgezustände eines fork-Pseudozustands müssen Unterzustände eines
nebenläufigen Kompositionszustands sein.
Notation
3.83.2
Nebenläufige Bereiche
eines Kompositionszustands können mit SynchronisationsA synch sta te is sh own as a small c ircle with the upper bound inside it. The bound is e ither a
pseudozuständen synchronisiert
Das
Feuern
star ( ’*’) for un
limited.
Sy nchausgehender
states are drawn oTransitionen
n the b oundary beines
etween
positive in teger or awerden.
o
regions
when
possible.
tw
Synchronisationszustands kann durch die Angabe einer Grenze beschränkt werden. Die
Grenze ist die Differenz zwischen der Häufigkeit des Feuerns ein- und ausgehender Tran3.83.3desExample
sitionen
Synchronisationszustands (siehe Abb. 4.64). Für Synchronisationszustände
Build House
Build
Frame
Put On
Roof
Install
Walls
Install
Foundation
Inspect
*
Install
Electricity
In Foundation
*
Install
Electricity
In Frame
Install
Electricity
Outside
Abbildung 4.64: Synchronisation
von nebenläufigen Bereichen eines SynchronisationsFigure 3-71 Synch states
zustands mit Synchronisationszuständen (*). Der Stern kennzeichnet
den Wert unlimited für die Grenze des Synchronisationszustands. (Entnommen aus [OMG99], Seite 3-147)
sind zwei Konsistenzbedingungen zu beachten ([OMG99], Seite 2-137):
• Zustand-7: Der Wert der Grenze eines Synchronisationszustands muß ein positiver
Integer oder unlimited sein.
UML V1.3 beta R5
May 1999
3-147
• Transition-15: Alle eingehenden Transitionen in einen Synchronisationszustand
müssen aus einem einzigen Bereich kommen, alle ausgehenden Transitionen müssen ihr Ziel in einem einzigen Bereich haben.
192
Die Darstellung des Inhalts verschachtelter Kompositionszustände kann unterdrückt
3 UMLwerden.
Notation
Transitionen in solche Zustände hinein können mit Stummel-Pseudozuständen
dargestellt werden (siehe Abb. 4.65). Für Stummelzustände sind in [OMG99] keine
Konsistenzbedingungen formuliert.
W
p
s
s
E
A
C
u
r
F
t
B
D
may be abstracted as
p
s
W
C
A
r
B
D
Stubbed
Transitions
AbbildungFigure
4.65:3-66
Details
innerhalb
von Kompositionszuständen können unterdrückt werden. Transitionen in Zustände hinein und aus Zuständen heraus werden mit Hilfe von Stummelzuständen dargestellt. (Entnommen aus
[OMG99], Seite 3-142)
Mit junction-Pseudozuständen können komplexe
Transitionspfade modelliert werden
interrupt
A1
A
C
(Abb. 4.66).
Sie können mehrere eingehende und ausgehende Transitionen
besitzen, mit
denen eine statisch bedingte Verzweigung modelliert werden kann.
Mit choice-Pseudozuständen können dynamisch bedingte
resume Verzweigungen modelliert
werden. In Abb. 4.67 wird der Wert von
a zur (gedachten) Laufzeit des Automaten
H
bestimmt.
A2
Für junction- und choice-Pseudozustände sind in [OMG99] weitere Konsistenzbedingungen definiert:
• Zustand-7: Junction- und choice-Pseudozustände müßen mindestens eine eingehende und eine ausgehende Transition besitzen ([OMG99], Seite 2-136).
Figure 3-67Nur
History
• Zustand-8:
eine Indicator
Transition von einem junction- oder choice-Pseudozustand
ausgehende Transition darf die vordefinierte Bedingung else besitzen ([OMG99],
Seite 2-130).
3.80.5 Mapping
An arrow to any state bo undary, nested or no t, maps into a Transition between the
corresponding States and similarly for tr ansitions direct ly to h istory state s.
A history indicator maps into a Pseudostate of kind shallowHistory or deepHistory.
3-142
UML V1.3 beta R5
May 1999
3 UML Notation
3 UML Notation
3.81.3 Examples
3.81.3 Examples
In Figu re 3-68 a sin gle ju nction point is u sed to merge and split tra nsitions. Reg ardless of
whether
the jun ction
was rea ched from state S tate0 or fromUND
state SKONSISTENZ
tate1, the o utgoing
KAPITEL
4. point
WERKZEUGUNTERSTÜTZUNG
In Figu re
3-68 a sin gle
ju
nction point is u sed to merge and split tra
nsitions. Reg ardless of
paths ar e the same f or both ca ses.
whether the jun ction point was rea ched from state S tate0 or from state S tate1, the o utgoing
e themachine
same f orinboth
ses. is in state State1 and b is less than 0 when event e1 occurs,
paths
If thearstate
this ca
example
193
the outgoing transition will be taken only if on e of the three downstream guards is true. Thus,
If the state machine in this example is in state State1 and b is less than 0 when event e1 occurs,
if a is eq ual to 6 at that po int, no transition will be trigg ered.
the outgoing transition will be taken only if on e of the three downstream guards is true. Thus,
if a is eq ual to 6 at that po int, no transition will be trigg ered.
State0
State1
State0
e2[b
< 0]
State1
e1[b < 0]
e2[b < 0]
e1[b < 0]
[a > 7]
[a < 0]
[a > 7]
[a = 5]
[a < 0]
State2
[a = 5]
State3
State4
State2
State3
State4
Abbildung
4.66:
(Entnommen aus [OMG99], Seite 3-144)
Figure
3-68Junction-Pseudozustand
Junction points
Figure 3-68
Junction points
In the dynamic choice point example in Figure 3-69, the decision on which branch to take is
only made after the transition from State1 is taken and the choice point is reached. Note that the
In the dynamic choice point example in Figure 3-69, the decision on which branch to take is
action associated with that incoming transition computes a new value for a. This new value c an
only made after the transition from State1 is taken and the choice point is reached. Note that the
then be us ed to d etermine the o utgoing transition to b e taken. The us e of the predef ined
action associated with that incoming transition computes a new value for a. This new value c an
con dition[else] is rec ommended to avoid run-time errors.
then be us ed to d etermine the o utgoing transition to b e taken. The us e of the predef ined
con dition[else] is rec ommended to avoid run-time errors.
State1
State1e1[b < 0]/a := f(m)
e1[b < 0]/a := f(m)
[else]
[a < 0]
[else]
[a = 5]
[a < 0]
State2
[a = 5]
State3
State2
Figure 3-69
State4
State3
State4
Dynamic choice points
Figure 3-69 Dynamic choice points
Abbildung
4.67: Choice-Pseudozustand (Entnommen aus [OMG99], Seite 3-144)
3-144
3-144
UML V1.3 beta R5
UML V1.3 beta R5
May 1999
May 1999
ZUSTANDSDIAGRAMME
34.7. UML
Notation
194
Ein Zustandsautomat kann Transitionen zu anderen, irgendwo spezifizierten Zustands3.82.3 Example
automaten besitzen. Dieser wird referenzierter Zustandsautomat genannt. Die ZustänThe following diagramwerden
shows a fragment
from a statech artdargestellt
diagram in (siehe
which a submachine (the
de des referenzierten Zustandsautomaten
als Stummelzustände
FailureSubmachine)
is
invoked
in
a
particular
way.
The
actual
submachine
Abb. 4.68) und auf die Metamodellklasse SubmachineState (Unterautomatenzustand)is presumably
defined elsewhere and is no t sho wn in this diagram . Note th at the sam e submachine could be
abgebildet.
invoked elsewh ere in th e same statec hart diagram with different entry and exit con figurations.
Handle Failure
include / FailureSubmachine
error1/
sub1
error3/
error2/
sub1::sub12
subEnd
fixed1/
Figure 3-70
Submachine State
Abbildung 4.68: Der Unterautomatenzustand Handle Failure enthält den ZustandsautomatenInFailureSubmachine.
aus [OMG99],
Seitewill
3-146)
the above example, the(Entnommen
transition triggered
by event “error1”
terminate on state “sub1”
of the Failur eSubmachine state m achine. Since th e entry point d oes not contain a path name,
Für referenzierte Zustandsautomaten
weitere
definiert
is defined
at the Konsistenzbedingungen
to p level o f that su bmachine.
In con trast, the tra nsition
this means th at “sub1” sind
triggered b y “error2” will ter minate on the “su b12” substate of the “su b1”substate (as indicated
([OMG99], Seite 2-137):
by the path nam e), while the “er ror3” transitio n im plies tak ing of the default tra nsition of th e
FailureSub machine.
• Unterautomatenzustand-1:
Ein Unterautomatenzustand (nicht der referenzierte
Zustandsautomat!)
nur Stummelzustände
triggered by the evenenthalten.
t “fixed1” em anates f rom the “su bEnd” sub state of the
The darf
tr ansition
submachine. Finally, the transition emanating from the edge of the submachine state is taken as
• Unterautomatenzustand-2:
Ein Unterautomatenzustand darf kein nebenläufiger
a result o f the completion event g enerated when th e Failu reSubmachine reaches its final state.
Kompositionszustand sein.
3.82.4 Mapping
3-146
A submachine state in a statech art d iagram maps directly to a Su bmachineState in th e
metamodel. The name following the “include” reserved action label represents the state
machine indicated by the “submachine” attribute. Stub states map to the Stub State concept in
the metamodel. The lab el on the diagram corresponds to th e pathn ame repre sented b y the
“referenceState” attribute of the stub state.
UML V1.3 beta R5
May 1999
Kapitel 5
Konzept einer Benutzerschnittstelle zur
Konsistenzprüfung in Rational Rose 98
Rational Rose läßt sich mit Hilfe von Rose-Script um Konsistenzprüfungen erweitern.
Wie der Name andeutet, können mit Rose-Script Skripte erstellt werden. Diese Skripte
müssen auf Benutzeranforderung gestartet werden. Sie können eine graphische Benutzerschnittstelle enthalten, so daß der Benutzer den Ablauf der Skripte steuern kann.
Die Skripte können nicht ereignisgesteuert gestartet werden, so daß keine Mechanismen, mit denen Inkonsistenzen vermieden werden können oder Mechanismen, die der
Unterstützung zum Modellierungszeitpunkt dienen, realisiert werden können. Ein Skript
muß immer beendet werden, d.h. es ist nicht möglich ein Skript anzuhalten, dann Veränderungen am Modell vorzunehmen und danach das Skript fortzusetzen.
In Abschnitt 5.1 werden die in Rose-Script zur Verfügung stehenden Möglichkeiten
zur Überprüfung von Konsistenzbedingungen und zur Realisierung einer graphischen Benutzerschnittstelle kurz vorgestellt. In Abschnitt 5.2 wird erläutert, nach welchen Kriterien Konsistenzbedingungen strukturiert werden können.
5.1
Möglichkeiten von Rose-Script
Mit Rose-Script kann auf (fast) alle Informationen, die der Modellierer in Rose spezifiziert, zugegriffen werden. Diese Informationen sind in den Objekten der Klassen des
Werkzeugmetamodells von Rose (Abschnitt 4.4) vorhanden. Die Möglichkeiten von
Rose-Script beschränken sich nicht auf die reine Ermittlung gewünschter Informationen.
Objekte (Modellelemente) können in dem Umfang erzeugt, gelöscht und verändert werden, wie es auch ein Modellierer in Rose könnte. Daher können neben der reinen Prüfung
auch Korrekturen am UML-Modell vorgenommen werden. Das Rose-Metamodell kann
allerdings nicht erweitert werden.
Ein lauffähiges Skript besteht aus einer ausgezeichneten Unterroutine (main). Ein
Skript kann weitere, benutzerdefinierte Unterroutinen und Funktionen beinhalten, an die
195
5.1. MÖGLICHKEITEN VON ROSE-SCRIPT
196
Argumente per Call-By-Reference oder Call-By-Value übergeben werden können. Skripte
können andere lauffähige Skripte starten und andere Skripte, die nicht notwendigerweise
eine main-Routine besitzen müssen, in den Speicher laden und den enthaltenen Code
benutzen.
In Rose können u.a. die folgenden Datentypen zur Deklaration von Variablen benutzt
werden:
• Any : beliebiger, nicht näher spezifizierter Datentyp,
• Date : Datum und Uhrzeit,
• Variant : Datentyp, der verschiedene Datentypen enthalten kann,
• die Standarddatentypen Boolean, Double, Single, Integer und String,
• die Klassen des Rose-Metamodells (z.B. Class, RoseItem),
• Sammlungen (Collections), die mehrere Objekte einer Rose-Metamodellklasse enthalten (z.B. ClassCollection, RoseItemCollection) und
• Arrays mit statischer oder dynamischer Größe.
Benutzerdefinierte Datentypen können nur in Form von statischen Arrays deklariert
werden. Es ist nicht möglich, neue Klassen mit Attributen und Operationen zu definieren.
Routinen, Funktionen und Variablen können als Public, Private oder Global deklariert
werden. Die „üblichen“ Operatoren (>, <, =, and, or, +, −, usw.) und Kontrollstrukturen
(If-Then-Else, For . . . Next, Do . . . Loop, while) sind vorhanden.
Es stehen Funktionen zur Verfügung, mit denen das Betriebssystem des Rechners
und betriebssystemabhängige Eigenschaften ermittelt werden können. Dies ist wichtig,
da nicht alle Möglichkeiten von Rose-Script auf jeder Plattform verfügbar sind. Dies
betrifft insbesondere die Möglichkeiten der graphischen Benutzerschnittstelle, die nur auf
Windows32-Plattformen vollständig genutzt werden können.
Die graphische Benutzerschnittstelle in Form eines Dialogs kann die folgenden Elemente enthalten (alle Plattformen, kein Vollständigkeitsanspruch):
• verschiedene Push-Buttons (OK, Cancel und benutzerdefinierte Buttons)
• Radio-Buttons zur Selektion einer Option aus mehreren, statisch vorgebenen Möglichkeiten
• Drop-Down-Listen und Listen zur Selektion einer Option aus mehreren Möglichkeiten, die zur Laufzeit durch den Inhalt eines Arrays bestimmt werden
• Check-Boxen, mit denen jeweils eine Option aktiviert/deaktiviert werden kann.
197
KAPITEL 5. BENUTZERSCHNITTSTELLE ZUR KONSISTENZPRÜFUNG
Ein Dialog wird als Vorlage definiert, die die Struktur des Dialogs beschreibt. Ein
Dialog kann eine Dialogfunktion besitzen, deren Parameter allerdings fest vorgegeben
sind. Die Dialogfunktion wird ausgeführt, wenn der Benutzer z.B. eine Check-Box aktiviert oder einen Radio-Button selektiert. Auf diese Weise kann der Dialoginhalt in einem geringen Umfang dynamisch verändert werden. Die Dialogfunktion wird vorrangig
dazu genutzt, Dialogelemente in Abhängigkeit von anderen Dialogelementen zu aktivieren/deaktiveren oder zu verstecken bzw. sichtbar zu machen. Werden Arrays, die den Inhalt für Drop-Down-Listen liefern, durch die Dialogfunktion verändert, so hat dies keinen
Einfluß auf den Dialog. Die Veränderung wird erst sichtbar, wenn der Dialog nochmals
geöffnet wird. Es ist leider nicht möglich, benutzerdefinierte Dialoge zu verschachteln.
5.2
Strukturierung der Konsistenzprüfungen
Eine Überprüfung aller Konsistenzbedingungen aller Modellelemente eines UML-Modells
einer realen Systementwicklung ist zeitaufwendig und führt, besonders in einem frühen
Entwicklungsstadium, meistens zu vielen Inkonsistenzmeldungen, die den Modellierer
nicht interessieren. Die interessante Information verschwindet in der Masse. Daher muß
dem Benutzer die Möglichkeit gegeben werden, nur die für ihn zu einem bestimmten
Zeitpunkt interessanten Konsistenzprüfungen durchführen zu lassen.
Betrachtet man den Entwicklungszeitraum, von der Konzeption bis zur Implementierung, so gibt es Konsistenzbedingungen, deren Überprüfung erst zu einem späteren Entwicklungszeitpunkt interessant werden. Die Konsistenzbedingungen lassen sich abhängig
vom Entwicklungszeitpunkt grob in zwei Arten einteilen:
1. Konsistenzbedingungen, die nie verletzt werden sollten („grundsätzliche Fehler“).
Dies sind Konsistenzbedingungen, die nicht auf Grund einer unvollständigen Spezifikation des Modells, sondern durch eine fehlerhafte Spezifikation verletzt werden.
2. Konsistenzbedingungen, die auf Grund einer unvollständigen Spezifikation verletzt
werden. Ob die Überprüfung dieser Konsistenzbedingungen für den Modellierer interessante Informationen liefern kann, hängt vom Entwicklungszeitpunkt und vom
gewünschten formalen Spezifikationsgrad ab.
Die meisten Konsistenzbedingungen lassen sich einem Modellelement und damit meistens auch einer Diagrammart zuordnen. Somit können Konsistenzbedingungen nach
Diagrammen geordnet werden.
Es gibt Konsistenzbedingungen, deren Verletzung automatisch korrigiert werden kann.
Dies sind vorrangig Konsistenzbedingungen, die die Existenz anderer Modellelemente
fordern. Das Merkmal einer vorhandenen bzw. nicht vorhandenen Korrekturmöglichkeit
ist ein weiteres Unterscheidungsmerkmal.
Da es nicht immer gewünscht ist das ganze Modell auf die Einhaltung von Konsistenzbedingungen zu prüfen, sollte es möglich sein, nur bestimmte Bereiche des Modells
zu überprüfen.
5.3. KONZEPT DER BENUTZERSCHNITTSTELLE
5.3
198
Konzept der Benutzerschnittstelle
Die obigen Überlegungen führten zu dem folgenden Konzept, welches auch umgesetzt
wurde (siehe Abb. 5.1):
1. Die Auswahl der Konsistenzprüfungen erfolgt diagrammorientiert. Dazu wird über
die Menüleiste eine Diagrammart ausgewählt.
2. Die Konsistenzprüfungen werden nach dem Entwicklungszeitpunkt (siehe Abschnitt
5.2) geordnet.
Wenn zuviele Konsistenzprüfungen im Kontext eines Diagramms existieren, werden diese auf mehrere Auswahldialoge verteilt.
3. Der Umfang der zu überprüfenden Modellelemente kann nach verschiedenen Kriterien gewählt werden:
(a) Paketorientiert: Es kann das gesamte Modell oder ein bestimmtes Paket inklusive aller enthaltenen Pakete zur Überprüfung gewählt werden.
(b) Diagrammorientiert: Entsprechend der ausgewählten Diagrammart können
entweder alle Diagramme oder nur ein bestimmtes Diagramm dieser Art ausgewählt werden.
(c) Benutzerorientiert: Sind vom Benutzer vor dem Öffnen des Auswahldialogs
Modellelemente selektiert worden, können entweder alle selektierten Modellelemente oder genau eines der selektierten Modellelemente gewählt werden.
Die Überprüfung findet auf der Basis des Werkzeugmetamodells statt. Die Auswahl
bestimmt lediglich den minimalen Umfang der zu überprüfenden Modellelemente.
4. Jede Prüfung kann einzelnd ausgewählt werden.
5. Jede Prüfung kann interaktiv durchgeführt werden, d.h. wenn eine Inkonsistenz
entdeckt wird, wird dem Benutzer ein Dialog mit den folgenden Informationen angezeigt (Abb. 5.2, siehe auch 4.2.4 Konsistenzprüfung als Informationsproduzent):
(a) Die überprüfte Konsistenzbedingung.
(b) Die Modellelemente, die für die Verletzung der Konsistenzbedingung verantwortlich sind.
(c) Maßnahmen zur Behebung der Inkonsistenz werden vorgeschlagen.
Dem Benutzer stehen nun mehrere Möglichkeiten zur Verfügung:
(a) In der Drop-Down-Liste „Modellelemente“ sind die Modellelemente vorhanden, die für die Inkonsistenz vorantwortlich sind. Die Auswahl eines dieser
199
Abbildung 5.1: Auswahldialog der Konsistenzprüfungen („grundsätzliche Fehler“) in
Klassendiagrammen
5.3. KONZEPT DER BENUTZERSCHNITTSTELLE
Abbildung 5.2: Inkonsistenzdialog
200
201
Modellelemente zeigt (unter dem Dialog) ein Diagramm an, in dem das Modellelement vorkommt. Auf diese Weise kann sich der Modellierer ein „Bild
von der Inkonsistenz verschaffen“.
(b) Der Button „Spezifikation öffnen“ beendet die Konsistenzprüfung und öffnet
das Spezifikationsfenster des in der Drop-Down-Liste angegebenen Elements.
(c) Handelt es sich um eine Konsistenzprüfung, deren Verletzung automatisch
korrigiert werden kann, wird ein Button „Autokorrektur“ und ein Text angezeigt. Der Text beschreibt die Funktion der Autokorrektur.
(d) Der Button „Weiter mit Einzelschritt“ setzt die Prüfung interaktiv fort.
(e) Der Button „Weiter ohne Einzelschritt“ setzt die Prüfung ohne Interaktionsmöglichkeit fort.
(f) Der Button „Abbruch“ bricht die Überprüfungen ab.
6. Die Prüfungsmeldungen werden in die Standardausgabe (Unix) oder in ein spezielles Fenster (Windows) geschrieben. Bei nicht interaktiver Prüfung wird eine
automatische Korrektur nur durchgeführt, wenn im Dialog die Autokorrektur ausgewählt wurde.
Anhang A
Realisierung der Benutzerschnittstelle
Die Benutzerschnittstelle ist durch mehrere Skripte realisiert: Jeder Auswahldialog und
jede Konsistenzprüfung befindet sich in einem eigenen Skript. Verschiedene Hilfsfunktionen (Seite 203) sind ebenfalls in einzelne Skripte ausgelagert.
Der Aufbau der Skripte wird in den beiden nächsten Abschnitten kurz erläutert. Die
restlichen Abschnitte geben eine Übersicht über die entwickelten Skripte und beschreiben
die Installation der Skripte.
A.1
Das Skript einer Konsistenzprüfung
Ein Skript, welches eine Konsistenzprüfung realisiert, besteht aus mehreren Teilen:
1. Dialogvorlage: Die Dialogvorlage für den Inkonsistenzdialog (Abb. 5.2, Seite 200)
ist zwar allgemein verwendbar, muß aber leider aus technischen Gründen in jedem
Skript vorhanden sein. Die Dialogvorlage besitzt mehrere Variablen, die von der
Routine, die die Konsistenzprüfung realisiert, gesetzt werden sollten:
(a) PrüfungText (String): beschreibt die durchgeführte Prüfung.
(b) MaßnahmenText (String): beschreibt mögliche Maßnahmen zur Beseitigung
der Inkonsistenz.
(c) AutokorrekturMöglich (Boolean): gibt an, ob der Button zur Autokorrektur
inklusive Beschreibung im Dialog sichtbar sein soll.
(d) AutokorrekturText (String): beschreibt die von der Autokorrektur durchgeführte Änderung.
(e) VerursacherNamen (String, Array): enthält die Namen der Modellelemente,
deren Diagramme angezeigt werden können.
(f) VerursacherObjekte (RoseItem, Array): gehört streng genommen nicht zur
Dialogvorlage, enthält die Objekte (Modellelemente), deren Diagramme angezeigt werden können.
202
203
ANHANG A. REALISIERUNG DER BENUTZERSCHNITTSTELLE
(g) InkonsistenzText (String): wird zur Ausgabe eines Textes, der die Inkonsistenz und die beteiligten Modellelemente beinhaltet, genutzt.
2. Dialogfunktion: Die Dialogfunktion ruft u.a. eine Routine auf, die ein Diagramm
anzeigt, in welchem das im Inkonsistenzdialog ausgewählte Modellelement vorhanden ist. Realisiert ist lediglich eine Routine, die ein Klassendiagramm anzeigt.
Für Konsistenzprüfungen im Kontext anderer Diagrammarten müßte diese Routine
entsprechend angepaßt werden.
3. Prüfungsroutine: Der erste Parameter einer Prüfungroutine ist immer von einem
Typ der Art Collection (z.B. ClassCollection oder AssociationCollection).
Dies ist die Sammlung von Modellelementen, die iterativ von der Prüfungsroutine
bearbeitet werden.
Weitere Parameter sind Einzel und Abbruch (beide Boolean, Call-By-Reference)
und, falls die Prüfung eine automatische Korrektur beinhaltet, Auto (Boolean). Die
Prüfungsroutine kann auch Unterroutinen beinhalten.
A.2
Das Skript eines Auswahldialogs
Das Skript eines Auswahldialogs besteht neben der Dialogvorlage und der Dialogfunktion
aus mehreren Routinen, die auf Basis der ausgewählten Modellelemente und Konsistenzprüfungen eine Sammlungen (Collection) entsprechend der Parameter der Prüfungsroutinen erzeugen (z.B. CreateClassCollection, CreateAssociationCollection).
Die Prüfungsroutinen werden dynamisch zur Laufzeit in den Speicher geladen und
auch wieder aus dem Speicher entfernt, da das Laden mehrerer Skripe zu einem Zeitpunkt
zu einer spürbar längeren Antwortzeit führt.
A.3
Entwickelte Skripte
A.3.1 Hilfsfunktionen
Function HasAttributeType
(anAttribute As Attribute) As Variant
Aufgabe: liefert True, falls anAttribute einen Typ (Type) besitzt
Datei: Function_HasAttributeType.ebs
Function HasSameSignatur
(op1 As Operation, op2 As Operation) As Variant
Aufgabe: liefert True, falls die beiden Operationen die gleiche Signatur besitzten
Datei: Function_HasSameSignature.ebs
A.3. ENTWICKELTE SKRIPTE
204
Function ExistsOperationSignatureInClass
(theClass As Class, theOperation As Operation) As Variant
Aufgabe: Überprüft, ob die Signatur der Operation in der Klasse existiert
Datei: Function_ExistsOperationSignatureInClass.ebs
Function ExistsOperationSignatureInSuperclasses
(theClass As Class, theOperation As Operation) As Variant
Aufgabe: Überprüft, ob die Signatur der Operation in einer Oberklasse der Klasse existiert.
Datei: Function_ExistsOperationSignaturInSuperclasses.ebs
Function IsAssociationNavigable
(anAssociation As Association) As Variant
Aufgabe: liefert True, falls ein Assoziationsende navigierbar ist.
Datei: Function_IsAssociationNavigable.ebs
Function IsInterface (theClass As Class) As Variant
Aufgabe: liefert True, falls die Klasse das Stereotyp «Interface» besitzt.
Datei: Function_IsInterface.ebs
A.3.2
Konsistenzprüfungen
Sub KP_CheckAttrPAttr (Classes As ClassCollection,
Einzel As Boolean, Abbruch As Boolean)
Aufgabe: Überprüft, ob die Attribute und Pseudoattribute der Klassen eindeutig sind
(Attribut-5).
Datei: Sub_KP_CheckAttrPAttr.ebs
Sub KP_UniqueOpSignatures (Classes As ClassCollection,
Aufgabe: Überprüft, ob die Operationssignaturen der Klassen eindeutig sind (Operation1).
Datei: Sub_KP_UniqueOpSignatures.ebs
Sub KP_UniqueParaNames (Classes As ClassCollection,
Aufgabe: Überprüft, ob die Parametername der Operationen der Klassen eindeutig sind
(Operation-2).
Datei: Sub_KP_UniqueParaNames.ebs
Sub KP_CheckCompositionCardinality (Associations As AssociationCollection,
205
Aufgabe: Überprüft, ob die Assoziationsenden, die eine Komposition kennzeichnen, eine
maximale Kardinalität von 1 besitzen (Komposition-1).
Datei: Sub_KP_CheckCompositionCardinality.ebs
Sub KP_CheckGeneralization (Generalizations As InheritRelationCollection,
Aufgabe: Überprüft, ob die Generalisierungsbeziehungen zwischen Klassifizierern der
gleichen Art spezifiziert sind (Generalisierung-4).
Datei: Sub_KP_CheckGeneralization.ebs
Sub KP_InterfaceOperationsOnly (Classes As ClassCollection,
Einzel As Boolean, Auto As Boolean, Abbruch As Boolean)
Aufgabe: Überprüft, ob die Klassen mit dem Stereotyp «Interface» nur Attribute als
Merkmale besitzen (Interface-1).
Datei: Sub_KP_InterfaceOperationsOnly.ebs
Sub KP_InterfaceNoContents (Classes As ClassCollection,
Aufgabe: Überprüft, ob die Klassen mit dem Stereotyp «Interface» Klassen beinhalten
(Interface-2).
Datei: Sub_KP_InterfaceNoContents.ebs
Sub KP_InterfaceAssoziation (Classes As ClassCollection,
Aufgabe: Überprüft, ob die Klassen mit dem Stereotyp «Interface» ein gegenüberliegendes, navigierbares Assoziationsende besitzen (Interface-7).
Datei: Sub_KP_InterfaceAssoziation.ebs
Sub KP_InterfaceHasOperation (Classes As ClassCollection,
Aufgabe: Überprüft, ob die Klassen mit dem Stereotyp «Interface» Operationen deklarieren (Interface-5).
Datei: Sub_KP_InterfaceHasOperation.ebs
Sub KP_InterfaceHierarchie (Classes As ClassCollection,
Aufgabe: Überprüft, ob die Klassen mit dem Stereotyp «Interface» eindeutige Operationssignaturen in der Klassenhierarchie besitzen (Interface-6).
Datei: Sub_KP_InterfaceHierarchie.ebs
Sub KP_InterfacePublicOperations (Classes As ClassCollection,
A.3. ENTWICKELTE SKRIPTE
206
Aufgabe: Überprüft, ob die Klassen mit dem Stereotyp «Interface» nur öffentliche, abstrakte Operationssignaturen besitzen (Interface-3, Interface-4).
Datei: Sub_KP_InterfacePublicOperations.ebs
Sub KP_InterfaceRealize (Classes As ClassCollection,
Aufgabe: Überprüft, ob die Klassen mit dem Stereotyp «Interface» etwas realisieren
(Interface-12).
Datei: Sub_KP_InterfaceRealize.ebs
Sub KP_InterfaceStatemachine (Classes As ClassCollection,
Aufgabe: Überprüft, ob die Klassen mit dem Stereotyp «Interface» einen Zustandsautomaten bzw. ein Zustandsdiagramm besitzen (Interface-10).
Datei: Sub_KP_InterfaceStatemachine.ebs
Sub KP_CheckTypeClassGeneralization (Generalizations As
InheritRelationCollection, Einzel As Boolean, Abbruch As Boolean)
Aufgabe: Überprüft, ob die Super-Klassifizierer eines Typen («type») ebenfalls Typen
sind (Typ-1).
Datei: Sub_KP_CheckTypeClassGeneralization.ebs
Sub KP_AttributeDeklariert (Classes As ClassCollection,
Aufgabe: Überprüft, ob die Attributdeklarationen der Klassen einen Typ beinhalten (Attribut2).
Datei: Sub_KP_AttributeDeklariert.ebs
Sub KP_AttributExTyp (Classes As ClassCollection,
Aufgabe: Überprüft, ob die Typen der Attribute der Klassen im Modell existieren (Attribut3).
Datei: Sub_KP_AttributExTyp.ebs
Sub KP_OpParaTypDeklariert (Classes As ClassCollection,
Aufgabe: Überprüft, ob die Typen der Parameter der Operationen der Klassen deklariert
sind.
Datei: Sub_KP_OpParaTypDeklariert.ebs
Sub KP_OpParaTypEx (Classes As ClassCollection,
207
Aufgabe: Überprüft, ob die Typen der Parameter der Operationen der Klassen im Modell
existieren (Operation-3).
Datei: Sub_KP_OpParaTypEx.ebs
Sub KP_CheckAndSetClassAbstract (Classes As ClassCollection,
Aufgabe: Überprüft, ob die Klassen abstrakte Operationen besitzen und als abstrakt spezifiziert sind (Operation-4).
Datei: Sub_KP_CheckAndSetClassAbstract.ebs
Sub KP_AssociationsNavigable (Associations As AssociationCollection,
Aufgabe: Überprüft, ob die Assoziationen in eine Richtung navigierbar sind (Assoziation2).
Datei: Sub_KP_AssociationsNavigable.ebs
Sub KP_NavRoleExName (Associations As AssociationCollection,
Aufgabe: Überprüft, ob navigierbare Assoziationsenden der Assoziationen benannt sind
(Assoziation-3).
Datei: Sub_KP_NavRoleExName.ebs
Sub KP_KonkreteKlassenUmAbstrakteOperationenErweitern
(Classes As ClassCollection, Einzel As Boolean, Auto As Boolean, Abbruch
As Boolean)
Aufgabe: Überprüft, ob Klassen abstrakte Operationen ihrer Oberklassen realisieren (als
nicht abstrakt deklarieren) (Operation-5).
Datei: Sub_KP_KonkreteKlassenUmAbstrakteOperationenErweitern.ebs
Sub KP_InterfaceAktiv (Classes As ClassCollection,
Aufgabe: Überprüft, ob Klassen mit dem Stereotyp «Interface» als aktiv spezifiziert sind
(Interface-8).
Datei: Sub_KP_InterfaceAktiv.ebs
Sub KP_RealizeInterfaceOperations (Classes As ClassCollection,
Aufgabe: Überprüft, ob Klassen alle Operationen ihrer Interfaces realisieren (deklarieren) (Operation-13).
Datei: Sub_KP_RealizeInterfaceOperations.ebs
A.4. INSTALLATION
208
Sub KP_ExistsSignalClass (Classes As ClassCollection,
Aufgabe: Überprüft, ob zu den Signal-Operationen eine entsprechende Signalklasse im
Modell existiert (Signal-1).
Datei: Sub_KP_ExistsSignalClass.ebs
Sub KP_SignalStatemachine (Classes As ClassCollection,
Aufgabe: Überprüft, ob Klassen mit Signal-Operationen einen Zustandsautomaten besitzen, der den Emfang des Signals spezifiziert (Signal-4).
Datei: Sub_KP_SignalStatemachine.ebs
Sub KP_SignalActiveClass (Classes As ClassCollection,
Aufgabe: Überprüft, ob Klassen mit Signal-Operationen als aktiv spezifiziert sind (Signal5).
Datei: Sub_KP_SignalStatemachine.ebs
A.3.3
Auswahldialoge
1. Datei: KP_Klassendiagramm1.ebs
2. Datei: KP_Klassendiagramm2.ebs
A.4
Installation
Die Installation besteht aus drei Schritten:
1. alle Skripte müssen in das Verzeichnis des Skript-Pfads ($SCRIPT_PATH) kopiert
werden.
2. Anpassung der Rose-Menü-Datei rose.mnu:
Sollen die Auswahldialoge unter dem Menüpunkt Report erreichbar sein, sind nach
den Zeilen
Menu Report
{
die folgenden Zeilen einzufügen:
option "Check Classdiagram1"
209
{
RoseScript $SCRIPT_PATH\KP_Klassendiagramm1
}
option "Check Classdiagram2"
{
RoseScript $SCRIPT_PATH\KP_Klassendiagramm2
}
Hinter option kann eine beliebige Zeichenkette (Menüeintrag) angegeben werden.
RoseScript . . . startet bei der Auswahl des Menüpunkts das angegebene Skript.
3. Rose muß gegebenenfalls neu gestartet werden.
Abbildungsverzeichnis
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
2.14
2.15
2.16
2.17
2.18
2.19
2.20
2.21
2.22
2.23
2.24
Klasse . . . . . . . . . . .
Interface (Lolli) . . . . . .
Interface . . . . . . . . . .
Kollaborationssymbol . . .
Anwendungsfall . . . . . .
aktive Klasse . . . . . . .
Komponente . . . . . . . .
Knoten . . . . . . . . . . .
Interaktion . . . . . . . . .
Zustände und Transitionen
Paket . . . . . . . . . . . .
Notiz . . . . . . . . . . .
Abhängigkeit . . . . . . .
Assoziation . . . . . . . .
Generalisierung . . . . . .
Realisierungsbeziehung . .
Anwendungsfalldiagramm
Klassendiagramm . . . . .
Objektdiagramm . . . . .
Sequenzdiagramm . . . . .
Kollaborationsdiagramm .
Zustandsdiagramm . . . .
Aktivitätsdiagramm . . . .
Zusicherung . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
15
15
16
16
17
17
17
18
19
19
20
20
21
21
22
22
24
25
26
27
27
28
29
34
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
Paketübersicht des Metamodells
Pakete des Fundaments der UML
Vererbungshierarchie . . . . . .
Link . . . . . . . . . . . . . . .
Backbone . . . . . . . . . . . .
Element . . . . . . . . . . . . .
Namensraum . . . . . . . . . .
Zusicherung . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
36
37
39
42
44
45
46
47
210
211
ABBILDUNGSVERZEICHNIS
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
3.17
3.18
3.19
3.20
3.21
3.22
3.23
3.24
3.25
3.26
3.27
3.28
3.29
3.30
3.31
3.32
3.33
3.34
3.35
3.36
3.37
3.38
3.39
3.40
3.41
3.42
3.43
3.44
3.45
3.46
3.47
3.48
3.49
3.50
verallgemeinerbares Element und Klassifizierer . .
Merkmale . . . . . . . . . . . . . . . . . . . . . .
Parameter . . . . . . . . . . . . . . . . . . . . . .
Klassifizierer . . . . . . . . . . . . . . . . . . . .
Assoziation und Kardinalität . . . . . . . . . . . .
gerichtete Assoziation . . . . . . . . . . . . . . . .
Spezifizierung von Rollen durch Interfaces . . . . .
geordnetes Assoziationsende . . . . . . . . . . . .
Komposition . . . . . . . . . . . . . . . . . . . . .
Aggregation . . . . . . . . . . . . . . . . . . . . .
qualifizierte Assoziation . . . . . . . . . . . . . .
nicht-qualifizierte Assoziation . . . . . . . . . . .
qualifizierte Assoziation . . . . . . . . . . . . . .
Assoziationsklasse . . . . . . . . . . . . . . . . .
Beziehungen . . . . . . . . . . . . . . . . . . . .
Assoziationsende . . . . . . . . . . . . . . . . . .
Ablaufbeziehung . . . . . . . . . . . . . . . . . .
Abhängigkeiten . . . . . . . . . . . . . . . . . . .
Kommentar . . . . . . . . . . . . . . . . . . . . .
Erweiterungsmechanismen . . . . . . . . . . . . .
Datentypen (1) . . . . . . . . . . . . . . . . . . .
Datentypen (2) . . . . . . . . . . . . . . . . . . .
Ausdrücke . . . . . . . . . . . . . . . . . . . . . .
Paketübersicht der Verhaltenselemente . . . . . . .
Signal, Ausnahme und Empfang . . . . . . . . . .
Aktionen . . . . . . . . . . . . . . . . . . . . . .
Sende-Aktion . . . . . . . . . . . . . . . . . . . .
Exemplare und Links . . . . . . . . . . . . . . . .
Link und Stimulus . . . . . . . . . . . . . . . . . .
Sequenzdiagramm . . . . . . . . . . . . . . . . . .
Kollaborationsdiagramm der Spezifikationsebene .
Kollaborationsdiagramm der exemplarischen Ebene
Sequenzdiagramm . . . . . . . . . . . . . . . . . .
Kollaboration . . . . . . . . . . . . . . . . . . . .
Zustandsautomat einer Klimaanlage . . . . . . . .
Metamodell der Ereignisse . . . . . . . . . . . . .
Erinnerungszustände . . . . . . . . . . . . . . . .
Zustand mit nebenläufigen Bereichen . . . . . . .
Metamodell des Zustandsautomaten . . . . . . . .
Aktivitätsdiagramm . . . . . . . . . . . . . . . . .
Aktivitätsdiagramm (Metamodell) . . . . . . . . .
Objektfluß . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
48
50
52
55
58
58
58
59
60
60
60
61
61
62
63
63
67
68
71
72
76
78
79
81
83
85
87
88
91
93
94
94
97
98
102
103
107
108
109
114
115
117
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
4.16
4.17
4.18
4.19
4.20
4.21
4.22
4.23
4.24
4.25
4.26
4.27
4.28
4.29
4.30
4.31
4.32
4.33
4.34
4.35
4.36
4.37
4.38
4.39
4.40
4.41
4.42
Konsistenz . . . . . . . . . . . . . . . . . . . .
Konsistenz: Beispiel . . . . . . . . . . . . . .
Ein hypothetisches Werkzeug . . . . . . . . . .
Rational Rose 98 . . . . . . . . . . . . . . . .
Rose Extensibility Interface (REI) . . . . . . .
Die Spitze der Klassenhierarchie von Rose . . .
Rose: Diagrammklassen . . . . . . . . . . . .
Rose: Klassendiagramm . . . . . . . . . . . .
Rose: Interaktionsdiagramm . . . . . . . . . .
Rose: Zustandsdiagramm . . . . . . . . . . . .
abstrakte Klasse . . . . . . . . . . . . . . . . .
abstrakte Klasse (Metamodellexemplar) . . . .
abstrakte Klasse (Rose-Metamodellexemplar .
Attribut . . . . . . . . . . . . . . . . . . . . .
Attribut (Metamodellexemplar) . . . . . . . . .
Attribut (Rose-Metamodellexemplar . . . . . .
Operation . . . . . . . . . . . . . . . . . . . .
Operation (Metamodellexemplar) . . . . . . . .
Operation (Rose-Metamodellexemplar . . . . .
Assoziation . . . . . . . . . . . . . . . . . . .
Assoziation (Metamodellexemplar) . . . . . . .
Assoziation (Rose-Metamodellexemplar) . . .
Komposition . . . . . . . . . . . . . . . . . . .
Assoziationsklasse, inkonsistent . . . . . . . .
Generalisierung . . . . . . . . . . . . . . . . .
Generalisierung (Metamodellexemplar) . . . .
Generalisierung (Rose-Metamodellexemplar) .
Interface . . . . . . . . . . . . . . . . . . . . .
Interface (Metamodellexemplar) . . . . . . . .
Interface (Rose-Metamodellexemplar) . . . . .
Realisierung . . . . . . . . . . . . . . . . . . .
Realisierung (Metamodellexemplar) . . . . . .
Realisierung (Rose-Metamodell) . . . . . . . .
Signal . . . . . . . . . . . . . . . . . . . . . .
Spezifizierung von Rollen durch Interfaces . . .
Typen . . . . . . . . . . . . . . . . . . . . . .
Klassifiziererrolle . . . . . . . . . . . . . . . .
„Objektrolle“ . . . . . . . . . . . . . . . . . .
Klassifiziererrolle (Metamodellexemplar 1) . .
Klassifiziererrolle (Metamodellexemplar 2) . .
Assoziationsrolle . . . . . . . . . . . . . . . .
Verwendung von Typen als Klassifiziererrollen
212
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
122
123
126
129
132
135
136
138
139
141
142
143
143
144
145
145
148
148
148
150
151
152
154
155
155
156
156
157
157
158
159
160
160
162
164
164
166
166
166
167
168
168
213
4.43
4.44
4.45
4.46
4.47
4.48
4.49
4.50
4.51
4.52
4.53
4.54
4.55
4.56
4.57
4.58
4.59
4.60
4.61
4.62
4.63
4.64
4.65
4.66
4.67
4.68
Verwendung von Typen als Rollen für Objekte . . . . . . . .
Assoziations- und Klassifiziererrollen (Metamodellexemplar)
Objekte, Links und Botschaften in Rose (Meta) . . . . . . .
Botschaften und Stimuli . . . . . . . . . . . . . . . . . . .
Botschaft im Kollaborationsdiagramm . . . . . . . . . . . .
Prozedualer Kontrollfluß . . . . . . . . . . . . . . . . . . .
Reihenfolge der Botschaften/Stimuli . . . . . . . . . . . . .
Iteration im Kollaborationsdiagramm . . . . . . . . . . . . .
Interaktion im Sequenzdiagramm . . . . . . . . . . . . . . .
Iteration im Sequenzdiagramm (außerhalb der UML) . . . .
Ereignisse im Metamodell . . . . . . . . . . . . . . . . . .
Die Klasse Event des Rose-Metamodells . . . . . . . . . .
Transition . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transition (Metamodellexemplar) . . . . . . . . . . . . . .
Transition (Rose-Metamodell) . . . . . . . . . . . . . . . .
Zustand . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Zustand (Metamodellexemplar) . . . . . . . . . . . . . . . .
Rekursiver Aufbau eines Zustandsautomaten . . . . . . . . .
Zustandsautomat (Beispiel) . . . . . . . . . . . . . . . . . .
nebenläufiger Kompositionszustand . . . . . . . . . . . . .
Die Pseudozustände fork und join . . . . . . . . . . . . . .
Synchronisationszustand . . . . . . . . . . . . . . . . . . .
Stummelzustände . . . . . . . . . . . . . . . . . . . . . . .
Junction-Pseudozustand . . . . . . . . . . . . . . . . . . . .
Choice-Pseudozustand . . . . . . . . . . . . . . . . . . . .
Aufruf eines eingebetteten Zustandsautomaten . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
168
169
171
172
174
176
176
177
178
179
180
181
183
183
184
185
186
187
187
189
190
191
192
193
193
194
5.1
5.2
Auswahldialog: Konsistenzprüfungen . . . . . . . . . . . . . . . . . . . 199
Inkonsistenzdialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Index
Abhängigkeit, 67
Abstraktion, 68
access (Zugriff), 70
Benutzung, 69
derive, 68
friend, 70
import, 70
realize, 68
refine, 68
trace, 68
Abhangigkeit, 20
Erlaubnis, 70
Abstraktion, 67
addOnly, 51
Aktion, 84, 105
Erzeuge-, 86
Nichtinterpretierte, 87
Rückgabe-Aktion, 86
Sende-, 87
Terminiere-, 86
Zerstöre-, 86
Zuweisungs-, 86
Aktionssequenz, 86
Aktionszustand, 116
Aktivitätsdiagramm, 81
Aktivitat, 105
Aktivitatsdiagramm, 26
Anderungs-Ereignis, 104
Anmerkungen, 20
Anwendungsfall, 16
Anwendungsfalldiagramm, 23
Anwendungsfallsicht, 31, 130
association, 91
Assoziation, 57, 62
Assoziationsende, 57, 63
Assoziationsklasse, 62, 65
Attribut, 51
Aufruf
Aktion-, 86
Aufruf-Ereignis, 103
Aufrufzustand, 117
Ausnahme, 83
Automat, 19
Basisklasse, 38
Benutzung, 67
Beziehungen, 20
Bindung, 67
Botschaft, 82
changeable, 51
child, 38
classifier, 51
Codeerzeugung, 120
complete, 66
concurrency, 53
concurrent, 53
Datentyp, 56
AggregationKind, 76
Aufzählung, 76
Boolean, 76
CallConcurrencyKind, 76
ChangeableKind, 76
Integer, 75
MessageDirectionKind, 76
OperationDirectionKind, 76
OrderingKind, 76
ParameterDirectionKind, 76
214
215
primitiver, 75
Programmiersprachentyp, 77
PseudostateKind, 76
String, 75
Struktur, 76
Time, 75
UnlimitedInteger, 75
VisibilityKind, 76
Datenwert, 89
destroyed, 91
Diagramme, 23
direkte Oberklasse, 38
direktes Exemplar, 38
disjoint, 66
Beispiel, 38
Diskriminator, 38, 66
Eigenschaftswert, 34, 72
Einsatzdiagramm, 30
Einsatzsicht, 32, 130
Element, 43
Modell-, 45
Präsentations-, 45
verallgemeinerbares, 47
Empfang, 83
Entwurfssicht, 31
Ereignis, 103
verzogertes, 106
Ereignis-Trigger, 105
Erinnerungszustand
flacher, 106
Erlaubnis, 67
Erweiterung, 38, 40
Erweiterungsmeachnismus, 71
Exemplar, 87
direkt, 38
indirektes, 40
Fachlexikon, 120
frozen, 51
Generalisierung, 21, 38, 66
global, 91
INDEX
guarded, 53
Implementationssicht, 31
in, 54
incomplete, 66
indirektes Exemplar, 40
Inkonsistenzvermeidung, 125
inout, 54
instance, 51
Instantiierung, 41
Interaktion, 18
Interaktionsdiagramm, 23
Interface, 15, 43, 56
Interoperabilitat, 121
Kardinalität, 79
Kind, 38
Klasse, 15, 38, 42, 55
abstrakte, 40
aktive, 17
konkrete, 40
Ober-, 38
Sub-, 38
Super-, 38
Unter-, 38
Klassendiagramm, 23
Klassifizierer, 48
Knoten, 18, 56
Knotenexemplar, 89
Kollaboration, 16, 99
Kollaborationsdiagramm, 25, 80
Kommentar, 20
Komponente, 17, 56
Komponentendiagramm, 30
Komponentenexemplar, 89
Komponentensicht, 31, 130
Konsistenz
Definition, 124
Probleme, 124
Konsistenzprufung, 120, 127
Konsistenzunterstutzung, 127
Link, 90
INDEX
Link-Ende, 90
Linkobjekt, 90
local, 91
logische Sicht, 31, 130
Mehrbenutzerunterstutzung, 120
Merkmal, 49
überschreiben, 40
strukturelles, 51
Verhaltens-, 52
Methode, 43, 54
multiplicity, 51
Nachbedingung, 43
Nachkomme, 38
Namensraum, 46
virtueller, 45
new, 91
Notiz, 20
Oberklasse, 38
Objekt, 89
Objektdiagramm, 23
Objektfluszustand, 117
Operation, 53
Operationsaufruf, 82
out, 54
overlapping, 66
Paket, 19
Paketdiagramm, 137
Parameter, 54
parameter, 91
parent, 38
persistence, 49
Polymorphismus, 40
Prozessicht, 31
Pseudoattribut, 45, 49
Pseudozustand, 111
Qualifikationsangabe, 60
Realisierung, 22
Realisierungssicht, 31
216
return, 54
Reverse-Engineering, 120
self, 91
sequential, 53
Sequenzdiagramm, 23, 80
Sichtbarkeit
Attribut-, 42
Signal, 82
Signal-Ereignis, 103
Signatur, 40
Definition, 52
Spezialisierung, 38
Statechart, 25
statechart, 101
StateVertex, 110
Stereotyp, 33, 71
access, 70
become, 66
call, 70
copy, 66
create, 53, 70, 103
derive, 68
destroy, 53, 103
document, 57
executable, 57
file, 57
friend, 70
implementation, 66
implementationClass, 55
implicit, 62
import, 70
instantiate, 70
invariant, 47
library, 57
metaclass, 49
postcondition, 47
powertyp, 49
precondition, 47
process, 49
realize, 68
refine, 68
217
requirement, 71
responsibility, 71
send, 70
signal, 82
table, 57
thread, 49
trace, 68
type, 55
utility, 49
Stimulus, 82, 90
Subklasse, 38
Substitutionsprinzip, 40
Superklasse, 38
Synchronisationszustand, 112
targetScope, 51
transient, 91
Transition, 105
interne, 105
Trigger, 105
Typ, 54
Attribut-, 42
Unterklasse, 38
Unterzustand, 110
Vererbung, 21, 38
Verteilungsdiagramm, 30
Verteilungssicht, 32
Vorbedingung, 43
Vorfahr, 38
Wachterbedingung, 105
Werkzeug
hypothetisches, 125
Wiederverwendbarkeit, 121
Zeit-Ereignis, 104
Zusicherung, 47, 72, 74
addOnly, 63
frozen, 63
xor, 62
Zusicherungen, 34
INDEX
Zustand, 105
Unterautomaten-, 113
Zustandsautomat, 19, 101, 105
Zustandsdiagramm, 25, 80, 101
Zustandsknoten, 110
Literaturverzeichnis
[Alh98]
Sinan Si Alhir. UML in a Nutshell. A Desktop Quick Reference. O’Reilly,
1998.
[Bal92]
Helmut Balzert. Die Entwicklung von Software-Systemen: Prinzipien, Methoden, Sprachen, Werkzeuge. Reihe Informatik. BI Wissenschaftsverlag, Mannheim; Leipzig; Wien, Zürich, 1992. Das Buchprogramm des Bibliographischen Instituts ist von Spektrum Akademischer Verlag GmbH, Heidelberg,
Berlin, Oxford übernommen worden.
[Bal96]
Helmut Balzert. Lehrbuch der Software-Technik: Software-Entwicklung.
Lehrbücher der Informatik. Spektrum Akademischer Verlag, Heidelberg, Berlin, 1996.
[Bal98]
Helmut Balzert. Lehrbuch der Software-Technik: Software-Management,
Software-Qualitätssicherung, Unternehmensmodellierung. Lehrbücher der Informatik. Spektrum Akademischer Verlag, Heidelberg, Berlin, 1998.
[BRJ99a] Grady Booch, James Rumbaugh, and Ivar Jacobson.
Das UMLBenutzerhandbuch. Professionelle Softwareentwicklung. Addison Wesley,
1999.
[BRJ99b] Grady Booch, James Rumbaugh, and Ivar Jacobson. The Unified Modeling
Language User Guide. Object Technology Series. Addison Wesley, 1999.
[Cet]
Cetus Links. Architecture and Design: Unified Modeling Language (UML).
http://www.rhein-neckar.de/˜cetus/oo_uml.html. Link-Sammlung zum Thema
UML im Web.
[EP98]
Hans-Erik Eriksson and Magnus Penker. UML Toolkit. John Wiley & Sons,
Inc., 1998.
[FS98]
Martin Fowler and Kendal Scott. UML konzentriert. Addison-Wesley, 1998.
[HW98]
Paul Harmon and Mark Watson. Understanding UML: The Developers Guide.
Morgan Kaufmann Publishers, Inc., San Francisco, California, 1998.
218
219
[Oes98]
LITERATURVERZEICHNIS
Bernd Oesterreich. Objektorientierte Softwareentwicklung. Analyse und Design mit der Unified Modeling Language. R. Oldenbourg Verlag, 4. edition,
1998.
[OMG99] OMG (Object Management Group). OMG unified modeling language specification (draft). http://www.omg.org, April 1999. Version 1.3 beta R1.
[Qua98]
Terry Quatrani. Visual Modeling with Rational Rose and UML. Object Technology Series. Addison Wesley, 1998.
[R+ 93]
James Rumbaugh et al. Objektorientiertes Modellieren und Entwerfen. Hanser, 1993.
[Rat98]
Rational Software Cooperation, editor. Rational Rose 98. Extensibility Reference Manual. February 1998. Software Release 1.0.
[Sch91]
Heinrich Schmidt. Philosophisches Wörterbuch. Alfred Kröner Verlag, Stuttgart, 22. edition, 1991.
[Sch95]
Jochen Schwarze. Systementwicklung. Verlag Neue Wirtschaftsbriefe, Herne/Berlin, 1995.

endpunkt uml diagramm

Transcription

Similar documents

When the Victim Forgets

Datenbankpraktikum 27.07.

Das Handbuch zu Umbrello UML Modeller

Das Technikgebiet XML: Herkunft, praktische Anwendung

Einführung in Python

Das Python3.2-Tutorial auf Deutsch

Das Python3.3-Tutorial auf Deutsch

3 Prozesse und Threads

Altova UModel 2016

Studienarbeit Umwandlung von XMI in GXL und von GXL in XMI

das problem der personalen identität in der analytischen

Basiskonzepte