Ingegneria del Software

appuntiDiIngegneria

Ingegneria del

Software

Sommario

1.0. Ingegneria del Software ....................................................................................................................2

1.1. Software Life-Cycle............................................................................................................................5

1.2. Modello Agile SCRUM .......................................................................................................................8

1.3. Requirement Engineering ................................................................................................................ 12

1.4. Modellazione UML .......................................................................................................................... 14

1.5. Testing ............................................................................................................................................ 16

1.6. Web Services................................................................................................................................... 22

1.7. Design Patterns ............................................................................................................................... 28

1.7.1. Composite ................................................................................................................................... 31

1.7.2. Singleton ..................................................................................................................................... 32

1.7.3. Facade ......................................................................................................................................... 32

1.7.4. Factory Method ........................................................................................................................... 33

1.8. Software Architectural Patterns ...................................................................................................... 34

1.9. BPMN.............................................................................................................................................. 37

1

1.0. Ingegneria del Software

L’ingegneria del Software è un settore dell’informatica che riguarda la costruzione di sistemi SW

di dimensione e complessità tale da richiedere il lavoro di un gruppo numeroso di persone anche

sparse per il mondo.

La figura del Software Engineer nasce per fissare le metodologie di sviluppo del SW, cioè per dare

delle regole e rendere sistematico lo sviluppo del SW come prodotto. Infatti, il SW non è solo

codice, ma è l’insieme dei programmi, delle procedure, dell’eventuale documentazione associate e

dei dati relativi all’operatività di un sistema di elaborazione. Un approccio più sistematico è

importante in quanto il SW è:

 Prodotto invisibile, intangibile, facilmente duplicabile, opera dell’ingegno e protetto da

leggi;

 Componente di un sistema di elaborazione: può essere di larga diffusione (off the shelf) o

commissionato da un singolo committente;

 Macchina astratta: offre funzioni utili per qualche scopo, ha un’architettura (fatta di

componenti e connettori);

 Servizio: ha un’interfaccia e si basa su una infrastruttura.

Passando a sistemi SW complessi, entreranno in gioco nuove problematiche, ad esempio:

 Multi-Version: lo stesso prodotto deve essere rilasciato in diverse versioni, in quanto lo

stesso SW potrebbe essere utilizzato su dispositivi diversi (e.g. il programma di gestione

della parte elettronica di un auto, avrà versioni differenti per ogni categoria di auto);

 Multi-Person: tante persone sparse per il mondo sviluppano versioni differenti dello stesso

SW. 2

L’ingegneria del software è una disciplina stratificata:

La base di qualunque strategia ingegneristica, quindi anche quella del processo di sviluppo del

software, è l’Attenzione alla Qualità. Subito al di sopra della “attenzione alla qualità”, vi è lo

strato del “Processo di Sviluppo del SW”, che definisce una serie di passi prevedibili che

permettono di ottenere risultati di alta qualità nel tempo prefissato; il Processo è importante

perché introduce stabilità, controllo ed organizzazione in un’attività che se lasciata libera potrebbe

diventare molto caotica. Il Processo, nella sua forma più generale, è costituito da 5 fasi principali:

1) Comunicazione (Communication): riguarda le comunicazioni e la collaborazione con il

cliente/stakeholder, e include la raccolta dei requisiti e altre attività correlate.

2) Pianificazione (Planning): stabilisce un piano per il successivo lavoro di ingegneria del

software. Descrive le operazioni da svolgere, i rischi del progetto, le risorse necessarie, i

prodotti da realizzare e una pianificazione del lavoro.

3) Modellazione (Modelling): include la creazione di modelli che consentono allo

sviluppatore e al cliente di comprendere meglio i requisiti software e progettuali. Si divide

in due sotto-attività:

o Analisi dei requisiti (Analysis of Requirements): raccolta, elaborazione,

negoziazione, specifica e convalida dei requisiti che conducono alla creazione del

modello analitico e/o alla specifica dei requisiti.

o Progettazione (Design): comprende la progettazione dei dati, la progettazione

dell’architettura, la progettazione dell’interfaccia, la progettazione dei componenti.

Viene creato un modello progettuale e/o una specifica del progetto.

4) Costruzione (Construction): Costruzione del codice e attività di collaudo per trovare

eventuali errori.

5) Rilascio (Deployment): il software viene consegnato al cliente, che valuta il prodotto.

Queste 5 fasi prendono il nome di attività strutturali, le quali sono composte da un insieme di

azioni, ovvero da un insieme di operazioni correlate che determinano un “prodotto”. Ogni azione

3

a sua volta è costituita da singole attività. Vi sono anche attività ombrello che coprono tutte le

varie attività strutturali facendone da contorno, come ad esempio la gestione della qualità.

Lo strato “Metodi” definisce le metodologie, ovvero, tutto il sapere tecnico usato per le varie fasi

della costruzione del SW, I metodi includono diverse attività come l’analisi dei requisiti, la

progettazione, la costruzione del programma, il test e il supporto. Infine, in cima abbiamo lo strato

“Strumenti”, essi forniscono al Processo e ai Metodi un supporto automatizzato per la risoluzione

dei problemi. Per descrivere un attività del Processo, un compito di una sua attività o l’intero

Processo, occorre definire dei Modelli di Processo, dei quali sono ben note due grandi categorie:

 Modelli a Processo Prescrittivi: si tratta dei modelli di sviluppo SW tradizionali che sono

definiti in contesti industriali chiari, in cui sia il cliente che chi sviluppa il SW, hanno chiara

comprensione del Processo. prescrivono un insieme di elementi del processo (attività, azioni,

compiti, risultati e prodotti) e un flusso di lavoro, e vengono descritti in modo rigido e

schematico. Il flusso di processi può essere

o lineare (modello a cascata);

o incrementale (modello incrementale e modello RAD);

o evolutivo (modello a prototipi, modello a spirale e modello di sviluppo

concorrente).

 Modelli di Processo Agile: l’insoddisfazione per l’eccessivo overhead richiesto dai tradizionali

approcci allo sviluppo software ha portato negli anni 90 all’introduzione di questi modelli. Essi:

o Usano un approccio iterativo (ed interattivo) che consente di apportare agilmente

modifiche al progetto;

o A differenza dei modelli prescrittivi propongono un approccio meno strutturato e

sono pensati per rilasciare software funzionante e di qualità rapidamente e

4

frequentemente early delivery/frequent delivery), e per farlo evolvere

rapidamente per soddisfare nuove esigenze;

o Non usano l’approccio classico e lineare di progettazione dei modelli prescrittivi; il

loro approccio consiste nel realizzare un progetto per fasi, chiamate “sprint”,ad

ognuno dei quali corrisponde una nuova funzionalità e viene verificata la

soddisfazione del cliente.

1.1. Software Life-Cycle

Il Software Engineer deve occuparsi di regolamentare il “Ciclo di Vita“ di un prodotto software,

ovvero l'insieme delle attività da svolgere per la sua realizzazione, dall‘analisi dei requisiti utente

fino alla manutenzione dopo il rilascio. Il ciclo di vita di un software designa tutte le varie fasi della

vita di un software, dalla sua concezione al suo ritiro. Il modello di base è il Waterfall Model

(Modello a Cascata), descritto nella figura sottostante:

Requirements Analysis: si occupa del COSA, cioè lo scopo è quello di definire (il più

precisamente possibile) il problema da risolvere; più precisamente in questa fase si vanno a

determinare i requisiti, le informazioni da elaborare, le funzioni, le prestazioni attese, il

comportamento del sistema, le interfacce, vincoli progettuali e i criteri di validazione.

Questa fase comprende anche lo Studio di Fattibilità.

Design: è la fase di progettazione nel quale ci si occupa del COME, cioè di definire (a un

certo livello di dettaglio) la soluzione del problema. Più precisamente in questa fase ci si

occupa della definizione del progetto, dell’architettura software, della strutturazione dei

dati e delle interfacce, dei dettagli procedurali. In questa fase sarà sviluppato un

documento che permetterà di avere una definizione della architettura di alto livello. 5

Implementation: in questa fase ci si dedica alla traduzione del progetto nel linguaggio di

programmazione, quindi è la vera e propria fase di coding/develop.

Testing: è la fase di collaudo, che consiste nella verifica e validazione di quanto il prodotto

software implementato soddisfi i requisiti individuati dall'analisi.

Deployment: una volta che il software ha superato con successo le verifiche della fase di

collaudo, esso viene pubblicato in una versione definitiva e messo a disposizione, secondo

le regole della specifica licenza d'uso prescelta, di chiunque o dei soli acquirenti.

Maintenance: in questa fase ci si occupa delle modifiche, delle correzioni, adattamenti,

miglioramenti, prevenzione.

Il Waterfall Model è il modello di base storico, estremamente semplice, che prevede un approccio

sistematico e sequenziale allo sviluppo del SW. Tale modello non prevede retroazioni, quindi ogni

fase deve essere svolta in maniera esaustiva prima di passare alla successiva. Tale modello è poco

indicato per progetti reali, in quanto:

 Devono essere previste delle retroazioni, perché ad esempio il cliente potrebbe cambiare

idea su quello che vuole e si devono ridefinire i requisiti, oppure i requisiti del cliente

potrebbero essere ambigui o sbagliati;

 Il cliente deve attendere il compimento dell’ultima fase per poter vedere una versione

funzionante del SW commissionato;

 Se una fase si blocca, saranno bloccate anche quelle successive, rendendo impossibile la

terminazione del progetto in tempi rapidi.

Per questi motivi sono stati definiti altri modelli prescrittivi più sofisticati:

Modello a Processo Incrementale: prevede

l’applicazione, scalata nel tempo, di più modelli a

cascata. Il primo di essi definisce un prodotto

base che soddisfa solo i requisiti fondamentali,

poi man mano nelle successive iterazioni

vengono aggiunti nuovi dettagli che raffinano il

prodotto base in maniera incrementale. Tale

modello risulta molto utile quando i tempi di

consegna sono moto stretti, e quindi invece del

prodotto finale al cliente è possibile consegnare

un prodotto intermedio. 6

Modello RAD (Rapid Application Development):

Adattamento ad alta velocità del modello a

cascata. Nella pianificazione si identificano i

moduli che compongono il Processo, ogni team

lavora su uno di essi e alla fine si integra il tutto.

Il problema principale è quello dell’eventuale

incompatibilità dei moduli e un dispendio delle

risorse umane impiegate nel team

Modello Evolutivo a Prototipi: il modello è

iterativo, ovvero ripetiamo n volte le stesse fasi.

L’obiettivo è costruire un prototipo che serve per

controllare se le scelte di

modellazione\progettazione erano giuste,

dopodiché quest’ultimo si può anche buttare

(throw away prototype), oppure riusare per

perfezionare i requisiti (revolutionary

prototype). Il cliente deve valutare il prototipo

dando un feedback, necessario ad aggiornare i

requisiti del prodotto da sviluppare. Il problema è

che a volte gli sviluppatori devono realizzare

rapidamente un prototipo a discapito della

qualità.

Modello Evolutivo a Spirale: è un modello

astratto che combina gli aspetti dei modelli

iterativi con gli aspetti prescrittivi dei modelli a

cascata. Il team di sviluppo esegue diverse fasi: le

prime servono a creare prototipi da proporre al

cliente, quelle successive per svolgere

funzionalità intermedie e perfezionare il prodotto

già finito. 7

Modello di Sviluppo Concorrente: ogni attività si

trova in un suo stato, e tutte coesistono

contemporaneamente, in tal modo tutte le fasi

possono essere portate avanti lavorando su

attività diverse, rispettando la dipendenza tra

queste ultime.

Processo Unificato: Si tratta di un modello di

processo guidato dai casi d'uso, basato

sull'architettura, iterativo e incrementale. Ha le

migliori funzionalità e caratteristiche dei modelli

convenzionali dei modelli di processo canonici,

ma incorpora anche molti principi dello sviluppo

agile. Incoraggia i casi d'uso perché è riconosciuta

l'importanza della comunicazione con il cliente e

del suo punto di vista nei confronti del sistema.

Tale modello unifica tutti i modelli visti in un

modello standardizzato che si basa sull’UML.

1.2. Modello Agile SCRUM

Quando si lavora in progetti in cui c’è una continua variazione di requisiti, clienti, condizioni di

mercato, e si ha necessità di rilasciare presto e frequentemente una milestone al cliente si usano i

modelli Agili. Le metodologie Agili, come dice il Manifesto Agile del 2001, vengono privilegiati: 8

Fra i modelli Agili più diffusi abbiamo: Extrem Programming (XP), DSDM, e SCRUM. Quest’ultimo

è il Modello Agile più diffuso, particolarmente indicato per progetti complessi ed innovativi. Si

tratta di un modello di processo per produrre software ottenendo il massimo valore utile nel

minor tempo. Esso è un framework, che divide il processo di gestione di un progetto in sprint per

coordinare il processo di sviluppo del prodotto con le esigenze del committente/cliente. Il cliente

definisce funzioni da realizzare e loro priorità, mentre il team di sviluppo decide quotidianamente

il modo migliore di produrre le funzioni di più alta priorità. Si tratta di un processo iterativo in cui

gli sprint durano da 2 a 4 settimane. Tale modello, permette al cliente di ispezionare rapidamente

e ripetutamente ogni 3-4 settimane versioni funzionanti del software, in quanto ogni 3-4

settimane nasce una nuova versione che viene esaminata per decidere se continuarne lo sviluppo

con un altro sprint o produrne un rilascio. Un processo SCRUM è costituito da una serie di sprint di

durata costante (2-4 settimane o un mese al massimo), ogni sprint estrae funzioni “Ready” dal

product backlog e aggiunge codice “Done” al prodotto da mostrare al cliente.

Le componenti principali di SCRUM si dividono in: ruoli, rituali ed artefatti. I Ruoli definiti in

SCRUM sono tre, ed essi lavorano in stretta connessione per assicurare un continuo e veloce flusso

di informazioni:

 PRODUCT OWNER: colui che conosce tutti i requisiti del prodotto e porta avanti gli

interessi di tutti gli stakeholder. Esso rappresenta l’interfaccia tra il business, i clienti e i

requisiti del prodotto da un lato e il team dall’altro. Deve massimizzare il valore del

prodotto e del lavoro svolto dal Team di Sviluppo.

 SCRUM MASTER: il responsabile del processo, colui che deve garantire che la metodologia

Scrum venga compresa ed eseguita con successo. Deve accertarsi che il team lavori in

maniera coerente con lo sviluppo del progetto, eliminando eventuali ostacoli esterni allo

9

Scrum Team che potrebbero avere impatto sulla produttività, e deve organizzare e

facilitare i meeting di confronto.

 TEAM DI SVILUPPO: il gruppo di professionisti cross-funzionali ed auto-organizzato, il cui

numero di solito si mantiene da 5 a 9. Si occupa dello sviluppo del prodotto e del testing

delle funzionalità, e ha la responsabilità di organizzare le priorità trasformandole in task da

completare per portare a termine un determinato sprint.

Invece sono ben 4 i Rituali formali utilizzati in SCRUM (con durata prefissata) per creare regolarità,

sincronizzare le attività e ridurre al minimo la necessità di incontri non definiti. L’obiettivo di questi

eventi è consentire trasparenza critica ed ispezione sull’andamento del progetto.

 SPRINT PLANNING: la riunione in cui il Product Owner ha

stilato il Product Backlog e, in presenza del Team di Sviluppo

e dello Scrum Master, descrive gli item più importanti e

l’obiettivo da raggiungere nello sprint seguente, cioè descrive

“cosa fare” (sprint backlog) e come aggiornare il prodotto

(product backlog). Al termine della riunione lo Scrum Master

può compilare lo Sprint Backlog. La durata è di 8 ore divise in

due parti da 4, nella prima parte partecipano sia pigs che

chicken, mentre nella seconda parte partecipa solo il Team e

lo Scrum Master.

 DAILY SCRUM (STAND UP MEETING): un breve confronto giornaliero

(della durata di 15 min) fra Team di Sviluppo e lo Scrum Master, il

quale annota il lavoro svolto il giorno precedente e crea un piano per

le prossime 24 ore (fino al p