Primi pensieri
Se dovessi usare la generalizzazione qui, un logged user potrebbe fare tutto ciò che un visitor può fare: quindi un logged user potrebbe login (senza uscire) e anche register di nuovo.
Quindi il mio primo consiglio sarebbe quello di usare l'alternativa 1 o l'alternativa 3: mantenere i due attori distinti e non correlati, ma disegnare altri due link (% da% di% a% di% di co_de e% di% di co_de). Ciò chiarirebbe chi può fare cosa.
Ulteriori riflessioni sulla semantica del caso d'uso
Lo standard UML suggerisce che il diagramma del caso d'uso dovrebbe essere indipendente dallo stato interno del sistema:
18.1.3.1:
UseCases define the offered Behaviors of the subject without reference
to its internal structure.
Ma la differenza tra logged user e see item sembra essere completamente dipendente dallo stato del sistema. Quindi non stai davvero mostrando ruoli utente distinti ma più stati utente diversi. Naturalmente, potresti non essere d'accordo con questo punto di vista, perché la semantica di un ruolo non è formalmente definita nello standard UML:
18.1.3.1:
NOTE. The term “role” is used informally here and does not imply any technical definition of that term found elsewhere in
this specification.
Tuttavia, suggerirei di considerare un approccio più user-centrico nella definizione degli attori. Ad esempio potresti distinguere:
-
see item detail che potrebbe vedere gli elementi indipendentemente dal fatto che abbia effettuato l'accesso o meno
-
visitor che è un logged user e può inoltre registrare
-
visitor che è unregistered user e può accedere e acquistare
Concentrarsi sull'utente invece che sullo stato interiore del sistema ha il vantaggio di mettere in risalto l'esigenza di ogni webshop di successo: cosa succede se un visitatore sfoglia gli oggetti, trova un oggetto che desidera acquistare ma si dimentica di accedere? Questo tipo di problemi rimane completamente senza macchia se gli attori devono essere considerati come dipendenti dallo stato. Eppure questi sono tra i principali motivi per cui i clienti non finiscono le transazioni online.
Lettura suggerita: Come evitare le insidie del caso d'uso è un po ' un po 'vecchio e utilizza una versione precedente di diagrammi di UML, ma la maggior parte dei consigli sono ancora rilevanti.
