Brevet FR2891074A1 — publié le 20070323

Procédé de modélisation de systèmes logiciels comportant des composants L'invention concerne un procédé de modélisation de systèmes logiciels comportant des composants. En particulier, l'invention s'applique à la modélisation de systèmes logiciels distribués à base de composants dont la modélisation est indépendante de la plateforme technique d'exécution. La conception de systèmes complexes à base de composants logiciels nécessite des moyens pour décrire simplement et sans ambiguïté les responsabilités fonctionnelles et structurelles allouées à chaque composant logiciel. Plus précisément, la définition des interfaces pour un composant logiciel doit faire l'objet de la plus grande attention. En effet, les erreurs et les incohérences dans la définition des interfaces, comme par exemple les erreurs de nommage, sont fréquentes pendant la phase de conception des composants logiciels. De plus, dans un souci d'accroître sensiblement l'adaptabilité, la modularité et les possibilités de ré-utilisation d'un composant logiciel, la définition des interfaces doit permettre en outre de limiter les dépendances entre les composants logiciels. Par ailleurs, certains concepts, notamment ceux relatifs aux systèmes distribués comme par exemple les concepts d'accès distant ou local, doivent être pris en compte dès la phase de conception d'un composant logiciel. Cependant la modélisation de ces concepts ne doit pas reposer sur les spécificités d'une plateforme technique si l'on ne souhaite pas restreindre les possibilités de ré-utilisation ou d'adaptation d'un composant logiciel. Le langage de modélisation UML pour Unified Modeling Langage selon l'expression anglo-saxonne propose une sémantique de base pour répondre aux besoins de modélisation de composants logiciels. Cependant la sémantique de base d'UML ne suffit pas à exprimer les responsabilités entre plusieurs composants logiciels. En outre, la sémantique de base d'UML n'offre pas de concept: d'accès distant ou local ni de gestionnaire de données, et ne supporte que très partiellement les concepts de communication et de service asynchrone. Les profils standards pour UML sont principalement liés à une plateforme technique donnée. Ils induisent de plus une intrusion de concepts technologiques dès la phase de modélisation dommageable à la ré-utilisation et à l'adaptabilité d'un composant logiciel. Il existe par ailleurs des modèles de composants techniques logiciels comme par exemple CCM pour CORBA Component Model selon l'expression anglosaxonne ou encore EJB pour Enterprise Java Bean selon 5 l'expression anglo-saxonne. Cependant, ces modèles de composants techniques logiciels sont liés à une plateforme technique donnée. De plus, ils n'apportent pas de solutions quant à la modélisation de l'architecture. L'invention a notamment pour but de pallier les inconvénients précités. A cet effet, l'invention a pour objet un procédé de modélisation d'un système logiciel comportant des composants. Un langage de modélisation objet est utilisé pour décrire les composants logiciels du système logiciel. Le procédé selon l'invention comporte notamment les étapes suivantes: définition des rôles d'un composant par un ou plusieurs contrats métiers, un contrat métier décrivant le rôle des composants qui lui sont attachés, un des composants étant qualifié de fournisseur pour un rôle donné, les autres composants étant qualifiés de clients pour un rôle donné ; définition des contrats d'interface pour chaque contrat métier. En outre, les contrats métiers et les contrats d'interfaces peuvent appartenir au composant logiciel ayant le rôle de fournisseur. Avantageusement, les dépendances cycliques ou mutuelles entre 25 les composants sont interdites. Un des contrats métiers peut être un contrat de service permettant de décrire un modèle de requête-réponse entre un composant logiciel assurant un rôle de fournisseur du service et un composant logiciel assurant un rôle d'utilisateur du service. L'utilisateur du service peut demander l'exécution d'une des opérations dudit service. Un des contrats métiers peut être un contrat d'observation permettant de décrire un modèle d'observation entre un composant logiciel assurant un rôle de gestionnaire d'événement et un composant logiciel assurant un rôle d'observateur d'événements. L'observateur d'événement reçoit les événements qui ont pu être lancés par le gestionnaire d'événement. Un des contrats métiers peut être un contrat de configuration permettant de décrire un composant configurable au travers de propriétés entre un composant logiciel assurant un rôle de fournisseur configurable et un composant logiciel assurant un rôle de gestionnaire de configuration. Le gestionnaire de configuration manipule les données de configuration qui doivent être prises en compte par le fournisseur configurable. Un des contrats métiers peut être un contrat de publication entre un composant logiciel assurant le rôle de dépôt de données et un composant logiciel assurant un rôle d'éditeur de données. L'éditeur de données peut créer, lire, détruire ou mettre à jour les données enregistrés dans le dépôt de données. Un des contrats métiers peut être un contrat de souscription entre un composant logiciel assurant le rôle de dépôt de données et un composant logiciel assurant un rôle de souscripteur de données, le souscripteur de données recevant des données qui ont été créées, mises à jour ou détruites dans le dépôt de données et répondant à certains critères. Un des contrats métiers peut être un contrat de notification entre un composant logiciel assurant un rôle de gestionnaire d'événement et un composant logiciel assurant un rôle de source d'événements, la source d'événements envoyant des évènements au gestionnaire d'événement. Un des contrats métiers peut être un contrat d'extension permettant de décrire un modèle d'extension entre un composant logiciel assurant un rôle de fournisseur du service et un composant logiciel assurant un rôle de développeur de service, le développeur de service mettant à disposition du fournisseur de service ledit service. Avantageusernent, les contrats d'interface sont générés automatiquement à partir des contrats métier. Dans un mode de réalisation, la sémantique des contrats métiers 5 et des contrats d'interfaces est décrite par un profil du langage de modélisation unifié. L'invention a notamment pour avantages qu'elle permet de projeter le système logiciel distribué à base de composants sur une plateforme technique éventuellement choisie après la phase de modélisation. Elle permet en outre de mieux appréhender l'architecture d'un système logiciel tout en permettant d'obtenir automatiquement des informations détaillées sur les éléments de base. D'autres caractéristiques et avantages de l'invention apparaîtront à l'aide de la description qui suit faite en regard des dessins annexés qui représentent: É la figure 1, deux composants logiciels modélisés selon le modèle de 20 composant selon l'invention; É la figure 2, les principaux contrats métier du modèle de composants selon l'invention appliqués à un composant logiciel client et un composant logiciel fournisseur; É la figure 3, les contrats métier de publication et de souscription de données du modèle de composants selon l'invention appliqués à un composant logiciel client et un composant logiciel fournisseur; É la figure 4, le contrat métier de notification du modèle de composants selon l'invention appliqué à un composant logiciel client et un composant logiciel fournisseur; É la figure 5, le contrat métier d'extension du modèle de composants selon l'invention appliqué à un composant logiciel client et un composant logiciel fournisseur; É la figure 6, des composants logiciels dépendant cycliquement les uns des autres. La conception de systèmes complexes à base de composants logiciels peut notamment comporter une phase de modélisation reposant sur un langage de modélisation dont la sémantique est définie et connue. Un langage de modélisation comme par exemple le langage de modélisation unifié, UML pour Unified Modeling Langage selon l'expression anglo-saxonne, propose une sémantique de base normée et versionnée. Les termes de composant logiciel , d' interface , d' opération et de paramètres sont notamment utilisés pour décrire le langage de modélisation unifié. Un composant logiciel est une partie d'un système logiciel caractérisée par sa modularité, son aptitude à être déployée et remplacée. La phase de modélisation aboutit à une définition des composants logiciels et de leurs interfaces. Le langage de modélisation unifié propose une sémantique de base permettant de décrire les aspects statiques et dynamiques des composants logiciels. La figure 1 illustre deux composants logiciels modélisés selon le modèle de composant selon l'invention. Dans le modèle de composant selon l'invention, deux niveaux de contrats sont définis: des contrats métiers et des contrats d'interface. Les contrats métiers permettent notamment de préciser fonctionnellement le comportement et les responsabilités de composants logiciels. Les contrats d'interface correspondent aux interfaces réelles d'un composant pouvant être générées à partir des contrats métiers. Pour un contrat donné un composant logiciel est dit composant logiciel fournisseur lorsqu'il a la responsabilité du contrat métier et du contrat d'interface correspondant. Réciproquement, pour un contrat donné, un composant logiciel client est un composant logiciel faisant appel à un composant logiciel fournisseur. Un composant logiciel client n'a pas la responsabilité du contrat métier et du contrat d'interface correspondant. Ainsi, les interfaces sont toujours rattachées au composant logiciel fournisseur. Un composant logiciel peut être fournisseur par rapport à plusieurs contrats métiers. En outre, un composant logiciel peut avoir un rôle de fournisseur pour un ensemble de contrats métier et un rôle de client pour un autre ensemble de contrats métier. La figure 1 comporte un composant logiciel 1 client et un composant logiciel 2 fournisseur. Le composant logiciel 2 fournisseur a la responsabilité d'un contrat métier 3. Un rôle 4 du contrat métier 3 est attribué au composant logiciel 2 fournisseur. Un autre rôle 5 du contrat métier 3 est attribué au composant logiciel 1 client. Le modèle de composant logiciel selon l'invention comporte en outre une sémantique étendue par rapport au langage de modélisation unifié. Cette sémantique étendue comprend de plus les concepts relatifs aux paramètres des opérations: passage de paramètre par valeur et passage de paramètre par référence. Ainsi les paramètres d'une opération d'un composant logiciel décrit par le modèle de composant selon l'invention peuvent être déclarés comme paramètre passé par valeur ou comme paramètre passé par référence. Dans le cas d'un paramètre passé par valeur, le paramètre n'est pas intégralement transmis. Seule la valeur est transmise. Le paramètre n'est pas accessible en écriture. Le concept de passage par valeur et par référence permet notamment de préciser la responsabilité entre le composant logiciel appelant et le composant logiciel appelé. Ainsi, on peut par exemple s'assurer qu'un composant logiciel appelé ne peut modifier un paramètre manipulé par l'appelant. Pour cela, il suffit de préciser que le paramètre est transmis par valeur. 2891074 7 Dans le cas d'un paramètre passé par référence, une référence vers le paramètre est transmise. Le composant logiciel recevant la référence vers le paramètre peut accéder et modifier la valeur de ce paramètre. Le paramètre est accessible en lecture et en écriture. Cette sémantique étendue comprend en outre les concepts d'opérations synchrones et asynchrones. Les opérations d'un composant logiciel décrit par le modèle de composant selon l'invention peuvent être déclarées comme opérations synchrones et comme opérations asynchrones. Dans le cas d'une opération synchrone, le composant logiciel client attend la fin de l'exécution de l'opération et le retour éventuel d'une réponse pour poursuivre son exécution. Dans le cas d'une opération asynchrone, le composant logiciel client n'attend pas la fin de l'exécution de l'opération pour poursuivre son exécution. Le retour éventuel d'une réponse peut lui parvenir ultérieurement. Le concept d'opération synchrone et asynchrone permet notamment de préciser la manière dont les services par l'intermédiaire des opérations qu'ils comportent renvoient une réponse. Cette sémantique étendue comprend encore la définition d'un 20 ensemble de contrats métiers de base. La figure 2 montre les principaux contrats métier du modèle de composants selon l'invention appliqués à un composant logiciel client et un composant logiciel fournisseur. Les éléments identiques aux éléments déjà présentés portent les mêmes références. Un contrat de service 32 est un contrat métier permettant notamment de décrire un modèle de requête-réponse (ou selon l'expression anglo-saxonne request-reply pattern) entre des composants logiciels. Le composant logiciel 2 assure un rôle de fournisseur du service 31. Le fournisseur de service 31 a la responsabilité de l'exécution du service tel que décrit dans le contrat de service 32. Il peut en outre modifier les paramètres qui lui ont été transmis si ces paramètres ont été passés par référence. Le composant logiciel 1 assure un rôle d'utilisateur du service 30 tel que décrit par le contrat de service 32. L'utilisateur du service 30 peut demander l'exécution d'une des opérations du service. L'utilisateur du service 30 transmet alors des paramètres nécessaires à l'exécution de cette opération du service. L'utilisateur 30 d'une opération d'un service peut recevoir un résultat dès la fin de l'exécution de l'opération, si celle-ci est synchrone, ou ultérieurement si celle-ci est asynchrone. Un contrat d'observation d'événements 35 est un contrat métier permettant notamment de décrire un modèle d'observation (ou selon l'expression anglosaxonne Observer Pattern) entre des composants logiciels. Les événements échangés entre le composant 1 et le composant 2 sont définis par le contrat d'événements 35. Le composant logiciel 2 assure un rôle de gestionnaire d'événement 34. Ce rôle de gestionnaire d'événement 34 précise que le composant 2 produira les événements définis par 35. Le composant logiciel 1 assure un rôle d'observateur d'événements 33. Ce rôle d'observateur d'événement 33 précise que le composant 1 peut recevoir les événements définis par 35 et produits par le composant 2. Ce rôle d'observateur d'événement 33 permet en outre au composant 1 de définir un filtre pour que ce dernier ne reçoive que les événements qui l'intéresse. Un contrat de configuration 38 est un contrat métier permettant notamment de décrire un composant configurable au travers de propriétés (ou selon l'expression anglo-saxonne Property Pattern). Le composant logiciel 2 assure un rôle de fournisseur configurable 37. Le fournisseur configurable 37 précise par l'intermédiaire du contrat de configuration 38 les propriétés (données de configuration) qu'il peut prendre en compte. Le composant logiciel 1 assure un rôle de gestionnaire de configuration 36. Le gestionnaire de configuration 36 manipule les données de configuration qui doivent être prises en compte par le fournisseur configurable 37 conformément au contrat de configuration 38. La figure 3 montre les contrats métier de publication et de souscription de données du modèle de composants selon l'invention appliqués à un composant logiciel client et un composant logiciel fournisseur. Les éléments identiques aux éléments déjà présentés portent les mêmes références. Un contrat de publication 42 est un contrat métier. Le contrat de 35 publication 42 s'applique à des composants logiciels. Le composant logiciel 2 assure un rôle de dépôt de données 41. Le contrat de publication 42 est équivalent à un contrat de service dans un contexte d'utilisation particulier. Le dépôt de données 41 enregistre et restitue les données définies par le contrat 42. L'enregistrement des données peut notamment s'inscrire dans un contexte transactionnel. Le composant logiciel 1 assure un rôle d'éditeur de données 40. L'éditeur de données 40 peut notamment créer, lire, détruire ou mettre à jour les données tels que définies par le contrat 42 et enregistrées dans le dépôt de données. Un contrat de souscription 45 est un contrat métier. Le contrat de souscription 45 s'applique à des composants logiciels. Le composant logiciel 2 assure le rôle de dépôt de données 44. Le dépôt de données 44 précise par l'intermédiaire du contrat de souscription 45 les données qu'il gère. Le composant logiciel 1 assure un rôle de souscripteur de données 43. Le souscripteur de données 43 reçoit des données qui ont été créées, mises à jour ou détruites dans le dépôt de données et répondant à certains critères. Le souscripteur de données précise au travers notamment de critères les données qui l'intéresse. La figure 4 montre le contrat métier de notification du modèle de composants selon l'invention appliqués à un composant logiciel client et un composant logiciel fournisseur. Les éléments identiques aux éléments déjà présentés portent les mêmes références. Un contrat de notification 52 est un contrat métier réciproque. Le contrat de notification 52 s'applique à deux composants logiciels. Le contrat de notification 52 joue un rôle comparable au contrat d'observation 35 présenté à la figure 2: cependant les rôles sont inversés. En effet, les événements sont transmis par le composant client 1 au composant fournisseur 2. Le composant logiciel 2 assure un rôle de gestionnaire d'événement 51. Le gestionnaire d'événement 51 précise par l'intermédiaire du contrat de notification les événements qu'il gère conformément au contrat de notification. Le composant logiciel 1 assure un rôle de source d'événements 50. La source d'événements 50 précise les événements qu'elle est en mesure cle produire conformément au contrat de notification 52. La source d'événements 50 envoie des événements au gestionnaire d'événement 51. Le gestionnaire d'événement 51 a notamment pour responsabilité de propager les événements qu'il reçoit à d'éventuels observateurs. La figure 5 rnontre le contrat métier d'extension du modèle de composants selon l'invention appliqués à un composant logiciel client et un composant logiciel fournisseur. Les éléments identiques aux éléments déjà présentés portent les mêmes références. Un contrat d'extension 62 est un contrat métier réciproque permettant notamment de décrire un modèle d'extension (ou selon l'expression anglosaxonne Extension Pattern) entre des composants logiciels. Le contrat d'extension 62 joue un rôle comparable au contrat de service 32 présenté à la figure 2: cependant les rôles sont inversés. En effet, c'est le composant fournisseur 2 qui utilise les services du composant client 1, le composant 1 jouant le rôle de sous-traitant. Le composant logiciel 2 assure un rôle de fournisseur pour un composant tiers mais a besoin de services qu'il sous-traite au composant logiciel 1. Le fournisseur de service 61 pour un composant tiers précise par l'intermédiaire du contrat d'extension 62 les services qu'il exige par un composant client soustraitant. Le composant logiciel 1 assure un rôle de développeur 60 pour les services définis par le contrat 62. La figure 6 montre des composants logiciels dépendant cycliquement les uns des autres. La figure 6 comporte un composant logiciel A, un composant logiciel B et un composant logiciel C. Un lien de dépendance entre deux composants logiciels indique que composant logiciel dont est issu le lien de dépendance utilise l'autre composant logiciel. Ainsi le composant logiciel A a un lien de dépendance avec le composant logiciel B. Le composant logiciel B a un lien de dépendance avec le composant logiciel C. Le composant logiciel C a un lien de dépendance avec le composant logiciel A. Aussi les trois composants logiciels A, B et C sont interdépendants: ils ne peuvent pas être réutilisés séparément les uns des autres. Le modèle de composant selon l'invention interdit les dépendances cycliques ou mutuelles (c'est à dire une interdépendance entre deux composants logiciels). En effet, les dépendances cycliques limitent la modularité et la capacité de ré-utilisation d'un composant logiciel. L'utilisation de contrat métier réciproque permet notamment d'éviter les dépendances cycliques entre composants. L'utilisation du modèle de composant selon l'invention pour décrire un système logiciel à base de composants logiciels peut notamment suivre les étapes suivantes: définition des rôles d'un composant logiciel par un ou plusieurs contrats métiers; définition des contrats d'interface comportant les interfaces réelles pour chaque contrat métier; recherche et interdiction des dépendances cycliques ou mutuelles entre les composants logiciels. Un composant logiciel peut être lié à plusieurs contrats métiers. De plus, un composant logiciel peut être fournisseur pour un contrat métier et client pour un autre contrat métier. Le modèle architectural connu sous la désignation de ModèleNue/Contrôleur permet de séparer le modèle de données, la présentation des données et la logique de contrôle des données d'un système logiciel. La modélisation comporte notamment trois composants logiciels: un contrôleur, un modèle de données et une vue. La modélisation présentée comporte en outre un contrat de publication entre le contrôleur et le modèle de données. Le contrôleur a notamment le rôle d'éditeur de données 40. Le modèle de données a quant à lui le rôle de dépôt de données 41. La modélisation présentée comporte de plus un contrat de souscription entre le modèle de données et la vue. Le modèle de données a notamment le rôle de dépôt de données 44. La vue a quant à elle le rôle de souscripteur de données 43. Le procédé selon l'invention peut notamment être mis en uvre à l'aide d'un profil du langage de modélisation unifié. La sémantique étendue du modèle de composant logiciel selon l'invention peut être supportée par la définition de stéréotypes et de valeurs taguées ( tagged-values selon l'expression anglo-saxonne). Le langage de modélisation unifié dans sa deuxième version dont la sémantique lié au composant a été enrichie s'avère adapté à la mise en oeuvre du modèle de composant selon l'invention. Le modèle de composant selon l'invention peut être utilisé dans le cadre d'un développement guidé par la modélisation (ou selon l'expression anglo-saxonne Model Driven Development). Le modèle de composant selon l'invention peut être utilisé en tant que modèle indépendant de la plateforme (ou selon l'expression anglo-saxonne Platform Independent Model). De plus, il est possible de mettre en oeuvre un procédé de génération des contrats d'interfaces des composants à partir des contrats métiers. Pour cela, des équivalences et des règles de génération entre la sémantique du modèle de composant selon l'invention et les interfaces réelles des composant logiciel sont définis selon le contexte d'utilisation. REVENDICATIONS 1. Procédé de modélisation d'un système logiciel comportant des composants (1,2), un langage de modélisation objet étant utilisé pour décrire les composants (1,2) du système logiciel, caractérisé en ce qu'il comporte au moins les étapes suivantes: définition des rôles d'un composant (1,2) par un ou plusieurs contrats métiers (3), un contrat métier (3) décrivant le rôle des composants (1,2) qui lui sont attachés, un des composants (2) étant qualifié de fournisseur pour un rôle donné (4) , les autres composants (1) étant qualifiés de clients pour un rôle donné (5) ; définition des contrats d'interface pour chaque contrat métier (3). 2. Procédé selon la revnedication 1 caractérisé en ce que les contrats métiers (3) et les contrats d'interfaces appartiennent au composant logiciel ayant le rôle de fournisseur (4). 3. Procédé selon l'une des quelconques revendications précédentes caractérisé en ce que les dépendances cycliques ou mutuelles entre les composants (1,2) sont interdites. 4. Procédé selon l'une des quelconques revendications précédentes caractérisé en ce qu'un des contrats métiers est un contrat de service (32) permettant de décrire un modèle de requête-réponse entre un composant logiciel (2) assurant un rôle de fournisseur du service (31) et un composant logiciel (1) assurant un rôle d'utilisateur du service (30), l'utilisateur du service (30) pouvant demander l'exécution d'une des opérations dudit service. 5. Procédé selon l'une des quelconques revendications précédentes caractérisé en ce qu'un des contrats métiers est un contrat d'observation (35) permettant de décrire un modèle d'observation entre un composant logiciel (2) assurant un rôle de gestionnaire d'événement (34) et un composant logiciel (1) assurant un rôle d'observateur d'événements (33), l'observateur d'événement (33) recevant les événements qui ont pu être lancés par le gestionnaire d'événement (34). 6. Procédé selon l'une des quelconques revendications précédentes caractérisé en ce qu'un des contrats métiers est un contrat de configuration (38) permettant de décrire un composant configurable au travers de propriétés entre un composant logiciel (2) assurant un rôle de fournisseur configurable (37) et un composant logiciel (1) assurant un rôle de gestionnaire de configuration (36), le gestionnaire de configuration (36) manipulant les données de configuration qui doivent être prises en compte par le fournisseur configurable (37). 7. Procédé selon l'une des quelconques revendications précédentes caractérisé en ce qu'un des contrats métiers est un contrat de publication (42) entre un composant logiciel (2) assurant le rôle de dépôt de données (41) et un composant logiciel (1) assurant un rôle d'éditeur de données (40), l'éditeur de données (40) pouvant créer, lire, détruire ou mettre à jour les données enregistrés dans le dépôt de données (41). 8. Procédé selon l'une des quelconques revendications précédentes caractérisé en ce qu'un des contrats métiers est un contrat de souscription (45) entre un composant logiciel (2) assurant le rôle de dépôt de données (44) et un composant logiciel (1) assurant un rôle de souscripteur de données (43), le souscripteur de données (43) recevant des données qui ont été créées, mises à jour ou détruites dans le dépôt de données (44) et répondant à certains critères. 9. Procédé selon l'une des quelconques revendications précédentes caractérisé en ce qu'un des contrats métiers est un contrat de notification (52) entre un composant logiciel (2) assurant un rôle de gestionnaire d'événement (51) et un composant logiciel (2) assurant un rôle de source d'événements (50), la source d'événements (50) envoyant des évènements au gestionnaire d'événement (51). 10. Procédé selon l'une des quelconques revendications précédentes caractérisé en ce qu'un des contrats métiers est un contrat d'extension (62) 35 permettant de décrire un modèle d'extension entre un composant logiciel (2) assurant un rôle de fournisseur du service (61) et un composant logiciel (1) assurant un rôle de développeur de service (60), le développeur de service (60) mettant à disposition du fournisseur de service (61) ledit service. 11. Procédé selon l'une des quelconques revendications précédentes caractérisé en ce que les contrats d'interface sont générés automatiquement à partir des contrats métier. 12. Procédé selon l'une des quelconques revendications précédentes o caractérisé en ce que la sémantique des contrats métiers et des contrats d'interfaces est décrite par un profil du langage de modélisation unifié.