Software-Entwicklung 2 - UML in der Analyse
Software-Entwicklung 2 - UML in der Analyse
Software-Entwicklung 2 - UML in der Analyse
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
<strong>Software</strong> <strong>Entwicklung</strong> 2<br />
<strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong>
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
Inhalt<br />
• Objektorientierte vs. klassische <strong>Software</strong>entwicklung<br />
• Imperative Programmierung<br />
• Objektorientierte Programmierung<br />
• Grundpr<strong>in</strong>zipien <strong>der</strong> objektorientierten Denkweise<br />
• Elemente <strong>in</strong> <strong>der</strong> objektorientierten Programmierung<br />
• Beson<strong>der</strong>heiten objektorientierter <strong>Software</strong>entwicklung<br />
• Objekte<br />
• Klassen<br />
• Operationen<br />
• Assoziationen<br />
• Kard<strong>in</strong>alität<br />
• Assoziationsnamen und Rollen<br />
• Son<strong>der</strong>fälle von Assoziationen<br />
• Assoziative Klassen<br />
• Aggregationen und Kompositionen<br />
• Vererbung<br />
• Pakete<br />
• Botschaften<br />
• Szenarios<br />
2
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
Lernziele<br />
• Grundlegende Eigenschaften <strong>der</strong> nicht-objektorientierten, imperativen<br />
<strong>Software</strong>entwicklung kennen<br />
• Grundlegende Eigenschaften <strong>der</strong> objektorientierten <strong>Software</strong>entwicklung kennen<br />
• Wesentliche Unterschiede zwischen diesen beiden Alternativen kennen<br />
• Die Begriffe im Zusammenhang mit <strong>der</strong> Objektorientierung erläutern können<br />
(Objekt, Klasse, Attribut, Operation, Objektdiagramm, Vererbung, Pakete,<br />
Botschaften, Szenarios, usw.)<br />
• Assoziationen erläutern und anwenden können (Kard<strong>in</strong>alitäten,<br />
Assoziationsnamen und Rollen, Son<strong>der</strong>fälle von Assoziationen, Assoziative<br />
Klassen, Aggregationen und Kompositionen)<br />
• Die <strong>UML</strong>-Darstellungen für diese Elemente anwenden können<br />
• Die <strong>UML</strong> zur Beschreibung <strong>in</strong> <strong>der</strong> <strong>Analyse</strong>phase verwenden können<br />
3
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
Imperative Programmierung<br />
• Trennung von Daten und Verarbeitung<br />
• Getrennte Hierarchien für Daten und Prozeduren<br />
• Än<strong>der</strong>ung <strong>der</strong> globalen Datenstruktur bewirkt weitreichende Än<strong>der</strong>ungen <strong>der</strong><br />
prozeduralen Struktur<br />
• Ungünstiges, weil kompliziertes Paradigma für die Problemanalyse (B<strong>in</strong>dung,<br />
Kopplung)<br />
4
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
Objektorientierte Programmierung<br />
• Ke<strong>in</strong>e Trennung von Daten und Prozeduren<br />
• Klare Richtl<strong>in</strong>ie für die Identifikation von Objekten und Klassen<br />
• Natürlicher Mechanismus zur Identifikation von Objekten<br />
• Zusammenfassung von Daten und den dazugehörigen Prozeduren zu Klassen<br />
bzw. Objekten<br />
• Gewünschtes Systemverhalten kommt zustande durch Zusammenwirken<br />
verschiedener Objekte und Klassen über Botschaften o<strong>der</strong> Nachrichten<br />
• Natürlicher Mechanismus zur Abbildung <strong>der</strong> Gruppenzugehörigkeit aus <strong>der</strong> realen<br />
Welt durch Bildung von Klassen<br />
• Unterschiedliche Reaktionsmöglichkeiten auf Nachrichten durch Objekte<br />
5
Grundpr<strong>in</strong>zipien <strong>der</strong> objektorientierten<br />
Denkweise<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
• Objekte vere<strong>in</strong>igen Daten und Prozeduren<br />
• Objekte tauschen Nachrichten aus und reagieren auf diese<br />
• Objekte erben ihre Eigenschaften und Fähigkeiten durch die Zugehörigkeit zu<br />
Objektklassen<br />
• Objekte verschiedener Klassen reagieren auf gleiche Nachrichten unterschiedlich<br />
6
Elemente <strong>in</strong> <strong>der</strong> objektorientierten<br />
Programmierung<br />
• Objekt<br />
• E<strong>in</strong>deutig benannte Abstraktion e<strong>in</strong>es <strong>in</strong> sich geschlossenen Elements <strong>der</strong> realen Welt<br />
• Stellt die relevanten Aspekte e<strong>in</strong>er Entität dar<br />
• Enthält Daten - sogenannte Attribute und hat ggf. Teile (Aggregation)<br />
• Bef<strong>in</strong>det sich <strong>in</strong> e<strong>in</strong>em Zustand<br />
• Enthält Prozeduren - sogenannte Methoden, die die Fähigkeiten des Objekts realisieren und Daten<br />
modifizieren<br />
• Attribute können (im Idealfall) nur über die objekteigenen Methoden abgefragt und modifiziert werden<br />
(Information Hid<strong>in</strong>g, Datenkapsel)<br />
• Methoden werden durch Nachrichten (Botschaften) aktiviert<br />
7<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer
Elemente <strong>in</strong> <strong>der</strong> objektorientierten<br />
Programmierung<br />
• Klasse<br />
• Klassen beschreiben Objekte <strong>der</strong>selben Art.<br />
• Klassen s<strong>in</strong>d die ”Baupläne“ <strong>der</strong> Objekte (Abstrakter Datentyp)<br />
• E<strong>in</strong> Objekt ist e<strong>in</strong>e Instanz e<strong>in</strong>er Klasse (vgl. Vere<strong>in</strong>barung e<strong>in</strong>er Variablen e<strong>in</strong>es bestimmten<br />
Datentyps <strong>in</strong> imperativen Programmiersprachen)<br />
• Eigenschaften, die für alle Objekte e<strong>in</strong>er Klasse identisch s<strong>in</strong>d, können <strong>der</strong> Klasse zugeordnet werden<br />
(Klassenvariablen). Alle Objekte e<strong>in</strong>er Klasse haben auf diese Variablen Zugriff<br />
• Klassen s<strong>in</strong>d ebenfalls Objekte. Daher können Klassen auch selbst Methoden besitzen<br />
(Klassenmethoden), z.B. zur Initialisierung <strong>der</strong> Klassenattribute<br />
8<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer
Elemente <strong>in</strong> <strong>der</strong> objektorientierten<br />
Programmierung<br />
• Attribut<br />
• Attribute beschreiben die Eigenschaften von Objekten bzw. Klassen (lokale Daten <strong>der</strong> Objekte)<br />
• Methode<br />
• Methoden realisieren die Funktionalität <strong>der</strong> Objekte, bzw. <strong>der</strong> Klassen<br />
• Fähigkeiten (Methoden) die zu allen Objekten e<strong>in</strong>er Klasse h<strong>in</strong>zugefügt werden müssen, werden<br />
lediglich <strong>der</strong> Klasse h<strong>in</strong>zugefügt<br />
• Botschaft<br />
• Botschaften (Nachricht, Message) dienen zur Aktivierung von Methoden <strong>in</strong> Objekten<br />
• Botschaften können verschiedene passende Methoden aktivieren (Polymorphismus)<br />
9<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer
Beson<strong>der</strong>heiten objektorientierter<br />
<strong>Software</strong>entwicklung<br />
• Vererbung<br />
• Neue Klassen können aus vorhandenen Klassen abgeleitet werden<br />
• Der Bezug zwischen Oberklasse und Unterklasse ist streng hierarchisch<br />
• Die Suche nach ausführbaren Methoden erfolgt <strong>in</strong> <strong>der</strong> Klassenhierarchie streng hierarchisch von<br />
unten nach oben<br />
(Empfänger, Oberklasse, <strong>der</strong>en Oberklasse, ...)<br />
• Klassen auf e<strong>in</strong>er Ebene werden nicht durchsucht<br />
• Methoden <strong>in</strong> abgeleiteten Klassen überschreiben gleichnamige Methoden <strong>in</strong> Oberklassen<br />
(Polymorphismus)<br />
• Mehrfachvererbung<br />
• Abgeleitete Klassen können mehr als e<strong>in</strong>e Oberklasse besitzen<br />
• Die Vererbungsbeziehungen bilden ke<strong>in</strong>e baumartige Struktur mehr<br />
10<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer
Beson<strong>der</strong>heiten objektorientierter<br />
<strong>Software</strong>entwicklung<br />
• B<strong>in</strong>den<br />
• Zuordnung zwischen Aufrufmechanismus (Methodenname) und Implementierung<br />
• Statisches B<strong>in</strong>den (typ. imperative Programmierung)<br />
• Zuordnung geschieht bereits zum Zeitpunkt <strong>der</strong> Übersetzung<br />
• Statische Fehleranalyse zur Übersetzungszeit möglich<br />
• Höhere Ausführungsgeschw<strong>in</strong>digkeit des Programmes<br />
• Nicht flexibel<br />
• Dynamisches B<strong>in</strong>den (typ. objektorientierte Programmierung)<br />
• Zuordnung zwischen aufrufen<strong>der</strong> Botschaft und auszuführendem Code geschieht zur Laufzeit<br />
des Programmes<br />
• Flexiblere Behandlung von Aufrufen, höhere Laufzeit, statische Fehlerprüfung nicht möglich<br />
11<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer
Beson<strong>der</strong>heiten objektorientierter<br />
<strong>Software</strong>entwicklung<br />
• Abstrakte Klassen<br />
• Werden verwendet, um e<strong>in</strong>en Klassenbaum zu strukturieren<br />
• Können zur Vere<strong>in</strong>barung von Methodenschnittstellen verwendet werden (falls Methoden erst später<br />
implementiert werden)<br />
• S<strong>in</strong>d nicht <strong>in</strong>stanziierbar<br />
• Auch Klassen s<strong>in</strong>d Objekte, d.h. auch Klassen s<strong>in</strong>d Instanzen von Klassen. Derartige Klassen heißen<br />
Metaklassen<br />
12<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
Objekte<br />
• <strong>UML</strong>-Notation Objekt<br />
:Klasse e<strong>in</strong>Objekt e<strong>in</strong>Objekt:Klasse<br />
Attribut1 = Wert1<br />
Attribut2 = Wert2<br />
Attribut3<br />
<strong>der</strong>Oberarm:Roboterarm<br />
aktueller W<strong>in</strong>kel = 45<br />
maximaler W<strong>in</strong>kel = 90<br />
m<strong>in</strong>imaler W<strong>in</strong>kel = 0<br />
:Mitarbeiter<br />
Name = Edelmann<br />
Gehalt = 5000<br />
13
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
Objekte<br />
• Objekte <strong>der</strong> Sem<strong>in</strong>arorganisation<br />
:Kunde<br />
Name = Hans Schulz<br />
Adresse = Dortmund<br />
Kommunikation = 0231/234789<br />
Geburtsdatum = 31.12.1960<br />
Funktion = Berater<br />
Umsatz = 6600,- [€]<br />
Kunde seit = 15.3.1995<br />
:Kunde<br />
Name = Sab<strong>in</strong>e Wenzel<br />
Adresse = Bochum<br />
Kommunikation = 0234/76424<br />
Geburtsdatum = 29.2.1972<br />
Funktion = Systemanalytiker<br />
Umsatz = 2500,- [€]<br />
Kunde seit = 30.6.1998<br />
14
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
Objekte<br />
• <strong>UML</strong>-Objektdiagramm<br />
e<strong>in</strong>Objekt1:Klasse1<br />
E<strong>in</strong> Objekt<br />
Verb<strong>in</strong>dung (l<strong>in</strong>k)<br />
:Klasse2<br />
:Klasse4<br />
:Klasse3<br />
Attribut1 = Wert1<br />
Attribut2 = Wert2<br />
15
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
Objekte<br />
• Beispiel für e<strong>in</strong> Objektdiagramm<br />
:Kunde<br />
Name = Hans Schulz<br />
Adresse = Dortmund<br />
Kommunikation = 0231/234789<br />
Geburtsdatum = 31.12.1960<br />
Funktion = Berater<br />
Umsatz = 6600,- [€]<br />
Kunde seit = 15.3.1995<br />
:Veranstaltung<br />
Nummer = 5<br />
Dauer = 3 [Tage]<br />
Vom = 15.1.2001<br />
Bis = 17.1.2001<br />
Ort = Hotel Sauerland<br />
:Veranstaltung<br />
Nummer = 27<br />
Dauer = 1 [Tag]<br />
Vom = 5.2.2001<br />
Bis = 5.2.2001<br />
Ort = Uni Bochum<br />
16
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
Objekte<br />
• Identität und Gleichheit von Objekten<br />
:Firma<br />
Name = KfZ-Zubehör GmbH<br />
Identität<br />
:Firma<br />
Name = Tankbau KG<br />
:Firma<br />
Name = Beratung und Mehr GmbH<br />
:Firma<br />
Name = KfZ-Zubehör GmbH<br />
:Firma<br />
Name = Tankbau KG<br />
Gleichheit<br />
:Firma<br />
Name = Beratung und Mehr GmbH<br />
:Firma<br />
Name = Beratung und Mehr GmbH<br />
17
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
Klassen<br />
• Beispiel<br />
:Kunde<br />
Name = Hans Schulz<br />
Adresse = Dortmund<br />
Kommunikation = 0231/234789<br />
Geburtsdatum = 31.12.1960<br />
Funktion = Berater<br />
Umsatz = 6600,- [€]<br />
Kunde seit = 15.3.1995<br />
:Kunde<br />
Name = Sab<strong>in</strong>e Wenzel<br />
Adresse = Bochum<br />
Kommunikation = 0234/76424<br />
Geburtsdatum = 29.2.1972<br />
Funktion = Systemanalytiker<br />
Umsatz = 2500,- [€]<br />
Kunde seit = 30.6.1998<br />
Name<br />
Adresse<br />
Kommunikation<br />
Geburtsdatum<br />
Funktion<br />
Umsatz<br />
Kunde seit<br />
anlegen()<br />
buchen()<br />
abmelden()<br />
Kunde<br />
18
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
Klassen<br />
• <strong>UML</strong>-Notation Klasse<br />
Nur Klassennamen<br />
Klasse<br />
Nur Attribute<br />
Klasse<br />
Attribut1<br />
Attribut2<br />
…..<br />
Nur Operationen<br />
Klasse<br />
Ausführliche Darstellung<br />
Attribut1<br />
Attribut2<br />
Attribut3<br />
…..<br />
Operation1()<br />
Operation2()<br />
Operation3()<br />
Operation4()<br />
…..<br />
Klasse<br />
Namensfeld<br />
Attributsliste<br />
Operationsliste<br />
Operation1()<br />
Operation2()<br />
….<br />
<br />
Kunde<br />
{Autor=Balzert<br />
Version 1.0}<br />
19
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
Klassen<br />
• <strong>UML</strong>-Notation für Attribute<br />
Klasse<br />
Attribut1: Typ = Anfangswert1<br />
Attribut2: Typ<br />
Klassenattribut: Typ<br />
/abgeleitetes Attribut: Typ<br />
Attribute:<br />
{ Merkmal1, Merkmal2, … }<br />
Person<br />
Geburtsdatum<br />
/Alter<br />
20
Operationen<br />
• Drei Klassen von Operationen<br />
• Objektoperationen (kurz: Operationen)<br />
• Konstruktoroperationen (kurz: Konstruktoren)<br />
• Klassenoperationen<br />
Mitarbeiter<br />
Personal-Nr<br />
Name<br />
Geburtsdatum<br />
E<strong>in</strong>stellungsdatum<br />
Beurteilung<br />
Anzahl<br />
Bezeichnung<br />
Ort<br />
Leiter<br />
Abteilungsprofil<br />
Abteilung<br />
gib Abteilungsprofil()<br />
e<strong>in</strong>stellen()<br />
entlassen()<br />
erstelle Arbeitsbesche<strong>in</strong>igung()<br />
notiere Beurteilung()<br />
berechne Dienstzeit()<br />
erstelle Geburtstagsliste()<br />
versetze <strong>in</strong> Abteilung()<br />
erstelle Zeugnis()<br />
21<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
Operationen<br />
• <strong>UML</strong>-Notation für Operationen<br />
Klasse<br />
Operationen()<br />
Klassenoperationen()<br />
abstrakte Operationen()<br />
Operation()<br />
{Merkmal1, Merkmal2, … }<br />
• Klassenoperationen<br />
Aushilfe<br />
Rechteck<br />
Name<br />
Adresse<br />
Stundenzahl<br />
Stundenlohn<br />
erhöhe Stundenlohn()<br />
Mittelpunkt<br />
Länge<br />
Breite<br />
Farbe<br />
än<strong>der</strong>e Farbe()<br />
22
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
Assoziation<br />
• Modelliert Beziehungen zwischen Objekten gleichrangiger Klassen<br />
• Auch zwischen Objekten <strong>der</strong>selben Klasse zulässig (reflexive Assoziation)<br />
• Im Gegensatz dazu verknüpft e<strong>in</strong>e Vererbung Klassen mite<strong>in</strong>an<strong>der</strong>, nicht Objekte<br />
<strong>der</strong> Klassen<br />
• In <strong>der</strong> Systemanalyse: bidirektional<br />
• <strong>UML</strong>: b<strong>in</strong>äre und höherwertige Assoziationen<br />
23
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
Assoziation<br />
• Fallstudie »Sem<strong>in</strong>arorganisation«<br />
Objektdiagramm<br />
:Kunde<br />
Name = Hans Schulz<br />
Adresse = Dortmund<br />
:Zahlungsverzug<br />
Betrag = 2000,-<br />
Stichtag = 10.5.05<br />
:Zahlungsverzug<br />
Betrag = 1500,-<br />
Stichtag = 15.7.05<br />
Klassendiagramm<br />
Name<br />
Adresse<br />
Kunde<br />
1 hat *<br />
Betrag<br />
Stichtag<br />
Zahlungsverzug<br />
24
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
Assoziation<br />
• <strong>UML</strong>-Notation<br />
Attribut<br />
Klasse1<br />
k1<br />
k2<br />
Attribut<br />
Klasse2<br />
Operation()<br />
Operation()<br />
Klasse1<br />
Attribut<br />
Operation()<br />
k2<br />
k1<br />
reflexive<br />
Assoziation<br />
25
Assoziation<br />
Kard<strong>in</strong>alität<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
• Kard<strong>in</strong>alität (multiplicity)<br />
Name<br />
Adresse<br />
Kunde<br />
1 *<br />
Zahlungsverzug<br />
Betrag<br />
Stichtag<br />
Je<strong>der</strong> Zahlungsverzug gehört<br />
genau zu e<strong>in</strong>em Kunden<br />
Je<strong>der</strong> Kunde hat 0 bis *<br />
Zahlungsverzüge<br />
26
Assoziation<br />
Kard<strong>in</strong>alität<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
• <strong>UML</strong>-Notation<br />
KlasseA<br />
k1<br />
Rolle A<br />
Assoziationsname<br />
Assoziationsname<br />
k2<br />
Rolle B<br />
KlasseB<br />
Anzahl <strong>der</strong> Assoziationen:<br />
Zwischen e<strong>in</strong>em beliebigen Objekt und<br />
e<strong>in</strong>em Objekt <strong>der</strong> Klasse A gibt es:<br />
KlasseA<br />
KlasseA<br />
KlasseA<br />
KlasseA<br />
1<br />
*<br />
0..1<br />
1..*<br />
genau e<strong>in</strong>e Beziehung<br />
(Muss-Beziehung)<br />
viele Beziehungen (null, e<strong>in</strong>e o<strong>der</strong> mehrere)<br />
(Kann-Beziehung)<br />
null o<strong>der</strong> e<strong>in</strong>e Beziehung<br />
(Kann-Beziehung)<br />
e<strong>in</strong>e o<strong>der</strong> mehrere Beziehungen<br />
(Muss-Beziehung)<br />
27
Assoziation<br />
Kard<strong>in</strong>alität<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
• <strong>UML</strong>-Notation<br />
KlasseA<br />
KlasseA<br />
KlasseA<br />
KlasseA<br />
3..*<br />
0..5<br />
4<br />
1, 3, 5<br />
drei o<strong>der</strong> mehr als drei Beziehungen<br />
(Muss-Beziehung)<br />
null bis fünf Beziehungen<br />
(Kann-Beziehung)<br />
genau vier Beziehungen<br />
(Muss-Beziehung)<br />
e<strong>in</strong>e, drei o<strong>der</strong> fünf Beziehungen<br />
(Muss-Beziehung)<br />
KlasseA<br />
1..4, 7, 9..* nicht ke<strong>in</strong>e, fünf, sechs o<strong>der</strong> acht<br />
Beziehungen (Muss-Beziehung)<br />
28
Assoziation<br />
Kard<strong>in</strong>alität<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
• Kann- und Muss-Assoziationen<br />
Kunde<br />
muss<br />
kann<br />
1 gehört<br />
*<br />
erteilt<br />
Auftrag<br />
Kunde<br />
muss<br />
muss<br />
1 1 ..*<br />
Auftrag<br />
29
Assoziation<br />
Assoziationsnamen und Rollen<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
• Rolle<br />
• Beschreibt, welche Funktion e<strong>in</strong> Objekt <strong>in</strong> e<strong>in</strong>er Assoziation <strong>in</strong>nehat<br />
• Beispiel<br />
1 *<br />
Firma Mitarbeiter PKW<br />
Arbeitgeber<br />
Arbeitnehmer<br />
0..1 0..1<br />
Fahrer<br />
Dienstwagen<br />
30
Assoziation<br />
Assoziationsnamen und Rollen<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
• Rollennamen bei mehr als e<strong>in</strong>er Assoziation<br />
Dozent<br />
1..* *<br />
Referent<br />
(subset)<br />
* *<br />
Sem<strong>in</strong>arleiter<br />
Veranstaltung<br />
:Dozent<br />
Referent<br />
:Dozent<br />
Referent<br />
Sem<strong>in</strong>arleiter<br />
:Veranstaltung<br />
31
Assoziation<br />
Assoziationsnamen und Rollen<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
• Rollennamen <strong>in</strong> e<strong>in</strong>er reflexiven Assoziation<br />
Angestellter<br />
Name<br />
Gehalt<br />
Position<br />
Mitarbeiter<br />
*<br />
Chef<br />
0..1<br />
{Chef.Gehalt > Mitarbeiter.Gehalt}<br />
:Angestellter<br />
Chef<br />
Chef<br />
Mitarbeiter<br />
:Angestellter<br />
Chef<br />
Chef<br />
Mitarbeiter<br />
:Angestellter<br />
Mitarbeiter<br />
:Angestellter<br />
Mitarbeiter<br />
:Angestellter<br />
32
Assoziation<br />
Son<strong>der</strong>fälle von Assoziationen<br />
• Geordnete Assoziation<br />
• Def<strong>in</strong>ition e<strong>in</strong>er Ordnung auf e<strong>in</strong>er Assoziation<br />
Kunde<br />
* bucht {or<strong>der</strong>ed} *<br />
Teilnehmer<br />
Veranstaltung<br />
:Kunde<br />
1. Veranstaltung<br />
:Veranstaltung<br />
:Kunde<br />
1. Veranstaltung<br />
:Veranstaltung<br />
:Veranstaltung<br />
33<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer
Assoziation<br />
Son<strong>der</strong>fälle von Assoziationen<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
• Restriktionen (constra<strong>in</strong>ts)<br />
Zugfahrzeug<br />
Anhängerlast<br />
0..1 0..1<br />
Gewicht<br />
Anhänger<br />
{ Zugfahrzeug.Anhängerlast >= Anhänger.Gewicht }<br />
ist Mitglied <strong>in</strong><br />
*<br />
Patient<br />
{or}<br />
*<br />
ist Mitglied <strong>in</strong><br />
1<br />
Ersatzkasse<br />
1 Privatkasse<br />
erster:Patient<br />
zweiter:Patient<br />
:Ersatzkasse<br />
:Privatkasse<br />
34
Assoziation<br />
Son<strong>der</strong>fälle von Assoziationen<br />
• Qualifizierte Assoziation<br />
Lager<br />
Lagernummer<br />
Lager<br />
*<br />
*<br />
0..1<br />
Palette<br />
*<br />
Palette<br />
35<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer
Assoziation<br />
Son<strong>der</strong>fälle von Assoziationen<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
• Abgeleitete Assoziation<br />
* bestellt * * 1<br />
Kunde Artikel Lieferant<br />
* / liefert an<br />
*<br />
abgeleitete Assoziation<br />
:Kunde<br />
:Artikel<br />
:Lieferant<br />
:Artikel<br />
:Lieferant<br />
36
Assoziation<br />
Assoziative Klassen<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
• Assoziation kann Eigenschaften e<strong>in</strong>er Klasse besitzen<br />
Name<br />
Adresse<br />
Kunde<br />
* *<br />
Veranstaltung<br />
Nummer<br />
Dauer<br />
Buchung<br />
Angemeldet am<br />
Abgemeldet am<br />
Rechnung am<br />
anmelden()<br />
abmelden()<br />
37
Assoziation<br />
Assoziative Klassen<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
• Auflösen e<strong>in</strong>er assoziativen Klasse<br />
A<br />
0..1<br />
*<br />
B<br />
A<br />
B<br />
1<br />
1<br />
C<br />
*<br />
C<br />
0..1<br />
A<br />
*<br />
*<br />
B<br />
A<br />
B<br />
1<br />
1<br />
C<br />
*<br />
C<br />
*<br />
38
Assoziation<br />
Aggregationen und Kompositionen: Aggregation<br />
• Son<strong>der</strong>fall <strong>der</strong> Assoziation<br />
• Liegt vor, wenn zwischen den Objekten <strong>der</strong> beteiligten Klassen (kurz: den<br />
beteiligten Klassen) e<strong>in</strong>e Rangordnung gilt, die sich durch »ist Teil von« bzw.<br />
»besteht aus« beschreiben lässt<br />
• Man spricht vom Ganzen und se<strong>in</strong>en Teilen<br />
• Die Objekte <strong>der</strong> Aggregation bilden e<strong>in</strong>en gerichteten azyklischen Graphen<br />
• Wenn B Teil von A ist, dann darf A nicht Teil von B se<strong>in</strong><br />
• Shared aggregation (weak ownership)<br />
• E<strong>in</strong> Teilobjekt kann mehreren Aggregatobjekten zugeordnet werden<br />
39<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer
Assoziation<br />
Aggregationen und Kompositionen: Komposition<br />
• Starke Form <strong>der</strong> Aggregation<br />
• Zusätzlich muss gelten<br />
• Jedes Objekt <strong>der</strong> Teilklasse kann – zu e<strong>in</strong>em Zeitpunkt – nur Komponente e<strong>in</strong>es e<strong>in</strong>zigen Objekts <strong>der</strong><br />
Aggregatklasse se<strong>in</strong>, d. h., die bei <strong>der</strong> Aggregatklasse angetragene Kard<strong>in</strong>alität darf nicht größer als<br />
e<strong>in</strong>s se<strong>in</strong> (unshared aggregation, strong ownership)<br />
• E<strong>in</strong> Teil darf jedoch – zu e<strong>in</strong>em an<strong>der</strong>en Zeitpunkt – auch e<strong>in</strong>em an<strong>der</strong>en Ganzen zugeordnet werden<br />
• Die dynamische Semantik des Ganzen gilt auch für se<strong>in</strong>e Teile (propagation semantics)<br />
• Wird beispielsweise das Ganze kopiert, so werden auch se<strong>in</strong>e Teile kopiert<br />
• Wird das Ganze gelöscht, dann werden automatisch se<strong>in</strong>e Teile gelöscht<br />
(they live and die with it)<br />
• E<strong>in</strong> Teil darf jedoch zuvor explizit entfernt werden<br />
40<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
Assoziation<br />
Aggregationen und Kompositionen: Aggregation versus Komposition<br />
Aggregatklasse<br />
Web-Auftritt<br />
Sparkonto<br />
Lagermodul<br />
Erstellt am<br />
Letzte Än<strong>der</strong>ung<br />
Verantwortlich<br />
Kontonummer<br />
Habenz<strong>in</strong>s<br />
/ Kontostand<br />
Nummer<br />
Störungsstatus<br />
eröffnen()<br />
e<strong>in</strong>zahlen()<br />
abholen()<br />
gutschreibenZ<strong>in</strong>sen()<br />
auflösen()<br />
ermittleBestand()<br />
ermittleKapazität()<br />
e<strong>in</strong>lagern()<br />
auslagern()<br />
*<br />
Aggregation<br />
1<br />
Komposition<br />
1<br />
1..*<br />
*<br />
1..*<br />
Web-Seite<br />
Kontobewegung<br />
Lagerplatz<br />
Erstellt am<br />
Letzte Än<strong>der</strong>ung<br />
Verantwortlich<br />
Betrag<br />
Datum<br />
X Koord<strong>in</strong>ate<br />
Y Koord<strong>in</strong>ate<br />
Belegt Status<br />
Sperrkennzeichen<br />
Teilklassen<br />
41
Assoziation<br />
Aggregationen und Kompositionen<br />
• Höherwertige Assoziationen<br />
Programmierer Projekt Programmiersprache<br />
Meier A C++<br />
Schrö<strong>der</strong> B Java<br />
Ludwig A Java<br />
Projekt<br />
*<br />
Programmierer<br />
* *<br />
Programmiersprache<br />
42<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer
Vererbung<br />
• Vererbung (generalization)<br />
• E<strong>in</strong>e spezialisierte Klasse (Unterklasse, subclass, abgeleitete Klasse) verfügt über<br />
• die Eigenschaften<br />
• das Verhalten und<br />
• die Assoziationen e<strong>in</strong>er o<strong>der</strong> mehrerer allgeme<strong>in</strong>er Klassen<br />
(Oberklassen, superclasses, Basisklassen)<br />
43<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
Vererbung<br />
• Beispiel für den<br />
Vererbungsmechanismus<br />
Objektebene<br />
:KlasseX<br />
Verb<strong>in</strong>dung<br />
(l<strong>in</strong>k)<br />
ObjektA: KlasseA<br />
AttributA = Wert1<br />
Klassenebene<br />
KlasseA<br />
AttributA<br />
KlassenattributA = W<br />
OperationA()<br />
KlassenoperationA()<br />
Direkte Oberklasse<br />
von<br />
KlasseB<br />
1<br />
KlasseX<br />
Assoziation<br />
:KlasseX<br />
:KlasseY<br />
ObjektB: KlasseB<br />
AttributA = Wert2<br />
AttributB = Wert3<br />
KlasseB<br />
AttributB<br />
KlassenattributA = W<br />
OperationB()<br />
1<br />
KlasseY<br />
:KlasseX<br />
ObjektC1: KlasseC1<br />
KlasseC1<br />
KlasseC2<br />
:KlasseY<br />
AttributC1 = Wert4<br />
AttributB = Wert5<br />
AttributA = Wert6<br />
AttributC1<br />
KlassenattributA = W<br />
OperationC1()<br />
AttributC2<br />
KlassenattributA = W<br />
OperationC2()<br />
:KlasseX<br />
:KlasseY<br />
ObjektC2: KlasseC2<br />
AttributC2 = Wert7<br />
AttributB = Wert8<br />
AttributA = Wert9<br />
direkte Unterklasse<br />
von<br />
KlasseB<br />
direkte Unterklasse<br />
von<br />
KlasseB<br />
44
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
Vererbung<br />
• <strong>UML</strong>-Notation<br />
alternativ<br />
45
Vererbung<br />
• Unterklassen »unsichtbar«<br />
• Jede Klasse »kennt« nur ihre eigenen Attribute, Operationen und Assoziationen und die ihrer<br />
Oberklassen, sofern diese für sie sichtbar s<strong>in</strong>d<br />
• Im Allgeme<strong>in</strong>en unterscheidet man drei verschiedene Sichtbarkeitsstufen<br />
• Außerhalb <strong>der</strong> Klasse nicht sichtbar (private)<br />
(<strong>in</strong> <strong>der</strong> <strong>UML</strong>: - ), auch nicht für Unterklassen<br />
• Für alle Unterklassen sichtbar (protected)<br />
(<strong>in</strong> <strong>der</strong> <strong>UML</strong>: # )<br />
• Für alle an<strong>der</strong>en Klassen sichtbar, d.h. öffentlich (public)<br />
(<strong>in</strong> <strong>der</strong> <strong>UML</strong>: + )<br />
46<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
Vererbung<br />
• Fallstudie »Sem<strong>in</strong>arorganisation«<br />
Name<br />
Adresse<br />
Kontakt<br />
Geburtsdatum<br />
Funktion<br />
Umsatz<br />
Kunde seit<br />
Kunde<br />
erstelle Adressaufkleber()<br />
ermittle durchschn. Umsatz()<br />
Dozent<br />
Name<br />
Adresse<br />
Kontakt<br />
Geburtsdatum<br />
Biografie<br />
Honorar pro Tag<br />
Dozent seit<br />
erstelle Adressaufkleber()<br />
l<strong>in</strong>k Sem<strong>in</strong>artyp()<br />
l<strong>in</strong>k Veranstaltung()<br />
47
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
Vererbung<br />
• Fallstudie »Sem<strong>in</strong>arorganisation«<br />
Name<br />
Adresse<br />
Kontakt<br />
Geburtsdatum<br />
Ersterfassung am<br />
Person<br />
{abstrakt}<br />
{abstrakte} Oberklasse von<br />
Kunde und Dozent<br />
erstelle Adressaufkleber()<br />
Kunde<br />
Dozent<br />
Funktion<br />
Umsatz<br />
ermittle durchschn. Umsatz()<br />
Biografie<br />
Honorar pro Tag<br />
l<strong>in</strong>k Sem<strong>in</strong>artyp()<br />
l<strong>in</strong>k Veranstaltung()<br />
48
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
Vererbung<br />
• Mehrfachvererbung<br />
Uhr-Anzeige<br />
Stunde<br />
M<strong>in</strong>ute<br />
13:47<br />
Digital-Anzeige<br />
Anzeigegröße<br />
Analog-Anzeige<br />
Ziffernblatt<br />
Stundenzeiger<br />
M<strong>in</strong>utenzeiger<br />
Digital-Analog-Anzeige<br />
Digital-Anordnung<br />
13:47<br />
49
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
Vererbung<br />
• Vererbungsstruktur mit Diskrim<strong>in</strong>ator<br />
Mitarbeiter<br />
Arbeitszeit<br />
Vollzeitkraft<br />
Teilzeitkraft<br />
freier Mitarbeiter<br />
Mitarbeiter<br />
Tätigkeit<br />
Systemanalytiker<br />
Entwerfer<br />
Programmierer<br />
50
Pakete<br />
• Pakete (packages)<br />
• Strukturierungsmechanismus<br />
• Erlauben es, Komponenten zu e<strong>in</strong>er größeren E<strong>in</strong>heit zusammenzufassen<br />
• Paketbegriff allerd<strong>in</strong>gs nicht e<strong>in</strong>heitlich def<strong>in</strong>iert<br />
• Analoge Begriffe: Subsystem, subject, category<br />
• <strong>UML</strong><br />
• E<strong>in</strong> Paket gruppiert Modellelemente (z. B. Klassen) und Diagramme<br />
• E<strong>in</strong> Paket kann selbst Pakete enthalten<br />
51<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
Pakete<br />
• <strong>UML</strong>-Notation<br />
Paketname<br />
Handelssystem<br />
E<strong>in</strong>kauf<br />
Verkauf<br />
Abhängigkeit<br />
Lager<br />
52
Pakete<br />
• Kriterien<br />
• Das Paket soll e<strong>in</strong>e logische E<strong>in</strong>heit bilden, d. h. es soll so strukturiert se<strong>in</strong>, dass es<br />
1. den Leser durch das Modell führt<br />
2. e<strong>in</strong>en Themenbereich enthält, <strong>der</strong> für sich alle<strong>in</strong> betrachtet und verstanden werden kann<br />
3. Klassen enthält, die logisch zusammengehören, z. B. Artikel, Lieferant und Lager<br />
4. für sich entworfen und eventuell implementiert werden kann, wobei e<strong>in</strong>e wohldef<strong>in</strong>ierte<br />
Schnittstelle zur Umgebung vorhanden ist<br />
• Die Schnittstelle soll<br />
1. Vererbungsstrukturen nur <strong>in</strong> vertikaler Richtung schneiden, d. h. zu je<strong>der</strong> Unter-klasse sollen alle<br />
Oberklassen <strong>in</strong> dem Paket enthalten se<strong>in</strong><br />
2. ke<strong>in</strong>e Aggregation durchtrennen<br />
3. möglichst wenig Assoziationen enthalten<br />
• Die Kopplung zwischen den Klassen – <strong>in</strong>nerhalb e<strong>in</strong>es Pakets – soll möglichst<br />
groß und zwischen Paketen möglichst ger<strong>in</strong>g se<strong>in</strong>.<br />
• Jedes potenzielle Paket prüft man auf se<strong>in</strong>e Kopplungseigenschaft<br />
53<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer
Botschaften<br />
• Botschaft (message)<br />
• Auffor<strong>der</strong>ung e<strong>in</strong>es Sen<strong>der</strong>s (client) an e<strong>in</strong>en Empfänger (server, supplier), e<strong>in</strong>e Dienstleistung zu<br />
erbr<strong>in</strong>gen<br />
• Der Empfänger <strong>in</strong>terpretiert diese Botschaft und führt e<strong>in</strong>e Operation aus<br />
• Der Sen<strong>der</strong> <strong>der</strong> Botschaft weiß nicht, wie die entsprechende Operation ausgeführt wird<br />
• Die Menge <strong>der</strong> Botschaften, auf die Objekte e<strong>in</strong>er Klasse reagieren können, wird als Protokoll<br />
(protocol) <strong>der</strong> Klasse bezeichnet<br />
• E<strong>in</strong>e Botschaft löst e<strong>in</strong>e Operation gleichen Namens aus<br />
54<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
Botschaften<br />
• Fallstudie<br />
»Sem<strong>in</strong>arorganisation«<br />
1: erstelleTN-Liste()<br />
:Veranstaltung<br />
2: getKurztitel()<br />
:Sem<strong>in</strong>artyp<br />
3: getName()<br />
Sem<strong>in</strong>artyp<br />
:Dozent<br />
4: getName()<br />
:Kunde<br />
Kurztitel<br />
Titel<br />
getKurztitel()<br />
1<br />
*<br />
Name<br />
Dozent<br />
getName()<br />
1..*<br />
Veranstaltung<br />
* * *<br />
Nummer<br />
Von<br />
Bis<br />
erstelleTN-Liste()<br />
Kunde<br />
Name<br />
adresse<br />
getName()<br />
Buchung<br />
Angemeldet am<br />
55
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
Szenarios<br />
• Sequenz von Verarbeitungsschritten, die unter bestimmten Bed<strong>in</strong>gungen<br />
auszuführen ist<br />
• Diese Schritte sollen das Hauptziel des Akteurs realisieren und e<strong>in</strong><br />
entsprechendes Ergebnis liefern<br />
• Sie beg<strong>in</strong>nen mit dem auslösenden Ereignis und werden fortgesetzt, bis das Ziel<br />
erreicht ist o<strong>der</strong> aufgegeben wird<br />
• E<strong>in</strong> Geschäftsprozess kann durch e<strong>in</strong>e Kollektion von Szenarios dokumentiert<br />
werden<br />
• Jedes Szenario wird durch e<strong>in</strong>e o<strong>der</strong> mehrere Bed<strong>in</strong>gungen def<strong>in</strong>iert, die zu e<strong>in</strong>em<br />
speziellen Ablauf des jeweiligen Geschäftsprozesses führen<br />
56
Szenarios<br />
<strong>UML</strong>-Darstellung dynamischer Abläufe<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
• Objektdiagramme (object diagrams)<br />
• Kommunikationsdiagramme (communication diagrams)<br />
• Sequenzdiagramme (sequence diagrams)<br />
57
Szenarios<br />
<strong>UML</strong>-Darstellung dynamischer Abläufe<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
• Kommunikationsdiagramm<br />
1: Operation1()<br />
:Klasse1<br />
{transient}<br />
2: Operation2()<br />
3: Operation4()<br />
:Klasse2<br />
{new}<br />
:Klasse4<br />
2.1: Operation3()<br />
:Klasse3<br />
{new}<br />
58
Szenarios<br />
<strong>UML</strong>-Darstellung dynamischer Abläufe<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
• Kommunikations- vs. Objektdiagramm<br />
1: erstelleTN-Liste()<br />
2: getKurztitel()<br />
:Veranstaltung<br />
:Sem<strong>in</strong>artyp<br />
3: getName()<br />
:Dozent<br />
4: getName()<br />
:Kunde<br />
zwölfteVeranstaltung: Veranstaltung<br />
Schrö<strong>der</strong>: Kunde<br />
OOA: Sem<strong>in</strong>artyp<br />
Herbst: Dozent<br />
Schulz: Kunde<br />
Wenzel: Kunde<br />
59
Szenarios<br />
<strong>UML</strong>-Darstellung dynamischer Abläufe<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
• Sequenzdiagramm<br />
Akteur<br />
Operation1()<br />
Botschaft<br />
Bereits existierende Objekte<br />
erstesObjekt<br />
:Klasse1<br />
Klasse3()<br />
:Klasse2<br />
Neu erzeugtes<br />
Objekt<br />
neuesObjekt<br />
:Klasse3<br />
Operation5()<br />
Objekt schickt<br />
Botschaft an<br />
sich selbst<br />
Operation3()<br />
Operation2()<br />
Objekt wird<br />
gelöscht<br />
Balkenlänge gibt<br />
relative Dauer<br />
<strong>der</strong> Aktivität an<br />
60
Szenarios<br />
<strong>UML</strong>-Darstellung dynamischer Abläufe<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
• Sequenzdiagramm: Beispiel<br />
:Veranstaltung :Sem<strong>in</strong>artyp :Dozent :Kunde<br />
erstelleTN-<br />
Liste()<br />
getKurztitel()<br />
getName()<br />
getName()<br />
Zeit<br />
61
Szenarios<br />
<strong>UML</strong>-Darstellung dynamischer Abläufe<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
• Sequenzdiagramm: Beispiel mit Alternativen<br />
:Kunde<br />
[Neukunde]<br />
erfassen()<br />
:Kunde<br />
buchen()<br />
:Veranstaltung<br />
[Altkunde]<br />
aktualisieren()<br />
buchen()<br />
:Veranstaltung<br />
62
Szenarios<br />
<strong>UML</strong>-Darstellung dynamischer Abläufe<br />
SE 2 – <strong>UML</strong> <strong>in</strong> <strong>der</strong> <strong>Analyse</strong><br />
© Prof. Dr. Liggesmeyer<br />
• Sequenz- vs. Kooperationsdiagramm<br />
Klasse<br />
:Klasse<br />
Klassenoperation()<br />
Konstruktoroperation()<br />
:Klasse<br />
Klassenoperation()<br />
Klasse<br />
Konstruktoroperation()<br />
:Klasse<br />
{new}<br />
Objektoperation()<br />
Objektoperation()<br />
:Klasse<br />
63