Architettura del software: dai Casi d Uso al Modello

Transcript

1 Architettura del software: dai Casi d Uso al Modello

2 Lorenzo Barbieri Sono un Senior Trainer/Consultant in ObjectWay SpA ( specializzato in architetture Microsoft.NET, Windows, SQL Server, Visual Studio Team System, Virtual PC/Virtual Server Collaboro con UGIdotNET, INETA, Team System Rocks!, Windowserver.it e sono tra i soci fondatori di GUISA lorenzo.barbieri@objectway.it

3 Dove eravamo rimasti... Problema Bisogni Caratteristiche del Sistema Tracciabilità Problema Soluzione Requisiti del Software Analisi, Design, Implementazione,...

4 Use-Case Model Non esiste solo il Diagramma grafico degli Use Case Giuoco del Calcio Use Case Model Survey Lista di diagrammi, attori e breve descrizione Allenatore Istruire i giocatori Use Case Specification (una per ogni Use Case) Descrizione Flussi (principale, secondari, eccezione) Pre/Post Condizioni Requisiti supplementari dello UC Attaccare gli avversari Rinviare con le mani Giocatore Portiere Effettuare rimessa dal fondo

5 Gli Use Case non sono SOLO i disegnini Il cuore della specifica è la Use Case Specification In molte realtà la parte grafica non viene utilizzata, si usa solo la Use Case Survey e le varie Use Case Specificatio

6 ...dove stiamo andando... Bisogni Problema Sistema Requisiti Analisi Design Implementazione, Etc... Tracciabilità

7 Un piccolo ripasso... Una classe è una definizione astratta di un oggetto Definisce la struttura ed il comportamento di ogni oggetto della classe Ogni oggetto e una istanza di una classe Gli oggetti possono essere raggruppati in classi

8 UML: Diagramma delle Classi Una classe è composta da tre sezioni Nome della classe Struttura (attributi) Comportamento (operazioni) Struttura e Comportamento sono opzionali, soprattutto in fase di analisi Calciatore Calciatore

9 UML: Stereotipi Uno stereotipo è un elemento di modellizzazione che estende la semantica del metamodello Ogni classe può avere al massimo uno stereotipo Gli stereotipi comuni per le classi sono: Attore Classe Entity Classe Boundary Classe Control <<Stereotipo>> nome della classe

10 Classi di Analisi Di solito in analisi si usano 3 tipi di classi: Entity, Boundary, Control Vengono rappresentate tramite gli appositi stereotipi L uso di questi stereotipi porta a strutturare il modello ad oggetti: Informazioni persistenti -> Entity Interfacce utente -> Boundary Flusso di controllo -> Control L uso di questi stereotipi serve per: Identificare le classi principali durante l analisi e nelle prime fasi di design Ridurre il numero di stereotipi che si tende ad usare

11 Classi Entity Una classe Entity modella informazioni persistenti ed il loro comportamento Generalmente modellano entità reali: Clienti, Fornitori, Fatture, etc... Molto spesso la loro definizione avviene dall analisi di più Use Case

12 Classi Entity Le classi Entity vengono ricercate esaminando i nomi e i predicati nominali negli scenari degli Use Case: Oggetti Descrizioni dello stato di un oggetto Entità esterne e/o Attori Nessuno di questi casi

13 I Nomi vanno filtrati Termini diversi possono identificare lo stesso oggetto (ambiguità e/o incoerenza) Bisogna valutare l importanza dei nomi trovati Troppi nomi -> troppi oggetti, soprattutto per l analisi Se gli Use Case sono fatti bene è più facile

14 Classi Boundary Una classe Boundary modella la comunicazione tra l ambiente e il sistema Ce ne sono di diverso tipo: User Boundary (Finestre, Pagine Web, etc...) System Boundary (comunicazione tra sistemi) Device Boundary (sensori e altri dispositivi)

15 Classi Boundary Per trovare le classi Boundary bisogna: Esaminare ogni coppia fisica di attore / scenario e creare le ovvie classi boundary Modellare solo le astrazioni chiave Ad esempio, identificare finestre, web form, etc... Non i singoli dettagli

16 Classi Control Una classe Control modella il comportamento di uno o più (pochi) Use Case Una classe control gestisce gli oggetti controllati: Creazione, cancellazione, esecuzione, sequenza dei metodi da chiamare, etc...

17 Classi Control Durante l analisi generalmente si individua una sola classe Control per Use Case Possiamo sempre raffinarla in seguito Attenzione: Una classe control comunque NON gestisce necessariamente tutto ciò che è richiesto da un UC, ma coordina oggetti che tutti insieme implementano le funzionalità dello UC

18 Ad esempio: Dallo UC... Allenatore Istruire i giocatori Giocatore

19 ...ad un primo Modello di Analisi Allenatore Giocatore Relativo allo Use Case specifico

20 Rifinire il modello di Analisi Bisogna definire fin da subito il livello di dettaglio che si vuole dare al modello di Analisi: Individuiamo solo le Classi e le loro relazioni principali Individuiamo anche Operazioni e Attributi principali Andiamo più in dettaglio (si rischia di entrare troppo nel modello di Design)

21 Relazioni tra le Classi Gli oggetti definiscono il comportamento di un sistema collaborando uno con l altro Le relazioni definiscono la modalità di collaborazione: Associazione Aggregazione

22 Associazioni Un associazione è un collegamento semantico bi-direzionale tra classi Le associazioni sono rappresentate nei diagrammi delle classi con una linea continua che collega le classi associate <<controller>> IstruireGiocatoriMgr <<boundary>> Lavagna

23 Associazioni: nomi e/o ruoli Per chiarire il significato, un associazione può essere nominata tramite una etichetta posizionata lungo la linea dell associazione Allenatore Allena> Giocatore Alternativamente si può specificare su un lato o su entrambi un ruolo chedenota lo scopo o la capacità con la quale una classe si associa con un altra Presidente proprietario dipendente Giocatore

24 Indicatori di Molteplicità Ogni estremità di un associazione può contenere un indicatore di molteplicità Indeterminata Uno Zero o molti Uno o molti Zero o uno Da... a... Intervalli disgiunti 1 0..* 1..* , 4..6 *

25 Aggregazione L Aggregazione è una forma specializzata di Associazione, nella quale un insieme è relazionato alle sue parti Squadra * Giocatori

26 Verificare l Aggregazione Per verificare che si tratti effettivamente di Aggregazione e non di Associazione bisogna capire se si può dire è parte di : Operazioni sull insieme applicate anche alle parti? Attributi dall insieme applicabili a tutte o ad alcune parti? L Aggregazione è implicitamente asimmetrica Nel dubbio è meglio usare l Associazione!!!

27 Operazioni e Attributi Le Operazioni definiscono come un oggetto agisce e reagisce ai messaggi che riceve Una operazione dovrebbe fare una cosa (precisa) e farla bene Le operazioni si ricavano leggendo i flussi o gli eventuali diagrammi di sequenza/comunicazione presenti UC Un Attributo e una caratteristica di una classe. Gli attributi sono estratti dal testo del problema (nomi scartati in precedenza), dalla definizione della classe e/o attraverso l esperienza del dominio

28 Scoprire le Operazioni dai Diagrammi di Interazione I messaggi mostrati nei diagrammi di sequenza e/o comunicazione presenti negli Use Case sono solitamente operazioni della classe ricevente Allenatore Lavagna Allenatore Lavagna Scrive lo schema ScrivereSchema(Dettagli)

29 UML: Operazioni e Attributi Gli Attributi vanno nel secondo comparto Le Operazioni vanno nel terzo comparto Larghezza Altezza Tipo <<boundary>> Lavagna ScrivereSchema(Dettagli)

30 Ripasso: Incapsulamento Incapsulamento e nascondere dettagli di implementazione al mondo esterno. Proteggere lo stato interno degli oggetti. Proteggere il codice del client dalle modifiche realizzative dell oggetto stesso.

31 Passaggio da Analisi a Design Le classi di analisi rappresentano entità concettuali che compongono un modello logico (Modello di Analisi) del sistema sotto sviluppo Descrive e modella COME dovrà fare il sistema, non COME dovrà farlo Il Modello di Design invece è una astrazione del modello di implementazione e del relativo codice sorgente Descrive e modella un astrazione di COME il sistema realizzerà i requisiti richiesti

32 Dove siamo: Modello di analisi E una rappresentazione minima del sistema, sufficiente a catturare i requisiti e la logica essenziale del sistema Un buon modello di analisi (modello logico) Considera tutti i requisiti funzionali (use cases) NON deve modellare i requisiti non funzionali Un modello di analisi contiene: classi e loro collaborazioni rappresentano il comportamento dinamico dettagliato negli UC tracciabilità fra ogni req. funzionale e le classi che lo realizzano

33 Dove andiamo: Modello di Design Nasce come raffinamento del Modello di Analisi ma dipende anche dai requisiti non funzionali Cosa contiene: Layer e Sottosistemi Classi di design Definisce completamente le dipendenze, le associazioni (ass./ compos./aggreg.), le generalizzazioni fra le diverse classi Per le operazioni definisce la Signature completa: Nome operazione, tipo di ritorno, parametri, Visibilità, se è di istanza o di classe (statica) Per gli attributi definisce: Nome, Tipo, valori iniziali o di default, visibilità

34 Ha senso separare i modelli di Vantaggi: Analisi e Design? Permette la realizzazione di uno stesso Modello di Analisi su diverse Architetture In sistemi molto complessi aiuta a verificare le assunzioni iniziali Svantaggi: Costo di manutenzione per la sincronizzazione dei modelli (se non li mantengo sincronizzati è inutile farne due) Analisi Design

35 Evoluzione delle Classi di Analisi Una Classe di Analisi può diventare: Una singola classe di Design Una parte di una classe Una classe aggregata Un gruppo di classi che ereditano da una stessa classe Un gruppo di classi funzionalmente relazionate Una relazione Una Classe di Analisi potrebbe non essere più necessaria in Design Una Relazione fra Classi di Analisi può diventare una Classe

36 Evoluzione delle Classi Boundary Le Classi Boundary diventano Form, WebForm, WebService, controlli grafici, interfacce a sottosistemi, o classi wrapper per dispositivi hardware

37 Evoluzione delle Classi Entity Rappresentano tipicamente oggetti persistenti (su DB o altro) La loro evoluzione dipende da come verranno modellate (Dataset vs. Custom Entities ad esempio) e da una serie di altri parametri: Attributi e loro legami Operazioni sulle Entity Dipendenze con altre parti del sistema Molto spesso bisogna modellarle cercando di ridurre al minimo la dipendenza da specifici modelli di persistenza

38 Evoluzione delle Classi Control Queste classi rappresenteranno puri oggetti software Sono le classi più difficili da progettare Sono responsabili della gestione dei flussi di eventi di UC e coordinano molte azioni Gli oggetti control incapsulano la logica che non è relativa alle interfacce utente o ai dati e che viene indicata come Business Logic

39 Evoluzione delle Classi Control e Pattern La progettazione di queste classi richiede spesso l uso e la conoscenza di Pattern di vario livello Un Pattern è una soluzione comune a problemi comuni E un modo per non reinventare la ruota Permette l uso di una soluzione già adottata I Pattern possono diventare i mattoncini di tanti progetti Per approfondire: Webcast Introduzione ai design pattern

40 Ripasso: Ereditarietà L Ereditarietà identifica la relazione di è un oppure tipo di Si riferisce alle classi e non agli oggetti: non ha nome non ha senso parlare di molteplicità Calciatore Attaccante Difensore Portiere

41 Generalizzazione Calciatore Attaccante Portiere Difensore Allenatore Persona Calciatore Allenatore Difensore Portiere Attaccante AllenatorePortieri

42 Specializzazione Persona Persona Calciatore Allenatore Difensore Portiere Attaccante AllenatorePortieri

43 Ripasso: Ereditarietà Durante l Analisi, l ereditarietà viene utilizzata solo se strettamente necessario Durante il Design, l ereditarietà è raffinata per: Aumentare il riuso Incorporare classi di implementazione o di libreria Aggregazione e Ereditarietà vengono spesso confuse: Ereditarietà: è un o tipo di Aggregazione: ha un o è parte di

44 Diagrammi di Interazione I diagrammi di interazione descrivono l insieme di messaggi che un gruppo di oggetti si scambiano per effettuare una certa operazione, o per raggiungere uno scopo Ce ne sono di due tipi: diagrammi di Sequenza: mostrano in ordine temporale quali messaggi si scambiano gli oggetti diagrammi di Comunicazione (ex collaborazione): mostrano le collaborazioni tra i vari oggetti e possono includere il flusso dei dati Ognuno fornisce una vista diversa della stessa interazione

45 Sequenza Oggetto: Classe 1:xxxxxx Oggetto1 Oggetto2: Classe2 Oggetto3 2: yyyyy 3: zzzzzz 4: kkkkkkk 5: mmmmm 6: nnnnn

46 Diagrammi di Comunicazione Equivale al Diagramma di Collaborazione di UML1.x E un modo alternativo per rappresentare i messaggi scambiati da un insieme di oggetti 2: yyyyyyy 1: xxxxxxx 3: zzzzzzzz 4: kkkkkk Oggetto:classe Oggetto1

47 ...cosa manca Bisogni Problema Sistema Requisiti Analisi Design Implementazione, Etc... Tracciabilità

48 Un ulteriore modello: Modello di Implementazione Nel Modello di Implementazione sono rappresentati Processi Componenti Sottosistemi logici Deployment Bisogna valutare attentamente se farlo In UML, utile per modellare, può diventare complesso e poco utile in pratica Con altri strumenti (Team System for Software Architects ad esempio) più legati all implementazione specifica

49 Ricordatevi di compilare il modulo di Feedback DOMANDE?