Kapitel 4. Die Unified Modeling Language (UML)

Transkript

1 Vorlesung Softwaretechnologie Wintersemester 2012 R O O T S Kapitel 4 Die Unified Modeling Language (UML) - Stand: Modellierung und UML Übersicht 4.2 Kurzüberblick wichtiger Notationen im Zusammenhang 4.3 Strukturdiagramme im Kleinen: Klassen, Objekte, Pakete 4.4 Verhaltensmodellierung: Zustands- und Aktivitätsdiagramme 4.5 Verhaltensmodellierung: Sequenz-, Kommunikations- und Interaktionsübersichtsdiagramme

2 Kapitel 4: UML 4.1 Modellierung und Unified Modelling Language Übersicht Ausgangspunkt Warum Modellierung? Warum objektorientierte Modellierung? Warum mit der UML? UML-Überblick R O O T S

3 Problemstellung Ausgangssituation: Sie kennen 2-3 Programmiersprachen haben bisher allein oder in sehr kleinen Gruppen (<5) gearbeitet Neue Herausforderungen: Sie sollen mit Kollegen zusammenarbeiten, die andere Programmiersprachen nutzen mit Kunden kommunizieren, die nichts von Informatik verstehen komplexe, evt. verteilte Systeme realisieren, mit einer Vielzahl von Klassen, Subsystemen, verschiedensten Technologien, Entwürfe auf einer höheren Abstraktionsebene als Quellcode kommunizieren und dokumentieren auch die Software-Verteilung, -Einführung und den Betrieb planen Lösungsweg: Abstraktion des zu realisierenden Systems Erst modellieren, dann programmieren! Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-3 R O O T S

4 Warum Software modellieren? Software ist schon eine Abstraktion, also warum noch modellieren? Software wird umfangreicher, nicht kleiner Windows NT 5.0 ~ 40 Millionen Zeilen Code Kein Programmierer kann diese Menge Code alleine bewältigen. Code ist oft von Entwicklern, die an der Entwicklung nicht mitgewirkt haben, nicht direkt zu verstehen Wir brauchen einfachere Repräsentationen für komplexe Systeme Modellierung ist ein Mittel um mit Komplexität umzugehen Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-4 R O O T S

5 Systeme, Modelle, und Sichten Ein Modell ist eine Abstraktion, welche ein System oder einen Teil davon beschreibt Eine Sicht stellt ausgewählte Aspekte eines Modells dar. Modelle eines Systems können sich überschneiden. Sichten auch. Flugzeug - System Skelettmodell Flugsimulator-Modell Elektr. Verkabelung Sicht Navigationssystem Sicht Tanksystem Sicht Eine Notation ist ein Satz von Regeln (grafisch oder textuell) zur Darstellung von Sichten Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-5 R O O T S

6 Systeme, Modelle, und Sichten (UML) Dies ist eine statische Sicht eines Modells von Systemen, Modellen und Sichten Sie ist in der UML -Notation beschrieben System beschrieben durch * Modell * dargestellt durch Sicht... und dies ist ihre Instanz für das vorige Beispiel. Sie ist ebenfalls in der UML - Notation beschrieben Flugzeug:System Skelettmodell:Modell Flugsimulator:Modell Blaupausen:Sicht Tanksystem:Sicht Elektr Verkabelung:Sicht Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-6 R O O T S

7 Anwendungsdomäne Lösungsdomäne Anwendungsdomäne (Anforderungsanalyse): Die Arbeitsumgebung des Systems Lösungsdomäne (Design): Die zum Bau verfügbaren Technologien Modell der Anwendungsdomäne (Ausschnitt) Verkehrskontrolle UML: Paket Flugplan Kontrolleur Systemmodell (Ausschnitt) Übersichtsdisplay Kartendisplay Flugzeug Flughafen Flugplandatenbank Verkehrskontrolle Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-8 R O O T S

8 Probleme im traditionellen SW-Prozess Workflow Dokumente. Analyse Pflichtenheft (Text) Übersicht? Abbildbarkeit? Nachvollziehbarkeit? Entwurf Flussdiagramme,... Implementierung Programmcode Test Programmcode Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-9 R O O T S

9 Unified Modeling Language (UML) Standardisierte graphische Notation für alle Aktivitäten der Softwareentwicklung Nutzen für Anforderungserhebung, Entwurf, Implementierung, Einsatz ( deployment ), Besondere Unterstützung für objektorientierte Modellierung Standardisiert durch die OMG (Object Management Group) Bietet zahlreiche Diagrammtypen für verschiedene Sichten von Software statische Sichten auf die Struktur dynamische Sichten auf das Verhalten Mittlerweile breite Werkzeugunterstützung für die Erstellung von UML Diagrammen Code-Generierung aus Diagrammen (Forward Engineering) Diagramm-Generierung aus Code (Reverse Engeneering) nahtlose Synchronisation von Diagrammen und Code (Round-Trip Engineering) Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-10 R O O T S

10 Nutzen der UML Kommunikation mit Anwendern Wenig formal Einfache graphische Notation Konzentration auf das Wesentliche Kommunikation mit Kollegen Austausch von Designs,... Abstraktion von Sprachdetails Schutz vor übereilter Implementationssicht Bandbreite unterstützt alltägliche und exotische Konzepte manuell, rechner-unterstützt und kombiniert einsetzbar Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-11 R O O T S

11 Bezug von UML zu gängigen OO Sprachen UML C++ Konzepte ohne direkter Entsprechung in gängigen Sprachen direkt ineinander abbildbarer gemeinsamer Kern sprachspezifische Details Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-12 R O O T S

12 UML: Geschichte und Literatur Entstanden aus der Zusammenführung dreier führender objektorientierten Methodologien OMT (James Rumbaugh) Klassendiagramme, Sequenzdiagramme, OOSE (Ivar Jacobson) Anwendungsfalldiagramme, Booch (Grady Booch) Software-Prozess Unified Process Literatur: Standardwerke The Unified Modeling Language User Guide (Booch & al 1999) The Unified Modeling Language Reference Manual (Rumbaugh & al 1999) alle im Addison Wesley / Pearsons Verlag) Empfehlung UML Distilled (Fowler & al. 2000, Addison Wesley) kurz und gut! UML@Work (Hitz & Kappel 2005, dpunkt) UML 2.0, deutsch, ausführlich! Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-13 R O O T S

13 UML Versionen UML 1 (1997) / UML 1.1 (1998) OMG-Spezifikation eines Modellierungsstandards OMG (Object Management Group): Verband führender Softwareunternehmen und Standardisierungsgremium für objektorientierte Systementwicklung UML 2 (2005) Neue Diagrammtypen Sollen den Anforderungen heutiger Softwarearchitekturen gerecht werden Komponenten- und Serviceorientierte (SOA) Architekturen, Geschäftsprozessmanagement, Echtzeitsysteme, Modifikationen bestehender Diagrammtypen Konvergenz der Diagrammtypen, vor allem der dynamischen Diagramme Grundidee: Modell-Driven Software Engineering (MDSE) Quellcode als Hauptartefakt ablösen und durch Modelle ersetzen, aus denen die Programme generiert werden Modelltransformationen, Generative Programmierung Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-14 R O O T S

14 UML Diagrammtypen Dies ist ein Klassendiagramm! Strukturdiagramm Klassendiagramm Objektdiagramm Paketdiagramm Komponentendiagramm UML-Diagramm Verhaltensdiagramm Kompositionsstrukturdiagramm Verteilungsdiagramm UseCase-Diagramm Aktivitätsdiagramm Zustandsdiagramm konkrete Klasse abstrakte Klasse (kursiv) Vererbungsbeziehung Interaktionsdiagramm Sequenzdiagramm Kommunikationsdiagramm Interaktionsübersichtsdiagramm Zeitverlaufsdiagramm

15 UML Diagrammtypen: Was wird wo erläutert? Strukturdiagramm Klassendiagramm Objektdiagramm Paketdiagramm Komponentendiagramm Kompositionsstrukturdiagramm Klassendiagramm++ UML-Diagramm Verteilungsdiagramm Verhaltensdiagramm UseCase-Diagramm Aktivitätsdiagramm Zustandsdiagramm Interaktionsdiagramm In diesem Kapitel Im Kapitel Anforderungserhebung und Anforderungsanalyse Im Kapitel Systementwurf Im Kapitel Objektentwurf Sequenzdiagramm Kommunikationsdiagramm Interaktionsübersichtsdiagramm Zeitverlaufsdiagramm

16 Kapitel 4: UML 4.2 Beispiel: Modellierung einer Uhr Kurzüberblick elementarer UML-Notationen Use-Case Diagramme Klassendiagramme Sequenzdiagramme Zustandsdiagramme R O O T S

17 Beispiel: Eine einfache LCD-Uhr Struktur 1 Display 2 Knöpfe 1 Batterie Verhalten Knopf 1 drücken startet Stunden-Einstellung Jeder weitere Druck schaltet weiter zu Minuten, Sekunden, Stunden,. Knopf 2 drücken erhöht den Wert des aktuell einzustellenden Elementes. Beide Knöpfe drücken beendet die Einstellung

18 UML-Kurzübersicht: Klassen-Diagramme Klasse Multiplizität 2 Knopf status drücke() lasselos() 1 1 LCDDisplay tick blinkesekunden() blinkeminuten() blinkestunden() stoppeblinken() refresh() EinfacheUhr Zeit Stunde Minuten Sekunden erhöhestunden() erhöheminuten() erhöhesekunden() start() jetzt() Assoziation lade() 2 Batterie Attribute Operationen Klassendiagramme repräsentieren die Struktur eines Systems

19 UML-Kurzübersicht: Use-Case Diagramme System Anwendungsfall ( Use Case ) LeseZeit Akteur Uhrenträger SetzeZeit Uhrmacher TauscheBatterie Use-Case Diagramme stellen die Funktionalität eines Systems aus Sicht der Benutzer dar.

20 UML-Kurzübersicht: Sequenz-Diagramme sd Watch Objekt :Uhrenträger :EinfacheUhr :LCDDisplay :Zeit drückeknopf1() drückeknopf1() blinkestunden() blinkeminuten() drückeknopf2() erhöheminuten() drückebeidek() stoppeblinken() refresh() starteabneuerzeit() Nachricht Aktivierung Sequenzdiagramme stellen die Interaktion von Objekten dar. Hier: Einstellen der Zeit an einer LCD-Uhr Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-22 R O O T S

21 UML-Kurzübersicht: Zustands-Diagramme Anfangszustand Zustand Event knopf1&2gedrückt Blinke Stunden knopf2gedrückt Erhöhe Stunden knopf1gedrückt Transition knopf1&2gedrückt Blinke Minuten knopf2gedrückt Erhöhe Minuten Endzustand Stoppe Blinken Blinke Sekunden knopf1&2gedrückt knopf1gedrückt knopf2gedrückt Erhöhe Sekunden Zustandsdiagramme stellen die interne Sicht von Objekten dar: Zustände und Zustandsübergänge endlicher Automat Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-23 R O O T S

22 UML Notationskonventionen Diagramme sind Graphen Knoten sind Konzepte Kanten sind Beziehungen zwischen Konzepten Rechtecke sind Typen oder Instanzen Instanzen werden durch Rolle : Typ und Unterstreichung gekennzeichnet meineuhr:einfacheuhr Joe:Feuerwehrmann Bei Typen werden die Namen nicht unterstrichen EinfacheUhr Feuerwehrmann

23 Kapitel 4: UML 4.3 Strukturdiagramme im Kleinen Klassendiagramme Seite Objektdiagramme Seite Paketdiagramme Seite jeweils Ausschnitte R O O T S

24 Strukturdiagramme im Kleinen Beschreiben die kleinsten in der objektorientierten Modellierung erfassten Teile eines Entwurfes Klassen die am häufigsten verwendete Struktur-Abstraktion Einzelne Objekte zur Verdeutlichung von Objektbeziehungen, die sich auf Klassenebene nicht ausreichend beschreiben lassen Pakete Gruppen von Klassen, die thematisch zusammengehören allerdings nicht unbedingt zur Laufzeit gemeinsam auftreten Diagrammtypen, die die Struktur im Großen beschreiben, werden im Kapitel Systementwurf behandelt Sie beschreiben Einheiten, die für die modulare Komposition, die Verteilung und die Laufzeit von Software Bedeutung haben Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-26 R O O T S

25 Klassendiagramm: Elemente Name Zone2Price : Table Tarif getzones() : Enumeration getprice(zone) : Price Attribute Signatur Operationen Eine Klasse repräsentiert ein Konzept. Eine Klasse kapselt Zustand (Attribute) und Verhalten (Operationen). Jedes Attribut hat einen Typ. Jede Operation hat eine Signatur. Der Klassenname ist die einzige unverzichtbare Information Hinzufügen weiterer Information beim Fortschreiten des Modellierungsprozesses Es ist möglich, unwichtige Details in einer teilweisen Sicht des Modells zu verstecken Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-28 R O O T S

26 Klassendiagramm: Verschiedene Sichten Detaillierungsgrad Implementierung Analyse / Design eingeklappt Window Fließender Übergang Window size: Area visibility: Boolean display() hide() Window { status=tested } + default-size: Rectangle + size: Area = (100,100) # visibility: Boolean - xwin: XWindow + display() + hide() + create() Sichtbarkeit (Implementierungs-Ansicht) public: + protected: # private: Weitere Notationen Klassenvariable / -methode: unterstrichen abstrakte Klasse / Methode: kursiv Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-29 R O O T S

27 Klassendiagramm: Abstrakte Klassen und Interfaces Abstrakte Klassen Definiton Implementierung unvollständig Enthalten abstrakte Methoden Notation Kursivschrift für Namen abstrakter Typen und Methoden Alternativ: Constraint {abstract} in geschweiften Klammern Äquivalente Beispiele Flugzeug tank starten() beladen() tanken() Flugzeug { abstract } tank starten() beladen() tanken() Interfaces Definition Ganz abstrakter Typ Keine Attribute und keine Methodenimplementierungen Notation wie Abstrakte Klasse evtl. zusätzlich Angabe des Stereotyps <<interface>> Beispiel Flugobjekt <<interface>> starten() fliegen(ziel) landen() Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-30 R O O T S

28 Stereotypen: Definition spezieller semantischer Kategorien Bisher nur Notationen für eine feste Menge von Konzepten Die Welt ist aber unendlich Stereotyp Hinweis auf semantische Kategorie für die es keine spezifische Notation gibt Ansatzpunkt für anwendungsspezifische Erweiterungen Anwendbarkeit Allgemein (Klassen, Variablen, Operationen, Beziehungen,...) Notation <<stereotyp>> oder graphisches Symbol, z.b. <<entity>> <<controller>> <<boundary>> <<interface>> <<selbst definierte Kategorie>> Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-31 R O O T S

29 Stereotypen: Beispiele Klasse mit Stereotypen <<entity>> Rechteck p1 : Punkt p2 : Punkt <<query>> fläche():real <<update>> bewege(delta:punkt) Rechteck p1 : Punkt p2 : Punkt <<query>> fläche():real <<update>> bewege(delta:punkt) Drei Äquivalente Darstellungen der Klasse PenTracker <<controller>> PenTracker PenTracker PenTracker Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-32 R O O T S

30 Objektdiagramme Objkte werden auch durch Rechtecke dargestellt, aber: Das Namensfeld einer Instanz ist unterstrichen und besteht aus: Einem Namen für die Rolle dieser Instanz Einem Doppelpunkt als Trenner Dem Typ der Instanz Man muss entweder die Rolle oder den Doppelpunkt und den Typ angeben Die Attribute werden zusammen mit ihren jeweiligen Werten angegeben. Eine anonyme Instanz von Tarif Eine benannte Instanz von Tarif :Tarif Sommertarif : Tarif zone2price = { { 1, 1.80}, { 2, 2.40}, { 3, 3.60} } Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-33 R O O T S

31 Klassendiagramm: Assoziationen Assoziationen definieren Beziehungen zwischen Instanzen von Klassen. Relationsname und Richtung in die er zu lesen ist. Hier: Person arbeitet-für Firma Rolle von Firma in Beziehung zu Person. Rolle von Person in Beziehung zu Firma. Firma Arbeitgeber * arbeitet-für Kardinalität / Multiplizität beliebig: * festes Intervall: 0..1 offenes Intervall: 5..* Arbeitnehmer * Person Die Multiplizität am jeweiligen Ende einer Assoziation gibt an, mit wie vielen Zielobjekten ein Quellobjekt in Beziehung stehen kann Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-34 R O O T S

32 Klassendiagramm: N zu M Assoziationen Assoziationen definieren Beziehungen zwischen Instanzen von Klassen. Die Multiplizität am jeweiligen Ende einer Assoziation gibt an, mit wie vielen Zielobjekten ein Quellobjekt in Beziehung stehen kann. Firma Arbeitgeber arbeitet-für Arbeitnehmer * * Person Dazu passendes Objektdiagramm hat mehrere Arbeitnehmer zeitarbeit: Firma eva : Person hat einen Job hat einen Arbeitnehmer ichag: Firma johan : Person hat mehrere Jobs hat keinen Arbeitnehmer briefkasten: Firma opa: Person hat keinen Job Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-36 R O O T S

33 Klassendiagramm: 1 zu 1 Assoziationen Assoziationen definieren Beziehungen zwischen Instanzen von Klassen. Die Multiplizität am jeweiligen Ende einer Assoziation gibt an, mit wie vielen Zielobjekten ein Quellobjekt in Beziehung stehen kann. Land 0..1 hat-hauptstadt 1 Stadt Dazu passendes Objektdiagramm nrw: Land Illegales Objektdiagramm bonn : Stadt dd : Stadt ist keine Hauptstadt ist Hauptstadt illegal: mehrere Hauptstädte nrw: Land dd : Stadt bayern : Land m: Stadt illegal: ist mehrfache Hauptstadt illegal: hat keine Hauptstadt takatuka: Land Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-37 R O O T S

34 Klassendiagramm: 1 zu N Assoziationen Assoziationen definieren Beziehungen zwischen Instanzen von Klassen. Die Multiplizität am jeweiligen Ende einer Assoziation gibt an, mit wie vielen Zielobjekten ein Quellobjekt in Beziehung stehen kann. Polygon 0..1 hat-eckpunkt 3..* Punkt Dazu passendes Objektdiagramm : Polygon Illegales Objektdiagramm : Punkt : Punkt : Punkt : Punkt : Punkt illegal: zu wenig Eckpunkte : Polygon : Punkt illegal: zu wenig Eckpunkte : Polygon : Punkt illegal: mehrfacher Eckpunkt illegal: zu wenig Eckpunkte : Polygon Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-38 R O O T S

35 Klassendiagramm: Aggregation Aggregation = ist Teil von -Beziehung Keine Aussage über Abhängigkeit des Teils vom Ganzen Teile dürfen in mehreren Ganzen enthalten sein Ihre Lebensdauer ist nicht von der des Ganzen abhängig Pfad * * {ordered} Segment Dazu passende Veranschaulichung der realen Welt B A C Rote Segmente sind Teil der Pfade BA und CA Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-39 R O O T S

36 Klassendiagramm: Aggregation Aggregation = ist Teil von -Beziehung Keine Aussage über Abhängigkeit des Teils vom Ganzen Teile dürfen in mehreren Ganzen enthalten sein Ihre Lebensdauer ist nicht von der des Ganzen abhängig Pfad * * {ordered} Segment Dazu passendes Objektdiagramm BA : Pfad CA : Pfad s7 : Segment s1 : Segment s6 : Segment s2 : Segment s3 : Segment s4 : Segment s5 : Segment Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-40 R O O T S

37 Klassendiagramm: Komposition Komposition = ist ausschließliches Teil von -Beziehung Lebensdauer des Teils endet mit Lebensdauer des Ganzen Beispiel: Abteilungen können ohne Firma nicht existieren Unterabteilung * Firma 1 1..* Abteilung 1 Hauptabteilung Dazu passende Veranschaulichung der realen Welt ABC GmbH Forschung Entwicklung Vertrieb F1 F2 F3 E1 E2 E3 V1 V2 V Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-41 R O O T S

38 Klassendiagramm: Komposition Komposition = ist ausschließliches Teil von -Beziehung Lebensdauer des Teils endet mit Lebensdauer des Ganzen Beispiel: Abteilungen können ohne Firma nicht existieren Unterabteilung * Firma * Abteilung 0,1 Hauptabteilung Dazu passendes Objektdiagramm Keine Aggregations- oder Kompositionsbeziehungen zu anderen Objekten: ABC: Firma Forschung: Abteilung Entwicklung: Abteilung Vertrieb: Abteilung F1: Abteilung F2: Abteilung F3: Abteilung E1: Abteilung E2: Abteilung E3: Abteilung V1: Abteilung V2: Abteilung V3: Abteilung Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-42 R O O T S

39 Assoziation, Aggregation, Komposition Spezialisierungen Aggregation ist spezielle Assoziation Komposition ist spezielle Aggregation Modellierung Alles was für Assoziationen gilt, gilt für die beiden anderen auch Im Zweifelsfall die allgemeinere Notation wählen und Intention durch zusätzliche Bedingungen explizit machen (Kardinalitäten, Constraints,...) Aggregation versus Assoziation Assoziation mit Kardinalitätsangaben und Constraints Komposition versus Aggregation Aggregation mit Kardinalitätsangaben und Constraints Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-43 R O O T S

40 Aggregation= Ist Teil von -Beziehung Modelliert Einheit eines "Ganzen" mit seinen "Teilen" Impliziert oft kaskadierende Operationen Operation auf Ganzem wird auch auf allen Teilen durchgeführt Beispiel 1: Verschiebung eines Rechtecks verschiebt alle seine Kanten Beispiel 2: Laden des Ganzen von Platte lädt alle seine Teile Impliziert oft Existenz-Abhängigkeit Teil existiert nicht ohne Ganzem Entspricht dem Kaskadierungsverhalten beim Löschen: Teile werden mit gelöscht oder an anderes Ganzes weitergegeben Impliziert oft Exklusivität Teil ist in genau einem Ganzen enthalten Mögliche semantische Kategorien (existenz-)abhängig, exklusiv (existenz-)abhängig, nicht exklusiv (existenz-)unabhängig, exklusiv (existenz-)unabhängig, nicht exklusiv

41 Assoziation: Die vier Kategorien exklusiv (nur in einem Ganzen) nicht exklusiv (in mehreren Ganzen) existenzabhängig (Propagierung der Löschoperation) 1 Spalte 1..* + explizite Angabe der Propagierungs-Semantik als Constraints (Seite 47) 1 Firma 1 * Abteilung Zeile 1 { } Zelle existenzunabhängig (keine Propagierung der Löschoperation)* * Sonderfall siehe Seite 48 Auto Reifen Proj. * * * Mitarb Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-45 R O O T S

42 Assoziation: Weitere Kategorien Aggregation und Komposition mit Kardinalität 0..1 Kardinalität 0 bedeutet hier: Teile können unabhängig von Ganzem erzeugt werden Sehr praxisrelevanter Fall: Vieles wir bottom-up produziert Kardinalität 1 bedeutet hier: Sobald die Teile einem Ganzen zugeordnet werden, sind sie exklusiv darin enthalten gerichtete Assoziation: nur eine Seite weiß von der anderen Seite und der Relation Entry element * x List Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-46 R O O T S

43 Bedingungen ( Constraints ) Bisher wurden nur besonders häufige Bedingungen modelliert, über Spezialnotationen (z.b. Komposition ) oder Kardinalitäten (z.b. 1..4) Das reicht oft nicht aus! Es gibt daher auch eine Notation für beliebige Bedingungen Angabe von Bedingung in geschweiften Klammern: { Bedingung } Bedingungssprache vordefinierte Eigenschaften: abstract, readonly, query, leaf, ordered, unique, set, bag, beliebige umgangssprachliche Formulierung Zeile 0,1 1..* Object Constraint Language Spalte 0,1 Kapitel Objektmodellierung { existenzabhängig } { existenzabhängig } Zelle 1..* Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-47 R O O T S

44 Bedingungen ( Constraints ): Angabe als Abhängigkeiten Manche Constraints geben nur eine Abhängigkeit an Beipiel: {existenzabhängig} -- Nomen est omen! Man kann sie daher auch als Abhängigkeitspfeile mit passendem Stereotyp modellieren Beispiel 1: Zellen sind existenzabhängig von Zeilen und Spalten Zeile Spalte 0,1 0,1 <<Existenzabhängigkeit>> <<Existenzabhängigkeit>> 1..* Zelle 1..* Achtung Der Pfeil gibt immer die Richtung der Abhängigkeit an, nicht die Richtung der Löschpropagierung! Beispiel 2 : Zutaten sind löschpropagierungsabhängig von Pizzen Pizza 0,1 <<Löschpropagierung>> 1..* Zutaten Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-48 R O O T S

45 Bedingungen ( Constraints ): Existenz- und Löschabhängigkeit Existenzabhängigkeit impliziert Löschpropagierung Zellen können nicht außerhalb von Zeilen und Spalten existieren Wenn eine Zeile gelöscht wird, werden alle Zellen dieser Zeile gelöscht! Zeile Spalte 1 1 <<Existenzabhängigkeit>> <<Existenzabhängigkeit>> Zelle Löschpropagierung impliziert aber keine Existenzabhängigkeit! Wenn die Pizza gegessen (also gelöscht ) wird, werden auch die Zutaten gegessen ( gelöscht )! Jedoch können die die Zutaten auch ohne der Pizza existieren! Pizza 1 <<Löschpropagierung>> Zutaten Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-49 R O O T S

46 Statisches Modell: Aggregation und Komposition Gemeinsames Beispiel Komposition Für Beziehung Polygon Punkt und Kreis Punkt weil man nicht möchte, dass der Mittelpunkt des Kreises auch Eckpunkt eines Polygons sein kann. Dann würde nämlich ein Verschieben des Kreises das Polygon verformen! Aggregation Für Beziehung Polygon Stil und Kreis Stil weil man gern möchte, dass anpassen eines gemeinsamen Stils alle Formen ändert die ihn benutzen {ordered} 3..* Punkt 1 Polygon * 1 farbe Stil 1 * Kreis radius istgefüllt Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-51 R O O T S

47 Denksportaufgabe Wie würden Sie die Beziehung einer Datei zu einem Ordner modellieren? Assoziation, Aggregation oder Komposition? Bedenken Sie: Die Datei ist zu jedem Zeitpunkt exklusiver Teil eines Ordners, kann aber in einen anderen Ordner verschoben werden Wenn der Ordner gelöscht wird, wird die Datei mit gelöscht.??? Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-52 R O O T S

48 Klassendiagramm: Vererbung "direkte" Darstellung Figur Linie Kurve Polygon "zusammengefasste" Darstellung Figur Linie Kurve Polygon Multiple Vererbung Eine Klasse mit mehreren Oberklassen Bsp: C++ Student studentische Hilfskraft Angestellter Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-53 R O O T S

49 Klassendiagramm: Vererbung Vererbung geerbte Methoden / Attribute im Diagramm der Unterklasse nicht wiederholen Overriding überschriebene Methoden im Diagramm der Unterklasse wiederholen field:t Super m(s:string) m(s:string, i:int ) Overloading alle verschiedenen Signaturen angeben auch überladene Methoden können in Untertypen überschreiben werden Sub1 otherfield:a m(s:string, i:int ) g() Sub2 m(s:string) f() Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-54 R O O T S

50 UML, statisches Modell: Generische Klassen Klassen mit Typ-Parameter C++: "Templates" Java: ab JDK 1.5 insert(t) remove(t) Set... T formaler Typ-Parameter Generische Klasse Gebundenes Element «bind» <Employee> EmployeeSet Wert für Typ-Parameter Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-55 R O O T S

51 UML, statisches Modell: Generische Klassen Klassen mit Typ-Parameter C++: "Templates" Java: ab JDK 1.5 insert(t) remove(t) Set... T formaler Typ-Parameter Generische Klasse Gebundenes Element kompaktere alternative Notation EmployeeSet = Set <Employee> Wert für Typ-Parameter Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-56 R O O T S

52 Statisches Modell: Interfaces Semantik Interfaces enthalten nur Methodensignaturen Notation Klassensymbol mit stereotyp <<interface>> im Namensfeld leeres Attributfeld kann weggelassen werden <<interface>> Hashable hash():integer <<interface>> Comparable isequal(string):boolean Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-57 R O O T S

53 Statisches Modell: Implementierungs- Beziehung Semantik Komponente / Klasse implementiert Interface Notation gestrichelter Vererbungs-Pfeil oder Lollipop String... isequal(string):boolean hash():integer <<bietet>> Hashable Comparable String... isequal(string):boolean hash():integer <<bietet>> <<interface>> Hashable <<interface>> Comparable Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-58 R O O T S

54 Statisches Modell: Braucht -Beziehung Semantik Klasse benötigt Interface Notation gestrichelter spitzer Pfeil ( Abhängigkeitspfeil ) + Stereotyp String... isequal(string):boolean hash():integer <<bietet>> Hashable Comparable <<braucht>> Hashtable String... isequal(string):boolean hash():integer <<bietet>> <<interface>> Hashable <<interface>> Comparable <<braucht>> Hashtable Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-59 R O O T S

55 Aktive Klassen / Objekte Aktive Klasse: Jede ihrer Instanzen ist ein eigener Thread. Notation UML 2.0: Klasse/Objekt mit doppeltem vertikalem Rand oder {active} Beispiel Bestellbestättigung Bestelungserfassung Rechnung * Zahlungsaufforderungs -UI Zahlungsanfragebearbeitung * * Rechnungsbearbeitung {active} 1 Zahlungsanweisungserstellung Zahlungsanfrage Zahlungsanfragebearbeitung, Rechnungsbearbeitung und Zahlungsanweisungserstellung sind aktive Klassen Hingegen sind z.b. Bestellerfassungen nur auf Anfrage aktiv Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-60 R O O T S

56 Paketdiagramme Bedeutung Gruppierung thematisch zusammengehöriger Klassen Darstellung Karteikarten, auf denen die dazugehörigen Klassen aufgemalt sind Referenz auf eine Klasse in einem anderen Package package::class Import aus anderem Package Gestrichelter Abhängigkeits-Pfeil mit stereotyp <<imports>> Kunden Bank Kunde Bank::Konto <<imports>> Konto Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-61 R O O T S

57 Kapitel 4: UML Kapitel Systementwurf Strukturdiagramme im Großen Komponentendiagramme Kompositionsübersichtsdiagramme Verteilungsdiagramme R O O T S

58 Kapitel 4: UML 4.4 Verhaltensmodellierung (Teil 1) Sequenzdiagramme Kommunikationsdiagramme Interaktionsübersichtsdiagramme R O O T S

59 Kapitel 4: UML Sequenzdiagramme Seite R O O T S

60 Sequenzdiagramm ( sequence diagram ) Visualisiert Nachrichten entlang einer vertikalen Zeitachse Modelliert Interaktion zwischen Akteuren und Objekten verschiedenen Objekten einem Objekt mit sich selbst sd Ticket Passenger selectzone() insertcoins() :TicketMachine Bietet Darstellung von Datenfluss Zeitpunkte und dauer Nebenläufigkeit Verzweigungen / Schleifen Filterungen / Zusicherungen pickupchange() pickupticket() Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-67 R O O T S

61 Sequenzdiagramm ( sequence diagram ) Akteure Wie im Use-Case-Diagramm Objekte Objektdiagramm-Notation für passive oder aktive Objekte Lebenslinie Zeitraum in dem das Objekt existiert Später: Explizite Notation für Objekt- Geburt und - Tod Aktivität / Aktivierung Zeitraum in dem das Objekt etwas tut Ausgelöst durch Nachricht bei passiven Objekten Thread bei aktiven Objekten sd Ticket Akteur Objekt Passenger :TicketMachine selectzone() Nachricht insertcoins() pickupchange() pickupticket() Lebenslinie Aktivität Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-68 R O O T S

62 Sequenzdiagramme: Kontroll- und Datenfluss Jeder Pfeil beginnt an der Aktivierung, welche die Nachricht gesendet hat Die Aktivierung an der der Pfeil endet beginnt direkt am Pfeilkopf Eine Aktivierung dauert (mindestens) so lange wie alle geschachtelten Aktivierungen Für synchrone Nachrichten erfolgen Rückgaben implizit am Ende einer Aktivierung Pfeile für Rückgaben werden nur benutzt, um den Datenfluss explizit zu machen sd Ticket :Passagier drücke() :ZonenKnopf : Tarif :Display preis(auswahl) Datenfluss Preis zeigepreis(preis) Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-69 R O O T S

63 Sequenzdiagramme (wichtige Elemente) UML 2.0 Interaktionspartner passives Objekt (aktiv nur als Reaktion auf Nachrichten) aktives Objekt (Prozess/Thread) rolle:typ rolle:typ Nachricht synchron (Aufrufender wartet auf Ende der Aktivierung) asynchron (Aufrufender sendet Nachricht und macht sofort weiter) m1 m2 Antwortnachricht ohne Ergebnis (bei synchronen Nachrichten meist weggelassen) mit Rückgabewert wert Zeiteinschränkung Absoluter Zeitpunkt Relativer Zeitpunkt Intervall at(12.00) after(12.00) { } Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-70 R O O T S

64 Sequenzdiagramme (wichtige Elemente) Objekt wird durch Nachricht erzeugt new UML 2.0 obj : Type Nachricht an sich selbst obj : Type Rekursiver Aufruf obj : Type Nachrichten ohne explizit modellierte Interaktionspartner lost found Zustandsinvariante Bedingung, die zu einem gewissen Zeitpunkt erfüllt sein muss obj : Type {p= 15} Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-71 R O O T S

65 Sequenzdiagramme: Kontrollstrukturen in UML 2 Kombinierte Fragmente sd MovieRental invoice() cus:customer :Rental :Movie Szenario: Ausdrucken einer Rechnung für Kunden eines Videoverleihs Alternative: Falls a Gesamtkosten drucken, falls b Bonuspunkte drucken Schleife: Gesamtkosten sind kosten aller Ausleihvorgänge (:Rental) Optionale Aktionen: Bonuspunkte für Altkunden anders berechnen Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-74 R O O T S

66 Sequenzdiagramme: Kontrollstrukturen in UML 2 Kombinierte Fragmente sd MovieRental invoice() Bedingung cus:customer trifft [a] zu, wird dies :Rental :Movie Interaktionsfragment ausgeführt alt [a] Schleife loop(1,*) totalcharge(cus) Alternative if-then-else price() getpricecode() [b] bonuspoints(cus) Optionale Interaktion if-then opt [old(cus)] getpricecode() Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-75 R O O T S

67 Sequenzdiagramme: Interaktionsfragmente Komplexere Kontrollstrukturen werden durch Operatoren auf Interaktionsfragmenten (Ausschnitte des Sequenzdiagramms) realisiert Verzweigungen und Schleifen Nebenläufigkeit und Ordnung Filterung und Zusicherung Operator Zweck alt Alternative Interaktionen if-then-else opt Optionale Interaktionen if-then break Ausnahme-Interaktion umgebendes Interaktionsfragment verlassen loop Iterative Interaktionen seq Sequentielle Interaktionen mit schwacher Ordnung (Default) strict Sequentielle Interaktionen mit strenger Ordnung par Nebenläufige Interaktionen critical Atomare Interaktionen ignore Irrelevante Interaktionen consider Relevante Interaktionen assert Zugesicherte Interaktionen neg Ungültige Interaktionen Anwendung siehe Beispiel auf der nächsten Folie Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-76 R O O T S

68 Sequenzdiagramm: Kalender-Beispiel Gemeinsamer Kalender sd Termin löschen À la Google-Kalender Man muss sich anmelden :Termin -Maske te[i] :Termin :Kalender Hier: Löschen eines Termins Erst anmelden b1: Benutzer ref sd Anmelden dann Terminanzeige dann Selektion des Termins und Löschen break melde Abbruch Abbrechen [ falsches Passwort ] Quelle UML@Work, Abbildung 4-46 zeige Kalender zeigekalender lösche(te[i]) lösche(te[i]) Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-77 R O O T S

69 Sequenzdiagramm: Kalender-Beispiel Was versteckt sich hinter der Referenz? Ein beliebiges dynamisches Diagramm Hier: Der Anmeldevorgang sd Anmelden b1: Benutzer :Termin -Maske te[i] :Termin :Kalender ref loop(1,3) [cond] Kombination von for- und do-until-schleife Wiederhole Fragment maximal 3 mal aber hör auf sobald cond erfüllt ist, sd Anmelden d.h. for (i=1..3) {...; if cond break;} loop (1,3) prüfe Passwort(pwd) anzeige (ergebnis) prüfe Passwort(pwd) ergebnis= prüfepaswort(pwd) [ richtiges Passwort ] Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-78 R O O T S

70 Sequenzdiagramme: Fazit Sequenzdiagramme repräsentieren Verhalten bezüglich Interaktionen. ergänzen die Klassendiagramme, welche die Struktur repräsentieren. sind nützlich, um das Verhalten eines Anwendungsfalls auf die beteiligten Objekte abzubilden beteiligte Objekte zu finden Verhalten präzise zu beschreiben Der Zusatzaufwand lohnt sich auf jeden Fall bei komplexen und unklaren Abläufen Aber: keine Zeit vergeuden, um Trivialitäten und Offensichtliches mit Sequenzdiagrammen zu modellieren Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-79 R O O T S

71 Kommunikationsdiagramm ( Communication diagram ) In UML1: Kollaborationsdiagramm Beschreibt Interaktion zwischen Objekten einschließlich struktureller Informationen (Beziehungen der Objekte) Comm Prüfen Sequenznummer nebenläufig Objekt mit Rolle : Typ te[t]:termin Selektor Sequenznummer sequentiell a: beginn b: dauer [te[t] kandidat]: kollidiertmit(kandidat) kandidat:termin 1.1: hatkollision(kandidat) tn[b]:teilnehmer 1.1.1* [für alle Termine te[t]]: prüfe(te(t)) 1* [für alle Teilnehmer tn[b]]:prüfe(tn[b]) Nachricht * Iteration * Nebenläufige Iteration [ ] Bedingung Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-81 R O O T S

72 Kommunikationsdiagramm ( Communication diagram ) Beziehungen im Kommunikationsdiagramm permanente Verbindungen: Assoziationen oder globale Variablen temporäre Verbindungen: Parameter oder lokale Variablen Comm Prüfen te[t]:termin a: beginn b: dauer [te[t] kandidat]: kollidiertmit(kandidat) kandidat:termin 1.1: hatkollision(kandidat) tn[b]:teilnehmer 1.1.1* [für alle Termine te[t]]: prüfe(te(t)) 1* [für alle Teilnehmer tn[b]]:prüfe(tn[b]) Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-82 R O O T S

73 Kommunikationsdiagramm Beschreibt Interaktion zwischen Objekten Zeigt auch strukturelle Informationen (Beziehungen der Objekte) Zeitlicher Verlauf wird durch Nummern angegeben Syntax: Nummer : Nachricht Beispiel: 1 : foo, 2 : bar zuerst wird foo gesendet, dann bar Nummer zeigt sequenzielle oder parallele Verarbeitung Sequentielle Bearbeitung Zahlen 1.1, 1.2 sind sequentielle Teilabläufe von 1 Nebenläufige Bearbeitung Namen 1.a, 1.b sind nebenläufigeteilabläufe von 1 Iteration wird nach der Sequenznummer angegeben: Sequentiell: 2.3 * [i=1..n]: nachricht(i) Nebenläufig: 2.3 * [i=1..n]: nachricht(i) Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-83 R O O T S

74 Vergleich zu Sequenzdiagramm Kommunikationsdiagramme sind schwieriger Zeitliche Abfolge muss aus Nummerierung rekonstruiert werden Bei Änderungen muss viel neu Nummeriert werden Gute Werkzeugunterstützung ist daher essentiell Kommunikationsdiagramme sind einfacher Strukturelle Informationen zusätzlich darstellbar Objekte können überall platziert werden Weniger Überkreuzungen übersichtlicher Leichter kollaborativ am Whiteboard zu erstellen

75 Kapitel 4: UML 4.5 Verhaltensmodellierung (Teil 2) Aktivitätsdiagramme Interaktionsübersichtsdiagramme Zustandsdiagramme R O O T S

76 Kapitel 4: UML Aktivitätsdiagramme Seite R O O T S

77 Aktivitätsdiagramme Eine Aktion ist ein elementarer Arbeitsschritt atomar (d.h. Effekte werden bei Unterbrechung rückgängig gemacht) Eine Aktivität spezifiziert den Kontroll- und Datenfluss zwischen Aktionen Parallelisierung Aktivität (Beliebige Abarbeitungs- Termin vereinbaren reihenfolge) Kontaktperson auswählen Aktion Person ausgewählt Synchronisierung Teilnehmer informieren Ende Start Vereinigung Terminvorschlag finden [Anzahl Teilnehmer ohne Kollision <90%] Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-87 R O O T S [else] Bedingung Entscheidung

78 Aktivitätsdiagramme: Tokenbasierte Semantik Operationales Modell: Token, die Abläufen entsprechen, fließen durch das Diagramm ab dem Startknoten. Parallelisierung: Auf jeder Ausgangskante fließt je ein Token weiter. Synchronisation: Auf jeder Eingangskante muss ein Token ankommen. Vereinigung: Jedes ankommende Token wird weitergeleitet. Entscheidung: Token fließt nur auf der Ausgangskante weiter, deren Bedingung wahr ist. Termin vereinbaren Kontaktperson auswählen Person ausgewählt [else] Teilnehmer informieren Terminvorschlag finden [Anzahl Teilnehmer ohne Kollision <90%] Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-88 R O O T S

79 Aktivitätsdiagramme: Tokenbasierte Semantik Mehrfache gleichzeitige Aufrufe Ein Aktivitätsdiagramm kann gleichzeitig mehrfach aufgerufen werden Jeder Aufruf bringt Tokens mit neuer Farbe hervor Semantik mehrfache Prozesse (unabhängig, mit eigenem Adressraum) default mehrfache Threads (im gleichen Adressraum) falls <<singleexecution>> Beispiel: Der rote Ablauf ist schon weiter fortgeschritten als der Blaue Termin vereinbaren Kontaktperson auswählen Person ausgewählt [else] Teilnehmer informieren Terminvorschlag finden [Anzahl Teilnehmer ohne Kollision <90%] Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-89 R O O T S

80 Ablaufende versus Endzustand Ablaufende Ende eines Ablaufs (andere können weiterlaufen) Endzustand Bildlich: Nur der Ablauf eines einzigen Tokens wird beendet Ende aller Abläufe, die gerade das Diagramm durchlaufen Bildlich: Wenn ein Token den Endzustand erreicht, werden die Abläufe aller anderen Token im selben Prozess mit beendet (egal welche Farbe sie haben) Termin vereinbaren betrifft nur Abläufe im selben Prozess / Adressraum Kontaktperson auswählen Person ausgewählt Teilnehmer informieren [else] Terminvorschlag finden [Anzahl Teilnehmer ohne Kollision <90%] Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-90 R O O T S

81 Endzustand versus Ablaufende: Beispiel Drucken, Adressieren und Versenden von Einladungen Wenn eine Einladung gedruckt ist, fließen 2 Token weiter, eines auf jeder Ausgangskante (implizite Parallelisierung) Die Einladung wird daher als Nächstes adressiert und es werden gleichzeitig weitere Einladungen gedruckt Wenn die letzte Einladung gedruckt ist, verschwindet das nach unten geflossene Token im entsprechenden Ablaufende Einladung versenden Einladung drucken Einladung adressieren [alle Einladungen adressiert] Einladungen abschicken [else] [else] [alle Einladungen gedruckt] Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-91 R O O T S

82 Endzustand versus Ablaufende: Beispiel Drucken, Adressieren und Versenden von Einladungen Wenn eine Einladung adressiert ist und es nicht die letzte war, verschwindet das nach rechts gewanderte Token in dem entsprechenden Ablaufende. Einladung versenden Einladung drucken Einladung adressieren [alle Einladungen adressiert] Einladungen abschicken [else] [else] [alle Einladungen gedruckt] Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-92 R O O T S

83 Endzustand versus Ablaufende: Beispiel Drucken, Adressieren und Versenden von Einladungen Sonst werden alle (gedruckten und adressierten) Einladungen gemeinsam verschickt und die gesamte Aktivität ist damit beendet. Das allerletzte Token verschwindet anschließend im Endzustand. Hier die Momentaufnahme während des Verschickens von 5 gedruckten und adressierten Einladungen Einladung versenden Einladung drucken Einladung adressieren [alle Einladungen adressiert] Einladungen abschicken [else] [else] [alle Einladungen gedruckt] Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-93 R O O T S

84 Aktivitätsdiagramme Ablauforientierte Notation basierend auf BPEL (Business Process Engineering Language) und Petri- Netzen Auch für nicht objekt-orientierte Systeme Aktivitäten sind unabhängig von Objekten Anwendbar auch auf Geschäftsprozesse, Funktionsbibliotheken, Elementare Konzepte Aktivität = benanntes Verhalten Aktion = atomare Aktivität (einzelner Arbeitsschritt) Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-94 R O O T S

85 Aktivitätsdiagramme Aktivitätsdiagramm Graph bestehend aus Aktivitätsknoten und Aktivitätskanten Aktivitätsknoten Kontrollknoten: Start, Alternative, Parallelisierung, Synchronisation, Ende Objektknoten: Parameter, Puffer, Datenbanken Aktionsknoten: Atomare, vordefinierte Aktionen Aktivitätskanten Kontrollfluss: Objektfluss: Verbindungen von Aktions- und Kontrollknoten Verbindungen von Objektknoten untereinander (direkt oder via Kontrollknoten aber nie nur Kontrollknoten untereinander) Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-95 R O O T S

86 Aktivitätsdiagramme Aktivitätsknoten Aktivität Name der Aktivität Kontrollknoten Start- und Endknoten Start Aktivitätsende (Ende aller Abläufe) Ablaufende (Ende eines bestimmten Ablaufs) Alternative Abläufe Entscheidungsknoten Vereinigungsknoten Nebenläufige Abläufe Parallelisierungsknoten Synchonisierungsknoten Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-96 R O O T S

87 analog für Aktivitäten Aktivitätsdiagramme Aktivitätsknoten Objektknoten Temporäre Puffer Persistente Puffer Parameter von Aktivitäten Parameter von Aktionen (Pins) Eingabeparameter Explizit: Pfeil im Objektknoten hin zur Aktivität / Aktion Implizit: Parameter links oder oben Ausgabeparameter Explizit: weg von der Implizit: rechts oder unten <<centralbuffer>> To-dos <<datastore>> Kontakte Aktivität Aktion Aktion Aktion Aktivitätsparameter überlappen den Rand! Pins liegen außen! Explizit Implizit Art (= Stereotyp) Name Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-97 R O O T S

88 Aktivitätsdiagramme Kanten Kontrollfluss Durchgezogene spitze Pfeile zwischen Aktivitäten oder Aktionen Direkt via Kontrollknoten nie zu Objektknoten Datenfluss Durchgezogene spitze Pfeile zwischen Objektknoten Direkt via Kontrollknoten nie zu Aktivitäts- / Aktionsknoten A1 A1 A1 A1 A1 A1 A2 A2 A3 A2 A2 A2 A3 A Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-98 R O O T S

89 Aktivitätsdiagramme Kanten An Kanten können immer Bedingungen stehen Auch an Kanten aus einem Startknoten Token fließt erst dann durch die Kante, wenn die Bedingung wahr ist / wird Aus einem Aktivitäts- / Aktionsknoten können mehrere Kanten heraus führen Implizite, potentielle Parallelität sofern nicht durch gegenseitig exklusive Bedingungen ausgeschlossen Dr. G. Kniesel Vorlesung Softwaretechnologie Seite 4-99 R O O T S

90 Aktivitätsdiagramme Aktionen Aktion = atomare Aktivität Atomar = kann unterbrochen werden, macht dann aber jegliche Effekte rückgängig 44 vordefinierte Aktionen in 4 Kategorien Alle sprachunabhängig definiert. Sonderfall: OpaqueAction als Hinweis auf Aktion die in einer bestimmten Implementierungssprache definiert ist Kommunikationsbezogenen Aktionen sendobjectaction, sendsignalaction Objekt oder Signal an Empfänger senden asynchron, Ergebnis wird ignoriert Notation: Blockpfeile Informiere Teilnehmer Für die meisten Aktionen gibt es lediglich textuelle Stereotypen (keine eigene graphische Notation) Dr. G. Kniesel Vorlesung Softwaretechnologie Seite R O O T S

91 Aktivitätsdiagramme Partitionen Partition Benutzer Kalender Gruppierung von Teilen eines Aktivitätsdiagramms Gruppierungskriterium ist beliebig Notation Im Beispiel: Zugehörigkeit der Aktionen zu gewissen Klassen Schwimmbahnen / Swimlanes BenutzerID prüfen [ok] Termin anlegen [else] Termin [erzeugt] <<datastore>> Benutzer Termin Termin Teilnehmer auswählen Eckdaten des Termins erfassen Kollisionen prüfen Dr. G. Kniesel Vorlesung Softwaretechnologie Seite R O O T S

92 Interaktionsübersichtsdiagramm ( Interaction overview diagram ) Modelliert Kontrollfluss zwischen verschiedenen Interaktionsabläufen Reihenfolge und Bedingungen intover Termin erfassen sd PrüfePasswort b1: Benutzer loop(1,3) prüfe Passwort(pwd) :Termin- Maske prüfe Passwort(pwd) :CALEN- DARIUM [richtiges Passwort] Siehe sd Anmelden Ist im Prinzip ein Aktivitätsdiagramm das statt Aktionen Interaktionsdiagramme als Knoten enthalten kann Auch nur Referenzen auf Interaktionsdiagramme möglich ( ref ) anzeige (ergebnis) ref Eckdaten des Termins erfassen ergebnis= prüfepaswort(pwd) ref Teilnehmer erfassen ref Notifikationen erzeugen Sichten aktualisieren Dr. G. Kniesel Vorlesung Softwaretechnologie Seite R O O T S

93 Kapitel 4: UML Zustandsdiagramme Seite R O O T S

94 Zustandsdiagramm Beispiel LCD-Uhr Struktur 1 Display 2 Knöpfe 1 Batterie Verhalten Knopf 1 drücken startet Stunden-Einstellung Jeder weitere Druck schaltet weiter zu Minuten, Sekunden, Stunden,. Knopf 2 drücken erhöht den Wert des aktuell einzustellenden Elementes. Beide Knöpfe drücken beendet die Einstellung Dr. G. Kniesel Vorlesung Softwaretechnologie Seite R O O T S

95 Zustandsdiagramm Beispiel LCD-Uhr Beschreiben das dynamische Verhalten eines Objektes als endlicher Automat Benanntes Diagramm Startzustand Uhr Ereignis button1&2pressed Blink Hours button2pressed Increment Hours Transition button1&2pressed Blink Minutes button1pressed button2pressed Increment Minutes Zustand button1pressed Stop Blinking button1&2 Pressed Blink Seconds button2pressed Increment Seconds Endzustand Dr. G. Kniesel Vorlesung Softwaretechnologie Seite R O O T S

96 Zustandsdiagramm Bestellungsbearbeitung Bestellung Ereignis [Bedingung] / Aktion Start-Zustand Zustand [nicht alle Posten geprüft] / hole nächsten Posten Prüfen [alle Posten geprüft && manche nicht verfügbar] Neue Ware erhalten [Posten nicht verfügbar] do / prüfe Verfügbarkeit Warten [alle Posten geprüft && verfügbar] Ausliefern do / ausliefern Ereignis / Aktion Transition Eigentransition ( self-transition ) Geliefert Dr. G. Kniesel Vorlesung Softwaretechnologie Seite R O O T S

97 Zustandsdiagramm Bestellungsbearbeitung Mit Abbruch Bestellung [nicht alle Posten geprüft] / hole nächsten Posten Prüfen [alle Posten geprüft && manche nicht verfügbar] do / prüfe Verfügbarkeit [alle Posten geprüft && verfügbar] Ausliefern do / ausliefern Neue Ware erhalten [Posten nicht verfügbar] Warten Abbruch Abbruch Abbruch Abgebrochen Geliefert Dr. G. Kniesel Vorlesung Softwaretechnologie Seite R O O T S

98 Zustandsdiagramm Bestellungsbearbeitung mit Abbruch Geschachtelt Bestellung Oberzustand ( superstate, complex state ) Aktiv [nicht alle Posten geprüft] / hole nächsten Posten Prüfen [alle Posten geprüft && manche nicht verfügbar] do / prüfe Verfügbarkeit [alle Posten geprüft && verfügbar] Ausliefern do / ausliefern Neue Ware erhalten [Posten nicht verfügbar] Warten Gruppentransition Unterbricht alle laufenden Aktionen des Quellzustandes und all seiner Unterzustände Abbruch Abgebrochen Geliefert Dr. G. Kniesel Vorlesung Softwaretechnologie Seite R O O T S

99 Zustandsdiagramm Nebenläufig, mit impliziten Übergängen auf und von Implizite Parallelisierung Implizite Transition von Außen in jeden der parallelen Startzustände Implizite Synchronisation Implizite Transition von den parallelen Endzuständen zum nächsten äußeren Zustand erst wenn alle parallelen Endzustände erreicht sind. canceled Abgebrochen Aktiv Warten Gruppentransitionen Prüfen Ausliefern Geliefert Autorisierung [ok] Autorisiert Einzeltransition [fehlgeschlagen] Abgelehnt Dr. G. Kniesel Vorlesung Softwaretechnologie Seite R O O T S

100 Zustandsdiagramm Nebenläufig, mit expliziter Parallelisierung / Synchronisierung Explizite Parallelisierung: Quellzustände außerhalb, Zielzustände in verschiedenen parallelen Unterbereichen Zielzustände beliebig (müssen nicht Startzustände sein) Explizite Synchronisation: Zielzustände außerhalb, Quellzustände in verschiedenen parallelen Unterbereichen Quellzustände beliebig (müssen nicht Endzustände sein) Aktiv Warten canceled Abgebrochen Prüfen Ausliefern Geliefert Autorisierung [ok] Autorisiert [authorization failed] Abgelehnt Dr. G. Kniesel Vorlesung Softwaretechnologie Seite R O O T S

101 Zustandsdiagramm Unterautomat Auktion Aus dem Aktivitätsdiagramm bekannte Kontrollflussnotation: Parallelisierung, Synchronisation, Entscheidung und Vereinigung Auktionshaus Auktion Bieten Gebot erwarten Gebot abgeben Gebot überprüfen [Gebot gültig] Gebot akzeptieren [Gebot abgelehnt, weitere Gebote] Kreditwürdigkeit prüfen Gekauft Kreditwürdigkeit prüfen [Prüfungen positiv] Identität prüfen [Prüfungen negativ] Dubioser Kunde Dr. G. Kniesel Vorlesung Softwaretechnologie Seite R O O T S