Immagina il sistema principale con i seguenti casi d'uso: una persona può registrarsi e prenotare una stanza.
Allo stesso tempo c'è un'app mobile che è derivata dal sistema principale che abilita le stesse funzioni (registra, prenota una stanza) con alcune opzioni di caso d'uso aggiunte.
Come distinguere questi due sistemi in uno stesso diagramma del caso d'uso?
Nella specifica UML 2.5, la Figura 18.2 nella sezione 18.1.5 è un esempio di ciò che si vuole fare:
Comepuoivedere,puoimostrarepacchettiesottosistemi,senecessario,inundiagrammadeicasid'usoUML.Neltuocaso,probabilmentenonavrestiilpacchetto,maavrestilecaselledidelimitazionedelsistemaidentificateeannotatecomesottosistemi.
Cisonoalcunecosedatenereamente:
Ognidiagrammadeicasid'usodovrebbemostrareunsistema.Sesidisponedidueopiùsistemi,ènecessarioundiagrammadelcasod'usoperciascunsistema.Comesidefinisceciòcheil"sistema" è contro ciò che il "sottosistema" dipende da ciò che si sta costruendo. Potresti voler definire il software che stai guardando come due sistemi o un sistema con almeno due sottosistemi.
Potresti anche essere interessato a una domanda sul polimorfismo nei casi d'uso e la mia risposta . Esistono buoni metodi per mostrare relazioni tra casi d'uso che fanno parte delle specifiche UML formali. Non ci sono modi per mostrare le relazioni tra attori, tuttavia, a meno che non ti interessi di seguire le specifiche.
Il schema dei casi d'uso mostra i casi d'uso offerti agli attori dal sistema sotto considerazione .
In linea di principio non dovrebbe rappresentare la distribuzione tecnica delle funzionalità tra i nodi di elaborazione: questo è per lo schema di distribuzione .
L'assunto qui, è che hai un solo sistema con potenzialmente diversi front-end che offrono ciascuno un diverso insieme di casi d'uso. Potresti quindi prendere in considerazione l'utilizzo di due attori: user e mobile user . Potresti quindi:
mobile user può sempre fare tutto ciò che un user può fare, potresti rappresentare una relazione di ereditarietà tra entrambi gli attori per evitare di ingombrare il diagramma con troppi collegamenti duplicati (anche se questo non è esplicitamente permesso, actor è un classificatore secondo UML2.5 §18.2.1 e come illustrato qui ) Esempio:
Seicasid'usocomunidevonopresentarealcunedifferenzenellefunzionalitàonell'interfacciautente,puoisemplicemente
Se tuttavia vuoi mostrare comportamenti opzionali nel diagramma, puoi pensare a estendere i casi d'uso . Le estensioni consentono di mostrare una variante del flusso normale e di documentare in una nota di commento la condizione di tale estensione.
Tenete comunque presente che UML usa i diagrammi dei casi dovrebbe non essere abusato per la scomposizione funzionale . Un sacco di inclusioni o estensioni specifiche dell'interfaccia utente potrebbero essere un sintomo di tale abuso. Quindi chiediti se hai davvero bisogno di questo livello di dettaglio nel diagramma.
Se si dispone di due sistemi che devono essere considerati distinti tra loro (ad esempio se il sistema di prenotazione è gestito da una terza parte), sono necessari diagrammi dei casi d'uso distinti (uno per ciascun sistema).
Nel diagramma dell'app per dispositivi mobili, mostreresti il sistema remoto come attore secondario (e materializzerai il suo coinvolgimento nei casi d'uso con collegamenti aggiuntivi).
