Post on 01-May-2015
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.