Asciidoctor

Suite a l'article d'hier [1],  on peut quand même se demander :Comment augmenter même un peu l’attractivité de la présentation?

En passant à Asciidoctor [2,3]!

Quoi un autre outil! non mais tu nous arnaques la, il va falloir tout refaire!

Non non ne vous inquiétez pas! Asciidoctor est un outil qui implémente (en ruby) tout le corpus de Asciidoc avec quelques petits trucs en plus.

Du coup oui il va falloir changer d’outil mais…. pas autant que vous le croyez [4]! n’oubliez pas ce dont nous parlions dans l'article précédent [1], comment rendre plus simple, plus attractive la rédaction documentaire dans le cadre d’un projet?

Et bien à l'instar d’un maven site [5] (qui est très très basique il faut l’avouer) on va également builder notre documentation technique avec Maven tout en restant (peu ou prou) compatible avec Asciidoc et sa simplicité (syntaxiquement parlant).

Avec Maven

Bien, on a déjà parlé de Maven [6] , et effectivement surtout dans le cadre de projet Java. Pourtant, si on prend un peu le point de vue du MDE/IDM, on peut considérer la documentation comme un modèle comme un autre de notre application alors si c'est un modèle, comme de l'UML ou même du code, pourquoi ne pas le compiler? Finalement il n'est qu une façon de voir une application ou un concept.

Ici on va rejoindre cette idée et nous allons définir un contexte de build maven pour faire notre documentation.

Des parents

Comme nous l'avions vu dans notre article sur Maven, on ne va pas partir bille en tête dans la simple définition d’un pom. On va se débrouiller pour augmenter la reutilisabilité. Du coup on va faire des pom parent!

On sait que asciidoc est naturellement fait pour produire des documents on va donc d’abord définir un parent permettant de construire ce type de doc, disons sous le format pdf puis par extension, on va tirer partie de ce premier pom pour l'étendre vers la production de présentations (il va de soit que le contenu sera le même, seul la forme change)

Pour faire ces deux pom parent, je citerai que je me suis beaucoup inspiré d’un fork d’un ami  sur github [7].

Ainsi le premier pom nommé tc-asciidoctor-pdf-parent va s’appuyer sur le plugin maven dédié à asciidoctor: asciidoctor-maven-plugin [8]. Il est complété par deux plugin asciidoctor que sont asciidoctorj-pdf [9] et asciidoctorj-diagram [10, 11] permettant de générer du pdf et de gérer des diagrammes au sein du document (comme UML, Graphviz, etc…) Pour en connaître un peu plus je vous invite à consulter le source du fichier sous github ici [12].

Le second pom nommé tc-asciidoctor-html-parent propose d'étendre le premier en spécialisant la génération documentaire au profit d’une interface html supportant la présentation. De façon à rendre celle ci plus dynamique, le pom va intégrer dynamiquement lors du build, une librairie Javascript revealjs [13] qui sera downloader via le plugin maven download-maven-plugin [14]. Ensuite, le plugin asciidoctor-maven-plugin va intégrer cette librairie pour construire la présentation en html. Pour en connaître un peu plus je vous invite à consulter le source du fichier sous github ici [15].

Utilisation

Il faut maintenant réintégrer les sources précédemment utilisées et les mettre dans un projet maven héritant du dernier pom présenté (tc-asciidoctor-html-parent)

On build :

mvn clean process-resources

et cela nous donne brutalement la présentation accessible ici [16].

Déjà c’est cool notre présentation à déjà bien évolué mais on voit que la compatibilité n’est pas présente à 100%.... le cadrage n’est pas parfait... Sachant cela, chacun verra midi à sa porte et choisira son approche préférée.

Conclusion

Nous n’avons pas été très loin dans l’utilisation de Asciidoc ni de Asciidoctor son équivalent, mais sont utilisation étant simple, il ne m'a pas semblé pertinent de s’attarder sur ce genre de problématique. Par contre son utilisation et les différents de logique de build existant entre les deux outils me semblait plus intéressant à montrer (sachant que Asciidoctor étant en ruby, via l’utilisation de l’installeur Ruby et de l’application Gem il est aussi possible de l’utiliser sans une industrialisation maven qui pourtant est, il me semble pertinente)

Voilà ainsi dans l’avenir, si je réalise une présentation en association avec un article, je procéderai comme pour le code source, je le déposerai dans le dépôt github du blog. Cela permettra de rendre plus dynamique les articles.

Pour ceux voulant aller un peu plus loin, les références suivantes sont pour vous: [17,18,19]

Remerciements (j’en fais pas souvent):

Merci à David et Christophe qui ont piqué ma curiosité avec asciidoc. Moi qui venait de Latex et de son formalisme jusqu’au boutiste, j’ai découvert un compromis et un outil fort pratique qui je pense va devenir un compagnon régulier de ma veille. (Il ne me reste qu'a tester la construction et l’intégration des diagrammes, mais on verra ça a la volée)

Références

[1] https://un-est-tout-et-tout-est-un.blogspot.com/2018/11/asciidoc.html
[2] https://asciidoctor.org/docs/
[3] https://asciidoctor.org/docs/what-is-asciidoc/
[4] https://asciidoctor.org/docs/asciidoc-asciidoctor-diffs/
[5] https://maven.apache.org/plugins/maven-site-plugin/
[6] https://un-est-tout-et-tout-est-un.blogspot.com/2018/01/maven-preparons-des-parents.html
[7] https://github.com/dvaillant/coursAsciidoc
[8] https://asciidoctor.org/docs/asciidoctor-maven-plugin/
[9] https://github.com/asciidoctor/asciidoctorj-pdf
[10] https://github.com/asciidoctor/asciidoctorj-diagram/
[11] https://asciidoctor.org/docs/asciidoctor-diagram/

[12] https://github.com/collonville-tom/tc-parent/blob/master/tc-asciidoctor-pdf-parent/pom.xml

[13] https://revealjs.com/

[14] https://mvnrepository.com/artifact/com.googlecode.maven-download-plugin

[15] https://github.com/collonville-tom/tc-parent/blob/master/tc-asciidoctor-html-parent/pom.xml

[16] https://collonville-tom.github.io/tc-un-est-tout-et-tout-est-un/tc-asciidoctor-article/ascii-article.html

[17] http://www.vogella.com/tutorials/AsciiDoc/article.html
[18] https://powerman.name/asciidoc/
[19] https://riduidel.wordpress.com/2017/06/16/generer-mon-asciidoc-dans-docker/

Bonne année 2018

Un article pas trop long pour vous souhaiter une bonne, belle et heureuse année 2018 et aussi pour faire une petite road map des articles en préparation.

Comme vous avez pu le voir; ces dernières semaines ont été un peu chargé et cela a ralenti le nombre d'articles, surtout que j'ai l'impression de plus me documenter que de produire (en terme de code ou de doc) du coup je ne publie qu'à la volée des choses sur lesquelles je tombe comme l'article des QQOQCCP ou sur les processus de dev ou quand je suis amener a faire des modifications dans ma prod perso (la je parle des deux sujets sur les dépôts et paquets Debian)

J'avais promis quelques articles comme Maven, la modélisation et l'IDM  (complété avec un article général sur UML) et c'est chose faite mais je ne suis pas parvenu a sortir ceux sur Drools ou Gradle. alors le second est passé complétement a la trappe car je voulais le faire a la suite de celui sur Maven pour lequel je prévois une suite... et pour le premier, et bien, bien que connaissant déjà Drools pour l'avoir utilisé régulièrement, j'ai voulu élargir le sujet au systèmes expert dans le but de nous amener a de futur article très intéressant portant sur l'Intelligence Artificiel. Cependant, la tache est conséquente et non seulement va nécessiter plusieurs articles mais demande aussi de réorganiser le plan.

Donc voila en résumé de ce début d'année je vous prépare les sujets suivant:

• un peu d'IA en commençant par le système expert suivi par Drools
• une suite pour Maven
• Gradle comme alternative a Maven
• et n'oublions pas les sujets JEE

Au passage j’espère que le petit écart en passant pas la theorie du control par supervision vous aura plus, j'ai pour projet de le compléter par un article sur les processus communicant et la vérification de modèle.

Voila une beau début d'année en perspective!

Les processus de développement ou cycles de vie du logiciel

Dans cet article faisons un état des lieux plus détaillé des cycles de vie les plus importants et les plus couramment utilisés. Après une présentation des cycles classiques comme ceux en Cascade ou en V, seront présentées des méthodes plus récentes basées sur l’agilité.

Les Classiques

Cycle en Cascade

Le cycle en cascade est typiquement un cycle de développement prédictif. Provenant du bâtiment, il part du principe que la construction nécessite, en général, un enchaînement logique ; la couverture d’une maison ne peut pas être effectuée sans avoir préalablement fait les fondations. Il définit une démarche de développement séquentiel (figure 2.9) où chaque phase conduit à la production d’un ou plusieurs livrable(s) qui doivent être validés avant d’être utilisés lors de la phase suivante.

Le modèle en cascade nécessite la définition d’un planning détaillé qui énonce toutes les étapes et réalisations attendues. Différentes activités d’analyse, de conception, d’implantation, de tests et d’intégration sont effectuées afin de converger vers l’obtention du système logiciel final.



Initialement, le modèle en cascade est un cycle de développement purement séquentiel, cependant, diverses possibilités d’itération ou de retour vers les phases amont ont ensuite été intégrées au modèle. Ces itérations permettent de vérifier les produits obtenus au fil du développement et ainsi fournir plus de souplesse à la conception.

Cycle en V

Le cycle en V est l’un des cycles les plus connus et utilisés (figure 2.10). C’est un cycle de type prédictif qui a été défini pour remédier aux lacunes du cycle en cascade qui manque de réactivité face aux erreurs découvertes lors de la conception, du développement ou encore de l’analyse. La structure en V du cycle a l’avantage de mettre en vis à vis les activités de développement et de tests permettant de mieux préciser les documents à
partager entre ces phases, notamment les rapports de tests et les modifications qu’il est nécessaire d’apporter pour corriger les erreurs. Ainsi, lors de la phase montante du cycle, toutes les réalisations doivent être testées et validées.


Depuis les années 80, le cycle en V est considéré comme un standard du développement logiciel et de la gestion de projet dans les industries. A la suite du cycle en V sont apparues diverses variantes telles que, par exemple, le cycle en W qui propose d’effectuer deux cycles en V successivement, le premier servant à la conception d’un prototype de l’application, le second à construire l’application finale.

Cycle en Y

Dans son principe, le cycle de développement en Y, est proche du cycle en cascade dont il reprend l’aspect descendant. Son intérêt est de séparer les préoccupations concernant les aspects fonctionnels liés au domaine métier et les aspects techniques liés aux solutions technologiques à employer pour la mise en oeuvre.

Avec le MDA, un cycle en Y orienté modèle a été proposé afin de séparer les spécifications fonctionnelles (PIM) et les spécifications techniques (PSM). Cette approche a pour avantage de fournir un modèle plus rationnel de la gestion des modèles et de l’utilisation des transformations de modèles employées lors de la phase de conception pour faire coïncider les modèles techniques et fonctionnels (employés également lors de la phase d’implantation sous la forme de génération de code).

Cycle en Spirale

Défini par Barry Boehm, le cycle en spirale est une approche itérative du cycle de développement en V. Ainsi, il en reprend l’essentiel des concepts en s’articulant autour de quatre phases importantes (figure 2.12) : la détermination des objectifs, la détermination des risques, le développement et les tests et enfin la planification de l’itération suivante.




Par contre, à l’inverse du cycle en V, le modèle en spirale met un focus plus important sur l’analyse et la résolution des risques. Ceci est nécessaire car au fur et à mesure des itérations, la réalisation devient de plus en plus conséquente. Il est donc important d’évaluer correctement le risque à chaque itération sachant que toute erreur sera d’autant plus difficile à corriger que le développement sera avancé.

Pre-agilité

Cycle avec Prototypage Rapide (RAD)

Proposé dés la fin des années 1980, le cycle de développement avec Prototypage Rapide (Rapid Application Development aussi appelé semi-itératif) se situe entre une approche prédictive et une méthode agile dans le sens où il s’agit de l’une des premières approches à introduire la notion d’itération au sein du processus de développement. La méthode RAD se structure ainsi autour de cinq phases :

1. L’initialisation pendant laquelle le périmètre du projet et les ressources nécessaires à celui-ci sont définis. Le travail à effectuer est alors organisé par thèmes.
2. Le cadrage qui va définir les besoins et les fonctionnalités du produit. Cette phase est effectuée lors de réunions se basant sur des techniques d’animation spécifiques.
3. La conception des modèles nécessaires à l’élaboration du système logiciel proprement dit. Le client est fortement impliqué dans cette phase puisqu’il a pour rôle de valider les modèles proposés.
4. La construction du système logiciel par l’équipe de développement par une approche itérative selon les fonctionnalités demandées. Le client est toujours présent afin de valider les différentes réalisations.
5. La finalisation est une phase de validation globale du livrable final par le client.

Ainsi, les deux premières phases se placent dans une approche descendante comme celle en V ou en Cascade. Par contre, à partir de la troisième phase, le cycle de développement devient itératif en permettant d’alterner conception et validation. De plus, avec l’intégration du client dans le développement, cette démarche fournit plus de réactivité.

La méthode RAD est pionnière dans l’utilisation de l’itération et d’une intégration plus importante du client dans le processus de développement. A ce titre, elle peut être considérée comme initiatrice des méthodes agiles qui sont fondamentalement tournées vers ces concepts. Les paragraphes suivants présentent les démarches et cycles proposant une approche agile du développement.

Unified Process UP

Tout comme RAD, UP est un cycle de développement qui se positionne entre les approches prédictives et les approches agiles. Ce cycle de vie est né de l’approche orientée objet issue de la collaboration de Ivar Jacobson, Grady Booch et James Rumbaugh. L’approche UP tente de rationaliser les processus de développement logiciel en fournissant un guide de bonne pratique fondé sur six points :

1. Avoir une démarche incrémentale et itérative pilotée par les risques et les cas d’utilisation.
2. Avoir une gestion rigoureuse des exigences.
3. Centrer le développement sur l’architecture.
4. Faire une modélisation graphique des exigences.
5. Contrôler en permanence la qualité.
6. Contrôler les changements éventuels à effectuer.

Ces six bonnes pratiques prônées par UP sont en l’occurrence ce qui permet de rattacher ce cycle de développement aux méthodes agiles. En effet, contrairement aux démarches de développement classiques, UP oriente naturellement le développement pour que celui-ci soit à même de répondre aux changements.
UP définit une démarche de développement intégrant les neuf disciplines majeures nécessaires au développement : la modélisation métier, la définition des exigences, l’analyse et la conception, l’implantation, les tests, le déploiement, la gestion des changements, la gestion du projet et enfin la prise en compte de l’environnement. Basé sur ces disciplines qui seront employées à chaque itération, le processus de développement va alors pouvoir suivre les quatre phases du processus qui consistent en :

1. Le début dont l’objectif est d’unifier les points de vue de chacune des disciplines sur l’ensemble du projet.
2. L’élaboration qui a pour objectif de définir et de valider l’ensemble des modèles permettant la conception du système logiciel.
3. La construction qui doit fournir une version documentée et fonctionnelle du logiciel.
4. La transition dont le but est de finaliser le système.

Avec Unified Software Process Metamodel (USPM), les démarches de développement se sont orientées vers la modélisation des processus en suivant le credo issu de la publication de Lee Osterweil : Software processes are software too. Traduit littéralement que les processus de développement de logiciel sont aussi une forme de logiciel. Cette publication montre la nécessité de maîtriser le processus de développement en modélisant sa structure et son évolution.

L'agilité

L’extreme programming

L’extreme programming est à proprement parler une approche agile qui propose des itérations courtes impliquant au maximum le client et cherche à recentrer le développement sur la composante humaine en revalorisant les bonnes pratiques de développement telles que le binomage, la définition au plus court de tests fonctionnels permettant de valider l'application, la promotion de styles ou de pattern d'écriture de code.
XP fonctionne autour de 5 valeurs fondamentales souvents reprise dans les approches agiles plus récentes:

• Communication
• Feedback
• Simplicite
• Courage
• Respect

Scrum

Développée en 1993, Scrum est une approche agile qui met en avant l’intérêt des petites équipes de développement. Dans ces petites équipes, sont avant tout recherchées les compétences multidisciplinaires et la capacité d’intégration sociale des acteurs. Dans Scrum, les itérations appelées Sprint sont planifiées sur quatre semaines maximum. Ces itérations sont axées sur les besoins définis par le client qui constituent alors le référentiel de travail.
Les besoins sont hiérarchisés par degré d’importance et développés selon les priorités définies par le client. Chaque jour constitue une itération pendant laquelle une réunion est organisée pour établir l’état d’avancement du projet et de vérifier que les fonctionnalités et les délais sont bien respectés.



A la fin de chaque Sprint, une réunion établissant le bilan des réalisations est menée afin d’établir l’efficacité de l’équipe et les éventuelles améliorations qui doivent être apportées. La finalité d’un Sprint est de présenter un démonstrateur au client afin que celui-ci puisse valider les réalisations. Scrum définit un certain nombre d’acteurs qui vont intervenir lors de la mise en oeuvre du processus :

1. Le ScrumMaster a pour rôle d’aider les acteurs du développement à communiquer au sein de l’équipe ainsi qu’avec le client. Il doit s’assurer que la philosophie et les pratiques de Scrum sont correctement suivies. Par contre son rôle n’est pas à confondre avec celui du chef de projet dont il est plutôt un conseillé.
2. Le Client ou Product Owner est lui aussi acteur du développement, il a pour rôle de définir les besoins. Il doit également définir les priorités dans les fonctionnalités à réaliser. Ainsi, il participe activement à l’élaboration du produit en suivant les étapes de sa réalisation afin de pouvoir en valider la finalité.
3. Enfin, l’Équipe qui est constituée de l’ensemble des corps de métiers nécessaires à l’élaboration du produit. Ces métiers sont classiquement ceux rencontrés lors des développements logiciels classiques (Développeur, Analyste, Testeur, etc.)

Pour finir, la méthode Scrum s’appuie sur la notion de Visibilité pour qualifier et quantifier les résultats de l’équipe. Des critères de validation doivent exister afin de définir si une fonctionnalité a été complètement réalisée ou non. Des critères d’Inspection doivent être définis afin de déterminer l’existence d’écarts entre la réalisation concrète et l’objectif final. Enfin, la notion d’Adaptation permet, lors d’écarts trop importants détectés pendant des Inspections, de modifier la gestion interne de l’équipe afin d’éviter que ces écarts ne s’amplifient. Ces critères permettront alors de gérer de la dette techniques ou encore d'évaluer la vélocité de l'équipe de développement afin de planifier au mieux les contenus des livraisons futurs

On peut noter que Scrum et XP sont deux approches très proches (on note d’ailleur une forte proximité des valeurs vehiculés) qui cherchent l’une comme l’autre a remettre la vie du développeur au centre du processus. Cependant Scrum a une volonté plus marqué de fournir un processus formellement établi pour gérer le cycle de vie du logiciel alors que XP s'intéresse plus sur les bonnes pratiques. Généralement les equipes de développement pratiquant l’une pratique préférablement la seconde.

Lean

Le lean est une approche de gestion de production développé par Toyota dans les années 90. Avec un héritage assumé issu du Taylorisme, le lean se définit dans une recherche d'accroissement de la productivité, de la qualité et d'une réduction systématique du gaspillage.

Dans les approches agiles, si XP a pour propos de mettre en avant des valeurs humaines et si Scrum a pour objet de recentrer le processus autour de la production des éléments a plus haute valeur, le Lean complète ces approches en visant l’optimisation des processus eux même.

Pour cela, le lean va se focaliser sur 7 règles qui servent d’axes de progressions (qui sont probablement des questions systématiques aux rétrospectives de sprints):

1. comment reduire les dechets? (temps perdus, réduction de dette technique, etc…)
2. comment améliorer la monté en compétences?
3. decider au plus tard
4. livrer au plus tot
5. valoriser l’equipe
6. la qualité commence des la conception
7. avoir toujours une vision du logiciel dans sa globalité (maintenir le recul)

Conclusion

Les processus de développement sont nombreux et si historiquement l'approche en V a été adoptée majoritairement, les nouvelles approches comme les approches agiles tendent a s'imposer comme étant des solutions plus dynamique et adaptées aux changements actuel. Je reviendrais plus dans le détail des approches telles que Scrum et Lean qui mérite au vue de leur présence actuel d'être approfondie. De la même manière, ces dernières années, au delà des processus de développement, on a pu voir émerger le DevOps dont le but est de regarder au delà des équipes de développement en prenant en considération l'ensemble des besoins des acteurs agissant de près ou de loin dans la livraison du produit au client. Il me semble que même si cela déborde du cadre des processus de développement de l'équipe logicielle, celle ci doit prendre en compte ces nouvelles préoccupations et cela a forcément un impact sur leur activité

Ingénierie Dirigée par les Modèles

L'ingénierie dirigée par les modèles (IDM) [13], [16] et [17]  est un cadre méthodologique permettant d'unifier différents domaines. Elle permet cette unification grâce à l'utilisation importante de modèles (potentiellement exprimables suivant différents domaines) et des transformations automatiques entre ces modèles. L’IDM permet le développement plus souple et plus simple de programmes informatiques dans des contextes comme les IHM  ou les systèmes temps réels distribués.

Système d’étude

L’IDM définit la notion de système [13] comme étant l’entité étudiée dans le cadre d’un processus de modélisation. Un système est vu comme étant un ensemble d’entités en interactions décomposable en sous-systèmes. Cette décomposition amène à une relation de composition entre systèmes et sous-systèmes. Dans [13], comme illustré par la figure 48, trois types principaux de systèmes sont distingués permettant une première classification : les systèmes physiques, les systèmes numériques et les systèmes abstraits. Un système physique représente une entité physique concrète et observable sur lequel l’homme peut d’agir matériellement. Un système abstrait est une entité purement conceptuelle comme un objet mathématique (fonction, ensemble, etc.). Un système numérique est un système appartenant à la classe des objets informatiques. Cette liste n'est pas exhaustive mais elle a le mérite de mettre en avant les limites de la modélisation: le monde physique et le monde conceptuel.

Modèle

Un modèle est l’abstraction d'un système réalisé dans une intention et un contexte particulier. Un modèle doit pouvoir être utilisé pour répondre à des questions sur le système. Un modèle peut décrire ou spécifier un système. Dans le premier cas, le modèle doit respecter le système, dans le second cas, c'est le système qui doit respecter le modèle. La relation existante entre le modèle et le système est définie dans les termes de "est le modèle de" ou "est représenté par" comme illustré par la figure 49. Comme le système, le modèle est composé d'éléments qui sont les abstractions des sous-systèmes donc également des modèles.

Méta-modèle

L'IDM définit le contexte de réalisation de modèles par un meta-modèle. Le meta-modèle est le modèle d'un langage de modélisation qui est l'ensemble des modèles réalisables comportant des caractéristiques communes. Le meta-modèle a un rôle important dans la modélisation car il définit les règles de construction de modèles pour le domaine qu'il définit. Un modèle est alors dit conforme à un meta-modèle s'il appartient à l'ensemble des modèles modélisé par le meta-modèle. Cette relation de conformité est illustrée par la figure 50.

Le système, le modèle, le langage de modélisation et le méta-modèle peuvent être réunis au sein d'un même diagramme en faisant apparaître les relations de conformité, de modélisation ainsi que d'appartenance à un langage de modélisation (figure 51). Ce diagramme porte le nom de pattern "Step" dans [13].

Langage spécifique de domaine

Apres les notions de bases de système, de modèle et de meta-modèle, l'IDM offre une définition de la notion de Langage Spécifique de Domaine (DSL). Un DSL est un langage qui capture les aspects spécifiques à un domaine comme le ferait un meta-modèle. Un DSL intègre cependant plus que cela car il intègre la notion de sémantique.

Transformation de modèles

Une transformation de modèles définie par IDM est la modification d'un modèle suivant des règles définies au niveau de son méta-modèle. Les transformations de modèles sont de deux types, les transformations de modèles endogènes et les transformations de modèles exogènes.

 Les transformations de modèles endogènes sont des transformations sans modification du meta-modèle donc au sein d'un même langage de modélisation. Ces transformations sont généralement dues à l'évolution du modèle dans une exécution.

 Les transformations exogènes permettent le changement de meta-modèle auquel le modèle est conforme afin de passer d'un langage de modélisation à un autre. Ce changement de langage de modélisation permet de bénéficier des avantages de chaque langage ou d'automatiser un processus de développement, ce processus se décomposant en diverses étapes qui peuvent être: une étape de modélisation, une étape de vérification puis une étape de ciblage vers une plateforme spécifique. Le passage d'une étape à une autre se réalisant par transformation de modèles.

 Pour la réalisation des transformations de modèles, l'IDM propose un modèle de transformations, illustré par la figure 52, liant les différents éléments du méta-modèles de façon à établir des règles de correspondances. Ces règles, appliquées au modèle à transformer, vont permettre la réalisation d'un nouveau modèle conforme au meta-modèle ciblé.



Exemple:
Avec l'illustration de la figure 53, considérons un fichier XML de base de données contenant l'identité de Thomas ainsi que des informations confidentielles telles que son adresse. Pour l'affichage des informations non confidentielles en HTML, vient tout de suite à l'esprit XSLT afin de générer de l'HTML automatiquement. Dans le cadre IDM ceci est purement une transformation de modèle par filtrage des informations et par la réalisation d'une mise en page.

Conclusions

L'IDM offre un cadre unifié pour la réalisation et la manipulation de modèles grâce aux notions de meta-modèle, de langage de modélisation, et de relations de :
•    Modélisation entre le système et son modèle ainsi qu'entre le langage de modélisation et le meta-modèle.
•    Conformité entre le modèle et son meta-modèle.

 La notion de transformation de modèles donne la possibilité d'intégrer diverses technologies possédant leur propre langage de modélisation dans le but de réaliser des systèmes complexes et fiables par génération automatique de code, par vérification dans des domaines adaptés à cette tâche etc. L'IDM offre le cadre nécessaire pour la mise en place d'un processus visant le développement d'un système logiciel par transformations de modèles. La dernière phase de ce processus est le ciblage vers une plateforme d'exécution permettant de finaliser la réalisation du système logiciel. La définition d'une plateforme d'exécution doit donc être définie.

 References:

[13] J-M. Favre. J. Estublier, M. Blay-Fornarino; L'ingénierie dirigée par les modèles, 2006, Edition Hermes, Lavoisier, Paris.
[16] A. Rasse, J-M. Perronne, B. Thirion. Ingénierie dirigée par les modèles pour une conception fiable des logiciels de commande, 2005 IDM05, p 231-244
[17] A. Rasse, Approche orientée modèles pour la spécification, la vérification, l'implantation des systèmes logiciels critiques, à paraître (2006), Mémoire de thèse, Université de Haute alsace, Laboratoire MIPS.

Design pattern : Etat

Le pattern Etat ou pattern state est un pattern comportemental. Il permet dynamiquement de changer le comportement du système logiciel qui l'utilise au delà du pattern stratégie qui n'est qu'une délégation du comportement. Le pattern état va bien plus loin car l’état est gérer par le client lui-même et les changements de mode de fonctionnement (donc d’état) sont également a la responsabilité du client. Le pattern stratégie ne permet pas ce niveau d'adaptation.



A noter que si état et stratégie sont bien des patterns différents, on peut facilement imaginer une utilisation du pattern stratégie pour répondre au besoin comportemental de chacun des états si des contexte d'utilisation sont différents eux aussi.

Par exemple, si l'on modélise le comportement d'un robot au travers d'un pattern état qui représenteront des modes de marche, on emploiera alors le pattern stratégie pour se placer dans un contexte réel et un contexte simulé. La différence entre les deux patterns se situe la.

A noter que personnellement je trouve ce modèle du pattern état très simple et j'aurai plutôt une approche IDM (Ingénierie Dirigée par les Modèles) pour la modélisation d'un système a Etat complet exploitant toute la sémantique des FSM (Finite State Machine). Je traiterais de ces sujets dans des articles dédiés.