FR2900748A1 - Accelerateur du developpement logiciel - Google Patents

Abstract

La présente invention se rapporte Procédé de fabrication d'un logiciel comportant une première étape de définition d'un modèle et des étapes de génération de composants numériques comprenant au moins des composants logiciels, lesdits composants numériques héritant de caractéristiques et propriétés dudit modèle,caractérisé en ce que :- l'étape de définition dudit modèle consiste à construire, selon un méta modèle préexistant structuré en XML, une représentation numérique métier spécifique structurée en XML, définissant l'intégralité des entités du métier, leurs propriétés et leurs relations décrites selon les règles dudit méta modèle,- une étape de paramétrage des générateurs de composants numériques se fait au sein d'un même flux XML selon les règles dudit méta modèle,- une étape d'interprétation du modèle consiste à construire pour le modèle ainsi défini une représentation-objet des éléments décrits dans ledit modèle, ladite représentation comprenant des éléments calculés à partir du contenu dudit modèle et de règles de déduction implicite, ladite étape d'interprétation préparant l'activation des générateurs de composants numériques,- une étape de génération des composants numériques consiste à activer lesdits générateurs de composants préalablement paramétrés, prenant en entrée la représentation-objet précédemment décrite et produit en sortie des composants numériques, incluant des programmes directement exécutables et des codes sources personnalisables.

Description

Accélérateur du développement Logiciel

La présente invention se rapporte au domaine des procédés industriels pour la construction d'applications informatiques. Elle repose sur une usine logicielle virtuelle, conçue comme un service hébergeable et dont l'entrée est un modèle formalisé selon un méta-modèle spécifique décrit comme élément de l'invention.

On connaît dans l'état de la technique le plus proche le brevet américain US2005/0198618 décrivant un atelier de génie logiciel prévoyant un processus d'interaction avec les utilisateurs, basé sur une approche et des outils spécifiques. Ce document décrit un procédé de fabrication d'un logiciel comportant une première étape de définition d'un modèle et des étapes de génération de composants numériques comprenant au moins des composants logiciels, lesdits composants numériques héritant de caractéristiques et propriétés dudit modèle.

L'état de la technique comporte différents points-clé qui constituent l'état de l'art maîtrisé en matière de développement d'applications d'informatique de gestion, et rappelés pour la plupart dans le document précité : - Des méthodologies de développement éprouvées comme Merise , Yourdon , Booch , qui incluent toutes des approches de modélisation des entités métiers. - Des techniques de modélisation diverses incluant en particulier le modèle entité-relation maîtrisé depuis fort longtemps avec les notions de cardinalité attachées : relations 1:1, 1:Many, Many:Many. -L'utilisation des bases de données relationnelles et de leurs capacités en matière de gestion données, incluant le stockage et les traitements fortement liés aux données : notions de tables, d'attributs, de clé, de relations d'intégrité, d'index et de procédures stockées. - La popularisation de la bureautique . utilisation de données dans des documents sur poste de travail ou dans des tableurs permettant la manipulation par l'individu. - L'avènement de la programmation objet et de ses concepts introduisant en particulier le découplage des éléments manipulés en mémoire de la base de données, et introduisant les concepts fondamentaux d'encapsulation, d'abstraction et d'héritage. - La banalisation du développement multi-tier (d'abord 2-lier puis 3-lier puis N-lier) avec la possibilité de répartir les traitements sur différentes machines (avec une évolution du client-serveur aux traitements distribués). - Le développement des technologies Internet et du Web, tout d'abord utilisées pour le partage documentaire basé sur le protocole http, puis intégration dans le modèle Internet des modèles distribués évoqués au point précédent - L'orientation de l'industrie vers le passage au Web programmé avec l'apparition des Services Web, un standard de l'industrie permettant aux applications de communiquer entre elles sur les protocoles du Web, grâce au développement et à la standardisation autour du format XML, par nature ouvert à la description de n'importe quel type d'élément et fournissant l'indépendance vis-à-vis des plates-formes matérielles et logicielles. - L'évolution globale vers les architectures orienté services avec des démarches pilotées par les modèles (Model-Driven Application) permettant un découplage des applications et une emphase sur les flux et les contrats d'interface, cette évolution ayant lieu à la fois au niveau technique et au niveau des modèles de commercialisation des logiciels (on utilise parfois le terme de Software as a Service ). - L'apparition d'UML en tant que langage pour représenter les modèles mais présentant des limites à cause de sa complexité et de l'impossibilité de passer automatiquement d'un modèle à des composants logiciels directement utilisables (explicité dans le document de référence). - L'émergence de plusieurs plates-formes d'implémentation mises en oeuvre sur le marché dites Middleware , chacune apportant sa propre réponse par rapport au développement distribué en matière de problématique transactionnelle, de gestion de la concurrence, de montée en charge, etc... Cette solution de l'art antérieur impose la description d'un modèle métier à partir du système décrit. Il ne permet pas de dissocier la modélisation du métier, à partir d'outils et de méthodes quelconques, et la génération d'une application basée sur ce modèle. Cette solution est basée sur une aide à la définition des besoins utilisateurs, à partir d'un générateur assisté, facilitant le développement d'application, mais est intrinsèquement limitée par la mise en oeuvre des outils spécifiques du système. La présente invention vise à remédier à cet inconvénient en proposant une solution dissociant la modélisation métier, et la mise en oeuvre du modèle pour la génération des composants numériques, en introduisant un méta-modèle conçu à la fois pour permettre cette séparation et pour permettre la génération automatique des de composants logiciels.

Cette solution est proposée sous la forme d'un procédé industriel rigoureux permettant de garantir la cohérence d'utilisation des concepts évoqués dans l'état de l'art, afin d'obtenir au meilleur coût et dans des délais prévisibles, une application de qualité, performante et maintenable dans le temps. Elle permet de concevoir et réaliser des applications à partir de modèles métiers, à l'aide d'un système basé sur un méta-modèle et des générateurs de composants commandés par le modèle défini par l'utilisateur, éventuellement avec des outils externes, découplés du système objet de l'invention.

A cet effet, l'invention concerne selon son acception la plus générale un procédé de fabrication d'un logiciel comportant une première étape de définition d'un modèle, et des étapes de génération de composants numériques comprenant au moins des composants logiciels, lesdits composants numériques héritant de caractéristiques et propriétés dudit modèle, caractérisé en ce que : - l'étape de définition dudit modèle consiste à construire, selon un méta modèle préexistant structuré en XML, une représentation numérique métier spécifique structurée en XML, définissant l'intégralité des entités du métier, leurs propriétés et leurs relations décrites selon les règles dudit méta modèle, - l'étape de paramétrage des générateurs de composants numériques se fait au sein d'un même flux XML selon les règles dudit méta modèle, - l'étape d'interprétation du modèle consiste à construire pour le modèle ainsi défini une représentation-objet des éléments décrits dans ledit modèle, ladite représentation comprenant des éléments calculés à partir du contenu dudit modèle et de règles de déduction implicite, ladite étape d'interprétation préparant l'activation des générateurs de composants numériques, - l'étape de génération des composants numériques consiste à activer lesdits générateurs de composants préalablement paramétrés, prenant en entrée la représentation-objet précédemment décrite et produit en sortie des composants numériques, incluant des programmes directement exécutables et des codes sources personnalisables. Dans un mode de réalisation le méta-modèle est structuré selon un schéma XML spécifiquement conçu pour pouvoir générer la totalité des composants directement exécutables, le schéma XML comprenant une définition des entités, des attributs, les énumérations mono et multivaluée, les relations 1 à 1, 1 à N, N à m (exprimées par des propriétés), les relations d'héritage.

Dans une autre variante, le méta-modèle permet l'expression de fonctionnalités de chargement d'information à partir d'un langage de description de requête basé sur une syntaxe spécifique.

Dans un autre mode de réalisation, les règles de déduction implicite comprennent : - la définition par défaut de la clé d'une entité en fonction de la première propriété de ladite 10 entité, - la détermination par défaut du type des propriétés (format chaîne par défaut, format date si le nom se termine par Date , format booléen Si le nom commence par Is ou Has ), 15 - la définition implicite d'une classe de collection pour chaque entité, - la définition implicite de méthodes de chargement de données en fonction des relations entre entités. 20 Dans une autre variante, les générateurs de composants comprennent des modèles de composants prédéfinis, distincts des modèles métier, lesdits modèles prédéfinis présentant des parties statiques et des parties programmées permettant l'injection d'éléments du modèle 25 métier.

On comprendra mieux l'invention à l'aide de la description, faite ci-après à titre purement explicatif, d'un mode de réalisation de l'invention, en référence aux 30 figures annexées .

- la figure 1 illustre le procédé se rapportant à l'invention, - la figure 2 illustre l'architecture d'un mode de réalisation CodeFluent (nom commercial), - la figure 3 illustre un mode de réalisation de l'invention dans une architecture globale.

La figure 1 présente un procédé de l'invention reposant sur une approche en quatre. Les étapes 1 et 2 sont potentiellement menées en parallèle avec comme objectif de définir un flux XML commun alimentant une troisième étape d'interprétation qui permet ensuite la fabrication de composants sur la base de l'étape 4 de génération. Dans la figure 2 la description du modèle XML incluant les étapes 1 et 2 de la figure 1, à l'aide d'un procédé de saisie quelconque (création manuelle d'un fichier ou utilisation d'un outil graphique spécifique de conception). CodeFluent (nom commercial) met ensuite en oeuvre le procédé en appliquant les règles de déduction pour fabriquer une représentation objet en mémoire du modèle et activer les générateurs de code. Ainsi . - un générateur est chargé de produire les tables et procédures stockées de la base de données, - un générateur est chargé de produire les classes métiers représentant les objets non visuels en mémoire, - des générateurs sont chargés respectivement de produire les services Web d'exposition de ces objets sur les protocoles d'Internet, l'un d'entre eux étant 30 spécifiquement orienté pour l'intégration avec les tableurs bureautiques, - des générateurs sont chargés de produire les éléments d'interface utilisateur, fenêtres et contrôles, pour les applications classiques et Web, - des générateurs additionnels peuvent être 5 mis en oeuvre pour générer de la documentation sur le modèle ou l'application informatique qui le met en oeuvre.

Dans un mode de réalisation, l'invention se rapporte à un procédé de fabrication de logiciel appelé 10 CodeFluent (nom commercial) comprenant un moteur d'interprétation d'un méta modèle et incluant des générateurs de composants numériques appelés producteurs. L'invention offre la possibilité de créer ses propres producteurs. 15 Ce procédé dans une première étape permet de définir un modèle métier selon une description entièrement réalisé en XML. Cette description formalise les éléments du métier suivant . - les entités, - les propriétés, - les énumérations mono ou multivaluées, - les liens d'héritage simple entre entités et, - les relations de différentes cardinalité entre lesdites entités.

Dans l'exemple utilisé, on souhaite réaliser une application de gestion de location de véhicule. Cela va 30 nous amener à utiliser en particulier les éléments compris dans le tableau (auquel on pourra se référer pour les éléments rencontrés par la suite) suivant: 20 25 Eléments constitutifs Définitions du flux XML Address Entité correspondant aux adresses des clients gérés par le loueur AgeCheck Règle de vérification de l'âge du conducteur BirthdayDate Propriété de l'entité Client contenant sa date de naissance Branch Entité correspondant aux agences du réseau de location Egalement, propriété de l'entité RentalAgreement faisant référence au client du contrat Car Entité correspondant aux voitures gérées par le réseau de location de véhicules CarOptions Type spécifique correspondant aux options pouvant être prises dans le cadre d'un contrat de location cf:configuration Syntaxe de déclaration des paramètres de configuration d'un producteur de la réalisation CodeFluent (non commercial) cf:import Syntaxe de déclaration d'une clause d'import pour fusionner un fichier XML additionnel au sein du fichier courant dans la réalisation CodeFluent (non commercial) cf:method Syntaxe de déclaration d'une méthode dans la réalisation CodeFluent (non commercial) cf:producer Syntaxe de déclaration d'une étape Io correspondant à un producteur dans la réalisation CodeFluent (non commercial) Coverage Entité correspondant aux couvertures d'assurance pouvant être affectées aux contrats de location Customer Entité correspondant aux clients louant des voitures Duration Durée de la location (calculée) FirstName Propriété de l'entité Client contenant son prénom HasPreAccidents Propriété de l'entité Client contenant un indicateur oui/non d'antériorité d'accident Id Propriété identifiant de type numérique servant à repérer de manière unique une instance d'entité Inventory Entité correspondant aux inventaires de véhicules réalisés périodiquement LastName Propriété de l'entité Client contenant son nom Line 1, Line 2, City, Propriétés d'adresse Country, Zip PayType Type spécifique correspondant à un mode de paiement disponible pour le métier RentalAgreement Entité correspondant aux contrats de location gérés par le loueur TotalPrice Propriété de l'entité RentalAgreement contenant le montant total du contrat Truck Entité correspondant aux camions gérés par le réseau de location de véhicules Dans le modèle XML métier appartenant au domaine de la location de véhicule de transport, les entités correspondent aux voitures (Car), camions (Truck), clients (Customer) ou contrats de location (RentalAgreement). Ces entités représentent les éléments qui seront gérés par l'application informatique final qui sera réalisée et générée par le procédé. En particulier on retrouvera les tables correspondant à ces entités au niveau de la base de données qui servira à stocker les données de l'application.

Les propriétés seront par exemple pour l'entité client, le nom ( LastName dans le modèle choisi) et le prénom ( FirstName dans le modèle choisi), correspondant généralement à des colonnes d'une table de la base de données. Ces propriétés représentent les valeurs spécifiques qu'une instance d'entité peut porter. Certaines propriétés sont de type basique (types classiques et connues dans le domaine de l'informatique), d'autres sont de type spécifique. Les propriétés de type spécifique sont définies par l'application ou par le domaine métier auquel ils se rapportent et sont créés explicitement pour les besoins de l'application comme dans le cadre d'un mode de paiement qui est une énumération de valeurs possibles définie par le métier de l'application. Pour un client (entité Customer dans le modèle choisi), les propriétés de type basique peuvent être : - int qui correspond à un entier, utilisé par exemple comme numéro identifiant permettant de retrouver le client, - chaîne ou string pour les propriétés 5 EmailAddress, FirstName, LastName , qui correspond à des chaînes de caractères, - datetime pour une propriété BirthdayDate , qui correspond à un format temporel incluant une date et une heure, 10 - boolean pour une propriété HasPreAccidents , qui correspond à une valeur de type vrai/faux.

Les propriétés de type spécifiques pour cette 15 même entité client ( customer ) peuvent être : - PayType , de type spécifique PayType , pour une propriété correspondant au mode de paiement habituel d'un client, les modes de paiement étant définis spécifiquement pour l'application, 20 - Rentals , de type spécifique RentalAgreementCollection exprimant une relation vers l'entité contrat de location ( RentalAgreement ), pour la propriété permettant de manipuler (consultation, création, modification, suppression) les contrats de location dudit 25 client.

Dans le modèle XML métier, l'entité client Customer est donc décrite avec ses propriétés de type basique et spécifique de la façon suivante : <Il tvz>eName="int" 30 <,En ail d dr e.,,-> typeN am =",->trizlgn FirstName t\-pName=" tring LastNan peNam ="string" B1 rth._ ayDate typeName "c_fatetime' at: mentType typeName="PayType Nias e ci_ents t\-pName="1_ entai tF -Name="RentalAgreement(." l les t i n" i _st >me Plus généralement, les types spécifiques permettent de définir des listes de valeurs ou énumérations valables pour une propriété. La déclaration d'une balise se terminant par Enum comme PayTypeEnum crée une définition de type PayType avec une liste de valeurs possibles, dans le cas présenté : Cash (pour le paiement en espèces), CreditCard (pour le paiement par carte bancaire) et Check (pour le paiement par chèque) Le type spécifique PayType est décrit dans le modèle par l'élément suivant : PPatiTypeEnum Flaq "fraise De manière générale, les listes de valeurs spécifiques pour le domaine métier sont définies et appelées des énumérations mono ou multivaluées. Le type spécifique des options retenues par le client dans le contrat de location est une énumération multivaluée (c'est-à-dire que le client peut à la fois demander l'option GPS (Système de positionnement par satellite) et un siège pour enfant). Un type multivalué est défini en ajoutant la propriété flags à true lors de la déclaration de l'énumération. C'est le cas du type CarOptions utilisé par l'entité RentalAgreement

)ticcnsEnum tla 'true mer typeNallle="I_~uSturner 15 'Car t\.-peName="p ar" ar mpti n._ t\ peName="CarOption IotalPrice tvpeName=" _ ecimal' nta1 cfreement

20 Dans ce cas, une propriété basée sur ce type pourra prendre plusieurs valeurs simultanément. Ces énumérations se retrouvent au niveau de l'application finale comme des listes de choix possibles (multiples si l'énumération est multivaluée) que l'on peut rencontrer 25 dans un formulaire sur une interface de saisie.

Chaque entité est libre de combiner des propriétés de types basiques et spécifiques, les types spécifiques devant êtres décrits au sein du modèle métier. Quand une entité comme Car fait l'objet d'un contrat de location, il y a une relation entre les entités Car et RentalAgreement (entité correspondant au 30 contrat de location dans notre modèle de location de véhicule). Cette relation permet par exemple de retrouver un véhicule faisant l'objet d'un contrat ou bien les contrats portant sur un véhicule donné.

Cette relation correspond à des relations binaires comprenant les besoins de cardinalité les plus courants, à savoir les relations 1:1, 1:N et N:M. L'invention offre la possibilité d'utiliser une propriété de l'entité comme porteuse de la relation vers l'entité cible. Ceci permet d'envisager une génération automatique d'éléments directement manipulables au niveau du code logiciel. Une relation 1:1 est utilisée entre les entités Customer et Address . Il y a une relation un pour un entres les deux entités mais ces notions sont gérées séparément dans l'application. Cette relation s'obtient simplement en déclarant une propriété de type Entité 2 sur 1' Entité 1 et inversement. La seule référence mutuelle des entités permet au système de déduire l'existence d'une relation 1:1 entre les entités. Comme illustré dans l'exemple suivant : u _s t o Ille r . [ ... ] ~1dr ess type Name "T_d dres ," [...] S'us bique d(fi t ~etTvpe "tist"> untry30 Cll; _merypeNaI e n('11 Ç=mer il re

Pour une relation 1:N l'utilisation d'une propriété de type Car sur l'entité RentalAgreement et d'une propriété de type RentalAgreementCollection sur l'Entité Car permet dans notre exemple de spécifier qu'un contrat de location porte sur une unique voiture et qu'une voiture peut faire l'objet de plusieurs contrats de location (la notion de collection étant implicitement construite pour toute entité du modèle comme évoqué dans les règles de déduction implicite). De manière générale une relation de type 1:N entre Entité 1 et Entité 2 s'obtient en déclarant une propriété de type Entité 2 sur l' Entité 1 (dans notre exemple, Entité 1 est RentalAgreement, et Entité 2 est Car). La déclaration d'une propriété de type collection d'entité 1 sur l'entité 2 est possible pour permettre la manipulation des entités 1 liées à l'entité 2 (comme la déclaration de la propriété Rentals dans l'exemple pris), mais non obligatoire. Le fait de la déclarer explicitement permettra surtout de pouvoir accéder par programmation aux contrats de location du client par une syntaxe de type Customer.Rentals . Cette relation est décrite dans le modèle par la simple présence des propriétés suivantes .

[ ... ] Rentals ypeName="Kemal greementCc_ll

<.Rental 'c eeITlent ar t ypeName= .ar,"

RêntalAC(reeITlent= Comme précisée précédemment, l'absence de déclaration de la propriété Rentals aboutirait à la même interprétation de relation. L'intérêt d'expliciter cette propriété est de permettre la manipulation des contrats de location depuis l'entité Customer .

Concernant la relation N:M dans notre modèle de location de véhicule, nous voulons par exemple permettre à un contrat de location de proposer plusieurs couvertures d'assurance, tout en permettant naturellement à une option de couverture d'assurance d'être utilisée par plusieurs contrats de location. Il nous faut donc une relation multiple dans les deux sens. Cette relation est mise en oeuvre dans le mode de réalisation par l'utilisation d'une propriété Coverages de type CoverageCollection sur l'entité RentalAgreement et d'une propriété Rentals de type RentalCollection sur l'entité Coverage . Ceci est illustré dans le modèle de la manière suivante : Rental .gréement [ ... ] erages ty peNaIne= : er ageCc.:1le tien [ ... ] Rental Acfreement

-_ erag Rental,, Name-" IltalC lie[. ti n" -[[e)

orage Cette relation est de manière générale décrite par l'utilisation d'une propriété de type Collection d'Entité 2 sur l' Entité 1 et inversement. Comme précisé plus haut pour les relations 1:N, si une propriété n'est déclarée que sur une seule des entités, la relation est interprétée comme de cardinalité N du côté de l'entité qui ne contient pas de propriété spécifique vers l'autre entité. On pourrait donc n'avoir que la propriété Rentals sur Coverage ou Coverages sur RentalAgreement et cela aboutirait à la même cardinalité pour cette relation.

Dans de nombreux scénarios métiers, il est utile de pouvoir décrire plusieurs relations entre les mêmes entités. Dans le cadre du contrat de location Rental Agreement celui-ci est lié à l'agence Branch par trois relations. En effet, sur le contrat, on distingue l'agence de prise en charge du véhicule, l'agence de retour prévue, et l'agence de retour réel du véhicule.

Pour lever les ambiguïtés sur la correspondance de propriétés entre celles qui sont situées sur RentalAgreemeent et sur Branch , on utilise un attribut relationPropertyName sur ces propriétés explicitant la propriété correspondante dans l'entité cible. Dans le modèle suivant on a un exemple de scénario: < entalAceemee> [...] <Pl kupBraech typeName= Branchu relaìc2 ?pertyName"2ickedUp?eutai: ctualReturnBraech ypeName= Branchu iaì?e ?pertyNameuRetureedRentais"/ cheduledReturnBranon typeName"Branchu iain R pe ỳNameu3oneduledReeàls <Branch <1 ! <Name ?? ie?ì?e e?"t ce" [...] <Pic JUp?eeàls yi Name"Rectal g eemee??11 i ìnPr pe \Name"2ickepBranch" <ReturnedReeàis 20 yi Name"?e utalmgreementCollectia1 iaìnPropertyName" ctualReturnBranonu ,oneduledReetais ypeName"?e utalAgreementCollectianu rRistionPrupertyName"3c1eduledReturnBraechu 25 /Branc1

D'autre part l'invention propose d'autres types de relation comme les relations d'héritage. Elles peuvent 30 être définies entre deux entités métier. Une entité Truck (correspondant au véhicule de type camion dans notre modèle) dérivant de l'entité Car disposera de toutes les propriétés de celles-ci, en plus des propriétés 10 15 supplémentaires qui peuvent lui être définies, comme le poids (propriété Weight ). L'héritage permet d'offrir des propriétés et méthodes communes entre plusieurs entités. Elle se définit dans le modèle XML de la façon suivante avec baseTypeName la relation d'héritage entre les entités Car et Truck et la propriété supplémentaire Weight qui est de type float

,::Truck b seTvpeN Mme="~~" ~i Weight t TpeName="flot" 'Truck>

Sans la relation d'héritage, les propriétés de l'entité Car auraient dû être redéfinies au niveau de l'entité Truck dans le modèle XML.

Au-delà de la description des données, une application nécessite la mise en oeuvre de traitements (chargement d'entités, calcul...), que nous appellerons ici méthodes .

Le procédé dans le cadre de son fonctionnement offre un langage de requête simplifié permettant de décrire des méthodes spécifiques à une entité, notamment les méthodes de chargement, telles que : - Celles qui sont centrées sur les données, - Celles qui appartiennent directement à l'entité porteuse de la méthode (celle sur laquelle on déclare la méthode), - Celles qui utilisent des entités liées par des relations plus ou moins directes et complexes.

Pour un contrat de location (entité RentalAgreement ) comprenant une méthode de chargement spécifique permettant de chercher les contrats par date de prise en charge des véhicules (propriété PickupDate ) et prénom du client (entité FirstName ), ordonnées par le nom de la catégorie du véhicule. La date de prise en charge est disponible au niveau de l'entité porteuse de la méthode (entité RentalAgreement sur laquelle la méthode est déclarée), alors que le prénom est obtenu en naviguant dans le modèle au travers du client, ce qui nécessite d'expliciter la propriété par Customer.FirstName. Par contre, il n'est nul besoin de préciser au niveau de la méthode comment le lien est effectué entre les entités Customer et RentalAgreement , le procédé le déduisant en fonction des relations du modèle. Tout ceci est décrit dans le modèle par l'élément XML suivant: t : metl- _. _ naine= Lc_ c B\.-PiCkupDate" ly="l:_.ad (PickupDate, , trirng FirstName) uhere PickupDate = @PickupDate and Cu s torer. FirtName = @FirstName zder ustorer . LastName'

La syntaxe du langage simplifié utilisé est proche du langage SQL. Elle permet de spécifier des paramètres à la méthode de chargement et de manipuler des entités liées au niveau du modèle ( Customer, Car, CarGroup ). De cette façon, l'invention offre une plus grande simplicité de mise en oeuvre d'autant plus que par rapport au langage SQL, aucune jointure n'est déclarée, des générateurs de code ayant les moyens nécessaires pour déduire les jointures à effectuer grâce aux relations comprises dans le modèle XML pour fabriquer la procédure stockée adéquate dans la base de données.

Un contrat de location qui porterait une propriété durée ( Duration dans notre modèle de location, de véhicule) obtenue par un simple calcul de différence entre les dates de retour et de prise en charge (c'est à dire entité ReturnDate moins l'entité PickupDate ) introduit la notion de méthode spécifique à une entité. C'est une méthode dont lanature est plus liée à un traitement fonctionnel de type calcul traduite directement par du code logiciel, encore appelé Snippet . On introduit ce code directement sous une balise de type <cf:method> comprise dans l'entité sur laquelle porte la méthode spécifique.

:mette d n m "Durati mette !!_ TVp ": nlppet"- "MAT [ pub_ 11c tem. Time pda Duration retour (ReturnDate - PickupDate ct.methoci Cette approche de mise en oeuvre est adaptée aux méthodes fonctionnelles simples.

30 Des méthodes spécifiques à une entité peuvent aussi faire appel à un composant externe (ici CodeFluent.Runtime.Rules.Method, CodeFluent.Runtime.Rules constitue le nom du composant25 externe) réalisant l'exécution d'un traitement spécifique, par exemple la vérification d'une règle métier gérée par un système externalisé de l'application et maintenu par les utilisateurs métiers. t . methcd n atme =...e Che c k" tvpeName="C . de Fluent . Runtime . Rul e s . Met1-1::d" returnl peName="int" 1 1v="rule (Cu t )Iller) etting name="Rule ,etTvpeName" value="CarRentalBj et :Illet1îc._. On suppose dans l'exemple l'existence d'un jeu de règles nommé CarRentalBizProj dans un système de gestion de règles, incluant la méthode AgeCheck pour 15 vérifier l'âge du conducteur selon des critères définis dans ce système. Cette approche de mise en oeuvre est adaptée aux méthodes fonctionnelles plus complexes implémentant des règles de gestion en dehors des applications elle-même. L'appel au système de gestion de 20 règles passe par un composant spécifique de type CodeFluent.Runtime.Rules.Method .

Dans une deuxième étape le flux XML comprend une description relative à la définition du paramétrage de 25 générateurs de composants numériques. Cette description permet la configuration de générateurs pour y préciser : les niveaux de génération et leur ordre, les producteurs de composants à activer ainsi que les paramètres à passer à chaque producteur incluant les répertoires de sortie des 30 éléments produits. De cette façon, les options de production des composants sont ainsi définies à cette étape. La description des paramètres de génération se fait par la déclaration des différentes étapes de génération. 10 Le processus de génération est constitué d'étapes qui correspondent à l'activation d'un producteur à partir de paramètres précisés au sein du flux XML. La présence dans le flux XML d'une balise de type cf:producer (<cf:producer>) permet d'identifier la description d'une étape de génération. Cette balise comprend différente propriétés. Par exemple, la propriété sortOrder précise l'ordre d'exécution et le typeName précise le producteur qui sera utilisé. A l'intérieur de la balise cf:producer, une balise de type cf:configuration décrit l'ensemble des paramètres pour cette étape, comme par exemple de manière non limitative : la création de l'environnement Web, le langage de programmation cible, le nom du composant final et les répertoires de génération.

Cette étape de génération se présente dans le flux XML suit :

du c e r der-rr n rT enabled='Tt1uerr typeName=rrC deFluent. Pr .du .ers . ~_ odeEiDm. TII. J _b.WebSer. i cePr. ducer deFluent. Pr. uce1 . !._ . deDcmrr 1t igurat1OI1 1ter,.,7irtualRÇ_::C.::•t="true" deDemPr vider /peNameù"c3harp' cutputName "Soit Fluent (arRenta1. Web . Servi ce dli rr targetRirecto "=rr \ eneratedNP7 '\ urce Itiguration> Pour préserver l'existence d'un flux XML unique alimentant la génération du code, tout en facilitant la séparation dans des fichiers distincts de la fabrication du modèle métier et des paramètres, le procédé prévoit l'utilisation d'une technique d'import d'un fichier XML dans un autre, permettant le remplacement également de paramètres à la volée lors de l'étape de constitution du flux XML. Cette technique d'import intelligent permet ainsi de fusionner les fichiers à la volée. On peut utiliser un paramétrage général des options de fabrication et l'appliquer au modèle de location de véhicule CarRental . 1I11pOrt path="lroduce r > . xml" _ er tirite="true" outputPath=" i O . xml"> :parameter xpath=" =an _ rc t I1dReplace\. al le" nome=" pst ndardNS " valise-Rental" imp rt

Cette technique peut par ailleurs permettre de réutiliser un morceau de modèle quelconque au sein d'un autre. Par exemple, on pourrait disposer d'un modèle de gestion de relation client, qu'on importerait à la fois dans une application de gestion de location de voitures et dans une application de gestion de magasin.

On peut noter que l'invention permet la création d'autant de producteurs que nécessaires, ceux-ci pouvant être activés comme des étapes de génération et utiliser les informations du modèle métier dont ils ont besoin. Un producteur peut utiliser les attributs définies par le méta-modèle de base ainsi que des attributs spécifiques qui ne sont pas prévus au niveau du méta-modèle de base fourni. A partir du format XML des attributs supplémentaires peuvent être ajoutés. Le modèle représenté en mémoire et qui active les producteurs expose les attributs supplémentaires aux producteurs spécifiques qu'il active. On peut avoir par exemple un producteur spécifique générant de la documentation sur le modèle métier décrit et utilisant des propriétés supplémentaires introduites pour ce producteur.

Dans une troisième étape l'ensemble décrit dans le flux XML est interprété pour constituer une représentation-objet en mémoire. Cette représentation comprend l'ensemble des éléments décrits au niveau du modèle (selon les deux étapes de description du modèle métier et des paramètres de génération). De plus des règles de déduction implicite sont associées à cette interprétation dans le cadre du traitement des applications. Ces déductions implicites permettent de caractériser la nature de certaines relations. Cette interprétation induit l'existence d'un lien symétrique entre deux entités par deux propriétés ayant chacune le type de l'autre par une relation 1:1. Si une seule propriété existe de 1' Entité 1 vers l'Entité 2, alors le procédé interprète la relation comme une relation 1:N. En prenant par exemple l'entité Car qui contient une propriété de type CarGroup sans qu'il y ait de retour de CarGroup vers Car , on déduit qu'elle dispose d'une relation 1:N vers l'entité CarGroup . De plus l'entité RentalAgreement dispose d'une relation N:M vers Coverage car elle contient une propriété de type CoverageCollection sans qu'il y ait de retour vers RentalAgreement dans l'entité Coverage . De plus, le procédé déduit automatiquement, que les liens spécifiés des deux côtés sont les deux extrémités d'une même relation. Dans l'exemple ci-dessous, la propriété 5 10 15 20 2eetals de type RentalAgreementCollection de l'entité Car exprime la même relation que la propriété Car de type Car de l'entité 2eetal .

<Rentai freement> <IJ : Òrner ỳpeName ?estomer" <PickupBraech typeName"Branch" <âeduledReturnBranch typeName"Braech" 7tua1ReturnBraech tvpeName"Branch" kupDate typeName"Jatetime" typeName"?a " erages typeName"?e erage(o11E /RentalAc eement>

<id /> <@inDay3 tyy,eName"iet" ehicl Type .?ehicleStatus tvpeName"'ehicu1eSatus" <?arGr up typeName EarGrcu <?epairs typeName"?arRegairCollection" ?entais ypeName="?ental greementCollecti eriaiNu ,e unique"truc" 25 30 <i <Same/ KLarLroup> <?? erage> <ic / <cade <Same rag

On voit bien dans cet exemple que les relations peuvent être intuitivement déduites. Une voiture (Car) étant attachée à une catégorie de voiture (CarGroup), il est naturel qu'une catégorie puisse disposer de plusieurs véhicules. Il en va de même pour la possibilité d'un contrat d'assurance (Coverage) qui peut être utilisé pour plusieurs contrats.

D'autre part, les règles de déduction implicite permettent également de faciliter l'industrialisation en interprétant par défaut l'absence de spécification comme étant le cas le plus fréquent. Dans l'exemple ci-dessous pour l'entité Coverage, le premier champ avec la propriété Id correspond à la clé. Il s'agit d'une déduction implicite, qui se fait lors de l'interprétation du modèle sauf mention contraire. De même, les deux autres propriétés Code et Name sont de type chaîne , en l'absence d'une propriété typeName explicitement spécifiée. era, 30 Des méthodes spécifiques peuvent être décrites au niveau du modèle. Les règles de déduction implicite permettent la génération automatique d'un nombre important de méthodes incluant : 28 <. 25 - Les méthodes CRUD classique (Create, Read, Update, Delete), c'est-à-dire les méthodes de création, de lecture, de mise à jour et de suppression d'instances d'entité. - Les méthodes de chargement de données en fonction des relations décrites. Dans notre exemple, une méthode de chargement des contrats de location par client sera créée, ainsi qu'une méthode en fonction de la voiture louée, et ce pour chaque relation déduite sur l'entité considérée.

Dans une quatrième étape, la génération des composants numériques a lieu selon l'interprétation effectuée à l'étape 3d du procédé, par l'activation des producteurs de composants. Ces producteurs peuvent générer : - des composants logiciels exécutables prêt à l'emploi par l'activation d'un producteur de code capable de générer du code source compilable mettant en oeuvre les propriétés et les méthodes précédemment décrites et interprétées. Dans un mode de réalisation, les producteurs de code génèrent des classes métiers et des services Web, sous forme de code source et compilent ces codes sources pour produire des composants binaires directement utilisable, - des codes sources personnalisables par l'activation d'un producteur de code capable de générer du code source en préservant une région marquée comme protégée du générateur, et ce afin de préserver son contenu d'une génération sur l'autre. Dans un mode de réalisation, si à l'issue des premières générations, du code source est ajouté dans une région déclarée comme GenerationSafe (il s'agit là d'une syntaxe spécifique conventionnelle utilisée par le procédé), ce code sera préservé à la prochaine génération. Ce procédé permet de combiner génération automatique et mise en oeuvre de code spécifique, - d'éléments numériques selon un modèle dual incluant en son sein à la fois du code et du contenu par l'activation d'un producteur de code capable de générer des éléments numériques quelconques en utilisant une approche de modèle combinant des parties statiques et des parties programmées. Dans un mode de réalisation, la génération d'une application Web manipulant les entités décrites ( Customer, Car, RentalAgreement ,...) est effectuée selon ce procédé. Le bénéfice est qu'il est possible de modifier certaines parties statiques au niveau du modèle de site web (par exemple les menus, le positionnement des zones de saisie, les feuilles de style, etc..) et d'obtenir la mise en oeuvre de ces modifications dans toute l'application.

La figure 3 propose un autre mode de réalisation dans lequel l'invention s'inscrit dans un dispositif permettant de produire de manière totalement automatisée des composants numériques en n'utilisant qu'un flux XML comprenant la description du modèle métier et la description des paramètres de génération. L'invention propose au travers d'Internet un ensemble de moyens autorisant la génération à distance de composants sur la base d'un fichier XML décrivant le modèle métier à mettre en oeuvre. L'unique besoin en paramètre du procédé de génération est constitué du flux XML constitué par le modèle et les paramètres de génération.

Dans ce cas, le flux XML est envoyé à un serveur Internet qui exécute les différentes étapes du procédé et retourne les composants générés selon les protocoles d'Internet (HTTP).

Ce dispositif peut correspondre à une usine logicielle distante , utilisée pour fabriquer des composants logiciels à la volée en fonction des modèles XML soumis. La mise en oeuvre du procédé selon ce mode apporte une innovation en matière de méthodologie de développement logiciel, puisque l'effort peut être concentré sur la spécification du modèle afin que la production des composants soit effectuée automatiquement. L'invention pourrait s'inscrire dans le cadre d'une usine logicielle virtuelle produisant à la demande des composants prêts à l'emploi sur la seule base de spécifications formelles traduites par le modèle.

L'invention est décrite dans ce qui précède à titre d'exemple. Il est entendu que l'homme du métier est à même de réaliser différentes variantes de l'invention sans pour autant sortir du cadre du brevet.

Claims (6)

REVENDICATIONS

1. Procédé de fabrication d'un logiciel comportant une première étape de définition d'un modèle et des étapes de génération de composants numériques comprenant au moins des composants logiciels, lesdits composants numériques héritant de caractéristiques et propriétés dudit modèle, caractérisé en ce que : - l'étape de définition dudit modèle consiste à construire, selon un méta modèle préexistant structuré en XML, une représentation numérique métier spécifique structurée en XML, définissant l'intégralité des entités du métier, leurs propriétés et leurs relations décrites selon les règles dudit méta modèle, - une étape de paramétrage des générateurs de composants numériques se fait au sein d'un même flux XML selon les règles dudit méta modèle, - une étape d'interprétation du modèle consiste à construire pour le modèle ainsi défini une représentation-objet des éléments décrits dans ledit modèle, ladite représentation comprenant des éléments calculés à partir du contenu dudit modèle et de règles de déduction implicite, ladite étape d'interprétation préparant l'activation des générateurs de composants numériques, - une étape de génération des composants numériques consiste à activer lesdits générateurs de composants préalablement paramétrés, prenant en entrée la représentation-objet précédemment décrite et produit en sortie des composants numériques, incluant des programmesdirectement exécutables et des codes sources personnalisables.

2. Procédé de fabrication d'un logiciel selon la revendication 1 caractérisé en ce que ledit méta-modèle est structuré selon un schéma XML spécifiquement conçu pour pouvoir générer la totalité des composants directement exécutables, le schéma XML comprenant : o une définition des concepts de base liés aux données du métier dont les entités, les propriétés et les énumérations mono et multi-valuée, ainsi que le lien d'héritage entre entités, o la formalisation des relations entre les entités sous forme de relations binaires de cardinalité 1:1, 1:N ou N:N avec l'utilisation d'une propriété porteuse de la relation au sein de chaque entité impliquée, o une description des méthodes spécifiques liées aux données à l'aide d'un langage de description de requête basé sur une syntaxe spécifique permettant d'exprimer les critères d'une méthode, et ce en incluant des propriétés d'entités liées indirectement à celle manipulée, o une description des méthodes spécifiques de type traitement à l'aide d'inclusion directe de code selon une technique dite de Snippet , o une description des méthodes spécifiques traitées par appel à un composant externe

3. Procédé de fabrication d'un logiciel selon la revendication 1 caractérisé en ce que ledit méta-modèle permet : o la description des générateurs à activer pour le modèle selon un schéma XML spécifiquement conçu pour pouvoir décrire les éléments à générer, l'ordre d'exécution et les paramètres de sortie, o l'utilisation d'une technique d'import avec remplacement dans le flux XML permettant de fusionner les fichiers à la volée et combiner ces paramètres avec le modèle, o la possibilité d'écrire ses propres générateurs par une architecture prévue au niveau du méta-modèle et grâce à l'extensibilité obtenue par construction à cause de la nature du format XML, permettant à un générateur d'utiliser des attributs qui lui sont spécifiques.

4. Procédé de fabrication d'un logiciel selon la revendication 1 caractérisé en ce que le modèle comprend une étape d'interprétation du modèle pour s'en faire une représentation-objet en mémoire, à l'aide de déductions implicites telles que : o la déduction des relations entre entités et de leur nature à partir des propriétés décrites sur les entités et référençant d'autres entités du modèle, o la déduction implicite d'éléments sur les propriétés : la clé d'une entité étant la première propriété, le type d'une propriété étant le format chaîne , en dehors d'une précision contraire explicitement exprimée au niveau du modèle,o la déduction automatique de méthodes de manipulation de données pour l'entité elle-même et en lien avec les autres entités en fonction des relations décrites au sein du modèle et permettant la navigation dans le modèle.

5. Procédé de fabrication d'un logiciel selon la revendication 1 caractérisé en ce que les générateurs de composants permettent : o la génération de composants logiciels directement exécutables et prêts à l'emploi o la génération de composants logiciels sous forme de code source personnalisable prévoyant des régions de code préservées par la génération o la génération d'éléments numériques quelconques selon une technique de modèle dual incluant un mélange d'instructions programmées et du contenu statique.

6. Procédé de fabrication d'un logiciel selon la revendication 1 caractérisé en ce qu'il est conçu comme un service autonome dont la seule information d'entrée nécessaire est un flux XML, et ce afin de permettre à ce procédé d'être un service hébergeable, exécutable à distance et pouvant constituer l'étape d'une démarche industrielle plus large dans laquelle il existe un besoin de production automatisée de composants numériques.