E' il mio primo post per cui rivolgo innanzitutto un saluto a tutti.

Sono alle prese con il mio progetto con UML e ho difficoltà a scrivere gli use case, nel senso che sono condizionato dall'idea che ho di COME il programma dovrà lavorare e questo mi crea confusione. Probabilmente è normale, dato che è il mio primo approccio, ma vi chiedo un aiuto per chiarirmi un pò le idee.

Vi illustro brevemente il contesto e come dovrà funzionare il software.

Devo sviluppare un piccolo software per la gestione della posta in uscita.

La registrazione di una nuova spedizione deve avvenire in questo modo (è un vincolo che mi è stato imposto) :

1) l'addetto inserisce il numero di protocollo del documento da spedire; l'inseriemnto deve avvenire con autocompletamento, per cui il sistema propone ed aggiorna l'elenco dei numeri di protocollo  man mano che l'utente digita i caratteri.

2) se il numero di protocollo è in elenco allora lo si seleziona e il sitema recupera i dati mancanti (oggetto, data del documento e ufficio mittente) altrimenti l'addetto dovrà inserire questi dati manualmente (al termine il sistema salva i dati del nuovo documento).

3) se ci sono altri documenti da inviare con la medesima spedizione allora si ripetono i punti 1 e 2

4) l'addetto inserisce il nominativo del destinatario e ,durante la digitazione, il sistema mostra l'elenco dei nominativi simili e relativi indirizzi.

5) l'addetto seleziona il nominativo dall'elenco (e il sistema aggiorna l'indirizzo sul form) oppure inserisce nomintivo e indirizzo (il sistema provvede al salvataggio del nuovo destinatrio)

6) l'adetto indica la modalità di invio (posta ordinaraia, raccomandata, etc) e quindi salva

  Grosso modo questo aspetto riesco a modellarlo. Poi i è stato chiesto se fosse possibile dare la possibilità di iinserire più destinatari per gestire il caso di invio di un unico documento a più soggetti con una sola operazione di inserimento dati.

Questo tipo di varianti vanno comunque descritte nello use-case?

Concettualmente una spedizione riguarda comunque un solo destinatario, solo che per velocizzare l'inseriemento dei dati si vuole poter specificare più destinatari inun unico passaggio. Questo aspetto non riguarda più COME lavora il software piuttosto che COSA fa?

Spero di essere stato chiaro e che possiate chiarirmi le idee. Grazie.

Concettualmente una spedizione riguarda comunque un solo destinatario, solo che per velocizzare l'inseriemento dei dati si vuole poter specificare più destinatari inun unico passaggio. Questo aspetto non riguarda più COME lavora il software piuttosto che COSA fa?

Hai assolutamente ragione.

Lo UC diagram dovrebbe rapresentare a grandi linee gli aspetti del sistema come viene visto dall'esterno (e questo mi pare tu lo sappia meglio di me).

Nessuno ti pone dei limiti su ciò che devi rappresentare: sta nel tuo buon senso ed esperienza "il dove fermarti" per non complicare troppo un modello che rischia poi di non essere più aggiornato.

A me, quello descritto, sembra più un dettaglio implementativo, quasi esclusivo della GUI, quindi eviterei di rappresentarlo. Se vuoi tenerne traccia, utilizza un interaction diagram o un diagramma simile.

Spero di esserti stato di aiuto.

---

Antonio Santise
Consultant ( simply developer :) )
Ugiblog: blogs.ugidotnet.org/theswra

theswra:

[liuc] Concettualmente una spedizione riguarda comunque un solo destinatario, solo che per velocizzare l'inseriemento dei dati si vuole poter specificare più destinatari inun unico passaggio. Questo aspetto non riguarda più COME lavora il software piuttosto che COSA fa?

Hai assolutamente ragione.

Lo UC diagram dovrebbe rapresentare a grandi linee gli aspetti del sistema come viene visto dall'esterno (e questo mi pare tu lo sappia meglio di me).

Concordo con il senso generale del post di theswra, ma ritengo che non sia quella la definizione di UC, da cui forse il dubbio iniziale.

Use cases e use case diagram sono artefatti introdotti dalla object oriented analysis (OOA) e si collocano ad un livello *gia'* tecnico, cioe' modellano il sistema e COME esso deve funzionare. Sono a tutti gli effetti e per definizione una vista interna, per quanto una vista sul confine fra sistema e ambiente.

Data questa (sommaria) definizione, due considerazioni:

-- Ad un livello piu' alto, il cosiddetto livello business, i processi si documentano ma con altri formalismi: Flow Diagrams (FD) + ERD e pochi altri ammennicoli (es. BR/NFC di alto livello), con l'avvertenza che la "D" in ERD sta per i dati di livello aziendale (entita' di business), e FD puo' diventare una gerarchia di FD.

Comunque questo e' il livello del COSA, ed e' anche il livello che produce quella analisi di livello business che dovrebbe fare da input alle fasi successive. Da questo segue:

-- Al livello di OOA, da una parte hai l'input della business analysis. Sul livello di dettaglio a cui arrivare nella specifica, personalmente la vedrei in un'ottica "agile": si tratta di definire il sistema nei suoi aspetti essenziali, dove "essenziale" sta per pronto ad essere passato in produzione.

Ad esempio, nel caso che riporti sopra e come anche theswra mi pare suggerisca, in sintesi sta a te sta trovare il livello adeguato di astrazione vs. dettaglio, "adeguato" a partire dallo scopo del documento.

Se lo usi per comunicare con il cliente (cosa a rigore non troppo corretta, come ho evidenziato sopra, perche' dovremmo essere al livello di COSA e non di COME) ti conviene stare sull'astratto (diagrammi piu' semplici e piu' semplici da leggere) e avere, magari, un unico generale concetto di "spedizione", dove gli aspetti che ti limiti a dettagliare sono quelli e solo quelli strettamenti legati al business, e ai dettagli procedurali su quali bottoni esattamente dovranno essere premuti in quale sequenza ci si pensa dopo, magari davanti ad un prototipo...

Se lo scopo invece e' andare in produzione, allora -- di nuovo -- credo che theswra ti abbia gia' risposto: piuttosto che forzare gli U.C. e le descrizioni pseudo-formali annesse, affiancalo con altri tipi di rappresentazione. In un'ottica agile -- e al contrario del livello business dove vale una regola diversa e per certi versi opposta -- ti direi comunque di focalizzare l'attenzione solo sui dettagli che lo richiedono piuttosto che impelagarti nell'idea di poter avere un sistema completamente documentato. Remember: siamo al livello di COME qui, non di COSA, e quel che conta in ultima analisi e' avere un sistema funzionante che soddisfa le esigenza del committente.

Si potrebbero aggiungere un altro milione di cose, spero di aver dato ulteriori spunti.

-LV

P.S.

Per completare il quadro, preciso che qui siamo nel contesto della cosiddetta (nomenclatura tutt'altro che standard) ingegneria dei sistemi informatici, con FD+ERD come formalismi di base. Esiste un ramo complementare che e' quella della ingegneria del prodotto informatico (tipo l'approccio di chi realizza uno specifico programma per la distribuzione) dove i formalismi di base sono altri e solo superficialmente simili (e ironicamente molto meglio noti sotto il nome collettivo di analisi strutturata, che e' propriamente un misnomer): DFD+ERD.

Che fine hanno fatto le CRC per la raccolta requisiti? Direi che e' un'altra storia... :)

---

Julio Di Egidio
Analyst Programmer
http://julio.diegidio.name

(Peace X Love] = [++1)

Hai usato tanti acronimi che erano finiti nel mio dimenticatoio :). Altri non li conoscevo.
Di fatto, ritieni che lo UML sia sufficiente a descrivere gli aspetti che si propongono di descrivere i DFD, ERD, ecc? Magari non nello stesso dettaglio.

Altra cosa: in genere al cliente si fa vedere qualche Use Case Diagram e qualche Interaction Diagram, giusto per fargli avere una idea di come/cosa farà il sistema. In pratica cerco di utilizzare UML come una sorta di schizzo iniziale. Questo nella migliore delle ipotesi.
Ritieni che lo use case diagram sia già al livello tecnico di COME fa il sistema? Io li ho sempre utilizzati per avere una vista di insieme. Non che questo significhi che abbia ragione, ovvio.

---

Antonio Santise
Consultant ( simply developer :) )
Ugiblog: blogs.ugidotnet.org/theswra

Grazie per i vostri interventi.

Il mio progetto, data la sua semplicità, non avrebbe nemmeno bisogno di una vera progettazione (escludendo il database e poco più).

Lo sto usando come esercizio per cercare di tirar fuori i vari "artifact" previsti da Unified Process (ho preso come riferimento il libro di Larman "Applying Uml And Patterns- An Introduction To Object-Oriented Analysis And Design And The Rup" quindi metto insieme Rational Unified Process, UML e analisi ad oggetti).

Da quanto mi pare di aver capito, indiendentemente dalla metodologia utilizzata, il livello di dettaglio adottato fa passare dal COSA fa il sistema al COME lo fa.

Un dubbio che mi resta è questo : ipotizziamo che una operazione di sistema (funzionalità) si la creazione di un nuovo documento, e che questa richiede l'indicazione della data, dell'oggetto, del numero di protocollo e dell'ufficio che lo ha emesso; inseriti questi dati si procede ad aggiungere l'elenco dei destinatari.

da qualche parte nel sistema ci sarà un bottone "Crea uovo Documento" cliccando il quale si apre un form in cui si trovano tre campi per inserire la data, l'oggetto e il numero di protocollo e una combobox dal quale selezionare l'ufficio. Nello stesso form una griglia consente l'inserimento dei destinatari.

un ipotetico Sequence Diagram potrebbe essere :

                                                                  SISTEMA                                           doc:DOCUMENTO
creaNuovoDoc(Data,Oggetto,NumProt,Ufficio)--->|----create(Data,Oggetto,NumProt,Ufficio)---->|           dest:Destinatario  
                                                                      |                                                                | ---crete()------>|
                                                                                                                                                     

dest:elenco destinatari per il documento

questo implica che la classe Documento deve avere un costruttore con que parametri?

quando creare listanza di documento? Se la si crea all'apertura del form quei dati ancora non si dispongono per cui forse è più corretto indicare una operazione generica Create() giusto per creare la gerarchia di classi e poi associare i dati con un metodo (impostaDati(data,Oggetto,Protocollo,Ufficio)).

Si potrebbe,però, decidere anche che una volta inseriti i dati in questione si debba salvare il documento prima di procedere all'inserimento dei destinatari.

 Questo modo di ragionare però, non mischia ,ed è qui che probabilmente sbaglio, il COSA e il COME?

Ad un livello più alto (per comunicare con il cliente) potrebbe andar bene lo schema illustrato, ma forse per comunicare con uno sviluppatore lo schema andrebbe modificato. O no?

theswra:

> Di fatto, ritieni che lo UML sia sufficiente a descrivere gli aspetti che si propongono di descrivere i DFD, ERD, ecc? Magari non nello stesso dettaglio.

Ritengo di no, e che anzi qui stia parte dell'inghippo.

Il COSA sta da una parte, e' il livello concettuale, e corrisponde all'incirca all'analisi e specifica dei requisiti. A questo livello si usano FD+ERD (o DFD+ERD, ma non e' il nostro caso). Dall'altra parte c'e' il COME, il livello cosiddetto tecnico, dove puoi avere diversi approcci, di cui il piu' diffuso al momento nel mondo enterprise e' fortemente OO (OOA+OOD+OOP+OOT). A tale livello tecnico si usano altri formalismi che nel caso dell'approccio OO sono stati per lo piu' integrati nello standard UML. Ma lo standard UML originariamente non era vincolato a nessuna metodologia specifica e che abbia preso questa piega lo trovo solo un forte limite.

In ogni caso, non e' una questione di livello di dettaglio perche' non c'e' continuita' fra i due mondi. Un ERD di livello business contiene informazioni diverse sia da quelle di un ERD di livello tecnico da passare al DBA, sia da un class diagram, e non mi riferisco al livello di dettaglio bensi' proprio alla natura delle informazioni raccolte. Tant'e', giusto per fare un esempio, che un ERD di livello business non presenta tabelle e campi, bensi'  le entita' di business e le loro relazioni, indipendentemente che si tratti di fax, transazioni su internet o lettere arrivate per posta ordinaria. Insomma, due livelli diversi che non hanno niente a che spartire, e se poi passiamo a confrontare un FD, cioe' la specifica del flusso dei processi, con cio' che ci mette a disposizione OO, non troviamo neanche piu' corrispondenti plausibili e gli use case sono un ben goffo strumento da questo punto di vista.

Dunque, da una parte il formalismo preferenziale per fare analisi concettuale resta quello canonico di cui sopra (FD+ERD per i sistemi informativi), e tentare di usare i diagrammi OO, che sono diagrammi tecnici a uso interno, e' una forzatura. D'altra parte, anche restando all'ambito strettamente tecnico, non esiste solo OO e il quadro che ho fatto sopra e' comunque molto superficiale: tanto per dirne una, l'impedence mismatch, che osserviamo al livello di codice contro il modello relazionale negli approcci fortemente OO, lo ritroviamo a livelli piu' concettuali nel fatto che non c'e' un mapping naturale fra la rappresentazione del dominio del problema e una specifica di tipo OO.

> Altra cosa: in genere al cliente si fa vedere qualche Use Case Diagram e qualche Interaction Diagram, giusto per fargli avere una idea di come/cosa farà il sistema. In pratica cerco di utilizzare UML come una sorta di schizzo iniziale. Questo nella migliore delle ipotesi.

La migliore delle ipotesi sarebbe usare i formalismi di cui sopra, anche perche' usare i formalismi sbagliati spesso contribuisce a discutere e documentare le cose sbagliate. E, lo ripeto: non e' tanto che usi OO contro non-OO, e' che stai usando formalismi tecnici per discutere e documentare aspetti concettuali.

> Ritieni che lo use case diagram sia già al livello tecnico di COME fa il sistema? Io li ho sempre utilizzati per avere una vista di insieme. Non che questo significhi che abbia ragione, ovvio.

Ritengo di si' e non lo dico io, lo dice l'ingegneria del software! :) Comunque vai tranquillo, al livello concettuale si sopravvive anche con una penna e un fazzoletto di carta. FD+ERD per i sistemi e DFD+ERD per i prodotti sono semplicemente i formalismi che condensano al meglio semplicita' ed efficacia relativamente alle esigenze della discussione e della specifica concettuali.

-LV

---

Julio Di Egidio
Analyst Programmer
http://julio.diegidio.name

(Peace X Love] = [++1)

liuc:

> Da quanto mi pare di aver capito, indiendentemente dalla metodologia utilizzata, il livello di dettaglio adottato fa passare dal COSA fa il sistema al COME lo fa.

Non e' cosi', come dovrebbe essere chiaro dalla mia precedente replica a theswra. Aggiungo che e' il COSA del _problema_ vs. il COME della _soluzione_. In entrambi compare "il sistema" ma con ruoli completamente diversi: nel primo caso lo vediamo dall'esterno, nel contesto degli scenari di processo in cui eventualmente funge da strumento (e nessuno ci impedisce di documentare processi completamente manuali se e' per questo); nel secondo caso e' il sistema stesso o uno degli enne sistemi che stiamo specificando, quindi una vista interna.

> [...] Si potrebbe,però, decidere anche che una volta inseriti i dati in questione si debba salvare il documento prima di procedere all'inserimento dei destinatari. Questo modo di ragionare però, non mischia ,ed è qui che probabilmente sbaglio, il COSA e il COME?

Si', trovo anch'io che, piu' che essere troppo dettagliato, stai mischiando informazioni concettuali con dettagli tecnici.

> Ad un livello più alto (per comunicare con il cliente) potrebbe andar bene lo schema illustrato, ma forse per comunicare con uno sviluppatore lo schema andrebbe modificato. O no?

Direi che e' appunto il contrario: quello che hai mostrato sopra assomiglia molto di piu' a un documento di design che ad un documento di analisi in ogni caso.

-LV

---

Julio Di Egidio
Analyst Programmer
http://julio.diegidio.name

(Peace X Love] = [++1)

LudovicoVan:

Aggiungo che e' il COSA del _problema_ vs. il COME della _soluzione_.

Forse e' il caso di approfondire un attimo su questo punto: Il processo software e' estremamente complesso e sfaccettato su molteplici livelli. Il COME di cui abbiamo parlato e' il lato tecnico vs. il lato concettuale di livello business. Tale COME pero' si suddivide a sua volta in un COSA-COME tecnico dove il cosa e' "analisi tecnica" propriamente detta (es. la OOA) e serve a costruire una base per lo sviluppo che faccia anche da ponte di collegamento con i requisiti a monte. Tuttavia e' il COSA di un COME, cioe' appunto analisi tecnica. Quanto al COSA del livello business, anche lui ha un suo COSA-COME incapsulato. In generale, si tratta del pattern problema-soluzione che si replica a tutti i livelli e sottolivelli del processo software piuttosto che un pattern lineare di tipo input-output fra fasi di un processo piatto. Anche il "coder", in generale, fa analisi e disegno per poter scrivere codice, in modo da specificare i COSA e COME che lo riguardano rispetto al modulo o alla funzionalita' da sviluppare (banalmente, gia' quando chiede "cosa devo fare" sta facendo la sua dose "locale" di analisi). C'e' dunque una gerarchia di scomposizione, ma non e' semplicemente lineare tipo uno zoom attraverso livello di dettaglio successivi. Ogni livello prevede una elaborazione e trasformazione che produce i deliverables da passare alla fase successiva. Tali deliverables passano poi per un processo simile a produrre un altro stage di deliverables tendenzialmente piu' vicino alla soluzione finale. E cosi' via in parallelo tutti ad iterare con tutti. Personalmente ritengo che sarebbe corretto dire che il processo software e' frattale, con la coppia COSA-COME (analisi-sviluppo) a fare da elemento base, ma sto ancora lavorando ad una formalizzazione del concetto... ;)

Riepilogando, assomiglierebbe a qualcosa del genere:

Committenza (problema) ->

    -> { Analisi business (specifica dei requisiti di business) ->

        -> [ Analisi tecnica (specifica dei requisiti di implementazione) ->

            -> Coding/Design/Testing (sviluppo in senso stretto) ] } ->

    -> Sistema/Prodotto (soluzione)

Analisi tecnica e' sul confine dove il concettuale viene trasformato in tecnico, ma dal lato gia' tecnico.

-LV

---

Julio Di Egidio
Analyst Programmer
http://julio.diegidio.name

(Peace X Love] = [++1)