Documento di ANALISI DEI REQUISITI Progetto di un portale per una società di servizi dedicati al settore delle imprese edili

Transcript

1 Documento di ANALISI DEI REQUISITI Progetto di un portale per una società di servizi dedicati al settore delle imprese edili GRUPPO 2 Indice analitico - 1. Introduzione Obiettivi del sistema Visibilità del sistema Obiettivi e criteri di successo del progetto Definizioni, acronimi e abbreviazioni Riferimenti Sistema proposto Requisiti funzionali Requisiti non funzionali Modello del sistema Scenari Contatta responsabile Visualizza lista gare Ricerca gare Scarica gara Inserimento nuova gara Modifica gara Cancella gara Inserimento nuovo utente Modifica utente Cancella utente Casi d uso ContattaResponsabileClientela VisualizzaListaGare RicercaGare ScaricaGara InserimentoNuovaGara ModificaGara CancellaGara InserimentoNuovoUtente ModificaUtente CancellaUtente Modello ad oggetti e modello dinamico ContattaResponsabileClientela VisualizzaListaGare RicercaGare ScaricaGara

2 InserimentoGara ModificaGara CancellaGara InserimentoUtente ModificaUtente CancellaUtente Relazioni tra oggetti Relazioni tra oggetti relativi a Visitatore Relazioni tra oggetti relativi ad Abbonato e Gara Relazioni tra oggetti relativi all Amministratore Diagrammi di stato Diagramma di stato per gara Diagramma di stato per abbonamento di tipo IS Diagramma di stato per abbonamento di tipo PS Identificazione degli attributi per Gara Mock-up Tempo richiesto per il completamento di questa documentazione

3 1. Introduzione 1.1 Obiettivi del sistema L obiettivo del progetto è la realizzazione di un portale internet per la messa on line di un servizio di gare e di appalti relative al settore edile. Il servizio è diretto sia alle aziende che intendono pubblicare una gara di appalto per la realizzazione di un lavoro edile sia alle imprese edili interessate alla consultazione delle gare. 1.2 Visibilità del sistema L utenza del sistema potrà accedere ad un catalogo di gare divise per categorie previa iscrizione al portale; in caso contrario, cioè non ci si logga, potrà soltanto visualizzare alcune gare per rendersi conto del tipo e della qualità del servizio che si offre per poi, eventualmente, fare l iscrizione. 1.3 Obiettivi e criteri di successo del progetto I criteri con cui valuteremo il sistema al termine di tutto il processo produttivo sono: semplicità, utilità e gestione rapida e veloce delle operazioni di inserimento e aggiornamento delle gare. Il sistema dovrà garantire affidabilità, tolleranza agli errori e robustezza. Tali caratteristiche verranno validate effettuando delle operazioni di testing da parte del cliente e degli sviluppatori stessi. 1.4 Definizioni, acronimi e abbreviazioni Sono previsti tre livelli di utenti che potranno accedere al sito: - Amministratore/webmaster (livello 3) - Abbonato (livello 2) - Visitatore (livello 1) L utente Amministratore, riconosciuto dal sistema, è colui che può gestire l utenza e il catalogo delle gare. L utente Abbonato è colui che vuole visualizzare le informazioni relative ad una gara ed è in possesso dei dati personali di accesso (login e password). Il visitatore è un utente non registrato sul portale. Il sistema prevede due tipologie di abbonamento: - Prepagato a scalare (in seguito denominato PS) - Illimitato a scadenza (in seguito denominato IS) Il portale informativo è diviso in varie sottosezioni tra cui: - Gare e appalti (parzialmente visibile agli utenti non registrati). Quest area contiene tutte le informazioni sulle gare disponibili e offre la possibilità di effettuare delle ricerche per tipologia, categoria o provincia. - Catalogo imprese L area catalogo imprese contiene informazioni su alcune imprese edili che vogliono essere visibili sul portale. - Certificazioni - Sicurezza - Amministrazione (area privata) Per link utili viene intesa una lista di riferimenti a siti relativi al settore edile. 3

4 1.5 Riferimenti - Bernd Bruegge e Allen H. Dutoit - Object-Oriented Software Engineering (using UML, Patterns and Java TM ) Prentice Hall - Slide del docente Carmine Gravino 2. Sistema proposto 2.1 Requisiti funzionali Il sistema visualizzerà una lista di gare disponibili, le quali, memorizzate in un database, possono essere aggiornate dall amministratore attraverso l area riservata del sistema. In particolare l utente di livello 3 (amministratore) potrà accedere a tutte le aree del sito e anche ad un area protetta in cui è possibile modificare, cancellare o inserire nuove gare, o accedere ai dati degli utenti. L utente di livello 2 (abbonato) è colui che vuole visualizzare le informazioni relative ad una gara ed è in possesso dei dati personali di accesso. L utente di livello 1 (visitatore) è un utente di passaggio dal portale e può accedere solo ad alcune gare in modo da rendere l idea del materiale disponibile e ad invogliare gli stessi ad abbonarsi al servizio. La lista delle gare contiene informazioni parziali (titolo, data e uno stralcio della descrizione) e sarà visualizzabile da tutte le tipologie di utenza. L abbonamento al servizio di Gare e appalti può essere di due tipi: - PS Questo tipo di abbonamento prevede la ricarica di un conto virtuale dell utente che verrà poi successivamente decrementato ad ogni visura effettuata. La quantità di credito disponibile viene espresso in euro e sarà ricaricabile a mezzo bonifico bancario. L aggiornamento del conto verrà effettuato dall amministratore del sito utilizzando l apposita area riservata. - IS L abbonamento illimitato permette l accesso ai servizi senza limiti di download ma prevede una scadenza e quindi deve essere rinnovato dall utente pagando un corrispettivo sempre a mezzo bonifico. 2.2 Requisiti non funzionali I requisiti non funzionali che il sistema dovrà rispettare sono: - Disponibilità 24 ore al giorno 365 giorni l anno. - Risposte in tempo reale. - Semplicità di utilizzo e intuitività. - Resistenza agli attacchi alla sicurezza. - Facile modifica delle gare presenti nel catalogo. - Semplicità di modifica del sistema in caso di difetti o per far fronte a nuove tecnologie. - Il software del sistema dovrà essere scritto usando tecnologia Java e Servlet la quale permette portabilità e semplice modularizzazione. 4

5 3. Modello del sistema 3.1 Scenari Scenario 1: Contatta responsabile Nome scenario: Partecipanti: Flusso degli eventi: ContattaResponsabile Bob: Visitatore 1. Bob accede al portale 2. Bob accede alla sezione contatti 3. Il sistema visualizza il form 4. Bob inserisce i propri dati e li invia 5. Il sistema notifica l invio dei dati Scenario 2: Visualizza lista gare Nome scenario: Partecipanti: Flusso degli eventi: VisualizzaListaGare Bob: Visitatore 1. Bob accede al portale 2. Bob richiede una lista degli appalti 3. Il sistema visualizza una lista degli appalti Scenario 3: Ricerca gare Nome scenario: Partecipanti: Flusso degli eventi: RicercaGare Bob: Visitatore 4. Bob accede al portale 5. Bob richiede il form per la ricerca delle gare 6. Il sistema visualizza il form 7. Bob inserisce i campi categoria, tipo e le date e sottomette il form 8. Il sistema visualizza la lista delle gare trovate Scenario 4: Scarica gara 5

6 Nome scenario: Partecipanti: Flusso degli eventi: ScaricaGara Jack: Abbonato 1. Jack accede al portale e si autentica 2. Jack richiede la lista degli appalti 3. Il sistema visualizza la lista degli appalti 4. Jack seleziona l appalto da scaricare 5. Il sistema verifica che il credito disponibile sia sufficiente e mostra le informazioni sull appalto. Scenario 5: Inserimento nuova gara Nome scenario: Partecipanti: Flusso degli eventi: InserimentoNuovaGara Alice: Amministratore 1. Alice accede al portale e si autentica 2. Alice richiede il form per inserire una nuova gara d appalto 3. Il sistema visualizza il form 4. Alice compila il form e lo invia 5. Il sistema aggiorna gli appalti e lo notifica Scenario 6: Modifica gara Nome scenario: Partecipanti: Flusso degli eventi: ModificaGara Alice: Amministratore 1. Alice accede al portale e si autentica 2. Alice seleziona l operazione di modifica 3. Il sistema visualizza la lista degli appalti 4. Alice richiede il form per modificare una gara d appalto esistente 5. Il sistema visualizza il form 6. Alice compila il form e lo invia 7. Il sistema aggiorna la gara e lo notifica Scenario 7: Cancella gara 6

7 Nome scenario: Partecipanti: Flusso degli eventi: CancellaGara Alice: Amministratore 1. Alice accede al portale e si autentica 2. Alice seleziona l operazione di cancellazione 3. Il sistema visualizza la lista degli appalti 4. Alice richiede la cancellazione di una gara d appalto esistente 5. Alice conferma l operazione 6. Il sistema cancella l appalto e lo notifica Scenario 8: Inserimento nuovo utente Nome scenario: Partecipanti: Flusso degli eventi: InserimentoNuovoUtente Alice: Amministratore 1. Alice accede al portale e si autentica 2. Alice seleziona l operazione di inserimento 3. Alice richiede il form per l inserimento di un nuovo utente 4. Il sistema visualizza il form 5. Alice compila il form e lo invia 6. Il sistema aggiunge il nuovo utente e lo notifica Scenario 9: Modifica utente Nome scenario: Partecipanti: Flusso degli eventi: ModificaUtente Alice: Amministratore 1. Alice accede al portale e si autentica 2. Alice richiede il form per la modifica di un utente 3. Il sistema visualizza il form 4. Alice compila il form e lo invia 5. Il sistema modifica i dati dell utente e lo notifica Scenario 10: Cancella utente 7

8 Nome scenario: Partecipanti: Flusso degli eventi: CancellaUtente Alice: Amministratore 1. Alice accede al portale e si autentica 2. Alice richiede l operazione di cancellazione di un utente 3. Il sistema visualizza la lista degli utenti 4. Alice conferma l operazione 5. Il sistema cancella l utente e lo notifica Casi d uso Nome Use Case Partecipanti Flusso degli eventi Condizioni d ingresso Condizioni d uscita ContattaResponsabileClientela Inizializzato dal Visitatore 1. Il Visitatore accede al portale 2. Il sistema visualizza la pagina iniziale 3. Il Visitatore richiede il form per contattare il responsabile alla clientela 4. Il sistema visualizza il form 5. Il Visitatore compila il form e lo sottomette 6. Il sistema notifica il corretto invio del form Il Visitatore ha accesso al portale Il Visitatore ha inviato i propri dati Nome Use Case Partecipanti Flusso degli eventi VisualizzaListaGare Inizializzato dal Visitatore 1. Il Visitatore accede al portale 2. Il sistema visualizza la pagina iniziale 3. Il Visitatore richiede la lista delle gare d appalto 8

9 Condizioni d ingresso Condizioni d uscita 4. Il sistema visualizza una lista degli appalti Il Visitatore ha accesso al portale Il Visitatore ha ottenuto la lista delle gare d appalto Nome Use Case Partecipanti Flusso degli eventi Condizioni d ingresso Condizioni d uscita Condizioni eccezionali RicercaGare Inizializzato dal Visitatore 1. Il Visitatore accede al portale 2. Il sistema visualizza la pagina iniziale 3. Il Visitatore richiede la form per la ricerca delle gare d appalto 4. Il sistema visualizza il form 5. Il Visitatore inserisce i campi categoria, titolo e date e sottomette la ricerca 6. Il sistema visualizza la lista delle gare Il Visitatore ha accesso al portale Il Visitatore ha ottenuto la lista delle gare d appalto Al punto 6 il sistema può mostrare un errore nel caso non esistano gare con i criteri di ricerca richiesti. Nome Use Case Partecipanti Flusso degli eventi Condizioni d ingresso Condizioni d uscita Condizioni eccezionali ScaricaGara Inizializzato dall Abbonato 1. L Abbonato accede al sistema 2. Il sistema visualizza la lista degli appalti 3. L Abbonato seleziona l appalto da scaricare 4. Il sistema controlla il credito, scarica il dovuto e visualizza l appalto L Abbonato ha accesso al portale Il bando è stato scaricato Al punto 4 il sistema può mostrare un messaggio di errore se il credito è esaurito. 9

10 Nome Use Case Partecipanti Flusso degli eventi Condizioni d ingresso Condizioni d uscita InserimentoNuovaGara Inizializzato dall Amministratore 1. L Amministratore accede al portale e si autentica 2. Il sistema mostra le possibili operazioni di aggiornamento 3. L Amministratore seleziona l operazione d inserimento 4. Il sistema visualizza il form per l inserimento di una nuova gara d appalto 5. L Amministratore compila il form e lo sottomette 6. Il sistema inserisce la nuova gara e notifica l avvenuto inserimento L Amministratore ha accesso all area riservata La gara è stata inserita nel catalogo Nome Use Case Partecipanti Flusso degli eventi Condizioni d ingresso Condizioni d uscita ModificaGara Inizializzato dall Amministratore 1. L Amministratore accede al portale e si autentica 2. Il sistema mostra le possibili operazioni di aggiornamento 3. L Amministratore seleziona l operazione di modifica 4. Il sistema visualizza la lista delle gare modificabili 5. L Amministratore seleziona la gara da modificare 6. Il sistema visualizza il form dei dati della gara 7. L Amministratore compila il form e lo sottomette 8. Il sistema modifica i dati della gara e notifica l avvenuta modifica L Amministratore ha accesso all area riservata La gara è stata modificata 10

11 Nome Use Case Partecipanti Flusso degli eventi Condizioni d ingresso Condizioni d uscita CancellaGara Inizializzato dall Amministratore 1. L Amministratore accede al portale e si autentica 2. Il sistema mostra le possibili operazioni di aggiornamento 3. L Amministratore seleziona l operazione di cancellazione 4. Il sistema visualizza la lista delle gare 5. L Amministratore seleziona la gara da cancellare 6. Il sistema cancella la gara e notifica l avvenuta cancellazione L Amministratore ha accesso all area riservata La gara è stata cancellata dalla lista Nome Use Case Partecipanti Flusso degli eventi Condizioni d ingresso Condizioni d uscita InserimentoNuovoUtente Inizializzato dall Amministratore 1. L Amministratore accede al portale e si autentica 2. Il sistema mostra le possibili operazioni per la gestione dell utente 3. L Amministratore seleziona l operazione di inserimento 4. Il sistema visualizza il form per l inserimento di un nuovo utente 5. L Amministratore compila il form e lo sottomette 6. Il sistema inserisce i dati del nuovo utente e notifica l avvenuto inserimento L Amministratore ha accesso all area riservata Il nuovo utente è stato registrato Nome Use Case Partecipanti Flusso degli eventi Condizioni d ingresso Condizioni d uscita ModificaUtente Inizializzato dall Amministratore 1. L Amministratore accede al portale e si autentica 2. Il sistema mostra le possibili operazioni per la gestione dell utente 3. L Amministratore seleziona l operazione di modifica 4. Il sistema mostra una lista degli utenti registrati 5. L Amministratore seleziona l utente da modificare 6. Il sistema visualizza il form per la modifica di un utente 7. L Amministratore compila il form e lo sottomette 8. Il sistema modifica i dati dell utente e lo notifica. L Amministratore ha accesso all area riservata I dati del nuovo utente sono stati modificati Nome Use Case Partecipanti Flusso degli eventi CancellaUtente Inizializzato dall Amministratore 1. L Amministratore accede al portale e si autentica 11

12 Condizioni d ingresso Condizioni d uscita 2. Il sistema mostra le possibili operazioni per la gestione dell utente 3. L Amministratore seleziona l operazione di cancellazione 4. Il sistema visualizza gli utenti registrati 5. L Amministratore seleziona l utente da cancellare 6. Il sistema cancella i dati dell utente e notifica l avvenuta cancellazione L Amministratore ha accesso all area riservata L utente è stato cancellato 3.3 Modello ad oggetti e modello dinamico Per ciascun caso d uso verranno identificati e descritti gli oggetti entità, boundary e control e successivamente tracciati i sequence diagram Analisi del caso d uso ContattaResponsabileClientela Entity - Visitatore: colui che può accedere al portale per contattare il responsabile - RichiestaInformazioni: le informazioni persistenti create dall utente Boundary - BottoneRichiestaContatto: bottone usato dal visitatore per richiedere il form dei contatti - FormContatti: contiene i campi relativi ai dati personali del visitatore e alle informazioni che si vogliono richiedere. - NotificaContatto: notifica l avvenuto contatto con il responsabile Control - ControlloContatto: gestisce la funzione ContattaResponsabile. Questo oggetto è creato quando il visitatore seleziona il bottone BottoneRichiestaContatto. Questo oggetto genera il form che viene compilato dal visitatore. Il controllo crea l entity RichiestaInformazioni e successivamente il boundary NotificaContatto. 12

13 BottoneRichiestaContatto ::Visitatore press() <<control>> ControlloContatto FormContatti inseriscidati() submit() submit() <<destroy>> <<entity>> RichiestaInformazione NotificaContatto Analisi del caso d uso VisualizzaListaGare Entity - Visitatore: colui che vuole visualizzare la lista delle gare - CatalogoGare: elenco delle gare d appalto Boundary - BottoneVisualizzaGare: bottone usato dal visitatore per iniziare lo use case VisualizzaListaGare - ListaGare: una lista delle gare 13

14 Control - ControlloGare: gestisce la funzione VisualizzaListaGare. Questo oggetto è creato quando il visitatore seleziona il bottone BottoneVisualizzaGare. Questo oggetto interroga l entità CatalogoGare e crea l oggetto boundary ListaGare. BottoneVisualizzaGara ::Visitatore press() <<control>> ControlloGara prendilista() ListaGare <<entity>> CatalogoGare Analisi del caso d uso RicercaGare Entity - Visitatore: colui che vuole ricercare delle gare - CatalogoGare: elenco delle gare d appalto Boundary - BottoneRicercaGare: bottone usato dal visitatore per iniziare lo use case VisualizzaListaGare - ListaGare: una lista delle gare trovate Control - ControlloRicercaGare: gestisce la funzione RicercaListaGare. Questo oggetto è creato quando il visitatore seleziona il bottone BottoneRicercaGare. Questo oggetto interroga l entità CatalogoGare utilizzando i parametri della ricerca selezionati dal Visitatore e crea l oggetto boundary ListaGare. 14

15 BottoneRicercaGare ::Visitatore press() <<control>> ControlloRicercaGare ricercalista() <<entity>> CatalogoGare ListaGare Analisi del caso d uso ScaricaGara Entity - Abbonato: colui che può accedere al portale e scaricare la gara d appalto - CatalogoGare: elenco delle informazioni persistenti sulle gare - InformazioniUtenti: elenco delle informazioni persistenti degli abbonati Boundary - BottoneRichiestaListaAppalti: bottone usato dall abbonato per visualizzare la lista degli appalti scaricabili - ListaGare: una lista delle gare - Gara: informazioni sulla gara scaricata Control - ControlloDownload: gestisce la funzione ScaricaGara. Questo oggetto è creato quando l abbonato seleziona il bottone BottoneRichiestaListaAppalti. Questo oggetto interpella l entity CatalogoGare e crea il boundary ListaGare. Dopo che l Abbonato ha selezionato la gara da scaricare crea il boundary Gara. 15

16 BottoneRichiestaListaAppalti <<entity>> CatalogoGare ::Abbonato press() <<control>> ControlloDownload prendilista() ListaGare selezionagara() garaselezionata() <<destroy>> controllocreditoutente() <<entity>> InformazioniUtenti Gara Analisi del caso d uso InserimentoGara Entity - Amministratore: colui che può inserire una nuova gara. - CatalogoGare: elenco delle informazioni persistenti sulle gare d appalto. Boundary - BottoneInserimentoGara: bottone usato dall Amministratore per iniziare lo use case InserimentoGara - FormInserimentoGara: form usato per l input quando viene selezionato InserisciGara. Contiene campi per specificare l operazione di inserimento, gli attributi di una gara e un bottone per sottomettere il form completato. - NotificaInserimentoAvvenuto: usato per confermare l avvenuto inserimento della gara. 16

17 Control - ControlloInserimentoGara: gestisce la funzione InserimentoGara. Questo oggetto è creato quando l amministratore seleziona il bottone BottoneInserimentoGara. Crea un boundary FormInserimentoGara e lo presenta all Amministratore. Dopo la sottomissione del form, questo oggetto colleziona le informazioni, inserisce la gara nell entity CatalogoGare e crea il boundary NotificaInserimentoAvvenuto. BottoneInserimentoGara <<entity>> CatalogoGare ::Amministratore press() <<control>> ControlloInserimentoGara FormInserimentoGara inseriscidati() submit() submit() <<destroy>> aggiornacatalogo() NotificaConfermaInserimento 17

18 Analisi del caso d uso ModificaGara Entity - Amministratore: colui che può modificare una gara - CatalogoGare: elenco delle gare d appalto Boundary - BottoneModificaGare: bottone usato da Amministratore per iniziare lo use case ModificaGara - ListaGare: una lista delle gare - FormModificaGara: form usato per l input quando viene selezionato ModificaGara. Contiene i campi per modificare gli attributi di una gara e un bottone per sottomettere il form completato. - NotificaModificaAvvenuta: usato per confermare l avvenuta modifica della gara. Control - ControlloModificaGara: gestisce la funzione ModificaGara. Questo oggetto è creato quando l amministratore seleziona il bottone BottoneModificaGara. Crea il boundary ListaGare e una volta che l utente effettua la scelta crea il boundary FormModificaGara, successivamente colleziona l informazione del form, effettua la modifica della gara nell entity CatalogoGare e crea il boundary NotificaModificaAvvenuta. 18

19 BottoneModificaGara <<entity>> CatalogoGare ::Amministratore press() <<control>> ControlloModificaGara elencogare() selezionagara() ListaGare garaselezionata() <<destroy>> FormModificaGara inseriscidati() submit() submit() <<destroy>> aggiornacatalogo() NotificaConfermaModifica Analisi del caso d uso CancellaGara Entity - Amministratore: colui che può cancellare una gara - CatalogoGare: elenco delle gare d appalto Boundary - BottoneCancellaGare: bottone usato da Amministratore per iniziare lo use case CancellaGara - ListaGare: la lista delle gare che l Amministratore può cancellare. - NotificaICancellazioneAvvenuta: usato per confermare l avvenuta cancellazione della gara. Control 19

20 - ControlloCancellaGara: gestisce la funzione CancellaGara. Questo oggetto è creato quando l amministratore seleziona il bottone BottoneCancellaGara. Questo oggetto crea un boundary ListaGare, non appena riceve la richiesta di cancellazione cancella la gara e crea un NotificaCancellazioneAvvenuta. - BottoneCancellaGare <<entity>> CatalogoGare ::Amministratore press() <<control>> ControlloCancellaGara elencogare() ListaGare selezionagara() submit() submit() <<destroy>> aggiornacatalogo() NotificaConfermaCancellazione Analisi del caso d uso InserimentoUtente Entity - Amministratore: colui che può inserire un nuovo utente - InformazioniUtenti: elenco degli abbonati 20

21 Boundary - BottoneInserimentoUtente: bottone usato da Amministratore per iniziare lo use case InserimentoUtente - FormInserimentoUtente: form usato per l input quando viene selezionato InserisciUtente. Contiene campi per specificare l operazione di inserimento, i dati di un utente e un bottone per sottomettere il form completato - NotificaInserimentoAvvenuto: usato per informare l attore sull avvenuto inserimento dell utente. Control - ControlloInserisciUtente: gestisce la funzione InserimentoUtente. Questo oggetto è creato quando l amministratore seleziona il bottone BottoneInserimentoUtente. Crea un form InserisciUtente e lo presenta all amministratore. Dopo la sottomissione del form, questo oggetto colleziona l informazione del form, inserisce il nuovo utente. Poi crea un NotificaInserimentoAvvenuto. BottoneInserimentoUtente <<entity>> InformazioneUtenti ::Amministratore press() <<control>> ControlloInserisciUtente FormInserimentoUtente inseriscidati() submit() submit() <<destroy>> inserisciabbonato() NotificaConfermaInserimento 21

22 Analisi del caso d uso ModificaUtente Entity - Amministratore: colui che può inserire un nuovo utente - InformazioniUtenti: elenco degli abbonati Boundary - BottoneModificaUtenti: bottone usato da Amministratore per iniziare lo use case ModificaUtente - ListaUtenti: la lista degli utenti registrati da cui l Amministratore sceglierà quello da modificare. - FormModificaUtente: form usato per l input quando viene selezionato ModificaUtente. Contiene campi per specificare l operazione di modifica, i dati di un utente e un bottone per sottomettere il form completato. - NotificaModificaAvvenuta: usato per confermare all amministratore dell avvenuta modifica dell utente. Control - ControlloModificaUtente: gestisce la funzione ModificaUtente. Questo oggetto è creato quando l amministratore seleziona il bottone BottoneModificaUtente. Il control crea un boundary ListaUtenti e quando l Amministratore seleziona l utente viene creato un FormModificaUtente. Dopo la sottomissione del form, il control colleziona l informazione del form, modifica i dati dell utente e crea un NotificaModificaAvvenuta. 22

23 BottoneModificaUtente <<entity>> InformazioniUtenti ::Amministratore press() <<control>> ControlloModificaUtente elencoutenti() sceltagara() ListaUtenti utenteselezionato() <<destroy>> FormModificaUtente inseriscidati() submit() submit() <<destroy>> aggiornaabbonati() NotificaConfermaModifica Analisi del caso d uso CancellaUtente Entity - Amministratore: colui che può cancellare un utente - InformazioniUtenti, elenco degli abbonati Boundary - BottoneCancellaUtenti: bottone usato da Amministratore per iniziare lo use case CancellaUtente - ListaUtenti: la lista degli utenti registrati da cui l Amministratore sceglierà quello da cancellare. - NotificaConfermaCancellazione: usato per visualizzare le informazioni sulla cancellazione e un bottone (o altro controllo) per confermare la cancellazione e cancellare l utente. 23

24 Control - ControlloCancellaUtente: gestisce la funzione CancellaUtente. Questo oggetto è creato quando l Amministratore seleziona il bottone BottoneCancellaUtenti. Il control crea il boundary ListaUtenti e quando l Amministratore seleziona l utente da eliminare le modifiche verranno applicate usando l entity InformazioniUtenti e creato un boundary NotificaConfermaCancellazione. 3.4 Relazioni tra oggetti Relazioni tra oggetti relativi a Visitatore Visitatore effettua 1 1 Contatto Visitatore ricerca 1 1 ListaGare Visitatore ottiene 1 1 ListaGare Relazioni tra oggetti relativi ad Abbonato e Gara scarica Abbonato 1 * contiene Gare * CatalogoGare Relazioni tra oggetti relativi all Amministratore Amministratore Aggiorna 1 1 ListaGare 24

25 Amministratore Aggiorna 1 1 ListaUtenti 3.5 Diagrammi di stato Diagramma di stato per gara creata In corso Scaduta rimossa Diagramma di stato per abbonamento di tipo IS registrazione InCorso tempo terminato rinnovo eliminato Scaduto Diagramma di stato per abbonamento di tipo PS 25

26 registrazione Carico creditoesaurito ricaricato eliminato Esaurito 3.6 Identificazione degli attributi per Gara -Inserzionista -Categoria -Provincia -Importo -Scadenza -Descrizione Gara 3.7 Mock-up 26

27 4. Tempo richiesto per il completamento di questa documentazione Questa documentazione è stata redatta in circa una settimana e con un totale effettivo di ore lavorative in gruppo uguali circa a 28. Francesco Amelio 556/ Clemente Vitulano 556/ Edoardo Mari 556/ Barbara Cusati 087/ Fabio Discenza 556/ Valerio Donnarumma 556/ Biagio Cosenza 556/ Debora Galdi 557/ Jole Sabella 556/