La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

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

Presentazioni simili


Presentazione sul tema: "Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2007."— 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) luso 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 desame

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 Schaums, 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è dellarchitettura 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 luso di pattern Manutenibilità Riparabilità Evolvibilità Riusabilità Portabilità Comprensibilità Interoperabilità

14 Processo iterativo Small steps (timeboxed), feedback and refinement 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 dallarchitettura 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 duso Elaborazione: visione raffinata, implementazione iterativa del nucleo dellarchitettura, 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 uniterazione 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 duso 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) IdeazioneElaborazioneCostruzioneTransizione Modello di business Casi duso (di business), classi (di business), etc. Modello analitico (non definito in UP) Casi duso 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 a Raffinamento, analisi linguistiche, passaggi etc. b Principi di progettazione per la qualità del software (pattern di progetto e di architettura) c Generatori parametrizzati di codice, framework Modelli usualmente prodotti

22 UML e UP (II) IdeazioneElaborazioneCostruzioneTransizione Modello di business Classi del dominio di business Modello analitico (non definito in UP) Casi dusoCasi duso raffinati, diagrammi di sequenza di sistema Modello di progetto Architettura logica e fisica (package e deployment), Interazioni tra oggetti, Modello dei Dati Codice 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à r Raffinamento r

23 UP ed altri elaborati (esempio) IdeazioneElaborazioneCostruzioneTransizione 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, dellelaborazione, r r

24 Fig. 6.1

25 Rappresentazione delle Iterazioni It N°IdeazioneElaborazioneCostruzioneTransizione Definizione del business Cosa deve essere prodotto come elaborato Etc. Ing. RequisitiCosa deve essere prodotto come elaborato Ing. Progettazione Cosa deve essere prodotto come elaborato CodiceNACosa deve essere prodotto come elaborato

26 Elaborato IdeazioneElaborazioneCostruzioneTransizione Definizione del business Modello del dominio di business i r r... Ing. dei requisiti Modello dei casi dusoir r r... Specifica supplementareir r r... Glossarioir r r... Visioneir r r... Diagrammi di sequenza di sistema e contratti delle operazioni i r r... Ing. progettazione Modello delle classi di progetto i r...r r r... Architetturai r r... Modello dei dati i r...r r r... Codice Gestione…. i indica inizio ed r raffinamento (il raffinamento è spesso un incremento sullelaborato)

27 ElaboratoIdeazioneElaborazi one Costruzio ne Transizi one Definizione del business Modello del dominio di business i r r... Ing. dei requisiti Modello dei casi duso8/115/1r r r... Specifica supplementareir r r... Glossarioir r r... Visioneir r r... Diagrammi di sequenza di sistema e contratti delle operazioni i r r... Ing. progettazione Modello delle classi di progetto i r...r r r... Architetturai r r... Modello dei dati i r...r r r... Codice Gestione….

28 Fig. 6.7

29 Caso POS NextGen Un POS (Point Of Sale) richiede lo sviluppo di software utilizzato tra laltro 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 linventario 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 lattività 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 duso In UP i casi duso costituiscono la guida principale: si dice infatti UP che è use case driven Ciò implica che: –I requisiti funzionali dovrebbero essere descritti principalmente con casi duso –I casi duso sono usati per la pianificazione delle iterazioni (incluse anche le stime) –La progettazione è poi basata sui casi duso da realizzare –I manuali utente sono influenzati dai casi duso –I test di sistema e di accettazione sono influenzati dai casi duso –I casi duso possono influenzare la visione (cioè i casi duso possono essere scritti per definire meglio la visione)

31 Casi dUso e Ideazione I casi duso sono interessanti descrizioni di scenari duso del sistema (software) I casi duso possono nella fase dideazione 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 duso possono essere quindi organizzati come diagramma (UML) ma il diagramma è solo una visualizzazione parziale e, da solo, non serve a niente!! I casi duso sono principalmente rappresentati con testo strutturato (template)

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

33 Scrivere i Casi dUso 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 dellattore; evitare stile troppo concreto nella ideazione e nelle iterazioni iniziali di elaborazione Scrivere il caso duso a scatola nera: indicare solo cosa fa il sistema (software) senza indicare come verrà fatto (il più possibile) Concentrarsi sul risultato dinteresse che il caso duso deve produrre per lattore principale Scegliere se usare una o due colonne Scegliere il formato: breve, informale, dettagliato

34 Identificare i Casi dUso (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 duso/diagramma dattività) i casi duso che soddisfano gli obiettivi degli attori primari –Usare check-list per identificare altri attori primari (pag. 89) Verificare lutilità dei casi duso 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 duso 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 duso (tipicamente solo nella ideazione)

39 Casi dUso nella Ideazione di NextGen DettagliatoInformaleBreve 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 dellElaborazione 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 duso dettagliati –Definire la corrispondente architettura del software –Definire le azioni correttive del rischio (di ogni tipo) –Stime approfondite

42 Elaborazione ed Elaborati Ancora casi duso (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 dellinterfaccia 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 duso Elabora Vendite: inserire gli articoli e ricevere un pagamento in contanti Implementare un caso duso 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) IdeazioneElaborazioneCostruzioneTransizione Modello di business Classi del dominio di business Modello analitico (non definito in UP) Casi dusoCasi duso raffinati, diagrammi di sequenza di sistema Modello di progetto Architettura logica e fisica (package e deployment), Interazioni tra oggetti, Modello dei Dati Codice 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à r Raffinamento r

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 unorganizzazione 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 1.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) 2.Trovare le associazioni Usare categorie di associazioni comuni Caratterizzare i ruoli attraverso la cardinalità e verso di lettura o navigabilità) 3.Trovare gli attributi Caratterizzare il tipo di attributo, derivato o non derivato Caratterizzare tipo di dato 4.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 1.Verificare le classi introdotte Alternativa classi/attributi Classi descrittive 2.Verificare gli attributi Non introdurre attributi usati principalmente per riferirsi ad altre classi; piuttosto usare associazioni 3.Verificare le associazioni Verificare lindipendenza di associazioni diverse coinvolgenti le stesse classi

58 Modello (parziale) del dominio, POS NextGen

59 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 duso) Le operazioni possono essere usate per valutare ad esempio i function points

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

62 POS NextGen, lo scenario di elabora vendite

63 Contratto di unoperazione di sistema Nome operazione Riferimenti al (ai) caso duso 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 unistanza 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 unistanza 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 Modello del dominio Pre – post condizioni Usato per esprimere Contratto Parte di Usato per incrementare 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 unassociazione

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 dellarchitettura 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

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, allinterno 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


Scaricare ppt "Sperimentazioni di Ingegneria del Software G.Berio V. Bono 2007."

Presentazioni simili


Annunci Google