modellare un progetto software con uml e il metodo dei colori
DESCRIPTION
UML - metodi di analisi (modellazione con i colori).L'articolo va integrato con i Design pattern, la progettazione a componenti e la progettazione con framework (vedi e-book dello stesso autore)TRANSCRIPT
1
Modellare con UML ed i colori Ing. R. Turco
Copyright 2003 – R. Turco
2
Introduzione
L’Analisi e la progettazione Object Oriented di un sistema richiede una mentalità diversa
rispetto all’approccio funzionale classico.
In realtà il nostro modo di concepire il mondo è proprio di immaginarlo attraverso una
rappresentazione ad oggetti.
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.
Un “beginner”, inizialmente, può solo affrontare tali problematiche disegnandone il modello in
modo intuitivo. Non potrebbe fare diversamente.
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].
La modellazione UML a colori (Object Model Color)
La modellazione a colori [DR1], dovuta a P. Coad, fornisce un modello elegante, minimo
necessario, estensibile, robusto e innanzitutto resistente ai cambiamenti.
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.
La modellazione a colori, difatti, è un modello teorico, un pattern, di guida all’analisi dei
domini.
3
DNC – Domain Neutral Component
Un sistema è generalmente costituito da quattro componenti o strati, come indicati in figura 1.
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.
Ma che cos’è un archetipo?
Si potrebbe pensare facilmente ad uno stereotipo particolare; ma tale definizione, anche se si
avvicina molto, non rende la giusta idea.
La vera definizione di archetipo è: “Una forma che tutte le cose dello stesso genere seguono,
più o meno”.
E’ proprio la sfumatura del “più o meno” che deve farci riflettere.
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.
Gli archetipi previsti dal modello sono:
Il Moment-Interval (pink color);
Il Role (yellow color);
Il PartyPlaceThing (green color);
Il Catalog-Description (blue color).
Presentation Layer
(User Interface Views and Controller)
Business Layer
(Problem Domain Layer)
Persistent Layer
(Database)
System Interface
(Legacy, etc)
4
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
In questa figura sono condensate molte esperienze:
I Pattern GRASP di Larman [DR4];
La modellazione a colori;
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.
Infine esiste il Cliente (ruolo di una persona, il Role, yellow).
Rappresentazione degli Archetipi
Si usa per la sua rappresentazione la notazione di stereotipo; ad esempio <<Moment-
Interval>> seguita dal nome dell’oggetto.
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ò.
Si usa per la sua rappresentazione la notazione di stereotipo: <<Moment-Interval>> seguita
dal nome dell’oggetto.
5
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
La fig. 3 dà un esempio generale.
A livello implementativo l’archetipo può essere indicato con una tecnica javadoc-style del
genere:
/** @archetype moment-interval */
public class MISale {
public BigDecimal calcTotal(){
}
private int number;
private Date date;
}
Archetipo Moment-Interval (Pink color)
Un Moment-Interval (pink) individua una necessità di ricordare (registrare) e calcolare; inoltre
ha in sé un significato di momento o di intervallo di tempo.
Un esempio: approvazione (moment), accordo (interval), storico (interval), stato (moment)
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
6
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)
Un ruolo è la modalità di partecipazione al dominio del Party (organizzazione o persona), del
Place (Posto, Località,etc.), del Thing (cosa o oggetto).
Come si può notare l’archetipo mette in gioco anche cose esterne al contesto: gli attori, le
cose, etc.
Esempi di Party Role possiamo indicare:
Cassiere, Cliente, Amministratore, Capo ufficio, etc.
Esempi di Place Role possiamo indicare:
Aeroporto militare, aeroporto civile, etc.
Esempi di Thing Role possiamo indicare:
Aereo militare, aereo civile, etc.
Ovviamente inseriamo solo gli archetipi pertinenti col nostro problema.
Alcuni di essi possono anche svolgere più ruoli in intervalli di tempo diversi o lo stesso ruolo in
intervalli diversi (fig. 5)
7
Figura 5
Archetipo Party, Place, Thing (Green color)
Il Party può essere una persona o un’organizzazione.
Il Place è il luogo dove le cose stanno. Ad esempio: palazzo, magazzino, etc.
Il Thing è un oggetto che può contenere altri. Esempio: prodotto.
In ogni caso un Party, un Place o un Thing sono oggetti univocamente individuabili.
Es attributi: quantità
Con un esempio di Party dimostriamo ora un vantaggio della metodologia a colori.
Considerando Dipendente e Manager, solitamente, li si pensa come una specializzazione di
Persona (fig. 6), ovvero come superclasse e sotto-classi. Nei progetti, spesso, si abusa della
ereditarietà, il che rende il modello del dominio poco flessibile in generale.
Figura 6
Un’alternativa migliore è fornita dal modello a colori (fig. 7), perché mira alla composizione.
8
Figura 7
Il legame tra Party, Role e Moment-Interval è evidente in fig. 8.
Figura 8
Archetipo Catalog-entry-like Description (Blue color)
Un archetipo Description tende a descrivere altri oggetti, di conseguenza è un catalogo.
Ad esempio: Descrizione di prodotto.
Non è un unico oggetto.
Ad esempio:
modello d’auto: BMW 528i
tipo d’aereo: Boeing 707
Es. attributi: text description, prezzo, image
Es. Metodi : business rules, terms and conditions, totalUnitsAvailable(),
totalUnitsManifactured()
9
Il legame tra Party, Role, Moment-Interval e Description è evidente in fig. 9.
Figura 9
Business flow
Un business flow è modellabile con uno “stack di Moment-Interval” che scandiscono il
tempo e gli stati delle attività.
Vediamo un flusso del tipo:
Richiesta Prestito -> LOC Approvazione Prestito -> Check della Documentazione ->
Assegnazione fondi
Figura 10
Il metodo per trovare gli archetipi nel modello
Il metodo è “Individuare innanzitutto i Moment-Intervals, poi i Role, successivamente i
Description ed infine i Party/Place/Thing”.
10
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.
Ma qual è il modello completo, la Big Picture?
Quello che contiene un Party Tree, un Place Tree, un Thing Tree e un Moment-Interval,
con priorità, successivo e dettagli.
In altri termini un Place può avere un PlaceRole e un PlaceDescription a sé legati che
costituiscono il Place Tree, mentre il Place Role è associato al Moment-Interval. Stesso dicasi
per il Thing e per il Party.
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.
11
Il Customizing e il Collapsing
Sebbene il metodo dei colori sia questo, ATTENZIONE! Applicarlo sempre “cum grano salis”!
NON bisogna mai sacrificare la flessibilità.
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!
Spesso Thing Role e Place Role sono un’aggiunta inutile.
Se tracciamo solo tipi generici è inutile, in qualche caso, particolarizzare il Party, il Thing, il
Place.
Il “Collapsing” si verifica quando, ad esempio, un archetipo ha pochi attributi e metodi; in tal
caso si Può decidere di spostare tali attributi e metodi nel PartyPlaceThing e così per gli altri
archetipi.
Nei casi limite siamo di fronte ad un attributo e non ad una classe!
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.
12
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.
Inoltre la metodologia a colori abbiamo visto che incoraggia la composizione e non
l’ereditarietà.
Ultimo e non trascurabile vantaggio è che la metodologia a colori consente di avere un
modalità di individuazione delle classi che è ripetibile anche da un “beginner”.
I Domini di analisi
Ritorniamo alla figura 1, vista all’inizio.
In un sistema software esistono almeno quattro componenti o domini di analisi o layer di un
sistema sottoposto ad analisi:
Presentation Layer o User Interface (UI) o Human Interface Component (HIC);
Business Layer o Dominio del Problema (PDC);
Persistent Layer o Data Management Component (DMC);
System Interaction o Task Management Component (TMC).
Da dove conviene iniziare?
Il suggerimento è di iniziare a capire innanzitutto il Business Layer. Preferisco così perché si
affronta e si perfeziona il dominio del problema e s’inizia anche a capire il concettuale del
database.
Problem Domain Component (PDC)
In generale conviene sforzarsi a mantenere la struttura organizzativa del Business Layer pari a
quella del dominio del problema o PDC.
In questo modo si ottengono vari vantaggi:
Si ottiene una maggiore e naturale stabilità del componente: i dettagli possono
cambiare ma non accadrà uno sconvolgimento del componente poiché il dominio del
problema risulterà stabile per lungo tempo.
La stabilità del dominio del problema permetterà una maggiore riusabilità dell’analisi,
della progettazione e dell’implementazione per tutti i sistemi aventi lo stesso dominio
del problema, costituendo un framework di dominio. Inoltre sarà facile estendere le sue
funzionalità.
Un facile incorpamento di nuovi requisiti.
Il passaggio e la “tracciabilità” dall’analisi (OOA) alla progettazione (OOD) è chiara,
naturale ed evidente. Non c’è nessuna rottura o transizione netta tra OOA e OOD ma
una naturale prosecuzione.
13
Nel suddividere il lavoro tra N gruppi occorre di evitare di “tagliare” il Business Layer.
LA suddivisione del lavoro deve privilegiare il fatto di assegnare ad un gruppo classi
logicamente correlate. Altrimenti rovineremo la stabilità, la riusabilità e l’estensibilità ed
esalteremo la fragilità.
Il passaggio dall’OOA all’OOP consisterà nell’aggiungere classi di servizio, non inerenti il
dominio del problema o altri dettagli di supporto.
Infine in fase implementativa, in base al linguaggio a disposizione si particolarizzano il tipo di
ereditarietà consentita (multipla o singola), si punta ad un refactoring per un miglioramento
del framework risultante, sia in termini di pattern migliorativi, sia per scelta di algoritmi
migliori, sia per migliorare le prestazioni.
Un esempio PDC: Sistema di controllo sensori
Supponiamo di avere il seguente dominio del problema.
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.
I sensori critici sono in più caratterizzati da una tolleranza di campionamento.
I sensori sono installati in edifici.
Il sistema di controllo memorizza la posizione di ogni sensore nell’edificio, l’indirizzo
dell’edificio ed i numeri di telefono da contattare in caso di emergenza.
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.
Viene tracciata la storia (data, ora, severità, durata) di ogni allarme.
14
Figura 12
Una prima analisi condurrebbe al diagramma della Fig.12.
Il componente di interazione umana (HIC)
Il componente di interazione umana in un sistema è una componente molto delicata. Non
basta conoscere il Business Layer, per poter capire come realizzare l’interfaccia utente.
Occorre fare un grosso lavoro in fase di raccolta dei requisiti, con la collaborazione del cliente e
delle persone che useranno il prodotto.
Occorrerà tener conto di molte cose:
Classificazione delle persone che la usano (il ruolo)
Scenari dei compiti di ognuno
Individuazione della gerarchia dei comandi
Individuazione di Pattern di Layout
L’usabilità e progettazione delle interazioni
Individuazione di pattern di dominio
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.
Nella fase OOD, invece, si progetta l’interazione e i suoi dettagli.
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.
15
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.
Essendo la struttura bidimensionale, 8x8=64 come una scacchiera!
Strategia di “Populating of the Navigational Model”
Quando si è di fronte ad una GUI è necessario stabilire la corretta strategia di “Populating of
the Navigational Model” in modo da individuare le voci organizzate nel modo giusto e che
permetta una buona usabilità.
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.
Le strategie di popolamento possono ispirarsi alla metodologia a colori, considerando varie
possibilità sulle due dimensioni della ChessBoard Layout:
Un top level choice per ogni Task;
Un top level choice per ogni Role;
Un top level choice per ogni Party/Place/Thing;
Un top level choice per ogni Moment-Interval;
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.
E’ utile una tale semplice strategia?
Se il ruolo degli attori in gioco è unico la strategia può andare, è rapida e non ci sono
controindicazioni; dipende solo dal numero di step e di task in gioco.
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.
Stesso discorso per i Moment-Interval.
L’usabilità e la progettazione delle interazioni
La progettazione delle interazioni viene fatta tenendo conto dei concetti di usabilità.
L’usabilità di una GUI verte su almeno due aspetti fondamentali:
il grado di complessità delle operazioni da compiere;
il grado di bravura della persona.
16
L’usabilità delle GUI tende a ridurre la complessità delle azioni per poter offrire la GUI anche a
persone con skill bassi.
Secondo l’usabilità occorre rispettare una serie di regole euristiche o guidelines:
la consistenza
riduzione dei passi
niente sonno del sistema
completezza
undo
non far uso di RAM umana
ridurre lo sforzo di apprendimento
look & feel (piacevolezza ed attrattiva)
La consistenza
Usare termini consistenti, passi consistenti, azioni consistenti.
Riduzione dei passi
Pochi passi per terminare un task, pochi click per arrivare ad un risultato, pochi tasti per
effettuare un’attività, e questo avari livelli d’abilità: principiante, occasionale, esperto.
Niente “sonno” del sistema
Il sistema non deve “addormentarsi” senza dare indicazioni di che cosa stia facendo e quali
progressi.
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.
Non far uso di RAM umana
Non complicare il task che l’utente deve compiere basandosi sulla sua memoria. E’ facile che
incorrerà in un errore.
Ridurre lo sforzo di apprendimento
Non sempre le persone hanno tempo per leggere la documentazione. In genere la leggono
quando si verifica un problema. Per cui affidatevi ad azioni intuitive dove c’è poco da dover
imparare. Le persone devono impiegare il 99% del loro tempo a pensare al lavoro da svolgere
e non a come dover impiegare lo strumento. L’utilità dello strumento diventa poi massima se
migliora anche le prestazioni del dipendente.
Look & Feel
Concetto eccessivamente abusato, che indica l’attrattiva e la piacevolezza e va oltre il concetto
di usabilità spesso arrivando a quello di qualità totale e di soddisfazione psicologica ed emotiva
(miroyukutaki hinshitsu).
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ì.
Usabilità: Guidelines o Patterns?
Le “Linee guida” sono certamente dei concetti acquisiti con l’esperienza e che suggeriscono di
“fare o non fare” certe cose nella fase di disegno per una GUI o anche per il Web (Web
Usability).
17
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à.
L’obiettivo di un Pattern UID è proprio quello di aiutare a costruire componenti d’interazione
più usabili.
Lo ChessBoard Layout è un esempio di Pattern UID. Ma ne esistono anche altri.
La figura successiva mostra il modello stratificato di usabilità secondo la visione ISO.
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.
18
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.
Per i teorici dell’usabilità, invece, esistono strumenti empirici e tecniche di osservazione
dell’utente al lavoro per dire se una UI o un sito Web è usabile o meno.
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 questa trattazione ci soffermeremo solo sul MVC.
Un esempio HIC-1: Sistema di controllo sensori
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.
Classificazione delle persone
“Sono Fred, voglio controllare i miei sensori. Voglio aggiungerli, inizializzarli, controllare le loro
operazioni, attivarli e disattivarli.”
Scenario principale dei compiti di Fred
Aggiungere sensore -> inizializzare sensore -> attivare sensore -> sensore in allarme (luce
rossa lampeggiante e suono regolabile) -> esco e risolvo il problema.
Scenario secondario dei compiti di Fred
Nessuno
Livello di abilità di Fred
Medio-alto
Fattori critici di successo per Fred
“Voglio vedere solo gli elementi di mio interesse. (A questo punto si presuppongono utenze
diverse). I font devono essere almeno di 10 in su”.
Gli scenari vanno ripetuti per ogni persona intervistata.
19
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:
i servizi necessari alle persone;
Un ordinamento dei servizi nell’ambito della gerarchia;
Un raggruppamento in Tutto-Parti;
Ampiezza contro profondità (regola del 7+/-2);
Numero minimo di passi e/o di click
Esempio:
File Modifica Inizializza Stato Stile
Aggiungi Spento Font
Cambia Acceso Icona
Cancella Attesa
Diagramma delle classi
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
20
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.
Il Design Pattern Model-View-Controller realizzabile per il Web è mostrato in figura 16.
Figura 16
La fig. 16 mostra una semplificazione two-tier.
Figura 17
In fig. 17 abbiamo la rappresentazione completa three-tier.
Un diagramma generico di classi che implementi il MVC è rappresentato in fig. 18.
21
Figura 18
In particolare sul web il Controller è una LoginSession (Moment-Interval), come in fig. 19.
22
Figura 19
23
System Interaction o Task Management Component (TMC)
Il componente di gestione task (TMC) può servire a:
Coordinare attività o task paralleli;
Far funzionare UI che hanno finestre su cui si eseguono task paralleli (pensate anche ad
un browser);
Provvedere alla comunicazione sincrona/asincrona tra i vari sotto-sistemi;
Provvedere alla comunicazione sincrona/asincrona tra sistemi;
Provvedere ad architetture hardware multi-processore;
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.
Ovviamente la concorrenza introduce complessità progettuale, implementativa, di test e di
manutenzione.
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 alcuni casi, invece, un TMC semplifica la progettazione e l’implementazione.
Determinazione del TMC
Occorre procedere sistematicamente:
Identificare le task attivate da eventi esterni;
Identificare le task attivate da clock di sistema;
Identificare le task con priorità e quelle critiche;
Identificare il coordinatore;
Verificare ogni task;
Definire ogni task.
Identificare le task attivate da eventi esterni
Occorre innanzitutto quali sono gli eventi:
Un interrupt su linea dati;
Un messaggio su una Message Queue, etc;
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.
Lo stato dormiente serve a non “consumare” tempo di CPU inutilmente.
Identificare le task attivate da clock di sistema
In questo caso la task in stato “dormiente” è svegliata dal clock del sistema (il crontab ad
esempio).
Anche questa task avrà un comportamento analoga alla precedente. Ciò che cambia è l’evento
che la sveglia.
Identificare le task con priorità e quelle critiche
Una task con priorità deve essere eseguita prima di un’altra.
Una task critica richiede l’isolamento delle operazioni critiche da effettuare per averne il successo.
24
In genere esistono la priorità Alta e Bassa.
I servizi con priorità diversa possono essere isolati in due task diverse.
I servizi critici richiedono un’ulteriore task che li isoli.
Il coordinatore dei task
Deve esistere alla fine un coordinatore dei task in gioco per le priorità, le criticità, ed ha
l’intelligenza delle priorità, delle criticità. Il coordinatore di task non esegue servizi ma coordina
task.
Verifica dei task
Ad ogni release tenete d’occhio il numero di task a cui siete giunti sul sistema. Mantenete sul
sistema solo i task veramente necessari.
Definizione di un task
La definizione di un task segue il seguente template.
Nome
Descrizione
Priorità
Criticità
Servizio 1 ed elaborazione
Coordinato da
Comunica con
Comunica attraverso
25
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.
Progettazione del DMC
La progettazione del DMC prevede almeno due cose:
lo schema del database;
le classi che mappano le tabelle del database.
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.
In questo modo un oggetto è in grado di salvarsi (sulla tabella) ed essere persistente.
Ovviamente il modo secondo cui gli attributi si salvano attraverso i servizi dipendono dal
legame esistente tra PDC e DMC.
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.
La progettazione a colori è un ottima teoria-template, un pattern irrinunciabile con i suoi
vantaggi.
Ulteriore strumenti a cui il progettista non deve rinunciare sono:
i Design Pattern [DR4]
il Refactoring [DR6].
26
INDICE
Modellare con UML ed i colori ........................................................................................................... 1
Introduzione ......................................................................................................................................... 2
La modellazione UML a colori (Object Model Color) ................................................................... 2
DNC – Domain Neutral Component .................................................................................................... 3
Rappresentazione degli Archetipi .................................................................................................... 4
Archetipo Moment-Interval (Pink color) ......................................................................................... 5
Archetipo Role (Yellow color) ........................................................................................................ 6
Archetipo Party, Place, Thing (Green color) ................................................................................... 7
Archetipo Catalog-entry-like Description (Blue color) ................................................................... 8
Business flow ................................................................................................................................... 9
Il metodo per trovare gli archetipi nel modello................................................................................ 9
La “Big Picture” ............................................................................................................................. 10
Il Customizing e il Collapsing ...................................................................................................... 11
Plug-in Point .................................................................................................................................. 11
Vantaggi della modellazione a colori ............................................................................................. 12
I Domini di analisi.............................................................................................................................. 12
Problem Domain Component (PDC) ............................................................................................. 12
Un esempio PDC: Sistema di controllo sensori ........................................................... 13
Il componente di interazione umana (HIC) .................................................................................... 14
Strategia di “Populating of the Navigational Model” ................................................................ 15
L’usabilità e la progettazione delle interazioni .............................................................................. 15
La consistenza ............................................................................................................................ 16
Riduzione dei passi .................................................................................................................... 16
Niente “sonno” del sistema ........................................................................................................ 16
Completezza ............................................................................................................................... 16
Undo ........................................................................................................................................... 16
Non far uso di RAM umana ....................................................................................................... 16
Ridurre lo sforzo di apprendimento ........................................................................................... 16
Look & Feel ............................................................................................................................... 16
Usabilità: Guidelines o Patterns? ................................................................................................... 16
Un esempio HIC-1: Sistema di controllo sensori......................................................... 18
Un esempio HIC-2 per il Web: Il Model-View-Controller ........................................... 20
System Interaction o Task Management Component (TMC) ........................................................ 23
Determinazione del TMC............................................................................................................... 23
Identificare le task attivate da eventi esterni .............................................................................. 23
Identificare le task attivate da clock di sistema .......................................................................... 23
Identificare le task con priorità e quelle critiche ........................................................................ 23
Il coordinatore dei task ............................................................................................................... 24
Verifica dei task ......................................................................................................................... 24
Definizione di un task ................................................................................................................ 24
Il Componente di Gestione Dati o Data Management Component (DMC) ................................... 25
Progettazione del DMC .............................................................................................................. 25
Conclusioni ........................................................................................................................................ 25
Riferimenti ......................................................................................................................................... 27
27
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