FR 2869127 A1 20051021 FR 0404098 A 20040419 PROCEDE DE GENERATION DE CIBLES DE TYPE DOCUMENTS XML, CODES, DIAGRAMMES, CONTROLES DE COHERENCE, INTERFACES HOMME/MACHINE Domaine technique général L'utilisation des modèles informatique augmente significativement depuis les années 1990, et a connu un fort regain avec l'arrivée du standard UML (Unified Modeling language, standardisé par l'OMG). On estime que dorénavant, plus de 20% des développements informatiques s'appuient sur la modélisation en utilisant UML, cette tendance augmentant toujours. La généralisation de cette pratique incite les utilisateurs à rechercher une exploitation maximale de ces modèles à des fins de production automatisée de code ou d'autres livrables importants dans un développement comme par exemple des diagrammes. L'approche MDA (Mode) Driven Architecture) promue par l'organisme de standardisation OMG va dans ce sens, afin de définir les technologies de base permettant d'exploiter les modèles. Cependant, l'approche MDA , si elle a le mérite de positionner et de standardiser les technologies sous jacentes, reste très technique , et peu accessible aux utilisateurs ciblés par ce type de besoin. Les utilisateurs sont typiquement des ingénieurs qualité, des ingénieurs méthode, des architectes logiciels, des chefs de projet, qui ne sont pas des spécialistes des technologies MDA comme par exemple les métamodèles, la transformation de modèle ou encore les profiles UML. L'objet du brevet présenté est de fournir un outillage accessible à tous par sa simplicité et très efficace en capacité de définition d'une exploitation de 25 modèles. Présentation de l'invention Le procédé de représentation et de génération de cibles de type documents XML, codes, diagrammes, contrôles de cohérence, interfaces 30 homme/machine, comprend la définition d'une structure d'arbre spécialisée par type de cible à générer, un tel arbre étant destiné à être appliqué à un modèle source. Pour chaque type de cible à générer, l'arbre contient des informations spécifiques de la cible à générer, propose des actions d'un intérêt typique pour la cible, ledit arbre étant interprété par un moteur d'exploitation dédié à la cible ou par un générateur de code transformant l'arbre en code; Chaque noeud de l'arbre contenant sous forme de choix préétablis mais pouvant être directement exprimées sous forme de code au moins une expression de navigation dans le modèle source et/ou une expression de filtrage et/ou une action à effectuer, cette dernière pouvant se décomposer en action avant, pendant et après le traitement du noeud. Partant des modèles d'applications logicielles, que ceux-ci soient exprimés en UML ou en d'autres langages, l'invention consiste à permettre de définir des exploitations de ces modèles pour une cible particulière (code, production de diagrammes, production de contrôles de cohérence, etc.) en bâtissant des représentations spécialisées selon les cibles sous une forme d'arbre représentative de la structure de la cible. A chaque type de cible correspond un type d'arbre dédié, qui a des informations dédiées à la cible, dispose d'un moteur d'interprétation spécifique et est édité sous une forme spécialisée. Ainsi, peuvent être réalisés des types d'arbre dédiés (voir Figure 1) : / à la traduction d'un modèle en code / à la création automatique de diagrammes d'après un modèle / au contrôle de cohérence sur un modèle / à la production de documents XML d'après un modèle Ces types d'arbres spécifiques sont appelés modèle de produit . Traditionnellement, pour obtenir un traducteur automatique d'un modèle informatique en une cible particulière (code, diagrammes, etc.), il faut programmer dans un langage informatique les règles de traduction. Cette activité nécessite une connaissance des langages informatiques et des métamodèles. L'invention permet de représenter ces traducteurs sous forme d'arbre, et de produire ces traducteurs automatiques sans programmation ou avec un niveau très réduit de programmation. Les catégories de modèle de produit citées ici ont été instrumentées par des logiciels, mais ne sont pas sensées être exhaustives. Le présent brevet recouvre toute exploitation reprenant le même procédé. Ces arbres permettent, via des éditeurs spécialisés, de présenter une forme naturelle de la cible, comme par exemple une vision structure de code pour un modèle de produit code source ou encore la structure d'un document XML pour un modèle de produit XML. Cette forme naturelle de la cible ne correspond pas à un modèle détaillé de celle-ci, mais plutôt à une façon de la représenter qui apparaisse intuitive à l'utilisateur, et suffisamment détaillée pour en permettre une exploitation informatique. Avantageusement, chaque noeud dispose d'informations spécifiques au type de cible, ces informations fournissant les expressions de navigation et/ou de filtrage lorsque la cible est connue. La spécialisation selon les cibles des modèles de produit permet, pour chaque noeud de l'arbre, de présenter des informations ayant un intérêt spécifique de la cible, et fournissant des exploitations (actions) dédiées de ces informations. Ainsi, un modèle de produit code indiquera par exemple des indications d'indentation du code ou de balisage du code. Un noeud d'un modèle de code sera donc un fragment de texte inséré dans le code lors de sa génération. Chaque catégorie de modèle de produit procure une signification spécifique à chacun des noeuds. Par exemple, un noeud d'un modèle de produit de code correspondra à un fragment syntaxique du code, un noeud d'un modèle de produit de diagramme correspondra à un élément graphique (boite, lien, annotation textuelle) en produisant ses caractéristiques graphiques (couleur, police de caractère, et autres options pertinentes). Par ailleurs de préférence, chaque noeud contient sous forme de choix préétablis - mais pouvant être directement exprimées sous forme de code au moins une expression de navigation, une expression de filtrage ou une action. Ainsi, chaque noeud de l'arbre exprime: É Sur quel type d'élément de modèle il s'applique, É La navigation à opérer dans le modèle pour accéder aux éléments de modèle sur lesquels le noeud s'appliquera, en s'appuyant sur la localisation du noeud parent (règles de navigation). La mise en oeuvre de méthodes de parcours ou de navigation prédéfinies basées sur un méta modèle de référence en facilite l'utilisation et la mise en oeuvre. É Une sélection sur les éléments de modèles à traiter. (règles de filtrage) É Une description des actions à entreprendre pour chacun de ces éléments de modèle. C'est notamment par des actions prédéfinies typiques d'une cible, que cette technique permet un traitement, le plus souvent sans code, rapide à mettre en oeuvre. Les caractéristiques exprimant les éléments de modèle ciblés, les règles de navigation et les règles de filtrage sont communes à toutes les catégories de modèle de produit. [4]Les actions sont par contre très spécialisées selon ces catégories. Par exemple, l'insertion de balise XML ou d'élément XML sont des actions typiques de la production de document XML, l'indentation de texte est une action typique de la génération de code et l'expression de la présence ou de l'absence d'une valeur est typiquement utilisée pour les contrôles de cohérence. Par ailleurs, il est possible pour un noeud de spécifier des actions générales exécutées avant de traiter les éléments de modèles, puis les actions portant sur chacun des éléments de modèle sur lesquels le noeud doit être appliqué, et enfin les actions générales réalisées après les traitements spécifiques des éléments de modèle. Egalement, lorsque les navigations, filtrages ou actions prédéfinies ne suffisent pas à exprimer l'intention de génération vers la cible, des zones d'échappement permettent d'introduire des navigations ou des filtrages (expressions booléennes) ou des actions sous forme de langage script de manipulation du modèle. L'algorithme présenté en description détaillée peut être appliqué à un modèle de produit. Pour chaque type de modèle de produit, un interprète peut être réalisé. Cet outil interprète les informations fournies par le modèle de produit pour exploiter des modèles, et générer des produits. Il est également possible de produire automatiquement un programme de génération, à partir d'un modèle de produit. Cette deuxième solution est moins souple mais plus efficace que l'interprète, Le procédé proposé peut notamment être un procédé de représentation et de génération de code pour tout langage informatique (Java, C++, etc.), un arbre étant une forme hiérarchique représentant la structure d'un code source, chaque noeud représentant un groupe syntaxique particulier. Les modèles de produits de code (Figure 6) présentent par exemple les actions spécifiques suivantes pour chaque noeud: É Création d'un fichier associé au noeud: permet de définir le découpage en fichier d'un code source É Insertion d'un texte prédéfini dans le produit source É Insertion d'un squelette de code associé dans le produit source É Indentation É Insertion d'une balise gérant la cohérence code source/modèle É Insertion d'une expression libre en script produisant une chaîne de caractère D'autres informations adaptées peuvent être adjointes. [8] Cette technique de modèle de produit peut être utilisée conjointement avec d'autres techniques connues pour certaines cibles, afin d'augmenter le potentiel et la facilité de génération. Ainsi, la technique de squelette de code (ou template selon la terminologie anglo-saxonne) utilisée pour la production de code, qui consiste à insérer des échappatoires représentant des valeurs à calculer dans du texte prédéfini représentant le code prédéfini (Figure 7) est fréquemment utilisé. En permettant à chaque noeud du modèle de produit de code de définir des actions en terme de squelette de code , et en permettant dans les échappements de ces squelettes de référencer un autre noeud, on peut construire un modèle de code par emboîtement, comme un assemblage de poupées russes , et éviter toute expression complexe d'itération qui obscurcit traditionnellement les squelettes de code. Le procédé proposé peut également être utilisé pour la génération de contrôles de cohérence Les modèles de produit de contrôle de cohérence permettent de définir des cohérences à vérifier sur un modèle, chaque noeud représentant une règle de contrôle de cohérence appliquée sur un élément de modèle particulier. La figure 5 en présente un exemple. Chaque noeud du modèle de produit correspond à une vérification particulière à opérer. L'arborescence représente les règles appliquées sur des types d'éléments de modèle définis. Dans ce modèle, les actions sont des contrôles (pouvant être des expressions booléennes) et des affichages de messages explicitant les erreurs. Par exemple, les actions prédéfinies pour chaque noeud peuvent être: É Des conditions prédéfinies de cardinalité (comparaison de nombre d'éléments >0, ≥0, > 1, etc. É Des vérifications de niveau d'imbrication ou de répétition É Des types de message (erreur, avertissement) É Des insertions de message D'autres informations adaptées peuvent être ajoutées à ces modèles de produits. Le procédé proposé peut en outre être utilisé pour la génération et représentation de diagrammes. L'imbrication graphique (exemple: classes dans un package, attributs dans une classe) étant représentée par la structure hiérarchique des noeuds, c'est-à-dire par l'arbre, chaque noeud représentant un élément de modèle affiché et possédant les propriétés graphiques que l'on veut représenter. Les modèles de produit de diagrammes permettent de définir les règles de construction ou de mise à jour de diagrammes d'après un modèle. Un exemple de modèle de produit de diagrammes est fournit figure 3. Dans ce type de modèle de produit, les noeuds représentent les éléments graphiques disposés sur un diagramme, la racine représentant un diagramme complet. Les informations spécifiques de ce type de modèle de produit sont par 30 exemple: É Pour la racine de l'arbre: o Type de diagramme (exemple diagramme d'état, diagramme de classes, etc.) o Importance du diagramme (vue par défaut ou sur demande spécifique) É Pour les noeuds de l'arbre o Couleur de premier plan de l'élément o Couleur d'arrière plan de l'élément o Police de caractère o Options d'affichage (par exemple dans le cas de modèles UML, mode de présentation des stéréotypes, des tagged values, présentation détaillées des signatures ou compacte, etc.) o Affichage imbriqué ou séparé de l'élément D'autres informations adaptées peuvent être ajoutées à ces modèles de produits. Les modèles de produit de documents XML permettent de définir les modalités de construction d'un document XML d'après un modèle. Chaque noeud d'un modèle de produit représente un noeud de l'arbre XML, la racine représentant un modèle complet. Les noeuds des modèles de produit XML contiennent par exemple: É Insertion d'un élément É Insertion de texte É insertion d'une balise É référencement d'un document É insertion d'un squelette de texte É insertion d'un attribut É insertion d'un commentaire D'autres informations adaptées peuvent être ajoutées à ces modèles de produits. Le présent brevet montre des cas particuliers d'utilisation où cette technique a été mise en oeuvre, mais couvre l'ensemble des cas où une cible peut se représenter sous forme d'arbre. Le nombre d'applications est potentiellement très grand. Par exemple, la définition d'une traduction d'un modèle en d'interface hommelmachine peut être effectuée via cette technique. II est utile de pouvoir référencer un autre modèle de produit ou d'autres noeuds depuis un modèle de produit. Ceci permet d'exploiter la production correspondant à ce noeud ou à cet arbre depuis le noeud ou la référence apparaît. Par exemple dans un modèle de produit de code, il est possible depuis un squelette de code de référencer un noeud pour insérer dans le code associé au squelette le résultat de l'exécution du noeud. L'originalité du présent brevet consiste à définir plusieurs types d'arbre (modèles de produit) dédiés à chacune des cibles, dont la représentation n'est pas un modèle ou métamodèle générique, mais une représentation sous forme naturelle et intuitive pour l'utilisateur. L'utilisateur peut, pour chaque modèle de produit, en choisissant un des types de noeuds disponibles, bâtir des noeuds d'une granularité variable, correspondant à sa vision de la cible à produire. Description des illustrations annexées La figure 1 présente le principe de fonctionnement d'un modèle de produit de code, en montrant comment l'application d'un modèle de produit sur un modèle se traduit en un code. La figure 2 représente les propriétés d'un modèle de produit diagramme. 30 On y voit des propriétés très spécifiques des diagrammes (1), que l'on ne retrouve pas dans les autres catégories de type de produits. La figure 3 présente un modèle de produit diagramme. (1) présente une action de navigation, et (2) désigne des actions d'affichage. La figure 4 représente un modèle de produit contrôle de cohérence. (1) présente une action de navigation, et (2) désigne des actions de vérification 5 de modèle. La figure 5 présente un exemple de résultat obtenu en appliquant un produit de contrôle de cohérence sur un modèle. La figure 6 présente un modèle de produit code. (1) représente des propriétés relatives au noeud sélectionné; (2) représente un Noeud et sa navigation correspondante; (3) représente une action appliquée sur un noeud. La figure 7 précise la figure 6, en montrant la combinaison de la rédaction d'un squelette de code, avec un modèle de produit code. (1) représente dans le squelette des zones d'échappement dans lesquelles peuvent exister des références aux résultats d'autres noeuds. La figure 8 présente la définition de filtres prédéfinis. La figure 9 présente l'exploitation des techniques de navigation prédéfinies. Pour chaque type d'élément de modèle, il est proposé un ensemble d'accès possibles vers d'autres éléments (1). Description détaillée Principe général La description d'un modèle de produit permet d'être interprétée par un moteur de produit ou permet de générer un code s'exécutant 25 conformément à la description du modèle de produit. Le modèle de produit est alors exploité par le moteur (ou le code généré), qui l'active à partir d'un élément d'un modèle particulier (comme par exemple un package UML). Le moteur ou code généré interprète ou exécute la description fournie par le modèle de produit en partant de cet élément de modèle: le noeud racine du modèle de produit. Dans l'exemple Erreur! Source du renvoi introuvable., un noeud racine s'applique sur un package, un noeud fils s'appliquera ensuite sur l'ensemble des classes du package, et un noeud fils de ce dernier s'appliquera sur les attributs de chacune des classes. Sur l'élément de modèle correspondant au noeud racine, le moteur applique les actions spécifiées par le noeud (par exemple, indenter, changer de couleur, vérifier une propriété, produire un texte en extrayant des informations, etc.). Dans l'exemple Erreur! Source du renvoi introuvable., un texte est inséré ( Description des classes ), puis les noeuds fils sont interprétés. En suivant l'ordre indiqué par le modèle de produit, le moteur interprète successivement les noeuds: 1. Il exploite les règles de navigation pour les appliquer à partir de l'élément de modèle du noeud parent, et obtenir une liste des éléments de modèles à traiter. Ainsi, dans le 2e noeud Erreur! Source du renvoi introuvable., il va rechercher les classes du Package. 2. II applique le filtre spécifié le cas échéant. (il n'y en a pas dans l'exemple) 3. II exécute les actions spécifiées par le noeud. Dans l'exemple, sur le deuxième noeud, il insère le texte Class { , puis indente le texte, et enfin, une fois les actions du noeud 3 achevées, il insère le texte "}" (Post). Ce processus est répété jusqu'au total parcours de l'arbre du modèle de produit. Les actions, le filtrage, et les règles de navigation seront autant que possible, et dans la grande majorité des cas exprimés sous forme de sélection de choix prédéfinis, supportés par une interface homme/machine dédiée. Cependant, des échappements sont possibles pour substituer à ces choix prédéfinis des instructions de manipulation de modèle dans un langage de script approprié. Sélection et création de méthodes de navigation Les méthodes de navigation sont prédéfinies pour chaque élément de modèle. Elles expriment un parcours qui à partir de l'élément de modèle du noeud parent, désigne un ensemble d'éléments de modèles sur lequel le noeud courant s'applique. Elles indiquent les navigations les plus utiles et fréquemment utilisées. L'utilisateur les voit simplement à travers leur nom, qui exprime leur fonction (par exemple classes du package ). Leur traitement effectif peut être très complexe. Sélection et création de filtres Pour chaque élément parcouru par la méthode de navigation, des règles de filtrage sont appliquées. Les éléments respectant toutes les règles de filtrage sont effectivement parcourus et les actions associées sont appliquées. Les autres éléments ne satisfaisant par les filtres sont ignorés. Un ensemble de filtres prédéfinis est disponible à l'utilisateur, lui permettant de créer rapidement toutes les règles que les éléments à parcourir doivent respecter. L'utilisateur peut aussi créer ses propres règles de filtrage, pour les ajouter à l'ensemble des règles prédéfinies. Action Les actions s'appliquent pour chacun des éléments de modèles désignés par un noeud. Elles sont exécutées en suivant le parcours de l'arbre, pour chacun des noeuds, dans l'ordre de haut en bas tel qu'il apparaît visuellement dans les exemples. Les actions peuvent se décomposer en actions avant (pré) décrivant des actions avant l'application du noeud sur chacun des éléments de modèle désignés, actions pendant (action) décrivant le traitement du noeud pour chacun des éléments de modèle désignés, et actions après (post) décrivant les actions à réaliser après le traitement de chacun des éléments de modèles désignés pour le noeud. Des actions prédéfinies sont mises à disposition selon la cible visée par le modèle de produit. Elles représentent les traitements les plus fréquents et utiles correspondant à la nature de la cible. Par exemple, pour un diagramme, des actions peuvent être faire apparaître un élément graphique , changer de couleur de fond , etc. La définition des actions peut être étendue en utilisant des langages de scripts supportés par l'environnement de modélisation associé. 14 Glossaire É action: Attaché à un noeud de l'arbre modèle de produit . Exprime quelles actions doivent être engagées sur chacun des éléments de modèles sur lesquels s'applique le noeud. É Arbre: Représentation hiérarchique d'informations. É Cible: Environnement technique sous lequel une application doit être produite. On parle de langage cible pour désigner le langage d'exécution, d'architecture cible, de système d'exploitation cible, etc. Plus généralement, désigne l'objectif et la technologie de production. Une cible peut être un document HTML , un graphique, un code XML , etc. É Elément de modèle: Unité exploitée dans un modèle informatique. Par exemple, une classe, un attribut, un paramètre sont des éléments de modèle. É MDA : Mode! Driven Architecture. Standardisée par l'OMG (Object Management Group- organisme de standardisation), cette technique vise à guider le développement logiciel par le modèle, en exploitant au maximum les modèles à des fins de production. É Modèle de produit: Technique objet du brevet. Représentation d'une cible sous une forme d'arbre permettant d'automatiser la production de la cible à partir d'un modèle. É Modèle informatique: Représentation d'un système informatique basée sur un langage graphique défini. É Règle (ou expression) de filtrage: Attaché à un noeud de l'arbre modèle de produit . Clause booléenne permettant de filtrer (omettre) les éléments pour lesquelles celle-ci est fausse. É Règle (ou expression) de navigation: Attaché à un noeud de l'arbre modèle de produit . Expression permettant de naviguer depuis l'élément de modèle où le noeud parent est appliqué, pour exprimer à quels éléments de modèle le noeud courant s'applique. Exploite typiquement les associations du métamodèle pour exprimer un parcours. É Template de code: Aussi appelé squelette. Description du code avec des zones contenant le code directement saisi, et des zones échappatoires autorisant des calculs de valeurs à introduire dans code prédéfini. É Type d'arbre: Forme de représentation arborescente pour un type d'objectif (cible) particulier. Chaque catégorie de modèle de produit exploite un type d'arbre donné. É UML: Unified Modeling Language. UML est un langage standard de modélisation (standardisé à l'OMG), très répandu dans les développements informatiques. REVENDICATIONS 1. Procédé de représentation et de génération de cibles de type documents XML, codes, diagrammes, contrôles de cohérence, interfaces homme/machine, ledit procédé comprenant la définition d'une structure d'arbre spécialisée par type de cible à générer, un tel arbre étant destiné à être appliqué à un modèle source, caractérisé en ce que, pour chaque type de cible à générer, l'arbre contient des informations spécifiques de la cible à générer, propose des actions d'un intérêt typique pour la cible, ledit arbre étant interprété par un moteur d'exploitation dédié à la cible ou par un générateur de code transformant l'arbre en code; Chaque noeud de l'arbre contenant sous forme de choix préétablis - mais pouvant être directement exprimées sous forme de code au moins une expression de navigation dans le modèle source et/ou une expression de filtrage et/ou une action à effectuer, cette dernière pouvant se décomposer en action avant, pendant et après le traitement du noeud. 2. Procédé selon la revendication 1, caractérisé en ce que chaque noeud contient sous forme de choix préétablis - mais pouvant être directement exprimées sous forme de code au moins une expression de navigation, une expression de filtrage ou une action. 3. Procédé selon l'une des revendications fou 2, caractérisé en ce que chaque noeud dispose d'informations spécifiques au type de 30 cible, ces informations fournissant les expressions de navigation et/ou de filtrage lorsque la cible est connue. 4. Procédé selon l'une des revendications précédentes, caractérisé en ce que les actions prédéfinies fournissent des traitements typiques et/ou fréquents pour la cible et définissent au moins en partie la traduction de l'arbre appliqué à un modèle source vers une cible, 5. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'un arbre a la capacité d'inclure des règles de navigation, des règles de filtrage ou actions libres, par insertions de scripts en langage de programmation supporté par l'environnement de modélisation. 6. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'un noeud d'un arbre a la capacité de référencer un autre noeud et un arbre de référencer un autre arbre depuis un noeud. 7. Procédé de représentation et de génération de code pour tout langage informatique (Java, C++, etc.). caractérisé en ce qu'il met en oeuvre le procédé selon l'une des revendications précédentes, un arbre étant une forme hiérarchique représentant la structure d'un code source, chaque noeud représentant un groupe syntaxique particulier. 8. Procédé selon la revendication 7, caractérisé en ce des actions au sein d'un noeud d'un arbre de cibles de type code sont exprimées 25 sous forme de squelette de code. 9. Procédé de génération de contrôles de cohérence, caractérisé en ce qu'il met en oeuvre le procédé selon l'une des revendications 1 à 6, chaque noeud représente une règle de contrôle de cohérence appliquée sur un élément de modèle particulier. 10. Procédé de représentation et de génération de diagrammes, caractérisé en ce qu'il met en oeuvre le procédé selon l'une des revendications 1 à 6, l'imbrication graphique (exemple: classes dans un package, attributs dans une classe) étant représentée par la structure hiérarchique des noeuds, c'est-à-dire par l'arbre, chaque noeud représentant un élément de modèle affiché et possédant les propriétés graphiques que l'on veut représenter. 11. Procédé de représentation et de génération de documents XML, caractérisé en ce qu'il met en oeuvre le procédé selon l'une des revendications 1 à 6, chaque noeud représentant un élément ou groupe d'élément cible XML. 12. Procédé selon la revendication 11, caractérisé en ce que les actions comportent notamment le balisage et/ou la référence à un autre élément XML. 13. Procédé de représentation et de génération automatisée d'interface homme machine, caractérisé en ce qu'il met en oeuvre le procédé selon l'une des revendications 1 à 6, les fenêtres étant un type de cible, un arbre définissant une structure hiérarchique des fenêtres.