Appunti Ingegneria del software - Home Page

Ingegneria del software
versione 1.0.5
Appunti
:::::::::::
19 luglio 2006
Indice
1 Ciclo di vita del software
1.1 Processo di sviluppo del software . . . . . . . . . . . . . .
1.2 Modelli . . . . . . . . . . . .
1.3 Agile . . . . . . . . . . . . . .
1.3.1 Dierenze con altri
modelli . . . . . . . .
1.3.2 Quando usarlo . . . .
1.4 Iterativo - Incrementale . . .
1.5 RAD . . . . . . . . . . . . . .
1.5.1 Vantaggi Svantaggi . .
1.6 Extreme Programming . . . .
1.6.1 Planning Game . . . .
1.6.2 Small Relesases . . . .
1.6.3 Customers on-Site . .
1.6.4 Test First . . . . . . .
1.6.5 Refactoring . . . . . .
1.6.6 Simplicity . . . . . . .
1.6.7 System Metaphor . . .
1.6.8 Pair Programming . .
1.6.9 Collective Code Ownership . . . . . . . .
1.6.10 Continous Integration
1.6.11 Standards . . . . . . .
1.6.12 Overtime: 40 hour week
1.6.13 JUnit . . . . . . . . .
1.7 RUP . . . . . . . . . . . . . .
1.7.1 RUP best practices . .
1.7.2 Ciclo di vita del Progetto . . . . . . . . . .
1.7.3 Il modello a Cascata WaterFall . . . . . . .
1.7.4 Il modello a Spirale .
1.7.5 Il modello a Release . 13
3 2 UXF
4 3 Metriche codice sorgente
3.1 LOC . . . . . . . . . . .
4
3.2
eLOC . . . . . . . . . .
5
3.3 lLOC . . . . . . . . . . .
5
3.4 DLOC . . . . . . . . . .
5
3.5 SLOC . . . . . . . . . .
5
3.5.1 Vantaggi . . . . .
6
3.5.2 Svantaggi . . . .
6
6 4 UMM
7
7 5 XMI
7
7 6 COTS
8
8 7 SCM
7.1 Goal . . . . . . . . . . .
8
8
8 FPA
13
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
14
14
14
14
14
14
15
15
15
15
16
16
. . . 16
17
8 9 COCOMO
18
9
9.1 Basic COCOMO . . . . . . . 18
9
9 10 COCOMO II
19
9
11 11 CORBA
20
11
11
12
12
12 DFD
20
13 Linguaggio Z
20
13.1 Esempio - Denizione sistema 21
13.2 Esempio - Add . . . . . . . . 21
2
Indice
14 Diagrammi UML
14.1
14.2
14.3
14.4
Diagramma casi d'uso . . . .
Diagramma delle classi . . . .
Diagramma delle sequenze . .
Diagramma delle collaborazioni . . . . . . . . . . . . . .
22
22
22
23
14.5
14.6
14.7
14.8
Diagramma di stato . . . . .
Diagramma delle attività . .
Diagramma dei componenti .
Diagramma di distribuzione
dei componenti (deployment)
23 Bibliograa
23
23
23
24
25
1
3
Ciclo di vita del software
1 Ciclo di vita del software
L'espressione ciclo di vita del software si riferisce al modo in cui una metodologia di sviluppo o un modello di processo scompongono l'attività di realizzazione 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 prodotto
software deve inserirsi, sulle caratteristiche che deve esibire, ed eventualmente su costi e aspetti logistici della sua realizzazione; questa fase
può 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 deniscono le linee essenziali della struttura del
sistema da realizzare, in funzione dei requisiti evidenziati dall'analisi
e dal documento nale da essa creato.
Anche questa fase può essere
scomposta in sottoattività:
(a) progetto architetturale,
(b) al progetto dettagliato.
In questa fase verrà sviluppando un documento che permetterà di avere
una denizione della struttura di massima (architettura di alto livello)
e una denizione 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 (Unied Modelling Language), ad esempio, è un linguaggio di modellazione, utilizzato dai processi per realizzare, organizzare, documentare i
prodotti realizzati dalle fasi di cui il processo si compone. Coloro che, individualmente o in gruppo, lavorano allo sviluppo o alla modica di un software,
adottano necessariamente un certo approccio nel modo di relazionarsi con
i propri clienti/utenti, nell'organizzare il proprio lavoro, nella scelta delle
tecniche da utilizzare. Adottano un processo [1].
Il ciclo di sviluppo del software, nella maggior parte dei casi, è
e ogni iterazione produce una sua release.
iterativo,
Elenchiamo di seguito le fasi
principali che possono far parte di ogni singola iterazione:
1. Specica dei requisiti: ciò che viene richiesto dal committente
2. Analisi e Design dove per analisi si intende lo studio di cosa deve fare il
sistema (punto di vista logico) e per design lo studio di come il sistema
deve 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
5
Ciclo di vita del software
1.3 Agile
Agile è una metodologia di sviluppo del software, un framework.
Ci sono più tipi di agile software per sviluppare questo metodo, questi possono essere trovati nell'organizzazione no-prot The Agile Alliance.
Questo metodo tenta di minimizzare i rischi dello sviluppo con piccole timeboxes, 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 software project, si propone di riuscire a rilasciare un nuovo software ad ogni
iterazione. Alla ne di ogni iterazione, il tema ssa le priorità del progetto.
1.3.1
Dierenze con altri modelli
<Agile> <Iterative> <Waterfall>
<-*-**>
Adaptive....................................Predictive
• Adaptive methods:
si concentra sull'adattarsi velocemente ai cam-
biamenti.
• Predictive methods:
si concentra sulla pianicazione dettagliata e
futura del progetto
1.3.2
Quando usarlo
•
Più di 20 sviluppatori,
•
distanza tra glil sviluppatori,
•
mission- and life-critical eorts,
•
command-and-control company cultures.
1.4 Iterativo - Incrementale
Il modello iterativo, e incrementale, risponde alle debolezze dei modelli watefall. I due modelli di sviluppo iterativo più conosciuti sono RUP (Rational
Unied Process), e DSDM (Dynamic Systems Development Method).
Questo modello è una parte essenziale dell'XP (Extreme Programming) e
tutti gli altri agile software frameworks.
6
1
Ciclo di vita del software
1.5 RAD
(Rapid Application Development) RAD nato come risposta al metodologia
non-agile, come il modello waterfall.
Il problema con i precedenti modelli era quello che i requisiti cambiassero
prima della conclusione del progetto, con il risultato di creare sistemi non
utilizzabili.
1.5.1
•
Vantaggi Svantaggi
accresce la velocità e qualità di sviluppo
1
Questa velocità è dovuta all'uso di tool quali CASE
Per qualità nel modello RAD si intende il grado con il quale l'applicazione nita si riscontra con le aspettative del cliente, ed i costi di
manutenzione bassi.
•
Come svantaggi, riduce la scalabilità e le features.
La scalabilità è ridotta perché questo modello parte da un prototipo e
si 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 determinate regole, per cercare di ottimizzare il più possibile lavoro fatto dai
programmatori [2]. Alcune di queste regole sono di seguito riportate:
1. Planning Game
7. System Metaphor
2. Small Releases (Piccole release)
8. Pair Programming
3. Customers on-Site (Cliente sul
posto)
4. Test First
9. Collective Code Ownership
10. Continous Integration
11. Code Standards
5. Refactorig
12. Overtime: 40 hour week
6. Simplicity
13. ...
1 L'obiettivo
di questo tool è quello di catturare i requisiti e descriverli come codice nel
modo più veloce possibile.
1
Ciclo di vita del software
1.6.1
7
Planning Game
Come Pianicare:
•
Creare delle priorità (con il cliente)
•
Stimare la dicoltà dei lavori (Lo sviluppatore)
•
Lavorare in task paralleli, si è più veloci (Lo sviluppatore)
•
Pianicare insieme i lavori ed i vari task all'inizio (Sviluppatore-Cliente)
1.6.2
Small Relesases
Signica piccole release frequenti, in genere prima dell'XP, si faceva il software per intero e poi si dava al committente validato; mentre ora si cerca di
dare subito qualcosa al cliente, in modo che capisca subito se il software è
corretto secondo le sue speciche; questo evita di fare lavoro inutile.
In genere per il cliente viene sviluppato subito il 10% del programma in
modo tale che sia veloce il riscontro in caso di problemi.
Questa tecnica, evita la nascita e la morte poi di determinati software, con la
perdita quindi di tempo e denaro, inoltre fa subito vedere se ci sono errori
o difetti
1.6.3
3
2
nei software prodotti.
Customers on-Site
Il committente deve essere tenuto sempre in stretto contatto con gli sviluppatori. In genere succede che dopo aver ottenuto l'ordine di progettare un
software, il programmatore ed il cliente non si sentono quasi più no a software terminato: questo non deve succedere.
Con l'XP, lo sviluppatore chiede subito al committente cosa sono le sue
priorità, i moduli che devono essere sviluppati prima, e come devono essere
sviluppati. 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. Mentre
in XP, il development è guidato dai test, questa può sembrare una perdita di
2 Per
errore si intende una dimenticanza del programmatore Es.: un errore di
battitura. . .
3 Per 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 recupera
sulla 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 modicare il codice, modicarne la struttura,
il usso di controllo ma non il risultato.
Ad esempio rinominare un metodo, aggiungere metodi a delle classi(ma
senza cambiare il risultato del modulo). Il refactoring serve in generale per
migliorare 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 sviluppo del software in termini di produzione di automobili, questo è una forma
per 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 è particolarmente dicile; 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 programma
la colpa è dell'intero team.
Bisogna dire che essendo il codice di tutti, chi vuole può fare tutte le
modiche, se secondo lui un modulo non è corretto lo può modicare, a patto
che usi i CVS (Concurrent Version System,controllo di versione); inoltre al
termine della modica il modulo modicato devo dare lo stesso risultato nei
test del modulo vecchio; in altre parole non devo alterare i risultati che il
modulo vecchio dava.
Se non è così, allora in quel caso, la colpa è del programmatore che ha
svolto la modica, il quale non si è preoccupato di vedere se i test erano
ancora corretti; in conclusione, più libertà ma anche più responsabilità.
1
9
Ciclo di vita del software
1.6.10
Continous Integration
In genere il test di integrità viene fatto alla ne dello sviluppo dei singoli
moduli con una frequenza molto alta di errori.
L'XP dice che questo test deve essere fatto in modo più frequente proprio
per evitare problemi di integrazione alla ne del progetto, molto più dicili
da trovare e sistemare.
1.6.11
Standards
Cercare di scrivere codice il più possibile in modo standard: es in java, i nomi
delle classi iniziano con la lettera maiuscola, mentre per i nomi dei metodi si
usano dei verbi.
1.6.12
Overtime: 40 hour week
Per uno sviluppatore, le ore di straordinario, (overtime), sono permesse solo per una settimana, altrimenti c'è il rischio di commettere errori, mentre
l'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 la
libreria Java riessione (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 osserva
se il risultato è corretto
•
Test Suite: una serie di casi di test
•
Test Runner: serve per far partire i test
Junit, introduce una nuova classe:
nomeclasse Test.
Inoltre introduce due
classi 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 se
sono corretti. Esempio in Java1:
10
1
7
public class ES
{
int mcd ( int x , int y)
{
...
}
}
9
/* C r e o un ' a l t r a c l a s s e */
1
3
5
Ciclo di vita del software
19
public class ES TEST
{
void testmcd ()
{
mcd (10 ,2) ; // Mi a s p e t t o c h e r e s t i t u i s c a 2
}
assertTrue ( mcd (10 ,2) ==2) ;
assertTrue ( mcd (6 ,12) ==6) ;
}
21
/* * * * T i p i di A s s e r z i o n i * * * */
11
13
15
17
23
static void assertTrue ( boolean test )
static void assertTrue ( String message , boolean test )
25
27
29
static void assertFalse ( boolean test )
static void assertFalse ( String message , boolean test )
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 scrivere
codice per questo controllo
•
Non è facile testare svariati metodi che lavorano in parallelo per dare
un risultato
1
Ciclo di vita del software
•
11
Sono comunque state proposte possibili soluzioni
1.7 RUP
RUP (Rational Unied Process) è un software molto noto di sviluppo iterativo. RUP deve essere visto non come attraverso una singola prospettiva di
lavoro, 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. verica 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 lo
sviluppo del software, limitandosi a farlo per pochi elementi alla volta,
•
l'implementazione viene fatta per moduli, facilitando il riuso del software,
•
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 denizione, 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 pianicate.
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.
4.
Construction Phase,
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 questo
modello, è il fatto di non poter tornare indietro; se c'è un problema nel software 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, attraverso
le varie fasi: analisi dei requisiti, specica. . . e poi si fa l'analisi dei rischi
2
13
UXF
Figura 3: Modello a Spirale
anche con il cliente per vedere se si può proseguire. Il principale vantaggio
dei 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 per
ottenere 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 per
UML(Unied Modeling Language) basato su XML.
Permette una alta inter operabilità; il team che sviluppa codice tramite questo modello, può riutilizzare e scambiare le informazioni tramite lo standard
XML. XML è un sosticato sottoinsieme dell'SGML (Standard Generalized
Markup Language: ISO 8879) i principali vantaggi sono:
•
Indipendenza dal vendor (vender independence),
•
Estensibilità,
•
Possibilità di rappresentare delle informazioni complesse,
14
3
•
Leggibilità umana (Human readability),
•
Interoperabilità tra i tools di sviluppo.
Metriche codice sorgente
3 Metriche codice sorgente
3.1 LOC
Line of code (LOC). LOC sono usate per stimare i tempi ed i costi.
3.2 eLOC
Eective line of code (ELOC), è la misura di tutte le line di codice che non
sono commenti, spazi bianchi, e parentesi.
Questa metrica rappresenta la
quantità 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 di
un certo programma. SLOC viene usato per stimare lo sforzo richiesto per
sviluppare un certo software.
5
15
XMI
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ò quanticare il costo, di un software contando le linee di
codice, in altre parole contando solo la fase di codica la quale occupa
solo 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 signicative, mentre un secondo
programmatore ne scrive molte ma meno signicative e con più errori,
3. linguaggi dierenti,
4. GUI, tramite queste interfacce, il programmatore può fare copia ed
incolla del codice già scritto in precedenza.
4 UMM
UMM (UN/CEFACT's
4
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 di
metadati tramite il linguaggio XML.
Può essere usato per qualsiasi metadato purché questo possa essere espresso
tramite MOF (Meta-Object Facility).
L'uso più comune di XMI è per l'interscambio di modelli UML, i quali possono
essere usati anche per altri linguaggi.
•
XML - eXtensible Markup Language, W3C standard.
•
UML - Unied Modeling Language, OMG modeling standard.
United Nations Centre for Trade facilitation and Electronic Business) UN/CEFACT ha come scopo migliorare il business, e l'organizzazione amministrativa, sviluppo
4 (The
e transazioni economiche, scambio di prodotti e servizi; contribuisce allo sviluppo del
commercio globale.
16
7
SCM
•
MOF - Meta Object Facility, OMG DSL per la specica di metamodelli.
•
MOF Mapping a XMI
6 COTS
(Commercial o-the-shelf ); COTS è un termine applicato nell'ambito sia dei
prodotti software che hardware, il quale dice quando questo prodotto è pronto
e disponibile alla vendita al pubblico.
•
GOTS : government o-the-shelf,
•
MOTS : modiable o-the-shelf, oppure military o-the-shelf.
La motivazione che spinge ad utilizzare dei componenti COTS, è che riduce il tempo ed i costi di sviluppo del software; perché i componenti possono
comprati e non progettati da zero.
A volte tuttavia i costi di integrazione e la dipendenza da terze parti possono
accrescere i costi.
7 SCM
SCM (Software Conguration Management) è una parte del CM (Conguration 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 prodotti
semplici. Ai nostri giorni, la sda è quella fare il minor numero di incrementi;
valutando la complessità del sistema che si sta sviluppando.
7.1 Goal
•
Conguration Identication- Con quale codice noi lavoriamo?
•
Conguration Control- Controllo delle release e eventuali cambiamenti.
•
Status Accounting- Registrazione e report dei componenti.
8
17
FPA
•
Review- Assicurarsi della completezza dei vari componenti.
•
Build Management- Gestione dei processi e dei tool utilizzati nel progetto.
•
...
8 FPA
FPA (Function Point Analysis) è un metodo che misura la dimensione funzionale di un sistema informativo. Questo viene fatto osservando le transazioni funzionali e logiche del les rilevanti per gli utenti nel loro business [5].
Necessità di alcuni passi:
1. Identicare 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 al
numero dei function point non pesati
4. Contare le funzioni di tipo transazionale per determinare il loro contributi 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 Barry
Boehm, per dare una stima del numero di uomini-mese che prenderanno parte
allo 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 software
come funzione della dimensione di un programma espressa nella sua
stima delle linee di codice.
2. Intermediate COCOMO : sforzo come funzione della dimensione del
programma e i cost drivers che includono subjective assessment of
product, hardware, personale e project attributes.
3. Detailed COCOMO : incorpora tutte le caratteristiche della versione intermedia con un impatto dei cost driver ad ogni passo (analisi, progetto,
codica. . . ), 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 dimensione
e complessità,
3. Embedded projects :
sono progetti che devono essere sviluppati con
hardware, 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 in
migliaia),
P
I coecienti
è il numero di persone richieste.
ab , bb , cb , db
sono dati Tabella 1 a Pagina 19.
10
19
COCOMO II
Software Project
ab
bb
cb
db
Organic
2.4
1.05
2.5
0.38
Semi-detached
3.0
1.12
2.5
0.35
Embedded
3.6
1.20
2.5
0.32
Tabella 1: Coecienti Basic COCOMO
10 COCOMO II
Nel COCOMO II vengono apportate modiche al COCOMO I. Vengono
deniti tre livelli di COCOMO, che corrispondono a tre classi di applicazioni
e utilizzano informazioni reperibili in tre diversi momenti del ciclo di vita:
1.
Application Composition:
è il settore di chi utilizza primitive di
alto livello per programmare (ad esempio GUI, spreadsheet) o si riferisce alla fase in cui viene generalmente eettuata una prototipazione
per risolvere problemi ad alto rischio (interfacce utente, interazione
software/sistema, prestazioni, maturità della tecnologia); vengono utilizzati gli Object Points, in quanto si ritiene che siano disponibili in
maniera adabile in questa fase
2.
Early Design:
si passa alla fase di progetto, con l'esplorazione di
alternative per le architetture; vengono usati i Function Points, il linguaggio e alcuni driver di costo in numero limitato, poiché in questa
fase 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, Function
Points e linguaggio con 17 cost drivers e 5 fattori di scala, che sostituiscono i fattori del modello precedente e i modelli Organic, Semidetachede Embedded
Inoltre, il modello COCOMO II
•
utilizza modelli non lineari per riuso e reingegnerizzazione
•
permette il trattamento delle economie di scala
•
apporta modiche ai moltiplicatori originari
•
si avvale di un modello Bayesiano per i parametri del modello valutati
da esperti
20
13
Linguaggio Z
11 CORBA
L'OMG (Object Management Group), decise di promuovere il CORBA (Common Object Request Broker Architecture) una architettura distribuita orientata algi oggetti.
Usando CORBA, un client può in modo trasparente (es.: senza conoscere
l'implementazione del server in dettaglio) invocare un metodo su un server
in due modi: in modo statico oppure tramite una invocazione dinamica.
12 DFD
Un DFD (data ow diagram) è una rappresentazione graca di un usso di
dati attraverso un sistema.
Un diagramma di usso può essere utilizzato per visualizzare il data processing.
13 Linguaggio Z
È un linguaggio per la specica formale, il quale usa la notazione matematica per descrivere in un modo preciso le proprietà e le informazioni che un
sistema deve avere, senza conoscere in che modo queste proprietà vengono
archiviate [7]; descrive che cosa il sistema deve fare senza sapere come [4].
Una importante caratteristica del linguaggio Z è quella di decomporre la specica in piccole parti chiamati schemas. Gli schema sono usati per descrivere
aspetti statici e dinamici.
Gli aspetti statici includono:
•
lo stato che può essere occupato,
•
le relazioni tra invarianti che sono mantenute quando un sistema si
muove 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
21
Linguaggio Z
13.1 Esempio - Denizione sistema
Denire formalmente tramite il linguaggio Z un software che gestisce il nome
e la data di compleanno di un database di persone.
BirthdayBook
NAME
NAME 9 DATE
: dom Birthday
known :
P
birthday :
known
•
known è il set dei record nomi con il compleanno
•
birthday è la funzione la quale applicata ad un nome restituisce il
compleanno
L'ultima riga, è l'invariante in quanto è una relazione vera in ogni stato del
sistema.
Un possibile stato del sistema è dato da:
known = { Primo, Michele, Claudia }
birthday = { Primo 7→ 25Mar,
Michele 7→ 20Dec,
Claudia 7→ 20Dec }.
L'invariate è rispettato in quanto il dominio dei birthday record è esattamente
uguale 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
: DATE
name? :
date?
name?
∈
/
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 il
compleanno
22
14
Diagrammi UML
14 Diagrammi UML
UML è un linguaggio di progettazione; UML è una evoluzione di modelli
già esistenti, forti anità 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 anche
per i non addetti ai lavori e possono essere deniti a livelli diversi (sistema
o 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 compongono
il sistema, ed i relativi attributi ed operazioni [6, 1].
Specica, mediante le associazioni, i vincoli che legano tra loro le classi;
può essere denito in fasi diverse (analisi, disegno di dettaglio) ed inoltre
può rappresentare diverse tipologie di oggetti (oggetti business, oggetti di
interfaccia,. . . ).
14
Diagrammi UML
23
14.3 Diagramma delle sequenze
Il diagramma delle sequenze, serve ad evidenziare il modo in cui uno scenario
(uno specico percorso in un caso d'uso) viene risolto dalla collaborazione
tra un insieme di oggetti; specica la sequenza dei messaggi che gli oggetti si
scambiano inoltre può specicare nodi decisionali e iterazioni. Diagrammi di
sequenza e diagrammi di collaborazione esprimono informazioni simili, ma le
evidenziano in modo diverso.
14.4 Diagramma delle collaborazioni
Il diagramma delle collaborazioni, specica gli oggetti che collaborano tra
loro in un dato scenario, ed i messaggi che si indirizzano. La sequenza dei
messaggi è 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
Specica il ciclo di vita degli oggetti di una classe, denendo le regole che lo
governano; quando un oggetto si trova in un certo stato può essere interessato
da determinati eventi (e non da altri). Come risultato di un evento l'oggetto
può passare ad un nuovo stato (transizione).
14.6 Diagramma delle attività
Serve a rappresentare sistemi di workow, oppure la logica interna di un
processo (di qualunque livello, dai business process ai processi di dettaglio).
Permette di rappresentare processi paralleli e la loro sincronizzazione; è un
caso 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 componenti sono moduli software eseguibili, dotati di identità e con un'interfaccia
ben specicata, inoltre i componenti (come a livello logico le classi) possono
essere raggruppati in package.
24
14
Diagrammi UML
14.8 Diagramma di distribuzione dei componenti (deployment)
Evidenzia la congurazione dei nodi elaborativi in ambiente di esecuzione
(run-time), e dei componenti, processi ed oggetti ubicati in questi nodi; permette di rappresentare, a diversi livelli di dettaglio, l'architettura sica del
sistema.
25
Riferimenti bibliograci
Riferimenti bibliograci
[1]
http://en.wikipedia.org
[2]
http://www.extremeprogramming.org/rules.html
Data accesso 30.06.2006
Data
accesso
15.06.2006
[3]
http://xoomer.virgilio.it/mmanara/ling_sicurr/dom_l.rar
Data
accesso 01.07.2006
[4]
http://spivey.oriel.ox.ac.uk/mike/zrm/index.html
Data accesso
15.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 work
of J. R. Abrial, I. J. Hayes et al.