ARIS UML Designer-Einführung - claudiubrandas.ro UML Designer... · ARIS UML Designer-Einführung...

ARIS UML Designer

ARIS UML Designer-Einführung

Januar 2016

Version 9.8


Dieses Dokument gilt für ARIS ab Version 9.8. Hierin enthaltene Beschreibungen unterliegen Änderungen und Ergänzungen, die in nachfolgenden Release Notes oder Neuausgaben bekanntgegeben werden. Urheberrechtlich geschützt © 2010 - 2016 Software AG, Darmstadt, Deutschland und/oder Software AG USA Inc., Reston VA, USA und/oder ihre Tochtergesellschaften und/oder ihre Lizenzgeber. Der Name Software AG und die Namen der Software AG Produkte sind Marken der Software AG und/oder Software AG USA Inc., einer ihrer Tochtergesellschaften oder ihrer Lizenzgeber. Namen anderer Gesellschaften oder Produkte können Marken ihrer jeweiligen Schutzrechtsinhaber sein. Genaue Informationen über die geschützten Marken und Patente der Software AG und ihrer Tochtergesellschaften sind veröffentlicht unter http://softwareag.com/licenses. Die Nutzung dieser Software unterliegt den Lizenzbedingungen der Software AG. Diese Bedingungen sind Bestandteil der Produktdokumentation und befinden sich unter http://softwareag.com/licenses und/oder im Wurzelverzeichnis des lizenzierten Produkts. Diese Software kann Teile von Software-Produkten Dritter enthalten. Urheberrechtshinweise, Lizenzbestimmungen sowie zusätzliche Rechte und Einschränkungen dieser Drittprodukte können dem Abschnitt „License Texts, Copyright Notices and Disclaimers of Third Party Products“ entnommen werden. Diese Dokumente enthalten den von den betreffenden Lizenzgebern oder den Lizenzen wörtlich vorgegebenen Wortlaut und werden daher in der jeweiligen Ursprungsprache wiedergegeben. Für einzelne, spezifische Lizenzbeschränkungen von Drittprodukten siehe PART E der Legal Notices, abrufbar unter dem Abschnitt „License Terms and Conditions for Use of Software AG Products / Copyrights and Trademark Notices of Software AG Products“. Diese Dokumente sind Teil der Produktdokumentation, die unter http://softwareag.com/licenses oder im Verzeichnis der lizenzierten Produkte zu finden ist.


I

Inhalt 1 Einleitung ............................................................................................................. 1

2 UML Grundlagen ................................................................................................... 2 2.1 Was ist UML? .............................................................................................. 2 2.2 UML-Diagrammtypen ................................................................................... 3

2.2.1 Klassendiagramm (Class Diagram) ...................................................... 4 2.2.2 Komponentendiagramm (Component Diagram)..................................... 6 2.2.3 Kompositionsstrukturdiagramm (Composite Structure Diagram) ............. 7 2.2.4 Objektdiagramm (Object Diagram) ...................................................... 8 2.2.5 Paketdiagramm (Package Diagram) ..................................................... 9 2.2.6 Profildiagramm (Profile Diagram) ...................................................... 10 2.2.7 Verteilungsdiagramm (Deployment Diagram) ..................................... 11 2.2.8 Aktivitätsdiagramm (Activity Diagram) .............................................. 12 2.2.9 Anwendungsfalldiagramm (Use Case Diagram) ................................... 14 2.2.10 Kommunikationsdiagramm (Communication Diagram) ......................... 16 2.2.11 Sequenzdiagramm (Sequence Diagram) ............................................ 18 2.2.12 Zeitablauf-Diagramm (Timing Diagram) ............................................. 19 2.2.13 Interaktionsübersichtsdiagramm (Interaction Overview Diagram) ......... 20 2.2.14 Zustandsautomatendiagramm (State Machine Diagram) ...................... 21 2.2.15 Protokoll-Zustandsautomaten-Diagramm (Protocol State Machine

Diagram) ....................................................................................... 23 2.3 Besonderheiten in ARIS UML Designer .......................................................... 25

2.3.1 Diagramminhalte ............................................................................ 25 2.3.2 Namen von UML-Elementen .............................................................. 26 2.3.3 Mehrsprachigkeit ............................................................................. 26

2.4 Das UML Metamodell .................................................................................. 26 2.4.1 Common Structure .......................................................................... 27 2.4.2 Values ........................................................................................... 32 2.4.3 Classification .................................................................................. 34 2.4.4 Structured Classifiers ....................................................................... 38 2.4.5 Simple Classifiers ............................................................................ 41

3 Übersicht ARIS UML Designer ............................................................................... 42 3.1 Festlegen des Tätigkeitsbereiches ................................................................ 42 3.2 Explorer ................................................................................................... 45

3.2.1 Leiste Navigation ............................................................................ 47 3.2.2 Eigenschaftsseiten ........................................................................... 49 3.2.3 Eigenschaftsdialog ........................................................................... 60 3.2.4 Anlegen neuer Elemente im Explorer ................................................. 61 3.2.5 Erzeugen neuer Diagramme im Explorer ............................................ 66

3.3 Designer ................................................................................................... 67 3.3.1 Leiste Navigation ............................................................................ 69 3.3.2 Leiste Eigenschaften ........................................................................ 71 3.3.3 Leiste Symbole ............................................................................... 72 3.3.4 Leiste Implizite Änderungen ............................................................. 78 3.3.5 Modellierung ................................................................................... 80

3.4 Optionen ................................................................................................. 101 3.4.1 Allgemeines ................................................................................... 102 3.4.2 UML - Allgemein ............................................................................. 103 3.4.3 UML - Designer-Allgemein ............................................................... 105


II

3.4.4 UML - Explorer ............................................................................... 106 3.4.5 UML - Für neue Diagramme ............................................................. 106 3.4.6 UML - Darstellungsoptionen ............................................................. 107 3.4.7 UML – Eigenschaftsregisterkarten ..................................................... 109

3.5 Registerkarte Administration ...................................................................... 110 3.5.1 Methodenfilter ............................................................................... 112 3.5.2 Link-Typen .................................................................................... 114 3.5.3 XMI-Ressourcen ............................................................................. 115 3.5.4 Datenübernahmen aus ARIS UML Designer 7.x .................................. 116

4 Abbildung von UML auf das ARIS-Objektmodell ...................................................... 117 4.1 Gruppen- und Objekteigenschaften von UML-Elementen ................................ 117 4.2 Komplexität von Kantenpräsentationen ....................................................... 119 4.3 Die wichtigsten Abbildungen von UML nach ARIS .......................................... 121

5 Verknüpfung von Geschäftsprozess- mit UML-Modellierung ...................................... 122 5.1 Hinterlegung von Geschäftsprozess-Objekten mit UML-Diagrammen ............... 122

5.1.1 Hinterlegung in ARIS UML Designer erstellen ..................................... 123 5.1.2 Hinterlegung in ARIS Architect und ARIS Designer erstellen ................ 125

5.2 Wiederverwendung von Geschäftsprozess-Objekten als UML-Elemente ............ 129 5.2.1 Festlegung der Abbildung von ARIS- auf UML-Typen ........................... 129 5.2.2 Wiederverwendung eines ARIS-Objekts in einem UML-Diagramm ......... 133 5.2.3 Verwaltung der Objekt-Link-Definitionen ........................................... 137

5.3 Navigation zwischen ARIS Architect/ARIS Designer und ARIS UML Designer ..... 138 5.3.1 Navigation von ARIS Architect/ARIS Designer nach ARIS UML Designer

................................................................................................... 138 5.3.2 Navigation von ARIS UML Designer nach ARIS Architect/ARIS Designer

................................................................................................... 140

6 UML Profile ........................................................................................................ 143 6.1 Vordefinierte Profile in ARIS UML Designer ................................................... 143 6.2 Verwendung von Profilen ........................................................................... 144

6.2.1 Zuordnung von Profilen zu einem Paket ............................................ 144 6.2.2 Zuordnung von Stereotypen zu einem UML-Element ........................... 146 6.2.3 Stereotypen in der Leiste Symbole von Diagrammen .......................... 148

6.3 Benutzerdefinierte UML-Profile ................................................................... 150 6.3.1 Der UML-Metamodellgenerator ......................................................... 150 6.3.2 Erstellung eines Profils .................................................................... 154 6.3.3 Erstellung eines Stereotyps ............................................................. 156 6.3.4 Definition neuer Eigenschaften ......................................................... 159 6.3.5 ARIS-spezifische Merkmale benutzerdefinierter Eigenschaften ............. 164 6.3.6 Vererbungsbeziehungen zwischen Stereotypen .................................. 168 6.3.7 Erstellung eines Filter-Profils ........................................................... 170 6.3.8 Erstellung eines Diagrammstereotyps ............................................... 172


III

7 Unterschiede zu ARIS Architect und ARIS Designer ................................................ 176 7.1 Relevanz des Modells und seiner Diagramme im Hinblick auf die Semantik ...... 176 7.2 Die Funktionen Speichern und Rückgängig/Wiederherstellen .......................... 176 7.3 Öffnen von Diagrammen ............................................................................ 177 7.4 Elementhierarchien ................................................................................... 177 7.5 Grafische Kanten in Diagrammen ................................................................ 177 7.6 Hinterlegungen ......................................................................................... 177 7.7 Erstellung von ARIS-Skripten ..................................................................... 178

8 Unterschiede zu ARIS UML Designer 7.x ................................................................ 179 8.1 UML-Version ............................................................................................ 179 8.2 Abbildung von UML auf ARIS ...................................................................... 179 8.3 Wiederverwendung von Geschäftsprozessobjekten in UML ............................. 179 8.4 Speichern und Rückgängig machen von Änderungen ..................................... 180 8.5 Integration von UML in den Explorer-Baum .................................................. 180 8.6 Eigenes Fenster für ARIS UML Designer ....................................................... 180 8.7 XMI-Schnittstelle ...................................................................................... 180

9 Anhang ............................................................................................................. 181 9.1 UML-Fachbegriffe in Deutsch und Englisch ................................................... 181

9.1.1 Diagramme ................................................................................... 181 9.1.2 Elemente ...................................................................................... 182

9.2 Glossar .................................................................................................... 183 9.3 Weitere Dokumente und Referenzen ........................................................... 184

9.3.1 Dokumente ................................................................................... 184 9.3.2 Referenzen .................................................................................... 184


1

1 Einleitung

Dieses Dokument gibt Ihnen einen Überblick über die wesentlichen Funktionalitäten von ARIS UML Designer 9 und stellt die dahinterliegenden Konzepte vor. Es wendet sich an alle UML-Modellierer, an Entwickler UML-spezifischer Reporte und Makros und an ARIS-Administratoren. Falls Sie mit ARIS noch nicht vertraut sind, sollten Sie zunächst das Dokument Schnelleinstieg ARIS Architect lesen, da zum Verständnis dieser Einführung einige Grundkenntnisse in ARIS erforderlich sind. Diese Einführung gliedert sich in folgende Kapitel: UML Grundlagen: Beinhaltet eine kurze Einführung zu UML und stellt die von ARIS UML Designer unterstützen Diagrammtypen vor. Darüber hinaus vermittelt Ihnen das Kapitel die Grundlagen des UML-Metamodells und schafft so die notwendigen Voraussetzungen für das Verständnis der nachfolgenden Themen Abbildung von UML auf das ARIS Objektmodell und UML Profile. Übersicht ARIS UML Designer: Stellt die wichtigsten Komponenten von ARIS UML Designer und ihre Funktionalitäten vor. Abbildung von UML auf das ARIS-Objektmodell: Zeigt, wie UML-Inhalte in ARIS abgelegt sind, sodass Sie verstehen können, wie sich ARIS-Standardfunktionalitäten wie Definitionskopie, Merge oder Zugriffsrechte auf UML-Inhalte auswirken. Verknüpfung von Geschäftsprozess- mit UML-Modellierung: Vermittelt Ihnen die entsprechenden technischen Grundlagen. UML Profile: Gibt Ihnen einen Überblick über die Erweiterungs- und Filtermechanismen von UML, die sich grundsätzlich von der klassischen ARIS-Methodenkonfiguration unterscheiden. Unterschiede zu ARIS Architect und ARIS Designer: Zeigt die Besonderheiten von ARIS UML Designer und die sich daraus ergebenden Unterschiede zur klassischen ARIS-Modellierung. Unterschiede zu ARIS UML Designer 7.x: Geht auf die Neuerungen von ARIS UML Designer 9 im Vergleich zur Vorgängerversion 7.x ein. Auch wenn die offizielle UML-Spezifikation nur in Englisch verfügbar ist, werden in diesem Dokument häufig deutsche UML-Fachbegriffe verwendet, insbesondere wenn es zum englischen Originalbegriff eine ähnlich lautende deutsche Übersetzung gibt oder die Verwendung des deutschen Fachbegriffs unter deutschsprachigen UML-Anwendern und Softwareentwicklern allgemein üblich ist. Beispiele für solche Fachbegriffe sind Class (deutsch: Klasse), Package (deutsch: Paket), Component (deutsch: Komponente) oder auch StateMachine (deutsch: Zustandsautomat). Solche Begriffe können in diesem Dokument beispielsweise als UML-Element vom Typ Class oder alternativ auch als UML-Klasse oder Klasse vorkommen. Ebenso werden für die verschiedenen Diagrammtypen in diesem Dokument die deutschen Namen verwendet, die auch in der deutschsprachigen UML-Literatur üblich sind. Im Anhang sind alle in diesem Dokument verwendeten deutschen UML-Fachbegriffe zusammen mit dem jeweiligen englischen Originalbegriff aufgeführt. Da die von ARIS bekannten Begriffe Modell und Objekt in UML eine andere Bedeutung haben, werden in diesem Dokument an ihrer Stelle die Begriffe Diagramm und Element verwendet. Somit ist eine EPK in diesem Dokument kein Modell, sondern ein Diagramm und eine EPK-Funktion kein Objekt, sondern ein Element. ARIS UML Designer 9 unterstützt die UML-Version 2.5. ARIS Architect und ARIS Designer unterstützen aus Kompatibilitätsgründen noch die alte UML-Version 1.4. Dies erfolgt allerdings nicht in UML-spezifischer Notation, sondern in Form klassischer ARIS-Diagramme. Wenn in diesem Dokument der Begriff UML ohne Versionsnummer verwendet wird, bezieht er sich stets auf die von ARIS UML Designer unterstütze Version 2.5.


2

2 UML Grundlagen

Dieses Kapitel beinhaltet eine kurze Einführung zu UML und dem zugrunde liegenden Metamodell, soweit dies für das Verständnis der restlichen Kapitel dieses Dokuments und ein erstes Arbeiten mit ARIS UML Designer notwendig ist. Für ausführliche Informationen zu UML und den einzelnen UML-Element und -Diagrammtypen sei auf die UML-Spezifikation selbst und entsprechende Sekundärliteratur verwiesen. Darüber hinaus sind Grundkenntnisse in objektorientierten Prinzipien für das Verständnis von UML sehr hilfreich.

2.1 Was ist UML?

UML steht für Unified Modeling Language und ist eine Modellierungssprache für objektorientierte (Software-) Systeme. Das Wort Software steht hier in Klammern, da der Entwurf und die Beschreibung von Softwaresystemen bei der Entwicklung der UML sicherlich im Vordergrund standen, sich UML aber prinzipiell zur Modellierung beliebiger Systeme unter objekt-orientierten Gesichtspunkten eignet. Ein Beispiel wäre die Beschreibung der IT-relevanten Aspekte einer Geschäftsdomäne im Rahmen einer objekt-orientierten Analyse, um daraus Anforderungen für ein entsprechendes Softwaresystem abzuleiten. UML wurde Mitte der neunziger Jahre von Grady Booch, Ivar Jacobson und James Rumbaugh als gemeinsame Weiterentwicklung ihrer eigenen objekt-orientierten Methoden (Booch-Methode, OOSE und OMT) vorgestellt. Seit 1997 wird UML von der OMG als Standard veröffentlicht und kontinuierlich weiter entwickelt. Die OMG (Object Management Group) ist eine Non-Profit-Organisation, die eine Reihe wichtiger Standards in der IT-Industrie verantwortet. Neben UML ist dies beispielsweise BPMN. Die aktuelle UML-Version zum Zeitpunkt der Erstellung dieses Dokuments ist 2.5. Diese wird auch von ARIS UML Designer 9 unterstützt. Die entsprechende UML-Spezifikation finden Sie bei der OMG unter folgender Adresse: http://www.omg.org/spec/UML/.

http://www.omg.org/spec/UML/


3

2.2 UML-Diagrammtypen

UML unterscheidet zwei Kategorien von Diagrammen: Strukturdiagramme und Verhaltensdiagramme. Bei Strukturdiagrammen stehen statische Strukturen im Vordergrund. Ein Beispiel hierfür ist das Komponentendiagramm, in welchem modelliert wird, wie einzelne (Software-) Komponenten zueinander in Beziehung stehen. Im Gegensatz dazu stehen die Verhaltensdiagramme, welche das dynamische Verhalten eines Systems in den Vordergrund stellen. Ein Beispiel für ein Verhaltensdiagramm ist das Zustandsautomatendiagramm, das zeigt, wie die Instanz einer Klasse beim Eintreten bestimmter Ereignisse ihren internen Zustand ändert. Typisch für Strukturdiagramme ist, dass sie einen beliebigen Ausschnitt einer UML-Struktur zeigen. Sie stellen eine Sicht auf eine frei definierbare Teilmenge dieser Struktur dar. Im Gegensatz dazu beschreiben Verhaltensdiagramme (bis auf das Anwendungsfalldiagramm) das dynamisch Verhalten eines bestimmten Elements, i. d. R. eines Zustandsautomaten, einer Aktivität oder einer Interaktion. UML definiert folgende Diagrammtypen:

Strukturdiagramme Verhaltensdiagramme Klassendiagramm (Class Diagram)

Aktivitätsdiagramm (Activity Diagram)

Komponentendiagramm (Component Diagram)

Anwendungsfalldiagramm (Use Case Diagram)

Kompositionsstrukturdiagramm (Composite Structure Diagram)

Kommunikationsdiagramm (Communication Diagram)

Objektdiagramm (Object Diagram)

Interaktionsübersichtsdiagramm (Interaction Overview Diagram)

Paketdiagramm (Package Diagram)

Protokoll-Zustandsautomaten-Diagramm (Protocol State Machine Diagram)

Profildiagramm (Profile Diagram)

Sequenzdiagramm (Sequence Diagram)

Verteilungsdiagramm (Deployment Diagram)

Zeitablauf-Diagramm (Timing Diagram)

Zustandsautomatendiagramm (State Machine Diagram)

Im Folgenden werden die einzelnen Diagrammtypen anhand einfacher Beispiele rund um das Thema Auftragsbearbeitung kurz vorgestellt. Diese Beispiele erheben keinerlei Anspruch auf Vollständigkeit oder fachliche Korrektheit. Sie sollen lediglich verdeutlichen, wie bestimmte Sachverhalte des Themas mit Hilfe der verschiedenen UML-Diagrammtypen dargestellt werden können.


4

2.2.1 Klassendiagramm (Class Diagram)

Klassendiagramme zeigen hauptsächlich Beziehungen zwischen Klassen und deren Eigenschaften.

Abbildung 1: Klassendiagramm

Abbildung 1 zeigt ein einfaches Klassendiagramm mit den vier Klassen (UML-Typ Class) Auftrag, Großkundenauftrag, Auftragsposition und Artikel, den beiden einfachen Datentypen (UML-Typ PrimitiveType) String und Integer und einem Kommentar (UML-Typ Comment). Die Klassen enthalten jeweils ein bis zwei Attribute (UML-Typ Property). Die Klasse Auftrag enthält z. B. das Attribut Auftragsnummer, welches vom Typ Integer ist. Das bedeutet, die Auftragsnummer ist eine Eigenschaft, deren Wert eine ganze Zahl darstellt. UML selbst macht keinerlei Vorgaben, welche Datentypen beim Modellieren verwendet werden sollen und wie diese zu bezeichnen sind1. In dem Beispiel oben könnten die beiden Typen String und Integer auch Zeichenfolge und Ganzzahl heißen.

Abbildung 2: Assoziation zwischen zwei Klassen

Die Klassen Auftrag und Auftragsposition sind durch eine Assoziation miteinander verknüpft. Diese Assoziation hat ein Assoziationsende auftrag mit der Multiplizität 1 und ein Assoziationsende position mit der Multiplizität 1..*. Die Multiplizität 1..* am Assoziationsende position besagt, dass einem Auftrag mindestens eine bis zu beliebig vielen Auftragspositionen zugeordnet sind. Die Eigenschaft {ordered} gibt an, dass die Auftragspositionen dem Auftrag in einer eine bestimmte Reihenfolge zugeordnet sind. Die Multiplizität 1 am Assoziationsende auftrag besagt, dass eine Auftragsposition immer genau einem Auftrag zugeordnet ist. Die ausgefüllte schwarze Raute an der Assoziation kennzeichnet, dass die Auftragspositionen Bestandteil des Auftrags sind und beim Löschen eines Auftrags auch seine Auftragspositionen automatisch mit gelöscht werden. Die beiden schwarzen Punkte am Ende der Assoziationskante besagen, dass die entsprechenden Assoziationsenden gleichzeitig auch Attribute der jeweils gegenüberliegenden Klasse sind. Abbildung 3 zeigt daher eine semantisch gleichwertige, alternative Darstellung zu Abbildung 22.

1 Eine Ausnahme stellt in ARIS UML Designer die Modellierung von Profilen dar, bei der für einfache Datentypen die entsprechenden, von der UML spezifizierten Typen verwendet werden müssen.


5

Abbildung 3: Assoziationsenden als Attribute

Eine Pfeilspitze an einem Assoziationsende besagt, dass die Assoziation in Pfeilrichtung navigierbar ist. Abbildung 4 zeigt eine Assoziation, die nur in eine Richtung navigierbar ist.

Abbildung 4: Unidirektionale Assoziation

In diesem Beispiel weiß die Auftragsposition, auf welchen Artikel sie sich bezieht. Umgekehrt hat der Artikel keine Kenntnis davon, von welchen Auftragspositionen er verwendet wird. Ein Assoziationsende gilt dann als navigierbar, wenn es gleichzeitig auch Attribut der gegenüberliegenden Klasse ist3. Wenn beide Enden einer Assoziation navigierbar sind, können Sie die Anzeige der beiden Pfeile im Diagramm unterdrücken (siehe Abbildung 2).

Abbildung 5: Generalisierung zwischen zwei Klassen

Abbildung 5 zeigt eine Generalisierungsbeziehung (UML-Typ Generalization) zwischen den Klassen Großkundenauftrag und Auftrag. Diese besagt, dass die Klasse Großkundenauftrag die Klasse Auftrag spezialisiert und damit sämtliche Eigenschaften von ihr erbt.

2 Das Attribut auftrag der Klasse Auftragsposition wird innerhalb der Klasse ohne Angabe seiner Multiplizität 1 angezeigt, da es sich bei dem Wert 1 um den Standardwert für Multiplizitäten handelt und dieser innerhalb von Klassen normalerweise nicht angezeigt wird. 3 Es gibt noch eine weitere Möglichkeit, die Navigierbarkeit eines Assoziationsendes festzulegen. Auf diese soll hier jedoch nicht eingegangen werden soll.


6

2.2.2 Komponentendiagramm (Component Diagram)

Komponentendiagramme zeigen Beziehungen zwischen Komponenten und deren Eigenschaften.

Abbildung 6: Komponentendiagramm

Abbildung 6 stellt die einfachste Form eines Komponentendiagramms dar. Es zeigt drei (Software-) Komponenten und ihre Abhängigkeiten. Aus ihm lässt sich ableiten, dass die Komponenten zur Kunden- und Artikelverwaltung unabhängig von anderen Komponenten arbeiten können, während die Komponente Auftragsverwaltung Abhängigkeiten zu den beiden anderen Komponenten besitzt. Über die Natur dieser Abhängigkeiten macht dieses Diagramm keine Aussagen. Durch Verwendung von Ports und Schnittstellen lassen sich die Komponentenabhängigkeiten genauer beschreiben. Abbildung 7 zeigt ein entsprechendes Beispiel.

Abbildung 7: Komponenten mit Ports und Schnittstellen

Die Komponente Kundenverwaltung stellt über einen Port eine Schnittstelle namens Kundendatenzugriff zur Verfügung, über die sich bei der Komponente Kundedaten abfragen lassen. Analog dazu stellt auch die Komponente Artikelverwaltung eine entsprechende Schnittstelle Artikeldatenzugriff zur Verfügung. Die Komponente Auftragsverwaltung wiederum spezifiziert über zwei Ports, dass sie Zugriff auf die Schnittstellen Kundendatenzugriff und Artikeldatenzugriff benötigt. Zwei Abhängigkeitsbeziehungen verdeutlichen wiederum den Zugriff auf die Schnittstellen.


7

2.2.3 Kompositionsstrukturdiagramm (Composite Structure Diagram)

Kompositionsstrukturdiagramme zeigen die interne Struktur einer Klasse und die Beziehungen der einzelnen Klassenbestandteile zueinander.

Abbildung 8: Klassendiagramm mit Auftragsbestandteilen

Abbildung 8 erweitert das Beispiel aus Abbildung 2 um eine weitere an einem Auftrag beteiligte Klasse, der Rechnung. Im Gegensatz zur Auftragsposition ist die Rechnung nicht kompositorischer Bestandteil eines Auftrags, sondern ist im lediglich direkt zugeordnet. Die Rechnung verweist zudem auf die einzelnen Auftragspositionen.

Abbildung 9: Kompositionsstrukturdiagramm der Klasse Auftrag

Das Kompositionsstrukturdiagramm in Abbildung 9 bietet eine alternative Darstellung zum Klassendiagramm der Abbildung 8. Die beiden Attribute rechnung und position sind in der Klasse Auftrag als Symbole vom Typ Property bzw. Part grafisch dargestellt. Die gestrichelte Umrandung des Property-Symbols rechnung zeigt, dass die Rechnung nicht kompositorischer Bestandteil des Auftrags ist, während die durchgehende Umrandung des Part-Symbols position ausdrückt, dass Auftragspositionen kompositorisch im Auftrag enthalten sind. Beide Symbole sind mit einem Connector mit Namen p verbunden, der seinerseits auf die in Abbildung 8 gezeigte Assoziation Rechnungsposition verweist.


8

2.2.4 Objektdiagramm (Object Diagram)

Objektdiagramme zeigen, wie Instanzen verschiedener Klassen zueinander in Beziehung stehen.

Abbildung 10: Objektdiagramm mit Auftragsinstanz

Abbildung 10 zeigt einen konkreten Auftrag mit zwei Auftragspositionen. Der Auftrag, die beiden Auftragspositionen und die beiden Artikel sind Instanzen der entsprechenden Klassen aus Abbildung 1. Ihre Beziehungen stellen Instanzen der Assoziationen zwischen diesen Klassen dar. Instanzen von Klassen werden auch als Objekte bezeichnet und Instanzen von Assoziationen als Links. Technisch sind alle Instanzen jedoch vom UML-Typ InstanceSpecification4. Instanzen zeigen optional ihren eigenen Namen und/oder - durch einen Doppelpunkt getrennt - den Namen ihrer Klasse an. In diesem Beispiel zeigen das Auftragsobjekt und die beiden Artikelobjekte sowohl ihren eigenen als auch den Namen ihrer Klasse an, während die beiden Auftragspositionsobjekte nur ihren Klassennamen anzeigen. Die Attributwerte der Objekte sind vom UML-Typ Slot. Ein Slot zeigt jeweils den Namen eines Attributs der Klasse der Instanz (z. B. Auftragsnummer) an und den Wert, den dieses Attribut bei der Instanz hat (z. B. 42). Auch die Link-Enden (z. B. position) sind vom Typ Slot. Da diese jedoch im Diagramm direkt mit ihrem Wert, d. h. dem entsprechende Objekt, verknüpft sind, wird für diese nur der Attributname im Diagramm angezeigt.

4 UML 2 kennt nur noch einen Typ InstanceSpecification für Instanzen aller Klassifizierer-Typen, wohingegen UML 1.4 für jeden Klassifizier-Typ auch einen speziellen Instanz-Typ definiert hatte (z. B. Class -> Object, Association -> Link, AssociationClass -> LinkObject, Component -> ComponentInstance usw.).


9

2.2.5 Paketdiagramm (Package Diagram)

Paketdiagramme zeigen Pakethierarchien und Abhängigkeiten zwischen Paketen.

Abbildung 11: Paketdiagramm

Abbildung 11 zeigt ein Paketdiagramm mit zwei Pakethierarchien und Abhängigkeitsbeziehungen. Auf oberster Ebene enthält es die beiden Modelle Analysemodell und Designmodell. UML versteht im Gegensatz zu ARIS unter dem Begriff Modell kein Diagramm, sondern eine Sicht auf ein physisches System in einem definierten Kontext. Ein Modell beinhaltet i. d. R. eine ganze Reihe von Elementen, Beziehungen und Diagrammen, die in ihrer Gesamtheit das Modell beschreiben. Gemäß dieser Definition stellt im vorliegenden Beispiel das Analysemodell eine objektorientierte Sicht auf die Geschäftsprozesse dar, die mit Hilfe einer neu zu entwickelnden Software unterstützt werden sollen. Daraus wird ein Designmodell abgeleitet, das die Architektur und die einzelnen Module der Software genauer spezifiziert. Diese Ableitung wird im Diagramm durch eine Verfeinerungsbeziehung dargestellt. Bei dieser Beziehung handelt es sich um ein Element vom UML-Typ Abstraction mit Stereotyp «Refine». Innerhalb des Designmodells drückt die Abhängigkeitsbeziehung zwischen den Paketen Module und Framework aus, dass das Framework Strukturen definiert, die von den Modulen benötigt werden.


10

2.2.6 Profildiagramm (Profile Diagram)

Profile stellen benutzerdefinierte Erweiterungen oder auch Einschränkungen des UML-Metamodells dar. Diese lassen sich mit Hilfe von Profildiagrammen erstellen.

Abbildung 12: Profildiagramm

Abbildung 12 zeigt ein Profildiagramm zur Definition eines einfachen Profils für die objektorientierte Analyse. Auf der linken Seite enthält das Diagramm das Profil Analyseprofil, welches die beiden Stereotypen Fachklasse und Geschäftsanwendungsfall definiert. Beide erben von einem abstrakten Stereotypen Analyseelement, der das Attribut Ansprechpartner definiert. Neben den Stereotypen definiert das Profil auch eine Aufzählung Priorität, die vom gleichnamigen Attribut des Stereotyps Geschäftsanwendungsfall als Typ verwendet wird. Auf der rechten Seite des Diagramms sind das UML-Metamodell und zwei seiner Metaklassen enthalten. Das Profil besitzt eine Beziehung vom Typ Metamodellreferenz5 zum Metamodell. Diese Beziehung ist immer dann notwendig, wenn innerhalb von Paketen, denen das Profil zugeordnet ist, alle UML-Inhalte zur Verfügung stehen sollen. Die beiden Stereotypen Fachklasse bzw. Geschäftsanwendungsfall besitzen eine Beziehung vom UML-Typ Extension zur Metaklasse Class bzw. zur Metaklasse UseCase. Diese Beziehung legt fest, welchen UML-Elementen der Stereotyp zuordnen werden kann. Die Attribute eines Stereotyps stehen bei den UML-Elementen als zusätzliche Eigenschaften zur Verfügung, denen der Stereotyp zugeordnet wird. So besitzt in diesem Beispiel ein Anwendungsfall mit Stereotyp «Geschäftsanwendungsfall» neben den durch die UML-Spezifikation definierten Eigenschaften zusätzlich die Eigenschaften Ansprechpartner und Priorität. Kapitel 6 UML Profile beinhaltet weitere Informationen zum Thema Profile und Stereotypen.

5 Streng genommen handelt es sich um eine Beziehung vom UML-Typ PackageImport, die in diesem Kontext als Metamodellreferenz bezeichnet wird und in der grafischen Darstellung auch mit dem Schlüsselwort «reference» anstelle des Schlüsselwortes «import» angezeigt wird.


11

2.2.7 Verteilungsdiagramm (Deployment Diagram)

Verteilungsdiagramme zeigen die Zuordnung von Softwarekomponenten zu physikalischen IT-Systemen und die Vernetzung dieser Systeme untereinander.

Abbildung 13: Verteilungsdiagramm mit Komponenten und Artefakten

Abbildung 13 zeigt die physikalische Manifestierung der Komponenten aus Abbildung 7 als JAR-Dateien6. Dies erfolgt mit Hilfe von UML-Elementen des Typs Artefact, die über eine Beziehung vom Typ Manifestation mit den entsprechenden Komponenten verknüpft sind.

Abbildung 14: Verteilung von Software-Komponenten auf physikalischen Systeme

Abbildung 14 zeigt, wie die in Abbildung 13 definierten Artefakte oder Software-Komponenten auf physikalische Systeme verteilt sind und wie diese Systeme miteinander in Beziehung stehen.

6 Java-Bibliotheken


12

2.2.8 Aktivitätsdiagramm (Activity Diagram)

Aktivitätsdiagramme zeigen dynamische Abläufe in Form eines Graphs einzelner Aktionen. Sie können sowohl einen Prozess mit hohem Abstraktionsgrad als auch detailliert einen Algorithmus in einer Software beschreiben.

Abbildung 15: Aktivitätsdiagramm Auftrag anlegen


13

Abbildung 15 zeigt den Prozess beim Anlegen eines Auftrags in Form eines UML-Aktivitätsdiagramms. Die Aktivität startet mit einem Element vom Typ InitialNode und endet mit einem Element vom Typ ActivityFinal. Im ersten Schritt werden die Kundendaten geprüft. Dies erfolgt mittels einer Aktion vom Typ CallBehaviorAction. Dabei handelt es sich um eine Aktion, die ihrerseits eine Aktivität Kundendaten prüfen aufruft. Diese ist in einem weiteren Aktivitätsdiagramm (siehe Abbildung 16) beschrieben. Die übrigen Aktionen sind alle vom Typ OpaqueAction. Diese sind dadurch gekennzeichnet, dass sie durch einen einfachen Text spezifiziert werden und keine weitergehende UML-Semantik besitzen. Die Bearbeitung der einzelnen Bestell- bzw. Auftragsposition erfolgt in einer ExpansionRegion. Diese besitzt als Eingangselemente die Bestellpositionen des Kunden und als Ausgangselemente die entsprechenden Auftragspositionen. Die ExpansionRegion wird für jedes Eingangselement durchlaufen. Die Beziehungen in den beiden Aktivitätsdiagrammen sind alle vom Typ ControlFlow. Ist an einer solchen Kontrollflusskante ein Text in eckigen Klammern angegeben, beschreibt dieser die Bedingung, die erfüllt sein muss, damit der Kontrollfluss entlang dieser Kante erfolgen kann.

Abbildung 16: Aktivitätsdiagramm Kundendaten prüfen


14

2.2.9 Anwendungsfalldiagramm (Use Case Diagram)

Anwendungsfalldiagramme werden im Rahmen einer objekt-orientierte Anforderungsanalyse verwendet, um die zu untersuchenden Anwendungsfälle und die beteiligten Akteure zu beschreiben.

Abbildung 17: Anwendungsfalldiagramm

Abbildung 17 zeigt ein Anwendungsfalldiagramm mit einem Akteur und drei Anwendungsfällen. Akteure sind Personen, Rollen oder Systeme, die mit dem zu analysierenden System interagieren. Ein Anwendungsfall stellt eine in sich abgeschlossene und von außerhalb des Systems aufrufbare Funktionalität dar, die ein bestimmtes Ergebnis zur Folge hat. Bei den Beziehungen zwischen dem Akteur und den Anwendungsfällen handelt es sich um Assoziationen. In der Regel werden diese in Anwendungsfalldiagrammen ohne Annotationen wie Namen oder Multiplizitäten angezeigt. Zwischen den Anwendungsfällen Auftrag anlegen und Kundendaten prüfen verläuft eine Beziehung des Typs Include. Diese besagt, dass der Anwendungsfall Auftrag anlegen den Anwendungsfall Kundendaten prüfen umfasst, d. h. beim Anlegen eines Auftrages werden auch die Kundendaten geprüft. Der Anwendungsfall Auftrag anlegen definiert einen Extension Point namens Rabattberechnung. Ein Extension Point kennzeichnet eine bestimmte Stelle im internen Ablauf des Anwendungsfalls, an der diesem Ablauf weitere Funktionalität hinzugefügt werden kann. Im vorliegenden Beispiel ist das die Berechnung eines Rabatts. Die Extend-Beziehung zwischen den Anwendungsfällen Großkundenauftrag anlegen und Auftrag anlegen drückt aus, dass der Anwendungsfall Großkundenauftrag anlegen den Anwendungsfall Auftrag anlegen an dessen Erweiterungspunkt Rabattberechnung um diese Funktionalität ergänzt, etwa durch Berechnung eines speziellen Großkundenrabatts. Zusätzlich ist an der Extend-Beziehung die Bedingung angegeben, unter der diese Erweiterung zulässig ist: bei dem Kunden muss es sich um einen Großkunden handeln.


15

Typischerweise würde man den internen Ablauf der Anwendungsfälle mit Hilfe von Verhaltensdiagrammen, beispielsweise den beiden Aktivitätsdiagrammen in Abbildung 15 und Abbildung 16 beschreiben.


16

2.2.10 Kommunikationsdiagramm (Communication Diagram)

Kommunikationsdiagramme zeigen, wie Elemente im Rahmen einer Interaktion miteinander Nachrichten austauschen. Im Gegensatz zu Sequenzdiagrammen stehen bei Kommunikationsdiagrammen die Kanäle im Vordergrund, über welche diese Nachrichten gesendet werden, weniger der zeitliche Ablauf des Nachrichtenaustauschs.

Abbildung 18: Kommunikationsdiagramm Auftrag anlegen

Abbildung 18 zeigt anhand eines Kommunikationsdiagramms, wie im System ein Auftrag angelegt wird. Bei dem Hintergrundobjekt, das alle anderen Elemente beinhaltet, handelt es sich um die Interaktion selbst. Bei den enthaltenen Elementen handelt es sich um Elemente des Typs Lifeline (deutsch: Lebenslinie). Der Begriff Lebenslinie stammt aus ihrer Verwendung in Sequenzdiagrammen, wo sie in Form eines Rechtecks mit unten angehängter vertikaler Linie dargestellt werden. Die Lebenslinien zeigen im Diagramm nicht ihren eigenen Namen an, sondern den Namen des jeweils repräsentierten Elements und/oder den Typnamen des repräsentierten Elements7. Je nach Kontext kann es sich bei dem repräsentierten Element um ein Attribut (Property), einen Port oder einen Parameter handeln. Im obigen Beispiel wurde für Lebenslinie :Auftragsverwaltung ein Property als Attribut der Interaktion angelegt und diesem als Typ die Komponente Auftragsverwaltung aus Abbildung 6 zugeordnet. Da der Name des Attributs hier keine Rolle spielt, zeigt die Lebenslinie nur den Typnamen an. Bei den Beziehungen zwischen den Lebenslinien handelt es sich um die aus den Kompositionsstrukturdiagrammen bekannten Konnektoren. Dabei ist zu beachten, dass diese im Diagramm zwar grafisch die Lebenslinien miteinander verbinden, es sich tatsächlich aber um Beziehungen zwischen den repräsentierten Elementen handelt. Dies bedeutet, wenn einer Lebenslinie kein repräsentiertes Element zugeordnet ist, können Sie diese auch nicht über einen Konnektor mit einer anderen Lebenslinie im Diagramm verbinden. Die Nachrichten, die die Lebenslinien entlang der Konnektoren miteinander austauschen, werden am Konnektor als Text angezeigt. Ein Pfeil gibt jeweils die Richtung der Nachricht an, ihre Reihenfolge ergibt sich aus den Sequenznummern der Nachrichten. Besitzen die Nachrichten Argumente, sind diese in Klammern hinter der Nachricht aufgeführt.

7 Das repräsentierte Element wird der Lebenslinie über dessen Eigenschaft represents zugeordnet.


17

Das vorliegende Kommunikationsdiagramm ist wie folgt zu lesen: 1: Die Auftragsverwaltung legt ein neues Auftragsobjekt an. 2: Die Auftragsverwaltung reserviert 100 Artikel mit der Artikelnummer 28.97.08.0040. 2.1: Die Artikelverwaltung bestätigt die Reservierung. 3: Die Auftragsverwaltung weist das Auftragsobjekt an, eine neue Auftragsposition zur

Artikelnummer 28.97.08.0040 mit Stückzahl 100 anzulegen. 3.1: Das Auftragsobjekt erzeugt eine neue Auftragsposition mit den entsprechenden Parametern. 4. – 5.1: Das Gleiche wird für einen weiteren Artikel wiederholt. Die Sequenznummern werden in ARIS UML Designer anhand der Reihenfolge der Nachrichten bei den Quell- und Ziellebenslinien automatisch berechnet. Möchten Sie diese ändern, müssen Sie dies im Eigenschaftsdialog der jeweiligen Lebenslinien tun. Alternativ dazu können Sie die Anzeige der berechneten Sequenznummern ausblenden und eigene Nummern als Teil des Nachrichtennamens vergeben.


18

2.2.11 Sequenzdiagramm (Sequence Diagram)

Sequenzdiagramme zeigen, wie Elemente im Rahmen einer Interaktion miteinander Nachrichten austauschen. Im Gegensatz zu Kommunikationsdiagrammen steht bei Sequenzdiagrammen der zeitliche Ablauf des Nachrichtenaustauschs im Vordergrund, nicht die Kanäle, über welche diese Nachrichten gesendet werden.

Abbildung 19: Sequenzdiagramm Auftrag anlegen

Abbildung 19 zeigt die in Abbildung 18 in Form eines Kommunikationsdiagramms dargestellte Interaktion Auftrag anlegen als Sequenzdiagramm. Beide Diagramme beinhalten Elemente vom Typ Lifeline. Im Sequenzdiagramm sind diese jedoch zusätzlich mit einer gestrichelten vertikalen Linie versehen8. Die Nachrichten werden im Sequenzdiagramm durch grafische Kanten repräsentiert. Während sich im Kommunikationsdiagramm die zeitliche Abfolge der Nachrichten aus ihren Sequenznummern ergibt, wird diese im Sequenzdiagramm durch deren vertikale Anordnung definiert. Die nicht explizit sichtbare Zeitachse verläuft im Diagramm vertikal von oben nach unten, d. h. weiter oben liegende Nachrichten werden vor weiter unten liegenden Nachrichten übertragen. Bei den Rechtecken auf den Lebenslinien handelt es sich um Elemente des Typs ExecutionSpecification. Sie zeigen an, wann das durch die Lebenslinie repräsentierte Objekt aktiv ist.

8 Auf diese Art der grafischen Darstellung geht auch der Name Lifeline zurück.


19

2.2.12 Zeitablauf-Diagramm (Timing Diagram)

Zeitablauf-Diagramme zeigen, wie sich im Rahmen einer Interaktion der Zustand der beteiligten Elemente beim Austausch von Nachrichten verändert. Die Notation ist an entsprechende Diagramme aus der Digitaltechnik angelehnt. Dieser Diagrammtyp ist vor allem für die Modellierung hardware-naher Softwaresysteme interessant und wird von ARIS UML Designer 9 nur rudimentär unterstützt.

Abbildung 20: Zeitablauf-Diagramm Auftragszustände

In Abbildung 20 zeigt ein einfaches Zeitablauf-Diagramm in kompakter Notation9, welche Zustände ein Auftrag annehmen kann. Bei dem Element Auftragszustände handelt es sich um eine Interaktion, das Element :Auftrag ist eine Lebenslinie und die verschiedenen Zustände werden mit Hilfe von Zustandsinvarianten (UML-Typ StateInvariant) dargestellt. Das Element DurationConstraint gibt zudem an, dass der Zustand in Auslieferung nur ein bis zwei Tage dauern darf.

9 Die ausführliche Notation, bei der Zustände und deren Übergänge mit Hilfe von Zeitlinien angezeigt werden, wird von ARIS UML Designer nicht unterstützt.


20

2.2.13 Interaktionsübersichtsdiagramm (Interaction Overview Diagram)

Ein Interaktionsübersichtsdiagramm zeigt im Rahmen eines größeren Szenarios die Abfolge einzelner Interaktionen, welche üblicherweise mittels Kommunikations- oder Sequenzdiagrammen modelliert werden. Bei diesen Diagrammen handelt es sich um Aktivitätsdiagramme, bei denen nur Aktionen vom Typ CallBehaviorAction verwendet werden, die ihrerseits Interaktion aufrufen.

Abbildung 21: Interaktionsübersichtsdiagramm Auftrag verwalten

Abbildung 21 zeigt ein Interaktionsübersichtsdiagramm, das unter anderem die in Abbildung 18 modellierte Interaktion Auftrag anlegen aufruft. Die einzelnen Aktionen vom Typ CallBehaviorAction zeigen jeweils den Namen der aufgerufenen Interaktion an.


21

2.2.14 Zustandsautomatendiagramm (State Machine Diagram)

Zustandsautomatendiagramme zeigen welche Zustände (UML-Typ State) ein System einnehmen kann, wie diese zueinander in Zusammenhang stehen und welche Ereignisse die jeweiligen Zustandsübergänge (UML-Typ Transition) auslösen. Ein Zustandsautomatendiagramm repräsentiert einen Zustandsautomaten (UML-Typ StateMachine). Die Zustände und deren Übergänge sind Bestandteile dieses Zustandsautomaten. Der Zustandsautomat kann das Verhalten einer Klasse (UML-Typ Class), das Verhalten eines anderen Klassifizierers vom UML-Typ BehavioredClassifier oder das Verhalten einer Operation beschreiben. Er kann aber auch ganz allgemein ein Verhalten beschreiben, ohne sich auf eines dieser Elemente zu beziehen.

Abbildung 22: Zustandsautomatendiagramm Auftragszustände

Abbildung 22 zeigt die Zustände eines Auftrags. Während das Zeitablauf-Diagramm aus Abbildung 20 lediglich eine Abfolge an Zustandsübergängen zeigt, beinhaltet das Zustandsautomatendiagramm den vollständigen Zustandsautomaten mit allen Zuständen und ihren möglichen Übergängen als grafische Kanten, welche die Zustände miteinander verknüpfen. Der erste Zustand, den ein Auftrag einnehmen kann, ist der Zustand neu. Beim Eintreten dieses Zustands werden die Auftragspositionen erfasst (Eigenschaft entry des UML-Typs State). Eine Verfügbarkeitsprüfung der Artikel der Auftragspositionen beendet den Zustand (Eigenschaft exit des UML-Typs State). Steht ein Text an einem Zustandsübergang in eckigen Klammern, bezeichnet er die Bedingung (Eigenschaft guard des UML-Typs Transition), die erfüllt sein muss, damit der Zustandsübergang stattfinden kann. Im


22

Beispieldiagramm sind dies die beiden Bedingungen [Artikel sind verfügbar] und [Artikel sind nicht verfügbar]. Der Text, der an einem Zustandsübergang auf das Zeichen / folgt, bezeichnet ein Verhalten, das durch den Zustandsübergang ausgelöst wird (Eigenschaft effect des UML-Typs Transition). Im Beispieldiagramm wären dies freigeben, ablehnen und ausliefern. Steht ein Text an einem Zustandsübergang weder in eckigen Klammern noch hinter einem Schrägstrich, handelt es sich um den Auslöser (UML-Typ Trigger) des Zustandsübergangs (Eigenschaft trigger des UML-Typs Transition). Im Beispieldiagramm sind dies die beiden Texte, die mit dem englischen Wort when beginnen. Aus dem Schlüsselwort when ergibt sich, dass den Triggern Ereignisse vom UML-Typ ChangeEvent zugeordnet sind (Eigenschaft event des UML-Typs Trigger).


23

2.2.15 Protokoll-Zustandsautomaten-Diagramm (Protocol State Machine Diagram)

Protokoll-Zustandsautomaten (UML-Typ ProtocolStateMachine) zeigen die von außen beobachtbaren Zustände und Zustandsübergänge eines Klassifizierers. Sie definieren ein Protokoll, an das sich die Implementierungen des jeweiligen Klassifizierers halten müssen und zeigen, wann, in welcher Reihenfolge und unter welchen Bedingungen die öffentlich sichtbaren Operationen des Klassifizierers aufgerufen werden.

Abbildung 23: Klasse Auftrag mit Operationen

Abbildung 23 zeigt die Klasse Auftrag mit ihren öffentlichen Operationen (UML-Elemente vom Typ Operation mit der Eigenschaft visibility = public, jeweils erkennbar am Zeichen + zu Beginn des Namens).

Abbildung 24:Protokoll-Zustandsautomaten-Diagramm Auftragszustände


24

Das Protokoll-Zustandsautomaten-Diagramm in Abbildung 24 zeigt, wie Aufrufe dieser Operationen entsprechende Zustandsänderungen zur Folge haben. Statt normaler Zustandsübergänge werden in Protokoll-Zustandsautomaten Protokoll-Zustandsübergänge (UML-Typ ProtocolTransition) verwendet. Protokoll-Zustandsübergänge unterscheiden sich in ihrer Notation von normalen Zustandsübergängen. Die Notation eines Protokoll-Zustandsübergangs lautet: [Vorbedingung] Ereignis / [Nachbedingung] Die Vorbedingung wird auf die Eigenschaft preCondition des UML-Typs ProtocolTransition abgebildet, die Nachbedingung auf die Eigenschaft postCondition. Das Ereignis wird wie bei normalen Zustandsübergängen auf die Eigenschaft trigger abgebildet, wobei den Triggern Ereignisse vom UML-Typ CallEvent zugeordnet sind, die ihrerseits auf die entsprechenden Operationen der Klasse verweisen, sodass im Diagramm als Ereignis die entsprechende Operation angezeigt wird.


25

2.3 Besonderheiten in ARIS UML Designer

2.3.1 Diagramminhalte

Die UML-Spezifikation sieht vor, dass die von ihr vorgeschlagenen typischen Inhalte der verschiedenen Diagrammtypen von Produktherstellern um Inhalte der jeweils anderen UML-Diagrammtypen erweitert werden können. ARIS UML Designer unterstützt für Strukturdiagramme beliebige UML-Inhalte. Neben den für den entsprechenden Diagrammtyp vorgesehenen Elementen können Sie dort optional auch alle anderen UML-Konstrukte modellieren. Auf diese Weise lassen sich Übersichtdiagramme erstellen, die beispielsweise sowohl Klassenhierarchien als auch vollständige Zustandsautomaten und Interaktionen in Sequenzdiagrammnotation beinhalten. Dies ermöglicht es, auch solche UML-Elemente grafisch miteinander in Verbindung setzen, die eigentlich unterschiedlichen Diagrammtypen zugeordnet sind.

Abbildung 25: UML-Notationen verschiedener Diagrammtypen in einem Klassendiagramm

Abbildung 25 zeigt Elemente aus Klassen-, Anwendungsfall-, Komponenten- und Aktivitätsdiagrammen gemeinsam in einem Klassendiagramm.


26

2.3.2 Namen von UML-Elementen

Die UML-Spezifikation beschreibt einige wenige Elementtypen, deren Elemente keinen Namen haben können. Beispiele für solche Typen sind Comment und Generalization. Bedingt durch die Abbildung von UML-Elementen auf ARIS-Objekte, haben auch solche Typen in ARIS UML Designer einen Namen.

2.3.3 Mehrsprachigkeit

Die UML-Spezifikation sieht nicht vor, dass Elementnamen, Kommentare oder andere Texteigenschaften in verschiedenen Sprachen gepflegt werden können. Einzige Ausnahme stellt der UML-Typ OpaqueExpression dar, der es erlaubt, dass der enthaltende Ausdruck mehrere Werte haben kann; für jeden dieser Werte können Sie eine Sprache angeben. Dabei ist der Begriff Sprache jedoch weiter gefasst als in ARIS und kann auch Programmiersprache bedeuten. ARIS UML Designer unterstützt auch für UML-Inhalte die von ARIS bekannte Mehrsprachigkeit, allerdings nur für Element- und Diagrammnamen, für Kommentare und Beschreibungen. Alle anderen Texteigenschaften sind nicht mehrsprachig.

2.4 Das UML Metamodell

Eine Besonderheit der UML-Spezifikation besteht darin, dass sie UML mit Hilfe einer Teilmenge von UML definiert. Anhand von Klassendiagrammen ist dort beschrieben, welche UML-Elementtypen es gibt, welche Eigenschaften diese besitzen und wie sie zueinander in Beziehung stehen. Die Gesamtheit dessen, was in diesen Klassendiagrammen dargestellt ist, wird als UML-Metamodell bezeichnet10. Die UML-Elementtypen werden in diesem Metamodell in Form von Metaklassen definiert. Die verschiedenen Eigenschaften der UML-Elementtypen werden mit Hilfe von Attributen und Assoziationen beschrieben. Abstrakte Metaklassen definieren Eigenschaften, die mehreren verschiedenen UML-Elementtypen gemeinsam sind und deren Metaklassen von diesen abstrakten Metaklassen erben. Die Architektur zur Beschreibung und Implementierung von Metamodellen ist im MOF11-Standard der OMG beschrieben. Eine ARIS-spezifische MOF-Implementierung mit Namen OMF12 stellt einen zentralen Bestandteil der Architektur von ARIS UML Designer dar. Grundkenntnisse dies UML-Metamodells sind zum Verständnis von UML hilfreich und zur Modellierung von UML-Profilen (siehe Kapitel 6 UML Profile) erforderlich. Im Folgenden wird ein kleiner Ausschnitt des UML-Metamodells vorgestellt, der diejenigen UML-Elemente definiert, die im Klassendiagramm von Abbildung 1 verwendet werden. Die gezeigten Metamodelldiagramme entsprechen weitgehend den jeweiligen Originalen der UML-2.5-Spezifikation. Teilweise wurden sie jedoch durch Auslassen einzelner hier nicht weiter betrachteter Metaklassen oder Hinzufügen von Inhalten aus anderen Diagrammen der UML-Spezifikation an die Erfordernisse dieses Kapitels angepasst. Die nachfolgend verwendeten Kapitelüberschriften entsprechen den Überschriften der Kapitel aus der UML-Spezifikation, in denen die entsprechenden Diagramme enthalten sind, sodass sie diese zur weiteren Vertiefung des Themas leicht in der UML-Spezifikation finden können.

10 Über die Klassendiagramme hinaus enthält die UML-Spezifikation auch zahlreiche OCL-Ausdrücke, die einerseits Konsistenzbedingungen, andererseits auch die Implementierung komplexer Abfragen beschreiben. Diese sind ebenfalls Bestandteil des UML-Metamodells, werden aber im Rahmen dieser UML-Einführung nicht weiter betrachtet. 11 MOF steht für Meta Object Facility 12 OMF steht für Object Modeling Framwork


27

2.4.1 Common Structure

2.4.1.1 Root

Abbildung 26: Diagramm Root der UML-Spezifikation mit ARIS-spezifischen Erweiterungen

Abbildung 26 zeigt das Diagramm Root der UML-Spezifikation ergänzt um ARIS-spezifische Erweiterungen. Die Metaklassen aus dem UML-Metamodell bilden eine Vererbungshierarchie, an deren Spitze die abstrakte Metaklasse Element steht. "Abstrakt" bedeutet in diesem Zusammenhang, dass es keine UML-Elemente vom Typ Element gibt, sondern dass hier nur Eigenschaften für andere Elementtypen definiert werden, die von Element erben. Abstrakte Klassen in UML-Diagrammen sind durch kursiv geschriebene Namen dargestellt.


28

In ARIS UML Designer erbt die UML-Metaklasse Element noch von einer abstrakten Metaklasse ArisElement. Dadurch werden alle UML-Elemente um ARIS-spezifische Eigenschaften wie creator, creationDate aber auch name, description und identifier erweitert13. Von der Metaklasse Element erbt die nicht abstrakte Metaklasse Comment. Jedes UML-Element kann über seine Eigenschaft ownedComment beliebig viele solcher Kommentare besitzen. Ein Kommentar wiederum kann sich über seine Eigenschaft annotatedElement auf beliebig viele UML-Elemente beziehen.

Abbildung 27: Comment mit Klasse als annotiertes Element

Kommentare werden in Diagrammen als Rechteck mit Eselsohr angezeigt. Der Text innerhalb des Kommentars zeigt den Wert der Eigenschaft Comment::body an. Die Eigenschaft Comment::annotatedElement wird als gestrichelte Kante zum annotierten Element im Diagramm angezeigt (siehe Abbildung 27). Eine ARIS-spezifische Erweiterung zum UML-Metamodell stellt auch die Eigenschaft Element::/description dar. Sie definiert für UML-Elemente die ARIS-Eigenschaft ArisElement::description neu, indem die Beschreibung aus dem ersten Kommentar, den das Element besitzt, abgeleitet wird14. Dadurch haben UML-Elemente in ARIS UML Designer die ARIS-Eigenschaft description. Deren Wert geht allerdings beim Datenaustausch via XMI mit anderen Tools nicht verloren, da er als ownedComment beim Element gespeichert ist. Umgekehrt hat somit auch jedes UML-Element, das via XMI in ARIS UML Designer importiert wird und einen Kommentar besitzt, automatisch einen Wert für seine Eigenschaft description. Das Root-Diagramm in Abbildung 26 zeigt auch, dass prinzipiell jedes UML-Element andere UML-Elemente besitzen kann. Zu diesem Zweck definiert Element zwei Eigenschaften /owner und /ownedElement. Bei beiden handelt es sich um sogenannte derived unions. Dies bedeutet, dass Sie ein Element nach seinem Eigentümer oder seinen enthaltenen Elementen fragen können, aber dass erst andere Eigenschaften des Typs Element und seiner Spezialisierungen festlegen, auf welche Weise das Element andere Elemente beinhalten kann bzw. auf welche Weise es in einem anderen Element enthalten sein kann. Ein erstes Beispiel hierfür ist bereits im gleichen Diagramm enthalten. Bei der Eigenschaft Element::ownedComment steht subsets ownedElement und bei der Eigenschaft Comment::owningElement steht subsets owner. Dies bedeutet, immer wenn ein Element nach dem Wert seiner Eigenschaft ownedElement gefragt wird, liefert es unter anderem den Wert der Eigenschaft ownedComment zurück, also die Kommentare, die es besitzt. Das gleiche gilt für den Fall, dass Sie einen Kommentar nach seiner Eigenschaft owner fragen: in diesem Fall wird der Wert der Eigenschaft owningElement zurück geliefert. Darüber hinaus beinhaltet das Root-Diagramm auch die beiden abstrakten Metaklassen Relationship und DirectedRelationship. Von diesen Klassen erben alle Metaklassen, die in erster Linie eine Semantik für Beziehungen zwischen Elementen zu definieren. Häufig werden solche Beziehungselemente als grafische Kanten in Diagrammen dargestellt. Als Beispiele für solche Beziehungstypen beinhaltet diese Metamodellvorstellung die beiden Metaklassen Generalization und Association.

13 Ein Schrägstrich / vor einem Attributnamen bedeutet, dass dessen Wert zur Laufzeit aus anderen Eigenschaften abgeleitet wird. Dies trifft hier auch auf ARIS-Eigenschaften wie creator oder guid zu, da diese intern nicht auf ARIS-Attribute abgebildet werden, sondern sich direkt aus dem ARIS-Objekt ergeben. 14 Zu diesem Zweck ist bei der Eigenschaft Element::ownedComment in ARIS UML Designer auch das Kennzeichen isOrdered gesetzt, während das UML-Metamodell hier ursprünglich keine Ordnung vorsieht.


29

2.4.1.2 Namespaces

Abbildung 28: Diagramm Namespaces der UML-Spezifikation

Abbildung 28 zeigt das Diagramm Namespaces der UML-Spezifikation. Es definiert die drei abstrakten Typen NamedElement, Namespace und PackageableElement und den nicht-abstrakten Typ Package. NamedElement definiert u.a. die Eigenschaft name, was bedeutet, dass eigentlich nur UML-Elemente, deren Typ von NamedElement erbt, einen Namen tragen können. Da in ARIS alle Objekte einen Namen haben können und Element in der ARIS-Implementierung des UML-Metamodells von ArisElement erbt, gibt der Zusatz {redefines name} bei NamedElement::name an, dass hier keine zweite Eigenschaft name definiert wird, sondern dass diese Definition von name innerhalb der Vererbungshierarchie von NamedElement die Definition ArisElement::name ersetzt. Beide Eigenschaften, ArisElement::name und NamedElement::name, werden im ARIS-Objektmodell auf den ARIS-Attributtyp Name abgebildet. Namespace ist ein abstrakter Typ für UML-Elemente, deren enthaltenen Elemente anhand ihres Namens unterschieden werden. Davon erbt der nicht-abstrakte Typ Package, der Elemente des abstrakten Typs PackageableElement beinhalten kann. Das Namspaces-Diagramm in Abbildung 28 enthält auch ein weiteres Beispiel für derived unions: Die Eigenschaft Package::packagedElement trägt zur Eigenschaft Namspace::member und diese zur Eigenschaft Element::ownedElement bei.


30

Abbildung 29: Beispiel für Kanten owningPackage

Die Eigenschaft Package::packagedElement bzw. PackageableElement::owningPackage kann in Diagrammen grafisch als Kante dargestellt werden (siehe Abbildung 29).


31

2.4.1.3 Types and Multiplicities

Abbildung 30: Diagramm Types and Multiplicities aus der UML-Spezifikation

Abbildung 30 zeigt das Diagramm Types and Multiplicities der UML-Spezifikation. Dieses definiert die abstrakten Metaklassen Type, TypedElement und MultiplicityElement. Von der abstrakten Metaklasse TypedElement erben Metaklassen, deren Elementen ein Typ zugeordnet werden kann. Typische Beispiele für solche Elemente sind Attribute (UML-Metaklasse Property) und Parameter (UML-Metaklasse Parameter). Die abstrakte Metaklasse MultiplicityElement ist Basisklasse aller Metaklassen, deren Elemente eine Multiplizität besitzen können. Auch hier sind Attribute und Parameter typische Beispiele. UML 2 ist an dieser Stelle insofern komplexer als UML 1.x, als die Ober- und Untergrenze einer Multiplizität kein primitiver Datentyp (also keine einfache Zahl) mehr ist, sondern es sich um UML-Elemente handelt, deren Metaklasse vom abstrakten Typ ValueSpecification erben. Neben den entsprechenden Eigenschaften MultiplicityElement::lowerValue und MultiplicityElement::upperValue sind zwar noch die zwei weitere Eigenschaften MultiplicityElement::/lower und MultiplicityElement::/upper mit einfachem Datentyp definiert, diese werden jedoch aus den zugeordneten ValueSpecification-Elementen abgeleitet.


32

2.4.2 Values

2.4.2.1 Literals

Abbildung 31: Diagramm Literals der UML-Spezifikation

Abbildung 31 zeigt das Diagramm Literals der UML-Spezifikation. Es definiert einige Spezialisierungen der Metaklasse ValueSpecification15. Typischerweise werden Sie für die Eigenschaft MultiplicityElement::lowerValue ein Element des Typs LiteralInteger und für die Eigenschaft MultiplicityElement::upperValue ein Element des Typs LiteralUnlimitedNatural verwenden.

Abbildung 32: Klassendiagramm mit Attributen, Assoziationsenden und Multiplizitäten

15 Neben den in Diagramm Literals gezeigten Spezialisierungen von ValueSpecification gibt es noch weitere, aber auf diese soll hier nicht näher eingegangen werden.


33

Das Klassendiagramm in Abbildung 32 zeigt zwei Beispiele für Multiplizitäten: Das Assoziationsende auftrag hat eine Multiplizität von 1, was eine Kurzform für 1..1 darstellt, d. h. die Eigenschaften /lower und /upper haben jeweils den Wert 1. Auf welchen konkreten Elementen des Typs ValueSpecification die beiden Werte basieren, geht aus der grafischen Notation im Diagramm nicht hervor. Das Assoziationsende position hat eine Multiplizität von 1..*, d. h. die Eigenschaft lower hat den Wert 1 und die Eigenschaft upper den Wert *, wobei * für unbegrenzt steht.


34

2.4.3 Classification

2.4.3.1 Classifiers

Abbildung 33: Diagramm Classifiers aus der UML-Spezifikation

Abbildung 33 zeigt das Diagramm Classifers aus der UML-Spezifikation. Es definiert die beiden abstrakten Metaklassen RedefinableElement und Classifier und die nicht abstrakte Metaklasse Generalization. RedefinableElement ist Basis für alle UML-Elementtypen, bei denen es möglich sein soll, dass ein UML-Element ein bereits existierendes anderes UML-Element in einem bestimmten Kontext ersetzt. Die UML-Spezifikation selbst verwendet diese Möglichkeit in ihren eigenen Diagrammen. Ein Beispiel dafür zeigt Abbildung 28: das Attribut PackageableElement::visibility ersetzt das entsprechende Attribut aus der Basisklasse NamedElement, da es im Gegensatz zu NamedElement::visibility einen Default-Wert besitzt. Classifier ist Basis für alle UML-Elementtypen, für deren Elemente Vererbungsbeziehungen existieren können. Diese Vererbungsbeziehungen basieren auf der Metaklasse Generalization.


35

Abbildung 34: Generalisierungsbeziehung zwischen zwei Klassen

Abbildung 34 zeigt eine solche Generalisierungsbeziehung zwischen den beiden Klassen Großkundenauftrag und Auftrag. Bei dieser Beziehung handelt es sich selbst um ein UML-Element des Typs Generalization. Dieses Element ist gemäß der kompositorischen Eigenschaft Classifier::general Bestandteil der abgeleiteten Klasse Großkundenauftrag und verweist über seine Eigenschaft Generalization::general auf die Basisklasse Auftrag.


36

2.4.3.2 Features

Abbildung 35: Diagramm Features der UML-Spezifikation

Abbildung 35 zeigt einen Ausschnitt aus dem Diagramm Features ergänzt um Inhalte aus dem Diagramm Properties der UML Spezifikation. Im Mittelpunkt steht die nicht abstrakte Metaklasse Property mit ihren Basisklassen. Attribute von Klassen und Assoziationsenden basieren auf der Metaklasse Property.

Abbildung 36Klassendiagramm mit Attributen und Assoziationsenden


37

Das Klassendiagramm in Abbildung 36 zeigt vier UML-Elemente des Typs Property: die beiden Attribute Auftragsnummer und Anzahl sowie die beiden Assoziationsenden auftrag und position16. Die Assoziationskante zeigt am gegenüberliegenden Ende von auftrag eine ausgefüllte schwarze Raute. Diese besagt, dass die Auftragspositionen Bestandteil des Auftrags und auch von diesem existentiell abhängig sind, d. h., ein Löschen des Auftrags beinhaltet auch das Löschen seiner Auftragspositionen. Eine solche Assoziation wird auch als Komposition bezeichnet. Am Assoziationsende auftrag wird die ausgefüllte Raute genau dann angezeigt, wenn die Eigenschaft Property::aggregation des Assoziationsendes position den Wert AggregationKind::composite hat.

16 Tatsächlich sind in diesem Diagramm auch die beiden Assoziationsenden Attribute der jeweils gegenüberliegenden Klasse. Der Abschnitt zur Metaklasse Association geht ausführlicher darauf ein.


38

2.4.4 Structured Classifiers

2.4.4.1 Classes

Abbildung 37: Diagramm Classes der UML –Spezifikation

Abbildung 37 zeigt einen Ausschnitt aus dem Diagramm Classes ergänzt um Inhalte aus den Diagrammen Structured Classifiers und Encapsulated Classifiers der UML-Spezifikation. Zentrale Metaklasse dieses Diagramms ist Class. Die drei abstrakten Basisklassen BehavioredClassifier, StructuredClassifier und EncapsulatedClassifier sind hier nur enthalten, um die Vererbungsbeziehung zwischen Class und Classifier zu verdeutlichen. Sie definieren zusätzliche Eigenschaften, auf die in dieser Einführung nicht weiter eingegangen wird. Das Diagramm zeigt auch, dass prinzipiell allen Klassifizierern über die abgeleitete Eigenschaft Classifier::/attribute Attribute (UML-Typ Property) zugeordnet sein können. Die Art der konkreten Zuordnung wird von den entsprechenden Spezialisierungen festgelegt. Bei der Metaklasse Class handelt es sich um die kompositorische Eigenschaft ownedAttribute. Ein Beispiel für die Darstellung von Attributen in Klassen zeigt Abbildung 36.


39

2.4.4.2 Associations

Abbildung 38: Diagramm Associations aus der UML-Spezifikation

Abbildung 38 zeigt einen Ausschnitt aus dem Diagramm Associations aus der UML-Spezifikation. Es definiert als zentrale Metaklasse den Beziehungstyp Association. Assoziationen werden verwendet, um Strukturen zu modellieren, die von einer oder mehreren Klassen oder anderen UML-Typen gebildet werden. Dabei ist die Assoziation nicht direkt mit den Beziehungspartnern verbunden, sondern verwendet dazu Element vom UML-Typ Property, in diesem Kontext oft auch Assoziationsenden bezeichnet. Maßgeblich hierzu ist die Eigenschaft Association::memberEnd, deren untere Multiplizitätsgrenze von 2 besagt, dass eine Assoziation mindestens zwei Assoziationsenden besitzen muss17. Diese Assoziationsenden können entweder über die Eigenschaft Association::ownedEnd in der Assoziation selbst enthalten oder Attribut des gegenüberliegenden Beziehungspartners der Assoziation sein (im Fall einer Klasse wäre dies die Eigenschaft Class::ownedAttribute). Ist das Assoziationsende Attribut des gegenüberliegenden Beziehungspartners, ist die Assoziation in Richtung des Assoziationsendes navigierbar. Alternativ kann auch ein Assoziationsende navigierbar sein, das kein Attribut ist (also als ownedEnd seiner Assoziation gehört), wenn es der Assoziation zusätzlich als navigableOwnedEnd zugeordnet ist.

Abbildung 39: Klassendiagramm mit einer Assoziation

17 Assoziationen mit zwei Enden bezeichnet man auch als binäre Assoziationen. Diese werden in Diagrammen i. d. R. als grafische Kante angezeigt. Hat eine Assoziation mehr als zwei Enden, spricht man von einer mehrgliedrigen Assoziation. Mehrgliedrige Assoziationen werden in Diagrammen als Rauten mit Kanten zu den Beziehungspartnern angezeigt.


40

Die Assoziation in Abbildung 39 verknüpft zwei Klassen miteinander. Das Assoziationsende artikel ist Attribut der Klasse Auftragsposition (Eigenschaft Class::ownedAttribute). Sie erkennt das am ausgefüllten schwarzen Punkt am Ende der Kante. Als Attribut der Klasse ist das Ende einer binären Assoziation automatisch navigierbar und wird mit einer Pfeilspitze angezeigt18. Dies bedeutet, dass eine Auftragsposition den ihr zugeordneten Artikel kennt. Das Assoziationsende auftragsposition hingegen ist Bestandteil der Assoziation (Eigenschaft Association::ownedEnd) und auch nicht navigierbar.

18 Sind beide Enden einer binären Assoziation navigierbar, ist die Anzeige der Pfeilspitzen im Diagramm optional.


41

2.4.5 Simple Classifiers

2.4.5.1 DataTypes

Abbildung 40: Diagramm DataTypes aus der UML-Spezifikation

Abbildung 40 zeigt einen Ausschnitt aus dem Diagramm DataTypes aus der UML-Spezifikation. Es definiert die beiden nicht abstrakten Metaklassen DataType und PrimitiveType. Solche Datentypen unterscheiden sich von Klassen darin, dass es für ihre Instanzen keine Objektidentität gibt. Instanzen von Datentypen werden ausschließlich anhand ihres Wertes voneinander unterschieden. Einfache Datentypen (Metaklasse PrimitiveType) besitzen zudem interne Struktur.

Abbildung 41: Klassendiagramm mit zwei einfachen Datentypen


42

3 Übersicht ARIS UML Designer

In diesem Kapitel werden die einzelnen Komponenten von ARIS UML Designer und ihre wesentlichen Funktionalitäten kurz vorgestellt. In Abhängigkeit vom gewählten Tätigkeitsbereich in der Arbeitsumgebung stellt ARIS UML Designer verschiedene funktionale Komponenten zur Verfügung.

3.1 Festlegen des Tätigkeitsbereiches

Die Arbeitsumgebung und damit den Tätigkeitsbereich können Sie durch Auswahl des Menüpunktes Arbeitsumgebung wählen des ARIS-Menüs festlegen.

Abbildung 42: Menüpunkt zum Festlegen der Arbeitsumgebung

Dadurch wird ein Assistent zur Festlegung der Arbeitsumgebung gestartet.


43

Abbildung 43: Themenauswahl im Arbeitsumgebungs-Assistent

Im Gegensatz zu ARIS Architect und ARIS Designer stehen für bei ARIS UML Designer neben der UML-Modellierung keine weiteren lizenzabhängigen Themen zur Verfügung.

Abbildung 44: Tätigkeitsbereiche im Arbeitsumgebungs-Assistent


44

Durch Wahl des Tätigkeitsbereiches passen Sie den Funktionsumfang von ARIS UML Designer an die eigene Tätigkeit an. Prüfen erlaubt einen rein lesenden Zugriff auf die UML-Inhalte. Es ist nicht möglich, Änderungen an den Daten und Diagrammen vorzunehmen. Modellieren erlaubt das Bearbeiten der Inhalte. Analysieren & Managen schaltet einige weitergehende Funktionalitäten wie XML-Export und XML-Import frei. Konfigurieren & Administrieren umfasst administrative Tätigkeiten in ARIS wie die Bearbeitung von Methodenfiltern oder die Konfiguration der Wiederverwendungsmöglichkeiten von Geschäftsprozessobjekten in UML und die Erstellung und Bearbeitung von Skripten.


45

3.2 Explorer

Wenn Sie ARIS UML Designer starten, wird die Registerkarte Explorer angezeigt.

Abbildung 45: Registerkarte Explorer

Abbildung 45 zeigt die Registerkarte Explorer in ARIS UML Designer. Die Leiste Navigation auf der linken Seite beinhaltet zwei Bäume: den Explorer- und den Diagrammbaum. Auf der rechten Seite werden die Eigenschaften des im Baum markierten Elements oder Diagramms angezeigt. Alternativ können Sie die Eigenschaften in einem separaten Dialog anzeigen, wozu Sie im Kontextmenü eines Elements oder Diagramms auf Eigenschaften klicken.

Die Leiste Navigation kann mit Hilfe der Schaltfläche am rechten Rand des Fensters ausgeblendet werden, um mehr Platz für die Eigenschaftsseiten zu schaffen.

Mit Hilfe der Schaltfläche können Sie die Leiste Implizite Änderungen am rechten Fensterrand ein- und ausblenden. In diesem Bereich wird protokolliert, wenn eine Änderung eines UML-Elements implizite Änderungen bei anderen UML-Elementen zur Folge hat. In Kapitel 3.3.4 wird die Leiste Implizite Änderungen genauer vorgestellt.


46

Die Schaltfläche können Sie verwenden, um alle Bereiche außer den Eigenschaftsseiten auszublenden. Wenn Sie erneut auf die Schaltfläche klicken, wird der vorherige Zustand wieder hergestellt. Haben Sie die Registerkarte Explorer geschlossen, können Sie sie durch Wählen von Explorer des ARIS-Menüs wieder öffnen.

Abbildung 46: Menüpunkt zur Anzeige der Registerkarte Explorer


47

3.2.1 Leiste Navigation

3.2.1.1 Explorer-Baum

Der Explorer-Baum zeigt die von ARIS bekannte Gruppenhierarchie mit Diagrammen und Elementen. Im Baum werden sowohl Standard-ARIS- als auch UML-Inhalte angezeigt.

Abbildung 47: Gruppen, Diagramme und Elemente im Explorer-Baum

Ein grundlegender Unterschied zwischen ARIS und UML besteht darin, dass UML-Elemente im Gegensatz zu ARIS-Elementen Hierarchien bilden können, d. h., ein UML-Element kann andere UML-Elemente beinhalten, was im Explorer-Baum entsprechend sichtbar wird. Die Wurzel einer solchen Hierarchie von UML-Elementen bildet immer ein UML-Element vom Typ Package, Model oder Profile. Nur diese drei Typen können direkt in einer Gruppe enthalten sein. Grundsätzlich können in ARIS UML Designer nur neue Gruppen, UML-Elemente und UML-Diagramme erzeugt werden. ARIS-Elemente und ARIS-Diagramme werden im Explorer-Baum von ARIS UML Designer zwar angezeigt, können dort aber nicht neu angelegt werden.


48

3.2.1.2 Diagrammbaum

Der Diagrammbaum bietet eine nach Diagrammtypen gruppierte Sicht auf die Datenbank. Er bietet insbesondere bei kleinen bis mittelgroßen Datenbanken einen schnellen und unkomplizierten Zugriff auf Diagramme.

Abbildung 48: Diagrammbaum

Abbildung 48 zeigt die Registerkarte Explorer mit dem Diagrammbaum der Leiste Navigation. Unterhalb des Datenbankknotens befinden sich die beiden Metamodellknoten ARIS und UML. Diese beinhalten jeweils nach Diagrammtyp gruppiert die entsprechenden Diagramme.


49

3.2.2 Eigenschaftsseiten

Auf der rechten Seite der Registerkarte Explorer werden die Eigenschaften des in der Leiste Navigation ausgewählten Elements oder Diagramms auf mehreren Eigenschaftsseiten angezeigt. Die wichtigsten Eigenschaftsseiten werden im Folgenden vorgestellt. Spezielle Eigenschaftsseiten, die im Zusammenhang mit UML Profilen oder Verknüpfung zwischen Geschäftsprozess- und UML-Modellierung stehen, werden in den entsprechenden Kapiteln dieses Dokuments erläutert. Grundsätzlich werden alle Eigenschaftsseiten der Registerkarte Explorer auch im Eigenschaftsdialog des Elements oder des Diagramms angezeigt.

3.2.2.1 Information (Elemente, Diagramme, Gruppen)

Abbildung 49: Eigenschaftsseite Information

Die Eigenschaftsseite Information wird für Gruppen, Elemente und Diagramme angezeigt. Sie zeigt allgemeine und zum Teil ARIS-spezifische Eigenschaften des gewählten Elements oder Diagramms an. Die Eigenschaft Gruppe beinhaltet den vollständigen Pfad zum gewählten Element oder Diagramm, also nicht nur ARIS-Gruppen, sondern auch übergeordnete UML-Elemente.


50

3.2.2.2 Allgemein (Elemente, Diagramme, Gruppen)

Abbildung 50: Eigenschaftsseite Allgemein

Die Eigenschaftsseite Allgemein zeigt alle Eigenschaften, die im Metamodell als Attribute der Metaklasse des ausgewählten Elements sowie als Attribute des Metadiagramms des ausgewählten Diagramms spezifiziert sind. Im unteren Teil der Seite wird eine Beschreibung der jeweils ausgewählten Eigenschaft angezeigt. Eigenschaften, die laut Metamodell einen Wert haben müssen, sind mit einem Stern (*) gekennzeichnet.

Die Schaltfläche Beschreibungsbereich anzeigen/ausblenden dient zum Aus- und Einblenden des Beschreibungsbereichs. Die Eigenschaften sind nach den Metaklassen und Metadiagrammen gruppiert, denen sie im Metamodell als Attribute zugeordnet sind. Alternativ können Sie die Eigenschaften auch alphabetisch sortieren ohne ihre Metaklassen oder Metadiagramme anzeigen lassen (siehe Abbildung 51).

Die Schaltflächen Kategorisiert und Alphabetisch dienen zum Umschalten zwischen nach Metaklassen gruppierter und alphabetischer Anzeige der Eigenschaften.


51

Abbildung 51: Alphabetische Anzeige der Eigenschaften

Bis auf wenige Ausnahmen19 werden standardmäßig keine Eigenschaften angezeigt, die auf abgeleiteten Metaattributen basieren, d. h. deren Wert zur Laufzeit auf Basis anderer Eigenschaften und Elemente berechnet werden muss. Optional können abgeleitete Eigenschaften mit angezeigt werden.

Der Schaltfläche Abgeleitete Eigenschaften anzeigen aktiviert oder deaktiviert die Anzeige abgeleiteter Eigenschaften.

Abbildung 52: Eigenschaftsseite Allgemein mit Anzeige abgeleiteter Eigenschaften

Das Beispiel in Abbildung 52 zeigt, dass bei Anzeige abgeleiteter Eigenschaften für die Metaklasse Element, d. h. für alle UML-Elemente, auch die beiden Eigenschaften /ownedElement und /owner aufgeführt sind (siehe Abbildung 26: Diagramm Root der UML-Spezifikation mit ARIS-spezifischen Erweiterungen). Die Schriftfarbe ihrer Werte ist grau statt schwarz, was kennzeichnet, dass diese Eigenschaften nicht geändert werden können.

19 Solcher Ausnahmen sind z. B. Element::/description, MultiplicityElement::/lower und MultiplicityElement::/upper.


52

Wenn Sie auf den Wert einer Eigenschaft klicken, können Sie ihn bearbeiten. Die Art der Bearbeitungsmöglichkeit hängt vom Typ der Eigenschaft ab. Eigenschaften vom Typ String können Sie direkt in der Textzeile bearbeiten:

Abbildung 53: Texteingabe

Wenn Sie auf die Schaltfläche am rechten Rand klicken, wir ein spezieller Dialog zur Textbearbeitung geöffnet:

Abbildung 54: Editor für nicht-formatierbaren Text

Handelt es sich um eine Eigenschaft, die formatierten Text unterstützt, stehen in diesem Dialog die entsprechenden Formatierungswerkzeuge zur Verfügung. ARIS UML Designer unterstützt dies nur für Beschreibungen und Kommentare:

Abbildung 55: Editor für formatierbaren Text


53

Handelt es sich bei dem Wert der Eigenschaft um ein UML-Element, ist auch hier eine direkte Bearbeitung in der Textzeile möglich:

Abbildung 56: Textuelle Bearbeitung eines UML-Elements in den allgemeinen Eigenschaften

Oberhalb der Textzeile wird während der Bearbeitung eine entsprechende UML-Syntaxhilfe eingeblendet. Diese UML-spezifische textuelle Bearbeitungsmöglichkeit wird in ARIS UML Designer überall dort angeboten, wo das Element in dieser Textform angezeigt wird: im Explorer-Baum, in den Eigenschaftsseiten des übergeordneten Elements und in Diagrammen. Sie wird im Abschnitt Erzeugen neuer Elemente im Explorer genauer vorgestellt. Die Schaltfläche am rechten Rand dient zum Öffnen eines Kontextmenüs, das weitere Funktionalitäten für das Element anbietet:

Abbildung 57: Weitere Funktionalitäten für ein UML-Element in den allgemeinen Eigenschaften

In der Tabellenzeile mit dem Namen der Eigenschaft steht ebenfalls ein Kontextmenü zur Verfügung. Es dient dazu, entsprechende UML-Elemente neu anzulegen oder bereits existierende Elemente der Eigenschaft hinzuzufügen. Die Schaltfläche zum Aufklappen des Menüs steht zur Verfügung, sobald Sie in das entsprechende Tabellenfeld klicken.

Abbildung 58: Neu Anlegen von UML-Elementen in den allgemeinen Eigenschaften


54

3.2.2.3 Beziehungen (Elemente)

Abbildung 59: Eigenschaftsseite Beziehungen

Die Eigenschaftsseite Beziehungen zeigt alle Beziehungen des ausgewählten Elements zu anderen Elementen an. Dabei werden sowohl unmittelbare Beziehungen angezeigt als auch solche, die zwar im Diagramm als eine direkte grafische Verbindung zwischen zwei Elementen erscheinen, tatsächlich aber selbst eine Kette von Elementen und Beziehungen darstellen. Ein Beispiel für eine solche Beziehung ist die binäre Assoziation. Sie verknüpft zwei Klassifizierer mittels einer grafischen Kante im Diagramm, zum Beispiel einen Anwendungsfall mit einem Akteur. Diese Assoziationskante visualisiert jedoch keine direkte Beziehung, sondern eine Kette von Elementen bestehend aus zwei Assoziationsenden (UML-Typ Property) und einer Assoziation. Die Eigenschaftsseite Beziehungen des Anwendungsfalls zeigt sowohl die unmittelbare Beziehung des Anwendungsfalls zum Assoziationsende als eingehende Beziehung vom Typ typedElement, als auch die mittelbare Beziehung zum Akteur vom Typ Association. Sie können für jede Beziehung folgende Funktionalitäten aufrufen:

Beziehung entfernen

Gehe zu Vorkommen des verbundenen Elements im Explorer

Zeige Elementeigenschaften des verbundenen Elements Die beiden anderen Funktionalitäten stehen nur in der Designer-Komponente zur Verfügung und werden im entsprechenden Kapitel vorgestellt.

ARIS UML Designer‐Einführung

55

3.2.2.4 Verknüpfte Diagramme (Elemente)

Abbildung 60: Eigenschaftsseite Verknüpfte Diagramme

Hier werden alle Diagramme angezeigt, die mit dem gewählten Element verknüpft sind. Ist das gewählte Element in einem Diagramm ausgeprägt, wird es dort mit einem Hinterlegungssymbol angezeigt. Dieses unterstützt im Diagramm die Navigation zu den verknüpften Diagrammen.

Eine solche Verknüpfung kann auf drei Weisen erfolgen:

Besitz

Das Diagramm gehört dem gewählten Element. Im Explorer‐Baum erscheint es als Kindknoten des Elements.

Navigation

Das Diagramm wurde dem Element zum Zweck der Navigation hinterlegt. Eine solche Verknüpfung besitzt keinerlei Semantik. Sie dient nur dazu, eine einfache Navigationsmöglichkeit von einem Element zu einem Diagramm bereit zu stellen. Im Gegensatz zu Diagrammhinterlegungen im ARIS‐Standard existieren hier keinerlei Einschränkungen. Jeder Diagrammtyp kann mit jedem Elementtyp verknüpft werden.

Impliziter Besitz

Hier gehört das Diagramm nicht unmittelbar dem gewählten Element. Es handelt sich um ein Verhaltensdiagramm20, dessen Besitzer dem gewählten Element gehört. Möchte Sie z. B. den internen Ablauf eines Anwendungsfalls in einem Aktivitätsdiagramm modellieren, erzeugt Sie eine Aktivität als ownedBehavior des Anwendungsfalls und für die Aktivität ein entsprechendes Aktivitätsdiagramm. Dieses Aktivitätsdiagramm ist automatisch als impliziter Besitz mit dem Anwendungsfall verknüpft.

20 Impliziter Besitz wird nicht für Strukturdiagramme unterstützt. Besitzt z. B. ein Kindpaket eines Paketes Klassendiagramme, sind diese nicht mit dem Paket verknüpft.


56

Sie können folgende Funktionalitäten aufrufen:

Diagramm hinterlegen

Zugeordnetes Diagramm entfernen (nur für Hinterlegungen vom Typ Navigation)

Diagramm öffnen

Gehe zu Vorkommen des Diagramms im Explorer

Diagrammeigenschaften anzeigen


57

3.2.2.5 Ausprägungen in Diagrammen (Elemente)

Abbildung 61: Eigenschaftsseite Ausprägungen in Diagrammen

Die Eigenschaftsseite Ausprägungen in Diagrammen listet alle Diagramme auf, in denen das gewählte Element enthalten ist. Sie können für jedes Diagramm folgende Funktionalitäten aufrufen:

Diagramm öffnen

Gehe zu Vorkommen des Diagramms im Explorer

Diagrammeigenschaften anzeigen


58

3.2.2.6 Ausprägungen (Diagramme)

Abbildung 62: Eigenschaftsseite Ausprägungen

Die Eigenschaftsseite Ausprägungen listet alle Elemente auf, die im gewählten Diagramm dargestellt sind. Sie können für jedes Element folgende Funktionalitäten aufrufen:

Gehe zu Vorkommen des Elements im Explorer

Elementeigenschaften anzeigen


59

3.2.2.7 Verbundene Objekte (Diagramme)

Abbildung 63: Eigenschaftsseite Verbundene Objekte

Die Eigenschaftsseite Verbundene Objekte eines Diagramms zeigt das Element, welches das Diagramm besitzt und optional auch den impliziten Besitzer, sofern es sich um ein Verhaltensdiagramm handelt. Sie können für jedes Element folgende Funktionalitäten aufrufen:

Gehe zu Vorkommen des Elements im Explorer

Elementeigenschaften anzeigen


60

3.2.3 Eigenschaftsdialog

Abbildung 64: Eigenschaftsdialog eines UML-Elements

Wenn Sie den Eigenschaftsdialog eines Elementes oder Diagramms öffnen, beinhaltet er im Wesentlichen die gleichen Eigenschaftsseiten, die auch in der Registerkarte Explorer angezeigt werden. Zusätzlich gibt es hier lediglich eine Eigenschaftsseite zum Bearbeiten der Beschreibung des Elements oder Diagramms (siehe Abbildung 65).

Abbildung 65: Eigenschaftsseite zum Anzeigen und Bearbeiten der Elementbeschreibung


61

3.2.4 Anlegen neuer Elemente im Explorer

Neue Elemente können im Explorer-Baum durch Aufruf des Kontextmenüeintrags Neues Modellelement angelegt werden. Dieser öffnet ein Untermenü, das die Elementtypen enthält, die innerhalb des ausgewählten Elements angelegt werden dürfen. Abbildung 66 zeigt dieses Kontextmenü für eine Gruppe. Es stehen die vier Typen Gruppe, Model, Package und Profile zur Verfügung.

Abbildung 66: Kontextmenü für das Erzeugen eines neuen Elements in einer Gruppe

Wenn Sie dieses Kontextmenü für ein UML-Element aufrufen, kann die Anzahl möglicher Elementtypen, die Sie innerhalb des ausgewählten Elements anlegen können, die Kapazität des Untermenüs übersteigen. In diesem Fall werden nur die wichtigsten Elementtypen direkt im Untermenü angeboten. Da die maximale Anzahl an Kontextmenüeinträgen von der Bildschirmgröße und der Bildschirmauflösung abhängt, können Sie in den globalen Optionen von ARIS UML Designer festlegen, wie viele Menüeinträge ein solches Kontextmenü maximal enthalten darf21.

21 ARIS > Optionen > UML > Explorer > Menü konfigurieren


62

Abbildung 67: Kontextmenü für das Erzeugen eines neuen Elements in einem UML-Paket

Abbildung 67 zeigt das Kontextmenü zum Anlegen eines neuen UML-Elements in einem UML-Paket. Zusätzlich zum Elementtyp enthält jeder Menüpunkt auch die Eigenschaft, unter der das neue Element beim übergeordneten Element angelegt wird. Im vorliegenden Beispiel würden die meisten Elemente als packagedElement im Paket angelegt werden (siehe auch Abbildung 28: Diagramm Namespaces der UML-Spezifikation). Wenn Sie den Menüpunkt Weitere wählen, wird der Dialog Element anlegen geöffnet, der alle UML-Typen aufführt, die innerhalb eines Pakets angelegt werden können, aber nicht im Kontextmenü enthalten sind (siehe Abbildung 67).

Abbildung 68: Dialog mit Elementtypen, die nicht im Kontextmenü enthalten sind


63

Der Inhalt des Untermenüs von Neues Modellelement lässt sich individuell für jeden UML-Elementtyp anpassen, sodass Sie die aus Anwendersicht wichtigsten Elementtypen in das Menü aufnehmen und die eher unwichtigen aus dem Menü entfernen können. Durch Klicken auf den in Abbildung 67 gezeigten Menüpunkt Menü konfigurieren wird der entsprechende Dialog zur Menükonfiguration geöffnet.

Abbildung 69: Dialog zur Konfiguration des Untermenüs von Neues Modellelement

Abbildung 69 zeigt den Dialog zur Konfiguration des Kontextmenüs Neues Modellelement. Die rechte Spalte enthält alle Elementtypen, die direkt im Kontextmenü enthalten sind, und die linke diejenigen, die bei Auswahl des Menüpunkts Weitere in einem Dialog zur Auswahl angeboten werden. Ist Alphabetisch sortieren aktiviert, werden die Elemente im Kontextmenü alphabetisch sortiert angezeigt. Andernfalls können Sie die Reihenfolge der Elemente im Kontextmenü individuell festlegen. Die Elementtypen im Dialog werden unabhängig von dieser Einstellung immer alphabetisch sortiert angezeigt. Wenn Sie ein Element im Explorer neu angelegt haben, wird automatisch die textuelle UML-spezifische Bearbeitung für das Element aktiviert.

Abbildung 70: Textuelle Bearbeitung eines UML-Elements im Explorer


64

In der Syntaxhilfe ist der Bereich hervorgehoben, auf den sich die aktuelle Cursor-Position im Textfeld bezieht. Bezieht sich der aktuelle Textteil auf ein anderes UML-Element, werden alle bereits aus der Datenbank geladenen UML-Elemente in einer Auswahlliste eingeblendet, deren Namen mit dem eingegebenen Text beginnt und die vom passenden Typ sind:

Abbildung 71: Auswahlliste mit passenden Elementen bei der textuellen Bearbeitung

Wird ein UML-Element referenziert, das noch nicht existiert oder das noch nicht aus der Datenbank geladen wurde, wird sein Name grün unterschlängelt angezeigt:

Abbildung 72: Unbekanntes UML-Element bei der textuellen Bearbeitung

Beendet Sie in einem solchen Fall die textuelle Bearbeitung, wird jedes unbekannte Element im Dialog Referenz zuordnen auflistet und die Möglichkeit angeboten, die Elemente neu anzulegen oder in der Datenbank nach passenden Elementen zu suchen.

Abbildung 73: Dialog mit unbekannten Referenzen bei der textuellen Bearbeitung


65

Ohne weitere Eingabe im Dialog der Abbildung 73 würde bei Klicken auf OK als Typ des Attributes Artikelbeschreibung eine neue Klasse mit Name Zeichenfolge angelegt werden. In der Spalte Metaklasse können Sie für den Fall, dass das Element neu angelegt werden soll, seinen genauen Typ festlegen.

Abbildung 74: Auswahl des Typs des neu anzulegenden Elements

Die Spalte Status beschreibt, ob das Element neu angelegt oder ob ein bereits existierendes Element aus der Datenbank zugeordnet wird. Wenn Sie auf die Schaltfläche am rechten Rand klicken, werden beide Möglichkeiten zur Auswahl angeboten.

Abbildung 75: Auswahlmöglichkeiten zum neu Anlegen oder Verwenden eines UML Elements

Wenn Sie Verwenden wählen, wird der Dialog Elemente wählen zur Suche nach dem Element in der Datenbank.

Abbildung 76: Suchdialog


66

3.2.5 Erzeugen neuer Diagramme im Explorer

UML-Diagramme sind immer in einem UML-Element enthalten. Es ist nicht möglich, ein UML-Diagramm direkt innerhalb einer ARIS-Gruppe anzulegen. UML-Elemente vom Typ Package, Model, Profile oder Class22 können beliebige Strukturdiagramme beinhalten. Verhaltensdiagramme hingegen sind immer im dargestellten Element enthalten, d. h. Zustandsdiagramme in Zustandsautomaten, Interaktionsdiagramme23 in Interaktionen und Aktivitätsdiagramme in Aktivitäten. Neue Diagramme können im Explorer-Baum durch Aufruf des Kontextmenüeintrags Neues Diagramm angelegt werden.

Abbildung 77: Kontextmenü zum Erzeugen neuer UML-Diagramme

Abbildung 77 zeigt das Kontextmenü zum Anlegen eines neuen Diagramms in einem UML-Paket. Das Kontextmenü bietet die gleichen Konfigurationsmöglichkeiten wie das Kontextmenü zum Anlegen neuer Elemente.

22 Dies gilt auch für alle Elemente, deren Metaklasse von Class abgeleitet ist, wie z. B. Component oder AssociationClass. 23 Kommunikations-, Sequenz- und Zeitablauf-Diagramme bezeichnet man als Interaktionsdiagramme.


67

3.3 Designer

Wenn Sie ein UML-Diagramm öffnen, wird es in der Designer-Komponente angezeigt.

Abbildung 78: Designer-Komponente

Die Designer-Komponente ist in vier Bereiche unterteil: In die Modellierungsfläche und die Leisten Navigation, Eigenschaften und Symbole. Die Leisten können ausgeblendet werden, um mehr Platz für die Diagrammdarstellung zu schaffen. Zusätzlich können Sie die Leisten durch Ziehen mit gedrückter Maustaste anders angeordnet.


68

Am rechten Rand des Fensters stehen folgende Schaltflächen zur Verfügung

Blendet die Leiste Navigation aus und ein

Blendet die Leiste Symbole aus und ein

Blendet die Leiste Eigenschaften aus und ein

Blendet die Leiste Implizite Änderungen ein und aus Blendet alle Leisten aus

Blendet alle Leisten ein Für die nachfolgend gezeigten Bildschirmfotos wurden die einzelnen Leisten jeweils so angeordnet, dass sich eine sinnvolle, an die in diesem Dokument zur Verfügung stehenden Seitenbreite angepasste Darstellung ergibt.


69

3.3.1 Leiste Navigation

Neben den beiden aus der Registerkarte Explorer bekannten Bäumen enthält die Leiste Navigation die Diagrammübersicht und die Liste der im Diagramm dargestellten Elemente.

3.3.1.1 Diagrammübersicht

Abbildung 79: Diagrammübersicht

Die Diagrammübersicht zeigt schematisch das gesamte Diagramm und kennzeichnet den Teil durch ein weißes Rechteck, der in der Modellierungsfläche sichtbar ist. Durch Verschieben des Rechtecks können nicht sichtbare Ausschnitt des Diagramms in der Modellierungsfläche in den sichtbaren Bereich verschoben werden.


70

3.3.1.2 Visualisierte Elemente

Abbildung 80: Visualisierte Elemente

Die Seite Visualisierte Elemente zeigt eine Liste aller im Diagramm dargestellten UML-Elemente an. Durch die Wahl eines Elementes der Liste wird das Element auch im Diagramm gewählt und der Ausschnitt der Modellierungsfläche so verschoben, dass das Element sichtbar wird.


71

3.3.2 Leiste Eigenschaften

Die Leiste Eigenschaft zeigt im Wesentlichen die gleichen Eigenschaftsseiten an wie die Registerkarte Explorer. Da der zur Verfügung stehende Platz jedoch kleiner ist, können Sie in den globalen Optionen festlegen, welche Eigenschaftsseiten in der Designer-Komponente angezeigt werden sollen. Es werden jeweils die Eigenschaften des aktuell in der Leiste Navigation oder im Diagramm gewählten Elements angezeigt.

3.3.2.1 Format

Abbildung 81: Eigenschaftsseite Format des im Diagramm ausgewählten Elements

Die Eigenschaftsseite Format wird für Elemente in Diagrammen angezeigt. Sie zeigt sämtliche Darstellungsoptionen des gewählten Elements. Sind mehrere Elemente gewählt, zeigt sie die gemeinsamen Darstellungsoptionen der gewählten Elemente. Dies erlaubt es, die grafische Darstellung mehrerer Elemente gleichzeitig zu bearbeiten. Genau wie bei den Allgemeinen Eigenschaften wird auch hier eine kurze Beschreibung der jeweils gewählten Darstellungsoption am unteren Rand angezeigt und Sie können zwischen einer thematischen Gruppierung und einer alphabetischen Anzeige der Darstellungsoptionen wählen. Diese Darstellungsoptionen umfassen sowohl allgemeine grafische Eigenschaften wie Farben, Linienstärke oder Schriftformat, als auch UML-spezifische Optionen, die festlegen, welche Details die jeweiligen Elemente im Diagramm anzeigen sollen.


72

3.3.3 Leiste Symbole

Abbildung 82: Leiste Symbole eines Klassendiagramms

Die Leiste Symbole dient zum Anlegen von Elementen und Beziehungen im Diagramm. Im Gegensatz zu ARIS Architect und ARIS Designer beinhaltet sie auch Kantensymbole. Wen Sie den Mauszeiger eine kurze Zeit auf einem Symbol platzieren, wird eine Beschreibung des Symbols eingeblendet.

Abbildung 83: Symbolbeschreibung


73

Mit den beiden Schaltflächen Symbole mit Namen anzeigen und Symbole ohne Namen anzeigen können Sie die Symbolnamen in der Leiste Symbole ein- und ausblenden.

Abbildung 84: Leiste Symbole mit ausgeblendeten Symbolnamen

Durch Wählen des Kontextmenüeintrags Symbol entfernen kann ein Symbol aus der Leiste Symbole entfernt werden.

Abbildung 85: Kontextmenü in der Leiste Symbole

Mit Hilfe der Schaltfläche Symbole hinzufügen oder durch Klicken auf den Kontextmenüeintrag Symbole hinzufügen können Sie den Dialog zur Konfiguration der Leiste Symbole öffnen.


74

Abbildung 86: Dialog zur Konfiguration der Leiste Symbole

Der Dialog beinhaltet eine Liste der verfügbaren Symbole und eine Liste der in der Leiste Symbole enthaltenen Symbole, jeweils nach Diagrammtyp gruppiert. Im Fall von Strukturdiagrammen wie dem Klassendiagramm können Sie der Leiste Symbole beliebiger UML-Diagrammtypen hinzufügen.


75

Ein Texteingabefeld oberhalb der Liste erlaubt es, die Liste nach den Symbolen zu filtern, deren Name den eingegebenen Text enthält. Die entsprechenden Diagrammknoten werden dabei in der Liste automatisch aufgeklappt, sodass auf diese Weise ein schneller Zugriff auf das gesuchte Symbol möglich ist (siehe Abbildung 87).

Abbildung 87: Alle verfügbare Symbole, deren Name den Text Call beinhaltet

Zusätzlich bietet die Leiste Symbole von ARIS UML Designer die Möglichkeit, besonders oft benutzte Symbole zum schnelleren Zugriff im oberen Bereich der Leiste Symbole unabhängig von ihrem Diagrammtyp zu gruppieren.

Abbildung 88Kontextmenüeintrag Den bevorzugten Symbolen hinzufügen


76

Dazu wählen Sie für das entsprechende Symbol in der Leiste Symbole den Kontextmenüeintrag Den bevorzugten Symbolen hinzufügen.

Abbildung 89: Bevorzugte Symbole

Das Symbol wird nun zusätzlich im oberen Bereich der Leiste Symbole unter Bevorzugte Symbole angezeigt.

Durch Klicken auf Zusätzliches Symbol ausprägen können Sie in einem Diagramm ein Element anlegen, dessen Symbol nicht dauerhaft in der Leiste Symbole aller Diagramme desselben Typs enthalten sein soll. Der Dialog Ausprägung anlegen wird geöffnet (siehe Abbildung 90).

Abbildung 90: Dialog zur Auswahl des Symbols

Der Dialog listet ebenfalls nach Diagrammtyp gruppiert alle verfügbaren Symbole auf und bietet die gleiche Filterung via Texteingabe wie der Dialog zur Konfiguration der Leiste Symbole.


77

Beinhaltet ein Diagramm Ausprägungen von Symbolen, die nicht in der Leiste Symbole des Diagrammtyps enthalten sind, werden diese in der Leiste Symbole des betroffenen Diagramms im Abschnitt Diagrammspezifische Symbole der Leiste Symbole angezeigt.

Abbildung 91: Diagrammspezifische Symbole


78

3.3.4 Leiste Implizite Änderungen

Abbildung 92: Leiste Implizite Änderungen

Die Leiste Implizite Änderungen protokokkiert Änderungen vonUML-Elementen und Diagrammen, die sich implizit aufgrund anderweitiger Änderungen ergeben. Im Folgenden wird ein typisches Beispiel für eine solche implizite Änderung gezeigt.

Abbildung 93: Binäre Assoziation deren Enden Attribute der beteiligten Klassen sind

Abbildung 93 zeigt ein Klassendiagramm mit einer binären Assoziation zwischen den Klassen Auftrag und Auftragsposition. Die beiden Enden der Assoziation sind als Attrubte der beteiligten Klasse navigierbar. Aus diesem Grund ist das Assoziationsende position im Explorer-Baum ein Kind der Klasse Auftrag. Es wird dort als Text position:auftragsposition[1..*]{ordered} mit seinem Typ angezeigt, der Klasse Auftragsposition.

Abbildung 94: Umbenennen des Assoziationsendes mit Löschen der Typangabe


79

Benennt man nun dieses Assoziationsende um und löscht dabei auch die Typangabe, hat dies zur Folge, dass das Assoziationsende position nicht mehr mit der Klasse Auftragsposition verknüpft ist. Dadurch wird auch die Assoziationskante aus dem Diagramm entfernt, was eine implizite und für den Anwender nicht immer direkt erkennbare Änderung darstellt. Diese implizite Änderung wird in der Leiste Implizite Änderungen protokolliert.

Abbildung 95: Protokollierte implizite Änderung

Die Protokollierung impliziter Änderungen kann auf der globalen Optionsseite UML -> Allgemein ein- und ausgeschaltet werden.


80

3.3.5 Modellierung

Grundsätzlich basiert die grafische Modellierung in ARIS UML Designer auf den gleichen Prinzipien wie in ARIS Architect und ARIS Designer. Aus diesem Grund liegt der Schwerpunkt dieses Kapitels auf den modellierungsspezifischen Besonderheiten von ARIS UML Designer, während die Grundlagen grafischer Modellierung in ARIS nur kurz vorgestellt werden.

3.3.5.1 Erzeugen neuer Knotenpräsentationen

Im Diagramm können neue Knotenpräsentationselemente erzeugt werden, indem Sie zunächst durch Mausklick das entsprechende Symbol in der Leiste Symbole wählen.

Abbildung 96: Auswahl des Knotensymbols Class

Wenn Sie danach den Mauszeiger auf die Modellierungsfläche führen, wird am Mauszeiger eine Vorschau der neu zu erzeugenden Präsentation angezeigt.

Abbildung 97: Mauszeiger mit Vorschau einer Klassenpräsentation

Durch Klicken auf die Modellierungsfläche wird an dieser Stelle die Präsentation angelegt und ein Texteingabefeld zur Eingabe des Namens angezeigt.

Abbildung 98: Neu platzierte Klasse mit Texteingabefeld für den Namen

Dieses Texteingabefeld enthält initial den entsprechenden Symbolnamen, eventuell ergänzt um einen Unterstrich und eine Zahl (_1, _2 usw.), falls schon Elemente desselben Typs mit diesem Namen existieren. Der Inhalt des Texteingabefeldes wird übernommen, wenn Sie die Eingabe durch Drücken der Eingabetaste oder durch Mausklick an eine beliebige Stelle in ARIS UML Designer außerhalb des Texteingabefeldes beendet. Abhängig von Ihrer Einstellung in den globalen Optionen kann die Texteingabe auch durch


81

gleichzeitiges Drücken von Strg- und Eingabetaste abgeschlossen werden24. Beenden Sie die Eingabe hingegen mit der Taste Esc, wird der ursprüngliche Name beibehalten. Haben Sie im Texteingabefeld den Namen eines bereits existierenden Elements gleichen Typs eingegeben, wird der Dialog Element wählen geöffnet, der nachfragt, ob für das bereits existierende Element im Diagramm eine neue Präsentation anlegt werden soll oder ob Sie ein neues Element mit diesem Namen anlegen möchten (siehe Abbildung 99).

Abbildung 99: Dialog beim Neuanlegen nach Eingabe des Namens von existierenden Elementen

24 Siehe ARIS > Optionen > UML > Designer - Allgemein > Zeilenumbruch per Eingabetaste


82

Sie können eine neue Präsentation für ein existierendes Element auch dadurch anlegen, indem Sie das Element vom Explorer-Baum auf die Modellierungsfläche ziehen oder es vom Explorer-Baum in die Zwischenablage kopieren und im Diagramm aus der Zwischenablage einfügen. Existieren mehrere mögliche Symbole, mit denen das Element im Diagramm dargestellt werden kann, werden Sie gefragt, welches dieser Symbole Sie verwenden möchten (siehe Abbildung 100). Kopieren Sie hingegen eine Präsentation des Elements aus einem Diagramm in die Zwischenablage und fügen es aus dieser in ein Diagramm ein, wird nicht nachgefragt, da in diesem Fall auch alle Präsentationseigenschaften wie Symbol, Farbe, Größe des Originals übernommen werden.

Abbildung 100: Dialog zur Nachfrage, welches Symbol verwendet werden soll


83

3.3.5.2 Neue Kantenpräsentation anlegen

Zum Anlegen einer Kantenpräsentation wählen Sie zunächst das entsprechende Kantensymbol in der Leiste Symbole.

Abbildung 101: Auswahl des Kantensymbols Association

Wenn Sie den Mauszeiger zum gewünschten Quellelement im Diagramm führen, wird der Ansatzpunkt grafisch angezeigt, der dem Mauszeiger am nächsten liegt.

Abbildung 102: Anzeige des Kantenansatzpunktes am Quellelement

Ein Mausklick an dieser Stelle legt den Startpunkt der Kante fest. Ausgehend von diesem Punkt wird dann eine Vorschau der Kante bis zur aktuellen Mauszeigerposition angezeigt. Wenn Sie den Mauszeiger zum gewünschten Zielelement führen, wird auch dort der nächstmögliche Ansatzpunkt grafisch angezeigt.

Abbildung 103: Anzeige des Kantenansatzpunktes am Zielelement und Kantenvorschau

Durch Mausklick am Zielelement wird die Kante angelegt.


84

Wenn schon eine Beziehung desselben Typs zwischen den beiden Quell- und Zielelement existiert und mehr als eine Beziehung dieses Typs zwischen beiden Elementen erlaubt ist, wird per Dialog nachgefragt, ob für die bereits existierende Beziehung eine neue Kantenpräsentation oder eine neue Beziehung angelegt werden soll (siehe Abbildung 104).

Abbildung 104: Dialog beim Anlegen einer Assoziation zwischen zwei Klassen, zwischen den bereits eine Assoziation existiert

Alternativ zur Auswahl eines bestimmten Kantensymbols können Sie auch das allgemeine Kantensymbol der Leiste Symbole verwenden, um eine Kante im Diagramm zu anzulegen.

Abbildung 105: Allgemeines Kantensymbol

In diesem Fall erfolgt beim Anlegen der Kante nach dem Klicken auf das Zielelement eine Abfrage nach dem konkreten Kantentyp, indem eine Auswahlliste eingeblendet wird.


85

Abbildung 106: Auswahlliste mit Kantentypen

Durch Klick auf der Funktionsleiste Start wird der Kantenmodus ein- und ausgeschaltet. Ist der Kantenmodus aktiv, werden mögliche Kantenansatzpunkte im Diagramm automatisch angezeigt, sobald sich der Mauszeiger in ihrer Nähe befindet. Eine vorherige Wahl des allgemeinen oder eines speziellen Kantensymbols in der Leiste Symbole ist dann nicht notwendig.

3.3.5.3 Löschen von Präsentationen und Elementen

In ARIS UML Designer enthält das Kontextmenü einer Ausprägung zwei verschiedene Einträge zum Löschen:

Abbildung 107: Löschfunktionalitäten im Kontextmenü

Löschen löscht lediglich die Ausprägung im Diagramm. Das dargestellte Element oder die dargestellte Beziehung bleiben im Modell enthalten, d. h. in der Datenbank verfügbar.

Element löschen löscht nicht nur die Ausprägung, sondern auch das Element selbst oder die dargestellte Beziehung im Modell.


86

3.3.5.4 Minisymbolleiste

Wenn Sie auf eine Knotenpräsentation klicken, wird neben ihr eine kleine Symbolleiste eingeblendet. Diese kann Knoten- und Kantensymbole beinhalten und kann von Ihnen individuell für jedes Symbol angepasst werden.

Abbildung 108: Minisymbolleiste

Wenn Sie ein Knotensymbol aus der Minisymbolleiste wählen, können Sie ein entsprechendes Element im Diagramm anlegen, das automatisch mit eine Kante zum markierten Knotenpräsentation verknüpft wird. Sind zwischen den beiden Elementen mehrere Kantentypen erlaubt, wird eine Auswahlliste eingeblendet. In diesem Fall wählen Sie zuerst den Kantentyp und klicken dann in der Modellierungsfläche auf die Position, wo Sie die Knotenpräsentation anlegen möchten.

Abbildung 109: Knoten- und Kantenvorschau mit Kantentypauswahl nach Klick auf das Symbol Comment in der Minisymbolleiste

Wenn Sie ein Kantensymbol der Minisymbolleiste wählen, wird die Knotenpräsentation, für die die Minisymbolleiste angezeigt wird, als Quellelement der Kante verwendet und Sie brauchen im Diagramm nur noch auf das Zielelement zu klicken, um die Kante anzulegen.


87

Durch Wählen des Kontextmenüeintrags Symbol entfernen können Sie ein Symbol aus der Minisymbolleiste entfernen. Durch Wählen von Symbol hinzufügen oder durch Klicken auf Symbole hinzufügen wird der Dialog zum Hinzufügen eines Symbols angezeigt.

Abbildung 110: Kontextmenü der Minisymbolleiste


88

3.3.5.5 Modellierung und Hierarchie im Explorer

Eine Reihe von Kantentypen in ARIS UML Designer stellen grafisch dar, dass ein Element in einem anderen Element enthalten ist.

Abbildung 111: Beziehung Owning package zwischen einer Klasse und dem Paket, in dem sie enthalten ist

Das Diagramm in Abbildung 111 zeigt eine solche Beziehung vom Typ Owning package zwischen der Klasse Auftrag und dem Paket Klassen. Diese drückt aus, dass die Klasse in dem Paket enthalten ist, was Sie auch anhand der Hierarchie im Explorer-Baum erkennen können25.

25 Siehe auch Abbildung 28 im Kapitel Namespaces.


89

Was geschieht, wenn Sie eine weitere Kante dieses Typs von der Klasse Auftrag zum Paket Anwendungsfälle erzeugen, zeigt Abbildung 112:

Die ursprüngliche Beziehung zwischen der Klasse Auftrag und dem Paket Klassen wird gelöscht.

Im Explorer‐Baum wird die Klasse Auftrag in das Paket Anwendungsfälle verschoben.

Abbildung 112: Nach dem Erzeugen einer zweiten Owning package‐Beziehung


90

3.3.5.6 Grafische Einbettungen

Vielfach kann in Diagrammen von ARIS UML Designer der Besitz eines Elementes durch ein anderes auch dadurch ausgedrückt werden, dass eine Präsentation des Elements grafisch in die Präsentation des besitzenden Elements eingebettet ist. In einigen Fällen kann eine grafische Einbettung auch eine Beziehung darstellen, die keinen Besitz repräsentiert. Allen grafischen Einbettungen in ARIS UML Designer ist jedoch gemeinsam, dass sie immer eine Beziehung zwischen den Elementen auf Definitionsebene repräsentieren. Beim Neuanlegen oder beim Verschieben eines Elements im Diagramm werden Präsentationen, in die das Element eingebettet werden kann, durch einen Rahmen gekennzeichnet, wenn sich der Mauszeiger innerhalb des potentiellen Schachtelungscontainers befindet.

Abbildung 113: Grafische Kennzeichnung eines Pakets als potentieller Schachtelungscontainer beim Neuanlegen einer Klasse

Nachdem die Klasse als geschachtelte Präsentation im Paket angelegt wurde, ist sie auch im Explorer-Baum im Paket enthalten.

Abbildung 114: Im Paket eingebettete Klasse

Die Darstellung einer Klasse in einem Diagramm als in einem Paket eingebettetes Element stellt eine alternative Notation zu der in Abbildung 111 gezeigt Verknüpfung mit einer Owning package-Kante dar. Es existieren einige Optionen, die das Verhalten von ARIS UML Designer beim Modellieren mit Einbettungen beeinflussen.


91

Die ersten Optionen26 betreffen den Umgang mit den Beziehungen, die der grafischen Einbettung zugrunde liegen.

Abbildung 115: Optionen für Einbettungen

Wenn die beiden Optionen Dialog anzeigen, wenn … aktiviert sind, erfolgt auch jeweils eine entsprechende Nachfrage beim Modellieren. Verschieben Sie in diesem Fall die Klasse in Abbildung 114 aus dem Paket heraus auf den Diagrammhintergrund, wird der Dialog Einbettung aufheben geöffnet:

Abbildung 116: Dialog Einbettung aufheben

Bei Wählen von Einbettungsbeziehung löschen wird die Klasse in das Paket verschoben, in der das Diagramm liegt. Bei Wählen von Einbettungsbeziehung anzeigen, wird eine Owning package-Beziehung zwischen der Klasse und dem Paket angezeigt. Bei der Option Einbettungsbeziehung beibehalten und nicht anzeigen wird keine Beziehung im Diagramm angezeigt; die Klasse bleibt auf Definitionsebene im Paket enthalten. Eine weitere Option bezieht sich auf den Fall, dass ein Element auf verschiedene Arten in ein anderes eingebettet werden kann.

Abbildung 117: Option für das Anlegen eines eingebetteten Elements

26 Siehe ARIS > Optionen > UML -> Designer – Allgemein > Einbettungen


92

In seltenen Fällen kann ein UML-Element ein anderes Element eines bestimmten Typs auf mehr als eine Art besitzen, ohne dass der semantische Unterschied zwischen den verschiedenen Arten von Besitz offensichtlich und für den Anwender wirklich relevant ist. Ein Beispiel hierfür ist der UML-Typ Constraint.

Abbildung 118: Ausschnitt aus dem UML-Metamodell mit den Metaklassen Package und Constraint

Jedes UML-Element, dessen Typ von der Metaklasse Namespace erbt, kann über seine Eigenschaft ownedRule Constraints besitzen. Jedes UML-Paket kann über seine Eigenschaft packedElement Elemente besitzen, deren Typ von der Metaklasse PackagedElement erbt. Da die Metaklasse Constraint von PackagedElement erbt, können Sie einen Constraint in ein Paket entweder als ownedRule oder als packagedElement einfügen. Wenn die Option Besitzereigenschaft beim Anlegen von Eigenen Elementen automatisch festlegen aktiviert ist, erfolgt beim Anlegen eines Constraints in einem Paket keine Nachfrage, ob der Constraint als ownedRule oder als packagedElement im Paket enthalten sein soll. Er wird in diesem Fall automatisch als ownedRule im Paket angelegt. Sie können die Art der Einbettung auch nachträglich durch Aufruf des Kontextmenüeintrags Einbettungsart ändern für das eingebettete Element ändern. Der Dialog Einbettungstyp wählen wird zur Auswahl des entsprechenden Einbettungstyps geöffnet.

Abbildung 119: Dialog zur Änderung des Einbettungstyps für einen in einem Paket enthaltenen Constraint


93

3.3.5.7 Textuelle Einbettungen

Abbildung 120: Klasse mit zwei Attributen

Abbildung 120 zeigt die UML-Notation einer Klasse mit zwei Attributen. Die Besonderheit von UML im Vergleich zum ARIS-Standard ist, dass hier eine einzige Ausprägung mehrere Elemente und deren Beziehungen darstellt: eine Klasse (Artikel), zwei Attribute (Artikelnummer und Bezeichnung), einen Datentyp (String), zwei Beziehungen vom Typ Class::ownedAttribute und zwei Beziehungen vom Typ TypedElement::type. Die beiden Attribute sind textuell in die Klassenpräsentation eingebettet und können als solche auch einzeln gewählt werden. Der erste Klick auf die Klasse wählt die Klasse selbst (wie in Abbildung 120 ersichtlich). Ein weiterer Klick auf ein Attribut innerhalb der Klasse wählt das Attribut. Der Eigenschaftsbereich zeigt in diesem Fall nicht mehr die Eigenschaften der Klasse an, sondern die des Attributs.

Abbildung 121: Klasse mit ausgewähltem Attribut

Viele Funktionalitäten, die ARIS UML Designer für Ausprägungen anbietet, sind auch für textuell eingebettete Elemente verfügbar. So können Sie diese z. B. in ein anderes Element verschieben, kopieren, den Eigenschaftsdialog aufrufen und nicht zuletzt textuell bearbeiten, indem Sie ein drittes Mal auf diese Klicken oder die Taste F2 drücken.

Abbildung 122: Textuelle Bearbeitung eines Attributs im Designer


94

Darüber hinaus können Sie im Designer für ein Element auch textuell eingebettete Elemente via Kontextmenü neu anlegen:

Abbildung 123: Anlegen einer neuen Operation via Kontextmenü


95

3.3.5.8 Modellierung in Gruppierungen

ARIS UML Designer bietet die Möglichkeit, Elemente innerhalb von Gruppierungen zu bearbeiten, ohne dass dazu die Gruppierung aufgehoben werden muss.

Abbildung 124: Erzeugen einer Gruppierung

Gruppierungen werden durch Wählen des Kontextmenüeintrags Gruppieren erstellt.

Abbildung 125: Gruppierte Elemente

Eine solche Gruppierung können Sie als Ganzes im Diagramm verschieben, ohne vorher jedes darin enthaltene Element wählen zu müssen. Sie können jedoch weiterhin einzelne Elemente innerhalb der Gruppierung wählen, um ihre Eigenschaften zu bearbeiten. Befindet sich ein Element in einer Gruppierung und die Gruppierung ist noch nicht gewählt, erfolgt die Auswahl der Gruppierung durch den ersten Klick auf das Element. Ein weiterer Klick auf das Element markiert dann das Element selbst, wie in Abbildung 126 gezeigt.


96

Abbildung 126: Auswahl eines Elements innerhalb einer Gruppierung

Darüber hinaus ist es möglich, Elemente innerhalb einer Gruppierung zu verschieben.

Abbildung 127: Verschieben eines Elementes innerhalb einer Gruppierung


97

3.3.5.9 UML-spezifische Modellierungsunterstützung

Eine Reihe von ARIS UML Designer-Funktionalitäten dienen dazu, typische Anwendungsfälle bei der UML-Modellierung, die normalerweise mehrere manuelle Bearbeitungsschritte benötigen, mit wenigen Klicks zu erledigen. Dies reicht von einfachen Anwendungsfällen, wie dem Setzen der Multiplizität von Assoziationsenden auf Standardwerte via Kontextmenü, bis hin zu komplexeren Anwendungsfällen, wie dem Erzeugen von Port-Interfaces an Komponenten. Allen Funktionalitäten ist gemeinsam, dass sie im Kontextmenü des Elements und unter Element bearbeiten der Funktionsleiste Inhalt zur Verfügung stehen. Exemplarisch werden im Folgenden zwei dieser Funktionalitäten vorgestellt.

3.3.5.9.1 Navigierbarkeit eines Assoziationsendes festlegen

Wie in Kapitel 2.4.4.2 Associations beschrieben, ist die Navigierbarkeit eines Assoziationsendes keine einfache boolesche Eigenschaft, sondern ergibt sich daraus, wem das Assoziationsende gehört und ggfs. auch daraus, auf welche Weise das Assoziationsende seinem Besitzer zugeordnet ist.

Abbildung 128: Unidirektional navigierbare Assoziation

Abbildung 128 zeigt zwei Klassen und Assoziation. Das Assoziationsende artikel ist navigierbar (erkennbar an der Pfeilspitze), da es Attribut der gegenüberliegenden Klasse Auftragsposition ist. Sie erkennen dies zum einen an der grafischen Darstellung, dem Punkt an der Pfeilspitze, zum anderen daran, dass es bei der Klasse als Attribut aufgeführt ist27.

Abbildung 129: Assoziationsenden der Assoziation

In den Eigenschaften der Assoziation erkennen Sie, dass nur eines der beiden Assoziationsenden der Assoziation gehört: das Assoziationsende auftragsposition. Da es nur bei der Eigenschaft ownedEnd, aber nicht bei der Eigenschaft navigableOwnedEnd aufgeführt ist, ist es nicht navigierbar.

27 Normalerweise werden Attribute, die gleichzeitig auch Assoziationsenden sind, in Diagrammen nicht noch zusätzlich im Attributbereich der Klasse angezeigt. Allerdings können Sie dies für die Klasse durch Abschalten der Darstellungsoption Klassifizierer > Verberge Assoziationsmitgliederenden ändern, was hier zur Verdeutlichung des Sachverhalts auch erfolgt ist.


98

Mit Hilfe des Kontextmenüs des Assoziationsendes oder der Funktionsleiste können Sie dessen Navigierbarkeit leicht ändern, ohne manuell Änderungen an den Besitzverhältnissen vornehmen zu müssen.

Abbildung 130: Funktionen zum Ändern der Navigierbarkeit und der Multiplizität

Abbildung 130 zeigt die UML-spezifischen Funktionalitäten für ein Assoziationsende. Der aktuelle Status des Elements ist in der Liste jeweils ausgeblendet (Navigierbar als Eigenes Attribut einstellen und Multiplizität festlegen [1..1]). Nach Auswahl des Listeneintrags Navigierbar als Eigenes Assoziationsende einstellen ergibt sich folgendes Bild:

Abbildung 131: Assoziationsende navigierbar, aber kein Attribut der gegenüberliegenden Klasse

Das Assoziationsende artikel ist immer noch navigierbar, allerdings nicht mehr als Attribut der Klasse Auftragsposition. Dies wird auch aus den geänderten Eigenschaften der Assoziation ersichtlich. Das Assoziationsende artikel ist jetzt sowohl bei der Eigenschaft ownedEnd als auch bei der Eigenschaft navigableOwnedEnd aufgeführt.

Abbildung 132: Assoziationsenden nach Ändern der Navigierbarkeit

Die Funktionalitäten zum Ändern der Navigierbarkeit ersparen dem Anwender somit das manuelle Bearbeiten der Eigenschaft ownedAttribute der Klasse am gegenüberliegenden Assoziationsende und der Eigenschaften ownedEnd und navigableOwnedEnd der Assoziation.


99

3.3.5.9.2 Erzeugung von Getter- und Setter-Operationen

Mit Hilfe der Funktionalität Getter und Setter generieren lassen sich auf einfache Weise für die Attribute einer Klasse entsprechende Zugriffsmethoden erzeugen.

Abbildung 133: Funktionalitäten zum Erzeugen von Operationen einer Klasse

Die Funktionalität öffnet den Dialog Getter und Setter generieren zum Wählen der Attribute und zum Setzen einiger weiter Parameter für das Generieren der Zugriffsmethoden.

Abbildung 134: Dialog Getter und Setter generieren

Abbildung 134 zeigt den Dialog Getter und Setter generieren für die Klasse Auftragsposition. Als Präfix für die Getter wurde gib und für die Setter setze eingegeben28. Für die Generierung wurden die beiden Attribute artikel und anzahl gewählt. Durch Klicken auf OK wird die Generierung gestartet.

28 Als Standard sind hier nach Start des Dialogs die beiden Präfixe get und set enthalten.


100

Abbildung 135 zeigt die Klasse mit den generierten Zugriffsmethoden.

Abbildung 135: Generierte Getter und Setter


101

3.4 Optionen

Durch Wählen des Menüpunkts Optionen des ARIS-Menüs öffnen Sie den Dialog zur Bearbeitung der allgemeinen Einstellungen von ARIS UML Designer.

Abbildung 136: Menüpunkt zur Bearbeitung der Optionen

Der Dialog beinhaltet eine Reihe Optionen, von denen die wichtigsten im Folgenden vorgestellt werden. Die Optionen zu den Themen Arbeitsumgebung, Drucken und Versionierung werden hier nicht weiter betrachtet, da es sich um ARIS-Standard-Optionen handelt. Die Änderung einige Optionen, z. B. Sprachoptionen oder Tätigkeitsbereich, erfordern einen Neustart von ARIS UML Designer.


102

3.4.1 Allgemeines

Abbildung 137: Optionsseite Allgemeines

Die Methodensprache legt fest, in welcher Sprache die Namen von Diagrammtypen, Elementtypen und Eigenschaften angezeigt werden, die sich nicht auf UML beziehen. Für UML-Typnamen gibt es eine davon unabhängige Spracheinstellung bei den UML-spezifischen Optionen. Die Oberflächensprache legt fest, in welcher Sprache Texte der Benutzeroberfläche angezeigt werden. Die Palette in ARIS UML Designer hat nur Auswirkung auf die Anzeige der Symbole von Nicht-UML-Elementen im Explorer-Baum.


103

3.4.2 UML - Allgemein

Abbildung 138: Optionsseite UML > Allgemein

Die Metamodellsprache legt fest, in welcher Sprache die Typnamen von UML-Elementen, UML-Eigenschaften und UML-Diagrammen angezeigt werden. Dadurch ist es beispielsweise möglich, Objekttypen, Diagrammtypen und Attributnamen für Nicht-UML-Inhalte in Deutsch anzuzeigen und UML-Typen in Englisch. Die Option zur Auswahl der Besitzereigenschaft wurde bereits in Kapitel 3.3.5.6 Grafische Einbettungen erläutert. Mit Hilfe der Option Warnen, wenn Daten implizit geändert werden können Sie die in Kapitel 3.3.4 Leiste Implizite Änderungen vorgestellte Protokollierung impliziter Änderungen aus- und einschalten. Einige ändernde Funktionalitäten von ARIS UML Designer werden auf dem Server ausgeführt, da sie mit potenziell großen Datenmengen arbeiten. Sie setzen daher voraus, dass alle im Client durchgeführten Änderungen zunächst gespeichert werden. Ist das Kontrollkästchen Vor dem Verarbeiten automatisch speichern aktiviert, erfolgt das Speichern ohne Rückfrage bei Aufruf der entsprechenden Funktionalität. Andernfalls wird erst per Dialog nachgefragt, ob gespeichert oder die Funktionalität abgebrochen werden soll.


104

Beim Arbeiten mit mehreren Benutzern an den gleichen Strukturen in einer Datenbank kann es theoretisch vorkommen, dass zwei Anwender gleichzeitig die Struktur so ändern, dass beide Änderungen zusammen einen Zyklus in der Elementhierarchie ergeben würden. Sobald ein Anwender seine Änderungen gespeichert hat, wird in einem solchen Fall das Speichern des zweiten Anwenders ohne vorherige Reparatur des Zyklus fehlschlagen. Ist das Kontrollkästchen Zyklus in der Namensraumhierarchie beim Speichern automatisch beseitigen aktiviert, erfolgt die Reparatur beim Speichern ohne weitere Nachfrage. Ansonsten erscheint ein entsprechender Dialog.

Abbildung 139: D:ialog beim Speichern mit Zyklus in der Namensraumhierarchie

Ist das Kontrollkästchen Nach dem Speichern Daten aktualisieren aktiviert, werden nach dem Speichern alle Daten vom Server neu geladen, sodass Änderungen durch andere Anwender berücksichtigt werden. Mit Hilfe des Kontrollkästchens Sicherheitsspeicherung einschalten wird ARIS UML Designer veranlasst, in regelmäßigen Zeitabständen alle Änderungen lokal zu sichern. Durch die Einstellung Speicherintervall (Sekunden) legen Sie fest, wie oft die Sicherheitsspeicherung durchgeführt werden soll. Geht aufgrund von Netzwerkproblemen die Verbindung zum Server verloren, wird beim nächsten Anmelden nachgefragt, ob die nicht in der Datenbank gespeicherten Änderungen wieder hergestellt werden sollen.

Abbildung 140: Nachfrage zur Wiederherstellung nicht gespeicherter Änderungen


105

3.4.3 UML - Designer-Allgemein

Abbildung 141: Optionsseite UML - Designer-Allgemein

Die Option Markierte Kanten - Farbe legt fest, in welcher Farbe in Diagrammen markierte Kanten angezeigt werden. Normalerweise werden Änderungen in Texteingabefeldern mit Hilfe der Eingabetaste übernommen und Zeilenumbrüche mit Strg + Eingabetaste eingegeben. Das können Sie durch Aktivieren des Kontrollkästchens Zeilenumbruch per Eingabetaste (Änderung per ‘Strg + Eingabetaste‘) umkehren. Die Optionen zu Einbettungen wurden bereits in Kapitel 3.3.5.6 Grafische Einbettungen erläutert. Ist das Kontrollkästchen Tooltips für Ausprägungen anzeigen aktiviert, wird in Diagrammen für UML-Elemente an der Mausposition ein entsprechender Tooltip mit Informationen zum Element angezeigt.

Abbildung 142: Tooltip eines UML-Elements im Diagramm


106

3.4.4 UML - Explorer

Abbildung 143: Optionsseite Explorer

Hier können Sie einstellen, wie viele Einträge das Kontextmenü des Explorers zum Erzeugen neuer Elemente anzeigt und ob die Einträge alphabetisch sortiert sein sollen (siehe Kapitel 3.2.4 Anlegen neuer Elemente im Explorer).

3.4.5 UML - Für neue Diagramme

Diese Optionsseiten beziehen sich auf allgemeine Darstellungsoptionen von Diagrammen, wie sie auch im ARIS-Standard unterstützt werden. Spezifisch für ARIS UML Designer ist hier lediglich folgende Option:

Abbildung 144: Layout-Option auf der Optionsseite UML - Für neue Diagramme - Darstellung

Das Aktivieren des Kontrollkästchens bewirkt, dass beim Öffnen eines Diagramms die Größe der dargestellten Elemente an ihren Inhalt angepasst wird. Die auf diesen Optionsseiten vorgenommenen Einstellungen wirken sich nur auf Diagramme aus, die Sie neu anlegen. Existierende Diagramme werden nicht geändert.


107

3.4.6 UML - Darstellungsoptionen

Abbildung 145: Optionsseite UML - Darstellungsoptionen

Auf dieser Optionsseite können Sie die Voreinstellungen für die Darstellungsoptionen aller UML-Symbole und grafischen Elemente festlegen. Die Symbole sind nach Diagrammtypen gruppiert. Die Optionen können für einzelne Symbole individuell festgelegt werden, indem Sie nur ein Symbol wählen und seine Darstellungsoptionen bearbeiten.

Abbildung 146: Auswahl des Symbols Enumeration


108

Sie können auch mehrere Symbole oder ganze Hierarchieebenen wählen. Im folgenden Beispiel wurden für alle UML-Symbole die Eigenschaften Schattiert und 3-D-Effekt deaktiviert.

Abbildung 147: Auswahl aller Symbole durch markieren der obersten Ebene

Die auf dieser Optionsseite vorgenommenen Änderungen wirken sich nur auf Präsentationselemente aus, die Sie neu anlegen. Existierende Elemente werden nicht geändert.


109

3.4.7 UML – Eigenschaftsregisterkarten

Abbildung 148: Optionsseite UML - Eigenschaftsregisterkarten

Hier können Sie wählen, welche Eigenschaftsregisterkarten im Eigenschaftsbereich der Designer-Komponente angezeigt werden sollen. Diese Optionen haben keine Auswirkungen auf die Registerkarte Explorer. Diese zeigt immer alle Eigenschaftsregisterkarten an, da dort wesentlich mehr Platz zur Verfügung steht.


110

3.5 Registerkarte Administration

Die Registerkarte Administration stellt verschiedene administrative Funktionalitäten zur Verfügung. Dies umfasst unter anderem die Konfiguration der Methodenfilter, die Verwaltung der Zugriffsrechte und das Schreiben von Reporten. Daneben gibt es einige UML-Designer-spezifische Funktionalitäten wie die Konfiguration der Verknüpfung zwischen Geschäftsprozess- und UML-Modellierung oder die Verwaltung der XMI-Ressourcen. Die Registerkarte Administration steht nur zur Verfügung, wenn Sie den Tätigkeitsbereich Konfigurieren & Administrieren gewählt haben (siehe Kapitel 3.1 Festlegen des Tätigkeitsbereiches). Sie wird durch Wählen des Menüpunktes Administration des ARIS-Menüs geöffnet.

Abbildung 149: Menüeintrag zum Start der Administration

Abbildung 150: Administrationskomponente


111

Im Folgenden werden nur die Aspekte der Registerkarte Administration betrachtet, die spezifisch für ARIS UML Designer sind.


112

3.5.1 Methodenfilter

Bei der Anmeldung bei einer Datenbank in ARIS UML Designer werden nur solche Methodenfilter zur Wahl angeboten, die auch UML 2 umfassen. Im Gegensatz zum ARIS-Standard kann UML 2 im Methodenfilter nur als Ganzes enthalten sein. Auch eine benutzerdefinierte Erweiterung der UML-Methode ist nicht möglich. Der Grund hierfür liegt in der hohen Komplexität des UML-Metamodells und darin, dass die UML-Spezifikation für benutzerdefinierte Erweiterungen und Einschränkungen die Verwendung von UML-Profilen vorsieht. Eine Einführung in das Thema UML-Profile finden Sie in Kapitel 6 UML Profile. Anhand des Standardfilters wird im Folgenden gezeigt, wie Sie UML dem Methodenfilter hinzufügen können. Markieren Sie in der Filterliste den Filter Standard und wählen Sie aus dem Kontextmenü oder der Funktionsleiste den Eintrag Bearbeiten.

Abbildung 151: Filter bearbeiten

Navigieren Sie im Filter-Assistenten durch Klick auf die Schaltfläche Weiter zur dritten Seite Metamodelle wählen und aktivieren Sie dort den Eintrag UML 2.5. Mit anschließendem Mausklick auf Fertigstellen haben Sie den Filter um UML 2 erweitert.


113

Abbildung 152: Auswahl des UML 2.5-Metamodells im Filter-Assistenten


114

3.5.2 Link-Typen

Abbildung 153: Verwaltung der Link-Typen

Hier definieren Sie, welche Geschäftsprozessobjekte Sie auf UML abbilden möchten und legen Regeln für deren Abbildung fest. Diese Funktionalität wird in Kapitel 5 Verknüpfung von Geschäftsprozess- mit UML-Modellierung im Detail vorgestellt.


115

3.5.3 XMI-Ressourcen

Abbildung 154: Verwaltung der XMI-Ressourcen

XMI (XML Metadata Interchange) ist ein Format zum Austausch metamodellbasierter Daten zwischen verschiedenen Werkzeugen. Wie UML ist XMI ein von der OMG definierter Standard. ARIS UML Designer exportiert und importiert XMI-Dateien im Format UML 2.5 / XMI 2.1. Mit Hilfe von XSLT-Dateien können Sie entsprechende Anpassungen an XML-Formaten von Drittherstellern vornehmen. Diese XSLT-Dateien werden im Bereich XMI-Ressourcen verwaltet und können beim XMI-Export und -Import optional gewählt werden. Das Thema XMI-Schnittstelle und XSLT-Dateien zur Anpassung an Fremdformate wird im Dokument ARIS UML Designer XMI-Schnittstelle genauer vorgestellt.


116

3.5.4 Datenübernahmen aus ARIS UML Designer 7.x

Enthält eine Datenbank aus ARIS 7.x UML-Inhalte, die mit ARIS UML Designer 7.x erstellt wurden, müssen diese erst zu UML 2 konvertiert werden, bevor sie mit ARIS UML Designer 9 angezeigt oder bearbeitet werden können. Eine ausführliche Beschreibung der UML-Konvertierung finden Sie im Dokument UML Migration Guidelines.


117

4 Abbildung von UML auf das ARIS-Objektmodell

UML ist vollständig auf das ARIS-Objektmodell abgebildet. Zwei wesentliche Aspekte von UML erforderten jedoch eine Erweiterung des ARIS-Objektmodells im Vergleich zu ARIS 7: § UML-Elemente können andere UML-Elemente und UML-Diagramme beinhalten, sie können in

Diagrammen ausgeprägt sein und sie können durch Beziehungen miteinander verknüpft werden. § Eine grafische Kante in einem UML-Diagramm kann eine ganze Kette von UML-Elementen und

Beziehungen darstellen. Diese Aspekte werden nachfolgend genauer betrachtet.

4.1 Gruppen- und Objekteigenschaften von UML-Elementen

Abbildung 155: Pakethierarchie und Paketdiagramm

Abbildung 155 zeigt im Explorer-Baum links eine Hierarchie von Paketen mit einem Diagramm und auf der rechten Seite ein Paketdiagramm mit Paketen und deren Beziehungen untereinander. Beide Seiten zeigen für Pakete typische Aspekte jeweils verschiedener ARIS-Typen. Die Pakethierarchie zeigt typische Merkmale einer ARIS-Gruppenhierarchie. So wie ARIS-Gruppen andere ARIS-Gruppen, ARIS-Objekte und ARIS-Modelle beinhalten können, können auch UML-Pakete andere UML-Elemente und UML-Diagramme beinhalten. Von daher wäre es naheliegend, UML-Pakete auf ARIS-Gruppen abzubilden. Das Diagramm hingegen zeigt typische Merkmale von ARIS-Objekten. So wie ARIS-Objekte als Objektausprägungen in ARIS-Modellen enthalten und durch Kanten miteinander verknüpft sein können, sind auch UML-Pakete im Diagramm als Elementausprägungen enthalten und durch Kanten miteinander


118

verknüpft. Wenn man nur diesen Aspekt betrachtet, wäre es naheliegend, UML-Pakete auf ARIS-Objekte abzubilden. Dieser Widerspruch in der Abbildung von UML auf ARIS konnte dadurch gelöst werden, indem der ARIS-Typ Gruppe alle Eigenschaften des ARIS-Typs Objekt erhielt. Das bedeutet, Gruppen haben einen Objekttyp, sie können Ausprägungen in Diagrammen besitzen und sie können durch Kanten miteinander verknüpft werden. Da letztlich jedes UML-Element andere UML-Elemente beinhalten kann (jedes UML-Element kann Elemente vom UML-Typ Comment besitzen) und auch etliche Elemente Diagramme besitzen können, sind UML-Elemente in ARIS auf Gruppen des jeweiligen UML-Typs abgebildet. Das bedeutet beispielsweise, dass ein Anwendungsfall (UML-Typ UseCase) in ARIS als Gruppe mit Objekttyp OT_UML2_USE_CASE gespeichert wird. Diese Abbildung gilt für alle UML-Elemente unabhängig von ihrer Darstellung in Diagrammen. Auch eine Generalisierung (UML-Typ Generalization), in Diagrammen grafisch als Kante angezeigt, wird in ARIS als Gruppe mit Objekttyp OT_UML2_GENERALIZATION gespeichert. Eine Ausnahme stellen einige Elementtypen dar, die i. d. R. in der Elementhierarchie jeweils ganz unten stehen und gleichzeitig häufig vorkommen. Beispiele für solche Elemente sind LiteralInteger und LiteralUnlimitedNatural. Sie werden i. d. R. als untere bzw. ober Grenze von Multiplizitäten an Assoziationsenden und Attributen verwendet. Um die Verwaltung von Benutzerrechten nicht zu feingranular werden zu lassen, wurde die Möglichkeit, Benutzerechte zu definieren, auf UML-Elemente der Typen Package, Model und Profile beschränkt. Das Verhalten herkömmlicher Gruppen hat sich in ARIS nicht geändert. Diese sind vom Objekttyp Gruppe (OT_GROUP). Für Gruppen dieses Typs existiert auch weiterhin keine Möglichkeit, sie in Diagrammen auszuprägen oder durch Kanten zu verknüpfen.


119

4.2 Komplexität von Kantenpräsentationen

Abbildung 155 zeigt auch den zweiten genannten Aspekt: die grafischen Kanten im Diagramm repräsentieren sowohl direkte Beziehungen zwischen den Paketen - die Kanten zwischen Paketen und ihren enthaltenen Paketen - als auch andere UML-Elemente, über die Pakete miteinander verknüpft sind, z. B. die Dependency-Beziehung.

Abbildung 156: Assoziation als grafische Kante im Diagramm

Abbildung 156 zeigt eine Assoziation als grafische Kante in einem Klassendiagramm. Diese stellt drei UML-Elemente und ihre Beziehungen untereinander und zu den beiden Klassen dar: die Assoziation (UML-Typ Association) A_artikel_auftragsposition, die beiden Assoziationsenden (UML-Typ Property) auftrag und position, die Beziehungen der Assoziation zu ihren beiden Assoziationsenden (UML-Eigenschaft Association::memberEnd) und die Beziehungen der Assoziationsenden zu den beiden Klassen (UML-Eigenschaft TypedElement::type). Die vorgestellten UML-Kanten repräsentieren somit vollkommen unterschiedliche Inhalte. Die Kanten zur Darstellung der Pakethierarchie in Abbildung 155 repräsentieren eine Hierarchiebeziehung zwischen zwei Gruppen. Diese Beziehung wird nicht durch Kantendefinitionen in ARIS abgebildet, sondern stellt einen direkten Verweis der untergeordneten Gruppe auf die übergeordnete Gruppe dar. Die Beziehung zwischen dem Kommentar und der Klasse in Abbildung 156 repräsentiert die UML-Eigenschaft Comment::annotatedElement und damit genau eine Kantendefinitionen.


120

Die Generalisierung in Abbildung 156 ist auf eine Gruppe abgebildet, die der abgeleiteten Klasse untergeordnet ist. Die Verknüpfung zur Basisklasse erfolgt mit Hilfe einer Kantendefinition. Damit repräsentiert die Generalisierungskante eine Hierarchiebeziehung, eine Gruppe und eine Kantendefinition. Die Assoziation in Abbildung 156 repräsentiert insgesamt drei Gruppen und fünf Kantendefinitionen. Klassische Kantenausprägungen in ARIS stellen immer genau eine Kantendefinition dar. Sie eigenen sich daher nicht zur Darstellung aller Kantentypen in UML-Diagrammen. Zu diesem Zweck wurde das ARIS-Objektmodell um einen neuen Typ von Kantenausprägung erweitert, der nur von ARIS UML Designer verwendet wird und in der Lage ist, beliebige Inhalte zu repräsentieren. Auch für Kantenpräsentationen, die genau eine Kantendefinition darstellen, wird in UML-Diagrammen der neue Typ von Kantenausprägungen verwendet.


121

4.3 Die wichtigsten Abbildungen von UML nach ARIS

Die folgende Tabelle zeigt die wichtigsten Abbildungen von UML nach ARIS.

UML Im Metamo-dell repräsen-tiert durch Metaelement des Typs

Abgebildet auf ARIS-Typ Bedingung

UML-Elemente Class Gruppe Die Metaklasse des Elements ist nicht OpaqueExpression und auch keine Spezialisierung von LiteralSpecification.

Attribut Die Metaklasse des Elements ist OpaqueExpression oder eine Spezialisierung von LiteralSpecification.

UML-Eigenschaften Property (Gruppenhierarchiebeziehung) Für das Meta-Property gilt: isDerived=false isComposite=true type ist eine Metaklasse

Kantendefinition Für das Meta-Property gilt: isDerived=false isComposite=false type ist eine Metaklasse

Attribut Für das Meta-Property gilt: isDerived=false type ist ein Datentyp

(wird zur Laufzeit berechnet) Für das Meta-Property gilt: isDerived=true

UML-Diagramme Diagram* Modell Knotenpräsentationen NodeSymbol* Objektausprägung Kantenpräsentationen EdgeSymbol* Kantenausprägung neuen

Typs

Lane-Präsentationen LaneSymbol* Objektausprägung * Im offiziellen UML-Metamodell existieren keine Konstrukte zur formalen Beschreibung der grafischen Repräsentation. Diese Metaelemente stellen eine ARIS-spezifische Erweiterung dar.


122

5 Verknüpfung von Geschäftsprozess- mit UML-Modellierung

Möchten Sie ein IT-System entwickeln, das die Geschäftsprozesse Ihres Unternehmens optimal unterstützt, ist es sinnvoll, mit einer Analyse der Geschäftsprozesse zu beginnen, um daraus entsprechende Anforderungen für das IT-System abzuleiten. ARIS bietet hierzu optimale Voraussetzungen, da es eine Geschäftsprozess- und UML-Modellierung integriert in einem Repository anbietet und es Ihnen ermöglicht, Geschäftsprozess- und UML-Inhalte miteinander zu verknüpfen. Grundsätzlich haben Sie zwei Möglichkeiten zur Verknüpfung von Geschäftsprozessen mit UML:

1. Hinterlegung von Geschäftsprozess-Objekten mit UML-Diagrammen 2. Wiederverwendung von Geschäftsprozess-Objekten in UML als UML-Elemente

Für beide Verknüpfungsmöglichkeiten gilt, dass Sie als Anwender frei entscheiden können, welche konkreten Geschäftsprozess- und UML-Typen Sie miteinander verknüpfen möchten. Es gibt hier keine starren Vorgaben durch die ARIS-Methode. Sie können problemlos zwischen den beiden Anwendungen ARIS UML Designer und ARIS Architect/ARIS Designer navigieren. Ein Doppelklick auf ein ARIS-Modell im Explorer-Baum von ARIS UML Designer startet automatisch ARIS Architect oder ARIS Designer (falls noch nicht zuvor gestartet) und öffnet dort das ARIS-Modell. Umgekehrt kann das Öffnen eines hinterlegten UML Diagramms in ARIS UML Designer durch Doppelklick auf das entsprechende Hinterlegungssymbol in einem ARIS-Modell in ARIS Architect/ARIS Designer erfolgen. Im Folgenden werden die beiden Verknüpfungsarten und die verschiedenen Navigationsmöglichkeiten genauer vorgestellt.

5.1 Hinterlegung von Geschäftsprozess-Objekten mit UML-Diagrammen

Die Verknüpfung von Geschäftsprozess-Objekten mit UML-Diagrammen erfolgt mit Hilfe von Hinterlegungen des Typs Navigation, wie sie in Kapitel 3.2.2.4 Verknüpfte Diagramme (Elemente) bereits vorgestellt wurden. Grundsätzlich können Sie diese Hinterlegung sowohl in ARIS UML Designer als auch in ARIS Architect und ARIS Designer erstellen.


123

5.1.1 Hinterlegung in ARIS UML Designer erstellen

Die Hinterlegung eines ARIS-Objekts mit einem Diagramm in ARIS UML Designer erfolgt wie die Hinterlegung eines UML-Elements mit einem Diagramm. Zunächst markieren Sie das ARIS-Objekt im Explorer und wechseln auf die Eigenschaftsseite Verknüpfte Diagramme. Wenn Sie sich nicht die Registerkarte Explorer geöffnet haben, die die Eigenschaftsseiten auf der rechten Seite anzeigt, sondern in der Designer-Komponente, öffnen Sie zunächst den Eigenschaftsdialog des ARIS-Objekts. Auf der Eigenschaftsseite Verknüpfte Diagramme klicken Sie auf Diagramm hinterlegen.

Abbildung 157: Schaltfläche Diagramm hinterlegen

Ein Dialog zum Wählen des Diagramms wird geöffnet. Sie können das Diagramm entweder durch eine Datenbanksuche oder durch direktes Wählen im Explorer-Baum hinterlegen (siehe Abbildung 158 und Abbildung 159).


124

Abbildung 158: Diagrammauswahl durch Suche in der Datenbank

Abbildung 159: Diagrammauswahl im Explorer


125

5.1.2 Hinterlegung in ARIS Architect und ARIS Designer erstellen

Um ein ARIS-Objekt in ARIS Architect oder ARIS Designer mit einem UML-2-Diagramm zu hinterlegen, markieren Sie zunächst das Objekt im ARIS-Modell und klicken in der Funktionsleiste Start auf Hinterlegungen anlegen.

Abbildung 160: Starten des Eigenschaftsdialogs einer Funktion in einem ARIS-Modell

Die Eigenschaftsseite Hinterlegungen wird geöffnet. Klicken Sie auf Neu, um eine neue Hinterlegung anzulegen.


126

Abbildung 161: Eigenschaftsseite Hinterlegungen in ARIS Architect und ARIS Designer

Sie werden gefragt, ob Sie ein ARIS-Modell oder ein UML-2-Diagramm hinterlegen möchten. Klicken Sie auf UML-2-Diagramm.

Abbildung 162: Abfrage des zu hinterlegenden Diagrammtyps


127

Mit dem folgenden Dialog können Sie ein UML-Diagramm zum Hinterlegen wählen.

Abbildung 163: Dialog zur Auswahl eines UML-Diagramms in ARIS Architect und ARIS Designer

Das hier gewählte Diagramm wird der Tabelle der hinterlegten Diagramme hinzugefügt (siehe Abbildung 164).

Abbildung 164: Hinterlegtes UML-Diagramm im Eigenschaftsdialog des ARIS-Objekts


128

Im ARIS-Modell wird ein Hinterlegungssymbol im Modell angezeigt (siehe Abbildung 165).

Abbildung 165Hinterlegungssymbol an der Funktion


129

5.2 Wiederverwendung von Geschäftsprozess-Objekten als UML-Elemente

Bevor Sie Geschäftsprozess-Objekte in UML-Diagrammen verwenden können, müssen Sie festlegen, welche ARIS-Objekttypen auf welche UML-Elementtypen abgebildet werden sollen. Anschließend können Sie diese ARIS-Objekte in UML-Diagrammen als UML-Elemente einfügen. Dabei erfolgt keine direkte Ausprägung des ARIS-Objekts im UML-Diagramm. Vielmehr wird ein neues UML-Element erzeugt und mit dem ARIS-Objekt über eine spezielle Wiederverwendungsbeziehung verknüpft. Die einzelnen Aspekte dieser Wiederverwendung werden im Folgenden genauer vorgestellt.

5.2.1 Festlegung der Abbildung von ARIS- auf UML-Typen

Die Abbildung von ARIS- auf UML-Typen wird im Bereich Link-Typen der Registerkarte Administration definiert, die bereits in Kapitel 3.5.2 Link-Typen kurz vorgestellt wurde. Bitte beachten Sie, dass Ihnen diese Funktionalität nur in der Registerkarte Administration von ARIS UML Designer, nicht jedoch in ARIS Architect zur Verfügung steht. Markieren Sie zur Definition einer Abbildung im Explorer-Baum der Registerkarte Administration den Eintrag Objekt-Links unter Link-Typen und klicken Sie im Kontextmenü auf Neu > Objekt-Link-Definition.

Abbildung 166: Anlegen einer neuen Objekt-Link-Definition


130

Der Dialog Objekt‐Link anlegen wird geöffnet.

Abbildung 167: Dialog zum Anlegen einer neuen Objekt‐Link‐Definition

In der Spalte Quelltyp wählen markieren Sie einen ARIS‐Objekttyp und in der Spalte Zieltyp wählen den gewünschten UML‐2‐Elementtyp. Grundsätzlich besteht die Möglichkeit, Abbildungen zwischen beliebigen Typen zu definieren, also auch zwischen klassischen ARIS‐Objekttypen. ARIS Architect unterstützt jedoch nur die Abbildung von klassischen ARIS‐Objekttypen auf UML2‐Elementtypen, sodass Sie als Quelltyp immer einen klassischen ARIS‐Objekttyp und als Zieltyp immer einen UML2‐Elementtyp wählen sollten.

Optional können Sie auch eine oder mehrere der folgenden Regeln aktivieren:

Quelle benennt Ziel um

Diese Regel bewirkt, dass beim Umbenennen des ARIS‐Objekts auch das UML‐Element umbenannt wird, sodass es den gleichen Namen wie das ARIS‐Objekt trägt.

Ziel benennt Quelle um

Diese Regel bewirkt, dass beim Umbenennen des UML‐Elements auch das ARIS‐Objekt umbenannt wird, sodass es den gleichen Namen wie das UML‐Element trägt.

Quelle löscht Ziel

Diese Regel bewirkt, dass das UML‐Element gelöscht wird, sobald das zugrunde liegende ARIS‐Objekt gelöscht wird.

Ziel löscht Quelle

Diese Regel bewirkt, dass das zugrunde liegende ARIS‐Objekt gelöscht wird, sobald das entsprechende UML‐Element gelöscht wird.


131

Wenn Sie in die Eingabefelder oberhalb der Objektlisten die Anfangsbuchstaben des gesuchten Typs eingeben, wird die Objektliste entsprechend gefiltert.

Abbildung 168: Definition einer Abbildung des ARIS‐Objekttyps Funktion auf den UML2‐Elementtyp UseCase

Abbildung 168 zeigt die Definition der Abbildung des ARIS‐Objekttyps Funktion auf den UML‐Typ UseCase mit der Regel, dass beim Umbenennen der Funktion der Anwendungsfall den gleichen Namen erhält. Mit OK wird die Definition angelegt und in der Tabelle entsprechend angezeigt.

Abbildung 169: Neu angelegte Objekt‐Link‐Definition

Durch diese Abbildung können Sie eine Funktion in einem Geschäftsprozess, die durch ein IT‐System realisiert werden soll, als Anwendungsfall im Rahmen der objektorientierten Analyse betrachten und sie als ein UML‐Element vom Typ UseCase wiederverwenden.

Grundsätzlich können Sie auf diese Weise einen ARIS‐Objekttyp auf verschiedene UML‐Elementtypen und mehrere ARIS‐Objekttypen auch auf einen UML‐Elementtyp abbilden.

So könnten Sie beispielsweise den Typ Funktion nicht nur auf UML2 UseCase, sondern auch auf UML2 Operation abbilden, um die Funktion in UML auch als Operation einer Fachklasse wiederzuverwenden.


132

Umgekehrt kann es sinnvoll sein, verschiedenen ARIS-Typen wie Organisationseinheit, Person oder Anwendungssystem, also alle Typen, die in irgendeiner Art mit der Ausführung oder Überwachung einer Funktion verknüpft sind, auf den UML-Typ Actor abzubilden, sodass Sie diese ARIS-Objekte als Akteure in UML-Anwendungsfalldiagrammen wiederverwenden können.

Abbildung 170: Verschiedene Objekt-Link-Definitionen

Abbildung 170 zeigt die zuvor beschriebenen Objekt-Link-Definitionen. Bei der Wahl des Zieltyps sind Sie nicht auf konkrete UML-2-Typen beschränkt, also solche, für die Sie auch ein direkt entsprechendes UML-Element anlegen können. Das obige Beispiel enthält eine Objekt-Link-Definition, bei der der ARIS-Typ Funktion auf den abstrakten UML-2-Typ Action abgebildet wird. Wenn Sie in einem solchen Fall eine Funktion in ein UML-Aktivitätsdiagramm einfügen, werden Sie gefragt, welche konkrete Action angelegt werden soll.

Abbildung 171: Symbolauswahl bei abstraktem Typ


133

5.2.2 Wiederverwendung eines ARIS-Objekts in einem UML-Diagramm

Markieren Sie zunächst im ARIS-Modell das ARIS-Objekt, das Sie als UML-Element wiederverwenden möchten. Kopieren Sie es in die Zwischenablage, indem Sie im Kontextmenü auf Kopieren klicken.

Abbildung 172: Kopieren des ARIS-Objekts in die Zwischenablage

Sie können das ARIS-Objekt alternativ auch im Explorer-Baum von ARIS Architect, ARIS Designer oder auch ARIS UML Designer markieren und kopieren. In ARIS UML Designer öffnen Sie anschließend durch Rechtsklick auf den Diagrammhintergrund das Kontextmenü und klicken entweder auf Einfügen oder Einfügen als > Hier als wiederverwendete Objekte platzieren.

Abbildung 173: Einfügen des ARIS-Objekts im UML-Diagramm


134

Der Dialog Objekte wiederverwenden zum Wählen der zugrundeliegenden Objekt-Link-Definition wird geöffnet.

Abbildung 174: Auswahl der Objekt.-Link-Definition

Falls es mehrere Symbole gibt, mit denen Elemente des UML-Typs im Diagramm ausgeprägt sein können, erfolgt eine Nachfrage, welches der Symbole zur Darstellung verwendet werden soll.

Abbildung 175: Dialog zur Auswahl des zu verwendenden Symbols


135

Damit ist ein neuer Anwendungsfall im Diagramm angelegt.

Abbildung 176: Neu angelegter Anwendungsfall

Der Anwendungsfall trägt denselben Namen wie die zugrundeliegende Funktion und zeigt diese auf seiner Eigenschaftsseite Wiederverwendete Objekte an.

Abbildung 177: Eigenschaftsseite Wiederverwendete Objekte in ARIS UML Designer


136

Nach dem Speichern in ARIS UML Designer steht diese Information auch in ARIS Architect und ARIS Designer zur Verfügung.

Abbildung 178: Eigenschaftsseite Wiederverwendete Objekte in ARIS Architect und ARIS Designer


137

5.2.3 Verwaltung der Objekt-Link-Definitionen

Im Kontextmenü einer Objekt-Link-Definition stehen Ihnen mehrere Einträge zur Bearbeitung zur Verfügung.

Abbildung 179: Kontextmenüeinträge zur Bearbeitung von Objekt-Link-Definitionen

Sie können eine neue Objekt-Link-Definition anlegen, die markierte Definition bearbeiten oder die markierte Definition löschen. Nach dem Klicken auf Bearbeiten wird der Dialog Objekt-Link anlegen wie beim Neuanlegen einer Objekt-Link-Definition geöffnet (siehe Abbildung 167). Die Einträge zur Bearbeitung der markierten Objekt-Link-Definition finden Sie auch in der Funktionsleiste.

Abbildung 180: Schaltflächen in der Funktionsleiste zur Verwaltung der Objekt-Link-Definitionen

Die Objekt-Link-Definitionen werden in der Systemdatenbank des ARIS-Servers gespeichert. Wenn Sie im Explorer-Baum der Registerkarte Administration den Eintrag Objekt-Links im Bereich Link-Typen markieren, können Sie durch Klicken auf Objekt-Link exportieren die Objekt-Link-Definitionen in eine Datei exportieren, um sie auf einen anderen ARIS-Server zu übertragen. Zum Importieren klicken Sie auf dem anderen Server auf Objekt-Link importieren.

Wenn Sie auf Aus Datenbankinhalt generieren klicken, startet die Analyse hinsichtlich aller existierenden Wiederverwendungsbeziehungen innerhalb einer ARIS-Datenbank und erzeugt für diese Objekt-Link-Definitionen in der Systemdatenbank. Das ist dann hilfreich, wenn Sie eine Datenbank mit Wiederverwendungsbeziehungen importieren und Sie in der Folge solche Wiederverwendungsbeziehungen selbst anlegen möchten, aber noch keine entsprechenden Objekt-Link-Definitionen selbst angelegt haben. Zum bloßen Betrachten oder Auswerten der Wiederverwendungsbeziehungen einer ARIS-Datenbank ist es nicht notwendig, die Objekt-Link-Definitionen in der Systemdatenbank zu erzeugen.


138

5.3 Navigation zwischen ARIS Architect/ARIS Designer und ARIS UML Designer

Auch wenn es sich bei ARIS Architect bzw. ARIS Designer und ARIS UML Designer um unterschiedliche Programme handelt, bieten sie einfache Navigationsmöglichkeiten zu Elementen und Diagrammen im jeweils anderen Programm.

5.3.1 Navigation von ARIS Architect/ARIS Designer nach ARIS UML Designer

In ARIS Architect und ARIS Designer können Sie für alle im Explorer-Baum enthaltenen Gruppen, ARIS-Objekte, ARIS-Modelle und UML-Elemente auf den Kontextmenüeintrag Gehe zu > Vorkommen im UML Explorer klicken. Bitte beachten Sie, dass ARIS Architect und ARIS Designer nur die UML-Pakete, Modelle und Profile anzeigt, die sich direkt in einer ARIS-Standardgruppe befinden, nicht jedoch deren Inhalt.

Abbildung 181: Kontextmenüeintrag in ARIS Architect zur Navigation nach ARIS UML Designer

Nach dem Klicken auf den Kontextmenüeintrag wird geprüft, ob schon eine ARIS UML Designer-Instanz mit der gleichen Server-Verbindung läuft. Falls nicht, wird sie neu gestartet. Anschließend erfolgt in ARIS UML Designer eine Anmeldung bei derselben Datenbank und das in ARIS Architect bzw. ARIS Designer markierte Element wird im Explorer von ARIS UML Designer markiert. Auf der Eigenschaftsseite Wiederverwendete Objekte besteht ebenfalls die Möglichkeit, durch Klicken auf

Vorkommen im UML-Explorer zum entsprechenden UML-Element im Explorer von ARIS UML Designer zu navigieren (siehe Abbildung 178). Zusätzlich steht diese Navigationsmöglichkeit auch im Kontextmenü zur Verfügung.

Abbildung 182: Kontextmenüeintrag zur Navigation zum verknüpften UML-Element


139

Hinterlegte UML-Diagramme können Sie in ARIS Architect und ARIS Designer durch Doppelklick auf das Hinterlegungssymbol im ARIS-Modell öffnen. Daneben können Sie auch die Eigenschaftsseite Hinterlegungen verwenden und auf den Kontextmenüeintrag Öffnen oder auf die Schaltfläche Öffnen klicken (siehe Abbildung 164), um UML-Diagramme in ARIS UML Designer zu öffnen.

Abbildung 183: Kontextmenüeintrag in ARIS Architect / ARIS Designer zum Öffnen eines UML-Diagramms


140

5.3.2 Navigation von ARIS UML Designer nach ARIS Architect/ARIS Designer

ARIS UML Designer zeigt im Explorer neben der Gruppenhierarchie und den UML-Inhalten alle ARIS-Modelle und ARIS-Objekte mit ihren Eigenschaften an. Zur Darstellung und Bearbeitung der ARIS-Modelle ist ein Wechsel zu ARIS Architect oder ARIS Designer erforderlich. Zu diesem Zweck bietet Ihnen ARIS UML Designer für alle Gruppen, ARIS-Modelle, ARIS-Objekte und UML-Pakete, -Modelle und –Profile, die sich direkt in einer Gruppe befinden, einen Kontextmenüeintrag zur Navigation nach ARIS Architect bzw. ARIS Designer an.

Abbildung 184: Kontextmenüeintrag zur Navigation nach ARIS Architect bzw. ARIS Designer

Dieselbe Funktionalität steht ihnen für das markierte Element in der Funktionsleiste Start zur Verfügung.

Abbildung 185Eintrag in der Funktionsleiste zur Navigation nach ARIS Architect bzw. ARIS Designer

Nach dem Klicken auf den Menüpunkt wird geprüft, ob schon eine ARIS Architect/ARIS Designer -Instanz mit der gleichen Server-Verbindung läuft. Falls nicht, wird sie neu gestartet. Anschließend erfolgt in ARIS Architect/ARIS Designer eine Anmeldung bei derselben Datenbank und das in ARIS UML Designer markierte Element wird im Explorer von ARIS Architect/ARIS Designer markiert. Genau wie für UML-Diagramme wird auch für ARIS-Modelle in ARIS UML Designer die Funktionalität zum Öffnen des Diagramms angeboten.

Abbildung 186: Öffnen eines ARIS-Modells in ARIS UML Designer

Auch hier wird, falls erforderlich, eine ARIS Architect/ARIS Designer -Instanz gestartet und das ARIS-Modell dort geöffnet.


141

Die Navigation wird nicht nur im Explorer, sondern in allen UML-Designer-Komponenten angeboten, welche Elemente darstellen, die auch im Explorer von ARIS Architect und ARIS Designer sichtbar sind.

Abbildung 187: Navigation vom UML-Element zum zugrundeliegenden Geschäftsprozess-Objekt


142

Sie können hinterlegte ARIS-Modelle auch mit Hilfe der Eigenschaftsseite Verknüpfte Diagramme des UML-Elements öffnen oder aus einem Diagramm heraus durch Doppelklick auf das Hinterlegungssymbol an der Präsentation des UML-Elements.

Abbildung 188: Menüpunkte zur Navigation und zum Öffnen eines einem UML-Element hinterlegten ARIS-Modells

Abbildung 189: Hinterlegungssymbol für eine ARIS Modell an einem UML-Element


143

6 UML Profile

Mit Hilfe von UML-Profilen können Sie in ARIS UML Designer das UML-Metamodell um benutzerdefinierte Typen und Eigenschaften erweitern und gleichzeitig die Menge der in Diagrammen zur Verfügung stehenden UML-Typen reduzieren. Damit haben UML-Profile für die UML-Modellierung eine ähnliche Bedeutung wie sie ARIS-Methodenfilter für die ARIS-Standardmodellierung darstellen. Während ein ARIS-Methodenfilter individuell vom Anwender bei der Anmeldung bei einer Datenbank gewählt wird und für die gesamte Datenbank und die Zeitdauer der Anmeldung gilt, werden UML-Profile in der Datenbank einzelnen UML-Paketen fest zugeordnet. Sie gelten somit nur für die Pakete (Modelle und Profile), denen sie jeweils zugeordnet sind, sowie für deren Inhalt. Dies ermöglicht es Ihnen, in unterschiedlichen Bereichen der Datenbank unterschiedliche UML-Profile zu verwenden. Darüber hinaus gelten UML-Profile für alle Benutzer in gleicher Weise, unabhängig vom Methodenfilter, den diese bei der Anmeldung ausgewählt haben.

6.1 Vordefinierte Profile in ARIS UML Designer

ARIS UML Designer enthält bereits einige vordefinierte UML-Profile: § StandardProfile

Hier handelt es sich um das Standard-Profil aus der UML-Spezifikation. Es beinhaltet alle Stereotypen, die im UML-Standard definiert sind.

§ OMF Meta Profile Dieses Profil wird vom UML-Metamodellgenerator (siehe Kapitel 6.3 Der UML-Metamodellgenerator ) zur Abbildung der Metaelemente auf UML verwendet.

§ OMF Extension Profile Dieses Profil erweitert die Profilmodellierung in ARIS UML Designer um Möglichkeiten, die im UML-Standard nicht vorgesehen sind, z. B. um ARIS-spezifische Eigenschaften wie Mehrsprachigkeit für Textattribute und Stereotypen für Diagramme.

§ UML 1.4 Compatibility Profile UML 1.4 ist nicht vollständig aufwärts-kompatible zu UML 2. Einige Konstrukte und Standardstereotypen aus UML 1.4 werden in UML 2 nicht mehr unterstützt. Dieses Profil wird von der UML-Migration verwendet, um sicherzustellen, dass solche Konstrukte bei der Migration nach UML 2 nicht verloren gehen.


144

6.2 Verwendung von Profilen

6.2.1 Zuordnung von Profilen zu einem Paket

Bevor Sie Stereotypen eines Profils verwenden können, müssen Sie das Profil dem Paket29 zuordnen, innerhalb dessen Hierarchie die Stereotypen benötigt werden.

Die Zuordnung erfolgt auf der Eigenschaftsseite Angewendete Profile des Pakets durch Klicken auf Profile anwenden.

Abbildung 190: Eigenschaftsseite Angewendete Profile

29 Der Begriff Paket umfasst hier auch die beiden UML‐Typen Modell und Profil, bei denen es sich um spezielle Arten von Paketen handelt.


145

Der Dialog Profile anwenden wird geöffnet, der die Profile enthält, die dem Paket zugeordnet werden sollen.

Abbildung 191Dialog zur Profilauswahl

Der Dialog listet alle Profile auf, die zugeordnet werden können. Durch Aktivieren des entsprechenden Kontrollkästchens kennzeichnen Sie, dass das Profil dem Paket zugeordnet werden soll. Ist ein Profil dem Paket bereits zugeordnet, ist sein Kontrollkästchen automatisch aktiviert. In diesem Fall können Sie durch Deaktivieren des Kontrollkästchens kennzeichnen, dass die Zuordnung des Profils zum Paket entfernt werden soll. Wenn Sie im Dialog das Profil durch Klicken auf den Text markieren, wird im unteren Teil des Dialogs eine Beschreibung des Profils eingeblendet. Die gleiche Beschreibung wird auch als Tooltip angezeigt, wenn Sie den Mauszeiger für eine kurze Zeit über einem Profilnamen stehen lassen. Durch Klicken auf OK werden die ausgewählten Profile dem Paket zugeordnet.

Abbildung 192: Paket mit zugeordnetem Profil

Durch Aktivieren des Kontrollkästchens Ist strikt in Abbildung 192 können Sie festlegen, dass Einschränkungen, die das Profil definiert, nicht durch andere zugeordnete Profile wieder aufgehoben werden können30. Sobald ein Profil einem Paket zugeordnet wurde, stehen seine Stereotypen innerhalb der Pakethierarchie zur Verfügung.

30 Die vordefinierten Profile beinhalten keinerlei Einschränkungen.


146

6.2.2 Zuordnung von Stereotypen zu einem UML-Element

Die Zuordnung von Stereotypen zu einem Element erfolgt auf dessen Eigenschaftsseite Angewendete Stereotypen durch Klicken auf Stereotypen anwenden.

Abbildung 193: Eigenschaftsseite Angewendete Stereotypen

Der Dialog Stereotypen anwenden wird geöffnet, der die Stereotypen enthält, die dem Element zugeordnet werden sollen.

Abbildung 194: Dialog zur Stereotyp-Auswahl


147

Der Dialog listet alle Stereotypen auf, die zugeordnet werden können. Durch Aktivieren des entsprechenden Kontrollkästchens kennzeichnen Sie, dass der Stereotype dem Element zugeordnet werden soll.

Ist ein Stereotyp bereits dem Element zugeordnet, ist sein Kontrollkästchen automatisch aktiviert. In diesem Fall können Sie durch Deaktivieren des Kontrollkästchens kennzeichnen, dass die Zuordnung des Stereotyps zum Element entfernt werden soll.

Wenn Sie im Dialog den Stereotyp durch Klicken auf den Text markieren, wird im unteren Teil des Dialogs eine Beschreibung des Stereotyps eingeblendet. Die gleiche Beschreibung wird auch als Tooltip angezeigt, wenn Sie den Mauszeiger für eine kurze Zeit über einem Stereotypnamen stehen lassen.

Durch Klicken auf OK werden die gewählten Stereotypen dem Element zugeordnet.

Abbildung 195: UML‐Klasse mit zugeordnetem Stereotyp

Die Zuordnung von Stereotypen kann auch für mehrere Elemente gleichzeitig erfolgen. Markieren Sie hierzu die entsprechenden Elemente im Explorer‐Baum oder im Diagramm und zeigen Sie deren Eigenschaften an.

Abbildung 196: Eigenschaftsseite Angewendete Stereotypen für zwei markierte Klassen

Es werden alle den markierten Elementen zugeordneten Stereotypen angezeigt. Ist ein Stereotyp nicht allen markierten Elementen zugeordnet, wird der Eintrag in der Tabelle in grauer statt schwarzer Schrift

angezeigt. Durch Klicken auf Stereotypen anwenden können Stereotypen allen markierten Klassen gleichzeitig hinzugefügt werden.

Die Stereotypen des Standardprofils definieren keine neuen Eigenschaften. Die Anzeige und Bearbeitung der entsprechenden Eigenschaftswerte werden im nachfolgenden Kapitel über benutzerdefinierte Profile erörtert.


148

6.2.3 Stereotypen in der Leiste Symbole von Diagrammen

Die Zuordnung eines Profils zu einem Paket wirkt sich auf die Leiste Symbole der im Paket enthaltenen Diagramme aus. Für jedes Symbol, für dessen Metaklasse das Profil einen Stereotyp definiert, wird ein weiteres Symbol mit dem Namen des Stereotyps angeboten.

Abbildung 197: Konfigurationsdialog der Leiste Symbole mit Stereotypsymbolen

Abbildung 197 zeigt den Konfigurationsdialog der Leiste Symbole eines Klassendiagramms, dessen Paket das Standard-Profil zugeordnet wurde. Zusätzlich zu den normalen Symbolen werden dort auch Symbole für die entsprechenden Stereotypen angeboten. Der jeweils zugrunde liegende Symbolname wird hinter dem Stereotypnamen in Klammern angezeigt.


149

Wenn Sie beispielsweise der Leiste Symbole eines solchen Klassendiagramms das Symbol Auxiliary (Class) hinzufügen und für dieses Symbol ein Element im Diagramm erzeugen, wird im Diagramm eine neue Klasse angelegt und dieser Klasse wird automatisch der Stereotyp «Auxiliary» zugeordnet.

Abbildung 198: Erzeugung einer stereotypisierten Klasse mit Hilfe eines entsprechenden Symbols


150

6.3 Benutzerdefinierte UML-Profile

ARIS UML Designer unterstützt das Erstellen benutzerdefinierter UML-Profile mit Hilfe von UML-Profildiagrammen. Die Profile stehen unmittelbar nach Erstellung innerhalb der Datenbank zur Verfügung, in der sie modelliert sind. Möchten Sie ein solches benutzerdefiniertes Profil in einer anderen Datenbank verwenden, können Sie es mit Hilfe von ARIS-Standardfunktionalitäten wie Merge oder XML-Export und -Import in andere Datenbanken übertragen.

6.3.1 Der UML-Metamodellgenerator

Die Profilmodellierung in ARIS UML Designer erfolgt gemäß der UML-Spezifikation, d. h., sowohl das Metamodell als auch seine Metaklassen werden im Profildiagramm grafisch dargestellt und durch Kanten mit den Elementen aus dem Profil in Beziehung gesetzt. Um ein Profil selbst erstellen zu können, benötigen Sie daher zunächst das UML-Metamodell mit seinen Metaklassen. Das UML-Metamodell können Sie mit Hilfe des Metamodellgenerators in der Datenbank erstellen.

Abbildung 199: Start des UML-Metamodellgenerators im Kontextmenü einer Gruppe

Sie können den Metamodellgenerator im Kontextmenü einer ARIS-Gruppe durch Klicken auf UML-Metamodelle generieren starten. Alternativ dazu können Sie auf die gleichnamige Schaltfläche der Funktionsleiste Inhalt klicken.


151

Abbildung 200: Start des UML-Metamodellgenerators in der Funktionsleiste für eine markierte Gruppe

Der Dialog zur Generierung des UML-Metamodells bietet Ihnen die Möglichkeit, die Sprache festzulegen, in der das Metamodell in der Datenbank erzeugt wird.

Abbildung 201: UML-Metamodellgenerator


152

Folgende Optionen stehen zur Wahl: § Originale Metamodell-Namen verwenden (empfohlen)

In diesem Fall werden die Originalnamen aus dem UML-Metamodell verwendet, was wir aufgrund der Tatsache, dass die UML-Spezifikation nur in Englisch existiert, grundsätzlich auch empfehlen. Während einige Metaklassen auch mit deutschem Namen einfach zu identifizieren sind, z. B. entspricht dem Original Class im Deutschen Klasse, ist das bei einigen Metaklassen mitunter schwieriger, z. B. Original RemoveStructuralFeatureValueAction im Vergleich zum Deutschen Entferne-Strukturmerkmalwert-Aktion. Die Namen werden bei dieser Option nur unter der Alternativsprache der Datenbank abgelegt, sodass Sie unabhängig von der beim Anmelden gewählten Datenbankpflegesprache immer die originalen Metamodellnamen sehen.

§ Aktuelle Metamodelsprache Bei dieser Option werden die Namen in der Sprache angelegt, die Sie in den allgemeinen Optionen als Metamodellsprache gewählt haben (siehe Kapitel 3.4.2 UML - Allgemein). Auch in diesem Fall werden die Namen nur unter der Alternativsprache der Datenbank angelegt. Haben Sie beispielsweise als Metamodellsprache Deutsch gewählt und als Alternativsprache in der Datenbank Englisch, werden die deutschen Metamodellnamen unter der Datenbankpflegesprache Englisch gespeichert.

§ Datenbankpflegesprachen verwenden Die Generierung erfolgt für jede Datenbankpflegesprache in der entsprechenden Sprache, d. h., wenn Sie mit der Datenbankpflegesprache Deutsch angemeldet sind, werden die Metamodelnamen in Deutsch angezeigt, sind Sie in Englisch angemeldet, werden die Originalnamen angezeigt.

Der Metamodellgenerator erzeugt drei Metamodelle in der Datenbank.

Abbildung 202: Generierte Metamodelle

Das Metamodell PrimitiveTypes definiert die einfachen Datentypen, die vom UML-Metamodell verwendet werden. Es ist ebenfalls Bestandteil des offiziellen UML-Standards der OMG.

Abbildung 203: Metamodell PrimitiveTypes


153

Beim Metamodell Base handelt es sich um eine ARIS-spezifische Erweiterung, die UML-Elemente und Diagramme um einige ARIS-spezifische Eigenschaften ergänzt (siehe dazu auch Kapitel 2.4.1.1 Root).

Abbildung 204: Metamodell Base

Das Metamodell UML enthält alle UML-Metaklassen, Assoziationen und Eigenschaften und als ARIS-spezifische Erweiterung auch die entsprechenden Symbol- und Diagrammtypen, die bei der Modellierung von Profilen ebenfalls eine Rolle spielen.

Abbildung 205: Kleiner Ausschnitt aus dem generierten UML-Metamodell

Bitte beachten Sie, dass Sie bei der Profilmodellierung nur die auf diese Weise generierten Metamodelle verwenden können. ARIS UML Designer identifiziert die jeweiligen Metaelemente anhand ihrer GUID und nicht anhand ihres Namens, der je nach Generatoreinstellung ganz unterschiedlich sein kann. Dadurch, dass jedes Metaelement mit einer spezifischen GUID erzeugt wird und eine GUID in einer ARIS-Datenbank nur von einem Element verwendet werden darf, ergeben sich einige Konsequenzen für die Generierung. Jedes generierte Metaelement kann nur einmal in einer Datenbank existieren. Daher sucht der Metamodellgenerator immer erst in der Datenbank nach einem bereits existierenden Element mit der entsprechenden GUID, bevor er ein neues erzeugt. Wird er fündig, wird dieses Element verwendet. Dies hat zur Folge, dass für den Fall, dass in der Datenbank bereits ein generiertes Metamodell in einer anderen Gruppe existiert, dieses in die Gruppe verschoben wird, in der der Generator gestartet wurde. Wenn Sie ein Metaelement aus dem Metamodell in ein anderes UML-Paket verschieben, es umbenennen oder auf andere Weise bearbeiten - was ausdrücklich nicht empfohlen wird-, wird dieses Metaelement beim nächsten Lauf des Metamodellgenerators wieder in seinen ursprünglichen Zustand versetzt.


154

6.3.2 Erstellung eines Profils

Erstellen Sie zunächst in einer ARIS-Gruppe des Explorer-Baums ein neues Profil und geben Sie ihm den gewünschten Namen.

Abbildung 206: Erzeugung eines neuen Profils im Explorer-Baum

Legen Sie anschließend im Profil ein Profildiagramm an.

Abbildung 207: Anlegen eines neuen Profildiagramms

Es ist wichtig, dass Sie erst das Profil anlegen und danach das Profildiagramm im Profil und nicht umgekehrt. Wenn Sie in einem Diagramm neue Elemente anlegen, werden diese innerhalb des Elements angelegt, in dem das Diagramm enthalten ist. Dadurch, dass das Profildiagramm im Profil enthalten ist, ist sichergestellt, dass alle Stereotypen, Extension-Beziehungen und Aufzählungen, die Sie im Rahmen der Profilmodellierung im Diagramm erzeugen, tatsächlich im Profil enthalten sind und nicht in einem anderen Paket. Danach ziehen Sie das Profil aus dem Explorer-Baum ins Diagramm.

Abbildung 208: Ausprägung des Profils im Profildiagramm


155

Schließlich müssen Sie das vom Metamodell-Generator erzeugte UML-Metamodell in das Profildiagramm ziehen und vom Profil zum Metamodell eine Beziehung des Typs Meta model reference anlegen.

Abbildung 209: Definition eines reinen Erweiterungsprofils

Dadurch haben Sie gekennzeichnet, dass das Profil UML in vollem Umfang unterstützt. In Kapitel 6.3.7 Erstellung eines Filter-Profils erfahren Sie, wie Sie Profile definieren, die nur eine Teilmenge von UML unterstützen. Wenn Sie in den Eigenschaften des Profils eine Beschreibung eingeben, wird diese später bei der Zuordnung des Profils zu einem Paket im Profilauswahldialog angezeigt.

Abbildung 210: Beschreibung des Profils

Abbildung 211: Benutzerdefiniertes Profil mit Beschreibung im Dialog zur Profilauswahl


156

6.3.3 Erstellung eines Stereotyps

Stereotypen werden verwendet, um eine bestimmte Semantik auszudrücken, die im UML-Standard nicht vorgesehen ist, z. B. Stereotypen «Fachklasse» und «Designklasse» zur Verdeutlichung der Bedeutung der entsprechenden Klassen, oder um neue Eigenschaften zu definieren. Die Stereotypen des UML-Standardprofils fallen in die erste Kategorie. Sie definieren keine neuen Eigenschaften. Wenn Sie einen neuen Stereotyp definieren möchten, müssen Sie ihn zunächst im Profildiagramm anlegen31.

Abbildung 212: Definition eines neuen Stereotyps

Im nächsten Schritt platzieren Sie aus dem generierten UML-Metamodell die zu erweiternde Metaklasse im Diagramm und verknüpfen den Stereotyp mittels einer Extension-Beziehung mit der Metaklasse.

Abbildung 213: Verknüpfung des Stereotyps mit der entsprechenden Metaklasse

Im Beispieldiagramm wurden die Darstellungsoptionen der Extension-Beziehung so angepasst, dass keine Multiplizitäten und Namen angezeigt werden (Extension ist eine spezielle Form der Assoziation) und bei der Metaklasse wurde die Merkmalssicht auf Details unterdrückt, damit keine Attribute angezeigt werden.

31 Natürlich könnten Sie den Stereotyp auch im Explorer-Baum erzeugen und bearbeiten. Jedoch gestaltet sich dann insbesondere die Verknüpfung mit der entsprechenden Metaklasse deutlich aufwendiger als bei grafischer Modellierung.


157

Auch für benutzerdefinierte Stereotypen gilt, dass ihre Beschreibungstexte im Dialog zur Stereotypzuordnung angezeigt werden.

Abbildung 214: Beschreibung des Stereotyps

Abbildung 215: Benutzerdefinierter Stereotyp mit Beschreibung im Dialog zur Stereotypauswahl

Wenn Sie in Paketen, denen Sie das Analyseprofil zugeordnet haben, nur Anwendungsfälle mit Stereotyp «Geschäftsanwendungsfall» erlauben möchten, können Sie das an der Extension-Beziehung im Profildiagramm durch Wählen des Kontextmenüeintrags Als ‘Benötigt‘ festlegen oder der entsprechenden Schaltfläche in der Funktionsleiste Inhalt kennzeichnen:

Abbildung 216: Kennzeichnung einer Extension-Beziehung als benötigt in der Funktionsleiste Inhalt


158

Im Profildiagramm wird an der Extension-Beziehung das Schlüsselwort {required} angezeigt32:

Abbildung 217: Extension-Beziehung mit Eigenschaft required

Diese Änderung bewirkt, dass beim Anlegen eines Anwendungsfalls in einem Paket, dem das Profil zugeordnet ist, dieser automatisch den Stereotyp «Geschäftsanwendungsfall» erhält. Das Setzen dieser Eigenschaft ist jedoch nur dann sinnvoll, wenn Sie für die entsprechende Metaklasse in Ihrem Profil nicht mehr als einen Stereotypen definiert haben.

32 Das Kennzeichnen einer Extension-Beziehung als benötigt ändert die Multiplizität des Assoziationsendes, das mit dem Stereotyp verknüpft ist, von [0..1] auf [1]. Da man die Multiplizitäten von Extension-Beziehungen i. d. R. in Diagrammen nicht anzeigt, wird stattdessen das Schlüsselwort {required} an der Kante angezeigt.


159

6.3.4 Definition neuer Eigenschaften

Sie können mit Hilfe von Stereotypen neue Eigenschaften definieren, die im UML-Metamodell nicht vorgesehen sind. Genau wie die vordefinierten Eigenschaften können die selbstdefinierten Eigenschaften einfache Datenwerte oder Beziehungen zu anderen Elementen repräsentieren. Zur Definition der neuen Eigenschaft Anforderungen für einen Stereotyp legen Sie zunächst ein neues Attribut vom UML-Typ Property an und geben ihm den entsprechenden Namen.

Abbildung 218: Erzeugung eines neuen Attributs für einen Stereotypen

Im nächsten Schritt müssen Sie den Typ der Eigenschaft festlegen. Beim Typ kann es sich um einen einfachen Datentyp, einen Aufzählungstyp, eine Metaklasse oder einen anderen Stereotyp handeln.


160

Abbildung 219: Festlegung des Attributtyps

Bitte beachten Sie, dass nur die vom UML-Metamodellgenerator erzeugten einfachen Datentypen verwendet werden dürfen. Sie finden diese in den Metamodellen PrimitiveTypes (Boolean, Integer, Real, String und UnlimitedNatural) und Base (TimeStamp). Selbst definierte einfache Datentypen werden nicht unterstützt, auch dann nicht, wenn sie die gleichen Namen wie die der generierten Metamodelle haben.


161

Die Werte der Eigenschaft Anforderungen sollen als Text eingegeben werden. Daher sollten Sie als Typ des Attributs den einfachen Datentyp String aus dem Metamodell PrimitiveTypes wählen.

Abbildung 220: Wahl des einfachen Datentyps String aus dem PrimitiveTypes-Metamodell

Der Stereotyp sieht damit wie folgt aus:

Abbildung 221: Stereotyp mit Textattribut

Wenn Sie neben dem Namen und dem Typ auch eine Beschreibung für die Eigenschaft eingegeben, wird diese bei Elementen im Eigenschaftsdialog angezeigt, denen dieser Stereotyp zugeordnet wird.

Abbildung 222: Beschreibung des Stereotypattributs


162

Bei allen Anwendungsfällen, denen der Stereotyp «Geschäftsanwendungsfall» zugeordnet ist, steht Ihnen nun auf der Eigenschaftsseite Eigenschaftswerte die neue Eigenschaft Anforderungen zur Verfügung.

Abbildung 223: Eigenschaftswert mit freier Texteingabe

Wenn Sie einen Aufzählungstyp (UML-Typ Enumeration) als Typ eines Stereotypattributs verwenden möchten, muss dieser entweder im gleichen Profil enthalten sein oder mittels einer ElementImport-Beziehung aus einem anderen Profil in das Profil des Stereotyps importiert werden33.

Abbildung 224: Definition der Eigenschaft Priorität vom Typ Priorität

Abbildung 224 zeigt einen UML-Aufzählungstyp Priorität mit den drei Aufzählungswerten hoch, normal und niedrig und ein Stereotypattribut gleichen Namens, das diesen Aufzählungstyp als Typ verwendet.

33 Um einen Aufzählungstyp aus einem anderen Profil in das Profil des Stereotyps zu importieren, erstellen Sie eine Ausprägung des Aufzählungstyps im Profildiagramm des Stereotyps und ziehen eine Kante vom Typ Element import vom Profil zum Aufzählungstyp.


163

Bei allen Anwendungsfällen, denen der Stereotyp «Geschäftsanwendungsfall» zugeordnet ist, steht Ihnen damit auf der Eigenschaftsseite Eigenschaftswerte die neue Eigenschaft Priorität mit den zuvor definierten Aufzählungswerten zur Verfügung.

Abbildung 225: Eigenschaftswert mit Auswahlliste

Eigenschaften mit Metaklassen als Typ ermöglichen es Ihnen, Elemente der entsprechenden Metaklasse als Werte zu verwenden. Wenn Sie als Typ eines Stereotypattributs eine Metaklassen verwenden möchten, gilt das Gleiche wie für einfache Datentypen: es werden nur Metaklassen unterstützt, die vom UML-Meta-modellgenerator erzeugt wurden. Wenn Sie einen Stereotyp als Typ verwenden, können Sie Elemente als Werte verwenden, denen dieser Stereotyp zugeordnet ist. Der Stereotyp muss entweder im gleichen Profil definiert sein oder ins Profil importiert werden.


164

6.3.5 ARIS-spezifische Merkmale benutzerdefinierter Eigenschaften

Wenn Sie die Werte einer benutzerdefinierten Eigenschaft mehrsprachig, d. h. in Abhängigkeit von der bei der Anmeldung ausgewählten Datenbankpflegesprache pflegen möchten, müssen Sie dies bei dem entsprechenden Stereotyp-Attribut definieren. Stereotyp-Attribute sind vom UML-Typ Property. Da die UML-Spezifikation eine Mehrsprachigkeit von Elementen nicht kennt, gibt es für den UML-Typ Property keine Eigenschaft, mit deren Hilfe Sie festlegen können, ob das UML-Property eine mehrsprachige Eigenschaft definiert oder nicht. ARIS-spezifischen Eigenschaften wie Mehrsprachigkeit werden für die Definition von Profilen durch das OMF Extension Profile zur Verfügung gestellt. Dabei handelt es sich um ein vordefiniertes Profil in ARIS UML Designer, das Sie genau wie das Standardprofil direkt verwenden können. Um innerhalb Ihres Profils mehrsprachige Eigenschaften definieren zu können, müssen Sie zunächst das OMF Extension Profile auf Ihr Profil anwenden.

Abbildung 226: Zuordnung des vordefinierten Profils OMF Extension Profile zum benutzerdefinierten Profil Analyseprofil


165

Danach öffnen Sie den Eigenschaftsdialog des Stereotypattributs, für dessen Werte eine mehrsprachige Pflege möglich sein soll, und ordnen ihm den Stereotyp ExtendedProperty zu.

Abbildung 227: Zuordnung des Stereotyps «ExtendedProperty» zum Stereotypattribut Anforderungen


166

Auf der Eigenschaftsseite Eigenschaftswerte des Stereotypattributs stehen Ihnen dann die beiden ARIS-spezifischen Eigenschaften isLanguageDependent und isStyledDocument zur Verfügung.

Abbildung 228: ARIS-spezifische Eigenschaften eines Stereotypattributs

Mit isLanguageDependent können Sie festlegen, ob Eigenschaftswerte, die auf diesem Stereotypattribut basieren, abhängig von der jeweiligen Datenbankpflegespreche gespeichert werden. Mit isStyledDocument können Sie festlegen, ob bei der Bearbeitung dieser Eigenschaftswerte Textformatierung zur Verfügung steht.


167

Abbildung 229: Bearbeitung eines Eigenschaftswertes mit Textformatierung


168

6.3.6 Vererbungsbeziehungen zwischen Stereotypen

Wenn verschiedene Stereotypen jeweils gleiche Eigenschaften definieren, empfiehlt es sich, für die gemeinsamen Eigenschaften einen Stereotyp zu definieren und die anderen von diesem erben zu lassen.

Abbildung 230: Vererbungsbeziehungen zwischen Stereotypen

Abbildung 230 erweitert das Beispiel aus Abbildung 224 um die beiden Stereotypen «Fachklasse» und Analyseelement. Der Stereotyp «Analyseelement» ist abstrakt34 und definiert die Eigenschaft Ansprechpartner vom Typ String. Die beiden übrigen Stereotypen erben jeweils von «Analyseelement». Dadurch zeigen alle Anwendungsfälle mit Stereotyp «Geschäftsanwendungsfall» und alle Klassen mit Stereotyp «Fachklasse» auf ihrer Eigenschaftsseite Eigenschaftswerte die Eigenschaft Ansprechpartner.

34 Dass der Stereotyp abstrakt ist, erkennen Sie daran, dass sein Name im Diagramm kursiv dargestellt ist.


169

Abbildung 231: Eigenschaftswerte mit geerbter Eigenschaft

Dadurch, dass der Stereotyp «Analyseelement» abstrakt ist und auch selbst keine Metaklasse erweitert, kann er selbst auch keinem UML-Element zugeordnet werden. Er dient lediglich dazu, eine Eigenschaft zu definieren, die mehreren Stereotypen gemeinsam sein soll. Sie können natürlich auch Vererbungsbeziehungen zwischen nicht-abstrakten Stereotypen erstellen.


170

6.3.7 Erstellung eines Filter-Profils

In Kapitel 6.3.2 Erstellung eines Profils haben Sie gesehen, wie Sie ein Profil erstellen, das UML vollständig unterstützt, indem Sie eine Beziehung vom Typ Meta model reference zwischen dem Profil und dem UML-Metamodell erzeugen. Innerhalb eines Pakets, dem ein solches Profil zugeordnet ist, stehen in Diagrammen zusätzlich zu den Stereotypen-basierten Symbolen auch weiterhin alle UML-Symbole zur Verfügung. Wenn Sie die Beziehung Meta model reference im Profil der Abbildung 213 löschen35, zeigt die Leiste Symbole eines Anwendungsfalldiagramms nur noch zwei Symbole für den Stereotyp «Geschäftsanwendungsfall» an, da dieser der einzig erlaubte Elementtyp ist.

Abbildung 232: Leiste Symbole im Anwendungsfalldiagramm

Die Symbolleisten anderer Diagrammtypen, in denen Anwendungsfälle nicht erlaubt sind, sind vollständig leer. Sie können einzelne Metaklassen gezielt in das Profil aufnehmen, in dem Sie diese im Profildiagramm platzieren und sie mit Hilfe der Beziehung Meta class reference mit dem Profil verknüpfen.

Abbildung 233: Profil, das nur wenige Metaklassen unterstützt

Dieses Profil legt fest, dass in Diagrammen alle Elemente der Typen Actor, Association und Property verwendet werden dürfen und Elemente des Typs UseCase, wenn ihnen der Stereotyp «Geschäftsanwendungsfall» zugeordnet ist.

35 Mit Löschen ist hier das Löschen des Elements und nicht nur seiner grafischen Ausprägung im Diagramm gemeint.


171

Abbildung 234: Leiste Symbole eines Anwendungsfalldiagramms bei Verwendung des Profils

Diese Art der Profil-Definition erfordert bereits einige Kenntnisse des UML-Metamodells und seiner grafischen Repräsentation in Diagrammen. Wäre im obigen Beispiel die Metaklasse Property nicht dem Profil zugeordnet, stünde in Diagrammen das Symbol Association nicht zur Verfügung, da eine Kantenpräsentation einer Assoziation nur in Verbindung mit ihren beiden Assoziationsenden angelegt werden kann, welche vom Typ Property sind. Zusätzlich zu den Symbolen, deren Metaklassen durch das Profil erlaubt sind, zeigt die Leiste Symbole auch alle Kantensymbole an, die eine Metaassoziation repräsentieren36 und deren beiden Endtypen ebenfalls durch das Profil erlaubt sind. In Abbildung 234 trifft dies auf das Symbol Owning classifier zu. Es repräsentiert keine Metaklasse, sondern die Metaassoziation A_ownedUseCase_classifier, durch die ein Klassifizierer Anwendungsfälle besitzen kann. Die beiden im Profil erlaubten Metaklassen UseCase und Actor erben von der Metaklasse Classifier, sodass Beziehungen dieses Typs auch bei Verwendung des Profils möglich sind. Bitte beachten Sie, dass ein Profil nur eine Auswirkung darauf hat, was Sie in einem Diagramm neu anlegen können. Bereits existierende und vom Profil nicht unterstützte Diagramminhalte bleiben auch nach Zuordnung des Profils zum einem dem Diagramm im übergeordneten Paket erhalten.

36 Mit Hilfe solcher Symbole erzeugen Sie eine direkte Beziehung zwischen zwei UML-Elementen.


172

6.3.8 Erstellung eines Diagrammstereotyps

Mit ARIS UML Designer können Sie Stereotypen für Diagramme definieren, um diese um benutzerdefinierte Eigenschaften zu erweitern oder um festzulegen, welche Inhalte in den Diagrammen erlaubt sein sollen. Stereotypen für Diagramme werden genau wie Stereotypen für Elemente erstellt, mit dem Unterschied, dass die Extension-Beziehung vom Stereotyp zu einem Metadiagramm statt zu einer Metaklasse angelegt wird. Metadiagramme werden vom Metamodellgenerator als UML-Komponenten mit Stereotyp «MetaDiagram» erzeugt.

Abbildung 235: Definition eines Stereotyps für Klassendiagramme

Die Definition neuer Eigenschaften erfolgt genau wie in Kapitel 6.3.4 Definition neuer Eigenschaften für Elemente beschrieben. Darüber hinaus können Sie festlegen, welche Symbole in der Leiste Symbole eines Diagramms, dem der Stereotyp zugeordnet ist, enthalten sein können. Zu diesem Zweck müssen Sie dem Profil das in Kapitel 6.3.5 ARIS-spezifische Merkmale benutzerdefinierter Eigenschaften vorgestellte OMF Extension Profile zuordnen und dem Stereotyp den Stereotyp «DiagramStereotype» zuordnen.

Abbildung 236: Zuordnung des vordefinierten Stereotyps «DiagramStereotype» zum benutzerdefinierten Stereotyp «Analyseklassendiagramm»


173

Der Stereotyp «DiagramStereotype» definiert drei neue Eigenschaften für Stereotypen, mit deren Hilfe Sie festlegen können, welche Symbole im entsprechenden Diagramm erlaubt sind:

supportedMetaClass

Hier können Sie alle Metaklassen hinzufügen, deren Symbole vom Diagramm unterstützt werden sollen, ohne dass Sie Einschränkungen hinsichtlich des zu verwendenden Symbols oder Stereotyps machen wollen.

supportedStereotype

Hier können Sie alle Stereotypen hinzufügen, deren Symbole vom Diagramm unterstützt werden sollen. Dies ist dann sinnvoll, wenn die entsprechenden Elemente ohne Stereotyp im Diagramm nicht erlaubt sein sollen.

supportedSymbol

Hier können Sie alle Symbole hinzufügen, die im Diagramm erlaubt sein sollen. Dies ist dann sinnvoll, wenn Sie für eine Metaklasse oder einen Stereotyp nur bestimmte Symbole im Diagramm erlauben möchten. Solange Sie bei dieser Eigenschaft kein Symbol angeben, sind (wie in Kapitel 6.3.7 Erstellung eines Filter-Profils beschrieben) auch alle auf Metassoziationen basierenden Kantensymbole im Diagramm erlaubt, deren Endtypen durch das Profil und die beiden anderen Eigenschaften unterstützt werden. Sobald Sie hier jedoch ein Symbol angeben, müssen Sie auch alle auf Metaassoziationen basierenden Kantensymbole, die im Diagramm erlaubt sein sollen, dieser Eigenschaft hinzufügen. Wenn Sie bei keiner der drei Eigenschaften einen Wert eingeben, sind alle Symbole im Diagramm erlaubt.


174

Mit der folgenden Konfiguration legen Sie fest, dass die Leiste Symbole von Klassendiagrammen mit Stereotyp «Analyseklassendiagramm» alle Symbole für die UML-Typen Comment und Constraint, alle Symbole für den UML-Typ Class mit Stereotyp «Fachklasse» und die Symbol Association, Constrained element und Annotated element beinhaltet.

Abbildung 237: Konfiguration eines Diagrammstereotyps

Im Profildiagramm wird der Stereotyp mit dieser Konfiguration wie folgt angezeigt:

Abbildung 238: Konfigurierter Diagrammstereotyp im Profildiagramm


175

Mit dieser Konfiguration kann die Leiste Symbole eines Klassendiagramms mit Stereotyp «Analyseklassendiagramm» folgende Symbole beinhalten:

Abbildung 239: Leiste Symbole eines Analyseklassendiagramms

Wenn Sie für ein Metadiagramm in Ihrem Profil genau einen Stereotyp definiert haben und in Paketen, denen das Profil zugeordnet ist, Diagramme dieses Typs nur in Verbindung mit diesem Stereotyp angelegt werden sollen, können Sie durch Kennzeichnen der Extension-Beziehung als benötigt festlegen, dass der Stereotyp bei Anlegen des Diagramms automatisch zugeordnet wird (siehe dazu auch Kapitel 6.3.3 Erstellung eines Stereotyps).


176

7 Unterschiede zu ARIS Architect und ARIS Designer

Dieses Kapitel zeigt Ihnen, welche Unterschiede in der Bedienung von ARIS UML Designer und ARIS Architect/ARIS Designer bestehen und wodurch diese begründet sind.

7.1 Relevanz des Modells und seiner Diagramme im Hinblick auf die Semantik

Zwischen der klassischen ARIS-Methode und UML gibt es einen grundsätzlichen Unterschied, der große Auswirkungen darauf hat, wie Sie mit ARIS Architect/ARIS Designer und ARIS UML Designer arbeiten. In UML ist die Semantik eines Modells (nicht Diagramms) vollständig in seinen Elementen und deren Eigenschaften und Beziehungen enthalten. Diagramme stellen lediglich eine grafische Sicht auf dieses Modell dar. Würden Sie alle UML-2-Diagramme in einer ARIS-Datenbank löschen, bliebe die Semantik des UML-Modells vollständig erhalten. Zudem werden viele UML-Elemente nicht grafisch in Diagrammen dargestellt und erscheinen dort höchstens in Textform innerhalb der grafischen Präsentation eines übergeordneten Elements. In der ARIS-Methode kommt den Diagrammen eine viel größere Bedeutung zu. Für einige ARIS-Objekte entscheidet erst das Symbol, durch das sie grafisch in einem Diagramm repräsentiert werden, welche Semantik sie besitzen37. Demzufolge tragen in der ARIS-Methode die Diagramme wesentlich zur Semantik des Modells bei. Umgekehrt spielen Objekte und Beziehungen, die nicht in einem Diagramm grafisch repräsentiert werden, in der ARIS-Methode keine Rolle. Bei einer Datenbankreorganisation38 werden daher alle ARIS-Objekte und ARIS-Beziehungen ohne Ausprägung in einem Diagramm gelöscht. UML-2-Elemente bleiben bei einer Datenbankreorganisation hingegen erhalten, da allein die Tatsache, dass ein UML-Element in keinem Diagramm ausgeprägt ist, keinen Rückschluss darauf zulässt, ob es noch benötigt wird oder nicht.

7.2 Die Funktionen Speichern und Rückgängig/Wiederherstellen

Im Gegensatz zum ARIS-Standard werden in ARIS UML Designer viele Elemente und Beziehungen nicht grafisch in Diagrammen, sondern im Explorer-Baum und in Eigenschaftsdialogen erzeugt und bearbeitet. Daher kommt dem Explorer-Baum in UML eine weitaus größere Bedeutung als Modellierungskomponente zu als dies im ARIS-Standard der Fall ist. Dort wird der Baum in erster Linie zur Bearbeitung der Gruppenhierarchie, zur Erzeugung von Diagrammen und zur Navigation verwendet. Durch ARIS UML Designer werden die im Explorer-Baum vorgenommenen Änderungen erst beim Speichern in der Datenbank gesichert. Zudem können die Änderungen, solange sie noch nicht gespeichert sind, wieder rückgängig gemacht werden. Lediglich Funktionalitäten, die auf dem ARIS-Server abgearbeitet werden, erfordern ein sofortiges Speichern der Änderungen, z. B. das Kopieren von Strukturen im Explorer. Abgesehen von der Bearbeitung der grafischen Eigenschaften einer Elementausprägung können UML-Elemente in ARIS UML Designer in verschiedenen Komponenten bearbeitet werden. So ist es beispielsweise vollkommen unerheblich, ob Sie eine Klasse im Explorer-Baum oder in einem der Diagramme markieren, um Attribute, Operationen oder andere Eigenschaften auf der Eigenschaftsseite Allgemein zu bearbeiten. Alle Änderungen, die in einer Komponente von ARIS UML Designer an einem Element vorgenommen wurden, werden augenblicklich auch in allen anderen Komponenten angezeigt. Insbesondere der

37 Ein Beispiel ist das Objekt Regel. Erst die grafische Darstellung in einem Diagramm mit einem Symbol XOR, UND, XOR/UND, OR/XOR usw. legt die genaue Bedeutung fest. 38 Administrative Funktionalität in ARIS Architect zum Löschen nicht mehr benötigter Objekte und Kanten.


177

Explorer-Baum zeigt in Diagrammen neu angelegte oder umbenannte Elemente sofort an und nicht erst nach dem Speichern, wie dies bei ARIS Architect/ARIS Designer der Fall ist. Darüber hinaus kann eine Änderung an einem Element im Explorer-Baum oder in einem Diagramm Änderungen in anderen Diagrammen zur Folge haben, wenn dort ausgeprägte Kanten oder Schachtelungsbeziehungen durch die Änderung ungültig werden. Aufgrund der genannten Tatsachen zeigt ARIS UML Designer im Hinblick auf die Funktionen Speichern und Rückgängig/Wiederherstellen ein anders Verhalten als ARIS Architect/ARIS Designer:

· Die Funktion Speichern sichert immer alle Änderungen, die Sie vorgenommen haben. Auch Änderungen im Explorer-Baum werden erst zu diesem Zeitpunkt gespeichert.

· Die Funktionen Rückgängig/Wiederherstellen arbeiten global über Explorer- und Diagrammgrenzen hinweg.

7.3 Öffnen von Diagrammen

Wenn Sie in ARIS Architect/ARIS Designer ein Diagramm öffnen, wird dieses beim Öffnen für den Schreibzugriff für andere Benutzer gesperrt oder eine Meldung wird eingeblendet, dass es nur lesend geöffnet werden kann, falls bereits ein anderer Benutzer das Diagramm geöffnet hat. Um zu verhindern, dass ein Diagramm automatisch für Änderungen durch andere Benutzer gesperrt wird, wenn Sie es nur anzusehen möchten, werden in ARIS UML Designer Diagramme immer lesend geöffnet. Erst beim ersten Versuch, das Diagramm zu ändern, wird die entsprechende Sperre vom Server angefordert und das Diagramm aktualisiert, sodass Sie das Diagramm im aktuellen Zustand bearbeiten. Falls es bereits durch einen anderen Anwender in Bearbeitung ist, erhalten Sie eine entsprechende Meldung. Beim Speichern werden in ARIS UML Designer alle Sperren wieder freigegeben.

7.4 Elementhierarchien

Während sich Hierarchien von Objekten in ARIS Architect/ARIS Designer nur grafisch mit Hilfe von entsprechenden Kantentypen in Diagrammen oder durch Hinterlegung eines übergeordneten Objekts mit einem Diagramm mit untergeordneten Objekten darstellen lässt, werden in ARIS UML Designer Element-Hierarchien direkt im Explorer-Baum dargestellt, bei denen das übergeordnete Element die untergeordneten Elemente besitzt.

7.5 Grafische Kanten in Diagrammen

In ARIS Architect/ARIS Designer zeigt eine grafische Kante in einem Diagramm immer genau eine Kantendefinition an. In ARIS UML Designer kann eine grafische Kante eine ganze Kette von Elementen und Beziehungen darstellen. Genaueres zu diesem Thema finden Sie in Kapitel 4.2 Komplexität von Kantenpräsentationen.

7.6 Hinterlegungen

In der ARIS-Methode ist für jeden Objekttyp festgelegt, mit welchen und mit wie vielen Diagrammtypen er hinterlegt werden darf. ARIS UML Designer nutzt für Diagrammhinterlegungen einen anderen Ansatz, der in Kapitel 3.2.2.4 Verknüpfte Diagramme (Elemente) genauer vorgestellt wird.


178

7.7 Erstellung von ARIS-Skripten

ARIS UML Designer stellt für die Bearbeitung von UML-Inhalten in ARIS-Reporten und Makros spezielle Funktionalitäten bereit. Diese werden anhand einiger Beispielskripte in den Report -und Makro-Kategorien UML-Beispielskripte vorgestellt.


179

8 Unterschiede zu ARIS UML Designer 7.x

Mit ARIS UML Designer 9 wurde sowohl ein neuer Ansatz zur Abbildung von UML auf ARIS als auch ein neuer Ansatz zur Integration von UML mit der klassischen ARIS-Modellierung eingeführt. Daraus ergeben sich einige Änderungen im Vergleich zu ARIS UML Designer 7.x, die nachfolgend erläutert werden.

8.1 UML-Version

Der offensichtlichste Unterschied betrifft die jeweils unterstützte UML-Version. ARIS UML Designer 7.x unterstützt UML 1.4 und ARIS UML Designer 9 die UML-Version 2.5. ARIS UML Designer 9 unterstützt alle in der UML-2.5-Spezifikation enthaltenen Elementtypen und Eigenschaften. Bis auf Zeitablauf-Diagramme, die nur rudimentär unterstützt werden, werden alle UML 2.5-Diagrammtypen unterstützt. Damit ist die UML-Unterstützung von ARIS UML Designer 9 deutlich umfangreicher ausgefallen als von ARIS UML Designer 7.x.

8.2 Abbildung von UML auf ARIS

Die Abbildung von UML 1.4 auf die ARIS-Methode stellte eine Mischung aus UML- und Geschäftsprozess-Typen dar. Teilweise beruhte die Entscheidung, ob ein UML-Elementtyp auf einen ARIS-Objekttyp oder ARIS-Kantentyp abgebildet wurde, darauf, wie dieser in Diagrammen grafisch dargestellt werden sollte. Damit war auch die Wiederverwendbarkeit von Geschäftsprozessobjekten als UML-Elemente in der ARIS-Methode fest vorgegeben. Elementhierarchien wurden über ARIS-Kanten zwischen den entsprechenden Objekten realisiert. So wurde beispielsweise die Schachtelung einer Klasse in einem Paket mit Hilfe einer Kante des Typs CT_IS_NESTED abgebildet. Das konnte zur Folge haben, dass eine Klasse über mehrere Kanten dieses Typs in verschiedenen Paketen enthalten war, was in UML nicht erlaubt ist. Da manche UML-Elemente selbst auf Kanten abgebildet wurden, z. B. Dependency, unterstützte ARIS UML Designer 7.x intern auch Kanten als Quelle oder Ziel von Kanten. Die Abbildung von UML 2.5 auf die ARIS Methode erfolgte nach dem neuen Ansatz, der in Kapitel 4 Abbildung von UML auf das ARIS-Objektmodell vorgestellt wird. Für jeden UML-Elementtyp existiert genau ein entsprechender UML-2-Objekttyp in der ARIS-Methode. Alle UML-Elemente werden auf ARIS-Gruppen mit der entsprechenden Objekttypnummer abgebildet. Diese Änderungen bedingen auch, dass Datenbanken mit von ARIS UML Designer 7.x erstellten UML 1.4 Inhalten nach UML 2 konvertiert werden müssen, bevor diese Inhalte von ARIS UML 9 angezeigt und bearbeitet werden können. Weitere Informationen hierzu finden Sie in Kapitel 3.5.4 Datenübernahmen aus ARIS UML Designer 7.x.

8.3 Wiederverwendung von Geschäftsprozessobjekten in UML

Das von ARIS UML Designer 7.x bekannte Konzept der direkten Wiederverwendung einiger fest definierter ARIS-Objekttypen in UML wurde in ARIS UML Designer 9 durch ein neues, flexibles Konzept ersetzt, sodass Sie als Benutzer entscheiden können, welche Geschäftsprozessobjekte Sie auf welche UML-Elemente abbilden. Zu diesem Zweck wurde die direkte Wiederverwendung durch eine neue Wiederverwendungsbeziehung ersetzt. Dieses Konzept wird in Kapitel 5 Verknüpfung von Geschäftsprozess- mit UML-Modellierung ausführlich vorgestellt.


180

8.4 Speichern und Rückgängig machen von Änderungen

In ARIS UML Designer 7.x wurden Diagramme einzeln gespeichert, jedoch wurden beim Speichern eines einzelnen Diagramms immer alle geänderten UML-Elemente gespeichert, also auch die Elemente, die ausgehend von anderen Diagrammen geändert wurden. Änderungen im UML-Paketbaum wurden immer direkt gespeichert, sodass diese auch nicht rückgängig gemacht werden konnten. ARIS UML Designer 9 speichert immer alle Änderungen. Die Funktionalität Rückgängig/Wiederherstellen arbeitet global über alle Komponenten und Diagramme hinweg. Kapitel 7.2 Die Funktionen Speichern und Rückgängig / Wiederherstellen beschreibt die Motivation für dieses geänderte Verhalten in ARIS UML Designer 9.

8.5 Integration von UML in den Explorer-Baum

ARIS UML Designer 7.x beinhaltete neben dem Explorer-Baum einen zweiten Baum, den UML-Paketbaum, zur UML-konformen Anzeige und Verwaltung der UML-Inhalte und Hierarchien. Für jedes UML-Paket, UML-Modell und UML-Profil wurde sowohl eine ARIS-Gruppe als auch ein ARIS-Objekt angelegt, um die UML-Pakethierarchie im Explorer-Baum in Form einer ARIS-Gruppenhierarchie repräsentieren und alle im Paket enthaltenen UML-Elemente in der entsprechenden Gruppe des Pakets ablegen zu können. Dabei konnte es insbesondere beim Arbeiten im Explorer-Baum vorkommen, dass die UML-Struktur beider Bäume nicht mehr synchron war und sie unterschiedliche UML-Hierarchien angezeigten. In ARIS UML Designer 9 wurde UML vollständig in den Explorer-Baum integriert. Zudem werden UML-Elemente auf Gruppen mit der entsprechenden Objekttypnummer abgebildet, sodass es keine zwei verschiedenen ARIS-Elemente (Gruppe + Objekt) für ein UML-Paket mehr gibt.

8.6 Eigenes Fenster für ARIS UML Designer

Die Funktionalitäten und Komponenten von ARIS UML Designer 7.x waren vollständig in das Fenster von ARIS Architect bzw. ARIS Designer integriert. Durch die unterschiedlichen Konzepte, insbesondere bezüglich des Explorer-Baums, des Speicher- und Rückgängig-Verhaltens von ARIS UML Designer 9 und ARIS Architect/ARIS Designer wurde eine Trennung der beiden Anwendungen in zwei verschiedene Fenster notwendig. Beide sind jedoch funktional eng integriert, sodass eine einfache Navigation von einer Anwendung in die andere möglich ist. In Kapitel 5.3 Navigation zwischen <aba>/ARIS Designer und ARIS UML Designer finden Sie genauere Informationen zu diesem Thema.

8.7 XMI-Schnittstelle

ARIS UML Designer 7.x unterstützt das XMI-Format UML 1.4/XMI 1.1, UML, ARIS UML Designer 9 unterstützt UML 2.5/XMI 2.1. Im Gegensatz zu ARIS UML Designer 7.x identifiziert der XMI Import von ARIS UML Designer 9 bereits in ARIS existierende Inhalte der zu importierenden XMI-Datei und legt diese nicht doppelt an. Darüber hinaus unterstützt die XMI-Schnittstelle von ARIS UML Designer 9 auch den Export und Import von Diagramminformationen nach dem UML Diagram Interchage Standard. Mit Hilfe von XSL-Transformationen, die Sie in der Administrationskomponente auf dem ARIS-Server verwalten, können Sie individuell Anpassungen an Fremdformaten sowohl für den XMI-Export als auch für den XMI-Import vornehmen. Weitere Informationen hierzu finden Sie in Kapitel 3.5.3 XMI-Ressourcen.


181

9 Anhang

9.1 UML-Fachbegriffe in Deutsch und Englisch

Die in diesem Dokument verwendeten deutschen UML-Fachbegriffe sind hier zusammen mit den jeweiligen englischen Originalbegriffen aufgeführt.

9.1.1 Diagramme

Deutsche Diagrammnamen UML-Diagrammnamen

Aktivitätsdiagramm Activity Diagram Anwendungsfalldiagramm Use Case Diagram Interaktionsübersichtdiagramm Interaction Overview Diagram Klassendiagramm Class Diagram Kommunikationsdiagramm Communication Diagram Komponentendiagramm Component Diagram Kompositionsstrukturdiagramm Composite Structure Diagram Objektdiagramm Object Diagram Paketdiagramm Package Diagram Profildiagramm Profile Diagram Protokollzustandsdiagramm Protocol State Machine Diagram Sequenzdiagramm Sequence Diagram Verteilungsdiagramm Deployment Diagram Zeitablauf-Diagramm Timing Diagram Zustandsautomatendiagramm State Machine Diagram


182

9.1.2 Elemente

Deutsche Elementnamen UML-Elementnamen Abstraktion Abstraction Aktion Action Aktivität Activity Artefakt Artifact Assoziation Association Attribut Property / Attribute Attributwert Slot Aufzählungstyp Enumeration Aufzählungswert Enumeration Literal Auslöser Trigger Einfacher Datentyp Primitive Type Generalisierung Generalization Instanz Instance Specification Interaktion Interaction Klasse Class Kommentar Comment Komponente Component Kontrollfluss Control Flow Manifestation Manifestation Modell Model Operation Operation Paket Package Port Port Profil Profile Protokollzustandsautomat Protocol State Machine Protokollzustandsübergang Protocol Transition Schnittstelle Interface Stereotyp Stereotype Zustandsautomat State Machine Zustandsübergang Transition


183

9.2 Glossar

Booch-Methode

(Objektorientierte Modellierungssprache, entwickelt von Grady Booch, Vorläufer von UML)

BPMN (Business Process Model and Notation)

(Modellierungssprache für Geschäftsprozesse, von der OMG standardisiert)

MOF (Meta Object Facility)

(Architektur für Metamodelle und deren Implementierung, von der OMG standardisiert)

OMF – Object Modeling Framework

(ARIS-Implementierung von MOF, Teil der Architektur von ARIS UML Designer)

OMG – Object Management Group

(Non-profit Organisation, veröffentlicht Standards für die IT-Industrie)

OMT – Object-Modeling Technique

(Objektorientierte Modellierungssprache, entwickelt von James Rumbaugh et al., Vorläufer von UML)

OOSE – Object-Oriented Software Engineering

(Objektorientierte Modellierungssprache, entwickelt von Ivar Jacobson, Vorläufer von UML)

UML – Unified Modeling Language

(Objektorientierte Modellierungssprache, von der OMG standardisiert)

W3C – World Wide Web Consortium

(Gremium zur Standardisierung von Techniken im World Wide Web)

XMI – XML Metadata Interchange

(XML-Format für Metamodelle und darauf basierende Modelle, von der OMG standardisiert)

XML – Extensible Markup Language

(Sprache zur Abbildung hierarchischer Strukturen in Textform, vom W3C standardisiert)

XSL – Extensible Stylesheet Language

(Sprachfamilie zur Definition des Layouts von XML-Dokumenten, vom W3C standardisiert)

XSLT – XSL Transformation

(Transformationssprache zur Überführung von Dokumenten von einem XML-Format in ein anderes, vom W3C standardisiert)


184

9.3 Weitere Dokumente und Referenzen

9.3.1 Dokumente

UML Migration Guidelines – Leitfaden zur Migration einer ARIS 7.x Datenbank mit UML 1.4 Inhalten nach UML 2.5

9.3.2 Referenzen

OMG (Object Management Group): www.omg.org Spezifikationen der OMG (BPMN, MOF, UML, XMI u.a.): www.omg.org/spec W3C (World Wide Web Consortium): www.w3.org Spezifikationen des W3C (XML, XSLT u.a.): www.w3.org/standards

http://www.omg.org/

http://www.omg.org/spec

http://www.w3.org/

http://www.w3.org/standards

ARIS UML Designer-Einführung - claudiubrandas.ro UML Designer... · ARIS UML Designer-Einführung...

Documents

Transcript of ARIS UML Designer-Einführung - claudiubrandas.ro UML Designer... · ARIS UML Designer-Einführung...