Analyse-Klassendiagramm - Datenbank- und Informationssysteme ...

Softwareentwurf 

Kapitel III: Analyse 

III.3 Entwicklung des Analyse- 

Klassendiagramms 

Christian Soltenborn 

AG Datenbank- und Informationssysteme

Schon wieder Klassendiagramme? 

Hilfe! 

Sind das jetzt andere? 

Wir haben die Übersicht verloren! 

So, und jetzt kommen 

wir zu den Analyse- 

Klassendiagrammen 

Softwareentwurf 2010/2011 Universität Paderborn - Gregor Engels 2

ok, dann noch mal das 

große Bild... 


Problem 

Pflichtenheft 

Problem 

System 

Genereller Überblick über die Beziehungen 

der Dokumente etc.? 

Ziele 

Beschreibung des 

Problembereichs 

Modell des 


Geschäftsfeld 

Struktur Verhalten 

Produktfunktionen 

Softwareentwurf 2010/2011 Universität Paderborn - Gregor Engels 4 

1. 

1. 

2. 

2. 

3. 

3.

Problem 

Pflichtenheft 

Problem 

System 

Präzisierung der 

Strukturbeschreibung 



Ziele 



Präzisierung der 

Ablaufbeschreibung 

Aufgaben des zu 

entwickelnden Systems 

festlegen 

Modell des 






1. 

1. 

2. 

2. 

3. 

3.

Problem 

Pflichtenheft 

Problem 

System 

Analysedokument 



Ziele 



Kann ich größere 

Strukturen 

identifizieren? 

Architektur 

Modell des 






1. 

1. 

2. 

2. 

3. 

3. 

Analyse-Sequenzdiagramm

Problem 

Pflichtenheft 

Problem 

System 




Ziele 



Welche Klassentypen 

(Stereotype) benötige ich? 

[boundary, control, entity] 

Architektur 

Modell des 






1. 

1. 

2. 

2. 

3. 

3. 


Problem 

Pflichtenheft 

Problem 

System 




Ziele 



Grundlage für 

Gegenstandsklassen 

Szenarien -> Analyse-SD 

Use-Cases -> Kontrollklassen 

Aktoren -> Übergangsklassen 

Architektur 

Modell des 






1. 

1. 

2. 

2. 

3. 

3. 


Gut, wir haben jetzt eine 

Tonne Sequenzdiagramme. 

Ist das nicht ganz schön 

unübersichtlich? 

Deswegen sammeln wir 

die Informationen im 

Analyse- 

Klassendiagramm 


III. 1 Architektur festlegen 

-> Architektur 

III. 2 Anforderungen analysieren 

-> Analyse-Sequenzdiagramme 

III.3 Ergebnisse synthetisieren 

-> Analyse-Klassendiagramm 

Übersicht Analyse 


Synthese der Analyse-Ergebnisse 

Probleme bei der Vielzahl an Sequenzdiagrammen: 

Viele Objekte (und ihre Typen) wurden gefunden 

Objekte derselben Klasse kommen an ganz unterschiedlichen Punkten vor 

Aufrufe auf Objekten wurden gefunden, sind diese einheitlich benutzt? 

Manche Klassen wurden aus dem MdP abgeleitet, was ist mit den 

Strukturen (Assoziationen) des MdP? 

Synthese zum Analyse-Klassendiagramm soll diese Probleme lösen: 

Zusammenfassen von vielen Objektinformationen zu einer Klasse 

Zusammenfassen aller Operationen und Eigenschaften einer Klasse 

Festlegen der Beziehungen zwischen den Klassen 


Sequenzdiagramme -> Klassendiagramme 

Großer Sprung 

Wenig Raum für Erläuterungen/Begründungen 

Vorgehen bei der Synthese 

Sequenzdiagramme -> Analyse-Tabellen -> Klassendiagramme 

Tabellen sammeln Informationen zu Klassen aus Sequenzdiagrammen ein 

Tabellen bieten Raum, unterschiedliche Informationen aus verschiedenen 

Sequenzdiagrammen zu vergleichen und zu integrieren 

Tabellen haben Platz, um auch Erläuterungen aufzunehmen 

Wenn die Tabellen fertig sind, kann man aus ihnen ein Analyse- 

Klassendiagramm ableiten 


Struktur der Analyse-Tabellen 

Klasse Aufgaben Attribute Kennt 

(dauerhaft?) 

Welche Klassen 

haben wir und 

welche 

Stereotypen 

haben diese? 

Welche 

Aufgaben 

erledigen diese 

Klassen? 

Welche Daten 

kennen diese 

Klassen? 

Welche anderen 

Klassen kennt 

diese Klasse? 

Ist diese 

Kenntnis 

dauerhaft? 


Analyse-Tabellen 

Klasse 

Jedes Objekt in den Analyse-Sequenzdiagrammen hat einen Typ (Klasse). 

Alle diese Klassen werden in der Analyse-Tabelle gesammelt 


(dauerhaft?) 


Verfeinerung ins System hinein 

starteKV() 

:GUI 

starteKV() 

:SysStrg 

gib nächsten() 

kv1 

:KV 

new KVStrg() 

Vom Sequenzdiagramm 

zur Analyse-Tabelle 

kv1:KV 

kommissioniere (kv1) 

Klassen einsammeln 

:KVStrg 



Klasse 


(dauerhaft?) 

GUI 

SysStrg 

KV Verwaltung 

KV 

KVStrg 

Achten auf ähnliche Namen (KVstr, KVStrg), ist dasselbe gemeint? 

Achten auf gleiche Namen (KV, KV), sind verschiedene Dinge gemeint? 

Multiobjekt umgesetzt als KV Verwaltung 



Aufgaben 

Objekte erhalten Nachrichten, bestimmte Aufgaben zu erledigen. 

Für jeden (verschiedenen) Aufruf wird in der Spalte Aufgaben ein 

Eintrag bei der entsprechenden Klasse angelegt 


(dauerhaft?) 

GUI 

SysStrg 

KV Verwaltung 

KV 

KVStrg 



starteKV() 

:GUI 

starteKV() 

:SysStrg 


kv1 

:KV 

new KVStrg() 



kv1:KV 


:KVStrg 


Aufgaben werden mit einem Kommentar beschrieben. 


Aufgaben 


(dauerhaft?) 

SysStrg starteKV() 

löst die Bearbeitung 

eines Kommissioniervorganges 

aus 


Analyse von „Los kommissionieren“ 

:LosStrg l1:Los 

gib Lagerfach() 

fa 

gib anzahl() 

12 


fa 

:Ware 

steuere an Fach Anzahl(fa,12) 

fa:Lagerfach 



fe:Lagerfeld 

gib Lagerfeld() 

fe 

gib ID() 


1 

gib ID() 

16 

:DHCStrg 

steuereAn 

FeldFachAnz 

(16,1,12)

Parameter werden mit ihren Datentypen angegeben 


Aufgaben 


(dauerhaft?) 

DHCStrg steuere an Fach Anzahl 

(Lagerfach, Integer) 

steuert das DHC so, dass 

das übergebene Lagerfach 

zugänglich ist und die 

übergebene Anzahl auf dem 

Display angezeigt wird 


Analyse von „KV kommissionieren“ 

:GUI :KVStrg kv1:KV 

zeige Anzahl 

Aufträge(3) 

gib Anzahl 

Aufträge() 

3 

new Schedule (kv1) 

gib nächstes Los () 

l1 

new LosStrg() 

kommissioniere (l1) 


… 

s:Schedule 



l1:Los 

:LosStrg 


Rückgabewerte werden mit ihren Datentypen nach einem 

Doppelpunkt angegeben 


Aufgaben 


(dauerhaft?) 

KV gib Anzahl Aufträge():Integer 

gibt die Anzahl der Aufträge 

im Kommissioniervorgang 

zurück 



Aufgaben 

Gibt es mehrere identische Aufgaben einer Klasse mit unterschiedlichen 

Namen? -> Integrieren 


(dauerhaft?) 




zurück 

gib Aufträge():Integer 



zurück 



Attribute 

Manche Aufgaben erledigen Objekte ohne Rückfrage bei anderen. Für 

diese Aufgaben können sie datenwertige Attribute benötigen, die 

auch über den Aufruf einer Methode hinaus zur Verfügung stehen. 


(dauerhaft?) 

KV 




zeige Anzahl 

Aufträge(3) 

gib Anzahl 

Aufträge() 

3 



l1 

new LosStrg() 



… 



s:Schedule 

l1:Los 

:LosStrg 


Attribute mit Name:Datentyp und Beschreibung eintragen 


Attribute 


(dauerhaft?) 

KV Anzahl Aufträge:Integer 

Die Anzahl der im 

Kommissioniervorgang 

enthaltenen Aufträge 

Attribute treten bei fast allen Entity-Klassen auf 

Control-Klassen haben wenig oder gar keine Attribute 

Boundary-Klassen haben häufig Zustands-Attribute 



Lokale Bekanntheit 

Objekte haben Kenntnisse über ihre Umgebung. Diese werden in die 

Spalte Lokale Bekanntheit (oder kurz: Kennt) eingetragen 


(dauerhaft?) 

SysStrg 


Wann kennt ein Objekt ein anderes? 

Wenn es aktiv mit diesem kommuniziert 

Wenn es dieses Objekt erzeugt 

Wenn es Referenzen auf dieses Objekt weitergibt 




starteKV() 

:GUI 

SysStrg kennt die 

KVStrg, weil es 

diese erzeugt 

starteKV() 

SysStrg kennt das Objekt 

kv1:KV (und damit die 

Klasse KV), weil es 

Referenzen auf dieses 

Objekt weitergibt 

:SysStrg 


kv1 

:KV 



kv1:KV 

SysStrg kennt die KV Verwaltung, 

weil es mit dieser kommuniziert 

KV Verwaltung kennt SysStrg nicht! 

(nur Antwort, keine aktive Kommunikation) 


:KVStrg 






Wie kann Bekanntheit entstehen? 

Selbsterzeugen von Objekten 

Übergabe als Parameter 

Übergabe als Antwort 





starteKV() 

:GUI 

SysStrg kennt die 

KVStrg, weil es 

diese erzeugt 

starteKV() 

KVStrg kennt das 

Objekt kv1:KV, weil es 

dieses als Parameter 

bekommt 

:SysStrg 


kv1 

:KV 



kv1:KV 

SysStrg kennt kv1:KV, weil es dieses 

als Antwort bekommt 


:KVStrg 






Wie kann Bekanntheit entstehen? 

Selbsterzeugen von Objekten 

Übergabe als Parameter 

Übergabe als Antwort 

Was ist dauerhafte Bekanntheit 



Ein Objekt kennt ein anderes über die Ausführung einer Methode 

hinaus 

-> lokale Speicherung der Objektidentität 



starteKV() 

:GUI 

starteKV() 

Ob SysStrg KV dauerhaft 

kennt, können wir hier 

nicht beurteilen, da wir 

nur eine Methode von 

SysStrg sehen 

Dies gilt auch für KVStrg: 

hier wird das Objekt zwar 

gelöscht, es könnte aber 

andere Methoden geben, die 

dauerhafte Speicherung 

implizieren! 

:SysStrg 


kv1 

:KV 



kv1:KV 

SysStrg kennt KV Verwaltung dauerhaft, weil es 

dieses Objekt nicht im Laufe der Methode 

starteKV() kennengelernt hat 


:KVStrg 




Einträge in der Spalte „Kennt“ mit Klassennamen und der Angabe der 

Dauerhaftigkeit (soweit schon bestimmbar) 

Klasse Aufgaben Attribute Kennt (dauerhaft?) 

SysStrg KV Verwaltung (ja) 

KV (?) 

KVStrg (?) 



Bestimmung der lokalen Bekanntheit 

An einem Analyse Sequenzdiagramm kann man 

erkennen 

Welche Klassen eine Klasse kennt (Achtung: Abstraktion von 

Objekten!) 

Ob eine Bekanntschaft dauerhaft ist (wenn die Bekanntschaft nicht 

innerhalb derselben Methode hergestellt wurde) 

An allen Analyse-Sequenzdiagrammen kann man 

erkennen 

Ob Bekanntschaften nicht dauerhaft sind (Bekanntschaft wird 

immer innerhalb derselben Methode hergestellt) 

⇒ Normalerweise werden wir nur "ja" und "?" bei dauerhaft benutzen können! 


Grundsätzlicher Pattern für dauerhafte Bekanntheit 

:A :B 

:X 

:Y 

:Z 

set C(c) 

foo 

bar 

baz 



Dauerhafte Bekanntheit: Einmal bekannt machen, dann immer auf die 

Bekanntheit zurückgreifen 


foo2 

bar2 

baz2 

c:C



Grundsätzlicher Pattern für nicht dauerhafte Bekanntheit 

:A :B 

:X 

:Y 

foo(c) 

bar(c) 

baz(c) 

… 


… 

Nicht dauerhafte Bekanntheit: Das entsprechende Objekt muss jedesmal 

übergeben/erfragt werden 

foo2 

bar2 

baz2 

c:C



Was ist, wenn keins der beiden Pattern erfüllt ist? 

Objekte werden mehrfach miteinander bekannt gemacht, obwohl 

sie bereits als dauerhaft bekannt gelten 

Inkonsistente Modellierung 

Einheitliche Entscheidung: Dauerhafte Bekanntschaft oder nicht 

Analyse-Sequenzdiagramme ändern, um Konsistenz herzustellen 

Objekte werden nie miteinander bekannt gemacht 

Unvollständige Modellierung 

Wenn wichtige Methoden fehlen -> Analyse-Sequenzdiagramme 

ergänzen 

Manche „Setup“-Methoden (Systemstart etc.) werden nicht modelliert 


Zusammenfassung Analyse-Tabellen 

Eingabe: Menge von Analyse-Sequenzdiagrammen 

Ausgabe: Tabelle, die 

Alle vorkommenden Klassen auflistet, inklusive 

Stereotyp der Klasse 

Aufgaben der Klasse mit Parametern und Rückgabewerten 

Attribute der Klassen mit Datentypen 

Bekannte andere Klassen mit Angabe der Dauerhaftigkeit 

Die Tabelle soll 

Informationen sammeln 

Konsistenz zwischen den Analyse-Sequenzdiagrammen sichern/herstellen 


Analyse-Klassendiagramm 

Eigentlich kennen wir bereits eine Notation, mit der 

man die Informationen aus der Tabelle darstellen kann: 

Klassendiagramme 

Uns fehlen nur noch einige Ausdrucksmöglichkeiten 


Operationen 


datum:Datum 

gib Anzahl Aufträge():Integer 

Navigationsrichtung 

Komissioniervorgang 

* 

Ausdrucksmittel in Analyse- 

Klassendiagrammen 

Zusätzliches Kompartment für 

Notation der Operationen einer 

Klasse 

speichert 

0..1 

KV Verwaltung 

Gibt an, dass eine Navigation von KV Verwaltung zu KV 

möglich ist. 

Achtung: Unabhängig von der Leserichtung! 

Unidirektionale und bidirektionale Navigation ist möglich 

Default (keine Pfeilspitzen) = beide Pfeilspitzen = bidir. Nav. 


Umsetzen von Analyse-Tabellen ins 


Jede Klasse der Analyse-Tabelle wird eine Klasse im 


Klasse 

GUI 

SysStrg 

KV Verwaltung 

KV 

KVStrg 

GUI 

KV Verwaltung 

SysStrg 


KVStrg 




Gefundene Attribute und Operationen werden eingetragen 

Klasse Aufgaben Attribute 


gibt die Anzahl der Aufträge im 

Kommissioniervorgang zurück 


KV 

Anzahl Aufträge:Integer 

gib Anzahl Aufträge():Integer 

Anzahl Aufträge:Integer 

Die Anzahl der im 

Kommissioniervorgang enthaltenen 

Aufträge



Dauerhaftes Bekanntsein wird zu (gerichteten) Assoziationen 

Klasse Aufgaben Attribute Kennt (dauerhaft?) 

SysStrg KV Verwaltung (ja) 

SysStrg KV Verwaltung 



Abschließen der Erstellung des Analyse-Klassenendigrammes: 

Assoziationen vervollständigen (Namen und Kardinalitäten) 

Bei Assoziationen zwischen Entity-Klassen: Gibt es bereits eine 

Assoziation im Modell des Problembereichs? 

Lagerfach Lagerfeld 

4..12 

enthält 

Bei Assoziationen mit mindestens einer neu gefundenen Klasse: 

Was ist ein sinnvoller Name? Wie sind die Kardinalitäten? 

SysStrg KV Verwaltung 

0..1 

1 


1

Problem 

Pflichtenheft 

Problem 

System 




Ziele 



Zusammenfassen der 

Informationen 

(über die Analyse- 

Tabellen) 

Architektur 

Modell des 








1. 

1. 

2. 

2. 

3. 

3. 


Yo, jetzt seh‘ ich 

wieder klarer, thnx! 

Aber haben wir jetzt 

nicht nur ein 


durch ein anderes 

ersetzt? 


Problem 

Pflichtenheft 

Problem 

System 


Ziele 



Architektur 

MdP vs. 


Modell des 




vs. 





1. 

1. 

2. 

2. 

3. 

3. 


Modell des Problembereichs 

Beschreibt das Problemgebiet 

Enthält Begriffe des Problembereichs 

Alle Klassen sind gleich 

Assoziationen sind ungerichtet 

MdP vs. 



Beschreibt unseren Lösungsansatz 

Übernimmt manche dieser Begriffe 

als Gegenstandsklassen 

Verwirft manche dieser Begriffe als 

irrelevant 

Integriert oder spaltet manche dieser 

Begriffe (z.B. KV Steuerung) 

Enthält komplett neue, lösungsorientierte 

Klassen (z.B. 

Übergangsklassen) 

Ordnet die Klassen verschiedenen 

Ebenen der Architektur zu 

Assoziationen sind gerichtet 


Relevanter Ausschnitt des MdP: 

Karussell 

1 

26 

{ordered} 

-Zulässiges Gewicht : Decimal 

1 

4..12 

{ordered} 

Lagerfeld 

Lagerfach 

-Zulässiges Gewicht : Decimal 

-Höhe : Decimal 

MdP vs. Analyse-Klassendiagramm 

Beispiel V-DHC 

Auftrag 

-Auftragsnummer : String 

-Bestelldatum : Date 

-Priorität : Decimal 

0..1 

Auslagerungsauftrag 

Charge 

-Nummer : Decimal 

-Verfallsdatum : Date 

3 liegt in 

3 1..* wird erledigt durch 

1 


Warengruppe 

-Bezeichnung : String 

-Gewicht pro Ware : Decimal 

-maxAnzahl pro Fach : Decimal 

-Standardlagerfach : String 


1 

0..* 

1..* 

von4 

1 

3 zusammengestellt in 

1 

0..* 

Ware 

1..* 

Los 

0..* 0..1 

enthält Waren von4 

1 

1..*



Relevanter Ausschnitt des Analyse-KD (nach den oben gezeigten Sequenzdiagrammen) 

-ID : int 

+gibID() : int 

-ID : int 

GUI 

1 

4..12 

{ordered} 

Lagerfeld 

Lagerfach 

+getLagerfeld() : Lagerfeld 

+getID() : int 

0..1 

KV Verwaltung 

+starteKV() 

+zeigeAnzahlAufträge(Integer)() +gibNaechsten() : Kommissioniervorgang 

zeigt an4 

1 

1 

1 

1 

zeigt an 

1 

1 

KVStrg 

+starteKV() 

SysStrg 

+kommissioniere(in kv : Kommissioniervorgang) 

+kommissioniere() : Los 

LosStrg 

DHCStrg 

+steuereAnFachAnzahl(in lf : Lagerfach, in anz : int) 

3 liegt in 

0..1 * 


-AnzahlAutraege : int 

+gibAnzahlAuftraege() : int 

-Anzahl : int 

+gibLagerfach() : Lagerfach 

3 zusammengestellt 

+gibAnzahl() 

in 

: int 

1..* 



0..* 

Ware 

1 

Schedule 

+gibNaechstesLos() : Los 

1..* 

Los 

0..1



Relevanter Ausschnitt des Analyse-KD (nach den oben gezeigten Sequenzdiagrammen) 

-ID : int 


-ID : int 

GUI 

1 

4..12 

{ordered} 

Lagerfeld 

Lagerfach 



0..1 

KV Verwaltung 

+starteKV() 

+zeigeAnzahlAufträge(Integer)() +gibNaechsten() : Kommissioniervorgang 

zeigt an4 

1 

1 

1 

1 

zeigt an 

1 

1 

KVStrg 

+starteKV() 

SysStrg 



LosStrg 

DHCStrg 


3 liegt in 

0..1 * 




-Anzahl : int 


3 zusammengestellt 

+gibAnzahl() 

in 

: int 

1..* 



0..* 

Ware 

1 

Schedule 


1..* 

Los 

0..1

Stimmt, da haben wir eine Menge 

dazugelernt 

Und in den Sequenzdiagrammen 

stecken 

auch noch Details über 

die internen Abläufe 


Aber dürfen Kontrollklassen auf 

Boundaryklassen zeigen? 


Wir erinnern uns: 

Drei Schichten Architektur 

Jede Schicht ist zur darüberliegenden ein Server 

Abschluss der Analyse 

Verfeinerung der Architektur 

Jede Schicht ist Client der darunterliegenden Schicht 

Wir hatten (erstmal) eine Drei-Schichten-Architektur vereinbart 

Nach der Analyse wissen wir jetzt viel mehr Details über 

unser System 

Haben wir uns an die Architektur gehalten? 

Wissen wir jetzt mehr Details über die Architektur? 


Nochmal das Analyse-Klassendiagramm 

+starteKV() 

+zeigeAnzahlAufträge(Integer)() 

zeigt an4 

1 

+starteKV() 

-ID : int 


1 

1 

SysStrg 

GUI 

Lagerfeld 

1 

4..12 

{ordered} 

1 

zeigt an 

1 


Lagerfach 

-ID : int 



1 

KV Verwaltung 

+gibNaechsten() : Kommissioniervorgang 

0..* 

3 liegt in 

0..1 

Überprüfung der Architektur 

+steuereAnFachAnzahl (in lf : Lagerfach, in anz : int) 

KVStrg 

Ware 

DHCStrg 



0..1 * 

1..* 


Los 

0..1 

-Anzahl : int 


+gibAnzahl() : int 

LosStrg 





1..* 

1 

Schedule 

+gibNaechstesLos() : Los


+starteKV() 


zeigt an4 

1 

Logikschicht 

+starteKV() 

Datenhaltungsschicht 

-ID : int 


1 

1 

SysStrg 

GUI 

Lagerfeld 

1 

-ID : int 

4..12 

{ordered} 

1 

zeigt an 

1 


Lagerfach 



1 

KV Verwaltung 


0..1 



KVStrg 

0..* 

3 liegt in 

Ware 

DHCStrg 


0..1 * 

1..* 

-Anzahl : int 


Präsentationsschicht 


Los 

0..1 



LosStrg 





1..* 


1 

Schedule


+starteKV() 


zeigt an4 

1 

Logikschicht 

+starteKV() 


-ID : int 


1 

1 

SysStrg 

GUI 

Lagerfeld 

1 

-ID : int 

4..12 

{ordered} 

1 

zeigt an 

1 


Lagerfach 



1 

KV Verwaltung 


0..1 



KVStrg 

0..* 

3 liegt in 

Ware 

DHCStrg 


0..1 * 

1..* 

-Anzahl : int 


Präsentationsschicht 


Los 

0..1 



LosStrg 





1..* 


1 

Schedule



zeige Anzahl 

Aufträge(3) 

gib Anzahl 

Aufträge() 

3 



l1 

new LosStrg() 



… 

s:Schedule 



l1:Los 

:LosStrg 


Analyse von „Los kommissionieren“ 

:LosStrg l1:Los 


fa 

gib anzahl() 

12 


fa 

:Ware 

steuere an Fach Anzahl(fa,12) 

fa:Lagerfach 



fe:Lagerfeld 

gib Lagerfeld() 

fe 

gib ID() 


1 

gib ID() 

16 

:DHCStrg 

steuereAn 

FeldFachAnz 

(16,1,12)

Aufwärtskommunikation 

in der 3-Schichten-Architektur 

Wie gelangen Informationen über den aktuellen Systemzustand zum 

Display? 

Antworten 

Berechne 

Berechne 

2+2 

4 

:GUI 

Berechne 

Wert(„2+2“) 

:Strg 

Problem: Die Art der Ausgabe kann sich abhängig von der 

Verarbeitung des Inputs ändern 


4




Display? 

Antworten mit Informationen über Anzeige 

Berechne 

2/(3-x) 

Es ist ein Fehler 

aufgetreten: 

Division by Zero 

:GUI 

Berechne 

Wert(„2/(3-x)“) 

„Fehlerscreen“, 

„Division by Zero“ 

:Strg 

Problem: Dieses Ein-Ausgabemuster entspricht nicht zeitgemäßen, 

interaktiven Systemen 





Display? 

Polling 

:GUI 

Berechne 

Wert(„2/(3-x)“) 

getUpdate 

getUpdate 

getUpdate 

„Ergebnis“,“2“ 

:Strg 

Problem: Dieses Muster ist unschön anzusehen und nicht 

gewinnbringend in der Analyse 


Lösung 



Ein Boundary Objekt der Analyse verkapselt (immer) ein relativ komplexes 

System (GUI Klassen, Dialogkontrolle, externe Protokolle…) 

Erweiterung des Boundary Begriffes um eine Fassadenklasse in der 

Logikschicht 

Freie Kommunikation in der Präsentationsschicht 

Logikschicht möglich 

Unabhängigkeit vom 

Informationstransport 

zur echten Schnittstelle Logikschicht 


«boundary» «boundary» 

«control» 

«control» 

«entity» «entity» 


Lösungspattern(intern): 

:GUI 

Berechne 

Wert(„2/(3-x)“) 

getUpdate 

getUpdate 

getUpdate 

„Ergebnis“,“2“ 

:GUIFassade 

Berechne 

Wert(„2/(3-x)“) 

zeigeErgebnis(„2“) 



Erkenntnis für uns: Wir können mit der GUI kommunizieren, ohne 

die Architektur zu verletzen. Interne Realisierung dann über das o.g. Pattern 

:Strg 

im Analyse-SD: 

:GUI :Strg 

Berechne 

Wert(„2/(3-x)“) 

zeigeErgebnis(„2“) 


Wichtige Erkenntnis: 

Ergebnis der Analyse 

Die „Objekte“ (und damit auch Klassen) in der Analyse 

erfordern (teilweise) noch eine Realisierung durch 

komplexe Strukturen. 

Analyse Klassen ≠ Implementationsklassen 

Analyse Klassen ≈ Interfaces 


In der Analyse 

Zusammenfassung Analyse 

Legen wir die grundsätzliche Architektur des Systems fest 

Verfeinern wir die Produktfunktionen durch Analyse- 

Sequenzdiagramme 

Fassen wir die dabei gewonnenen strukturellen Informationen erst 

zu Tabellen, dann zu einem Analyse-Klassendiagramm zusammen 


Analyse-Sequenzdiagramme 

Wozu sie gut sind 

Wie man sie zeichnet 

Welche Elemente ihnen zugrunde liegen 

Was Sie gelernt haben sollten 

Welche Prinzipien Sie bei der Erstellung berücksichtigen sollten 


Welche Informationen hier einzutragen sind 

Welche Probleme dabei auftreten können 

Analyse-Klassendiagramme 

Welche neuen Notationselemente diese enthalten 

Wie man sie aus den Tabellen ableitet 

Was man sonst noch einfügen muss 

Wie sie sich vom Modell des Problembereichs unterscheiden

Analyse-Klassendiagramm - Datenbank- und Informationssysteme ...

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?