Home
 UML
BuiltByNOF
 Use-Cases

1) Szenarien der Verwendung eines SW-Systems heißen Use-Cases. Generell kann man jede zeitlich zusammenhängende Interaktion eines SW-Systems mit seiner Umwelt (also nicht nur mit Menschen, sondern auch mit anderen technischen Systemen) als Use-Case betrachten.

2) Die funktionalen Anforderungen eines Lastenhefts können als Use-Cases formuliert werden. Die nicht-funktionalen Anforderungen können typischerweise nicht als Use-Cases dargestellt werden.

3) Die Zusammenfassung von Anforderungen zu Use-Cases ist leichter verständlich, als die bloße Auflistung von Anforderungen im Lastenheft. Dies trägt dazu bei, Kunden und Anwender besser in die Erhebung von Anforderungen zu involvieren. Die Darstellung von Anfoderungen als Use-Cases hilft bei der Präzisierung, Vervollständigung und Korrektur von Anforderungen, weil die Darstellung von Abläufen evtl. Lücken und Widersprüche entdecken hilft. Use-Cases stellen einen praktischen Rahmen für Testspezifikationen (funktionale Merkmale) dar.

4) Use-Cases sortieren und priorisieren die funktionalen Anforderungen an ein SW-System. Der Fortschritt der SW-Entwicklung lässt sich an der relativen Anzahl der erfolgreich realisierten Use-Cases besser messen, als an der Prozentzahl realisierter Anforderungen. Entwicklungsprojekte tendieren dahin, effizienter zu sein, wenn mehr Messgrößen überwacht und kommuniziert werden.

5) Use-Cases werden durch die "Detailed Description" genau spezifiziert. Die "Detailed Description" besteht aus
Use-Case-Name
Brief Description   Was passiert im Normalfall ?
Actors Wer startet und wer kommuniziert mit dem Use-case ?
Special Requirements Anforderungen an die Umgebung im Verlauf der UC-Abarbeitung
Priority Wie wichtig ist der Use Case für den Kunden ?
Precondition Welche Bedingung muss beim Start erfüllt sein ?
Basic-Flows Liste der Aktionen beim normalen Ablauf
Alternative Flows alternative Abläufe und Erweiterungen
PostCondition Endbedingung nach erfolgreicher Abarbeitung
Extension Points Bedingungen für Sonderfälle, Erweiterungen und Fehlerbedingungen

6) Aktoren sind die Initiatoren eines use-Case, also diejenigen, die Initiative ergreifen und Use-Cases anstoßen. Damit sind nicht nur menschliche Bediener, sondern u. U.auch technische Systeme gemeint, z.B. Alarmgeber, Schnittstellen, Kommunikations- und Überwachungsprozesse etc.
Aktoren stehen außerhalb des modellierten Systems. Dieses System wird im Normalfall aus mehreren Use-Cases bestehen.

7) Use-Case-Diagramme verbinden die verschiedenen Use-Cases grafisch miteinander und schaffen eine Übersicht über das System, die Use-cases und die Aktoren. UC-Diagramme bestehen aus Symbolen für
boundary
Systemgrenze

actor
Aktor

usecase
Use-Case

uses
uses-Relation (auch "include")

extends 
extends-Relation

uc_extend
extends-Relation mit Bedingung
 

 genspec
generalization-Relation

8) Use-Case-Diagramme werden pro Use-Case erstellt und gelesen: Man klärt zunächst die Aktoren (falls vorhanden) sowie die auslaufenden "extends"-und "generalization"-Beziehungen. Dann liest man die Detailed-Description des Use-Case. Dann sucht man die auslaufenden "uses"-Bezeihungen, sowie die einlaufenden "extends"- Beziehungen. Zum Schluss kann man die einlaufenden "generalization"-Beziehungen ermitteln.


9) Beispiel für Use-Case-Diagramme

uc_system
Anordnung in einem Diagramm


uc_atm_relation
Beziehung zwischen Use-Cases

10) Werden Use-Cases auf der Systemebene eingesetzt, stehen sie (zusammen mit den Detailed Descriptions) auf der Ebene des Lastenhefts. Sie sind leichter VOR dem Lastenheft zu ermitteln, decken jedoch typischerweise nur funktionale Anforderungen ab. Use Cases ersetzen wegen der nicht-funktionalen Anforderungen das Lastenheft nicht, welches weiterhin oft Grundlage der SW-Verträge ist.

11) Die Vorgehensweise, zuerst Use-Cases aufzustellen, and dann für jeden Use-Case nach und nach Requirements im Lastenheft detailliert zu nennen, nennt man "Use-Case-Driven Requierements Engineering". Diese Technik ist zwar sehr gut zur Ermittelung der wichtigsten funktionalen Anforderungen, vernachlässigt allerdings nicht-funktionale Anforderungen, was mit Nacharbeiten behoben werden muss. Weiterhin können sich durch "Use-Case-Driven Requierements Engineering" leicht widersprüchliche Anforderungen einschleichen, die nur in der weiteren Modellierung zu erkennen sind.

12) Referenzen
Managing Software Requirements: A Use Case Approach, 2/E, by Dean Leffingwell / Don Widrig,
ISBN: 0-321-12247-X, Publisher: Addison Wesley Professional, Copyright: 2003, Format: Cloth;
544 pp, Published: 05/05/2003

Applying Use Cases, by Schneider / Winters,  Publisher: Addison Wesley Professional
 

[Home] [UML]