Slide 1

Lezione 1. La disciplina dell’Ingegneria del Software, e il software come prodotto

• [GJM91, Capp. 1, 2]

• [S2001, Cap. 1]

La disciplina S. E. - generalità Caratteristiche del prodotto software. Requisiti di qualità in diverse aree applicative

Slide 2

Software Engineering

Si occupa di teorie, metodi, strumenti per progettare, costruire e mantenere grandi sistemi

software … …cosi’ grandi da richiedere un TEAM di sviluppatori

• --> problemi di comunicazione fra persone, anche non tecnici

e da realizzare entro un dato TEMPO e BUDGET (‘cost-effective’ software development).

Parnas: “Multi-person construction of multi-version software”.

Slide 3

• Sempre piu’ sistemi sono controllati via software

• Le economie dei paesi evoluti dipendono dal software (nell’industria, nelle amministrazioni)

• ...e le spese di ingegneria del software rappresentano una frazione significativa del loro P.I.L.

• Dunque i progressi in questo settore possono avere un forte impatto economico

Importanza della disciplina

Slide 4

Prospettiva storica

Il termine SE viene introdotto in una conferenza USA del 1968 sulla crisi del software derivata dalla accresciuta potenza dei computer di terza generazione.

I costi dell’hardware crollavano, quelli del software crescevano: si sapevano scrivere buoni programmi (strutturati, efficienti), non buoni sistemi.

Molti insuccessi in 30 anni, anche recenti• AT&T SW switching system failed: long distance call paralized for almost 24

hours in USA.

• DENVER Airport: difetti software --> ritardo di 9 mesi nell’apertura dell’aeroporto. Perdite: mezzo milione di dollari al giorno.

Disciplina ancora in evoluzione (vedi dibattito su Formal Methods). Piani attuali per un curriculum universitario SE autonomo in USA.

Slide 5

Differenze fra S.E. e Computer Science

Computer Science si occupa di teorie e fondamenti; Software Engineering degli aspetti ‘pratici’ dello sviluppo di sistemi software

Le teorie della C. S. non forniscono attualmente fondamenta complete per S. E. ...

Slide 6

Cosa è un processo software?

Un insieme di attività il cui obiettivo è lo sviluppo e l’evoluzione di un sistema software

Attività fondamentali in qualunque processo software:• Specifica - cosa il sistema deve fare, e sotto quali vincoli

• Sviluppo - produzione del software

• Validazione - appurare che il sistema corrisponda alle aspettative del cliente

• Evoluzione - modifiche del sistema in risposta a evoluzioni dei requisiti iniziali

Slide 7

Esistono vari modelli (tipi) di processo software

• Waterfall

• Evolutionary development

• Formal transformation

• Integration from reusable components

Un modello puo’ essere descritto in termini di• workflow: sequenza di attività di team o individui, e inter-

relazioni

• data-flow: insieme di attività (di persone o computers) e loro connessioni input-output

• role-action: chi (persone) fa che cosa

Slide 8

Cosa sono i metodi di ingegneria del software?

Sono approcci allo sviluppo software che includono• modelli e notazioni (spesso grafici) per la descrizione di aspetti del

sistema

• regole, o vincoli che i modelli devono (mutuamente) soddisfare

• raccomandazioni pragmatiche per la ‘buona progettazione’

• guida all’uso di un dato modello di sviluppo (chi svolge quali attività in quale ordine…)

I metodi sono piu’ concreti, specifici dei modelli di sviluppo• diversi metodi possono far riferimento, ad esempio, al modello

waterfall

Slide 9

Cosa è il CASE (Computer-Aided Software Engineering)

Strumenti (software) per il supporto semi-automatico di attività del processo software. Spesso associati a un metodo specifico• es: strumento: Rational Rose; metodo: Rational Unified Process

Upper-CASE• Supportano le attività iniziali del processo: requirements,

design

Lower-CASE• Supportano le attività finali del processo: programming,

debugging and testing

Slide 10

Nello sviluppo di sistemi integrati i costi della parte software (spesso la piu’ creativa) tendono a dominare su quelli hardware.

• Il prezzo del software installato su un PC puo’ superare quello dell’hardware…

La manutenzione del sw costa piu’ dello sviluppo. La produzione su larga scala del pacchetto software Rational

Rose Modeller Edition, a sviluppo completato, costa circa un euro a copia (il costo di un CD)

• quella della FIAT Stilo no

I costi dipendono fortemente dai requisiti non -funzionali• es: performance, reliability

Quali sono i costi del software?

Slide 11

Possibili ripartizioni di costi

Costi di solo sviluppo:

25 10075500

25 10075500

25 10075500

25 10075500

Specification Design Implem. Integration and testing

Costi di sviluppocon il modello evolutionary:

Sviluppo

Evolutionary develop. System testing

Costi di sviluppo, manutenzione,evoluzione del sistema:

Spec.

Manutenzione e/o Evoluzione

Si s

t em

i sof

twar

e sp

eci f

i ci (

clie

nt-c

ont r

act o

r)

Development

Spec.

System testing (per piu’ piattaforme/config.)Sistemi software generici (per PC)

Slide 12

Quali le sfide attuali di S.E. ?

Utilizzo di legacy systems• I vecchi sistemi devono essere manutenuti, aggiornati, integrati

nei nuovi sistemi (esigenza economica)

Eterogeneità• I sistemi tendono ad essere distribuiti e ad utilizzare diverse

piattaforme hard/soft» architettura Microsoft .net

» coordination languages

Tempi di consegna sempre piu’ brevi• “…entro ieri…”

Slide 13

Le proprietà del prodotto software

Comprende tutto l’insieme degli artefatti del processo di sviluppo:• requisiti, specifiche, progetti, programmi,

• files di configurazione

• documentazione di sistema, documentazione utente

• sito web per il download di nuove versioni, correzioni, informazioni…

Prodotto ‘logico’, non ‘fisico’: molto malleabile• Si può modificare molto facilmente, anche indipendentemente dal

progetto o dalla specifica…(!) » … mentre per modificare un aereo si riparte sicuramente dal progetto

Slide 14

Due tipi di prodotto software

Prodotti generici• Sistemi ‘stand-alone’ prodotti da una azienda di sviluppo software (es:

Microsoft) e offerti a un pubblico vasto, non necessariamente specializzato.

• In crescita a partire dagli anni ‘80, con la diffusione dei PC

• Requisiti e specifica sono prodotti dallo stesso sviluppatore

Prodotti specifici (‘bespoke’)• Sistemi richiesti da un committente, o cliente, che è l’origine di

requisiti e specifica

Il maggior volume di affari e’ sui prodotti generici, Il maggior sforzo di sviluppo su quelli specifici.

Slide 15

Proprietà interne ed esterne

Si distinguono proprietà:• Esterne: quelle visibili dall’utente finale.

• Interne: quelle che riguardano chi lo sviluppa, lo mantiene, lo cambia

• Le interne aiutano a ottenere le esterne: esempio, la verificabilità aiuta a ottenere la affidabilità.

L’importanza di una data proprietà dipende dal tipo di prodotto e dal suo ambiente di utilizzo.• In sistemi safety-critical e real-time, dependability e efficienza

sono cruciali

Slide 16

Correttezza

Un programma, o la implementazione di un sistema, è funzionalmente corretto se si comporta sempre come definito nella specifica dei requisiti funzionali.

Viene verificata con metodi sperimentali (testing) o analitici (formal verification).

Slide 17

Dependability

Mix di reliability, safety, security… Reliable (affidabile)

• Proprietà statistica, espressa in termini della probabilità che il sistema operi come previsto in un determinato intervallo temporale.

» Non implica correttezza: i programmi artigianali sono ‘corretti’ quelli professionali hanno ‘known bugs’.

• Failure rate: numero di fallimenti per unità di tempo, o per n. di transazioni o di program runs

Safety critical• Quando un fallimento software può causare perdite umane

Secure• Protezione da accessi non autorizzati, e da conseguenti danni economici

Slide 18

Efficienza (efficiency, performance)

• Un sistema è efficiente se usa le sue risorse in maniera economica. Tipicamente: usare poco spazio (disco, memoria centrale) e poco tempo per fornire i propri servizi.

• Questa proprietà varia col miglioramento della tecnologia hardware (MegaBytes e MegaHertz).

• Performance evaluation mediante:» analisi di complessità degli algoritmi (caso medio, caso peggiore)

» misura sul campo

» analisi matematica di un modello

» simulazione sul modello.

Slide 19

Usabilità (usability, user-friendliness)

• Documentazione e user-interface appropriate

• Proprietà soggettiva. Es.» Spiegazioni verbose e menù sono apprezzati dall’ utente inesperto,

non dall’esperto.

• Proprietà relativa: adeguamento alle soluzioni più diffuse» Mac --> Windows

» In futuro…?

• In sistemi senza interfaccia utente (embedded): facilità di configurazione e adattamento all’ambiente hardware.

• Ricerca su nuovi paradigmi di interazione uomo-macchina

Slide 20

Robustezza

Comportamento ‘ragionevole’ anche in casi non previsti nei requisiti (es. dati input scorretti o disk error). • Indipendente dalla correctness.

• Es: un ponte che crolla per una piena di estrema gravità.

Diversi gradi di robustness vanno applicati a diversi casi – per esempio: l’input al sistema viene da un utente inesperto o da un sensore?

Slide 21

Interoperabilità

Capacità di cooperare con altri sistemi. Es. 1 - Un amplificatore HiFi accetta giradischi e

CD Es. 2 - Cooperazione fra le diverse componenti

(Spreadsheet, Word processor, Mail, Presentation) di pacchetti software integrati.

Viene ottenuta standardizzando le interfacce.

Slide 22

Manutenibilità - evolvibilità

Deve essere possibile correggere e far evolvere il software per riflettere nuovi requisiti• Ma i cambiamenti devono interessare tutta la pila di documenti

del processo

Es. - Il sistema di prenotazione aerea SABRE (American Airlines) è mantenuto ed accresciuto dagli anni ‘60.

Slide 23

Verificabilità

La specifica, il design, il codice vengono realizzati in modo da semplificarne la verifica di proprietà.

• Certi linguaggi di specifica sono più verificabili di altri.

• Il codice può venire arricchito con ‘software monitors’.

Slide 24

Riusabilità

Come evolvable ma riferito a nuovi prodotti, anziché a versioni dello stesso prodotto.

Applicabile soprattutto a parti del sistema. Librerie FORTRAN, C, Java disponibili sul

mercato. Proprieta’ ben realizzata in O-O Design (anche

attraverso ereditarietà).

Slide 25

Portabilità

Quando può girare in diversi ambienti (piattaforma HW o SW)

Si può ottenere facendo utilizzare al sistema solo un sottoinsieme stabile di risorse dell’ambiente, o di istruzioni macchina.

Slide 26

Conflitti tra proprietà del software

Esempio 1• Ottimizzare interfacce utente oppure

• l’efficienza

Esempio 2• Ottimizzare l’efficienza oppure

• la manutenibilità (mediante riuso di componenti ‘off-the shelf’)

Slide 27

Requisiti di qualità in diverse aree applicative

Information systems Real-time systems Distributed systems Embedded systems

Slide 28

Information systems

Sistemi data-oriented. La loro funzione è gestire informazione.• Costruiti attorno a un data base che viene manipolato mediante

transazioni (create, retrieve, update, delete).

• Es.: banca, biblioteca, personale dipendente.

Data integrity• Non corruzione dei dati per malfunzionamenti del sistema

Security• Protezione da accessi non autorizzati

Slide 29

Data availability• Quando e per quanto i dati diventano inaccessibili?

Transaction performance• Transazioni per unità di tempo.

Slide 30

Real-time systems

Sistemi control-oriented. • Devono rispondere a eventi esterni entro tempi prefissati,

spesso (non sempre!) brevissimi.

• Es1. Sistema controllo edificio: aumento temperat. => allarme

• Es2. Controllo mouse - 1 click, 2 click.

Tempi di risposta• Essi caratterizzano la performance in sistemi generici, ma la

correctness in sistemi real-time.

Slide 31

Distributed systems

Insieme di computers collegati da rete (nodi + link)• Banda larga e bassa error-rate ==> possibilità di distribuire le

componenti del sistema.

• Distribuzione di dati o funzioni di calcolo ?

Robust• Tolleranza a fallimenti di nodi

• Tolleranza a fallimenti di link

Slide 32

Rendere distribuito un sistema può migliorare alcune sue proprietà:

• data-replication ==> reliability

• data-distribution ==> performance

Slide 33

Embedded systems

La componente software è immersa in un sistema hardware specifico (non PC) e lo controlla.• Es. Aereo, frigorifero, robot

Requisiti meno stringenti per usabilità.• Interfaccia uomo-macchina ===> interfaccia SW-HW

Il Sistema è più evolvibile se si spostano funzionalità da HW a SW.