Architettura del software: dai Casi d`Uso al Modello

Architettura del
software: dai Casi
d’Uso al Modello
Lorenzo Barbieri
• Sono un Senior Trainer/Consultant in
ObjectWay SpA (www.objectway.it),
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
– [email protected]
– www.geniodelmale.info
Dove eravamo rimasti...
Problema
Problema
Bisogni
Soluzione
Caratteristiche
del Sistema
Requisiti del Software
Analisi, Design, Implementazione,...
Tracciabilità
Use-Case Model
• Non esiste solo il Diagramma
“grafico” degli Use Case
• Use Case Model Survey
– Lista di diagrammi, attori e breve
descrizione
• Use Case Specification (una per
ogni Use Case)
– Descrizione
– Flussi (principale, secondari,
eccezione)
– Pre/Post Condizioni
– Requisiti supplementari dello UC
Giuoco del Calcio
Allenatore
Istruire i giocatori
Giocatore
Attaccare gli avversari
Rinviare con le mani
Portiere
Effettuare rimessa dal fondo
040205
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
...dove stiamo andando...
Problema
Bisogni
Sistema
Requisiti
Analisi
Design
Implementazione, Etc...
Tracciabilità
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
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
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
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
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
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
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
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)
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
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...
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
Ad esempio: Dallo UC...
Giocatore
Allenatore
Istruire i giocatori
...ad un primo Modello di
Analisi
Allenatore
Giocatore
Relativo allo Use Case specifico
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)
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
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
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
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..*
0..1
2..4
2, 4 ..6
*
Aggregazione
• L’Aggregazione è una forma specializzata
di Associazione, nella quale un insieme è
relazionato alle sue parti
Squadra
1
11..*
Giocatori
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!!!
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
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
Scrive lo schema
Allenatore
ScrivereSchema(Dettagli)
Lavagna
UML: Operazioni e Attributi
• Gli Attributi vanno nel secondo comparto
• Le Operazioni vanno nel terzo comparto
<<boundary>>
Lavagna
Larghezza
Altezza
Tipo
ScrivereSchema(Dettagli)
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.
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
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
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à
Ha senso separare i modelli di
Analisi e Design ?
• Vantaggi:
– 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
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
Evoluzione delle Classi
Boundary
• Le Classi Boundary diventano Form,
WebForm, WebService, controlli grafici,
interfacce a sottosistemi, o classi wrapper
per dispositivi hardware
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
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
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
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
Generalizzazione
Calciatore
Attaccante
Difensore
Portiere
Allenatore
Persona
Calciatore
Difensore
Portiere
Attaccante
Allenatore
AllenatorePortieri
Specializzazione
Persona
Persona
Calciatore
Difensore
Portiere
Attaccante
Allenatore
AllenatorePortieri
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”
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
Sequenza
Oggetto2:
Classe2
Oggetto1
Oggetto:
Classe
1:xxxxxx
2: yyyyy
3: zzzzzz
4: kkkkkkk
5: mmmmm
6: nnnnn
Oggetto3
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
Oggetto1
4: kkkkkk
Oggetto:classe
...cosa manca
Problema
Bisogni
Sistema
Requisiti
Analisi
Design
Implementazione, Etc...
Tracciabilità
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
Ricordatevi di compilare il modulo di Feedback
DOMANDE?