Modul Software Komponenten 17 UML Diagramme Martin Jud
Quelle: Scott Hawker, University of Alabama (angepasst) Modelle und UML Diagramme Requirements (Use Case) Model Analysis Model Design Model Deployment Model Implementation Model Test Model Use Case Diagrams Class and Object Diagrams Component Diagrams Deployment Diagrams Package Diagrams Sequence Diagrams Statechart Diagrams Activity Diagrams HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 2
übersetzt aus: Introduction into UML von Martin Kropp, 2001 by SWEED Elemente eines UseCases Akteur (Actor) Ein externes System (meist der Nutzer), das mit dem betrachteten System im Rahmen des Anwendungsfalls interagiert. Szenario (Scenario) Ein konkreter Ablauf des Anwendungsfalls (instance) Ein Standardszenario, mehrere Varianten. Beziehungen (Relations) Zwischen Akteur und UseCase... oder zwischen verschiedenen Anwendungsfällen HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 3
Übersetzt aus Vorlesungsunterlagen von Scott Hawker, University of Alabama Anwendungsfallmodell erarbeiten Ziele Systemgrenzen festlegen (was gehört zum System, was ist Teil der Umgebung) Übersicht über die Akteure und ihre Anwendungsfälle Begriffe / Terminologie der Anwendung erfassen (Glossar) Quellen Stakeholders (Kunden, Nutzer, Partner) Business/Domain Modell, Kundenanforderungen Vorgehen Akteure suchen Anwendungsfälle suchen Jeden Anwendungsfall beschreiben Das Anwendungsfallmodell als ganzes beschreiben (incl. Glossar) HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 4
Übersetzt aus Vorlesungsunterlagen von Scott Hawker, University of Alabama Akteure erfassen Beispiele für Akteure (Rollen): Bearbeiter/innen von Geschäftsfällen Personen / Systeme die Anfragen auslösen oder Entscheide fällen externe Systeme System-Wartung und -Support Kriterien Es muss mindestens einen Nutzer geben, der Akteur-Rolle spielt oder den Akteur anstösst Die Rollen sollen sich möglichst nicht überschneiden Beschreibung Name des Akteurs (Rollenbezeichnung) Zweck des UseCases; Erwartungen des Akteurs an das System; Leistung die das System dem Akteur erbringt. HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 5
Übersetzt aus Vorlesungsunterlagen von Scott Hawker, University of Alabama Anwendungsfälle ermitteln Ein UseCase liefert ein nützliches Ergebnis für den Akteur, z.b. Anwendungsfälle für Rollen im Business- bzw. Domain-Modell Geschäftsobjekte (erzeugen, verändern, löschen ) Ereignisse ( Umwelt System oder System Umwelt) das Hoch- und Runterfahren des Systems bzw. für die Wartung Namensgebung: Verb (+ Substantiv) Interaktion (+ Ergebnis) Abgrenzung Zeitliche Entkoppelung Andere Datenbenützung Iterativ herantasten ( Architekturentwurf) HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 6
2001 by SWEED, Martin Kropp UseCase Diagramm Register for Course Customer Request for Information Relationship Billing Actor Send Comment Use Case System Boundary HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 7
1999 by oose.de GmbH, Hamburg UseCase Beschreibung Jeder UseCase wird beschrieben durch: einen eindeutigen Namen, möglichst Substantiv + Verb einen kurzen Erläuterungstext von ca. 2-20 Zeilen eine Liste mit den beteiligten Akteuren Benennung wichtiger Auslöser / Vorbedingungen Benennung wichtiger Ergebnisse / Nachbedingungen Benennung wichtiger Dokumente und Ansprechpartner eine Beschreibung der einzelnen Ablaufschritte mit: Namen, möglichst Substantiv + Verb Stichwortartige Erläuterung HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 8
Adapted from SWEED, Martin Kropp Beziehungen zwischen UseCases <<include>> Teile die in mehreren UseCases vorkommen, können in einen eigenen UseCase ausgelagert und mit <<include>> wieder eingebunden werden. <<extend>> erlaubt einen UseCase an einem festgelegten ExtensionPoint mit einem andern UseCase zu erweitern wenn eine bestimmte Bedingung erfüllt ist. Generalisierung / Spezialisierung Mittels Vererbung lässt sich das UseCase Modell hierarchisch strukturieren, dabei werden Abläufe und Akteur-Beziehungen vererbt. Für Beziehungen zwischen UseCases gilt: weniger ist mehr! HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 9
2001 by SWEED, Martin Kropp <<include>> Customer <<include>> Browse Course Catalog <<include>> Register for Course Request for Information <<include>> Course Registration Enter Personal Data <<include>> Billing Send Comment HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 10
2001 by SWEED, Martin Kropp Vererbung und <<extend>> Base Use Case Specialized Use Case Spezialisierung / Generalisierung Extending Use Case <<extend>> Base Use Case extensionpoint1 extensionpoint2 Extension HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 11
Adapted from SWEED, Martin Kropp Aktivitätsdiagramm Zweck Beschreibung von Geschäftsprozessen Beschreibung von UseCase Szenarien Modellierung paralleler Abläufe Aktivitätsdiagramme wurden aus Fluss- / Event-, SDL- und Zustandsdiagrammen in UML übernommen und weiter entwickelt. Aktivitätsdiagramme werden auch von Personen ohne spezielle Informatikkenntnisse gut verstanden und sind deshalb äusserst hilfreich in der Analyse. HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 12
2001 by SWEED, Martin Kropp Aktivitätsdiagramm Grundelemente Start Activity Browse Course Catalog Guard Select Course Info Branch Enter Personal Data Confirm Registration [data correct] End [else] Update Course Send Email Print Bill HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 13
Aus Objektorientierte Geschäftsprozessmodellierung, Oestereich et. al. 2003 dpunkt Verlag Verzweigung und Aufteilung HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 14
aus der UML Superstructure Specification,2.0 2004 OMG Parallele Abläufe Partitionen HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 15
Aus Objektorientierte Geschäftsprozessmodellierung, Oestereich et. al. 2003 dpunkt Verlag Verfeinernde Zerlegung Eine Aktivität kann in einem andern Aktivitätsdiagram weiter verfeinert werden. Icon Natürlich muss die Verfeinerung gleich viele Start- und Endpunkte haben, wie die abstrakte Aktivität Ein- und Ausgänge besitzt. Aktivitäten mit Unteraktivitätsmodellen können durch ein kleines ActivityDiagram Icon gekennzeichnet werden. HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 16
Aus Die UML 2.0 Kurzreferenz für die Praxis von B.Oestereich, 2004 Oldenbourg-Verlag Zeitereignisse, Signale & Unterbrechung Signal senden erfolgt im Fluss, dieser wird davon nicht unterbrochen Signal empfangen kann ebenfalls im Fluss erfolgen (Synchronisation) oder aber isoliert in einem unterbrechbaren Bereich: Symbole: Alle Aktivitäten im Unterbr.- Bereich werden abgebrochen HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 17
Aus der Vorlesung Softwareengineering von Jörg Hofstetter HTA Luzern Objektknoten und Objektfluss ObjectNode ObjectFlow Rechnung schicken Rechnung Zahlung ausführen Rechnung schicken verändert (erstellt) die Rechnung, diese wird zu Zahlung ausführen übertragen. Rechnung schicken Rechnung Rechnung Zahlung ausführen Alternative 1 Pin Rechnung Rechnung schicken Zahlung ausführen Alternative 2 HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 18
aus der UML Superstructure Specification,2.0 2004 OMG DataStore Zentraler Speicherknoten für nicht-transiente Daten. Bewahrt alle einkommenden Daten auf. DataStore Einstellung «datastore» Personal Datenbank {weight=all} Nur Neuangestellte Review der Angestellten jährlich Angestellte einteilen TimeEvent Action HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 19
Aus Objektorientierte Geschäftsprozessmodellierung, Oestereich et. al. 2003 dpunkt Verlag Aktivitätsbeschreibung HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 20
Quelle: Karl Rege, ZHAW Klassendiagramm: Beziehungen Assoziation benutzt-beziehung Klasse_1 Klasse_2 Aggregation & Komposition hat-beziehung Klasse_1 Klasse_2 Generalisierung ist-beziehung Klasse_1 Klasse_2 HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 21
1998 by OBJEKTspektrum, Günter Wahl Beispiel Geldautomat Das Klassendiagramm beschreibt die statische Struktur der Objekte in einem System sowie ihre Beziehungen untereinander. HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 22
adapted from SWEED, Martin Kropp (ergänzt) Elemente im Klassendiagramm «stereotyp» Name {property} Attributs Operations Klasse Object:Class Attribut1 = value1 Objekt Generalisierung Assoziation Aggregation Komposition 0..1 0..* Arb.geber Arb.nehmer arbeitet bei Kardinalität / (multiplicity) Rollen Navigierbarkeit Name und Leserichtung HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 23
Quelle Karl Rege, ZHAW Generalisierung: ist-beziehung Klassen können auch durch Spezialisierung von allgemeineren Oberklassen hervorgehen. Generalisierung wird meist durch Vererbung implementiert Notation Beispiel Oberklasse Motorfahrzeug Unterklasse Auto Motorrad Implementation von Interfaces wird durch gestrichelte Linie dargestellt HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 24
Assoziationen Die Assoziation stellt eine allgemeine Beziehung zwischen zwei Klassen dar, über die Realisierung wird dabei nichts ausgesagt. Die Aggregation ist eine besondere Assoziation, die durch eine Raute an der Linie dargestellt wird. Sie gibt an, dass z.b. die Klasse Kartenleser in der Klasse Geldautomat "enthalten" ist (Ist-Teil-von-Beziehung). Die Komposition ist eine stärkere Form der Aggregation, die durch eine ausgefüllte Raute dargestellt wird. Bei der Beziehung Komposition handelt es sich um ein physisches enthalten sein. HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin 1998 Judby OBJEKTspektrum, Günter Wahl 25
Assoziation Aggregation Komposition allgemeine Beziehung zwischen Klassen benutzt wenn man "besteht aus" sagen kann hat Bremse Spezialfall der Aggregation hat exklusiv Bremse ( immer 1 ) Bremskraftregler Sensor meldet blockiert 4 Bremsscheibe Bremsbelag Meist als Zeiger implementiert (Java Objektreferenz) Name optional Unterschied zur Benutz-Beziehung (Assoziation) oft unklar Teile haben die gleiche Lebensdauer wie das Aggregat HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud nach Karl Rege, ZHW 26
Quelle: Karl Rege, ZHAW Assoziation: benutzt-beziehung Modelliert eine allgemeine Beziehung zwischen Klassen Land Name hat zur Hauptstadt Stadt Name Bremskraftregler Role Name Navigability Multiplicity meldet blockiert 2 Sensor Assoziation = Menge aller Verbindungen zwischen den Objekten der beteiligten Klassen Meist als Zeiger implementiert (Java Objektreferenz) Assoziations-Name / -Rolle / -Navigierbarkeit / -Kardinalität optional HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 27
von Jörg Hofstetter, HSLU T&A (Nicht-) Navigierbarkeit Neu: Nicht-Navigierbarkeit kann explizit ausgedrückt werden. Wie bisher: navigierbares Ende markiert durch Pfeilspitze. Bestellung * 1 Preisliste Bedeutung: Von einem Preisliste-Objekt kann nicht auf eine Bestellung geschlossen werden Bedeutung: Jedes Bestell-Objekt hat einen eindeutigen Bezug zu einer Preisliste HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 28
Quelle: Karl Rege, ZHAW Aggregationen: hat-beziehung Unterschied zur Benutz-Beziehung (Assoziation) oft unklar Hat-Beziehung, wenn man "besteht aus" sagen kann Dokument hat mehrere Absätze: besteht aus mehreren Absätzen Ein Land hat eine Hauptstadt: besteht aber nicht aus ihr Echte "ist enthalten" Beziehung, im Gegensatz zu Assoziation, die eine "steht in Verbindung mit" Beziehung ist Notation Beispiel Klasse_1 Bremse Klasse_2 Bremsscheibe HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 29
Quelle: Karl Rege, ZHAW Komposition: hat-exklusiv-beziehung Eigenschaften ist ein Spezialfall der hat-beziehung Unterscheidung zur hat-beziehung nicht immer einfach drückt stärkere Bindung als hat-beziehung aus Unterscheidungsmerkmal: Teile haben die gleiche Lebensdauer Notation Beispiel Bremse Bremsbelag 4 HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 30
Quelle: Karl Rege, ZHAW Kardinalität von Assoziationen A B (keine Aussage zur Kardinalität) 2 3 Jedes A ist mit 3 B verbunden A B Jedes B ist mit 2 A verbunden A 2..4 B Jedes A ist mit 2.. 4 B verbunden A 0..1 B Jedes A ist mit 0..1 B verbunden A * B Jedes A ist mit 0.. B verbunden HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 31
von Jörg Hofstetter, HSLU T&A DataFlow Firma Lohn «flow» Association Angestellte Information Item Firma Arbeit Lohn Angestellte Connector :Firma Arbeit Lohn :Angestellte Port HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 32
2001 by SWEED, Martin Kropp Attribute und Methoden Attribute Bestimmen die Struktur der Klasse Die aktuellen Werte der Attribute definieren den Zustand eines Objektes. Methoden Bestimmen das Verhalten Objekte einer Klasse Die Funktionalität die Objekten einer Klasse zur Verfügung steht From the conceptual level, a Person s name attribute, indicates that a Person has a name. So there is no difference between attributes and associations at the conceptual level. At the specification level, the attributes indicate, that the Person object can give you the name and allows you to set the name. On the implementation level, the attribute specifies that the Person has a field (or data member, or instance variable) for its name. HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 33
Sichtbarkeit, visibility Die Visibility kann vor dem Namen eines Attributes bzw. einer Methode mit folgenden Symbolen angegeben werden: + (public) wer die Klasse sieht, sieht das Element # (protected) in der Klasse und ihren Subklassen ~ (package)* im gleichen Paket wie die Klasse (private) nur in der Klasse selbst Vollständige UML Syntax für Methoden: visibility name(parameterlist): return-type-expression {propertystring} HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 34
2001 by SWEED, Martin Kropp Interfaces CourseReader <<interface>> DataInput Realization DataInputStream Interface-Klassen haben keine Attributes und keine implementierten Methoden, UML hat einen vordefinierten Stereotyp für interfaces. HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 35
2001 by SWEED, Martin Kropp Abstrakte Klassen Dependency Text Editor Window {abstract} Abstrakte Klassen können sowohl Attribute als auch Methoden- Implementationen haben. Darstellung mittels {abstract} Constraint oder mit kursiv geschriebenen Klassennamen HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 36
von Jörg Hofstetter, HSLU T&A Aktive Klasse : Zeigt an, dass ein Objekt dieser Klasse aktiv ist. Aktives Objekt: hat eigenen thread of control. HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 37
2001 by SWEED, Martin Kropp Elemente eines Sequenzdiagramms aregistration: Form aregistration: Manager Object acourse: Course register(joe, acourselist) Message Condition acust = getcustomer(joe) [not acust] a Cust = new(joe) Creation Self Delegation Joe: Customer Iteration *[for all courses] addparticipant(acust) numpart Return Activation Box delete() Deletion HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 38
sinngemäss nach: Scott W. Ambler, www.modelingstyle.info Objekte erzeugen, Rückgabewerte, Synchron/Asynchron aregistration: Manager Joe: Customer aregistration: Manager acourse: Course aregistration: Manager acourse: Course <<create>> addparticipant(acust) addparticipant(acust) aregistration: Manager numpart Return numpart aregistration: Manager acourse: Course aregistration: Manager acourse: Course Joe: Customer addp(acust): numpart addparticipant(acust) Return HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 39
Aus den UML-2 Unterlagen von Jörg Hofstetter, HTA Luzern UML 2: Interaktion und Fragment :System :Credit Card System :Gast Bereit für Reservation Zahlungsinfo angeben meineinfo(zahlungsinfo) Interaction Fragment Operator ref Kreditkarte prüfen(zahlungsinfo) alt opt critical neg loop seq par alt [Prüfung = OK] guard Reservation ok [else] Reservation fehlgeschlagen create ReservationsNr :Reservation Separator HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 40
2001 by SWEED, Martin Kropp Package Diagram Package Registration UI Registration Application Domain Courses AWT Dependency Persons Stereotype <<global>> Common Constraint Database Interface {abstract} Oracle SQL Server HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 41
2001 by SWEED, Martin Kropp Darstellung der Modul-Abhängigkeiten View Notification Message Queries and Updates Controler User Input Model Edit Model-View-Controller HSLU T&A, 16.11.2008 Modul SWK - 17-UML Diagramme - Martin Jud 42