Kein Folientitel

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2.5.1
Okt 2010
Objektorientierte Analyse (OOA)
Inhaltsübersicht
•
•
•
•
•
•
Einführung
Anforderungen an die UML-Diagramme
Verhalten: Use-Case-Diagramm
Verhalten: Aktivitätsdiagramm
Verhalten: Zustandsautomat
Struktur: Klassendiagramm
Seite 1
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2.5.1
Okt 2010
Objektorientierte Analyse (OOA)
Einführung
In der Systemanalyse wird aus den
fachspezifischen Anforderungen das
Systemmodell erstellt; im
Systemmodell ist spezifiziert, was das
System leisten soll, d.h. statische
Struktur und dynamisches Verhalten
sind vollständig beschrieben.
In der Systementwicklung wird aus
dem Systemmodell und den ITspezifischen Anforderungen das
Software-System erstellt; das
Software-System beschreibt, wie die
Anforderungen umgesetzt wurden
Seite 2
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2.5.1
Okt 2010
Objektorientierte Analyse (OOA)
Einführung
UML ist die Notation für die OOA. Mit den UML-Diagrammen gliedert sich das
Systemmodell in zwei Aspekte: (dynamische) Verhaltensmodellierung und (statische)
Strukturmodellierung, für deren Beschreibung vier UML-Diagramme zuständig sind.
Methodische Gliederung
Komponenten
Diagramm (UML 2)
Verhaltensmodellierung
(dynamisch)
Ereignisse
Kontrollfluss (Ablauf)
Zustandsübergänge
Use-Case-Diagramm
Aktivitätsdiagramm
Zustandsautomat
Strukturmodellierung
(statisch)
Daten (–Strukturen)
Schnittstellen (Kontext)
Funktionen
Datenfluss
Klassendiagramm
Aktivitätsdiagramm (nur
Parameter/Objektfluß)
Seite 3
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2.5.1
Okt 2010
Objektorientierte Analyse (OOA)
Anforderungen an die UML-Diagramme
Vollständigkeit der OOA
• Kontext, d.h. externe Schnittstellen
• Funktionshierarchie
Konsistenz zwischen den Diagrammen
• Aktoren und Swimlanes
• Parameter und Klassen
• Ereignisse und Klassen
• Use Cases und Aktionen bzw Aktivitäten
Verständlichkeit für die unterschiedlichen Nutzer
• Komplexität einer Aktivität
• Beschreibungsmöglichkeiten in einem Diagramm
Seite 4
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2.5.1
Okt 2010
Objektorientierte Analyse (OOA)
Verhaltensmodellierung
Seite 5
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2.5.1
Okt 2010
Objektorientierte Analyse (OOA)
Verhaltensmodellierung
Seite 6
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2.5.1
Okt 2010
Objektorientierte Analyse (OOA)
Verhaltensmodellierung
Seite 7
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2.5.1
Okt 2010
Objektorientierte Analyse (OOA)
Bedeutung der Use Cases
Anwendung im Projekt
•
•
•
•
Use Case Diagramm liefert die funktionelle Gliederung in form von Anwendungsfällen in der 1.
Gliederungsebene; weitere Gliederungsebenen werden durch Aktivitätsdiagramme visualisiert
Use Cases liefern den Kontext, d.h. sie beschreiben alle Systemgrenzen (externe Schnittstellen)
Use Cases stellen keine objektorientierte Sicht auf das System dar, sondern beschreiben die
funktionellen Anforderungen aus Anwendersicht (was statt wie) (und Entwicklersicht)
Verständlichkeit wird erreicht durch:
–
Sparsame Verwendung der include- und extend-Beziehungen
–
Vorgabe eines Templates zur textuellen Beschreibung der Use Cases
Zu beachten
•
•
•
•
Akteure (actors) werden nur dann eingeführt, wenn sie direkt mit dem System (inter-)agieren, d.h.
aktiv beteiligt sind; es gibt somit nicht nur menschliche Akteure!
Schnittstellen nach außen werden in den Aktivitätsdiagrammen als Ein- und Ausgabeparameter
spezifiziert
Für eine detaillierte(re) Spezifikation der Daten steht das Klassendiagramm zur Verfügung
Bei einem gleichwertigen Auftreten von Abfolgen und Ereignissen im Use Case empfiehlt es sich,
einen Zustandsautomaten zur Beschreibung hinzuzufügen
Seite 8
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2.5.1
Okt 2010
Objektorientierte Analyse (OOA)
Use Case Diagramm
•
•
•
Das Use Case Diagramm hält fest, was Akteure/Aktoren, die sich außerhalb des
Systems befinden) vom System erwarten. Es bildet des externe Verhalten des System
ab. Es enthält die grafische Darstellung der Use Cases (Anwendungsfälle).
Use Cases helfen, das System in logische Teile (planbare Einheiten) zu gliedern und
liefern die Schnittstellen, so dass sie auch als Grundlage für das Testen des Systems
nach der Erstellung bieten
Notation: Anwendungsfälle werden durch Ellipsen, die den Namen des
Anwendungsfalles - möglichst als Verb - tragen, und einer Menge von beteiligten
Objekten (Akteure, häufig als Strichmännchen gezeichnet), die den Namen ihrer Rolle
tragen. dargestellt. Zwischen den Anwendungsfällen existieren KommunikationsBeziehungen, die durch Linien dargestellt werden, spezielle Beziehungen sind:
– <<extend>>-Beziehung,
– <<include>>-Beziehung (ersetzt die <<uses>>-Beziehung aus der UML1.1)
– Generalisierungsbeziehung (seit UML 1.3).
Seite 9
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2.5.1
Okt 2010
Objektorientierte Analyse (OOA)
Use Case Diagramm
Beispiel mit dem Case-Tool Innovator:
• Paket “Verwaltung” dient zur Gruppierung (Systemgrenze)
•
•
•
•
Kommunikationsbeziehungen
(einfache Striche) werden
nicht benannt
<<extend>>Beziehung sagt,
daß der Use Case
“Anmelden” durch den Use
Case “Kontozugang sperren”
(unter bestimmten
Umständen, siehe [ ] im
Diagramm) erweitert wird
(extension point)
<<include>>Beziehung sagt,
daß der Use Case
“Abmelden” den Use Case
“BLZ überprüfen” enthält
Der use case “BLZ
überprüfen“ gehört originär
zum Paket “Auskunft”
Seite 10
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2.5.1
Okt 2010
Objektorientierte Analyse (OOA)
Use Case Diagramm
Beispiel für eine Generalisierung (Innovator):
Es existieren drei (konkrete) Anwendungsfälle, die eine
Spezialisierung des abstrakten Anwendungsfalles Kfz
reservieren darstellen.
Christoph Riewerts
Ebenfalls ist die Generalisierung
zwischen den Akteuren
eingezeichnet. Für den Prozeß
der Reservierung bedeutet das,
daß entweder der
Reservierungswunsch direkt vom
Kunden im Anwendungsfall Kfz
online reservieren bearbeitet wird
oder daß der
Reservierungswunsch vom CallCenter-Agenten (im Falle Kfz
telefonisch reservieren) oder vom
Niederlassungsmitarbeiter (im
Falle Kfz persönlich reservieren)
weitergeleitet wird (leider ist
diese Datenschnittstelle
Reservierungswunsch im
Diagramm nicht sichtbar).
Seite 11
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2.5.1
Okt 2010
Objektorientierte Analyse (OOA)
Use Case Diagramm
Übung (Flugbuchung):
Der Anwendungsfall “Buchen eines Fluges” verwendet die zwei Use Cases “Beratung” und
“Rechnung ausdrucken”. Eine Beratung wird jedoch nur in Ausnahmefällen durchgeführt,
während der Anwendungsfall “Rechnung ausdrucken” von allgemeiner Natur sein soll
und somit auch von weiteren Use Cases benutzt werden kann.
Entwerfen Sie ein
Anwendungsfall-Diagramm.
Seite 12
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2.5.1
Okt 2010
Objektorientierte Analyse (OOA)
Use Case Diagramm
Übung (Bibliothekssystem):
Für ein Bibliothekssystem sind folgende Anwendungsfälle zu spezifizieren: Buch ausleihen,
Buch vormerken, Buch zurückgeben, Buch inventarisieren, Buch suchen. Sollte ein
Kunde zur Benutzung der Bibliothek noch nicht berechtigt sein, müssen seine
Kundendaten aufgenommen werden.
Definieren Sie die notwendigen Akteure und stellen Sie ein Use Case Diagramm auf.
Seite 13
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2.5.1
Okt 2010
Objektorientierte Analyse (OOA)
Use Case Beschreibung (Template)
Wann ist eine Funktion ausreichend
beschrieben?
Antwort: Wenn zu jeder Funktion folgende Angaben
gemacht werden:
–
Auslöser einer Funktion
–
Input zu einer Funktion
–
Output einer Funktion
–
(bei komplexen Inhalten) einzelne
Funktionsschritte
–
Durchführender
Use case Titel: ___________________
Nummer: ………
Kurzbeschreibung (Ziel): ………
Akteure: ………
Auslösendes Ereignis: ………
Vorbedingung: ………
Nachbedingung (bei Erfolg / bei Fehlerfall):
Der Standardablauf wird in der Regel als
Aktivitätsdiagramm gezeichnet, da wir bei
umfangreichen Use Cases die Ein- und
Ausgabeparameter der Aktionen explizit
benötigen.
Standardablauf (Abfolge der Aktionen):
1.
2.
3.
……..
Seite 14
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2.5.1
Okt 2010
Objektorientierte Analyse (OOA)
Use Case Beschreibung
Beispiel für einen Use Case
Use Case Titel:
Auftrag ausführen
Nummer: FREQ 21
Kurzbeschreibung (Ziel): Ware an Kunde geliefert
Akteure: Kundensachbearbeiter, Lagersachbearbeiter, Buchhaltung
Auslösendes Ereignis: Bestellung des Kunden liegt vor
Vorbedingung: Bestellung
Nachbedingung (bei Erfolg): Ware ausgeliefert (auch Teillieferungen), Rechnungskopie bei
Buchhaltung
Nachbedingung (bei Fehlerfall): Mitteilung an Kunden, dass nicht lieferbar
Standardablauf:
1. Kundendaten abrufen
2. Lieferbarkeit prüfen
3. Rechnung erstellen
4. Auftrag vom Lager ausführen lassen
5. Rechnungskopie an Buchhaltung geben
Erweiterungen:
1a. Kundendaten aktualisieren
Alternativen:
1a. Neukunden erfassen
3a. Rechnung mit Nachnahme erstellen
3b. Rechnung mit Bankeinzug erstellen
Seite 15
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2.5.1
Okt 2010
Objektorientierte Analyse (OOA)
Use Case Beschreibungen
Beispiele für verbesserungsfähige Use Cases:
Seite 16
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2.5.1
Okt 2010
Objektorientierte Analyse (OOA)
Use Case Beschreibungen
Hier sind die verbesserten Use Cases:
- Keine Lösungen (Oberflächen)
beschreiben
- Hauptablauf (mit Alternativen)
kennzeichnen
- Detaillierung der Daten (Attribute) ins
Klassendiagramm übernehmen
Seite 17
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2.5.1
Okt 2010
Objektorientierte Analyse (OOA)
Anhang: Lösungen der Übungen
Übung Flugbuchung Seite 12:
Seite 18
DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2.5.1
Okt 2010
Objektorientierte Analyse (OOA)
Anhang: Lösungen der Übungen
Übung (Bibliothekssystem) Seite 13
Seite 19