Une gestion efficace des versions et de la configuration est toujours très importante dans les projets de développement logiciel.
1. Le concept de versionnage
Dans un projet MDSD, les aspects suivants doivent être gérés et versionnés :
- Générez des outils. Actuellement, les outils eux-mêmes sont encore en cours de développement, il est donc logique de les contrôler en version.
- Configuration du générateur : partie générée de l'architecture de domaine, elle comprend les définitions de fichiers DSL/configuration, les métamodèles, les modèles et les transformations.
- La partie non générée de l'architecture du domaine : la plateforme MDSD.
- L'application elle-même : modèles, spécifications et code développé manuellement.
Idéalement, le code généré n'est pas versionné, car il peut être reproduit à partir du modèle à tout moment et ne constitue donc pas le code source réel du programme. Bien entendu, cette idée ne peut être appliquée de manière réaliste que s’il existe une séparation structurelle entre le code créé à la main et le code généré dans le système de fichiers.
L'un des objectifs du développement piloté par modèle est de développer des applications basées sur la même architecture de domaine. Par conséquent, il est nécessaire de séparer complètement la configuration de la plateforme et du générateur de l’application.
2. Projets et dépendances
L'accent est mis sur la gestion des dépendances de divers projets, y compris leurs versions. Pour les projets d’application, il est nécessaire de préciser sur quelle version de l’architecture de domaine est basé le projet. Si la plate-forme sous-jacente s'améliore, l'architecture du domaine et éventuellement même le projet d'application devront peut-être être améliorés en même temps. Une métaphore du framework peut être utilisée pour démontrer cela : imaginez l'architecture du domaine comme un framework. Si vous améliorez le framework, vous devez modifier son application client. Ces éléments sont de la même pertinence, c'est pourquoi la même approche est appliquée à l'amélioration de l'architecture du domaine.
3. La structure du projet de candidature
Projets, artefacts et référentiels
Le diagramme ci-dessus montre comment un projet d'application est configuré au plus haut niveau et comment le générateur et le compilateur l'utilisent.
Le modèle de l'application, ainsi que le code créé manuellement, résident dans le référentiel de l'application. Les générateurs créent du code généré soutenu par les configurations du générateur, y compris les fichiers de configuration, etc. Les fichiers de configuration se trouvent dans le référentiel d'architecture de domaine. Ensuite, l'application est générée à l'aide d'un script de construction. Cette étape utilisera le code artisanal de l'application et de la plateforme, en obtenant le code artisanal de la plateforme à partir du référentiel d'architecture de domaine.
4. Gestion des versions et processus de construction de fichiers mixtes
Il n'est pas toujours possible ou pratique de séparer complètement le code généré et non généré. Voici des exemples pertinents :
- Code personnalisé dans le descripteur de déploiement J2EE ;
- Code personnalisé dans les fichiers JSP ;
- Code personnalisé dans les fichiers de propriétés ou autres fichiers de configuration.
En général, ce sont des endroits où la langue cible ne fournit pas un mécanisme de délégation adéquat.
Bien évidemment, l'utilisation de cette zone protégée aboutit à un fichier dans lequel se mélangent du code généré et du code non généré. Le problème ici est que ces fichiers ne sont généralement versionnables que dans leur ensemble. Cela conduit au fait que le code redondant sera enregistré, puisque le code généré n'est finalement pas la source - la source sera le modèle à partir duquel le code est généré.
Ce code redondant peut entraîner des incohérences lors du développement de l'équipe. Cette incohérence deviendra un problème croissant à mesure que l’équipe évoluera.
Les conflits de fusion entre développeurs sont détectés exclusivement à l'aide des sources d'application du référentiel.
Il convient de souligner à nouveau que, à notre avis, la séparation entre le code généré et non généré est l'approche préférable et doit être tentée dans tous les cas.
5. Modélisation en équipe et versioning de certains modèles
Les grands systèmes doivent être partitionnés. Leurs éléments constitutifs ou sous-systèmes se développent plus ou moins indépendamment les uns des autres. Les interfaces définissent la manière dont le système va interagir. L’étape normale d’intégration consiste à rassembler les pièces. Cette approche est particulièrement utile si les pièces sont développées dans différents endroits ou par différentes équipes. Bien entendu, cela affecte principalement le processus de développement et la communication au sein de l’équipe, et peut-être également l’architecture du système.
1. Partitions et sous-domaines
Tout d'abord, il est important de souligner la différence entre le partitionnement et l'utilisation d'un sous-domaine.
Les sous-domaines sont des aspects qui isolent l'ensemble du système. Chaque sous-domaine possède son propre métamodèle et son propre DSL. Les différents métamodèles sont conceptuellement unifiés via la métaclasse de passerelle. Dans le contexte des systèmes d'entreprise, il peut s'agir de processus métier de sous-domaine, de persistance et d'interface graphique.
Au lieu de cela, les partitions décrivent la définition des parties du système. Pour des raisons d'organisation efficace ou de complexité du projet, décomposer un grand nombre d'exigences techniquement similaires en parties distinctes pouvant être intégrées à l'aide d'interfaces.
2. Diverses architectures logicielles générées
Si différentes architectures de build sont utilisées dans différentes partitions du projet, la question se pose de savoir si les artefacts générés fonctionneront ensemble. En général, cela signifie que l'intégration doit avoir lieu au niveau du code généré. À titre d'exemple, supposons que différentes versions de l'infrastructure de construction soient utilisées, qui créeront toutes des parties d'une application J2EE complète.
3. Développement du DSL
Les DSL continuent généralement d'être développés au cours d'un projet. Les DSL évolueront à mesure que la connaissance et la compréhension du domaine se développeront et s’approfondiront. Pour faciliter les choses, il faut s'assurer que le DSL conserve une rétrocompatibilité lors de son développement.
4. Partitionnement et intégration
Supposons que différentes équipes aient besoin de la même interface, peut-être parce qu'une équipe implémente un composant qui utilise le code d'une autre équipe.
Lorsque le travail à effectuer est piloté par un modèle, il est nécessaire d'appliquer un modèle avec des interfaces dans au moins deux des modèles. Toutefois, cette approche n’est pas idéale en raison des problèmes de cohérence liés à la duplication des informations dans les deux modèles. Selon l'outil, d'autres options existent.
1) Intégration dans le modèle
Si l'outil de modélisation le prend en charge, vous devez vous assurer que l'interface existe à un seul endroit et qu'elle est référencée à partir des deux modèles. Du point de vue du générateur, cela produira un modèle cohérent.
La possibilité de cette approche dépend de l’outil de modélisation. Parmi les outils UML, un outil basé sur un référentiel prenant en charge la modélisation discrète est le choix idéal.
2) Intégration via la synchronisation du modèle dans le générateur
L'intégration peut également se produire au niveau du générateur si l'outil de modélisation ne fournit pas un choix d'intégration approprié. Le générateur lit certains modèles d'entrée, chaque ligne contenant des éléments de modèle spécifiques.
Dans ce cas, la tâche du générateur est de résoudre d’éventuels problèmes de cohérence.
3) Intégration par référence dans le générateur
Une autre option d'intégration consiste à utiliser des références.