Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
È possibile generare o configurare parti dell'applicazione da un modello.
Il modello rappresenta i requisiti più direttamente rispetto al codice. Derivando il comportamento dell'applicazione direttamente dal modello, è possibile rispondere ai requisiti modificati in modo molto più rapido e affidabile rispetto all'aggiornamento del codice. Anche se alcuni lavori iniziali sono necessari per configurare la derivazione, questo investimento viene restituito se si prevede di modificare i requisiti o se si prevede di apportare diverse varianti del prodotto.
Generazione del codice dell'applicazione da un modello
Il modo più semplice per generare codice consiste nell'usare modelli di testo. È possibile generare codice nella stessa soluzione di Visual Studio in cui si mantiene il modello. Per altre informazioni, vedere:
Generazione di codice in fase di progettazione usando modelli di testo T4
Generazione di codice da un linguaggio di Domain-Specific
Questo metodo è facile da applicare in modo incrementale. Iniziare con un'applicazione che funziona solo per un caso specifico e scegliere alcune parti dell'applicazione che si vogliono variare rispetto al modello. Rinominare i file di origine di queste parti in modo che diventino file di modello di testo (con estensione tt). A questo punto, i file di origine .cs verranno generati automaticamente dai file modello, quindi l'applicazione funzionerà come in precedenza.
È quindi possibile prendere una parte del codice e sostituirla con un'espressione modello di testo, che legge il modello e genera tale parte del file di origine. Almeno un valore del modello deve generare l'origine originale in modo che sia possibile eseguire di nuovo l'applicazione e funzioni come prima. Dopo aver testato valori di modello diversi, è possibile passare all'inserimento di espressioni modello in un'altra parte del codice.
Questo metodo incrementale indica che la generazione del codice è in genere un approccio a basso rischio. Le applicazioni risultanti in genere eseguono quasi tutte le versioni scritte a mano.
Tuttavia, se si inizia con un'applicazione esistente, si potrebbe notare che è necessario eseguire un notevole refactoring per separare i diversi comportamenti regolati dal modello in modo che possano essere variati in modo indipendente. È consigliabile valutare questo aspetto dell'applicazione quando si stima il costo del progetto.
Configurazione dell'applicazione da un modello
Se si vuole variare il comportamento dell'applicazione in fase di esecuzione, non è possibile usare la generazione di codice, che genera il codice sorgente prima che l'applicazione venga compilata. È invece possibile progettare l'applicazione per leggere il modello e variarne il comportamento di conseguenza. Per altre informazioni, vedere:
Procedura: Aprire un modello da un file nel codice del programma
Questo metodo può essere applicato anche in modo incrementale, ma richiede più lavoro all'inizio. È necessario scrivere il codice che leggerà il modello e configurare un framework che consenta l'accessibilità dei relativi valori alle parti delle variabili. Rendere generico le parti variabili è più costoso rispetto alla generazione di codice.
Un'applicazione generica in genere offre prestazioni inferiori rispetto alle controparti specifiche. Se le prestazioni sono fondamentali, il piano di progetto deve includere una valutazione di questo rischio.
Sviluppo di un'applicazione derivata
È possibile trovare le linee guida generali seguenti utili.
Inizia specifico, poi generalizza. Scrivere prima una versione specifica dell'applicazione. Questa versione dovrebbe funzionare in un set di condizioni. Quando si è soddisfatti che il sistema funzioni correttamente, è possibile farne derivare alcuni elementi da un modello. Estendere gradualmente le parti derivate.
Ad esempio, progettare un sito Web con un set specifico di pagine Web prima di progettare un'applicazione Web che presenta pagine definite in un modello.
Modellare gli aspetti della variante. Identificare gli aspetti che variano, tra una distribuzione e un'altra, o nel corso del tempo quando i requisiti cambiano. Questi sono gli aspetti che devono essere derivati da un modello.
Ad esempio, se il set di pagine Web e i collegamenti tra di essi cambia, ma lo stile e il formato delle pagine sono sempre uguali, il modello deve descrivere i collegamenti, ma non deve descrivere il formato delle pagine.
Problemi separati. Se gli aspetti delle variabili possono essere suddivisi in aree indipendenti, usare modelli separati per ogni area. Usando ModelBus, è possibile definire operazioni che influiscono su entrambi i modelli e sui vincoli tra di essi.
Ad esempio, usare un modello per definire lo spostamento tra le pagine Web e un modello diverso per definire il layout delle pagine.
Modellare il requisito, non la soluzione. Progettare il modello in modo che descriva i requisiti utente. Al contrario, non progettare la notazione in base agli aspetti variabili dell'implementazione.
Ad esempio, il modello di spostamento Web deve rappresentare pagine Web e collegamenti ipertestuali tra di essi. Il modello di spostamento Web non deve rappresentare frammenti di classi o HTML nell'applicazione.
Generare o interpretare? Se i requisiti per una particolare distribuzione cambieranno raramente, generare codice del programma dal modello. Se i requisiti possono cambiare frequentemente o potrebbero coesistere in più varianti nella stessa distribuzione, scrivere l'applicazione in modo che possa leggere e interpretare un modello.
Ad esempio, se si usa il modello di sito Web per sviluppare una serie di siti Web diversi e installati separatamente, è necessario generare il codice del sito dal modello. Ma si usa il modello per controllare un sito che cambia ogni giorno, quindi è preferibile scrivere un server Web che legge il modello e presenta il sito di conseguenza.
UML o DSL? Valutare la possibilità di creare la notazione di modellazione usando stereotipi per estendere UML. Definire un linguaggio DSL se non esiste un diagramma UML adatto allo scopo. Ma evitare di interrompere la semantica standard di UML.
Ad esempio, un diagramma classi UML è una raccolta di caselle e frecce; con questa notazione si può in teoria definire qualsiasi cosa. Non è tuttavia consigliabile usare il diagramma classi, ad eccezione del punto in cui si descrive effettivamente un set di tipi. Ad esempio, è possibile adattare diagrammi classi per descrivere diversi tipi di pagine Web.