konsistenz und werkzeugunterstützung von ... · 3.2.3.2 zustandsautomat ... 4.1 anforderungen an...
TRANSCRIPT
Konsistenz und
Werkzeugunterstützung von
Systemspezifikationen in UML
Diplomarbeit von
STEPHAN SCHUBERT
im Rahmen des StudiengangsMathematik mit Studienrichtung Informatik
an der Universität Hannover
Erstgutachter: Prof. Dr. Udo LipeckZweitgutachter: 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 unddynamischen Aspekte eines Systems durch mehrere ineinandergreifende Sichten, die ausverschiedenen Diagrammen bestehen.
In der vorliegenden Arbeit wird vorgestellt, wie mit einem Werkzeug ein UML-Modellauf Konsistenz überprüft werden kann. Das UML-Metamodell, welches die die Semantikder UML definiert, wird vorgestellt. Es bildet die Basis für die Identifizierung von Kon-sistenzbedingungen, die zwischen den Modellelementen eines vom Modellierer erstelltenUML-Modells gelten müssen.
Es wird erläutert, im welchen Rahmen ein Werkzeug den Modellierer bei der Erstel-lung konsistenter UML-Modelle unterstützen kann. Das kommerzielle UML-WerkzeugRational Rose 98 wird vorgestellt und um Konsistenzprüfungen erweitert.
Inhaltsverzeichnis
1 Einleitung 81.1 Die Unified Modeling Language . . . . . . . . . . . . . . . . . . . . . .81.2 Historische Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . .81.3 Ziele der Unified Modeling Language . . . . . . . . . . . . . . . . . . .91.4 Ziele dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111.5 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111.6 Probleme bei der Erstellung der Arbeit . . . . . . . . . . . . . . . . . . .12
2 Eine Übersicht 142.1 Dinge in der UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
2.1.1 Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15Klasse . . . . . . . . . . . . . . . . . . . . . . . . . . . .15Interface . . . . . . . . . . . . . . . . . . . . . . . . . .15Kollaboration . . . . . . . . . . . . . . . . . . . . . . . .16Anwendungsfall . . . . . . . . . . . . . . . . . . . . . .16Aktive Klasse . . . . . . . . . . . . . . . . . . . . . . . .17Komponente . . . . . . . . . . . . . . . . . . . . . . . .17Knoten . . . . . . . . . . . . . . . . . . . . . . . . . . .18
2.1.2 Verhalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18Interaktion . . . . . . . . . . . . . . . . . . . . . . . . .18Zustandsautomat . . . . . . . . . . . . . . . . . . . . . .19
2.1.3 Gruppierung . . . . . . . . . . . . . . . . . . . . . . . . . . . .192.1.4 Anmerkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
2.2 Beziehungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .202.2.1 Abhängigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . .202.2.2 Assoziation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .212.2.3 Generalisierung . . . . . . . . . . . . . . . . . . . . . . . . . . .212.2.4 Realisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
2.3 Diagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .232.3.1 Anwendungsfalldiagramm . . . . . . . . . . . . . . . . . . . . .232.3.2 Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . .232.3.3 Objektdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . .23
2
3 INHALTSVERZEICHNIS
2.3.4 Interaktionsdiagramme . . . . . . . . . . . . . . . . . . . . . . .232.3.5 Zustandsdiagramm . . . . . . . . . . . . . . . . . . . . . . . . .252.3.6 Aktivitätsdiagramm . . . . . . . . . . . . . . . . . . . . . . . . .262.3.7 Komponentendiagramm . . . . . . . . . . . . . . . . . . . . . .302.3.8 Einsatzdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . .30
2.4 Architektur und Sichten . . . . . . . . . . . . . . . . . . . . . . . . . . .302.4.1 Anwendungsfallsicht . . . . . . . . . . . . . . . . . . . . . . . .312.4.2 Logische Sicht . . . . . . . . . . . . . . . . . . . . . . . . . . .312.4.3 Prozeßsicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . .312.4.4 Komponentensicht . . . . . . . . . . . . . . . . . . . . . . . . .312.4.5 Verteilungssicht . . . . . . . . . . . . . . . . . . . . . . . . . . .32
2.5 Vier-Schichten Metamodell-Architektur . . . . . . . . . . . . . . . . . .322.6 Erweiterungsmechanismen . . . . . . . . . . . . . . . . . . . . . . . . .33
2.6.1 Stereotypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .332.6.2 Eigenschaftswerte . . . . . . . . . . . . . . . . . . . . . . . . .342.6.3 Zusicherungen . . . . . . . . . . . . . . . . . . . . . . . . . . .34
3 Metamodell 353.1 Fundament . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
3.1.1 Kern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .373.1.1.1 Backbone . . . . . . . . . . . . . . . . . . . . . . . .37
Generalisierung . . . . . . . . . . . . . . . . . . . . . . .38Erweiterung und Einschränkung . . . . . . . . . . . . . .40Deskriptor und Vererbungsmechanismus . . . . . . . . .41Instantiierung . . . . . . . . . . . . . . . . . . . . . . . .41Klasse . . . . . . . . . . . . . . . . . . . . . . . . . . . .42Element . . . . . . . . . . . . . . . . . . . . . . . . . . 43PresentationElement . . . . . . . . . . . . . . . . . . 45ModelElement . . . . . . . . . . . . . . . . . . . . . . . 45Namespace . . . . . . . . . . . . . . . . . . . . . . . . . 46Constraint . . . . . . . . . . . . . . . . . . . . . . . . 47GeneralizableElement . . . . . . . . . . . . . . . . . . 47Classifier . . . . . . . . . . . . . . . . . . . . . . . . 48Feature . . . . . . . . . . . . . . . . . . . . . . . . . . 49StructuralFeature . . . . . . . . . . . . . . . . . . . . 51Attribute . . . . . . . . . . . . . . . . . . . . . . . . . 51BehavioralFeature . . . . . . . . . . . . . . . . . . . . 52Operation . . . . . . . . . . . . . . . . . . . . . . . . . 53Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Parameter . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.1.1.2 Klassifizierer . . . . . . . . . . . . . . . . . . . . . . .55Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
INHALTSVERZEICHNIS 4
Interface . . . . . . . . . . . . . . . . . . . . . . . . . 56DataType . . . . . . . . . . . . . . . . . . . . . . . . . . 56Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Component . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.1.1.3 Assoziation und Generalisierung . . . . . . . . . . . .57Relationship . . . . . . . . . . . . . . . . . . . . . . . 62Association . . . . . . . . . . . . . . . . . . . . . . . . 62AssociationEnd . . . . . . . . . . . . . . . . . . . . . . 63AssociationClass . . . . . . . . . . . . . . . . . . . . 65Generalization . . . . . . . . . . . . . . . . . . . . . . 66Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.1.1.4 Abhängigkeiten . . . . . . . . . . . . . . . . . . . . .67Dependency . . . . . . . . . . . . . . . . . . . . . . . . 67Abstraction . . . . . . . . . . . . . . . . . . . . . . . . 68Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69Permission . . . . . . . . . . . . . . . . . . . . . . . . 70
3.1.1.5 Kommentar . . . . . . . . . . . . . . . . . . . . . . .713.1.2 Erweiterungsmechanismen . . . . . . . . . . . . . . . . . . . . .71
Stereotype . . . . . . . . . . . . . . . . . . . . . . . . 72Modelelement . . . . . . . . . . . . . . . . . . . . . . . 73Constraint . . . . . . . . . . . . . . . . . . . . . . . . 74TaggedValue . . . . . . . . . . . . . . . . . . . . . . . . 75
3.1.3 Datentypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75Primitive . . . . . . . . . . . . . . . . . . . . . . . . . 75Structure . . . . . . . . . . . . . . . . . . . . . . . . . 76Enumeration . . . . . . . . . . . . . . . . . . . . . . . . 76ProgrammingLanguageType . . . . . . . . . . . . . . . . 77Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . 77Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77LocationReference . . . . . . . . . . . . . . . . . . . . 79Multiplicity . . . . . . . . . . . . . . . . . . . . . . . 79Expression . . . . . . . . . . . . . . . . . . . . . . . . 79
3.2 Verhaltenselemente . . . . . . . . . . . . . . . . . . . . . . . . . . . . .803.2.1 Allgemeines Verhalten . . . . . . . . . . . . . . . . . . . . . . .82
3.2.1.1 Signale . . . . . . . . . . . . . . . . . . . . . . . . . .82Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Exception . . . . . . . . . . . . . . . . . . . . . . . . . 83Reception . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.2.1.2 Aktion . . . . . . . . . . . . . . . . . . . . . . . . . .84Action . . . . . . . . . . . . . . . . . . . . . . . . . . . 84ActionSequence . . . . . . . . . . . . . . . . . . . . . . 86CreateAction . . . . . . . . . . . . . . . . . . . . . . . 86
5 INHALTSVERZEICHNIS
DestroyAction . . . . . . . . . . . . . . . . . . . . . . 86TerminateAction . . . . . . . . . . . . . . . . . . . . . 86CallAction . . . . . . . . . . . . . . . . . . . . . . . . 86ReturnAction . . . . . . . . . . . . . . . . . . . . . . . 86AssignmentAction . . . . . . . . . . . . . . . . . . . . 86SendAction . . . . . . . . . . . . . . . . . . . . . . . . 87UninterpretedAction . . . . . . . . . . . . . . . . . . 87
3.2.1.3 Exemplare und Links . . . . . . . . . . . . . . . . . .87Instance . . . . . . . . . . . . . . . . . . . . . . . . . . 87DataValue . . . . . . . . . . . . . . . . . . . . . . . . . 89Object . . . . . . . . . . . . . . . . . . . . . . . . . . . 89ComponentInstance . . . . . . . . . . . . . . . . . . . . 89NodeInstance . . . . . . . . . . . . . . . . . . . . . . . 89Linkobject . . . . . . . . . . . . . . . . . . . . . . . . 90Stimulus . . . . . . . . . . . . . . . . . . . . . . . . . . 90Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90LinkEnd . . . . . . . . . . . . . . . . . . . . . . . . . . 90
3.2.2 Kollaborationen . . . . . . . . . . . . . . . . . . . . . . . . . . .92Notation der Rollen in einer Kollaboration . . . . . . . . .92Interaktion . . . . . . . . . . . . . . . . . . . . . . . . .95Botschaften und Stimuli in einem Kollaborationsdiagramm95Sequenzdiagramm . . . . . . . . . . . . . . . . . . . . .97Collaboration . . . . . . . . . . . . . . . . . . . . . . 99Interaction . . . . . . . . . . . . . . . . . . . . . . . . 99Message . . . . . . . . . . . . . . . . . . . . . . . . . .100ClassifierRole . . . . . . . . . . . . . . . . . . . . . .100AssociationRole . . . . . . . . . . . . . . . . . . . . .101AssociationEndRole . . . . . . . . . . . . . . . . . . .101
3.2.3 Zustandsautomaten . . . . . . . . . . . . . . . . . . . . . . . . .1013.2.3.1 Ereignisse . . . . . . . . . . . . . . . . . . . . . . . .103
Event . . . . . . . . . . . . . . . . . . . . . . . . . . . .103SignalEvent . . . . . . . . . . . . . . . . . . . . . . . .103CallEvent . . . . . . . . . . . . . . . . . . . . . . . . .103TimeEvent . . . . . . . . . . . . . . . . . . . . . . . . .104ChangeEvent . . . . . . . . . . . . . . . . . . . . . . . .104
3.2.3.2 Zustandsautomat . . . . . . . . . . . . . . . . . . . . .105StateMachine . . . . . . . . . . . . . . . . . . . . . . .106CompositeState . . . . . . . . . . . . . . . . . . . . . .110StateVertex . . . . . . . . . . . . . . . . . . . . . . . .110Transition . . . . . . . . . . . . . . . . . . . . . . . .110Guard . . . . . . . . . . . . . . . . . . . . . . . . . . . .110State . . . . . . . . . . . . . . . . . . . . . . . . . . . .111
INHALTSVERZEICHNIS 6
SimpleState . . . . . . . . . . . . . . . . . . . . . . . .111FinalState . . . . . . . . . . . . . . . . . . . . . . . .111PseudoState . . . . . . . . . . . . . . . . . . . . . . . .111SyncState . . . . . . . . . . . . . . . . . . . . . . . . .112SubmachineState . . . . . . . . . . . . . . . . . . . . .113StubState . . . . . . . . . . . . . . . . . . . . . . . . .113
3.2.4 Aktivitätsgraphen . . . . . . . . . . . . . . . . . . . . . . . . . .113ActivityGraph . . . . . . . . . . . . . . . . . . . . . .116SubactivityState . . . . . . . . . . . . . . . . . . . .116ActionState . . . . . . . . . . . . . . . . . . . . . . . .116CallState . . . . . . . . . . . . . . . . . . . . . . . . .117ObjectFlowState . . . . . . . . . . . . . . . . . . . . .117ClassifierInState . . . . . . . . . . . . . . . . . . . .118PseudoState . . . . . . . . . . . . . . . . . . . . . . . .118
4 Werkzeugunterstützung und Konsistenz 1194.1 Anforderungen an ein UML-Werkzeug . . . . . . . . . . . . . . . . . . .1194.2 Konsistenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121
4.2.1 Sinn einer Konsistenzprüfung . . . . . . . . . . . . . . . . . . .1244.2.2 Probleme der (werkzeuggestützten) Konsistenzprüfung . . . . . .1244.2.3 Ein hypothetisches Werkzeug zur Konstruktion konsistenter Mo-
delle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1254.2.4 Konsistenzprüfung als Informationsproduzent . . . . . . . . . . .128
4.3 Rational Rose 98 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1284.3.1 UML-Modelle in Rational Rose 98 . . . . . . . . . . . . . . . .1284.3.2 Weitere Merkmale von Rational Rose 98 . . . . . . . . . . . . .1314.3.3 Konsistente UML-Modelle und Rational Rose 98 . . . . . . . . .133
4.4 Das Werkzeugmetamodell von Rational Rose 98 . . . . . . . . . . . . . .1344.4.1 Die Spitze der Klassenhierarchie . . . . . . . . . . . . . . . . . .1344.4.2 Diagrammarten . . . . . . . . . . . . . . . . . . . . . . . . . . .1344.4.3 Modellelemente in Klassendiagrammen . . . . . . . . . . . . . .1374.4.4 Modellelemente in Interaktionsdiagrammen . . . . . . . . . . . .1394.4.5 Modellelemente in Zustandsdiagrammen . . . . . . . . . . . . .140
4.5 Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1424.5.1 Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1424.5.2 Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1444.5.3 Operationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1474.5.4 Assoziationen . . . . . . . . . . . . . . . . . . . . . . . . . . . .1504.5.5 Spezielle Assoziationen . . . . . . . . . . . . . . . . . . . . . .1534.5.6 Generalisierungen . . . . . . . . . . . . . . . . . . . . . . . . .1554.5.7 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1574.5.8 Realisierungsbeziehungen . . . . . . . . . . . . . . . . . . . . .159
7 INHALTSVERZEICHNIS
4.5.9 Abhängigkeitsbeziehungen . . . . . . . . . . . . . . . . . . . . .1614.5.10 Signale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1624.5.11 Spezifizierung von Rollen . . . . . . . . . . . . . . . . . . . . .164
4.6 Interaktionsdiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . .1654.6.1 Klassifiziererrollen und Objekte . . . . . . . . . . . . . . . . . .1654.6.2 Assoziationsrollen und Links . . . . . . . . . . . . . . . . . . . .1674.6.3 Botschaften und Stimuli . . . . . . . . . . . . . . . . . . . . . .1714.6.4 Kontrollfluß . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1754.6.5 Verzweigung und Iteration . . . . . . . . . . . . . . . . . . . . .177
4.7 Zustandsdiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1784.7.1 Ereignisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1794.7.2 Aktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1824.7.3 Transitionen . . . . . . . . . . . . . . . . . . . . . . . . . . . .1824.7.4 Zustände . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1844.7.5 Zustandsautomaten . . . . . . . . . . . . . . . . . . . . . . . . .186
5 Benutzerschnittstelle zur Konsistenzprüfung 1955.1 Möglichkeiten von Rose-Script . . . . . . . . . . . . . . . . . . . . . . .1955.2 Strukturierung der Konsistenzprüfungen . . . . . . . . . . . . . . . . . .1975.3 Konzept der Benutzerschnittstelle . . . . . . . . . . . . . . . . . . . . .198
A Realisierung der Benutzerschnittstelle 202A.1 Das Skript einer Konsistenzprüfung . . . . . . . . . . . . . . . . . . . .202A.2 Das Skript eines Auswahldialogs . . . . . . . . . . . . . . . . . . . . . .203A.3 Entwickelte Skripte . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203
A.3.1 Hilfsfunktionen . . . . . . . . . . . . . . . . . . . . . . . . . . .203A.3.2 Konsistenzprüfungen . . . . . . . . . . . . . . . . . . . . . . . .204A.3.3 Auswahldialoge . . . . . . . . . . . . . . . . . . . . . . . . . . .208
A.4 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .208
Kapitel 1
Einleitung
Die ersten drei Abschnitte erläutern, was die Unified Modeling Language ist, ihre hi-storischen Wurzeln und die Ziele, die bei der Entwicklung dieser Modellierungssprachespezifiziert wurden. Anschließend wird das Ziel dieser Arbeit erklärt und ihr Aufbaubeschrieben. Abschließend wird auf die Probleme bei der Erstellung dieser Arbeit hinge-wiesen.
1.1 Die Unified Modeling Language
Systeme bestehen „aus einer Menge von Elementen, die über Beziehungen zusammen-wirken oder interagieren, um ein bestimmtes Ziel oder einen bestimmten Zweck zu er-reichen“ ([Sch95], S. 15). Menschen benutzen zum Verständnis komplexer Systemedas Prinzip der Abstraktion. „Abstraktion im engeren Sinne heißt ein Denkvorgang,der vom Einzelnen, Zufälligen, Unwesentlichen absieht und das Allgemeine, Notwendi-ge, Wesentliche heraushebt, um zu wissenschaftlich objektiver Erkenntnis zu gelangen“([Sch91], S. 4). Das Ziel der Abstraktion von einem System ist die Bildung eines Modellsdes Systems, die es dem Menschen erlaubt, die Systemelemente und ihr Zusammenwir-ken zu verstehen. Allgemein ausgedrückt ist die Unified Modeling Language (UML)eine Sprache, mit der Modelle von Systemen graphisch beschrieben werden können. Pri-mär dient die UML der Dokumentation, Analyse, Entwurf und Spezifikation von Soft-waresystemen - speziell von objektorientierten Systemen. UML ist „nur“ eine (visuelle)Modellierungssprache, aber kein Softwareentwicklungsprozeß oder gar eine visuelle Pro-grammmiersprache. Der Begriff „unified“ (dt. vereinheitlicht) wird durch die historischeEntwicklung der Sprache begründet.
1.2 Historische Entwicklung
Während der neunziger Jahre wurden eine Vielzahl von Methoden für die Systement-wicklung 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 Metho-den hatte eine eigene Notation und eigene Stärken und Schwächen. Die Weiterentwick-lung der einzelnen Methoden führte dazu, daß Konzepte anderer Methoden übernom-men wurden. Leider hatte jede Methode noch immer ihre eigene Notation. Diese Zeitwird durch den Begriff „method war“ beschrieben. Z.B. beschreibt ein gefüllter Kreis inOMT-Notation einen Kardinalitätsindikator, in Booch-Notation jedoch ein Aggregations-symbol. Wie soll eine Klasse dargestellt werden: Als Wolke (Booch) oder als Rechteck(OMT)? Welche Darstellung ist besser? Eine Situation die unbefriedigend für alle Betei-ligten war, denn eine unterschiedliche Syntax und Semantik führt nicht nur bei Software-entwicklern zu Kommunikationsschwierigkeiten.
Im Oktober 1994 begannen Grady Booch (Rational Software Corporation) und JamesRumbaugh (der von General Electric zu Rational wechselte) mit der Vereinheitlichung derBooch und OMT Methoden, dessen Entwurf einer Version 0.8 im Oktober 1995 erschienund „Unified Method“ hieß.
1995 stieß auch Jakobson (OOSE) zu Rational und OOSE wurde in das Projekt auf-genommen (1996, UML 0.9). Mit mehreren Software-Organisationen, die bereit warenRessourcen einzubringen, um eine vollständige UML-Definition auszuarbeiten, wurde einUML-Konsortium gegründet (UML 1.0). Im Januar 1997 wurde UML 1.0 bei der OMG(Object Management Group) zur Standardisierung eingereicht. Das Konsortium wurdeerweitert und eine überarbeitete Version (UML 1.1) wurde im Juli 1997 bei der OMG zurStandardisierung eingereicht und im November 1997 angenommen. In die Vereinheitli-chung gingen nicht nur die Konzepte der Booch, OMT und OOSE Methoden ein, sondernauch „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. ImHerbst 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ß dieUML, 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 vomKonzept bis zu ausführbaren Teilen.
2. Berücksichtigung der Skalierung von komplexen Systemen.
3. Erzeugung einer Modellierungssprache, die sowohl von Menschen als auch vonMaschinen benutzt werden kann.
1.3. ZIELE DER UNIFIED MODELING LANGUAGE 10
4. Die UML sollte den Benutzern eine leicht zugängliche und ausdrucksstarke visu-elle Modellierungssprache bieten, mit der sie Modelle entwickeln und austauschenkönnen.
UML vereinigt eine Menge von allgemeinen bzw. Kern-Konzepten, die in anderenMethoden und Tools verwendet werden. Benutzer anderer Methoden können somitrelativ leicht umsteigen und ihre Modelle mit erträglichem Aufwand transformie-ren.
5. Die UML sollte Erweiterungs- und Spezialisierungsmechanismen enthalten.
Es ist (bzw. war) zu erwarten, daß die UML an neue Bedürfnisse oder spezielleBereiche angepaßt werden wird. Dabei ist aber nicht gewollt, den Kern von UMLfür jedes Gebiet neu zu definieren oder zu implementieren. Der Kern der UMLsollte nicht mehr als notwendig geändert werden müssen. Die Benutzer sollten inder Lage sein
• Modelle der meisten Anwendungen mit den allgemeinen Konzepten der UMLzu 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 spezialisie-ren.
6. Unabhängigkeit von besonderen Programmiersprachen und Entwicklungsprozes-sen.
Unabhängigkeit bedeutet, daß man sich nicht auf eine bestimmte Programmierspra-che oder einen bestimmten Prozeß festlegen wollte, allerdings bei gleichzeitigerMinimierung der Schwierigkeiten, die UML mit einer bestimmten Programmier-sprache 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 ohneInformationsverlust ausgetauscht werden können. Damit können sich die Herstellervon Werkzeugen auf spezielle Funktionen ihrer Software konzentrieren anstatt ihreRessourcen auf verschiedene Werkzeuge für verschiedene Modellierungssprachenzu verteilen.
9. Unterstützung höherer Entwicklungskonzepte wie z.B. Kollaborationen, Frame-works, Muster (pattern) und Komponenten.
10. Integration der besten und bewährten Praktiken.
11 KAPITEL 1. EINLEITUNG
1.4 Ziele dieser Arbeit
Systeme zeichnen sich durch Struktur und Verhalten aus und können durch Modelle be-schrieben werden. Ein UML-Modell beschreibt die statischen und dynamischen Aspekteeines Systems durch mehrere ineinandergreifende Sichten.
In der Anwendungsfallsicht wird das System als black-box betrachtet. Sie beschreibtrelativ grob die Funktionen und Abläufe des Systems, ohne auf deren Realisierung ein-zugehen. Die logische Sicht beschreibt das Systeminnere. Sie spezifiziert die Systemele-mente und ihre gegenseitigen Beziehungen, mit denen die Funktionen und Abläufe derAnwendungsfallsicht umgesetzt werden. Weitere Sichten beschreiben die Nebenläufig-keit und Synchronisationsmeachnismen des Systems, die Realisierung des Systems durchKomponenten (Quelltexte, ausführbare Dateien u. ä.) und die Verteilung der Komponen-ten auf die Hardware des Systems.
Die Sichten bestehen aus Diagrammen, die jeweils einen bestimmten Aspekt des Sys-tems beschreiben. Die UML stellt Diagramme zur Verfügung, die teilweise in mehre-ren Sichten benutzt werden. Klassendiagramme beschreiben Systemelemente und ihreBeziehungen, während Interaktionsdiagramme die Interaktion der Systemelemente zurErreichung eines bestimmten Ziels darstellen. Mit Zustands- (Statecharts) und Aktivitäts-diagrammen (eine Art Flowchart) können jeweils weitere dynamische Aspekte modelliertwerden. Anwendungsfall-, Komponenten- und Verteilungsdiagramme sind weitere Dia-gramme, 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 istes, die Zusammenhänge zwischen den Diagrammen und Modellelementen eines UML-Modells 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 demCASE-Toolmarkt verfügbar. Rational Rose 98 ist ein UML-Werkzeug der Rational Soft-ware Cooperation (s.o.), welches von verschiedenen Instituten der Universität Hannovereingesetzt wird. Ein weiteres Ziel dieser Arbeit ist die Untersuchung dieses Werkzeugs.Wie geht Rational Rose 98 mit der Problematik konsistenter Systemspezifikationen umund welche Zusammenhänge zwischen den Modellelementen werden auf Konsistenz ge-prü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 werdendie Sprachelemente, Diagramme und Sichten der UML, aus denen ein UML-Modell be-steht und die Erweiterungsmechanismen, mit denen der Sprachumfang der UML erweitertwerden 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 Konsistenzbe-dingungen in UML-Modellen.
In Kapitel 4 werden einleitend allgemeine Anforderungen an ein UML-Werkzeug auf-gestellt. Anschließend wird definiert, wann ein UML-Modell konsistent ist. Es wirderläutert, welche Probleme bei der Konsistenzprüfung von UML-Modellen zu beachtensind. Anhand eines hypothetischen Werkzeugs wird erläutert, wie ein Werkzeug demModellierer bei der Erstellung konsistenter UML-Modelle unterstützen kann und welcheInformationen eine Konsistenzprüfung liefern sollte. Die Modellierungsmöglichkeitenund Konsistenzprüfungen von Rational Rose 98 werden vorgestellt.
Rational Rose 98 besitzt ein eigenes Metamodell, welches das UML-Metamodell teil-weise realisiert. Anhand dieses Metamodells wird erläutert, in welchem Rahmen mit Ra-tional Rose 98 UML-Modelle modelliert werden können und welche Konstrukte RationalRose 98 semantisch erkennt. Abschließend werden Konsistenzbedingungen zwischen denModellelementen der Klassen-, Interaktions- und Zustandsdiagramme identifiziert.
In Kapitel 5 wird die Erweiterung von Rational Rose um eine Benutzerschnittstellefü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 Be-ginn der Arbeit erwartet wurde. Daher mußte nicht nur ein weiteres (optionales) Zielder 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 Modellelementendieser Diagrammarten Verbindungen existieren, die sich auf Konsistenz untersuchen las-sen.
Das UML-Metamodell, und damit auch die Semantik der UML, beinhaltet selbst In-konsistenzen. Es gab zwar in relativ kurzen Abständen korrigierte und wenig veränderteSpezifikationen der UML, zwischen April ’99 und Juni ’99 waren es sieben, die einigeInkonsistenzen beseitigten, aber auch Veränderungen beinhalteten und damit neue Fragenaufwarfen. Eine Sprachspezifikation umfaßt mittlerweise knapp 800 Seiten, von denenungefähr die Hälfe relevant für diese Arbeit ist. Leider sind die Veränderungen zwischenden Spezifikationsversionen kaum dokumentiert, so daß als Grundlage für diese Arbeitdie 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, diesemAnspruch (noch) nicht gerecht werden, d.h. das Metamodell ist in diesem Sinne nichtvollständig.
Die Identifizierung von Konsistenzbedingungen setzt voraus, daß die Semantik derKonzepte formal klar definiert ist. Dies ist nicht immer der Fall. Dadurch gibt es auch
13 KAPITEL 1. EINLEITUNG
in der benutzten Literatur, die größtenteils die Anwendung der UML beschreibt, Inkon-sistenzen. Teilweise hat es den Anschein, als ob die Autoren (verständlicherweise) nachdem Motto „Problem erkannt – Gefahr gebannt“ verfahren. Diesen Vorwurf muß sichauch der Autor dieser Arbeit gefallen lassen. Eine Diskussion dieser Problematik wür-de zu Veränderungsvorschlägen des Metamodells der UML führen, die den Rahmen derArbeit sprengen.
Kapitel 2
Eine Übersicht
Die Unified Modeling Language ist eine Sprache zur Visualisierung, Spezifizierung, Kon-struktion und Dokumentation der Bestandteile eines software-intensiven Systems. DasVokabular und die Grammatik dieser Modellierungssprache zielen auf die konzeptionel-le und physische Darstellung von Softwaresystemen. Die graphische Darstellung von(komplexen) Zusammenhängen erleichtert das Verständnis („ein Bild sagt mehr als tau-send Worte“) und die Kommunikation über Grenzen (Programmiersprache, Sprache, Vo-kabular1) hinweg. Die UML ist aber mehr als eine reine Ansammlung von graphischenSymbolen. Hinter jedem Symbol der UML verbirgt sich eine wohldefinierte Semantik,so daß ein Entwickler ein Modell erstellen kann, welches ein anderer Entwickler (oderein Werkzeug) eindeutig identifizieren kann ([BRJ99a], Seite 15). In diesem Kontext be-deutet Spezifizierung die Erstellung präziser, eindeutiger und vollständiger Modelle. DieAbbildung solcher Modelle auf eine Programmiersprache ermöglicht (unter bestimmtenVoraussetzungen) Codeerzeugung (forward engineering). Die UML unterstützt die Do-kumentation von Softwaresystemen durch Diagramme, die bestimmte Sichten auf einSystem oder Phasen repräsentieren.
Das Vokabular der UML besteht aus Dingen, Beziehungen und Diagrammen (2.1 bis2.3). Dinge sind die Grundbausteine in einem Modell, Beziehungen verbinden diese Din-ge miteinander und Diagramme stellen durch Gruppierung bestimmter Dinge und derenBeziehungen einen Aspekt des Systems dar. Eine Sicht auf das System besteht aus mehre-ren Diagrammen (2.4). Die UML ist in ein Schichtenmodell (2.5) eingebettet und besitztErweiterungsmechanismen, 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 werdenkann: 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 oderphysische Elemente eines Systems und sind meist statischer Natur. Insgesamt gibt essieben Arten von strukturellen Elementen.
Klasse EineKlassebeschreibt eine Menge von Objekten, die sich durch gleiche Struk-tur (Attribute und Beziehungen), gleiches Verhalten (Operationen) und die gleiche Se-mantik auszeichnen.
Eine Klasse wird als Rechteck mit ihrem Namen und optional mit ihren Attributenund 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 (Na-me, Argumente, Rückgabetyp), die einen Dienst einer Klasse oder einer Komponente be-schreiben. Die Operationen des Interface werden von der Klasse bzw. der Komponenterealisiert. 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 Interfacerealisiert (Abb. 2.2). Diese Interfacedarstellung wird auch „Lolli“ genannt.
Kunde
nameadresse
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 dasKlassenrechteck mit «interface», einem Stereotyp (siehe Seite 33), markiert. DieVerbindung zwischen dem Interface und der Klasse wird durch eine Realisierungs-beziehung (siehe Seite 22) hergestellt.
Kunde
nameadresse
speichern()
speicherbar
speichern()
<<Interface>>
Abbildung 2.3: Ausführliche Darstellung eines Interfaces mit Operationssignatur.
Das UML-Interfacekonzept gleicht dem Interfacekonzept von Java. In Java werdenInterfaces ebenfalls durch Klassen realisiert.
Kollaboration EineKollaborationdefiniert einen Kontext für eine Interaktion und be-steht aus Rollen, die von Elementen (z.B. Klassen) gespielt werden, und Beziehungenzwischen den Rollen. Die Rollen und ihre Beziehungen werden benutzt, um ein koopera-tives Verhalten darzustellen, das größer ist als die Summe der einzelnen Elemente, d.h. ineiner Kollaboration wird die Bewältigung einer Aufgabe beschrieben, zu der ein einzel-nes Element nicht in der Lage ist. Eine Kollaboration hat also nicht nur eine strukturelle,sondern auch eine verhaltensorientierte Dimension. Kollaborationen stellen die Imple-mentierung von Mustern dar, aus denen ein System gebildet wird.
Dargestellt wird eine Kollaboration als Ellipse mit einer gestrichelten Linie, die nor-malerweise 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 dasVerhalten zur Erfüllung der Aufgabe der Kollaboration ausführlicher darstellt.
Anwendungsfall Ein Anwendungsfallist eine Beschreibung einer Menge von Abläu-fen, die ein System ausführt und die dem Benutzer (Anwender, aber auch ein externesSystem) ein wahrnehmbares Ergebnis liefert. Anwendungsfälle werden benutzt um das
17 KAPITEL 2. EINE ÜBERSICHT
Verhalten eines Systems zu strukturieren, ohne auf die Realisierung des Verhaltens ein-zugehen. Das System wird hierbei als „black box“ betrachtet. Realisiert werden Anwen-dungsfä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 Ab-läufe selbst werden z.B. durch strukturierten Text oder mit Hilfe von Interaktions- undAktivitätsdiagrammen (Seite 26) spezifiziert.
Bestellung aufnehmen
Abbildung 2.5: Anwendungsfallnotation
Aktive Klasse Eineaktive Klasseist eine spezielle Klasse, deren Objekte einen Prozeßoder Thread oder mehrere Prozesse oder Threads besitzen, d.h. ihre Objekte repräsentie-ren Elemente, die nebenläufig ausgeführt werden können.
Eine aktive Klasse wird wie eine Klasse in einem Klassenrechteck dargestellt, welcheszur Unterscheidung von normalen Klassen fett umrandet wird (Abb. 2.6). Chart Name : New Class Diagram
Chart Filename : clsUntitled2.VobChart Type : UML Class DiagramEreignisManager
aussetzen( )verwerfem( )
Abbildung 2.6: aktive Klasse
Komponente Eine Komponenteist ein physisches und austauschbares Teil eines Sy-stems, 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).
EreignisManager.java
Abbildung 2.7: Komponente
2.1. DINGE IN DER UML 18
Knoten Ein Knoten ist ein physisches Element eines Systems und stellt meist einenComputer mit Prozessor und Speicher dar. Ein Computer mit mehreren Prozessoren kanndurch mehrere Knoten modelliert werden. Mit Hilfe der Knoten kann z.B. die Topologiedes Rechnernetzes modelliert werden (Abb. 2.8). Den Knoten können Komponentenzugeordnet werden.
Work-stations
PCs
switching Hub
Applikations-server
Datenbank-server
10 Mb Ethernet
100 Mb Ethernet
100 Mb Ethernet
100 Mb Ethernet
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 Ver-ben der Sprache. Insgesamt gibt es zwei grundlegende Arten von Verhaltensweisen inder UML, welche die Dynamik eines Systems beschreiben: Interaktionen und (endliche)Automaten.
Interaktion Eine Interaktionist eine Menge von Botschaften (messages), die von Ob-jekten in einem, durch eine Kollaboration bestimmten, Kontext ausgetauscht werden, umein bestimmtes Ziel oder einen bestimmten Zweck zu erfüllen. Mit einer Interaktion läßtsich das Verhalten einer Gruppe von Objekten oder einer Operation spezifizieren. DerEmpfang einer Botschaft führt bei dem empfangenen Objekt zur Ausführung eines Ver-haltens. Dies ist meist eine Operation des empfangenden Objekts, die z.B. Beziehungenzu anderen Objekten modifiziert, Werte verändert oder Botschaften an andere Objekteverschickt.
Eine Botschaft wird als Pfeil, gerichtet vom Sender zum Empfänger, dargestellt (Abb.2.9). Die zu übermittelnde Information ist meistens ein Operationsname inklusive optio-naler Argumente.
19 KAPITEL 2. EINE ÜBERSICHT
Druckvorschau : Window
EventManager
«create»
display
Chart Name : New Sequence DiagramChart Filename : C:\Home\Stephan\DA\VUML\seqUntitled4.VobChart Type : UML Sequence Diagram
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 die-ses in seiner Existenz als Reaktion auf Ereignisse durchläuft, als auch die Reaktion aufdiese Ereignisse. Mit Zustandsautomaten kann das Verhalten einer einzelnen Klasse odereiner Operation spezifiziert werden.
Zustände werden als Rechtecke mit abgerundeten Ecken dargestellt, die den Namendes Zustands enthalten (Abb. 2.10). An der Darstellung eines Automaten sind meistensweitere Elemente beteiligt: Zustandsübergänge (Transitionen) als gerichtete Pfeile, Er-eignisse (Auslöser eines Zustandsübergangs) und Aktivitäten als Reaktion auf einen Zu-standsübergang.
essen arbeiten
hungrig / Essen organisieren
satt / an den Schreibtisch setzen
Abbildung 2.10:Vereinfachte Darstellung der Zustände eines Diplomanden während derDiplomarbeit
Die Zustandsautomaten bzw. Diagramme der UML basieren auf den Statecharts vonHarel. Ein UML-Zustandsautomat kann Zustände besitzen, die selbst als Zustandsauto-maten angesehen werden können.
2.1.3 Gruppierung
Zur Organisation eines Modells in überschaubare Gruppen bietet die UML einen Paket-mechanismus an. EinPaketbeinhaltet beliebige (logisch zusammengehörende) Modell-elemente und kann somit ein Teilsystem darstellen. Die Organisation in Pakete ist aller-dings nur rein konzeptionell, für die physische Aufteilung sind Komponenten und Knotenzuständig.
Dargestellt wird ein Paket als Akte mit Reiter und dem Namen des Pakets. Alternativkann 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
Benutzerschnittstellesiehe GUI.DOC
Abbildung 2.12: Notiz
Die UML kennt eine Hauptart von Anmerkungen: Notizen bzw. Kommentare. Dia-gramme, aber auch einzelne Modellelemente, können in der UML mit einerNotizverse-hen werden.
Eine Notiz wird als Rechteck mit Eselsohr dargestellt (Abb. 2.12), welches weitereInformationen zu einem oder mehreren Elementen enthält. Eine Notiz kann jede beliebigeKombination von Text und Graphik enthalten, z.B. eine Web-Adresse (URL) oder einVerweis auf ein Dokument. Notizen geben dem Modellierer die Möglichkeit, die Modellemit 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, Generali-sierung und Realisierung. Von diesen Arten existieren weitere Abwandlungen und Spe-zialisierungen.
2.2.1 Abhängigkeit
EineAbhängigkeitist eine semantische Beziehung zwischen zwei Modellelementen, beidenen sich Änderungen der Spezifikation des unabhängigen Elements auf das abhängigeElement auswirken können. Eine Abhängigkeit wird als gestrichelte Linie dargestellt, dieoptional gerichtet und benannt ist (Abb. 2.13).
21 KAPITEL 2. EINE ÜBERSICHT
Paket-A Paket-B
Abbildung 2.13: Paket-A ist abhängig von Paket-B
2.2.2 Assoziation
Eine Assoziationist eine strukturelle Beziehung zwischen Klassen. Sie beschreibt eineMenge von Objektbeziehungen, die sich durch eine gemeinsame Struktur und Seman-tik auszeichnen. EineAggregationist eine spezielle Assoziation, welche eine „Ganzes-Teile“-Beziehung beschreibt. Eine Assoziation wird als Linie dargestellt, die optionalgerichtet, benannt wird und weitere Beschriftungen, wie z.B. Kardinalität und Rollenna-men, enthalten kann (Abb. 2.14).
Person Firma*1..*
ArbeitgeberPerson
*1..*
Abbildung 2.14:Eine Person (in der Rolle als Angestellter) kann beliebig vielen Firmenzugeordnet werden. Einer Firma (in der Rolle als Arbeitgeber) muß min-destens ein Angestellter zugeordnet sein. In dieser Beziehung spielt einObjekt der Klasse „Person“ die Rolle „Angestellter“ und entsprechendein 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 allgemeinenund einer spezielleren Spezifikation eines Modellelements, in der Exemplare (Instanzen)eines spezialisierten Elements (Sub-Element, child) durch Exemplare des verallgemei-nerten Elements (Super-Element, parent) substituiert werden können. Das Sub-Element„erbt“ auf diese Weise die Struktur und das Verhalten des allgemeineren Elements. DasSub-Element kann die Struktur und das Verhalten unter der Prämisse der Substituier-barkeit spezialisieren. Dieses Substitutionsprinzip garantiert, daß überall dort, wo einExemplar eines allgemeinen Modellelements erwartet wird, auch ein Exemplar eines spe-zielleren Modellelements verwendet werden kann.
Dargestellt wird eine Generalisierung als durchgezogene Linie mit einem Dreieck alsSpitze, 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 Unterklassender Klasse Window mit spezielleren Eigenschaften als die Klasse Win-dow, können aber überall dort eingesetzt werden, wo ein Objekt derKlasse Window erwartet wird.
2.2.4 Realisierung
EineRealisierungstellt eine semantische Beziehung zwischen Klassifizierern (z.B. Klas-sen, Interfaces, Komponenten) dar, bei der ein Klassifizierer etwas spezifiziert und der an-dere diese Spezifikation umsetzt (Vertragscharakter). Realisierungsbeziehungen könnenzwischen Interfaces und Klassen/Komponenten oder zwischen Anwendungsfällen undKollaborationen existieren.
Dargestellt wird eine Realisierung als gestrichelte Linie mit einem Dreieck als Spitze,welche auf das spezifizierende Modellelement zeigt (Abb. 2.16).
Kunde
nameadresse
speichern()
speicherbar
speichern()
<<Interface>>
Abbildung 2.16:Realisierung: Die Klasse „Kunde“ realisiert das Interface „speicherbar“.Eine Realisierung beinhaltet eine Abhängigkeit (die Klasse ist vom In-terface abhängig) und eine Übertragung von Eigenschaften zwischenden beteiligten Elementen (die Klasse „erbt“ die Operationssignaturendes Interface). Als graphische Darstellung einer Realisierungsbeziehungist die Kreuzung der Darstellungen von Abhängigkeits- und Realisie-rungsbeziehung gewählt worden.
23 KAPITEL 2. EINE ÜBERSICHT
2.3 Diagramme
Ein Diagramm wird benutzt, um ein System aus einer bestimmten Sicht und unter einembestimmten Aspekt zu betrachten. Einige Diagramme können in verschiedenen Sichten(siehe 2.4) benutzt werden, so daß sich hieraus Zusammenhänge zwischen den unter-schiedlichen Sichten modellieren lassen. In der UML sind die folgenden neun Diagram-me definiert.
2.3.1 Anwendungsfalldiagramm
Ein Anwendungsfalldiagramm(use case diagram) zeigt die Beziehungen zwischen An-wendungsfällen (use cases) und Akteuren (actors). Anwendungsfalldiagramme stellendie statische Anwendungsfallsicht eines Systems dar. Mit Anwendungfalldiagrammenwird das Systemverhalten organisiert und modelliert. (Abb. 2.17).
Anwendungsfälle beschreiben das Systemverhalten aus der Sicht von Akteuren (meistBenutzer, aber auch andere Systeme), die sich in der Systemumwelt befinden und dieseAnwendungsfälle benutzen (Abb. 2.17). Anwendungsfälle werden durch Abläufe be-schrieben, die angebenwasdas System machen soll, nicht wie die Anwendungsfälle im-plementiert werden. Sie dienen primär der Kommunikation zwischen den Endanwendernbzw. den Experten des Einsatzbereichs des Systems und den Systementwicklern.
2.3.2 Klassendiagramm
Klassendiagramme sind die in einer objektorientierten Modellierung am häufigsten anzu-treffenden Diagramme. EinKlassendiagramm(Abb. 2.18) besteht im wesentlichen auseiner Menge von Klassen, Interfaces und ihren Beziehungen. Klassendiagramme zeigendie statische Entwurfssicht des Systems. Klassendiagramme mit aktiven Klassen zeigendie statische Prozessicht des Systems.
2.3.3 Objektdiagramm
Ein Objektdiagrammist eine Instantiierung von Modellelementen eines oder mehrererKlassendiagramme. Es enthält Objekte und Links (Exemplare einer Klasse bzw. einerAssoziation) und zeigt eine statische Momentaufnahme des Systems (Abb. 2.19). Ob-jektdiagramme werden benutzt, um Klassen und Beziehungen exemplarisch darzustellen.
2.3.4 Interaktionsdiagramme
Ein Interaktionsdiagrammbesteht aus Objekten und zeigt, wie sie miteinander durch Bot-schaftenaustausch kommunizieren. Die UML bietet zwei semantisch äquivalente Interak-tionsdiagramme, die jeweils einen anderen Aspekt hervorheben. EinSequenzdiagrammzeigt den Botschaftenaustausch zwischen den Objekten zeitlich geordnet (Abb. 2.20),
2.3. DIAGRAMME 24
Auftragsbearbeitung
Kunde
MA-Bestellannahme
Datenbank
MA-Rechnungswesen
MA-Lager
Bestellungaufnehmen
Zahlungseingangüberwachen
Waren ausliefern
Abbildung 2.17:Anwendungsfalldiagramm. Das Rechteck symbolisiert die Systemgren-zen.
25 KAPITEL 2. EINE ÜBERSICHT
Chart Name : New Class DiagramChart Filename : KD-Bestellung.VobChart Type : UML Class Diagrameine Bestellung ist immer einem
Kunden zugeordnet. Entweder als "besteller" oder als "kunde".
Diese spezielle Form der Assoziationheißt Komposition.Sie ist eine Aggregation, bei der die Teile (BestPosition) vom Ganzen existenzabhängig sind.
BestellungbestDatum: Datezustand: BestellzustandgesamtPreis( )
BestPositionmenge: Doublepreis: Double
KundenameaktiveBestellungen( )abgBestellungen( )
ArtikelnamebestNrinfo
besteht aus1 1..*
bestellung position
0..1
0..*
besteller
aktiveBestellung 0..*
0..1
abgBestellung
kunde
1
0..*
artikel
bestPos
Abbildung 2.18: Klassendiagramm
während einKollaborationsdiagrammdie strukturelle Organisation der interagierendenObjekte hervorhebt (Abb. 2.21). Die semantische Äquivalenz der beiden Interaktionsdia-gramme bedeutet nicht, daß beide explizit die gleichen Informationen darstellen. Es gibtInformationen, die nur in jeweils einem Diagramm dargestellt werden. Z.B. wird in einemKollaborationsdiagramm 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 Sei-te 19, Abb. 2.10). Ein Zustandsdiagramm wird meistens benutzt, um die Reaktion einerKlasse (genauer: der Objekte einer Klasse) auf mögliche Ereignisse zu modellieren. Zu-standsdiagramme werden nur für Klassen gezeichnet, die mehrere Zustände haben. Esist auch möglich, das dynamische Verhalten eines Systems (oder Teilsystems) oder einerOperation 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
name = Schubert
BestObj-1 : Bestellung
bestDatum = 01.03.99zustand = abgeschlossen
BestObj-2 : Bestellung
bestDatum = 25.05.1999zustand = erfassung
: BestPosition
menge = 1preis = 99.90
: Artikel
name = UML - Das BenutzerhandbuchbestNr = 3-8273-1486-0
: BestPosition : BestPosition
kunde
abgBestellung aktiveBestellung
besteller
besteht aus
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äufi-gen Zustandsautomaten zusammenzusetzen.
2.3.6 Aktivitätsdiagramm
Ein Aktivitätsdiagrammist im wesentlichen ein Flußdiagramm, welches auch nebenläu-fige Flüsse enthalten kann. Ein Aktivitätsdiagramm ist ein Spezialfall eines Zustandsdia-gramms, bei dem der Zustandsautomat größtenteils aus sogenannten Aktivitätszuständenbesteht. In einem Aktivitätsdiagramm findet im Gegensatz zu einem Zustandsdiagrammdas 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 einesZustands beendet ist, d.h. die Beendigung der Aktivität stellt das Ereignis dar.
Aktivitätsdiagramme werden benutzt, um die Befehlssequenz einer Operation oder
2Mit der UML können auch Zustandsautomaten modelliert werden, die innerhalb eines Zustands eineAktivität ausführen
27 KAPITEL 2. EINE ÜBERSICHT
: ... KdObj : Kunde
BestObj-2 : Bestellung
neueBestellung«create» Bestellung(KdObj)
setCurrentDate
setKunde(KdObj)
BestObj-2
addAktiveBestellung(BestObj-2)
Abbildung 2.20: Interaktion in einem Sequenzdiagramm
Chart Name : New Collaboration DiagramChart Filename : KoD-Bestellung.VobChart Type : UML Collaboration Diagram
{self}
{self}
: ...
KdObj : Kunde BestObj-2 : Bestellung
1: neueBestellung
{new}
1.1: Bestellung(KdObj)
1.1.1: setCurrentDate
1.1.2: setKunde(KdObj)
1.2: addAktiveBestellung(BestObj-2)
Abbildung 2.21:Darstellung der Interaktion aus Abb. 2.20 in einem Kollaborationsdia-gramm. Die zeitliche Folge der Botschaften kann in dieser Diagrammartdurch sogenannte Sequenznummern gekennzeichnet werden.
2.3. DIAGRAMME 28
Chart Name : New State DiagramChart Filename : ZD-Bestellung.VobChart Type : UML State Diagram
aktiv
Aufnahme Autorisierung
Warten aufVollständigkeit
lieferbar
abgeschlossen
Aufnahme Autorisierung
Warten aufVollständigkeit
lieferbar
abgeschlossen
Bestellung(kunde)
autorisiere
autorisiert
vollständig
geliefert
BestLöschen
Abbruch/BestellungStornieren
Abbildung 2.22: Zustandsautomat, dessen Zustand „aktiv“ ein Zustandsautomat ist.
29 KAPITEL 2. EINE ÜBERSICHT
Neuer Kunde?
Kundendaten erfragenund eingeben
Kundendaten suchen
Kundendaten überprüfen
[ja] [nein]
[gefunden]
[nicht gefunden]
Abbildung 2.23:Dieses Aktivitätsdiagramm modelliert einen Ablauf, wie er z.B. im An-wendungsfall „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 Komponentendiagrammzeigt die Organisation und Abhängigkeiten einer Menge vonKomponenten. Da eine Komponente Klassen realisiert, stellt das Komponentendiagrammeine 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). Ineinem Einsatzdiagramm können Computer und andere Geräte sowie ihre Verbindungenals Knoten (siehe Seite 18, Abb. 2.8) und Linien visualisiert werden. Mit diesen Knotensind häufig (ausführbare) Komponenten assoziiert. Verteilungsdiagramme eignen sich zurVisualisierung 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 ei-nes Systems aus mehreren Perspektiven (z.B. aus einer Black-Box-Sicht oder aus einerinneren, strukturellen Sicht). Jede in einen Systementwicklungsprozeß involvierte Per-son (Analysierer, Designer, Tester, Benutzer, Projektmanager) betrachtet das System zuunterschiedlichen Zeitpunkten unter einem bestimmten Aspekt (z.B. grob konzeptionelloder 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 Sy-stem 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.EineSichtist eine Abstraktion, die Diagramme enthält. Jedes Diagramm wiederum hebteinen 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], Seite15): Anwendungsfallsicht, logische Sicht, Prozeßsicht, Komponentensicht, Verteilungs-sicht.
31 KAPITEL 2. EINE ÜBERSICHT
2.4.1 Anwendungsfallsicht
Die Anwendungsfallsichtbeschreibt die Funktionalität des Systems. Diese Sicht ist fürKunden, Entwickler und Tester gedacht und wird durch Anwendungsfall-, Interaktions-,Zustands- und Aktivitätsdiagramme beschrieben. Die Anwendungsfallsicht nimmt unterden Sichten eine zentrale Stellung ein, da ihr Inhalt die Grundlage für die anderen Sichtenbildet. Ziel der Systementwicklung ist es, die in der Anwendungsfallsicht beschriebeneFunktionalität zu realisieren (neben nicht-funktionalen Eigenschaften). Diese Sicht wirdauch benutzt, um das fertige System anhand der Anforderungen und gewünschten Abläu-fe zu verifizieren. Die statischen Aspekte dieser Sicht werden durch Anwendungsfalldia-gramme und die dynamischen durch Interaktions-, Zustands- und Aktivitätsdiagrammemodelliert.
2.4.2 Logische Sicht
Die logische Sicht(Entwurfssicht) beschreibt wie die in der Anwendungsfallsicht ermit-telte Funktionalität zur Verfügung gestellt wird. Diese Sicht ist hauptsächtlich für Ent-wickler gedacht. Im Gegensatz zur Anwendungsfallsicht zeigt diese Sicht das Innere desSystems. Sie beschreibt die statische Struktur (Klassen, Objekte und ihre Beziehungen)und die Kollaboration (Zusammenarbeit) von Systemelementen. Die statische Strukturwird durch Klassen- und Objektdiagramme beschrieben, die dynamische Sicht wird durchZustands-, Aktivitäts- und Interaktionsdiagramme modelliert.
2.4.3 Prozeßsicht
Die Prozeßsichtmodelliert mit Hilfe von Prozessen und Threads die Nebenläufigkeit undSynchronisationsmeachnismen des Systems. Diese Sicht dient primär der Beschreibungder Performance, Skalierbarkeit und des Durchsatzes des Systems. Die statischen unddynamischen Aspekte der Sicht werden durch die gleichen Diagramme wie in der logi-schen Sicht beschrieben, jedoch mit einer Fokussierung auf aktive Klassen, da diese dieProzesse und Threads darstellen.
2.4.4 Komponentensicht
Die Komponentensicht(Realisierungssicht, Implementationssicht) stellt die Komponen-ten, aus denen das Systems zusammengestellt wird, und ihre Abhängigkeiten dar. Weiterbeschreibt diese Sicht das Management der Versionsfreigaben (Releases). Die statischenMerkmale werden in Komponentendiagrammen, die dynamischen Merkmale werden inInteraktions-, Zustands- und Aktivitätsdiagrammen dargestellt.
2.5. VIER-SCHICHTEN METAMODELL-ARCHITEKTUR 32
2.4.5 Verteilungssicht
Die Verteilungssicht(Einsatzsicht) zeigt die physische Verteilung des Systems. In denDiagrammen dieser Sicht wird modelliert, wie die Knoten des Systems (Computer undandere Geräte) verbunden sind und welchen Knoten welche Komponenten zugeordnetsind. Diese Sicht ist für Entwickler, Tester und Administratoren vorgesehen, und wirddurch Einsatzdiagramme (Verteilungsdiagramme) dargestellt.
2.5 Vier-Schichten Metamodell-Architektur
Die UML ist innerhalb eines vier-Schichten-Modells mit den folgenden Schichten (Ab-straktionsebenen) definiert: Meta-Metamodell, Metamodell, Modell und Benutzermodell(siehe [OMG99], Seite 2-5).
Schicht Beschreibung Anmerkungen
Meta-Metamodell
Diese Abstraktionsebene wirdbenutzt, um eine Sprache zurSpezifizierung eines Metamo-dells zu formalisieren.
Das Konzept eines „Ding“,welches alles repräsentiert wasdefiniert werden kann, wirdspezifiziert. Die Objekte, überdie in dieser Ebene gesprochenwird heißen z.B. MetaKlasse,MetaObjekt und MetaAttribut.Die Semantik dieser Objektewird in dieser Schicht festge-legt.
Metamodell Ein Exemplar eines Meta-Metamodells. Dieses Exem-plar definiert die Sprache zurSpezifizierung eines Modells.
Jedes Konzept dieser Ebene istein Exemplar eines Konzeptsdes Meta-Metamodells. Ob-jekte dieser Ebene sind z.B.Klasse, Attribut, Operation,Komponente. Mit Hilfe der inder Meta-Meta-Ebene spezifi-zierten Sprache wird hier z.B.festgelegt, was eine Klasse ist.Auf dieser Abstraktionsebenewird die UML definiert.
33 KAPITEL 2. EINE ÜBERSICHT
Schicht Beschreibung Anmerkungen
Modell Ein Metamodellexemplar, wel-ches eine Sprache zur Be-schreibung eines Informations-bereichs definiert.
Diese Schicht besteht aus denUML Modellen. In dieser Ebe-ne befinden sich die vom Be-nutzer definierten Modellele-mente, z.B. Kunde, getKonto-stand.
Benutzermodell,Benutzerobjekte,Benutzerdaten
Exemplar eines Modells. Esdefiniert einen spezifischen In-formationsbereich.
Modelle dieser Ebene werdenhäufig Objekt- oder Instanzmo-delle genannt. Objekte dieserEbene sind z.B. „Schmidt“ und„Müller“.
Das UML-Metamodell wird nicht durch eine Meta-Meta-Sprache beschrieben, son-dern durch die UML selbst, natürliche Sprache und formale Sprache (OCL, Objekt Cons-traint Language).
Diese vierschichtige Architektur ermöglicht eine Verbindung zu anderen vierschich-tigen Architekturen der OMG (Object Management Group), z.B. der OMG Meta-Object-Facility (MOF).
2.6 Erweiterungsmechanismen
Die Erweiterungsmechanismen sind in der Metamodellebene beschrieben und sind somitBestandteil der UML, d.h. die Benutzer der UML können diese Mechanismen benutzen,ohne von der Existenz der Metaebene zu wissen. Drei Erweiterungsmechanismen sind imMetamodell beschrieben: Stereotypen, Eigenschaftswerte und Zusicherungen.
2.6.1 Stereotypen
Stereotypenbieten die Möglichkeit, das Vokabular der UML zu erweitern. Unter einemStereotyp kann man sich einen Metatyp vorstellen, mit dem (Sprach-) Elemente der UMLauf einer höheren Ebene klassifziert werden. Z.B. könnte man Klassen, die zu einerBenutzerschnittstelle gehören, mit dem Stereotyp «GUI» markieren. «GUI» bezeichnetdann eine Klasse mit speziellen Eigenschaften (z.B. existieren ihre Objekte nur zur Lauf-zeit), bestimmter Semantik und eigener Notation (jedes Stereotyp kann durch ein eigenesSymbol dargestellt werden). Das Stereotyp «GUI» bezeichnet somit eine andere Art einerKlasse und ist sogesehen eine Erweiterung des Vokabulars der UML. Da ein Stereotyp aufeinem existierenden Sprachelement basiert, welches im Metamodell definiert sein muß,sind die Erweiterungsmöglichkeiten durch Stereotypen geringer als die Möglichkeitengegenüber einer echten Erweiterung des Metamodells.
2.6. ERWEITERUNGSMECHANISMEN 34
In der einfachsten Form wird das Stereotyp in franz. Anführungszeichen in Kombina-tion mit dem Basiselement dargestellt. So wurde in Abb. 2.3 das Interface als Stereotypeiner Klasse dargestellt. Alternativ kann das Stereotyp durch ein mit dem Stereotypenassoziierten 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 Modellele-menten der UML (inklusive den stereotypisierten) neue Eigenschaften hinzufügen. EinEigenschaftswertist ein Metadatum. Sein Wert bezieht sich auf das Element selbst, nichtauf seine Instanzen. In der einfachsten Form wird ein Eigenschaftswert als Zeichenkette,eingeschlossen von geschweiften Klammern, unter dem Namen des entsprechenden Ele-ments dargestellt. Die Zeichenkette besteht aus einem Namen (tag, Markierung), einemTrennzeichen „= “und einem Wert. Bei Eindeutigkeit ist der Wert ausreichend.
Beispielsweise können Modellelemente mit einer Markierung „Autor“ versehen wer-den, dessen Wert den Autor des Modellelements bezeichnet:
{ Autor = Schubert}.
2.6.3 Zusicherungen
Mit Zusicherungen(constraints, Einschränkungen) kann man die Semantik von Modell-elementen erweitern oder bestehende Regeln ändern. Eine Zusicherung ist eine Bedin-gung, die eingehalten werden muß, damit das Modell konsistent bleibt. Ein Zusicherung
Person
Geschlecht : {männlich, weiblich}
0..1
0..1
+Ehefrau
+Ehemann
{self.ehefrau.geschlecht=weiblich and self.eheman.geschlecht=männlich}
0..1
0..1
Abbildung 2.24: Eine Zusicherung, formuliert in OCL (Object Constraint Language)
wird als Zeichenkette, eingeschlossen von geschweiften Klammern, nahe dem entspre-chenden Element dargestellt. Die Zusicherung kann einen beliebigen Text enthalten. Zu-sicherungen 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 mehrals 100 Metaassoziationen. Wegen dieser Komplexität ist das Metamodell hierarchisch inmehrere logische Pakete aufgeteilt (Abb. 3.1), die jeweils zusammengehörige Elementeenthalten.
Das Foundation-Paket (Fundament) definiert die Basis der UML. Dieses Paket enthältdie wichtigsten strukturellen Elemente (z.B. Klassen), grundlegende Verhaltensmerkmale(Operationen und Methoden) und Datentypen, die von der UML benutzt werden. Weiterwerden in diesem Paket die Erweiterungsmechanismen der UML definiert.
Weitere Verhaltenselemente werden im Paket Behavioral Elements definiert: Anwen-dungsfälle, Kollaborationen, Interaktionen, Zustandsautomaten und Aktivitätsgraphen.
Im Paket Model Management wird spezifiziert, wie Modellelemente z.B. in Paketeorganisiert werden.
Im Rahmen dieser Arbeit werden die wesentlichen Pakete und Konzepte des Meta-modells beschrieben. So fehlt neben dem Modell-Management-Paket auch das Konzeptder 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 In-formationen enthalten, die in anderen Diagrammen und Sichten wiederverwendet werdenkönnen. Die vollständige und offizielle Beschreibung befindet sich in [OMG99] bzw. dennachfolgenden aktuelleren Dokumenten, die auf der Homepage der UML Revision TaskForce (RTF) (http://uml.systemhouse.mci.com) veröffentlicht werden.
In den folgenden Abschnitten wird vor der Definition der Elemente des Metamodellsjeweils 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) de-finiert die Basis-Konzepte: Klassifizierer (eine Verallgemeinerung von Klassen, Interfa-ces, Komponenten, Knoten und Datentypen), strukturelle und dynamische Merkmale von
35
3.1. FUNDAMENT 36
Behavioral Elements
Common Behavior
Collaborations Use Cases State Machines
Activity Graphs
Model Management
Foundation
Data Types
Core Extension Mechanisms
Abbildung 3.1:Aufteilung des UML-Metamodells in Pakete. Stärker zusammengehörigeElemente sind in Pakete zusammengefaßt. Das Paket Model Managemententhält keine weiteren Pakete.
37 KAPITEL 3. METAMODELL
Core
Data Types
Extension Mechanisms
Abbildung 3.2: Pakete des Fundaments und ihre Abhängigkeiten
Klassifizierern (Attribute, Operationen, Methoden) und Beziehungen (Assoziationen, Ge-neralisierungen, Abhängigkeiten) zwischen Modellelementen. Die Erweiterungsmecha-nismen der UML (Stereotypen, Zusicherungen und Eigenschaftswerte) werden im PaketExtension Mechanisms definiert. Das Paket Data Types definiert Datentypen (der Meta-modellebene), 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 weitereMetaklassen dienen. Abstrakte Metaklassen sind z.B.ModelElement, Feature (Merk-mal) undGeneralizableElement. Sie dienen der Zusammenfassung von gemeinsamenMerkmalen der Sprachelemente der UML. Das Konstrukt „Klassifizierer“ (Klasse, Inter-face usw.) wird in Abschnitt 3.1.1.2 konkretisiert. In Abschnitt 3.1.1.3 werden Asso-ziation und Generalisierung, und in Abschnitt 3.1.1.4 werden Abhängigkeitsbeziehungendefiniert.
3.1.1.1 Backbone
In diesem Abschnitt werden zuerst die BegriffeKlasseundGeneralisierungerläutert, dadas Metamodell im wesentlichen aus einer Klassenhierarchie besteht.
Vereinfacht ausgedrückt besteht die UML aus Modellelementen, die graphisch darge-stellt werden (z.B. Klassen, Beziehungen zwischen Modellelementen, Operationssignatu-ren). Die folgenden Erläuterungen und Beispiele zeigen die Komplexität der Zusammen-hänge zwischen den Modellelementen der UML, die das Metamodell der UML erfassenmuß.
3.1. FUNDAMENT 38
Generalisierung Eine Klassedient der Deklaration von Attributen, Operationen undMethoden1, die die Struktur und das Verhalten von Objekten2 beschreiben. EineGene-ralisierung (Abb. 3.3) ist eine Abstraktionsmöglichkeit, die dazu dient, Ähnlichkeitenzwischen Klassen durch allgemeinere Klassen zu beschreiben und gleichzeitig ihre Un-terschiede zu erhalten. Eine Generalisierung ist eine Relation zwischen einer Klasse undeiner oder mehreren spezialisierten Versionen dieser Klasse. EinDiskriminator ist einAttribut einer Generalisierung, welches die durch die Generalisierung abstrahierte Eigen-schaft beschreibt. Eine Generalisierungsbeziehung kann weitere Eigenschaften besitzen,in Abbildung 3.3 z.B. die Zusicherungdisjunkt. Die Klasse, die spezialisiert wird, heißtOberklasseund jede spezialisierte Klasse heißtUnterklasse. Synonyme fürOberklassesind Basisklasse, Vorfahr, Superklasseund (engl.) parent. Synonyme fürUnterklassesindNachkomme, 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 istViereck einedirekteOberklasse vonParallelogramm und ei-ne Oberklasse vonRechteck und Quadrat. Umgekehrt istParallelogramm eine di-rekteUnterklasse vonViereck. Rechteck undQuadrat sind weitere Unterklassen vonViereck.
Bei der Modellierung werden Merkmale wie z.B. Attribute, Operationen und die Be-teiligung an Assoziatonen, die für eine Gruppe von Klassen gelten, einer Oberklasse zu-gewiesen und von den einzelnen (Unter-) Klassen gemeinsam genutzt. Die Unterklassen„erben“ die Merkmale ihrer Oberklassen. Dieser Mechanismus wirdVererbunggenannt.Vererbung und Generalisierung werden häufig synonym verwandt, hier bezeichnet Gene-ralisierung die Relation und Vererbung den Mechanismus. Andere Synonyme für Gene-ralisierung sindSpezialisierungund Erweiterung. So wird z.B. in der Sprache Java dasSchlüsselwortextendszur 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 KlasseGeomFigur u.a. die MerkmaleistSichtbar,anzeigen und ist mit der KlassePunkt assoziiert. Alle Unterklassen vonGeomFigurerben diese Merkmale.
Bei dieser Form der Assoziation wird ein Punktobjekt als existenzabhängiges Teileiner geometrischen Figur angesehen. Dies bedeutet, daßPunkt ein Merkmal vonGeom-Figur ist.
Viereck kanndirekte Exemplarebesitzen, d.h. es kann ein konkretes Exemplar derKlasse existieren, welches nur die Merkmale vonViereck besitzt (siehe auch Instan-tiierung, Seite 41). Die OperationberechneFläche ist in der KlasseGeomFigur alsabstract gekennzeichnet, da nicht vorgesehen ist, eine Operation zu implementieren,welche die Fläche aller geometrischen Figuren berechnet. Daher kann es keine direkten
1Operationen und Methoden definieren Verhaltensmerkmale, die ein Objekt einer Klasse besitzt. EineOperation deklariert die Signatur eines Verhaltensmerkmals, Methoden implementieren das Merkmal.
2In der UML bezeichnet ein Objekt ein Exemplar einer Klasse.
39 KAPITEL 3. METAMODELL
GeomFigur
sichtbar : Boolean
anzeigen()entfernen()bewegeRel(x : Integer, y : Integer)berechneFläche()istSichtbar() : Boolean
Punkt
x : Integery : Integer
getX() : IntegergetY() : Integer
+Punkt
Ellipse
anzeigen()entfernen()berechneFläche()
Kreis
Dreieck
anzeigen()entfernen()berechneFläche()
Viereck
anzeigen()entfernen()berechneFläche()
Rechteck
Parallelogramm
Raute
Quadrat
Figurenform{disjunkt}
Diskriminator
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.
{abstract}
{abstract}{abstract}
Abbildung 3.3:Von unten nach oben betrachtet lagern Unterklassen gemeinsame Merk-male in Oberklassen aus. Von oben nach unten betrachtet erben Unter-klassen die Merkmale ihrer Oberklassen. Deshalb wird diese Strukturauch Vererbungshierarchie genannt.
3.1. FUNDAMENT 40
Exemplare der KlasseGeomFigur geben, die aus diesem Grund alsabstrakte Klassebe-zeichnet wird. Die Unterklassen vonGeomFigur können diese Operation implementieren.So erbt z.B. die KlasseViereck die Deklaration der OperationberechneFläche und im-plementiert diese. Klassen mit dieser Eigenschaft werdenkonkrete Klassengenannt. Eindirektes Exemplar einer (konkreten) Klasse ist einindirektes Exemplardieser Klasse undaller Oberklassen dieser Klasse.
Das Grundprinzip, welches bei der Konstruktion von Generalisierungsbeziehungenangewandt wird, heißtSubstitutionsprinzip: Ein Exemplar einer Unterklasse kann überalldort verwendet werden, wo ein Exemplar einer Oberklasse erwartet wird. Dieses Prin-zip ermöglicht es, Methoden für eine Oberklasse zu schreiben und diese Methoden aufExemplare der Unterklassen anzuwenden. Nach diesem Prinzip sollte in Abbildung 3.3z.B. die OperationberechneFläche der KlasseViereck so implementiert werden, daßsie auf jede Unterklasseninstanz anwendbar ist.
Eine Unterklasse kann eine Methode einer Oberklasseüberschreiben, indem sie eineOperation mit der gleichenSignaturdeklariert. Zwei Operationssignaturen sind gleich,wenn die Operationen den gleichen Namen, den gleichen Rückgabetyp sowie die gleicheAnzahl und Reihenfolge von Parametertypen besitzen. So überschreibt z.B. die Metho-de berechneFläche der KlasseQuadrat die Methode ihrer Oberklasse. Dabei sollteaber nicht die Signatur der Operation (Anzahl und Argumente einer Operation sowie derRückgabetyp) verändert werden. Wird die MethodeberechneFläche auf ein Objekt derKlasseQuadrat angewandt, sorgt ein Mechanismus der Implementationssprache dafür,daß die „richtige“ Methode auf das Objekts angewandt wird (Polymorphismus). Die Be-dingung der Beibehaltung der Signatur eines Merkmals (hier Operation) ermöglicht es,den Programmcode lokal innerhalb einer Klasse zu optimieren, ohne den restlichen Co-de zu verändern. Daher sollte ein Merkmal niemals so überschrieben werden, daß eineInkonsistenz mit der Signatur oder der Semantik des ursprünglich geerbten Merkmalsentsteht. Eine Unterklasse ist eine Spezialisierung ihrer Oberklasse und sollte in jederHinsicht mit ihr kompatibel sein.
Erweiterung und Einschränkung Eine Unterklasse kann den geerbten Merkmalenneue Merkmale hinzufügen. Dies wirdErweiterung(Synonym für Spezialisierung, s.o.)genannt. Die Erweiterung ist konsistent mit dem Substitutionsprinzip. So kann z.B. dieKlasseKreis um das Merkmalradius erweitert werden.
Eine Unterklasse kann auch Vorfahrensmerkmale begrenzen oder einschränken (spe-zialisieren)3. So unterliegen z.B. die markanten Punkte eines Quadrats einer stärkerenEinschränkung als die eines Rechtecks. Diese Einschränkung ist konsistent innerhalb derVererbungshierachie, führt aber zu Problemen, wenn man z.B. eine Methode zur nicht-maß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 Qua-drat angewandt, kann das Quadrat seine „Quadrateigenschaft“ verlieren. Daher dürfen
3In UML werden Einschränkungen Zusicherungen (constraints) genannt
41 KAPITEL 3. METAMODELL
Operationen/Methoden, welche die Einschränkungen einer Klasse verletzen würden, aussemantischen Gründen nicht zugelassen werden. Eine Einschränkung impliziert, daß eineUnterklasse unter bestimmten Umständen nicht alle Operationen ihrer Oberklassen erbenkann. Diese Operationen müssen vom Designer spezifiziert werden (vgl.[R+93], Seite78).
Deskriptor und Vererbungsmechanismus Jedes Objekt wird durch einenvollständi-gen Klassendeskriptorbeschrieben. Ein vollständiger Deskriptor enthält eine Beschrei-bung aller Attribute, Assoziationen und Operationen, die das Exemplar enthält.
In einer objektorientierten Sprache wird die Beschreibung eines Objekts inkremen-tell aus mehreren Segmenten, entsprechend der Vererbungshierarchie, aufgebaut. Jedes(generalisierbare) Modellelement enthält eine Liste (Segmentdeskriptor) von Merkmalenund Beziehungen, die es den geerbten Merkmalen und Beziehungen hinzufügt. Der Ver-erbungsmechanismus definiert, wie ein Deskriptor aus den Segmentdeskriptoren erzeugtwird. Jedes Modellelement vererbt Zusicherungen. Klassen vererben u.a. Attribute, Ope-rationen, Methoden und die Teilnahme an Assoziationen. Ein vollständiger Deskriptoreines Exemplars enthält die Vereinigung des Segment-Deskriptors seiner Klasse mit denSegment-Deskriptoren der Vorfahrensklassen.
Bei einem Klassifizierer darf kein Attribut in mehr als einem Segment deklariert wer-den. Eine Methode kann in mehreren Segmenten deklariert werden. Eine Methode einesSegments überschreibt und ersetzt eine Methode der gleichen Signatur, die durch einenVorfahren deklariert wurde. Die Zusicherungen eines vollständigen Deskriptors ergebensich entsprechend aus den Zusicherungen der Vorfahren. Sind die Zusicherungen inkon-sistent, dann ist es auch das Modell. In jeder Vereinigung der Segmentdeskriptoren einerKlasse muß zu jeder Methode eine entsprechende Operation existieren. Im Falle einerkonkreten Klasse muß zu jeder Operation des vollständigen Deskriptors eine entspre-chende Methode existieren.
Instantiierung Ein Modell dient zur Beschreibung der möglichen Zustände eines Sys-tems und dessen Verhaltens. Der Zustand eines Systems beinhaltet Objekte, Werte undLinks (Verknüpfungen). EineInstantiierungist das Erzeugen eines Exemplars (bzw. einerInstanz). EinObjektist ein Exemplar einer Klasse, einWert ist ein Exemplar eines Attri-buts und einLink ist ein Exemplar einer Assoziation. Jedes Objekt wird durch einen voll-ständigen Klassendeskriptor beschrieben. Die Klasse, die diesem Deskriptor entspricht,ist die direkte Klassedes Objekts. Ebenso hat jeder Link eine direkte Assoziation undjeder Wert einen direkten Datentyp. Ein Exemplar ist eindirektes Exemplareines Klas-sifizierers (z.B. Klasse, Komponente), von dem der vollständige Deskriptor stammt. EinExemplar ist ein indirektes Exemplar dieses Klassifizierers und jeder seiner Vorfahren.
Der Dateninhalt eines Objekts enthält für jedes Attribut des vollständigen Deskriptorseinen 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 : PunktChart Name : New Object DiagramChart Filename : C:\Home\Stephan\vuml\objUntitled2.VobChart Type : UML Object Diagram
Abbildung 3.4:Visualisierung eines Links. Quadrat1 ist eine indirektes Exemplar vonQuadrat, Rechteck, Parallelogramm, Viereck undGeomFigur
Der Zustand eines Systems ist ein gültiger Systemzustand, wenn jedes Exemplar eindirektes Exemplar eines Elements des Systemmodells ist und alle Zusicherungen des Mo-dells von den Exemplaren erfüllt werden. Mit den Verhaltenselementen der UML könnenSequenzen gültiger Systemzustände beschrieben werden.
Klasse Eine Klassedeklariert Attribute, Operationen und Methoden, die die Strukturund das Verhalten von Objekten vollständig beschreiben. Alle Objekte einer Klasse habenAttributwerte und Operationen, die zum vollständigen Klassendeskriptor passen.
Wenn eine Klasse zur Erzeugung eines neuen Objekts instantiiert wird, wird diesesObjekt mit einem Attributwert für jedes Attribut aus dem vollständigen Klassendeskriptorinitialisiert. Das Objekt wird ebenfalls mit einer Verbindung zu einer Liste von Methodendes Klassendeskriptors initialisiert und am Ende wird die Identität des neuen Objekts anden Erzeuger übermittelt. Die Identität jedes Exemplars in einem wohlgeformten Systemist einmalig und wird automatisch erzeugt.
Wird eine Klasse alsroot spezifiziert, kann sie keine Unterklasse einer anderen Klas-se sein, wird sie alsleaf spezifiziert, kann sie keine Oberklasse sein.
Der Gültigkeitsbereich(ownerScope) eines Merkmals einer Klasse gibt an, ob jedesObjekt einen eigenen Wert für dieses Merkmal besitzt (instance) oder ob es nur einenWert des Merkmals für alle Objekte der Klasse gibt (classifier)4.
Jedes deklarierte Attribut einer Klasse hat eine Sichtbarkeit und einen Typ. DieSicht-barkeitgibt an, ob das Attribut von Objekten anderer Klassen „gesehen“ und benutzt wer-den 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 Typeines Attributs spezifiziert dessen Wertebereich. Ein Attribut kann Default-Werte deklarieren und festlegen, wie viele Attributwerte mit jedem Attribut verbundenwerden (Kardinalität). Die Modifizierbarkeit der Attributwerte kann angegeben wer-den. DieModifizierbarkeitkann uneingeschränkt sein (changeable), unterbunden wer-den (frozen) oder derart eingeschränkt werden, daß nur noch Attributwerte hinzugefügtwerden können5 (addOnly).
4classifier entspricht „static“ in C++.5Bei einer Kardinalität der Attribute> 1.
43 KAPITEL 3. METAMODELL
Für jede Operation werden der Name der Operation, die Typen der Parameter, dieRückgabetypen sowie ihre Sichtbarkeit angegeben. Eine Operation kann die Spezifikati-on ihrer Effekte beinhalten. Diese Spezifikation kann auf verschiedene Arten beschriebenwerden, z.B. durchVor- undNachbedingungen, Pseudo-Code oder (beliebigen) Text. Zueiner Operation kann angegeben werden, ob ihre Anwendung den Zustand eines Objektsändert (isQuery) und ob die Operation in Unterklassen durch eine andere Methode reali-siert werden kann.
EineMethoderealisiert eine Operation, besitzt die gleiche Signatur wie die Operati-on und einen Rumpf, der die Spezifikation realisiert. Jede Methode implementiert eineOperation, die in der Klasse oder in einem Vorfahren der Klasse deklariert wurde. EineOperation kann mehrfach in den Segmentdeskriptoren der Klasse und ihren Vorfahren de-klariert werden. Dabei muß die Beschreibung der Operation, mit Ausnahme derGenerali-sierungseigenschaften(isAbstract, isRoot, isLeaf) und derisQuery-Eigenschaft,die von Nachkommen verschärft werden darf, mit der Beschreibung in den Segmentde-skriptoren übereinstimmen. Eine Methode, die eine Operation implementiert, muß diegleiche Signatur (Name, Parameteranzahl, -folge und -typen) wie die Operation besitzenund dieisQuery-Eigenschaft beachten.
Der einer Klasse in einer Assoziation gegenüberliegende Rollenname kann als Pseu-doattribut der Klasse angesehen werden. Für dieses Pseudoattribut wird wie bei einemnormalen Attribut eine Sichtbarkeit spezifiziert. Unter Berücksichtigung dieser Sichtbar-keit wird die Assoziation an Unterklassen vererbt.
Ein Interfaceist ein generalisierbares Modellelement, welches eine Sammlung vonOperationssignaturen enthält. Eine Klasse kann Interfaces realisieren. Dies bedeutet, daßjede Operation aus dem vollständigen Deskriptor eines Interfaces für jedes realisierte In-terface im vollständigen Deskriptor der Klasse mit der gleichen Signatur existieren muß.Ein Interface kann durch mehrere Klassen realisiert werden, d.h. die Operationen einesInterfaces werden in mehreren Klassen mit der gleichen Signatur deklariert und imple-mentiert.
Eine Klasse kann andere Elemente, z.B. Klassen, Interfaces und Assoziationen, ent-halten und ist für diese Elemente einNamensraum. Der Inhalt einer Klasse, der an eineandere 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 Me-tamodell istElement die oberste Metaklasse in der Metaklassenhierarchie.Element isteine abstrakte Metaklasse mit zwei direkten Unterklassen: ModelElement und Presenta-tionElement.
3.1. FUNDAMENT 44
Ele
men
t
Gen
eral
izab
leE
lem
ent
isR
oot :
Boo
lean
isLe
af :
Boo
lean
isA
bstr
act :
Boo
lean
Attr
ibut
e
initi
alV
alue
: E
xpre
ssio
n
Met
hod
body
: P
roce
dure
Exp
ress
ion
Ope
ratio
n
conc
urre
ncy
: Cal
lCon
curr
ency
Kin
dis
Roo
t : B
oole
anis
Leaf
: B
oole
anis
Abs
trac
t : B
oole
an
*1
*
+spe
cific
atio
n
1
Ele
men
tOw
ners
hip
visi
bilit
y : V
isib
ility
Kin
d
Nam
espa
ceC
onst
rain
t
body
: B
oole
anE
xpre
ssio
n
Mod
elE
lem
ent
nam
e : N
ame
0..1
*
+nam
espa
ce
0..1
+ow
nedE
lem
ent*
*
1..*
+con
stra
int *
+con
stra
ined
Ele
men
t
1..*
{ord
ered
}
Beh
avio
ralF
eatu
re
isQ
uery
: B
oole
an
Fea
ture
owne
rSco
pe :
Sco
peK
ind
visi
bilit
y : V
isib
ility
Kin
d
Str
uctu
ralF
eatu
re
mul
tiplic
ity :
Mul
tiplic
itych
ange
abili
ty :
Cha
ngea
bleK
ind
targ
etS
cope
: S
cope
Kin
d
Par
amet
er
defa
ultV
alue
: E
xpre
ssio
nki
nd :
Par
amet
erD
irect
ionK
ind
0..1
*
0..1
+pa
ram
eter
*
{ord
ered
}C
lass
ifier
*
1
+fe
atur
e*
{ord
ered
}
+ow
ner
1
*
1
*
+ty
pe
1
*
1
*
+ty
pe1
Abbildung 3.5:Backbone: Dieses Diagramm zeigt die allgemeinsten Klassen des Me-tamodells. Klassen, deren Klassenname kursiv dargestellt werden, sindabstrakte Klassen. Exemplare konkreter Klassen sind Sprachelemente,die auf der Modellebene sichtbar sind.
45 KAPITEL 3. METAMODELL
Element
PresentationElementModelElement
name : Name**
+presentation
*
+subject
*
Abbildung 3.6: Element, die allgemeinste Klasse im Metamodell
Jedes Element besitzt den vordefinierten Eigenschaftswertdocumentation:Eigenschaftswert Semantik
documentation Ein Kommentar, eine Beschreibung oder eine Erläuterung desElements
PresentationElement EinPräsentationselement(Abb. 3.6) repräsentiert ein odermehrere Modellelemente, die durch Text oder Graphik dargestellt werden. Die abstrakteMetaklassePresentationElement ist die Basis aller Metaklassen, die der Präsentationdienen. Die (nicht definierten) Unterklassen vonPresentationElement sind für dieBenutzung durch ein Werkzeug vorgesehen.
Im folgenden wird mit Pseudoattribut der Rollenname der gegenüberliegenden Klasseeiner Assoziation bezeichnet.
Pseudoattribut Semantik
subject Bezeichnet ein Modellelement, welches durch das Präsentati-onselement dargestellt wird.
ModelElement Ein Modellelementist eine Abstraktion eines Elements des zu mo-dellierenden Systems. Die abstrakte MetaklasseModelElement ist die Basis für alle Me-taklassen, die der Modellierung dienen.
Attribut Semantik
name Name des Modellelements innerhalb seines Namensraums
Pseudoattribut Semantik
presentation (Abb. 3.6) Bezeichnet ein Präsentationselement, welches dasModellelement darstellt.
3.1. FUNDAMENT 46
Pseudoattribut Semantik
namespace (Abb. 3.7) Bezeichnet den Namensraum, der das Modellele-ment enthält. Jedes Modellelement mit Ausnahme eines „Wur-zelelements“ muß entweder zu genau einem Namensraum ge-hören oder ein Teil eines anderen Modellelements (virtuellerNamensraum) sein.
constraint (Abb. 3.8) Zusicherung, die das Modellelement erfüllen muß,damit das Modell wohldefiniert ist.
ModelElement
name : Name
Namespace
*
0..1
+ownedElement *
+namespace 0..1
ElementOwnership
visibility : VisibilityKind
Abbildung 3.7: Namensraum
Namespace Ein Namensraum(Abb. 3.7) ist einModelElement und enthält beliebigviele Modellelemente. Die Namen dieser Modellelemente, ausgenommen Assoziationenund Generalisierungen, müssen innerhalb ihres Namensraums eindeutig sein.
Jede Assoziation muß eine eindeutige Kombination des Assoziationsnamens und derbeteiligten Klassifizierer sein. Jedes Modellelement gehört zu maximal einem Namens-raum.
Die Assoziationsklasse(siehe 3.1.1.3)ElementOwnership in Abb. 3.7 ist eine Ei-genschaft der Assoziation zwischenModelElement und Namespace. Sie gibt an, obdas Modellelement außerhalb seines Namensraums sichtbar ist (public, protected,private).
Namespace ist eine abstrakte Metaklasse, deren Unterklassen (z.B.Class) zusätzlicheEinschränkungen bzgl. der Art der enthaltenen Modellelemente besitzen.
Pseudoattribut Semantik
ownedElement Modellelemente, die zum Namensraum gehören.
47 KAPITEL 3. METAMODELL
Constraint Eine Zusicherung(Abb. 3.8) ist eine an ein Modellelement gehefte-te Bedingung oder Einschränkung, die durch einen Text (Formalisierungsgrad beliebig)beschrieben wird (siehe auch 3.1.2 Erweiterungsmechanismen). Im Metamodell ist ei-
Constraint
body : BooleanExpression
ModelElement
name : Name
*
1..*
+constraint*
+constrainedElement1..*
{ordered}
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 dasModell nicht wohldefiniert. Zu einer Zusicherung gehört mindestens ein zugesichertesElement (constraindedElement). Mehrere Modellelemente einer Zusicherung sind ge-ordnet ({ordered}). Ein Modellelement kann mit beliebig vielen Zusicherungen assozi-iert sein. Ausnahme: Eine Zusicherung kann nicht auf sich selbst angewandt werden.
Die folgenden Stereotypen einer Zusicherung sind in der UML definiert, weitere kön-nen von den Benutzern hinzugefügt werden.
Stereotyp Semantik
«invariant» Eine Zusicherung, die an mehrere Klassifizierer und Beziehun-gen geheftet wird und immer gelten muß.
«postcondition» (Nachbedingung) Zusicherung, die an eine Operation angehef-tet wird und nach der Ausführung der Operation gelten muß.
«precondition» (Vorbedingung) Zusicherung, die an eine Operation angeheftetwird und vor der Ausführung der Operation gelten muß.
GeneralizableElement Ein verallgemeinerbares Element(Abb. 3.9) ist ein Mo-dellelement, welches an einer Generalisierungsbeziehung teilnehmen kann (siehe auchAbb. 3.23, Seite 63).
3.1. FUNDAMENT 48
GeneralizableElement
isRoot : BooleanisLeaf : BooleanisAbstract : Boolean
ModelElement
name : Name
Namespace
*
0..1
+ownedElement
*
+namespace
0..1
Feature
ownerScope : ScopeKindvisibility : VisibilityKind
Classifier
*
1
+feature *{ordered}
+owner
1
ElementOwnership
visibility : VisibilityKind
Abbildung 3.9: verallgemeinerbares Element und Klassifizierer
Attribut Semantik
isAbstract Falls wahr, besitzt das verallgemeinerbare Element keine di-rekten Exemplare.
isLeaf (Blatt) Falls wahr, darf das Element nicht weiter spezialisiert(vererbt) werden.
isRoot (Wurzel) Falls wahr, kann das Element keine Spezialisierungeines anderen Modellelements sein.
Classifier Ein Klassifiziererist ein Modellelement, welches Verhaltens- und Struk-turmerkmale beschreibt (Abb. 3.9, 3.10). Beispiele für Klassifizierer sind Klassen, Inter-faces und Komponenten.
Im Metamodell ist ein Klassifizierer ein Namensraum und ein verallgemeinerbaresElement, welches Merkmale (feature) enthalten kann. Als verallgemeinerbares Elementkann es Merkmale und die Teilnahme an Assoziationen (ver-)erben. Ein Klassifiziererkann in seiner Eigenschaft als Namensraum Klassifizierer (auch verschachtelt) enthalten.Auf die enthaltenen Klassifizierer können andere Klassifizierer nur unter Berücksichti-gung der Sichtbarkeit des Namensraum zugreifen (ElementOwnership).
Kein Verhaltensmerkmal der gleichen Art6 eines Klassifizieres darf die gleiche Signa-tur besitzen. Rollennamen einer Assoziation des Klassifizierers7 werden alsPseudoattri-
6Operationen und Methoden sind verschiedene Arten eines Verhaltensmerkmals7auf der gegenüberliegenden Seite eines Klassifizierers
49 KAPITEL 3. METAMODELL
buteangesehen. Die Menge der Attributnamen, der Pseudoattributnamen und die Namender enthaltenen Modellelemente eines Klassifizierers müssen eindeutig sein (hierzu ge-hören auch geerbte Modellelemente). Zu jeder als nicht-abstrakt spezifizierten Operationdes Klassifizierers muß der Klassifizierer eine Methode mit der spezifizierten Signaturenthalten.
Mehrere Stereotypen und Eigenschaftswerte eines Klassifizierers sind definiert:
Stereotyp Semantik
«metaclass» (Metaklasse) Bezeichnet einen Klassifizierer, dessen Exempla-re Klassen sind.
«powertype» (Metatyp) Bezeichnet einen Typ, dessen Exemplare Unterty-pen eines anderen Klassifizierer sind.
«process» (Prozeß) Ein Klassifizierer, der eine aktive Klasse und einenProzeß darstellt. Ein Prozeß kann nebenläufig mit anderenProzessen ausgeführt werden und besitzt einen eigenen Kon-trollfokus.
«thread» Ein Klassifizierer, der eine aktive Klasse und einen Thread dar-stellt. Ein Thread kann nebenläufig innerhalb eines Prozessesausgeführt werden. Ein Thread besitzt einen eigenen Kontroll-fokus, aber keinen eigenen Adressraum.
«utility» (Dienstklasse, Hilfsmittelklasse) Klassifizierer, dessen Attri-bute und Operationen alle die Klasse als Gültigkeitsbereichhaben ([BRJ99a], Seite 148). Hilfmittelklassen sind keineechten Klassen, sondern Sammlungen von globalen Variablenund Funktionen, die aber in Form einer Klasse notiert werden([Oes98], Seite 230).
Eigenschaftswert Semantik
persistence Der Wertpersistent (lat.: „anhaltend“) besagt, das die Le-bensdauer der Exemplare des Klassifizieres über die Laufzeitdes Programms hinausreicht und gespeichert werden sollten.transient bedeutet nicht persistent.
semantics Spezifiziert die Semantik des Klassifzierers.
Feature Ein Merkmalist eine Eigenschaft eines Klassifizierers, z.B. ein Attribut odereine Operation. Ein Merkmal (Abb. 3.10) hat einen Namen, der zur Identifizierung in-nerhalb eines Klassifizierers oder eines Exemplars dient. Ein Merkmal gehört zu genaueinem Klassifizierer (owner). Das AttributownerScope 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ürdieses Merkmal gibt, der dann für alle Exemplare des Klassifizierers gilt. Das Attributvisibility spezifiziert, ob andere Klassifizierer das Merkmal sehen und benutzen odererben können.Feature ist eine abstrakte Metaklasse.
Attribut Semantik
ownerScope instance: Jedes Exemplar des Klassifizierers hat seinen eige-nen Wert für dieses Merkmal.classifier: Es gibt nur einen Wert für alle Exemplare einesKlassifizierers.
visibility public: Jeder andere Klassifizierer (mit Sichtbarkeit auf denKlassifizierer) kann dieses Merkmal benutzen.protected: Jeder Nachkomme des Klassifizierers kann diesesMerkmal benutzen.private: Nur der Klassifizierer selbst kann das Merkmal be-nutzen.
ModelElement
name : Name
Attribute
initialValue : Expression Method
body : ProcedureExpression
Operation
concurrency : CallConcurrencyKindisRoot : BooleanisLeaf : BooleanisAbstract : Boolean
*1 *
+specification
1
BehavioralFeature
isQuery : BooleanStructuralFeature
multiplicity : Multiplicitychangeability : ChangeableKindtargetScope : ScopeKind
Feature
ownerScope : ScopeKindvisibility : VisibilityKind
Classifier
1
*
+type 1
*
*1
+feature
*
{ordered}+owner
1
Abbildung 3.10: Merkmale
51 KAPITEL 3. METAMODELL
StructuralFeature Ein strukturelles Merkmal(Abb. 3.10) ist eine statische Ei-genschaft eines Modellelements. Im Metamodell der UML (Version 1.3) istAttributedie einzige Unterklasse vonStructuralFeature. Ein strukturelles Merkmal besitzt ei-ne Kardinalität (multiplicity), die die Anzahl dieses Merkmals eines Modellelementsangibt, z.B. kann das Merkmal „IP-Adresse“ eines Computers eine Kardinalität> 1 besit-zen. Der Wertebereich eines strukturellen Merkmals wird durch einen Typ (type) spezi-fiziert. Dieser Typ kann z.B. auf der Modellebene eine benutzerdefinierte Klasse oder einExemplar eines in UML definierten Datentyps (siehe 3.1.3) sein. Die Modifizierbarkeit(changeability) gibt an, ob der Wert des Merkmals verändert werden kann, nachdemdas 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, nachdemdas Exemplar instantiiert und der Wert initialisiert wurde. Wei-tere 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 darfverändert oder entfernt werden.
targetScope instance: (default) Jeder Wert enthält eine Referenz auf einExemplar des Typs.classifier: Jeder Wert enthält eine Referenz auf einen Klas-sifizierer. Auf diese Weise können Metainformationen gespei-chert werden.
Pseudoattribut Semantik
type Bezeichnet einen durch einen Klassifizierer beschriebenenWertebereich des Merkmals. Exemplare des Klassifizie-rers bilden die Attributwerte. Der Klassifizierer muß eineKlasse (Class), ein Datentyp (DataType) oder ein Interface(Interface) sein. Zur Laufzeit kann der aktuelle Typ auchein Nachkomme sein. Der aktuelle Typ eines Interfaces ist zurLaufzeit ein Klassifizierer, der dieses Interface realisiert.Die Typen sollten im Namensraum des Besitzers des Merkmalssein.
Attribute Ein Attribut ist ein benanntes Fach innerhalb eines Klassifizierers und be-schreibt einen Wertebereich. Im Metamodell istAttribute ein Teil eines Klassifizierers,welches einen Namen besitzt (geerbt vonModelElement) und mögliche Zustände, dieExemplare des Klassifizierers annehmen können, durch einen Wertebereich (type, geerbtvonStructuralFeature) beschreibt.
3.1. FUNDAMENT 52
Attribut Semantik
initialValue Ausdruck, der den Wert des Attributs bei seiner Initialisierungbestimmt.
ModelElement
name : Name
BehavioralFeature
isQuery : Boolean
ClassifierParameter
defaultValue : Expressionkind : ParameterDirectionKind
*
0..1
+parameter *{ordered}
0..1
1 *
+type
1 *
Abbildung 3.11: Parameter
BehavioralFeature Ein Verhaltensmerkmal(Abb. 3.10, 3.11) ist ein dynami-sches Merkmal eines Klassifizierers, z.B. eine Operation oder eine Methode. Das At-tribut isQuery gibt an, ob die Ausführung/Anwendung des Merkmals den Zustand desSystems unverändert läßt. Ein Verhaltensmerkmal kann eine geordnete Liste von Parame-tern besitzen, die das Verhalten des Merkmals beeinflußen können. Die Parameter solltenunterschiedliche Namen haben und ihre Typen sollten zum Namensraum des Klassifi-zierers gehören. Ein Verhaltensmerkmal besitzt eineSignatur, die aus dem Namen desVerhaltensmerkmals 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 Zu-stand des Klassifizierers nicht, d.h. der Systemzustand bleibtebenfalls unverändert.isQuery wird benutzt, um Abfragenbzw. reine Funktionen, d.h. Funktionen ohne Seiteneffekte, zumarkieren.
53 KAPITEL 3. METAMODELL
Pseudoattribut Semantik
parameter 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 EineOperation(Abb. 3.10) spezifiziert einen Dienst, der von Exemplareneines Klassifizierers ausgeführt bzw. angefordert werden kann. Eine Operation hat eineSignatur, die aus dem Namen der Operation (geerbt vonModelElement) und Parameternbesteht.
Im Metamodell ist eine Operation ein Verhaltensmerkmal, welches auf die Exemplaredes deklarierenden Klassifizierers angewandt werden kann.
Das Attributconcurrency (Nebenläufigkeit) spezifiziert die Semantik von nebenläu-figen Aufrufen des gleichen passiven Exemplars (die die untersuchte Operation enthält).Aktive Exemplare kontrollieren den Zugriff auf ihre Operationen selbst8.
Attribut Semantik
concurrency sequential: (sequentiell) Aufrufer der Operation müssen au-ßerhalb des Exemplars koordiniert werden. Die Operation darfwährend der Ausführung nicht nocheinmal aufgerufen werden.Dies gilt für die Gesamtheit der sequentiellen Operationen ei-nes Exemplars, d.h. es dürfen auch nicht gleichzeitig zweiverschiedene sequentielle Operationen aufgerufen werden. ImFalle simultaner Aufrufe ist die Semantik und Integrität desExemplars (und damit des Systems) nicht gewährleistet.guarded: (überwacht) Gleichzeitige Aufrufe einer Operationeines Exemplars von nebenläufigen Threads sind zugelassen,aber nur eine Anforderung wird zu einem Zeitpunkt bearbei-tet, die anderen werden bis zur vollständigen Ausführung derOperation blockiert. Die Verhinderung von Deadlocks liegtin der Verantwortlichkeit des Systemdesigners. Im Falle dergleichzeitigen Ausführung sequentieller Operationen müssendie überwachten Funktionen korrekt ausgeführt werden bzw.müssen sie sich selbst blockieren.
8Ein aktives Exemplar ist ein Exemplar eineraktivenKlasse
3.1. FUNDAMENT 54
Attribut Semantik
concurrent: (nebenläufig) Wie überwachte Operationen, nurwerden die Operationen in diesem Fall sogar nebenläufig aus-geführt. Nebenläufige Operationen müssen so entworfen wer-den, daß sie im Falle nebenläufiger sequentieller oder über-wachter Operationen korrekt ausgeführt werden.
isAbstract Falls wahr, implementiert der deklarierende Klassifizierer dieOperation nicht. Die Operation muß von einem Nachfahrenimplementiert werden.
isLeaf Falls wahr, kann die Implementation von keinem Nachfahrenüberschrieben werden.
isRoot Falls wahr, kann die Klasse eine Deklaration dieser Operationmit der gleichen Signatur nicht erben.
Method EineMethode(Abb. 3.10) ist die Implementation einer Operation. Im Meta-modell ist eine Methode ein benanntes Verhaltensmerkmal eines Klassifizierers und reali-siert/implementiert eine Operation (body). Eine Methode wird durch eine Operation spe-zifiziert (specification). Eine Operation kann mehrere Methoden spezifizieren. DieSignaturen der Operation und der Methode müssen übereinstimmen. Falls die Operati-on als „query“ markiert ist, muß die Methode eine reine Funktion (ohne Seiteneffekte)sein. Die Sichtbarkeit der Methode sollte mit der Sichtbarkeit der Operation überein-stimmen. Eine Operation muß ein (geerbtes) Merkmal des Klassifizierers sein, der diesesimplementiert. 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 Verhaltensmerkmalevon Klassifizierern benutzt. Im Metamodell beschreibt ein Parameter die Deklarationeines Arguments, welches an eine Operation o.ä. übergeben wird. Jeder Parameter hat(als Modellelement) einen Namen.type gibt den Typ (ein Klassifizierer) des Parametersan. 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, umInformationen zum Aufrufer zu liefern.inout: Ein modifizierbarer Eingabeparameter.return: Rückgabeparameter.
defaultValue Ausdruck, dessen Wert genutzt wird, falls kein Argument über-geben wird.
55 KAPITEL 3. METAMODELL
Classifier
Class
isActive : BooleanDataType
Interface Node Component
*
*+deploymentLocation
* +resident
*
ModelElement
name : Name
*
*
+implementation*
+resident*
ElementResidence
visibility : VisibilityKind
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), diein anderen Paketen des Metamodells beschrieben sind.
Class Eine Klasseist eine Beschreibung einer Menge von Objekten, die sich durchgemeinsame Attribute, Operationen, Methoden, Beziehungen und Semantik auszeichnen.
Attribut Semantik
isActive true: Die Klasse ist eineaktive Klasse, d.h. ein Objekt derKlasse kontrolliert den Zugriff auf seine Operationen und At-tribute selbst. Das Objekt besitzt einen eigenen Kontrollfokusund ist nebenläufig mit anderen aktiven Objekten.false: (default) Die Klasse ist keine aktive Klasse.
isAbstract (geerbt vonGeneralizableElement)true: Die Klasse kann nicht instantiiert werden.
3.1. FUNDAMENT 56
Stereotyp Semantik
«type» Ein Typ ist eine Klasse, die einen Bereich von Exemplaren(Wertebereich) zusammen mit Operationen, die auf diese Ex-emplare anwendbar sind, definiert. Ein Typ kann Attribute undAssoziationen, aber keine Methoden enthalten.
«implementation-Class»
Bezeichnet eine Klasse, die kein Typ sondern die Implemen-tation einer Klasse in einer Programmiersprache repräsentiert.Ein Exemplar kann maximal zu einer Implementationsklassegehören. Dies ist ein Unterschied zu normalen Klassen, beidenen ein Exemplar zu mehreren Klassen gehören kann (so-wohl statisch, als auch dynamisch).
Interface Der Zweck einesInterfaceist die Sammlung von Operationen, die einenDienst spezifizieren, der von Klassifizierern angeboten wird. Interfaces bieten einen Wegzur Charakterisierung von Gruppen von Operationen.
Ein Interface ist eine Sammlung von öffentlichen (public) Operationen. Ein Inter-face kann nicht direkt instantiiert werden. Instantiierbare Klassifizierer können Interfaceszur Spezifizierung verschiedener Dienste, die von ihren Exemplaren angeboten werden,benutzen. Mehrere Klassifizierer können das gleiche Interface realisieren. Ein Interfacekann als generalisierbares Element eine Spezialisierung anderer Interfaces sein und anAssoziationen teilnehmen, vorausgesetzt, es kann die Assoziation nicht sehen (es kannnicht vom Interface wegnavigiert werden, siehe 3.1.1.3AssociationEnd). Z.B. kann ei-ne Klasse mit einem Interface assoziiert sein, die Assoziation darf aber nur von der Klassezum Interface navigierbar sein9.
DataType Ein Datentypist ein Typ, dessen Werte keine Identität haben (reine Werte).Zu den Datentypen gehören primitive Typen (z.B. integer, string) und (benutzerdefinier-bare) Aufzählungstypen (z.B. boolean).
Im Metamodell istDataType ein spezieller Klassifizierer, der nur Operationen, diereine Funktionen sind, enthalten kann.
Node Ein Knotenist ein physisches Objekt und repräsentiert Rechenkapazität, im all-gemeinen mit Speicher und Prozessfähigkeit. Im Metamodell ist ein Knoten mit einerMenge von Komponenten assoziiert, die sich auf diesem Knoten befinden (resident).
Component EineKomponenteist ein physisches, austauschbares Teil eines Systems.Es repräsentiert ein Bestandteil der Implementation des Systems, z.B. Quelltext, Bilio-thekscode, ein ausführbares Programm oder ein Skript.
9Der Sinn einer solchen Assoziation ist dem Autor verschlossen geblieben.
57 KAPITEL 3. METAMODELL
Eine Komponente kann keine anderen Komponenten beinhalten. Eine Komponentekann nur Datentypen, Interfaces, Klassen, Assoziationen, Abhängigkeiten, Zusicherun-gen, Signale, Datenwerte und Objekte implementieren (resident). Eine Komponentekann sich auf einem Knoten (deploymentLocation) befinden.
Für Komponenten sind mehrere Stereotypen vordefiniert:
Stereotyp Semantik«document» Die Komponente repräsentiert ein Dokument«executable» Die Komponente repräsentiert ein Programm, welches auf ei-
nem Knoten ausgeführt werden kann.«file» Die Komponente repräsentiert ein Dokument, welches Daten
oder Quellcode enthält.«library» Die Komponente repräsentiert eine (statische oder dynami-
sche) Bibliothek.«table» Die Komponente repräsentiert eine Tabelle einer Datenbank
3.1.1.3 Assoziation und Generalisierung
EineAssoziationdeklariert mögliche Verbindungen (links) zwischen Exemplaren von as-soziierten Klassifizierern (z.B. Klassen). Die Exemplare einer Assoziation (Links) bildeneineMenge10 von Tupeln, die aus Referenzen auf die assoziierten Exemplare bestehen.Eine Assoziation besteht aus mindestens zwei Assoziationsenden, von denen jedes miteinem Klassifizierer verbunden ist und Zusicherungen definiert, die erfüllt sein müssen,damit die Beziehung gültig ist. Die Kardinalitätseigenschaft eines Assoziationsendes spe-zifiziert, wieviele Exemplare eines Klassifizierers an einem gegebenen Assoziationsende(dasjenige, welches die Kardinalität angibt) mit einem einzigen Exemplar des Klassifizie-rers an einem anderen Ende assoziiert sein müssen (siehe Abb. 3.13). Eine Kardinalitätist ein Bereich von nicht-negativen ganzen Zahlen (Integer). Ein Assoziationsende gibtweiter an, ob die Verbindung zu dem Exemplar navigierbar ist, d.h. ob das Exemplardurch die Assoziation erreichbar ist (siehe als Beispiel Abb. 3.14).
In einer Assoziation kann die Menge der Merkmale, die eine Klasse in dieser Bezie-hung benötigt, beschränkt werden. So kann z.B. eine Klasse „Person“ mehrere Schnitt-stellen 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ön-nen auch Typen (Klassen mit dem Stereotyp «type») benutzt werden.
Eine weitere Zusicherung eines Assoziationsendes gibt an, ob die Menge der Linksauf die entsprechenden Exemplare des Assoziationsendes verändert werden dürfen. Mög-lichkeiten sind:
1. Es existiert keine Zusicherung (changeable), d.h. die Links dürfen beliebig hinzu-
10Jedes Tupel tritt maximal einmal auf (extensionale Auffassung)
3.1. FUNDAMENT 58
Person
name : String
Ort
name : String0..*1..*
+Wohnort+Einwohner
0..*1..*
Rollenname
Kardinalität
Abbildung 3.13:Beispiel einer binären Assoziation: Eine Person kann in der Rolle alsEinwohner mit beliebig vielen Wohnorten assoziiert sein. Ein Wohnorthat mindestens einen Einwohner. Die Assoziation ist beidseitig navi-gierbar (nach Konvention des Werkzeugs).
Person
name : String
Passwort
name : String0..1
+passwort
0..1
Abbildung 3.14:Eine gerichtete Assoziation, die nur von Person zu Paßwort navigierbarist.
IMitarbeiter
IManager
Person
1..1
0..*
+Vorgesetzer: IManager
+Mitarbeiter: IMitarbeiter
1..1
0..*
Abbildung 3.15: Spezifizierung von Rollen durch Interfaces
59 KAPITEL 3. METAMODELL
gefügt, entfernt und geändert werden.
2. Nachdem die Verbindung initialisiert wurde, können keine Links mehr geändertoder 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 dasLink-Ende (Exemplar eines Assoziationsendes) geheftet sind.
Durch eine weitere Zusicherung eines Assoziationsendes kann angegeben werden, obdie Exemplare an dem Assoziationsende bezüglich eines einzigen Exemplars eines ande-ren Assoziationsendes auf irgendeine Weise geordnet sein müssen (Abb. 3.16). In diesemFall müssen Operationen, die Links einfügen, verändern oder löschen, die Ordnung be-rücksichtigen. Das Sortieren von Links ist eine Optimierung aus Performancegründen,
Person
name : String
Ort
name : String0..*
+Wohnort
0..*
{addOnly,zeitlich geordnet}
Abbildung 3.16:Die verschiedenen Wohnorte einer Person zeitlich geordnet. Ist die Be-ziehung zwischen einer Person und einem Wohnort initialisiert, darf sienicht mehr entfernt werden. Die Art der Ordnung (z.B. aufsteigend) istnicht festgelegt. Vorsicht: eine Person kann nur einmal mit einem Ortassoziiert werden, d.h. ein Umzug in einen ehemaligen Wohnort kannin diesem Modell nicht erfaßt werden.
aber kein Beispiel einer logischen Ordnung, da die Sortierung keine zusätzliche Informa-tion besitzt. Die Zusicherung „zeitlich geordnet“ in Abbildung 3.16 ist ein Beispiel einerbenutzerdefinierten 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, istaber 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 Anwendungs-gebiet hat, präzisiert die UML Assoziation und Komposition genau, läßt aber bei derAggregation einen Interpretationsspielraum offen.
3.1. FUNDAMENT 60
Eine Assoziation kann eine Ganzes-Teile-Hierachie darstellen. In diesem Fall wirddas Assoziationsende, welches das Ganze darstellt, gekennzeichnet, und das andere Endeder Assoziation stellt die Teile der Aggregation dar. Nur binäre Assoziationen können Ag-gregationen sein. Eine Komposition ist eine strenge Form der Assoziation, die verlangt,daß ein Exemplar eines Teils (Komponente) zu einem Zeitpunkt nur zu maximal einerKomposition gehören darf (Abbildung 3.17). Der Besitzer der Komponente kann aller-dings ausgetauscht werden. Eine Komposition impliziert eine Übertragung der Semantik
Dokument Absatz
0..*
Satz
0..*0..* 0..*
Abbildung 3.17:Komposition: Die Teile (Komponenten) sind vom Ganzen (Kompositi-on) 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.
PersonFirma 0..* 1..*
+Arbeitgeber +Arbeitnehmer
0..* 1..*
Abbildung 3.18:Aggregation: In diesem Modell werden Arbeitnehmer als Teil einer Fir-ma angesehen.
Eine (normale) Aggregation hat weniger starke Einschränkungen. Die Teile könnenzu verschiedenen Aggregaten (dem Ganzen) gehören, die Besitzer der Teile können eben-falls ausgetauscht werden. Bei dieser Form der Aggregation impliziert das Löschen desGanzen nicht das Löschen seiner Teile (Abbildung 3.18).
Beide Arten der Aggregation definieren eine transitive, asymmetrische Beziehung.EineQualifikationsangabe(engl. Qualifier) ist ein Assoziationsattribut, dessen Werte
die Menge der Exemplare am gegenüberliegenden Ende partitionieren. In Abbildung
PersonBankktoNr
0..1ktoNr
+kunde
0..1
Abbildung 3.19:qualifizierte Assoziation: maximal ein Kunde pro Kontonummer undBank
3.19 partitioniertktoNr die Menge der Kunden, die mit einem gegebenen Exemplar vonBank assoziiert sind. Ein Exemplar bzw. ein Wert vonktoNr selektiert den zugehöri-gen Kunden (falls einer existiert). In Abbildung 3.21 kann ein Wert vonktoNr mehrereKunden selektieren. Da ein Exemplar von Bank nicht mehrfach miteinem Exemplar
61 KAPITEL 3. METAMODELL
Person
ktoNr : StringBank
0..* 0..*
+kunde
0..*0..*
Abbildung 3.20:nicht-qualifizierte Assoziation: maximal eine Kontonummer für einenKunden pro Bank
PersonBankktoNr
0..*0..*
ktoNr+kunde
0..*0..*
Abbildung 3.21:qualifizierte Assoziation: mehrere Kunden pro Konto und Bank, aller-dings kann ein Kunde nur ein Konto pro Bank haben
von Kunde assoziiert sein kann11, kann ein Kunde maximal eine Kontonummer pro Bankhaben.
Die Kardinalität der Zielseite (die zu partitionierende Seite) einer qualifizierten Asso-ziation gibt die Anzahl der Zielexemplare, die durch ein Quellexemplar und einem Wertder Qualifikationsangabe selektiert werden, an. Gebräuchliche Werte sind:
• „0..1“: Maximal ein Zielexemplar wird durch den Wert der Qualifikationsangabeselektiert, aber nicht jeder mögliche Wert muß notwendigerweise ein Exemplar se-lektieren.
• „1“: Jeder mögliche Wert der Qualifikationsangabe selektiert genau ein Zielexem-plar, daher muß der Wertebereich der Qualifikationsangabe endlich sein.
• „*“: Der qualifizierende Wert partitioniert die Zielexemplare in Teilmengen. Ersuggeriert eine Implementation, bei der durch einen qualifizierenden Wert auf eineTeilmenge der Exemplare zugegriffen werden kann.
Die Kardinalität der Qualifikationsangabe ist durch die Annahme gegeben, daß der quali-fizierende Wert unterstützt wird. Die reine Kardinalität der Quellseite ohne eine Qualifi-kationsangabe 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 istmöglich, einen Klassifizierer mehrfach zu qualifizieren (mehrere Assoziationen) und eineAssoziation mit mehreren Qualifikationsangaben an einer Seite zu versehen. Ein Beispielist in [OMG99] (Seite 3-71) angegeben.
Bei einer Assoziation zwischen zwei Klassen kann die Assoziation selbst weitere Ei-genschaften haben. Z.B. kann in einer Arbeitnehmer/Arbeitgeber-Beziehung zwischen
11Eine Assoziation ist eine Menge von Tupeln.
3.1. FUNDAMENT 62
einer Firma und einer Person eine Stelle sein, die die Eigenschaften der Beziehung zwi-schen genau einem Arbeitnehmer/Arbeitgeber-Paar beschreibt (Einstellungsdatum, Ge-halt, usw.). In der UML kann man diese Situation mit einerAssoziationsklassemodellie-ren (Abbildung 3.22). Eine Assoziationsklasse ist ein Teil einer Assoziation und model-
Firma Person
1..*0..*
+Arbeitnehmer+Arbeitgeber
1..*0..*
Stelle
eintrittsDatumgehalt
Abbildung 3.22: Assoziationsklasse:Stelle ist eine Eigenschaft der Assoziation
liert Merkmale, die zur Assoziation selbst gehören. Eine Assoziationsklasse kann nur aneine einzige Assoziation geheftet werden.
Abbildung 3.23 zeigt die Klassen des Metamodells, die die Assoziations- und Gene-ralisierungsbeziehungen darstellen.
Relationship Im Metamodell in Abb. 3.23 istRelationship eine abstrakte Klasseohne eigene Semantik, die nur aus technischen Gründen vorhanden ist.
Association EineAssoziationdefiniert eine strukturelle Beziehung zwischen Klas-sifizierern. Ein Exemplar einer Assoziation (Link) ist ein Tupel der entsprechenden Ex-emplare (bzw. Verweise auf die Exemplare) der Klassifizierer. Eine Assoziation bestehtaus mindestens zweiAssoziationsenden, die die Verbindung zwischen der Assoziationund den Klassifizierern bilden. Jedes Asssoziationsende spezifiziert eine Menge von Ei-genschaften, die erfüllt sein müssen, damit die Beziehung gilt (auf der Modellebene). Dieassoziierten 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 reinkonzeptionellen Gründen dargestellt. Beispielsweise ist eineAssoziation zwischen zwei Unterklassen implizit, wenn ihreOberklassen bereits assoziiert sind.
Zusicherung Semantik
xor Wird auf eine Menge von Assoziationen angewandt. Sie for-dert, daß genau eine Assoziation für jedes assoziierte Exemplargilt (Beispiel: Abb. 3.28, Seite 72).
63 KAPITEL 3. METAMODELL
{ordered}
AssociationClass
Class
isActive : Boolean
GeneralizableElement
isRoot : BooleanisLeaf : BooleanisAbstract : Boolean
Generalization
discriminator : Name * 1
+generalization
*
+child
1
1*
+parent
1
+specialization
*
Association
Attribute
initialValue : Expression
AssociationEnd
isNavigable : Booleanordering : OrderingKindaggregation : AggregationKindtargetScope : ScopeKindmultiplicity : Multiplicitychangeability : ChangeableKindvisibility : VisibilityKind
2..* 1
+connection
2..* 1
* 0..1
+qualifier
*{ordered}
+associationEnd
0..1
Classifier
1 *
+type
1 *
**
+participant
*
+specification
*
Relationship
Flow
ModelElement
name : Name
*
*
+source
*
+source *
*
*
+target
*
+target *
Abbildung 3.23: Assoziations-, Generalisierungs- und Flußbeziehungen
AssociationEnd Ein Assoziationsendeist der Endpunkt einer Assoziation und ent-hält den größten Informationsanteil einer Assoziation. Jedes Assoziationsende ist Teilgenau einer Assoziation. Der Name des Assoziationsendes beschreibt dieRolle, die dieExemplare des assoziierten Klassifizierers in der Beziehung spielen. Im folgenden wer-den die Hilfsbezeichnungen aus Abb. 3.24 benutzt.
Quelle Ziel
betrachtetes Assoziationsende
.
Abbildung 3.24: Hilfsbezeichnungen für die Erläuterung des Assoziationsendes
3.1. FUNDAMENT 64
Attribut Semantik
name Der Rollennamedes Assoziationsendes. Er bezeichnet dieRolle, die der Zielklassifizierer in der Assoziationsbeziehungspielt. Dieser Rollenname repräsentiert ein Pseudoattribut desQuell-Klassifizierers, d.h. er kann auf die gleiche Art wie einAttribut vom Quell-Klassifizierer benutzt werden (unabhängigvon der Sichtbarkeit, abhängig von der Navigierbarkeit). Da-her muß der Rollenname bzgl. der Attribute und anderer Pseu-doattribute des Quell-Klassifizierers eindeutig sein.
aggregation none: Dies Ende ist keine Aggregation.aggregate: Der mit diesem Ende assoziierte Klassifizierer(Ziel) stellt das Ganze der Aggregationsbeziehung dar. DasQuellende muß den Wertnone haben.composite: Der mit diesem Ende assoziierte Klassifiziererstellt das Ganze der Kompositionsbeziehung dar. Das Quel-lende muß den Wertnone haben.
changeability Gibt an, ob ein Link vom Quellende aus verändert wer-den kann (entsprechend derchangeability-Eigenschaft vonAttribute). Die Werte vonchangeability werden als Zu-sicherungen dargestellt.changeable: Keine Einschränkungen (Default).addOnly: Links können von der Quelle hinzugefügt, aber nichtverändert werden.frozen: Nachdem das Quellobjekt erzeugt wurde, dürfen kei-ne Links hinzugefügt werden.
ordering unordered: Die Links sind nicht geordnet (Default)ordered: Die Links sind geordnet (die Ordnung selbst ist abernicht definiert)Zusätzliche Werte (z.B.sorted) werden eventuell in weite-ren Versionen definiert. Es besteht die Möglichkeit zusätzlicheWerte als Stereotypen zu definieren, die entsprechende Werk-zeuge unterstützen könnten.
isNavigable true: Ein Exemplar des Quellendes kann auf die assoziiertenExemplare des Zielendes schließen (zum Ziel navigieren). DieNavigierbarkeit eines Assoziationsendes ist unabhängig vonder Navigierbarkeit der anderen Assoziationsenden.false: nicht navigierbar.
multiplicity (Kardinalität) Bezeichnet die Anzahl der mit einem Quelle-xemplar assoziierten Zielexemplare.
targetScope instance: Der Link verweist auf ein Exemplar (default).classifier: Der Link verweist auf einen Klassifizierer.
65 KAPITEL 3. METAMODELL
Attribut Semantik
visibility Gibt die Sichtbarkeit des Assoziationsendes aus der Sicht vonKlassifizierern an, die den Quellklassifizierer „sehen“ können.public: Andere Klassifizierer können navigieren und denRollennamen in Ausdrücken benutzen, d.h. sie können denRollennamen wie ein öffentliches Attribut benutzen.protected: Nachkommen des Quellklassifizierers können na-vigieren und den Rollennamen in Ausdrücken benutzen.private: Nur der Quell-Klassifizierer kann navigieren undden Rollennamen in Ausdrücken benutzen.
Pseudoattribut Semantik
type Bezeichnet den Klassifizierer, der mit dem Assoziationsendeverbunden ist. In einem Link kann die Klasse ein Nachkom-me der Quellklasse sein, im Falle eines Interfaces kann es dierealisierende Klasse sein.
specification Bezeichnet optional Klassifizierer, die Operationen spezifizie-ren, die auf Exemplare angewandt werden können, welchedurch die Assoziation und das Assoziationsende erreicht wer-den. Diese spezifizierenden Klassifizierer bestimmen die mi-nimale Schnittstelle, die durch den assoziierten Klassifiziererrealisiert werden muß. Dies können Typen (Klassen mit demStereotyp «type») oder Interfaces sein, die Eigenschaften spe-zifizieren, die ein Exemplar in dieser Beziehung zur Verfügungstellt (vgl. Abb. 3.15).
qualifier Bezeichnet eine optionale Liste von Qualifikationsangaben.
Der Klassifizierer eines Assoziationsendes kann kein Interface oder Datentyp (Data-Type) sein, wenn ein gegenüberliegendes Assoziationsende navigierbar ist, d.h. man kannnicht von einem Interface oder Datentyp wegnavigieren.
AssociationClass Mit einer Assoziationsklassewerden Eigenschaften einer bi-nären Assoziation modelliert. Dies sind Eigenschaften, die nicht zu den beteiligten Klas-sifizierern gehören, sondern Eigenschaften der Assoziation selbst sind.
Im Metamodell ist eineAssociationClass eine Unterklasse vonClass undAsso-ciation. Daher kann eine assoziierte Klasse sowohl Merkmale als auch Assoziationsen-den haben.
Die Namen der Assoziationsenden und die Namen der strukturellen Merkmale (Attri-bute) einer Assoziationsklasse dürfen sich nicht überschneiden.
3.1. FUNDAMENT 66
Generalization EineGeneralisierungist eine Beziehung zwischen einem Super-Element (parent) und einem Sub-Element (child). Im Metamodell istGeneralizationeine Assoziation zwischen (verschiedenen) verallgemeinerbaren Elementen. Exemplaredieser Metamodellklassen beschreiben eine Vererbungshierarchie auf der Modellebene.
Attribut Semantik
discriminator Gibt an, welche Eigenschaft durch die Generalisierungsbezie-hung abstrahiert wird.
Stereotyp Semantik
«implementation» Bezeichnet eine Generalisierung, bei der das spezialisierte Ele-ment die Implementation des allgemeineren Elements erbt,aber die Implementierung der Interfaces des allgemeinerenElements weder öffentlich zugängig macht noch deren Unter-stützung garantiert. Dies verletzt das Substitutionsprinzip derGeneralisierung. Das Stereotyp kennzeichnet eine „private“Verererbung, die normalerweise nur in einer Implementations-sicht Sinn macht.
Zusicherung Semantik
disjoint (disjunkt) Dies ist eine Standardzusicherung der Generalisie-rung. Exemplare des allgemeineren Elements dürfen maximaleinen der Nachkommen als Typ haben.
overlapping (nicht disjunkt, überschneidend) Exemplare des allgemeinerenElements dürfen den Typ mehrerer (direkter) Nachfahren ha-ben. Dieses wird z.B. modelliert, wenn ein Exemplar einerKlasse Person sowohl als Kunde als auch als Lieferant in Er-scheinung treten kann, d.h. ein Exemplar kann seine Klassen-zugehörigkeit dynamisch ändern.
incomplete (nicht-vollständig) Dies ist eine Standardbedeutung der Gene-ralisierung. Es sind nicht alle direkten Nachkommen spezifi-ziert, weitere können hinzugefügt werden.
complete (vollständig) Alle direkten Nachkommen sind spezifiziert, zu-sätzliche sind nicht erlaubt.
Flow Ein Ablauf oder Fluß ist eine gerichtete Beziehung zwischen zwei Versioneneines Exemplars (zu unterschiedlichen Zeitpunkten) oder zwischen einem Exemplar undeiner Kopie des Exemplars (Abb. 3.25).
Ein Fluß kann auch eine Aktivität (siehe Abb. 3.50, Seite 117) zu oder von einemObjektflusszustand oder zwei Objektflusszuständen verbinden.
67 KAPITEL 3. METAMODELLChart Name : New Activity DiagramChart Filename : actUntitled2.VobChart Type : UML Activity Diagram
Müller : Person[Mitarbeiter]
Müller : Person[Manager]
<< become >>
Abbildung 3.25:Ablauf- oder Flußbeziehung zwischen zwei Versionen eines Exemplarszu unterschiedlichen Zeitpunkten.
Stereotyp Semantik
«become» (wird) bezeichnet eine Ablaufabhängigkeit, dessen Quelle undZiel dasselbe Exemplar zu unterschiedlichen Zeitpunkten dar-stellt. Sie verbindet zwei Versionen eines Exemplars, die sichbzgl. Wert, Zustand, Ort oder Rolle unterscheiden können.
«copy» (kopiert) bezeichnet eine Ablaufabhängigkeit, bei der dieQuelle und das Ziel unterschiedliche Exemplare mit den glei-chen Werten, Rollen und dem gleichen Zustand, aber mit ei-ner unterschiedlichen Identität sind. Eine Kopie-Abhängigkeitvon A zu B bedeutet, daß B eine exakte Kopie von A zu einemZeitpunkt ist.
3.1.1.4 Abhängigkeiten
In der UML bezeichnet eine Abhängigkeitsbeziehung eine andere Beziehung als Asso-ziation, Generalisierung, Ablauf oder Metabeziehung (die Beziehung zwischen einemKlassifizierer und einem Exemplar). Bei einer Abhängigkeit können sich Veränderun-gen unabhängiger Elemente auf abhängige Elemente auswirken. Die UML definiert vierAbhängigkeitsbeziehungen:
• Eine Abstraktionist eine Abhängigkeitsbeziehung zwischen zwei Elementen, diedas gleiche Konzept repräsentieren.
• Eine Erlaubnisgewährt einem Modellelement den Zugriff auf einen anderen Na-mensraum (z.B. ein Paket).
• Mit einer Benutzungwird dargestellt, daß ein Modellelement die Gegenwart einesanderen Modellelements benötigt.
• EineBindungist eine Beziehung zwischen einer Schablone (template) und einemModellelement.
Dependency Im Metamodell (Abb. 3.26) istDependency eine abstrakte Metaklasseohne eigene Semantik, die lediglich eine gerichtete Beziehung von abhängigen Modell-elementen (client) zu unabhängigen Modellelementen (supplier) repräsentiert.
3.1. FUNDAMENT 68
Usage
PermissionAbstraction
mapping : MappingExpression
Dependency
Binding
ModelElement
name : Name * 1..*
+supplier
*
+supplierDependency
1..*
* 1..*
+client
*
+clientDependency
1..*
0..1
1..*
0..1
+argument 1..*
Relationship
Abbildung 3.26: Die vier Arten der Abhängigkeit in der UML
Abstraction EineAbstraktionist eine Abhängigkeitsbeziehung zwischen zwei Ele-menten, die das gleiche Konzept auf unterschiedlichen Abstraktionsebenenoderaus un-terschiedlichen Sichten repräsentieren.
Im Metamodell beinhaltetAbstraction eine Abbildung (mapping) zwischenclient(abhängig) undsupplier (unabhängig). Abhängig vom Stereotyp der Abstraktion kanndie Abbildung informal oder formal und die Abhängigkeit gerichtet oder bidirektionalsein.
Die folgenden Stereotypen einer Abstraktion sind in der UML definiert:
Stereotyp Semantik
«derive» (ableiten) Eine abgeleitete Abstraktionsabhängigkeit besagt, daßdie abhängigen Elemente aus der Information der unabhängigenElemente berechnet werden können. Z.B. kann das Alter einer Per-son aus dem Geburtsdatum und dem aktuellen Datum berechnetwerden. Die Abbildung spezifiziert die Berechnung (meist formal).
69 KAPITEL 3. METAMODELL
Stereotyp Semantik
«derive»(Forts.)
Bei dieser Abstraktion sind die beteiligten Elemente nicht notwen-digerweise vom gleichen Typ. Das abhängige Element kann imple-mentiert werden, obwohl die Implementation logisch redundant ist.Effizienz ist meist der Grund für die Implementierung.
«realize» (realisiert) Eine Realisierung ist eine Beziehung zwischen einemspezifizierenden (supplier) und einem implementierenden Mo-dellelement (client), z.B. zwischen einem Interface und einerKlasse. Das implementierende Element muß die Verhaltensmerk-male des spezifizierenden Elements unterstützen. Das implemen-tierende Element muß die Deklarationen der Verhaltenselementeentweder erben oder selbst spezifizieren. Die Abbildung beschreibtdie (nicht notwendigerweise berechenbare) Beziehung zwischenden Modellementen. Realisierungen können zur Modellierung derschrittweisen Verfeinerung, Optimierung, etc. benutzt werden. Ei-ne Realisierung besitzt eine eigene graphische Notation (Kreuzungaus Generalisierung und Abhängigkeit), die durch weitere Stereo-typen ( (noch) nicht in der UML definiert) genauer beschriebenwerden kann.
«refine» (verfeinert) Eine Verfeinerung ist eine Abstraktionsbeziehung zwi-schen Modellelementen auf unterschiedlichen Abstraktionsebenen,z.B. Analyse und Design. Die Abbildung beschreibt die (nicht not-wendigerweise berechenbare und vollständige) Beziehung. EineBeschreibung der Abbildung kann als Kommentar an die Bezie-hung angeheftet werden. Die Abhängigkeit kann gerichtet oder bi-direktional sein. Die Verfeinerung wird zur Modellierung der Über-gänge zwischen Analyse und Design (u.ä. Veränderungen) einge-setzt.
«trace» (Spur) Eine Spur ist eine Abhängigkeitsbeziehung zwischen Mo-dellelementen, die sich in unterschiedlichen Modellen befinden,aber das gleiche Konzept repräsentieren. Spuren werden haupt-sächlich zur Ermittlung von Anforderungen und Änderungen zwi-schen Modellen benutzt. Diese Art der Abhängigkeit sollte voneinem Tool unterstützt werden. Da die Richtung der Abhängigkeitmeist bidirektional ist, wird sie meistens ignoriert. Die Abbildungbeschreibt die Beziehung zwischen den Modellelementen meistensinformell.
Usage Benutzungist eine Abhängigkeitsbeziehung, in der ein Element andere Ele-mente zur Implementation oder zur Erfüllung seiner Funktionalität benötigt. Auf welcheWeise das abhängige Element das unabhängige benutzt, wird durch das Stereotyp der
3.1. FUNDAMENT 70
Abhängigkeitsbeziehung definiert:
Stereotyp Semantik
«call» Call ist eine Benutzt-Abhängigkeit, dessen Quelle und ZielOperationen sind. Diese Beziehung kann auch an eine Klas-se gerichtet sein, die eine Operation enthält. In diesem Fallbedeutet die Abhängigkeit, daß eine Operation in der Klas-se existiert, die das abhängige Modellelement anwendet. Ei-ne Call-Abhängigkeit spezifiziert, daß die Quelloperation odereine Operation in der Quellklasse die Zieloperation oder eineOperation in der Zielklasse aufruft.
«create» Bezeichnet eine Abhängigkeit, bei der das abhängige Model-lelement ein Exemplar des unabhängigen Modellelements er-zeugt.
«instantiate» Abhängigkeitsbeziehung zwischen Klassifizierern, die anzeigt,daß Operationen des abhängigen Elements Exemplare des un-abhängigen Elements erzeugen.
«send» Quelle dieser Benutzt-Abhängigkeit ist eine Operation, Ziel istein Signal. Diese Beziehung sagt aus, daß die Quelle (eineOperation) ein Signal sendet bzw. senden kann. Signale wer-den im Abschnitt 3.2 Verhaltenselemente erläutert.
Permission Eine Erlaubnis garantiert einem Modellelement den Zugriff auf Ele-mente in einem anderen Namensraum. Das abhängige Element muß hierbei ein Namens-raum, z.B. eine Klasse, sein.
Stereotyp Semantik
«access» Abhängigkeit zwischen zwei Namensräumen. Der abhängi-ge Namensraum kann auf die öffentlichen (public) Anteile desunabhängigen Namensraum zugreifen.
«import» Abhängigkeit zwischen zwei Namensräumen. Der abhängigeNamensraum importiert die öffentlichen Anteile des unabhän-gigen Namensraum.
«friend» Abhängigkeit zwischen einem Modellelement (z.B. Operati-on, Klasse, Paket) und einem Modellelement in einem anderenPaket (z.B. Operation, Klasse, Paket). Das abhängige Elementerhält, ohne Berücksichtigung der Sichtbarkeit, Zugriff auf denunabhängigen Namensraum.
71 KAPITEL 3. METAMODELL
3.1.1.5 Kommentar
In der UML kann an jedes Modellelement eine Anmerkung, eine Notiz oder ein Kom-mentar geheftet werden. Die Notiz selbst hat in der UML keine Semantik, enthält aberzusätzliche Informationen für den Modellierer.
ModelElement
name : Name
Comment
*
*
+annotatedElement*
*
Abbildung 3.27:Jedes Modellelement kann mit beliebig vielen Kommentaren versehenwerden.
Im Metamodell werden die Kommentare durch die KlasseComment repräsentiert, dieein direkter Nachkomme der abstrakten MetaklasseModelElement ist (Abb. 3.27).
Zwei Stereotypen einer Notiz/eines Kommentars sind vordefiniert:
Stereotyp Semantik
«requirement» Anforderung: gefordertes Merkmal, Eigenschaft oder Verhal-ten eines Systems.
«responsibility» Verantwortlichkeit: Vertrag oder Verpflichtung eines Ele-ments.
3.1.2 Erweiterungsmechanismen
Die UML besitzt eingebaute Erweiterungsmechanismen, die verschiedenen Zwecken die-nen:
• Hinzufügen neuer Arten von Modellelementen.
• Definieren von Standards, die als nicht interessant oder komplex genug angesehenwurden 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.Stereotypenbieteneinen Weg, Elemente der Modellebene zu klassifizieren und ermöglichen das Hinzufügen
3.1. FUNDAMENT 72
„virtueller“ Metaklassen mit neuen Metaattributen und neuer Semantik.Eigenschaftswer-te (tagged values) undZusicherungen(constraints) basieren auf Eigenschaftslisten, diedas Anheften zusätzlicher Eigenschaften und Semantik an Modellelemente ermöglichen.
GeneralizableElement
TaggedValue
tag : Namevalue : String
ModelElement0..1
*
0..1 +taggedValue
*
Stereotype
icon : GeometrybaseClass : Name
*
0..1
+requiredTag *
0..1
0..1
*
+stereotype
0..1
+extendedElement
*
Constraint
body : BooleanExpression
1..*
*
+constrainedElement1..* {ordered}
+constraint
*
0..1
*
+constrainedStereotype0..1
+stereotypeConstraint *
{xor}
Abbildung 3.28: Erweiterungsmechanismen
Stereotype Ein Stereotyp ist ein UML-Modellelement, welches zur Markierungoder Klassifizierung anderer UML-Elemente benutzt wird. Die stereotypisierten Elemen-te können als Exemplare neuer „virtueller“ oder „Pseudo-“ Metamodellklassen angese-hen werden, die auf bestehenden Metamodellklassen basieren. Stereotypen vergrößernden Klassifikationsmechanismus, basierend auf der Metamodellklassenhierachie, deshalbmüssen sich die Namen neuer Stereotypen von den Namen der Metamodellelemente oderanderen Stereotypen unterscheiden. Jedes Modellelement kann durch maximal ein Ste-reotyp markiert werden. Ein Stereotyp kann als Spezialisierung anderer Stereotypen kon-struiert werden. Ein Stereotyp kann zusätzliche Eigenschaftswerte und Zusicherungensowie eine neue graphische Notation definieren. Die durch das Stereotyp markierten Mo-dellelemente erhalten diese Eigenschaftswerte, Zusicherungen und Notation. Ein ste-reotypisiertes Modellelement erhält die Attribute, Assoziationen und Operationen seinerBasisklasse (aus dem Metamodell) und kann zusätzliche zur Basisklasse konsistente Zu-sicherungen definieren, eine andere Bedeutung haben sowie eigene Eigenschaftswertedefinieren. Exemplare stereotypisierter Elemente haben die gleiche Struktur (Attribu-te, Assoziationen) und das gleiche Verhalten (Operationen) wie ein vergleichbares nicht-stereotypisiertes Element. Ein Stereotyp kann benutzt werden, um eine unterschiedlicheBedeutung oder Benutzung zweier Elemente mit identischer Struktur zu indizieren.
73 KAPITEL 3. METAMODELL
Im Metamodell (Abb. 3.28) ist die MetaklasseStereotype eine Unterklasse vonGeneralizableElement. Eigenschaftswerte und Zusicherungen eines Stereotyps wer-den auf alle durch das Stereotyp markierte Modellelement angewandt. Ein Stereotypkann optional ein Icon spezifizieren, welches zur Darstellung von Elementen des Stereo-typs benutzt werden kann. Falls ein Stereotyp ein Untertyp eines anderen Stereotypen ist,erbt es alle Eigenschaftswerte und Zusicherungen des Supertyps, wobei beide Stereotypendie gleiche Basisklasse haben müssen.
Attribut Semantik
baseClass Spezifiziert den Namen einer Klasse aus dem Metamodell derUML, auf das das Stereotyp angewandt wird, z.B.Class,Association oderConstraint.
icon Geometrische Beschreibung des Icons, welches zur Darstel-lung der durch das Stereotyp markierten Elemente benutztwird (optional).
Pseudottribut Semantik
extendedElement Bezeichnet die durch das Stereotyp klassifizierten Modellele-mente. Jedes dieser Modellelemente muß von der Art desdurchbaseClass spezifizierten UML-Modellelements sein.
constraint (geerbt vonModelElement) Zusicherung, die auf das Stereo-typ selbst angewandt wird.
stereotype-Constraint
Bezeichnet die Zusicherungen, die auf die stereotypisiertenElemente angewandt werden.
requiredTag Ein Eigenschaftswert (s.u.) ist ein Tupel bestehend aus einerMarkierung und einem Wert.requiredTag gibt die Markie-rungen an, die ein stereotypisiertes Element haben muß. DerWert gibt den Defaultwert des Eigenschaftswertes an. Falls derWert nicht spezifiziert ist, muß ein stereotypisiertes Elementden Wert setzen.
Die Namen der Eigenschaftswerte eines Stereotypen dürfen weder mit dem Meta-Attribut-Namensraum (Meta-Ebene) der Basisklasse, noch mit den Markierungen der ge-erbten Stereotypen kollidieren.
Modelelement Jedes Modellelement kann beliebige Eigenschaftswerte und Zusiche-rungen besitzen. Ein Modellelement darf maximal ein Stereotyp, dessen Basisklasse(baseclass) mit der UML-Klasse des Modellelements (z.B. Klasse) übereinstimmenmuß, besitzen. Die Markierung durch ein Stereotyp kann das Modellelement implizitmit Zusicherungen versehen und die Angabe von Eigenschaftswerten erfordern.
3.1. FUNDAMENT 74
Pseudottribut Semantik
stereotype Bezeichnet maximal einen Stereotyp, der die UML-Basisklasse des Modellelements erweitert bzw. weiterspezifiziert. Das Stereotyp verändert nicht die Strukturder Basisklasse, kann aber zusätzliche Eigenschaftswerteund Zusicherungen definieren, deren Semantik auf dasstereotypisierte Element übertragen wird.
constraint Zusicherung, die für die Exemplare des Modellelements erfülltsein muß. Ein Modellelement kann mehrere Zusicherungenbesitzen. Die Zusicherung wird ausgewertet, wenn das Systemin einem stabilen Zustand ist (z.B. nicht innerhalb einer atoma-ren Operation).
taggedValue Ein Eigenschaftswert, der an das Modellelement geheftet wird.Die Markierung (tag) ist der Name12 der Eigenschaft, derWert ist beliebig. Die Interpretation des Eigenschaftswer-tes liegt außerhalb des Bereichs der UML. Ein Modellele-ment kann mehrere Eigenschaftswerte besitzen, die Markie-rung muß dabei eindeutig sein.
Die mit einem Modellelement assoziierten Markierungen (der Eigenschaftswerte) (di-rekt oder indirekt durch ein Stereotyp) müssen sich von den mit dem Modellelement as-soziierten Metaattributen unterscheiden (man kann Eigenschaftswerte als Pseudo-Meta-attribute interpretieren). Falls ein Stereotyp einen Eigenschaftswert erfordert, aber nichtspezifiziert, muß das stereotypisierte Modellelement den Wert festlegen.
Constraint Das Konzept der Zusicherungen (engl. constraints) erlaubt die Spezi-fizierung neuer Semantiken für ein Modellelement. Die Spezifizierung kann durch einespeziell entworfene Sprache für Zusicherungen (z.B. OCL, Object Constraint Language),eine Programmiersprache, mathematische Notation oder eine natürliche Sprache formu-liert werden. Wenn Zusicherungen durch ein Werkzeug weitergehend unterstützt werdensollen, 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 Modellele-mente angewandt (z.B. Exemplare der Klasse Kunde). Eine Zusicherung kann eben-falls an ein Stereotyp geheftet werden (constrainedStereotype), d.h. die Zusicherungwird dann auf alle mit diesem Stereotyp markierten Elemente angewandt. BezeichnetconstrainedElement ein Stereotyp, dann wird die Zusicherung auf das Stereotyp selbstangewandt.
12taggedValue ist nicht als Unterklasse von ModelElement definiert, d.h. es kann weder den Namen vonModelElement erben, noch Zusicherungen besitzen.
75 KAPITEL 3. METAMODELL
Attribut Semantik
body Ein boolescher Ausdruck, der die Zusicherung definiert. Da-mit das Modell wohldefiniert ist, muß der Ausdruck den Wert„wahr“ ergeben, wenn er für ein Exemplar des zugesichertenElements (constrainedElement) ausgewertet wird. Der Aus-druck wird nur ausgewertet, wenn sich das System in einemstabilen Zustand befindet.
TaggedValue Ein Eigenschaftswert (tagged value) ist ein (Markierung, Wert)-Paar,welches als zusätzliche Information an ein Modellelement geheftet werden kann. Ein Mo-dellelement kann mehrere Eigenschaftswerte besitzen, zu einem Namen einer Markierungdarf es aber nur einen Wert geben. Die Interpretation einer Markierung liegt außerhalbdes Bereichs der UML, sie muß durch Benutzer- oder Werkzeugkonventionen festgelegtwerden. Beispiele für Eigenschaftswerte sind Autor und Versionnummer, die durch einWerkzeug automatisiert werden könnten.
Attribut Semantik
tag (Marke, Markierung) Name, der die angeheftete Eigenschaftbeschreibt. Eine Markierung ist ein Pseudoattribut eines Mo-dellelements. Ein Modellelement darf maximal einen markier-ten Wert pro Namen besitzen.
value Ein (beliebiger) Wert. Aus Gründen der einheitlichen Manipu-lation durch Tools muß der Wert als String ausgedrückt wer-den. Der Wertebereich hängt von der Interpretation der Mar-kierung ab.
3.1.3 Datentypen
Im Metamodell werden die Datentypen zur Deklarierung der Typen der Attribute derMetaklassen benutzt. Die Datentypen, die von den Anwendern der UML benutzt werden,sind die Exemplare der Datentyp-Metaklasse (Abb. 3.29 und 3.30).
Primitive Ein primitiver Datentypist ein einfacher Datentyp ohne relevante Un-terstruktur.
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 inklusi-ve des Wertes „unbegrenzt“ (unlimited) umfaßt.
3.1. FUNDAMENT 76
primitiver Datentyp Semantik
String Im Metamodell definiertString eine beliebig lange Zeichen-kette.
Time Im Metamodell definiertTime einen Wert, der einen absolutenoder relativen Moment in Raum und Zeit repräsentiert. DerWert hat eine entsprechende Darstellung als String.
StructurePrimitive
DataType
Enumeration
EnumerationLiteral
name : Name
1
1..*
1
+literal1..*
{ordered}
ProgrammingLanguageType
type : TypeExpression
Abbildung 3.29: Datentypen (1)
Structure Eine Struktur ist ein spezieller Datentyp, der eine feste Anzahl von be-nannten Teilen hat (vergleichbar einem „Record“).
Enumeration EineAufzählung(enumeration) ist ein Datentyp, dessen Wertebereicheine Liste von definierbaren Werten (EnumerationLiteral) ist. Diese Liste definiertAtome (d.h. Elemente ohne Unterstruktur), die auf Gleichheit untersucht werden können.
Aufzählung Semantik
AggregationKind Werte sind none, aggregate und composite. DieseWerte bezeichnen die Art der Aggregation einerAssoziation.
Boolean Werte sind true und false.
77 KAPITEL 3. METAMODELL
Aufzählung Semantik
CallConcurrencyKind Werte sind sequential, guarded und concurrent.Sie indizieren die Semantik der Nebenläufigkeiteiner Operation.
ChangeableKind Werte sind changeable, frozen und addOnly. Siespezifizieren, ob einAssociationEnd, LinkEndoderAttributLink (Verweis auf ein Exemplar)verändert werden kann.
MessageDirectionKind Werte sind activation und return. Sie spezifizie-ren die Richtung einer Botschaft. (wird in UMLVersion 1.3 final nicht mehr benutzt)
OperationDirectionKind Werte sind provide und require. Sie geben an,ob eine Operation von einem Klassifizierer unter-stützt oder seine Gegenwart verlangt wird. (wirdin UML Version 1.3 final nicht mehr benutzt)
OrderingKind Gibt die Art der Ordnung der Exemplare an ei-nem Assoziationsende an.
ParameterDirectionKind Werte sind in, out, inout und return. Sie gebenan, ob ein Parameter als Eingabe- und/oder Aus-gabeparameter benutzt wird.
PseudostateKind Werte sind initial, deepHistory, shallowHistory,join, fork, branch, junction und final. Beschreibtdie möglichen Pseudo-Zustände eines Zustands-automaten.
VisibilityKind Werte sind public, protected und private. Sie ge-ben an, ob die Elemente eines Namensraums vonaußen sichtbar sind.
ProgrammingLanguageType Ein Programmiersprachentypbeschreibt einen Typin der Syntax einer bestimmten Programmiersprache. Dieser Typ kann zur programmier-sprachenspezifischen Deklarierung von Attributen, Parametern und lokalen Variablen be-nutzt werdenTypeExpression ist ein String, der diesen Typ definiert.
Mapping EineAbbildungist ein Ausdruck, der zur Abbildung von Modellelementenbenutzt wird (siehe 3.1.1.4 Abhängigkeiten, 67). Aus Gründen der Austauschbarkeit soll-te dieser als String repräsentiert werden.
Name Im Metamodell definiertNameein Token, welches zur Benennung von Modell-elementen benutzt wird. Jeder Name hat eine entsprechende Darstellung als String.
3.1. FUNDAMENT 78
AggregationKind<<enumeration>>
Boolean<<enumeration>>
ChangeableKind<<enumeration>>
OperationDirectionKind<<enumeration>>
Expression
language : Namebody : String
Name
body : String
Integer<<primitive>>
ParameterDirectionKind<<enumeration>>
MessageDirectionKind<<enumeration>>
ScopeKind<<enumeration>>
String<<primitive>>
Time<<primitive>>
VisibilityKind<<enumeration>>
PseudostateKind<<enumeration>>
CallConcurrencyKind<<enumeration>>
MultiplicityRange
lower : Integerupper : UnlimitedInteger
Multiplicity
Mapping
body : StringUnlimitedInteger
<<primitive>>
OrderingKind<<enumeration>>
LocationReference
+range
1..*1 1..*1
Abbildung 3.30: Datentypen (2)
79 KAPITEL 3. METAMODELL
LocationReference Ein Ortsverweis(LocationReference) bezeichnet eine Po-sition innerhalb einer Verhaltenssequenz für die Einfügung eines erweiterten Anwen-dungsfalls. Dies kann z.B. eine Code-Zeile oder ein Zustand eines Zustandsautomatensein.
Multiplicity Im Metamodell definiert eineKardinalität eine Menge von nicht-negativen ganzen Zahlen (Integer). Eine Menge, die nur die Null enthält ({0}), ist keinegültige Kardinalität. Jede Kardinalität hat (mindestens) eine entsprechende Darstellungals String. Ein Kardinalitätsbereich (MultiplicityRange) definiert einen Bereich ganzerZahlen (Integer). Dabei darf die obere Grenze nicht unter der unteren Grenze liegen. Dieuntere Grenze muß ein nicht-negativer Integer sein, die obere Grenze kann den speziellenWert „unlimited“ annehmen.
BooleanExpression
Expression
language : Namebody : String
ObjectSetExpression TimeExpression
ActionExpression
IterationExpression
TypeExpression
ArgListsExpression
MappingExpression ProcedureExpression
Abbildung 3.31: Ausdrücke
Expression Ein Ausdruck(Abb. 3.31) wird zu einer eventuell leeren Menge vonExemplaren 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 einemNamen, der die Interpretationssprache (language) angibt, mit der der Ausdruck ausge-wertet wird, und einem String, der den eigentlichen Ausdruck enthält (body).
Ausdruck Semantik
ActionExpression Die Auswertung führt zur Ausführung einer Ak-tion.
ArgListsExpression Die Auswertung ergibt eine eine Menge von Li-sten, die aus Objekten bestehen.
BooleanExpression Boolescher Ausdruck, dessen Auswertung trueoder false ergibt.
IterationExpression Die Auswertung ergibt ein Iterationskonstrukt inder durchlanguage spezifizierten Sprache.
3.2. VERHALTENSELEMENTE 80
Ausdruck Semantik
MappingExpression Die Auswertung ergibt eine Abbildung.ObjectSetExpression Die Auswertung ergibt eine Menge von Exem-
plaren. ObjectSetExpressions werden zur Be-zeichnung der Zielexemplare einer Aktion be-nutzt. Der Ausdruck kann aus dem reservier-ten Wort „all“ bestehen, wenn er als Ziel einerSende-Aktion (siehe 3.2.1.2) benutzt wird. DieAuswertung enthält dann alle Exemplare, die dasSignal empfangen können.
ProcedureExpression Die Auswertung ergibt ein Exemplar einer Pro-zedur.
TimeExpression Die Auswertung ergibt ein Exemplar vonTime.TypeExpression Ein String, der einen Typ in einer Programmier-
sprache darstellt.
3.2 Verhaltenselemente
Die UML enthält Verhaltenselemente, mit denen funktionale und dynamische Aspekteeines Systems dargestellt werden können (Abb. 3.32).
Eine Kollaboration (PaketCollaborations) bezeichnet eine Gruppe von Objekten,die spezielle Rollen ausüben und zusammenarbeiten, um ein Verhalten zu zeigen, dasmehr ist als die Summe seiner Einzelteile. Eine Kollaboration definiert einen Kontext,in dem Objekte Botschaften austauschen, um eine bestimmte Aufgabe zu erfüllen. DerBotschaftenaustausch zwischen den Objekten kann in der UML durch zwei verschiede-ne Interaktionsdiagramme dargestellt werden: Kollaborationsdiagramm und Sequenzdia-gramm.
Ein Kollaborationsdiagrammzeigt die strukturellen Beziehungen zwischen den Ob-jekten (Kollaboration), auf deren Basis der Botschaftenaustausch (die Interaktion) statt-findet. Die Botschaften werden zwischen den beteiligten Objekten gruppiert, d.h. dieBeziehungen und die Kommunikation zwischen den Objekten wird in den Vordergrundgestellt. Der zeitliche Ablauf der Interaktion rückt in den Hintergrund, kann aber durchNummerierung der Botschaften gekennzeichnet werden
Sequenzdiagrammebeschreiben ein Szenario, in dem die Interaktion von Objektenzeitlich geordnet dargestellt wird. Im Gegensatz zum Kollaborationsdiagramm stellt einSequenzdiagramm den zeitlichen Ablauf in den Vordergrund, ohne die strukturellen Be-ziehungen zu zeigen.
Beide Arten der Interaktionsdiagramme heben den Kontrollfluß zwischen Objektenhervor.
Ein Zustandsdiagramm(statechart) ist die graphische Darstellung eines endlichen Au-
81 KAPITEL 3. METAMODELL
Use Cases State MachinesCollaborations
Common Behavior
Activity Graphs
Abbildung 3.32: Paketübersicht der Verhaltenselemente
tomaten (PaketStateMaschines). Mit endlichen Automaten kann das Verhalten vonObjekten (oder Systemen) modelliert werden, bei denen das Verhalten von ihrer Vergan-genheit abhängt. Objekte können auf Ereignisse wie z.B. Signalereignisse, die asynchronauftreten, oder Operationsaufrufe (meist synchron) reagieren. Wenn ein Ereignis eintritt,kann findet eine Reaktion statt, die vom aktuellen Zustand des Objekts abhängt. EndlicheAutomaten werden z.B. benutzt, um die Aufrufreihenfolge von Operationen auf einemObjekt einzuschränken. Mit ihnen wird modelliert,wanneine Operation angewandt wird(dynamisches Modell). Zustandsdiagramme zeigen den Kontrollfluß von Zustand zu Zu-stand, d.h. den Kontrollfluß innerhalb eines Objekts oder auch eines Systems.
Ein Aktivitätsdiagramm(PaketActivityGraphs) zeigt den Kontrollfluß von Aktivi-tät zu Aktivität. Aktivitätsdiagramme sind spezielle Zustandsdiagramme, deren Zustän-de größtenteils Aktivitätszustände sind. Ein Aktivitätsdiagramm ist im wesentlichen einFlußdiagramm (flowchart), welches auch nebenläufige Flüsse enthalten kann. Aktivitäts-diagramme werden zur Beschreibung komplexer Operationen oder zur Verfeinerung vonAnwendungsfällen eingesetzt.
Das PaketCommonBehavior enhält die Infrastruktur für die abhängigen Pakete ausAbb. 3.32. Das Paket definiert Objekte, Links und andere Exemplare zur Modellierungstruktureller Beziehungen, und Signale und Aktionen (z.B. Operationsaufrufe), die vonden abhängigen Paketen benötigt werden.
3.2. VERHALTENSELEMENTE 82
3.2.1 Allgemeines Verhalten
Im Inneren des Systems kommunizieren Objekte miteinander durch das Versenden vonBotschaften. Das sendende Objekt (sender) verschickt eine Botschaft, das empfangendeObjekt (receiver) empfängt eine Botschaft. Eine Botschaft benutzt einen Link als Kom-munikationskanal, über den die Botschaft zwischen den Objekten ausgetauscht wird. EineBotschaft kann durch Argumente näher spezifiziert werden. Eine konkrete Botschaft (einExemplar einer Botschaft) wird in der UMLStimulusgenannt.
Es gibt zwei grundsätzliche Arten von Botschaften:
1. Ein Signalist eine Botschaft zwischen einem auslösenden Objekt und allen Objek-ten, die dieses Signal zu diesem Zeitpunkt empfangen können. Bei den Empfängernführt der Empfang des Signals zu einer Zustandsveränderung.
2. Ein Operationsaufrufist 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 dieNachricht verarbeitet hat, bei asynchroner Kommunikation wartet der Sender nicht undkann parallel weiter arbeiten. Bei sequentieller Verarbeitung ist nur ein Objekt zu einemZeitpunkt aktiv, während bei einer parallelen Verarbeitung mehrere Objekte zu einemZeitpunkt aktiv (nebenläufig) sind. Eine parallele Verarbeitung kann vorliegen, wenn dasSystem auf mehrere Knoten (Prozessoren) verteilt ist. Eine pseudoparallele Verarbeitungmit Hilfe von Prozessen oder Threads auf einem Prozessor wird ebenfalls als parallelangesehen.
Zwischen Exemplaren können verschiedene Arten von Requests (Bitten oder Auffor-derungen) existieren. Die Metadarstellung der Signale, die eine Reaktion bei den Emp-fängern asynchron „triggern“, wird in Abschnitt 3.2.1.1 erläutert. Die Definition vonOperationsaufrufen und anderen Requests, z.B. das Erzeugen (create) oder Zerstören (de-stroy) von Exemplaren wird in Abschnitt 3.2.1.2 erläutert. Abschnitt 3.2.1.3 beschreibtdie Exemplare von Klassifizierern, Attributen, Assoziationen, Botschaften, Komponentenund Knoten.
3.2.1.1 Signale
Signal EinSignalist die Spezifikation eines Stimulus (Anreiz) zur asynchronen Kom-munikation zwischen Exemplaren.
Signale werden als Klassen mit dem Stereotyp «signal» modelliert. Die Attributedieser Klasse sind die Parameter des modellierten Signals.
Im Metamodell (Abb. 3.33) istSignal eine Unterklasse von Klassifizierer (also auchgeneralisierbar), die Parameter werden als Attribute (geerbt vonClassifier) dargestellt.Die Instantiierung eines Signals ergibt dann eine konkrete Botschaft (Stimulus), die zu
83 KAPITEL 3. METAMODELL
Exception
ReceptionisPolymorphic : Booleanspecification : String
BehavioralFeatureSignal
1
0..*
+signal
1
+reception
0..*
**
+context
*
+raisedSignal
*
Classifier
Abbildung 3.33: Signal, Ausnahme und Empfang
einem (Signal-) Ereignis beim Empfänger führt. Ein Signal kann mit einem Verhal-tensmerkmal des Senders (context) und mit einem Verhaltensmerkmal des Empfängers(reception) assoziiert sein.
Exception EineAusnahmeist ein Signal, welches von Klassifizierern typischerweisezur Behandlung von Fehlern abgesandt wird.
Im Metamodell istException eine Unterklasse vonSignal und kann mit den Verhal-tensmerkmalen (context), und damit mit den Klassifizierern, die dieses Signal absetzenkönnen, assoziiert sein.
Reception Ein Empfangist eine Deklaration eines Klassifizierers, auf den Empfangeines Signals (signal) vorbereitet zu sein und entsprechend zu reagieren. Die Reaktionauf den Empfang wird durch einen String (specification) zusammenfassend beschrie-ben. Detailliert beschrieben wird die Reaktion auf den Empfang des Signals, die zu einerZustandsveränderung (des Exemplars) des Klassifizierers führen muß, durch einen Zu-standsautomaten.
Im Metamodell istReception eine Unterklasse von Verhaltensmerkmal (Behavi-oralFeature), d.h. es erbt die AttributeisAbstract, isLeaf und isRoot. Falls dasAttribut isPolymorphic den Wert false besitzt, ist die Reaktion auf den Empfang immer
3.2. VERHALTENSELEMENTE 84
gleich, z.B. wenn das empfangende Exemplar nur in einem Zustand das Signal empfan-gen kann, also so gesehen keine Vergangenheit hat). Ansonsten kann das Verhalten vomZustand des empfangenden Exemplars abhängen.
3.2.1.2 Aktion
Eine Aktion ist eine ausführbare, atomare Verarbeitung, die zu einer Zustandsverände-rung des Systems führt. Die verschiedenen Arten einer Aktion (Abb. 3.34) sind dasSenden eines Signals (SendAction), der Aufruf einer Operation (CallAction), das Er-zeugen (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 (targetSetEx-pression), deren Argumente (actual) und die Art der Kommunikation (isAsynchronous)spezifizieren. Das Attributrecurrence ist ein Iterationsausdruck, der angibt, wie dieEmpfänger abgearbeitet werden bzw. wie oft die Botschaft abgeschickt wird.Action isteine abstrakte Metaklasse.
Das Ausführen einer Aktion bedeutet die Auswertung der Metaattribute und führtmeistens zum Versenden eines Stimulus oder mehrerer Stimuli.
Attribut Semantik
isAsynchronous Gibt an, ob die Botschaft (bzw. der Stimulus) asynchron istoder nicht.
recurrence Iterationsausdruck, der angibt, wie oft die Aktion ausgeführtwird.
target Ein TargetSetExpression, der zu einer eventuell leeren Mengevon Exemplaren, die die Empfänger der Botschaft (der Stimu-li) sind, ausgewertet wird. In der UML ist nicht definiert, obdie Aktion sequentiell oder parallel auf ihre Ziele angewandtwird.
script Ein Ausdruck, der die Auswirkungen der Aktion beschreibt.
Pseudoattribut Semantik
actual Eine Argumentliste, die Ausdrücke zur Bestimmung der zurAusführungszeit der Aktion zu benutzenden Argumente (Ex-emplare) enthält.
85 KAPITEL 3. METAMODELL
Des
troy
Act
ion
Uni
nter
pret
edA
ctio
n
Mod
elE
lem
ent
Cre
ateA
ctio
nC
lass
ifier
0..*
10.
.*
+in
stan
tiatio
n
1
Ret
urnA
ctio
nT
erm
inat
eAct
ion
Ass
ignm
entA
ctio
n
Cal
lAct
ion
Ope
ratio
n
* 1*
+op
erat
ion
1
Sen
dAct
ion
Sig
nal
* 1*
+si
gnal
1
Arg
umen
t
valu
e : E
xpre
ssio
n
Act
ionS
eque
nce
Act
ion
*
0..1
+ac
tual
*
{ord
ered
}
0..1
0..1
0..1
+ac
tion
{ord
ered
}
Abbildung 3.34: Aktionen
3.2. VERHALTENSELEMENTE 86
ActionSequence Eine Aktionssequenzist eine geordnete Folge von Aktionen, diesequentiell als atomare Einheit ausgeführt wird. Sie wird benutzt, um eine Aktion einesZustands oder einer Transition in einem Zustandsautomaten zu beschreiben.
CreateAction EineErzeuge-Aktionist eine Aktion, die ein Exemplar eines Klassi-fizierers erzeugt. Im Metamodell istCreateAction eine Unterklasse vonAction, diemit genau einem Klassifizierer assoziiert ist. Eine Erzeuge-Aktion hat kein durchtargetangegebenes Ziel bzw. Empfänger. Der zu instantiierende Klassifizierer wird durch dasPseudoattributinstantiation angegeben.
DestroyAction EineZerstöre-Aktionführt zur Zerstörung eines Exemplars. Das be-treffende Exemplar wird durch dastarget-Attribut der Aktion spezifiziert. Eine Zerstöre-Aktion hat keine Argumente.
TerminateAction Eine Terminiere-Aktionführt zur Selbstzerstörung eines Exem-plars. Das Ziel dieser Anweisung ist implizit das Exemplar, welches die Aktion ausführt,d.h. es gibt kein explizites Ziel.
CallAction EineAufruf-Aktionist eine Aktion, die eine Operation eines Exemplarsaufruft. Der Aufruf kann synchron oder asynchron sein. Das Exemplar oder die Mengevon Exemplaren wird durch das Attributtarget, die Argumente werden durch das (ge-erbte) Pseudoattributactual und die aufzurufende Operation wird durch das Pseudoattri-butoperation spezifiziert. Die Anzahl der Argumente muß mit der Anzahl der Parame-ter der Operation übereinstimmen. Die Übereinstimmung der Typen der Argumente mitden Typen der Parameter wird nicht gefordert! Dies ermöglicht die Argumentübergabean eine Operation auf verschiedene Arten (siehe Seite 174) .
ReturnAction EineRückgabe-Aktionist eine Aktion, die dem Aufrufer einen Wertzurückliefert. Im Metamodell werden die Werte durch die vonAction geerbten Argu-mente repräsentiert. Eine Rückgabe-Aktion hat kein explizites Ziel, das implizite Zieldieser Aktion ist das aktivierende Exemplar, welches, z.B. durch einen Operationsauf-ruf, eine Folge von Aktionen aktiviert hat, die durch die Rückgabe-Aktion abgeschlossenwird.
AssignmentAction Eine Zuweisungs-Aktionist eine Aktion, die einem Link odereinem Attributlink (Exemplar eines Attributs) einen Wert zuweist. Im Metamodell wirddas zugewiesene Exemplar (der Wert) durch das Argument der Aktion spezifiziert.
87 KAPITEL 3. METAMODELL
Eine Zuweisungs-Aktion besitzt die (nicht explizit dargestellten) Pseudoattributeasso-ciation undattribute (siehe Abb. 3.36)13. Sie bezeichnen die Assoziation, welcherein Link bzw. das Attribut, welchem ein Attributlink zugewiesen wird.
SendAction Eine Sende-Aktionsendet ein Signal. Ein Signal ist immer asynchron.Das Signal kann an bestimmte Empfänger oder an eine Menge unbestimmter Empfän-ger gesandt werden (viatarget). Hat target den Wertall, wird das Signal an alleObjekte, die das Signal empfangen können, gesandt. Ist das Signal z.B. eine Ausnah-me (exception), wird der Empfänger durch den Mechanismus des Laufzeitsystems be-stimmt14.
SignalSendAction +signal
* 1* 1
Abbildung 3.35: Sende-Aktion
Im Metamodell (Abb. 3.35) istSendAction mit dem zu sendenen Signal assoziiert,die Argumente werden durch das vonAction geerbte Pseudoattributactual spezifiziert.Die Ausführung einer Sende-Aktion instantiiert ein Signal mit den angegebenen Parame-tern (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 Argu-mente und Parameter gefordert.
UninterpretedAction Eine nichtinterpretierte Aktionist eine Aktion, die nichtexplizit 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 Dar-stellung von Struktur- und Verhaltensaspekten benötigt werden.
Instance Ein Exemplar(Instanz) definiert ein „Ding“, auf welches Operationen an-gewendet werden können und einen Zustand hat, der die Auswirkungen der Operationspeichert.
Im Metamodell istInstance mit mindestens einem Klassifizierer (classifier) ver-bunden, welcher Struktur und Verhalten des Exemplars deklariert. Ein Exemplar kann
13Vermutlich sind hier die Pseudoattribute des Arguments der Zuweisungsaktion gemeint. Dies geht ausder Dokumentation nicht hervor ([OMG99], Seite 2-86)
14Siehe [OMG99], Seite 2.91
3.2. VERHALTENSELEMENTE 88
Link
Obj
ect
Dat
aVal
ueO
bjec
t
Mod
elE
lem
ent
Ass
ocia
tion
Nod
eIns
tanc
e
Act
ion
recu
rren
ce :
Itera
tionE
xpre
ssio
nta
rget
: O
bjec
tSet
Exp
ress
ion
isA
sync
hron
ous
: Boo
lean
scrip
t : A
ctio
nExp
ress
ion
Ass
ocia
tionE
nd
2..*
1
+con
nect
ion
2..*
1
Link 1*
+ass
ocia
tion
1*
Attr
ibut
e
Com
pone
ntIn
stan
ce
*0.
.1
+re
side
nt
*0.
.1
Stim
ulus
1 *
+dis
patc
hAct
ion
1 *
*0.
.1*
+com
mun
icat
ion0.
.1Li
nkE
nd
1*
+ass
ocia
tionE
nd1*
12
.. *
1
+con
nect
ion
2 ..
*{o
rder
ed}
Cla
ssifi
er
Attr
ibut
eLin
k
*1
*
+at
trib
ute
1
Inst
ance
*
0..1
+re
side
nt*
0..1
* **
+arg
umen
t*
{ord
ered
}
* 1*
+se
nder
11*
+re
ceiv
er1*
1
*
+ins
tanc
e
1
+lin
kEnd
*
1..*
*
+cl
assi
fier
1..*
*
10..*
1
+sl
ot0.
.** 1*
+val
ue1
Abbildung 3.36: Metamodell: Exemplare und Links
89 KAPITEL 3. METAMODELL
eine Menge von Attributen und Attributwerten besitzen. Im Metamodell besitzt ein Ex-emplar Attributlinks (slot, Fach), die auf die Attribute und Attributwerte verweisen.
Ähnlich wie Klassifizierer mit Assoziationsenden zur Darstellung einer Assoziationverbunden sein können, werden ihre Exemplare mit den entsprechenden Link-Enden (Ex-emplar eines Assoziationsendes) zur Darstellung eines Links verbunden. Ein Exemplarkann auch als Sender und Empfänger von Stimuli, d.h. konkreter Botschaften, dargestelltwerden.Instance ist eine abstrakte Metaklasse, für die ein Eigenschaftswert vordefiniertist:
Eigenschaftswert Semantik
persistent Wird der Wert der Eigenschaft mit „persistent“ gekennzeich-net, dann wird der Zustand des Exemplars nicht zerstört wenndas Exemplar zerstört wird, d.h. der Zustand wird gespeichert.Wird der Wert mit „transitory“ gekennzeichnet, dann wird derZustand mit dem Exemplar zerstört.
DataValue Ein Datenwertist ein Exemplar ohne Identität. Im Metamodell istData-Value ein Nachkomme vonInstance, welches seinen Zustand nicht ändern kann, d.h.alle auf einen Datenwert anwendbare Operationen sind reine Funktionen (keine Seiten-effekte) oder Abfragen (Query). Datenwerte werden als Attributwerte (value) benutzt.Ein Datenwert wird von genau einem Klassifizierer (einDataType) erzeugt und hat keineAttributlinks, d.h. keine Attribute.
Object Ein Objekt ist ein Exemplar einer Klasse. Im Metamodell istObject eineUnterklasse vonInstance. Ein Objekt ist das Exemplar mindestens einer Klasse. DieKlassenzugehörigkeit eines Objekts kann dynamisch modifiziert werden, d.h. die Merk-male eines Objekts können sich währernd seiner Lebensdauer ändern. Jeder Klassifizierer(classifier) eines Objekts muß ein Exemplar der MetaklasseClass sein.
ComponentInstance Ein Komponentenexemplarist ein Exemplar einer Kompo-nente und kann mehrere Zustände haben. Im Metamodell kann eine Komponentenin-stanz mit Exemplaren assoziiert sein (resident), die Exemplare innerhalb einer Kom-ponente repräsentieren. Ein Komponentenexemplar kann von genau einer Komponente(classifier) erzeugt werden.
NodeInstance Ein Knotenexemplarist ein Exemplar eines Knotens und kann Kom-ponentenexemplare enthalten (resident). Jedes Komponentenexemplar, das sich aufeinem Knotenexemplar befindet, muß ein Exemplar einer Komponente sein, die sich aufdem entsprechenden Knoten befindet. Der Klassifizierer eines Knotenexemplars muß ein
3.2. VERHALTENSELEMENTE 90
Exemplar der MetaklasseNode sein15.
Linkobject Ein Linkobjektist ein Exemplar einer Assoziationsklasse. Im Metamo-dell ist ein Linkobjekt eine Verbindung zwischen Exemplaren, wobei die Verbindungselbst Attributwerte besitzen kann und auf die Verbindung Operationen angewendet wer-den können.LinkObject ist ein Nachkomme vonObject undLink. Ein Klassifiziererdes Linkobjekts muß mit der entsprechenden Assoziation übereinstimmen, die Assoziati-on muß ein Exemplar der MetaklasseAssociationClass sein16.
Stimulus Ein Stimulus(Abb. 3.37) beschreibt eine Kommunikation zwischen zweiExemplaren.
Pseudoattribut Semantik
receiver Ein Exemplar, welches den Stimulus empfängt.sender Ein Exemplar, welches den Stimulus sendet.argument 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 überein-stimmen. Die Aktion muß eine Sende-Aktion, eine Aufruf-Aktion, eine Erzeuge-Aktionoder eine Zerstöre-Aktion sein.
Link Ein Link (Abb. 3.37) bezeichnet eine Verbindung zwischen Exemplaren. ImMetamodell ist ein Link ein Exemplar einer Assoziation (association). Ein Link besitzteine (geordnete) Menge von Link-Enden (connection), die den Assoziationsenden derAssoziation entsprechen müssen. Es darf keine Links einer Assoziation geben, die diegleichen Instanzen auf die gleiche Art verbinden, d.h. jedes Tupel (als Exemplar einerAssoziation) ist eindeutig.
LinkEnd Ein Link-Ende(Abb. 3.37) ist ein Exemplar eines Assoziationsendes, d.h.ein Endpunkt eines Links. Im Metamodell istLinkEnd der Teil des Links, der den Linkmit einem Exemplar (instance) verbindet. Ein Link-Ende entspricht genau einem Asso-ziationsende (associationEnd) der Assoziation des Links. Der Typ des Exemplars desLink-Endes muß mit dem Typ des Assoziationsendes übereinstimmen.
15Weitere Unterklassen vonNode im Metamodell können so in weiteren Versionen der UML hinzugefügtwerden.
16In weiteren Versionen werden eventuell Unterklassen vonAssociationClass eingeführt.
91 KAPITEL 3. METAMODELL
AssociationEndAssociation
2..*1
+connection
2..*1
Action
recurrence : IterationExpressiontarget : ObjectSetExpressionisAsynchronous : Booleanscript : ActionExpression
Link
*
1
*
+association 1
LinkEnd
*
1
*
+associationEnd 1
2 .. *1
+connection
2 .. *1{ordered}
Stimulus
*
1
*
+dispatchAction 1
0..1*
+communicationLink
0..1*
Instance
*
1
+linkEnd
*
+instance
1
*
*
*
+argument *
{ordered}
1
*
+sender 1
* *
1
*
+receiver 1
ModelElement
name : Name
Abbildung 3.37: Link und Stimulus
Links bilden eine Verbindung zwischen Exemplaren, über die in Kollaborationsdia-grammen Stimuli verschickt werden (communicationLink). Es sind mehrere Zusiche-rungen für Link-Enden definiert, die in Kollaborationsdiagrammen verwendet werden:
Zusicherung Semantik
association Das mit dem Link-Ende assoziierte Exemplar ist durch eineAssoziation sichtbar.
destroyed Das Exemplar wird während der Ausführung (in dem model-lierten Kontext) zerstört.
new Das Exemplar wird während der Ausführung erzeugt.transient Das Exemplar wird während der Ausführung erzeugt und zer-
stört.global Das Exemplar ist sichtbar, da es in einem globalen Bereich
(scope) relativ zum Link liegt (globale Variable).local Das Exemplar ist sichtbar, da es in einem lokalen Bereich (sco-
pe) relativ zum Link liegt (lokale Variable).parameter Das Exemplar ist sichtbar, da es ein Parameter relativ zum Link
ist.self Das Exemplar ist sichtbar, da es der Absender eines Requests
an sich selbst ist.
3.2. VERHALTENSELEMENTE 92
3.2.2 Kollaborationen
Eine Kollaboration bezeichnet „[...] Gruppen von Objekten, die spezielle Rollen ausübenund zusammenarbeiten, um ein Verhalten zu zeigen, das mehr ist als die Summe seinerEinzelteile. Diese Rollen repräsentieren prototypische Instanzen von Klassen, Schnittstel-len, Komponenten, Knoten und Anwendungsfällen“17. Eine Kollaboration definiert einenstrukturellen Kontext als Basis für eine Interaktion zwischen den beteiligten Objekten.
Eine Interaktion von Modellelementen wird in der UML durch Interaktionsdiagram-me dargestellt, von denen es zwei Versionen gibt: Sequenzdiagramme und Kollaborati-onsdiagramme. Ein Sequenzdiagramm hebt den zeitlichen Ablauf von Kommunikationenzwischen Objekten hervor, ohne die strukturellen Beziehungen zwischen den Objekten zuzeigen (Abb. 3.38) . Ein Kollaborationsdiagramm enthält die strukturellen Beziehungenzwischen den beteiligten Modellelementen (die Kollaboration) und darauf aufbauend dieInteraktion zwischen den Modellelementen, wobei der zeitliche Ablauf durch sogenannteSequenznummern notiert wird.
Ein Kollaborationsdiagramm kann auf zwei verschiedenen Ebenen bzw. durch zweiverschiedene Sichten auf die Zusammenarbeit der Modellelemente dargestellt werden.Ein Kollaborationsdiagramm derSpezifikationsebene(Abb. 3.39) enthält Klassifizierer-und Assoziationsrollen zur Darstellung des Strukturaspekts sowie Botschaften (messages)zwischen den Klassifiziererrollen zur Spezifikation der Kommunikation. Die Rollen sindEinschränkungen der Eigenschaften der Klassifizierer und Assoziationen, so daß nur diefür die Zusammenarbeit benötigten Merkmale gezeigt werden.
Eine Kollaboration auf einerexemplarischen Ebenekann als Instantiierung der Spe-zifikationsebene aufgefaßt werden. Ein Diagramm dieser Ebene enthält Exemplare vonKlassifizierern (meist Objekte), Links und Stimuli. Ein Kollaborationsdiagramm der (ex-emplarischen Ebene) ist semantisch äquivalent zu einem Sequenzdiagramm, da beide ausden gleichen Informationen im Metamodell abgeleitet werden. Das bedeutet aber nicht,daß beide Diagramme explizit die gleiche Information darstellen18. Auf der exemplari-schen Ebene kann die Erzeugung, Benutzung oder Zerstörung von Objekten bzw. Linksexplizit gezeigt werden (Abb. 3.38).
Notation der Rollen in einer Kollaboration Eine Klassifiziererrolle dient zur Ein-schränkung der in der Kollaboration benötigten Merkmale einer Klasse und wird in einemKlassenrechteck dargestellt. Das Klassenrechteck enthält, neben optionalen Attributenund Operationen, eine Zeichenkette nach dem folgenden Muster:
/ Klassifiziererrolle : KlassifizierernameEine Assoziationsrolle wird mit der normalen Assoziationslinie gezeigt. Die optionale
Benennung der Assoziationsrolle folgt der Syntax für die Klassifiziererrolle. Die Notationfür die Assoziationsendrollen entspricht der Notation für die Assoziationsenden.
17[BRJ99a], Seite 23118vgl. [BRJ99a], Seite 282
93 KAPITEL 3. METAMODELL
3-98 UML V1.3 beta R1 April 1999
3 UML Notation
Figure 3-48 Sequence Diagram with Focus of Control, Conditional, Recursion, Creation, and Destruction.
[x>0] foo(x)
[x<0] bar(x)
doit(z)doit(w)
mo� re()
ob1:C1
ob2:C2
ob3:C3 ob4:C4
op()
Abbildung 3.38:Visualisierung einer Interaktion durch ein Sequenzdiagramm. Die verti-kal gestrichelten Linien sind die Lebenslinien der Objekte. Die diese Li-nien überlagernden Rechtecke kennzeichnen den Kontroll- oder Steue-rungsfokus der Objekte. Sie geben an, wann ein Objekt innerhalb desProgrammablaufs die Kontrolle erhält. Eine Botschaft bzw. ein Stimu-lus an ein Objektrechteck stellt die Erzeugung eines Objekts, ein Kreuzam Ende der Lebenslinie die Zerstörung eines Objekts innerhalb der Se-quenz dar. Alternative Abläufe werden durch Botschaften dargestellt,die eine Bedingung enthalten und deren Pfeile den gleichen Startpunktbesitzen. (entnommen aus [OMG99], Seite 3-98)
3.2. VERHALTENSELEMENTE 94
Klassifiziererrolle
/Leiter:Person
Projekt
1
/Mitarbeiter:PersonMitarbeiter *Gruppenleiter 1 leitet
*
*
verantwortlich für +Projekt *
Projektleiter
Projekt
*
*
Teilnehmer1
Assoziationsendrolle
Assoziationsrolle Kardinalität
Abbildung 3.39:Kollaboration auf der Spezifikationsebene ohne Interaktion. Hinweiseauf Kollaborationsdiagramme auf der Spezifikationsebene fanden sichnur in der offiziellen UML-Dokumentation ([OMG99], Seite 3-111).Ein Beispiel einer Interaktion im Kontext einer solchen Kollaborationist selbst dort nicht vorhanden.
Multiobjekt
UML-Tool : Projekt... /Mitarbeiter : Person
/Leiter : Person
1.1* [i=1..n]: name := name()1: NamenBeteiligter()
1.2: name := name()
Chart Name : Kolla_SpezifikationChart Filename : D:\Home\Stephan\vuml\colUntitled2.VobChart Type : UML Collaboration Diagram
Abbildung 3.40:Kollaboration auf der exemplarischen Ebene. Der Stern „*“ der Bot-schaft/des Stimulus 1.1 kennzeichnet eine Iteration. Es ist leider nichtvisuell erkennbar, welche Botschaften innerhalb der Iteration bearbei-tet werden. Erweiterte Modellierungsmöglichkeiten wie Verzweigun-gen und Iterationen lassen Interaktionsdiagramme unübersichtlich (sie-he auch Abb. 3.38) werden.
95 KAPITEL 3. METAMODELL
Ein Objekt, welches die durch eine Klassifiziererrolle definierte Rolle spielt, wirddurch eine Objektbox (siehe Abb. 3.40), meistens ohne Attributanteile, dargestellt. DerNamensanteil der Objektbox wird nach dem folgenden Muster dargestellt:
Objektname / Klassifiziererrolle : KlassifizierernameDer Objektname ist optional, d.h. eine Objektbox ohne Objektnamen wird als ano-
nymes Objekt der Klasse angesehen. Die Klassifiziererrolle kann weggelassen werden,falls von den Objekten der Basisklasse nur eine Rolle innerhalb der Kollaboration gespieltwird.
Interaktion Eine Interaktion ist eine Spezifikation des Verhaltens von Objekten in ei-nem Kontext (Kollaboration), um eine bestimmte Aufgabe zu erfüllen. Hierauf aufbau-end können mögliche Interaktionsfolgen spezifiziert werden. Die Interaktionsfolge kanndurch eine einzelne Beschreibung, die Bedingungen und Verzweigungen enthält, oderdurch mehrere Beschreibungen, die jeweils einen bestimmten Pfad enthalten, spezifiziertwerden.
Eine Kommunikation wird durch eine Botschaft (message) spezifiziert, die Sender-und Empfängerrollen sowie eine Aktion enthält, welche die Kommunikation initiiert. DieAktion gibt die Art der Kommunikation (z.B. Operationsaufruf) zusammen mit Argu-mentausdrücken an, welche die zu sendenden Parameter bestimmen. Als Folge der Aus-führung der Aktion werden ein oder mehrere Stimuli entsprechend der Botschaft abge-setzt. Ein Stimulus enthält Referenzen auf die Sender- und Empfängerobjekte sowie eineFolge von Objektreferenzen als Resultat der Auswertung der Argumentausdrücke.
Interaktionen werden durch Sequenz- oder Kollaborationsdiagramme dargestellt. Se-quenzdiagramme (Abb. 3.38) zeigen den Verhaltensaspekt einer Kollaboration inklusiveder zeitlichen Folge der Botschaften/Stimuli. Kollaborationsdiagramme zeigen den voll-ständigen Kontext einer Interaktion, der zeitliche Ablauf ist aber in einem Sequenzdia-gramm visuell leichter zu erfassen.
Botschaften und Stimuli in einem Kollaborationsdiagramm Ein Stimulus ist dieKommunikation von einem Objekt zu einem anderen, während eine Botschaft die Spe-zifikation der Kommunikation ist.
Die Darstellungsart eines Pfeils entlang einer Assoziationslinie oder eines Links gibtdie Art der Kommunikation, z.B. synchron oder asynchron, an. Die Pfeile in Abb. 3.40bezeichnen (verschachtelte) Operationsaufrufe. Dabei muß die verschachtelte Sequenz(angegeben durch Sequenznummern) vollständig beendet werden, bevor die äußere Se-quenz fortgesetzt werden kann.
In der Nähe des Pfeils wird die Botschaft (bzw. der Stimulus) angegeben. Die Bot-schaft hat die folgende Syntax ([OMG99], Seite 3-123):
Vorgänger Bedingung Sequenzausdruck Rückgabewert :=Botschaftsname Argumentliste
3.2. VERHALTENSELEMENTE 96
Vorgängerist eine durch Kommata getrennte Liste von Sequenznummern (siehe Se-quenzausdruck) ohne Verzweigungsbedingung oder Iterationsausdruck, gefolgt von ei-nem Slash (/). Dies bedeutet, daß die durch die Sequenznummern bezeichneten Botschaf-ten vor dem Absetzen dieser Botschaft bearbeitet worden sein müssen. Die implizit durchdie Sequenznummer gegebenen Vorgänger (1.2.3 ist Vorgänger von 1.2.4) müssen hierbeinicht explizit angegeben werden. Vorgänger werden benutzt, um nebenläufige Threads zusynchronisieren.
Die Bedingungist in [OMG99] nicht definiert. Nach [Alh98], Seite 183, ist die Be-dingung eine in eckige Klammern gefaßte boolesche Bedingung, deren Erfüllung denVersand der Botschaft ermöglicht.
Der Sequenzausdruckbesteht aus einer durch Punkte getrennten Liste von Sequenz-termen 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).nameist 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 neben-läufig innerhalb dieser Verschachtelungsebene.
recurrenceist eine Bedingungsklausel ([ Bedingungsklausel ]) oder eine Iterations-klausel (* [ Iterationsklausel ]). Die Form der Bedingungsklausel und der Iterationsklau-sel ist nicht von der UML vorgegeben. Eine Iteration gibt die Wiederholungshäufigkeitder Botschaft an, z.B.[i = 1..n]. Die Botschaften werden sequentiell ausgeführt. Mit„∗‖“ kann die nebenläufige Ausführung spezifiziert werden.recurrencewird auf dasrecurrence-Attribut der mit der Botschaft assoziierten Aktion (Action), z.B. ein Ope-rationsaufruf, abgebildet.
Eine Bedingungsklausel gibt an, daß die Ausführung der Botschaft vom Wahrheits-wert der Bedingungsklausel abhängt. Beispiel:[x< y]. Bedingungsklauseln werden be-nutzt, um bedingte Verzweigungen zu realisieren.
Der Rückgabewertbesteht aus einer Liste von Bezeichnern, die die Rückgabewerteam Ende der Kommunikation repräsentieren. Diese Bezeichner können als Argumente innachfolgenden Botschaften benutzt werden.
Der Botschaftsnameist der Name des Ereignisses, welches im Zielobjekt passiert.Dies ist meist das Ereignis eines Requests, eine Operation auszuführen. Falls diese Bot-schaft als Operationsaufruf implementiert wird, ist der Botschaftenname der Name derOperation und die Klasse des Empfängers der Botschaft muß diese Operation deklarierenoder erben.
Die Argumentlistebesteht aus einer geklammerten und durch Kommata getrenntenListe von Argumenten (Aktualparameter). Jedes Argument ist entweder eine Objektre-ferenz oder ein Pseudocodeausdruck. Die Ausdrücke können Rückgabewerte vorheriger
97 KAPITEL 3. METAMODELL
Botschaften und Navigationsausdrücke ausgehend vom Quellobjekt benutzen. Navigati-onsausdrücke bestehen aus Attributen und Links des Quellobjekts und aus Attributen undLinks anderer Objekte, die durch die Links des Quellobjekts erreichbar sind. Auch hierwird die Syntax der Ausdrücke nicht in der UML definiert.
Sequenzdiagramm Ein Sequenzdiagramm hat zwei Dimensionen. Die vertikale Di-mension repräsentiert den zeitlichen Ablauf, die horizontale Dimension die beteiligtenObjekte. Syntax und Semantik der Botschaften entsprechen den Botschaften in den Kol-laborationsdiagrammen. Verschiedene zusätzliche Informationen, z.B. Zeitmarken und
... UML-Tool : Projekt /Mitarbeiter : Person /Leiter : Person
1: NamenBeteiligter() 1.1* [i=1..n]:name := name()
1.2: name := name()
Beteiligte
Abbildung 3.41:Interaktion aus Abb. 3.40 in einem Sequenzdiagramm. Die Sequenz-nummern werden üblicherweise nicht dargestellt, da die Folge der Bot-schaften implizit gegeben ist.
Aktionsbeschreibungen, können am Rand des Diagramms oder in der Nähe der Pfeiledargestellt werden.
Die Interaktionen der Kollaborations- und Sequenzdiagramme werden auf die glei-chen Klassen des Metamodells abgebildet. Deshalb werden die beiden Interaktionsdia-gramme als semantisch äquivalent angesehen, obwohl jede Diagrammart Modellelementedarstellen kann, die die andere Diagrammart nicht darstellen kann.
Das MetamodellpaketCollaborations (Abb. 3.42) besteht u.a. aus der KlasseCol-laboration, die aus einer Komposition von Rollen (AssociationRole, Classifier-Role) und Interaktionen (Interaction) besteht.Interaction beinhaltet eine Mengevon halbgeordneten Botschaften (Message), die jeweils mit einer Aktion assoziiert sind.
Klassen, die auf eine Kollaboration der exemplarischen Ebene schließen lassen, sindin diesem Paketnicht vorhanden.
3.2. VERHALTENSELEMENTE 98
{xor
}
Nam
espa
ce
Ass
ocia
tion
Act
ion
Ass
ocia
tionE
nd
2..*1
+con
nect
ion
2..*1
Attr
ibut
e
Ope
ratio
n
Inte
ract
ion
Ass
ocia
tionR
ole
mul
tiplic
ity :
Mul
tiplic
ity
0..1
*
+ba
se
0..1
*
Fea
ture
Mes
sage
*0..1 *+ac
tivat
or
0..1** *+pr
edec
esso
r
*
1 1..*
1
+m
essa
ge1.
.*
1*
+act
ion 1
*
*0.
.1*
+com
mun
icat
ion
Con
nect
ion
0..1
Ass
ocia
tionE
ndR
ole
colla
bora
tionM
ultip
licity
: M
ultip
licity
0..1
*
+ba
se
0..1
*
1 2..*
1
+/co
nnec
tion
2..*
* **+a
vaila
bleQ
ualif
ier
*
Cla
ssifi
er
Col
labo
ratio
n
*0.
.1*
+re
pres
ente
dO
pera
tion
0..1
1 *
+con
text
1
+int
erac
tion
*
1 *1
+/ow
nedE
lem
ent
*
*0.
.1*
+re
pres
ente
dC
lass
ifier
0..1
Cla
ssifi
erR
ole
mul
tiplic
ity :
Mul
tiplic
ity
**
*
+ava
ilabl
eFea
ture
*
1
1..*
1
+/ow
nedE
lem
ent
1..*
1*
+se
nder
1** 1*
+re
ceiv
er1
*1
*+
/type
1
*
1
*
+ba
se1
Mod
elE
lem
ent
* **+c
onst
rain
ingE
lem
ent
*
*
*
*
+ava
ilabl
eCon
tent
s*
Abbildung 3.42: Kollaboration
99 KAPITEL 3. METAMODELL
Collaboration EineKollaborationbeschreibt, wie eine Operation (represented-Operation) oder ein Klassifizierer (representedClassifier) (z.B. ein Anwendungs-fall) durch die Benutzung von Klassifizierern und Assoziationen auf eine bestimmte Wei-se realisiert wird. Die Kollaboration definiert Rollen, die von Exemplaren und Linksgespielt werden, und Interaktionen, die die Kommunikationen zwischen den Exemplarendefinieren, während sie ihre Rollen spielen.
Eine Kollaboration spezifiert eine Sicht auf eine Gruppe von Klassifizierern. DieseSicht beschreibt die benötigten Beziehungen zwischen den Exemplaren der entsprechen-den Rollen der Klassifizierern sowie die benötigten Merkmale und enthaltenen Modell-elemente dieser Klassifizierer.
Verschiedene Kollaborationen können verschiedene Sichten auf die gleichen Klassifi-zierer beschreiben. Eine Kollaboration kann Modellelemente beinhalten, meistens Klas-sifizierer und Generalisierungen, die zur Darstellung der strukturellen Anforderungen zurErfüllung der Aufgabe der Kollaboration benutzt werden.
Eine Kollaboration ist ein verallgemeinerbares Element, d.h. sie kann eine Aufgabespezifizieren, die eine Spezialisierung der Aufgabe einer anderen Kollaboration ist.
Pseudoattribut Semantik
ownedElement (geerbt von Namespace) Rollen, die durch die Kollabo-ration definiert sind. Dies sindClassifierRoles undAssociationRoles.
interaction Bezeichnet die Interaktionen, die innerhalb der Kollaborationdefiniert sind.
constraining-Element
Modellelemente, die den Modellelementen der Kollaborationweitere Bedingungen hinzufügen (z.B. Generalisierungen, Zu-sicherungen).
Die Klassifizierer der Klassifiziererrollen, die Assoziationen der Assoziationsrollenund die zugesicherten Modellelemente (constrainingElement) müssen zum Namens-raum der Kollaboration gehören. Falls eine Klassifizierer- oder Assoziationsrolle keinenNamen hat, sollte sie die einzige ihres Basisklassifizierers bzw. ihrer Basisassoziationsein. Eine Kollaboration (im strukturellen Sinne) kann nur Klassifiziererrollen, Assozia-tionsrollen sowie die Generalisierungen und Zusicherungen zwischen ihnen enthalten.
Interaction Eine Interaktion spezifiziert die Kommunikation zwischen Modell-elementen zur Erfüllung einer bestimmten Aufgabe. Jede Interaktion ist im Kontext(context) einer Kollaboration definiert, d.h. auch für ein Sequenzdiagramm muß zu-mindest implizit ein Kontext existieren.
Im Metamodell enthält eine Interaktion Botschaften (Message), die die Kommuni-kation zwischen Exemplaren, entsprechend der Rollen ihrer Klassifizierer, spezifiziert.
3.2. VERHALTENSELEMENTE 100
Alle zu sendenen Signale müssen im Namensraum der Kollaboration, zu dem dieInteraktion gehört, enthalten sein.
Message Eine Botschaft (Nachricht) spezifiziert eine bestimmte Kommunikation zwi-schen Rollen von Exemplaren in einer Interaktion.
Pseudoattribut Semantik
sender Die Rolle des Exemplars, welches die Kommunikation initiiertund möglicherweise eine Antwort erhält.
receiver Die Rolle des Exemplars, welches die Botschaft empfängt undauf sie reagiert.
action Die Aktion, welche einen Stimulus entsprechend der Bot-schaft zum Senden veranlaßt. Auf diese Aktion wer-den der Botschaftsname, Argumente, Iterationsausdrücke und(Verzweigungs-)Bedingungen des Pfeils in einem Interaktions-diagramm abgebildet.
activator Eine Botschaft, deren Empfang das Verhalten, welches zumAbschicken dieser Botschaft führt, aktiviert. Dies ist die Bot-schaft, die eine Kommunikationssequenz innerhalb eines Ob-jekts initiiert. Diese Botschaft muß in der gleichen Interaktionenthalten sein.
communication-Connection
Die Assoziationsrolle bzw. der Link, der zur Kommunikationbenutzt wird.
predecessor Eine Menge von Botschaften, deren vollständige Ausführungdie Ausführung dieser Botschaft ermöglicht. Diese Botschaf-ten müssen in der gleichen Interaktion enthalten sein und dengleichen Aktivierer (activator) besitzen.
Der Sender und der Empfänger müssen an der Kollaboration, welche den Kontextdefiniert, teilnehmen. Ihre Rollen müssen durch die Kommunikationsverbindung (com-municationConnection) verbunden sein.
ClassifierRole Eine Klassifiziererrolleist eine bestimmte Rolle, die von einemTeilnehmer einer Kollaboration gespielt wird. Sie spezifiziert eine eingeschränkte Sichtauf die Merkmale eines Klassifizierers, die dazu dient, nicht benötigte Merkmale auszu-blenden bzw. einem Kommunikationspartner nicht zur Verfügung zu stellen. Die Klassi-fiziererrolle und ihre Merkmale werden in einem Klassenrechteck dargestellt.
Im Metamodell istClassifierRole Teil einer Kollaboration.availableFeaturespezifiziert die, in der Kollaboration zur Verfügung stehenden, Merkmale des Basisklas-sifizierers (base). availableContents spezifiziert eine Teilmenge des Inhalts des Mo-
101 KAPITEL 3. METAMODELL
dellelements des Basisklassifizierers. Das Attributmultiplicity gibt die Anzahl derExemplare an, die diese Rolle in der Kollaboration spielen.
AssociationRole Eine Assoziationsrolleist eine bestimmte Benutzung einer As-soziation in einer Kollaboration.
Im Metamodell ist eine Assoziationsrolle eine eingeschränkte Sicht auf eine Asso-ziation (base) in einer Kollaboration.AssociationRole ist eine Komposition von As-soziationsendrollen (connection) entsprechend den Assoziationsenden der Assoziation.Auch hier gibt das Attributmultiplicity die Anzahl der Exemplare an, die diese Rollein der Kollaboration spielen.
AssociationEndRole EineAssoziationsendrolleist der Endpunkt einer Assoziati-on in einer Kollaboration.
Das AttributcollaborationMultiplicity19 gibt die Anzahl der Link-Enden an,die diese Rolle in der Kollaboration spielen,base bezeichnet die zugehörige AssoziationundavailableQualifier gibt die in der Kollaboration benutzten Qualifizierer an.
3.2.3 Zustandsautomaten
Zustandsautomaten(endliche Automaten) bzw. Zustandsdiagramme (statecharts) wer-den zur Modellierung des dynamischen Verhaltens von Modellelementen eingesetzt. Beidiesen Elementen handelt es sich meist um Klassen bzw. deren Objekte, bei denen dieReaktion auf einEreignis, z.B. ein Operationsaufruf, von der Vergangenheit des Objektsabhängt.
Ein Zustandsautomat ist eine hypothetische Maschine, die sich in jedem Zeitpunkt ineiner Menge endlicher Zustände, auch Konfiguration genannt, befindet. Abhängig vonder Konfiguration, welche die relevante Vergangenheit eines modellierten Elements dar-stellt, können Ereignisse spezifiziert werden, auf die der Zustandsautomat (und damit dasElement) reagiert oder nicht reagiert. Die Reaktion des Automaten kann aus einerAktionund einerZustandsveränderung(Transition) bestehen.
Abbildung 3.43 zeigt beispielsweise einen Zustandsautomaten einer Klimaanlage.Durch diese Art der Modellierung kann die Aufrufreihenfolge der Operationen auf ei-nem Objekt eingeschränkt werden, die ein Objekt während seiner Lebensdauer ausführenkann.
In den beiden folgenden Abschnitten werden die Metamodellklassen der Ereignisseund Zustandsautomaten erläutert. Aktionen und ihre Metamodellklassen sind bereits be-handelt worden (siehe Seite 84).
19Ein Attribut mit dem Namenmultiplicity ist bereits inAssociationEnd deklariert.
3.2. VERHALTENSELEMENTE 102
Idle
Cooling Heating
Activating ActiveActivating Activeready / turnOn()
atTemp
tooHot( desiredTemp )
StartzustandEndzustand
Zustand
Transition
Ereignis (Parameter)
Ereignis/Aktion
Transitionen ohne Ereignis werden "triggerless" genannt
atTemp
TooCold( desiredTemp )
after( 1 hour ) / selfTest()
shutDown
tooCold( desiredTemp )
tooHot( desiredTemp )
Zeitereignis/Aktion
Abbildung 3.43: Zustandsautomat einer Klimaanlage
103 KAPITEL 3. METAMODELL
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).
TimeEvent
when : TimeExpression
ChangeEvent
changeExpression : BooleanExpression
Operation
CallEvent
1
*
1
+occurrence *
SignalEvent
Signal
*
1
+occurrence *
1
Parameter Event
* 0..1
+parameters
*
{ordered}
0..1
ModelElement
Abbildung 3.44: Metamodell der Ereignisse
Event Ein Ereignis ist eine Spezifikation eines wahrnehmbaren Vorkommens. EinEreignis besitzt einen Namen (geerbt vonModelElement) und kann durch Parameter(parameter) spezifiziert werden.Event ist eine abstrakte Metaklasse.
SignalEvent Ein Signal-Ereignisbezeichnet den (asynchronen) Empfang eines Si-gnals und ist im Metamodell mit diesem Signal assoziiert.
CallEvent EinAufruf-Ereignisrepräsentiert den Empfang (reception) eines Requests,eine Operation (operation) auszuführen.
Zwei Stereotypen eines Aufruf-Ereignisses sind definiert:
3.2. VERHALTENSELEMENTE 104
Stereotyp Semantik
«destroy» Eine Aufforderung an das empfangende Exemplar, sich zu zer-stören.
«create» Das empfangende Exemplar wurde gerade erzeugt. Dies ist daseinzige Ereignis, das an eine initiale Transition auf der ober-sten Ebene eines Zustandsautomaten geheftet werden kann.
TimeEvent Ein Zeit-Ereignismodelliert das Erreichen eines bestimmten Zeitpunkts(deadline), der durch einen Zeitausdruck (timeExpression) spezifiziert wird.
Bei der Interpretation des Laufzeitverhaltens des Zustandsautomaten stimmt der Zeit-punkt des Auftretens des Ereignisses mit dem Empfang des Ereignisses überein. Ein Er-eignis hat sogesehen keine zeitliche Dimension. Der modellierte Zeitpunkt (when) kannabsolut oder relativ (ein Timer) sein. Bei einem relativen Zeitpunkt ohne eine expliziteStartzeit beginnt der Timer mit der Aktivierung des Ausgangszustands der entsprechen-den Transition. Das Zeitereignis findet nur statt, wenn beim Erreichen der Deadline derAusgangszustand noch aktiviert ist.
Zeitereignisse werden durch das Schlüsselwortafter dargestellt, z.B.after (2 se-conds) undafter (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 undSeite 3-136). Die Wahl des Attributnamenswhen der MetamodellklasseTimeEvent istverwirrend.
ChangeEvent Ein Änderungs-Ereignis(change event) ist ein Ereignis, welches durcheine Veränderung des Systemszustands, d.h. eine Änderung von Attributwerten oderLinks, ausgelöst werden kann.
Ein Änderungsereignis wird durch das Schlüsselwortwhen, gefolgt von einem boo-leschen Ausdruck (changeExpression), modelliert. Bei der Interpretation des Laufzeit-verhaltens wird dieser boolesche Ausdruck fortlaufend ausgewertet. Falls die Auswertungden Wert wahr ergibt, findet das Änderungsereignis statt.
Ein Änderungsereignis unterscheidet sich von einer Bedingung (guard) einer Transiti-on (s.u.), die nur ausgewertet wird, wenn ein Ereignis stattfindet. Der boolesche Ausdruckeines Änderungs-Ereignisses wird solange fortlaufend ausgewertet, bis er wahr wird. DasEreignis bleibt bis zu seiner Bearbeitung bestehen, d.h. die Bearbeitung des Ereignis-ses wird unabhängig vom Wert des booleschen Ausdrucks zum Bearbeitungszeitpunktdurchgeführt.
Mit when formulierte „Zeitereignisse“ sind formal Änderungsereignisse. Läßt sichder Modellierer vom üblichen Sprachgebrauch leiten, kann dieses leicht zu Änderungser-eignissen der Artwhen (23:49PM) führen (Beispiel: [BRJ99a], Seite 317, Abb. 20-4),welches semantisch eher als Zeitereignis und nicht als Änderungsereignis (23:49PM istkein boolescher Ausdruck) interpretiert wird.
105 KAPITEL 3. METAMODELL
3.2.3.2 Zustandsautomat
Aktionensind ausführbare, atomare Verarbeitungen, die den Zustand des Systems ver-ändern. Die Dauer einer Aktion, z.B. ein Operationsaufruf, wird als vernachlässigbarinterpretiert. EineAktivität ist eine Folge von Aktionen und bezeichnet eine nicht-atomareAusführung innerhalb eines Zustands eines Zustandsautomaten. Eine Aktivität kann durchein Ereignis unterbrochen werden. Dies ist meistens eine Art Interrupt auf einer höherenEbene des Zustandsautomaten.
Ein Zustandist eine Bedingung oder eine Situation während der Existenz eines Ob-jekts. Während sich das Objekt in einem Zustand befindet, dem sogenanntenaktivenZustand, kann das Objekt Aktionen und Aktivitäten ausführen oder auf ein bestimmtesEreignis warten.
Ein Transitionist eine gerichtete Beziehung zwischen Zuständen. Tritt ein bestimmtesEreignis ein und ist eine optionale Bedingung erfüllt, „feuert“ die Transition, d.h. einZustandsübergang wird ausgeführt. Eine Transition besteht aus fünf Teilen:
1. DerEreignis-Triggerbezeichnet ein Ereignis, dessen Empfang es dem Zustandsau-tomaten ermöglicht, eine Transition durchzuführen.
2. Eine optionaleBedingung(engl. guard condition, auch Wächterbedingung ge-nannt) ist ein boolescher Ausdruck, der beim Empfang des Ereignis-Triggers ausge-wertet wird. Falls der Ausdruck zum Wert wahr ausgewertet wird, wird die Transiti-on durchgeführt. Wird keine Transition des Zustandsautomaten durch das Ereignis„getriggert“, gilt das Ereignis als bearbeitet.
3. DerQuell-Zustand(Ausgangszustand) bezeichnet den Zustand, der vor dem Feuernder Transition aktiv sein muß.
4. DerZiel-Zustand(Folgezustand) bezeichnet den Zustand, der nach dem Feuern derTransition aktiviert wird.
5. EineAktion, die beim Feuern der Transition, d.h. vor der Aktivierung des Folgezu-stands, ausgeführt wird.
Ein Zustand kann mehrere Bestandteile besitzen:
1. Ein Zustand kann einenNamenbesitzen. Zustände ohne Namen sind anonymeZustände.
2. Entry- und Exit-Aktionen, die beim Eintritt in den Zustand (derAktivierungdesZustands) bzw. beim Verlassen des Zustands (seinerDeaktivierung) ausgeführtwerden.
3. Eineinterne Transitionist eine Transition, bei der der Zustand nicht verlassen wird.Insbesondere werden bei internen Transitionen die Entry- und Exit-Aktionen nichtausgeführt.
3.2. VERHALTENSELEMENTE 106
4. Ein Zustand kannUnterzuständebesitzen. Dies sind Zustände, die einen Zustands-automaten oder mehrere nebenläufige Zustandstandsautomaten innerhalb eines Zu-standsautomaten repräsentieren. Der Zustand „Heating“ in Abb. 3.43 ist ein Bei-spiel eines Zustands, der Unterzustände besitzt. Abb. 3.46 zeigt einen Zustand, dernebenläufige Zustandsautomaten besitzt.
5. Normalerweise ignoriert ein Zustandsautomat Ereignisse, auf die er nicht durch ei-ne Transition reagieren kann. Die ignorierten Ereignisse gelten dann als verarbeitet.In der UML können zu einem Zustand Ereignisse spezifiziert werden, auf die in die-sem Zustand nicht reagiert wird, die aber in anderen Zuständen verarbeitet werdensollen. Diese Ereignisse werdenverzögerte Ereignisse(deferred events) genannt(siehe [BRJ99a], Seite 337). Die Verzögerung eines Ereignisses bedeutet, daß dasEreignis nicht stattgefunden hat. Ein verzögertes Ereignis ereignet sich erst bei derAktivierung eines Zustands, der dieses Ereignis nicht verzögert.
Falls nicht anders festgelegt, beginnt der Zustandsautomat eines Unterzustands in sei-nem Anfangszustand. In manchen Situationen (z.B. bei einem Interrupt auf einer höherenEbene) ist es wünschenswert, die Konfiguration eines komplexen Zustands (Komposi-tionszustand) zu speichern, damit dieser bei der nächsten Aktivierung wiederhergestelltwerden kann. Dazu bietet die UML das Konzept der Erinnerungszustände (history-states)an. Ein Erinnerungszustand ist ein Pseudozustand, der es einem Zustand ermöglicht, sichseinen letzten aktiven Unterzustand zu merken (siehe Abb. 3.45).
Ist eine Reaktivierung eines Kompositionszustands in seiner vorherigen Konfigurationerwünscht, wird dies durch eine Transition zum Erinnerungszustand modelliert. Bei dererstmaligen Aktivierung besitzt der Kompositionszustand keine Vergangenheit und dievom Erinnerungszustand ausgehende Transition wird ausgeführt (siehe Abb. 3.45).
Durch die Verschachtelung von Zuständen ergibt sich ein Baum von Zuständen. DieKnoten des Baums sind Kompositionszustände, die Blätter sind einfache Zustände oderPseudozustände. In der UML sind zwei Arten von Erinnerungszuständen definiert:flacheund tiefe Erinnerungszustände. Ein flacher Erinnerungszustand (shallow history) spei-chert den letzen direkten aktiven Unterzustand eines Kompositionszustands (den aktivenZustand der nächsten Ebene des Baum). Flache Erinnerungszustände werden, wie inAbb. 3.45, durchH dargestellt. Ein tiefer Erinnerungszustand (deep history) speichertdie aktiven Zustände des gesamten Teilbaums des Kompositionszustands. Tiefe Erinne-rungszustände werden durch „H∗“ dargestellt.
Kompositionszustände können nebenläufige Bereiche enthalten, die jeweils einen Zu-standsautomaten 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 Zustandsautomatist ein Modellelement, welches die möglicheDynamik eines Modellelements (context) beschreibt. Dieses Modellelement ist entwe-
107 KAPITEL 3. METAMODELL
Command
BackingUp
H
Collecting
Copying
CleaningUp
H
Collecting
Copying
CleaningUp
queryStartzustand der ersten Aktivierung von "BackingUp"
flacher Erinnerungszustand (shallow history): speichert den letzten aktiven Zustand von "BackingUp"
Abbildung 3.45:Erinnerungszustände speichern den letzen aktiven Zustand eines Kom-positionszustands (hier: BackingUp), der bei erneuter Aktivierung zurWiederherstellung der letzten Konfiguration des Kompositionszustandsgenutzt wird. Das Beispiel zeigt den Zustandsautomaten eines Backup-Programms ohne Endzustand, welches z.B. für die Datensicherung einesNetzwerks eingesetzt wird. Ein Systemoperator kann das Programm zuInformationszwecken unterbrechen. Danach setzt das Programm seineTätigkeit, ausgehend von der letzten Konfiguration, fort.
3.2. VERHALTENSELEMENTE 108
Chart Name : Backup - HistoryStatesChart Filename : nebenlaeufigeZA.VobChart Type : UML State Diagram
Vorbereitung
RadioAus RadioAn
ComputerAus ComputerAn
Arbeit
RadioAus RadioAn
ComputerAus ComputerAn
Arbeit
RadioAn
ComputerAn
when(istGenug)
Abbildung 3.46:Der Zustand „Vorbereitung“ besteht aus zwei nebenläufigen Bereichen.Der Zustand „Arbeit“ wird aktiviert, wenn beide Zustandsautomaten dernebenläufigen Bereiche ihren Endzustand erreicht haben.
109 KAPITEL 3. METAMODELL
Pse
udos
tate
kind
: P
seud
osta
teK
ind
Sim
pleS
tate
Syn
chS
tate
boun
d : U
nlim
itedI
nteg
er Stu
bSta
te
refe
renc
eSta
te :
Nam
e
Fin
alS
tate
Com
posi
teS
tate
isC
oncu
rent
: B
oole
an
Gua
rd
expr
essi
on :
Boo
lean
Exp
ress
ion
Sta
teV
erte
x
1..*
0..1
+sub
vert
ex
1..*
+co
ntai
ner
0..1
Eve
nt
Act
ion
Mod
elE
lem
ent
Tra
nsiti
on
1
0..1 1
+gu
ard
0..1
0..1
*
+tr
igge
r0.
.1
*1
*
+so
urce
1
+ou
tgoi
ng *
1*
+ta
rget
1
+in
com
ing *
0..1
0..1
+ef
fect
0..1
0..1
Sta
te
0..*
0..*
0..*
+de
ferr
able
Eve
nt 0..*
*
0..1
+in
tern
al*
0..1
0..1
0..1
0..1
+en
try
0..1
0..1
0..1
0..1
+ex
it
0..1
0..1
0..1
0..1
+do
Act
ivity0..1
Sub
mac
hine
Sta
te
Sta
teM
achi
ne
*0..1
+be
havi
or*
+co
ntex
t0.
.1
*
0..1
+tr
ansi
tion
*
0..1
1
0..1
+to
p1
0..1
*
1
*
+su
bmac
hine1
Abbildung 3.47: Metamodell des Zustandsautomaten
3.2. VERHALTENSELEMENTE 110
der ein Klassifizierer oder ein Verhaltenselement. Ein Modellelement kann durch mehrereZustandsautomaten beschrieben werden.
Ein Zustandsautomat setzt sich aus Zuständen zusammen, die Aktionen, Transitionenund Bedingungen enthalten können. Ein Zustandsautomat kann neben Kompositions-zuständen auch Zustände enthalten, die andere Zustandsautomaten repräsentieren (sieheSubmachineState, Seite 113), die irgendwo im Modell spezifiziert sind.
top bezeichnet die Wurzel (Top-Level-Zustand) im Baum der Zustände eines Zu-standsautomaten. Ein Zustandsautomat besitzt genau einen Top-Level-Zustand, der einKompositionszustand (sieheCompositeState) sein muß. Der Top-Level-Zustand kannkeine Quelle einer Transition sein und kann in keinem anderen (Kompositions-) Zustandenthalten sein. Wenn ein Zustandsautomat ein Verhaltensmerkmal beschreibt, kann er,mit Ausnahme der initialen Transition, keinen Trigger vom TypCallEvent enthalten.
CompositeState Ein Kompositionszustandist ein Zustand, der einen oder mehrereUnterknoten (Unterzustände) enthält. Ein Zustand (StateVertex) kann zu maximal ei-nem Kompositionszustand gehören (Semantik einer Komposition). Jeder in einem Kom-positionszustand enthaltende Zustand heißtUnterzustanddes Kompositionszustands. Erheißtdirekter Unterzustand, wenn er in keinem weiteren Zustand enthalten ist. Anson-sten wird ertransitiv verschachtelter Unterzustandgenannt. Ein Kompositionszustandkann maximal einen Anfangszustand, einen flachen und einen tiefen Erinnerungszustandbesitzen.
Falls das boolesche AttributisConcurrent wahr ist, besteht der Kompositionszu-stand aus zwei oder mehreren direkten nebenläufigen Bereichen (auch Regionen genannt).
StateVertex Ein Zustandsknotenist eine abstrakte Metaklasse, die einen Zustandeines Zustandsautomaten bzw. einen Knoten eines Zustandsdiagramms darstellt. DieseKnoten können Quelle und Ziel einer Transition sowie Teil eines Kompositionszustands(container) sein.
Transition EineTransitionist eine gerichtete Beziehung zwischen einem Quellzu-standsknoten (source) und einem Zielzustandsknoten (target). trigger bezeichnet einEreignis (optional), das zum „Feuern“ der Transition führen kann, wenn eine optionalgegebene boolesche Bedingung (guard) erfüllt ist.
Transitionen ohne Ereignisse werden „triggerless“ genannt.effect ist eine optionaleAktion, die während der Transition ausgeführt wird.
Guard EineBedingung(Wächterbedingung) ist ein boolescher Ausdruck, der an eineTransition geheftet ist und das Feuern der Transition kontrolliert. Der Ausdruck wird aus-gewertet, wenn das mit der Transition assoziierte Ereignis (trigger) eintritt. Wenn dieAuswertung den Wert wahr ergibt, wird die Aktion (effect) ausgeführt und der Folge-
111 KAPITEL 3. METAMODELL
zustand aktiviert. Die booleschen Ausdrücke der Transitionen sollten reine Funktionen,d.h. ohne Seiteneffekte, sein.
State Ein Zustandist eine abstrakte Metaklasse, die eine Situation repräsentiert, inder eine (meist implizite) Bedingung gilt (z.B. Warten auf ein Ereignis, Ausführen einerAktivität).
Pseudoattribut Semantik
stateMachine Zustandsautomat, zu dem der Zustand gehören kann.internal Bezeichnet eine Transition, die zum Zustand selbst gehört (in-
terne Transition). Die Ausführung dieser Transition führt nichtzur Anwendung der Entry- und Exitaktionen, d.h. diese Tran-sition führt nicht zu einer Zustandsveränderung des Zustands-automaten.
entry Bezeichnet eine Aktion, die bei der Aktivierung des Zustandsausgeführt wird (Eintrittsaktion).
exit Bezeichnet eine Aktion, die bei der Deaktivierung des Zu-stands ausgeführt wird (Austrittsaktion).
doActivity Bezeichnet eine Aktivität (Action kann eine Sequenz von Ak-tionen sein), die ausgeführt wird, wenn der Zustand aktiviertist.
deferrableEvent Bezeichnet Ereignisse, die verzögert werden, wenn dieser Zu-stand aktiv ist.
SimpleState Ein einfacherZustand bezeichnet einen Zustand ohne Unterzustände.
FinalState Ein End-Zustandist ein spezieller Zustand, der angibt, daß sein Contai-ner (ein Kompositionszustand) verarbeitet ist. Ist dieser Kompositionszustand der Top-Zustand des Zustandsautomaten, dann ist der Zustandsautomat vollständig verarbeitet.Ein End-Zustand besitzt keine ausgehenden Transitionen.
PseudoState Ein Pseudozustandist ein Hilfszustand, der aus technischen Gründenbenötigt wird. Die folgenden sieben Arten eines Pseudozustands (Attribut:kind) sinddefiniert:
• initial: Ein Initialpseudozustand ist der Anfangszustand eines Zustandsautoma-ten bzw. eines Kompositionszustands. Ein Kompositionszustand hat maximal einenAnfangszustand.
3.2. VERHALTENSELEMENTE 112
• deepHistory: (tiefer Erinnerungszustand) Eine Notation, die die letzte aktive Kon-figuration des Kompositionszustands repräsentiert, der diesen Pseudozustand ent-hält (H∗). Ein Kompositionszustand hat maximal einen solchen Knoten. Eine Tran-sition kann diesen Knoten als Quelle mit einem Initialzustand als Ziel verbinden.Diese Transition wird ausgeführt, wenn der Kompositionszustand erstmalig akti-viert wird.
• shallowHistory: (flacher Erinnerungszustand) Repräsentiert den letzten aktivendirekten Unterzustand des umschließenden Kompositionszustands, jedoch nicht dieverschachtelten Unterzustände (H). Ein Kompositionszustand kann maximal einensolchen Knoten haben.
• join: Dient der Zusammenfassung (Synchronisation) mehrerer Transitionen ausnebenlä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 verschie-dene Ziele haben (Nebenläufigkeit). Transitionen, die von diesem Knoten wegfüh-ren dürfen keine Bedingungen (guards) haben. In Abb. 4.63 auf Seite 190 ist einBeispiel angegeben.
• junction: Knoten, die der Verknüpfung mehrerer Transitionen dienen. Sie werdenzur Konstruktion komplexer Transitionspfade zwischen Zuständen benutzt. DieserKnoten kann benutzt werden, um mehrere eingehende Transitionen in eine einzigeausgehende Transition zu vereinen. Dies wird „mischen“ (merge) genannt. Ande-rerseits kann der Knoten zur Aufspaltung einer eingehenden Transition in mehre-re ausgehende Transitionen mit verschiedenen Bedingungen (guards) benutzt wer-den. Dies wirdstatisch bedingte Verzweigung(static conditional branch) genannt.Ausgehende Transitionen, deren Bedingungen als falsch bewertet werden, werdendeaktiviert. Die vordefinierte Bedingungelse kann für maximal eine Transitionbenutzt werden. Sie wird als wahr bewertet, wenn alle anderen Bedingungen nichtzutreffen. In Abb. 4.66 auf Seite 193 ist ein Beispiel angegeben.
• choice: Auswahlknoten, mit dem einedynamisch bedingte Verzweigungrealisiertwerden kann. Beim Erreichen des Knotens werden die Bedingungen der ausgehen-den Transitionen ausgewertet. Wenn mehrere Bedingungen gültig sind, wird eineder gültigen Transitionen durch eine Funktion ausgewählt. Falls keine Bedingunggilt, ist das Modell nicht wohldefiniert. In Abb. 4.67 auf Seite 193 ist ein Beispielangegeben.
SyncState Ein Synchronisationszustandist ein Knoten, der zur Synchronisation ne-benläufiger Regionen eines Zustandsautomaten benutzt wird. In Abb. 4.64, auf Seite191 ist ein Beispiel angegeben. Ein Synchronisationszustand wird nicht wie ein Zustand
113 KAPITEL 3. METAMODELL
(State) auf einen booleschen Wert (aktiv, nicht aktiv), sondern auf einen Integer (bound)abgebildet. Ein Synchronisationszustand wird zusammen mit fork und join benutzt, umsicherzustellen, daß eine Region einen bestimmten Zustand oder bestimmte Zustände ver-läß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 zwischender Anzahl der „gefeuerten“ eingehenden und ausgehenden Transitionen spezifiziert. Alleeingehenden Transitionen müssen aus dem gleichen Bereich kommen und alle ausgehen-den Transitionen müssen ihr Ziel ebenfalls in einem Bereich haben.
SubmachineState Ein Unterautomatenzustandist eine syntaktische Annehmlich-keit, die Wiederbenutzung und Modularität ermöglicht. Er stellt eine notationelle Abkür-zung eines Zustandsautomaten (submaschine) dar, die eine makroähnliche Expansionder Abkürzung durch den Zustandsautomaten ermöglicht. Der eingesetzte Zustandsauto-mat heißtreferenzierterZustandsautomat. Der Zustandsautomat, der den Unterautomatenenthält heißtContainerzustandsautomat. Effektiv repräsentiert ein Unterautomatenzu-stand einen Aufruf des assoziierten Zustandsautomaten.
In einem Zustandsdiagramm wird der referenzierte Zustandsautomat nicht vollständigdargestellt. Transitionen in einen Unterautomatenzustand hinein oder aus ihm heraus,werden durch Stummelzustände (StubState) dargestellt (Beispiel: Abb. 4.68, Seite 194).
StubState Ein Stummelzustandkann innerhalb eines Unterzustandsautomaten auf-treten und repräsentiert einen Unterknoten eines referenzierten Zustandsautomaten (re-ferenceState). Er kann als Quelle oder Ziel einer Transition dienen, die einen Zu-standsknoten eines Zustandsautomaten mit einem Unterzustandsknoten des referenziertenZustandsautomanten verbindet.
3.2.4 Aktivitätsgraphen
Mit Aktivitätsgraphen bzw. Aktivitätsdiagrammen kann funktionales Verhalten von Mo-dellelementen beschrieben werden. Sie werden zur Ablaufbeschreibung komplexer Ope-rationen (flowchart) und zur Verfeinerung (von Operationen) von Anwendungsfällen (work-flow) eingesetzt.
Aktivitätsdiagramme sind spezielle Zustandsdiagramme. Ein Aktivitätsdiagramm stelltnicht den Klassifizierer, der Aktionen ausführt, sondern die Reihenfolge und die Bedin-gungen der Aktionen in den Vordergrund. Die meisten Zustände eines Aktivitätsgraphensind Aktivitätszustände, die sich dadurch auszeichnen, daß sie eine Aktivität ausführenund die Vervollständigung dieser Aktivität einen Zustandsübergang (Transition) auslöst.
Eine Aktivität hat mindestens eine ausgehende Transition. Mehrere ausgehende Tran-sitionen werden zur Fallunterscheidung benutzt. Aktivitätsdiagramme können nebenläufi-ge Aktivitäten beschreiben. Für parallele Aktivitäten gilt, daß ihre Reihenfolge irrelevantist. Abbildung 3.48 zeigt ein Aktivitätsdiagramm mit den wichtigsten Modellelementen.
3.2. VERHALTENSELEMENTE 114
Synchronisationsbalken
Aktivität
Entscheidung
Bedingung
Bestimme Getränk
Kaffeepulver in Filter einfüllen
Behälter mit Wasser auffüllen
Tassenholen
Filter in Maschineeinsetzen
Maschine anschalten
Kaffee filtern
Kaffeeeinschenken
Coladosenholen
Getränktrinken
[Kaffee gefunden]
[kein Kaffee]
[Cola gefunden]
[keine Cola]
Chart Name : KaffeeChart Filename : D:\Home\Stephan\vuml\kaffee.VobChart Type : UML Activity Diagram
Abbildung 3.48: Nebenbeschäftigung der (Java) Programmierer
115 KAPITEL 3. METAMODELL
Act
ionS
tate
isD
ynam
ic :
Boo
lean
dyna
mic
Arg
umen
ts :
Arg
List
sExp
ress
ion
dyna
mic
Mul
tiplic
ity :
Mul
tiplic
ity
Sim
pleS
tate
Sub
activ
ityS
tate
isD
ynam
ic :
Boo
lean
dyna
mic
Arg
umen
ts :
Arg
List
sExp
ress
ion
dyna
mic
Mul
tiplic
ity :
Mul
tiplic
ity
Sub
mac
hine
Sta
te
Com
posi
teS
tate
isC
oncu
rent
: B
oole
an
Cal
lSta
te
Act
ivity
Gra
phP
artit
ion
10.
.*1
+pa
rtiti
on 0..*
Mod
elE
lem
ent
* *
+co
nten
ts* *
Sta
teM
achi
ne
0..1
*
+con
text
0..1
+be
havi
or
*
Sta
te
0..1
10..1
+to
p1
Cla
ssifi
erIn
Sta
te
0..*
*
0..*
+in
Sta
te
*
Par
amet
er
Cla
ssifi
er
1 *
+typ
e1 *
Obj
ectF
low
Sta
te
isS
ynch
: B
oole
an
**
+pa
ram
eter
*
+st
ate
*
1
*
+typ
e
1
*
Abbildung 3.49: Metamodell: Aktivitätsgraph
3.2. VERHALTENSELEMENTE 116
Die Metamodellklassen eines Aktivitätsdiagramms sind überwiegend Spezialisierun-gen der Metamodellklassen eines Zustandsautomaten (Abb. 3.49).
ActivityGraph Ein Aktivitätsgraph spezifiziert das Verhalten eines Pakets, einesKlassifizierers oder eines Verhaltensmerkmals (context) (Abb. 3.49).
Eine Partition (partition) teilt die Zustände (contents) eines Aktivitätsgraphen inGruppen auf. Diese Gruppen werden auch Schwimmbahnen (swimlanes) genannt. DiePartitionierung entspricht häufig den organisatorischen Einheiten in einem Geschäftsmo-dell (z.B. Einkauf, Verkauf, usw.). Partitionen haben keinen Einfluß auf die dynamischeSemantik eines Modells, sie sind ein Hilfsmittel zum besseren Verständnis.
SubactivityState Ein Unteraktivitätszustandrepräsentiert die Ausführung einernicht-atomaren Folge von Schritten, die „einige“ Zeit in Anspruch nimmt. Ein Unterakti-vitätszustand ist ein Unterautomatenzustand, der einen verschachtelten Aktivitätsgraphenausführt.
Attribut Semantik
isDynamic Boolescher Ausdruck, der angibt, ob die Aktivität nebenläufigausgeführt werden kann.
dynamicArguments Bestimmt die Anzahl der parallelen Ausführungen der Un-termaschinen des Zustands. Der Wert muß eine Menge vonListen von Objekten sein, die jeweils Argumente für eineAusführung enthält. Dieser Ausdruck wird ignoriert, wennisDynamic den Wert „false“ hat.
dynamic-Multiplicity
Eine Kardinalität, die die Anzahl der parallelen Ausführungender Aktionen des Zustands beschränkt. Wird ignoriert, wennisDynamic den Wert „false“ hat.
Pseudoattribut Semantik
submaschine Geerbt vonSubmaschineState. Bezeichnet den referenzier-ten Aktivitätsgraphen innerhalb des Unteraktivitätszustand.Der Aktivitätsgraph muß einen Anfangszustand und einenEndzustand haben.
ActionState Ein Aktionszustandbezeichnet die Ausführung einer atomaren Aktion,typischerweise den Aufruf einer Operation.
Ein Aktionszustand ist ein einfacher Zustand mit einer Eintrittsaktion (Entry),desseneinzige ausgehende Transition durch die Vervollständigung der Eintrittsaktion getriggertwird. Ein Aktionszustand kann mehrere Aktionen als Teil seiner Eintrittsaktion, aber
117 KAPITEL 3. METAMODELL
keine Exit-Aktionen, interne Transitionen oder do-Aktivitäten haben.Attribut Semantik
isDynamic Boolescher Ausdruck, der angibt, ob die (Eintritts-) Aktionennebenläufig ausgeführt werden können.
dynamicArguments Bestimmt zur Laufzeit die Anzahl der parallelen Ausführungender Aktionen des Zustands. Der Wert muß eine Menge vonListen von Objekten ergeben. Jede Liste dient als Argumentfür eine parallele Ausführung. Dieser Ausdruck wird ignoriert,wennisDynamic den Wert „false“ hat.
dynamic-Multiplicity
Eine Kardinalität, die die Anzahl der parallelen Ausführungender Aktionen des Zustands beschränkt. Wird ignoriert, wennisDynamic den Wert „false“ hat.
Pseudoattribut Semantik
Entry Geerbt vonState. Bezeichnet die Eintrittsaktionen.
CallState Ein Aufrufzustandist ein Aktionszustand mit genau einer Aufrufaktionals Eintrittsaktion. Aufrufzustände dienen der notationellen Vereinfachung.
ObjectFlowState Ein Objektflußzustanddefiniert einen Objektfluß zwischen Ak-tionen in einem Aktivitätsgraph (siehe Abb. 3.50). Er bezeichnet die Verfügbarkeit einesExemplars eines Klassifizierers, möglicherweise in einem bestimmten Zustand. Die Ver-fügbarkeit ist meistens das Resultat einer Operation.
Objekt[Zustand]
Aktivität1 Aktivität2
Chart Name : ObjektflussChart Filename : D:\Home\Stephan\vuml\actUntitled1.VobChart Type : UML Activity Diagram
Abbildung 3.50:Als Resultat der Aktivität1 befindet sich das Objekt in dem angegebenenZustand. Aktivität2 setzt den Zustand des Objekts voraus.
Die Generierung eines Objekts durch eine Aktion eines Aktionszustands kann als Ob-jektfluß modelliert werden, der durch die Vervollständigung des Aktionszustands getrig-gert wird. Die Benutzung des Objekts in einem nachgeordneten Aktionszustand kann alsausgehende Transition des Objektflußzustands, die eine eingehende Transition des Akti-onszustands ist, modelliert werden.
3.2. VERHALTENSELEMENTE 118
Attribut Semantik
isSynch Boolescher Ausdruck, der angibt, ob ein Objektflußzustand alsSynchronisationszustand benutzt wird.
Pseudoattribut Semantik
type Bezeichnet den Klassifizierer des Objekts. Der Klassifiziererkann vom TypClassifierInState sein (s.u.), d.h. der Zu-stand kann spezifiziert werden.
parameter Ein- oder Ausgabeparameter des Objekts. Die Parameter müs-sen einen Typ und eine Richtung (direction) haben, die kom-patibel mit dem Klassifizierer (type) sind.
Stereotyp Semantik
«signalflow» Wird zur Hervorhebung benutzt, wenn der Typ des Objektfluß-zustands ein Signal ist.
ClassifierInState EinClassifierInState bezeichnet einen Klassifizierer (type),der sich in einem bestimmten Zustand (inState) befindet. Diese Art eines Klassifiziererskann 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 inbestimmten Zuständen befinden.
PseudoState (siehe auch Seite 111.) In Aktivitätsgraphen können ein- und ausge-hende Transitionen der Pseudozuständefork und join jeden Zustandsknoten (State-Vertex) als Quelle bzw. Ziel haben. Anders als in Zustandsautomaten ist die Benutzungvon 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 dieMöglichkeiten, in welchem Rahmen ein Werkzeug Konsistenz (Widerspruchsfreiheit) si-cherstellen bzw. Konsistenzprüfungen ermöglichen kann, um sowohl Widersprüche alsauch Unvollständigkeiten in einer Systemspezifikation in UML zu verhindern oder zuentdecken.
Als Beispiel für ein existierendes Werkzeug wird Rational Rose 98 vorgestellt. Ratio-nal Rose enthält selbst nur wenige Möglichkeiten zur Konsistenzprüfung, bietet aber dieMöglichkeit, Konsistenzprüfungen und Vervollständigungen von Modellen durch Skriptezu realisieren.
Es wird erläutert, wie Ausschnitte von UML-Diagrammen (Klassen-, Interaktions-und Zustandsdiagramme) auf die Metamodellklassen der UML abgebildet werden undwelche Konsistenzbedingungen zwischen den Modellelementen existieren (ohne Anspruchauf Vollständigkeit).
Die Skriptsprache von Rational Rose 98 (kurz: Rose) läßt auf ein eigenes realisier-tes „Metamodell“ der UML schließen, welches von Rose benutzt wird. Die Abbildungvon Ausschnitten aus Diagrammen auf die Rose-Metamodellklassen zeigt, welche Kon-sistenzprü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üt-zung durch ein Werkzeug. In realen Entwicklungsprojekten führen bereits wenige An-wendungsfälle zuvielenverschiedenen Diagrammen, die teilweise selbst relativkomplexsind. Veränderungen in einem Diagramm führen zu weiteren Veränderungen in abhängi-gen Diagrammen. So führt z.B. ein Operationsaufruf einer nichtvorhandenen Operation ineinem Interaktionsdiagramm zu einer Inkonsistenz, wenn die Klasse des Empfangsobjektsdiese Operation nicht deklariert. Wird der Name einer Klasse in einem Diagramm geän-dert, 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 durchdie „Synchronisation“ der Diagramme untereinander zur Sicherstellung eines konsisten-ten Systementwurfs verursacht, die ohne Werkzeugunterstützung jeden wirtschaftlichenRahmen sprengen würden.
Ein UML-Werkzeug sollte die folgenden Merkmale unterstützen:
• Zeichnen von Diagrammen: Ein Werkzeug sollte nicht nur das reine Zeichnenaller Diagramme in ihrer gesamten Komplexität ermöglichen, sondern die Notati-on der Diagrammelemente verstehen und unterstützen, ohne die Freiheit des Mo-dellierers einzuschränken. So sollte z.B. im Falle zweier assoziierter Klassen dasVerschieben einer Klasse nicht dazu führen, daß die Verbindungslinie zwischen denKlassen mitten durch eine andere Klasse verläuft.
Das Werkzeug sollte die Semantik der UML zumindest soweit verstehen, daß einegrundsätzlich falsche Benutzung von Modellelementen nicht möglich ist und voreiner inkonsistenten Benutzung gewarnt wird.
Das Werkzeug sollte Änderungen an der Spezifikation eines Modellelements in ei-nem Diagramm automatisch für das gesamte Modell durchführen.
• Fachlexikon: Das Werkzeug sollte die zentrale Speicherung von Fachbegriffendes Anwendungsbereichs unterstützen, damit Kommunikationsstörungen zwischenEntwicklern 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 Ar-beit an einem Modell ermöglichen, ohne daß sie sich gegenseitig behindern.
• Konsistenzprüfung: Da ein UML-Modell nicht zu jedem Zeitpunkt der Modellie-rung konsistent sein kann, sollte das Werkzeug eine dem Entwicklungsstand ange-paßte Konsistenzprüfung auf Wunsch des Benutzers ermöglichen. Je früher Inkon-sistenzen aufgedeckt werden, desto geringer sind die Fehlerbeseitigungskosten.
• Codeerzeugung:Das Werkzeug sollte aus den (mühsam gesammelten) Informa-tionen des Modells Codefragmente in der gewünschten Implementationsspracheerzeugen können. Auch hier ist eine Konsistenzprüfung vor der Codeerzeugungsinnvoll.
• Reverse-Engineering:Da die UML auch zur Dokumentation bestehender Systemegenutzt werden kann, sollte das Werkzeug aus vorhandenem Code Modelle erzeu-gen können. Dies ermöglicht zusammen mit der Codeerzeugung das sogenannteRound-Trip-Engineering, d.h. Veränderungen in der tatsächlichen Realisierungdes 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 Model-lelement gehörenden Informationen generieren, d.h. z.B. in welchen Diagrammenund mit welchen anderen Modellelementen ein Modellelement benutzt wird.
• Wiederverwendbarkeit: Ein Vorteil des objektorientierten Ansatzes, sei es nunder Entwurf oder die Implementierung in einer objektorientierten Sprache, ist dieWiederverwendbarkeit von bestehenden objektorientierten Systemen. Deshalb soll-te das Werkzeug nicht nur in der Lage sein, Teile von Modellen aus früheren Pro-jekten zu importieren, sondern im Falle des Imports von Komponenten auch derenRealisierung.
Zur Unterstützung der Wiederverwendbarkeit ist eine Datenbank vorhandener (undbewährter) Modelle sinnvoll. In diesem Zusammenhang ist auch eine Analyse-und Entwurfsmusterdatenbank wünschenswert. Diese Muster (patterns) stellen (ab-strakte) Lösungen für häufig auftretene Probleme dar, die bereits verifiziert sind undsich in der Praxis bewährt haben.
• Anpassungsfähigkeit und Erweiterbarkeit: Das Werkzeug sollte an die Anfor-derungen spezieller Einsatzgebiete, z.B. Geschäftsprozeßmodellierung oder Mo-dellierung von Echtzeitsystemen angepaßt oder erweitert werden können.
• Schnittstellen zu anderen Werkzeugen:Das Werkzeug sollte Schnittstellen zuanderen in einer Systementwicklung eingesetzten Werkzeugen, z.B. Programmier-umgebung (Editor, Compiler, Debugger), Projektmanagement, Konfigurations- undVersionsmanagement, besitzen.
• Interoperabilität mit anderen UML-Werkzeugen: Das Werkzeug sollte UML-Modelle exportieren und von anderen Werkzeugen importieren können.
4.2 Konsistenz
Das UML-Metamodell definiert Modellelemente in Form von abstrakten und konkretenMetamodellklassen, Regeln zur Verwendung der Modellelemente und die daraus resultie-rende Semantik und Bedingungen, welche die Verwendungsmöglichkeiten auf Grund derSpezifikation der Modellelemente einschränken. So sind z.B. Klassen generalisierbareModellelemente, die durch Attribute und Operationen spezifiziert und durch Generali-sierungen miteinander verbunden werden können, falls bestimmte Bedingungen, z.B. diemehrfache Deklaration eines Attributs in einer Klasse und einer Oberklasse, nicht verletztwerden. Es gibt Modellelemente, deren Existenz die Existenz anderer Modellelementevoraussetzt. So setzt z.B. eine Botschaft, die eine Operation auf einem Objekt aufruft,voraus, daß das Objekt auf einer existierenden Klasse basiert, welche die aufzurufendeOperation deklariert hat.
4.2. KONSISTENZ 122
Bei der Modellierung eines Systems mit der UML wird das System üblicherweisedurch 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 System-
spezifikation
Met
amo
del
leb
ene
UML-Metamodell(in UML-Notation dargestellt)
Besteht aus:
• abstrakten Metaklassen (ModelElement, Classi-fier, Relationship usw.),
• konkreten Metaklassen (Class, Attribute, Asso-ciation usw.), deren Exemplare (Modellelemente) eine
graphische Darstellung besitzen und/oder zur Spezifikation
eines Modells benutzt werden
• Generalisierungen und Assoziationen zwischen den Me-
taklassen.
Das Metamodell definiert die Semantik der Metaklassen, mög-
liche und notwendige Beziehungen zwischen Modellelementen
sowie Bedingungen an die Spezifikation der Modellelemente,
die auch von der Beziehung zu anderen Modellelementen ab-
hängen können.
UML Notation
Guide der OMG
• Erläutert die graphische Dar-
stellung der semantischen Kon-
zepte (forward mapping to no-
tation).
• Beschreibt verschiedene Optio-
nen zur Darstellung von Mo-
dellinformationen (Auslassung
von Informationen bis hin zu
alternativen Darstellungen, läßt
Freiraum für Werkzeuge)
Mo
del
leb
ene
Metamodellexemplar(formales, i.a. nicht sichtbares UML-Modell)
• Besteht aus Exemplaren der konkreten Metaklassen (z.B.
der Klasse „Person“ und dem Attribut „name“).
• Kann als Objektdiagramm dargestellt werden, deren Ob-
jekte und Links auf den Klassen bzw. Assoziationen des
Metamodells basieren.
UML-Modell(graphische Darstellung)
Besteht aus verschiedenen, ineinan-
dergreifenden Sichten auf ein System.
Die Sichten bestehen aus Dia-
grammen, die Elemente eines Sys-
tems und ihre gegenseitigen Bezie-
hungen spezifizieren und darstellen.
Exemplar von
beschreibt
Semantik und
BedingungenNotation
Abbildung 4.1:Metamodell, Metamodellexemplar und die Sicht des Benutzers auf dasModell.
Formal kann ein solches UML-Modell auch durch ein Metamodellexemplar (Modell)beschrieben werden (siehe Abb. 4.1), bei der die Modellelemente des UML-ModellsInstantiierungen der Metamodellklassen sind. In UML-Notation wäre dies eineinzigesObjektdiagramm, dessen Objekte und Links auf den Klassen und Assoziationen des Me-tamodells basieren (siehe Abb. 4.2). Ein solches Metamodellexemplar wird bereits durchdie Verwendung weniger Modellelemente so unübersichtlich, daß niemand ernsthaft ver-suchen wird, ein Metamodellexemplar eines UML-Modells mit mehreren Diagrammendarzustellen.
123 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
Abbildung 4.2: Die Klasse „Person“ als Metamodellexemplar.
4.2. KONSISTENZ 124
Diagramme und Sichten eines UML-Modells, die die Zusammenhänge zwischen Mo-dellelementen darstellen, zeigen eine Sicht auf einen Ausschnitt des Metamodellexem-plars.
Ein UML-Modell ist konsistentbzw. widerspruchsfrei zum UML-Metamodell, wennein durch die Diagramme und Sichten beschriebenes Metamodellexemplar existiert. Indiesem Fall sind die Bedingungen des Metamodells erfüllt, d.h. die Sichten auf das Me-tamodellexemplar bzw. auf das System widersprechen sich nicht.
Da ein UML-Modell aus ineinandergreifenden Sichten und Diagrammen besteht, reichtes nicht aus, jedes einzelne Diagramm auf Einhaltung der Bedingungen des Metamodellszu überprüfen, d.h. eine Überprüfung eines UML-Modells auf Einhaltung der Bedingun-gen des Metamodells muß notwendigerweise auf einem äquivalenten diagrammübergrei-fenden Metamodellexemplar basieren.
4.2.1 Sinn einer Konsistenzprüfung
Wie jedes Projekt steht ein Softwareentwicklungsprojekt unter Kostendruck. Betrachtetman die Fehlererkennungs- und -beseitigungskosten ([Bal98], Seite 286) einer Software-entwicklung, so ist offensichtlich, daß Wert auf Fehlervermeidung und, da sich Fehler nieganz ausschließen lassen, auf eine frühzeitige Fehlererkennung gelegt werden muß. Hierkann ein Werkzeug helfen, indem es eine inkonsistente Verwendung von Modellelemen-ten nicht erlaubt oder auf eine inkonsistente Verwendung hinweist. Eine werkzeugun-terstützte Konsistenzprüfung zu einem vom Benutzer bestimmten Zeitpunkt hilft, Fehlerzu entdecken, die selbst von einem aufmerksamen Leser bzw. Kritiker des Modells auf-grund 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 vonUML-Modellen ist aus mehreren Gründen nicht möglich:
1. In der praktischen Anwendung der UML ist es üblich, daß ein Modellierer nicht nurwohlgeformte Modelle entwickelt, sondern zur Vereinfachung bestimmte Elementeausläßt, die eventuell zu einer Konsistenzprüfung notwendig sind (Modellunvoll-ständigkeit).
2. Während der gesamten Lebensdauer eines Modells unterliegt das Modell fortlau-fenden Veränderungen, so daß Konsistenz nicht zu jedem Zeitpunkt möglich ist.Deshalb muß ein Werkzeug Inkonsistenzen zulassen und eine Konsistenzprüfungzu einem vom Benutzer bestimmten Zeitpunkt unterstützen.
3. Eine werkzeuggestützte Konsistenzprüfung setzt voraus, daß das Werkzeug Syntaxund Semantik der UML versteht. Die Definition der UML überläßt dem Model-
125 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
lierer in vielen Situationen die Wahl, in welcher Form (natürliche Sprache, Pseu-docode, OCL) er Informationen in einem Modell hinterlegt. Dies erhöht die Aus-drucksstärke der Sprache auf Kosten der Möglichkeiten einer werkzeuggestütztenKonsistenzprü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 dieMetamodellklassen ist nicht durchgängig hinreichend formal definiert. Für Interak-tionsdiagramme der exemplarischen Ebene existieren keine entsprechenden Meta-modellklassen im Kontext einer Kollaboration, während für die, in der verwende-ten Literatur mit Ausnahme von [OMG99] nicht erwähnten, Interaktionsdiagram-me der Spezifikationsebene Metamodellklassen existieren (Unvollständigkeit desUML-Metamodells).
6. Die Umsetzung eines UML-Modells in eine Programmiersprache impliziert weitereKonsistenzbedingungen, z.B. unterstützt Java keine Mehrfachvererbung, die zwarauß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 konsistenterModelle
Das UML-Metamodell ist ein logisches Modell, anhand dessen die Semantik der UMLerläutert wird, aber kein physisches Modell, welches die Implementation eines Werkzeugsbeschreibt. Ein Werkzeug, welches die Konsistenz von UML-Modellen unterstützen undprüfen soll, muß das logische UML-Metamodell auf irgendeine Weise implementieren.
Das UML-Metamodell kann als konzeptionelle Basis für ein Metamodell eines Werk-zeugs dienen (Abb. 4.3). Dabei muß das UML-Metamodell an implementationsspezifi-sche Details angepaßt und u.a. um Metamodellklassen, die der Darstellung der Modellele-mente dienen (die MetamodellklassePresentationElement ist bereits im Metamodellvorhanden), 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 Artenunterstützen:
• Inkonsistenzvermeidung:Das Werkzeug vermeidet die Verletzung von Konsistenz-bedingungen, indem es eine Verletzung bestimmter Bedingungen nicht zuläßt (z.B.die inkonsistente Modellierung einer Generalisierung zwischen einer Klasse undeinem Interface).
4.2. KONSISTENZ 126
Sem
anti
kG
raphis
che
Dar
stel
lun
g u
nd S
yst
em-
spez
ifik
atio
n
Wer
kze
ug
Metamodellebene
UM
L-M
eta
mo
del
l(i
n U
ML
-No
tati
on d
arges
tell
t)
Bes
teht
aus:
• ab
stra
kte
n M
etak
lass
en (ModelElement, Classi-
fier
, Relationship
usw
.),
• konkre
ten M
etak
lass
en (Class, Attribute, Asso-
ciation
usw
.), d
eren
Ex
empla
re (
Model
lele
men
te)
ein
e
gra
phis
che
Dar
stel
lun
g b
esit
zen u
nd/o
der
zur
Spez
ifik
atio
n
eines
Model
ls b
enutz
t w
erden
• G
ener
alis
ieru
ngen
und A
ssozi
atio
nen
zw
isch
en d
en M
e-
takla
ssen
.
Das
Met
amodel
l def
inie
rt d
ie S
eman
tik d
er M
etak
lass
en, m
ög-
lich
e und n
otw
endig
e B
ezie
hungen
zw
isch
en M
odel
lele
men
ten
sow
ie B
edin
gun
gen
an d
ie S
pez
ifik
atio
n d
er M
odel
lele
men
te,
die
auch
von d
er B
ezie
hung z
u a
nd
eren
Mod
elle
lem
ente
n a
b-
hän
gen
können
.
UM
L N
ota
tio
n
Gu
ide
der
OM
G
• E
rläu
tert
die
gra
phis
che
Dar
-
stel
lung d
er s
eman
tisc
hen
Kon-
zepte
(fo
rwar
d m
appin
g t
o n
o-
tati
on
).
• B
esch
reib
t ver
schie
den
e O
pti
o-
nen
zur
Dar
stel
lun
g v
on M
o-
del
linfo
rmat
ionen
(A
usl
assu
ng
von I
nfo
rmat
ionen
bis
hin
zu
alte
rnat
iven
Dar
stel
lun
gen
, lä
ßt
Fre
irau
m f
ür
Wer
kze
uge)
Wer
kze
ug
-Met
am
od
ell
• bei
nhal
tet
das
konze
pti
onel
le U
ML
-
Met
amodel
l au
f ei
ne
Wei
se, so
daß
das
Wer
kze
ug d
ie S
eman
tik d
er
UM
L v
erst
eht.
• E
rwei
tert
das
UM
L-M
etam
od
ell
um
Met
akla
ssen
, die
zur
Vis
ual
isie
run
gder
Model
lele
men
te b
enutz
t w
erden
(sie
he
Kap
itel
3, Presentation-
Element
)
• die
Met
akla
ssen
rep
räse
nti
eren
ein
ph
ysi
sches
Dat
enb
anksc
hem
a
Modellebene
Met
am
od
elle
xem
pla
r(f
orm
ales
, i.
a. n
icht
sich
tbar
es U
ML
-Model
l)
• B
este
ht
aus
Ex
empla
ren d
er k
onkre
ten M
etak
lass
en (
z.B
.
der
Kla
sse
„Per
son“
und d
em A
ttri
but
„nam
e“).
• K
ann
als
Ob
jek
tdia
gra
mm
dar
ges
tell
t w
erd
en,
der
en O
b-
jekte
und L
inks
auf
den
Kla
ssen
bzw
. A
ssozi
atio
nen
des
Met
amodel
ls b
asie
ren.
UM
L-M
od
ell
(gra
phis
che
Dar
stel
lung)
Bes
teht
aus
ver
schie
den
en, in
ein
an-
der
gre
ifen
den
Sic
hte
n a
uf
ein S
yst
em.
Die
Sic
hte
n b
este
hen
aus
Dia
-
gra
mm
en, die
Ele
men
te e
ines
Sys-
tem
s und i
hre
geg
ense
itig
en B
ezie
-
hungen
sp
ezif
izie
ren u
nd d
arst
elle
n
wer
kze
ugin
tern
es
Mod
ell
(Dat
enban
k)
Ein
UM
L-M
od
ell
wir
d i
nte
rn a
uf
eine
Dat
enban
k a
bgeb
ildet
, die
au
f die
Ein
hal
-
tung v
on K
onsi
sten
zbed
ingun
gen
gep
rüft
wer
den
kan
n.
Exem
pla
r von
Sem
an
tik
u
nd
Bed
ing
un
gen
Nota
tion
bes
chre
ibt
Au
sprä
gu
ng
von
i.a. w
ird
die
Nota
-
tio
n d
urc
h d
as
Wer
kze
ug b
e-
sch
rän
kt
bes
chre
ibt
Abbildung 4.3: Ein hypothetisches Werkzeug (Erweiterung von Abb. 4.1)
127 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
• Konsistenzunterstützung:Das Werkzeug unterstützt die Modellierung konsistenterModelle, indem es in Situationen, in denen die Spezifikation eines Modellelementesauf anderen Modellelementen basiert (z.B. basiert ein Objekt auf einer Klasse), einekonsistente Auswahl der Möglichkeiten anbietet.
• Konsistenzprüfung auf Anforderung:Das Werkzeug bietet die Möglichkeit, daskonstruierte Modell, zu einem vom Benutzter bestimmten Zeitpunkt, auf die Ver-letzung von Konsistenzbedingungen zu prüfen.
Da ein Werkzeug auch das Erstellen inkonsistenter Modelle zulassen muß, solltendie Konsistenzbedingungen, deren Verletzung in jedem Fall vermieden werden sollte,sorgfältig ausgewählt werden. Zu der Kategorie der vermeidbaren Inkonsistenzen ge-hört die falsche Verwendung von Modellelementen, z.B. die Modellierung einer Gene-ralisierungsbeziehung zwischen einer Klasse und einem Interface. Betrachtet man dasWerkzeug-Metamodell als physisches Datenbankschema, so könnte die Einhaltung be-stimmter Konsistenzbedingungen durch die Realisierung als Integritätsbedingungen einerDatenbank gesichert werden (z.B. darf ein Attribut nur einmal in einer Klasse deklariertwerden).
Diese Art der Realisierung kann zu Problemen führen, wenn das Werkzeug inkonsi-stente Modelle anderer Werkzeuge importieren können soll. Ein weiteres Problem ergibtsich, wenn ein Modellelement aus dem Modell entfernt werden soll, von dem andereModellelemente abhängen. Z.B. basiert ein Operationsaufruf in einem Interaktionsdia-gramm auf einem Objekt, dessen Klasse die entsprechende Operation deklariert. Beieinem Werkzeug, welches eine Verletzung dieser Konsistenzbedingung vermeidet, würdedas Entfernen der Operation aus der Klasse entweder nicht möglich sein oder zu einemkaskadierenden Löschen von Modellelementen führen. Beide Möglichkeiten sind im Sin-ne der Benutzerfreundlichkeit nicht akzeptabel.
Ein Werkzeug, welches in bestimmten Situationen eine konsistente Auswahl von Mög-lichkeiten anbietet, sollte in dieser Situation auch die konsistente Erweiterung der Mög-lichkeiten anbieten, d.h. die Erzeugung weiterer Modellelemente, auf denen die Spezi-fikation basiert, ermöglichen. Beispielsweise, wenn in einem Interaktionsdiagramm eineOperation auf einem Objekt aufgerufen werden soll, werden die Operationen der Klassedes Objekts zur Auswahl angeboten. Hat die Klasse die gewünschte Operation jedochnoch nicht deklariert, sollte aus diesem Kontext heraus die Deklaration der gewünschtenOperation möglich sein.
Ein mit dem Werkzeug erstelltes UML-Modell beschreibt immer ein werkzeuginter-nes Modell, während nur ein konsistentes UML-Modell ein existierendes Metamodelle-xemplar beschreibt. Genügt das werkzeuginterne Modell den Konsistenzbedingungen, sobeschreibt das mit dem Werkzeug erstellte UML-Modell ein existierendes Metamodel-lexemplar 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 128
4.2.4 Konsistenzprüfung als Informationsproduzent
Wird das Modell auf die Einhaltung von Konsistenzbedingungen geprüft und eine Inkon-sistenz 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 unterschiedlichenSpezifikationsgraden erstellt. Bei einem konzeptionellen Modell ist das Modell nochunvollständig, z.B. sind Attribute und Operationen noch nicht vollständig spezifiziert,während dies bei implementationsspezifischen Modellen nicht mehr der Fall sein soll-te. Anhand der überprüften Konsistenzbedingung sollte der Benutzer feststellen können,ob es sich um eine inkonsistente Verwendung von Modellelementen, eine inkonsistenteSpezifikation von Modellelementen oder um eine Inkonsistenz auf Grund einer Model-lunvollständigkeit handelt.
4.3 Rational Rose 98
Rational Rose 98 ist ein kommerzielles UML-Werkzeug der Rational Software Cooperati-on (siehe www.rational.com), also der Firma, bei der Booch, Rumbaugh und Jacobson dieersten UML-Versionen entwickelt haben. Rational Rose 98 (im folgendenRosegenannt)basiert auf der UML-Version 1.11 und ist verfügbar für MS-Windows und kommerzielleUnix-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 Antwort-zeiten besitzt.
4.3.1 UML-Modelle in Rational Rose 98
In Rose können Anwendungsfall-, Sequenz-, Kollaborations-, Klassen-, Zustands-, Kom-ponenten- und Einsatzdiagramme modelliert werden. Rose unterstützt keine Objekt- undAktivitätsdiagramme. Für die Windowsversion existiert zwar eine Erweiterung, mit derauch Aktivitätsdiagramme modelliert werden können, aber Rose erkennt nicht die Seman-tik des Diagramms und die mit dieser Erweitung erstellten Aktivitätsdiagramme könnennicht in Nachfolgeversionen von Rose übernommen werden, falls diese (echte) Aktivi-tätsdiagramme unterstützen sollten.
Ein UML-Modell wird in Rose durch Sichten (siehe auch Abschnitt 2.4) und Paketestrukturiert (Abb. 4.4).
1Version 1.1 ist der direkte Vorgänger von Version 1.3
129 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
Abbildung 4.4:Rational Rose 98: Im linken Bereich wird der strukturelle Aufbau desModells durch Pakete dargestellt. Im rechten Bereich werden Diagrammein größenveränderbaren Fenstern dargestellt. Modellelemente können per„Drag and Drop“ aus dem rechten Bereich in ein Diagramm übernommenwerden.
4.3. RATIONAL ROSE 98 130
Die Anwendungsfallsicht(use case view) besteht aus Akteuren und Anwendungsfäl-le, die in Anwendungsfalldiagrammen dargestellt und durch Pakete weiter strukturiertwerden können. Anwendungsfälle können durch Sequenz-, Kollaborations- und Klassen-diagramme weiter spezifiziert werden, d.h. sie befinden sich in der Baumstruktur (linkerBereich in Abb. 4.4) unterhalb eines Anwendungsfalls. Akteure, die in Rose ähnlich wieKlassen behandelt werden, können durch Attribute und Operationen sowie durch maximalein Zustandsdiagramm spezifiziert werden.
Die logische Sicht(logical view) kann ebenfalls durch Pakete strukturiert werden. Dielogische Sicht besteht aus Klassendiagrammen, in denen neben Klassen, Interfaces, Ak-teuren und Beziehungen auch Pakete und Paketabhängigkeiten dargestellt werden können.Jede Klasse kann durch maximal ein Zustandsdiagramm spezifiziert werden. In Rose kön-nen in der logischen Sicht auch Anwendungfall-, Sequenz- und Kollaborationsdiagrammemodelliert werden. Dabei kann aus einem Sequenzdiagramm ein entsprechendes Kolla-borationsdiagramm erzeugt werden (sowie umgekehrt), bei denen sich Veränderungen ineinem Diagramm auch auf das entsprechende andere Diagramm übertragen.
Die Komponentensicht(component view) in Rose besteht aus Komponentendiagram-men und kann durch Pakete weiter struktriert werden. Für die Komponenten existiereneine Reihe vordefinierter Stereotypen, deren graphische Darstellung durch ein eigenesIcon unterstützt wird. Den Komponenten können Klassen und Interfaces zugeordnet wer-den. Diese Information wird z.B. bei der Codeerzeugung für Java genutzt. Die dynami-schen Diagramme der Komponentensicht (Interaktionsdiagramme, Zustandsdiagrammeund 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 wer-den.
In Rose kann jedes Diagramm mit einer Notiz, entweder als reiner Text oder in Formeines Rechtecks mit einem Eselsohr (siehe Abb. 2.12, Seite 20) versehen werden, wobeidie letztere Möglichkeit mit einem Modellelement verknüpft werden kann. Die meistenModellelemente können in Rose durch einen beliebigen Text dokumentiert werden (derin dem kleinen Fenster links unten in Abb. 4.4 angezeigt wird, wenn das Modellelementselektiert ist). Für ausführlichere Dokumentationen können in der Baumstruktur vorhan-dene Modellelemente2 mit Dateien und Internetadressen verknüpft werden.
Klassifizierer (Klassen, Interfaces, usw.), teilweise auch andere Modellelemente, wer-den nur einmal im Modell angelegt, können aber in mehreren Diagrammen verwendetwerden. Daher kann die Änderung der Spezifikation eines Modellelements auch zur Än-derung der Darstellung in anderen Diagrammen führen. Bei einigen Modellelementenkann die im Diagramm dargestellte Information diagrammabhängig selektiert werden.Dabei kann z.B. bei Klassen sowohl der Detailliertheitsgrad von Operationen (nur derOperationsname oder die ganze Operationssignatur) als auch der Umfang der darzustel-lenden Informationen (Attribute und Operationen können einzelnd ausgeblendet werden)
2Beziehungen zwischen Modellelementen werden nicht angezeigt.
131 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
eingestellt werden.Weitere Editionsmerkmale:
• Akteure und Interfaces können wahlweise durch ihr Icon oder durch ihre Standard-darstellung visualisiert werden.
• Die Größenanpassung von zweidimensionalen Modellelementen (Klassen, Kompo-nenten, usw.) kann wahlweise von Rose automatisch oder manuell vom Benutzervorgenommen 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 anzuwen-den, da die „Optimierung“ nicht rückgängig gemacht werden kann.
• Werden Modellelemente aus der Modellübersicht (linker Bereich in Abb. 4.4) in einDiagramm ü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. Wirddas Modellelement nur aus dem Diagramm entfernt, dann existiert es noch im Mo-dell und wird, mit Ausnahme von Beziehungen, in der Modellübersicht angezeigt.Die zweite Möglichkeit besteht aus dem Entfernen des Modellelements aus demModell. Das Löschen von Beziehungen (Assoziationen, Generalisierungen, usw.)aus einem Diagramm kann zu Problemen führen, wenn die Beziehung in keinemDiagramm dargestellt wird. Da die Beziehung auch nicht in der Übersicht ange-zeigt wird, ist sie für den Modellierer visuell nicht mehr zu erfassen, obwohl sieweiterhin im Modell vorhanden ist.
• Ausgehend von einem Modellelement kann zu den Diagrammen gewechselt wer-den, in denen das Modellelement vorhanden ist oder zur Spezifikation anderer Mo-dellelemente gewechselt werden, die mit diesem Element verbunden sind. Auf die-se Weise kann die Verwendung eines Modellelements im Modell verfolgt und einenicht mehr sichtbare Beziehung entdeckt werden.
• Teilweise können die Diagramme auch in Booch- oder OMT-Notation (re-) trans-formiert werden.
4.3.2 Weitere Merkmale von Rational Rose 98
Rose unterstützt mehrere Programmiersprachen, d.h. die UML-Modelle können sprach-spezifisch erweitert werden und aus den UML-Modellen kann Code erzeugt werden. Teil-weise ist sogar ein Round-Trip-Engineering möglich. Bei der Modellierung können meh-
4.3. RATIONAL ROSE 98 132
rere Sprachen gleichzeitig unterstützt werden. Rose unterstützt u.a. C++, Java, Small-talk, Ada, Visual Basic, Oracle 8 und kann auch IDL (Interface Definition Language) fürCORBA-Anwendungen (Common Object Request Broker Architecture) und DDL (DataDescription Language) für Datenbankanwendungen erzeugen.
In der Unix-Version fehlt u.a. die Unterstützung für Visual Basic, Smalltalk undOracle 8, während die Windows-Version weitergehende Visual C++ (Microsoft) Unter-stützung bietet und andere Produkte von Microsoft integriert (z.B. MS Repository, MSVisual Source Safe).
Rose unterstützt mehrere Benutzer nebenläufig, indem jedem Benutzer ein privaterArbeitsbereich zugestanden wird und sich Modellveränderungen in diesem Bereich nichtglobal auswirken. Erst der Umweg über ein Konfigurations-Management und Kontroll-System (CMVS, z.B. Rational ClearCase oder Microsoft SourceSafe) machen die Ände-rungen für andere sichtbar. Ein Werkzeug zur graphischen Darstellung von Unterschiedenzwischen zwei Modellen ist im Lieferumfang enthalten (Visual Differencing Tool).
Rose besitzt ein Interface (Rose Extensibility Interface , REI), welches den Zugriffauf die Anwendung Rose selbst, die Diagramme und die Modellelemente eines Rose-UML-Modells ermöglicht (Abb. 4.5). Dieses Interface kann von Rose Script3 zur Auto-matisierung manueller Rose-Funktionen genutzt werden. Sogenannte „Rose Automationobjects“ können das Interface ebenfalls nutzen und eröffnen die Möglichkeit per OLE(Object Linking And Embedding) Funktionen anderer Anwendungen aus Rose herausauszuführen oder umgekehrt Rose-Funktionen aus anderen Anwendungen heraus auszu-führen. Dabei dient Rose entweder als Controller oder als Server.
Rose
Application
Diagrams
Model
Elements
Rose
Extensibility
Interface
Rose
Script
Rose
Automation
Abbildung 4.5: Rose Extensibility Interface (REI)
3Die Rose Scripting Languageist eine erweiterte Version der Summit BasicScriptlanguage(www.summsoft.com) und hat Ähnlichkeiten zu MS Visual Basic.
133 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
4.3.3 Konsistente UML-Modelle und Rational Rose 98
Rose unterstützt die Konstruktion von konsistenten UML-Modellen auf alle in Abschnitt4.2.3, Seite 125 genannten Arten: Inkonsistenzvermeidung, Konsistenzunterstützung undKonsistenzprüfung auf Anforderung.
Einige Inkonsistenzen, die auf Grund der Modellierung falscher Beziehungen entste-hen würden, werden von Rose zurückgewiesen. Inkonsistenzen, die sich durch die Spezi-fikation der Modellelemente ergeben, werden nicht verhindert. So ist es z.B. möglich, ineiner Klasse einen Attributnamen mehrfach zu verwenden.
An Stellen, an denen die Spezifikation eines Modellelements auf einem anderen Mo-dellelement basiert, bietet Rose eine (meist!) konsistente Auswahl an, ermöglicht teilwei-se eine konsistente Erweiterung der Möglichkeiten, indem das gewünschte Basiselementaus diesem Kontext heraus erstellt werden kann, und ermöglicht teilweise eine Spezi-fikation von Modellelementen durch beliebigen Text, ohne einen Bezug zu einem Ba-siselement herzustellen. Zu einer Komponente kann angegeben werden, welche Klassenund Interfaces sie realisiert. Hier stellt Rose eine Liste von Klassen bzw. Interfaces zurVerfügung, die aber nicht aus diesem Kontext (Spezifikation einer Komponente) herauserweitert werden kann. Soll in einem Interaktionsdiagramm eine Operation auf einemObjekt aufgerufen werden, bietet Rose als Auswahl die Operationen der Klasse des Ob-jekts an (inklusive geerbter öffentlicher Operationen. Alternativ kann aus diesem Kontextheraus die Klasse um die gewünschte Operation erweitert werden oder ein beliebiger Textals Repräsentant für eine nicht existierende Operation angegeben werden.
Rose besitzt nur wenige Konsistenzprüfungen, die auf Anforderung durchgeführt wer-den können. Der Menüpunkt „Check Model“ aus dem Menü „Tools“ untersucht das Mo-dell auf nicht auflösbare Referenzen. Es ist möglich, daß ein Modellelement (z.B. einObjekt) ein anderes Element (z.B. eine Klasse) referenziert, welches jedoch nicht exi-stiert. In diesem Fall kann die Referenz nicht aufgelöst werden. Dieser Befehl überprüftmehrere Konsistenzbedingungen, deren Überprüfung auch einzelnd (diagrammabhängig)ausgeführt werden kann.
Teilweise kann vor der Codeerzeugung ein sprachabhängiger Syntaxcheck durchge-fü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 derUML, 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 rea-lisiert werden (siehe Kapitel 5). Da die Konsistenzprüfungen auf der Basis des werk-zeuginternen Modells durchgeführt werden, wird im nächsten Abschnitt das Werkzeug-metamodell von Rose kurz vorgestellt. Anhand dieses Modells ist erkennbar, welche In-formationen ein Modellierer in einem Rose-UML-Modell spezifzieren kann und welcheInformationen Rose semantisch erkennt.
4.4. DAS WERKZEUGMETAMODELL VON RATIONAL ROSE 98 134
4.4 Das Werkzeugmetamodell von Rational Rose 98
Aus der Dokumentation von Rose Script kann auf eine Klassenhierarchie geschlossenwerden, deren Klassen von Rose Script genutzt werden können, um Informationen derUML-Modelle in Rose zu überprüfen und die Modelle zu verändern. In diesem Abschnittwerden die wichtigsten zu diesem Zweck notwendigen Klassen mit einer Auswahl ihrerAttribute und Operationen vorgestellt. Aus den Namen der Attribute und Operationenkann teilweise auf Assoziationen zwischen den Klassen geschlossen werden, die nichtdokumentiert sind und hier auch nicht explizit dargestellt werden. Modellelemente, diein Anwendungsfall-, Komponenten- und Verteilungsdiagramme benutzt werden, werdennicht erläutert, da sie im Rahmen dieser Arbeit nicht behandelt werden.
Da diese Klassen ebenfalls von Rose genutzt werden, geben die folgenden Abschnitteauch einen Einblick auf die Spezifikationsmöglichkeiten von UML-Modellen in Rose.
4.4.1 Die Spitze der Klassenhierarchie
Die KlasseRoseObject 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 Ob-jekt zu einer bestimmten Klasse gehört oder auch als Objekt einer bestimmten anderenKlasse angesehen werden kann. Die KlasseElement ist mit der UML-MetamodellklasseModelElement vergleichbar. Das Attributname kennzeichnet den Namen eines Elements,Model undApplication bezeichnen das Modell bzw. die Anwendung (Rose), zu der dasElement gehört.
Die KlasseRoseItem (und deren Unterklassen) stellen die Datensicht auf die Spezi-fikation eines Modellelements dar, während die KlasseRoseItemView (und deren Unter-klassen) für die graphische Darstellung eines Modellelements und dessen Spezifikationzuständig sind. EinRoseItem kann ein Stereotyp besitzen, intern in Rose dokumen-tiert und mit einer externen Datei oder Internetadresse verknüpft werden. Die OperationOpenSpecification öffnet ein Dialogfenster in Rose zur Spezifikation des Modellele-ments.
Die Datensicht auf ein Modellelement wird in den Diagrammen jeweils durch eineSicht (RoseItemView) dargestellt. Dadurch ist es möglich, die darzustellende Infor-mation in einem Diagramm dem Zweck des Diagramms anzupassen. Jedes Diagramm(Diagram) kann in Rose durch beliebigen Text dokumentiert und mit graphisch darge-stellten Notizen versehen werden.
4.4.2 Diagrammarten
In Rose können die graphisch dargestellten Modellelemente z.B. mit der Maus selek-tiert werden. Diese Information kann durch ein Roseskript abgefragt werden (OperationGetSelectedItems, siehe Abb. 4.7) und wird später bei der Realisierung von Kon-sistenzprüfungen benutzt, um die Prüfungen auf einen Teilbereich des Modells einzu-
135 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
RoseObject
CanTypeCast()IdentifyClass()IsClass()TypeCast()
RoseItem
DocumentationStereotypeExternalDocumentsLocalizedStereotype
AddExternalDocument()DeleteExternalDocument()GetRoseItem()OpenSpecification()
Element
NameApplicationModel
RoseItemView
ItemParentDiagramParentViewSubViewsXPositionYPosition
IsSelected()HasItem()HasParentView()
Diagram
DocumentationItemsItemViews
Activate()AddNoteView()IsActive()Exists()RemoveNoteView()
Abbildung 4.6: Die Spitze der Klassenhierarchie von Rose
4.4. DAS WERKZEUGMETAMODELL VON RATIONAL ROSE 98 136
schränken. Die OperationActivate der KlasseDiagram stellt das entsprechende Dia-gramm in einem Fenster von Rose dar. Diese Operation wird später benutzt, um Model-lelemente sichtbar darzustellen, die eventuell für eine Verletzung einer Konsistenzbedin-gung verantwortlich sind.
Diagram
Activate()GetSelectedItems()
ClassDiagram
ParentCategory
AddAssociation()AddCategory()AddClass()AddUseCase()GetAssociations()GetCategories()GetClasses()GetClassView()GetSelectedCategories()GetSelectedClasses()GetUseCases()IsUseCaseDiagram()RemoveAssociation()RemoveCategory()RemoveClass()RemoveUseCase()
StateDiagram
Parent
AddStateView()GetSelectedStates()GetSelectedStateViews()GetSelectedTransitions()GetStateView()GetStateViews()RemoveStateView()
ScenarioDiagram
InstanceViews
AddInstance()AddInstanceView()CreateMessage()DeleteInstance()GetDiagramType()GetMessages()GetSelectedLinks()GetSelectedMessages()GetSelectedObjects()RemoveInstanceView()
DeploymentDiagram
AddDevice()AddProcessor()GetDevices()GetProcessors()RemoveDevice()RemoveProcessor()
ModuleDiagram
ParentSubsystem
AddModule()AddSubsystem()GetModules()GetSelectedModules()GetSelectedSubsystems()GetSubsystems()
Abbildung 4.7: Die Diagrammklassen von Rose
Die fünf Unterklassen vonDiagram dienen der internen Darstellung der sieben mög-lichen Diagrammarten in Rose. Die KlasseClassDiagram ist für Klassen- und An-wendungsfalldiagramme verantwortlich. Sequenz- und Kollaborationsdiagramme, die als(weitgehend) äquivalent angesehen werden können, werden intern durch die KlasseSce-narioDiagram dargestellt. Zustands-, Komponenten- und Verteilungsdiagramme werdendurch die KlassenStateDiagram, ModuleDiagram undDeploymentDiagram repräsen-tiert.
Die meisten Diagrammklassen besitzen Operationen, mit denen auf selektierte Mo-dellelemente differenzierter zugegriffen werden kann, als dies mit der OperationGet-SelectedItems möglich ist.
137 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
Das Attribut Parent der KlasseStateDiagram bezeichnet die Klasse, zu der dasZustandsdiagramm gehört. Wie bereits oben erwähnt, wird in Rose ein UML-Modellmittels Sichten (use case view, logical view, usw.) und Paketen strukturiert. Das AttributParentCategory gibt die Sicht bzw. das Paket an, zu der das Klassen- bzw. Anwen-dungsfalldiagramm gehört. In Klassen- und Anwendungsfalldiagrammen können Paket-abhängigkeiten modelliert werden. Ein Diagramm, welches nur Pakete enthält wird auchPaketdiagrammgenannt.
4.4.3 Modellelemente in Klassendiagrammen
Die Darstellung von Klassen, Interfaces und anderen in Klassendiagrammen von Roseverwendbaren Modellelementen werden durch Unterklassen vonRoseItemView (Abb.4.6) repräsentiert. Die Klassen, die für die Spezifikation dieser Modellelemente verant-wortlich sind, sind Unterklassen vonRoseItem und werden in diesem Abschnitt erläutert(siehe Abb. 4.8).
Die KlasseClass repräsentiert nicht nur Klassen, sondern auch Modellelemente, dieals Klassen mit einem bestimmten Stereotyp, z.B. «Interface», dargestellt werden können.Rose erkennt die beiden Klassifizierer Interface und Akteur anhand ihrer Stereotypen undkann sie auch mit ihrem Icon darstellen. Während die Spezifikation von Akteuren ge-genü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 belie-bigen stereotypisierten Klasse und einem Interface. Mit Hilfe der Funktionen der KlasseClass können mit Rose Script u.a. Beziehungen zu anderen Klassen hinzugefügt, ent-fernt und ermittelt werden. Die Attribute und Operationen der Klasse werden durch dieAttribute Attributes undOperations gespeichert. Diese Attribute repräsentieren so-genannte Collections (Sammlungen), über die auf die Attribute und Operationen einerKlasse zugegriffen werden kann. Damit sind alle Informationen, die der Benutzer imModell spezifiziert, prinzipiell auch in Rose Script verfügbar und veränderbar. Klassenkönnen als abstrakt markiert werden, ihre Sichtbarkeit (public, protected, private), Kar-dinalität und Nebenläufigkeit kann angegeben werden.StateMaschine bezeichnet daseinzige, falls vorhandene, Zustandsdiagramm der Klasse, welches auch von Rose Scripterzeugt werden kann (OperationCreateStateMaschine).
Umgekehrt „kennen“ auch Attribute und Operationen ihre Klasse (AttributParent-Class). Die Parameter einer Operation (AttributParameters vom Typ collection) wer-den durch die KlasseParameters repräsentiert.
Assoziations-, Realisierungs-, Abhängigkeits- und Generalisierungsbeziehungen wer-den durch die KlassenAssociation, RealizeRelation, ClassDependency und In-heritRelation repräsentiert. Die KlasseRole ist vergleichbar mit der KlasseAssoci-ationEnd des UML-Metamodells. Sie repräsentiert die Informationen, die an den Endeneiner Assoziation spezifiziert wird. Die Rollen bzw. Assoziationsenden einer Assoziati-on können über die AttributeRole1 bzw. Role2 erreicht werden. Ob es sich bei einemAssoziationsende um die erste oder zweite Rolle der Assoziation handelt, ist irrelevant.
4.4. DAS WERKZEUGMETAMODELL VON RATIONAL ROSE 98 138
Ros
eIte
m
Ste
reot
ype
Ope
nSpe
cific
atio
n()
Cla
ss
Abs
trac
tA
ttrib
utes
Ope
ratio
nsE
xpor
tCon
trol
Car
dina
lity
Con
curr
ency
Sta
teM
asch
ine
Add
Ass
ocia
tion(
)A
ddA
ttrib
ute(
)A
ddC
lass
Dep
ende
ncy(
)A
ddIn
herit
Rel
()A
ddO
pera
tion(
)A
ddR
ealiz
eRel
()C
reat
eSta
teM
asch
ine(
)D
elet
eAss
ocia
tion(
)D
elet
eAttr
ibut
e()
Del
eteC
lass
Dep
ende
ncy(
)D
elet
eInh
eritR
el()
Del
eteN
este
dCla
ss()
Del
eteO
pera
tion(
)D
elet
eRea
lize(
)D
elet
eSta
teM
asch
ine(
)G
etA
ssoc
iate
Rol
es()
Get
Ass
ocia
tions
()G
etC
lass
Dep
ende
ncie
s()
Get
Inhe
ritR
elat
ions
()G
etLi
nkA
ssoc
iatio
n()
Get
Rea
lizeR
elat
ions
()G
etR
oles
()G
etS
ubcl
asse
s()
Get
Sup
ercl
asse
s()
IsA
Link
Cla
ss()
Ass
ocia
tion
Der
ived
Link
Cla
ssR
ole1
Rol
e2R
oles
Get
Cor
resp
ondi
ngR
ole(
)G
etO
ther
Rol
e()
Set
Link
Cla
ssN
ame(
)
Cla
ssR
elat
ion
Get
Con
text
Cla
ss()
Get
Sup
plie
rCla
ss()
Cla
ssD
epen
denc
y
Clie
ntC
ardi
nalit
yS
uppl
ierC
ardi
nalit
yE
xpor
tCon
trol
Attr
ibut
e
Con
tain
men
tPro
perty
Der
ived
Exp
ortC
ontro
lPro
perty
InitV
alue
Par
entC
lass
Sta
ticT
ype
Rea
lizeR
elat
ion
Get
Con
text
Cla
ss()
Get
Sup
plie
rCla
ss()
Rol
e
Cla
ssC
onst
rain
tsA
ssoc
iatio
nE
xpor
tCon
trol
Frie
ndC
onta
inm
ent
Car
dina
lity
Agg
rega
teS
tatic
Nav
igab
leK
eys
Add
Key
()D
elet
eKey
()G
etC
lass
Nam
e()
Rel
atio
n
Sup
plie
rNam
e
Has
Clie
nt()
Has
Sup
plie
r()
Get
Clie
nt()
Get
Sup
plie
r()
Ope
ratio
n
Con
curr
ency
Exc
eptio
nsE
xpor
tCon
trolP
rope
rtyP
aram
eter
sP
aren
tCla
ssP
ostc
ondi
tions
Pro
cond
ition
sR
etur
nTyp
eS
eman
tics
Add
Par
amet
er()
Del
eteP
aram
eter
()R
emov
eAllP
aram
eter
s()
Par
amet
er
Con
stIn
itVal
ueT
ype
Inhe
ritR
elat
ion
Exp
ortC
ontr
olF
riend
ship
Req
uire
dV
irtua
l
Abbildung 4.8:Die Rose-Metaklassen für die in einem Klassendiagramm vorkommen-den Modellelemente.
139 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
4.4.4 Modellelemente in Interaktionsdiagrammen
In Rose können Kollaborationsdiagramme nur auf der exemplarischen Ebene modelliertwerden. Sequenz- und Kollaborationsdiagramme der exemplarischen Ebene bestehen ausObjekten (Exemplaren), Links und Botschaften (bzw. Stimuli). Diese Modellelementewerden in Rose für beide Diagrammarten durch die gleichen Klassen repräsentiert (Abb.4.9).
Link
LinkRole1LinkRole2LinkRole1VisibilityLinkRole2Visibility
AddMessageTo()AssignAssociation()DeleteMessage()GetMessages()UnAssignAssociation()
Message
FrequencySynchronization
GetSenderObject()GetReceiverObject()IsMessageToSelf()IsOperation()GetOperation()GetLink()
ObjectInstance
ClassNameLinksMultipleInstancesPersistence
AddLink()DeleteLink()GetClass()IsClass()
RoseItem
Stereotype
OpenSpecification()
Abbildung 4.9:Die Rose-Metaklassen für die in den Sequenz- und Kollaborationsdia-grammen vorkommenden Modellelemente.
Die Klasse eines Objekts (ObjectInstance) wird als String gespeichert (AttributClassName). Falls der Benutzer in Rose eine Klasse für das Objekt ausgewählt hat, kanndiese Klasse mit der OperationGetClass ermittelt werden. Das AttributLinks enthälteine Sammlung (Collection) der mit dem Objekt verbundenen Links.
Die durch einen Link verbundenen Objekte in einem Kollaborationsdiagramm werdendurch die AttributeLinkRole1 bzw. LinkRole2 repräsentiert. Im Gegenstatz zu denRollen-Attributen einer Assoziation verweisen diese Attribute nicht auf die Link-Endeneines Links. Zu einem Link-Ende kann jedoch die Sichtbarkeit spezifiziert und durchRose Script abgefragt werden. Ein Link kann einer bestehenden Assoziation zugeordnetsein 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örigenLink. Die Reihenfolge der Botschaften kann von Rose Scriptnicht ermittelt werden. Die
4.4. DAS WERKZEUGMETAMODELL VON RATIONAL ROSE 98 140
Reihenfolge kann in Rosenicht explizit spezifiziert werden. In einem Interaktionsdia-gramm ergibt sich die Reihenfolge der Botschaften implizit durch die Anordnung entlangder vertikalen Achse des Diagramms. In einem Kollaborationsdiagramm wird die Rei-henfolge 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 entsprechendenKlassen (Abb. 4.10).
Die KlasseStateMaschine verweist auf das Zustandsdiagramm (StateDiagram),die zugehörige Klasse (ParentClass) sowie auf die, im Zustandsautomaten vorhande-nen, Zustände und Transistionen. Zustandsautomaten (Statecharts) können weitere ver-schachtelte Zustände enthalten. Die Operationen der KlasseStateMaschine ermögli-chen wahlweise den Zugriff auf die Zustände und Transitionen der obersten Ebene oderaller Zustände und Transistionen des Zustandsautomaten.
Diese Auswahlmöglichkeit besteht auch bei den Zuständen (State). Z.B. kennzeich-net das AttributSubstates die unmittelbaren Unterzustände eines Zustands, währenddie OperationGetAllSubstates alle Unterzustände des Zustands liefert. Ein Zustand„kennt“ die mit ihm verbundenen Transitionen und kann einen Erinnerungs-Zustand ent-halten. Ein Zustand kann Entry- und Exit-Aktionen enthalten, sowie anhaltende Aktionen,die solange ausgeführt werden, wie der Zustand aktiv ist (GetDoActions). Die Zuständein Rose können auch interne Transitionen, die auf Grund benutzerdefinierter Ereignisse„feuern“ können, enthalten. Verzögerte Ereignisse können spezifiziert werden, indem dieAktion auf das zu verzögernde (benutzerdefinierte) Ereignis als „defer“ spezifiziert wird.
In Rose besteht eine Aktion (Action) aus drei Teilen:
1. Der Name (AttributName der KlasseElement) ist ein String, der die Aktion be-schreibt. Dies sollte der Name einer Operation, eines Signals oder einer Ausnahmesein. Rose bietet dem Modellierer jedoch keine Auswahl von Möglichkeiten an,daher fehlt auch eine Beziehung zu einer entsprechenden Operation o.ä.
2. Das AttributArgument ist ein String, der die Argumente der Aktion speichert.
3. Das AttributTarget ist ebenfalls ein String, der nur zur Verfügung steht wenn essich um eine Sende-Aktion handelt. Es sollte eine Klasse bzw. ein Objekt bezeich-nen, die dieses Signal empfängt. Auch hier bietet Rose keine Auswahlmöglichkeitbzw. eine Verbindung zum entsprechenden Element an.
Sende-Aktionen werden von Rose anders als Aufruf-Aktionen dargestellt. Dies istin UML Version 1.3 nicht mehr der Fall.
141 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
Transition
GetSendAction()GetSourceState()GetTargetState()GetTriggerAction()GetTriggerEvent()RedirectTo()
Statemaschine
DiagramParentClassStates
AddState()DeleteState()GetAllStates()GetAllTransitions()GetTransitions()RelocateState() State
HistoryParentStateParentStateMaschineStateKindSubStatesTransitions
AddDoAction()AddEntryAction()AddExitAction()AddState()AddTransition()AddUserDefinedEvent()DeleteAction()DeleteState()DeleteTransition()DeleteUserDefinedEvent()GetAllSubstates()GetDoActions()GetEntryActions()GetExitActions()GetUserDefinedEvents()RelocateState()
Event
ArgumentsGuardCondition
GetAction()
Action
ArgumentsTarget
Element
Name
RoseItem
Stereotype
OpenSpecification()
Relation
SupplierName
HasClient()HasSupplier()GetClient()GetSupplier()
Abbildung 4.10:Die Rose-Metaklassen für die in einem Zustandsdiagramm vorkommen-den Modellelemente.
4.5. KLASSENDIAGRAMM 142
Transitionen (KlasseTransition) „kennen“ ihren Ausgangs- und Folgezustand, so-wie das dazugehörige Ereignis und die Aktion auf das Ereignis.
Das AttributGuardCondition der KlasseEvent kennzeichnet eine Bedingung, diedas „Feuern“ ihrer Transition überwacht. Von einem benutzerdefiniertem Ereignis, wel-ches zu einem Zustand gehört, kann auf die zugehörige Aktion geschlossen werden (Get-Action).
4.5 Klassendiagramm
Klassendiagramme gehören zu den wichtigsten und am meisten verwendeten Diagram-men einer objektorientierten Systementwicklung. Sie spezifizieren die strukturelle undlogische Basis für die Realisierung des Systems, auf der die Spezifikation und die Reali-sierung des Systemverhaltens aufbaut.
In diesem Abschnitt wird erläutert, wie die graphische Darstellung der Modellele-mente eines Klassendiagramms ein Metamodellexemplar der UML bzw. ein Rose-Meta-modellexemplar beschreibt. Der Vergleich der Metamodellexemplare zeigt, in welchemAusmaß Rose die Semantik der UML erkennt und welche Konsistenzbedingungen, dieim 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 dreiBestandteile zerlegt wird. Der obere Teil ist für den Klassennamen, Eigenschaftswerte,Zusicherungen sowie für einen Stereotyp vorgesehen. Im mittleren Teil werden die Attri-bute und im unteren Teil die Operationen dargestellt. Abb. 4.11 zeigt eine abstrakte Klas-se ohne Attribut- und Operationsanteile mit einem Stereotyp. Abstrakte Klassen könnendurch die Zusicherung {abstract} oder durch einen kursiv geschriebenen Klassennamendargestellt werden.
Klassenname<<Stereotyp>>
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 zeigtAbb. 4.13.
143 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZChart Name : KlasseNotationMetaUMLChart Filename : KlasseNotationMetaUML.VobChart Type : UML Object Diagram : Class
name = KlassennameisRoot = falseisLeaf = falseisAbstract = trueisActive = false
: Stereotype
name = StereotypiconbaseClass = Class
extendedElement stereotype
Abbildung 4.12: Darstellung einer stereotypisierten Klasse als Metamodellexemplar
Chart Name : KlasseNotationMetaRoseChart Filename : KlasseNotationMetaRose.VobChart Type : UML Object Diagram : Class
Name = KlassennameStereotype = StereotypAbstract = trueCardinality = nConcurrency = Sequential
Abbildung 4.13:Eine stereotypisierte Klasse aus Sicht der Skriptsprache von RationalRose.
Die folgenden Informationen zu einer Klasse in den Abbildungen 4.12 und 4.13 ent-sprechen einander:
UML Rose Bemerkung
name NameisAbstract AbstractisActive Concurrency Concurrency kann in Rose die Werte Sequen-
tial, Guarded, Active und Synchronous an-nehmen.
stereotype Stereotype In Rose ist „Stereotype“ ein Attribut der Klas-seRoseItem. Es ist möglich, einen Stereotypaus einer Liste auszuwählen oder einen neu-en Stereotyp zu erstellen. Es ist nicht mög-lich, den Namen eines Stereotyps zu ändern(nicht zu verwechseln mit der Möglichkeit,einen anderen Stereotyp für ein Modellele-ment (RoseItem) auszuwählen).
Die im Metamodell angegebenen EigenschaftenisRoot und isLeaf einer Klassekönnen in Rose nicht in jedem Fall angegeben werden. Die Java-Erweiterung von Roseermöglicht das Setzen eines booleschen Wertes für die „Final“-Eigenschaft einer Klasse(vergleichbar mitisLeaf), die bei der Codeerzeugung berücksichtigt wird.
Konsistenzbedingungen für Klassen existieren im Zusammenhang mit anderen Mo-dellelementen und werden in den entsprechenden Abschnitten behandelt.
4.5. KLASSENDIAGRAMM 144
4.5.2 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 ’-’ (pri-vat) angegeben.
• Der Eigenschafts-String dient der Notierung von Zusicherungen und Eigenschafts-werten.
• 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 derAttribute dargestellt werden (Abb. 4.14). Es liegt in der Verantwortung des Werkzeugs,bestimmte Eigenschaften darzustellen bzw. für Default-Werte für bestimmte Eigenschaf-ten, z.B. die Sichtbarkeit, zu sorgen. Rose ermöglicht es, einzelne Attribute und Operatio-nen einer Klasse in einem Klassendiagramm auszublenden und den Detailliertheitsgradder 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 istin Abb. 4.16 angegeben.
Die folgenden Informationen eines Attribut aus den Abbildungen 4.15 und 4.16 ent-sprechen einander:
145 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
Chart Name : AttributNotationUML-MetamodellChart Filename : AttributNotationUML-Metamodell.VobChart Type : UML Object Diagram : Attribute
name = AttributNameownerScope = instancevisibilityKind = publicinitialValue = Initialwertmultiplicity = 1changeability = changeabletargetScope = instance
: Class
name = KlassennameisRoot = falseisLeaf = falseisAbstract = falseisActive = false
: Class
name = TypisRoot = falseisLeaf = falseisAbstract = falseisActive = false
featureowner type
Abbildung 4.15:Darstellung eines Attributs als Metamodellexemplar unter Auslassungder Zugehörigkeit zu einem Namensraum. Es wird angenommen, daßein Werkzeug sinnvolle Defaultwerte für nicht-spezifizierte Eigenschaf-ten setzt.Anstelle vonClass als Typ kann auch einDataType benutzt werden.
: Class
Name = KlassennameAbstract = falseAttributes
: Attribute
Name = AttributNameStatic = falseExportControlProperty = PublicAccessInitValue = InitialwertDerived = falseType = TypParentClass
Abbildung 4.16:Klasse und Attribut aus Sicht der Skriptsprache von Rational Rose. DieParameter „Attributes“ und „ParentClass“ lassen auf eine Assoziationzwischen den Metaklassen „Class“ und „Attribute“ schließen. Das At-tribut „Attributes“ der Metaklasse „Class“ enthält eine Sammlung (col-lection) von Referenzen auf die Attribute der Klasse.
4.5. KLASSENDIAGRAMM 146
UML Rose Bemerkung
name NameownerScope Static instance entspricht Static = falsevisibilityKind ExportControl-
Propertypublic entspricht PublicAccess
initialValue InitValuetype Type In Rose ist Typ ein Attribut der Klasse
Attribute.
Die folgenden Informationen können nicht aus Abb. 4.16 extrahiert bzw. nicht ineinem 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 unter-stützt. Eine Klasse kann als „persistent“ oder „transient“ spezifiziert werden.
Es ergeben sich folgende Konsistenzbedingungen und Möglichkeiten, diese Bedin-gungen 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 rea-lisiert werden.
• Attribut-2: Die Deklarations eines Attributs sollte eines Typen beinhalten.
• Attribut-3: Der Typ des Attributs sollte im Modell (genauer: im Namensraum desAttributs) existieren (Vollständigkeitsbedingung).
Als Typen eines Attributs kommen die KlassifiziererClass undDataType in Fra-ge. Diese gehören in Rose zur KlasseClass. Mit der Skript-Sprache von Roseläßt sich überprüfen, ob eine Klasse mit dem Namen des Typs existiert und gege-benenfalls die fehlende Klasse im Modell erzeugen (d.h. nicht, daß es auch einKlassendiagramm gibt, welches die Klasse enthält).
• Attribut-4: Ein vorhandender Defaultwert sollte aus dem Wertebereich des Typssein.
4Indirekt können weitere Informationen immer als Notiz im Diagramm oder als Dokumentation zueinem Modellelement vermerkt werden.
147 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
Eine Überprüfung dieser Bedingung setzt voraus, daß das Werkzeug den Wertebe-reich 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 Klassemit der folgenden Syntax notiert:
Sichtbarkeit Operationsname (Parameterliste): Rückgabetyp { Eigenschafts-String }
• Die Sichtbarkeit entspricht der Sichtbarkeit von Attributen. Zusätzliche Arten vonSichtbarkeiten können definiert werden. Sie sollten durch Werkzeugkonventionenoder 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 Parame-tern, die durch die folgende Syntax spezifiziert wird:
Art Name : Typ-Ausdruck = Default-Wert
mit
– Art ist in, out, inout. Default istin.
– 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. Da-zu gehören die EigenschaftenisQuery undabstract sowie die Spezifikationvon 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 Operationgeheftet werden.
• Operationen können mit einem Stereotypen markiert werden, der vor der Operati-onssignatur einschließlich der Sichtbarkeit notiert wird.
Bei der Darstellung einer Operation müssen nicht alle spezifizierten Eigenschafteneiner Operation dargestellt werden ([OMG99]). Abb. 4.17 zeigt ein Beispiel, welches imfolgenden benutzt wird.
4.5. KLASSENDIAGRAMM 148
Klassenname
Operationsname(Parametername : Parametertyp = Default-Wert) : Rückgabetyp
Abbildung 4.17: Beispielhafte Notation einer Operation
Aus Sicht der Operationsind die Parameter geordnet.
Der Typ eines Parameterskönnte auch ein "DataTyp" sein
: Operation
name = OperationsnamevisibilityKind = publicconcurrency = sequentialownerScope = instanceisQuery = falseisRoot = falseisLeaf = falseisAbstract = false
: Parameter
name = Parameternamekind = inoutdefaultValue = Default-Wert
: Parameter
name = ?kind = returndefaultValue = ?
: Class
name = Parametertyp
: Class
name = Rückgabetyp
: Class
name = Klassenname
type
type
owner
feature
Abbildung 4.18:Metamodellexemplar der Operation aus Abb. 4.17. Der Wert des At-tributs „kind“ dient der Unterscheidung zwischen einem Parameter undeinem Rückgabetyp. Da Rückgabetypen wie Parameter behandelt wer-den, kann eine Operation mehrere Rückgabetypen besitzen.
Chart Name : OperationNotationMetaRoseChart Filename : OperationNotationMetaRose.VobChart Type : UML Object DiagramKonzeptionell vorhanden
Konzeptionell vorhanden
: Class
Name = KlassennameOperations
: Operation
name = OperationsnameExportControlProperty = PublicAccessConcurrency = sequentialStereotypeReturnType = RückgabetypParametersParentClass
: Parameter
name = ParameternameType = ParametertypInitValue = Default-WertConst = false
Abbildung 4.19:Interne Darstellung der Operation aus Abb. 4.17. Eine Klasse kennt ihreOperationen, eine Operation kennt ihre Klasse und ihre Parameter, aberein Parameter kennt seine Operation nicht.
149 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
Die Abbildung der Operation aus Abb. 4.17 auf ein Metamodellexemplar der UMList in Abb. 4.18 dargestellt. Stereotypen und Zusicherungen einer Operation würdengegebenfalls mit einem Link an die Operation geheftet werden.
Die Abbildung der Operation aus Abb. 4.17 auf ein Metamodellexemplar von Rose inAbb. 4.19 dargestellt.
Die folgenden Informationen aus den Abbildungen 4.18 und 4.19 entsprechen einan-der:
UML Rose Bemerkung
name NamevisibilityKind ExportControl-
Propertypublic (UML) entspricht PublicAccess (Ro-se)
concurrency ConcurrencydefaultValue InitValueRückgabetyp ReturnType In Rose ist ein Rückgabetyp kein Parameter,
sondern ein Attribut einer Operation. Es kannnur ein Rückgabetyp angegeben werden.
Die folgenden Informationen können nicht aus Abb. 4.19 extrahiert bzw. in einemRose-Modell hinterlegt werden:
• Eine dem AttributownerScope der MetamodellklasseOperation entsprechendeInformation kann nur mit einer sprachspezifischen Erweiterung von Rose im Mo-dell notiert werden. Z.B. enthält die Java-Erweiterung die entsprechende boolescheEigenschaftStatic.
• Weitere einstellbare Eigenschaften der Java-Erweiterung sindAbstract undFinal(entsprechend den booleschen Attributenabstract undisLeaf des Metamodells).
• Die EigenschaftenisQuery undisRoot 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 deklariertwerden. Genauer: Kein Verhaltensmerkmal der gleichen Art (Operation, Methode,Empfangserklärung für ein Signal) darf die gleiche Signatur in einem Klassifiziererhaben ([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ändig-keitsbedingung). Genauer: Die Typen der Parameter sollten im Namensraum desKlassifizierers der Operation enthalten sein ([OMG99], Seite 2-45).
4.5. KLASSENDIAGRAMM 150
• Operation-4: Die Klasse einer abstrakten Operation muß abstrakt sein ([OMG99],Seite 2-46), da eine Klasse mit einer abstrakten Operation keine direkten Exemplarebesitzen kann.
Eine Verletzung dieser Bedingungen wird von Rose nicht entdeckt. Die Überprüfungdieser Bedingungen läßt sich in Rose jedoch realisieren.
4.5.4 Assoziationen
Eine binäre Assoziation zwischen Klassen wird als Linie zwischen den Klassen model-liert. Die Assoziation kann optional benannt und mit einem Stereotyp und Zusicherungenversehen werden. Die Rollennamen der Klassen (optional mit Sichtbarkeit), die Kar-dinalitä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 B
2..41..1
#Rollenname-B-Rollenname-A
2..41..1
Assoziationsname<<Stereotyp>>
{Assoziationszusicherung}
Abbildung 4.20:Beispielhafte Notation einer Assoziation mit Rollennamen und Spezifi-kation 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 Assoziati-onsendes würden gegebenenfalls mit einem Link an das entsprechende Objekt geheftetwerden.
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 einan-
der:UML Rose Bemerkung
name NameisNavigable Navigableaggregation Aggregate In Rose ist Aggregate ein boolescher Wert,
der zwischen normaler Assoziation und Ag-gregation unterscheidet.
targetScope Static targetScope = instance entspricht Static = fal-se.
multiplicity Cardinalityvisibility ExportControl
151 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZChart Name : AssoziationNotationMetaUMLChart Filename : AssoziationNotationMetaUML.VobChart Type : UML Object Diagram
: Class
name = A
: Class
name = B
: AssociationEnd
name = Rollenname-AisNavigable = trueaggregation = nonetargetScope = instancemultiplicity = 1..1visibility = privateordering = unorderedchangeability = changeable
: AssociationEnd
name = Rollenname-BisNavigable = trueaggregation = nonetargetScope = instancemultiplicity = 2..4visibility = protectedordering = unorderedchangeability = changeable
: Association
name = Assoziationsname
type
type connection
connection
Abbildung 4.21:Metamodellexemplar der Assoziation aus Abb. 4.20 ohne Berücksichti-gung des Stereotypen und der Zusicherung.
Rose besitzt die folgenden Einschränkungen:
• Rollen (Assoziationsenden) können in Rose nicht mit einem Stereotyp markiertoder mit einer Zusicherung verbunden werden, obwohl Abb. 4.22 das Gegenteil an-deutet (Genauer: Die normale Benutzerschnittstelle bietet dazu keine Möglichkeit).In Rose können Zusicherungen zu einer Assoziation angegeben werden, obwohl dieExistenz eines Attributs „Constraints“ nicht dokumentiert und auch nicht durch dieSkript-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 Assozia-tionsname und assoziierten Klassifizierern sein ([OMG99], Seite 2-44). D.h. beimehreren Assoziationen zwischen zwei Klassifizierern muß ein Assoziationsnameexistieren.
• Assoziation-2: Eine Assoziation sollte mindestens in eine Richtung navigierbarsein (Vollständigkeitsbedingung).
• Assoziation-3: Ein navigierbares Assoziationsende sollte einen Rollennamen be-sitzen (Vollständigkeitsbedingung).
4.5. KLASSENDIAGRAMM 152
Chart Name : AssoziationNotationMetaRoseChart Filename : AssoziationNotationMetaRose.VobChart Type : UML Object Diagram
: Class
Name = A
Association
Name = AssoziationsnameDerived = falseStereotype = StereotypRole1Role2RolesLinkClass
: Role
Name = Rollenname-ANavigable = trueAggregate = falseStatic = falseCardinality = 1..1ExportControl = PrivateAccessClassStereotypeConstraintsAssociationKeysContainment = undefined
: Role
Name = Rollenname-BNavigable = trueAggregate = falseStatic = falseCardinality = 2..4ExportControl = ProtectedAccessStereotypeConstraintsAssociationKeysContainment = undefinedClass
: Class
Name = B
Abbildung 4.22:Interne Darstellung der Assoziation aus Abb. 4.20 in Rose. Die Attribute„Role1“ und „Role2“ der KlasseAssociation verweisen auf die Asso-ziationsenden der Assoziation. Das Attribut „Roles“ ist eine Sammlung(Collection) der Assoziationsenden, deren Benutzung dem Autor in derSkript-Sprache nicht möglich war. Das Attribut deutet jedoch an, daßRose auch n-äre Assoziationen unterstützen könnte.
153 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
• Assoziation-4:Die durch eine Assoziation verbundenen Klassifizierer sollten zumNamensraum 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 Objektmit Hilfe eines Pseudoattributs auf assoziierte Objekte zugreifen kann, d.h. Attribu-te und Operationen aufrufen kann. Bei der Java-Codeerzeugung benutzt Rose dieseRollennamen 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 spezi-elle Assoziationen.
Eine Aggregationen und Kompositionen beschreiben eine Ganzes-Teile-Beziehung.Im Metamodellexemplar wird das Ganze in einer Aggregations- bzw. Kompositionsbe-ziehung durch das Attributaggregation der KlasseAssociationEnd (die mit der Klasseverbunden ist, die das Ganze repräsentiert), festgelegt. Eine Aggregation in Rose ist ge-kennzeichnet durch das WertepaarAggregate = true undContainment = ByReferenceoderUnspecified, eine Komposition wird durchAggregate = true undContainment= ByValue gekennzeichnet.
Im Metamodellexemplar werdenqualifizierendeAttribute mit dem Assoziationsendeverbunden, an dem das Attribut notiert wird. In Rose gibt das AttributKeys der KlasseRole eine Sammlung (collection) von Attributen an, die die Exemplare des Assoziations-endespartitionieren(dies ist ein anderes (!) Assoziationsende als im Metamodell).
Eine Assoziationsklasse stellt sich im Metamodellexemplar ähnlich wie in Abb. 4.20angegeben dar, nur mit dem Unterschied, daß die Assoziation nicht durch ein Exemplarvon Association, sondern durch ein Exemplar vonAssociationClass repräsentiertwird. In Rose kennzeichnet das AttributLinkClass gegebenenfalls die Klasse, die dieMerkmale (Attribute) der Assoziationsklasse repräsentiert. In [OMG99] ist nicht ausge-schlossen, 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 Kom-positionsbeziehung sein ([OMG99], Seite 2-44).
Diese Bedingung wird von Rose trivialerweise eingehalten, da die Möglichkeit zurModellierung n-ärer Assoziationen fehlt.
4.5. KLASSENDIAGRAMM 154
• Aggregation-2: Nur ein Assoziationsende kann eine Aggregation bzw. Komposi-tion 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. diemaximale Kardinalität des Assoziationsendes, welches das Ganze kennzeichnet,beträgt maximal 1 ([OMG99], Seite 2-45).
ModelElement TaggedValue0..10..1
Stereotype0..10..1
Abbildung 4.23:Kompositionen mit der Kardinalität 0..1: Ein Eigenschaftswert (Tagged-Value) gehört entweder zu einem Modellelement oder zu einem Stereo-typ.
Beträgt die Kardinalität 0..1, kann die Klasse des „Teils“ an mehreren Kompositi-onsbeziehungen 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 weiterenKompositionsbeziehungen aus.
• Qualifikationsangabe-1:Nur eine binäre Assoziation kann qualifiziert werden.
• Qualifikationsangabe-2:Der Name des qualifizierenden Attributs sollte nicht derName eines Attributs der Klasse sein, deren Objekte über die Qualifikationsangabeauf verbundene Objekte zugreifen.
Das Attribut, welches die Assoziation qualifiziert, ist eine Eigenschaft der Assozia-tion (vgl. [BRJ99a], Seite 165). Eine Qualifikationsangabe impliziert eine Reali-sierung, bei der über einen Wert auf eine Menge von Exemplaren (meistens genauein Exemplar) zugegriffen werden kann.
• Assoziationsklasse-1:Die Namen der Assoziationsenden (Rollenname) und dieAttributnamen der Assoziationsklasse müssen eindeutig sein ([OMG99], Seite 2-44).
• Assoziationsklasse-2:Eine Assoziationsklasse kann nicht zwischen sich selbst undirgendeinem Modellelement definiert werden ([OMG99], Seite 2-44), d.h. eine as-soziierte 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 Asso-ziation verknüpft werden (vgl. [BRJ99a], Seite 168), da sie selbst eine Assoziationist.
Diese Konsistenzbedingung wird von Rose eingehalten.
155 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
Chart Name : New Class DiagramChart Filename : clsUntitled2.VobChart Type : UML Class DiagramClass 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), sondernauch zwischen Interfaces (siehe Abschnitt 4.5.7), Signalen (siehe Abschnitt 4.5.10) undKollaborationen existieren. Eine Generalisierung kann benannt werden und einen Diskri-minator besitzen, der das Abstraktionsmerkmal der Generalisierung beschreibt.
Oberklasse
Unterklasse
Generalisierungsname
Abbildung 4.25: Einfache Generalisierungsbeziehung ohne Diskriminator
Die Abbildungen 4.26 und 4.27 zeigen die Darstellung von Abb. 4.25 als Metamodel-lexemplare.
In Rose kann nur eine Generalisierung zwischen genau zwei Klassifizierern benanntund mit einem Stereotyp markiert werden. In Rose kann sogar die Sichtbarkeit der Gene-ralisierungsbeziehung spezifiziert werden, die im Metamodell nicht vorgesehen ist. Be-sitzt eine Oberklasse zwei Unterklassen, dann kann diese Beziehung durcheineGene-ralisierungsbeziehung miteinemVorfahren undzwei Nachkommen modelliert werden.Rose unterstützt diese Möglichkeit, jedoch kann die Generalisierungsbeziehung in die-sem Fall nicht spezifiziert werden, d.h. der Name, ein Stereotyp und die Sichtbarkeitkann nicht angegeben werden. In Rose fehlt die Möglichkeit, einen Diskriminator an-zugeben ebenso wie die Möglichkeit, Zusicherungen für die Generalisierungsbeziehung(disjoint/overlapping und incomplete/complete), die sich meist auf mehrere Generalisie-rungen beziehen, zu spezifizieren.
Es gibt nicht nur Konsistenzbedingungen für die Modellelemente, die durch die Gene-ralisierung verbunden sind, sondern auch für deren Inhalte. So werden u.a. die Attribute,
4.5. KLASSENDIAGRAMM 156
Chart Name : GeneralisierungNotationMetaUMLChart Filename : GeneralisierungNotationMetaUML.VobChart Type : UML Object Diagram
: Class
name = Oberklasse
: Class
name = Unterklasse
: Generalization
name = Generalisierungsnamediscriminator
parent
specialization
generalization
child
Abbildung 4.26: Darstellung von Abb. 4.25 als UML-Metamodellexemplar.
: Class
Name = Oberklasse
: Class
Name = Unterklasse
: InheritRelation
Name = GeneralisierungsnameStereotypeSupplierNameExportControl
Abbildung 4.27: Darstellung von Abb. 4.25 als Rose-Metamodellexemplar.
Operationen und Assoziationen einer Klasse abhängig von der spezifizierten Sichtbarkeitvererbt.
• Generalisierung-1:Klassifizierer, die alsRoot (Wurzel) gekennzeichnet sind, dür-fen keine Vorfahren besitzen ([OMG99], Seite 2-51).
• Generalisierung-2:Klassifizierer, die alsLeaf (Blatt) gekennzeichnet sind, dürfenkeine Nachkommen besitzen ([OMG99], Seite 2-51).
In Rose kann diese Eigenschaft in der Java-Erweiterung (Eigenschaft Final) spezi-fiziert werden.
• Generalisierung-3:Ein Klassifizierer darf kein Unter- bzw. Oberklassifizierer vonsich selbst sein, d.h. ein Graph, der die Vererbungshierachie darstellt, mit Klassi-fizierern als Knoten und Generalisierungen als Kanten, darf keine Zykel besitzen(vgl. [OMG99], Seite 2-51).
Diese Konsistenzbedingung wird von Rose eingehalten.
157 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
• Generalisierung-4:Die an einer Generalisierung beteiligten Modellelemente müs-sen von der gleichen Art sein, d.h. sie müssen die gleichekonkreteMetamodellklas-se besitzen (vgl. [OMG99], Seite 2-52).
Klassen, Interfaces, Signale und Komponenten sind unterschiedliche (konkrete)Metamodellklassen.
• Generalisierung-5: Die durch eine Generalisierung verbundenen Modellelementemü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 ab-strakte Operationen realisieren, d.h. Operationen mit der gleichen Signatur alsnicht-abstrakt deklarieren (Vollständigkeitsbedingung).
4.5.7 Interfaces
Interfaces (Schnittstellen) dienen der Spezifikation eines Dienstes, der von einer Klasseoder einer Komponente angeboten bzw. unterstützt wird. Interfaces können als Klassemit dem Stereotyp «Interface» (ausführliche Form, Abb. 4.28) oder mit dem speziellenInterfacesymbol (siehe Abb. 2.2, Seite 15) dargestellt werden.
Interfacename<<Interface>>
Abbildung 4.28:Darstellung eines Interface als stereotypisierte Klasse ohne Operationen.
Die Abbildungen 4.29 und 4.30 zeigen die entsprechenden Metamodellexemplare derAbb. 4.28.
: Interface
name = InterfacenameisAbstract = falseisRoot = falseisLeaf = false
Abbildung 4.29: Abb. 4.28 als Instantiierung der MetmodellklasseInterface.
4.5. KLASSENDIAGRAMM 158
: Class
Name = InterfacenameStereotype = InterfaceAbstract = falseAttributesOperations = (Referenzen)ExportControlCardinalityConcurrencyStateMaschine
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 undKlasse unterschieden. In Rose kann ein Interface nur anhand des Stereotypen von einerKlasse 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 Si-gnale.
• Interface-2: Ein Interface darf keine Modellelemente enthalten ([OMG99], Seite2-52).
• Interface-3: Alle Operationen eines Interfaces müssen „public“ ([OMG99], Seite2-52) sein.
• Interface-4: Die Operationen eines Interfaces und das Interface selbst sind implizitabstrakt.
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 eindeutigsein ([OMG99], Seite 2-47).
• Interface-7: Das mit einem Interface gegenüberliegende Assoziationsende darfnicht navigierbar sein ([OMG99], Seite 2-45).
Da in Rose Interfaces alle Merkmale einer Klasse mit Ausnahme eines Stereotypenbesitzen können, sind weitere Bedingungen zu überprüfen:
• Interface-8: Interfaces sollten nicht „aktiv“ sein (AttributConcurrency).
159 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
• 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 nichtverhindert 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 Anwendungs-falls durch eine Kollaboration modelliert werden (in Rose nicht möglich). Die Instantiie-
realisierendeKlasse
Operation()
Interfacename
Operation()
<<Interface>>
Abbildung 4.31: Die Klasse realisiert die Operation des Interfaces.
rung von Abb. 4.31 als Metamodellexemplar (Abb. 4.32) zeigt, daß die Operationsobjek-te, als „Teil“ einer Komposition, eine eigene Identität besitzen.
Im Metamodell der UML (siehe Abb. 3.26, Seite 68) ist eine Realisierung eine ste-reotypisierte 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 ei-ne Realisierungsbeziehung folgerichtig nicht mit einem Stereotyp markiert werden kann.Eine Realisierungsbeziehung kann nicht näher spezifiziert werden, d.h. sie kann wederbenannt werden, noch kann die im Metamodell vorgesehene Beschreibung der Abhängig-keitsbeziehung (mapping) spezifiziert werden.
Für Realisierungsbeziehungen sind folgende Konsistenzbedingungen zu beachten:
• Interface-11: Ein Interface sollte von einer Klasse oder einer Komponente reali-siert werden.
• Interface-12: Interfaces realisieren keine anderen Elemente, d.h. ein Interfacein einer Realisierungsbeziehung muß das spezifizierende Element (Metamodell:supplier) sein.
• Operation-13: Klassen, die Interfaces realisieren, müssen alle Operationen desInterfaces (mit der gleichen Signatur) deklarieren (Vollständigkeitsbedingung).
Die Verletzung von Konsistenzbedingungen in diesem Abschnitt wird von Rose nichtverhindert oder entdeckt.
4.5. KLASSENDIAGRAMM 160
Chart Name : RealisierungNotationMetaUMLChart Filename : RealisierungNotationMetaUML.VobChart Type : UML Object Diagram : Interface
name = Interfacename
: Operation
name = Operation
: Abstraction
namemapping = (MappingExpression)
: Stereotype
name = realize
: Class
name = realisierendeKlasse
: Operation
name = Operation
owner feature
supplier
supplierDependency
clientDependency
client
owner feature
Abbildung 4.32:Instantiierung von Abb. 4.31 als Metamodellexemplar. Die Objekte be-sitzen die notwendigen Methoden zur Identifizierung der Realisierungs-beziehung und der beteiligten Modellelemente.
Chart Name : RealisierungNotationMetaRoseChart Filename : RealisierungNotationMetaRose.VobChart Type : UML Object Diagram
: Class
Name = InterfacenameStereotyp = Interface
: Class
Name = realisierendeKlasse
: RealizeRelation
Name = (kann nicht gesetzt werden)Stereotype = (kann nicht gesetzt werden)SupplierName = InterfaceName
: Operation
: Operation
Abbildung 4.33: Interne Sicht von Rose auf Abb. 4.31.
161 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
4.5.9 Abhängigkeitsbeziehungen
Neben Realisierungsbeziehungen gibt es noch weitere Abhängigkeitsbeziehungen (sieheAbb. 3.26, Seite 68).
Die folgenden Konsistenzbedingungen für Abhängigkeitsbeziehungen und Einschrän-kungen für Rose existieren (ohne Vollständigkeitsanspruch): (siehe auch [BRJ99a])
• Abhängigkeit-1: Eine mit «derive» markierte Abhängigkeitsbeziehung ist eine Be-ziehung zwischen zwei Attributen oder zwei Assoziationen.
Abhängigkeiten zwischen Attributen können in Rose nicht semantisch korrekt mo-delliert werden. Ein Attribut kann zwar als abgeleitet (boolesches Attributderivedder KlasseAttribute) markiert werden, aber eine Beziehung zu einem oder meh-reren unabhängigen Attributen und eine (berechenbare) Abbildung kann nicht spe-zifiziert werden. Es besteht jedoch die Möglichkeit, diese Informationen als Doku-mentation zum Attribut zu hinterlegen.
Abhängigkeiten zwischen zwei Assoziationen können in Rose modelliert werden.Zu dieser Abhängigkeit können jedochkeine weiteren Informationen hinterlegtwerden.
• Abhängigkeit-2: Bei einer mit «instanceOf» markierten Abhängigkeitsbeziehungist die Quelle ein Exemplar und das Ziel eine Klasse oder die Quelle ist eine Klasseund 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 undmit einem Stereotypen markiert werden. Die zweite Möglichkeit einer «instance-Of»-Abhängigkeit kann überprüft werden: Die unabhängige Klasse muß das Ste-reotyp oder den Typ «MetaClass» besitzen.
• Abhängigkeit-3: Eine mit «refine» markierte Abhängigkeitsbeziehung ist eine Be-ziehung zwischen Klassen.
Diese Abhängigkeit kann in Rose (mit Stereotyp) modelliert werden.
• Abhängigkeit-4: Eine mit «access», «import» oder «friend» markierte Abhängig-keitsbeziehung ist eine Beziehung zwischen Namensräumen (meist Paketen).
In Rose können Abhängigkeiten zwischen Paketen zwar modelliert, aber nicht ste-reotypisiert werden. Rose ermöglicht die Überprüfung von Zugriffsverletzungen(Menü Report - Show Access Violations). Hierbei wird überprüft, ob sich die Klas-sen eines Klasssendiagramms im gleichen Paket wie das Diagramm befinden oderdurch eine modellierte Abhängigkeit zwischen Paketen verfügbar sind.
4.5. KLASSENDIAGRAMM 162
4.5.10 Signale
Signale, die in Zustandsautomaten und Aktivitätsdiagrammen benutzt werden, können inKlassendiagrammen deklariert werden.
Die Existenz eines Signals kann in Klassendiagrammen modelliert werden. Dabeiwird ein Signal als Klasse mit dem Stereotyp «signal» modelliert (Abb. 4.34). OptionaleParameter des Signals werden als Attribute im Klassenrechteck dargestellt.
SignalName<<signal>>
Klassenname
Operation()<<signal>> SignalName()<<send>>
Abbildung 4.34:Eine Klasse mit dem Stereotyp «signal» spezifiziert ein Signal, eine«send»-Abhängigkeit gibt die Verwendung eines Signals an und einemit «signal» markierte Operation erklärt den Empfang eines Signals.
Eine modellierte «send»-Abhängigkeit zwischen einer Operation und einem Signalbedeutet, daß die Operation das Signal senden kann. Diese Abhängigkeit kann in Rosenicht 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 eineAbhängigkeit zwischen Klassen.
Möchte man explizit modellieren, daß Objekte einer Klasse ein bestimmtes Signalempfangen können (siehe auch Metamodell, Abb. 3.33, Seite 83), so kann dies durchdie Deklarierung einer gleichnamigen Operation mit dem Stereotyp «signal» angegebenwerden (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 typi-scherweise Fehlersituationen signalisieren. Der Sender der Ausnahme bricht seine Aus-fü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 «Ex-ception» modelliert. Die Ausnahmen, die eine Operation auslösen kann, können durcheine «send»-Abhängigkeit spezifiziert oder in der Spezifikation der Operation formuliertwerden. Letzteres wird von Rose unterstützt, indem zu einer Operation ein beliebigerText zur Spezifizierung der Ausnahmen eingegeben werden kann (Attributexceptionsder KlasseOperation).
163 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
Für Signale können die folgenden Konsistenzbedingungen identifiziert werden:
• Signal-1: Zu einer Operation mit dem Stereotyp «Signal» sollte ein gleichnamigesSignal existieren (Vollständigkeitsbedingung)
• Signal-2: Die Anzahl der Argumente der „Signaloperation“ sollte mit der Anzahlder Argumente (Attribute) des Signals übereinstimmen (vgl. [OMG99], Seite 2-95SendAction).
• Signal-3: Die Parameternamen und -typen einer „Signaloperation“ sollten mit denAttributnamen und -typen übereinstimmen.
Die Reihenfolge der Parameter kann nicht vorgeschrieben werden, da die Attributeeines Signal (einer Klasse) nicht geordnet sind.
• Signal-4: Eine Klasse, die ein Signal empfangen kann, sollte einen Zustandsauto-maten besitzen, der die Reaktion auf den Empfang des Signals spezifiziert (Voll-ständigkeitsbedingung).
• Signal-5: Eine Klasse, die ein Signal empfangen kann, sollte eine aktive Klassesein.
• Signal-6: Zu einer mit «send» markierten Abhängigkeitsbeziehung zwischen einerOperation und einem Signal (d.h. die Operation kann das Signal senden), solltein einem Aktivitätsdiagramm der Operation (falls vorhanden) die Verwendung desSignals 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 Zustandsautoma-ten, so sollte dort das Senden des Signals ebenfalls modelliert sein (Vollständig-keitsbedingung).
• 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 las-sen noch einige Fragen unbeantwortet:
• Welche Bedeutung hat die Sichtbarkeit der Merkmale eines Signals?
• Da Signale generalisierbare Modellelemente sind, können „Signalhierarchien“ mo-delliert werden (Beispiel: siehe [BRJ99a], Seite 321).
– Wie funktioniert in diesem Fall der Vererbungsmechanismus?5Nach [BRJ99a], Seite 315, können Signale Operationen besitzen!
4.5. KLASSENDIAGRAMM 164
– Wenn eine Klasse ein bestimmtes Signal empfangen kann, kann es dann auchein Sub-Signal empfangen?Nach dem Prinzip der Substituierbarkeit müßte eine Klasse auch Sub-Signaleempfangen können. Nach [Alh98], Seite 199, kann ein Sub-Signal auch Tran-sitionen, 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 spe-zifiziert werden (Abb. 4.35, vgl. [BRJ99a], Seite 182 ff). Typen sind mit «type» stereo-
IMitarbeiter
IManager
Person
1..1
0..*
+Vorgesetzer: IManager
+Mitarbeiter: IMitarbeiter
1..1
0..*
Abbildung 4.35: Spezifizierung von Rollen durch Interfaces
typisierte Klassen, die sich von Interfaces dahingehend unterscheiden, daß die Definitioneines Typs Attribute enthalten kann. Die Typen in Abb. 4.36 repräsentieren verschiedeneRollen, die ein Objekt der Klasse Person im Laufe der Zeit spielen kann.
Person
Bewerber<<type>>
Mitarbeiter<<type>>
Pensionär<<type>>
Abbildung 4.36: Typen, die potentielle Rollen der Klasse Person darstellen.
Die Benutzung von Interfaces oder Typen zur Spezifizierung einer Rolle in einer Asso-ziation wird im Metamodell durch das Attributspecification der KlasseAssociation-
165 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
End spezifiziert. Ein Assoziationsende kann durch mehrere Typen und Interfaces spezifi-ziert 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 diedurch 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 wieInterfaces sind die Operationen implizit abstrakt.
4.6 Interaktionsdiagramme
Interaktionsdiagramme werden benutzt, um den Ablauf der Kommunikation zwischenObjekten zur Erfüllung einer bestimmten Aufgabe anhand von Botschaften zu spezifi-zieren. Die beiden Interaktionsdiagramme der UML, Kollaborations- und Sequenzdia-gramm, 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 denHintergrund rückt. Ein Kollaborationsdiagramm der Spezifikationsebene besteht aus Klas-sifizierer- und Assoziationsrollen, die Objekte und Links repräsentieren, und Botschaften,während ein Kollaborationsdiagramm der exemplarischen Ebene Objekte, Links und Sti-muli enthält.
Sequenzdiagramme existieren nur auf einer exemplarischen Ebene. Sie heben die Rei-henfolge der Botschaften bzw. Stimuli hervor ohne den strukturellen Kontext zu zeigen.
In Rose können Kollaborationsdiagramme nicht auf einer Spezifikationsebene mo-delliert werden. Kollaborationsdiagramme der exemplarischen Ebene und Interaktions-diagramme werden in Rose intern auf die selben Klassen abgebildet (Abb. 4.45). Diesermö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 oderEmpfänger von Botschaften bzw. Stimuli. Neben der Klassenzugehörigkeit einer Klas-sifiziererrolle 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 derRolle 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 Inter-aktionsdiagramm besteht aus einem Objektnamen, einer Klassifizierer-rolle und dem Namen der Klasse des Objekts. Optional können weitereMerkmale des Objekts dargestellt werden.
Im Metamodell (Abb. 3.42, Seite 98) ist eine Klassifiziererrolle (ClassifierRole)mit genau einem Basisklassifizierer (Pseudoattributbase) assoziiert. Eine entsprechendeMetaklasse für Objekte, die eine Rolle in einer Kollaboration spielen, z.B. ObjectRole,ist im PaketKollaboration 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 mitmindestenseinem Klassifizierer assoziiert).
Die Abbildung einer Klassifiziererrolle (Abb. 4.37) auf das Metamodell der UMLbzw. auf ein Metamodell eines Werkzeugs ist auf (mindestens) zwei Arten möglich:
1. Der Rollenname und der Klassenname wird auf das Attributname der Metamodell-klasseClassifierRole abgebildet (Abb. 4.37).
: ClassifierRole
name = Mitarbeiter:Person
Abbildung 4.39:Instantiierung von Abb. 4.39. Geeignet für ein Werkzeug, welches dieModellierung von Klassifiziererrollen zuläßt, ohne die Existenz der Ba-sisklasse zu fordern.
Bei dieser Art der Abbildung muß die folgende Konsistenzbedingung überprüftwerden:
• Inter-1: Es muß eine Klasse mit dem Namen der Klasse (hier „Person“) exi-stieren. Diese Klasse muß die optional dargestellten Merkmale besitzen. Diesgilt entsprechend für Objekte in Interaktionsdiagrammen.
167 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
Eine werkzeugunterstützte Überprüfung dieser Bedingung erfordert die eindeutigeIdentifizierung des Rollen- und Klassennamens.
2. Es wird nur der Rollenname auf das Attributname der Metamodellklasse abgebil-det. Der Name der Klasse ist implizit der Name der Basisklasse der Klassifizierer-rolle (Abb. 4.40). Läßt das Werkzeug in diesem Fall nur die Darstellung vorhan-
Chart Name : New Object DiagramChart Filename : objUntitled2.VobChart Type : UML Object Diagram
: ClassifierRole
name = Mitarbeiter
: Class
name = Personbase
Abbildung 4.40:Alternative, semantisch korrekte Instantiierung von Abb. 4.37. Bei die-ser Art der Instantiierung muß eine Klasse mit dem Namen „Person“existieren.
dener Merkmale der Basisklasse zu, wird die oben genannte Konsistenzbedingungaktiv 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 Empfangsob-jekt „kennt“. Dies wird in einem Kollaborationsdiagramm durch eine Assoziationsrollebzw. einen Link dargestellt. Bei einem Botschaftenaustausch zwischen Objekten wirddieser Link zur Kommunikation genutzt. Eine Assoziation zwischen Klassifiziererrollenbzw. ein Link zwischen Objekten basiert auf einer Assoziation zwischen Klassen.
Das Klassendiagramm in Abb. 4.41 zeigt die Basisklassifizierer und die Basisassozia-tion für die Kollaborationsdiagramme in Abb. 4.42 und Abb. 4.43. Abb. 4.44 zeigt dieZusammenhänge zwischen dem Klassendiagramm (Abb. 4.41) und dem Kollaborations-diagramm 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 dieexemplarische Ebene übertragen: Zu einem Link zwischen Objekten muß eine (ge-erbte) Assoziation zwischen den Klassen der Objekte existieren.
Ein Link kennzeichnet eine Kommunikationsverbindung, über die ein Objekt eineBotschaft an ein anderes Objekt schicken kann. Damit Objekte, deren Basisklassennicht assoziiert sind, Botschaften austauschen können, gibt es Ausnahmen von derBedingung Inter-2 (siehe Abschnitt 4.6.3).
Bei aktiver Konsistenzunterstützung kann der Name der Assoziation übernommenwerden.
4.6. INTERAKTIONSDIAGRAMME 168
Mitarbeiter<<type>>
Manager<<type>>
Person
*
0..1
leitet
+MA:Mitarbeiter
+Leiter:Manager
*
0..1
Abbildung 4.41:Die Rollen einer Person werden durch Typen spezifiziert. Die Abbildun-gen 4.42 und 4.43 zeigen die Benutzung dieser Information in Kollabo-rationsdiagrammen.
/Mitarbeiter:Person /Manager:Person0..1*
leitet
0..1*
Abbildung 4.42:Verwendung der Typen aus Abb. 4.41 als Klassifiziererrollen in einemKollaborationsdiagramm der Spezifikationsebene.
Müller/Mitarbeiter : Person
Schmidt/Manager : Personleitet
Abbildung 4.43:Verwendung der Typen aus Abb. 4.41 als Rollen für Objekte in einemKollaborationsdiagramm der exemplarischen Ebene.
169 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
Cha
rt N
ame
: New
Obj
ect D
iagr
amC
hart
File
nam
e : K
olla
bora
tionB
espi
elM
eta.
Vob
Cha
rt T
ype
: UM
L O
bjec
t Dia
gram
: C
lass
ifier
Rol
ena
me
= M
itarb
eite
r
: C
lass
nam
e =
Per
son
: C
lass
ifier
Rol
ena
me
= M
anag
er
: A
ssoc
iatio
nEnd
Rol
ena
me
colla
bora
tionM
ultip
licity
= *
: A
ssoc
iatio
nEnd
Rol
ena
me
colla
bora
tionM
ultip
licity
= 0
..1
: A
ssoc
iatio
nRol
ena
me
mul
tiplic
ity
Ass
ocia
tionE
ndna
me
= M
Am
ultip
licity
= *
: A
ssoc
iatio
nEnd
nam
e =
Lei
ter
mul
tiplic
ity =
0..1
: A
ssoc
iatio
nna
me
= le
itet
: C
lass
nam
e =
Mita
rbei
ter
: C
lass
nam
e =
Man
ager
base
base
type
type
base ba
se
base
type
type
part
icip
ant
spec
ifica
tion
spec
ifica
tion
part
icip
ant
Abbildung 4.44:Instantiierung der Abbildungen 4.41 und 4.42. Eine Klassifiziererrol-le basiert auf einer Klasse. Eine Assoziationsrolle zwischen Klassifi-ziererrollen basiert auf einer Assoziation zwischen den entsprechendenKlassen.
4.6. INTERAKTIONSDIAGRAMME 170
• Inter-3: Optionale Qualifizierer einer Assoziationsendrolle müssen eine Teilmengeder 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 zwischencollaborationMultiplicity undmultiplicity ei-ner 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 Beispielbekannt.
Weitere sinnvolle Konsistenzbedingungen:
• Der Name der Klassifiziererrolle sollte der Name des entsprechenden Assoziations-endes 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 Klas-sifiziererrolle eine Teilmenge der Merkmale des spezifizierenden Klassifiziererssein.
• Die Kardinalität einer Assoziationsendrolle sollte eine Einschränkung der Kardina-lität des Basisassoziationsendes sein oder mit ihr übereinstimmen.
Offene Frage: In welcher Modellierungssituation sollte man die Kardinalität ein-schränken?
• Die Sichtbarkeit einer Assoziationsendrolle darf nicht erweitert werden.
• Eine Assoziationsendrolle darf nur dann eine Aggregation/Komposition kennzeich-nen, wenn dies auch für das Basisassoziationsende gilt.
Die Kardinalität einer Assoziationsrolle gibt die Anzahl der Links an, die diese Rollein der Kollaboration spielen. In [OMG99] ist kein Beispiel angegeben, das zeigt, wann dieKardinalität einer Assoziationsrolle modelliert wird. Eine Notation für die Kardinalitäteiner Assoziationsrolle ist ebenfalls nicht definiert.
Objekte und Links in Interaktionsdiagrammen werden in Rose auf die KlasseOb-jectInstance bzw. Link abgebildet (Abb. 4.45).
Bei der Modellierung von Objekten in Interaktionsdiagrammen kann in Rose der Klas-senname des Objekts aus den vorhandenen Klassen gewählt werden. Die Eingabe eines
171 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
RoseItem
Stereotype
Element
Name
AssociationOperation
Class
Link
LinkRole1LinkRole2LinkRole1VisibilityLinkRole2Visibility
AddMessageTo()AssignAssociation()DeleteMessage()GetMessages()UnAssignAssociation()
0..10..1Message
FrequencySynchronization
GetSenderObject()GetReceiverObject()IsMessageToSelf()IsOperation()GetOperation()GetLink()
0..10..1ObjectInstance
ClassNameLinksMultipleInstancesPersistence
AddLink()DeleteLink()GetClass()IsClass()
0..10..1
+Sender+Receiver
Abbildung 4.45:Metadarstellung der Objekte, Links und Botschaften (Message) in Rose.
beliebigen Klassennamens ist nicht möglich. Multi-Objekte (AttributMultipleInstan-ces) repräsentieren die Existenz mehrerer Objekte. Die Bedingung Inter-1 kann von Rosegeprüft werden (Menü: Report - Show unresolved Objects).
Nach dem gleichen Schema kann in Kollaborationsdiagrammen eine benannte(!) Ba-sisassoziation eines Links ausgewählt werden. Dabei werden die Rollen- und Qualifizie-rernamen der Assoziationsenden sowie der Assoziationsname übernommen. Die Rollen-und Qualifizierernamen werden an den Link-Enden und der Assoziationsname, der durcheinen Linknamen erweitert werden kann, als Name des Links dargestellt. Unter den aus-wählbaren Assoziationen befinden sich neben den geerbten Assoziationen der Basisklas-sen auch Assoziationen zwischen den Oberklassen der Basisklassen, die nicht vererbtwerden (die Sichtbarkeit der Assoziationsenden istprivate). Verletzungen der Bedin-gung Inter-2 werden nicht identifiziert, zusätzliche Qualifizierer können nicht hinzuge-fü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 odermehrerer Empfänger. Der eigentliche Inhalt der Botschaft besteht aus einer Aktion (mei-stens ein Operationsaufruf) und optionalen Parametern.
4.6. INTERAKTIONSDIAGRAMME 172
DestroyAction ReturnActionTerminateAction
Operation
CallAction
1
*
+operation1
*
SendAction
Reception
Signal
*
1
*
+signal 1
0..*
1
+reception 0..*
+signal1
BehavioralFeature
*
*
+raisedSignal
*
+context*
CreateAction
Feature
Classifier
1
0..*
+instantiation1
0..*
1
+feature
{ordered}
+owner1
Link
Instance
1..*
*
+classifier1..*
*
Argument
value : Expression
Stimulus0..1*
+communicationLink
0..1*
*
*
*
+argument*{ordered}
1
*
+sender1
* *
1
*
+receiver1
Message
*
0..1
*
+activator
0..1
*
*
+predecessor
*
*
Action
recurrence : IterationExpressiontarget : ObjectSetExpressionisAsynchronous : Booleanscript : ActionExpression
0..1 *0..1
+actualArgument
*{ordered}
*
1
*
+dispatchAction 1
*1 *
+action
1
Abbildung 4.46:Die Ausführung einer Aktion erzeugt einen Stimulus, welcher dieSende- und Empfangsinstanz referenziert, einen Link zur Kommunika-tion benutzt und eventuell Argumente enthält.
173 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
Die Ausführung der Aktion erzeugt eine entsprechende Anzahl von Stimuli, die je-weils über einen Link (communicationLink) von einem Sendeexemplar zu einem Emp-fangsexemplar 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 Stimuliführt beim Empfänger zur Ausführung eines Verhaltens entsprechend der Aktion.
Der Kommunikationslink kann in speziellen Fällen (auf der Metaebene) fehlen, ob-wohl er im Kollaborationsdiagramm dargestellt wird. Dies gilt sowohl für die Spezifi-kationsebene, in der eine Assoziationsrolle einen oder mehrere Links repräsentiert, alsauch für die exemplarische Ebene. In den folgenden Fällen kann ein Link bzw. eineAssoziation als Basis für eine Kommunikation zwischen Sender und Empfänger fehlen:
• Dem Sender wurde eine Referenz auf das Empfangsexemplar als Parameter überge-ben. In diesem Fall kann das Link-Ende des Empfängers mit «parameter» markiertwerden.
• Der Empfänger der Botschaft/des Stimuli ist global oder lokal sichtbar. Dann kanndas Link-Ende mit «global» oder «local» markiert werden.
• Der Sender und der Empfänger repräsentieren das gleiche Objekt. Dann kann dasLinkende mit «self» markiert werden.
Rose ermöglicht die Spezifizierung der Link-Enden, indem dem Sender und demEmpfänger einer Botschaft eine Sichtbarkeit zugeordnet wird (AttributLinkRole1Vi-sibility bzw. LinkRole2Visibility der KlasseLink). Zur Verfügung stehen u.a. dieWerte „Parameters“, „Global“ und „Local“. Mit diesen Informationen kann die Bedin-gung Inter-2 neu formuliert werden:
• Inter-2’: Zu einem Link zwischen Objekten muß entweder eine (geerbte) Assozia-tion zwischen den Basisklassen existieren oder der Link muß mit Parameter, Globaloder Local markiert sein oder die beiden Link-Enden verweisen auf das gleiche Ob-jekt (self).
Im Metamodell (Abb. 4.46) werden Operationsaufrufe einer Botschaft auf die KlasseCallAction abgebildet. Für einen Operationsaufruf gilt die folgende Konsistenzbedin-gung:
• Inter-5: Der Name der Operation muß mit dem Namen einer Operation des Emp-fangsobjekt übereinstimmen bzw. muß die Klasse des Empfangsobjekts die Opera-tion deklariert oder geerbt haben.
Bei der Spezifikation einer Botschaft ermöglicht Rose die Auswahl einer vom Empfängerangebotenen Operation (inklusive geerbter öffentlicher Operationen). Alternativ kann einbeliebiger Text als Botschaft eingegeben werden. Dieser Text referenziert aus der Sichtvon Rose keine Operation und ist in diesem Sinne nicht konsistent. Anstelle eines Textes,
4.6. INTERAKTIONSDIAGRAMME 174
: ArtikelLager
: ArtikelReservierung
1: Reservierung(long, double)
Abbildung 4.47:Notation einer Botschaft im Kollaborationsdiagramm, die einen Opera-tionsaufruf spezifiziert. Die Argumente werden in diesem Fall durch dieParametertypen der Operation repräsentiert.
der eine Operation bzw. eine „Signaloperation“ repräsentieren sollte, ist es möglich, auseinem Interaktionsdiagramm heraus eine Klasse um die gewünschte Operation zu erwei-tern. Im Falle einer referenzierten Operation stellt Rose die Operationsignatur in der Näheeines Pfeils dar (Abb. 4.47), der die Richtung der Botschaft kennzeichnet. Rose bietet dieMö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 desEmpfangsobjekts gelöscht, wird der Operationsname inklusive Parametertypen intern alsText gespeichert, d.h. die entsprechende Botschaft wird nicht aus dem Interaktionsdia-gramm gelöscht. Rose warnt nicht vor der Löschung der Operation, obwohl sie eineInkonsistenz zur Folge hat.
Das Senden eines Signals wird im Metamodell auf die KlasseSendSignal 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 Operationnicht dargestellt, d.h. man kann visuell nicht zwischen Operationen und Signalen unter-scheiden.
Die Darstellung der Argumente einer Botschaft einerCallAction oderSendActionist 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 (Pseu-doattributargument der KlasseStimulus).
2. Ein Argumentausdruck, dessen Auswertung die Aktualargumente bestimmt, wirdauf die Argumente der mit dem Stimulus assoziierten Aktion abgebildet (Pseudoat-tribut actualArgument der KlasseArgument).
3. Die Typen der Argumente werden zusammen mit den Namen der Operation/desSignals dargestellt. Dann werden die Argumente auf die Parameter-Typen der Ope-ration bzw. die Attributtypen des Signals abgebildet.
175 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
Rose unterstützt nur die letzte Möglichkeit der Argumentdarstellung semantisch kor-rekt, die anderen Möglichkeiten können zwar genutzt werden (eine Nachricht kann einbeliebiger 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 inInteraktionsdiagrammen benutzt werden. Rückgabeaktionen werden nur in Sequenzdia-grammen gezeigt. Die anderen Aktionsarten besitzen in Sequenzdiagrammen eine eigenegraphische Notation (siehe Abb. 3.38, Seite 93). Die Modellierung dieser Aktionsartenwird von Rose nicht unterstützt. Da die Stereotypen der Operationen in den Interaktions-diagrammen nicht angezeigt werden, ist auch die alternative Darstellungsart mit Hilfe vonStereotypen in Rose nicht möglich.
Der Rückgabewert einer Rückgabeaktion wird auf das Argument der Aktion abgebil-det. Eine Rückgabeaktion setzt einen vorherigen Operationsaufruf voraus (Konsistenzbe-dingung siehe 4.6.4 Kontrollfluß).
Der Empfänger der Botschaft einer Erzeuge-Aktion ist das Objekt, welches durch denEmpfang der Botschaft bzw. des Stimuli erzeugt wurde. Eine Erzeuge-Aktion besitztkein explizites Ziel (target), da das Ziel implizit der Empfänger der Botschaft ist. Da imMetamodell eine Erzeuge-Aktion mit genau einem Klassifizierer assoziiert ist, muß diefolgende Konsistenzbedingung berücksichtigt werden:
• Inter-7: Der Empfänger der Botschaft einer Erzeuge-Aktion muß ein Objekt derKlasse sein, mit der die Aktion assoziiert ist.
Die Botschaft einer Zerstöre-Aktion führt zur Zerstörung des Empfangsobjekts. DieBotschaft einer Terminiere-Aktion, die zur Selbstzerstörung eines Objekts führt, muß diefolgende Konsistenzbedingung erfüllen:
• Inter-8: Der Empfänger und der Sender einer Botschaft einer Terminiere-Aktionmüssen übereinstimmen.
4.6.4 Kontrollfluß
Wenn ein Sender einem Empfänger eine Botschaft sendet, kann der Empfänger auf denEmpfang der Botschaft reagieren, indem er selbst wiederum eine Botschaft schickt usw.Die Botschaften bilden eine sequentiell zeitlich geordnete Folge (Kontrollfluß), die im-mer zu einem Prozess oder Thread gehört. Die Folge der Botschaften wird visuell durchSequenznummern (siehe Abschnitt 3.2.2) dargestellt.
Man unterscheidet zwischen flachen und prozedualen bzw. verschachtelten Kontroll-flüssen (siehe [BRJ99a], Seite 240 ff). Bei flachen Kontrollflüssen, die meist im Kontextvon Anwendungsfällen modelliert werden, wird die Kontrolle von einem Objekt zumnächsten weitergegeben, während bei prozedualen Kontrollflüssen (Abb. 4.48) die Kon-trolle an den Aufrufer einer Operation zurückgegeben wird.
4.6. INTERAKTIONSDIAGRAMME 176
Object 1 Object 2 Object 3 Object 4
1: 1.1:
1.2:
Abbildung 4.48: Prozedualer Kontrollfluß
Message
*
0..1
*
+activator 0..1 *
*
+predecessor*
*
Abbildung 4.49: Reihenfolge der Botschaften/Stimuli
Die Reihenfolge der Botschaften wird im Metamodell auf die Pseudoattributeprede-cessor (Vorgänger) undactivator (Aktivierer) abgebildet (Abb. 4.49). In Abb. 4.48ist Botschaft 1.1 der Vorgänger von Botschaft 1.2. Der Aktivierer einer Botschaft istdie Botschaft, dessen Empfang zum Senden der Botschaft führt. In Abb. 4.48 aktiviertBotschaft 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 Pfeil-spitze). Ein Operationsaufruf aktiviert eine (verschachtelte) Folge, die durch eine Rück-gabebotschaft (Rückgabe-Aktion) abgeschlossen wird. Die Rückgabebotschaft bzw. dieRückgabe der Kontrolle an den Aufrufer ist implizit vorhanden, auch wenn sie nicht ex-plizit dargestellt wird. Im Falle eines Operationsaufrufs lassen sich auf diese Weise Rück-schlüsse auf die Implementierung der Operation ziehen (zumindest auf die Reihenfolgeweiterer Operationsaufrufe).
Für eine Rückgabebotschaft lassen sich die folgenden Konsistenzbedingungen formu-lieren (vgl. [OMG99], Seite 3-101):
• Inter-9: Eine Rückgabebotschaft setzt eine aktivierende Botschaft voraus.
177 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
• 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, Seite93) und Iterationen (Abb. 4.50) modelliert werden.
Falls ein Interaktionsdiagramm Iterationsausdrücke beinhaltet, kann die Reihenfol-ge 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 Collaboration DiagramChart Filename : colUntitled1.VobChart Type : UML Collaboration Diagram
Object 1 : ArtikelReservierung
b : Bestellung
bpos : BestellPosition
: ArtikelLager
1: reserviere(b)
«parameter»
1.1* [i=1..*]: bpos := gibBestellPosition(i)
«local»
1.1.1: artikel := gibArtikel()
1.1.2: anzahl := gibAnzahl
1.1.3: reserviere(artikel, anzahl)
Abbildung 4.50:Iteration in einem Kollaborationsdiagramm, vgl. [Oes98], Seite 305.Die Botschaft, die die Iteration initiiert, wird um einen Iterationsaus-druck erweitert. Die Sequenznummern der Botschaften innerhalb derIteration besitzen eine Stelle mehr.
Botschaft 1.1 liefert iterativ eine bestimmte Bestellposition, die von den Botschaf-ten in der untergeordneten Ebene benutzt wird. Abbildung 4.51 zeigt die gleiche In-teraktion in einem Sequenzdiagramm inklusive der Sequenznummern. Die Reihenfolgeder Botschaften entsprechend der oben genannten Bedingungen stimmt leider nicht mehr
4.7. ZUSTANDSDIAGRAMME 178Chart Name : ReservierungChart Filename : seqUntitled2.VobChart Type : UML Sequence Diagram
... : ArtikelReservierung b : Bestellung bPos : BestellPosition : ArtikelLager
1: reserviere(b) «parameter»1.1* [i=1..n]: gibBestellPos(i)
bPos
1.1.1: artikel := gibArtikel()
1.1.2: gibMenge()
menge
1.1.3: reserviere(artikel, anzahl) 1.2:
Abbildung 4.51: Interaktion aus Abb. 4.50 in einem Sequenzdiagramm.
mit den Sequenznummern überein. Wenn im Sequenzdiagramm die problematischen Se-quenznummern 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 desMetamodells abgebildet werden müßte. In [Oes98] ist auf Seite 308 die gleiche Situationwie in Abb. 4.50 in einem Sequenzdiagramm modelliert. Im Unterschied zu Abb. 4.51fehlt 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 ge-hört die Iteration nicht mehr zu einer Botschaft, und die zur Iteration gehörenden Bot-schaften sind visuell leicht zu erkennen (Abb. 4.52). Leider ist diese Modellierungsweisenicht in [OMG99] angegeben und läßt sich auch nicht auf ein Metamodellexemplar ab-bilden.
4.7 Zustandsdiagramme
Ein Zustandsdiagramm (Statechart) enthält einen Zustandsautomaten, der aus Zuständen,Transitionen, Ereignissen und Aktionen besteht. Zustandsdiagramme werden zur Mo-dellierung des Verhaltens von Modellelementen eingesetzt. Bei diesen Modellelementenhandelt es sich meistens um Klassen. Die Definition der UML erlaubt jedoch auch, dasVerhalten von anderen Modellelementen (z.B. Operationen) mit Zustandsdiagrammen zumodellieren.
In diesem Abschnitt werden zuerst die elementaren Bestandteile eines Zustandsauto-
179 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
i = 1..n
... : ArtikelReservierung b : Bestellung bpos : Bestellposition : ArtikelLager
reserviere(b)
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 wirderläutert, wie aus diesen Bestandteilen Zustandsautomaten konstruiert werden können.
4.7.1 Ereignisse
Auf Signal, Aufruf-, Zeit- und Änderungsereignisse kann ein Zustandsautomat durchTransitionen und Aktionen reagieren. Entry-, Exit- und Do-Ereignisse sind spezielle,zu einem Zustand gehörende Ereignisse, die nicht zu einer Transition führen. Sie werdenin Abschnitt 4.7.4 behandelt.
Signal- und Aufrufereignisse werden mit der gleichen Syntax in Zustandsdiagrammendargestellt:
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 FormParametername’:’ Typ-Ausdruckdargestellt wird ([OMG99], Seite 3-136).
Ein Signal- oder Aufrufereignis wird auf einSignalEvent bzw. auf einCallEventabgebildet, das mit dem entsprechenden Signal bzw. mit der entsprechenden Operationverbunden ist (Abb. 4.53). Die Parameterliste des Ereignisses wird auf dieParameterdes Ereignisses abgebildet, die im Metamodell als existenzabhängige Teile des Ereignis-ses definiert sind, d.h. die Parameter einer Operation und die Parameter eines Aufruf-Ereignisses sind unterschiedliche Objekte des Metamodellexemplars
Aus Abb. 4.53 lassen sich die folgenden Konsistenzbedingungen für Signal- und
4.7. ZUSTANDSDIAGRAMME 180
TimeEvent
when : TimeExpression
ChangeEvent
changeExpression : BooleanExpression
Operation
CallEvent
1
*
1
+occurrence *
SignalEvent
Signal
*
1
+occurrence *
1
Parameter Event
* 0..1
+parameters
*
{ordered}
0..1
ModelElement
Abbildung 4.53: Ereignisse im Metamodell
Aufruf-Ereignisse ableiten:
• Ereignis-1: Der Name eines Signal- oder Aufrufereignisses muß mit dem Nameneines Signal oder einer Operation übereinstimmen.
Gehört das Ereignis zum Zustandsdiagramm einer Klasse, sollte die Klasse denEmpfang des Signals bzw. die Operation deklariert haben.
• Ereignis-2: Die Anzahl der Parameter eines Signal- oder Aufrufereignisses müs-sen mit der Anzahl der Attribute des Signals bzw. mit der Parameteranzahl derOperation übereinstimmen.
Gehört das Ereignis zum Zustandsdiagramm einer Klasse, dann sollte die Reihen-folge der Parameter des Signals bzw. der Operation mit der Reihenfolge der Para-meter des Ereignisses übereinstimmen.
Bemerkung: Es läßt sich anhand der Notation nicht zwischen Signal- und Aufrufer-eignissen unterscheiden. Wenn das Zustandsdiagramm das Verhalten einer Klasse spe-zifiziert, ist das Signal als Operation mit dem Stereotyp «signal» deklariert (Ereignis-1).Zur Überprüfung der Konsistenzbedingung Ereignis-2 muß dann nicht mehr zwischenSignal- und Aufrufereignissen unterschieden werden. Eine visuelle Unterscheidung zwi-schen Signal- und Aufrufereignis ist nicht unbedingt notwendig, da das empfange Objektden Unterschied „kennt“.
181 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
Ein Zeitereignis wird durch das Schlüsselwortafter, gefolgt von einem Zeitausdruck(TimeExpression) dargestellt, z.B.after (10 sec.), und auf einTimeEvent abgebildet.
Ein Änderungsereignis wird durch das Schlüsselwortwhen, gefolgt von einem boole-schen Ausdruck (ChangeExpression) dargestellt, z.B.when(antwort = 42), und auf einChangeEvent abgebildet.
Im Metamodell ist etwas verwirrend als Attributname für den Zeitausdruck eines Zei-tereignisseswhenangegeben. Ein Ereignis der Artwhen(datum = 1. Jan. 2000) kannzwar als Zeitereignis mit einem absoluten Zeitpunkt interpretiert werden, wird aber ent-sprechend des Schlüsselworts auf ein Änderungsereignis abgebildet (vgl. [OMG99], Seite3-136).
Die Spezifizierung von Zeit- und Änderungsereignissen sollte zum entsprechendenTyp des Ausdruck passen. Da eine Syntax dieser Ausdrücke nicht definiert ist, kanneine derartige Konsistenzbedingung auf der Basis des UML-Metamodells nicht durch einWerkzeug überprüft werden.
Aus dem Metamodell folgt:
• Ereignis-3: Zeit- und Änderungsereignisse dürfen keine Parameter besitzen.
Event
Arguments
Element
Name
Abbildung 4.54:Die KlasseEvent des Rose-Metamodells.Event besitzt keine Opera-tion, die gegebenenfalls eine Operationssignatur o.ä. der Klasse liefert,dessen Verhalten vom Zustandsdiagramm spezifiziert wird.
In Rose wird ein Ereignis auf die KlasseEvent abgebildet (Abb. 4.54). Der Ereignis-name und die Parameter werden in verschiedenen Attributen gespeichert. In Rose wirdnicht zwischen verschiedenen Ereignisarten unterschieden, der Ereignisname ist lediglichein String. Da in Rose ein Zustandsdiagramm immer das Verhalten einer Klasse spezifi-ziert, ist eine Unterscheidung zwischen Signal- und Aufrufereignis nicht notwendig, Zeit-und Änderungsereignisse können anhand der Schlüsselworteafter undwhenvon Signal-und Aufrufereignissen unterschieden werden, falls kein Signal oder eine Operation derKlasse mit dem Namenafter bzw. whenexistiert.
4.7. ZUSTANDSDIAGRAMME 182
4.7.2 Aktionen
Aktionen und Aktivitäten kennzeichnen die Reaktion eines Zustandsautomaten auf einEreignis. Eine Aktion ist eine ausführbare atomare Verarbeitung, typischerweise einOperationsaufruf oder das Senden eines Signals. Eine Aktion kann aber auch ein Aus-druck sein, der Attribute, Links und Parameter eines Ereignisses beinhaltet oder die Er-zeugung/Zerstörung eines Objekts kennzeichnet. Eine Aktion eines Zustandsautomatengehö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 Aufruf-Aktion, eine Sende-Aktion oder eine andere Aktion handelt (siehe Abb. 4.55). Die No-tation des Aktionsausdrucks hängt von der gewählten Sprache für die Aktionsausdrückeab ([OMG99], Seite 3-138). Da eine Aktion immer eine beliebige Aktionsart sein kann,können Konsistenzbedingungen an eine Aktion nur dann identifiziert werden, wenn klarist, um welche Art es sich bei der Aktion handelt:
• Aktion-1: Falls es sich um eine Aufruf-Aktion handelt, wird eine Operation aufeinem Objekt einer Klasse aufgerufen. Diese Klasse sollte die Operation deklarierthaben und sich im Sichtbarkeitsbereich des Eigentümers des Zustandsautomatenbefinden. Diese Bedingung gilt im übertragenden Sinne auch für das Senden einesSignals.
• Aktion-2: Die Anzahl der Parameter eines Operationsaufrufs (eines Signals) solltemit der Deklaration der Operation (des Signals) übereinstimmen.
• Aktion-3: Der Aktionsausdruck sollte nur Merkmale aus dem Sichtbarkeitsbereichdes Eigentümers des Zustandsdiagramms und sprachabhängige Konstrukte beinhal-ten. Hieraus können sich weitere Konsistenzbedingungen ergeben, deren Überprü-fung schwieriger zu realisieren ist.
Ein Werkzeug, welches den Modellierer bei der Erstellung konsistenter Modelle un-terstützt, sollte die Möglichkeit bieten, die Aktionsart einer Aktion zu spezifizieren. Indiesem Fall erkennt das Werkzeug die Semantik einer Aktion und eine Konsistenzprüfungist möglich. Die Überprüfung auf konsistente Aktionen ist wichtig, da die Aktionsaus-drücke häufig Verhaltensmerkmale (Operationen, Signale) anderer Modellelemente be-nutzen, und somit eine Verbindung zu anderen Diagrammen (eventuell Sichten) darstel-len.
4.7.3 Transitionen
Eine Transition (Zustandsübergang) ist eine Beziehung zwischen Zuständen. Eine Transi-tion besitzt mindestens einen Ausgangszustand (source), mindestens einen Folgezustand
183 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
(target), und jeweils optional ein Ereignis, eine Bedingung und eine Aktion (Abb. 4.55).
Ausgangszustand FolgezustandEreignis( Argument )[ Bedingung ] / Aktion
Abbildung 4.55:Notation einer Transition mit Ereignis, Ereignisargumenten, einer Be-dingungung und einer Aktion. Die Art der Aktion ist nicht erkennbar.
Chart Name : New Object DiagramChart Filename : TransitionNotationMetaUML.VobChart Type : UML Object Diagram
: Transition
: State
name = Ausgangszustand
: State
name = Folgezustand
: Guard
expression = Ausdruck
: Operation
name = Aktion
: CallAction
: Event
name = Ereignis
: Parameter
name = Argument
source
outgoing
incoming
target
guard
effecttrigger
Abbildung 4.56:Metamodellexemplar der Transition aus Abb. 4.55. Auf der Metaebeneist erkennbar, daß „Aktion“ eine Operation ist.
Abb. 4.56 zeigt das entsprechende Metamodellexemplar von Abb. 4.55. Alle In-formationen, die zu einer Transition spezifiziert werden können, sind sichtbar und dieSemantik ist klar. Semantisch gibt es sogar noch eine Verbindung von der Operation zueiner Klasse. Ein Werkzeug, welches die Semantik von Aktionen versteht, könnte dieKonsistenzbedingungen aus Abschnitt 4.7.2 Aktionen überprüfen.
Abb. 4.57 zeigt, daß in Rose der Ausgangs- und Folgezustand, das Ereignis, dieBedingung und die Aktion einer Transition spezifiziert werden kann, aber Rose die wei-terreichende Semantik des Ereignisses (siehe 4.7.1) oder der Aktionnicht erkennt.
In früheren UML-Versionen konnte anhand der Notation noch zwischen Sende-Aktio-nen und anderen Aktionen unterschieden werden. Rose unterstützt diese Art der Notation.Die Rose-MetaklasseTransition enthält die OperationGetSendAction, die ein Objekt
4.7. ZUSTANDSDIAGRAMME 184Chart Name : New Object DiagramChart Filename : TransitionNotationMetaRose.VobChart Type : UML Object Diagram : State
Name = Ausgangszustand
: State
Name = Folgezustand
: Transition : Action
name = Aktion
: Event
Name = EreignisArguments = ArgumentGuardCondition = Bedingung
Abbildung 4.57: Interne Darstellung Transition aus Abb. 4.55 in Rose.
der KlasseAction liefert (siehe Abb. 4.10). Zu einer solchen Sende-Aktion werden dieAktion, die Argumente und das Ziel der Aktion auf jeweils eigene Attribute des Aktions-Objekts abgebildet. Dadurch kann die Semantik einer Sende-Aktion genauer spezifiziertwerden.
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 Sei-teneffekten führen.
4.7.4 Zustände
„Ein Zustand ist ein Umstand oder eine Situation im Leben eines Objekts, während dem eseiner 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ändenunterscheidet. Ein Zustand ohne Namen wird „anonymer“ Zustand genannt.
Ein Zustand kann interne Transitionen enthalten. Falls eine interne Transition gefeuertwird, findet kein Zustandsübergang statt. Insbesondere wird der Zustand nicht verlassen,wie dies bei den sogenannten Selbsttransitionen der Fall ist, deren Ausgangs- und Folge-zustand übereinstimmen.
entry, exitund do sind vordefinierte Ereignisse. Das Eintrittsereignis (entry) wirdbeim Eintritt in den Zustand, das Austrittsereignis (exit) wird beim Verlassen des Zustandsausgelöst.dowird fortlaufend ausgelöst, solange der Zustand aktiv ist.
185 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
Die mit einem do-Ereignis verbundene Aktion ist eine Aktivität, d.h. eine nicht-atomare Folge von Aktionen. Eine Aktion kann als Aktionssequenz (MetamodellklasseActionSequence, siehe Abb. 3.34, Seite 85) spezifiziert werden, d.h. ebenso wie eineAktivität aus mehreren Aktionen bestehen. Der Unterschied zwischen eineratomarenAktion und einernicht-atomarenAktivität bezieht sich auf das Laufzeitverhalten des Zu-standsautomaten: eine Aktivität kann durch ein Ereignis unterbrochen werden, währendeine Aktion immer bis zu Ende ausgeführt wird.
Neben den vordefinierten Ereignissen kann ein Zustand benutzerdefinierte Ereignissebeinhalten. Zu jedem dieser Ereignisse kann eine Aktion bzw. eine Aktivität spezifiziertwerden. Abb. 4.58 zeigt die Darstellung eines Zustands mit internen Transitionen.
Zustandsname
exit: Austrittsaktiondo: anhaltendeAktivitäton verzögern: deferentry: Eintrittsereignison Ereignis( Argument )[ Bedingung ]: Aktion
Abbildung 4.58: Notation eines Zustands.
Das entsprechende Metamodellexemplar (Abb. 4.59) ist wesentlich komplexer, da esdie Semantik der Aktionen beinhaltet, die visuell aus Abb. 4.58 nicht zu erfassen sind.
Die Rose-MetaklasseState besitzt die OperationenGetEntryActions, GetExit-Actions, GetDoActions und GetUserDefinedEvents, mit denen die entsprechendenAktionen bzw. Ereignisse ermittelt werden können (siehe Abb. 4.10). Die Art einerAktion kann jedoch nicht ermittelt werden (siehe Abschnitt 4.7.2).
Die Spezifikation der Ereignisse in Zuständen müssen (mindestens) zwei Bedingun-gen 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 nichtdurch eine Bedingung verhindert werden.
Im Metamodell der UML (Abb. 3.47, Seite 109) sind diese Aktionen existenzab-hänge Teile (Komposition) eines Zustands und nicht mit einer Bedingung verbun-den.
In Rose kann die KonsistenzbedingungEreignis-5nicht verletzt werden. Eine Verlet-zung der BedingungEreignis-4wird nicht entdeckt, es können sogar die vordefiniertenEreignisse mehrfach spezifiziert werden.
4.7. ZUSTANDSDIAGRAMME 186
Chart Name : New Object DiagramChart Filename : objUntitled2.VobChart Type : UML Object Diagram
nicht näher spezifizierte Aktivität
: SimpleState
name = Zustandsname
: CallAction : Operation
name = Eintrittsaktion
: SendAction : Signal
name = Austrittsaktion
: Action
: CallEvent
: Operation
name = verzögern
: Transition
: CallEvent
Operation
name = Ereignis
: Parameter
name = Argument
: Guard
expression = Bedingung : CallEvent
: Operation
name = Aktion
entry
exit
doActivity
deferableEvent
internal
trigger guard effect
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 Zustands-automat besteht aus einem Top-Level-Zustand, der weitere Zustände enthalten kann. DerTop-Level-Zustand wird nicht im Zustandsdiagramm dargestellt. Die im Top-Level-Zu-stand enthaltenden Zustände können Kompositionszustände, die wiederum Kompositi-onszustände enthalten können, oder „einfache“ Zustände sein, die keine weiteren Zustän-de enthalten. Ein Kompositionszustand kann Anfangs- und Endzustände sowie weiterePseudozustände, z.B. flache und tiefe Erinnerungszustände beinhalten.
Ein Kompositionszustand repräsentiert einen Zustandsautomaten innerhalb eines Zu-standsautomaten. Z.B. enthält der KompositionszustandB-Ebene1in Abb. 4.61 einenAnfangs-, einen End- und den KompositionszustandC-Ebene2, der wiederum weitereZustände enthält. Auf diese Weise können nicht nur flache Zustandsautomaten konstruiertwerden, sondern auch Zustandsautomaten, deren Zustände sich auf mehreren Ebenen be-finden. 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, mo-delliert werden (Abb. 4.61).
Das Metamodellexemplar von Abb. 4.61 ist zu komplex, so daß es hier ausgespartwird. Diese Art von Zustandsautomaten kann mit Rose modelliert werden. Die Rose-
187 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
StateMachine
State
1..1
0..1
+top 1..1
CompositeState
0..1
0..*
0..1
+container
0..1
0..*
Abbildung 4.60:Rekursiver Aufbau eines Zustandsautomaten (vereinfachte Darstellung,siehe auch 3.47, Seite 109)
.
A-Ebene1
B-Ebene1
C-Ebene2
D-Ebene3
E-Ebene3
C-Ebene2
D-Ebene3
E-Ebene3
D-Ebene3
E-Ebene3
Abbildung 4.61:Beispiel eines Zustandsautomaten mit mehreren verschachtelten(Kompositions-) Zuständen (B und C).
4.7. ZUSTANDSDIAGRAMME 188
MetaklasseState (Abb. 4.10, Seite 141) besitzt die AttributeSubstates undStateKind,die die Unterzustände eines Zustands bzw. die Art des Zustands (Start-, Endzustand odernormaler 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 sindin [OMG99], Seite 2-135 ff, mehrere Konsistenzbedingungen definiert:
• Zustandsautomat-1: Ein Zustandsautomat gehört entweder zu einem Klassifizie-rer oder einem Verhaltensmerkmal.
• Zustandsautomat-2:Wenn ein Zustandsautomat ein Verhaltensmerkmal beschreibt,kann er keine Ereignistrigger vom Typ Aufruf-Ereignis besitzen. Ausgenommenist der Ereignistrigger der ausgehenden Transition des Anfangszustands des Top-Level-Zustands.
• Zustandsautomat-3:Ein Top-Level-Zustand ist immer ein Kompositionszustand.
• Zustandsautomat-4: Ein Top-Level-Zustand kann kein Ausgangszustand einerTransition sein.
• Zustand-1: Ein Kompositionszustand kann maximal einen Anfangszustand besit-zen.
• Zustand-2: Ein Kompositionszustand kann maximal einen flachen oder tiefen Er-innerungszustand besitzen.
• Transition-2: Ein Anfangszustand kann maximal eine ausgehende Transition be-sitzen.
• 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 Transitionbesitzen.
• Transition-6: Transitionen, die von Pseudozuständen (z.B. Anfangs- und Erinne-rungszuständen, siehe Abschnitt 3.2.3) ausgehen, dürfen keine Ereignistrigger be-sitzen. Ausnahme: Die ausgehende Transition des Anfangszustands des Top-Level-Zustands.
• Transition-7: Die ausgehende Transition des Anfangszustands des Top-Level-Zu-stands kann einen Ereignistrigger mit dem Stereotyp «create» besitzen. Falls derZustandsautomat ein Verhaltensmerkmal spezifiziert, kann diese Transition ein Auf-ruf-Ereignis besitzen.
189 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
• Transition-8: Der Folgezustand eines Erinnerungszustands sollte sich im gleichenKompositionszustand befinden6.
In Rose gehört ein Zustandsdiagramm immer zu genau einer Klasse. Top-Level-Zustände können in Rose nicht explizit modelliert werden und werden auch nicht ange-zeigt. In Rose ist der Top-Level-Zustand der Zustandsautomat (Rose-MetaklasseState-machine) selbst. In Rose kann ein Kompositionszustand nur einen Anfangszustand ent-halten, der keine eingehenden Transitionen besitzen kann. Die Modellierung von einemEndzustand ausgehender Transitionen ist ebenfalls nicht möglich. Bei der Spezifikationvon Transitionen wird in Rose nicht weiter zwischen Zuständen und Pseudozuständen un-terschieden: Eine Transition kann immer einen Ereignistrigger, eine Bedingung und eineAktion besitzen, und Ausgangs- und Folgezustände können sich in beliebigen Ebenen desZustandsautomaten befinden.
Ein nebenläufiger Kompositionszustand kann zwei oder mehrere Kompositionszu-stände, genannt Bereiche oder Regionen, besitzen (siehe Abb. 4.62). Diese Bereiche sindwieder Kompositionszustände. Zustandsautomaten mit nebenläufigen Bereichen könnenmit Rose nicht modelliert werden. Diese gilt auch für die weiteren in diesem Abschnittvorgestellten Arten von Zustandsautomaten.
UML V1.3 beta R5 May 1999 3�
-135
3.77 Events
Figure 3-63 Concurrent Substates
3�
.76.4 Mapping
A state sym�
bol maps into a S tate. I f the sy mbol has no subdiagrams 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 �
i�sConcurrent value true; otherwise, it maps into a CompositeState with the i
�sConcurrent
valu� e false.
An �
initial pseudostate symbol map into a Pseudostate of kind in�
itial. A �
final state s ymbol maps to a �
fin�
al state.�
3
.77 Events
3�
.77.1 Semantics
An event is a noteworthy occurrence. For practical purposes in state diagrams, it is an occurre nce that may trigger a s tate transition. Events may be of severa l kinds (no t necessarily m� utually exclusive).
Lab1 Lab2
Ter�
m
lab done
pr oject done
Passed
Incomplete
Project
Final pa ss
Test
Failedfail
lab done
T�
aking Class
Abbildung 4.62:Nebenläufiger Kompositionszustand (Incomplete) mit drei Bereichen.(Entnommen aus [OMG99], Seite 3-135)
6Nicht explizit in [OMG99] gefordert.
4.7. ZUSTANDSDIAGRAMME 190
Für nebenläufige Kompositionszustände sind in [OMG99], Seite 2-135 ff, die folgen-den Konsistenzbedingungen definiert:
• Zustand-3: Ein nebenläufiger Kompositionszustand muß mindestens zwei Kom-positionszustände (Bereiche) besitzen.
• Zustand-4: Ein nebenläufiger Kompositionszustand kann nur Kompositionszu-stände als direkte Unterzustände enthalten.
Mehrere Transitionen in nebenläufige Bereiche hinein oder aus ihnen heraus, könnenmit den Pseudozuständenfork und join modelliert werden (Abb. 4.63). Diese Transitio-nen werden auchnebenläufige(concurrent) Transitionen genannt.
3-140 UML V1.3 beta R5 May 1999
3 UML Notation
3.79.3 Example
Figure 3-65 Concurrent Transitions
3.79.4 Mapping
A bar with multiple transition arrows leaving it maps into a fork pseudostate. A bar with m� ultiple transition arrows entering it maps into a join pseudostate. The transitions co� rresponding to the incoming and outgoing arrows attach to the pseudostate as if it were a regular state. If a bar has multiple incoming and multiple outgoing arrows, then it maps into a join
� connected to a fork pseudostate by a single transition with no attachments.
3.�
80 Transitions to and from Composite States
3.80.1 Semantics
A �
transition drawn to the boundary of a composite state is equivalent to a transition to its initial p� oint (or to a complex transition to the initial point of each of its concurrent regions, if it is co� ncurrent). The entry action is always performed when a state is entered from outside.
A transition from a composite state indicates a transition that applies to each of the states within the s�
tate region (at any depth). It is “inherited” by the nested states. Inherited transitions can be m� asked by the presence of nested transitions with the same trigger.
3.80.2 Notation
A transition drawn to a composite state boundary indicates a transition to the composite state. This is eq�
uivalent to a transition to the initial pseudostate within the composite state region. The initial p�
seudostate must be present. If the state is a concurrent composite state, then the tr�
ansition indicates a transition to the initial pseudostate of each of its concurrent substates.
Transitions may be drawn directly to states within a composite state region at any nesting dep�
th. All entry actions are performed for any states that are entered on any transition. On a tr�
ansition within a concurrent composite state, transition arrows from the synchronization bar may be drawn to one or more concurrent states. Any other concurrent regions start with their defa�
ult initial p seudostate.
Process
Se
tup C
leanup
A1�
A2
B2B1
Abbildung 4.63:Die senkrechten Balken werden auf die Pseudozuständefork und joinabgebildet. Sie dienen der Synchronisation von nebenläufigen Berei-chen. Die von einem Synchronisationsbalken ausgehenden Transitionenwerden erst gefeuert, wenn alle eingehenden Transitionen ausgeführtwurden. (Entnommen aus [OMG99], Seite 3-140)
Für diese Pseudozustände und nebenläufigen Transitionen sind weitere Konsistenzbe-dingungen definiert ([OMG99], Seite 2-136 ff):
• Zustand-5: Ein fork-Pseudozustand muß mindestens zwei ausgehende und genaueine eingehende Transition besitzen.
• Zustand-6: Ein join-Pseudozustand muß mindestens zwei eingehende und genaueine ausgehende Transition besitzen.
• Transition-9: Eine von einem fork-Pseudozustand ausgehende Transition darf kei-nen Ereignistrigger und keine Bedingung enthalten.
• Transition-10: Eine in einem join-Pseudozustand eingehende Transition darf kei-nen Ereignistrigger und keine Bedingung enthalten.
• Transition-11: Der Ausgangszustand einer in einen join-Pseudozustand eingehen-den Transition darf kein Pseudozustand sein.
191 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
• Transition-12: Der Folgezustand eines fork-Pseudozustands darf kein Pseudozu-stand sein.
• Transition-13: Der Ausgangszustand einer in einen join-Pseudozustand eingehen-den Transition muß ein Unterzustand eines nebenläufigen Kompositionszustandssein, d.h. es muß ein Zustand eines Bereichs sein.
• Transition-14: Die Folgezustände eines fork-Pseudozustands müssen Unterzustän-de eines nebenläufigen Kompositionszustands sein.
Nebenläufige Bereiche eines Kompositionszustands können mit Synchronisations-pseudozuständen synchronisiert werden. Das Feuern ausgehender Transitionen einesSynchronisationszustands kann durch die Angabe einer Grenze beschränkt werden. DieGrenze ist die Differenz zwischen der Häufigkeit des Feuerns ein- und ausgehender Tran-sitionen des Synchronisationszustands (siehe Abb. 4.64). Für Synchronisationszustände
UML V1.3 beta R5 May 1999 3�
-147
3.83 Synch States
3�
.83 Synch States
3�
.83.1 Semantics
A synch state is for synchronizing concurrent regions of a state machine. It is used in co� njunction with f orks and joins to insure that one region leaves a p articular state o r states b�
efore another region can enter a particular state o r states. T he firing of outgoing transitions from a synch state can be limited by specifying a bound on the difference between the number of tim� es outgoing and incoming transitio ns have fir ed.
3�
.83.2 Notation
A�
synch sta te is sh own as a small c ircle with the upper bound inside it. The bound is e ither a po� sitive in teger or a star ( ’*’) for un limited. Sy nch states are drawn o n the b oundary between tw�
o regions when possible.
3�
.83.3 Example
Figure 3-71 Synch states
Build
InstallElectricity
Build House
InspectInstall
Foundation
Frame
In Foundation
InstallElectricityIn Frame
Put OnRoof
InstallElectricityOuts
ide
InstallWalls
**
Abbildung 4.64:Synchronisation von nebenläufigen Bereichen eines Synchronisations-zustands mit Synchronisationszuständen (*). Der Stern kennzeichnetden Wertunlimitedfür die Grenze des Synchronisationszustands. (Ent-nommen aus [OMG99], Seite 3-147)
sind zwei Konsistenzbedingungen zu beachten ([OMG99], Seite 2-137):
• Zustand-7: Der Wert der Grenze eines Synchronisationszustands muß ein positiverInteger oderunlimitedsein.
• Transition-15: Alle eingehenden Transitionen in einen Synchronisationszustandmüssen aus einem einzigen Bereich kommen, alle ausgehenden Transitionen müs-sen ihr Ziel in einem einzigen Bereich haben.
4.7. ZUSTANDSDIAGRAMME 192
Die Darstellung des Inhalts verschachtelter Kompositionszustände kann unterdrücktwerden. Transitionen in solche Zustände hinein können mit Stummel-Pseudozuständendargestellt werden (siehe Abb. 4.65). Für Stummelzustände sind in [OMG99] keineKonsistenzbedingungen formuliert.
3-142 UML V1.3 beta R5 May 1999
3 UML Notation
Figure 3-66 Stubbed Transitions
Figure 3-67 History Indicator
3.80.5 Mapping
An arr�
ow to any state bo undary, nested or no t, maps into a Transition between the corr� esponding States and similarly for tr ansitions direct ly to h istory states.
A history indicator maps into a Pseudostate of kind s� hallowHistory or� de�
epHistory.
A C�
A C�
BD
E
F
p s�
t�
B
r
p
r
D
W�
W�
may be abstracted as
u
s�
s�
A
C�
H
A1
A2
interrupt
resume
Abbildung 4.65:Details innerhalb von Kompositionszuständen können unterdrückt wer-den. Transitionen in Zustände hinein und aus Zuständen heraus wer-den mit Hilfe von Stummelzuständen dargestellt. (Entnommen aus[OMG99], Seite 3-142)
Mit junction-Pseudozuständen können komplexe Transitionspfade modelliert werden(Abb. 4.66). Sie können mehrere eingehende und ausgehende Transitionen besitzen, mitdenen einestatisch bedingte Verzweigungmodelliert werden kann.
Mit choice-Pseudozuständen könnendynamisch bedingte Verzweigungenmodelliertwerden. In Abb. 4.67 wird der Wert vona zur (gedachten) Laufzeit des Automatenbestimmt.
Für junction- und choice-Pseudozustände sind in [OMG99] weitere Konsistenzbedin-gungen definiert:
• Zustand-7: Junction- und choice-Pseudozustände müßen mindestens eine einge-hende und eine ausgehende Transition besitzen ([OMG99], Seite 2-136).
• Zustand-8: Nur eine Transition von einem junction- oder choice-Pseudozustandausgehende Transition darf die vordefinierte Bedingungelsebesitzen ([OMG99],Seite 2-130).
193 KAPITEL 4. WERKZEUGUNTERSTÜTZUNG UND KONSISTENZ
3-144 UML V1.3 beta R5 May 1999
3 UML Notation
3.81.3 Examples
I�n Figure 3-68 a sin gle junction point is u sed to merge and split transitions. Reg ardless of
wh� ether the junction point was rea ched from state S tate0 or from state S tate1, the o utgoing p� aths ar e the same f or both cases.
If the state machine in this example is in state State1 and b is less than 0 when event e1 occurs, the o�
utgoing 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.
Figure 3-68 Junction points
In the dynamic choice point example in Figure 3-69, the decision on which branch to take is o� nly made after the transition from State1 is taken and the choice point is reached. Note that the ac� tion associated with that incoming transition computes a new value for a. This new value c an 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.
Figure 3-69 Dynamic choice points
[a < 0]
St�
ate1
St�
ate2 S�
tate3 St�
ate4
e1 [b < 0]e2 [b < 0]
St�
ate0
[a = 5]
[a > 7]
[a < 0]
S�
tate1
St�
ate2 S�
tate3 St�
ate4
e1[ b < 0]/a := f(m)
[a = 5]
[else]
Abbildung 4.66: Junction-Pseudozustand (Entnommen aus [OMG99], Seite 3-144)
3-144 UML V1.3 beta R5 May 1999
3 UML Notation
3.81.3 Examples
I�n Figure 3-68 a sin gle junction point is u sed to merge and split transitions. Reg ardless of
wh� ether the junction point was rea ched from state S tate0 or from state S tate1, the o utgoing p� aths ar e the same f or both cases.
If the state machine in this example is in state State1 and b is less than 0 when event e1 occurs, the o�
utgoing 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.
Figure 3-68 Junction points
In the dynamic choice point example in Figure 3-69, the decision on which branch to take is o� nly made after the transition from State1 is taken and the choice point is reached. Note that the ac� tion associated with that incoming transition computes a new value for a. This new value c an 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.
Figure 3-69 Dynamic choice points
[a < 0]
St�
ate1
St�
ate2 S�
tate3 St�
ate4
e1 [b < 0]e2 [b < 0]
St�
ate0
[a = 5]
[a > 7]
[a < 0]
S�
tate1
St�
ate2 S�
tate3 St�
ate4
e1[ b < 0]/a := f(m)
[a = 5]
[else]
Abbildung 4.67: Choice-Pseudozustand (Entnommen aus [OMG99], Seite 3-144)
4.7. ZUSTANDSDIAGRAMME 194
Ein Zustandsautomat kann Transitionen zu anderen, irgendwo spezifizierten Zustands-automaten besitzen. Dieser wirdreferenzierterZustandsautomat genannt. Die Zustän-de des referenzierten Zustandsautomaten werden als Stummelzustände dargestellt (sieheAbb. 4.68) und auf die MetamodellklasseSubmachineState (Unterautomatenzustand)abgebildet.
3-146 UML V1.3 beta R5 May 1999
3 UML Notation
3.82.3 Example
Th�
e following diagram shows a fragment from a statechart diagram in which a submachine (the FailureSubmachine) is invoked in a particular way. The actual submachine is presumably defined elsewh�
ere and is not shown in this diagram. Note that the same submachine could be in�
voked elsewhere in the same statechart diagram with dif ferent entry and exit configurations.
Figure 3-70 Submachine State
In the above example, the transition triggered by event “error1” will terminate on state “sub1” o� f the FailureSubmachine state machine. Since the entry point does not contain a path name, this m�
eans that “sub1” is defined at the top level of that submachine. In contrast, the transition tr�
iggered by “error2” will ter minate on the “sub12” substate of the “sub1”substate (as indicated by�
the path name), while the “error3” transition implies taking of the default transition of the FailureSub�
machine.
The tr�
ansition triggered by the event “f ixed1” emanates from the “subEnd” substate of the su� bmachine. Finally, the transition emanating from the edge of the submachine state is taken as a r� esult of the completion event generated when the FailureSubmachine reaches its final state.
3.82.4 Mapping
A su
bmachine state in a statechart diagram maps directly to a SubmachineState in the 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 m�
etamodel. The label on the diagram corresponds to the pathname represented by the “referenceState” attribute of the stub state.
Handle Failure
include / FailureSubmachine
su b1 su b1::sub12
s ubEnd
e� rror2/e� rror1/
e� rror3/
fixed1/
Abbildung 4.68:Der UnterautomatenzustandHandle Failureenthält den Zustandsauto-matenFailureSubmachine. (Entnommen aus [OMG99], Seite 3-146)
Für referenzierte Zustandsautomaten sind weitere Konsistenzbedingungen definiert([OMG99], Seite 2-137):
• Unterautomatenzustand-1: Ein Unterautomatenzustand (nicht der referenzierteZustandsautomat!) darf nur Stummelzustände enthalten.
• Unterautomatenzustand-2: Ein Unterautomatenzustand darf kein nebenläufigerKompositionszustand sein.
Kapitel 5
Konzept einer Benutzerschnittstelle zurKonsistenzprü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 Skriptemüssen auf Benutzeranforderung gestartet werden. Sie können eine graphische Benutzer-schnittstelle enthalten, so daß der Benutzer den Ablauf der Skripte steuern kann.
Die Skripte können nicht ereignisgesteuert gestartet werden, so daß keine Mechanis-men, mit denen Inkonsistenzen vermieden werden können oder Mechanismen, die derUnterstützung zum Modellierungszeitpunkt dienen, realisiert werden können. Ein Skriptmuß immer beendet werden, d.h. es ist nicht möglich ein Skript anzuhalten, dann Verän-derungen am Modell vorzunehmen und danach das Skript fortzusetzen.
In Abschnitt 5.1 werden die in Rose-Script zur Verfügung stehenden Möglichkeitenzur Überprüfung von Konsistenzbedingungen und zur Realisierung einer graphischen Be-nutzerschnittstelle kurz vorgestellt. In Abschnitt 5.2 wird erläutert, nach welchen Kriteri-en 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 spezi-fiziert, zugegriffen werden. Diese Informationen sind in den Objekten der Klassen desWerkzeugmetamodells von Rose (Abschnitt 4.4) vorhanden. Die Möglichkeiten vonRose-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 wer-den, wie es auch ein Modellierer in Rose könnte. Daher können neben der reinen Prüfungauch Korrekturen am UML-Modell vorgenommen werden. Das Rose-Metamodell kannallerdings nicht erweitert werden.
Ein lauffähiges Skript besteht aus einer ausgezeichneten Unterroutine (main). EinSkript kann weitere, benutzerdefinierte Unterroutinen und Funktionen beinhalten, an die
195
5.1. MÖGLICHKEITEN VON ROSE-SCRIPT 196
Argumente perCall-By-ReferenceoderCall-By-Valueübergeben werden können. Skriptekönnen andere lauffähige Skripte starten und andere Skripte, die nicht notwendigerweiseeine main-Routine besitzen müssen, in den Speicher laden und den enthaltenen Codebenutzen.
In Rose können u.a. die folgenden Datentypen zur Deklaration von Variablen benutztwerden:
• Any : beliebiger, nicht näher spezifizierter Datentyp,
• Date : Datum und Uhrzeit,
• Variant : Datentyp, der verschiedene Datentypen enthalten kann,
• die StandarddatentypenBoolean, Double, Single, Integer undString,
• die Klassen des Rose-Metamodells (z.B.Class, RoseItem),
• Sammlungen (Collections), die mehrere Objekte einer Rose-Metamodellklasse ent-halten (z.B.ClassCollection, RoseItemCollection) und
• Arrays mit statischer oder dynamischer Größe.
Benutzerdefinierte Datentypen können nur in Form von statischen Arrays deklariertwerden. Es ist nicht möglich, neue Klassen mit Attributen und Operationen zu definieren.
Routinen, Funktionen und Variablen können als Public, Private oder Global deklariertwerden. 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 Rechnersund betriebssystemabhängige Eigenschaften ermittelt werden können. Dies ist wichtig,da nicht alle Möglichkeiten von Rose-Script auf jeder Plattform verfügbar sind. Diesbetrifft insbesondere die Möglichkeiten der graphischen Benutzerschnittstelle, die nur aufWindows32-Plattformen vollständig genutzt werden können.
Die graphische Benutzerschnittstelle in Form eines Dialogs kann die folgenden Ele-mente 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ög-lichkeiten
• Drop-Down-Listen und Listen zur Selektion einer Option aus mehreren Möglich-keiten, 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. EinDialog kann eine Dialogfunktion besitzen, deren Parameter allerdings fest vorgegebensind. Die Dialogfunktion wird ausgeführt, wenn der Benutzer z.B. eine Check-Box ak-tiviert oder einen Radio-Button selektiert. Auf diese Weise kann der Dialoginhalt in ei-nem geringen Umfang dynamisch verändert werden. Die Dialogfunktion wird vorrangigdazu genutzt, Dialogelemente in Abhängigkeit von anderen Dialogelementen zu aktivie-ren/deaktiveren oder zu verstecken bzw. sichtbar zu machen. Werden Arrays, die den In-halt für Drop-Down-Listen liefern, durch die Dialogfunktion verändert, so hat dies keinenEinfluß auf den Dialog. Die Veränderung wird erst sichtbar, wenn der Dialog nochmalsgeö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-Modellseiner realen Systementwicklung ist zeitaufwendig und führt, besonders in einem frühenEntwicklungsstadium, meistens zu vielen Inkonsistenzmeldungen, die den Modellierernicht interessieren. Die interessante Information verschwindet in der Masse. Daher mußdem Benutzer die Möglichkeit gegeben werden, nur die für ihn zu einem bestimmtenZeitpunkt interessanten Konsistenzprüfungen durchführen zu lassen.
Betrachtet man denEntwicklungszeitraum, von der Konzeption bis zur Implementie-rung, so gibt es Konsistenzbedingungen, deren Überprüfung erst zu einem späteren Ent-wicklungszeitpunkt interessant werden. Die Konsistenzbedingungen lassen sich abhängigvom 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 Spezi-fikation des Modells, sondern durch eine fehlerhafte Spezifikation verletzt werden.
2. Konsistenzbedingungen, die auf Grund einer unvollständigen Spezifikation verletztwerden. Ob die Überprüfung dieser Konsistenzbedingungen für den Modellierer in-teressante Informationen liefern kann, hängt vom Entwicklungszeitpunkt und vomgewünschten formalen Spezifikationsgrad ab.
Die meisten Konsistenzbedingungen lassen sich einemModellelementund damit mei-stens auch einerDiagrammartzuordnen. Somit können Konsistenzbedingungen nachDiagrammen geordnet werden.
Es gibt Konsistenzbedingungen, deren Verletzungautomatisch korrigiertwerden kann.Dies sind vorrangig Konsistenzbedingungen, die die Existenz anderer Modellelementefordern. Das Merkmal einer vorhandenen bzw. nicht vorhandenen Korrekturmöglichkeitist ein weiteres Unterscheidungsmerkmal.
Da es nicht immer gewünscht ist das ganze Modell auf die Einhaltung von Konsi-stenzbedingungen zu prüfen, sollte es möglich sein, nur bestimmte Bereiche des Modellszu überprüfen.
5.3. KONZEPT DER BENUTZERSCHNITTSTELLE 198
5.3 Konzept der Benutzerschnittstelle
Die obigen Überlegungen führten zu dem folgenden Konzept, welches auch umgesetztwurde (siehe Abb. 5.1):
1. Die Auswahl der Konsistenzprüfungen erfolgt diagrammorientiert. Dazu wird überdie Menüleiste eine Diagrammart ausgewählt.
2. Die Konsistenzprüfungen werden nach dem Entwicklungszeitpunkt (siehe Abschnitt5.2) geordnet.
Wenn zuviele Konsistenzprüfungen im Kontext eines Diagramms existieren, wer-den diese auf mehrere Auswahldialoge verteilt.
3. Der Umfang der zu überprüfenden Modellelemente kann nach verschiedenen Kri-terien gewählt werden:
(a) Paketorientiert: Es kann das gesamte Modell oder ein bestimmtes Paket inklu-sive aller enthaltenen Pakete zur Überprüfung gewählt werden.
(b) Diagrammorientiert: Entsprechend der ausgewählten Diagrammart könnenentweder alle Diagramme oder nur ein bestimmtes Diagramm dieser Art aus-gewählt werden.
(c) Benutzerorientiert: Sind vom Benutzervor dem Öffnen des AuswahldialogsModellelemente selektiert worden, können entweder alle selektierten Modell-elemente oder genau eines der selektierten Modellelemente gewählt werden.
Die Überprüfung findet auf der Basis des Werkzeugmetamodells statt. Die Auswahlbestimmt 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 Inkonsistenzentdeckt wird, wird dem Benutzer ein Dialog mit den folgenden Informationen an-gezeigt (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 verant-wortlich 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 vorhan-den, die für die Inkonsistenz vorantwortlich sind. Die Auswahl eines dieser
199 KAPITEL 5. BENUTZERSCHNITTSTELLE ZUR KONSISTENZPRÜFUNG
Abbildung 5.1:Auswahldialog der Konsistenzprüfungen („grundsätzliche Fehler“) inKlassendiagrammen
201 KAPITEL 5. BENUTZERSCHNITTSTELLE ZUR KONSISTENZPRÜFUNG
Modellelemente zeigt (unter dem Dialog) ein Diagramm an, in dem das Mo-dellelement vorkommt. Auf diese Weise kann sich der Modellierer ein „Bildvon der Inkonsistenz verschaffen“.
(b) Der Button „Spezifikation öffnen“ beendet die Konsistenzprüfung und öffnetdas Spezifikationsfenster des in der Drop-Down-Liste angegebenen Elements.
(c) Handelt es sich um eine Konsistenzprüfung, deren Verletzung automatischkorrigiert werden kann, wird ein Button „Autokorrektur“ und ein Text ange-zeigt. 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 Interaktions-möglichkeit fort.
(f) Der Button „Abbruch“ bricht die Überprüfungen ab.
6. Die Prüfungsmeldungen werden in die Standardausgabe (Unix) oder in ein spe-zielles Fenster (Windows) geschrieben. Bei nicht interaktiver Prüfung wird eineautomatische Korrektur nur durchgeführt, wenn im Dialog die Autokorrektur aus-gewählt wurde.
Anhang A
Realisierung der Benutzerschnittstelle
Die Benutzerschnittstelle ist durch mehrere Skripte realisiert: Jeder Auswahldialog undjede Konsistenzprüfung befindet sich in einem eigenen Skript. Verschiedene Hilfsfunk-tionen (Seite 203) sind ebenfalls in einzelne Skripte ausgelagert.
Der Aufbau der Skripte wird in den beiden nächsten Abschnitten kurz erläutert. Dierestlichen Abschnitte geben eine Übersicht über die entwickelten Skripte und beschreibendie 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 jedemSkript vorhanden sein. Die Dialogvorlage besitzt mehrere Variablen, die von derRoutine, 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 Beseitigungder Inkonsistenz.
(c) AutokorrekturMöglich (Boolean): gibt an, ob der Button zur Autokorrekturinklusive Beschreibung im Dialog sichtbar sein soll.
(d) AutokorrekturText (String): beschreibt die von der Autokorrektur durch-gefü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 zurDialogvorlage, enthält die Objekte (Modellelemente), deren Diagramme an-gezeigt werden können.
202
203 ANHANG A. REALISIERUNG DER BENUTZERSCHNITTSTELLE
(g) InkonsistenzText (String): wird zur Ausgabe eines Textes, der die Inkon-sistenz und die beteiligten Modellelemente beinhaltet, genutzt.
2. Dialogfunktion: Die Dialogfunktion ruft u.a. eine Routine auf, die ein Diagrammanzeigt, in welchem das im Inkonsistenzdialog ausgewählte Modellelement vor-handen ist. Realisiert ist lediglich eine Routine, die ein Klassendiagramm anzeigt.Für Konsistenzprüfungen im Kontext anderer Diagrammarten müßte diese Routineentsprechend angepaßt werden.
3. Prüfungsroutine: Der erste Parameter einer Prüfungroutine ist immer von einemTyp der ArtCollection (z.B.ClassCollection oderAssociationCollection).Dies ist die Sammlung von Modellelementen, die iterativ von der Prüfungsroutinebearbeitet werden.
Weitere Parameter sindEinzel undAbbruch (beide Boolean, Call-By-Reference)und, falls die Prüfung eine automatische Korrektur beinhaltet,Auto (Boolean). DiePrüfungsroutine kann auch Unterroutinen beinhalten.
A.2 Das Skript eines Auswahldialogs
Das Skript eines Auswahldialogs besteht neben der Dialogvorlage und der Dialogfunktionaus mehreren Routinen, die auf Basis der ausgewählten Modellelemente und Konsistenz-prüfungen eine Sammlungen (Collection) entsprechend der Parameter der Prüfungsrouti-nen erzeugen (z.B.CreateClassCollection, CreateAssociationCollection).
Die Prüfungsroutinen werden dynamisch zur Laufzeit in den Speicher geladen undauch wieder aus dem Speicher entfernt, da das Laden mehrerer Skripe zu einem Zeitpunktzu einer spürbar längeren Antwortzeit führt.
A.3 Entwickelte Skripte
A.3.1 Hilfsfunktionen
Function HasAttributeType(anAttribute As Attribute) As VariantAufgabe: liefert True, falls anAttribute einen Typ (Type) besitztDatei: Function_HasAttributeType.ebs
Function HasSameSignatur(op1 As Operation, op2 As Operation) As VariantAufgabe: liefert True, falls die beiden Operationen die gleiche Signatur besitztenDatei: Function_HasSameSignature.ebs
A.3. ENTWICKELTE SKRIPTE 204
Function ExistsOperationSignatureInClass(theClass As Class, theOperation As Operation) As VariantAufgabe: Überprüft, ob die Signatur der Operation in der Klasse existiertDatei: Function_ExistsOperationSignatureInClass.ebs
Function ExistsOperationSignatureInSuperclasses(theClass As Class, theOperation As Operation) As VariantAufgabe: Überprüft, ob die Signatur der Operation in einer Oberklasse der Klasse exi-stiert.Datei: Function_ExistsOperationSignaturInSuperclasses.ebs
Function IsAssociationNavigable(anAssociation As Association) As VariantAufgabe: liefert True, falls ein Assoziationsende navigierbar ist.Datei: Function_IsAssociationNavigable.ebs
Function IsInterface (theClass As Class) As VariantAufgabe: 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,Einzel As Boolean, Abbruch As Boolean)Aufgabe: Überprüft, ob die Operationssignaturen der Klassen eindeutig sind (Operation-1).Datei: Sub_KP_UniqueOpSignatures.ebs
Sub KP_UniqueParaNames (Classes As ClassCollection,Einzel As Boolean, Abbruch As Boolean)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,Einzel As Boolean, Abbruch As Boolean)
205 ANHANG A. REALISIERUNG DER BENUTZERSCHNITTSTELLE
Aufgabe: Überprüft, ob die Assoziationsenden, die eine Komposition kennzeichnen, einemaximale Kardinalität von 1 besitzen (Komposition-1).Datei: Sub_KP_CheckCompositionCardinality.ebs
Sub KP_CheckGeneralization (Generalizations As InheritRelationCollection,Einzel As Boolean, Abbruch As Boolean)Aufgabe: Überprüft, ob die Generalisierungsbeziehungen zwischen Klassifizierern dergleichen 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 alsMerkmale besitzen (Interface-1).Datei: Sub_KP_InterfaceOperationsOnly.ebs
Sub KP_InterfaceNoContents (Classes As ClassCollection,Einzel As Boolean, Auto As Boolean, Abbruch As Boolean)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,Einzel As Boolean, Auto As Boolean, Abbruch As Boolean)Aufgabe: Überprüft, ob die Klassen mit dem Stereotyp «Interface» ein gegenüberliegen-des, navigierbares Assoziationsende besitzen (Interface-7).Datei: Sub_KP_InterfaceAssoziation.ebs
Sub KP_InterfaceHasOperation (Classes As ClassCollection,Einzel As Boolean, Abbruch As Boolean)Aufgabe: Überprüft, ob die Klassen mit dem Stereotyp «Interface» Operationen dekla-rieren (Interface-5).Datei: Sub_KP_InterfaceHasOperation.ebs
Sub KP_InterfaceHierarchie (Classes As ClassCollection,Einzel As Boolean, Abbruch As Boolean)Aufgabe: Überprüft, ob die Klassen mit dem Stereotyp «Interface» eindeutige Operati-onssignaturen in der Klassenhierarchie besitzen (Interface-6).Datei: Sub_KP_InterfaceHierarchie.ebs
Sub KP_InterfacePublicOperations (Classes As ClassCollection,
A.3. ENTWICKELTE SKRIPTE 206
Einzel As Boolean, Auto As Boolean, Abbruch As Boolean)Aufgabe: Überprüft, ob die Klassen mit dem Stereotyp «Interface» nur öffentliche, ab-strakte Operationssignaturen besitzen (Interface-3, Interface-4).Datei: Sub_KP_InterfacePublicOperations.ebs
Sub KP_InterfaceRealize (Classes As ClassCollection,Einzel As Boolean, Abbruch As Boolean)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,Einzel As Boolean, Auto As Boolean, Abbruch As Boolean)Aufgabe: Überprüft, ob die Klassen mit dem Stereotyp «Interface» einen Zustandsauto-maten bzw. ein Zustandsdiagramm besitzen (Interface-10).Datei: Sub_KP_InterfaceStatemachine.ebs
Sub KP_CheckTypeClassGeneralization (Generalizations AsInheritRelationCollection, Einzel As Boolean, Abbruch As Boolean)Aufgabe: Überprüft, ob die Super-Klassifizierer eines Typen («type») ebenfalls Typensind (Typ-1).Datei: Sub_KP_CheckTypeClassGeneralization.ebs
Sub KP_AttributeDeklariert (Classes As ClassCollection,Einzel As Boolean, Abbruch As Boolean)Aufgabe: Überprüft, ob die Attributdeklarationen der Klassen einen Typ beinhalten (Attribut-2).Datei: Sub_KP_AttributeDeklariert.ebs
Sub KP_AttributExTyp (Classes As ClassCollection,Einzel As Boolean, Auto As Boolean, Abbruch As Boolean)Aufgabe: Überprüft, ob die Typen der Attribute der Klassen im Modell existieren (Attribut-3).Datei: Sub_KP_AttributExTyp.ebs
Sub KP_OpParaTypDeklariert (Classes As ClassCollection,Einzel As Boolean, Abbruch As Boolean)Aufgabe: Überprüft, ob die Typen der Parameter der Operationen der Klassen deklariertsind.Datei: Sub_KP_OpParaTypDeklariert.ebs
Sub KP_OpParaTypEx (Classes As ClassCollection,
207 ANHANG A. REALISIERUNG DER BENUTZERSCHNITTSTELLE
Einzel As Boolean, Auto As Boolean, Abbruch As Boolean)Aufgabe: Überprüft, ob die Typen der Parameter der Operationen der Klassen im Modellexistieren (Operation-3).Datei: Sub_KP_OpParaTypEx.ebs
Sub KP_CheckAndSetClassAbstract (Classes As ClassCollection,Einzel As Boolean, Auto As Boolean, Abbruch As Boolean)Aufgabe: Überprüft, ob die Klassen abstrakte Operationen besitzen und als abstrakt spe-zifiziert sind (Operation-4).Datei: Sub_KP_CheckAndSetClassAbstract.ebs
Sub KP_AssociationsNavigable (Associations As AssociationCollection,Einzel As Boolean, Abbruch As Boolean)Aufgabe: Überprüft, ob die Assoziationen in eine Richtung navigierbar sind (Assoziation-2).Datei: Sub_KP_AssociationsNavigable.ebs
Sub KP_NavRoleExName (Associations As AssociationCollection,Einzel As Boolean, Abbruch As Boolean)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, AbbruchAs Boolean)Aufgabe: Überprüft, ob Klassen abstrakte Operationen ihrer Oberklassen realisieren (alsnicht abstrakt deklarieren) (Operation-5).Datei: Sub_KP_KonkreteKlassenUmAbstrakteOperationenErweitern.ebs
Sub KP_InterfaceAktiv (Classes As ClassCollection,Einzel As Boolean, Auto As Boolean, Abbruch As Boolean)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,Einzel As Boolean, Auto As Boolean, Abbruch As Boolean)Aufgabe: Überprüft, ob Klassen alle Operationen ihrer Interfaces realisieren (deklarie-ren) (Operation-13).Datei: Sub_KP_RealizeInterfaceOperations.ebs
A.4. INSTALLATION 208
Sub KP_ExistsSignalClass (Classes As ClassCollection,Einzel As Boolean, Auto As Boolean, Abbruch As Boolean)Aufgabe: Überprüft, ob zu den Signal-Operationen eine entsprechende Signalklasse imModell existiert (Signal-1).Datei: Sub_KP_ExistsSignalClass.ebs
Sub KP_SignalStatemachine (Classes As ClassCollection,Einzel As Boolean, Auto As Boolean, Abbruch As Boolean)Aufgabe: Überprüft, ob Klassen mit Signal-Operationen einen Zustandsautomaten besit-zen, der den Emfang des Signals spezifiziert (Signal-4).Datei: Sub_KP_SignalStatemachine.ebs
Sub KP_SignalActiveClass (Classes As ClassCollection,Einzel As Boolean, Auto As Boolean, Abbruch As Boolean)Aufgabe: Überprüft, ob Klassen mit Signal-Operationen als aktiv spezifiziert sind (Signal-5).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) kopiertwerden.
2. Anpassung der Rose-Menü-Dateirose.mnu:Sollen die Auswahldialoge unter dem MenüpunktReporterreichbar sein, sind nachden Zeilen
Menu Report{
die folgenden Zeilen einzufügen:
option "Check Classdiagram1"
209 ANHANG A. REALISIERUNG DER BENUTZERSCHNITTSTELLE
{RoseScript $SCRIPT_PATH\KP_Klassendiagramm1
}option "Check Classdiagram2"
{RoseScript $SCRIPT_PATH\KP_Klassendiagramm2
}
Hinter optionkann 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 Klasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .152.2 Interface (Lolli) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .152.3 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162.4 Kollaborationssymbol . . . . . . . . . . . . . . . . . . . . . . . . . . . .162.5 Anwendungsfall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .172.6 aktive Klasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .172.7 Komponente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .172.8 Knoten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182.9 Interaktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192.10 Zustände und Transitionen . . . . . . . . . . . . . . . . . . . . . . . . .192.11 Paket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .202.12 Notiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .202.13 Abhängigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .212.14 Assoziation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .212.15 Generalisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .222.16 Realisierungsbeziehung . . . . . . . . . . . . . . . . . . . . . . . . . . .222.17 Anwendungsfalldiagramm . . . . . . . . . . . . . . . . . . . . . . . . .242.18 Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .252.19 Objektdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .262.20 Sequenzdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .272.21 Kollaborationsdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . .272.22 Zustandsdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . .282.23 Aktivitätsdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . .292.24 Zusicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
3.1 Paketübersicht des Metamodells . . . . . . . . . . . . . . . . . . . . . .363.2 Pakete des Fundaments der UML . . . . . . . . . . . . . . . . . . . . . .373.3 Vererbungshierarchie . . . . . . . . . . . . . . . . . . . . . . . . . . . .393.4 Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .423.5 Backbone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .443.6 Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .453.7 Namensraum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .463.8 Zusicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
210
211 ABBILDUNGSVERZEICHNIS
3.9 verallgemeinerbares Element und Klassifizierer . . . . . . . . . . . . . .483.10 Merkmale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .503.11 Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .523.12 Klassifizierer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .553.13 Assoziation und Kardinalität . . . . . . . . . . . . . . . . . . . . . . . .583.14 gerichtete Assoziation . . . . . . . . . . . . . . . . . . . . . . . . . . . .583.15 Spezifizierung von Rollen durch Interfaces . . . . . . . . . . . . . . . . .583.16 geordnetes Assoziationsende . . . . . . . . . . . . . . . . . . . . . . . .593.17 Komposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .603.18 Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .603.19 qualifizierte Assoziation . . . . . . . . . . . . . . . . . . . . . . . . . .603.20 nicht-qualifizierte Assoziation . . . . . . . . . . . . . . . . . . . . . . .613.21 qualifizierte Assoziation . . . . . . . . . . . . . . . . . . . . . . . . . .613.22 Assoziationsklasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . .623.23 Beziehungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .633.24 Assoziationsende . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .633.25 Ablaufbeziehung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .673.26 Abhängigkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .683.27 Kommentar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .713.28 Erweiterungsmechanismen . . . . . . . . . . . . . . . . . . . . . . . . .723.29 Datentypen (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .763.30 Datentypen (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .783.31 Ausdrücke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .793.32 Paketübersicht der Verhaltenselemente . . . . . . . . . . . . . . . . . . .813.33 Signal, Ausnahme und Empfang . . . . . . . . . . . . . . . . . . . . . .833.34 Aktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .853.35 Sende-Aktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .873.36 Exemplare und Links . . . . . . . . . . . . . . . . . . . . . . . . . . . .883.37 Link und Stimulus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .913.38 Sequenzdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .933.39 Kollaborationsdiagramm der Spezifikationsebene . . . . . . . . . . . . .943.40 Kollaborationsdiagramm der exemplarischen Ebene . . . . . . . . . . . .943.41 Sequenzdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .973.42 Kollaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .983.43 Zustandsautomat einer Klimaanlage . . . . . . . . . . . . . . . . . . . .1023.44 Metamodell der Ereignisse . . . . . . . . . . . . . . . . . . . . . . . . .1033.45 Erinnerungszustände . . . . . . . . . . . . . . . . . . . . . . . . . . . .1073.46 Zustand mit nebenläufigen Bereichen . . . . . . . . . . . . . . . . . . .1083.47 Metamodell des Zustandsautomaten . . . . . . . . . . . . . . . . . . . .1093.48 Aktivitätsdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1143.49 Aktivitätsdiagramm (Metamodell) . . . . . . . . . . . . . . . . . . . . .1153.50 Objektfluß . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117
ABBILDUNGSVERZEICHNIS 212
4.1 Konsistenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1224.2 Konsistenz: Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . .1234.3 Ein hypothetisches Werkzeug . . . . . . . . . . . . . . . . . . . . . . . .1264.4 Rational Rose 98 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1294.5 Rose Extensibility Interface (REI) . . . . . . . . . . . . . . . . . . . . .1324.6 Die Spitze der Klassenhierarchie von Rose . . . . . . . . . . . . . . . . .1354.7 Rose: Diagrammklassen . . . . . . . . . . . . . . . . . . . . . . . . . .1364.8 Rose: Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . .1384.9 Rose: Interaktionsdiagramm . . . . . . . . . . . . . . . . . . . . . . . .1394.10 Rose: Zustandsdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . .1414.11 abstrakte Klasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1424.12 abstrakte Klasse (Metamodellexemplar) . . . . . . . . . . . . . . . . . .1434.13 abstrakte Klasse (Rose-Metamodellexemplar . . . . . . . . . . . . . . .1434.14 Attribut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1444.15 Attribut (Metamodellexemplar) . . . . . . . . . . . . . . . . . . . . . . .1454.16 Attribut (Rose-Metamodellexemplar . . . . . . . . . . . . . . . . . . . .1454.17 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1484.18 Operation (Metamodellexemplar) . . . . . . . . . . . . . . . . . . . . . .1484.19 Operation (Rose-Metamodellexemplar . . . . . . . . . . . . . . . . . . .1484.20 Assoziation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1504.21 Assoziation (Metamodellexemplar) . . . . . . . . . . . . . . . . . . . . .1514.22 Assoziation (Rose-Metamodellexemplar) . . . . . . . . . . . . . . . . .1524.23 Komposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1544.24 Assoziationsklasse, inkonsistent . . . . . . . . . . . . . . . . . . . . . .1554.25 Generalisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1554.26 Generalisierung (Metamodellexemplar) . . . . . . . . . . . . . . . . . .1564.27 Generalisierung (Rose-Metamodellexemplar) . . . . . . . . . . . . . . .1564.28 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1574.29 Interface (Metamodellexemplar) . . . . . . . . . . . . . . . . . . . . . .1574.30 Interface (Rose-Metamodellexemplar) . . . . . . . . . . . . . . . . . . .1584.31 Realisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1594.32 Realisierung (Metamodellexemplar) . . . . . . . . . . . . . . . . . . . .1604.33 Realisierung (Rose-Metamodell) . . . . . . . . . . . . . . . . . . . . . .1604.34 Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1624.35 Spezifizierung von Rollen durch Interfaces . . . . . . . . . . . . . . . . .1644.36 Typen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1644.37 Klassifiziererrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1664.38 „Objektrolle“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1664.39 Klassifiziererrolle (Metamodellexemplar 1) . . . . . . . . . . . . . . . .1664.40 Klassifiziererrolle (Metamodellexemplar 2) . . . . . . . . . . . . . . . .1674.41 Assoziationsrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1684.42 Verwendung von Typen als Klassifiziererrollen . . . . . . . . . . . . . .168
213 ABBILDUNGSVERZEICHNIS
4.43 Verwendung von Typen als Rollen für Objekte . . . . . . . . . . . . . . .1684.44 Assoziations- und Klassifiziererrollen (Metamodellexemplar) . . . . . . .1694.45 Objekte, Links und Botschaften in Rose (Meta) . . . . . . . . . . . . . .1714.46 Botschaften und Stimuli . . . . . . . . . . . . . . . . . . . . . . . . . .1724.47 Botschaft im Kollaborationsdiagramm . . . . . . . . . . . . . . . . . . .1744.48 Prozedualer Kontrollfluß . . . . . . . . . . . . . . . . . . . . . . . . . .1764.49 Reihenfolge der Botschaften/Stimuli . . . . . . . . . . . . . . . . . . . .1764.50 Iteration im Kollaborationsdiagramm . . . . . . . . . . . . . . . . . . . .1774.51 Interaktion im Sequenzdiagramm . . . . . . . . . . . . . . . . . . . . . .1784.52 Iteration im Sequenzdiagramm (außerhalb der UML) . . . . . . . . . . .1794.53 Ereignisse im Metamodell . . . . . . . . . . . . . . . . . . . . . . . . .1804.54 Die KlasseEvent des Rose-Metamodells . . . . . . . . . . . . . . . . .1814.55 Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1834.56 Transition (Metamodellexemplar) . . . . . . . . . . . . . . . . . . . . .1834.57 Transition (Rose-Metamodell) . . . . . . . . . . . . . . . . . . . . . . .1844.58 Zustand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1854.59 Zustand (Metamodellexemplar) . . . . . . . . . . . . . . . . . . . . . . .1864.60 Rekursiver Aufbau eines Zustandsautomaten . . . . . . . . . . . . . . . .1874.61 Zustandsautomat (Beispiel) . . . . . . . . . . . . . . . . . . . . . . . . .1874.62 nebenläufiger Kompositionszustand . . . . . . . . . . . . . . . . . . . .1894.63 Die Pseudozustände fork und join . . . . . . . . . . . . . . . . . . . . .1904.64 Synchronisationszustand . . . . . . . . . . . . . . . . . . . . . . . . . .1914.65 Stummelzustände . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1924.66 Junction-Pseudozustand . . . . . . . . . . . . . . . . . . . . . . . . . . .1934.67 Choice-Pseudozustand . . . . . . . . . . . . . . . . . . . . . . . . . . .1934.68 Aufruf eines eingebetteten Zustandsautomaten . . . . . . . . . . . . . . .194
5.1 Auswahldialog: Konsistenzprüfungen . . . . . . . . . . . . . . . . . . .1995.2 Inkonsistenzdialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200
Index
Abhängigkeit, 67Abstraktion, 68access (Zugriff), 70Benutzung, 69derive, 68friend, 70import, 70realize, 68refine, 68trace, 68
Abhangigkeit, 20Erlaubnis, 70
Abstraktion, 67addOnly, 51Aktion, 84, 105
Erzeuge-, 86Nichtinterpretierte, 87Rückgabe-Aktion, 86Sende-, 87Terminiere-, 86Zerstöre-, 86Zuweisungs-, 86
Aktionssequenz, 86Aktionszustand, 116Aktivitätsdiagramm, 81Aktivitat, 105Aktivitatsdiagramm, 26Anderungs-Ereignis, 104Anmerkungen, 20Anwendungsfall, 16Anwendungsfalldiagramm, 23Anwendungsfallsicht, 31, 130association, 91Assoziation, 57, 62
Assoziationsende, 57, 63Assoziationsklasse, 62, 65Attribut, 51Aufruf
Aktion-, 86Aufruf-Ereignis, 103Aufrufzustand, 117Ausnahme, 83Automat, 19
Basisklasse, 38Benutzung, 67Beziehungen, 20Bindung, 67Botschaft, 82
changeable, 51child, 38classifier, 51Codeerzeugung, 120complete, 66concurrency, 53concurrent, 53
Datentyp, 56AggregationKind, 76Aufzählung, 76Boolean, 76CallConcurrencyKind, 76ChangeableKind, 76Integer, 75MessageDirectionKind, 76OperationDirectionKind, 76OrderingKind, 76ParameterDirectionKind, 76
214
215 INDEX
primitiver, 75Programmiersprachentyp, 77PseudostateKind, 76String, 75Struktur, 76Time, 75UnlimitedInteger, 75VisibilityKind, 76
Datenwert, 89destroyed, 91Diagramme, 23direkte Oberklasse, 38direktes Exemplar, 38disjoint, 66
Beispiel, 38Diskriminator, 38, 66
Eigenschaftswert, 34, 72Einsatzdiagramm, 30Einsatzsicht, 32, 130Element, 43
Modell-, 45Präsentations-, 45verallgemeinerbares, 47
Empfang, 83Entwurfssicht, 31Ereignis, 103
verzogertes, 106Ereignis-Trigger, 105Erinnerungszustand
flacher, 106Erlaubnis, 67Erweiterung, 38, 40Erweiterungsmeachnismus, 71Exemplar, 87
direkt, 38indirektes, 40
Fachlexikon, 120frozen, 51
Generalisierung, 21, 38, 66global, 91
guarded, 53
Implementationssicht, 31in, 54incomplete, 66indirektes Exemplar, 40Inkonsistenzvermeidung, 125inout, 54instance, 51Instantiierung, 41Interaktion, 18Interaktionsdiagramm, 23Interface, 15, 43, 56Interoperabilitat, 121
Kardinalität, 79Kind, 38Klasse, 15, 38, 42, 55
abstrakte, 40aktive, 17konkrete, 40Ober-, 38Sub-, 38Super-, 38Unter-, 38
Klassendiagramm, 23Klassifizierer, 48Knoten, 18, 56Knotenexemplar, 89Kollaboration, 16, 99Kollaborationsdiagramm, 25, 80Kommentar, 20Komponente, 17, 56Komponentendiagramm, 30Komponentenexemplar, 89Komponentensicht, 31, 130Konsistenz
Definition, 124Probleme, 124
Konsistenzprufung, 120, 127Konsistenzunterstutzung, 127
Link, 90
INDEX 216
Link-Ende, 90Linkobjekt, 90local, 91logische Sicht, 31, 130
Mehrbenutzerunterstutzung, 120Merkmal, 49
überschreiben, 40strukturelles, 51Verhaltens-, 52
Methode, 43, 54multiplicity, 51
Nachbedingung, 43Nachkomme, 38Namensraum, 46
virtueller, 45new, 91Notiz, 20
Oberklasse, 38Objekt, 89Objektdiagramm, 23Objektfluszustand, 117Operation, 53Operationsaufruf, 82out, 54overlapping, 66
Paket, 19Paketdiagramm, 137Parameter, 54parameter, 91parent, 38persistence, 49Polymorphismus, 40Prozessicht, 31Pseudoattribut, 45, 49Pseudozustand, 111
Qualifikationsangabe, 60
Realisierung, 22Realisierungssicht, 31
return, 54Reverse-Engineering, 120
self, 91sequential, 53Sequenzdiagramm, 23, 80Sichtbarkeit
Attribut-, 42Signal, 82Signal-Ereignis, 103Signatur, 40
Definition, 52Spezialisierung, 38Statechart, 25statechart, 101StateVertex, 110Stereotyp, 33, 71
access, 70become, 66call, 70copy, 66create, 53, 70, 103derive, 68destroy, 53, 103document, 57executable, 57file, 57friend, 70implementation, 66implementationClass, 55implicit, 62import, 70instantiate, 70invariant, 47library, 57metaclass, 49postcondition, 47powertyp, 49precondition, 47process, 49realize, 68refine, 68
217 INDEX
requirement, 71responsibility, 71send, 70signal, 82table, 57thread, 49trace, 68type, 55utility, 49
Stimulus, 82, 90Subklasse, 38Substitutionsprinzip, 40Superklasse, 38Synchronisationszustand, 112
targetScope, 51transient, 91Transition, 105
interne, 105Trigger, 105Typ, 54
Attribut-, 42
Unterklasse, 38Unterzustand, 110
Vererbung, 21, 38Verteilungsdiagramm, 30Verteilungssicht, 32Vorbedingung, 43Vorfahr, 38
Wachterbedingung, 105Werkzeug
hypothetisches, 125Wiederverwendbarkeit, 121
Zeit-Ereignis, 104Zusicherung, 47, 72, 74
addOnly, 63frozen, 63xor, 62
Zusicherungen, 34
Zustand, 105Unterautomaten-, 113
Zustandsautomat, 19, 101, 105Zustandsdiagramm, 25, 80, 101Zustandsknoten, 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, Metho-den, Sprachen, Werkzeuge. Reihe Informatik. BI Wissenschaftsverlag, Mann-heim; Leipzig; Wien, Zürich, 1992. Das Buchprogramm des Bibliographi-schen 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, Ber-lin, 1996.
[Bal98] Helmut Balzert. Lehrbuch der Software-Technik: Software-Management,Software-Qualitätssicherung, Unternehmensmodellierung. Lehrbücher der In-formatik. Spektrum Akademischer Verlag, Heidelberg, Berlin, 1998.
[BRJ99a] Grady Booch, James Rumbaugh, and Ivar Jacobson.Das UML-Benutzerhandbuch. Professionelle Softwareentwicklung. Addison Wesley,1999.
[BRJ99b] Grady Booch, James Rumbaugh, and Ivar Jacobson.The Unified ModelingLanguage 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 ThemaUML 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 LITERATURVERZEICHNIS
[Oes98] Bernd Oesterreich.Objektorientierte Softwareentwicklung. Analyse und De-sign mit der Unified Modeling Language.R. Oldenbourg Verlag, 4. edition,1998.
[OMG99] OMG (Object Management Group). OMG unified modeling language speci-fication (draft). http://www.omg.org, April 1999. Version 1.3 beta R1.
[Qua98] Terry Quatrani.Visual Modeling with Rational Rose and UML. Object Tech-nology Series. Addison Wesley, 1998.
[R+93] James Rumbaugh et al.Objektorientiertes Modellieren und Entwerfen. Han-ser, 1993.
[Rat98] Rational Software Cooperation, editor.Rational Rose 98. Extensibility Refe-rence Manual. February 1998. Software Release 1.0.
[Sch91] Heinrich Schmidt.Philosophisches Wörterbuch. Alfred Kröner Verlag, Stutt-gart, 22. edition, 1991.
[Sch95] Jochen Schwarze.Systementwicklung. Verlag Neue Wirtschaftsbriefe, Her-ne/Berlin, 1995.