Vorlesung Software Engineering I

1. VorlesungSoftware Engineering I Einführung UML Verhaltensidagramme Strukturdiagramme Design Pattern Software Engineering I VE 04: Einführung UML

2. Systemsichten und Modellierung Beschreiben die feste Struktur des Systems, die sich während der Laufzeit nicht ändert. Beschreiben das Verhalten und die Veränderungen während der Laufzeit. Beschreiben die Programmfunktion logisch und mathematisch Software Engineering I VE 04: Einführung UML

3. Unified Modelling Language (UML) UML = Sprache zur Beschreibung von Softwaresystemen • Grundgedanke: Einheitliche Modellierungs-Notation für alle Softwaresysteme • UML entstand aus mehreren bestehenden Notationen • UML ist eine Notation, keine Methode ! • UML ist ein Werkzeug für Systemanalyse und Systemdesign • Unterstützung durch viele CASE-Tools • Verschiedene Diagrammtypen, die sich gegenseitig ergänzen können und verschiedene Systemaspekte hervorheben Software Engineering I VE 04: Einführung UML 3

4. Geschichte der UML Software Engineering I VE 04: Einführung UML

5. UML2: Diagrammarten sieben Strukturdiagramme sieben Verhaltensdiagramme  UML Diagrammübersicht siehe http://www.oose.de/uml Software Engineering I VE 04: Einführung UML

6. UML2: Verhaltensdiagramme • Anwendungsfalldiagramm (Use Case Diagram) (stellt Beziehungen zwischen Akteuren und Anwendungsfällen dar) • Aktivitätsdiagramm (Activity Diagram)(beschreibt Abläufe, die aus einzelnen Aktivitäten bestehen) • Zustandsdiagramm (Statechart Diagram)(beschreibt endliche Zustandsautomaten für ein Objekt oder System) • Sequenzdiagramm (Sequence Diagram)(beschreibt den zeitlichen Ablauf von Nachrichten zwischen Objekten) • Kommunikationsdiagramm (Communication Diagram, ehem. Kollaborationsdiagramm)(Interaktionsdiagramm, zeigt Beziehungen und Interaktionen zwischen Objekten) • Zeitverlaufsdiagramm (Timing Diagram)(Interaktionsdiagramm mit Zeitverlaufskurven von Zuständen) • Interaktionsübersichtsdiagramm (Interaction Overview Diagram)(Interaktionsdiagramm zur Übersicht über Abfolgen von Interaktionen, ähnlich Aktivitätsdiagramm) Software Engineering I VE 04: Einführung UML

7. Use-Case-Diagramme • Beschreiben das Zusammenwirken von Aktoren [bspw. Personen] mit einem System • Use-Case-Diagramme sind Verhaltensdiagramme: Sie beschreiben bestimmte Aspekte, wie sich ein System verhält. • Im Use-Case-Diagramm können wesentliche Funktionen des Systems hervorgehoben und zueinander in Beziehung gesetzt werden. • Diesen Diagrammen fehlt jedoch eine Möglichkeit, die Reihenfolge der Ausführung festzulegen. Software Engineering I VE 04: Einführung UML

8. Use Case Diagramm: Notation Akteur Software Engineering I VE 04: Einführung UML

9. Use Case Diagramm: Notation Software Engineering I VE 04: Einführung UML

10. UML2: Aktionen • In UML2 sind die Spracheinheit Aktionen (engl. actions) elementare Bausteine zur Verhaltensmodellierung. • Ein- und Ausgabewerte werden über sog. Eingabepins entgegengenommen an sog. Ausgabepins ausgegeben. Software Engineering I VE 04: Einführung UML

11. UML2: Spezielle Aktionen • Die UML2 definiert einen Satz von elementaren Aktionen und teilt diese in mehrere Gruppen ein. Im folgenden eine Auswahl: Software Engineering I VE 04: Einführung UML

12. UML2: Aktivität • Eine Aktivität ordnet Aktionen als elementare Verhaltensbausteine in einem Netzwerk an, das aus Knoten und Kanten besteht. • Aktivitätskanten sind in zwei Hauptgruppen eingeteilt: • ein Kontrollfluss ist eine Aktivitätskante, über die keine Objekt-Token fließen • ein Objektfluss ist eine Aktivitätskante, über die Objekt-Token von einem Objektknoten zum nächsten fließen können Software Engineering I VE 04: Einführung UML

13. UML2: Aktivitätsdiagramm (Flussnotation) • Das UML-Äquivalent zum Flussdiagramm • Beispiel: Software Engineering I VE 04: Einführung UML

14. UML2: Aktivitätsdiagramm (Knoten-Notation) Knoten-Notation: • Zur Darstellung von Kontrollstrukturen ähnlich wie Struktogramme • Unterstützt strukturierte Programmierung besser als Fluss-Notation Software Engineering I VE 04: Einführung UML

15. Synchronisation der Kontrolle (AND) mit Synchronisationsbedingung (Die Bedingung ist optional.) Aufsplitten der Kontrolle (Zulassen von Parallelität) Aktivität Aktivität Kontrollfluß Aktivität2 wird nach Abschluß von Aktivität1 gestartet. Verzweigunsaktivität (kann auch durch normale Aktivität dargestellt werden) Kontrollfluß, der unter der angegebenen Bedingung gewählt wird. [Bedingung] Aktivität1 Aktivität2 [Bedingung] UML2: Aktivitätsdiagramm: Notation Software Engineering I VE 04: Einführung UML

16. Aktivität Objekt [Zustand] Aktivität wird durchgeführt, wenn über einen der eingehenden Kontrollflüsse die Kontrolle ankommt (OR) Start des Ablaufs und Identifikation der betroffenen Klasse Ende des Ablaufs (optional) Aktivität Die Ausführung der Aktivität versetzt das Objekt in den angegebenen Zustand (optionales, selten verwendetes Konstrukt in Aktivitätsdiagrammen).  Überlappung zu Zustandsdiagrammen ! Beispiel: aus dem Aktivitätsdiagramm wird eine Bestellung in den Zustand „abgewiesen“ versetzt (was bedeutet das,für das Zustandsdiagramm?) Klasse UML2: Aktivitätsdiagramm: Notation Software Engineering I VE 04: Einführung UML

17. UML2: Aktivitätsdiagramm Veränderungen gegenüber der UML1: • In der UML1 waren die Aktivitätsdiagramme eine spezielle Form der Zustandsdiagramme. In der UML2 sind die Aktivitätsdiagramme eigenständig. • Einige Begriffe der UML1 wurden weiterverwendet, bekamen aber eine vollständig neue Bedeutung. Ein Aktivitätsdiagramm in UML2 beschreibt eine Aktivität, die Teilschritte werden Aktionen genannt. In der UML1 wurden die Teilschritte eines Aktivitätsdiagramms Aktivitäten genannt; die Aktivitäten der UML1 heißen jetzt Aktionen, das Aktivitätsdiagramm von UML1 heißt jetzt Aktivität. • Aktivitätsmodelle haben jetzt eine starke Ähnlichkeit zu Petrinetzen. • Ein Aktivitätsdiagramm darf mehrere Anfangszustände haben. • Signale, Zeitereignis und das Ablaufende wurden als neue Notationselemente eingeführt. • Aktivitätsdiagramme dürfen Ein- und Ausgabeparameter enthalten. Software Engineering I VE 04: Einführung UML

18. Beispiel Geschäftsprozessmodellierung Mit BPMN gibt es auch eine UML-Erweiterung für Geschäftsprozesse: http://de.wikipedia.org/wiki/Business_Process_Modeling_Notation Software Engineering I VE 04: Einführung UML

19. Aktivitätsdiagramme (Bewertung) • Ein Aktivitätsdiagramm beschreibt die Reihenfolge und Abhängigkeiten von logisch zusammengehörenden Aktionen. • Die Aktionen eines Aktivitätsdiagramms sind Objekten zugeordnet (Unterschied zur Funktionsorientierung von Datenflußdiagrammen !) • Geeignet für die Modellierung von Geschäftsprozessen über die Grenzen von Anwendungsfällen hinweg. • geeignet für die detaillierte Analyse von Anwendungsfällen. • geeignet für die Modellierung von parallelen Software-Systemen mittels Partitionierung (sog. „Swimlanes“) • nicht geeignet für die Beschreibung der Interaktion von Objekten • nicht geeignet für die Zustandsübergänge eines einzelnen Objektes Software Engineering I VE 04: Einführung UML

20. UML: Interaktionsdiagramme • Beschreiben zeitliche Abläufe (Aufrufsequenzen) zwischen (bekannten) Objekten • Zwei semantisch äquivalente Darstellungen: (Andere Darstellung, aber dieselbe Sicht) • Sequenzdiagramm - Verwendung bei wenigen Klassen - Zeitablauf klar ersichtlich - Basierend auf den Message Sequence Charts (MSCs) der ITU-T • Kommunikationsdiagramm - Verwendung bei wenigen Nachrichten - Zeitablauf weniger klar ersichtlich Software Engineering I VE 04: Einführung UML

21. Sequenzdiagramm: Notation ZEIT Software Engineering I VE 04: Einführung UML

22. Sequenzdiagramm: Notation Software Engineering I VE 04: Einführung UML

23. Kommunikationsdiagramm: Notation Software Engineering I VE 04: Einführung UML

24. Objekt Pfandmaschine 1: nimmEineFlasche() 2: [Genommen==TRUE] habeFlasche() Sequenznummer FlaschenMechanik Nachricht Kommunikationsdiagramm: Beispiel Software Engineering I VE 04: Einführung UML

25. Kommunikationsdiagramm: Bewertung Vorteile: • Darstellung von sowohl dynamischen als auch statischen Beziehungen zwischen Objekten. • Darstellung komplexer Strukturen und Abläufe möglich. Nachteile: • Zeitlicher Verlauf ist weniger übersichtlich. Software Engineering I VE 04: Einführung UML

26. Kommunikations- vs. Sequenzdiagramm Beide Diagramme modellieren denselben Sachverhalt ! Software Engineering I VE 04: Einführung UML

27. UML: Strukturdiagramme • Klassendiagramm (Class Diagram)(wichtigstes Diagramm: Klassen und ihre Beziehungen untereinander) • Paketdiagramm (Package Diagram)(Gliedert Softwaresysteme in Untereinheiten) • Objektdiagramm (Object Diagram)(Objekte, Assoziationen und Attributwerte während Laufzeit) • Kompositionsstrukturdiagramm (Composite Structure Diagram)(Abbildung innerer Zusammenhänge einer komplexen Systemarchitektur, Darstellung von Design Patterns) • Komponentendiagramm (Component Diagram)(Komponenten und ihre Beziehungen und Schnittstellen) • Verteilungsdiagramm (Deployment Diagram)(Einsatzdiagramm, Knotendiagramm, Laufzeitumfeld) • Profildiagramm (Profile Diagram) Seit UML 2.2, um eigendefinierte Stereotypen-Sammlungen strukturieren zu können. Software Engineering I VE 04: Einführung UML

28. Attribute Methoden Klasse  Objekt Kontomodell Software Engineering I VE 04: Einführung UML

29. Klassendiagramm: Notation + für public # für protected ~ für package − für private Abstrakt: kursiv geschriebener Klassennamen. Oder „{abstract} Klassenname“. Notationsbeispiel: Software Engineering I VE 04: Einführung UML

30. Klassendiagramm: Notation Klasse1 erbt von Klasse2 (Klasse1 spezialisiert Klasse2)‏ Beziehung zwischen Klasse 1 und Klasse 2 Gerichtete Assoziation Navigierbar: von Klasse 1 nach 2 nicht navigierbar: von Klasse 2 nach 1 Beziehung zwischen Klasse 1 und Klasse 2 Software Engineering I VE 04: Einführung UML

31. Klassendiagramm: Notation Klasse1 realisiert Klasse2 Aggregation: Teil des Ganzen. Der Teil kann aber auch alleine bestehen. Komposition: „Existenzabhängiges Teil“ kann nur in Verbindung mit dem Ganzen existieren. Software Engineering I VE 04: Einführung UML

32. Objektdiagramm: Notation Das Objektdiagramm soll verdeutlichen, wie die Attribute einer Klasse zu einem bestimmten Zeitpunkt (Momentaufnahme) des Programms sind. => Es werden die Ausprägungen einer Klasse dargestellt Software Engineering I VE 04: Einführung UML

33. Objektdiagramm: Notation Die Komponenten (Assoziationen, Vererbungspfeile, usw.) sind genau gleich wie beim Klassendiagramm. Unterschiede zum Klassendiagramm: • Es werden nur die Attribute mit ihren Werten eingetragen (nicht die Methoden)‏ • Statt dem Klassennamen wird das Objekt folgendermaßen bezeichnet: • Objektname:Klassenname (Wichtig: Unterstreichen nicht vergessen! Mit Unterstreichen wird deutlich gemacht, dass es sich um Objekte handelt. Dies gilt für alle UML-Diagramme)‏ • Bei unbekanntem Objektnamen: :Klassenname • Datentypen können fortgelassen werden! Software Engineering I VE 04: Einführung UML

34. UML: Komponentendiagramm Komponentensymbol • Eine Komponente ist eine austauschbare Einheit • Diese Einheit ist ausführbar • Komponenten bieten Schnittstellen • Komponenten nutzen Schnittstellen anderer Komponenten Software Engineering I VE 04: Einführung UML

35. UML: Komponentendiagramm Komponenten enthalten z.B.: • Klassen • Pakete • Komponenten Verschiedene Darstellungsweisen: Software Engineering I VE 04: Einführung UML

36. UML: Komponentendiagramm Software Engineering I VE 04: Einführung UML

37. Implementierungsdiagramme • Zur Darstellung von Aspekten der Implementierung. • Dies betrifft sowohl die statische Code-Struktur als auch die Systemstruktur zur Ausführungszeit (Runtime). Speziell bei verteilten Anwendungen und Komponenten ist dies von besonderer Bedeutung. • Die UML sieht zwei Implementierungsdiagramme vor: • Komponentendiagramm • Komponentendiagramme zeigen den Aufbau des Applikationscodes • Verteilungsdiagramm • Verteilungsdiagramme zeigen die Struktur des Laufzeitsystems, (Physische Struktur) Software Engineering I VE 04: Einführung UML

38. UML:Komponentendiagramm Software Engineering I VE 04: Einführung UML

39. UML: Verteilungsdiagramm Software Engineering I VE 04: Einführung UML

40. Bsp. Verteilungsdiagramm Kommunikation Knoten Software Engineering I VE 04: Einführung UML

41. Übung UML Design Pattern Praxisprojekt • Erstellen Sie für Ihre Systemmodellierung ein Design Pattern in UML • Benutzen Sie dazu ein CASE-Tool • Starten sie mit einem Use-Case-Diagramm • Fügen sie jedem Use-Case ein Aktivitätsdiagramm hinzu • Modellieren Sie die Systemarchitektur mit einem Component/Deployment Diagram • Fügen Sie jeder Komponente ein State Diagramm hinzu • etc. Software Engineering I VE 04: Einführung UML