1.2 Objektorientierte Analyse Ziel der Analyse

Transkript

1 1 1.2 Objektorientierte Analyse Ziel der Analyse Wünsche und Anforderungen eines Auftraggebers an ein neues Softwaresystem ermitteln und beschreiben Modell des Fachkonzepts erstellen, das konsistent, vollständig, eindeutig und realisierbar ist 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 Objektorientierte Analyse Produkte der Analysephase Pflichtenheft das Einstiegsdokument OOA-Modell das Fachkonzept Prototyp der Benutzungsoberfläche die Visualisierung des Fachkonzepts

2 3 1.2 Objektorientierte Analyse Pflichtenheft Umgangssprachliche Beschreibung dessen, was das zu realisierende System leisten soll Weniger detailliert als das OOA-Modell Enthält auch einige Informationen, die nicht im OOA-Modell dargestellt werden Zwei Zielsetzungen Einstiegsdokument in das Projekt für alle, die das System später pflegen und warten sollen Ausgangsbasis für die objektorientierte Modellbildung Es ist nicht das Ziel, anhand des Pflichtenhefts, das System zu implementieren Objektorientierte Analyse Gliederungsschema Pflichtenheft 1 Zielbestimmung Formulieren Sie Ziele und keine Funktionen 1.1 Muß-Kriterien 1.2 Kann-Kriterien 1.2 Abgrenzungskriterien 2 Einsatz 2.1 Anwendungsbereiche 2.2 Zielgruppen 2.3 Betriebsbedingungen

3 5 1.2 Objektorientierte Analyse 3 Umgebung 3.1 Software 3.2 Hardware 3.3 Orgware 4 Funktionalität typische Arbeitsabläufe wichtige Selektionen 5 Daten 6 Leistungen 7 Benutzungsoberfläche 8 Qualitätsziele 9 Ergänzungen Objektorientierte Analyse OOA-Modell Assoziation Geschäftsprozeß Szenario Vererbung Statische Konzepte Paket Botschaft Dynamische Konzepte Zustandsautomat Attribut Operation Basiskonzepte Statisches Modell Objekt Klasse Dynamisches Modell

4 7 1.2 Objektorientierte Analyse Das statische Modell beschreibt... die Klassen des Fachkonzepts die Assoziationen (Beziehungen) zwischen den Klassen die Vererbungstrukturen die Attribute der Klassen (Daten des Systems) die Bildung von Paketen (Teilsysteme) Objektorientierte Analyse Das dynamische Modell zeigt Funktionsabläufe Geschäftsprozesse beschreiben die durchzuführenden Aufgaben auf einem sehr hohen Abstraktionsniveau Szenarios zeigen, wie Objekte miteinander kommunizieren, um eine bestimmte Aufgabe zu erledigen Zustandsautomaten beschreiben die Reaktionen eines Objekts auf verschiedene Ereignisse (= Botschaften)

5 9 1.2 Objektorientierte Analyse Der Prototyp der Benutzungsoberfläche... ist ein ablauffähiges Programm, das alle Attribute des OOA-Modells auf der Benutzungsoberfläche darstellt besitzt weder Anwendungsfunktionen noch die Fähigkeit, Daten zu speichern besteht aus Fenstern, Dialogen Menüs usw. hat den Zweck, das erstellte OOA-Modell mit dem zukünftigen Benutzer oder einem Repräsentanten zu evaluieren sollte möglichst die vollständige Benutzungsoberfläche des Fachkonzepts enthalten Objektorientierte Analyse Grundprinzip der Softwareentwicklung Trennung von Fachkonzept und Benutzeroberfläche Im Fachkonzept wird festgelegt, welche Informationen auf dem Bildschirm sichtbar sind Bei der Benutzungsoberfläche wird festgelegt, in welchem Format sie dargestellt werden

6 Objektorientierter Entwurf Entwurfsziel Weitgehende Entkopplung von Fachkonzept, Benutzungsoberfläche und Datenhaltung Realisierung durch Drei-Schichten-Architektur Einfluß durch... verwendetes GUI (Graphical User Interface) Bestimmt Aussehen der Benutzungsoberfläche verwendete Form der Datenhaltung Relationale Datenbank Objektorientierte Datenbank Flache Dateien Objektorientierter Entwurf Drei Schichten-Architektur Reale Welt OOA-Modell OOA OOD Titel Buch OOD-Modell Benutzungsoberfläche Fachkonzept Datenhaltung BuchView Buch BuchFile Titel C++/Java class BuchView {...} class Buch {String Titel;...} class BuchFile {...}

7 Objektorientierter Entwurf Analyse Entwurf OK Prototyp OOD-Modell OOA-Modell a/b Fachkonzept Datenhaltung Relat. DB OO DB Abgrenzung von Analyse und Entwurf Pflichtenheft Benutzungsoberfläche Netzverteilung Klassenbibliotheken C++ bzw. Java-Programme Objektorientierter Entwurf Produkt der Entwurfsphase: OOD-Modell Abbild des späteren Programms Statisches Modell Enthält alle Architektur-Klassen des Programms Pakete zur Modellierung von Teilsystemen und Darstellung der verschiedenen Schichten Dynamisches Modell Übersichtliche Beschreibung der komplexen Kommunikation zwischen Objekten

8 15 Inhalt: UML - Statische Konzepte 2.1 Objekt 2.2 Klasse 2.3 Attribut 2.4 Operation 2.5 Assoziation 2.6 Vererbung 2.7 Paket CRC Karten Objekt Beispiel: Mitarbeiter-Objekt einstellen () Personalnr 1234 Name Müller Gehalt 5500 erhöhe Gehalt () drucke Ausweis ()

9 Klasse Definition Eine Klasse... definiert für eine Kollektion von Objekten deren Struktur (Attribute) Verhalten (Operationen) und Beziehungen (relationships) besitzt einen Mechanismus, um neue Objekte zu erzeugen (object factory) Jedes erzeugte Objekt gehört zu genau einer Klasse Unter den Beziehungen sind Assoziationen und Vererbungsstrukturen zu verstehen Klasse Beispiel :Mitarbeiter Personalnr = 1234 Name = Müller Gehalt = 5500 :Mitarbeiter Personalnr = 5678 Name = Meyer Gehalt = 5100 Mitarbeiter Personalnr Name Gehalt einstellen() erhöhe Gehalt() drucke Ausweis()

10 Klasse Notation UML Attribut... Klasse Namensfeld Attributliste Attribut... Klasse Operation()... Klasse Operationsliste Klasse Operation() Klasse e. Klassendiagramm Klassensymbole werden zusammen mit weiteren Symbolen (z.b. Assoziationen und Vererbung) in das Klassendiagramm eingetragen Beschreibung des statischen Modells des Systems Bei großen Systemen mehrere Klassendiagramme erstellen

11 Attribut a. Definition Attribute beschreiben die Daten, die von den Objekten einer Klasse angenommen werden können Jedes Attribut ist von einem bestimmten Typ Alle Objekte einer Klasse besitzen dieselben Attribute, jedoch unterschiedliche Attributwerte Student Matrikelnr Name Geburtsdatum Immatrikulation Vordiplom Noten :Student Matrikelnr = Name = (Hans, Mey er) Geburtsdatum = Immatrikulation = Noten = ((2.3, Analy sis), (1.3, Informatik)) Das Attribut Vordiplom besitzt - noch - keinen Wert Attribut Notation UML Klasse Attribut Klassenattribut /abgeleit etes Attribut At tribut: Ty p = Anfangswert {Merkmal1, Merkmal2,...}

12 Attribut a. Abgeleitetes Attribut (derived attribute) Der Wert kann jederzeit aus anderen Attributwerten berechnet werden Ein abgeleitetes Attribut darf nicht direkt geändert werden Kennzeichnung mit dem Präfix / Person Geburtsdatum /Alter Attribut d. Restriktion (constraint) Beziehung zwischen Attributwerten eines Objekts, die während der Ausführung des Systems unverändert erhalten bleiben muß Restriktion = Invariante = Zusicherung, die immer wahr sein muß Beispiele: Klasse Student {Vordiplom > Immatrikulation > Geburtsdatum} Klasse Artikel {Verkaufspreis >= 1.5 * Einkaufspreis}

13 Attribut a. Attributtyp Jedes Attribut wird durch einen Typ beschrieben Verwendung folgender Typen zur Erstellung eines standardisierten OOA-Modells Standardtypen Aufzählungstypen (elementare) Klassen list of Typ, wobei Typ ein beliebiger Typ sein kann. Typ = [Standardtyp Aufzählungstyp Klasse list of Typ] Attribut d. Standardtypen String = String (Länge) Int : ganze Zahl UInt : positive ganze Zahl Float : Gleitkommanzahl 32 Bit Double : Gleitkommazahl 64 Bit Fixed (Vorkommastellen, Nachkommastellen) : Festkommazahl Boolean Date Time

14 Attribut 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 werden b. Kein Eintrag in das Klassendiagramm des Gesamtmodells c. In der Regel: Einmalige Definition und Wiederverwendung bei jedem Projekt Attribut Beispiele a. Aufzählungstyp NotenwertT {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: String Nachname: String NoteT Fach: String Wert: NotenwertT

15 Attribut Spezifikation der Attribute Um aus einem OOA-Modell den Prototyp der Benutzungsoberfläche abzuleiten, sind anzugeben: a. Name b. Typ c. Anfangswert d. Muß-Attribut (mandatory) e. Schlüssel (key) f. Attributwert nicht änderbar (frozen) g. Einheit h. Beschreibung Attribut Beispiel: Klasse Student Matrikelnummer: String(7) {mandatory, key} Name: NameT {mandatory} Geburtsdatum: Date {mandatory} Immatrikulation: Date {mandatory, Beschreibung:Datum des Studienbeginns} Vordiplom: Date {Beschreibung: Datum der abschließenden Vordiplomprüfung} Noten: list of NoteT Restriktionen: {Geburtsdatum < Immatrikulation < Vordiplom}

16 Operation Definition Eine Operation beschreibt eine ausführbare Tätigkeit Alle Objekte einer Klasse verwenden dieselben Operationen Jede Operation kann auf alle Attribute eines Objekts dieser Klasse direkt zugreifen Die Menge aller Operationen wird als das Verhalten der Klasse oder als die Schnittstelle der Klasse bezeichnet Operation Beispiel Student Matrikelnummer Name Geburtsdatum Immatrikulation Vordiplom Noten Anzahl Firma Name Ort Anzahl Mitarbeiter Branche immatrikulieren() exmatrikulieren() drucke Studienbescheinigung() notiere Noten() berechne Durchschnitt() drucke V ordiplomliste() anmelde Praktikum() drucke Prakt.bescheinigung()

17 Operation 3 Arten von Operationen Objektoperation bzw. Operation drucke Studienbescheinung() exmatrikulieren() Konstruktoroperation immatrikulieren() Klassenoperation drucke Vordiplomliste() Alle Objekte einer Klasse (Objektverwaltung) erhöhe Stundenlohn() Zugriff auf Klassenattribute Aushilfe Name Adresse Stundenzahl Stundenlohn erhöhe Stundenlohn () Operation Externe und interne Operationen Externe Operation... wird direkt vom Benutzer aktiviert kann weitere interne Operationen aufrufen Ziel der Systemanalyse ist es, alle externen Operationen zu ermitteln Interne Operation... wird von anderen Operationen aktiviert wird nur dann in das Klassendiagramm eingetragen, wenn es für das Verständnis notwendig ist

18 Operation Verwaltungsoperationen Interne Basisoperationen new(), delete() setattribute(), getattribute() link(), unlink(), getlink() Externe Verwaltungsoperationen erfassen() ändern() löschen() erstelleliste() Assoziation Definition Eine Assoziation modelliert Verbindungen (links) zwischen Objekten einer oder mehrerer Klassen Eine reflexive Assoziation besteht zwischen Objekten derselben Klasse Assoziationen sind in der Systemanalyse inhärent bidirektional Es gibt binäre und höherwertige Assoziationen

19 Assoziation Beispiel Objektdiagramm :Kunde Name = Hans Meyer :Konto Kontonr = 4711 Art = Geschäft Eröffnung = :Konto KontoNr = 1234 Art = Privat Eröffnung = Klassendiagramm Name Kunde 1 besitzt * Kontonr Art Eröffnung Konto Assoziation Notation UML Binäre Assoziation Linie zwischen einer oder zwei Klassen An jedem Ende der Linie steht die Wertigkeit bzw. Kardinalität (multiplicity) Klasse1 Klasse2 Attribut k1 k2 Attribut Operation() Operation() Klasse Attribut Operation() k2 k1 reflexive Assoziation

20 Assoziation Notation Kardinalität UML * 3..* , 4, , 8, 10..* genau 1 0 bis 1 0 bis viele 3 bis viele 0 bis 2 genau 2 2, 4 oder 6 nicht 6, 7 oder Assoziation Name einer Assoziation Beschreibt meistens nur eine Richtung der Assoziation Ein schwarzes Dreieck gibt die Leserichtung an Name darf fehlen, wenn die Bedeutung der Assoziation offensichtlich ist Name Kunde 1 besitzt * Kontonr Art Eröffnung Konto

21 Assoziation Rollenname Beschreibt Bedeutung eines Objekt in einer Assoziation Binäre Assoziationen besitzen maximal zwei Rollen Er wird an das Ende der Assoziation geschrieben bei der Klasse, deren Bedeutung in der Assoziation sie beschreibt Tragen zur Verständlichkeit des Modells mehr bei als der Name der Assoziation 42 Name Kunde 2.5 Assoziation Rollenname ist nicht optional... wenn zwischen zwei Klassen mehr als eine Assoziation besteht bei reflexiven Assoziationen 1 1..* Kontoinhaber * 1..* Kontoberechtigter Konto Kontonr Art Eröffnung :Kunde :Kunde Kontoinhaber Kontoberechtigter :Konto Angestellter Name Gehalt Position Mitarbeiter * Chef 0..1 :Angestellter Chef Chef :Angestellter :Angestellter Chef Chef Mitarbeiter Mitarbeiter Mitarbeiter Mitarbeiter :Angestellter :Angestellter

22 Assoziation Abgeleitete Assoziation (derived association) Professor 1 liest * Vorlesung * /ist Hörer von * * hört * Student :Professor :Vorlesung :Student :Vorlesung :Student Assoziation 3 Arten von Assoziationen in der UML Einfache Assoziation (ordinary association) Aggregation (aggregation) Komposition (composite aggregation) Hypertext-Buch Titel Erscheinungsjahr Verzeichnis Name MS-DOS-Name Erstellung Kapitel Autor Anzahl Seiten * Aggregation * Aggregatklasse Teilklasse Komposition 1 * Datei Name MS-DOS-Name Erstellung letzte Änderung letzter Zugriff

23 Assoziation Aggregation Läßt sich durch ist Teil von bzw. besteht aus beschreiben (Ganzes und Teile, whole part) Komposition»starke«Aggregation Kardinalität der Aggregatklasse <= 1 Dynamische Semantik des Ganzen gilt auch für seine Teile (propagation semantics) Wird das Ganze gelöscht, werden automatisch seine Teile gelöscht (they live and die with it) Vererbung Definition Vererbung (generalization) ist eine Beziehung zwischen einer allgemeinen Klasse (Basisklasse) und einer spezialisierten Klasse Die spezialisierte Klasse ist vollständig konsistent mit der Basisklasse, enthält aber zusätzliche Informationen (Attribute, Operationen, Assoziationen) Allgemeine Klasse = Oberklasse (super class) Spezialisierte Klasse = Unterklasse (sub class)

24 Vererbung Person Name Adresse Geburtsdatum drucke Adresse() Hilfskraft Matrikelnr Name Adresse Geburtsdatum Immatrikulation Beschäftigungen drucke Adresse() drucke Ausweis() drucke Arbeitszeiten() Angestellter Personalnr Name Geburtsdatum Gehalt Bank drucke Adresse() überweise Gehalt() Angestellter Personalnr Gehalt Bank überweise Gehalt() Student Matrikelnr Immatrikulation drucke Ausweis() Student Matrikelnr Name Adresse Geburtsdatum Immatrikulation Hilfskraft Beschäftigungen drucke Adresse() drucke Ausweis() drucke Arbeitszeiten() Vererbung Notation UML Weißes bzw. transparentes Dreieck bei der Basisklasse Klasse1 Klasse1 {abstract} Klasse2 Klasse3 Klasse2 Klasse3

25 Vererbung Überschreiben von Operationen Unterklassen können das Verhalten ihrer Oberklassen verfeinern, redefinieren bzw. überschreiben (redefine, override) K onto Kontonum mer Kontostand buchen() Sparkonto buchen() Paket Definition Das Paket (package)... faßt Modellelemente (z.b. Klassen) zusammen kann selbst Pakete enthalten Das vollständige System kann als ein großes Paket aufgefaßt werden Beispiel: Warenwirtschaftssystem Einkauf Verkauf Produktion Material- Wirtschaft

26 Paket Notation UML Paketname muß im gesamten System eindeutig sein System Paket1 Paket2 Paket1 Paket2 Paket Paket Paket und Klasse Jede Klasse (allgemeiner: jedes Modellelement) gehört zu höchstens einem Paket Es kann in mehreren anderen Paketen darauf verwiesen werden Ein Paket definiert einen Namensraum für alle enthaltenen Klassen Paket::Klasse Paket1::Paket11::Paket111::Klasse

27 53 CRC-Karte Name der Klasse (class) Verantwortlichkeiten (responsibilities) d. Klasse Notwendige Klassen (collaborations) Class Bestellung Responsibilities verwaltet eine Bestellung delegiert Aufgaben an Bestellpositionen Collaborations Bestellposition Bestellung Nummer Datum erfassen() drucken() 1 1..* Bestellposition Artikelnummer Bezeichnung Anzahl 54 Inhalt: UML - Dynamische Konzepte 2.8 Geschäftsprozeß 2.9 Botschaft 2.10 Szenario 2.11 Zustandsautomat

28 Geschäftsprozeß Begriff des use case von Jacobson in die Objektorientierung eingeführt use case in einem Informationssystem 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 Alle use cases zusammen dokumentieren alle Möglichkeiten der Benutzung des Systems (use case model) use case in einem Unternehmen Sequenz von unternehmensinternen Aktivitäten, die durchgeführt werden, um die Wünsche eines Kunden zu befriedigen Geschäftsprozeß Problematik in der Analyse Nicht abzusehen, ob alle Aufgaben durch die Software abgedeckt werden oder ob auch organisatorische Schritte enthalten sind Ziel Spezifikation der ergebnisorientierten Arbeitsabläufe Definition 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

29 Geschäftsprozeß Wer ist der Akteur (actor)? Rolle, die ein Benutzer des Systems spielt Hat einen Einfluß auf das System Ist häufig eine Person Kann auch Organisationseinheit oder anderes System sein Befindet sich immer außerhalb des Systems Geschäftsprozeß Wer ist der Akteur (actor)? Handelshaus (System = Unternehmen) Kunde Lieferant Kundensachbearbeiter Auftragsund Bestellwesen (Softwaresystem) Lieferantensachbearbeiter Lagersachbearbeiter Buchhaltung

30 Geschäftsprozeß Spezifikationsschablone (use case template) Geschäftsprozeß: Name des Geschäftsprozesses Ziel: globale Zielsetzung bei erfolgreicher Ausführung des Geschäftsprozesses Kategorie: primär (notwendig, häufig benötigt) sekundär (notwendig, selten benötigt) optional (nützlich, nicht unbedingt notwendig) Vorbedingung: erwarteter Zustand, bevor der Geschäftsprozeß beginnt Nachbedingung Erfolg Nachbedingung Fehlschlag Akteure Geschäftsprozeß Spezifikationsschablone Auslösendes Ereignis Beschreibung: Hier wird der Standardfall beschrieben 1 Erste Aktion 2 Zweite Aktion Erweiterungen: 1a Erweiterung des Funktionsumfangs der ersten Aktion Alternativen: 1a Alternative Ausführung der ersten Aktion

31 Geschäftsprozeß Geschäftsprozeß:Auftrag ausführen Ziel: Ware an Kunden geliefert Vorbedingung: - Nachbedingung Erfolg: Ware ausgeliefert (auch Teillieferungen), Rechnungskopie bei Buchhaltung Nachbedingung Fehlschlag: Mitteilung an Kunden, daß nichts lieferbar Akteure: Kundensachbearbeiter, Lagersachbearbeiter, Buchhaltung Auslösendes Ereignis: Bestellung des Kunden liegt vor Geschäftsprozeß Beschreibung: 1 Kundendaten abrufen 2 Lieferbarkeit prüfen 3 Rechnung erstellen 4 Auftrag vom Lager ausführen lassen 5 Rechnungskopie an Buchhaltung geben Erweiterung: 1a Kundendaten aktualisieren Alternativen: 1a Neukunden erfassen 3a Rechnung mit Nachnahme 3b Rechnung mit Bankeinzug erstellen

32 Geschäftsprozeß Notation Geschäftsprozeßdiagramm (use case diagram) UML System Akteur1 Akteur3 Akteur Geschäftsprozeß Geschäftsprozeßdiagramm für ein Informationssystem Warenwirtschaftssystem Auftrag ausführen Buchhaltung Lager verwalten Geschäftsprozeß2 Geschäftsprozeß3 Geschäftsprozeß1 Kundensachbearbeiter Lieferantensachbearbeiter Lagersachbearbeiter

33 Geschäftsprozeß extends-beziehung Erweiterung eines vorhandenen GP Auftrag durchführen «extends» Auftrag mit Nachlieferung ausführen uses-beziehung Zwei GP besitzen gemeinsames Verhalten Wareneingang aus Einkauf bearbeiten Wareneingang aus Produktion bearbeiten «uses» «uses» Ware einlagern Geschäftsprozeß Aktivitätsdiagramm (activity diagram) Beispiel: Auftrag ausführen Kundendaten abrufen 1. Schritt Lieferbarkeit prüfen 2. Schritt Rechnung erstellen 3. Schritt Auftrag vom Lager ausführen lassen Rechnungskopie an Buchhaltung geben Reihenfolge aus fachlicher Sicht irrelevant.

34 Botschaft Definition Eine Botschaft (message, Nachricht) ist die Aufforderung eines Senders (client) an einen Empfänger (server, supplier) eine Dienstleistung zu erbringen Empfänger interpretiert diese Botschaft und führt eine Operation (gleichen Namens) aus Sender der Botschaft weiß nicht, wie die entsprechende Operation ausgeführt wird Protokoll (protocol) der Klasse Menge der Botschaften, auf die Objekte einer Klasse reagieren können Botschaft Beispiel Bezeichnung Leiter Filiale berechnedurchs chnittsumsatz() 1 * Versicherter Nummer Name Adresse Geburtsdatum berechnebeit rag() 1 :Filiale berechnedurchschnittsumsatz() berechnebeitrag() :Versicherter getjahresbeitrag() * Vertrag Nummer Art Jahresbeitrag Versicherungs sum me Absc hlußdatum :Vertrag

35 Szenario Definition Ein Szenario (scenario) ist eine Sequenz von Verarbeitungsschritten, die unter bestimmten Bedingungen auszuführen ist Diese Schritte sollen das Hauptziel des Akteurs realisieren und ein entsprechendes Ergebnis liefern Sie beginnen mit dem auslösenden Ereignis und werden fortgesetzt bis das Ziel erreicht ist oder aufgegeben wird Szenario Geschäftsprozeß und Szenario Ein Geschäftsprozeß wird durch eine Kollektion von Szenarios dokumentiert Jedes Szenario wird durch eine oder mehrere Bedingungen definiert, die zu einem speziellen Ablauf des Geschäftsprozesses führen Zwei Kategorien von Szenarios: Szenarios, die eine erfolgreiche Bearbeitung des Geschäftsprozesses beschreiben Szenarios, die zu einem Fehlschlag führen

36 Szenario Beispiel Szenarios zum Geschäftsprozeß Auftrag bearbeiten Auftrag für einen Neukunden bearbeiten und mindestens ein Artikel ist lieferbar Auftrag bearbeiten, wenn Kunde bereits existiert und mindestens ein Artikel lieferbar ist Auftrag bearbeiten, wenn der Kunde bereits existiert, sich seine Daten geändert haben und mindestens ein Artikel lieferbar ist Szenario Notation Szenarios werden durch Interaktionsdiagramme (interaction diagrams) modelliert UML bietet zwei Arten von Diagrammen an Sequenzdiagramm (sequence diagram) Kollaborationsdiagramm (collaboration diagram)

37 Szenario Notation Sequenzdiagramm UML Akteur Objekt wird erzeugt :C2 :C3 op() Botschaft :C1 op1() Objektlinie op2() op3() Objekt wird gelöscht Szenario Sequenzdiagramm Besitzt zwei Dimensionen Die Vertikale repräsentiert die Zeit Auf der Horizontalen werden die Objekte eingetragen Jedes Objekt wird dargestellt durch Objektsymbol und vertikale gestrichelte Linie (Objektlinie) Bedingung (condition) [<Bedingung>] Operation() Wiederholung (iteration) * Operation() oder *[Bedingung] Op()

38 Szenario Auftrag für einen Neukunden bearbeiten Klassendiagramm Kunde erfassen() Artikel istlieferbar() 1 * 1 * Auftrag erfassen() erstellerechnung() 1 * Auftragsposition Bestellmenge Liefermenge Szenario :Artikel erfassen() :Kunde erfassen() :Auftrag new() :Auftragsposition setbestellmenge() istlieferbar() [nichtlieferbar] setliefermenge() erstelle Rechnung()

39 Szenario Auftrag für existierende Kunden bearbeiten :Kunde :Artikel abrufen() [Änderung] aktualisieren() erfassen() :Auftrag istlieferbar() erstelle Rechnung() Szenario Notation Kollaborationsdiagramm UML {new} Objekt wird erzeugt {destroyed} Objekt wird gelöscht {transient} Objekt wird sowohl erzeugt als auch gelöscht op() :C1 {transient} 2: op2() 1: op1() 2.1: op3() :C2 :C3

40 Szenario Kollaborationsdiagramm Permanente Objektverbindungen Assoziationen Temporäre Objektverbindungen... bestehen nur für die Dauer der Kommunikation liegen vor, wenn das angesprochene Empfängerobjekt auch ohne Vorliegen einer Assoziation vom Sender eindeutig identifiziert werden kann werden mit «temp» gekennzeichnet Implizite Objektverbindung (self link) Jedes Objekt kann jederzeit Botschaften an sich selbst schicken Szenario Sequenz- vs. Kollaborationsdiagramm Klasse :Klasse Klassenoperation() Klassenoperation() Klasse Konstruktoroperation() :Klasse Konstruktoroperation() :Klasse {new} Objektoperation() Objektoperation() :Klasse

41 Zustandsautomat Definition Ein Zustandsautomat (finite state machine) besteht aus Zuständen und Zustandsübergängen (Transitionen) Ein Zustand ist eine Zeitspanne, in der ein Objekt auf ein Ereignis wartet Ein Ereignis tritt immer zu einem Zeitpunkt auf und besitzt keine Dauer Zustandsautomat Beispiel: Lebenszyklus der Klasse Buch Buch defekt / entfernen() Ausleihwunsch / ausleihen() Buch verloren / entfernen() Ausleihwunsch / vorbestellen() präsent ausgeliehen neues Buch liegt vor / erfassen() after (Abholfrist vorbei) Leser gibt Buch zurück / zurückgeben() Leser holt Buch ab / ausleihen() zur Abholung bereit Buch erfassen() ausleihen() zurückgeben() vorbestellen() entfernen() vorbestellt Leser gibt Buch zurück / zurückgeben()

42 Zustandsautomat Notation UML Zustand1 Anfangszustand Ereignis1 Transition Zustand2 do/ Aktivität Zustand4 entry/ Aktion3 exit/ Aktion4 Ereignis3[Wächter] Zustand3 implizites Ereignis Ereignis4 Endzustand Ereignis2/ Aktion Zustandsautomat Zustand Zustandsname ist optional Zustände ohne Namen heißen anonyme Zustände und sind alle voneinander verschieden Zustandsname soll kein Verb sein Innerhalb einer Klasse muß jeder Zustandsname eindeutig sein Anfangszustand Pseudozustand, der mit einem echten Zustand durch eine Transition verbunden ist Endzustand Objekt hört auf, zu existieren

43 Zustandsautomat Verarbeitung in einem Zustand Aktion Ist atomar Terminiert selbständig entry-aktion exit-aktion Aktivität Beginnt, wenn Objekt Zustand einnimmt und endet, wenn es ihn verläßt Start Aktion + Stop Aktion Zustandsautomat Zustandsübergang (Transition) Verbindet zwei Zustände Gesprochen: die Transition»feuert«Wird durch ein Ereignis ausgelöst Kann mit einer Aktion verbunden sein Ereignis kann sein Bedingung, die wahr wird, z.b. when (Temperatur > 100 Grad) Signal, z.b. rechte Maustaste gedrückt Botschaft (Aufruf einer Operation) verstrichene Zeit, z.b. after(10 sec) Eintreten eines bestimmten Zeitpunkts, z.b. when( )

44 Zustandsautomat Wächter Ereignis kann mit Wächter (guard condition) kombiniert werden Die Transition feuert nur dann, wenn... das zugehörende Ereignis eintritt und die im Wächter spezifizierte Bedingung erfüllt ist Implizites Ereignis Transition wird ausgeführt, wenn die mit dem Zustand verbundene Verarbeitung beendet ist Zustandsautomat Beispiel: Lebenszyklus der Klasse Tank neue Füllhöhe / einstellen Füllhöhe() Tank füllen leer Tank füllen() leeren() einstellenfüllhöhe() füllend do/ füllen() when(voll) when(leer) voll Tank leeren leerend do/ leeren()

45 Zustandsautomat Beispiel: Kartenautomat in einem Parkhaus when(karte falsch)/ auswerfen Karte bereit Karte / einziehen Karte entry/ prüfe Karte after (5 sec) wartet auf Geld when(karte korrekt) / anzeigen Gesamtbetrag Geld eingeworfen [reicht nicht] / anzeigen Restbetrag Quittung anfordern / drucke Quittung wartet auf Quittung Geld eingeworfen [reicht aus]/ ausgeben Karte Kartenautomat bezahlen Parkgebühr() Zustandsautomat ausgeschaltet Einschalten / speichern Geschwindigkeit() Ausschalten Ausschalten ohne Verfeinerung regelnd Bremsen do/ einhalten Soll-Geschwindigkeit() Wiederaufnahme ausgeschaltet unterbrochen Tempomat speichern Geschwindigkeit() einhalten Soll-Geschwindigkeit() Einschalten / speichern Geschwindigkeit() Ausschalten mit Verfeinerung eingeschaltet regelnd do/ einhalten Soll-Geschwindigkeit() Bremsen Wiederaufnahme unterbrochen

46 Zustandsautomat Aktivitätsdiagramm (activity diagram) Verarbeitung1 [Bedingung1b] Entscheidung [Bedingung2b] Splitting [Bedingung1a] [Bedingung2a] Verarbeitung2 Verarbeitung4 Verarbeitung6 Verarbeitung3 Synchronisation Verarbeitung Zustandsautomat Aktivitätsdiagramm (activity diagram) Sonderfall des Zustandsdiagramms (Fast) alle Zustände sind mit Verarbeitung verbunden Zustand wird verlassen, wenn Verarbeitung beendet ist Wächter (guard condition) spezifiziert Verzweigungen im Kontrollfluß Spezifikation von parallelen Abläufen