Creare un'architettura della soluzione

Parte della creazione di un'architettura soddisfacente consiste nell'individuazione di strategie architetturali alternative. Le strategie alternative comportano vantaggi diversi a seconda della scelta della piattaforma, delle tecnologie utilizzate e del riutilizzo del codice. Viene progettata una strategia e quindi vengono compilati i relativi modelli di prova per determinare ulteriormente i costi e i vantaggi di ogni strategia. Le strategie vengono valutate rispetto ai requisiti di qualità e del prodotto e viene quindi scelta una strategia da utilizzare per implementare il prodotto. La sicurezza e le prestazioni rappresentano infine aspetti architetturali importanti per cui è necessario lavorare sull'intero prodotto.

In questo argomento

• Creare progettazioni di partizionamento di architetture alternative

• Progettare l'architettura e la distribuzione del sistema

• Creare modelli di prova

• Valutare le alternative

• Selezionare l'architettura

• Sviluppare un modello di prestazioni

Creare progettazioni di partizionamento di architetture alternative

Viene analizzato il problema e vengono considerati diversi approcci. Viene selezionato un gruppo di requisiti che rappresentano le principali sfide aziendali e tecnologiche. Esaminare le caratteristiche di tali sfide, ad esempio l'integrazione di sistemi legacy, e prevedere le esigenze future in base a quelle attuali, alla riusabilità del codice e ai costi di manutenzione.

Creare un diagramma applicazioni

Utilizzando il modello di dominio e i requisiti come input, creare un diagramma applicazioni che rappresenta gli elementi logici principali del sistema. Tale diagramma verrà partizionato in seguito in diagrammi sistema. Verranno considerati e valutati schemi di partizionamento alternativi.

Un metodo per rappresentare un diagramma applicazioni consiste nel rappresentarlo come diagramma caso di utilizzo UML (Unified Modeling Language). In questo tipo di diagramma è possibile mostrare i sottosistemi principali e le relative dipendenze. È inoltre possibile inserire casi di utilizzo in ogni sottosistema per mostrare il sottosistema che gestisce ogni scenario utente.

Stabilire criteri di valutazione

Determinare i criteri da utilizzare per identificare i requisiti e gli scenari che rappresentano sfide architetturali significative. Consultare i documenti esistenti relativi all'architettura dell'organizzazione per individuare i criteri. Esaminare tutti i requisiti aziendali, i requisiti tecnici e gli standard aziendali che è necessario adottare per le nuove applicazioni. Includere criteri aggiuntivi ritenuti significativi dal punto di vista architetturale, quali integrazione con sistemi legacy, riusabilità del codice, riutilizzo di librerie e piattaforme esistenti dei fornitori e controllo dei costi di manutenzione. Includere criteri aggiuntivi che rappresentano rischi e costi per l'implementazione di una soluzione tecnica.

Selezionare un gruppo di requisiti candidato

Valutare ogni requisito di qualità del servizio e del prodotto rispetto ai criteri di valutazione. Se un requisito rappresenta una sfida architetturale, considerarlo un candidato per la modellazione. Un requisito che stabilisce, ad esempio, che il nuovo prodotto deve supportare i database dei clienti meno recenti soddisfa i criteri di integrazione con sistemi legacy. Tale requisito è un candidato per la modellazione del funzionamento dell'integrazione.

Selezionare un gruppo di scenari candidato

Valutare ogni scenario rispetto ai criteri di valutazione. Se uno scenario rappresenta una sfida architetturale, considerarlo un candidato per la modellazione. Uno scenario, ad esempio, in cui l'utente scarica un aggiornamento client soddisfa i criteri relativi ai costi di manutenzione. Tale scenario è un candidato per la modellazione della migliore modalità di gestione degli aggiornamenti client.

Ridurre il gruppo candidato

Esaminare gli scenari e i requisiti candidati. Rimuovere gli scenari e i requisiti che comportano criteri di valutazione duplicati o che possono essere rappresentati in modo migliore da altri scenari e requisiti. Ridurre il gruppo candidato a un gruppo di base che rappresenta i principali rischi, costi e sfide architetturali della nuova applicazione. Mantenere solo gli scenari e i requisiti che rappresentano al meglio i criteri di valutazione e che tengono conto dei rischi e dei costi potenziali maggiori per l'architettura di una soluzione tecnica. Mantenere gli scenari e i requisiti più esaustivi o che rappresentano i componenti principali dell'applicazione.

Creare criteri di partizionamento

Utilizzando i requisiti come motivazione, analizzare modelli architetturali stabiliti, ad esempio un modello di modellazione, visualizzazione e controller, e identificare i possibili candidati per l'implementazione. Identificare i modelli candidati tramite la rispettiva motivazione e considerarne i compromessi di progettazione rispetto a accoppiamento, coesione, estensibilità, adattabilità e flessibilità. Selezionare un set di candidati per l'implementazione come alternativa per la valutazione.

Progettare l'architettura e la distribuzione del sistema

L'architettura del sistema definisce i raggruppamenti e le configurazioni degli elementi identificati nel diagramma applicazioni. Vengono creati diagrammi sistema che definiscono l'architettura del sistema per ogni possibile approccio architetturale. I diagrammi distribuzione indicano i passaggi di distribuzione basati sulle dipendenze e le funzionalità di base. Un architetto dell'infrastruttura crea un diagramma centro dati logico in cui viene descritta la struttura logica del centro dati logico in cui verrà distribuita l'applicazione. I diagrammi distribuzione vengono convalidati rispetto al diagramma centro dati logico per verificare che i sistemi possano essere distribuiti.

Creare un modello del sistema

L'architetto e il responsabile dello sviluppo creano diagrammi sistema dal diagramma applicazioni. Tramite i diagrammi sistema è possibile progettare sistemi di applicazioni riutilizzabili come unità di distribuzione componendoli da elementi presenti nel diagramma applicazioni. È inoltre possibile progettare sistemi più grandi e complessi contenenti altri sistemi in modo da utilizzarli in scenari di sistemi distribuiti ed estrarre i dettagli delle applicazioni in tali sistemi. Archiviare ogni nuovo file diagramma nel controllo della versione.

È possibile rappresentare diagrammi sistema in Visual Studio nei modi seguenti:

• Diagrammi casi di utilizzo. Gli scenari utente principali vengono rappresentati come casi di utilizzo e i componenti principali del sistema vengono visualizzati come sottosistemi. È possibile inserire ogni caso di utilizzo nel sottosistema che lo gestisce. Per ulteriori informazioni, vedere Diagrammi casi di utilizzo UML: linee guida.

• Diagrammi componente UML. Questi diagrammi consentono di mostrare i canali di comunicazione tra i componenti, nonché le dipendenze. Potrebbe inoltre essere necessario creare diagrammi classi per descrivere i tipi visibili nelle interfacce ai componenti ed è possibile creare diagrammi di sequenza per indicarne le interazioni. Per ulteriori informazioni, vedere Diagrammi dei componenti UML: linee guida, Diagrammi classi UML: linee guida e Diagrammi di sequenza UML: linee guida.

• Diagrammi livello. In un diagramma livello viene descritta la struttura dei blocchi dell'applicazione. Vengono mostrati solo i componenti e le relative dipendenze. Il vantaggio di questo diagramma consiste nel fatto di consentire, dopo la scrittura del codice, la convalida del codice e delle dipendenze rispetto al diagramma. Per ulteriori informazioni, vedere Diagrammi livello: linee guida.

Per ogni sottosistema, è possibile creare un pacchetto che ne descrive i tipi e il comportamento in modo più dettagliato. Per ulteriori informazioni, vedere Definizione di pacchetti e spazi dei nomi.

Creare modelli di prova

È possibile ridurre rischi significativi per il progetto creando un modello di prova architetturale. È importante gestire i rischi quanto prima possibile nel progetto in modo da adottare decisioni strategiche e architetturali chiave quando è ancora possibile modificare agevolmente parti fondamentali dell'architettura. La creazione di modelli di prova iniziali riduce i rischi complessivi e gli imprevisti del progetto. Rischi e imprevisti minori rendono più accurate la pianificazione e la stima nelle iterazioni successive. I modelli di prova possono essere temporanei e venire ignorati dopo la risoluzione dei problemi oppure possono essere compilati come elementi fondanti dell'architettura di base.

Esaminare i rischi

Individuare gli elementi che conducono all'identificazione dei rischi o delle decisioni architetturali. Esaminare gli scenari correlati e i requisiti di qualità del servizio. Verificare qualsiasi implicazione dell'ambiente di destinazione.

Pianificare l'approccio

Determinare il formato del modello di prova necessario. Utilizzare i diagrammi applicazioni e i diagrammi sistema per semplificare la pianificazione. Risolvere solo il problema architetturale identificato dal rischio. Cercare la risoluzione più semplice.

Compilare ed eseguire il modello di prova

Compilare il modello di prova. È possibile implementare il modello di prova dal diagramma applicazioni. Concentrare l'attenzione sul problema da risolvere. Distribuire il modello di prova in un ambiente fisico congruente con il diagramma centro dati logico. L'ambiente fisico deve corrispondere quanto più possibile alle impostazioni del diagramma centro dati logico. Testare il modello di prova rispetto ai problemi ad alto rischio.

Valutare le alternative

Il metodo LAAAM (Lightweight Architecture Alternative Analysis Method) semplifica l'adozione della decisione tra diverse strategie architetturali per la compilazione di un'applicazione. Il completamento del metodo LAAAM richiede in genere un giorno. Iniziare compilando una struttura ad albero dell'utilità in cui vengono descritti i fattori chiave responsabili di qualità e funzioni dell'applicazione basati sui requisiti. Ognuno di questi aspetti determinanti viene scritto come scenario sotto forma di un'istruzione scritta come contesto, stimolo e risposta. Utilizzare una matrice di valutazione per valutare il modo in cui ogni strategia gestisce ciascuno scenario.

Creare una struttura ad albero dell'utilità

Esaminare i requisiti di qualità del servizio e i requisiti del prodotto per determinare i fattori chiave responsabili di qualità e funzione nell'applicazione. Costruire una struttura ad albero dell'utilità per rappresentare la qualità complessiva dell'applicazione. Il nodo radice nella struttura ad albero è identificato come Utilità. I nodi successivi sono in genere identificati in termini di qualità standard, quali modificabilità, disponibilità e sicurezza. La struttura ad albero deve rappresentare la natura gerarchica delle qualità e deve fornire una base per la classificazione in ordine di priorità. Ciascun livello nella struttura ad albero rappresenta un'ulteriore perfezionamento delle qualità. Queste qualità diventano infine scenari.

Costruire una matrice di valutazione

Per ogni foglia nella struttura ad albero dell'utilità, scrivere uno scenario. Lo scenario viene definito sotto forma di contesto, stimolo e risposta, ad esempio: "A fronte di un funzionamento tipico, eseguire una transazione del database in meno di 100 millisecondi".

Creare un foglio di calcolo o una tabella e immettere ogni scenario come riga in questa matrice di valutazione. Immettere ogni strategia architetturale come colonna. A ogni intersezione di strategie e scenari, immettere una classificazione su una scala da 1 a 4.

La classificazione deve prendere in considerazione i fattori seguenti:

• Costo di sviluppo Si tratta di una soluzione facile o difficile da implementare? Qual è l'impatto su altre aree?

• Costi operativi In fase di esecuzione questa soluzione funzionerà facilmente o influirà negativamente su usabilità, prestazioni e così via?

• Rischi È sicuro che questa soluzione gestisca in modo appropriato lo scenario oppure interverranno costi sconosciuti? Questa soluzione può avere un impatto negativo sulla capacità del team di adattare miglioramenti futuri ai requisiti?

Se è stato compilato un modello di prova per una strategia, utilizzare le informazioni ottenute da tale modello di prova per determinare i valori.

Nella parte inferiore della tabella sommare i valori ottenuti dagli scenari. Utilizzare queste cifre come input per la discussione che determinerà le decisioni da adottare sulle architetture alternative.

Caricare la matrice di valutazione completata nel portale del progetto.

Selezionare l'architettura

Al termine della creazione della matrice di valutazione, viene tenuta una riunione di revisione per determinare l'architettura da utilizzare nell'iterazione successiva. La matrice di valutazione e le informazioni individuate dalla creazione dei modelli di prova vengono utilizzate per semplificare l'adozione di una decisione. Dopo aver selezionato l'architettura, i diagrammi per l'architettura vengono archiviati come soluzione di riferimento e viene creato un documento giustificativo in cui vengono definiti i motivi alla base della selezione.

Preparare la revisione

L'architetto e il responsabile dello sviluppo identificano i revisori appropriati per la revisione delle architetture proposte e distribuiscono a ogni partecipante la documentazione per le architetture.

Rivedere l'architettura del sistema e l'architettura di distribuzione

Durante la riunione di revisione, vengono rivisti i diagrammi sistema, il rapporto di distribuzione e il diagramma centro dati logico. L'obiettivo consiste nello scegliere un'architettura da implementare nell'iterazione successiva.

Considerare le classificazioni della matrice di valutazione per le architetture per semplificare la valutazione dell'idoneità di ogni architettura. Considerare tutte le informazioni individuate dai modelli di prova, quali costi o complessità correlati all'implementazione delle diverse architetture. Se il diagramma centro dati logico rappresenta un centro dati logico esistente che non può essere modificato, non rivederlo. Se viene creato un centro dati logico, rivedere il diagramma per definire le considerazioni sulla distribuzione. Selezionare l'architettura da utilizzare. Esaminare il concetto architetturale rispetto agli scenari per verificare che la soluzione soddisfi le esigenze del cliente e sia completa.

Creare una soluzione di riferimento

Creare un documento giustificativo in cui sono incluse le decisioni adottate durante la riunione. Caricare il documento nel portale del progetto. Per l'architettura selezionata, archiviare tutti i diagrammi applicazioni, sistema o centro dati logico come soluzione di riferimento da utilizzare per l'implementazione di funzionalità nell'iterazione successiva. Comunicare a tutto il team e a tutti i team dipendenti la decisione sull'architettura selezionata per l'iterazione successiva.

Sviluppare un modello di prestazioni

La modellazione delle prestazioni consente di identificare e risolvere possibili problemi di prestazioni nell'applicazione. Un modello di prestazioni viene sviluppato da un requisito di qualità del servizio e viene quindi suddiviso in attività di sviluppo. A ogni attività di sviluppo è assegnato un budget delle prestazioni per l'implementazione.

Identificare gli scenari collegati al requisito di qualità delle prestazioni del servizio. Associare le attività di sviluppo agli scenari. Dall'elenco dei requisiti di qualità del servizio determinare il carico di lavoro per l'applicazione. Utilizzando le stime del carico di lavoro e l'elenco dei requisiti di qualità del servizio, identificare gli obiettivi relativi alle prestazioni per ogni scenario principale. Tali obiettivi includono tempi di risposta, velocità effettiva e utilizzo delle risorse. Identificare le risorse correlate alle prestazioni che sono state inserite nel budget per soddisfare gli obiettivi relativi alle prestazioni. Alcuni esempi di risorse correlate alle prestazioni sono i tempi di esecuzione e la larghezza di banda di rete. Determinare l'allocazione massima consentita di ogni risorsa.

Distribuire le risorse incluse nel budget tra i passaggi di elaborazione per ogni scenario. In caso di dubbi su come allocare il budget, adottare supposizioni affidabili o suddividere uniformemente le risorse tra i passaggi. La definizione del budget viene perfezionata durante la convalida. Allegare o scrivere l'allocazione nell'attività di sviluppo appropriata.

Individuare le allocazioni del budget che comportano un rischio per la realizzazione degli obiettivi relativi alle prestazioni. Considerare i compromessi che consentono di realizzare gli obiettivi relativi alle prestazioni, ad esempio le alternative di progettazione e distribuzione. Se necessario, valutare nuovamente i requisiti di qualità del servizio.

Identificare gli scenari che non soddisfano le allocazioni del budget. Misurare le prestazioni degli scenari. Utilizzare prototipi nelle iterazioni iniziali se il codice non è disponibile. Ripetere i passaggi di definizione del budget, valutazione e convalida in base alle esigenze utilizzando i dati acquisiti durante la convalida.

Sviluppare un modello di rischio

Per ulteriori informazioni, vedere la seguente pagina sul sito Web Microsoft: Security Developer Center.