Linea guida: Modello di progettazione
Questa linea guida spiega come derivare il modello di progettazione dal modello di analisi.
Relazioni
Elementi correlati
Descrizione principale

Identificazione degli elementi di progettazione dalle classi di analisi Inizio pagina

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.

Mappatura al modello di analisi Inizio pagina

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: 

Il diagramma mostra la dipendenza di traccia.

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.

Mappatura al modello di implementazione

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.

Caratteristiche di un buon 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.