Slide 1 Lezione 1. La disciplina dellIngegneria del Software, e il software come prodotto [GJM91, Capp. 1, 2] [S2001, Cap. 1] La disciplina S. E. - generalità

Presentazione sul tema: "Slide 1 Lezione 1. La disciplina dellIngegneria del Software, e il software come prodotto [GJM91, Capp. 1, 2] [S2001, Cap. 1] La disciplina S. E. - generalità"— Transcript della presentazione:

1 Slide 1 Lezione 1. La disciplina dellIngegneria 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

2 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.

3 Slide 3 Sempre piu sistemi sono controllati via software Le economie dei paesi evoluti dipendono dal software (nellindustria, 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

4 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 dellhardware 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 nellapertura dellaeroporto. 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.

5 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....

6 Slide 6 Cosa è un processo software? Un insieme di attività il cui obiettivo è lo sviluppo e levoluzione 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

7 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

8 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 alluso 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

9 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

10 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 dellhardware… 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?

11 Slide 11 Possibili ripartizioni di costi Costi di solo sviluppo: 25 10075500 25 10075500 25 10075500 25 10075500 SpecificationDesignImplem.Integration and testing Costi di sviluppo con il modello evolutionary: Sviluppo Evolutionary develop.System testing Costi di sviluppo, manutenzione, evoluzione del sistema: Spec. Manutenzione e/o Evoluzione Sistemi software specifici (client-contractor) Development Spec. System testing (per piu piattaforme/config.) Sistemi software generici (per PC)

12 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…

13 Slide 13 Le proprietà del prodotto software Comprende tutto linsieme 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

14 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 è lorigine di requisiti e specifica Il maggior volume di affari e sui prodotti generici, Il maggior sforzo di sviluppo su quelli specifici.

15 Slide 15 Proprietà interne ed esterne Si distinguono proprietà: Esterne: quelle visibili dallutente 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à. Limportanza 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

16 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).

17 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

18 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.

19 Slide 19 Usabilità (usability, user-friendliness) Documentazione e user-interface appropriate Proprietà soggettiva. Es. »Spiegazioni verbose e menù sono apprezzati dall utente inesperto, non dallesperto. Proprietà relativa: adeguamento alle soluzioni più diffuse » Mac --> Windows »In futuro…? In sistemi senza interfaccia utente (embedded): facilità di configurazione e adattamento allambiente hardware. Ricerca su nuovi paradigmi di interazione uomo-macchina

20 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: linput al sistema viene da un utente inesperto o da un sensore?

21 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.

22 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.

23 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.

24 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à).

25 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 dellambiente, o di istruzioni macchina.

26 Slide 26 Conflitti tra proprietà del software Esempio 1 Ottimizzare interfacce utente oppure lefficienza Esempio 2 Ottimizzare lefficienza oppure la manutenibilità (mediante riuso di componenti off-the shelf)

27 Slide 27 Requisiti di qualità in diverse aree applicative Information systems Real-time systems Distributed systems Embedded systems

28 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

29 Slide 29 Data availability Quando e per quanto i dati diventano inaccessibili? Transaction performance Transazioni per unità di tempo.

30 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.

31 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

32 Slide 32 Rendere distribuito un sistema può migliorare alcune sue proprietà: data-replication ==> reliability data-distribution ==> performance

33 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.