Konsistenz und Werkzeugunterstützung von ... · 3.2.3.2 Zustandsautomat ... 4.1 Anforderungen an ein UML-Werkzeug ... Systeme zeichnen sich durch Struktur und Verhalten aus und

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


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


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.


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


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


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.


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


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.


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.


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


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


: ... KdObj : Kunde


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.


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.


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.


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.


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


Viereck


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


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.


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.


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


presentation (Abb. 3.6) Bezeichnet ein Präsentationselement, welches dasModellelement darstellt.

3.1. FUNDAMENT 46


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.


ownedElement Modellelemente, die zum Namensraum gehören.


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


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


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


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.


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.



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.


Classifier

Class

isActive : BooleanDataType

Interface Node Component

*

*+deploymentLocation

* +resident

*

ModelElement

name : Name

*

*

+implementation*

+resident*

ElementResidence


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.


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


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


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


{ordered}

AssociationClass

Class

isActive : Boolean


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.


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.


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.


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


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.


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.


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.


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.


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.


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)


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-


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


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


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.


actual Eine Argumentliste, die Ausdrücke zur Bestimmung der zurAusführungszeit der Aktion zu benutzenden Argumente (Ex-emplare) enthält.


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


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.


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


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


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


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.


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.


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:


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


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)


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.


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


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


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.


{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


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.


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.


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.


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-


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.


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


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:


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.


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.


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-


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.


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.


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


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-


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


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.


• 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


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


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


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


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.


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


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.


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.


Attribut Semantik

isSynch Boolescher Ausdruck, der angibt, ob ein Objektflußzustand alsSynchronisationszustand benutzt wird.


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.


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-


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)


• 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


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.


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.


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-


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.


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-


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


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.


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.


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.


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


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.


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


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.


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.


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.


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.


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


• 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).


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.


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


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



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,


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



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


: 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).


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


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.


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


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!


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


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.


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.


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.


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.


• 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


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.


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.


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,


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


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.


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.


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


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


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


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


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.


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-


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


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.


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


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.


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


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


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)


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


Abbildung 5.1:Auswahldialog der Konsistenzprüfungen („grundsätzliche Fehler“) inKlassendiagrammen

5.3. KONZEPT DER BENUTZERSCHNITTSTELLE 200

Abbildung 5.2: Inkonsistenzdialog


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)


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,


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"


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