Prof. Dr. Nikolaus Wulff 1
Wenn du eine Hundehütte bauen willst, so reicht es aus sich ein paar Bretter, Nägel und als Handwerkzeug eine Säge, einen Hammer und einen Zollstock zu besorgen. Mit grosser Wahrscheinlichkeit wird nach wenigen Stunden eine halbwegspassable Hundehütte entstehen.
So lange sie gross genug ist, wird der Hund glücklich sein.Falls nicht, ist es kein Problem wieder von vorne anzufangenoder den Hund zu tauschen ...
Wenn du ein Hochhaus bauen willst ist dieser Ansatz idiotisch!
Grady Booch
Prof. Dr. Nikolaus Wulff
Softwaredesign Softwaredesign mit der UML mit der UML Eine Einführung in die Unified Modelling Language
Prof. Dr. Nikolaus Wulff 3
Agenda
• UML Historie
• Modellbildung
•
• Use Cases & Anforderungen
• Klassen & Assoziationen
• Dynamische Aspekte
• Struktur und Verteilung
Prof. Dr. Nikolaus Wulff 4
Modelle in der Naturwissenschaft
• Das Erstellen von Modellen ist typisch für die Naturwissenschaften Physik, Chemie etc.
• Diese Modelle werden meist durch mathematische Gleichungen beschrieben.
• Häufig werden Modelle zum besseren Verständnis durch entsprechende Grafiken dargestellt.
Prof. Dr. Nikolaus Wulff 5
Problem der Modellbildung• In der Softwareentwicklung gibt es im
Allgemeinen keine „Naturgesetze“ und somit keine verbindliche Vorschrift wie Modelle erstellt werden.
• Die UML bietet lediglich eine einheitliche Notation, wie man SWE Modelle abbildet.
• Dies sagt jedoch wenig dazu, wie man ein Modell findet und entwickelt.
Prof. Dr. Nikolaus Wulff 6
Softwaredesign ist Arbeit
• Die UML ist ein wichtiger Schritt zu einer gemeinsamen Sprache in der Informatik.
• Dies erleichtert die Kommunikation und den Wissensaustausch.
• Sie hebt die Semantik auf eine höhere Ebene und bietet einen besseren Abstraktionsgrad.
• Jedoch: Gute Software wird nach wie vor von guten Entwicklern gemacht.
• Und dennoch gilt: Gute Entwickler verwenden die UML!
Prof. Dr. Nikolaus Wulff 7
Softwareentwicklung ist Modellbildung
Anforderungs-Modelle
Use Case Modelle
Anforderer
Oberflächen-Modelle
Benutzer
Klassenmodelle
Objektmodelle
HW/SWSysteme
Implementierungs-Modelle
Sprachen
Test-Modelle
Subsysteme
Sicherheits-systeme
Datenbank
Modelle nicht als Wasserfall sondern inkrementell entwickeln!
Prof. Dr. Nikolaus Wulff 8
UML ist Ansichtssache...
• UML ist eine visuelle Modellierungssprache.
• Ein System wird unter vielen verschiedenen Blickwinkeln modelliert.
• Für jede Blickrichtung gibt es eine geeignete Darstellung bzw. einen Diagrammtyp.
• Nicht alle Diagramme sind in jedem Projekt gleich wichtig
• => sinnvoller Einsatz der Diagramme, je nach Problemstellung
Prof. Dr. Nikolaus Wulff 9
Prinzipien der Modellierung
• Die Wahl der Modelle hat einen signifikanten Einfluss auf die Qualität der Lösung.
• Jedes Modell lässt sich unterschiedlich detailliert beschreiben.
• Die besten Modelle zeichnen sich durch ihren hohen Bezug zur Realität aus.
• Kein einzelnes Modell ist ausreichend. Jedes nicht triviale System wird durch mehrere, kleine lose gekoppelte Modelle beschrieben.
Prof. Dr. Nikolaus Wulff 10
Charakteristika der UML
• Die UML beinhaltet:– Informelle Semantik– Abstrakte Syntax– Konkrete Notation– Die UML ist eine Modellierungssprache
• Das leistet die UML nicht:– Sie ist kein Vorgehensmodell.– Sie ist keine Methodik. Einsatz der UML muss an eine Methodik angepasst
werden• Beschränkte Erweiterbarkeit:
– Stereotypen– Tagged Values– Constraints
Prof. Dr. Nikolaus Wulff 11
Modellebenen der Architektur
Implementierung & Komponenten
Verteilung& Maschinen
Prozesse & Threads
Analyse & Design
Use Case / Anforderungen
Prof. Dr. Nikolaus Wulff 12
Gliederung der UML
• Die Diagrammtypen der UML lassen sich grob klassifizieren:
Statische Sicht KlassendiagrammKomponentendiagrammDeploymentdiagramm
DynamischeSicht
Use Case DiagrammSequenzdiagrammKollaborationsdiagrammZustandsdiagramm
Prozess Sicht Aktivitätendiagramm
Prof. Dr. Nikolaus Wulff 13
Diagramme der UML (I)
Diagramm Aktivität Einsatzgebiet
Use Case Anforderung,Festlegung,Erstellung,Übergabe
Geschäftsprozesse,allgemeine Einsatzmöglichkeiten
Klassendia-gramm
Festlegung,Erstellung
So gut wie überall; das Klassendiagrammist das wichtigste Diagramm der UML
Interaktions-diagramm
Sequenzdia-gramm
Kollaborations-diagramm
Anforderung,Festlegung,Erstellung,Übergabe
Zeigt den Nachrichtenfluß und damit dieZusammenarbeit der Objekte im zeitlichenAblauf.
Zeitliche Aufrufstruktur mit wenigenKlassen
Zeitliche Aufrufstruktur mit wenigenNachrichten
Zustands-diagramm
Anforderung,Festlegung,Erstellung,Übergabe
Darstellung des dynamischen Verhaltens
Prof. Dr. Nikolaus Wulff 14
Use Case / Szenario
• Ein Use Case beschreibt vom Anfang bis zum Ende, wie ein Benutzer mit dem System agiert, um ein bestimmtes Ziel zu erreichen,.
• Die „W“-Fragen zum Finden eines Use Case lauten:– Wer (= > Akteur) macht
– Was (=> Aktion) mit
– Wem (=> Teil/Komponente des Systems)
– Wozu (=> Endresultat)
• Es geht nicht darum wie das System etwas macht!
• Es geht um das Systemverhalten aus Sicht der Benutzerziele.
Prof. Dr. Nikolaus Wulff 15
Szenarien, Varianten & Stories
• Ein erster Ansatz zu einem Use Case lässt sich durch das Schreiben von kurzen Szenarien oder (Stories in der XP Syntax) finden.
• Der Benutzer beschreibt in seiner Sprache wie er mit dem System umgeht bzw. umgehen möchte.
• Häufig wird unterteilt nach Ist-Zustand und einer zukünftigen System Vision.
• Im Prinzip geht es immer um das Gleiche:
• Finde heraus, was der Anforderer wirklich vom System möchte ...
Prof. Dr. Nikolaus Wulff 16
Use Case & Anforderung
• Die verschiedenen Anforderungen der Benutzer sind meistens an bestimmte Arbeitsschritte gebunden.
• Ein Use Case beschreibt aus Benutzersicht einen bestimmten Weg durch das System.
• Verschiedene Arbeitsschritte werden in einem Use Case durchlaufen.
• Dieser Ablauf wird in einer Use Case Beschreibung dokumentiert.
Prof. Dr. Nikolaus Wulff 17
Use Case Beispiel
Finanzierung berechnenKurzbeschreibung Die Finanzierungskonditionen eines Leasingpaketes wird nach Anfrage
der Leasinggesellschaft durchgeführt.Beteiligte Akteure SB Sachbearbeiter Leasing-Abteilung
SYS Das EDV System zur „Leasing (Re)Finanzierung“Auslöser Anfrage eine LeasinggesellschaftEingaben Leasinggesellschaft und LeasingvertragAusgaben Angebot(e) für eine FinanzierungVorbedingungen Leasinggesellschaft muss mit ihren Konditionen im System bekannt
seinNachbedingungen Angebotsmappe ist der Leasinggesellschaft zugeordnetHäufigkeit Tag: 10- 20 / SB Woche: Monat: Jahr:
Ablauf:
1. SB Sucht die LG aus 1.1. Eingabe der LV Daten 1.2. Durchführung der Berechnung1.3.2.2.1.
Ausnahmen und Varianten
A1.4. SB Neue LeasinggesellschaftA1.4.1V1.8.V1.8.1
Qualitätssicherung
Prof. Dr. Nikolaus Wulff 18
Use Case Diagramm
• Use Cases lassen sich mit Diagrammen visualisieren. (=> besserer Überblick)
• Diese Diagramme ersetzen jedoch nicht eine vollständige Use Case Beschreibung.
• Die Summe aller Use Cases deckt die gesamte Funktionalität des Systems aus der Sicht der verschiedenen Benutzer(rollen) ab.
• => alle Benutzerziele müssen erreicht sein.
Prof. Dr. Nikolaus Wulff 19
Use Case Diagramm (II)
• In der obersten Sicht werden die beteiligten Akteure (=> Benutzer, externe Systeme) und ihre Kommunikation mit dem System dargestellt.
• Dies markiert zu gleich die Systemgrenzen.
• Auch die externen Systeme und Benutzer im System müssen richtig modelliert werden.
– => „Dialoge“ für Benutzer
– => technische Schnittstellen für Systeme
Prof. Dr. Nikolaus Wulff 20
Use Case Strukturierung
• Use Cases können mit den Beziehungen– uses / includes (Benutzt-Beziehung)
– extends (Spezialisierungs-Beziehung)
strukturiert und „wiederverwendet“ werden.
• Die visuelle Notation sieht hierzu die selben Symbole, wie in den Klassendiagrammen für die Vererbung vor.
• Die Beziehung selbst wird durch die Stereotypen includes und extends kenntlich gemacht.
Prof. Dr. Nikolaus Wulff 21
UCD: Vertragerstellung
Systemgrenze
«uses»
«uses»«include»
«include»
ext. System alsAkteur modelliert
Akteure
Prof. Dr. Nikolaus Wulff 22
Pragmatik: Use Case • Gute Use Case dienen nicht nur zur
Dokumentation der Funktionalität:– Hilfe für die Aufwandsschätzung
– Steuerung der Inkremente durch Einteilung nach • Risiko und
• Nutzen
– Anleitung für fachliche Tests
• Jedoch die Use Cases sind nicht das Projekt. Anforderungen ändern sich in der Regel ...
Prof. Dr. Nikolaus Wulff 23
Use Cases und Klassen• Use Cases sind nicht mit den Klassen der
Klassendiagramme zu verwechseln.
• Sie geben jedoch Hinweise auf mögliche Kandidaten für Klassen, die in verschiedenen Szenarien immer wieder vorkommen.
• Use Cases, die eine Interaktion des Benutzers mit dem System beschreiben, erfordern typischerweise einen Dialog zur Ein- und Ausgabe.
Prof. Dr. Nikolaus Wulff 24
UseCase 4
UseCase 3
Von Abläufen zu Werkzeugen
UseCase 2
:= Material
:= WerkzeugKristallisationspunkt für ein potentielles Werkzeug
UseCase 1
:= Interaktionspfad des Benutzers
Prof. Dr. Nikolaus Wulff 25
• Eine Klasse beschreibt eine Menge von Objekten mit gleicher Struktur, gleichem Verhalten und gleichen Beziehungen.
• Die UML definiert– eine grafische Notation für Klassen
– eine textuelle Notation für die Referenzierung packagename::Klassenname
Klassen und Objekte
Prof. Dr. Nikolaus Wulff 26
Klasse
• Eine Klasse wird dargestellt als ein Rechteck, unterteilt in drei Bereiche:
– Den Klassennamen
– Den Attributen
– Den Methoden
• Alle Bezeichner können mit Stereotypen «...» versehen werden.
Prof. Dr. Nikolaus Wulff 27
Klassen (II)• Der Klassenname muss angegeben werden.
• Attribute und Methoden sind optional und müssen im Kontext der Klasse eindeutig sein.
• Der Klassenname hat Gültigkeit im Paket der Klasse und muss hierin eindeutig sein.
• Die vollständige Referenzierung von Klassen, die in anderen Paketen definiert sind lautet:
– UML: Package-Name::Class-Name
– Vergleich:• Java: packagename.classname
• C++: namespace::classname
Prof. Dr. Nikolaus Wulff 28
Template Klasse• Parameterisierte Template Klassen, wie in C++
oder Java Generics, werden als Klassen oder Schnittstellen dargestellt, mit den formalen Typ Parameter in einem rechteckigen Symbol.
public interface List<T> { /** Einfügen eines Elements */ public void add(T obj); /** Auslesen mit Index */ public T get(int idx);}
public class ArrayList<T> implements List<T> {
...
Prof. Dr. Nikolaus Wulff 29
Klassen finden • In der Literatur werden verschiedene Methoden
für das Finden von Klassen beschrieben, u.a.:– Lexikalische Analyse (z.B. der Szenarien)– Realitätsbeobachtungen– Formularanalyse, Benutzersichtanalyse– Ereignisanalyse– CRC Sessions (Class Responsibilities Collaborators)
Prof. Dr. Nikolaus Wulff 30
Lexikalische Analyse• Untersuchung einer textuellen Beschreibung * nach
• Substantiven• Adjektiven• Verben
• Substantive stehen für potentielle Klassen
• Adjektive stehen für Attribute
• Verben stehen für Methoden.
*) R. Abbott, Programm Design by Informal English Descriptions. Communication of the ACM vol. 26(11), 1983.
Prof. Dr. Nikolaus Wulff 31
Realitätsbeobachtungen• Ableitung der in einem Problembereich relevanten
Objekte durch Beobachtungen, also ohne Umweg über eine textuelle Beschreibung.
• Beispiel: In einem Bibliotheksverwaltungssystem identifiziert man intuitiv folgende Objekte:
– Bücher– Ausleiher– Standorte
• Eignet sich, um schnell und intuitiv ein erstes Klassenmodell zu erstellen, das jedoch anschließend durch Anwendung weiterer Methoden verfeinert werden muß.
Prof. Dr. Nikolaus Wulff 32
Formular- und Benutzersichtanalyse
• Ableitung von Klassenkandidaten aus Dokumenten, die Arbeitsergebnisse beinhalten, z.B.
– Layouts für Bildschirmausgaben– Listen, Formulare, Tabellen
• Klassenkandidaten: Kunde, Artikel, Lieferanschrift, Zahlungsart
BestellungKundennr: Telefonisch erreichbar:LieferanschriftName: Vorname:Straße: Hausnr.PLZ: Ort:Artikelnr. Artikelbezeichnung Einzelpreis Menge Gesamtpreis
Zahlungsart: Überweisung Nachnahme total:Datum: Unterschrift:
Prof. Dr. Nikolaus Wulff 33
Ereignisanalyse• Benennung von problemrelevanten Ereignissen,
über die das System Information speichern muß.
• Beispiel: Kontoführungssystem einer Bank.– Ereignis: Gutschrift auf ein Sparkonto– Benötigte Informationen:
• Datum• Betrag
damit die Zinsen berechnet werden können.
Prof. Dr. Nikolaus Wulff 34
CRC Sessions• Eine CRC Session ist eine spezielle
Vorgehensweise, um in einer Gruppensitzung, an der Teilnehmer aus unterschiedlichen Bereichen mitarbeiten, Objekte und deren Interaktionen zu finden.
• CRC steht für Class Responsibilities Collaborator.• Für jede zum System gehörende Klasse wird eine
CRC Card angelegt. Sie beinhaltet– Verantwortlichkeiten der Klasse (=
Responsibilities),– bei der Ausübung der Verantwortlichkeiten
beteiligte Klassen (= Collaborators),– kurze Aufgabenbeschreibung der Klasse,– ggf. Attribute der Klasse.
Prof. Dr. Nikolaus Wulff 35
Pragmatik: CRC Karten
• Das Verhalten und die Verantwortlichkeiten von Klassen lassen sich gut durch eine Use Case Analyse und CRC* Karten finden.
Muster für eine CRC Karte*) CRC: Classes, Responsibilities and Collaborators
Klasse:Verantwortung: Beteiligte:
Prof. Dr. Nikolaus Wulff 36
Klassenkandidaten• Objekte der Realwelt
Person, Flugzeug
• Rollen Vertragspartner, Passagier
• Beziehungen zwischen Objekten, z.B. Vertrag, Flug
• Konzepte, z.B. Sterbetafel, Reservierung
• Ergebnisse, z.B. Vertragspolice, Diskussionsergebnis
Prof. Dr. Nikolaus Wulff 37
Klassenkandidaten II
• Ereignisse, z.B. Vertragsabschluß, Anfrage, Landung
• Interaktionen Akquisegespräch, Vertragsverhandlung
• Kollektionen, z.B. Liste, Menge, Dictionary, Vektor
• technische Hilfsklassen, z.B. Fabrik (Factory), Stellvertreter (Proxy),
Befehl (Command)
Prof. Dr. Nikolaus Wulff 38
Klassenbildung• Klassen werden gebildet durch
– Klassifizierung von Objekten, unter Verwendung von Kontexten.
• Beispiel: Was passt nicht in diese Aufzählung: Pferd, Himmel, Auto und Gemälde ?
– Klassifizierung durch Weglassen von Details (Abstraktion).
• Beispiel:Wie lassen sich die Züge im folgenden Bild klassifizieren ?
Prof. Dr. Nikolaus Wulff 39
Klassenbildung - Beispiel
Quelle: Grady Booch.Object-Oriented Analysis and Designwith Applications
Prof. Dr. Nikolaus Wulff 40
Klassenbildung II
• Abstrahieren bedeutet, unwesentliche Eigenschaften zu ignorieren und wesentliche Eigenschaften zu betonen.
• Was wesentlich ist und was nicht, hängt vom Kontext und vom Betrachter ab.
• => Entwickler/Designer mit unterschiedlichen Erfahrungshintergrund kommen bei gleicher Aufgabenstellung zu unterschiedlichen Klassenentwürfen.
Prof. Dr. Nikolaus Wulff 41
Pragmatik: Klassenbildung
• Erstelle das fachliche Klassenmodell ähnlich einem Kartographen der eine Landkarte zeichnet:
– benutze die Bezeichner des (Fach) Bereichs
– entferne irrelevante Artefakte
– füge nichts hinzu, was nicht da ist.
• Nagelprobe: Wenn wir über ein Artefakt „X“ nicht als eine Zahl oder ein einfaches Textstück in der realen Welt denken können, so ist „X“ ein Klassenkandidat.
Prof. Dr. Nikolaus Wulff 42
• Klassenmodelle beschreiben die Beziehungen zwischen den Objekten. Beziehungen sind bidirektional, d.h. beschreiben immer eine Relation zwischen mindestens zwei Elementen
• Es gibt verschiedene Typen von Beziehungen: – Generalisierung: is-A-Relation
– Assoziation: has-A-Relation
– Abhängigkeit: uses-Relation
– Realisierung: implements-Relation
– Aggregation: isPartOf-Relation
Relationen
Prof. Dr. Nikolaus Wulff 43
Generalisierung
• Generalisierung beschreibt die Vererbungs-beziehung zwischen einer Klasse (SuperKlasse) und einer oder mehreren Varianten (SubKlassen) dieser Klasse.
• Die SuperKlasse beschreibt das gemeinsame Verhalten der SubKlassen und somit in der Regel auch die gemeinsamen Attribute und Operationen.
• SubKlassen werden weiteres Verhalten hinzufügen und eventuell Methoden der SuperKlasse überladen. ( => Polymorphie)
• Vererbungsbeziehungen lassen sich auch auf Schnittstellen anwenden.
Prof. Dr. Nikolaus Wulff 44
Assoziation
• Eine Assoziation beschreibt eine Beziehung (Verbindung) zwischen zwei Klassen.
• Die Assoziation sollte einen sprechenden Namen tragen, der den Sinn ausdrückt.
• Jede der Klassen spielt aus der Sicht der anderen Klasse eine Rolle, die auch einen entsprechenden Namen trägt.
• Der Rollenname wird nach der Codegenerierung der Name des entsprechenden Attributs innerhalb der Klasse. (=> Beispiel)
Prof. Dr. Nikolaus Wulff 45
Diagramm und Codepublic class KontoListe { /** Eine Liste mit Konten für die Implementierung der Assoziation */ List<Konto> konten = new ArrayList<>();
/** Einfügen eines Kontos */ public void addKonto(Konto k) {
konten.add(k); } /** Auslesen mit Index */ public Konto getKonto(int index) { preCondition(index < konten.size()); return konten.get(index); }
} // end class KontoListe
~
Prof. Dr. Nikolaus Wulff 46
Pragmatik
• Jede Rolle schlägt sich in der Implementierung als ein Attribut nieder
– eindeutige Rollennamen vergeben
– an einen sprechenden Namen denken
• Es gibt in der Implementierung prinzipiell keinen Unterschied zwischen einer Rolle und einem Attribut.
• Die Assoziationen/Rolleninstanzen werden bei der Codegenerierung meist nicht initialisiert!
• Rollen lassen sich durch Reversengeneering meist nicht automatisch durch Tools rekonstruieren!!!
Prof. Dr. Nikolaus Wulff 47
Pragmatik (II)
• 1:N und N:M Assoziationen werden im OO-Klassendesign anders implementiert, als man dies aus der Umsetzung von ER-Modellen für relationale Datenbanken i.A. gewohnt ist:
CREATE TABLE Buchung buchung-id ID not null, konto-id ID not null, PRIMARY KEY (buchung-id), FOREIGN KEY (konto-id) REFRENCES Konto
CREATE TABLE Konto konto-id ID not null, PRIMARY KEY (konto-id)
Prof. Dr. Nikolaus Wulff 48
Multiziplitäten und Navigation
Multiplizitäten,1:1, 1:N,N:M,werden in derUML explizit spezifiziert.
Ist die Assoziation nur in eine Richtungnavigierbar, so wirddies durch eine Pfeil-spitze angedeutet.
Notation Min Max
1 1
0 1
0
1
2 4
0..1
0..*
1..*
2..4
Prof. Dr. Nikolaus Wulff 49
Aggregation
• Eine Aggregation ist eine spezielle Form der Assoziation
• Sie stellt eine Ganzes-Teile Beziehung da– sie ist transitiv: ab und bc ac
– sie ist antisymmetrisch: ab (ba)
• Sie ist i.A. keine Ordnungsrelation (<=), da sie nicht reflexiv ist. aa ist immer falsch.
• Die Teile können außerhalb des Kontext des Ganzen vorkommen.
-a
Prof. Dr. Nikolaus Wulff 50
Aggregation „byValue“
• Eine spezielle Form der Aggregation, die eine stärkere Bindung der Teile an das Ganze beschreibt. (Physische Aggregation)
• Die Teile gehören genau zu einem Ganzen– eindeutig: ab und ac b c
• Es gibt immer ein Ganzes zu einem Teil– abgeschlossen: a b | ab
• Die Multiplizität auf der Seite des Ganzen ist immer eins und durch Löschen des Ganzen werden auch die Teile gelöscht.
• Java z.B. „Innere Klasse“
Prof. Dr. Nikolaus Wulff 51
o:Object
Qualifizierte Assoziation
• Durch Angabe eines Schlüssels lassen sich bei 1:N Beziehungen die Elemente vom Typ A genauer spezifizieren.
• Meist ist der Schlüssel eindeutig und aus einer 1:N wird eine 1:[0,1] Beziehung.
• In Java wird eine solche Assoziation häufig mit einer Map/Hashtable etc. implementiert.
• Die Qualifikation wird angegeben durch den Bezeichner (b) und den Typ (T) als b:T.
Prof. Dr. Nikolaus Wulff 52
Assoziations Klasse
• Häufig gibt es Eigenschaften einer Assoziation, die zu keinem der beiden Partner gehören. Dies wird dann in einer Assoziations Klasse modelliert.
• Aus ER Diagrammen kennt man dies bei n:m Beziehungen.
Prof. Dr. Nikolaus Wulff 53
Abhängigkeiten
• Klassen hängen von Objekten anderer Klassen ab, wenn sie
– diese als Übergabeparameter,
– als Rückgabewert oder
– als interne Hilfsvariable innerhalb
einer Methode verwenden
• diese Abhängigkeit wird als uses- oder creates-Relation beschrieben
• Abhängigkeiten werden häufig nicht modelliert und fallen erst im Compile-Step auf ...
«uses»
Prof. Dr. Nikolaus Wulff 54
Vererbung
• Schnittstellen werden vererbt.• Alle Kindklassen erben automatisch die
Implementierungen der Elternklasse.• Alle Objekte einer Vererbungshierarchie
haben den selben Typ (Shape)
Prof. Dr. Nikolaus Wulff 55
Vererbungsbeispiel/** * Oberklasse aller Shape Objekte */public abstract class Shape { protected int x,y; // ... public abstract void draw();}/** * Is-A Relation * Konkreter Subtype Circle */public class Circle extends Shape { public void draw() {
System.out.println(“x: “ + super.x); } // ...
Prof. Dr. Nikolaus Wulff 56
Polymorphismus/** * Ein Stück Code für alle Shape Objekte */void doMove(Shape s,int x,int y) {
s.erase(); s.setXY(x,y); s.draw();} ...Circle circ = new Circle();Square squa = new Square();Line line = new Line();
doMove(circ,1,4);doMove(squa,1,2);doMove(line,2,3);
Prof. Dr. Nikolaus Wulff 57
Assoziationen
• Objekte haben Beziehungen zu anderen Objekten:
• Eine Person hat eine Adresse. – Jedoch eine Adresse hat keine Person!
– Dies ist ein Beispiel einer gerichteten Assoziation.
Prof. Dr. Nikolaus Wulff 58
Personen-Adress Assoziation
/** * has-A Relation * Person Address */public class Person { private Address address; private String name, surname; // ...}/** * Address kennt Person nicht */public class Address { private String town, street; private int nr; // ...}
Prof. Dr. Nikolaus Wulff 59
KomponentendiagrammWindow Handler(whnd.cpp)
Window Handler(whnd.obj)
Comm Handler(comhnd.cpp)
Main Class(main.cpp)
Main Class(main.obj)
Comm Handler(comhnd.obj)
Graphic l ib(graphic.l ib)
Client Program(client.exe)
• Das Komponentendiagramm visualisiert die Be-ziehungen zwischen Komponenten und den zuge-hörigen Implementierungen.
Prof. Dr. Nikolaus Wulff 60
Modellierung der Dynamik
• Das statische Bild der Klassendiagramme ist meistens nicht deckungsgleich mit den Geflecht der Objekthierarchien zur Laufzeit.
• Typische Fragestellungen sind:– Wer erzeugt oder verwendet welches Objekt?
– Wann wird ein Objekt vernichtet?
– Wie laufen bestimmte Nachrichten oder Ereignisse durch das System?
– Wer sind die beteiligten Partner?
Prof. Dr. Nikolaus Wulff 61
Interaktionsdiagramme
• Die UML bietet zur Visualisierung dieser Problemstellung zwei verschiedene Interaktionsdiagrammtypen
– Sequenzdiagramme und
– Kollaborationsdiagramme
• Sie sind im wesentlichen äquivalent zum Inhalt einer CRC-Card.
Prof. Dr. Nikolaus Wulff 62
Sequenz und Kollaboration
• Ein Sequenzdiagramm zeigt die zeitliche Abfolge bestimmter Abläufe im System, mit der Zeit als y-Achse.
• Ein Kollaborationsdiagramm zeigt im Prinzip die selben Abläufe, jedoch ohne die Dimension der Zeit.
• Das Augenmerk richtet sich auf die Nachrichten-flüsse und das gemeinsame Handeln der betei-ligten Partner.
• UML Werkzeuge können aus dem Sequenz meistens das Kollaborationsdiagramm generieren.
Prof. Dr. Nikolaus Wulff 63
CRC Beispiel: Bestellung
Klasse: BestellwesenVerantwortung: Beteiligte:Bestellwunschentgegennehmen
User
Warenkorb suchen this
Bestellung erzeugen Bestellung
Bestellung in denWarenkorb legen
Bestellung, Warenkorb
Bestellung bestätigen User
Prof. Dr. Nikolaus Wulff 64
Beispiel: Sequenzdiagramm
: UserBestellWesen Bestellung Warenkorb
verschickeBestellung
create
hinzufügen
bestätigeBestellung
sucheWarenkorb
Prof. Dr. Nikolaus Wulff 65
Beispiel: Kollaborationsdiagramm
: User
BestellWesen
BestellungWarenkorb
2: sucheWarenkorb
1: verschickeBestellung
5: bestätigeBestellung
L
3: create
G
4: hinzufügen
Prof. Dr. Nikolaus Wulff 66
Modellierung der Dynamik (II)
• Sequenz- und Kollaborationsdiagramme beschreiben das Verhalten von vielen Objekten im Verbund.
• Eine Zustandsmaschine beschreibt das Verhalten eines einzelnen Objektes.
• Ein Zustandsdiagramm beschreibt die möglichen Zustände und Änderungen eines Objekts, als Antwort auf von aussen eintreffende Stimuli.
Prof. Dr. Nikolaus Wulff 67
Zustand eines Objekts
• Die Attribute eines Objekts repräsentieren seinen Zustand.
• Der mögliche Wertebereich unterliegt häufig bestimmten Regeln. Z.B. kann nicht beliebig zwischen diesen Werten gewechselt werden.
• Unter diesen Umständen macht es Sinn, von einem Status zu sprechen und den Wechsel der Werte als einen Statusübergang zu modellieren.
Prof. Dr. Nikolaus Wulff 68
StatusdiagrammStart
Angebotsphase Anlage
erfassen
übernehmen
erfassen
Eindecken
entry: Marzipan benachrichtigen
refinanzieren[ LG, LN, Objekt, Valutierung etc. erfasst ]
Aktiviert
do: LeistungseinzugÄnderungsmodus
entry: copyErzeugen
Abgeschlossen
exit: löschen
Ende
reorg
aktivieren[ Freigabe durch AL ]
Stati einer Finanzierung
aktivieren
ändern
ausgelaufen
abgelehntverworfen
Prof. Dr. Nikolaus Wulff 69
Strukturierung
• Systeme sind im allgemeinen komplex.
• Um sie verstehen zu können, werden sie in kleinere Einheiten/Komponenten unterteilt.
– => Schichtenarchitektur
• Hierzu werden logisch zusammenhängende Komponenten in Pakete eingeteilt.
• Die Abhängigkeiten zwischen Paketen werden in der UML in einem Packagediagramm visualisiert.
Prof. Dr. Nikolaus Wulff 70
Pragmatik: Packages
• Design Prinzip:– hohe Kohäsion innerhalb eines Paketes
– geringe Koppelung zwischen den Paketen
• Keine zyklischen Abhängigkeiten zwischen Paketen einbauen.
• Direkte Abhängigkeiten der Klassen zwischen Paketgrenzen vermeiden.
– => gegen öffentliche Schnittstellen programmieren.
– Klassen mit „Package scope“ verstecken.
Prof. Dr. Nikolaus Wulff 71
Hierarchische Paketstruktur
Client Server
Prof. Dr. Nikolaus Wulff 72
Packete verschachteln
UI Package
Microsoft Foundation Classes
(from UI Package)
Application Windows
(from UI Package)
ActiveX Components Package
(from UI Package)
Business Objects Package
Service Interface<<Facade>>
(from Business Objects Package)
Control Business Objects
(from Business Objects Package)
External Business Objects (Legacy System Wrapper)
(from Business Objec ts Package)
Entity Business Objects
(from Business Objects Package)
Database Package
ObjectTo Relational Translation Package
<<Facade>>
(from Database Package)
SQL Generator Package
(from Database Package)
Prof. Dr. Nikolaus Wulff 73
Verteilung der Komponenten
• Eine verteilte Anwendung besteht aus verschiedenen Komponenten, wie z.B AnwendungsServer, DatenbankServer, DruckServern, Kartenleser und Clients.
• Jede dieser Komponente stellt einen Knoten da, der nach der UML in einem Verteilungsdiagramm visualisiert wird.
Prof. Dr. Nikolaus Wulff 74
Verteilungsdiagramm J2EE
WebServer
DB Server
PrintServer
Web Client
CORBA Cl ient
EJB Client
http
ServletEngine
Legacy System
AppServer
iiop
jdbc
mqseries
Printer
rmi
JSPPlugIn
File System
Componente des Web Servers
Clients des AppServers
rmi - iiop
RMI Cl ient rmi
Prof. Dr. Nikolaus Wulff 75
Zusammenfassung• Die UML ist ein mächtiges Werkzeug in der Hand eines
guten Softwareentwicklers.
• Nicht alle Diagrammtypen sind in jedem Projekt gleich wichtig. => Augenmaß
• Daher sinnvoller Einsatz: was am Ende zählt ist das lauffähige Programm.
• Die Wahrscheinlichkeit qualitativ hochwertigen Code zu erzeugen wird durch den Einsatz der UML nicht geringer ;-)
• Wichtig ist die Integration des UML Tools in die Entwicklungsumgebung und Projektkultur!