SE Logo

Software Engineering PS (WS2000/2001)

© Copyright 2000, Schwaiger Roland


Home

Vorbesprechung

Organisation

Thema

Gruppen

Aufgaben

Präsentation

Abschluss

Material




Detailed Primary Scenarios, Secondary Scenarios, Activity Diagrams, User Interface Diagrammed

Aufgabe 5

  • Für diese Aufgabe ist nur ein Gruppendokument abzugeben, in das die Individuallösungen eingearbeitet werden.
  • 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.
  • Erstellen Sie eine vollständige Beschreibung eines primary use case ihrer Wahl, wie unten im vollständigen Beispiel ausgeführt. Verteilen Sie die primary use cases in ihrer Gruppe so, dass kein primary use case von mehr als einer Person ausgearbeitet wird.
    • Detaillieren sie einen primary use case mit den dazugehörigen secondary use cases (use case diagramm mit allen beteiligten actors),
    • Ermitteln sie dazu die secondary scenarios.
    • Erstellen sie das dazugehörige Activity Diagram.
    • Erstellen sie das dazupassende Story Board.
Referenzen: 2, 10

Primary Scenarios Wir haben uns, nach eingehenden Diskussionen, dazu entschlossen unser Projekt durchzuführen. Nun müssen wir gewisse Zeit investieren, um die technischen Details unseres Projektes zu verfeinern.

In jedem Use Case werden die Details inkludiert, die benötigt werden, um die geplante Funktionalität des Use Cases zu realisieren. Daher werden wir uns Gedanke über die prinzipielle Funktionalität, Alternativen, Fehlerbedingungen, Voraussetzungen (Preconditions) und Exitbedingungen (Postconditions)machen. Desweiteren kann der Use Case Bedingungen, Verzweigungen und Schleifen beinhalten.

Wir haben in Aufgabe 3 bereits eine Schablone zur vollständigen Beschreibung von Use Cases kennengelernt, aber bis jetzt nur eine kurze Beschreibung des Use Case und die beteiligten Actors hinterlegt. Der nächste Schritt wird sein, die restlichen Punkte zu füllen. Im folgenden die Erläuterungen zu den unterschiedlichen Punkten:

Use Case Name Der Name des Use Case. Es gibt den Vorschlag für den Namen eine Noun-Verb Kombination zu wählen, diese drückt den Sachverhalt und Funktion aus, z.B. ArtefakteAnlegen.

Actors Die Liste der Actors, die mit diesem Use Case kommunizieren, z.B. Erfasser.

Priority Die Angabe, wie relevant dieser Use Case für das betreffende Projekt ist. Für den Wertebereich können sie prinzipiell eie beliebige diskrete Skala wählen, in Aufgabe 2 wurde eine zehnteilige Skala vorgeschlagen, z.B. 1.

Status Gibt den derzeitigen Status der Entwicklung dieses Use Case an. In 0 werden vier Statusausprägungen unterschieden:

  • Facade: Beschreibung auf hohem Abstraktionslevel.
  • Filled: Design des kompletten Use Case.
  • Focused: Narrowing und Prunning des Use Case.
  • Finished: Fine tuning des Use Case.
Nach Aufgabe 3 hätte der Use Case ArtefakteAnlegen den Status Facade, nach Aufgabe 5 wechselt er den Status auf Filled.

Preconditions Drücken aus, was vor dem Use Case stattfindet. Es legt fest, welche Bedingungen erfüllt sein müssen bzw. in welchem Zustand das System sein muss zu Beginn des Use Case, z.B: Der Benutzer muss am System angemeldet sein.

Postconditions Drücken aus, was nach dem Use Case stattfindet. Es legt fest, welche Bedingungen erfüllt sein müssen bzw. in welchem Zustand das System am Ende des Use Case sein muss. Die Postcondition mus wahr sein, egal welcher Weg durch den Use Case gewählt wird, z.B. Das Artefakt ist in der Datenbank gespeichert.

Extension Points Falls mit dem Use Case andere Use Cases über <> assoziiert sind, dann werden diese Use Cases hier angeführt, z.B. ErrorHandling.

"Used" Use Cases Falls mit dem Use Case andere Use Cases über <> assoziiert sind, dann werden diese Use Cases hier angeführt, z.B. Suchen.

Flow of Events (siehe auch Aufgabe 3 ) Ist eine Serie von deklarativen Statements, die die Schritte eines Use Case beschreiben. Alternativen können hier mittels Verzweigungen angeführt werden oder alternativ unter dem Punkt "Secondary Scenarios" aufgelistet werden. Normalerweise wird das Wort if benutzt, um einen alternativen Pfad anzudeuten. Fü Wiederholungen, also wenn gewisse Schritte mehrfach ausgeführt werden sollten, werden i.A. die Wörter for bzw. while benutzt. Das Ende einer Schleife wird durch das Wort end angezeigt. Zu for und while können zusätzlich logische Bedingungen angegeben werden, z.B.

  1. Der use case beginnt mit der Selektion "ArtefakteAnlegen".
  2. Der Benutzer gibt die Inventarnummer eines Artefaktes ein um dieses anzulegen.
  3. Der Benutzer bestätigt die Eingabe.
  4. if (System findet Inventarnummer)
    1. Das System meldet, dass das Artefakt mit der eingegebenen Nummer gefunden wurde.
    2. while (keine neue Inventarnummer eingegeben)
      1. Der Benutzer gibt eine neue Inventarnummer ein, auf die das gefunde Artefakt kopiert wird.
      2. Der Benutzer bestätigt die Eingabe.
      3. Das System sucht nach der eingegebenen Nummer.
    3. end
    4. Das System kopiert das Artefakt auf die neue Inventarnummer.
    5. Das System zeigt die Eingabemaske zur Pflege der Attribute es Artefaktes.
  5. if (System findet keine Inventarnummer)
    1. Das System zeigt die Eingabemaske zur Pflege der Attribute es Artefaktes.
  6. Der Benutzer pflegt die Attribute des Artefaktes.
  7. Der Benutzer sicher das Artefakt oder bricht die Verarbeitung ab.
  8. if (Benutzer bricht Verarbeitung ab)
    1. Das System verlässt die Eingabemaske. Der use case ist beendet.
  9. if (Benutzer sichert Artefakt)
    1. Das System speichert das Artefakt auf die Datenbank und verlässt die Eingabemaske. Der use case ist beendet.

Activity Diagram Wir benutzen Activity Diagrams um die Schritte eines Use Case zu dokumentieren. FOE und Activity Diagrams können alternativ benutzt werden. Jede Aktivität im Use Case wird im Activity Diagram mittels eines gerundeten Rechtecks dargestellt. Übergänge zwischen den Aktivitäten werden mittels Pfeilen dargestellt. Die Übergänge können mit Bedingungen versehen werden, diese werden mit eckigen Klammern umschlossen. Entsscheidungen werden mittels einer Raute dargestellt, wobei von dieser Raute beliebige Pfade ausgehen können. Verzweigungen können "geforked" bzw. "gesplittet" werden. Also wird der Pfad in zwei oder mehrere parallele Pfade aufgeteilt. Um parallele Pfade zusammenzuführen werden "joins" bzw. "synchronisations" Punkte definiert (siehe Kopien im Sekretariat). Für ein Beispiel sieh unten.

User Interface Bei Projekten, die sehr viel mit Kommunikation zwischen Benutzer und System auf GUI Ebene operieren, ist es angebracht, um die Benutzerakzeptanz zu erhöhen, Beispiel für mögliche GUIs zu präsentieren. Durch diese Beispiel können sich u.U. neue Anforderungen ergeben. Mittels der Story Board Technik werden dem Benutzer folgen von Screen präsentiert, als ob er das System benutzen würde. Diese Technik wurde aus der Filmindustrie übernommen.

Secondary Scenarios Zeigen die Alternativen und Ausnahmen zum prinzipiellen Pfad im use case an. Secondary Scenarios werden hauptsächlich dann benutzt, wenn if und while zu komplizierte Konstrukte ergeben würden. Eine Methode um Secondary Scenarios zu finden, sind die folgenden zu stellenden Fragen:

  • Kann eine andere Aktivität zu diesem Zeitpunkt stattfinden?
  • Kann etwas schief gehen zu diesem Zeitpunkt?
Besonders gut geeignet sind Secondary Scenarios, wenn Ereignisse zu jeder beliebigen Zeit auftreten könnten, z.B. Der Benutzer kann zu jeder Zeit mit der CANCEL Taste den Vorgang abbrechen und kehrt zum Ausgangszustand zurück.

Secondary Scenarios

Vollständiges Beispiel

  • ArtefakteAnlegen: 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.
  • Actors: Erfasser.
  • Priority: 1
  • Status: Filled.
  • Preconditions: Der Benutzer muss am System angemeldet sein.
  • Postconditions: Das Artefakt ist in der Datenbank gespeichert.
  • Extension Points: ErrorHandling.
  • "Used" Use Cases: Suchen.
  • Flow of Events: This could be a basic path and alternative paths, or the primary scenario.
    1. Der use case beginnt mit der Selektion "ArtefakteAnlegen".
    2. Der Benutzer gibt die Inventarnummer eines Artefaktes ein um dieses anzu legen.
    3. Der Benutzer bestätigt die Eingabe.
    4. if (System findet Inventarnummer)
      1. Das System meldet, dass das Artefakt mit der eingegebenen Nummer gefunden wurde.
      2. while (keine neue Inventarnummer eingegeben)
        1. Der Benutzer gibt eine neue Inventarnummer ein, auf die das gefu nde Artefakt kopiert wird.
        2. Der Benutzer bestätigt die Eingabe.
        3. Das System sucht nach der eingegebenen Nummer.
      3. end
      4. Das System kopiert das Artefakt auf die neue Inventarnummer.
      5. Das System zeigt die Eingabemaske zur Pflege der Attribute es Ar tefaktes.
    5. if (System findet keine Inventarnummer)
      1. Das System zeigt die Eingabemaske zur Pflege der Attribute es Ar tefaktes.
    6. Der Benutzer pflegt die Attribute des Artefaktes.
    7. Der Benutzer sicher das Artefakt oder bricht die Verarbeitung ab.
    8. if (Benutzer bricht Verarbeitung ab)
      1. Das System verlässt die Eingabemaske. Der use case ist been det.
    9. if (Benutzer sichert Artefakt)
      1. Das System speichert das Artefakt auf die Datenbank und verl&aum l;sst die Eingabemaske. Der use case ist beendet.
  • Activity Diagram:

  • User Interface:

  • Secondary Scenarios: Der Benutzer kann zu jeder Zeit mit der CANCEL Taste den Vorgang abbrechen und kehrt zum Ausgangszustand zurück.
  • Sequence Diagrams: nicht relevant für diese Aufgabe
  • Subordinate Use Cases: nicht relevant für diese Aufgabe
  • View of Participating Classes: nicht relevant für diese Aufgabe
  • Other Artifacts: nicht relevant für diese Aufgabe
  • Other Requirements: nicht relevant für diese Aufgabe

last modified Thursday, 24-Oct-2002 14:39:10 CEST by

rschwaig@cosy.sbg.ac.at