Sperimentazioni di Ingegneria del Software

Presentazione sul tema: "Sperimentazioni di Ingegneria del Software"— Transcript della presentazione:

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

6 Ulteriori richieste

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 UML e UP (I) a b c Raffinamento, analisi linguistiche, passaggi etc.
Modelli usualmente prodotti Ideazione Elaborazione Costruzione Transizione Modello di business Casi d’uso (di business), classi (di business), etc. Modello analitico (non definito in UP) Casi d’uso raffinati, classi del dominio di business, diagrammi di sequenza di sistema Modello di progetto Architettura logica e fisica (package e deployment), Interazioni tra oggetti, Modello dei Dati Codice a b c Raffinamento, analisi linguistiche, passaggi etc. Principi di progettazione per la qualità del software (pattern di progetto e di architettura) a b Generatori parametrizzati di codice, framework c

22 UML e UP (II) Raffinamento r r
Ideazione Elaborazione Costruzione Transizione Modello di business Classi del dominio di business Modello analitico (non definito in UP) Casi d’uso Casi d’uso raffinati, diagrammi di sequenza di sistema Modello di progetto Architettura logica e fisica (package e deployment), Interazioni tra oggetti, Modello dei Dati Codice 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)
Ideazione Elaborazione Costruzione Transizione Definizione del business Visione, specifiche supplementari, glossario Ingegneria dei Requisiti Visione raffinata, specifiche supplementari (caratteristiche), regole di business (dominio), glossario Ingegneria della progettazione Codice Gestione… Rischi e loro gestione, specializzazione di UP, piano della prima iterazione, dell’elaborazione, r r

24 Fig. 6.1

25 Rappresentazione delle Iterazioni
It N° Ideazione Elaborazione Costruzione Transizione Definizione del business Cosa deve essere prodotto come elaborato Etc. Ing. Requisiti Ing. Progettazione Codice NA

26 Elaborato Ideazione Elaborazione Costruzione Transizione Definizione del business Modello del dominio di business i r r... Ing. dei requisiti Modello dei casi d’uso i r r r... Specifica supplementare Glossario Visione Diagrammi di sequenza di sistema e contratti delle operazioni Ing. progettazione Modello delle classi di progetto i r... r r r... Architettura Modello dei dati Codice Gestione…. i indica inizio ed r raffinamento (il raffinamento è spesso un incremento sull’elaborato)

27 Definizione del business Ing. dei requisiti
Elaborato Ideazione Elaborazione Costruzione Transizione Definizione del business Modello del dominio di business i r r... Ing. dei requisiti Modello dei casi d’uso 8/1—15/1 r r r... Specifica supplementare i Glossario Visione Diagrammi di sequenza di sistema e contratti delle operazioni Ing. progettazione Modello delle classi di progetto i r... r r r... Architettura Modello dei dati Codice Gestione….

28 Fig. 6.7

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

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

31 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)

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

33 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

34 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”

35 Fig. 6.2

36 Fig. 6.3 Elabora Vendite

37 Fig. 6.4

38 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)

39 Casi d’Uso nella Ideazione di NextGen
Dettagliato Informale Breve Elabora Vendite Gestisci Restituzione Analizzare dati sulle vendite Gestire sicurezza Gestisci utenti Cash in Cash out Avviare il sistema Arrestare il sistema

40 Riassunto (Iterazione nella Ideazione)
Pag. 133

41 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

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

43 Elaborazione: Iterazione 1

44 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

45 UML e UP (II) Raffinamento r r
Ideazione Elaborazione Costruzione Transizione Modello di business Classi del dominio di business Modello analitico (non definito in UP) Casi d’uso Casi d’uso raffinati, diagrammi di sequenza di sistema Modello di progetto Architettura logica e fisica (package e deployment), Interazioni tra oggetti, Modello dei Dati Codice 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à

46 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

47 Posizione in UP del modello del dominio

48 Posizione del modello di dominio

49 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

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

51 Classi descrittive

52 POS NextGen: classi del dominio

53 Attributi derivati

54 Attributi usati come riferimenti

55 Attributi e Tipo di Dato
ProductID pID: ProductID

56 Attributi e Tipo di Dato

57 Costruire il modello del dominio II
Verificare le classi introdotte Alternativa classi/attributi Classi descrittive Verificare gli attributi Non introdurre attributi usati principalmente per riferirsi ad altre classi; piuttosto usare associazioni Verificare le associazioni Verificare l’indipendenza di associazioni diverse coinvolgenti le stesse classi

58 Modello (parziale) del dominio, POS NextGen

59 Modello (parziale) del dominio, POS NextGen
productID

60 Diagramma di sequenza di sistema
Sono parte della specializzazione di UP usata nel testo Indica un uso specializzato di un diagramma UML (il diagramma di sequenza) Serve per trovare le operazioni (messaggi) cui il sistema software dovrebbe rispondere (molto simile al DFD di contesto ma qui il diagramma di sequenza indica con precisione quando certe operazioni hanno luogo ed in quale scenario ovvero caso d’uso) Le operazioni possono essere usate per valutare ad esempio i function points

61 Posizione in UP e forma di un SSD
Operazione di sistema Un SSD Un caso d’uso : System User uno scenario 1: m () Dovrebbe chiarire cosa fa il sistema e cosa fa il resto

62 POS NextGen, lo scenario di elabora vendite

63 Contratto di un’operazione di sistema
Nome operazione Riferimenti al (ai) caso d’uso Pre-condizioni: espresse con i nomi indicati nel glossario ovvero nel modello del dominio Post-condizioni: espresse con i nomi indicati nel glossario ovvero nel modello del dominio ed in particolare indicano quali oggetti sono stati creati o distrutti, quali valori di attributi sono cambiati, quali link sono stati creati

64 POS NextGen, uno scenario di elabora vendite

65 Un Contratto I Contratto CO1: makeNewSale Operazione: makeNewSale()
Riferimenti: Elabora Vendite Precondizioni: nessuna Post condizioni: è stata creata un’istanza s di Sale s è stata associata a Register gli attributi di s sono stati inizializzati

66 Un Contratto (II) Contratto CO2: enterItem
Operazione: enterItem(itemID:ItemID, quantity:integer) Riferimenti: Elabora Vendite Precondizioni: è in corso una vendita Post condizioni: è stata creata un’istanza sli di SaleLineItem sli è stata associata alla Sale corrente sli.quantity è divenuta quantity sli è associata alla corrispondente ProductDescription usando itemID

67 Un Contratto (III) Contratto CO3: endSale() Operazione: endSale()
Riferimenti: Elabora Vendite Precondizioni: è in corso una vendita Post condizioni: sale.isComplete è diventato vero

68 Relazione Contratti – Modello del dominio
Usato per esprimere Pre – post condizioni Modello del dominio Parte di Usato per incrementare Contratto Sale dateTime isComplete : :Boolean Attributo aggiunto

69 Creare e scrivere i contratti
Creare un contratto per singola operazione parte di un SSD Descrivere le post-condizioni usando, ad esempio tre tipi di “operazioni concettuali”: Creare o distruggere un oggetto Modificare il valore di un attributo di un oggetto Creare o distruggere un’associazione

70 Creare e scrivere i contratti
I contratti devono essere scritti per tutte le operazioni trovate attraverso gli SSD? Non necessario! Nuovi classi, attributi, associazioni possono essere aggiunti al modello del dominio (tipico dei metodi iterativi ed incrementali) Ed è necessario! Le post-condizioni devono, in ogni momento, essere il più complete possibili? Non necessario ma con attenzione! Ispirati a Iterazione e Incrementalità di UP

71 Transizione al progetto nella Iterazione 1: Elaborati
Definizione dell’architettura del software (prima versione), ed in particolare: La struttura ovvero organizzazione completa del software Definizione di diagrammi di sequenza e di diagrammi di comunicazione di progetto Responsabilità degli oggetti: quali oggetti fanno che cosa! Definizione del diagramma delle classi di progetto Ereditarietà!

72 Transizione al progetto: legami tra elaborati

73 Modello di progetto Stili e pattern architetturali Design patterns * :
Register enterItem ( itemID , quantity ) ProductCatalog spec = getProductSpec Require - ments Business Modeling Design UP Artifact Relationships from Requirements/Business to Design Vision Glossary The logical architecture is influenced by the constraints and non functional requirements captured in the Supp . Spec Domain Model * Supplementary Specification Use Case Model and SSDs ... makeNewSale () (...) 1 class diagrams a static view interaction diagrams a dynamic view UI package diagrams of the logical architecture Tech Services Design Model Stili e pattern architetturali Design patterns

74 Dipendenze tra package

75 Package: alternative di rappresentazione

76 Pattern Layer

77 Layers, Partitions

78 Operazioni di sistema ed architettura a layer

79 Diagramma di Comunicazione
Un altro modo di indicare i messaggi che, all’interno di una comunicazione (scenario), vengono scambiati dagli oggetti Mentre un diagramma di sequenza indica solo che un oggetto invia (ovvero dovrebbe poter inviare) un messaggio ad un altro, un diagramma di comunicazione indica, di fatto, se ciò può avvenire

80 Notazione base di un diagramma di comunicazione

81 Diagrammi di sequenza e di comunicazione (I)

82 Diagrammi di sequenza e di comunicazione (II)

83 Messaggi e causalità

84 Link e messaggi

85 Messaggi intra-oggetto

86 Creazione di oggetti dei diagrammi di comunicazione

87 Leggere un diagramma di comunicazione

88 Messaggi condizionali

89 Messaggi condizionali e mutua esclusione

90 Interazione di messaggi

91 Lo scenario principale di Elabora Vendite: esempio di iterazione di messaggi