Alcuni consigli sulla stesura del progetto

1. Scopo della materia è insegnare come si progetta un software, non come lo si codifica. Per questo, tutte le tesine che vengono svolte DOPO aver eventualmente  realizzato il software falliscono totalmente nel raggiungere gli obiettivi del corso (con conseguenti risultati dell'esame)
2. Ricordo a tutti che l'interfacciamento del linguaggio JAVA con i database è possibile con estrema facilità  grazie al JDBC (vedi sito relativo a Java). Sono sconsigliate soluzioni basate su pagine web dinamiche ASP o php in quanto violano lo spirito del corso e falserebbero gli obbiettivi di valutazione posti per la tesina. Infatti, la metodologia di progettazione studiata nel corso non è adatta alla progettazione di soluzioni web-based.
3. Con riguardo al documento contenente la scaletta di massima del progetto, preciso che nel capitolo 2 (Project Organization) va inserita (nei relativi paragrafi) la pianificazione effettuata con l'uso del MS Project (programma e licenza sono disponibili per gli studenti del corso).
   
4. Le tesine proposte come esempio non sono esenti da errori. Esse vanno esaminate con molto spirito critico e in nessun modo devono sostituire il libro di testo che rimane la fonte di consultazione più attendibile.
    
5. Scaletta proposta per le tesine:

- Problem Statement
- Software Project Management Plan (SPMP)
- Requirements Analysis Document (RAD)
- System Design Document (SDD)
- Object Design Document (ODD)

6. ODD per le tesine ridotte: A partire dal codice generato con il CASE tool (quello che va compilato!), aggiungere i commenti in JAVADoc come studiato. Si noti che il diagramma delle classi raffinato da cui si genera il codice fa parte del'ODD.
7. Uno degli obbiettivi del corso è sviluppare la capacità  di lavoro in gruppo degli studenti (abilità  fondamentale del software engineer), per questo è vietata la presentazione di tesine individuali. Gli studenti sono invitati a prendere accordi per tempo con i colleghi al fine di predisporre l'attività  di gruppo necessaria. Gli studenti che alla data fissata non si fossero organizzati in gruppi verranno associati dal docente a gruppi composti a partire dalla lista degli studenti iscritti al corso
   
8. Le tesine verranno corrette con i criteri descritti nel modulo per la correzione riportato. Si consigliano gli studenti di valutare attentamente la qualità  del loro lavoro in rapporto ad esso.
9. I servizi vanno specificati nel cap. 4 del SDD e poi usati per la specifica dei contratti e delle interfacce nel cap.3 del ODD (la specifica dei contratti è richiesta nell'ODD, eventualmente nella forma testuale se eccessivi per i diagrammi delle classi). L'ODD include i diagrammi delle classi da cui si ottiene il codice JAVA.
10. Con riferimento alla scaletta del documento ODD, si ricorda che: a) devono essere riportati i diagrammi delle classi dei vari package; tali diagrammi sono quelli da cui si genera il codice sorgente che poi verrà  adoperato per codificare l'applicazione (e documentato con Javadoc). b) Deve essere riportato il diagramma/i diagrammi dei componenti e la relativa documentazione (elenco classi realizzate da ogni componente). c) deve essere riportato il diagramma di deployment
11. Si chiarisce che la documentazione cartacea delle classi in formato javadoc va prodotta mediante stampa del codice java opportunamente etichettato.
    

Frequently Asked Questions

Domanda: Sul sito dedicato al corso di Ing. del Software, lei ha messo a disposizione alcuni template da usare come linea guida per la stesura di alcuni documenti (Object Design Document, Requirements Analysis Document, ...). Le sarebbe possibile mettere sul sito anche un template di "più alto livello" che definisca l'insieme minimale di documenti che dovranno costituire la tesina ?

Risposta: Vedere gli esempi di tesine svolte o esempi degli autori del libro:  progetto JAMES, progetto TRAMP.
 

Domanda: Dobbiamo cominciare a sviluppare il progetto relativo alla tesina, ma ovviamente abbiamo bisogno di conoscere prima l'esatta scaletta della tesina. Non abbiamo capito dove dobbiamo inserire la parte relativa all'ERD e al database. Potrebbe indicarci la corretta collocazione all'interno del progetto?

Risposta: Per quanto riguarda la scaletta complessiva, vi consiglierei di riferirvi a quanto illustrato nel punto 5 dei consigli sulla stesura della tesina.

Per la progettazione del database potrete procedere in tal modo:
1) la progettazione concettuale poichè è strettamente legata alla analisi del dominio può essere posta nel capitolo 3.5.3 (modello degli oggetti) del documento RAD. Si può quindi usare questo approccio: definizione delle entità  nel paragrafo Dizionario dei dati e descrizione delle loro relazioni in un altro paragrafo che chiamerei diagrammi entità  relazioni se si usano gli ERD.
2) il progetto logico può essere inserito nel capitolo 5 (Data Management) del documento di System Design. Esso è infatti dedicato ad esplorare le problematiche relative ai dati e dar loro soluzione. Da questa analisi potrebbe ad esempio emergere l'esigenza di una distribuzione dei dati in più database (in base alla loro disponibilità/reperibilità) o server (per problemi di prestazioni).
3) Nell'Object Design andranno ovviamente dettagliate tutte le classi che permettono l'accesso ai dati e che sono state (probabilmente) introdotte nelle fasi precedenti.

Domanda: Ci sono errori nelle tesine proposte come esempio oppure è sbagliato il libro/sto sbagliando io (studente) l'impostazione?

Risposta: Le tesine proposte contengono probabilmente degli errori. Non sono da prendersi come strumento di studio ma pura esemplificazione di massima del lavoro da svolgere in termini di dimensioni delle parti e stile di documentazione. Mi è stato ad esempio riportato che in alcuni sequence diagram non sono presenti le dovute classi di controllo e/o entità. Spesso mancano i diagrammi di stato delle classi di controllo e/o entità. E' possibile, ciò non vuol dire che non dovevano esserci. La fonte di studio principale rimane il libro, secondariamente ci sono le slide da me presentate e gli appunti presi a lezione.

Domanda: Bisogna fare degli scenari delle eccezioni?

Risposta: Le eccezioni spesso necessitano di un approfondimento che giustifica uno scenario apposito ma nella tesina potete evitare quelle più banali

Domanda: Possiamo fare un caso d'uso senza aver fatto uno scenario inerente?

Risposta: Come da regola generale, un caso d'uso deve discendere dalla generalizzazione di uno o più scenari (testuali nella raccolta dei requisiti, sotto forma di sequence diagram nella analisi dei requisiti).

Domanda: Stiamo creando dei casi d'uso generali che comprendono, al loro interno, altri casi d'uso particolari. Che tipo di documentazione dobbiamo mettere per questo tipo di casi d'uso?

Risposta: La documentazione del caso d'uso va fatta come da scaletta proposta nel libro ed a lezione anche quando esso viene decomposto in altri più dettagliati. In più ovviamente esso avrà  un nuovo diagramma dei casi d'uso contenente il maggior livello di dettaglio. E' importante riportare nel caso d'uso di dettagli gli attori che interagivano con il caso d'uso più generale al fine di evidenziare con quali casi d'uso particolari essi interagiscano.

Domanda: E' possibile svolgere la tesina usando tecnologie di tipo web-based (pagine web statiche o dinamiche, JSP, ASP, php e simili)?

Risposta: NO. Tali applicazioni si progettano in modo specifico e diverso da quello studiato e quindi il progetto svolto con la metodologia studiata non sarebbe appropriato. E' richiesta la realizzazione di un sistema (probabilmente distribuito) di applicazioni Java che dialogano tra loro (se necessario) e con la base dati (se presente/necessaria).

Domanda: avrei un dubbio sui diagrammi di stato; a lezione si è detto che i diagrammi di stato servono per rappresentare classi control complesse, mentre negli esempi di tesina presi dal suo sito ho notato che i diagrammi di stato rappresentano delle funzionalità  generali come per esempio "funzionalità  del magazziniere", quindi non sapevo se fare i diagrammi di stato relativi ad alcune delle mie classi control, oppure sulle funzionalità  per esempio relative al docente o allo studente, etc..

Risposta: I diagrammi che rappresentano il comportamento di parti complesse dell'intero sistema (ad esempio a livello di componente e quindi potrebbe trattarsi del componente che gestisce le funzionalità  del magazziniere) possono essere utili per descrivere il comportamento ad alto livello. Essi però non devono sostituire i diagrammi di stato di tutte le classi con una vita significativamente complessa (in generale la maggior parte delle control ma questo non esclude anche le entity e piùraramente le boundary la cui complessità  in genere è legata alla implementazione della veste grafica dalla quale noi prescindiamo). Molto comuni sono anche i diagrammi di stato che rappresentano i percorsi di navigazione tra le schermate del sistema (non sono necessariamente richiesti in tesina)
 

Domanda: nella visione delle tesine precedenti da Lei pubblicate, siamo incappati nel seguente diagramma dei casi d'uso

 I casi d'uso "Elimina Corso" e "Modifica Corso" sono legati a Ricerca Corso da relazioni di inclusione. Il libro, a pag. 115 riporta che per funzionamenti opzionali bisogna ricorrere all'uso di estensioni. E' più corretto pensare ad Elimina Corso come estensione di Ricerca Corso (analogo per Modifica Corso) al posto dell'inclusione ??

Risposta:  Il  metodo migliore per capire se una relazione tra due casi d'uso è (o può essere) di include/extend consiste nell'analizzare le funzionalità  del caso d'uso base (quello da cui parte la linea di include o arriva quella di extend): se il caso d'uso base è completo (nel senso che riesce ad esprimere il comportamento che da esso ci si attende) allora non si vede la ragione di inserire (includere) in esso un altro pezzo di comportamento. Probabilmente allora si dovrà  usare una relazione di extend (ovviamente è anche possibile che non ci sia alcuna relazione ma questo è errore di altro tipo). Se il caso d'uso base necessita di un certo pezzo di comportamento (quello del caso d'uso incluso) per portare a termine il suo compito allora la relazione è di include.
Da quanto detto discende che le relazioni di include citate nella domanda sono errate, dovevano essere relazioni di extend.

Domanda: in un diagramma di stato, quando inserisco una guard condition, è giusto pensare che questa "coincide" con la condizione <<on exit>> dello stato che precere la G.C.. Basta che si verifichi la G.C. affinchè si passi da uno stato all'altro?

Risposta:  in un diagramma di stato, si esce dallo stato SOLO quando arriva un evento che abilita la transizione verso un nuovo stato. Talvolta questa transizione ?condizionata dal verificarsi di una ulteriore condizione. In pratica, oltre ad arrivare l'evento deve anche essere vera quella condizione per avere la transizione

NEW FAQ

Risposta:  dovete fare una descrizione (testuale) delle situazioni in cui verrebbe usato il software. Per lo stile da adottare, già a lezione vi ho consigliato di leggere le tesine degli anni passati. Troverete i relativi siti web elencati nella homepage del mio sito: http://www.pa.icar.cnr.it/cossentino/

Domanda: Per quanto riguarda l'appello previsto per l'esame, siccome già ad oggi c'è esattamente un mese per la data di consegna del primo appello, è penalizzante prevedere di farlo in quella data ma poi trovarsi a doverlo rinviare al secondo, anche perché c'è una parte di programma che non abbiamo ancora studiato?

Risposta:  assolutamente no, la data di esame la concordate tra di voi, io ne vengo a conoscenza soltanto quanto presentate la tesina nei tempi previsti prima dell’appello

Domanda: Il problem statement deve includere solo funzionalità che andremo a realizzare nel progetto, oppure è possibile includere delle possibilità di espansione che non verranno realizzate, ma di cui si terrà conto nella progettazione?

Risposta:  tutto ciò che viene descritto nel problem statement deve essere progettato. Non vi è richiesta la codifica di nulla (è soltanto un’opzione)

Domanda: Poiché è la prima volta che troviamo a scrivere un problem statement ci chiedevamo come debba essere strutturato per essere corretto. Possiamo farlo ricalcando la struttura delle consegne delle tesine degli anni passati?

Risposta:  si, come già detto a lezione

Domanda:  Dalle idee raccolte emerge la necessità di introdurre una parte che andrebbe implementata su tablet. Sottolineamo che non è una semplice applicazione client/server in cui la parte client è solo quella mobile, ma sarebbe una tra altre componenti.
Tra l'altro pensiamo che il software che dovrebbe girare su tablet condividerebbe buona parte della progettazione con il client per desktop.
Pensa che possiamo continuare lo stesso oppure il mobile è da evitare? Forse sarebbe meglio parlarne di presenza?

Risposta: Possiamo parlarne di presenza oppure vi invito a valutare se la porzione di sistema da dislocare su tablet potrebbe essere concepita come dislocata su un computer portatile dotato di connessione wi-fi oppure cellulare.

Domanda: potrebbe darmi delle linee guida per scrivere un corretto problem statement

Risposta: come già detto, consiglio di partire da un problema noto (per conoscenza personale, per disponibilità di un esperto del dominio o per senso comune) e come struttura generale utilizzare quella dei problem statement dei progetti degli anni passati. Sottolinerei l’importanza di pensare ad un applicativo da sviluppare in java, con possibilmente tre utenti coinvolti (uno per ogni componente il gruppo di sviluppo), con una logica di business significativa che richieda una specifica modellazione del comportamento del sistema tramite diagrammi dinamici (sequenza, stato,…).