Einführung und Überblick LE 1 V Unternehmensmodellierung ... · II SW-Management 8 LE 6 Kontrolle...

I SWT - Die Definitionsphase - OOA

LE 131

Software-Technik

2 Die DefinitionsphaseObjektorientierte Analyse[leicht gekürzt]

Prof. Dr. Helmut BalzertLehrstuhl für Software-TechnikRuhr-Universität Bochum

© Helmut Balzert 2001


LE 132

Einf ührung und Überbl ickLE 1

V Unternehm ensmodell ierung

2 LE

1 Grundlagen

LE 24

2 ObjektorientierteUnternehmensmodellierung

LE 25

I SW-Ent wick lung

33 LE

6 Die Wartungs- & Pflegephase

LE 34

5 Die Abnahme- undEinführungsphase

LE 34

4 Die Implementierungsphase

LE 33

3 Die Entwurfsphase

LE 23 – 32

2 Die Definitionsphase

LE 4 – 22

1 Die Planungsphase

LE 2 – 3

III SW-Qual i täts-managem ent

11 LE

6 Produktqualität– Systeme

LE 18 – 19

5 Produktqualität– Komponenten

LE 14 – 17

4 Prozeßqualität

LE 12 – 13

3 ManuellePrüfmethoden

LE 11

2 Qualitäts-sicherung

LE 10

1 Grundlagen

LE 9

II SW-Management

8 LE

6 Kontrolle

LE 8

5 Leitung

LE 6 – 7

4 Personal

LE 5

3 Organisation

LE 3 – 4

2 Planung

LE 2

1 Grundlagen

LE 1

IV Querschni tt e und Ausbl ick e

4 LE

4 Sanierung

LE 23

1 Pr inzipien& Methoden

LE 20

3 Wieder-verwendung

LE 22

2

LE 21


LE 133

Inhalt2.18 Objektorientierte Analyse

2.18.1 Zur Historie2.18.2 OOA-Muster2.18.3 Methodische Vorgehensweise mit Checklisten


LE 134

2.18 Objektorientierte AnalyseZur Historie

Peter Coad*30.12.1953 in San FranciscoErzielte 1990 mit seinem Buch »Object-Oriented Analysis« (zusammen mit E. Yourdon) den Durchbruch in OOA(Integration des ER-Modells und des Zustandsautomaten in die Grundkonzepte der Objektorientierung) Wegbereiter von OOA-Mustern (patterns) (1995).


LE 135

2.18 Objektorientierte AnalyseZur Historie

Dr. James Rumbaugh*22.8.1947 in Bethlehem, PA, USAFellow, Rational Software CorporationChefentwickler der OMT-Methode (Object Modeling Technique), die heute zu den führenden objektorientierten Entwicklungsmethoden zählt.


LE 136

2.18.1 Zur HistorieUrsprünge Von Zeitdiagrammen:

Sequenz-Diagramm

Von OOP: Objekt Klasse At tribut

Operat ion Vererbung Botschaft

Vom ER-Modell: Assoziationen mit Kardinal itäten (At tribut ) (Ent itätstypen)

Von semantischerDatenmodellierung: Aggregat ion (General isierungstyp/ Spezial isierungstyp)

Vom Zustandsautomat: Mealy-Automat Moore-Automat Harel-Automat

Von Geschäftsprozessen:use case


LE 137

2.18.1 Zur HistorieStatisches und dynamisches Modell

Assoziat ion

StatischeKonzepte

Vererbung Paket

Geschäftsprozess

DynamischeKonzepte

BotschaftZustands-automat

Szenar io

Attribut

Basiskonzepte

Objekt Klasse

Operat ion

StatischesMod ell

DynamischesModell


LE 138

2.18.2 OOA-MusterMuster 1: Liste

Numm er

Lager li st e

4

okStörungsstatus

X Y Belegt Sperrkenn- Regal -Koord inate Koord inate Stat us zeichen sei t e 50 100 Frei k ein A 50 200 Belegt k ein A 50 300 Frei k ein A

Notiz

Lagerm odul

Num m erSt örungsstatus

Lag er pl at z

X Koord inat eY Koord inat eBelegt StatusSperrkennzeichenRegalseit e

1

1..*

List e


LE 139

2.18.2 OOA-MusterMuster 1: Liste

Es liegt eine Komposition vorEin Ganzes besteht aus gleichartigen Teilen, d.h. es gibt nur eine Teil-KlasseTeil-Objekte bleiben einem Aggregat-Objekt fest zugeordnet

Sie können jedoch gelöscht werden, bevor das Ganze gelöscht wird

Die Attributwerte des Aggregat-Objekts gelten auch für die zugehörigen Teil-ObjekteDas Aggregat-Objekt enthält mindestens ein Teil-Objekt, d.h. die Kardinalität ist meist 1..*.


LE 1310

2.18.2 OOA-MusterMuster 2: Exemplartyp

Sem inartyp

TitelZielsetzungMethodikInhalt

Veranstaltung

NummerDauerVonBis

1

*


LE 1311

2.18.2 OOA-MusterMuster 2: Exemplartyp

Einfache AssoziationEinmal erstellte Objektverbindungen werden i. Allg. nicht verändert

Sie werden nur gelöscht, wenn das betreffende Exemplar entfernt wird

Der Name der neuen Klasse enthält oft Begriffe wie Typ, Gruppe, Beschreibung, SpezifikationEine Beschreibung kann – zeitweise – unabhängig von konkreten Exemplaren existieren

Daher ist die Kardinalität i. Allg. many (0..m)Würde auf die neue Klasse verzichtet, so würde als Nachteil lediglich die redundante »Speicherung«von Attributwerten auftreten.


LE 1312

2.18.2 OOA-MusterMuster 3: Baugruppe

Es handelt sich um physische ObjekteEs liegt eine Komposition vor Objektverbindungen be-stehen über eine längere Zeit

Ein Teil-Objekt kann von seinem Aggregat-Objekt getrennt werden und einem anderen Ganzen zugeordnet werden

Ein Ganzes kann aus unterschiedlichen Teilen bestehen.

Auto

Motor Rad

1

1

1

4


LE 1313

2.18.2 OOA-MusterMuster 4: Stückliste

:Grafik :Rechteck :Tex t

:Rechteck :Linie :Rechteck

:Graf ik

Linie

StartelementZielelement

*

Stückliste

Rechteck

LängeBrei te

Text

Schriftart

Graf ik

VersionsnummerFreigabe

Graf ikelement

Posit ionFarbeGrößeerstellt am

0..1

:Komponente

:Komponente :Komponente

:Komponente :Komponente

Komponente

TitelInhalt 0..1

*


LE 1314

2.18.2 OOA-MusterMuster 4: Stückliste

Es liegt eine Komposition vorDas Aggregat-Objekt und seine Teil-Objekte müssen sowohl als Einheit als auch einzeln behandelt werden können Teil-Objekte können anderen Aggregat-Objekten zugeordnet werdenDie Kardinalität bei der Aggregat-Klasse ist 0..1 Ein Objekt der Art A kann sich aus mehreren Objekten der Arten A, B und C zusammensetzenDer Sonderfall der Stückliste ist, dass ein Stück nicht aus Objekten unterschiedlicher Art, sondern nur aus einer einzigen Art besteht.


LE 1315

2.18.2 OOA-Muster

Muster 5: Koordinator

Verk äufer

Kunde Produkt11

1

Verkauf

DatumPreisnachlass

Ver käufer

Kunde Produkt11

1

Ver k auf

DatumPreisnachlass

Koordinator

Koordinator-Klasse


LE 1316

2.18.2 OOA-Muster

Muster 5: KoordinatorEs liegen einfache Assoziationen vorDie Koordinator-Klasse ersetzt eine n-äre (n >= 2) Assoziation durch binäre Assoziationen mit assoziativer KlasseDie Koordinator-Klasse besitzt kaum Attribute/Operationen, sondern mehrere Assoziationen zu anderen Klassen, i. Allg. zu genau einem Objekt jeder Klasse.


LE 1317

2.18.2 OOA-Muster

Muster 6: Rollen

:Dozent

Nam e = Herbst

:Veranstaltung

Num mer = 4632

:Veranstaltung

Num mer = 4712

1..*Veranstaltung

Numm erDauerVonBis

Rollen

Dozent

Num merNam eAdresse

Seminar-leiter*

Referent

1*

Teilnehmer

* *

{subset}

{Teilnehmer ≠ Referent }


LE 1318

2.18.2 OOA-Muster

Muster 6: RollenZwischen 2 Klassen existieren 2 oder mehrere einfache AssoziationenEin Objekt kann – zu einem Zeitpunkt – in Bezug auf die Objekte der anderen Klasse verschiedene Rollen spielen Objekte, die verschiedene Rollen spielen können, besitzen unabhängig von der jeweiligen Rolle die gleichen Eigenschaften und ggf. gleiche Operationen.


LE 1319

2.18.2 OOA-Muster

Muster 7: Wechselnde Rollen:Adressat

Zeit raum =(1.1 .0 0,30.6.00)

: In teressen t

Zeit raum =(1.7 .0 0,7 .10 .00)

:Teilnehm er

Zeit raum =(8 .10.00)

:Kunde

Wechseln deRollen

1

*

Ku nde

Nam eAdresse

Kun denr ol le

Zeit rau mPr ioritätskategorie

abst rakteRolle

kon kreteRolle

Tei lne hmer

Erste Bu ch un g amLetz te Buchung amAn zahl Buch ungenUm satz

Inter essent

Kataloganford erun g am

Adr ess at

Herkun ft der AdresseVersand am


LE 1320

2.18.2 OOA-Muster

Muster 7: Wechselnde RollenEin Objekt der realen Welt kann zu verschiedenen Zeiten verschiedene Rollen spielen

In jeder Rolle kann es unterschiedliche Eigenschaften (Attribute, Assoziationen) und Operationen besitzen

Die unterschiedlichen Rollen werden mittels Vererbung modelliertObjektverbindungen zwischen dem Objekt und seinen Rollen werden nur erweitert, d.h. weder gelöscht noch zu anderen Objekten aufgebaut.


LE 1321

2.18.2 OOA-MusterMuster 8: Historie

:Buchexemplar

Inventarnr = 9712Zeit raum =(25.12.00)

:Buchexemplar

Inventarnr = 1387Zeit raum =(13.3.0 0, 16.3.00)

:Buchexemplar

Inventarnr = 1222Zeit raum =(12.1.0 0, 31.1.00)

:Kunde

1 1..*

Buchexemplar

InventarnrTitelZeit raum

Kunde

NameAdresse


LE 1322

2.18.2 OOA-MusterMuster 8: Historie

Es liegt eine einfache Assoziation vorFür ein Objekt sind mehrere Vorgänge bzw. Fakten zu dokumentieren Für jeden Vorgang bzw. jedes Faktum ist der Zeitraum festzuhalten Aufgebaute Objektverbindungen zu den Vorgängen bzw. Fakten werden nur erweitertDie zeitliche Restriktion {t#k} (k = gültige Kardinalität) sagt aus, was zu einem Zeitpunkt gelten muss, wobei # für die Vergleichsoperationen =, <, >, <=, >= und ≠ steht.


LE 1323

2.18.2 OOA-MusterMuster 9: Gruppe

0..1*

Mitarbeiter

NameAdresseSpezialgebiet

Projek tteam

KürzelBezeichnungZeitraum


LE 1324

2.18.2 OOA-MusterMuster 9: Gruppe

Es liegt eine einfache Assoziation vorMehrere Einzel-Objekte gehören – zu einem Zeitpunkt – zum selben Gruppen-Objekt Es ist jeweils zu prüfen, ob die Gruppe – zeitweise – ohne Einzel-Objekte existieren kann oder ob sie immer eine Mindestanzahl von Einzel-Objekten enthalten muss Objektverbindungen können auf- und abgebaut werden.


LE 1325

2.18.2 OOA-MusterMuster 10: Gruppenhistorie

{t=0..2}*

Mit arbeiter

NameAdresseSpezialgebiet

Pr ojek tteam

KürzelBezeichnungZeitraum

Zugehör igkeit

ZeitraumEndegrund

*


LE 1326

2.18.2 OOA-MusterMuster 10: Gruppenhistorie

Ein Einzel-Objekt gehört – im Laufe der Zeit – zu unterschiedlichen Gruppen-Objekten Die Historie wird mittels einer assoziativen Klasse modelliert

Dadurch ist die Zuordnung zwischen Einzel-Objekten und Gruppen deutlich sichtbar

Die zeitliche Restriktion {t=k} (k = gültige Kardinalität) sagt aus, was zu einem Zeitpunkt gelten mussDa Informationen über einen Zeitraum festzuhalten sind, bleiben erstellte Objektverbindungen bestehen und es werden nur Verbindungen hinzugefügt.


LE 1327

2.18.3 Methodische VorgehensweiseZur Modellbildung

Geschäf tsprozesseerstellen

statischesModel lerstellen

dynamischesModellerstel len

OOA-Modell i

i = 1

i = Anzahl der Iterat ionen

1. I terat ion

OOA-Model l 1

2. I terat ion

OOA-Model l 2

3. I terat ion

OOA-Model l 3

Zeit


LE 1328

7 Schritte zum statischen Modell1 Klassen identifizieren

Für jede Klasse nur so viele Attribute und Operationen identifizieren, wie für das Problemverständnis und das einwandfreie Erkennen der Klasse notwendig sind

→Klassendiagramm→Kurzbeschreibung Klassen

2 Assoziationen identifizierenZunächst nur die reinen Verbindungen eintragen, d.h. noch keine genaueren Angaben, z.B. zur Kardinalität oder zur Art der Assoziation, machen

→Klassendiagramm.


LE 1329

7 Schritte zum statischen Modell3 Attribute identifizieren

Identifizieren aller Attribute des Fachkonzepts→Klassendiagramm

4 Vererbungsstrukturen identifizieren... aufgrund der identifizierten Attribute →Klassendiagramm

5 Assoziationen vervollständigenEndgültig festlegen, ob eine »normale«Assoziation, Aggregation oder Komposition vorliegt sowie Festlegung der Kardinalitäten, Rollen, Namen und Restriktionen

→Klassendiagramm→Objektdiagramm.


LE 1330

7 Schritte zum statischen Modell6 Attribute spezifizieren

Für alle identifizierten Attribute eine vollständige Spezifikation erstellen

→ Attributspezifikation

7 Muster identifizierenDas Klassendiagramm daraufhin überprüfen, ob Muster enthalten sind und diese richtig modelliert wurden.


LE 1331

3 Schritte zum dynamischen Modell1 Szenarios erstellen

Jeden Geschäftsprozess durch eine Menge von Szenarios präzisieren

→Sequenzdiagramm, KollaborationsdiagrammAlternativ oder ergänzend können auch Aktivitätsdiagramme verwendet werden

2 Zustandsautomat erstellenFür jede Klasse prüfen, ob ein nicht-trivialer Lebenszyklus erstellt werden kann und muss

→Zustandsdiagramm.


LE 1332

3 Schritte zum dynamischen Modell3 Operationen beschreiben

Überlegen, ob eine Beschreibung notwendig istWenn ja, dann ist je nach Komplexitätsgrad die entsprechende Form zu wählen

→Klassendiagramm→fachliche Beschreibung der Operationen→ Zustandsautomaten → Aktivitätsdiagramme

→SemOrg.


LE 1333

Checkliste KlassenErgebnisse

KlassendiagrammJede Klasse – entweder nur mit Namen oder mit wenigen wichtigen Attributen/Operationen – in das Klassendiagramm eintragenKurzbeschreibung der Klassen

Konstruktive Schritte1 Welche Klassen lassen sich mittels

Dokumentanalyse identifizieren (bottom-up)?Aus Formularen und Listen Attribute entnehmen und zu Klassen zusammenfassen.


LE 1334

Checkliste KlassenReengineering von Software-Altsystemen:

Arbeitsabläufe anhand von Benutzerhandbüchern, Bildschirmmasken, Dateibeschreibungen ermittelnAnhand des laufenden Systems die Funktionen der Geschäftsprozesse ausführenKlassen mithilfe der Bildschirmmasken ermitteln

Bei technischen Systemen bieten sich die realen Objekte als Ausgangsbasis an, z.B. Lagermodul

2 Welche Klassen lassen sich aus der Beschreibung der Geschäftsprozesse identifizieren (top-down)?

Beschreibung nach Klassen durchsuchenOft sind Substantive potenzielle Klassen

Potenzielle Klassen auf Attribute überprüfenAkteure, über die man sich etwas »merken«muss, sind potenzielle Klassen.


LE 1335

Checkliste Klassen3 Zu welchen Kategorien gehören die Klassen?

Konkrete Objekte bzw. Dinge, z.B. PKWPersonen und deren Rollen, z.B. Kunde, DozentInformationen über Aktionen, z.B. Banküberweisung durchführenOrte, z.B. WartezimmerOrganisationen, z.B. FilialeBehälter, z.B. LagerplatzDinge in einem Behälter, z.B. Reifen in einem LagerplatzEreignisse, z.B. EheschließungKataloge, z.B. ProduktkatalogVerträge, z.B. Autokaufvertrag.


LE 1336

Checkliste KlassenAnalytische Schritte

4 Liegt ein aussagefähiger Klassenname vor?Der Klassenname soll

der Fachterminologie entsprechenein Substantiv im Singular seindasselbe ausdrücken wie die Gesamtheit der Attributenicht die Rolle dieser Klasse in einer Beziehung zu einer anderen Klasse beschreibeneindeutig im Paket bzw. im System seinnicht dasselbe ausdrücken wie der Name einer anderen Klasse

5 Ist das gewählte Abstraktionsniveau richtig?Die Ziele sind nicht

möglichst viele Klassen oderKlassen geringer Komplexität zu identifizieren.


LE 1337

Checkliste Klassen6 Wann liegt keine Klasse vor?

Keine Klassen bilden, um Mengen von Objekten zu verwalten

7 FehlerquellenZu kleine KlassenAus jedem Report eine Klasse modellierenKlasse modelliert BenutzungsoberflächeKlasse modelliert Entwurfs- oder Implementierungsdetails

Für klassische Entwickler8 Identifizieren von Klassen für Datenmodellierer

Eine potenzielle Klasse ist jeder Entitätstyp und jeder Beziehungstyp mit Attributen.


LE 1338

2.18.3.3 Checkliste Klasse1 Dokumentanalyse

Fallstudie »Seminarorganisation«

Firm a Straße/ Post fach Land

PLZ Ort Telef on

Ti tel Vorname Nam e

Anmeldebest ätigung und Rechnung erbet en an:

Veranstalt ungs-Nr. Sem inarbezeichnung vom b is

Ti tel Vorname Name

Als Teilnehmer zu nachfo lgenden TEACHWARE-Sem inaren wi rd angem eldet:

Anmeldung zu TEACHWARE-Seminaren


LE 1339

2.18.3.3 Checkliste KlasseKlassen des Anmeldeformulars

Seminar veranst al tung

Veranstaltungs-NrSeminarbezeichnungSeminarbeginnSeminarende

Rechnungsempfänger

TitelVornameNameFirmaSt raße/ PostfachLandPLZOrtTelefon

Teilnehmer

TitelVornameName


LE 1340

2.18.3.3 Checkliste Klasse2 Beschreibung der Geschäftsprozesse

Kunde

NameAdresseKont ak tGeburtsdatumFunktionUm satzKunde seit

erst el le Adressaufkleber()erst el le Mit tei lung()

Veranstal tung

NummerDauerVomBisTagesrasterAnf angTagesrasterEndeAnfangErst erTagEndeLet zterTagOrtAdresseTeilnehmerMaxStorniert

erst elle Teilnehm erliste()erst elle Teilnehm erurkunde()stornieren()erst elle Honorarmi tt ei lung()

Doz en t

Num merNam eAdresseKontaktGeburtsdatumBiografieHonorar pro TagKurzmit teilungNot izenDozent sei t

Buchun g

Angem eldet amBest ät igung amRechnung amAbgemeldet amMit tei lung am

erst el le Mit tei lung()anm elden()abmelden()

Fi rmenbuchung

erstelle Mi tt eilung()anmelden()abmelden()

Semi nartyp

Kurzt it elTit elZielsetzungMethodikInhal tsübersichtTagesablaufDauerUnterlagenZielgruppeVoraussetzungenGebühr ohne MWSTTei lnehmerzahl maxTei lnehmerzahl min

Zahl un gsverz ug

Rechnungsdat umRechnungsbetrag

Firma

KurznameNameAdresseKont ak tAnsprechpartnerAbt eilungGeburtsdat umFunktionKurzmit t ei lungNotizenUmsatzKunde seit

M itarb eit er

NameBerecht igungPasswortTätigkei t


LE 1341

2.18.3.3 Checkliste Klasse3 Kategorien

Personen und deren RollenKunde, Dozent, Mitarbeiter

Informationen über AktionenBuchung, Firmenbuchung, Zahlungsverzug

OrganisationFirma

KatalogeSeminar, Veranstaltung

→SemOrg.


LE 1342

Checkliste AssoziationenErgebnis

KlassendiagrammAssoziationen im ersten Schritt nur als Linie eintragenNoch keine Kardinalitäten, Aggregationen, Kompositionen, Rollen, Namen, Restriktionen

Konstruktive Schritte1 Welche Assoziationen lassen sich mittels

Dokumentanalyse ableiten?Aus Primär- und Fremdschlüsseln ermitteln.


LE 1343

Checkliste Assoziationen2 Welche Assoziationen lassen sich aus

Beschreibungen der Geschäftsprozesse ermitteln?Nach Verben suchen, insbesondere:

räumliche Nähe (in der Nähe von)Besitz (hat)Aktionen (fährt)Kommunikation (redet mit), (verheiratet mit)allgemeine Beziehungen

3 Liegt eine Assoziation folgender Kategorien vor?A ist physische Komponente von BA ist logische Komponente von BA ist eine Beschreibung für BA ist eine Zeile einer Liste BA ist ein Mitglied von B.


LE 1344

Checkliste AssoziationenA ist eine organisatorische Einheit von BA benutzt BA kommuniziert mit BA besitzt B

4 Welche Restriktionen muss die Assoziation erfüllen?Eine Assoziation: {ordered}Mehrere Assoziationen: {or}, {subset}

5 Welche Rollen spielen die beteiligten Klassen?Rollennamen angeben, wenn

Assoziation zwischen derselben Klasse existierteine Klasse in verschiedenen Assoziationen auch verschiedene Rollen spieltdurch den Rollennamen die Bedeutung der Klasse in der Assoziation genauer spezifiziert werden kann.


LE 1345

Checkliste AssoziationenAnalytische Schritte

6 Ist eine Benennung notwendig oder sinnvoll?Notwendig, wenn zwischen zwei Klassen mehrere Assoziationen bestehenRollennamen (Substantive) bevorzugenRollennamen sind bei reflexiven Assoziationen immer notwendig

7 Liegt eine 1:1-Assoziation vor?Zwei Klassen sind zu modellieren, wenn...

die Verbindung in einer oder beiden Richtungen optional ist und sich die Verbindungzwischen beiden Objekten ändern kannes sich um zwei umfangreiche Klassen handeltdie beiden Klassen eine unterschiedliche Semantik besitzen.


LE 1346

Checkliste Assoziationen8 Gibt es zwischen 2 Klassen mehrere Assoziationen?

Prüfen, ob die Assoziationeneine unterschiedliche Bedeutung besitzen oder/undunterschiedliche Kardinalitäten haben

9 Sind abgeleitete Assoziationen korrekt verwendet? Fügen keine neue Information zum Modell hinzuLassen sich mittels Objektdiagrammen erkennen

10 Assoziative Klasse oder eigenständige Klasse?Assoziative Klasse betont die Assoziation zwischen den beteiligten KlassenAssoziative Klassen lassen sich in eigenständige Klassen wandeln

11 FehlerquellenVerwechseln von Assoziation mit Vererbung.


LE 1347

2.18.3.4 Checkliste AssoziationIdentifizierte Assoziationen in der Fallstudie »Seminarorganisation«

Kunde

Seminartyp

Firm a

Zahlun gsver zug

Ver ans tal tu ng

Arbeitgeber

Mitarbeiter

Fir men buch ung

Buch ung

DozentAuft raggeber

Referent Seminarleiter

Ersatz-teilnehm er

{subset}

kann fach l ich abhalten

Teilnehmer


LE 1348

2.18.3.4 Checkliste Assoziation3 Kategorien

A ist logische Komponente von B: Veranstaltung zu Seminartyp

A ist ein Mitglied von BKunde zu Firma

4 Restriktionen Aus dem Pflichtenheft ist nicht ersichtlich, ob ein Seminarleiter gleichzeitig auch Referent auf derselben Veranstaltung sein mussEine Rückfrage beim Auftraggeber ergibt, dass diese Restriktion gilt:

Der Seminarleiter muss Referent sein, aber außer ihm kann es noch andere Referenten geben.


LE 1349

2.18.3.4 Checkliste AssoziationKlasse Zahlungsverzug gewandelt in eine Assoziation →SemOrg

Kunde Buchung

Teilnehmer

Debitor

{ordered nach Datum}

→SemOrg.


LE 1350

Checkliste AttributeErgebnisse

KlassendiagrammFür jedes Attribut den Namen in das Klassendiagramm eintragenKlassenattribute und abgeleitete Attribute kennzeichnen

AttributspezifikationJedes Attribut spezifizierenFür komplexe Attribute sind ggf. entsprechende Typen zu definieren.


LE 1351

Checkliste AttributeKonstruktive Schritte

1 Attribute durch Dokumentanalyse identifizierenEinfache Attribute sind ggf. zu Datenstrukturen zusammenzufassenPrüfen, ob alle Attribute wirklich notwendig sindFür jedes Attribut prüfen, ob es »im Laufe seines Lebens« einen Wert annehmen kann und ob diese Werte an der Benutzungsoberfläche sichtbar sind

2 Attribute durch Geschäftsprozesse identifizierenBenötigte Daten zur Ausführung der Aufgaben eines GeschäftsprozessesBenötigte Daten für Listenfunktionalität.


LE 1352

Checkliste Attribute3 Wurden geeignete Attributtypen gewählt und u.U. als

elementare Klasse beschrieben?Vorgegebene Typen nur verwenden, wenn problemadäquatAttribute beliebigen Typs definieren, um problemadäquate Modellierung auf ausreichendem Abstraktionsniveau zu erreichenFür komplexe Attribute zur Konstruktion der Typen das Klassenkonzept verwenden (elementare Klassen).


LE 1353

Checkliste AttributeAnalytische Schritte

4 Ist der Attributname geeignet?Der Attributname soll

kurz, eindeutig und verständlich seinein Substantiv oder Adjektiv-Substantiv sein den Namen der Klasse nicht wiederholen bei komplexen (strukturierten) Attributen der Gesamtheit der Komponenten entsprechennur fachspezifische oder allgemein übliche Abkürzungen enthalten, z.B. PLZ

5 Klasse oder komplexes Attribut?Klasse:

Objektidentität, gleichgewichtige Bedeutung im System, Existenz unabhängig von der Existenz anderer Objekte, Zugriff in beiden Richtungen grundsätzlich möglich.


LE 1354

Checkliste AttributeAttribut: keine Objektidentität, Existenz abhängig von Existenz anderer Objekte, Zugriff immer über das Objekt, untergeordnete Bedeutung

6 Wurde das richtige Abstraktionsniveau gewählt?Wurden komplexe Attribute gebildet?Bilden Attribute geeignete Datenstrukturen?Anzahl der Attribute pro Klasse angemessen?

7 Gehört Attribut zur Klasse oder einer Assoziation?Test:

Muss Attribut auch dann zur Klasse gehören, wenn die Klasse isoliert von anderen Klassen betrachtet wird?

Wenn ja, dann gehört das Attribut zu dieser KlasseWenn nein, dann ist zu prüfen, ob es sich einer Assoziation zuordnen lässt Sonst: Klasse oder Assoziation vergessen.


LE 1355

Checkliste Attribute8 Liegen Klassenattribute vor?

Ein Klassenattribut liegt vor, wenn gilt:Alle Objekte der Klasse besitzen für dieses Attribut denselben AttributwertEs sollen Informationen über die Gesamtheit der Objekte modelliert werden

9 Sind Schlüsselattribute fachlich notwendig?Schlüsselattribute werden nur dann eingetragen, wenn sie Bestandteil des Fachkonzepts sind

10 Werden abgeleitete Attribute korrekt verwendet?Information ist für den Benutzer sichtbarLesbarkeit wird verbessert.


LE 1356

Checkliste Attribute11 Wann wird ein Attribut nicht eingetragen?

Dient nur zum Identifizieren der ObjekteDient lediglich dazu, eine andere Klasse zu referenzieren, d.h. es realisiert eine AssoziationBeschreibt den internen Zustand eines Lebenszyklus und ist außerhalb des Objekts nicht sichtbarBeschreibt Entwurfs- / ImplementierungsdetailsIst abgeleitetes Attribut, das nur eingefügt wurde, um Berechnungszeit zu sparen

12 FehlerquellenVerwenden atomarer Attribute anstelle von komplexen DatenstrukturenFormulieren von Assoziationen als Attribute.


LE 1357

2.18.3.5 Checkliste Attribut3 Selbstdefinierte Typen

Für die Seminarorganisation werden folgende elementare Klassen definiert:

Strukturierte Typen: NameT, AdresseT, KontaktT, BankverbindungT

Aufzählungstypen: AnredeET, TitelET, LandET, RolleET.


LE 1358

2.18.3.5 Checkliste AttributAttribute der Seminarorganisation

Firma

Kur znam e: St ring <10 >Name: Nam eTAd resse: Ad resseTKon takt : Kon tak tTAn sp rech partner : NameTKon taktAnsp rech partn er: Ko ntaktTAb teilun g: St ring<3 0>Geburtsd atum Ansprechp ar tn er: DateFun kt ion : St ring <30>Kur zmit teilung: St ring <2 0 0>Not izen: St ring <2 00>Um satz: Flo atKund e seit : Date

M ita rbe it er

Nam e: Nam eTBerecht ig ung: Ro lleETPassw ort : St r ing<6 >Tät ig keit : Str ing <3 0>

Firm enbu chu ng

Ang emeld et am: DateBestätig un g am : DateRechn ung am : DateAb gem eld et am: DateMit teilu ng am : Date

erstelle Mit teilung ()anm elden()abm elden ()

Buch ung

Ang emeld et am: DateBestätig un g am : DateRechn ung am : DateAb gem eld et am: DateMit teilu ng am : Date

erstelle Mit teilung ()anm elden()abm elden ()

Doz ent

Nam e: Nam eTAd resse: AdresseTKon takt : KontaktTGeb ur tsdatum : DateBiog raf ie: St ring <4 0 0>Hono rar p ro Tag : FloatKurzmit teilung : Str ing<200>Not izen: St r ing<2 00>Dozent seit : Date

«En um erat ion »Rol le ET

Sem inarsachb earb eiterKu nd ensachb earb eiterVeranstaltun gsbet reuerAdm inist rator

Semina rt yp

Ku rzt it el: St ring <10 >Titel: St ring<2 0 0>Zielsetzun g: St rin g<4 00 >Meth od ik: St rin g<40 0>In haltsü bersicht : St ring<40 0>Tagesab lauf : St ring<20 0 >Dau er : Sho rtUnterlagen : St ring<20 0>Zielgru ppe: St rin g<20 0>Vo raussetzungen: St ring<2 00>Gebühr ohne MWST: FloatTeilneh mer zah l m ax: Sh ortTeilneh mer zah l m in: Sh or t

Ver ans ta l tun g

Num m er : Sho rtDau er: Sh ortVom : DateBis: DateTag esrasterAn fan g: Tim eTag esrasterEnd e: TimeAn fan gErsterTag: Tim eEnd eLetzter Tag: Tim eOrt : St rin g<5 0>Ad resse: AdresseTTeiln ehm erMax: Sh ortSto rn ier t: JaNeinET

erstelle Teilnehmerliste()erstelle Teilnehmerur kunde()stor nieren()erstelle Hon orarm it teilun g()

Kunde

Name: Nam eTAd resse: Ad resseTKon takt : Kon tak tTGebu rtsdatu m: DateFun kt ion : St ring <50>Um satz: Cur rencyKund e seit : Date

erstelle Adressau fk leber()erstelle Mit teilun g()

A rbeitg eber

Mitar beiter

Ersatzteil nehm er

Au f t ragg eber

Referent Sem in ar-leiter

ka nn fach lich ab geh alten

Teil-nehm er

Deb itor


LE 1359

2.18.3.5 Checkliste AttributAttribut oder Klasse

1

*

Ar t ikel

Preis

Lager

Bezeich nun gVerw alter

Fixed 0 ..11

od er

Pr eisT

PreisHändlerPreisGroßku ndePreisEin zelkund e

Pr eisT

BetragWährun g

1

*

Art ik el

Lag er

BezeichnungVerwalter

Preis

→SemOrg.


LE 1360

Checkliste VererbungErgebnis

Klassendiagramm Alle Vererbungsstrukturen eintragenAbstrakte Klassen bilden

Konstruktive Schritte1 Ergibt Generalisierung eine Einfachvererbung?

Neue Oberklasse aus gleichartigen Klassen?Vorhandene Klasse als Oberklasse geeignet?

2 Ergibt Spezialisierung eine Einfachvererbung?Kann jedes Objekt der Klasse für jedes Attribut einen Wert annehmen?Kann jede Operation auf jedes Objekt der Klasse angewendet werden?


LE 1361

Checkliste VererbungAnalytische Schritte

3 Liegt eine »gute« Vererbungsstruktur vor?Verbessert die Vererbungsstruktur das Verständnis des Modells?Benötigt jede Unterklasse alle geerbten Attribute, Operationen und Assoziationen?Liegt eine Ist-ein-Beziehung vor?Entspricht die Vererbungsstruktur den »natürlichen« Strukturen des Problembereichs?Besitzt sie maximal 3 bis 5 Hierarchiestufen?

4 Wann liegt keine Vererbung vor?Die Unterklassen bezeichnen nur verschiedene Arten, unterscheiden sich aber weder in ihren Eigenschaften noch in ihrem Verhalten.


LE 1362

2.18.3.5 Checkliste VererbungErmittelte Vererbungsstruktur Person

Per son

Nummer: Ser ialName: Nam eTAdresse: AdresseTKontak t: Kontak tTGeburtsdatum: DateErsterfassung am: DateKurzm itteil ung: Str ing<200>Not izen: Str ing<200>

erst el le Adressaufk leber()

Dozent

Biografie: Str ing<400>Honorar pro Tag: FloatDozent seit: Date

M itarbeiter

Berechtigung: RolleETPasswort: Str ing<6>Tätigkeit : St r ing<30>

Kunde

Funkti on: Str ing<50>Um satz: Currency

erst elle Mittei lung()


LE 1363

2.18.3.5 Checkliste VererbungErmittelte Vererbungsstrukturen →SemOrgVeranstaltung und Buchung

Buchung

An gemeldet am : DateBestät igu ng am : DateRechnu ng am : DateAb gemeldet am: DateMit teilun g am: Date

erstelle Mit teilu ng()anm eld en ()abm eld en()

Verans tal t ung

Num mer: Sho rtDauer: ShortVo m: DateBis: DateTagesrasterAn fang : Tim eTagesrasterEnd e: TimeAn fang ErsterTag : Tim eEnd eLetzterTag: TimeOrt : St ring <5 0>Ad resse: AdresseTTeiln eh merMax : ShortStorniert : JaNein ET

sto rnieren ()erstelle Hon orarmit teilu ng()

Arbeit -geber

Mit -arb eiter

Auf tr ag -geberTeil-

nehm er Deb itor

Kundenbuchung Firme nbuchung

Fir meninte rne Ver anst al tung

Pausch alp reis: Flo atTeiln eh mer m ax : Sh ort

Öff ent l iche Ve ranst al tung

Ko operat ionsp ar tn er: St rin g<1 00 >Storn ogeb ühr: FloatTeilnehm er min: Sh ortTeilnehm er aktuell: Shor t

erstelle Teiln ehmerliste()erstelle Teiln ehmerurkunde()

Kunde Firm a


LE 1364

Checkliste KardinalitätenErgebnis

KlassendiagrammAlle Kardinalitäten eintragen

Konstruktive/analytische Schritte1 Schnappschuss oder Historie modellieren?

Aus den Anfragen an das System ergibt sich, obein Schnappschuss (1- bzw. 0..1-Kardinalität) oder die Historie (many-Kardinalität)

zu modellieren istSchnappschuss: eine alte Verbindung wird gelöst wird, wenn eine neue aufgebaut wirdHistorie: eine neue Verbindung wird zwischen den jeweiligen Objekten hinzugefügt.


LE 1365

Checkliste Kardinalitäten2 Liegt eine Muss- oder Kann-Assoziation vor?3 Enthält die Kardinalität feste Werte?

Ist eine Obergrenze vom Problembereich her (oft bei technischen Systemen) zwingend vorgegeben?

Im Zweifelsfall mit variablen Obergrenzen arbeiten

Ist die Untergrenze vom Problembereich her zwingend vorgegeben?

Im Zweifelsfall mit »0« arbeiten

Gelten besondere Restriktionen für die Kardinalitäten?

4 FehlerquelleOft werden Muss-Assoziationen verwendet, wo sie nicht benötigt werden.


LE 1366

2.18.3.7 Checkliste KardinalitätenSeminarorganisation

Bei allen Assoziationen: Historie modellierenKardinalitäten aus dem Pflichtenheft:

Zwischen der Buchung und dem Kunden sowie der Veranstaltung liegt jeweils eine Muss-Beziehung vor, da eine Buchung für sich alleine nicht existieren kann

Ursprünglich: Assoziative Klasse

Ein Kunde kann mehrere Buchungen vornehmen (*), zu einer Veranstaltung kann es m Buchungen geben (*)Jeder Zahlungsverzug gehört zu genau einem Kunden bzw. einer Firma, ein Kunde bzw. eine Firma kann mehrere Zahlungsverzüge besitzen.


LE 1367

2.18.3.7 Checkliste KardinalitätenZu jeder Veranstaltung gibt es einen oder mehrere Dozenten, die Seminarleiter sindJede Veranstaltung gehört zu genau einem SeminartypEine Veranstaltung muss von mindestens einem Dozenten als Referent und einem Dozenten als Seminarleiter durchgeführt werdenEin gebuchter Kunde kann bei Abmeldung genau einen Ersatzteilnehmer meldenAlle anderen Beziehungen sind Kann-Beziehungen mit variabler Obergrenze

Feste GrenzenDurch Problemstellung: keine festen Grenzen

→SemOrg.


LE 1368

Checkliste Aggregation und KompositionErgebnis

KlassendiagrammAlle Aggregationen und Kompositionen eintragen

Konstruktive/Analytische Schritte1 Für eine Komposition gilt:

Es liegt eine Ist-Teil-von-Beziehung vorKardinalität bei der Aggregatklasse: 0..1 oder 1

Lebensdauer der Teile ist an die des Ganzen gebundenEin Teil darf jedoch zuvor explizit entfernt werden

Funktionen des Ganzen werden automatisch auf seine Teile angewendetMuster bilden eine gute Orientierungshilfe

Liste (Bestellung – Bestellposition), Baugruppe (Auto –Motor) und Stückliste mit physikalischem Enthaltensein.


LE 1369

Checkliste Aggregation und Komposition2 Für eine Aggregation gilt:

Es liegt eine Ist-Teil-von-Beziehung mit shared aggregation (ein Teilobjekt kann mehreren Aggregatobjekten zugeordnet werden) vorSie ist selten

3 Im Zweifelsfall: immer einfache AssoziationBei dem geringsten Zweifel an einer Komposition oder Aggregation immer die Assoziation wählen

4 FehlerquellenPrinzipiell ist es möglich, jedes Attribut als Klasse zu modellieren und mittels einer Komposition mit der ursprünglichen Klasse zu verbinden

Dies führt jedoch zu schlechten Modellen.


LE 1370

2.18.3.8 Checkliste Aggregation & KompositionSeminarorganisation

Eine Komposition liegt nicht vorIn erster Näherung könnte es sich bei Seminartyp – Veranstaltung um eine Komposition handeln

Nicht erfüllt: Funktionen des Ganzen werden automatisch auf seine Teile angewandt

AggregationEine Aggregation liegt nicht vor

Bei Seminartyp – Veranstaltung liegt keine Ist-Teil-von-Beziehung vor

Im Zweifel AssoziationAlle Beziehungen sind »einfache« Assoziationen.


LE 1371

Makroprozess »Statisches Modell«7 Muster identifizieren

Folgende Muster lassen sich identifizierenExemplartyp: Seminartyp – VeranstaltungKoordinator: Kundenbuchung, FirmenbuchungRollen: DozentGruppe: Firma - Kunde

Alle Muster sind korrekt angewendet

→SemOrg.


LE 1372

Checkliste SzenariosErgebnisse

Sequenzdiagramm, KollaborationsdiagrammFür jedes relevante Szenario: SequenzdiagrammAlternativ: Kollaborationsdiagramme

Konstruktive Schritte1 Aus jedem Geschäftsprozess (GP) mehrere

Szenarios entwickelnVariationen von GPs ermittelnStandardausführung und AlternativenPositive und negative Fälle unterscheidenPrüfen, welche Szenarios wichtig sindDiagramme benennen und beschreiben.


LE 1373

Checkliste Szenarios2 Ablauf relevanter Szenarios durch Sequenz- oder

Kollaborationsdiagramme beschreibenBeteiligte KlassenAufgaben in Operationen zerlegenReihenfolge der Operationen prüfenUML erlaubt es, im Sequenzdiagramm Bedingungen anzugeben

Damit können mehrere Variationen durch ein einziges Sequenzdiagramm beschrieben werden

3 Operationen den Klassen zuordnenWerden nur Attribute einer Klasse benötigt, dann ist die Operation dieser Klasse zuzuordnenKonstruktoren sind der jeweiligen Klasse selbst zuzuordnen.


LE 1374

Checkliste SzenariosAnalytische Schritte

4 Sind die Empfänger-Objekte erreichbar?Assoziation existiert (permanente Verbindung)Identität kann dynamisch ermittelt werden (temporäre Verbindung)

5 Sequenzdiagramm konsistent mit Klassendiagr.?Alle Klassen auch im Klassendiagramm enthaltenMit Ausnahme von impliziten Operationen werden nur Operationen aus dem Klassendiagramm eingetragen

6 FehlerquellenBenutzungsoberfläche wird beschriebenZu viele Details sind beschrieben.


LE 1375

2.18.3.9 Checkliste SzenarioSeminarorganisation →SemOrg

Beispiel einer erfolgreichen Anmeldung

anmelden()

Mit teilung(Anmelde-bestät igung,Rechnung)

istFrei()

erfassen()

:Kunden-buchung

:Kunde

:Veranstal tung


LE 1376

Checkliste ZustandsautomatenErgebnis

Zustandsdiagramm

Konstruktive Schritte1 Existiert ein nicht-trivialer Lebenszyklus?2 Welche Zustände enthält der Automat?

Ausgangsbasis ist der AnfangszustandDurch welche Ereignisse wird ein Zustand verlassen?

Ereignisse umgangssprachlich beschreiben, was »von außen auf das Objekt einwirkt«

Welche Folgezustände treten auf?Wodurch wird der Zustand definiert (Attributwerte, Objektverbindungen)?


LE 1377

Checkliste Zustandsautomaten3 Existieren Endzustände?

Nur bei linearen Lebenszyklen:Das Objekt hört auf zu existierenDas Objekt existiert weiterhin, aber sein dynamisches Verhalten ist nicht länger von Interesse (schlafendes Objekt)

4 Welche Operationen besitzt das Objekt?Jede zustandsabhängige Operation aus dem Klassendiagramm eintragenOperationen, die in jedem Zustand ausgeführt werden können, nicht eintragenPrüfen, ob weitere Operationen notwendig sind

5 Sind Operationen als Aktivitäten oder als Aktionen zu modellieren?


LE 1378

Checkliste Zustandsautomaten6 Welche Ereignisse sind zu modellieren?

Externe Ereignisse:vom Benutzervon anderen Objekten

Zeitliche Ereignisse:ZeitdauerZeitpunkt

Intern generierte Ereignisse des betrachteten ObjektsWelche Fehlersituationen können auftreten und wie soll das Objekt darauf reagieren (Ausnahmebehandlung)

Zuerst immer das Normalverhalten und erst im zweiten Schritt das Fehlerverhalten betrachten.


LE 1379

Checkliste ZustandsautomatenAnalytische Schritte

7 Geeigneter ZustandsnameBeschreibt eine bestimmte ZeitspanneKein VerbKann entfallen, wenn er keine zusätzliche Information enthält

8 Ist der Objekt-Lebenszyklus konsistent mit der Liste der Operationen?

Gibt es für jede Operation mindestens einen Zustand, in dem das Objekt auf die entsprechende Botschaft reagieren kann?Sind alle Aktivitäten und Aktionen auch Operationen des Klassendiagramms?


LE 1380

Checkliste Zustandsautomaten9 Sind alle Zustandsübergänge korrekt eingetragen?

Ist jeder Zustand erreichbar?Kann jeder Zustand – mit Ausnahme der Endzustände – verlassen werden?Sind die Zustandsübergänge eindeutig?

10 FehlerquellenModellierung der Benutzungsoberfläche im LebenszyklusGedankengut aus den Programmablaufplänen übernommen

»Schleifen« dürfen nicht vorkommenBedingungen sind immer mit einem Ereignis verknüpft.


LE 1381

2.18.3.10 Checkliste ZustandsautomatSeminarorganisation

Nicht-trivialer Zustandsautomat der Klasse Veranstaltung

existiert

fällt aus

when(Veranstaltungvorbei)

when(voll)

Teilnehmersagt ab/ notiereAbsage()

neue Veranstaltung/ erfassen()

Kunde meldet sich an/ notiereAnmeldung()

entfällt/ löschen()

gelöscht

Kunde meldet sich an/ notiereAnmeldung()

Teilnehmer sagt ab/ notiereAbsage()

Aktualisierungen/ ändern()

when(Veranstaltungvorbei)

buchend

ausgebuchtstorniert

entry / st ornieren()

fällt aus

durchgeführt


LE 1382

2.18.3.10 Checkliste ZustandsautomatSeminarorganisation →SemOrg

Zustandsmatrix der Veranstaltung

Ereignis Kunde meldet Teilnehmer ist voll fällt aus VeranstaltungZustand sich an sagt ab vorbeiex ist ier t b uchend i n.m. i ibuchend b uchend buchend ausgebucht st orniert durchgef ührtausgeb ucht i buchend n.m. st orniert durchgef ührt

st orniert i i n.m. i idurchgef . i i n.m. i i

Legende: i : Ereignis w ird ignoriert n.m .: Ereignis ni cht m öglich


LE 1383

Checkliste OperationenErgebnisse

Klassendiagramm: Operationen eingetragenBeschreibung der Operationen

Konstruktive Schritte1 Operationen ins Klassendiagramm eintragen

Aus Szenarios & Zustandsautomat. übernehmenListenoperationen hinzufügenKeine Verwaltungsoperationen eintragen

2 Vererbung von Operationen berücksichtigenOperationen so hoch wie möglich in der Hierarchie eintragen

3 Beschreibungen erstellen (nur wenn nötig).


LE 1384

Checkliste OperationenAnalytische Schritte

4 Besitzt die Operation einen geeigneten Namen?Beginnt mit einem VerbBeschreibt, was die Operation »tut«

5 Erfüllt jede Operation die Qualitätskriterien?Angemessener UmfangFunktionale Bindung, d.h. jede Operation realisiert eine in sich abgeschlossene Funktion

6 Ist das balancing erfüllt?Alle Attribute werden von den Operationen benötigt

7 FehlerquellenKeine Benutzungsoberfläche.


LE 1385

2.18.3.11 Checkliste OperationSeminarorganisation

Klassendiagramm nach dem 1. Durchlauf des Makroprozesses

Fir ma

Kurznam e: Str ing<10>Nam e: NameTAdresse: AdresseTKontakt : Kontakt TAnsprechpart ner : NameTKontakt Ansprechpartner: Kontakt TAbtei lung: Str ing<30>Gebur tsdat um Ansprechpartner: DateFunktion : St ring<30>Kurzmi ttei lung: Str ing<200>Notizen: Str ing<200>Umsatz: FloatKunde seit : Date

Seminartyp

Kurzt itel : St ring<10>Titel : St ring<200>Zielsetz ung: String<400>Method ik: Str ing<400>Inhalt sübersicht: Str ing<400>Tagesablauf : Str ing<200>Dauer: Shor tUnter lagen: Str ing<200>Zielgruppe: Str ing<200>Voraussetzungen: Str ing<200>Gebühr ohne MWST: FloatTeilnehmerzahl max: Shor tTeilnehmerzahl min: Short

Arbei tgeber

Auf traggeber

Referent

Seminar lei ter

k annf achl ichabhal ten

Teilnehmer

Debi to r

0..1

Kunde

Funktion : St ring<50>Umsatz: Currency

erstel le Mit tei lung()

Mi tarbei ter

Ersatzt eilnehmer

*0..1

1

Ver anstaltun g

Nummer: ShortDauer: ShortVom : DateBis: DateTagesrast erAnfang: TimeTagesrast erEnde: TimeAnf angErst erTag: TimeEndeLet zterTag: Tim eOrt: Str ing<50>Adresse: AdresseTTei lnehm erMax: ShortSt orniert : JaNeinET

st ornieren()erstel le Honorarm it teilung()notiere Anmeldung()notiere Abmeldung()istFrei()gib Al ternative Veranst al tung()

* 1

Fi rmen buchung

*

0..1

Buchung

Angem eldet am: Dat eBestätigung am: Dat eRechnung am: Dat eAbgem eldet am: Dat eMit tei lung am : Date

anmelden()abmelden()erst elle Mi ttei lung()prü fe Zahlungsmoral()

Fir menin terne Ver anstal tu ng

Pauschalpreis: FloatTei lnehm er max : Shor t

Öffent li che Veransta ltung

Kooperationspart ner : St ring<100>Stornogebühr : FloatTeilnehmer min: Shor tTeilnehmer ak tuel l : Shor t

erstelle Teilnehmer liste()erstelle Teilnehmerurkunde()

Doz ent

Biograf ie: Str ing<400>Honorar pro Tag: Float

*

*

*

*

*

1

1

*1

*

**

*

Kun denb uchung

Mitarbeiter

Berecht igung: Rol leETPasswor t: Str ing<6>Tätigkeit : Str ing<30>

Per son

Nummer: Ser ialName: Nam eTAdresse: AdresseTKont akt: Kont aktTGeburtsdatum: Dat eErst erf assung am: Dat eKurz mit tei lung: Str ing>200>Notiz en: St ring<200>

0..1

erstelle Adressaufkleber()


LE 1386

Danke!Aufgaben

Diese Präsentation bzw. Teile dieser Präsentation enthalten Inhalte und Grafiken desLehrbuchs der Software-Technik (Band 1), 2. Auflagevon Helmut Balzert, Spektrum Akademischer Verlag, Heidelberg 2001

Einführung und Überblick LE 1 V Unternehmensmodellierung ... · II SW-Management 8 LE 6 Kontrolle...

Documents

Transcript of Einführung und Überblick LE 1 V Unternehmensmodellierung ... · II SW-Management 8 LE 6 Kontrolle...