L'essenza dei diagrammi dei casi d'uso
https://stackoverflow.com/questions/627871
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianDomanda
Per un compito scolastico, dobbiamo creare un diagramma di Usecase. Ma la documentazione che abbiamo non è molto estesa. Descrive solo i componenti di un caso d'uso e un esempio.
Dobbiamo creare un caso d'uso su un sistema di librerie. Abbiamo trovato 11 casi d'uso, ma non ti darò fastidio con tutti loro.
IIRC, un caso d'uso descrive un uso tipico di un sistema, giusto? Ma quali elementi appartengono a un diagramma del caso d'uso e come si collegano insieme?
Ciò che abbiamo ora sono quattro attori (membro, impiegato, manager e contabile). Quelli con cui abbiamo più problemi sono membri e dipendenti.
Il dipendente è colui che sta usando il sistema. Un membro appartiene ancora qui come attore?
Alcuni casi d'uso che abbiamo:
- Il membro si unisce alla libreria.
- Il membro modifica i suoi record.
- Il membro prende in prestito un libro.
- Il membro divide la libreria (annulla l'iscrizione).
- Il membro prenota un articolo.
- Libro dei resi dei membri.
- Il socio paga (una parte) delle tasse e delle multe.
Quelli diventano casi d'uso sul diagramma. Ma dovrebbero esserci più casi d'uso, ad esempio, il dipendente inserisce il numero membro, il dipendente entra nel numero di libro e così via (usi?).
Qualcuno può far luce (?) una luce su questo?
Modifica Come vengono descritte le sequenze d'azione? Mi è stato detto che puoi vedere un'associazione di usi come una chiamata di metodo a un qualche tipo di routine che ricorre? È giusto? E come viene esteso?
Soluzione
IIRC, un caso d'uso descrive un tipico utilizzo di un sistema, giusto? Ma cosa thin [g] s appartengono a un diagramma di usecase e come si collegano insieme?
I diagrammi dei casi d'uso (sì, un progetto tipico avrà più di uno) dovrebbe probabilmente essere il diagramma più semplice nella tua suite UML. Dovrebbero mappare gli attori / i ruoli che hai definito direttamente nei casi d'uso del tuo sistema. In realtà, dovrebbero concentrarsi principalmente su un singolo attore e includere altri attori solo se devono partecipare a un caso d'uso specifico.
Ecco un esempio che ho lasciato su Google:
Nota la semplicità. Un attore, un sistema, 5 casi d'uso. Nient'altro.
Inoltre, come @Eric P suggerito e la mia immagine di esempio implica che dovresti intitolare i tuoi Casi d'uso con un " [Verbo] [Oggetto] " struttura; vale a dire "membro prende in prestito un libro" diventa " Prendi in prestito il libro " ;. L'oggetto mancante della frase del caso d'uso ("membro") è codificato nel diagramma del caso d'uso come attore con un'associazione al caso d'uso.
Il dipendente è colui che sta usando il sistema. Fa ancora un membro appartiene qui come attore?
Temo che la risposta sia soggettiva. Alcuni diranno di no, poiché poiché il sistema viene utilizzato solo dal dipendente, il dipendente è l'unico attore. Personalmente non sono d'accordo.
Perché? Per uno, i casi d'uso fanno parte della fase di raccolta dei requisiti. Sono lì per aiutarti a organizzare l'eventuale funzionalità del sistema. Ma negare l'attore Member semplicemente perché la tua attuale convinzione è che la tecnologia non verrà utilizzata dal Member è di limitarti in quella fase.
Che cosa succede se il tuo eventuale sistema è automatizzato , il che significa che il Member va su un terminale per controllare un libro da solo? Se hai formulato un'ipotesi durante la raccolta dei requisiti, potresti perdere funzionalità importanti.
Modifica : Come sono le sequenze d'azione descritto? Mi è stato detto che puoi vedere a utilizza un'associazione come una chiamata di metodo a qualche tipo di routine che ricorre? È giusto? E come è esteso usato?
I diagrammi dei casi d'uso sono di alto livello . Dovrebbero mostrare la tua funzionalità di alto livello (nella forma di ciascun caso d'uso) e gli attori che li utilizzano e nient'altro. Non sporcare i diagrammi dei casi d'uso con estensioni e include; quelli dovrebbero essere rari e solo casi speciali. Il più grande errore da principiante che puoi fare (e credimi, ce l'ho fatta!) È provare a modularizzare il tuo codice nel diagramma del caso d'uso. Sì, lo so, è la prima cosa che un programmatore degno del suo sale cerca di fare, ma i diagrammi Use Case non sono il posto adatto.
Per quanto riguarda le sequenze d'azione: in una tipica suite di diagrammi UML, ogni caso d'uso ha associato uno o più Diagrammi di attività . Questi sono all'incirca analoghi a un diagramma di flusso e servono come rappresentazione grafica della tipica struttura narrativa del caso d'uso incoraggiata dalla maggior parte dei libri di testo di ingegneria del software.
Comunque, spero che questo aiuti. Se hai altre domande, sentiti libero di chiedere!
Altri suggerimenti
Mi è stato insegnato che tutti si avvicinano all'uso dei diagrammi di caso sono un po 'diversi, quindi non so se questo si applica a te, ma gli attori sono generalmente quelli che hanno un contatto diretto con il sistema. Quindi un membro non sarebbe un attore a meno che non scansiona la sua tessera della biblioteca o qualcosa del genere perché dovrebbe passare attraverso l'impiegato.
I casi d'uso dovrebbero riguardare tutto, ma non essere molto dettagliati. Quindi il dipendente verificherebbe la presenza di un abbonamento, se non esiste, andrebbe a creare un caso d'uso dell'abbonamento, altrimenti verificherebbe le commissioni in sospeso. Se l'appartenenza è valida, esegui la scansione del libro e così via
Sembra che tu abbia una comprensione fangosa di quali siano i casi d'uso. Ecco alcune risorse per farti andare nella giusta direzione:
L'attore è la persona che utilizza il sistema, quindi se il Dipendente è l'unico a utilizzare il sistema, dovrebbe essere l'attore. Potresti anche avere più attori possibili se ad esempio una funzione è disponibile sia per i dipendenti che per i dirigenti.
Quindi, potresti voler riformulare i tuoi casi d'uso in qualcosa come " Aggiungi nuovo membro " ;, " Alter account account " ;, ecc.
Per quanto riguarda il livello di dettaglio, includerei il maggior numero di dettagli possibile senza ottenere "tecnico". I suggerimenti di Brandon sono piuttosto validi.
