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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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)
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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)
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
{...}{...}
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
LE 115
Inhalt: UML - Statische Konzepte2.1 Objekt2.2 Klasse2.3 Attribut2.4 Operation2.5 Assoziation2.6 Vererbung2.7 PaketCRC Karten
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
LE 116
2.1 Objekts Beispiel: Mitarbeiter-Objekt
einstellen ()
Personalnr 1234Name MüllerGehalt 5500
druckeAusweis ()
erhöheGehalt ()
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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()
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
LE 119
2.2 Klasses Notation UML
Namensfeld
Attributliste
Operationsliste
Klasse
Attribut. . .
Operation(). . .
Operation(). . .
Klasse
Klasse
Klasse
Attribut. . .
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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.
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
LE 122
2.3 Attributs Notation UML
Klasse
AttributKlassenattribut/abgeleitetes Attribut
At tribut: Typ = Anfangswert{Merkmal1, Merkmal2, ...}
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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}
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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]
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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}
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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 ()...
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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()
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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..*
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
KontonrArtEröffnung
1
besitzt
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
KontonrArtEröffnung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
LE 143
2.5 Assoziations Abgeleitete Assoziation (derived association)
*
Professor Vorlesung
Student/ist Hörer von
*hört
*
*
liest1 *
:Professor :Vorlesung
:Vorlesung
:Student
:Student
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
*
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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)
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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)
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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()
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
LE 148
2.6 Vererbungs Notation UMLu Weißes bzw. transparentes Dreieck bei der
Basisklasse
Klasse1
Klasse2 Klasse3
Klasse1{abstract}
Klasse2 Klasse3
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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()
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
LE 151
2.7 Pakets Notation UMLu Paketname muß im gesamten System
eindeutig sein
Paket1
Paket2
System
Paket3
Paket2Paket1
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
LE 154
Inhalt: UML - Dynamische Konzeptes 2.8 Geschäftsprozeßs 2.9 Botschafts 2.10 Szenarios 2.11 Zustandsautomat
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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)
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
LE 164
2.8 Geschäftsprozeßs Geschäftsprozeßdiagramm für ein
Informationssystem
Warenwirtschaftssystem
Lagerverwalten
Auftragausführen
BuchhaltungKunden-sachbearbeiter
Lieferanten-sachbearbeiter
Lager-sachbearbeiter
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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.
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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()
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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)
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
LE 173
2.10 Szenarios Notation Sequenzdiagramm UMLAkteur
Objektwird erzeugt
op()
Objektwirdgelöscht
op2()
:C2 :C3
op1()
op3()
Botschaft
Objekt-linie
:C1
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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()
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
LE 175
2.10 Szenarios Auftrag für einen Neukunden bearbeitenu Klassendiagramm
Kunde
erfassen()
Artikel
istLieferbar()
Auftrag
erfassen()erstelleRechnung()
1
*
1 *
1 * Auftragsposition
BestellmengeLiefermenge
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
LE 176
2.10 Szenario
:Auftrags-position
:Auftragerfassen()
erfassen()
erstelleRechnung()
[nichtLieferbar]setLiefermenge()
istLieferbar()
setBestellmenge()
new()
:Kunde
:Artikel
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
LE 177
2.10 Szenarios Auftrag für existierende Kunden bearbeiten
:Artikel
erfassen()
abrufen()
erstelleRechnung()
istLieferbar()
:Kunde
[Änderung]aktualisieren()
:Auftrag
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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()
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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)
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
LE 191
2.11 Zustandsautomats Aktivitätsdiagramm (activity diagram)
[Bedingung1b]
Syn-chronisation
[Bedingung1a] [Bedingung2a]
[Bedingung2b]
Entscheidung
Splitting
Verarbeitung4 Verarbeitung6
Verarbeitung3
Verarbeitung5
Verarbeitung1
Verarbeitung2
OM OM –– ObjektorientierteObjektorientierte SoftwareentwicklungSoftwareentwicklung
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