Concetto: Corrispondenza da progettazione a codice
Questa linea guida descrive alcune opzioni differenti per passare da una progettazione all'implementazione e discute i vantaggi e gli svantaggi di tali approcci.
Relazioni
Elementi correlati
Descrizione principale

Introduzione

La progettazione deve definire elementi sufficienti del sistema per implementarlo senza ambiguità. Il significato di "elementi sufficienti" varia da un progetto all'altro e da un'azienda all'altra.

In alcuni casi, la progettazione assomiglia a una bozza, elaborata solo per assicurare che l'implementatore possa procedere (approccio "bozza e codice"). Il grado di specifica varia con l'esperienza dell'implementatore, con la complessità della progettazione e con il rischio che è possibile che la progettazione venga interpretata erroneamente.

In altri casi, la progettazione viene elaborata al punto in cui è possibile convertire automaticamente la progettazione nel codice. Ciò implica, generalmente, estensioni all'UML standard per rappresentare il linguaggio e/o la semantica specifica dell'ambiente.

La progettazione può anche essere gerarchica, ad esempio:

  • un modello di progettazione di livello elevato che abbozza una panoramica del sistema generale
  • un modello di specifica del sottosistema che determina, in modo preciso, la funzionalità e le interfacce necessarie dei sottosistemi principali all'interno del sistema
  • un modello di progettazione dettagliato per l'interno dei sottosistemi

Il  Caso di sviluppo dovrebbe definire le modalità con cui il modello di progettazione viene realizzato nel processo specifico del progetto e come/se il modello è correlato ad altri modelli e all'implementazione. Per dettagli, consultare le  Linee guida specifiche del progetto.

Le sezioni seguenti descrivono delle opzioni differenti per correlare una progettazione e un'implementazione e trattano i vantaggi e gli svantaggi di tali approcci.

Bozza e codice

Un approccio comune di progettazione è abbozzare la progettazione a un livello lievemente astratto e quindi passare direttamente al codice. La gestione del modello di progettazione è manuale.

In questo approccio, la classe di progettazione è un'astrazione di diverse classi a livello del codice. Si consiglia di mappare ogni classe di progettazione a una classe principale che, a sua volta, può utilizzare diverse classi "di aiuto" per eseguire la propria funzionalità. E' possibile utilizzare le classi "di aiuto" per implementare un attributo complesso o per costruire una struttura di dati necessaria per l'implementazione di un'operazione. Nella progettazione, non vengono modellate le classi "di aiuto", ma solo gli attributi chiave, le relazioni e le operazioni definite dalla classe principale. Lo scopo di tale modello è astrarre i dettagli che è possibile completare tramite l'implementatore.

Questo approccio viene esteso per essere applicato ad altri elementi del modello di progettazione. E' possibile che esistano interfacce di progettazione più astratte delle interfacce a livello del codice e così via.

Round-Trip Engineering

In ambienti di round-trip engineering, il modello di progettazione evolve a un livello di dettaglio in cui diventa una rappresentazione visiva del codice. Il codice e la relativa rappresentazione visiva sono sincronizzati (con supporto di tool).

Di seguito vengono riportate alcune opzioni per rappresentare un modello di progettazione in un contesto di round-trip engineering.

Modello di progettazione di livello elevato e Modello di progettazione dettagliatoInizio pagina

In questo approccio, vengono mantenuti due livelli del modello di progettazione. Ogni elemento di progettazione di livello elevato è un'astrazione di uno o più elementi dettagliati nel modello round-trip. Ad esempio, è possibile che una classe di progettazione sia mappata a una classe principale e a diverse classi "di aiuto", come avviene nell'approccio "bozza e codice", descritto in precedenza. La tracciabilità dagli elementi del modello di progettazione di livello elevato agli elementi del modello round-trip consente per mantenere la coerenza tra i due modelli.

Sebbene ciò consenta di trascurare i dettagli meno importanti, tale vantaggio deve essere bilanciato rispetto all'impegno richiesto per mantenere la coerenza tra i modelli.

Modello di progettazione singolo in evoluzioneInizio pagina

In questo approccio, è presente un modello di progettazione singolo. Le bozze iniziali degli elementi di progettazione vengono elaborate fino al punto in cui possono essere sincronizzate con il codice. I diagrammi, come quelli utilizzati per descrivere le realizzazioni dei casi d'uso di progettazione, inizialmente fanno riferimento alle classi di progettazione abbozzate, ma alla fine si riferiscono alle classi specifiche del linguaggio. Le descrizioni di livello elevato della progettazione vengono gestite secondo le necessità, come ad esempio:

  • diagrammi della struttura logica del sistema,
  • specifiche del componente/sottosistema,
  • meccanismi/modelli di progettazione.

Tale modello è più semplice da mantenere coerente con l'implementazione.

Modelli di realizzazione e di specifica

Un approccio correlato è definire la progettazione in termini di specifiche per sottosistemi principali, dettagliate al punto in cui le implementazioni del client possono eseguire la compilazione rispetto ad esse.

La progettazione dettagliata della realizzazione del sottosistema può essere modellata e mantenuta separatamente da questo modello di specifica.

Consultare Linea guida del prodotto di lavoro: Sottosistema di progettazione per linee guida relative alle realizzazioni e alle specifiche del sottosistema e al momento in cui occorre utilizzarle.