[UML] Hoe diep te gaan in een use case / activity?

[Verwijderd]

Ik ben momenteel bezig met wat UML diagrammen waaronder use case en activity diagrams.
Ik heb voor mijn opleiding welliswaar een 7 gehaald voor het vak maar zit nu met mijn project toch iets in de knoop. Ik zit nameijk met de vraag hoe diep ik in detail moet gaan. Een voorbeeld is dat er in de tool energieaansluitingen beheerd worden. Maar ook facturen en afwijkingen hierin.

Nou kan ik al deze drie punten apart bij 1 van de 4 actors onderbrengen. Maar ik kan ze ook samenvoegen tot de use cases data beheren, data wijzigingen, data verwijderen.

Voor mijn idee wordt het anders een te onoverzichtelijk diagram. Wat is jullie ervaring hiermee en hoe denken jullie hierover?

[whoami]

-> SE&A

[whoami]

Ik denk dat je niet te 'diep' moet gaan.
Als je je van te voren tot in de details gaat bezighouden met bepaalde structuren, en een bepaald design dan ga je imho veel tijd verliezen in eerste instantie met het designen, terwijl het in een latere fase kan duidelijk worden dat je initieel design helemaal niet goed was. (En dan mag je natuurlijk niet vergeten om al je documenten te gaan aanpassen. )

Ik wil hiermee niet zeggen dat je zomaar direct moet beginnen code kloppen. Het is nl. wel echt belangrijk dat je weet wat de functionele vereisten zijn, en deze op papier zet.
Echter, of het echt nodig is om dit tot in detail in een diagram te verwerken.... Daar stel ik me toch vragen bij. Ik vind een tekst soms al even duidelijk of duidelijker.

[bonzz.netninja]

maar dat is dan gewoon een kwestie van goed uml-en Bij kleine (web)projecten ga ik ook niet uml-en, maar bij echt grote gefaseerde projecten heeft het zeker meerwaarde om dan maar een ontwerp traject in te gaan van meerdere weken.

[Verwijderd]

Nou het is voor mij voor een stageproject. Ik onderzoek de mogelijkheden van standaardpakketten. Die zijn nihil hier komt altijd nog maatwerk bij aan te pas. En ik onderzoek hoe het mogelijk zou zijn als studenten na mij een Functioneel ontwerp van mij gaan uitbouwen.

Onderzoeksrapport + adviesrapport + implementatieplan

Na mij gaat er dus een nieuwe groep aan de gang met de daadwerkelijke bouw van de app. Dus ik moet denk ik idd niet te diep. Moet het nog even met school afstemmen uiteraard, maar ik zit er altijd wat mee te knoeien... hehe

[Verwijderd]

Als ik het goed begrijp hoef jij alleen de high level specificaties op te stellen. Dan is een diagram met 1 of meerder actors op een paar hoofd use cases voldoende. Meer hoeft er in het diagram niet te staan. Tekst is in dit geval meer zinvol om te beschrijven wat de use case high level zouden moeten doen en hoe ze samenhangen. De samenhang tussen de use cases kun je trouwens ook in het diagram kwijt.

De drie use cases die je noemt zijn 1 zogenaamde CRUD use cases: Create Update Update Read. Dit wordt gezien als een "bad practice". Beter zou het zijn om het in 1 use case te vatten, bijvoorbeeld in Beheer Energie Aansluitingen.
In deze use case zou je een verwijzing op kunnen nemen naar de use case Print Factuur en Beheer Afwijkingen (of zoiets).

[Verwijderd]

Het is al een paar keer eerder gezegd, maar ik zeg het graag nogmaals om het te benadrukken:

De Use Case tekst is in veel gevallen belangrijker en interessanter dan het Use Case diagram.

Besteed dus minder aandacht aan het schema en meer aan de beschrijving.

De rest van de tips sluit ik me volledig bij aan.