Fragen du Use-Case Diaggramme..
-
Hallo,
ich schlag mich grad mit Use-Case Diagramme rum und mit sind bisher die beziehungen "include" /"uses" und "extends" bekannt und verständlich.. wie modellierei ich aber nun diese fall:
haben einen Use-Case "Profil bearbeiten" und diese ist dann gesplittet
in "Name eingeben" und "Parameter X eingeben" etc.
so nun meine Frage..
Wenn ich nun das Use-Case "Name eingeben" mit der beziehung "include" mit derm Use-Case "Profil bearbietn" verbinde.. musst oder kann dann der Akteur den name eigneben für das profil? wie modelliere ich als die MUSS oder KANN beziehung also der name kann angegeben werdern muss aber nich!?
-
"Profil bearbeiten" ist ein Use Case. Dieses "Name eingeben" ist, so wie es sich anhört (nämlich dass man einfach irgendwo seinen Namen in ein Textfeld eingibt), gar kein Use Case. Das ist einfach nur ein Bearbeitungsschritt von deinem Use Case "Profil bearbeiten". Nicht mehr und nicht weniger. Da ist nichts mit include. Wenn in diesem Use Case "Profil bearbeiten" der Vorgang der Eingabe des Namens optional ist, dann kannst du in deiner Beschreibung eine Alternative dazu angeben.
Und zum Thema include: Meines Wissens ist es so, dass wenn du in einem Use Case einen anderen includest, dann wird dieser natürlich auch immer durchlaufen (also MUSS und nicht KANN).
Du musst einfach mal unterscheiden was ein Use Case ist und was nicht. Wenn du eine Eingabemaske hast, und dort in ein Textfeld irgendwas eingegeben wird, dann ist das einfach kein Use Case.
-
hmm ok... verstanden
hab ich aber jetzt ein usecase "Profil eingeben"
und würde der Akteur nun irgendwelceh unerlaubte sonderzeichen als name angeben.. muss das ja überpfüft werden... aber da gehört alle nich in ein use- case??
wenn ich nun optional ein fesnter habe das heist "Profil bearbeiten" dann ist da aber ein usecasse quaise ein subsystem??
-
Also es ist schwer zu entziffern was du überhaupt meinst... Aber wie du schon sagtest, die Überprüfung auf unerlaubte Sonderzeichen ist kein Use Case (*). Du musst mal weg von deinem programmlogischen Denken gehen... Wenn du eine Beschreibung zu deinem Use Case machst, musst du aber natürlich, wie schon gesagt, den genauen Ablauf des Use Cases beschreiben, und da wirst du dann auch irgendwas wie folgt stehen haben "Schritt 4: Das System überprüft die Eingaben auf Korrektheit. Bei der Eingabe eines Namens sind folgende Zeichen nicht erlaubt: $,§, ..."
Ist natürlich nur ein Beispiel...Das was du am Ende geschrieben hast, verstehe ich nicht
(*): Also man kann sich natürlich streiten, was nun für jemanden ein Use Case ist und was nicht. Da gibts keine festen Regeln und die Grenzen sind da *sehr* verschwommen. Ich persönlich jedenfalls würde das nicht als Use Case machen. Man läuft oft Gefahr ganz viele kleine Einzelaktionen als einzelne Use Cases zu modellieren, aber das ist halt nicht der Sinn von Use Cases. Sowas erkennt man eben daran, wenn man wie du, z.B. einzelne Use Cases hat, nur um z.B. die Eingabe aus einem Textfeld entgegen zu nehmen.
-
hmm genau die grenzne im BEzug auf das Detail sind sehr verschwommen
wenn ich jetzt eine Formual habe, in dem ich "Profile" anfügen, löschen oder bearabien kann, dann hab ich ja ein quaise 3 use-cases? seh ich das richtrig..
und für das die 2 use-casese "anfügen" und "bearbeiten" könnte ich ja wieder detailierter beschreiben als o mit "Name" , "Parameter" etc. eingeben..
oder soo ich das detail nich beschreiben?? in welchem Teil der OOA oder OOD werden dann die detail genauer beschrieben??UND NOCHWAS: Ein Programmier hat zusätzlich die möglihkeit den Programmcode zu modifizieren .. ist das denn ein Use-Case?? er arbeit nicht mit dem programm sonder am programm..
-
Nein, das Programm umzustricken ist eher kein use-case.
Um use-cases sinnvoll zu definieren solltest Du mehr von Anwenderseite auf das System schauen. Frag dich mal was ein Anwender mit Deinem System erledigen will.
Will er beispielsweise einen Namen eingeben und der soll dann geprüft werden?
- Nein, er will nicht wirklich nen Namen eingeben, nur damit der eingegeben ist. Den muss er vielleicht eingeben, weil er irgendwas anderes erledigen will. Beispielsweise ein neues Profil anlegen.
-
ist es sinnvoll, dass ich zu meinen use-case diagramme auch die use-cases als text verfasse?
-
Für gewöhnlich verwendet man Use Cases doch in der Anforderungsanalyse, also weder OOA noch OOD sondern noch davor! Sie beziehen sich auf die Aufgaben, die die Anwendung erledigen soll, also Aktion des Benutzers und die Reaktion des Systems. Sachen wie "eingegebenen Namen auf Gültigkeit prüfen" würde ich da wahrscheinlich gar nicht mit aufnehmen. Das ist schon viel zu formal; Use Cases sind informell. Die kann man dann in der nächsten Phase, also in der OOA formalisieren, aber dann halt mit anderen Modellierungstechniken, z.B. Aktivitätsdiagrammen oder Sequenzdiagrammen. Und danach dann halt OOD in Form von Klassendiagrammen, Objektdiagrammen, Statecharts etc pp.
Aber es lässt sich natürlich darüber streiten, ob wirklich immer alles in eine Dokumentation gehört. Das solltest Du wie schon gesagt wurde mit deinem Betreuer besprechen. Wenn eben die Resultat der Anwendung im Mittelpunkt steht und nicht der Ablauf der Entwicklung, dann würde ich mich wohl auf das OOD und die fertige Anwendung konzentrieren.
-
das ist sowieo klar.. der betreuer will natürlich zu 70% das fertige programm in seiner funktion und dessen beschreibung haben.. aber es sollte natürlich auch bischen die vorüberlegung und planung ahnad von OOA und OOD beschrieben werden damit man siet das man sich darüber gedanken gemacht hat und dies in die entwicklung einläuft...
habe aber in die OOA was ja im prinzip Analyse bedeutet auch die geamchte analyse planung .. was ich von anfang an mir gedacht habe und wie ich so die tatsaschen und zukünftige funktion der anwendung definiere ahnad von anforderunge etc. stakehoder use-cases prototypen bla bla