Il Prodotto di lavoro: Classi di analisi rappresenta i ruoli svolti
dalle istanze degli elementi di progettazione; questi ruoli possono essere portati avanti da più elementi del modello
di progettazione. Inoltre, un singolo elemento della progettazione può farsi carico di più ruoli. Le osservazioni che
seguono trattano i modi in cui è possibile adempiere ai ruoli dell'analisi:
-
Una classe di analisi può diventare una classe di progettazione singola nel modello di progettazione.
-
Una classe di analisi può diventare parte di una classe di progettazione nel modello di progettazione.
-
Una classe di analisi può diventare una classe di progettazione aggregata nel modello di progettazione. (Ciò
significa che non è possibile modellare esplicitamente le parti contenute in questo aggregato, come classi di
analisi.)
-
Una classe di analisi può diventare un gruppo di classi di progettazione che eredita dalla stessa classe nel
modello di progettazione.
-
Una classe di analisi può diventare un gruppo di classi di progettazione funzionalmente collegate nel modello di
progettazione.
-
Una classe di analisi può diventare un sottosistema di progettazione nel modello di progettazione.
-
Una classe di analisi può diventare parte di un sottosistema di progettazione, come una o più interfacce e
l'implementazione relativa corrispondente.
-
Una classe di analisi può diventare una relazione nel modello di progettazione.
-
Una relazione tre classi di analisi può diventare una classe di progettazione nel modello di progettazione.
-
La classi di analisi gestiscono principalmente i requisiti funzionali e gli oggetti del modello del dominio
"problem"; le classi di progettazione gestiscono i requisiti non funzionali e gli oggetti del modello del dominio
"solution".
-
E' possibile utilizzare le classi di analisi per rappresentare "gli oggetti che desideriamo che vengano supportati
dal sistema" senza prendere una decisione su quanti supportare con l'hardware e quanti col software. Perciò, parte
della classe di analisi può essere realizzata dall'hardware e non modellata affatto nel modello di progettazione.
E' inoltre possibile una qualsiasi combinazione di quanto sopra descritto.
Se si mantiene un modello di analisi separato, accertarsi di aver mantenuto la tracciabilità dall'elemento di
progettazione identificato alle classi di analisi cui corrispondono. Per ulteriori informazioni, consultare Mappatura al modello di analisi.
Questa sezione verrà applicata solo se viene mantenuto un modello di analisi separato.
Durante la progettazione, vengono identificati elementi della progettazione che supportano un allineamento più stretto
all'architettura e le tecnologie scelte. E' necessario associare ogni classe di analisi presente nel modello di
analisi con almeno una classe di progettazione contenuta nel modello di progettazione.
Per modellare questa tracciabilità, è necessario disegnare una dipendenza di<<traccia>> dall'elemento di
progettazione alla classe di analisi che rappresenta, come mostrato nel diagramma seguente:
Nota: i collegamenti di tracciabilità vengono disegnati dagli elementi del modello di progettazione agli
elementi del modello di analisi, così che il modello di progettazione sia dipendente solo dal modello di analisi.
E' necessario decidere, prima che inizi la progettazione il modo in cui è necessario che le classi contenute nel
modello di progettazione si correlino all'implementazione; è necessario descrivere quanto determinato nelle linee guida
di progettazione specifiche del progetto.
Il modello di progettazione può essere più o meno vicino al modello di implementazione, a seconda del modo in cui
vengono mappate le classi, i pacchetti ed i sottosistemi alle classi di implementazione, ai file, ai pacchetti ed ai
sottosistemi nel modello di implementazione. Durante l'implementazione, verranno spesso risolti piccoli problemi
tattici relativi all'ambiente di implementazione che non è necessario influenzino il modello di progettazione. Ad
esempio, è possibile aggiungere classi e sottosistemi durante l'implementazione per gestire lo sviluppo parallelo
oppure per regolare le dipendenze di importazione. Per ulteriori informazioni, fare riferimento alla sezione Compito: Strutturare il modello di implementazione e Tecnica: Mappatura dalla progettazione al codice.
E' necessaria una costante mappatura dal modello di progettazione al modello di implementazione. E' necessario che in
Prodotto di lavoro: Linee guida specifiche del progetto venga
definita questa mappatura e che venga applicato un livello costante attraverso il modello di progettazione.
Un buon modello di progettazione dispone delle
seguenti caratteristiche:
-
Soddisfa i requisiti del sistema.
-
E' resistente alle modifiche nell'ambiente di implementazione.
-
E' facile da mantenere rispetto ad altri modelli di oggetto possibili e all'implementazione del sistema.
-
La modalità di implementazione relativa è chiara.
-
Non include informazioni che siano meglio documentate nel codice del programma.
-
Si adatta facilmente alle modifiche nei requisiti.
Per caratteristiche specifiche, consultare la sezione Elenco di
controllo: Modello di progettazione.
|