4. Analyse-Phase: Datenmodell Softwaretechnik (CNAM) · Übersicht Abstraktion Datenmodell-Elemente...
Transcript of 4. Analyse-Phase: Datenmodell Softwaretechnik (CNAM) · Übersicht Abstraktion Datenmodell-Elemente...
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
4. Analyse-Phase: Datenmodell
5. Analyse-Phase: Dialoge
6. Design-Phase: Architektur-Grundlagen
7. Design-Phase: Referenzarchitektur betriebliche Informationssysteme
8. Design-Phase: Querschnittsthemen und Muster
9. Programmierungs-Phase
10.Test- / Integrationsphase, Einführung , Qualitätsmanagement
11.Projektmanagement
Übersicht
Abstraktion
Datenmodell-Elemente
Regeln zur Datenmodellierung
Struktur und Verhalten
Kontrollfragen
� Übersicht
Agenda
Agenda
4 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Bausteine zum Verhalten: Struktur
FachlicheGestaltung
Interaktion
VerhaltenGeschäftsprozesse
Struktur
Anforderungen Zentrale Ziele und Rahmenbedingungen
Logisches Datenmodell & Datentypverzeichnis
Funktionale Anforderungen
Glossar
Betriebsanforderungen
Projektanforderungen
Migrationsanforderungen
EinführungsanforderungenNichtfunktionale Anforderungen
Querschnittskonzepte und Dienste
Fachlicher Überblick
Domänen & Komponenten
Dialog-Gestaltungsvorgabe
Dialoge Nachbarsystem-Schnittstellen
BatchverarbeitungDruckausgaben
Anwendungsfälle
Anwendungsfunktionen
Quelle: sd&m Research
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
Vom konkreten zum allgemeinen Modell
Klassen +
Beziehungen +
Eigenschaften
Lagerfeld 1Lagerfeld 1
zulässigesGewicht = 700zulässigesGewicht = 700
Lagerfeld 1 hat ein zulässiges
Gewicht von 700 kg.
LagerfeldLagerfeld
zulässigesGewicht : DezimalzulässigesGewicht : Dezimal
Lagerfelder haben ein
zulässiges Gewicht, das
durch eine Dezimal-
zahl angegeben wird.
Quelle: www.musoft.org
14 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Modellierung ist Abstraktion von der Realität in mehreren Schritten
Realität:
Konkrete Modelle:Objektdiagramme
Allgemeines Modell:Klassendiagramm
Karussell
Lagerfeld
zulässigesGewicht : Dezimal
Karussell 1
Lagerfeld 1zulässigesGewicht = 700
Quelle: www.musoft.org
15 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Abstraktion: Was interessiert ?
Quelle: Roger King
Übersicht
Abstraktion
Datenmodell-Elemente
Regeln zur Datenmodellierung
Struktur und Verhalten
Kontrollfragen
� Datenmodell-Elemente
Agenda
17 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Beispiel: Fitness Center
Beispiel
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..*
18 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Entitäten
Merkmale: Jede Entität ist:
� autonom: Für sich alleine lebensfähig(Gegenbeispiel: Saldo eines Kontos).
� unverzichtbar: Wenn ich ihn weglasse, kann ich bestimmte Abläufe nicht mehr darstellen.
� Man kann ihn anlegen und löschen.
� Man kann ihn zählen.
� Man kann und will ihn durch Attribute beschreiben.
� Eindeutig identifizierbar
� UML-Notation: Klasse
Der Name von Entitätstypen ist immer ein Singular („Kunde“, „Konto“)
Man kann sich hinter jedem Entitätstyp die Menge der Entitäten vorstellen:
Kunde: Maier, Huber, ..
Datenmodell-Elemente
cd Kundenverwaltung ...
Kunde
- Adresse: String- Kontonummer: int- Mitgliedsnummer: int- Name: String
Name
Attribute Datentypen
19 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Beziehungen zwischen Entitäten: Assoziationen
Datenmodell-Elemente
Name und Leserichtung
� Beziehung zwischen Entitäts-Objekten
� Kann benannt sein
� die Leserichtung kann durch einen Pfeil angegeben werden
� Die Rollen der beteiligten Entitäten können benannt sein
� Kardinalitäten:
– „1“ : genau ein
– „0..1“ : höchstens ein (optional)
– „1..*“ : mehrere
– „*“ bzw. „0..*“ : mehrere (optional)
– „2..4“ : zwei oder drei oder vier
– „3, 4“ : drei oder vier
class Assoziation
KundeVertrag+Vertrag
0..*
schließt ab >
+Kunde
1
Rolle
Kardinalität
20 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Beziehungen zwischen Entitäten: Komposition, Aggregation
� Aggregation:
– Spezielle Assoziation
– Drückt Teile / Ganzes – Beziehung aus
– Lies: „besteht aus“
– Kardinalität auf der Ganzes-Seite(Diamant) ist immer 1
� Komposition:
– Strengere Form der Aggregation
– Teile sind physisch im ganzen enthalten
– Löschung des Ganzen führt zur Löschung aller Teile (Cascading delete)
– Bei Löschung aller Teile wird auch Ganzes gelöscht
� Empfehlung: nur Assoziationen und, falls angemessen, Kompositionen verwenden
class Aggregation
Firma Mitarbeiter
class Komposition
Mensch Körperteil
21 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Beziehungen zwischen Entitäten:Generalisierung / Spezialisierung
� Beziehung zwischen Entitätsklassen
� Lies „ist ein“, z.B. „jede juristische Person ist eine Person“
� Die generelle Klasse vererbt Eigenschaft die speziellen Klassen:
– Attribute
– Assoziationen
– Methoden
� Setze Generalisierung / Spezialisierung sparsam ein! Besonders: verwende Generalisierung / Spezialisierung nie, wenn keine „ist ein“-Beziehungvorliegt!
class Generalisierung / Spezialisierung
Person
- adresse: string- name: string
NatürlichePerson
- geburtsdatum: date
JuristischePerson
- handelsregisterNr: int
22 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Attribute
� Beschreiben die Eigenschaften von Entitäten, zum Beispiel Adresse eines Kunden
� Haben einen Datentyp, zum Beispiel int
� Sind alleine nicht lebensfähig, zum Beispiel macht der Betrag von EUR 42 ohne den Kontext der Überweisung keinen Sinn
cd Kundenverwaltung ...
Kunde
- Adresse: String- Kontonummer: int- Mitgliedsnummer: int- Name: String
23 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Fachliche Datentypen
� Ein Datentyp definiert die Struktur von (ggf. mehreren) Attributen.
� Ein Datentyp kann einfach sein...
– String, Integer
� eine Einschränkung einfacher Datentypen
– positive Ganzzahlen, Strings wie z.B. IP-Adresse, ISBN
� eine Struktur (= zusammengesetzter DT)
– Datum, Adresse
� eine Enumeration
– Wochentag
� Allgemein: eine Menge von zulässigen Werten
� Datentypobjekte ändern ihren Wert nicht (immutable)
� Im Datenmodell stellen wir fachliche Datentypen nicht als UML-Klassen mit Assoziationen zu den Entitäten dar, um den Überblick nicht zu verlieren
Datenmodell-Elemente
24 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
hier:
Übersicht in Datenmodellen:Wo ist der Prozess „Instandhaltung“ abgebildet?
TfzDomRzwDom
BauartVarDom BaureiheSerieDom DatenblRzwDom
UebergangTfzTyp
1
DatenblTfzDom
1
LeistungTyp
1
1
IhFabrikDom
IhFabrikDom
AuswRzwWerkAufDom AuswIhHistZuFzDom
AuswRzwFuerVorausAusgangDom AuswRzwFuerWerkEingangDom
AuswGeplaIhZuRzwDom
AuswahlFabrikDom
IhTerminBatch FzLwTagesdurchschnittBatch
BatchProcess
FzAusPosDom
0..* 1
1
1..*
BerEinheitDom
10..*
1
0..*
BerechtigungFuerBerEinhDom 0..* 1
1
BerechtigungFabrikDom
1
1..*
0..*
0..*
FzZusatzDom
0..* 0..*
1
0..*
0..*
MerkmalSpecDom
1 0..*
1
KomponenteFabrikDom
10..*
0..*
0..* 0..*
BerechtigungDom
1
0..*
10..*
1
BenutzerFabrikDom0..*
0..*
1
KompVarDom
0..*
0..*
MerkmalDom
0..*
0..* 0..*
1
0..1
1
KomponenteDom
0..*
0..*
1 0..*
1
0..*
1
AusgefuehrteArbeitFabrikDom (Stufe A)
0..*
0..*
0..* BstAufgabeDom
0..*
1
OrgaFabrikDom0..*
fremdeBst
0..*
0..*
HeimatBst
0..*
BenutzerDom
0..* 0..*
1
0..*
1
1 0..*
10..* StdAusPosDom
0..*
1
0..*
0..*
0..1
1
1
1 AbmessungTyp
1
1 AnschriftenTyp
1
1 GepaeckTyp
1
1WagenPlaetzeTyp
11
WagenBettenTyp
1 WagenSonstTyp
1
1VorratTyp
1
1
ZusatzEinrTyp
1
1BetriebTyp
1
1BremseTyp
1
1
UebergangTyp
1
1 StammdatenTyp
fzHeimatPlan
1
1
fzHeimatHist
1
1
1
fzHeimatIst
1 FzHeimatTyp
1
1
FzAustattungDom
1
1
1
AusgefuehrteArbeitDom (Stufe A)
1
0..*
1
1
FzFabrikDom
0..*
0..1
0..1
0..1
NkDom
0..1
ihStufe
0..*
1
ausgefSoArb
0..*
0..*
ausgefIhSt
0..*
1
ihStufe
0..*
1
SchlVerzFabrikDom DartEntity
BatchExport BatchImport
TapExport FzLwImport
DartEntity ist Superklasse fuer alle Klassen
1 1
StdAusstattungDom
10..*
1 1
DatenblattTyp 1
1
1
1
1
1
1
1
11
1
1
1
1
1
1
1
1
1
1
1
1
1
0..*
1
1
BaBrDom0..1
0..1von
0..1 0..1bis
1..*
0..*
GeplaIhAnzDom
1
1 0..*
IhTpDom
ausgefArbeiten
1
0..*
AusgefArbeitDom
0..* 1
0..*
1
zufGrund
0..1 0..*
0..*1IhSchrittDom
1 0..*
0..*
1
BahnstelleDom0..*
0..*
0..*
1
0..*
0..*
0..*
0..*
1
0..*
1
FahrzeugDom
1
1
1
1
1
1
1
1
1
1
1
1
10..*
ihStufe
1
0..*
0..*
geplaIhStufeZuletzt
0..1
SchlVerzEintragDom
0..*
1
0..*
0..*
0..*
10..*
1
1
0..*
1
0..*
WerkAufDom
1
0..*
0..* 1
0..*
1
0..1 0..*
10..*
GeplaIhDom0..*1
0..*
1
0..*
1
1
0..*
0..*
0..1
1
0..*
NkIhVorDom
1
0..*
GeplaUntAnzDom
1
0..*
GeplaFstAnzDom
1
IhPlanDom
1 0..*
0..*
0..1
0..1 BaBrVarDom
1 11 1
0..*
1
1
1..*
0..*
1
1
IhFabrikDom
1
0..*
1
0..*
10..*
1
0..*
1
0..*
1
0..*
0..*
NkIhPlanDom
1
0..*
0..1
0..1
1
0..*
1
0..*BrDom
1
BaBrFabrikDom
1
0..*0..*
BaDom
1
0..*
##
Paket-Diagramme
25 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Komponenten
� Gruppieren fachlich zusammenhängende Entitäten
� Dienen der Übersicht
� Können später getrennt implementiert werden
� UML-Notation: UML componentsoder Pakete
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..*
26 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 28.10.2008
Finden von KomponentenIdee: Partitionierung des Datenmodells
� Idee: Entitätstypen zusammenstellen, die
– fachlich zusammenpassen
– Häufig gemeinsam verwendet werden
� Hilfsmittel
– Anwendungsfälle
– Dialoge
prüfen
� Ziel: möglichst wenig und selten verwendete Verbindungen zwischen Komponenten
Komponenten
class Fitnesscenter ohne Komponenten
Kunde
- Adresse: String- Kontonummer: int- Mitgliedsnummer: int- Name: String
Vertrag
- Datum: int- Laufzeit:
Besuch
- ende: DateTime- start: DateTime
RechnungLeistung
- Artikel: String- Betrag: int
+Rechnungen *
+Vertrag 1+Besuch 1
+Leistungen *
+Besuche
*
Besuch
+Kunde1
+Vertrag
0..*
schließt ab >
+Kunde
1
Übersicht
Abstraktion
Datenmodell-Elemente
Regeln zur Datenmodellierung
Struktur und Verhalten
Kontrollfragen
� Regeln zur Datenmodellierung
Agenda
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)
class Person mit Assoziation
Person
- adresse: String- name: String
Rolle
- typ: enum{Kunde, Lieferant, Mitarbeiter:Arbeiter, Mitarbeiter:Manager}*
object Person mit Assoziation
Huber :PersonKunde :Rolle
Lieferant :Rolle
Schmidt :Person Mitarbeiter:Arbeiter -> Manager :Rolle
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
Bessere Lösung: m:n-Beziehungen aufgelöst
object CRM mit Entität Kontakt
Person
Kunde
Kontakt
- datum: Date- typ: enum{Reise, Beschwerde, Kampagne}- rol le: enum {Reiseanmelder, Reiseteilnehmer, ...}
Reiseauftrag Beschwerdevorgang Kampagne
{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?
Kontrollfragen