Anwendungsfalldiagramm

Use Case Diagramm - Anwendungdfalldiagramm

Zweck

In Use Case Diagrammen wird das externe Systemverhalten aus Anwendersicht beschrieben. Use Case Diagramme stellen das geplante System, die Akteure, die Verwendung des geplanten Systems (Anwendungsf√§lle) und die Beziehungen zwi¬≠schen Akteuren und Anwendungsf√§llen dar. Use Case Diagramme geben Auskunft dar√ľber, was ein geplantes System aus Sichtweise der Benutzer leisten soll.

 

Diagrammelemente

Innovator HelpSystem
Das Rechteck stellt das geplante System dar. Der Name gibt den Namen des Systems an. Ein Use Case Diagramm kann auch mehrere Systeme enthalten. Dadurch kann ein System in Teilsysteme gegliedert werden.
Use Case (Anwendungsfall) Eine Ellipse stellt einen Anwendungsfall des Systems dar. Ein Anwendungsfall ist ein in sich abgeschlossener Vorgang, der f√ľr einen oder mehrere Akteure ein beobachtbares Ergebnis liefert. Er beschreibt aus Sicht der Akteure welche Leistungen das System f√ľr den Anwender zur Verf√ľgung stellt. Ein Use Case stellt somit einen Teil der Gesamtfunktionalit√§t des Systems dar. In UML 2.0 kann auch ein Rechteck, das mit einer Ellipse markiert wird, als Use-Case-Symbol verwendet werden. Der Name kann innerhalb oder au√üerhalb des Symbols stehen.
AkteurEin Akteur ist ein Element, das nicht zum geplanten System ge­hört. Er kann eine Person sein, die auf das System zugreift, oder ein anderes System, das mit dem geplanten System kommuniziert. Die UML erlaubt mehrere Symbole zur Darstellung eines Ak­teurs. Er kann als Strichmännchen dargestellt werden. Es ist optio­nal erlaubt ein Klassensymbol zu verwenden, das mit dem Stereotyp <<actor>> markiert wird. Zusätzlich können eigene Symbole verwendet werden um nicht menschliche Akteure darzu­stellen.
AssoziationEine Linie stellt eine Assoziation zwischen einem Akteur und einem Use Case dar. Sie beschreibt den Zugriff des Akteurs auf die Funktionalit√§t, die das System in diesem Use Case zur Verf√ľ¬≠gung stellt, bzw. eine Antwort des Systems an einen Akteur.
include-Assoziation
Bei der include Beziehung verwendet ein Use Case die Funktionalit√§t, die ein anderer Use Case zur Verf√ľgung stellt. Der includierte Use Case wird immer ausgef√ľhrt.  Der Use Case a importiert die Funktionalit√§t des Use Case b.
extendextend-Assoziation
Die extend Beziehung beschreibt die Erweiterung der Funktionalit√§t eines Use Cases durch einen anderen Use Case. Man kann dadurch optionales Verhalten beschreiben, bzw. Funktionen modellieren, die nur unter bestimmten Bedingungen ausgef√ľhrt werden.
Extension point (Erweiterungspunkt)Ein extension point gibt bei einer extend-Beziehung den Punkt an, an dem der erweiternde Use Case im erweiterten Use Case eingeh√§ngt ("aufgerufen")  wird. Es kann eine Bedingung f√ľr den Aufruf angegeben werden. In diesem Beispiel erweitert der Use Case B den Use Case A. Er wird an dem Erweiterungspunkt "ruftB" in A eingeh√§ngt. Der Aufruf erfolgt nur, wenn die Bedingung "wenn Bedingung" zutrifft.

 

Beispiel include und extend Beziehung

 

Dieses Diagramm zeigt ein Beispiel zu einer include und extend Beziehung. Ein "Be¬≠arbeiter" erfasst einen Auftrag; er greift auf den Use Case "Auftrag erfassen" zu. Der Use Case "Auftrag erfassen" includiert (importiert) den Use Case "Kunden pr√ľfen", d. h. bei jedem Erfassen eines Auftrags wird der Kunde gepr√ľft. Inclu¬≠dierte Use Cases werden beim Ausf√ľhren des includierenden Use Case immer aus¬≠gef√ľhrt.

Der Use Case "Auftrag erfassen" hat den extension point "Kunde einf√ľgen". Dieser verweist √ľber die extend-Beziehung und die in der angeh√§ngten Notiz ent¬≠haltene Information auf den Use Case "Kunden erfassen". Das bedeutet, dass der Use Case "Kunden erfassen" nur dann ausgef√ľhrt wird, wenn die Bedingung "Kunde=neu" erf√ľllt ist. Durch die Angabe des extension points bei der Be¬≠dingung wird deutlich gemacht an welcher Stelle des erweiterten Use Case ("Auf¬≠trag erfassen") der erweiternde Use Case ("Kunden erfassen") im Ablauf des erweiterten Use Case eingef√ľgt wird. Die extend Beziehung dr√ľckt also eine optionale Erweiterung eines Use Case aus, die nur unter bestimmten Bedingungen ausgef√ľhrt wird.

Anwendungsbereich

Use Case Diagramme werden zur Festlegung der Anforderungen an ein Softwaresystem  (Anforderungsanalyse, Requirements Engineering) eingesetzt. Use Case Modelle sind leicht verst√§ndlich und ein gutes Kommunikationsmittel zwischen Systemanalytiker, Anwender und Entwickler. Sie legen die Grenzen des Systems fest, die Akteure, die darauf zugreifen und die Funktionalit√§t des Systems. Die Funktionalit√§t wird aus Sicht der zuk√ľnftigen Benutzer des geplanten Systems analysiert und definiert. Implementierungsdetails, wie z. B. die zu verwendende Programmiersprache, Systemarchitektur (Client-Server, ....), usw. sind in diesen Phasen noch nicht wichtig und deshalb zu vernachl√§ssigen.

In der Systemanalyse wird, z. B. in Meetings zwischen Systemanalytikern und Anwendern des k√ľnftigen Systems definiert was das System aus der Sicht der Anwender leisten soll. Die einzelnen F√§lle, die das System abdecken soll, werden als Use Case in die Diagramme eingezeichnet und beschrieben.
Ein Use Case Diagramm stellt also eine grobe Skizze des Systems dar, das den Zweck des geplanten Systems angibt, seine Grenzen und Schnittstellen, die auf es einwirken. Alle modellierten Elemente sind in einer Spezifikation zu beschreiben. Die Spezifikation sollte das Verhalten im Normalfall, mögliche alternativen Ab­läufe und das Verhalten im Fehlerfall enthalten.

Zusammenhang

Die Use Cases stellen jeweils eine Menge von Systemfunktionen dar. Diese Funktionen sind in einem Projekt genauer zu beschreiben. Diese Spezifikation der Use Cases kann in Form von anderen UML-Diagrammen (Verhaltensdiagrammen) erfolgen, oder als struk¬≠turierter Text hinterlegt werden. Stehen die Gesch√§ftsprozesse im Vordergrund, so k√∂nnen Aktivit√§tsdiagramme verwendet werden. Damit k√∂nnen die Abl√§ufe der Use Cases pr√§zise beschrieben werden. Einzelne Szenen k√∂nnen in Sequenzdiagrammen oder in Kommunika¬≠tionsdiagrammen modelliert werden, wenn die Interaktion von Objekten eine wichtige Rolle spielt. Interaktions√ľbersichtsdiagramme k√∂nnen verschiedene In¬≠teraktionsdiagramme einem Use Case zuordnen.

Die Use Case Spezifikationen enthalten wichtige Informationen f√ľr das zu entwi¬≠ckelnde System. Aus den Spezifikationen k√∂nnen erste Klassenkandidaten f√ľr das statische Modell abgeleitet werden.

 

Hinweise f√ľr die Praxis

Identifikation der Akteure

In der Anforderungsanalyse ist es n√∂tig die Akteure zu identifizieren und zu benennen. Dabei m√ľssen die Fragen beantwortet werden:

  • F√ľr wen wird das System entwickelt?

  • Wer soll das System benutzen?

  • Mit welchen anderen Systemen soll das geplante System interagieren?

Identifikation der Systemgrenzen

Die Use Cases sind Teil des Systems und enthalten die Funktionalit√§t des zuk√ľnf¬≠tigen Systems. Akteure sind Elemente, die nicht zu dem System geh√∂ren und auf das System zugreifen. Das System grenzt die Elemente, die zum System geh√∂ren von Elementen, die nicht zu dem System geh√∂ren ab. Alle Elemente innerhalb des Systems geh√∂ren zu dem System und sind zu entwickeln. Elemente au√üerhalb des Systems greifen auf das System zu.

Identifikation der Use Cases

Use Cases beschreiben den Zweck, f√ľr den ein System entwickelt wird auf einer hohen Abstraktionsebene. Sie beschreiben die Leistung, die ein System f√ľr den Benutzer erbringt.

Folgende Fragen sind zur Identifikation von Use Cases hilfreich:

  • F√ľr welchen Zweck soll das System eingesetzt werden?

  • Wof√ľr will der sp√§tere Benutzer es einsetzen?

  • Durch welches externe Ereignis wird ein Use Case angesto√üen?

  • Welches Ergebnis liefert ein Use Case dem sp√§teren Nutzer?

 

Spezifikation der Use Cases

Zur Spezifikation von Use Cases ist es vorteilhaft strukturierten Text zu verwenden. Die Textstruktur könnte folgende Abschnitte enthalten:

  • Name des Use Case

  • Ausl√∂sendes Ereignis

  • Vorbedingungen

  • Verhalten im Normalfall

  • Verhalten im Fehlerfall

  • Nachbedingungen

  • Ergebnis

 

Identifikation der Beziehungen zwischen Akteuren und Use Cases

Zur Identifikation der Beziehungen hilft die Beantwortung folgender Fragen:

  • Auf welche Use Cases greift ein Akteur zu?

  • Welche Antworten erh√§lt er vom System?

  • √úber welche externen Ereignisse muss ein Use Case informiert werden?

 

Style Guide

  • Akteure und Use Cases sollten niemals in einem Diagramm isoliert sein (ohne Bezug zu anderen Modellelementen).

  • Ein Use Case Diagramm sollte nicht mehr als ca. 10 Use Cases enthalten. Bei zu vielen Use Cases wird das Diagramm un√ľbersichtlich. Zu viele Use Cases in einem Diagramm sind ein Hinweis darauf, dass die Granularit√§t der Use Cases nicht korrekt gew√§hlt wurde. Sollte das System zu gro√ü sein, ist es sinnvoll es in Teilsysteme zu zerlegen und in mehrere Use Case Diagramme zu verteilen.

  • Kreuzungen zwischen Assoziationen sind zu vermeiden.

  • Akteure sind au√üerhalb des Systems einzuzeichnen.



 

Beispiel

 

 

Spezifikation

Name des Use Case: KarteLaden

Auslösendes Ereignis: Kunde schiebt eine Karte in den Automat

Verhalten im Normalfall: Der Automat liest und pr√ľft die Karte. Ist die Karte g√ľltig, so zeigt er dem Kunden den Betrag, der noch auf der Karte gespeichert ist auf dem Display an. Ist die Karte ung√ľltig, wird sie wieder ausgeschoben. Ist die Karte g√ľltig, kann der Kunde Geld in den Automaten einschieben. Das Geld wird auf Echtheit √ľberpr√ľft. Ist das Geld echt, wird der Betrag des eingelegten Geld¬≠scheins zu dem Restbetrag, der noch auf der Karte gespeichert war, addiert und der Gesamtbetrag angezeigt. Wird das Geld vom Automaten nicht als echt akzep¬≠tiert, so schiebt er den Schein wieder aus. Der Kunde kann keine oder mehrere Geldscheine einschieben. Dr√ľckt der Kunde die Taste Quittieren, wird der aktuelle Betrag auf der Karte gespeichert und die Karte wird vom Automat ausgeschoben. Hat der Kunde kein Geld eingeschoben, erh√§lt er die Karte unver√§ndert zur√ľck.

Verhalten im Fehlerfall: Lässt ein Kunde seine Karte länger als eine Minute in dem Automat, ohne ihn zu bedienen, dann schiebt der Automat die Karte wieder aus.

Fällt während der Benutzung der Strom aus, dann schiebt der Automat nach Wiederkehr des Stroms Karte und Geld wieder aus. Der Geldbetrag auf der Karte bleibt unverändert.

Ergebnis: Der Kunde erh√§lt seine Karte zur√ľck.



Name des Use Case: EssenZahlen

Auslösendes Ereignis: Kunde steht mit beladenem Tablett an der Kasse

Verhalten im Normalfall: Die KassenFrau tippt das Essen in die Kasse. Der zu zahlende Gesamtbetrag wird auf dem Display angezeigt. Der Kunde schiebt seine Karte ein. Der Betrag, den das Essen kostet, wird abgebucht. Ist auf der Karte nicht mehr genug Geld gespeichert, wird eine entsprechende Fehlermeldung auf dem Display ausgegeben. Die Karte wird ausgeschoben.

Verhalten im Fehlerfall: Ist die Karte f√ľr die Leseeinheit des Automaten nicht lesbar, so gibt er eine Fehlermeldung auf dem Display aus. Die Karte wird heraus geschoben. F√§llt der Strom aus, w√§hrend eine Karte im Automat ist, wird die Karte noch Wiederkehr des Stroms heraus geschoben. Der Bezahlvorgang muss wieder¬≠holt werden.

Ergebnis: Der Kunde hat das Essen bezahlt und erh√§lt die Karte zur√ľck.