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 ISBN: 3-8984-2738-2 (Deutsch)

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?

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

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

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

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

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

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

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

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

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

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

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

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

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

Entscheidungsknoten • Modellieren Entscheidungsfälle Startpunkt Endpunkt

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

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

Zustandsdiagramm BSP.: Event Interne Aktion Transition

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

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

Create-Nachricht • Ein Objekt wird erstellt Nachricht

Nachricht mit Rückantwort Nachricht Rückantwort

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

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

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

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

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

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

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

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

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

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)

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

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

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

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>>

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

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

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

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

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

Objektdiagramm Klassendiagramm Objektdiagramm Zugehörige Klasse Objektname Objekt Attributwert Attributname

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

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

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

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

Horizontale Strukturierung Pakete

Software-Engineering II