Sperimentazioni di Ingegneria del Software

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

2. Obiettivi del corso • Approfondire la notazione UML (Unified Modeling Language) • Approfondire le caratteristiche dei processi di sviluppo object-oriented • 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 object-oriented con processi e metodologie object-oriented • Riepilogo: ingegneria dei requisti e della progettazione, vantaggi della ingegneria object-oriented • The Unified Process (Rational/IBM) • Diagrammi UML 2.0 • Parte II: Ingegneria della progettazione con pattern; rappresentazione di pattern di progetto e di architettura 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 • Metodologia di sviluppo del software • Attività, metodi, pratiche • Ingegneria dei requisiti e della progettazione; analisi e progettazione etc.

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 • Guidata dalla qualità del software descritta attraverso attributi di qualità (quality forecasting with quality metrics) • Basata su principi di progettazione (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 della Ingegneria object-oriented • Correttezza, affidabilità, robustezza • Prestazioni • Usabilità • Verificabilità • Manutenibilità • Riparabilità • Evolvibilità • Riusabilità • Portabilità • Comprensibilità • Interoperabilità Esempio di attributi di qualità

13. Vantaggi della Ingegneria object-oriented con l’uso di pattern • Manutenibilità • Riparabilità • Evolvibilità • Riusabilità • Portabilità • Comprensibilità • Interoperabilità

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

15. Unified Process • Iterativo e incrementale • Basato su fasi: ideazione (inception), elaborazione (elaboration), costruzione (construction), transizione (transition) • Iterazioni iniziali guidate dal rischio, dal cliente e dall’architettura • Inizialmente sviluppato da Rational, la società dei promotori storici di UML: Booch, Jacobson, Rumbaugh

16. Unified Process • Warning: The phases are not iterations. Attività o compiti operativi (Larman le chiama Discipline)

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

18. Glossario UP • Release: un sottoinsieme stabile ed eseguibile del prodotto finale • Elaborato (artifact): un qualunque documento ovvero modello sviluppato • Sistema: il sistema software • 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

19. 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 consiglia pratiche e metodi che indicano quando e come usare alcuni diagrammi UML • I vari diagrammi sono trattati in UP seguendo principalmente iterazione e incrementalità (incrementi definiti su uno stesso diagramma)

20. Diagrammi UML usati 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

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

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

23. UP ed altri elaborati (esempio) r r

24. Fig. 6.1

25. Rappresentazione delle Iterazioni

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

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

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

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

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

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

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

34. Fig. 6.2

35. Fig. 6.3 Elabora Vendite

36. Fig. 6.4

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

38. Casi d’Uso nella Ideazione di NextGen

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

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

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

42. Elaborazione: Iterazione 1

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

44. 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à

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

46. Posizione in UP del modello del dominio

47. Posizione del modello di dominio

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

49. Patterns di Analisi Problem: How do you keep track of resource quotations performed before its actual trade?

50. Classi descrittive