Software Engineering PS (WS2000/2001)
© Copyright 2000, Schwaiger Roland
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.
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.
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 <
"Used" Use Cases Falls mit dem Use Case andere Use Cases über <
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.
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:
Secondary Scenarios
Vollständiges Beispiel
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.
