Ingegneria del Software (Ing.Informatica Nuovo Ord.) Canale M-Z / A.A. 2005-06

Ingegneria del Software
(Ing.Informatica Nuovo Ord.)

Canale M-Z / A.A. 2005-06
Marco Cadoli
Universit di Roma La Sapienza
Dipartimento di Informatica e Sistemistica
www.dis.uniroma1.it/~cadoli
PRIMA PARTE
Il processo di produzione del SW

Sezione I: Introduzione, ciclo di vita del SW
Versione definitiva
Ing. del SW: Prima parte Sez I
Marco Cadoli, Universit La Sapienza, set 2005
PRIMA PARTE
Il processo di produzione del software
I.
II.
III.
IV.
Introduzione, ciclo di vita del SW

Qualit, standard
Test del SW
Project Management
I. Introduzione, ciclo di vita del SW

I.1. Cos lIngegneria del Software
I.2. Il prodotto
I.3. Il processo
I.4. Modelli per il ciclo di vita del software
I.1. COS LINGEGNERIA DEL

SOFTWARE
Possibili definizioni
Breve storia
Crisi del SW
Possibili definizioni dellIng. Del SW

Creazione di software multiversione da parte di pi
operatori [Parnas, 1978] programmazione ing. SW
Il settore dellinformatica che si occupa di sistemi
grandi e complessi, per la cui realizzazione servono
una o pi squadre di ingegneri [Ghezzi, Jazayeri,
Mandrioli, 2003] eliminazione difetti,
potenziamento/modifica/eliminazione funzioni
Applicazione di un approccio sistematico, disciplinato
e quantificabile nello sviluppo, funzionamento e
manutenzione del SW [IEEE Standard 610.12-1990]
applicazione dellingegneria al SW
Breve storia dellIng. Del SW

Albori dellinformatica (~1945-55):
problemi ben compresi e conosciuti (ad es., soluzione
equazioni differenziali);
spesso, programmatore = utente
Diffusione dei computer (~1955-65):

professione programmatore (programmatore utente
necessit di specifiche);
tipicamente, lavora da solo
Grandi sistemi SW ( 1965):

esempio: OS 360 (per IBM 360)
difficolt nelladattare le tecniche usate per lo sviluppo di
piccoli programmi
Crisi del software

La buona programmazione non basta
I membri di un gruppo spendono pi tempo per
comunicare fra loro che per programmare
Alcune persone possono abbandonare il progetto:
influenza negativa sul lavoro altrui,
trasferimento orale della conoscenza
Cambiamento nei requisiti influenza su tutto il

progetto
Serviva un nuovo approccio!
Ingegneria del software

Il termine nasce nel 1968 in una conferenza NATO.
la disciplina il cui scopo dare un approccio
sistemistico alla produzione, alla manutenzione ed alla
evoluzione del prodotto software
Si vuole usare lo stesso approccio degli altri settori
dellingegneria (civile, industriale)
Lingegneria del software comprende:
modelli astratti e teoria di base

metriche
metodi e processi di produzione e di test
tecnologie e strumenti
obiettivi da raggiungere (qualit del sw)
sensibilit pratica
Un problema temporaneo?
Ipotesi:
I ritardi nella consegna e gli sforamenti del budget
possono essere risolti con migliori:
strumenti (di analisi, sviluppo, )
tecniche di management
Realt:
No silver bullet [Brooks 1987]
Problemi accidentali (risolti dagli strumenti)
Problemi essenziali (non risolti dagli strumenti)
Le applicazioni complesse non sono completamente comprese
n dai clienti, n dagli sviluppatori
Non si sa come stimare la difficolt di un progetto e quanto
tempo necessario
Un esempio famoso
Programma Guerre stellari (1985, presidenza
Reagan).
Si dimette Dave Parnas (uno dei massimi esperti di IS
mondiali, responsabile informatica),
Motivazione pubblica: le odierne conoscenze e
tecnologie non sono in grado (e non lo saranno in breve
tempo) in grado di affrontare problemi cos complessi
10
Il futuro
HW potente e a basso costo produzione di
sistemi software sempre pi complessi e difficili
da gestire
Spese mondiali per il SW:
1985: 140 G$
2000: 800 G$
(PIL Italia 2000: 1074 G$)
Si continuano a sviluppare
strumenti
metodologie
11
I.2. -- IL PRODOTTO
Definizioni
Concetti generali
Cenni storici
I problemi dello sviluppo del software
12
Definizioni
Software:
Creazione dellintelletto che include programmi, strutture dati,
documentazione. Lesecuzione dei programmi realizza
(sperabilmente) le funzionalit previste.
Prodotto Software:
Insieme completo di programmi, procedure e relativa
documentazione, rilasciato ad un utente.
Componente Software:
Ogni parte identificabile di un prodotto software, sia in uno
stadio intermedio del processo di sviluppo, che al termine di
esso.
13
Classificazione delle applicazioni SW (1)

Rispetto al flusso di esecuzione:
Sequenziali (unico flusso di controllo)
Concorrenti (necessit di sincronizzazione e
comunicazione)
Dipendenti dal tempo (come le concorrenti +
vincoli temporali sulla velocit di esecuzione)
14
Classificazione delle applicazioni SW (2)

Rispetto alla natura degli elementi:
Realizzazione di funzioni
Gestione di dati (sistemi informativi)
Controllo (sincronizzazione e cooperazione)
15
Macroclassificazione delle
applicazioni sw
Sistemi operativi e software di sistema

sw di servizio
Real time software
vincoli precisi sui tempi di risposta
Sistemi informativi
gestione patrimonio informativo di unazienda
Software scientifico
calcolo numerico/simbolico
Software nascosto (embedded)
semafori, ascensori, lavatrici, telefoni, ecc..
PC software
16
Caratteristiche del software

Il SW sviluppato (attivit human intensive) e
non costruito come un qualsiasi prodotto
industriale (ad es., un monitor) ingegneria, e
non fabbricazione
possibile modificare facilmente il prodotto
senza modificare il progetto frequente
labuso della flessibilit
Il SW non si consuma
Il SW non (era) realizzato utilizzando
componenti preesistenti
17
Prodotto industriale e prodotto

software
Prodotto Industriale
Prodotto Software
A partire da una specifica

comune delegare la
realizzazione a diversi
soggetti porta alla
realizzazione di prodotti
totalmente diversi.
La descrizione delle
caratteristiche funzionali e
di qualit del prodotto
software rimane un
problema aperto.
Definito il progetto e il
processo di produzione del bene
si pu delegare la produzione a
strutture
esterne
senza
influenzarne il risultato.
I parametri e le tecniche usate
per descrivere un prodotto sono
consolidate,
affidabili
ed
efficaci.
18
Prodotto industriale e prodotto

software (2)
Prodotto Industriale
Prodotto Software
Sono possibili:
economie di scala
processi di produzione e
distribuzione diversificati
in
funzione
delle
dimensioni del mercato a
cui il prodotto si rivolge.
Non distinguibile la
produzione su piccola scala da
quella su larga scala.
Esiste una attivit di
revisione ed aggiornamento
non comparabile con quella
dei prodotti tradizionali.
19
Processo di sviluppo del software:

Insieme di:
persone,
strutture organizzative,
regole,
politiche,
procedure/attivit,
componenti software,
metodologie,
strumenti utilizzati o creati appositamente
per concepire, sviluppare, mettere in servizio e innovare/estendere

un prodotto software.
20
Prospettiva storica della produzione

del software
1950 - 1965: prima era
1973-1987: terza era
batch, distribuzione limitata,

software customizzato
1964-1974: seconda era

multiuser, Real-Time,
Database, software prodotto
sistemi distribuiti, hardware

low-cost, mercato di massa
1985-1995: quarta era

OO technologies, sistemi user
friendly, Powerful PC
1995-oggi: quinta era

internet, distributed
computing, CORBA-DCOM,
component-ware, J2EE
21
Esercizi/riflessioni
Esistono altri fattori che differenziano il software
da altri prodotti industriali?
Perch il prodotto software si differenzia cos
tanto da altri prodotti industriali?
22
Prospettiva storica del costo sw / hw

costo sw / costo hw
100
80
60
40
20
0
1950
2000
23
Prospettiva storica del costo del

software
costo sw / costo hw
100
80
60
sviluppo
40
20
1955
manutenzione
1965
1975
1985
ANDAMENTO DELLA LA SPESA PER IL SOFTWARE
24
Ripartizione del costo del software

15%
manutenzione e
modifiche
80%
manutenzione
46%
sviluppo
20%
verifica e
validazione
9%
dis.
e analisi
codifica
documentazione
10%
20%
% costo totale
% costo di sviluppo
RIPARTIZIONE DEI COSTI TRA

MANUTENZIONE E SVILUPPO
RIPARTIZIONE DEI COSTI DI SVILUPPO

TRA: ANALISI, DISEGNO, CODIFICA,
DOCUMENTAZIONE E VERIFICA
25
Deterioramento e guasti hw e sw
% guasti
sw
(teoria)
% guasti
hw
tempo
tempo
% guasti sw
(comportamento osservato)
Cambiamenti
sw
tempo
26
Problemi nello sviluppo del SW

IBM survey, 1994
55% dei sistemi costa pi del previsto
68% non viene completato nel tempo previsto
88% deve essere riprogettato in maniera sostanziale
Bureau of labour, 1997

Ogni 6 nuovi sistemi messi in linea, 2 cancellati
Per sistemi di grandi dimensioni, sale a 3
In media la sottostima del tempo di completamento
del 50%
27
Alcuni famosi incidenti causati dal

Errore di
software
programmazione
Therac-25: macchina per la radioterapia (1985-87).
Gestione SW della mutua esclusione errata.
http://sunnyday.mit.edu/therac-25.html
Errore di analisi
Ariane 6: missile ESA (1996).
Eccezione lanciata (ADA) a causa di violazione di
assunzioni non documentate.
http://www.esa.int/export/esaCP/Pr_33_1996_p_EN.html
Errore di
London Ambulance Service (1992).
management
Perdita di chiamate, duplicazione di dispatching.
http://www.cs.ucl.ac.uk/staff/A.Finkelstein/las.html
28
Componenti sw e riusabilit
Il concetto di componente software riusabile si va
sempre pi facendo strada.
strettamente collegato allanalisi (ad es., in
UML) e ai linguaggi (ad es., Java, C++, C#,
Delphi) Object Oriented.
Determina, fra laltro, un alto riuso di componenti,
molto efficace in alcuni contesti (ad es., per la
costruzione di interfacce grafiche -- Graphical
User Interface o GUI).
29
I.3. -- IL PROCESSO
Il processo di produzione del sw
Fasi essenziali
30
Il processo di produzione del software

Nel corso degli anni, nel passaggio dalla visione
artigianale alla visione industriale del software, si
compreso che il processo andava formalizzato
attraverso:
un insieme di fasi in cui decomporlo,

un insieme di prodotti delle varie fasi,
un insieme di metodi da adottare nelle varie fasi,
un insieme di tecniche o modelli con cui
descrivere i prodotti delle fasi.
31
Fasi essenziali del processo di

produzione sw
Progetto
Sviluppo
Manutenzione (sw esistente)
correttiva (20%): risoluzione di errori

adattativa (20%): cambiamenti/aggiunte di specifiche
perfettiva (50%)
migliorativa: req. non funzionali (spazio, tempo)
evolutiva: req. funzionali secondari
preventiva (10%)
rendere pi semplice la individuazione di errori tramite
miglioramenti del codice (ristrutturazione, pulizia, ecc.)
32
Attivit trasversali
Controllo/gestione del progetto

Revisioni tecniche del progetto
Controllo di qualit
Gestione della configurazione
Gestione della documentazione
Gestione della riusabilit
Misure
Gestione dei rischi
33
Elementi del processo di

produzione del sw
Insiemi di attivit
Scadenze
Prodotti intermedi
Controlli qualit
Attivit trasversali
Gestione del progetto
Metriche
ecc.
34
Re-Engineering
Lo sviluppo ex novo solo uno degli aspetti

dellIngegneria del Software
In questo caso si pu parlare di forward engineering
Se di un sistema esistente (mal documentato) si vuole
creare una documentazione adeguata, si attua un
processo di reverse engineering
Per ricostruire un sistema ingegnerizzato a partire da un
vecchio sistema inadeguato:
Reverse Engineering
+
Forward Engineering
=
Re-Engineering
35
I.4. MODELLI PER IL CICLO DI

VITA DEL SW
Presentazione dei vari modelli
Confronto
36
Modelli per il processo di produzione

(ciclo di vita) del sw
Sequenziale (cascata, classico)

Prototipale
Rapid Application Development (RAD)
Modelli evolutivi
Incrementale
Spirale
Sviluppo concorrente
Extreme programming
Tecniche e linguaggi di quarta generazione

Modelli basati su metodi formali
37
Visione caotica del processo

Definizione
del problema
Soluzione
tecnica
Stato
corrente
Integrazione
38
Visione caotica del processo (2)
Stato
corrente
Sfida: gestire in maniera ragionevole questi stadi coesistenti

39
Processo a cascata (waterfall, Royce 1970)

ANALISI
DESIGN
CODIFICA
TEST
MANUTENZIONE
Ispirazione dallindustria manufatturiera, reazione al code and fix

40
Fasi e prodotti del modello a cascata

codifica
analisi
descrizione di cosa si
vuole realizzare
definizione dei
requisiti
realizzazione in un
linguaggio di
programmazione
sorgenti
test
design
progettazione del
sistema (come si vuole
realizzarlo)
architettura e moduli
verifica di aderenza, test

di modulo e di
integrazione
documenti di test
manutenzione
gestione cambiamenti
41
Problemi del modello a cascata

I progetti reali raramente seguono il flusso
sequenziale proposto dal modello
Spesso si verificano iterazioni
spesso difficile per il cliente dichiarare tutti i
requisiti in modo esplicito.
Il modello ha difficolt a gestire la naturale
incertezza che esiste allinizio di nuovi progetti
42
Problemi del modello a cascata (2)

Il cliente deve avere pazienza, una versione
funzionante del sistema non potr essere disponibile
se non nelle ultime fasi del ciclo di vita.
Inoltre, scoprire un errore in questa fase pu avere
conseguenze disastrose.
Il lavoro degli sviluppatori inutilmente ritardato (il
tempo di attesa complessiva pu superare il tempo
di lavoro !!!)
43
Modello prototipale
Interazione
con lutente
Realizz. modifica
prototipo
Test del prototipo

(con lutente)
La prototipazione ha come obiettivo la realizzazione del prodotto

software attraverso successive realizzazioni di prototipi:
paper protoype, o mock-up, o prototipo freddo, solo
interfaccia completezza e disambiguazione requisiti,
manuale utente
working prototype: implementa solo alcune funzioni
breadboard: funzionalit critiche, senza interfaccia
44
Modello prototipale (2)

Se il prototipo working:
lo si trasforma nel programma finale, oppure
lo si butta
Vantaggi:
molto attraente, sia per il cliente sia per lo sviluppatore
coinvolge maggiormente il cliente nella definizione delle
specifiche,
evita/riduce le incomprensioni
Potenziali svantaggi:
pu evolvere in un sistema senza un progetto solido
possibile spreco di risorse nel caso usa e getta
tentazione di riutilizzare le scelte prototipali (o,
addirittura il prototipo stesso)
45
Modello RAD
(Rapid Application Development)
Obiettivo: rapida (60-90 gg.) codifica

(riuso/parallelismo)
Ipotesi fondamentali (e limiti dellapproccio):

requisiti chiari
la complessit limitata (ad es., semplice sistema
informativo), le prestazioni non sono critiche
lapplicazione si pu decomporre in macrofunzioni
realizzate da gruppi di lavoro diversi che operano in
parallelo
46
Modello RAD (2)

Le cinque fasi:
1. Analisi dellazienda:
A che serve linformazione, da dove viene, dove va, a chi serve?
2. Analisi dei dati:

Modellazione (ad es., con diagramma delle classi UML)
3. Analisi dei processi:

Modellazione del ciclo di vita degli oggetti (come vengono creati,
interrogati, modificati, cancellati)
4. Codifica:
riuso, tramite componenti sw
4th generation techniques (4GT)
5. Test e messa in esercizio

(alcune componenti sono gi state testate)
47
Modello incrementale
analisi
progetto
codifica
test
versione 1
. . .
analisi
progetto
codifica
test
versione n
Prodotti
Funzionanti
Simile al prototipale ma:

i prodotti intermedi sono funzionanti
permette una pi accurata progettazione e
programmazione delluso delle risorse
48
Modello incrementale (2)

Esempio (editore di testi):
1. Gestione file, editing, stampa documenti (core)
2. Correzioni ortografiche
3. Formattazione pagina
49
Modello a spirale (Bohem, 1988)

Raccolta
dei requisiti
iniziale
2) Planning
3) Risk analysis
1) Interazione
con il cliente
4) Ingegnerizzazione
6) Valutazione
da parte del cliente
Primo prototipo
5)
Realizzazione e
rilascio
50
Gestione dei rischi

Alcune tipologie di rischio:
Personale inadeguato
Scheduling sbagliato
Budget non realistico
Sviluppo del sistema sbagliato (validation: Are we
building the right product?, vs. verification: Are we
building the product right?, Bohem)
Alti rischi possono provocare ritardi e costi

imprevisti
Meno informazione pi rischi
51
Considerazioni sul modello a spirale

Rappresenta una razionalizzazione del modello prototipale:
Non termina con la consegna del prodotto
Ammette che il processo sia dormiente
Si presta alla gestione di progetti complessi

Pu essere significativo prevedere il numero delle
iterazioni
Pu essere integrato con altri approcci (modello ad
assemblaggio dei componenti)
Sta acquistando sempre maggiore popolarit
Alcuni CASE tool lo supportano
Il cliente spesso scettico (converge?)
Recente evoluzione: modello ad assemblaggio di
componenti
52
Modello ad assemblaggio di componenti

Le fasi 4 e 5 del ciclo di vita a spirale vengono
unificate, e comprendono la seguente sequenza di
attivit
Identificazione dei
componenti di interesse
Realizzazione dei
componenti non
disponibili
Inserimento dei nuovi
componenti in libreria
Ispezione dei
componenti di libreria
Estrazione dei
componenti disponibili
Realizzazione delln-esima
iterazione del sistema
53
Concurrent engineering: nasce in ambito
manifatturiero per:
eliminare i rischi di insuccesso che nascono dalla
separazione tra le varie funzioni industriali
(marketing, R&D, process engineering,
manifacturing, ...)
ridurre i costi e le difficolt produttive che nascono
dalla logica di comunicazione formale
ridurre i tempi di produzione che derivano da uno
sviluppo prodotti essenzialmente sequenziale
La risposta: Integrazione di metodi, tools, cultura
54
Concurrent Engineering
Sviluppo sequenziale
Base delivery
Release 1
Release 2
Release 3
Base delivery
Mod1
Mod2
Integr.
Release 1
...
Release 2
Release
La differenza
rispetto ai modelli
di processo
incrementali o a
spirale la
granularit e la
dimensione dei
processi che
vengono attivati in
simultanea (fasi vs
processi completi)
55
Extreme Programming (XP)

Approccio recente (1996)
Obiettivi:
Maggiore coinvolgimento del cliente (customer
satisfaction)
Rispondere ragionevolmente ai cambiamenti nei
requisiti (anche quelli tardivi)
Enfasi sul lavoro di gruppo (che pu coinvolgere anche
il cliente)
Ridurre il numero di regole e di procedure (lightweight,
o agile methodology)
Forte enfasi sul test
56
Ciclo di vita: modello XP
http://www.extremeprogramming.org/
57
Alcune regole di XP: codifica
The customer is always available.

Code must be written to agreed standards.
Code the unit test first.
All production code is pair programmed.
Only one pair integrates code at a time.
Integrate often.
Use collective code ownership.
Leave optimization till last.
No overtime.
58
Il mondo open source: alcuni link

Eric S. Raymond's Home Page
http://www.catb.org/~esr/
Articolo The Cathedral and the Bazaar

http://www.catb.org/~esr/writings/cathedral-bazaar/
In italiano: http://www.apogeonline.com/openpress/doc/cathedral.html
Table of Contents:
The Cathedral and the Bazaar

The Mail Must Get Through
The Importance of Having Users
Release Early, Release Often
How Many Eyeballs Tame Complexity
When Is a Rose Not a Rose?
Popclient becomes Fetchmail
Fetchmail Grows Up
A Few More Lessons from Fetchmail
Necessary Preconditions for the Bazaar Style
The Social Context of Open-Source Software
On Management and the Maginot Line
Epilog: Netscape Embraces the Bazaar
59
Tecniche e linguaggi di quarta

generazione (4GT/4GL)
Strumenti e linguaggi caratterizzati da un elevato
livello di astrazione
Linguaggi dichiarativi
Formalismi/linguaggi grafici
Generazione automatica del codice maggiore
produttivit
60
Un esempio Open Source: ArgoUML
http://argouml.tigris.org/
61
Tecniche e linguaggi di quarta

generazione (2)
Strumenti difficili da usare (difficolt paragonabile ai
linguaggi di programmazione convenzionali)
Il codice generato potrebbe essere inefficiente
La manutenzione difficile
Lapproccio sembra essere indicato per

applicazioni di piccole dimensioni
Non si risparmia tempo nellanalisi, progetto e test
62
Metodi formali
Formalismi rigorosi (logici/algebrici) per le fasi di
specifica, sviluppo e verifica
Non si basano sul linguaggio naturale
(inerentemente ambiguo)
Affrontano i problemi di ambiguit, vaghezza,
incompletezza e inconsistenza delle specifiche
Esistono linguaggi formali funzionanti (ad es.
SMV, TLA, Alloy, Z, )
Riportiamo un esempio con una sintassi
inventata
63
Metodi formali: esempio

void Ordina(int a[], int n)
// commento: ordina il vettore a, che ha n componenti tutte diverse tra
// loro, in maniera crescente
pre: I J (I 0 I n-1 J 0 J n-1 I J) a[I] a[J]
post:
//1. gli elementi del vettore risultante sono ordinati
( I (I > 0 I n-1 ) a[I] > a[I-1])
//2. gli elementi nel vett. risultante sono presenti nel vett. originario
( K (K 0 K n-1 )
L (L 0 L n-1 a[K] = pre(a[L])))
//3. gli elementi del vett. originario sono presenti nel vett.risultante
( R (R 0 R n-1 )
S (S 0 S n-1 pre(a[R]) = a[S]))
64
Metodi formali: esercizi

1. possibile semplificare la specifica precedente?
2. Scrivere un specifica valida per il caso generale, ovvero

il caso in cui non sia valida la precondizione che
impone che tutti gli elementi del vettore sono distinti
fra loro.
65
Metodi formali (2)

Vantaggi:
Permettono controlli formali sulle specifiche
Permettono la verifica automatica di incompletezze e
inconsistenze nelle specifiche
Permettono la generazione automatica del codice
Difficili ad usarsi, richiedono personale specializzato
Lenti nellutilizzo
Non molto validi come forma di comunicazione con
lutente
66
Metodi formali: sviluppi recenti
Recentemente sono stati sviluppati strumenti e

metodologie che risolvono, in parte, i problemi
dei metodi formali, in particolare:
Offrendo una migliore gestione dei processi di

forward e backward engineering
Garantendo unefficienza accettabile
Offrendo utili metafore grafiche
Un esempio dato dal tool Alloy Analyzer

(alloy.mit.edu), che fornisce, fra laltro,
strumenti per lanalisi di diagrammi delle classi
UML
67
Un esempio in AlloyAnalyzer
module
alloyExamples/prog_sw_1/IIIappello_2005
// 1. encoding of UML class diagram
// 1.a classes and associations
// 1.b inverse associations
// 1.c disjointness & completeness
// 2. encoding of constraints
// 3. verification of assertions
Generato
automaticamente
// 1.a --EXAMPLE
sig Visita {
assistito: one Persona,
medico: one Persona,
indicazione: set Prescrizione
}
// 1.b --EXAMPLE
fact reverseAssistito {
all p: Persona |
p.assistito.assistito = p
}
// 2. --EXAMPLE
fact noMedicoAssistito {
// un medico non pu mai visitare
// se stesso
all v: Visita |
v.medico != v.assistito
}
68
Un esempio in AlloyAnalyzer (cont.)

assert noDueVisiteStessaPrescrizione {
// true assertion:
// implied by cardinality constraints
// due visite distinte non possono
// avere prescrizioni in comune
all v1, v2: Visita |
v1 != v2 =>
no v1.indicazione & v2.indicazione
}
check noDueVisiteStessaPrescrizione for 2
Chiediamo la verifica
di questa affermazione
69
Prodotto e processo: riassunto

Il prodotto SW ed il relativo processo di
produzione differiscono notevolmente da quelli di
altri prodotti industriali
Le tecnologie e le metodologie si evolvono
rapidamente
necessaria una (auto)formazione continua, per
restare aggiornati!
70
Metodi formali: soluzioni (1)

1. S, in due modi alternativi:
1. Eliminando il secondo vincolo
2. Eliminando il terzo vincolo
71
Metodi formali: soluzioni (2)

void Ordina(int a[], int n)
// commento: ordina il vettore a, che ha n componenti
// in maniera non decrescente
pre: nessuna
post:
//1. gli elementi del vettore risultante sono ordinati tramite un
// vettore perm, con n elementi compresi fra 0 e n-1
( I (I > 0 I n-1 ) pre(a[perm[i]]) pre(a[perm[i-1]])
//2. fra gli elementi del vettore perm sono presenti tutti gli indici
( K (K 0 K n-1 )
L (L 0 L n-1 K = perm[L])
//3. alternativo al precedente: tutti gli elementi di perm sono distinti
I J (I 0 I n-1 J 0 J n-1 I J)
perm[I] perm[J]
72
Soluzione allesercizio 2 in OPL/ILOG

int+ n = ...; // # of elements of the input array
int maximum = maxint;
range myInt [-maximum..maximum];
Schema dei dati
range indexes [0..n-1];
myInt pre_a[0..n-1] = ...;
// input array
var indexes perm[indexes];
// guessed permutation
Vettore perm
solve {
// 1. elements of the output array
//
(implicitly defined as pre_a[perm]) are sorted
forall (i in 1..n-1)
pre_a[perm[i]] >= pre_a[perm[i-1]];
// 2. all elements of perm are different
//
--> perm is a permutation
alldifferent(perm);
Vincoli
};
73

Lingua

Benvenuto in Scribd!

Ingegneria del Software (Ing.Informatica Nuovo Ord.) Canale M-Z / A.A. 2005-06

Caricato da

Informazioni sul documento

Descrizione:

Data di caricamento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Descrizione:

Copyright:

Formati disponibili

Ingegneria del Software (Ing.Informatica Nuovo Ord.) Canale M-Z / A.A. 2005-06

Titolo originale:

Caricato da

Descrizione:

Copyright:

Formati disponibili

Titoli correlati

Ingegneria del Software

(Ing.Informatica Nuovo Ord.)

Il processo di produzione del SW

Marco Cadoli, Universit La Sapienza, set 2005

Introduzione, ciclo di vita del SW

Ing. del SW: Prima parte Sez I

Marco Cadoli, Universit La Sapienza, set 2005

I. Introduzione, ciclo di vita del SW

Marco Cadoli, Universit La Sapienza, set 2005

I.1. COS LINGEGNERIA DEL

Ing. del SW: Prima parte Sez I

Marco Cadoli, Universit La Sapienza, set 2005

Possibili definizioni dellIng. Del SW

Marco Cadoli, Universit La Sapienza, set 2005

Breve storia dellIng. Del SW

Diffusione dei computer (~1955-65):

Grandi sistemi SW ( 1965):

Marco Cadoli, Universit La Sapienza, set 2005

Crisi del software

Cambiamento nei requisiti influenza su tutto il

Marco Cadoli, Universit La Sapienza, set 2005