Konformität und Werkzeugunterstützung für ... 3.2.3.2 Zustandsmaschinen ... 4.1 Anforderungen an UML-Werkzeuge ... Systeme zeichnen sich durch Struktur und Verhalten aus und

Konsistenz und

Werkzeughalter

Systemspezifikationen in UML

Abschlussarbeit

Stephen Schubert

im Rahmen der Mathematik für Informatik

an der Universität Hannover

Erstgutachter: Prof. Dr. Udo Lipeck Zweitgutachter: Dipl. Mathematik. Christopher Glass-DeUlis

Hannover, 25. Juli 1999

zusammenfassen

Unified Modeling Language (UML) ist eine Sprache zum Dokumentieren, Analysieren, Entwerfen und Spezifizieren von Systemen. Ein UML-Modell beschreibt die statischen und dynamischen Aspekte eines Systems durch mehrere miteinander verbundene Ansichten, die aus verschiedenen Diagrammen bestehen.

In dieser Arbeit wird beschrieben, wie Tools zur Überprüfung der Konsistenz von UML-Modellen verwendet werden. Einführung des UML-Metamodells, das die Semantik von UML definiert. Es bildet die Grundlage für die Identifizierung der Konsistenzbedingungen, die zwischen den Elementen des vom Modellierer erstellten UML-Modells angewendet werden müssen.

Es erläutert, inwieweit Tools Modellierer bei der Erstellung konsistenter UML-Modelle unterstützen können. Die kommerziellen UML-Tools von Rational Rose 98 wurden eingeführt und um die Konsistenzprüfung erweitert.

Index

1 Einführung 81.1 Unified Modeling Language. . . . . . . . . . . . . . . . . . . . . . 81.2 Historische Entwicklung. . . . . . . . . . . . . . . . . . . . . . . . . . 81.3 Zweck der Unified Modeling Language. . . . . . . . . . . . . . . . . . 91.4 Ziele dieser Arbeit. . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.5 Arbeitsstruktur. . . . . . . . . . . . . . . . . 1 . . . . . . . . . . . . . . . .12

2 Gliederung 142.1 Dinge in UML. . . . . . . . . . . . . . . . . . . . . . . . . . .14

2.1.1 Struktur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Schnittstelle. . . . . . . . . . . . . . . . . . . . . . . . . . 15 Zusammenarbeit. . . . . . . . . . . . . . . . . . . . . . . 16 Anwendungsfälle. . . . . . . . . . . . . . . . . . . . . . . 16 Aktive Klasse. . . . . . . . . . . . . . . . . . . . . . .17 Komponenten. . . . . . . . . . . . . . . . . . . . . .17 Abschnitt . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.1.2 Verhalten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Interaktion. . . . . . . . . . . . . . . . . . . . . . . . . 18 Zustandsmaschine. . . . . . . . . . . . . . . . . . . . .19

2.1.3 Gruppierung. . . . . . . . . . . . . . . . . . . . . . . . . 192.1.4 Hinweis. . . . . . . . . . . . . . . . . . . . . . . . . . .20

2.2 Beziehungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2.1 Abhängigkeiten. . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2.2 Verein. . . . . . . . . . . . . . . . . . . . . . . . . . . 212.2.3 Verallgemeinerung. . . . . . . . . . . . . . . . . . . . . . . . .212.2.4 Umsetzung. . . . . . . . . . . . . . . . . . . . . . . . . . . .zweiundzwanzig

2.3 Diagramme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.3.1 Anwendungsfalldiagramm. . . . . . . . . . . . . . . . . . . . 232.3.2 Klassendiagramme. . . . . . . . . . . . . . . . . . . . . . . . 232.3.3 Objektdiagramme. . . . . . . . . . . . . . . . . . . . . . . . . .23

3 Verzeichnis

2.3.4 Interaktionsdiagramm. . . . . . . . . . . . . . . . . . . . . . 232.3.5 Zustandsdiagramm. . . . . . . . . . . . . . . . . . . . . . . 252.3.6 Aktivitätsdiagramme. . . . . . . . . . . . . . . . . . . . . . . 262.3.7 Komponentendiagramm. . . . . . . . . . . . . . . . . . . . . . 302.3.8 Bereitstellungsdiagramm. . . . . . . . . . . . . . . . . . . . . . .30

2.4 Architektur und Ansichten. . . . . . . . . . . . . . . . . . . . . . . 302.4.1 Anwendungsfallansicht. . . . . . . . . . . . . . . . . . . . . . 312.4.2 Logische Ansicht. . . . . . . . . . . . . . . . . . . . . . . . 312.4.3 Prozessvisualisierung. . . . . . . . . . . . . . . . . . . . . . . . . . 312.4.4 Komponenten anzeigen. . . . . . . . . . . . . . . . . . . . . . . 312.4.5 Verteilungsanzeige. . . . . . . . . . . . . . . . . . . . . . . . .32

2.5 Vierschichtige Metamodellarchitektur. . . . . . . . . . . . . . . . . 322.6 Verlängerungsmechanismus. . . . . . . . . . . . . . . . . . . . .33

2.6.1 Stereotypen. . . . . . . . . . . . . . . . . . . . . . . . . . . 332.6.2 Attributwerte. . . . . . . . . . . . . . . . . . . . . . . 342.6.3 Garantie. . . . . . . . . . . . . . . . . . . . . . . . .34

3 Metamodell 353.1 Hintergrund. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35

3.1.1 Kern. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.1.1.1 Struktur. . . . . . . . . . . . . . . . . . . . . .37

Verallgemeinerung. . . . . . . . . . . . . . . . . . . . . . . . 38 Erweiterungen und Einschränkungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Instanziierung. . . . . . . . . . . . . . . . . . . . . . . . Level 41. . . . . . . . . . . . . . . . . . . . . . . . . . . .42 Artikel. . . . . . . . . . . . . . . . . . . . . . . . 43 Präsentationselemente. . . . . . . . . . . . . . . . . 45 Modellelemente. . . . . . . . . . . . . . . . . . . . . . . 45 Namespaces. . . . . . . . . . . . . . . . . . . . . . . . 46 Einschränkungen. . . . . . . . . . . . . . . . . . . . . . 47 Generalisierbare Elemente. . . . . . . . . . . . . . . . . 47 Klassifikatoren. . . . . . . . . . . . . . . . . . . . . . . 48 Funktionen. . . . . . . . . . . . . . . . . . . . . . . . 49 Strukturmerkmale. . . . . . . . . . . . . . . . . . . . 51 Eigenschaften. . . . . . . . . . . . . . . . . . . . . . . 51 Verhaltensmerkmale. . . . . . . . . . . . . . . . . . . . 52 Operationen. . . . . . . . . . . . . . . . . . . . . . . 53 Methoden. . . . . . . . . . . . . . . . . . . . . . . . 54 Parameter. . . . . . . . . . . . . . . . . . . . . . 54

3.1.1.2 Klassifikatoren. . . . . . . . . . . . . . . . . . . . . . .55. . . . . . . . . . . . . . . . . . . . . . . . . . 55

Verzeichnis 4

Schnittstelle. . . . . . . . . . . . . . . . . . . . . . . 56 Datentypen. . . . . . . . . . . . . . . . . . . . . . . . . 56 Nr. . . . . . . . . . . . . . . . . . . . . . . . . . 56 Komponenten. . . . . . . . . . . . . . . . . . . . . . 56

3.1.1.3 Assoziation und Verallgemeinerung. . . . . . . . . . . . 57 Beziehungen. . . . . . . . . . . . . . . . . . . . . . . . 62 Vereine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Verein beendet. . . . . . . . . . . . . . . . . . . . . . 63 Assoziationsklassen. . . . . . . . . . . . . . . . . . . . 65 Zusammenfassung. . . . . . . . . . . . . . . . . . . . . . 66 Durchfluss. . . . . . . . . . . . . . . . . . . . . . . . . 66

3.1.1.4 Abhängigkeiten. . . . . . . . . . . . . . . . . . . . .67 Abhängigkeiten. . . . . . . . . . . . . . . . . . . . . . 67 Abstraktion. . . . . . . . . . . . . . . . . . . . . . . 68 Verwendung. . . . . . . . . . . . . . . . . . . . . . . . . . 69 Lizenz. . . . . . . . . . . . . . . . . . . . 70

3.1.1.5 Kommentare. . . . . . . . . . . . . . . . . . . . . . .713.1.2 Verlängerungsmechanismus. . . . . . . . . . . . . . . . . .71

Stereotyp. . . . . . . . . . . . . . . . . . . . . . 72 Vorlagenelemente. . . . . . . . . . . . . . . . . . . . . 73 Einschränkungen. . . . . . . . . . . . . . . . . . . . . 74 Tag-Wert. . . . . . . . . . . . . . . . . . . 75

3.1.3 Datentypen. . . . . . . . . . . . . . . . . . . . . . . . . . .75 Primitive. . . . . . . . . . . . . . . . . . . . . . 75 Struktur. . . . . . . . . . . . . . . . . . . . . . 76 Aufzählungen. . . . . . . . . . . . . . . . . . . . . 76 Arten von Programmiersprachen. . . . . . . . . . . . . . 77 Zuordnung. . . . . . . . . . . . . . . . . . . . . . . 77 Namen. . . . . . . . . . . . . . . . . . . . . . . . 77 Positionsreferenz. . . . . . . . . . . . . . . . . . 79 Vielfalt. . . . . . . . . . . . . . . . . . . . . 79 Ausdruck. . . . . . . . . . . . . . . . . . . . 79

3.2 Verhaltenselemente. . . . . . . . . . . . . . . . . . . . . . . . . . . 803.2.1 Allgemeines Verhalten. . . . . . . . . . . . . . . . . . . . .82

3.2.1.1 Signalisierung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Auffälligkeiten. . . . . . . . . . . . . . . . . . . . . . . . . 83 Empfang. . . . . . . . . . . . . . . . . . . . . . 83

3.2.1.2 Aktionen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Aktionen. . . . . . . . . . . . . . . . . . . . . . . . 84 Aktionssequenzen. . . . . . . . . . . . . . . . . . . . . . 86 Aktionen erstellen. . . . . . . . . . . . . . . . . . . . . 86

5 Verzeichnis

Aktion zerstören. . . . . . . . . . . . . . . . . . . . . 86 Beenden Sie den Vorgang. . . . . . . . . . . . . . . . . . . . . 86 Aufrufvorgang. . . . . . . . . . . . . . . . . . . . . 86 Rückgabeaktion. . . . . . . . . . . . . . . . . . . . . . 86 Aktionen zuweisen. . . . . . . . . . . . . . . . . . . . . 86 Aktion senden. . . . . . . . . . . . . . . . . . . . . . . 87 Unerklärliche Handlungen. . . . . . . . . . . . . . . . . 87

3.2.1.3 Kopie und Links. . . . . . . . . . . . . . . . . . 87 Beispiele. . . . . . . . . . . . . . . . . . . . . . . 87 Datenwerte. . . . . . . . . . . . . . . . . . . . . . . 89 Objekte. . . . . . . . . . . . . . . . . . . . . . . . 89 Komponenteninstanzen. . . . . . . . . . . . . . . . . . . 89 Knoteninstanzen. . . . . . . . . . . . . . . . . . . . . . 89 Objekte verknüpfen. . . . . . . . . . . . . . . . . . . . . . . . . 90 Reize. . . . . . . . . . . . . . . . . . . . . . . . 90 Links. . . . . . . . . . . . . . . . . . . . . . . . . . 90 Ende des Links. . . . . . . . . . . . . . . . . . . . . . . . Nach den 90ern

3.2.2 Zusammenarbeit. . . . . . . . . . . . . . . . . . . . . . . . . . .92 Funktionale Notation in der Zusammenarbeit. . . . . . . . . 92 Interaktion. ............. . . . . . . . . . . . . . . . . . . . . 97 Zusammenarbeit. . . . . . . . . . . . . . . . . . . . . . . 99 Interaktionen. . . . . . . . . . . . . . . . . . . . . . . 99 Nachrichten. . . . . . . . . . . . . . . . . . . . . . . . . . 100 Klassifiziererrollen. . . . . . . . . . . . . . . . . . . . . . . . . . . . 100AssociationRole. . . . . . . . . . . . . . . . . . . . . . 101AssociationEndRole. . . . . . . . . . . . . . . . .101

3.2.3 Zustandsmaschine. . . . . . . . . . . . . . . . . . . . . . .1013.2.3.1 Ereignis. . . . . . . . . . . . . . . . . . . . . .103

selbst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Signalereignisse. . . . . . . . . . . . . . . . . . . . . . . . . 103 Anrufereignis. . . . . . . . . . . . . . . . . . . . . . . . . 103 Zeitereignisse. . . . . . . . . . . . . . . . . . . . . . . . 104ChangeEvent. . . . . . . . . . . . . . . . . . . . . .104

3.2.3.2 Zustandsmaschine. . . . . . . . . . . . . . . . . . . . . . 105 Zustandsmaschine. . . . . . . . . . . . . . . . . . . . . . . . . 106 Zusammengesetzte Zustände. . . . . . . . . . . . . . . . . . . . . . . 110StateVertex. . . . . . . . . . . . . . . . . . . . . . . .110 Übergang. . . . . . . . . . . . . . . . . . . . . . . 110 Verteidiger. . . . . . . . . . . . . . . . . . . . . . 110 Staaten . . . . . . . . . . . . . . . . . . . . . . . . . . .111

Verzeichnis 6

einfacher Zustand. . . . . . . . . . . . . . . . . . . . . . . . . . 111EstadoFinal. . . . . . . . . . . . . . . . . . . . . . . . 111 Pseudoland. . . . . . . . . . . . . . . . . . . . . . . . . 111 Synchronisierungsstatus. . . . . . . . . . . . . . . . . . . . . . . . . . 112 Submachine-Status. . . . . . . . . . . . . . . . . . . . . . 113 Stub-Status. . . . . . . . . . . . . . . . . . . . . .113

3.2.4 Aktivitätsdiagramme. . . . . . . . . . . . . . . . . . . . . . . . . . 113 Aktivitätsdiagramme. . . . . . . . . . . . . . . . . . . . . . . 116 Subaktivitätsstatus. . . . . . . . . . . . . . . . . . . . . 116 Staatliche Maßnahmen. . . . . . . . . . . . . . . . . . . . . . . . . 116 Anrufstatus. . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Objektflussstatus. . . . . . . . . . . . . . . . . . . . . . . 117 Klassifikatorstatus. . . . . . . . . . . . . . . . . . . . 118 Pseudo-Zustand. . . . . . . . . . . . . . . . . . . . . .118

4 Tool-Unterstützung und Konformität 1194.1 UML-Tool-Anforderungen. . . . . . . . . . . . . . . . . . 1194.2 Konsistenz. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121

4.2.1 Bedeutung der Konsistenzprüfung. . . . . . . . . . . . . . . . . 1244.2.2 Problem mit der Konsistenzprüfung (Support-Tools). . . . . .1244.2.3 Was-wäre-wenn-Tools zum Erstellen von Modellen

Zähne. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1254.2.4 Als Konsistenzprüfung für Informationsproduzenten. . . . . . . . . . .128

4.3 Rational Rose 98. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1284.3.1 UML-Modelle in Rational Rose 98. . . . . . . . . . . . . . . . 1284.3.2 Zusätzliche Funktionen von Rational Rose 98. . . . . . . . . . . . 1314.3.3 Konsistente UML-Modelle und Rational Rose 98. . . . . . . . .133

4.4 Rational Rose 98 Tools-Metamodell. . . . . . . . . . . . . . 1344.4.1 Spitze der Klassenhierarchie. . . . . . . . . . . . . . . . . 1344.4.2 Diagrammtyp. . . . . . . . . . . . . . . . . . . . . . . . . . 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 Klasse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1424.5.2 Eigenschaften. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1444.5.3 Bedienung. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1474.5.4 Verein. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1504.5.5 Sonderverband. . . . . . . . . . . . . . . . . . . . . . 1534.5.6 Allgemeines. . . . . . . . . . . . . . . . . . . . . . . .1554.5.7-Schnittstelle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1574.5.8 Leistungsbeziehung. . . . . . . . . . . . . . . . . . . .159

7 Verzeichnis

4.5.9 Abhängigkeiten. . . . . . . . . . . . . . . . . . . 1614.5.10 Signal. . . . . . . . . . . . . . . . . . . . . . . . . .1624.5.11 Rollenspezifikation. . . . . . . . . . . . . . . . . . . .164

4.6 Interaktionsdiagramm. . . . . . . . . . . . . . . . . . . . . . . . . 1654.6.1 Klassifikatorfunktionen und -objekte. . . . . . . . . . . . . . . . . 1654.6.2 Affiliate-Rollen und Links. . . . . . . . . . . . . . . . . . . . 1674.6.3 Botschaften und Reize. . . . . . . . . . . . . . . . . . . . . . 1714.6.4 Kontrollfluss. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1754.6.5 Verzweigung und Iteration. . . . . . . . . . . . . . . . . . . .177

4.7 Zustandsdiagramm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1784.7.1 Vorfall. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1794.7.2. . . . . . . . . . . . . . . . . . . . . . . . . . . 1824.7.3 Übergang. . . . . . . . . . . . . . . . . . . . . . . . . . . 1824.7.4 Staat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1844.7.5 Zustandsmaschine. . . . . . . . . . . . . . . . . . . . . .186

5 Konsistenzprüfung UI 1955.1 Rose-Skriptressource. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1955.2 Build-Konsistenzprüfung. . . . . . . . . . . . . . . . . 1975.3 Benutzeroberflächenkonzepte. . . . . . . . . . . . . . . . . . . .198

Die Benutzeroberfläche implementiert das 202A.1-Konformitätsprüfungsskript. . . . . . . . . . . . . . . . . . . 202A.2 Skriptauswahldialoge. . . . . . . . . . . . . . . . . . . . . . 203A.3 Skripte entwickeln. . . . . . . . . . . . . . . . . . . . . . . . . . 203

A.3.1 Barrierefreiheit. . . . . . . . . . . . . . . . . . . . . . . . .203A.3.2 Konsistenzprüfung. . . . . . . . . . . . . . . . . . . . . . 204A.3.3 Auswahldialog. . . . . . . . . . . . . . . . . . . . . . . . .208

A.4 Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .208

Kapitel 1

einführen

Die ersten drei Abschnitte erklären, was die Unified Modeling Language ist, ihre historischen Wurzeln und die Ziele der Entwicklung dieser Modellierungssprache. Anschließend werden die Ziele dieser Arbeit erläutert und ihr Aufbau beschrieben. Abschließend wird auf die Probleme hingewiesen, die beim Verfassen dieser Arbeit aufgetreten sind.

1.1 Einheitliche Modellierungssprache

Ein System besteht aus „einer Menge von Elementen, die zusammenarbeiten oder durch Beziehungen interagieren, um ein bestimmtes Ziel oder einen bestimmten Zweck zu erreichen“ ([Sch95], S. 15). Menschen nutzen abstrakte Prinzipien, um komplexe Systeme zu verstehen. „Unter Abstraktion im engeren Sinne versteht man einen Denkprozess, der das Einzelne, Nebensächliche und Unwesentliche außer Acht lässt und das Allgemeine, Notwendige und Notwendige hervorhebt, um wissenschaftlich objektive Erkenntnisse zu erlangen“ ([Sch91], Seite 4). Das Ziel der Abstraktion vom System besteht darin, ein Modell des Systems zu erstellen, das es einem ermöglicht, die Elemente des Systems und ihre Interaktion zu verstehen. Im Allgemeinen handelt es sich bei der Unified Modeling Language (UML) um eine Sprache, die Systemmodelle grafisch beschreiben kann. UML wird hauptsächlich zur Dokumentation, Analyse, Gestaltung und Spezifikation von Softwaresystemen – insbesondere objektorientierten Systemen – verwendet. UML ist „nur“ eine (visuelle) Modellierungssprache, kein Softwareentwicklungsprozess oder gar eine visuelle Programmiersprache. Die historische Entwicklung der Sprache rechtfertigt den Begriff „Einheit“.

1.2 Historische Entwicklung

In den 1990er Jahren entstanden verschiedene Ansätze zur Entwicklung von Softwaresystemen. Die drei beliebtesten Methoden sind OMT (Ob-

9 Einleitung zu Kapitel 1

Project Modeling Techniques, James Rumbaugh et al., siehe [R+93]), Booch (Grady Booch) und OOSE (Object-Oriented Software Engineering, Ivar Jacobson). Jede dieser Methoden hat ihre eigene Notation und ihre eigenen Vor- und Nachteile. Die Weiterentwicklung einzelner Methoden erfordert die Übernahme von Konzepten aus anderen Methoden. Leider hat jede Methode immer noch ihre eigene Notation. Diese Zeit wird mit dem Begriff „Methodenkrieg“ beschrieben. Beispielsweise beschreibt ein ausgefüllter Kreis einen Kardinalitätsindikator in der OMT-Notation, in der Booch-Notation jedoch ein Aggregationszeichen. Wie soll eine Klasse dargestellt werden: als Wolke (Booch) oder als Rechteck (OMT)? Welcher Repräsentant ist besser? Die Situation ist für alle Beteiligten nicht ideal, da unterschiedliche Syntax und Semantik nicht nur für Softwareentwickler zu Kommunikationsschwierigkeiten führen.

Im Oktober 1994 begannen Grady Booch (Rational Software Company) und James Rumbaugh (der von General Electric zu Rational kam) mit der Vereinheitlichung der Booch- und OMT-Methoden und entwarfen Version 0.8, die im Oktober 1995 als „einheitliche Methode“ erschien.

Im Jahr 1995 trat Jakobson (OOSE) Rational bei und OOSE wurde dem Projekt hinzugefügt (1996, UML 0.9). Das UML-Konsortium (UML 1.0) besteht aus mehreren Softwareorganisationen, die bereit sind, Ressourcen beizutragen, um eine vollständige Definition von UML zu erstellen. Im Januar 1997 wurde UML 1.0 der OMG (Object Management Group) zur Standardisierung vorgelegt. Das Konsortium wurde erweitert und eine überarbeitete Version (UML 1.1) wurde im Juli 1997 der OMG zur Standardisierung vorgelegt und im November 1997 angenommen. In die Standardisierung fließen nicht nur Konzepte aus Booch-, OMT- und OOSE-Methoden ein, sondern auch „neue“ Konzepte, wie etwa die Zustandsdiagramme von Harel.

Die Weiterentwicklung von UML wurde von der OMG Revision Task Force (RTF) übernommen, die im Juni 1998 eine redaktionelle Überarbeitung veröffentlichte. Im Herbst 1998 erschien die Version 1.3, die einige technische Hinweise enthielt, und die endgültige Version wurde im Juli 1998 fertiggestellt. Jahr 1999. Es wird erwartet, dass sich UML wie jede „lebende“ Sprache weiterentwickeln wird.

1.3 Ziele der Unified Modeling Language

UML wurde mit mehreren Zielen entwickelt: (siehe [BRJ99b] und [OMG99])

1. Modellieren Sie das System vom Konzept bis zu ausführbaren Teilen mithilfe objektorientierter Techniken.

2. Überlegungen zur Erweiterung komplexer Systeme.

3. Erstellen Sie eine Modellierungssprache, die sowohl Menschen als auch Maschinen verwenden können.

1.3. Ziele der Unified Modeling Language 10

4. UML muss Benutzern eine leicht zugängliche und ausdrucksstarke visuelle Modellierungssprache für die Entwicklung und den Austausch von Modellen bieten.

UML vereint eine Reihe allgemeiner oder grundlegender Konzepte, die in anderen Methoden und Werkzeugen verwendet werden. Somit können Anwender anderer Methoden relativ einfach umsteigen und ihre Modelle mit vertretbarem Aufwand konvertieren.

5. UML muss Erweiterungs- und Spezialisierungsmechanismen enthalten.

Es wurde erwartet (oder wurde erwartet), dass sich UML an neue Anforderungen oder spezielle Domänen anpassen würde. Es besteht jedoch nicht die Absicht, den UML-Kern für jede Domäne neu zu definieren oder zu implementieren. Der UML-Kern erfordert keine unnötigen Änderungen. Benutzer müssen dazu in der Lage sein

• Entwurfsmodelle für die meisten Anwendungen verwenden generische UML-Konzepte ohne Erweiterungsmechanismen.

• Hinzufügen neuer Konzepte und Symbole, die nicht vom Kern abgedeckt werden,

• Konzepte und Symbole, die für bestimmte Anwendungsbereiche spezifisch sind.

6. Unabhängig von speziellen Programmiersprachen und Entwicklungsprozessen.

Unabhängigkeit bedeutet, sich nicht auf eine bestimmte Programmiersprache oder einen bestimmten Prozess festzulegen und gleichzeitig die Schwierigkeit zu minimieren, UML mit einer bestimmten Programmiersprache oder einem bestimmten Entwicklungsprozess zu verwenden.

7. Stellen Sie eine formale Grundlage für UML bereit.

8. Tool-Interoperabilität.

Interoperabilität erfordert, dass Modelle ohne Informationsverlust zwischen verschiedenen Tools ausgetauscht werden können. Dadurch können sich Tool-Entwickler auf bestimmte Funktionen ihrer Software konzentrieren, anstatt ihre Ressourcen auf verschiedene Tools für verschiedene Modellierungssprachen zu verteilen.

9. Unterstützung für übergeordnete Entwicklungskonzepte wie Zusammenarbeit, Frameworks, Muster und Komponenten.

10. Integrieren Sie bewährte Best Practices.

11 Kapitel 1 Einführung

1.4 Ziele dieser Arbeit

Systeme zeichnen sich durch Struktur und Verhalten aus und können durch Modelle beschrieben werden. Ein UML-Modell beschreibt die statischen und dynamischen Aspekte eines Systems durch mehrere miteinander verbundene Ansichten.

In der Use-Case-Sicht wird das System als Blackbox betrachtet. Es beschreibt grob die Funktionen und Prozesse des Systems, ohne deren Umsetzung detailliert darzustellen. Die logische Sicht beschreibt die Interna des Systems. Es spezifiziert die Systemelemente und deren Zusammenhänge und die Funktionen und Prozesse der Use-Case-Sicht werden realisiert. Andere Ansichten beschreiben die Parallelitäts- und Synchronisationsmechanismen des Systems, die Implementierung der vom System verwendeten Komponenten (Quelltext, ausführbare Dateien usw.) und die Verteilung der Komponenten auf der Systemhardware.

Ansichten bestehen aus Diagrammen, wobei jedes Diagramm einen bestimmten Aspekt des Systems beschreibt. UML stellt Diagramme zur Verfügung, die teilweise in verschiedenen Ansichten verwendet werden. Klassendiagramme beschreiben Systemelemente und ihre Beziehungen, während Interaktionsdiagramme die Interaktion von Systemelementen zur Erreichung eines bestimmten Ziels beschreiben. Andere dynamische Aspekte können mithilfe von Zustandsdiagrammen (Zustandsdiagrammen) und Aktivitätsdiagrammen (einer Art Flussdiagramm) modelliert werden. Anwendungsfalldiagramme, Komponentendiagramme und Verteilungsdiagramme sind weitere Diagramme, die in ihren jeweiligen Ansichten verwendet werden.

Eine UML-Systemspezifikation besteht aus einer Reihe von Diagrammen, die jeweils einen bestimmten Aspekt des Systems hervorheben. Ein Ziel dieser Arbeit ist es, Verbindungen zwischen Diagrammen und UML-Modellelementen zu finden, mit denen die Konsistenz (das Fehlen von Widersprüchen) von Systemspezifikationen in UML überprüft werden kann.

Auf dem CASE-Toolmarkt gibt es mehrere Tools zur Modellierung von Systemen mithilfe von UML. Rational Rose 98 ist ein UML-Tool der Rational Software Cooperation (siehe oben), das von mehreren Instituten der Universität Hannover eingesetzt wird. Ein weiteres Ziel dieser Arbeit ist die Untersuchung dieses Tools. Wie geht Rational Rose 98 mit der Frage der konsistenten Systemspezifikation um und welche Beziehungen zwischen Modellelementen werden auf Konsistenz überprüft? Rational Rose 98 sollte bei Bedarf um zusätzliche Tests erweitert werden.

1.5 Arbeitsstruktur

Kapitel 2 gibt einen Überblick über den Sprachumfang von UML. Eine kurze Einführung in die Elemente, Diagramme und Ansichten der UML-Sprache, aus denen ein UML-Modell besteht, sowie in die Erweiterungsmechanismen, die den Umfang der UML-Sprache erweitern.

Kapitel 3 erklärt das UML-Metamodell. Das Metamodell definiert

1.6. Probleme bei der Entstehung von Werken 12

Die formale Semantik von UML bildet die Grundlage für die Identifizierung von Konsistenzbedingungen in UML-Modellen.

In Kapitel 4 werden allgemeine Anforderungen an UML-Tools vorgestellt. Anschließend wird definiert, wann UML-Modelle konsistent sind. Erläutert Aspekte, die bei der Konsistenzprüfung von UML-Modellen zu berücksichtigen sind. Anhand eines hypothetischen Tools wird erläutert, wie das Tool den Modellierer bei der Erstellung konsistenter UML-Modelle unterstützt und welche Informationen die Konsistenzprüfung liefern soll. Stellt Modellierungsfunktionen und Konsistenzprüfung von Rational Rose 98 vor.

Rational Rose 98 verfügt über ein eigenes Metamodell, das teilweise das UML-Metamodell implementiert. Dieses Metamodell wird verwendet, um das Framework zu erläutern, das Rational Rose 98 zum Modellieren von UML-Modellen und zum Aufbau der semantischen Erkennung von Rational Rose 98 verwenden kann. Abschließend werden Konsistenzbedingungen zwischen Modellelementen von Klassendiagrammen, Interaktionsdiagrammen und Zustandsdiagrammen identifiziert.

Kapitel 5 beschreibt, wie Rational Rose um eine Benutzeroberfläche zur Konsistenzprüfung erweitert wird.

1.6 Probleme bei der Erstellung von Werken

Die Komplexität und Formalität des UML-Metamodells war zu Beginn der Arbeiten größer als erwartet. Daher muss nicht nur ein weiteres (optionales) Ziel der Arbeit, die Untersuchung und Umsetzung der Codegenerierung aus UML-Modellen, eliminiert werden, sondern auch bestimmte Arten von Diagrammen. Arbeiten Sie mit Klassendiagrammen, Interaktionsdiagrammen, Zustandsdiagrammen und Aktivitätsdiagrammen, da zwischen den Modellelementen dieser Diagrammtypen Verbindungen bestehen und deren Konsistenz überprüft werden kann.

Sowohl das UML-Metamodell als auch die UML-Semantik weisen Inkonsistenzen auf. Obwohl UML-Spezifikationen in relativ kurzen Abständen Korrekturen und kleinere Änderungen erfahren haben, gab es zwischen April 1999 und Juni 1999 sieben Spezifikationen, die einige Inkonsistenzen beseitigten, aber auch Änderungen einarbeiteten und somit neue Probleme aufwiesen. Eine Sprachspezifikation umfasst mittlerweile fast 800 Seiten, von denen etwa die Hälfte für diese Arbeit relevant ist. Leider sind Änderungen zwischen Spezifikationsversionen nur unzureichend dokumentiert, daher wurde die Version 1.3 Beta R1 vom April 1999 als Grundlage für diese Arbeit ausgewählt.

Der Grad der Formalität des Metamodells und die Semantik der Konzepte sind für „alte“ Diagrammtypen wie Klassendiagramme und Zustandsdiagramme gut definiert und klar, während dies für „neuere“ Diagrammtypen wie Sequenzdiagramme und Kollaborationsdiagramme (noch) nicht der Fall ist. Erfüllen Sie diese Anforderungsanforderungen, das heißt, das Metamodell ist in diesem Sinne unvollständig.

Die Identifizierung von Konsistenzbedingungen setzt voraus, dass die Semantik der Konzepte formal wohldefiniert ist. Dies ist nicht immer der Fall. und das

13 Kapitel 1 Einführung

In der verwendeten Literatur gibt es Inkonsistenzen, die größtenteils den Einsatz von UML beschreiben. Manchmal scheint es, als ob der Autor (verständlicherweise) nach dem Motto „Problem erkennen – Gefahr vermeiden“ vorgeht. Mit diesem Vorwurf muss auch der Autor dieses Werkes leben. Die Diskussion dieses Problems wird zu vorgeschlagenen Änderungen am UML-Metamodell führen, die den Rahmen dieser Arbeit sprengen würden.

Kapitel 2

Überblick

Die Unified Modeling Language ist eine Sprache zur Visualisierung, Spezifikation, Erstellung und Dokumentation softwareintensiver Systemkomponenten. Vokabular und Syntax dieser Modellierungssprache zielen auf die konzeptionelle und physische Darstellung von Softwaresystemen ab. Grafische Darstellungen von (komplexen) Zusammenhängen erleichtern das Verständnis („ein Bild sagt mehr als tausend Worte“) und die Kommunikation über Grenzen hinweg (Programmiersprachen, Sprachen, Wortschatz1). Allerdings ist UML mehr als eine Sammlung grafischer Symbole. Hinter jeder UML-Notation verbirgt sich eine wohldefinierte Semantik, sodass ein Entwickler ein Modell erstellen kann, das ein anderer Entwickler (oder Tool) klar erkennen kann ([BRJ99a], S. 15). Spezifikation bedeutet in diesem Zusammenhang die Erstellung genauer, eindeutiger und vollständiger Modelle. Die Abbildung solcher Modelle auf Programmiersprachen ermöglicht (unter bestimmten Voraussetzungen) die Codegenerierung (Forward Engineering). UML unterstützt die Dokumentation von Softwaresystemen mithilfe von Diagrammen, die bestimmte Ansichten des Systems oder Phasen darstellen.

Das UML-Vokabular besteht aus Dingen, Beziehungen und Diagrammen (2.1 bis 2.3). Dinge sind die Grundbausteine eines Modells, Beziehungen verbinden diese Dinge und ein Diagramm stellt einen Aspekt eines Systems dar, indem er bestimmte Dinge und ihre Beziehungen gruppiert. Eine Systemansicht besteht aus mehreren Diagrammen (2.4). UML ist in das Schichtenmodell eingebettet (2.5) und verfügt über Erweiterungsmechanismen, die Sprache selbst kann in gewissem Umfang erweitert werden (2.6).

2.1 Dinge in UML

Es gibt vier Arten von Dingen, die zur Beschreibung eines Systems in UML verwendet werden können: strukturelle Dinge (2.1.1), Verhaltensdinge (2.1.2),

1 Wittgenstein: „Die Grenzen meiner Sprache sind die Grenzen meiner Welt“

15 Kapitel 2 Übersicht

Dinge werden zum Gruppieren von Dingen (2.1.3) und zum Kommentieren (2.1.4) verwendet.

2.1.1 Struktur

Strukturelle Dinge sind UML-Substantive. Sie stellen konzeptionelle oder physikalische Elemente des Systems dar und sind meist statischer Natur. Insgesamt gibt es sieben Strukturelemente.

Klasse Eine Klasse beschreibt eine Menge von Objekten, die dieselbe Struktur (Attribute und Beziehungen), dasselbe Verhalten (Operationen) und dieselbe Semantik aufweisen.

Eine Klasse wird als Rechteck mit ihrem Namen und optionalen Attributen und Operationen dargestellt (Abbildung 2.1).

Klassenname

Eigenschaft:Typ=Anfangswert

Operation (Parameterliste): Rückgabewert

Abbildung 2.1: Klassennotation

Schnittstellen Eine Schnittstelle ist eine Sammlung von Betriebssignaturen (Name, Parameter, Rückgabetyp), die eine Klasse oder einen Komponentendienst beschreiben. Schnittstellenoperationen werden durch Klassen oder Komponenten implementiert. Somit beschreibt eine Schnittstelle das von außen sichtbare Verhalten einer Klasse oder Komponente.

Die Schnittstelle kann auf zwei Arten dargestellt werden:

1. Die Schnittstelle wird durch einen Kreis mit dem Namen der Schnittstelle dargestellt, und der Kreis ist mit dem Element verbunden, das die Schnittstellenoperation implementiert (Abbildung 2.2). Diese Schnittstellendarstellung wird auch als „Lollipop“ bezeichnet.

es kann

Adresse

save() kann speichern

Abbildung 2.2: Schnittstellendarstellung ohne Operationssignaturen.

2.1. Was ist in UML 16?

2. Alternativ kann die Schnittstelle durch eine Klasse von Rechtecken dargestellt werden (Abbildung 2.3). Um Schnittstellen von gewöhnlichen Klassen zu unterscheiden, wird das Klassenrechteck mit dem Stereotyp „Schnittstelle“ gekennzeichnet (siehe Seite 33). Verbindungen zwischen Schnittstellen und Klassen werden durch Implementierungsbeziehungen hergestellt (siehe Seite 22).

es kann

Adresse

nicht speichernComputer()

kann aufbewahrt werden

nicht speichernComputer()

Abbildung 2.3: Detaillierte Darstellung einer Schnittstelle mit Operationssignaturen.

Das UML-Schnittstellenkonzept ähnelt dem Java-Schnittstellenkonzept. In Java werden Schnittstellen auch über Klassen implementiert.

Kollaborationen Kollaborationen definieren den Kontext der Interaktion, bestehend aus den Rollen, die Elemente (z. B. Klassen) spielen, und den Beziehungen zwischen den Rollen. Rollen und ihre Beziehungen werden verwendet, um kollaboratives Verhalten darzustellen, das über die Summe der einzelnen Elemente hinausgeht, d. h. Zusammenarbeit beschreibt die Erledigung einer Aufgabe, die nicht von einem einzelnen Element erledigt werden kann. Zusammenarbeit hat nicht nur eine strukturelle Dimension, sondern auch eine Verhaltensdimension. Kollaborationen stellen die Verwirklichung von Mustern dar, die ein System bilden.

Eine Kollaboration wird durch eine gepunktete Ellipse dargestellt, die normalerweise nur ihren Namen enthält (Abbildung 2.4). Diese Darstellung ist in erster Linie ein Ort

Kooperationsname

Abbildung 2.4: Kollaborationsnotation

Kehren Sie zum Interaktionsdiagramm (S. 23) zurück, in dem die Struktur und das Verhalten detailliert beschrieben werden, die zur Erfüllung einer kollaborativen Aufgabe erforderlich sind.

Anwendungsfälle Ein Anwendungsfall ist eine Beschreibung einer Reihe von Prozessen, die von einem System ausgeführt werden und für den Benutzer (den Benutzer, aber auch ein externes System) ein wahrnehmbares Ergebnis liefern. Anwendungsfall hierfür

17 Kapitel 2 Übersicht

Erstellen Sie das Verhalten des Systems, ohne sich mit der Verhaltensimplementierung zu befassen. Das System gilt als „Black Box“. Ein Anwendungsfall wird durch Kollaboration, also durch die Zusammenarbeit mehrerer Elemente, realisiert.

Ein Anwendungsfall wird in einem Anwendungsfalldiagramm (z. B. Abbildung 2.17, Seite 24) als Oval mit einem Anwendungsfallnamen (Abbildung 2.5) dargestellt. Der Prozess selbst wird beispielsweise durch strukturierten Text oder mit Hilfe von Interaktions- und Aktivitätsdiagrammen spezifiziert (S. 26).

Bestellung annehmen

Abbildung 2.5: Use-Case-Notation

Aktivitätsklasse Eine Aktivitätsklasse ist eine spezielle Klasse, deren Objekte über einen oder mehrere Prozesse oder Threads verfügen, dh ihre Objekte stellen Elemente dar, die gleichzeitig ausgeführt werden können.

Aktive Klassen werden als Klassen in einem Klassenrechteck mit fetter Umrandung dargestellt, um sie von normalen Klassen zu unterscheiden (Abbildung 2.6). Diagrammname: Neues Klassendiagramm

Name der Diagrammdatei: clsUntitled2.VobChart Typ: UML-Klasse DiagramEreignisManager

suspend() verwerfen()

Abbildung 2.6: Aktivitätsklasse

Komponente Eine Komponente ist ein physischer, austauschbarer Teil eines Systems, der eine physische Gruppierung logischer Elemente (z. B. Klassen und Kollaborationen) darstellt, die implementiert werden sollen.

Komponenten werden als gestreifte Rechtecke dargestellt (Abbildung 2.7).

EreignisManager.java

Abbildung 2.7: Komponenten

2.1. Inhalte in UML 18

Knoten Ein Knoten ist ein physisches Element eines Systems und stellt typischerweise einen Computer mit einem Prozessor und Speicher dar. Ein Computer mit mehreren Prozessoren kann durch mehrere Knoten modelliert werden. Beispielsweise kann die Topologie eines Computernetzwerks mit Hilfe von Knoten modelliert werden (Abbildung 2.8). Komponenten können Knoten zugeordnet werden.

Arbeitsplatz

Stücke

Schaltzentrale

Anwendungsserver

Datenbankserver

10 MB Ethernet

100 MB Ethernet

Abbildung 2.8: Die Topologie eines Systems kann durch Knoten dargestellt werden

2.1.2 Verhalten

Verhalten beschreibt die dynamischen Aspekte des Systems. Sie sind Verben der Sprache. Im Allgemeinen gibt es in UML zwei grundlegende Verhaltenstypen zur Beschreibung der Dynamik eines Systems: Interaktionen und (endliche) Automaten.

Interaktion Eine Interaktion ist eine Reihe von Nachrichten (Nachrichten), die zwischen Objekten in einem gemeinsam festgelegten Kontext ausgetauscht werden, um ein bestimmtes Ziel oder einen bestimmten Zweck zu erreichen. Interaktionen können verwendet werden, um das Verhalten einer Reihe von Objekten oder Vorgängen festzulegen. Der Empfang einer Nachricht führt dazu, dass das empfangende Objekt ein bestimmtes Verhalten ausführt. Dies ist normalerweise eine Aktion am empfangenden Objekt, beispielsweise das Ändern von Beziehungen zu anderen Objekten, das Ändern von Werten oder das Senden von Nachrichten an andere Objekte.

Nachrichten werden als Pfeile dargestellt, die vom Sender zum Empfänger zeigen (Abbildung 2.9). Bei den zu übergebenden Informationen handelt es sich in erster Linie um einen Operationsnamen, einschließlich optionaler Parameter.

19 Kapitel 2 Übersicht

Druckvorschau: Windows

Event Manager

"erstellen"

Ausstellungsstück

Diagrammname: Neues Sequenzdiagramm. Dateiname des Diagramms: C:\Home\Stephan\DA\VUML\seqUntitled4.VobChart. Typ: UML-Sequenzdiagramm

Abbildung 2.9: Nachrichten in einem Sequenzdiagramm

Zustandsmaschine Eine Zustandsmaschine (endliche Automaten) beschreibt ein Verhalten, das die mögliche Abfolge von Zuständen angibt, die ein Objekt als Reaktion auf Ereignisse während seiner Existenz durchläuft, sowie die Reaktionen auf diese Ereignisse. Eine Zustandsmaschine kann verwendet werden, um das Verhalten einer einzelnen Klasse oder Operation festzulegen.

Staaten werden als abgerundete Rechtecke dargestellt, die die Namen der Staaten enthalten (Abbildung 2.10). An der Darstellung der Maschine sind üblicherweise weitere Elemente beteiligt: Zustandsübergänge (Transitions) als Richtungspfeile, Ereignisse (Auslöser von Zustandsübergängen) und Aktivitäten als Reaktionen auf Zustandsübergänge.

Arbeit essen

hungrig/Essen sortieren

satt / am Tisch sitzen

Abbildung 2.10: Vereinfachte Darstellung des Status von Diplomanden während des Studienabschlusses

UML-Zustandsmaschinen und -Diagramme basieren auf Harel-Zustandsdiagrammen. Eine UML-Zustandsmaschine kann Zustände haben, die als Zustandsmaschine betrachtet werden können.

2.1.3 Gruppierung

UML bietet einen Verpackungsmechanismus zum Organisieren von Modellen in überschaubaren Gruppen. Ein Paket enthält beliebige (logisch zusammenhängende) Modellelemente und kann somit ein Subsystem darstellen. Allerdings ist die Organisation in Pakete nur konzeptioneller Natur, Komponenten und Knoten sind für die physische Unterteilung verantwortlich.

Pakete werden als Dateien mit Tabs und dem Paketnamen angezeigt. Alternativ kann auch der Paketinhalt angezeigt werden (Abbildung 2.11).

2.2. Beziehungen 20

Mini-App

(von Java)+ Applet+ AppletStub+ AppletContext+ AudioClip

Abbildung 2.11: Das Java-Paket „Applet“.

2.1.4 Vorsichtsmaßnahmen

Benutzeroberfläche, siehe GUI.DOC

Abbildung 2.12: Beobachtung

UML kennt einen Haupttyp von Annotationen: Annotationen oder Annotationen. Anmerkungen können sowohl für Diagramme als auch für einzelne Modellelemente in UML bereitgestellt werden.

Anmerkungen werden als Rechtecke mit Ohren dargestellt (Abbildung 2.12), die zusätzliche Informationen zu einem oder mehreren Elementen enthalten. Anmerkungen können eine beliebige Kombination aus Text und Grafiken enthalten, beispielsweise Webadressen (URLs) oder Verweise auf Dokumentation. Annotationen geben dem Modellierer die Möglichkeit, dem Modell Informationen bereitzustellen, die in UML nicht oder nur schwer ausgedrückt werden können, der Informationsinhalt selbst jedoch keine UML-Semantik aufweist.

2.2 Beziehung

In UML gibt es vier Arten von Beziehungen: Abhängigkeit, Assoziation, Generalisierung und Realisierung. Es gibt weitere Variationen und Spezialisierungen dieser Arten.

2.2.1 Abhängigkeiten

Eine Abhängigkeit ist eine semantische Beziehung zwischen zwei Modellelementen, bei der Änderungen an der Spezifikation eines unabhängigen Elements Auswirkungen auf das abhängige Element haben. Einschränkungen werden durch gestrichelte Linien dargestellt, optional ausgerichtet und benannt (Abbildung 2.13).

21 Kapitel 2 Übersicht

Paket-A Paket-B

Abbildung 2.13: Paket A hängt von Paket B ab

2.2.2 Assoziationen

Assoziationen sind strukturelle Beziehungen zwischen Klassen. Es beschreibt eine Reihe von Objektbeziehungen, die durch eine gemeinsame Struktur und Semantik gekennzeichnet sind. Aggregationen sind spezielle Assoziationen, die „Ganzheitsbeziehungen“ beschreiben. Eine Assoziation wird als Linie dargestellt, die optional ausgerichtet und benannt ist und zusätzliche Bezeichnungen wie Kardinalität und Rollennamen enthalten kann (Abbildung 2.14).

Zeichensignatur*1..*

Arbeitgeber

*1..*

Abbildung 2.14: Eine Person (als Mitarbeiter) kann beliebig vielen Unternehmen zugeordnet werden. Dem Unternehmen muss mindestens ein Mitarbeiter (in der Arbeitgeberrolle) zugeordnet sein. In dieser Beziehung spielt ein Objekt der Klasse „Person“ die Rolle „Mitarbeiter“ und ein entsprechendes Objekt der Klasse „Unternehmen“ die Rolle „Arbeitgeber“. Der Rollenname „Arbeitgeber“ wird als Pseudoeigenschaft der Klasse „Person“ bezeichnet, da „Arbeitgeber“ als Merkmal einer Person angesehen werden kann.

2.2.3 Zusammenfassung

Generalisierung (auch Vererbung genannt) ist eine Beziehung zwischen einer allgemeinen Spezifikation eines Modellelements und einer spezifischeren Spezifikation, in der Instanzen (Instanzen) spezialisierter Elemente (Unterelemente, Unterelemente) durch Instanzen verallgemeinerter Elemente (Super) subsumiert werden -Elemente, Vater). Auf diese Weise „erben“ untergeordnete Elemente die Struktur und das Verhalten des allgemeineren Elements. Unterelemente können Struktur und Verhalten vorbehaltlich der Substituierbarkeit spezialisieren. Dieses Substitutionsprinzip stellt sicher, dass immer dann, wenn eine Instanz eines generischen Modellelements benötigt wird, auch eine Instanz eines spezifischeren Modellelements verwendet werden kann.

Eine Verallgemeinerung wird als durchgezogene Linie mit einem Dreieck am Ende dargestellt, das auf das allgemeinste Element zeigt (Abb. 2.15).

2.2. Beziehungen 22

Fenster

Standort

Öffnen ( ) Schließen ( ) Verschieben ( ) Anzeigen ( )

Dateiauswahlfeld für das Meldungsfeld

Abbildung 2.15: Verallgemeinerung: MessageBox und FileSelectionBox sind Unterklassen der Window-Klasse mit spezielleren Eigenschaften als die Window-Klasse, können aber überall dort verwendet werden, wo ein Window-Klassenobjekt erwartet wird.

2.2.4 Umsetzung

Eine Implementierung stellt eine semantische Beziehung zwischen Klassifikatoren (z. B. Klassen, Schnittstellen, Komponenten) dar, wobei ein Klassifikator etwas spezifiziert und der andere diese Spezifikation implementiert (Vertragsmerkmal). Implementierungsbeziehungen können zwischen Schnittstellen und Klassen/Komponenten oder zwischen Anwendungsfällen und Kollaborationen bestehen.

Realisierungen werden als gestrichelte Linien mit Dreieckseckpunkten dargestellt, die auf bestimmte Modellelemente zeigen (Abbildung 2.16).

es kann

Adresse

nicht speichernComputer()

kann aufbewahrt werden

nicht speichernComputer()

Abbildung 2.16: Implementierung: Die Klasse „Client“ implementiert die Schnittstelle „storable“. Die Implementierung besteht aus Abhängigkeiten (Klassen hängen von Schnittstellen ab) und Eigenschaftsübertragungen zwischen verwandten Elementen (Klassen „erben“ die Operationssignaturen von Schnittstellen). Als grafische Darstellung der Realisierungsbeziehungen wird der Schnittpunkt der Abhängigkeits- und Realisierungsbeziehungsdarstellungen gewählt.

23 Kapitel 2 Übersicht

2.3 Abbildung

Diagramme werden verwendet, um ein System aus einem bestimmten Blickwinkel und unter einem bestimmten Aspekt zu visualisieren. Einige Diagramme können in verschiedenen Ansichten verwendet werden (siehe 2.4), sodass daraus Beziehungen zwischen verschiedenen Ansichten modelliert werden können. Die folgenden neun Diagramme sind in UML definiert.

2.3.1 Anwendungsfalldiagramm

Ein Anwendungsfalldiagramm zeigt die Beziehung zwischen Anwendungsfällen und Akteuren. Ein Anwendungsfalldiagramm stellt eine statische Anwendungsfallansicht eines Systems dar, und Anwendungsfalldiagramme werden verwendet, um das Verhalten des Systems zu organisieren und zu modellieren. (Abbildung 2.17).

Anwendungsfälle beschreiben das Verhalten des Systems aus Sicht der Akteure (hauptsächlich Benutzer, aber auch andere Systeme), die sich in der Systemumgebung befinden und diese Anwendungsfälle nutzen (Abbildung 2.17). Ein Anwendungsfall wird durch einen Prozess beschrieben, der angibt, was das System tun soll, und nicht, wie der Anwendungsfall implementiert wird. Sie werden hauptsächlich zur Kommunikation zwischen Endbenutzern oder Experten im Bereich Systemanwendung und Systementwicklern verwendet.

2.3.2 Klassendiagramm

Klassendiagramme sind die am häufigsten vorkommenden Diagramme in der objektorientierten Modellierung. Ein Klassendiagramm (Abbildung 2.18) besteht im Wesentlichen aus einer Menge von Klassen, Schnittstellen und ihren Beziehungen. Ein Klassendiagramm zeigt eine statische Ansicht des Systemdesigns. Ein Klassendiagramm mit aktiven Klassen zeigt eine statische Prozessansicht des Systems.

2.3.3 Objektgraph

Ein Objektdiagramm ist eine Instanziierung von Modellelementen aus einem oder mehreren Klassendiagrammen. Es enthält Objekte und Links (Instanzen von Klassen oder Assoziationen) und zeigt eine statische Momentaufnahme des Systems an (Abbildung 2.19). Objektdiagramme dienen der Veranschaulichung von Klassen und Beziehungen.

2.3.4 Interaktionsdiagramm

Interaktionsdiagramme bestehen aus Objekten und zeigen, wie diese durch den Austausch von Nachrichten kommunizieren. UML bietet zwei semantisch äquivalente Interaktionsdiagramme, die jeweils unterschiedliche Aspekte hervorheben. Ein Sequenzdiagramm zeigt den Nachrichtenaustausch zwischen Objekten in chronologischer Reihenfolge (Abbildung 2.20).

23. Abbildung 24

Auftragsabwicklung

es kann

MA-Auftragsannahme

Datenbank

MA Buchhaltung

MA-Lager

Bestellung annehmen

Überwachen Sie die Zahlung

Waren ausliefern

Abbildung 2.17: Anwendungsfalldiagramm. Die Rechtecke symbolisieren die Grenzen des Systems.

25 Kapitel 2 Übersicht

Diagrammname: Neue Klasse DiagramChart Dateiname: KD-Order.VobChart Typ: UML Die Reihenfolge der Klassendiagramme ist immer eins

Kunden zugeordnet. als „Bestellung“ oder „Kunde“.

Diese besondere Form der Assoziation wird Komposition genannt und ist eine Aggregation, bei der der Teil (beste Position) von der Existenz des Ganzen abhängt.

BestDate bestellen: Datumsstatus: Zurück StatusTotalPrice( )

BestPositionmenge: Doublepreis: Double

NomedocienteactiveOrders()abgOrders()

Artikelname bestNrinfo

Enthalten 1 1..*

Bestellposition

0..1

0..*

Klient

Aktive Bestellung 0..*

0..1

außer Betrieb

es kann

0..*

Artikel

Beste Lage

Abbildung 2.18: Klassendiagramm

Kollaborationsdiagramme hingegen verdeutlichen die strukturelle Organisation interagierender Objekte (Abbildung 2.21). Die semantische Äquivalenz zweier Interaktionsdiagramme bedeutet nicht, dass beide explizit dieselben Informationen darstellen. Einige Informationen werden jeweils nur in einem Diagramm angezeigt. Beispielsweise wird in einem Kollaborationsdiagramm nicht explizit gezeigt, dass die Kontrolle an das Objekt zurückgegeben wird, aber die zugrunde liegenden semantischen Informationen sind für beide Diagramme gleich.

2.3.5 Zustandsdiagramm

Ein Zustandsdiagramm zeigt einen endlichen Automaten (siehe Abbildung 2.10, Seite 19). Statecharts dienen vor allem dazu, die Reaktion einer Klasse (genauer: Objekte einer Klasse) auf mögliche Ereignisse zu simulieren. Zustandsdiagramme werden nur für Klassen mit mehreren Zuständen gezeichnet. Es ist auch möglich, das dynamische Verhalten eines Systems (oder Subsystems) oder des Betriebs mithilfe von Zustandsdiagrammen zu modellieren.

In UML kann ein Zustand eine Zustandsmaschine sein, d. h. ein Zustand kann es sein

23. Abbildung 26

KdObj: Ja

Vorname = Schubert

BestObj-1:Ordnung

Mindesthaltbarkeitsdatum = 01.03.99, Status = Abgeschlossen

BestObj-2:Ordnung

Mindesthaltbarkeitsdatum = 25.05.1999 Bedingung = Kaufen

: Beste Lage

Menge = 1 Preis = 99,90

: Artikel

Name = UML – Benutzerhandbuch bestID = 3-8273-1486-0

: beste Lage : beste Lage

es kann

Aktive Bestellung abgOrder

Klient

es beinhaltet

Abbildung 2.19: Objektdiagramm basierend auf Klassendiagramm (Abbildung 2.18)

Hat Unterzustände (Abbildung 2.22). Es ist sogar möglich, einen Zustand aus einer gleichzeitigen Zustandsmaschine zusammenzusetzen.

2.3.6 Aktivitätsdiagramm

Ein Aktivitätsdiagramm ist im Wesentlichen ein Flussdiagramm, das auch gleichzeitige Abläufe enthalten kann. Aktivitätsdiagramme sind ein Sonderfall der Zustandsdiagramme, bei denen die Zustandsmaschine hauptsächlich aus sogenannten aktiven Zuständen besteht. In Aktivitätsdiagrammen findet das Verhalten im Gegensatz zu Zustandsdiagrammen innerhalb von Zuständen und nicht während Zustandsübergängen statt. 2. Zustandsübergänge in Aktivitätsdiagrammen erfolgen am Ende der Aktivitäten eines Zustands, d. h. das Ende einer Aktivität stellt ein Ereignis dar.

Aktivitätsdiagramme werden verwendet, um die Befehlsfolge von Operationen darzustellen oder

2A UML kann auch zur Modellierung von Zustandsmaschinen verwendet werden, die Aktivitäten innerhalb von Zuständen ausführen

27 Kapitel 2 Übersicht

: ... KdObj : Ja

BestObj-2:Ordnung

Neue Bestellung «Erstellen» Bestellung (KdObj)

definirDataAtual

setKunde(KdObj)

BestObj-2

addActiveBestellung(BestObj-2)

Abbildung 2.20: Interaktionen in einem Sequenzdiagramm

Diagrammname: Neues Kollaborationsdiagramm. Diagrammdateiname: KoD-Bestellung.VobChart. Typ: UML-Kollaborationsdiagramm

{Auto}

: ...

KdObj: Kunde BestObj-2: Bestellung

1: Neue Bestellung

{neu}

1.1: Ordnung (KdObj)

1.1.1: definirDataAtual

1.1.2: setKunde(KdObj)

1.2: addActiveBestellung(BestObj-2)

Abbildung 2.21: Eine Darstellung der Interaktion in Abbildung 2.21. 2.20 Zum Kollaborationsdiagramm. In diesem Diagrammtyp kann die zeitliche Reihenfolge der Nachrichten anhand sogenannter Sequenznummern identifiziert werden.

23. Abbildung 28

Diagrammname: New State Chart Diagrammdateiname: ZD-Bestellung.VobChart Typ: UML State Chart

positiv

Aufnahmeberechtigung

warte auf den Abschluss

verwendbar

Zusammenfassen

Aufnahmeberechtigung

warte auf den Abschluss

verwendbar

Zusammenfassen

Bestellung (Kunde)

autorisiert

völlig

veröffentlicht

am besten löschen

Bestellung stornieren/stornieren

Abbildung 2.22: Zustandsmaschine, wobei der „aktive“ Zustand eine Zustandsmaschine ist.

29 Kapitel 2 Übersicht

Neukunde?

Kundendaten anfordern und eingeben

Kundendaten durchsuchen

Überprüfen Sie das Kundenprofil

[ob]

[gegründet]

[nicht gefunden]

Abbildung 2.23: Dieses Aktivitätsdiagramm modelliert einen Prozess, der beispielsweise im Anwendungsfall „Bestellung eingeben“ ablaufen könnte.

2.4. Architektur und Landschaft 30

Modellieren Sie den Prozess im Anwendungsfall (Abbildung 2.23).

2.3.7 Komponentendiagramm

Ein Komponentendiagramm zeigt die Organisation und Abhängigkeiten einer Reihe von Komponenten. Da Komponenten Klassen implementieren, stellen Komponentendiagramme die Zuordnung von logischen Ansichten (Klassen) zu physischen Ansichten (Komponenten) (statische Implementierungsansichten) dar. Komponentenabhängigkeiten zeigen, ob sich Änderungen an einer Komponente auf andere Komponenten auswirken.

2.3.8 Bereitstellungsdiagramm

Ein Bereitstellungsdiagramm (auch als Bereitstellungsdiagramm bezeichnet) zeigt die physische Architektur von Hardware und Software (statische Bereitstellungsschichten). In einem Bereitstellungsdiagramm können Computer und andere Geräte sowie deren Verbindungen als Knoten (siehe Abbildung 2.8, Seite 18) und Linien visualisiert werden. Diesen Knoten sind normalerweise Komponenten (ausführbare Dateien) zugeordnet. Bereitstellungsdiagramme eignen sich zur Visualisierung verteilter Systeme.

2.4 Architektur und Ansichten

Die Komplexität der Analyse, Entwicklung, Implementierung, Dokumentation und Prüfung nicht-trivialer Softwaresysteme (kurz: Systementwicklung) erfordert die Betrachtung des Systems aus mehreren Perspektiven (z. B. Black-Box-Sicht oder Struktursicht). intern). Alle am Systementwicklungsprozess Beteiligten (Analysten, Designer, Tester, Benutzer, Projektmanager) betrachten das System zu unterschiedlichen Zeitpunkten aus einer bestimmten Perspektive (z. B. grobes Konzept oder detailliert). Architekturentscheidungen (siehe [BRJ99b], S. 31):

• Organisation von Softwaresystemen

• Auswahl von Strukturelementen und deren Schnittstellen zu Montagesystemen

• Verhalten und Zusammenarbeit von Elementen

• Kombinieren Sie diese Elemente zu größeren Subsystemen

Diese Architektur kann durch miteinander verbundene Ansichten beschrieben werden. Ansichten sind Abstraktionen, die Diagramme enthalten. Jede Figur betont wiederum einen bestimmten Aspekt. Dadurch entsteht ein Abbild (Modell) des Gesamtsystems. Ein UML-Entwickler hat die folgenden fünf Ansichten (siehe [EP98], S. 15): Use Case View, Logic View, Process View, Component View, Distribution View.

31 Kapitel 2 Übersicht

2.4.1 Anwendungsfallansicht

Die Use-Case-Ansicht beschreibt die Funktionalität des Systems. Diese Ansicht eignet sich für Kunden, Entwickler und Tester und wird durch Use-Case-Diagramme, Interaktionsdiagramme, Zustandsdiagramme und Aktivitätsdiagramme beschrieben. Die Anwendungsfallansicht ist für die Ansicht von zentraler Bedeutung, da ihr Inhalt die Grundlage für die anderen Ansichten bildet. Das Ziel der Systementwicklung besteht darin, die in der Anwendungsfallansicht beschriebene Funktionalität (mit Ausnahme nichtfunktionaler Attribute) zu implementieren. Diese Ansicht wird auch verwendet, um das fertige System anhand der erforderlichen Anforderungen und Prozesse zu validieren. Die statischen Aspekte dieser Ansicht werden durch Anwendungsfalldiagramme modelliert, und die dynamischen Aspekte werden durch Interaktions-, Zustands- und Aktivitätsdiagramme modelliert.

2.4.2 Logische Ansicht

Die logische Ansicht (Entwurfsansicht) beschreibt, wie die in der Anwendungsfallansicht identifizierte Funktionalität verfügbar ist. Diese Ansicht ist in erster Linie für die Verwendung durch Entwickler gedacht. Im Gegensatz zur Use-Case-Ansicht zeigt diese Ansicht die Interna des Systems. Es beschreibt die statische Struktur (Klassen, Objekte und ihre Beziehungen) und die Zusammenarbeit (Zusammenarbeit) von Systemelementen. Statische Strukturen werden durch Klassendiagramme und Objektdiagramme beschrieben, dynamische Ansichten werden durch Zustandsdiagramme, Aktivitätsdiagramme und Interaktionsdiagramme modelliert.

2.4.3 Prozessvisualisierung

Die Prozessansicht modelliert die Parallelitäts- und Synchronisationsmechanismen des Systems mithilfe von Prozessen und Threads. Diese Ansicht wird hauptsächlich zur Beschreibung der Systemleistung, Skalierbarkeit und des Durchsatzes verwendet. Die statischen und dynamischen Aspekte der Ansicht werden durch dasselbe Diagramm wie die logische Ansicht beschrieben, jedoch mit Schwerpunkt auf Aktivitätsklassen, da diese Prozesse und Threads darstellen.

2.4.4 Komponentenansicht

Die Komponentenansicht (Realisierungsansicht) stellt die vom System zusammengestellten Komponenten und deren Abhängigkeiten dar. Diese Ansicht beschreibt auch die Verwaltung von Releases. Statische Merkmale werden durch Komponentendiagramme dargestellt, und dynamische Merkmale werden durch Interaktionsdiagramme, Zustandsdiagramme und Aktivitätsdiagramme dargestellt.

2.5. Vierschichtige Metamodellarchitektur 32

2.4.5 Verteilungsvisualisierung

Die Verteilungsansicht (Bereitstellungsansicht) zeigt die physische Verteilung des Systems. Die Diagramme in dieser Ansicht simulieren, wie Systemknoten (Computer und andere Geräte) verbunden sind und welche Komponenten welchen Knoten zugeordnet sind. Diese Ansicht steht Entwicklern, Testern und Administratoren zur Verfügung und wird durch Bereitstellungsdiagramme dargestellt.

2.5 Architektur des vierschichtigen Metamodells

UML ist in einem Vier-Ebenen-Modell mit den folgenden Schichten (Abstraktionsebenen) definiert: Meta-Metamodell, Meta-Modell, Modell und Benutzermodell (siehe [OMG99], S. 2-5).

Anmerkung zur Ebenenbeschreibung

Meta-Meta-Modell

Diese Abstraktionsebene wird in einer formalen Sprache verwendet, um ein Metamodell zu spezifizieren.

spezifiziert den Begriff eines „Dings“, das alles darstellt, was definiert werden kann. Die auf dieser Ebene besprochenen Objekte heißen beispielsweise MetaClass, MetaObject und MetaAttribute. Die Semantik dieser Objekte wird auf dieser Ebene definiert.

Metamodell Eine Instanz von Meta-Metamodell. Diese Instanz definiert die Sprache, die zur Angabe des Modells verwendet wird.

Jedes Konzept auf dieser Ebene ist eine Instanz eines Meta-Metamodell-Konzepts. Objekte auf dieser Ebene sind beispielsweise Klassen, Attribute, Operationen, Komponenten. Mithilfe der auf der Meta-Meta-Ebene spezifizierten Sprache kann hier beispielsweise ermittelt werden, was eine Klasse ist. UML wird auf dieser Abstraktionsebene definiert.

33 Kapitel 2 Übersicht

Anmerkung zur Ebenenbeschreibung

Modell Eine Instanz eines Metamodells, das die Sprache definiert, die zur Beschreibung einer Informationsdomäne verwendet wird.

Diese Schicht besteht aus UML-Modellen. Diese Ebene enthält benutzerdefinierte Modellelemente wie Kunde, Kontostand abrufen.

Benutzermodell, Benutzerobjekt, Benutzerdaten

Eine Kopie des Modells. Es definiert einen bestimmten Informationsbereich.

Modelle auf dieser Ebene werden oft als Objekt- oder Instanzmodelle bezeichnet. Beispiele für Objekte auf dieser Ebene sind „Smith“ und „Müller“.

Das UML-Metamodell wird nicht durch eine Meta-Meta-Sprache beschrieben, sondern durch UML selbst, natürliche Sprache und formale Sprache (OCL, Object Constraint Language).

Diese vierstufige Architektur ermöglicht die Verbindung mit anderen vierstufigen Architekturen der OMG (Object Management Group), wie beispielsweise der OMG Meta-Object Facility (MOF).

2.6 Verlängerungsmechanismus

Die Erweiterungsmechanismen werden auf Metamodellebene beschrieben und sind daher Teil von UML, d. h. UML-Benutzer können diese Mechanismen nutzen, ohne die Existenz des Metamodells zu kennen. Im Metamodell werden drei Erweiterungsmechanismen beschrieben: Stereotypen, Attributwerte und Behauptungen.

2.6.1 Stereotypen

Stereotypen bieten die Möglichkeit, das UML-Vokabular zu erweitern. Ein Stereotyp kann als Metatyp betrachtet werden, anhand dessen UML-(Sprach-)Elemente auf einer höheren Ebene klassifiziert werden. Beispielsweise können Sie Klassen, die zu einer Benutzeroberfläche gehören, mit dem Stereotyp «GUI» kennzeichnen. „GUI“ bezeichnet dann eine Klasse mit besonderen Eigenschaften (z. B. existieren ihre Objekte nur zur Laufzeit), bestimmter Semantik und einer eigenen Notation (jeder Stereotyp kann durch eine eigene Notation dargestellt werden). Somit spezifiziert das Stereotyp „GUI“ einen anderen Klassentyp und gilt als Erweiterung des UML-Vokabulars. Da Prototypen auf vorhandenen Sprachelementen basieren, die im Metamodell definiert werden müssen, sind Erweiterungen über Prototypen weniger wahrscheinlich als tatsächliche Erweiterungen aus dem Metamodell.

2.6. Inflationsmechanismus 34

In ihrer einfachsten Form werden Stereotypen ins Französische übersetzt. Referenzen werden in Verbindung mit Basiselementen angezeigt. In Abbildung 2.3 wird eine Schnittstelle als Stereotyp einer Klasse dargestellt. Alternativ kann ein Archetyp durch ein dem Archetyp zugeordnetes Symbol dargestellt werden. Im Falle einer Schnittstelle ist dies ein „Lollipop“ (Abbildung 2.2).

2.6.2 Immobilienwert

Mit getaggten Werten können Sie UML-Modellelementen (einschließlich Prototypelementen) neue Attribute hinzufügen. Eigenschaftswerte sind Metadatenelemente. Sein Wert bezieht sich auf das Element selbst, nicht auf seine Instanz. In der einfachsten Form werden Attributwerte als in geschweifte Klammern eingeschlossene Zeichenfolgen unter dem entsprechenden Elementnamen dargestellt. Die Zeichenfolge besteht aus einem Namen (Token), einem „=“-Trennzeichen und einem Wert. Wenn dieser Wert eindeutig ist, ist er ausreichend.

Vorlagenelemente können beispielsweise mit „author“ getaggt werden, dessen Wert den Autor des Vorlagenelements angibt:

{Autor = Schubert}.

2.6.3 Notation

Mit Garantien (Constraints, Constraints) können Sie die Semantik von Modellelementen erweitern oder bestehende Regeln ändern. Behauptungen sind Bedingungen, die ein Modell erfüllen muss, um konsistent zu sein. sicherstellen

Menschen

Geschlecht Männlich Weiblich}

0..1

+Frau

+Ehemann

{self.wife.gender=feminino und self.husband.gender=masculino}

0..1

Abbildung 2.24: In OCL (Object Constraint Language) formulierte Behauptungen

Wird als Zeichenfolge dargestellt, die in geschweifte Klammern um das entsprechende Element eingeschlossen ist. Behauptungen können einen beliebigen Text enthalten. Assertions können auch als Ersatz für grafische Darstellungen verwendet werden (z. B. wenn das verwendete Tool keine grafischen Darstellungen unterstützt).

Kapitel 3

Metamodell

Das UML-Metamodell besteht aus etwa 90 Metaklassen, etwa 50 Stereotypen und mehr als 100 Metaassoziationen. Aufgrund dieser Komplexität ist das Metamodell hierarchisch in mehrere logische Pakete unterteilt (Abbildung 3.1), die jeweils verwandte Elemente enthalten.

Das Foundation-Paket definiert die Grundlagen von UML. Dieses Paket enthält die wichtigsten Strukturelemente (z. B. Klassen), grundlegende Verhaltensmerkmale (Operationen und Methoden) und Datentypen, die von UML verwendet werden. In diesem Paket sind auch UML-Erweiterungsmechanismen definiert.

Weitere Verhaltenselemente sind im Paket „Behavioral Elements“ definiert: Anwendungsfälle, Kollaborationen, Interaktionen, Zustandsmaschinen und Aktivitätsdiagramme.

Die Paketmodellverwaltung gibt beispielsweise an, wie Modellelemente in Paketen organisiert werden.

Im Rahmen dieser Arbeit werden die Grundpakete und Konzepte des Metamodells beschrieben. Neben dem Template-Management-Paket fehlt das Konzept von Templates, wie sie beispielsweise von C++ verwendet werden. Anwendungsfälle (Paketanwendungsfälle) werden nicht im Detail erläutert, da sie nur wenige oder keine formalen Informationen enthalten, die in anderen Diagrammen und Ansichten wiederverwendet werden können. Eine vollständige und maßgebliche Beschreibung finden Sie in [OMG99] oder in den folgenden neuesten Dokumenten, die auf der Homepage der UML Revision Task Force (RTF) (http://uml.systemhouse.mci.com) veröffentlicht wurden.

In den folgenden Abschnitten wird erläutert, welche Informationen auf der Metaebene erfasst werden müssen, bevor die Elemente des Metamodells definiert werden.

3.1 Grundlagen

Abbildung 3.2 veranschaulicht die Grundlagen von UML. Das Kernpaket definiert grundlegende Konzepte: Klassifikatoren (eine Verallgemeinerung von Klassen, Schnittstellen, Komponenten, Knoten und Datentypen), Strukturen und dynamische Funktionen

3.1. Stiftung 36

Verhaltenselemente

gemeinsames Verhalten

Kollaborationsanwendungsfall-Zustandsmaschine

Aktivitätsdiagramm

Vorlagenverwaltung

Base

Art der Daten

Zentraler Fördermechanismus

Abbildung 3.1: Aufteilung des UML-Metamodells in Pakete. Die nächstgelegenen Elemente werden in Taschen gruppiert. Das Model Management-Paket enthält keine anderen Pakete.

37 Kapitel 3 Das Metamodell

Basic

Art der Daten

Verlängerungsmechanismus

Abbildung 3.2: Basispaket und seine Abhängigkeiten

Klassifikatoren (Attribute, Operationen, Methoden) und Beziehungen (Assoziationen, Verallgemeinerungen, Abhängigkeiten) zwischen Modellelementen. UML-Erweiterungsmechanismen (Stereotypen, Behauptungen und Attributwerte) werden im Erweiterungsmechanismuspaket definiert. Das Paket „Datentypen“ definiert die Datentypen, die zur Definition von UML (auf Metamodellebene) verwendet werden. Instanzen dieser Datentypen werden von UML-Benutzern auf Modellebene verwendet.

3.1.1 Kern

Abschnitt 3.1.1.1 definiert die abstrakte Metaklasse, auf der andere Metaklassen basieren. Beispiele für abstrakte Metaklassen sind ModelElement, Feature und GeneralizableElement. Sie werden verwendet, um gemeinsame Merkmale von UML-Sprachelementen zusammenzufassen. Der Aufbau eines „Klassifikators“ (Klasse, Schnittstelle etc.) ist in Abschnitt 3.1.1.2 spezifiziert. Abschnitt 3.1.1.3 definiert Assoziationen und Verallgemeinerungen und Abschnitt 3.1.1.4 definiert Abhängigkeiten.

3.1.1.1 Struktur

In diesem Abschnitt werden zunächst die Begriffe Klasse und Generalisierung erläutert, da das Metamodell im Wesentlichen aus einer Hierarchie von Klassen besteht.

Vereinfacht ausgedrückt besteht UML aus grafisch dargestellten Modellelementen (z. B. Klassen, Beziehungen zwischen Modellelementen, Operationssignaturen). Die folgenden Erläuterungen und Beispiele zeigen die Komplexität der Beziehungen zwischen UML-Modellelementen, die ein UML-Metamodell enthalten muss.

3.1. Stiftung 38

Eine verallgemeinerte Klasse wird verwendet, um Eigenschaften, Operationen und Methoden1 zu deklarieren, die die Struktur und das Verhalten eines Objekts2 beschreiben. Die Generalisierung (Abbildung 3.3) ist eine Abstraktionsoption zur Beschreibung von Ähnlichkeiten zwischen Klassen anhand allgemeinerer Klassen unter Beibehaltung ihrer Unterschiede. Unter Generalisierung versteht man die Beziehung zwischen einer Klasse und einer oder mehreren spezialisierten Versionen dieser Klasse. Ein Diskriminator ist eine Eigenschaft einer Generalisierung, die Eigenschaften der Generalisierungsabstraktion beschreibt. Generalisierungsrelationen können zusätzliche Eigenschaften haben, wie zum Beispiel die disjunkte Behauptung in Abbildung 3.3. Eine spezialisierte Klasse wird als Superklasse bezeichnet, und jede spezialisierte Klasse wird als Unterklasse bezeichnet. Synonyme für Superklasse sind Basisklasse, Vorfahr, Superklasse und Superklasse. Synonyme für Unterklasse sind Nachkomme, Unterklasse, Kind.

Generalisierungsbeziehungen können auch zwischen anderen Modellelementen wie beispielsweise Schnittstellen bestehen. Die Bezeichnungen gelten entsprechend.

In Abbildung 3.3 ist ein Viereck die unmittelbare Oberklasse eines Parallelogramms sowie eine Oberklasse von Rechtecken und Quadraten. Parallelogramme hingegen sind direkte Unterklassen von Vierecken. Rechtecke und Quadrate sind weitere Unterklassen von Vierecken.

Bei der Modellierung werden Merkmale wie Attribute, Operationen und Mitgliedschaften in Assoziationen, die für eine Menge von Klassen gelten, Oberklassen zugewiesen und von einzelnen (Unter-)Klassen gemeinsam genutzt. Unterklassen „erben“ die Eigenschaften ihrer Oberklassen. Dieser Mechanismus wird als Vererbung bezeichnet. Vererbung und Generalisierung werden häufig synonym verwendet, wobei die Generalisierung sowohl die Beziehung als auch den Vererbungsmechanismus angibt. Weitere Synonyme für Generalisierung sind Spezialisierung und Erweiterung. Beispielsweise wird in der Java-Sprache das Schlüsselwort textends verwendet, um die Oberklasse anzugeben, von der eine Unterklasse erbt. Der Grund für die Verwendung des Begriffs „Erweiterung“ ist folgender.

In Abbildung 3.3 verfügt die GeomFigure-Klasse über Merkmale wie isVisible, Show usw. und ist der Point-Klasse zugeordnet. Alle Unterklassen von GeomFigure erben diese Eigenschaften.

In dieser Form der Assoziation werden punktuelle Objekte als abhängige Teile der Existenz der Geometrie betrachtet. Das bedeutet, dass Point eine Funktion von GeomFigure ist.

Square kann direkte Instanzen haben, das heißt, es kann eine konkrete Instanz einer Klasse geben, die nur Square-Merkmale hat (siehe auch Instanziierung, S. 41). Die Operation „computeArea“ ist in der Klasse „GeomFigure“ als „abstrakt“ gekennzeichnet, da sie nicht dazu gedacht ist, eine Operation zu implementieren, die die Fläche aller geometrischen Figuren berechnet. Daher kann ich nicht direkt Kontakt aufnehmen

1 Operationen und Methoden definieren die Verhaltensmerkmale von Objekten einer Klasse. Eine Operation deklariert die Signatur eines Verhaltensmerkmals und eine Methode implementiert dieses Merkmal.

2 In UML stellt ein Objekt eine Instanz einer Klasse dar.

39 Kapitel 3 Das Metamodell

Geometrie

Sichtbar: Boolesch

show()remove()moveRel(x : Integer, y : Integer)calculateArea()isVisible() : Boolean

Orientierung

x:integer:integer

getX(): Ganzzahl getY(): Ganzzahl

+ Punkt

Oval

show() delete() berechnearea()

Chris

Dreieck

show() delete() berechnearea()

Quadrat

show() delete() berechnearea()

Rechteck

Parallelogramm

Glück

Quadrat

figurative Form {Disjunkt}

Diskriminator

Behauptung: Eine Instanz der Oberklasse „GeomFigure“ kann höchstens einer Klasse ihrer unmittelbaren Unterklassen angehören, also nicht sowohl ein Dreieck als auch ein Viereck sein.

{Abstrakt}

{Zusammenfassung}{Zusammenfassung}

Abbildung 3.3: Bottom-up: Unterklassen lagern gemeinsame Funktionen an Oberklassen aus. Von oben nach unten erben Unterklassen die Eigenschaften ihrer Oberklassen. Daher wird diese Struktur auch als Vererbungshierarchie bezeichnet.

3.1. Stiftung 40

Stellt eine Instanz der GeomFigure-Klasse bereit, die aus diesem Grund als abstrakte Klasse bezeichnet wird. Unterklassen von GeomFigure können diese Operation implementieren. Beispielsweise erbt und implementiert die Square-Klasse die ComputeArea-Operationsdeklaration. Eine Klasse mit dieser Eigenschaft wird als konkrete Klasse bezeichnet. Eine direkte Instanz einer (konkreten) Klasse ist eine indirekte Instanz dieser Klasse und aller ihrer Oberklassen.

Das Grundprinzip, das zum Aufbau von Generalisierungsbeziehungen gilt, heißt Substitutionsprinzip: Immer wenn eine Instanz der Oberklasse benötigt wird, kann eine Instanz der Unterklasse verwendet werden. Dieses Prinzip ermöglicht es, Methoden für Oberklassen zu schreiben und diese Methoden auf Instanzen von Unterklassen anzuwenden. Nach diesem Prinzip können in Abb. 3.3 z. B. die Rechenbereichsoperationen der Quadrangle-Klasse so implementiert werden, dass sie für alle Instanzen der Unterklasse gelten.

Unterklassen können Methoden von Oberklassen überschreiben, indem sie Operationen mit derselben Signatur deklarieren. Zwei Operationssignaturen sind identisch, wenn die Operationen denselben Namen, denselben Rückgabetyp und dieselbe Anzahl und Reihenfolge der Argumenttypen haben. Beispielsweise überschreibt die Methode „calcuteSurface“ der Klasse „Square“ die Methode ihrer Oberklasse. Die Operationssignatur (Anzahl und Parameter der Operation und Rückgabetyp) darf jedoch nicht verändert werden. Wenn die Methode „calcureArea“ auf ein Objekt der Klasse „Quadrat“ angewendet wird, sorgt ein Mechanismus in der implementierenden Sprache dafür, dass die „richtige“ Methode auf das Objekt angewendet wird (Polymorphismus). Bedingungen, die Ressourcensignaturen (hier Operationen) bewahren, ermöglichen eine lokale Optimierung des Programmcodes innerhalb einer Klasse, ohne den Rest des Codes zu ändern. Daher sollten Merkmale nicht auf eine Weise ersetzt werden, die mit der Signatur oder Semantik des ursprünglich vererbten Merkmals unvereinbar ist. Eine Unterklasse ist eine Spezialisierung ihrer Oberklasse und muss in jeder Hinsicht mit dieser kompatibel sein.

Erweiterungen und Einschränkungen Unterklassen können den geerbten Funktionen neue hinzufügen. Dies nennt man Erweiterung (synonym mit Spezialisierung, siehe oben). Erweiterungen folgen dem Substitutionsprinzip. Beispielsweise kann eine Kreisform den Radius eines Features erweitern.

Ein Unterzweig kann auch das Vorfahrenmerkmal 3 einschränken oder einschränken (spezialisieren). Beispielsweise ist eine Erhebung auf einem Quadrat stärker eingeschränkt als eine Erhebung auf einem Rechteck. Diese Einschränkung ist in der gesamten Vererbungshierarchie konsistent, verursacht jedoch Probleme, wenn beispielsweise nicht skalierende Methoden für Grafiken eingeführt werden. Vielleicht gibt es also eine Möglichkeit, einen Punkt des Rechtecks zu verschieben. Wenn diese Methode auf ein Quadrat angewendet wird, kann es sein, dass das Quadrat seine „Rechteckigkeit“ verliert. so kann

3 In UML werden Einschränkungen als Behauptungen bezeichnet

41 Kapitel 3 Das Metamodell

Operationen/Methoden, die Klassenbeschränkungen verletzen, sind aus semantischen Gründen nicht zulässig. Einschränkungen bedeuten, dass eine Unterklasse in manchen Fällen nicht alle Operationen von ihrer Oberklasse erben kann. Diese Operationen müssen vom Designer spezifiziert werden (siehe [R+93], S. 78).

Deskriptoren und Vererbungsmechanismen Jedes Objekt wird durch einen vollständigen Klassendeskriptor beschrieben. Ein vollständiger Deskriptor enthält eine Beschreibung aller Attribute, Zuordnungen und Operationen, die eine Instanz enthält.

In einer objektorientierten Sprache wird die Beschreibung eines Objekts schrittweise aus mehreren Teilen gemäß einer Vererbungshierarchie aufgebaut. Jedes (verallgemeinerbare) Modellelement enthält eine Liste von Merkmalen und Beziehungen (Segmentdeskriptor), die zu den vererbten Merkmalen und Beziehungen hinzugefügt wird. Der Vererbungsmechanismus definiert, wie Deskriptoren aus Segmentdeskriptoren erstellt werden. Jedes Modellelement erbt Behauptungen. Klassen erben Attribute, Operationen, Methoden, Assoziationsmitgliedschaften usw. Der vollständige Deskriptor einer Instanz enthält die Vereinigung der Segmentdeskriptoren ihrer Klasse mit den Segmentdeskriptoren der Vorgängerklassen.

In einem Klassifikator kann kein Attribut in mehr als einem Abschnitt deklariert werden. Eine Methode kann in mehreren Threads deklariert werden. Eine Methode aus einem Thread überschreibt und überschreibt eine von einem Vorfahren deklarierte Methode mit derselben Signatur. Die Behauptungen des vollständigen Deskriptors folgen den Behauptungen der Vorfahren. Wenn die Garantien nicht übereinstimmen, stimmen auch die Modelle nicht überein. Für jede Methode in jeder Union des Segmentdeskriptors einer Klasse muss eine entsprechende Operation vorhanden sein. Bei konkreten Klassen muss jede Operation des vollständigen Deskriptors eine entsprechende Methode haben.

Das Instanziierungsmodell dient zur Beschreibung der möglichen Zustände des Systems und seines Verhaltens. Der Zustand eines Systems besteht aus Objekten, Werten und Verknüpfungen (Verbindungen). Instanziierung ist die Erstellung einer Instanz (oder Instanzen). Objekte sind Instanzen von Klassen, Werte sind Instanzen von Attributen und Links sind Instanzen von Assoziationen. Jedes Objekt wird durch einen vollständigen Klassendeskriptor beschrieben. Die diesem Deskriptor entsprechende Klasse ist die direkte Klasse des Objekts. Ebenso hat jeder Link eine direkte Zuordnung und jeder Wert einen direkten Datentyp. Eine Instanz ist eine direkte Instanz des Klassifikators (z. B. Klasse, Komponente), von dem der vollständige Deskriptor stammt. Instanzen sind indirekte Instanzen dieses Klassifikators und jedes seiner Vorgänger.

Der Dateninhalt des Objekts enthält den Wert jeder Eigenschaft des vollständigen Deskriptors. Der Wert muss mit dem Typ des Attributs übereinstimmen.

Verknüpfter Dateninhalt enthält eine Liste von Instanzen, die indirekte Instanzen enthalten

3.1. Stiftung 42

Die Ebene jedes beteiligten Klassifikators für den vollständigen Assoziationsdeskriptor (Abb. 3.4).

Quadrat1: Quadrat Punkt1: PunktChart Name: Neues DiagramChart-Objekt Dateiname: C:\Home\Stephan\vuml\objUntitled2.VobChart Typ: UML-Objektdiagramm

Abbildung 3.4: Visualisierung von Links. Quadrat1 ist eine indirekte Instanz von Quadrat, Rechteck, Parallelogramm, Viereck und GeomFigure

Ein Systemzustand ist ein gültiger Systemzustand, wenn jede Instanz eine direkte Instanz eines Systemmodellelements ist und die Instanz alle Modellzusicherungen erfüllt. Mithilfe der Verhaltenselemente der UML kann der effektive Zustandsablauf eines Systems beschrieben werden.

Klasse Eine Klasse deklariert Eigenschaften, Operationen und Methoden, die die Struktur und das Verhalten eines Objekts vollständig beschreiben. Alle Objekte in einer Klasse verfügen über Attributwerte und Operationen, die dem vollständigen Klassendeskriptor entsprechen.

Wenn eine Klasse instanziiert wird, um ein neues Objekt zu erstellen, wird das Objekt mit Attributwerten für jedes Attribut des vollständigen Klassendeskriptors initialisiert. Das Objekt wird außerdem mit Links aus der Methodenliste des Klassendeskriptors initialisiert und schließlich wird die Identität des neuen Objekts an den Ersteller übergeben. In einem gut strukturierten System ist die Identität jeder Instanz eindeutig und wird automatisch generiert.

Wenn eine Klasse als Wurzelklasse bezeichnet wird, kann sie keine Unterklasse einer anderen Klasse sein; wenn sie als Blattklasse bezeichnet wird, kann sie keine Oberklasse sein.

Der Gültigkeitsbereich (ownerScope) eines Klassenmerkmals gibt an, ob jedes Objekt seinen eigenen Wert für dieses Merkmal (Instanz) hat oder ob alle Objekte der Klasse (Classifier)4 nur einen Merkmalswert haben.

Jede deklarierte Eigenschaft einer Klasse hat eine Sichtbarkeit und einen Typ. Die Sichtbarkeit gibt an, ob das Attribut von Objekten anderer Klassen „gesehen“ und verwendet werden kann. Das Attribut kann für jede Klasse (öffentlich), nur für Unterklassen (geschützt) oder nur innerhalb der deklarierenden Klasse selbst (privat) sichtbar sein.

Der Typ einer Eigenschaft gibt den Bereich ihrer Werte an. Ein Attribut kann Standardwerte deklarieren und angeben, mit wie vielen Attributwerten (Kardinalität) jedes Attribut verknüpft ist. Die Veränderbarkeit von Eigenschaftswerten kann angegeben werden. Änderungen können uneingeschränkt (veränderbar), blockiert (eingefroren) oder eingeschränkt sein, sodass nur der Attributwert 5 hinzugefügt werden kann (addOnly).

4classifier entspricht „statisch“ in C++. 5, wenn die Kardinalität des Attributs > 1 ist.

43 Kapitel 3 Das Metamodell

Für jede Operation werden der Operationsname, die Parametertypen, der Rückgabetyp und seine Sichtbarkeit angegeben. Aktionen können die Angabe ihrer Auswirkungen umfassen. Diese Spezifikation kann auf unterschiedliche Weise beschrieben werden, z. B. über Vor- und Nachbedingungen, Pseudocode oder (beliebigen) Text. Sie können für eine Aktion festlegen, ob Ihre Anwendung den Zustand des Objekts (isQuery) ändert und ob diese mit anderen Methoden in Unterklassen implementiert werden kann.

Die Methode implementiert die Operation, hat dieselbe Signatur wie die Operation und implementiert den Hauptteil der Spezifikation. Jede Methode implementiert eine Operation, die für die Klasse oder einen Vorfahren der Klasse deklariert wurde. Eine Operation kann in den Segmentdeskriptoren einer Klasse und ihrer Vorgänger mehrfach deklariert werden. Die Operationsbeschreibung muss mit der Beschreibung im Segmentdeskriptor übereinstimmen, mit Ausnahme der generalisierten Attribute (isAbstract, isRoot, isLeaf) und isQuery-Attribute, die auf Nachkommen beschränkt sein können. Die Methode, die den Vorgang implementiert, muss dieselbe Signatur (Name, Parameteranzahl, Reihenfolge und Typ) wie der Vorgang haben und das isQuery-Attribut berücksichtigen.

Der Name einer Rolle in einer Assoziation relativ zu einer Klasse kann als Pseudoattribut dieser Klasse betrachtet werden. Geben Sie die Sichtbarkeit für diese Pseudoeigenschaft genau wie für normale Eigenschaften an. Um dieser Sichtbarkeit Rechnung zu tragen, werden Assoziationen von Unterklassen geerbt.

Eine Schnittstelle ist ein verallgemeinerbares Modellelement, das eine Sammlung von Operationssignaturen enthält. Klassen können Schnittstellen implementieren. Dies bedeutet, dass jede Operation des vollständigen Deskriptors der Schnittstelle im vollständigen Deskriptor der Klasse vorhanden sein muss und jede implementierte Schnittstelle dieselbe Signatur haben muss. Eine Schnittstelle kann von mehreren Klassen implementiert werden, d. h. die Operationen einer Schnittstelle werden in mehreren Klassen mit derselben Deklaration und Implementierungssignatur ausgeführt.

Eine Klasse kann andere Elemente wie Klassen, Schnittstellen und Bindungen enthalten und ist ein Namespace für diese Elemente. Was eine Klasse von einer anderen Klasse erbt, hängt von der Sichtbarkeit (öffentlich, geschützt, privat) der enthaltenen Elemente ab.

Nachfolgend werden die Backbone-Klassen (Abbildung 3.5) vorgestellt und erläutert.

Elemente Elemente (Abbildung 3.6) sind die atomaren Teile eines Modells. Im Metamodell ist Element die oberste Metaklasse in der Metaklassenhierarchie und Element ist eine abstrakte Metaklasse mit zwei unmittelbaren Unterklassen: ModelElement und PresentationElement.

3.1. Stiftung 44

Mann

Tonne

die allgemeine

Mund

isab

Le E

Lyme

Eingeben

ist R

Hey:

Wow

dünn

Insel

von :

Wow

dünn

es ist ein

bstr

Aktion:

Wow

dünn

Atr

Angezogen werden

elektronisch

Start

alV

Mut

irgendwas du willst

Das Ö

er weiß

Halter

Körper

ein Jahr

Zeitraum

Index

Antwort

rein

offen

Grund

konzentriert

Kaneko

neuer Westen

: Carl

lCon

aktuell

Kleber

verhältnismäßig

zeigen

Känguru

Tuberkulose

Anis

Blatt

:Zweite

Anis

Abdomen

Schiene

Tuberkulose

eins

+Spezifität

Seaver

Benehmen

Mann

ziehen

nas

modisch

alle

kompliziert

Elektronik: V

Treffen

Fähigkeit

verhältnismäßig

Name

Raum

Zentralkomitee

Ontario

Regen

Tonne

Körper

:Zweite

ein E

irgendwas du willst

Das Ö

Modul

Lyme

Eingeben

Name

Elektronik: Nein

Ami

0..1

+Name

Raum

0..1

+Stream

Unteres E

Lyme

HNO*

1..*

+con

Stella

ganze Zahl *

+con

Stella

hospitalisiert

Mann

Tonne

1..*

{Befehl

aufrecht

}

kauri

Verheiratet

Ralph

USW

Epoche

ist Q

Sehr

:Zweite

eins

Fea

Tula

Dono

rSco

Bewegungserziehung, Körpererziehung, Leibeserziehung :

sco

Sehr

Industrie

alle

kompliziert

Elektronik: V

Treffen

Fähigkeit

verhältnismäßig

Stärke

respektieren

Ralph

USW

Epoche

mehrere

typisch

Alter:

Multiplikator

typisch

jucken

Wut

kompetent

Thailändisch:

Tee

Enya

blass

Industrie

Förderung

Warten

Lidar

verhältnismäßig

Par

ganz

Das ist

Zweitklassig

Aurora

Mut

irgendwas du willst

Das Ö

Was

Entdecken:

Par

ganz

Direkte

Ion K

Industrie

0..1

+pa

an die Tür klopfen

Äther

{Befehl

aufrecht

} C

Mädchen

Identifikator

+Eisen

arrangieren

elektronisch*

{Befehl

aufrecht

}

+Stream

nell

+ty

Bewegungserziehung, Körpererziehung, Leibeserziehung

+ty

oder 1

Abbildung 3.5: Backbone: Diese Abbildung zeigt die häufigsten Klassen des Metamodells. Eine Klasse, deren Klassenname kursiv geschrieben ist, ist eine abstrakte Klasse. Instanzen konkreter Klassen sind Sprachelemente, die auf Modellebene sichtbar sind.

45 Kapitel 3 Das Metamodell

Element

Präsentationselement Modellelement

Vorname Vorname**

+Einführung

+ Thema

Abbildung 3.6 Elemente, die häufigste Klasse im Metamodell

Jedes Element verfügt über ein vordefiniertes Eigenschaftswertdokument: Eigenschaftswertsemantik

Dokumentation Ein Kommentar, eine Beschreibung oder eine Erklärung zu einem Element

Ein PresentationElement-Präsentationselement (Abbildung 3.6) stellt ein oder mehrere Modellelemente dar, die entweder textlich oder grafisch dargestellt werden. Die abstrakte Metaklasse PresentationElement ist die Basis für alle präsentationsspezifischen Metaklassen. (Undefinierte) Unterklassen von PresentationElement, die für die Verwendung durch Tools vorgesehen sind.

Im Folgenden wird der Funktionsname der zugehörigen Gegenklasse als Pseudoattribut bezeichnet.

Semantische Pseudoattribute

subject gibt das Modellelement an, das durch das Präsentationselement dargestellt wird.

ModelElement Ein Modellelement ist eine Abstraktion des zu modellierenden Systemelements. Die abstrakte Metaklasse ModelElement ist die Basis für alle zur Modellierung verwendeten Metaklassen.

Attributsemantik

der Name des Modellelements im Namespace

Semantische Pseudoattribute

Präsentation (Abbildung 3.6) stellt ein Präsentationselement dar, das ein Modellelement darstellt.

3.1. Stiftung 46

Semantische Pseudoattribute

Namespaces (Abbildung 3.7) geben Namespaces an, die Modellelemente enthalten. Bis auf das „Wurzelelement“ muss jedes Modellelement zu einem Namensraum gehören oder Teil eines anderen Modellelements (virtueller Namensraum) sein.

Einschränkung (Abb. 3.8) Eine Einschränkungsbedingung, die ein Modellelement erfüllen muss, damit das Modell gut definiert ist.

Modellelement

Vorname

Namensräume

0..1

+Attributelement *

+Namespace 0..1

Elementattribut

Sichtbarkeit: VisibilityKind

Abbildung 3.7: Namensräume

Namespace Ein Namespace (Abbildung 3.7) ist ein Modellelement, das eine beliebige Anzahl von Modellelementen enthält. Die Namen dieser Modellelemente (außer Assoziationen und Generalisierungen) müssen innerhalb ihres Namensraums eindeutig sein.

Jede Assoziation muss eine eindeutige Kombination aus dem Assoziationsnamen und den beteiligten Klassifikatoren sein. Jedes Modellelement gehört zu höchstens einem Namensraum.

Die zugehörige Klasse (siehe Abbildung 3.1.1.3) ElementOwnership 3.7 ist das Attribut, das ModelElement und Namespace zugeordnet ist. Gibt an, ob das Modellelement außerhalb seines Namespace sichtbar (öffentlich, geschützt, privat) ist.

Ein Namespace ist eine abstrakte Metaklasse, deren Unterklassen (z. B. Class) zusätzliche Einschränkungen hinsichtlich der Typen der darin enthaltenen Modellelemente haben.

Semantische Pseudoattribute

ownElement Das Modellelement, das zum Namespace gehört.

47 Kapitel 3 Das Metamodell

Einschränkungszusicherungen (Abbildung 3.8) sind Bedingungen oder Einschränkungen, die an Modellelemente geknüpft sind und durch Text (in beliebiger Formalität) beschrieben werden (siehe auch 3.1.2 Erweiterungsmechanismen). Im Metamodell gibt es eine

Einschränkung

Korpus: Boolesche Ausdrücke

Modellelement

Vorname

1..*

+Limit*

+element element1..*

{Befehl}

Abbildung 3.8: Bestätigung

ne Assertion Boolescher Ausdruck (Körper), der dem Modellelement zugeordnet ist. Wenden Sie die Behauptung an, wenn der Ausdruck „true“ ergibt. Ansonsten ist das Modell schlecht definiert. Versprechen Sie, mindestens ein ConstraintElement zu haben. Bestätigt, dass mehrere Modellelemente geordnet sind ({ordered}). Einem Modellelement kann eine beliebige Anzahl von Behauptungen zugeordnet werden. Ausnahme: Behauptung kann nicht auf sich selbst angewendet werden.

Die folgenden Behauptungsstereotypen sind in UML definiert, weitere können vom Benutzer hinzugefügt werden.

Stereotypensemantik

„Invariant“ ist eine Behauptung, die an mehrere Klassifikatoren und Beziehungen gebunden ist und immer gelten muss.

„Postcondition“ wird an die Behauptung einer Aktion angehängt und muss gültig sein, nachdem die Aktion ausgeführt wurde.

Eine „Vorbedingung“-Behauptung wird an eine Operation angehängt und muss gültig sein, bevor die Operation ausgeführt wird.

Generalisierbare Elemente Generalisierbare Elemente (Abbildung 3.9) sind Modellelemente, die an generalisierbaren Beziehungen teilnehmen können (siehe auch Abbildung 3.23, Seite 63).

3.1. Stiftung 48

gemeinsames Element

isRoot: BooleanisLeaf: BooleanisAbstract: Boolean

Modellelement

Vorname

Namensräume

0..1

+ Attributelement

+ Namensraum

0..1

Ressource

EigentümerScope:ScopeKindvisibility:VisibilityKind

Klassifikator

+ressource*{sortiert}

+Besitzer

Elementattribut

Sichtbarkeit: VisibilityKind

Abbildung 3.9: Generalisierbare Elemente und Klassifikatoren

Attributsemantik

isAbstract Wenn true, hat das generalisierbare Element keine direkte Instanz.

isLeaf Wenn true, darf das Element nicht weiter spezialisiert (vererbt) werden.

isRoot Wenn true, kann das Element keine Spezialisierung eines anderen Modellelements sein.

Klassifikatoren Klassifikatoren sind Modellelemente, die Verhaltens- und Strukturmerkmale beschreiben (Abbildungen 3.9, 3.10). Beispiele für Klassifikatoren sind Klassen, Schnittstellen und Komponenten.

Im Metamodell ist ein Klassifikator ein Namespace und ein generalisierbares Element, das Ressourcen enthalten kann. Als generalisierbares Element kann es Attribute (erben) und an Assoziationen teilnehmen. Ein Klassifikator kann Klassifikatoren (auch verschachtelt) innerhalb seiner Namespace-Kapazität enthalten. Andere Klassifikatoren können nur dann auf den enthaltenen Klassifikator zugreifen, wenn die Sichtbarkeit des Namensraums (Elementattribut) berücksichtigt wird.

Jedes Verhaltensmerkmal desselben Typs wie der Klassifikator kann nicht dieselbe Signatur haben. Der mit classifier7 verknüpfte Rollenname wird als Pseudoattribut verwendet.

6 Operationen und Methoden sind verschiedene Arten von Verhaltensmerkmalen 7 Gegenteil von Klassifikatoren

49 Kapitel 3 Das Metamodell

Aber visualisieren. Der in einem Klassifikator enthaltene Satz von Attributnamen, Pseudoattributnamen und Modellelementnamen muss eindeutig sein (dies schließt auch geerbte Modellelemente ein). Für jede als nicht abstrakt angegebene Klassifikatoroperation muss der Klassifikator eine Methode mit der angegebenen Signatur enthalten.

Es werden mehrere Stereotypen und Attributwerte für einen Klassifikator definiert:

Stereotypensemantik

Eine «Metaklasse» (Metaklasse) bezeichnet einen Klassifikator, dessen Instanzen Klassen sind.

Ein „Powertype“ (Metatyp) gibt einen Typ an, dessen Instanzen Untertypen eines anderen Klassifikators sind.

„Prozess“-Klassifikator, der Aktivitätsklassen und Prozesse darstellt. Ein Prozess kann gleichzeitig mit anderen Prozessen ablaufen und hat seinen eigenen Kontrollschwerpunkt.

„Thread“-Klassifikator, der aktive Klassen und Threads darstellt. Ein Thread kann gleichzeitig innerhalb eines Prozesses ausgeführt werden. Ein Thread hat seinen eigenen Kontrollschwerpunkt, aber keinen eigenen Adressraum.

„Utility“-Klassifikatoren (Dienstklassen, Utility-Klassen), deren Attribute und Operationen klassenbezogen sind ([BRJ99a], S. 148). Eine Hilfsklasse ist nicht wirklich eine Klasse, sondern eine Sammlung globaler Variablen und Funktionen, annotiert als Klasse ([Oes98], S. 230).

Attributwertsemantik

Ein Wert von Persistenz persistent (lateinisch: „persistent“) bedeutet, dass die Lebensdauer der Klassifikatorinstanz über die Laufzeit des Programms hinausgeht und persistiert werden muss. vorübergehend bedeutet nicht dauerhaft.

Semantik gibt die Semantik des Klassifikators an.

Features Ein Feature ist ein Attribut eines Klassifikators, beispielsweise ein Attribut oder eine Operation. Ein Merkmal (Abbildung 3.10) hat einen Namen, der es innerhalb eines Klassifikators oder einer Probe identifiziert. Ein Feature gehört nur einem Klassifikator (Eigentümer). AttributeownerScope gibt an, ob jede Instanz einen hat

3.1. Stiftung 50

Ein Klassifikator hat seinen eigenen Wert für dieses Feature. Wenn das Feature nur einen Wert hat, gilt dieser Wert für alle Instanzen dieses Klassifikators. Das Attribut Sichtbarkeit gibt an, ob andere Klassifikatoren die Ressource sehen und verwenden oder erben können. Ressource ist eine abstrakte Metaklasse.

Attributsemantik

OwnerScope-Instanz: Jede Klassifikatorinstanz hat ihren eigenen Attributwert. Klassifikator: Alle Instanzen eines Klassifikators haben nur einen Wert.

öffentliche Sichtbarkeit: Jeder andere Klassifikator (mit Sichtbarkeit für diesen Klassifikator) kann dieses Merkmal verwenden. geschützt: Jeder Nachkomme dieses Klassifikators kann dieses Merkmal verwenden. privat: Nur der Klassifikator selbst kann dieses Merkmal verwenden.

Modellelement

Vorname

Attribute

Anfangswert: Ausdrucksmethode

Körper: Prozedurausdruck

Betrieb

Gleichzeitig: CallConcurrencyKindisRoot: BooleanisLeaf: BooleanisAbstract: Boolean

*1*

+Spezifikationen

Verhaltensmerkmale

isQuery: BooleanStructuralFeature

Beschreibung:Multiplicitychangeability:ChangeableKindtargetScope:ScopeKind

Ressource

EigentümerScope:ScopeKindvisibility:VisibilityKind

Klassifikator

+Typ 1

+ Funktion

{order} + Ladenbesitzer

Abbildung 3.10: Ressourcen

51 Kapitel 3 Das Metamodell

StructuralFeature Strukturmerkmale (Abbildung 3.10) sind statische Eigenschaften von Modellelementen. Im UML-Metamodell (Version 1.3) ist Attribute die einzige Unterklasse von StructuralFeature. Strukturmerkmale haben eine Kardinalität (Multiplizität), die die Merkmalsnummer eines Modellelements angibt, beispielsweise kann das Merkmal „IP-Adresse“ eines Computers eine Kardinalität > 1 haben. Der Wertebereich für Strukturmerkmale wird durch den Typ (Kategorie) angegeben. Dieser Typ kann beispielsweise eine benutzerdefinierte Klasse auf Modellebene oder eine Instanz eines in UML definierten Datentyps sein (siehe 3.1.3). Veränderlichkeit gibt an, ob sich der Wert eines Merkmals ändern kann, nachdem die Instanz erstellt wurde. StructuralFeature ist eine abstrakte Metaklasse.

Attributsemantik

Die Multiplizität gibt die Häufigkeit des Merkmals an. Variablenveränderlichkeit: unbegrenzt (Standard)

eingefroren: Nachdem die Instanziierung abgeschlossen ist und der Wert initialisiert wurde, kann der Wert nicht mehr geändert werden. Es können keine weiteren Werte hinzugefügt werden. addOnly: Nur relevant, wenn Kardinalität > 1. Es können weitere Werte hinzugefügt, jedoch keine Werte geändert oder gelöscht werden.

targetScope-Instanz: (Standard) Jeder Wert enthält einen Verweis auf einen Typ.Classifier-Instanz: Jeder Wert enthält einen Verweis auf einen Klassifikator. Metadaten können auf diese Weise erhalten bleiben.

Semantische Pseudoattribute

Typ stellt den Wertebereich eines von einem Klassifikator beschriebenen Merkmals dar. Klassifikatorinstanzen bilden Attributwerte. Ein Klassifikator muss eine Klasse (Class), ein Datentyp (DataType) oder eine Schnittstelle (Interface) sein. Zur Laufzeit kann der aktuelle Typ auch ein Nachkomme sein. Zur Laufzeit ist der aktuelle Typ einer Schnittstelle der Klassifikator, der diese Schnittstelle implementiert, und der Typ muss sich im Namespace des Merkmalbesitzers befinden.

Attribute Attribute sind benannte Abschnitte in einem Klassifikator, die einen Wertebereich beschreiben. Im Metamodell ist ein Attribut Teil eines Klassifikators, der einen Namen hat (geerbt von ModelElement) und die möglichen Zustände einer Menge von Werten (Typen, geerbt von StructuralFeature) beschreibt, die eine Instanz des Klassifikators annehmen kann.

3.1. Stiftung 52

Attributsemantik

initialValue Ein Ausdruck, der den Wert der Eigenschaft zum Zeitpunkt der Initialisierung bestimmt.

Modellelement

Vorname

Verhaltensmerkmale

isQuery: Boolesch

Klassifikatorparameter

Standard: Ausdruckstyp: Parameterrichtungstyp

0..1

+parameter*{bestellt}

0..1

1 *

+Typ

1 *

Abbildung 3.11: Parameter

Verhaltensmerkmale Verhaltensmerkmale (Abbildungen 3.10, 3.11) sind dynamische Merkmale eines Klassifikators, beispielsweise Operationen oder Methoden. Die Eigenschaft isQuery gibt an, ob die Running/App-Ressource den Systemstatus unverändert beibehält. Verhaltensmerkmale können eine geordnete Liste von Parametern haben, die das Verhalten des Merkmals beeinflussen können. Die Argumente müssen unterschiedliche Namen haben und ihre Typen müssen zum Klassifikator-Namespace gehören. Eine Verhaltensressource verfügt über eine Signatur, die aus dem Namen der Verhaltensressource sowie der Anzahl, dem Typ und der Reihenfolge der Parameter besteht. BehavioralFeature ist eine abstrakte Metaklasse.

Attributsemantik

isQuery Wenn true, ändert die Anwendung der Ressource den Zustand des Klassifikators nicht, d. h. der Zustand des Systems bleibt unverändert. Markiert eine reine Funktion, also eine Funktion ohne Nebenwirkungen.

53 Kapitel 3 Das Metamodell

Semantische Pseudoattribute

Parameter Eine geordnete Liste von Parametern.

In UML sind zwei Stereotypen von Verhaltensmerkmalen definiert: Stereotypensemantik

„create“ erstellt eine Klassifikatorinstanz. „destroy“ zerstört eine Klassifikatorinstanz.

Operationen Operationen (Abbildung 3.10) geben die Dienste an, die eine Klassifikatorinstanz ausführen oder anfordern kann. Eine Operation verfügt über eine Signatur, die aus dem Operationsnamen (geerbt von ModelElement) und Parametern besteht.

Im Metamodell ist eine Operation ein Verhaltensmerkmal, das auf eine Instanz eines deklarierten Klassifikators angewendet werden kann.

Das Parallelitätsattribut gibt die Semantik gleichzeitiger Aufrufe derselben passiven Instanz an, die den überprüften Vorgang enthält. Eine aktive Instanz kontrolliert den Zugriff auf ihre eigenen Vorgänge.

Attributsemantik

Sequentielle Parallelität: Aufrufer von (sequentiellen) Operationen müssen sich außerhalb der Instanz koordinieren. Die Operation darf während der Ausführung nicht erneut aufgerufen werden. Dies gilt für alle sequentiellen Operationen einer Instanz, d. h. es dürfen nicht zwei verschiedene sequentielle Operationen gleichzeitig aufgerufen werden. Bei gleichzeitigen Aufrufen kann die Semantik und Integrität der Instanz (und damit des Systems) nicht gewährleistet werden. bewacht: (Geschützt) Ein Vorgang darf gleichzeitig von Instanzen gleichzeitiger Threads aufgerufen werden, es wird jedoch jeweils nur eine Anforderung verarbeitet. Der Rest wird verarbeitet, bis er blockiert wird, um den Vorgang abzuschließen. Die Verhinderung von Deadlocks liegt in der Verantwortung des Systementwicklers. Bei gleichzeitigen sequentiellen Vorgängen müssen die überwachten Funktionen korrekt ablaufen oder blockieren.

8 Eine Aktivitätsinstanz ist eine Instanz einer Aktivitätsklasse

3.1. Stiftung 54

Attributsemantik

Parallelität: Wie bei überwachten Vorgängen werden die Vorgänge nur in diesem Fall gleichzeitig ausgeführt. Gleichzeitige Vorgänge müssen so konzipiert sein, dass sie auch bei gleichzeitigen sequenziellen oder überwachten Vorgängen ordnungsgemäß ausgeführt werden.

isAbstract Wenn true, wird dem Klassifikator erklärt, dass er die Operation nicht ausführen soll. Der Vorgang muss von Nachkommen implementiert werden.

isLeaf Wenn true, kann diese Implementierung von keinem Nachkommen überschrieben werden.

isRoot Wenn true, kann die Klasse keine Deklarationen für diesen Vorgang mit derselben Signatur erben.

Methoden Eine Methode (Abbildung 3.10) ist die Implementierung einer Operation. Im Metamodell werden Methoden als Verhaltensmerkmale von Klassifikatoren bezeichnet und führen/implementieren Operationen (Körper). Methoden werden durch Operationen (Spezifikationen) spezifiziert. Eine Operation kann mehrere Methoden angeben. Operations- und Methodensignaturen müssen übereinstimmen. Wenn die Operation als „Abfrage“ markiert ist, muss die Methode eine reine Funktion sein (keine Nebenwirkungen). Die Sichtbarkeit der Methode muss mit der Sichtbarkeit der Operation übereinstimmen. Eine Operation muss ein Merkmal (geerbt) des Klassifikators sein, der sie implementiert. Wenn die Operation durch einen Vorfahren des Methodeneigentümers ersetzt wurde, muss die Methode die letzte Ersetzung implementieren.

Parameter Parameter (Abbildung 3.11) werden verwendet, um Verhaltensmerkmale des Klassifikators anzugeben. Im Metamodell beschreibt ein Parameter eine Deklaration von Parametern, die an eine Operation oder ähnliche Operationen übergeben werden. Jeder Parameter hat einen Namen (als Vorlagenelement). Typ gibt den Typ des Parameters (einen Klassifikator) an. Aus Sicht der Verhaltensmerkmale sind die Parameter geordnet (Liste).

Attributsemantik

Geben Sie Folgendes ein: Eingabeparameter, der Wert kann nicht geändert werden. out: Ausgabeparameter, der Wert kann geändert werden, um Informationen über den Anrufer bereitzustellen. inout: veränderbare Eingabeparameter. return: Rückgabeparameter.

defaultValue Ein Ausdruck, dessen Wert verwendet wird, wenn kein Argument übergeben wird.

55 Kapitel 3 Das Metamodell

Klassifikator

Klassenzimmer

isActive: Boolescher Datentyp

Portnummer Komponente

*+Bereitstellungsort

* + Einwohner

Modellelement

Vorname

+Umsetzung*

+Bewohner*

Element Residenz

Sichtbarkeit: VisibilityKind

Abbildung 3.12: Klassifikator

3.1.1.2 Klassifikatoren

In diesem Abschnitt werden Klassen, Schnittstellen, Datentypen sowie Knoten- und Komponentenklassifikatoren beschrieben. Andere Klassifikatoren (z. B. Anwendungsfälle) werden in anderen Metamodellpaketen beschrieben.

Klasse Eine Klasse ist eine Beschreibung einer Reihe von Objekten, die gemeinsame Attribute, Operationen, Methoden, Beziehungen und Semantiken aufweisen.

Attributsemantik

isActive true: Die Klasse ist aktiv, dh Objekte dieser Klasse steuern den Zugriff auf ihre eigenen Operationen und Eigenschaften. Dieses Objekt hat seinen eigenen Kontrollschwerpunkt und ist gleichzeitig mit anderen aktiven Objekten. false: (Standard) Die Klasse ist keine aktive Klasse.

isAbstract (geerbt von GeneralizableElement) true: Die Klasse kann nicht instanziiert werden.

3.1. Stiftung 56

Stereotypensemantik

Ein „Typ“-Typ ist eine Klasse, die eine Folge von Instanzen (Werteraum) und auf diese Instanzen anwendbare Operationen definiert. Typen können Eigenschaften und Assoziationen enthalten, jedoch keine Methoden.

«Implementierungsklasse»

Gibt eine Klasse an, die keinen Typ darstellt, sondern eine Implementierung einer Klasse in einer Programmiersprache. Eine Instanz kann höchstens einer implementierenden Klasse angehören. Dies steht im Gegensatz zu normalen Klassen, bei denen eine Instanz mehreren Klassen (sowohl statischen als auch dynamischen) angehören kann.

Schnittstelle Der Zweck einer Schnittstelle besteht darin, den Satz von Operationen für den vom Klassifikator bereitgestellten Dienst anzugeben. Schnittstellen bieten eine Möglichkeit, Gruppen von Operationen darzustellen.

Eine Schnittstelle ist eine Sammlung allgemeiner Operationen. Schnittstellen können nicht direkt instanziiert werden. Instanziierbare Klassifikatoren können Schnittstellen verwenden, um die verschiedenen von ihren Instanzen angebotenen Dienste zu spezifizieren. Mehrere Klassifikatoren können dieselbe Schnittstelle implementieren. Als generalisierbares Element kann eine Schnittstelle eine Spezialisierung einer anderen Schnittstelle sein und an einer Assoziation teilnehmen, solange die Assoziation nicht sichtbar ist (die Schnittstelle kann nicht herausnavigiert werden, siehe 3.1.1.3AssociationEnd). Beispielsweise kann eine Klasse einer Schnittstelle zugeordnet werden, die Zuordnung darf jedoch nur von der Klasse zur Schnittstelle navigieren9.

DataType Ein Datentyp ist ein Typ, dessen Wert keine Identität hat (reiner Wert). Zu den Datentypen gehören primitive Typen (z. B. Ganzzahlen, Zeichenfolgen) und aufgezählte (benutzerdefinierbare) Typen (z. B. boolesche Werte).

Im Metamodell ist DataType ein spezieller Klassifikator, der nur Operationen an reinen Funktionen enthalten kann.

Knoten Ein Knoten ist ein physisches Objekt, das Rechenleistung darstellt, normalerweise mit Speicher und Verarbeitungsleistung. Im Metamodell ist ein Knoten mit einer Reihe von Komponenten verknüpft, die sich auf diesem Knoten befinden (residieren).

Komponenten Eine Komponente ist ein physischer, austauschbarer Teil eines Systems. Es stellt einen Teil der Systemimplementierung dar, beispielsweise Quellcode, Bibliothekscode, ausführbares Programm oder Skript.

9 Die Bedeutung dieses Zusammenhangs bleibt den Autoren verborgen.

57 Kapitel 3 Das Metamodell

Eine Komponente kann keine anderen Komponenten enthalten. Eine Komponente kann nur Datentypen (resident), Schnittstellen, Klassen, Assoziationen, Abhängigkeiten, Behauptungen, Signale, Datenwerte und Objekte implementieren. Komponenten können sich in einem Knoten (deploymentLocation) befinden.

Für Komponenten sind mehrere Stereotypen vordefiniert:

Stereotype Semantik Eine „Dokument“-Komponente stellt ein „ausführbares“ Dokument dar. Eine Komponente stellt ein „ausführbares“ Dokument dar

Kann auf einem Knoten ausgeführt werden. Die Komponente „Datei“ stellt ein Dokument dar, das Daten enthält

oder Quellcode einschließen. Die Komponente „Bibliothek“ stellt eine (statische oder dynamische)

sche) Die Komponente „Tabelle“ der Bibliothek stellt eine Datenbanktabelle dar

3.1.1.3 Assoziation und Verallgemeinerung

Assoziationen deklarieren mögliche Verbindungen zwischen Instanzen assoziierter Klassifikatoren (z. B. Klassen) (links). Instanzen von Assoziationen (Links) bilden eine Menge von Tupeln, die aus Verweisen auf Assoziationsinstanzen bestehen. Eine Assoziation besteht aus mindestens zwei Assoziationsenden, die jeweils einem Klassifikator zugeordnet sind und die Behauptungen definieren, die erfüllt sein müssen, damit die Beziehung gültig ist. Das Kardinalitätsattribut an einem Ende einer Assoziation gibt an, wie viele Instanzen eines Klassifikators an einem bestimmten Ende der Assoziation (dem Ende, das die Kardinalität angibt) mit einer einzelnen Instanz des Klassifikators am anderen Ende verknüpft werden sollen (siehe Abbildung 3.13). Die Kardinalität ist eine Folge nicht negativer Ganzzahlen. Das Assoziationsende gibt außerdem an, ob der Link zur Instanz navigierbar ist, d. h. ob über die Assoziation auf die Instanz zugegriffen werden kann (siehe Abbildung 3.14 für ein Beispiel).

In einer Assoziation ist es möglich, die Menge der Merkmale einzuschränken, die eine Klasse in dieser Beziehung benötigt. Beispielsweise könnte eine „Person“-Klasse mehrere Schnittstellen implementieren und nur die Schnittstellen in der Assoziation bereitstellen, die zum Ausführen der Rolle erforderlich sind (Abbildung 3.15). Anstelle von Interfaces können auch Typen (Klassen mit dem Stereotyp «type») verwendet werden.

Zusätzliche Deklarationen auf Assoziationsseite geben an, ob der Linkage-Satz für die entsprechende Instanz auf Assoziationsseite geändert werden kann. Die Möglichkeiten sind:

1. Keine Garantie (kann geändert werden), dh Links können bei Bedarf hinzugefügt werden

10 Jedes Tupel erscheint höchstens einmal (Erweiterungsansicht)

3.1. Stiftung 58

Menschen

Name: Seil

Olt

Name: String0..*1..*

+Wohnort+Einwohner

0..*1..*

Papiertitel

Kardinalität

Abbildung 3.13: Beispiel einer binären Assoziation: Einer Person in der Rolle Bewohner können beliebig viele Wohnorte zugeordnet werden. Der Wohnort hat mindestens einen Einwohner. Die Zuordnung kann von beiden Seiten (entsprechend den Werkzeugkonventionen) navigiert werden.

Menschen

Name: Seil

Passwort

Name: String0..1

+Passwort

0..1

Abbildung 3.14: Eine navigierbare Richtungszuordnung einer Person zu einem Passwort.

Mitarbeiter

Manager

Menschen

1..1

0..*

+ Vorgesetzter: IManager

+Mitarbeiter: IEmployees

1..1

0..*

Abbildung 3.15: Funktionalität über eine Schnittstelle spezifizieren

59 Kapitel 3 Das Metamodell

Hinzufügen, löschen und ändern.

2. Nach der Initialisierung der Verbindung kann der Link weder geändert noch gelöscht (eingefroren) werden.

3. Neue Links können hinzugefügt, aber nicht geändert werden (addOnly).

Diese Behauptungen haben keinen Einfluss auf die Veränderlichkeit der Instanz selbst, die an das Ende des Links angehängt ist (die Instanz am Ende der Zuordnung).

Zusätzliche Deklarationen an einem Ende einer Assoziation können verwendet werden, um anzugeben, ob Instanzen an einem Ende der Assoziation in irgendeiner Weise relativ zu einzelnen Instanzen am anderen Ende der Assoziation angeordnet werden sollen (Abbildung 3.16). In diesem Fall muss bei Vorgängen zum Einfügen, Ändern oder Löschen von Links die Reihenfolge eingehalten werden. Link-Ranking ist eine Optimierung aus Performance-Gründen,

Menschen

Name: Seil

Olt

Name: String0..*

+ Adresse

0..*

{addOnly, sortiert nach Zeit}

Abbildung 3.16: Die verschiedenen Wohnorte einer Person in chronologischer Reihenfolge. Eine einmal begonnene Beziehung zwischen Mensch und Wohnort kann nicht aufgelöst werden. Die Auftragsart (z. B. aufsteigend) ist nicht festgelegt. Hinweis: Eine Person kann einem Ort nur einmal zugeordnet werden, d. h. Umzüge an einen früheren Wohnort können in dieser Vorlage nicht erfasst werden.

Dies ist jedoch kein Beispiel für eine logische Reihenfolge, da die Reihenfolge keine zusätzlichen Informationen enthält. Die „chronologisch geordnete“ Behauptung in Abbildung 3.16 ist ein Beispiel für eine benutzerdefinierte Behauptung, die der Bindung weitere Informationen hinzufügt und (auch) Auswirkungen auf die Implementierung hat. Eine Behauptung, die „alphanumerische Sortierung“ angibt, fügt der Bindung selbst keine Informationen hinzu, ist aber aus Sicht der Implementierung sinnvoll.

In UML gibt es drei Arten von Assoziationen:

1. Allgemeiner Verband

2. Aggregation (beschreibt die Hierarchie des gesamten Abschnitts)

3. Zusammensetzung (Aggregation, der Teil hängt von der Existenz des Ganzen ab)

Da Aggregatkonstrukte in verschiedenen Anwendungsdomänen unterschiedliche Bedeutungen haben, spezifiziert UML Assoziation und Zusammensetzung genau, lässt jedoch Raum für Interpretation im Aggregat.

3.1. Stiftung 60

Assoziationen können ganze Hierarchien von Teilen darstellen. In diesem Fall, in dem die Identität das gesamte Ende der Assoziation und das andere Ende den Teil des Aggregats darstellt, können nur binäre Assoziationen Aggregate sein. Komposition ist eine strenge Form der Assoziation, die erfordert, dass Instanzen von Teilen (Komponenten) jeweils zu höchstens einer Komposition gehören (Abbildung 3.17). Der Eigentümer einer Komponente kann jedoch geändert werden. Komposition bedeutet Übertragung von Semantik

Dokumentabsatz

0..*

Phrase

0..*0..* 0..*

Abbildung 3.17: Zusammensetzung: Die Existenz eines Teils (Komponente) hängt vom Ganzen (Zusammensetzung) ab.

(Spread-Semantik), also das Verhalten des Ganzen auf seine Teile zu übertragen. Wird beispielsweise das Ganze kopiert/gelöscht, gilt dies auch für seine Teile.

Persönliche Firma 0..* 1..*

+Arbeitgeber +Mitarbeiter

0..* 1..*

Abbildung 3.18: Aggregation: In diesem Modell werden Mitarbeiter als Teil des Unternehmens betrachtet.

(Normale) Aggregate unterliegen weniger Einschränkungen. Teile können zu verschiedenen Aggregaten (Ganzheiten) gehören und der Eigentümer eines Teils kann wechseln. Bei dieser Form der Aggregation bedeutet die Löschung des Ganzen nicht die Löschung seiner Teile (Abbildung 3.18).

Beide Arten von Aggregaten definieren transitive und asymmetrische Beziehungen. Ein Qualifizierer ist eine zugehörige Eigenschaft, deren Wert

Teilen Sie den Instanzsatz am anderen Ende. In dem Bild

persönliches Bankkonto

0..1ktoNr

+ kann

0..1

Abbildung 3.19: Teilnahmeberechtigte Mitglieder: maximal ein Kunde pro Kontonummer und Bank

3.19 ktoNr Partitioniert die Gruppe der Kunden, die einer bestimmten Bankinstanz zugeordnet sind. Eine Instanz oder ein Wert von ktoNr wählt den zugehörigen Client aus, falls vorhanden. In Abbildung 3.21 kann ein ktoNr-Wert mehrere Kunden auswählen. Da die Bankkopie nicht mit der Kopie dupliziert werden kann

61 Kapitel 3 Das Metamodell

Menschen

ktoNr: String-Bibliothek

0..* 0..*

+ kann

0..*0..*

Abbildung 3.20: Nicht teilnahmeberechtigte Mitgliedschaft: maximal eine Kontonummer pro Kunde und Bank

persönliches Bankkonto

0..*0..*

ktoNo+Kunde

0..*0..*

Abbildung 3.21: Berechtigte Mitglieder: Mehrere Kunden pro Konto und Bank, aber ein Kunde kann nur ein Konto pro Bank haben

Es kann ein Kunde 11 zugeordnet werden, und ein Kunde kann höchstens eine Kontonummer pro Bank haben.

Die Kardinalität, die die Zielseite der Assoziation (die zu teilende Seite) begrenzt, gibt die Anzahl der Zielinstanzen an, die die Quellinstanz auswählt, und begrenzt den Spezifikationswert. Gemeinsame Werte sind:

• „0..1“: Ein Grenzwertspezifikationswert wählt höchstens eine Zielinstanz aus, aber nicht jeder mögliche Wert wählt notwendigerweise eine Instanz aus.

• „1“: Für jeden möglichen Qualifier-Spezifikationswert wird genau eine Zielinstanz ausgewählt, daher muss der Bereich der Qualifier-Spezifikationswerte endlich sein.

• „*“: Der Qualifizierer unterteilt die Zielinstanz in Teilmengen. Schlagen Sie eine Implementierung vor, die über qualifizierte Werte auf eine Teilmenge von Instanzen zugreifen kann.

Die Kardinalität qualifizierender Aussagen wird durch die Annahme einer Unterstützung für qualifizierende Werte angegeben. Die reine Kardinalität einer Quellseite ohne qualifizierende Spezifikation wird üblicherweise mit „0..*“ angenommen, da der Fall der Kardinalität „1“ durch einfache Assoziation modelliert werden muss.

Die Qualifikation beider Seiten des Verbandes ist zulässig (seltener Fall). Es ist möglich, einen Klassifikator mehrfach zu qualifizieren (mehrere Assoziationen) und Assoziationen mit mehreren qualifizierenden Aussagen auf einer Seite bereitzustellen. Ein Beispiel finden Sie in [OMG99] (Seite 3-71).

Wenn zwischen zwei Klassen eine Assoziation besteht, kann die Assoziation selbst andere Eigenschaften haben. Zum Beispiel in einem Arbeitnehmer-Arbeitgeber-Verhältnis

11 Eine Assoziation ist eine Menge von Tupeln.

3.1. Stiftung 62

Ein Unternehmen und eine Person können Orte sein, um die Beziehung zwischen einem Arbeitnehmer-/Arbeitgeberpaar zu charakterisieren (Einstellungsdatum, Gehalt usw.). In UML kann diese Situation mit Assoziationsklassen modelliert werden (Abbildung 3.22). Assoziationsklassen sind Teil von Assoziationen und Modellen

feste Person

1..*0..*

+Mitarbeiter+Arbeitgeber

1..*0..*

Arbeiten

Gehaltseintragsdatum

Abbildung 3.22: Assoziationsklasse: Position ist eine Assoziationseigenschaft

Relevante Merkmale, die zum Verein selbst gehören. Assoziationsklassen können nur einer einzelnen Assoziation zugeordnet werden.

Abbildung 3.23 zeigt die Metamodellklassen, die Assoziations- und Generalisierungsbeziehungen darstellen.

Relationship Im Metamodell von Abbildung 3.23 ist Relationship eine abstrakte Klasse, die keine eigene Semantik hat und nur aus technischen Gründen existiert.

Assoziationen Assoziationen definieren strukturelle Beziehungen zwischen Klassifikatoren. Eine zugehörige (verknüpfte) Instanz ist ein Tupel entsprechender Instanzen (oder Verweise auf Instanzen) des Klassifikators. Eine Assoziation besteht aus mindestens zwei Assoziationsenden, die die Verbindung zwischen der Assoziation und dem Klassifikator bilden. Jedes Ende der Assoziation gibt eine Reihe von Eigenschaften an, die erfüllt sein müssen, um die Beziehung aufrechtzuerhalten (auf Modellebene). Der zugehörige Klassifikator muss im zugehörigen Namensraum enthalten sein.

Stereotype und Behauptungen werden definiert: Stereotypensemantik

„implizite“ Beziehungen sind implizit und nur aus rein konzeptionellen Gründen vorhanden. Beispielsweise wird eine Assoziation zwischen zwei Unterklassen impliziert, wenn ihre Oberklassen bereits verknüpft sind.

Behauptungssemantik

xor wird auf eine Reihe von Assoziationen angewendet. Es erfordert, dass für jede Assoziationsinstanz genau eine Assoziation gilt (Beispiel: Abbildung 3.28, Seite 72).

63 Kapitel 3 Das Metamodell

{Befehl}

Mitgliedschaftsstufe

Klassenzimmer

isActive: Boolescher Wert

gemeinsames Element

isRoot: BooleanisLeaf: BooleanisAbstract: Boolean

zusammenfassen

Diskriminator: Name*1

+ Verallgemeinerung

+ Kind

+ Kuchen

+ Spezialisierung

Verband

Attribute

Anfangswert: Ausdruck

Der Verein endet

isNavigable:Booleanordering:OrderingKindaggregation:AggregationKindtargetScope:ScopeKindmultiplicity:Multiplicitychangeability:ChangeableKindvisibility:VisibilityKind

2..* 1

+ verbinden

2..* 1

* 0..1

+ Qualifikanten

*{sauber}

+associationEnd

0..1

Klassifikator

1 *

+Typ

1 *

+ Teilnehmer

+Spezifikationen

Beziehung

Fluss

Modellelement

Vorname

+ Quelle

+Quelle*

+Ziel

+Ziel*

Abbildung 3.23: Assoziations-, Generalisierungs- und Flussbeziehungen

AssociationEnd Der Assoziationsendpunkt ist der Endpunkt der Assoziation und enthält die meisten Informationen der Assoziation. Jedes Assoziationsende ist Teil einer Assoziation. Der Name des Assoziationsendpunkts beschreibt die Rolle, die die Assoziationsklassifikatorinstanz in der Beziehung spielt. Unten Sekundärnamen in Abbildung 1. 3.24.

Ursprüngliches Ziel

galt als das Ende des Vereins

Abbildung 3.24: Sekundärname, der das Ende einer Assoziation erklärt

3.1. Stiftung 64

Attributsemantik

Name Der Name der Assoziationsendrolle. Gibt die Rolle an, die der Zielklassifikator in der Assoziationsbeziehung spielt. Der Funktionsname stellt eine Pseudoeigenschaft des Quellklassifikators dar, d. h. er kann auf die gleiche Weise verwendet werden wie die Eigenschaften des Quellklassifikators (unabhängig von der Sichtbarkeit, abhängig von der Navigationsfähigkeit). Daher müssen Funktionsnamen im Verhältnis zu den Attributen und anderen Pseudoattributen des Quellklassifikators eindeutig sein.

Aggregation keine: Diese Endung ist keine Aggregation. Aggregat: Der diesem Endpunkt zugeordnete Klassifikator (Ziel) repräsentiert die gesamte Aggregationsbeziehung. Der Ursprung muss den Wert „Keine“ haben. zusammengesetzt: Der diesem Ende zugeordnete Klassifikator stellt die gesamte zusammengesetzte Beziehung dar, und loin muss den Wert „none“ annehmen.

Die Veränderbarkeit gibt an, ob der Link vom Ursprung aus geändert werden kann (gemäß der Änderbarkeitseigenschaft des Attributs). Veränderlichkeitswerte werden als Assertions.changeable:unrestricted (Standard) ausgedrückt. addOnly: Links können aus der Quelle hinzugefügt, aber nicht geändert werden. eingefroren: Links können nicht hinzugefügt werden, nachdem das Quellobjekt erstellt wurde.

ungeordnete Reihenfolge: Links werden nicht geordnet (Standard) geordnet: Links werden geordnet (aber die Reihenfolge selbst ist nicht definiert) Zusätzliche Werte (z. B. geordnet) können in anderen Versionen definiert werden. Zusätzliche Werte können als Stereotypen definiert werden, die das entsprechende Tool unterstützen können.

isNavigable true: Die Quellendpunktinstanz kann auf die zugehörige Zielendpunktinstanz schließen (zum Ziel navigieren). Die Navigationsfähigkeit an einem Ende einer Assoziation ist unabhängig von der Navigationsfähigkeit am anderen Ende der Assoziation. false: Nicht durchsuchbar.

Die Multiplizität (Kardinalität) stellt die Anzahl der Zielinstanzen dar, die der Quellinstanz zugeordnet sind.

targetScope-Instanz: Der Link zeigt auf eine Instanz (Standard). Klassifikator: Der Link verweist auf einen Klassifikator.

65 Kapitel 3 Das Metamodell

Attributsemantik

Sichtbarkeit gibt die Sichtbarkeit des Endes der Assoziation aus der Perspektive eines Klassifikators an, der den Quellklassifikator „sehen“ kann. öffentlich: Andere Klassifizierer können Rollennamen in Ausdrücken durchsuchen und verwenden, d. h. Rollennamen können als öffentliche Attribute verwendet werden. vigate und Rollennamen in Ausdrücken verwenden privat: Nur der Quellklassifizierer kann Rollennamen in Ausdrücken durchsuchen und verwenden.

Semantische Pseudoattribute

Typ gibt den Klassifikator an, der dem Assoziationsende zugeordnet ist. Bei der Verknüpfung kann eine Klasse ein Nachkomme einer Quellklasse sein, und im Falle einer Schnittstelle kann sie eine implementierende Klasse sein.

Die Spezifikation stellt optionale Klassifizierer dar, die Vorgänge angeben, die auf Instanzen angewendet werden können, die über Assoziationen und Assoziationsenden eintreffen. Diese kanonischen Klassifikatoren bestimmen die Mindestschnittstelle, die die relevanten Klassifikatoren implementieren müssen. Dies können Typen (Klassen mit einem „Typ“-Stereotyp) oder Schnittstellen sein, die die Eigenschaften angeben, die Instanzen in dieser Hinsicht zur Verfügung stehen (siehe Abbildung 3.15).

qualifier stellt eine optionale Liste von Qualifizierern dar.

Wenn das gegenüberliegende Assoziationsende navigierbar ist, kann der Klassifikator des Assoziationsendes keine Schnittstelle oder kein Datentyp sein, d. h. es ist nicht möglich, die Schnittstelle oder den Datentyp zu verlassen.

AssociationClass Attribute binärer Assoziationen werden mit Assoziationsklassen modelliert. Dabei handelt es sich um Attribute, die nicht zum zugeordneten Klassifikator gehören, sondern zur Assoziation selbst.

Im Metamodell ist AssociationClass eine Unterklasse von Class und Association. Daher kann eine Assoziationsklasse Merkmale und Assoziationsbeendigung haben.

Die Namen der Assoziationsenden und die Namen der Strukturmerkmale (Eigenschaften) der Assoziationsklasse dürfen sich nicht überschneiden.

3.1. Stiftung 66

Generalisierung Generalisierung ist die Beziehung zwischen einem Superelement (übergeordnetes Element) und einem untergeordneten Element (untergeordnetes Element). In einem Metamodell ist eine Generalisierung eine Assoziation zwischen (verschiedenen) verallgemeinerbaren Elementen. Instanzen dieser Metamodellklassen beschreiben Vererbungshierarchien auf Modellebene.

Attributsemantik

Ein Diskriminator spezifiziert die durch eine Generalisierungsrelation abstrahierten Eigenschaften.

Stereotypensemantik

„Implementierung“ bezeichnet eine Verallgemeinerung, bei der ein spezialisiertes Element die Implementierung eines allgemeineren Elements erbt, aber keine Implementierung der Schnittstelle des allgemeineren Elements offenlegt und nicht garantiert wird, dass sie diese unterstützt. Dies verstößt gegen das Substitutionsprinzip der Generalisierung. Stereotype kennzeichnen eine „private“ Vererbung und machen meist nur unter Umsetzungsgesichtspunkten Sinn.

Behauptungssemantik

disjunkt Dies ist eine Standardverallgemeinerungsaussage. Eine Instanz des allgemeinsten Elements kann höchstens einen Nachkommen als Typ haben.

Überlappende Instanzen eines allgemeineren Elements können mehrere abgeleitete (direkte) Typen haben. Dies wird beispielsweise modelliert, wenn eine Instanz der Person-Klasse sowohl als Kunde als auch als Lieferant auftreten kann, d. h. eine Instanz kann ihre Klassenzugehörigkeit dynamisch ändern.

Unvollständig Dies ist die Standardbedeutung der Verallgemeinerung. Es werden nicht alle direkten Nachkommen angegeben, weitere können hinzugefügt werden.

Complete gibt alle unmittelbaren Nachkommen an, Extras sind nicht zulässig.

Fluss Ein Fluss ist eine gerichtete Beziehung zwischen zwei Versionen eines Elements (zu unterschiedlichen Zeitpunkten) oder zwischen einem Element und einer Kopie dieses Elements (Abbildung 3.25).

Ein Fluss kann auch eine Aktivität (siehe Abbildung 3.50, Seite 117) mit oder von einem Objektflusszustand oder zwei Objektflusszuständen verbinden.

67 KAPITEL 3. METAMODELLChart-Name: Neues AktivitätsdiagrammChart-Dateiname: actUntitled2.VobChart-Typ: UML-Aktivitätsdiagramm

Miller: Person [Angestellter]

Miller: Person [Manager]

Abbildung 3.25: Eine Ablauf- oder Flussbeziehung zwischen zwei Versionen eines Elements zu unterschiedlichen Zeitpunkten.

Stereotypensemantik

„become“ stellt eine Prozessabhängigkeit dar, deren Start- und Endpunkte dieselbe Instanz zu unterschiedlichen Zeitpunkten darstellen. Kombiniert zwei Versionen eines Artikels, die sich in Wert, Zustand, Standort oder Funktion unterscheiden.

„Replikation“ stellt eine Flussabhängigkeit dar, bei der Quelle und Ziel unterschiedliche Instanzen mit denselben Werten, Rollen und Status, aber unterschiedlichen Identitäten sind. Eine Replikationsabhängigkeit von A nach B bedeutet, dass B zu einem bestimmten Zeitpunkt eine exakte Kopie von A war.

3.1.1.4 Abhängigkeiten

In UML stellen Abhängigkeiten andere Beziehungen als Assoziationen, Verallgemeinerungen, Flüsse oder Metabeziehungen (Beziehungen zwischen Klassifikatoren und Instanzen) dar. In einer Abhängigkeit wirken sich Änderungen am unabhängigen Element auf das abhängige Element aus. UML definiert vier Arten von Abhängigkeiten:

• Eine Abstraktion ist eine Abhängigkeit zwischen zwei Elementen, die dasselbe Konzept darstellen.

• Berechtigungen gewähren einem Modellelement Zugriff auf einen anderen Namespace (z. B. ein Paket).

• Die Verwendung gibt an, dass ein Modellelement das Vorhandensein eines anderen Modellelements erfordert.

• Links sind Beziehungen zwischen Modellen und Modellelementen.

Abhängigkeit Im Metamodell (Abbildung 3.26) ist Abhängigkeit eine abstrakte Metaklasse, die über keine eigene Semantik verfügt und nur eine einseitige Beziehung zwischen abhängigen (Kunden) und unabhängigen (Lieferanten) Modellelementen darstellt.

3.1. Stiftung 68

verwenden

Erlaubnisabstraktion

Zuordnung: MappingExpression

darauf ankommen

Fesseln

Modellelement

Name: Name * 1..*

+ Lieferanten

+ lieferantenabhängig

1..*

*1..*

+Kunde

+ Client-Abhängigkeiten

1..*

0..1

1..*

0..1

+Parameter 1..*

Beziehung

Abbildung 3.26: Vier Arten von Abhängigkeiten in UML

Abstraktion Abstraktion ist eine Abhängigkeitsbeziehung zwischen zwei Elementen, die dasselbe Konzept auf unterschiedlichen Abstraktionsebenen oder aus unterschiedlichen Perspektiven darstellen.

Im Metamodell umfassen Abstraktionen Abbildungen zwischen Kunden (abhängig) und Lieferanten (unabhängig). Abhängig vom abstrakten Stereotyp können Zuordnungen informell oder formal sein und Abhängigkeiten können direktional oder bidirektional sein.

Die folgenden abstrakten Stereotypen sind in UML definiert:

Stereotypensemantik

„Ableiten“ von Abhängigkeiten Die abgeleitete Abstraktion besagt, dass abhängige Elemente aus Informationen unabhängiger Elemente berechnet werden können. Beispielsweise kann aus dem Geburtsdatum und dem aktuellen Datum das Alter einer Person berechnet werden. Der Graph spezifiziert (meist formale) Berechnungen.

69 Kapitel 3 Das Metamodell

Stereotypensemantik

„Abgeleitet“ (fort.)

Bei dieser Abstraktion sind die beteiligten Elemente nicht unbedingt vom gleichen Typ. Abhängige Elemente können implementiert werden, und obwohl die Implementierung logisch redundant ist, ist Effizienz häufig der Grund für die Implementierung.

«realisieren» Realisieren ist die Beziehung zwischen Spezifikationselementen (Anbietern) und Realisierungsmodellelementen (Clients), beispielsweise die Beziehung zwischen Schnittstellen und Klassen. Implementierende Elemente müssen das Verhalten von Spezifikationselementen unterstützen. Implementierende Elemente müssen die Deklarationen von Verhaltenselementen erben oder diese selbst angeben. Das Diagramm beschreibt die Beziehungen (nicht unbedingt berechenbar) zwischen Modellelementen. Implementierungen können zur Modellierung inkrementeller Verfeinerung, Optimierung usw. verwendet werden. Eine Implementierung verfügt über eine eigene grafische Notation (Schnittpunkt von Generalisierung und Abhängigkeit), die durch andere Stereotypen (noch (noch) nicht in UML definiert) genauer beschrieben werden kann.

«refine» Refinement ist eine abstrakte Beziehung zwischen Modellelementen unterschiedlicher Abstraktionsebene, z. Analyse und Design. Die Grafik beschreibt Zusammenhänge (nicht unbedingt berechenbar und vollständig). Eine Beschreibung des Diagramms kann als Notiz an die Beziehung angehängt werden. Abhängigkeiten können direktional oder bidirektional sein. Die Verfeinerung wird verwendet, um Übergänge (und andere Änderungen) zwischen Analyse und Design zu modellieren.

Ein „Trait“-Merkmal ist eine Abhängigkeit zwischen Modellelementen in verschiedenen Modellen, die jedoch dasselbe Konzept repräsentieren. Trace wird hauptsächlich verwendet, um Anforderungen und Änderungen zwischen Modellen zu identifizieren. Diese Art von Abhängigkeit muss vom Tool unterstützt werden. Da die Abhängigkeitsrichtung meist bidirektional ist, wird sie fast immer ignoriert. Das Diagramm beschreibt die Beziehungen zwischen Modellelementen meist informell.

Verwendung Verwendung ist eine Abhängigkeit, bei der ein Element andere Elemente benötigt, um erfüllt zu werden oder seine Funktionalität zu erreichen. Wie Abhängige Unabhängige nutzen, hängt von abhängigen Stereotypen ab

3.1. Stiftung 70

Abhängigkeiten definieren:

Stereotypensemantik

«call» Call ist eine Nutzungsabhängigkeit, deren Quelle und Ziel Operationen sind. Diese Beziehung kann auch auf die Klasse verweisen, die die Operation enthält. Abhängigkeit bedeutet in diesem Zusammenhang, dass es eine Operation für die Klasse gibt, die das abhängige Modellelement verwendet. Der Aufruf hängt von der angegebenen Quelloperation oder Operation in der Quellklasse ab, um die Zieloperation oder Operation in der Zielklasse aufzurufen.

„create“ stellt eine Abhängigkeit dar, bei der ein abhängiges Modellelement eine Instanz eines unabhängigen Modellelements erstellt.

Abhängigkeiten zwischen „instanziierten“ Klassifikatoren, was darauf hinweist, dass Operationen an abhängigen Elementen Instanzen unabhängiger Elemente erstellen.

«senden» Diese Verwendung hängt davon ab, dass die Quelle eine Operation und das Ziel ein Signal ist. Diese Beziehung besagt, dass die Quelle (Operation) ein Signal sendet oder senden kann. Signale werden in Abschnitt 3.2 Verhaltenselemente erläutert.

Berechtigungen Berechtigungen gewähren einem Modellelement das Recht, auf Elemente in einem anderen Namespace zuzugreifen. Abhängige Elemente müssen Namespaces sein, beispielsweise Klassen.

Stereotypensemantik

Eine „Zugriffs“-Abhängigkeit zwischen zwei Namespaces. Abhängige Namespaces können auf die gemeinsamen Teile unabhängiger Namespaces zugreifen.

Eine „Import“-Abhängigkeit zwischen zwei Namespaces. Abhängige Namespaces importieren gemeinsame Teile unabhängiger Namespaces.

Eine „Freund“-Abhängigkeit zwischen einem Modellelement (z. B. Operation, Klasse, Paket) und einem Modellelement (z. B. Operation, Klasse, Paket) in einem anderen Paket. Abhängige Elemente können unabhängig von der Sichtbarkeit auf unabhängige Namespaces zugreifen.

71 Kapitel 3 Das Metamodell

3.1.1.5 Kommentare

In UML können jedem Modellelement Anmerkungen, Annotationen oder Kommentare beigefügt werden. Annotation selbst hat in UML keine Semantik, enthält aber zusätzliche Informationen für den Modellierer.

Modellelement

Vorname

Kommentar

+Anmerkungselement*

Abbildung 3.27: Jedes Modellelement kann beliebig viele Anmerkungen bereitstellen.

Im Metamodell werden Kommentare durch classComment dargestellt, die ein direkter Nachkomme der abstrakten Metaklasse ModelElement ist (Abbildung 3.27).

Zwei Stereotypen für Kommentare/Kommentare sind vordefiniert:

Stereotypensemantik

«Anforderung» Anforderung: Eine erforderliche Eigenschaft, Eigenschaft oder ein erforderliches Verhalten eines Systems.

«Verantwortung» Verantwortung: Der Vertrag oder die Verpflichtung eines Elements.

3.1.2 Erweiterungsmechanismus

UML verfügt über integrierte Erweiterungsmechanismen, die für verschiedene Zwecke verwendet werden können:

• Neue Arten von Modellelementen hinzufügen.

• Definieren Sie ein Schema, das nicht interessant oder komplex genug ist, um als Metamodellelement definiert zu werden.

• Definieren Sie prozedur- oder sprachbezogene Erweiterungen.

• Fügen Sie Modellelementen beliebige Informationen mit spezifischer Semantik hinzu.

Der wichtigste Erweiterungsmechanismus ist das Konzept der Stereotypen. Stereotypen bieten eine Möglichkeit, Elemente auf Modellebene zu kategorisieren und das Hinzufügen von zu ermöglichen

3.1. Stiftung 72

Eine „virtuelle“ Metaklasse mit neuen Metaattributen und neuer Semantik. Markierte Werte und Einschränkungen basieren auf Eigenschaftslisten, mit denen Sie Modellelementen zusätzliche Eigenschaften und Semantik hinzufügen können.

gemeinsames Element

markierter Wert

Etikett: Name, Wert: Zeichenfolge

Modellelemente 0..1

0..1 + Tag-Wert

Stereotyp

Symbol: GeometrybaseClass:Name

0..1

+erforderliche Tags *

0..1

+ Stereotyp

0..1

+Erweiterungselement

Einschränkung

Korpus: Boolesche Ausdrücke

1..*

+constrainElement1..* {sortiert}

+ Grenze

0..1

+constrainedStereotype0..1

+stereotypeConstraint *

{Exklusiv oder}

Abbildung 3.28: Erweiterungsmechanismus

Prototypen Prototypen sind UML-Modellelemente, die zur Markierung oder Klassifizierung anderer UML-Elemente verwendet werden. Prototypelemente können als Instanzen neuer „virtueller“ oder „Pseudo“-Metamodellklassen betrachtet werden, die auf vorhandenen Metamodellklassen basieren. Stereotypen verbessern den Klassifizierungsmechanismus basierend auf der Klassenhierarchie des Metamodells. Daher müssen sich die Namen neuer Stereotypen von den Namen von Metamodellelementen oder anderen Stereotypen unterscheiden. Jedes Modellelement kann mit maximal einem Stereotyp markiert werden. Stereotypen können als Spezialisierungen anderer Stereotypen konstruiert werden. Stereotypen können zusätzliche Eigenschaftswerte und Aussagen sowie neue grafische Symbole definieren. Mit Stereotypen gekennzeichneten Modellelementen werden diese Attributwerte, Aussagen und Symbole zugewiesen. Stereotype Modellelemente erhalten die Attribute, Assoziationen und Operationen ihrer Basisklasse (aus dem Metamodell) und können zusätzliche Behauptungen definieren, die mit der Basisklasse konsistent sind, unterschiedliche Bedeutungen haben und ihre eigenen Attributwerte definieren. Instanzen eines Prototypelements haben die gleiche Struktur (Attribute, Assoziationen) und das gleiche Verhalten (Operationen) wie vergleichbare Nicht-Prototypelemente. Stereotypen können verwendet werden, um unterschiedliche Bedeutungen oder Verwendungen zweier Elemente mit derselben Struktur anzuzeigen.

73 Kapitel 3 Das Metamodell

Im Metamodell (Abbildung 3.28) ist die Stereotype-Metaklasse eine Unterklasse von GeneralizableElement. Stereotype Attributwerte und Behauptungen gelten für alle mit dem Stereotyp gekennzeichneten Modellelemente. Stereotypen können optional ein Symbol angeben, das zur Darstellung von Elementen des Stereotyps verwendet werden kann. Wenn ein Stereotyp ein Subtyp eines anderen Stereotyps ist, erbt er alle Eigenschaftswerte und Behauptungen vom Supertyp und beide Stereotypen müssen dieselbe Basisklasse haben.

Attributsemantik

baseClass gibt den Namen der UML-Metamodellklasse an, für die das Stereotyp gilt, beispielsweise Class, Association oder Constraint.

Symbol Eine geometrische Beschreibung des Symbols, das zur Darstellung des durch den Stereotyp markierten Elements verwendet wird (optional).

Semantische Pseudoattribute

ExtendedElement gibt die nach Stereotyp sortierten Modellelemente an. Jedes dieser Modellelemente muss vom durch baseClass angegebenen UML-Modellelementtyp sein.

Einschränkungen (von ModelElement geerbt) gelten für Behauptungen für den Volumenkörpertyp selbst.

stereotype Zwänge

Stellt eine Anweisung dar, die auf ein Trainingselement angewendet werden soll.

Der Attributwert „requiredTag“ (siehe unten) ist ein Tupel bestehend aus einem Tag und einem Wert. requireTag Gibt die Tags an, die Stereotypelemente haben müssen. Dieser Wert stellt den Standardwert für den Attributwert dar. Wenn der Wert nicht angegeben ist, muss das Stereotypelement den Wert definieren.

Die Namen von Attributwerten eines Stereotyps dürfen weder mit dem Meta-Eigenschafts-Namespace (Metaebene) der Basisklasse noch mit Tokens geerbter Stereotypen in Konflikt stehen.

Modellelemente Jedes Modellelement kann beliebige Attributwerte und Behauptungen haben. Ein Modellelement kann höchstens einen Stereotyp haben, dessen Basisklasse mit der UML-Klasse (z. B. Klasse) des Modellelements übereinstimmen muss. Stereotyp-Tags können verwendet werden, um implizite Aussagen zu Modellelementen bereitzustellen und die Angabe von Attributwerten zu erfordern.

3.1. Stiftung 74

Semantische Pseudoattribute

Ein Stereotyp stellt höchstens einen Stereotyp dar, der eine UML-Basisklasse für ein Modellelement weiter erweitert oder spezifiziert. Ein Stereotyp verändert die Struktur der Basisklasse nicht, kann aber zusätzliche Eigenschaftswerte und Behauptungen definieren, deren Semantik auf das stereotypisierte Element übertragen wird.

Die Einschränkung besagt, dass eine Instanz eines Modellelements wahr sein muss. Ein Modellelement kann mehrere Assertionen haben. Behauptungen werden ausgewertet, wenn sich das System im stationären Zustand befindet (z. B. außerhalb atomarer Operationen).

taggedValue Der Attributwert, der dem Modellelement zugeordnet ist. Die Bezeichnung ist der Name12 des Attributs und der Wert ist willkürlich. Die Interpretation von Attributwerten liegt außerhalb des Geltungsbereichs von UML. Ein Vorlagenelement kann mehrere Attributwerte haben und Tags müssen eindeutig sein.

Die Bezeichnung (eines Eigenschaftswerts), die einem Modellelement zugeordnet ist (direkt oder indirekt über einen Stereotyp), muss sich von der Metaeigenschaft unterscheiden, die dem Modellelement zugeordnet ist (Sie können Eigenschaftswerte als Pseudo-Meta-Eigenschaften interpretieren). Wenn ein Stereotyp einen Attributwert erfordert, diesen aber nicht angibt, muss das stereotypisierte Modellelement diesen Wert angeben.

Einschränkungen Das Konzept der Behauptungen (Einschränkungen) ermöglicht die Festlegung neuer Semantiken für Modellelemente. Spezifikationen können in Sprachen formuliert werden, die speziell für Behauptungen entwickelt wurden (z. B. OCL, Object Constraint Language), Programmiersprachen, mathematischer Notation oder natürlicher Sprache. Wenn ein Tool Behauptungen unterstützt, muss das Tool die Syntax und Semantik der Sprache verstehen.

Im Metamodell kann eine Einschränkung direkt an ein Modellelement (constrainElement) angehängt werden, d. h. eine Einschränkung wird auf eine Instanz eines Modellelements (z. B. eine Instanz der Customer-Klasse) angewendet. Versprechen können auch an Stereotypen (eingeschränkte Stereotypen) angehängt werden, d. h. das Versprechen wird dann auf alle mit diesem Stereotyp gekennzeichneten Elemente angewendet. Wenn das ConstraintElement einen Stereotyp darstellt, gilt die Behauptung für den Stereotyp selbst.

12taggedValue ist nicht als Unterklasse von ModelElement definiert, das heißt, es kann weder den Namen von ModelElement erben noch Aussagen enthalten.

75 Kapitel 3 Das Metamodell

Attributsemantik

body Ein boolescher Ausdruck, der die Behauptung definiert. Damit ein Modell wohldefiniert ist, muss der Ausdruck „true“ ergeben, wenn er anhand einer Instanz von „constraintElement“ ausgewertet wird. Ausdrücke werden nur ausgewertet, wenn sich das System im stabilen Zustand befindet.

TaggedValue Ein getaggter Wert ist ein Paar (Tag, Wert), das als zusätzliche Information an ein Modellelement angehängt werden kann. Ein Vorlagenelement kann mehrere Attributwerte haben, ein Platzhaltername kann jedoch nur einen Wert haben. Die Interpretation des Markups liegt außerhalb des Geltungsbereichs von UML und muss vom Benutzer oder durch Toolkonventionen bestimmt werden. Beispiele für Attributwerte sind Autor und Versionsnummer, was durch Tools automatisch erfolgen kann.

Attributsemantik

Tag beschreibt den Namen des angehängten Attributs. Tags sind Pseudoattribute von Modellelementen. Jeder Name eines Modellelements kann höchstens einen getaggten Wert haben.

Wert Ein Wert (willkürlich). Zur einheitlichen Verarbeitung durch Tools muss der Wert als String dargestellt werden. Der Wertebereich hängt von der Interpretation des Tags ab.

3.1.3 Datentypen

Im Metamodell werden Datentypen verwendet, um die Attributtypen von Metaklassen zu deklarieren. Von UML-Benutzern verwendete Datentypen sind Instanzen von Datentyp-Metaklassen (Abbildungen 3.29 und 3.30).

Ein primitiver Datentyp ist ein einfacher Datentyp ohne zugehörige Unterstruktur.

Semantik primitiver Datentypen

Ganze Zahlen Im Metamodell sind ganze Zahlen Mitglieder der (unendlichen) Menge von ganzen Zahlen.

UnlimitedInteger Ein Datentyp, dessen Wertebereich natürliche Zahlen umfasst, einschließlich „unbegrenzter“ Werte.

3.1. Stiftung 76

Semantik primitiver Datentypen

String Im Metamodell definiert String einen String beliebiger Länge.

Zeit Im Metamodell definiert Zeit einen Wert, der einen absoluten oder relativen Moment in Raum und Zeit darstellt. Der Wert hat eine Darstellung, die einer Zeichenfolge entspricht.

ursprüngliche Struktur

Art der Daten

aufzählen

Enum-Literal

Vorname

1..*

+char1..*

{Befehl}

Typ der Programmiersprache

Typ: TypeExpression

Abbildung 3.29: Datentypen (1)

Struktur Eine Struktur ist ein spezieller Datentyp, der eine feste Anzahl benannter Teile hat (ähnlich wie „Datensätze“).

Aufzählung Eine Aufzählung ist ein Datentyp, dessen Bereich eine Liste definierbarer Werte ist (Aufzählungsliteral). Die Liste definiert Atome (d. h. Elemente ohne Unterstrukturen), die auf Gleichheit getestet werden können.

Enum-Semantik

Die AggregationKind-Werte sind „none“, „aggregat“ und „composite“. Diese Werte stellen einen zugehörigen Aggregationstyp dar.

Boolesche Werte können wahr oder falsch sein.

77 Kapitel 3 Das Metamodell

Enum-Semantik

CallConcurrencyKind-Werte sind sequentiell, geschützt und gleichzeitig. Sie geben die Semantik der Parallelität von Operationen an.

ChangeableKind-Werte sind veränderbar, eingefroren und addOnly. Sie geben an, ob ein AssociationEnd, LinkEnd oder AttributeLink (ein Verweis auf eine Instanz) geändert werden kann.

Der MessageDirectionKind-Wert wird aktiviert und zurückgegeben. Sie geben die Richtung der Nachricht vor. (in der endgültigen Version von UML 1.3 veraltet)

Der OperationDirectionKind-Wert wird bereitgestellt und ist erforderlich. Sie geben an, ob der Klassifikator die Operation unterstützt oder ihre Anwesenheit erfordert. (in der endgültigen Version von UML 1.3 veraltet)

OrderingKind Gibt den Bestelltyp der Instanz am Ende der Zuordnung an.

Die Werte von ParameterDirectionKind sind in, out, inout, return. Sie geben an, ob der Parameter als Ein- und/oder Ausgabeparameter verwendet wird.

Die Werte für PseudostateKind sind „initial“, „deepHistory“, „shallowHistory“, „join“, „fork“, „branch“, „join“ und „final“. Beschreibt die möglichen Pseudozustände einer Zustandsmaschine.

VisibilityKind-Werte sind öffentlich, geschützt und privat. Sie geben an, ob Elemente eines Namensraums von außen sichtbar sind.

Programmiersprachentypen Programmiersprachentypen beschreiben Typen in der Syntax einer bestimmten Programmiersprache. Dieser Typ kann für programmiersprachenspezifische Deklarationen von Eigenschaften, Parametern und lokalen Variablen verwendet werden. TypeExpression ist eine Zeichenfolge, die diesen Typ definiert.

Zuordnungen Zuordnungen sind Ausdrücke, die zum Zuordnen von Modellelementen verwendet werden (siehe 3.1.1.4 Abhängigkeiten, 67). Aus Gründen der Austauschbarkeit sollte dies als Zeichenfolge dargestellt werden.

Name Im Metamodell definiert Name ein Tag zur Benennung von Modellelementen. Jeder Name verfügt über eine entsprechende Zeichenfolgendarstellung.

3.1. Stiftung 78

Aggregationstyp<>

Boolescher Wert<>

Veränderbar<>

Betriebsrichtungsklasse<>

Äußern

Idioma: Namebody: String

Name

Körper: Seil

Ganzzahl<>

Parameter DirectionKind<>

MessageDirectionKind<>

Bereichstyp<>

string<>

Rhythmus<>

Sichtbarkeit<>

Pseudozustandsklasse <>

CallConcurrencyKind<>

Mehrfachbereich

Untergeordnet: Ganzzahl Vorgesetzt: UnlimitedInteger

Vielzahl

Vermessung und Kartierung

Körper: StringUnlimitedInteger

Auftragsart<>

Standortreferenz

+ Reichweite

1..*1 1..*1

Abbildung 3.30: Datentypen (2)

79 Kapitel 3 Das Metamodell

LocationReference LocationReference (LocationReference) gibt einen Standort in einer Reihe von Verhaltensweisen zum Einfügen erweiterter Anwendungsfälle an. Dies könnte beispielsweise eine Codezeile oder ein Zustand aus einer Zustandsmaschine sein.

Multiplizität Im Metamodell definiert eine Kardinalität eine Menge nicht negativer Ganzzahlen (Ganzzahlen). Eine Menge, die nur Nullen enthält ({0}), ist keine gültige Kardinalität. Jede Basis hat (mindestens) eine entsprechende String-Darstellung. Ein Basisbereich (MultiplicityRange) definiert einen Ganzzahlbereich (Integer). Die Obergrenze kann nicht niedriger sein als die Untergrenze. Die untere Grenze muss eine nicht negative ganze Zahl sein, die obere Grenze kann den Sonderwert „unbegrenzt“ haben.

Boolescher Ausdruck

Äußern

Idioma: Namebody: String

ObjectSetExpression-Zeitausdruck

Aktionsausdruck

Iterationsausdruck

Typausdruck

ArgLists-Ausdruck

Mapping-Ausdruck, prozeduraler Ausdruck

Abbildung 3.31: Ausdrücke

Ausdrücke Ausdrücke (Abbildung 3.31) ergeben bei Ausführung in einem Kontext einen möglicherweise leeren Satz von Instanzen. Ein Ausdruck verändert nicht die Umgebung, in der er ausgewertet wird. Ausdrücke bestehen aus einem Namen, der die interpretierte Sprache (Sprache) angibt, die zur Auswertung des Ausdrucks verwendet wird, und einer Zeichenfolge, die den eigentlichen Ausdruck enthält (Hauptteil).

Ausdruckssemantik

Die ActionExpression-Auswertung führt zur Ausführung einer Aktion.

Der ArgListsExpression ergibt einen Satz von Objektlisten.

BooleanExpression Ein boolescher Ausdruck, der als wahr oder falsch ausgewertet wird.

Das Ergebnis der Auswertung von IterationExpression erzeugt ein Iterationskonstrukt in der durch Sprache angegebenen Sprache.

3.2. Verhaltenselemente 80

Ausdruckssemantik

MappingExpression Die Auswertung führt zu einem Mapping.ObjectSetExpression Die Auswertung führt zu einer Reihe von Instanzen

Boom. ObjectSetExpressions wird verwendet, um die Zielinstanz der Aktion anzugeben. Ein Ausdruck kann das reservierte Wort „all“ enthalten, wenn er als Ziel einer Sendeoperation verwendet wird (siehe 3.2.1.2). In die Auswertung werden dann alle Fälle einbezogen, in denen das Signal empfangen werden kann.

Das Ergebnis der Auswertung eines ProcedureExpression in einer Prozedurinstanz.

Die TimeExpression-Auswertung führt zu einer Instanz von Time.TypeExpression. Eine Zeichenfolge, die den Typ im Plan darstellt

Sprachdarstellung.

3.2 Verhaltenselemente

UML enthält Verhaltenselemente, die zur Darstellung der funktionalen und dynamischen Aspekte eines Systems verwendet werden können (Abbildung 3.32).

Kollaborationen (Paketkollaborationen) stellen eine Gruppe von Objekten dar, die eine bestimmte Funktion ausführen und zusammenarbeiten, um ein Verhalten zu zeigen, das größer ist als die Summe ihrer Teile. Eine Zusammenarbeit definiert einen Kontext, in dem Objekte Nachrichten austauschen, um eine bestimmte Aufgabe zu erfüllen. Der Austausch von Nachrichten zwischen Objekten kann in UML durch zwei verschiedene Interaktionsdiagramme dargestellt werden: Kollaborationsdiagramme und Sequenzdiagramme.

Kollaborationsdiagramme zeigen die strukturellen Beziehungen zwischen Objekten (Kollaborationen), auf deren Grundlage Nachrichtenaustausche (Interaktionen) stattfinden. Nachrichten werden zwischen den beteiligten Objekten gruppiert, d. h. Beziehungen und Kommunikation zwischen Objekten werden in den Vordergrund gerückt. Die chronologische Reihenfolge der Interaktionen steht im Hintergrund, ist aber anhand der Nummern der Nachrichten erkennbar

Ein Sequenzdiagramm beschreibt ein Szenario, in dem die Interaktionen von Objekten im Zeitverlauf geordnet dargestellt werden. Im Gegensatz zu Kollaborationsdiagrammen stellen Sequenzdiagramme die chronologische Reihenfolge in den Vordergrund und zeigen keine strukturellen Zusammenhänge.

Beide Arten von Interaktionsdiagrammen betonen den Kontrollfluss zwischen Objekten.

Ein Zustandsdiagramm ist eine grafische Darstellung eines endlichen Zustands

81 Kapitel 3 Das Metamodell

Use Case State Machine Collaboration

gemeinsames Verhalten

Aktivitätsdiagramm

Abbildung 3.32: Übersicht über das Verhaltenselementpaket

Tomaten (PaketStateMachines). Finite-State-Maschinen können verwendet werden, um das Verhalten eines Objekts (oder Systems) zu modellieren, dessen Verhalten von seiner Vergangenheit abhängt. Objekte können auf Ereignisse wie Signalereignisse oder Operationsaufrufe reagieren, die asynchron (normalerweise synchron) erfolgen. Wenn ein Ereignis eintritt, ist es möglich, basierend auf dem aktuellen Zustand des Objekts zu reagieren. Beispielsweise werden Finite-State-Maschinen verwendet, um die Reihenfolge einzuschränken, in der Operationen an Objekten aufgerufen werden. Sie werden zur Modellierung (dynamische Modelle) bei der Anwendung von Operationen verwendet. Ein Zustandsdiagramm zeigt den Kontrollfluss von einem Zustand in einen anderen, also den Kontrollfluss innerhalb eines Objekts oder Systems.

Aktivitätsdiagramme (packageActivityGraphs) zeigen den Kontrollfluss zwischen Aktivitäten. Aktivitätsdiagramme sind spezielle Zustandsdiagramme, deren Zustände in erster Linie aktive Zustände sind. Ein Aktivitätsdiagramm ist im Wesentlichen ein Flussdiagramm, das auch gleichzeitige Abläufe enthalten kann. Aktivitätsdiagramme werden verwendet, um komplexe Vorgänge zu beschreiben oder Anwendungsfälle zu verfeinern.

PackageCommonBehavior enthält die Infrastruktur für abhängige Pakete in Abbildung 1. 3.32. Das Paket definiert Objekte, Links und andere Instanzen, um die strukturellen Beziehungen sowie Signale und Operationen (z. B. Operationsaufrufe) zu modellieren, die von abhängigen Paketen benötigt werden.

3.2. Verhaltenselemente 82

3.2.1 Allgemeines Verhalten

Innerhalb des Systems kommunizieren Objekte durch das Senden von Nachrichten. Das Senderobjekt (Sender) sendet die Nachricht und das Empfängerobjekt (Receiver) empfängt die Nachricht. Nachrichten nutzen Links als Kommunikationskanäle, über die Nachrichten zwischen Objekten ausgetauscht werden. Meldungen können zusätzlich über Parameter spezifiziert werden. Konkrete Nachrichten (Kopien von Nachrichten) werden in UML als Stimuli bezeichnet.

Es gibt zwei grundlegende Arten von Nachrichten:

1. Ein Signal ist eine Nachricht zwischen dem initiierenden Objekt und allen Objekten, die das Signal zu diesem Zeitpunkt empfangen können. Bei einem Empfänger führt der Empfang eines Signals zu einer Zustandsänderung.

2. Ein Operationsaufruf ist eine Nachricht zwischen einem Absender (Anrufer) und einem bestimmten Empfänger, der eine gewünschte Operation ausführt.

Bei synchronen Nachrichten wartet der Sender darauf, dass der Empfänger die Verarbeitung der Nachricht abgeschlossen hat; bei asynchroner Kommunikation kann der Sender ohne Wartezeit parallel weiterarbeiten. Bei der sequentiellen Verarbeitung ist jeweils nur ein Objekt aktiv, während bei der parallelen Verarbeitung mehrere Objekte gleichzeitig (gleichzeitig) aktiv sind. Parallele Verarbeitung kann vorliegen, wenn das System auf mehrere Knoten (Prozessoren) verteilt ist. Als parallel gilt auch die pseudoparallele Verarbeitung mithilfe von Prozessen oder Threads auf einem Prozessor.

Zwischen Instanzen können unterschiedliche Arten von Anfragen (Anfragen oder Anforderungen) bestehen. Die Meta-Darstellung eines Signals, das asynchron eine Reaktion in einem Empfänger „auslöst“, wird in Abschnitt 3.2.1.1 erläutert. Die Definition von Operationsaufrufen und anderen Anforderungen, wie beispielsweise der Erstellung oder Zerstörung von Instanzen, wird in Abschnitt 3.2.1.2 erläutert. Abschnitt 3.2.1.3 beschreibt Instanzen von Klassifikatoren, Attributen, Assoziationen, Nachrichten, Komponenten und Knoten.

3.2.1.1 Signale

Signale Signale sind Anreizvorgaben für die asynchrone Kommunikation zwischen Entitäten.

Signale werden als Klassen mit dem Stereotyp «Signal» modelliert. Die Eigenschaften dieser Klasse sind die Parameter des modellierten Signals.

Im Metamodell (Abbildung 3.33) ist Signal eine Unterklasse von Classifier (und kann daher auch verallgemeinert werden) und Parameter werden als Attribute dargestellt (von Classifier geerbt). Die Instanziierung eines Signals führt zu einer bestimmten Nachricht (Stimulus).

83 Kapitel 3 Das Metamodell

Ausnahme

Empfang istPolymorph: Boolesche Spezifikation: String

Signalverhaltensmerkmale

0..*

+ Zeichen

+ Empfang

0..*

+ Kontext

+ Signalverstärkung

Klassifikator

Abbildung 3.33: Signale, Ausnahmen und Empfang

Ereignis (Signal) des Empfängers. Signale können mit Verhaltensmerkmalen des Senders (Kontext) und Verhaltensmerkmalen des Empfängers (Empfang) verknüpft werden.

Ausnahmen Eine Ausnahme ist ein Signal, das ein Klassifikator normalerweise sendet, um einen Fehler zu behandeln.

Im Metamodell ist Exception eine Unterklasse von Signal und kann einem Verhaltensmerkmal (Kontext) und damit einem Klassifikator zugeordnet werden, der dieses Signal aussenden kann.

Empfang Empfang ist eine Aussage darüber, dass der Klassifikator bereit ist, ein Signal zu empfangen und entsprechend zu reagieren. Reaktionen auf Quittungen werden durch Strings (Specs) kurz beschrieben. Eine Zustandsmaschine beschreibt Reaktionen auf empfangene Signale, die Änderungen im Zustand des Klassifikators (einer Instanz) bewirken.

Im Metamodell ist Reception eine Unterklasse von BehavioralFeature, die die Attribute isAbstract, isLeaf und isRoot erbt. Wenn die Eigenschaft „isPolymorphic“ den Wert „false“ hat, ist die empfangene Antwort immer „false“.

3.2. Verhaltenselemente 84

Gleiches gilt z. B. wenn das empfangende Replikat nur Signale eines Zustands empfangen kann, also keine Vergangenheit hat. Andernfalls hängt das Verhalten möglicherweise vom Status der empfangenden Instanz ab.

3.2.1.2 Aktionen

动作是导致系统状态改变的可执行原子处理。不同类型的动作（图 3.34）是发送信号（SendAction）、调用操作（CallAction）、创建（CreateAction）、自毁（TerminateAciton）和销毁（DestroyAction）一个实例、分配一个值（AssignmentAction）和一个值的返回（ReturnAction）。

Aktionen Eine Aktion kann einen oder mehrere Empfänger einer Nachricht (targetSetExpression), ihre Parameter (real) und die Art der Kommunikation (isAsynchronous) angeben. Die Eigenschaft recurrence ist ein iterativer Ausdruck, der angibt, wie mit Empfängern umgegangen wird oder wie oft Nachrichten gesendet werden. Aktion ist eine abstrakte Metaklasse.

Das Ausführen einer Aktion bedeutet die Bewertung von Metaeigenschaften, was normalerweise zum Senden eines oder mehrerer Reize führt.

Attributsemantik

isAsynchronous gibt an, ob die Nachricht (oder der Stimulus) asynchron ist.

Wiederholung Ein Iterationsausdruck, der angibt, wie oft die Operation ausgeführt wird.

target Ein TargetSetExpression, der eine möglicherweise leere Menge von Instanzen ergibt, die Empfänger (Stimuli) der Nachricht sind. In UML ist nicht definiert, ob Aktionen sequentiell oder parallel auf ihre Ziele angewendet werden.

Skript Ein Ausdruck, der die Wirkung einer Aktion beschreibt.

Semantische Pseudoattribute

real enthält eine Argumentliste mit Ausdrücken, die die Argumente (Instanzen) angeben, die bei der Ausführung der Operation verwendet werden sollen.

85 Kapitel 3 Das Metamodell

Tun

Troja

Aktion

rein

Universität

Eingeben

Gegenteil

Ada

Roman

Modul

Lyme

Eingeben

Kerry

an der Tür

Roman

Siliziumkarbid

Mädchen

Identifikator

0..*

10.

+em

Stan

erziehen

ausscheiden

eine Urne

Roman

Also

Hartnäckig

E-Rechnung

rein

bei diesem

Fogo

entA

Roman

Kalibrierung

bis 1

rein

offen

Grund

*1*

+Betrieb

Epoche

rein

Holz

Rechnung

rein

erklären

Finale

*1*

+ Simulation

Antrieb

Parameter

eine Frau

Tonne

Mut

Harmonie

irgendwas du willst

Das Ö

Aktion

Ion

Pferd

Enns

Aktion

rein

0..1

+Kommunikation

aktuell

{Befehl

aufrecht

}

0..1

+Kommunikation

Hund

{Befehl

aufrecht

}

Abbildung 3.34: Aktionen

3.2. Verhaltenselemente 86

Aktionssequenz Eine Aktionssequenz ist eine geordnete Folge von Aktionen, die nacheinander als atomare Einheit ausgeführt werden. Es wird verwendet, um Zustandsaktionen oder Übergänge in einer Zustandsmaschine zu beschreiben.

CreateAction Eine Erstellungsaktion ist eine Aktion, die eine Klassifikatorinstanz erstellt. Im Metamodell ist CreateAction eine Unterklasse von Action, die einem Klassifikator zugeordnet ist. Für den Erstellungsvorgang ist kein Ziel oder Empfänger durch das Ziel angegeben. Der zu instanziierende Klassifikator wird durch die Pseudoeigenschaft „instanziieren“ angegeben.

DestroyAction Die Destroy-Aktion bewirkt, dass die Instanz zerstört wird. Die zugehörige Instanz wird durch die Zieleigenschaft der Operation angegeben. Der Zerstörungsvorgang hat keine Parameter.

TerminateAction Die Beendigungsaktion führt zur Selbstzerstörung der Instanz. Das Ziel der Anweisung ist die Instanz, die die Operation implizit ausführt, d. h. es gibt kein explizites Ziel.

CallAction Eine Call-Aktion ist eine Aktion, die eine Aktion für eine Instanz aufruft. Aufrufe können synchron oder asynchron sein. Die Instanz oder der Satz von Instanzen wird durch das Zielattribut angegeben, die Argumente werden durch die tatsächliche (geerbte) Pseudoeigenschaft angegeben und die aufzurufende Operation wird durch die Pseudoeigenschaftsoperation angegeben. Die Anzahl der Parameter muss mit der Anzahl der Betriebsparameter übereinstimmen. Es besteht keine Notwendigkeit, Parametertypen mit Parametertypen abzugleichen! Dadurch können Parameter auf verschiedene Weise an Aktionen übergeben werden (siehe Seite 174).

ReturnAction Eine Return-Aktion ist eine Aktion, die einen Wert an den Aufrufer zurückgibt. Im Metamodell werden Werte durch von Action geerbte Parameter dargestellt. Eine Rückrufaktion hat kein explizites Ziel. Das implizite Ziel dieser Aktion besteht darin, die Instanz zu aktivieren, beispielsweise um eine Operation aufzurufen, die eine Folge von Aktionen aktiviert, die von der Rückrufaktion ausgeführt werden sollen.

AssignmentAction Eine Zuweisungsaktion ist eine Aktion, die einem Link oder Attributlink (einer Instanz eines Attributs) einen Wert zuweist. Im Metamodell werden zugeordnete Instanzen (Werte) durch Operationsparameter spezifiziert.

87 Kapitel 3 Das Metamodell

Zuweisungsaktionen verfügen über (nicht explizit dargestellte) Pseudoeigenschaften und Eigenschaftszuordnungen (siehe Abbildung 3.36)13. Sie geben die Assoziation an, der der Link zugeordnet ist, bzw. das Attribut, dem der Attributlink zugeordnet ist.

SendAction Signalisiert das Ende einer Aktion. Signale sind immer asynchron. Ein Signal kann an einen bestimmten Empfänger oder an eine nicht spezifizierte Gruppe von Empfängern (viatarget) gesendet werden. Wenn das Ziel jeder ist, senden Sie das Signal an alle Objekte, die das Signal empfangen können. Handelt es sich bei dem Signal beispielsweise um eine Ausnahme, wird der Empfänger durch den Laufzeitsystemmechanismus bestimmt.

SignalSendAction + Signal

* 1 * 1

Abbildung 3.35: Aktion senden

Im Metamodell (Abbildung 3.35) ist SendAction mit dem zu sendenden Signal verknüpft, und die Parameter werden durch die von Action geerbten echten Pseudoeigenschaften angegeben. Durch die Ausführung einer Sendeoperation wird ein Signal mit den angegebenen Parametern (Stimuli) instanziiert.

Die Anzahl der Parameter muss mit der Anzahl der Parameter (Eigenschaften) des Signals übereinstimmen. Auch hier müssen lediglich die Parameter und die Anzahl der Parameter übereinstimmen.

UninterpretedAction Eine uninterpretierte Aktion ist eine Aktion, die in UML nicht klar definiert ist. Wird für sprachspezifische Anweisungen verwendet, die nicht anderen Operationen zugewiesen werden können.

3.2.1.3 Kopieren und verlinken

In diesem Abschnitt werden die Modellelemente beschrieben, die für eine beispielhafte Darstellung von Struktur- und Verhaltensaspekten erforderlich sind (Abb. 3.36).

Instanzen Eine Instanz definiert ein „Ding“, auf das eine Operation angewendet werden kann, und verfügt über einen Status, der die Auswirkungen der Operation speichert.

Im Metamodell ist eine Instanz mit mindestens einem Klassifikator verknüpft, der die Struktur und das Verhalten der Instanz deklariert. eine Kopie ist ok

13 Das Pseudoattribut des Zuweisungsaktionsparameters bezieht sich wahrscheinlich darauf. Dies geht aus der Dokumentation nicht klar hervor ([OMG99], S. 2-86)

14 Advisory [OMG99], S. 2.91

3.2. Verhaltenselemente 88

assoziieren

Objekt

usw.

Was

aVal

bjc

Tonne

Modul

Lyme

Eingeben

bei diesem

Laser

Hund

winken

elektronische Eingabemethode

Panzer

elektronisch

Aktion

rein

erhalten

von

Mittel:

Dies führt zu

ich ein

irgendwas du willst

Das Ö

nta

erhalten

:Ö

bjc

Satz

Index

Antwort

rein

es ist ein

Synchronisieren

Herron

uns

: Wow

dünn

Straßenkarte

Tonne: a

Roman

nExp

Antwort

rein

bei diesem

Laser

ich ein

2..*

+con

rein

2..*

Link 1*

+ hier

Laser

Hund

Atr

Angezogen werden

elektronisch

Kommunikation

Stich

eingeben

Stan

*0。

+ bez

Seite

Neuer Taiwan-Dollar

*0。

Stimulieren

Nation

1 *

+dis

Patch

Verhalten

rein

1 *

*0。

.1*

+com

oder

Erfindung

Ion 0.

.1 Lee

Und

+ hier

Laser

ich ein

nd1*

.. *

+con

rein

2 ..

*{Ö

Befehl

bearbeiten}

Karat

Science-Fiction

Das ist

Atr

Angezogen werden

Erin

+ in

Stamm

ute

Handelshochschule

Enns

0..1

+ bez

Seite

NT$*

0..1

* **

+Parameter

eine Frau

Tonne*

{Befehl

aufrecht

}

*1*

+se

Nächste Seite

11*

+ bez

Sekundarschulbildung

es ist 1*

+Plugins

Panzer

elektronisch

+ Wald

kFIM

1..*

+kl

assi

Eisen

1..*

10..*

+sl

0,0

.** 1*

+Wert

UE1

Abbildung 3.36: Metamodell: Instanzen und Links

89 Kapitel 3 Das Metamodell

Es gibt eine Reihe von Eigenschaften und Eigenschaftswerten. Im Metamodell verfügen Instanzen über Attributverknüpfungen (Slots, Topics), die auf Attribute und Attributwerte verweisen.

Ähnlich wie Klassifikatoren mit Assoziationsterminals verbunden sind, um Assoziationen darzustellen, sind ihre Instanzen mit entsprechenden Link-Terminals (Instanzen von Assoziationsterminals) verbunden, um Links darzustellen. Instanzen können auch Sender und Empfänger von Reizen, also konkreten Nachrichten, darstellen. Eine Instanz ist eine abstrakte Metaklasse, die einen Eigenschaftswert vordefiniert:

Attributwertsemantik

persistent Wenn der Wert des Attributs als „persistent“ markiert ist, wird der Status der Instanz nicht zerstört, wenn die Instanz zerstört wird, dh der Status bleibt erhalten. Wenn der Wert als „transient“ markiert ist, wird der Zustand zusammen mit der Instanz zerstört.

DataValue Ein Datenwert ist eine Instanz ohne Identität. Im Metamodell ist Data-Value ein Nachkomme von Instance und kann seinen Status nicht ändern. Das heißt, alle auf Datenwerte anwendbaren Operationen sind entweder reine Funktionen (keine Nebenwirkungen) oder Abfragen (Query). Der Datenwert wird als Attributwert (Wert) verwendet. Ein Datenwert wird nur von einem Klassifikator (einem Datentyp) generiert und es gibt keine Attributverknüpfung, also kein Attribut.

Objekte Objekte sind Instanzen von Klassen. Im Metamodell ist Object eine Unterklasse von Instance. Ein Objekt ist eine Instanz mindestens einer Klasse. Die Klassenmitglieder eines Objekts können dynamisch geändert werden, d. h. die Eigenschaften des Objekts können sich während seiner Lebensdauer ändern. Jeder Klassifikator für ein Objekt muss eine Instanz der Class-Metaklasse sein.

ComponentInstance Eine Komponenteninstanz ist eine Instanz einer Komponente, die mehrere Zustände haben kann. Im Metamodell kann eine Komponenteninstanz mit einer Instanz verknüpft sein (sich dort befinden), die eine Instanz innerhalb der Komponente darstellt. Eine Komponenteninstanz kann aus einer Komponente (Klassifikator) erstellt werden.

NodeInstance Eine Knoteninstanz ist eine Instanz eines Knotens, die Komponenteninstanzen (residente Instanzen) enthalten kann. Jede Komponenteninstanz, die sich auf einer Knoteninstanz befindet, muss eine Instanz einer Komponente sein, die sich auf dem entsprechenden Knoten befindet. Der Klassifikator für eine Knoteninstanz muss a sein

3.2. Verhaltenselemente 90

ist eine Instanz der Metaklasse Node15.

Link-Objekt Ein Link-Objekt ist eine Instanz einer zugehörigen Klasse. Im Metamodell sind Linkobjekte Verbindungen zwischen Instanzen, wobei die Links selbst Attributwerte haben und Operationen auf die Links angewendet werden können. LinkObject ist ein Nachkomme von Object und Link. Ein verknüpfter Objektklassifizierer muss mit der entsprechenden Assoziation übereinstimmen, die eine Instanz der Metaklasse AssociationClass16 sein muss.

Reize Reize (Abbildung 3.37) beschreiben die Kommunikation zwischen zwei Proben.

Semantische Pseudoattribute

Die Empfängerinstanz, die den Stimulus empfängt. Absender Die Instanz, die den Stimulus gesendet hat. argument eine Folge von Instanzen, die die konkreten Argumente enthalten

Nachricht are.communicationLink Link zur Kommunikation. „dispatchAction“ löst bei der Ausführung die Aktion des Stimulus aus.

Die Anzahl der Argumente muss mit der Anzahl der Argumente in der Operation übereinstimmen. Bei der Operation muss es sich um eine Sendeoperation, eine Aufrufoperation, eine Erstellungsoperation oder eine Zerstörungsoperation handeln.

Links Links (Abbildung 3.37) stellen Verbindungen zwischen Instanzen dar. Im Metamodell sind Links Instanzen von Assoziationen. Links verfügen über einen (geordneten) Satz von Link-(Verbindungs-)Enden, die mit den Assoziationsenden einer Assoziation übereinstimmen müssen. Es dürfen keine Assoziationsverknüpfungen vorhanden sein, die dieselbe Instanz auf die gleiche Weise verbinden, d. h. jedes Tupel (wie eine Assoziationsinstanz) ist einzigartig.

LinkEnd Ein Link-Ende (Abbildung 3.37) ist eine Instanz eines Assoziationsendes, also ein Ende eines Links. Im Metamodell ist LinkEnd der Link-Teil, der einen Link mit einer Instanz verbindet. Das Linkende stimmt genau mit dem Assoziationsende (associationEnd) der Linkassoziation überein. Der Typ der Link-Seiteninstanz muss mit dem Typ der Assoziationsseite übereinstimmen.

15 Daher können andere Unterklassen von Node im Metamodell zu anderen Versionen von UML hinzugefügt werden.

Versionen nach 16 führen möglicherweise Unterklassen von AssociationClass ein.

91 Kapitel 3 Das Metamodell

Assoziation endet Assoziation

2..*1

+ verbinden

2..*1

Aktion

Treffer: IterationExpressiontarget: ObjectSetExpressionisAsynchronous: Booleanscript: ActionExpression

assoziieren

+Verband 1

Link endet

+associationEnd 1

2 .. *1

+ verbinden

2 .. *1{Sortieren}

Stimulieren

+dispatchAction 1

0..1*

+Kommunikationslink

0..1*

Beispiel

+linkFim

+Instanz

+Parameter*

{Befehl}

+Absender 1

* *

+ Rezeptor 1

Modellelement

Vorname

Abbildung 3.37: Verbindungen und Reize

Diese Links bilden Verbindungen zwischen Instanzen, über die Reize im Kollaborationsgraphen gesendet werden (Kommunikationslinks). Im Kollaborationsdiagramm werden mehrere definierte Link-End-Behauptungen verwendet:

Behauptungssemantik

Die mit dem Ende des Links verknüpfte Assoziationsinstanz ist durch die Assoziation sichtbar.

zerstört Die Instanz wird (im Modellierungskontext) zur Laufzeit zerstört.

Während der Ausführung wird eine neue Instanz erstellt. Transiente Instanz, die während der Ausführung erstellt und zerstört wird

Die Instanz „Störungen.global“ ist sichtbar, da sie sich im globalen Bereich befindet

(Bereich) ist relativ zum Link (globale Variable). Die lokale Instanz ist sichtbar, da sie sich im lokalen Bereich (Bereich) befindet.

pe) ist relativ zum Link (lokale Variable). Die Parameterinstanz ist sichtbar, da es sich um einen verknüpfungsrelativen Parameter handelt

Die ist.self-Instanz ist sichtbar, da sie der Absender der Anfrage ist

selbst ist.

3.2. Verhaltenselemente 92

3.2.2 Zusammenarbeit

Kollaborationen sind „[…] Gruppen von Objekten, die bestimmte Rollen ausführen und zusammenarbeiten, um ein Verhalten zu zeigen, das größer ist als die Summe ihrer Teile. Diese Rollen stellen prototypische Instanzen von Klassen, Schnittstellen, Komponenten, Knoten und Anwendungsfällen dar“, definieren 17 Kollaborationen ein struktureller Kontext Die Grundlage für die Interaktion zwischen den beteiligten Objekten.

Die Interaktion von Modellelementen wird in UML durch Interaktionsdiagramme dargestellt, von denen es zwei Versionen gibt: Sequenzdiagramme und Kollaborationsdiagramme. Sequenzdiagramme verdeutlichen den zeitlichen Ablauf der Kommunikation zwischen Objekten, zeigen jedoch nicht die strukturellen Beziehungen zwischen Objekten (Abbildung 3.38). Kollaborationsdiagramme enthalten die strukturellen Beziehungen zwischen den beteiligten Modellelementen (Kollaborationen) und darauf aufbauend die Interaktionen zwischen den Modellelementen, wobei die zeitliche Reihenfolge durch sogenannte Sequenznummern kommentiert wird.

Kollaborationsdiagramme können auf zwei verschiedenen Ebenen oder durch zwei unterschiedliche Ansichten der Zusammenarbeit von Modellelementen dargestellt werden. Ein Kollaborationsdiagramm auf Spezifikationsebene (Abb. 3.39) enthält Klassifikatoren und Assoziationsfunktionen, die strukturelle Aspekte darstellen, sowie Nachrichten (Nachrichten) zwischen Klassifikatorfunktionen, um die Kommunikation zu spezifizieren. Funktionen stellen Einschränkungen für Klassifikatoren und zugehörige Attribute dar, sodass nur Features angezeigt werden, die zusammenarbeiten müssen.

Die Zusammenarbeit auf der Instanzebene kann als Instanziierung auf der Spezifikationsebene angesehen werden. Diagramme auf dieser Ebene enthalten Instanzen von Klassifikatoren (hauptsächlich Objekte), Links und Reize. Ebenenkollaborationsdiagramme (z. B. Emplar) sind semantisch äquivalent zu Sequenzdiagrammen, da beide aus denselben Informationen im Metamodell abgeleitet sind. Dies bedeutet jedoch nicht, dass beide Abbildungen explizit dieselben Informationen darstellen 18 . Die Erstellung, Nutzung oder Zerstörung von Objekten oder Links kann explizit auf Instanzebene dargestellt werden (Abbildung 3.38).

Funktionen in Kollaborationen Symbolklassifikatorfunktionen werden verwendet, um die Eigenschaften der in der Kollaboration erforderlichen Klassen einzuschränken, und werden in Klassenrechtecken dargestellt. Zusätzlich zu optionalen Attributen und Operationen enthält die Klasse „Rechteck“ Zeichenfolgen, die dem folgenden Muster entsprechen:

/ Klassifikatorfunktion: Klassifikatorname Die Korrelationsfunktion wird als normale Korrelationslinie angezeigt. Optional

Die Benennung von Linkfunktionen folgt der Syntax von Klassifikatorfunktionen. Das Symbol für die endgültige Funktion des Vereins entspricht dem Symbol für den Zweck des Vereins.

17[BRJ99a], Florida. 23118cf. [BRJ99a], S. 282

93 Kapitel 3 Das Metamodell

3-98 UML V1.3 Beta R1 April 1999

3 UML-Notation

Abbildung 3-48. Sequenzdiagramm mit Kontrollfokus, Bedingungen, Rekursion, Erstellung und Zerstörung.

[x>0] foo(x)

[x<0] bala(x)

entwickeln (z) entwickeln (w)

moe re()

ob1:C1

ob2:C2

ob3:C3 ob4:C4

arbeiten()

Abbildung 3.38: Visualisierung von Interaktionen durch Sequenzdiagramme. Die vertikale gestrichelte Linie ist die Lebensader des Objekts. Ein diese Linien überlappendes Rechteck stellt den Kontrollfokus oder die Kontrolle des Objekts dar. Sie zeigen an, wann ein Objekt die Kontrolle im Programmablauf übernimmt. Die Botschaft oder der Reiz des Objektrechtecks zeigt die Entstehung des Objekts an, und das Kreuz am Ende der Lebenslinie zeigt die Zerstörung des Objekts in der Sequenz an. Alternative Prozesse werden durch Nachrichten dargestellt, die Bedingungen enthalten und deren Pfeile den gleichen Startpunkt haben. (Aus [OMG99], S. 3-98)

3.2. Verhaltenselemente 94

Klassifizierungsfunktion

/leader:person

Projekt

/Employee:PersonEmployee *Gruppenleiter 1 Leiter

Verantwortlich für +Projekt *

Projektmanager

Projekt

Teilnehmer 1

Die ultimative Rolle des Verbandes

Kardinalität der Assoziationsrollen

Abbildung 3.39: Zusammenarbeit auf Spezifikationsebene ohne Interaktionen. Verweise auf Kollaborationsdiagramme auf Spezifikationsebene finden sich nur in der offiziellen UML-Dokumentation ([OMG99], S. 3-111). Im Rahmen dieser Zusammenarbeit gibt es keine interaktiven Beispiele.

Viele Ziele

UML-Tool: Projekt.../Mitarbeiter:Person

/leader:person

1.1* [i=1..n]: name := name()1: NameBeteiligter() 名称

1.2: Name := Name()

Diagrammname: Kolla_SpecificationChart Dateiname: D:\Home\Stephan\vuml\colUntitled2.VobChart Typ: UML-Kollaborationsdiagramm

Abbildung 3.40: Zusammenarbeit auf Modellebene. Das Sternchen „*“ in Nachricht/Stimulus 1.1 weist auf eine Iteration hin. Leider gibt es keine Möglichkeit, visuell zu erkennen, welche Nachrichten in einer Iteration verarbeitet wurden. Erweiterte Modellierungsoptionen wie Verzweigungs- und Iterations-Clutter-Interaktionsdiagramme (siehe auch Abbildung 3.38).

95 Kapitel 3 Das Metamodell

Objekte, die die durch die Klassifikatorrollen definierten Rollen spielen, werden durch Objektboxen (siehe Abbildung 3.40) dargestellt, normalerweise ohne Attributteil. Der Namensteil des Objektrahmens wird nach dem folgenden Muster angezeigt:

Objektname/Klassifikatorfunktion: Der Klassifikatorname Objektname ist optional, d. h. Objektboxen ohne Objektnamen gelten als anonym

Das von der Klasse aus gesehene Nymes-Objekt. Die Klassifikatorrolle kann weggelassen werden, wenn das Basisklassenobjekt nur eine Rolle in der Zusammenarbeit spielt.

Interaktionen Eine Interaktion ist eine Spezifikation des Verhaltens von Objekten innerhalb eines Kontexts (Zusammenarbeit), um eine bestimmte Aufgabe zu erfüllen. Darauf aufbauend können mögliche Abfolgen von Interaktionen spezifiziert werden. Interaktionssequenzen können durch eine einzelne Beschreibung angegeben werden, die Bedingungen und Verzweigungen enthält, oder durch mehrere Beschreibungen, die jeweils einen bestimmten Pfad enthalten.

Kommunikationen werden durch eine Nachricht spezifiziert, die die Rollen von Absender und Empfänger sowie die Aktion, die die Kommunikation initiiert, enthält. Die Operation gibt die Art der Kommunikation (z. B. Aufruf der Operation) und Parameterausdrücke an, die die zu sendenden Parameter bestimmen. Als Ergebnis der Ausführung einer Aktion werden entsprechend der Nachricht ein oder mehrere Reize übermittelt. Ein Stimulus enthält Referenzen auf Sender- und Empfängerobjekte sowie eine Folge von Objektreferenzen als Ergebnis der Auswertung von Parameterausdrücken.

Interaktionen werden durch Sequenzdiagramme oder Kollaborationsdiagramme dargestellt. Ein Sequenzdiagramm (Abbildung 3.38) zeigt die Verhaltensaspekte der Zusammenarbeit, einschließlich der zeitlichen Reihenfolge von Nachrichten/Stimuli. Kollaborationsdiagramme zeigen den gesamten Kontext von Interaktionen, in Sequenzdiagrammen ist es jedoch einfacher, das Timing intuitiv zu verstehen.

Nachrichten und Reize in Kollaborationsdiagrammen Reize sind die Kommunikation von einem Objekt zu einem anderen, während Nachrichten die Spezifikation der Kommunikation darstellen.

Pfeile entlang zugehöriger Linien oder Links zeigen die Art der Kommunikation an, z. B. synchron oder asynchron. Pfeile im Diagramm. 3.40 stellt einen (verschachtelten) Operationsaufruf dar. Verschachtelte Sequenzen (dargestellt durch Sequenznummern) müssen vollständig beendet sein, bevor die äußere Sequenz fortgesetzt werden kann.

Neben den Pfeilen werden Botschaften (oder Reize) angezeigt. Die Nachricht hat die folgende Syntax ([OMG99], Seite 3-123):

Rückgabewert des Bedingungszeichenfolgenausdrucks: = Parameterliste für Nachrichtennamen

3.2. Verhaltenselemente 96

Ancestor ist eine durch Kommas getrennte Liste von Sequenznummern (siehe Sequenzausdrücke) ohne Verzweigungsbedingungen oder Iterationsausdrücke, gefolgt von einem Schrägstrich (/). Das bedeutet, dass die durch die Sequenznummer identifizierte Nachricht verarbeitet werden muss, bevor diese Nachricht gesendet wird. Die durch die Sequenznummer implizit angegebenen Vorfahren (1.2.3 ist ein Vorfahre von 1.2.4) müssen hier nicht explizit angegeben werden. Vorfahren werden verwendet, um gleichzeitige Threads zu synchronisieren.

Diese Bedingung ist in [OMG99] nicht definiert. Nach [Alh98], S. 183, ist eine Bedingung eine boolesche Bedingung in eckigen Klammern, deren Erfüllung das Versenden einer Nachricht ermöglicht.

Ein Zeichenfolgenausdruck besteht aus einer durch Punkte getrennten Liste von Zeichenfolgenelementen, gefolgt von Doppelpunkten:

Sequenzelement. ...: Jeder Begriff stellt eine Verschachtelungsebene innerhalb der Gesamtinteraktion dar.

Jedes Sequenzelement hat die folgende Syntax: [Ganzzahl | Name] [Wiederholung] Ganzzahl ist eine positive Zahl, die die Reihenfolge angibt, in der sich die Nachricht befindet

Der Name der nächsthöheren Ebene (Nachricht 1.2.4 nach Nachricht 1.2.3) ist eine Zeichenfolge, die gleichzeitige Threads bezeichnet. Information

Verschiedene Namen auf dieser Ebene (z. B. 1.2.3.a und 1.2.3.b) sind auf dieser Verschachtelungsebene gleichzeitig.

Wiederholung ist eine Bedingungsklausel ([ Bedingungsklausel ]) oder eine Iterationsklausel (* [ Iterationsklausel ]). UML legt die Form von Bedingungsklauseln und Iterationsklauseln nicht fest. Iterationen geben an, wie oft die Nachricht wiederholt wird, z. B. [i = 1..n]. Nachrichten werden nacheinander ausgeführt. Mit „*“ können Sie die gleichzeitige Ausführung angeben. Wiederholung wird dem Wiederholungsattribut der Aktion (Aktion) zugeordnet, die der Nachricht zugeordnet ist, beispielsweise einem Operationsaufruf.

Eine Bedingungsklausel erklärt, dass die Ausführung der Nachricht vom Wahrheitswert der Bedingungsklausel abhängt. Beispiel: [x

Der Rückgabewert besteht aus einer Liste von Bezeichnern, die den Rückgabewert am Ende der Kommunikation darstellen. Diese Bezeichner können als Parameter in nachfolgenden Nachrichten verwendet werden.

Der Nachrichtenname ist der Name des Ereignisses, das auf dem Zielobjekt aufgetreten ist, normalerweise das Ereignis, das die Ausführung der Aktion angefordert hat. Wenn diese Nachricht als Operationsaufruf implementiert ist, ist der Nachrichtenname der Name der Operation, und die Nachrichtenempfängerklasse muss diese Operation deklarieren oder erben.

Die Parameterliste besteht aus einer durch Kommas getrennten Liste von Parametern in eckigen Klammern (tatsächliche Parameter). Jeder Parameter ist entweder eine Objektreferenz oder ein Pseudocode-Ausdruck. Ausdrücke können vorherige Werte zurückgeben

97 Kapitel 3 Das Metamodell

Verwenden Sie Nachrichten- und Navigationsausdrücke basierend auf Quellobjekten. Ein Navigationsausdruck besteht aus den Eigenschaften und Links des Quellobjekts sowie den Eigenschaften und Links anderer Objekte, auf die über die Links des Quellobjekts zugegriffen werden kann. Außerdem ist die Syntax von Ausdrücken in UML nicht definiert.

Sequenzdiagramme Sequenzdiagramme haben zwei Dimensionen. Die vertikale Dimension repräsentiert die zeitliche Reihenfolge und die horizontale Dimension repräsentiert die beteiligten Objekte. Die Syntax und Semantik der Nachrichten stimmen mit denen im Kollaborationsdiagramm überein. Verschiedene Zusatzinformationen, wie Zeitstempel und

... UML-Tools: Projekte / Mitarbeiter: Personen / Führungskräfte: Personen

1: Name Teilnehmer() 1.1* [i=1..n]:name := name()

1.2: Name := Name()

einbeziehen

Abbildung 3.41: Interaktion von Abbildung 3.40 in einem Sequenzdiagramm. Sequenznummern werden normalerweise nicht angezeigt, da die Reihenfolge der Nachrichten implizit vorgegeben ist.

Aktionsbeschreibungen können an den Rändern des Diagramms oder in der Nähe der Pfeile angezeigt werden.

Kollaborationen und Sequenzdiagramm-Interaktionen werden denselben Metamodellklassen zugeordnet. Daher gelten die beiden Arten von Interaktionsdiagrammen als semantisch äquivalent, obwohl jeder Diagrammtyp Modellelemente darstellen kann, die durch den anderen Diagrammtyp nicht dargestellt werden können.

Das Collaborations-Metamodellpaket (Abbildung 3.42) besteht aus der Collaboration-Klasse, die eine Kombination aus Rollen (AssociationRole, Classifier-Role) und Interaktionen (Interaction) enthält. Nachrichten, die jeweils einer Aktion zugeordnet sind.

In diesem Paket sind keine Klassen vorhanden, die Kollaborationen auf Instanzebene darstellen.

3.2. Verhaltenselemente 98

{XOR

}

Name

Raum

bei diesem

Laser

Hund

Aktion

rein

bei diesem

Laser

ich ein

2..*1

+con

rein

2..*1

Atr

Angezogen werden

elektronisch

offen

Grund

NEIN

Das

rein

bei diesem

Laser

Ion R

alt

mehrere

typisch

Alter:

Multiplikator

typisch

Alter

0..1

+ba

com

0..1

Fea

Tula

Keule

Vernünftig

*0..1 *+ac

Tivat

oder

0..1** *+PR

Editor

Das

1 1..*

Das

ge1。

+ Aktion

rein 1

*0。

.1*

+com

oder

Erfindung

rein

Betrug

rein

0..1

bei diesem

Laser

ich ein

NDR

alt

Paste

Polaris

Ion

Super Tipp

Rechtmäßigkeit

: männlich

Super Tipp

Rechtmäßigkeit

0..1

+ba

com

0..1

1 2..*

+/Co

Netzwerkanschluss

Hund

2..*

* ** + a

Arzneimittel

Blau Q

Waliff

Also

Karat

Science-Fiction

Das ist

Yamaguchi

Rabo

Grund

*0。

.1*

+ bez

Druck

Körper

machen

pera

Hund

0..1

1 *

+con

Text

+ ganze Zahl

er ist

Hund

1*1

+/niedrig

Unteres E

Lyme

Eingeben

*0。

.1*

+ bez

Druck

Körper

Gleichstrom

Mädchen

Identifikator

0..1

Karat

Science-Fiction

Also

alt

mehrere

typisch

Alter:

Multiplikator

typisch

Alter

+ava

Etikett

eFea

Tula

1..*

+/niedrig

Unteres E

Lyme

Eingeben

1..*

+se

Nächste Seite

1** 1*

+ bez

Sekundarschulbildung

es ist 1

/Typ

+ba

se1

Modul

Lyme

Eingeben

* **+c

Ontario

Regen

Inge

Lyme

Eingeben

+ava

Etikett

Wirtschaft

Zelt

Klein*

Abbildung 3.42: Zusammenarbeit

99 Kapitel 3 Das Metamodell

Collaboration Collaboration beschreibt, wie eine Operation (represented operation) oder ein Klassifikator (representedClassifier) (z. B. ein Anwendungsfall) auf eine bestimmte Weise mithilfe von Klassifikatoren und Assoziationen durchgeführt wird. Kollaborationen definieren die Rollen, die Instanzen und Links spielen, und definieren die Interaktionen zwischen Instanzen, die bei der Ausführung der Rollen kommunizieren.

Collaboration gibt eine Ansicht einer Reihe von Klassifikatoren an. Diese Ansicht beschreibt die erforderlichen Beziehungen zwischen Instanzen der entsprechenden Merkmale der Klassifikatoren sowie die erforderlichen Merkmale und enthaltenen Modellelemente dieser Klassifikatoren.

Verschiedene Kooperationen können unterschiedliche Ansichten desselben Klassifikators beschreiben. Kollaborationen können Modellelemente umfassen, am häufigsten Klassifikatoren und Verallgemeinerungen, die zur Darstellung struktureller Anforderungen zur Erfüllung kollaborativer Aufgaben verwendet werden.

Eine Kollaboration ist ein generalisierbares Element, das heißt, sie kann eine Aufgabe spezifizieren, die eine Spezialisierung einer anderen Kollaborationsaufgabe darstellt.

Semantische Pseudoattribute

ownElement (geerbt von Namespace) Gemeinsam definierte Funktionen. Dies sind Klassifikatorrollen und Assoziationsrollen.

Interaktion Identifiziert die in der Zusammenarbeit definierte Interaktion.

begrenzendes Element

Fügen Sie dem Vorlagenelement der Zusammenarbeit weitere bedingte Vorlagenelemente (z. B. „Generalisieren“, „Garantie“) hinzu.

Klassifizierer für Klassifikatorfunktionen, Bindungen für gebundene Funktionen und gebundene Modellelemente (constrainingElement) müssen zum Collaboration-Namespace gehören. Wenn ein Klassifikator oder Link unbenannt ist, muss es sich um den einzigen seiner Basisklassifikatoren oder Basislinks handeln. Kollaborationen (im strukturellen Sinne) können nur Klassifikatorfunktionen, Korrelationsfunktionen sowie Verallgemeinerungen und Behauptungen zwischen ihnen enthalten.

Interaktionen Interaktionen spezifizieren die Kommunikation zwischen Modellelementen, um bestimmte Aufgaben zu erfüllen. Jede Interaktion wird im Kontext einer Zusammenarbeit definiert, das heißt, auch für Sequenzdiagramme muss zumindest implizit ein Kontext vorhanden sein.

Im Metamodell enthalten Interaktionen Nachrichten, die die Kommunikation zwischen Instanzen entsprechend den Rollen der Klassifikatoren spezifizieren.

3.2. Verhaltenselemente 100

Alle zu sendenden Signale müssen im Namensraum der Kollaboration enthalten sein, zu der die Interaktion gehört.

Nachrichten Nachrichten geben spezifische Kommunikationen zwischen Instanzrollen in einer Interaktion an.

Semantische Pseudoattribute

Absender Die Rolle einer Entität, die die Kommunikation initiiert und Antworten empfangen kann.

Empfänger Die Rolle des Projekts, das Nachrichten empfängt und darauf antwortet.

Aktion Die Aktion, die dazu führt, dass der der Nachricht entsprechende Stimulus gesendet wird. Der Nachrichtenname, die Parameter, der Iterationsausdruck und die Bedingung (Zweig) des Pfeils sind dieser Operation im Interaktionsdiagramm zugeordnet.

Trigger Eine Nachricht, deren Empfang eine Aktion auslöst, die das Senden der Nachricht bewirkt. Dies ist die Nachricht, die die Kommunikationssequenz innerhalb des Objekts initiiert. Diese Nachricht muss in derselben Interaktion enthalten sein.

Kommunikationsverbindung

Eine zugehörige Rolle oder ein Link zur Kommunikation.

Präambel Eine Reihe von Nachrichten, deren vollständige Ausführung die Ausführung dieser Nachricht ermöglicht. Diese Nachrichten müssen in derselben Interaktion enthalten sein und denselben Auslöser haben.

Sender und Empfänger müssen an einer Zusammenarbeit teilnehmen, die den Kontext definiert. Ihre Funktion muss über eine Kommunikationsverbindung (communicationConnection) verbunden sein.

ClassifierRole Eine Classifier-Rolle ist eine bestimmte Rolle, die ein Kollaborationsteilnehmer spielt. Es legt eine eingeschränkte Sicht auf die Funktionen des Klassifikators fest und dient dazu, unerwünschte Funktionen auszublenden oder sie Kommunikationspartnern nicht zur Verfügung zu stellen. Klassifikatorrollen und ihre Funktionen werden in Klassenrechtecken dargestellt.

Im Metamodell ist ClassifierRole Teil der Zusammenarbeit. availableFeature gibt die in der Kollaboration verfügbaren Basisklassifikatorfunktionen (Basisfunktionen) an. availableContents gibt eine Teilmenge des angezeigten Inhalts an.

101 Kapitel 3 Das Metamodell

dellElements für den Basisklassifizierer. Das Multiplizitätsattribut gibt die Anzahl der Instanzen an, die diese Rolle in der Zusammenarbeit spielen.

AssociationRole Assoziationsrollen sind spezifische Verwendungen von Assoziationen in Kollaborationen.

Im Metamodell ist eine Assoziationsrolle eine eingeschränkte Sicht auf eine Assoziation (Basis) in einer Zusammenarbeit. AssociationRole ist eine Zusammensetzung von Assoziations-(Verbindungs-)Nebenrollen, die dem Mitgliedschaftszweck der Assoziation entsprechen. Ebenso gibt das Attribut Multiplizität die Anzahl der Instanzen an, die bei der Zusammenarbeit eine Rolle spielen.

AssociationEndRole Eine Assoziationsendrolle ist der Endpunkt einer Assoziation in einer Zusammenarbeit.

Das Attribut CollaborationMultiplicity19 gibt die Anzahl der Linkenden in der Kollaboration an, die diese Rolle spielen, base gibt die Assoziation der Assoziation an und availableQualifier gibt den in der Kollaboration verwendeten Qualifizierer an.

3.2.3 Zustandsmaschine

Zur Modellierung des dynamischen Verhaltens von Modellelementen werden Zustandsmaschinen (finite Machines) oder Zustandsdiagramme (Zustandsdiagramme) verwendet. Diese Elemente sind normalerweise Klassen oder deren Objekte, und Reaktionen auf Ereignisse, wie z. B. Operationsaufrufe, hängen von der Vergangenheit der Objekte ab.

Eine Zustandsmaschine ist eine hypothetische Maschine, die sich zu jedem Zeitpunkt in einer endlichen Menge von Zuständen befindet, die auch als Konfiguration bezeichnet wird. Abhängig von der Konfiguration, die den relativen Verlauf des modellierten Elements darstellt, kann festgelegt werden, ob die Zustandsmaschine (und damit das Element) auf Ereignisse reagiert. Maschinenreaktionen können Aktionen und Zustandsänderungen (Übergänge) umfassen.

Abbildung 3.43 zeigt beispielsweise den Zustandsautomaten für eine Klimaanlage. Diese Art der Modellierung kann verwendet werden, um die Reihenfolge der Aufrufe von Objektoperationen einzuschränken, die ein Objekt während seiner Lebensdauer ausführen kann.

Die Metamodellklassen für Ereignisse und Zustandsmaschinen werden in den nächsten beiden Abschnitten erläutert. Aktionen und ihre Metamodellklassen werden bereits behandelt (siehe Seite 84).

19AssociationEnd hat eine Eigenschaft namens Multiplizität deklariert.

3.2. Verhaltenselemente 102

stoppen

Kühlen und Heizen

Ativando ActiveActivating Activeready / turnOn（）

Temperatur

zu heiß (gewünschte Temperatur)

Anfangszustand Endzustand

Krankheit

Übergang

Ereignis (Parameter)

Ereignis/Aktion

Ein Übergang ohne Ereignis wird als „nicht auslösend“ bezeichnet.

Temperatur

zu kalt (gewünschte Temperatur)

nach (1 Stunde) / selfTest()

abschalten

sehr kalt (gewünschte Temperatur)

zu heiß (gewünschte Temperatur)

Zeitereignisse/Aktionen

Abbildung 3.43: Zustandsmaschine für Klimaanlagen

103 Kapitel 3 Das Metamodell

3.2.3.1 Ereignisse

Eine Zustandsmaschine kann auf vier Arten von Ereignissen reagieren: Signale, Aufrufe, Änderungen und zeitgesteuerte Ereignisse (Abbildung 3.44).

Zeitereignis

wann: Zeitausdruck

Ereignis ändern

Variationsausdruck: Boolescher Ausdruck

Betrieb

Anrufereignis

+passieren*

Vorfall an der Ampel

Signal

+passieren*

Parameterereignis

* 0..1

+Parameter

{Befehl}

0..1

Modellelement

Abbildung 3.44: Ereignismetamodell

Ereignisse Ereignisse sind Spezifikationen beobachtbarer Ereignisse. Ein Ereignis hat einen Namen (geerbt von ModelElement), der über Parameter angegeben werden kann. Event ist eine abstrakte Metaklasse.

SignalEvent Ein Signalereignis stellt den Empfang eines Signals (asynchron) dar und ist einem Signal im Metamodell zugeordnet.

CallEvent Ein Anrufereignis stellt eine Aufforderung zur Ausführung einer Aktion dar.

Es werden zwei Stereotypen für Aufrufereignisse definiert:

3.2. Verhaltenselemente 104

Stereotypensemantik

„destroy“ fordert die empfangende Instanz zur Selbstzerstörung auf.

«create» Die empfangende Instanz wurde gerade erstellt. Dies ist das einzige Ereignis, das dem anfänglichen Übergang auf der obersten Ebene der Zustandsmaschine zugeordnet werden kann.

Ein TimeEvent-Zeitereignis simuliert das Eintreffen eines durch einen Zeitausdruck (timeExpression) angegebenen Zeitpunkts (Deadline).

Bei der Erläuterung des Laufzeitverhaltens einer Zustandsmaschine entspricht der Zeitpunkt des Eintretens eines Ereignisses dem Empfang des Ereignisses. Auf diese Weise haben Ereignisse keine zeitliche Dimension. Der Modellierungszeitpunkt (wann) kann ein absoluter Zeitpunkt oder ein relativer Zeitpunkt (Stoppuhr) sein. Zu relativen Zeitpunkten ohne explizite Startzeit beginnt der Timer mit der Aktivierung des Startzustands des entsprechenden Übergangs. Das Zeitereignis tritt nur ein, wenn der Ausgangszustand bei Erreichen der Frist noch aktiv ist.

Zeitereignisse werden durch das Schlüsselwort „after“ dargestellt, z. B. „after“ (2 Sekunden) und „after“ (10 Sekunden nach Verlassen von Zustand A). Andere „Zeitereignisse“, wie zum Beispiel „wann“ (Datum = 1. Januar 2000), sind Änderungsereignisse (siehe unten, [OMG99], S. 2-134 und 3-136). Auswahl der Eigenschaftsnamen bei der Verschleierung der TimeEvent-Metamodellklasse.

ChangeEvent Ein Änderungsereignis ist ein Ereignis, das durch eine Änderung des Systemstatus (d. h. eine Eigenschafts- oder Linkwertänderung) ausgelöst werden kann.

Ein Änderungsereignis wird durch ein Schlüsselwort gefolgt von einem booleschen Ausdruck (changeExpression) modelliert. Dieser boolesche Ausdruck wird bei der Interpretation des Laufzeitverhaltens kontinuierlich ausgewertet. Wenn die Auswertung „true“ ist, tritt ein Änderungsereignis auf.

Änderungsereignisse unterscheiden sich von Übergangsbedingungen (Guards) (siehe unten), die nur ausgewertet werden, wenn das Ereignis auftritt. Wertet den booleschen Ausdruck für das Änderungsereignis aus, bis er wahr wird. Ereignisse bleiben bestehen, bis sie verarbeitet werden, d. h. die Ereignisverarbeitung erfolgt unabhängig vom Wert des booleschen Ausdrucks zum Zeitpunkt der Verarbeitung.

Ein „Zeitereignis“ ist ein formelles Änderungsereignis. Wenn sich der Modellierer an der üblichen Verwendung der Sprache orientiert, kann dies leicht zu Änderungsereignissen des Typs (23:49 Uhr) führen (Beispiel: [BRJ99a], S. 317, Abbildung 20-4), die eher semantisch sind eines Änderungsereignisses ( 23:49 Uhr ist kein boolescher Ausdruck) wird interpretiert.

105 Kapitel 3 Das Metamodell

3.2.3.2 Zustandsmaschine

Operationen sind ausführbare atomare Prozeduren, die den Zustand des Systems ändern. Die Dauer einer Aktion, beispielsweise eines Bedienaufrufs, wird als bedeutungslos interpretiert. Eine Aktivität ist eine Folge von Aktionen, die eine nicht-atomare Ausführung innerhalb eines Zustandsautomaten darstellt. Aktivitäten können durch Ereignisse unterbrochen werden. Dabei handelt es sich meist um eine Art Interrupt auf einer höheren Ebene der Zustandsmaschine.

Ein Zustand ist ein Zustand oder eine Situation während der Existenz eines Objekts. Wenn sich ein Objekt in einem Zustand befindet, der als aktiver Zustand bezeichnet wird, kann das Objekt Aktionen und Aktivitäten ausführen oder auf bestimmte Ereignisse warten.

Übergänge sind Richtungsbeziehungen zwischen Zuständen. Ein Übergang „triggert“, d. h. führt einen Zustandsübergang durch, wenn ein bestimmtes Ereignis eintritt und optionale Bedingungen erfüllt sind. Ein Übergang besteht aus fünf Teilen:

1. Ein Ereignisauslöser gibt ein Ereignis an, dessen Empfang es der Zustandsmaschine ermöglicht, einen Übergang durchzuführen.

2. Die optionale Bedingung (Schutzbedingung) ist ein boolescher Ausdruck, der ausgewertet wird, wenn der Ereignisauslöser empfangen wird. Wenn der Ausdruck „true“ ergibt, wird die Konvertierung durchgeführt. Ein Ereignis gilt als behandelt, wenn es keinen Zustandsmaschinenübergang „auslöst“.

3. Der Quellzustand (Anfangszustand) gibt den Zustand an, der aktiv sein muss, bevor der Übergang ausgelöst wird.

4. Der Zielzustand (nächster Zustand) stellt den Zustand dar, der aktiv ist, nachdem der Übergang ausgelöst wurde.

5. Die Aktion, die ausgeführt werden soll, wenn der Übergang ausgelöst wird, d. h. die Aktion, die ausgeführt wird, bevor der nachfolgende Zustand aktiviert wird.

Ein Zustand kann mehrere Komponenten haben:

1. Ein Staat kann einen Namen haben. Ein Land ohne Namen ist ein anonymes Land.

2. Eingabe- und Ausgabeaktionen, die beim Eintritt in einen Zustand (aktivierter Zustand) und beim Verlassen eines Zustands (deaktiviert) ausgeführt werden.

3. Ein interner Übergang ist ein Übergang, dessen Zustand nicht beendet ist, insbesondere ein interner Übergang, der keine Ein- und Austrittsaktionen ausführt.

3.2. Verhaltenselemente 106

4. Ein Staat kann Unterstaaten haben. Diese Zustände stellen eine Zustandsmaschine oder mehrere gleichzeitige Zustandsmaschinen innerhalb einer Zustandsmaschine dar. Der Zustand „Heizung“ in Abbildung 1. 3.43 ist ein Beispiel für einen Staat mit Unterstaaten. Wie im Bild gezeigt. 3.46 zeigt einen Zustand mit einer gleichzeitigen Zustandsmaschine.

5. Die Zustandsmaschine ignoriert normalerweise Ereignisse, auf die sie nicht über Transitionen reagieren kann. Ereignisse, die ignoriert werden, gelten als behandelt. In UML können Ereignisse für einen Zustand angegeben werden, in dem keine Reaktion auf das Ereignis erfolgt, in anderen Zuständen jedoch eine Behandlung erfolgen soll. Diese Ereignisse werden verzögerte Ereignisse genannt (siehe [BRJ99a], S. 337). Ein verzögertes Ereignis bedeutet, dass das Ereignis nicht eingetreten ist. Ein verzögertes Ereignis tritt erst ein, wenn der Zustand aktiv wird, der das Ereignis nicht verzögert.

Sofern nicht anders angegeben, beginnt der Zustandsautomat für einen Unterzustand mit seinem Anfangszustand. In manchen Fällen (zum Beispiel bei übergeordneten Interrupts) ist es notwendig, die Konfiguration eines komplexen Zustands (Composite State) zu speichern, damit sie bei der nächsten Aktivierung wiederhergestellt werden kann. Zu diesem Zweck stellt UML das Konzept des Speicherzustands (historischer Zustand) zur Verfügung. Ein Speicherzustand ist ein Pseudozustand, der es einem Zustand ermöglicht, sich an seinen letzten aktiven Unterzustand zu erinnern (siehe Abbildung 3.45).

Wenn ein zusammengesetzter Zustand in seiner vorherigen Konfiguration reaktiviert werden muss, wird dies durch einen Übergang in einen speicherinternen Zustand modelliert. Bei der ersten Aktivierung wird der zusammengesetzte Zustand nicht übergeben und es wird ein Speicherzustandsübergang durchgeführt (siehe Abbildung 3.45).

Durch das Verschachteln von Zuständen entsteht ein Zustandsbaum. Die Knoten des Baums sind zusammengesetzte Zustände und die Blätter sind einfache oder Pseudozustände. In UML werden zwei Arten von Speicherzuständen definiert: flache Speicherzustände und tiefe Speicherzustände. Ein flacher Verlauf speichert den letzten direkt aktiven Unterzustand (aktiver Zustand eine Ebene tiefer in der Baumstruktur) eines zusammengesetzten Zustands. Ein flacher Speicherzustand, wie in Abbildung 1 dargestellt. 3,45, vertreten durch H. Der tiefe Verlauf speichert den aktiven Zustand für den gesamten Zustandsteilbaum zusammen. Tiefe Speicherzustände werden mit „H*“ gekennzeichnet.

Zusammengesetzte Zustände können gleichzeitige Regionen enthalten, die jeweils eine Zustandsmaschine enthalten, die gleichzeitig ausgeführt wird (siehe Abbildungen 3.46 und 4.62, Seite 189).

Die Metamodellklassen der UML-Zustandsmaschine (Abbildung 3.47) werden im Folgenden erläutert.

StateMachine Eine Zustandsmaschine ist ein Modellelement, das die mögliche Dynamik eines Modellelements (Kontext) beschreibt. Dieses Modellelement ist

107 Kapitel 3 Das Metamodell

Befehl

Sicherung

sammeln

Kopieren

Aufräumen

sammeln

Kopieren

Aufräumen

„BackingUp“ erster aktiver queryStart-Status

Shallow-Memory-Status (Shallow-History): Speichern Sie den letzten aktiven Status von „BackingUp“.

Abbildung 3.45: Erinnerungszustände speichern den zuletzt aktivierten Zustand des Verbundzustands (hier: BackingUp), der bei erneuter Aktivierung zur Wiederherstellung der letzten Konfiguration des Verbundzustands verwendet wird. Das Beispiel zeigt eine Zustandsmaschine für ein Backup-Programm ohne Endzustand, beispielsweise zur Datensicherung über ein Netzwerk. Der Systembetreiber kann das Programm zu Informationszwecken unterbrechen. Anschließend setzt das Programm seine Aktivitäten fort, beginnend mit der letzten Konfiguration.

3.2. Verhaltenselemente 108

Diagrammname: Backup – HistoryStatesChart Dateiname: concurrentZA.VobChart Typ: UML Statechart

Vorbereiten

RadioAus-Radio

ComputerAus ComputerAn

arbeiten

RadioAus-Radio

ComputerAus ComputerAn

arbeiten

Radio

Computer

wann (istGenug)

Abbildung 3.46: Der Zustand „Bereit“ besteht aus zwei gleichzeitigen Regionen. Der „Arbeits“-Zustand wird aktiviert, wenn beide Zustandsmaschinen in der gleichzeitigen Region ihren Endzustand erreicht haben.

109 Kapitel 3 Das Metamodell

pse

Exzellent

Tate

Typ

Juwel

Vergleichen

nur

Industrie

Simulation

Bitte

Tate

Meiden

CHS

Tate

Bohnen

d: du

Grenzwert

ited ich

hinlegen

Es ist Blödsinn

bSta

Referenz

Herzkrankheit

Das ist

Ö :

Name

elektronisch

Flosse

bei diesem

Tate

Kommunikation

Standort

prüfen

Tate

ist C

Nku

mieten

:Zweite

eins

Gua

dritte

Ausdruck

ihnen

um :

Wow

dünn

Index

Antwort

rein

Stern

Stromspannung

Spott

1..*

0..1

+ Kind

Kap Verde

Vorgänger

1..*

+ Zusammenarbeit

Dann

nell

0..1

Vorabend

Neuer Taiwan-Dollar

Aktion

rein

Modul

Lyme

Eingeben

zwischen

Nation

0..1 1

+Gu

hart

0..1

+tr

Bank

r0。

+ also

Zertifikat

+ Du

tgoi

von *

+ sie

erhalten

+em

com

ING *

0..1

+ef

perfekt

0..1

Stern

0..*

+'s

Eisen

fähig

Vorabend

n 0..*

0..1

+em

Seeschwalbe

alle*

0..1

+em

versuchen

0..1

+ex

Das

0..1

+ tun

Aktion

Aktivität 0..1

Kind

Apfel

Klage

Stern

TEM

Archie

Das ist es

*0..1

+werden

der dritte

oder*

+ Zusammenarbeit

ntex

t0。

0..1

+tr

Anxi

Hund

0..1

+zu

0..1

+ ist

bmac

feministisch 1

Abbildung 3.47: Zustandsmaschinen-Metamodell

3.2. Verhaltenselemente 110

Dies ist ein Klassifikator oder Verhaltenselement. Ein Modellelement kann durch mehrere Zustandsmaschinen beschrieben werden.

Eine Zustandsmaschine besteht aus Zuständen, die Aktionen, Übergänge und Bedingungen enthalten können. Neben zusammengesetzten Zuständen können Zustandsmaschinen auch Zustände enthalten, die andere Zustandsmaschinen darstellen (siehe SubmachineState, Seite 113), die an anderer Stelle im Modell angegeben sind.

top stellt die Wurzel (Zustand der obersten Ebene) im Zustandsbaum der Zustandsmaschine dar. Eine Zustandsmaschine hat nur einen Zustand der obersten Ebene, der ein zusammengesetzter Zustand sein muss (siehe CompositeState). Ein Zustand der obersten Ebene kann weder eine Übergangsquelle sein, noch kann er in einem anderen Zustand (Zusammensetzung) enthalten sein. Wenn eine Zustandsmaschine Verhaltensmerkmale beschreibt, kann sie außer anfänglichen Übergängen keine Trigger vom Typ CallEvent enthalten.

CompositeState Ein zusammengesetzter Zustand ist ein Zustand, der einen oder mehrere untergeordnete Knoten (Unterzustände) enthält. Ein Zustand (StateVertex) kann zu höchstens einem zusammengesetzten Zustand gehören (Semantik von Composite). Jeder in einem zusammengesetzten Zustand enthaltene Zustand wird als Unterzustand des zusammengesetzten Zustands bezeichnet. Wenn es in keinem anderen Zustand enthalten ist, spricht man von einem direkten untergeordneten Zustand. Andernfalls spricht man von der Übergabe verschachtelter Unterzustände. Ein zusammengesetzter Zustand kann höchstens einen Anfangszustand, einen flachen Speicherzustand und einen tiefen Speicherzustand haben.

Wenn die boolesche Eigenschaft „AttributeisConcurrent“ wahr ist, besteht der zusammengesetzte Zustand aus zwei oder mehr direkt gleichzeitigen Regionen (auch Regionen genannt).

StateVertex Ein Zustandsknoten ist eine abstrakte Metaklasse, die einen Zustand einer Zustandsmaschine oder einen Knoten eines Zustandsgraphen darstellt. Diese Knoten können Quelle und Ziel von Transformationen sein oder Teil eines zusammengesetzten (Container-)Zustands sein.

Übergänge Ein Übergang ist eine gerichtete Beziehung zwischen einem Quellzustandsknoten und einem Zielzustandsknoten (Zielzustand). Trigger gibt ein (optionales) Ereignis an, das dazu führen kann, dass der Übergang „auslöst“, wenn die optional bereitgestellte boolesche Bedingung (Guard) erfüllt ist.

Übergänge ohne Ereignisse werden als „keine Auslöser“ bezeichnet. Effekte sind optionale Aktionen, die während Übergängen ausgeführt werden.

Eine Guard-Bedingung ist ein boolescher Ausdruck, der an den Übergang angehängt ist, den der Control-Übergang auslöst. Der Ausdruck wird ausgewertet, wenn das mit dem Übergang verbundene Ereignis (Trigger) eintritt. Wenn die Auswertung „true“ ergibt, führen Sie die Aktion (Effekt) aus und gehen Sie wie folgt vor

111 Kapitel 3 Das Metamodell

aktiver Zustand. Konvertierte boolesche Ausdrücke müssen reine Funktionen sein, d. h. keine Nebenwirkungen haben.

State State ist eine abstrakte Metaklasse, die eine Situation darstellt, in der (häufig implizite) Bedingungen angewendet werden (z. B. Warten auf ein Ereignis, Ausführen einer Aktivität).

Semantische Pseudoattribute

stateMachine Die Zustandsmaschine, zu der der Zustand gehören kann. internal bezeichnet Übergänge, die zum Zustand selbst gehören (intern).

interner Übergang). Die Ausführung dieses Übergangs führt nicht zur Anwendung von Eingabe- und Ausgabeaktionen, dh dieser Übergang führt nicht zu einer Änderung des Zustands der Zustandsmaschine.

Eingabe Gibt die Aktion an, die ausgeführt werden soll, wenn der Status aktiv wird (Eingabeaktion).

Exit gibt die Aktion an, die ausgeführt werden soll, wenn der Status deaktiviert wird (Exit-Aktion).

doActivity stellt die Aktivität dar (die Aktion kann eine Folge von Aktionen sein), die ausgeführt wird, wenn der aktive Status aktiv ist.

deferrableEvent stellt ein Ereignis dar, das verzögert wird, während dieser Status aktiv ist.

SimpleState Ein einfacher Zustand stellt einen Zustand ohne Unterzustände dar.

FinalState Ein Endzustand ist ein besonderer Zustand, der angibt, dass sein Container (zusammengesetzter Zustand) verarbeitet wurde. Wenn dieser zusammengesetzte Zustand der Zustand der obersten Ebene der Zustandsmaschine ist, wird die Zustandsmaschine vollständig verarbeitet. Der Endzustand hat keine Ausgangsübergänge.

PseudoState Pseudostates sind Hilfszustände, die aus technischen Gründen erforderlich sind. Die folgenden sieben Arten von Pseudozuständen (Attribut: Typ) sind definiert:

• Initial: Der anfängliche Pseudozustand ist der Anfangszustand einer Zustandsmaschine oder eines zusammengesetzten Zustands. Zusammengesetzte Zustände haben höchstens einen Anfangszustand.

3.2. Verhaltenselemente 112

• deepHistory: (Deep Memory State) Ein Symbol, das die letzte aktive Konfiguration des kombinierten Zustands darstellt, der diesen Pseudozustand (H*) enthält. Zusammengesetzte Staaten haben höchstens einen dieser Knoten. Ein Übergang kann diesen Knoten als Quelle mit dem Ausgangszustand als Ziel verbinden. Dieser Übergang wird ausgeführt, wenn der zusammengesetzte Zustand zum ersten Mal aktiviert wird.

• flatHistory: (Shallow-Memory-Zustand) Stellt den letzten aktiven direkten Unterzustand des umschließenden zusammengesetzten Zustands dar, jedoch keinen verschachtelten Unterzustand (H). Zusammengesetzte Staaten können höchstens einen dieser Knoten haben.

• join: Wird zum Kombinieren (Synchronisieren) mehrerer Übergänge aus benachbarten Regionen verwendet. Diese Übergänge dürfen keine Bedingungen (Guards) haben. Abbildung 1 zeigt ein Beispiel. 4,63 Bei 190.

• Fork: Wird verwendet, um eine Transformation in mehrere Transformationen mit unterschiedlichen Zielen aufzuteilen (Parallelität). Transitionen, die diesen Knoten verlassen, können keine Bedingungen (Guards) haben. Abbildung 1 zeigt ein Beispiel. 4,63 Bei 190.

• Verbindungspunkt: Ein Knoten, der zum Verknüpfen mehrerer Transformationen verwendet wird. Sie werden verwendet, um komplexe Übergangspfade zwischen Staaten aufzubauen. Dieser Knoten kann verwendet werden, um mehrere Eingabetransformationen in einer einzigen Ausgabetransformation zu kombinieren. Dies nennt man „Fusion“. Knoten hingegen können verwendet werden, um einen Eingabeübergang in mehrere Ausgabeübergänge mit unterschiedlichen Bedingungen (Guards) aufzuteilen. Dies wird als statische bedingte Verzweigung bezeichnet. Ausgabeübergänge, deren Bedingung „falsch“ ergibt, werden deaktiviert. Eine vordefinierte Bedingung kann maximal für einen Übergang verwendet werden. Es wird als wahr ausgewertet, wenn alle anderen Bedingungen falsch sind. Abbildung 1 zeigt ein Beispiel. 4,66 Bei 193.

• choice: Ein Auswahlknoten, der dynamische bedingte Verzweigungen implementieren kann. Beim Erreichen eines Knotens wird der Zustand der ausgehenden Transition ausgewertet. Wenn mehrere Bedingungen gültig sind, wählt die Funktion einen der gültigen Übergänge aus. Wenn keine Einschränkungen gelten, ist das Modell nicht genau definiert. Abbildung 1 zeigt ein Beispiel. 4,67 Bei 193.

SyncState ist der Knoten, der zum Synchronisieren der gleichzeitigen Bereiche der Zustandsmaschine verwendet wird. Abbildung 1 zeigt ein Beispiel. 4.64 auf Seite 191. Der synchrone Zustand wird nicht zum Gleichzustand

113 Kapitel 3 Das Metamodell

(Zustand) wird einem booleschen Wert (aktiv, nicht aktiv) zugeordnet, aber einer Ganzzahl (endlich). Synchrone Zustände werden in Verbindung mit Fork und Join verwendet, um sicherzustellen, dass eine Region den angegebenen Zustand oder Status verlässt, bevor eine andere Region in den angegebenen Zustand oder die angegebenen Zustände eintreten kann, um den Unterschied zwischen der Anzahl der Eingabe- und Ausgabeübergänge „umzuschalten“. Alle eingehenden Transitionen müssen aus derselben Zone stammen und alle ausgehenden Transitionen müssen ihr Ziel ebenfalls in einer Zone haben.

SubmachineState Der Submachine-Status ist eine syntaktische Erleichterung, die Wiederverwendung und Modularität ermöglicht. Es stellt eine symbolische Abkürzung für eine Zustandsmaschine (Submachine) dar, die eine makroähnliche Erweiterung der Abkürzung durch die Zustandsmaschine ermöglicht. Die verwendete Zustandsmaschine wird Referenzzustandsmaschine genannt. Eine Zustandsmaschine, die untergeordnete Maschinen enthält, wird als Container-Zustandsmaschine bezeichnet. Tatsächlich stellt ein Untermaschinenzustand einen Aufruf der zugehörigen Zustandsmaschine dar.

Der referenzierte Zustandsautomat ist im Zustandsdiagramm nicht vollständig dargestellt. Übergänge in oder aus subautomatischen Zuständen werden durch Stub-Zustände (StubState) dargestellt (Beispiel: Abbildung 4.68, Seite 194).

StubState Ein Stub-Status kann in einer untergeordneten Zustandsmaschine erscheinen und einen untergeordneten Knoten einer Referenz-Zustandsmaschine (referenceState) darstellen. Es kann als Quelle oder Ziel eines Übergangs verwendet werden, der den Zustandsknoten einer Zustandsmaschine mit einem untergeordneten Zustandsknoten verbindet, der auf die Zustandsmaschine verweist.

3.2.4 Aktivitätsdiagramm

Das funktionale Verhalten von Modellelementen kann mithilfe von Aktivitätsdiagrammen oder Aktivitätsdiagrammen beschrieben werden. Sie werden verwendet, um den Ablauf komplexer Vorgänge (Flussdiagramme) und detaillierte (operative) Anwendungsfälle (Workflows) zu beschreiben.

Aktivitätsdiagramme sind spezielle Zustandsdiagramme. Bei Aktivitätsdiagrammen geht es nicht um Klassifikatoren, die Aktionen ausführen, sondern um die Reihenfolge und Bedingungen von Aktionen. Die meisten Zustände in einem Aktivitätsdiagramm sind Aktivitätszustände, die dadurch gekennzeichnet sind, dass sie eine Aktivität ausführen und der Abschluss dieser Aktivität einen Zustandsübergang auslöst.

Eine Aktivität hat mindestens eine ausgehende Transition. Aus Gründen der Groß- und Kleinschreibung werden mehrere ausgehende Übergänge verwendet. Aktivitätsdiagramme können gleichzeitige Aktivitäten darstellen. Bei parallelen Aktivitäten spielt die Reihenfolge keine Rolle. Abbildung 3.48 zeigt ein Aktivitätsdiagramm, das die wichtigsten Modellelemente enthält.

3.2. Verhaltenselemente 114

Synchronisierungsleiste

Aktivität

Entscheiden

Krankheit

wähle ein Getränk

Geben Sie Kaffeesatz in den Filter

Füllen Sie den Behälter mit Wasser

Sackhöhle

Setzen Sie den Filter in die Maschine ein

Schalten Sie die Maschine ein

Kaffeefilter

Kaffee servieren

Glysenhorn

trinken

[Kaffee finden]

[kein Kaffee]

[Cola entdecken]

[keine Cola]

Diagrammname: CoffeeChart Dateiname: D:\Home\Stephan\vuml\coffee.VobChart Typ: UML-Aktivitätsdiagramm

Abbildung 3.48: Teilzeitjobs für Programmierer (Java)

115 Kapitel 3 Das Metamodell

Aktion

Ion

Tate

bearbeiten

glauben

Europäische Union:

Wow

dünn

Verabscheuungswürdig

Mikrofon

Parameter

eine Frau

TS:

Parameter

Die Liste

Index

Antwort

rein

Verabscheuungswürdig

Mikrofon

Multiplikator

typisch

Alter:

Multiplikator

typisch

Alter

Simulation

Bitte

Tate

Kind

positiv

Stadt

Tate

bearbeiten

glauben

Europäische Union:

Wow

dünn

Verabscheuungswürdig

Mikrofon

Parameter

eine Frau

TS:

Parameter

Die Liste

Index

Antwort

rein

Verabscheuungswürdig

Mikrofon

Multiplikator

typisch

Alter:

Multiplikator

typisch

Alter

Kind

Apfel

Klage

Stern

Kommunikation

Standort

prüfen

Tate

ist C

Nku

mieten

:Zweite

eins

Kalibrierung

lSTA

Aktion

Aktivität

Gra

PHP

zwischen

rein

10.

.*1

+pa

Titi

0..*

Modul

Lyme

Eingeben

* *

+ Zusammenarbeit

Ent

TS * *

Stern

TEM

Archie

Das ist es

0..1

+con

Text

0..1

+werden

der dritte

oder

Stern

0..1

10..1

+zu

Karat

Science-Fiction

Stern

0..*

+em

Stern

Par

ganz

Das ist

Karat

Science-Fiction

Das ist

1 *

+Typ

e1 *

Objekt

Plasma

niedrig

Stern

Und

:Zweite

eins

+pa

an die Tür klopfen

Äther

+st

er aß

+Typ

elektronisch

Abbildung 3.49: Metamodell: Aktivitätsdiagramm

3.2. Verhaltenselemente 116

Die Metamodellklassen für Aktivitätsdiagramme sind in erster Linie Spezialisierungen der Zustandsmaschinen-Metamodellklassen (Abbildung 3.49).

Aktivitätsgraph Ein Aktivitätsgraph gibt das Verhalten eines Pakets, eines Klassifikators oder eines Verhaltensmerkmals (Kontext) an (Abbildung 3.49).

Partitionen unterteilen den Zustand (Inhalt) eines Aktivitätsdiagramms in Gruppen. Diese Gruppen werden auch Swimlanes genannt. Partitionen entsprechen typischerweise Organisationseinheiten im Geschäftsmodell (z. B. Einkauf, Vertrieb usw.). Partitionen haben keinen Einfluss auf die dynamische Semantik des Modells, sie tragen jedoch zu einem besseren Verständnis bei.

SubactivityState Ein Subaktivitätsstatus stellt eine Folge nichtatomarer Schritte dar, deren Ausführung „etwas“ Zeit in Anspruch nimmt. Ein untergeordneter Aktivitätsstatus ist ein untergeordneter Maschinenstatus, der ein verschachteltes Aktivitätsdiagramm ausführt.

Attributsemantik

isDynamic Boolescher Ausdruck, der angibt, ob die Aktivität gleichzeitig ausgeführt werden kann.

DynamicArguments bestimmt die Anzahl der parallelen Ausführungen der Zustands-Submaschine. Der Wert muss ein Array von Objektlisten sein, die jeweils die auszuführenden Argumente enthalten. Dieser Ausdruck wird ignoriert, wenn isDynamic false ist.

dynamische Vielfalt

Kardinalität, die die Anzahl paralleler Ausführungen staatlicher Operationen begrenzt. Wird ignoriert, wenn isDynamic falsch ist.

Semantische Pseudoattribute

Submaschine erbt von SubmaschineState. Stellt ein Aktivitätsdiagramm dar, auf das in einem untergeordneten Aktivitätsstatus verwiesen wird. Ein Aktivitätsdiagramm muss einen Anfangszustand und einen Endzustand haben.

ActionState Ein Aktionsstatus stellt die Ausführung einer atomaren Aktion dar, normalerweise einen Aufruf einer Operation.

Ein Aktionszustand ist ein einfacher Zustand mit einer Eingabeaktion, dessen einziger Ausgabeübergang durch den Abschluss der Eingabeaktion ausgelöst wird. Ein Aktionszustand kann als Teil seiner Eintrittsaktion mehrere Aktionen haben, aber

117 Kapitel 3 Das Metamodell

Es gibt keine äußeren Handlungen, inneren Übergänge oder Aktivitäten. Attributsemantik

isDynamischer boolescher Ausdruck, der angibt, ob die Operation (Eingabe) gleichzeitig ausgeführt werden kann.

DynamicArguments bestimmt die Anzahl der parallelen Ausführungen der Laufzeitzustandsoperation. Dieser Wert muss eine Liste von Objekten generieren. Jede Liste wird als Argument für die parallele Ausführung verwendet. Dieser Ausdruck wird ignoriert, wenn isDynamic false ist.

dynamische Vielfalt

Kardinalität, die die Anzahl paralleler Ausführungen staatlicher Operationen begrenzt. Wird ignoriert, wenn isDynamic falsch ist.

Semantische Pseudoattribute

Vom Staat geerbte Elemente. Zeigt eine Eingabeaktion an.

CallState Ein Anrufstatus ist ein Aktionsstatus mit nur einer Anrufaktion als Eingabeaktion. Der Anrufstatus wird zur symbolischen Vereinfachung verwendet.

ObjectFlowState Objektflusszustände definieren den Fluss von Objekten zwischen Aktionen in einem Aktivitätsdiagramm (siehe Abbildung 3.50). Zeigt die Verfügbarkeit einer Klassifikatorinstanz an, möglicherweise in einem bestimmten Zustand. Die Verfügbarkeit ist in erster Linie ein Ergebnis des Betriebs.

Objekt[Zustand]

Aktivität 1 Aktivität 2

Diagrammname: ObjektflussChart Dateiname: D:\Home\Stephan\vuml\actUntitled1.VobChart Typ: UML-Aktivitätsdiagramm

Abbildung 3.50: Als Ergebnis der Aktivität 1 befindet sich das Objekt im angegebenen Zustand. Aktivität2 übernimmt den Zustand des Objekts.

Aktionsgenerierende Objekte durch Aktionszustände können als Fluss von Objekten modelliert werden, der durch den Abschluss von Aktionszuständen ausgelöst wird. Die Verwendung von Objekten in nachgelagerten Aktionszuständen kann als ausgehende Übergänge von Objektflusszuständen modelliert werden, während Flusszustände eingehende Übergänge von Aktionszuständen sind.

3.2. Verhaltenselemente 118

Attributsemantik

isSynch Boolescher Ausdruck, der angibt, ob der Objektflussstatus als Synchronisierungsstatus verwendet wird.

Semantische Pseudoattribute

Typ repräsentiert den Klassifikator des Objekts. Klassifikatoren können vom Typ ClassifierInState sein (siehe unten), d. h. sie können einen Zustand angeben.

Der Eingabe- oder Ausgabeparameter des Parameterobjekts. Parameter müssen einen Typ und eine Richtung haben, die mit dem Klassifikator (Typ) kompatibel sind.

Stereotypensemantik

«signalflow» Wird zur Hervorhebung verwendet, wenn der Flusszustandstyp des Objekts Signal ist.

ClassifierInState ClassifierInState gibt einen Klassifikator (Typ) in einem bestimmten Zustand (inState) an. Diese Art von Klassifikator kann auch in statischen Strukturdiagrammen und Kollaborationen verwendet werden, um beispielsweise Objekte anzuzeigen, die nur dann wichtig sind, wenn sie sich in einem bestimmten Zustand befinden.

Pseudozustände (Siehe auch Seite 111.) In Aktivitätsdiagrammen können Pseudozustandszweige und Verbindungsübergänge in und aus Pseudozuständen jeden Zustandsknoten (Zustandsscheitelpunkt) als Quelle oder Ziel haben. Im Gegensatz zu Zustandsmaschinen gibt es bei der Verwendung von Fork und Join bei zusammengesetzten Zuständen keine Einschränkungen.

Kapitel 4

Werkzeugunterstützung und Konsistenz

Zusätzlich zu den allgemeinen Anforderungen an UML-Tools wird in diesem Kapitel die Möglichkeit beschrieben, dass Tools Konsistenz (Widerspruchsfreiheit) gewährleisten oder Konsistenzprüfungen ermöglichen können, um Widersprüche und Unvollständigkeiten in UML-Systemspezifikationen zu verhindern oder zu erkennen.

Als Beispiel für bestehende Tools wird Rational Rose 98 vorgestellt. Rational Rose selbst enthält nur wenige Optionen zur Konsistenzprüfung, bietet jedoch Möglichkeiten zur Verwendung von Skripten zur Konsistenzprüfung und Modellvervollständigung.

Es erklärt, wie Teile von UML-Diagrammen (Klassendiagramme, Interaktionsdiagramme und Zustandsdiagramme) auf UML-Metamodellklassen abgebildet werden und welche Konsistenzbedingungen zwischen Modellelementen bestehen (kein Anspruch auf Vollständigkeit).

Die Skriptsprache von Rational Rose 98 (kurz Rose) stellt eine eigene Implementierung des UML-„Metamodells“ dar, das Rose verwendet. Die Zuordnung von Diagrammfragmenten zu Rose-Metamodellklassen zeigt, welche Konsistenzprüfungen mithilfe von Skripten in Rose implementiert werden können.

4.1 Anforderungen an UML-Tools

Die Modellierung von Softwaresystemen mittels UML erfordert Werkzeugunterstützung. In einem realen Entwicklungsprojekt können bereits wenige Anwendungsfälle zu vielen verschiedenen, teilweise komplexen Diagrammen führen. Änderungen an einem Diagramm führen zu anderen Änderungen an zugehörigen Diagrammen. Beispielsweise führt ein Operationsaufruf für eine Operation, die im Interaktionsdiagramm nicht vorhanden ist, zu einer Inkonsistenz, wenn die empfangende Objektklasse die Operation nicht deklariert. Wenn Sie den Namen einer Klasse in einem Diagramm ändern, müssen Sie auch den Namen in den anderen Diagrammen ändern. Es entstehen also Kosten

119

4.1. Anforderungen an UML 120-Tools

Nicht nur wegen der zeitaufwändigen Neuzeichnung von Diagrammen, sondern auch, weil die Diagramme miteinander „synchronisiert“ werden, um ein konsistentes Systemdesign zu gewährleisten, das jedes kostengünstige Framework ohne Tool-Unterstützung übertreffen würde.

UML-Tools müssen die folgenden Funktionen unterstützen:

• Diagramme zeichnen: Ein Tool sollte nicht nur alle komplexen Diagramme einfach zeichnen können, sondern auch die Notation von Diagrammelementen verstehen und unterstützen, ohne die Freiheit des Modellierers einzuschränken. Wenn beispielsweise zwei Klassen miteinander verbunden sind, kann das Verschieben einer Klasse nicht dazu führen, dass die Verbindungslinie der Klassen durch die andere verläuft.

Das Tool muss mindestens die Semantik von UML verstehen, sodass eine grundsätzlich falsche Verwendung von Modellelementen ausgeschlossen ist und vor inkonsistenter Verwendung gewarnt wird.

Das Tool sollte automatisch Änderungen an der Spezifikation von Modellelementen im gesamten Modelldiagramm anwenden.

• Fachwörterbücher: Das Tool muss die zentrale Speicherung von Fachbegriffen aus der Anwendungsdomäne unterstützen, um Kommunikationsunterbrechungen zwischen Entwicklern und Benutzern oder Fachdomänenexperten zu minimieren.

• Navigation: Das Tool soll die Navigation im Modell erleichtern, beispielsweise soll es möglich sein, Modellelemente durch verschiedene Diagramme zu verfolgen.

• Mehrbenutzerunterstützung: Das Programm muss es mehreren Benutzern ermöglichen, an einem Modell zu arbeiten, ohne sich gegenseitig zu beeinträchtigen.

• Konsistenzprüfung: Da UML-Modelle während des Modellierungsprozesses nicht durchgängig konsistent sein können, muss das Tool auf Wunsch des Benutzers eine dem Entwicklungsstand entsprechende Konsistenzprüfung ermöglichen. Je früher eine Inkonsistenz gefunden wird, desto kostengünstiger ist das Debuggen.

• Codegenerierung: Das Tool muss in der Lage sein, aus den (aufwändig zusammengetragenen) Modellinformationen Codeschnipsel in der gewünschten Implementierungssprache zu generieren. Auch hier ist eine Konsistenzprüfung vor der Codegenerierung sinnvoll.

• Reverse Engineering: Da mit UML auch bestehende Systeme dokumentiert werden können, muss das Tool in der Lage sein, Modelle aus vorhandenem Code zu generieren. Zusammen mit der Codegenerierung ermöglicht dies das sogenannte Round-Trip-Engineering, bei dem Änderungen in der tatsächlichen Implementierung des Systems im UML-Modell des Systems erkannt werden können.

121 Kapitel 4 Tool-Unterstützung und -Konformität

• Dokumentation: Das Tool muss die Dokumentation von Modellelementen, auch über externe Dokumentation, ermöglichen und bei Bedarf alle Informationen zu den Modellelementen generieren, z. B. in welchen Diagrammen und mit welchen anderen Modellelementen aufgebaut wird. Modellelemente werden verwendet.

• Wiederverwendbarkeit: Ein Vorteil des objektorientierten Ansatzes, unabhängig davon, ob er in einer objektorientierten Sprache entworfen oder implementiert wurde, ist die Wiederverwendbarkeit bestehender objektorientierter Systeme. Daher muss das Tool nicht nur in der Lage sein, Teilmodelle aus früheren Projekten zu importieren, sondern diese auch mit importierten Komponenten auszuführen.

Eine Datenbank bestehender (und validierter) Modelle ist hilfreich, um die Wiederverwendung zu unterstützen. In diesem Fall ist auch eine Datenbank mit Analyse- und Entwurfsmustern wünschenswert. Diese Muster stellen (abstrakte) Lösungen für häufige Probleme dar, die in der Praxis verifiziert und bewährt wurden.

• Anpassbarkeit und Skalierbarkeit: Das Tool muss sich anpassen oder erweitern lassen, um den Anforderungen einer bestimmten Anwendungsdomäne gerecht zu werden, beispielsweise der Modellierung von Geschäftsprozessen oder der Modellierung von Echtzeitsystemen.

• Schnittstellen zu anderen Werkzeugen: Das Werkzeug muss über Schnittstellen zu anderen Werkzeugen verfügen, die in der Systementwicklung eingesetzt werden, wie z. B. Programmierumgebungen (Editoren, Compiler, Debugger), Projektmanagement, Konfiguration und Versionsverwaltung.

• Interoperabilität mit anderen UML-Tools: Das Tool muss in der Lage sein, UML-Modelle zu exportieren und aus anderen Tools zu importieren.

4.2 Konsistenz

Das UML-Metamodell definiert Modellelemente in Form abstrakter und konkreter Metamodellklassen, Regeln für die Verwendung von Modellelementen sowie daraus resultierende Semantiken und Bedingungen, die die mögliche Verwendung basierend auf Modellelementspezifikationen einschränken. Klassen sind beispielsweise generalisierbare Modellelemente, die durch Attribute und Operationen spezifiziert und durch Generalisierung miteinander verbunden werden können, sofern bestimmte Bedingungen nicht verletzt werden (z. B. Mehrfachdeklarationen von Attributen in Klassen und Oberklassen). Die Existenz einiger Modellelemente setzt die Existenz anderer Modellelemente voraus. Beispielsweise geht eine Nachricht, die eine Operation für ein Objekt aufruft, davon aus, dass das Objekt auf einer vorhandenen Klasse basiert, die die aufzurufende Operation deklariert.

4.2. Konsistenz 122

Bei der Modellierung eines Systems mittels UML wird das System in der Regel durch mehrere miteinander verbundene Sichten (Use-Case-Sicht, logische Sicht etc.) beschrieben. Jede Ansicht besteht in der Regel aus mehreren Diagrammen und Diagrammtypen, die wiederum aus Modellelementen bestehen.

Semantische grafische Darstellungen und Systeme

Spezifikation

er weiß

Amo

Tun

Leib

ene

UML-Metamodell (dargestellt in UML-Notation)

Es beinhaltet:

• abstrakte Metaklassen (ModelElement, Classi-fier, Relationship usw.),

• Konkrete Metaklassen (Klassen, Attribute, Assoziationen usw.), ihre Instanzen (Modellelemente)

Eigene grafische Darstellung und/oder Spezifikation

aus der Vorlage verwendet werden

• Zusammenfassen und in Beziehung setzen

Gesicht.

Das Metamodell definiert möglicherweise die Semantik von Metaklassen

Verantwortlichkeiten und erforderliche Beziehungen zwischen Modellelementen

und Bedingungen, die Modellelemente spezifizieren,

Dies unterscheidet sich auch von der Beziehung zu anderen Elementen des Modells

kann hängen.

UML-Notation

Führe meinen Gott dorthin

• Grafische Darstellungen interpretieren

semantische Kontextposition

zepte (nicht vorwärts zugeordnet

ändern).

• Beschreiben Sie verschiedene Optionen

zeige Mo-

Dell-Informationen (Standard).

Informationen zu

alternative Darstellung

Werkzeugraum)

Tun

Leib

ene

Metamodell-Beispiel (formales UML-Modell, normalerweise nicht sichtbar)

• Besteht aus Instanzen konkreter Metaklassen (z. B.

Klasse „Person“ und Eigenschaft „Name“).

• Kann als Objektgraph dargestellt werden, dessen Objekte sind

Objekte und Links zu Klassen oder Assoziationen

Basierend auf dem Metamodell.

UML-Modell (grafische Darstellung)

Besteht aus mehreren ineinandergreifenden

Umfassende Sicht auf das System.

Diese Ansichten umfassen den Durchmesser

Gras, ein Element des Systems

Gegenstände und ihre Wechselbeziehungen

Anforderungen spezifizieren und darstellen.

Sicherung

beschreiben

Semantische und

bedingtes Symbol

Abbildung 4.1: Modellansicht des Metamodells, der Metamodellinstanzen und der Benutzer.

Formal kann dieses UML-Modell auch durch Metamodellinstanzen (Modelle) beschrieben werden (siehe Abbildung 4.1), wobei UML-Modellelemente Instanziierungen von Metamodellklassen sind. In der UML-Notation wäre dies ein Einzelobjektdiagramm mit Objekten und Links, die auf den Klassen und Assoziationen des Metamodells basieren (siehe Abbildung 4.2). Durch die Verwendung nur weniger Modellelemente wird diese Metamodellinstanz so unübersichtlich, dass niemand ernsthaft versucht, eine Metamodellinstanz eines UML-Modells mit mehreren Diagrammen darzustellen.

123 Kapitel 4 Tool-Unterstützung und -Konformität

Abbildung 4.2: Die Person-Klasse als Instanz des Metamodells.

4.2. Konsistenz 124

Diagramme und Ansichten von UML-Modellen, die Beziehungen zwischen Modellelementen zeigen, zeigen Ansichten eines Teils des Beispielmetamodells.

Ein UML-Modell ist konsistent oder konsistent mit einem UML-Metamodell, wenn die durch Diagramme und Ansichten beschriebenen Metamodellinstanzen vorhanden sind. In diesem Fall ist die Bedingung des Metamodells erfüllt, das heißt, die Sicht der Metamodellinstanz und die Sicht des Systems widersprechen sich nicht.

Da ein UML-Modell aus miteinander verbundenen Ansichten und Diagrammen besteht, reicht es nicht aus, zu prüfen, ob jedes einzelne Diagramm die Bedingungen des Metamodells erfüllt, d. h. die Prüfung, ob das UML-Modell die Bedingungen des Metamodells erfüllt, muss auf einer äquivalenten Schnittmenge basieren Metamodellinstanz.

4.2.1 Zweck der Konsistenzprüfung

Wie jedes Projekt stehen auch Softwareentwicklungsprojekte unter Kostendruck. Betrachtet man den Aufwand für die Fehlererkennung und -beseitigung in der Softwareentwicklung ([Bal98], S. 286), wird deutlich, dass der Schwerpunkt auf Fehlervermeidung und, da Fehler nie völlig ausgeschlossen werden können, auf Fehler bei der Früherkennung gelegt werden muss . Ein Tool kann helfen, indem es die inkonsistente Verwendung von Modellelementen nicht zulässt oder eine inkonsistente Verwendung kennzeichnet. Das Tool unterstützt Konsistenzprüfungen zu vom Benutzer festgelegten Zeitpunkten und hilft so, Fehler zu erkennen, die aufgrund der Komplexität des Modells selbst von aufmerksamen oder kritischen Lesern des Modells leicht übersehen werden können. Daher ist die Prüfung „einfacher“ Konsistenzbedingungen nicht zu unterschätzen.

4.2.2 Probleme bei der Konsistenzprüfung (toolbasiert)

Eine vollständige, werkzeuggestützte Sicherstellung bzw. Verifizierung der Konformität von UML-Modellen ist aus mehreren Gründen nicht möglich:

1. In praktischen Anwendungen von UML ist es für Modellierer nicht ungewöhnlich, nicht nur wohlgeformte Modelle zu entwickeln, sondern auch bestimmte Elemente zu vereinfachen, die für Konsistenzprüfungen erforderlich sein könnten (Modellunvollständigkeit).

2. Während des Lebenszyklus des Modells wird sich das Modell ständig ändern, sodass es unmöglich ist, die Konsistenz ständig aufrechtzuerhalten. Daher muss das Tool Inkonsistenzen zulassen und den Benutzer dabei unterstützen, zu einem bestimmten Zeitpunkt eine Konsistenzprüfung durchzuführen.

3. Die werkzeuggestützte Konformitätsprüfung erfordert Werkzeuge zum Verständnis der UML-Syntax und -Semantik. Die Definition von UML bleibt dem Modell überlassen

125 Kapitel 4 Tool-Unterstützung und -Konformität

In vielen Fällen können Hersteller die Form wählen, in der Informationen im Modell gespeichert werden (natürliche Sprache, Pseudocode, OCL). Dadurch erhöht sich die Ausdruckskraft der Sprache auf Kosten der Möglichkeit einer werkzeuggestützten Konsistenzprüfung.

4. Das UML-Metamodell beschreibt die UML-Semantik, aus der sich weitere Konformitätsbedingungen ableiten lassen, die nicht explizit im Metamodell formuliert sind, sondern vor der Verifizierung identifiziert werden müssen (Vollständigkeitsproblem).

5. Die Abbildung von UML-Modellen auf Metamodellinstanzen oder Metamodellklassen ist nicht immer ausreichend formal definiert. Für Interaktionsdiagramme auf Beispielebene gibt es im Kollaborationskontext keine entsprechende Metamodellklasse, während die Metamodellklassen für Interaktionsdiagramme auf Spezifikationsebene in der verwendeten Literatur nicht erwähnt werden, mit Ausnahme von [OMG99] (Unvollständiges UML-Metamodell).

6. Die Implementierung von UML-Modellen in einer Programmiersprache impliziert andere Konformitätsbedingungen, z. B. unterstützt Java keine Mehrfachvererbung, was außerhalb der hier verwendeten Definition eines konsistenten UML-Modells liegt, aber dennoch von Tools unterstützt werden sollte.

4.2.3 Hypothesenwerkzeuge zum Aufbau konsistenter Modelle

Ein UML-Metamodell ist ein logisches Modell, das die Semantik von UML erklärt, und kein physisches Modell, das Toolimplementierungen beschreibt. Tools zur Unterstützung und Überprüfung der Konsistenz von UML-Modellen müssen das logische UML-Metamodell in irgendeiner Weise implementieren.

Als konzeptionelle Grundlage für das Tool-Metamodell kann das UML-Metamodell dienen (Abbildung 4.3). Das UML-Metamodell muss auf spezifische Implementierungsdetails zugeschnitten und unter anderem um Metamodellklassen zur Darstellung von Modellelementen erweitert werden (die Metamodellklasse PresentationElement existiert bereits im Metamodell). Die Präsentationsoptionen eines Tools sind im Allgemeinen eine Teilmenge der in [OMG99] angegebenen Optionen.

Ein Tool kann die Erstellung konsistenter Modelle auf verschiedene Weise unterstützen:

• Inkonsistenzverhinderung: Dieses Tool verhindert Verstöße gegen Konformitätsbedingungen, indem es Verstöße gegen bestimmte Bedingungen nicht zulässt (z. B. inkonsistente Modellierung von Verallgemeinerungen zwischen Klassen und Schnittstellen).

4.2. Konsistenz 126

welche

dagegen sein

Kilogramm

Nadelholz

Was

Aber

Definition

Lun

nd S

extrem

em-

Spezifikation

Junge Leute

Benehmen

wir sind

kze

elektronisch

Metamodell

eins

L-M

elektronisch

Tun

Mich

-NEIN

Tati

Ausweis

MAUT

erklären

Tonne)

Bass

Fes

außen:

• ab

Stella

kte

elektronisch

Mädchen

In (ModelElement, Classi-

Eisen

, Beziehung

USW

.),

• Beton

zehn Meter

elektronisch

Mädchen

en(Klasse, Attribut, Assoziation

Verband

USW

.), D

zwei Menschen

Vorgänger

Beispiel

um (

Modell

Lele

Mann

Ö)

elektronisch

Gras

pH-Wert

Was

Aber

Definition

Lun

gleich

Zen dich

keine/keine

für

Spezifikation

Junge Leute

Benehmen

eins

Modell

ls b

Entz

die Erde

• G

Vitalität

Aris

Hier

Erfordern

es ist ein

Berg

Benehmen

zart

wie

Ausweis

in Metern

elektronisch-

Kyle

Ecke

Europa

er weiß

ein Model

Ich definiere

Start

Zimmertemperatur

d.h. S

Aber

D-Typ

ist Reis

elektronisch

Mädchen

ich, m

elektronisch-

Lich

und und n

Internet-TV

Vollendet

Jedoch

Pause

wie

in Metern

Modell

Lele

Mann

Dez

Aussaat

Nämlich B

bearbeiten

Pistole

Generation

bearbeiten

d.h. S

Tempo

Junge Leute

Benehmen

ist Reis

Modell

Lele

Mann

Oh,

sterben

zurückkehren

von D

für B

Jedoch

hängend z

Wer bist du

zwei Menschen

Modul

sie

Lyme

Körper

unzutreffend

B-

Generation

er kann

eins

Ota

Titan

Idee

• Zweite

rläu

Onkel

sterben

Gras

pH-Wert

Was

Aber

Definition

Lunge d

das ist p

Aber

Tisk

Henne

Betrug-

dramatisch verbessern

(für

rwar

Teilung von Reis

Anwendung

Ö-

Tati

•Zweite

Esch

Raib

Ausführung

Schießen

Und

öffentlicher Verkehr

Ö-

zart

für

Aber

Definition

Lun

in Metern

Ö-

Tun

Lymphom

Format

Ion

usl

Flügel

von

Für mich

Material

Format

Ion

von zwei

genießen

für

andere

geboren

Evan

Aber

Definition

Lun

Generation

, Ja

ßt

frei

Iran

Reis

Produktion

wir sind

kze

Woche)

wir sind

kze

elektronisch

-er weiß

existieren

von

Graf

• NEIN

gehaltenen

Frühlingsfest

verzeihen

öffentlicher Verkehr

eine Person

Und du

er weiß

ein Model

Blätter

NEIN

Das ist es

Wei

ja so

Was

wir sind

kze

bearbeiten

d.h. S

Aber

D-Typ

Das ist

eins

der erste

Also.

• Zweite

Weil

Onkel

eins

L-M

Ethylamin

von

Graf

eins

er weiß

Geist

Ecke

, sterben

für

sichtbar

selbst

Das ist

Betrieb

sehen

Modell

Lele

Mann

o b

Entz

die Erde

(sie

Erste

iter

3, Einführung-

Element

)

• sterben

er weiß

Geist

Ecke

vertreten

erheben

Widerstand

zwei Menschen

pH-Wert

Husten

sie

Was

enb

anksc

Mantel

Modellebene

er weiß

existieren

von

sie

Ausführung

Volksbefreiungsarmee

r(f

Spezifikation

Bier

, Europäische Union.

Ein

NEIN

Ich kann

Bar

Und du

-Modell

Europäische Union)

•Zweite

Das ist es

H T

außen

Vorgänger

Beispiel

rein d

ist k

Onkre

zehn Meter

elektronisch

Mädchen

em (

Zum Beispiel

Karat

Shanghai

"durchgehen

Sohn"

bearbeiten

in einem

drei

Aber

"Süd

e“）。

• Kalium

Installieren

Und

Jack

Zeitunterschied

Gras

Aber

ges

erklären

ähm

Äh,

innen

B-

Affe

Und ich

malen

Karat

Ecke

oder

. A

Berg

Benehmen

zart

Tun

er weiß

ein Model

ls b

Asien

Wohlwollen.

eins

L-M

von

Graf

(Gras

pH-Wert

Was

Aber

Definition

Lunge)

Bass

Fes

außen

Ausführung

Schießen

existieren

eins-

Grau

Und

sic

hte

unzutreffend

übertakten

als

extrem

Äh.

sterben

sic

hte

Das ist es

Henne

außen

Scharf

Gras

Es ist bei

Mann

Und

Ness

ältere Schwester-

Zeit

ich und ich

Stunde

Boca

Mutter

B B

Jedoch

Pause

ezif

Eitelkeit

lauf dich

Und

Arzt

sie

wir sind

kze

angegeben

Seeschwalbe

Modul

Graf

(Was

Verbot

eins

L-M

von

Graf

uns

europäische Union

Ent

eins

übertakten

eins

Was

Verbot

K a

bgeb

Feuer

, sterben

Geld

ich sterbe

Hal

Osten fünf

onsi

sten

Boden

als

Generation

Japp

rüft

wir sind

konnten

Substantiv

Ekzem

Volksbefreiungsarmee

r's

welche

eins

nur

kama

ING

elektronisch

Generation

verwenden

Hund

Bass

Ton

IBT

Geld

überprüfen

von

Feng

ich eins. C

Der dritte

sterben

verwenden

Titan

urc

als

wir sind

kze

e B

elektronisch-

anwenden

Karat

Bass

Ton

IBT

Abbildung 4.3: Ein hypothetisches Werkzeug (eine Erweiterung von Abbildung 4.1)

127 Kapitel 4 Tool-Unterstützung und -Konformität

• Konsistenzunterstützung: Das Tool unterstützt die Modellierung konsistenter Modelle und bietet eine konsistente Auswahl an Optionen, wenn die Spezifikation von Modellelementen auf anderen Modellelementen basiert (Objekte basieren beispielsweise auf Klassen).

• On-Demand-Konsistenzprüfung: Das Tool bietet die Möglichkeit, das erstellte Modell zu benutzerdefinierten Zeitpunkten auf Verstöße gegen Konsistenzbedingungen zu überprüfen.

Da das Tool auch die Erstellung inkonsistenter Modelle ermöglichen muss, müssen die Konsistenzbedingungen, deren Verletzung auf jeden Fall vermieden werden darf, sorgfältig ausgewählt werden. Zur Kategorie der vermeidbaren Inkonsistenzen zählt die fehlerhafte Verwendung von Modellelementen, beispielsweise zur Modellierung von Generalisierungsbeziehungen zwischen Klassen und Schnittstellen. Wenn Sie sich das Metamodell Ihres Tools als physisches Datenbankschema vorstellen, können Sie die Einhaltung bestimmter Konsistenzbedingungen (z. B. kann eine Eigenschaft nur einmal in einer Klasse deklariert werden) gewährleisten, indem Sie diese als Integritätsbedingungen für die Datenbank implementieren.

Solche Implementierungen können zu Problemen führen, wenn das Tool inkonsistente Modelle aus anderen Tools importieren kann. Ein weiteres Problem entsteht, wenn Modellelemente aus einem Modell entfernt werden müssen, von denen andere Modellelemente abhängen. Beispielsweise deklariert ein Operationsaufruf in einem Interaktionsdiagramm ein Objekt für die entsprechende Operation basierend auf seiner Klasse. Mit Tools, die eine Verletzung dieser Konsistenzbeschränkung vermeiden, wären Klassenlöschvorgänge unmöglich oder würden zu kaskadierenden Löschvorgängen von Modellelementen führen. Keine der beiden Optionen ist im Hinblick auf die Benutzerfreundlichkeit akzeptabel.

Ein Werkzeug, das in einem bestimmten Fall eine konsistente Auswahl an Möglichkeiten bietet, muss in diesem Fall auch eine konsistente Auswahl an Möglichkeiten bereitstellen, d. h. die Erstellung anderer Modellelemente ermöglichen, auf denen die Spezifikation basiert. Wenn beispielsweise in einem Interaktionsdiagramm eine Operation für ein Objekt aufgerufen werden soll, wird die Operation der Objektklasse zur Auswahl angeboten. Wenn die Klasse die gewünschte Operation jedoch nicht bereits deklariert, sollte es möglich sein, die gewünschte Operation aus diesem Kontext heraus zu deklarieren.

Ein mit einem Tool erstelltes UML-Modell beschreibt immer das interne Modell des Tools, wohingegen nur ein konsistentes UML-Modell eine Instanz eines vorhandenen Metamodells beschreibt. Ein mit einem Tool erstelltes UML-Modell beschreibt eine Instanz eines vorhandenen Metamodells und ist in dem Sinne konsistent, dass das interne Modell des Tools die Konformitätskriterien erfüllt. Hierzu muss die Konsistenzbedingung überprüft werden, das Tool verhindert keine Verletzung der Bedingung.

4.3. Rational Rose 98 128

4.2.4 Konsistenzprüfung als Informationsproduzent

Wenn das Modell auf Konformität überprüft wird und Inkonsistenzen festgestellt werden, sollte das Tool folgende Informationen liefern:

• eine Konsistenzbeschränkung verletzt wird,

• Modellelemente, die zu Inkonsistenzen und Inkonsistenzen führen

• Schlagen Sie Maßnahmen zur Beseitigung von Inkonsistenzen vor.

Bei der Systemspezifikation mittels UML werden Modelle mit unterschiedlichem Spezifikationsgrad erstellt. In einem konzeptionellen Modell ist das Modell noch unvollständig, d. h. Attribute und Operationen sind nicht vollständig spezifiziert, während dies in einem umsetzungsspezifischen Modell nicht mehr der Fall sein sollte. Anhand der validierten Konsistenzbedingungen soll der Benutzer feststellen können, ob die Verwendung von Modellelementen inkonsistent ist, die Spezifikation von Modellelementen inkonsistent ist oder die Inkonsistenz auf ein unvollständiges Modell zurückzuführen ist.

4.3 Die Rose der Vernunft 98

Rational Rose 98 ist ein kommerzielles UML-Tool von Rational Software Cooperation (siehe www.rational.com), dem Unternehmen, in dem Booch, Rumbaugh und Jacobson die erste Version von UML entwickelt haben. Rational Rose 98 (im Folgenden Rose genannt) basiert auf der UML 1.11-Version und kann in MS Windows und kommerziellen Unix-Systemen verwendet werden. Die Unix-Version scheint eine Portierung der Windows-Version zu sein, die einen kleineren Leistungsumfang (4.3.2) und deutlich bessere Reaktionszeiten aufweist.

4.3.1 UML-Modelle in Rational Rose 98

Anwendungsfalldiagramme, Sequenzdiagramme, Kollaborationsdiagramme, Klassendiagramme, Zustandsdiagramme, Komponentendiagramme und Anwendungsdiagramme können alle in Rose modelliert werden. Rose unterstützt keine Objektdiagramme und Aktivitätsdiagramme. Die Windows-Version verfügt über eine Erweiterung, die auch zur Modellierung von Aktivitätsdiagrammen verwendet werden kann, Rose erkennt jedoch keine Diagrammsemantik und Aktivitätsdiagramme, die mit dieser Erweiterung erstellt wurden, können nicht auf nachfolgende Versionen von Rose übertragen werden, wenn diese (echte) Aktivitätsdiagramme unterstützen.

UML-Modelle in Rose bestehen aus Ansichten (siehe auch Abschnitt 2.4) und Paketen (Abbildung 4.4).

Version 11.1 ist der unmittelbare Vorgänger von Version 1.3

129 Kapitel 4 Tool-Unterstützung und -Konformität

Abbildung 4.4: Rational Rose 98: Im linken Bereich werden die Strukturkomponenten des Modells durch Pakete dargestellt. Im rechten Bereich wird das Diagramm in einem Fenster mit veränderbarer Größe angezeigt. Modellelemente können per Drag & Drop in das Flächendiagramm rechts übertragen werden.

4.3. Rational Rose 98 130

Die Use-Case-Ansicht besteht aus Akteuren und Use-Cases, die in einem Use-Case-Diagramm dargestellt und durch Pakete weiter strukturiert werden können. Anwendungsfälle können mithilfe von Sequenzdiagrammen, Kollaborationsdiagrammen und Klassendiagrammen spezifiziert werden, d. h. sie befinden sich in der Baumstruktur unterhalb der Anwendungsfälle (linker Bereich in Abbildung 4.4). Akteure werden in Rose ähnlich wie Klassen behandelt und können durch Attribute und Operationen oder bestenfalls durch Zustandsdiagramme spezifiziert werden.

Business Views können auch als Pakete erstellt werden. Die logische Sicht besteht aus Klassendiagrammen, in denen neben Klassen, Schnittstellen, Akteuren und Beziehungen auch Pakete und Paketabhängigkeiten dargestellt werden können. Jede Klasse kann durch höchstens ein Statechart spezifiziert werden. In Rose können auch Anwendungsfalldiagramme, Sequenzdiagramme und Kollaborationsdiagramme in Business Views modelliert werden. Aus Sequenzdiagrammen können passende Kollaborationsdiagramme (und umgekehrt) generiert werden, wobei Änderungen in einem Diagramm auch auf das andere passende Diagramm übertragen werden.

Die Komponentenansicht in Rose besteht aus einem Komponentendiagramm, das nach Paketen strukturiert werden kann. Komponenten verfügen über mehrere vordefinierte Stereotypen, deren grafische Darstellung durch individuelle Icons unterstützt wird. Komponenten können Klassen und Schnittstellen zugewiesen werden. Diese Informationen werden beispielsweise beim Generieren von Code für Java verwendet. Pivot-Diagramme der Komponentenansicht (Interaktionsdiagramm, Zustandsdiagramm und Aktivitätsdiagramm) fehlen in der Komponentenansicht von Rose.

Die Bereitstellungsansicht in Rose enthält nur ein Bereitstellungsdiagramm oder Verteilungsdiagramm. Verbindung zur Komponente kann nicht angegeben werden.

In Rose kann jedes Diagramm mit einem Kommentar markiert werden, entweder im Klartext oder in Form eines Rechtecks mit Ohren (siehe Abbildung 2.12, Seite 20), der mit einem Vorlagenelement verknüpft werden kann. Die meisten Modellelemente können in Rose über einen beliebigen Text dokumentiert werden (wenn ein Modellelement ausgewählt ist, wird es im kleinen Fenster in der unteren linken Ecke von Abbildung 4.4 angezeigt). Für eine detailliertere Dokumentation können vorhandene Modellelemente 2 in einer Baumstruktur mit Dateien und Internetadressen verknüpft werden.

Klassifikatoren (Klassen, Schnittstellen usw.) und manchmal auch andere Modellelemente werden nur einmal im Modell erstellt, können aber in mehreren Diagrammen verwendet werden. Daher kann eine Änderung der Spezifikation von Modellelementen auch zu Änderungen führen, die in anderen Diagrammen dargestellt werden. Für einige Modellelemente können Sie die im Diagramm angezeigten Informationen anhand des Diagramms auswählen. Für eine Klasse beispielsweise die Granularität der Operation (nur der Operationsname oder die gesamte Operationssignatur) und der Umfang der anzuzeigenden Informationen (Eigenschaften und Operationen können einzeln ausgeblendet werden).

2 zeigt keine Beziehungen zwischen Modellelementen.

131 Kapitel 4 Tool-Unterstützung und -Konformität

Wird bald eingestellt. Weitere Versionsfunktionen:

• Akteure und Schnittstellen können durch ihre Symbole oder durch ihre Standarddarstellungen visualisiert werden.

• Die Größenänderung von 2D-Modellelementen (Klassen, Komponenten usw.) kann automatisch von Rose oder manuell vom Benutzer vorgenommen werden.

• Die Größe des Diagramms kann verändert (gezoomt) werden.

• Rose kann das Layout der Modellelemente im Diagramm „anpassen“ (Menü „Extras“, Layoutdiagramm). Diese Funktion muss jedoch mit Vorsicht verwendet werden, da die „Optimierung“ nicht rückgängig gemacht werden kann.

• Werden Modellelemente aus der Modellübersicht (linker Bereich in Abbildung 4.4) in ein Diagramm übertragen und bestehen Beziehungen zwischen diesen Elementen, wird dies im Diagramm angezeigt.

• Es gibt zwei Möglichkeiten, Modellelemente aus einem Diagramm zu entfernen. Wird ein Modellelement einfach aus dem Diagramm entfernt, ist es weiterhin im Modell vorhanden und wird in der Modellübersicht zusätzlich zu den Beziehungen angezeigt. Die zweite Möglichkeit besteht darin, Modellelemente aus dem Modell zu entfernen. Das Entfernen einer Beziehung (Assoziation, Generalisierung usw.) aus einem Diagramm kann zu Problemen führen, wenn die Beziehung in keinem Diagramm dargestellt wird. Da die Beziehung auch nicht in der Übersicht angezeigt wird, kann sie vom Modellierer nicht mehr visuell erfasst werden, obwohl sie im Modell noch vorhanden ist.

• Von einem Modellelement aus können Sie zu dem Diagramm wechseln, in dem sich das Modellelement befindet, oder zu anderen Modellelementen, die für die Verbindung mit diesem Element angegeben sind. Dadurch kann die Verwendung von Modellelementen im Modell nachverfolgt und nicht mehr sichtbare Zusammenhänge aufgedeckt werden.

• Einige Diagramme können auch in die Booch- oder OMT-Notation (rück)konvertiert werden.

4.3.2 Weitere Funktionen von Rational Rose 98

Rose unterstützt mehrere Programmiersprachen, d. h. UML-Modelle können sprachspezifisch erweitert werden und Code kann aus UML-Modellen generiert werden. In manchen Fällen ist sogar ein Round-Trip-Engineering möglich. Beim Modellieren mehr

4.3. Rational Rose 98 132

Unterstützen Sie mehrere Sprachen gleichzeitig. Rose unterstützt C++, Java, Small-Talk, Ada, Visual Basic, Oracle 8 usw. und kann auch IDL (Interface Definition Language) für CORBA-Anwendungen (Common Object Request Broker Architecture) und DDL-Datenformulare (Data Description Language) generieren für Datenbanken.

Der Unix-Version fehlt die Unterstützung für Visual Basic, Smalltalk, Oracle 8 usw., während die Windows-Version mehr Visual C++ (Microsoft)-Unterstützung und Integration mit anderen Microsoft-Produkten (z. B. MS Repository, MSVisual Source Safe) bietet.

Rose unterstützt mehrere Benutzer gleichzeitig und ermöglicht jedem Benutzer einen privaten Arbeitsbereich. Modelländerungen in diesem Bereich sind nicht global betroffen. Änderungen können für andere nur sichtbar gemacht werden, indem ein Konfigurationsverwaltungs- und -kontrollsystem (CMVS, z. B. Rational ClearCase oder Microsoft SourceSafe) umgangen wird. Enthält ein Tool zur grafischen Darstellung der Unterschiede zwischen zwei Modellen (visuelles Diff-Tool).

Rose verfügt über eine Schnittstelle (Rose Extensibility Interface (REI)), die Zugriff auf die Rose-Anwendung selbst, Diagramme und Rose UML-Modellelemente bietet (Abbildung 4.5). Rose Script3 kann diese Schnittstelle verwenden, um die manuellen Funktionen von Rose zu automatisieren. Auch sogenannte „Rose Automation Objects“ können diese Schnittstelle nutzen und eröffnen die Möglichkeit, Funktionen aus anderen Rose-Anwendungen über OLE (Object Linking and Embedding) auszuführen oder umgekehrt Rose-Funktionen aus anderen Anwendungen auszuführen. Rose fungiert als Controller oder Server.

Rosa

Anwendung

Diagramm

Modell

Element

Rosa

Skalierbarkeit

Schnittstelle

Rosa

Straßenkarte

Rosa

Automatisierung

Abbildung 4.5: Rose Extensibility Interface (REI)

3A Rose Scripting Language ist eine erweiterte Version der Summit BasicScript-Sprache (www.summsoft.com) mit Ähnlichkeiten zu MS Visual Basic.

133 Kapitel 4 Tool-Unterstützung und -Konformität

4.3.3 Konsistente UML-Modelle und Rational Rose 98

Rose unterstützt die Erstellung konsistenter UML-Modelle auf alle in Abschnitt 4.2.3, Seite 125 genannten Arten: Inkonsistenzverhinderung, Konsistenzunterstützung und Konsistenzprüfung bei Bedarf.

Rose weist einige Inkonsistenzen zurück, die aus falsch modellierten Beziehungen resultieren. Inkonsistenzen durch die Angabe von Modellelementen können nicht vermieden werden. Beispielsweise kann ein Eigenschaftsname in einer Klasse mehrfach verwendet werden.

Wenn die Spezifikation eines Modellelements auf einem anderen basiert, bietet Rose (größtenteils!) eine konsistente Auswahl, dass ein Modellelement mit einem beliebigen Text angegeben werden kann, ohne einen Verweis auf das Basiselement herzustellen. Sie können angeben, welche Klassen und Schnittstellen eine Komponente implementiert. Rose stellt hier eine Liste von Klassen oder Schnittstellen bereit, die aus diesem Kontext (Komponentenspezifikation) nicht erweitert werden können. Wenn Operationen für Objekte in einem Interaktionsdiagramm aufgerufen werden müssen, stellt Rose Operationen für die Klasse des Objekts (einschließlich geerbter öffentlicher Operationen) als Auswahl zur Verfügung. Alternativ kann die Klasse um die in diesem Kontext gewünschte Aktion oder einen beliebigen Text erweitert werden, der eine nicht vorhandene Aktion darstellt.

Rose verfügt nur über wenige Konsistenzprüfungen, die es auf Anfrage durchführen kann. Der Menüpunkt „Modell prüfen“ des Menüs „Extras“ prüft das Modell auf nicht aufgelöste Referenzen. Ein Modellelement (z. B. ein Objekt) kann auf ein anderes Element (z. B. eine Klasse) verweisen, das nicht existiert. In diesem Fall kann die Referenz nicht aufgelöst werden. Dieser Befehl prüft mehrere Konsistenzbedingungen, auch einzeln (je nach Diagramm).

In einigen Fällen ist es möglich, vor der Codegenerierung eine sprachabhängige Syntaxprüfung durchzuführen, wodurch weitere Fehler oder Inkonsistenzen gefunden werden, aber leider nicht alle. Rose erkennt mehrere Deklarationen eines Attributs weder als Inkonsistenz in UML noch als Syntaxfehler in Java. Fehler werden erst entdeckt, wenn der Java-Compiler den Code übersetzt.

Mit Hilfe von Rose Script können auf Wunsch weitere Konsistenzprüfungen implementiert werden (siehe Kapitel 5). Da die Konsistenzprüfung auf der Grundlage des internen Modells des Tools erfolgt, wird im nächsten Abschnitt kurz das Tool-Metamodell von Rose vorgestellt. Das Modell zeigt die Informationen, die ein Modellierer in einem Rose UML-Modell angeben kann und die Rose semantisch erkennt.

4.4. RATIONAL ROSE Metamodellierungstool 98 134

4.4 Rational Rose 98 Tool-Metamodell

Die Klassenhierarchie kann aus der Rose Script-Dokumentation abgeleitet werden, und Rose Script kann seine Klassen verwenden, um Informationen über das UML-Modell in Rose zu untersuchen und das Modell zu ändern. In diesem Abschnitt werden die wichtigsten hierfür benötigten Klassen sowie einige ihrer Eigenschaften und Operationen vorgestellt. Aus den Namen von Attributen und Operationen können einige Assoziationen zwischen Klassen abgeleitet werden, die hier weder dokumentiert noch explizit gezeigt werden. Modellelemente, die in Anwendungsfall-, Komponenten- und Bereitstellungsdiagrammen verwendet werden, werden nicht erläutert, da sie den Rahmen dieses Artikels sprengen.

Da Rose diese Klassen ebenfalls verwendet, werden in den folgenden Abschnitten auch Spezifikationsmöglichkeiten für UML-Modelle in Rose beschrieben.

4.4.1 Die oberste Ebene der Klassenhierarchie

Die RoseObject-Klasse ist die allgemeinste Klasse in der Klassenhierarchie (Abb. 4.6) und stellt Operationen bereit, mit denen beispielsweise überprüft werden kann, ob ein Objekt zu einer bestimmten Klasse gehört oder auch als Objekt von angesehen werden kann eine bestimmte Klasse in einer anderen Klasse. Die Element-Klasse entspricht der UML-Metamodellklasse ModelElement. Das Namensattribut identifiziert den Namen des Elements, und Modell und Anwendung identifizieren das Modell oder die Anwendung (Rose), zu der das Element gehört.

Die RoseItem-Klasse (und ihre Unterklassen) stellen die Datenansicht der Modellelementspezifikation dar, während die RoseItemView-Klasse (und ihre Unterklassen) für die grafische Darstellung des Modellelements und seiner Spezifikation verantwortlich sind. RoseItems können als Prototyp erstellt, in Rose dokumentiert und mit externen Dateien oder Internetadressen verknüpft werden. OperationOpenSpecification öffnet in Rose ein Dialogfenster zur Angabe von Modellelementen.

Die Datenansicht eines Modellelements wird im Diagramm durch eine Ansicht (RoseItemView) dargestellt. Dadurch ist es möglich, die im Diagramm anzuzeigenden Informationen an den Zweck des Diagramms anzupassen. Jedes Diagramm (Diagramm) kann in Rose in einem beliebigen Text dokumentiert und mit Diagrammkommentaren versehen werden.

4.4.2 Diagramm Martin

In Rose können Sie beispielsweise mit der Maus Modellelemente für die grafische Anzeige auswählen. Diese Informationen können durch ein Rose-Skript (OperationGetSelectedItems, siehe Abbildung 4.7) abgefragt und später bei der Implementierung einer Konsistenzprüfung verwendet werden, um die Prüfung auf Teilbereiche des Modells anzuwenden.

135 Kapitel 4 Tool-Unterstützung und -Konformität

Rosa Objekt

CanTypeCast()IdentifyClass()IsClass()TypeCast()

rosa Artikel

DocumentationStereotypeExternalDocumentsLocalizedStereotype

AddExternalDocument()DeleteExternalDocument()GetRoseItem()OpenSpecification()

Element

Anwendungsmodell nennen

RoseItemView

ItemParentDiagramParentViewSubViewsXPositionYPosition

IsSelected() hat Item() und ParentView()

Diagramm

DocumentationItemsItemViews

Activate()AddNoteView()IsActive()Exists()RemoveNoteView()

Abbildung 4.6: Oberste Ebene der Rose-Klassenhierarchie

4.4. RATIONAL ROSE Metamodellierungstool 98 136

OperationActivate der limit Diagram-Klasse zeigt das entsprechende Diagramm in einem Rosettenfenster an. Dieser Vorgang wird später verwendet, um Modellelemente zu visualisieren, die zu Verletzungen von Konsistenzbeschränkungen führen können.

Diagramm

activate()GetSelectedItems()

Klassen Diagramm

Kategorie Eltern

AddAssociation()AddCategory()AddClass()AddUseCase()GetAssociations()GetCategories()GetClasses()GetClassView()GetSelectedCategories()GetSelectedClasses()GetUseCases()IsUseCaseDiagram()RemoveAssociation()RemoveCategory()RemoveClass()RemoveUseCase()

Zustandsdiagramm

Reihe

AddStateView()GetSelectedStates()GetSelectedStateViews()GetSelectedTransitions()GetStateView()GetStateViews()RemoveStateView()

Szenendiagramm

Instanzansicht

AddInstance()AddInstanceView()CreateMessage()DeleteInstance()GetDiagramType()GetMessages()GetSelectedLinks()GetSelectedMessages()GetSelectedObjects()RemoveInstanceView()

Bereitstellungsdiagramm

AddDevice()AddProcessor()GetDevices()GetProcessors()RemoveDevice()RemoveProcessor()

Moduldiagramm

Eltern-Kind-System

AddModule()AddSubsystem()GetModules()GetSelectedModules()GetSelectedSubsystems()GetSubsystems()

Abbildung 4.7: Rose-Diagrammklasse

Für die interne Darstellung der sieben möglichen Diagrammtypen in Rose werden fünf Diagramm-Unterklassen verwendet. Die Klasse ClassDiagram ist für Klassen- und Anwendungsfalldiagramme verantwortlich. Sequenzdiagramme und Kollaborationsdiagramme können als (weitgehend) gleichwertig betrachtet werden und werden intern durch die ScenarioDiagram-Klasse dargestellt. Zustandsdiagramme, Komponentendiagramme und Bereitstellungsdiagramme werden durch die Klassen StateDiagram, ModuleDiagram und DeploymentDiagram dargestellt.

Die meisten Diagrammklassen verfügen über Operationen, über die auf ausgewählte Modellelemente detaillierter zugegriffen werden kann als mit OperationGet-SelectedItems.

137 Kapitel 4 Tool-Unterstützung und -Konformität

Die Parent-Eigenschaft der StateDiagram-Klasse gibt die Klasse an, zu der das Zustandsdiagramm gehört. Wie oben erwähnt, werden UML-Modelle in Rose mithilfe von Ansichten (Anwendungsfallansicht, Logikansicht usw.) und Paketen erstellt. attributeParentCategory gibt die Ansicht oder das Paket an, zu der die Klasse oder das Anwendungsfalldiagramm gehört. Paketabhängigkeiten können in Klassen- und Anwendungsfalldiagrammen modelliert werden. Ein Diagramm, das nur Pakete enthält, wird auch Paketdiagramm genannt.

4.4.3 Modellelemente in Klassendiagrammen

Die Darstellungen von Klassen, Schnittstellen und anderen Modellelementen, die in Roses Klassendiagrammen verwendet werden können, werden durch Unterklassen von RoseItemView dargestellt (Abbildung 4.6). Die für die Spezifikation dieser Modellelemente verantwortlichen Klassen sind Unterklassen von RoseItem und werden in diesem Abschnitt erläutert (siehe Abbildung 4.8).

Die Class-Klasse stellt nicht nur Klassen dar, sondern modelliert auch Elemente, die als Klassen mit einem bestimmten Stereotyp dargestellt werden können, beispielsweise „Schnittstelle“. Obwohl die Spezifikation von Akteuren gegenüber Klassen streng ist, werden Schnittstellen selbst nicht semantisch erfasst; für Rose gibt es keinen Unterschied zwischen einer stereotypen Klasse und einer Schnittstelle, außer der Darstellung. Mit den Klassenfunktionen der Klasse können Sie mithilfe von Rose Script Beziehungen zu anderen Klassen hinzufügen, entfernen und festlegen. Attribute und Operationen einer Klasse werden von den Attributen- und Operations-Eigenschaften gespeichert. Diese Eigenschaften stellen sogenannte Sammlungen dar, über die auf die Eigenschaften und Operationen der Klasse zugegriffen werden kann. Grundsätzlich stehen alle vom Benutzer im Modell angegebenen Informationen auch in Rose Script zur Verfügung und können geändert werden. Klassen können als abstrakt markiert werden und ihre Sichtbarkeit (öffentlich, geschützt, privat), Kardinalität und Parallelität können angegeben werden. StateMachine gibt das eindeutige Zustandsdiagramm der Klasse an (falls vorhanden), das auch vom Rose-Skript (OperationCreateStateMachine) generiert werden kann.

Andererseits „kennen“ Attribute und Operationen auch ihre Klasse (AttributeParent-Class). Parameter für Operationen (Eigenschaftsparameter von Typsammlungen) werden durch Klassenparameter dargestellt.

Assoziations-, Realisierungs-, Abhängigkeits- und Generalisierungsbeziehungen werden durch die Klassen Association, RealizeRelation, ClassDependency und In-heritRelation dargestellt. Die Role-Klasse entspricht der AssociationEnd-Klasse des UML-Metamodells. Stellt Informationen dar, die durch ein Zuordnungsende angegeben werden. Die Rollen- bzw. Mitgliederseite einer Assoziation kann über AttributeRole1 oder Role2 erreicht werden. Dabei spielt es keine Rolle, ob das Assoziationsende die erste Funktion oder die zweite Funktion der Assoziation ist.

4.4. RATIONAL ROSE Metamodellierungswerkzeuge 98 138

Ross

Ecke

Reis

Ste

zerbrechlich

Simulation

offen

nSp

Seaver

Benehmen

N()

Karat

Abdomen

Schiene

Gesicht

aufwachsen

Utes

offen

Grund

Fehler

Pose

Kontrollzeit

Überprüfen

Auto

Verabscheuungswürdig

Leben

Betrug

aktuell

Kleber

Stern

TEM

Ashi

Dann

Plus

bei diesem

Laser

Hund(

ddA

aufwachsen

ute (

Gleichstrom

Mädchen

Abteilung

dünner Film

ncy(

eingeben

Erbe

verhältnismäßig

()A

ddO

pera

Hund(

ddR

elektronisch

eRel

()C

Reaktion

Das ist

TEM

Ashi

Innen(

Leben

E-Arsch

Laser

Hund(

Leben

eAtr

Angezogen werden

e()

Tun

USW

Mädchen

Abteilung

dünner Film

ncy(

Leben

eInh

Fehlerrate

Er()

Tun

Ecke

Das ist es

dCla

ss()

Tun

Äther

pera

Hund(

Leben

das ist nicht gut

Liga (

Leben

Das ist

TEM

Ashi

Innen(

Es ist bei

ssoc

Yacht

Papier

es()

nehmen

bei diesem

Laser

System

()G

USW

Mädchen

Abteilung

dünner Film

ncie

S()

nehmen

Binnenfluss

Reiter

lass uns gehen

Ion

()G

fleischig

Multiple Sklerose. Das

ssoc

Aktion

N()

nehmen

Rhea

Lizzie R

lass uns gehen

Ion

()G

Warten

Oles

()G

Warten

ubcl

Esel

S()

nehmen

neben

ercl

Esel

S()

es ist ein

assoziieren

Karat

ss()

bei diesem

Laser

Hund

Europa

geliebt

assoziieren

Karat

SSR

ole1

Papier

e2R

Oles

nehmen

Herzkrankheit

Antwort

Blätter

Nanogramm

Ole (

Warteschlange

Blätter

Papier

e()

Definition

assoziieren

Karat

ssN

Amen(

)

Karat

SSR

lass uns gehen

rein

nehmen

Betrug

Text

Karat

ss()

nehmen

neben

Auch

rCla

ss()

Karat

SSD

Epos

Denk

Lüge

Siliziumkarbid

Schaf

Nalit

arbeiten

Horizont

Schaf

Nalit

Pose

Kontrollzeit

Überprüfen

Atr

Angezogen werden

elektronisch

Betrug

trüben

Mann

Tepro

Eigentum

Europa

geliebt

Index

ortC

einführen

lPro

Eigentum

V initialisieren

Mut

Par

entC

Mädchen

Stern

zucken

Simulation

Rhea

Lizzie R

lass uns gehen

rein

nehmen

Betrug

Text

Karat

ss()

nehmen

neben

Auch

rCla

ss()

Papier

elektronisch

Karat

ssc

Ontario

Regen

Allergie

ssoc

Aktion

Pose

Kontrollzeit

Überprüfen

Buch

NDC

Scham

Reis

Eingeben

Auto

Verabscheuungswürdig

Leben

gesamt

Rega

prüfen

Papaya

Navigation

Beteiligung

Leck

Insel

Plus

Taste

()D

Leben

elektronischer Schlüssel

()G

USW

Mädchen

Name

e()

verhältnismäßig

Benehmen

neben

Auch

Name

elektronisch

Temperatur

Lüge

NT$ ()

Temperatur

neben

Auch

R()

nehmen

Lüge

NT$ ()

nehmen

neben

Auch

R()

offen

Grund

Betrug

aktuell

Kleber

implementieren

Vergleichen

Fehler

Pose

Kontrollzeit

Kontrolle

Corda

rtyP

alam

Äther

sie sind

tCla

SSP

Ostbahnhof

Blätter

System

Profi

Situation

ändern

Widerstand

ängstlich

nTipo

Aber

Zecken

Plus

Par

ganz

Das ist()

Tun

Ethernet P

alam

Äther

()R

emov

eAllP

alam

Äther

S()

Par

ganz

Das ist

Betrug

Boxenstopp

Wand

Testsubstanz

Simulation

Binnenfluss

Reiter

lass uns gehen

rein

Index

ortC

ONTR

von

zerreißen

schicken

Erfordern

Ouray

links

europäische Union

Abbildung 4.8: Die Rose-Metaklasse eines Modellelements, wie sie in einem Klassendiagramm erscheint.

139 Kapitel 4 Tool-Unterstützung und -Konformität

4.4.4 Modellelemente in Interaktionsdiagrammen

In Rose können Kollaborationsdiagramme nur auf Instanzebene modelliert werden. Sequenz- und Kollaborationsdiagramme auf Beispielebene bestehen aus Objekten (Instanzen), Links und Nachrichten (oder Reizen). In Rose werden diese Modellelemente für beide Diagrammtypen durch die gleichen Klassen repräsentiert (Abbildung 4.9).

assoziieren

LinkRole1LinkRole2LinkRole1VisibilityLinkRole2Visibility

AddMessageTo()AssignAssociation()DeleteMessage()GetMessages()UnAssignAssociation()

Information

Frequenzsynchronisation

GetSenderObject()GetReceiverObject()IsMessageToSelf()IsOperation()GetOperation()GetLink()

Objektinstanz

ClassNameLinksMultipleInstancesPersistence

AddLink()DeleteLink()GetClass()IsClass()

rosa Artikel

Stereotyp

openSpec()

Abbildung 4.9: Rose-Metaklassen für Modellelemente, die in Sequenz- und Kollaborationsdiagrammen erscheinen.

Die Klasse des Objekts (ObjectInstance) wird als Zeichenfolge (AttributeClassName) gespeichert. Wenn der Benutzer eine Klasse für das Objekt in Rose auswählt, kann diese mit OperationGetClass abgerufen werden. Die Links-Eigenschaft enthält die Sammlung von Links, die dem Objekt zugeordnet sind.

Verknüpfte Objekte in einem Kollaborationsdiagramm werden durch die Eigenschaften LinkRole1 bzw. LinkRole2 dargestellt. Im Gegensatz zu den zugehörigen Rollenattributen beziehen sich diese Attribute nicht auf das Linkende des Links. Allerdings kann Rose Script am Ende des Links die Sichtbarkeit angeben und abfragen. Links können vorhandenen Zuordnungen zugewiesen werden und erkennen Nachrichten, die über diese Verbindung gesendet werden.

Eine Nachricht kann mit einer Operation (IsOperation, GetOperation) verknüpft werden, die die Sender- und Empfängerobjekte und die zugehörigen Links kennt. Rose Script kann die Reihenfolge der Nachrichten nicht bestimmen. Europa

4.4. RATIONAL ROSE Metamodellierungstool 98 140

Die Reihenfolge kann in Rose nicht explizit angegeben werden. In einem Interaktionsdiagramm wird die Reihenfolge der Nachrichten durch ihre Anordnung entlang der vertikalen Achse des Diagramms impliziert. In einem Kollaborationsdiagramm ergibt sich die Reihenfolge aus der Reihenfolge, in der die Nachrichten erstellt werden.

4.4.5 Modellelemente in Zustandsdiagrammen

Ein Zustandsdiagramm enthält eine Zustandsmaschine, die aus Zuständen, Ereignissen, Übergängen und Aktionen als möglichen Reaktionen auf Ereignisse besteht. Roses Tools-Metamodell enthält die entsprechenden Klassen für diese Modellelemente (Abbildung 4.10).

Die StateMachine-Klasse bezieht sich auf das Zustandsdiagramm (StateDiagram), die zugehörige Klasse (ParentClass) und die Zustände und Übergänge, die in der Zustandsmaschine vorhanden sind. Eine Zustandsmaschine (Zustandsdiagramm) kann weitere verschachtelte Zustände enthalten. Operationen der StateMachine-Klasse ermöglichen den Zugriff auf Zustände und Übergänge der obersten Ebene oder alle Zustände und Übergänge einer Zustandsmaschine.

Diese Auswahlmöglichkeit gilt auch für Staaten. Beispielsweise identifiziert die Substates-Eigenschaft die unmittelbaren Unterzustände eines Staates, und die Operation „GetAllSubstates“ gibt alle Unterzustände eines Staates zurück. Ein Zustand „weiß“ über die damit verbundenen Übergänge und kann einen Zustand im Speicher enthalten. Ein Status kann Eingabe- und Ausgabeaktionen sowie persistente Aktionen (GetDoActions) enthalten, die ausgeführt werden, während der Status aktiv ist. Zustände in Rose können auch integrierte Übergänge enthalten, die basierend auf benutzerdefinierten Ereignissen „ausgelöst“ werden können. Verschobene Ereignisse können angegeben werden, indem die Aktion des zu verschiebenden (benutzerdefinierten) Ereignisses als „aufschieben“ angegeben wird.

Bei Rose besteht eine Aktion aus drei Teilen:

1. Der Name (AttributeName von classElement) ist eine Zeichenfolge, die die Aktion beschreibt. Muss der Name einer Operation, eines Signals oder einer Ausnahme sein. Allerdings stellt Rose dem Modellierer keine Auswahlmöglichkeit zur Verfügung und hat daher keinen Bezug zu entsprechenden oder ähnlichen Vorgängen.

2. AttributeArgument ist eine Zeichenfolge, die zum Speichern der Parameter der Operation verwendet wird.

3. Das Attribut target ist ebenfalls eine Zeichenfolge und nur beim Senden einer Aktion verfügbar. Es muss die Klasse oder das Objekt identifizieren, die das Signal empfängt. Auch hier bietet Roth keine Auswahl oder Verbindung zum entsprechenden Element an.

Eine Sendeoperation wird durch eine Rose dargestellt, die sich von einer Aufrufoperation unterscheidet. Dies ist in der UML-Version 1.3 nicht mehr der Fall.

141 Kapitel 4 Tool-Unterstützung und -Konformität

Übergang

GetSendAction()GetSourceState()GetTargetState()GetTriggerAction()GetTriggerEvent()RedirectTo()

Zustandsmaschine

Diagramm übergeordneter Zustand

AddState()DeleteState()GetAllStates()GetAllTransitions()GetTransitions()RelocateState() Status

HistoryParentStateParentStateMaschineStateKindSubStatesTransitions

AddDoAction()AddEntryAction()AddExitAction()AddState()AddTransition()AddUserDefinedEvent()DeleteAction()DeleteState()DeleteTransition()DeleteUserDefinedEvent()GetAllSubstates()GetDoActions()GetEntryActions()GetExitActions()GetUserDefinedEvents()RelocateState()

Fall

Parameter GuardCondition

getOperation()

Aktion

Argument Arvo

Element

Name

rosa Artikel

Stereotyp

openSpec()

Beziehung

Name des Anbieters

HasClient()HasSupplier()GetClient()GetSupplier()

Abbildung 4.10: Rose-Metaklasse für Modellelemente, die in einem Zustandsdiagramm erscheinen.

4.5. Klassendiagramm 142

Übergänge (ClassTransition) „kennen“ ihren Anfangs- und Folgezustand sowie zugehörige Ereignisse und Aktionen für Ereignisse.

Die GuardCondition-Eigenschaft der Event-Klasse markiert die Bedingung, unter der der Überwachungsübergang „ausgelöst“ wird. Aus einem benutzerdefinierten Ereignis, das zu einem Zustand gehört, kann eine zugehörige Aktion (Get-Action) abgeleitet werden.

4.5 Klassendiagramm

Das Klassendiagramm ist eines der wichtigsten und am häufigsten verwendeten Diagramme bei der Entwicklung objektorientierter Systeme. Sie legen die strukturellen und logischen Grundlagen für die Implementierung des Systems fest, auf denen die Spezifikation und Implementierung des Systemverhaltens basiert.

In diesem Abschnitt wird erläutert, wie die grafische Darstellung eines Modellelements eines Klassendiagramms eine UML-Metamodellinstanz oder eine Rose-Metamodellinstanz beschreibt. Der Vergleich von Metamodellinstanzen zeigt, wie gut Rose UML-Semantik erkennt und Konformitätsbedingungen, die in UML-Metamodellen definiert sind oder von Metamodellen abgeleitet werden können, mit der Skriptsprache von Rose überprüft werden können.

4.5.1 Klassen

Eine Klasse wird durch ein Rechteck dargestellt, das üblicherweise horizontal in drei Teile geteilt ist. Oben stehen Klassennamen, Eigenschaftswerte, Behauptungen und Stereotypen. Eigenschaften werden in der Mitte und Aktionen unten angezeigt. Wie im Bild gezeigt. 4.11 zeigt eine abstrakte Klasse ohne Attribute und stereotype Operationen. Abstrakte Klassen können durch {abstract}-Behauptungen oder kursiv geschriebene Klassennamen gekennzeichnet werden.

aus dem Namen der Klasse<>

Abbildung 4.11: Abstrakte Klasse mit Stereotyp

Abbildung 1 Klassenzuordnung Abbildung 4.11 ist ein Beispiel für ein Metamodell. 4.12. Die entsprechenden Metamodellteile sind in Abbildung 4 dargestellt. 3.5, Seite 44 (Klassen) und Abbildung 1. 3.28, S. 72 (Ausfahrmechanismus).

Abbildung 1 Klassenzuordnung 4.11 Die interne Datenstruktur von for Rose ist in der Abbildung dargestellt. 4.13.

143 Kapitel 4 Tool-Unterstützung und Konformität Diagrammname: ClassNotationMetaUMLCart Dateiname: ClassNotationMetaUML.VobChart Typ: UML-Objektdiagramm: Klasse

nome = KlassennameisRoot = falseisLeaf = falseisAbstract = trueisActive = false

: Stereotyp

nome = StereotypiconbaseClass = Klasse

Erweitertes Elementstereotyp

Abbildung 4.12: Darstellung stereotyper Klassen als Metamodellinstanzen

Diagrammname: KlasseNotationMetaRoseChart Dateiname: KlasseNotationMetaRose.VobChart Typ: UML-Objektdiagramm: Klasse

Name = KlassennameStereotype = StereotypAbstract = trueCardinality = nConcurrency = Sequential

Abbildung 4.13 Prototypklassen aus Sicht der RationalRose-Skriptsprache.

Die folgenden Informationen für eine Klasse in den Abbildungen 4.12 und 4.13 entsprechen einander:

Die UML-Beobachtung stieg

名称 NameisAbstract AbstractisActive Concurrency Concurrency kann in Rose die Werte Sequen-

zielgerichtet, geschützt, aktiv und synchron.

stereotype Stereotype In Rose ist Stereotype eine Eigenschaft der RoseItem-Klasse. Sie können ein Stereotyp aus der Liste auswählen oder ein neues erstellen. Es ist nicht möglich, den Namen des Stereotyps zu ändern (nicht zu verwechseln mit der Möglichkeit, einen anderen Stereotyp für ein Modellelement (RoseItem) auszuwählen).

Die Eigenschaften isRoot und isLeaf der im Metamodell angegebenen Klassen können in Rose nicht immer angegeben werden. Mit der Java-Erweiterung von Rose können Sie einen booleschen Wert (ähnlich wie isLeaf) für eine „Final“-Eigenschaft einer Klasse definieren, der bei der Codegenerierung berücksichtigt wird.

Konsistenzbedingungen für Klassen beziehen sich auf andere Modellelemente und werden in den entsprechenden Abschnitten behandelt.

4.5. Klassendiagramm 144

4.5.2 Eigenschaften

Kommentieren Sie Eigenschaften in der Klasse „Rechteck“ mit der folgenden Syntax: Sichtbarkeitseigenschaftsname '['base']'': 'type' = 'initial value' {'property string'}'

• Die Sichtbarkeit von Attributen wird durch „+“ (öffentlich), „#“ (geschützt) und „-“ (privat) gekennzeichnet.

• Attributzeichenfolgen werden zur Dokumentation von Behauptungen und Attributwerten verwendet.

• Bei Klassenattributen (Eigenschaften, deren Werte für alle Objekte der Klasse gelten) wird die gesamte Deklaration unterstrichen.

• Ein abgeleitetes Attribut wird durch einen Schrägstrich („/“) vor dem Attributnamen gekennzeichnet.

• Attribute können mit Stereotypen gekennzeichnet werden.

Bei der Anzeige von Eigenschaften ist es nicht immer notwendig, die vollständige Deklaration der Eigenschaft anzuzeigen (Abbildung 4.14). Es liegt in der Verantwortung des Tools, bestimmte Eigenschaften anzuzeigen oder Standardwerte für bestimmte Eigenschaften bereitzustellen, z. B. die Sichtbarkeit. Rose kann einzelne Attribute und Operationen einer Klasse in einem Klassendiagramm ausblenden und den Detaillierungsgrad festlegen, mit dem Attribute und Operationen angezeigt werden.

Klassenname

Eigenschaftsname:Typ=Anfangswert

Abbildung 4.14: Eigenschaften ohne Sichtbarkeitsdarstellung. Behauptungen, wie z. B. das Einfrieren, können an Eigenschaften angeheftet werden.

Abbildung 1. Attributzuordnung Abbildung 4.14 zeigt ein Beispiel für ein Metamodell. 4.15. Ein Auszug aus dem Metamodell ist in Abbildung 1 dargestellt. 3.10, S. 50. Behauptungen können mit Links an Eigenschaften angehängt werden.

Abbildung 1. Attributzuordnung Die interne Datenstruktur von 4.14 für Rose ist in der Abbildung dargestellt. 4.16.

Die folgenden Informationen eines Attributs in Abbildung 4.15 und Abbildung 4.16 entsprechen nacheinander:

145 Kapitel 4 Tool-Unterstützung und -Konformität

Diagrammname: AttributNotationUML-MetamellChart Dateiname: AttributNotationUML-Metamell.VobChart Typ: UML-Objektdiagramm: Attribute

name = AttributNameownerScope = instancevisibilityKind = publicinitialValue = Initialwertmultiplicity = 1changeability = changeabletargetScope = instância

: Klassenzimmer

nome = KlassennameisRoot = falseisLeaf = falseisAbstract = falseisActive = false

: Klassenzimmer

nome = TypisRoot = falseisLeaf = falseisAbstract = falseisActive = false

Eigentümertyp

Abbildung 4.15: Darstellung von Attributen als Metamodellinstanzen ohne Namespace-Mitgliedschaft. Es wird davon ausgegangen, dass Tools sinnvolle Standardwerte für nicht spezifizierte Eigenschaften definieren. Es ist auch möglich, DataType anstelle von Class als Typ zu verwenden.

: Klassenzimmer

name = className abstract = falseAttributes

: Attribute

名称 = AttributNameStatic = falseExportControlProperty = PublicAccessInitValue = InitialwertDerived = falseType = TypParentClass

Abbildung 4.16: Klassen und Eigenschaften aus der Skriptsprache Rational Rose. Die Parameter Attributes und ParentClass stellen die Zuordnung zwischen Class- und Attribute-Metaklassen dar. Die Attributes-Eigenschaft der Class-Metaklasse enthält eine Sammlung von Verweisen auf Klassenattribute.

4.5. Klassendiagramm 146

Die UML-Beobachtung stieg

Name NameownerScope Static-Instanz entspricht Static = falsevisibilityKind ExportControl-

Propertypublic entspricht PublicAccess

initialValue InitValuetype Typ In Rose ist Typ ein Attribut der Klasse

Attribute.

Die folgenden Informationen können der Abbildung nicht entnommen werden. 4.16 oder in einem Rose-Modell gespeichert:

• Die Basis 4 eines Attributs kann nicht direkt angegeben werden.

• Der Zielbereich kann nicht angegeben werden.

• Garantien können nicht direkt angegeben werden.

Abgeleitete Eigenschaften sind Aussagen über Eigenschaften, die Rose direkt stützen. Klassen können als „persistent“ oder „transient“ bezeichnet werden.

Die folgenden Konformitätsbedingungen und Optionen zu deren Überprüfung in der Rose-Ausgabe:

• Attribut-1: Kein Attribut darf mehr als einmal in einer Klasse deklariert werden ([OMG99], Seite 2-47).

Rose stellt fest, dass diese Bedingung nicht verletzt ist, aber überprüft werden kann.

• Attribut-2: Die Deklaration eines Attributs muss einen Typ enthalten.

• Attribut-3: Der Attributtyp muss im Modell (genauer: im Attribut-Namensraum) vorhanden sein (Abschlussbedingung).

Als Typ des Attributs werden die Klassifikatoren „Class“ und „DataType“ abgefragt. Diese gehören zur KlasseClass in Rose. Die Skriptsprache von Rose kann verwendet werden, um zu prüfen, ob eine Klasse mit diesem Typnamen vorhanden ist, und wenn ja, die fehlende Klasse im Modell zu erstellen (d. h. es ist kein Klassendiagramm vorhanden, das die Klasse enthält).

• Attribut-4: Ein vorhandener Standardwert muss innerhalb des Wertebereichs des Typs liegen.

4 Indirekt können Zusatzinformationen immer auch als Notizen auf Diagrammen oder als Dokumentation von Modellelementen vermerkt werden.

147 Kapitel 4 Tool-Unterstützung und -Konformität

Eine Überprüfung dieser Bedingung setzt voraus, dass das Tool den Wertebereich kennt. Dies könnte beispielsweise für primitive Typen erfolgen, deren Semantik oder Wertebereiche allgemein vereinbart sind.

4.5.3 Bedienung

Kommentieren Sie die Aktion am unteren Rand des Klassenrechtecks, wo die Klasse deklariert ist, mit der folgenden Syntax:

Name der Sichtbarkeitsoperation (Argumentliste): Rückgabetyp {Eigenschaftszeichenfolge}

• Sichtbarkeit entspricht der Sichtbarkeit des Attributs. Andere Arten der Sichtbarkeit können definiert werden. Sie müssen durch Werkzeugkonventionen oder in attributierten Zeichenfolgen dargestellt werden.

• Ein Rückgabetyp ist eine sprachabhängige Spezifikation des Typs (oder Typs, [OMG99], Seite 3-43) des Rückgabewerts einer Operation.

• Eine Parameterliste ist eine durch Kommas getrennte Liste formaler Parameter, die durch die folgende Syntax angegeben werden:

Typname: Ausdruckstyp = Standard

com

– Kunst ist im Inneren, im Äußeren und im Inneren. Es ist standardmäßig dort enthalten.

– Name gibt den Namen des Parameters an.

– Ein Typausdruck ist eine (sprachabhängige) Spezifikation eines Typs.

– Der Standardwert ist ein optionaler Wertausdruck für den Parameter.

– Eigenschaftszeichenfolgen indizieren Eigenschaftswerte und Behauptungen. Dazu gehören isQuery- und abstrakte Eigenschaften sowie die Angabe von Eigenschaften, die sich auf die Parallelität von Vorgängen auswirken.

• Klassenoperationen (Klassenbereich) sind unterstrichen.

• Die Methode oder der Algorithmus der Operation kann als Kommentar an die Operation angehängt werden.

• Vorgänge können vor ihrer Signatur mit annotierten Stereotypen gekennzeichnet werden, einschließlich Sichtbarkeit.

Bei der Anzeige einer Operation ist es nicht notwendig, alle angegebenen Attribute der Operation anzuzeigen ([OMG99]). Wie im Bild gezeigt. 4.17 zeigt das Beispiel, das im Folgenden verwendet wird.

4.5. Klassendiagramm 148

Klassenname

Operationsname (Parametername: Parametertyp = Standardwert): Rückgabetyp

Abbildung 4.17: Beispielnotation für Operationen

Aus betrieblicher Sicht sind die Parameter geordnet.

Der Typ des Parameters kann auch „DataType“ sein.

: Betrieb

name = OperationsnamevisibilityKind = publicconcurrency = sequenceownerScope = instanceisQuery = falseisRoot = falseisLeaf = falseisAbstract = false

: Umfang

name = Parameternamekind = inoutdefaultValue = Default-Wert

: Umfang

name=? type = return default = ?

: Klassenzimmer

Name = Typparameter

: Klassenzimmer

Name = Rückgabetyp

: Klassenzimmer

name = Name aus der Klasse

Typ

Eigentümer

Ressource

Abbildung 4.18: Beispielmetamodell für die Operationen in Abbildung 1. 4.17. Der Wert des Attributs „type“ wird zur Unterscheidung von Parameter- und Rückgabetypen verwendet. Da Rückgabetypen als Parameter behandelt werden, kann eine Operation mehrere Rückgabetypen haben.

Diagrammname: OperationNotationMetaRoseChart Dateiname: OperationNotationMetaRose.VobChart Typ: UML-Objektdiagrammkonzept verfügbar

Begriffliche Existenz

: Klassenzimmer

name = Name der Klassenoperationen

: Betrieb

name = BetriebsnameExportControlProperty = PublicAccessConcurrency = sequencialStereotypeReturnType = return typeParametersParentClass

: Umfang

name = ParameternameType = ParametertypInitValue = Default-WertConst = false

Abbildung 4.19: Interne Darstellung der Operationen in Abbildung 4.19. 4.17. Eine Klasse kennt ihre Operationen, eine Operation kennt ihre Klasse und ihre Parameter, aber Parameter kennen ihre Operationen nicht.

149 Kapitel 4 Tool-Unterstützung und -Konformität

Die Operationskarte 4.17 in Abbildung 1 ist ein Beispiel für das UMList-Metamodell. 4.18. Betriebsstereotypen und Garantien werden mit der Operation (falls vorhanden) verbunden sein.

Die Operationszuordnung 4.17 in Abbildung 1 wird zu einem beispielhaften Rose-Metamodell, wie in Abbildung 4.19 dargestellt.

Die folgenden Informationen in den Abbildungen 4.18 und 4.19 entsprechen einander:

Die UML-Beobachtung stieg

Name NamevisibilityKind ExportControl-

Propertypublic (UML) entspricht PublicAccess (Ro-se)

concurrencydefaultValue InitValueReturn-Typ ReturnType In Rose ist der Rückgabetyp kein Parameter.

Es handelt sich vielmehr um eine Eigenschaft einer Operation. Es kann nur ein Rückgabetyp angegeben werden.

Die folgenden Informationen können der Abbildung nicht entnommen werden. 4.19 oder in einem Rose-Modell gespeichert:

• Informationen, die dem AttributeOwnerScope der Operation-Metamodellklasse entsprechen, können nur in Modellen mit sprachspezifischen Rose-Erweiterungen beobachtet werden. Beispielsweise enthält die Java-Erweiterung eine entsprechende boolesche Eigenschaft Static.

• Weitere konfigurierbare Eigenschaften der Java-Erweiterung sind Abstract und Final (entsprechend den booleschen Eigenschaften abstract und isLeaf des Metamodells).

• Die Attribute isQuery und isRoot können nicht angegeben werden.

• Der Parametertyp kann nicht angegeben werden.

Für den Betrieb gelten folgende Konformitätsbedingungen:

• Operation-1: Eine Operationssignatur kann nicht mehrfach in einer Klasse deklariert werden. Genauer gesagt: Verhaltensmerkmale desselben Typs (Operation, Methode, Anweisung, die ein Signal empfängt) können in einem Klassifikator nicht dieselbe Signatur haben ([OMG99], S. 2-47).

• Operation-2: Parameternamen für Operationen müssen eindeutig sein ([OMG99], Seite 2-45).

• Aktion 3: Der Parametertyp muss im Modell vorhanden sein (Integritätsbedingung). Genauer gesagt: Der Parametertyp muss im Namensraum des Operationsklassifikators enthalten sein ([OMG99], Seite 2-45).

4.5. Klassendiagramm 150

• Operation-4: Klassen für abstrakte Operationen müssen abstrakt sein ([OMG99], S. 2-46), da Klassen mit abstrakten Operationen keine direkten Instanzen haben können.

Rose wird keinen Verstoß gegen diese Bedingungen feststellen. Die Überprüfung dieser Bedingungen kann jedoch in Rose implementiert werden.

4.5.4 Assoziationen

Binäre Assoziationen zwischen Klassen werden als Linien zwischen Klassen modelliert. Die Assoziation kann optional benannt werden und Stereotypen und Aussagen enthalten. Am Ende der Zeile werden der Klassenfunktionsname (optional mit Sichtbarkeit), die Basis und die Assertion (z. B. geordnet) angezeigt (Abbildung 4.20). N-äre Assoziationen werden mit zusätzlicher Notation dargestellt [OMG99], können aber nicht in Rose modelliert werden.

A und B

2..41..1

#Rollenname-B-Rollenname-A

2..41..1

Vereinsname<>

{Assoziationsbehauptung}

Abbildung 4.20: Beispielsymbole, die Rollennamen zugeordnet sind und die Sichtbarkeit von Rollennamen angeben.

Abbildung 1. Assoziationskarte Abbildung 4.20 ist ein Beispiel für ein Metamodell. 4.21. Bei Bedarf werden die Klischees und Garantien des Vereins bzw. des Vereinsschlusses über einen Link dem entsprechenden Objekt beigefügt.

Abbildung 4.22 zeigt eine Darstellung der Rose-Metamodell-Instanz von Abbildung 4.20. Die folgenden Informationen in den Abbildungen 4.21 und 4.22 entsprechen

a: Notizen von UML Rose

NameisNavigable Navigableaggregation Aggregate ist Rose, Aggregate ist ein boolescher Wert,

Unterscheiden Sie zwischen normalen Assoziationen und Aggregationen.

targetScope Static targetScope = instância entspricht Static = false.

Exportkontrolle der Sichtbarkeit mehrerer Kardinalitäten

151 Kapitel 4 Tool-Unterstützung und Konformität Diagrammname: AssociationNotationMetaUMLCart Dateiname: AssociationNotationMetaUML.VobChart Typ: UML-Objektdiagramm

: Klassenzimmer

Name = a

: Klassenzimmer

Name = b

: Assoziation beenden

name = Rollenname-AisNavigable = trueaggregation = nonetargetScope = instancemultiplicity = 1..1visibility = privateordering = unorderedchangeability = mutável

: Assoziation beenden

name = Rollenname-BisNavigable = trueaggregation = nonetargetScope = instancemultiplicity = 2..4visibility = protectedordering = unorderedchangeability = alterável

: Verband

name = Vereinsname

Typ

Verbindungstyp

verbinden

Abbildung 4.21: Beispiel des in Abbildung 1 zugehörigen Metamodells. 4.20 Ausgeschlossen sind Typ- und Gewährleistung.

Für Ross gelten folgende Einschränkungen:

• Rollen (Assoziationsenden) können in Rose nicht mit Stereotypen markiert oder mit Behauptungen verknüpft werden, obwohl Abbildung 4.22 etwas anderes sagt (genauer gesagt: die normale Benutzeroberfläche bietet diese Option nicht). Eine Zuordnung ist trotz der Existenz der Constraints-Eigenschaft weder dokumentiert noch über Skriptsprachen zugänglich.

• In Rose können nur binäre Assoziationen modelliert werden.

Für Joins gelten folgende Konsistenzbedingungen:

• Assoziation-1: Jede Assoziation muss eine eindeutige Kombination aus Assoziationsname und Assoziationsklassifikator sein ([OMG99], Seite 2-44). Das heißt, wenn zwischen zwei Klassifikatoren mehrere Assoziationen bestehen, muss der Assoziationsname vorhanden sein.

• Assoziation-2: Die Assoziation muss in mindestens einer Richtung navigierbar sein (Integritätsanforderung).

• Assoziation-3: Ein navigierbares Assoziationsende muss einen Funktionsnamen (Abschlussbedingung) haben.

4.5. Klassendiagramm 152

Diagrammname: AssoziationNotationMetaRoseChart Dateiname: AssoziationNotationMetaRose.VobChart Typ: UML-Objektdiagramm

: Klassenzimmer

Name = A

Verband

Name = AssociationsnameDerived = falseStereotype = StereotypRole1Role2RolesLinkClass

: Papier

Name = Rollenname-ANavigable = trueAggregate = falseStatic = falseCardinality = 1..1ExportControl = PrivateAccessClassStereotypeConstraintsAssociationKeysContainment = indefinido

: Papier

Name = Rollenname-BNavigable = trueAggregate = falseStatic = falseCardinality = 2..4ExportControl = ProtectedAccessStereotypeConstraintsAssociationKeysContainment = undefinedClass

: Klassenzimmer

Name = B

Abbildung 4.22: Interne Darstellung der Assoziation in Abbildung 1. 4,20 Rosen. Die Eigenschaften „Role1“ und „Role2“ der Association-Klasse beziehen sich auf die beiden Enden der Assoziation. Die Eigenschaft „role“ ist eine Sammlung von Member-Endungen, die von Autoren in Skriptsprachen nicht verwendet werden können. Diese Eigenschaft weist jedoch darauf hin, dass Rose auch n-äre Assoziationen unterstützen kann.

153 Kapitel 4 Tool-Unterstützung und -Konformität

• Assoziation-4: Durch eine Assoziation verknüpfte Klassifikatoren müssen zum Namensraum der Assoziation gehören ([OMG99], Seite 2-44).

• Rolle-1: Der Name einer Rolle (Pseudoattribut) relativ zu einer Klasse muss in der Menge aller Attribute und Pseudoattribute dieser Klasse eindeutig sein ([OMG99], Seite 2-44).

• Rolle-2: Ein durchsuchbares Assoziationsende muss einen Rollennamen (Gesundheitsstatus) haben.

Ein navigierbares Assoziationsende bedeutet, dass das Objekt über eine Pseudoeigenschaft, also die Implementierung der Eigenschaft und den Aufrufvorgang, auf das Assoziationsobjekt zugreifen kann. Bei der Java-Codegenerierung verwendet Rose diese Rollennamen als Eigenschaftsnamen (Pseudoeigenschaften) von Klassen.

Rose wird Verstöße gegen diese Bedingungen nicht feststellen.

4.5.5 Sonderverbände

Aggregation, Zusammensetzung, qualifizierte Assoziationen und Assoziationsklassen sind spezielle Assoziationen.

Aggregation und Zusammensetzung beschreiben Ganzteilbeziehungen. In einer Metamodellinstanz wird ein Ganzes in einer Aggregations- oder Kompositionsbeziehung durch eine Aggregation von Attributen der AssociationEnd-Klasse (die der Klasse zugeordnet ist, die das Ganze darstellt) angegeben. Aggregate in Rose werden durch Wertepaare Aggregate = true und Containment = ByReference oder Unspecified charakterisiert, und Kombinationen werden durch Aggregate = true und Containment = ByValue charakterisiert.

In einer Metamodellinstanz ist das qualifizierende Attribut mit dem Ende der Assoziation des Annotationsattributs verbunden. In Rose geben die attributeKeys von classRole einen Satz von Attributen an, die Instanzen des Assoziationsendes (das vom Metamodell verschiedene(!) Assoziationsende ist) partitionieren.

Assoziationsklassen werden in Metamodellinstanzen dargestellt, die denen in Abbildung 4.20 ähneln, mit dem einzigen Unterschied, dass Assoziationen nicht durch Instanzen von Association, sondern durch Instanzen von AssociationClass dargestellt werden. In Rose identifiziert das LinkClass-Attribut (sofern vorhanden) die Klasse, die die Merkmale (Attribute) der zugehörigen Klasse darstellt. In [OMG99] wird nicht ausgeschlossen, dass Assoziationsklassen auch Verhaltensmerkmale aufweisen können.

Für Sonderverbände gelten zusätzliche Konformitätsbedingungen:

• Aggregation-1: Nur binäre Assoziationen können Aggregations- oder Kompositionsbeziehungen sein ([OMG99], Seite 2-44).

Dies ist für Rose leicht zu beobachten, da ihm die Möglichkeit fehlt, n-äre Assoziationen zu modellieren.

4.5. Klassendiagramm 154

• Aggregation-2: Nur ein Assoziationsende kann Aggregation oder Kombination erkennen ([OMG99], Seite 2-44).

Ross erfüllte diese Bedingung.

• Zusammensetzung-1: Ein „Teil“ kann nur vollständig zu einem Ganzen gehören, dh die maximale Kardinalität der assoziativen Enden, die das Ganze charakterisieren, beträgt höchstens 1 ([OMG99], S. 2-45).

Modellelement-Tag-Werte 0..10..1

Stereotyp 0..10..1

Abbildung 4.23: Zusammensetzung mit Kardinalität 0..1: Attributwert (getaggter Wert) gehört zu Modellelement oder Stereotyp.

Wenn die Kardinalität 0..1 beträgt, kann eine „Teil“-Klasse als „Teil“ an mehreren Kompositionsbeziehungen mit jeweils einer Kardinalität von 0..1 teilnehmen (siehe Abbildung 4.23). Eine Kardinalität von genau 1 schließt die Teilnahme als „Seite“ an anderen zusammengesetzten Beziehungen aus.

• Qualifizierungsspezifikation-1: Es können nur binäre Assoziationen qualifiziert werden.

• Qualifikation-2: Der Name eines qualifizierten Attributs darf nicht der Name eines Attributs einer Klasse sein, deren Objektzugriff durch Qualifikation verbunden ist.

Die Eigenschaften, die eine Assoziation qualifizieren, sind die Eigenschaften der Assoziation (siehe [BRJ99a], S. 165). Eine qualifizierte Spezifikation bedeutet, dass auf die Implementierung einer Reihe von Kopien (normalerweise eine Kopie) über den Wert zugegriffen werden kann.

• Assoziationsklasse 1: Assoziationsendenamen (Funktionsnamen) und Assoziationsklassenattributnamen müssen eindeutig sein ([OMG99], Seite 2-44).

• Assoziationsklasse 2: Eine Assoziationsklasse kann nicht zwischen sich selbst und irgendeinem Modellelement definiert werden ([OMG99], Seite 2-44), dh eine Assoziationsklasse kann keine Assoziationsklasse sein (Abbildung 4.24).

Rose erfüllt diese Konsistenzbedingung.

• Assoziationsklasse 3: Eine Assoziationsklasse kann nicht mit mehreren Assoziationen verknüpft werden (siehe [BRJ99a], S. 168), da sie selbst eine Assoziation ist.

Rose erfüllt diese Konsistenzbedingung.

155 Kapitel 4 Tool-Unterstützung und -Konformität

Diagrammname: New DiagramChart Klassendateiname: clsUntitled2.VobChart Typ: UML-Klasse DiagramClass 1

Level 2

Abbildung 4.24: Beispiel für inkonsistente Modellierung von Assoziationsklassen.

4.5.6 Zusammenfassung

Generalisierungsbeziehungen können nicht nur zwischen Klassen (Abbildung 4.25), sondern auch zwischen Schnittstellen (siehe Abschnitt 4.5.7), Signalen (siehe Abschnitt 4.5.10) und Kollaborationen bestehen. Verallgemeinerungen können benannt werden und verfügen über Diskriminatoren, die die abstrakten Merkmale der Verallgemeinerung beschreiben.

fortschrittlich

Unterklasse

allgemeiner Name

Abbildung 4.25: Eine einfache Generalisierungsrelation ohne Diskriminator

Die Abbildungen 4.26 und 4.27 zeigen Darstellungen von Abbildung 1. 4.25 als Beispiel für ein Metamodell.

In Rose können nur Verallgemeinerungen zwischen genau zwei Klassifikatoren benannt und mit einem Prototyp beschriftet werden. In Rose ist es sogar möglich, die Sichtbarkeit von Generalisierungsbeziehungen zu spezifizieren, die im Metamodell nicht vorhersehbar sind. Wenn eine Oberklasse zwei Unterklassen hat, kann diese Beziehung mit einer Generalisierungsbeziehung von einem Vorfahren und zwei Nachkommen modelliert werden. Rose unterstützt diese Möglichkeit, allerdings gibt es in diesem Fall keine Möglichkeit, eine Verallgemeinerungsbeziehung anzugeben, d. h. Name, Stereotyp und Sichtbarkeit können nicht angegeben werden. Rose hat weder die Möglichkeit, einen Diskriminator anzugeben, noch eine Möglichkeit, eine Behauptung für eine Generalisierungsbeziehung (disjunkt/überlappend und unvollständig/vollständig) anzugeben, die sich normalerweise auf mehrere Generalisierungen bezieht.

Durch Generalisierungen verbundene Modellelemente haben nicht nur Konsistenzbedingungen, sondern auch deren Inhalte. Unter anderem Immobilien

4.5. Klassendiagramm 156

Diagrammname: GeneralisierungNotationMetaUML Diagrammdateiname: GeneralisierungNotationMetaUML.VobChart Typ: UML-Objektdiagramm

: Klassenzimmer

Name = Superklasse

: Klassenzimmer

Name = Unterklasse

: Zusammenfassung

name = verallgemeinerter benannter Diskriminator

Reihe

Spezialisierung

zusammenfassen

Kind

Abbildung 4.26: Darstellung von Abbildung 4.25 als UML-Metamodellinstanz.

: Klassenzimmer

Name = Superklasse

: Klassenzimmer

Name = Unterklasse

: Vererbungsverhältnis

Nome = generischer Name StereotypeSupplierNameExportControl

Abbildung 4.27: Darstellung von Abbildung 4.25 als Instanz des Rose-Metamodells.

Erben Sie die Aktionen und Bindungen der Klasse entsprechend der angegebenen Sichtbarkeit.

• Generalization-1: Der als Root markierte Klassifikator darf keine Vorfahren haben ([OMG99], Seite 2-51).

• Generalisierung-2: Ein als Blatt markierter Klassifikator kann keine Nachkommen haben ([OMG99], Seite 2-51).

In Rose kann diese Eigenschaft in einer Java-Erweiterung (der Final-Eigenschaft) angegeben werden.

• Generalisierung-3: Ein Klassifikator darf kein Unterklassifikator oder Superklassifikator seiner selbst sein, d. h. ein Graph, der eine Vererbungshierarchie darstellt, wobei Klassifikatoren Knoten und Verallgemeinerungen Kanten sind, ohne jegliche Zyklen (siehe [OMG99], S. 2-51).

Rose erfüllt diese Konsistenzbedingung.

157 Kapitel 4 Tool-Unterstützung und -Konformität

• Generalisierung-4: An einer Generalisierung beteiligte Modellelemente müssen vom gleichen Typ sein, das heißt, sie müssen die gleiche konkrete Metamodellklasse haben (siehe [OMG99], S. 2-52).

Klassen, Schnittstellen, Signale und Komponenten sind (konkrete) Metamodelle verschiedener Klassen.

• Generalisierung-5: Durch Generalisierung verbundene Modellelemente müssen im gleichen Namensraum enthalten sein (siehe [OMG99], Seite 2-51).

• Attribut-5: Die Namen von Attributen und Pseudoattributen einer Klasse (einschließlich geerbter) müssen eindeutig sein, dh sie können nicht in Unterklassen umdefiniert oder ersetzt werden.

Diese Bedingung umfasst Attribut-1- und Rollen-1-Bedingungen.

• Operation-5: Konkrete Nachkommen einer abstrakten Klasse müssen ihre abstrakte Operation implementieren, dh eine Operation (Abschlussbedingung) mit derselben Signatur wie die nicht-abstrakte Klasse deklarieren.

4.5.7 Schnittstelle

Schnittstellen werden verwendet, um die von einer Klasse oder Komponente bereitgestellten oder unterstützten Dienste anzugeben. Schnittstellen können als Klassen mit dem Stereotyp „Interface“ (detaillierte Form, Abbildung 4.28) oder als spezielle Schnittstellensymbole (siehe Abbildung 2.2, Seite 15) dargestellt werden.

Schnittstellenname<>

Abbildung 4.28 stellt eine Schnittstelle als Prototypklasse ohne Operationen dar.

Die Abbildungen 4.29 und 4.30 zeigen Beispiele der entsprechenden Metamodelle aus Abbildung 1. 4.28.

: Schnittstelle

nome = InterfacenameisAbstract = falseisRoot = falseisLeaf = false

Abbildung 4.29: Abbildung 4.28 als Instanz der Met Interface-Modellklasse.

4.5. Klassendiagramm 158

: Klassenzimmer

Name = InterfacenameStereotype = InterfaceAbstract = falseAttributesOperations = (Referenzen)ExportControlCardinalityConcurrencyStateMaschine

Abbildung 4.30: Innenansicht der Rose in Abbildung 4.28.

Im Metamodell (Abbildung 3.12, Seite 55 und Abbildung 4.29) wird zwischen Schnittstellen und Klassen unterschieden. In Rose unterscheiden sich Schnittstellen von Klassen nur durch Stereotypen (Abbildung 4.30).

Generell gelten die Konformitätsbedingungen für folgende Schnittstellen:

• Schnittstelle-1: Die Schnittstelle kann nur Operationen enthalten ([OMG99], Seite 2-52).

Zu den Operationen zählen auch „Signaloperationen“, siehe Abschnitt 4.5.10, „Signale“.

• Schnittstelle-2: Die Schnittstelle darf keine Template-Elemente enthalten ([OMG99], Seite 2-52).

• Schnittstelle-3: Alle Operationen auf der Schnittstelle müssen „öffentlich“ sein ([OMG99], Seite 2-52).

• Schnittstelle-4: Die Operationen der Schnittstelle und der Schnittstelle selbst werden implizit abstrahiert.

In [OMG99] ist nicht angegeben, ob diese Eigenschaft festgelegt oder ignoriert werden soll.

• Schnittstelle-5: Eine Schnittstelle muss mindestens eine Operation deklarieren oder erben (Abschlussbedingung).

• Schnittstelle-6: Innerhalb einer Schnittstellenhierarchie muss jede Operationssignatur eindeutig sein ([OMG99], Seite 2-47).

• Schnittstelle-7: Das der Schnittstelle gegenüberliegende Assoziationsende darf nicht navigierbar sein ([OMG99], Seite 2-45).

Da ein Interface in Rose alle Merkmale einer Klasse (außer Stereotypen) aufweisen kann, müssen zusätzliche Bedingungen geprüft werden:

• Schnittstelle-8: Die Schnittstelle kann nicht „aktiv“ sein (Parallelitätseigenschaft).

159 Kapitel 4 Tool-Unterstützung und -Konformität

• Schnittstelle-9: Basis muss ignoriert werden oder „1“.

• Schnittstelle-10: Die Schnittstelle kann keine Zustandsmaschine haben.

Rose verhindert oder erkennt keine Verstöße gegen die Konsistenzbeschränkungen in diesem Abschnitt.

4.5.8 Leistungsverhältnis

Typischerweise treten Realisierungsbeziehungen zwischen Schnittstellen und Klassen (Abbildung 4.31) oder Komponenten auf. Die Realisierung von Anwendungsfällen kann jedoch auch durch Zusammenarbeit modelliert werden (in Rose nicht möglich). sofort

Schauspiel-Unterricht

Betrieb()

Schnittstellenname

Betrieb()

Abbildung 4.31: Klassen implementieren Schnittstellenoperationen.

Interpretation der Diagramme Abb. 4.31 als Beispiel-Metamodell (Abb. 4.32) zeigt, dass Operanden als „Teile“ von Kompositionen eigene Identitäten haben.

Im UML-Metamodell (siehe Abbildung 3.26, Seite 68) sind Implementierungen prototypische Abstraktionen (Abhängigkeiten). Die Metadarstellung des Diagramms. Die Abbildungen 4.31 und 4.33 zeigen, dass die Entwickler von Rose der Notation gefolgt sind und daher Realisierungsbeziehungen nicht mit Stereotypen gekennzeichnet werden können. Es kann eine Beschreibung der im Metamodell bereitgestellten Abhängigkeiten (Mappings) angegeben werden.

Für Materialisierungsbeziehungen müssen die folgenden Konformitätsbedingungen eingehalten werden:

• Schnittstelle-11: Die Schnittstelle muss durch eine Klasse oder Komponente implementiert werden.

• Schnittstelle-12: Eine Schnittstelle implementiert keine anderen Elemente, dh eine Schnittstelle in einer Realisierungsrelation muss ein Spezifizierelement (Metamodell: Anbieter) sein.

• Operation-13: Eine Klasse, die eine Schnittstelle implementiert, muss alle Schnittstellenoperationen (mit derselben Signatur) deklarieren (Abschlussbedingung).

Rose verhindert oder erkennt keine Verstöße gegen die Konsistenzbeschränkungen in diesem Abschnitt.

4.5. 160-stufiges Diagramm

Diagrammname: RealisierungNotationMetaUMLChart Dateiname: RealisierungNotationMetaUML.VobChart Typ: UML-Objektdiagramm: Schnittstelle

name = Schnittstellenname

: Betrieb

Name = Aktion

: abstrakt

NameMap = (MappingExpression)

: Stereotyp

Name = Wahrnehmung

: Klassenzimmer

Name = Schauspielklasse

: Betrieb

Name = Aktion

Eigentümereigenschaften

Anbieter

lieferantenabhängig

Kundenabhängigkeit

Klient

Eigentümereigenschaften

Abbildung 4.32: Abbildung 4.31 als Metamodellinstanz. Objekte verfügen über die notwendigen Methoden, um die beteiligten Implementierungsbeziehungen und Modellelemente zu identifizieren.

Diagrammname: RealisierungNotationMetaRoseChart Dateiname: RealisierungNotationMetaRose.VobChart Typ: UML-Objektdiagramm

: Klassenzimmer

Nome = InterfacenameStereotyp = Interface

: Klassenzimmer

Name = Schauspielklasse

: Beziehung implementieren

Name = (nicht einstellbar)Stereotyp = (nicht einstellbar)SupplierName = InterfaceName

: Betrieb

Abbildung 4.33: Innenansicht der Rose in Abbildung 4.31.

161 Kapitel 4 Tool-Unterstützung und -Konformität

4.5.9 Abhängigkeiten

Neben Implementierungsbeziehungen gibt es noch weitere Abhängigkeiten (siehe Abbildung 3.26, Seite 68).

Roses Abhängigkeiten und Einschränkungen unterliegen den folgenden Konsistenzbedingungen (der Vollständigkeit halber nicht erforderlich): (siehe auch [BRJ99a])

• Abhängigkeit-1: Eine als „abgeleitet“ gekennzeichnete Abhängigkeit ist eine Beziehung zwischen zwei Attributen oder zwei Assoziationen.

In Rose können Abhängigkeiten zwischen Eigenschaften nicht semantisch korrekt modelliert werden. Eine Eigenschaft kann als abgeleitet markiert werden (boolesche Eigenschaftsableitung von Klasseneigenschaften), kann jedoch keine Beziehung zu einer oder mehreren unabhängigen Eigenschaften und (berechenbaren) Karten angeben. Es ist jedoch möglich, diese Informationen als Attributdokument zu speichern.

Eine Abhängigkeit zwischen zwei Assoziationen kann in Rose modelliert werden, es können jedoch keine weiteren Informationen zu dieser Abhängigkeit gespeichert werden.

• Abhängigkeit-2: Bei einer mit „instanceOf“ gekennzeichneten Abhängigkeit ist die Quelle eine Instanz und das Ziel eine Klasse, oder die Quelle ist eine Klasse und das Ziel eine Metaklasse.

Objekte können nicht im Klassendiagramm von Rose platziert werden.

In Rose können Abhängigkeiten zwischen Klassen modelliert und mit Stereotypen gekennzeichnet werden. Eine zweite Möglichkeit, „instance-of“-Abhängigkeiten zu prüfen: Eine eigenständige Klasse muss einen Stereotyp oder Typ „MetaClass“ haben.

• Abhängigkeit-3: Mit „gut“ markierte Abhängigkeiten sind Beziehungen zwischen Klassen.

Diese Abhängigkeit kann in Rose modelliert werden (mittels Stereotypen).

• Abhängigkeit-4: Mit „access“, „import“ oder „friend“ gekennzeichnete Abhängigkeiten sind Beziehungen zwischen Namespaces (normalerweise Paketen).

In Rose können Abhängigkeiten zwischen Paketen modelliert, aber nicht prototypisiert werden. Rose ermöglicht die Überprüfung auf Zugriffsverletzungen (Menü „Berichte“ – Zugriffsverletzungen anzeigen). Hierbei wird geprüft, ob die Klassen des Klassendiagramms im selben Paket wie das Diagramm liegen oder ob sie durch modellierte Abhängigkeiten zwischen Paketen verfügbar sind.

4.5. Klassendiagramm 162

4.5.10 Signale

Signale, die in Zustandsmaschinen- und Aktivitätsdiagrammen verwendet werden, können in Klassendiagrammen deklariert werden.

Das Vorhandensein von Signalen kann in Klassendiagrammen modelliert werden. Signale werden als Klassen mit dem Stereotyp „Signal“ modelliert (Abb. 4.34). Optionale Parameter eines Signals werden als Attribute in der Klasse „Rechteck“ dargestellt.

Signalname<>

Klassenname

operation()<> Signalname()<>

Abbildung 4.34: Eine Klasse mit dem Stereotyp „signal“ spezifiziert ein Signal, eine Abhängigkeit „send“ spezifiziert die Verwendung eines Signals und eine mit „signal“ gekennzeichnete Operation erklärt, dass sie ein Signal empfängt.

Die Modellierung von „Sende“-Abhängigkeiten zwischen Operationen und Signalen bedeutet, dass Operationen Signale senden können. Diese Abhängigkeit kann in Rose nicht angegeben werden. Darstellung in der Abbildung. Der 4.34-Build mit Rose zeigte diese Abhängigkeit in der Vorschau an, aber innerhalb von Rose handelt es sich um eine klassenübergreifende Abhängigkeit.

Wenn Sie explizit modellieren möchten, dass Objekte einer Klasse ein bestimmtes Signal empfangen können (siehe auch Metamodell, Abbildung 3.33, S. 83), können Sie dies tun, indem Sie eine Operation mit dem gleichnamigen Stereotyp „Signal“ als realisiert deklarieren (Abbildung 1). . 4.34).

Kommentar:

• Schnittstellen können auch den Empfang von Signalen deklarieren.

• Intern werden Signale in Rose als Klassen behandelt.

Im Metamodell werden Ausnahmen als spezielle Signale definiert, die normalerweise auf Fehlerbedingungen hinweisen. Der Absender der Ausnahme bricht deren Ausführung ab und führt den Empfänger der Ausnahme aus ([OMG99], S. 2-97).

Ausnahmen werden signaltechnisch als Klassen mit dem Stereotyp «Exception» modelliert. Die Ausnahmen, die eine Operation auslösen kann, können über die Abhängigkeit «send» oder in der Operationsspezifikation angegeben werden. Rose unterstützt Letzteres, indem es die Eingabe eines beliebigen Textes für die Aktion zur Angabe von Ausnahmen (Operationsklassenattribut-Ausnahmen) ermöglicht.

163 Kapitel 4 Tool-Unterstützung und -Konformität

Für Signale können folgende Konsistenzbedingungen ermittelt werden:

• Signal-1: Für eine Operation mit Stereotyp «Signal» muss ein gleichnamiges Signal vorhanden sein (Integritätsbedingung)

• Signal-2: Die Anzahl der Argumente für eine Signalaktion muss mit der Anzahl der Argumente (Attribute) für das Signal übereinstimmen (siehe [OMG99], Seite 2-95SendAction).

• Signal-3: Parameternamen und -typen für Signalaktionen müssen mit Attributnamen und -typen übereinstimmen.

Die Reihenfolge der Parameter kann nicht angegeben werden, da die Eigenschaften von Signalen (Klassen) nicht geordnet sind.

• Signal-4: Eine Klasse, die ein Signal empfangen kann, muss über eine Zustandsmaschine verfügen, die die Reaktion (Abschlussbedingung) auf das empfangene Signal angibt.

• Signal-5: Eine Klasse, die ein Signal empfangen kann, muss eine aktive Klasse sein.

• Signal-6: Bei einer Abhängigkeit zwischen einer Operation und einem mit „senden“ gekennzeichneten Signal (d. h. die Operation kann ein Signal senden) muss die Verwendung des Signals, sofern verfügbar, im Aktivitätsdiagramm der Operation (Abschlussbedingung) angegeben werden ).

Es gibt keine Möglichkeit, diese Abhängigkeit in Rose anzugeben.

• Signal-7: Verfügt der Klassifikator, der das Signal sendet, über eine Zustandsmaschine, muss dort auch das Senden des Signals modelliert werden (Integritätsbedingung).

• Signal-8: Das Signal darf keine Aktion haben („versteckt“ in [OMG99] auf Seite 3-136)5.

• Signal-9: Signale müssen eine „Signalaktion“ haben.

Die offizielle UML-Dokumentation ([OMG99]) und die verwendete Literatur lassen noch einige Fragen offen:

• Wie wichtig ist die Sichtbarkeit der Signaleigenschaften?

• Da Signale verallgemeinerbare Modellelemente sind, ist es möglich, „Signalhierarchien“ zu modellieren (Beispiel: siehe [BRJ99a], S. 321).

– Wie funktioniert in diesem Fall der Vererbungsmechanismus? 5 Laut [BRJ99a], S. 315, kann das Signal Operationen haben!

4.5. Klassendiagramm 164

– Wenn eine Klasse ein bestimmtes Signal empfangen kann, kann sie auch Teilsignale empfangen. Nach dem Substituierbarkeitsprinzip muss eine Klasse auch Teilsignale empfangen können. Nach [Alh98], S. 199, können Subsignale auch durch Supersignale spezifizierte Übergänge auslösen.

4.5.11 Funktionsbeschreibung

Rollen in Assoziationen können durch Schnittstellen oder Typen weiter spezifiziert werden (Abb. 4.35, siehe [BRJ99a], S. 182ff). Typ ist Stereo

Mitarbeiter

Manager

Menschen

1..1

0..*

+ Vorgesetzter: IManager

+Mitarbeiter: IEmployees

1..1

0..*

Abbildung 4.35: Funktionalität über eine Schnittstelle spezifizieren

Eine typisierte Klasse, die sich von einer Schnittstelle dadurch unterscheidet, dass die Typdefinition Eigenschaften enthalten kann. Die Typen in Abbildung 4.36 stellen die unterschiedlichen Rollen dar, die Objekte der Klasse Person im Laufe der Zeit spielen können.

Menschen

Bewerber <>

Mitarbeiter<>

Rentner<>

Abbildung 4.36 stellt die möglichen Rollentypen für die Person-Klasse dar.

Die Verwendung von Schnittstellen oder Typen zur Angabe von Rollen in Assoziationen wird im Metamodell durch Klassenassoziationsattributspezifikationen definiert.

165 Kapitel 4 Tool-Unterstützung und -Konformität

angegebenen Ende. Assoziationsenden können durch verschiedene Typen und Schnittstellen angegeben werden.

Konsistenzbedingungen:

• Rolle 3: Wenn eine Rolle durch eine Schnittstelle oder einen Typ weiter spezifiziert wird, muss die Rollenklasse diese Schnittstelle oder diesen Typ implementieren.

Der Zugriff auf Eigenschaften einer Klasse über Bindungen ist auf die durch die Rolle angegebenen beschränkt.

• Typ-1: Der Vorfahre eines Typs muss ein Typ sein ([OMG99], Seite 2-56).

• Typ 2: Der Typ hat keine Methoden ([OMG99], S. 2-56), dh die Operationen sind wie Interfaces implizit abstrakt.

4.6 Interaktionsdiagramm

Interaktionsdiagramme werden verwendet, um den Kommunikationsprozess zwischen Objekten zu spezifizieren, um bestimmte Aufgaben mithilfe von Nachrichten zu erfüllen. Die beiden UML-Interaktionsdiagramme, Kollaborationsdiagramme und Sequenzdiagramme sind semantisch äquivalent, da sie auf denselben UML-Metamodellklassen basieren (Abbildung 3.42, S. 98).

Kollaborationsdiagramme betonen den strukturellen Kontext der Interaktion, während die Abfolge der Nachrichten, die nur durch Zahlen identifiziert werden, in den Hintergrund tritt. Ein Kollaborationsdiagramm auf Spezifikationsebene besteht aus Klassifikatoren und Assoziationsfunktionen, die Objekte, Links und Nachrichten darstellen, während ein Kollaborationsdiagramm auf Beispielebene Objekte, Links und Reize enthält.

Sequenzdiagramme existieren nur auf Instanzebene. Sie betonen die Abfolge von Informationen oder Reizen, ohne den strukturellen Kontext aufzuzeigen.

In Rose können Kollaborationsdiagramme nicht auf Spezifikationsebene modelliert werden. Kollaborationsdiagramme und Interaktionsdiagramme auf Beispielebene werden intern denselben Klassen in Rose zugeordnet (Abbildung 4.45). Dies ermöglicht die Generierung von Kollaborationsdiagrammen aus Sequenzdiagrammen (und umgekehrt), wobei Änderungen in einem Diagramm automatisch auf das andere übertragen werden.

4.6.1 Klassifikatorfunktionen und -objekte

Klassifikatorrollen und -objekte in einem Interaktionsdiagramm repräsentieren Sender oder Empfänger von Nachrichten oder Reizen. Neben Klassifikatorrollen oder Klassenzugehörigkeiten von Objekten können auch Attribute oder Attributwerte angezeigt werden (Abbildungen 4.37 und 4.38).

4.6. Interaktionsdiagramm 166

/Mitarbeiter:Person

Optionale Funktionen für die Klasse „Person“.

Abbildung 4.37: Spezifikationsebene: Klassifikatorfunktionen werden mit Funktions- und Klassennamen und optional weiteren Merkmalen der in der Zusammenarbeit benötigten Klasse dargestellt.

Schubert/Mitarbeiter: Menschen

Abbildung 4.38: Beispielebene: Der Namensteil eines Objekts in einem Interaktionsdiagramm besteht aus dem Objektnamen, der Klassifikatorrolle und dem Klassennamen des Objekts. Optional können weitere Eigenschaften des Objekts angezeigt werden.

Im Metamodell (Abbildung 3.42, Seite 98) ist eine Klassifikatorrolle (ClassifierRole) genau einem Basisklassifikator (Basispseudoeigenschaft) zugeordnet. Die entsprechende Metaklasse für Objekte, die bei der Zusammenarbeit eine Rolle spielen, ist nicht im Collaboration-Paket angegeben, z. B. ObjectRole. Allerdings ist die Semantik übertragbar: Ein Objekt muss genau einem Klassifikator zugeordnet sein (siehe Abbildung 3.36, Seite 88, wo ein Objekt mindestens einem Klassifikator zugeordnet ist).

Es gibt zwei Möglichkeiten, Klassifikatorrollen (Abbildung 4.37) dem UML-Metamodell oder (mindestens) dem Tool-Metamodell zuzuordnen:

1. Der Rollenname und der Klassenname werden dem Klassenattributnamen des Metamodells ClassifierRole zugeordnet (Abbildung 4.37).

: Klassifikatorrolle

Name = Mitarbeiter:Person

Abbildung 4.39: Abbildung 4.39. Gilt für Tools, mit denen Sie die Rolle eines Klassifikators modellieren können, ohne dass eine Basisklasse vorhanden sein muss.

Bei dieser Art der Zuordnung müssen folgende Konsistenzbedingungen überprüft werden:

• Inter-1: Es muss eine Klasse mit einem Klassennamen (hier „Person“) vorhanden sein. Diese Klasse muss über optionale Anzeigefunktionen verfügen. Dies gilt entsprechend für Objekte in Interaktionsdiagrammen.

167 Kapitel 4 Tool-Unterstützung und -Konformität

Tool-Support-Prüfungen für solche Fälle erfordern eine eindeutige Identifizierung von Funktions- und Klassennamen.

2. Nur Funktionsnamen werden Attributnamen von Metamodellklassen zugeordnet. Der Klassenname ist implizit der Basisklassenname der Klassifikatorrolle (Abbildung 4.40). In diesem Fall lässt das Tool nur die Darstellung zu

Diagrammname: Neues DiagramChart-Objektdateiname: objUntitled2.VobChart Typ: UML-Objektdiagramm

: Klassifikatorrolle

Name = Mitarbeiter

: Klassenzimmer

Name = Profil

Abbildung 4.40: Alternative und semantisch korrekte Instanziierung von Abbildung 4.40. 4.37. Für eine Instanziierung dieser Art muss es eine Klasse namens „Person“ geben.

Diese Basisklassenmerkmale unterstützen aktiv die oben beschriebenen Konformitätsbedingungen.

Als nächstes gehen wir von dieser Art der Abbildung für das Metamodell aus.

4.6.2 Aufgaben und Kontakte des Vereins

Die Interaktion zwischen Objekten erfordert, dass das sendende Objekt über das empfangende Objekt „weiß“. Dies wird im Kollaborationsdiagramm durch Assoziationsrollen dargestellt oder mit Links dargestellt. Dieser Link dient der Kommunikation beim Austausch von Nachrichten zwischen Objekten. Assoziationen zwischen Klassifikatorfunktionen oder Verknüpfungen zwischen Objekten basieren auf Assoziationen zwischen Klassen.

Das Klassendiagramm ist in der Abbildung dargestellt. 4.41 zeigt die grundlegenden Klassifikatoren und grundlegenden Assoziationen für das Kollaborationsdiagramm in Abbildung 1. 4.42 und Abb. 4.43. Wie in der Abbildung gezeigt. Abb. 4.44 zeigt den Zusammenhang zwischen dem Klassendiagramm (Abb. 4.41) und dem Kollaborationsdiagramm auf Spezifikationsebene (Abb. 4.43).

Folgende Konformitätsbedingungen müssen überprüft werden (siehe Abbildung 4.44):

• Inter-2: Für Assoziationsrollen muss eine entsprechende Basisassoziation zwischen den Basisklassifizierern der Klassifikatorrollen bestehen (siehe [OMG99], S. 2-104). Dabei könnte es sich auch um eine Erbschaftsgemeinschaft handeln. Dies überträgt sich auf die Instanzebene: Für eine Verknüpfung zwischen Objekten muss eine (geerbte) Assoziation zwischen den Klassen der Objekte bestehen.

Ein Link stellt eine Kommunikationsverbindung dar, über die ein Objekt eine Nachricht an ein anderes Objekt senden kann. Eine Ausnahme von der Inter-2-Bedingung besteht für Objekte, deren Basisklasse nicht mit der Nachrichtenübermittlung verknüpft ist (siehe Abschnitt 4.6.3).

Wenn die Konformitätsunterstützung aktiviert ist, kann ein Assoziationsname übernommen werden.

4.6. Interaktionsdiagramm 168

Mitarbeiter<>

Manager <>

Menschen

0..1

Befehl

+MA: Angestellter

+ Chef: Manager

0..1

Abbildung 4.41: Die Rolle einer Person wird nach Typ spezifiziert. Die Abbildungen 4.42 und 4.43 zeigen, wie diese Informationen in einem Kollaborationsdiagramm verwendet werden können.

/Mitarbeiter:Person /Manager:Person 0..1*

Befehl

0..1*

Abbildung 4.42: Verwendung der Typen in Abbildung 4.42 unter Verwendung von 4.41 als Rangfolgefunktion in einem Kollaborationsdiagramm auf Spezifikationsebene.

Müller/Mitarbeiter: Leute

Schmidt / Manager: Personleitet

Abbildung 4.43: Verwendung der Typen in Abbildung 4.41 als Rollen für Objekte in einem Kollaborationsdiagramm auf Beispielebene.

169 Kapitel 4 Tool-Unterstützung und -Konformität

Tee

Zeit N

Ami

: Neu

Objekt

usw. D

Tiger

amC

Hart

dokumentieren

Name

e:K

werden

Polaris

Rückzug B

Spion

Ulme

elektronisch

Verb

Tee

Zeit

Simulation

: eins

Europa

bjc

Tag t

Grama

: C

Mädchen

Identifikator

Papier

Das ist

Mine

= m

Itab

Flosse

: C

Mädchen

Name

e =

durchgehen

Sohn

: C

Mädchen

Identifikator

Papier

Das ist

Mine

= m

Anag

Das ist

: A

ssoc

Aktion

nFim

Papier

Das ist

Mine

Paste

Polaris

Ion

Super Tipp

Rechtmäßigkeit

= *

: A

ssoc

Aktion

nFim

Papier

Das ist

Mine

Paste

Polaris

Ion

Super Tipp

Rechtmäßigkeit

= 0

..1

: A

ssoc

Aktion

nRoll

Das ist

Mine

mehrere

typisch

Alter

bei diesem

Laser

ich ein

Ribonukleinsäure

Mine

= m

existieren

Super Tipp

Rechtmäßigkeit

= *

: A

ssoc

Aktion

nFim

Name

e =

lei

der dritte

mehrere

typisch

Alter =

0..1

: A

ssoc

Aktion

Oma

Mine

oder

: C

Mädchen

Name

e =

Mita

rbei

der dritte

: C

Mädchen

Name

e =

Mann

Alter

entsprechend

Typ

pakistanisch

com

entsprechend

Typ

Papier

Ich mag

Ameise

Spezifikation

ifica

Hund

Spezifikation

ifica

Hund

Papier

Ich mag

Ameise

Abbildung 4.44: Instanziierung der Abbildungen 4.41 und 4.42. Klassifikatorfunktionen basieren auf Klassen. Die Assoziationsfunktion zwischen Klassifikatorfunktionen basiert auf der Assoziation zwischen entsprechenden Klassen.

4.6. Interaktionsdiagramm 170

• Inter-3: Die optionalen Qualifizierer für assoziationsseitige Funktionen müssen eine Teilmenge der grundlegenden assoziationsseitigen Qualifizierer sein (siehe [OMG99], Seite 2-104).

• Inter-4: Eine Assoziationsende-Rolle (oder Link-Ende) ist nur dann navigierbar, wenn das entsprechende Basis-Assoziationsende auch navigierbar ist (siehe [OMG99], Seite 2-104).

Kommentar:

• Keine anderen Bedingungen in [OMG99] angegeben.

• Die Unterscheidung zwischen kooperativer Multiplizität und endgültiger Korrelationsfunktionsmultiplizität ist nicht genau definiert.

• In [OMG99] gibt es keine Beispiele für zugehörige „echte“ Funktionsnamen, und den Autoren sind auch keine Beispiele aus anderer UML-Literatur bekannt.

Weitere angemessene Konformitätsbedingungen:

• Der Name einer Klassifikatorfunktion muss der Name des entsprechenden Assoziationsendes oder der Name eines Klassifikators sein, der ein Assoziationsende angibt, also der Name eines Typs oder einer Schnittstelle.

• Wenn ein Assoziationsende angegeben ist, müssen die Darstellungsmerkmale der Klassifikatorrolle eine Teilmenge der Klassifikatormerkmale des Spezifizierers sein.

• Die Kardinalität der assoziationsseitigen Funktion muss eingeschränkt oder gleich der Kardinalität der basisseitigen Funktion sein.

Offene Frage: In welchen Modellierungssituationen sollte die Kardinalität eingeschränkt werden?

• Die Sichtbarkeit der zugehörigen Endrolle darf nicht erweitert werden.

• Eine Assoziationsende-Rolle kann Aggregate/Kompositionen nur markieren, wenn die Assoziationsende-Rolle auch für das zugrunde liegende Assoziationsende gilt.

Die Kardinalität einer Assoziationsrolle gibt die Anzahl der Links an, die diese Rolle in der Zusammenarbeit spielen. [OMG99] liefert keine Beispiele dafür, wann die Kardinalität einer Assoziationsfunktion modelliert werden sollte. Die Notation für die Kardinalität der zugehörigen Funktion ist ebenfalls undefiniert.

Objekte und Links in einem Interaktionsdiagramm werden in Rose den ObjectInstance- oder Link-Klassen zugeordnet (Abbildung 4.45).

Beim Modellieren eines Objekts in einem Interaktionsdiagramm kann der Klassenname des Objekts aus vorhandenen Klassen in Rose ausgewählt werden. Geben Sie ein

171 Kapitel 4 Tool-Unterstützung und -Konformität

rosa Artikel

Stereotyp

Element

Name

Vereinsbetrieb

Klassenzimmer

assoziieren

LinkRole1LinkRole2LinkRole1VisibilityLinkRole2Visibility

AddMessageTo()AssignAssociation()DeleteMessage()GetMessages()UnAssignAssociation()

0..10..1Mengem

Frequenzsynchronisation

GetSenderObject()GetReceiverObject()IsMessageToSelf()IsOperation()GetOperation()GetLink()

0..10..1 Objektinstanz

ClassNameLinksMultipleInstancesPersistence

AddLink()DeleteLink()GetClass()IsClass()

0..10..1

+Absender+Empfänger

Abbildung 4.45: Meta-Darstellungen von Objekten, Links und Nachrichten (Nachrichten) in Rose.

Ein beliebiger Klassenname ist nicht möglich. Mehrere Objekte (AttributeMultipleInstances) repräsentieren die Existenz mehrerer Objekte. Inter-1-Bedingungen können in Rose überprüft werden (Menü: Bericht – Nicht aufgelöste Objekte anzeigen).

Nach dem gleichen Schema können in Kollaborationsdiagrammen benannte(!) zugrunde liegende Assoziationen für Links ausgewählt werden. Rollennamen und Assoziationsqualifizierer werden beendet und übernehmen den Assoziationsnamen. Am Ende des Links erscheinen die Rollen- und Qualifizierernamen und als Linkname erscheint der Assoziationsname, der um den Linknamen erweitert werden kann. Zusätzlich zu den von Basisklassen geerbten Assoziationen umfassen optionale Assoziationen auch Assoziationen zwischen Superklassen nicht geerbter Basisklassen (die Sichtbarkeit der Assoziationsenden ist privat). Verstöße gegen Inter-2-Bedingungen werden nicht erkannt, es gibt keine Möglichkeit, zusätzliche Qualifikationsmerkmale hinzuzufügen (um Inter-3-Verstöße zu vermeiden). Die Navigationsfähigkeit von Links (Inter-4) kann nicht angegeben werden.

4.6.3 Botschaften und Reize

Eine benannte Nachricht enthält einen benannten Absender und einen oder mehrere Empfänger. Der eigentliche Inhalt der Nachricht besteht aus einer Aktion (normalerweise einem Operationsaufruf) und optionalen Parametern.

4.6. Interaktionsdiagramm 172

Zerstörungsaktion ReturnActionTerminateAction

Betrieb

Aufruf zum Handeln

+Betrieb 1

Aktion senden

Rezeption

Signal

+ Zeichen 1

0..*

+Empfang 0..*

+ Signal 1

Verhaltensmerkmale

+ Signalverstärkung

+Kontext*

Aktion erstellen

Ressource

Klassifikator

0..*

+ instanziieren 1

0..*

+ Funktion

{Befehl}

+Besitzer 1

assoziieren

Beispiel

1..*

+Klassifikator1..*

Debatte

Wert: Ausdruck

Reiz 0..1*

+Kommunikationslink

0..1*

+parameter *{sort}

+Absender 1

* *

+ Rezeptor 1

Information

0..1

+ Aktivator

0..1

+Vorgänger

Aktion

Treffer: IterationExpressiontarget: ObjectSetExpressionisAsynchronous: Booleanscript: ActionExpression

0..1 *0..1

+aktueller Parameter

*{sauber}

+dispatchAction 1

*1*

+ Aktion

Abbildung 4.46: Durch das Ausführen einer Aktion wird ein Stimulus erstellt, der auf die sendenden und empfangenden Instanzen verweist, über Links kommuniziert und Parameter enthalten kann.

173 Kapitel 4 Tool-Unterstützung und -Konformität

Die Ausführung einer Aktion erzeugt eine entsprechende Anzahl von Reizen, die jeweils über einen Link (communicationLink) von der sendenden Kopie an die empfangende Kopie gesendet werden (Meta-Darstellung, siehe Abbildung 4.46). Ein Link bedeutet, dass der Absender die Adresse des Empfängers „sieht“ oder „kennt“. Der Empfang eines Reizes führt dazu, dass der Empfänger ein mit der Aktion übereinstimmendes Verhalten ausführt.

In besonderen Fällen kann es vorkommen, dass eine Kommunikationsverbindung (auf der Metaebene) verloren geht, obwohl sie im Kollaborationsdiagramm dargestellt wird. Dies gilt sowohl auf der Spezifikationsebene, wo eine zugehörige Funktion einen oder mehrere Links darstellt, als auch auf der Beispielebene. Die Verbindung oder Assoziation, die der Kommunikation zwischen Sender und Empfänger zugrunde liegt, kann in den folgenden Situationen verloren gehen:

• Der Absender erhielt als Parameter eine Referenz auf die empfangene Kopie. In diesem Fall kann das Ende des Empfängerlinks mit «Parameter» markiert werden.

• Nachrichten-/Stimulusempfänger sind global oder lokal sichtbar. Dann kann das Ende des Links als „global“ oder „lokal“ markiert werden.

• Sender und Empfänger repräsentieren dasselbe Objekt. Anschließend kann das Ende des Links mit „self“ markiert werden.

Rose ermöglicht die Angabe von Linkenden, indem dem Absender und Empfänger der Nachricht Sichtbarkeit (LinkRole1Visibility- oder LinkRole2Visibility-Eigenschaften der Link-Klasse) zugewiesen wird. Verfügbare Werte sind „Parameter“, „Global“ und „Lokal“. Mit diesen Informationen kann die Inter-2-Bedingung umformuliert werden:

• Inter-2': Für Links zwischen Objekten muss eine (geerbte) Assoziation zwischen Basisklassen bestehen, oder der Link muss mit Parameter, Global oder Lokal markiert sein, oder beide Enden des Links verweisen auf dasselbe Objekt (Selbst). .

Im Metamodell (Abbildung 4.46) wird der Aktionsaufruf für eine Nachricht auf die Klasse CallAction abgebildet. Für Operationsaufrufe gelten die folgenden Konformitätsbedingungen:

• Inter-5: Der Operationsname muss mit dem des empfangenden Objekts übereinstimmen, oder die Klasse des empfangenden Objekts muss die Operation deklarieren oder erben.

Beim Spezifizieren einer Nachricht ermöglicht Rose die Auswahl von vom Empfänger bereitgestellten Vorgängen (einschließlich geerbter öffentlicher Vorgänge). Alternativ kann als Nachricht auch ein beliebiger Text eingegeben werden. Der Artikel bezieht sich nicht auf Operationen aus der Sicht von Ross und ist in diesem Sinne inkonsistent. statt Text,

4.6. Interaktionsdiagramm 174

: Artikelinventar

: Artikel-Abonnement

1: Reserve (lang, doppelt)

Abbildung 4.47: Nachrichtennotation für einen angegebenen Operationsaufruf in einem Kollaborationsdiagramm. In diesem Fall wird der Parameter durch den Parametertyp der Operation dargestellt.

Es muss eine Operation oder „Signaloperation“ darstellen, die eine Klasse um die gewünschte Operation aus dem Interaktionsdiagramm erweitern kann. Bei einem Verweis auf eine Operation stellt Rose die Operationssignatur neben dem Pfeil dar, der die Richtung der Nachricht angibt (Abbildung 4.47). Ross bietet die Möglichkeit, den Inter-3-Status bei Bedarf zu überprüfen. Dadurch wird ermittelt, ob auf eine bestehende Operation der empfangenden Objektklasse verwiesen wird.

Wenn eine in einem Interaktionsdiagramm referenzierte Operation aus der empfangenden Objektklasse entfernt wird, wird der Name der Operation (einschließlich Parametertypen) intern als Text gespeichert, d. h. die entsprechende Nachricht wird nicht aus dem Interaktionsdiagramm entfernt. Rose warnt nicht vor einer Aufhebung der Operation, obwohl dies zu Inkonsistenzen führen würde.

Sendesignale werden der SendSignal-Klasse im Metamodell zugeordnet. Beim Senden eines Signals gelten folgende Konformitätsbedingungen:

• Inter-6: Der Empfänger muss das bestätigte Signal empfangen.

Wie bei Rose gibt es keine Möglichkeit, zwischen Sende- und Anrufvorgängen zu unterscheiden, und Signale werden als Vorgänge behandelt. Für die Darstellung von Operationen gibt es in Rose kein Stereotyp, d. h. es gibt keine visuelle Unterscheidung zwischen Operationen und Signalen.

Der Nachrichtenparameter von CallAction oder SendAction kann auf drei Arten ausgedrückt werden:

1. Parameter sind Verweise auf im Diagramm enthaltene Objekte, daher werden Parameter Stimulus-Parametern (Pseudo-Eigenschaftsparameter der Stimulus-Klasse) zugeordnet.

2. Der Argumentausdruck, dessen Auswertung das eigentliche Argument bestimmt, wird auf das Argument der mit dem Stimulus verknüpften Aktion abgebildet (Pseudoeigenschaft „actualArgument“ von classArgument).

3. Der Parametertyp wird zusammen mit dem Operations-/Signalnamen angezeigt. Die Parameter werden dann dem Parametertyp oder Signaleigenschaftstyp der Operation zugeordnet.

175 Kapitel 4 Tool-Unterstützung und -Konformität

Rose unterstützt nur die letzte Möglichkeit zur semantisch korrekten Parameterdarstellung, andere Möglichkeiten können genutzt werden (die Nachricht kann ein beliebiger Text sein), führen aber zu (aus Roses Sicht) inkonsistenten Modellen.

Andere Arten von Aktionen in Interaktionsdiagrammen sind Rückgabe-, Erstellungs-, Zerstörungs- und Schließaktionen (siehe Abbildung 4.46). Zuweisungsaktionen können nicht in Interaktionsdiagrammen verwendet werden. Rückrufoperationen werden nur in Sequenzdiagrammen angezeigt. Andere Aktionstypen verfügen über eigene grafische Symbole in Sequenzdiagrammen (siehe Abbildung 3.38, Seite 93). Rose unterstützt die Modellierung dieser Art von Vorgängen nicht. Da die Stereotypen von Operationen in Interaktionsdiagrammen nicht dargestellt werden, ist es in Rose nicht möglich, Stereotypen für alternative Darstellungen zu verwenden.

Der Rückgabewert der Rückrufoperation wird den Parametern der Operation zugeordnet. Eine Return-Operation erfordert einen vorherigen Operationsaufruf (Konsistenzbedingung, siehe 4.6.4 Kontrollfluss).

Der Nachrichtenempfänger einer Erstellungsaktion ist das Objekt, das erstellt wird, wenn es eine Nachricht oder einen Stimulus empfängt. Erstellungsvorgänge haben kein explizites Ziel (Ziel), da das Ziel implizit der Empfänger der Nachricht ist. Da der Erstellungsvorgang nur einem Klassifikator im Metamodell zugeordnet ist, müssen die folgenden Konsistenzbedingungen berücksichtigt werden:

• Inter-7: Der Empfänger einer Nachricht zum Erstellen einer Aktion muss ein Objekt der mit der Aktion verknüpften Klasse sein.

Eine Nachricht für einen Zerstörungsvorgang führt zur Zerstörung des empfangenden Objekts. Eine Nachricht für einen Beendigungsvorgang, der zur Selbstzerstörung eines Objekts führt, muss die folgenden Konsistenzbedingungen erfüllen:

• Inter-8: Empfänger und Absender einer Shutdown-Action-Nachricht müssen übereinstimmen.

4.6.4 Kontrollfluss

Wenn der Absender eine Nachricht an den Empfänger sendet, kann der Empfänger auf den Empfang der Nachricht reagieren, indem er eine weitere Nachricht sendet usw. Diese Nachrichten bilden eine sequentielle chronologische Reihenfolge (Kontrollfluss), die immer zu einem Prozess oder Thread gehört. Die Reihenfolge der Nachrichten wird durch Sequenznummern visuell dargestellt (siehe Abschnitt 3.2.2).

Man unterscheidet zwischen flachem Kontrollfluss und prozeduralem oder verschachteltem Kontrollfluss (siehe [BRJ99a], S. 240). In einem einfachen Kontrollfluss, der hauptsächlich im Kontext eines Anwendungsfalls modelliert wird, wird die Kontrolle von einem Objekt zum nächsten übergeben, während in einem prozeduralen Kontrollfluss (Abbildung 4.48) die Kontrolle an den Aufrufer der Operation zurückgegeben wird.

4.6. Interaktionsdiagramm 176

Objekt 1 Objekt 2 Objekt 3 Objekt 4

1: 1.1:

1.2:

Abbildung 4.48: Prozesskontrollfluss

Information

0..1

+ Aktivator 0..1 *

+Vorgänger*

Abbildung 4.49: Reihenfolge der Nachrichten/Stimuli

Die Reihenfolge der Nachrichten wird im Metamodell auf Pseudoeigenschaften Vorgänger und Aktivatoren abgebildet (Abbildung 4.49). In Abbildung 4.48 ist Nachricht 1.1 der Vorgänger von Nachricht 1.2. Der Auslöser einer Nachricht ist eine Nachricht, deren Empfang dazu führt, dass die Nachricht gesendet wird. In Abbildung 4.48 aktiviert Nachricht 1 die Nachrichten 1.1 und 1.2.

Im Allgemeinen gilt, wenn X eine beliebige Seriennummer ist:

• X.i ist ein Vorfahre von X.i+1

• Der Aktivator von X.i ist X.

Die Meldungen 1, 1.1 und 1.2 stellen betriebliche Anrufe dar (durchgezogene Pfeile). Ein Operationsaufruf aktiviert eine (verschachtelte) Sequenz, die durch eine Rückgabenachricht (Return-Operation) abgeschlossen wird. Die Rückgabe einer Nachricht oder die Rückgabe der Kontrolle an den Aufrufer erfolgt implizit, auch wenn dies nicht explizit angezeigt wird. Bei Operationsaufrufen können Rückschlüsse auf die Operationsausführung (zumindest auf die Reihenfolge anderer Operationsaufrufe) gezogen werden.

Für Rückmeldungen können folgende Konformitätsbedingungen formuliert werden (siehe [OMG99], Seite 3-101):

• Inter-9: Für die Rückmeldung ist eine Aktivierungsnachricht erforderlich.

177 Kapitel 4 Tool-Unterstützung und -Konformität

• Inter-10: Die Antwortnachricht ist die letzte Nachricht in der vorhergehenden Kette.

4.6.5 Verzweigung und Iteration

Auch Verzweigungen (siehe Abbildung 3.38, Seite 93) und Iterationen (Abbildung 4.50) können in Interaktionsdiagrammen modelliert werden.

Wenn das Interaktionsdiagramm Iterationsausdrücke enthält, kann die Reihenfolge der Nachrichten nicht mehr konsistent auf das Metamodell abgebildet werden. Abbildung 4.50 zeigt eine typische Verwendung (Beispiel) von Iterationsausdrücken in einem Kollaborationsdiagramm.

Diagrammname: Neues Kollaborationsdiagramm. Diagrammdateiname: colUntitled1.VobChart. Typ: UML-Kollaborationsdiagramm

Objekt 1: Artikelreservierung

Grenze

bpos:BestellPosition

: Artikelinventar

1: Reserve (b)

"Umfang"

1.1* [i=1..*]: bpos := gibBestellPosition(i)

"Lokal"

1.1.1:artigo := getArticle()

1.1.2: Count := getCount

1.1.3: Reservierung(Artikel, ID)

Abbildung 4.50: Iterationen in einem Kollaborationsdiagramm, siehe [Oes98], S. 305. Nachrichten, die Iterationen starten, werden durch Iterationsausdrücke erweitert. Die Sequenznummer der Nachricht in der Iteration ist eins mehr.

Nachricht 1.1 Liefern Sie bestimmte Auftragspositionen, die von Botschaften auf niedrigerer Ebene verwendet werden, iterativ aus. Abbildung 4.51 zeigt die gleiche Interaktion in einem Sequenzdiagramm, das Sequenznummern enthält. Leider ist die Reihenfolge der Meldungen gemäß den oben genannten Bedingungen nicht mehr korrekt.

4.7. Zustandsdiagramm 178 Diagrammname: ReservationChart Dateiname: seqUntitled2.VobChart Typ: UML-Sequenzdiagramm

...: ItemReservation b: Order bPos: OrderItem: Item Repository

1: Reserve(b) «Parameter»1.1* [i=1..n]: gibBestellPos(i)

bPos

1.1.1:artigo := getArticle()

1.1.2:gibAmount()

Menge

1.1.3: Buch(Artikel, ID) 1.2:

Abbildung 4.51: Interaktion der Diagramme 4.50 auf einem Sequenzdiagramm.

Passen Sie die Seriennummer an. Wenn Sie die fehlerhaften Sequenznummern im Sequenzdiagramm auf 1.1, 1.2, 1.3, 1.4 ändern, sind die oben genannten Bedingungen erfüllt, aber die Verschachtelung der Nachrichten ist nicht mehr sichtbar. Das Problem liegt in der Botschaft iterativer Ausdrücke, dass mehrere Metamodell-Reize abgebildet werden müssen. In [Oes98] auf Seite 308 ist die gleiche Situation wie in Abb. 4.50 Basierend auf Sequenzdiagrammen. Im Vergleich zu Abbildung 4.51 fehlt jedoch der iterative Ausdruck.

In [Alh98] werden Iterationen in Sequenzdiagrammen durch Rechtecke markiert, die Nachrichten aus den Iterationen enthalten. Bei dieser Art der Modellierung gehören Iterationen nicht mehr zu Nachrichten und Nachrichten, die zu Iterationen gehören, können visuell leicht identifiziert werden (Abbildung 4.52). Leider ist dieser Modellierungsansatz in [OMG99] nicht spezifiziert und kann nicht auf das Beispielmetamodell abgebildet werden.

4.7 Zustandsdiagramm

Ein Zustandsdiagramm (Statechart) enthält eine Zustandsmaschine bestehend aus Zuständen, Übergängen, Ereignissen und Aktionen. Zustandsdiagramme werden verwendet, um das Verhalten von Modellelementen zu modellieren. Bei diesen Modellelementen handelt es sich in erster Linie um Klassen. UML-Definitionen ermöglichen jedoch auch die Modellierung des Verhaltens anderer Modellelemente (z. B. Operationen) mithilfe von Zustandsdiagrammen.

In diesem Abschnitt werden die Grundkomponenten des automatischen Zustands erläutert

179 Kapitel 4 Tool-Unterstützung und -Konformität

i = 1..n

...: Artikelreservierung b: Bestellung bpos: Bestellartikel: Artikellager

Reserve (b)

gibOrderPos(i)

bPos

Artikel := Artikel abrufen

Menge := gibt die Menge an

Buchung(Artikel, ID)

Abbildung 4.52: Darstellung von Iterationen in einem Sequenzdiagramm, nach [Alh98], S. 176.

maten (Ereignisse, Aktionen, Übergänge und Zustände). Abschließend wird erklärt, wie man aus diesen Komponenten eine Zustandsmaschine aufbaut.

4.7.1 Ereignisse

Eine Zustandsmaschine kann durch Übergänge und Aktionen auf Signale, Aufrufe, Timing und Änderungsereignisse reagieren. Entry-, Exit- und Do-Ereignisse sind spezielle zustandsbezogene Ereignisse, die keine Übergänge verursachen. Sie sind in Abschnitt 4.7.4 beschrieben.

Signale und Anrufereignisse werden in Zustandsdiagrammen mit derselben Syntax dargestellt:

event-name'('parameter-list')'parameter-list ist eine durch Kommas getrennte Liste von Parametern, wobei

Parameter bestehen aus einem Parameternamen ([Alh98], Seite 198) oder werden in Form eines Parameternamens „:“ Ausdruckstyp dargestellt ([OMG99], Seite 3-136).

Ein Signal- oder Anrufereignis wird einem SignalEvent oder CallEvent zugeordnet, das mit dem entsprechenden Signal oder der entsprechenden Aktion verbunden ist (Abbildung 4.53). Die Ereignisparameterliste wird dem Ereignisparameter zugeordnet, und der Ereignisparameter wird im Metamodell als abhängiger Teil der Ereignisexistenz definiert, dh die Parameter der Operation und die Parameter des aufrufenden Ereignisses sind unterschiedliche Objekte des Metamodells Beispiel

Aus Abb. 4.53 die Notation und die folgende Konformitätsbedingung

4.7. Zustandsgraph 180

Zeitereignis

wann: Zeitausdruck

Ereignis ändern

Variationsausdruck: Boolescher Ausdruck

Betrieb

Anrufereignis

+passieren*

Vorfall an der Ampel

Signal

+passieren*

Parameterereignis

* 0..1

+Parameter

{Befehl}

0..1

Modellelement

Abbildung 4.53: Ereignisse im Metamodell

Abgeleitetes Anrufereignis:

• Ereignis-1: Der Name des Signal- oder Anrufereignisses muss mit dem Namen des Signals oder der Operation übereinstimmen.

Wenn das Ereignis zum Zustandsdiagramm einer Klasse gehört, muss die Klasse den Signalempfang oder die Aktion deklarieren.

• Ereignis-2: Die Anzahl der Parameter des Signal- oder Anrufereignisses muss mit der Anzahl der Attribute des Signals oder der Anzahl der Parameter der Operation übereinstimmen.

Wenn das Ereignis zum Zustandsdiagramm der Klasse gehört, muss die Reihenfolge der Parameter des Signals oder der Operation mit der Reihenfolge der Parameter des Ereignisses übereinstimmen.

Hinweis: Diese Notation unterscheidet nicht zwischen Signalereignissen und Anruferereignissen. Wenn das Zustandsdiagramm das Verhalten der Klasse angibt, wird das Signal als Operation mit dem Stereotyp «Signal» deklariert (Ereignis 1). Um die Konsistenzbedingung für Ereignis 2 zu prüfen, ist es nicht mehr erforderlich, zwischen Signal- und Anrufereignissen zu unterscheiden. Die visuelle Unterscheidung zwischen Signal- und Rufereignissen ist nicht unbedingt erforderlich, da das empfangende Objekt den Unterschied „kennt“.

181 Kapitel 4 Tool-Unterstützung und -Konformität

Ein Zeitereignis wird durch das Schlüsselwort „after“ dargestellt, gefolgt von einem Zeitausdruck (TimeExpression), z. B. „after (10 sec)“, und wird einem TimeEvent zugeordnet.

Ein Änderungsereignis wird durch das Schlüsselwort when gefolgt von einem booleschen Ausdruck (ChangeExpression) wie when(response = 42) gekennzeichnet und einem ChangeEvent zugeordnet.

Im Metamodell gibt es einige Verwirrung, wenn es als Attributname eines Zeitausdrucks für ein Zeitereignis angegeben wird. Ereignisse vom Typ when(date = 1. Januar 2000) können als Zeitereignisse mit einem absoluten Zeitpunkt interpretiert werden, aber anhand von Schlüsselwörtern auf Änderungsereignisse abgebildet werden (siehe [OMG99], Seite 3-136).

Angaben zu Zeit- und Änderungsereignissen müssen mit dem entsprechenden Ausdruckstyp übereinstimmen. Da die Syntax dieser Ausdrücke nicht definiert ist, können Konformitätsbedingungen, die auf dem UML-Metamodell basieren, nicht von Tools überprüft werden.

Aus dem Metamodell wie folgt:

• Ereignis-3: Zeit- und Änderungsereignisse können keine Parameter haben.

Fall

Debatte

Element

Name

Abbildung 4.54: Die Ereignisklassen des Rose-Ereignismetamodells stellen keine Operationen mit Operationssignaturen oder Klassen bereit, die denen ähneln, deren Verhalten durch ein Zustandsdiagramm spezifiziert wird.

In Rose werden Ereignisse Ereignisklassen zugeordnet (Abbildung 4.54). Der Name und die Parameter des Ereignisses werden in verschiedenen Eigenschaften gespeichert. In Rose wird nicht zwischen verschiedenen Ereignistypen unterschieden und der Ereignisname ist nur eine Zeichenfolge. Da Zustandsdiagramme in Rose immer das Verhalten von Klassen angeben, ist es nicht notwendig, zwischen Signal- und Rufereignissen zu unterscheiden; Zeit- und Änderungsereignisse können von Signal- und Rufereignissen unterschieden werden, indem die Schlüsselwörter „after“ und „when“, wenn kein Signal vorhanden ist, verwendet werden. oder der Name ist Nach oder wenn Klassenoperationen vorhanden sind.

4.7. Zustandsgraph 182

4.7.2 Aktion

Aktionen und Aktivitäten charakterisieren die Reaktion der Zustandsmaschine auf Ereignisse. Eine Aktion ist ein ausführbarer atomarer Prozess, normalerweise ein Operationsaufruf oder ein Signalversand. Eine Aktion kann jedoch auch ein Ausdruck sein, der Eigenschaften, Verknüpfungen und Parameter eines Ereignisses enthält, oder die Erstellung/Zerstörung eines Markierungsobjekts. Zustandsmaschinenaktionen sind entweder Übergänge (4.7.3) oder Zustände (4.7.4).

Eine Aktion wird wie folgt annotiert:

Ereignissignatur '[' Bedingung ']' '/' Aktionsausdruck

Anhand des Vorzeichens kann nicht unterschieden werden, ob es sich um eine Call-Aktion, eine Sende-Aktion oder etwas anderes handelt (siehe Abbildung 4.55). Die Notation von Aktionsausdrücken hängt von der für Aktionsausdrücke gewählten Sprache ab ([OMG99], S. 3-138). Da es sich bei einer Aktion immer um jede Art von Aktion handeln kann, kann eine Konformitätsbedingung für eine Aktion nur dann identifiziert werden, wenn klar ist, um welche Art von Aktion es sich handelt:

• Aktion-1: Wenn es sich um eine Aufrufaktion handelt, wird die Operation für das Objekt der Klasse aufgerufen. Diese Klasse muss Operationen deklarieren und für den Besitzer der Zustandsmaschine sichtbar sein. Im übertragenen Sinne gilt dieser Sachverhalt auch für die Übertragung von Signalen.

• Aktion 2: Die Anzahl der Argumente des Operationsaufrufs (Signal) muss mit der Operationsdeklaration (Signal) übereinstimmen.

• Aktion-3: Aktionsausdrücke dürfen nur Attribute aus dem Sichtbarkeitsbereich des Statechart-Eigentümers und sprachabhängigen Konstrukten enthalten. Dies kann zu anderen Konformitätsbedingungen führen, die schwieriger zu überprüfen sind.

Werkzeuge, die Modellierer bei der Erstellung konsistenter Modelle unterstützen, sollten Möglichkeiten zur Angabe des Aktionstyps einer Aktion bieten. In diesem Fall kann das Tool die Semantik der Operation erkennen und eine Konsistenzprüfung durchführen. Die Überprüfung auf konsistente Aktionen ist wichtig, da Aktionsausdrücke häufig Verhaltensmerkmale (Operationen, Signale) von anderen Modellelementen verwenden und somit Verbindungen zu anderen Diagrammen (möglicherweise Ansichten) darstellen.

4.7.3 Übergang

Übergänge sind Beziehungen zwischen Zuständen. Ein Übergang hat mindestens einen Anfangszustand (Ursprung) und mindestens einen Folgezustand

183 Kapitel 4 Tool-Unterstützung und -Konformität

(Ziel) und optional Ereignisse, Bedingungen und Aktionen (Abbildung 4.55).

Anfangszustand Nächster ZustandEreignis(Argument)[Bedingung]/Aktion

Abbildung 4.55 Übergangsnotation mit Ereignissen, Ereignisargumenten, Bedingungen und Aktionen. Die Art der Aktion ist nicht erkennbar.

Diagrammname: Neues DiagramChart-Objekt Dateiname: TransitionNotationMetaUML.VobChart Typ: UML-Objektdiagramm

: Übergang

: Zustand

Name = Ausgangszustand

: Zustand

Name = nächster Zustand

: bewachen

Ausdruck = Ausdruck

: Betrieb

Name = Aktion

: Aufrufvorgang

: Fall

Name = Ereignis

: Umfang

Name = Parameter

Quelle

Ausgehend

verbieten

Ziel

die Wache

Effektauslöser

Abbildung 4.56: Beispiel-Metamodell, transformiert in Abbildung 1. 4,55. Auf der Metaebene lässt sich erkennen, dass eine „Aktion“ eine Operation ist.

Wie im Bild gezeigt. Abbildung 4.56 zeigt ein Beispiel des entsprechenden Metamodells. 4,55. Alle Informationen, die für eine Transformation angegeben werden können, sind sichtbar und semantisch eindeutig. Semantisch besteht sogar ein Zusammenhang zwischen Operationen und Klassen. Tools, die die Semantik von Aktionen verstehen, können die Konformitätsbedingungen für Aktionen in Abschnitt 4.7.2 überprüfen.

Wie im Bild gezeigt. 4.57 zeigt, dass es in Rose möglich ist, Aktionen für Anfangs- und Folgezustände, Ereignisse, Bedingungen und Übergänge zu spezifizieren, Rose erkennt jedoch keine umfassendere Ereignis- (siehe 4.7.1) oder Aktionssemantik.

In früheren UML-Versionen konnte eine Notation verwendet werden, um Commit-Operationen von anderen Operationen zu unterscheiden. Rose unterstützt diese Art der Notation. MetaclassTransition Rose enthält OperationGetSendAction, ein Objekt

4.7. ZUSTANDSDIAGRAMME 184 Diagrammname: Neues Diagrammobjekt Dateiname: TransitionNotationMetaRose.VobChart Typ: UML Diagrammobjekt: Status

Name = Ausgangszustand

: Zustand

Name = nächster Zustand

:übergang:Aktion

Name = Aktion

: Fall

name = EventArguments = ArgumentGuardCondition = Bedingung

Abbildung 4.57: Interne Darstellung der Transformation in Abbildung 4.55 in Rose.

welche classAction zurückgibt (siehe Abbildung 4.10). Bei dieser Übermittlungsaktion werden die Aktion, die Parameter und das Ziel der Aktion ihren eigenen Eigenschaften im Aktionsobjekt zugeordnet. Dies ermöglicht eine genauere Spezifikation der Semantik von Commit-Operationen.

Konformitätsbedingungen für (Schutz-)Bedingungen sind im UML-Metamodell ([OMG99], S. 2-136) spezifiziert:

• Übergang-1: Die Bewertung der Übergangsbedingungen darf keine Nebenwirkungen verursachen.

4.7.4 Status

„Ein Zustand ist eine Bedingung oder Situation im Lebenszyklus eines Objekts, während der ein Objekt eine Bedingung erfüllt, eine Aktivität ausführt oder auf ein Ereignis wartet“ ([BRJ99a], S. 328).

Ein Staat hat normalerweise einen Namen, um ihn von anderen Staaten zu unterscheiden. Der unbenannte Staat wird als „anonymer“ Staat bezeichnet.

Zustände können interne Übergänge enthalten. Wenn ein interner Übergang ausgelöst wird, findet kein Zustandsübergang statt. Insbesondere enden Zustände nicht, wie bei sogenannten automatischen Übergängen, deren Anfangs- und Folgezustand zusammenfallen.

„entry“, „exit“ und „do“ sind vordefinierte Ereignisse. Das Eintrittsereignis wird ausgelöst, wenn der Zustand betreten wird, und das Ausgangsereignis wird ausgelöst, wenn der Zustand verlassen wird. do feuert kontinuierlich, solange der Zustand aktiv ist.

185 Kapitel 4 Tool-Unterstützung und -Konformität

Die mit einem do-Ereignis verbundene Aktion ist eine Aktivität, also eine nichtatomare Abfolge von Aktionen. Eine Aktion kann als Folge von Aktionen angegeben werden (Metamodellklasse ActionSequence, siehe Abbildung 3.34, Seite 85), d. h. sie kann mehrere Aktionen als eine Aktivität enthalten. Die Unterscheidung zwischen atomaren Operationen und nichtatomaren Aktivitäten hat mit dem Laufzeitverhalten von Zustandsmaschinen zu tun: Aktivitäten können durch Ereignisse unterbrochen werden, während Operationen immer bis zum Abschluss ausgeführt werden.

Zusätzlich zu den vordefinierten Ereignissen können Zustände auch benutzerdefinierte Ereignisse enthalten. Für jedes dieser Ereignisse kann eine Aktion oder Aktivität angegeben werden. Wie im Bild gezeigt. Abbildung 4.58 zeigt eine Zustandsdarstellung mit internen Übergängen.

Staatsname

Exit: Exit-Aktion. Do: Auf persistente Aktivität zurückstellen: Deferentry: Eintrittsereignis bei Ereignis (Argument) [Bedingung]: Aktion

Abbildung 4.58: Single-State-Symbol.

Das entsprechende Metamodell-Beispiel (Abb. 4.59) ist deutlich komplexer, da es eine Handlungssemantik enthält, die in Abb. 4.5 nicht intuitiv erfasst werden kann. 4,58.

Die Rose State-Metaklasse verfügt über die Operationen GetEntryActions, GetExit-Actions, GetDoActions und GetUserDefinedEvents, über die die entsprechenden Aktionen bzw. Ereignisse ermittelt werden können (siehe Abbildung 4.10). Die Art der Operation kann jedoch nicht bestimmt werden (siehe Abschnitt 4.7.2).

Die Spezifikation eines Ereignisses in einem Zustand muss (mindestens) zwei Bedingungen erfüllen:

• Ereignis-4: Jeder Ereignisname kann in einem Zustand mehrfach verwendet werden, wenn die (Schutz-)Bedingung eindeutig ist. ([OMG99], S. 3-132)

• Ereignis-5: Aktionen von Eintritts-, Austritts- und Ausführungsereignissen können nicht durch Bedingungen blockiert werden.

Im UML-Metamodell (Abbildung 3.47, Seite 109) sind diese Operationen abhängige Teile der Zustandsexistenz (Zusammensetzung) und nicht mit Bedingungen verbunden.

In Rose kann die Konsistenzbeschränkung von Ereignis 5 nicht verletzt werden. Es wurde kein Verstoß gegen die Ereignis-4-Bedingung festgestellt, auch wenn das vordefinierte Ereignis mehrfach angegeben werden kann.

4.7. Zustandsgraph 186

Diagrammname: Neues DiagramChart-Objektdateiname: objUntitled2.VobChart Typ: UML-Objektdiagramm

nicht näher bezeichnete Tätigkeit

: einfacher Zustand

Name = Staat

: CallAction : Aktion

Name = Eingabeaktion

:Aktion senden: Signal

Name = Ausgabeaktion

: Aktion

: Anrufereignis

: Betrieb

Name = Verzögerung

: Übergang

: Anrufereignis

Betrieb

Name = Ereignis

: Umfang

Name = Parameter

: bewachen

Ausdruck = Bedingung: CallEvent

: Betrieb

Name = Aktion

verbieten

Ausfahrt

Aktivitäten durchführen

aufschiebbare Ereignisse

Intern

eine Schutzwirkung auslösen

Abbildung 4.59: Ein Beispiel für ein Zustandsmetamodell für Graphen. 4,58.

4.7.5 Zustandsmaschine

UML-Zustandsmaschinen werden rekursiv aufgebaut (Abbildung 4.60). Jeder Zustandsautomat besteht aus einem Zustand der obersten Ebene, der weitere Zustände enthalten kann. Zustände der obersten Ebene werden in Zustandsdiagrammen nicht dargestellt. Zustände, die in einem Zustand der obersten Ebene enthalten sind, können zusammengesetzte Zustände sein, die wiederum zusammengesetzte Zustände enthalten können, oder „einfache“ Zustände, die keine anderen Zustände enthalten. Zusammengesetzte Zustände können Anfangs- und Endzustände sowie andere Pseudozustände wie flache und tiefe Zustände umfassen.

Ein zusammengesetzter Zustand stellt eine Zustandsmaschine innerhalb einer Zustandsmaschine dar. Zum Beispiel die synthetische Zustandsebene B 1 in Abbildung 1. 4.61 enthält zusammengesetzte Start-, End- und Level-C2-Zustände, die wiederum andere Zustände enthalten. Auf diese Weise lassen sich nicht nur flache Zustandsmaschinen konstruieren, sondern auch Zustandsmaschinen, deren Zustände auf unterschiedlichen Ebenen liegen. Die Modellierung von Übergängen ist nicht auf eine Ebene beschränkt: Übergänge zwischen Zuständen können auf mehreren Ebenen modelliert werden (Abb. 4.61).

Ein Beispielmetamodell in Abbildung 1. 4.61 ist zu kompliziert und wird daher hier weggelassen. Diese Art von Zustandsmaschine kann mit Rose modelliert werden. Rose-

187 Kapitel 4 Tool-Unterstützung und -Konformität

Zustandsmaschine

Zustand

1..1

0..1

+ Gelände 1..1

Zusammengesetzter Zustand

0..1

0..*

0..1

+ Behälter

0..1

0..*

Abbildung 4.60: Rekursive Struktur einer Zustandsmaschine (vereinfachte Darstellung, siehe auch 3.47, S. 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 einer Zustandsmaschine mit mehreren verschachtelten (kombinierten) Zuständen (B und C).

4.7. Zustandsgraph 188

Die State-Metaklasse (Abbildung 4.10, Seite 141) verfügt über die Attribute Substates und StateKind, die die Unterzustände des Staates oder des Zustandstyps (Start-, Endzustand oder Normalzustand) bereitstellen. Flache und tiefe Speicherzustände können von Rose-Script modelliert, aber nicht richtig bestimmt werden.

Für Zustandsmaschinen, einfache Zustände, Zusammensetzung und Pseudozustände definiert [OMG99], S. 2-135ff. mehrere Konsistenzbedingungen:

• Zustandsmaschine-1: Eine Zustandsmaschine ist ein Klassifikator oder ein Verhaltensmerkmal.

• Zustandsmaschine-2: Wenn eine Zustandsmaschine Verhaltensmerkmale beschreibt, kann sie keine Ereignisauslöser vom Typ „Invoke Event“ haben. Die Ausnahme besteht darin, dass das Übergangsereignis „Anfangszustandsausgang der obersten Ebene“ ausgelöst wird.

• Zustandsmaschine-3: Der Zustand der obersten Ebene ist immer ein zusammengesetzter Zustand.

• Zustandsmaschine-4: Der Zustand der obersten Ebene kann nicht der Startzustand eines Übergangs sein.

• Zustand-1: Ein zusammengesetzter Zustand kann höchstens einen Anfangszustand haben.

• Zustand-2: Ein zusammengesetzter Zustand kann höchstens einen flachen Speicherzustand oder einen tiefen Speicherzustand haben.

• Übergang-2: Der Anfangszustand kann höchstens einen ausgehenden Übergang haben.

• Übergang-3: Der Anfangszustand kann keine eingehenden Übergänge haben.

• Übergang-4: Der Endzustand kann keine ausgehenden Übergänge haben.

• Übergang-5: Ein Speicherzustand kann höchstens einen Ausgangsübergang haben.

• Übergang-6: Übergänge, die auf Pseudozuständen basieren (z. B. Anfangszustand und Alarmzustand, siehe Abschnitt 3.2.3), dürfen keine Ereignisauslöser haben. Ausnahme: Übergänge vom Anfangszustand zum Top-Level-Zustand.

• Transition-7: Ein Übergang vom Anfangszustand zum Top-Level-Zustand kann einen Ereignisauslöser mit dem Stereotyp „create“ haben. Dieser Übergang kann einen Ereignisaufruf haben, wenn die Zustandsmaschine ein Verhaltensmerkmal angibt.

189 Kapitel 4 Tool-Unterstützung und -Konformität

• Übergang-8: Nachfolgende Zustände des Speicherzustands müssen im gleichen kombinierten Zustand sein6.

In Rose gehört ein Zustandsdiagramm immer zu einer Klasse. Zustände der obersten Ebene können in Rose nicht explizit modelliert werden und werden nicht angezeigt. In Rose ist der Zustand der obersten Ebene die Zustandsmaschine selbst (Rose State-Machine-Metaklasse). In Rose können zusammengesetzte Zustände nur einen Anfangszustand enthalten und keine Eingabeübergänge haben. Auch die Modellierung von Übergängen aus Endzuständen ist nicht möglich. Beim Spezifizieren von Übergängen gibt es in Rose keine weitere Unterscheidung zwischen Zuständen und Pseudozuständen: Ein Übergang kann immer einen Ereignisauslöser, eine Bedingung und eine Aktion haben, und der Anfangs- und Folgezustand kann sich auf jeder Ebene der Zustandsmaschine befinden.

Ein gleichzeitiger zusammengesetzter Zustand kann zwei oder mehr zusammengesetzte Zustände haben, die als Regionen oder Regionen bezeichnet werden (siehe Abbildung 4.62). Diese Gebiete sind wiederum zusammengefasste Staaten. Eine Zustandsmaschine mit gleichzeitigen Regionen kann mit Rose nicht modelliert werden. Dies gilt auch für die anderen in diesem Abschnitt beschriebenen Arten von Zustandsmaschinen.

UML V1.3 Beta R5 3. Mai 1999�

-135

3,77 Ereignisse

Abbildung 3-63 Gleichzeitige Unterzustände

3�

.76.4 Zuordnung

Ein Symbol eines Landes.

Bol ist dem Bundesstaat S zugeordnet. Wenn ein Symbol keinen Untergraphen hat, wird es Sim zugeordnet.

Bitte angeben. Wenn es in der Region durch eine gepunktete Linie gekachelt ist, wird es einem zugeordnet

Die Parallelität von i ist wahr; andernfalls wird sie einem CompositeState mit i zugeordnet

Begleitet

Der Wert ist falsch.

Das anfängliche Pseudozustandssymbol wird einem Pseudozustand vom Typ in zugeordnet.

Initial. Das

Die Endzustandssymbole werden auf � abgebildet

Flosse

zum Land.

.77 Vorfall

3�

.77.1 Semantik

Ereignisse sind bemerkenswerte Ereignisse. Aus praktischen Gründen handelt es sich in einem Zustandsdiagramm um ein Ereignis, das einen Zustandsübergang auslösen kann. Ereignisse können unterschiedlicher Art sein (nicht unbedingt gegenseitig ausschließend).

Labor 1 Labor 2

Ter�

Reis

Experiment abgeschlossen

Projektabschluss

die Vergangenheit

unvollständig

Projekt

endlich bestanden

prüfen

Fehler fehler

Experiment abgeschlossen

T�

meine Klasse

Abbildung 4.62: Gleichzeitiger kombinierter Zustand mit drei Regionen (unvollständig). (Aus [OMG99], S. 3-135)

6 In [OMG99] nicht explizit erforderlich.

4.7. Zustandsgraph 190

Für gleichzeitige zusammengesetzte Zustände sind in [OMG99], S. 2-135ff, folgende Konsistenzbedingungen definiert:

• Zustand-3: Ein gleichzeitiger zusammengesetzter Zustand muss mindestens zwei zusammengesetzte Zustände (Regionen) haben.

• Zustand-4: Gleichzeitige zusammengesetzte Zustände können nur zusammengesetzte Zustände als direkte Unterzustände enthalten.

Verschiedene Übergänge in und aus gleichzeitigen Regionen können mithilfe von Fork- und Join-Pseudozuständen modelliert werden (Abbildung 4.63). Diese Transformationen werden auch als gleichzeitige Transformationen bezeichnet.

3-140 UML V1.3 Beta R5 Mai 1999

3 UML-Notation

3.79.3 Beispiele

Abbildung 3-65 Simultane Konvertierung

3.79.4 Zuordnung

Ein Schrägstrich mit mehreren Übergangspfeilen, der ihn einem verzweigten Pseudozustand zuordnet. Balken mit mehreren Übergangspfeilen werden pseudoverbundenen Zuständen zugeordnet. Übergänge, die den Ein- und Auswärtspfeilen entsprechen, werden an den Pseudozustand angehängt, als wäre es ein regulärer Zustand. Wenn ein Balken über mehrere Ein- und Auswärtspfeile verfügt, wird er einer Verbindung zugeordnet

� Stellen Sie über einen einzigen Übergang ohne Anhang eine Verbindung zum Fork-Pseudozustand her.

3.�

80 Übergänge in und aus zusammengesetzten Zuständen

3.80.1 Semantik

�

Ein zu einer zusammengesetzten Zustandsgrenze gezeichneter Übergang entspricht einem Übergang zu seinem Ursprung (oder einem komplexen Übergang zum Ursprung jeder seiner gleichzeitigen Regionen, falls diese gleichzeitig sind). Wenn ein Zustand von außen betreten wird, wird immer die Eintrittsaktion ausgeführt.

Ein Übergang von einem zusammengesetzten Zustand stellt einen Übergang dar, der für jeden Zustand in s gilt.

Tate-Bereich (in jeder Tiefe). Es wird von verschachtelten Zuständen „vererbt“. Geerbte Transformationen können durch das Vorhandensein verschachtelter Transformationen mit demselben Auslöser in Frage gestellt werden.

3.80.2 Symbole

Ein zu einer zusammengesetzten Zustandsgrenze gezeichneter Übergang stellt einen Übergang zu einem zusammengesetzten Zustand dar. es ist gleich

Entspricht dem Übergang zum anfänglichen Pseudozustand innerhalb der zusammengesetzten Zustandsregion. Anfangss

yourdostate muss vorhanden sein. Wenn der Zustand ein gleichzeitiger zusammengesetzter Zustand ist, dann sind die drei

ansition zeigt einen Übergang zum anfänglichen Pseudozustand jedes seiner gleichzeitigen Unterzustände an.

Übergänge können direkt zu Zuständen innerhalb eines zusammengesetzten Zustandsbereichs beliebiger Verschachtelungstiefe gezeichnet werden.

Tag. Führt alle Eingabeoperationen für jeden in einem beliebigen Übergang eingegebenen Zustand aus. in drei

Um Übergänge innerhalb eines zusammengesetzten Zustands zu synchronisieren, kann für einen oder mehrere gleichzeitige Zustände ein Synchronisationsbalken-Übergangspfeil gezeichnet werden. Alle anderen gleichzeitigen Regionen beginnen mit Ihrer Standardeinstellung.

p Ihr anfänglicher Endzustand.

Verfahren

Selen

Abbildung C

Neigung

A1�

B2B1

Abbildung 4.63: Vertikale Balken bilden Gabelungen und Verbindungen von Pseudozuständen ab. Sie werden zur Synchronisierung von Synchronisierungszonen verwendet. Ausgehende Übergänge für Synchronisierungsleisten werden erst ausgelöst, nachdem alle eingehenden Übergänge ausgeführt wurden. (Aus [OMG99], S. 3-140)

Für diese Pseudozustände und gleichzeitigen Übergänge werden zusätzliche Konsistenzbedingungen definiert ([OMG99], S. 2-136):

• Zustand-5: Ein Fork-Pseudozustand muss mindestens zwei ausgehende Übergänge und genau einen eingehenden Übergang haben.

• Zustand-6: Ein Verbindungspseudozustand muss mindestens zwei Eingabeübergänge und einen Ausgabeübergang haben.

• Übergang-9: Vom Fork-Pseudozustand abgeleitete Übergänge dürfen keine Ereignisauslöser oder Bedingungen enthalten.

• Übergang-10: Ein Übergang zu einem Verbindungspseudostatus darf keine Ereignisauslöser oder Bedingungen enthalten.

• Übergang-11: Der Anfangszustand eines Übergangs in einen Verbindungs-Pseudozustand darf kein Pseudozustand sein.

191 Kapitel 4 Tool-Unterstützung und -Konformität

• Übergang-12: Der Nachfolgestatus eines Fork-Pseudostatus kann kein Pseudostatus sein.

• Übergang-13: Der Anfangszustand des Übergangs in den Knoten-Pseudozustand muss ein Unterzustand des gleichzeitigen zusammengesetzten Zustands sein, dh er muss der Zustand der Region sein.

• Übergang-14: Der nachfolgende Zustand eines verzweigten Pseudozustands muss ein Unterzustand eines gleichzeitigen zusammengesetzten Zustands sein.

Gleichzeitige Regionen zusammengesetzter Zustände können mit synchronen Pseudozuständen synchronisiert werden. Das Auslösen von Übergängen außerhalb des Sync-Status kann durch Angabe eines Schwellenwerts eingeschränkt werden. Der Schwellenwert ist die Differenz zwischen der Häufigkeit der Übergangsauslöser für den Eintritt in den und das Verlassen des synchronisierten Zustands (siehe Abbildung 4.64). Für den Synchronisierungsstatus

UML V1.3 Beta R5 3. Mai 1999�

-147

3.83 Synchronisierungsstatus

3�

.83 Synchronisierungsstatus

3�

.83.1 Semantik

Der Synchronisierungsstatus wird verwendet, um die gleichzeitigen Bereiche der Zustandsmaschine zu synchronisieren. Es wird in Verbindung mit Fork und Join verwendet, um sicherzustellen, dass die Region einen bestimmten Zustand oder Zustand b verlässt.

Bevor eine andere Region einen oder mehrere bestimmte Staaten betreten kann. Das Auslösen von Übergängen außerhalb des synchronen Zustands kann durch die Angabe eines Schwellenwerts für die Differenz zwischen der Anzahl der Auslösungen von Out- und In-Übergängen begrenzt werden.

3�

.83.2 Notation

A�

Der Synchronisierungsstatus wird als kleiner Kreis mit einer Obergrenze angezeigt. „Limit“ ist eine positive Zahl oder ein Sternchen („*“) für „kein Limit“. Der Synchronisierungsstatus wird an der Grenze zwischen den beiden gezeichnet

o Mögliche Bereiche.

3�

.83.3 Beispiele

Abbildung 3-71 Synchronisierungsstatus

aufstellen

Strom installieren

Ein Haus bauen

Überprüfen Sie die Installation

Base

Quadro

im Fundament

Installieren Sie Strom im Rahmen

aufs Dach legen

Elektrischen Ausgang installieren

Idee

Installieren Sie Paredes

Abbildung 4.64: Synchronisierung gleichzeitiger Regionen mit synchronisiertem Status (*). Ein Sternchen gibt einen unbegrenzten Wert für das Synchronisierungsstatuslimit an. (Aus [OMG99], S. 3-147)

Zwei Konformitätsbedingungen müssen eingehalten werden ([OMG99], S. 2-137):

• Status-7: Der Schwellenwert für den Synchronisierungsstatus muss eine positive ganze Zahl oder unbegrenzt sein.

• Übergang-15: Alle eingehenden Übergänge in einem synchronisierten Zustand müssen aus einer einzigen Region stammen und alle ausgehenden Übergänge müssen ihr Ziel in einer einzigen Region haben.

4.7. Zustandsgraph 192

Das Rendern von Inhalten für verschachtelte Kompositionszustände kann unterdrückt werden. Übergänge zu solchen Zuständen können durch Stub-Pseudozustände dargestellt werden (siehe Abbildung 4.65). In [OMG99] ist keine Konsistenzbedingung für den Stub-Status angegeben.

3-142 UML V1.3 Beta R5 Mai 1999

3 UML-Notation

Abbildung 3-66 Interrupt-Übergang

Abbildung 3-67 Historische Indikatoren

3.80.5 Zuordnung

ein arr

Der Fluss einer beliebigen Zustandsgrenze, ob verschachtelt oder nicht, wird auf Übergänge zwischen den entsprechenden Zuständen und ebenfalls direkt auf den Verlaufszustand abgebildet.

Historische Metriken werden Pseudozuständen vom Typ „shallowHistory“ oder „de“ zugeordnet

elektronische Geschichte.

C�

Blu-Ray

Zweite

Nachwort

Tonne

Zweite

Mann

W�

kann abstrahiert werden als

klein

C�

unterbrechen

genesen

Abbildung 4.65: Details in zusammengesetzten Zuständen können unterdrückt werden. Übergänge in und aus Zuständen werden durch Stub-Zustände dargestellt. (Aus [OMG99], S. 3-142)

Komplexe Übergangspfade können mit Verbindungspseudozuständen modelliert werden (Abbildung 4.66). Sie können über mehrere Eingabe- und Ausgabeübergänge verfügen, die zum Modellieren statischer bedingter Verzweigungen verwendet werden können.

Dynamische bedingte Verzweigungen können mithilfe von Auswahlpseudozuständen modelliert werden. In Abb. 4.67 wird der Wert von a durch die (gedachte) Ausführungszeit des Automaten bestimmt.

Zusätzliche Konformitätsbedingungen sind in [OMG99] für die Verbindungs- und Auswahl-Pseudozustände definiert:

• State-7: Join- und Select-Pseudozustände müssen mindestens einen eingehenden und einen ausgehenden Übergang haben ([OMG99], Seite 2-136).

• Zustand-8: Nur Übergänge aus den Pseudozuständen „Join“ oder „Choice“ können vordefinierte Bedingungen haben ([OMG99], Seite 2-130).

193 Kapitel 4 Tool-Unterstützung und -Konformität

3-144 UML V1.3 Beta R5 Mai 1999

3 UML-Notation

3.81.3 Beispiele

In Abbildung 3-68 wird ein einzelner Verbindungspunkt zum Mischen und Teilen von Übergängen verwendet. Jedoch

Unabhängig davon, ob der Verbindungspunkt vom Zustand State0 oder vom Zustand State1 erreicht wird, ist der Austrittspfad in beiden Fällen derselbe.

Wenn sich die Zustandsmaschine in diesem Beispiel im Zustand State1 befindet und b kleiner als 0 ist, wenn Ereignis e1 auftritt, dann o�

Kontinuierliche Übergänge werden nur durchgeführt, wenn einer der drei nachgeschalteten Wächter wahr ist. Deshalb, wenn

An diesem Punkt ist a gleich 6 und es wird kein Übergang ausgelöst.

Abbildung 3-68 Verbindungspunkt

Im Beispiel des dynamischen Auswahlpunkts in Abbildung 3-69 wird die Entscheidung darüber, welche Verzweigung genommen werden soll, erst getroffen, nachdem ein Übergang von Zustand 1 den Auswahlpunkt erreicht. Beachten Sie, dass die mit dieser Eingabetransformation verbundene Operation einen neuen Wert für a berechnet. Dann ist dieser neue Wert in Ordnung.

Wird verwendet, um die durchzuführende Ausgabetransformation zu bestimmen. Es wird empfohlen, die vordefinierte Bedingung [else] zu verwenden, um Laufzeitfehler zu vermeiden.

Abbildung 3-69 Dynamischer Auswahlpunkt

[a < 0]

heilig

Leber 1

heilig

comeu2 S�

Tate 3rd Street

comeu4

e1 [b < 0] e2 [b < 0]

heilig

common0

[a=5]

[a > 7]

[a < 0]

S�

Reihe 1

heilig

comeu2 S�

Tate 3rd Street

comeu4

e1[ b < 0]/a := f(m)

[a=5]

[andere]

Abbildung 4.66: Pseudozustände hinzufügen (aus [OMG99], Seite 3-144)

3-144 UML V1.3 Beta R5 Mai 1999

3 UML-Notation

3.81.3 Beispiele

In Abbildung 3-68 wird ein einzelner Verbindungspunkt zum Mischen und Teilen von Übergängen verwendet. Jedoch

Unabhängig davon, ob der Verbindungspunkt vom Zustand State0 oder vom Zustand State1 erreicht wird, ist der Austrittspfad in beiden Fällen derselbe.

Wenn sich die Zustandsmaschine in diesem Beispiel im Zustand State1 befindet und b kleiner als 0 ist, wenn Ereignis e1 auftritt, dann o�

Kontinuierliche Übergänge werden nur durchgeführt, wenn einer der drei nachgeschalteten Wächter wahr ist. Deshalb, wenn

An diesem Punkt ist a gleich 6 und es wird kein Übergang ausgelöst.

Abbildung 3-68 Verbindungspunkt

Wird verwendet, um die durchzuführende Ausgabetransformation zu bestimmen. Es wird empfohlen, die vordefinierte Bedingung [else] zu verwenden, um Laufzeitfehler zu vermeiden.

Abbildung 3-69 Dynamischer Auswahlpunkt

[a < 0]

heilig

Leber 1

heilig

comeu2 S�

Tate 3rd Street

comeu4

e1 [b < 0] e2 [b < 0]

heilig

common0

[a=5]

[a > 7]

[a < 0]

S�

Reihe 1

heilig

comeu2 S�

Tate 3rd Street

comeu4

e1[ b < 0]/a := f(m)

[a=5]

[andere]

Abbildung 4.67: Pseudozustand auswählen (aus [OMG99], Seite 3-144)

4.7. Zustandsgraph 194

Zustandsmaschinen können zu anderen irgendwo angegebenen Zustandsmaschinen übergehen. Dies wird als Referenzzustandsmaschine bezeichnet. Die Zustände der Referenzzustandsmaschine werden als Stub-Zustände dargestellt (siehe Abbildung 4.68) und auf die Metamodellklasse SubmachineState abgebildet.

3-146 UML V1.3 Beta R5 Mai 1999

3 UML-Notation

3.82.3 Beispiele

Die folgende Abbildung zeigt einen Ausschnitt eines Zustandsdiagramms, in dem eine Teilmaschine (FailureSubmachine) auf eine bestimmte Weise aufgerufen wird. Die eigentliche Teilmaschine kann auf andere Weise definiert werden

Hier in dieser Abbildung nicht dargestellt. Beachten Sie, dass dieselbe Submaschine eingeschaltet sein kann.

Wird an anderer Stelle im selben Zustandsdiagramm mit unterschiedlichen Eingabe- und Ausgabekonfigurationen aufgerufen.

Abbildung 3-70 Mobilteilstatus

Im obigen Beispiel endet der durch das Ereignis „error1“ ausgelöste Übergang im Zustand „sub1“ der FailureSubmachine-Zustandsmaschine. Da der Einstiegspunkt keinen Pfadnamen enthält, m�

Zeigt an, dass „sub1“ auf der obersten Ebene dieses Subs definiert ist. Im Gegensatz dazu der Übergang

Von „error2“ generierte Ergebnisse landen im Unterzustand „sub12“ des Unterzustands „sub1“ (wie gezeigt).

Pfadname), während die „error3“-Transformation die Standard-FailureSub-Transformation impliziert.

Maschine.

autry

Die durch das Ereignis „fixed1“ verursachte Angst hat ihren Ursprung im Unterzustand „subEnd“ des Slaves. Wenn schließlich eine FailureSubmachine ihren Endzustand erreicht, wird ein Übergang von einer Submachine-Zustandskante als Ergebnis eines Abschlussereignisses betrachtet.

3.82.4 Zuordnung

dein

Der bmachine-Zustand im Zustandsdiagramm wird direkt dem SubmachineState im Metamodell zugeordnet. Der Name nach dem reservierten Aktions-Tag „add“ gibt die Zustandsmaschine an, die durch das Attribut „submachine“ angegeben wird. Der Stub-Zustand entspricht dem Stub-Zustandskonzept in m.

Modell. Die Beschriftungen im Diagramm entsprechen den Pfadnamen, die durch das Attribut „referenceState“ des Stub-Status dargestellt werden.

Verarbeitung fehlgeschlagen

Ausfall der Einschluss-/Untermaschine

ist b1 ist b1::sub12

Kind Ende

e�erro2/e�erro1/

Fehler 3/

fixo1/

Abbildung 4.68: Die Submaschine stateHandleFailure enthält die Zustandsmaschine FailureSubmachine. (Aus [OMG99], S. 3-146)

Für Referenzzustandsmaschinen sind zusätzliche Konsistenzbedingungen definiert ([OMG99], S. 2-137):

• Untermaschinenzustand 1: Ein Untermaschinenzustand (keine Referenzzustandsmaschine!) kann nur Stub-Zustände enthalten.

• Submaschinenstatus 2: Ein Submaschinenstatus kann kein gleichzeitiger zusammengesetzter Status sein.

Kapitel 5

Benutzeroberflächenkonzepte für die Konsistenzprüfung in Rational Rose 98

Rational Rose kann mit Hilfe von Rose-Script um Konsistenzprüfungen erweitert werden. Wie der Name schon sagt, können Sie mit Rose-Script Skripte erstellen. Diese Skripte müssen auf Benutzeranforderung gestartet werden. Sie können eine grafische Benutzeroberfläche enthalten, sodass der Benutzer die Ausführung des Skripts steuern kann.

Da Skripte nicht ereignisgesteuert gestartet werden können, gibt es keinen Mechanismus, um Inkonsistenzen zu vermeiden oder bei der Modellierung zu unterstützen. Das Skript muss immer beendet werden, d. h. es ist nicht möglich, das Skript zu stoppen, das Modell zu ändern und das Skript fortzusetzen.

Abschnitt 5.1 beschreibt kurz die in Rose-Script verfügbaren Möglichkeiten zur Überprüfung von Konformitätsbedingungen und zur Erstellung grafischer Benutzeroberflächen. In Abschnitt 5.2 werden die Kriterien erläutert, anhand derer Konformitätsbedingungen erstellt werden.

5.1 Möglichkeiten von Rose-Script

Mit Rose-Script sind (fast) alle Informationen zugänglich, die der Modellierer in Rose angibt. Diese Informationen sind in Objekten der Rose-Tools-Metamodellklasse vorhanden (§4.4). Die Möglichkeiten von Rose-Script beschränken sich nicht nur auf die bloße Ermittlung der benötigten Informationen. Objekte (Modellelemente) können erstellt, gelöscht und geändert werden, genau wie Modellierer in Rose. Daher können UML-Modelle neben der reinen Verifikation auch überarbeitet werden. Allerdings ist das Rose-Metamodell nicht erweiterbar.

Ein ausführbares Skript besteht aus einer einzelnen (Haupt-)Unterroutine. Skripte können andere Unterprogramme und benutzerdefinierte Funktionen enthalten

195

5.1. Möglichkeiten der Rosenschrift 196

Argumente können per Call-by-Reference oder Call-by-Value übergeben werden. Skripte können andere ausführbare Skripte starten und andere Skripte (die nicht unbedingt über eine Hauptroutine verfügen) in den Speicher laden und den enthaltenen Code verwenden.

In Rose können die folgenden Datentypen zum Deklarieren von Variablen verwendet werden:

• Any: beliebiger, nicht spezifizierter Datentyp,

• Datum: Datum und Uhrzeit,

• Variante: Ein Datentyp, der verschiedene Datentypen enthalten kann,

• die StandarddatentypenBoolean, Double, Single, Integer undString,

• Rose-Metamodellklassen (z. B. Class, RoseItem),

• Eine Sammlung von Objekten, die Rose-Metamodellklassen enthalten (z. B. ClassCollection, RoseItemCollection) und

• Arrays mit statischer oder dynamischer Größe.

Benutzerdefinierte Datentypen können nur als statische Arrays deklariert werden. Es ist nicht möglich, neue Klassen mit Attributen und Operationen zu definieren.

Routinen, Funktionen und Variablen können als öffentlich, privat oder global deklariert werden. Es stehen „universelle“ Operatoren (>, <, =, and, or, +, − usw.) und Kontrollstrukturen (If-Then-Else, For...Next, Do...Loop, while) zur Verfügung.

Zur Ermittlung des Betriebssystems und der betriebssystembezogenen Attribute des Computers stehen mehrere Funktionen zur Verfügung. Dies ist wichtig, da nicht alle Rose-Script-Funktionen auf allen Plattformen verfügbar sind. Dies betrifft insbesondere die Möglichkeit einer grafischen Benutzeroberfläche, die nur auf der Windows32-Plattform voll ausgeschöpft werden kann.

Eine GUI in Form eines Dialogs kann folgende Elemente enthalten (alle Plattformen, ohne Anspruch auf Vollständigkeit):

• Verschiedene Schaltflächen (OK, Abbrechen und benutzerdefinierte Schaltflächen)

• Optionsfelder zum Auswählen einer Option aus statisch festgelegten Optionen

• Dropdown-Listen und Listen zur Auswahl einer Option aus einer Reihe von Möglichkeiten, die zur Laufzeit durch den Inhalt des Arrays bestimmt werden

• Aktivieren Sie das Kontrollkästchen, um die Option zu aktivieren/deaktivieren.

197 Kapitel 5 Konsistenzprüfung der Benutzeroberfläche

Ein Dialog ist als Modell definiert, das die Struktur eines Dialogs beschreibt. Ein Dialog kann eine Dialogfunktion haben, seine Parameter sind jedoch festgelegt. Wenn der Benutzer beispielsweise ein Kontrollkästchen aktiviert oder eine Optionsschaltfläche auswählt, wird eine Dialogboxfunktion ausgeführt. Auf diese Weise kann der Inhalt des Dialogfelds in kleinen Schritten dynamisch geändert werden. Dialogfunktionen werden hauptsächlich verwendet, um Dialogelemente basierend auf anderen Dialogelementen zu aktivieren/deaktivieren oder auszublenden oder sichtbar zu machen. Wenn das Array, das den Inhalt des Dropdowns bereitstellt, durch eine Dialogfunktion geändert wird, hat dies keine Auswirkungen auf den Dialog. Änderungen werden erst sichtbar, wenn der Dialog erneut geöffnet wird. Leider ist es nicht möglich, benutzerdefinierte Dialoge zu verschachteln.

5.2 Aufbau der Konsistenzprüfung

Die Überprüfung aller Konformitätsbedingungen aller Modellelemente eines UML-Modells der realen Systementwicklung ist zeitaufwändig und führt insbesondere in den frühen Entwicklungsstadien häufig zu vielen Inkonsistenzmeldungen, die für den Modellierer nicht von Interesse sind. . Interessante Informationen gehen in der Menge verloren. Daher sollte der Benutzer die Möglichkeit haben, zu einem bestimmten Zeitpunkt nur die Konsistenzprüfungen durchzuführen, an denen er interessiert ist.

Betrachtet man die Entwicklungsphase, vom Konzept bis zur Umsetzung, werden Konformitätsbedingungen erst in späteren Entwicklungsstadien interessant. Entsprechend der unterschiedlichen Entwicklungszeit kann die Konsistenzbedingung in zwei Typen unterteilt werden:

1. Konsistenzbedingungen, die niemals verletzt werden dürfen („grundlegende Fehler“) Diese Konsistenzbedingungen werden nicht durch unvollständige Modellspezifikationen, sondern durch falsche Spezifikationen verletzt.

2. Konsistenzbeschränkungen werden aufgrund einer unvollständigen Spezifikation verletzt. Ob die Überprüfung dieser Konformitätsbedingungen Modellierern interessante Informationen liefern kann, hängt von der Entwicklungszeit und dem Erwartungsgrad der formalen Spezifikation ab.

Die meisten Konformitätsbedingungen lassen sich Modellelementen und damit meist auch Diagrammtypen zuordnen. Daher können die Konsistenzbedingungen grafisch sortiert werden.

Es gibt Konsistenzbeschränkungen, die verletzt werden und automatisch korrigiert werden können. Dabei handelt es sich in erster Linie um Konsistenzbeschränkungen, die die Existenz anderer Modellelemente erfordern. Ein weiteres Unterscheidungsmerkmal ist das Merkmal mit oder ohne Revisionsmöglichkeit.

Da es nicht immer notwendig ist, das gesamte Modell auf Konformitätsbedingungen zu überprüfen, sollte es möglich sein, nur bestimmte Bereiche des Modells zu überprüfen.

5.3. Benutzeroberflächenkonzepte 198

5.3 Benutzeroberflächenkonzepte

Die obigen Überlegungen führten zu folgendem Konzept, das auch umgesetzt wurde (siehe Abbildung 5.1):

1. Die Konsistenzprüfung wird entsprechend der Grafik ausgewählt. Wählen Sie dazu über die Menüleiste den Diagrammtyp aus.

2. Konsistenzprüfungen werden nach Entwicklungszeit klassifiziert (siehe Abschnitt 5.2).

Wenn es im Kontext des Diagramms viele Konsistenzprüfungen gibt, werden diese auf mehrere Auswahldialoge verteilt.

3. Der Umfang der zu prüfenden Modellelemente kann nach mehreren Kriterien ausgewählt werden:

(a) Paketorientiert: Das gesamte Modell oder bestimmte Pakete (einschließlich aller enthaltenen Pakete) können zur Überprüfung ausgewählt werden.

(b) Diagrammorientiert: Je nach ausgewähltem Diagrammtyp können entweder alle Diagramme oder nur bestimmte Diagramme dieses Typs ausgewählt werden.

(c) Benutzerorientiert: Wenn der Benutzer Modellelemente auswählt, bevor er den Auswahldialog öffnet, kann er alle ausgewählten Modellelemente oder nur ein ausgewähltes Modellelement auswählen.

Die Validierung erfolgt anhand des Metamodells des Tools. Wählen Sie den Mindestumfang aus, der nur die zu prüfenden Modellelemente bestimmt.

4. Jede Prüfung kann einzeln ausgewählt werden.

5. Jede Prüfung kann interaktiv durchgeführt werden, d. h. wenn eine Inkonsistenz festgestellt wird, wird dem Benutzer ein Dialog mit den folgenden Informationen angezeigt (Abb. 5.2, siehe auch 4.2.4 Konsistenzprüfung als Informationsproduzent):

(a) Überprüfen Sie Konsistenzbeschränkungen.

(b) Modellelemente, die für Verletzungen von Konsistenzbeschränkungen verantwortlich sind.

Benutzer haben jetzt einige Optionen:

(a) Das Modellelement, das die Inkonsistenz verursacht hat, ist in der Dropdown-Liste „Modellelement“ verfügbar. wähle ein

199 Kapitel 5 Konsistenzprüfung der Benutzeroberfläche

Abbildung 5.1: Auswahldialog für die Konsistenzprüfung („Grundfehler“) im Klassendiagramm

5.3. Benutzeroberflächenkonzepte 200

Abbildung 5.2: Inkonsistenter Dialog

201 Kapitel 5 Konsistenzprüfung der Benutzeroberfläche

Die Modellelementanzeige (unterhalb des Dialogs) zeigt ein Diagramm des Modellelements. Auf diese Weise könne sich der Modellierer „ein inkonsistentes Bild machen“.

(b) Die Schaltfläche „Spezifikation öffnen“ beendet die Konsistenzprüfung und öffnet das Spezifikationsfenster für das in der Dropdown-Liste angegebene Element.

(c) Zeigen Sie die Schaltfläche und den Text für die automatische Korrektur an, wenn es sich um eine Konsistenzprüfung handelt, mit der Verstöße automatisch korrigiert werden können. Der Text beschreibt, was AutoCorrect tut.

(d) Schaltfläche „Weiter mit Einzelschritt“, um den Test interaktiv fortzusetzen.

(e) Der Button „Weiter ohne Einzelschritt“ setzt die Validierung ohne Interaktionsmöglichkeit fort.

(f) Die Schaltfläche „Abbrechen“ bricht die Prüfung ab.

6. Testmeldungen werden in die Standardausgabe (Unix) oder in ein spezielles Fenster (Windows) geschrieben. Beim nicht-interaktiven Scannen wird die Autokorrektur nur durchgeführt, wenn sie im Dialogfeld ausgewählt wird.

Anhang A

Implementierung der Benutzeroberfläche

Die Benutzeroberfläche wird über mehrere Skripte realisiert: Jeder Auswahldialog und jede Konsistenzprüfung befindet sich in einem eigenen Skript. Auch diverse Hilfsfunktionen (S. 203) sind in einzelnen Skripten hinterlegt.

Der Aufbau des Skripts wird in den nächsten beiden Abschnitten kurz erläutert. In den verbleibenden Abschnitten werden die entwickelten Skripte beschrieben und beschrieben, wie sie installiert werden.

A.1 Roadmap für Konsistenzprüfungen

Ein Skript, das eine Konsistenzprüfung durchführt, besteht aus mehreren Teilen:

1. Dialogvorlage: Die Dialogvorlage für inkonsistente Dialoge (Abb. 5.2, Seite 200) ist universell einsetzbar, muss aber leider aus technischen Gründen in allen Skripten vorhanden sein. Die Dialogvorlage verfügt über mehrere Variablen, die von der Routine zur Durchführung der Konsistenzprüfung festgelegt werden müssen:

(a) CheckText (String): Beschreibt die durchgeführte Prüfung.

(b) Aktionstext (Zeichenfolge): Beschreibt mögliche Aktionen zur Behebung der Inkonsistenz.

(c) autocorrect_possible (boolean): Gibt an, ob die Schaltfläche für die Autokorrektur (einschließlich Beschreibung) im Dialog sichtbar sein soll.

(d) AutoCorrectText (Zeichenfolge): Beschreibt die von AutoCorrect vorgenommenen Änderungen.

(e) OriginatorNames (String, Array): Enthält die Namen der Modellelemente, die das Diagramm anzeigen können.

(f) CauserObjects(RoseItem, Array): Genau genommen gehört es nicht zum Dialogmodell, es enthält Objekte (Modellelemente), die Diagramme anzeigen können.

202

203 Anhang A. Implementierung der Benutzeroberfläche

(g) InconsistencyText (String): Wird zum Generieren von Text verwendet, der Inkonsistenzen und beteiligte Modellelemente enthält.

2. Dialogfunktionen: Die Dialogfunktionen rufen unter anderem Routinen zur Darstellung von Diagrammen auf, in denen Modellelemente in inkonsistenten Dialogen ausgewählt sind. Es ist lediglich eine Routine zur Anzeige von Klassendiagrammen implementiert, die entsprechend angepasst werden muss, um Konsistenzprüfungen im Kontext anderer Diagrammtypen durchzuführen.

3. Validierungsroutinen: Das erste Argument einer Validierungsroutine ist immer vom Typ ArtCollection (z. B. ClassCollection oder AssociationCollection), bei dem es sich um die Sammlung von Modellelementen handelt, die die Validierungsroutine iterativ verarbeitet.

Die anderen Parameter sind Single und Cancel (beide boolesch, Call-by-Reference) und Auto (boolesch), wenn die Prüfung eine Autokorrektur umfasst. Testroutinen können auch Unterroutinen umfassen.

A.2 Skript für Auswahldialog

Das Skript für den Auswahldialog besteht neben Dialogmodellen und Dialogfunktionen aus mehreren Routinen, die basierend auf den ausgewählten Modellelementen und Konsistenzprüfungen Sammlungen aus den Parametern der Validierungsroutinen erstellen (z. B. CreateClassCollection, zugehörige Sammlungen erstellen).

Testroutinen werden zur Laufzeit dynamisch geladen und aus dem Speicher entfernt, da das gleichzeitige Laden mehrerer Skripte zu deutlich längeren Antwortzeiten führen kann.

A.3 Ausgearbeitete Reiseroute

A.3.1 Barrierefreiheitsfunktionen

Function HasAttributeType(anAttribute As Attribute) As VariantTask: Gibt True zurück, wenn ein Attribut einen Typ (Type) hat: Function_HasAttributeType.ebs

Funktion HasSameSignature(op1 As Operation, op2 As Operation) As VariantTask: Gibt True zurück, wenn beide Operationen dieselbe Signaturdatei haben: Function_HasSameSignature.ebs

A.3. Entwickelte Skripte 204

Function ExistsOperationSignatureInClass(theClass As Class, theOperation As Operation) As VariantTask: Überprüfen Sie, ob die Operation in der Klasse existiert.File: Function_ExistsOperationSignatureInClass.ebs

Funktion ExistsOperationSignatureInSuperclasses(theClass As Class, theOperation As Operation) As VariantTask: Prüft, ob die Operationssignatur in einer Superklasse dieser Klasse vorhanden ist. Datei: Function_ExistsOperationSignatureInSuperclasses.ebs

Funktion IsAssociationNavigable(anAssociation As Association) As VariantTask: Gibt True zurück, wenn das Ende der Assoziation navigierbar ist. Datei: Function_IsAssociationNavigable.ebs

Funktion IsInterface (theClass As Class) As VariantTask: Gibt True zurück, wenn die Klasse den Prototyp „Interface“ hat. Datei: Function_IsInterface.ebs

A.3.2 Konsistenzprüfung

Sub KP_CheckAttrPAttr (Classes As ClassCollection, Individual As Boolean, Abort As Boolean) Aufgabe: Prüfen, ob die Attribute und Pseudoattribute der Klasse eindeutig sind (Attribute-5). Datei: Sub_KP_CheckAttrPAttr.ebs

Sub KP_UniqueOpSignatures (Classes As ClassCollection, Individual As Boolean, Abort As Boolean) Aufgabe: Überprüfen Sie, ob die Operationssignatur der Klasse eindeutig ist (Operation-1). Datei: Sub_KP_UniqueOpSignatures.ebs

Sub KP_UniqueParaNames (Classes As ClassCollection, Individual As Boolean, Abort As Boolean) Aufgabe: Überprüfen Sie, ob die Namen der Klassenoperationsparameter eindeutig sind (Operation-2). Datei: Sub_KP_UniqueParaNames.ebs

Sub KP_CheckCompositionCardinality (Association As AssociationCollection, Einzel As Boolean, Abbruch As Boolean)

205 Anhang A. Implementierung der Benutzeroberfläche

Aufgabe: Überprüfen Sie, ob das Assoziationsende einer Markerkomposition eine maximale Kardinalität von 1 (Komposition-1) hat. Datei: Sub_KP_CheckCompositionCardinality.ebs

Sub KP_CheckGeneralization (Generalizations As InheritRelationCollection, Individual As Boolean, Abort As Boolean) Aufgabe: Prüfen Sie, ob die Generalisierungsbeziehung zwischen Klassifikatoren desselben Typs angegeben ist (Generalization-4). Datei: Sub_KP_CheckGeneral.ebs

Sub KP_InterfaceOperationsOnly (Classes As ClassCollection, Individual As Boolean, Auto As Boolean, Abort As Boolean) Aufgabe: Prüfen, ob eine Klasse mit Stereotyp «Interface» nur Eigenschaften als Attribute hat (Interface-1). Datei: Sub_KP_InterfaceOperationsOnly.ebs

Sub KP_InterfaceNoContents (Classes As ClassCollection, Individual As Boolean, Auto As Boolean, Abort As Boolean) Aufgabe: Überprüfen Sie, ob eine Klasse mit dem Stereotyp „Interface“ die Klasse (Interface-2) enthält. Datei: Sub_KP_InterfaceNoContents.ebs

Sub KP_InterfaceAssoziation (Classes As ClassCollection, Individual As Boolean, Auto As Boolean, Abort As Boolean) Aufgabe: Überprüfen Sie, ob die Klasse den Stereotyp „Interface“ mit entgegengesetztem navigierbarem Assoziationsende (Interface-7) hat. Datei: Sub_KP_InterfaceAssoziation. ebs

Sub KP_InterfaceHasOperation (Classes As ClassCollection, Individual As Boolean, Abort As Boolean) Aufgabe: Überprüfen Sie, ob die Klasse über den Stereotyp „Interface“ deklarierte Operation (Interface-5) verfügt. Datei: Sub_KP_InterfaceHasOperation.ebs

Sub KP_InterfaceHierarchie(Classes As ClassCollection, Individual As Boolean, Abort As Boolean) Aufgabe: Überprüfen Sie, ob eine Klasse mit dem Stereotyp „Interface“ eine eindeutige Operationssignatur in der Klassenhierarchie (Interface-6) hat. Datei: Sub_KP_InterfaceHierarchie.ebs

Sub KP_InterfacePublicOperations (Klassen wie ClassCollection,

A.3. Entwickelte Skripte 206

(Single As Boolean, Auto As Boolean, Abort As Boolean) Aufgabe: Überprüfen Sie, ob eine Klasse mit dem Stereotyp „Interface“ nur öffentliche abstrakte Operationssignaturen hat (Interface-3, Interface-4). Datei: Sub_KP_InterfacePublicOperations.ebs

Sub KP_InterfaceRealize (Classes As ClassCollection, Individual As Boolean, Abort As Boolean) Aufgabe: Prüfen, ob eine Klasse mit Prototyp „Interface“ etwas implementiert (Interface-12).

Sub KP_InterfaceStatemachine (Classes As ClassCollection, Individual As Boolean, Auto As Boolean, Abort As Boolean) Aufgabe: Überprüfen Sie, ob die Klasse über den Stereotyp „Interface“-Zustandsmaschine oder Zustandsdiagramm (Interface-10) verfügt. Datei: Sub_KP_InterfaceStatemachine.ebs

Sub KP_CheckTypeClassGeneralization (Generalizations AsInheritRelationCollection, Individual As Boolean, Abort As Boolean) Aufgabe: Prüfen, ob der Superclassifier eines Typs („type“) auch ein Typ (Type-1) ist. Datei: Sub_KP_CheckTypeClassGeneralization.ebs

Sub KP_AttributeDeclared(Classes As ClassCollection, Individual As Boolean, Abort As Boolean) Aufgabe: Prüft, ob eine Attributdeklaration einer Klasse einen Typ (Attribute-2) enthält. Datei: Sub_KP_AttributeDeclared.ebs

Sub KP_AttributeExTyp (Classes As ClassCollection, Individual As Boolean, Auto As Boolean, Abort As Boolean) Aufgabe: Überprüfen Sie, ob der Klassenattributtyp (Attribute-3) im Modell vorhanden ist. Datei: Sub_KP_AttributeExTyp.ebs

Sub KP_OpParaTypDeclared (Classes As ClassCollection, Individual As Boolean, Abort As Boolean) Aufgabe: Überprüfen Sie, ob der Typ des Klassenoperationsparameters deklariert ist. Datei: Sub_KP_OpParaTypDeclared.ebs

Sub KP_OpParaTypEx (Klassen wie ClassCollection,

207 Anhang A. Implementierung der Benutzeroberfläche

(Single As Boolean, Auto As Boolean, Abort As Boolean) Aufgabe: Überprüfen Sie, ob der Typ des Klassenoperationsparameters im Modell vorhanden ist (Operation-3). Datei: Sub_KP_OpParaTypEx.ebs

Sub KP_CheckAndSetClassAbstract(Classes As ClassCollection, Individual As Boolean, Auto As Boolean, Abort As Boolean) Aufgabe: Überprüfen Sie, ob eine Klasse eine abstrakte Operation hat und als abstrakt bezeichnet ist (Operation-4). Datei: Sub_KP_CheckAndSetClassAbstract.ebs

Sub KP_AssociationsNavigable(Associations As AssociationCollection,Single As Boolean, Cancel As Boolean) Aufgabe: Überprüfen Sie, ob die Assoziation in eine Richtung navigierbar ist (Assoziation-2). Datei: Sub_KP_AssociationsNavigable.ebs

Sub KP_NavRoleExName (Associations As AssociationCollection, Individual As Boolean, Abort As Boolean) Aufgabe: Prüft, ob das Ende einer navigierbaren Assoziation (Assoziation-3) benannt ist. Datei: Sub_KP_NavRoleExName.ebs

Sub KP_Konkrete KlassenUmAbstrakteOperationenExpand(Classes As ClassCollection, Individual As Boolean, Auto As Boolean, AbbruchAs Boolean) Aufgabe: Überprüfen Sie, ob eine Klasse die abstrakten Operationen ihrer Oberklasse implementiert (sie als nicht abstrakt deklarieren) (Operation 5). Datei: Sub_KP_Konkrete KlassenUmAbstrakteOperationenExpand.ebs

Sub KP_InterfaceAktiv (Classes As ClassCollection, Individual As Boolean, Auto As Boolean, Abort As Boolean) Aufgabe: Prüfen, ob eine Klasse mit dem Stereotyp «Interface» als aktiv (Interface-8) gekennzeichnet ist. Datei: Sub_KP_InterfaceAktiv.ebs

Sub KP_RealizeInterfaceOperations(Classes As ClassCollection, Individual As Boolean, Auto As Boolean, Abort As Boolean) Aufgabe: Prüft, ob eine Klasse alle Operationen ihrer Schnittstelle implementiert (deklariert) (Operation 13). Datei: Sub_KP_RealizeInterfaceOperations.ebs

A.4. Gerät 208

Sub KP_ExistsSignalClass (Classes As ClassCollection, Individual As Boolean, Auto As Boolean, Abort As Boolean) Aufgabe: Überprüfen Sie, ob die entsprechende Signalklasse (Signal-1) im Signaloperationsmodell vorhanden ist. Datei: Sub_KP_ExistsSignalClass.ebs

Sub KP_SignalStatemachine (Classes As ClassCollection, Individual As Boolean, Auto As Boolean, Abort As Boolean) Aufgabe: Prüft, ob eine Klasse mit einer Signaloperation über eine Zustandsmaschine verfügt, die den Signalempfang angibt (Signal-4). Datei: Sub_KP_SignalStatemachine.ebs

Sub KP_SignalActiveClass (Classes As ClassCollection, Individual As Boolean, Auto As Boolean, Abort As Boolean) Aufgabe: Prüft, ob eine Klasse mit einer Signaloperation als aktiv (Signal-5) gekennzeichnet ist. Datei: Sub_KP_SignalStatemachine.ebs

A.3.3 Auswahldialog

1. Archiv: KP_Klassendiagramm1.ebs

2. Datei: KP_Klassendiagramm2.ebs

A.4 Installation

Die Installation besteht aus drei Schritten:

1. Alle Skripte müssen in das Skriptpfadverzeichnis ($SCRIPT_PATH) kopiert werden.

2. Rose Anpassung der Menüdatei rose.mnu: Wenn der Auswahldialog über den Menüpunkt Bericht zugänglich ist, stehen sie hinter der Zeile

Menübericht {

Fügen Sie die folgenden Zeilen ein:

Option „Klassendiagramm1 prüfen“.

209 Anhang A. Implementierung der Benutzeroberfläche

{RoseScript $SCRIPT_PATH\KP_Class Diagram1

} Option „Klassendiagramm2 prüfen“

{RoseScript $SCRIPT_PATH\KP_Klassendiagramm2

}

Nach option.RoseScript kann eine beliebige Zeichenfolge (Menüelement) angegeben werden. . .Startet das angegebene Skript, wenn der Menüpunkt ausgewählt wird.

3. Rose muss möglicherweise neu gestartet werden.

Abbildung auf einen Blick

2.1 Klassen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2 Schnittstelle (Lollipop). . . . . . . . . . . . . . . . . . . . . . . . . . . .152.3-Schnittstelle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.4 Symbol für Zusammenarbeit . . . . . . . . . . . . . . . . . . . . . . . . . . 162.5 Anwendung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172,6 Aktive Klassen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.7 Montage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172,8 Wir. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182,9 Interaktion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.10 Zustände und Übergänge. . . . . . . . . . . . . . . . . . . . . . . . . 192.11 Paket. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .202.12 Achtung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.13 Abhängigkeiten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.14 Mitgliedschaft. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.15 Verallgemeinerung. 222,16 Leistungsverhältnis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.17 Anwendungsfalldiagramm. . . . . . . . . . . . . . . . . . . . . . . 242.18 Klassendiagramme. . . . . . . . . . . . . . . . . . . . . . . . . . . .252.19 Objektgraphen. . . . . . . . . . . . . . . . . . . . . . . . . . . .262.20 Zeitdiagramm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.21 Kollaborationsdiagramm. . . . . . . . . . . . . . . . . . . . . . . 272.22 Zustandsdiagramm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.23 Aktivitätsdiagramme. . . . . . . . . . . . . . . . . . . . . . . . . . . . 292,24 Garantie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34

3.1 Übersicht über Metamodellpakete. . . . . . . . . . . . . . . . . . . . . . . . . . . 363.2 UML Foundation Paket. . . . . . . . . . . . . . . . . . . . . . 373.3 Vererbungshierarchie. . . . . . . . . . . . . . . . . . . . . . . . . 393.4 Bindung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .423.5 Backbone-Netzwerk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443,6 Artikel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .453.7 Namespaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.8 Garantie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47

210

Kapitel 211

3.9 Generalisierbare Elemente und Klassifikatoren. . . . . . . . . . . . . . 483,10 Ressourcen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .503.11 Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .523.12 Klassifikator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .553.13 Assoziation und Kardinalität. . . . . . . . . . . . . . . . . . . . . . .583.14 Gezielte Assoziationen. . . . . . . . . . . . . . . . . . . . . . . . . . . 583.15 Spezifikation der Funktionalität durch Schnittstellen. . . . . . . . . . . . . . . . . 583.16 Eine Verbindung ordnungsgemäß beenden. . . . . . . . . . . . . . . . . . . . . . .593.17 Komposition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.18 Aggregation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .603.19 Qualifizierte Verbände. . . . . . . . . . . . . . . . . . . . . . . . . 603.20 Unqualifizierte Assoziationen. . . . . . . . . . . . . . . . . . . . . . . . . . 613.21 Förderfähige Verbände. . . . . . . . . . . . . . . . . . . . . . . .613.22 Assoziationsklassen. . . . . . . . . . . . . . . . . . . . . . . . . . .623.23 Beziehungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633.24 Ende der Assoziation. . . . . . . . . . . . . . . . . . . . . . . . . . . .633.25 Prozessbeziehungen. . . . . . . . . . . . . . . . . . . . . . . . . . .673.26 Abhängigkeiten. . . . . . . . . . . . . . . . . . . . . . . . . . . .683.27 Kommentare. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713.28 Verlängerungsmechanismus. . . . . . . . . . . . . . . . . . . . . 723.29 Datentyp(1) . . . . . . . . . . . . . . . . . . . . . . . . . .763.30 Datentyp(2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783.31 Ausdrücke. . ... . . . . . . . . . . . . . . . . .813.33 Signale, Ausnahmen und Empfang. . . . . . . . . . . . . . . . . . . . . . 833,34 Aktien. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853.35 Einreichen des Vorgangs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .873.36 Kopieren und verlinken. . . . . . . . . . . . . . . . . . . . . . . . . . . .883.37 Links und Anregungen. . . . . . . . . . . . . . . . . . . . . . . . . . . .913.38 Zeitdiagramm. . . . . . . . . . . . . . . . . . . . . . . . . . . . .933.39 Diagramm zur Zusammenarbeit auf Spezifikationsebene. . . . . . . . . . . . . . . . . . . . . 943.40 Kollaborationsdiagramm auf Beispielebene. . . . . . . . . . .943.41 Zeitdiagramm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 973.42 Zusammenarbeit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .983.43 Zustandsmaschine für Klimaanlagen. . . . . . . . . . . . . . . . . . . 1023.44 Ereignismetamodell. . . . . . . . . . . . . . . . . . . . . . . . .1033.45 Speicherstatus. . . . . . . . . . . . . . . . . . . . . . . . . . . .1073.46 Länder und gleichzeitige Regionen. . . . . . . . . . . . . . . . . . 1083.47 Zustandsmaschinen-Metamodell. . . . . . . . . . . . . . . . . . . 1093.48 Aktivitätsdiagramm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1143.49 Aktivitätsdiagramm (Metamodell). . . . . . . . . . . . . . . . . . . . . . . 1153.50 Objektstrom. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117

Abbildungsliste 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 Rose Spitzenreiter der Klassenhierarchie. . . . . . . . . . . . . . . . . 1354.7 Rose: Graph-Klasse. . . . . . . . . . . . . . . . . . . . . . . . 1364.8 Ross: Klassendiagramme. . . . . . . . . . . . . . . . . . . . . . . . . 1384.9 Ross: Interaktives Diagramm. . . . . . . . . . . . . . . . . . . . . . . 1394.10 Ross: Zustandsdiagramm. . . . . . . . . . . . . . . . . . . . . . . . 1414.11 Abstrakte Klassen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1424.12 Abstrakte Klassen (Metamodellinstanzen). 。 . ……………………………………………… .............................. .................... ..1444.15 Attribute (Metamodellinstanzen) .................... .............. .................................... ............1454.16 Attribut (Rose-Metamodell-Instanz. ............................ ................................................. ................................................. ................................................. 1484.18 Betrieb (Metamodell-Beispiel) ................................................ ................................................. ................................................. ................................. …………………………………………… …………………… 1514.22 Assoziationen (Rose-Metamodell-Instanz) ……………………… …………1524.23 Zusammensetzung…………………………………………………… ………………………………………………………………………………………………………………………………… ………………………………………………………………………………………………………………………………… ………………………………………………………………………………………………………………………………… ………1544.24 . . . . . . . . . . . . 1554.25 Verallgemeinerung. . . . . . . . . . . . . . . . . . . . . . . . . 1554.26 Generalisierung (Metamodell-Instanz). . . . . . . . . . . . . . . . . 1564.27 Generalisierung (Rose-Metamodell-Instanz). . . . . . . . . . . . . . . 1564.28 Schnittstelle. . . . . . . . . . . . . . . . . . : . . . . . . . . 1574.30-Schnittstelle (Rose-Metamodell-Instanz). . . . . . . . . . . . . . . . . . . 1584.31-Implementierung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1594.32 Implementierung (Metamodellinstanz). . . . . . . . . . . . . . . . . . 1604.33-Implementierung (Rose-Metamodell). . . . . . . . . . . . . . . . . . . . . . 1604.34-Signal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1624.35 Spezifikation der Funktionalität durch Schnittstellen. . . . . . . . . . . . . . . .1644.36 Typ. . . . . . . . . . . . . . . . . . 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1664.38 „Objektfunktionen.“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1664.39 Die Rolle von Klassifikatoren (Metamodellinstanz 1). . . . . . . . . . . . . . . .1664.40 Klassifikatorfunktionen (Metamodellinstanz 2). . . . . . . . . . . . . . . . .1674.41 Zugehörige Funktionen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1684.42 Verwendung von Typen als Klassifikatorfunktionen. . . . . . . . . . . . . .168

Kapitel 213

4.43 Verwenden Sie Typen als Funktionen von Objekten. . . . . . . . . . . . . . . 1684.44 Assoziations- und Klassifikatorfunktionalität (Metamodellinstanz). . . . . .1694.45 Objekte, Links und Nachrichten in Rose (Meta). . . . . . . . . . . . . . 1714.46 Botschaften und Anregungen. . . . . . . . . . . . . . . . . . . . . . . . 1724.47 Nachrichten in einem Kollaborationsdiagramm. . . . . . . . . . . . . . . . . . . . 1744.48 Programmkontrollfluss. . . . . . . . . . . . . . . . . . . . . . . . 1764.49 Reihenfolge der Botschaften/Reize. . . . . . . . . . . . . . . . . . 1764.50 Iteration des Kollaborationsdiagramms. . . . . . . . . . . . . . . . . . . 1774.51 Sequenzdiagramm-Interaktion. . . . . . . . . . . . . . . . . . . . . 1784.52 Sequenzdiagramm-Iteration (außerhalb von UML). . . . . . . . . .1794.53 Ereignisse im Metamodell. . . . . . . . . . . . . . . . . . . . . . . . 1804.54 Ereignisklassen für das Rose-Metamodell. . . . . . . . . . . . . . . . . 1814.55 Übergang. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1834.56 Übergang (Metamodellinstanz). . . . . . . . . . . . . . . . . . . . 1834.57 Übergang (Rosenmetamodell). . . . . . . . . . . . . . . . . . . . . . . 1844.58 Bedingungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1854.59 Zustand (Metamodellinstanz). . . . . . . . . . . . . . . . . . . . . . 1864.60 Rekursive Struktur von Zustandsmaschinen. . . . . . . . . . . . . . .1874.61 Zustandsmaschine (Beispiel). . . . . . . . . . . . . . . . . . . . . . . 1874.62 Gleichzeitiger kombinierter Zustand. . . . . . . . . . . . . . . . . . . . 1894.63 Pseudonationale Teilung und Vereinigung. . . . . . . . . . . . . . . . . . . . 1904.64 Synchronisierungsstatus. . . . . . . . . . . . . . . . . . . . . . . 1914.65 Stump State. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1924.66 Pseudoland hinzugefügt. . . . . . . . . . . . . . . . . . . . . . . . . 1934.67 Pseudozustand auswählen. . . . . . . . . . . . . . . . . . . . . . . . . . 1934.68 Aufruf der eingebauten Zustandsmaschine. . . . . . . . . . . . . .194

5.1 Auswahldialog: Konsistenzprüfung. . . . . . . . . . . . . . . . . 1995.2 Inkonsistenter Dialog. . . . . . . . . . . . . . . . . . . . . . . . . .200

Index

Depend, 67abstraction, 68access, 70use, 69derive, 68friend, 70import, 70realize, 68refine, 68trace, 68

Abhängigkeit, 20 Erlaubnis, 70

Zusammenfassung, 67addOnly, 51action, 84, 105

create-, 86uninterpreted, 87return-action, 86send-, 87finish-, 86destroy-, 86assign-, 86

Aktionssequenz, 86 Aktionsstatus, 116 Aktivitätsdiagramm, 81 Aktivität, 105 Aktivitätsdiagramm, 26 Änderungsereignis, 104 Notiz, 20 Anwendungsfall, 16 Anwendungsfalldiagramm, 23 Anwendungsfallansicht, 31, 130 Assoziation, 91 Assoziation, 57, 62

Assoziationsende, 57, 63 Assoziationsklasse, 62, 65 Attribut, 51 Aufruf

Aktion, 86 Aufrufereignis, 103 Aufrufstatus, 117 Ausnahme, 83 Automat, 19

Basisklasse, 38 Verwendung, 67 Beziehung, 20 Bindung, 67 Nachricht, 82

Variable, 51child, 38classifier, 51Coderzeugung, 120complete, 66concurrency, 53concurrent, 53

Datentyp, 56AggregationKind, 76Enumeration, 76Boolean, 76CallConcurrencyKind, 76ChangeableKind, 76Integer, 75MessageDirectionKind, 76OperationDirectionKind, 76OrderingKind, 76ParameterDirectionKind, 76

214

215 Inhalt

Primitive, 75Sprachtyp, 77PseudostatusKind, 76String, 75Struktur, 76Zeit, 75UnlimitedInteger, 75VisibilityKind, 76

Wertigkeit, 89zerstört, 91Diagramme, 23direkte Superklasse, 38direkte Instanz, 38disjunkt, 66

Beispiel: 38Diskriminator, 38, 66

Attributwert, 34, 72Bereitstellungsdiagramm, 30Bereitstellungsansicht, 32, 130Element, 43

Modell, 45 Einführung, 45 verallgemeinerbar, 47

Empfang, 83design-Vorschau, 31event, 103

Verzögerung, 106 Ereignisauslöser, 105 Speicherstatus

Plan, 106Genehmigung, 67Erweiterung, 38, 40Erweiterungsmechanismus, 71Kopie, 87

Direkt, 38 Indirekt, 40

Fachwörterbuch, 120 Frozen, 51

Verallgemeinerung, 21, 38, 66global, 91

Erhaltung, 53

Implementationssicht, 31in, 54incomplete, 66indirectktes Exemplar, 40Inkonsistenzvermeidung, 125inout, 54instance, 51Instantiierung, 41Interaktion, 18Interaktionsdiagramm, 23Interface, 15, 43, 56Interoperabilität, 121

Kardinalität, 79Kind, 38Klasse, 15, 38, 42, 55

Abstract, 40active, 17concrete, 40superior, 38sub, 38super, 38inferior, 38

Klassendiagramm, 23Klassifikator, 48Knoten, 18, 56Knoteninstanz, 89Zusammenarbeit, 16, 99Zusammenarbeitsdiagramm, 25, 80Kommentar, 20Komponente, 17, 56Komponentendiagramm, 30Komponenteninstanz, 89Komponentenansicht, 31, 130Konsistenz

Definition, 124 Fragen, 124

Konsistenzprüfung, 120, 127 Konsistenzunterstützung, 127

Link, 90

Index 216

Link-Ende, 90Link-Objekt, 90Local, 91LogicalView, 31, 130

Mehrbenutzerunterstützung, 120 Funktionen, 49

Ersatz, 40 Strukturell, 51 Verhalten, 52

Methoden, 43, 54 Multiplizität, 51

Nachbedingungen, 43descendant, 38 Namespaces, 46

virtuell, 45neu, 91note, 20

Superklasse, 38Objekt, 89Objektdiagramm, 23Objektflussstatus, 117Operation, 53Operationsaufruf, 82Ausgabe, 54Overlay, 66

Paket, 19Paketdiagramm, 137Parameter, 54parameter, 91parent, 38persistence, 49Polymorphismus, 40Prozessicht, 31Pseudoattribut, 45, 49Pseudozustand, 111

Berechtigungserklärung, 60

Leistung, 22 Leistung Vision, 31

Rückkehr, 54 Reverse Engineering, 120

self, 91sequential, 53Sequenzdiagramm, 23, 80Sichtbarkeit

Attribut, 42signal, 82signal-Ereignis, 103signatur, 40

Definition, 52Spezialisierung, 38Statechart, 25statetchart, 101StateVertex, 110Stereotyp, 33, 71

access, 70become, 66call, 70copy, 66create, 53, 70, 103derive, 68destroy, 53, 103document, 57executable, 57file, 57friend, 70implementation, 66implementationClass, 55implicit, 62import, 70instantiate, 70invariant, 47 Bibliothek, 57 Metaklassen, 49 nach Vorbedingung , 47powertyp, 49 Vorbedingung, 47 Prozess, 49 Realisierung, 68 Verfeinerung, 68

217 Inhalt

Anfrage, 71 Pflicht, 71 Senden, 70 Signal, 82 Tabelle, 57 Thread, 49 Trace, 68 Typ, 55 Dienstprogramm, 49

Reiz, 82, 90Unterklasse, 38Substitutionsprinzip, 40Superklasse, 38Synchronisationszustand, 112

targetScope, 51transient, 91Transition, 105

Intern, 105Trigger, 105Typ, 54

Attribut-, 42

Unterklasse, 38 Unterstaat, 110

Vererbung, 21, 38 Verteilung, 30 Verteilung, 32 Voraussetzungen, 43 Vorfahren, 38

Wachterbedingung, 105Werkzeug

Annahme, 125 Wiederverwendung, 121

Zeitereignisse, 104 Garantia, 47, 72, 74

addOnly，63frozen，63xor，62

Garantie, 34

bedingt, 105 subautomatisch, 113

Zustandsmaschine, 19, 101, 105 Zustandsdiagramm, 25, 80, 101 Zustandsnummer, 110

Literaturverzeichnis

[Alh98] Sinans Alsheer. Kurz gesagt, UML. Kurze Desktop-Referenz. O'Reilly Press, 1998.

[Bal92] Helmut Balzert Die Entwicklung von Softwaresystemen: Prinzipien, Methoden, Sprachen, Werkzeuge. Computerserie. BI Wissenschaftsverlag, Mannheim; Leipzig; Wien, Zürich, 1992. Das Buchprojekt des Bibliographischen Instituts wurde von der Spektrum Akademischer Verlag GmbH in Heidelberg, Berlin und Oxford übernommen.

[Bal96] Helmut Balzeit. Lehrbuch für Softwaretechnik: Lehrbuch für Softwareentwicklung und Informatik. Spektrum Akademischer Verlag, Heidelberg, Berlin, 1996.

[Bal98] Helmut Balzeit. Lehrbücher zur Softwaretechnik: Softwaremanagement, Softwarequalitätssicherung, Unternehmensmodellierung. Computerlehrbücher. Spectrum Academic Publishers, Heidelberg, Berlin, 1998.

[BRJ99a] Grady Booch, James Rumbaugh und Ivar Jacobson. Ein Benutzerhandbuch zu UML. Professionelle Softwareentwicklung. Addison Wesley, 1999.

[BRJ99b] Grady Booch, James Rumbaugh und Ivar Jacobson. Benutzerhandbuch zur Unified Modeling Language. Objekttechnologie-Reihe. Addison Wesley, 1999.

[Cet] Cetu kam heraus. Architektur und Design: Unified Modeling Language (UML). http://www.rhein-neckar.de/~cetus/oo_uml.html. Eine Sammlung von Links im Internet zum Thema UML.

[EP98] Hans-Erik Eriksson und Magnus Penker. UML-Toolkit. John Wiley & Sons, 1998.

[FS98] Martin Fowler und Kendal Scott. UML-Konzentration. Addison-Wesley Press, 1998.

[HW98] Paul Harmon und Mark Watson.Understanding UML: The Developers Guide.Morgan Kaufmann Publishers, Inc., San Francisco, Kalifornien, 1998.

218

219 Referenzen

[Oes98] Bernd Austria. Objektorientierte Softwareentwicklung. Verwenden Sie Unified Modeling Language.R für Analyse und Design. Oldenburg Press, 4. Auflage, 1998.

[OMG99] OMG (Objektverwaltungsgruppe). OMG Unified Modeling Language Specification (Entwurf). http://www.omg.org, April 1999. Version 1.3 Beta R1.

[Qua98] Triquatrani. Visualisierung mit Rational Rose und UML. Objekttechnologie-Reihe. Addison Wesley, 1998.

[R+93] Objektorientierte Modellierung und Design von James Rumbaugh und anderen. Hänsel, 1993.

[Rat98] Rational Software Cooperation, Herausgeber. Rational Rose 98. Referenzhandbuch zur Erweiterbarkeit. Februar 1998. Softwareversion 1.0.

[Sch91] Heinrich Schmidts Wörterbuch der Philosophie. Alfred Kröner Verlag, Stuttgart, 22. Auflage, 1991.

[Sch95] Jochen Schwarze. Desenvolvimento do sistema. Verlag Neue Wirtschaftsbriefe, Herne/柏林, 1995.

Konformität und Werkzeugunterstützung für ... 3.2.3.2 Zustandsmaschinen ... 4.1 Anforderungen an UML-Werkzeuge ... Systeme zeichnen sich durch Struktur und Verhalten aus und - [PDF-Dokument] (2023)