Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Modellare Un Progetto Software Con UML e Il Metodo Dei Colori
Modellare Un Progetto Software Con UML e Il Metodo Dei Colori
Ing. R. Turco
1
Introduzione
L’Analisi e la progettazione Object Oriented di un sistema richiede una mentalità diversa
rispetto all’approccio funzionale classico.
Modellare un sistema, tuttavia, non è così semplice come potrebbe sembrare e richiede una
sensibilità ed una buona conoscenza di:
UML (Unified Modelling Language);
Formalizzazione dei requisiti con gli Use Case;
Modellazione del sistema con diverse view: il modello delle attività, il modello degli
stati, il modello delle sequenze, il modello delle classi, il modello dei packeges, il
modello di deployment, il modello dei componenti, etc;
Individuazione degli oggetti, degli attributi, dei servizi, delle strutture, dei soggetti
coinvolti;
L’utilizzo di modelli teorici utili nell’analisi (OOA) e nel disegno (OOD);
I Design Pattern;
I concetti di refactoring.
Tuttavia così si riusa ben poco del grande “bagaglio tecnico” oggi disponibile, grazie alla ricerca
di migliaia di persone nel mondo; né si affronta il lavoro in modo “ingegneristico”, cioè
tracciabile e ripetibile da chiunque nello stesso modo [DR2].
In questo articolo ci proponiamo di vedere come, attraverso dei modelli teorici di notevole
interesse, sia possibile affrontare l’analisi dei domini, concentrandoci in maniera non troppo
superficiale, SOLO sui diagrammi delle classi.
In generale, però, l’analisi per forza deve basarsi su tutte le viste utili al problema e tracciabili
con vari diagrammi possibili [DR3].
Il modello a colori rappresenta una validissima tecnica che permette di tirar fuori in modo
prevedibile ed ingegneristico un modello di qualità.
Tale tecnica permette di mettere insieme l’abilità di anni di analisi e pratica dei migliori analisti
del settore.
2
DNC – Domain Neutral Component
Un sistema è generalmente costituito da quattro componenti o strati, come indicati in figura 1.
Presentation Layer
(User Interface Views and Controller)
Business Layer
(Problem Domain Layer)
System Interface
Persistent Layer (Legacy, etc)
(Database)
Figura 1
In [DR1] si dimostra che per l’analisi di un dominio vanno considerati solo quattro archetipi
fondamentali, che si ritrovano sempre in un qualsiasi layer della fig.1.
La vera definizione di archetipo è: “Una forma che tutte le cose dello stesso genere seguono,
più o meno”.
In altri termini ciò vuol dire che siamo di fronte a dei “Componenti di Dominio Neutrali”, quindi
a componenti generici, che possono trovarsi nel dominio in numero e nome diversi, ma di
ugual natura.
Il metodo di Coad propone di colorare gli archetipi, una volta individuati. Questo facilita una
maggiore visibilità e permette una modellazione a strati (layering). I colori proposti sono il
giallo (yellow), il rosa (pink), il verde (green) ed il blu (blue).
Con i colori un occhio esperto può capire se il modello disegnato sta andando per il verso
giusto.
3
Pensiamo ad un dominio nel quale un cliente effettua la vendita di oggetti, in una certa
quantità, e ad un determinato prezzo (fig.2).
Figura 2
Con i pattern GRASP e in particolar modo col pattern Expert, si assegna la responsabilità solo a
chi sa le cose (l’esperto), spezzando le sotto-responsabilità secondo un’analisi funzionale.
In fig.2 c’è la classe che conosce il prezzo e la descrizione di un altro oggetto e ne è, quindi,
l’archetipo Catalog-Description (blue).
C’è poi l’oggetto venduto (Thing) che conosce la quantità di quell’oggetto venduto e, quindi, ha
la sotto-responsabilità dell’ammontare parziale (green).
Inoltre c’è la classe Sale, che avviene in un certo istante (Moment-Interval, pink) ed ha la
responsabilità dell’ammontare totale della vendita di tutti gli oggetti.
L’indicazione dello stereotipo << >> serve a indicare il ruolo svolto dalla classe nel modello ed
il tipo di associazioni che dovremmo aspettarci da essa.
Lo stesso dicasi del colore. Solo che il colore da una maggiore immediatezza di tutto ciò.
4
Es:
<<Role>>
<<Moment-Interval>>
<<Person/Place/Thing>> oppure <<Party/Place/Thing>>
<<Description>>
L’indicazione dello stereotipo << >> serve a indicare il ruolo svolto dalla classe nel modello ed
il tipo di associazioni che dovremmo aspettarci da essa.
Lo stesso dicasi del colore. Solo che il colore da una maggiore immediatezza di tutto ciò.
Figura 3
A livello implementativo l’archetipo può essere indicato con una tecnica javadoc-style del
genere:
Un Moment-Interval (MI) è alla fine un oggetto o una classe del dominio, quindi avrà attributi e
metodi (e questo è vero per ogni archetipo).
Esempi di attributi:
startDate, endDate, number, total, priorità, status
5
Esempi di metodi:
totalSalesValue(), isComplete(), isApproved(), isUrgent(), etc.
In genere un Moment-Interval può avere dei dettagli, delle priorità ed un prossimo moment-
interval.
In tal caso, una strategia utile è di individuare ogni Moment-Interval e collocare ognuno
secondo l’ordine temporale in gioco (fig. 4), poi solo alla fine aggiungere gli altri archetipi.
Figura 4
Archetipo Role (Yellow color)
Come si può notare l’archetipo mette in gioco anche cose esterne al contesto: gli attori, le
cose, etc.
Alcuni di essi possono anche svolgere più ruoli in intervalli di tempo diversi o lo stesso ruolo in
intervalli diversi (fig. 5)
6
Figura 5
Es attributi: quantità
Figura 6
Un’alternativa migliore è fornita dal modello a colori (fig. 7), perché mira alla composizione.
7
Figura 7
Figura 8
Ad esempio:
modello d’auto: BMW 528i
tipo d’aereo: Boeing 707
8
Il legame tra Party, Role, Moment-Interval e Description è evidente in fig. 9.
Figura 9
Business flow
Figura 10
9
In realtà individuare subito Role e PartyPlaceThing è anche un’altra modalità di “Domain
Partitioning”.
Supponiamo di avere nel nostro dominio dei posti vendita e dei depositi, dove avvengono
vendite e inventari (fig.11).
Figura 11
La “Big Picture”
In ogni caso il metodo dei colori è un Pattern di costruzione del modello del dominio in
modalità “buttom-up”, cioè si individuano i singoli archetipi fino a costruire il modello totale
corrispondente al dominio.
E’ possibile operare anche al contrario, partendo, cioè, già da un modello completo e tagliando
ciò che non serve.
Quello che contiene un Party Tree, un Place Tree, un Thing Tree e un Moment-Interval,
con priorità, successivo e dettagli.
Zero o molti Party hanno un PartyDescription, mentre un Party ha zero o uno PartyRole.
Stesse molteplicità per gli altri.
Per il Moment-Interval che lega i tre alberi, vale la figura 4 e su esso convergono il Party Tree,
il Place Tree ed il Thing Tree.
10
Il Customizing e il Collapsing
Sebbene il metodo dei colori sia questo, ATTENZIONE! Applicarlo sempre “cum grano salis”!
E’ consigliabile sempre fare il “Customizing” del metodo dei colori, cioè rimuovendo le classi
che producono solo extra complessità rispetto al problema da risolvere senza fornire valore
aggiunto.
D’altra parte l’astrazione consiste proprio nel riportare nel modello solo i particolari significativi
del mondo reale, eliminando quelli che non sono utili ai fini del contesto!
Se tracciamo solo tipi generici è inutile, in qualche caso, particolarizzare il Party, il Thing, il
Place.
Plug-in Point
Spesso si introducono dei plug-in point per il Description e/o per il Moment-Interval. Coad in
“Java Modelling in Color with UML” introduce le interface per questo compito.
11
Vantaggi della modellazione a colori
Creando un Object Model Color ci si aspetta innanzitutto di lavorare a layer, questo dovrebbe
consentire un automatico abbassamento dell’accoppiamento tra classi.
Se esiste un forte numero di relazione tra strati bisogna dare meglio un’occhiata al modello.
Ogni layer dovrebbe essere predominato da un solo colore, con minimi collegamenti verso gli
altri archetipi.
Ogni layer avrà legami verso un altro layer. Se abbiamo nel nostro modello la presenza di un
solo colore o layer, forse, qualcosa è da rivedere.
Gli archetipi ed il metodo dei colori non sono soltanto una categorizzazione di classi, ma anche
una categorizzazione di responsabilità, attributi, metodi, link, plug-in point, interazioni.
I Domini di analisi
Ritorniamo alla figura 1, vista all’inizio.
In generale conviene sforzarsi a mantenere la struttura organizzativa del Business Layer pari a
quella del dominio del problema o PDC.
12
Nel suddividere il lavoro tra N gruppi occorre di evitare di “tagliare” il Business Layer.
Un sistema di controllo sensori controlla dei sensori e dei sensori critici. Ogni sensore è
descritto dal proprio modello (marca e numero modello), da caratteristiche tecniche come:
fattore di scala, errore sistematico, unità di misura, dall’intervallo di campionamento,
dall’ubicazione, dallo stato (acceso, spento, in attesa), dalla soglia di allarme.
Il sistema attiva dei dispositivi di allarme.ogni volta che un sensore supera la soglia.
Il dispositivo d’allarme è caratterizzato da una durata d’allarme e dallo stato del dispositivo.
13
Figura 12
Occorre fare un grosso lavoro in fase di raccolta dei requisiti, con la collaborazione del cliente e
delle persone che useranno il prodotto.
La User Task Analisys in base alle persone, gli scenari d’utilizzo ed il ruolo, permette di
individuare l’insieme dei comandi necessari sulla GUI. In altri termini si interessa delle prime
tre voci di cui sopra.
Nella fase OOA devono essere specificati tutti i servizi e gli attributi richiesti.
A volte nella fase di raccolta di requisiti e per alcune cose critiche o anche per il solo layout si
opera con la prototipazione, parallelamente alla fase OOA.
Un Pattern di Layout per GUI è il “ChessBoard Layout” di Fig.13 che prevede un frame
orizzontale in alto (top level) ed uno verticale a sinistra (second level), su cui possono essere
inseriti dei bottoni secondo una struttura bidimensionale.
14
Figura 13
Il dott. Miller, in un suo studio del 95, affermò che 7+/-2 è il numero di cose che il nostro
cervello è in grado di elaborare.
Per cui il numero di bottoni, per una questione di simmetria, è consigliabile che sia al massimo
8.
I Task ed il ruolo delle persone sono fortemente legati (Task and Role Player).
L’eseguire un Task coinvolge Party (Persone o Organizzazioni), Place e Thing in un qualche tipo
di ruolo (Role) ed in un qualche intervallo di tempo (Moment-Interval).
Occorre individuare tutti i ruoli nel sistema e chiedere ad ognuno come effettuano i loro task;
ed è su questo che si basa la User Task Anlysis.
Si potrebbe pensare ad una prima strategia di popolamento della GUI secondo la quale si pone
il Task al top level; per cui magari il second level è costituito dai bottoni degli step associati ad
un Task ed il top level è costituito dai bottoni dei Task.
Se, invece, il ruolo è fondamentale, allora è facile immaginarsi sul level i bottoni relativi al
ruolo (“Role”), mentre sul second level i Task relativi al ruolo.
Se nel dominio troviamo dei Party/Place/Thing che sono legati a molti Role, allora i primi
assumono notevole importanza. In altri termini il Party/Place/Thing sta giocando una parte nel
sistema e deve essere valutato se possa servire metterlo al top level.
La progettazione delle interazioni viene fatta tenendo conto dei concetti di usabilità.
15
L’usabilità delle GUI tende a ridurre la complessità delle azioni per poter offrire la GUI anche a
persone con skill bassi.
La consistenza
Usare termini consistenti, passi consistenti, azioni consistenti.
Completezza
Pochi passi che portano a termine in modo chiaro l’azione.
Undo
Errare è umano. Diabolico è non fornire sulla GUI un task per poter recuperare l’errore o per
ripensarci su un’azione delicata.
In altri termini il concetto è che se ogni giorno occorre lavorare molte ore (1/3 della giornata),
meglio farlo con strumenti piacevoli e divertenti. Per la verità la cosa è vera anche con le
persone! Solo che le persone non si possono scegliere, gli strumenti sì.
16
Tuttavia si fa osservare in [DR5] che spesso le “guidelines” sono troppo semplici o troppo
astratte, anche difficili da interpretare correttamente (un po’ come i proverbi!).
Migliori risultati, invece, si ottengono con dei Pattern UID (Pattern User Interface Design),
perché esplicitamente fanno riferimento al contesto di applicazione (quando applicarlo), al
problema in gioco (perché applicarlo), la soluzione attualmente in uso (come applicarlo), e a
vari esempi.
Un Pattern UID, invece, è sicuramente una Guidelines. NON è vero, invece, il contrario; per cui
si propende di far riferimento giustamente ai Pattern UID per l’usabilità.
Figura 14
Nel livello alto della figura si capisce che sono importanti tre cose: l’efficienza, l’efficacia, la
soddisfazione.
Il livello inferiore da degli indicatori del livello di usabilità (Usage Indicator), rilevati osservando
un utente al lavoro.
17
Per esempio un basso tasso di errore (error-rate) contribuisce ad una migliore efficacia e una
migliore performance e quindi ad efficienza.
Il desiderato livello di ognuno di questi indicatori, però, dipende dal tipo di sistema in gioco.
Per un sistema di produzione potrebbe essere imperativa l’efficienza (performance), per un sito
di intrattenimento e giochi, invece, potrebbe essere importante la soddisfazione.
Ad un livello inferiore troviamo i Mezzi (Means). Mentre gli Usage Indicator sono osservabili da
test sugli utenti e possono aiutare ad arrivare al livello di usabilità, i Means non sono
osservabili né sono essi stessi degli obiettivi. In realtà i Means vengono usati in modo euristico
vedendone l’influenza sugli Usage Indicator. Infine all’ultimo strato vi deve essere la
conoscenza: lo User Model, Il Design Knowledge, il Task Model.
All’atto pratico ad un progettista dovrebbero bastare i primi tre strati se usati con saggezza e
consultando i Pattern UID per verificare se esistono cose d’interesse per il proprio caso.
E’ chiaro che i Pattern UID risolvono il problema dell’usabilità di UI; difatti fanno riferimento al
layout, alla navigazione, alla correlazione degli argomenti, all’help, al numero di passi che un
utente deve fare, etc. Ma per Presentation Layer, Model Layer e Database Layer di una
componente d’interazione (HIC) esistono dei Design Pattern per l’organizzazione delle classi?
Sì, il Model View Controller (MVC), ad esempio, è un famoso Design Pattern per UI e Web,
anche se ne esistono altri simili, con qualche variante. La SUN ha introdotto, ad esempio, in
ambito J2EE, il Boundary- Control-Entity-Database (BCDE), ma che somiglia al MVC.
In questo esempio ci soffermiamo sul problema definito nel PDC, precedentemente e vediamo
come applicare la User Task Analysis e la modellazione a colori.
Nell’esempio teniamo conto di una sola persona, in realtà nella pratica occorrerà intervistare
tutte le persone in gioco che saranno utenti del prodotto.
18
Gerarchia dei comandi
I base alla User Task Analisys, si è deciso di usare i servizi ed il ruolo in gioco. Si presuppone
poi una barra menu, con sottomenu per ogni voce. Per la gerarchia dei comandi ci facciamo
guidare, se possibile, da:
Esempio:
File Modifica Inizializza Stato Stile
Aggiungi Spento Font
Cambia Acceso Icona
Cancella Attesa
Qui si progetta una GUI su cui sono disegnati dei Sensori-Finestra di stato e di allarme. Ogni
sensore ha una sua posizione nell’edificio.
Figura 15
19
Un esempio HIC-2 per il Web: Il Model-View-Controller
Il MVC è applicabile per ogni UI e, quindi, anche per il Web.
In ambito Web il Presentation Layer è visualizzato dal browser (client), ma fisicamente tale
strato è server-side (JSP, Servlet, CGI, FastCGI). Nel seguito ipotizziamo un minimo di
conoscenza Web e di protocollo http e ci focalizzeremo solo sulla problematica delle
modellazione.
Figura 16
Figura 17
20
Figura 18
In particolare sul web il Controller è una LoginSession (Moment-Interval), come in fig. 19.
21
Figura 19
22
System Interaction o Task Management Component (TMC)
L’uso di un task, comunque, aggiunge un livello di complessità maggiore nel sistema a causa
della concorrenza in gioco.
I task concorrenti possono essere lanciati su processori indipendenti oppure su uno stesso
processore sfruttando i thread ed il multi-tasking.
Per cui un TMC va introdotto quando necessario (miglioramento prestazioni, etc). Però non
evitatelo se è necessario! In ogni caso esiste sempre un requisito non funzionale che allerta
sull’esistenza di un TMC.
In questo caso la task è in uno stato “dormiente”. Il verificarsi dell’evento sveglia la task che
valuta i dati ricevuti, li elabora, li memorizza su qualche tipo di supporto (memoria, memoria di
massa), esegue delle azioni e poi termina ritornando in uno stato dormiente.
Anche questa task avrà un comportamento analoga alla precedente. Ciò che cambia è l’evento
che la sveglia.
23
In genere esistono la priorità Alta e Bassa.
I servizi con priorità diversa possono essere isolati in due task diverse.
Definizione di un task
Nome
Descrizione
Priorità
Criticità
Servizio 1 ed elaborazione
Coordinato da
Comunica con
Comunica attraverso
24
Il Componente di Gestione Dati o Data Management Component (DMC)
Il componente DMC fornisce l’infrastruttura per la persistenza dei dati e la lettura di oggetti da
un DBMS relazionale o ad oggetti.
Il componente DMC ci serve per schermare, isolare gli effetti del DBMS sul restante progetto.
Sebbene oggi sia possibile usare database ad oggetti, il DBMS relazionale è ancora
universalmente adottato.
In questo modo ogni classe che mappa una tabella avrà tutti gli attributi della tabella ed i
servizi get e set che operano sulla tabella.
In genere tutti gli attributi e servizi di questo tipo sono detti “impliciti” e non vengono riportati
sul modello OOD, ma eventualmente sono descritti testualmente.
I Design Pattern danno ottimi consigli su come realizzare DMC riusabili, estensibili e
mantenibili.
Conclusioni
L’informatica non è la matematica che assegnato un problema ben specificato, c’è un solo
progetto giusto per risolverlo ed è quello ottimo.
Questo sarebbe bello, anzi darebbe la garanzia che qualsiasi software engineer produrrebbe il
progetto sempre allo stesso modo seguendo il processo produttivo e la metodologia scelta
[DR2]. Tuttavia la scelta di un processo produttivo e di una metodologia, da sole, non sono
garanzia di tracciabilità e ripetibilità del lavoro stesso. Come pure il processo produttivo da solo
non riduce i rischi progettuali [DR2].
Occorrono teorie, strumenti e template che portino ad una maggiore ripetibilità sistematica del
processo produttivo da parte di persone anche con skill diverse.
Il progettista deve avere teorie, modelli e template che gli forniscano i criteri di valutazione e
di progettazione per poter fare sempre la giusta scelta, in modo ripetibile.
25
INDICE
26
Riferimenti
[DR1] Coad, Lefebvre, De Luca – Java modelling in Color with UML
[DR2] Rosario Turco – Usabilità e ripetibilità dei processi produttivi software
[DR3] Martin Fowler – UML Distilled – Prima edizione italiana
[DR4] Rosario Turco – Pattern e la “GRASP Oriented Analysis”
[DR5] Martijn van Welie, Gerrit C. V der Veer, Anton Eliens – Patterns as Tools for User
Interface Design
[DR6] Rosario Turco – Refactoring: la teoria in pratica
27