Génération et configuration de votre application à partir de modèles
Vous pouvez générer ou configurer certaines parties de votre application à partir d'un modèle. Le modèle peut être en langage UML ou DSL.
Le modèle représente les spécifications plus directement que le code. En faisant dériver le comportement de l'application directement du modèle, vous pouvez répondre à la modification des spécifications beaucoup plus rapidement et de manière plus fiable que si vous deviez mettre à jour le code. Bien qu'un certain travail préalable de configuration de la dérivation soit nécessaire, il s'agit d'un bon investissement de temps si vous prévoyez la modification des spécifications ou si vous projetez de créer plusieurs variantes d'un même produit.
Génération du code de votre application à partir d'un modèle
La façon la plus facile de générer du code est d'utiliser des modèles de texte. Vous pouvez générer du code dans la même solution Visual Studio que celle dans laquelle vous conservez le modèle. Pour plus d'informations, consultez :
Génération de code durant la conception à l'aide de modèles de texte T4
Génération de code à partir d'un langage spécifique à un domaine
Cette méthode est facile à appliquer de façon incrémentielle. Commencez par une application qui fonctionne uniquement dans un cas spécifique, puis choisissez certaines parties de cette application en vue de créer des variantes à partir d'un modèle. Renommez les fichiers sources de ces parties de l'application, afin de les convertir en fichiers de modèle de texte (.tt). À ce stade, les fichiers sources .cs seront générés automatiquement à partir des fichiers modèles et l'application fonctionnera comme auparavant.
Ensuite, vous pouvez prendre une partie du code et la remplacer par une expression de modèle de texte, qui lira le modèle et génèrera cette partie du fichier source. Au moins l'une des valeurs du modèle doit générer la source d'origine pour qu'une fois encore, l'application puisse fonctionner comme auparavant. Après avoir testé différentes valeurs de modèle, poursuivez en insérant des expressions de modèle dans une autre partie du code.
Avec cette méthode incrémentielle, la génération de code constitue habituellement une approche peu risquée. Les applications qui en résultent sont en général aussi efficaces que leur version écrite manuellement.
Toutefois, si vous utilisez une application existante, vous pouvez trouver qu'un important travail de refactorisation est nécessaire pour séparer les différents comportements gouvernés par le modèle, afin que les variantes puissent être créées indépendamment. Nous vous recommandons d'évaluer cet aspect de l'application au moment d'estimer le coût de votre projet.
Configuration de votre application à partir d'un modèle
Si vous souhaitez varier le comportement de votre application au moment de l'exécution, vous ne pouvez pas utiliser la génération de code, car cela génère du code source avant que l'application ne soit compilée. Concevez plutôt votre application de façon à lire le modèle UML ou DSL, puis à varier son comportement en conséquence. Pour plus d'informations, consultez :
Cette méthode peut également être appliquée de façon incrémentielle, mais cela requiert un travail préalable plus important. Vous devez écrire le code qui devra lire le modèle, puis configurer une infrastructure qui permette à ses valeurs d'être accessibles aux parties variables. Le fait de rendre les parties variables génériques se révèle plus coûteux que de générer du code.
Une application générique est habituellement moins efficace que ses équivalents spécifiques. Si les performances constituent un point crucial, votre plan de projet doit inclure une évaluation de ce risque.
Développement d'une application dérivée
Les instructions générales suivantes pourront vous être utiles.
Commencez par être spécifique, ensuite généralisez. Écrivez d'abord une version spécifique de votre application. Cette version doit fonctionner sous un ensemble de conditions. Lorsque vous êtes satisfait de son fonctionnement, vous pouvez faire dériver certaines parties de l'application à partir d'un modèle. Étendez progressivement les parties dérivées.
Par exemple, concevez un site Web composé d'un ensemble spécifique de pages Web avant de concevoir une application Web qui présente des pages définies dans un modèle.
Modélisez les variantes. Identifiez les parties qui devront varier, à l'occasion d'un nouveau déploiement ou dans le cadre d'une modification des spécifications. Il s'agit des parties qui devront dériver d'un modèle.
Par exemple, si l'ensemble des pages Web, ainsi que les liens hypertexte qui les lient les unes aux autres, viennent à changer, mais que le style et le format des pages restent le même, le modèle doit décrire ces liens, mais n'a pas besoin de décrire le format des pages.
Divisez les problèmes. Si les parties variables peuvent être divisées en zones indépendantes, utilisez un modèle différent pour chaque zone. À l'aide de ModelBus, définissez des opérations qui affectent les deux modèles, ainsi que leurs contraintes.
Utilisez, par exemple, un modèle pour définir la navigation entre pages Web et un autre modèle pour définir la mise en page. Pour plus d'informations, consultez Comment : intégrer des modèles UML à d'autres modèles et outils.
Modélisez les spécifications, pas la solution. Concevez du code DSL ou adaptez du code UML afin qu'il décrive les besoins des utilisateurs. Par contre, ne concevez pas la notation en fonction des parties variables de l'implémentation.
Par exemple, le modèle de navigation Web doit représenter des pages Web et les liens hypertexte qui lient ces dernières entre elles. Le modèle de navigation Web ne doit pas représenter des fragments de HTML ou de classes de votre application.
Générer ou interpréter ? Si les spécifications d'un déploiement particulier ne seront amenées à changer que rarement, générez le code du programme à partir d'un modèle. Si les spécifications seront amenées à changer fréquemment ou à co-exister dans plusieurs variantes lors d'un même déploiement, écrivez l'application de façon à ce qu'elle puisse lire et interpréter un modèle.
Par exemple, si vous utilisez votre modèle de site Web pour développer une série de sites Web différents et installés séparément, vous devez générer le code du site à partir d'un modèle. Mais si vous utilisez votre modèle pour contrôler un site qui doit changer tous les jours, il vaut mieux écrire un serveur Web qui lira le modèle et présentera le site en conséquence.
UML ou DSL ? Envisagez de créer votre notation de modélisation à l'aide de stéréotypes permettant d'étendre du code UML. Définissez un diagramme DSL si aucun diagramme UML ne répond à vos besoins. Mais veillez à respecter la sémantique standard UML.
Par exemple, un diagramme de classes UML est une collection de zones et de flèches. Grâce à cette notation, vous pouvez, en théorie, tout définir. Cependant, nous vous recommandons de ne pas utiliser de diagrammes de classes, sauf lorsque vous devez décrire un ensemble de types. Vous pouvez, par exemple, adapter des diagrammes de classes pour décrire différents types de pages Web.
Voir aussi
Concepts
Comment : générer des fichiers à partir d'un modèle UML
Comment : lire un modèle UML dans le code de programme
Comment : ouvrir un modèle depuis un fichier dans le code de programme
Génération de code durant la conception à l'aide de modèles de texte T4
Autres ressources
Génération de code à partir d'un langage spécifique à un domaine