Opzioni di rappresentazione |
Rappresentazione UML: Modello, stereotipato come <<modello di analisi>>.
Il modello di analisi potrebbe avere le seguenti proprietà:
-
Introduzione: Una descrizione testuale che serve come breve introduzione al modello.
-
Pacchetti di analisi: I pacchetti nel modello che rappresentano una cronologia.
-
Classi: Le classi nel modello possedute dai pacchetti.
-
Rapporti: I rapporti nel modello posseduto dai pacchetti.
-
Realizzazioni del caso d'uso: Le realizzazioni del caso d'uso nel modello, possedute dai
pacchetti.
-
Diagrammi : I diagrammi nel modello posseduti dai pacchetti.
Normalmente, le "classi di analisi" evolvono direttamente in elementi nel Modello di progetto: alcuni diventano classi
di progetto e altri sottosistemi di progetto. L'obiettivo dell'analisi è di identificare una mappatura preliminare
delle funzionalità richieste ad elementi di modellazione nel sistema. L'obiettivo del Progetto è di trasformare questa
mappatura preliminare (e in qualche modo idealizzata) in un insieme di elementi di modello che possono essere
implementati. Come risultato, c'è un perfezionamento nei dettagli e nella precisione quando ci si sposta dall'Analisi
al Progetto. Come risultato, le "classi di analisi" sono spesso abbastanza fluide, modificabili ed evolvono molto prima
di solidificarsi nel progetto.
Punti da considerare quando si decide se è necessario un Modello di analisi separato:
-
Un modello di analisi separato può essere utile quando il sistema deve essere progettato per più ambienti di
destinazione con architetture di progetto separate. Il modello di analisi è un'astrazione, o una generalizzazione
del modello di progetto. Questo omette la maggior parte dei dettagli del progetto per fornire una panoramica della
funzionalità del sistema.
-
Il progetto è complesso, tanto che è necessario un "progetto" semplificato e astratto per introdurre il progetto a
nuovi membri del team. Di nuovo, un'architettura ben definita può servire allo stesso scopo.
-
Il lavoro supplementare richiesto per assicurare che i modelli di Analisi & progetto restino coerenti deve
essere bilanciato rispetto al beneficio di avere una vista del sistema che rappresenta solo i dettagli più
importanti di come funziona il sistema. Può essere molto costoso conservare un alto grado di fedeltà tra il modello
di analisi ed il modello di progetto. Un approccio meno ambizioso potrebbe essere di conservare il Modello di
analisi con solo le classi di dominio più importanti e le astrazioni chiave nel progetto. Se aumenta la complessità
del modello di analisi, aumenta anche il costo per conservarlo.
-
Quando il modello di analisi non è più conservato, il suo valore decade rapidamente. Ad un certo punto, se non
viene conservato, smetterà di essere utile poiché non rifletterà più accuratamente il progetto corrente del
sistema. Decidere di non conservare più il modello di analisi potrebbe essere appropriato (potrebbe essere servito
allo scopo), ma la decisione dovrebbe essere consapevole.
In alcune società, dove i sistemi durano decenni, o dove ci sono molte varianti del sistema, è utile un modello di
analisi separato.
|