Questa risposta è stata aggiornata per specifica UML 2.5.1 .
Per prima cosa, sembra che la notazione sia valida.
Gli attori (18.2.1) possono avere solo associazioni per utilizzare case, componenti e classi e queste associazioni devono essere binarie.
La relazione tra amministratore e utente è la generalizzazione (definita in 9.9.7). È una specializzazione della DirectedRelationship (definita in 7.8.5) che è una specializzazione della relazione (definita in 7.8.15). Le specializzazioni di relazione sono DirectedRelationship and Association (definite in 11.8.1). Ciò significa che una generalizzazione non è un'associazione.
L'attore pone delle restrizioni su cosa sia un'Associazione valida. Tuttavia, la definizione di attore non limita altre relazioni, quindi è necessario esaminare la gerarchia delle definizioni per determinare se una generalizzazione è valida.
L'attore è una specializzazione di BehavioredClassifier (10.5.1). Nessuno degli End di associazione definiti copre questo caso, quindi dobbiamo continuare a cercare. Un BehavioredClassifier è una specializzazione di un Classificatore (10.5.1.3). Uno degli estremi di un classificatore di associazione è la generalizzazione. Poiché un classificatore consente la generalizzazione tra i classificatori e un attore è un classificatore senza ulteriori restrizioni sulla generalizzazione, la relazione sembra essere valida.
Vorrei notare che non esiste un diagramma di esempio che mostri una relazione di generalizzazione tra due attori. Inoltre, non c'è discussione nel testo (che potrei trovare) su questa relazione. L'unico modo per conoscerlo è seguire le definizioni formali di attore, associazione e generalizzazione lungo tutta la loro gerarchia.
La prossima cosa da guardare è se questo diagramma avrebbe senso per un lettore.
Formalmente, gli Use Case sono descritti nella Sezione 18 delle specifiche UML - un Use Case è un insieme di comportamenti che un sistema offre, e questo insieme di comportamenti può anche includere variazioni (e le variazioni includono, ma non sono limitate a eccezioni comportamento e gestione degli errori). Informalmente, un caso d'uso è "un elenco di azioni o passaggi di eventi che tipicamente definiscono le interazioni tra un ruolo e un sistema per raggiungere un obiettivo".
Come lettore, se vedessi il diagramma senza alcun testo esplicativo, farei supporre che il comportamento definito dal caso d'uso Authenticate fosse lo stesso sia per l'amministratore che per l'utente. Dopo tutto, entrambi hanno una relazione con lo stesso insieme di comportamenti chiamati Autentica. Non mi aspetto un singolo simbolo su un diagramma per indicare due diversi gruppi di passaggi di eventi.
In UML, i casi d'uso possono essere correlati l'un l'altro, come ad esempio le relazioni Estendi e Include insieme alla generalizzazione. Questi possono essere usati per modificare il comportamento di un caso d'uso.
Credo che tu possa esprimere tutto ciò che vuoi esprimere in un diagramma di caso d'uso UML. Tuttavia, non sono convinto che l'esempio, come presentato nella domanda, sia il modo migliore per comunicare le informazioni alle parti interessate.
Preferirei generalmente evitare l'uso di diagrammi dei casi. Preferirei invece uno dei numerosi metodi testuali o tabellari per catturare casi d'uso, collegandoli tra loro ed estraendo passaggi comuni o informazioni condivise tra i casi d'uso in un'unica posizione. Questo è simile al consiglio fornito da Martin Fowler in UML Distilled .
Se ritieni che sia necessario un diagramma dei casi d'uso, guarderei come rappresento il caso d'uso Authenticate per rendere più chiaro che ci sono in realtà due flussi diversi. Credo che ci siano alcune diverse opzioni qui che sono tutte conformi alle specifiche.
