Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Vous pouvez générer ou configurer des parties de votre application à partir d’un modèle.
Le modèle représente les exigences plus directement que le code. En dérivant le comportement de l’application directement à partir du modèle, vous pouvez répondre aux exigences modifiées beaucoup plus rapidement et de manière fiable qu’en mettant à jour le code. Bien que certains travaux initiaux soient nécessaires pour configurer la dérivation, cet investissement est retourné si vous attendez des changements dans les exigences, ou si vous envisagez d’effectuer plusieurs variantes du produit.
Génération du code de votre application à partir d’un modèle
Le moyen le plus simple de générer du code consiste à utiliser des modèles de texte. Vous pouvez générer du code dans la même solution Visual Studio dans laquelle vous conservez le modèle. Pour plus d’informations, consultez :
Génération de code pendant la conception en utilisant des modèles de texte T4
Génération de code à partir d’un langage Domain-Specific
Cette méthode est facile à appliquer de manière incrémentielle. Commencez par une application qui fonctionne uniquement pour un cas spécifique, puis choisissez quelques parties de celle-ci que vous souhaitez varier du modèle. Renommez les fichiers sources de ces parties afin qu’ils deviennent des fichiers de modèle de texte (.tt). À ce stade, les fichiers source .cs seront automatiquement générés à partir des fichiers modèles, pour que l’application fonctionne comme auparavant.
Vous pouvez ensuite prendre une partie du code et le remplacer par une expression de modèle de texte, qui lit le modèle et génère cette partie du fichier source. Au moins une valeur du modèle doit générer la source d’origine afin que vous puissiez à nouveau exécuter l’application et qu’elle fonctionnera comme avant. Après avoir testé différentes valeurs de modèle, vous pouvez passer à l’insertion d’expressions de modèle dans une autre partie du code.
Cette méthode incrémentielle signifie que la génération de code est généralement une approche à faible risque. Les applications résultantes effectuent généralement presque aussi bien qu’une version écrite manuellement.
Toutefois, si vous commencez par une application existante, vous pouvez constater qu’un grand nombre de refactorisations est nécessaire pour séparer les différents comportements régis par le modèle afin qu’ils puissent être variés indépendamment. Nous vous recommandons d’évaluer cet aspect de l’application lorsque vous estimez le coût de votre projet.
Configuration de votre application à partir d’un modèle
Si vous souhaitez modifier le comportement de votre application au moment de l’exécution, vous ne pouvez pas utiliser la génération de code, qui génère du code source avant la compilation de l’application. Au lieu de cela, vous pouvez concevoir votre application pour lire le modèle et modifier son comportement en conséquence. Pour plus d’informations, consultez :
Guide pratique pour ouvrir un modèle à partir d’un fichier dans le code du programme
Cette méthode peut également être appliquée de manière incrémentielle, mais il y a plus de travail au début. Vous devez écrire le code qui lit le modèle et configurer une infrastructure qui permet à ses valeurs d’être accessibles aux parties variables. La création des composants variables génériques est plus coûteuse que la génération de code.
Une application générique fonctionne généralement moins bien que ses équivalents spécifiques. Si les performances sont cruciales, votre plan de projet doit inclure une évaluation de ce risque.
Développement d’une application dérivée
Vous trouverez peut-être les instructions générales suivantes utiles.
Démarrez spécifique, puis généralisez. Écrivez d’abord une version spécifique de votre application. Cette version doit fonctionner dans un ensemble de conditions. Lorsque vous êtes satisfait qu’il fonctionne correctement, vous pouvez en faire une partie dérivée d’un modèle. Étendez progressivement les parties dérivées.
Par exemple, concevez un site web qui a 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 aspects des variantes. Identifiez les aspects qui varient entre un déploiement et un autre, ou au fil du temps à mesure que les exigences changent. Il s’agit des aspects qui doivent être dérivés d’un modèle.
Par exemple, si l’ensemble de pages web et de liens entre eux change, mais que le style et le format des pages sont toujours identiques, le modèle doit décrire les liens, mais n’a pas à décrire le format des pages.
Préoccupations distinctes. Si les aspects variables peuvent être divisés en zones indépendantes, utilisez des modèles distincts pour chaque zone. À l’aide de ModelBus, vous pouvez définir des opérations qui affectent les deux modèles et les contraintes entre eux.
Par exemple, utilisez un modèle pour définir la navigation entre les pages web et un autre modèle pour définir la disposition des pages.
Modélisez l’exigence, et non la solution. Concevez le modèle afin qu’il décrit les exigences de l’utilisateur. En revanche, ne concevez pas la notation en fonction des aspects variables de l’implémentation.
Par exemple, le modèle de navigation web doit représenter des pages web et des liens hypertexte entre eux. Le modèle de navigation web ne doit pas représenter des fragments de html ou de classes dans votre application.
Générer ou interpréter ? Si les exigences d’un déploiement particulier changent rarement, générez du code de programme à partir du modèle. Si les exigences peuvent fréquemment changer ou coexister dans plusieurs variantes du même déploiement, écrivez l’application afin 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 du modèle. Toutefois, vous utilisez votre modèle pour contrôler un site qui change chaque jour, puis il est préférable d’écrire un serveur web qui lit le modèle et présente le site en conséquence.
UML ou DSL ? Envisagez de créer votre notation de modélisation à l’aide de stéréotypes pour étendre UML. Définissez une DSL s’il n’existe aucun diagramme UML qui correspond à l’objectif. Mais évitez de briser la sémantique standard de UML.
Par exemple, un diagramme de classes UML est une collection de zones et de flèches ; avec cette notation, vous pouvez en théorie définir quoi que ce soit. Mais nous vous déconseillons d’utiliser le diagramme de classes, sauf si vous décrivez en fait un ensemble de types. Par exemple, vous pouvez adapter des diagrammes de classes pour décrire différents types de pages web.