Brevet FR2910984A1 — publié le 20080704

La présente invention est relative au domaine de l'urbanisme fonctionnel des plates-formes de service. Plus précisément, la présente invention est relative à un procédé automatisé de détermination d'un modèle arborescent des quartiers fonctionnels dédiés à des services de télécommunications, à partir de l'analyse dynamique de ces services de télécommunications du point de vue de leurs utilisations. On précise brièvement ci-dessous les définitions de notions 1 o fondamentales utilisées dans le cadre de la présente invention. Une "plate-forme de services de télécommunications" est un dispositif apte à fournir à un utilisateur un ou plusieurs services dans lesquels des messages sont transmis à distance. Une plate-forme de services est constituée d'un ensemble de composants organiques implémentés réalisant de façon 15 logique plusieurs fonctions du (ou des) service(s) à l'utilisateur. Un ou plusieurs de ces composants peuvent offrir une interface organique à d'autres plates-formes de services. Elle exécute une ou plusieurs logiques de service. Un "enabler" est un élément (par exemple une application, ou une composition d'applications) mutualisé qui facilite la construction d'un service à 20 l'utilisateur. Il est fourni pour l'environnement dans lequel les services à l'utilisateur peuvent être développés et déployés. Il n'est pas perceptible par l'utilisateur. Il a un périmètre fonctionnel clairement identifié, un cycle de vie maîtrisé, une responsabilité de données définie, et il est accessible à travers des prises de services au sens de l'Architecture Orientée Service "SOA" 25 (initiales des mots anglais "Service-Oriented Architecture"). La notion d'enabler est normalisée par l'OMA (Open Mobile Alliance). Un "modèle dynamique d'informations service" est ici un ensemble de diagrammes de séquence où des instances "d'informations service", représentées par des objets UML (initiales des mots anglais "Unified Modeling 30 Language" signifiant "Langage de Modélisation Unifié"), et des messages échangés entre ces instances, représentés par des interactions entre objets UML, permettent de décrire d'une manière dynamique le comportement des informations service liées à un service de télécommunications lors de son utilisation (pour une présentation du langage UML, on pourra se référer à 35 l'ouvrage de G. Booch, J. Rumbaugh et I. Jacobson intitulé "The Unified Modeling Language User Guide", Addison-Wesley, 1999). Un modèle dynamique d'informations service participantes à l'utilisation d'un service de télécommunications représente : - les instances d'informations, et les messages échangés entre instances d'informations lors d'une utilisation du service de télécommunications. Un "modèle de composants fonctionnels" est un ensemble de composants fonctionnels représentés par des composants UML (un composant UML étant une partie logique et remplaçable d'un système), et d'interfaces entre ces composants représentés par des interfaces UML (une interface UML étant un ensemble d'opérations utilisé pour spécifier le service d'un composant) ; ces composants et interfaces UML permettent de cartographier d'une manière cohérente les composants fonctionnels liés aux services de télécommunications. Ces composants fonctionnels sont appelés "composants fonctionnels service" dans le cadre de la présente invention. Ils peuvent être cohérents avec l'urbanisme choisi pour les plates-formes de services de télécommunications, ou être définis de façon spécifique par les architectes fonctionnels développant un service de télécommunications. Une plate-forme qui réalise au moins un composant fonctionnel a son contour fonctionnel externe défini par un modèle. Ce modèle doit permettre à la fois d'optimiser l'utilisation de la plate-forme en évitant des redondances, et de faire évoluer la solution mise en place à l'intérieur d'un cadre fonctionnel maitrisé. Un "modèle de composants fonctionnels service" spécifie : - les composants fonctionnels service, et - les interfaces fonctionnelles service. Un "modèle de données logiques" est un ensemble de données représentées par des classes UML, et de dépendances orientées entre ces données, représentées par des associations UML. Dans le cadre de la présente invention, ces données logiques, que l'on appellera données service, sont manipulées par l'ensemble des composants fonctionnels réalisant l'usage d'un service de télécommunications. Les données service sont réalisées par des données physiques qui sont produites ou utilisées par les composants organiques implémentés sur la plate-forme de service de télécommunications. Ces données physiques sont en effet transformées à partir des données service avec la prise en compte des solutions techniques mises en oeuvre pour les données physiques (type de base de données, solutions de persistance, et ainsi de suite). Pour cette raison, la conception d'une donnée service a des conséquences majeures sur la plate-forme de service de télécommunications réalisée. Un "modèle de données service" dédiées à un service de télécommunications spécifie : - les données service, et - les dépendances entre données service. Un "quartier fonctionnel" est un regroupement de composants fonctionnels homogènes quant aux traitements réalisés. Un "modèle de quartiers fonctionnels" spécifie : - des composants fonctionnels, - des entités fonctionnelles, et - des quartiers fonctionnels. Dans le cadre de la présente invention, les entités fonctionnelles sont appelées "entités fonctionnelles service", et les quartiers fonctionnels sont appelés "quartiers fonctionnels service". Enfin, une "règle d'urbanisme" est une règle qui porte sur les liens entre les modèles définis ci-dessus (modèle d'information, modèle de composants fonctionnels, modèle de données logiques). Depuis peu, il a été proposé de mettre en oeuvre des techniques d'urbanisme dans le cadre des plates-formes de services de télécommunications. Pour les urbanistes en matière de services de télécommunications, la détermination de quartiers fonctionnels est une étape importante du travail d'urbanisation. En effet, le regroupement de composants fonctionnels dans des quartiers fonctionnels permet de travailler avec des niveaux de détail différents. Les urbanistes et les décideurs d'une entreprise peuvent ainsi raisonner sur les quartiers fonctionnels, alors que les architectes et les concepteurs travaillent dans le détail à partir des composants fonctionnels. Pour cela, les quartiers fonctionnels doivent constituer un regroupement parfaitement cohérent de composants fonctionnels du point de vue de l'usage des services de télécommunications. L'optimisation de la découpe des quartiers peut avoir une incidence sur la découpe en composants fonctionnels, sur leurs relations, et donc sur les plates-formes de services de télécommunications qui réalisent les composants fonctionnels. La façon classique de regrouper les composants fonctionnels d'un service est d'effectuer un regroupement qui semble logique aux architectes du service, d'après les besoins d'interactions entre composants et les solutions techniques existantes. Ainsi, l'OMA souligne qu'un enabler ne doit mettre en oeuvre que des fonctions intrinsèques (c'est-à-dire reliées directement à la réalisation de son objectif métier), et non des fonctions extrinsèques (c'est-à-dire non directement reliées à la réalisation de son objectif métier). Cependant, l'OMA ne définit pas de critère objectif pour séparer les fonctions intrinsèques des fonctions extrinsèques (il est juste indiqué que cette distinction doit se faire de façon collective, dans le cadre d'un processus normatif). Seules les connaissances des experts métier sont mises à profit dans la définition de ces regroupements. L'inconvénient essentiel de cette 4o approche classique intervient lors de l'étude de tous les choix possibles concernant des regroupements, lorsque le nombre de composants fonctionnels est important. La présente invention concerne donc un procédé de détermination de quartiers fonctionnels service pour des services de télécommunications, dans lequel, lors du déroulement d'un scénario décrivant l'utilisation d'un service de télécommunications : - on associe à chaque message échangé entre instances d'informations service un ou plusieurs flux entre composants fonctionnels service représentés par un modèle d'architecture de composants, - on estime la pertinence métier d'au moins un regroupement de 1 o composants fonctionnels service, et - on regroupe, de façon itérative, lesdits composants fonctionnels service dans des quartiers fonctionnels service, en appliquant la contrainte selon laquelle les regroupements impliquant les meilleurs indicateurs de pertinence métier doivent être traités en priorité. 15 Dans le cadre de la présente invention, on entend par "indicateur de pertinence métier" ou, pour faire court, "indicateur de pertinence", relatif à un regroupement d'entité fonctionnelle, l'espérance mathématique de la variable aléatoire représentant le nombre de flux successifs entre composants fonctionnels de l'entité fonctionnelle cible du regroupement. Cet indicateur 20 dépend, pour un (ou plusieurs) service(s) de télécommunications existant(s) ou à développer, des séquences de messages émis entre instances d'informations représentées dans un modèle dynamique d'informations de ce ou ces services. Ainsi, le procédé selon l'invention s'appuie sur une modélisation à partir de tous langages évolués de modélisation d'analyse objet et d'architecture à 25 base de composants, tels qu'UML. De plus, elle peut être réalisée avec un code conforme à l'approche MDA (initiales des mots anglais "Mode/ Driven Architecture"). Avantageusement, le langage de modélisation UML et l'approche MDA sont préconisés par l'OMG (Object Management Group). La détermination des quartiers fonctionnels services est contrainte par 30 l'architecture des données dédiées aux services, et par des règles d'urbanisme spécifiques. L'invention propose de regrouper automatiquement des composants fonctionnels dédiés aux services de télécommunications, à partir d'une estimation de la pertinence métier de chaque regroupement possible de 35 composants fonctionnels à l'intérieur d'un même quartier fonctionnel service. La pertinence métier est évaluée à partir du comportement dynamique des informations participant à l'utilisation d'un service de télécommunications, et donc indépendamment de toute architecture fonctionnelle. Chaque regroupement obtenu est le résultat de la mise en oeuvre d'un procédé 4o permettant de sélectionner de manière optimale les composants fonctionnels à regrouper. Le procédé automatisé selon l'invention permet d'obtenir un regroupement rigoureux de composants fonctionnels dédiés à un service de télécommunications du point de vue de l'usage des services de télécommunications, en proposant des regroupements en fonction de critères objectifs (métriques). Ce procédé permet, dans le cadre de services de télécommunications, une détermination de quartiers fonctionnels service qui soit cohérente entre les différents services, car réalisée de façon automatisée et reproductible. Les regroupements ainsi obtenus fournissent alors une base de travail 1 o cohérente et reproductible pour les urbanistes ayant à déterminer des regroupements en quartiers fonctionnels. Les urbanistes bénéficient ainsi d'une véritable assistance à la détermination des quartiers fonctionnels, qui : - simplifie la mise en oeuvre d'une évolution de la stratégie d'une entreprise en considérant les conséquences de cette évolution sur chaque quartier 15 fonctionnel, avant de s'intéresser aux conséquences sur les composants des quartiers concernés, et - offre une découpe optimisée des quartiers reposant sur l'usage des services de télécommunications, là où une approche par regroupements motivés simplement par des raisons métier montre rapidement ses limites. 20 Cette assistance est notamment de grande utilité pour les urbanistes lorsqu'ils doivent faire face à un nouveau besoin de service de télécommunications. L'introduction d'un nouveau service de télécommunications peut avoir un impact sur l'urbanisme des plates-formes de services. Dans ce cas, il convient d'apporter rapidement une réponse, laquelle 25 aura nécessairement des effets sur l'organisation, notamment en termes de coût. L'invention aide l'urbaniste à faire évoluer la conception des quartiers fonctionnels et donc à mesurer l'impact d'une évolution de l'urbanisme sur les plates-formes existantes et, si l'organisation de l'opérateur est en relation avec la découpe en quartiers fonctionnels, d'estimer l'impact sur la structure 30 organisationnelle de l'entreprise. Un deuxième avantage de l'invention est qu'elle permet aux architectes des plates-formes de services d'optimiser le pilotage et l'organisation de ces plates-formes. La détermination des quartiers fonctionnels permet le regroupement des composants fonctionnels structurants, et a notamment pour 35 conséquence l'optimisation de la production d'enablers. L'utilité de l'invention pour les architectes de plates-formes de services de télécommunications se situe lors du développement industriel d'enabler (composant organique défini comme stratégique par l'entreprise et donc destiné à être réutilisé prioritairement lors de développements de plates-formes 4o de services de télécommunications) du fait du couplage fort existant entre les composants fonctionnels qui appartiennent à un même quartier et sont donc développables dans un même enabler. Une conséquence pour les architectes des plates-formes de services de télécommunications est de prendre en compte de nouvelles solutions d'infrastructure pour un enabler résultant de la modification du positionnement des composants fonctionnels réalisés, dans la découpe en quartiers. En effet, si un quartier est jugé plus critique que les autres d'un point de vue stratégique, le déplacement d'un composant fonctionnel vers ce quartier aura nécessairement des conséquences sur la solution d'infrastructure mise en place. 1 o Un troisième avantage de l'invention est qu'elle permet d'améliorer la définition des composants fonctionnels et de leurs relations. En effet, la détermination assistée de quartiers fonctionnels services peut faire apparaître des problèmes d'architecture. Une réponse aux questions soulevées peut être trouvée en adaptant le découpage en composants fonctionnels. Cette 15 adaptation de l'architecture fonctionnelle a une incidence directe sur l'organisation et les liens entre les plates-formes de services qui réalisent les composants fonctionnels. L'invention permet de déterminer les effets que le choix des composants fonctionnels réalisés dans un enabler aura sur les autres quartiers fonctionnels. On peut ainsi déterminer de façon automatisée 20 les conséquences (conflits, regroupement sous-optimal, et ainsi de suite) du choix d'un enabler "sur étagère" sur les autres enablers. La présente invention vise également : -un moyen de stockage de données comportant des instructions de code de programme informatique pour l'exécution des étapes de l'un quelconque des 25 procédés décrits succinctement ci-dessus, et - un programme d'ordinateur contenant des instructions telles que, lorsque ledit programme commande un dispositif de traitement de données programmable, lesdites instructions font que ledit dispositif de traitement de données met en oeuvre l'un quelconque des procédés décrits succinctement ci-dessus. 30 Une description plus détaillée du procédé de détermination de quartiers fonctionnels service pour des services de télécommunications, objet de l'invention, sera donnée ci-après en liaison avec les figures dans lesquelles : - la figure 1 illustre la représentation en langage UML de la dépendance de données logiques, 35 - la figure 2 illustre la représentation arborescente d'un modèle de quartiers fonctionnels, - la figure 3 illustre le modèle dynamique des informations service de "User Context"û scénario de notification de présence, - la figure 4 illustre la cohérence avec la représentation UML d'un modèle 4o statique d'informations service, - la figure 5 illustre un extrait du modèle de données service de la zone "User Context', - la figure 6 illustre le modèle statique des informations service de "User Context", - la figure 7 illustre le modèle dynamique des informations service de "User Context"-scénario de souscription de présence, - la figure 8 illustre le modèle dynamique des informations service de "User Context"û 1 scénario de transfert d'appel, - la figure 9 illustre le modèle dynamique des informations service de "User 1 o Context"- 2 scénario de transfert d'appel, - la figure 10 illustre le modèle dynamique des informations service de "User Context"- scénario d'unification de messageries, - la figure 11 illustre le modèle dynamique des informations service de "User Context"- scénario de configuration de disponibilité, 15 - la figure 12 illustre le modèle des données service de "User Context", - la figure 13 illustre le modèle de quartiers fonctionnels services de "User Context"û Initialisation, - la figure 14 illustre le modèle de quartiers fonctionnels services de "User Context"û 1 itération, et 20 - la figure 15 illustre le modèle de quartiers fonctionnels services de "User Context"û 2 itération. La figure 1 illustre l'orientation des dépendances dans un modèle de données logiques. On voit que la donnée origine de l'association Dl a pour responsabilité de connaître la donnée cible de l'association D2, et non l'inverse. 25 Comme mentionné ci-dessus, dans le cadre de la présente invention, lesdites données logiques sont des "données service" manipulées par l'ensemble des composants fonctionnels réalisant l'usage d'un service de télécommunications. La figure 2 illustre un modèle de quartiers fonctionnels services. Ce modèle est représenté ici sous forme arborescente, où chaque feuille terminale 30 correspond à un composant fonctionnel service (CF;, CFj sur la figure 2), et où chaque noeud intermédiaire correspond à la spécification d'une entité fonctionnelle services (EF;, EF, EF,1, EF,jk sur la figure 2) regroupant les entités fonctionnelles de niveau inférieur liées à cette entité. Les entités fonctionnelles de niveau le plus bas (EF;, EF) sont constituées d'un unique composant 35 fonctionnel service. Le procédé selon l'invention permet d'extraire des quartiers fonctionnels service (EF,jk, entourée d'un trait gras sur la figure 2) parmi les entités fonctionnelles service. Chaque quartier doit respecter la Règle d'Urbanisme selon laquelle un composant fonctionnel service n'appartient qu'à un, et un seul, quartier 40 fonctionnel service. Sur la figure 2, le quartier fonctionnel service extrait de l'entité fonctionnelle services EF,Ïk comprend, entre d'autres, les composants fonctionnels service CF; et CFj. Les moyens mis en oeuvre par l'invention comprennent notamment : - un moyen pour représenter des échanges de messages entre informations service, - un moyen pour représenter des séquences de composants fonctionnels service à partir d'échanges de messages entre informations service, et - la description d'un algorithme itératif permettant de mettre au point un modèle de quartiers fonctionnels service. 1 o Ledit algorithme permet les regroupements de composants fonctionnels service les plus pertinents. La mesure de cette pertinence s'appuie sur l'estimation de la pertinence métier d'un regroupement de composants fonctionnels service, sur la proposition d'un seuil au-delà duquel un regroupement est considéré comme pertinent, ainsi que sur une estimation du 15 gain issu d'un tel regroupement à partir des séquences de composants fonctionnels service. Pour des raisons de commodité de présentation de la présente invention, on a choisi de représenter les échanges de messages entre informations service au moyen de diagrammes de séquence du langage UML. 20 Ces diagrammes mettent en évidence, pour un scénario d'utilisation d'un service de télécommunications, les échanges de messages entre des instances d'informations service. On va présenter un mode de réalisation particulier de l'invention fondé sur la zone "User Context' définie dans le document interne France Télécom 25 intitulé "Archinoo Service û Reference architecture û User Context", FT/R&D/BIZZ/PMX/79.04/EB, version 1.4, 29 mars 2005. Cette étude modélise les informations et les composants fonctionnels nécessaires pour décrire les services utilisateur adaptés au contexte de l'utilisateur, et à ce titre utilisant des informations sur la présence de l'utilisateur, sur ses préférences, ses capacités, 30 les capacités de ses terminaux, sur ses contacts privilégiés, et sur son identité. L'étude "User Context' a été appliquée pour la conception du portail de la société Orange, qui permet à l'utilisateur d'un service de télécommunications d'avoir une vue unifiée des services offerts par le portail, qu'il soit sur le réseau mobile ou sur le réseau Internet. 35 Dans l'extrait de l'analyse dynamique des exigences fonctionnelles formulées pour la zone "User Context" représenté sur la figure 3, les éléments représentés sont le scénario, les instances d'informations service et les messages échangés. Le scénario d'utilisation d'un service de télécommunications représenté 4o dans le diagramme de séquence sur cette figure 3 est la notification de présence "Presence notification" d'un utilisateur. Les informations service instanciées lors du déroulement de ce scénario sont : o Identity, o User profile, o Availability rule, o le message échangé entre le scénario et la première instance d'information service, soit Identity, et o Cal/Action. Les messages échangés entre instances d'informations service sont les suivants : o owns ù Request émis par l'instance de Identity vers celle de User profile, o owns ù Response émis par l'instance de User profile vers celle de Identity, o defines ù Request émis par l'instance de Identity vers celle de Availability rule, et o defines ù Response émis par l'instance de Availability rule vers celle de Identity. La notation des messages échangés dans ce mémoire est la suivante : Lien entre informations ù Type du message. Le lien entre informations est celui qui est activé dans le modèle statique d'informations service lors de l'échange de message entre des instances de ces informations service. On notera que le modèle dynamique d'informations service doit être cohérent avec le modèle statique d'informations service réalisé lors de l'analyse de l'utilisation d'un service de télécommunications particulier. Chaque message échangé entre deux instances d'informations service nécessite une association entre ces informations service. Comme le montre la figure 4, cette cohérence est traduite ici dans le modèle statique d'informations service par l'existence : o du lien owns, entre les informations service User profile et Identity, utile aux messages owns ù Request et owns ù Response, et o du lien defines, entre Identity et Availability rule, utile aux messages defines ù Request et defines ù Response. Le message est du type "requête" si le message est une demande, ou du type "réponse" si le message est une réponse à une demande. Par analogie, un message du type "requête" correspond à l'émission des paramètres d'entrée d'une requête, et un message du type "réponse" correspond à l'émission des paramètres de sortie d'une requête. Dans l'illustration du scénario de notification de présence : o owns ù Request et defines ù Request sont du type requête, et 4o o owns ù Response et defines ù Response sont du type réponse. En complément du modèle dynamique d'informations service, il est nécessaire de disposer d'un "modèle de données service". On respectera ici les conventions de notation suivantes : - pour les données service : information service source ù composant fonctionnel service de référence ù Type "donnée service" (Flux, Stock, Codification) ù Nature du système producteur de la "donnée service" (SI, PFS, PFR), - pour les dépendances entre données service : lien entre "informations service" ù "Interface fonctionnelle service" de référence, et - pour les dépendances entre "données service" extraites d'une même 1 o information service : scission de "l'information service" ù "Interface fonctionnelle service" de référence. Afin d'illustrer l'identification des éléments techniques de l'invention, on va extraire du modèle de données service de la zone "User Context" les données service suivantes : 15 o Identity ù Identity Management ù Stock ù PFS, o User profile ù Profile ù Stock ù PFS, o Availability rule ù User Presence ù Flux ù PFS, et o Availability rule ù User Presence ù Stock ù PFS. Comme illustré sur la figure 5, les dépendances entre ces données 20 service sont les suivantes : o owns ù createStaticProfile de Identity ù Identity Management ù Stock ù PFS vers User profile ù Profile ù Stock ù PFS, et o scission de Availability rule ù interface fonctionnelle interne à Profile de Availability rule ù Profile ù Flux ù PFS vers Availability rule ù Profile ù Stock 25 ù PFS, et o defines ù createStaticProfile de Identity ù Identity Management ù Stock ù PFS vers Availability rule ù Profile ù Stock ù PFS. La détermination de quartiers fonctionnels service selon l'invention est contrainte par les Règles d'urbanisme suivantes. 30 Règle d'Urbanisme n 1 : un message M, émis par l'instance de l'information service I, vers l'instance de l'information service /2, active une dépendance de la donnée service D, vers la donnée service D2 si : - D, est extraite de I,, 35 - D2 est extraite de /2, et - il existe une dépendance entre D, et D2. En outre, la dépendance est orientée de D, vers D2 si M est un message de type "requête", et orientée de D2 vers D, si M est un message de type "réponse". 4o Dans l'exemple "User Context", le message owns ù Request active owns ù createStaticProfile puisque : - Identity ù Identity Management ù Stock ù PFS est extraite de Identity, - User profile ù Profile ù Stock ù PFS est extraite de User profile, - il existe une dépendance owns ù createStaticProfile entre Identity ù Identity Management ù Stock ù PFS et User profile ù Profile ù Stock ù PFS (cf. figure 5). -owns ù Request est émis par une instance de Identity vers une instance de User profile est un message de requête (cf. figure 3), - owns ù createStaticProfile est orientée de Identity ù Identity Management ù Stock ù PFS vers User profile ù Profile ù Stock ù PFS (cf. figure 3). 1 o Règle d'Urbanisme n 2 : un message M, émis vers l'instance de l'information service I, active une dépendance de la donnée service D, vers la donnée service D2 si : - D, est extraite de I, - D2, différente de D,, est extraite de 1, et 15 - il existe une dépendance entre D, et D2. Dans l'exemple "User Context', le message defines - Request active la dépendance scission de Availablity rule ù interface fonctionnelle interne à Profile, puisque : - defines ù Request est émis vers une instance de Availablity rule (cf. figure 20 3), - Availability rule ù Profile ù Flux ù PFS est extraite de Availability rule, - Availability rule ù Profile ù Stock ù PFS est extraite de Availability rule, et - il existe une dépendance scission de Availablity rule ù interface fonctionnelle interne à Profile entre Availability rule ù Profile ù Flux ù PFS et 25 Availability rule ù Profile ù Stock ù PFS (cf. figure 5). Règle d'Urbanisme n 3 : un message échangé lors d'un scénario d'utilisation de service de télécommunications est considéré comme non-réalisable si : - il n'existe pas de dépendance entre données service activée lors de la mise 30 en oeuvre de la Règle d'Urbanisme n 1 ou de la Règle d'Urbanisme n 2,ou - le type du message (à savoir, "requête" ou "réponse") est incohérent avec l'orientation au sens de la Règle d'Urbanisme n 1 des dépendances activées entre données service. On notera que cette incapacité de réalisation peut être surmontée par 35 l'évolution du modèle dynamique d'informations service, ou du modèle de données service concernés. Dans l'exemple "User Context", le message defines ù Request, d'après la Règle d'Urbanisme n 1, devrait activer les dépendances de : - Identity ù Identity Management ù Stock ù PFS vers Availability rule ù Profile 4o ù Flux ù PFS, et - Identity û Identity Management û Stock û PFS vers Availability rule û Profile û Stock û PFS. Or, il n'existe pas de dépendance dans le modèle de données service (cf. figure 5) entre Identity û Identity Management û Stock û PFS et Availability rule û Profile û Flux û PFS. D'après la Règle d'Urbanisme n 3, le message defines û Request est donc non-réalisable entre les données Identity û Identity Management û Stock û PFS et Availability rule û Profile û Flux û PFS. En revanche, le message defines û Request est réalisable entre les données Identity û Identity Management û Stock û PFS et Availability rule û Profile û 1 o Stock û PFS, puisqu'une dépendance existe entre ces données dans le modèle de données service (cf. figure 5). Règle d'Urbanisme n 4 : L'activation d'une dépendance entre deux données service (cf. Règles d'urbanisme n 1 et n 2), suite à l'échange d'un message lors de l'utilisation d'un service de télécommunications, implique 15 l'activation d'un flux entre les composants fonctionnels service référençant chacune des données, et l'orientation de ce flux est cohérente avec l'orientation du message. Cette Règle d'Urbanisme n 4 utilise un référencement de données produites au sein d'un système d'informations (SI) au moyen d'applications de 20 ce même SI, qui fournit pour cette donnée les valeurs qui font foi, tel qu'enseigné dans la demande de brevet EP1473627 au nom de France Télécom. Dans l'exemple "User Context", un flux du composant fonctionnel service Identity Management vers le composant fonctionnel service Profile est activé 25 suite à l'échange du message owns û Request, puisque : - le message owns û Request échangé dans le scénario de notification de présence lié à l'utilisation d'un service de télécommunications active owns û createStaticProfile (cf. Règle d'Urbanisme n 1), - owns û createStaticProfile est une dépendance entre les données service 30 Identity û Identity Management û Stock û PFS et User profile û Profile û Stock û PFS, - le message owns û Request est émis de Identity vers User profile, - Identity Management référence la donnée service Identity û Identity Management û Stock û PFS extraite de l'information service Identity, et 35 - Profile référence la donnée service User profile û Profile û Stock û PFS extraite de l'information service User profile. Règle d'Urbanisme n 5 : un composant fonctionnel service est ciblé par un regroupement avec d'autres composants fonctionnels service s'il est la source ou, de façon exclusive, la destination, d'un flux entre composants 4o fonctionnels service activé suite à l'échange d'un message lors de l'utilisation d'un service de télécommunications (cf. Règle d'Urbanisme n 4). On notera qu'un composant fonctionnel service ne peut donc être ciblé par un regroupement s'il est une extrémité d'un flux interne, c'est-à-dire dont il est à la fois la source et la destination. Le lien entre composants fonctionnels service ciblés par un 5 regroupement ainsi définis peut donc représenter un message échangé lors d'un scénario de l'utilisation d'un service de télécommunications. Dans l'exemple "User Context', les composants fonctionnels service Identity Management et Profile sont ciblés par un regroupement, puisque le message owns ù Request échangé dans le scénario de notification de 1 o présence active un flux de Identity Management vers Profile (cf. Règle d'Urbanisme n 4). Afin de formaliser le flux du composant fonctionnel service CF1, ciblé par un regroupement, vers le composant fonctionnel service CF2, ciblé par un regroupement, on utilisera ci-dessous la notation suivante : CF1ù>CF2. 15 Dans l'exemple du scénario de notification de présence de "User Context' : - owns ù Request active le flux Identity Managementù> Profile, - owns ù Response active le flux Profileù> Identity Management, - defines ù Request active le flux Identity Managementù> Profile, et 20 - defines ù Response active le flux Profileù> Identity Management. Une séquence de composants fonctionnels service activée est définie comme un ensemble de flux activés entre composants fonctionnels ciblés par un regroupement. La séquence est arrêtée en cours de scénario lorsqu'un message non réalisable au sens de la Règle d'Urbanisme n 3 est émis. Une 25 nouvelle séquence est alors définie à partir du premier composant fonctionnel service ciblé par un regroupement. Le scénario de notification de présence peut donc être représenté dans sa totalité par la séquence de composants fonctionnels service activée Identity Managementù> Profileù> Identity Managementù> Profileù> 30 Identity Management. En cas d'alternative, c'est-à-dire lorsque plusieurs données sont extraites d'une même information service, l'opérateur OU est utilisé de la manière suivante : - (CF1 OU CF2)ù>CF3 (CF1ù>CF3) OU (CF2ù>CF3) 35 - CF1 ù> (CF2 OU CF3) (CF1 ù> CF2) OU (CF1 ù> CF3) Règle d'Urbanisme n 6 : L'indicateur I(EF) de pertinence d'un regroupement de composants fonctionnels service dans une même entité fonctionnelle service EFest défini de la façon suivante : N 1(i -1) * NSi(EF ) 40 1(EF) _ N NSi(EF) i =1 i=2 où - N est la longueur maximale des séquences de composants fonctionnels service appartenant à EF, et -NS1(EF) est le nombre de séquences de i composants fonctionnels service, appartenant à EF, activées lors du déroulement d'un ou plusieurs scénarios d'usage de services de télécommunications. Les séquences de composants fonctionnels service prises en compte dans le calcul de l'indicateur de pertinence d'une entité fonctionnelle service sont les séquences internes à l'entité fonctionnelle service de longueur 1 o maximale. On notera que : - cet indicateur i est fonction des séquences, pour un ou plusieurs services de télécommunications étudiés, de composants fonctionnels service susceptibles d'être regroupés dans des entités fonctionnelles (cf. Règle 15 d'Urbanisme n 5) ; - si EF contient n composants fonctionnels service, la longueur maximale N des séquences de composants fonctionnels service activées de EF est telle que n N= 2*f ND;*Cn +1, ;=1 20 où NDi est le nombre de données service référencées par le j-ème composant fonctionnel service de EF, et Cn est le symbole mathématique du nombre de combinaisons de 2 éléments, dont l'ordre n'a pas d'importance, parmi n éléments ; en effet, par hypothèse, chaque paire de composants fonctionnels peut impliquer, au plus, un échange de deux 25 messages entre chaque donnée service référencé par ces composants ; et - la notion de "séquence de longueur maximale" signifie que si EF = {CF1, CF2, CF3} et s'il existe dans un scénario une séquence ordonnée de messages CF1ù>CF2ù>CF3, alors les séquences incluses CF1ù>CF2 et CF2- CF3 ne seraient pas à prendre en compte pour le calcul de i(EF) ; 30 elles seraient à inclure dans le calcul de i(EF) uniquement si elles existaient sous forme de séquences de longueur maximale dans ce scénario ou dans un autre décrivant l'usage du service de télécommunications ; c'est le cas s'il existe une séquence CF1ù>CF2ù>CF4 et une séquence CF2- CF3- CF5 telles que CF4 et CF5 n'appartiennent pas à EF. 35 Si le seul scénario étudié est celui de la notification de présence représenté par la séquence "Identity Management- Profile - Identity Management- Profile- Identity Management', et si EF = {Identity Management, Profile}, alors (i -1) * NSi(EF ) =2 (1*0)+(2*0)+(3*0)+(4*1)+(5*0)+(6*0)4 0+0+0+0+1+0+0 15 I(EF) = puisque : NSi(EF) 2 - d'une part, N = 2 *UND; *Cz +1= 2 * 1* 3 * Cz +1 = 7, car J=1 Identity Management référence 1 donnée service (Identity û Identity Management û Stock û PFS), et Profile référence 3 données service (User profile û Profile û Stock û PFS, Availability rule û Profile û Flux û PFS, Availability rule û Profile û Stock û PFS), et - d'autre part, NS5(EF) = 1, car il existe une seule séquence de composants fonctionnels service de longueur 5, soit Identity Managementû Profile - Identity Managementû Profile - Identity Management. Règle d'Urbanisme n 7 : on ne regroupe des composants fonctionnels service que si ledit indicateur de pertinence est supérieur à un seuil S de regroupement de composants fonctionnels service défini de la façon suivante : N M (i + j -1) * (NSci(EF1) * NSc;(EF2 )) S (EF1, EF2) = N M + NSi (EF1 ) * NS; (EF2 ) i=i i=i N M 1(i û 1) * (NSi(EF1) û NSci(EF1 ))+j-1)*(NS;(EF2)ûNSc;(EF2)) i=2 j=2 N M NSi(EF~) * NS;(EF2) Oë: - N est la longueur maximale des séquences de composants fonctionnels service appartenant à une entité fonctionnelle service EF,, -M est la longueur maximale des séquences de composants fonctionnels service appartenant à une entité fonctionnelle service EF2, - NS;(EF1) est le nombre de séquences de i composants fonctionnels service, appartenant à EF,, activées lors du déroulement d'un ou plusieurs scénarios d'usage de services de télécommunications, - NSi(EF2) est le nombre de séquences de j composants fonctionnels service, appartenant à EF2, activées lors du déroulement d'un ou plusieurs scénarios 30 d'usage de services de télécommunications, - NSc1(EF1) est le nombre de scénarios différents où des séquences de i composants fonctionnels service, appartenant à EF1, sont activées, et - NSc(EF2) est le nombre de scénarios différents où des séquences de j composants fonctionnels service, appartenant à EF2, sont activées. Les séquences de composants fonctionnels service prises en compte dans le calcul du seuil de regroupement de deux entités fonctionnelles service sont les séquences internes à l'entité fonctionnelle service de longueur maximale. La définition de ce seuil a été choisie de manière à ce que l'on ait, pour 1 o un scénario global regroupant l'ensemble des scénarios d'usage de services de télécommunications étudiés, un nombre minimum d'échanges de message entre un élément de chaque séquence activée de i composants fonctionnels service de EF1 et un élément de chaque séquence activée de j composants fonctionnels service de EF2. Ce nombre minimum d'échanges est calculé à 15 partir du nombre de scénarios où apparaissent des séquences de i composants fonctionnels service de EF1 et du nombre de scénarios où apparaissent les séquences de j composants fonctionnels service de EF2. On notera que le seuil S autorisant un regroupement de deux entités fonctionnelles service est proposé ici comme minimum à atteindre pour 20 l'indicateur de pertinence I (cf. Règle d'Urbanisme n 6) de l'entité fonctionnelle service qui résulte du regroupement. Dans le cas de "User Context' considéré ici, on étudie le regroupement des entités fonctionnelles EF1 = {Identity Management} et EF2 = {Profile}, pour lesquelles le calcul du seuil S est le suivant : 25 1 1 + jù1)*(NSci(EF1)*NScj(EF2)) S (EF1, EF2) _ `=i j =i ~~NS~(EFi) * NSS(EF2) j=1 i=1 30 d'où S (EF1, EF2) =1*1*1 1 3*2 6 puisque : - N = M = 1, EF1 et EF2 ne comportant qu'un seul composant fonctionnel, - NSc1(EF1) = NSc1(EF2) = 1, un seul scénario d'usage de services de télécommunications étant étudié, - NS1(EF1) = 3, Identity Management apparaissant 3 fois dans la séquence Identity Management- Profile - Identity Management- Profile -Identity Management, et - NSc1(EF2) = 2, Profile apparaissant 2 fois dans la séquence Identity Management- Profile - Identity ManagementProfile -Identity 1 o Management. Or, I (EF1 U EF2) = 4 (cf. exemple Règle d'Urbanisme n 6). Donc : I (EF1 U EF2) > S (EF1, EF2), 15 et le regroupement de EF1 = {Identity Management} et EF2 = {Profile} est autorisé. Règle d'Urbanisme n 8 : on sélectionne le meilleur regroupement de composants fonctionnels service en fonction de la valeur respective la plus grande prise par un gain F apporté par le regroupement respectif de deux 20 entités fonctionnelles service EF1 et EF2, ledit gain F étant défini comme suit : I(EF1 u EF2) F (EF1u EF2) = S(FFI ,EF2) où I désigne l'indicateur de pertinence de l'entité fonctionnelle service résultante du regroupement, et S désigne le seuil de ce regroupement. Ainsi, le gain d'un regroupement de deux entités fonctionnelles service 25 permet de comparer les regroupements possibles d'entités fonctionnelles service. Plus précisément, le gain le plus élevé, parmi un ensemble de regroupements d'entités fonctionnelles service, correspond au regroupement optimal dans cet ensemble. Dans le cas de "User Context', où l'on étudie regroupement des entités 30 fonctionnelles EF1 = {Identity Management} et EF2 = {Profile} : r (EF1 v EF2) = I(EF1 v EF2) = 4 =24, S (EF1, EF2 ) puisque : I (EF1 U EF2) = 4 (cf. exemple Règle d'Urbanisme n 6), et S (EF1, EF2) = 16 (cf. exemple Règle d'Urbanisme n 7). 35 Règle d'Urbanisme n 9 : la détermination de quartiers fonctionnels service selon l'invention repose sur une définition itérative des entités fonctionnelles service telle que : o une entité fonctionnelle service peut être regroupée lors d'une itération si elle n'a été incluse dans aucune autres entités fonctionnelles service conçues lors des itérations précédentes ; o une entité fonctionnelle service n'est regroupée qu'une seule fois par itération ; o un regroupement de deux entités fonctionnelles service est possible lors d'une itération lorsque l'indicateur de pertinence métier du regroupement 1 o est supérieur ou égal au seuil de ce regroupement ; et o un regroupement de deux entités fonctionnelles service est modélisé lors d'une itération lorsque son gain est supérieur ou égal aux gains de regroupements d'entités possibles et non encore réalisés lors de cette itération. 15 L'objectif est de concevoir de façon itérative un arbre où chaque noeud est une entité fonctionnelle service représentant un regroupement d'entités fonctionnelles service. Plus précisément : - chaque feuille terminale de l'arbre est un composant fonctionnel service ciblé par un regroupement (cf. Règle d'Urbanisme n 5), 20 - l'initialisation du modèle comprend la définition d'un noeud contenant une, et une seule, feuille terminale, c'est-à-dire une entité fonctionnelle service contenant un et un seul composant fonctionnel service ciblé, et - l'arbre est alors réalisé de façon "bottom ù up", ce qui signifie que les regroupements sont évalués de façon itérative à partir du niveau des entités 25 fonctionnelles service le plus bas (initialisation du modèle) vers le niveau le plus haut. En résumé, selon l'invention, chaque message échangé entre instances d'informations service lors du déroulement d'un scénario décrivant l'utilisation d'un service de télécommunications est associé à un ou plusieurs flux entre 30 composants fonctionnels service. En effet : - lors du déroulement de chaque scénario, un ou plusieurs messages peuvent être échangés entre des instances d'informations service, - on extrait de chaque information service une ou plusieurs données service, - chaque message échangé peut donc activer une ou plusieurs dépendances 35 entre données service sous condition du respect de la Règle d'Urbanisme n 1 ou de la Règle d'Urbanisme n 2, - lorsqu'un message ne peut activer une dépendance entre données service, il est considéré comme non-réalisable au sens de la Règle d'Urbanisme n 3 (cette inefficacité peut être résolue par l'évolution du modèle dynamique 4o d'informations service ou du modèle de données service), et - l'activation d'une dépendance entre données service est équivalente à l'activation d'un flux entre composants fonctionnels service orienté de manière cohérente avec l'orientation du message échangé (cf. Règle d'Urbanisme n 4). Par ailleurs, le procédé selon l'invention est itératif (Règle d'Urbanisme n 9). Chaque activité d'une itération décrite dans l'algorithme est fondée sur les flux entre composants fonctionnels service (cf. Règle d'Urbanisme n 4), et fait appel aux moyens suivants : - la définition des composants fonctionnels service ciblés par un 1 o regroupement avec d'autres composants fonctionnels service (cf. Règle d'Urbanisme n 5), - la valorisation de chaque regroupement de composants fonctionnels service ciblés définie par un indicateur de pertinence défini dans la Règle d'Urbanisme n 6, 15 - l'estimation d'un seuil défini dans la Règle d'Urbanisme n 7 au dessous duquel l'indicateur de pertinence ne permet pas le regroupement des composants fonctionnels service, et - l'estimation des gains (cf. Règle d'Urbanisme n 8), fonction de l'indicateur de pertinence et du seuil, des différents regroupements possibles 20 permettant de sélectionner les meilleurs regroupements de composants fonctionnels service. Suite à l'initialisation du modèle arborescent de quartiers fonctionnels service décrite précédemment, l'algorithme de détermination itérative de ce modèle est, à titre d'exemple de mise en oeuvre, listé en Annexe 1. 25 Lorsque la détermination arborescente du modèle de quartiers fonctionnels service est terminée, c'est-à-dire lorsque plus aucun regroupement d'entités fonctionnelles service n'est possible, la définition des quartiers fonctionnels service est effectuée par le choix d'un niveau pertinent effectué par les urbanistes dans le modèle. Plus précisément, les quartiers sont 30 déduits des entités fonctionnelles service conçues à un des niveaux de l'arborescence. Le procédé selon l'invention permet donc d'assister, à l'appui du modèle arborescent ainsi conçu, les urbanistes du domaine qui doivent réaliser ce choix. 35 Dans le mode de réalisation présenté ci-dessous, le choix est effectué par les urbanistes de la zone "User Context' des plates-formes de services de télécommunications. En amont du mode de réalisation du procédé décrit dans ce mémoire, le résultat de l'analyse fonctionnelle dynamique de la zone "User Context" est 4o essentiel. Les scénarios d'usage de services de télécommunications restreints à cette zone avec, en référence, leurs représentations sous forme de diagramme de séquence UML, sont : - la souscription de présence d'un utilisateur (cf. figure 7), - la notification de la présence d'un utilisateur (cf. figure 3), - le transfert d'appel d'un utilisateur (cf. figures 8 et 9), - l'unification de messageries d'un utilisateur (cf. figure 10), et - la mise en configuration de la disponibilité d'un utilisateur (cf. figure 11). Le modèle dynamique d'informations service est cohérent avec le modèle statique d'informations service conçu pour la zone "User Context" (cf. figure 6). Les messages représentés dans ces diagrammes de séquence sont : - de type "requête" lorsqu'ils sont libellés : lien entre informations ù Request (exemple : has an ù Request), et - de type "réponse" lorsqu'ils sont libellés : lien entre informations ù Request (exemple : has an ù Response). Afin d'associer chaque message d'un diagramme de séquences UML, représentant un scénario d'usage de services de télécommunications réduit à la zone "User Context", à un ou plusieurs flux entre des composants fonctionnels service, un modèle de données service est nécessaire. Le modèle de données service utilisé ici est illustré sur la figure 12. La Règle d'Urbanisme n 1 donne la possibilité, pour chaque message des diagrammes de séquence UML résultant de l'analyse dynamique de la zone "User Context', d'activer une dépendance entre données service : o Scénario de souscription de présence : o has an ù Request émis par l'instance de Certified contact vers l'instance de Identity active has an ù mergeldentities, o defines ù Request émis par l'instance de Identity vers l'instance de Availability rule active defines ù createStaticProfile, o defines ù Response émis par l'instance de Availability rule vers l'instance de Identity active defines ù createStaticProfile, o owns ù Request émis par l'instance de Identity vers l'instance de User profile active owns ù createStaticProfile, o owns ù Response émis par l'instance de User profile vers l'instance de Identity active owns ù createStaticProfile, o has an ù Response émis par l'instance de Identity vers l'instance de Certified contact active has an ù mergeldentities, o Scénario de notification de présence : o owns ù Request émis par l'instance de Identity vers l'instance de User profile active owns ù createStaticProfile, 4o o owns ù Response émis par l'instance de User profile vers l'instance de Identity active owns ù createStaticProfile, o defines ù Request émis par l'instance de Identity vers l'instance de Availability rule active defines ù createStaticProfile, o defines ù Response émis par l'instance de Availability rule vers l'instance de Identity active defines ù createStaticProfile, o Scénario de transfert d'appel n : o has an ù Request émis par l'instance de Certified contact vers l'instance de Identity active has an ù mergeldentities, o owns ù Request émis par l'instance de Identity vers l'instance de Reachable address active owns ù createStaticProfile, o owns - Response émis par l'instance de Reachable address vers l'instance de Identity active owns ù createStaticProfile, o owns ù Request émis par l'instance de Identity vers l'instance de User profile active owns ù createStaticProfile, o owns ù Response émis par l'instance de User profile vers l'instance de Identity active owns ù createStaticProfile, o defines ù Request émis par l'instance de Identity vers l'instance de Availability rule active defines ù createStaticProfile, o defines ù Response émis par l'instance de Availability rule vers l'instance de Identity active defines ù createStaticProfile, o has an ù Response émis par l'instance de Identity vers l'instance de Certified contact active has an ù mergeldentities, o Scénario de transfert d'appel n 2 : o has an ù Request émis par l'instance de Certified contact vers l'instance de Identity active has an ù mergeldentities, o defines ù Request émis par l'instance de Identity vers l'instance de Availability rule active defines ù createStaticProfile, o defines ù Request émis par l'instance de Availability rule vers l'instance de Reachable address active defines ù interface fonctionnelle interne à Profile (activation double pour les données extraites de Availability rule, soient Availability rule ù Profile ù Flux ù PFS et Availability rule ù Profile ù Stock ù PFS), o defines ù Response émis par l'instance de Reachable address vers l'instance de Availability rule active defines ù interface fonctionnelle interne à Profile (activation double pour les données extraites de Availability rule, soient Availability rule ù Profile ù Flux ù PFS et Availability rule ù Profile ù Stock ù PFS), o defines ù Response émis par l'instance de Availability rule vers l'instance de Identity active defines ù createStaticProfile, o owns ù Request émis par l'instance de Identity vers l'instance de 4o User profile active owns ù createStaticProfile, o owns û Response émis par l'instance de User profile vers l'instance de Identity active owns û createStaticProfile, o has an û Response émis par l'instance de Identity vers l'instance de Certified contact active has an û mergeldentities, o Scénario d'unification de messageries : o owns û Request émis par l'instance de Identity vers l'instance de User profile active owns û createStaticProfile, o owns û Response émis par l'instance de User profile vers l'instance de Identity active owns û createStaticProfile, o owns û Request émis par l'instance de Identity vers l'instance de Reachable address active owns û createStaticProfile, o is compliant with - Request émis par l'instance de Communication service vers l'instance de Communication terminal active is compliant with û getUserCapablities et compliant with getDeviceCharacteristics, o is compliant with - Response émis par l'instance de Communication terminal vers l'instance de Communication service active is compliant with û getUserCapablities et compliant with û getDeviceCharacteristics, o owns Response émis par l'instance de Reachable address vers l'instance de Identity active owns û createStaticProfile, o Scénario de configuration de disponibilité : o has an û Request émis par l'instance de Certified contact vers l'instance de Identity active has an û mergeldentities, o owns û Request émis par l'instance de Identity vers l'instance de User profile active owns û createStaticProfile, o owns û Response émis par l'instance de User profile vers l'instance de Identity active owns û createStaticProfile, o defines û Request émis par l'instance de Identity vers l'instance de Availability rule active defines û createStaticProfile, o defines û Request émis par l'instance de Availability rule vers l'instance de Reachable address active defines û interface fonctionnelle interne à Profile (activation double pour les données extraites de Availability rule, soient Availability rule û Profile û Flux û PFS et Availability rule û Profile û Stock û PFS), o is compliant with - Request émis par l'instance de Communication service vers l'instance de Communication terminal active is compliant with û getUserCapablities et compliant with getDeviceCharacteristics, 4o o is compliant with - Response émis par l'instance de Communication terminal vers l'instance de Communication service active is compliant with ù getUserCapablities et compilant with getDeviceCharacteristics, o defines ù Response émis par l'instance de Reachable address vers l'instance de Availability rule active defines ù interface fonctionnelle interne à Profile (activation double pour les données extraites de Availability rule, soient Availability rule ù Profile ù Flux ù PFS et Availability rule ù Profile ù Stock ù PFS), et o defines ù Response émis par l'instance de Availability rule vers l'instance de Identity active defines ù createStaticProfile. 1 o La Règle d'Urbanisme n 2 permet de traiter les messages reçus par des informations service d'où sont extraites plusieurs données service, soit Availability rule et Communication terminal dans ce mode de réalisation : o Scénario de souscription de présence : o defines ù Request émis par l'instance de Identity vers l'instance de 15 Availability rule active scission de Availability rule ù interface fonctionnelle interne à Profile, o Scénario de notification de présence : o defines ù Request émis par l'instance de Identity vers l'instance de Availability rule active scission de Availability rule ù interface 20 fonctionnelle interne à Profile, o Scénario de transfert d'appel n o defines ù Request émis par l'instance de Identity vers l'instance de Availability rule active scission de Availability rule ù interface fonctionnelle interne à Profile 25 o Scénario de transfert d'appel n 2 : o defines ù Request émis par l'instance de Identity vers l'instance de Availability rule active scission de Availability rule ù interface fonctionnelle interne à Profile, o defines ù Response émis par l'instance de Reachable address vers 30 l'instance de Availability rule active scission de Availability rule ù interface fonctionnelle interne à Profile (activation double pour les données extraites de Availability rule, soient Availability rule ù Profile ù Flux ù PFS et Availability rule ù Profile ù Stock ù PFS), o Scénario de configuration de disponibilité : 35 o defines ù Request émis par l'instance de Identity vers l'instance de Availability rule active scission de Availability rule ù interface fonctionnelle interne à Profile,et o defines ù Response émis par l'instance de Reachable address vers l'instance de Availability rule active defines ù interface fonctionnelle 40 interne à Profile (activation double pour les données extraites de Availability rule, soient Availability rule ù Profile ù Flux ù PFS et Availability rule ù Profile ù Stock ù PFS). La Règle d'Urbanisme n 3 permet de préciser les messages entre instances d'informations service non réalisables pour cause de non respect des Règles d'urbanisme n 1 ou n 2 : o Scénario de souscription de présence : o defines ù Request émis par l'instance de Identity vers l'instance de Availability rule ne respecte pas de manière exhaustive la Règle d'Urbanisme n 1 puisqu'il n'y a pas de dépendance de la donnée 1 o service Identity ù Identity Management ù Stock ù PFS vers la donnée service Availability rule ù Profile ù Flux ù PFS, o defines ù Response émis par l'instance de Availability rule vers l'instance de Identity ne respecte pas de manière exhaustive la Règle d'Urbanisme n 1 puisqu'il n'y a pas de dépendance de la donnée 15 service Identity ù Identity Management ù Stock ù PFS vers la donnée service Availability rule ù Profile ù Flux ù PFS, o Scénario de notification de présence : o defines ù Request émis par l'instance de Identity vers l'instance de Availability rule ne respecte pas de manière exhaustive la Règle 20 d'Urbanisme n 1 puisqu'il n'y a pas de dépendance de la donnée service Identity ù Identity Management ù Stock ù PFS vers la donnée service Availability rule ù Profile ù Flux ù PFS, o defines ù Response émis par l'instance de Availability rule vers l'instance de Identity ne respecte pas de manière exhaustive la Règle 25 d'Urbanisme n 1 puisqu'il n'y a pas de dépendance de la donnée service Identity ù Identity Management ù Stock ù PFS vers la donnée service Availability rule ù Profile ù Flux ù PFS, o Scénario de transfert d'appel n 1 : o triggers ù Request émis par l'instance de Reachable address vers 30 l'instance de Communication service ne respecte pas la Règle d'Urbanisme n 1 puisque le type requête est incompatible avec l'orientation de la dépendance triggers ù getStaticProfile, o triggers ù Response émis par l'instance de Communication service vers l'instance de Reachable address ne respecte pas la Règle 35 d'Urbanisme n 1 puisque le type réponse est incompatible avec l'orientation de la dépendance triggers ù getStaticProfile, o defines ù Request émis par l'instance de Identity vers l'instance de Availability rule ne respecte pas de manière exhaustive la Règle d'Urbanisme n 1 puisqu'il n'y a pas de dépendance de la donnée 4o service Identity ù Identity Management ù Stock ù PFS vers la donnée service Availability rule ù Profile ù Flux ù PFS, o defines ù Response émis par l'instance de Availability rule vers l'instance de Identity ne respecte pas de manière exhaustive la Règle d'Urbanisme n 1 puisqu'il n'y a pas de dépendance de la donnée service Identity ù Identity Management ù Stock ù PFS vers la donnée service Availability rule ù Profile ù Flux ù PFS, o Scénario de transfert d'appel n 2 : o defines ù Request émis par l'instance de Identity vers l'instance de Availability rule ne respecte pas de manière exhaustive la Règle d'Urbanisme n 1 puisqu'il n'y a pas de dépendance de la donnée 1 o service Identity ù Identity Management ù Stock ù PFS vers la donnée service Availability rule ù Profile ù Flux ù PFS, o triggers ù Request émis par l'instance de Reachable address vers l'instance de Communication service ne respecte pas la Règle d'Urbanisme n 1 puisque le type requête est incompatible avec 15 l'orientation de la dépendance triggers ù getStaticProfile, o triggers ù Response émis par l'instance de Communication service vers l'instance de Reachable address ne respecte pas la Règle d'Urbanisme n 1 puisque le type réponse est incompatible avec l'orientation de la dépendance triggers ù getStaticProfile, 20 o defines ù Response émis par l'instance de Availability rule vers l'instance de Identity ne respecte pas de manière exhaustive la Règle d'Urbanisme n 1 puisqu'il n'y a pas de dépendance de la donnée service Identity ù Identity Management ù Stock ù PFS vers la donnée service Availability rule ù Profile ù Flux ù PFS, 25 o Scénario d'unification de messageries : o triggers ù Request émis par l'instance de Reachable address vers l'instance de Communication service ne respecte pas la Règle d'Urbanisme n 1 puisque le type requête est incompatible avec l'orientation de la dépendance triggers ù getStaticProfile, 30 o is compilant with - Request émis par l'instance de Communication service vers l'instance de Communication terminal ne respecte pas la Règle d'Urbanisme n 2 puisqu'il n'y a pas de dépendance entre la donnée service Communication terminal ù User Capability ù Stock ù PFS et la donnée service Communication terminal ù Device 35 Capabilities ù Codification ù PFS, o triggers ù Response émis par l'instance de Communication service vers l'instance de Reachable address ne respecte pas la Règle d'Urbanisme n 1 puisque le type réponse est incompatible avec l'orientation de la dépendance triggers ù getStaticProfile, 4o o Scénario de configuration de disponibilité : o defines û Request émis par l'instance de Identity vers l'instance de Availability rule ne respecte pas de manière exhaustive la Règle d'Urbanisme n 1 puisqu'il n'y a pas de dépendance de la donnée service Identity û Identity Management û Stock û PFS vers la donnée service Availability rule û Profile û Flux û PFS, o triggers û Request émis par l'instance de Reachable address vers l'instance de Communication service ne respecte pas la Règle d'Urbanisme n 1 puisque le type requête est incompatible avec l'orientation de la dépendance triggers û getStaticProfile, o is compilant with - Request émis par l'instance de Communication service vers l'instance de Communication terminal ne respecte pas la Règle d'Urbanisme n 2 puisqu'il n'y a pas de dépendance entre la donnée service Communication terminal û User Capability û Stock û PFS et la donnée service Communication terminal û Device Capabilities û Codification û PFS, o triggers û Response émis par l'instance de Communication service vers l'instance de Reachable address ne respecte pas la Règle d'Urbanisme n 1 puisque le type réponse est incompatible avec l'orientation de la dépendance triggers û getStaticProfile, et o defines û Response émis par l'instance de Availability rule vers l'instance de Identity ne respecte pas de manière exhaustive la Règle d'Urbanisme n 1 puisqu'il n'y a pas de dépendance de la donnée service Identity û Identity Management û Stock û PFS vers la donnée service Availability rule û Profile û Flux û PFS. On notera que : o l'irrespect non exhaustif de la Règle d'Urbanisme n 1 pour le message defines û Request est dû au fait qu'il active defines û createStaticProfile, dépendance de la donnée service Identity û Identity Management û Stock û PFS vers la donnée service Availability rule û Profile û Stock û PFS, o l'irrespect non exhaustif de la Règle d'Urbanisme n 1 pour le message defines û Response est dû au fait qu'il active la dépendance defines û createStaticProfile de la donnée service Identity û Identity Management û Stock û PFS vers la donnée service Availability rule û Profile û Stock û PFS, o l'inefficacité des messages triggers û Request et triggers û Response entre l'instance de Reachable address et l'instance de Communication service devrait être à traiter prioritairement par les urbanistes de la zone "User Context' car elle rend impossible tout échange vers une instance de Communication service, à l'exception d'un scénario. La Règle d'Urbanisme n 4 permet de représenter pour chaque scénario 4o d'usage de services de télécommunications, restreint à la zone "User Context', les flux activés entre composants fonctionnels service équivalents aux dépendances entre données service précédemment activées : o Scénario de souscription de présence : o has an ù Request émis par l'instance de Certified contact vers l'instance de Identity active has an ù mergeldentities, i.e. le flux Address Book ù> Identity Management, o defines ù Request émis par l'instance de Identity vers l'instance de Availability rule active defines ù createStaticProfile, i.e. le flux Identity Management ù> Profile, o defines ù Request émis par l'instance de Identity vers l'instance de 1 o Availability rule active scission de Availability rule ù interface fonctionnelle interne à Profile, i.e. le flux Profile ù Profile, o defines ù Response émis par l'instance de Availability rule vers l'instance de Identity active defines ù createStaticProfile, i.e. le flux Profile ù Identity Management, 15 o owns ù Request émis par l'instance de Identity vers l'instance de User profile active owns ù createStaticProfile, i.e. le flux Identity Management ù Profile, o owns ù Response émis par l'instance de User profile vers l'instance de Identity active owns ù createStaticProfile, i.e. le flux Profile ù 20 Identity Management, o has an ù Response émis par l'instance de Identity vers l'instance de Certified contact active has an -mergeldentities, i.e. le flux Identity Management ù> Address Book, o Scénario de notification de présence : 25 o owns ù Request émis par l'instance de Identity vers l'instance de User profile active owns ù createStaticProfile, i.e. le flux Identity Management ù Profile, o owns ù Response émis par l'instance de User profile vers l'instance de Identity active owns ù createStaticProfile, i.e. le flux Profile ù 30 Identity Management, o defines ù Request émis par l'instance de Identity vers l'instance de Availability rule active defines ù createStaticProfile, i.e. le flux Identity Management ù> Profile, o defines ù Request émis par l'instance de Identity vers l'instance de 35 Availability rule active scission de Availability rule ù interface fonctionnelle interne à Profile, i.e. le flux Profile ù Profile, o defines ù Response émis par l'instance de Availability rule vers l'instance de Identity active defines ù createStaticProfile, i.e. le flux Profile ù Identity Management, 4o o Scénario de transfert d'appel n l : o has an ù Request émis par l'instance de Certified contact vers l'instance de Identity active has an - mergeldentities, i.e. le flux Address Book ù> Identity Management, o owns ù Request émis par l'instance de Identity vers l'instance de Reachable address active owns - createStaticProfile, i.e. le flux Identity Management ù Profile, o owns - Response émis par l'instance de Reachable address vers l'instance de Identity active owns - createStaticProfile, i.e. le flux Profile ù Identity Management, o owns ù Request émis par l'instance de Identity vers l'instance de User profile active owns ù createStaticProfile, i.e. le flux Identity Management ù Profile, o owns ù Response émis par l'instance de User profile vers l'instance de Identity active owns ù createStaticProfile, i.e. le flux Profile ù Identity Management, o defines ù Request émis par l'instance de Identity vers l'instance de Availability rule active defines ù createStaticProfile, i.e. le flux Identity Management ù> Profile, o defines ù Request émis par l'instance de Identity vers l'instance de Availability rule active scission de Availability rule ù interface fonctionnelle interne à Profile, i.e. le flux Profile ù Profile, o defines ù Response émis par l'instance de Availability rule vers l'instance de Identity active defines ù createStaticProfile, i.e. le flux Profile ù Identity Management, o has an ù Response émis par l'instance de Identity vers l'instance de Certified contact active has an - mergeldentities, i.e. le flux Identity Management ù Address Book, o Scénario de transfert d'appel n 2 : o has an ù Request émis par l'instance de Certified contact vers l'instance de Identity active has an - mergeldentities, i.e. le flux Address Book ù Identity Management, o defines ù Request émis par l'instance de Identity vers l'instance de Availability rule active defines ù createStaticProfile, i.e. le flux Identity Management ù Profile, o defines ù Request émis par l'instance de Identity vers l'instance de Availability rule active scission de Availability rule ù interface fonctionnelle interne à Profile, i.e. le flux Profile ù Profile, o defines ù Request émis par l'instance de Availability rule vers l'instance de Reachable address active defines ù interface 4o fonctionnelle interne à Profile (activation double pour les données extraites de Availability rule, soient Availability rule ù Profile ù Flux ù PFS et Availability rule ù Profile ù Stock ù PFS) , i.e. le flux Profile ù Profile, o defines ù Response émis par l'instance de Reachable address vers l'instance de Availability rule active defines ù interface fonctionnelle interne à Profile (activation double pour les données extraites de Availability rule, soient Availability rule ù Profile ù Flux ù PFS et Availability rule ù Profile ù Stock ù PFS) , i.e. le flux Profile ù Profile, o defines ù Response émis par l'instance de Reachable address vers l'instance de Availability rule active scission de Availability rule ù 1 o interface fonctionnelle interne à Profile (activation double pour les données extraites de Availability rule, soient Availability rule ù Profile ù Flux ù PFS et Availability rule ù Profile ù Stock ù PFS) , i.e. le flux Profile ù> Profile, o defines ù Response émis par l'instance de Availability rule vers 15 l'instance de Identity active defines ù createStaticProfile, i.e. le flux Profile ù Identity Management, o owns ù Request émis par l'instance de Identity vers l'instance de User profile active owns ù createStaticProfile, i.e. le flux Identity Management ù Profile, 20 o owns ù Response émis par l'instance de User profile vers l'instance de Identity active owns ù createStaticProfile, i.e. le flux Profile ù Identity Management, o has an ù Response émis par l'instance de Identity vers l'instance de Certified contact active has an -mergeldentities, i.e. le flux Identity 25 Management ù> Address Book, o Scénario d'unification de messageries : o owns ù Request émis par l'instance de Identity vers l'instance de User profile active owns ù createStaticProfile, i.e. le flux Identity Management ù Profile, 30 o owns ù Response émis par l'instance de User profile vers l'instance de Identity active owns ù createStaticProfile, i.e. le flux Profile ù Identity Management, o owns ù Request émis par l'instance de Identity vers l'instance de Reachable address active owns - createStaticProfile, i.e. le flux 35 Identity Management ù> Profile, o is compliant with Request émis par l'instance de Communication service vers l'instance de Communication terminal active is compliant with ù getUserCapablities et compliant with ù getDeviceCharacteristics, i.e. les flux User Facing Service ù User 4o Capability et User Facing Service ù> Device Capabilities, o is compilant with - Response émis par l'instance de Communication terminal vers l'instance de Communication service active is compilant with ù getUserCapablities et compilant with ù getDeviceCharacteristics, i.e. les flux User Facing Service ù User Capability et User Facing Service ù> Device Capabilities, o owns -Response émis par l'instance de Reachable address vers l'instance de Identity active owns - createStaticProfile, i.e. le flux Profile ù> Identity Management, o Scénario de configuration de disponibilité : o has an ù Request émis par l'instance de Certified contact vers l'instance de Identity active has an - mergeldentities, i.e. le flux Address Book ù Identity Management, o owns ù Request émis par l'instance de Identity vers l'instance de User profile active owns ù createStaticProfile, i.e. le flux Identity Management ù> Profile, o owns ù Response émis par l'instance de User profile vers l'instance de Identity active owns ù createStaticProfile, i.e. le flux Profile ù Identity Management, o defines ù Request émis par l'instance de Identity vers l'instance de Availability rule active defines ù createStaticProfile, i.e. le flux Identity Management ù Profile, o defines ù Request émis par l'instance de Identity vers l'instance de Availability rule active scission de Availability rule ù interface fonctionnelle interne à Profile, i.e. le flux Profile ù Profile, o defines ù Request émis par l'instance de Availability rule vers l'instance de Reachable address active defines ù interface fonctionnelle interne à Profile (activation double pour les données extraites de Availability rule, soient Availability rule ù Profile ù Flux ù PFS et Availability rule ù Profile ù Stock ù PFS) , i.e. le flux Profile ù Profile, o is compilant with - Request émis par l'instance de Communication service vers l'instance de Communication terminal active is compilant with ù getUserCapablities et compilant with ù getDeviceCharacteristics, i.e. les flux User Facing Service ù User Capability et User Facing Service ù> Device Capabilities, o is compilant with - Response émis par l'instance de Communication terminal vers l'instance de Communication service active is compilant with ù getUserCapablities et compilant with ù getDeviceCharacteristics, i.e. les flux User Facing Service ù User 4o Capability et User Facing Service ù> Device Capabilities, o defines ù Response émis par l'instance de Reachable address vers l'instance de Availability rule active defines ù interface fonctionnelle interne à Profile (activation double pour les données extraites de Availability rule, soient Availability rule ù Profile ù Flux ù PFS et Availability rule ù Profile ù Stock ù PFS) , i.e. le flux Profile ù> Profile, o defines ù Response émis par l'instance de Reachable address vers l'instance de Availability rule active defines ù interface fonctionnelle interne à Profile (activation double pour les données extraites de Availability rule, soient Availability rule ù Profile ù Flux ù PFS et Availability rule ù Profile ù Stock ù PFS) , i.e. le flux Profile ù> Profile, o defines ù Response émis par l'instance de Availability rule vers l'instance de Identity active defines ù createStaticProfile, i.e. le flux Profile ù> Identity Management, et o has an ù Response émis par l'instance de Identity vers l'instance de 15 Certified contact active has an - mergeldentities, i.e. le flux Identity Management ù Address Book. La mise en oeuvre du procédé itératif pour la zone "User Context' permet de déterminer un modèle de quartiers fonctionnels service de façon arborescente. La description de cette seconde partie du présent mode de 20 réalisation est faite ci-dessous par itération, et dans chaque itération, pour chaque règle d'urbanisme à respecter. Initialisation La Règle d'Urbanisme n 5 permet de définir les composants 25 fonctionnels service ciblés par un regroupement avec d'autres composants fonctionnels service et d'en déduire les séquences de composants fonctionnels service activées. Les composants fonctionnels service ciblés par un regroupement sont, d'après les flux activés définis dans le paragraphe précédent : 30 o Address Book, o Device Capabilities, o Identity Management, o Profile, o User Capability, et 35 o User Facing Service. Les séquences de composants fonctionnels service activées lors du déroulement de chaque scénario d'usage de services de télécommunications, restreint à la zone "User Context', sont donc : o Scénario de souscription de présence : 4o o Address Book ù> Identity Management ù> Profile ù> Identity Management ù Profile ù Identity Management ù Address Book, o Scénario de notification de présence : o Identity Management - Profile -Identity Management - Profile ù> Identity Management, o Scénario de transfert d'appel n : o Address Book ù> Identity Management ù> Profile (arrêt de séquence lors du déroulement du scénario), o User Facing Service (arrêt de séquence lors du déroulement du scénario), o Profile -Identity Management - Profile - Identity Management 10 ù> Profile ù> Identity Management ù> Address Book, o Scénario de transfert d'appel n 2 : o Address Book - Identity Management - Profile (arrêt de séquence lors du déroulement du scénario), o User Facing Service (arrêt de séquence lors du déroulement du 15 scénario), o Profile - Identity Management -Profile - Identity Management - Address Book, o Scénario d'unification de messageries : o Identity Management - Profile - Identity Management -Profile 20 (arrêt de séquence lors du déroulement du scénario), o User Facing Service - (User Capability OU Device Capabilities) - User Facing Service (arrêt de séquence lors du déroulement du scénario), o Profile ù> Identity Management, o Scénario de configuration de disponibilité : 25 o Address Book ù> Identity Management ù> Profile ù> Identity Management - Profile (arrêt de séquence lors du déroulement du scénario), o User Facing Service - (User Capability OU Device Capabilities) - User Facing Service (arrêt de séquence lors du déroulement du scénario), et o Profile - Identity Management - Address Book. 30 Lors de l'initialisation du modèle de quartiers fonctionnels service (cf. figure 13), une entité fonctionnelle service est créée de manière à contenir un seul composant fonctionnel service ciblé par le regroupement : o EF01 = {Address Book}, o EF02 = { Device Capabilities}, 35 o EF03 = {Identity Management}, o EF04 = {Profile}, o EF05 = {User Capability}, et o EF06 = {User Facing Service}. Première itération 4o La Règle d'Urbanisme n 6 permet d'évaluer l'indicateur de pertinence de regroupement de deux entités fonctionnelles service initialisées précédemment. Cet indicateur est non nul s'il existe, dans une séquence au moins un flux activé entre deux composants fonctionnels service tels que chaque composant appartienne à une des deux entités à regrouper et que l'entité ne soit pas la même : o EF01 U EF03 = { Address Book , Identity Management} I (EF01 U EF03) = s (iù1)*NSi(EFoiuEF03) =2 s NSi(EFoi u EF03) car N S 1 (EF01 U EF03) = 11 et NS2 (EF01 U EF03) = 8. (1*0)+(2*2) 1 (EF02 U EF06) = `-~ 3 ù =1, 1NSi(EFO2 uEF06) 2+0+2 i-1 car NS1(EF02UEF06)=2etNS3(EF02UEF06)=2. o EF03 U EF04 = {Identity Management, Profile} 9 1(i -1) * NSi(EF03 u EF04 ) 1 (EF03 U EF04) = `-2 9 1 NSi(EF03 u EF04 ) i=1 I (EF03 U EF04) = (1*4)+(2*0)+(3*3)+(4*2)+(5*1)+(6*0)+(7*0)+(8*0) 0+4+0+3+2+1+0+0+0 I (EF03 U EF04) = 5 , car NS2 (EF03 U EF04) = 4, NS4 (EF03 U EF04) = 3, NS5 (EF03 U EF04) = 2 et NS6 (EF03 U EF04) = 1. o EF05 U EF06 = {User Capability, User Facing Service} (1*8)+(2*0)+(3*0)+(4*0) 8 11+8+0+0+0 19' o EF02 U EF06 = {Device Capabilities, User Facing Service} 3 1(i -1) * NSi(EFO2 u EF06 )20 34 1(iù1)*NSi(EF05 uEF06) (1*0)+(2*2) I (EF05 U EF06) = 3 = =1, 1NSi(EFOS uEF06) 2+0+2 i=1 car N S 1 (EF05 U EF06) = 2 et N S3 (EF05 U EF06) = 2. La Règle d'Urbanisme n 7 permet d'évaluer le seuil des regroupements 5 de deux entités fonctionnelles service dont la pertinence vient d'être évaluée : o EF01 = {Address Book} et EF03 = {Identity Management} Il(i+j -1)*(NSci(EF01)*NSc;(EF03)) S (EF01, EF03) = `_1 '_l II NSi(EFO1) * NS1(EF03 ) i=1 i=1 car NSci (EF01) = 4, NSci(EF03) = 6, NS1(EF01) = 8 et NS, (EF03) = 19. o EF02 = { Device Capabilities} et EF06 = {User Facing Service} Il(i+j -1)*(NSci(EF02)*NSc;(EF06)) S (EF02, EF06) = 1=1 3=1 II NSi(EFO2) * NS1(EF06 ) i=1 i=1 S (EF01, EF03) =1* 4 * 6 3 8*19 19' 10 S(EF02,EF06)=1*2*4 2 2*6 3 15 car NSci(EF02) = 2, NSci(EF06) = 4, NS1(EF02) = 2 et NS1(EF06) = 6. o EF03 = {Identity Management} et EF04 = {Profile} II (i + j -1) * (NSci(EF03) * NSc;(EF04 )) S (EF03 , EF04) = `=1 '=l II NSi(EF03) * NS1(EF04 ) i=1 i=1 S (EF03 , EF04) _1*6*6 36 19*17 323' car NSc1(EF03) = 6, NSc1(EF04) = 6, NS1(EF03) = 19 et NS1(EF04) = 17. 2o o EF05 = {User Capability} et EF06 = {User Facing Service} 1 35 II (i + j -1) * (NSci(EF05) * NScj(EF06 )) S ( EF05, EF06) = `=1 j =1 1 1 II NSi(EF05) * NSj (EF06 ) j=1 i=1 1*2*4 2 S(EF05,EF06)= 2*6 3' car NSci(EF05) = 2, NSc1(EF06) = 4, NS1(EF05) = 2 et NS1(EF06) = 6. La Règle d'Urbanisme n 8 permet d'évaluer le gain apporté par chaque regroupement de deux entités fonctionnelles service dont la pertinence et le seuil viennent d'être évalués : o EF01 = {Address Book} et EF03 = {Identity Management} I (EF01 U EF03) = 8 et S (EF01, EF03) =19 I(EFuEF) F (EF01 U EF03) = 01 03 S(EF01 , EF03 ) o EF02 = { Device Capabilities} et EF06 = {User Facing Service} 2 I (EF02 U EF06) = 1 et S (EF02 , EF06) = 3 I (EFuEF) 1 3 F (EF02 U EF06) = 02 06 _ = ù S (EFO2 , EF06) 23 2 o EF03 = {Identity Management} et EF04 = {Profile} I (EF03 U EF04) = 5 et S (EF03 , EF04) = 3 6 F (EF03 U EF04) = I(EF03 u EF04) 13 4199 S (EF03 , EF04) 3x23 180 o EF05 = {User Capability} et EF06 = {User Facing Service} 2 I (EF05 U EF06) = 1 et S (EF05 , EF06) =ù3 F (EF05 U EF06) I(EF05 u EF06) 3 ) = S(EF05 EF06 ) La Règle d'Urbanisme n 9 permet, à l'appui des meilleurs gains apportés par les différents regroupements de deux entités fonctionnelles service étudiés, de concevoir le niveau supérieur du modèle de quartiers fonctionnels service. En effet, les entités fonctionnelles services à ajouter au modèle (cf. figure 14) sont, dans l'ordre décroissant des gains de regroupement : o EF11 = EF03 U EF04 avec EF03 = {Identity Management}, EF04 = {Profile} et F (EF03 U EF04) = 23,33, et o EF12 = EF02 U EF06 avec EF02 = {User Capability}, EF06 = {User Facing Service} et F (EF02 U EF06) = 1, 5. 1 o II est à noter que : o EF01 = {Address Book} et EF03 = {Identity Management} ne peuvent être regroupées car EF03 a déjà été regroupée dans EF11, et o EF05 = {Device Capabilities} et EF06 = {User Facing Service} ne peuvent être regroupées car EF06 a déjà été regroupée dans EF12. 15 Les gains étant identiques pour les regroupements de EF02 et EF06, et de EF05 et EF06, le choix (fait de façon arbitraire) est ici celui du premier regroupement traité. Dans ce mode de réalisation, le choix indiqué est celui issu du codage informatique du procédé, où le premier regroupement traité est celui de EF02 et EF06 . 20 Deuxième itération L'indicateur de pertinence de regroupement de deux entités fonctionnelles service est non nul s'il existe, dans une séquence, au moins un flux activé entre deux composants fonctionnels service tels que chaque composant appartienne à une des deux entités à regrouper et tels que ces 25 entités soient distinctes. La Règle d'Urbanisme n 6 permet d'évaluer l'indicateur de pertinence de regroupement de deux entités fonctionnelles service telles qu'aucune ne soit incluse dans une autre entité fonctionnelle existante : o EF11 U EF01 = { Identity Management, Profile, Address Book} 49 (i -1) * NSi(EFn u EFo1) 49 NSi(EFi1 u EFo1) I (EF11 U EF01) _ (1*1)+(2*3)+(3*1)+(4*3)+(5*0)+(6*2) -17 0+1+3+1+3+0+2 5 car NS2 (EF11 U EF01) = 1, NS3 (EF11 U EF01) = 3, NS4 (EF11 U EF01) = 1, NS5(EF11 U EF01) = 3, et NS, (EF11 UEF01)=2. o EF12 U EF02 = {User Capability, User Facing Service, Device 35 Capabilities} 30 1 (EF11 U EF01) = i=2 7 (i -1) * NSi(EF12 u EF02 ) I (EF12 U EF02) = i=2 car N S 1 (EF05 U EF06) = 2 et N S5 (EF05 U EF06) = 2. La Règle d'Urbanisme n 7 permet d'évaluer le seuil des regroupements de 2 entités fonctionnelles service dont la pertinence vient d'être évaluée : o EF11 = {Identity Management, Profile} et EF01= {Address Book} 9 1 II (i + j -1) * (NSci(EF11) * NScj(EF01)) S (EF11, EF01) = i=1 j=1 + II NSi(EF11) * NSj(EFo1) j=1 i=1 9 (iù1)*(NSi(EF11)ùNSc(EF11)) 9 1 NSi (EF11) * NSj (EF01) j=1 i=1 S(EF11,EF01)= (1*0*4)+(2*4*4)+(3*0*4)+(4*3*4)+(5*2*4)+(6*1*4) (0*8)+(4*8)+(0*8)+(3*8)+(2*8)+(1*8) S(EF11,EF01)=5, car NSc2(EF11) = NS2(EF11) = 4, NSc4(EF11) = NS4(EF11) = 3, 15 NSc5(EF11) = NS5(EF11) = 2, NSc6(EF11) = NS6(EF11) = 1, NSci(EF01) = 4, et NS1(EF01) = 8. o EF12 = {User Capability, User Facing Service} et EF02 = {Device Capabilities} 3 1 II (i + j -1) * (NSci(EF12) * NScj(EF02 )) S (EF12 , EF02) = i=1 j=1 +3 1 II NSi(EF12) * NSj(EF02 ) j=1 i=1 3 (i -1) * (NSi(EF12) ù NSc(EF12 )) 20 3 1 1 1 NSi(EF12) * NSj(EF02 ) j=1 i=1 7 NSi(EF12 v EF02 ) i=1 (1*0)+(2*0)+(3*0)+(4*2)+(5*0)+(6*0) -2 I (EF12 U EF02) = 2+0+0+0+2+0+ 0 i=2 i=2 S (EF12, EF02) =(1*2*2)+(2*0*2)+(3*2*2) = 2, (2*2)+(0*2)+(2*2) car NSc1 (EFi2) = NS1 (EFi2) = 2, NSc3 (EFi2) = NS3 (EFi2) = 2, et NSci(EF02) = NS,(EF02)= 2. La Règle d'Urbanisme n 8 permet d'évaluer le gain apporté par chaque 5 regroupement de deux entités fonctionnelles service dont la pertinence et le seuil viennent d'être évalués : o EF11 = {Identity Management, Profile} et EF01= {Address Book} I (EF11 U EF01) = 5 et S (EF11, EF01) = 17 I(EF11 u EFo1) 17 9 F(EF11 UEF01)= 9~ S (EF11 , EFo1) o EF12 = {User Capability, User Facing Service} et EF02 = {Device Capabilities} I (EF12 U EF02) = 2 et S (EF12, EF02) = 2 F (EF12 U EF02) = I (EF12 u EFO2) = 2 ù = 1. S (EF12 , EFO2) 2 La Règle d'Urbanisme n 9 permet, à l'appui des meilleurs gains apportés par les différents regroupements de deux entités fonctionnelles service étudiés, de concevoir le niveau supérieur du modèle de quartiers fonctionnels service. En effet, les entités fonctionnelles service à ajouter au modèle (cf. figure 15) sont, dans l'ordre décroissant des gains de regroupement : o EF21 = EF11 U EF01 avec EF11 = {Identity Management, Profile}, EF01 = {Address Book} et F (EF11 U EF01) = 1,89, o EF22 = EF12 U EF02 avec EF12 = {User Capability, User Facing Service}, EF02 = {Device Capabilities} et F (EF12 U EF02) = 1. Fin La Règle d'Urbanisme n 6 ne peut être appliquée aux entités EF21 = {Identity Management, Profile, Address Book} et EF22 = {User Capability, User Facing Service, Device Capabilities}, car il n'existe aucune flux activé entre deux composants fonctionnels service appartenant à une des deux entités à regrouper et tels que ces entités soient 30 distinctes. La détermination du modèle arborescent des quartiers fonctionnels service dans ce mode de réalisation, est donc terminée. Les deux niveaux du modèle ainsi obtenu induisent deux alternatives aux urbanistes lors de la définition des quartiers fonctionnels service de la zone "User Context' : o Première alternative : o QF11 = EF01 = {Address Book}, o QF12 = EF02 = {Device Capabilities}, o QF13 = EF11 = {Identity Management, Profile}, et o QF14 = EF12 = {User Capability, User Facing Service}. o Deuxième alternative : o QF21 = EF21 = {Identity Management, Profile, Address Book}, et o QF22 = EF22 = {User Capability, User Facing Service, Device 1 o Capabilities}. ANNEXE 1 Algorithme de détermination itérative d'un modèle arborescent de quartiers fonctionnels service 5 k=0; Faire /* k itération du regroupement des entités fonctionnelles service */ { 10 n = 0 ; k++ ; Pour i de 1 à Nk_1 { Pour j de i+1 à Nk_1 { M(i, j) = 0 ; /* Initialisation des éléments de la matrice des gains du regroupement de EF(k_1); et EF(k_1)i */ } AR(i) = 1 ; /* Initialisation de l'autorisation du regroupement de EF(k_1); avec une autre "entité fonctionnelle service" */ } Pour i de 1 à Nk_1 { Pour j de i+1 à Nk_1 { 25 Si I(EF(k_1)ju EF(k_1)i)>S(EF(k_1);, EF(k_1)i) /* Vérification que l'indicateur de pertinence est supérieur ou égal au seuil de regroupement */ Alors M(i, j) = F ( EF(k_1);, EF(k_1)i) ; /* mise à jour du gain 30 du regroupement de EF(k_1); et EF(k_1)i */ Finsi } } Faire suivant l'ordre décroissant des valeurs des M(i, j), tant que M(i, 35 j)≠ 0 { Si ((AR(i) = 1) et (AR(j) = 1)) /* EF(k_1)i et EF(k_1)i peuvent être regroupées */ Alors 40 { n++ ; 15 20 EFkn = EF(k_1)iu EF(k_1)j ; /* Regroupement des entités fonctionnelles service EF(k_1); et EF(k_1)j dans l'entité fonctionnelle service EFkn */ AR(i) = 0 ; AR(j) = 0 ; /* EF(k_1) i et EF(k_1)j ne peuvent plus être regroupées avec d'autres entités fonctionnelles service lors de la k itération */ } Finsi } Finfaire Pour i de 1 à Nk_1 { Si (AR(i) = 1) /* Récupération des entités fonctionnelles service non regroupées */ Alors { n++ ; EFkn = EF(k_1)i ; /* Réaffectation des entités fonctionnelles service non regroupées lors de la k itération */ } Finsi } Nk=n; } 2 5 Jusqu'à ((Nk = Nk_1) ou (Nk = 1)) Finfaire FIN REVENDICATIONS 1. Procédé de détermination de quartiers fonctionnels service pour des services de télécommunications, dans lequel, lors du déroulement d'un scénario décrivant l'utilisation d'un service de télécommunications : - on associe à chaque message échangé entre instances d'informations 1 o service un ou plusieurs flux entre composants fonctionnels service représentés par un modèle d'architecture de composants, - on estime la pertinence métier d'au moins un regroupement de composants fonctionnels service, et - on regroupe, de façon itérative, lesdits composants fonctionnels 15 service dans des quartiers fonctionnels service, en appliquant la contrainte selon laquelle les regroupements impliquant les meilleurs indicateurs de pertinence métier doivent être traités en priorité. 2. Procédé selon la revendication 1, caractérisé en ce que l'on extrait de chaque information service une ou plusieurs données service, en ce qu'un 20 message M, émis par l'instance de l'information service /, vers l'instance de l'information service /2, active une dépendance de la donnée service D, vers la donnée service D2 si : - D, est extraite de /,, - D2 est extraite de /2, et 25 - il existe une dépendance entre D, et D2, et en ce que la dépendance est orientée de D, vers D2 si M est un message de type "requête", et orientée de D2 vers D, si M est un message de type "réponse". 3. Procédé selon la revendication 1 ou la revendication 2, caractérisé en 30 ce qu'un message M, émis vers l'instance de l'information service /, active une dépendance de la donnée service D, vers la donnée service D2 si : - D, est extraite de /, - D2, différente de D,, est extraite de 1, et -il existe une dépendance entre D, et D2. 35 4. Procédé selon la revendication 2 et la revendication 3, caractérisé en ce qu'un message échangé lors d'un scénario d'utilisation de service de télécommunications est considéré comme non-réalisable si : - il n'existe pas de dépendance entre données service activée lors de la mise en oeuvre de la revendication 2 ou de la revendication 3, ou - le type du message (à savoir, "requête ou réponse") est incohérent avec l'orientation selon la revendication 2 des dépendances activées entre données service. 5. Procédé selon la revendication 2 ou la revendication 3, caractérisé en ce que l'activation d'une dépendance entre deux données service, suite à l'échange d'un message lors de l'utilisation d'un service de télécommunications, implique l'activation d'un flux entre les composants fonctionnels service référençant chacune des données, et en ce que l'orientation de ce flux est cohérente avec l'orientation du message. 6. Procédé selon la revendication 5, caractérisé en ce qu'un composant fonctionnel service est ciblé par un regroupement avec d'autres composants fonctionnels service s'il est la source ou, de façon exclusive, la destination, d'un flux entre composants fonctionnels service activé suite à l'échange d'un message lors de l'utilisation d'un service de télécommunications. 7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que ledit indicateur i(EF) de pertinence d'un regroupement de composants fonctionnels service dans une même entité fonctionnelle service EF est défini de la façon suivante : N 1(i -1) * NSi(EF) I (EF) = N NSi(EF) i=1 i=2 où : - N est la longueur maximale des séquences de composants fonctionnels service appartenant à EF, et - NS;(EF) est le nombre de séquences de i composants fonctionnels service, 25 appartenant à EF, activées lors du déroulement d'un ou plusieurs scénarios d'usage de services de télécommunications. 8. Procédé selon la revendication 7, caractérisé en ce que l'on ne regroupe des composants fonctionnels service que si ledit indicateur de pertinence est supérieur à un seuil S de regroupement de composants 30 fonctionnels service défini de la façon suivante : N M II (i+ j ù 1) * (NSci(EF1 )*NScj(EF2)) S (EF1, EF2) = `_1 '_l + N M NSi(EF1 ) * NSj(EF2 ) j=i i=1 N M (i ù 1) * (NSi(EFI )ùNSc(EFI))+(j-1)*(NSj(EF2)ùNScj(EF2)) i=2 j=2 N M NSi(EF~) * NSj (EF2 ) j=i i=ioù - N est la longueur maximale des séquences de composants fonctionnels service appartenant à une entité fonctionnelle service EF,, - M est la longueur maximale des séquences de composants fonctionnels service appartenant à une entité fonctionnelle service EF2, - NS;(EF1) est le nombre de séquences de i composants fonctionnels service, appartenant à EF,, activées lors du déroulement d'un ou plusieurs scénarios d'usage de services de télécommunications, -NSi(EF2) est le nombre de séquences de j composants fonctionnels service, 1 o appartenant à EF2, activées lors du déroulement d'un ou plusieurs scénarios d'usage de services de télécommunications, - NSc1(EF1) est le nombre de scénarios différents où des séquences de i composants fonctionnels service, appartenant à EF,, sont activées, et - NSci(EF2) est le nombre de scénarios différents où des séquences de j 15 composants fonctionnels service, appartenant à EF2, sont activées. 9. Procédé selon la revendication 8, caractérisé en ce que l'on sélectionne le meilleur regroupement de composants fonctionnels service en fonction de la valeur respective la plus grande prise par un gain F apporté par le regroupement respectif de deux entités fonctionnelles service EF1 et EF2, 20 ledit gain F étant défini comme suit : I (ET', u EF2 ) F (EF1u EF2) = S(EF, ,EF2) où I désigne l'indicateur de pertinence de l'entité fonctionnelle service résultante du regroupement, et S désigne le seuil de ce regroupement. 10. Moyen de stockage de données comportant des instructions de code 25 de programme informatique pour l'exécution des étapes de l'un quelconque des procédés selon les revendications 1 à 9. 11. Programme d'ordinateur contenant des instructions telles que, lorsque ledit programme commande un dispositif de traitement de données programmable, lesdites instructions font que ledit dispositif de traitement de 30 données met en oeuvre un procédé selon l'une quelconque des revendications 1 à9.