Ingegneria del softwareversione 1.0.5

:::::::::::Appunti

19 luglio 2006

Indice

1 Ciclo di vita del software 31.1 Processo di sviluppo del soft-

ware . . . . . . . . . . . . . . 41.2 Modelli . . . . . . . . . . . . 41.3 Agile . . . . . . . . . . . . . . 5

1.3.1 Di�erenze con altrimodelli . . . . . . . . 5

1.3.2 Quando usarlo . . . . 51.4 Iterativo - Incrementale . . . 51.5 RAD . . . . . . . . . . . . . . 6

1.5.1 Vantaggi Svantaggi . . 61.6 Extreme Programming . . . . 6

1.6.1 Planning Game . . . . 71.6.2 Small Relesases . . . . 71.6.3 Customers on-Site . . 71.6.4 Test First . . . . . . . 71.6.5 Refactoring . . . . . . 81.6.6 Simplicity . . . . . . . 81.6.7 System Metaphor . . . 81.6.8 Pair Programming . . 81.6.9 Collective Code Ow-

nership . . . . . . . . 81.6.10 Continous Integration 91.6.11 Standards . . . . . . . 91.6.12 Overtime: 40 hour week 91.6.13 JUnit . . . . . . . . . 9

1.7 RUP . . . . . . . . . . . . . . 111.7.1 RUP best practices . . 111.7.2 Ciclo di vita del Pro-

getto . . . . . . . . . . 111.7.3 Il modello a Cascata -

WaterFall . . . . . . . 121.7.4 Il modello a Spirale . 12

1.7.5 Il modello a Release . 13

2 UXF 13

3 Metriche codice sorgente 143.1 LOC . . . . . . . . . . . . . . 14

3.2 eLOC . . . . . . . . . . . . . 14

3.3 lLOC . . . . . . . . . . . . . . 14

3.4 DLOC . . . . . . . . . . . . . 14

3.5 SLOC . . . . . . . . . . . . . 14

3.5.1 Vantaggi . . . . . . . . 15

3.5.2 Svantaggi . . . . . . . 15

4 UMM 15

5 XMI 15

6 COTS 16

7 SCM 167.1 Goal . . . . . . . . . . . . . . 16

8 FPA 17

9 COCOMO 189.1 Basic COCOMO . . . . . . . 18

10 COCOMO II 19

11 CORBA 20

12 DFD 20

13 Linguaggio Z 2013.1 Esempio - De�nizione sistema 21

13.2 Esempio - Add . . . . . . . . 21

2 Indice

14 Diagrammi UML 22

14.1 Diagramma casi d'uso . . . . 22

14.2 Diagramma delle classi . . . . 22

14.3 Diagramma delle sequenze . . 23

14.4 Diagramma delle collabora-zioni . . . . . . . . . . . . . . 23

14.5 Diagramma di stato . . . . . 2314.6 Diagramma delle attività . . 2314.7 Diagramma dei componenti . 2314.8 Diagramma di distribuzione

dei componenti (deployment) 24

Bibliogra�a 25

1 Ciclo di vita del software 3

1 Ciclo di vita del software

L'espressione ciclo di vita del software si riferisce al modo in cui una metodo-logia di sviluppo o un modello di processo scompongono l'attività di realizza-zione di prodotti software in sottoattività fra loro coordinate, il cui risultato�nale è il prodotto stesso e tutta la documentazione a esso associato[1].Esistono varie fasi:

1. Analisi: ovvero l'indagine preliminare sul contesto in cui il prodottosoftware deve inserirsi, sulle caratteristiche che deve esibire, ed even-tualmente su costi e aspetti logistici della sua realizzazione; questa fasepuò essere scomposta in sottoattività quali:

(a) analisi di fattibilità,

(b) analisi e modellazione del dominio applicativo,

(c) analisi dei requisiti.

2. Progetto: in cui si de�niscono le linee essenziali della struttura delsistema da realizzare, in funzione dei requisiti evidenziati dall'analisie dal documento �nale da essa creato. Anche questa fase può esserescomposta in sottoattività:

(a) progetto architetturale,

(b) al progetto dettagliato.

In questa fase verrà sviluppando un documento che permetterà di avereuna de�nizione della struttura di massima (architettura di alto livello)e una de�nizione delle caratteristiche dei singoli componenti (moduli)

3. Implementazione

4. Testing

(a) testing dei singoli moduli,

(b) testing del sistema integrato,

(c) test funzionali,

(d) test di performance,

(e) test di accettazione,

(f) test d'installazione.

5. Manutenzione

4 1 Ciclo di vita del software

1.1 Processo di sviluppo del software

L'UML (Uni�ed Modelling Language), ad esempio, è un linguaggio di mo-dellazione, utilizzato dai processi per realizzare, organizzare, documentare iprodotti realizzati dalle fasi di cui il processo si compone. Coloro che, indivi-dualmente o in gruppo, lavorano allo sviluppo o alla modi�ca di un software,adottano necessariamente un certo approccio nel modo di relazionarsi coni propri clienti/utenti, nell'organizzare il proprio lavoro, nella scelta delletecniche da utilizzare. Adottano un processo [1].

Il ciclo di sviluppo del software, nella maggior parte dei casi, è iterativo,e ogni iterazione produce una sua release. Elenchiamo di seguito le fasiprincipali che possono far parte di ogni singola iterazione:

1. Speci�ca dei requisiti: ciò che viene richiesto dal committente

2. Analisi e Design dove per analisi si intende lo studio di cosa deve fare ilsistema (punto di vista �logico�) e per design lo studio di come il sistemadeve venire implementato (punto di vista �tecnico�). Negli ultimi anni,la distinzione tradizionale tra analisi e design è entrata in crisi.

3. Implementazione

4. Integrazione e test

1.2 Modelli

Esistono molti modelli per lo sviluppo del software:

• iterativo (1970 - 1992),

• Waterfall (a cascata) (1970),

• RAD (1980 - 1991),

• spirale (1985),

• RUP (1998),

• Extreme Programming (XP) (1999).

• Agile (2001),

1 Ciclo di vita del software 5

1.3 Agile

Agile è una metodologia di sviluppo del software, un framework.Ci sono più tipi di agile software per sviluppare questo metodo, questi pos-sono essere trovati nell'organizzazione no-pro�t The Agile Alliance.Questo metodo tenta di minimizzare i rischi dello sviluppo con piccole time-boxes, chiamate iterazioni, da una a quattro settimane.Ogni iterazione include delle fasi: planning, requirements analysis, design,coding, testing e documentation.Mentre una iterazione non garantisce il rilascio di un prodotto, l'agile soft-ware project, si propone di riuscire a rilasciare un nuovo software ad ogniiterazione. Alla �ne di ogni iterazione, il tema �ssa le priorità del progetto.

1.3.1 Di�erenze con altri modelli

<�Agile�> <�Iterative�> <�Waterfall�><�-*�����-*�������*���>Adaptive....................................Predictive

• Adaptive methods: si concentra sull'adattarsi velocemente ai cam-biamenti.

• Predictive methods: si concentra sulla piani�cazione dettagliata efutura del progetto

1.3.2 Quando usarlo

• Più di 20 sviluppatori,

• distanza tra glil sviluppatori,

• mission- and life-critical e�orts,

• command-and-control company cultures.

1.4 Iterativo - Incrementale

Il modello iterativo, e incrementale, risponde alle debolezze dei modelli wa-tefall. I due modelli di sviluppo iterativo più conosciuti sono RUP (RationalUni�ed Process), e DSDM (Dynamic Systems Development Method).Questo modello è una parte essenziale dell'XP (Extreme Programming) etutti gli altri agile software frameworks.

6 1 Ciclo di vita del software

1.5 RAD

(Rapid Application Development) RAD nato come risposta al metodologianon-agile, come il modello waterfall.Il problema con i precedenti modelli era quello che i requisiti cambiasseroprima della conclusione del progetto, con il risultato di creare sistemi nonutilizzabili.

1.5.1 Vantaggi Svantaggi

• accresce la velocità e qualità di sviluppoQuesta velocità è dovuta all'uso di tool quali CASE1

Per qualità nel modello RAD si intende il grado con il quale l'appli-cazione �nita si riscontra con le aspettative del cliente, ed i costi dimanutenzione bassi.

• Come svantaggi, riduce la scalabilità e le features.La scalabilità è ridotta perché questo modello parte da un prototipo esi evolve �no alla applicazione �nita; mentre riduce le features questo èdovuto al time boxing, le features vengono inserite tardi nelle versioni�nali della release.

1.6 Extreme Programming

L'extreme programming XP, è un modo di programmare che segue deter-minate regole, per cercare di ottimizzare il più possibile lavoro fatto daiprogrammatori [2]. Alcune di queste regole sono di seguito riportate:

1. Planning Game

2. Small Releases (Piccole release)

3. Customers on-Site (Cliente sulposto)

4. Test First

5. Refactorig

6. Simplicity

7. System Metaphor

8. Pair Programming

9. Collective Code Ownership

10. Continous Integration

11. Code Standards

12. Overtime: 40 hour week

13. ...1L'obiettivo di questo tool è quello di catturare i requisiti e descriverli come codice nel

modo più veloce possibile.

1 Ciclo di vita del software 7

1.6.1 Planning Game

Come Piani�care:

• Creare delle priorità (con il cliente)

• Stimare la di�coltà dei lavori (Lo sviluppatore)

• Lavorare in task paralleli, si è più veloci (Lo sviluppatore)

• Piani�care insieme i lavori ed i vari task all'inizio (Sviluppatore-Cliente)

1.6.2 Small Relesases

Signi�ca piccole release frequenti, in genere prima dell'XP, si faceva il soft-ware per intero e poi si dava al committente validato; mentre ora si cerca didare subito qualcosa al cliente, in modo che capisca subito se il software ècorretto secondo le sue speci�che; questo evita di fare lavoro inutile.

In genere per il cliente viene sviluppato subito il 10% del programma inmodo tale che sia veloce il riscontro in caso di problemi.Questa tecnica, evita la nascita e la morte poi di determinati software, con laperdita quindi di tempo e denaro, inoltre fa subito vedere se ci sono errori2

o difetti3 nei software prodotti.

1.6.3 Customers on-Site

Il committente deve essere tenuto sempre in stretto contatto con gli svilup-patori. In genere succede che dopo aver ottenuto l'ordine di progettare unsoftware, il programmatore ed il cliente non si sentono quasi più �no a soft-ware terminato: questo non deve succedere.

Con l'XP, lo sviluppatore chiede subito al committente cosa sono le suepriorità, i moduli che devono essere sviluppati prima, e come devono esseresviluppati. Coinvolgere il cliente nei test per sapere se il software per lui ècorretto, mostrare se il programma per lui è user-friendly.

1.6.4 Test First

In genere i test vengono eseguiti dopo lo sviluppo della applicazione. Mentrein XP, il development è guidato dai test, questa può sembrare una perdita di

2Per errore si intende una dimenticanza del programmatore Es.: un errore dibattitura. . .

3Per difetto si intende un problema nei risultati ottenuti dal software, risultati inattesi.(Altrimenti detto bug, Fault.)

8 1 Ciclo di vita del software

tempo ma poi alla �ne: si ha si, una perdita di tempo iniziale, ma si recuperasulla �ne del progetto; mentre con l'approccio tradizionale si ha una velocitàmaggiore all'inizio per poi decelerare alla �ne nella fase di Testing.

1.6.5 Refactoring

Con questo termine, si intende modi�care il codice, modi�carne la struttura,il �usso di controllo ma non il risultato.

Ad esempio rinominare un metodo, aggiungere metodi a delle classi(masenza cambiare il risultato del modulo). Il refactoring serve in generale permigliorare la qualità del codice. Divisione di un grande metodo in più parti. . .

1.6.6 Simplicity

Cercare di tenere il progetto più semplice possibile.

1.6.7 System Metaphor

Usare metafore vicine al dominio del committente.Se il cliente è un produttore di automobili, cercare di parlare dello svilup-

po del software in termini di produzione di automobili, questo è una formaper cercare di capire nel miglior cosa deve fare il software prodotto.

1.6.8 Pair Programming

Con il termine pair programming si intende, la programmazione in gruppo,per esempio in due, questa viene richiesta quando il compito è particolar-mente di�cile; su lavori critici si lavora insieme.

1.6.9 Collective Code Ownership

Il codice scritto è di tutti gli sviluppatori; se si trova un errore nel programmala colpa è dell'intero team.

Bisogna dire che essendo il codice di tutti, chi vuole può fare tutte lemodi�che, se secondo lui un modulo non è corretto lo può modi�care, a pattoche usi i CVS (Concurrent Version System,controllo di versione); inoltre altermine della modi�ca il modulo modi�cato devo dare lo stesso risultato neitest del modulo vecchio; in altre parole non devo alterare i risultati che ilmodulo vecchio dava.

Se non è così, allora in quel caso, la colpa è del programmatore che hasvolto la modi�ca, il quale non si è preoccupato di vedere se i test eranoancora corretti; in conclusione, più libertà ma anche più responsabilità.

1 Ciclo di vita del software 9

1.6.10 Continous Integration

In genere il test di integrità viene fatto alla �ne dello sviluppo dei singolimoduli con una frequenza molto alta di errori.

L'XP dice che questo test deve essere fatto in modo più frequente proprioper evitare problemi di integrazione alla �ne del progetto, molto più di�cilida trovare e sistemare.

1.6.11 Standards

Cercare di scrivere codice il più possibile in modo standard: es in java, i nomidelle classi iniziano con la lettera maiuscola, mentre per i nomi dei metodi siusano dei verbi.

1.6.12 Overtime: 40 hour week

Per uno sviluppatore, le ore di straordinario, (overtime), sono permesse so-lo per una settimana, altrimenti c'è il rischio di commettere errori, mentrel'orario lavorativo normale non deve superare le 40 ore settimanali.

1.6.13 JUnit

E' uno strumento che serve per eseguire Test di unità in Java. Utilizza lalibreria Java ri�essione (per gestire le classi).

Terminologia:

• Unit Test: una classe che testa un'altra classe

• Caso di Test: chiama un metodo con un input particolare e si osservase il risultato è corretto

• Test Suite: una serie di casi di test

• Test Runner: serve per far partire i test

Junit, introduce una nuova classe: nomeclasseTest. Inoltre introduce dueclassi con nomi �ssi:

• setUp: inizializza la classe per eseguire i test

• tearDown: libera la classe

Junit utilizza le asserzioni per produrre il risultato dei test e vedere sesono corretti. Esempio in Java1:

10 1 Ciclo di vita del software

1 public class ES

{

3 int mcd(int x, int y)

{

5 ...

}

7 }

9 /* Creo un ' altra classe */

11 public class ES TEST

{

13 void testmcd ()

{

15 mcd(10,2); // Mi aspetto che restituisca 2

}

17 assertTrue(mcd(10,2) ==2);

assertTrue(mcd(6,12) ==6);

19 }

21 /* *** Tipi di Asserzioni *** */

23 static void assertTrue(boolean test)

static void assertTrue(String message , boolean test)

25

static void assertFalse(boolean test)

27 static void assertFalse(String message , boolean test)

29 static void assertEquals(expected , actual)

static void assertEquals(String message , expected , actual

)

Codice 1: Esempio in pseudolinguaggio Java

Limiti e problemi del Testing con JUnit

• È una buona idea scrivere metodi che controllano lo stato di un oggetto

• Non è facile testare il codice delle GUI

• Con questo metodo si controlla l'output ma ha volte non è facile scriverecodice per questo controllo

• Non è facile testare svariati metodi che lavorano in parallelo per dareun risultato

1 Ciclo di vita del software 11

• Sono comunque state proposte possibili soluzioni

1.7 RUP

RUP (Rational Uni�ed Process) è un software molto noto di sviluppo itera-tivo. RUP deve essere visto non come attraverso una singola prospettiva dilavoro, ma piuttosto un framework operativo adattabile alle esigenze

1.7.1 RUP best practices

1. Sviluppo del software in modo iterativo,

2. gestione dei requisiti,

3. veri�ca della qualità del codice,

4. CVS controllo dei cambiamenti apportati al software.

RUP usa il modello iterativo per le seguenti ragioni:

• Il processo di integrazione viene fatto passo dopo passo durante losviluppo del software, limitandosi a farlo per pochi elementi alla volta,

• l'implementazione viene fatta per moduli, facilitando il riuso del soft-ware,

• se i requisiti cambiano è possibile adattarsi,

• l'architettura del software viene migliorata ad ogni release

1.7.2 Ciclo di vita del Progetto

È formato da quattro fasi vedi Figura 1 a Pagina 12:

1. Inception Phase

(a) Stakeholder de�nizione, stima dei costi, tempi,

(b) comprensione dei requisiti,

(c) priorità costi/tempi, rischio, sviluppo del processo,

(d) studio del prototipo architetturale che si è studiato,

(e) spese attuali vs spese piani�cate.

2. Elaboration Phase

12 1 Ciclo di vita del software

(a) Generazione casi d'uso i casi d'uso completati all'80%

(b) descrizione dell'architettura software,

(c) piano di sviluppo per coprire tutto il progetto.

3. Construction Phase,

4. Transition Phase.

Figura 1: Ciclo di vita del progetto

1.7.3 Il modello a Cascata - WaterFall

Figura 2: Modello WaterFall

L'output di ogni fase è l'input della successiva; il principale limite di questomodello, è il fatto di non poter tornare indietro; se c'è un problema nel soft-ware che viene scoperto tardi bisogna ricominciare.

1.7.4 Il modello a Spirale

In questo modello vedi Figura 3 a pagina 13, si crea un prototipo, attraversole varie fasi: analisi dei requisiti, speci�ca. . . e poi si fa l'analisi dei rischi

2 UXF 13

Figura 3: Modello a Spirale

anche con il cliente per vedere se si può proseguire. Il principale vantaggiodei modelli a spirale e Release e che il software è in continua evoluzione [3].

1.7.5 Il modello a Release

In questo modello, si crea una prima release da sottoporre al cliente perottenere un primo feedback; per poi correggerla o svilupparla ancora.Alla �ne di tutte le release si ottiene il prodotto �nale.

2 UXF

UXF (UML eXchange Format) è un modello di interscambio di formati perUML(Uni�ed Modeling Language) basato su XML.Permette una alta inter operabilità; il team che sviluppa codice tramite que-sto modello, può riutilizzare e scambiare le informazioni tramite lo standardXML. XML è un so�sticato sottoinsieme dell'SGML (Standard GeneralizedMarkup Language: ISO 8879) i principali vantaggi sono:

• Indipendenza dal vendor (vender independence),

• Estensibilità,

• Possibilità di rappresentare delle informazioni complesse,

14 3 Metriche codice sorgente

• Leggibilità umana (Human readability),

• Interoperabilità tra i tools di sviluppo.

3 Metriche codice sorgente

3.1 LOC

Line of code (LOC). LOC sono usate per stimare i tempi ed i costi.

3.2 eLOC

E�ective line of code (ELOC), è la misura di tutte le line di codice che nonsono commenti, spazi bianchi, e parentesi. Questa metrica rappresenta laquantità del lavoro.

3.3 lLOC

Logical lines of code (ILOC) rappresenta una metrica per gli statements; es.:for. Esempio:

Source code line LOC eLOC lLOC Comment Blank

--------------------------------------------------------------

if (x<10) // test range x x x

{ x

// update y coordinate x

x

y = x + 1; x x x

} x

--------------------------------------------------------------

3.4 DLOC

Developed line of code (DLOC). Include tutto il programma ed gli statement.Esiste anche il Kilo line of code (KLOC).

3.5 SLOC

SLOC (Source lines of code) è una metrica usata per misurare il codice diun certo programma. SLOC viene usato per stimare lo sforzo richiesto persviluppare un certo software.

5 XMI 15

3.5.1 Vantaggi

• Automatizzare il conteggi delle linee di codice tramite tools

• Una metrica intuitiva: le righe di un software possono essere visionate.

3.5.2 Svantaggi

1. Non si può quanti�care il costo, di un software contando le linee dicodice, in altre parole contando solo la fase di codi�ca la quale occupasolo il 33% - 35% di tutti il processo,

2. non ci permette di catturare questa diversità: un programmatore puòscrivere poche righe di codice ma molto signi�cative, mentre un secondoprogrammatore ne scrive molte ma meno signi�cative e con più errori,

3. linguaggi di�erenti,

4. GUI, tramite queste interfacce, il programmatore può fare copia edincolla del codice già scritto in precedenza.

4 UMM

UMM (UN/CEFACT's4 Modeling Methodology), è una metodologia di mo-dellazione la quale si sviluppa tramite UN/CEFACT.

5 XMI

XMI (XML Metadata Interchange) è uno standard OMG per lo scambio dimetadati tramite il linguaggio XML.Può essere usato per qualsiasi metadato purché questo possa essere espressotramite MOF (Meta-Object Facility).L'uso più comune di XMI è per l'interscambio di modelli UML, i quali possonoessere usati anche per altri linguaggi.

• XML - eXtensible Markup Language, W3C standard.

• UML - Uni�ed Modeling Language, OMG modeling standard.

4(The United Nations Centre for Trade facilitation and Electronic Business) UN/CE-FACT ha come scopo migliorare il business, e l'organizzazione amministrativa, sviluppoe transazioni economiche, scambio di prodotti e servizi; contribuisce allo sviluppo delcommercio globale.

16 7 SCM

• MOF - Meta Object Facility, OMG DSL per la speci�ca di metamodelli.

• MOF Mapping a XMI

6 COTS

(Commercial o�-the-shelf); COTS è un termine applicato nell'ambito sia deiprodotti software che hardware, il quale dice quando questo prodotto è prontoe disponibile alla vendita al pubblico.

• GOTS : government o�-the-shelf,

• MOTS : modi�able o�-the-shelf, oppure military o�-the-shelf.

La motivazione che spinge ad utilizzare dei componenti COTS, è che ri-duce il tempo ed i costi di sviluppo del software; perché i componenti possonocomprati e non progettati da zero.A volte tuttavia i costi di integrazione e la dipendenza da terze parti possonoaccrescere i costi.

7 SCM

SCM (Software Con�guration Management) è una parte del CM (Con�gu-ration Management).Risponde a queste domande:

1. Qualcuno fa qualcosa, come possiamo riprodurla?

Spesso il problema si evolve e non è possibile riprodurlo in modo identico,ma servono dei cambiamenti incrementali.Tradizionalmente CM si è concentrato sul controllo e la creazione di prodottisemplici. Ai nostri giorni, la s�da è quella fare il minor numero di incrementi;valutando la complessità del sistema che si sta sviluppando.

7.1 Goal

• Con�guration Identi�cation- Con quale codice noi lavoriamo?

• Con�guration Control- Controllo delle release e eventuali cambiamenti.

• Status Accounting- Registrazione e report dei componenti.

8 FPA 17

• Review- Assicurarsi della completezza dei vari componenti.

• Build Management- Gestione dei processi e dei tool utilizzati nel pro-getto.

• . . .

8 FPA

FPA (Function Point Analysis) è un metodo che misura la dimensione fun-zionale di un sistema informativo. Questo viene fatto osservando le transa-zioni funzionali e logiche del �les rilevanti per gli utenti nel loro business [5].Necessità di alcuni passi:

1. Identi�care le funzioni del sistema che sono rilevanti per gli utenti

2. Determinare la complessità di ogni funzione

3. Contare le funzioni di tipo di dati per determinare il loro contributi alnumero dei function point non pesati

4. Contare le funzioni di tipo transazionale per determinare il loro contri-buti al numero dei function point non pesati

5. Determinare il fattore di aggiustamento del valore

6. Calcolare il numero di function point pesati.

Step 1 - FPA distingue tra cinque tipi di funzioni utente:

1. Internal Logical File (ILF)

2. External Interface File (EIF)

3. External Input (EI)

4. External Output (EO)

5. External Inquiry (EQ)

Step 2 - FPA distingue tra tre tipi di complessità:

1. Low

2. Average

3. High

18 9 COCOMO

9 COCOMO

COCOMO (COnstructive COst MOdel) è un modello progettato da BarryBoehm, per dare una stima del numero di uomini-mese che prenderanno parteallo sviluppo di un software.COCOMO consiste in una gerarchia di tre crescenti livelli di dettaglio:

1. Basic COCOMO : è statico, sforzo e costo dello sviluppo di un softwarecome funzione della dimensione di un programma espressa nella suastima delle linee di codice.

2. Intermediate COCOMO : sforzo come funzione della dimensione delprogramma e i �cost drivers� che includono subjective assessment ofproduct, hardware, personale e project attributes.

3. Detailed COCOMO : incorpora tutte le caratteristiche della versione in-termedia con un impatto dei cost driver ad ogni passo (analisi, progetto,codi�ca. . . ), del processo di produzione del software.

9.1 Basic COCOMO

Può essere applicato a tre tipologie di progetto:

1. Organic projects : sono relativamente piccoli, semplici progetti,

2. Semi-detached projects : sono una via di mezzo in termini di dimensionee complessità,

3. Embedded projects : sono progetti che devono essere sviluppati conhardware, software.

L'equazione del basic COCOMO:

E = ab(KLOC)bb

D = cb(E)db

P = E/D

dove E è lo sforzo (persone-mese), D è il tempo di sviluppo in un mese,KLOC è la stima del numero di line di codice per i progetto (espresse inmigliaia), P è il numero di persone richieste.I coe�cienti ab, bb, cb, db sono dati Tabella 1 a Pagina 19.

10 COCOMO II 19

Software Project ab bb cb db

Organic 2.4 1.05 2.5 0.38Semi-detached 3.0 1.12 2.5 0.35Embedded 3.6 1.20 2.5 0.32

Tabella 1: Coe�cienti Basic COCOMO

10 COCOMO II

Nel COCOMO II vengono apportate modi�che al COCOMO I. Vengonode�niti tre livelli di COCOMO, che corrispondono a tre classi di applicazionie utilizzano informazioni reperibili in tre diversi momenti del ciclo di vita:

1. Application Composition: è il settore di chi utilizza �primitive� dialto livello per programmare (ad esempio GUI, spreadsheet) o si rife-risce alla fase in cui viene generalmente e�ettuata una prototipazioneper risolvere problemi ad alto rischio (interfacce utente, interazionesoftware/sistema, prestazioni, maturità della tecnologia); vengono uti-lizzati gli Object Points, in quanto si ritiene che siano disponibili inmaniera a�dabile in questa fase

2. Early Design: si passa alla fase di progetto, con l'esplorazione dialternative per le architetture; vengono usati i Function Points, il lin-guaggio e alcuni driver di costo in numero limitato, poiché in questafase non è ancora noto molto a riguardo del progetto

3. Post-Architecture: si giunge alla fase di sviluppo tradizionale; si ot-tiene la stessa precisione di COCOMO 1; vengono usati LOC, FunctionPoints e linguaggio con 17 cost drivers e 5 fattori di scala, che sosti-tuiscono i fattori del modello precedente e i modelli Organic, Semi-detachede Embedded

Inoltre, il modello COCOMO II

• utilizza modelli non lineari per riuso e reingegnerizzazione

• permette il trattamento delle economie di scala

• apporta modi�che ai moltiplicatori originari

• si avvale di un modello Bayesiano per i parametri del modello valutatida esperti

20 13 Linguaggio Z

11 CORBA

L'OMG (Object Management Group), decise di promuovere il CORBA (Com-mon Object Request Broker Architecture) una architettura distribuita orien-tata algi oggetti.Usando CORBA, un client può in modo trasparente (es.: senza conoscerel'implementazione del server in dettaglio) invocare un metodo su un serverin due modi: in modo statico oppure tramite una invocazione dinamica.

12 DFD

Un DFD (data �ow diagram) è una rappresentazione gra�ca di un ��usso� didati attraverso un sistema.Un diagramma di �usso può essere utilizzato per visualizzare il data proces-

sing.

13 Linguaggio Z

È un linguaggio per la speci�ca formale, il quale usa la notazione matema-tica per descrivere in un modo preciso le proprietà e le informazioni che unsistema deve avere, senza conoscere in che modo queste proprietà vengonoarchiviate [7]; descrive che cosa il sistema deve fare senza sapere come [4].Una importante caratteristica del linguaggio Z è quella di decomporre la spe-ci�ca in piccole parti chiamati schemas. Gli schema sono usati per descrivereaspetti statici e dinamici.Gli aspetti statici includono:

• lo stato che può essere occupato,

• le relazioni tra invarianti che sono mantenute quando un sistema simuove da uno stato all'altro.

Gli aspetti dinamici includono:

• le operazioni possibili,

• le relazioni tra i loro input e output,

• i cambiamenti di stato.

13 Linguaggio Z 21

13.1 Esempio - De�nizione sistema

De�nire formalmente tramite il linguaggio Z un software che gestisce il nomee la data di compleanno di un database di persone.

BirthdayBook

known: P NAME

birthday : NAME 9 DATE

known: dom Birthday

• known è il set dei record nomi con il compleanno

• birthday è la funzione la quale applicata ad un nome restituisce ilcompleanno

L'ultima riga, è l'invariante in quanto è una relazione vera in ogni stato delsistema.Un possibile stato del sistema è dato da:

known = {Primo, Michele, Claudia }birthday = {Primo 7→ 25�Mar,

Michele 7→ 20�Dec,Claudia 7→ 20�Dec }.

L'invariate è rispettato in quanto il dominio dei birthday record è esattamenteuguale a quello di known cioè 3.

13.2 Esempio - Add

Aggiungiamo al sistema la possibilità di inserire nuovi dati. Lo schema èAddBirthday.

AddBirthday

∆BirthdayBook

name? : NAMEdate? : DATEname? /∈ known

Birthday'=Birthday ∪ {name? 7→ date? }

• known è il set dei record nomi con il compleanno

• birthday è la funzione la quale applicata ad un nome restituisce ilcompleanno

22 14 Diagrammi UML

14 Diagrammi UML

UML è un linguaggio di progettazione; UML è una evoluzione di modelligià esistenti, forti a�nità con ER (Entity - Relationship), FC (Flow Chart),modelli object oriented.Diagrammi UML:

• Livello logico:

� diagramma dei casi d'uso (use case)

� diagramma delle classi (class)

� diagramma di sequenza (sequence)

� diagramma di collaborazione (collaboration)

� diagramma di transizione di stato (state)

� diagramma delle attività (activity)

• Livello �sico:

� diagramma dei componenti (component)

� diagramma di distribuzione dei componenti (deployment)

14.1 Diagramma casi d'uso

Questi descrivono l'interazione tra attori e sistema, non la �logica interna�della funzione; sono infatti espressi in forma testuale, comprensibile ancheper i non �addetti ai lavori� e possono essere de�niti a livelli diversi (sistemao parti del sistema).Ragionare sui casi d'uso aiuta a scoprire i requisiti funzionali.

14.2 Diagramma delle classi

Il diagramma delle classi, rappresenta le classi e gli oggetti che compongonoil sistema, ed i relativi attributi ed operazioni [6, 1].Speci�ca, mediante le associazioni, i vincoli che legano tra loro le classi;può essere de�nito in fasi diverse (analisi, disegno di dettaglio) ed inoltrepuò rappresentare diverse tipologie di oggetti (oggetti business, oggetti diinterfaccia,. . . ).

14 Diagrammi UML 23

14.3 Diagramma delle sequenze

Il diagramma delle sequenze, serve ad evidenziare il modo in cui uno scenario(uno speci�co percorso in un caso d'uso) viene risolto dalla collaborazionetra un insieme di oggetti; speci�ca la sequenza dei messaggi che gli oggetti siscambiano inoltre può speci�care nodi decisionali e iterazioni. Diagrammi disequenza e diagrammi di collaborazione esprimono informazioni simili, ma leevidenziano in modo diverso.

14.4 Diagramma delle collaborazioni

Il diagramma delle collaborazioni, speci�ca gli oggetti che collaborano traloro in un dato scenario, ed i messaggi che si indirizzano. La sequenza deimessaggi è meno evidente che nel diagramma di sequenza, mentre sono piùevidenti i legami tra gli oggetti; può essere utilizzato in fasi diverse (analisi,disegno di dettaglio), e rappresentare diverse tipologie di oggetti.

14.5 Diagramma di stato

Speci�ca il ciclo di vita degli oggetti di una classe, de�nendo le regole che logovernano; quando un oggetto si trova in un certo stato può essere interessatoda determinati eventi (e non da altri). Come risultato di un evento l'oggettopuò passare ad un nuovo stato (transizione).

14.6 Diagramma delle attività

Serve a rappresentare sistemi di work�ow, oppure la logica interna di unprocesso (di qualunque livello, dai business process ai processi di dettaglio).Permette di rappresentare processi paralleli e la loro sincronizzazione; è uncaso particolare di diagrammi di stato, in cui ogni stato è uno stato di attività.

14.7 Diagramma dei componenti

Evidenzia l'organizzazione e le dipendenze esistenti tra componenti; i compo-nenti sono moduli software eseguibili, dotati di identità e con un'interfacciaben speci�cata, inoltre i componenti (come a livello logico le classi) possonoessere raggruppati in package.

24 14 Diagrammi UML

14.8 Diagramma di distribuzione dei componenti (de-ployment)

Evidenzia la con�gurazione dei nodi elaborativi in ambiente di esecuzione(run-time), e dei componenti, processi ed oggetti ubicati in questi nodi; per-mette di rappresentare, a diversi livelli di dettaglio, l'architettura �sica delsistema.

Riferimenti bibliogra�ci 25

Riferimenti bibliogra�ci

[1] http://en.wikipedia.org Data accesso 30.06.2006

[2] http://www.extremeprogramming.org/rules.html Data accesso15.06.2006

[3] http://xoomer.virgilio.it/mmanara/ling_sicurr/dom_l.rar Dataaccesso 01.07.2006

[4] http://spivey.oriel.ox.ac.uk/mike/zrm/index.html Data accesso15.07.2006

[5] Data processing Organization IFPUG Function point 4.2 Guida rapida

(2005.02.21)www.dpo.it

[6] Adriano Comai (1998) Introduzione a UML

[7] J. M. Spivey (1992) The Z Notation: A Reference Manual Second Edition

Programming Research Group University of Oxford, Based on the workof J. R. Abrial, I. J. Hayes et al.