Einführung in die Unified Modeling Language · se Programmentwicklung, Vorlesungsskript UML...

Einführung in die Unified Modeling

Language

Rainer Schmidbergerrainer.schmidberger@informatik.uni-stuttgart.de

WS 2008/09

Folie 2

UML (1)The Unified Modeling Language is a visual languagefor specifying, constructing, and documenting theartifacts of systems. It is a general-purpose modelinglanguage [...] that can be applied to all applicationdomains (e.g., health, finance, telecom, aerospace) and implementation platforms [www.uml.org].Die Unified Modeling Language (UML) ist eine von der Object Management Group (OMG) entwickelte und standardisierte Sprache für die Modellierung von Software und anderen Systemen [de.wikipedia.org].Aktuelle Version: 2.1

Folie 3

UML (2)Wurde entscheidend durch Grady Booch, Ivar Jacobson und James Rumbaugh geprägt. Hat die vor 1996 existierenden verschiedenen Modellierungsmethoden (der genannten drei, sowie anderer) abgelöstWird zur Prozessmodellierung, Analyse, Spezifikation und zum Systementwurf verwendetEs sind sehr viele gute Werkzeuge zur UML auf dem MarktBietet sehr konkreten Übergang zur Implementierung. Code-Generierung ist aus den Modellen heraus in vielen Teilen möglichIn Zukunft: MDA, MDD und Executable UML?

Folie 4

Die drei „Amigos“Ivar Jacobson

GradyBooch

James Rumbaugh

Folie 5

Geschichte der UML

Quelle: Mario Jeckle, 2003

Folie 6

„Entstehung“ der UML

Quelle: www.ibm.com

Kurzübersicht über die UML-Diagramme

Folie 8

Diagramm Übersicht

UML Diagramme

Struktur-diagramme

Verhaltens-diagramme

Interaktions-diagramme

Klassend. Objektd. Komponentend.

Kompositions-strukturd.

Verteilungsd. Paketd.

Use Case-D. Aktivitätsd. Zustandsd.

Sequenzd. Kommunikationsd.

Zeitdiagramm Interaktions-übersichtsd.

Neu in UML 2.0

Folie 9

Diagramm Übersicht (engl.)

Quelle: www.uml.org, 2006

Folie 10

StrukturdiagrammeKlassendiagramm (class diagram)

Modellierung der Klassen mit Methoden, Attributen und Beziehungen

Paketdiagramm (paket diagram)Modellierung der logische Struktur der Modellelemente mit deren (z.T. abstrakten) Abhängigkeiten

Objektdiagramm (object diagram)Modellierung von „Momentaufnahmen“ konkreter Objekte mit Werten und Beziehungsausprägungen

Kompositionsstrukturdiagramm (composite structurediagram)

Modellierung der internen Struktur eines Modell-elements (Classifiers) sowie dessen Möglichkeiten zu Interaktion mit anderen Systemkomponenten

Komponentendiagramm (component diagram)Modellierung der Komponenten (=Module) und deren Abhängigkeiten

Verteilungsdiagramm (deployment diagram)Zeigt die (physischen) Geräte des Systems im Betrieb

Folie 11

VerhaltensdiagrammeUse-Case Diagramm (use case diagram)

Modellierung der Anwendungsfunktionalität aus der Sicht der Anwender

Aktivitätsdiagramm (activity diagram)Modellierung des dynamischen Ablaufs (i.d.R. eines Use Case)

Zustandsdiagramm (state transition diagram)Modelliert die Zustände und Zustandswechsel (i.d.R. zu einer Klasse)

Sequenzdiagramm (sequence diagram)Modelliert ein Szenario: den Botschaftsfluss zwischen Objekten

Kommunikationsdiagramm (comunicationdiagram)

Dynamik wie Sequenzdiagramm; zusätzlich Objekteigenschaften

Timing-Diagramm Präziser zeitlicher Verlauf

InteraktionsübersichtsdiagrammModellierung des Zusammenspiels einzelner Interaktionsdiagramme

Folie 12

Diagramm Übersicht

UML Diagramme

Struktur-Diagramme

Verhaltens-Diagramme

Interaktions-Diagramme

Klassen-D. Objekt- D. Komponenten-D.

Kompositions-struktur-D.

Verteilungs-D. Paket-D.

Use Case-D. Aktivitäts-D. Zustands-D.

Sequenz- D. Kommunikations- D.

Zeit-D. Interaktions-Übersichts-D.

Folie 13

Personname : Stringvorname : String

belasten(betrag : Waehrungsbetrag)

KreditkartebetreibernrkontrollNrAblaufdatum

istGueltig()belasten(betrag : waehrungsbetrag)

1 +karteninhaber

Bestellvorgang

start()

Fahrkartestartpunktzielpunktwegstreckerabatt

bestellen()stornieren()

10..* 1

+fahrgast

KlassendiagrammModellierung der Klassen mit Methoden, Attributen und BeziehungenÄhnlich dem ER-Diagramm

Attribute

Beziehung

Multiplizität

Sicht-barkeit

Methoden

Folie 14

PaketdiagrammPakete dienen als „Container“ für beliebige UML ModellelementeDas Paketdiagramm zeigt (abstrakte) Beziehungen zwischen einzelnen Paketen

GUI Klassen Businesslogic Klassen

Datenbankzugriffe

Ein Paket kann selber wieder Pakete oder andere Modellelemente wie z.B. Klassen enthalten

BerechnungslogikRechnung

Modellsicht:

Folie 15

ObjektdiagrammZeigt eine Momentaufnahme des SystemsDem Klassendiagramm sehr ähnlich: statt der (abstrakten) Klassen werden (konkrete) Objekte dargestelltObjektname ist in der Regel eine Rolle, in der ein Objekt agiertAttributwerte können auch angezeigt werden

Objektname : Klassenname

fluggast: Person

: Kreditkarte

name : String = „Duck“vorname : String = „Donald“

betreiber : String = „Visa“Nr : String = „1234567“

bezahltMit

Folie 16

Kompositions-Struktur-DiagrammAb UML 2.0, Composite Structure„Kontext“-bezogenes Klassen-, Objekt oder KomponentendiagrammZeigt eine „Ausprägung“ oder eine bestimmte Konfiguration

fahrgast : Person

: Kreditkarte

Abrechnung Kollaborationstyp

Folie 17

Komponenten DiagrammModelliert die Software-Architektur mit Bibliotheken, Komponenten, Datenbanken, usw.

Abhängigkeiten

Komponente

<<Component>>

GUISteuerung

<<Component>>

Verbindungsrechner

<<Component>>

Fahrplandatenbank

Anschlüsse

<<Component>>

BenutzerGUI

Verbindungen

Konnektor

InterfacePort

Folie 18

VerteilungsdiagrammDeployment diagramModelliert die Abbildung auf das physische Ziel-System (die Geräte) wie Server, Clients, externe Geräte, usw.Beschreibende Artefakte können ebenso mit aufgenommen werden

Application-ServerBrowser<<HTTP>>

Datenbank<<JDBC>>

Folie 19

Diagramm Übersicht

UML Diagramme

Struktur-Diagramme

Verhaltens-Diagramme

Interaktions-Diagramme

Klassen-D. Objekt- D. Komponenten-D.

Kompositions-struktur-D.

Verteilungs-D. Paket-D.

Use Case-D. Aktivitäts-D. Zustands-D.

Sequenz- D. Kommunikations- D.

Zeit-D. Interaktions-Übersichts-D.

Folie 20

Verbindungen abfragen

Fahrgast

Fahrkarten bestellen

Use CaseModellierung der Anwendungsfunktionalität aus der Sicht der AnwenderGeschäftsprozesseSehr einfache Diagramme

Akteur: Nutzer des Systems Use Case

Beziehung: der Akteur benutzt einen Use Case

System

Folie 21

Verbindungsstart eingeben

Verbindungsziel eingeben

Eingaben sind gültig

Weg berechnen Mind. eine Verbindung

wurde gefunden

Fehlerseite Verbindungen anzeigen

neinja

AktivitätsdiagrammBeschreibt den Ablauf eines Use CaseIst auch für parallele Abläufe geeignet

Aktivität

Entscheidung

Folie 22

ungültig

gültig

erfolgreiche Belastung eines Fahrgastkontos

storno

ZustandsdiagrammModelliert die Zustände und Zustandsübergänge einer Klasse oder einer KomponenteDen Zustandsübergängen können Ereignisse und Aktionen zugeordnet werden

ZustandEnde

Beginn

Transition

Folie 23

SequenzdiagrammBotschaftsfluss zwischen Objekten

: Fahrkarte kunde: Person : Kreditkarte

bestellen()berechnePreis()

belasten(betrag)istGueltig()

belasten(betrag)

Fahrkarte bestellen

Folie 24

: Fahrgast : Bestellvorgang

: Fahrkarte

: Person

: Kreditkarte

1: start( ) 2: bestellen( )

3: berechnePreis( )

4: belasten(Waehrungsbetrag)

5: istGueltig( )6: belasten(waehrungsbetrag)

KommunikationsdiagrammÄhnlicher Inhalt wie beim SequenzdiagrammBei vielen Objekten mit wenig Botschaftsfluss geeignet

Botschaft

Beteiligtes Objekt

Reihenfolge

Folie 25

Timing diagramAb UML 2.0Zeigt das Verhalten von Objekten mit genauer Zeitachse.Speziell für Hardware dominierte oder RealtimeSoftware.

Quelle: www.oose.de, www.sparxsystems.com.au

Folie 26

InteraktionsübersichtAb UML 2.0Zeigt den Zusammenhang zwischen einzelnen Interaktionsdiagrammen aufElemente wie im Aktivitätendiagramm

Folie 27

UML – Diagramm LayoutHeader

Syntax:• [<DiagrammTyp>]<DiagrammName>[<Parameter>]

DiagrammTyp (Kürzel) - optional• cd, sd, uc, ...

DiagrammNameParameter – optional

• wird nur selten benutzt

InhaltGraphisches Diagramm des angegebenen Typs

AnmerkungDie Diagramm-Darstellung wird letztendlich vom Werkzeug festgelegt

Header

Inhalt

Folie 28

UML Werkzeuge: Rational Rosewww.ibm.com/software/rational

Folie 29

UML Werkzeuge: Argo UMLwww.argouml.org

Folie 30

UML Werkzeuge: Rational XDEwww.ibm.com/software/rational

Folie 31

UML Werkzeuge: Enterprise Architecthttp://www.sparxsystems.com/

Folie 32

UML Werkzeuge: Borland Togetherwww.borland.com/de/products/together/index.html

Folie 33

UML Werkzeuge: Visual Paradigmhttp://www.visual-paradigm.com/

Folie 34

UML im ProjektverlaufEn

Quelle: Rational Software

Klassendiagramm(Domänenmodell)

Aktivitätend.Klassendiagramm

(techn. Modell)

Sequenzd.

Komponentend. Zustandsd.

Verteilungsd.

Use Case D.

Folie 35

UML LiteraturRumbaugh, James; Jacobson, Ivar; Booch, Grady : „Theunified modeling language reference manual“, Second Edition, Addison-Wesley, 2004

Jeckle, Mario; et al. : „UML2 glasklar“, Hanser Verlag, 2004

Folie 36

UML LiteraturMartin Fowler: „UML Distilled. A Brief Guide to the Standard Object Modeling Languange“, Addison-Wesley, 2003

Kendall Scott : „UML Explained “, Addison-Wesley, 2001

Folie 37

UML Spezifikation (1)Erhältlich über www.uml.orgGliedert sich in zwei Dokumente:

Infrastucture (http://www.omg.org/docs/formal/05-07-05.pdf)Definition der grundlegenden Sprachelemente.Superstructure (http://www.omg.org/docs/formal/05-07-04.pdf)Definition der Diagrammtypen

Überwiegend in UML Klassendiagrammen und OCL (ObjectConstraint Language) spezifiziert.

Folie 38

UML Superstructure: Class

Folie 39

UML Spezifikation: Classifier

Class(from Kernel)

DataType(from Kernel)

Enumeration(from Kernel)

Classifier(from Dependencies)

Signal(from Communications)

AssociationClass(from AssociationClasses)

Class(from Communications)

Collaboration(from Collaborations)

Behavior(from BasicBehaviors)

Classifier(from Collaborations)

PrimitiveType(from Kernel)

Classifier(from PowerTypes)

Artifact(from Artifacts)

Actor(from UseCases)

Classifier(from Kernel)

InformationItem(from InformationFlows)

EncapsulatedClassifier(from Ports)

Node(from Nodes)

Device(from Nodes)

Class(from StructuredClasses)

ExecutionEnvironment(from Nodes)

CommunicationPath(from Nodes)

Interaction(from BasicInteractions)

StateMachine(from BehaviorStateMachines)

BehavioredClassifier(from BasicBehaviors)

ProtocolStateMachine(from ProtocolStateMachines)

Classifier(from Templates)

BehavioredClassifier(from Interfaces)

Interface(from Communications)

Interface(from Interfaces)

Component(from BasicComponents)

Component(from PackagingComponents)

Classifier(from UseCases)

UseCase(from UseCases)

Association(from Kernel)

StructuredClassifier(from InternalStructures)

Activity(from BasicActivities)

Activity(from FundamentalActivities)

Activity(from CompleteActivities)

Behavior(from CompleteActivities)

Activity(from StructuredActivities)

OpaqueBehavior(from BasicBehaviors)

Class and its increments

Folie 40

UML SpracharchitekturMeta-MetamodellDefiniert als UML Infrastructure

M3Class

MetamodellDefiniert als UML Superstructure

M2Attribute Class Association

ModellDomänenmodell in UML

M1Person Firma

BezeichnungNameVornameGehalt

<<instanceof> <<instanceof> <<instanceof>

<<instanceof> <<instanceof>

Objekte der Applikation

Meta Object Facility, MOF

<<instanceof> <<instanceof> <<instanceof>

Folie 41

Anmerkungen zur UMLIn der Praxis werden die verschiedenen Diagramme unterschiedlich stark eingesetztWerkzeuge spielen eine wichtige RolleNicht alle Werkzeuge unterstützen die UML 2.0 Praktisch niemand kennt und nutzt die UML vollständig

Use Cases

Folie 43

Nutzen von Use Cases

Quelle: Alan Chapman

Formalisierung und Beschreibung der funktionalen Anforderungen

Folie 44

Definition"A use case is a piece of functionality in the system that gives a user a result of value"

"All the use cases together make up the use casemodel, which describes the complete functionality of the system"

"A use case specifies a sequence of actions, including variants, that the system can perform and that yields an observable result of value to a particular actor"

Aus "The Unified Software Development Process", Ivar Jacobson u.a., Addison-Wesley, 1999

Folie 45

Use Case (1)Ein Use Case

beschreibt mehrere zusammenhängendende Aktivitäten, die von einem oder mehreren Akteuren durchgeführt (genutzt) werden, um ein Ziel zu erreichen bzw. ein gewünschtes Ergebnis zu erstellen

Fahrgast

Fahrkarten bestellen

Akteur: Nutzer des Systems Use Case

Beziehung: der Akteur benutzt einen Use Case

System

Fahrscheinsystem

Folie 46

Use Case (2)

Use Cases beschreiben aus Anwendersicht den SystemnutzenEinfaches Kommunikationsmedium mit "Stakeholdern" (Anwendern, Kunden, Management, ...)Die Gesamtmenge der Use Cases beschreibt das System, das an der Systemschnittstelle beobachtetwerden kann.Abgrenzung zur Aktivität: ein Use Case umfasst viele Aktivitäten

Folie 47

Use Case (3)

Bezeichnung durch Substantiv + Verb (Infinitiv) z.B. Einstellung durchführenPrämie berechnen, usw.

(Geschäfts-)Prozesse können als Use Case modelliert werdenSystemgrenzen werden festgelegtSystemnutzer (=Akteure) werden festgelegtEinsatzmöglichkeiten: Ist-Analyse, Soll-Analyse und SpezifikationAchtung: ein Use Case ist kein Softwaremodul!Strukturierung der funktionalen Anforderungen

Folie 48

Use-Case-Diagramm

dient der Visualisierung und als Übersicht über die vorhandenen Use Cases und Akteureenthält die Beziehungen zwischen Akteuren und UseCasesTipp: mehrere Use-Case-Diagramme erstellen!

Jedes Use-Case-Diagramm sollte einen wichtigen Aspekt des Systems wiederspiegeln!

Folie 49

Akteure

Akteure sindRollen (Personen oder Systeme, z.B. Benutzer, Rechner, externe Datenbanken, auch Ereignisse oder Termine)

Akteure werden im Begriffslexikon beschriebenAkteure werden im Use-Case-Diagramm eingezeichnetAkteure werden im Diagramm durch Assoziationen mit den Use Casesverbunden, an denen sie beteiligt sind

selbst nicht Teil des zu beschreibenden Systems,direkt mit einem oder mehreren Use Cases verbunden und kommunizieren mit diesemin der Regel aktiv, das heißt sie können Vorgänge anstoßenAchtung: es werden nur die Akteure mit einem Use Caseverbunden, die an der Interaktion mit dem System selbst teilnehmen!

MA Verwaltung

Folie 50

Include-Beziehung

Use Case A fügt Use Case B an einer gekennzeichneten Stelle einUse Case B kennt Use Case A nichtMehrfach vorkommende Use-Case-Abschnittewerden nur einmal beschriebenTipp: man sollte diese Dekomposition nicht übertreiben! Jeder Use Case soll erkennbaren Nutzen behalten.

Use Case A

Use Case B

<<include>>

Use Case A fügt an einer bestimmten Stelle Use Case B ein

Folie 51

Extend und GeneralisierungEs gibt weitere Beziehungen, die vorsichtig verwendet

werden sollten:

extend-Beziehung: B erweitert A an einer dort festgelegten StelleGeneralisierungsbeziehung: B ist eine spezielle Ausprägung von ABeispiele:

Fremdwährung abheben

Geld abheben

<<extend>>

Auslandsstudent Immatrikulieren

Student Immatrukulieren

<<extend>>

Benutzer validieren

Kennwort prüfen Biometriemerkmale prüfen

Achtung: die Semantik beider Beziehungen ist nicht scharf spezifiziert!

Folie 52

Beispiel: Bankomat

Bankkunde

Geld abheben

Kontostand abfragen

Legitimierung prüfen<<include>>

<<include>>

Fremdwährung abheben

<<extend>>

Folie 53

Beispiel: Seminarbuchungssystem

Eigene Bildungshistorie anzeigen

Registrierung via Group Directory, HR-Online

Produkt suchen

Produktdaten anzeigen

Katalogfunktionen

Surfer

Mitarbeiter

Selbst-Buchung

Termin buchen Auf anderen Termin UmbuchenBuchung stornieren

Ersatzteilnehmer buchenMitarbeiter buchen

Reports zu MA-Buchungen anzeigen

Vorgesetzter

Kann soviel wie...

Sowohl das Produkt, als auch der MA muss hierfür freigegeben sein

<<include>>

uc: Seminarbuchungss.

Folie 54

Use-Case-Beschreibung (1)Beschreibung erfolgt

in verständlicher Sprachemit konkretem Nutzen für den initiierenden Akteurpräzise und eindeutigmit überprüfbaren Ergebnissenmit definierten Begriffen (Begriffslexikon)semi-formal (strukturiert)einheitlich

Use Case Dokumentation

Name: Seminar buchenAkteure: Kunde

Vorbedingung:Seminar ist freigegeben und hat noch ausreichend Plätze frei

Regulärer Ablauf:Der Kunde selektiert ein Seminar und ...

Nachbedingung:Der Kunde ist auf das entsprechende Seminar gebucht

Alternative Abläufe:- das Seminar ist ausgebucht- der Kunde hat keine Buchungsberechtigung

Folie 55

Use-Case-Beschreibung (2)Name des Use CaseBeteiligte AkteureVorbedingung

Voraussetzungen vor der Ausführung des Use CaseRegulärer Ablauf

Beschreibung einzelner Aktionen innerhalb des Use Case in Form verbaler Szenarien (Einzelaktivitäten)Evtl. Diagramme und EntscheidungstabellenBegriffe sorgfältig verwenden (Begriffslexikon)

NachbedingungZusicherungen, die nach Use-Case-Ende eintreffen müssen

Alternative AbläufeFehlerfälleSonderfälle

Folie 56

Use Case Beschreibung (3)Name des Use Case

Personalausweis beantragenVorbedingung

Antragsteller hat sich legitimiert und entsprechende Aktion angstoßen. Es handelt sich nicht um einen Erstantrag

Regulärer AblaufBerechtigungen des Antragstellers werden geprüft (Siehe Verordnung XY)Zuständiges Amt wird über die Wohnsitzangaben ermittelt. Für Wohnsitzlose gilt Sonderregelung 4711.Gebührenrechnung wird erstellt. Abwicklung abhängig vom Antragsteller über Kreditkarte oder Bankeinzug Zusammenstellen des Antragpakets und weiterleiten an Stelle 0815

NachbedingungDer Antragsteller hat jetzt den Status "beantragt", weitere Anträge können solange nicht entgegengenommen werden

Alternative AbläufeErstanträge werden über use Case ABC behandelt

Folie 57

Verbindungsstart eingeben

Verbindungsziel eingeben

Eingaben sind gültig

Weg berechnen Mind. eine Verbindung

wurde gefunden

Fehlerseite Verbindungen anzeigen

neinja

Beschreibung durch AktivitätsdiagrammBeschreibt (grafisch) den Ablauf eines Use Case

Aktivität

Entscheidung

Folie 58

Beschreibung durch Sequenzdiagramm

: Fahrgast : Bestellsystem

: Reservierungssystem

: Abrechnungssystem

1: buchung( )

2: reservieren( ) 3: berechnen( )

Beschreibt (grafisch) die beteiligten Instanzen und den zeitlichen Ablauf eines Use Case

Folie 59

Vor- und NachteileVorteile

Einfache Darstellung, leicht verständlichUse Cases sind innerhalb der UML klar beschriebenEs sind (sehr gute) Werkzeuge verfügbarErweiterungsmöglichkeit um Aktivitätsdiagramme und SequenzdiagrammeGreifen den verbreiteten Prozess-Gedanken auf

NachteileBeschreibung ist nicht formalisiertKonsistenzen sind automatisch nicht prüfbarÜbergang zur Modellierung der fachlichen Klassen ist brüchig

Folie 60

Business Use CaseBusiness Use Case

Beschreibung der Fachlichkeit ohne Berücksichtigung, welche Teile des Prozesses mit IT-gestützt ablaufen und welche nichtUnterscheidung „manuell“ oder „IT-gestützt“ über den <<stereotyp>>

Use CaseEingrenzung auf die IT-gestützten Prozesse

Bei e-Commerce-Systemen entsprechen die Business Use Cases den Use Cases

Seminar durchführen

Namenskärtchen verteilen

<<include>>

Klassen-Diagramme

Folie 62

UML Klassen (1)Die Darstellung von Klassen erfolgt als Rechteck mit den Bereichen

KlassennameAttributlisteMethodenliste

Person

Attribute

Methoden

Folie 63

UML Klassen (2)Klassenname mit stereotype AngabeAttribute mit Datentypen und Sichtbarkeiten und VorbelegungenMethoden mit Signaturen und SichtbarkeitenSichtbarkeiten:

public (+)protected (#)private (-)

Die Datentypen sind von der verwendeten Programmiersprache abhängig!

<<entity>>Person

-name : String-vorname : String-gehalt:GeldBetrag

+setGehalt(g:GeldBetrag)+getGehalt() : GeldBetrag+updateGehalt()

Folie 64

AttributeBerechnetes Attribut (Derived). Berechnungsformel ist nicht Teil des UML-ModellsKlassenattribut: Attribut steht allen Objekten der Klasse Person nur einmal zur Verfügung

Person

-name-vorname#gehaltsgruppe : int = 0+/gehaltanzahlPersonen : int

Folie 65

MethodenSignaturen werden oft nicht angegebenPrivate Methoden werden oft nicht angegebenKlassenmethode (Aufruf über Klassenbezeichner, unterstrichen)Abstrakte Methode (wird kursiv gedruckt), erzwingt Implementierung in den Kindklassen

Person

+setGehalt(g:GeldBetrag)+getGehalt() : GeldBetrag+getAnzahlPersonen() : int+updateGehalt()

Folie 66

Assoziationen"Beziehungen", "Verbindungen" oder "Navigationspfade" zwischen Klassen werden als Assoziation bezeichnetVerbindungen zwischen Objekten werden als Link bezeichnetIn der UML werden Assoziationen sehr differenziert beschriebenAssoziationen sind logische Beziehungen, sie müssen nicht notwendigerweise durch ein Programmkonstrukt direkt im Code implementiert sein

Folie 67

Assoziationen

Person Firma0..1

Arbeitnehmer

Arbeitgeber

Firma in der Rolle als "Arbeitgeber"

Person in der Rolle als "Arbeitnehmer"

Multipizität, Person ist 1 oder kein Firma-Objekt zugeordnet

Multipizität, Firma sind kein, 1 oder viele Personen-Objekte zugeordnet

arbeitet für

Name der Beziehung, wird von links nach rechts gelesen

Folie 68

Navigierbarkeit

Person Firma0..1

Arbeitgeberarbeitet für

Die Pfeilrichtung zeigt die Navigierbarkeitsrichtung an. Beidseitig navigierbare Assoziationen haben aber keine Pfeile.Nichtspezifizierte Navigierbarkeit hat ebenso keine Pfeile

Objekte der Klasse Person "kennen" ihren Arbeitgeber, Objekte der Klasse Firma "kennen" aber ihre Mitarbeiter nicht.

Folie 69

MultiplizitätDie Multiplizität zeigt an, wie viele Objekte der jeweiligen Klasse an der Assoziation teilnehmen

Typische Multiplizität: 0..1, 1, 0..*, 1..*Es können auch spezielle Multiplizitäten verwendet werden wie z.B. 5, 29 oder 5..290

Person Firma0..1

Arbeitnehmer

Arbeitgeberarbeitet für

Auto Rad4

Folie 70

Aggregation und KompositionGanzes-Teil-AssoziationAggregierte Objekte werden von dem besitzenden Objekt dominiertI.Allg. ist kein externer Zugriff auf aggregierte Objekte möglichKomposition: Die Lebensdauer (Instanzierung und Freigabe) werden vom dominierenden Objekt beherrscht

Person Adresse0..*

Person StudentRolle0..*

Aggregation

Komposition

Folie 71

Assoziationsklassen (1)Assoziationen selbst können über Attribute (und auch Methoden) verfügenDie Assoziationsklasse repräsentiert die AssoziationInsbesondere bei n:m-Assoziationen werden häufig Assoziationsklassen verwendet

Student Prüfung0..*

schreibt

PrüfungsTeilnahmehatTeilgenommen : booleannote : NoteAuffälligkeit : String

Folie 72

Assoziationsklassen (2)Eine n:m Assoziation mit Assoziationsklasse (A) ist semantisch mit einer 1:n und m:1-Assoziation (B) gleichzusetzen

Student Prüfung0..*

schreibt

PrüfungsTeilnahme

Student PrüfungsTeilnahme Prüfung0..* 0..*

Folie 73

Umgang mit AssoziationenBestehen mehrere Assoziationen zwischen zwei Klassen, so werden oft rollenbeschreibende Assoziationsklassen eingeführt

Person Firma0..*

arbeitet fürArbeitnehmer

Arbeitgeber

0..*0..*

investiert inAktionär

Kapitalanlage

0..*0..*

bezieht Produkte vonKunde

Lieferant

Person Firma0..*

PersonRollerolle

Folie 74

Rekursive AssoziationenAssoziationen können zur selben Klasse verbunden seinDamit ist nicht gemeint, dass ein Objekt mit sich selbst in Beziehung steht, sondern zu Objekten der selben Klasse!Rekursive Assoziationen können auch Assoziationsklassen haben

Person Firma0..1

Arbeitnehmer

Arbeitgeberarbeitet für0..*

0..1Vorgesetzter

Mitarbeiter

Folie 75

Qualifizierende AttributeAttribute, die wesentlich die Rolle eines Objektes in der Beziehung beschreiben oder überhaupt die Beziehung erst herstellenDie qualifizierenden Attribute werden der Assoziation nicht der Klasse zugeordnet

Aufführung Eintrittskarte0..1

1aufführungsDatum: DateSitzplatzNr : String

QualizierendeAttribute

Folie 76

AssoziationseinschränkungenSpezielle Regeln einer Assoziation werden als Constraint bezeichnetAb UML 2.0: Object Constraint Language OCLDie Darstellung erfolgt in { }Typische Beispiele sind Sichtbarkeit oder Änderbarkeit (z.B. ordered, addOnly)

Person Firma0..1

Arbeitnehmer

{ordered} arbeitet für

Folie 77

StereotypesStellen Erweiterungen des UML-Standards darVergeben einem UML-Element (wie z.B. einer Klasse) ein spezielle AusprägungDarstellung des stereotyp in<< >> über dem KlassennamenHäufig verwendete Stereotypen:

Keine Klasse, nicht instanzierbar, kapselt globale Variablen und Funktionen. Zur Abbildung Nicht-OO-Bibliotheken geeignet (z.B. Mathematik-Funktionen)

<<utility>>

Klassen, die selbst passiv sind und keine Interaktionen auslösen (i.Allg. zur Datenhaltung)

<<entity>>

Klassen, die Interaktionen zwischen anderen Klassen steuern<<control>>

Klassen, die mit der Außenwelt kommunizieren. Sie bilden Schnittstellen zwischen System und Umwelt

<<boundary>>

Folie 78

VererbungAlle Eigenschaften (also Methoden, Attribute oder Beziehungen) einer Klasse (Vaterklasse) werden an die Kindklassen übertragenDie Kindklassen können weitere eigene Eigenschaften definieren und auch ererbte Eigenschaften überschreiben

VersicherungsVertrag

SachVersicherungsVertrag LebenVersicherungsVertrag

SpezialisierungGeneralisierung

VersicherungsNehmerAbschlussDatum

JahresBeitragVersicherterGegenstand

RisikoLVAnteilBegünstigtePersonLaufzeit

Folie 79

Entstehung von Vererbung

VersicherungsNehmerAbschlussDatumJahresBeitragVersicherterGegenstand

SachVersicherungsVertrag1

Zunächst entsteht aus den bekannten Anforderungen eine konkrete Klasse.Motivation zur Vererbung besteht nicht

VersicherungsNehmerAbschlußDatum

SachVersicherungsVertrag LebenVersicherungsVertrag

RisikoLVAnteilBegünstigtePersonLaufzeit

3 Eine weitere Klasse nutzt die zuvor stattgefundene GeneralisierungDieser Vorgang wird nun als Spezialisierung bezeichnet

JahresBeitragVersicherterGegenstand

VersicherungsNehmerAbschlussDatum

SachVersicherungsVertrag

Es wird eine mögliche Wieder-verwendbarkeiterkennbarAllgemeingültige Merkmale werden generalisiert

VersicherungsNehmerAbschlussDatumJahresBeitragVersicherterGegenstand

Folie 80

Vererbung vs. AggregationRealisierung einer "ist-ein" Beziehung im Gegensatz zu einer "hat-ein" Beziehung der Assoziation

Ein LV-Vertrag ist einer VersicherungsvertragEin Auto hat Räder

Vererbung im fachlichen Kontext ist selten sinnvoll Alternative zur Vererbung ist eine Aggregation

Person

Student

Person Student0..1

Ein Student ist eine Person (?)Wie wird mit dem Student in (A) verfahren, wenn das Studium beendet wurde?

Folie 81

Vererbung abstrakter MethodenWird eine abstrakte Methode vererbt, wird deren Implementierung in den Kindklassen erzwungenVorteil: lässt sich auch keine generische Implemen-tierung festlegen, so ist doch ein gemeinsames Interface erzwingbar

PersistentesObject

Person VersicherungsVertrag

Store()getStoreSQL() : String

getStoreSQL() : String getStoreSQL() : String

Eine abstrakte Methode erzwingt die Implementierung in den KindklassenKlassen mit abstrakten Methoden können selbst keine Objekte instanzieren

Die Klasse Person implementiert die abstrakte Methode

Folie 82

InterfaceEin Interface ist einer Klasse mit ausschließlich abstrakten Methoden gleichzusetzenInterfaces werden "realisiert"Eine Klasse kann viele Interfaces realisierenInterfaces definieren Methoden, die von den Realisierungen implementiert werden müssen

PersistentesObjekt

Store()Delete()Load()

<<Interface>>Veranstaltung

datumVon : DatedatumBis : Datebezeichnung : Stringpreis : Waehrungsbetrag

hatPlaetzeFrei()einbuchen()Store()Delete()Load()

VeranstaltungdatumVon : DatedatumBis : Datebezeichnung : Stringpreis : Waehrungsbetrag

hatPlaetzeFrei()einbuchen()Store()Delete()Load()

PersistentesObjekt

Store()Delete()Load()

Label-Darstellung: Icon-Darstellung:

Folie 83

Beispiel eines Klassendiagramms (1)

RoomAssignmentRoomRole : SelectionSeatingOrder : Selection

TrainerAssignmentMainTrainer : IntegerState : IntegerHotelNeed : SelectionInvitationDate : DateTrainerRole : Selection

ResourceCheckTimeoverlapping : BooleanDefaultBookingType : Selection

PersonDayOfBirth : DateEntryDate : DateExitDate : DateFunktion : SelectionEducationState : SelectionPlaceOfBirth : Text (50)

ResourceAssignmentDateFrom : DateDateTo : DateInterpretTimeframe : SelectionHourFrom : DateHourTo : DateFullDay : BooleanAssignmentText : Text (100)Comment : Text (100)OccupancyMode : SelectionReservationValidUntil : DateExternalComment : MemoInternalComment : MemoDifferentDuration : NumberDifferentDurationUnit : IntegerOccupancyReason : Integer

AddressAddressField1 : Text (100)AddressField2 : Text (100)AddressField3 : Text (100)Street : Text (100)Country : Text (6)Zip : Text (30)City : Text (100)POBox : Text (30)POBoxZip : Text (30)POBoxCity : Text (100)Type : SelectionValidUntil : Date

TelecomPhone : Text (30)Fax : Text (30)MobilePhone : Text (30)EMail : Text (100)HomePage : Text (100)Type : Selection

OrganizerGroupName : Text (100)DefaultCostCenter : Text (50)DefaultContingenteKey : Text (50)Initial : Text (30)ContingenteKey : Text (30)

OrganizationVHasChilds : Boolean 0..1

0..n +Parent

+Child 0..n

0..1+Member

ResourceSingledateAssignment

FolderField : Text (30)OrderNo : IntegerTitle : Text (100)VHasChildrenProduct : BooleanVHasChildrenFolder : BooleanDescription : MemoExportControl : Boolean

+parent

+child

ExternalEnrollContractNo : Text (50)Comment : MemoConfirmationBySupplier : DateQualityOfTrainingComment : MemoTrainingDuartion : NumberSupplierProductID : Text (30)TrainingTitle : Text (100)State : IntegerDateFrom : DateDateTo : DateLocationName : Text (50)

+ExternalSupplier

PartnerName1 : Text (50)Name2 : Text (50)PartnerID : Text (30)Status : SelectionCostCostCenter : Text (100)IncomeCostCenter : Text (100)Comment : MemoDebitorID : Text (15)CreditorID : Text (15)VATFlag : BooleanAccountigProcedure : SelectionDefaultCurrency : SelectionExtern : BooleanType : SelectionContraktID : Text (30)VAddressStreet : Text (100)VAddressCountry : Text (6)VAddressZip : Text (30)VAddressCity : Text (100)VPhone : Text (30)VFax : Text (30)VEMail : Text (100)VIsTrainer : BooleanVIsOrganizer : BooleanVIsLocation : BooleanVIsHotel : BooleanVOrganizationName1 : Text (50)VOrganizationName2 : Text (50)VContactPerson : Text (100)DefaultLanguage : SelectionContingenteKey : Text (50)FormOfAddress : SelectionJobTitle : Text (100)TextField1 : Text (100)TextField2 : Text (100)TextField3 : Text (100)TextField4 : Text (100)TextField5 : Text (100)TextField6 : Text (100)TextField7 : Text (100)TextField8 : Text (100)TextField9 : Text (100)NumberField1 : IntegerNumberField2 : IntegerNumberField3 : IntegerNumberField4 : IntegerNumberField5 : NumberNumberField6 : NumberNumberField7 : NumberNumberField8 : Number

PartnerPropertyname : Text (100)description : MemoType : Selectiongroup : SelectionhasValues : BooleanvalueSelection : Selectionexpiry : IntegerexpiryUnit : SelectionrangeFrom : IntegerrangeTo : Integer

OrganizerInitial : Text (30)LogonName : Text (30)Password : Text (15)ActiveUntil : DatePasswordValidUntil : DateDbPasswort : Text (30)FileNameImage : Text (50)Type : IntegerAssignedCostCenters : MemoVName1 : Text (50)VName2 : Text (50)VOrganizationName2 : Text (50)EcadiaPassword : Text (30)

+groupMember

+organizerAdmin0..n

LocationDescription : MemoTravelInfoPublic : MemoTravelInfoCar : MemoMapFileName : Text (50)AdditionalServices : Memo

RoomRoomName : Text (50)AmountSeats : IntegerRoomID : Text (30)SuitableForHandicap : IntegerFloor : SelectionSize : IntegerDefaultSeatingOrder : SelectionAdditionalInformation : MemoPhone : Text (50)

+TrainingRoom0..n

EventNotecreationDate : Datecontent : MemoaccessMode : SelectionpublishingMode : Selection

SingledateBegin : DateEnd : DateObjectives : MemoContent : MemoAdditionalInformation : Memo

TrainerContract : SelectionContractComment : Text (100)ContractDate : DateComment : MemoTrainerType : SelectionDefaultHoursPerYear : Integer

TrainingProgramEvent

TrainingProductContentTitle : Text (100)Targetgroup : MemoPrerequisites : MemoContent : MemoTargets : MemoAdditionalInformation : MemoMethodology : MemoIntroduction : MemoFacilitator : MemoTechnicalRequirements : MemoLanguage : SelectionCommentDuration : Text (100)CommentParticipantAmount : Text (100)CommentPrice : Text (100)ValidUntil : Date

ExplorerShortcutType : SelectionOrderNo : IntegerPositionX : IntegerPositionY : Integer

0..n0..n

EnrollRegistrationDate : DateCancellationDate : DateKostenpflichtig : BooleanState : SelectionAttendance : IntegerComment : MemoValidUntil : DateCertification : BooleanInviatationSent : SelectionInvitationSentDate : DateHotelNeed : SelectionPriority : IntegerOrderNo : IntegerCommentForIncompleteAttendance : MemoDifferentAttendanceDateFrom : DateDifferentAttendanceDateTo : DatePreferedAttendanceFrom : DatePrefferedAttendanceTo : DateOriginType : SelectionQualificationReached : SelectionLearningResult : SelectionLearningResultCommentBemerkung : MemoVParticipantID : Text (30)VParticipantName1 : Text (50)VParticipantName2 : Text (50)VParticipantPhone : Text (30)VParticipantOrgName1 : Text (50)VParticipantOrgName2 : Text (50)VParticipantEMail : Text (100)VHasHotelbooking : BooleanVEventDateFrom : DateVEventDateTo : DateVProductID : Text (30)VProductTitle : Text (100)DifferentDuration : NumberDifferentDurationUnit : IntegerVContactPersonr : Text (100)CancellationReason : SelectionDesiredLanguage : SelectionShowInTrainingHistory : BooleanTextField0 : Text (100)TextField1 : Text (100)TextField2 : Text (100)TextField3 : Text (100)

+Child

+Parent 0..1

+Participant

PartnerPropertyAssignmentvalue : Integercomment : Memostatus : SelectionpartnerPropertyType : SelectioncreationDate : Dateselection1 : Selectionselection2 : Selection

+contactPerson

TrainingProductPredecessorNecessaryType : SelectionPositionX : IntegerPositionY : IntegerRole : SelectionNecessaryLevel : Number

EventID : Text (30)Semester : Text (50)DateFrom : DateDateTo : DateHourFrom : DateHourTo : DateHourFromFirstDay : DateHourToLastDay : DateSingledatesText : Text (50)Status : IntegerCancelationReason : SelectionComment : MemoExportControl : IntegerMaxEnroll : IntegerMinEnroll : IntegerVSumEnroll : IntegerVSumWaitingList : IntegerTextBlock1 : MemoTextBlock2 : MemoTextBlock3 : MemoVSumNonShown : IntegerVSumInvited : IntegerVSumTempEnroll : IntegerVSumAttendedParticular : IntegerVSumCancellationParticipant : IntegerVSumWaitinglistExpicit : IntegerVSumCancellationOrganizer : IntegerVSumInterested : IntegerVSumAppeard : IntegerVRooms : Text (50)VTrainers : Text (50)VSumAttended : IntegerDuration : NumberDurationUnit : IntegerDeadlineDays : IntegerWebInfo : MemoVProductTitle : Text (100)VProductID : Text (30)TitleDiffering : Text (100)Language : SelectionVContactPerson : Text (100)inSingledates : BooleanNumberField7 : NumberNumberField8 : NumberInviteBeforeEvent : IntegerProceedOnDays : SelectionNumberField1 : IntegerNumberField2 : IntegerNumberField3 : IntegerNumberField4 : IntegerNumberField5 : NumberNumberField6 : Number

+EventLocation 0..1

0..n0..n

TrainingProductID : Text (30)Title : Text (100)DeliveryMode : SelectionTrainingSection : SelectionCourseType : SelectionExportControl : IntegerNewUntil : DateValidUntil : DateModuleOnly : BooleanMultipleRegistration : BooleanVHasEvents : BooleanRegistrationMode : SelectionVSumPreRegistration : IntegerReleaseState : SelectionExtern : BooleanComment : MemoRefreshCycle : NumberRefreshCycleUnit : SelectionIgnoreTimeOverlap : IntegerNumberField1 : IntegerNumberField2 : IntegerNumberField3 : IntegerNumberField4 : IntegerNumberField5 : NumberNumberField6 : NumberNumberField7 : NumberNumberField8 : NumberPlanningTimeFrom : DatePlanningTimeTo : Date

+Origin

+ProductPreRegistration

+PreRegistration

+Predecessor

+Successor0..n0..n0..n

+LogisticprofileProduct

+Logisticprofile0..*

TrainingProgram

+module0..n

+trainingProgram

TrainingProgramAssignmentOrderNo : IntegerIdealBeginWeekday : IntegerMinDistanceToPredecessor : IntegerMaxDistanceToPredecessor : IntegerBookingType : SelectionColorInTimeTable : Selection

Folie 84

Beispiel eines Klassendiagramms (2)Room

RoomName : Text (50)AmountSeats : IntegerRoomID : Text (30)SuitableForHandicap : IntegerFloor : SelectionSize : IntegerDefaultSeatingOrder : SelectionAdditionalInformation : MemoPhone : Text (50)

EquipmentName : Text (50)Description : MemoSoftwareKey : Text (50)Type : Selection

LocationDescription : MemoTravelInfoPublic : MemoTravelInfoCar : MemoMapFileName : Text (50)AdditionalServices : Memo

+TrainingRoom0..n

+EventLocation

EquipmentAssignmentamount : Integerday : IntegerdaySection : SelectionamountInterpretation : SelectiondeliveryBy : Selectionneccessity : SelectionroomRole : Selectioncomment : Memo

0..n0..n

contains

0..n0..n

requires

0..n0..ncontains

OrganizerInitial : Text (30)LogonName : Text (30)Password : Text (15)ActiveUntil : DatePasswordValidUntil : DateDbPasswort : Text (30)FileNameImage : Text (50)Type : IntegerAssignedCostCenters : MemoVName1 : Text (50)VName2 : Text (50)VOrganizationName2 : Text (50)EcadiaPassword : Text (30)

0..n 0..10..n

+OrganizerEvent

+OrganizerContent

0..n0..1

0..n+OrganizerLogistic

+Responsible0..1

Folie 85

PortInteraktionspunkt zwischen einem Classifier (Klasse, Paket, Komponente, ...) und seiner Umgebung

Gruppierung einer beliebigen Anzahl von Interfaces zu einem Dienst, der einen bestimmten Dienst/ Zweck verfolgtKapselung des Classifiers gegenüber seiner UmgebungFür ein- und ausgehende Signale

Sichtbarkeitpublic für eingehende Nachrichten protected, private für interne Nachrichtenverteilung

<<Component>>

Komponente A

Port (public)Port (protected)

Ausgehendes Interface (provided)

Eingehendes Interface (required)

Folie 86

Komponenten DiagrammModelliert die Software-Architektur mit Bibliotheken, Komponenten, Datenbanken, usw.

Abhängigkeiten

Komponente

<<Component>>

GUISteuerung

<<Component>>

Verbindungsrechner

<<Component>>

Fahrplandatenbank

Anschlüsse

<<Component>>

BenutzerGUI

Verbindungen

Konnektor

InterfacePort

Folie 87

Komponenten Diagramm (2)Komponente: Abgegrenzter Teil des GesamtsystemsKonnektor (=requiredInterface): eine von der Komponente benötigte SchnittstelleInterface (=providedInterface): eine von der Komponente bereitgestellte SchnitttstellePort: Interaktionspunkt, kann mehrere (provided) Interfaces enthalten

<<Component>>

Komponente 1

<<Component>>

Komponente 2

Interface 1

Konnektor

InterfacePort

Folie 88

UML Spezifikation zu Komponente Siehe UML Superstructure, Kapitel 8

Folie 89

Kompositions-Struktur-Diagramm (1)Ab UML 2.0, Composite Structure„Kontext“-bezogenes Klassen-, Objekt oder KomponentendiagrammZeigt eine „Ausprägung“ oder eine bestimmte Konfiguration

fahrgast : Person

: Kreditkarte

Abrechnung Kollaborationstyp

Folie 90

Kompositions-Struktur-Diagramm (2)Modelliert eine „Teil von“-Beziehung, ähnlich wie bei der AggregationDie „Teile“ können über definierte Schnittstellen (Ports) mit der Umgebung kommunizieren

Person

: Adresse „Teile“ werden zu Attributen der umhüllenden Klasse

: Bankverbindung

Verhaltensdiagramme

Folie 92

SequenzdiagrammBeschreibt einzelne, genau definierte AbläufeDient der Beschreibung von Use Cases und zur Beschreibung des dynamischen Verhaltens von Objekten (Achtung: der Objekte, nicht der Klassen!)Zeigt über die Abfolge (von oben nach unten) und auch über die Nummerierung die zeitliche Reihenfolge der Botschaften anDie Summe aller Sequenzdiagramme beschreibt das dynamische Verhalten des SystemsBotschaften werden bei der Klasse des Empfänger-objekts als Methode implementiert

Folie 93

Sequenzdiagramm (1)Beispiel: „Fahrkarte bestellen“

belasten(betrag)

sd: Fahrkarte bestellen

Folie 94

Sequenzdiagramm (2)Alternativen

belasten(betrag)

[ result == true ]

result

[ else ]sperren()

Folie 95

Sequenzdiagramm (3)Schleifen

bestellenberechnePreis

belasten(betrag)

[ restbetrag = 0 ]

result

restbetrag

Folie 96

Sequenzdiagramm (4)Referenzen

bestellenberechnePreis

belasten(betrag)

result

restbetrag

belasten(betrag)

Folie 97

Sequenzdiagramm (5)Referenz

: Kreditkarte ...

belasten(betrag)

sd: belasten(betrag)

Folie 98

: Fahrgast : Bestellvorgang

: Fahrkarte

: Person

: Kreditkarte

1: start( ) 2: bestellen( )

3: berechnePreis( )

4: belasten(Waehrungsbetrag)

5: istGueltig( )6: belasten(waehrungsbetrag)

KommunikationsdiagrammÄhnlicher Inhalt wie beim SequenzdiagrammBei vielen Objekten mit wenig Botschaftsfluss geeignet

Botschaft

Beteiligtes Objekt

Reihenfolge

Folie 99

AktivitätendiagrammAktivitätenfolge mit KontrollflussWird zur Beschreibung von Use Cases oder Klassen eingesetztWie bei Zustandsübergängen kann ein Ereignis je Transition hinterlegt werdenVerzweigungen und Zusammenführungen

Aktivität

Entscheidung (Decision)

Aktivität 1 Aktivität 2

Aktivität 3

Note bewerten

Als nicht bestanden markieren

Prüfung korrigieren

Noten eintragen

besser als 5

Synchronisation

Folie 100

Verzweigung / VereinigungVereinigung (MergeNode)

Einer der Eingänge muss aktiv sein

Verzweigung (Decision Node)

Einer der Ausgänge wird aktiv

Zusammenführung (JoinNode)

Alle Eingänge müssen aktiv sein

Gabelung (Fork Node)Alle Ausgänge werden aktiv

Folie 101

KnotenStart- und Endknoten

Sprungmarken

Aktivität A 1 1 Aktivität B

Aktivität A Aktivität B

(beendet den Fluss an der entsprechenden)

(beendet die gesamte Aktivität)

Folie 102

Signale im Aktivitätsdiagramm

Signal senden

Signal empfangen

Empfang eines Zeitereignisses

Unterbrechungsbereich

Unterbrechungskante

Schlafen

Aufstehen

7.00 UhrNachbar lärmt

Fernsehen

Folie 103

Verlauf einer typischen PartyZeitpunkt wählen

Gäste einladen Einkaufen

[Zusagen < 50%]

[Zusagen >= 50%]

Getränke kalt stellen

Essen kochen

Feiern

Partygäste zählen

Vorräte prüfen

Bei Tankstelle nachkaufen

Warnung der Polizei

Party beenden

Betrunken ins Bett fallen

Essen wegwerfen

Partyservice bestellen

[Essen verbrannt]

[Essen OK]

[< 10% sind noch da]

[>= 10% sind noch da]

[keine Vorräte mehr]

[genug]Party abbrechen

Quelle: Jeckle u.a., „UML glasklar“, Hanser Verlag, 2003

Folie 104

Aktivitätsdiagramm: Partitionss

Eine „Partitions" veranschaulicht den Zuständigkeits-bereich eines bestimmten ObjektsWerden oft auch als „Swimmlanes“bezeichnetSpeziell zur Veranschau-lichung von UseCases

Prüfung anmelden

Prüfung schreiben

Prüfung abgeben

Anmeldung auf Prüfungsliste ergänzen

Als nicht bestanden markieren

Noten eintragen

Note bewertenbesser als 5 5

Prüfung erstellen

Prüfung abhalten

Prüfung korrigieren

PrüferPrüfungsamtStudent

Folie 105

Zustandsautomat

Zustandsname

entry / Aktivitätexit / Aktivitätdo / Aktivität

Trigger [Guard] / Aktivität

Trigger: Ereignisse, die den Zustandswechsel herbeiführenGuard: Bedingung, die zum Zustandswechsel erfüllt sein mussAktivität: Aktivität, die beim Zustandswechsel durchgeführt wird

Zudem können noch Trigger mit Bedingungen festgelegt werden, die Aktivitäten auslösen

Zeigt die Zustände und Zustandsübergänge innerhalb eines Objektes anElemente:

Folie 106

ZustandsautomatZeigt die Zustände und Zustandsübergänge innerhalb eines Objektes an

Geldbetrag ist eingeworfen

Geld einwerfen / Anzeige aktualisieren

Parkschein wird gedruckt

Taste "Parkschein" gedrückt / Geldeingabe sperren

GeldausgabeTaste "Abbruch" gedrückt

Timer T1 abgelaufen / Alle Werte zurücksetzen

/ Alle Werte zurücksetzen

Zustand

Beginn

Ereignis /Aktion

Zustands-übergang

Das Erreichen des Ende-Zustandes (final state) führt zur Terminierung des Objektes, dessen Zustände hier dargestellt werden

Folie 107

VerbundzustandComposite stateSpezialisierung von Zuständen

Verbindung aufbauen

Abgehoben

Nummerneingabe

Verbindungsaufbau

Partner belegt Freizeichen

Verbindung

Abgehoben

NummerneingabeTaste

Verbindungsaufbau

Nummer gültig

Partner belegt Freizeichen

Aufgelegt

Verbindung

Partner nimmt ab

Partner frei signalisiertPartner belegt signalisiert

Aufgelegt

Abheben

Composite state

Führt in den Startzustand des Verbundzustands

Alle Ereignisse "Aufgelegt" führen aus dem Verbundzustand (jedem beliebigen Zustand dort) wieder heraus

Object ConstraintLanguage (OCL)

Folie 109

OCLDie Object Constraint Language ist Teil von UML 2.0OCL ist eine formale, prädikatenlogikbasierte Sprache zur Ergänzung von UML-ModellenOCL Ausdrücke sind leicht zu lesen (leichter als beispielsweise die von Z oder die Prädikatenlogik)OCL Ausdrücke sind deklarativ, d.h. sie ändern den Systemzustand nichtDient zur Formulierung von Zusicherungen

Invarianten von Klassen Vor- und Nachbedingungen von Methoden

Nutzen von OCLDie UML-Modelle können präziser beschrieben werdenProgrammcode kann generiert werden

Folie 110

OCL Constraints (1)OCL constraints werden relativ zu einem Systemzustand S ausgewertetOCL constraints sind vom Typ Boolean; sie sind wahr oder falsch bezüglich SOCL constraints beschränken die erlaubten Systemzustände eines UML Klassendiagramms

Folie 111

OCL Constraints (2)Invarianten:

Eine Invariante I für eine Klasse C ist ein Boolscher OCL-Ausdruck.Semantik: I gilt in jedem feststellbaren Zustand (snapshot) jeder Instanz von C.

Vor- und Nachbedingungen:Vor- und Nachbedingungen (v, n) für eine Operation p ist ein Paar von Boolschen OCL-Ausdrücken.Semantik: v muss zum Zeitpunkt, wenn p aufgerufen wird, truesein. n muss zum Zeitpunkt, wenn p terminiert, true sein

Folie 112

Der KontextDer Kontext legt fest, auf welches Element sich ein OCL Constraintbezieht.

Beispiel:

context [ kontextInstanz : ] typeNameinv: OclAusdruck1...inv: OclAusdruckn

context Personinv: self.alter > 0

Soll bedeuten: zu keinem Zeitpunkt darf es ein Objekt der Klasse Person geben, das einen negativen Wert im Attribut alterhatself (die referenziert per

default auf die Kontext-Instanz)

Folie 113

Boolean Operationen

Booleannot aNegation

Booleana = bVergleich

Booleana <> bUngleichheit

Booleana implies bImpliziert (wenn a true ist, muss auch b true sein

Booleana or | and | xor bOder | Und |Exklusiv Oder

ErgebnistypNotationOperation

Folie 114

Integer/Real Operationen

Integer/Reala.mod(b)Modulo

Integer/Reala.max(b), a.min(b)Min, Max

Booleana = b, a<>b, a<b, a>b, a<=b, a>=b,

Vergleich

Integer/Reala+b, a-b, a*b, a/bRechnen

ErgebnistypNotationOperation

Folie 115

Spezielle OCL-OperatorenoclIsTypeOf (t : OclType) : BooleanoclIsKindOf (t : OclType) : BooleanoclInState (s : OclState) : Boolean

Prüfung von Zuständen bei Zustandsautomaten (State D.)oclIsNew () : Boolean

für Nachbedingungen, prüft, ob Objekte innerhalb einer Methode neu erzeugt wurden

oclAsType (t : OclType) : instance of OclTypeBeispiel:context Personinv: self.oclIsTypeOf( Person ) -- ist trueinv: self.oclIsTypeOf( Firma) -- ist false

Folie 116

OCL KollektionenSet(Menge), OrderdSetBag (Liste)Sequence (geordnete Liste)

Instanzierung:als Literal

Set { 1, 2, 4, 42}Sequence {1..10} entspricht Sequence {1,2,3,4,5,6,7,8,9,10}

durch Navigationdurch Aufruf von Kollektionsmethodendurch Klasse.allInstances()

Folie 117

OCL Kollektionen (Auszug)

Anzahl, wie oft das Objekt in der Kollektion enthalten ist

integercount(objekt)

wahr, wenn Menge leer istbooleanisEmpty

wahr, wenn <ausdruck> für jedes Element gilt

booleanforAll(<ausdruck>)

wahr, wenn <ausdruck> für mind. ein Element gilt

booleanexists(<ausdruck>)

Teilmenge, für die <ausdruck> giltMengeselect(<ausdruck>)

wahr, wenn alle Elemente der Menge Menge2 enthalten sind

booleanincludesAll(Menge2)

falsch, wenn Menge leer istbooleannotEmpty

Anzahl d. Elementeintegersize

BeschreibungErgebnistypOperator

Folie 118

OCL Kollektionen (2)liefert true falls <ausdruck> für alle Elemente true ist.

c->forAll(objekt1, ... Objektn |<ausdruck >)

liefert true falls <ausdruck> für mindestens eines der Elemente true ist.

c->exists(objekt1, ... Objektn | <ausdruck>)

context Firma

inv: self.Mitarbeiter->forAll(p1, p2 |

p1 <> p2 implies p1.Name <> p2.Name)

context Firma

inv: self.Mitarbeiter->exists(p | p.Gehalt > 100000)

Folie 119

OCL - Beispiel

Person0..*

Mitarbeiter Firma

BezeichnungNameVornameGehaltAlter

Arbeitgeber

Die Mitarbeiter sind mind. 16 und max. 65 Jahre altJeder hat ein Gehalt > 0

context Firma

inv: self.Mitarbeiter->forAll(m | m.Alter>=16 and m.Alter<=65)self.Mitarbeiter->forAll(m | m.Gehalt >= 0)

Folie 120

OCL - Beispiel

Person0..*

Mitarbeiter Firma

Bezeichnung

Der Chef verdient mehr als sein Mitarbeiter

NameVornameGehaltAlter

Arbeitgeber

Mitarbeiter

context Person

inv: self.Chef->notEmpty() impliesself.Chef.Gehalt > self.Gehalt

Folie 121

OCL - Beispiel

Person0..*

Mitarbeiter Firma

Bezeichnung

Der Chef arbeitet bei der selben Firma wie sein Mitarbeiter

Arbeitgeber

Mitarbeiter

context Person

inv: self.Chef->notEmpty() impliesself.Chef.Arbeitgeber = self.Arbeitgeber

Folie 122

OCL - Beispiel

Person0..*

Mitarbeiter Firma

Bezeichnung

Es gibt mindestens einen „Oberchef“

Arbeitgeber

Mitarbeiter

context Firma

inv: self.Mitarbeiter->select(Chef->isEmpty())->size >= 1

Folie 123

Vor- und NachbedingungenPerson

Mitarbeiter Firma

BezeichnungistPleite : Boolean

Arbeitgeber

context Firma::einstellen(p : Person)

pre: not self.istPleite and -- Firma ist nicht pleitep.Arbeitgeber->isEmpty() -- Person ist nicht bereits

-- anderswo beschäftigtpost: p.Arbeitgeber = self and -- jetzt eingestellt

p.Gehalt > p.Gehalt@pre -- Stellenwechsel mit -- Gehaltserhöhung

einstellen(p : Person)

NameGehalt : Real

Folie 124

OCL MessagesUm auszudrücken, dass eine „Botschaft“ versendet wurde, dient der hasSent (‘^’) Operator:

Bei unspezifizierten Parametern:

Die Menge der Aufrufe einer Methode an einen Empfänger wird über ^^ ausgedrückt

context Firma::einstellen(p : Person)

post: p^setArbeitgeber(self)

context Subject::hasChanged()

post: observer^update(? : Integer, ? : Integer))

Folie 125

OCL Werkzeuge

Folie 126

OCL Literaturhttp://www.omg.org/technology/documents/modeling_spec_catalog.htmJos Warmer, Anneke Kleppe, „The Object ConstraintLanguage“, second edition, Addison-Wesley, 2003.

Folie 127

Übung

SpieleristVerletzt : BooleanistTorwart : Boolean

Spielaustragungsort : StringaustragungsDatum : Date

Aufstellung

auswechseln(spielerRein : Spieler, spielerRaus : Spieler)

+feldspieler10

0..1+torwart

VereinvereinsName : String

+mitarbeiter 11..*

Trainer

1+chefTrainer0..*

+assistenzTrainer10..*

+arbeitgeber

Folie 128

AufgabeJeder Verein hat mindestens einen CheftrainerKein Spieler einer Aufstellung ist verletztAlle Spieler einer Aufstellung arbeiten beim selben Verein

Vor und Nachbedingungauswechseln

Folie 129

Übung a:

context Verein

inv: not self.chefTrainer->isEmpty()

Jeder Verein hat mindestens einen Cheftrainer

Folie 130

Übung b:

context Aufstellung

inv: self.feldSpieler->Select(istVerletzt)->isempty()inv: not self.torwart.istVerletzt

Kein Spieler der Aufstellung ist verletzt

Folie 131

Übung c:

context Aufstellung

inv: self.feldSpieler->forAll(s1, s2 | s1.arbeitgeber = s2.arbeitgeber)

Alle Spieler einer Aufstellung arbeiten beim selben Verein

Folie 132

Übung d:

context Aufstellung::auswechseln(spielerRein : Spieler,

spielerRaus : Spieler)pre: self.feldspieler->exists(spielerRaus) and

not self.feldspieler->exists(spielerRein) andnot spielerRein.istVerletzt

post: not self.feldspieler->exists(spielerRaus) andself.feldspieler->exists(spielerRein)

Auswechslung

Model DrivenArchitecture MDA

Folie 134

Modelle im Entwicklungsprozess

Modell Modell

Code Code

Modell

generieren generieren Reverse-Engineering

Nur Code Code-Generierung

„Round Cycle“ Ausführbares Modell

Folie 135

MDAwww.omg.org/mdaModelle sind zentrales Element des EntwicklungsprozessesGrundgedanke ist eine Modelltrennung

Platform independent model (PIM): Technologieneutrale Bestandteile wie z.B. Geschäftsprozesse, Fachlogik, Domänenmodell etc.Platform specific model (PSM): Modell für die speziell zum Einsatz kommende Systemlandschaft wie z.B. J2EE

Die Vision besteht in einer Ausführbarkeit dieser ModelleViele Werkzeuge werden angeboten

Folie 136

UML-ProfileUML-Profile spezifizieren domänenspezifische Typen, Stereotypes usw.UML Testing Profile

The UML Testing Profile defines a language for designing, visualizing, specifying, analyzing, constructing and documenting the artifacts of test systems. [...] The UML Testing Profile can be used stand alone forthe handling of test artifacts or in an integrated manner [...]

UML Profile for Systems Engineering (SysML)[...] supports the specification, analysis, design, verification and validation of a broad range of systems and systems-of-systems. These systems may include hardware, software, information, processes, personnel, and facilities. (www.sysml.org)

WeitereUML Profile for Schedulability, Performance and Time UML Profile for System on a Chip (SoC) UML Profile for Enterprise Application Integration (EAI)

Folie 137

ACM, Alex E. Bell, Death by UML Fever, Queue, v.2 n.1, March 2004

Folie 138

Was UML nicht modellieren kann ...Projektplan, Arbeitspakete, Rollen, AktivitätenPersonalplanungBudgetNichtfunktionale Anforderungen (z.B. Stabilität, Wartbarkeit, Performance, Qualität, ...)Relationales Datenmodell (ER-Diagramm)Testplan, Testfälle, TestberichtRisiken, QualitätssicherungBegriffslexikon (Glossar)GUI-EntwürfeConfiguration Management...

Einführung in die Unified Modeling Language · se Programmentwicklung, Vorlesungsskript UML...

Documents

Transcript of Einführung in die Unified Modeling Language · se Programmentwicklung, Vorlesungsskript UML...

Graphische Testfallmodellierung mit UML – …...Verwendung von UML (Unified Modeling Language) Graphische Testfallmodellierung mit UML > 25. Oktober 2006 > Folie 6 Institut für

Unified Modeling Language (UML) - Uni Bremen || Startseiteroefer/pi2-04/10.pdf · 3 Universität Bremen Unified Modeling Language (UML) Warum Modellieren? Die meisten Systeme sind

Scriptum zur Vorlesung im Master-Modul · 4 Aufbau einer Methode mit der Unified Modeling Language (UML) ..... 215 7. Prozeßmodellierung mit ARIS ..... 243 1 Geschäftsprozeßorientierung

1 Dipl.-Inform. Christian Fuß Lehrstuhl für Informatik 3 an der RWTH Aachen UML Unified Modelling Language Dipl.-Inform. Christian Fuß Dieses Tutorial.

A Einführung in die UML - dpunkt.de Einfuehrung in di… · 1375 A Einführung in die UML Die Uniﬁed Modeling Language, kurz UML, ist eine graﬁsche Notationsform, die bei der

UML Version 2 (rev. 2002-01-04) · 2017. 3. 5. · M. Jeckle – UML Version 2 2002-01-23 4 Research and Technology Gliederung I. Was bisher geschah ... • Vom Method War zur Unified

Die Unified Modeling Language (UML) - mario-jeckle.de · M. Jeckle – Die Unified Modeling Language (UML) 2001-01-29 3 Research and Technology „Modellierung“ •allgemein: Muster,

Einführung in die Unified Modeling Language (UML)micha/praesentationen/uml_hausarbeit.pdf · Einführung in die Unified Modeling Language (UML) Hausarbeit zum Proseminar „Datenbanken“

Uni ed Modeling Language (UML) UML: Einf uhrung Uni ed ... · Einf uhrung in die Modellierung Petrinetze Uni ed Modeling Language (UML) Klassen- und Objektdiagramme Verhaltensdiagramme

Einführung in das Eclipse Modeling Framework · UML-basierten Editoren (grafische, konkrete Syntax) – Text-basierten Editoren (textuelle, konkrete Syntax) • Alle Editoren garantieren

Datenmodellierung Entity-Relationship-Modell (ER) … · Datenmodellierung-Entity-Relationship-Modell (ER) Unified Modeling Language (UML) Prof. Dr.-Ing. Ralf Bill Universität Rostock

UP1 Unified Process (UP), Rational UP (RUP) Prozessmodell passend zu UML und teils in UML spezifiziert; sehr mächtiges Prozessframework; baut auf den best.

Modellierung UML (Folien teilw. von Prof. B. K onig) · UML (Folien teilw. von Prof. B. K onig) Prof. Norbert Fuhr 1/196 UML: Einf uhrung UML = Uni ed Modeling Language IStandard-Modellierungssprache

UML - Klassendiagramme · Unified Modeling Language(UML) Standardisierte graphische Notation für alle Aktivitäten der Softwareentwicklung • Nutzen für Anforderungserhebung, Entwurf,

Kapitel 3 Die Unified Modeling Language (UML) · UML-Diagramm Vhlt di UseCase-Diagramm Aktivitätsdiagramm Verhaltensdiagramm Zt ddiZustandsdiagramm Interaktionsdiagramm Sequenzdiagramm

Kapitel 4 Einführung in die Unified Modeling Language (UML) · zAktivitätsdiagramm/Activity diagram f g h d e Aktivitätsdiagramm / Modelliert das dynamische Verhalten eines Systems,

Modellierungstechniken im Softwaredesign€¦ · Unified Modeling Language (UML) • Standard-Modellierungssprache für Software Engineering • Entwickelt von Grady Booch, James

Handbuch TC3 UML - Beckhoff Automationftp.beckhoff.com/download/document/automation/twincat3/TF1910_… · UML (Unified Modeling Language) ist eine grafische Sprache, die zur Analyse,

SysML (Systems Modeling Language) und UML (Unified ... · Inhalt SysML und UML: Übersicht, Zusammenhang, Diagramme Modellbasierte Entwicklung: Systementwicklung, Softwareentwicklung

Modellieren mit der Unified Modeling Language: Klassen ... · UML-Literal → Java-Konstante UML-Enumeration → Java Enum Typ A B e d i..j k..l. Taentzer Einführung in die Softwaretechnik