1 / 53

Software-Engineering II

Software-Engineering II. UML. Themenübersicht. Objektorientierung Aspektorientierung Vorgehensmodelle UML Analyse- & Entwurfsmuster Objektorientiertes Testen Versionsverwaltung Refactoring Labor (Praktischer Teil). UML. UML 2.0 Christoph Kecher Galileo Computing 424 Seiten

kynton
Download Presentation

Software-Engineering II

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related