Download - Grundlagen Objekt-orientierter Modellierung
© 2002, W. Pree 1
Grundlagen Objekt-orientierterModellierung
Analyse und Design mit UML
O.Univ.-Prof. Dipl.-Ing. Dr. Wolfgang Pree
www.SoftwareResearch.net
© 2002, W. Pree, OOAD/UML 2
OO Analyse-und Design-
Tools
© 2002, W. Pree, OOAD/UML 3
In OO gesetzteErwartungen
Verbesserte Modularisierung Verbesserte Wiederverwendbarkeit
Potential von wiederverwendbaren OO SW-Architekturen (= generischen komplexen Komponenten)wurde bisher keineswegs ausgeschöpft
Durchgängiges Denkmodell Analyse → Design → Implementierung
Wichtige Grundlage: Unterstützung der OOModellierung
© 2002, W. Pree, OOAD/UML 4
Was ist von OOAD-Toolszu erwarten? (I)
Great designs come from greatdesigners, not from great tools.
Tools help bad designers createghastly designs much morequickly.
Grady Booch(1994)
© 2002, W. Pree, OOAD/UML 5
Was ist von OOAD-Toolszu erwarten? (II)
OO Analyse- und Design- (OOAD)Werkzeuge können fogende Aufgabenübernehmen:
Erstellen und Editieren von Diagrammenbasierend auf diversen OO Notationen
Konsistenz- und Constraint-Checkshat ein Objekt die aufgerufene Methode?werden die Invarianten (nur eine Instanz, etc.)
eingehalten? . . .
Prüfungen auf Vollständigkeitwerden alle Methoden/Klassen benutzt? . . .
© 2002, W. Pree, OOAD/UML 6
Konventionelle (SA/SD)versus OO Werkzeuge (I)
Unterschiede ergeben sich in zweierlei Hinsicht:
(1) Software-Architektur Konventionelle Werkzeuge basieren auf einer
Trennung von Daten (ER-Modell) undFunktionen
OO Werkzeuge bieten bessereAusdrucksmittel, um Objekte als in sichgeschlossene Einheiten aus Daten undFunktionen zu sehen und darzustellen
© 2002, W. Pree, OOAD/UML 7
Konventionelle (SA/SD) versusOO Werkzeuge (II)
(2) Semantische MöglichkeitenKonventionelles ER-Modell:has_a (1:1)is_a (1:1)owns, contains, is_contained_in (1:m)consists_of (m:m)
© 2002, W. Pree, OOAD/UML 8
Konventionelle (SA/SD)versus OO Werkzeuge (III)
Bei OO Modellierung werden umfangreichereund vom ER-Modell abweichendeAusdrucksmöglichkeiten geboten:Klassen-/Objektbeziehungen: inheritance association (friend, virtual, static) has-a (by value, by reference) uses-a (by value, by reference) is_abstract, is_metaclass,
is_parameterized . . .Zugriffsrechte
© 2002, W. Pree, OOAD/UML 9
Methodenlandschaft zuBeginn der 90er Jahre
OOD / Rational RoseGrady Booch
Object Modeling Technique (OMT)James Rumbaugh et al.
OO Software EngineeringIvar Jacobson et al.
OO Analysis (OOA)Peter Coad und Ed. Yourdon
Responsibility-Driven Design (RDD)Rebecca Wirfs-Brock et al.
OO System Analysis (OOSA)Sally Shlaer and Steve Mellor
. . .
© 2002, W. Pree, OOAD/UML 10
Beispiel für Booch-Notation
aa
Folder
TextDocument
Mailer
1
N
1
1
N
N
© 2002, W. Pree, OOAD/UML 11
Beispiel fürOMT-Notation
aaaa
Mailer
... ...Folder
Mailbox
EmployeeGroup
Employee DesktopItem
© 2002, W. Pree, OOAD/UML 12
Gemeinsamkeiten vonOOAD-Methoden (I)
Sie zielen darauf ab, die reale Welt ohne künstlicheTransformationen auf Software-Systemeabzubilden:
Anwendung gleicher Ideen und Konzepte inallen Phasen der Software-Entwicklung
Grenze zwischen Analyse und Design verschwimmt stärker
Dazu werden sehr vage Richtlinienangegeben.
© 2002, W. Pree, OOAD/UML 13
Gemeinsamkeiten vonOOAD-Methoden (II)
OOAD Methoden erlauben die Modellierung folgenderAspekte eines Systems:
statische Aspekteim Vordergrund steht das Klassen-
/Objektmodell,auf höhere Abstraktion werden Subsysteme
entworfen
dynamische AspekteZustandsübergangsdiagramme, Interaktionsdiagramme
© 2002, W. Pree, OOAD/UML 14
Unterschiede zwischenOOAD-Methoden
Die Unterschiede zwischen den Methoden liegeninsbesondere in der Notation.Dennoch sind die Notationen in den einzelnenOOAD-Methoden weitgehend sprachunabhängig.
=> Vereinheitlichung ist naheliegend (→ UML)
All of the OO methodologies havemuch in common and should becontrasted more with non-OOmethodologies than with each other.
James Rumbaugh(1991)
© 2002, W. Pree, OOAD/UML 15
UML-Einflüße
Die Unified Modeling Language (UML) enhältdiverse Aspekte und Notationen aus verschiedenenMethoden:
BoochHarel (State Charts)Fusion (Methodennummerierung)
Rumbaugh (Notation) Jacobson (Use Cases) Wirfs-Brock (Responsibilities) Shlaer-Mellor (Object Life Cycles) Meyer (Pre- und Post-Conditions)
© 2002, W. Pree, OOAD/UML 16
UML-Standard
Der erste Draft (Version 0.8) wurde im Oktober 1995publiziert.
Diverse Anpassungen und die Einbeziehung von IvarJacobson führten zu Version 0.9 im Oktober 1996.
Version 1.0 wurde der Object Management Group (OMG)im Juli 1997 als Grundlage zur Standardisierung vorgelegt.
Im September 1997 wurden noch diverse Details inVersion 1.1 modifiziert.
1998 und 1999 ist die Standardisierung wesentlicherElemente vorangetrieben worden.
Im April 1999 wurde Version 1.3 veröffentlicht.
© 2002, W. Pree, OOAD/UML 17
The Unified ModelingLanguage(I)
Was ist die UML? Sprache
KommunikationAustausch von Ideen
ModellierungsspracheVokabeln und Regeln für die Darstellung von
Aspekten eines Systems
© 2002, W. Pree, OOAD/UML 18
The Unified ModelingLanguage(II)
Was ist die UML nicht? Keine Methode
Spezifiziert wie Modelle gemacht werden,aber nicht welche und wann.
Aufgabe des Entwicklungsprozesses
Prozess + Modellierungssprache = Methode
© 2002, W. Pree, OOAD/UML 19
The Unified ModelingLanguage(III)
Wofür braucht man die UML?
Visualisierung von Modellen Spezifikation von Modellen Konstruktion des Systems
Forward and Reverse Engineering Dokumentation des Systems
© 2002, W. Pree, OOAD/UML 20
The Unified ModelingLanguage(IV)
Modelle Projektionen des Systems auf eine
Sichtweise Für das Verständnis des Systems
© 2002, W. Pree, OOAD/UML 21
OO KonzepteDarstellung in UML
Objekte, Klassen, Nachrichten/Methoden Vererbung, Polymorphismus, Dynamische Bindung Abstrakte Klassen, abstrakte Kopplung
© 2002, W. Pree, OOAD/UML 22
OO vs Prozedural
Prozedural Trennung von Daten und Prozeduren
© 2002, W. Pree, OOAD/UML 23
OO vs Prozedural
Objekt-orientiert: Daten und Prozeduren bilden eine logische
Einheit ein Objekt
© 2002, W. Pree, OOAD/UML 24
Objekte(I)
Ein Objekt ist eine Repräsentation einer
konkreten Einheit, wieeiner Person, einem Auto, etc.
oder einer logischen Einheit, wieeinem chemischen Prozess, einer mathematischen Formel, etc.
© 2002, W. Pree, OOAD/UML 25
Objekte(II)
Die wesentlichen Merkmale einesObjektes sind:
Seine Identität Sein Zustand Sein Verhalten
© 2002, W. Pree, OOAD/UML 26
Objekte(III)
ZustandDer Zustand eines Objektes besteht aus seinenstatischen Eigenschaften und derendynamischen Werten.
Werte können primitiv sein: int, double,boolean
Werte können Referenzena auf andereObjekte oder selbst andere Objekte sein
© 2002, W. Pree, OOAD/UML 27
Objekte(IV)
Beispiel Getränkeautomat Zustand: Bereit Zustand: Bezahlt Zustand: Bereit
Eigenschaften – Werte Bezahlt:boolean Dosen:Menge von Dosen
Bezahlen
Getränk ausgeben
© 2002, W. Pree, OOAD/UML 28
Objekte(V)
Das Verhalten von Objekten wirdspezifiziert durch Methoden (=Operationen).
Im Prinzip sind Methoden konzeptionellwie Prozeduren/Funktionen:Methode = Name + Parameter +
Rückgabeparameter
© 2002, W. Pree, OOAD/UML 29
Objekte(VI)
Beispiel Quadrat:
Name der Operation: setzeFarbeParameter: Name der Farbe (z.B.: Rot)Rückgabeparameter: keine
Das Aufrufen einer Operation(z.B.:setzeFarbe) eines Objektes wird alsSchicken einer Nachricht an dasObjekt bezeichnet.
© 2002, W. Pree, OOAD/UML 30
Objekte(VII)
IdentitätIdentität ist die Eigenschaft einesObjektes, die es von allen anderenunterscheidet.
Zwei Objekte können verschieden sein,auch wenn ihre Eigenschaften, Werte undOperationen übereinstimmen.
© 2002, W. Pree, OOAD/UML 31
Objekt-Orientierung
Klassifikation Gruppierung von Objekten
Polymorphismus Statische und dynamische Typen Dynamischen Binden
Vererbung Hierarchien von Typen
© 2002, W. Pree, OOAD/UML 32
Klassifikation(I)
KlasseEine Klasse ist eine Menge von Objekten, diegleiche Struktur und gleiches Verhaltenhaben.
KlasseEine Klasse ist eine Schablone, aus der Objektegeneriert werden können.
© 2002, W. Pree, OOAD/UML 33
Klassifikation(II)
Klasse: Person Eigenschaften: Name:String, Alter:int.... Operationen: schlafe, esse, ...
Objekt vom Typ Person: Steffen Eigenschaften: Name:Steffen, Alter:24
© 2002, W. Pree, OOAD/UML 34
Klasse als Schablone/Typ (I)
Vergleich mit der Sprache C:struct{
int day, month, year;
} date;
date d1, d2;
=> alles zugreifbar, keine Methoden
© 2002, W. Pree, OOAD/UML 35
Klasse als Schablone/Typ (II)
© 2002, W. Pree, OOAD/UML 36
Klasse als Schablone/Typ (III)
Eine Klasse gibt an, von welchem Typeine Objekt ist, d.h. welche Nachrichtenes versteht und welche Eigenschaften eshat.
Eine Klasse besteht aus: einem eindeutigen Name Attributen(=Eigenschaften) und deren Typen Methoden/Operationen
© 2002, W. Pree, OOAD/UML 37
Klassen in UML(I)
UML Notation einer Klasse:BeispielStruktur
© 2002, W. Pree, OOAD/UML 38
Klassen in UML (II)
Notation für Attribute:A nur der Attributname: C nur der Name der AttributklasseA : C Attributname und KlasseA : C = E w. o.; zusätzliche Definition eines
AttributwertestimeWhenStarted → A: Date → : CtimeWhenStarted : Date → A : CtimeWhenStarted : Date = 1.1.1999 → A : C = EtimeWhenStarted = 1.1.1999 → A = E
© 2002, W. Pree, OOAD/UML 39
Klassen in UML (III)
Notation für Methoden/Operationen:
m() nur der Methodennamem(arguments): R Methodenname, Argumente, Rückgabeparametertyp
Beispiele:printInvoice() → m()printInvoice(itemNo: int): bool →m(arguments): R
© 2002, W. Pree, OOAD/UML 40
Klassen in UML(IV)
Sogenannte Adornments (dt.: Schmuck, Zierde)ergänzten in der Booch-Methode Notationselemente undwurden durch ein Dreieckssymbol dargestellt.
Methoden und Attribute haben in UML grafischeSymbole beigefügt, um die Zugriffsrechte (public,protected, private) auszudrücken.Beispiel:
+schlafe(Stunden:int)
© 2002, W. Pree, OOAD/UML 41
Beispiel: Zugriffsrechte
Unnötige Komplexität, dakeine Abhängigkeit zw. xund y besteht
besser
© 2002, W. Pree, OOAD/UML 42
Klassen in Java
public class Person{
String name; int age; ...
public int getAge(){ return age; } public void setAge(int theAge){ age = theAge; }}
Name derKlasse
Eigenschaften
Operationen
© 2002, W. Pree, OOAD/UML 43
Verwendung von Klassenin Java
Klassen werden in Java dazu verwendet,den Typ von Variablen festzulegen undObjekte zu instanziieren
Schlüsselwort: new Beispiel
Person manager = new Person(„Steffen“);
Deklaration derVariable„manager“
Instanziierung einesObjektes der Klasse Personmit dem Namen Steffen
© 2002, W. Pree, OOAD/UML 44
Beispiel:Hotelreservierung
Was könnte man bei einermHotelreservierungsystem als Klassenmodellieren?
Welche Eigenschaften haben dieseKlassen?
Welche Operationen? Welche Instanzen(Objekte) dieser
Klassen könnte es geben?
© 2002, W. Pree, OOAD/UML 45
Objekte in UML
Notation in UML
Objektdiagramme stellen einen Laufzeit-Schnappschuss des Systems dar. Dabeiwerden Objekte und Verbindungenzwischen den Objekten dargestellt, die ausdrücken,daß zwischen den Objekten navigiert werden kann
© 2002, W. Pree, OOAD/UML 46
Objektdiagramme
... mehr dazu bei Sequenz-diagrammen
© 2002, W. Pree, OOAD/UML 47
Klassenbeziehungen (I)
Eine Association zwischen zwei Klassen kann durch die anderenBeziehungen verfeinert werden.
Oft modelliert man zunächst nur die Tatsache, daß zwei Klassenuntereinander in Beziehung stehen und verfeinert später diesesallgemeine Notationselement.
Association
InheritanceAggregation (has-a)
Abhängigkeit
© 2002, W. Pree, OOAD/UML 48
Klassenbeziehungen (II)
Jede der Beziehungen kann durch einen Text-Labelgenauer gekennzeichnet werden (→ ER-Modell).
Zusätzlich können an den Enden einer AssociationRollen-Namen spezifiziert werden.
Eine Klasse kann auch eine Association auf sichselbst haben. Damit wird ausgedrückt, daß Objekte dergleichen Klasse in Beziehung stehen.
© 2002, W. Pree, OOAD/UML 49
Klassenbeziehungen (III)
Die Kardinalität von Beziehungen kann wie in der ER-Notation jeweils amEnde einer Beziehung angegeben werden:
1 genau eins* beliebig (0 oder mehr)0..* beliebig (0 oder mehr)1..* 1 oder mehr0..1 0 oder eins2..5 Wertebereich1..5, 9 Wertebereich oder genaue Zahl
© 2002, W. Pree, OOAD/UML 50
Klassenbeziehungen (IV)
Beispiel:
© 2002, W. Pree, OOAD/UML 51
VererbungPolymorphismus
Dynamische Bindung
© 2002, W. Pree, OOAD/UML 52
Vererbung(I)
Klassen definiren den Typ eines Objektes Modelliert man beispielsweise eine
Klasse Kunde und eine KlasseFirmenkunde, so sollte jedes Objekt vomTyp Firmenkunde auch vom Typ Kundesein. Der Typ Firmenkunde ist einUntertyp vom Typ Kunde.
© 2002, W. Pree, OOAD/UML 53
Vererbung(II)
Eine Oberklasse verallgemeinert eineUnterklasse
Eine Unterklasse spezialisiert eineOberklasse
Eine Unterklasse erbt alle Methoden undEigenschaften einer Oberklasse.
© 2002, W. Pree, OOAD/UML 54
Vererbung(III)
Eine Unterklasse hat folgendeMöglichkeiten, ihr Verhalten zuspezialisieren: Neue Operationen und Eigenschaften definieren Die Implementation bestehender Operationen
modifizieren (eine Methode „überschreiben“).
Flache Sicht:
aa
iv1iv2iv3
m1()m2()m3()m4()
m1()m4()m5()
iv4
aa
iv1iv2iv3
m1()m2()m3()m4()
m5()m4()m3()m2()m1()
iv4iv3iv2iv1
© 2002, W. Pree, OOAD/UML 55
Vererbung(IV)
UML Notation:
© 2002, W. Pree, OOAD/UML 56
Vererbung (V)
“Delta”-Sicht „Flache“ Sicht(nicht in Standard UML!)
© 2002, W. Pree, OOAD/UML 57
Vererbung (VI)—in Java
Java unterstützt einfache Vererbung, d.h.Jede Klasse hat höchstens eineOberklasse.
Das Schlüsselwort ist extends.
public class Firmenkunde extends Kunde{ ...}
© 2002, W. Pree, OOAD/UML 58
Polymorphismus (I)
Sogenannte Objekttypen sind poly (= viel)morph (= Gestalt). Anschaulich ist das mit„Steckerkompatibilität“ vergleichbar:
„Stecker“-StandardObjekte, die zu diesemStecker kompatibel sind
© 2002, W. Pree, OOAD/UML 59
Polymorphismus (II)
Objekte vom Typ Firmenkunde(Unterklasse) haltenmindestens den selben Vertrag ein wie Objekte vom TypKunde(Oberklasse).Es ist daher sinnvoll, zu definieren, daß ein Objekt einerKlasse Ai, die eine Unterklasse von A ist, nicht nur den TypAi sondern auch den Typ aller Oberklassen von Ai hat,insbesondere natürlich den Typ A.Das heißt, daß ein Objekt nicht nur einen Typ sondernbeliebig viele Typen hat. Die Anzahl ist abhängig von derPosition jener Klasse in der Klassenhierarchie, aus der dasjeweilige Objekt generiert wurde.Der Objekttyp ist also poly (= viel) morph (= Gestalt).
© 2002, W. Pree, OOAD/UML 60
Polymorphismus-Beispiel (I)
Kunde kunde= new Kunde();Privatkunde privatkunde = new Privatkunde();Firmenkunde firmenkunde = new Firmenkunde();
© 2002, W. Pree, OOAD/UML 61
Polymorphismus-Beispiel (II)
kunde=privatkunde; //OK kunde=firmenkunde;//OK
© 2002, W. Pree, OOAD/UML 62
Polymorphismus-Beispiel (III)
privatkunde = kunde; //Fehler firmenkunde = kunde ; //analog
© 2002, W. Pree, OOAD/UML 63
Polymorphismus-Beispiel(IV)
Der Grund liegt darin, daß ein von „kunde“referenziertes Objekt (d.h.:, wenn es eine Instanzvon Kunde ist) nicht unbedingt Methodenaufrufeverstehen muß, die Instanzen von Unterklassenvon Kunde verstehen würden:
firmenkunde=kunde;firmenkunde.rechneFuerMonatAb();
würde in einem Laufzeitfehler resultieren ("keineMethode zum Methodenaufruf gefunden" ="Methodenaufruf nicht verstanden"), wenn kunde(und nach der Zuweisung auch firmenkunde) einObjekt referenziert, das z.B. aus Kunde generiertwurde.
© 2002, W. Pree, OOAD/UML 64
Statischer und dynamischerTyp von Variablen
In objektorientierten Sprachen mit strenger Typenprüfung(wie in Java, Eiffel, Oberon, C++) muß man zwischeneinem statischen und einem dynamischen Datentypunterscheiden:
der statische Typ einer Variable ist der Typaufgrund der Variablendeklaration im (statischen)Programmtext
der dynamische Typ einer Variable ist der Typ desreferenzierten Objektes zur Laufzeit
Eine Variable hat somit exakt einen statischen Typ. ZurLaufzeit kann sie mehrere dynamische Typen annehmen(abhängig von der Breite und Tiefe der Klassenhierarchie).Im zuvor präsentierten Beispiel hat die Variable kunde denstatischen Typ Kunde. Nach der Zuweisung kunde =firmenkunde hat sie nach wie vor den statischen TypKunde, jedoch den dynamischen Typ Firmenkunde, da sienun eine Instanz der Klasse Firmenkunde referenziert.
© 2002, W. Pree, OOAD/UML 65
Dynamische Bindung (I)
Dynamische Bindung heißt, daß der Compiler nicht festlegt, welcheMethode zur Laufzeit aufgerufen wird. Welche Methode tatsächlich zurLaufzeit aufgerufen wird, hängt
vom Methodennamen vom dynamischen Typ der Variable
ab.
Beispiel (basierend auf zuvor präsentierter Klassenhierarchie):
Kunde kunde= new Firmenkunde; // durch Polymorphismus möglichkunde.pruefeObStammkunde();
© 2002, W. Pree, OOAD/UML 66
Dynamische Bindung (II)
Die Variable kunde referenziert ein Objekt, das aus der KlasseFirmenkunde generiert wurde (kunde hat also den dynamischenTyp Firmenkunde). Es wird daher die MethodepruefeObStammkunde(), wie sie in Firmenkundeimplementiert ist, ausgeführt.
In Java sind alle Methoden dynamisch gebunden, außer manmarkiert sie explizit, indem man das Schlüsselwort static vor dieMethodendefinition stellt.(In C++ müssen hingegen Methoden explizit als "dynamischgebunden" markiert werden. Dazu wird das Schlüsselwort virtualvor die Methodendeklaration gestellt.)
© 2002, W. Pree, OOAD/UML 67
Dynamische Bindung (III)
Dynamische Bindung heißt, daß es vom eingestecktenObjekt abhängt, welche Methode tatsächlichausgeführt wird. Das gelbe Objekt implementiert m1()zB anders als das rote Objekt:
m1()
m1()
m1()
call m1
© 2002, W. Pree, OOAD/UML 68
Type-Test und Type-Guardin Java
Type-Test: Abfrage des dynamischen TypsType-Guard: Laufzeit-geprüfte Typumwandlung (::Type-Cast)
Beispiele:if (kunde instanceof Firmenkunde) { // type test Firmenkunde fKunde= (Firmenkunde )kunde; // type guard
...}
if (kunde instanceof Firmenkunde) ((Firmenkunde)kunde).rechneFuerMonatAb();
© 2002, W. Pree, OOAD/UML 69
Achtung: Is-A versus Has-A
Typischer Fehler: Is-A statt Has-A
© 2002, W. Pree, OOAD/UML 70
Verstehen derInteraktionen
zwischenObjekten
© 2002, W. Pree, OOAD/UML 71
Object Game
„Durchspielen“ einerHotelzimmerreservierung
© 2002, W. Pree, OOAD/UML 72
AbstrakteKlassen und
abstrakteKopplung
© 2002, W. Pree, OOAD/UML 73
Warum abstrakte Klassen?
Objektorientierte Sprachen werden in vielen Software-Projekten ähnlich wie modulorientierte Sprachen (Modula-2, Ada) zur Erstellung von Legobausteinsammlungenverwendet:
Klassen sind ein Sprachkonstrukt zurImplementierung von Modulen / abstraktenDatentypen.
durch Unterklassenbildung können derartigeSoftware-Bausteine an neue Projekte angepaßtwerden.
Um jedoch das volle Potential objektorientierter Sprachenauszuschöpfen, also die Wiederverwendbarkeit vonSoftwarearchitekturen zu ermöglichen, ist eine geschickteKombination von Unterklassenbildung (und somitPolymorphismus) sowie dynamischer Bindung in Form vonabstrakten Klassen essentiell.
© 2002, W. Pree, OOAD/UML 74
Abstrakte Klassen (I)
Eigenschaften ähnlicher Objekte werden ineine gemeinsame Klasse "herausgefiltert".Dieser Vorgang kann mit dem "Heraus-faktorisieren" von Termen in mathematischenAusdrücken verglichen werden.
Die entstandene Klasse wird nur wenigeMethoden konkret implementieren können.Wenn auch einige Methoden nicht konkretimplementiert werden können, kann man beidiesen Methoden zumindest Namen undParameter festlegen und beschreiben, was dieMethode "im Prinzip" tun soll.
es wird eine Standardisierung derKlassenschnittstelle für alle Unterklassenvorgenommen
© 2002, W. Pree, OOAD/UML 75
Abstrakte Klassen (II)
Die durch Herausfaktorisieren von gemeinsamenEigenschaften entstandenen Klassen spiegelnmeist nicht Objekte der realen Welt wider. Eshandelt sich vielmehr um Abstraktionen davon.Deshalb nennt man diese Klassen abstrakteKlassen.
Ein weiterer Grund für diese Namensgebung ist,daß es keinen Sinn ergibt, Instanzen aussolchen Klassen zu generieren. AbstrakteKlassen enthalten ja "dummy"-Implementierungen oder keineImplementierungen (→ abstrakte Methoden) füreinige Methoden.
© 2002, W. Pree, OOAD/UML 76
Abstrakte Kopplung (I)
Andere Klassen können basierend auf abstraktenKlassen implementiert werden. Die Kopplungzwischen einer Klasse (zB Klasse B) und einerabstrakten Klasse (zB Klasse A) kann aufmehrere Arten erfolgen:
B hat eine Instanzvariable vom statischen Typ Aeine oder mehrere Methoden von B haben einen
Parameter vom statischen Typ AB greift auf eine globale Variable vom statischen
Typ A zu
© 2002, W. Pree, OOAD/UML 77
Abstrakte Kopplung (II)
Diese mit einer abstrakten Klasse gekoppelten Klassenkönnen dank Polymorphismus und dynamischer Bindungohne Änderung mit Objekten beliebiger Unterklassender abstrakten Klassen, auf denen sie basieren, arbeiten.Das Verhalten dieser Komponenten wird also nicht durchdirekten Eingriff verändert, sondern durchsoftwaretechnisch saubere Modifikation der abstraktenKlassen in Unterklassen.
Abstrakte Klassen + abstrakteKopplung bilden somit die Basis fürOO Frameworks (= Halbfertigfabrikate).
© 2002, W. Pree, OOAD/UML 78
Abstrakte Kopplung (III)
Das Hauptproblem ist, guteAbstraktionen zu finden, sodaß andereSoftware-Komponenten darauf aufbauendrealisiert werden können.Abstrakte Klassen entwickeln sichtypischerweise erst im Zusammenspielmit den mit ihnen gekoppelten Klassenevolutionär weiter.
© 2002, W. Pree, OOAD/UML 79
BeispielHotelreservierung
© 2002, W. Pree, OOAD/UML 80
Frameworks—Statische Sicht
abstrakte Klassen(hier mit jeweils einerabstrakten Methode)
aaa
. . .
CreditCardEMoney
Framework-Klassen
Framework-Adaption
. . .. . .. . .
A1
A
Payment
Promotion
FreqShopping
. . .
. . .
© 2002, W. Pree, OOAD/UML 81
Black-Box versus White-BoxFramework-Teile
aa
vor der Adaptierung
EMoneyPayment
nach der Adaptierung
© 2002, W. Pree 82
Hands-On Übung
Webshop
© 2002, W. Pree, OOAD/UML 83
Case StudyWebshop (I)
Es soll ein Webshop konstruiert werden,mit Hilfe dessen man Bücher über dasInternet kaufen kann.
Ein Bestandteil soll der „Katalog“ sein,der die Bücher verwaltet.
© 2002, W. Pree, OOAD/UML 84
Case StudyWebshop (II)
Erster Entwurf:
© 2002, W. Pree, OOAD/UML 85
Case StudyWebshop (III)
Problem: Es sollen nun auch CDs undComputerspiele mitangeboten werden;Der Katalog muß also erweitert werden.
© 2002, W. Pree, OOAD/UML 86
Case StudyWebshop (IV)
Neuer Entwurf:
© 2002, W. Pree 87
Collaboration& SequenceDiagramme
© 2002, W. Pree, OOAD/UML 88
Collaboration-Diagramm (I)
In einem Collaboration-Diagramm gibt es nur einfache Beziehungenzwischen Objekten( ).
Optional kann auch der Message-Fluß zwischen Objektendargestellt werden. (Dazu sind aber meist Sequence-Diagrammebesser geeignet.)
message ist: [no:] method() method() wird wie bei Klassendiagrammen angegeben no ist eine optionale Nummer, die die Reihenfolge der
Methodenaufrufe definiert.
message, ...
© 2002, W. Pree, OOAD/UML 89
Collaboration-Diagramm(II)
Beispiel:
© 2002, W. Pree, OOAD/UML 90
Sequence-Diagramm (I)
Ein Sequence-Diagramm drückt imwesentlichen die gleiche Semantik aus wie einCollaboration-Diagramm, ist aber evtl. leichterzu lesen.
Collaboration-Diagramme bieten den Vorteil,daß zusätzliche Informationen darstellbar sind(zB Beziehungen zwischen Objekten).
Collaboration-Diagramme können automatischin Sequence-Diagramme überführt werden.
© 2002, W. Pree, OOAD/UML 91
Sequence-Diagramm (II)
Beispiel:
© 2002, W. Pree, OOAD/UML 92
Case Study:Webshop (I)
Katalog dynamisch: Wie werden Produkte in den Katalog
eingefügt? Wie sieht das Sequence – Diagramm aus? Wie sieht das Collaborations – Diagramm
aus?
© 2002, W. Pree, OOAD/UML 93
Case Study:Webshop (II)
© 2002, W. Pree, OOAD/UML 94
Case Study:Webshop (III)
© 2002, W. Pree, OOAD/UML 95
Use Cases
© 2002, W. Pree, OOAD/UML 96
Use Case:Erstes Artefakt
Use Cases helfen, die Anforderungen eines Systems besser zu
verstehen. die Anforderungen eines Systems zu
dokumentieren.
Use Cases verbinden die verschiedenenModelle eines Systems
© 2002, W. Pree, OOAD/UML 97
Papierübung
Lehrveranstaltungssystem Professoren tragen ihre Veranstaltungen ein Studenten wählen ihre Veranstaltungen System berechnet Gebühren
Was sind die Anforderungen? Wie könnte man die Anforderungen
dokumentieren? Wie könnte man die Anforderungen
visualisieren?
© 2002, W. Pree, OOAD/UML 98
Use-Case: Kommunikations-grundlage
Use Cases (Szenarien) stellen ein wichtigesKommunikationsvehikel dar, mit Hilfedessen sich die Endanwender/Benutzer einesSystems und die Entwickler verständigen.Bestandteile eines Use-Case-Modells:
Systemfunktionen (Use Cases) Umgebung (Actors) Beziehungen zwischen Use Cases und
Actors (Use Case Diagrams)
© 2002, W. Pree, OOAD/UML 99
Actors
Darstellung in UML:
Es sollte nicht für jede Rolle, die jemand hat, ein Actordefiniert werden.
Beispiele für Actors: Studenten, die sich für Lehrveranstaltungen
anmelden (externes) Abrechnungssystem Rezeptionist, der ein Hotelreservierungssystem
bedient
© 2002, W. Pree, OOAD/UML 100
Use Cases (I)
Ein Use Case modelliert einen Dialogzwischen einem Actor und dem System.Damit wird beschrieben, welche Funktionalitätdas System einem Actor bietet.
Darstellung in UML:
© 2002, W. Pree, OOAD/UML 101
Use Cases (II)
Hilfreiche Fragen, um Use Cases zu definieren:• Was sind die Aufgaben eines Actors?• Wird ein Actor Informationen im System erzeugen,
speichern, ändern, löschen oder lesen?• Welche Use Cases werden diese Informationen
erzeugen, speichern, ändern, löschen oder lesen?• Muß ein Actor über bestimmte Ereignisse im System
informiert werden?• Können alle funktionalen Anforderungen mit den Use
Cases erfüllt werden?
© 2002, W. Pree, OOAD/UML 102
Use Cases (III)
Beispiel für die Kurzbeschreibung eines Use Cases:Bezeichnung: Anmeldung zu einer Lehrveranstaltung(LVA)Dieser Use Case wird durch einen Studenten gestartet. Eswird die Möglichkeit geboten, einen Stundenplan für einbestimmtes Semester zu erstellen, löschen, ändernund/oder anzuschauen.
Ereignisfluß (Flow of Events) wird in Form eines Text-Dokuments (zB Word)
beschrieben Vorschlag für eine Schablone:
Pre-ConditionsMain Flow und eventuelle Sub-FlowsAlternative Flows
© 2002, W. Pree, OOAD/UML 103
Use Cases (IV)
Beispiel: Auswahl von LVAs (durch Professoren), dieangeboten werden
Pre-ConditionsDer Use Case “Anbieten von Kursen” muß ausgeführt sein,
bevor dieser Use Case beginnt. Main FlowDieser Use Case beginnt, wenn sich ein Professor im LVA-
Verwaltungssystem anmeldet und sein/ihr Passworteingibt. Das System verifiziert, ob das Passwort gültig ist(E-1) und fordert den Professor auf, das aktuelleSemester oder ein künftiges Semester auszuwählen (E-2). Danach wählt der Professor die gewünschte Tätigkeit:Hinzufügen, Löschen, Anzeigen, Drucken oder Beenden.
© 2002, W. Pree, OOAD/UML 104
Use Cases (V)
Wenn Hinzufügen gewählt wurde, wird der Sub-Flow S-1:Hinzufügen eines LVA-Angebots ausgeführt.... Sub-FlowsS-1: Hinzufügen eines LVA-AngebotsÜber entsprechende Eingabefelder können LVA-Bezeichnungund Nummer eingegeben werden (E-3). Das System verbindetden Professor mit der angebotenen LVA (E-4). Der Use Casebeginnt von neuem.... Alternative FlowsE-1: Ein falscher Name oder ein flasches Passwort wurdeneingegeben. Der Benutzer kann beides neu eingeben oder denUse Case beenden.
© 2002, W. Pree, OOAD/UML 105
Use Case Diagramm (I)
Diese zeigen bestimmte oder alle Actors, Use Casessowie Beziehungen zwischen diesen Entitäten.Typischerweise gibt es
ein Main Use Case Diagram, welches diewichtigsten Actors und die Hauptfunktionalitätgrafisch darstellt
beliebig viele weitere Use Case Diagrams, zBein Diagramm, welches alle Use Cases für einen
bestimmten Actor zeigtein Diagramm, welches einen Use Case und alle seine
Beziehungen zeigt
© 2002, W. Pree, OOAD/UML 106
Use Case Diagramm (II)
Beispiel:
© 2002, W. Pree, OOAD/UML 107
Use Case Diagramm (III)
Die “Uses”-Beziehung zeigt, daß Funktionalität inmehreren Use Cases benötigt wird.
Die “Extends”-Beziehung drückt optionalesVerhalten eines Use Cases aus.
Beide Beziehungen werden durch einen Abhängigkeits-Pfeil dargestellt und durch Stereotypen-Namenbezeichnet:In UML gibt es das sogenannte Stereotype-Konzept,mit Hilfe dessen die grundlegendenModellierungselemente erweitert werden können. DieNamen von Stereotypen sind zwischen << und >>.Stereotypen werden zB benutzt, um die Beziehungenzwischen Use Cases zu beschreiben.
© 2002, W. Pree, OOAD/UML 108
Use Case Diagramm (IV)
Beispiel:
© 2002, W. Pree, OOAD/UML 109
Hands-On Übung
Webshop Vgl. Amazon.com Kunde surft durch das Angebot, wählt Produkt,bezahlt mit Karte oder Bankeinzug...
Anbieter kann neue Produkte in den Katalogstellen...
© 2002, W. Pree, OOAD/UML 110
Hands-On Übung
© 2002, W. Pree, OOAD/UML 111
Hands-On Übung:Registrieren
MainflowDer Use Case beginnt, wenn der Benutzer denPunkt „registrieren“ wählt. Das System fordertihn auf, ein Formular auszufüllen, in dem erseinen Namen, Adresse, Alter, Nickname undPasswort angibt(E-1). Danach schickt dasSystem eine E-Mail an den Benutzer und zeigtihm an, dass er sich erfolgreich registriert hat.
© 2002, W. Pree, OOAD/UML 112
Case Study:Registrieren
Alternative FlowsE-1: Falls der Benutzer das Formularunvollständig ausgefüllt hat, wird eraufgefordert, die unausgefüllten Felderauszufüllen.E-1: Falls ein Nickname vom System schonvergeben wurde, wird er aufgefordert, einenanderen Nickname zu wählen...
© 2002, W. Pree, OOAD/UML 113
CRC-Karten
© 2002, W. Pree, OOAD/UML 114
CRC Karten(I)
Welche Klassen werden gebraucht,um ein Szenario zu modellieren?
Wie arbeiten diese Klassenzusammen?
© 2002, W. Pree, OOAD/UML 115
CRC Karten(II)
Class, Responsibility, Collaboration Beck und Cunningham, OOPSLA89
Entwickelten CRC – Karten, um denParadigmenwechsel (prozedural OO) anschaulich unterrichten zukönnen.
Unmittelbare Einführung in die Ideevon „Verantwortungen“ (Wirfs-Brock1990)
© 2002, W. Pree, OOAD/UML 116
CRC-Karten(III)
4x6 Index Karten Spezifizieren:
Klassennamen Verantwortungen Zusammenarbeit
© 2002, W. Pree, OOAD/UML 117
Beispiel:
© 2002, W. Pree, OOAD/UML 118
CRC Karten(IV)
Vorteile Kommunikation zwischen Designern Weg von Datenbehältern – hin zu
„Verantwortungen“ Kollaboration zwischen Klassen wird
leichter verstanden (kann nachgespieltwerden)
Grösse der Karten sorgt für richtigeGranularität der Klassen und forciert eineHigh-Level Spezifikation der Klassen
© 2002, W. Pree, OOAD/UML 119
Pakete und
Paketdiagramme
© 2002, W. Pree, OOAD/UML 120
Pakete
Pakete weden verwendet, um Klassen zugruppieren. Klassen, die logischzusammengehören, werden in Paketenstrukturiert.UML Notation:
© 2002, W. Pree, OOAD/UML 121
Pakete(II)
Pakete können geschachtelt sein, umkomplizierte Architekturen besserstrukturieren zu können.In UML können optional dieKlassennamen, die zu einem Paketgehören, aufgelistet werden.
© 2002, W. Pree, OOAD/UML 122
Paketdiagramme
Folgende Beziehungen zwischen Paketen könnendefiniert werden: Abhängigkeit
Wird verwendet, um auszudrücken, daß dieKlassen des einen Pakets Klassen desanderen Pakets verwenden Verallgemeinerung
Wird verwendet, wenn die Klassen des einen Pakets dieVerträge der Klassen des anderen Pakets erfüllen
© 2002, W. Pree, OOAD/UML 123
Beispiel:E-Commerce-Anwendung
© 2002, W. Pree, OOAD/UML 124
Zustands-übergangs-diagramme
© 2002, W. Pree, OOAD/UML 125
Notationselemente (I)
Zustandsübergangsdiagramme zeigen das dynamischeVerhalten einer Klasseninstanz oder eines ganzenSystems.
Symbol für einen Zustand:
Symbol für den Zustandsübergang:
aa
state name
actions
aa
event / action
© 2002, W. Pree, OOAD/UML 126
Notationselemente (II)
Eine Aktion kann wie folgt geschrieben werden: converter.ReadFile() method call DeviceFailure event triggering start Converting begin some activity stop Converting stop some activity
© 2002, W. Pree, OOAD/UML 127
Beispiel
Controller in einem Glashaus:
aa
Idle Daytime
Nighttime
defineclimate
temperature drop or rise /AdjustTemp()
sunset /LightOff()
sunrise /LightOn()
temperature drop or rise /AdjustTemp()
terminate climate
terminate climate
© 2002, W. Pree, OOAD/UML 128
Notationszusätze (I)
Innerhalb eines Zustandes können Aktionen definiertwerden,
wenn das System in diesen Zustand kommt, bzw. ihnverläßt:
sich in einem Zustand befindet: do Heating
Zustandsübergänge können an Bedingungen geknüpftwerden, die in eckigen Klammern angegeben werden.
aa
Heating
entry StartUp()exit ShutDown() too cool
[restart time >= 5 minutes]
© 2002, W. Pree, OOAD/UML 129
Notationszusätze (II)
Bedingungen können auch Zeitlimits enthalten:timeout(Heating, 30s) TRUE, wenn System
länger als 30 Sek.im Zustand Heating ist
Zustände können beliebig geschachtelt werden:
aa
Ready
Startup
Running
Cooling
compressorrunning
fanrunning
© 2002, W. Pree, OOAD/UML 130
Notationszusätze (III)
Zustände mit “Gedächnis”:Ein Zustand, der weitere Unterzustände enthält,kann ein "Gedächnis" bekommen, also sichmerken, in welchem Unterzustand er sich befand,wenn der Zustand verlassen wird.Dies wird durch das Adornment
ausgedrückt.
aa
H
© 2002, W. Pree, OOAD/UML 131
Beispiel
aa
H
Heating
entry StartUp()exit ShutDown()
Idle
too cool[restart time >= 5 minutes]
too hot
OK
Ready
Startup
Running
Cooling
compressorrunning
fanrunning
loggedlogready
createlog
createdposted
post
Failure
failure failurecleared
failure
© 2002, W. Pree, OOAD/UML 132
Beispiel: GUI
Abfolge von Dialogen alsZustandsübergangsdiagramm:
© 2002, W. Pree, OOAD/UML 133
Hands-On Übung
© 2002, W. Pree, OOAD/UML 134
Hands-On Übung
Welche Zustände kann ein Telefonhaben?
Gibt es Unterzustände? Weche Zustandsübergange gibt es? Gibt es Bedingungen für diese?
© 2002, W. Pree, OOAD/UML 135
Hands-On Übung
© 2002, W. Pree, OOAD/UML 136
Case Study:Webshop (I)
Shoppingcart Welche Zustände hat ein
Einkaufswagen? Um es spannender zu machen; es
sollen nie mehr als 10 Elemente imWagen sein.
© 2002, W. Pree, OOAD/UML 137
Case Study:Webshop (II)
© 2002, W. Pree, OOAD/UML 138
Component-Diagramme
© 2002, W. Pree, OOAD/UML 139
Notation
Klassen entsprechen Komponenten. Analog zuPackages können mehrere Klassen in eine Komponentezusammengfasst werden.In UML-Notation wird eine Komponente wie folgtdargestellt:
Komponenten entsprechen Modulen inmodulorientierten Sprachen.C++: Nachbau von Modulen durch .h, .C FilesSmalltalk: Klassengruppen, keine ModuleOberon und Java: Modularisierung direkt durch dieSprache unterstützt
© 2002, W. Pree, OOAD/UML 140
Deployment-Diagramm
© 2002, W. Pree, OOAD/UML 141
Notation
Diese Darstellung ist aus Booch’sProzeßdiagramm entstanden. Sie drückt aus,welche Hauptprogramme bzw. welche aktivenObjekte welchen Prozessoren zugeordnet sind,wenn ein System auf mehreren Prozessorenverteilt läuft.
aa
greenhouse 1
greenhouse 2
gardenerworkstation
© 2002, W. Pree, OOAD/UML 142
Beispiel: CORBA
© 2002, W. Pree, OOAD/UML 143
Hands-On Übung:Webshop
Ein Webshop ist typischerweise eineverteilte Anwendung. Normalerweise sinddrei Schichten beteiligt.
Wie könnte die Topologie des Systemsaussehen?
Welche Komponenten befinden sich aufwelchen computational-nodes?
© 2002, W. Pree, OOAD/UML 144
3-tier Applikationen
© 2002, W. Pree, OOAD/UML 145
Webshop:Topologie
© 2002, W. Pree, OOAD/UML 146
Anhang ALiteraturhinweise
© 2002, W. Pree, OOAD/UML 147
Literaturhinweise (I)Booch G., Jacobson I, Rumbaugh J. (1999)
Objektorientierte Analyse und Design. Mit praktischenAnwendungsbeispielenDas UML-Benutzerhandbuch (Unified Modeling Language User
Guide)Unified Modeling Language Reference Manual,The Objectory Software Development Process,Addison-Wesley
Österreich B. (2000) Erfolgreich mit Objektorientierung, Oldenburg VerlagBalzert H. (2000) Objektorientierung in 7 Tagen, m. CD-ROM. Vom UML-Modell zur
fertigen Web-Anwendung, Spektrum Akadem. VerlagBudd T. (1997) An Introduction to Object-Oriented Programming, Addison-WesleyFayad M., Schmidt D., Johnson R. (1999) Building Application Frameworks: Object-
Oriented Foundations of Framework Design, WileyFayad M., Schmidt D., Johnson R. (1999) Implementing Application Frameworks:
Object-Oriented Frameworks at Work, WileyFayad M., Schmidt D., Johnson R. (1999) Domain-Specific Application Frameworks:
Manufacturing, Networking, Distributed Systems, and SoftwareDevelopment, Wiley
Fowler M. (1997) Analysis Patterns, Addison-Wesley.Fowler M. (1999) UML Distilled (= UML konzentriert)
© 2002, W. Pree, OOAD/UML 148
Literaturhinweise (II)
Gamma E., Helm R., Johnson R. and Vlissides J. (1995). Design Patterns—Elementsof Reusable OO Software. Reading, MA: Addison-Wesley (auch als CDverfügbar)
Pree W. (1995). Design Patterns for Object-Oriented Software Development.Reading, Massachusetts: Addison-Wesley/ACM Press
Goldberg A., Rubin K. (1995) Suceeding with Objects—Decision Frameworks forProject Management, Addison-Wesley
Fontoura M., Pree W., Rumpe B. (2001) The UML-F Profile for FrameworkArchitectures, Addison Wesley
Larman C. (1998) Applying UML And PatternsRumbaugh J. (1992) Object-Oriented Modeling and Design, Prentice-Hall
http://www.rational.com (diverse aktuelle Informationen zu Rational Tools, UML)
http://www.together.com (diverse aktuelle Informationen zu Together Tools, UML)
© 2002, W. Pree, OOAD/UML 149
Anhang BUML Essentials
© 2002, W. Pree, OOAD/UML 150
Anhang:UML: Klasse, Vererbung
Klassen:
Vererbung:
© 2002, W. Pree, OOAD/UML 151
Anhang:UML: Klassenbeziehungen
Association:
Vielfachheiten:
© 2002, W. Pree, OOAD/UML 152
Anhang:UML: Klassenbeziehungen
Aggregation:
Navigierbarkeit:
Abhängigkeit:
© 2002, W. Pree, OOAD/UML 153
Anhang:UML: Objekte, Bemerkungen
Objekt:
Bemerkung:
© 2002, W. Pree, OOAD/UML 154
Anhang:UML: Use Case Diagramm
© 2002, W. Pree, OOAD/UML 155
Anhang:UML: Sequence Diagramm
© 2002, W. Pree, OOAD/UML 156
Anhang:UML: Collaboration Diagramm
© 2002, W. Pree, OOAD/UML 157
Anhang:UML: Zustandsdiagramm
© 2002, W. Pree, OOAD/UML 158
Anhang:UML: Paketdiagramm
© 2002, W. Pree, OOAD/UML 159
Anhang:UML: Deployment Diagramm
© 2002, W. Pree, OOAD/UML 160
Anhang CUML-
Beispieldiagramme
© 2002, W. Pree, OOAD/UML 161
Getränkeautomat
© 2002, W. Pree, OOAD/UML 162
Hotel-reservierungs-system
© 2002, W. Pree, OOAD/UML 163
Hotel – Collaboration
© 2002, W. Pree, OOAD/UML 164
Hotel – Sequence
© 2002, W. Pree, OOAD/UML 165
WebShop – Use Case
© 2002, W. Pree, OOAD/UML 166
WebShop – Katalog
© 2002, W. Pree, OOAD/UML 167
WebShop – ShoppingCart
© 2002, W. Pree, OOAD/UML 168
Login-Dialog
© 2002, W. Pree, OOAD/UML 169
CORBA – Deployment
© 2002, W. Pree, OOAD/UML 170
3-Tier – Deployment