# Use Cases



## sauerpeter (5. Dez 2012)

Hallo Zusammen,

mal eine Frage zu den Use Cases.
Ich entwickle gerade ein Supportsystem. Ein Kunde soll sich einloggen können und Issues anlegen können.

Jetzt mal textuell das Use case dargestellt, nicht bildlich:

Kunde => Probleme anlegen
         => Probleme bearbeiten
         => Probleme anzeigen
         ...

So, wenn ich jetzt "Issue anlegen" näher spezifizieren will, also was der Kunde alles einzugeben hat, welche Daten wichtig, welcher weniger wichtig sind, kann ich dann "Issues anlegen" praktisch als "User" hinschreiben? - hoffe ihr versteht was ich meine 

quasi so:

Issues anlegen => ProblemName eingeben
                    => Produkt eingeben
                    => dringlichkeit eingeben
                    => ProblemBeschreibung eingeben
                    ... 

Versteht ihr was ich meine? Also kann "Issue anlgen" an der gleichen Stelle eines nächsten Use cases stehen, wo voher "Kunde" stand? Oder muss es immer eine Person sein, von dem das alles abgeht?

Danke für eure Hilfe


----------



## Marcinek (5. Dez 2012)

Würde man eher "extends" für nutzen.

Die Frage ist, ob sowas überhaupt in ein Use-Case Diagramm eingetragen werden muss.

---

Ich hoffe, dass das kein Ticketsystem ist, dass auch Produktiv genutzt werden soll ^^


----------



## sauerpeter (5. Dez 2012)

Nee, so meinte ich das nicht.

Ich meine, ob der Akteur (also das Stichmännchen) immer nur eine Person bzw. ein System sein darf?

Oder eben auch ein Prozess, in meinem Fall "Problem anlegen"??


----------



## sauerpeter (5. Dez 2012)

Es geht quasi nur um die Akteure.


----------



## nillehammer (5. Dez 2012)

Akteure sind immer nur Systeme oder Personen. Ein Prozess kann kein Akteur sein. Allerdings läuft der Prozess ja auf einem System. Dieses könnte der Akteur sein.


----------



## sauerpeter (5. Dez 2012)

Hier mal zwei Beispiele, wie ich es meine:

Bild Kunde ist das Ausgangs-Use-Case:
- der Kunde soll Probleme anlegen können
=> jetzt möchte ich "Problem anlegen" näher spezifizieren, d.h. was muss bei "Problem anlegen" alles eingegeben werden, welche felder sind Pflicht, welche nicht, etc.

Bild 2 ist jetzt praktisch "Probleme anlegen":
- hier soll jetzt rein, was beim "Prozess" Problem anlegen gemacht werden muss
=> ProblemName eingeben
=> Problembeschreibung eingeben
=> etc.

Hoffe ich habe es jetzt verständlich beschrieben


----------



## sauerpeter (5. Dez 2012)

nillehammer hat gesagt.:


> Akteure sind immer nur Systeme oder Personen. Ein Prozess kann kein Akteur sein. Allerdings läuft der Prozess ja auf einem System. Dieses könnte der Akteur sein.



Aber wie könnte ich das dann darstellen?


----------



## nillehammer (5. Dez 2012)

> Aber wie könnte ich das dann darstellen?
> ...
> => jetzt möchte ich "Problem anlegen" näher spezifizieren, d.h. was muss bei "Problem anlegen" alles eingegeben werden, welche felder sind Pflicht, welche nicht, etc.


Hinter UseCases verbergen sich i.d.R. Fachprozesse. Dafür würde sich das Aktivitätsdiagramm anbieten.


----------



## sauerpeter (5. Dez 2012)

nillehammer hat gesagt.:


> Hinter UseCases verbergen sich i.d.R. Fachprozesse. Dafür würde sich das Aktivitätsdiagramm anbieten.



Ja ok, das würde eher Sinn machen.
Aber in erster Linie geht es mir ja nicht daraum, den Prozess "Problem anlegen" zu beschreiben sondern vielmehr deren Funktion.

Bleiben wir beim Problem anlegen:

Kunde => Problem anlegen

Das sagt relativ wenig aus, d.h. was muss angelegt werden? Name, Beschreibung, Priorität, Schweregrad etc. Diese Sachen sind bspw. Pflicht, andere Angaben sind nciht Pflicht, bspw. ein Screenshot oder so von dem Problem.

Wie kann man das darstellen, dass bespw. dei Entwicklung genaus weiß, was hinter "Problem anlegen" steckt und wie sie das zu modellieren haben?


----------



## Marcinek (5. Dez 2012)

In ein Feinkonzept schreiben.


----------



## nillehammer (6. Dez 2012)

> Das sagt relativ wenig aus, d.h. was muss angelegt werden? Name, Beschreibung, Priorität, Schweregrad etc. Diese Sachen sind bspw. Pflicht, andere Angaben sind nciht Pflicht, bspw. ein Screenshot oder so von dem Problem.


Hier beschreibst Du (Fach-)Klassen. Dafür sind Klassendiagramme da. Du kannst die Attribute mit sog. Constraints spezifizieren. In der UML hat sich dafür die Object-Constraint-Language etabliert.

Aber, *ich* nutze UML nur noch für die Darstellung fachlicher Aspekte. Mit technischen UML-Spezifikationen habe ich in der Vergangenheit nur viel Zeit verplempert, ohne wirklich einen Mehrwert zu schaffen. Einzig das Sequenzdiagramm finde ich als techniknahes Diagramm ganz gut, um ggf. Probleme bei Nebenläufigkeit zu erkennen. Aber das ist nur meine persönliche Meinung. Ich bin mir bewusst, dass die im Widerspruch zur Meinung vieler Gurus steht...

Alles, was man technisch schön in UML-Diagrammen malt, kann man eigentlich auch direkt in Code spezifizieren. Wenn Du z.B. ein XML-Basiertes Ticketsystem spezifizierst, kannst Du das Problem-Element in xsd beschreiben. Oder ein Java-Interface _Problem_ mit BeanValidation-Annotationen, wenn es Java sein soll oder, oder. Das ist meiner Meinung nach genauso aussagekkräftig wie ein Klassendiagramm und hat den Vorteil, dass es direkt benutzt werden kann.


----------



## maki (6. Dez 2012)

nillehammer hat gesagt.:


> Aber das ist nur meine persönliche Meinung. Ich bin mir bewusst, dass die im Widerspruch zur Meinung vieler Gurus steht...


Sehe ich anders, denke du fährst da die gleiche oder zumindest eine ähnliche Linie wie viele "Gurus" 
UmlAsNotes | Javalobby


			
				Martin Fowler hat gesagt.:
			
		

> UML has got rather out of fashion it seems. Although this isn't good for me financially, I can't say I'm displeased to see a lot of rather dodgy UMLisms going away.


----------

