Utilizzo di modelli nel processo di sviluppo

Articolo
08/11/2011

In Visual Studio Ultimate è possibile utilizzare un modello per individuare e modificare un sistema, un'applicazione o un componente. Un modello consente di visualizzare il mondo in cui funziona il sistema, chiarire le necessità degli utenti, definire l'architettura del sistema, analizzare il codice e assicurarsi che il codice soddisfi i requisiti.

Per un introduzione video, vedere il video: UML con Visual Studio 2010

Procedura: utilizzare i modelli

I modelli sono utili per diversi motivi:

Disegnando diagrammi di modellazione è possibile chiarire i concetti coinvolti in requisiti, architettura e progettazione ad alto livello. Per ulteriori informazioni, vedere Modellazione dei requisiti utente.
L'utilizzo di modelli può consentire di esporre le incoerenze dei requisiti.
Comunicando con i modelli è possibile comunicare concetti importanti in modo meno ambiguo rispetto al linguaggio naturale. Per ulteriori informazioni, vedere Modellazione dell'architettura di un sistema software.
È possibile qualche volta utilizzare i modelli per generare codice o altri elementi quali schemi di database o documenti. Ad esempio, i componenti di modellizzazione di Visual Studio Ultimate vengono generati da un modello. Per ulteriori informazioni, vedere Generazione e configurazione dell'applicazione dai modelli.

I modelli possono essere utilizzati in un'ampia varietà di processi, da quelli estremamente agili a quelli molto formali.

Utilizzo dei modelli per ridurre l'ambiguità

Il linguaggio di modellazione è meno ambiguo del linguaggio naturale ed è progettato per esprimere le idee generalmente richieste durante lo sviluppo del software.

Se il progetto prevede un piccolo team che segue le procedure Agile, è possibile utilizzare i modelli per chiarire le storie utente. Nelle discussioni con il cliente circa le relative necessità, la creazione di un modello può generare domande utili molto più velocemente e in relazione a un'area del prodotto più ampia rispetto alla scrittura del codice del raccoglitore o del prototipo.

Se il progetto è grande e include team in diverse parti a livello mondiale, è possibile utilizzare i modelli per comunicare i requisiti e l'architettura molto più efficacemente rispetto al testo normale.

In entrambi i casi, la creazione di un modello quasi sempre comporta una riduzione significativa di incoerenze e ambiguità. Parti interessate diverse frequentemente hanno percezioni diverse del mondo aziendale nelle quali funziona il sistema e sviluppatori diversi frequentemente hanno percezioni diverse sul funzionamento del sistema. L'utilizzo di un modello come stato attivo di una discussione generalmente espone queste differenze. Per ulteriori informazioni su come utilizzare un modello per ridurre le incoerenze, vedere Modellazione dei requisiti utente.

Utilizzo dei modelli con altri elementi

Un modello in sé non è una specifica di requisiti o un'architettura. È un strumento per esprimere alcuni aspetti di questi elementi più chiaramente, ma non tutti i concetti richiesti durante la progettazione del software possono essere espressi. I modelli devono essere utilizzati pertanto insieme con altri mezzi di comunicazione, ad esempio pagine o paragrafi OneNote, documenti di Microsoft Office, elementi di lavoro in Team Foundation o Sticky Notes sulla bacheca della stanza del progetto. Eccetto l'ultimo elemento, tutti questi tipi di oggetto possono essere collegati a parti di elementi del modello.

Gli altri aspetti della specifica che sono normalmente utilizzati insieme ai modelli includono gli elementi seguenti. A seconda della scala e dello stile del progetto, è possibile utilizzare diversi di questi aspetti o non utilizzarli affatto:

Storie utente. Una storia utente è una breve descrizione, discussa con utenti e altre parti interessate, di un aspetto del comportamento del sistema che verrà recapitato in una delle iterazioni del progetto. Una storia utente tipica inizia "Il cliente sarà in grado di..." Una storia utente potrebbe introdurre un gruppo di casi di utilizzo o definire estensioni di casi di utilizzo che sono stati sviluppati precedentemente. La definizione o l'estensione dei casi di utilizzo consente di rendere più chiara la storia utente.
Richieste di modifica. Una richiesta di modifica in un progetto più formale è molto simile a una storia utente in un progetto Agile. L'approccio Agile tratta tutti i requisiti come modifiche a ciò che è stato sviluppato nelle iterazioni precedenti.
Descrizione del caso di utilizzo. Un caso di utilizzo rappresenta un modo in cui un utente interagisce con i sistema per il raggiungimento di obiettivo particolare. Una descrizione completa include l'obiettivo, le sequenze principali e alternative degli eventi e risultati eccezionali. Un diagramma caso di utilizzo consente di riepilogare e fornire una panoramica dei casi di utilizzo.
Scenari. Un scenario è una descrizione abbastanza dettagliata di una sequenza di eventi che mostrano come il sistema, gli utenti e altri sistemi collaborano per fornire il valore alle parti interessate. Potrebbe essere nel formato di una presentazione dell'interfaccia utente o un prototipo dell'interfaccia utente. Può descrivere un caso di utilizzo o una sequenza di casi di utilizzo.
Glossario. Il glossario dei requisiti del progetto descrive le parole utilizzate dai clienti nelle discussioni. Questi termini devono essere utilizzati anche nell'interfaccia utente e nei modelli dei requisiti. Un diagramma classi può chiarire le relazioni tra la maggior parte di questi termini. La creazione dei diagrammi e del glossario non solo riduce malintesi tra utenti e sviluppatori, ma quasi sempre evidenzia anche malintesi tra le diverse parti interessate aziendali.
Regole business. Molte regole business possono essere espresse come vincoli invariabili sulle associazioni e sugli attributi nel modello di classe requisiti e come vincoli sui diagrammi di sequenza.
Progettazione ad alto livello. Descrive le parti principali e come si combinano insieme. I diagrammi dei componenti, di sequenza e di interfaccia costituiscono una parte importante di una progettazione ad alto livello.
Modelli di progettazione. Descrivere le regole di progettazione condivise tra le diverse parti del sistema.
Specifiche di test. Gli script di test e le progettazioni per il codice del test possono avvalersi dei diagrammi di sequenza e attività per descrivere le sequenze di passi del test. I test del sistema devono essere espressi nei termini del modello dei requisiti in modo che sia possibile modificarli facilmente quando cambiano i requisiti.
Piano di progetto. Il piano del progetto o il backlog definisce quando ogni funzionalità verrà recapitata. È possibile definire ogni funzionalità dichiarando i casi di utilizzo e le regole business che implementa o estende. È possibile riferirsi direttamente nel piano ai casi di utilizzo e alle regole business o è possibile definire un set di funzionalità in un documento separato e utilizzare i titoli delle funzionalità nel piano.

Utilizzo di modelli nel piano di iterazione

Anche se tutti i progetti sono diversi per scala e organizzazione, un progetto tipico è pianificato come una serie di iterazioni da due a sei settimane. È importante pianificare sufficienti iterazioni per consentire di utilizzare il feedback delle iterazioni precedenti per regolare l'ambito e i piani per le iterazioni successive.

I suggerimenti riportati di seguito possono risultare utili per comprendere i vantaggi della modellazione in un progetto iterativo.

Stato attivo all'approccio di ogni iterazione

All'approccio di ogni iterazione, utilizzare i modelli per definire quello che deve essere recapitato alla fine dell'iterazione.

Non modellare tutto in dettaglio nelle prime iterazioni. Nella prima iterazione, creare un diagramma classi per gli elementi principali nel glossario dell'utente, disegnare un diagramma dei casi di utilizzo principali e disegnare un diagramma dei componenti principali. Non descrivere nessuno di essi dettagliatamente perché il dettaglio verrà modificato in un secondo momento nel progetto. Utilizzare i termini definiti in questo modello per creare un elenco di funzionalità o di storie utente principali. Assegnare le funzionalità alle iterazioni come per bilanciare approssimativamente il carico di lavoro stimato in tutto il progetto. Queste assegnazioni cambieranno in un secondo momento nel progetto.
Tentare di implementare le versioni semplificate di tutti i più importanti casi di utilizzo in una prima iterazione. Estendere i casi di utilizzo nelle iterazioni successive. Questo approccio consente di ridurre il rischio di individuare un difetto nei requisiti o nell'architettura del progetto con troppo ritardo per poterlo correggere.
Verso la fine di ogni iterazione, mantenere un workshop di requisiti per definire in dettaglio i requisiti o le storie utente che saranno sviluppati nell'iterazione successiva. Invitare gli utenti e le parti interessate delle aziende che possono decidere le priorità nonché gli sviluppatori e i tester di sistema. Predisporre tre ore per definire i requisiti per un'iterazione di 2 settimane.
L'obiettivo del workshop è per ognuno accettare quello che sarà restituito alla fine dell'iterazione successiva. Utilizzare i modelli come uno degli strumenti per chiarificare i requisiti. L'output del workshop è un backlog dell'iterazione, ovvero un elenco di attività di sviluppo in Team Foundation e i gruppi di test in Microsoft Test Manager.
Nel workshop dei requisiti, discutere la progettazione solo nella misura in cui è necessario determinare le stime per le attività di sviluppo. In caso contrario, tenere la discussione sul comportamento del sistema che gli utenti possono verificare direttamente. Tenere il modello requisiti separato dal modello d'architettura.
Le parti interessate non tecniche di solito non hanno problemi di comprensione dei diagrammi UML, con qualche istruzione per l'utente.

Modello di collegamento a elementi di lavoro

Dopo il workshop di requisiti, elaborare i dettagli del modello requisiti e connettere il modello alle attività di sviluppo. È possibile procedere connettendo gli elementi di lavoro in Team Foundation agli elementi nel modello. Per informazioni su come eseguire questa operazione, vedere Procedura: collegare elementi di modello a elementi di lavoro.

È possibile connettere qualsiasi elemento agli elementi di lavoro, ma gli elementi più utili sono:

Casi di utilizzo. È possibile collegare un caso di utilizzo alle attività di sviluppo che lo implementeranno.
Estensioni del caso di utilizzo. Se solo un aspetto di un caso di utilizzo sarà implementato in un'iterazione, è possibile separarlo insieme in un caso di utilizzo di base con una o più estensioni. Le estensioni sono casi di utilizzo collegati al caso di base con la relazione «estendi». Per ulteriori informazioni sull'estensione dei casi di utilizzo, vedere Diagrammi casi di utilizzo UML: riferimento.
Commenti che descrivono regole business o requisiti di qualità del servizio. Per ulteriori informazioni, vedere Modellazione dei requisiti utente.

Collegamento del modello ai test

Utilizzare il modello requisiti per guidare la progettazione dei test di accettazione. Creare questi test contemporaneamente al lavoro di sviluppo.

Per ulteriori informazioni su questa tecnica, vedere Sviluppo di test da un modello.

Stima del lavoro rimanente

Un modello requisiti può consentire di stimare la dimensione totale del progetto in relazione alla dimensione di ogni iterazione. Stimando il numero e la complessità dei casi di utilizzo e delle classi può contribuire a stimare il lavoro di sviluppo che sarà richiesto. Quando sono state completate le prime iterazioni, un confronto dei requisiti analizzati e dei requisiti ancora analizzare può fornire una indicazione approssimativa del costo e dell'ambito del resto del progetto.

Verso la fine di ogni iterazione, rivedere l'assegnazione dei requisiti alle iterazioni future. Può essere utile per rappresentare lo stato del software alla fine di ogni iterazione come un sottosistema in un diagramma caso di utilizzo. Nelle discussioni, è possibile spostare i casi di utilizzo e le estensioni del caso di utilizzo da uno di questi sottosistemi a un altro.

Livelli di astrazione

I modelli dispongono di un intervallo di astrazione in relazione al software. I modelli più concreti rappresentano direttamente il codice del programma e i modelli più astratti rappresentano i concetti aziendali che hanno potuto o potrebbero non essere rappresentati nel codice.

È possibile visualizzare un modello tramite diversi tipi di diagramma. Per ulteriori informazioni sui modelli e sui diagrammi, vedere Sviluppo di modelli per la progettazione software.

Diversi tipi di diagramma sono utili per descrivere la progettazione a livelli di astrazione diversi. Molti tipi di diagramma sono utili per più di un livello. In questa tabella viene indicato come può essere utilizzato ogni tipo di diagramma.

Livello di progettazione	Tipi di diagramma
Processo aziendale Comprendendo il contesto nel quale sarà utilizzato il sistema è possibile capire le necessità degli utenti.	I diagrammi di attività descrivono il flusso di lavoro tra persone e sistemi per realizzare obiettivi aziendali. I diagrammi classi concettuali descrivono i concetti aziendali utilizzati all'interno del processo aziendale.
Requisiti dell'utente Definizione di ciò che gli utenti necessitano dal sistema.	I diagrammi casi di utilizzo riepilogano le interazioni che gli utenti e gli altri sistemi esterni hanno con il sistema che si sviluppa. È possibile associare altri documenti a ogni caso di utilizzo per una descrizione dettagliata. I diagrammi classi UML descrivono i tipi di informazioni su cui comunicano gli utenti e il sistema. È possibile descrivere le regole business e i requisiti di qualità del servizio in documenti separati.
Progettazione ad alto livello La struttura complessiva del sistema, ossia i componenti principali e gli accoppiamenti.	I diagrammi livello descrivono il modo in cui il sistema è strutturato in parti indipendenti. È possibile convalidare il codice programma in base ai diagrammi livello per assicurarsi che sia conforme all'architettura. I diagrammi componente mostrano le interfacce delle parti, specificando i messaggi e i servizi forniti e richiesti da ciascun componente. I diagrammi di sequenza mostrano come comunicano i componenti per implementare ogni caso di utilizzo. I diagrammi classi UML descrivono le interfacce dei componenti e i tipi di dati passati tra i componenti.
Modelli di progettazione Convenzioni e metodi di risoluzione dei problemi di progettazione utilizzati in tutte le parti della progettazione	I diagrammi classi UML descrivono le strutture di un modello I diagrammi di attività o sequenza mostrano le interazioni e gli algoritmi
Analisi codice È possibile generare molti tipi di diagramma dal codice.	I diagrammi di sequenza mostrano l'interazione tra gli oggetti nel codice. I diagrammi di livello mostrano le dipendenze tra le classi. È possibile convalidare un codice aggiornato in relazione a un diagramma livello. I diagrammi classi mostrano le classi nel codice.

Risorse esterne

Categoria	Collegamenti
Video
Forum	Strumenti di visualizzazione e modellazione di Visual Studio 2010 Visual Studio Visualization and Modeling SDK (Strumenti DSL)
Blog	Blog sugli strumenti di modellazione, visualizzazione e per l'architettura di Visual Studio
Articoli e pubblicazioni tecniche	Articolo del numero 23 di The Architecture Journal dedicato alla modellazione dell'architettura e ai relativi processi
Altri siti	Area Architetti MSDN Documentazione Visual Studio 2010 Architecture Tooling Guidance