[UML] UseCases beschreiben

[Daffi89]

Hi Leute,

Ich beschäftige mich seit langem mal wieder mit UML und bin noch relativ unschlüssig beim Thema UseCases.

Bisher habe ich folgendes modelliert:



Uploaded with ImageShack.us

Dazu habe ich zwei Fragen:

- sind die Anwendungsfälle treffend formuliert? Sprich ist die Tiefe so OK oder genauer? Gibts Fehler bei der Modellierung?
- Soll ich jetzt alle Beziehungen in ein Diagramm modellieren? Das würde ja dann zu unübersichtlich werden ... Wie macht ihr es bei der Modellierung? Für jeden User ein eigenes Diagram?

Danke und viele Grüße
Daffi

 

[Keepers]

Sagt dir der Begriff Rollenbildung etwas?

 

[Tafelmolch]

Hehe, UseCases modellieren ist ein bisschen wie eine Religion. Ein "richtig" oder "falsch" gibt es bis auf ein paar Ausnahmen (richtige Syntax, Verwendung der Assoziationen, etc.) nicht.

Ich kann den fachlichen Hintergrund jetzt nicht so gut nachvollziehen, da ich mir unter "Durable" nichts vorstellen kann, aber generell habe ich mal die Faustregel gelernt, man sollte nicht mehr als 7 (+/- 2) Use Cases auf ein Diagramm packen, da es sonst zu unübersichtlich wird.

Die generelle Benennung der Use Cases scheint zu passen (Substantiv + Verb). Allerdings würde ich schauen, ob du nicht einige Use Cases zusammenfassen kannst. Aufbauend auf das Diagramm kommt ja noch die Use Case Spezifikation in der du beschreibst, was der Use Case genau macht. Das UC Diagramm soll ja nur einen groben Überblick vermitteln.

Vor allem die ganzen includes finde ich persönlich etwas ungeschickt. Die sollte man eigentlich nur verwenden, wenn ein Use Case in mehreren anderen UCs wiederverwendet wird. Bei dir scheinen die alle nur in einem UC verwendet zu werden. Also könntest du sie auch einfach als Schritte oder Alternativpfade in der UC-Spezifikation beschreiben.

 

[Keepers]

Neben dem was Tafelmolch gesagt hat, will ich dann nochmal das mit den Rollen und deiner User Frage nachziehen:

Man schreibt nicht die einzelnen Akteure da hinein, sondern man bildet Rollen.
Diese Rollenhüte zieht sich der Chef, die Putze, der Produktbetreuer, einfach jeder entsprechend auf wenn er den UC ausführt.

Vgl. hierzu UML 2.0 (zB Mario Winter - Methodisch objektorienterte Softwareentwicklung, UML 2.0 glasklar und andere).

De facto gibt es nur einen beschreibenden Anleitungsstandard für die UML, richtig oder falsch liegt irgendwo dazwischen.. Ich kann auch 100h lang modellieren.. Man findet jeden Tag etwas, was man noch ändern kann.

 

[NuminousDestiny]

Ich erkenne zwar auf deinem Bild nich all zu viel, aber folgende Anmerkungen habe ich für dich:

1. Die Tiefe: Ich weiß zwar nicht wie komplex Durable ist, aber so oft wie das dort steht solltest du definitiv über eine Zusammenfassung nachdenken bzw. ein paar extend Fälle...

2.Beziehungen zwischen den UCs und den Akteuren:
Normalerweise nach UML Norm malst du um deine UCs einen Kasten und verpasst dem Ding ne Systemnamen. Dann verbindest du jeden einzelnen UC mit dem zutreffenden Akteur mittels Assoziation.
Externe Systeme die auch relevant sind, sind ebenfalls als Akteure zu erfassen. Diese können sein: DB, Web Server, FremdSystem, Jeglicher Netzwerkkram wie Backbone, DNS-Server, etc.

3.Unterteile dein Diagramm sinnvoll:
Falls du es nicht hinbekommst oder dein Meinung bist die UCs sind grob genug, da diese grob sein sollen, dann unterteile dein System.

4.UC ohne Akteure:
Entweder hast du den Akteur hierzu nicht identifiziert oder es ist kein UC und du kannst diesen löschen.

5.Use-Cases:
Diese sind immer aus Benutzersicht zu erfassen und nicht aus Systemsicht!

Gruß!

 

[Daffi89]

Hey Leute,

Danke für die Antworten.

Also folgendes:

- eine Durable ist schlicht ein Verbrauchsgegenstand ... jedweder Art (meist Produktionsteile).
- die Systemgrenze ist eingezeichnet, leider sieht man sie nicht
- Der UseCase "Durable suchen" ist immer die Grundlage für die anderen Aktionen. Willst du z.B. eine Durable ändern musst du sie vorher suchen ... das wollte ich damit zum Ausdruck bringen (Pfeile falsch herum?).
- Akteure ... das Problem ist das die Akteure meine Rollen bilden. ( Es gibt dabei keinen Admin jeder Akteur kann halt verschiedene Sachen im System...)
- Ich wollt die obrigen 7 Use Cases zusammenfassen zu "Durable verwalten" allerdings ist das Problem das einige Akteure nur auf Teile des Anwendungsfalles zugreifen dürfen (z.b. "Durable ausleihen" möglich aber "Durable anlegen" nicht). Da wusste ich nicht wie ich es modellieren sollte.

Grüße
Daffi

 

[NuminousDestiny]

Hm ja meiner Meinung nach sind die Pfeile falsch. Sie gehören in die andere Richtung und mit einem "extend" bezeichnet.

Use-Cases, die nur teilweise für einen Akteur zutreffen kann man nicht zusammenfassen. Allerdings sowas wie anlegen/editieren/löschen , solltest du unter bearbeiten zusammenfassen können, falls du auch hier Akteure hast, die z.b. nicht alles tun dürften darfst du dir selbst was ausdenken

 

[Daffi89]

Hi Leute,
habe nocheinmal eine neue Version erstellt, Feedback ist willkommen!

Dabei habe ich einige UseCases zusammengefasst.



Uploaded with ImageShack.us

Danke für eure Kritik,
Daffi

 

[Keepers]

'Ticketstatus einsehen' extends 'Ticket eröffnen'

Das erschließt sich mir noch nicht logisch.

Unter (einer) Bedingung(en) beim 'ticket eröffnen' kann ich den Ticketstatus einsehen ?

 

[Daffi89]

Ist in dem Sinne gemeint, dass man ab diesem zeitpunkt den Status einsehen kann.
Wird aber wohl nicht mit Extend gemacht nehm ich mal an

 

[Keepers]

Nee, extend, wie der Name schon sagt, erweitert einen UC unter einer oder mehrerer Bedingungen.

Einen UC einsehen ist aber ein eigenständiges UC dass nichts erweitert um Funktionalität, sondern eine in sich geschlossene Aktion denke ich mal? Alles andere fällt ja wieder unter bearbeiten.