This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
1 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Softwaretechnik (CNAM)
4. Analyse-Phase:Datenmodell
Wintersemester 2009 / 2010Prof. Dr. Bernhard HummHochschule Darmstadt, FB Informatik
2 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Einordnung in den gesamten Kurs
1. Einführung
2. Vorgehensmodelle
3. Analyse-Phase: Anforderungen und Anwendungsfälle
5 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Für wen ist das Datenmodell gedacht?
� Fachbereich: Idealerweise versteht der Fachbereich das Datenmodell. Falls nicht, kann man die Zusammenhänge des Datenmodells rückspiegeln, ohne die UML-Diagramme direkt zu verwenden
� SW-Entwickler in nachfolgenden Phasen: für Design und Implementierung
� IT-Abteilung des Kunden: um Zusammenhänge zu erläutern
� Teamkollegen: um Zusammenhänge zu erläutern
� Das Datenmodell ist wichtiger Input für Aufwandsschätzungen
formal
informell
Übersicht
Übersicht
Abstraktion
Datenmodell-Elemente
Regeln zur Datenmodellierung
Struktur und Verhalten
Kontrollfragen
� Abstraktion
Agenda
7 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Von der Realität zum Modell
Realität:Realität:
Quelle: www.musoft.org
8 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Von der Realität zum Modell
Rechte Tür
Linke Tür
Objekte
Quelle: www.musoft.org
9 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Von der Realität zum Modell
Rechte Tür
Karussell 1Karussell 1
ermöglichtZugang zu
Lagerfeld 1
Lagerfeld 2
Lagerfeld 3
...
Objekte +
Beziehungen
Quelle: www.musoft.org
10 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Von der Realität zum Modell
Objekte +
Beziehungen +
Eigenschaften
Karussell 1
Lagerfeld 1
zulässigesGewicht = 700
...
Quelle: www.musoft.org
11 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Vom konkreten zum allgemeinen Modell
Rechte Tür
Linke Tür
Abstraktion:
von Objekten
zu Klassen Tür
Es gibt eine rechte
und eine linke Tür.
Es gibt Türen.
Quelle: www.musoft.org
12 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Vom konkreten zum allgemeinen Modell
Tür
Linke TürKarussell
Karussell 2
ermöglicht Zugang zu
ermöglichtZugang zu
Klassen +
Beziehungen
Die linke Tür ermöglicht
den Zugang zum
zweiten Karussell.
Türen ermöglichen
den Zugang zu
Karussells.
Quelle: www.musoft.org
13 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
28 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Gestaltungsziele für Datenmodelle
Korrektheit
Redundanzfreiheit
Einfachheit
Erweiterbarkeit
29 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Aufgabe 1
Modellieren Sie folgenden Sachverhalt:
� Eine Firma hat Kunden, Lieferanten und Mitarbeiter
� Alle werden durch Name und Adresse identifiziert
� Ein Mitarbeiter ist entweder Arbeiter oder Manager
� Arbeiter können zu Managern befördert werden
� Kunden können gleichzeitig Lieferanten sein
� In Zukunft können auch weitere Personen wie Gesellschafter etc., aber auch weitere Laufbahnstufen wie Ingenieur etc. relevant werden
30 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Erster Lösungsansatz: mit Vererbung (Generalisierung / Spezialisierung)
class Person mit Vererbung
KundeLieferant Mitarbeiter
ManagerArbeiter
Person
- adresse: String- name: String
object Person mit Vererbung
Huber :Kunde Huber :Lieferant
Redundanter Name und Adresse, wenn Huber sowohl Kunde als auchLieferant ist
Schmidt :Arbeiter Schmidt :Manager
Bei der Beförderung von Schmidt vom Arbeiter zum Managager muss das Arbeiter-Objekt gelöscht, ein neues Manager-Objekt angelegt und alle Attributevom Arbeiter- zum Manager-Objekt kopiert werden.
Einfügen neuer Personen wie Gesellschafter etc., oder weiterer Laufbahnstufen wie Ingenieur etc. erfordern eine strukturelle Änderung des Datenmodells.
31 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Bessere Lösung: Mit Assoziation (bzw. Komposition)
Dieselbe Person kann verschiedene Rollen haben. Name und Adresse werden nur einmal gespeichert.
Die Beförderung vom Arbeiter zum Manager wird durch Änderung des Attibuts typ dargestel lt.
Neue Rollen wie Gesellschafter etc. können durch einfache Erweiterung des Aufzählungstyps dargestell t werden.
32 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Regel 1: Setze Vererbung (Generalisierung / Spezialisierung) sparsam ein
� Vererbung (Generalisierung / Spezialisierung) ist das am meiste überschätzte und überbenutzte Konzept der Objekt-Orientierung
���� Setze Vererbung nur bei echter „ist ein“ Beziehung ein
���� Ersetze, wo sinnvoll möglich, eine Vererbung durch eine AssoziationBeispiele:
– Ein Rothaariger ist eine Person � eine Person hat die Haarfarbe rot
– Eine Frau ist eine Person � eine Person hat das Geschlecht weiblich
– Ein Kunde ist eine Person � eine Person hat die Rolle Kunde
���� Verwende nur einfache Vererbung (Single Inheritance)„Bei der Einfachvererbung hat man nur einen Schuss – und der muss sitzen!“
���� Schachtele Vererbungsbäume nicht zu tiefTiefe 2-3 reicht meistens aus
� Sparsame Verwendung von Vererbung fördert die Einfachheit, Erweiterbarkeit und Redundanzfreiheit
33 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Aufgabe 2
Modellieren Sie folgenden Sachverhalt:
� In einem MP3-Archiv sollen Lieder gespeichert werden
� Für jedes Lied soll der Titel des Lieds, der Interpret und der Name des Albums gespeichert werden
34 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Erster Lösungsansatz: denormalisiert
class Lied denormalisiert
Lied
- interpret: String- album: String- titel: String
object Lied denormalisiert
Not That Kind :Lied
interpret = Anastaciaalbum = Not That Kind
I'm Outta Love :Lied Cowboys & Kisses :Lied
Shine On You Crazy Diamond :Lied
interpret = Anastaciaalbum = Not That Kind
interpret = Anastaciaalbum = Not That Kind
interpret = Pink Floydalbum = Wish You Were Here
Ist der Name des Interpreten falsch geschrieben, so muss dies in allen Objekten vom Typ LIedkorrigiert werden.Sollen zum Album weitere Daten gespeichert werden wie z.B. das Genre (Klassik, Rock, ...), so muss das redundant in allen Liedern erfolgen.
35 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Bessere Lösung: normalisiert
object Lied normalisiert
Not That Kind :Lied
I'm Outta Lov e :Lied
Cowboys & Kisses :Lied
Shine On You Crazy Diamond :Lied
Ist der Name des Interpreten falsch geschrieben, so muss dies nur im Objekt Interpret geändert werden, auch wenn er mehrere Alben herausgebracht hatSollen zum Album weitere Daten gespeichert werden wie z.B. das Genre (Klassik, Rock, ...), so muss das nur einmal im Album-Objekt erfolgen.
Not That Kind :Album
Anastacia :Interpret
Pink Floyd :Interpret Wish You Were Here :Album
von
von
class Lied normalisiert
Lied
- titel: String
Album
- titel: String
Interpret
- name: String1..*
<von
36 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Regel 2: Normalisiere das Datenmodell
� Redundanzen können auftreten:
– Zwischen Entitätstypen, z.B. Name und Adresse sowohl in Entitätstyp Kunde als auch in Entitätstyp Lieferant
– Zwischen Entitätsinstanzen (Objekten), z.B. Name des Albums und des Interpreten in allen Liedobjekten desselben Albums wiederholt
� Normalisierung ist ein Konzept aus der Datenbanktheorie zur Vermeidung von Redundanzen:1. Normalform (1NF), …, 5. Normalform (5NF), Boyce-Codd-Normalform (BCNF), …
���� Normalisiere das Datenmodell, soweit fachlich sinnvoll
� Meist reicht 3NF aus. Eine formale Betrachtung ist nicht notwendig
37 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Aufgabe 3
Modellieren Sie folgenden Sachverhalt:
� Kunden können Bestellungen für Waren aufgeben
� Mehrere Bestellungen zusammen bilden einen Auftrag
� Ein Auftrag bezieht sich immer auf einen Kunden
38 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Erster Lösungsansatz:Zyklische Assoziationen
class Bestellung mit Zykel
Person
Kunde
BestellungAuftrag
1
gibt auf
*
*
von
1
*1
object Bestellung mit Zykel
Huber :Kunde
Buch :BestellungDezember :Auftrag
Müller :Kunde
Müller hat den Auftrag für Hubers Bestellungen. Das ist natürl ich fachlich falsch. Das Datenmodell erlaubt es aber.
gibt aufvon
39 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Bessere Lösung:Azyklische Assoziationen
class Bestellung ohne Zykel
Person
Kunde
BestellungAuftrag
*1
*
von
1
object Bestellung ohne Zykel
Buch :BestellungDezember :Auftrag
Müller :Kunde
Über den Auftrag ist der Kunde eindeutig bestimmt, der die Bestellung aufgegeben hat.
von
40 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Regel 3: Vermeide zyklische Assoziationen
���� Vermeide Zyklen in den Assoziationen zwischen Entitäten
� Zyklen können meist durch Weglassen von (redundanten) Assoziationen aufgelöst werden
� Zyklenfreiheit reduziert die Redundanz
� Zyklenfreiheit erhöht die Korrektheit. Falls Zyklen nicht vermeidbar sind, müssen Widersprüche über Constraints ausgeschlossen werden, z.B. Kunde der Bestellung muss gleich sein dem Kunden des Auftrags
41 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Aufgabe 4
Es soll ein System für das Customer Relation Management (CRM) für einen Reiseveranstalter entworfen werden. Modellieren Sie folgenden Sachverhalt:
� Kunden können Reisen buchen. Ein Reiseauftrag kann mehrere Reisende umfassen
� Beschwerdevorgänge sollen erfasst werden können
� Kunden können mittels Kampagnen über neue Produkte informiert werden
� Im Call Center soll die Kontakthistorie eines Kunden angezeigt werden können
42 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Erster Lösungsansatz:m:n-Beziehungen
class CRM mit m:n Beziehungen
Person
Kunde
Reiseauftrag Beschwerdev organg Kampagne
1..*
*
1..*
*
1..*
*
object CRM mit m:n Beziehungen
Huber :Kunde
Mayer :Kunde
Balearen :Kampagne
Mallorca :Beschwerdev organg
Mallorca :Reiseauftrag
Die Kundenkontakthistorie ist implizit in den Assoziationen von Kunde zu Kampagne, Reiseauftrag und Beschwerdevorgang.
43 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
{Die assoziierten Objekte müssen zum Typ passen (Reise zu Reiseauftrag etc.). Die Rolle muss zum Typ passen, z.B: Reiseteilnehmer zu Reise oder Beschwerdeführer zu Beschwerde.}{xor}
0..1
1..*
0..1
1..*
0..1
1..*
*
1
object CRM mit Entität Kontakt
Huber :Kunde
Mayer :Kunde
Balearen :Kampagne
Mailing-Empfänger :Kontakt
Reiseanmelder :Kontakt
Reiseteilnehmer :Kontakt
Beschwerdeführer :Kontakt
Mallorca :Beschwerdevorgang
Mallorca :Reiseauftrag
Der Kontakt wird zur zentralen Entität des CRM-Systems - obwohl er in der fachlichen Beschreibung so gar nicht erwähnt wurde. Er dient nicht zur zur Auflösung von m:n-Beziehungen zwischen Kunde und Reiseauftrag etc. Er erlaubt Call Center Mitarbeitern Fragen zu beantworten wie: welche Mail ings hat der Kunde erhalten? Wie oft ist er gereist? Wie oft hat er sich beschwert? etc.
44 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Regel 4: Beschränke Dich auf 1:n Beziehungen
���� Löse m:n-Beziehungen in (mehrere) 1:n-Beziehungen auf. Finde fachlich passende
Begriffe für die entstehenden neuen Entitäten
� Die Auflösung der m:n-Beziehungen ist kein (Datenbank-) technischer Vorgang! Häufig enthalten die neu entstehenden Entitäten weitere fachliche Informationen (z.B. das Datum des Kundenkontakts). Außerdem sind für deren Pflege häufig Dialoge notwendig.Manchmal verwendet der Fachbereich noch keinen Begriff für die neue Entität. Es ist aber sinnvoll, gemeinsam mit dem Fachbereich dafür einen passenden Begriff zu finden, der z.B. später auch der Titel des Dialogs wird.
���� Vermeide 1:1-Beziehungen
� Stehen zwei Entitäten in einer 1:1-Beziehung, so sollte man sie, sofern fachlich sinnvoll, in eine Entität zusammenfassenBeispiel: Auftrag und Auftragskopf � Auftrag
� 1:1-Beziehungen aufzulösen vereinfacht das Datenmodell
45 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Eigentlich selbstverständlich, aber …Weitere Regeln
���� Modelliere nur fachliche, nie technischen Aspekte
� Beispiel: Eine Entität Liste oder gar VerketteteListe gibt es nicht
���� Beschränke Dich auf das für das System notwendige
� Beispiel: Sollen für einen Reisekatalog die Ausstattungen von Hotels (Pool, Sauna, Tennis, etc.) modelliert werden, so sind nur die Kategorien relevant. Irrelevant ist hier, dass Tennis eine Sportart ist, ob Pool und Saunabereich aneinandergrenzen etc.
46 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Übersicht der Regeln für die Datenmodellierung
R1: Setze Vererbung sparsam ein
R4: Beschränke Dich auf 1:n-Beziehungen
R3: Vermeide zyklische Assoziationen
R2: Normalisiere das Datenmodell
Korrektheit
Redundanzfreiheit
Einfachheit
Erweiterbarkeit
Übersicht
Abstraktion
Datenmodell-Elemente
Regeln zur Datenmodellierung
Struktur und Verhalten
Kontrollfragen
� Struktur und Verhalten
Agenda
48 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Sequenzdiagramme: Struktur und Verhalten zusammenbringen
Anwendungs-fall-
Diagramm
Sequenz-Diagramm
1*
Klassen-diagramm
Sequenz-Diagramme
49 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Beispiel Fitness Center:Anwendungsfall + Datenmodell ���� …
cd Kundenverwaltung Fitnesscenter
Buchhaltung
KundenverwaltungDienstleistung
Kunde
- Adresse: int- Kontonummer: int- Mitgliedsnummer: - Name: int
Vertrag
- Datum: int- Laufzeit:
Besuch
- ende: DateTime- start: DateTime
RechnungLeistung
- Artikel: String- Betrag: int
+Rechnungen *
+Vertrag 1+Besuch 1
+Leistungen *
+Besuche
*
Besuch
+Kunde 1
+Vertrag
1
Vertragsabschluss
+Kunde
1..*
uc Kundenverwaltung Fitnesscenter
Kunde
Kundenbetreuer
anmelden
50 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
UML Sequenzdiagramm
sd Anmelden
Kundenbetreuer
FitnessCenter::Kunde
Fitness Center::Vertrag
Fitness Center::Rechnung
legeKundenAn
gibKundendatenAn
legeVertragAn
gibVertragsdetailsAn
schliesseVertragAb
druckeVertrag
erstelleRechnung
Wer nimmt an der
Interaktion teil?
Aktoren und Objekte
Die vertikale Achse
gibt den zeitlichen
Ablauf an
Nachricht an/ Methodenaufruf auf
anderem Objekt
•Name stellt
Aufforderung dar
•Kann (instantiierte)
Parameter enthalten
•Synchrone Nachricht:
durchgezogener Pfeil,
asynchrone Nachricht:
gestrichelter Pfeil
Objekterzeugung:
Nachricht mit new
Klassenname direkt auf
das Objekt
Antwort auf NachrichtenKönnen als gestrichelte
Pfeile zurück dargestellt
werden (optional)
Lebenslinie
stellt die Existenz
eines Objektes dar
Aktivierung
zeigt die Dauer eines
Methodenaufrufs an
Übersicht
Abstraktion
Datenmodell-Elemente
Regeln zur Datenmodellierung
Struktur und Verhalten
Kontrollfragen� Kontrollfragen
Agenda
52 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Kontrollfragen
� Erklären Sie Modellierung als Abstraktion von der Realität
� Für wen ist das Datenmodell gedacht?
� Was sind Entitäten? Nennen Sie Beispiele
� Was sind Attribute? Nennen Sie Beispiele
� Welche Beziehungen zwischen Entitäten existieren?
� Was sind Datentypen? Nennen Sie Beispiele
� Welche UML-Notation wird für Datenmodelle verwendet?
� Wie kann Struktur und Verhalten zusammengebracht werden?
� Welche UML-Notation kann dafür verwendet werden?