DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2.5.1 Okt 2010 Seite 1 Objektorientierte Analyse...

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2.5.1 Okt 2010

Seite 1

Objektorientierte Analyse (OOA)Inhaltsübersicht

• Einführung• Anforderungen an die UML-Diagramme• Verhalten: Use-Case-Diagramm• Verhalten: Aktivitätsdiagramm• Verhalten: Zustandsautomat • Struktur: Klassendiagramm


Seite 2

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 IT-spezifischen Anforderungen das Software-System erstellt; das Software-System beschreibt, wie die Anforderungen umgesetzt wurden


Seite 3

Objektorientierte Analyse (OOA)Einführung

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ß)

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.


Seite 4

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 5

Objektorientierte Analyse (OOA) Verhaltensmodellierung


Seite 6



Seite 7



Seite 8

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 9

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 Kommunikations-Beziehungen, 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 10

• 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”


Beispiel mit dem Case-Tool Innovator: • Paket “Verwaltung” dient zur Gruppierung (Systemgrenze)


Seite 11Christoph Riewerts


Beispiel für eine Generalisierung (Innovator):

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 Call-Center-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).

Es existieren drei (konkrete) Anwendungsfälle, die eine Spezialisierung des abstrakten Anwendungsfalles Kfz reservieren darstellen.


Seite 12

Ü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 13

Ü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 14

Objektorientierte Analyse (OOA) Use Case Beschreibung (Template)

Use case Titel: ___________________

Nummer: ………

Kurzbeschreibung (Ziel): ………

Akteure: ………

Auslösendes Ereignis: ………

Vorbedingung: ………

Nachbedingung (bei Erfolg / bei Fehlerfall):

Standardablauf (Abfolge der Aktionen):1.2.3.……..

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

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.


Seite 15

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 geliefertAkteure: Kundensachbearbeiter, Lagersachbearbeiter, BuchhaltungAuslösendes Ereignis: Bestellung des Kunden liegt vorVorbedingung: BestellungNachbedingung (bei Erfolg): Ware ausgeliefert (auch Teillieferungen), Rechnungskopie bei BuchhaltungNachbedingung (bei Fehlerfall): Mitteilung an Kunden, dass nicht lieferbarStandardablauf: 1. Kundendaten abrufen

2. Lieferbarkeit prüfen3. Rechnung erstellen4. Auftrag vom Lager ausführen lassen5. Rechnungskopie an Buchhaltung geben

Erweiterungen: 1a. Kundendaten aktualisierenAlternativen: 1a. Neukunden erfassen

3a. Rechnung mit Nachnahme erstellen3b. Rechnung mit Bankeinzug erstellen


Seite 16

Beispiele für verbesserungsfähige Use Cases:

Objektorientierte Analyse (OOA) Use Case Beschreibungen


Seite 17

Hier sind die verbesserten Use Cases:- Keine Lösungen (Oberflächen)

beschreiben- Hauptablauf (mit Alternativen)

kennzeichnen- Detaillierung der Daten (Attribute) ins

Klassendiagramm übernehmen

Objektorientierte Analyse (OOA) Use Case Beschreibungen


Seite 18

Übung Flugbuchung Seite 12:

Objektorientierte Analyse (OOA) Anhang: Lösungen der Übungen


Seite 19

Übung (Bibliothekssystem) Seite 13

Objektorientierte Analyse (OOA) Anhang: Lösungen der Übungen

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2.5.1 Okt 2010 Seite 1 Objektorientierte Analyse...

Documents

Transcript of DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 2.5.1 Okt 2010 Seite 1 Objektorientierte Analyse...