Modul Software Komponenten 17 UML Diagramme. Martin Jud

Transkript

1 Modul Software Komponenten 17 UML Diagramme Martin Jud

2 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, Modul SWK - 17-UML Diagramme - Martin Jud 2

3 ü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, Modul SWK - 17-UML Diagramme - Martin Jud 3

4 Ü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, Modul SWK - 17-UML Diagramme - Martin Jud 4

5 Ü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, Modul SWK - 17-UML Diagramme - Martin Jud 5

6 Ü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, Modul SWK - 17-UML Diagramme - Martin Jud 6

7 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, Modul SWK - 17-UML Diagramme - Martin Jud 7

8 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 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, Modul SWK - 17-UML Diagramme - Martin Jud 8

9 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, Modul SWK - 17-UML Diagramme - Martin Jud 9

10 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, Modul SWK - 17-UML Diagramme - Martin Jud 10

11 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, Modul SWK - 17-UML Diagramme - Martin Jud 11

12 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, Modul SWK - 17-UML Diagramme - Martin Jud 12

13 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 Print Bill HSLU T&A, Modul SWK - 17-UML Diagramme - Martin Jud 13

14 Aus Objektorientierte Geschäftsprozessmodellierung, Oestereich et. al dpunkt Verlag Verzweigung und Aufteilung HSLU T&A, Modul SWK - 17-UML Diagramme - Martin Jud 14

15 aus der UML Superstructure Specification, OMG Parallele Abläufe Partitionen HSLU T&A, Modul SWK - 17-UML Diagramme - Martin Jud 15

16 Aus Objektorientierte Geschäftsprozessmodellierung, Oestereich et. al 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, Modul SWK - 17-UML Diagramme - Martin Jud 16

17 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, Modul SWK - 17-UML Diagramme - Martin Jud 17

18 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, Modul SWK - 17-UML Diagramme - Martin Jud 18

19 aus der UML Superstructure Specification, 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, Modul SWK - 17-UML Diagramme - Martin Jud 19

20 Aus Objektorientierte Geschäftsprozessmodellierung, Oestereich et. al dpunkt Verlag Aktivitätsbeschreibung HSLU T&A, Modul SWK - 17-UML Diagramme - Martin Jud 20

21 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, Modul SWK - 17-UML Diagramme - Martin Jud 21

22 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, Modul SWK - 17-UML Diagramme - Martin Jud 22

23 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 * Arb.geber Arb.nehmer arbeitet bei Kardinalität / (multiplicity) Rollen Navigierbarkeit Name und Leserichtung HSLU T&A, Modul SWK - 17-UML Diagramme - Martin Jud 23

24 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, Modul SWK - 17-UML Diagramme - Martin Jud 24

25 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, Modul SWK - 17-UML Diagramme - Martin 1998 Judby OBJEKTspektrum, Günter Wahl 25

26 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, Modul SWK - 17-UML Diagramme - Martin Jud nach Karl Rege, ZHW 26

27 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, Modul SWK - 17-UML Diagramme - Martin Jud 27

28 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, Modul SWK - 17-UML Diagramme - Martin Jud 28

29 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, Modul SWK - 17-UML Diagramme - Martin Jud 29

30 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, Modul SWK - 17-UML Diagramme - Martin Jud 30

31 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 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, Modul SWK - 17-UML Diagramme - Martin Jud 31

32 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, Modul SWK - 17-UML Diagramme - Martin Jud 32

33 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, Modul SWK - 17-UML Diagramme - Martin Jud 33

34 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, Modul SWK - 17-UML Diagramme - Martin Jud 34

35 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, Modul SWK - 17-UML Diagramme - Martin Jud 35

36 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, Modul SWK - 17-UML Diagramme - Martin Jud 36

37 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, Modul SWK - 17-UML Diagramme - Martin Jud 37

38 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, Modul SWK - 17-UML Diagramme - Martin Jud 38

39 sinngemäss nach: Scott W. Ambler, 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, Modul SWK - 17-UML Diagramme - Martin Jud 39

40 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, Modul SWK - 17-UML Diagramme - Martin Jud 40

41 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, Modul SWK - 17-UML Diagramme - Martin Jud 41

42 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, Modul SWK - 17-UML Diagramme - Martin Jud 42