Requirements Analysis Document · 2010. 1. 2. · Requirements Analysis Document Progetto Atena...

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

2/36

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 Gestione studente .........................................................................................................................................6 3.1.2 Gestione docente ..........................................................................................................................................7 3.1.3 Gestione amministratore ..............................................................................................................................8

3.2 Requisiti non funzionali.................................................................................................................. 8 3.2.1 Interfaccia utente e fattori umani .................................................................................................................8 3.2.2 Accesso ai disabili ........................................................................................................................................8 3.2.3 Documentazione...........................................................................................................................................8 3.2.4 Considerazioni hardware..............................................................................................................................9 3.2.5 Caratteristiche prestazionali .......................................................................................................................10 3.2.6 Gestione degli errori e casi eccezionali......................................................................................................10 3.2.7 Interfaccia del sistema................................................................................................................................10 3.2.8 Modifiche del sistema ................................................................................................................................10 3.2.9 Sicurezza ....................................................................................................................................................10 3.2.10 Privacy...................................................................................................................................................11 3.2.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


3/36

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


4/36

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


5/36

• 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 - APPLICATION-

DEFINED 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


6/36

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.


7/36

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ò


8/36

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.


9/36

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


10/36

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.


11/36

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.


12/36

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.


13/36

3.4.2.1 Scenari di autenticazione

3.4.2.1.1 Autenticazione studente Istanze attori partecipanti: Luigi: Studente

Database: DBMS_applicazione. Flusso degli eventi: 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: prof. Rossi: Docente

Database: DBMS_applicazione. Flusso degli eventi: 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: sig. Gianni: Amministratore.

Database: DBMS_applicazione. Flusso degli eventi: 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.


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.


14/36

3.4.2.2.1 Iscrizione ad esame Istanze attori partecipanti: Luigi: Studente.

Database: DBMS_applicazione. Segreteria: DBMS_segreteria.

Flusso degli eventi: 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 e-mail 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: Luigi: Studente.

Database: DBMS_applicazione Flusso degli eventi: 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: Luigi: Studente.

Database: DBMS_applicazione. Flusso degli eventi: 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.


15/36

Flusso degli eventi: 1. 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.

2. 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.

3. Il Database fornisce l’indirizzo e-mail dei docenti. 4. L’e-mail viene spedita.

3.4.2.3.2 Modifica data di un esame Istanze attori partecipanti: sig. Gianni: Amministratore.

Database: DBMS_applicazione. Flusso degli eventi: 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: prof. Rossi: Docente.

Database: DBMS_applicazione Flusso degli eventi: 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: prof. Rossi: Docente.

Database: DBMS_applicazione Flusso degli eventi: 1. Il prof. Rossi, in previsione dell’esame di Ingegneria del Software, vuole

preparare alcuni quesiti da sottoporre ai candidati per velocizzare le


16/36

operazioni. 2. Il prof. Rossi accede alla sezione relativa alla preparazione degli esami. 3. Il prof. Rossi sceglie la materia (Ingegneria del Software) e dà il comando

per la gestione dei quesiti d’esame. 4. Viene visualizzato l’elenco dei quesiti d’esame della materia prescelta,

precedentemente memorizzate sul Database. 5. Il prof. Rossi aggiunge un nuovo quesito d’esame mediante una apposito

campo di testo e conferma l’inserimento. 6. Il nuovo quesito viene aggiunto nel Database. 7. Il sistema visualizza l’elenco aggiornato dei quesiti d’esame. 8. 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: prof. Bianchi: Docente.

Database: DBMS_applicazione Flusso degli eventi: 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: prof. Rossi: Docente.

Database: DBMS_applicazione Flusso degli eventi: 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.


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: prof. Rossi: Docente.

Database: DBMS_applicazione Flusso degli eventi: 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 .



17/36

comando per la stampa degli iscritti. 4. Il Database fornisce al sistema l’elenco degli studenti iscritti desiderato;

viene visualizzata un’anteprima di stampa a video. 5. 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: prof. Rossi: Docente.

Database: DBMS_applicazione. Flusso degli eventi: 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: prof. Rossi: Docente. Flusso degli eventi: 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: prof. Rossi: Docente.

Database: DBMS_applicazione. Flusso degli eventi: 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


18/36

sessione.

3.4.2.5.4 Gestione contemporanea più appelli d’esame Istanze attori partecipanti: prof. Rossi: Docente. Flusso degli eventi: 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: prof. Rossi: Docente.

Luigi: Studente. Database: DBMS_applicazione.

Flusso degli eventi: 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: prof. Rossi: Docente.


Flusso degli eventi: 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


19/36

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: prof. Rossi: Docente.


Flusso degli eventi: 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: prof. Rossi: Docente. Flusso degli eventi: 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: prof. Rossi: Docente.

Luigi: Studente. Flusso degli eventi: 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


20/36

(modificabili), la votazione, il nome del candidato ed il codice della materia. 6. 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.

7. Il prof. Rossi e Luigi firmano il verbale. 8. L’esame si considera concluso ed il prof. Rossi può continuare con i

candidati rimanenti.

3.4.2.5.10 Chiusura verbale a fine appello Istanze attori partecipanti: prof. Rossi: Docente. Flusso degli eventi: 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.

3.4.2.5.11 Chiusura verbale a interruzione appello Istanze attori partecipanti: prof. Rossi: Docente. Flusso degli eventi: 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.

3.4.2.5.12 Studente ritirato o assente Istanze attori partecipanti: prof. Rossi: Docente.

Luigi: Studente. Flusso degli eventi: 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.

3.4.2.5.13 Stampa iscritti all’esame e verifica delle presenze Istanze attori partecipanti: prof. Rossi: Docente. Flusso degli eventi: 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.


21/36

3. 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.

4. 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.

5. Terminate le operazioni di verifica delle presenze il prof. Rossi conferma le assenze e può procedere con l’inizio dell’esame.

6. Il sistema elimina dalla lista degli iscritti i nominativi segnati.

3.4.2.5.14 Stampa verbale su nuova facciata Istanze attori partecipanti: prof. Rossi: Docente. Flusso degli eventi: 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.

3.4.2.5.15 Stampa verbale su nuova facciata e nuova pagina Istanze attori partecipanti: prof. Rossi: Docente. Flusso degli eventi: 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: prof. Rossi: Docente.

Database: DBMS_applicazione. Flusso degli eventi: 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


22/36

scegliere, nome, cognome e numero di matricola dello studente richiedente l’iscrizione.

5. Il prof. Rossi inserisce i dati, presenti nell’e-mail ricevuta, e procede con la registrazione straordinaria.

6. Il Database riceve la richiesta di iscrizione all’esame e la memorizza. 7. Il sistema notifica al prof. Rossi l’avvenuta iscrizione all’esame. 8. 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: Luigi: Studente. Flusso degli eventi: 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: prof. Rossi: Docente.

Database: DBMS_applicazione. Flusso degli eventi: 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: Luigi: Studente.

Database: DBMS_applicazione. Flusso degli eventi: 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).


6. Il Database notifica l’errore nei dati inseriti; il sistema mostra un messaggio comunicante l’errore e ritorna alla finestra di autenticazione.


23/36

3.4.2.6.5 Fallimento importazione elenco iscritti Istanze attori partecipanti: prof. Rossi: Docente.

Database: DBMS_applicazione. Flusso degli eventi: 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: Luigi: Studente.

prof. Rossi: Docente. Database: DBMS_segreteria.

Flusso degli eventi: 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.


24/36

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:


25/36

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.


26/36

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.


27/36

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:


28/36

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:


29/36

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:


30/36

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”.


31/36

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”.


32/36

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:


33/36

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.


34/36

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.


35/36

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 m

Requirements Analysis Document · 2010. 1. 2. · Requirements Analysis Document Progetto Atena...

Documents

Transcript of Requirements Analysis Document · 2010. 1. 2. · Requirements Analysis Document Progetto Atena...