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.
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.
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
dettagliato
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 evoluzione
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.
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.
|