1. Software-Engineering II UML

2. Themenübersicht Objektorientierung Aspektorientierung Vorgehensmodelle UML Analyse- & Entwurfsmuster Objektorientiertes Testen Versionsverwaltung Refactoring Labor (Praktischer Teil)

3. UML UML 2.0 Christoph Kecher Galileo Computing 424 Seiten ISBN: 3-8984-2738-2 (Deutsch)

4. Unified Modelling Language Allgemein verwendbare Modellierungsnotation Im Laufe vieler Jahre entstanden Unabhängig von Programmiersprachen Unabhängig von Vorgehensmodellen Eigenschaften Einfach Verständlich Ausdrucksstark Standardisiert UML – Was ist das?

5. Klassendiagramm Objektdiagramm Paketdiagramm … Modellieren statische, zeitunabhängige Gegebenheiten Use-Case-Diagramm Aktivitäts-Diagramm Zustandsdiagramm Sequenzdiagramm … Modellieren Verhalten und zeitabhängige Gegebenheiten Diagrammtypen Verhaltensdiagramme Strukturdiagramme

6. Modellieret Funktionalität des zu entwickelnden Systems Zeitpunkt: Analysephase Bildet Grundlage für weitere Modelle Hohes Abstraktionsniveau Sicht eines externen Anwenders Modelliert, welche Anwendungsfälle die Software bieten wird und nicht wie es Realisiert werden kann Use-Case-Diagramm

7. Akteur • Modelliert einen Typ oder eine Rolle, die ein externer Benutzer oder ein externes System einnimmt • Mehrere Akteure sind möglich

8. Anwendungsfall • Spezifiziert eine Aktion oder eine Menge von Aktionen, die von einem Subsystem zur Verfügung gestellt wird Anwendungsfall Subsystem

9. Assoziation • Modelliert Beziehungen zwischen Anwendungsfällen • Wird angewandt, wenn Akteure Anwendungsfälle ausführen dürfen • Anmerkung: Da Aktoren externe Elemente in Use-Cases representieren, werden sie außerhalb der Subsystemgrenzen positioniert

10. Ein Akteur erbt alle Eigenschaften eines anderen Akteurs Kann auch für Anwendungsfälle verwendet werden Generalisierung

11. Include • Modelliert das unbedingte Einbinden eines Anwendungsfalles in einen anderen • Jedes Mal, wenn ein Anwendungsfall ausgeführt wird, müssen alle mit <<include>> assoziierten Anwendenfälle ausgeführt werden • Im Bsp.: Das Planen einer Vorlesung beinhaltet demnach immer das Vorbereiten des Vorlesungsinhaltes, das Halten der Vorlesung und das Festlegen der Prüfungsleistung

12. Extends • Modelliert das bedingte Einbinden eines Anwendungsfalles in einen Anderen • Ein bedingt eingebundener Anwendungsfall kann (muss aber nicht) bei der Ausführung des einbindenden Anwendungsfalles durchgeführt werden • Achtung: Der Pfeil zeigt von dem bedingt eingebundenen Anwendungsfall auf den Einbindenden

13. Extension Points • Definieren, welchen Teil eines Anwendungsfalles eine Extends-Beziehung bedingt erweitert Extension Point Extension Point

14. Fokus auf Aktionen, die durchgeführt werden können Analyse-Phase: Modellierung von Geschäftsprozessen Zeigt Reihenfolge von Prozessen und Tätigkeiten auf Erleichtert Analyse der Geschäftsprozesse Können zur Umsetzung verwendet werden Sicht des Anwenders Entwurfs-Phase Modellierung von internen Systemprozessen Wichtigster Einsatz der AD Umfangreiche Abläufe, komplexe Algorithmen Implementierungs-Phase: Realisierungsvorlage Test-Phase: Grundlage für Testfälle Aktivitätsdiagramm

15. Aktion • Ausführbarer Knoten, der Funktionalität bietet • Grundlegende Einheit eines Aktivitätsdiagrammes

16. Kontrollfluss • Gerichtete Verbindung zw. Aktionsknoten • Definiert die Reihenfolge der Aktivitäten Kontrollfluss

17. Aktivitätsbereich • Ordnet Aktivitäten eindeutig Akteuren zu (Siehe Use-Case-Diagramm) • Alle Aktionen, die hier modelliert werden, müssen im Use-Case-Diagramm zuvor definiert worden sein • Umgekehrt ist es jedoch möglich, dass eine in einem Use-Case-Diagramm definierte Aktion nicht in einem Aktivitätsdiagramm verfeinert wird Akteur

18. Entscheidungsknoten • Modellieren Entscheidungsfälle Startpunkt Endpunkt

19. Gabelung / Zusammenführung • Deutet parellele Abläufe an Gabelung Zusammen- führung

20. Ahnlich dem Aktivitätsdiagramm Ähnliche Symbolik Konzentriert sich im Gegensatz zum Aktivitätsdiagramm nicht auf Aktionen sondern (zustandsabhängige) Reaktionen von Systemen Zustandsdiagramm

21. Zustandsdiagramm BSP.: Event Interne Aktion Transition

22. Modellieren zeitabhängige Interaktionen zwischen Objekten Im Vergleich zu Aktivitätsdiagrammien liegt hier der Fokus auf den Nachrichtenaustausch, nicht die verschiedenen Ablaufpfade Analysephase: Darstellungen der Geschäftsprozesse auf Nachrichtenebene Entwurfsphase: Interaktionen von Systemen oder Aktoren Bsp: Kommunikation Benutzer mit GUI Sequenzdiagramm

23. Lebenslinie • Eine Lebenslinie stellt einen Teilnehmer einer Interaktion dar • Durch ein Stop-Symbol wird dargestellt, dass eine Lebenslinie terminiert • Eine gestrichelte Linie stellt einen passiven bereich einer Lebenslinie dar Lebenslinie Stop-Symbol passive Lebenslinie

24. Create-Nachricht • Ein Objekt wird erstellt Nachricht

25. Nachricht mit Rückantwort Nachricht Rückantwort

26. Zentrales Konzept der UML Modellierung von Klassen und deren Zusammenhänge Analysephase: Relativ einfache Diagramme für Kommunikation mit Vorgesetzten / Partnern Entwurfsphase: Detailliert, legt spätere Programmstruktur fest Definieren nicht, in welcher Reihenfolge Klassen miteinander kommunizieren. Klassendiagramm

27. Klassen I Klassenname Attribute Access Modifiers Methoden Private – Protected # Package ~ Public + Datentyp

28. Klassen II class BADozent { private String name; private String geburtsDatum; public void setName( String name ) { … } public void benote( BAStudent student ) { … } } vs. • einfach, übersichtlich • Für fachunkundige lesbar • Ohne programmiersprachen-spezifische Elemente

29. Klassen III Typ mit Angabe der Multiplizität Default-Wert (statisches) Klassenattribut

30. (Binäre) Assoziation • Spezifiziert eine semantische Beziehung zwischen zwei Klassen • BAStudent und BADozent „kennen“ sich gegenseitig, können interagieren

31. Assoziation - Name • Durch einen Assoziationsnamen kann man die Beziehung genauer spezifizieren (e.g. „benotet“) Assoziationsname Anmerkung: Dies würde heißen, dass auch der BAStudent den BADozent benoten kann

32. Assoziation - Navigierbarkeit • Gerichtete Assoziationen sind binäre Assoziationen, die die Navigierbarkeit einschränken • Ein navigierbares Ende definiert, dass die Klasse am anderen Assoziationsende Kenntnis über die Klasse besitzt • Ein nicht navigierbares Ende verbietet solch eine Kenntnis BADozent enthält eine Abhängigkeit zu BAStudent. Umgekehrt besteht keine Abhängigkeit nicht navigierbar navigierbar

33. Assoziation - Multiplizität • Durch Hinzufügen von Multiplizitäten kann definiert werden, wieviele Referenzen des anderen Typs existieren können. • Multiplizitäts-Formen: • Beliebig viele „*“ • Feste Zahl z.B. „1“ • Zahlenbereich z.B. „1..15“ oder „1..*“ • Im Beispiel: • Ein BADozent kann einen bis 40 Studenten benoten • Ein BAStudent kann von einem bis 15 Dozenten benotet werden

34. Assoziation - Rollen • Definieren die Rollen der Klassen bei der Assoziation • Eine Klasse kann • an mehreren Assoziationen teilhaben • dabei in verschiedene Rollen schlüpfen • Die Rolle wird oft nach dem Attributnamen der Referenz benannt Sichtbarkeit der Rolle Rolle

35. Assoziation: Aggregation • Spezielle Form der binären Assoziation • Beschreibt, dass eine Klasse ein Teil einer anderen ist • Ein Studiengang kann auch ohne BA-Studenten existieren (auch wenn das nichts Gutes für den Studiengang verheißt)

36. Assoziation: Komposition • Starke Form der Aggregation • Sagt aus, dass die Verbindung zwischen den Klassen untrennbar ist. • Wird das komponierende Objekt zerstört können die komponierte Objekte nicht weiterexistieren. • Im Beispiel: • Ein Kurs kann ohne BA-Studenten nicht existieren

37. Assoziation: Generalisierung • Mithilfe der Generalisierung ist es möglich, Vererbung zu modellieren • Der Pfeil zeigt stets auf die Superklasse

38. Abstrakte Methoden • Durch kursives Schreiben eines Methoden- oder Klassennamens wird dargestellt, dass es sich um eine abstrakte Eigenschaft handelt • Optional wird unterhalb des Klassennamens auch {abstract} notiert abstrakt

39. Stereotyp • Können in allen Diagrammarten verwendet werden • Spezifizieren Art des Elementes • Verändern nicht die Semantik • Verändern die Auskunft über Zweck und Rolle des Elementes <<stereotyp>>

40. Gängige Stereotypen <<utility>> • Dient als Werkzeugkasten für weitere Klassen (e.g. java.util.*) <<interface>> • Schnittstellendefinition <<enumeration>> • Definiert einen Datentypen, der Elemente beinhalten kann (e.g. java.util.Vector) <<use>> • Gibt an, dass das Element vom anderen verwendet wird

41. Schnittstellen I • Mit Schnittstellen kann man die in Java existierenden Interfaces modellieren • Sie besitzen wie zu erwarten einen Namen und Schnittstellen-Operationen • Oft werden Schnittstellen auch mit dem Stereotyp <<interface>> oberhalb des Namens gekennzeichnet PartyPerson <<interface> +feiern(): void Name Operationen

42. Schnittstellen II • Durch einen gestrichelten geschlossenen Pfeil kann modelliert werden, dass eine Klasse ein Interface realisiert (implementiert). • Gelegentlich wird dies auch durch die Notation von <<realize>> am Pfeil betont

43. Schnittstellen III Werden Interfaces von anderen Klassen verwendet, modelliert man dies mit einer <<use>>-Abhängigkeit

44. Objektdiagramm • Basiert auf ein Klassendiagramm • Dient zur Veranschaulichung von Klassendiagrammen • Stellt die instanziierten Objekte zu einem speziellen Zeitpunkt dar • Enthält nur Attribute, keine Methoden • Darf nur Objekte beinhalten, deren Klassen im zugrundeliegenden Klassendiagramm definiert wurden • Darf nur Attribute beinhalten, die diese Klassen definiert haben • Kann unvollständig sein und nur Attribute umfassen, die für den Zustand von Bedeutung sind

45. Objektdiagramm Klassendiagramm Objektdiagramm Zugehörige Klasse Objektname Objekt Attributwert Attributname

46. Link • Pendant zur Assoziation im Klassendiagramm • Verbinden genau zwei Objekte • Bei 1:n-Multiplizitäten werden Links zu den einzelnen Instanzen modelliert Link

47. Namenlose Objekte • Objektnamen können weggelassen werden, wenn sie im Kontext nicht wichtig erscheinen Namenlose Instanz

48. Rollen • Entsprechen den Rollen des Klassendiagramms • Werkzeug der Wahl um Objektreferenzen zu modellieren

49. Frühe Phasen der Softwareentwicklung (Analyse/Design) Horizontale Strukturierung Gruppiert Klassen in Pakete Klassifizierung von Klassen Vertikale Strukturierung Gruppiert Pakete in Unterpakete Bessere Übersicht („Zoomen“) Paketdiagramm

50. Horizontale Strukturierung Pakete