Specifiche Tecniche di Sistema Titolo Documento · riguardanti prodotti o tecnologie utilizzati,...

STRUTTURA AZIENDALE

Specifiche Tecniche di Sistema Titolo Documento

Codice Documento Pag. 1/16

Controllo delle copie Il presente documento, se non preceduto dalla pagina di controllo identificata con il numero della copia, il destinatario, la data e la firma autografa del Responsabile della Documentazione, è da ritenersi copia informativa non controllata.

Il presente documento rappresenta una guida per la compilazione delle evidenze documentali di questa tipologia ed è così costituito: • gli elementi che si intende debbano essere parte fissa di tali evidenze sono scritti in

grassetto; • il testo blu corsivo o rosso corsivo è invece usato per fornire, rispettivamente, informazioni

e spiegazioni utili alla compilazione o esempi contestualizzati, e si intende che sia rimosso dopo l’uso;

• le parole racchiuse nei simboli < (minore) e (maggiore) >, inoltre, sono indicazioni di codici di campo che contengono le istruzioni utili al loro aggiornamento o alla loro sostituzione.

Il presente riquadro, infine, è puramente informativo e deve essere sempre rimosso ad ogni uso del template.

Specifiche Tecniche di Sistema Titolo Documento Codice Documento

STRUTTURA AZIENDALE



Sommario

1 Introduzione 3

1.1 Scopo e campo di applicazione 3

2 Riferimenti 4

2.1 Controllo del Documento: Stato delle revisioni 4

2.2 Documenti esterni 4

2.3 Documenti interni 4

2.4 Termini e Definizioni 4

3 Descrizione del sistema 4

3.1 Struttura del sistema 6

3.2 Operatività del sistema 7

3.3 Distribuzioni considerate 7

4 Descrizione delle interfacce per l’esterno 9

4.1 Interfaccia [XXX] 9

5 Descrizione dei sottosistemi 11

5.1 Sottosistema [KKK] 11

6 Descrizione dei dati 14

6.1 Modello entità-relazioni 14

6.2 Matrice di tracciabilità dei dati 15

7 Matrice di tracciabilità dei requisiti 15

8 Stima delle risorse necessarie (hardware e software) 16

9 Dizionario dei dati 16

STRUTTURA AZIENDALE



1 Introduzione L’introduzione dovrebbe fornire un’anteprima della tematica trattata dal documento di STS. Essa non dovrebbe riguardare la struttura del sistema software, ovvero le specifiche stesse, ma solo inquadrare il tema che tali specifiche riguardano, fornendone magari una minimale definizione. E’ anche possibile, in questa sezione, presentare una breve guida per il lettore spiegando la struttura del documento ed accennando il contenuto delle altre sezioni. Un esempio tipico dell’introduzione può essere il seguente: ‘Il presente documento si occupa di definire le specifiche tecniche del software utile alla realizzazione di un sistema di presentazione e pagamento online (a mezzo internet) delle pratiche auto. Il documento si può considerare strutturato in quattro parti principali:

o una prima parte discorsiva (capitolo 3) che prevede una panoramica riassuntiva e generale della struttura e dell’operatività del sistema software anche attraverso l’indicazione dei suoi principali sottosistemi, dei componenti e degli scenari di deployment supportati;

o una seconda parte (capitolo 4) che fornisce il quadro di dettaglio dell’interazione verso le interfacce esterne offerte dal sistema evidenziandone i contenuti e la ‘navigabilità’;

o una terza parte (capitolo 5) che elenca e specifica approfonditamente la struttura del sistema nei suoi sottosistemi costituenti avvalendosi dei vari tipi di diagrammi utili a rappresentarne tanto gli aspetti statici quanto quelli dinamici;

o una quarta parte (capitolo 6) che descrive il modello dei dati e la correlazione tra componenti software ed entità del data base.

A chiusura del documento vengono proposte una matrice per la correlazione tra i requisiti dichiarati nel propedeutico documento di SRI per il sistema software - oggetto delle presenti specifiche - e le parti costituenti del sistema software stesso, una stima indicativa delle risorse hardware e software necessarie alla costruzione ed alla messa in opera, ed un utile e necessario dizionario dei dati.’ <Click qui per inserire il testo>

1.1 Scopo e campo di applicazione In questa sezione è descritto lo scopo del documento delle Specifiche Tecniche relativamente al sistema software da costruire. Si deve descrivere il campo di applicazione del sistema software per il quale si stanno fornendo le specifiche, includendone gli obiettivi, le tecnologie, gli scenari di utilizzo ed i sistemi esterni con cui è previsto un interfacciamento. Si devono, inoltre, presentare qui tutti i prodotti software che le specifiche realizzano in quanto concorrono a comporre il sistema, identificandoli per nome, e chiarendo per ognuno di essi il ruolo o la funzionalità. Un inizio tipico di questa sezione può essere il seguente: ‘Lo scopo del presente documento è quello di fornire le specifiche tecniche di sistema per la costruzione del prodotto PraticheAutoWeb utile alla presentazione delle pratiche auto via internet con un web browser. Il sistema consente ad ogni cittadino di effettuare in maniera autonoma e senza intermediari la presentazione di formalità al PRA e di procedere al pagamento con carta di credito dell’importo dovuto utilizzando i canali e le tecnologie di maggiore diffusione e sicurezza per le transazioni in ambiente internet (SSL – secure socket layer). Il sistema consente inoltre al funzionario delibatore del PRA, tramite la rete interna ACI, ma sempre utilizzando un’interfaccia web-browser, di consultare e convalidare i dati delle pratiche auto acquisiti in modo automatico riscontrandoli, ove necessario, con la documentazione cartacea. A riscontro avvenuto in maniera positiva (convalida), il sistema produce i previsti documenti legali (certificato di proprietà – CDP – o certificato di radiazione – CDR -) e procede alla segnalazione all’utente, attraverso i canali supportati (email, sms o posta ordinaria), della loro disponibilità e fruibilità. E’ supportata nel sistema la possibilità di un interfacciamento anche attraverso i protocolli di trasmissione di informazioni in uso sulla rete GSM o sul Digitale Terrestre. Un canale d’accesso particolare, su protocollo proprietario, costruito comunque sul layer TCP/IP, è previsto per consentire il monitoraggio remoto e le procedure di fermo, manutenzione o aggiornamento del sistema da parte di personale tecnico ACI Informatica. Le comunicazioni con il circuito interbancario, necessarie alle operazioni di verifica e movimentazione sulle carte di credito, sono gestite attraverso moduli adattatori per gli operatori bancari selezionati…’ <Click qui per inserire il testo>

STRUTTURA AZIENDALE



2 Riferimenti

2.1 Controllo del Documento: Stato delle revisioni Vers. Descrizione delle modifiche apportate nella revisione alla versione precedente Cap.

modificati

1 Prima emissione N.A.

2.2 Documenti esterni In questa sezione occorre elencare tutti i documenti esterni usati come riferimento nella preparazione del documento di STS. Tipicamente questi documenti possono essere libri, whitepaper, blueprint, articoli tecnici o di supporto riguardanti prodotti o tecnologie utilizzati, norme emesse da enti riconosciuti, documenti vigenti dello stato, ecc. Ogni documento va identificato con: il titolo in stile grassetto corsivo racchiuso da apici singoli, gli autori, se noti, l’ente che ha emesso il documento, l’eventuale codice identificativo separati da virgole ed immessi tra parentesi ed in stile corsivo, la data di pubblicazione del documento prefissa dalla dicitura ‘del’ ed in stile normale. Nel caso di riferimenti a norme, il titolo del documento va prefisso con la dicitura in stile normale ‘NORMATIVA’. Un esempio di riferimento ad un documento esterno può essere: NORMATIVA ‘Norme per la sicurezza nella gestione dei dati nella pubblica amministrazione’ (autori vari, CNIPA, orientamento normativo) del 03/06/2005. <Click qui per inserire il testo>

2.3 Documenti interni In questa sezione occorre elencare tutti i riferimenti a documenti interni usati nella preparazione del documento di STS. Tipicamente questi riferimenti richiamano, oltre all’ovvio documento di specifiche dei requisiti del software (SRI), anche altri documenti quali quelli del sistema qualità, documenti aziendali a vario titolo, documenti progettuali, documenti di fornitori, documenti di metodologie, articoli tecnici o di supporto ai prodotti o alle tecnologie utilizzate, ecc. Ogni documento va identificato con: il titolo in stile grassetto corsivo racchiuso da apici singoli; il codice identificativo a seguire del titolo immesso tra parentesi ed in stile corsivo; la data dell’ultima revisione del documento all’atto del riferimento a seguire del codice identificativo prefissa dalla dicitura ‘revisione del’ ed in stile normale. Un esempio di riferimento ad un documento interno può essere: ‘Specifiche dei requisiti informatici per il prodotto PraticheAutoWeb’ (XX.YY.ZZ.01) revisione del 01/01/2005. <Click qui per inserire il testo>

2.4 Termini e Definizioni In questa sezione devono essere inseriti tutti i termini, gli acronimi e le abbreviazioni utili ad interpretare correttamente il contenuto del documento di STS. Tali termini possono comprendere vocaboli specialistici, sigle e quanto altro sia utilizzato all’interno del documento che potrebbe non essere correttamente compreso da un lettore non coinvolto nel progetto. Per ogni termine, acronimo o abbreviazione deve essere fornita una definizione o un riferimento documentale. Le definizioni facenti parte del Glossario definito nel Sistema Qualità aziendale possono non essere elencate purché si rimandi esplicitamente al documento riportando la seguente frase: “Per i termini, sigle e acronimi contenuti in questo documento si fa riferimento al Glossario dei termini utilizzati nel Sistema Qualità.”

3 Descrizione del sistema In questa sezione deve essere riportata una descrizione generale dell’architettura del sistema accennando alle sue componenti logiche principali ed al loro funzionamento. Devono essere inoltre descritti o richiamati brevemente i fattori generali, tra quelli ricavabili dal documento di SRI di riferimento, che hanno influenzato la progettazione del sistema: non occorre qui specificare i dettagli tecnici del sistema o delle sue componenti, ma piuttosto delinearne l’impostazione logica, fornendo la cornice entro la quale la comprensione delle specifiche che si forniscono più avanti può essere ragionevolmente semplificata. E’ anche consigliato, in questa sezione, ricorrere ad un disegno o diagramma (con UML package) che dia visione delle principali componenti logiche del sistema. Un esempio tipico di questa sezione può essere il seguente: ‘Il sistema PraticheAutoWeb, così come definito dalle specifiche di questo documento, si può considerare composto da tre sottosistemi logici fondamentali: il primo che si occupa di ricevere e gestire le richieste utente relative al disbrigo delle pratiche auto e che coincide più o meno con l’applicazione web fruibile tramite internet, o tramite gli altri canali supportati, dal cittadino comune (detta PraticheAutoUtenti), il secondo che procede a processare le richieste immagazzinate e produrre per esse gli esiti ed i documenti in base ai controlli ed all’operatività prevista e che coincide più o meno con l’insieme dei servizi di backoffice (detta PraticheAutoBackOffice), ed il terzo che consente al personale delibatore del PRA di visualizzare e convalidare, attraverso la intranet aziendale, i risultati della elaborazione automatica a seguito dei necessari riscontri manuali (detta PraticheAutoConvalide). L’operatività base del sistema può essere così riassunta: l’utente si collega al sottosistema PraticheAutoUtenti ed ottiene l’accesso utile a poter inserire pratiche auto, avviarle alla lavorazione, consultarne lo stato corrente e stamparne i documenti una volta che questi siano resi disponibili; il sottosistema PraticheAutoBackOffice esegue

STRUTTURA AZIENDALE



l’elaborazione automatica delle pratiche avviate alla lavorazione dagli utenti e definisce per queste un esito positivo (pratica accettata) o negativo (pratica respinta); il funzionario delibatore del PRA accede al sottosistema PraticheAutoConvalide ed opera la conferma (convalida) o la non conferma (non convalida), in base al riscontro sulla documentazione cartacea disponibile, dell’esito delle pratiche già elaborate automaticamente; il sottosistema PraticheAutoBackOffice esegue la produzione delle notifiche previste per indicare il termine della lavorazione delle pratiche e la disponibilità di eventuali documenti prodotti. Come si può notare facilmente, l’esecuzione del processo di lavorazione delle pratiche auto eseguita nel sottosistema logico di backoffice è resa asincrona rispetto al momento della effettiva raccolta della richiesta utente eseguita dal sottosistema web-internet. Questo comportamento ha le sue ragioni nel rispetto di una serie di fattori che emergono chiaramente dal documento di SRI. Tali fattori comprendono (ma non sono a questi affatto limitati) il rispetto del requisito prestazionale di poter scalare efficacemente la risposta del sistema al variare del carico di lavoro ed il rispetto del vincolo funzionale di dover rendere indipendenti dai tempi di lavorazione automatica (ivi compresi sovraccarichi, malfunzionamenti, ecc…) tutti gli atti di presentazione eseguiti in maniera formalmente corretta. Per presentazione formalmente corretta si intende la presentazione della richiesta di una pratica auto che passi i primi elementari controlli di validazione e correttezza dei dati inseriti e produca la prevista movimentazione di cassa attraverso l’uso di una carta di credito o altro mezzo di pagamento tra quelli supportati. Per quel che riguarda il sottosistema web-intranet di convalida delle pratiche auto da parte del funzionario delibatore del PRA, le operazioni qui possibili sono similmente condotte in maniera asincrona (rispetto almeno al termine del processo di lavorazione automatica), ma questo comportamento trova ragione nell’ovvia e necessaria dipendenza della procedura da un intervento umano. A valle della conclusione del processo di convalida per ogni singola pratica auto, il sottosistema web-intranet incarica il backoffice di notificare all’utente (tramite email, sms o stampa di posta ordinaria), l’avvenuta definizione di uno stato conclusivo e la fruibilità di un eventuale certificato (di proprietà, CDP, o di radiazione, CDR) scaricabile come PDF (portable document format) direttamente dall’utente attraverso il sottosistema web-internet. A maggior chiarezza, segue un diagramma dei sottosistemi contenuti nel sistema PraticheAutoWeb:

’ <Click qui per inserire il testo>

STRUTTURA AZIENDALE



3.1 Struttura del sistema In questa sezione deve essere chiarita la prospettiva generale del sistema software dal punto di vista della sua architettura d’insieme (applicazione desktop, client-server, web-based, a due livelli, a n-livelli, distribuita, ecc.), elencando tanto le componenti, sia interne che esterne (Commercial Off-The Shelf - COTS -), quanto i middleware, le tecnologie ed eventualmente i linguaggi di programmazione di cui è previsto o considerato l’utilizzo per la sua realizzazione. E’ opportuno inserire in questa sezione un diagramma delle componenti (Component Diagram) d’alto livello per chiarire meglio gli aspetti tecnico-logici generali dell’architettura che verranno poi espansi nelle successive sotto-sezioni. Un esempio tipico di questa sezione può essere il seguente: ‘Il sistema PraticheAutoWeb è una applicazione web based con due interfacce d’accesso per web browser poste l’una su rete internet pubblica aperta al cittadino comune e l’altra su rete intranet ACI aperta ai soli funzionari delibatori. La struttura del sistema è quella di una applicazione a più livelli, con una netta separazione delle componenti di presentazione, (business) logic, infrastrutture e dati. Il livello di presentazione del sistema è affidato all’uso di pagine web dinamiche (tipicamente in tecnologia jsp) inquadrate in un modello MVC preferibilmente poggiato sull’implementazione standard di Jakarta Struts e sui web server ad essa compatibili (apache, tomcat, websphere, ecc..). Opzionalmente è anche possibile, per la parte del livello di presentazione, relativamente a quanto attiene all’interfaccia pubblica, l’uso di canali alternativi quali Digitale Terrestre e SMS. E’ inoltre prevista, sempre per quel che riguarda l’interfaccia pubblica, la gestione dei profili utente (profilatura) e delle autorizzazioni (controllo degli accessi). Il livello di business logic (inserimento, consultazione, elaborazione e convalida delle pratiche auto) e infrastrutture (persistenza, controllo d’accesso) è garantito da una serie di componenti remotizzabili (tipicamente EJB) accessibili con tecnologia CORBA o attraverso sistemi asincroni di invio/ricezione di messaggi (come IBM MQSeries). Il livello dei dati è strutturato su una astrazione dal sottostrato relazionale (RDBMS Oracle) fondata in alcuni casi sull’uso di StoredProcedure ed in altri sull’uso di sistemi ORM esterni (Entity Bean o prodotti come Hybernate), tuttavia sempre basata su una tecnologia comune (tipicamente JDBC). Il linguaggio di programmazione preso a riferimento per lo sviluppo del sistema è in grado di supportare OOP ed i sistemi middleware dalle caratteristiche citate (java in tecnologia J2EE), mentre per gli ambienti di runtime si sono assunte come disponibili le caratteristiche proprie degli application server commercialmente più diffusi (supporto a J2EE con EJB 2.0, come IBM WebSphere v.5.1). Un component diagram d’alto livello che illustra l’architettura tecnico-logica del sistema può essere osservato di seguito:


STRUTTURA AZIENDALE



3.2 Operatività del sistema In questa sezione devono essere dettagliate, mediante gli opportuni diagrammi di sequenza (sequence diagram), tutte le basilari modalità d’interazione col sistema utili a descriverne efficacemente l’operatività. E’ bene evidenziare qui il ruolo di ognuna delle macro-componenti del sistema così da offrire una prospettiva il più possibile chiara della sua logica complessiva. Un inizio tipico di questa sezione può essere il seguente: ‘Di seguito vengono presentate le basilari modalità di interazione col sistema PraticheAutoWeb utili a fornire una visione d’alto livello della sua operatività. Ogni singola modalità è trattata come una macro-sequenza ed è resa in maniera diagrammatica attraverso gli idonei diagrammi di sequenza. Poiché l’interazione col sistema PraticheAutoWeb avviene attraverso due soli agenti specifici, ovvero il privato cittadino ed il funzionario del PRA, sussistono in tutto le sole seguenti macro-sequenze:

• Operatività dell’agente ‘privato cittadino’ verso il sistema (macro componenti): • Operatività dell’agente ‘funzionario delibatore’ verso il sistema (macro componenti):

……… ‘

<Click qui per inserire il testo>

3.3 Distribuzioni considerate In questa sezione devono essere introdotte le distribuzioni supportate dal sistema limitatamente alle sue macro-componenti. Questa descrizione non impone il deployment fisico che si applicherà al sistema una volta prodotto, non risolve problemi di configurazione propri di successivi momenti (sono cioè estranee a questa sezione i concetti di load balancing, clustering, ecc…), né tantomeno propone assetti tipicamente variabili da un ambiente logico all’altro (sviluppo, test, test prestazionale, esercizio, ecc...). Questa descrizione serve solo a chiarire gli aspetti relativi a quali siano i componenti del sistema progettati per poter essere distribuiti insieme e quali no, e altri aspetti ‘tecnici’ similari, in modo da fornire un utile riferimento per indirizzare il sottoinsieme possibile delle future distribuzioni. Inoltre questa descrizione consente di porre nei giusti tempi il tema della strutturazione fisica del sistema, favorendo l’approccio, se non la soluzione, dei problemi pratici di configurazione che altrimenti dovrebbero essere affrontati e risolti all’ultimo minuto. In questa sezione è utile far ricorso ad uno o più diagrammi di deployment (deployment

STRUTTURA AZIENDALE



diagram) per meglio specificare le possibilità di distribuzione. Un inizio tipico del contenuto di questa sezione può essere il seguente: ‘La struttura del sistema PraticheAutoWeb è quella di una applicazione web-based multilivello (n-tier) con una netta separazione delle logiche proprie della presentazione (User Interface), logica di business, infrastruttura e dati. Ovviamente, ai livelli logici dell’applicazione possono corrispondere diverse ripartizioni fisiche delle varie componenti del sistema. Tuttavia non tutte le componenti del sistema sono state progettate per essere separate fisicamente. Ciò vuol dire che, accanto alle componenti in grado di comunicare tra loro anche cross-network (previa corretta configurazione dei sistemi ospiti), ve ne sono alcune utilizzabili solo in scenari particolari e più limitati (come quello in-process) ed altre che hanno comunque necessità di trovarsi almeno sul medesimo server. Per questo motivo, di seguito, vengono elencati una serie di possibili distribuzioni considerate come applicabili al sistema PraticheAutoWeb e viene fornito per ognuna di esse un digramma di deployment con le relative spiegazioni.

• Scenario di deploy con doppio Web, un Application Server, un BackOffice server e un RDBMS

In questo scenario, le componenti di presentazione sono state mantenute isolate da quelle che realizzano la logica di business. Inoltre, è stato isolato il sottosistema di lavorazione automatica. Le componenti di infrastruttura (persistenza e sicurezza) sono state replicate ovunque necessario. Si è posta evidenza sul fatto che il componente preposto alla lavorazione automatica delle pratiche auto ha comunque bisogno di accedere localmente ad alcuni aspetti del componente di logica generale relativa alle pratica auto, per cui nel distribuire il primo su un backoffice separato si è dovuto distribuire con esso anche una copia del secondo. Si è inoltre messo in risalto come le componenti di infrastruttura non siano mai accessibili con chiamate remote (cross-network).

• Scenario di deploy con singolo Web, un ApplicationServer e un RDBMS ……… ‘


STRUTTURA AZIENDALE



4 Descrizione delle interfacce per l’esterno In questa sezione deve essere fornita una breve introduzione alla successiva organizzazione del dettaglio delle singole interfacce per l’esterno del sistema, ovvero dei punti di ingresso al sistema utilizzabili da un qualsiasi agente interno o esterno (come le UI). Il contenuto tipico di questa sezione può essere il seguente: ‘Di seguito viene presentata la descrizione di dettaglio delle interfacce per l’esterno previste dal sistema PraticheAutoWeb relativamente al loro uso ed al loro funzionamento. ’ <Click qui per inserire il testo>

4.1 Interfaccia [XXX] In ognuna di queste sezioni occorre descrivere il dettaglio di una interfaccia per l’esterno prevista dal sistema. Per ogni interfaccia va espressamente specificato l’uso reale, in termini di input ed output concreti, che è previsto se ne faccia per ogni tipologia di agente (o utente). Occorre dunque descrivere in ognuna di queste sezioni sia la visione concettuale dei possibili modi di utilizzo del sistema attraverso l’interfaccia, sia i passi reali e specifici che l’agente compie per ogni singolo utilizzo. Nel proporre questa descrizione si può far ricorso agli opportuni diagrammi dei casi d’uso (use case diagram) visti nella loro accezione di casi d’uso reali, corredati cioè di tutti i dettagli utili a chiarire la progettazione e l’implementazione di massima del funzionamento delle singole interfacce. In questo senso è possibile affiancare ai singoli diagrammi di casi d’uso gli opportuni diagrammi di stato (UML state diagram) o, nel caso specifico di interfacce web, di ipertesto (WebML hypertext diagram). E’ anche possibile includere rappresentazioni non formali del funzionamento delle singole interfacce attraverso storyboard apposite. Un inizio tipico del contenuto di una queste sezione può essere il seguente: ‘4.1 Interfaccia PraticheAutoUtenti (accesso JSP) Questa interfaccia si occupa di garantire l’uso previsto del sistema PraticheAutoWeb per gli utenti privati cittadini che possono fruire di una connessione ad internet e di un web browser. L’interfaccia è realizzata con pagine web dinamiche ed è accessibile nelle sue funzioni principali previa login o registrazione (libera). L’utente che accede a questa interfaccia ha la possibilità di gestire le proprie pratiche presenti sul sistema, ovvero di inserirle, modificarle, avviarle alla lavorazione o stamparne i documenti. Di seguito viene fornito un diagramma dei casi d’uso ed il relativo dettaglio reale, espresso con l’ovvia descrizione di ogni caso d’uso e con il ricorso (ove ritenuto opportuno) ai necessari diagrammi di stato, utili a chiarire la progettazione dell’interfaccia:

Descrizione dei singoli casi d’uso reali:

STRUTTURA AZIENDALE



• Caso d’uso ‘registra al sistema’:

Nome Registra al sistema Attori coinvolti Privato Cittadino (non registrato) Scopo Effettuare la registrazione al sistema di un utente privato cittadino in

modo da garantirne l’accesso. Casi d’uso inclusi Nessuno Casi d’uso estesi Effettua Login Condizione d’ingresso L’utente indica di volersi registrare per poter accedere al sistema. Corso degli eventi - L’utente inserisce il proprio nome, il cognome, l’indirizzo email, il

numero di telefono, il codice fiscale, una login, una password e conferma la password. - L’utente decide se consentire al trattamento dei dati personali o rifiutarlo. - Se la login o l’indirizzo email già esistono nel sistema oppure se la login, la password (la conferma della password) o l’email non sono valide, viene stampato un messaggio; altrimenti viene creato un nuovo account. - Viene garantito l’accesso al sistema (login valida)

Condizione d’uscita L’utente annulla l’azione oppure entra nel sistema avendo creato un account.

Requisiti particolari Nessuno • Caso d’uso ‘effettua login’:

Nome Effettua login Attori coinvolti Privato Cittadino (registrato) Scopo Effettuare l’acceso al sistema Casi d’uso inclusi Consulta situazione pratche Casi d’uso estesi Nessuno Condizione d’ingresso L’utente indica di voler effettuare l’accesso al sistema. Corso degli eventi - L’utente inserisce il proprio login e la propria password.

- Se la coppia login e password non individua un utente nel sistema viene stampato un messaggio che invita a riprovare ed aggiorna un conteggio dei tentativi: al terzo tentativo l’accesso viene bloccato. Se la coppia login e password individua un utente del sistema l’accesso viene consentito. - Viene mostrata una lista paginata delle pratiche proprie dell’utente.

Condizione d’uscita L’utente annulla l’azione oppure entra nel sistema avendo effettuata la login.

Requisiti particolari Nessuno A riferimento del presente caso d’uso si può considerare il seguente diagramma di stato:

STRUTTURA AZIENDALE



• …….…‘


5 Descrizione dei sottosistemi In questa sezione deve essere fornita una breve introduzione alla successiva organizzazione del dettaglio dei singoli sottosistemi costituenti il sistema software. Il contenuto tipico di questa sezione può essere il seguente: ‘Di seguito viene presentata la descrizione di dettaglio dei sottosistemi costituenti il sistema PraticheAutoWeb relativamente alla loro struttura ed al loro funzionamento. ’ <Click qui per inserire il testo>

5.1 Sottosistema [KKK] In ognuna di queste sezioni occorre descrivere il dettaglio di un sottosistema costituente il sistema software. Per ogni sottosistema va espressamente descritto da quali macro-componenti fisiche sia composto e quindi, per ogni macro-componente, da quali classi. E’ necessario servirsi, nell’operare questa descrizione, degli idonei diagrammi delle classi (class diagram), restando inteso che è anche possibile, ove ritenuto utile, presentare più diagrammi di classi (in luogo di uno solo), inerente ciascuno ad una porzione specifica del sottosistema. Man mano che si chiarisce la struttura statica del sottosistema, occorre procedere a chiarire anche tutti gli aspetti dinamici di un qualche rilievo, ovvero la collaborazione e l’interazione interna che portano alla realizzazione di specifiche funzionalità del sottosistema. A questo scopo è opportuno servirsi degli appositi diagrammi di collaborazione o sequenza (collaboration o sequence diagram) e far riferimento per ognuno di essi al caso d’uso che realizzano o che contribuiscono a realizzare. E’ anche possibile includere rappresentazioni più dettagliate delle logiche di funzionamento di alcune parti del sottosistema facendo ricorso, ove ritenuto opportuno, ai diagrammi di attività (activity diagram). Un inizio tipico del contenuto di una queste sezioni può essere il seguente: ‘5.1 Sottosistema PraticheAutoUtenti Questo sottosistema è costituito dall’unica macro-componente detta ‘interfaccia al pubblico’ al cui interno, tuttavia, è possibile distinguere almeno quattro parti costituenti: il front-end basato sul web, il front-end basato sul digitale terrestre, il front-end basato su SMS e la logica di presentazione comune. Di queste quattro parti costituenti, le prime tre rappresentano semplicemente modi diversi di rendere la vera e propria interfaccia utente nei vari canali supportati dal sistema (web, digitale terrestre e gsm), mentre la quarta rappresenta la logica di lavoro effettivamente comune a tutte. E’ chiaro come il sottosistema PraticheAutoUtenti, nel dover gestire una logica di lavoro (navigabilità, sicurezza, ecc…) comune a tre canali utente così diversi, deve poter mantenere una netta separazione tra quanto relativo alla rappresentazione del contenuto utente e quanto relativo alla sua produzione. In questa direzione, il sottosistema PraticheAutoUtenti è progettato su una solida struttura MVC (Model – View – Controller) che, nello specifico, si intende poggiata sull’implementazione classica di jakarta struts. Di seguito, viene proposta una serie di diagrammi relativi alle porzioni appena accennate del sottosistema PraticheAutoUtenti: tali diagrammi rappresentano spaccati della struttura statica e dinamica del

STRUTTURA AZIENDALE



sottosistema e delle sue parti, e nel loro insieme ne forniscono la vista ordinata e completa. Per maggior facilità e chiarezza di comprensione, ad alcuni diagrammi sono associate delle piccole descrizioni o delle spiegazioni aggiuntive. Ecco lo schema di suddivisione dei diagrammi:

• Sottosistema PraticheAutoUtenti – Accesso Web – login e registrazione • Sottosistema PraticheAutoUtenti – Accesso Web – operazioni pratica • Sottosistema PraticheAutoUtenti – Accesso Digitale Terrestre – login e registrazione • Sottosistema PraticheAutoUtenti – Accesso Digitale Terrestre – operazioni pratica • Sottosistema PraticheAutoUtenti – Accesso SMS – login e registrazione • Sottosistema PraticheAutoUtenti – Accesso SMS – operazioni pratica

Ed eccone il dettaglio: • Sottosistema PraticheAutoUtenti – Accesso Web – login e registrazione

o Diagramma per le classi utili alla procedura di login e registrazione:

Il diagramma rappresenta sotto forma di classi con stereotipi noti (pagina jsp, pagina web, form, servlet) anche gli elementi propri dell’interfaccia web ed i loro collegamenti. Il framework jakarta struts non è, ovviamente, rappresentato nella sua interezza.

• Diagramma per sequenza d’uso delle classi utili alla procedura di login (UCD002 - ‘effettua login’):

STRUTTURA AZIENDALE



• Diagramma per sequenza d’uso delle classi utili alla procedura di registrazione (UCD001 - ‘registra al sistema’):

…….

o Sottosistema PraticheAutoUtenti – Accesso Web – operazioni pratica • Diagramma delle classi

……… ……… ………

‘ <Click qui per inserire il testo>

STRUTTURA AZIENDALE



6 Descrizione dei dati

6.1 Modello entità-relazioni In questa sezione deve essere presentato il modello dei dati del sistema. E’ opportuno inserire in questa sezione la vista delle entità e delle relazioni facendo uso degli idonei diagrammi ER (entity relationship). I diagrammi ER devono essere espressi al livello di dettaglio utile a descrivere i dati principali, rimandando la definizione esatta e completa ad altra e successiva sezione (dizionario dei dati). Un inizio tipico del contenuto di questa sezione può essere il seguente: ‘Di seguito viene presentato il modello dei dati del sistema PraticheAutoWeb. Il modello riguarda le sole entità oggetto del business principale del sistema, ovvero le entità correlate alla gestione delle pratiche auto. Questo vuol dire che sono escluse dal presente modello tutte quelle entità di cui si faccia eventualmente uso attraverso componenti di terze parti o che siano di pertinenza propria delle infrastrutture utilizzate (come ad esempio la base dati per gli utenti che è propria dell’infrastruttura di sicurezza e gestione profili). Il modello, riportato nell’apposito diagramma ER (entity relationship), è espresso nella notazione introdotta da G. Everest (notazione tipica di erwin):


STRUTTURA AZIENDALE



6.2 Matrice di tracciabilità dei dati Occorre inoltre, a seguito della presentazione del diagramma (o dei diagrammi) ER, fornire una matrice di correlazione tra dati e componenti del sistema. Tale matrice non deve limitarsi ad inquadrare solo le componenti che fanno un uso diretto delle entità (cosa che ne limiterebbe l’utilità alla sola documentazione del livello dati), ma piuttosto deve riguardare tutte le parti del sistema che, a vario titolo, fanno uso dei dati ricavati da tali entità. Per ogni entità è necessario chiarire il tipo di accesso che il singolo componente del sistema applica nei suoi confronti (INSERT, SELECT, UPDATE o DELETE). E’ ovviamente possibile scegliere il livello di dettaglio al quale si vuole esprimere la correlazione (entità rispetto ai sottosistemi, alle componenti, alle classi), anche se è consigliato scendere ad un livello di dettaglio non troppo distante da quello della singola classe. Un inizio tipico del contenuto di questa sezione può essere il seguente: Facendo riferimento alle entità definite nel presente modello, si può tracciare una matrice delle correlazioni tra le componenti software del sistema ed i dati, evidenziando anche la tipologia di accesso (INSERT, SELECT, UPDATE o DELETE). Tale matrice è riportata di seguito. Nel tracciare tali correlazioni si è voluto, per efficacia di rappresentazione, prendere a riferimento i singoli sottosistemi, elencando solo nei punti di correlazione l’intero insieme delle classi coinvolte (da notare che elementi come le pagine jsp sono stati considerati alla stregua delle classi).

PraticheAutoWeb Sottosistemi

Entità PraticheAutoUtenti PraticheAutoConvalide PraticheAutoBackOffice …… ……

PraticaAuto

X INSERT, SELECT, UPDATE, DELETE

[consultazione.jsp, inserimento.jsp, modifica.jsp,

ConsultaPraticaAction, InserisciPraticaAction, ModificaPraticaAction

PraticaBean]

X SELECT, UPDATE

[elenca.jsp, convalida.jsp,

ConvalidaPraticaBean]

X SELECT, UPDATE

[PraticaFacade, Pratica]

…… ……

PraticheAutoDaLavorare

X INSERT, SELECT

[avviaLavorazione,jsp, AvviaLavorazioneAction

]

X SELECT, UPDATE

[PraticaDaLavorareBean, PraticaDaLavorare]

…… ……

Documenti …… …… …… …… ……

……… …… …… …… …… ……

……… …… …… …… …… ……


7 Matrice di tracciabilità dei requisiti In questa sezione deve essere riportata la matrice di tracciabilità dei requisiti. Poiché tutti i moduli (sottosistemi, componenti, classi) del sistema software devono essere stati pensati per assolvere ad uno o più requisiti dell'applicazione (contenuti nel relativo documento di specifiche dei requisiti), è possibile, in questa sezione, costruire una matrice tra requisiti e moduli software che consenta da un lato di verificare che tutti i requisiti siano stati presi in considerazione, e dall’altro che non esistano moduli software che non coprono alcun requisito (over-design). E’ ovviamente possibile scegliere il livello di dettaglio al quale si vuole eseguire la tracciabilità (requisiti rispetto ai sottosistemi, alle componenti, alle classi), anche se è consigliato scendere ad un livello di dettaglio non troppo distante da quello della singola componente. Un inizio tipico del contenuto di questa sezione può essere il seguente: ‘Di seguito viene presentata la matrice di tracciabilità dei requisiti del sistema rispetto ai suoi moduli. La tracciatura è eseguita, per maggiore efficacia di rappresentazione, prendendo a riferimento i singoli sottosistemi, ed elencando eventualmente solo nei punti di correlazione le classi più significativamente coinvolte. Per il significato completo dei codici relativi ai singoli requisiti, si fa riferimento al propedeutico documento di specifiche dei requisiti per il sistema PraticheAutoWeb.

PraticheAutoWeb Sottosistemi

STRUTTURA AZIENDALE



Requisiti PraticheAutoUtenti PraticheAutoConvalide PraticheAutoBackOffice ……

RF001 (accesso al sistema) X

[login.jsp, LoginAction, LoginBean]

…… …… ……

RF002 (registrazione utenti)

X [register.jsp, RegisterAction, RegisterBean]

…… …… ……

RF003 (….) …… …… …… ……

……… …… …… …… ……

……… …… …… …… ……


8 Stima delle risorse necessarie (hardware e software) In questa sezione occorre prevedere, per quanto possibile, una stima delle risorse minime, sia hardware, come caratteristiche dei sistemi, che software, come caratteristiche dei middleware e dei servizi, necessarie al corretto funzionamento del sistema (nel rispetto anche dei requisiti non funzionali posti nel propedeutico documento di SRI). L’elencazione di tali risorse può essere effettuata in maniera discorsiva servendosi anche, ove fosse ritenuto utile, di liste o di elenchi puntati o numerati. Un inizio tipico del contenuto di questa sezione può essere il seguente: ‘Il sistema PraticheAutoWeb pone tra i requisiti non funzionali necessari per il suo corretto funzionamento la possibilità di gestire un volume di traffico di picco pari a 2000 utenti contemporaneamente attivi sulla sua interfaccia tipica (quella web) e 60000 utenti totali per singola giornata lavorativa (nell’arco di 12 ore) senza che la sua operatività soffra di blocchi anomali o di eccessivi rallentamenti (le risposte devono essere comunque nel limite di 5 sec dalla richiesta). Il rispetto di questo vincolo impone alcune importanti considerazioni sulle risorse hardware e software che il sistema dovrà avere a disposizione. Prima di tutto occorre tenere presente che l’impatto di 2000 utenti che contemporaneamente eseguono operazioni sul sistema può facilmente tradursi, considerando il tempo di risposta tipico per ogni operazione contenuto attorno ad 1 secondo, nella gestione reale di circa 400 utenti attivi contemporanei: l’accodamento dei restanti utenti consentirebbe, infatti, di rimanere comunque nel limite dei 5 sec a risposta. Questo significa che il front-end web deve poter gestire, appunto, fino a 400 richieste contemporanee, ovvero 400 thread d’esecuzione. Poiché per ogni processore non è raccomandabile eseguire più di 20 thread di un web-server, se si assume di avere a disposizione macchine quadriprocessore, ne occorrerebbero almeno cinque, poste in load balancing, per gestire efficacemente il traffico indicato. Detto questo, c’è da osservare che mantenere i tempi di risposta minimi di ogni singola richiesta attorno ad 1 sec significa fare in modo che le richieste più gravose per il sistema siano risolte tutte in maniera asincrona rispetto al chiamante, introducendo, ad esempio, come previsto dalla progettazione, gli adeguati sistemi di supporto al messaging. E’ importante, in quanto richiesto dal linguaggio e dalla tecnologia di riferimento (j2ee), che tali sistemi offrano una interfaccia JMS (IBM MQSeries è un buon candidato). Inoltre, poiché il volume target di 60000 richieste al giorno significa almeno altrettanti inserimenti di pratiche sul sistema, considerando che una singola pratica occupa spazio sulla base dati per circa 4 kb, bisogna valutare la disponibilità di spazio su disco per il DBMS pari ad almeno……’ <Click qui per inserire il testo>

9 Dizionario dei dati In questa sezione occorre riportare il dettaglio dei dati trattati dal sistema, così come precedentemente descritti, specificando per essi la descrizione (nome, descrizione), le caratteristiche fisiche (tipo, dimensione), il dominio (range dei possibili valori e valore iniziale) e le relazioni. La descrizione deve essere condotta in maniera ordinata, ovvero entità per entità, dettagliandone come indicato i relativi attributi. Un inizio tipico del contenuto di questa sezione può essere il seguente: ‘Di seguito vengono dettagliati i dati in uso al sistema PraticheAutoWeb, così come precedentemente descritti, riportandone, entità per entità, il nome, la descrizione, il tipo, il range dei possibili valori, il valore iniziale e le eventuali relazioni con altri dati…’ <Click qui per inserire il testo>

Specifiche Tecniche di Sistema Titolo Documento · riguardanti prodotti o tecnologie utilizzati,...

Documents

Transcript of Specifiche Tecniche di Sistema Titolo Documento · riguardanti prodotti o tecnologie utilizzati,...