Esporta (0) Stampa
Espandi tutto
Il presente articolo è stato tradotto manualmente. Passare il puntatore sulle frasi nell'articolo per visualizzare il testo originale. Ulteriori informazioni.
Traduzione
Originale

Generazione e configurazione dell'applicazione dai modelli

È possibile generare o configurare parti dell'applicazione da un modello. Il modello può essere in linguaggio UML o DSL.

Un modello consente di rappresentare i requisiti in modo più diretto rispetto al codice. Derivando il comportamento dell'applicazione direttamente dal modello, è possibile rispondere ai cambiamenti di requisiti con maggiore rapidità e affidabilità che non semplicemente aggiornando il codice. Anche se la configurazione della derivazione richiede un impegno iniziale, l'investimento di tempo risulta sicuramente proficuo quando i requisiti sono destinati a cambiare o si prevede di realizzare più varianti del prodotto.

Il modo più semplice per generare codice consiste nell'utilizzare modelli di testo. È possibile generare codice nella stessa soluzione di Visual Studio che contiene il modello. Per ulteriori informazioni, vedere:

Questo metodo può essere facilmente applicato in modo incrementale. Partire da un'applicazione che funziona solo per un caso specifico e sceglierne alcune parti da variare rispetto al modello. Rinominare i file di origine di queste parti in modo che diventino file modello di testo (con estensione tt). A questo punto, i file cs di origine verranno automaticamente generati dai file modello e l'applicazione funzionerà nel modo consueto.

Quindi, sarà possibile sostituire una parte del codice con un'espressione del modello di testo che legge il modello e genera la parte sostituita del file di origine. Affinché sia l'applicazione possa essere rieseguita e funzioni come di consueto, è necessario che almeno un valore del modello generi il codice sorgente originale. Dopo avere testato valori del modello differenti, è possibile continuare a inserire espressioni del modello in un'altra parte del codice.

Grazie a questo metodo incrementale, la generazione di codice risulta generalmente un approccio a basso rischio. Il livello di prestazioni garantito dalle applicazioni risultanti è in genere pressoché simile a quello della versione scritta manualmente.

Tuttavia, se si parte da un'applicazione esistente, potrebbe rendersi necessaria un'attività di refactoring non indifferente per separare i diversi comportamenti regolati dal modello in modo che possano essere variati in modo indipendente. Si consiglia di valutare questo aspetto dell'applicazione quando si effettua una stima del costo del progetto.

Se si desidera variare il comportamento dell'applicazione in fase di esecuzione, non è possibile utilizzare la generazione di codice, in quanto genera il codice sorgente prima che venga compilata l'applicazione. Al contrario, è possibile progettare l'applicazione in modo che legga il modello UML o DSL e che il comportamento vari di conseguenza. Per ulteriori informazioni, vedere:

Questo metodo può anche essere applicato in modo incrementale, ma ciò comporta maggiore impegno nelle fasi iniziali. Sarà infatti necessario scrivere il codice che leggerà il modello e configurare un framework che ne renda i valori accessibili alle parti variabili. La generalizzazione delle parti variabili è un approccio più dispendioso rispetto alla generazione di codice.

Il livello di prestazioni garantito da un'applicazione generica è solitamente inferiore a quello delle controparti specifiche. Se le prestazioni sono cruciali, è opportuno che il piano del progetto includa una valutazione di questo rischio.

Per lo sviluppo di un'applicazione derivata potranno rivelarsi utili le linee guida descritte di seguito.

  • Iniziare con un approccio specifico e, in seguito, generalizzare. Scrivere prima una versione specifica dell'applicazione. Questa versione dovrebbe funzionare in un set di condizioni specifico. Una volta soddisfatti del corretto funzionamento dell'applicazione, sarà possibile derivarne una parte da un modello. Estendere gradualmente le parti derivate.

    Ad esempio, progettare un sito Web che dispone di un set specifico di pagine Web prima di progettare un'applicazione Web che presenta pagine definite in un modello.

  • Modellare gli aspetti variabili. Identificare gli aspetti che varieranno tra una distribuzione e l'altra o nel tempo con il mutare dei requisiti. Questi sono gli aspetti che devono essere derivati da un modello.

    Ad esempio, se il set di pagine Web e dei relativi collegamenti cambia, ma lo stile e il formato delle pagine rimangono gli stessi, sarà necessario che il modello descriva i collegamenti, ma non il formato delle pagine.

  • Separare le problematiche. Se gli aspetti variabili possono essere suddivisi in aree indipendenti, utilizzare modelli separati per ogni area. Utilizzando ModelBus, è possibile definire operazioni che influiscono su entrambi modelli e i vincoli reciproci.

    Ad esempio, utilizzare un modello per definire la navigazione delle pagine Web e un modello differente per definire il layout delle pagine. Per ulteriori informazioni, vedere Procedura: integrare i modelli UML con altri modelli e strumenti.

  • Modellare il requisito, non la soluzione. Progettare il modello DSL o adattare il modello UML in modo che descriva i requisiti dell'utente. Non progettare invece la notazione in base agli aspetti variabili dell'implementazione.

    Ad esempio, il modello della navigazione Web deve rappresentare le pagine Web e i reciproci collegamenti ipertestuali. Il modello della navigazione Web non deve rappresentare frammenti di HTML o classi dell'applicazione.

  • Scegliere tra generazione e interpretazione. Se i requisiti per una particolare distribuzione sono destinati a cambiare di rado, generare il codice programma dal modello. Se è possibile che i requisiti cambino di frequente o che ne coesistano più varianti nella stessa distribuzione, scrivere l'applicazione in modo che possa leggere e interpretare un modello.

    Ad esempio, se si utilizza il modello del sito Web per sviluppare una serie di siti Web differenti e installati separatamente, sarà necessario generare il codice del sito dal modello. Se, invece, si utilizza il modello per controllare un sito che cambia quotidianamente, sarà preferibile scrivere un server Web che legga il modello e che presenti il sito conformemente a tale modello.

  • Scegliere tra UML e DSL. Creare la notazione dei modelli tramite stereotipi per estendere UML. Definire un modello DSL se non si dispone di un diagramma UML appropriato. Evitare tuttavia di alterare la semantica standard di UML.

    Ad esempio, un diagramma classi UML è una raccolta di caselle e di frecce; con questa notazione si può, teoricamente, definire qualsiasi elemento. L'utilizzo del diagramma classi è tuttavia consigliato solo quando si descrive un set di tipi. Ad esempio, è possibile adattare diagrammi classi per descrivere tipi differenti di pagine Web.

Aggiunte alla community

AGGIUNGI
Mostra:
© 2014 Microsoft