UML 2 Theorie Workshop - DHBW Stuttgartrie/literatur/Uml2WorkshopOutline.pdf · Die Executable UML...

UML 2 Theorie Workshop© 2004 Jiri Lundak

UML 2 Theorie WorkshopLöwenfels Partner AG

23.2.2004

© 2004 Jiri Lundak

- 1 -


Ablauf

(Theorie-Blöcke gemischt mit Übungen in jedem Teil)

Kurzvorstellung aller Anwesenden

Übersicht Tagesprogramm

- Einführung (15 Min.) -

Teil 1

- Theorie (30 Min.) - - Anwendung (45 Min.) -

- Review (15 Min.) -

Pause (15 Min.)

Teil 2



Gemeinsame Mittagspause (ca. 1,5 Std.)

Teil 3



Pause (15 Min.)

Teil 4



- Wrap-Up (30 Min.) -

- 2 -


Einführung

- 3 -


Was ist die UML?

Etwas Geschichte

Vor 1996: Vielzahl von Notationen (Rumbaugh, Coad, Booch, etc.) Nach 1996: UML (Booch, Rumbaugh, Jackobson) als OMG Standard Oktober 2004: UML 2.0 als Standard fixiert

Definition

Universelle Notation zur Beschreibung von Software-Prozessen und -Systemen(Einheitliche Symbolik)

Ein grafisches Vokabular, mit dem Software-Ingenieure sich über Softwareunterhalten können (Einheitliche Sprache)

Was ist die UML nicht?

Ein Entwicklungsprozess Ein Modellierungstool Ein Satz von Modellierungsrichtlinien Eine Programmiersprache (noch nicht!)

Aktuelle Strömungen in der Verwendung

Agile Modeling (AM)

Die Agile Modeling Bewegung tritt für eine möglichst leichtgewichtige Modellierungvon Softwaresystemen ein. Dabei handelt es sich um einen Sammlung vonGrundwerten, Prinzipien und Best Practices, die einzig und allein dem Zweck dienen,genau so viel zu Modellieren, wie nötig ist um ein System abzubilden, nicht mehrund nicht weniger. Enhält eine Gewichtung des Wertes einzelner UML Diagramme.

http://www.agilemodeling.com

Domain Driven Development (DDD)

Ein pragmatischer Einzatz um komplexes, domänen-getriebenes Design zubetreiben. Dabei wird stark auf eine gemeinsames Vokabular der Domänenexpertenund der Entwickler wert gelegt. DDD ist unabhängig von einer bestimmtenTechnologie oder Methodik. Grosser Nachdruck wird jedoch auf das destillieren einesKernes des Domänenmodells. Gleichzeitig wird auf Designfragen, wie dieSegmentierung von komplexen Softwaresystem eingegangen.

Die UML wird dabei punktuelle eingesetzt um Konzepte oder Sachverhalte allenProjektbeteiligten zu verdeutlichen.

http://www.DomainDrivenDesign.org

- 4 -


Model Driven Architecture (MDA)

Mit MDA soll eine erhebliche Steigerung der Entwicklungsgeschwindigkeit erreichtwerden. Das Mittel dazu heißt „Automation durch Formalisierung“. Aus formaleindeutigen Modellen soll durch Generatoren automatisch Code erzeugt werden.

Fachliche Spezifikationen werden in pattformunabhängigen Modellen (PIM = PlatformIndependent Model) definiert. Dazu wird eine formal eindeutige Modellierungs-sprache – eine erweiterte UML-Notation (UMLProfil) – verwendet. Die damitspezifizierte Fachlichkeit ist vollständig unabhängig von der späteren Zielplattform.Plattformen können zum Beispiel CORBA, J2EE oder .NET sein.

Durch eine in der Regel mit Werkzeugen automatisierte Modelltransformationwerden aus den plattformunabhängigen fachlichen Spezifikationenplattformabhängige Modelle (PSM = Platform Specific Model) gewonnen. Dieseplattformabhängigen Modelle enthalten die spezifischen Konzepte der Zielplattform.Mit einer weiteren werkzeugunterstützten Transformation auf der Basis eines PSMwird dann für eine konkrete Zielplattform die Implementierung gewonnen.

http://www.omg.org/mda/

Executable UML

Wenn ein graphisches Modell ein komplettes System detailliert beschreibt, warumsollte es dann nötig sein es noch in eine andere Programmiersprache zu übersetzen?Die Executable UML möchte das UML-Modell direkt ausführbar machen. Dabei wirdim Moment jedoch lediglich ein Subset der aktuellen UML-Notation (mit einigenEigenheiten) verwendet. Es gibt bisher lediglich experimentelle Implementationdieses Paradigmas.

http://www.executableumlbook.com

- 5 -


Was ist neu in der UML Version 2?

Gegenüberstellung Version 1.x zu 2

Die nachfolgende Übersicht zeigt die 13 definierten Diagramme der UML 2:

Statische, strukturelle Aspekte (Skelett) Dynamische Verhaltensaspekte (Muskulatur)

- 6 -


Wozu werden die einzelnen Diagramme verwendet? Was sind ihre Stärken undSchwächen? Die nachfolgende Tabelle soll gerafft diese Fragen beantworten:

Diagrammtyp Zentraler Einsatzzweck Stärken Schwächen

Klassendiagramm Welche Klassen existierenund in welcher Beziehungstehen sie zueinander

- Beschreibt die statischeStruktur des Systems

- Enthält alle relevantenStrukturzusammenhängeund Datentypen

- Bildet Brücke zudynamischen Diagrammen

- relative leicht zuverstehen, da Ähnlichkeitzu Entity RelationshipDiagrammen

- Kern der UML

- AusschliesslicheKonzentration auf Strukturohne Einbezug vonVerhalten (Gefahr:anämisches Objektmodell)

- Detailreichtum kann beigrossen Systemunübersichtlich werden

Paketdiagramm Segmentierung desGesamtsystems inübersichtliche Teile

- Organisation desSystemmodells in logischzusammenhängendeEinheiten

- schafft Übersicht

- erlaubt Modellierung vonAbhängigkeiten undInklusion

- ermöglicht Entkopplungvon Diensten oderSubsystemen

- ungeeignet zumDarstellen von Aspektendie sich quer durch einSystem ziehen

Objektdiagramm Visualisierung der innerenStruktur des Systems zueinem festgelegtenZeitpunkt (Schnappschuss)

- Abbildung realer Objekteund ihrer Zustände zueinem bestimmtenZeitpunkt

- wirkungsvolleVisualisierung vonMengenverhältnissen

- konkrete, klareVorstellung einesSachverhalts

- Ungeeignet fürkomplexere Modelle

- äusserst begrenzteLebensdauer desDiagrammes

Kompositions-strukturdiagramm

Beschreibung der innerenStruktur einer Klasse,Komponente oder einesSystemteils

- Ideal für Top DownModellierung (Ganz-Teil-Hierarchien)

- Präzise Modellierung vonTeilebeziehungen (überPorts) möglich

- Zeigen die Laufzeit-Zusammenhänge vonKlassen, währendPaketdiagramme dieCompile-Zeit-Strukturaufzeigen

- 7 -



Komponenten-diagramm

Zusammenfassen vonKlassen zu wiederver-wendbaren undverwaltbarenKomponenten abbildenihrer Beziehungenzueinander

- Zeigt Organisation undAbhängigkeiten einzelnertechnischerSystemkomponenten

- Modellierung angebotenerund benötigterSchnittstellen

Verteilungs-diagramm

Beschreibung derAblaufumgebung meinesSystems und derVerteilung vonKomponenten aufverschiedene Prozesse

- Zeigt Laufzeit-Umgebungmit 'greifbaren'Systemteilen

- hohes Abstraktionsniveau

- einfache Notationsmittel

Use-Case-Diagramm

Hält die Anforderungen derUmwelt an das Systemfest. Beschreibt die Sichtvon Aussen auf das System

- Präsentiert Aussenansichtdes Systems

- hilft beiKontextabgrenzung

- hohes Abstraktionsniveau

- einfache Notationsmittel

- praktisch alsInhaltsverzeichnis

- UML sagt nichts über denInhalt eines Use-Case

- Diagramme werden zuunklar, wenn Use-CasesSpezialisierungen vonanderen Use-Cases werden

- Der Wert von Use-Casesliegt in der textuellenBeschreibung und nicht imDiagramm

Aktivitäts-diagramm

Komplexe Abläufe vonProzessen oderAlgorithmen festhalten

- sehr detaillierteVisualisierung von Abläufen

- Parallelisierung undSynchronisation möglich

- Darstellung vonDatenflüssen

- Workflow-Abbildung

- Prozessmodellierung

- von Domänenexpertennicht einfach zu verstehen(deshalb auch relativungeeignet um Use-Caseszu beschreiben)

Zustandsautomat Beschreibt die möglichenZustände eines Objektes,einer Schnittstelle odereines Use-Cases

- präzise Abbildung voneines Zustandsmodellseines einzelnen Objektesmit Zuständen, Ereignissen,Nebenläufigkeiten,Bedingungen, Ein- undAustrittsaktionen.

- Schachtelung möglich

- schlecht geeignetVerhalten zu beschreiben,dass mehrere Objektebetrifft, diezusammenarbeiten

- Aufwand lohnt nur fürinteressanteZustandsveränderungen

Sequenzdiagramm Definiert den Austauschvon Informationen in einerbestimmten Reihenfolgeunter mehreren Objekten

- detaillierte DarstellungdesInformationsaustauschesvonKommunikationspartnern

- sehr präzise Darstellungder zeitlichen Abfolge(auch mit Nebenläufigkeit)

- unübersichtlich umdetaillierte Algorithmenoder komplexe Abläufe mitSchleifen und konditionalenZweigen darzustellen

- 8 -



Kommunikations-diagramm

Beschreibt welche Objektemiteinanderkommunizieren undzusammenarbeiten

- Darstellung desInformationsaustauscheszwischenKommunikationspartnern

- Überblick betont

- Einfacher zu zeichnen alsSequenzdiagramme

- können helfen Design zu'entdecken'

- Keine präzise Abfolge vonMethodenaufrufenersichtlich

Timing-Diagramm Hält die Zustände voninteragierenden Objektenin zeitlichem Ablauf fest

- Visualisierung vonexaktem zeitlichenVerhalten von Klassen undSchnittstellen

- Modellierung vonRealtime-Systemen

Interaktions-übersichts-diagramm

Zeigt die zeitliche AbfolgeverschiedenerInteraktionen auf

- Verbinden vonInteraktionsdiagrammenauf Toplevel-Ebene

- Hohes Abstraktionsniveau

- Leseeinstieg inInteraktionsdiagramme

- Zwitter zwischenAktivitätsdiagramm undSequenzdiagramm (alssolches kopliziert es dasVerständnis)

- 9 -


TEIL 1

- 10 -


Use-Case-Diagramm

Definition

Das Use-Case-Diagramm hält fest, was externe Aktoren (System oderPersonen/Stakeholder) vom System erwarten. Es bildet das externe Verhalten desSystems - aus Sicht des Anwenders – ab.

Anwendung im Projekt

Use-Cases kommen sehr früh im Projekt zum Einsatz. Gewöhnlich stützen sie sichauf die, von den Anwendern (Kunden, Usern) des Systems, vorgegebenenAnforderungen.

Use-Cases vermitteln eine Übersicht der funktionalen Dienstleistungen desSystems 'auf einen Blick'.

Sie helfen das System in – aus Nutzersicht – handhabbare und logische Teile zuzerlegen.

Ausserdem helfen sie die Aussenschnittstellen und externenKommunikationspartner des Systems zu identifizieren.

Sie helfen auch das System in ein planbare Einheiten, bzw. Inkremente zuunterteilen.

Aufgrund ihrer leichten Verständlichkeit (auch bei Nicht-Technikern eignen sie sichsehr gut zur Kommunikation zwischen Anwendern, Entwicklern und Analytikern.

Notation

Ein Use-Case-Diagramm enthält die graphische Darstellung

des Systems der Anwendungsfälle der Akteure ausserhalb des Systems der Beziehungen zwischen Akteur und Anwendungsfall, der Akteure oder

Anwendungsfälle untereinander

- 11 -


Siehe das folgende Use-Case-Diagramm als Beispiel:

- 12 -


Unterschiede zu UML 1.x

UML 1.x UML 2

Ein Akteur darf unbenannt sein Ein Akteur muss einen Namen haben

Bei der «extend»-Beziehung werden dieVorbedingungen nur in der Nähe der entsprechendenRelation notiert

Die Vorbedingung und die entsprechenden'extension points' werden als Notiz an dieErweiterungsbeziehung angehängt

Nur Packages können Use-Cases besitzen Classifier im Allgemeinen können Use-Casesbesitzen

Als Realisierer von Use-Cases werden (Sub-)Systemeimpliziert, obwohl jeder Classifier einen Use-Caserealisieren darf

Es wird deutlich herausgestellt, dass alleClassifier Use-Cases realisieren können

Zu Beachten

Use-Cases nicht zur detaillierten Beschreibung von Operationen verwenden Nicht-funktionale Anforderungen nicht mittels Use-Cases spezifizieren Zu starke funktionale Zerlegung mittels Use-Cases vermeiden Use-Cases immer aus der Sicht des Anwenders und nicht des Entwicklers erstellen Beim Zeichnen von Use-Case-Diagrammen immer daran erinnern, dass sie keine

objektorientierte Sicht auf das System darstellen, sondern die reine(oberflächliche) Anwendersicht beschreiben (was statt wie).

Sehr sparsam mit Beziehungen zwischen Use-Cases (include und extend)umgehen, denn sie reduzieren die intuitive Verständlichkeit für den Leser

How-To

Beschreibungsmöglichkeiten von Use-Cases

Merkmale des Use-Cases Empfohlene Notation zur Bescheibung

Kurze klare Abläufe, wenige Sonderfälle (Strukturierter) Text

Zielpublikum der Use-Cases Entwickler undEndanwender

(Strukturierter) Text (Use-Case-Diagramm nurals Inhaltsverzeichnis der Use-Cases)

Ablauf- oder schrittorientiert (1., 2., ...) Aktivitätsdiagramm

Einfache daten- und entitätsorientierte Abläufe(viele Entitäten)

Kommunikationsdiagramm

Komplexe daten- und entitätsorientierte Abläufe(viele Entitäten)

Sequenzdiagramm

Kein 'typischer' Ablauf, gleichwertiges Auftretenvon Abfolgen und Ereignissen

Zustandsautomat

Use-Case bündelt viele Szenarien Interaktionsübersichtsdiagramm

- 13 -


Granularität

Use-Cases können und sollten in unterschiedlicher Granularität erstellt werden (jenach Einsatzzweck/-ziel, aka. Goal-Level):

Cloud (Wolke): Grober Überblick Kite (Flugdrachen): Feiner Überblick Sea (Meereshöhe): Standard Fish (Fisch): Detail Clam/Shell (Muschel): Feines Detail

Alistair Cockburn definiert dazu neben den Farben (von Weiss bis Schwarz) folgendeIcons, um auf die Granularität hinzuweisen:

Er verwendet sie sowohl bei den Diagrammen, als auch in der textuellenBescheibung von Use Cases.

Von den fünf Detaillierungsgraden, werden jedoch in der Regel nur die mittleren dreiverwendet. Dabei empfiehlt es sich nicht zu früh zu sehr ins Detail zu gehen. Für dasGesamtsystem können beim erfassen der Anforderungen Überblicks-Use-Cases(Flugdrachen) definiert werden. Für einige wenige, kritische Use-Cases (hohesRisiko) kann der Use-Case detailliert formuliert werden (Fisch). Die meisten Use-Cases sollten sich auf Meereshöhe (Sea-Level) bewegen. Bei iterativem Vorgehenwerden die einzelnen Use-Cases im Lauf des Projektes bei Bedarf detailliertergefasst.

Strukturierung von Use-Cases

Wie Use-Cases strukturiert werden hängt grösstenteils davon ab, was mit den Use-Cases abgebildet wird und mit welcher Granularität das System beschrieben werdensoll.

Business-Use-Case versus System-Use-Case:

Business-Use-Cases (essenziell) beschreiben wie eine Unternehmung auf dieAnfrage eines Kunden oder beim eintreffen eines Ereignisses reagiert (AbstrakterAnwendungsfall) (Symbol: )

System-Use-Cases (real) beschreiben die Interaktion mit dem Software-System(Konkreter Anwendungsfall) (Symbol: )

«include» versus «extend»-Beziehungen:

Die «include»-Beziehung visualisiert, dass ein Use-Case das Verhalten einesanderen Use-Case importiert. Das Verhalten, dass durch die «include»-Beziehungimportiert wird, ist nicht optional, sondern wird immer inkludiert. Der Use-Caseder das Verhalten einbindet, ist somit abhängig vom Use-Case, den er inkludiert.

- 14 -


Ein Use-Case darf sich weder selbst inkludieren noch einen anderen Use-Case, derwiederum in selber inkludiert (Verbot zyklischer Abhängigkeiten).

Die «extend»-Beziehung zeigt an, dass das Verhalten eines Use-Case durch einenanderen Use-Case erweitert werden kann, aber nicht muss. Den Punkt, an demein Verhalten eines Use-Case erweitert werden kann, bezeichnet man alsErweiterungspunkt (extension point). Ein Use Case darf mehrere Erweiterungs-punkte besitzen.

Zu beachten: Die «extend»-Beziehung ist zwar ebenso eine Spezialisierung desBasis-Use-Cases wie ein durch Generalisierung abgeleiteter Use-Case. Die«extend»-Beziehung dient nur der Verhaltenserweiterung eines Use-Cases, siekopiert und überschreibt nie den Basis-Use-Case wie ein durch Generalisierungabgeleiteter Use-Case. Bei der Generalisierung erfolgt die Erweiterung zurSpezifikationszeit, während bei der «extend»-Beziehung die Erweiterung zurLaufzeit stattfindet. Die Generalisierung ist jedoch nur in wenigen Fällen geeignet,da sie häufig zu semantischen Zweideutigkeiten führt.

Wie schreibt man einen Use-Case?

Systemgrenzen festlegen Akteure ermitteln Liste von Akteuren und ihren Zielen festlegen Liste um Use-Case-Kurzbeschrieb erweitern Einen Use-Case herausgreifen und detaillieren

(Weitere Details siehe kopiertes Beiblatt “The Writing Process”)

Es gibt keine vorgeschriebene Art, wie man Use-Cases beschreibt. Allerdings habensich in den letzten Jahren einige Formen der Use-Case Beschreibung eingebürgert.

- 15 -


Das nachfolgende Template dient als Beispiel einer textuellen Bescheibung einesUse-Cases in der Business Prozess Modellierung:

Eine rein strukturiert-textuelle Beschreibung von Use-Cases eignet sich vor allem fürdie Kommunikation mit Anwendern.

Eine tabellarisch Darstellung erleichtert dagegen die Planung aufgrund von Use-Cases, ihre Priorisierung und Unterteilung in Tasks.

- 16 -

Use Case 28 Business Prozess – Workshop durchführen

Scope: Löpa UML Workshop

Level: Übersicht

Kontext: Eine Workshop-Reihe soll neues Wissen vermitteln und bestehendes konsolidieren

Primary Actor: der Coach

Interessenten: die Firma will einen einheitlichen Lernstand der Angestellten, die Teilnehmer wollen etwas lernen,der Coach will etwas lernen

Minimale Garantien: keine

Erfolgsgarantie: etwas gelernt

Vorbedingungen: Workshop nicht abgesagt, Raum verfügbar, Teilnehmer anwesend

Auslöser: Löpa Geschäftsleitung lädt zum Workshop ein

Hauptszenario:

1. Der Coach erklärt ein Thema

2. Der Coach zeigt Beispiele

3. Der Coach gibt den Teilnehmern Übungen zur Lösung

4. Die Teilnehmer führen Übungen durch und präsentieren ihre Lösung

5. Der Coach bespricht die Lösungen

6. Weiter mit dem nächsten Thema bei 1 bis alle Themen besprochen.

Erweiterungen:

1a. Der Coach erklärt das Thema schlecht und Fragen entstehen

1a1. Die Teilnehmer stellen Fragen

1a2. Der Coach beantwortet die Fragen

Häufigkeit des Falles: 3 - 5

Offene Punkte: Wann ist die nächste Kaffeepause?


Bestandteile der textuellen Beschreibung eines Use-Cases (tabellarisch oder reinstrukturiert-textuell) sind unter anderem:

Name Beteiligte Akteure und Interessenten Granularität (Goal-Level) Ablaufbeschreibung Vorbedingungen Nachbedingungen Ausnahmen/Erweiterungen

Der Umfang einer Use-Case-Beschreibung kann im Umfang sehr stark variieren (jenach Zweck, Zielpublikum, Projektumfeld, etc.).

Ableitung von Features aus Use-Cases

Wenn möglich sollte direkt ab Use-Cases gearbeitet werden können, damit nichtnoch eine separate Feature/Task-Liste synchron nachgeführt werden muss.

Wenn eine Feature/Task-Liste angefertigt werden soll, dann sollte ein Use-Case(idealerweise Sea- oder Fish-Level) in kleine Stücke zerlegt werden, die jeweilsein Feature ergeben (Geschätzter Implementationsaufwand 1-3 Tage proFeature).

Ein Feature/Task kann ein ganzer Use-Case, ein Szenario oder ein Aktionschrittinnerhalb eines Use-Cases. Ausserdem können auch Features/Tasks erzeugtwerden, die in keinem Use-Case vorkommen. Features/Tasks sind normalerweisedeutlich feinkörniger als Use-Cases.

Plannung kann sich nun auf die generierte Feature/Task-Liste stützten (Format:Referenz, Feature-Beschreibung, Business Wert, Geschätzter Aufwand, Target-Release, etc.). Dies kommt vor allem einem iterativen, inkrementellenEntwicklungsprozess zu Gute.

Use-Cases im iterativen Entwicklungsprozess

Breite zuerst, Tiefe bei Bedarf (zu einem späteren Zeitpunkt) Liefern dem Kunden Business Value (wenn komplettes Szenario implementiert) Ergeben eine gute Grundlage für die Kommunikation mit dem Kunden Können gut für das Ableiten von Features/Tasks herangezogen werden, die das

Schätzen des Aufwandes eines Stückes Funktionalität ermöglichen. Stellen eine Basis für Akzeptanztests dar

Use-Cases als Anforderungsdokumentation

Ideal geeignet funktionale Anforderungen an ein System zu Erfassen Da sie auch für den Nichtentwickler verständlich sind, können sie einfach dazu

eingesetzt werden, mit Kunden zu definieren, was das System (von aussensichtbar) leisten soll.

Wenn Use-Cases als Anforderungen aufgeschrieben werden, dann beinhalten siewirklich Anforderungen (d.h. Sie müssen nicht noch in ein weiteres Dokumenttransformiert werden)

Use-Cases definieren nicht alle Anforderungen an ein System. (z.B. Sagen sienichts über die Details von externen Schnittstellen, Datenformaten,

- 17 -


Geschäftsregeln, Formeln, Validierungen oder Systemattributen, etc.) Deshalb sind Use-Cases nur ein Teil eines Anforderungsdokumentes.

Use-Cases als Kommunikationsmittel mit dem Kunden

Use-Cases sind das Kommunikationsmittel mit dem Kunden Da sie eine externe (die Anwender-) Sicht des Systems darstellen und –

zumindest auf der Business-Prozess-Ebene – die Sprache des Kunden sprechen,sind sie von beiden Parteien einfach zu verstehen.

Weiterführende Literatur

Use-Cases eingebettet in den OOAD Entwicklungsprozess:Applying UML and Patterns (Craig Larman, 1998, Prentice-Hall)

Use-Cases textuell beschreiben (mit Beispiel-Templates):Writing Effective Use-Cases (2001, Alistair Cockburn, Addison-Wesley)

Use-Cases in UML 2.0:UML 2 glasklar (Mario Jeckle et al., 2004, Hanser)

Alistair Cockburns Use-Case Website:http://usecases.org

Wie Benutzerschnittstellen aus Use-Cases abgeleitet werden können:http://foruse.com

- 18 -


TEIL 2

- 19 -


Klassendiagramm

Definition

Das Klassendiagramm erlaubt die Abbildung der statische Struktur eines Systems zubeschreiben. Es zeigt die konstanten Eigenschaften und die Beziehungen innerhalbdes Systems. Es stellt den Kern der UML dar.


Klassendiagramme sind das Rückgrad der UML. Dementsprechend finden sie in jederProjektphase Verwendung. Allerdings ist ihr Detaillierungsgrad je nach dem was manmit dem Klassendiagramm bezweckt unterschiedlich. Grundsätzlich kann man zwei'Arten' von Klassendiagrammen unterscheiden: konzeptuell-analytisch orientierteund eher auf logisches Design ausgerichtete.

Notation

Einfaches Klassendiagramm:

- 20 -


Interface Notation und abstrakte Klassen:

Weitere Notationselemente:

Ball- and Socket-Notation für Interfaces (aka. Lollipop) Referenz-Objekte versus Werte-Objekte («value»-Stereotyp) Assoziationsklassen (als vollwertige Klassen modellieren) Aufzählungsklassen («enumeration»-Stereotyp) Sichtbarkeit: public (+), private (-), package (~), protected (#)


UML 1.x UML 2

Attribute werden als Komposition bezüglich derumgebenden Klasse betrachtet.

Attribute werden nur noch als durch Assoziationmit der umgebenden Klasse betrachtet.

Attribut- und Operationsreihenfolge innerhalbeiner Klasse unspezifiziert.

Auftreten von Attributen und Operationen ineiner Klasse geordnet.

Eine mit dem Stereotyp «realize» verseheneAbhängigkeitsbeziehung verbindet Schnittstelleund implementierende Klasse.

Ersetzt durch 'Lollipop'-Notation.

Der Eigenschaftswert frozen zur Kennzeichnungunveränderlich konstanter Attribute undAssoziationen.

Wird durch die Eigenschaft readOnly, die mitderselben Semantik belegt ist, ausgedrückt.

Eigenständige Notation für innere Klassen. Als Komposition ausgedrückt.

- 21 -


Zu Beachten

Klassen sollten mit einem Nomen im Singular oder einer entsprechendenWendung benannt werden.

Klassen-, Attribut- und Operationsbezeichner nie mit abkürzenden oderungewöhnlichen Notationen bezeichnen, da dies die Lesbarkeit der Modelledeutlich herabsetzt.

Keine Sonderzeichen oder Umlaute in der Benennung. Namen von Eigenschaften oder Operationen beginnen immer mit einem

Kleinbuchstaben Eigendefinierte Stereotype zur näheren Charakterisierung von Modellelementen

verwenden. Diese Annotation dokumentiert die konkrete Verwendungsemantikbesser als ein Kommentar.

(Statische) Klassenoperationen oder -attribute nur verwenden, wenn dieszwingend notwendig ist.

Paketdiagramm

Definition

Das Paketdiagramm hilft die Struktur eines Systems logisch zu gliedern, indem esSichten auf verschiedenen Abstraktionsebenen definiert. Somit erlaubt es inkomplexen Systemen den Überblick zu bewahren.


Grundsätzlich kann man Paketdiagramme im Projekt vor allem in zwei Bereicheneinsetzen:

Funktionale Gliederung des Systems Prinzipiell können Pakete rein intuitiv gefunden werden, indem man sich überlegt,welche Classifier funktional oder logisch in sehr engem Zusammenhang stehen.

Existiert für das zu beschreibende System ein Klassendiagramm, das sehrumfangreich ist und durch ein Paketdiagramm gegliedert werden soll, kann man sichauch an den Beziehungen zwischen den Klassen orientieren: Klassen mit vielenBeziehungen untereinander werden meistens einem gemeinsamen Paketzugeordnet.

Die funktionale und logische Gliederung eines Systems wird häufig schon zu Beginneines Projektes angewendet. Aus der Gliederung ergeben sich meistens Einheiten,die zusammenhängend entwickelt werden können. Somit kann die Paketbildungauch die Planung einer inkrementellen Entwicklung unterstützen.

Beschreibung der architekturellen Struktur des Systems

Über die rein funktionale oder logische Gliederung des Systems hinaus kann man mitdem Paketdiagramm auch die Struktur eines Systems nach anderen Kriterien

- 22 -


beschreiben. So werden z.B. Softwaresysteme oft in einer Schichtenarchitekturrealisiert. Die einzelnen Schichten können in der UML durch Pakete definiert sein.Diese können dann weitere, nach funktionallen Gesichtspunkten gegliederte Paketeenthalten.

Notation

Beispieldiagramm (UML 2 konform):

Beispieldiagramm (nicht UML 2 konform, aber nützlich):

- 23 -


Beispieldiagramm (zeigt Abhängigkeiten (können neu auch als Generalisierungmodelliert werden):


(Keine)

Zu Beachten

Den Paketen möglichst aussagekräftige Namen geben. Ist es nicht möglich, ein Paket mit einem prägnanten Namen zu benennen, so ist

dies meistens ein Zeichen von unpassender Aufteilung der Pakete.

- 24 -


Komponentendiagramm

Definition

Das Komponentendiagramm beschreibt die Struktur eines Systems zur Laufzeit underlaubt es den inneren Aufbau von Systemkomponenten (auch geschachtelt), sowiedie Schnittstellen, die diese Komponenten anbieten oder fordern, darzustellen.

Objektdiagramm (nur erwähnt)

Definition

Ein Objektdiagramm stellt einen Schnappschuss eines ein Systems oderSystemteiles zur Laufzeit dar. Bei den dargestellten Elementen handelt es sich umeinzelne Instanzen von Klassen, mit beispielhaften Beziehungen und Datenangereichert, wie sie zu einem bestimmten Zeitpunkt erscheinen.

Kompositionsstrukturdiagramm (nur erwähnt)

Definition

Ein Kompositionsstrukturdiagramm ermöglicht es, die interne Struktur einesClassifiers sowie seine Interaktionsbeziehungen zu anderen Systembestandteilen zubeschreiben. Es zeigt somit, wie sind einzelne Komponenten strukturiert sind undzusammenspielen.

Verteilungsdiagramm (nur erwähnt)

Definition

Ein Verteilungsdiagramm zeigt die dynamische Zuordnung von Software-Komponenten auf Hardware-Einheiten, die als Knoten bezeichnet werden. Danebenstellt das Verteilungsdiagramm die Kommunikationsverbindungen undAbhängigkeiten zwischen diesen Knoten dar.

- 25 -


TEIL 3

- 26 -


Aktivitätsdiagramm

Definition

Das Aktivitätsdiagramm stellt Abläufe von Verhalten unter Berücksichtigung vonNebenläufigkeit, alternativen Entscheidungswegen und Ähnlichem dar. Es erlaubtdas Modellieren von einzelnen Operationen oder kompletten Geschäftsvorfällen(Use-Cases).


Aktivitätsdiagramme visualisieren Abläufe, die zu verschiedenen Projektzeitpunktenmit stark variierendem Detaillierungsgrad modelliert werden. Sie lassen sich deshalb mehrfach im Projekt einsetzen. Die wichtigsten Anwendungsgebiete sind:

Geschäftsprozess- und Workflowmodellierung Bescheibung von Use-Cases Implementation einer Operation (Algorithmus)

Notation

Einfaches Aktivitätsdiagramm:

- 27 -


Eine Subaktivität:

Referenzieren der Subaktivität:

- 28 -


Einfaches Aktivitätsdiagramm mit Aktivitätsbereichen:

- 29 -


Ein Algorithmus als Aktivitätsdiagramm mit strukturiertem Knoten:

- 30 -



UML 1.x UML 2

Aktivitätsdiagramm als Sonderform desZustandsdiagramms.

Aktivitäten sind unabhängig vonZustandsautomaten.

Aktivitätsdiagramme entsprechen der Strukturvon Zustandsdiagrammen.

Aktivitäten verwenden eine den Petrinetzenähnliche Semantik (Token).

Das komplette Diagramm heisstAktivitätsdiagramm.

Das komplette Diagramm wird als Aktivitätbezeichnet.

Einzelne Schritte im Aktivitätsdiagramm werdenAktivitäten genannt.

Die Schritte im Ablauf werden Aktionen genanntund beschreiben einen Verhaltensaufruf und nichtdas Verhalten selber. Daher können aus einerAktion eine neue Aktivität, eine Interaktion, ein Use-Case, etc. aufgerufen werden.

Aktionen haben keine Vor- undNachbedingungen.

Aktionen können mit Vor- und Nachbedingungenverknüpft werden.

Notationssymbole für Zustand und Aktionunterschiedlich:

Die Notation von Aktionen entspricht der Notationvon Zuständen der UML 1.x:

In einem Aktivitätsdiagramm ist nur einAnfangszustand erlaubt

Es sind mehrere Startknoten erlaubt.Das bedeutet, dass parallele Abläufe gestartetwerden können.

Ein Endzustand beendet den gesamten Ablauf imAktivitätsdiagramm.

Es wird unterschieden zwischen dem Endknoten fürAktivitäten, der die gesamte Aktivität beendet, unddem Endknoten für Abläufe, der nur einenAblaufstrang beendet.

Aktivitätsdiagramme haben keine Ein- undAusgabeparameter.

Aktivitäten können Ein- und Ausgabeparameterenthalten; diese können auch den Start- und denEndknoten ersetzen.

Es gibt Objektzustände, die semantisch äusserstvage definiert sind.

Einführung von Objektknoten zur besserenModellierung der Objektflüsse

Objektflüsse und Kontrollflüsse werden durchTransitionen modelliert

Objektflüsse und Kontrollflüsse sind explizit; dieÜbergänge zwischen den Aktionen werden alsKanten bezeichnet.

Parallele Stänge müssen zusammen-geführtwerden.

Parallele Abläufe müssen nicht wiederzusammengeführt werden.

Aktivitätsbereiche (Swimlanes) sind immereindimensional.

Aktivitätsbereiche können hierarchisch odermultidimensional sein.

Neue Notationselemente:

Strukturierte Knoten Mengenverarbeitungsknoten Entscheidungsknoten Schleifenknoten Datenspeicher und Pufferknoten Unterbrechungsbereich Parametersatz

- 31 -

Aktionszustand1 Zustand ZustandAktion


Zu Beachten

Zur Modellierung reaktiver (event-gesteuerter) Systeme lieberZustandsautomaten statt Aktivitäten benutzen.

Abläufe nicht zu detailliert beschreiben, wenn nicht unbedingt erforderlich, sonstübersteigt die Komplexität schnell den Nutzen des Diagramms

Nach Möglichkeit vermeiden, dass mehrere Kanten in eine Aktion münden. Besservorangeschaltete Synchronisierungs- oder Vereinigungsknoten verwenden.

Bei Verwendung von Verzweigungsknoten darauf achten, das dieAuztrittsbedingungen korrekt angegeben sind. Lücken oder Überschneidungenvermeiden.

Ist mit einer anderen Darstellung (z.B. Text oder Code) bereits eine klare undeindeutige Analyse des Problems festgehalten, sollte auf die zusätzlicheAnfertigung eines Aktivitätsdiagrammes verzichtet werden.

Problem bei der Verwendung von Aktivitätsdiagrammen zur detailliertenBescheibung von Use-Cases: Oft bekunden Domänen-Experten Mühe dieDiagramme zu verstehen (besonders wenn komplexe Abläufe visualisiert werden).In einem solchen Fall bewährt sich die textuelle Form der Use-Case-Beschreibung.

How-To

Das Token-Konzept

Um gerade die komplexen und schwer durchdringbaren Verhältnisse vonnebenläufigen Prozessen zu klären, ist Aktivitätsdiagrammen ein logisches Konzepthinterlegt: das Konzept der Token.

Unter einem Token stellt man sich am besten einen Staffelstab vor, der denlogischen Punkt anzeigt, an dem sich ein Ablauf gerade befindet.

Die Wanderung des Tokens durch eine Aktivität repräsentiert die Abarbeitung einesAblaufes. In einer Aktivität können gleichzeitig beliebig viele Token unterwegs sein,um dadurch parallele Abläufe oder mehrfach instanzierte Abläufe abzubilden.

- 32 -


TEIL 4

- 33 -


Zustandsdiagramm (Zustandsautomat)

Definition

Ein Zustandsdiagramm beschreibt die möglichen Zustände einer einzelnen Klasse,sowie die Übergänge von einem Zustand in den nächsten (unter Berücksichtigungder auslösenden Ereignisse).


Ein Zustandsautomat stellt die verschiedenen Zustände eines verhaltensspezifischenClassifiers dar, sowie die Ereignisse die zum Erreichen dieser Zustände führen unddie Bedingungen die erfüllt sein müssen damit diese Ereignisse eintreffen.

Die Einsatzmöglichkeiten sind breit gefächert, sind aber vor allem dann sinnvoll,wenn der Lebenszyklus einer Klasse oder eines Ablauf eines Use-Cases modelliertwerden muss. Der Aufwand lohnt dann, wenn das Element einen komplexenLebenszyklus oder Ablauf hat.

Zustandsautomaten sind Sequenzdiagrammen dann vorzuziehen, wenn ein Classifierim Zentrum des Interesses steht und nicht die Interaktion mehrerer Classifier.

Notation

Beispieldiagramm einfacher Zustandsautomat (Business Objekt Zustand):

- 34 -


Beispieldiagramm einfacher Zustandsautomat (Use-Case Authentifizierung amBankomaten):

Notationselemente: Trigger/Aktivität, Interne Trigger (entry, exit, do),Pseudozustände (Startzstand, Endzustand, Austrittspunkt, Entscheidung, Kreuzung)


UML 1.x UML 2

Interfaces können neu können nunProtokollzustandsautomaten besitzen.

Ein- und Austrittspunkte und Terminatoreneingeführt.

Regeln zur Ergänzung und Ersätzung beivererbten Zustandsautomaten wurdenhinzugefügt.

Generalisierung von Zustandsautomaten durchNotizzettel.

Das vererbte Verhalten wird mit einemZustandsautomaten dargestellt.

Zu Beachten

Startzustand versuchen in der oberen linken Ecke und Endzustand in der unterenrechten Ecke zu platzieren.

Immer Zustände überprüfen, die nur eingehende aber keine ausgehendenTransitionen besitzen. Bei einem vollständigen Modell sollte dies niemals der Fallsein.

- 35 -


Bei komplexen Diagrammen, wenn möglich, eine hierarchische Gliederung mitUnterzustandsautomatenzuständen verwenden.

Sequenzdiagramm

Definition

Das Sequenzdiagramm hält die Interaktionen zwischen mehreren beteiligten Klassenfest. Dabei wird die genaue zeitliche Abfolge des Informationsaustauschesabgebildet.


In Sequenzdiagrammen lassen sich Interaktionen auf verschiedenenAbstraktionsebenen modellieren (auf Klassen- Komponenten- oder System-Ebene).Obwohl sie bei design- bzw. implementationsnahen Tätigkeiten häufiger eingesetztwerden, sind sie zu jedem Zeitpunkt im Projekt nutzbar.

Hier einige mögliche Einsatzgebiete:

Abgrenzung des Systemkontexts (Analyse) Fachmodell, Use-Case-Realisierung (Analyse/Architektur) Schichtenübergreifende Kommunikation, Komponentenkommunikation

(Architektur) Detaillmodellierung von Operationsaufrufen (Feindesign) Abbildung von Testszenarien (Test)

Trotzdem werden sie in der Praxis nicht sehr oft eingesetzt und zwar aus folgendenGründen:

Das Modellieren von Sequenzdiagrammen ist sehr zeitaufwändig (besonders beidesign-/implementationsnahen Anwendungen), was dazu für das sie imProjektverlauf oft ein Schattendasein fristen und schnell veralten.

Das Interaktionsmodell ist meistens nicht vollständig, was seinen Wertbeschränkt.

- 36 -


Notation

Notationsbeispiel einfaches Sequenzdiagramm (zentrale Kontrolle):

- 37 -


Notationsbeispiel einfaches Sequenzdiagramm (verteilte Kontrolle):

- 38 -


Notationsbeispiel Erzeugung und Zerstörung von Objekt-Instanzen:

- 39 -


Notationsbeispiel Kombinierte Fragmente:

Mögliche Operatoren (Auswahl): alt (Alternativer Ablauf), opt (optionaleInteraktionsteile), break (Interaktionen in Ausnahmefällen), neg (ungültigeInteraktionen), loop (iterative Interaktionen), assert (unabdingbare Interaktionen)

Um Programmlogik zu beschreiben sind normalerweise jedoch Aktivitätsdiagrammebesser geeignet, oder Pseudocode, z.B. für obiges Diagramm:

- 40 -

procedure versendenforeach (bestellZeile)

if (produkt.wert > 10000 Franken)eingeschrieben.versenden

elsenormal.versenden

end ifend forif (benoetigtBestaetigung) post.bestaetigen

end procedure



UML 1.x UML 2

Im Sequenzdiagramm interagieren Objekte, diedurch Objektlinien repräsentiert werden.

Im Sequenzdiagramm interagieren jegliche“Partner”, die zur Kommunikation fähig sind. Siesind durch Lebenslinien repräsentiert.

Referenzen auf andere Interaktionen sind nichtmöglich.

Innerhalb von Sequenzdiagrammen kann aufandere Interaktionen verwiesen werden. DieZerlegung von Lebenslinien ist erlaubt. Damitsind hierarchische Diagramme mitunterschiedlichem Abstraktionsgrad möglich.

Es gibt nur wenige Möglichkeiten Kontrollflussdarzustellen (Schleifen undNachrichtenbedingungen sind notierbar).

Nahezu alle Möglichkeiten Kontrollflussdarzustellen sind verfügbar.

Es gibt drei Nachrichtenarten:asynchron, synchron, unspezifiziert

Die unspezifizierte Nachricht entfällt. Zusätzlichwerden neu lost- und found-Nachrichteneingeführt.

Neue Notationselemente:

Interaktionsrahmen Kombinierte Fragmente Sprungmarken und Coregionen Interaktionsreferenzen Gates für Nachrichten

Zu Beachten

Ausprägungen immer sinnvolle Namen vergeben (C1, C2, etc. vermeiden) Interaktionsreferenzen nutzen, um Diagramme übersichtlicher zu gestalten. Top-

Down-Hierarchien bilden. Vor allem kritische Interaktionen modellieren und nicht viel Zeit auf

Nebensächlichkeiten verschwenden. Keinen Anspruch auf Vollständigkeit stellen. Gewünschte Reihenfolge der Ereignisse übelegen bevor mit dem Modellieren

begonnen wird. Nicht scheuen, konkrete, vielleicht unvollständige Szenarien zu modellieren. Diese

helfen dem Leser häufig mehr, als vollständige, aber abstrakte Modelle. Interaktionsübersichtsdiagramme nutzen statt kombinierte Fragmente und

Interaktionsreferenzen, wenn Interaktionen auf hohem Abstraktionsniveaudargestellt werden sollen.

How-To

Strukturierung von Sequenzdiagrammen

Reihenfolge der Kommunikationspartner im voraus überlegen Nicht zu detailliert ausführen Kombinierte Fragmente zum modellieren von Kontrolllogik vermeiden (messy) Komplexe Sequenzdiagramme in untergeordnete Sequenzdiagramm aufteilen und

mit dem ref-Operator referenzieren.

- 41 -


Kommunikationsdiagramm (nur erwähnt)

Definition

Ein Kommunikationsdiagramm zeigt das Wechselspiel und den Nachrichtenaustauschin einem komplexen System. Es bildet auf einem mittleren Abstraktionsniveau ab,welche Kommunikationspartner wie gemeinsam zur Lösung einer gemeinsamenAufgabe beitragen. Dabei wird die Reihenfolge der versandten Nachrichten sichtbargemacht.

Timing-Diagramm (nur erwähnt)

Definition

Ein Timing-Diagramm zeigt das zeitliche Verhalten von Classifiern in einem System.Dazu beantwortet es die Fragen, wann sich die verschiedenen Interaktionspartner inwelchem Zustand befinden.

Interaktionsübersichtsdiagramm (nur erwähnt)

Definition

Ein Interaktionsübersichtsdiagramm zeigt das Zusammenspiel verschiedenerInteraktionen, indem es Abfolgen von Interaktionen und Interaktionsreferenzenmittels einer Variante des Aktivitätsdiagramms darstellt. Dabei beantwortet es dieFrage, über die Reihenfolge und die Bedingungen unter welchen bestimmteInteraktionen stattfinden.

- 42 -


Wrap-Up

- 43 -


Wieviel UML braucht es?

Bedeutung von OOAD-Prinzipien

Mit Version 2 bewegt sich die UML deutlich in Richtung Universalsprache für alleEntwicklungsbelange (seien sie objektorientiert oder prozedural).

Dies führt zur Gefahr einer rein funktionalen Dekomposition von Abläufen undSystemen. Diese ist gut zur Analyse von bestehenden Systemen oder zur Aufnahmevon rein benutzerorientierten Anforderungen und deren Dokumentation. Nichtvernachlässigbar, und auch nicht zu unterschätzen im Aufwand, ist jedoch dasobjektorientierte Design des zu erstellenden Systems, soll es nicht zu einerAnsammlung von – auf die Dauer – unwartbarem Code werden.

Objektorientierte Systeme sind ausserdem zunehmend 'lebende' Systeme, d.h.Systeme, die im Laufe der Zeit modifiziert und auch intern vereinfacht werden(Refactoring), da neue Anforderungen von Kundenseite nicht nur einfach an dasbestehende System angebaut werden, und dadurch das gesamte System auf dieDauer zu einem grossen Patchwork an Flicken wird, sondern im Idealfall eineSoftware entsteht, die kein 'Fett' ansetzt.

Was ist mit Patterns?

Patterns sind erprobte Lösungsansätze für Standardprobleme der objektorientiertenSoftwareentwickling.

Viele UML-Tools bieten eine Bibliothek von bekannten Patterns an, die man auf daseigene OO-Design anwenden kann. Patterns sind oft in Form vonKlassendiagrammen formuliert und es kann hilfreich sein eigene Pattern in UMLfestzuhalten, um nicht nur Algorithmen-Knowhow festzuhalten sondern auchArchitektur-/Design-Knowhow.

Dadurch kann Wissen innerhalb des Projektteams verteilt werden.

UML als Dokumentation

Damit die UML im Rahmen der Dokumentation eines Projektes die richtige Rollespielen kann, muss entschieden werden welchem Zweck die Dokumentation dienensoll und welches Gewicht UML Diagramme darin erhalten sollen.

Dies führt unter anderem zu ganz unterschiedlichen Ausprägungen von UMLDiagrammen (System-Ausschnitt, Detaillierungsgrad, Diagrammtyp, etc.) .

Wenn es darum geht Konzepte und komplexe Zusammenhänge deutlich zu machen,dann ist der Detaillierungsgrad eines Diagrammes recht niedrig zu wählen. Oftwerden nur für den Sachverhalt relevante Klassen dargestellt, z.T. ohne Attributeoder nicht mit allen Operationen versehen, damit man den Aspekte den manhervorheben möchte klar kommuniziert und nicht durch unnötigen optischen Balastvernebelt.

- 44 -


Wenn es darum geht möglichst ein getreues Abbild des aktuellen Implementation zuerstellen, empfiehlt sich ein Reverse Engineering aus dem Sourcecode. Allerdingsgibt es im Moment kein Tool, dass in der Lage wäre z.B. Aktivitätsdiagramme direktaus Sourcecode zu erzeugen.

Leitprinzipien zum Einsatz der UML

Klare Kommunikation Weniger ist mehr DRY (Don't Repeat Yourself) Selektives Hervorheben wichtiger Konzepte Vollständigkeit ist eine Illusion

Faktoren, die die Anwendung von UML beeinflussen

Ziele Zielpublikum der erarbeiteten Artefakte Entwicklungsprozess (Iterativ, Wasserfall, etc.) Plannung/Überwachung Architektur Tools

Einsatz von UML bei Löpa

Damit über den Einsatzgrad der UML innerhalb der Löpa entschieden werden kann,müssen folgende Fragen beantwortet werden:

Wozu soll die UML eingesetzt werden? (Dokumentation, Entwicklungsprozess) Wie synchron sollen die UML-Diagramme zum Code sein? Wer wird mit den Diagrammen arbeiten, wer wird sie lesen? Wie detailliert sollen die Diagramme sein? Welche Rolle spielen Diagramme in der kompletten Projektdokumentation? Welche Rolle soll die UML im Löpa Entwicklungsprozess spielen? (Weitere Fragen...)

Schlussbemerkungen

Zusammenfassung

Die UML ist ein hochflexibles Werkzeug Die UML ist kein Allheilmittel Die UML will customized eingesetzt werden Der Entwicklungsprozess ist wichtiger als die Werkzeuge Bilder sagen nicht immer mehr als 1000 Worte

Ausblick - Wie weiter?

- 45 -


Welche Fragen sind offen geblieben? Welche weiteren Schulungsinhalte sollen behandelt werden? Sollen gewisse Themen vertieft behandelt werden?

Glossar

Classifier: Die UML abstrahiert das objektorientierte Grundkonzept “Klasse” noch einenSchritt weiter. Verschiedene Eigenschaften von Modellelementen werden bereits auf derabstrakten Ebene des Classifiers definiert, damit sie einheitlich für verschiedeneModellartefakte zur Verfügung stehen. Hierunter fällt beispielsweise die Zuordnungs-beziehung, die festlegt, dass ein Classifier einem anderen zugeordnet werden kann.(Konkrete Ausprägungen eines Classifiers sind z.B. Klassen, Aktivitäten, Use-Cases,Interface, Actor, etc.)

Verhaltensspezifischer Classifier: Da einige Classifier selbst und nicht nur ihreBestandteile Verhalten besitzen, kann man dieses “Classifier-Verhalten” druch eineVerhaltenspezifikation beschreiben. Beispielsweise drückt sich das Gesamtverhalten einesClassifiers durch seine Attributänderungen aus. Diese Veränderungen lassen sich durcheinen Zustandsautomaten beschreiben (z.B. Use-Cases, Klassen, etc.). Keineverhaltenspezifische Classifier sind hingegen: z.B. Interfaces, Assoziationen, Activity.

Kante: Ein Verbindungslinie zwischen zwei Classifiern, die eine Beziehung oder eineAbhängigkeit beschreibt.

- 46 -

UML 2 Theorie Workshop - DHBW Stuttgartrie/literatur/Uml2WorkshopOutline.pdf · Die Executable UML...

Documents

Transcript of UML 2 Theorie Workshop - DHBW Stuttgartrie/literatur/Uml2WorkshopOutline.pdf · Die Executable UML...