Einführung in UML

Transcription

Einführung in UML

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 halbwegs
passable Hundehütte entstehen.
So lange sie gross genug ist, wird der Hund glücklich sein.
Falls nicht, ist es kein Problem wieder von vorne anzufangen
oder den Hund zu tauschen ...
Wenn du ein Hochhaus bauen willst ist dieser Ansatz idiotisch!
Grady Booch
Prof. Dr. Nikolaus Wulff
1
Softwaredesign
mit der UML
Eine Einführung in die Unified Modelling Language
Agenda
•
•
•
•
•
•
•
UML Historie
Modellbildung
Use Cases & Anforderungen
Klassen & Assoziationen
Dynamische Aspekte
Struktur und Verteilung
3
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.
4
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.
5
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!
6
Softwareentwicklung ist Modellbildung
Anforderer
AnforderungsModelle
Benutzer
Sicherheitssysteme
Datenbank
Use Case Modelle
HW/SW
Systeme
OberflächenModelle
Subsysteme
Sprachen
Klassenmodelle
Objektmodelle
TestModelle
ImplementierungsModelle
Modelle nicht als Wasserfall sondern inkrementell entwickeln!
7
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
8
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.
9
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
10
Modellebenen der Architektur
Analyse & Design
Implementierung
& Komponenten
Use Case /
Anforderungen
Prozesse
& Threads
Verteilung
& Maschinen
11
Gliederung der UML
• Die Diagrammtypen der UML lassen sich grob
klassifizieren:
Statische Sicht
Klassendiagramm
Komponentendiagramm
Deploymentdiagramm
Dynamische
Sicht
Prozess Sicht
Use
Case Diagramm
Sequenzdiagramm
Kollaborationsdiagramm
Zustandsdiagramm
Aktivitätendiagramm
12
Diagramme der UML (I)
Diagramm
Aktivität
Einsatzgebiet
Use Case
Anforderung,
Festlegung,
Erstellung,
Übergabe
Festlegung,
Erstellung
Anforderung,
Festlegung,
Erstellung,
Übergabe
Geschäftsprozesse,
allgemeine Einsatzmöglichkeiten
Klassendiagramm
Interaktionsdiagramm
 Sequenzdiagramm
 Kollaborationsdiagramm
Zustandsdiagramm
So gut wie überall; das Klassendiagramm
ist das wichtigste Diagramm der UML
Zeigt den Nachrichtenfluß und damit die
Zusammenarbeit der Objekte im zeitlichen
Ablauf.
 Zeitliche Aufrufstruktur mit wenigen
Klassen
 Zeitliche Aufrufstruktur mit wenigen
Nachrichten
Anforderung, Darstellung des dynamischen Verhaltens
Festlegung,
Erstellung,
Übergabe
13
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.
14
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 ...
15
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.
16
Use Case Beispiel
Kurzbeschreibung
Beteiligte Akteure
Auslöser
Eingaben
Ausgaben
Vorbedingungen
Nachbedingungen
Häufigkeit
1.
1.1.
1.2.
1.3.
2.
2.1.
SB
Finanzierung berechnen
Die Finanzierungskonditionen eines Leasingpaketes wird nach Anfrage
der Leasinggesellschaft durchgeführt.
SB
Sachbearbeiter Leasing-Abteilung
SYS
Das EDV System zur „Leasing (Re)Finanzierung “
Anfrage eine Leasinggesellschaft
Leasinggesellschaft und Leasingvertrag
Angebot(e) für eine Finanzierung
Leasinggesellschaft muss mit ihren Konditionen im System bekannt
sein
Angebotsmappe ist der Leasinggesellschaft zugeordnet
Tag: 10- 20 / SB Woche: Monat: Jahr:
Ablauf:
Sucht die LG aus
Eingabe der LV Daten
Durchführung der Berechnung
Ausnahmen und Varianten
A1.4.
SB
A1.4.1
V1.8.
V1.8.1
Neue Leasinggesellschaft
Qualitätssicherung
17
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.
18
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
19
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.
20
UCD: Vertragerstellung
Systemgrenze
ext. System als
Akteur modelliert
«include»
Akteure
«uses»
«include»
«uses»
21
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 ...
22
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.
23
Von Abläufen zu Werkzeugen
UseCase 1
UseCase 2
UseCase 3
UseCase 4
:= Material
Kristallisationspunkt für
ein potentielles Werkzeug
:= Werkzeug
:= Interaktionspfad
des Benutzers
24
Klassen und Objekte
• 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
25
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.
26
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
27
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> {
...
28
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)
29
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.
30
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ß.
31
Formular- und Benutzersichtanalyse
• Ableitung von Klassenkandidaten aus Dokumenten, die
Arbeitsergebnisse beinhalten, z.B.
– Layouts für Bildschirmausgaben
– Listen, Formulare, Tabellen
Bestellung
Kundennr:
Lieferanschrift
Name:
Straße:
PLZ:
Ort:
Artikelnr.
Artikelbezeichnung
Zahlungsart:  Überweisung
Datum:

Telefonisch erreichbar:
Vorname:
Hausnr.
Einzelpreis
Nachnahme
Unterschrift:
Menge
Gesamtpreis
total:
• Klassenkandidaten: Kunde, Artikel, Lieferanschrift,
Zahlungsart
32
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.
33
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.
34
Pragmatik: CRC Karten
• Das Verhalten und die Verantwortlichkeiten
von Klassen lassen sich gut durch eine Use
Case Analyse und CRC* Karten finden.
Klasse:
Verantwortung:
Beteiligte:
Muster für eine CRC Karte
*) CRC: Classes, Responsibilities and Collaborators
35
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
36
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)
37
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 ?
38
Klassenbildung - Beispiel
Quelle: Grady Booch.
Object-Oriented Analysis
and Design
with Applications
39
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.
40
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.
41
Relationen
• 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
42
Generalisierung
• Generalisierung beschreibt die Vererbungsbeziehung 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.
43
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)
44
Diagramm und Code
public class KontoListe {
/** Ein Vector mit Konten für die
Implementierung der Assoziation
*/
private List 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 (Konto)konten.get(index);
}
} // end class KontoListe
45
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!!!
46
Pragmatik (II)
• 1:N und N:M Assoziationen werden im OOKlassendesign anders implementiert, als man dies
aus der Umsetzung von ER-Modellen für
relationale Datenbanken i.A. gewohnt ist:
CREATE TABLE Konto
konto-id
ID not null,
PRIMARY KEY (konto-id)
CREATE TABLE Buchung
buchung-id
ID not null,
konto-id
ID not null,
PRIMARY KEY (buchung-id),
FOREIGN KEY (konto-id) REFRENCES Konto
47
Multiziplitäten und Navigation
Multiplizitäten,
1:1, 1:N,N:M,
werden in der
UML explizit
spezifiziert.
Ist die Assoziation
nur in eine Richtung
navigierbar, so wird
dies durch eine Pfeilspitze angedeutet.
Notation
0..1
0..*
1..*
2..4
Min Max
1
1
0
1
0

1

2
4
48
Aggregation
• Eine Aggregation ist eine spezielle Form der
Assoziation
• Sie stellt eine Ganzes-Teile Beziehung da
-a
– sie ist transitiv: ab und bc ac
– sie ist antisymmetrisch: ab ba)
• Sie ist i.A. keine Ordnungsrelation (<=), da sie
nicht reflexiv ist. aa ist immer falsch.
• Die Teile können außerhalb des Kontext des
Ganzen vorkommen.
49
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: ab und ac b c
• Es gibt immer ein Ganzes zu einem Teil
– abgeschlossen: a b | ab
• 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“
50
Qualifizierte Assoziation
o:Object
• 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.
51
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.
52
Abhängigkeiten
• Klassen hängen von Objekten anderer Klassen ab,
«uses»
wenn sie
– diese als Übergabeparameter,
– als Rückgabewert oder
– als interne Hilfsvariable innerhalb
einer Methode verwenden
• diese Abhängigkeit wird als uses- oder createsRelation beschrieben
• Abhängigkeiten werden häufig nicht modelliert
und fallen erst im Compile-Step auf ...
53
Vererbung
• Schnittstellen werden vererbt.
• Alle Kindklassen erben automatisch die
Implementierungen der Elternklasse.
• Alle Objekte einer Vererbungshierarchie
haben den selben Typ (Shape)
54
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);
}
// ...
55
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);
56
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.
57
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;
// ...
}
58
Komponentendiagramm
Window Handler
(whnd.cpp)
Window Handler
(whnd.obj)
Graphic lib
(graphic.lib)
Comm Handler
(comhnd.cpp)
Comm Handler
(comhnd.obj)
Main Class
(main.cpp)
Client Program
(client.exe)
Main Class
(main. obj)
• Das Komponentendiagramm visualisiert die Beziehungen zwischen Komponenten und den zugehörigen Implementierungen.
59
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?
60
Interaktionsdiagramme
• Die UML bietet zur Visualisierung dieser
Problemstellung zwei verschiedene
Interaktionsdiagrammtypen
– Sequenzdiagramme und
– Kollaborationsdiagramme
• Sie sind im wesentlichen äquivalent zum Inhalt
einer CRC-Card.
61
Sequenz und Kollaboration
• Ein Sequenzdiagramm zeigt die zeitliche Abfolge
bestimmter Abläufe im System, mit der Zeit als yAchse.
• Ein Kollaborationsdiagramm zeigt im Prinzip die
selben Abläufe, jedoch ohne die Dimension der
Zeit.
• Das Augenmerk richtet sich auf die Nachrichtenflüsse und das gemeinsame Handeln der beteiligten Partner.
• UML Werkzeuge können aus dem Sequenz
meistens das Kollaborationsdiagramm generieren.
62
CRC Beispiel: Bestellung
Klasse: Bestellwesen
Verantwortung: Beteiligte:
Bestellwunsch
entgegennehmen
Warenkorb suchen
Bestellung erzeugen
Bestellung in den
Warenkorb legen
Bestellung bestätigen
User
this
Bestellung
Bestellung, Warenkorb
User
63
Beispiel: Sequenzdiagramm
: User
BestellWesen
Bestellung
Warenkorb
verschickeBestellung
sucheWarenkorb
create
hinzufügen
bestätigeBestellung
64
Beispiel: Kollaborationsdiagramm
2: sucheWarenkorb
1: verschickeBestellung
BestellWesen
5: bestätigeBestellung
: User
3: create
4: hinzufügen
G
L
Bestellung
Warenkorb
65
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.
66
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.
67
Statusdiagramm
Start
erfassen
Angebotsphase
Stati einer Finanzierung
erfassen
übernehmen
Anlage
refinanzieren[ LG, LN, Objekt, Valutierung etc. erfasst ]
Eindecken
verworfen
abgelehnt
entry: Marzipan benachrichtigen
aktivieren[ Freigabe durch AL ]
aktivieren
Aktiviert
Abgeschlossen
Änderungsmodus
do: Leistungseinzug
exit: löschen
entry: copyErzeugen
ausgelaufen
ändern
reorg
Ende
68
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.
69
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.
70
Hierarchische Paketstruktur
Client
Server
71
Packete verschachteln
UI Package
Business Objects Package
Microsoft Foundation
Classes
(from UI Package)
ActiveX Components
Package
(from UI Package)
<<Facade>>
Service Int erface
(from Business Objects Package)
Application Windows
(from UI Package)
External Business Objects (Legacy
System Wrapper)
Control Business Objects
(from Business Objec ts Package)
Entity Business Objects
Database Package
<<Facade>>
ObjectTo Relational
Translation Package
SQL Generator Package
(from Database Package)
(from Database Package)
72
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.
73
Verteilungsdiagramm J2EE
Web
Client
Web
Server
http
Servlet
Engine
File
System
JSP
Plug In
Clients des Ap
pServers
Componente des
Web Servers
rmi
EJB
Client
rmi - iiop
RMI
Cl ie nt
App
Server
rmi
jd bc
DB
Server
iiop
CORBA
Cl ient
mqseries
Legacy
System
Print
Server
Printer
74
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!
75

Einführung in UML

Transcription

Documents pareils

Das Haus des Nikolaus - Dr. Andreas M. Seifert

Pastoralverbund Büren | St. Nikolaus Pfarrkirche

Awerizo und der Heilige Nikolaus Franz Kett

bad säckingen: 25 jahre zahnarztpraxis dr. nikolaus– ANZEIGE –

Iphigenie trifft Hamlet

UNSER TÄGLICH BROT Interview Wolfgang Widerhofer

Pressetext herunterladen als

Nikolaus Heidelbach

Tagungsbericht "Journalismus ohne Grenzen? Medien zwischen