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

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

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

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

Abstraktion

Kontrollfragen

� Abstraktion

Agenda

Von der Realität zum Modell

Realität:Realität:

Quelle: www.musoft.org

Rechte Tür

Linke Tür

Objekte

Rechte Tür

Karussell 1Karussell 1

ermöglichtZugang zu

Lagerfeld 1

Lagerfeld 2

Lagerfeld 3

Objekte +

Beziehungen

Objekte +

Beziehungen +

Eigenschaften

Karussell 1

Lagerfeld 1

zulässigesGewicht = 700

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.

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.

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.

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

Abstraktion: Was interessiert ?

Quelle: Roger King

Übersicht

Abstraktion

Kontrollfragen

� Datenmodell-Elemente

Agenda

Beispiel: Fitness Center

Beispiel

cd Kundenverwaltung Fitnesscenter

Buchhaltung

KundenverwaltungDienstleistung

- 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

Vertragsabschluss

+Kunde

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, ..

cd Kundenverwaltung ...

- Adresse: String- Kontonummer: int- Mitgliedsnummer: int- Name: String

Attribute Datentypen

Beziehungen zwischen Entitäten: Assoziationen

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

schließt ab >

+Kunde

Kardinalität

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

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

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 ...

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

Übersicht in Datenmodellen:Wo ist der Prozess „Instandhaltung“ abgebildet?

TfzDomRzwDom

BauartVarDom BaureiheSerieDom DatenblRzwDom

UebergangTfzTyp

DatenblTfzDom

LeistungTyp

IhFabrikDom

AuswRzwWerkAufDom AuswIhHistZuFzDom

AuswRzwFuerVorausAusgangDom AuswRzwFuerWerkEingangDom

AuswGeplaIhZuRzwDom

AuswahlFabrikDom

IhTerminBatch FzLwTagesdurchschnittBatch

BatchProcess

FzAusPosDom

0..* 1

BerEinheitDom

BerechtigungFuerBerEinhDom 0..* 1

BerechtigungFabrikDom

FzZusatzDom

0..* 0..*

MerkmalSpecDom

1 0..*

KomponenteFabrikDom

0..* 0..*

BerechtigungDom

BenutzerFabrikDom0..*

KompVarDom

MerkmalDom

0..* 0..*

KomponenteDom

1 0..*

AusgefuehrteArbeitFabrikDom (Stufe A)

0..* BstAufgabeDom

OrgaFabrikDom0..*

fremdeBst

HeimatBst

BenutzerDom

0..* 0..*

1 0..*

10..* StdAusPosDom

1 AbmessungTyp

1 AnschriftenTyp

1 GepaeckTyp

1WagenPlaetzeTyp

WagenBettenTyp

1 WagenSonstTyp

1VorratTyp

ZusatzEinrTyp

1BetriebTyp

1BremseTyp

UebergangTyp

1 StammdatenTyp

fzHeimatPlan

fzHeimatHist

fzHeimatIst

1 FzHeimatTyp

FzAustattungDom

AusgefuehrteArbeitDom (Stufe A)

FzFabrikDom

ihStufe

ausgefSoArb

ausgefIhSt

ihStufe

SchlVerzFabrikDom DartEntity

BatchExport BatchImport

TapExport FzLwImport

DartEntity ist Superklasse fuer alle Klassen

StdAusstattungDom

DatenblattTyp 1

BaBrDom0..1

0..1von

0..1 0..1bis

GeplaIhAnzDom

1 0..*

IhTpDom

ausgefArbeiten

AusgefArbeitDom

0..* 1

zufGrund

0..1 0..*

0..*1IhSchrittDom

1 0..*

BahnstelleDom0..*

FahrzeugDom

ihStufe

geplaIhStufeZuletzt

SchlVerzEintragDom

WerkAufDom

0..* 1

0..1 0..*

GeplaIhDom0..*1

NkIhVorDom

GeplaUntAnzDom

GeplaFstAnzDom

IhPlanDom

1 0..*

0..1 BaBrVarDom

1 11 1

IhFabrikDom

NkIhPlanDom

0..*BrDom

BaBrFabrikDom

0..*0..*

Paket-Diagramme

Komponenten

� Gruppieren fachlich zusammenhängende Entitäten

� Dienen der Übersicht

� Können später getrennt implementiert werden

� UML-Notation: UML componentsoder Pakete

Buchhaltung

Vertrag

Besuch

RechnungLeistung

+Rechnungen *

+Vertrag 1+Besuch 1

+Leistungen *

+Besuche

Besuch

+Kunde 1

+Vertrag

Vertragsabschluss

+Kunde

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

Vertrag

Besuch

RechnungLeistung

+Rechnungen *

+Vertrag 1+Besuch 1

+Leistungen *

+Besuche

Besuch

+Kunde1

+Vertrag

schließt ab >

+Kunde

Übersicht

Abstraktion

Kontrollfragen

� Regeln zur Datenmodellierung

Agenda

Gestaltungsziele für Datenmodelle

Korrektheit

Redundanzfreiheit

Einfachheit

Erweiterbarkeit

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

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.

Bessere Lösung: Mit Assoziation (bzw. Komposition)

class Person mit Assoziation

Person

- adresse: String- name: String

- 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.

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

Aufgabe 2

� 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

Erster Lösungsansatz: denormalisiert

class Lied denormalisiert

- 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 = 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.

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

class Lied normalisiert

- titel: String

Interpret

- name: String1..*

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

Aufgabe 3

� Kunden können Bestellungen für Waren aufgeben

� Mehrere Bestellungen zusammen bilden einen Auftrag

� Ein Auftrag bezieht sich immer auf einen Kunden

Erster Lösungsansatz:Zyklische Assoziationen

class Bestellung mit Zykel

Person

BestellungAuftrag

gibt auf

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

Bessere Lösung:Azyklische Assoziationen

class Bestellung ohne Zykel

Person

BestellungAuftrag

object Bestellung ohne Zykel

Buch :BestellungDezember :Auftrag

Müller :Kunde

Über den Auftrag ist der Kunde eindeutig bestimmt, der die Bestellung aufgegeben hat.

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

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

Erster Lösungsansatz:m:n-Beziehungen

class CRM mit m:n Beziehungen

Person

Reiseauftrag Beschwerdev organg Kampagne

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.

Bessere Lösung: m:n-Beziehungen aufgelöst

object CRM mit Entität Kontakt

Person

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}

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.

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

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.

Ü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

Kontrollfragen

� Struktur und Verhalten

Agenda

Sequenzdiagramme: Struktur und Verhalten zusammenbringen

Anwendungs-fall-

Diagramm

Sequenz-Diagramm

Klassen-diagramm

Sequenz-Diagramme

Beispiel Fitness Center:Anwendungsfall + Datenmodell �� …

Buchhaltung

Vertrag

Besuch

RechnungLeistung

+Rechnungen *

+Vertrag 1+Besuch 1

+Leistungen *

+Besuche

Besuch

+Kunde 1

+Vertrag

Vertragsabschluss

+Kunde

uc Kundenverwaltung Fitnesscenter

Kundenbetreuer

anmelden

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

Kontrollfragen� Kontrollfragen

Agenda

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

4. Analyse-Phase: Datenmodell Softwaretechnik (CNAM) · Übersicht Abstraktion Datenmodell-Elemente...

Documents

Transcript of 4. Analyse-Phase: Datenmodell Softwaretechnik (CNAM) · Übersicht Abstraktion Datenmodell-Elemente...

Hanover-Messe 2004 IEC 61850IEC 61850...Datenmodell (Attribute der Daten) 7-3 fertig Dienstmodell, generelles Datenmodell 7-4 fertig Abbildung auf ein Protokoll Kommunikation in Schaltanlagen

BAC CNAM +5 Innovation

SAP Mobile Platform - uni- · PDF fileSeite 2bpc 18.04.2013 Agenda Einleitung Ausgangssituation SAP Mobile Platform Architektur Einheitliches Datenmodell – Mobile Business

Diplomarbeit „Dokumentation eines Planungsprogrammes im ...€¦ · Autodesk Revit • In einem zentralen Datenmodell • Direkte Änderungssynchronisation – „Echtzeitbearbeitung“

Datenmodellrückführung Ölpumpe MB M199 Informationen zur Fertigung Wanddicke im Datenmodell 21.09.2012 © Stephan Hostert, FEMET GmbH Seite 1 von 10.

Datenmodell für ein kommunales Freizeit- und Infrastrukturkataster¶ffentlichungen... · 2013. 6. 3. · Datenmodell für ein kommunales Freizeit- und Infrastrukturkataster Geoinformatik

XML-Datenmodellierung und Web-Services XML Datenmodell Schemabeschreibungssprachen Anfragesprachen: XPath und XQuery Web-Services Überblick WSDL UDDI SOAP.

SBK Datenmodell Datenstrukturen Modell 2020...SBK Datenmodell Datenstrukturen Modell 2020 Ausgangslage Nicht klassifiziert 3/27 1. Ausgangslage 1.1 Einleitung Die Datenbank SBK dient

XML-Algebren Martin Winkler. Gliederung Motivation: Warum Algebren? Die Natix-Algebra, NAL - Datenmodell - Funktionsprinzip - Beispiel Tree Algebra for.

GEWIS-BE – ein Gewässerinformationssystem für den …€¦ · 3] wurde ein weitgehend generisches Datenmodell entwickelt, ... sungen werden standardmässig auf das geroutete Gewässernetz

Interoperable Informationssysteme - 1 Klemens Böhm Datenmodell 2: XML ('Extended Markup Language)

Datenlexikon und Mini-Spezifikation Gliederung: Datenlexikon 1 Notation und Operatoren 2 Datenbeschreibung für das River Datenmodell 3 Essentielle Aktivität.

KarczewskiDatenbanken I1 2. Semantische Datenmodellierung Datenmodell: System von Konzepten zur Beschreibung relevanter Daten Datenbankmodell: System von.

FAIRE DES CHOSES AVEC LA PHILOSOPHIE - Cnam …lirsa.cnam.fr/medias/fichier/fairedeschosesaveclaphilo...Stefania CONTESINI, après un Master sur les Politiques du travail, s'est intéressée

Semantisches Datenmodell für flächenbezogene Daten Von Solveig Velte Hauptseminar: Nichtrelationale Datenbanken Prof. Dr. Thaller.

Garagen-Sectionaltore Baureihe 30€¦ · Übersicht LTE 6 Übersicht LPU 7 Übersicht LTH 8 Übersicht Beschlagsarten 9 Übersicht Torsionsfederwellen 10 Bestimmung von Torsionsfedern

Datenmodell zur Planung von Stellwerkenrcsumaschek/datenmodell/U_Maschek-Datenmod... · Datenmodell zur Planung von Stellwerken 1 Vorwort Mit dem Einzug der EDV in den Büroalltag

Geodatabase Enrico Kurtenbach. Modellierung der Wirklichkeit Realität Logisches Datenmodell Grundstück Gebäude Eigentümer.

XML-Datenmodellierung und Web-Services · XML-Datenmodellierung und Web-Services XML Datenmodell Schemabeschreibungssprachen Anfragesprachen: XPath und XQuery Web-Services Überblick

1. Einführung Softwaretechnik (CNAM) · Zusatz-ZI daten (Amadeus) Buch.-daten gebuchte TX Zusatz-infos / daten Dialog Dialog KI / VU / Data in - Anlief. (ohne VISA) Debitoren- und