Che materia stai cercando?

Ingegneria del software

Appunti di ingegneria del software basati su appunti personali del publisher presi alle lezioni del prof. Ferrucci dell’università degli Studi di Salerno - Unisa, della facoltà di Scienze matematiche fisiche e naturali. Scarica il file in formato PDF!

Esame di Ingegneria del software docente Prof. F. Ferrucci

Anteprima

ESTRATTO DOCUMENTO

10.2.1 ACTIVITY DIAGRAM ................................................................................................................................ 24

11 CLASS DIAGRAM ................................................................................................................................................. 25

11.1 GLI OGGETTI E LE CLASSI ............................................................................................................................. 25

11.1.2 ATTRIBUTI .................................................................................................................................................. 26

11.1.3 OPERAZIONI ............................................................................................................................................... 26

RESPONSABILITA’

11.1.4 .................................................................................................................................... 26

VISIBILITA’.................................................................................................................................................

11.1.5 26

MOLTEPLICITA’

11.1.6 ........................................................................................................................................ 26

11.1.7 RELAZIONI ................................................................................................................................................. 27

11.2 COSTRUZIONE DI UN CLASS DIAGRAM ..................................................................................................... 28

12 SYSTEM DESIGN .................................................................................................................................................. 28

12.1 OUTPUT .............................................................................................................................................................. 28

ATTIVITA’ DEL SYSTEM

12.2 DESIGN ................................................................................................................. 29

12.3 PRODOTTI DEL SYSTEM DESIGN ................................................................................................................. 29

12.4 IDENTIFICARE GLI OBIETTIVI DI DESIGN .................................................................................................. 29

12.4 CRITERI DI DESIGN .......................................................................................................................................... 29

12.4.1 CRITERI DI PERFORMANCE .................................................................................................................... 29

12.4.2 CRITERI DI DEPENDABILITY ................................................................................................................. 29

12.4.3 CRITERI DI COSTO .................................................................................................................................... 29

CRITERI DELL’UTENTE

12.4.5 FINALE ............................................................................................................ 30

12.5 DESIGN TRADE-OFF ..................................................................................................................................... 30

12.6 CONCETTI DEL SYSTEM DESIGN .............................................................................................................. 30

12.6.1 I SOTTOSISTEMI ........................................................................................................................................ 30

12.7 COESIONE E ACCOPPIAMENTO ................................................................................................................. 30

12.8 LAYERS E PARTIZIONI................................................................................................................................. 31

12.8.1 BASIC LAYER PATTERN .......................................................................................................................... 31

12.9 ARCHITETTURE............................................................................................................................................. 31

12.9.1 ARCHITETTURA A REPOSITORY ........................................................................................................... 31

12.9.2 ARCHITETTURA MODEL/VIEW/CONTROLLER .................................................................................. 32

12.9.3 ARCHITETTURA CLIENT/SERVER ......................................................................................................... 32

12.9.4 ARCHITETTURA PEER-TO-PEER ............................................................................................................ 32

12.9.5 ARCHITETTURA THREE-TIER................................................................................................................. 32

12.10 SCELTA DEI SOTTOSISTEMI ....................................................................................................................... 33

ATTIVITA’ DEL SYSTEM

12.11 DESIGN .............................................................................................................. 33

12.11.1 MAPPARE I SOTTOSISTEMI SU PIATTAFORME E PROCESSORI .................................................. 33

12.11.3 STABILIRE I CONTROLLI DI ACCESSO ............................................................................................. 34

12.11.4 PROGETTARE IL FLUSSO DI CONTROLLO GLOBALE ................................................................... 35

12.11.5 IDENTIFICARE LE CONDIZIONI LIMITE ........................................................................................... 35

12.11.6 RIVEDERE IL MODELLO DI SYSTEM DESIGN ................................................................................. 35

12.11.7 GESTIONE DEL SYSTEM DESIGN ....................................................................................................... 36

13 OBJECT DESIGN .................................................................................................................................................... 36

Pag. 3 a 57

13.1 CONCETTI ....................................................................................................................................................... 36

13.1.1 RIUSO........................................................................................................................................................... 36

13.1.2 INTERFACCE .............................................................................................................................................. 37

13.1.3 RISTRUTTURAZIONE ............................................................................................................................... 37

13.1.4 OTTIMIZZAZIONE ..................................................................................................................................... 37

ATTIVITA’ DI OBJECT

13.2 DESIGN ................................................................................................................... 37

13.3 SPECIFICA DELLE INTERFACCE ................................................................................................................ 37

13.3.1 TIPI E SIGNATURE .................................................................................................................................... 37

13.3.2 INFORMAZIONI SULLA VISIBILITA’ ..................................................................................................... 37

GESTIONE DELL’OBJECT

13.4 DESIGN ............................................................................................................. 38

13.5 JAVADOC ........................................................................................................................................................ 39

13.6 CONCETTI DI RIUSO ..................................................................................................................................... 39

13.6.1 OGGETTI DI APPLICAZIONE E OGGETTI DI SOLUZIONE.................................................................. 39

EREDITARIETA’ DI SPECIFICA DI IMPLEMENTAZIONE

13.6.2 ED EREDITARIETA’ .............................. 40

13.6.3 DELEGAZIONE ........................................................................................................................................... 40

13.6.4 PRINCIPIO DI SOSTITUZIONE DI LISKOV............................................................................................. 40

13.7 DESIGN PATTERN ......................................................................................................................................... 40

13.7.1 CLASSIFICAZIONE .................................................................................................................................... 40

13.7.2 COMPOSITE PATTERN ............................................................................................................................. 41

13.7.3 FAÇADE PATTERN .................................................................................................................................... 41

13.7.4 ADAPTER PATTERN.................................................................................................................................. 41

13.7.5 BRIDGE PATTERN ..................................................................................................................................... 41

13.7.6 PROXY PATTERN ...................................................................................................................................... 42

13.7.7 OBSERVER PATTERN ............................................................................................................................... 42

13.7.8 ABSTRACT PATTERN ............................................................................................................................... 42

13.7.9 COME USARE I DESIGN PATTERN ......................................................................................................... 43

14 MAPPING TO CODE............................................................................................................................................... 43

14.1 TRASFORMAZIONI........................................................................................................................................ 43

14.1.1 TRASFORMAZIONI DI MODELLO .......................................................................................................... 43

14.1.2 REFACTORING ........................................................................................................................................... 43

14.1.3 FORWARD ENGINEERING ....................................................................................................................... 44

14.1.4 REVERSE ENGINEERING ......................................................................................................................... 44

14.1.5 PRINCIPI DI TRASFORMAZIONE ............................................................................................................ 44

ATTIVITA’ DEL MAPPING

14.2 ........................................................................................................................... 44

14.2.1 OTTIMIZZARE IL MODELLO DI OBJECT DESIGN ............................................................................... 44

14.2.2 MAPPARE LE ASSOCIAZIONI IN COLLEZIONI .................................................................................... 45

14.2.3 MAPPARE CONTRATTI IN ECCEZIONI .................................................................................................. 45

MAPPARE L’OBJECT MODEL

14.2.4 IN UNO SCHEMA DI MEMORIZZAZIONE PERSISTENTE .............. 46

DI EREDITARIETA’

14.2.4 MAPPARE LE RELAZIONI .................................................................................... 46

GESTIRE L’IMPLEMENTAZIONE

14.2.5 E LE RESPONSABILITA’................................................................ 47

15 TESTING .................................................................................................................................................................. 47

Pag. 4 a 57

15.1 OVERVIEW ..................................................................................................................................................... 47

15.1.1 TEST E CASI DI TEST ................................................................................................................................ 48

15.1.2 ORACOLO ................................................................................................................................................... 48

15.1.3 TESTING ESAUSTIVO ............................................................................................................................... 49

15.2 CONCETTI DI TESTING ................................................................................................................................ 49

15.2.1 CORREZIONI............................................................................................................................................... 50

15.3 MANAGING TESTING ................................................................................................................................... 50

ATTIVITA’ DI TESTING

15.4 ................................................................................................................................ 51

15.4.1 COMPONENT INSPECTION .......................................................................................................................... 51

15.4.2 USABILITY TESTING .................................................................................................................................... 52

15.4.3 UNIT TESTING................................................................................................................................................ 52

15.4.4 INTEGRATION TESTING .............................................................................................................................. 54

15.4.5 SYSTEM TESTING ......................................................................................................................................... 55

15.4.6 FUNCTIONAL TESTING ................................................................................................................................ 55

15.4.7 PERFORMANCE TESTING ............................................................................................................................ 55

15.4.8 PILOT TESTING .............................................................................................................................................. 55

15.4.9 ACCEPTANCE TESTING ............................................................................................................................... 56

15.4.10 INSTALLATION TESTING .......................................................................................................................... 56

15.5 GESTIRE IL TESTING ........................................................................................................................................... 56

15.6 CATEGORY PARTITION ...................................................................................................................................... 56

Pag. 5 a 57

1 PRODUZIONE SOFTWARE: EVOLUZIONE

L’arte sono tutte quelle applicazioni sviluppate da singole persone e utilizzate dagli stessi sviluppatori. All’artigianato

appartengono le applicazioni sviluppate da piccoli gruppi specializzati per un cliente; L’industria invece prevede la diffusione

del software in diversi settori: crescita di dimensioni, complessità e criticità delle applicazioni.

Un programma si differisce da un prodotto software dalle persone che lo utilizzano; il primo viene utilizzato dall’au-

tore (utente=autore), non è documentato, quasi mai vi è un progetto e una fase di testing; il secondo viene usato da persone

diverse da chi lo ha sviluppato.

Molto spesso la produzione di un prodotto software ha costi elevati, dovuti alle risorse umane, ore di lavoro, hard-

ware, software e risorse di supporto. Il testing impiega fino al 50% dei costi di sviluppo, questi ultimi vengono incrementati

se dopo il rilascio del software vi è una fase di manutenzione. Anche se vengono impiegati diversi mesi per la sua produzione,

il software è spesso inaffidabile e per questo necessita di applicare principi ingegneristici per sviluppare il giusto prodotto, al

costo giusto, nel tempo giusto e con la giusta quantità. Per un efficace sviluppo software è necessario conoscere il contesto

“dominio applicativo”.

in cui ci muoveremo, il cosiddetto

2 FONDAMENTI DELL’INGEGNERIA DEL SOFTWARE

L’ingegneria del software si occupa dei metodi, delle metodologie, dei processi, degli strumenti per la gestione pro-

fessionale. Lo sviluppo di un software (metodologia) non cambia se cambiano gli strumenti a disposizione.

Il concetto primitivo per antonomasia è il rigore, primitivo poiché non si può definire; oltre il rigore troviamo la

formalità, cioè basandosi su leggi matematiche; separare i diversi aspetti; modularità, suddividere un sistema complesso in

parti più semplici; astrazione, indentificare gli aspetti cruciali in un certo istante, ignorando gli altri; anticipare il cambia-

mento, favorire in qualche modo l’evoluzione del sw; generalità, tentare di essere quanto più generici per favorire la riusabi-

lità; incrementalità, lavorare a piccoli passi.

2.1 METODI E METODOLOGIE

Un metodo è un procedimento generale per risolvere classi di problemi specificati di volta in volta, una sorta di linee

guida o regole che governano le attività. Una metodologia, invece, è un insieme di principi, metodi, elementi di cui una o più

discipline si servono per garantire la correttezza e l’efficacia del proprio procedere. Molto spesso ci vengono in aiuto gli

strumenti per fare qualcosa in modo migliore. Una combinazione di strumenti viene chiamata procedura, che insieme per-

mettono di produrre un certo prodotto. Un paradigma invece è un particolare approccio o filosofia per fare qualcosa.

2.2 PROCESSI

Un processo è un particolare modo di fare qualcosa, costituito da una sequenza di passi che svolgono attività, vincoli

e risorse. Un processo software è un insieme organizzato di attività che sovrintendono alla costruzione del prodotto da parte

del team di sviluppo utilizzando metodi, tecniche, metodologie e strumenti. Viene diviso in varie fasi secondo uno schema

di riferimento, il ciclo di vita del software. Viene descritto da un modello che può essere informale, semi-formale o formale.

3 IL CICLO DI VITA DEL SOFTWARE

Il cvs è il periodo che inizia quando un prodotto software viene concepito e finisce quando il prodotto non è più in

uso. Il cvs include tipicamente una fase concettuale, una fase di raccolta dei requisiti, una fase di design, una fase di imple-

mentazione, una fase di test, l’installazione e controllo, manutenzione e, alcune volte il ritiro. Spesso le fasi sono svolte in

maniera disordinata e posso essere sovrapposte. Il cvs differisce dal ciclo di sviluppo del software poiché non è presente la

fase di manutenzione.

3.1 MODELLI DI CVS

Un modello di cvs è una caratterizzazione descrittiva o prescrittiva di come un sistema software viene o dovrebbe

essere sviluppato, in alcuni casi ci impone delle regole di sviluppo. I modelli di processo sono precise e formalizzate descri-

zioni di dettaglio delle attività, degli oggetti, delle trasformazioni e degli eventi che includono strategie per realizzare e

ottenere l’evoluzione software. Ne esistono di diversi di modelli, nati o scoperti negli ultimi 40 anni. Molti aspetti ne influen-

zano la definizione dei modelli.

3.2 FASI DI UN CVS Pag. 6 a 57

“del

La definizione si occupa cosa”, di quello che serve senza il dettaglio di come deve essere realizzato; lo sviluppo

“del

si occupa come”, il processo con il quale deve essere realizzato in modo da poter strutturare i dati, le interfacce e la

traduzione del progetto nel linguaggio di programmazione scelto. La manutenzione, infine, si occupa delle correzioni e gli

adattamenti per mantenere in vita il sw.

3.3 MODELLO A CASCATA

Gli anni ’70 sono passati alla storia per la crisi del software, in cui i prodotti non venivano consegnati oppure conse-

gnati in ritardo, con la conseguente qualità scadente del software e bassi costi di produzione. Proprio in quegli stessi anni

Royce ideò il modello a cascata come reazione al “code e ispirato dall’industria manifatturiera. È definito come un

and fix”

modello sequenziale lineare: progressione sequenziale di fasi, senza ricicli al fine di meglio controllare tempi e costi. Defi-

nisce e separa le varie fasi e attività del processo in modo tale da

rendere nullo o minimo l’overlap fra le fasi. Prevede delle uscite in-

termedie, una sorta di semilavorati del processo, prodotti dopo ogni

fase corredati da documentazione cartacea, e consente anche un con-

trollo dell’evoluzione del processo.

Ogni fase raccoglie un insieme di attività omogenee per me-

todi, tecnologie, skill del personale ed è caratterizzata dalle attività,

dai prodotti di tali attività (deliverables), dai controlli relativi. La

fine di ogni fase è definita milestone, un punto rilevante del processo.

I semilavorati output di ogni fase, sono input alla fase successiva. I

prodotti di una fase vengono congelati, ovvero non sono più modificabili se non formale e sistematica modifica.

fasi alte, che comprendono lo studio di fattibilità, l’analisi

Le fasi del modello a cascata vengono suddivise in dei

requisiti, la progettazione, e in fasi basse, lo sviluppo e test di unità, integrazione e test di sistema, il deployment e la manu-

tenzione.

3.3.1 STUDIO DI FATTIBILITA’

Per studio di fattibilità intendiamo la valutazione preliminare di costi e benefici (cost-effectiveness). Varia a seconda

della relazione committente/produttore ed ha come obiettivi stabilire se avviare il progetto, individuare le possibili opzioni e

le scelte più adeguate, valutare le risorse umane e finanziare necessarie. Questa prima fase produce come output il documento

di fattibilità, nel quali sono definite preliminarmente le caratteristiche del sistema, gli scenari e le strategie alternative di

soluzione, i costi, i tempi e le modalità di sviluppo per ogni alternativa.

3.3.2 ANALISI DEI REQUISITI

Per analisi dei requisiti intendiamo l’analisi completa dei bisogni dell’utente e del dominio del problema. Spesso

sw. L’obiettivo è descrivere le funzionalità e le caratteristiche di

vengono coinvolti sia il committente che gli ingegneri del

qualità che l’applicazione deve soddisfare (requisiti funzionali e non funzionali). Questa fase ha come output la stesura del

documento di specifica dei requisiti, accompagnato dal manuale utente, il quale dovrà essere corretto, completo, non ambiguo

e consistente, e il piano di acceptance test del sistema.

3.3.3 PROGETTAZIONE

Con la fase di progettazione si definisce una struttura opportuna per il sw tramite la scomposizione del sistema in

componenti e moduli, allocando le funzionalità ai vari moduli e definendo delle relazioni tra questi ultimi. L’obiettivo è come

si deve procedere, a differenza dell’analisi in cui viene descritto cosa bisogna fare. L’output di questa fase è il documento di

specifica di progetto in cui è possibile usare linguaggi e/o formalismi per la progettazione.

3.3.4 FASI BASSE DEL PROCESSO

Con fasi basse vengono definite tutte quelle fasi che vanno oltre la progettazione. Per programmazione e test di unità

si intende la fase in cui ogni modulo viene codificato nel linguaggio scelto e testato in isolamento. Per integrazione e test di

sistema viene identificata quella fase in cui ogni modulo nel sistema globale viene scomposto, viene verificato il corretto

del sistema e rilasciato quest’ultimo in due modalità: α-test, con il rilascio all’interno del produttore, e β-test,

funzionamento

con il rilascio a pochi e selezionati utenti. La distribuzione e gestione del software presso l’utenza vengono definiti de-

quest’ultimo la manutenzione, l’ultima fase prima di un eventuale ritiro del software, in cui vi è un’evolu-

ployment. Segue

zione del sistema, seguendo le esigenze dell’utenza; comporta ulteriore sviluppo per cui racchiude in sé nuove iterazioni di

tutte le precedenti fasi. Pag. 7 a 57

3.3.5 PRO E CONTRO

Importanti in questo modello sono i vantaggi offerti, poiché è stato il primo modello con cui si sono definiti molti

concetti utili (semilavorati, fasi, ecc.); ha rappresentato un punto di partenza importante per lo studio dei processi sw, ed è

facilmente applicabile e comprensibile. Per contro l’interazione con il cliente l’abbiamo solo all’inizio e alla fine e il nuovo

sistema sw diventa installabile solo quando è totalmente finito.

3.4 VARIANTI AL MODELLO A CASCATA

Dopo la nascita del modello a cascata, numerosi sono stati altri modelli che hanno ripreso o cambiato alcune meto-

dologie del primo modello di sviluppo, spesso sono modelli derivati dalle critiche, ovviando il problema dell’instabilità dei

l’esistenza dei ricicli e dando maggiore enfasi sulla manutenzione.

requisiti, tenendo in considerazione

3.4.1 MODELLO FEEDBACK: V&V E RETROAZIONE Con il modello feedback vengono introdotte la verifica e la

convalida. Per verifica intendiamo lo stabilire la verità della corri-

spondenza tra un prodotto software e la sua specifica (stiamo co-

struendo il prodotto giusto?). Per convalida intendiamo lo stabilire

l’appropriatezza di un prodotto software rispetto alla sua missione

operativa (stiamo costruendo il giusto prodotto?). Una novità intro-

dotta con questo modello è il riciclo delle fasi a partire da qualsiasi

altra fase, cioè i feedback posso essere inviati ad una qualsiasi delle

fasi precedenti.

3.4.2 MODELLO A V

Il modello a V è simile al modello a cascata, solo che le fasi alte e

basse del progetto ruotano intorno alla codifica. Le attvità di sinistra sono

collegate a quelle di destra. Se si trova un errore in una fase di destra si

riesegue il pezzo della V collegato. Si può iterare migliorando requisiti,

progetto e codice.

3.4.3 MODELLO BASATO SU PROTOTIPAZIONE

Un prototipo può aiutare a comprendere i requisiti o per valutare la fattibilità di un approccio. La realizzazione di

una prima implementazione più o meno completa, può considerarsi come una prova con lo scopo di accettare la fattibilità del

prodotto e validare i requisiti. Il prototipo è un mezzo attraverso il quale si interagisce con il committente per accertarsi di

aver ben compreso le sue richieste, per specificare meglio tali richieste, per valutare la fattibilità del prodotto. Dopo la fase

di utilizzo del prototipo si passa alla produzione della versione definitiva del sistema sw mediante un modello che, in generale,

dell’interfaccia utente,

è di tipo waterfall. I prototipi vengono suddivisi in due categorie: mock-ups: produzione completa

consente di definire con completezza e senza ambiguità i requisiti (si può, già in questa fase, definire il manuale di utente);

breadboard: implementazione di sottoinsiemi di funzionalità critiche del SS, non nel senso della fattibilità ma in quello dei

vincoli pesanti che sono posti nel funzionamento del SS (carichi elevati, tempo di risposta, ...), senza le interfacce utente,

produce feedback su come implementare la funzionalità (in pratica si cerca di conoscere prima di garantire). Esistono poi due

tipi di prototipazione: prototipazione “throw-away” che consente di pervenire ad una migliore comprensione dei requisiti del

prodotto da sviluppare e lo sviluppo dovrebbe avviarsi con la parte dei requisiti meno compresa; poi vi è la prototipazione

“esplorativa” che consente di pervenire ad un prodotto finale partendo da una descrizione di massima e lavorando a stretto

contatto con il committente; lo sviluppo dovrebbe avviarsi con la parte dei requisiti meglio compresa.

3.5 SVILUPPO EVOLUTIVO

Spesso l’evoluzione di un prodotto software può avere diversi problemi: la perdita di visibilità del processo, spesso

il prodotto finito è scarsamente strutturato, sono richieste competenze specifiche nell’uso di linguaggi di prototipazione rapida

(RAD), perdita di visibilità del processo da parte del management. I modelli finora descritti si applicano per sistemi interattivi

che sconvolge poco l’architettura iniziale, si possono applicare per parti di sistemi più grandi

di taglia medio-piccola, oppure

per sistemi con un ciclo di vita breve. Lo sviluppo viene visto come una sequenza di passi che trasformano formalmente una

specifica in una implementazione. Formalmente perché bisogna definirlo con una sintassi e semantica ben definita. I requisiti

Pag. 8 a 57

sono sempre soggetti a modifiche nel corso dello sviluppo del prodotto. Questo comporta iterazioni soprattutto nelle fasi

iniziali. Abbiamo due approcci correlati: sviluppo incrementale e a spirale.

3.5.1 SVILUPPO INCREMENTALE

la difficoltà a produrre l’intero sistema in una sola volta nel caso di grandi progetti

Lo sviluppo incrementale risolve

sw. Le difficoltà posso essere sia del produttore che del committente. Quest’ultimo potrebbe non avere l’immediata disponi-

bilità finanziaria necessaria per l’intero progetto, quindi il prodotto viene consegnato con più rilasci. Con lo sviluppo incre-

mentale si ha la possibilità di anticipare da subito delle funzionalità al committente, quindi vi è un minor rischio di un com-

pleto fallimento del progetto; il testing è più esaustivo poiché i rilasci agiscono come prototipi e consentono di individuare i

requisiti per i successivi incrementi ed i servizi a più alta priorità vengono maggiormente testati.

3.5.2 SVILUPPO ITERATIVO

Entrambi gli sviluppi sono accomunati dal prevedere più versioni successive del sistema. Ad ogni istante dopo il

rilascio esiste un sistema versione N in esercizio ed un sistema versione N+1 in sviluppo. Con lo sviluppo incrementale ad

ogni versione di aggiungono nuove funzionalità, mentre con lo sviluppo iterativo/evolutivo, da subito sono presenti tutte le

funzionalità che vengono successivamente raffinate e migliorate.

3.6 EXTREME PROGRAMMING

L’XP è un approccio recente nello sviluppo del software basato su iterazioni veloci che rilasciano piccoli incrementi

delle funzionalità. La partecipazione del committente al team di sviluppo è più attiva; vi è poi un miglioramento costante e

continuo del codice. L’XP prevede dodici regole: -progettare con il cliente; -test funzionali e unitari; -refactoring (riscrivere

il codice senza alterarne le funzionalità esterne); -progettare al minimo; -descrivere il sistema con una metafora, anche per la

descrizione formale; -proprietà del codice collettiva (contribuisce alla stesura chiunque sia coinvolto nel progetto); -scegliere

ed utilizzare un preciso standard di scrittura del codice; -integrare continuamente i cambiamenti al codice; -il cliente deve

essere presente e disponibile a verificare (sono consigliate riunioni settimanali); -Open Workspace; -40 ore di lavoro setti-

manali; -Pair Programming (due programmatori lavorano insieme su un solo computer).

3.7 MODELLO A SPIRALE Vantaggi: rende esplicita la gestione dei rischi;

Il modello a spirale è quello che meglio concretizza il concetto di aiuta a determinare errori nelle fasi iniziali; ob-

iterazione e lo formalizza. Il processo viene rappresentato come una spirale bliga a considerare gli aspetti di qualità; integra

piuttosto che come una sequenza di attività: ogni giro della spirale rappre- sviluppo e manutenzione.

senta una fase del processo, le fasi non sono predefinite ma vengono scelte Svantaggi: richiede persone in grado di valutare

in accordo al tipo di prodotto; in ultimo ogni fase prevede la scoperta, la i rischi; può creare problemi nella definizione

esplicito dei “rischi”. È un meta-modello,

valutazione e il trattamento ed del contratto col cliente; per poter essere usato

offre la possibilità di utilizzare uno o più modelli. L’approccio ciclico in- deve essere adattato alla realtà aziendale e/o al

crementa il grado di definizione e implementazione del sistema mentre de- team.

crementa il grado di rischio.

3.8 GESTIONE DEI RISCHI

Il manager ha il compito di minimizzare i rischi. Ne esistono di diversi tipi: personale inadeguato, scheduling, budget

non realistico, sviluppo del sistema sbagliato … Il rischio è insito in tutte le attività umane ed è una misura dell’incertezza

risultato dell’attività. Alti rischi provocano ritardi e costi imprevisti. Il rischio è collegato alla quantità e qualità delle

sul

informazioni disponibili: meno informazione si ha, più alti sono i rischi. Per il modello a cascata alti rischi si presentano per

sistemi nuovi, non familiari, mentre bassi rischi si presentano nello sviluppo di applicazioni familiari con tecnologie note.

Nella prototipazione si presentano bassi rischi per le nuove applicazioni mentre la specifica e lo sviluppo vanno di pari passo;

si presentano alti rischi per la mancanza di un processo definito e visibile. Nel modello trasformazionale si presentano alti

rischi per le tecnologie coinvolte e le professionalità richieste. Il modello a spirale, infine, non presenta quasi mai alti rischi,

dovuto principalmente alla ripetizione delle fasi.

4 UML

Modellare consiste nel costruire un’astrazione della realità. Le astrazioni sono semplificazioni perché ignorano det-

tagli irrilevanti e rappresentano solo i dettagli rilevanti. Cosa è rilevante e cosa meno dipende dallo scopo del modello. Perché

modellare il software? Poiché il software è in continuo incremento di complessità. Il codice non è facilmente comprensibile

Pag. 9 a 57

dagli sviluppatori che non lo hanno scritto. Abbiamo bisogno di semplici rappresentazioni per sistemi complessi, attraverso

la regola 7±2.

Un sistema è un insieme organizzato di parti comunicanti, queste ultime posso essere considerate come un semplice

sistema chiamato “sottosistema”. Un è un’astrazione che descrive un sottoinsieme

modello di un sistema. Una vista descrive

selezionati aspetti di un modello. Una notazione è un insieme di regole testuali o grafiche per descrivere le viste. Viste e

modelli di un singolo sistema posso sovrapporsi tra di loro. Un fenomeno è un oggetto nel mondo del dominio che viene

percepito, un concetto invece descrive le proprietà comuni di un fenomeno. Un concetto è una tupla: nome, scopo, membri.

è un’astrazione nel contesto del linguaggio di programmazione mentre un’istanza

Il tipo è un membro di un tipo specifico.

è un’astra-

Un tipo di dati astratto è uno speciale tipo la cui implementazione è nascosta dal resto del sistema. Una classe

domino dell’applicazione è l’ambiente in cui il sistema opera, definito

zione nel contesto dei linguaggi object-oriented. Il

nelle fasi alte, mentre il dominio della soluzione sono tutte le tecnologie utilizzate per costruire il sistema, definito nelle fasi

di progettazione.

UML sta per Linguaggio Unificato di Modelli, uno standard per modellare software object-oriented. È il risultato

Si può modellare l’80% di molti problemi utilizzando

della convergenza di notazioni da tre maggiori metodi object-oriented.

circa il 20% di UML. UML usa i diagrammi per descrivere le relazioni tra i diversi componenti. Il diagramma use-case

descrive il comportamento funzionale del sistema visto dagli utenti; il diagramma delle classi descrive la struttura statica del

sistema, gli oggetti, gli attributi e le associazioni; il diagramma di sequenza descrive il comportamento dinamico tra gli oggetti

del sistema; il digramma di stato descrive il comportamento dinamico di un particolare oggetto; il diagramma di attività

descrive il comportamento dinamico di un sistema, in particolare il flusso di lavoro.

4.1 CONVENZIONI

Tutti i diagrammi UML denotano grafi di nodi e archi: i nodi sono entità e vengono disegnati come rettangoli o ovali;

i rettangoli denotano le classi o le istanze; gli ovali denotano le funzioni. I nomi delle classi non sono sottolineati, mentre i

nomi delle istanze sì. Un arco tra due nodi denota una relazione tra le corrispondenti entità.

5 SCOPERTA DEI REQUISITI

Spesso si utilizza un modello univoco per descrivere un oggetto. Tre sono i modi di maneggiare la complessità:

l’astrazione, la decomposizione, la gerarchia. Due sono i modi di trattare la decomposizione: funzionale e object-oriented, la

prima attraverso le funzioni, la seconda attraverso gli oggetti. Si parte con la descrizione delle funzionalità, poi si procede

con la scoperta degli oggetti. Il ciclo di vita di un software è un insieme di attività e le relazioni tra esse che supportano lo

sviluppo di un sistema software. Lo sviluppo di un software non può essere fatto prendendo una raffigurazione di una scena

(dominio). Come identifichiamo lo scopo del sistema? Cosa sta dentro e cosa fuori dal sistema? Le risposte a queste due

domande provengono dall’ingegneria dei requisiti, che consiste in due attività: scoperta dei requisiti e analisi dei requisiti,

nella prima si definisce il sistema in termini comprensibili dal cliente, mentre nella seconda si prende il problem descriptor,

lo si analizza e lo si formalizza per essere capito dagli sviluppatori.

5.1 SPECIFICHE DI SISTEMA VS MODELLO DI ANALISI

Entrambi i modelli si concentrano sui requisiti del sistema dal punto di vista degli utenti. Se la specifica di sistema

utilizza il linguaggio naturale, di contro il modello di analisi usa una notazione formale o semi-formale, ma il punto di par-

tenza è lo stesso: la definizione del problema. Quest’ultimo è sviluppato dal cliente come una descrizione del problema

indirizzato al sistema. Spesso viene definito statement of work. Un buon problem statement descrive la situazione corrente,

le funzionalità che il nuovo sistema deve supportare, l’ambiente in cui il sistema si troverà a lavorare, i diversi artefatti che

si aspetta il cliente, le date di scadenza, un insieme di criteri di accettazione, alcune volte contiene anche il piano strategico

e gli obiettivi di business.

5.2 PRIORITIZZAZIONE DEI REQUISITI

per priorità: alta, indirizzati durante l’analisi, la fase di design e l’implementazione, e

I requisiti vengono suddivisi

sono requisiti che dovranno essere dimostrati; media, indirizzati durante analisi e la fase di design, solitamente dimostrarti

durante l’analisi, illustrano come il sistema verrà utilizzato nel futuro anche senza

nella seconda iterazione; bassa, indirizzati

tecnologie disponibili.

5.3 TIPOLOGIE DI SCOPERTA DEI REQUISITI Pag. 10 a 57

Tre sono le tipologie: greenfield engineering, re-engineering, interface engineering. La prima parte da disegni, non

ha progetti già svolti da cui prendere spunto; la seconda utilizza un sistema già implementato, per implementarne altri utiliz-

zando nuove tecnologie; la terza prevede un aggiornamento del sistema in un nuovo ambiente. La scoperta è una sfida.

Richiede la collaborazione di persone con diversi background e, in qualche modo, colma il gap tra utenti e sviluppatori

attraverso gli scenari, esempi di uso del sistema in termini di una serie di iterazioni tra sistema e utente, e casi d’uso, astrazioni

che descrivono una classe di scenari. Esistono diversi tipi di scenari: as-is, usato nella descrizione di una situazione corrente;

visionario, utilizzato per descrivere un sistema futuro; di valutazione, descrive le attività degli utenti contro le quali il sistema

deve essere valutato; di formazione, istruzioni passo-passo che guidano un nuovo utente a conoscere il sistema.

5.3.1 SCENARI all’analista

Lo scenario è una sorta di racconto per individuare i tratti sostanziali per la raccolta dei requisiti. Serve sia

sia al cliente per avere una panoramica delle funzionalità del sistema. Per procedere a trovare il relativo use-case bisogna

descrivere le entry condition, il flusso di eventi, le exit condition, le eccezioni e requisiti speciali.

5.4 USE-CASE

Uno use case è un flusso di eventi nel sistema, che include le interazioni con gli attori. È iniziato da un attore, ogni

use-case ha un nome e una condizione di fine.

5.4.1 ASSOCIAZIONI DEGLI USE CASE

Le dipendenze tra gli use case sono rappresentate con le associazioni. Queste ultime sono utilizzate per ridurre la

complessità, decompongono uno use case in altri più corti, separano i flussi di eventi alternativi e raffinano gli use case più

astratti. Le tipologie di associazioni sono le include, le extend, e le generalizzazioni.

La relazione di include serve a descrivere la funzione come un aggregato di un insieme di funzioni più semplici. Lo

all’altro indica che un’istanza

use case associato è decomposto in use case più piccoli. La relazione di include da uno use case

regola il comportamento descritto nell’altro

di uno use case use case.

è un’estensione di un altro

La relazione di extend indica che uno use case use case.

Le differenze tra le due tipologie di associazioni sono le seguenti: per la prima ogni use case che include deve speci-

ficare dove viene invocato lo use case incluso e racchiude in sé funzioni comuni a più use case. Per la seconda la condizione

che attiva lo use case che estende è inserita nella entry condition dello use case che estende, non occorre modificare lo/gli

che vengono estesi, l’attivazione può avvenire in un punto qualsiasi del flusso di eventi dello

use case use case base e spesso

sono situazioni eccezionali.

La relazione di generalizzazione tra gli use case racchiude il comportamento comune. Gli use case figli ereditano il

comportamento e il significato dal padre e aggiungono o sovrascrivono alcuni comportamenti.

5.5 REQUISITI NON FUNZIONALI

I requisiti non funzionali si distinguono da quelli funzionali perché si riferiscono alla qualità del prodotto software

che si sta sviluppando. Per descriverli vengono utilizzati dei modelli universali: il FURPS+ racchiude nell’acronimo i requisiti

non funzionali che vengono descritti con il modello. Tra i vari troviamo:

• Usabilità: è la facilità con cui un utente può imparare ad operare, interpretare gli output del sistema o componente,

per la UI, nell’ambito dell’aiuto in rete,

come ad esempio le convenzioni adottate e il livello della documentazione

utente.

• Affidabilità: è l’abilità di un sistema o componente di performarsi alle funzionalità richieste sotto le condizioni sta-

bilite per uno specifico periodo, recentemente è stata sostituita con la dipendenza, che è di proprietà di un sistema

essere giustamente posta sul servizio da esso fornito ed include l’affi-

informatico in modo tale che la fiducia possa

dabilità, la robustezza e la safety.

• Prestazioni: requisiti concepiti con attributi quantificabili di un sistema, come il tempo di risposta, il throughput, la

disponibilità e l’accuratezza.

• Supportabilità: requisiti concepiti con i cambiamenti del sistema dopo lo sviluppo, ed includono l’adattabilità, la

manutenibilità e l’internazionalizzazione.

Poi, oltre ai requisiti funzionali, troviamo anche gli pseudo-requisiti come:

• implementazioni: che consistono nei requisiti per l’implementazione del sistema, come gli strumenti da

Requisiti di

utilizzare, i linguaggi di programmazione, e le piattaforme hardware. Pag. 11 a 57

• Requisiti di interfaccia: imposti dall’esterno del sistema, ed includono le legacy di sistema e i formati di interscambio.

• Requisiti di operazioni: imposti sull’amministratore e sui gestori del sistema nelle operazioni.

• sulla consegna attuale del sistema come i requisiti sull’installazione del sistema.

Requisiti di packaging:

• Requisiti legali: come le licenze, le regolamentazioni e le certificazioni.

5.6 TRACCIABILITA’ DEI REQUISITI

Ci sono molte relazioni tra requisiti e altri requisiti e tra requisiti e il system design. Ci sono anche collegamenti tra

requisiti e le ragioni sottostanti per cui questi requisiti sono proposti. Quando i cambiamenti sono proposti bisogna tracciare

l’impatto di questi cambi su altri requisiti e sul system design. La tracciabilità è la proprietà di una specifica dei requisiti che

riflette il sollievo di trovare requisiti relativi. La tracciabilità richiede identificativi unici per ogni requisito e prodotto.

Tracciabile significa che l’origine di ciascun requisito è chiara e può essere referenziata nello sviluppo futuro. Si

–forward

definiscono due tipi di tracciabilità: traceability: requisito collegabile a qualche elemento del progetto e del codice;

–backward traceability: dal progetto e dal codice è possibile risalire al requisito corrispondente

6 PROJECT MANAGEMENT

Il project management racchiude le attività necessarie per assicurare che un progetto software venga sviluppato ri-

spettando le scadenze e gli standard.

Le entità fisiche che prendono parte al project management sono:

1. Business manager: definiscono i termini economici del progetto

2. Project manager: panificano, motivano, organizzano e controllano lo sviluppo, stimano il costo del progetto, selezio-

nano il team di sviluppo, stendono i rapporti e le presentazioni.

3. Practitioners: hanno competenze tecniche per realizzare il sistema

4. Customers (clienti): specificano i requisiti del software da sviluppare

5. End users (utenti): gli utenti che interagiscono con il sistema

6.1 TEAM DI SVILUPPO

Esistono vari tipi di team di sviluppo qui di seguito indicati:

- Democratico decentralizzato

Assenza di un leader permanente (possono esistere dei leader a rotazione), consenso di gruppo, organizzazione orizzon-

tale.

Vantaggi: individuazione degli errori, adatto a problemi difficili

Svantaggi: difficile da implementare, non è scalabile.

- Controllato decentralizzato

Vi è un leader che controlla il lavoro e assegna i problemi ai gruppi a lui sottesi. I sottogruppi hanno un leader e sono

composti da 2 a 5 persone. I leader dei sottogruppi possono comunicare tra loro come anche i membri dei sottogruppi

possono comunicare in maniere orizzontale.

- Controllato centralizzato

Vi è un leader che decide sulle soluzioni e le organizzazioni dei gruppi. Ogni gruppo ha un proprio leader che assegna e

controlla il lavoro dei componenti. I leader dei gruppi non comunicano tra loro ma possono comunicare solo con il loro

capo. I membri dei gruppi non comunicano tra loro ma solo con il capo gruppo.

6.2 STESURA DEL PIANO DI PROGETTO

- Introduzione

Viene definita una descrizione di massima del progetto, gli elementi che vengono consegnati con le rispettive date di

consegne e vengono pianificati eventuali cambiamenti.

- Organizzazione del progetto

Vengono definite le relazioni tra le varie fasi del progetto, la sua struttura organizzativa, le interazioni con entità esterne,

le responsabilità di progetto (le principali funzioni e chi sono i responsabili).

- Processi gestionali

Si definiscono gli obiettivi e le priorità, le assunzioni, le dipendenze, i vincoli, i rischi con i relativi meccanismi di mo-

nitoraggio, pianificazione dello staff.

- Processi tecnici

Vanno specificati i sistemi di calcolo, i metodi di sviluppo, la struttura del team, il piano di documentazione del software

e viene pianificata la gestione della qualità.

- Pianificazione del lavoro, delle risorse umane e del budget Pag. 12 a 57

Il progetto viene diviso in task (attività) e a ciascuno assegnata una priorità, le dipendenze, le risorse necessarie e i costi.

Le attività devono essere organizzate in modo da produrre risultati valutabili dal management. I risultati possono essere

il primo rappresenta il punto finale di un’attività di processo, il secondo è un risultato fornito al

milestone o deliverables;

cliente. è un’unità atomica definita specificando: nome e descrizione del lavoro da svolgere, precondizioni

Ogni task per poter

avviare il lavoro, risultato atteso, rischi. I vari task vanno organizzati in modo da ottimizzare la concorrenza e minimizzare

la forza lavoro. Lo scopo è quello di minimizzare la dipendenza tra le mansioni per evitare ritardi dovuti al completamento

di altre attività.

Le WBS o struttura di scomposizione del lavoro sono usate nella pratica del Project management e aiutano il project

manager nell'organizzazione delle attività di cui è responsabile. La work breakdown structure è un albero gerarchico

orientato al prodotto (o deliverable) che viene suddiviso nel materiale, nel software, nei servizi, nei dati e nelle attrezza-

ture che lo compongono. L'albero viene strutturato in base all'ingegneria di sistema che è sviluppata nella fase iniziale

dell'apertura del progetto. La WBS definisce il prodotto, o i prodotti, da sviluppare o da produrre. Essa mette in relazione

con il prodotto finale e fra di loro gli elementi di lavoro che sono necessari alla sua realizzazione. La WBS può articolarsi

in un numero qualsiasi di livelli.

Le attività del progetto vengono divise in task che sono caratterizzati dai tempi di inizio e fine, una descrizione, le pre-

condizioni di partenza, i rischi possibili ed i risultati attesi.

6.3 GRAFO DELLE ATTIVITA’ (PERT)

Mostra la suddivisione del lavoro in attività evidenziando le dipendenze e il cammino.

1 2

ES EF

3 4

LS LF

Tabella 1 Tempi relativi alle attività

Figura 1 Cammino critico del grafo della attività

1 dell’attività a partire dal minimo tempo in cui terminano le attività precedenti (ovvero il valore massimo

ES (earliest start time) tempo minimo di inizio

degli EF precedenti).

2 dato ES è il minimo tempo in cui l’attività può finire.

EF (earliest finish time)

3 LS (latest start time) dato LF e la durata del task quale è il giorno massimo in cui deve iniziare per evitare ritardo nei task che dipendono da lui.

4 LF (latest finish time) il giorno massimo in cui quel task può finire senza portare ritardi ai successivi (ovvero il valore minimo tra gli LS dei successivi)

6.4 MANAGEMENT DEI RISCHI

Il management dei rischi identifica i rischi possibili e cerca di pianificare per minimizzare il loro effetto sul progetto,

pianifica i rischi e li monitorizza.

6.4.1 IDENTIFICAZIONE

I rischi da identificare sono di vari tipi tra cui: rischi tecnologici, rischi delle risorse umane, rischi organizzativi, rischi

nei tools, rischi relativi ai requisiti, rischi di stima/sottostima.

Le tipologie di rischi sono le seguenti:

- Tecnologici

Alcune tecnologie di supporto (database, componenti esterne) non sono abbastanza validi come ci aspettavamo.

- Risorse umane

Non è possibile reclutare staff con la competenza richiesta oppure non è possibile fare formazione allo staff.

- Organizzativi

Cambi nella struttura organizzativa possono causare ritardi o nello sviluppo del progetto.

- Strumenti

Ad esempio, il codice/documentazione prodotto con un determinato strumento non è abbastanza efficiente.

- Requisiti Pag. 13 a 57

Cambiamenti nei requisiti richiedono una revisione del progetto già sviluppato.

- Stima

Il tempo richiesto, la dimensione del progetto sono stati sottostimati.

6.4.2 ANALISI DEI RISCHI

Ad ogni rischio va assegnata una probabilità che esso si verifichi e vanno valutati gli effetti dello stesso che possono

essere: catastrofici, seri, tollerabili, insignificanti.

6.4.3 PIANIFICAZIONE DEI RISCHI

Viene considerato ciascun rischio e viene sviluppata una strategia per risolverlo. Le strategie che possiamo prendere

possono essere:

- Evitare i rischi con una prevenzione

- Minimizzare i rischi

- Gestire i rischi con un piano di contingenza per evitarli

6.4.4 MONITORAGGIO DEI RISCHI

Ogni rischio viene regolarmente valutato e viene verificato se è diventato meno o più probabile, inoltre i suoi aspetti

vanno discussi con il management per valutare meglio i provvedimenti da adottare.

7 COMUNICAZIONE E RAZIONALE

In un sistema in via di sviluppo si spende più tempo a comunicare che ad implementare. Il linguaggio UML permette

ai partecipanti del progetto di costruire modelli del sistema e discutere su di essi. Comunque, i modelli non sono solamente

le informazioni che servono quando si comunica per un progetto. Un ingegnere del software ha bisogno di imparare le cosid-

dette soft-skill: la scrittura tecnica, la lettura della documentazione, la comunicazione, la collaborazione, la gestione e infine

la presentazione.

7.1 COMPONENTI DI UN PROGETTO

Tra i componenti di un progetto troviamo:

• Il lavoro prodotto: ogni cosa prodotta dal progetto, come un pezzo di codice, un modello o un documento. I lavori

prodotti per il cliente vengono chiamati deliverable.

• Schedule: specifica quando lavorare sul progetto.

• Partecipanti: sono le persone che partecipano in un progetto, qualche volta vengono chiamati membri del progetto.

• Task: è il lavoro che deve essere svolto da un partecipante per creare un prodotto.

7.2 ORGANIZZAZIONE DEL TEAM

Un team è un piccolo insieme di partecipanti che lavorano allo stesso task o attività, mentre un gruppo è un insieme

di persone a cui viene assegnato un task comune, ma lavorano individualmente senza la necessità di comunicazione per unire

le loro parti del task. Un comitato comprende delle persone che insieme revisionano e criticano problemi e proposte di azioni.

7.2.1 TIPI DI INTERAZIONI

• Report: questo tipo di interazione è utilizzata per riportare informazioni di stato, come ad esempio la situazione di

sviluppo di un API oppure lo stato di completamento di un task.

• Decisione: utilizzata per propagare le decisioni.

• Comunicazione: utilizzata per scambiarsi tutti gli altri tipi di informazioni necessari per le decisioni e lo stato.

La struttura del report è gerarchica: sia lo stato che le decisioni sono unidirezionali, vale a dire che le decisioni sono

e passa attraverso le interazioni associate a tutti i livelli dell’organizzazione. Lo stato

sempre dalla radice dell’organizzazione

è generato alla fine dell’organizzazione e viene riportato alla radice attraverso le associazioni.

7.2.2 RUOLI In un’organizzazione

Un ruolo definisce un insieme di task tecnici e manageriali previsti dai partecipanti del team.

team-based, i task sono assegnati ad una persona o ad un team attraverso un ruolo. Sono classificati in:

• manageriali: riguardano l’organizzazione e l’esecuzione di un progetto entro i vincoli.

Ruoli Pag. 14 a 57

• Ruoli di sviluppo: riguardano con la specifica, il design e la costruzione di un sottosistema. Questi ruoli includono

l’analisi, l’architettura del sistema, la struttura dell’oggetto, lo sviluppatore e il tester.

• Ruoli cross-functional: (liaison) riguardano la coordinazione tra i team.

• Ruoli consulenti: riguardano il supporto temporaneo nelle aree in cui i partecipanti sono meno esperti.

7.2.3 TASK E PRODOTTI

è un lavoro ben definito assegnato per un ruolo mentre un’attività e un insieme di

Un task task. Un prodotto è una

cosa tangibile che è il risultato di un task, tutti gli altri prodotti che sono consegnati al cliente sono chiamati deliverable.

7.2.4 PACKAGING

Le specifiche di un lavoro da realizzare in task o attività è descritto in un pacchetto di lavoro ed include il nome e la

descrizione del task, le risorse necessarie per eseguirlo, dipendenze dagli input e output.

7.2.5 SCHEDULE

Uno schedule è la mappatura dei task nel tempo: ad ogni task è assegnato un tempo di inizio e fine, che ci permette

di pianificare la scadenza per i deliverable. I diagrammi più utilizzati sono il PERT e il GANTT

7.2.6 COMUNICAZIONE

Esistono diversi tipi di comunicazione: schedulata (pianificata) oppure ad eventi (non pianificata). Molto spesso ci si

serve di tool specifici per la comunicazione tra i membri del team. La comunicazione può essere sincrona, quando il mittente

e il destinatario sono disponibili allo stesso tempo (contemporaneamente), oppure asincrona, quando il mittente e il destina-

tario non comunicano allo stesso tempo.

Per la comunicazione pianificata, la definizione del problema ha come obiettivo presentare lo scopo, i requisiti e i

vincoli, alcune volte l’inizio del progetto è schedulato; la revisione del progetto si focalizza sul modello ed ha come obiettivo

la valutazione dello stato e revisione del modello, la decomposizione del sistema e le interfacce del sottosistema e si pianifica

intorno alle milestones e i deliverables del sistema; la revisione del cliente si focalizza sui requisiti ed ha come obiettivo

i cambiamenti ai requisiti, solitamente pianificata dopo la fase di analisi; la soluzione ha come obiettivo l’aumento

concordare mentre l’ispezione ha come obiettivo la conformità dei requisiti

della qualità del sottosistema ed è pianificata da ogni team,

ed è pianificata dal project manager; la revisione dello stato ha come obiettivo trovare deviazioni dal schedule e correggerlo

identificando nuovi problemi ed è pianificato ogni settimana; il brainstorming ha come obiettivo generare e valutare un largo

numero di soluzioni per un problema ed è pianificato ogni settimana; il rilascio ha come obiettivo definire il risultato di ogni

ha come obiettivo la descrizione dell’insegna-

attività sviluppata ed è pianificata dopo ogni fase; la revisione post-mortem

mento ed è pianificata alla fine del progetto.

La comunicazione non pianificata prevede la richiesta di chiarificazioni ed è il cuore della comunicazione tra gli

sviluppatori, clienti e utenti spesso sotto forma di incontri, chiamate, e-mail; la richiesta di cambiamenti prevede che un

membro riporti un problema e propone una soluzione e le richieste di cambiamenti spesso sono formalizzate quando la taglia

del progetto è sostanziale.

7.3 RAZIONALE

• Un problema non ha un’unica e corretta soluzione.

• Le proposte sono delle possibili alternative ai problemi e può essere condivisa tra problemi multipli.

• Una conseguenza è un problema causato dall’introduzione di una proposta.

• Un criterio rappresenta una misura di bontà, e sono spesso degli obiettivi di design o requisiti non funzionali.

• Gli argomenti rappresentano il dibattito che arriva dalla risoluzione del problema e supporta o oppone le altre parti

del razionale; gli argomenti costituiscono la gran parte del razionale.

• La risoluzione rappresenta la decisione e riassume le alternative scelte e gli argomenti a favore. Un problema risolto

si dice chiuso. Un problema risolto può essere riaperto se necessario, in quel caso la risoluzione è retrocessa.

Quindi il razionale include i problemi, le alternative, le decisioni, i criteri e il dibattito che porta al sistema. Per raggiun-

gere la soluzione ad un problema, spesso si ricorre a degli incontri tra i membri del team. Gli incontri devono essere brevi, i

partecipanti devono parlare piano in modo da essere capiti da tutti, devono partecipare solo i membri giusti, bisogna registrare

le scelte fatte e le scelte da fare. Ci si deve incontrare settimanalmente.

7.3.1 DOCUMENTI PRODOTTI NEL MEETING

• Agenda: che definisce lo scopo dell’incontro in termini di problemi aperti, invita i membri a risolvere i problemi

Pag. 15 a 57

• Minuta: registra le decisioni e la loro realizzazione oppure il progresso di una discussione in termini di opzioni, criteri

e argomenti. esecuzione, scrive l’agenda e

Ad ogni incontro si scegli un facilitatore, che è il responsabile del meeting e guida la sua

che è il responsabile di registrare l’incontro; il

la distribuisce ai membri; un minute taker, time keeper, responsabile di

mantenere il tempo.

8 CODICE ETICO

L’ingegneria del software coinvolge più ampie responsabilità che una semplice applicazione di abilità tecniche. Gli

ingegneri del software devono comportarsi in maniera onesta e eticamente responsabile se vogliono essere rispettati come

professionisti. Il comportamento etico è molto di più del rispetto della legge. Le società professionali negli US hanno coope-

rato per produrre un codice di pratica etica. I membri di queste organizzazioni firmano il codice quando si uniscono. Il codice

contiene otto principi relativi al comportamento e le decisioni fatte dagli ingegneri del software professionisti, includendo i

partecipanti, gli educatori, i supervisori. È composto da un preambolo e da otto principi:

• Pubblico: gli ingegneri agiranno consistentemente per il pubblico interesse

• Clienti e impiegati: gli ingegneri opereranno in una maniera che sia nei migliori interessi dei loro clienti e impiegati

che consistono nel pubblico interesse

• Prodotto: gli ingegneri garantiscono che i loro prodotti e relative modifiche sono in linea agli standard professionali.

• manterranno l’integrità e l’indipendenza nel loro giudizio professionale

Giudizio: gli ingegneri

• Gestione: i manager e i leader sottoscriveranno e promuoveranno un approccio etico alla gestione di uno sviluppo e

manutenibilità del software.

• l’integrità e la reputazione della professione consistente nel pubblico inte-

Professione: gli ingegneri avanzeranno

resse.

• Colleghi: gli ingegneri saranno leali e daranno supporto ai loro colleghi.

• Self: gli ingegneri parteciperanno in un processo di apprendimento per tutta la vita riguardante la partica della loro

professione e promuoveranno un approccio etico alla pratica della loro professione.

9 ANALISI DEI REQUISITI

L’analisi dei requisiti è finalizzata a produrre un modello del sistema chiamato modello dell’analisi che deve

essere corretto, completo, consistente e non ambiguo.

La differenza tra la raccolta dei requisiti e l’analisi è nel fatto che gli sviluppatori si occupano di strutturare e

formalizzare i requisiti dati dall’utente e trovare gli errori commessi nella fase precedente (raccolta dei requisiti).

L’analisi, rendendo i requisiti più formali, obbliga gli sviluppatori a identificare e risolvere caratteristiche diffi-

cili del sistema già in questa fase, il che non avviene di solito.

Il modello dell’analisi è composto da tre modelli individuali:

rappresentato da casi d’uso e scenari

- Il modello funzionale

dell’analisi rappresentato da diagrammi di classi e diagrammi ad oggetti

- Il modello a oggetti

- Il modello dinamico rappresentato da diagrammi a stati e sequence diagram

9.1 MODELLO AD OGGETTI VS MODELLO DINAMICO

Il modello degli oggetti di analisi rappresenta il sistema dal punto di vista dell’utente e si focalizza sui concetti

che sono manipolati dal sistema, le loro proprietà e relazioni. È considerato un dizionario visuale dei concetti principali

visibili all’utente.

Il modello dinamico, invece, si focalizza sul comportamento del sistema: i sequence diagram rappresentano le

interazioni tra un insieme di oggetti durante un singolo use case, invece gli statechart rappresentano il comportamento

di un singolo oggetto o di alcuni oggetti strettamente accoppiati. Consente di assegnare le responsabilità alle classi

quindi di individuare nuove classi che sono aggiunte al modello degli oggetti dell’analisi. Sia il modello dinamico che

il modello degli oggetti rappresentano concetti a livello utente non a livello di componenti e classi software.

9.2 OGGETTI ENTITY, BOUNDARY E CONTROL

In ogni sistema troviamo oggetti di tipi ricorrenti e molto spesso ci conviene classificarli. Il modello degli oggetti di

analisi consiste di oggetti Entity, Boundary e Control. Pag. 16 a 57

• rappresentano l’informazione persistente e sono quindi identificati da oggetti del dominio di appli-

Gli oggetti Entity

cazione;

• Gli oggetti Boundary rappresentano le interazioni tra gli attori e il sistema e sono identificati da oggetti relativi

all’interfaccia utente, oggetti dell’interfaccia dei dispositivi e oggetti dell’interfaccia di sistema.

• Gli oggetti Control si occupano di realizzare gli use case e rappresentano il controllo dei task eseguiti dal sistema,

contengono la logica e determinano l’ordine dell’interazione degli oggetti.

Considerando questi tipi di oggetti porta a modelli che sono molto più elastici al cambiamento, aiutano ad identificare

chiaramente le responsabilità dei vari oggetti, a verificarli e aiutano a leggere i class diagram.

UML fornisce il meccanismo degli stereotipi per consentire di aggiungere tale meta-informazione agli elementi di

modellazione. È opportuno usare convenzioni sui nomi: gli oggetti control possono avere il suffisso Control, gli oggetti

dovrebbero avere nomi che ricordano aspetti dell’interfaccia.

boundary

9.2.1 DAGLI USE CASE AGLI OGGETTI

Le attività che consentono di trasformare gli use case e gli scenari della raccolta dei requisiti in un modello di analisi

sono: identificare gli oggetti entity, boundary, control, mappare gli use case con sequence diagram, identificare le associa-

zioni, gli aggregati e gli attributi, modellare il comportamento dipendente dallo stato degli oggetti individuali, modellare le

relazioni di ereditarietà e rivedere il modello di analisi. Queste attività sono guidate da euristiche.

9.2.2 IDENTIFICARE GLI OGGETTI ENTITY

Gli oggetti partecipanti formano la base del modello di analisi. Per individuare gli oggetti partecipanti si esaminano

e si individuano i candidati. L’Euristica si basa sull’analisi del linguaggio naturale per identificare

gli use case di Abbot

oggetti, attributi, associazioni dalla specifica dei requisiti. Map- Testo Modello ad oggetti

pano parti del parlato per modellare componenti e ci si focalizza Nomi propri Istanze

sui termini dell’utente, però molto spesso, il linguaggio naturale è Nomi comuni Classi

Verbi di fare Operazioni

impreciso, anche il modello a oggetti derivato rischia di essere im- Verbi essere Ereditarietà

preciso. La qualità del modello dipende fortemente dallo stile di

scrittura dell’analista e quindi il modello Verbi avere Aggregazioni

va bene per generare una Verbi modali (es. deve essere) Costanti

lista iniziale di candidati a partire da una descrizione breve come Aggettivi Attributi

il flusso di eventi di uno scenario o uno use case.

9.2.3 IDENTIFICARE GLI OGGETTI BOUNDARY

rappresentano l’interfaccia del sistema con gli

Gli oggetti boundary attori. In ogni use case, ogni attore interagisce

Quest’ultimo colleziona informazione dall’attore e la traduce in una forma che può essere

almeno con un oggetto boundary. Questi oggetti modellano l’interfaccia

usata sia dagli oggetti control che entity. senza descriverne gli aspetti visuali e lo

sviluppo dell’interfaccia è solitamente di tipo prototipale e iterativo, vale a dire che i test di usabilità fanno evolvere conti-

nuamente l’interfaccia. caso usare un’euristica:

Per scovare gli oggetti boundary è possibile anche in questo

Identificare il controllo dell’interfaccia utente di cui l’utente ha bisogno per iniziare un caso d’uso

-

- Identificare i moduli di cui gli utenti hanno bisogno per inserire dati nel sistema

che il sistema deve fornire all’utente

- Identificare messaggi e notifiche

Non modellare aspetti visuali dell’interfaccia con oggetti

- boundary

- Usare sempre il termine utente finale per descrivere le interfacce.

9.2.4 IDENTIFICARE GLI OGGETTI CONTROL

Gli oggetti control sono responsabili del coordinamento degli oggetti boundary e entity. Si preoccupano di collezio-

nare info dagli oggetti boundary e inviarla agli oggetti entity. Di solito non hanno una controparte nel mondo reale e spesso

è creato all’inizio dello

esiste una stretta relazione tra oggetti control e use case: un oggetto control use case e cessa di esistere

alla fine.

Anche questo come gli oggetti entità e boundary si basa su delle euristiche:

per ogni caso d’uso

- Identificare un oggetto control per ogni attore nel caso d’uso

- Identificare un oggetto control

deve corrispondere alla durata di un caso d’uso o di una sessione utente.

- La vita di un oggetto control Pag. 17 a 57

9.3 MAPPARE USE CASE IN OGGETTI CON SEQUENCE DIAGRAM

Un sequence diagram mostra come il comportamento di uno

use case (o scenario) è distribuito tra i suoi oggetti partecipanti, infatti

vengono assegnate responsabilità a ogni oggetto in termini di un in-

sieme di operazioni.

Illustra la sequenza di interazioni tra gli oggetti necessaria per

realizzare uno use case. Non è adatto alla comunicazione con il cliente,

si utilizzano formalismi, per gli esperti invece è intuitivo e più preciso

degli use case e fornisce una prospettiva diversa che consente di indi-

viduare oggetti mancanti e aree non chiare nelle specifiche.

In un sequence diagram:

Le colonne rappresentano gli oggetti che partecipano al caso d’uso

- La prima colonna rappresenta l’attore che inizia il caso d’uso

- La seconda colonna è l’oggetto con cui l’attore interagisce per iniziare il caso d’uso

- boundary

La terza colonna è l’oggetto che gestisce il resto del caso d’uso

- control

- Gli oggetti control creano altri oggetti boundary e possono interagire con altri oggetti Control

- Le frecce orizzontali tra le colonne rappresentano messaggi o stimoli inviati da un oggetto ad un altro

La ricezione di un messaggio determina l’attivazione di un’operazione

- L’attivazione è rappresentata da un rettangolo da cui altri messaggi possono prendere origine

- durante il quale l’operazione è attiva

- La lunghezza del rettangolo rappresenta il tempo

Il tempo procede verticalmente dall’alto al basso

- Mediante i sequence

- Al top del diagramma si trovano gli oggetti che esistono prima del 1° messaggio inviato diagram è possibile tro-

Oggetti creati durante l’interazione sono illustrati con il messaggio

- <<create>> vare comportamenti o

Oggetti distrutti durante l’interazione sono evidenziati con una croce

- oggetti mancanti. Nel

La linea tratteggiata indica il tempo in cui l’oggetto può ricevere messaggi

- caso manchi qualche en-

tità è necessario ritor-

nare ai casi d’uso, ride-

9.3.1 MAPPARE USE CASE IN OGGETTI CON CLASS DIAGRAM finire le parti mancanti e

Il sequence diagram consente di illustrare le interazioni tra gli oggetti. Il class diagram tornare a questa fase per

mostra tra gli oggetti associazioni, ereditarietà e aggregazione. Identificare le associazioni con- ricreare il sequence dia-

sente di identificare casi limiti che devono essere chiariti con il cliente. Il class diagram rappre- gram.

la struttura del sistema. Viene utilizzato durante l’analisi dei

senta requisiti per modellare i con-

cetti del dominio del problema, durante il system design per modellare il sottosistema e le inter-

facce, durante l’object design per modellare le classi.

Una classe rappresenta un concetto, incapsula stati (attributi) e comportamenti (operazioni). Ogni attributo ha un tipo

classe è un’informazione obbligatoria.

e ogni operazione ha una firma. Solo il nome della

Un’istanza rappresenta un fenomeno. Il nome dell’istanza è sottolineata e può contenere la classe dell’istanza. Gli

attributi sono rappresentati con i loro valori.

Le differenze tra attori, classi e istanze sono: un attore è un’entità esterno al sistema da modellare, interagendo con

quest’ultimo; una classe è un’astrazione che modella un’entità nel dominio del problema e deve essere modellato nel sistema;

un oggetto è un’istanza di una classe.

9.3.2 IDENTIFICARE LE ASSOCIAZIONI

Un’associazione è una relazione tra due o più oggetti/classi. Ogni associazione ha un nome, un ruolo ad ogni

capo dell’arco che identifica la funzione di ogni classe rispetto all’associazione e una molteplicità che indica ad ogni

capo il numero di istanze possibili (vedi UML per dettagli).

Un’utile euristica per trovare le associazioni è la seguente:

- Esaminare i verbi nelle frasi

- Nominare in modo preciso i nomi delle associazioni e i ruoli

- Eliminare associazioni che possono essere derivate da altre associazioni

“illeggibile”

Troppe associazioni rendono il modello degli oggetti

- Link e associazioni stabiliscono una relazione tra oggetti. Un link è una connessione tra istanze di oggetti ed è definito

è un’istanza di associazione. Un’associazione è un mapping bi-direzionale

come una tupla. Un link e descrive un insieme di

link come una classe descrive un insieme di oggetti. Pag. 18 a 57

Un’associazione tra due classi è di default un mapping bi-direzionale. Se invece una classe è associata monodirezio-

nalmente ad un’altra, la classe client punta alla classe server e la freccia è direzionata dal client al server e sulla freccia è

presente il nome dell’associazione.

9.3.3 IDENTIFICARE LE AGGREGAZIONI

Un’aggregazione modella una gerarchia. Le associazioni di aggregazione aggiungono informazioni al mo-

dello di analisi su come i concetti di contenimento nel dominio di applicazione possono essere

organizzati. Se non si è sicuri che l’associazione che si sta descrivendo sia un’aggregazione è

meglio modellarla come associazione 1-Many e poi rivederla quando si ha maggiore conoscenza

dominio. Un’aggregazione è un caso speciale di aggregazione che denota una gerarchia “con-

del

siste di”.

L’aggregato è la classe padre, mentre il componente è la classe figlio. Un dia-

mante pieno denota la composizione, una forma forte di aggregazione dove i compo-

nenti non possono esistere senza aggregato.

I qualificatori possono essere usati per ridurre la molteplicità di una associazione.

Le classi figlie ereditano gli attributi e le operazioni dalla classe padre. L’ereditarietà semplifica il modello elimi-

nando la ridondanza. L’ereditarietà consente di organizzare concetti in gerarchie, al top ci sono i concetti più generali, al

bottom i concetti più specializzati. La generalizzazione è un’attività di modellazione che identifica concetti astratti da quelli

di più basso livello. La specializzazione è un’attività che identifica concetti più specifici da quelli di più alto livello. Come

risultato sia della specializzazione che della generalizzazione abbiamo la specifica di ereditarietà tra concetti.

9.3.3.1 EREDITARIETA’

L’ereditarietà modella una gerarchia e risponde a “è uno di. Una nota-

zione potente per condividere similarità tra classi preservando le loro differenze.

La notazione utilizzata in UML è un arco con un triangolo.

9.3.4 IDENTIFICARE GLI ATTRIBUTI

Gli attributi sono proprietà individuali degli oggetti. Solo gli attributi rilevanti al sistema dovrebbero essere identifi-

cati, come il nome, una breve descrizione e il tipo che descrive tutti i valori possibili che può assumere. Gli attributi possono

essere aggiunti anche dopo che l’analisi è finita. Non sono direttamente legati alle funzionalità del sistema. Gli sviluppatori

in questa fase non devono spendere molto del loro tempo per l’identificazione degli attributi. Le associazioni dovrebbero

identificate prima degli attributi per evitare confusione. L’euristica di Abbott indica che gli attributi possono essere

essere

identificati nel linguaggio naturale del documento delle specifiche prendendo in considerazione gli aggettivi.

9.3.5 NOTAZIONI ALTERNATIVE PER GLI STEREOTIPI

Le tre icone di Jacobson per gli stereotipi.

Sono possibili tre diverse notazioni:

• Utilizzo dei simboli di stereotipi nei simboli di classe

• Collasso del riquadro della classe nel solo simbolo di stereotipo

• Uso combinato del nome di stereotipo e del simbolo.

9.3.6 MODELLARE IL COMPORTAMENTO DEI SINGOLI OGGETTI

sono usati per “di-

I sequence diagram

stribuire il comportamento tra i diversi oggetti del

sistema e rappresentano il comportamento del si-

stema dal punto di vista dell’utente. Gli sta-

techart rappresentano il comportamento dei sin-

goli oggetti. Gli sviluppatori costruiscono una de- “tralasciati” nella prima fase. Non

scrizione formale del comportamento degli oggetti, e di conseguenza identificano use case

è necessario costruire statechart per tutti gli oggetti del sistema, come gli oggetti control, meno per gli oggetti entity e non si

usano per gli oggetti boundary. Pag. 19 a 57

9.3.7 RIVEDERE IL MODELLO DI ANALISI

Una volta che il modello dell’analisi non subisce più modifiche o ne subisce raramente è possibile passare alla fase

si revisione del modello. La revisione del modello deve essere fatta prima dagli sviluppatori e poi insieme dagli sviluppatori

e gli utenti. L’obiettivo di questa attività di revisione è stabilire che la specifica risulta essere: corretta, completa, consistente

e chiara.

Domande da porsi per assicurarsi della correttezza:

– Il glossario è comprensibile per gli utenti?

– Le classi astratte corrispondono a concetti ad alto livello?

– Tutte le descrizioni concordano con le definizioni degli utenti?

– Oggetti Entity e Boundary hanno nomi significativi?

– Oggetti control e use case sono nominati con verbi significativi del dominio?

– Tutti gli errori/eccezioni sono descritti e trattati?

Domande da porsi per assicurarsi della completezza:

– Per ogni oggetto: è necessario per uno use case? In quale use case è creato? modificato? distrutto? Può essere acceduto da un oggetto boundary?

– Per ogni attributo: quando è settato? Quale è il tipo?

– Per ogni associazione: quando è attraversata? Perché ha una data molteplicità?

– Per ogni oggetto control: ha le associazioni necessarie per accedere agli oggetti che partecipano nel corrispondente use case?

Domande da porsi per assicurarsi della consistenza:

– Ci sono classi o use case con lo stesso nome?

– Ci sono entità con nomi simili e che denotano concetti simili?

Domande da porsi per assicurarsi della chiarezza:

– Le richieste di performance specificate sono state assicurate?

– Può essere costruito un prototipo per assicurarsi della fattibilità?

10 MODELLI DINAMICI: SEQUENCE E COLLABORATION DIAGRAM

I modelli dinamici descrivono il comportamento del sistema in funzione del tempo: i modelli dinamici sono un tipo

di modello operazionale, cioè che descrive il comportamento desiderato, e sono utili soprattutto per sistemi orientati al con-

trollo. Ne esistono di due tipi:

• Diagrammi di interazione, che descrivono il comportamento dinamico tra gli oggetti

• Statechart, che descrivono il comportamento dinamico di un singolo oggetto

Tra i diagrammi di interazione troviamo:

• Sequence diagram, che descrivono il comportamento di un insieme di oggetti per un determinato periodo

• Collaboration diagram, mostrano la relazione tra gli oggetti senza prendere in considerazione il tempo.

Invece gli statechart diagram descrivono la risposta di un oggetto di una determinata classe come comportamento a

stimoli esterni. L’activity diagram è uno speciale statechart dove tutti gli stati sono azioni.

Un modello dinamico è una collezione di statechart diagram multipli in cui un singolo statechart rappresenta una

classe con un comportamento dinamico importante. Serve per scoprire ed aggiungere metodi per il modello a oggetti. Per

costruirli iniziamo dallo use case o dallo scenario.

che accade ad un certo punto nel tempo. Un evento invia informazioni da un oggetto all’altro.

Un evento è qualcosa

10.1 INTERACTION DIAGRAM

descrivono il comportamento dinamico di un gruppo di oggetti che “interagiscono” per ri-

Gli interaction diagram

solvere un problema. Un’interazione è un comportamento che comprende un insieme di messaggi scambiati tra un insieme

di oggetti nell’ambito di un contesto per raggiungere uno scopo.

UML propone due diversi tipi di interaction diagram

• Sequence diagram

• Collaboration diagram

Sequence e collaboration diagrams esprimono informazioni simile ma le evidenziano in modo diverso.

Un’interazione, tipicamente, avviene tra oggetti tra cui esiste un link(istanza di un’associazione). Un messaggio è

che trasmette informazione con l’aspettativa che ne conseguirà un’atti-

una specificazione di una comunicazione tra oggetti

vità: la ricezione di un messaggio può essere considerata una istanza di un evento. Gli oggetti sono gli elementi attivi di un

Pag. 20 a 57

programma e sono attivati dalla ricezione di un messaggio. Una classe determina i messaggi a cui un oggetto può rispondere

e sono inviati da altri oggetti. Per l’invio di un messaggio è necessario specificare il ricevente, il messaggio ed eventuali

informazioni aggiuntive.

10.1.1 SEQUENCE DIAGRAM

I diagrammi di sequenza descrivono interazioni tra oggetti che collaborano per svolgere un compito. Sono utili per

evidenziare la distribuzione del controllo nel sistema. Gli oggetti collaborano scambiandosi messaggio e lo scambio di

quest’ultimi in OOP equivale all’invocazione di un metodo. I diagrammi di sequenza posso essere utilizzati nei seguenti

modi: modellare le interazioni ad alto livello tra oggetti attivi all’interno di un sistema; per modellare l’interazione tra istanze

che realizza un caso d’uso; per modellare l’interazione tra oggetti in una colla-

di oggetti nel contesto di una collaborazione

borazione che realizza una operazione. Evidenziano la sequenza temporale delle azioni e sono trasparenti le associazioni tra

gli oggetti che vi partecipano. Le attività svolte dagli oggetti sono mostrate su linee verticali e la sequenza dei messaggi

scambiati tra di essi è mostrata su linee orizzontali. Possono corrispondere a uno scenario specifico o a un intero caso d’uso

e si possono anche annotare con vincoli temporali.

Gli oggetti sono situati sull’asse x e sono disposti orizzontal-

mente; un oggetto è un’istanza di una classe; mentre l’asse t è l’asse del

tempo che è descritto verticalmente. I messaggi sincroni sono disegnati

con una freccia chiusa da chiamante a chiamato. La freccia è etichettata

col nome del metodo invocato e, opzionalmente, con i suoi parametri e

il suo valore di ritorno. Il chiamante attende la terminazione del metodo

del chiamato prima di proseguire. Il life.time di un metodo è rappresen-

tato da un rettangolino che collega la freccia di invocazione con la frec-

cia di ritorno. Life-time corrisponde ad avere un record di attivazione di

quel metodo sullo stack di attivazione. Il ritorno è rappresentato con una

freccia tratteggiata ed è sempre opzionale. Se si omette, la fine è decre-

tata dalla fine del life.time.

I messaggi asincroni si usano per descrivere interazioni concorrenti. Si disegna con una freccia aperta da chiamante

a chiamato. La freccia è etichettata col nome del metodo invocato e, opzionalmente, con i suoi parametri e il suo valore di

ritorno. Il chiamante non attende la terminazione del metodo del chiamato, ma prosegue subito dopo l’invocazione. Il ritono

non segue quasi mai la chiamata. L’esecuzione di un metodo può essere assoggettata

ad una condizione. Il metodo viene invocato solo se la con-

dizione risulta verificata a run-time. Se la condizione non è

verificata, il diagramma non dice cosa succede (a meno che

non venga esplicitamente modellato ciascun caso) la condi-

zione si rappresenta sulla freccia di invocazione del metodo e

racchiusa tra parentesi quadre.

La costruzione di un nuovo oggetto rappresenta la costru-

zione di un nuovo oggetto non presente nel sistema fino a quel mo-

mento. Corrisponde all’allocazione dinamica e il messaggio viene

L’oggetto viene allocato

etichettato con new oppure con create.

nell’asse temporale in corrispondenza dell’invocazione nel metodo

new o create. Pag. 21 a 57

La distruzione di un oggetto persistente rappresenta la di-

struzione di un oggetto nel sistema fino a quel momento. Corri-

sponde alla de-allocazione dinamica. Si rappresenta con una X posta

dell’oggetto. Da quel momento in

in corrispondenza della life-time

poi non è “legale” invocare alcun metodo dell’oggetto distrutto.

L’iterazione ciclica di più mes-

rappresenta l’esecuzione

saggi. Si disegna raggruppando con un blocco i messaggi (metodi)

su cui si vuole iterare. Si può aggiungere la condizione che definisce

l’iterazione sull’angolo in alto a sinistra del blocco. La condizione si

rappresenta al solito tra parentesi quadre.

Cicli e condizioni si indicano con un riquadro (frame) che

racchiude una sotto-sequenza di messaggi.

Nell’angolo in alto è indicato il costrutto. Tra i costrutti possibili:

• tra parentesi quadra all’inizio o alla fine;

Loop (ciclo while-do o do-while): la condizione è indicata

• Alt (if-then-else): la condizione si indica in cima; se ci sono anche dei rami else allora si usa una linea tratteggiata

dalla zona else indicando eventualmente un’altra condizione

per separare la zona then accanto alla parola else;

• Opt (if-then): racchiude una sotto-sequenza che viene eseguita solo se la condizione indicata in cima è verificata

Sono possibili anche altri costrutti per indicare parallelismo, regioni critiche, etc.. In realtà, è buona norma utilizzare

altri tipi di diagramma quando l’algoritmo da modellare si fa complesso.

L’auto-chiamata descrive un oggetto che invoca un

proprio metodo. Chiamante e chiamato in questo caso coinci-

che rimane all’in-

dono. Si rappresenta con una freccia circolare

terno del life-time di uno stesso metodo. Viene anche usata per

rappresentare la ricorsione.

Per riassumere, le istanze di classi sono rappresentate da rettangoli col nome della classe e l’identificatore dell’og-

con un nome dal quali si evinca che si sta considerando un’istanza della classe.

getto sottolineati oppure semplicemente

Gli attori sono rappresentati come negli use case diagram e sono riportati sulla sinistra con frecce di interazione verso

oggetti del sistema; possono anche non essere riportati, nel caso in cui lo scenario venga avviato a sua volta da un altro

scenario.

I messaggi sono rappresentati come frecce da un attore ad un oggetto, o fra due oggetti; un messaggio può insistere

all’interno di uno stesso oggetto e in tale caso è indicato con una freccia circolare; l’ordine dei messaggi ricalca l’ordine

sequenziale con il quale vengono scambiati. Ad un messaggio possono corrispondere diversi tipi di azioni:

• Call: invoca una operazione di un oggetto; un oggetto può inviare un messaggio a se stesso

• Return: restituisce un valore al chiamante

• Send: invia un segnale ad un oggetto Pag. 22 a 57

• Create: crea un oggetto

• Destroy: distrugge un oggetto; un oggetto può distruggere se stesso

I messaggi possono essere preceduti da condizioni ([x>0]messaggio()) e possono indicare iterazioni (*messaggio()).

Un messaggio può essere:

• Semplice: rappresenta un flat flow of control; il controllo è passato dal mittente al ricevente

• Sincrono: rappresenta un nested flow of control; il controllo è passato dal mittente al ricevente ed il mittente

aspetta che il ricevente gli restituisca il controllo

• il mittente ‘segnala’ il ricevente tramite

Asincrono: rappresenta un non-nested flow of control tramite un signal;

il message e continua senza aspettare il ricevente, che può o meno ritornare informazioni

Da un flusso di eventi in uno scenario o use case si passa al sequence diagram. Un diagramma di sequenza è una

descrizione grafica di oggetti che partecipano ad uno scenario o use case utilizzando un DAG. Bisogna seguire una serie di

euristiche per costruirli.

• Un evento ha sempre un mittente e un destinatario.

• La rappresentazione di un evento è qualche volta chiamato messaggio

• Trovarli per ogni evento significa che ci sono oggetti partecipanti in uno use case.

• all’attore che inizia lo

La prima colonna corrisponde use case.

• La seconda è un oggetto boundary

• La terza è un oggetto control che gestisce il resto dello use case.

• sono creati all’inizio dello

Gli oggetti control use case.

• Gli oggetti boundary sono creati da oggetti control.

• Gli oggetti entity sono acceduti da oggetti control e boundary.

• Gli oggetti entity non chiamano mai oggetti control o boundary. Questo semplifica la condivisione di oggetti

entity tra gli use case e rende gli oggetti entity capaci di adattarsi ai cambi di tecnologia negli oggetti boundary.

I sequence diagram derivano dagli use case. La struttura di un diagramma di sequenza ci aiuta a determinare quanto

il sistema è centralizzato. Distinguiamo due strutture di diagrammi: fork e a scala.

In un diagramma a fork la maggior parte del comportamento dinamico è in un singolo oggetto, solitamene un control.

Quest’ultimo conosce tutti gli altri oggetti e spesso li usa per dirigere domande e richieste.

In un diagramma a scala il comportamento dinamico è distribuito. Ogni oggetto delega alcune responsabilità ad altri

oggetti. Ogni oggetto conosce solo alcuni degli altri oggetti e conosce quale oggetto può aiutarlo con un comportamento

specifico.

Spesso la mappatura use case-sequence diagram è 1 a 1. Si parte da un sequence di base, con un solo attore e un solo

oggetto, quest’ultimo rappresenta l’intero sistema, così come lo vede l’attore dall’esterno(black-box). Un messaggio dall’at-

tore al sistema con cui il caso d’uso viene attivato, si tratta il caso base in modo “ottimistico”, quindi si tralasciano le eccezioni

e ogni volta che ci sono scelte, si descrive solo ciò che accade nel caso “positivo”. Bisogna inserire un attore che attiva il

caso d’uso, un oggetto che si occupa della presentazione, un oggetto che si occupa di coordinare l’attività svolta dal sistema,

un oggetto responsabile della rappresentazione/gestione/memorizzazione dei dati. Bisogna assicurarsi che i metodi rappre-

sentati nel diagramma siano gli stessi definiti nelle corrispondenti classi, documentare ogni assunzione nella dinamica con

note o condizioni, mettere un titolo ad ogni diagramma, scegliere nomi espressivi per le condizioni e per i valori di ritorno,

non inserire troppi dettagli in un unico diagramma; se il diagramma è complesso, scomporlo in più diagrammi semplici.

Pag. 23 a 57

10.1.2 COLLABORATION DIAGRAM

Un collaboration diagram specifica gli oggetti

che collaborano tra loro in un dato scenario ed i mes-

saggi che si indirizzano. La sequenza dei messaggi è

meno evidente che nel diagramma di sequenza, mentre

sono più evidenti i legami tra gli oggetti. Per meglio

visualizzare l’ordine sequenziale dello scambio dei

messaggi è possibile ‘numerare’ i message antepo-

nendo al loro nome un numero che indica l’ordine

nella sequenza.

10.2 STATE DIAGRAM specifica il ciclo di vita di un oggetto, il quale può essere un’istanza di una classe,

Uno state o statechart diagram

caso d’uso o sistema. Questi diagrammi rappresentano il comportamento dei singoli oggetti in termini di eventi a cui gli

e transizioni di stato, cioè l’identificazione degli stati interni degli oggetti. Si ha la

oggetti sono sensibili, azioni prodotte

possibilità di descrivere evoluzioni parallele. Il diagramma degli stati e delle transizioni viene definito per una classe ed

intende descrivere l’evoluzione tipica di un oggetto generico di quella classe. Uno stato rappresenta una situazione in cui un

oggetto ha un insieme di proprietà considerate stabili. Una transizione, invece, modella un cambiamanto di stato ed è deno-

tata da: evento[condizione]/azione.

Lo stato di un oggetto racchiude le proprietà, di solito statiche, dell’oggetto, più i valori correnti, di solito dinamici,

Una freccia non etichettata che parte dal “vuoto” ed entra in uno stato

di tali proprietà.

indica che lo stato è iniziale. Una freccia non etichettata che esce da uno stato e finisce

nel “vuoto” indica che lo stato è finale. Stato iniziale e finale possono anche essere de-

notati da appositi simboli.

La transizione connette due stati. La condizione è anche detta “guardia”. L’evento è quasi sempre presente mentre la

condizione e l’azione sono opzionali. Gli stati sono rappresentati da rettangoli arrotondati.

Alcune volte vogliamo rappresentare dei processi che l’oggetto esegue senza cambiare stato. Questi processi si chia-

mano attività, e si mostrano negli stati con la notazione do/attività.

Uno stato composto (o macro-stato) è uno stato che ha un nome e che contiene a sua volta un diagramma. Esiste uno

stato inziale del macro-stato e i sotto-strati ereditano le transizioni in uscita del macro-stato.

Si hanno sotto-strati concorrenti (AND) quando più macchine di stato sono eseguite in parallelo entro lo stato che

raggiunge lo stato finale prima dell’altro, il controllo aspetta lo stato finale dell’al-

li racchiude. Se una macchina sotto-strato

tro. Quando avviene una transizione in uno stato con concurrent substate, il flusso di controllo subisce un fork per ciascun

concurrent substate; alla fine esso si ricompone in un unico flusso con un join.

10.2.1 ACTIVITY DIAGRAM

Un activity diagram fornisce la sequenza di operazioni che de-

finiscono un’attività più complessa. Permettono di rappresentare pro-

cessi paralleli e la loro sincronizzazione. Posso essere considerati state

particolari in cui ogni stato contiene (è) un’azione. Un

diagram activity

può essere associato ad una classe, all’implementazione di

diagram

un’operazione oppure ad uno use case. Questi diagrammi servono a rap-

presentare sistemi di workflow, oppure la logica interna di un processo

di qualunque livello. Sono utili per modellare comportamenti sequen-

ziali, non deterministici, concorrenti, sistemi distribuiti, business

workflow, operazioni. Sono ammessi stereotipi per rappresentare le

azioni. Gli elementi che costituisco un activity diagram sono:

• Activity: una esecuzione non atomica entro uno state machine. Una activity è composta da un action, elaborazioni

atomiche comportanti un cambiamento di stato del sistema e il ritorno di un valore.

• Transition: flusso di controllo tra due action successive

• Guard expression: espressione booleana (condition) che deve essere verificata per attivare una transition

Pag. 24 a 57

• ha un’unica

Branch: specifica percorsi alternativi in base a espressioni booleane; un branch transition in in-

gresso e due o più transition in uscita

• Syncronization bar: usata per sincronizzare flussi concorrenti

o Fork: per splittare un flusso su più transition verso action state concorrenti

o Join: per unificare più transition da più action state concorrenti in una sola

Gli activity state sono stati atomici (decomponibili ed interrompibili) che possono essere a loro volta rappresentati

con un activity diagram. Gli action state sono azioni eseguibili atomiche (non possono esser decomposti né interrotti) e

possono essere considerati come un caso particolare di activity state. Activity e ac-

tion hanno la stessa rappresentazione grafica invece un activity state può avere più

parti addizionali.

Un swimlane è un costrutto grafico rappresentante un insieme partizionato

di action/activity ed identificano le responsabilità relative alle diverse operazioni.

In un business model identificano le unità organizzative. Per ogni oggetto respon-

sabile di action/activity nel diagramma è definito un swimlane identificato da un

nome univoco nel diagramma; le action/activity state sono divise in gruppi e cia-

dell’oggetto responsabile per esse; l’orine

scun gruppo è assegnato allo swimlane

con cui gli swimlane si succedono non ha alcuna importanza; le transition posso

attraversare swimlane per raggiungere uno stato in uno swimlane non adiacente a

quello di inizio della transition.

e oggetti. Modellano l’utilizzo di oggetti da parte di

Gli oggetti flow sono associazioni tra action/activity state ac-

e l’influenza di questa su essi. Gli oggetti possono:

tion/activity state

• Essere l’output di una crea l’oggetto, la freccia della relazione punta all’oggetto

action: la action

• Essere l’input di una action: questa usa

l’oggetto, la freccia della relazione punta

all’action

• Essere manipolati da qualsiasi numero di

l’output di una

action: action può essere

l’input di un’altra

• Essere presenti più volte nello stesso dia-

gramma: ogni presenza indica un diffe-

rente punto di vita dell’oggetto

Può essere rappresentato lo stato di un oggetto in-

dicandolo tra [] al di sotto del nome.

11 CLASS DIAGRAM statica del sistema. Rappresentano le classi (di oggetti) tramite l’incapsulamento

I class digram definiscono la visione

di struttura e funzioni e relazioni tra classi (associazione, generalizzazione, aggregazione). È forse il modello più importante

perché definisce gli elementi basi del sistema.

Un software orientato agli oggetti è organizzato in forma di collezione di oggetti discreti che incorporano sia lo stato

(struttura dei dati) che il comportamento (operazioni/funzioni). È un’evoluzione del concetto di tipo di dato astratto. Nell’ap-

proccio orientato alle procedure, strutture dati e funzioni sono connesse debolmente. Il termine OO e i modelli sono applica-

bili a tutte le fasi di sviluppo: analisi, progettazione, realizzazione; ciò che cambia è il livello di astrazione ma non i concetti

e la notazione.

11.1 GLI OGGETTI E LE CLASSI

Un oggetto rappresenta qualsiasi cosa, reale o astratta, che abbia un confine definito ma è anche un qualcosa di

identificabile che ricorda il proprio stato e che può rispondere a richieste per operazioni relative al proprio stato. Gli oggetti

interagiscono tra di loro richiedendo reciprocamente servizi o informazioni. In risposta ad una richiesta, un oggetto può

invocare un’operazione che può cambiare il suo stato.

Un oggetto ha due tipi di proprietà: attributi, che descrivono lo stato, e operazioni, che descrivono il comportamento.

rappresenta un’astrazione di oggetti simili, cioè oggetti che hanno le stesse proprietà. I termini oggetto e istanza

Una classe

sono interscambiabili. Pag. 25 a 57

In UML una classe è composta da tre parti: nome, attributi, metodi o operazioni. Una classe può essere rappresentata

anche usando solo la sezione del nome. Un nome può essere un nome semplice, il solo nome della classe, o nome percorso,

il nome della classe preceduto dal nome del package in cui la classe è posta.

11.1.2 ATTRIBUTI

Un attributo è una proprietà statica di un oggetto e contiene un valore per ogni istanza. I nomi degli attributi devono

essere unici all’interno di una classe. Per ciascuno attributo si può specificare il tipo ed un eventuale valore iniziale. Tipica-

mente il nome di un attributo è composto da una parola o più parole e si usa il maiuscolo per la prima lettera di ciascuna

parola lasciando minuscola la lettera iniziale del nome. Gli oggetti avranno una loro identità, non bisogna aggiungerla. Spesso

alcuni attributi posso essere derivati, calcolati e non memorizzati. Si usano quando i loro valori variano frequentemente e la

correttezza del valore è importante. Il valore viene calcolato in basi ai valori di altri attributi.

11.1.3 OPERAZIONI

Un’operazione è un’azione che un oggetto esegue su un altro oggetto e che determina una reazione. Possono essere

classificate in selettore, quando accedono allo stato dell’oggetto senza alterarlo, oppure modificatore, quando alterano lo

stato. Sono previste elle operazioni di base per una classe di oggetti e sono chiamati costruttore, che crea un nuovo oggetto

e/o inizializza il suo stato, e distruttore, che distrugge un oggetto e/o libera il suo stato. Per ciascuna operazione si può

specificare il solo nome o la sua signature, indicando il nome, il tipo, parametri e, in caso di funzione, il tipo ritornato. Si

usano le stesse convenzioni dette per gli attributi.

Attributi e operazioni di una classe non devono essere obbligatoriamente descritti tutti subito e possono essere mo-

strati solo parzialmente, elidendo la classe. Per organizzare meglio lunghe liste di attributi/operazioni si raggruppano insieme

in categoria usando gli stereotipi.

11.1.4 RESPONSABILITA’

Una responsability è un contratto o una obbligazione di una classe: questa è definita dallo stato e comportamento

della classe, mentre quest’ultima può avere un qualsiasi numero di responsabilità, ma una classe ben strutturata ha una o

poche responsabilità. Le responsabilità possono essere indicate, in maniera testuale, in una ulteriore sezione, sul fondo della

icona della classe.

11.1.5 VISIBILITA’

È possibile specificare la visibilità di attributi e operazioni. In UML è possibile specificare tre livello di visibilità:

• qualsiasi altra classe con visibilità alla classe data può usare l’attributo/operazione (default)

+ (public):

• qualsiasi classe discendente della classe data può usare l’attributo/operazione

# (protected):

• solo la classe data può usare l’attributo/operazione

- (private):

11.1.6 MOLTEPLICITA’

La molteplicità è usata per indicare il numero di istanze di una classe: una multiplicity pari a zero indicherà una

classe astratta, una multiplicity pari ad uno una singleton class; per default è assunta una molteplicità maggiore di uno. La

molteplicità di una classe è indicata con un numero intero posto nell’angolo in alto a destra del simbolo della classe. La

molteplicità si applica anche agli attributi, indicandoli tra […].

La sintassi completa per specificare un attributo in UML è: [visibility] name [ [multiplicity] ] [: type] [= inital-value]

[{property-string}] dove property-string può assumere uno dei seguenti valori:

• nessuna limitazione per la modifica del valore dell’attributo

Changeable:

• addOnly: per attributi con molteplicità maggiore di 1 possono essere aggiunti ulteriori valori, ma una volta

creato un valore non può essere né rimosso né modificato

• frozen: il valore non può essere modificato dopo la sua inizializzazione

con la lista dei parametri avente questa sintassi: [direction] name: type [=default-value] dove direction può assumere uno dei

seguenti valori:

• in: parametro di input

• out: parametro di output

• inout: parametro di input/output

Un legame (link) rappresenta una relazione (fisica o concettuale) tra oggetti la cui conoscenza deve essere preservata

per un certo periodo di tempo. Un’associazione descrive un gruppo di legami aventi struttura e semantica comuni. Un’asso-

ciazione deve avere un nome che è solitamente un verbo. Le associazioni sono bidirezionali sebbene al nome della relazione

sono istanze delle associazioni e connettono due oggetti mentre un’associazione

può essere associata una direzione. I link Pag. 26 a 57

La molteplicità dice se l’associazione è obbligatoria oppure no e il numero minimo e massimo

connette due classi. di oggetti

che possono essere relazionati ad un altro oggetto.

11.1.7 RELAZIONI

forniscono una modalità per attraversare relazioni da una classe ad un’altra. I nomi di ruolo possono essere

I ruoli

usati in alternativa ai nomi delle associazioni. I ruoli sono spesso usati per relazioni tra oggetti della stessa classe (associazioni

riflessive). Un’associazione può avere un interface specifier, per specificare quale parte

dell’interfaccia di una classe è mostrata da questa nei confronti di un’altra classe

della stessa associazione.

Le classi associative sono utilizzate per modellare le proprietà delle associazioni:

alcune proprietà potrebbero appartenere all’associazione e non alle parti coinvolte. Un at-

tributo di una classe associativa contiene un valore per ogni legame.

è un’associazione spe-

La relazione di aggregazione

ciale che aggrega gli oggetti di una classe componente in un unico oggetto della classe: la si può

leggere come “è composto da “ in un verso e “è parte di” nell’altro verso. L’aggregazione ha le

seguenti proprietà: transitività, se A è parte di B e B è parte di C allora A è parte di C; antisimmetria, se A è parte di B allora

B non è parte di A; dipendenza, un oggetto contenuto potrebbe non sopravvivere senza l’oggetto contenente. Un albero di

aggregazione rappresenta una classe con più di una relazione di aggregazione.

La relazione di composizione è una relazione di aggregazione forte: le parti componenti non

esistono senza il contenitore, ciascuna parte componente ha la stessa durata di vita del contenitore e

una parte può appartenere ad un solo tutto per volta.

La relazione di generalizzazione rappresenta una tassonomia delle

classi in cui la classe generale è detta superclasse e ogni classe specializzata è detta sottoclasse. Può

letta come “è un tipo di” in un verso e “può essere un” nell’altro verso. Ogni oggetto di una

essere

sottoclasse è anche un oggetto della sua superclasse.

L’ereditarietà è un meccanismo di condivisione delle proprietà degli oggetti in una gerarchia di generalizzazione.

Tutte le proprietà di una superclasse possono essere applicati alle sottoclassi: generalizzazione ed ereditarietà godono della

proprietà transitiva, è possibile definire nuove proprietà per le sottoclassi, è possibile ridefinire le

proprietà ereditate (overriding). Anche le relazioni di una superclasse valgono per le sottoclassi.

definisce un comportamento “generico”; definisce e può implementare

Una classe astratta

parzialmente il comportamento, ma molto della classe è lasciato indefinito e non implementato. Det-

tagli specifici sono completati nelle sottoclassi specializzate. Le classi astratte sono indicate ponendo

il nome in corsivo. Per specificare che una class non può avere discendenti si

indicherà per questa la proprietà leaf sotto il nome della classe. Per

specificare che una classe non può avere antenati si indicherà per questa la proprietà root

sotto il nome della classe. Per indicare che una operazione è astratta il suo nome sarà scritto

in corsivo. Una operazione per la quale esiste la stessa signature in più classi di una gerar-

chia è polimorphic.

Per la gerarchia di classi, UML definisce

lo stereotipo implementation, cioè la sottoclasse

eredita l’implementazione della superclasse ma

non rende pubblica né supporta la sua interfaccia;

definisce 4 vincoli: complete, tutte le sottoclassi

sono state specificate e nessun altra sottoclasse è

permessa, incomplete, non tutte le sottoclassi

sono state specificate e altre sottoclassi sono sono

permesse, disjoint, oggetti del genitore posso avere non più di un figlio come tipo, over-

lapping, oggetti del genitore possono avere più di un figlio come tipo.

L’overlapping può portare all’ereditarietà multipla: una sottoclasse ha più di

una superclasse ed eredita le proprietà da tutte le superclassi. Questa soluzione è co-

modo nella modellizzazione ma può creare conflitti nella realizzazione. Pag. 27 a 57


PAGINE

57

PESO

2.44 MB

PUBBLICATO

8 mesi fa


DETTAGLI
Corso di laurea: Corso di laurea in informatica
SSD:
Università: Salerno - Unisa
A.A.: 2018-2019

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher francy96da di informazioni apprese con la frequenza delle lezioni di Ingegneria del software e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Salerno - Unisa o del prof Ferrucci Filomena.

Acquista con carta o conto PayPal

Scarica il file tutte le volte che vuoi

Paga con un conto PayPal per usufruire della garanzia Soddisfatto o rimborsato

Recensioni
Ti è piaciuto questo appunto? Valutalo!

Altri appunti di Corso di laurea in informatica

Architettura degli elaboratori - Appunti
Appunto
Esercitazioni Architettura degli Elaboratori
Esercitazione