High Quality
Open the downloaded document, and select print from the file menu (PDF reader required).
1
Modellare con UML ed i colori
Ing. R. TurcoCopyright 2003
–
R. Turco
2
Introduzione
L’Analisi e la progettazione Object Oriented di un sistema richiede una mentalità diversarispetto all’approccio funzionale classico.
In realtà il nostro modo di concepire il mondo è proprio di immaginarlo attraverso unarappresentazione ad oggetti.Modellare un sistema, tuttavia, non è così semplice come potrebbe sembrare e richiede unasensibilità 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 deglistati, il modello delle sequenze, il modello delle classi, il modello dei packeges, ilmodello di deployment, il modello dei componenti, etc;
Individuazione degli oggetti, degli attributi, dei servizi, delle strutture, dei soggetticoinvolti;
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 perso
ne 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 notevoleinteresse, sia possibile affron
tare 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, minimonecessario, estensibile, robusto e innanzitutto resistente ai cambiamenti.Il modello a colori rappresenta una validissima tecnica che permette di tirar fuori in modoprevedibile 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 siavvicina 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ò vu
ol 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 diugual natura.Il metodo di Coad propone di colorare gli archetipi, una volta individuati. Questo facilita unamaggiore visibilità e permette una modellazione a strati (layering). I
colori
proposti sono ilgiallo (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 versogiusto.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)
Add a Comment