Sperimentazioni di Ingegneria del Software

1. Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2008

2. Obiettivi del corso • Approfondire la notazione UML (Unified Modeling Language) • Approfondire le caratteristiche dei processi di sviluppo detti orientati agli oggetti • Sperimentare con strumenti CASE (Computer Aided Software Engineering) l’uso della notazione UML e dei processi di sviluppo object-oriented

3. Pre-requisiti • I medesimi di Ingegneria del Software (logica, basi dati etc.) • Conoscere il contenuto del corso di Ingegneria del Software

4. Organizzazione • Parte I: Ingegneria del Software - orientato agli oggetti - con processi e metodologie orientati agli oggetti • Breve riepilogo ed approfondimento su alcuni aspetti della ingegneria del software • The Unified Process (Rational/IBM) • Diagrammi UML (2.0) • Parte II: Ingegneria della progettazione con pattern; rappresentazione di pattern di progetto (design pattern) e di architettura (architectural pattern) con diagrammi UML (eventualmente introduzione ai framework) • Parte III: Strumenti di sviluppo; esercitazioni guidate in laboratorio • Parte IV: Progetto d’esame

5. Materiale di supporto • Testo di riferimento: C. Larman, Applicare UML e i pattern, Terza edizione (prima edizione italiana), Pearson. • Esercizi su UML: Bennet, Skelton, Lunn, Introduzione a UML, Collana Schaum’s, McGraw-Hill. • Materiale aggiuntivo dato dai docenti (disponibile a http://www.di.unito.it/~berio)

6. Ulteriori richieste • berio@di.unito.it • bono@di.unito.it

7. Il problema della Ingegneria del Software (IEEE) • Strategie sistematiche, a partire da richieste formulate del committente, per lo sviluppo, esercizio e manutenzione del software • Studio di tali strategie

8. Definizioni • Processo di sviluppo del software e sua rappresentazione • Ingegneria dei requisiti e della progettazione; analisi e progettazione etc. • Pratiche, metodi (usate in compiti) • Metodologia di sviluppo del software

9. Ingegneria dei Requisiti • Identificazione, rappresentazione e gestione dei requisiti del software • Produce il modello analitico (Pressman) o specifica dei requisiti • Usualmente distinti in funzionali e non funzionali • Più o meno semplice identificarli: talvolta i requisiti devono essere trovati in modo esplicito (obiettivi del sistema…requisiti del software…ipotesi ambientali)

10. Ingegneria della Progettazione • Produce il modello di progetto (Pressman) o specifica del software cioè dell’architettura del software e dei suoi componenti • Ottenimento di una certa qualità del software descritta attraverso attributi di qualità (quality forecasting and assessment) • Guidata da principi di progettazione (per costruire software di qualità)

11. Gestione della Ingegneria del Software • Qualità del processo • Stime sulla bontà del processo di sviluppo • Project management, pianificazione dei compiti (o attività)

12. Vantaggi dell’orientamento agli oggetti nella Ingegneria del Software • Correttezza, affidabilità, robustezza • Prestazioni • Usabilità • Verificabilità • Manutenibilità • Riparabilità • Evolvibilità • Riusabilità • Portabilità • Comprensibilità • Interoperabilità Esempio di attributi di qualità Ragioni principali: garantisce al meglio la tracciabilità, tende a nascondere le implementazioni

13. Vantaggi dell’orientamento agli oggetti con l’uso di pattern nella Ingegneria del Software • Manutenibilità • Riparabilità • Evolvibilità • Riusabilità • Portabilità • Comprensibilità • Interoperabilità Ragione principale: sfrutta al meglio le migliori conoscenze pregresse su come raggiungere buone valutazione degli attributi elencati a lato

14. Processo iterativo • Small steps (timeboxed), feedback and refinement 2 weeks 2 weeks

15. Processo incrementale (incremental delivery)

16. Quick plan Communication Modeling Quick design Deployment delivery & feedback Construction of prototype Processo evolutivo

17. Unified Process • Iterativo, incrementale (evolutivo) • Basato su fasi: ideazione (inception), elaborazione (elaboration), costruzione (construction), transizione (transition) • Iterazioni iniziali scelte in base al rischio, alle aspettative del cliente e da un’architettura preliminare • Iterazioni di elaborazione centrate sull’architettura • Inizialmente sviluppato da Rational (acquisita da IBM), la società dei promotori storici di UML: Booch, Jacobson, Rumbaugh

18. Unified Process • Attenzione: le fasi non sono (necessariamente) iterazioni. Attività generiche (Larman ed UP le chiamano Discipline)

19. Fasi UP • Ideazione: visione, studio economico, stime approssimate dei costi e dei tempi --- molto simile ad una fattibilità ma basata sulla rappresentazione di casi d’uso • Elaborazione: visione raffinata, implementazione iterativa del nucleo dell’architettura, identificazione della maggior parte dei requisiti, risoluzione rischi maggiori, stime più realistiche • Costruzione: implementazione di ciò che resta, cioè degli elementi più semplici ed a minor rischio, preparazione del rilascio (deployment) • Transizione: beta test e rilascio

20. Glossario UP • Rilascio (release): un sottoinsieme stabile ed eseguibile del prodotto finale • Elaborato (artifact): un qualunque documento ovvero modello sviluppato • Sistema: il sistema software • Pietra miliare (milestone): fine di un’iterazione ove dovrebbero essere ottenuti risultati significativi, necessari per prendere ulteriori decisioni • Iterazione: passo con obiettivi ben definiti (es. release, diagrammi UML, stime etc.) • Incremento: differenza tra due release consecutivi

21. Uso di UML in UP • Solo UML è usato in UP (ad esempio, non si usano DFD) • I vari diagrammi sono usati con una certa variabilità in UP: se un diagramma non è utile non è necessario usarlo ma tale scelta deve essere indicata esplicitamente; UP dovrebbe essere specializzato prima di essere usato • Tuttavia, UP stesso consiglia pratiche e metodi che indicano quando e come usare alcuni diagrammi UML • I vari diagrammi sono trattati in UP seguendo principalmente iterazioni (quali diagrammi) e incrementi o evoluzioni (incrementi definiti su uno stesso diagramma)

22. Diagrammi UML usati (usabili) in UP • Diagramma dei casi d’uso • Diagramma di attività • Diagramma delle classi • Diagramma di sequenza • Diagramma di comunicazione • Diagramma statechart • Diagramma dei package • Diagramma componenti e deployment

23. Modelli usualmente prodotti UML e UP (I) a b c Principi di progettazione per la qualità del software (pattern di progetto e di architettura) Raffinamento, analisi linguistiche, passaggi etc. a b Generatori parametrizzati di codice, framework c

24. UML e UP (II) Raffinamento r r Forza una visione “black box” del sistema (software) anche se ciò è discutibile nella filosofia object-oriented ove le classi (corrette) sono la principale giustificazione della maggiore qualità

25. UP ed altri elaborati (esempio) r r

26. Fig. 6.1

27. Rappresentazione delle Iterazioni

28. i indica inizio ed r raffinamento (il raffinamento è spesso un incremento sull’elaborato)

30. Caso POS NextGen • Un POS (Point Of Sale) richiede lo sviluppo di software utilizzato tra l’altro per registrare vendite ed i pagamenti, in negozi e supermercati. Comprende componenti hardware, e software. Alcune funzionalità di servizio, ad esempio il calcolo delle imposte, sviluppate da terzi, e l’inventario devono interagire con il POS. Il software POS deve essere relativamente tollerante ai guasti: ad esempio, se alcune funzionalità di servizio non sono funzionanti, il software deve comunque permettere di registrare i pagamenti in modo che l’attività non si fermi. • Il software POS deve essere in grado di usare terminali diversi ed interfacce diverse, browser, PDA, touch screen, interfacce dedicate. • Poiché il software verrà venduto a diversi clienti, è necessario pensare al grado di personalizzazione.

31. UP e Casi d’uso • In UP i casi d’uso costituiscono la guida principale: si dice infatti UP che è “use case driven” • Ciò implica che: • I requisiti funzionali dovrebbero essere descritti principalmente con casi d’uso • I casi d’uso sono usati per la pianificazione delle iterazioni (incluse anche le stime) • La progettazione è poi basata sui casi d’uso da realizzare • I manuali utente sono influenzati dai casi d’uso • I test di sistema e di accettazione sono influenzati dai casi d’uso • I casi d’uso possono influenzare la visione (cioè i casi d’uso possono essere scritti per definire meglio la visione)

32. Casi d’Uso e Ideazione • I casi d’uso sono interessanti descrizioni di scenari d’uso del sistema (software) • I casi d’uso possono nella fase d’ideazione essere sviluppati secondo tre gradi: • Breve • Informale • Dettagliato • UP consiglia di concentrarsi nella ideazione sullo sviluppo dettagliato di circa il 10% dei casi maggiormente significativi per la riuscita del progetto • I casi d’uso possono essere quindi organizzati come diagramma (UML) ma il diagramma è solo una visualizzazione parziale e, da solo, non serve a niente!! I casi d’uso sono principalmente rappresentati con testo strutturato (template)

33. Rappresentazione dei casi d’uso (UML) • Template (funzione anche dello strumento CASE) • Diagramma dei casi d’uso (UML) • Un esempio: • Elabora vendite • Breve • Dettagliato

34. Scrivere i Casi d’Uso nella Ideazione ed Elaborazione • Stile essenziale e conciso (per non eliminare a priori eventuali alternative, che costituiscono soluzioni migliori): ignorare le interfacce, concentrarsi sullo scopo dell’attore; evitare stile troppo concreto nella ideazione e nelle iterazioni iniziali di elaborazione • Scrivere il caso d’uso a “scatola nera”: indicare solo cosa fa il sistema (software) senza indicare come verrà fatto (il più possibile) • Concentrarsi sul risultato d’interesse che il caso d’uso deve produrre per l’attore principale • Scegliere se usare una o due colonne • Scegliere il formato: breve, informale, dettagliato

35. Identificare i Casi d’Uso (Ideazione ed Elaborazione) • Identificare gli attori primari ed i loro obiettivi; gli attori primari sono sempre esterni al sistema, quindi aiutano a stabilire i confini di cosa è parte del software da sviluppare e cosa rimane esterno • Definire e rappresentare con UML (diagramma del caso d’uso/diagramma d’attività) i casi d’uso che soddisfano gli obiettivi degli attori primari • Usare check-list per identificare altri attori primari (pag. 89) • Verificare l’utilità dei casi d’uso identificati: • Chiedere ad altri • Valutare se si tratta di un “processo elementare di business” • Valutare le “dimensioni”

36. Fig. 6.2

37. Fig. 6.3 Elabora Vendite

38. Fig. 6.4

39. Casi d’uso e Iterazione ed Incrementalità • Iterazione: scegliere i casi da descrivere in forma dettagliata e realizzarli in codice; la realizzazione in codice indicherà il feedback • Incrementalità (o raffinamento): incrementare la descrizione (breve ovvero informale) con una descrizione dettagliata; approfondire eventualmente sezioni del template. • Incrementalità: aggiungere casi d’uso (tipicamente solo nella ideazione)

40. Casi d’Uso nella Ideazione di NextGen

41. Riassunto (Iterazione nella Ideazione) • Pag. 133

42. Obiettivi dell’Elaborazione • Sulle iterazioni: • Iterazioni guidate dal rischio, brevi e con durata fissata • Iniziare la programmazione (non di un prototipo ma del vero e proprio software), presto • Frequente test • Nelle iterazioni: • Scoperta (dedotta, trovata) la maggior parte dei requisiti (quelli più rischiosi), rappresentati da casi d’uso dettagliati • Definire la corrispondente architettura del software • Definire le azioni correttive del rischio (di ogni tipo) • Stime approfondite

43. Elaborazione ed Elaborati • Ancora casi d’uso (raffinati) • Modello del dominio • Diagrammi di sequenza di sistema e contratti delle operazioni • Modello delle classi di progetto • Architettura del software • Modello dei dati • Descrizione dell’interfaccia utente: navigabilità, usabilità etc.

44. Elaborazione: Iterazione 1

45. Obiettivi della Iterazione 1 • Realizzare una prima versione del modello delle classi del dominio di business • Implementare il seguente scenario del caso d’uso Elabora Vendite: inserire gli articoli e ricevere un pagamento in contanti • Implementare un caso d’uso Avviare il sistema necessario per le esigenze di inizializzazione • Non si considerano “requisiti complessi” come articolare regole di business e connessioni ad altri sistemi (software) esterni

46. UML e UP (II) Raffinamento r r Forza una visione “black box” del sistema (software) anche se ciò è discutibile nella filosofia object-oriented ove le classi (corrette) sono la principale giustificazione della maggiore qualità

47. Modello del Dominio in UP • Usare il diagramma UML delle classi per esprimere il modello del dominio • Diagramma delle classi del dominio del business: • Diagramma delle classi tipicamente privato delle operazioni e di altre caratteristiche delle classi di progetto • Ogni classe dovrebbe essere definita in modo che il diagramma costituisca un’organizzazione per il glossario dei termini

48. Posizione in UP del modello del dominio

49. Posizione del modello di dominio

50. Costruire il modello del dominio I • Trovare le classi • Usare categorie di classi (Pag. 149) • Usare i nomi e le frasi nominali (pag.150) • Usare pattern di analisi (non trattati da Larman) • Trovare le associazioni • Usare categorie di associazioni comuni • Caratterizzare i ruoli attraverso la cardinalità e verso di lettura o navigabilità) • Trovare gli attributi • Caratterizzare il tipo di attributo, derivato o non derivato • Caratterizzare tipo di dato • Introdurre classi per tipo di dato specializzato