Wenn du eine Hundehütte bauen willst, so reicht es …Prof. Dr. Nikolaus Wulff 1 Wenn du eine...

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


Agenda

• UML Historie

• Modellbildung

•

• Use Cases & Anforderungen

• Klassen & Assoziationen

• Dynamische Aspekte

• Struktur und Verteilung


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.


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.


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!


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!


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


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.


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


Modellebenen der Architektur

Implementierung & Komponenten

Verteilung& Maschinen

Prozesse & Threads

Analyse & Design

Use Case / Anforderungen


Gliederung der UML

• Die Diagrammtypen der UML lassen sich grob klassifizieren:

Statische Sicht KlassendiagrammKomponentendiagrammDeploymentdiagramm

DynamischeSicht

Use Case DiagrammSequenzdiagrammKollaborationsdiagrammZustandsdiagramm

Prozess Sicht Aktivitätendiagramm


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


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.


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


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.


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


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.


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


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.


UCD: Vertragerstellung

Systemgrenze

«uses»

«uses»«include»

«include»

ext. System alsAkteur modelliert

Akteure


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


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.


UseCase 4

UseCase 3

Von Abläufen zu Werkzeugen

UseCase 2

:= Material

:= WerkzeugKristallisationspunkt für ein potentielles Werkzeug

UseCase 1

:= Interaktionspfad des Benutzers


• 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


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.


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


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

...


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)


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.


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


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:


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.


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.


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:


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


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)


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 ?


Klassenbildung - Beispiel

Quelle: Grady Booch.Object-Oriented Analysis and Designwith Applications


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.


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.


• 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


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.


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)


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

~


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


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)


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


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


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“


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.


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.


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»


Vererbung

• Schnittstellen werden vererbt.• Alle Kindklassen erben automatisch die

Implementierungen der Elternklasse.• Alle Objekte einer Vererbungshierarchie

haben den selben Typ (Shape)


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); } // ...


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


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.


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; // ...}


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.


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?


Interaktionsdiagramme

• Die UML bietet zur Visualisierung dieser Problemstellung zwei verschiedene Interaktionsdiagrammtypen

– Sequenzdiagramme und

– Kollaborationsdiagramme

• Sie sind im wesentlichen äquivalent zum Inhalt einer CRC-Card.


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.


CRC Beispiel: Bestellung

Klasse: BestellwesenVerantwortung: Beteiligte:Bestellwunschentgegennehmen

User

Warenkorb suchen this

Bestellung erzeugen Bestellung

Bestellung in denWarenkorb legen

Bestellung, Warenkorb

Bestellung bestätigen User


Beispiel: Sequenzdiagramm

: UserBestellWesen Bestellung Warenkorb

verschickeBestellung

create

hinzufügen

bestätigeBestellung

sucheWarenkorb


Beispiel: Kollaborationsdiagramm

: User

BestellWesen

BestellungWarenkorb

2: sucheWarenkorb

1: verschickeBestellung

5: bestätigeBestellung

L

3: create

G

4: hinzufügen


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.


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.


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


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.


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.


Hierarchische Paketstruktur

Client Server


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


External Business Objects (Legacy System Wrapper)

(from Business Objec ts Package)

Entity Business Objects


Database Package

ObjectTo Relational Translation Package

<<Facade>>

(from Database Package)

SQL Generator Package

(from Database Package)


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.


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


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!

Wenn du eine Hundehütte bauen willst, so reicht es …Prof. Dr. Nikolaus Wulff 1 Wenn du eine...

Documents

Transcript of Wenn du eine Hundehütte bauen willst, so reicht es …Prof. Dr. Nikolaus Wulff 1 Wenn du eine...