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

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

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

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

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)

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

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

Definizioni Processo di sviluppo del software Metodologia di sviluppo del software Attività, metodi, pratiche Ingegneria dei requisiti e della progettazione; analisi e progettazione etc.

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)

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

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

Vantaggi della Ingegneria object-oriented Correttezza, affidabilità, robustezza Prestazioni Usabilità Verificabilità Manutenibilità Riparabilità Evolvibilità Riusabilità Portabilità Comprensibilità Interoperabilità Esempio di attributi di qualità

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

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

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

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

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

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

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)

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

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

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à

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

Fig. 6.1

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

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)

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

Fig. 6.7

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.

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)

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)

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

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

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”

Fig. 6.2

Fig. 6.3 Elabora Vendite

Fig. 6.4

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)

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

Riassunto (Iterazione nella Ideazione) Pag. 133

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

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.

Elaborazione: Iterazione 1

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

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à

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

Posizione in UP del modello del dominio

Posizione del modello di dominio

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

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

Classi descrittive

POS NextGen: classi del dominio

Attributi derivati

Attributi usati come riferimenti

Attributi e Tipo di Dato ProductID pID: ProductID

Attributi e Tipo di Dato

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

Modello (parziale) del dominio, POS NextGen

Modello (parziale) del dominio, POS NextGen productID

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

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

POS NextGen, lo scenario di elabora vendite

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

POS NextGen, uno scenario di elabora vendite

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

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

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

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

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

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

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à!

Transizione al progetto: legami tra elaborati

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

Dipendenze tra package

Package: alternative di rappresentazione

Pattern Layer

Layers, Partitions

Operazioni di sistema ed architettura a layer

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

Notazione base di un diagramma di comunicazione

Diagrammi di sequenza e di comunicazione (I)

Diagrammi di sequenza e di comunicazione (II)

Messaggi e causalità

Link e messaggi

Messaggi intra-oggetto

Creazione di oggetti dei diagrammi di comunicazione

Leggere un diagramma di comunicazione

Messaggi condizionali

Messaggi condizionali e mutua esclusione

Interazione di messaggi

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