OM – ObjektorientierteObjektorientierte ... · OM – ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung LE 1 7 1.2 Objektorientierte Analyse s Das statische

OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung

LE 11

1.2 Objektorientierte Analyses Ziel der Analyseu Wünsche und Anforderungen eines

Auftraggebers an ein neues Softwaresystem ermitteln und beschreiben

u Modell des Fachkonzepts erstellen, das konsistent, vollständig, eindeutig und realisierbar ist

u Alle Aspekte der Implementierung bewußt ausklammern (perfekte Technologie!)

Es ist nicht die Aufgabe des Auftraggebers, den Systemanalytiker zu verstehen, sondern der Systemanalytiker wird dafür bezahlt, sich dem Auftraggeber verständlich zu machen


LE 12

1.2 Objektorientierte Analyses Produkte der Analysephaseu Pflichtenheftl das Einstiegsdokument

u OOA-Modelll das Fachkonzept

u Prototyp der Benutzungsoberflächel die Visualisierung des Fachkonzepts


LE 13

1.2 Objektorientierte Analyses Pflichtenheftu Umgangssprachliche Beschreibung dessen, was

das zu realisierende System leisten solll Weniger detailliert als das OOA-Modelll Enthält auch einige Informationen, die nicht

im OOA-Modell dargestellt werdenu Zwei Zielsetzungenl Einstiegsdokument in das Projekt für alle, die

das System später pflegen und warten sollenl Ausgangsbasis für die objektorientierte

Modellbildung u Es ist nicht das Ziel, anhand des Pflichtenhefts,

das System zu implementieren


LE 14

1.2 Objektorientierte AnalyseGliederungsschema Pflichtenhefts 1 Zielbestimmung

Formulieren Sie Ziele und keine Funktionenu 1.1 Muß-Kriterienu 1.2 Kann-Kriterienu 1.2 Abgrenzungskriterien

s 2 Einsatzu 2.1 Anwendungsbereicheu 2.2 Zielgruppenu 2.3 Betriebsbedingungen


LE 15

1.2 Objektorientierte Analyses 3 Umgebungu 3.1 Softwareu 3.2 Hardwareu 3.3 Orgware

s 4 Funktionalität u typische Arbeitsabläufe u wichtige Selektionen

s 5 Datens 6 Leistungens 7 Benutzungsoberfläches 8 Qualitätszieles 9 Ergänzungen


LE 16

1.2 Objektorientierte Analyses OOA-Modell

Assoziation

StatischeKonzepte

Vererbung Paket

Geschäftsprozeß

DynamischeKonzepte

BotschaftZustands-automat

Szenario

Attribut

Basiskonzepte

Objekt Klasse

Operation

StatischesModell

DynamischesModell


LE 17

1.2 Objektorientierte Analyses Das statische Modell beschreibt ...u die Klassen des Fachkonzeptsu die Assoziationen (Beziehungen) zwischen den

Klassenu die Vererbungstrukturenu die Attribute der Klassen (Daten des Systems)u die Bildung von Paketen (Teilsysteme)


LE 18

1.2 Objektorientierte Analyses Das dynamische Modell zeigt

Funktionsabläufeu Geschäftsprozesse beschreiben die

durchzuführenden Aufgaben auf einem sehr hohen Abstraktionsniveau

u Szenarios zeigen, wie Objekte miteinander kommunizieren, um eine bestimmte Aufgabe zu erledigen

u Zustandsautomaten beschreiben die Reaktionen eines Objekts auf verschiedene Ereignisse (= Botschaften)


LE 19

1.2 Objektorientierte Analyses Der Prototyp der Benutzungsoberfläche ...u ist ein ablauffähiges Programm, das alle Attribute

des OOA-Modells auf der Benutzungsoberfläche darstellt

u besitzt weder Anwendungsfunktionen noch die Fähigkeit, Daten zu speichern

u besteht aus Fenstern, Dialogen Menüs usw. u hat den Zweck, das erstellte OOA-Modell mit dem

zukünftigen Benutzer oder einem Repräsentanten zu evaluieren

u sollte möglichst die vollständige Benutzungsoberfläche des Fachkonzepts enthalten


LE 110

1.2 Objektorientierte Analyses Grundprinzip der Softwareentwicklungu Trennung von Fachkonzept und

Benutzeroberfläche u Im Fachkonzept wird festgelegt, welche

Informationen auf dem Bildschirm sichtbar sind

u Bei der Benutzungsoberfläche wird festgelegt, in welchem Format sie dargestellt werden


LE 111

1.3 Objektorientierter Entwurfs Entwurfszielu Weitgehende Entkopplung von Fachkonzept,

Benutzungsoberfläche und Datenhaltungs Realisierung durchu Drei-Schichten-Architektur

s Einfluß durch ...u verwendetes GUI (Graphical User Interface)l Bestimmt Aussehen der

Benutzungsoberflächeu verwendete Form der Datenhaltung l Relationale Datenbankl Objektorientierte Datenbank l Flache Dateien


LE 112

1.3 Objektorientierter Entwurfs Drei Schichten-Architektur

Reale Welt

OOAOOD

OOA-Modell

OOD-ModellBuchView BuchFile

Benutzungsoberfläche Fachkonzept Datenhaltung

C++/Java

class BuchView class Buch

{String Titel;...}

class BuchFile

Buch

Titel

Buch

Titel

{...}{...}


LE 113

1.3 Objektorientierter Entwurf

Abgren-zung

von Analyse

und Entwurf

Analyse

OOA-Modell

Pflichten-heft

a/b

Prototyp| | | |

| | | |

OK

Entwurf

Fachkonzept

Datenhaltung

Benutzungs-oberfläche

OOD-ModellRelat.DB

OODB

Netz-verteilung

Klassen-bibliotheken

C++ bzw.Java-Programme


LE 114

1.3 Objektorientierter Entwurfs Produkt der Entwurfsphase: OOD-Modell u Abbild des späteren Programmsu Statisches Modelll Enthält alle Architektur-Klassen des

Programms l Pakete zur Modellierung von Teilsystemen und

Darstellung der verschiedenen Schichtenu Dynamisches Modelll Übersichtliche Beschreibung der komplexen

Kommunikation zwischen Objekten


LE 115

Inhalt: UML - Statische Konzepte2.1 Objekt2.2 Klasse2.3 Attribut2.4 Operation2.5 Assoziation2.6 Vererbung2.7 PaketCRC Karten


LE 116

2.1 Objekts Beispiel: Mitarbeiter-Objekt

einstellen ()

Personalnr 1234Name MüllerGehalt 5500

druckeAusweis ()

erhöheGehalt ()


LE 117

2.2 Klasses Definitions Eine Klasse ...u definiert für eine Kollektion von Objekten derenl Struktur (Attribute)l Verhalten (Operationen) und l Beziehungen (relationships)

u besitzt einen Mechanismus, um neue Objekte zu erzeugen (object factory)

u Jedes erzeugte Objekt gehört zu genau einer Klasse

u Unter den Beziehungen sind Assoziationen und Vererbungsstrukturen zu verstehen


LE 118

2.2 Klasses Beispiel

:Mitarbeiter

Personalnr = 1234Name = MüllerGehalt = 5500

:Mitarbeiter

Personalnr = 5678Name = MeyerGehalt = 5100

Mitarbeiter

PersonalnrNameGehalt

einstellen()erhöhe Gehalt()drucke Ausweis()


LE 119

2.2 Klasses Notation UML

Namensfeld

Attributliste

Operationsliste

Klasse

Attribut. . .

Operation(). . .

Operation(). . .

Klasse

Klasse

Klasse

Attribut. . .


LE 120

2.2 Klassee. Klassendiagrammu Klassensymbole werden zusammen mit

weiteren Symbolen (z.B. Assoziationen und Vererbung) in das Klassendiagramm eingetragen

u Beschreibung des statischen Modells des Systems

u Bei großen Systemen mehrere Klassendiagramme erstellen


LE 121

2.3 Attributa. Definitionu Attribute beschreiben die Daten, die von den

Objekten einer Klasse angenommen werden können

u Jedes Attribut ist von einem bestimmten Typu Alle Objekte einer Klasse besitzen dieselben

Attribute, jedoch unterschiedliche Attributwerte

Student

MatrikelnrNameGeburtsdatumImmatrikulat ionVordiplomNoten

:Student

Matrikelnr = 7002345Name = (Hans, Mey er)Geburtsdatum = 4.7.1974Immatrikulation = 1.9.1994

Noten = ((2.3, Analy sis),(1.3, Informat ik ))

Das At tribut Vordiplom besitz t- noch - keinen Wert.


LE 122

2.3 Attributs Notation UML

Klasse

AttributKlassenattribut/abgeleitetes Attribut

At tribut: Typ = Anfangswert{Merkmal1, Merkmal2, ...}


LE 123

2.3 Attributa. Abgeleitetes Attribut (derived attribute)u Der Wert kann jederzeit aus anderen

Attributwerten berechnet werdenu Ein abgeleitetes Attribut darf nicht direkt

geändert werdenu Kennzeichnung mit dem Präfix “/”

Person

Geburtsdatum/Alter


LE 124

2.3 Attributd. Restriktion (constraint)u Beziehung zwischen Attributwerten eines

Objekts, die während der Ausführung des Systems unverändert erhalten bleiben muß

u Restriktion = Invariante = Zusicherung, die immer wahr sein muß

u Beispiele:l Klasse Student{Vordiplom > Immatrikulation > Geburtsdatum}

l Klasse Artikel{Verkaufspreis >= 1.5 * Einkaufspreis}


LE 125

2.3 Attributa. Attributtyp u Jedes Attribut wird durch einen Typ beschriebenu Verwendung folgender Typen zur Erstellung eines

standardisierten OOA-Modellsl Standardtypenl Aufzählungstypenl (elementare) Klassenl list of Typ, wobei Typ ein beliebiger Typ sein

kann.u Typ = [Standardtyp | Aufzählungstyp |

Klasse | list of Typ]


LE 126

2.3 Attributd. Standardtypenu String = String (Länge)u Int : ganze Zahlu UInt : positive ganze Zahlu Float : Gleitkommanzahl 32 Bitu Double : Gleitkommazahl 64 Bitu Fixed (Vorkommastellen,

Nachkommastellen) : Festkommazahlu Booleanu Dateu Time


LE 127

2.3 Attributs Aufzählungstyp { values: W1, W2, W3,

select: 1..n,noAdd}

a. Elementare Klasse (support class) a. Der Typ eines Attributs kann selbst wieder

durch eine Klasse beschrieben werdenb. Kein Eintrag in das Klassendiagramm des

Gesamtmodellsc. In der Regel: Einmalige Definition und

Wiederverwendung bei jedem Projekt


LE 128

2.3 Attributs Beispiele

a. AufzählungstypNotenwertT{values: 1.0., 1.3, 1.7., 2.0., 2.3,

3.0, 3.3, 3.7, 4.0, 5.0,noAdd}

a. Elementare Klassen

NameT

Vorname: StringNachname: String

NoteT

Fach: StringWert: NotenwertT


LE 129

2.3 Attributs Spezifikation der Attributeu Um aus einem OOA-Modell den Prototyp der

Benutzungsoberfläche abzuleiten, sind anzugeben:a. Nameb. Typc. Anfangswertd. Muß-Attribut (mandatory)e. Schlüssel (key)f. Attributwert nicht änderbar (frozen)g. Einheit h. Beschreibung


LE 130

2.3 Attributs Beispiel: Klasse Studentu Matrikelnummer: String(7)

{mandatory, key}u Name: NameT {mandatory}u Geburtsdatum: Date {mandatory}u Immatrikulation: Date

{mandatory, Beschreibung:Datum des Studienbeginns}

u Vordiplom: Date {Beschreibung: Datum derabschließenden Vordiplomprüfung}

u Noten: list of NoteTu Restriktionen: {Geburtsdatum <

Immatrikulation < Vordiplom}


LE 131

2.4 Operations Definitionu Eine Operation beschreibt eine ausführbare

Tätigkeitu Alle Objekte einer Klasse verwenden dieselben

Operationenu Jede Operation kann auf alle Attribute eines

Objekts dieser Klasse direkt zugreifenu Die Menge aller Operationen wird als das

Verhalten der Klasse oder als die Schnittstelleder Klasse bezeichnet


LE 132

2.4 Operations Beispiel

Student

MatrikelnummerNameGeburtsdatumImmatrikulationVordiplomNotenAnzahl

immatrikulieren()exmatrikulieren()drucke Studienbescheinigung()notiere Noten()berechne Durchschnitt()drucke V ordiplomliste()anmelde Praktikum()drucke Prakt.bescheinigung()

Firma

NameOrtAnzahl MitarbeiterBranche


LE 133

2.4 Operations 3 Arten von Operationenu Objektoperation bzw. Operationl drucke Studienbescheinung()l exmatrikulieren()

u Konstruktoroperationl immatrikulieren()

u Klassenoperationl drucke Vordiplomliste()¡ Alle Objekte einer Klasse (Objektverwaltung)

l erhöhe Stundenlohn()¡ Zugriff auf Klassenattribute

Aushilfe

NameAdresseStundenzahlStundenlohn

erhöhe Stundenlohn ()...


LE 134

2.4 Operations Externe und interne Operationenu Externe Operation ...l wird direkt vom Benutzer aktiviertl kann weitere – interne – Operationen

aufrufenu Ziel der Systemanalyse ist es, alle externen

Operationen zu ermittelnu Interne Operation ...l wird von anderen Operationen aktiviertl wird nur dann in das Klassendiagramm

eingetragen, wenn es für das Verständnis notwendig ist


LE 135

2.4 Operations Verwaltungsoperationen u Interne Basisoperationen l new(), delete()l setAttribute(), getAttribute()l link(), unlink(), getlink()

u Externe Verwaltungsoperationenl erfassen()l ändern()l löschen()l erstelleListe()


LE 136

2.5 Assoziations Definitionu Eine Assoziation modelliert Verbindungen

(links) zwischen Objekten einer oder mehrerer Klassen

u Eine reflexive Assoziation besteht zwischen Objekten derselben Klasse

u Assoziationen sind in der Systemanalyse inhärent bidirektional

u Es gibt binäre und höherwertige Assoziationen


LE 137

2.5 Assoziations Beispiel

:Kunde

Name = Hans Meyer

:Konto

Kontonr = 4711Art = GeschäftEröffnung = 4.7.93

:Konto

KontoNr = 1234Art = PrivatEröffnung = 8.9.93

Objektdiagramm

*Kunde

Name

Konto

KontonrArtEröffnung

1

besitzt

Klassendiagramm


LE 138

2.5 Assoziations Notation UMLu Binäre Assoziationl Linie zwischen einer oder zwei Klassen l An jedem Ende der Linie steht die Wertigkeit

bzw. Kardinalität (multiplicity)

Klasse1

Attribut

Operation()

Klasse

Attribut

Operation()

Klasse2

Attribut

Operation()

k1 k2

k1

k2

reflexiveAssoziation


LE 139

2.5 Assoziations Notation Kardinalität UML

genau 1

0 bis 1

0 bis viele

3 bis viele

0 bis 2

genau 2

2, 4 oder 6

nicht 6, 7 oder 9

1

0..1

*

3..*

0..2

2

2, 4, 6

1..5, 8, 10..*


LE 140

2.5 Assoziations Name einer Assoziationu Beschreibt meistens nur eine Richtung der

Assoziationu Ein schwarzes Dreieck gibt die Leserichtung anu Name darf fehlen, wenn die Bedeutung der

Assoziation offensichtlich ist

*Kunde

Name

Konto


1

besitzt


LE 141

2.5 Assoziations Rollennameu Beschreibt Bedeutung eines Objekt in einer

Assoziation u Binäre Assoziationen besitzen maximal zwei

Rollenu Er wird an das Ende der Assoziation geschrieben

bei der Klasse, deren Bedeutung in der Assoziation sie beschreibt

u Tragen zur Verständlichkeit des Modells mehr bei als der Name der Assoziation


LE 142

2.5 Assoziationu Rollenname ist nicht optional ...l wenn zwischen zwei Klassen mehr als eine

Assoziation bestehtl bei reflexiven Assoziationen

Kunde

Name

Angestellter

NameGehaltPosition

Konto


1 1..*

Chef

Mitarbeiter

Kontoinhaber

* 1..*

Kontoberechtigter

0..1

*

:Konto

:Kunde

:Kunde Kontoinhaber

Konto-berechtigter

:Angestellter :Angestellter

:Angestellter

ChefMit-arbeiter

ChefMit-arbeiter

:Angestellter

:Angestellter

ChefMit-arbeiter

ChefMit-arbeiter


LE 143

2.5 Assoziations Abgeleitete Assoziation (derived association)

*

Professor Vorlesung

Student/ist Hörer von

*hört

*

*

liest1 *

:Professor :Vorlesung

:Vorlesung

:Student

:Student


LE 144

2.5 Assoziations 3 Arten von Assoziationen in der UMLu Einfache Assoziation (ordinary association)u Aggregation (aggregation)u Komposition (composite aggregation)

Hypertext-Buch

TitelErscheinungsjahr

Kapitel

AutorAnzahl Seiten

Verzeichnis

NameMS-DOS-NameErstellung

Datei

NameMS-DOS-NameErstellungletz te Änderungletz ter Zugriff

*

*

Aggregation

Aggregat-klasse

Teil-klasse

Komposition1

*


LE 145

2.5 Assoziations Aggregationu Läßt sich durch ist Teil von bzw. besteht aus

beschreiben (Ganzes und Teile, whole part)

s Komposition u »starke« Aggregationu Kardinalität der Aggregatklasse <= 1 u Dynamische Semantik des Ganzen gilt auch für

seine Teile (propagation semantics)u Wird das Ganze gelöscht, werden automatisch

seine Teile gelöscht (they live and die with it)


LE 146

2.6 Vererbungs Definition u Vererbung (generalization) ist eine Beziehung

zwischen einer allgemeinen Klasse (Basisklasse) und einer spezialisierten Klasse

u Die spezialisierte Klasse ist vollständig konsistent mit der Basisklasse, enthält aber zusätzliche Informationen (Attribute, Operationen, Assoziationen)

u Allgemeine Klasse = Oberklasse (super class)u Spezialisierte Klasse = Unterklasse (sub class)


LE 147

2.6 Vererbung

Beschäftigungen

Hilfskraft

drucke Arbeitszeiten()

MatrikelnrImmatrikulation

Student

drucke Ausweis()

PersonalnrGehaltBank

Angestellter

überweise Gehalt()

NameAdresseGeburtsdatum

Person

drucke Adresse()

Hilfskraft

MatrikelnrNameAdresseGeburtsdatumImmatrikulationBeschäftigungen

drucke Adresse()drucke Ausweis()drucke Arbeitszeiten()

Student

MatrikelnrNameAdresseGeburtsdatumImmatrikulation

drucke Adresse()drucke Ausweis()

Angestellter

PersonalnrNameGeburtsdatumGehaltBank

drucke Adresse()überweise Gehalt()


LE 148

2.6 Vererbungs Notation UMLu Weißes bzw. transparentes Dreieck bei der

Basisklasse

Klasse1

Klasse2 Klasse3

Klasse1{abstract}

Klasse2 Klasse3


LE 149

2.6 Vererbungs Überschreiben von Operationenu Unterklassen können das Verhalten ihrer

Oberklassen verfeinern, redefinieren bzw. überschreiben (redefine, override)

Kontonum merKontostand

K onto

buchen()

Sparkonto

buchen()


LE 150

2.7 Pakets Definitions Das Paket (package) ...u faßt Modellelemente (z.B. Klassen) zusammenu kann selbst Pakete enthalten

u Das vollständige System kann als ein großes Paket aufgefaßt werden

s Beispiel: Warenwirtschaftssystem

Einkauf Verkauf Produktion Material-Wirtschaft


LE 151

2.7 Pakets Notation UMLu Paketname muß im gesamten System

eindeutig sein

Paket1

Paket2

System

Paket3

Paket2Paket1


LE 152

2.7 Pakets Paket und Klasseu Jede Klasse (allgemeiner: jedes

Modellelement) gehört zu höchstens einem Paket

u Es kann in mehreren anderen Paketen darauf verwiesen werden

u Ein Paket definiert einen Namensraum für alle enthaltenen Klassenl Paket::Klasse l Paket1::Paket11::Paket111::Klasse


LE 153

CRC-Kartes Name der Klasse (class)s Verantwortlichkeiten (responsibilities) d. Klasses Notwendige Klassen (collaborations)

Responsibilitiesverwaltet eine Bestellungdelegiert Aufgaben anBestellpositionen

CollaborationsBestellposition

Class Bestellung

Bestellung

1..*NummerDatum

erfassen()drucken()

1

Bestellposition

ArtikelnummerBezeichnungAnzahl


LE 154

Inhalt: UML - Dynamische Konzeptes 2.8 Geschäftsprozeßs 2.9 Botschafts 2.10 Szenarios 2.11 Zustandsautomat


LE 155

2.8 Geschäftsprozeßs Begriff des use case von Jacobson in die

Objektorientierung eingeführtu use case in einem Informationssysteml Sequenz von zusammengehörenden

Transaktionen, die von einem Akteur im Dialog mit einem System durchgeführt wird, um ein Ergebnis von meßbarem Wert zu erhalten

l Alle use cases zusammen dokumentieren alle Möglichkeiten der Benutzung des Systems (usecase model)

u use case in einem Unternehmenl Sequenz von unternehmensinternen Aktivitäten,

die durchgeführt werden, um die Wünsche eines Kunden zu befriedigen


LE 156

2.8 Geschäftsprozeßs Problematik in der Analyseu Nicht abzusehen, ob alle Aufgaben durch die

Software abgedeckt werden oder ob auch organisatorische Schritte enthalten sind

s Zielu Spezifikation der ergebnisorientierten

Arbeitsabläufe

s Definitionu Ein Geschäftsprozeß (use case) besteht aus

mehreren zusammenhängenden Aufgaben, die von einem Akteur durchgeführt werden, um ein Ziel zu erreichen bzw. ein gewünschtes Ergebnis zu erstellen


LE 157

2.8 Geschäftsprozeßs Wer ist der Akteur (actor) ?u Rolle, die ein Benutzer des Systems spieltu Hat einen Einfluß auf das Systemu Ist häufig eine Personu Kann auch Organisationseinheit oder anderes

System seinu Befindet sich immer außerhalb des Systems


LE 158

2.8 Geschäftsprozeßs Wer ist der Akteur (actor)?

Kunde Lieferant

Kundensachbearbeiter

Lagersachbearbeiter

Lieferantensachbearbeiter

Buchhaltung

Handelshaus(System =Unternehmen)

Auftrags-undBestellwesen(Software-system)


LE 159

2.8 Geschäftsprozeßs Spezifikationsschablone (use case template)u Geschäftsprozeß: Name des Geschäftsprozessesu Ziel: globale Zielsetzung bei erfolgreicher

Ausführung des Geschäftsprozessesu Kategorie:l primär (notwendig, häufig benötigt)l sekundär (notwendig, selten benötigt)l optional (nützlich, nicht unbedingt notwendig)

u Vorbedingung: erwarteter Zustand, bevor der Geschäftsprozeß beginnt

u Nachbedingung Erfolgu Nachbedingung Fehlschlagu Akteure


LE 160

2.8 Geschäftsprozeßs Spezifikationsschabloneu Auslösendes Ereignisu Beschreibung: Hier wird der Standardfall

beschriebenl 1 Erste Aktionl 2 Zweite Aktion

u Erweiterungen:l 1a Erweiterung des Funktionsumfangs der

ersten Aktionu Alternativen:l 1a Alternative Ausführung der ersten Aktion


LE 161

2.8 Geschäftsprozeßs Geschäftsprozeß:Auftrag ausführenu Ziel: Ware an Kunden geliefert u Vorbedingung: -u Nachbedingung Erfolg: Ware

ausgeliefert (auch Teillieferungen), Rechnungskopie bei Buchhaltung

u Nachbedingung Fehlschlag: Mitteilung an Kunden, daß nichts lieferbar

u Akteure: Kundensachbearbeiter, Lagersachbearbeiter, Buchhaltung

u Auslösendes Ereignis: Bestellung des Kunden liegt vor


LE 162

2.8 Geschäftsprozeßu Beschreibung:l 1 Kundendaten abrufenl 2 Lieferbarkeit prüfenl 3 Rechnung erstellenl 4 Auftrag vom Lager ausführen lassenl 5 Rechnungskopie an Buchhaltung geben

u Erweiterung:l 1a Kundendaten aktualisieren

u Alternativen:l 1a Neukunden erfassenl 3a Rechnung mit Nachnahme l 3b Rechnung mit Bankeinzug erstellen


LE 163

2.8 Geschäftsprozeßs Notation Geschäftsprozeßdiagramm

(use case diagram) UML

System

Geschäfts-prozeß2

Geschäfts-prozeß3

Geschäfts-prozeß1

Akteur3

Akteur1

Akteur2


LE 164

2.8 Geschäftsprozeßs Geschäftsprozeßdiagramm für ein

Informationssystem

Warenwirtschaftssystem

Lagerverwalten

Auftragausführen

BuchhaltungKunden-sachbearbeiter

Lieferanten-sachbearbeiter

Lager-sachbearbeiter


LE 165

2.8 Geschäftsprozeßs extends-Beziehungu Erweiterung eines vorhandenen GP

Auftragdurchführen

Auftragmit Nachlieferung

ausführen

«extends»

Wareneingangaus Einkaufbearbeiten

Wareeinlagern

Wareneingangaus Produktion

bearbeiten

«uses» «uses»

s uses-Beziehungu Zwei GP besitzen gemeinsames Verhalten


LE 166

2.8 Geschäftsprozeßs Aktivitätsdiagramm (activity diagram) u Beispiel: Auftrag ausführen

Kundendaten abrufen

Lieferbarkeit prüfen

Rechnung erstellen

Auftrag vom Lagerausführen lassen

Rechnungskopie anBuchhaltung geben

1. Schritt

2. Schritt

3. Schritt

Reihenfolgeaus fachlicherSichtirrelevant.


LE 167

2.9 Botschafts Definition u Eine Botschaft (message, Nachricht) ist die

Aufforderung eines Senders (client) an einen Empfänger (server, supplier) eine Dienstleistung zu erbringen

u Empfänger interpretiert diese Botschaft und führt eine Operation (gleichen Namens) aus

u Sender der Botschaft weiß nicht, wie die entsprechende Operation ausgeführt wird

u Protokoll (protocol) der Klassel Menge der Botschaften, auf die Objekte

einer Klasse reagieren können


LE 168

2.9 Botschafts Beispiel

Vertrag

NummerArtJahresbeitragVersicherungs sum meAbsc hlußdatum

Versicherter

NummerNameAdresseGeburtsdatum

berechneBeit rag()

1 *

1

*

Filiale

BezeichnungLeiter

berechneDurchs chnit tsumsatz()

berechneDurchschnit tsumsatz()

:Filiale berechneBeit rag() :Versicherter

:Vertrag

getJahresbeitrag()


LE 169

2.10 Szenario s Definition u Ein Szenario (scenario) ist eine Sequenz von

Verarbeitungsschritten, die unter bestimmten Bedingungen auszuführen ist

u Diese Schritte sollen das Hauptziel des Akteurs realisieren und ein entsprechendes Ergebnis liefern

u Sie beginnen mit dem auslösenden Ereignis und werden fortgesetzt bis das Ziel erreicht ist oder aufgegeben wird


LE 170

2.10 Szenarios Geschäftsprozeß und Szenariou Ein Geschäftsprozeß wird durch eine

Kollektion von Szenarios dokumentiertu Jedes Szenario wird durch eine oder mehrere

Bedingungen definiert, die zu einem speziellen Ablauf des Geschäftsprozesses führen

u Zwei Kategorien von Szenarios:l Szenarios, die eine erfolgreiche Bearbeitung

des Geschäftsprozesses beschreibenl Szenarios, die zu einem Fehlschlag führen


LE 171

2.10 Szenarios Beispiels Szenarios zum Geschäftsprozeß Auftrag

bearbeitenu Auftrag für einen Neukunden bearbeiten und

mindestens ein Artikel ist lieferbaru Auftrag bearbeiten, wenn Kunde bereits

existiert und mindestens ein Artikel lieferbar ist

u Auftrag bearbeiten, wenn der Kunde bereits existiert, sich seine Daten geändert haben und mindestens ein Artikel lieferbar ist


LE 172

2.10 Szenarios Notation u Szenarios werden durch Interaktionsdiagramme

(interaction diagrams) modelliertu UML bietet zwei Arten von Diagrammen anl Sequenzdiagramm (sequence diagram)l Kollaborationsdiagramm (collaboration

diagram)


LE 173

2.10 Szenarios Notation Sequenzdiagramm UMLAkteur

Objektwird erzeugt

op()

Objektwirdgelöscht

op2()

:C2 :C3

op1()

op3()

Botschaft

Objekt-linie

:C1


LE 174

2.10 Szenarios Sequenzdiagrammu Besitzt zwei Dimensionenl Die Vertikale repräsentiert die Zeitl Auf der Horizontalen werden die Objekte

eingetragenu Jedes Objekt wird dargestellt durch l Objektsymbol undl vertikale gestrichelte Linie (Objektlinie)

u Bedingung (condition)l [<Bedingung>] Operation()

u Wiederholung (iteration)l * Operation() oder *[Bedingung] Op()


LE 175

2.10 Szenarios Auftrag für einen Neukunden bearbeitenu Klassendiagramm

Kunde

erfassen()

Artikel

istLieferbar()

Auftrag

erfassen()erstelleRechnung()

1

*

1 *

1 * Auftragsposition

BestellmengeLiefermenge


LE 176

2.10 Szenario

:Auftrags-position

:Auftragerfassen()

erfassen()

erstelleRechnung()

[nichtLieferbar]setLiefermenge()

istLieferbar()

setBestellmenge()

new()

:Kunde

:Artikel


LE 177

2.10 Szenarios Auftrag für existierende Kunden bearbeiten

:Artikel

erfassen()

abrufen()

erstelleRechnung()

istLieferbar()

:Kunde

[Änderung]aktualisieren()

:Auftrag


LE 178

2.10 Szenarios Notation Kollaborationsdiagramm UMLu {new} Objekt wird erzeugtu {destroyed} Objekt wird gelöscht u {transient} Objekt wird sowohl erzeugt als

auch gelöscht

:C3

:C1{transient} 2: op2()

op()

1: op1() 2.1: op3()

:C2


LE 179

2.10 Szenarios Kollaborationsdiagrammu Permanente Objektverbindungenl Assoziationen

u Temporäre Objektverbindungen ...l bestehen nur für die Dauer der

Kommunikationl liegen vor, wenn das angesprochene

Empfängerobjekt auch ohne Vorliegen einer Assoziation vom Sender eindeutig identifiziert werden kann

l werden mit «temp» gekennzeichnet

u Implizite Objektverbindung (self link)l Jedes Objekt kann jederzeit Botschaften an

sich selbst schicken


LE 180

2.10 Szenarios Sequenz- vs. Kollaborationsdiagramm

:KlasseKlasse

:Klasse

Klassen-operation()

Konstruktor-operation()

Objekt-operation()

Klasse

:Klasse{new}

Konstruktor-operation()

:Klasse

Klassen-operation()

Objekt-operation()


LE 181

2.11 Zustandsautomats Definition u Ein Zustandsautomat (finite state machine)

besteht aus Zuständen und Zustandsübergängen (Transitionen)

u Ein Zustand ist eine Zeitspanne, in der ein Objekt auf ein Ereignis wartet

u Ein Ereignis tritt immer zu einem Zeitpunkt auf und besitzt keine Dauer


LE 182

2.11 Zustandsautomats Beispiel: Lebenszyklus der Klasse Buch

präsent

ausgeliehen

vorbestellt

after(Abholfrist vorbei)

Buch defekt/ entfernen()

Buch verloren/ entfernen()

Ausleihwunsch/ ausleihen()

Leser gibt Buch zurück/ zurückgeben()

Leser gibt Buch zurück/ zurückgeben()

Ausleihwunsch/ vorbestellen()

Leserholt Buch ab/ ausleihen()

neues Buch liegt vor/ erfassen()

erfassen()ausleihen()zurückgeben()vorbestellen()entfernen()

Buch

zurAbholung

bereit


LE 183

2.11 Zustandsautomats Notation UML

Zustand1 Zustand2do/ Aktivität

Zustand4

entry/ Aktion3exit/ Aktion4

implizitesEreignis

Anfangszustand

Ereignis1

Ereignis3[Wächter] Zustand3

Endzustand

Transition

Ereignis2/ Aktion2Ereignis4


LE 184

2.11 Zustandsautomats Zustandu Zustandsname ist optionalu Zustände ohne Namen heißen anonyme Zustände

und sind alle voneinander verschiedenu Zustandsname soll kein Verb seinu Innerhalb einer Klasse muß jeder Zustandsname

eindeutig sein

s Anfangszustandu Pseudozustand, der mit einem echten Zustand

durch eine Transition verbunden ist

s Endzustandu Objekt hört auf, zu existieren


LE 185

2.11 Zustandsautomats Verarbeitung in einem Zustandu Aktionl Ist atomarl Terminiert selbständigl entry-Aktionl exit-Aktion

u Aktivitätl Beginnt, wenn Objekt Zustand einnimmt und

endet, wenn es ihn verläßtl Start Aktion + Stop Aktion


LE 186

2.11 Zustandsautomats Zustandsübergang (Transition) u Verbindet zwei Zuständeu Gesprochen: die Transition »feuert«u Wird durch ein Ereignis ausgelöstu Kann mit einer Aktion verbunden sein

s Ereignis kann seinu Bedingung, die wahr wird, z.B.

when (Temperatur > 100 Grad)u Signal, z.B. rechte Maustaste gedrücktu Botschaft (Aufruf einer Operation)u verstrichene Zeit, z.B. after(10 sec) u Eintreten eines bestimmten Zeitpunkts, z.B.

when(1.1.2000)


LE 187

2.11 Zustandsautomats Wächteru Ereignis kann mit Wächter (guard condition)

kombiniert werdenu Die Transition feuert nur dann, wenn ...l das zugehörende Ereignis eintritt undl die im Wächter spezifizierte Bedingung

erfüllt ist

s Implizites Ereignisu Transition wird ausgeführt, wenn die mit dem

Zustand verbundene Verarbeitung beendet ist


LE 188

2.11 Zustandsautomats Beispiel: Lebenszyklus der Klasse Tank

leer

füllenddo/ füllen()

voll

leerenddo/ leeren()

neue Füllhöhe/ einstellenFüllhöhe()

Tank füllen

when(voll)

Tank leeren

when(leer)

füllen()leeren()einstellenFüllhöhe()

Tank


LE 189

2.11 Zustandsautomats Beispiel: Kartenautomat in einem Parkhaus

bereit

wartet aufGeld

wartet aufQuittung

Karte/ einziehen Karte

Geld eingeworfen [reicht aus]/ ausgeben Karte

Geld eingeworfen [reicht nicht]/ anzeigen Restbetrag

when(Karte korrekt)/ anzeigen Gesamtbetrag

when(Karte falsch)/ auswerfen Karte

after(5 sec)

Kartenautomat

bezahlen Parkgebühr()

Quittung anfordern/ drucke Quittung

entry/ prüfe Karte


LE 190

ausgeschaltet

unterbrochen

Einschalten/ speichern

Geschwindigkeit()Ausschalten

Bremsen

Wiederaufnahme

AusschaltenohneVerfeinerung

regelnd

do/ einhalten Soll-Geschwindigkeit()

2.11 Zustandsautomat

ausgeschaltet

Einschalten/ speichern Geschwindigkeit() Ausschalten

eingeschaltet

mitVerfeinerung

unterbrochenBremsen

Wiederaufnahme

regelnd

do/ einhalten Soll-Geschwindigkeit()

speichern Geschwindigkeit()einhalten Soll-Geschwindigkeit()

Tempomat


LE 191

2.11 Zustandsautomats Aktivitätsdiagramm (activity diagram)

[Bedingung1b]

Syn-chronisation

[Bedingung1a] [Bedingung2a]

[Bedingung2b]

Entscheidung

Splitting

Verarbeitung4 Verarbeitung6

Verarbeitung3

Verarbeitung5

Verarbeitung1

Verarbeitung2


LE 192

2.11 Zustandsautomats Aktivitätsdiagramm (activity diagram)u Sonderfall des Zustandsdiagrammsu (Fast) alle Zustände sind mit Verarbeitung

verbundenu Zustand wird verlassen, wenn Verarbeitung

beendet istu Wächter (guard condition) spezifiziert

Verzweigungen im Kontrollfluß u Spezifikation von parallelen Abläufen

Documents

OM – ObjektorientierteObjektorientierte ... · OM – ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung LE 1 7 1.2 Objektorientierte Analyse s Das statische