Usare i modelli nel processo di sviluppo

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

Per vedere quali versioni di Visual Studio supportano ogni tipo di modello, vedere Supporto della versione per gli strumenti di architettura e modellazione.

I modelli possono essere utili in diversi modi:

• I diagrammi di modellazione di disegno consentono di chiarire i concetti coinvolti in requisiti, architettura e progettazione di alto livello. Per altre informazioni, vedere Requisiti utente del modello.

• L'uso dei modelli consente di esporre incoerenze nei requisiti.

• La comunicazione con i modelli consente di comunicare concetti importanti in modo meno ambiguo rispetto al linguaggio naturale. Per altre informazioni, vedere Modellare l'architettura dell'app.

• A volte è possibile usare i modelli per generare codice o altri artefatti, ad esempio schemi di database o documenti. Ad esempio, i componenti di modellazione di Visual Studio vengono generati da un modello. Per altre informazioni, vedere Generare e configurare l'app dai modelli.

È possibile usare modelli in un'ampia gamma di processi, dall'estremo agile ai processi ad alto formalismo.

Usare i modelli per ridurre l'ambiguità

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

Se il progetto ha un piccolo team che segue procedure agile, è possibile usare i modelli per chiarire le storie utente. Nelle discussioni con il cliente sulle proprie esigenze, la creazione di un modello può generare domande utili molto più velocemente e in un'area più ampia del prodotto, rispetto alla scrittura di codice picco o prototipo.

Se il progetto è di grandi dimensioni e include team in diverse parti del mondo, è possibile usare i modelli per comunicare i requisiti e l'architettura molto più efficacemente di quanto sia possibile in testo normale.

In entrambi i casi la creazione di un modello comporta quasi sempre una riduzione significativa delle incoerenze e delle ambiguità. Le diverse parti interessate hanno spesso conoscenze diverse del mondo aziendale in cui funziona il sistema e i diversi sviluppatori hanno spesso conoscenze diverse del funzionamento del sistema. L'uso di un modello come obiettivo di una discussione espone in genere queste differenze. Per altre informazioni su come usare un modello per ridurre le incoerenze, vedere Requisiti utente del modello.

Usare modelli con altri artefatti

Un modello non è per sé una specifica dei requisiti o un'architettura. Si tratta di uno strumento per esprimere alcuni aspetti di queste cose in modo più chiaro, ma non tutti i concetti necessari durante la progettazione software possono essere espressi. I modelli devono quindi essere usati insieme ad altri mezzi di comunicazione, ad esempio pagine o paragrafi di OneNote, documenti di Microsoft Office, elementi di lavoro in Team Foundation o note permanenti sulla parete della sala di progetto. Oltre all'ultimo elemento, tutti questi tipi di oggetto possono essere collegati a parti di elementi del modello.

Altri aspetti della specifica comunemente usati insieme ai modelli includono quanto segue. A seconda della scala e dello stile del progetto, è possibile usare diversi di questi aspetti o non usarli affatto:

• Storie utente. Una storia utente è una breve descrizione, discussa con utenti e altri stakeholder, di un aspetto del comportamento del sistema che verrà distribuito in una delle iterazioni del progetto. Una tipica storia utente inizia "Il cliente sarà in grado di...". Una storia utente può introdurre un gruppo di casi d'uso o definire estensioni di casi d'uso sviluppati in precedenza. La definizione o l'estensione dei casi d'uso consente di rendere più chiara la storia dell'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 considera tutti i requisiti come modifiche a quanto sviluppato nelle iterazioni precedenti.

• Descrizione del caso d'uso. Un caso d'uso rappresenta un modo in cui un utente interagisce con il sistema per raggiungere un determinato obiettivo. Una descrizione completa include l'obiettivo, le sequenze principali e alternative degli eventi e risultati eccezionali. Un diagramma dei casi d'uso consente di riepilogare e fornire una panoramica dei casi d'uso.

• Scenari. Uno scenario è una descrizione abbastanza dettagliata di una sequenza di eventi che mostra come il sistema, gli utenti e altri sistemi interagiscono per fornire valore agli stakeholder. Può assumere la forma di una presentazione dell'interfaccia utente o di un prototipo dell'interfaccia utente. Può descrivere un caso d'uso o una sequenza di casi d'uso.

• Glossario. Il glossario dei requisiti del progetto descrive le parole con cui i clienti discutono del loro mondo. I modelli di interfaccia utente e requisiti devono usare anche queste condizioni. Un diagramma classi può aiutare a chiarire le relazioni tra la maggior parte di questi termini. La creazione di diagrammi e glossario non solo riduce i malintesi tra utenti e sviluppatori, ma anche quasi sempre espone malintesi tra diversi stakeholder aziendali.

• Regole di business. Molte regole business possono essere espresse come vincoli invarianti per le associazioni e gli attributi nel modello di classe dei requisiti e come vincoli sui diagrammi di sequenza.

• Progettazione di alto livello. Descrive le parti principali e il modo in cui si adattano. I diagrammi componenti, sequenza e interfaccia sono una parte importante di una progettazione di alto livello.

• Schemi progettuali. 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 di test possono usare i diagrammi di attività e sequenza per descrivere le sequenze dei passaggi di test. I test di sistema devono essere espressi in termini di modello di requisiti in modo che possano essere facilmente modificati quando cambiano i requisiti.

• Piano di progetto. Il piano di progetto o il backlog definisce quando ogni funzionalità verrà recapitata. È possibile definire ogni funzionalità indicando quali casi d'uso e regole business implementa o estende. È possibile fare riferimento ai casi d'uso e alle regole business direttamente nel piano oppure definire un set di funzionalità in un documento separato e usare i titoli delle funzionalità nel piano.

Usare i modelli nella pianificazione dell'iterazione

Anche se tutti i progetti sono diversi nella scala e nell'organizzazione, un progetto tipico è pianificato come una serie di iterazioni di tra due e sei settimane. È importante pianificare sufficienti iterazioni per consentire l'uso di feedback dalle iterazioni iniziali per modificare l'ambito e i piani per le iterazioni successive.

È possibile trovare i suggerimenti seguenti utili per comprendere i vantaggi della modellazione in un progetto iterativo.

Affina la concentrazione con l'avvicinarsi di ciascuna iterazione

Poiché ogni iterazione si avvicina, usare i modelli per definire ciò che deve essere recapitato alla fine dell'iterazione.

• Non modellare tutti gli elementi in dettaglio nelle iterazioni iniziali. Nella prima iterazione creare un diagramma classi per gli elementi principali del glossario utente, disegnare un diagramma dei casi d'uso principali e disegnare un diagramma dei componenti principali. Non descrivere nessuno di questi in dettaglio, perché i dettagli cambieranno più avanti nel progetto. Usare i termini definiti in questo modello per creare un elenco di funzionalità o storie utente principali. Assegnare le funzionalità alle iterazioni in modo da bilanciare approssimativamente il carico di lavoro stimato in tutto il progetto. Queste assegnazioni cambieranno più avanti nel progetto.

• Provare a implementare versioni semplificate di tutti i casi d'uso più importanti in un'iterazione anticipata. Estendere tali casi d'uso nelle iterazioni successive. Questo approccio consente di ridurre il rischio di individuare un difetto nei requisiti o l'architettura troppo tardi nel progetto per eseguire qualsiasi operazione.

• Al termine di ogni iterazione, tenere un workshop sui requisiti per definire in dettaglio i requisiti o le storie utente che verranno sviluppate nell'iterazione successiva. Invitare utenti e stakeholder aziendali che possono decidere le priorità, nonché sviluppatori e tester di sistema. Consentire tre ore per definire i requisiti per un'iterazione di 2 settimane.

• L'obiettivo del workshop è consentire a tutti di accettare ciò che verrà realizzato entro la fine dell'iterazione successiva. Usare i modelli come uno degli strumenti per chiarire i requisiti. L'output del workshop è un backlog di iterazione, ovvero un elenco di attività di sviluppo in Team Foundation e gruppi di test in Microsoft Test Manager.

• Nel workshop sui requisiti, discutere la progettazione solo nella misura in cui è necessario stabilire le stime per le attività di sviluppo. In caso contrario, continuare a discutere sul comportamento del sistema che gli utenti possono sperimentare direttamente. Mantenere il modello di requisiti separato dal modello di architettura.

• Gli stakeholder non tecnici in genere non hanno problemi a comprendere i diagrammi UML, con alcune indicazioni da parte dell'utente.

Collegare il modello agli elementi di lavoro

Dopo il workshop sui requisiti, elaborare i dettagli del modello di requisiti e collegare il modello alle attività di sviluppo. A tale scopo, è possibile collegare gli elementi di lavoro in Team Foundation agli elementi nel modello.

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

• Commenti che descrivono le regole business o i requisiti di qualità del servizio. Per altre informazioni, vedere Requisiti utente del modello.

Collegare il modello ai test

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

Per altre informazioni su questa tecnica, vedere Sviluppare test da un modello.

Stimare il lavoro rimanente

Un modello di requisiti consente di stimare le dimensioni totali del progetto in relazione alle dimensioni di ogni iterazione. La valutazione del numero e della complessità dei casi d'uso e delle classi consente di stimare il lavoro di sviluppo che sarà necessario. Dopo aver completato le prime iterazioni, un confronto dei requisiti coperti e i requisiti ancora da coprire possono fornire una misura approssimativa del costo e dell'ambito del resto del progetto.

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

Livelli di astrazione

I modelli hanno una gamma di astrazioni in relazione al software. I modelli più concreti rappresentano direttamente il codice del programma e i modelli più astratti rappresentano concetti aziendali che potrebbero o non essere rappresentati nel codice.

Un modello può essere visualizzato tramite diversi tipi di diagrammi. Per informazioni su modelli e diagrammi, vedere Creare modelli per l'app.

Diversi tipi di diagramma sono utili per descrivere la progettazione a diversi livelli di astrazione. Molti dei tipi di diagramma sono utili a più di un livello. Questa tabella illustra come usare ogni tipo di diagramma.

Livello di progettazione	Tipi di diagramma
Processo aziendale Comprendere il contesto all'interno del quale verrà usato il sistema consente di comprendere le esigenze degli utenti.	- I diagrammi classi concettuali descrivono i concetti aziendali usati all'interno del processo aziendale.
Requisiti dell'utente Definizione delle esigenze degli utenti dal sistema.	- Le regole business e i requisiti di qualità del servizio possono essere descritti in documenti separati.
Progettazione generale La struttura complessiva del sistema: i componenti principali e il modo in cui si associano.	- Diagrammi di dipendenza descrive come il sistema è strutturato in parti interdipendenti. È possibile convalidare il codice del programma rispetto ai diagrammi di dipendenza per assicurarsi che sia conforme all'architettura.
Analisi del codice I diagrammi possono essere generati dal codice.	- I diagrammi di dipendenza mostrano le dipendenze tra le classi. Il codice aggiornato può essere convalidato in base a un diagramma delle dipendenze. - I diagrammi classi mostrano le classi nel codice.

Risorse esterne

Categoria	Collegamenti
video	Video Tutorial MSDN: Come Creare e Utilizzare Modelli e Diagrammi UML (Visual Studio Ultimate) MSDN How Do I Series: UML Tools and Extensibility (Visual Studio Ultimate)
Forum	- Visual Studio Visualization & Modeling Tools Visual Studio Visualization & Modeling SDK (DSL Tools)
Blog	Microsoft DevOps
Articoli tecnici e journal	MSDN Architecture Center

Contenuti correlati

• Usare i modelli nello sviluppo Agile
• Creare modelli per l'app
• Requisiti utente del modello
• Modellare l'architettura dell'app
• Sviluppare test da un modello
• Strutturare la soluzione di modellazione

Annotazioni

Il componente Trasformazione modello di testo viene installato automaticamente come parte del carico di lavoro di sviluppo di estensioni per Visual Studio. È anche possibile installarlo dalla scheda Singoli componenti del programma di installazione di Visual Studio, nella categoria SDK, librerie e framework . Installare il componente Modeling SDK dalla scheda Singoli componenti .