Use-cases e Controllers

Ciao Gianni,

sto cercando di buttar giù qualche notazione per la stesura dei diagrammi UML per lo sviluppo del mio progetto sullo zend framework, lavorando un pò ho notato che gli use-case diagram si adattano bene alla struttura del framework, mi spiego meglio utilizzando un esempio grafico:

L'attore, Admin in questo caso, può avere accesso ad un caso d'uso "Gestione Utenti" e alle due azioni "Nuovo Utente" e "Modifica Permessi".

In questo modo posso facilmente sviluppare i diagrammi mantenendo la compatibilità con la struttura del framework, in quanto, traducendo l'esempio in codice mi basterebbe fare qualcosa del genere:

//Gestione Utenti
class userManagerController extends Zend_Controller_Action {

    //Modifica Permessi
    public function editPermissionAction() {}

    //Nuovo Utente
    public function newUserAction() {}
}

Una volta steso lo scheletro dei controller a partire dagli use-case passo alla stesura del diagramma delle classi in modo da rappresentare effettivamente tutte le classi che intercorrono al completamento dell'use-case.

Una volta completato il diagramma delle classi con le dovute indicazioni circa il comportamento e le interazioni tra gli oggetti, passo al diagramma di sequenza per la formalizzazione delle azioni da eseguire per il completamento dell'use-case.

Una raccolta di use-case completi (quindi di controllers) posso raggrupparli in un diagramma che rappresenta il modulo.

Mi piacerebbe sapere la tua riguardo questo procedimento.

 :bye:

inviato 8 anni fa
Andrea Turso
Andrea Turso
86
X 0 X

L'UML è un linguaggio di modellazione e come tale si presta a rappresentare qualsiasi cosa poiché il significato dei simboli e dei diagrammi è definito all'interno del team di sviluppo, nonostante ci sia comunque una certa standardizzazione nell'interpretazione di questi simboli.

La mappatura tra il concetto astratto di "caso d'uso" e quello concreto di Controller è un'ottima scelta architetturale, ma ovviamente non si è costretti a seguirla. In azienda usiamo questo stesso approccio, anche se in Java, dove il Controller è la servlet.

Secondo questo approccio però il tuo diagramma è sbagliato, poiché rappresente 2 flussi alternativi del caso d'uso "Gestione Utenti" come se fossero 2 casi d'uso, per i quali però non ci saranno i rispettivi Controller.

 :bye:

risposto 8 anni fa
Gianni Tomasicchio
X 0 X

Cosa posso fare per correggere l'incorrettezza della quale parli?

:bye:

risposto 8 anni fa
Andrea Turso
Andrea Turso
86
X 0 X

togli dal diagramma i casi d'uso "nuovo utente" e "modifica permessi". Se poi decidi di implementare queste funzionalità nel caso d'uso "Gestione Utenti" allora devi descrivere queste due funzionalità come flussi alternativi del caso d'uso "Gestione Utenti"

 :bye:

risposto 8 anni fa
Gianni Tomasicchio
X 0 X

Okay, anche se non mi è ben chiaro cosa intendi con "flussi alternativi".

:bye:

risposto 8 anni fa
Andrea Turso
Andrea Turso
86
X 0 X
Okay, anche se non mi è ben chiaro cosa intendi con "flussi alternativi".

Da dove stai studiando l'UML?

risposto 8 anni fa
Gianni Tomasicchio
X 0 X

Beh ho frequentato un corso a scuola ma non è che sia stato molto esplicativo a causa del disinteresse generale-a parte il mio :P.

Comunque ho acquistato anche un libro, solo che non sono molto soddisfatto: UML e Design Patterns

 :bye:

risposto 8 anni fa
Andrea Turso
Andrea Turso
86
X 0 X

Un caso d'uso è corredato da una descrizione testuale che viene scritta dall'analista. Questa descrizione non è un testo libero ma deve seguire una determinata struttura:

Scopo: breve descrizione del caso d'uso

Precondizioni: condizioni che devono essere verificate affinché il caso d'uso possa essere eseguito

Postcondizioni: condizioni che saranno verificate al termine al termine del caso d'uso

Requisiti accessori: ulteriori requisiti necessari all'avvio del caso d'uso

Flusso principale: azioni eseguite dall'attore e dal sistema durante l'esecuzione del caso d'uso

Flusso Alternativo 1: azioni eseguite dall'attore e dal sistema nel caso, durante il flusso principale, si sia imboccata una strada alternativa

Flusso Alternativo 2:    " "               " "

Flusso Eccezionale 1: azioni eseguite dall'attore e dal sistema in caso di eccezioni verificatesi nel flusso principale o nel flusso alternativo

 :bye:

risposto 8 anni fa
Gianni Tomasicchio
X 0 X

Mmh di questo non mi aveva parlato ^^

Solo una curiosità lavorando con StartUML, che è molto simile a Rational Rose (lo trovo molto più usabile :P di RR in effetti ) Scopo, Precondizioni, Postcondizioni and so on dovrebbero essere descritti dove?

:bye:

risposto 8 anni fa
Andrea Turso
Andrea Turso
86
X 0 X

Nella descrizione del caso d'uso. Purtroppo si tratta di riempire una casella di testo quindi queste informazioni non sono strutturate nell'applicativo.

 :bye:

risposto 8 anni fa
Gianni Tomasicchio
X 0 X

ok, dovrei dare un'occhiata al campo indicato con "Documentazione" ?

Il mio problema credo derivi dal fatto che mi hanno insegnato a leggere quel diagramma in questo modo:

"Admin può accedere a Gestione Utenti, una volta che accede al caso d'uso gestione utenti può Aggiungere i nuovi utenti o modificarne i permessi"

Praticamente ci hanno fatto lavorare sul caso d'uso come se fosse una semplificazione di ciò che l'attore vede.

risposto 8 anni fa
Andrea Turso
Andrea Turso
86
X 0 X
ok, dovrei dare un'occhiata al campo indicato con "Documentazione" ?

Tasto destro sul caso d'uso -> Open specification... -> Documentation

Il mio problema credo derivi dal fatto che mi hanno insegnato a leggere quel diagramma in questo modo:

"Admin può accedere a Gestione Utenti, una volta che accede al caso d'uso gestione utenti può Aggiungere i nuovi utenti o modificarne i permessi"

Praticamente ci hanno fatto lavorare sul caso d'uso come se fosse una semplificazione di ciò che l'attore vede.

In questo modo i casi d'uso si riducono a delle schermate. Questa interpretazione purtroppo è parecchio diffusa.

Invece i casi d'uso sono le funzionalità di valore offerte dal sistema, ovvero le risposte alle necessità espresse dal committente.

 :bye:

risposto 8 anni fa
Gianni Tomasicchio
X 0 X

Non vorrei sbagliare, ma intendi dire che i casi d'uso dovrebbero rappresentare cosa l'applicazione offre in funzione di cosa ha richiesto il committente?

PS: sarebbe interessante avere un "salotto" di ingegneria del software. ;D

:bye:

risposto 8 anni fa
Andrea Turso
Andrea Turso
86
modificato 8 anni fa
X 0 X
Non vorrei sbagliare, ma intendi dire che i casi d'uso dovrebbero rappresentare cosa l'applicazione offre in funzione di cosa ha richiesto il committente?

Si. Infatti quando si stipula un contratto per la realizzazione di un software, l'insieme dei casi d'uso completi di documentazione testuale costituisce una parte dell'accordo stretto tra il committente e la software house.

 :bye:

risposto 8 anni fa
Gianni Tomasicchio
X 0 X
Effettua l'accesso o registrati per rispondere a questa domanda