UML 2 Tutorial - mario-jeckle.de · DV-Anforderungen DV-Architektur ... Struktur und Einbettung von...

UML 2 Tutorial Net.ObjectDays 2003 Seite 1

UML 2 Tutorial: Einführung in die neue Standardmodellierungssprache

Mario JeckleChris RuppJürgen HahnBarbara Zengler


Darum geht´s

UML 2Standardi-

sierungPraktischer

Einsatz

Über-sichtlichkeit

Ideen

Präzisions-steigerung

Ausführ-barkeit

Vorschläge

Roadmap Abhängig-keiten

Meta-modell

NeueDiagramme

Ver-besserte

Diagramme


Was ist die UML?

Requirements & Use Case-Beschreibungen

Requirements:- Das System soll mit C++ realisiert werden- Bei Anfrage durch einen Kunden muss die Funktionalität sichergestellt sein

...

Deployment - Sicht

Use Case - Sicht

Prozess - Sicht

Implemen-tierungs-Sicht

Datenmodell - Sicht

logische Sicht

Wunsch des Kunden

Notation für Modell des Systemszeigt statische und dynamische AspekteNicht jede Sicht in jedem System sinnvoll


UML ... Geschichten von den fremden Meeren der Standardisierung

OODBooch; 1992

OOSAShlear, Mellor; 1991

OMTRumbaugh, et al.; 1991

State ChartsHarel; 1987

OBABailin; 1989

OOACoad, Yourdan; 1991

OOA&DMartin, Odell; 1992

OOAD&IHenderson-Sellers,

Macrone; 1992

HOODESA; 1990

SCOOPCherry; 1990

OMLFiresmith, Henderson-

Sellers, Page-Jones; 1998

OSAEmbley; 1991

OBARubin; 1992

BONNerson; 1992

FusionColeman, et al.;

1994

Unified Modeling Language v1.0Booch, Jacobson, Rumbaugh;

1997

Unified MethodBooch, Rumbaugh; 1995

SOMAGraham; 1994

CatalysisD’Souza, Willes; 1996

MOSESHenderson-Sellers; 1994

RDDWirfs-Brock; 1990

OOSEJacobson; 1992

Vom Methodenkrieg ...


UML ...Geschichten von den fremden Meeren der Standardisierung

OODBooch; 1992

OMTRumbaugh, et al.; 1991

Erw

eite

rung

OOSEJacobson; 1992

Unified Modeling Language 0.9, 0.91Booch, Rumbaugh, Jacobson; 1996

Unified Modeling Language 1.0UML Partners 1/1997

Unified Modeling Language 1.1UML Partners; 9/1997

OMG Unified Modeling Language 1.3UML Partners; 1999



OMG Unified Modeling Language 2.0UML 2 Partners; unveröffentlicht

OMG Unified Modeling Language 1.2UML Partners; 1998( )

Einsatzerfahrungder Sprachschöpfer

Erfahrungender Anwender

XML MetadataInterchange

Integration derObject Constraint Language

Object Management Groupübernimmt Copyright

Unified Method 0.8Booch, Rumbaugh 1995

...

Bre

itene

insa

tzSt

anda

rdis

ieru

ngVe

rein

heitl

ichu

ngFr

agm

entie

rung

Viele arbeiten für alle

Einige arbeiten für andere

Wenige arbeiten für einige

... zum Standardisierungskrieg


UML 2... Warum eine neue Version?

Evolution- Der Markt hat sich bewegt...

- Neue Programmiersprachen (z.B. C#, Python, PHP)- Neue Anwendungsdomänen

(z.B. Serverprogrammierung, Echtzeitanwendungen)Erfahrung

- Für einige Einsatzgebiete bietet UML v1.x ...- Manchmal zu wenig Konstrukte- Manchmal zu viele- Machmal so viele, dass die sinnvolle

Auswahl schwerfälltEliminierung

- Einige Programmiersprachen verschwinden (z. B. C++)- Einige früher als modellierungsnah eingestufte Konzepte

entwickeln sich inzwischen getrennt von UML weiter(z. B. Entwicklungsprozesse, Codegenerierung)


UML ...Ein Leiden am Second System Syndrom


UML 2Die Ziele

Übersichtlichkeit- Weniger graphische Modellkonstrukte- Weniger Basiskonzepte- Wiederverwendung von Basiskonzepten

Präzisionssteigerung- Reformulierung des Meta-Modells- Weitestgehende OCL-Verwendung- Unveränderte Wiederverwendung von Basiskonstrukten soweit sinnvoll

möglich

Ausführbarkeit- Erweiterte Zustandsmaschinen- Stärkere Beziehungen zwischen statischen und dynamischen

Diagrammen- Integration erprobter Konzepte außerhalb der UML


UML 2 Verrentung existierender Modellelemente

1. Durch UML-Werkzeuge nicht implementierte Sprachanteile

2. Durch OO-Methoden unberücksichtigte Sprachelemente

3. Programmiersprachen-spezifische Sprachelemente

4. Inpräzise UML-Sprachelemente


UML 2Verrentung existierender Modellelemente

SWE 1System-Anforde-

rungsanalyse und-Entwurf

SWE 8

DV-Integration

SWE 2

DV-Anforderungs-analyse und -Entwurf

SWE 9

System-In-tegration

SWE 3

SW-Anforderungsanalyse

SWE 4

Grobentwurf

SWE 5

Feinentwurf

SWE 6

Implementierung

SWE 7

SW-Inte-gration

System-Ebene

Segment-Ebene

Komponenten-Ebene

Modul-/Datenbank-Ebene

System

Handbuch-informationen

DV-Segment

SWKE-Integration

Kompo-nenten-

Integration

Implementierungsdok.(SWKE)

SWKE

Implementierungsdok.(Komponente)

Komponente

Implementierungsdok.(Modul)

Implementierungsdok.(Datenbank)

ModulDatenbank

Konfigurations-einheits-

Ebene

SystemanforderungenSystemarchitekturSystemintegrationsplan

DV-AnforderungenDV-ArchitekturDV-Integrationsplan

SW-Anforderungen

SW-ArchitekturSchnittstellenentwurfSWKE-Integrationsplan

DatenkatalogSW-Entwurf

Abb. 2.7 Funktionsüberblick Submodell SWE

Legende:Prüf-aktivitäten(siehe QS)











KlasseAirgend : intein : boolwichtiges : floatElement : byte

KlasseB

noch : Stringviel : shortwichtiger : float

«friend»



Objekt1 : KlasseAirgend = 1ein = truewichtiges = 3.1Element = 42

Objekt2 : KlasseA«copy»irgend = 1ein = truewichtiges = 3.1Element = 42

«become»






UML 2 Neu: UML Schichten

CompleteEbene 3

IntermediateEbene 2

BasicEbene 1

FoundationEbene 0

Die Idee entstammt der SQL-Standardisierung

Operationalisiert den Begriff der UML-Unterstützung

Auch weniger UML ist immer noch UML


...

...

...

...

Use-Case Akivitätsdiagramm Sequenzdiagramm

complete

intermediate

foundation

basic

Grundlagen Use-Cases

GrundlagenSequenzen

GrundlagenAktivitäten

EinfacherAblaufplan

Parallelität

Gewichtete Kan-ten, Streaming

Anwendungsfall Ablaufdiagramm

(noch nichteingeteilt)




x

x

x

x

x

x

x

x

x

x


Struktur und Einbettung von UML 2

MOF2 Infrastructure

StatischeAnteile Dynamische

Anteile

Unified Modeling Language 2.0

DiagramInterchange

OCL

Super-structure

nutzt

überträgt

UML ist nicht mehr eine monolithische SpracheVier seperate Entwicklungsgruppen werden vier seperate Weiterentwicklungen mit starken inneren Zusammenhang erzeugen


Struktur und Einbettung von UML 2

Verschiedene Weiterentwicklungsvorschläge:- Infrastructure: 36 Lettern of Intents (LOIs);

5 Einreichungen durch 28 Firmen- Superstructure: 37 LOIs;

5 Einreichungen durch 28 Firmen- OCL: 30 LOIs; 4 Einreichungen durch 10 Firmen- Diagram Interchange: 6 LOIs;

3 Einreichungen durch 6 Firmen

Eingereicht durch Einzelfirmen und Konsortien

Bezugnehmend auf einzelne Sprachaspekte der UML v1.x um diese neu zu erweitern; Vorschläge für vollständig neue Diagrammtypen oder die Abschaffung Existierender


Der Weg zu UML 2

0.91.0

IntelliCorpi-LogixIBMObjecTimePlatinum TechnologyPtech TaskonReich TechnologiesSOFTEAM

MicrosoftHewlett-PackardOracleSterling SoftwareMCI SystemhouseUnisysICON ComputingRational Software

1.1/2

MCI Systemhouse

OMGEDS

1.3

Computer Associates

1.4

Sterling SoftwareICON ComputingObjecTimePlatinum Technology

AlcatelKabiraKennedy Carter

1.5

EricssonIONAMotorolaTelelogicBoldsoftAdaptiveFinancial System ArchitectsSUNGentlewareDaimlerChrylser

2.0

MicrosoftHewlett-PackardICON ComputingIntelliCorpPtech TaskonReich Technologies


Vorschläge zur UML 2

Einige komplexe Dinge sollten einfacher werden ...



Manchmal sagen Bilder einfach zu wenig ...



Superstructure und Infrastructure:Ausgereiftester und mit breiter Unterstützung bedachter Vorschlag durch die sog. „UML2 Partners“:

- Mitglieder:Alcatel, Computer Associates, Ericsson, Hewlett-Packard, IONA, Kabira Technologies, Motorola, Oracle, Rational Software, SOFTEAM, Telelogic, and Unisys

- Unterstützer:Advanced Concepts Center, Ceira Technologies, Compuware, Commisariat à L´Energie Atomique, DaimlerChrysler, Embarcardero Technologies, Enea Business Software, France Telecom, ...


UML 2.0 Ablaufplan

Ziel: Ein UML 2.0 Standard

Erste Einreichung ÜberarbeiteteEinreichung Annahme

Erste Einreichung ÜberarbeiteteEinreichung Annahme

Infrastructure RFP

Superstructure RFP

Sep 00 Apr 01 Jun 01 Aug 01 Okt 01 Dez 01 Feb 02

Jan 03 Apr 03 Sep 03


UML 2.0 Standardisierungsablauf

Komplexer Annahmeprozess

Bestätigung durch dasOMG Architecture Board

Jun 03

Sep 03 ?

Okt 03 ?

Jun 04 ?

Sep 04 ?

Okt 04 ?

angenommeneSpezifikation

gültigeSpezifikation

OMGMitgliedsabstimmung

Bestätigung durch dasOMG Board of Directors

UML 2.0 FinalizationTask Force (FTF)

OMGMitgliedsabstimmung

Bestätigung durch dasOMG Board of Directors

Ab diesem Zeitpunkt sind UML 2Artikel, Bücher, Tools, ...

Wahrscheinlich zu erwarten

„offizieller“ Standard(bis Oktober 2004 änderbar)


Diagramme der UML 2

Kommunikations-diagramm

Interaktionsüber-sichtsdiagramm

Zeitverlaufs-diagramm

Sequenz-diagramm

Interaktions-diagramme

Verteilungs-diagramm

Objektdiagramm

Paketdiagramm

Komponenten-diagramm

Struktur-diagramme

ZustandsautomatUse-Case-Diagramm

Aktivitäts-diagramm

Verhaltens-diagramme

Diagramme derUML 2

Klassendiagramm

Kompositions-strukturdiagramm


Wie hätten Sie´s denn gern?

Rational Unified Process Agiles VorgehenArte

XPCrystal EOS

OEP ASDLean SoftwareDevelopment Spiralmodell

V-Modell Unified Process SCRUM


Entscheidungshilfe (1): Gibt es Vorschriften?

Es gibt Vorschriften

Was wird durch Ihre Umwelt erzwungen?- Standardkonformität erforderlich zwecks

Freigabe des Systems (TÜV it, FDA,...)?- Standard/Vorgehensmodell schreibt

gewisse Notation vor- Zertifizierbarkeit des Systems

erforderlich?

Es haben freie Wahl

Machen Sie dasBeste daraus!

Sie haben keine Wahl!Allenfalls ergänzende Informationenin anderen Notationen hinzufügen und auf Vorschriften abbilden!


Entscheidunghilfe (2): Akzeptanz von Formalität

Leser akzeptiert keinerleiFormalismus

Prototypen jeglicher Art (Lo-fi, Hi-fi)

Leser akzeptiert Formalismus

Was wünschen/ akzeptieren dieStakeholder?

- Wie hoch ist die Motivation, sich in Dokumente des Entwicklungsprozesses zu vertiefen?

- Welche Grundausbildung haben die Betroffenen?

- Aufgeschlossenheit gegenüber neuen Notationen vorhanden?

- Starke Fixierung auf die alt bekannte Methode?

Entscheiden Sie zwischen „Lesbarkeit“, „Verständlichkeit“auf der einen Seite und „Prüfbarkeit“, „Automatisier-barkeit“ auf der anderen Seite.


Entscheidungshilfe (3):Eignung für die Problemstellung

.... Jetzt kommt endlich die Fragen nach dem fachlichen Inhalt, den ein Modell darstellt


Diagramme der UML und ihre Anwendung I

Diagrammtyp Diese zentrale Frage beantwortet das Diagramm

Stärken

Klassendiagramm Aus welchen Klassen besteht mein System und wie stehen diese untereinander in Beziehung?

Beschreibt die statische Struktur des Systems.Enthält alle relevanten Struktur-zusammenhänge/Datentypen.Brücke zu dynamischen Diagrammen.Normalerweise unverzichtbar.

Paketdiagramm Wie kann ich mein Modell so schneiden, dass ich den Überblick bewahre?

Logische Zusammenfassung von Modellelementen.Modellierung von Abhängigkeiten/ Inklusion möglich.

Objektdiagramm Welche innere Struktur besitzt mein System zu einem bestimmten Zeitpunkt zur Laufzeit (Klassendiagramm-schnappschuss)?

Zeigt Objekte u. Attributbelegungen zu einem bestimmten Zeitpunkt.Verwendung beispielhaft zur Veranschaulichung Detailniveau wie im Klassen-diagramm.Sehr gute Darstellung von Mengenverhältnissen.


Diagramme der UML und ihre Anwendung II


Stärken

Kompositionsstruktur-diagramm

Wie sieht das Innenleben einer Klasse, einer Komponente,eines Systemteils aus?

Ideal für die Top-Down-Modellierung des Systems (Ganz-Teil-Hierarchien).Zeigt Teile eines „Gesamtelements“und deren Mengenverhältnisse.Präzise Modellierung der Teile-Beziehungen über spezielle Schnittstellen (Ports) möglich.

Komponentendiagramm Wie werden meine Klassen zu wieder verwendbaren, verwaltbaren Komponenten zusammengefasst und wie stehen diese in Beziehung?

Zeigt Organisation und Abhängig-keiten einzelner technischer Systemkomponenten.Modellierung angebotener und benötigter Schnittstellen möglich.

Verteilungsdiagramm Wie sieht das Einsatzumfeld (Hardware, Server, Datenbanken, …) des Systems aus? Wie werden die Komponenten zur Laufzeit wohin verteilt?

Zeigt das Laufzeitumfeld des Systems mit den „greifbaren“ Systemteilen.Darstellung von „Softwareservern“möglich.Hohes Abstraktionsniveau, kaum Notationselemente.


Diagramme der UML und ihre Anwendung III


Stärken

Use-Case-Diagramm Was leistet mein System für seine Umwelt (Nachbarsysteme, Stakeholder)?

Außensicht auf das System.Geeignet zur Kontextabgrenzung.Hohes Abstraktionsniveau, einfache Notationsmittel.

Aktivitätsdiagramm Wie läuft ein bestimmter fluss-orientierter Prozess oder ein Algorithmus ab?

Sehr detaillierte Visualisierung von Abläufen mit Bedingungen, Schleifen, Verzweigungen.Parallelisierung und Synchronisation.Darstellung von Datenflüssen.

Zustandsautomat Welche Zustände kann ein Objekt, eine Schnittstelle, ein Use Case, …bei welchen Ereignissen annehmen?

Präzise Abbildung eines Zustands-modells mit Zuständen, Ereignissen, Nebenläufigkeiten, Bedingungen, Ein- und Austrittsaktionen.Schachtelung möglich.

Wer tauscht mit wem welche Informationen in welcher Reihenfolge aus?

Darstellung d. Informationsaustauschs zwischen Kommunikationspartnern Sehr präzise Darstellung der zeitlichen Abfolge auch mit Nebenläufigkeiten.


Diagramme der UML und ihre Anwendung IV


Stärken


Wer kommuniziert mit wem? Wer „arbeitet“ im Systemzusammen?

Stellt den Informationsaustausch zwischen Kommunikationspartnern dar.Überblick steht im Vordergrund (Details und zeitliche Abfolge weniger wichtig).

Timingdiagramm Wann befinden sich verschiedene Interaktionspartner in welchem Zustand?

Visualisiert das exakte zeitliche Verhalten von Klassen,Schnittstellen,..Geeignet für die Detailbetrachtungen, bei denen es wichtig ist, dass ein Ereignis zum richtigen Zeitpunkt eintritt.

Interaktionsübersichts-diagramm

Wann läuft welche Interaktion ab? Verbindet Interaktionsdiagramme (Sequenz-, Kommunikation- undTimingdiagramme) auf Top-Level-Ebene.Hohes Abstraktionsniveau.


UML 2 –Die Strukturdiagramme

Barbara ZenglerMario Jecklewww.uml-glasklar.de


Zwei Dinge sind zu unserer Arbeit nötig: Unermüdliche Ausdauer und die Bereitschaft, etwas, in das man viel Zeit und Arbeit gesteckt hat, wieder wegzuwerfen.

Albert Einstein


Diagramme der UML 2




Sequenz-diagramm



Objektdiagramm

Paketdiagramm


Struktur-diagramme




Diagramme derUML 2

Klassendiagramm



Die StrukturdiagrammeKlassendiagrammEine Zusammenstellung deklarativ-statischer Modellelemente (d.h. Klassen, Typen, ihre Inhalte und Beziehungen)ObjektdiagrammEnthält Objekte und BeziehungsausprägungenPaketdiagrammStellt die logische Organisation von Modellelementen und deren Abhängigkeiten darKomponentendiagrammZeigt die Organisation und Abhängigkeiten von KomponentenKompositionsstrukturdiagrammZeigt die interne Struktur eines classifiers sowie seine Möglichkeiten zu Interaktion mit anderen SystemkomponentenVerteilungsdiagrammZeigt die Ausführungssicht des Systems


Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm



Warum neue oder geänderte Strukturdiagramme?Hintergrund

Statische Modellierung seit Mitte der 1970er Jahre gängig und hinreichend erforscht(z.B. Entity-Relationship)Darstellung nicht ausführbarer statischer Zusammenhänge durch die ersten OO-Modellierungssprachen (u.a. Boochs OOSE, Rumbaughs OMT) weidlich bearbeitetStrukturdiagramme (insbesondere Klassendiagramme) ausgereiftester und stabilster Teil der UML v1.x

Jüngere Entwicklungstrends, die eine Neufassung rechtfertigenMetamodellierungKonzeptionelle BereinigungWiederverwendung von bestehenden Konstrukten


Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm



Änderungen an den Strukturdiagrammen!?Statische Diagramme besitzen in der UML und ihrerAnwendung eine hervorgehobene Bedeutung

Bekanntester DiagrammtypMeistverwendester DiagrammtypBasis des UML-MetamodellsBasis des UML-Metametamodells (Meta Object Facility)

Änderungen„automatisch“ sehr sichtbarfür den UML-Anwender „spürbar“beeinflussen u.U. gesamtes Sprachkonzeptwirken sich auf andere (Meta-)Sprachen ausInhärente Bedeutung für den Modellaustausch zwischen Werkzeugen (XMI-Format wird aus Metamodell generiert)


Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm



Statische Diagramme der UML 2

45%

9%7%

19%

15% 5%

Klassendiagramm

Komponentendiagramm

Objektdiagramm

Kompositionsstrukturdiagramm

Verteilungsdiagramm

Paketdiagramm




Sequenz-diagramm



Objektdiagramm

Paketdiagramm


Struktur-diagramme




Diagramme derUML 2

Klassendiagramm


„wichtigster“ Diagrammtyp

neuer Diagrammtyp

meist-geänderter Diagrammtyp


Basiskonzepte

Die UML-Basiskonzepte sindAbstraktionTypisierung und IdentitätStrukturierung (d.h. gekapselte Eigenschaften und vielfältige Beziehungen)Erweiterbarkeit der Sprache


Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm



Basiskonzepte



Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm


UML 2 ...Erweitert die Nutzung der ClassifierVereinheitlicht ähnliche Konzepte unter gemeinsamen OberbegriffenBietet neue Diagrammtypen und -sichten


Basiskonzepte -- Abstraktion


Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm



Classifier

DataType

PrimitiveType Enumeration

Association

CommunicationPath AssociationClass Interface

Class(from Kernel)Signal

Artifact

BehavioredClassifier StructuredClassifierInformationItemActor

Behavior Class(from Communications) UseCase Collaboration EncapsulatedClassifier

Activity Interaction StateMachine

ProtocolStateMachine

Class(from StructuredClasses)

Node

Device ExecutionEnvironment




Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm


UML 2 ...Erweitert die Nutzung der Classifier

Beziehungen (Assoziationen) werden zwischen ihnen geknüpft... können Charakteristika (Attribute) besitzen... können Verhaltensspezifikationen (Operationen) besitzen... können generalisiert werden... können autonom auf Signale reagieren... können ausschließlich der Strukturierung dienen (abstract)

Classifier

DataType


Association



Artifact






Node





Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm



Beispiel:Artefakt kann beliebige paktierbare Elemente „manifestieren“

myWebApp

.xml

.class

.html

.jsp

«artifact»

myApp.war«manifest»

Anwendung:Deployment von Webapplikationen




Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm



Beispiel:KompositionsstrukturdiagrammZeigt die interne Struktur eines Classifiers sowie seine Möglichkeiten zu Interaktion mit anderen Systemkomponenten


Basiskonzepte



Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm


UML 2 ...Verhältnis zwischen Classifier und typisierten Elementen klarer gefasstUnterschied zwischen „typisiert sein“ und „Typ sein“ verwirklichtIdentitätsverhalten geklärt(Insbesondere bei dynamischer Verarbeitung statischer Daten)


Basiskonzepte –Typisierung und Identität


Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm


UML 2 ...Verhältnis zwischen Classifier undtypisierten Elementen klarer gefasstUnterschied zwischen „typisiert sein“ und „Typ sein“ verwirklichtIdentitätsverhalten geklärt(Insbesondere bei dynamischer Verarbeitung statischer Daten)

Element ElementUML 1.x UML 2

ModelElementname

Namespace GeneralizableElement

NamedElementname

TypedElement Type

Classifier Classifier


Basiskonzepte –Typisierung und Identität


Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm


UML 2 ...Verhältnis zwischen Classifier undtypisierten Elementen klarer gefasstUnterschied zwischen „typisiert sein“ und „Typ sein“ verwirklichtIdentitätsverhalten geklärt(Insbesondere bei dynamischer Verarbeitung statischer Daten)

UML 2 ...Identitätsbesitz ist nicht mehr statisch über die gesamte LebensdauerIdentitätsbehaftete Objekte können durch dynamische Aktivitäten ihre Identität verlieren oder wechselnTeilweise (beispielsweise in Kollaborationen) ist sie sogar unerheblich


Basiskonzepte



Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm


UML 2 ...Assoziationen zur Formulierung von Beziehungen zwischenClassifier-Ausprägungen (viele (unnötige) Einschränkungen) entfallen (z.B. Anwendung auf Use-Cases))

Generalisierungen zur Hierarchisierung von Classifiern(Damit sind z.B. Pakete nicht mehr naiv generalisierbar, hierfür existiert ein separiertes „merge“-Konzept)

Abhängigkeitsbeziehungen dokumentieren logische Wechselwirkungen


Basiskonzepte -- Strukturierung


Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm


UML 2 ...Assoziationen zur Formulierung vonBeziehungen zwischen Classifier-Ausprägungen (viele (unnötige) Einschränkungen) entfallen (z.B. Anwendung auf Use-Cases))



Konstrukteur

Kundenbetreuer

Konstruktion

Änderungswunsch entgegennehmen




Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm





Konstrukteur

Kundenbetreuer

KonstruktionKundenbetreuer

Änderungswunsch entgegennehmen




Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm





Classifier

Generalization1 general

specific*

isSubstitutable

Alle Classifier-Spezialisierungen sind nun spezialisierbarSubstituierbarkeit expliziert


Der Classifier-ZooClassifier

DataType


Association



Artifact






Node


Alle Classifier-Spezialisierungen sind nun spezialisierbar




Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm





Neue Notation (genaugenommen gibt es erstmals eine)

Programmiersprachenspezifische Abhängigkeiten entfallenz.B. C++-spezifisches „friend“

«metaclass»Klasse «stereotype»

persistent

«persistent, xml»Partyteilnehmer

«persistent»Gastgeber

«stereotype»xml


Klassendiagramm ---Das „wichtigste“ Diagramm


Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm

Kompositions-strukturdiagrammKlassendiagramm


Klassendiagramm


Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm


Funktion:Zusammenstellung deklarativ-statischer Modellelemente (d.h. Klassen, Typen, ihre Inhalte und Beziehungen)

Aufgabe im Projekt:Variierend ...

von der ersten Darstellung konzeptueller Dateninhalteüber plattformunabhängige logische Modellebis hin zu „Implementierungsbauplänen“(„Bilder-für-Java“, „Kästchen-und-Strichchen-statt-C++“)

Ersetzt oftmals das klassische, in Entity Relationship-Notation abgefasste, Datenmodell


Klassendiagramm

Gast

feiere()

Feier

+termin : Datum

abbrechen()

Gastgeber

hektisch : Boolean = true

begruesse(in g : Gast)verabschiede (in g : Gast)treibeAn(in b : Barmixer)

Cocktail

Zutaten : Zutat [1..*]

Barmixer

+mixe(in z : Zutat [1..*], out c:Cocktail)

Zutat

+name : String

Häppchen

empfängt{unique}1..*

besucht

verabschiedet{unique}1..*

mixt

1..*

treibt an

isst {ordered}0..*

unterhält

*

1 mixt für

1..1

«enumeration»Begeisterung

ekstatischverzücktneutralgelangweiltüberdrüssig

Partyteilnehmer

/betrunken : Boolean = false~intus : Cocktail [1..*]#begeistert : Begeisterung

«interface»Esser

iss(in h : Häppchen; return satt:Boolean)

Esser Esser

#überdenkeBegeisterung()~trinke(in c : Cocktail)

Klasse

Klassenname

Attribut

AggregationKomposition

Assoziation

Multiplizität

Rolle

Operation

GeneralisierungSchnittstelle

abstrakte Klasse

gerichtete Assoziation

Stereotyp

Eigenschaftswert


Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm



Klassendiagramm


Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm


Gast

feiere()

Feier

+termin : Datum

abbrechen()

Gastgeber

hektisch : Boolean = true

begruesse(in g : Gast)verabschiede (in g : Gast)treibeAn(in b : Barmixer)

Cocktail

Zutaten : Zutat [1..*]

Barmixer

+mixe(in z : Zutat [1..*], out c:Cocktail)

Zutat

+name : String

Häppchen

empfängt{unique}1..*

besucht

verabschiedet{unique}1..*

mixt

1..*

treibt an

isst {ordered}0..*

unterhält

*

1 mixt für

1..1

«enumeration»Begeisterung

ekstatischverzücktneutralgelangweiltüberdrüssig

Partyteilnehmer

/betrunken : Boolean = false~intus : Cocktail [1..*]#begeistert : Begeisterung

«interface»Esser

iss(in h : Häppchen; return satt:Boolean)

Esser Esser

#überdenkeBegeisterung()~trinke(in c : Cocktail)

Klasse

Klassenname

Attribut

AggregationKomposition

Assoziation

Multiplizität

Rolle

Operation

GeneralisierungSchnittstelle

abstrakte Klasse

gerichtete Assoziation

Stereotyp

EigenschaftswertKlasse

Sichtbarkeit / name : Typ [Multiplizität] = Vorgabewert {Eigenschaft=Wert}

Klasse

Sichtbarkeit name (Richtung Name : Typ [Multiplizität]=Vorgabe {Eigenschaft=Wert}) : Rückgabetyp {Eigenschaft=Wert}

[1..3]


Klassendiagramm


Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm


Neu in UML 2:

Klasse1 Klasse2«Abhängigkeitsname»

Klasse3

Klasse4

Klasse5

Klasse6

Kommentar zurAbhängigkeitsbeziehung


Klassendiagramm

Neu in UML 2:- Attribute besitzen Ordnung- Graphische Assoziationsnotation

(Nutzung des „großen leeren Diamanten“auch für binäre Assoziationen)- Kommentarnotation „mit Punkt“

Geändert in UML 2:- Graphische Schnittstellennotation (Lollipops) jetzt Standard- Spezifikation von Sichtbarkeit, Name, Typ und Multiplizität für Operationen

und Attribute vereinheitlicht- Multiplizitätsdefinition schärfer formuliert - Attribute sind keine implizite Kompositionsassoziation mehr

Entfällt in UML 2:- Programmiersprachenmanifestationsspezifische Eigenschaften

(z.B. friend)- Eigenschaften und Stereotypen unklarer Semantik

(z.B. become und copy)


Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm



Kompositionsstrukturdiagramm ---Ein neues Diagramm in UML 2


Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm





Funktion:Zeigt die interne Struktur eines Classifiers sowie seine Möglichkeiten zu Interaktion mit anderen Systemkomponenten

Aufgabe im Projekt:Beschreibung von extern angebotenen SchnittstellenAbstraktion der Operationen und des Signals


Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm


KompositionsstrukturdiagrammKompositionsstrukturdiagramm



Basiskonzepte:PartPortKollaborationKonnektorRollenverwendung


Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm





Basiskonzepte:PartObjekte oder RollenausprägungenPortÖffentlich sicht- und zugreifbarer Interaktionspunkt, der auf einen Operationsaufruf oder den Empfang eines Signals reagiertKollaborationZusammenspiel von Operationen oder ClassifiernKonnektorAssoziationsinstanz (Link), die Kommunikation zwischen (allgemeinen) Instanzen ermöglichtRollenverwendungBindet realisierende Classifier an Kollaborationsinstanz


Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm






Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm


KompositionsstrukturdiagrammKompositionsstrukturdiagrammNeu in UML 2:

Port: Definiert einen öffentlich sicht-und zugreifbaren Interaktionspunkt, der auf einen Operationsaufruf oder den Empfang eines Signals reagiert.

Klasse

bereitgestellteSchnittstelle

benötigteSchnittstelle

Stereoanlage

partybeschallung

strom, medium




Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm



Port: Werden durch andere Classifieroder Ports angesprochen.

Musikerzeugung

Stereoanlage : Steckdosekabel

Musikerzeugung

: HamsterradStereoanlagetransformator

Konnektor

Konnektor




Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm



Behavior Port:Wie Port, allerdingsmit der Einschränkung, dass der definierende Classifier das Verhalten selbst manifestieren muss, andernfalls ist die empfangende Botschaft oder das empfangene Signal verloren.Kann Sichtbarkeits- und Zugriffsbeschränkt sein.

Stereoanlage

partybeschallung

strom, medium




Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm


KompositionsstrukturdiagrammKompositionsstrukturdiagrammÜberarbeitet in UML 2:

Kollaboration: Visualisiert das Zusammenspiel von Operationen oder Classifiern




Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm



Kollaboration: Visualisiert das Zusammenspiel von Operationen oder Classifiern




Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm



Beispiel:




Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm



- Der gesamte Diagrammtyp- Ports als gemeinsame Abstraktion

von Operationen und Signalen- Auffassung von Kollaborationen als Teile von

Kompositionsstrukturen

Geändert in UML 2:- Schnittstellennotation- Möglichkeiten zur Darstellung von Kollaborationen


Verteilungsdiagramm ---Das Diagramm mit den meisten Änderungen


Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm


Verteilungsdiagramm


Verteilungsdiagramm

Funktion:Zeigt die Ausführungssicht des Systems

Aufgabe im Projekt:Beschreibung der SystemarchitekturErweitert Systemsicht um an der Ausführung beteiligte oder zur Ausführung benötigte Hardwarekomponenten


Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm


VerteilungsdiagrammVerteilungsdiagramm


Verteilungsdiagramm

Basiskonzepte:ArtefaktPhysische Informationseinheit, die währenddes Entwicklungsprozesses erzeugt oderverwendet wird.(z.B. Modelle, Quellcode, Objekdateien, ...)KnotenClassifier, der eine zur Ausführungszeit verfügbare Ressourcedarstellt.Einsatzspezifikation (Deployment Specification)Paramtermenge, die Laufzeitverhalten festlegt


Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm




Verteilungsdiagramm


Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm



«device»: Application Server

J2EE Server«execution environment»: J2EE Server

entry.jspconfig.xmlMyBean.class

«artifact»

application.jar«deploy»

Artefakt

Knoten

Deployment-Beziehung

«device»: DB Server

1..*

1..*

Assoziation«deployment spec»

appDesc.xml

Deployment-Spezifikation

execution : threadtransaction : false


Verteilungsdiagramm


Objektdiagramm

Paketdiagramm


Struktur-diagramme

Klassendiagramm


VerteilungsdiagrammVerteilungsdiagrammNeu in UML 2:

- Aktuelle Ausführungs- und Laufzeitumgebungen wie J2EE und .NET werden besser berücksichtigt

Geändert in UML 2:- Knoten können hinsichtlich ihrer Rollen zum Ausführungszeitpunkt

feinspezifiziert werden- Ausdetaillierung der Abhängigkeitsbeziehungen

Entfällt in UML 2:- Unpraktikable graphische Darstellung des Knotens


Fazit ---statische Diagramme in UML 2

Absichtsvoll wenig „spürbar“ Neues- Im Hintergrund

- Klarere Basiskonzepte- Deutlich mehr Wiederverwendung- Fast vollständig neues Metamodell

Modifizierte Semantik vieler (Meta-)ModellelementeEinige neue graphische PrimitiveReichhaltigeres Angebot an Abhängigkeiten und „eingebauten“ Modellerweiterungen (Stereotypen)Behutsame Verrentung „problematischer“ Modellelemente


UML 2 –Die Verhaltensdiagramme

Chris RuppJürgen Hahnwww.uml-glasklar.de


Diagramme der UML 2




Sequenz-diagramm



Objektdiagramm

Paketdiagramm


Struktur-diagramme




Diagramme derUML 2

Klassendiagramm



Use-Case-Diagramm

„Die Neugier steht immer an erster Stelle eines Problems, das gelöst werden will.“

Galileo Galilei


Use-Case-DiagrammAnwendung im Projekt

Darstellung der funktionalen Dienstleistungen eines SystemsAbgrenzung des Systems gegenüber seiner UmweltAufteilen des Systems aus einer AußensichtErstellung planbarer EinheitenSchaffen einer Kommunikationsgrundlage zwischen Stakeholdern


Use-Case-DiagrammDie Elemente im Überblick

«include» «extend»

Anwendungsfall

Use-Case Subject Akteur

System

Benutzer

Beziehung «include»-Beziehung «extend»-Beziehung Generalisierungs-beziehung


Use-Case-Diagramm

Use-Case:- spiegelt ein funktionales Verhalten wieder- wird durch Akteur angestoßen- liefert ein für den Akteur sichtbares Ergebnis

Akteur:- beschreibt eine Rolle - steht außerhalb des Systems- interagiert mit dem System- kann eine Person, ein Nachbarsystem, .... sein


Use-Case-Diagramm

System (Betrachtungsgegenstand):- Umgrenzt die Einheit, welche die Use-Cases realisiert- Darstellung ist nicht zwingend notwendig

Assoziationen:- beschreiben die Beziehungen zwischen Akteuren und Use-

Cases- «Extend»-Beziehung: Verhalten eines Use-Case kann durch

einen anderen erweitert werden- «Include»-Beziehung: Verhalten eines Use-Case ist

vollständig in einem anderen enthalten


Use-Case-DiagrammDie Anwendung

Extend-Beziehung

Verkauf

Systemname Systemgrenze

Akteur

Verkaufsposteneingeben

Kreditwürdigkeitprüfen

Kunde nichtgefunden

«include»

«extend»

AssoziationInclude-

Beziehung

Use-Case

Kundendateneinsehen

extension points:fehlender KundeVerkäufer


Use-Case-DiagrammDie Anwendung

Bürger

Finanzamt

Steuern zahlen

Auskunft über Finanzen geben- Einkommen- Vermögen+ Belege zeigen()+ Einkommensbeleg vorlegen()

Steuern hinterziehen- Einkommen- Vermögen+ Belege fälschen()+ Privat-/Geschäftskosten vermischen()

Lohnsteuerkartebeantragen- Familienstand- Steuerklasse+ Formular ausfüllen()+ Karte ausdrucken()


Use-Case-DiagrammKontextabgrenzung

Abgrenzung von Systemen zu ihren Nachbarsystemen

Fast Food RestaurantBestellung

Rechnung

Bestellung

Waren

Geld

Nahrung

Geld

Rechnung

Richtlinien

BestätigungZinsen

Geld

Amt

Kunde

Zulieferer

Bank


Use-Case-DiagrammDie wichtigsten Änderungen

UML 1.x UML 2

Ein Akteur darf unbenannt sein Ein Akteur muss einen Namen haben

Nur Pakete können Use-Cases besitzen. Classifier im Allgemeinen können Use-Cases besitzen.

Als Realisierer von Use-Cases werden (Sub-) Systeme impliziert, obwohl jeder Classifier einen Use-Case realisieren darf.

Es wird deutlich herausgestellt, dass alle Classifier Use-Cases realisieren können.

Bei der «extend»-Beziehung werden die Vorbedingungen nur in der Nähe der entsprechenden Relation angetragen:

Die Vorbedingung und die entsprechenden extension points werden als Notiz an die Erweiterungsbeziehung angehängt:

«Vorbedingung»{Benutzer ruft Hilfefunktion auf}

«extend»

extension point: Hilfethema

«extend»

Benutzer ruft Hilfefunktion auf


Use-Case-DiagrammVorsicht: Fehler die vermieden werden sollten

Bezeichnung des Akteursfehlt

Verkauf

Kundendateneinsehen

Kreditwürdigkeitprüfen

Kunde nichtgefunden

Use-Case Name fehltAkteur muss außerhalb des

Systems stehen

Zwischen Use-Cases des selben Systems dürfenkeine Assoziationen vorhanden sein

Assoziationen dürfen nurbinär sein

Bürgen finden«extend»

Angabe desErweiterungspunktes fehlt

Verkäufer


Aktivitätsdiagramm

„Wenn du etwas so machst, wie du es seit zehn Jahren gemacht hast, dann sind die Chancen recht groß, daßdu es falsch machst.“

Charles Kettering


AktivitätsdiagrammAnwendung im Projekt

Aktivitätsdiagramme visualisieren mögliche Abläufemit veränderbarem Detaillierungsgrad

vielfache Anwendungsgebiete

GeschäftsprozessmodellierungBeschreibung von Use-CasesImplementieren einer Operation


AktivitätsdiagrammDas Tokenkonzept

Das Tokenkonzept wurde den Petrinetzen entnommenDer Ablauf in einer Aktivität wird durch den Tokenfluss gesteuertErmöglicht die präzise Beschreibung des VerhaltensDie Token sind nur ein Gedankenkonstrukt (keine explizite Modellierung)

Achtung! Tokenkonzept bewirkt semantische Änderungen zu UML 1.x Aktion 1 Aktion 2

Aktion 3

Aktion 1 Aktion 2

Aktion 3

UML 1.x UML 2

ODER UND

Aktion 1 Aktion 2


AktivitätsdiagrammeDie wichtigsten Elemente im Überblick

Eingangsparameter Ausgangsparameter

Objekttyp

Objektknoten

Aktionsname

Aktion

Aktivität

Name

Startknoten

Endknoten

Verzweigungsknoten

Verbindungsknoten Synchronisationsknoten

Parallelisierungsknoten

Kontrollelemente

Kante

StrukturierteKnoten


AktivitätsdiagrammAktivität - Aktion

Aktivität beschreibt das komplette DiagrammKann Ein- und Ausgangsparameter haben

Aktionen sind VerhaltensaufrufeSumme der Aktionen realisiert die Aktivität

Zutaten mischen

Eis zerkleinern

in Gläser füllen

Cocktail mixen

Zutaten Cocktail

AktivitätAktion

EingangsparameterAusgangsparameter


AktivitätsdiagrammObjektknoten

Objektknoten repräsentierennicht das Objekt selber, sondernden Typ des ObjektsDarstellung als Objektknotenoder durch Pin-Notation

Objektknoten als Datenspeicher

Cocktail mixen Cocktail

Cocktail mixenCocktail

Cocktail trinkenCocktail

«centralBuffer»

«datastore»Name

[Zustand]


AktivitätsdiagrammKontrollelemente I

Kontrollelemente steuern den Ablauf der AktivitätKontrollelemente

- starten und beenden Abläufe- ermöglichen parallele Abläufe- können mehrere Abläufe

synchronisieren- lassen alternative Abläufe zu

[Lustvorhanden]

Einladung bekommen

Einladung Datum prüfen

Lust auf Feierprüfen

Feier absagen Zur Feierzusagen

[keine Zeit]

[Zeitvorhanden]

[keine Lust]

Kante

Bedingung

Kontrollknoten

möglicher Ablauf


AktivitätsdiagrammKontrollelemente II

Startknoten:- Starten den Ablauf- Mehrere Startknoten initiieren parallele Abläufe

Endknoten:- Beenden die Aktivität oder- einen einzigen Ablauf

Kanten:- Übergänge zwischen zwei Knoten- Beschreiben die Ablaufrichtung

Startknoten

Endknoten

Kante


AktivitätsdiagrammKontrollelemente III

Verzweigungsknoten:- Ermöglichen alternative Abläufe- Bedingungen geben Ablaufrichtung vor

Verbindungsknoten:- Vereinigen mehrere Abläufe

Parallelisierungsknoten:- Aufteilen in parallele Abläufe

Synchronisationsknoten:- Zusammenführen paralleler Abläufe

Verzweigungsknoten

Verbindungsknoten

Parallelisierungsknoten

Synchronisationsknoten


AktivitätsdiagrammUnterbrechungsbereich und Exception-Handler

Unterbrechungsbereich:- Umfasst ein oder mehrere Aktionen- Kann über Unterbrechungskante

verlassen werden- Alle Aktionen im Bereich werden

dann gestoppt

Exception-Handler:- Ermöglicht die Beschreibung von Ausnahmen- Exception-Handler substituiert eine Aktion

Unterbrechungsbereich Unterbrechungskante

Aktion

Exception-Typ

Exception-Handler


Strukturierte Knoten

Umfassen mehrere Elemente einer AktivitätAblauf startet erst dann, wenn an allen eingehenden kanten Token anliegenObjektknoten als Ein- und Ausgangsparameter möglich

Schlüsselwort


Strukturierte KnotenEntscheidungsknoten

Visualisierung komplexer Entscheidungenif: prüfen der Bedingungthen: auszuführende

Elementeelse: möglicher Ablauf,

wenn kein if-Bereichzutrifft

else if: wie if-Bereich nur mit vorgegebenerPrüfreihenfolge

if

then

else

schmackhaft?

Schlechte Kritikerstellen

Gute Kritikerstellen

Restaurant Bewertung

Speise

Speise bewerten


Strukturierte KnotenMengenverarbeitung

Einzelne Betrachtung der Elemente welche in der restlichen Aktivität nur als Sammlung betrachtet werden z.B. Vektorkomponenten, hashtable, verkettete Listen....

Elemente werden als Objektknoten (Pin) übergeben

Bierkistebesorgen Flasche öffnen Flasche leeren leere Bierkiste

zurückgeben

iterative


Strukturierte KontenSchleifenknoten

Visualisieren den Ablauf komplexer Schleifen

for: initiale Aufgabenwhile: prüfen der Bedingung

für einen Durchlaufdo: Schleifenrumpf

Reihenfolge do – while ist optional

for

while

do

X = Zahl 1 Y = Zahl 2

A = X+ Zähler A < Y

Zähler = Zähler +1

Zähler = 0

Zahl 1 Zahl 2


AktivitätsdiagrammAktivitätsbereiche

Einteilen des Diagramms in Bereiche mit gemeinsamen EigenschaftenHierarchische und mehrdimensionaleAufteilung möglich

PKW parken

Menü bestellen Menüzusammenstellen

KassierenMenü verzehren

PKW ausparken

Fastfood-Restaurant besuchen

Kunde Bedienung

Par

kpla

tzR

esta

uran

t

Ort

Person

Bere

ichs

nam

e


AktivitätsdiagrammDie wichtigsten Änderungen

UML 1.x UML 2

Aktivitätsdiagramm als „Sonderform“ des Zustandsdiagramms.

Aktivitäten sind unabhängig von Zustandsautomaten.

Aktivitätsdiagramme entsprechen in der Struktur den Zustandsdiagrammen.

Aktivitäten verwenden eine den Petri-Netzen ähnlich Semantik (Token-Konzept).

Diagramm heißt Aktivitätsdiagramm. Diagramm wird als Aktivität bezeichnet.

Es ist nur ein Anfangszustand erlaubt. Es sind mehrere Startknoten erlaubt.

Notationssymbole für Zustand und Aktivität unterschiedlich:

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

Aktivitätsdiagramme haben keine Ein- und Ausgabeparameter.

Aktivitäten können Ein- und Ausgabeparameter enthalten.

Parallele Stränge müssen zusammengeführt werden.

Parallel Abläufe müssen nicht wieder zusammengeführt werden.

Swimlanes sind immer eindimensional Aktivitätsbereiche können hierarchisch oder multidimensional sein.

ZustandAktionszustand1 Aktion Zustand


AktivitätsdiagrammVorsicht: Fehler die vermieden werden sollten

Biergartenbetreten

Bier bestellen Bier trinken

Sitzplatz suchen

Biergarten

bezahlenBiergartenverlassen

FehlenderAktionsname

FehlendeBedingungen

Fehlender Pin

Durch vorherigeVerzweigung ist hier eine

Synchronisation nichtmöglich


Zustandsautomaten

„Take your chance while you still got a choice.“

Scott/Young/Young


ZustandsautomatEinfaches Beispiel

sm Scheibenwischer

Ausgangsstellung

Waschengewählt

Wischengewählt

after(3seconds) /Waschen beenden

Wischenbeendet

Waschengewählt

after(3seconds) /Waschen beenden

[Wischer inParkposition]



Nachwischen Wi

entry / in Parkposition bringen

Nachwischen Wa

entry / in Parkposition bringen

Fertigwischen

entry / in Parkpositionbringen

Wischendo / normal wischen

Wischen [schnell] / schnell wischenWischen [Intervall] / Intervall wischen

Waschendo / Waschen

Waschen Wido / Waschen


ZustandsautomatAnwendung im Projekt

Zustandsautomaten bilden Verhalten ab:- in welchem Zustand kann - unter welcher Bedingung - bei welchem eingehenden Ereignis - welche Transition ausgeführt werden

Anwendungsgebiete- Zustandsbeschreibung von Classifiern, u. a.- Detaillierung von Use-Cases- Verhaltensbeschreibung von Interfaces und Ports- Detailbeschreibung von Signal- und Ereignisempfang


ZustandsautomatDie wichtigsten Elemente im Überblick

sm Zustandsautomat

TerminatorVereinigungGabelung

Hflache Historie

H*

tiefe Historie

KreuzungEntscheidungStartzustand EintrittspunktAustrittspunkt

Pseudozustände

zusammengesetzter Zustand

Trigger [Guard] / Aktivität

Transition inVerhaltenszustandsautomaten

Transition inProtokollzustandsautomaten

[Vorbedingung] Operation / [Nachbedingung]

Zustandsname

einfacher Zustand

Unterzustandsautomatenzustand : sm Unterzustandsautomat

Unterzustandsautomatenzustand

Endzustand

Zustandsname


ZustandsautomatZustandsautomat

Unterscheidung:- Verhaltenszustandsautomaten- Protokollzustandsautomaten

Ein Verhaltenszustandsautomatbildet das diskrete Verhalten einer Instanz eines Classifiers ab.

Ein Protokollzustandsautomatbeschreibt die erlaubte Aufrufsab-folge der Instanz eines Classifiers.

sm Zustandsautomatenname

sm Zustandsautomatenname{protocol}


ZustandsautomatProtokollzustandsautomat

sm Ampel

rot

gelb

grünrot-gelbschalte(grün) /

gelb(an) /

schalte(gelb) /

schalte(rot) /

rot(an) /

[reset]schalte(rot) /

[aus] /


Zustandsautomateinfacher Zustand und Transition

Ein Zustand beschreibt eine bestimmte Ausprägung:

- eine statische Situation- auf ein externes Ereignis wartend

Kann Aktivitäten enthalten:- entry, do und exit activity- interne Transitionen- verzögerte Ereignisse

Eine Transition ist der Übergang von einem Quell- zu einem Zielzustand

Zustandsnameentry / Aktivitätexit / Aktivitätdo / AktivitätTrigger [Guard] / AktivitätTrigger [Guard] / defer

Zustandsname

[Vorbedingung] Operation / [Nachbedingung]Trigger [Guard] / Aktivität

Transitionen inVerhaltenszustandsautomaten Protokollzustandsautomaten


ZustandsautomatZustandsübergänge

Verschiedenste Möglichkeiten einen Zustandsübergang anzustoßen

listen

closed

[passiv offen]TCB erstellen

[geschlossen]TCB löschen

Ausgangsstellung


Fertigwischen

entry / in Parkpositionbringen

Stufe 1

do / langsam drehen

Stufe 2

do / schnell drehen

Stufe1 gewählt /schalte 1

Stufe2 gewählt /schalte 2

angemeldetPKW neu

PKW gebraucht

do/ benutzen

aktiv standbyafter(60 seconds)


Zustandsautomatzusammengesetzter Zustand

Zustandsnameentry / Aktivitätexit / Aktivitätdo / AktivitätTrigger / AktivitätTrigger / defer

Setzt sich aus Zuständen, Pseudozuständen und Transitionen zusammen

Zustandsnameentry / Aktivitätexit / Aktivitätdo / AktivitätTrigger / AktivitätTrigger / defer

A

B

aktiv

abgebrochen

gedrückt[anykey]

Startort eingegeben

Zielort eingegeben

rück-gängig

Zielgewählt Termin gewählt

rück-gängig

Termingewählt

gedruckt

bestätigt /drucken


ZustandsautomatUnterzustandsautomatenzustand

Steht stellvertretend für einen ZustandsautomatenKann Ein- und Austrittspunkte besitzen

sm Bezahlung

BezahlenBargeld : sm BB

BezahlenGeldkarte : sm BG

[Z_art = GK]

abgebrochen

[Z_art = BG]

abgebrochen

Abbruch

[ok] /abbuchen

[ok] /abbuchen

Abbruch

abwickelnBezahlung : sm Bezahlung

Auswahlbestätigt

/ ausgebenGetränk


ZustandsautomatRegion

Verwendung von Regionen impliziert ParallelitätErreichbar durch Verwendung von:

- Gabelungszuständen, oder- Startzuständen (einer pro Region)

kalt

warm

sprudelnd

still

after(Zeit)

after(Zeit)

Flaschegeöffnet

Temperatur Blubbereffekt

offen

kalt

warm

sprudelnd

still

after(Zeit)

after(Zeit)

Flaschegeöffnet

Temperatur Blubbereffekt

offen


ZustandsautomatPseudozustände I

Startzustand:- Verweist auf den ersten Zustand- Einer pro Region

Entscheidung:- Ausgehende Transition wird während

der Ausführung der Transition bestimmtKreuzung:

- Ausgehende Transition ist vor der Ausführung der Transition bekannt

Ein- und Austrittspunkt:- Zum Betreten und Verlassen von

Unterzustandsautomaten

Startzustand

Entscheidung

Kreuzung

Austrittspunkt

Eintrittspunkt


ZustandsautomatPseudozustände II

Gabelung und Vereinigung:- Teilen eine Transition auf mehrere

parallele Zustände auf bzw. fügen mehrere Transitionen zu einer zusammen

Flache Historie:- Speichert den zuletzt aktiven Unterzustand

eines komplexen ZustandsTiefe Historie:

- Speichert den zuletzt aktiven Unterzustand eines in einem komplexen Zustandenthaltenen Zustand

Terminator: - Bei Erreichen endet die Lebensdauer der Instanz

des beschriebenen Classifiers

Gabelung

Vereinigung

Hflache Historie

H*

tiefe Historie

Terminator


ZustandsautomatBeispiele Pseudozustände

Zustand3

Zustand2

Zustand1

H

Betriebsmodi Autoradio

ausge-schalten

einge-schalten

manuellumschalten

[CD-Kassettedrin]

manuellumgeschaltet

manuellumgeschaltet

[keine Kassettedrin]

[Kassetteausgeworfen]umschalten

Kassetteeingelegt

manuellumgeschaltet[Kassette drin]

getrunken

[ist ok = ja]trinken

[ist ok = nein]wegschütten

probiert TrinkbarkeitgeprüftPrüfung Trinkbarkeit

do / Trinkbarkeit prüfen

A

B C

do / x = 1

Trigger / x = -1*x

[>=0][<0]x

A

B C

do / x = 1

Trigger / x = -1*x

[x>=0][x<0]


ZustandsautomatExplicit und default entry

Default entry:Eine eingehende Transition endet am Rand des zusammengesetzten Zustands.

Explicit entry:Eine eingehende Transition endet an einem Unterzustand des zusammengesetzten Zustands

Adefault entry

B

explicit entry

A

A

explicit entry

B

explicit entry

A Bdefault entry


ZustandsautomatVerlassen von Zuständen

Das Verlassen von zusammengesetzten Zuständen und Zustandsautomaten kann auf verschiedene Arten erfolgen

B

A

ZC

Y

X

Trigger2 [Guard] /Aktivität

Trigger1 [Guard] /Aktivität

sm Authentifizierung

authentifiziert

Pin eingeben /Eingabe# = 0

[Pin =richtig]

[Pin = falsch] /Eingabe#++

Pinunterdrückt

[#<3]

[#>=3] gesperrt

Pincodegeprüft

Fehleingabe

do / Eingabe# prüfen

Pincodeabfrage

do / Pincode prüfen

Authentifizierung : sm Authentifizierung

gesperrt

Pinunterdrückt

[else] / ein-schalten

[Pin unterdrückt] /einschalten


ZustandsautomatVererbung

Spezialisierung von Zustandsautomaten durch- Erweiterung um Regionen, Zustände und Transitionen- Erweiterung von Regionen und Zuständen- Erweiterung von Transitionen

Transaktion nichtbestätigen

sm Geldautomat {extended}

Betrag einlesen {extended}

Betrag eingeben

Betrag wählen

Transaktionbestätigen {final}

anderer Betraggewählt

ok

Karte prüfen{final}

Betrag wählendefekt{final}

Transaktionbestätigen {final}

defekt

Karteangenommen

Betraggewählt

Karte ausgegeben{final}

sm Geldautomat


ZustandsautomatDie wichtigsten Änderungen

UML 1.x UML 2

- Ports können nun Protokollzustandsautomaten besitzen.

- Ein-, Austrittspunkte und Terminatorenwurden eingeführt.

Tiefe Historien können nur eingehende Transitionen von außerhalb des enthaltenden Zustands haben.

Tiefe Historien können auch Ziel einer Transition innerhalb des enthaltenen Zustands sein (also nicht nur von außen).

- Regeln zur Ergänzung und Ersetzung von Transitionen bei vererbten Zustandsautomaten wurde hinzugefügt.

Generalisierung von Zustandsautomaten wird durch eine Notiz kenntlich gemacht.

Das vererbte Verhalten wird mit einem Zustandsautomaten dargestellt.


ZustandsautomatVorsicht: Fehlerteufel

A B C

Nur ein Startzustandpro Region gestattet

Bei Startzuständen nur eineausgehende Transition erlaubt

Ausgehende Transitionin einem Endzustand

sm Fehlerbeispiel

Transition ohne Zielzustand

DTransition ohne Quellzustand

Vereinigung nichtorthogonaler Zustände

nicht möglich


Interaktionsmodellierungmit der UML 2

„Auch in der Kommunikation gilt das Gesetz des abnehmenden Grenznutzens: Immer mehr Aufwand bringt – ab einem gewissen Punkt – immer weniger Erfolg.“

Michael Tost


InteraktionenDefinition und Prinzip

Interaktionen sind ein wichtiges Basiskonzept der UML-VerhaltensdiagrammeInteraktion ist der Nachrichten- und Datenaustausch zwischen zwei KommunikationspartnernGrundelemente der Interaktion:

- Kommunikationspartner (repräsentiert durch Lebenslinien)- Nachrichten

Nachrichtenaustausch verbindet Sende- und Empfangsereignisse Nachricht

Sendeereignis Empfangsereignis

Sender Empfänger


InteraktionenWann modelliere ich Interaktionen im Projekt?

Modellierung von Interaktionen auf verschiedenen Abstraktionsebenen

vielfache Einsatzmöglichkeiten

Lokale oder verteilte Kommunikation

Beschreibung von Use-CasesDetailmodellierung im FeindesignSpezifikation von SchnittstellenTest und Simulation


InteraktionenWelche UML 2 Diagramme gibt es zur Interaktionsmodellierung?



Timing-Diagramm

Sequenz-diagramm



Objektdiagramm

Paketdiagramm


Struktur-diagramme




Diagramme derUML 2

Klassendiagramm



InteraktionenSichten auf Interaktionen

Interaktionsdiagramme zeigen nur Sichten auf InteraktionenDiagrammwahl nach hervorzuhebenden Modellierungsaspekt

:Koch :Herd

Temp_einstellen

:Herd:Koch1: Temp_einstellen

Kommunikationsdiagramm

Sequenzdiagramm

:Koc

h:H

erd

Temp_einstellen

Timing-Diagramm

Lebenslinie

Nachricht


Sequenzdiagramm

„Erst die richtige Reihenfolge macht aus klugen Gedanken ein gutes Ergebnis.“

A. van Rheyn


Sequenzdiagramm

sd Interaktion

Nachricht2

Nachricht1(Argument)

Ok=Nachricht1

Kommunikationspartner

ZeitlicherVerlauf

K1 K2 K3

Lebenslinie

Aktions-sequenz

Nachricht


SequenzdiagrammKontextabgrenzung

sd Waschmaschine

befüllen

Waschmittel_zugeben

Weichspüler_zugeben

Programm_wählen

einschalten

fertig

Wäsche_entnehmen

auschalten

aus

Benutzer

:Waschmaschine

{30...90}

:Stromnetz :Wasserleitung :Kanal

Abwasser

EinheitMinuten Strom

Wasser


SequenzdiagrammBeschreibung von Use-Cases

Waschmaschine

Wäsche waschen

Wäsche trocknen

Hausmann

sd Wäsche waschen

öffnen

Wasser erhitzen(Temperatur=30°)

Hauptwaschgang

schliessen

schleudernpar

abpumpen

abpumpen

einschalten

fertig

:Benutzer :Steuerung :Wasserventil :Heizelement :Motor :Pumpe

«extend»

Benutzer

Steuerung

Wasserventil

Heizelement

Motor

Pumpe

Use-Case-Diagramm

Klassendiagramm

Sequenzdiagramm


SequenzdiagrammDie wichtigsten Elemente im Überblick

sd Bild aufhaengen

schlagen

treffen

loop

alt

treffen

aufhaengen

[Nagelhaelt]

KombiniertesFragment

Nachricht Aktionssequenz

[gerade]

refDaumen verbinden

Interaktions-verweis

Abbruch-bedingung

Zustandsbedingung

:Person :Hammer :Nagel :Daumen :Bild

getroffen =schlagen

Lebenslinie


SequenzdiagrammLebenslinien

Repräsentieren die Teilnehmer einer InteraktionRepräsentieren

- den Classifier selbst,- die Attribute des Classifiers,- Teile des Classifiers, z. B. Ports- die Operationen des Classifiers,- und Parameter von Operationen - (lokale) Variablen einer Operation.

Darstellung der AktionssequenzenStopp löscht die Lebenslinie

sd Internetsuche

Aktions-sequenz

:Internetbrowser :Suchmaschine

suche_starten(Keyword)

suche_starten

aktualisieren

lösche

Bestellung


SequenzdiagrammBeispiele für Lebenslinien

Person

+ berechneAlter(int Geburtsjahr,Datum):Alter

berechneAlter:AlterGeburtsjahr:int Datum

sd berechneAlter(int Geburtsjahr,Datum):AlterOperationsname

kennzeichnetRückgabewert

Setzen desRückgabewerts

Motor

Gaspedal p:Getriebe

beschleunigen

p:Getriebe self

sd

Motor

+ Beschleunigen()

Nachname:String

Vorname[0]:String

Vorname[1]:String

sd Anschrift setzen

Adresse

Person

Nachname:String

Vorname[0]:String

Vorname[1]:String Adresse


SequenzdiagrammZustandsinvariante-/Zustandsbedingung

„Lebenslinie“ muss Bedingung erfüllenWird zur Laufzeit überprüft

:Kunde :Pizzaservice

geöffnet

sd Pizzabestellung

bestellen

bestellen

Zustandsbedingung fürLebenslinie „Pizzaservice“


SequenzdiagrammNachrichten

Beschreiben den Informationsfluss zwischen den Kommunikationspartnern

Synchrone Nachrichten(Sender wartet auf Antwort)Asynchrone Nachrichten(Antwort wird nicht erwartet)Abgebildet durch Pfeil und PfeilspitzeLost und Found Nachrichten:

N1N3

N2

N4

Antwortnachricht

Synchrone Nachricht

Asynchrone Nachricht

A B C

Found NachrichtLost Nachricht


SequenzdiagrammKombinierte Fragmente

Teil einer InteraktionMit bestimmten Regeln für

- Auswahl - Reihenfolge- Häufigkeit

der Nachrichten

:A :B

alt

[x == 1]

[else]

m

n

trenntOperanden

kombiniertesInteraktionsfragment

Interaktionsbedingung

Interaktionsoperator

Interaktions-operand}



Alternativ (alt):- Existenz von mehr als

einer Ablaufmöglichkeit- Bedingungen geben den

Ablauf vor- Immer 2 Operanden

Modellierung von - If-else-Bedingungen- Switch/case -

Anweisungen

[Partygast.Hungergefühl>normal]

[else]

alt

sd Nahrung aufnehmen

pluendern

aufessen

:Partygast :Buffet :Snacks

[Partygast.Hungergefühl== normal]

weiterfeiern



sd Interaktion ignore {N3, N4}

A B C

N1

N2

N5

sd Interaktion consider {N3, N4}

A B C

N1

N3

N4

Ignore (ignore)- Blendet Nachrichten aus,

die für die Modellierung irrelevant sind

- Im realen System können diese jedoch vorkommen

Consider (consider)- Nur die genannten

Nachrichten sind relevant- Betont Intention des

Modellierers



sd Spiel ignore {ziehen}

opt[keine Figur im

Feld]

loop (1,3) [Augenzahl!=6]

opt [Augenzahl==6]

loop [Augenzahl==6]wuerfeln

wuerfeln

wuerfeln

wuerfeln

:Spieler :WürfelOption (opt):- Interaktion, die nur unter

bestimmten Bedingungen durchgeführt wird

- If(...) then { ... }

Loop (loop)- Abbildung von Schleifen- Zählschleife:

loop(min, max)- Abbruch/Ausführung durch

[Bedingungen] steuerbar



sd Party verlassen

verabschieden

assert

weggehen

:Partygast :Gastgeber

sd trinken

neg

austrinken

austrinken

:Glas:PartygastNegative (neg)

- Hebt ungültige Folgen von Einzelschritten hervor

- Zur Betonung gedacht- Modellierung von

negativen (Test-)fällen

Assertion (assert)- Legt eine bestimmte

Reihenfolge fest- Zur Betonung gedacht



sd Unfallaufnahme

Patient Aufnahme OP

par aufnehmenoperieren

aufnehmenverlegen

aufnehmen(Herzinfarkt) operieren

Station

criticalaufnehmen(Herzinfarkt)

:Patient :Aufnahme :OP :Station

Parallel (par)- Mehrere Abläufe

sollen gleichzeitig ablaufen

- „Threading“

Critical Region (critical)- Festlegen eines

ununterbrechbaren, statischen Ablaufs


SequenzdiagrammKombinierte Fragmente - Coregion

Alternativdarstellung zum parallel kombinierten FragmentAber nur wenn nur eine Lebenslinie betroffen istAblaufreihenfolge innerhalb der Coregion ist beliebig

sd Tankstopp

tanken(Benzin)

Scheiben putzen

Öl kontollieren

bezahlen

:Person :Auto :Kasse



Break (break)- Unterberechen

des normalen Ablaufs

Zur Modellierung von- Exceptions- Systemfehlern- Kritischen

asynchronen Ereignissen

Fahrer

sd Drogenfahndung

Polizist Auto

anhalten

durchsuchen

Ergebnis

break [Ergebnis == Drogen gefunden]verhaften

weiterfahren

:Fahrer :Polizist :Auto


SequenzdiagrammNotationselemente - Interaktionsverweis

sd

X Y Zref C

Aref

Bref

sd A

X Y Zsd B

Y Z

Cref

Referenziert (ref) auf eine beliebige InteraktionWiederverwendung in mehreren Diagram-men möglich„Zooming“ – GedankeAuch für Lebenslinien möglich


SequenzdiagrammModellierung von Zeitangaben

X Y

a

c

b

t=now

t=now

t..t+5

{12.00..12.05}

Zeiteinheit für t ist ms

Einheit Uhr

X Y

Zeitpunkte beschreiben, wann ein Ereignis eintritt

Zeitdauer beschreibt,Die Dauer von Nachrichten oder Aktionssequenzen

X Y

a {2..10}

b

b {5..5}

Hilfslinien

c ÜZeit=duration

d {0..0,5*ÜZeit}

Zeitdauer-bedingung

Zeitdauer-beobachtungsaktion

X Y

ZeiteinheitSekunden


SequenzdiagrammDie wichtigsten Änderungen

UML 1.x UML 2

Zerlegung von Lebenslinie nicht möglich, Referenzen von anderen Interaktionen nicht möglich

Innerhalb von Sequenzdiagrammen kann auf andere Interaktionen verwiesen werden (Zerlegung von Abläufen oder Lebenslinien)

Kontrollflussmöglichkeiten äußerst bescheiden: Schleifen und Nachrichtenbedingungen möglich

Alle Kontrollflussmöglichkeiten (if, switch, ...) höherer Programmiersprachen durch kombinierte Fragmente, sehr gute Unterstützung von nebenläufiger Modellierung

Nachrichtenarten:asynchron, synchron, unspezifiziert

unspezifiziert entfällt, lost und found Nachrichten eingeführt

Zustandsinvarianten können an Lebenslinien angetragen werden


Kommunikationsdiagramm

„Auch das Chaos gruppiert sich um einen festen Punkt, sonst wäre es nicht einmal als Chaos da.“

Arthur Schnitzler


KommunikationsdiagrammDie Elemente im Überblick

Notationselemente:- Interaktion- Lebenslinien- Nachrichten- Sequenzbezeichner

cd Gassi gehen

Hundehalter Hund

Passant Häufchen

1:Gassi gehen

1.1:machen

2:reintreten

3:entfernen

2.1:schimpfen

Name der Interaktion

Sequenzbezeichner

Nachrichtenname

Richtung derNachricht

Lebenslinie


KommunikationsdiagrammAnwendung im Projekt

Gehört zu den InteraktionsdiagrammenZeigt das Zusammenspiel von strukturiertenKommunikationspartnern. Kontrollflüsse und zeitliche Aspekte sind weniger wichtigGut geeignet für die Modellierung von Prinzipien und Konzepten

Wenig Änderungen zur UML 1.x Version, dem Kollaborationsdiagramm


KommunikationsdiagrammNachricht - Sequenzbezeichner

Definiert für Nachrichten- Reihenfolge- Ebene

der Abarbeitung

Reihenfolge wird durch Zahlen spezifiziert

Ausführungsbedingung in eckigen Klammern

cd Restaurantbesuch

Gast

Getraenk Essen

Rechnung

1a:bestellen

2a: [Glas voll]trinken

1b:bestellen

2b*[Teller voll]:essen

1:hinzufuegen 1:hinzufuegen

4:bezahlen(Betrag)

3:berechnen(Betrag)


KommunikationsdiagrammNebenläufigkeit und Schleifen

Nebenläufigkeit durch Buchstaben im Sequenzbezeichner

Definition von Schleifen mit einem Stern „*“

Kennzeichnung von nebenläufigen Schleifen-durchläufen mit Doppelstrich „||“

cd Reparaturauftrag

Besitzer Auftragsannahme Mechaniker

Lager

Ersatzteil

Mietwagen

1a:beauftragen 1a.1:Auftrag

1a.1.1b*||[alle Ersatzteile vorhanden]:Ersatzteil beschaffen

1a.1.1c:[Ersatzteil nicht vorhanden]:bestellen

1a.1.1.1:erledigt1b:ausleihen

Auto

1a.1.1a:reparieren

2:fahren


KommunikationsdiagrammDie wichtigsten Änderungen

UML 1.x UML 2Kollaborationsdiagramm Kommunikationsdiagramm

Vollständig äquivalent zum Sequenzdiagramm

Subset des Sequenzdiagramms, z. B. - keine Interaktionsverweise („ref“)- keine kombinierten Fragmente- Ereignisreihenfolge wird ignoriert


Timing-Diagramm

„Die Neugier steht immer an erster Stelle eines Problems, das gelöst werden will.“

Galileo Galilei


Timing-DiagrammDie Elemente im Überblick

td Fußgängerampel

rot

betriebsbereit

:Am

pel

Lebenslinien

d

Zeit-Bedingung

Zustandslinie

:Fuß

gäng

ergrün

wartend

aktiv

{d...6*d}

ZustandZeitskala

Name desDiagramms

aktivieren

gehen nichtgehen

Nachricht

Sek.0 10 3020


Timing-DiagrammAnwendung im Projekt

Gehört zu den InteraktionsdiagrammenDarstellung des zeitlichen Veränderung eines Classifiers (Klasse, Objekt, Komponente, ...)Für die Modellierung zeitkritischer Zustands- und Wertänderungen sinnvoll

Neu in der UML 2!Bereits seit Jahren in Elektrotechnik genutzt (z. B. für elektronische Schaltvorgänge)


Timing-DiagrammElemente – Lebenslinie - Zustandslinie

Nur eine Lebenslinie oder kommunizierende Lebenslinien möglich

Meist nur Sicht auf wenige Zustände der auf Lebenslinie

Zustandslinien beschreiben den Wechsel der Zustände im Ablauf der Zeit

Zustand

td Fahrstuhltür

offen

:Fah

rstu

hltü

r:L

icht

schr

anke

nsys

tem

unterbrochen

nichtunterbrochen

beimschliessen

beim öffnen

0 2 sek

Zeitliche Verzögerung desZustandsüberganges

Zustandslinie


Timing-DiagrammElemente - Nachrichten

Nachrichten werden zwischen den Zustandslinien ausgetauschtBewirken häufig einen Zustandswechsel

td Autoradio

aktiv

inaktiv:Ver

kehr

sfun

k:M

usik

send

er leise

laut

EndeAnfangNachricht


Timing-DiagrammGeneral-Value-Lifeline

Alternative Darstellungsform

td Waschstraße

:Waschstraße

:Kunde

betriebsbereit Vorreinigung Hauptwäsche Trocknen betriebsbereit

aktivwartenaktiv

{5a} {2a..6,5a} {4a}

a


Timing-DiagrammVorsicht: Fehler die vermieden werden sollten

fehlendeLebenslinienbeschriftung

td Schweinebraten zubereiten

zubereitet

roh

:Sch

wei

nebr

aten

aktiv

warten

Empfangsereignis vorSendeereignis

Lücke in derZustandszeitlinie

fehlendeZustandsbeschriftung


Interaktionsübersichtsdiagramm

„Wer auf morgen wartet, wird übermorgen erkennen, dass er heute versäumt hat das Notwendigste zu tun.“

Walter Scheffel


Interaktionsübersichtsdiagrammiod Betriebsfeier

sd

:Chef :Angestellter

organisiereFeier

[Keine Hemmschwelle]

sd

:Chef :Personalchef

mitarbeiterfeuern

sd

:Chef :Mitarbeiter

bedanken

Verpflegung_organisieren

ref

Mitarbeiter_verständigen

ref

Mitarbeiter.Hemmschwelle=Feier:Alkoholkonsum

ref


InteraktionsübersichtAnwendung im Projekt

Darstellung der Ablaufreihenfolge mehrerer InteraktionenBesonders geeignet für:

- Brückenschlag zwischen Aktivitäts- und Interaktionsdiagrammen

- Logischen Zusammenhang zwischen mehreren Interaktionsdiagrammen schaffen

Ablauf wird durch Kontrollelemente aus dem Aktivitätsdiagramm dargestellt

Neu in der UML 2!


Fazit ---dynamische Diagramme in UML 2

Viel neu - viel geklautAktivitätsdiagramme und Sequenzdiagramme faktisch neuVerbesserte Unterstützung der CodeabbildungBessere Modellierung von Nebenläufigkeiten und Zeitverhalten möglich dennoch keine „Echtzeitsprache“Deutlich bessere Schnittstelle zu StrukturdiagrammenNotationsvielfalt erfordert TailoringInteraktionsübersichtsdiagramm, Timingdiagramm erfordern Nachbesserungen


Damit Sie klar sehen!

Infos:•www.uml-glasklar.de•www.jeckle.de•www.sophist.de


Modelle der Realität erstellen

Infos unter www.SOPHIST.de Wir erkennen die Struktur Ihrer Projektanforderungen!

UML 2 Tutorial - mario-jeckle.de · DV-Anforderungen DV-Architektur ... Struktur und Einbettung von...

Documents

Transcript of UML 2 Tutorial - mario-jeckle.de · DV-Anforderungen DV-Architektur ... Struktur und Einbettung von...