libro

Universit degli studi di Catania

Facolt di Scienze Matematiche, Fisiche e Naturali Corso di laurea in Informatica applicata

Relazione ingegneria del software

prof. Giuseppe Scollo

UUULLLMMMSSS UUUNNNiiiVVVEEERRRSSSiiiTTTYYY LLLiiiBBBRRRAAARRRYYY MMMAAANNNAAAGGGEEEMMMEEENNNTTT SSSYYYSSSTTTEEEMMM

di Canzonieri Matteo, Giummarra Andrea, Roberto Fabiano matr. A40/000030, A40/000061, A40/000081

A.A. 2007/2008

Relazione Ingegneria del Software

ULMS University Library Management System

- 2 -



- 3 -

Sommario

1. Introduzione 5

2. Progettazione e piano operativo 6

2.1 Analisi dei requisiti 6

2.2 Progettazione 6

2.2.1 Sviluppo 6

2.3 Collaudo 7

2.4 Manutenzione 7

3. Principi di accessibilit di siti web 8

4. Principi per la qualit di un sito web culturale 11

5. Specifiche di qualit dei siti web pubblici culturali 12

6. Usabilit per la comunicazione pubblica 13

6.1 La definizione ISO 13

6.2 I tre settori dellusabilit 13

6.2.1 Larchitettura informativa 14

6.2.2 La progettazione dellinterfaccia grafica 14

6.2.3 Lanalisi dei flussi interattivi 14

6.3 Principi del buon design 15

7. Pianificazione di risorse per la produzione software 16

7.1 Studio di fattibilit 16

7.1.1 Obiettivi del prodotto 17

7.1.2 Strategie e politiche di UMLS: ciclo di vita del processo 18

7.1.3 Identificazione e allocazione delle risorse 19

7.1.4 Stima di massima di tempi e mesi-uomo 20

7.1.1 Stima di massima dei costi 22

7.2 Piano operativo 23

7.2.1 Scheduling delle attivit 23

7.2.2 Diagramma PERT 25

8. Evoluzione del software 26

8.1 Stima e valutazione dei rischi di ULMS 26

9. Analisi, modellazione e specifica dei requisiti 27

9.1 Sistema corrente 27

9.2 Requisiti funzionali 27

9.3 Requisiti non funzionali 28

9.3.1 Interfaccia utente e fattore umano 28

9.3.2 Documentazione 28

9.3.3 Considerazioni Hardware 28



- 4 -

9.3.4 Prestazioni Hardware 29

9.3.5 Interfaccia del sistema 29

10. Analisi dei requisiti funzionali 30

10.1 Diagramma di contesto del sistema 30

10.2 Diagramma delle funzionalit offerte dal sistema 31

10.3 Diagramma della funzionalit di impiegato 34

11. Architettura software 38

11.1 Tipi e caratteristiche degli stili di architetture software 38

11.1.1 Architettura dataflow 38

11.1.2 Architettura ad astrazione di dati (od orientata agli oggetti) 39

11.1.3 Architettura event-driven (oppure ad invocazione implicita) 40

11.1.4 Architettura stratificata 41

11.1.5 Architettura basata su repository 43

11.1.6 Architettura basata su interprete 44

12. Accenni al collaudo software 45

13. Modello di stima dei costi e tempo di produzione del software 46

13.1 Modello base 46

13.2 Modello intermedio 47

13.3 Metodo dei punti funzione (Albrecht) 47

14. Progettazione dellArchitettura del software 49

14.1 Diagramma delle classi 49

14.2 Diagrammi di sequenza 53

14.3 Diagrammi degli stati 55

14.4 Diagrammi delle attivit 56

15. Conclusioni 57

16. Bibliografia 58



- 5 -

1. Introduzione (Canzonieri Matteo, Giummarra Andrea, Roberto Fabiano)

LIngegneria del Software una branca dellingegneria che ha come oggetto di studio lo

sviluppo delle migliori metodologie da utilizzare come metodo di sviluppo di sistemi

software di ogni genere, a partire da un semplice sito web fino ad arrivare agli applicativi

pi complessi.

ULMS si propone di supportare la gestione di una libreria universitaria al fine di

migliorarne lefficienza in tutte le sue attivit cio nella:

Vendita dei libri

Gestione del magazzino

Acquisizione dei libri

Le tre figure fondamentali per la sua gestione sono:

Addetto alle vendite (commesso) che consulta le disponibilit in magazzino,

registra le vendite ed effettua le prenotazioni dei libri in funzione delle esigenze dei

clienti

Addetto al magazzino (magazziniere) il quale deve poter registrare le consegne dei

libri specificandone lordine

Addetto agli ordini (gestore ordini) che si occupa di generare ed inoltrare gli ordini

in funzione del periodo e delle previsioni di vendita e di gestire il database dei libri

inserendo alloccorrenza nuovi testi e rimuovendo quelli non pi prodotti. Inoltre si

occupa di associare ai libri i corsi universitari che li adottano in modo da avere

sempre una visione di quando pi utile incrementare la scorta di magazzino.



- 6 -

2. Progettazione e piano operativo (Roberto Fabiano)

Lo sviluppo di ogni applicativo o sistema web-based passa da quattro fasi fondamentali

definite dallingegneria del software:

Analisi dei requisiti

Progettazione

o Sviluppo

Collaudo

Manutenzione

A volte si parla pi comunemente di ciclo di vita del software.

2.1 Analisi dei requisiti

In una prima fase opportuno domandarsi cosa lutente cerca dal nostro software, quali

risultati voglia ottenere e come verr impiegato una volta che il software sar completato.

Al termine di questa prima fase, si andr a produrre una documentazione dettagliata sulle

specifiche dei dati ed un manuale duso. Andando a produrre questa documentazione si

eviter il problema di dimenticare dettagli importanti utili alle fasi successive.

2.2 Progettazione

In questa seconda fase si vuole cercare un mezzo per poter soddisfare a pieno tutte le

specifiche derivanti allanalisi dei requisiti. Durante tale fase si andranno a ricercare gli

elementi generali per la realizzazione dellobiettivo, mentre nella fase successiva di

sviluppo, si andr a raffinare il codice derivante da questa fase.

2.2.1 Sviluppo

La fase di sviluppo (o detta anche coding) quella dove si iniziano a tradurre le idee in

codice. Molto spesso per la complessit del progetto preferibile dividere questa fase in

due sottofasi:

fase di creazione di moduli base

fase di integrazione dei moduli creati



- 7 -

Nella fase di creazione di moduli, il codice viene spezzato in pi parti indipendenti in

modo da avere una panoramica delle porzioni di codice ottenendo applicativi semplici e

funzionali.

Nella fase di integrazione dei moduli andremo ad unire i vari blocchi creati per ottenere

cos il progetto finale.

2.3 Collaudo

In questa fase che vengono eseguiti i test di conformit del progetto e la verifica del

rispetto delle specifiche iniziali. In questo momento possibile verificare se la richiesta da

parte dellutente finale (fatta nellanalisi dei requisiti) fattibile in pratica.

I test da effettuare si propongono di:

confermare la correttezza del software creato

verificare che tutto sia conforme alle specifiche fornite dal cliente.

Ancora in fase di collaudo possono essere rilasciate alfa test e beta test. Mentre il primo

rilasciato allinterno dellazienda stessa (e i programmatori fungono da utenti finali), il

secondo rilasciato in modalit gratuita al grande pubblico con lo scopo di andare ad

individuare errori non pervenuti nella fase di collaudo interna. Spesso queste ultime

possono contenere vicoli di usabilit come date di scadenza.

2.4 Manutenzione

La fase pi lunga questultima, quella di manutenzione, dove lazienda rilascia

aggiornamenti e nuove versioni al fine di andare a migliorare il programma, correggerne

bug, implementarlo su altre piattaforme, aggiungerne nuove funzionalit.

Questultima fase, incide sul 60% dei costi totali del progetto in quanto ad ogni modifica

del codice dovr essere rieseguita la fase di testing sul prodotto semi-finito.



- 8 -

3. Principi di accessibilit dei siti web (Roberto Fabiano)

"The power of the Web is in its universality.

Access by everyone regardless of disability is an essential aspect."

(Tim Berners-Lee, direttore del Consorzio W3C e ideatore del World Wide Web)

L'accessibilit uno strumento fondamentale affinch un sito web sia usabile da parte di

tutti. Tale requisito regolamentato dalla legge Stanca (conosciuta anche come Legge

sull'Usabilit) approvata dal governo Italiano il 17 Dicembre 2003 col titolo Disposizioni

per favorire l'accesso dei soggetti disabili agli strumenti informatici (cf. Gazzetta ufficiale,

legge 9 Gennaio 2004, n. 4).

La presente legge si applica alle pubbliche amministrazioni, agli enti pubblici economici,

alle aziende private concessionarie di servizi pubblici, alle aziende municipalizzate

regionali, agli enti di assistenza e di riabilitazione pubblici, alle aziende di trasporto e di

telecomunicazione e alle aziende appaltatrici di servizi informatici. Alla data di entrata in

vigore del decreto, in caso di rinnovo, modifica o creazione tutti i siti che non rispettano le

disposizioni della presente legge circa il rispetto dei requisiti di accessibilit verranno

annullati.

Allegato al decreto legge Stanca vi una documentazione specificante le Linee Guida da

seguire per la realizzazione di siti web accessibili.

Allo scopo di accertare la conformit della pagina Web o della applicazione Web-based si

suggerisce una metodologia di valutazione che fa ricorso dei seguenti passi:

1. Verifica con sistemi di validazione automatica attraverso il servizio di validazione

delle grammatiche formali fornito dal W3C (http://validator.w3.org/)

2. Esame della pagina con diversi browser grafici, in differenti versioni e in diversi

sistemi operativi per verificare che contenuto e funzionalit presenti in una pagina

siano gli stessi nei vari browser, che disattivando il caricamento delle immagini,

fogli di stile, script, applet, contenuto e funzionalit siano ancora fruibili, che

disattivando il suono, i contenuti di eventuali file audio siano fruibili in altra forma;

Diverse agevolazioni sono previste per utenti disabili in maniera da non compromettere la



- 9 -

loro permanenza su internet. Si tratta di strumenti come lenti di ingrandimento, speaker

vocali che leggono il testo a schermo, sistemi di puntamento alternativi a mouse o tastiera.

Quindi i due punti cardine dell'accessibilit sono i seguenti:

capacit di trasformazione dei documenti secondo le caratteristiche proprie del

browser o fissate dall'autore per la lettura.

facilit di orientamento, di navigazione e di comprensione all'interno dei

documenti.

La prima delle due linee guida indica la propriet insita in una pagina di potersi adeguare

alle diverse modalit di rilettura rendendo le pagine auto-adattanti alle diverse

piattaforme dell'utente. I principi di base sono:

fornire testo alternativo ad immagini, applet e mappe immagini

fornire una descrizione pi accurata per grafici, script o applet importanti se risulta

inadeguata quella fatta per mezzo del testo alternativo o dal contesto del

documento

fornire l'equivalente testuale (didascalie) per le componenti audio la cui conoscenza

indispensabile per la comprensione del documento. Si pu aggiungere una frase

di testo sulla pagina che collega ad una trascrizione o descrizione dell'audio. In

questo caso il link alla trascrizione dovrebbe apparire in una locazione altamente

visibile come l'inizio della pagina.

fornire descrizioni verbali dell'informazione visuale in movimento (filmati,

animazioni, ecc)

assicurarsi che testo e grafica siano percepibili e comprensibili anche se visualizzati

senza colori.

indicare l'architettura del documento con elementi strutturali e la visualizzazione

con elementi di presentazione e style sheet.

assicurarsi che le tabelle siano strutturate correttamente.

assicurarsi che le pagine che usano le tecniche pi nuove, come gli style sheet ad

esempio, si trasformino adeguatamente in un formato accessibile se quella tecnica

non gestita o stata disabilitata.

assicurarsi che gli oggetti o pagine in movimento (immagini animate), testo che

scorre, o che si aggiornano automaticamente possano essere bloccate o poste in

pausa.

gli elementi che contengono delle proprie interfacce dovrebbero avere una propria



- 10 -

accessibilit costruita all'interno.

usare caratteristiche che abilitino l'attivazione degli elementi della pagina attraverso

dispositivi d'input diversi dal mouse (ad es. via tastiera o via voce).

usare soluzioni temporanee di accessibilit finch la tecnologia assistiva ed i

browser non si siano adeguati agli sviluppi del linguaggio HTML ed operino

correttamente.

fin dove possibile, usare le tecnologie W3C (specifiche e tecniche raccomandate e

certificate dal consorzio W3C) in accordo con le linee guida. Laddove questo non

possibile usare una versione alternativa del documento che risulti accessibile.

La seconda linea guida invita a rendere massima la possibilit di utilizzo fornendo

informazioni sul contesto e l'orientamento e semplificando la presentazione delle

informazioni.

In presenza di pagine complesse fornire informazioni sul contesto e

sull'orientamento.

Provvedere meccanismi che facilitino la navigazione all'interno del sito.



- 11 -

4. Principi per la qualit di un sito web culturale (Roberto Fabiano)

Un sito Web di qualit deve:

essere trasparente, definendo chiaramente sia l'identit e gli obiettivi del sito Web

sia l'organismo responsabile della sua gestione;

selezionare, digitalizzare, indicizzare, presentare e controllare i contenuti per creare

un sito Web efficace per tutti gli utenti;

implementare linee guida per le politiche di qualit del servizio per assicurare che il

sito Web venga adeguatamente mantenuto e aggiornato;

essere accessibile a tutti gli utenti, indipendentemente dalla tecnologie utilizzata o

dalle loro disabilit, inclusi gli strumenti di navigazione, il contenuto e gli elementi

interattivi;

essere centrato sull'utente, tenendo conto delle sue esigenze, garantendo

pertinenza della risposta e facilit d'uso attraverso meccanismi di valutazione e

feedback;

essere reattivo, consentendo agli utenti di contattare il sito e ricevere un'adeguata

risposta. Se necessario, incoraggiare i quesiti, la condivisione dei dati e la

discussione con e tra gli utenti;

essere consapevoli dell'importanza del multilinguismo fornendo un livello minimo

di accesso in pi di una lingua;

impegnarsi a essere interoperabile all'interno delle reti culturali per consentire agli

utenti di localizzare facilmente i contenuti e i servizi che rispondono alle loro

necessit;

essere gestito nel rispetto delle norme legali come il diritto di propriet intellettuale e la riservatezza e indicare chiaramente i termini e le condizioni di utilizzo del sito

Web e dei suoi contenuti; adottare strategie e standard per assicurare che il sito Web e i suoi contenuti

vengano conservati a lungo termine.



- 12 -

5. Specifiche di qualit dei siti web pubblici culturali (Roberto Fabiano)

Il Web, con proprie espressioni concettuali, strumentali e di linguaggio si confronta con il

settore della cultura, nel suo aspetto pubblico e specifico della tutela e valorizzazione del

patrimonio culturale. Prima di addentrarci nel contesto utile specificare le entit

partecipanti, chiarendo concetti, ambiti e soggetti.

Soggetto culturale pubblico: ente, istituzione con la finalit di andare a produrre,

conservare, tutelare e diffondere la cultura su ogni settore. Sono di interesse

generale la sua storia, le finalit istituzionali, i contenuti culturali da esso prodotti.

Applicazione Web culturale pubblica: realizzazione web di contenuti che

riguardino il patrimonio culturale e scientifico, rappresentando adeguatamente

lidentit e lattivit di un soggetto culturale pubblico, fornendo informazioni

culturali e scientifiche, diventando strumento di formazione per leducazione e la

ricerca scientifica.

Utente: soggetto qualificato o meno che vada ad usufruire dellapplicazione web

culturale pubblica. E una figura molto importante (in fase preliminare) al fine di

definire gli aspetti cruciali della realizzazione web.

I principi generali che deve avere unapplicazione Web nel settore della cultura sono quelli

di:

Adoperarsi per unampia diffusione della cultura

Far parte di una comunit di soggetti culturali

Approfittare dellefficacia dei nuovi canali di comunicazione

Adottare un uso consapevole del Web

Considerare la qualit come risultato del processo di incontro tra soggetti culturali e

utenti.



- 13 -

6. Usabilit per la comunicazione pubblica (Roberto Fabiano)

Per essere usabile un prodotto interattivo dovr:

essere adeguato ai bisogni e alle aspettative di specifici utenti che lo utilizzano in

specifici contesti d'uso;

risultare facile da capire, da imparare, da usare ed essere gradevole;

consentire di eseguire le specifiche attivit lavorative in maniera corretta, veloce e

con soddisfazione;

generare pochi errori non critici.

6.1 La definizione ISO

Lo standard ISO/IEC 9126 "Information technology - Software product evaluation -

Quality characteristics and guidelines for their use" definisce l'usabilit come "la capacit

del software di essere compreso, appreso, usato e gradito dall'utente quando usato in

determinate condizioni".

Lo standard ISO 9241-11 "Ergonomic requirements for office work with visual display terminals -

Guidance on usability" invece, definisce l'usabilit come "il grado in cui un prodotto pu

essere usato da classi di utenti per raggiungere specifici obiettivi con efficacia, efficienza e

soddisfazione in un contesto d'uso determinato".

6.2 I tre settori dellusabilit

Figura 1: I tre settori dell'usabilit



- 14 -

L'usabilit racchiude tre grandi settori di analisi:

l'architettura informativa;

la progettazione dell'interfaccia grafica;

l'analisi dei flussi interattivi.

6.2.1 Larchitettura informativa

L'architettura informativa chiarisce lobiettivo del prodotto, bilanciando le esigenze della

produzione con quelle degli utenti, determinando quali contenuti e funzioni deve avere il

prodotto, specificando come gli utenti saranno in grado di raggiungere le informazioni

all'interno del prodotto, prevedendo come il prodotto possa evolvere e crescere nel corso

del tempo.

6.2.2 La progettazione dell'interfaccia grafica

Il design di un prodotto informatico interattivo deve tenere conto soprattutto delle regole

grafiche di usabilit. Nella progettazione dell'interfaccia grafica convogliano competenze e

discipline di studio che svariano dal design alla psicologia percettiva, dai linguaggi e tool

di sviluppo (Html, Flash, ecc), al tipo font utilizzato.

6.2.3 L'analisi dei flussi interattivi Lo studio delle interazioni uomo-macchina mette in relazione l'usabilit con lergonomia.

L'ergonomia lo studio dell'interazione uomo-strumenti-ambiente nel suo complesso.

Pu essere riassunta come

"un corpus di conoscenze interdisciplinari in grado di analizzare, progettare e valutare sistemi

semplici o complessi in cui l'uomo figura come operatore o utente. Persegue coerenza e compatibilit

tra il mondo che ci circonda - oggetti, servizi, ambienti di vita e di lavoro - ed esigenze di natura

psicofisica e sociale, anche con l'obiettivo di migliorare l'efficienza e l'affidabilit dei sistemi"

(Societ Italiana di Ergonomia).

"L'interazione uomo-calcolatore una disciplina che riguarda la progettazione, la valutazione e

l'implementazione di sistemi interattivi per l'uso da parte degli esseri umani e lo studio dei pi

importanti fenomeni ad essi collegati".



- 15 -

6.3 Principi del buon design

Figura 2: Modello progettuale e modello dellutente

I principi di un buon design possono essere riassunti come:

fornire buon modello concettuale (permette di prevedere gli effetti delle azioni;

utile quando sorgono imprevisti o situazioni nuove)

rendere visibili le cose (rendere quanto pi intuitivi i comandi e le loro funzioni)

mapping (relazione tra azione e risultato finale)

presenza del feedback (informazione di ritorno che dice all'utente quale azione ha

effettivamente eseguito e quale risultato si realizzato).



- 16 -

7. Pianificazione di risorse per la produzione software (Giummarra Andrea)

Al fine di valutare attentamente le risorse a disposizione per il raggiungimento degli

obiettivi di qualit per la produzione di software e, dati determinati requisiti di sistema,

importante conoscere inizialmente i prodotti e i processi coinvolti nel sistema ULMS.

Nella seguente fase, dopo una breve definizione per la corretta distinzione dei termini

prodotti e processi, vedremo come si articola lo studio di fattibilit per la

pianificazione delle risorse.

7.1 Studio di fattibilit

I Prodotti sono il risultato di una determinata attivit di sviluppo; costituiscono ci che

viene consegnato allutente finale, quindi linsieme delle opere fornite dallattivit stessa

(applicativo software, documentazione, etc...). ULMS fornisce all'utente un software per la

gestione di una libreria universitaria con la relativa documentazione. Il costo del software

dominante sugli altri costi nello sviluppo di un sistema informatico. Nella vita di un

prodotto software la manutenzione costa molto di pi dello sviluppo.

ULMS si propone di poter garantire i seguenti requisiti del prodotto fornito:

Manutenibilit: Deve essere possibile modificare il software in modo da soddisfare

nuovi requisiti. Le sotto caratteristiche correlate sono:

Analizzabilit: capacit di limitare impegno richiesto per diagnosticare

carenze o cause di malfunzionamenti, o per identificare parti da modificare.

Modificabilit: capacit di limitare limpegno richiesto per modificare,

rimuovere errori o sostituire componenti.

Stabilit: capacit di ridurre il rischio di comportamenti inaspettati a seguito

della effettuazione di modifiche.

Testabilit: capacit di essere facilmente testato per validare le modifiche

apportate.

Funzionalit: capacit di fornire servizi tali da soddisfare, in determinate

condizioni, requisiti funzionali espliciti o impliciti (il software fa ci per fare il quale

stato acquistato). Le sotto caratteristiche correlate sono:

Adeguatezza: presenza di funzioni appropriate per compiti specifici che

supportano obiettivi dellutente.



- 17 -

Accuratezza: capacit di fornire risultati corretti in accordo con i requisiti dati

dallutente.

Interoperabilit: capacit di interagire con altri sistemi.

Sicurezza: capacit di proteggere programmi e dati da accessi non autorizzati

e di consentire quelli autorizzati.

Affidabilit: Nel caso di guasto, il software non deve produrre danni fisici od

economici.

Efficienza: Il software non deve fare un uso indiscriminato di memoria e tempo di

calcolo.

Facilit di utilizzo: Il software deve essere corredato di uninterfaccia utente e della

documentazione appropriate. Le sotto caratteristiche correlate sono:

Comprensibilit: capacit di ridurre limpegno richiesto agli utenti per capirne

il funzionamento e le modalit di utilizzo.

Apprendibilit: capacit di ridurre limpegno richiesto agli utenti per

impararlo ad usare.

Operabilit: capacit di mettere in condizione gli utenti di farne uso per i

propri scopi e controllarne luso.

Attrattivit/Piacevolezza: capacit di essere piacevole per lutente che ne fa

uso.

I Processi comprendono tutte le attivit che portano allo sviluppo di un certo prodotto; tra

queste ci sono le scelte che caratterizzano il prodotto finale (scelta del supporto hardware,

di metodologia di programmazione come il linguaggio da usare e il sistema operativo di

supporto, etc...).

7.1.1 Obiettivi del prodotto

ULMS propone di realizzare un software che guidi gli impiegati della libreria nel loro

lavoro.

Il sistema si basa sulla gestione di un unico database cui ci si pu interfacciare in modo

diverso in funzione del ruolo che lutilizzatore ha nella libreria.

Questo database conterr:

dati relativi al magazzino per gestire i suoi movimenti e per avere sempre una

visione aggiornata della giacenze;

dati relativi ai corsi universitari quali nome, numero di studenti, moduli di



- 18 -

svolgimento, testi consigliati o richiesti;

dati circa la storia dellacquisto/vendita dei libri;

dati relativi ai clienti per gestire le prenotazioni;

dati statistici di vendita per facilitare gli ordini dei libri nei periodi di

maggiore richiesta.

7.1.2 Strategie e politiche di ULMS: ciclo di vita del processo

Il processo di sviluppo del software integra i tre principali processi di sviluppo tra cui

lIterative and Incremental; pertanto la realizzazione del sistema avviene attraverso cicli di

iterazioni controllate, ognuna delle quali termina con la produzione di una nuova versione

del sistema.

Ogni ciclo costituito da quattro fasi: iniziale, elaborazione, costruzione e transizione,

ognuna delle quali , a sua volta, suddivisa in iterazioni. Risultato di ogni ciclo la

produzione di una nuova versione di ULMS virtualmente pronta per la consegna.

Grosso vantaggio di questo criterio che anche il processo di verifica iterativo e

incrementale: ogni volta che una nuova versione disponibile viene sottoposta a relativa

fase di test. Ci dovrebbe favorire la produzione di sistemi di migliore qualit.

Nel mondo dellideale, ogni versione dovrebbe consistere in codice incapsulato in

opportuni componenti eseguibili, corredati da manuali, documentazione e cos via.

Sebbene dal punto di vista del cliente i componenti eseguibili siano i manufatti pi

importanti, essi da soli non sono sufficienti. Ci dovuto al fatto che lambiente

tipicamente destinato a variare: espansione dei sistemi hardware, aggiornamenti di

sistemi operativi e database manager, ecc.

Gli stessi requisiti cliente diventano pi chiari e precisi con il procedere nel ciclo di vita del

software e pertanto sono soggetti anchessi ad aggiornamenti. Non a caso unidea che

spesso si ingenera nei team di sviluppo a consegna avvenuta, di essere in grado di poter

rifare lintero sistema pi adeguatamente e in minor tempo. I prodotti che devono

accompagnare la versione finale sono:

il modello dei casi duso, con evidenziate tutte le relazioni tra i diversi use case e i

relativi attori e gli scenari;

il modello di analisi che dovrebbe conseguire, principalmente, due obiettivi:

a. definire i casi duso in maggior dettaglio;

b. orientare un iniziale disegno del comportamento del sistema per mezzo



- 19 -

dellindividuazione degli oggetti basilari che lo caratterizzano;

il modello di disegno che definisce:

a. la struttura statica del sistema in termini di sottosistemi, classi, interfacce;

b. la realizzazione dei casi duso per mezzo di collaborazioni attraverso i

sottosistemi, le classi , ecc. evidenziati nella proiezione statica al punto

precedente;

il modello di implementazione che include i componenti (raggruppamento di

codice) e il mapping degli stessi con le relative classi;

il modello di dispiegamento (deployment) che definisce come i componenti

software vadano allocati sui nodi fisici (computer, server, reti, ecc.) previsti

dallarchitettura hardware;

il modello di test il quale definisce i casi di test (Test Case) che verificano gli Use-

Case;

la rappresentazione dellarchitettura.

La totalit di questi manufatti rappresenta ULMS nel suo insieme.

Un'alternativa alla variazione del ciclo di vita da valutare l'outsourcing, metodo di

affidamento di attivit giudicate non critiche a fornitori esterni .

7.1.3 Identificazione e allocazione delle risorse

In questa fase oltre a studiare la fattibilit del sistema, attraverso l'identificazione delle

risorse, entreremo nel piano operativo del progetto con l'allocazione delle risorse, le scelte

operative e lo scheduling delle attivit, nonch con la creazione del gruppo di lavoro

definendo ruoli, responsabilit, direzioni e coordinamento delle attivit.

Per la realizzazione di ULMS sono richieste un gruppo di risorse umane (risorse a

disponibilit limitata) e risorse di tipo materiale.

Si prevede l'utilizzazione di circa 4 unit di personale divisi, in base alle rispettive

competenze, in ruoli. In particolare in ULMS vengono impiegati 2 sviluppatori, che si

occupano della parte implementativa del progetto. I requisiti necessari richiesti per questi

soggetti sono la conoscenza di linguaggi di programmazione orientata ad oggetti, la

capacit di gestione di un DBMS per lo storage dei dati e la facilit ad adattarsi a

qualunque ambiente di sviluppo, quindi alle relative applicazioni.

Oltre a questi soggetti necessaria la presenza di un'unit di personale per l'analisi in

itinere e finale del prodotto, nonch per il coordinamento generale del lavoro. Un ulteriore



- 20 -

soggetto viene impiegato per la diffusione di ULMS nel mercato, nonch nella gestione

dei bilanci circa l' approvvigionamento e l'utilizzo delle risorse finanziarie destinate alla

realizzazione del prodotto. Le conoscenze richieste per quest'ultimo soggetto sono

principalmente l'abilit nella consulenza e nel marketing.

Per quanto riguarda invece le risorse di tipo materiale occorre fornirsi di un numero di

workstation con adeguate prestazioni pari al numero di unit fisiche componenti il gruppo

di lavoro. E' inoltre necessario fornirsi di un locale in cui svolgere le attivit di sviluppo,

analisi e gestione del progetto. Altri tipi di risorse, relativamente significative in quanto

classificabili a disponibilit illimitata, sono materiali di cancelleria e in generale materiali

di consumo.

Per quanto riguarda, invece, le risorse finanziarie come ad esempio spese di viaggio e

soggiorno all'estero compito dell'addetto alla consulenza e al marketing svolgere

periodicamente un bilancio circa le disponibilit temporanee e la stima di quelle future.

7.1.4 Stima di massima di tempi e mesi-uomo Al fine di calcolare una stima di massima di alcuni parametri fondamentali come il tempo

di consegna e i mesi-uomo necessari per lo sviluppo di ULMS, esiste un metodo chiamato

COnstructive COst Mode (COCOMO), definito da B. Boehm all'inizio anni 80.

Tale metodo, radicato su un modello algoritmico, si basa sul waterfall model e consente di

calcolare, tramite una serie di formule ed in base a parametri quantificanti le

caratteristiche del software da sviluppare, una stima di:

quantit di lavoro M (espressa in mesi/uomo - MM)

tempo di sviluppo T (in mesi)

dove 1 MM = 152 ore

Le due formule utilizzate da questo modello sono le seguenti:

Sforzo: =

Tempo di sviluppo: =

dove, E (effort) indica la quantit di lavoro (espressa in Mesi/Persona), D (duration)

rappresenta il tempo di sviluppo (espresso in Mesi) e S rappresenta il numero di linee di

codice previste (espresse in migliaia).



- 21 -

Esistono tre diversi modelli di COCOMO che si differenziano per la raffinatezza e la

precisione con cui vengono stimati i diversi valori: Basic, Intermediate e Advanced,

chiamato anche Detailed.

Basic COCOMO - il pi facile da calcolare ma anche il meno preciso, la stima viene

fatta partendo dalla dimensione del software da sviluppare calcolata in numero di

linee di codice esclusi i commenti.

Intermediate COCOMO - calcola lo sforzo di sviluppo del software come funzione

della grandezza del programma, espressa sempre in linee di codice, e su un insieme

di "indici di costi", detti Cost-driver, che includono l'assegnazione soggettiva di

valutazioni di prodotti, hardware, attributi di progetto e personali.

Advanced/Detailed COCOMO - incorpora tutte le caratteristiche del COCOMO

intermedio con una valutazione dell'impatto dei vari costi per ogni passo (analisi,

progettazione, ecc.) del processo di ingegneria del software.

Per ciascun livello di COCOMO esistono tre diverse tipologie di progetto, Organic, Semi-

detached e Embbedded, che possono essere utilizzate come modello a seconda dei vincoli

che si hanno:

Organic: il progetto che si sta sviluppando piccolo, si ha gi esperienza su questa

tipologia, si hanno pochi vincoli esterni.

Embedded: l'opposto dell'organic, il progetto di grandi dimensioni, sia ha poca

esperienza su questa tipologia di prodotti, ci sono forti vincoli esterni sui costi e sui

tempi.

Semi-detached: a met via tra organic e embedded.

Una delle osservazioni importanti nel modello che considerazioni soggettive affiancano

tutti gli altri parametri. Ci significa che le abilit del team e dell'individuo incaricato di

tale valutazione influenzano grandemente il modello.

Per ULMS si prevede una produzione approssimata di circa 10.000 righe di codice.

Applicando l'algoritmo(Baker) del modello base di COCOMO vengono restituiti in output

i seguenti valori:



- 22 -

Organic Values

Number of Months Needed: 8.738165793274268

(numero di mesi necessari)

Number of People Needed: 3

(numero di personale necessario)

SemiDetached Values





Embedded Values





Considerando i valori della tipologia SemiDetached per ULMS si prevede l'impiego di 4

unit fisiche per quanto riguarda i componenti del gruppo di lavoro per un totale di circa

9 mesi di tempo necessario per coprire tutte le fasi del ciclo di vita del processo produttivo.

7.1.5 Stima di massima dei costi

Questa fase prevede la pianificazione dei costi a cui l'azienda deve far fronte durante il

periodo produttivo.

Si prevede la spesa destinata all'affitto dei locali in cui si svolgeranno le attivit di

sviluppo, analisi e gestione del progetto di un ammontare di circa 250,00 al mese. Per

tutto il periodo di attivit occorreranno dunque solo per l'affitto 2.250,00. Si prevede

inoltre l'acquisto di 4 pc di circa 1.000,00 cadauno per un ammontare di 4.000,00. Altre

spese saranno destinate per i consumi di luce e connessione a internet per una media di

120,00 mensili e quindi un totale di 1.080,00. Supposto che occorrer assumere un

esperto in consulenza e marketing, si dovranno spendere circa 7.200,00 in totale per la

retribuzione, considerando una mensilit di circa 800. Considerando che verr utilizzato

un ambiente di sviluppo opensource non si prevedono ulteriori spese eccessive. Il totale

quindi ammonter per l'intero ciclo di vita a circa 14.530,00.



- 23 -

7.2 Piano operativo

7.2.1 Scheduling delle attivit

Il seguente schema rappresenta la collocazione temporale delle attivit previste per la

realizzazione di ULMS.

Figura 3: Pianificazione delle attivit per la realizzazione di ULMS



- 24 -

Definita come carta di Gantt, tale rappresentazione descrive l'andamento di ogni attivit

durante l'intera durata del ciclo di vita (9 mesi circa).

Come citato nella Legenda della carta di Gantt, viene inizialmente creato il gruppo di

lavoro in seguito ad unaccurata selezione, formazione e valutazione per definire ruoli e

responsabilit. Questa fase preliminare, della durata di qualche giorno,

immediatamente seguita da altre attivit; tuttavia non viene svolta in concomitanza di

altre attivit in quanto risulta necessaria la definizione dei ruoli prima dello svolgimento

di tutte le altre attivit. Proprio per questa motivazione possiamo definire un legame di

precedenza di tipo f-to-s (finish-to-start) tra questa attivit e tutte le altre in quanto queste

ultime non possono avere inizio prima del completamento della prima.

Dopo i primi giorni dall'inizio e quindi, dopo la prima attivit, iniziano simultaneamente

altre tre attivit: lo sviluppo del software, una prima gestione delle configurazioni

(opzionale) nel caso in cui si parta da software di base preesistente e un bilancio sulle

risorse. Le parti delle attivit in cui sviluppo del software e gestione delle configurazioni

sono in concomitanza sono esclusive nel senso che, se vi una gestione delle

configurazioni non pu esserci sviluppo del software in quanto tra di esse c' un legame di

precedenza di tipo f-to-s e viceversa se non vi una gestione delle configurazioni iniziale si

pu iniziare a sviluppare software. Per tutti i successivi casi di concomitanza tra queste

due attivit non ci sar mutua esclusione in quanto gli sviluppatori potranno continuare il

loro lavoro, magari testando, collaudando o revisionando ci che stato fatto fino a quel

momento, nonostante in quel momento sia in atto la fase di gestione delle configurazioni.

Per questo secondo caso possiamo attribuire un legame di precedenza tra queste due

attivit di tipo s-to-s (start-to-start) in quanto la gestione delle configurazioni non pu avere

inizio prima dell'inizio della fase di sviluppo. La terza attivit svolta dopo la fine della

formazione del gruppo di lavoro quella in cui avviene un bilancio delle risorse. Questa

attivit non tiene conto del caso opzionale dell'attivit di gestione delle configurazioni, per

cui possiamo dire che tra di esse non esiste mutua esclusione. Possiamo attribuire un

legame di precedenza tra questa attivit e quelle di sviluppo del software e gestione delle

configurazioni, esclusa la prima parte, del tipo s-to-s in quanto il bilancio delle risorse non

pu avere inizio prima che inizi lo sviluppo del software e la gestione delle configurazioni.

Un'ultima attivit prevista quella di collaudo finale. Lo svolgimento di tale attivit si

riconduce nella fase conclusiva del processo di produzione di ULMS, pi precisamente tra

la fine dell'ottavo mese e l'inizio del nono. Attribuiremo un legame di precedenza tra

questa attivit e tutte le altre di tipo f-to-s in quanto non possibile iniziare il collaudo di

ULMS prima che non vengano completate tutte le altre operazioni, soprattutto quella di

sviluppo.



- 25 -

7.2.2 Diagramma PERT

Valutando i legami di precedenza esistenti tra le varie attivit per la progettazione di

ULMS possibile raffigurarle nel seguente schema, detto diagramma PERT (acronimo di

Program Evaluation and Review Technique, una tecnica di controllo dello stato di

avanzamento di progetti adoperata dalla Lockheed negli anni '50, in cui venne per la

prima volta fatto uso di questo genere di diagrammi).

Figura 4: Pianificazione delle attivit per la realizzazione di ULMS

Si pu notare che le tre attivit centrali (s sviluppo software; a analisi delle versioni;

b bilancio sulle risorse) vengono svolte in parallelo. Esse tuttavia non possono avere

inizio se prima non viene completata l'attivit di formazione del gruppo (g). La quinta

attivit (c collaudo finale di ULMS) chiude l'intero ciclo di vita. Essa non pu iniziare se

prima non terminano tutte le altre operazioni.

Lo scheduling delle attivit deve tener conto non solo dei legami di precedenza ma anche

dei conflitti di allocazione di risorse, e risolvere questi ultimi operando sulle date delle

attivit. Il resource leveling consiste nell'applicazione di questo principio.



- 26 -

8. Evoluzione del Software (Giummarra Andrea)

8.1 Stima e valutazione dei rischi di ULMS

I principali rischi a cui soggetto ULMS sono da ricercare soprattutto nella fase di

pianificazione in quanto proprio in questa fase in cui si improntano le basi del progetto;

risulta dunque indispensabile fare attenzione alla definizione delle previsioni proprio

nelle prime battute dell'intero ciclo di vita.

Il primo rischio da evitare consiste nella indeterminatezza, ambiguit, indefinizione o

genericit degli obiettivi da raggiungere. In altre parole bisogna assolutamente evitare che

la formulazione degli obiettivi sia di scarsa qualit. Per formulare adeguatamente gli

obiettivi, occorre che siano il pi possibile chiari, cio espressi in un linguaggio

comprensibile, specifici e soprattutto misurabili. La misurabilit di un obiettivo, infatti,

associata alla definizione dei valori attesi, permetter di riconoscerne il raggiungimento e,

in definitiva, di garantire il successo stesso del progetto.

Un altro importante rischio a cui potrebbe essere esposto ULMS riguarda la fase di

strutturazione del gruppo di lavoro. E' importante selezionare, formare e valutare per bene

i soggetti fisici che operano attivamente nella produzione del software per poi definire in

maniera chiara e corretta ruoli e responsabilit. Una buona selezione del gruppo di lavoro

evita, o per lo meno aiuta a eludere, possibili rischi in fase di sviluppo di ULMS che a loro

volta porterebbero ad ulteriori errori, bug e malfunzionamenti del prodotto finale.

Esiste ancora un altro rischio dovuto alla inadeguata allocazione delle risorse. Questo

porta ad un problema piuttosto comune che riguarda la fuoriuscita dai budget assegnati e

al superamento del tempo di scadenza precalcolato. Le cause possibili che conducono a

questo tipo di problema sono principalmente di due tipi: unadeguata allocazione delle

risorse che tuttavia verranno poi gestite inappropriatamente; oppure una scarsa

allocazione di risorse dovuta ad unimprecisa stima iniziale.

Un ultimo rischio si pu presentare in fase di gestione delle configurazioni ed in

particolare quando si effettua per la prima volta l'attivit di gestione di configurazione.

Osservando lo schema in cui rappresentato lo scheduling delle attivit di ULMS si pu

notare che se si parte da un modello di software gi esistente e quindi, prima che ancora

inizi la fase di sviluppo del software, viene eseguita un'attivit di gestione delle

configurazioni non adeguatamente corretta, si pu correre il rischio di importare difetti da

software preesistenti.



- 27 -

9. Analisi, modellazione e specifica dei requisiti (Giummarra Andrea)

Utilizzeremo il termine impiegato come soggetto di azioni comuni alle tre figure che sono i

possibili utilizzatori del sistema:

commesso

magazziniere

gestore ordini

Distingueremo fra i termini prenotazione e ordine intendendo con il primo la richiesta di

uno o pi libri da parte di un cliente alla libreria e, con il secondo, quella della libreria ad

un rappresentante o fornitore.

9.1 Sistema corrente

Attualmente possiamo supporre che la libreria sia gestita totalmente in maniera manuale

anche se basata su una divisione logica dei compiti analoga a quella identificata per il

sistema. Questo causa problemi di comunicazione tra le diverse figure che operano

allinterno della libreria e che si ripercuotono nella qualit del servizio offerto ai clienti.

Con tale approccio, infatti, non agevole prevedere le future vendite n tanto meno

gestirle nel modo adeguato facendo un ordine preventivo. Inoltre si hanno difficolt nella

gestione di casi eccezionali.

9.2 Requisiti funzionali

Il sistema prevede la possibilit di accedervi in tre modalit:

Vendita dei libri

Gestione del magazzino

Acquisizione dei libri

Si accede al sistema tramite uno qualunque dei terminali (non necessariamente tre). Tutti i

terminali sono in grado di funzionare in qualunque modalit sopra menzionata, previa

abilitazione o durante la fase di avvio del sistema o durante lutilizzo in una modalit

differente. Queste si differenziano per linterfaccia utente ma soprattutto per le operazioni

che loperatore pu effettuare.



- 28 -

9.3 Requisiti non funzionali

9.3.1 Interfaccia utente e fattore umano

ULMS presenta uninterfaccia utente di tipo intuitivo. Questo permette una sua

utilizzazione da parte di utenti anche non esperti con lausilio di un addestramento

minimo, inoltre la distinzione delle tre modalit permette di limitare il campo di azione

dellutente preservando il sistema da perdite e/o modifiche accidentali di dati.

9.3.2 Documentazione

Durante la progettazione di ULMS saranno prodotti e rilasciati i seguenti

documenti:

Documento Utenti del documento

Documento di analisi dei requisiti (RAD) Sviluppatori, clienti

Documento del piano di sviluppo del

progetto

Sviluppatori, clienti

Documento dell'architettura software Sviluppatori,

analisti

Documento del progetto esecutivo Sviluppatori

9.3.3 Considerazioni Hardware

ULMS verr installato su ununica macchina nella quale sar anche allocato il database.

Poich il sistema si interfaccia con il database facilmente si pu estendere il suo utilizzo ad

una generica rete di computer eventualmente dedicando ununica macchina, che funger

da server, per il database. Lutilizzo di questo approccio non pone un limite massimo al

numero di terminali collegabili.

Si supporr di utilizzare macchine dotate di processori Intel o AMD.



- 29 -

9.3.4 Prestazioni Hardware

Si prevede che i requisiti minimi imposti da ULMS siano quelli relativi al

corretto funzionamento del sistema operativo.

9.3.5 Interfaccia del sistema

ULMS prevede lutilizzo di dispositivi di interfacciamento tradizionali di un personal

computer (monitor, tastiera e mouse).



- 30 -

10. Analisi dei requisiti funzionali (Canzonieri Matteo)

Descriviamo i requisiti funzionali attraverso il modello dei casi d'uso, comprensivo di

diagramma/i di casi d'uso, scenari e package di casi d'uso.

Di seguito essi verranno mostrati. Inizialmente presentiamo un diagramma che presenti il

sistema in maniera generica, man mano il livello di astrazione andr scendendo.

10.1 Diagramma di contesto del sistema

Figura 5: Diagramma di contesto del sistema



- 31 -

10.2 Diagramma delle funzionalit offerte dal sistema

Il seguente diagramma mostra le funzionalit offerte ai singoli attori mantenendo,

comunque, un alto livello di astrazione. I casi duso pi complessi verranno dettagliati con

ulteriori diagrammi dei casi duso.

Figura 6: Diagramma delle funzionalit offerte dal sistema

verranno mostrati una serie di casi duso che sono stati uniformati perch comuni a pi

figure. Ad esempio, osserviamo che le operazioni di ricerca, riguardano sia i libri, che i

clienti, o le prenotazioni dei libri ecc.



- 32 -

Caso d'uso: Cerca

Attori partecipanti Inizializzato da IMPIEGATO

Flusso d'eventi:

Condizione

d'ingresso:

L' IMPIEGATO, trovandosi in una finestra che permette la

ricerca riempie gli appositi campi presenti nel form con i dati

da ricercare (non necessariamente tutti) e clicca sul tasto

Cerca

Condizione d'uscita: Il SISTEMA riordina la lista nella finestra mostrando

quelli che soddisfano i requisiti

Caso d'uso: Mostra tutti


Flusso di eventi:

Condizione

d'ingresso:

L' IMPIEGATO, trovandosi in una finestra che permette la

ricerca dopo aver effettuato una ricerca, volendo visualizzare

tutto l'elenco (in funzione della finestra in cui si trova) clicca

sul tasto Mostra tutti

Condizione d'uscita: Il SISTEMA mostra tutto l'elenco.

Caso d'uso: Indietro


Flusso di eventi:

Condizione

d'ingresso:

L' IMPIEGATO, trovandosi in una finestra qualsiasi clicca sul

tasto indietro.

Condizione d'uscita: Il SISTEMA visualizza la finestra immediatamente superiore



- 33 -

Caso d'uso: Nuovo


Flusso di eventi:

Condizione

d'ingresso:

l'IMPIEGATO, trovandosi in una finestra che

permette l'immissione di una nuova voce, riempie gli

appositi campi presenti nel form con i nuovi dati e clicca sul

tasto Nuovo

Condizione d'uscita: Il SISTEMA riordina la lista nella finestra

evidenziando nella lista il nuovo dato inserito

Caso d'uso: Cancella


Flusso di eventi:

Condizione

d'ingresso:

L' IMPIEGATO, trovandosi in una finestra che

permette la cancellazione di una voce del database, seleziona

una voce dalla lista e clicca sul tasto Cancella

Il SISTEMA chiede conferma per la cancellazione del dato.

L'IMPIEGATO fa la sua scelta

Condizione d'uscita: Il SISTEMA se necessario aggiorna il database

Caso d'uso: Modifica


Flusso di eventi:

Condizione

d'ingresso:

L' IMPIEGATO, trovandosi in una finestra che

permette la modifica di una voce del database, seleziona la

voce, ne modifica i dati e clicca sul tasto Modifica

Il SISTEMA chiede conferma della modifica del dato.

L'IMPIEGATO fa la sua scelta

Condizione d'uscita: Il SISTEMA se necessario aggiorna il database, evidenziando

il dato modificato nella lista



- 34 -

10.3 Diagramma delle funzionalit di impiegato

Queste funzionalit sono comuni a tutte e tre le figure (commesso, gestore ordini,

magazziniere) operanti nella libreria e per questo vengono generalizzate tramite la figura

di impiegato. Di seguito vengono riportati i casi duso relativi.

Figura 7: Diagramma delle funzionalit di impiegato

Caso d'uso: Selezione_modalita_vendita_libri


Flusso di eventi:

Condizione

d'ingresso:

L' IMPIEGATO, avvia il programma di gestione della

libreria

Il SISTEMA visualizza la finestra di scelta della modalit di

utilizzo

L'IMPIEGATO clicca sul tasto vendita libri

Condizione d'uscita: Il SISTEMA visualizza la finestra vendita libri



- 35 -

Caso d'uso: Selezione_modalita_gestione_ordini


Flusso di eventi:

Condizione

d'ingresso:


libreria


utilizzo

L'IMPIEGATO clicca sul tasto gestione ordini

Condizione d'uscita: Il SISTEMA visualizza la finestra di gestione ordini

Caso d'uso: Selezione_modalita_magazzino


Flusso di eventi:

Condizione

d'ingresso:


libreria


utilizzo

L'IMPIEGATO clicca sul tasto magazzino

Condizione d'uscita: Il SISTEMA visualizza la finestra magazzino

Caso d'uso: Selezione_modalita_di utilizzo


Flusso di eventi:

Condizione

d'ingresso:

L' IMPIEGATO, trovandosi nella finestra iniziale di una

qualunque modalit , clicca sul tasto Modifica modalit.

Il SISTEMA visualizza una finestra con scritto "Sei

sicuro di voler cambiare modalit?"



- 36 -

L'IMPIEGATO seleziona Si

Il SISTEMA visualizza la finestra scelta della modalit di

utilizzo

L'IMPIEGATO seleziona una nuova modalit di

utilizzo tra quelle disponibili (vendita libri, gestione ordini,

magazzino)

Condizione d'uscita: Il SISTEMA visualizza la finestra della modalit selezionata

Caso d'uso: Esci


Flusso di eventi:

Condizione

d'ingresso:

L' IMPIEGATO, trovandosi nella finestra scelta della

modalit di utilizzo o in una qualunque finestra iniziale

clicca sul tasto Esci

Il SISTEMA visualizza una finestra con scritto Sei sicuro di

voler uscire?

L'IMPIEGATO risponde alla domanda

Condizione d'uscita: Il SISTEMA se necessario chiude il programma

Vediamo adesso tre scenari che vedono come attore l'impiegato

Nome dello scenario: Selezione iniziale modalit di utilizzo

Attori partecipanti Ugo: commesso

Flusso di eventi: Ugo avvia il programma di gestione della libreria

Ugo seleziona la modalit di utilizzo vendita tra quelle

disponibili (vendita, magazzino, gestione_ordini)

Compare la finestra di gestione delle vendite



- 37 -

Nome dello scenario: Modifica modalit di utilizzo


Pippo : magazziniere

Flusso di eventi: Ugo sta lavorando al suo terminale in modalit vendita

Arriva Pippo che ha la necessita di lavorare in modalit

magazzino. Chiede ad Ugo di cedergli momentaneamente la

postazione.

Pippo clicca sul tasto Modifica Modalit

Compare la finestra che chiede Sei sicuro di voler cambiare

la modalit di utilizzo e Pippo seleziona Si

Appare il form di selezione modalit e Pippo seleziona

Magazzino

Nome dello scenario: Cerca libro


Ciccio : cliente

Flusso di eventi: Ciccio chiede la disponibilit di un libro

Ugo riempie gli appositi campi presenti nel form con i dati

del libro (non necessariamente tutti) e clicca sul tasto Cerca

libro

Il sistema riordina la lista dei libri mostrando quelli

che soddisfano i requisiti

Ugo osserva il numero di copie disponibili in magazzino

nella colonna apposita e risponde a Ciccio



- 38 -

11. Architettura software (Canzonieri Matteo)

L'enorme sviluppo del software ha creato la necessit di affrontare problemi che non

riguardano, semplicemente, gli algoritmi o le strutture dati, ma sono concentrati sulla

organizzazione generale del sistema l'architettura software. Il design del software

quindi si provvede di diagrammi descrittivi (talvolta anche informali), moduli di

interconnessione tra linguaggi eterogenei, che servono per i modelli formali di

integrazione tra i componenti del software stesso.

11.1 Tipi e caratteristiche degli stili di architetture software

Adesso passeremo in rassegna le diverse tipologie di scelte architetturali, concentrandoci

inoltre sui compromessi che le varie scelte ci obbligano ad affrontare.

11.1.1 Architettura dataflow

L'architettura dataflow oppure a canali e filtri (pipes and filter) composta da elementi

chiamati appunto filtri che modificano un flusso di dati, proveniente dal canale d'ingresso,

e lo ripongono nel canale di uscita.

Figura 8: Schema architettura dataflow

Le connessioni tra i vari filtri servono per condurre i dati da un filtro allaltro. Ogni filtro

unentit indipendente che non condivide lo stato con altri filtri, quindi le trasformazioni

sono effettuate localmente in ogni filtro.

Canale in Canale out Filtro



- 39 -

Vantaggi e svantaggi

Tra i vantaggi del dataflow ne notiamo due :

Il comportamento globale dato dal comportamento locale dei singoli filtri.

Garantisce facilit di manutenzione in quanto i filtri possono essere modificati,

aggiunti o cancellati senza sconvolgere la struttura del sistema.

Gli svantaggi invece sono i seguenti:

I filtri non sono adatti a gestire applicazioni interattive, rappresentano solo un

flusso di informazioni.

Ogni filtro pu iniziare a lavorare solamente quando il filtro precedente ha concluso

la generazione del suo output.

11.1.2 Architettura ad astrazione di dati (od orientata agli oggetti)

Un' alternativa l'architettura di un sistema basata su oggetti e classi; in questo contesto

un oggetto corrisponde generalmente ad un concetto presente nel dominio del problema o

nello spazio della soluzione, mentre una classe corrisponde ad un insieme di oggetti simili.

Ogni oggetto caratterizzato da unidentit, da uno stato e da un comportamento. Ogni oggetto

deve garantire l'integrit dell'operato di cui responsabile, e tale operato celato agli occhi degli

altri oggetti.

Vantaggi e svantaggi

Tra i vantaggi dellarchitettura ad astrazione di dati notiamo:

Conduce allo sviluppo di sistemi pi piccoli e semplici perch consente di applicare

meglio il riutilizzo di componenti preesistenti;

Conduce allo sviluppo di sistemi pi piccoli e semplici perch consente di applicare

meglio il riutilizzo di componenti preesistenti;

Consente di descrivere il sistema in un modo pi comprensibile per gli utenti finali

e pi vicino al dominio applicativo nel quale il sistema si colloca.



- 40 -

Gli svantaggi invece sono i seguenti:

Se un oggetto deve interagire con un altro ha bisogno di conoscerne lidentit. Ci

implica che se un oggetto viene modificato, tutti gli altri oggetti dovranno essere

modificati.

11.1.3 Architettura event-driven (oppure ad invocazione implicita)

Questo stile di design del software si basa sul fatto che un componente non invia

uninvocazione esplicita a procedura, ma trasmette un evento; Intanto gli altri

componenti associano una o pi procedure a uno specifico evento tramite il sistema. Una

volta che un componente invia l'evento, il sistema si preoccupa di eseguire tutte le

procedure ad esso associate.

Figura 9: Schema architettura event-driven

Il principale vantaggio di questo stile che un componente pu essere inserito o sostituito

senza alcuna modifica dell'intero sistema, necessario soltanto registrarsi per gli eventi di

quel sistema.



- 41 -

Figura 10: Schema di gestione degli eventi

Uno svantaggio invece, che come abbiamo visto, un componente lascia la responsabilit

dell'esecuzione al sistema; ci implica che il componente in questione non ha idea di cosa

accade successivamente alla sua emissione dell'evento. Il componente non pu sapere cosa

gli viene risposto dagli altri componenti; inoltre non pu tenere traccia dell'ordine in cui le

risposte gli sono state inviate, e nemmeno se le risposte sono finite. Infine uno svantaggio

sicuramente la difficolt di analizzare il sistema, in quanto l'analisi degli eventi dipende

soprattutto dai tipi di evento invocato.

11.1.4 Architettura stratificata

Questo tipo di architettura, detta anche layered, rappresentabile in livelli. Ogni livello

pu comunicare solo con i livelli adiacenti, ed usa il livello sottostante per creare le sue

funzioni. Alcuni sistemi sono implementati in maniera che i livelli pi bassi possano essere

visti solo dai livelli adiacenti.

Figura 11: Schema di architettura a strati

Sottosistema

1

Sottosistema

2

Sottosistema

3

Gestore eventi e messaggi



- 42 -

Tra i pro notiamo, proprio dalla struttura di questa architettura, la possibilit di

implementare sistemi che esigono una struttura astratta a livelli gerarchici incrementali.

Essi permettono inoltre di scindere macro-problemi in sotto-problemi, rendendone pi

agevole la risoluzione. La foto mostra inoltre che possono esistere moduli separati ma che

risiedono sullo stesso livello, ci fa in modo che livelli adiacenti siano interagenti e

interscambiabili.

Purtroppo questo tipo di architettura presenta diversi svantaggi:

Non sempre facile stabilire il giusto livello di astrazione in cui va inserito un

modulo.

Una funzione ad alto livello potrebbe voler interagire con un livello molto basso.

Ci diventa problematico quanto i livelli d'astrazione sono protocolli.

Figura 12: Schema stratificato dellinterprete dei comandi

Un esempio esplicativo di questo tipo di architettura sicuramente il protocollo di

comunicazione stratificato, quale ad esempio quello presente tra l'interprete dei comandi e

il kernel.

Interprete Comandi

Input/Output

Gestione Periferiche

Gestione Memoria

Nucleo



- 43 -

11.1.5 Architettura basata su repository

Tale modello presenta due sottoinsiemi, un repository centrale che rappresenta lo stato

corrente, e molti elementi decentrati.

I sottoinsiemi devono scambiare dati. Questo pu essere fatto in due modi:

I dati condivisi sono mantenuti in un data base centrale o repository e possono

essere acceduti da tutti i sottosistemi.

Ogni sottosistema mantiene il proprio database e passa esplicitamente i dati agli

altri sottosistemi.

Figura 13: Schema di architettura basata su repository

Quando grandi quantit di dati devono essere condivisi, il modello repository il pi

usato. In questo modello, il repository, pu essere passivo nel caso in cui ripone la

responsabilit, di eseguire le operazioni su di esso, ai client; viceversa si dice attivo

quando si incarica in prima persona di notificare ai client le avvenute modifiche sui dati.

Vantaggi:

E' un modo efficiente per condividere grandi quantit di dati.

I sottosistemi (client) non necessitano di sapere in che modo i dati sono condivisi.

La gestione dei dati centralizzata (backup, sicurezza...).

Lo schema dei dati pu venire pubblicato nel repository condiviso.



- 44 -

Svantaggi:

I sottosistemi (client) devono basarsi sulla stessa struttura dei dati condivisi. Ossia,

tutti i client devono usare la stessa rappresentazione dei dati.

Modificare la struttura (schema) dei dati difficile e costoso.

Difficile impostare delle politiche diverse di accesso ai dati.

Bassa scalabilit: il repository centrale un buon candidato ad essere un collo di

bottiglia.

11.1.6 Architettura basata su interprete

In unorganizzazione ad interprete in genere si implementa una macchina virtuale via

software. Un interprete contiene quattro elementi:

1) Un motore di interpretazione che svolge il grosso del lavoro.

2) Una memoria che contiene lo pseudo-codice da interpretare.

3) Un controllo di stato del motore di interpretazione (in memoria)

4) Una rappresentazione dello stato corrente del programma simulato.

Questa architettura in genere usata per colmare il vuoto tra ci che si vuole

semanticamente ottenere e ci che invece possibile ottenere in hardware.



- 45 -

12. Accenni al collaudo software (Canzonieri Matteo)

Come, in precedenza, abbiamo discusso, l'utilizzo del software ha subito un forte

incremento negli ultimi decenni. Tale sviluppo ne ha implicato l'uso anche in ambienti in

cui errori computazionali possono portare a seri rischi, si pensi ad esempio agli ospedali.

Proprio per questo nato l'interesse a incrementare quella parte dello sviluppo software

atta a minimizzare gli errori. Tale branca chiamata collaudo del software o software

testing.

Il software testing deve tenere in debita considerazione alcuni punti chiave:

Il collaudo deve essere basato sui requisiti specificati.

Il tempo e le risorse dedicabili al collaudo sono limitate.

Non possibile (purtroppo) testare tutto.

Le risorse usate per il collaudo devono essere valide (sia i collaudatori che i metodi

di collaudo).

Il collaudo non inizia quando il codice pronto, ma alla specifica dei requisiti.

Si inizia a collaudare dai singoli moduli, e via via risalendo alla totalit del codice,

con il metodo bottom-up.



- 46 -

13. Modello di stima dei costi e tempo di produzione del

software (Canzonieri Matteo)

Le metriche del software sono delle misure che servono principalmente a:

Migliorare il processo software

Pianificare seguire e controllare l'andamento di un progetto

Valutare la qualit del prodotto

Effettuare una stima dello sforzo richiesto per implementare e mantenere il sistema

software

Un ottimo metodo per calcolare i costi del software il modello COCOMO nato anche

dalla fusione delle esperienze acquisite dall'uso di altri metodi.

La stima viene effettuata considerando come unica variabile indipendente la dimensione

del programma da sviluppare in KLOC (migliaia di line of code righe di codice).

13.1 Modello base

Per avere una stima si usano, in questo modello, due formule (S = dimensione del

programma):

= =

Dove:

Tipo dell applicazione Ab Bb Cb Db

Organic 2,4 1,05 2,5 0,38

Semi-detached 3,0 1,12 2,5 0,35

Embedded 3,6 1,20 2,5 0,32

Nel modello base si usano anche tabelle che indicano per ogni classe la suddivisione

percentuale per le varie fasi del ciclo di vita esse sono parametrizzate in funzione della

dimensione del programma.



- 47 -

Per esempio le varie percentuali di quantit di lavoro nella classe di applicazioni semplici

sono:

Dimensione in KDSI (del modo organic)

Fasi 2 8 32 128 512

Pianificaz. 6 6 6 6

Progetto 16 16 16 16

Sviluppo 68 65 62 59

Integr. test 16 19 22 25

All'aumentare della dimensione del sistema i tempi per la pianificazione ed il progetto

restano pressoch invariati mentre il tempo per lo sviluppo diminuisce a scapito

dell'integrazione e test.

All'aumentare della complessit del sistema (applicazioni intermedie, complesse) i tempi

aumentano tranne quello dello sviluppo che addirittura uguaglia quello del progetto.

13.2 Modello intermedio

Si calcola un M fondamentalmente identico a quello del modello base, con altri coefficienti.

=

= =1..15

A questo punto nasce il problema della corretta valutazione della dimensione del

prodotto.

Per risolvere tale problema, ci si affida alla stima dei punti di funzione PF.

13.3 Metodo dei Punti Funzione (Albrecht)

Il metodo dei Punti Funzione (Function Point), utilizzabile soprattutto nell'ambito delle

applicazioni di tipo EDP (applicazioni commerciali tipo Basi di Dati).



- 48 -

Il valore del Punto Funzione (FP) viene calcolato a partire da alcune caratteristiche

funzionali del programma. In particolare vengono considerati cinque indici :

1) Numero di input: il numero di informazioni distinte fornite dall'utente e utilizzate

dal programma come dati di ingresso.

2) Numero di output: il numero di output distinti che il programma ritorna all'utente

come risultato delle proprie elaborazioni.

3) Numero di richieste: il numero di interrogazioni in linea che producono una

risposta immediata del sistema.

4) Numero di file: numero di file creati ed utilizzati internamente dal programma.

5) Numero di interfacce esterne: il numero dei file o di altri insiemi di dati scambiati dal

programma con altri programmi.

Il valore di FP viene poi ottenuto attraverso la seguente formula (empirica):

= (0,65 + 0,01 =1..14

)

=1..5

I valori Fi sono 14 parametri di aggiustamento che vengono calcolati in base al

questionario e ai valori (compresi tra 0 e 5) descritti nella tabella seguente, a seconda dell'

influenza che il fattore i-esimo (i = 1...14) ha nello sviluppo del programma.

0 1 2 3 4 5

Ininfluente Incidenza

scarsa

Incidenza

moderata

Incidenza

media

Incidenza

significativa

Incidenza

essenziale

I calcoli esatti per la stima dei costi per la produzione del software di ULMS riportato in

precedenza.



- 49 -

14. Progettazione dellArchitettura del software (Canzonieri Matteo, Giummarra Andrea, Roberto Fabiano)

14.1 Diagrammi delle classi Seguiranno quattro diagrammi, ognuno relativo ad un particolare attore di ULMS.

Diagramma 1: Diagramma delle classi del dominio di Impiegato



- 50 -

Diagramma 2: Diagramma delle classi del dominio di Commesso



- 51 -

Diagramma 3: Diagramma delle classi del dominio di Gestore ordini



- 52 -

Diagramma 4: Diagramma delle classi del dominio di Magazziniere



- 53 -

14.2 Diagrammi di sequenza

I seguenti diagrammi di sequenza descrivono casi duso analoghi ma compiuti da attori

differenti.

a b

c

Diagramma 5: Scelta modalit di utilizzo da parte dellimpiegato (a),

modifica modalit di utilizzo (b),

esci dal sistema (c).



- 54 -

Diagramma 6: Vendita da prenotazione da parte del commesso.

Diagramma 7: Visualizza ordine da parte del Gestore Ordini.



- 55 -

Diagramma 8: Visualizza ordine da parte del Magazziniere.

14.3 Diagrammi degli stati

Questi diagrammi illustrano come avviene la transizione di stato delle classi Prenotazione e

Ordine utilizzando per entrambi lattributo evaso (boolean che assume valori TRUE o

FALSE).

Diagramma 9: Diagramma degli stati per prenotazione e ordine.



- 56 -

14.4 Diagrammi delle attivit

Questi diagrammi illustrano le transizioni che avvengono in ULMS in seguito a

sollecitazioni esterne.

Diagramma 10: Diagramma di selezione modalit di utilizzo.



- 57 -

15. Conclusioni (Canzonieri Matteo, Giummarra Andrea, Roberto Fabiano)

ULMS, grazie alle sue funzionalit e alla sua semplicit d'utilizzo, trova larga applicazione

in tutti i contesti in cui importante una gestione ordinata di materiale cartaceo e in

particolare di libri.

Svolgendo operazioni di acquisizione e vendita di libri, nonch di gestione di magazzino,

ULMS permette la globale amministrazione centralizzata, sostituendo il ruolo fin'ora

svolto da pi soggetti fisici.

Inoltre, grazie alla funzionalit di associare ad ogni libro il corso universitario che lo

adotta, facilita all'interno stesso di un Ateneo la fruizione da parte di studenti e docenti dei

libri di testo, sia per gli acquisti che per la consultazione.

Vista l'esigenza, sempre pi in continuo accrescimento, dello scambio di materiale

didattico digitale, ULMS si propone nell'immediato futuro di aggiornare le proprie

funzionalit proiettando i suoi obiettivi verso le applicazioni dello sviluppo tecnologico.



- 58 -

16. Bibliografia

[1] Ingegneria del Software - Prof. G. Scollo

http://www.ippari.unict.it/~scollo/corsi/2006-7/is1/gsids1/it/class/html/unit_programma.html

[2] Legge Stanca http://www.diodati.org/scritti/2004/legge4_2004/

[3] Progettazioni siti web - Giacomo Coccolini www.coccolinigiacomo.it/files/strumenti_e_metodi.pdf

[4] Accessibilit di siti web - Laura Burzagli e Paolo Graziani http://www.ifac.cnr.it/smid/accesso/accesso.htm

[5] Manuale per la qualit dei siti Web pubblici culturali - Progetto MINERVA http://www.minervaeurope.org/publications/qualitycriteria-i/indice0512.html

[6] Usabilit per la comunicazione pubblica http://www.urp.it/cpusabile/index95ee.html

[7] Ingegneria del Software - Prof. G. A. Di Lucca - Dip. di Ingegneria, Univ. del Sannio http://www.ing.unisannio.it/dilucca/LSISW/materiale0405/Cocomo.pdf

[8] Ingegneria del Software - Prof.ssa Stefania Gnesi http://fmt.isti.cnr.it/~gnesi/matdid/IngSoftCap1_4.pdf

[9] Rischi, requisiti e stima di un progetto software - Roberto Meli www.dpo.it/resources/papers/1999-escom-risks-it.pdf

[10] I modelli di qualit del software - Gianluigi Raiss http://www2.cnipa.gov.it/site/_contentfiles/01379900/1379951_ISO%209126.pdf

[11] Sviluppo del SW - Scozzari http://www.sci.unich.it/~scozzari/ingsw/ingsw.pdf

[12] SSIS Ingegneria del Software - G.A. Cignoni - Dip. Di Informatica, Universit di Pisa http://www.sci.unich.it/~scozzari/ingsw/ingsw.pdf

[13] Analisi e progettazione object-oriented - Giacomo Piscitelli http://www-ictserv.poliba.it/piscitelli/doc/appunti_fi/OO_UML.pdf

[14] An Introduction to Software Architecture - David Garlan and Mary Shaw http://www.cs.cmu.edu/afs/cs/project/able/ftp/intro_softarch/intro_softarch.pdf



- 59 -

[15] An Introduction to Implicit Invocation Architectures - Benjamin Edwards http://www.mach-ii.com/resources/intro_to_implicit_invocation.pdf

[16] Software Engineering, 5th edition. Chapter 13 - Ian Sommerville http://www.mfn.unipmn.it/~giannini/ING_SW100/Lucidi/Ch_13.pdf

[17] Architetture - Ing. E. Tramontana http://www.dmi.unict.it/~tramonta/se/L9_Architetture.pdf

[18] Il metodo COCOMO per la stima dei costi di sviluppo del software - Luigi Lavazza http://webbook.cefriel.it/download/COCOMO.pdf

[19] Principi di misurazione del software - Prof.ssa Stefania Gnesi http://fmt.isti.cnr.it/~gnesi/matdid/metriche.pdf

libro

Documents

Transcript of libro