Use Cases

[sauerpeter]

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]

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]

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]

Es geht quasi nur um die Akteure.

 

[nillehammer]

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]

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]

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]

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]

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]

In ein Feinkonzept schreiben.

 

[nillehammer]

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]

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

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.