Requirements Analysis
Document
Progetto Atena
Versioni:
0.1, rilasciata il 10/9/2004: Scheletro del documento
1.0, rilasciata il 13/02/2005: Revisione e aggiornamento successivo a completamento
sistema
Redatto da:
Bianca Lo Cascio
Davide Rizzo
_________________________________
_________________________________
Approvato da:
Bianca Lo Cascio
Silvio Lo Nano
Mariarosaria Padalino
Davide Rizzo
_________________________________
_________________________________
_________________________________
_________________________________
Descrizione:
Questo documento parte dall’analisi del sistema corrente, per elencare i requisiti funzionali e
non funzionali del progetto e i modelli risultanti dall’analisi.
A chi è rivolto:
Cliente, utenti finali, analisti e sviluppatori.
Requirements Analysis Document
Progetto Atena
Sommario
1
Introduzione ................................................................................................................................4
1.1
Scopo del sistema ............................................................................................................................ 4
1.2
Criteri di accettazione del sistema................................................................................................. 4
1.3
Definizioni........................................................................................................................................ 4
1.4
Acronimi e abbreviazioni ............................................................................................................... 4
1.5
Materiale di riferimento ................................................................................................................. 5
2
Sistema corrente ..........................................................................................................................6
3
Sistema proposto..........................................................................................................................6
3.1
Requisiti funzionali ......................................................................................................................... 6
3.1.1
3.1.2
3.1.3
3.2
Gestione studente .........................................................................................................................................6
Gestione docente ..........................................................................................................................................7
Gestione amministratore ..............................................................................................................................8
Requisiti non funzionali.................................................................................................................. 8
3.2.1
3.2.2
3.2.3
3.2.4
3.2.5
3.2.6
3.2.7
3.2.8
3.2.9
3.2.10
3.2.11
Interfaccia utente e fattori umani .................................................................................................................8
Accesso ai disabili........................................................................................................................................8
Documentazione...........................................................................................................................................8
Considerazioni hardware..............................................................................................................................9
Caratteristiche prestazionali .......................................................................................................................10
Gestione degli errori e casi eccezionali......................................................................................................10
Interfaccia del sistema................................................................................................................................10
Modifiche del sistema ................................................................................................................................10
Sicurezza ....................................................................................................................................................10
Privacy...................................................................................................................................................11
Requisiti di qualità.................................................................................................................................11
3.3
Pseudo requisiti ............................................................................................................................. 11
3.4
Modelli del sistema........................................................................................................................ 12
3.4.1
Attori ..........................................................................................................................................................12
3.4.1.1
Studente ............................................................................................................................................12
3.4.1.2
Docente .............................................................................................................................................12
3.4.1.3
DBMS_applicazione.........................................................................................................................12
3.4.1.4
DBMS_segreteria .............................................................................................................................12
3.4.1.5
Amministratore .................................................................................................................................12
3.4.2
Scenari........................................................................................................................................................12
3.4.2.1
Scenari di autenticazione ..................................................................................................................13
3.4.2.1.1 Autenticazione studente ...............................................................................................................13
3.4.2.1.2 Autenticazione professore............................................................................................................13
3.4.2.1.3 Autenticazione amministratore ....................................................................................................13
3.4.2.2
Scenari operazioni studente ..............................................................................................................13
3.4.2.2.1 Iscrizione ad esame ......................................................................................................................14
3.4.2.2.2 Visualizzazione elenco esami a cui studente è iscritto ................................................................14
3.4.2.2.3 Cancellazione precedente iscrizione ad esame ............................................................................14
3.4.2.3
Scenari operazioni amministratore ...................................................................................................14
3.4.2.3.1 Invio comunicazioni di servizio ai docenti ..................................................................................14
3.4.2.3.2 Modifica data di un esame ...........................................................................................................15
3.4.2.4
Scenari operazioni docente ...............................................................................................................15
3.4.2.4.1 Esportazione elenco iscritti in CSV .............................................................................................15
2/36
Requirements Analysis Document
Progetto Atena
3.4.2.4.2 Inserimento quesiti d’esame ........................................................................................................15
3.4.2.4.3 Invio comunicazioni agli studenti iscritti ad un esame................................................................16
3.4.2.4.4 Modifica data esame ....................................................................................................................16
3.4.2.4.5 Stampa iscritti ad un appello d’esame .........................................................................................16
3.4.2.5
Scenari svolgimento esami ...............................................................................................................17
3.4.2.5.1 Inizio appello esame con elenco iscritti da database ...................................................................17
3.4.2.5.2 Inizio appello esame con elenco iscritti da CSV .........................................................................17
3.4.2.5.3 Interruzione appello esame ..........................................................................................................17
3.4.2.5.4 Gestione contemporanea più appelli d’esame .............................................................................18
3.4.2.5.5 Esame superato con domande da elenco......................................................................................18
3.4.2.5.6 Esame superato con domande da elenco e domande libere .........................................................18
3.4.2.5.7 Esame non superato con domande libere.....................................................................................19
3.4.2.5.8 Inizializzazione verbale ...............................................................................................................19
3.4.2.5.9 Compilazione statino e verbale....................................................................................................19
3.4.2.5.10 Chiusura verbale a fine appello ..................................................................................................20
3.4.2.5.11 Chiusura verbale a interruzione appello.....................................................................................20
3.4.2.5.12 Studente ritirato o assente ..........................................................................................................20
3.4.2.5.13 Stampa iscritti all’esame e verifica delle presenze.....................................................................20
3.4.2.5.14 Stampa verbale su nuova facciata ..............................................................................................21
3.4.2.5.15 Stampa verbale su nuova facciata e nuova pagina .....................................................................21
3.4.2.6
Scenari eccezionali ...........................................................................................................................21
3.4.2.6.1 Accettazione iscrizione straordinaria ad esame ...........................................................................21
3.4.2.6.2 Chiusura automatica della sessione .............................................................................................22
3.4.2.6.3 Fallimento aggiornamento database dopo interruzione appello esame .......................................22
3.4.2.6.4 Fallimento autenticazione ............................................................................................................22
3.4.2.6.5 Fallimento importazione elenco iscritti .......................................................................................23
3.4.2.6.6 Richiesta iscrizione straordinaria ad esame .................................................................................23
3.4.3
Use case model e Dynamic models............................................................................................................23
3.4.3.1
Interfaccia utente e mock-ups...........................................................................................................23
3.4.3.1.1 Amministratore ............................................................................................................................24
3.4.3.1.2 Studente .......................................................................................................................................26
3.4.3.1.3 Docente ........................................................................................................................................29
3/36
Requirements Analysis Document
Progetto Atena
1 Introduzione
1.1 Scopo del sistema
Lo sviluppo del presente sistema è indirizzato alla fornitura di servizi fruibili dalle tipologie di
utenti coinvolte a vario titolo con il Corso di Laurea in Ingegneria Informatica. L’obiettivo sarà
quello dell’automatizzazione delle operazioni tipiche svolte dagli utenti al fine di rendere le stesse
più veloci.
1.2 Criteri di accettazione del sistema
In fase di analisi del progetto è stato prodotto un RAD iniziale contenente una descrizione
funzionale e dinamica del sistema che ci si apprestava a realizzare. Il cliente, presa visione di tale
documento, ha provveduto all’accettazione del sistema che in seguito si è realizzato. In tal modo
tale RAD iniziale consegnato al cliente ha svolto il ruolo di un contratto.
1.3 Definizioni
In tale sottoparagrafo si specificano i termini del dominio del discorso del progetto realizzato. Essi,
infatti, pur essendo di uso comune, potrebbero indurre a interpretazioni personali, quindi
potenzialmente diverse da quelle sottointese in questa trattazione.
• Appello – esame di una stessa materia che può svolgersi in più giorni, solitamente
consecutivi.
• Sessione di lavoro – accesso al sistema mediante autenticazione e svolgimento delle
operazioni desiderate che termina con la disconnessione dal sistema.
• Sessione d’esame – in sede di svolgimento degli esami, arco temporale compreso tra
l’apertura e la chiusura di un verbale.
• Sessione estiva/invernale/straordinaria – insieme di uno o tre appelli (nomenclatura da
riportare in fase di registrazione).
1.4 Acronimi e abbreviazioni
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
API – Applications Programming Interface
CASE – Computer Aided Software Engineering
GUI – Graphical User Interface
JDK – Java Development Kit
ODD – Object Design Document
OMT – Object-Oriented Modeling Technique
RAD – Requirements Analysis Document
ROSE – Visual modeling tool for Java
SDD – System Design Document
SPMP – Software Project Management Plan
UML – Unified Modeling NotationAIP – Agent Identification Phase
COD – Communication Ontology Description
DBMS – Data Base Management System
DCP – Deployment Configuration Phase
DDP – Domain Description Phase
DOD – Domain Ontology Description
GUI – Graphical User Interface
4/36
Requirements Analysis Document
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Progetto Atena
JDK – Java Development Kit
JDBC – Java DataBase Connectivity
JVM – Java Virtual Machine
MASD – Multi Agent Structure Definition
MABD – Multi Agent Behaviour Description
PASSI – Project for Agent Societies Specification and Implementation
PTK – Passi Tool Kit
ODP – Ontology Description Phase
RDF – Resource Description Language
RDP – Role Description Phase
RAD – Requirements Analysis Document
RIP – Role Identification Phase
ROSE – Tool di progettazione e sviluppo software
SPMP - Software Project Management Plan
SQL – Structured Query Language
SASD – Single Agent Structure Definition
TSP – Task Specification Phase
UML – Unified Modeling Notation
XML – eXtensible Markup Language
1.5 Materiale di riferimento
Per la realizzazione del sistema sono stati utilizzati i seguenti materiali di riferimento:
•
•
•
•
•
Bruegge-Dutoit: Object-Oriented Software Engineering: Conquering Complex and
Changing System, Prentice Hall, 2000.
H. Schildt: La guida completa – Java 2, McGraw-Hill, 2003.
Specifiche FIPA
o FIPA Abstract Architecture
o FIPA Agent Management Specification
o FIPA Request Interaction Protocol Specs
o FIPA Query Interaction Protocol Specs
o FIPA Request When Interaction Protocol Specs
o FIPA Communicative Act Library Specification
Guide Jade:
o F. Bellifemine, G. Caire, T. Trucco (TILAB S.p.A., formerly CSELT), G. Rimassa
FRAMeTech s.r.l.): JADE ADMINISTRATOR’S GUIDE, 2003
o G. Caire (TILAB, formerly CSELT): JADE TUTORIAL - APPLICATIONDEFINED CONTENT - LANGUAGES AND ONTOLOGIES, 2002
o F. Bellifemine, G. Caire, T. Trucco (TILAB S.p.A., formerly CSELT), G. Rimassa
FRAMeTech s.r.l.): JADE PROGRAMMER’S GUIDE, 2004
o M. Cossentino: Tutorial su PASSI
o P. Pialorsi: Programmare con XML, Mondadori Informatica, 2004
Paolo Atzeni, Stefano Ceri, Stefano Paraboschi, Riccardo Torlone: Basi di dati 2.ed,
McGraw-Hill 1999
5/36
Requirements Analysis Document
Progetto Atena
2 Sistema corrente
Il sistema che intendiamo realizzare verrà ideato da principio, quindi non sarà un’opera di
reingegnerizzazione. Piuttosto il sistema dovrà automatizzare tutte le operazioni inerenti agli esami
universitari, che al momento si svolgono nei modi tradizionali. Allo stato attuale, ad esempio, gli
studenti provvedono ad iscriversi agli esami scrivendo il proprio nome in appositi fogli presso il
dipartimento di competenza oppure presentando lo statino. La procedura attuale di iscrizione risulta
poco sicura, in quanto i fogli delle iscrizioni sono accessibili da chiunque e come tali possono
essere modificati o smarriti, e poco rispettosa della privacy, dal momento che sono visionabili da
tutti. Attualmente anche la figura del docente può avere delle difficoltà nello svolgimento degli
esami, ad esempio nel non avere immediatamente a disposizione l’elenco degli iscritti o nel
ricordare le domande che ha sottoposto all’esaminando. Inoltre allo stato attuale il docente e
l’esaminando durante lo svolgimento degli esami devono provvedere manualmente alla
compilazione del verbale e dello statino, provocando l’aumento della durata di ciascun esame.
3 Sistema proposto
Il sistema proposto ha l’obiettivo di migliorare la situazione attuale della gestione degli esami da
più punti di vista (studente, docente e amministratore del sistema). In particolar modo con l’impiego
di questo sistema, gli studenti effettueranno le iscrizioni agli esami in modo più sicuro, grazie ad un
accesso al sistema tramite username e password, e veloce, visto che gli studenti avranno
immediatamente un elenco delle materie a cui potersi iscrivere. Inoltre lo studente potrà effettuare
altre operazioni quali cancellazione di un’iscrizione o visualizzazione del quadro delle proprie
iscrizioni agli esami.
Il sistema supporterà anche la figura del docente nella preparazione degli esami (stampa dell’elenco
degli iscritti, esportazione dello stesso in file CSV o compilazione dell’elenco delle domande
d’esame di archivio) e nello svolgimento degli esami (appello per segnare le assenze, inserimento
delle domande d’esame nel verbale e relativa stampa, stampa dello statino).
3.1 Requisiti funzionali
Il sistema si propone di coadiuvare gli studenti durante le iscrizioni agli esami e i docenti durante la
preparazione e lo svolgimento degli esami.
Le funzionalità del sistema vengono suddivise in tre categorie, in base alla tipologia di utente che ne
usufruisce. Questa ripartizione si dimostra utile sia per ottenere un sistema dotato di interfaccia
facilmente comprensibile sia per evitare accessi non autorizzati ad aree funzionali non di dominio
pubblico.
In questa ottica si sono individuate queste tre macro-aree funzionali percepibili dagli utenti
dall’esterno:
•
•
•
Gestione studente
Gestione docente
Gestione amministratore
Procediamo con la descrizione dettagliata delle funzionalità appartenenti a queste tre categorie.
3.1.1 Gestione studente
Gli studenti accedono al sistema mediante delle apposite postazioni, ovvero dei totem.
6/36
Requirements Analysis Document
Progetto Atena
Il sistema supporta lo studente nelle operazioni tipiche relative agli esami universitari, in particolar
modo presenta le seguenti funzionalità specifiche a questa area funzionale:
•
•
•
Iscrizione esami: il sistema assiste lo studente nell’iscrizione agli esami. Al momento in cui
lo studente ha l’intenzione di iscriversi ad un esame il sistema fornisce un elenco delle
materie ai cui esami lo studente può iscriversi. Poiché ogni studente accede al sistema
mediante il proprio numero di matricola, il sistema conosce il suo attuale piano di studi e in
tal modo visualizza l’elenco delle materie di cui lo studente può ancora sostenere l’esame,
escludendo da tale elenco le materie già sostenute e quelle di anni successivi all’anno di
iscrizione.
Il sistema prevede anche una modalità di iscrizione straordinaria, nel caso in cui uno
studente voglia iscriversi all’esame di una materia che non compare nell’elenco delle
materie sostenibili. Tale situazione si può presentare in più circostanze come nel caso di una
materia di un piano di studi non ancora approvato, o nel caso di un mancato aggiornamento
del database della segreteria. In una tale situazione uno studente invia una mail al docente
della materia in questione contenente i suoi dati (nome , cognome e matricola) in cui fa
richiesta di accedere ad un appello d’esame, scrivendone le motivazioni. Il docente avvisa lo
studente se può accedere all’esame o meno e in caso affermativo inserisce i suoi dati
nell’elenco degli iscritti all’appello richiesto dallo studente. Lo studente verrà avvisato da
una mail sull’esito della richiesta dell’iscrizione.
Visualizzazione esami: il sistema fornisce l’opportunità di visualizzare il quadro
complessivo della situazione corrente di iscrizione agli esami, visualizzando anche dettagli
logistici relativi a ciascun esame, quali la data ed eventuali note del docente inerenti a
particolari indicazioni sull’esame (aula, orario, materiale di riferimento, strumentazione
necessaria,…).
Cancellazione esami: il sistema permette ad ogni studente di cancellare una sua iscrizione
precedentemente eseguita.
3.1.2 Gestione docente
L’applicazione supporta la figura del docente universitario in due macro-aree funzionali:
•
•
Preparazione esami: questa area funzionale comprende tutte quelle azioni che servono per
organizzare un esame dal punto di vista logistico e didattico. Il sistema permette al docente
di visualizzare, stampare o esportare in formato CSV l’elenco degli studenti iscritti ad un
dato appello. Inoltre una funzionalità prevista è quella di gestione di un archivio delle
domande d’esame di una materia, permettendo l’inserimento, la cancellazione e la modifica
delle stesse. Al docente viene data anche la possibilità di cambiare la data di un esame, nel
caso in cui una data d’esame il docente è impegnato o non in salute. Per permettere una
rapida comunicazione tra docente e studenti, utile ad esempio nel succitato caso di modifica
di data d’esame, il docente può inviare loro degli avvisi tramite posta elettronica.
Nonostante il docente possa inviare delle e-mail agli studenti per rispettare la riservatezza
dei dati, non è a conoscenza degli indirizzi di posta elettronica dei destinatari, ma incarica
l’amministratore del sistema ad inoltrare le mail.
Gestione svolgimento esami: il sistema supporta il docente nello svolgimento degli esami da
più punti di vista. Innanzitutto fornisce al docente all’inizio della giornata d’esame un elenco
degli iscritti nel quale il docente può segnare le assenze. Il docente può visualizzare l’elenco
degli iscritti anche su di un sistema esterno, come un palmare, importando l’elenco nel
formato CSV. Durante lo svolgimento degli esami, il sistema fornisce il nominativo dello
studente da esaminare, seguendo l’ordine di iscrizione, tuttavia il docente può variare
l’ordine di interrogazione in modo personale. Nel corso dell’interrogazione il docente può
7/36
Requirements Analysis Document
Progetto Atena
prelevare dall’elenco di archivio le domande d’esame da sottoporre all’esaminando, che alla
fine
dell’esame
verranno
automaticamente
inserite
nel
verbale.
Nel caso in cui il collegamento con il database sia temporaneamente inattivo, è possibile
aggiornare l’elenco degli iscritti, segnare le assenze e l’avanzamento delle interrogazioni
sugli elenchi CSV. Infine, il sistema assiste il docente nella stampa del verbale e degli statini
d’esame, incasellando opportunamente i dati e aiutando il docente nella gestione dei fogli
nella stampante, segnalando il momento in cui è necessario voltare facciata o introdurre un
nuovo foglio.
3.1.3 Gestione amministratore
E’ prevista una figura autorizzata alla modifica dei dati inerenti gli esami e all’accesso dei dati
personali. Tale ruolo può essere assunto da più persone fisiche (responsabile del dipartimento,
preside) ed è nelle condizioni di poter cambiare data di un esame, per motivi di carattere logistico
(chiusura dell’ateneo per disinfestazione, giorni festivi, indisponibilità del docente). Nell’atto della
modifica ad esempio di una data d’esame il sistema fornisce un calendario con le date disponibili,
vietando di fissare un esame di domenica. Inoltre l’amministratore può fornire comunicazioni di
servizio ai docenti tramite posta elettronica.
3.2 Requisiti non funzionali
3.2.1 Interfaccia utente e fattori umani
Il sistema interagisce con l’utente tramite interfacce grafiche; ne consegue che non è richiesto che
l’utente abbia una particolare familiarità con i sistemi informatici, ma soltanto una certa
dimestichezza con i sistemi a finestre. Sono previsti tre tipi di interfaccia, ognuna relativa ad una
tipologia di utente (studente, docente, amministratore), in modo tale da evidenziare a ciascun utente
esclusivamente le funzionalità ad esso pertinenti, al fine di fornire una interfaccia completa ma
essenziale. Data la semplicità delle interfacce utilizzate non sarà richiesto alcun tipo di
addestramento preliminare.
Le interfacce utilizzate adotteranno una struttura grafica in cui sono presenti bottoni, finestre di
dialogo, finestre scorrevoli ed aree di immissione dati.
3.2.2 Accesso ai disabili
Analogamente per permettere l’accesso ai non vedenti si potrà effettuare la navigazione all’interno
del sistema usando dei comandi tramite tastiera; inoltre è auspicabile che sulle postazioni sia
presente un lettore di interfacce, per permettere l’accesso ai non vedenti
3.2.3 Documentazione
A corredo del sistema verrà prodotta la seguente documentazione:
Un Problem Statement che descrive la situazione antecedente all’introduzione del sistema
proposto e espone quanto il sistema si propone di realizzare, volto ad una preliminare
contrattazione tra cliente e progettisti.
8/36
Requirements Analysis Document
Progetto Atena
Un Software Project Management Plan (SPMP) che definisce i processi tecnici e manageriali
necessari per lo sviluppo e la consegna del sistema Atena, indirizzato sia al cliente sia ai
progettisti.
Un Requirements Analysis Document (RAD) che descrive le funzionalità ed i requisiti globali
del sistema; tale documento viene prodotto mediante collaborazione con gli esperti del
dominio applicativo ed è indirizzato sia al cliente sia ai progettisti.
Un PASSI Project Document (PPD) che raccoglie le varie fasi della progettazione del sistema
secondo la metodologia PASSI, indirizzato ai progettisti.
Un documento di Progetto Database che include il progetto concettuale e logico del database
utilizzato, indirizzato ai progettisti.
Il Codice Sorgente mediante il quale è stato implementato il sistema.
3.2.4 Considerazioni hardware
Per il corretto funzionamento del sistema sono richieste tre tipologie di postazioni:
•
•
•
una che ospita il database dell’applicazione
un numero indeterminato di terminali, accessibili dai docenti e dagli amministratori del
sistema, collegati tramite una rete di tipo LAN
alcuni totem, ubicati presso il Dipartimento di Ingegneria Informatica, accessibili dagli
studenti, collegati alla medesima rete LAN di cui sopra
Si prevede che tutte le postazioni siano munite di scheda di rete e collegate ad una LAN privata
secondo uno degli standard 802.x (802.3, 802.5, 802.11). Si suggerisce comunque
l’interconnessione dei terminali mediante cablaggio strutturato adeguandosi alla normativa CEI
EN50173 (in riferimento allo standard europeo dettato dal Cenelec) o equivalentemente allo
standard americano TIA/EIA 568-B.
Presso ogni postazione sarà necessaria la presenza di un dispositivo di puntamento (mouse o
trackball), il quale permetterà di interagire velocemente con l’ambiente grafico delle interfacce, e di
una tastiera per l’immissione dei dati.
Tutte le postazioni, ad esclusione di quella ospitante il database, prevedono come configurazione
hardware minima i seguenti componenti principali:
•
•
•
•
CPU: Pentium III 700MHz o AMD equivalente.
RAM: 256 Mb.
Hard-disk con capacità di 10Gb.
Sistema Operativo Windows 2000 o superiore
In particolar modo le postazioni per lo svolgimento degli esami devono avere collegate
direttamente o in rete una o più stampanti ink-jet o laser in grado di stampare in formato A4 e A3.
Per la postazione ospitante il database è consigliata una configurazione RAID 0+1 (Mirroring), per
garantire l’integrità dei dati indipendentemente dai backup programmati, e i seguenti requisiti
minimi:
CPU: Pentium IV >1GHz o AMD equivalente.
RAM: 512 Mb.
2 Hard-disk con capacità di 100Gb.
Controller Raid
9/36
Requirements Analysis Document
Progetto Atena
Dal punto di vista software tutte le postazioni del sistema richiedono computer dotati di:
•
•
•
Jade 3.0b1 con codec RDF
JRE 1.5
Accesso ad un server di posta elettronica
Nella postazione del database, oltre al suddetto software, deve esser presente:
•
Microsoft Access
3.2.5 Caratteristiche prestazionali
Nonostante non siano richieste dal committente delle particolari caratteristiche inerenti alle
prestazioni, ci si pone l’obiettivo di garantire una rapida ed efficiente interazione col sistema, se
rispettati i requisiti minimi richiesti relativi all’hardware delle postazioni.
3.2.6 Gestione degli errori e casi eccezionali
Il sistema non necessita di un particolare controllo per l’immissione dei dati, in quanto la quasi
totalità dei dati viene inserita mediante menù a tendina. Quando necessario saranno presenti dei
controlli sulla consistenza dei dati. E’ da specificare che la consistenza e la correttezza dei dati è
assicurata dalla comunicazione mediante file xml “validi”.
Inoltre sono previsti dei messaggi che comunicano all’utente l’esito di una data operazione, sia esso
un successo o un insuccesso, o dei quadri che riassumono la situazione corrente dell’ambito
interessato.
Al fine di aiutare l’utente e di evitare errori di compilazione, il sistema aiuta nelle scelte,
visualizzando soltanto alternative corrette e plausibili; ad esempio ad uno studente che vuole
compiere un’iscrizione ad un esame, mostra soltanto le materie a cui può iscriversi, mentre ad un
docente mostra solo le materie da lui impartite.
3.2.7 Interfaccia del sistema
In generale il sistema prevede l’utilizzo di tradizionali dispositivi di I/O come monitor, tastiera e
mouse; in particolar modo le postazioni poste per lo svolgimento degli esami dovranno essere
dotate di stampanti che supportino anche il formato A3.
Il sistema inoltre dialoga con un sistema esterno, da cui trae i dati, ovvero il database della
segreteria, che ad ogni studente associa i dati prelevati dall’iscrizione.
3.2.8 Modifiche del sistema
Non sono previste particolari modifiche da dover apportare al sistema, tranne in caso di
cambiamento di regolamento degli esami.
3.2.9 Sicurezza
L’accesso al sistema da parte di ogni utente avviene mediante autenticazione con inserimento di
username e password. Si provvederà ad assegnare agli utenti con maggiori funzionalità, quali il
docente e l’amministratore, password composte da un maggior numero di caratteri alfanumerici
rispetto le password degli utenti studenti. Le password si suppone siano già in possesso degli utenti.
10/36
Requirements Analysis Document
Progetto Atena
All’atto dell’autenticazione il sistema è in grado di riconoscere la tipologia d’utente, in modo da
farlo accedere alla sezione con le funzionalità che gli competono.
3.2.10
Privacy
Il sistema sarà progettato tenendo conto del Codice in materia di protezione dei dati personali, in
base alla Legge delega 127/2001 e al Decreto legislativo 196/2003. Le funzionalità del sistema
richiedono operazioni quali la raccolta e la registrazione dei dati degli studenti (nominativo,
matricola, anno di corso, indirizzo di posta elettronica), quindi implica il trattamento dei dati
personali.
Nel progetto si adotteranno misure di sicurezza volte a impedire la distruzione o la perdita dei dati,
gli accessi non autorizzati, i trattamenti non consentiti o non conformi alla Legge.
Per rispondere al requisito di sicurezza dell’integrità dei dati è previsto un salvataggio periodico dei
dati. Nel caso in cui vengano effettuate copie di back-up su supporti rimovibili (quali hard-disk
esterni o DVD), questi dovranno essere riposti in luoghi sicuri e inaccessibili alle persone non
autorizzate.
L’unica figura che avrà accesso ai dati personali, ovvero l’incaricato al trattamento dei dati
personali, è il docente (e in caso di bisogno l’amministratore); tuttavia soltanto l’amministratore
sarà a conoscenza degli indirizzi di posta elettronica degli studenti, quindi nel caso in cui un
docente debba comunicare con gli studenti sarà coadiuvato dall’amministratore in qualità di
intermediario. Ogni incaricato del trattamento dei dati avrà attribuite delle credenziali di
autenticazione mediante assegnazione di password al sistema.
La figura dello studente potrà accedere esclusivamente ai propri dati personali.
Ad ogni utente del sistema verrà assegnata una password che risponde alle caratteristiche di
sicurezza: non meno di otto caratteri, combinazione di lettere, caratteri simbolici e numeri, nessun
riferimento a identificativi facilmente intuibili come nomi, cognomi, date di nascita dell'utente.
Verrà garantito che il sistema usato per il trattamento dei dati personali non rimanga incustodito
mediante la terminazione della sessione di lavoro dopo un intervallo massimo di tempo di inutilizzo
del sistema (tipicamente pari ad un minuto) .
Al fine di evitare intrusioni all’interno del sistema, sulle macchine da cui accedere al sistema
dovranno essere predisposte misure di sicurezza di tipo software (antivirus e firewall).
Infine, in caso di crash del sistema o danneggiamento del database, il ripristino dell'accesso ai dati
sarà garantito entro il termine massimo 24 ore.
3.2.11
Requisiti di qualità
Non sono richieste particolari requisiti di qualità.
3.3 Pseudo requisiti
Poiché si è scelto di sviluppare il software mediante il paradigma ad agenti, si dovrà utilizzare la
metodologia PASSI, usufruendo dell’apposito tool PTK (Passi ToolKit) disponibile come plugin
per il Software di progettazione Rational Rose che, di conseguenza, si dovrà utilizzare.
Il sistema verrà implementato in linguaggio Java sia in seguito ad esplicita richiesta del cliente sia
per poter impiegare la piattaforma ad agenti JADE.
Viene richiesta l’interazione da parte del sistema con il preesistente database della Segreteria nel
quale si trovano tutti i dati anagrafici e quelli relativi alla situazione universitaria (anno di
iscrizione, piano di studi, ecc.) degli studenti. Si ritiene garantita l’autenticità dei dati di tale
database.
11/36
Requirements Analysis Document
Progetto Atena
3.4 Modelli del sistema
3.4.1 Attori
Gli attori rappresentano le entità esterne che interagiscono con il sistema, siano esse persone umane
o sistemi software. Sono i responsabili delle interazioni del sistema negli scenari di utilizzo descritti
successivamente.
3.4.1.1 Studente
Generico studente iscritto ad un corso universitario. Accede al sistema per potersi iscrivere agli
esami.
3.4.1.2 Docente
Figura professionale che personifica il generico docente universitario, titolare di una o più cattedre.
Si occupa della preparazione e dello svolgimento degli esami universitari.
3.4.1.3 DBMS_applicazione
Data Base Management System del Database dell’applicazione; sistema esterno che interagisce con
il sistema. In esso vengono memorizzati i dati di diretta pertinenza con la gestione degli esami e per
il funzionamento del sistema nel suo complesso. Oltre all’immagazzinamento ha il compito di
mantenere la coerenza e la coesione dei dati memorizzati.
3.4.1.4 DBMS_segreteria
Data Base Management System del Database della segreteria; sistema esterno fisicamente
localizzato in un apposita macchina posta presso la Segreteria centrale della facoltà. In esso
vengono memorizzati i dati anagrafici e la situazione universitaria (piano di studio, esami sostenuti)
relativi agli studenti iscritti. Ha il compito di certificare la veridicità dei dati in esso contenuti e di
garantire l’accesso alle sole informazioni necessarie al funzionamento del programma nell’ottica del
rispetto della privacy.
3.4.1.5 Amministratore
Figura professionale responsabile dei cambiamenti logistici relativi allo svolgimento degli esami
universitari. È incaricata dal preside, dal direttore di un dipartimento o da una figura autorizzata del
cambiamento della data degli esami universitari.
3.4.2 Scenari
Gli scenari sono delle descrizioni narrative e testuali di ciò che gli attori (vedi sezione successiva)
fanno e avvertono durante l’utilizzo del sistema. La descrizione del singolo scenario è focalizzata al
punto di vista degli attori coinvolti e pertanto non rappresenta tutti i possibili aspetti del sistema ma
solo i più salienti.
12/36
Requirements Analysis Document
Progetto Atena
3.4.2.1 Scenari di autenticazione
3.4.2.1.1 Autenticazione studente
Istanze attori partecipanti:
Flusso degli eventi:
Luigi: Studente
Database: DBMS_applicazione.
1. Luigi si reca presso il Dipartimento di Ingegneria Informatica (DINFO).
2. Luigi si posiziona presso un’apposita postazione (totem o pc) predisposta
presso il DINFO.
3. Il sistema mostra la finestra di autenticazione
4. Luigi inserisce numero di matricola (7 cifre) e password (minimo 8 caratteri
alfanumerici) in suo possesso e richiede l’autenticazione da parte del sistema.
5. Il sistema invia la richiesta di autenticazione al Database che controlla la
correttezza dei dati inseriti.
6. Il Database notifica la correttezza dei dati inseriti; il sistema mostra la
schermata iniziale relativa alle operazioni possibili per gli studenti.
3.4.2.1.2 Autenticazione professore
Istanze attori partecipanti:
Flusso degli eventi:
prof. Rossi: Docente
Database: DBMS_applicazione.
1. Il prof. Rossi si reca presso il Dipartimento di Ingegneria Informatica
(DINFO).
2. Il prof. Rossi si posiziona presso un’apposita postazione (totem o pc)
predisposta presso il DINFO.
3. Il sistema mostra la finestra di autenticazione.
4. Il prof. Rossi inserisce username (minimo 8 caratteri alfanumerici) e
password (minimo 10 caratteri alfanumerici) in suo possesso e richiede
l’autenticazione da parte del sistema.
5. Il sistema invia la richiesta di autenticazione al Database che controlla la
correttezza dei dati inseriti.
6. Il Database notifica la correttezza dei dati inseriti; il sistema mostra la
schermata iniziale relativa alle operazioni possibili per i docenti.
3.4.2.1.3 Autenticazione amministratore
Istanze attori partecipanti:
Flusso degli eventi:
sig. Gianni: Amministratore.
Database: DBMS_applicazione.
1. Il sig. Gianni si reca presso il Dipartimento di Ingegneria Informatica
(DINFO).
2. Il sig. Gianni si posiziona presso un’apposita postazione (totem o pc)
predisposta presso il DINFO.
3. Il sistema mostra la finestra di autenticazione.
4. Il sig. Gianni inserisce la particolare username “administrator” e la password
(minimo 12 caratteri alfanumerici) in suo possesso e richiede
l’autenticazione da parte del sistema.
5. Il sistema invia la richiesta di autenticazione al Database che controlla la
correttezza dei dati inseriti.
6. Il Database notifica la correttezza dei dati inseriti; il sistema mostra la
schermata iniziale relativa alle operazioni possibili per l’amministratore.
3.4.2.2 Scenari operazioni studente
Rappresentano le operazioni tipiche svolte dallo studente, per come vengono percepiti ai suoi occhi
i servizi fornitigli dal sistema.
13/36
Requirements Analysis Document
Progetto Atena
3.4.2.2.1 Iscrizione ad esame
Istanze attori partecipanti:
Flusso degli eventi:
Luigi: Studente.
Database: DBMS_applicazione.
Segreteria: DBMS_segreteria.
1. Luigi, dovendo iscriversi all’esame di Ingegneria del Software, accede alla
sezione relativa all’iscrizione ad un esame
2. La Segreteria fornisce al sistema la lista contenente gli esami delle materie a
cui Luigi può iscriversi, che vengono mostrate in un apposito elenco.
3. Luigi sceglie la materia (Ingegneria del Software) e l’appello (I appello),
inserisce (come campi opzionali) un recapito telefonico ed un indirizzo email per eventuali comunicazioni, e invia la richiesta di iscrizione.
4. Il Database riceve la richiesta di iscrizione all’esame di Luigi e la
memorizza.
5. Il sistema notifica a Luigi l’avvenuta iscrizione all’esame.
6. Il sistema mostra uno schema sintetico aggiornato degli esami a cui Luigi è
iscritto.
3.4.2.2.2 Visualizzazione elenco esami a cui studente è iscritto
Istanze attori partecipanti:
Flusso degli eventi:
Luigi: Studente.
Database: DBMS_applicazione
1. Luigi non ricorda bene le date degli esami e vuole controllare per esserne
certo; accede quindi alla sezione relativa alla visualizzazione degli esami a
cui è correntemente iscritto.
2. Il Database fornisce al sistema i dati richiesti; il sistema mostra uno schema
dettagliato degli esami a cui Luigi risulta iscritto, contenente nome della
materia, data dell’esame, docente titolare della materia ed eventuali note
informative.
3.4.2.2.3 Cancellazione precedente iscrizione ad esame
Istanze attori partecipanti:
Flusso degli eventi:
Luigi: Studente.
Database: DBMS_applicazione.
1. Luigi, non avendo completato lo studio della materia, decide di cancellarsi
dall’esame di Ingegneria del Software a cui si era precedentemente iscritto.
2. Luigi accede alla sezione relativa alla cancellazione degli esami a cui è
correntemente iscritto.
3. Viene mostrata una schermata con un elenco sintetico (nome materia, nome
docente, data dell’esame e note informative) contenente gli esami a cui Luigi
risulta correntemente iscritto.
4. Luigi seleziona da tale elenco l’iscrizione all’esame da cancellare ed invia la
richiesta di cancellazione.
5. Il Database riceve la richiesta di cancellazione all’esame di Luigi e cancella
il suo nominativo dalla lista degli iscritti all’esame selezionato.
6. Il sistema notifica a Luigi l’avvenuta cancellazione all’esame.
7. Il sistema mostra lo schema sintetico aggiornato delle iscrizioni agli esami.
3.4.2.3 Scenari operazioni amministratore
Operazioni tipiche svolte dalla figura dell’amministratore.
3.4.2.3.1 Invio comunicazioni di servizio ai docenti
Istanze attori partecipanti:
sig. Gianni: Amministratore.
Database: DBMS_applicazione.
14/36
Requirements Analysis Document
Flusso degli eventi:
1.
2.
3.
4.
Progetto Atena
Il sig. Gianni viene incaricato dal Preside di notificare ad alcuni docenti una
comunicazione di servizio; accede quindi alla sezione relativa all’invio delle
comunicazioni.
Viene mostrato l’elenco dei docenti; il sig. Gianni seleziona i docenti
interessati alle comunicazioni e scrive il testo del messaggio nell’apposita
area di testo.
Il Database fornisce l’indirizzo e-mail dei docenti.
L’e-mail viene spedita.
3.4.2.3.2 Modifica data di un esame
Istanze attori partecipanti:
Flusso degli eventi:
sig. Gianni: Amministratore.
Database: DBMS_applicazione.
1. Il sig. Gianni viene incaricato dal Preside di spostare la data di tutti gli esami
del giorno previsto per la disinfestazione dei locali della Facoltà di
Ingegneria; accede quindi alla sezione relativa alla modifica della data degli
esami.
2. Il sig. Gianni sceglie l’esame di cui deve effettuare il cambio di data.
3. Il sig. Gianni seleziona la nuova data d’esame da un apposito calendario.
4. Il Database riceve la richiesta di modifica della data d’esame e modifica di
conseguenza i dati presenti.
5. Il sistema conferma l’avvenuta modifica ed elimina dall’elenco delle materie
originariamente previste nel giorno in questione l’esame appena modificato.
6. Il sistema provvede ad inviare automaticamente una e-mail ad ogni studente
iscritto all’esame nonché al docente della materia avvisando della modifica
effettuata.
7. Il sig. Gianni ripete le operazioni 3,4 finché non deve più modificare date
d’esame.
3.4.2.4 Scenari operazioni docente
Descrizione delle operazioni tipiche del docente universitario inerenti la preparazione agli esami, la
gestione delle date e tutto ciò che non riguarda esplicitamente l’assistenza durante lo svolgimento
delle prove d’esame.
3.4.2.4.1 Esportazione elenco iscritti in CSV
Istanze attori partecipanti:
Flusso degli eventi:
prof. Rossi: Docente.
Database: DBMS_applicazione
1. Il prof. Rossi decide di esportare l’elenco degli iscritti all’appello in un file
Comma Separated Values (CSV) in modo tale da poterlo successivamente
importare nel proprio palmare o nel sistema stesso qualora il collegamento
alla rete non sia disponibile.
2. Il prof. Rossi accede alla sezione relativa alla preparazione degli esami.
3. Il prof. Rossi sceglie la materia (Ingegneria del Software) e l’appello e dà il
comando per l’esportazione dell’elenco in un file CSV.
4. Viene mostrata una schermata dove il prof. Rossi inserisce il nome del file e
la locazione dove salvare l’elenco e procede con l’esportazione.
3.4.2.4.2 Inserimento quesiti d’esame
Istanze attori partecipanti:
Flusso degli eventi:
prof. Rossi: Docente.
Database: DBMS_applicazione
1. Il prof. Rossi, in previsione dell’esame di Ingegneria del Software, vuole
preparare alcuni quesiti da sottoporre ai candidati per velocizzare le
15/36
Requirements Analysis Document
2.
3.
4.
5.
6.
7.
8.
Progetto Atena
operazioni.
Il prof. Rossi accede alla sezione relativa alla preparazione degli esami.
Il prof. Rossi sceglie la materia (Ingegneria del Software) e dà il comando
per la gestione dei quesiti d’esame.
Viene visualizzato l’elenco dei quesiti d’esame della materia prescelta,
precedentemente memorizzate sul Database.
Il prof. Rossi aggiunge un nuovo quesito d’esame mediante una apposito
campo di testo e conferma l’inserimento.
Il nuovo quesito viene aggiunto nel Database.
Il sistema visualizza l’elenco aggiornato dei quesiti d’esame.
Il prof. Rossi ripete i punti 4,5 finché non ha più quesiti da inserire.
3.4.2.4.3 Invio comunicazioni agli studenti iscritti ad un esame
Istanze attori partecipanti:
Flusso degli eventi:
prof. Bianchi: Docente.
Database: DBMS_applicazione
1. Il prof. Bianchi deve comunicare agli studente iscritti al I appello dell’esame
di Controlli Automatici di portare con sé alcuni fogli di carta millimetrata e
la calcolatrice per agevolare lo svolgimento dell’esame.
2. Il prof. Bianchi accede alla sezione relativa alla preparazione degli esami.
3. Il prof. Bianchi sceglie la materia (Controlli Automatici) e l’appello e dà il
comando per l’invio delle comunicazioni agli studenti.
4. Viene mostrata una schermata nella quale il prof. Bianchi scrive il testo del
messaggio nell’apposita area di testo.
5. Il prof. Bianchi conferma l’invio dell’e-mail; il Database fornisce l’indirizzo
e-mail degli studenti iscritti all’esame.
6. L’e-mail viene spedita attraverso il client di posta elettronica disponibile nel
sistema.
3.4.2.4.4 Modifica data esame
Istanze attori partecipanti:
Flusso degli eventi:
prof. Rossi: Docente.
Database: DBMS_applicazione
1. Il prof. Rossi viene convocato per una conferenza internazionale il giorno
originariamente previsto per l’esame di Ingegneria del Software; decide
quindi di spostare la data dell’esame.
2. Il prof. Rossi accede alla sezione relativa alla preparazione degli esami.
3. Il prof. Rossi sceglie la materia (Ingegneria del Software) e l’appello e dà il
comando per la modifica della data d’esame.
4. Il prof. Rossi modifica la data prescelta, scegliendone una tra quelle mostrate
nel calendario.
5. Il Database riceve la richiesta di modifica della data d’esame e modifica di
conseguenza i dati presenti.
6. Il sistema conferma l’avvenuta modifica.
7. Il sistema provvede ad inviare automaticamente una e-mail ad ogni studente
iscritto avvisando della modifica effettuata.
3.4.2.4.5 Stampa iscritti ad un appello d’esame
Istanze attori partecipanti:
Flusso degli eventi:
prof. Rossi: Docente.
Database: DBMS_applicazione
1. Il prof. Rossi, per avere un quadro generale degli iscritti all’esame di
Ingegneria del Software che si svolgerà fra qualche giorno, decide di
stampare l’elenco degli iscritti .
2. Il prof. Rossi accede alla sezione relativa alla preparazione degli esami.
3. Il prof. Rossi sceglie la materia (Ingegneria del Software) e l’appello e dà il
16/36
Requirements Analysis Document
4.
5.
Progetto Atena
comando per la stampa degli iscritti.
Il Database fornisce al sistema l’elenco degli studenti iscritti desiderato;
viene visualizzata un’anteprima di stampa a video.
Il prof. Rossi conferma l’operazione e procede con la stampa dell’elenco.
3.4.2.5 Scenari svolgimento esami
Operazioni tipiche durante lo svolgimento degli esami e l’assistenza al docente.
3.4.2.5.1 Inizio appello esame con elenco iscritti da database
Istanze attori partecipanti:
Flusso degli eventi:
prof. Rossi: Docente.
Database: DBMS_applicazione.
Il giorno dell’esame di Ingegneria del Software il prof. Rossi, dalla sezione
principale, accede alla sezione relativa allo svolgimento degli esami
Viene mostrata la schermata con la lista delle materie impartite; il prof. Rossi
sceglie la materia (Ingegneria del Software) e l’appello, e seleziona l’opzione
per l’inizio dell’appello d’esame.
Viene mostrata la schermata con la richiesta dell’indicazione dell’origine
dell’elenco degli iscritti; il prof. Rossi sceglie di importare l’elenco dal
Database.
Il Database fornisce l’elenco dei candidati (Nome, Cognome, Matricola).
Il Database fornisce l’elenco dei quesiti d’esame.
Il prof. Rossi può iniziare l’appello d’esame con il primo candidato.
3.4.2.5.2 Inizio appello esame con elenco iscritti da CSV
Istanze attori partecipanti:
Flusso degli eventi:
prof. Rossi: Docente.
1. Il giorno dell’esame di Ingegneria del Software il prof. Rossi, dalla sezione
principale, accede alla sezione relativa alla gestione dello svolgimento degli
esami
2. Viene mostrata la schermata con la lista delle materie impartite; il prof. Rossi
sceglie la materia (Ingegneria del Software) e l’appello, e seleziona l’opzione
per l’inizio dell’appello d’esame.
3. Viene mostrata la schermata con la richiesta dell’indicazione dell’origine
dell’elenco degli iscritti; il prof. Rossi sceglie di importare l’elenco da un file
CSV.
4. Il prof. Rossi fornisce manualmente l’elenco dei candidati (Nome, Cognome,
Matricola) importandolo da un file CSV.
5. Il Database, se disponibile, fornisce l’elenco dei quesiti d’esame.
6. Il prof. Rossi può iniziare l’appello d’esame con il primo candidato
3.4.2.5.3 Interruzione appello esame
Istanze attori partecipanti:
Flusso degli eventi:
prof. Rossi: Docente.
Database: DBMS_applicazione.
Il prof. Rossi, dopo una mattinata di esami, decide di fare una pausa pranzo e di
riprendere gli esami dopo qualche ora; terminato allora l’ultimo esame della
mattinata, dalla sezione relativa allo svolgimento degli esami sceglie di
arrestarne temporaneamente il proseguimento.
Viene mostrata la schermata relativa alla chiusura del verbale, il sistema
suggerisce data e orario, che il prof. Rossi può eventualmente modificare.
Automaticamente viene aggiornato il Database con la lista degli studenti ancora
da esaminare. In caso di mancata disponibilità del collegamento con il
Database il sistema chiede se salvare la lista su un file CSV.
Viene mostrata la schermata iniziale dalla quale il prof. Rossi può terminare la
17/36
Requirements Analysis Document
Progetto Atena
sessione.
3.4.2.5.4 Gestione contemporanea più appelli d’esame
Istanze attori partecipanti:
Flusso degli eventi:
prof. Rossi: Docente.
1. Il prof. Rossi decide di gestire in contemporanea lo svolgimento dell’esame
di Ingegneria del Software VO e Ingegneria del Software NO, affidando in
particolare lo svolgimento di quest’ultimo ad un assistente.
2. Il prof. Rossi inizia l’appello d’esame di Ingegneria del Software VO dalla
sezione relativa allo svolgimento degli esami; viene mostrata la schermata
con la lista degli esaminandi dalla quale il prof. Rossi può gestire
l’andamento degli esami.
3. Il prof. Rossi ritorna alla sezione relativa allo svolgimento degli esami.
4. Il prof. Rossi inizia l’appello d’esame di Ingegneria del Software NO dalla
sezione relativa allo svolgimento degli esami; viene mostrata la schermata
con la lista degli esaminandi dalla quale il prof. Rossi può gestire
l’andamento degli esami.
5. Gli esami possono proseguire parallelamente: il prof. Rossi si occuperà degli
esami del VO mentre l’assistente, che condivide l’utilizzo della postazione, si
occuperà degli esami del NO.
6. Al momento della registrazione della documentazione ufficiale, l’assistente
farà apporre le firme dal titolare della materia, il prof. Rossi.
3.4.2.5.5 Esame superato con domande da elenco
Istanze attori partecipanti:
Flusso degli eventi:
prof. Rossi: Docente.
Luigi: Studente.
Database: DBMS_applicazione.
1. Si stanno svolgendo gli esami di Ingegneria del Software; il prof. Rossi si
trova nella sezione relativa allo svolgimento degli esami e inizia l’esame del
prossimo candidato in elenco, Luigi; viene mostrata la schermata relativa allo
svolgimento dell’esame ed il nome di Luigi viene eliminato dalla lista degli
studenti ancora da esaminare.
2. Il prof. Rossi sceglie di volta in volta da un apposito elenco presente nel
sistema le domande da sottoporre a Luigi e le introduce nell’apposita
sezione, relativa all’esame di Luigi.
3. Alla fine dell’esame, il prof. Rossi considera la prova d’esame superata e
propone a Luigi il voto 25/30.
4. Luigi accetta il voto; il prof. Rossi può quindi passare alla compilazione della
documentazione ufficiale (statino e verbale).
3.4.2.5.6 Esame superato con domande da elenco e domande libere
Istanze attori partecipanti:
Flusso degli eventi:
prof. Rossi: Docente.
Luigi: Studente.
Database: DBMS_applicazione.
Si stanno svolgendo gli esami di Ingegneria del Software; il prof. Rossi si trova
nella sezione relativa allo svolgimento degli esami e deve esaminare un
nuovo candidato.
Il prof. Rossi inizia l’esame del prossimo candidato in elenco, Luigi; viene
mostrata la schermata relativa allo svolgimento dell’esame ed il nome di
Luigi viene eliminato dalla lista degli studenti ancora da esaminare.
Il prof. Rossi sceglie di volta in volta da un apposito elenco presente nel sistema
le domande da sottoporre a Luigi e le introduce nell’apposita sezione,
relativa all’esame di Luigi.
Come ultima domanda il prof Rossi propone a Luigi un quesito non presente in
18/36
Requirements Analysis Document
Progetto Atena
elenco e lo inserisce manualmente nella lista delle domande fatte.
Alla fine dell’esame, il prof. Rossi considera la prova d’esame superata e propone
a Luigi il voto 25/30.
Luigi accetta il voto; il prof. Rossi può quindi passare alla compilazione della
documentazione ufficiale (statino e verbale).
3.4.2.5.7 Esame non superato con domande libere
Istanze attori partecipanti:
Flusso degli eventi:
prof. Rossi: Docente.
Luigi: Studente.
Database: DBMS_applicazione.
1. Si stanno svolgendo gli esami di Ingegneria del Software; il prof. Rossi si
trova nella sezione relativa allo svolgimento degli esami e deve esaminare un
nuovo candidato.
2. Il prof. Rossi inizia l’esame del prossimo candidato in elenco, Luigi; viene
mostrata la schermata relativa allo svolgimento dell’esame ed il nome di
Luigi viene eliminato dalla lista degli studenti ancora da esaminare.
3. Il prof. Rossi sceglie di volta in volta da un apposito elenco presente nel
sistema le domande da sottoporre a Luigi e le introduce nell’apposita
sezione, relativa all’esame di Luigi.
4. Alla fine dell’esame, il prof. Rossi considera la prova d’esame superata e
propone a Luigi il voto 18/30.
3.4.2.5.8 Inizializzazione verbale
Istanze attori partecipanti:
Flusso degli eventi:
prof. Rossi: Docente.
1. Il prof. Rossi ha appena concluso l’esame del primo della lista di Ingegneria
del Software, che ha accettato il voto proposto; viene mostrata la schermata
con la richiesta dei dati necessari all’inizializzazione del verbale d’esame.
2. Il sistema inserisce automaticamente i campi relativi al nome della materia,
al codice e suggerisce la data odierna e l’orario per l’inizializzazione; il prof.
Rossi inserisce manualmente la data (se quella odierna non va bene per un
qualche motivo) e l’orario.
3. Viene chiesto il formato di stampa da utilizzare (A3 o A4) ed il prof. Rossi
sceglie il formato A3.
4. Viene mostrata un’anteprima del verbale che il prof. Rossi accetta.
5. Il prof. Rossi può quindi passare alla compilazione del verbale e dello statino
relativamente all’esame appena concluso.
3.4.2.5.9 Compilazione statino e verbale
Istanze attori partecipanti:
Flusso degli eventi:
prof. Rossi: Docente.
Luigi: Studente.
1. Il prof. Rossi ha appena concluso l’esame di Luigi con la votazione proposta
di 25/30; viene mostrata la schermata relativa alla compilazione dello statino.
2. I campi con nome, cognome, numero di matricola, nome della materia,
codice della materia e data (stabilita automaticamente poiché il verbale
risulta già inizializzato) vengono automaticamente inseriti (i campi possono
essere comunque modificati qualora fosse necessario).
3. Il prof. Rossi inserisce la votazione proposta (che viene automaticamente
trasformata in formato letterale) e procede con la stampa dello statino per
l’apposizione delle firme; il sistema indica al docente il corretto orientamento
(facciata) del foglio.
4. Il prof. Rossi e Luigi firmano lo statino.
5. Viene successivamente presentata la schermata relativa alla compilazione del
verbale; il sistema inserisce automaticamente la lista delle domande poste
19/36
Requirements Analysis Document
6.
7.
8.
3.4.2.5.10
prof. Rossi: Docente.
1. Il prof. Rossi, dopo una giornata intera di esami, decide di rinviare
all’indomani la continuazione con gli esaminandi rimanenti.
2. Il prof. Rossi, appena terminato un esame, dalla schermata relativa allo
svolgimento degli esami sceglie di arrestarne il proseguimento.
4. Viene mostrata automaticamente la schermata con la richiesta dei dati per la
chiusura del verbale.
3. Il prof. Rossi inserisce i dati necessari (data e orario) e procede con la stampa
del verbale.
Studente ritirato o assente
Istanze attori partecipanti:
Flusso degli eventi:
3.4.2.5.13
prof. Rossi: Docente.
1. Il prof. Rossi ha appena interrogato l’ultimo studente presente in lista;
l’appello d’esame si considera terminato e si può procedere con la chiusura
del verbale.
2. Viene mostrata automaticamente la schermata con la richiesta dei dati per la
chiusura del verbale (che comunque vengono suggeriti).
3. Il prof. Rossi inserisce i dati necessari (data e orario) e procede con la stampa
del verbale.
Chiusura verbale a interruzione appello
Istanze attori partecipanti:
Flusso degli eventi:
3.4.2.5.12
(modificabili), la votazione, il nome del candidato ed il codice della materia.
Il prof. Rossi procede con la stampa del verbale per l’apposizione delle
firme; il sistema indica al docente quale foglio inserire (primo, secondo,
terzo…) e con quale orientamento (facciata), in base al numero di esami già
verbalizzati.
Il prof. Rossi e Luigi firmano il verbale.
L’esame si considera concluso ed il prof. Rossi può continuare con i
candidati rimanenti.
Chiusura verbale a fine appello
Istanze attori partecipanti:
Flusso degli eventi:
3.4.2.5.11
Progetto Atena
prof. Rossi: Docente.
Luigi: Studente.
1. Si stanno svolgendo gli esami di Ingegneria del Software; il prof. Rossi si
trova nella sezione relativa allo svolgimento degli esami.
2. Viene chiamato il prossimo studente nella lista, Luigi, e il suo nome viene
eliminato dalla lista degli studenti ancora da esaminare.
3. Luigi comunica al professore che preferisce perfezionare ulteriormente la
preparazione e si ritira dall’esame.
4. Il prof. Rossi notifica il ritiro di Luigi come se questi fosse assente; il
nominativo di Luigi viene eliminato dalla lista degli iscritti e il prof. Rossi
può quindi passare al prossimo studente in lista.
Stampa iscritti all’esame e verifica delle presenze
Istanze attori partecipanti:
Flusso degli eventi:
prof. Rossi: Docente.
1. Il prof. Rossi ha appena iniziato l’appello d’esame di Ingegneria del Software
e si trova nella schermata relativa allo svolgimento degli esami; prima di
iniziare con il primo Studente, decide di verificare le presenze.
2. Sceglie l’opzione per la visualizzazione; viene mostrata la schermata con la
lista degli iscritti.
20/36
Requirements Analysis Document
3.
4.
5.
6.
3.4.2.5.14
Il prof. Rossi decide di stampare l’elenco per l’apposizione delle firme dei
candidati attestanti la loro presenza; sceglie quindi l’opzione per la stampa
dell’elenco.
Una volta stampato l’elenco e fattolo circolare, il prof. Rossi notifica
l’assenza degli studenti che non hanno firmato segnando il rispettivo
identificativo nella lista degli studenti iscritti.
Terminate le operazioni di verifica delle presenze il prof. Rossi conferma le
assenze e può procedere con l’inizio dell’esame.
Il sistema elimina dalla lista degli iscritti i nominativi segnati.
Stampa verbale su nuova facciata
Istanze attori partecipanti:
Flusso degli eventi:
3.4.2.5.15
Progetto Atena
prof. Rossi: Docente.
1. Il prof. Rossi ha appena terminato l’esame di uno studente che ha accettato il
voto proposto e passa alla compilazione della documentazione.
2. Al momento della compilazione del verbale, poiché la verbalizzazione va
registrata su una nuova facciata, viene richiesto di inserire il foglio con la
prima facciata (la facciata è identificata mediante il numero progressivo a
fianco di ogni esame registrato).
3. Viene stampata la dicitura “Prosegue in altra pagina” nella sezione riepilogo,
in calce al verbale.
4. Viene richiesto l’inserimento della nuova facciata per il verbale, che può
essere quindi stampato con i dati relativi alla nuova verbalizzazione.
Stampa verbale su nuova facciata e nuova pagina
Istanze attori partecipanti:
Flusso degli eventi:
prof. Rossi: Docente.
1. Il prof. Rossi ha appena terminato l’esame di uno studente che ha accettato il
voto proposto e passa alla compilazione della documentazione.
2. Al momento della compilazione del verbale, poiché la verbalizzazione va
registrata su un nuovo foglio per il verbale, viene richiesto di inserire il
foglio precedente con la seconda facciata (la facciata è identificata mediante
il numero progressivo a fianco di ogni esame registrato).
3. Viene stampata la dicitura “Prosegue in altra pagina” nella sezione riepilogo,
in calce al verbale.
4. Viene richiesto l’inserimento della nuova pagina per il verbale, che può
essere quindi stampato con i dati relativi alla nuova verbalizzazione.
3.4.2.6 Scenari eccezionali
Operazioni particolari in risposta a casi eccezionali. Vengono rappresentate solo quelle situazioni
che presentano apposite risposte da parte del sistema.
3.4.2.6.1 Accettazione iscrizione straordinaria ad esame
Istanze attori partecipanti:
Flusso degli eventi:
prof. Rossi: Docente.
Database: DBMS_applicazione.
1. Il prof. Rossi riceve una e-mail dello studente Luigi con la richiesta di
iscrizione straordinaria all’esame di Informatica Grafica e tutti i suoi dati
personali.
2. Il prof. Rossi accetta le motivazioni addotte da Luigi e procede con la
registrazione manuale dello studente all’esame.
3. Dopo l’ accesso al sistema, dalla sezione relativa alla gestione degli esami
sceglie la materia Informatica Grafica e procede con la registrazione
straordinaria mediante l’apposita opzione.
4. Viene visualizzata la schermata contenente l’indicazione dell’appello da
21/36
Requirements Analysis Document
5.
6.
7.
8.
Progetto Atena
scegliere, nome, cognome e numero di matricola dello studente richiedente
l’iscrizione.
Il prof. Rossi inserisce i dati, presenti nell’e-mail ricevuta, e procede con la
registrazione straordinaria.
Il Database riceve la richiesta di iscrizione all’esame e la memorizza.
Il sistema notifica al prof. Rossi l’avvenuta iscrizione all’esame.
Il sistema invia a Luigi una e-mail di notifica dell’avvenuta iscrizione
all’esame.
3.4.2.6.2 Chiusura automatica della sessione
Istanze attori partecipanti:
Flusso degli eventi:
Luigi: Studente.
1. Luigi accede al sistema mediante autenticazione.
2. Luigi effettua le operazioni pianificate.
3. Luigi, avendo terminato i suoi compiti, si allontana dalla postazione
dimenticando di chiudere esplicitamente la sessione; il sistema rimane
inattivo per un intervallo massimo di tempo (timeout pari a 1 minuto).
4. Il sistema, per evitare usi impropri da parte di estranei, termina
automaticamente la sessione.
3.4.2.6.3 Fallimento aggiornamento database dopo interruzione appello esame
Istanze attori partecipanti:
Flusso degli eventi:
prof. Rossi: Docente.
Database: DBMS_applicazione.
1. Il prof. Rossi sta interrompendo il proseguimento degli esami; dopo avere
inserito i dati per la chiusura del verbale, bisogna aggiornare la lista degli
studenti ancora da esaminare alla ripresa dell’esame.
2. Viene chiesto di scegliere se aggiornare il Database con la lista degli studenti
ancora da esaminare o se salvare la lista su un file CSV; il prof. Rossi sceglie
di aggiornare il Database.
3. Durante la connessione al Database si verifica un errore di trasmissione;
viene chiesto se ritentare la connessione o optare per il salvataggio della lista
su un file CSV.
4. Il prof. Rossi, dopo un ulteriore tentativo di aggiornare il Database, non
andato a buon fine, opta per il salvataggio su file CSV.
5. Viene mostrata una schermata dove il prof. Rossi inserisce il nome del file e
la locazione dove salvare l’elenco e procede con il salvataggio.
6. Viene mostrata la schermata iniziale dalla quale il prof. Rossi può terminare
la sessione.
3.4.2.6.4 Fallimento autenticazione
Istanze attori partecipanti:
Flusso degli eventi:
Luigi: Studente.
Database: DBMS_applicazione.
1. Luigi si reca presso il Dipartimento di Ingegneria Informatica (DINFO).
2. Luigi si posiziona presso un’apposita postazione (totem) predisposta presso il
DINFO.
3. Il sistema mostra la finestra di autenticazione.
4. Luigi inserisce numero di matricola (7 cifre) e password (minimo 8 caratteri
alfanumerici) in suo possesso e richiede l’autenticazione da parte del sistema
(nella digitazione viene commesso qualche errore di battitura).
5. Il sistema invia la richiesta di autenticazione al Database che controlla la
correttezza dei dati inseriti.
6. Il Database notifica l’errore nei dati inseriti; il sistema mostra un messaggio
comunicante l’errore e ritorna alla finestra di autenticazione.
22/36
Requirements Analysis Document
Progetto Atena
3.4.2.6.5 Fallimento importazione elenco iscritti
Istanze attori partecipanti:
Flusso degli eventi:
prof. Rossi: Docente.
Database: DBMS_applicazione.
1. Il prof. Rossi sta per iniziare l’appello d’esame; dopo avere scelto la materia
deve importare la lista degli studenti da esaminare.
2. Viene mostrata la schermata con la richiesta dell’indicazione dell’origine
dell’elenco degli iscritti; il prof. Rossi sceglie di importare l’elenco dal
Database.
3. Il collegamento con il Database non risulta al momento disponibile; viene
chiesto se tentare nuovamente il collegamento o importare la lista degli
iscritti da un file CSV.
4. Il prof. Rossi sceglie di importare l’elenco da un file CSV precedentemente
salvato e indica la locazione del file.
5. Viene notificata la corretta importazione dell’elenco che viene mostrato a
video.
6. Il prof. Rossi può iniziare l’appello d’esame con il primo candidato.
3.4.2.6.6 Richiesta iscrizione straordinaria ad esame
Istanze attori partecipanti:
Flusso degli eventi:
Luigi: Studente.
prof. Rossi: Docente.
Database: DBMS_segreteria.
1. Luigi, dopo avere fatto richiesta di inserimento della materia Informatica
Grafica nel proprio piano di studi, ha necessità di iscriversi al relativo esame.
2. Dall’apposita sezione relativa all’iscrizione agli esami la materia Informatica
Grafica non risulta disponibile poiché i dati della segreteria non sono ancora
stati aggiornati.
3. Luigi richiede allora l’iscrizione forzata all’esame mediante la relativa
opzione.
4. Viene mostrata una schermata contenente l’elenco degli esami disponibili per
tutte le materie ed un’area di testo.
5. Luigi seleziona l’appello dell’esame di Informatica Grafica e scrive
nell’apposita area le motivazioni per la richiesta di iscrizione straordinaria.
6. Luigi conferma la richiesta di iscrizione straordinaria; viene richiesto un
recapito telefonico ed un indirizzo e-mail, che Luigi fornisce.
7. Il sistema preleva dal Database l’indirizzo e-mail del docente titolare della
materia Informatica Grafica e gli invia una e-mail con la richiesta, corredata
del Nome, Cognome e Numero di Matricola dello studente.
3.4.3 Use case model e Dynamic models
Questi due modelli sono sostituiti da diagrammi presenti nel progetto PASSI.
3.4.3.1 Interfaccia utente e mock-ups
In questo paragrafo viene fornita una panoramica delle interfacce utente impiegate nel sistema.
I criteri generali che sono stati applicati nella progettazione dell’interfaccia grafica sono stati la
funzionalità, la facilità di utilizzo e gradevolezza. Dove si è potuto sono stati inseriti componenti
grafici che guidino l’utente nella scelta dei dati corretti, mediante menù a tendina o form predefiniti
(come nel caso del calendario per il cambio data).
Inoltre per evidenziare le sezioni diverse del sistema per ogni tipologia di utente, ad ognuna di esse
è stato associato un colore diverso per lo sfondo.
Segue la descrizione dei mock-up che vengono presentati suddivisi per attore di pertinenza.
23/36
Requirements Analysis Document
Progetto Atena
3.4.3.1.1 Amministratore
Una volta effettuato l’accesso al sistema, all’amministratore viene visualizzata la seguente finestra:
Figura 1 - Amministratore - Finestra principale
In questa finestra compaiono due bottoni: l’”Invia comunicazione di servizio” provoca la comparsa
della finestra “Invio posta”, mentre il “Modifica data esame/i” fa accedere alla finestra “Cambio
data esame”. Da sottolineare la presenza di due bottoni per il logoff dal sistema che denotano le due
modalità di uscita dal programma da parte dell’amministratore. Il pulsante “Logoff” permette la
normale uscita dal programma, mentre “Logoff e fornisci servizi”, disattiva la sezione
dell’amministratore accessibile dall’attore, ma lascia attivo l’amministratore software per la
fornitura di servizi ad altri utenti, quali il servizio di cambio data d’esame e l’invio di
comunicazioni.
Dopo la pressione del pulsante “Invia comunicazione di servizio”, il sistema visualizza quest’altra
finestra:
24/36
Requirements Analysis Document
Progetto Atena
Figura 2 - Amministratore - Invio posta
Tale finestra riproduce i campi tradizionali di un client di posta elettronica per offrire una
interfaccia dal modello già conosciuto.
In tale finestra l’amministratore può scegliere alcuni o tutti i docenti a cui inviare le comunicazioni;
alla selezione della riga relativa ad un nominativo, l’indirizzo e-mail viene automaticamente
visualizzato nell’area testo dei destinatari.
L’amministratore può inserire l’oggetto e il testo della comunicazione. Il pulsante “Invia” inoltra le
e-mail.
Se invece l’amministratore dalla finestra principale pressa il pulsante “Modifica data esame/i”
compare la finestra:
Figura 3 - Amministratore - Cambio data d'esame prima della scelta dell'esame
Essa visualizza gli esami al momento stabiliti dal calendario accademico, inoltre per ogni esame
sono specificati il nome della materia, il docente titolare e le date d’esame. Al momento il
calendario che offre le date alternative risulta disattivato in quanto non è stato selezionato alcun
esame di cui richiedere un cambio di data. Successivamente alla scelta di un esame diventano attivi
sia il calendario sia il bottone “Modifica data”. Selezionato un esame l’utente può scegliere da menù
a tendina mese e anno e dal calendario il giorno.
25/36
Requirements Analysis Document
Progetto Atena
Figura 4 - Amministratore - Cambio data d'esame dopo scelta dell'esame
Se come data alternativa viene scelta da calendario una domenica, il sistema non accetta tale scelta
e chiede di scegliere un’altra data. Scelta graficamente una data ammissibile, il sistema preleva
automaticamente la nuova data.
Il bottone “Modifica data” modifica la data dell’esame scelto.
3.4.3.1.2 Studente
La finestra che ogni studente trova già visualizzata sul monitor del totem a cui accede è la finestra
per accedere al sistema ed è la seguente:
Figura 5 - Studente – Login
Dunque vengono richiesti i dati per effettuare l’autenticazione, quali userID e password. In caso di
inserimento di dati errati, il sistema non permette l’accesso e ripropone la medesima finestra di
ingresso. La stessa finestra viene nuovamente visualizzata al momento dell’uscita dal sistema per
permettere l’autenticazioni di eventuali nuovi utenti.
26/36
Requirements Analysis Document
Progetto Atena
Ad autenticazione avvenuta, il sistema mostra la seguente finestra che presenta allo studente le
funzionalità a cui può accedere:
La finestra mostra i pulsanti “Visualizza iscrizioni” che fa accedere alla finestra “Visualizza
iscrizioni”, il pulsante “Iscrizione esami” che fa accedere alla finestra “Iscrizione esami” e il
pulsante “Cancellazione iscrizioni” che visualizza la finestra “Cancellazione esami”.
Inoltra in basso a destra è presente il pulsante per effettuare al disconnessione dal sistema.
A completamento della finestra in alto a sinistra viene proposto un calendario che visualizza la data
corrente in modo tale da offrire un riferimento temporale allo studente che si appresta a pianificare i
propri esami.
Alla pressione del pulsante “Iscrizione esami” viene visualizzata la finestra che permette allo
studente di effettuare le iscrizioni agli esami schedulata, ovvero:
27/36
Requirements Analysis Document
Progetto Atena
Figura 6 - Studente - Iscrizione esami
In tale finestra viene presentata una tabella che mostra solo l’elenco degli esami a cui lo studente
può iscriversi, ovvero quelli relativi a materie appartenenti al suo piano di studi e appartenenti al
suo anno di corso o a quelli precedenti. Per ogni esame vengono visualizzati il nome della materia,
il nome del docente titolare, la data dell’esame e eventuali note informative di comunicazioni che il
docente desidera fornire agli studenti. Il bottone “Iscrizione” diviene attivo soltanto in seguito alla
selezione di un esame e permette l’accesso alla finestra nella quale sono richiesti il numero di
telefono e l’indirizzo e-mail, dati che non essendo obbligatori al momento dell’iscrizione al corso di
studi, potrebbero non essere disponibili al database, ma che possono essere utili per eventuali
comunicazioni di servizio. Mentre alla pressione del bottone “Richiedi iscrizione forzata” verrà
visualizzata una finestra contenente un elenco degli esami a cui potersi iscrivere arricchito, ovvero
contenente anche le materie che non appartengono al piano di studi dello studente, ma sempre
facenti parte delle materie previste per il corso di laurea. Una volta scelta la materia di cui si
desidera richiedere l’iscrizione forzata, compare la seguente finestra, che permette di inserire
recapito telefonico, indirizzo e-mail e motivazione dell’iscrizione. Alla pressione del bottone
“Conferma iscrizione” si inoltra la richiesta. Il sistema provvederà a inviare la mail di richiesta al
docente del caso.
Figura 7 - Studente - Conferma di un'iscrizione straordinaria
L’ultima funzionalità a cui lo studente può accedere dalla schermata principale è quella relativa al
bottone “Cancellazione iscrizioni”, che provoca la comparsa della seguente finestra:
28/36
Requirements Analysis Document
Progetto Atena
Figura 8 - Studente - Cancellazione iscrizioni
La tabella visualizza gli esami a cui lo studente è correntemente iscritto; a questo punto basta
selezionare un esame e pressare il bottone “Cancella” per effettuare la cancellazione dell’iscrizione
selezionata.
3.4.3.1.3 Docente
Dopo aver effettuato l’accesso al sistema mediante userID e password, al docente viene visualizzata
la finestra principale della sua sezione.
Figura 9 - Docente - Finestra principale
Da essa può effettuare il logoff mediante pressione del bottone “Logoff”. Il bottone “Preparazione
esami” permette l’accesso alla finestra “Preparazione esami”, mentre il bottone “Svolgimento
esami” fa comparire la finestra “Selezione sorgente dati”.
Quindi la prima finestra relativa alla sottosezione della preparazione agli esami è la seguente:
29/36
Requirements Analysis Document
Progetto Atena
Figura 10 - Docente - Preparazione agli esami
All’autenticazione del docente, il sistema carica automaticamente le materie impartite dal docente,
che sono visualizzate in questa finestra. Anche in questo caso prima della scelta della materia, non
viene attivato il bottone “Domande d’esame”, in quanto le domande sono pertinenti ad una materia.
Il bottone “Domande d’esame” fa accedere alla finestra “Gestione quesiti d’esame”:
Figura 11 - Docente - Gestione quesiti d'esame
In questa schermata viene fornita una tabella contenente l’elenco dei quesiti d’esame che il docente
ha precedentemente archiviato. Ad ogni quesito è associato un identificativo numerico sequenziale
e una check-box che indica i quesiti da salvare. Tramite questa finestra il docente può effettuare le
tradizionali operazioni di gestione di una struttura dati, quali l’inserimento (tramite la riga di testo
posta in basso), cancellazione (spuntando il quesito da eliminare) e modifica (composta da
cancellazione e inserimento). Alla fine di tutte le operazioni di gestione, il docente rende effettive le
modifiche pressando il bottone “Salva modifiche”.
I bottoni “Visualizza elenco iscritti” e “Comunicazioni agli studenti” accedono alla finestra “Scegli
esame”, che nel primo caso presenta come bottone d’avanzamento “Visualizza elenco”, mentre nel
secondo caso “Invia comunicazioni”.
30/36
Requirements Analysis Document
Progetto Atena
Figura 12 - Docente - Scelta dell'esame di cui visualizzare l'elenco degli iscritti
Tale finestra visualizza tutti gli appelli previsti delle materie impartite dal docente e le note relative
agli esami. Scegliendo un esame il docente può visualizzare l’elenco degli studenti iscritti, per
mezzo della pressione dell’apposito bottone “Visualizza elenco”.
All’interno della procedura per visualizzare gli iscritti ad un esame, alla pressione del bottone
“Visualizza elenco” compare la finestra “Visualizza iscritti”.
Figura 13 - Docente - Visualizza iscritti
Per ogni studente sono specificati nome, cognome e numero di matricola. Il docente può decidere se
stampare l’elenco pressando il bottone “Stampa”, o salvare l’elenco in un file di formato CSV.
Nella procedura per l’invio di comunicazioni agli studenti, alla pressione del bottone “Invia
comunicazioni” viene visualizzata la finestra per l’invio delle mail “Invio posta”.
31/36
Requirements Analysis Document
Progetto Atena
Figura 14 - Docente - Finestra per la preparazione di una e-mail del docente agli studenti.
Automaticamente il sistema inserisce nel campo destinatari tutti gli studenti, dei quali il sistema
provvede a procurarsi gli indirizzi e-mail, e l’intestazione della comunicazione all’interno dell’area
testo, che specifica il nome della materia, la data d’esame e il docente titolare. Il docente deve
scrivere manualmente soltanto l’oggetto e il messaggio della comunicazione. L’invio di questa
ultima è reso effettivo dalla pressione del bottone “Invia”.
Se dalla finestra principale del docente l’utente sceglie di accedere alla funzionalità del cambio data
d’esame, mediante la pressione del bottone “Modifica data esame”, viene visualizzata la finestra
seguente:
Essa è graficamente analoga a quella che compare all’amministratore del sistema in sede di cambio
data d’esame.
Per ultimo, il docente può scegliere di accedere alla modalità iscrizione straordinaria, tramite la
pressione del pulsante “Iscrizione straordinaria”, che provoca la comparsa della seguente:
32/36
Requirements Analysis Document
Progetto Atena
Si presuppone che il docente abbia ricevuto una e-mail da parte di uno studente, contenente la
richiesta di iscrizione ad una materia momentaneamente non presente nel proprio piano di studi.
Entro tale mail lo studente ha specificato l’esame a cui chiede di essere iscritto e i propri dati
personali. Dunque il docente è a conoscenza di tali informazioni, che possono essere qui inserite. Al
momento della pressione del bottone “Aggiungi iscrizione” il sistema si occuperà di aggiungere lo
studente all’elenco dell’esame scelto e all’invio di una e-mail di risposta allo studente.
Se dalla finestra “Preparazione esami” di figura 10 il docente sceglie il bottone “Svolgimento
esami”, accede alla seconda macroarea funzionale interessante il docente, ovvero quella relativa allo
svolgimento vero e proprio degli esami. Appare la finestra per la selezione della sorgente dei dati.
Figura 15 - Docente - Scelta sorgente dei dati
Si presuppone che generalmente venga scelto di acquisire i dati dal database, la cui veridicità è
assicurata, ma in caso di assenza di connessione al database o per pura volontà del docente, egli può
caricare i dati necessari all’esame da un file in suo possesso in formato CSV, precedentemente
creato in fase di preparazione agli esami.
Se viene scelto di caricare da file CSV, viene mostrata una finestra per fornire al sistema il percorso
del file e si prosegue regolarmente allo svolgimento esami, facendo comparire la finestra della
figura 16. Diversamente nel caso in cui si scelga di caricare i dati da database, occorre prima
scegliere l’appello relativamente al quale si richiedono i dati, successivamente compare la stessa
finestra della figura 16, in modo da far convergere le due alternative di caricamento dati.
33/36
Requirements Analysis Document
Progetto Atena
Figura 16 - Docente - Visualizzazione elenco iscritti
Grazie a tale interfaccia, il docente può regolarmente chiamare l’appello prima di cominciare
l’esame e segnare le assenze mediante apposita check-box. Opzionalmente il docente può anche
stampare o esportare l’elenco in un file CSV. Mentre alla pressione del bottone “Continua” compare
la finestra “Svolgimento esami”.
Figura 17 - Docente - Svolgimento esami
In essa tramite un menù a tendina viene visualizzato di volta in volta lo studente da esaminare. Il
sistema propone un ordine sequenziale degli esaminandi, provvedendo automaticamente a fornirne
il successivo, tuttavia il docente può stabilire a mano a mano lo studente da esaminare secondo un
proprio ordine. Anche da questa finestra il docente può segnare l’assenza o il ritiro del candidato,
mediante pressione del bottone “Candidato assente/ritirato”. Il docente può anche avere una visione
di insieme degli iscritti pressando il pulsante “Visualizza/stampa elenco iscritti”, che permette
anche di stampare l’elenco.
34/36
Requirements Analysis Document
Progetto Atena
Alla pressione del bottone “Esamina nuovo candidato” appare la finestra di figura 18, il cui titolo
indica il nominativo dello studente che si sta interrogando, la materia e l’ordinamento.
Figura 18 - Docente - Finestra per lo svolgimento esami
Dal menù a tendina in alto a sinistra il docente può scegliere i quesiti d’esame da sottoporre al
candidato e che andranno inseriti automaticamente sul verbale. In ogni caso il docente può porre
allo studente una domanda che non appartenga all’elenco fornito, digitandone il testo nell’apposita
area. Nel caso in cui il docente ritenga che l’esame abbia avuto un esito negativo, pressando il
bottone “Esame non superato”, il nominativo dello studente viene eliminato dall’elenco degli iscritti
dell’esame e ricompare la finestra di figura 17, col nominativo del successivo studente da
interrogare. Alla pressione del bottone “Esame superato” si attiva la casella di testo “Inserisci voto
proposto” che permette di inserire il voto. A questo punto pressando il bottone “Registrazione
esame” viene avviata la procedura di compilazione e stampa dell’opportuna documentazione.
Alla pressione del bottone “Arresta svolgimento esami” delle finestra di figura 17 o al momento in
cui l’elenco degli iscritti all’esame risulta vuoto, viene fatta apparire la finestra per la chiusura del
verbale, “Chiusura verbale”.
35/36
Requirements Analysis Document
Progetto Atena
Figura 19 - Finestra per la chiusura del verbale
In tale finestra si indicano la data e l’orario della chiusura del verbale. Il sistema propone data e ora
correnti, ma il docente può anche specificarli manualmente. Con la pressione del bottone “Stampa
verbale” si procede alla compilazione dei campi relativi alla chiusura del verbale, ad esclusione
delle firme dei membri della commissione le quali devono essere apposte manualmente.
36/36
