- 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)
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)
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)
IMPORTANTE Domanda: avrei un piccolo problema. Lavorando alla tesina di I.S. e creando le classi di stampa mi sono accorto di alcune differenze di allineamento caratteri effettuando stampe su diverse stampanti...
Mi spiego meglio... : se stampo nella stampante X tutto è perfetto ma, se stampo nella stampante Y ho qualche pixel di differenza.
Premettendo che tutto questo è più che normale (si provi a stampare un file doc su una stampante X e poi su una Y ... da qui la scelta del formato pdf o di altro...), come mi comporto nel caso specifico della tesina... dove un pixel può compromettere il corretto allineamento dei dati sullo statino o sul verbale?
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.