Alcuni consigli sulla stesura della tesina

  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 già realizzato il programma falliscono totalmente nel raggiungere gli obiettivi del corso (con conseguenti risultati dell'esame)
  2. Ricordo a tutti che esistono vari ambienti di sviluppo che si integrano bene con gli strumenti CASE che è possibile utilizzare. A titolo di esempio, Poseidon si integra come modulo di NetBeans o Sun Forte/Studio One, Rational Rose si integra con Visual Studio (linguaggi VC++ e VB) e IBM VisualAge (Java), MS Visio nell'ultima versione è stato integrato in Visual Studio .NET. Segnalo particolarmente Eclipse di IBM che dispone del tool Eclipse UML di Omondo.
  3. Ricordo a tutti che l'interfacciamento del linguaggio JAVA con i database è possibile con estrema facilità grazie al JDBC (vedi sito SUN). 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 è particolarmente adatta alla progettazione di soluzioni web-based.
  4. 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).
     
  5. 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.
     
  6. Scaletta proposta per le tesine:

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

(vedasi esempi degli autori del libro:  progetto JAMES, progetto TRAMP)

  1. 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.
  2. 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. Non è possibile al docente dare alcun supporto per la composizione di gruppi di lavoro.
  3. 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.
  4. 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.
  5. 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

 

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: Riguardo allo strumento MS-Project, vorrei sapere a chi rivolgermi per averlo con licenza.

Risposta: Si rivolga agli ingg. Dindo o Macaluso, allo CSAI lab (al DINFO) (per la sede di Palermo)

 

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. A titolo di esempio si considerino i diagrammi delle classi presenti nell'esempio http://james.globalse.org/james1/J_courseDocs/RAD/RAD_VIP/RAD_VIP.html. Come si può notare essi sono dei dagrammi entità-relazioni espressi sotto forma di diagrammi delle classi (pratica abbastanza comune). Si può quindi usare lo stesso approccio dell'esempio anzidetto (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 al posto dei diagrammi delle classi).
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)
 

Risposta:  In genere queste differenze sono minime e non mi preoccuperei più di tanto. Prenda piuttosto come riferimento la stampa su pdf. Veda se riesce ad allineare tutto sufficientemente bene con essa.

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