Software Engineering PS (WS2000/2001)

Schwaiger Roland

Home

Vorbesprechung

Organisation

Thema

Gruppen

Aufgaben

Präsentation

Abschluss

Material

Use Case Diagramm

Aufgabe 3

1. Gehen Sie in die Problembeschreibung und Anforderungsdefinition und erweitern Sie diese um die Antworten bzw. neue Anforderungen, die sich aufgrund der Diskussion mit dem project leader ergeben haben (Dieser Punkt bezieht sich nur auf das Gruppendokument, nicht auf die individuellen Dokumente).
2. Ermitteln Sie die derzeit bekannten actors für das System und beschreiben Sie diese, wie unten angeführt.
3. Ermitteln Sie die primary use cases, also die Haupfunktionalität, für das System und beschreiben Sie diese, wie unten angeführt (Kurzbeschreibung) (min 5, max 10). Verwenden Sie dazu die vorgeschlagenen Templates unter Punkt Material (Use_Case_Description_Document_Template.tex nach tar) bzw. wie unten angeführt. Füllen Sie die Punkte "Use Case Name" mit einer Kurze Beschreibung und "Actors" ein.
4. Erstellen Sie das Use Case Diagramme für einen Actor Ihrer Wahl (handschriftlich).

Zusatzinformation

Das Verhalten des zu entwicklenden Systems (die Funktionalität) wird in Use Case Models dokumentiert. Diese zeigen die geplanten Funktionen des Systems (Use Cases), ihre Umgebung (actors) und die Beziehung zwischen den uses cases und den actors (use case diagramm). Das use case model startet in der Inception Phase mit der Identifikation der actors und der prinzipiellen (primary) use cases. Das Modell wird in der Elaboration Phase erweitert bzgl. use cases (secondary).

Actors sind nicht Teil des Systems, sie repräsentieren jemanden oder etwas, das mit dem System interagiert, z.B. Benutzer, Prozess. Actors senden oder empfangen oder senden und empfangen Informationen vom und zum System. Wie kann man Actors identifizieren?

• Wer ist an einer gewissen Anforderung interessiert?
• Wo in der Organisation wird das System eingesetzt?
• Wer profitiert von der Benutzung des Systems?
• Wer versorgt das System mit Information, benutz die Information und entfernt die Information?
• Wer wird das System pflegen?
• Benutzt das System externe Ressourcen?
• Hat eine Person unterschiedliche Rollen?
• Spielen mehrere Personen dieselbe Rolle?
• Interagiert was System mit Altsystemen (legacy systems)?

Wie werden actors beschrieben? Die grafische Notation eines actors in UML ist das "Strichmännchen" (siehe unten). Zu jedem actor sollte eine Beschreibung angelegt werden und die Rolle, die dieser actor spielt, z.B. Actor Erfasser: eine Person, die Daten erfasst, die von einem wissenschaftlichen Mitarbeiter (Archäologen) handschriftlich vorbereitet wurden.

Das use case model stellt einen Dialog zwischen einem actor und dem System dar. Use Cases entsprechen den Funktionen, die vom System angeboten werden, also welche Leistungen einem actor angeboten werden. Idealerweise stellt die Sammlung aller use cases die Gesamtmenge der Benutzbarkeit des Systems dar.

Def: Ein use case ist ein Sequenz von Transaktionen, die von einem System ausgeführt werden und die ein bedeutungsvolles, messbares Ergebnis für einen actor liefern.

Wie kann man use cases identifizieren?

• Was sind die Aufgaben eines actors?
• Werden von einem actor Daten erzeugt, bewegt, verändert, gelesen im System?
• Welche uses cases werden diese Daten erzeugt, bewegen, verändern, lesen?
• Muss ein actor das System über externe Veränderungen benachrichtigen?
• Muss ein actor vom System über interne Veränderungen benachrichtigt werden?
• Welche use cases pflegen (support, maintainance) das System?
• Können alle funktionalen Anforderungen durch die use cases abgedeckt werden?

Wie werden use cases beschrieben? In der UML werden use cases durch ein Oval dargestellt. Eine Rule of Thumb zum Auffinden von Use Cases: "Normalerweise repräsentiert ein use case ein angemesses Teil Funktionalität, das vollstädig ist. Ein use case liefert an den actor etwas von Bedeutung, Wert zurück." Ein Beispiel für einen use case: Erfassung von Artefakten. Es stellt einen wichtigen Teil der Funktionalität dar, ist abgeschlossen und liefert dem Benutzer etwas von Wert zurück, z.B. "Die erfassten Daten wurden gesichert".

Zu einem use case wird eine kurze Beschreibungen angelegt, die den Zweck des use cases in einigen Sätzen beschreibt. Diese Beschreibung wird normalerweise in der Inception Phase erzeugt, z.B. für den use case "Erfassung von Artefakten": Der use case wird durch den Erfasser gestartet. Es werden die Möglichkeiten geboten nach bereits vorhandenen Artefakten zu suchen und passende Artefakte zu kopieren, bzw. ein neues Artefakt vollständig neu zu erfassen. Der Erfasser sichert oder verwirft die Eingaben.

Jeder relevante use case wird zusätzlich durch sg. flow of events (FOE) dokumentiert. Der FOE für einen Use Case ist eine Beschreibung der events, die benötigt werden umd das gewünschte Verhalten des use cases zu erzielen. Also wird im FOE beschrieben WAS das System zu leisten hat, MICHT WIE. Folgende Aspekte sollten in der FOE enthalten sein:

• Wann und wie startet und endet der use case?
• Welche Interaktion gibt es zwischen actors und use case?
• Welche Daten werden dafür benötigt?
• Die normale Sequenz der events für den use case.
• Die Beschreibung von alternativen, oder Ausnahmen-flows.

Use Case Relationship Eine Assoziationsbeziehung kann zwischen einem Use Case und einem Actor bestehen. Dieser Typ von Assoziation wird als "communicates association" bezeichnet, nachdem diese Beziehung eine Kommunikation zwischen Actor und Use Case darstellt. Einer solchen Assoziation wird eine Navigationsrichtung zugeordnet (Actor -> Use Case, Actor <- Use Case, Actor <-> Use Case), diese deutet an, von wem die Kommunikation aufgebaut wird. Eine Assoziation wird im UML mittels einer Verbinsungslinie zwischen Use Case und Actor dargestellt. Falls die Assoziation nur in einer Richtung "bereist" werden kann, dann wird die Richtung durch einen Pfeil angezeit.

Es gibt in UML 1.1 zwei Arten von Beziehungen zwischen Use Cases: uses und extends. Mehrere Use Cases können unter Umständen gemeinsame Funktionalitäten aufweisen, es bietet sich an diese Funktionalität in einen eigenen Use Case zu legen, z.B. wird der Use Case "Artefakt anlegen" und "Artefakt bearbeiten" den Use Case "Artefakt suchen" benutzen. Eine uses Relation wird als Pfeil dargestellt mit einem leeren Dreieck beim benutzten Use Case.

Eine extends Beziehung wird benutzt um:

• Optionales Verhalten anzuzeigen,
• Verhalten anzuzeigen, das nur unter gewissen Bedingungen ausgeführt wird,
• Unterschiedliche Flows, die in Abhängigkeit von der Actor Selektion ausgeführt werden.

Laut 0.1 können die folgenden Regeln angewandt werden:

• Benutze include falls man sich in verschiedenen use cases wiederholt und Wiederholung vermeiden möchte.
• Benutze Generalisierung wenn man eine Variation eines normalen Vehaltens nicht-formal beschreiben möchte.
• Benutze extend um die Variation eines Verhaltes formal beschreiben möchte, mittels Deklaration von extension points, im Basis use case.

Use Case Diagrams sind nun eine grafische Darstellung einiger oder aller Actors, Use Cases und deren Beziehungen (siehe Beispiel weiter unten). Jedes System hat normalerweise ein Main Use Case Diagram, wo die Systemgrenzen (Actors) eingezeichnet werden und die Hauptfunktionalität (Use Cases) des Systems. Sehr oft findet man auch die Darstellung, dass die Use Cases in einem Rechteck dargestellt werden, um die Systemgrenze zu visualisieren. Andere Use Case Diagrams können für einen bestimmten Actor, alle Use Cases die in einer Iteration implementiert werden und ein Diagramm das alle Use Cases und deren Beziehungen zeigt.

Beispiel

Wir werden das folgende Template zur Beschreibung der Use Cases verwenden (mein Dank an Konrad Lang für das Template, Referenz: 2):

Detailed Use Case Description

• Use Case Name: A brief description. Usually a paragraph or less.
• Actors: A list of the actors who communicate with this use case.
• Priority: How important is this use case to the project?
• Status: At what point are we in developing this use case?
• Preconditions: A list of conditions that must be true before the use case starts.
• Postconditions: A list of conditions that must be true when the use case ends, no matter which scenario is executed.
• Extension Points: If the use case has extension points, list them here.
• "Used" Use Cases: If the use case uses other use cases, list them here.
• Flow of Events: This could be a basic path and alternative paths, or the primary scenario.
• Preconditions
• Main Flow
• Subflows (if applicable)
• Alternative Flows
• Activity Diagram: An activity diagram of the flow of events, or some significant or complex part of the flow of events.
• User Interface: For systems that interface with people, include a description of the user interface, possibly using storyboards.
• Secondary Scenarios: If alternatives and exceptions are not shown in the flow of events, scenarios should be listed here, and a brief description may be included.
• Sequence Diagrams: If you do not have separate documents for scenarios, you might include sequence diagrams for them here.
• Subordinate Use Cases: If the use case has subordinate use cases, show them here. Or you could include a use case diagram for the subordinate use case. Or both. Also tell what subsystem is responsible for this subordinate use case.
• View of Participating Classes: A collaboration showing all the classes whose objects interact to implement this use case. You also can show interfaces to the use case here and which of the classes implement the interfaces.
• Other Artifacts: This can include references to the subsystem the use case belongs to, an analysis model, adesign model, code, or test plans.
• Other Requirements: This section is where you can put nonfunctional requirements affecting the use case.