Ports composites de composants logiciels

Transcription

1 UNIVERSITE MONTPELLIER II SCIENCES ET TECHNIQUES DU LANGUEDOC T H E S E pour obtenir le grade de DOCTEUR DE L'UNIVERSITE MONTPELLIER II Discipline : Informatique Ecole Doctorale : I2S présentée et soutenue publiquement par Nicolas Desnos Le 23 juin 2008 Ports composites de composants logiciels Application à la construction dynamique et à non anticipée Jury Rapporteurs : Mireille Blay-Fornarino, Maître de conférences, Laboratoire I3S Université de Nice Sophia Antipolis Laurence Duchien, Professeur, INRIA Futurs et LIFL Université des Sciences et Technologies de Lille Examinateurs : Christophe Dony, Professeur, Laboratoire LIRMM, UMR 5506 CNRS et UM2 Salah Sadou, Maître de conférences HDR, Sud Guy Tremblay, Professeur, Département informatique UQAM, Montréal Directrice : Encadrants : Marianne Huchard, Professeur, Laboratoire LIRMM, UMR 5506 CNRS et UM2 Christelle Urtado, Maître de conférences, Sylvain Vauttier, Maître de conférences, Page 1

2 Page 2

3 Page 3

4 TABLE DES MATIERES 1 Introduction Préambule Contexte Systèmes construits par assemblage de composants Processus de développement à base de composants Objectifs et motivations Objectif principal Objectifs connexes Plan de la thèse Approches à base de composants Objectifs fonctionnels Architecture logicielle Synthèse Correction Complétude Validité Synthèse Construction Evolution Automatisation Critères de qualité Processus de construction Top-down (classique) Processus de construction bottom-up Evolution dynamique «Autonomic computing» Page 4

5 2.3.5 Critères de qualités Synthèse Discussion Proposition Introduction Composant Elément connectable Interface connectable Port Port primitif Port composite Bilan Métamodèle de la partie interne Architecture Composant Connexion entre composants Analyse Système global Système logiciel Objectifs fonctionnels Référentiel de composants Analyse Validité et quasi Les niveaux de vérification classiques adaptés à notre approche Page 5

6 3.5.2 Les nouveaux niveaux de vérification Analyse Discussion ages valides Introduction Description du problème Contexte, hypothèses, objectifs Algorithme naïf Vers un algorithme de construction optimisé Bilan Construire un assemblage quasi-valide : un problème NP-Complet Preuve mblages quasi-valides Modélisation CSP Tous les assemblages quasi-valides : Assemblages de taille minimale : Discussion Evolution dynamique sure et non anticipée Introduction Contexte Exemple Substitution n-à Suppression du composant cible Gestion des composants morts Reconstruc Page 6

7 5.4 Discussion Réalisation et expérimentations Julia Le fichier de configuration Julia.cfg Fract-Port : une extension de Julia Généralités Contrôleurs Ports Noyau Calcul virtuel Génération des fichiers Java Utilisation de Fract-Port Un premier exemple Exemple de Construction automatique Expérimentations Analyse Conclusion et perspectives Contributions Perspectives Bibliographie Page 7

8 Je remercie Yannick Vimont, directeur du LGI2P, ainsi que Mines thèse dans leur établissement. Je désire remercier sincèrement ma directrice de thèse, Marianne Huchard, professeur au pellier II, dont les qualités sont nombreuses tant sur le plan scientifique que humain. Son don précieux de toujours ressortir les points positifs d'une Je remercie chaleureusement mes encadrants de thèse, Christelle Urtado et Sylvain Vauttier, maîtres de conférences Ecole des Mi recherche. J'ai beaucoup appris et pas seulement au niveau scientifique, ce fut un plaisir de travailler avec eux. et Mireille Blay-Fornarino, maître de conférences niversité de Nice Sophia Antipolis, qui ont accepté de rapporter ce travail. Je suis très sensible à la présence dans ce jury de Guy Tremblay, professeur au département informatique Montréal (UQAM) de travailler. Je remercie également Christophe Dony, professeur au LIRMM de niversité Montpellier II et Salah Sadou, maître de conférences au laboratoire VALORIA de rsité de Bretagne Sud Je remercie également personnel Je tiens à mentionner le plaisir que j'ai eu à travailler avec Marianne, Sylvain et Christelle qui se sont beaucoup investis dans mon travai leur expérience. Je les remercie aussi pour leurs encouragements et leur assistance aussi bien matérielle que morale qui m'ont permis de faire cette thèse dans de très bonnes conditions. Je remercie aussi Gabriela pour son soutien moral durant la dernière ligne droite. Merci aussi à mes collègues et amis Reena, Jean, Yulin, Fady, Fabien a autres qui se reconnaîtront ici. Merci enfin à mes parents, à mon frère et à permis de me ressourcer à chaque retour dans le pays Narbonnais. Page 8

9 Page 9

10 1 INTRODUCTION Cette thèse, intitulée «:», traite de la construction et de la reconstruction autonomiques d e composants satisfaisant des objectifs fonctionnels. La base de notre approche est fondée sur un métamodèle de composants dont les interactions potentielles sont documentées par des ports composites. 1.1 PREAMBULE A a permis de mettre en relation les ordinateurs du monde entier. Le matériel a également. Au cours des années 2000, les interfaces de communication son environnement de se diversifier et de se perfectionner. Nous vivons désormais dans un monde ubiquitaire (ordinateur, PDA, Palm, mobile, GPS, possède des interfaces de communication et une informatique embarquée de qualité. La technologie ayant permis de mettre en relation des entités autonomes différen leurs Depuis domaine. Le processus de construction classique (top-down) système logiciel à nouveaux besoins qui ont émergés. Face à cela le processus de construction vers un processus de construction bottom-up. Ces entités peuvent être considérées comme des composants logiciels ou des agents évoluant dans un monde virtuel (représentant une abstraction du monde réel). Chaque entité possède des objectifs fonctionnels et non fonctionnels à satisfaire. La question que nous nous posons ici concerne les premiers : comment organiser les interactions entre une entité et les autres entités disponibles de son environnement afin de satisfaire les objectifs fonctionnels de? intérêt 1.2 CONTEXTE Un grand nombre de systèmes logici -localisation de dispositifs nomades communiquant composants logiciels actuels sont encore relativement limités en matière de gestion de systèmes ouverts et dynamiques. Page 10

11 ion) SYSTEMES CONSTRUITS PAR ASSEMBLAGE DE COMPOSANTS ciels e objets. complexité de systèmes de taille moyenne a désormais trouvé ses limites. Bien que de ces agrammes UML, la compréhension globale de ces systèmes ainsi que leur maintenance devient quasiment impossible une fois que le système a été codé, la cohérence entre le code et respectée dans la majorité des cas. Depuis les années 2000, les approches à composants ont pris une part centrale dans le génie logiciel. CBSE (Component-Based Software Engineering) [58] fait référence dans le domaine de la construction de systèmes logiciels et propose de construire des systèmes logiciels par assemblage de composants réutilisables afin sûreté, la qualité et la maintenance du système tout en ressources matérielles, en temps et en argent. Il est intéressant de noter que l s sur été proposée par McIlroy [71] en Les composants sont rfaces qui définissent ce que le composant est capable de fournir et ce que le composant requiert. Les assemblages de composants sont construits en connectant leurs interfaces [26, 25, 30, 18]. Un système logiciel basé sur une approche à composants peut être décomposé en trois parties [41] : ses objectifs fonctionnels et non fonctionnels, son architecture, et son code., complémentaires, traitent des objectifs non fonctionnels [119, 101]. La Figure 1 illustre cette décomposition du système. Figure 1 Les objectifs fonctionnels correspondent à des besoins fonctionnels exprimés par les utilisateurs du système. 58, 57, 56, 55, 54, 41] définit les fondements structurels et Page 11

12 [42, 43]. Dans [41 fait le lien entre les besoins fonctionnels et le code. On peut noter que le code PROCESSUS DE DEVELOPPEMENT A BASE DE COMPOSANTS Le cycle de vie d'une application réalisée suivant une approche orientée composants est présenté dans ses grandes lignes sur la Figure 2. Analyse du besoin. cte étudie le besoin charges. Il définit alors un Analyse du besoin Conception de l'architecture Validation Déploiement (assemblage conforme à l'architecture) Exécution Evolution Figure 2 : Cycle de vie simple pour un système à base de composants logiciels Conception de. architecte est de décomposer le système, en distribuant les objectifs fonctionnels à des sous-systèmes puis en raffinant le design en décomposant les sous-systèmes en composants responsables de fonctionnalités concrètes, sélectionne des composants réutilisables dans un référentiel de composants et les connecte le composant est indisponible ou ne se trouve pas dans le référentiel, fournisseur de composants. Le fournisseur prend en charge la conception du composant et la documentation de son fonctionnement. L composant réutilisable Design for reuse. Dans le cadre de notre travail notre intérêt se porte sur la phase suivante : Design by reuse. Les travaux [99 aux nôtre. doit consister à correct [56, 58, 60, 61]. la méta-information qui documente Page 12

13 les composants. Le niveau minimal de cohérence requis par un système est celui de la vérification syntaxique. Celle-ci peut être assimilée à une vérification de typage au sens des langages de programmation à typage statique [93, 20]. Par exemple la vérification syntaxique vérification des types lors de Cependant, garantir un niveau syntaxique dans un assemblage n'est pas suffisant pour garantir un comportement cohérent de l'ensemble du système. En conséquence, une vérification sémantique, -information plus riche, doit être effectuée. Cette méta- généralement sur un formalisme es comportements dynamiques du système (protocoles de comportement, assertions) [29, 30, 35, 36, 86]. Déploiement. La phase de déploiement consiste à hitecture du système sur une plate forme cible. A la fin du déploiement, un assemblage de composants conforme à architecture du système peut r. Evolution. Les systèmes logiciels doivent un jour évoluer [72]. Il est donc fondamental de ntenance de systèmes logiciels. «La maintenance logicielle correspond à la plication après sa livraison en vue de corriger ses erreurs, améliorer sa performance ou toute autre propriété logicielle ainsi que de dans un nouvel environnement» [80, 104]. Causes. divers et variés comme par exemple une évolution technologique,, un changement de profil des utilisateurs, etc. Contraintes. pour un coût optimal. La main : e était de 67% [76] du coût total. En 1990, le coût se situait entre 60% et 70% du coût total. En 2000, le coût était supérieur à 90% [78]. Sûreté. e système ne doit pas subir de régression fonctionnelle. Ainsi, le nouveau système doit supporter les fonctionnalités que proposait Stratégies. puis ensuite de manière concrète (modification du code). La réalisation concrète peut être effectuée de manière statique ou dynamique. Les aspects dynamiques sont propres aux systèmes à base de composants. La modification dynamique du système fait entrevoir des problèmes comme par exemple le besoin de composants dont système lors de la maintenance [107]. Qualité. contrôle des évolutions en surveillant leur impact sur la qualité des nouvelles architectures [106]. Page 13

14 Conséquences. [73] et le vieillissement [74] des systèmes, abordés dans la thèse de Dolorès Diaz [104], sont deux problèmes qui apparaissent à long termes. En effet, la spécification ou oins soutenus [75]. La Figure 3 résume les tâches propres à chaque acteur du cycle de vie. Le fournisseur est chargé de la conception et de la documentation (méta-information) du composant. La documentation exprime la manière dont fonctionne le composant et peut être spécifiée de manière formelle (section ). Fournisseur Architecte Référentiel de composants conception des composants documentation de leur fonctionnement analyse du besoin spécification de l'architecture stockage des composants Outil de validation validation de l'architecture Figure 3 : Les acteurs du cycle de vie Dans le cadre de ce ont été abordées. 1.3 OBJECTIFS ET MOTIVATIONS Nous présentons dans cette section nos objectifs ainsi que nos motivations qui portent sur assemblages de composants. Spécification des objectifs fonctionnels Construction dynamique de tous les assemblages valides de composants Evolution sûre et non anticipée Figure 4 : No Alors que la plupart des approches existantes fournissent des langages pour décrire (ADL Architecture Description Language e architecture, peu y Page 14

15 étant un niveau de vérification combinant la correction et la satisfaction des objectifs fonctionnels. La Figure 4 représente le processus de construction que nous souhaitons atteindre OBJECTIF PRINCIPAL assemblages 1 valides de composants à partir La Figure 5 illustre ce propos. Figure 5 : Objectif principal de notre approche de notre approche est que la construction assemblages de composants est guidée par les objectifs fonctionnels et non pas par des règles contraignantes prédéfinies. Les : - dont le comportement global est cohérent et où les objectifs fonctionnels sont satisfaits. - Trouver des assemblages avec un minimum de connexions OBJECTIFS CONNEXES Dans ce cadre, nous présentons ci-après un ensemble de sous-objectifs : notre intérêt se porte tout Assista. B 41, 45, 37, 36, 35, 13, 12, 53, 81] qui permettent de décrire les aspects structurels travaux [29, 22, 21, 30, 19, 17, 36, 35] e. Peu de travaux 1 Notre approche permet aussi bien de construire des architectures que des assemblages de composants. Lors de la Page 15

16 amené à faire pour construire son architecture. Automatiser la c ssemblages valides. La construction automatique ssemblages valides est un objectif ambitieux qui trouve son intérêt dans une multitude de contextes et de domaines, à commencer par CBSE, mais également en intelligence ubiquitaire et dans le cadre des web services [102, 118]. ipée. ution de composant, pour faire face au possible. Réparer un assemblage valide de composants après avoir enlevé un composant tout en composant est composants, la plupart des travaux choisissent la stratégie de substitution un-à-un. Les approches un tel composant sont réduites par le fait que les contraintes concernant sa structure, notamment le type des interfaces exposées, sont for plus flexible de permettre à un composant de pouvoir être remplacé par un assemblage de composants. 1.4 PLAN DE LA THESE La principale contribution de cette thèse est de proposer un processus de construction automatique métamodèle de composants dont les interactions potentielles sont documentées par des ports composites. Cette information permet de définir u potentiellement valides grâce à une recherche parmi tous les assemblages possibles. La complexité de cette recherche est maîtrisée grâce à des optimisations heuristiques. Ce mécanisme est aussi utilisé pour la re- proposition est plus flexible que celles de travaux comparables car elle permet de réaliser des substitutions n à 1 afin de pallier la difficulté de posséder un composant proposant exactement les fonctionnalités attendues. Une implémentation prototype, comme extension du modèle de composants Fractal, permet de réaliser diverses expérimentations sur des simulations de bases de composants et de icacité des algorithmes proposés. Le manuscrit est structuré comme suit. Chapitre 3. Ce chapitre propose notre métamodèle de composants à base de ports. Ceux-ci constituent le fondement de notre approche. Il va être utilisé pour répondre aux problématiques telles que assemblages valides (chapitre 4 5). De manière plus précise, les concepts que nous allons décrire dans le métamodèle vont permettre : fonctionnels de ce dernier tout en raisonnant de manière locale au composant. Page 16

17 De définir un niveau de vérification intermédiaire (la quasi-validité) moins coûteux en temps de calcul qui peut être utilisé lors du processus de construction. De permettre un processus de construction bottom-up efficace. Ce chapitre propose aussi les niveaux de vérification : validité, correction, complétude. Nous commençons par définir la validité. Une propriété de validité est ensuite définie afin de prouver la validité à partir de la correction et de la complétude. Une propriété de quasi-validité basée sur les ports Chapitre 4. cause de problèmes de combinatoire, notre stratégie consiste à construire des assemblages valides en utilisant la propriété de validité comme suit : 1. s. La propriété de quasi-validité est utilisée pour construire des assemblages complets. 2. Vérification de la correction sur ces assemblages pré-calculés Chapitre 5. Ce chapitre présente une application à notre algorithme de construction. Ce dernier est utilisé pour reconstruire des parties amique sûre et non anticipée. Chapitre 6. Une implémentation du métamodèle et des algorithmes de construction et de reconstruction sont proposés. Page 17

18 2 ction de cette thèse. Ce chapitre présente un sur les approches à composants existantes limites par rapport à nos objectifs. Cette analyse nous permettra ensuite de proposer une solution adaptée à chacun de nos objectifs. ainsi plusieurs facettes : les concepts clés utilisés par les approches existantes, les différents processus de vérification des assemblages de composants, les processus de construction ainsi que les pr ganisation de ce chapitre est la suivante : la section 2.1 propose une analyse conceptuelle des approches à composants. La section 2.2 esse aux processus de vérification. La section 2.3 présente les processus de construction top-down et bottom-up, ynamique des. La section 2.4 constitue une discussion finale de ce chapitre. Cette discussion reprend nos objectifs, identifie les limites des approches existantes et énonce une partie des solutions apportées à chacun de nos objectifs. 2.1 APPROCHES A BASE DE COMPOSANTS Il a été présenté composants pouvait être décomposé en trois parties : les objectifs fonctionnels et non fonctionnels e et le code. Dans le cadre de nos travaux, notre intérêt se porte sur les deux premières parties. Ainsi, la section est consacrée aux objectifs fonctionnels et la section a section est dédiée aux langages ment la section propose une synthèse de section. Remarque : fs fonctionnels mais pas des objectifs non fonctionnels. art, nous ne parlerons donc plus nous appuyons sur la Figure 1 et nous assombrissons la zone correspondante à la partie du système traitée OBJECTIFS FONCTIONNELS De manière générale, les objectifs fonctionnels sont des services et des contraintes que le système Ils sont définis lors des phases amont du développement lors Un système possède nécessairement des objectifs fonctionnels [55, 56, 57, 58, 60, 61], qui constituent les raisons pour lesquelles il est conçu. Les objectifs fonctionnels constituent le point de départ pour construire une architecture. Ils peuvent être décrits de manière plus ou moins formelle suivant les approches. Le degré de formalisme impacte directement sur la qualité de Page 18

19 Un 26, 90] décrit une fonctionnalité fournie par le système à une catégorie souvent décrit de manière informelle (essentiellement Mencl [89] et Lung [57] proposent Dans [54, 55] les objectifs fonctionnels sont décrits de manière informelle. Les auteurs de [58] utilisent une spécification formelle pour exprimer les objectifs fonctionnels sous la forme de processus métiers ARCHITECTURE LOGICIELLE architecture permet de décrire les éléments de haut niveau qui constituent la structure et le comportement en vue de réduire sa complexité [42, 43, 12]. Dans la littérature, la définition la plus citée est donnée par Kazman, Bass et Clements dans [7] : The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components and the relationships among them celle du éléments qui composent la maison : décrites : structurelle, services. Dans la littérature [42] certains types utilisées de manière récurrente dans les approches à composants) ont été classés et généralisés pour définir des itectural pour définir une architecture est que chaque style a ses conventions : ils permettent de faciliter la validation des architectures conformément à des modèles dont les qualités non fonctionnelles sont connues par avance. Figure 6 : L Page 19

20 Un -serveur. C2 [81], Rapide [35] et UNICON [37] ne permettent pas de définir des styles architecturaux, à la différence de Darwin [13] et Wright [36]. La description que nous proposons dans cette section peut être assimilée à la définition suivant quatre vues : la vue structurelle, la vue syntaxique, la vue sémantique. La Figure 6 illustre la partie du système décrite dans cette section Vue structurelle décrit les interactions structurelles qui existent entre les différentes entités du système. La Figure 7 illustre la partie du système décrite dans cette section. Figure 7 Les éléments structurels peuvent être partitionnés en plusieurs classes : les composants, les des concepts de deuxième niveau utilisés pour représenter s tels que la composition hiérarchique et le partage. éléments structurels. Nous commençons cette description par les trois entités de premier niveau : composant, connexion et connecteurs. Le composant. I sur la définition du concept de composant, cependant la définition la plus souvent citée est celle proposée par Szyperski [8] : Page 20

21 A software component is a unit of composition with contractually specified interface and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parts composant» est souvent ambigu. En effet, ce terme est utilisé pour désigner à la fois le modèle Dans la suite de ce manuscrit, nous préciserons classe de composant ou instance de composant lorsque cette distinction est significative. Un composant peut être vu : la vue boîte noire (black box) et la vue boîte blanche (white box) sont les deux vues principales. On parle également des vues boîte grise (grey box) et boîte transparente (glass box) qui constituent deux vues supplémentaires du composant. Figure 8 : Les vues boîte noire et boîte blanche les services fournis et requis par le composant et masque les détails de son implémentation. La partie gauche de la Figure 8 llaborations du composant avec son environnement. Suivant port. e de validation (chapitre 3.5 la notion de type syntaxique (section ) et de type sémantique (section termes, c possède un type syntaxique et un type sémantique. - Opération. Dans les approches orientées objets, une opération est un service déclaré par un type 26]. Une opération possède un nom, une signature et un type de retour. Dans les approches à composants, certains modèles utilisent directement comme environnement [13, 35, 37]. Par exemple UNICON [37] propose la notion de player comme point player correspond à une opération qui peut être déclarée fournie (Definer) ou requise (Caller). Dans Darwin [13 travers de services (fournis et requis) qui sont représentés au ommunication (appelés port). Un objet de communication correspond à une opération fournie ou requise. le cas pour Rapide [35]. Page 21

22 - Interface. unidirectionnelles [26, 18, 8 type de les approches à composants. Communément, une interface peut jouer deux rôles : celui de fourni ou celui de requis. Une interface fournie définit un service implémenté par le composant. Une interface requise définit un service qui doit être invoqué par le composant sur un autre composant. Les éléments classiques erface sont les suivants : Nom. (section ). Elle est généralement exprimée par un Rôle. Une interface peut avoir le rôle de client (requise) ou de serveur (fournie). Cardinalité. Elle indique le nombre de connexions qui peuvent être réalisées sur Contingence. Certains étant facultative ou obligatoire. Un composant ne peut être correctement utilisé que lorsque toutes ses interfaces obligatoires ont été connectées ). - Le port. Un port est un p interaction qui modélise une collaboration pair-à-pair (interaction bidirectionnelle) avec un autre composant. La définition du port diffère suivant les approches. 36, 39, 14, 22] utilisent la définition suivante : Un port est être fournies ou requises). Dans CCM [12] un port est composé par un ensemble 36 et fournies. Celles-ci sont déclarées de manière implicite lors de la déclaration du port. approches [26, 30, 17] la définition est la suivante : Un port est un concept modélise une collaboration pair-à-pair avec un autre composant. Certains modèles [26, 30 orts (une interface peut être membre de plusieurs ports) 17]. Certains [17 interfaces les interfaces peuvent seulement être utilisées au travers des ports dont elles font partie 26, 30]. La vue boîte blanche (partie droite de la Figure 8) composant. Un composant peut être primitif ou composite. Un composant primitif est un composant peut être réalisée par une ou plusieurs classes. Il peut être vu comme une feuille arbre de composition hiérarchique de composants (le composant composite est récursivement. L composite est constituée architecture de composants 26, 30, 50, 36, 13, 35, 39, 53, 18, 37, 14, 22, 17] autorisent la composition hiérarchique. Page 22

23 Connexions. Chaque type ) dispose connexion. de deux a connexion dépend du type (type syntaxique et sémantique) de chacun des points. La correction syntaxique est décrite dans la section et la correction sémantique est décrite dans la section Connexions entre opérations. La connexion sur un même niveau de composition hiérarchique est effectuée comme suit : une opération requise par un composant peut être connectée à une opération fournie compatible autre composant. Dans UNICON [37], un player de type Caller pourra être connecté à un player de type Definer (modulo la compatibilité des deux opérations). Dans Darwin [13], une connexion est effectuée entre un service fourni et un service requis. Ce type de connexion est appelé attachement dans Wright [36], binding dans Darwin [13], connection dans Rapide [35], UNICON [37] et CCM [12]. La connexion entre deux niveaux de composition hiérarchique successifs définit la dél vers une appartenant à de connexion est appelé binding dans Wright [36] et UNICON [37], Hierarchical binding dans Darwin [13]. - Connexions entre interfaces. La connexion entre deux interfaces de rôles différents (i.e. fournie et requise) sur un même niveau de composition hiérarchique définit une interaction classique Ce type de connexion est appelé binding dans Fractal [18] et SOFA [50], assembly connector dans UML 2.0 [26] et interaction dans ACCORD [30]. La connexion entre deux niveaux de composition hiérarchique successifs définit une délégation entre deux interfaces de même rôle. Une interface fournie de la boîte noire peut être déléguée vers e type de délégation est appelé Delegate dans SOFA [50], Delegation connector dans UML 2.0 [50] et Délégation dans ACCORD [30 «ressortir» via une interface requise de la boîte noire. Ce type de délégation est appelé Subsume dans SOFA [50], Delegation connector dans UML 2.0 [50], Délégation dans ACCORD [30] et binding dans Fractal [18]. - Connexions entre ports. La connexion entre deux ports sur un même niveau de composition hiérarchique est effectuée comme suit : chaque opération (resp. interface) re port est connectée à une opération (resp. interface) fournie 30], UML 2.0 [26], Java/A [22] et ArchJava [14] utilisent cette règle. SafArchie [39] impose en plus que chaque opération fournie soit connectée à La délégation entre deux ports correspond à une connexion entre deux ports sur deux niveaux de composition hiérarchique successifs. Connecteurs. Les composants interagissent entre eux via des connecteurs. Suivant les approches, les connecteurs peuvent être représentés de manière explicite [30, 50, 36, 39, 37, 22] ou bien de manière implicite [13, 35, 12, 18, 26 ]. Page 23

24 - Connecteur explicite. Un connecteur (explicite) est une entité de première classe qui permet de gérer la partie non fonctionnelle de composants. Il est générique et réutilisable. Un connecteur explicite peut être considéré comme un type de composant jouant un rôle spécifique de médiateur et de contrôleur des interactions entre un ensemble de composants. Wright [36] utilise le terme role composant) et le terme glue UNICON [37] utilise des connecteurs explicites dont les types sont pré-définis. Par exemple : Pipe ou encore RemoteProcCall qui permet de relier des composants de type process. SOFA 2.0 [50] propose les deux mécanismes : connecteurs implicites et connecteurs explicites. On peut signaler que dans la version SOFA/DCUP [28 autorisés. Certaines approches représentent aussi les connecteurs avec des composants [30]. - Connecteur implicite. Dans certaines approches qui utilisent des connecteurs implicites, les composants composites contrôlent et gèrent les interactions de leurs composants internes. Darwin [13], Rapide [35] et de Fractal [18]. Résumé. La Figure 9 résume les éléments structurels qui interviennent dans une interaction entre deux composants. Figure 9 : Sommaire des notions concernant l composants Vue syntaxique Les approches à composants, tout comme les approches objets, utilisent la notion de typage. La vue syntaxique assurer un premier niveau de Elle dans les langages de programmation classiques [93, 20]. Un type syntaxique peut être associé aux points d. La Figure 10 illustre la partie du système décrite dans cette section.. Nous avons présenté, dans la section , les trois sortes de points pour interagir avec son environnement. A titre de. Un type syntaxique. Page 24

25 opération est défini par sa signature et par sa direction. Dans la plupart des approches à composants, le es opérations et par sa direction [26, 18, 8]. des types syntaxiques de ses interfaces (Resp. de ses opérations suivant la définition du port). Figure 10 : La vue syntaxique Ty ble des types syntaxiques. La règle de substitution proposée par Fractal [18] résume la règle classiquement utilisée. Celle-ci est présentée sur la Figure 11. Figure 11 : Les règles de sous- Page 25

26 Vue sémantique La vue sémantique a pour objectif de décrire les aspects dynamiques du système. Elle exprime généralement sous la forme de contrats ou de protocoles de comportement. A chaque élément structurel peut être associé un type sémantique. aspects fonctionnels du. La Figure 12 illustre la partie du système décrite dans cette section. Protocole de comportement. Un protocole de comportement est un ensemble de méta-informations message La plupart des approches utilisent des protocoles qui sont des spécifications de séquences valides. SOFA [29] exprime les protocoles avec des expressions régulières et permet (vers un composant connecté), permetten opérations internes. Carrez [19] exprime les protocoles grâce à des expressions régulières et y intègre la modalité (may et must utilisent des machines à états pour spécifier les protocoles. OMEGA [17] utilise des statecharts. Figure 12 : La vue sémantique UML 2.0 [26] et Java/A [22 décrire les protocoles de façon simple. Cependant, les PSM ne peuvent prendre en compte que des messages orientés dans une même direction. Pour dépasser cette contrainte, Mencl [24] propose les PoSM, une adaptation des PSM qui permet de décrire des protocoles de ports qui sont aussi précis que ceux de Page 26

27 SOFA. La vérification de protocoles repose sur diffic 5]. Contrats. sation des contrats a pour but la description de contraintes statiques et dynamiques qui doivent être respectées lors des échanges de services entre composants. Ils sont souvent représentés par des invariants ou des pré/post conditions. Les premiers contrats ont été proposés par Bertrand Meyer dans le langage Eiffel [86]. Dans ce langage, ils peuvent être assimilés à de la méta-information visant à faciliter la compréhension des programmes ainsi qu Meyer [86] précise module alors que le code exprime comment il doit le faire. Le projet ACCORD [30] propose des contrats utilisant des machines à états. Dans ce modèle, le contrat syntaxique correspond à la description des contraintes liées au typage. Le contrat sémantique correspond aux pré/post conditions. Enfin, certains modèles [31, 30] utilisent des pré/post conditions pour contrôler le séquencement des opérations. Remarque : Pour les aspects non fonctionnels, les propriétés définissant les services échangés sont des contrats qui spécifient comment les composants coopèrent réellement au travers des assemblages [15]. Typage sémantique Un type sémantique peut être associé à un point Des assertions, sous la forme de pré/post conditions, peuvent être associées à une opération. Une interface possède un protocole de comportement qui décrit toutes les séquences valides Un contrat ou un protocole de comportement peuvent être rattachés à un port. sant. Un contrat ou un protocole de comportement peuvent être rattachés à un composant volution dynamique sera abordée dans le détail dans la section Néanmoins, dans un souci de complétude sur une brève description en est proposée ici. Les approches Page 27

28 Figure 13 : La v restera valide La Figure 13 illustre la partie du système décrite dans cette section LANGAGES DE DESCRIPTI Un ADL (Architecture Description Language) système. Il permet de travailler sur des concepts de haut niveau indépendamment des détails 81]. Les langages de d ont fait leur apparition dans les années 90 pour répondre à la complexité des logiciels qui ne cessait de croître [44]. On compte un dans la littérature. Une synthèse et une classification ont été proposées, une L, par Medvidovic et Taylor [45]. définition consensuelle Chaque ADL est adapté à des objectifs spécifiques. Par exemple C2 [81 s utilisant des interfaces graphiques. UNICON [37] utilise des types de composants et de connecteurs prédéfinis qui permettent de vérifier certaines propriétés ainsi que de générer une partie du code de general mais en contrepartie, les vérifications de validité sur Darwin [13] est un ADL dédié à la description de la répartition Wright [36], Rapide [35] ) Page 28

29 sont des ADL qui permettent de spécifier de manière formelle le comportement système puis de vérifier sa validité Description (classe) Description de la structure. Les ADL permettent une description statique des classes de composants description statique des connexions entre les classes de composants [45]. Exemple. Figure 14 est extrait des travaux de Fractal [18]. On rappelle que dans Fractal Dans cet exemple, un composant HelloWorld un composant Client un composant Serveur. Figure 14 : Exemple avec Fractal-ADL (1/2) La description des classes de composants HelloWorld, Client et Server, ainsi que la description de leurs interactions est illustrée Figure 15 en Fractal-ADL [18]. Le composant «HelloWorld» est spécifié comme composite (dan avant dernière ligne de la figure). Son type est défini par son interface fournie «r». Le composant est composé des composants primitifs «Client» et «Serveur». Figure 15 : Exemple avec FractalADL (2/2) La connexion est effectuée via la balise <binding>. Il est important de souligner que Fractal respecte la Par exemple, le composant Client est un composant primitif dont le type est représenté par ses deux interfaces «r» (fournie) et «s» (requise), et dont le contenu est implémenté par le fichier ClientImpl. Page 29

30 Exemple. La Figure 16 illustre un exemple avec ArchJava [14]. On rappelle que dans ArchJava, un point Figure 16 : Exemple avec ArchJava Cet exemple décrit un composant Compiler comme composé des composants scanner, parser et codgegen. Dans cet exemple, le composant parser possède deux ports, in et out. Le port in est composé par deux opérations, void setinfo() (fournie) et Token nexttoken() (requise) void setinfo() est décrite dans le même fichier. ArchJava est un modèle à composants proche du langage de programmation Java dans lequel il Description du comportement au niveau des classes de composants. Un protocole de comportement peut être observable du composant. Un protocole de comportement peut aussi être associé à la boîte blanche 2. Celui- assemblage de composants. Le protocole de comportement de la boîte blanche du composant, appelé est calculé en composant les protocoles de boîtes noires des composants constituant. Le protocole de la boîte noire et le protocole de la boîte blanche peuvent être comparés Exemple. La Figure 17 illustre un exemple avec SOFA [29]. On rappelle que dans SOFA un point Beast interagit avec un composant Worker qui est lui-même composé de deux composants, LoggingWorker et Logger. 2 Dans SOFA [29] ce protocole est appelé architecture protocol. SOFA [29] permet la génération automatique du protocole Page 30

31 Figure 17 : Exemple avec SOFA Interface Protocol Frame Protocol composants (Architecture Protocol -dessous illustre la LogInterface à laquelle est rattaché un protocole, log*. interface LogInterface { void log(in string number); }; protocol: log* -dessous illustre la définition du composant LoggingWorker auquel est rattaché un protocole de comportement. frame LoggingWorker { provides: WorkInterface Work; requires: LogInterface Log; protocol:!log.log;?work.start{!log.log } ;?Work.doit{!Log.log }* ;?Work.finish{!Log.log };!Log.log }; rchitecture est généré de manière automatique Un crit la configuration du système, au niveau des instances de composants, au moment de sa première initialisation. Wright [36] et Rapide [35] permettent de décrire la dynamique. Page 31

32 Exemple. La Figure 18 On rappelle que dans Wright un point représenté par un port composé Le port est défini directement par une formule logique. On peut alors remarquer que les opérations et leurs directions respectives sont ainsi déclarées de manière implicite. Figure 18 : Exemple avec Wright Une configuration Clients-Server est proposée comme exemple sur la Figure 18. La clause Component, de déclarer chaque port (clause Port) ainsi que le comportement global du composant (clause Computation). A la différence de Rapide, Wright utilise des connecteurs. La clause Connector permet de définir un type de connecteur. La clause Instances permet de déclarer des instances de composants et de connecteurs. Dans cet exemple, une instance s, du composant Server a été déclarée. Deux instances c1 et c2 du composant Client ont été déclarées. Enfin deux instances c1_to_s et c2_to_s du connecteur Con_C_S ont été déclarées. La clause Attachement ent Darwin [13] a été défini pour faciliter la description du processus de construction sur des sites répartis. -calcul [46] et son support 47]. De manière plus précise, Darwin permet de décrire la collaboration forall et de when permettant, entre autres, de instances (ce que ). Page 32

33 Figure 19 Exemple dans Darwin (1/3) Exemple. Les trois figures ci-après (cf. Figure 19, Figure 20 et Figure 21) constituent un exemple avec La Figure 19 montre les composants qui interviennent dans cet exemple. Le système fait intervenir quatre classes de composants : printer, odds, filter et sieve. Figure 20 Exemple dans Darwin (2/3) Odds, 1 de Sieve et n-2 de Filter. Figure 21 Exemple dans Darwin (3/3) Le système est vu au travers du composant composite Sieve. La Figure 21 illustre le déploiement du système. Page 33

34 Remarque : La plupart des approches à composants offrent un modèle de composition hiérarchique. Dans ce cas, un encapsulée par le composant composite de plus haut niveau [18, 39, 40, 37, 13]. Plus rarement, le système est décrit directement [36] SYNTHESE Cette section présente une synthèse concernant la section 2.1. Un système logiciel à base de composants est construit dans le but de satisfaire des objectifs fonctionnels et non fonctionnels. On rappellera que dans le cadre de ce travail, seuls les objectifs fonctionnels sont considérés. Le système peut être décomposé en trois parties : Ses objectifs fonctionnels Son architecture Son code Cette décomposition a pour but de maîtriser la complexité du système : sa description, sa validation et sa maintenance sont ainsi facilitées. constitue sa partie centrale. Elle décrit sa structure et son comportement. Elle se décompose suivant quatre vues : une vue structurelle, une vue syntaxique, une vue sémantique. La vue structurelle correspond au squelette du système. Elle définit les entités de première classe que sont : les composants les connexions les connecteurs t ainsi que ceux dont il a besoin pour fonctionner via des : les opérations les interfaces les ports Chaque point un type syntaxique et un type sémantique. Toute la méta- checker de valider Tableau 1 propose une synthèse de ces éléments. Page 34

35 Nom du modèle Spécification (Objectifs fonctionnels) Type syntaxique Type syntaxique des points Type sé composant Type sémantique des points UML 2.0 Ports bidirectionnels Port : ensemble Machine à états Port : Machine à états de protocole ACCORD -- Interfaces et ports bidirectionnels Interface : ensemble Port Contrat Port : contrat Interface : contrat Opération : contrat SOFA On peut interfaces du composant composite de plus haut niveau (i.e. celui qui représente le système) Frame : ensemble des interfaces Interface : ensemble Frame protocol Interface protocol Wright -- Ports bidirectionnels Port : ensemble fournies ou requises Computation. Protocole en CSP décrivant le comportement du composant Formule logique qui décrit une collaboration possible avec (CSP) Darwin -- Opérations fournies et requises Opération Description du comportement en utilisant le Pi-calcul Non Rapide -- Opérations fournies et requises Opération Description formelle du comportement Non Fractal -- Interfaces Interface : ensemble Non Non ArchJava -- Ports bidirectionnels Port bidirectionnelles Non Non Tableau VERIFICATION Cette section est dédiée à la vérification système à composants. La plupart des travaux proposent une architecture. : la satisfaction des objectifs fonctionnels. Mencl [89 de vérifier que le raisonnement exprimé sous le comportement du système est correct. Muccini [88] exprime aussi le besoin de vérifier que le système satisfait bien certaines propriétés de la spécification. Page 35

36 Nous allons introduire, dans le chapitre 3.5, le concept de validité. De manière intuitive, un assemblage correcte aux objectifs fonctionnels du système CORRECTION La section 2.1 a présenté, spécifiée par la description des composants, des connecteurs et des liens qui les unissent. Ceci constitue le squelette du système. Il est -information syntaxique et sémantique permettant Figure 22 s co sémantique dans son architecture. La Figure 22 illustre le fait que la correction est vérifiée à partir des éléments structurels, syntaxiques et comportementaux. ACCORD [30] propose une vérification au niveau des contrats, SOFA [29] et Wright [36] permettent une vérification des protocoles et permettent aussi de détecter des cycles et des interblocages. Darwin [13] -calcul, permet de détecter des interblocages Correction syntaxique La correction syntaxique constitue le niveau de vérification minimal. Elle repose essentiellement sur un contrôle de la compatibilité des types syntaxiques des points (section ). Page 36

37 Vérification syntaxique des connexions. Les types syntaxiques des deux opérations sont comparés. - [53, 18, 50, 26, 25, 27]. Par exemple, dans Koala [53] composant doit être connectée à précisément connectée à zéro ou plusieurs interfaces requises. Les types syntaxiques des deux ports sont comparés. Analyse. L puisse être utilisé correctement. En effet, la correction syntaxique vérifie uniquement que les peuvent collaborer -à- leurs informations en séquences ordonnées formant un dialogue cohérent et leur permettant de produire un processus métier souhaité Correction sémantique La correction sémantique constitue un niveau de vérification élevé du fonctionnement de composants. Elle repose sur un contrôle de la compatibilité des protocoles et des contrats des points En décrivant les appels de fonctions que chacun des composants peut/doit envoyer ainsi que les appels de fonctions ge de recevoir, les protocoles permettent de réaliser différentes vérifications sur la appels de fonction potentiellement envoyée par un composant client sur une interface requise peut être exécutée par le composant serveur -blocages (cyc être vérifiées [19]. Ces vérifications font appel à des procédures de génération de traces qui sont trop complexes (combinatoire importante) pour être gérées à la main et doivent donc être outillées. Vérification sémantique des connexions. Par convention nous choisissons de décrire le sens de variation des pré/post conditions du requis vers le fourni. Ainsi, les pré-conditions attachées à une fournie doivent varier de manière covariante. Les post-conditions attachées à une opération de manière contravariante. Plusieurs cas doivent être envisagés classique entre une interface requise et. délégation entre deux interfaces lus haut niveau bas niveau de composition hiérarchique. Le troisième cas traite de la délégation entre deux interfaces requises (i.e. dans SOFA le terme employé est subsume Page 37

38 requise de plus haut niveau de composition hiérarchique. Les protocoles attachés aux ports sont comparés. Vérification de conformité entre la boîte noire et les interfaces. Cette vérification vise à contrôler que la spécification du comportement global du composant associé à la boîte noire (protocole de Frame dans Sofa) est conforme à cha conformités proposées dans [29] sont les suivantes : pour une interface fournie, son protocole doit être contenu dans le protocole de frame restreint à cette interface. Pour une interface requise, le protocole de frame Conformité entre le protocole de la boîte blanche et le protocole de la boîte noire. La vérification de la conformité entre le protocole de la boîte blanche et celui attaché à la boîte noire est proposée dans [29]. Le but de cette véri comportement global du composant est conforme au comportement résultant de son architecture interne (son implémentation). SOFA propose un mécanisme de génération automatique du. Les règles de conformité peuvent être divisées en deux parties. La première partie concerne les services fournis. Le protocole de frame restreint aux services fournis. restreint aux services requis (subsume par les services requis du frame) doit être contenu dans le protocole de frame restreint aux services requis. Analyse. [23, 5, 6]. Des optimisations cherchent à minimise 87] propose une optimisation qui consiste, dans une première phase, à détecter les parties non ut réduire les protocoles de comportement de chaque composant à une forme minimale. Dans une deuxième phase la vérification des protocoles est effectuée COMPLETUDE fonctionnels du système. e doivent être suffisantes pour laborations qui incluent les objectifs fonctionnels. En effet, peut nécessiter e lités (ou interfaces) sont dites dépendantes. Cette information est généralement [29] fournie par la description du comportement du composant. La Figure 23 illustre le fait que la complétude est vérifiée à partir des La complétude est étudiée dans le chapitre 3.5 (section ). Page 38

39 Figure 23 : Complétude définit une spécification structurelle et comportementale du système qui doit satisfaire chacun des objectifs fonctionnels (complétude). La sémantique du terme complétude (completeness) que nous considérons diffère de celle proposée par R. Allen [36]. Pour Allen, question suivante : la spécification du comportement a-t-elle été décrite de manière complète? Alors que pour nous elle se résume à la question suivante : les objectifs fonctionnels sont-ils satisfaits? Voici ci-dessous une étude des travaux existants au sujet de la complétude. Connecter toutes les interfaces. Pour une première classe de systèmes [9], la complétude est garantie en que toutes les interfaces de tous les composants sont connectées. La vérification de cette règle est triviale mais sur-contraint grandement mblage, diminuant ainsi possibilités de construire une architecture complète avec un nombre prédéfini de composants. Les interfaces obligatoires/facultatives. Afin de surmonter les imperfections de cette première classe de systèmes, une deuxième classe de systèmes [33, 53] définit : obligatoires ou facultatives. Ces systèmes permettent de construire des architectures complètes en ne connectant pas toutes les interfaces. Des interfaces optionnelles peuvent ainsi être pendantes (i.e. non connectées). Cette approche ne complique pas le contrôle de la complétude et, étant donné un ensemble prédéfini de composants, permet Page 39

40 une architecture complète. Sans définition explicite des contextes dans lesquels les interfaces sont de connexions répondant à un objectif fonctionnel donné. Dépendances entre interfaces. Une troisième stratégie consiste à vérifier que les interfaces qui sont dépendantes pour atteindre un objectif fonctionnel sont connectées [5, 4, 34, 10, 11, 32]. [11, 4, 5] sont capable de déterminer si une interface doit être connectée ou pas en analysant les protocoles de comportement pour [4 et 29] et 5]. [32] utilise des techniques de model-checking. [10] propose alyse de dépendances aux architectures logicielles VALIDITE 2.1. Figure 24 : Propriété de validité De manière informelle la validité est introduite, dans le chapitre 3.5 (section ), comme étant un niveau de vérification qui consiste à vérifier que les chemins d Une propriété de validité est ensuite proposée pour assemblage. La Figure 24 illustre le fait que la validité fait intervenir la correction et la complétude. Page 40

41 2.2.4 SYNTHESE Cette section avait pour but de décrire les mécanismes liés à la vérifi défini par assemblage de composants. Dans les approches existantes, la correction syntaxique et la correction comportementale sont définies clairement. Par contre, la vérification de la satisfaction des objectifs réellement définie. Bien que le concept de validité et de complétude fassent partie discuter ici afin de clarifier notre propos dans Un assemblage de composants est val spécification structurelle et comportementale (présentée dans la section 2.1). Les constats suivants peuvent être dressés : (1) La plupart des travaux se focalisent sur le calcul de la correction et peu la complétude ; (2) Le contrôle de la correction ou pire un problème indécidable. Nous verrons par la suite que ce problème limite fortement les approches qui se basent sur un processus de construction incrémental (processus bottom-up) ; (3) («optimale») des composants dans un système. Le Tableau 2 constitue une synthèse Nom du modèle Correction Complétude UML précis pour satisfaire ACCORD Vérification par contrats -- SOFA Frame Architecture connectées. Wright Vérification des protocoles et détection -- Darwin Typage -- Rapide Vérification des protocoles de comportement + contraintes liées aux événements et détection -- Fractal Type-matching : être un super- Méc optionnelle. Toute interface requise obligatoire doit être connectée autre composant ArchJava Typage -- Tableau 2 : Synthèse sur la validité Page 41

42 2.3 CONSTRUCTION EVOLUTION AUTOMATISATION CRITERES DE QUALITE La section 2.1 a présenté les concepts clés utilisés dans les approches existantes pour définir des systèmes à base de composants. La section 2.2 a été consacrée au processus de contrôle de la validité s. Cette section est consacrée composants. es de : le processus top-down (section 2.3.1) et le processus bottom-up (section 2.3.2). Dans les deux cas, et surtout dans un processus de construction bottom-up, La On estime que 40% à 60% du code est réutilisable gramme à un autre. Le dépend de la manière dont sont exposées ses différentes utilisations possibles (services, interfaces, rôles, ports intégrer facilement, seules ses interfaces utiles au bon fonctionnement global du système doivent être connectées [34, 4, 10]. Ainsi, des travaux se rfaces. Il est possible de distinguer deux sortes de dépendances : Les dépendances intra-composantes. Cette catégorie de dépendances correspond à des Les dépendances inter-composant. Cette catégorie de dépendances correspond à des dépendances entre des interfaces de plusieurs composants PROCESSUS DE CONSTRUCTION TOP-DOWN (CLASSIQUE) Le processus de construction top-down est le processus de construction classique des approches à composants. Il est basé principalement sur cinq phases, de validation, de déploiement, les architectes cherchent à comprendre le problème. Les besoins des utilisateurs sont collectés, exprimés puis formalisés sous. sélectionnés. Un langage de architecture (ADL) est utilisé pour décrire la manière dont ils sont mis prend en considération les aspects structurels et sémantiques. Dans les projets actuels, il est courant usieurs langages de programmation. Aussi un composants. La phase de vérification défini st La -automatisée en utilisant des descripteurs de déploiement. Après la phase de déploiement, conception. Page 42

43 2.3.2 PROCESSUS DE CONSTRUCTION BOTTOM-UP Un processus de construction bottom-up et cherche à combiner des composants déjà existants et disponibles en les sélectionnant et en les connectant de manière incrémentale afin de construire un assemblage valide [91, 92]. Dans un tel processus de construction, la solution n défini. Cependant, la plupart des approches ne fournissent pas assez de méta- processus de construction [92]. Un processus bottom-up est soumis à la combinatoire engendrée par le choix des composants et des connexions à chaque pas de la construction. Nous verrons dans le chapitre 4 que la recherche de la, tenter la vérification de la correction un assemblage donné a une complexité algorithmique élevée [23, 5, 6]. Le coût imposé par ces algorithmes interdit leur utilisation itératif incrémental EVOLUTION DYNAMIQUE Ainsi, dans la nature, les systèmes les plus complexes sont issus des évolutions de systèmes plus simples qui fonctionnent Contexte Nous étudions s dynamique peuvent être répertoriées etc. SafArchie [39] autorise la création / destr, la création / destruction de liaisons et le raffinement. ACCORD [30], SOFA 2.0 [50], Fractal [18] et Wright [36] autorisent la substitution de composants. Dynamic Wright [105 t en charge de la évolution. Ainsi, Il permet de faire face à certaines pannes qui pourraient se produire lors de. Le configurateur définit des stratégies de réassemblage concernant certains des initial. Cependant les évolutions possibles doivent être anticipées lors de la phase de conception. Fractal [18 / suppression de connexions. SOFA/DCUP [28] permet le versionnement automatique de composants. UNICON [37 torise pas Ces modifications dynamiques peuvent intervenir soit au niveau Différentes stratégies sont employées suivant les approches : Page 43

44 Certaines approches interdisent l 48, 49, 37]. Les assemblages ne peuvent à de référence. Dans cette la phase de 45]. Dans Koala [53 existant soit estampillée comme optionnelle. Il est interdit de supprimer une 14] et SOFA 2.0 [50] utilisent des modèles (patterns) pour spécifier quelles interfaces pourront être connectées ou déconnectées et quels composants pourront être ajoutés ou supprimés approches [36, 51] utilisent des règles logiques, un moyen plus puissant pour exprimer toutes les conception et nécessitent pas toujours possible [50, 52]. Dans le cadre de notre travail nous étudions la substitution de composants Substitution de composants un-à-un La problématique relative à la substitution de composants part des hypothèses suivantes : Un assemblage valide de composants est disponible Un composant cible de cet assemblage doit être remplacé la substitution doit alors Ainsi, le nouveau composant doit pouvoir assurer au moins les mêmes services que le composant cible. De plus le nouveau composant ne doit pas se trouver dans un état incohérent : ses interfaces non La compatibilité stricte et la compatibilité contextuelle sont deux règles de sûreté employées par les modèles existants. La compatibilité stricte [84, 28, 18, 50] est basée sur le principe suivant : le nouveau composant La compatibilité contextuelle est proposée par Brada [85]. Cette compatibilité est plus flexible composant peut ne pas posséder cette rfaces requises que ne possédait fournisse des interfaces fournies compatibles. Page 44

45 Modification c -à-dire au processus de mise à jour du système repose sur les quatre points suivants : 1. Suspendre 2. Réaliser les modifications 3. Valider le système 4. Reprendre Un assemblage valide de composants correspond à un graphe de dépendances entre composants. La U Une problématique intéressante s être interrompue «AUTONOMIC COMPUTING» -organiser [109]. : les approches à composants et les agents [108]. Les agents peuvent être vus comme des entités autonomes. Cependant, définir des buts locaux à chaque agent pour atteindre un but global est difficile [110]. Le problème des approches à composants existantes est que le processus de construction est topdown un est pas adapté auto-organisation. En effet, dans un tel s de composants résultant. partir de composants réutilisables accessibles sur étagère. Le problème peut être énoncé comme suit : s et un référentiel de composants, automatiser la Ce problème est s. Construction automatique. construction automatique peuvent être classés en deux catégories : Ces travaux cherchent à le rendre valide. Les auteurs de [67, 60, 61] présentent un système qui permet interactions incompatibles et génèrent des adaptateurs afin de les rendre compatibles. Grondin [68] propose la construction automatique : un ensemble de composants pré-définis devant être assemblés Page 45

46 manière orientée par la politique de construction. De plus, leur processus de construction ne permet pas de construire toutes les architectures qui satisfont les objectifs fonctionnels. Ora [69] pose une problématique très intéressante : «given a set of application requirements (including here possible environmental constraints) and a library of components being available, how to select and assemble the necessary components to define an adequate implementation?». Ce problème est intrinsèquement très complexe [69]. Evolution automatique. SOFA/DCUP [28] propose la mise à jour automatique de version de composants ans un premier temps téléchargées puis les partie de contrôle. DCUP introduit une implémentation spécifique des composants composant soit composé au minimum de deux objets : un manager (CM) et un constructeur (BC). Le CM se situe dans la partie permanente du composant. Il est le gestionnaire du composant. Il a pour mission principale de coordonner les mises à jour du composant. Il permet aussi de gérer des aspects non fonctionnels comme le cycle de vie et la sécurité du compo composant, un CM lui est associé. Le CB se situe dans la partie remplaçable du composant. Comme son version du composant. La mission principale du CB est de construire la partie remplaçable du composant. Le SOFAnode [28], de distribuer et : In, Out, Made, Run et Template Repository (TR). Un réseau de SOFAnode porte le nom de SOFAnet. La partie la plus importante du SOFAnode est le TR. En effet, le leur documentation (CDL). Polini [69] propose la mise à jour de composants en fonction du modèle des spécifications CRITERES DE QUALITES Un grand nombre de travaux [64, 62, 63, 65, 66] nt à la qualité des architectures logicielles. De bonnes architectures doivent satisfaire les objectifs fonctionnels du système. Le système doit être performant, fiable, portable et interopérable [57, 41]. Les métriques mesurant ces qualités sont variées et les modèles manquent de formalisation. Une approche intéressante est proposée dans [62]. Elle est basée sur est de prendre un composant individuel avec son protocole de comportement puis de construire une architecture dont le comportement est en accord avec les objectifs fonctionnels.? embarqués, la taille de la mémoire est un paramètre essentiel. Dans le domaine du temps réel, les ) doivent être effectués en temps contraint. Page 46

47 Minimalité. La minimalité du nombre de connexions dans une architecture est un bon critère. Deux architectures peuvent être valides, avoir les mêmes objectifs fonctionnels et avoir des nombres de connexions (parfois des connexions superflues) : elle peut perdre en efficacité, subir un plus vérification sémantique est plus coûteuse en temps. En effet, chaque connexion implique une vérification de protocole. Même pour un petit système, la vérification est exponentiel [6, 5] SYNTHESE Processus top-down. Dans une approche top-down la structure finale du système est définie lors de la phase de conception par. ésultant du déploiement est dit rigide itution de composants est dictée par des règles contraignantes de substitution un-à-un. le meilleur des cas, la validité du système impose que se conforme toujours au plan défini par son architecture. Processus bottom-up. Dans une approche bottom-up ue e système est construit de manière incrémentale, en fonction des composants disponibles à complètement des acteurs humains. Ainsi, une démarche bottom-up est particulièrement adaptée aux systèmes automatiques et mobiles, qui ont besoin de se reconfigurer automatiquement. La difficulté de ces approches est de guider la construction pour produire des architectures valides. 2.4 DISCUSSION NOS OBJECTIFS FACE A NT s soient de plus en plus robustes, fiables et de qualité tout en ayant un coût de construction minimum. Atteindre cet objectif passe par la construction composants existants. Un système logiciel à base de composants est construit dans le but de satisfaire des objectifs fonctionnels. Il peut être décomposé en trois parties : ses objectifs fonctionnels, son architecture et son code. Cette décomposition a pour but de maîtriser la complexité du système : sa description, sa validation et sa maintenance sont ainsi facilitées constitue la partie centrale de sa définition. Elle décrit la structure et le comportement du système. Elle se décompose suivant quatre vues : une vue structurelle, une vue syntaxique, une vue sémantique. La vue structurelle correspond au squelette du système. Page 47

48 Rappel de notre objectif principal système est valide si son comporteme composants est guidée par les objectifs fonctionnels et non par des règles prédéfinies. La construction : l s composants et la vérification de la validité Motivations. Nous avons pu mettre en évidence, que de nombreux travaux s 41, 45, 37, 36, 35, 13, 12, 53, 81] qui [29, 22, 21, 30, 19, 17, 36, 35 aux processus de e, mais que peu de travaux est amené à faire pour construire son architecture. Le Tableau 3 constitue un bilan général concernant les approches à composants existantes. Lorsque uel composant choisir? Quel point de connexion connecter? A quel autre point de connexion le connecter? Les réponses à ces trois questions doivent être guidées par les objectifs fonctionnels du système. Or ration est locale. Nous verrons que les ports permettent de réaliser cela en raisonnant de manière locale. Il est avantageux e première architecture qui ne 23, 5, 6 envisageable de relancer le processus de validation de manière inconsidérée. Habituellement, : le niveau syntaxique (i.e. les types) et le niveau sémantique (i.e. les protocoles). Le niveau minimal de cohérence requis par un système est ce qui est couramment appelé la vérification syntaxique. Celle-ci peut être assimilée à une vérification de typage au sens des langages à typage statique. Cependant, garantir un niveau syntaxique de correction dans un assemblage n'est pas suffisant pour garantir un comportement cohérent de l'ensemble du système. Un exprimer de manière formelle des contraintes de collaboration entre composant composants et de connexions entre composants. Page 48

49 Nom du modèle Caractéristiques Style de processus de construction Spécification de la sémantique Type de vérification Evolution dynamique / validation UML 2.0 Langage semi-formel standard de Métamodèle / Machine à états de protocole ACCORD système suivant plusieurs niveaux Métamodèle / Contrats Comportementale. Assertions Substitution composant-à-composant (compatibilité contextuelle) / oui SOFA / DCUP Permet de générer le protocole Changement de version dynamique et automatique ADL : CDL / topdown Protocoles de comportements Comportementale. détection des cycles / contrôle statique SOFA/DCUP : Versioning (automatique). Substitution composant-à-composant (compatibilité stricte) /oui Wright Wright permet la description de configuration précise du système. ADL / top-down Algèbre de processus CSP Comportementale / Détection des deadlocks. contrôle statique Substitution composant-à-composant. Prévoir des pannes / oui Darwin Permet la description du schéma entre les instances ADL langage de programmation / top-down Pi-calcul Dynamique de collaboration entre instances. Détection statique et dynamique sants sur des sites répartis / oui Rapide Description de systèmes événementiels ADL langage de programmation / top-down Protocole de comportement + contraintes (événements) Contrôle statique et dynamique /oui Fractal basés sur les contrôleurs Top-down et bottom-up Typage Typage Substitution composant-à-composant (compatibilité stricte). Ajout / suppression de connexions /oui ArchJava système au niveau du langage Java Langage de programmation / top-down Typage Typage -- Tableau 3 : Bilan général concernant les approches à composants C requiert un haut niveau de compétence. Généralement, l exclusivement destinée au checker. Problématique. Le problème principal auquel est con au système. L suivantes : Quel composant choisir? Quelles connexions effectuer? Page 49

50 Les réponses à ces deux questions doivent être guidées de rendre globalement cohérent le système. Le choix du composant et de ses connexions ont un impact direct sur la qualité de [62] être un spécialiste [63] ou doit être assisté par un outillage performant.. les protocoles de comportement de la vue sémantique. Les deux informations importantes sont les suivantes : Les dépendances entre les donnée, ation pair-à-pair de connexion, sait gérer. sinon, ne figure que dans les protocoles. Cependant, la sémantique des ports telle qu décrite dans les modèles de composants existants nous semble trop restrictive car elle ne permet pas de représenter des dépendances complexes. La Figure 25 Figure 25 Contribution. métamodèle adapté qui fournisse les concepts Nous allons introduire le concept de port composite. Il va permettre n ne connectant que ce qui est nécessaire pour atteindre les objectifs fonctionnels) tout en raisonnant de manière locale au composant Automatisation de la construction. Les approches existantes suivent un processus de construction top-down car il assure une maîtrise de la complexité du système tout au long du cycle de vie : de la phase de conception e composants est valide Page 50

51 de construction top-. Dans le but de garantir une sûreté du système ces approches doivent anticiper, lors de la phase de design, toutes les évolutions qui pourront être réalisées lors Un processus top-down ne convient pas à nos objectifs. Nous souhaitons construire non pas une, mais les meilleures architectures. Un deuxième argument en défaveur du choix top-down de anticipé. Les approches existantes se focalisent sur la vérification assemblage déjà existant. Elles tème. bottom-up car un tel processus de construction est confronté à deux gros problèmes. Le processus de construction bottom-up se focalise sur la construction de systèmes valides à partir de composants déjà validés. assemblages pour satisfaire les besoins fonctionnels). Des composants sur étagères sont ainsi utilisés pour construire un système valide de manière incrémentale. Le problème est que le processus de construction bottom-up se heurte à de gros problèmes de combinatoire ce qui le rend inefficace et inutilisé dans la réalité (excepté sous certaines hypothèses très contraignantes). Les ports primitifs et composites sont des éléments structurels qui vont permettre la construction et la reconstruction suivant un processus de construction bottom-up. Figure 26 bottom-up Cependant l difficultés manière incrémentale ce qui interdit son utilisation pour atteindre nos objectifs avec les concepts émental sont illustrées sur la Figure 26. Problématique. Nous verrons qu les suivants : liée au processus incrémental de construction, la combinatoire pour atteindre la validité. Page 51

52 Contribution. bottom-up métamodèle sur un niveau de vérification adapté (moins coûteux en temps de calcul). Nous souhaitons automatiser le processus de construction afin de construire toutes les architectures valides puis toutes les architectures de taille minimale. Pour ce faire, nous reprenons les concepts de ports composites et de quasi-validité que nous avons présentés précédemment [100, 94] Evolution dynamique sûre et non anticipée non anticipée Nous voulons proposer une approche inédite permettant de faire de la substitution de composant de manière automatique, sûre et non anticipée. Dans un tel contexte, notre défi -à-un, dite classique, en une substitution n-à-1, inédite, lorsque la première est impossible à utiliser PROPOSITION avons aussi, pour chaque objectif, énoncé une partie de notre proposition. Cette section est destinée à préciser, de manière synthétique, la stratégie globale de notre approche : les chapitres suivants auront Chapitre 3. Ce chapitre propose notre métamodèle de composants à base de ports. Celui-ci constitue les fondements de notre approche. Il va être utilisé pour répondre aux problématiques telles que ssemblages valides de composants (chapitre 4 5). De manière plus précise, les concepts que nous allons décrire dans le métamodèle vont permettre : fonctionnels de ce dernier tout en raisonnant de manière locale au composant. De définir un niveau de vérification intermédiaire (la quasi-validité) moins coûteux en temps de calcul qui peut être utilisé lors du processus de construction. De permettre un processus de construction bottom-up efficace. Ce chapitre propose aussi les niveaux de vérification suivants : validité, correction, complétude. Nous commençons par définir la validité. Une propriété de validité est ensuite définie afin de prouver la validité à partir de la correction et de la complétude. Une propriété de quasi-validité basée sur les ports Chapitre 4. Ce chapitre traite de la construction automatique cause de problèmes de combinatoire, notre stratégie consiste à construire des assemblages valides en utilisant la propriété de validité comme suit : Page 52

53 s. La propriété de quasi-validité est utilisée pour construire des assemblages complets. Vérification de la correction sur ces assemblages pré-calculés Chapitre 5. Notre algorithme de construction sera ensuite utilisé pour reconstruire des parties Chapitre 6. Une implémentation du métamodèle et des algorithmes de construction et de reconstruction sont proposés. Page 53

54 3 METAMODELE SEMBLAGE DE COMPOSANTS 3.1 INTRODUCTION Nous proposons dans ce chapitre un méta-modèle de composants logiciels enrichi de ports composites a processus de vérification Notre métamodèle de ports constitue les fondements de notre approche. Les ports composites vont construction assemblages complets (satisfaisant les objectifs fonctionnels du système) suivant un processus de construction bottom-up. Le métamodèle. Notre métamodèle définit les concepts ainsi que leurs relations pour décrire un système logiciel. Pour des raisons pratiques, la présentation de notre métamodèle est scindée en trois parties distinctes : la partie du métamodèle relative à la vue, la partie du métamodèle relative à la vue interne et la partie du métamodèle relative à la vue globale du système. Nous exposons notre métamodèle dans cette introduction puis nous y ferons référence tout au long de ce chapitre. La partie du métamodèle relative à la vue composant est présentée sur la Figure 27 et celle relative aux types est présentée sur la Figure 28. Figure 27 : Partie du métamodèle représentant la : concepts principaux Page 54

55 Dans notre approche un composant interagit avec son environnement via des ConnectableFeature. Un type ConnectableFeatureType est associé à un ConnectableFeature. Ce dernier est composé syntaxique et sémantique. Un ConnectableFeature peut être soit une ConnectableInterface, soit un PrimitivePort, soit un CompositePort. Une ConnectableInterface est le plus petit élément connectable de notre métamodèle. Un PrimitivePort peut être assimilé à une prise simple : il regroupe un ensemble de ConnectableInterface un autre composant. Un CompositePort peut être assimilé à une prise complexe. Il regroupe un ensemble de Port composants. Figure 28 : Partie du métamodèle représentant la : types Un composant peut exposer des ConnectableFeature. Dans ce cas une telle ConnectableFeature joue le ExposedFeature (section ). composites exposés être utilisé dans des A un niveau structurel, le partage représente alternative dans le choix des Cette notion est développée dans la section La notion de cohérence permet de calculer la quasi- Cette notion est développée dans la section Page 55

56 Figure 29 : Partie du métamodèle Figure 29. Un composant peut être primitif (PrimitiveComponent) ou composite (CompositeComponent). Un PrimitiveComponent possède un contenu qui correspond à des classes qui implémentent directement les services fournis par le composant. Un CompositeComponent possède une architecture (Architecture) qui représente son contenu. Les composants un même niveau de composition hiérarchique via des AssemblyConnection. La délégation est possible via des DelagationConnection. Nous introduisons, de manière informelle, la délégation multiple, c'est-à-dire un ensemble de ports vers un autre ensemble de ports. La partie du méta modèle relative à la vue globale du système est présenté sur la Figure 30. Un système logiciel (SoftwareSystem Architecture) et possède un ensemble fonctionnels (FunctionalObjective). Un FunctionalObjective correspond à un ou à plusieurs ConnectableFeature exposés (i.e. ExposedFeature Page 56

57 Figure 30 Partie du métamodèle représentant la vue globale du système La validité. Nous présentons à la fin de ce chapitre les différents niveaux de composants. ne tiennent pas compte des objectifs fonctionnels. Notre approche considère les objectifs fonctionnels comme étant le centre névralgique de la vér : l -elles suffisantes pour satisfaire les besoins fonctionnels? Partant de cette idée voici notre démarche : Présenter un niveau de vérification évolué : la validité. Ce niveau étend les niveaux de vérifications classiques en y intégrant la vérification du respect des objectifs fonctionnels du système. La validité est atteinte lorsque les deux points suivants sont vérifiés : - qui constitue la vérification classique utilisée dans la plupart des approches. - s suffisantes à la satisfaction des objectifs fonctionnels. Présenter un niveau de vérification intermédiaire : quasi-validité. Elle est basée sur les ports et permet pas perdre de vue notre objectif qui consiste à construire des assemblages de composants in nombre s vérifiant la propri la quasi-validité est basée système de manière simple et peu coûteuse en temps de calcul. Plan du chapitre. Le chapitre est organisé de la manière suivante : la section 3.2 présente la partie du métamodèle relative à la vue, la section 3.3 présente la partie du métamodèle relative à la vue interne, et la section 3.4 présente la partie du métamodèle relative à la vue globale du système. La section 3.6 conclut le chapitre par une discussion. Page 57

58 3.2 PARTIE DU METAMODELE DECRIVANT LA VUE EXTERNE COMPOSANT La partie du méta-modèle relative à la vue e dans cette section. En ette section décrit les éléments de la vue boîte y définissons notamment le concept de composant ainsi que les concepts permettant de décrire ses. Nous définissons également un système de types et des règles de compatibilité pour assembler les composants. métamodèle et de notre approche de règles de partage et de cohérence. Ces règles ont pour but de permettre de déterminer la quasi-validité COMPOSANT Cette section vise à présenter le concept de composant. Une présentation réalisée au niveau du modèle, puis une définition formelle est ensuite énoncée. Il est à noter que durant la description du métamodèle, nous ferons référence à des concepts (ConnectableFeature, ConnectableInterface, Port, PrimitivePort, CompositePort) qui seront étudiés dans le détail dans les sections suivantes Métamodèle Une première partie du métamodèle est présentée sur la Figure 27. Elle décrit les concepts relatifs à la vue La Figure 28 présente la partie du métamodèle relative au typage. Nous commençons ici par détailler les trois principaux concepts relatifs à un composant. ConnectableFeature. Un composant interagit avec son environnement au travers de points de connexion (ConnectableFeature). Les ConnectableFeature seront développées en détail dans la section ExposedFeature. Parmi ConnectableFeature) certains jouent ExposedFeature. Les ExposedFeature définissent chacun des contextes de connexion possibles (des rôles possibles) pour le composant. Cela est possible de connecter un ExposedFeature ConnectableFeature pour que le composant soit cohérent. ComponentType. Un type (ComponentType) est associé à un composant (Component). Ce type alisation de la classe Type association ComponentProtocol. Les protocoles. Le travail présenté dans cette thèse ne traite pas directement des protocoles de comportement. Aussi les classes telles que BehaviorProtocol, CollaborationProtocol, CommunicationProtocol et ComponentProtocol ne seront pas détaillées comme les autres. Elles sont cependant inspirées de concepts utilisés par Plasil [29] et Mencl [24]. Page 58

59 Un protocole de comportement (BehaviorProtocol laquelle celui-ci est rattaché. Un protocole de comportement est décrit par une expression régulière. Nous précisons que dans le cadre de ce manuscrit, nous utilisons un ensemble couramment utilisés s sur les protocoles. Nous Figure 31 sera utilisé pour illustrer notre propos. Cet exemple sera repris dans la suite de ce manuscrit.!). Un composant peut émettre un message via une ConnectableInterface requise.. Exemple : peut être émis via la ConnectableInterface requise du composant. Remarque : Par convention ConnectableInterface est une minuscule. Interface du langage de programmation. (?). Un composant peut recevoir un message via une ConnectableInterface fournie.. Exemple : peut être reçu sur la ConnectableInterface fournie du composant. La séquence simple ( ).. Les choix possibles parmi un ensemble de séquences de messages sont représentés par. La répétition (*). est représentée par. Nous distinguons différents types de BehaviorProtocol : le CommunicationProtocol, le CollaborationProtocol, et le ComponentProtocol. CommunicationProtocol. Le protocole de comportement attaché au type (ConnectableInterfaceType ConnectableInterface est le CommunicationProtocol. Il ConnectableInterface transitant par cette ConnectableInterface. Exemple : Figure 31 le ConnectableInterfaceType de la ConnectableInterface dialogue a un CommunicationProtocol : connect ; (cancel + withdrawal + balance) * ; disconnect CollaborationProtocol. PortType) est le CollaborationProtocol. Page 59

60 -à-dire les messages entrant sur ses ConnectableInterface fournies et ceux sortant de ses ConnectableInterface requises. Le CollaborationProtocol inclut chacun des CommunicationProtocol de ses ConnectableInterface. Exemple : Figure 31 le PortType du PrimitivePort Money_Dialogue du composant ATM a un CollaborationProtocol : (?dialogue.connect{!dialogue.clientidentify} ;(?dialogue.cancel + ((?dialogue.withdrawal ;!money.getmoney) *) + ((?dialogue.balance;!money.getticket) *) );?dialogue.disconnect ConnectableInterface composant le port (dialogue est la ConnectableInterface fournie et money est la ConnectableInterface requise) sont spécifiées pour décrire sans ambigüité quelles sont les ConnectableInterface en jeu. On peut remarquer que le CollaborationProtocol inclut 29]) le CommunicationProtocol de dialogue. ComponentProtocol. ComponentType) est le ComponentProtocol Le ComponentProtocol CollaborationProtocol de ses ports. ((?dialogue.connect{!dialogue.clientidentify} ; (?dialogue.cancel + + ((?dialogue.withdrawal{!control.checkbalance ;!transaction.withdrawal} ;!money.getmoney) *) + ((?dialogue.banance{!transaction.balance} ;!money.getticket) *) );?dialogue.disconnect) ((?order.moneystocktest ;!stock.askmoney) ;!control.updatestock) + On peut remarquer que celui-ci inclut le CollaborationProtocol de Money_Dialogue Définition formelle La définition formelle du concept de composant est énoncée ci- Figure 31 sera utilisé pour illustrer la définition. Définition : Un composant est défini comme un septuplé : Page 60

61 est une chaîne de caractères qui correspond au nom du composant. ConnectableInterface fournies de. ConnectableInterface requises de. Remarque : Les ConnectableInterface sont définies formellement dans la section Figure 31 : Exemple : La partie droite de la Figure 31 montre la déclaration de la boîte noire du composant ATM. Trois ConnectableInterface sont déclarées comme fournies (, order et ) et cinq autres comme requises (, control, transaction, stock et ). C. Remarque : Les PrimitivePort sont définis formellement dans la section Exemple : La clause permet de déclarer tous les ports primitifs du composant. Les ports et User_Info sont ainsi définis. Le port primitif est défini comme étant composé des ConnectableInterface et. ous les ports composites de C. Remarque : Les CompositePort sont définis formellement dans la section Exemple : La clause CompositePorts permet de déclarer tous les ports composites du composant ATM. Un port composite est ainsi défini. Ce port composite est composé de deux ports Page 61

62 primitifs directs ( et ) spécifiés via la clause DirectPrimitivePorts. s composites : la clause DirectCompositePorts est vide (cf. Figure 31). ConnectableFeature exposées par le composant (ExposedFeatures). Notation [ ] composites exposés. correspond à la restriction de aux ports composites. Exemple : Dans (cf. Figure 31), la clause ExposedFeatures contient le port composite ainsi que tous les ports primitifs Money_Dialogue et de Money_Transaction. Un exemple plus complet sera présenté dans la section est le protocole de comportement (ComponentProtocol) associé à C. Exemple : La clause composant Description (ADL) La boî C est décrite comme suit :. Les clauses ConnectableInterfaces, PrimitivePorts, CompositePorts, ExposedFeatures et ComponentProtocol sont utilisées dans le corps de la BlackBox. La clause ExposedFeatures permet de déclarer les ConnectableFeature exposées par le composant. Cet ensemble peut donc contenir des ConnectableInterface, des PrimitivePort et des CompositePort. Nous faisons remarquer que les clauses ConnectableInterfaces, PrimitivePorts et CompositePorts seront détaillées dans la suite de ce manuscrit Notations, propriétés et opérateurs Voici ci-dessous un ensemble de notations et une propriété. Propriété : Notation : [ ] On note ConnectableInterface de. Notation : [ ] On note C ELEMENT CONNECTABLE Nous avons mis en évidence,, que les composants interagissent avec leur (dans sa version primitive) de granularités différentes. Dans ces approches, un point validation du futur assemblage de composants. Dans notre approche, les éléments connectables sont : Page 62

63 connectable (ConnectableInterface) et les ports (Port). Nous considérons à la fois des ports simples (PrimitivePort) et des ports composites (CompositePort). La notion de port composite fait partie utilisée comme élément de connexion de plus faible granularité dans certaines approches à composants [13, 35, 37] ConnectableInterface. En effet, ConnectableInterface Interface qui Un élément connectable ConnectableFeature (cf. Figure 27) possède un nom (name) une cardinalité minimale (CardMin), une cardinalité maximale (CardMax) et une cardinalité courante (CurrentCard). La cardinalité correspond au nombre de connexions effectuées au niveau du ConnectableFeature. Un type (ConnectableFeatureType) est associé à un ConnectableFeature. Un élément connectable (ConnectableFeature) possède un type (ConnectableFeatureType). Ce type est Type. Un ConnectableFeatureType possède une direction (Direction) de type DirectionType dont la valeur est CLIENT, SERVER ou bien MIXED. Dans les travaux existants, la notion de direction existe uniquement pour ce qui correspond dans notre métamodèle aux ConnectableInterface. Dans ces travaux, la direction est soit CLIENT soit SERVER. Dans le cadre de ce manuscrit, nous étendons cette notion à tous les éléments connectables (i.e. ConnectableInterface, PrimitivePort, CompositePort). Une direction de type CLIENT signifie que le ConnectableFeature associé joue le rôle de demandeur de service Une direction de type SERVER signifie que le ConnectableFeature associé joue le rôle de fournisseur Une direction de type MIXED signifie que le ConnectableFeature associé peut jouer les deux rôles. Remarque : Un port primitif peut être bidirectionnel (i.e. être composé de ConnectableInterface fournies et requises) et avoir une direction de type CLIENT, SERVER ou bien MIXED. Remarque : La direction peut être déterminée à partir de son CollaborationProtocol : la direction du premier appel (entrant ou sortant) détermine alors le rôle du port (dans le cas où identifiable sans ambiguïté). Cependant, dans le cadre de ce travail de thèse nous nous contenterons de considérer que les directions des ports sont MIXED INTERFACE CONNECTABLE Une interface connectable (ConnectableInterface, cf. Figure 27) composant et son environnement. Elle est caractérisée par un type qui est lui-même défini par un ensemble (cliente ou serveur). Une interface connectable (ConnectableInterface) est un ConnectableFeature et peut être spécialisée suivant sa direction : fournie (ProvidedConnectableInterface) ou requise (RequiredConnectableInterface). Un type (ConnectableInterfaceType) est associé à un ConnectableInterface. Une interface connectable (ConnectableInterface) possède un type (ConnectableInterfaceType de programmation (Interface) associée Page 63

64 et par la direction. Une Interface est composée de signatures d représentée par le protocole de communication CommunicationProtocol. Un CommunicationProtocol est un protocole de comportement (BehaviorProtocol) Définition formelle Nous présentons ci- e ConnectableInterface. Définition : Une interface connectable (ConnectableInterface) est définie comme un triplet :. est une chaîne de caractères qui correspond au nom de la ConnectableInterface. :. o au sens langage de programmation) associée. o. o interface connectable (ConnectableInterfaceType) est donc caractérisé par, et ; le type syntaxique étant caractérisé par et le type sémantique par. On note :, et Description (ADL) Les Interface (au sens langage de programmation) sont spécifiées via la clause Interface. Les ConnectableInterfaceType sont spécifiées via la clause ConnectableInterfaceType. Les Interface et les ConnectableInterfaceType sont déclarés en dehors du composant. Une ConnectableInterface est composant via la clause ConnectableInterface. Exemple : Dans la Figure 32 le composant Client possède deux ConnectableInterface fournies : et et deux ConnectableInterface requises : et. La ConnectableInterface money est déclarée dans la clause ConnectableInterface du composant Client. Ainsi la ligne suivante, money: {Name: «money», Card: 1, ConnectableInterfaceType: Money_cit_p}, spécifie que le nom de cette ConnectableInterface est «money», que sa cardinalité a pour valeur 1 et que son type est Money_cit_p. Le type Money_cit_p est défini dans la clause ConnectableInterfaceType. Celui- Interface Dialogue. Remarque : Afin de ne pas surcharger la Figure 32 nous volontairement pas fait apparaître les signatures des opérations. Page 64

65 La clause Direction indique Required et son protocole de communication est défini dans la clause CommunicationProtocol. Figure 32 : Compatibilité assemblage de Connectable_Interface Nous allons présenter dans cette section la relation de ConnectableInterface de compatibilité sémantique. Dans le cadre de ce travail nous centrons notre intérêt autour de la relation de compatibilité syntaxique. Compatibilité syntaxique. Définition : Une ConnectableInterface spécialise une ConnectableInterface, noté, si On rappelle que correspond à et que correspond à. La notation correspond à la relation de sous-typage classiquement utilisée dans les langages à objets. Nous avons proposé [95, 96] les bases théoriques formelle de concepts pour une construction incrémentale des annuaires de composants basée sur les définitions syntaxiques des services requis et fournis. Dans ce travail nous proposons une relation de compatibilité syntaxique plus évoluée. Page 65

66 Deux ConnectableInterface et sont syntaxiquement compatibles si elles sont reliées par spécialisation. Définition : Soit et deux ConnectableInterface. ssi ou. Compatibilité sémantique. Deux ConnectableInterface et sont sémantiquement compatibles si leur types sémantiques respectifs sont compatibles. Ce manuscrit ne traite pas de la comparaison des protocoles de comportement. En revanche certains travaux comme SOFA [29] ont déjà largement abordé ce thème. Dans le cadre de ce travail, on se contentera de compatibilité si les deux ConnectableInterface sont sémantiquement compatibles.. Deux ConnectableInterface et sont compatibles si elles sont syntaxiquement et sémantiquement compatibles et si leurs cardinalités sont strictement positives PORT Un port (Port, cf. Figure 27) est un élément connectable (ConnectableFeature) qui représente de manière structurelle et explicite des dépendances entre ConnectableInterface. Un type (PortType) est associé à un Port. Un port (Port) possède un type (PortType). Un PortType de ConnectableInterfaceType. Un PortType ConnectableFeatureType CollaborationProtocol). Un CollaborationProtocol est un protocole de comportement (BehaviorProtocol). Le port est déclaré comme une classe abstraite. Il peut être spécialisé en port primitif et en port composite. Les ports primitifs et composites sont des éléments structurels qui pe que les ConnectableInterfaces mises en jeu : les dépendances structurelles entre interfaces, les dépendances de connexions pair-à-pair, la structure en sous- es grâce aux ports. La réutilisation du composant PORT PRIMITIF Un port primitif est Il regroupe un ensemble de ConnectableInterface. De manière imagée, il représente une prise simple. De manière plus abstraite, il représente une pair-à-pair potentielle avec un autre composant. Un port primitif (PrimitivePort) est un Port qui est composé de ConnectableInterface. primitif est représenté par un PortType. ses ConnectableInterface. Un port primitif peut être assimilé à une contrainte forte de connexion sur ses Page 66

67 ConnectableInterface. En effet, il exprime premièrement des dépendances de connexion entre ses ConnectableInterface et deuxièmement une connexion pair-à-pair eut être vue comme la conjonction de deux sous-contraintes : le premier est que toutes les ConnectableInterface doivent être soit toutes connectées soit toutes déconnectées. La seconde est que si elles sont connectées, alors elles le sont à des ConnectableInterface composant Définition formelle Voici la définition formelle du port primitif. Définition : [Port primitif] Un port primitif est défini comme un quadruplet : est une chaîne de caractères qui correspond au nom du port primitif. connectables de. Propriété :. correspond à la cardinalité ConnectableInterface termes, la cardinalité indique le nombre de connexions supporter. La Figure 33 illustre cela. Dans cet exemple, le composant possède un port primitif qui est lui-même composé des ConnectableInterface,. La cardinalité de est égale à. Figure 33 : Cardinalité est le protocole de comportement associé à (CollaborationProtocol). Définition : est caractérisé par ConnectableInterface et par son protocole de collaboration. Page 67

68 Où est la direction héritée de ConnectableFeatureType. et Description (ADL) La clause permet de déclarer tous les ports primitifs de la boî mposant. La syntaxe est la suivante : PrimitivePorts :{Name :... ; ConnectableInterfaces Exemple : (cf. Figure 31). Les ports,, et User_Info sont ainsi définis. Le port primitif est défini comme étant composé des ConnectableInterface et Notations et opérateurs Nous posons un ensemble de notations et définissons un ensemble relatifs au port primitif. Notation : [ ] Soit la notation pour signifier que le port primitif est connecté à un autre port primitif. Dans la Figure 34, si du composant alors vaut vrai puisque le port primitif du composant est connecté au port primitif du composant ATM du composant alors est faux puisque celui- Notation : [ ] Soit la notation pour signifier que le port primitif possède une cardinalité courante strictement positive. Figure 34 : Illustration des concepts relatifs aux ports primitifs et composites Page 68

69 Compatibilité Compatibilité syntaxique. ports primitifs. La relation que nous présentons est une relation de compatibilité forte car elle potentielle entre les interfaces des deux ports. Une fois que la compatibilité a été établie entre deux ports via la relation, alors on plusieurs configurations. En effet, dans un contexte où -même les composants la relation pourrait être utilisée. Ainsi, en té, celui-ci pourrait Dans un contexte de co est utilisée. Deux ports primitifs et sont compatibles si et nt le même nombre de ConnectableInterface et si chaque ConnectableInterface de possède une unique ConnectableInterface compatible dans (compatible au sens de ). Définition :. Soit et. est syntaxiquement (noté : ) si et seulement si il existe une unique bijection de ConnectableInterface de ConnectableInterface de assurant que les ConnectableInterface correspondantes sont compatibles. Compatibilité sémantique. La compatibilité sémantique fait intervenir les protocoles de collaboration de chacun des deux ports. Comme pour le cas de la compatibilité sémantique des ConnectableInterface (section ,, et qui ne fai dans [24]. blage. syntaxiquement et sémantiquement compatibles, et si leur cardinalité respective est strictement positive. Il est nécessaire de contrôler les cardinalités car celles-ci peuvent varier à cause des intersections de ports primitifs et de leurs connexions. En effet, dans le cas général, des intersections peuvent exister entre des ports primitifs. Dans c des ports primitifs qui partagent au moins une interface doit être mises à jour. De manière formelle, et peuvent être connectés si PORT COMPOSITE Il est composé de ports. De manière imagée, il représente une prise complexe (un ensemble de parties de Page 69

70 collaborations pair-à-pair ). Un port composite (CompositePort, cf. Figure 27) est un Port qui est composé de Ports. Il peut être composé de PrimitivePort et/ou de CompositePort. Le PortType : ses ConnectableInterface. comportement du composant et représente une contrainte faible de connexion sur ses ports primitifs directs et indirects. Dans le cas simple (i.e. pas de partage de ports primitifs), sa connexion impose la connexion simultanée de tous ses ports primitifs directs et indirects, mais avec la possibilité de les connecter à des composants différents. Le cas du partage sera débattu dans la section Pourquoi le port composite? Afin de montrer le réel intérêt du port composite, plaçons-nous dans un contexte où celui- pas. La principale limite du port primitif est corrélée à sa granularité. Plus celle-ci est importante et plus il est difficile de trouver un port primitif compatible. La question qui se pose est alors la suivante : e. collaborations multi-pair-à-pair)? Si le port primitif est le seul concept disponible pour exprimer cela alors la seule solution est de créer un port primitif qui contienne toutes les interfaces qui apparaissent dans la partie de la collaboration complexe. Figure 35 : Les limites structurelles des ports primitifs lution raisonnable car elle sur contraint le problème en pair-à-pair. Il est à noter que la solution qui consiste à découper le port primitif de grosse granularité en plusieurs ports primitifs de granularité moi simultanées entre ces ports ne peut être exprimée. La Figure 35 illustre cela. Page 70

71 Définitions formelles Voici Définition : est défini comme suit : est une chaîne de caractères qui correspond au nom du port composite. directs de :. directs de. Un port composite de est luimême composé de ports primitifs et de ports composites. : les ports primitifs directs ( ), les ports composites directs ( ), les ports primitifs directs et indirects ( cf. section ), les ports composites directs et indirects ( cf. section ) Description (ADL) La clause permet de déclarer tous les ports composites de la boîte composant. Le corps est constitué des clauses suivantes : ; Le nom du CompositePort est défini. Direct. PrimitivePort PrimitivePort du composant. Direct. CompositePort des CompositePort du composant. Exemple : u composant ATM (cf. Figure 31). Le port composite est composé de deux ports primitifs directs et ) spécifiés via la clause DirectPrimitivePorts de ports composites : la clause DirectCompositePorts est vide Notations, propriétés et opérateurs Propriété : Soit un port composite de. Notation : [ ] Soit la notation pour signifier que tous les ports primitifs directs et indirects de sont connectés. est défini ci-après. Exemple : En repre (cf. Figure 34), si du composant alors est vrai puisque tous ses ports primitifs, et, sont connectés. Notation : [ ] Un port composite partiellement connecté est noté, défini comme suit : Page 71

72 Exemple : (cf. Figure 34), si du composant alors est connecté et il en existe au du port composite du composant est connecté et le port primitif du port composite du composant Figure 36 : Exemple du composant MemberBank présenté sur la Figure 36 représente le composant un certain nombre de ports composites. Ceci a été fait dans le b es définitions présentées ci-dessous. La Figure 36 propose une description de la structure du composant. Notation : [ ] Un port composite (i.e. exposé) est noté (cf. Figure 36), le port composite est déclaré comme étant un port composite exposé pour le composant. Opérateur : [ ] Nous définissons qui sont directement ou indirectement contenus dans. Opérateur : [ ] Nous définissons comme composites qui sont directement ou indirectement contenus dans. Page 72

73 Les deux contraintes suivantes doivent cependant être satisfaites : - ne peut pas être un sous-port de lui-même : - ne peut pas contenir un port qui contient : Exemple : du composant alors et. Opérateur : [ ] Etant donné des ports composites exposés qui le partagent est noté comme suit : Exemple : Si du composant alors Partage de ports par des ports composites exposés Nous introduisons une notion structurelle importante véhiculée par les ports composites exposés : le partage de ports par des ports composites. exposés ports composites exposés qui le partage). Connecter entièrement ports composites revient ites partiellement connectés sont considérés comme cohérents. Nous rappelons que l t. Afin que ce contexte puisse être utilisé de manière cohérente, tous les ports primitifs directs et indirects du port composite doivent être connectés. Le partage de ports permet exprimer puisse intervenir dans des contextes Ainsi un port composite peut être partiellement connecté tout en étant cohérent, pourvu que ses ports primitifs directs et indirects qui sont connectés le soient dans un autre -même entièrement connecté. Opérateur : [ ] Cet exposé. Il renvoie un ensemble de ports primitifs : chaque de cet ensemble appartient à indirects de tel que est partagé par au moins un autre port composite exposé et différent de. Page 73

74 Exemple : du composant alors. En effet, et il existe tel que où Règle de cohérence Afin de déter doivent être connectées sont effectivement connectées chaque port composite exposé. Deux cas doivent alors être considérés : lorsque le port composite ne partage aucun port primitif avec un autre port composite exposé et celui où il partage certains de ses ports primitifs avec un autre port composite exposé exposé de la façon suivante : étant donné un port composite exposé, trois cas sont possibles pour que soit cohérent : 1. Tous ses ports primitifs directs et indirects sont connectés. 2. Tous ses ports primitifs directs et indirects sont déconnectés. 3. est partiellement connecté (i.e. l existe au moins un port primitif direct Dans ce cas, le port composite est cohérent si chacun de ses ports primitifs non partagés est déconnecté, chacun de ses ports primitifs partagés autre port composite exposé entièrement connecté. Le partage de ports primitifs possibilités de connexion alternatives dans différents contextes. Un port composite partiellement connecté peut représenter un rôle qui est inutile pour nt dès que ses ports primitifs De manière formelle : Remarque : représente le ou exclusif. Notation : [ ] On notera le fait que est cohérent. Page 74

75 3.2.7 BILAN La partie de notre métamodèle correspondant à la vue a été présentée dans cette section. Nous avons présenté la partie du métamodèle concernant les concepts généraux, puis celle relative aux éléments connectables et enfin celle concernant les types. Les concepts clés de notre approche sont les ports et principalement les ports composites. La Figure 37 synthétise les notions importantes relatives aux ports. Concept Port primitif Port composite composé de ensemble de ConnectableInteface ensemble de Port vue informelle prise simple: connexion pair-à-pair prise complexe: multi-connexion pair-à-pair relation compatibilité pour l'assemblage partage pour exprimer plusieurs contextes d'utilisation possibles cohérence toujours - entièrement connecté ou - entièrement déconnecté ou - existence de ports composites partagés entièrement connectés Figure 37 Bilan concernant les concepts de ports primitifs et composites principal de notre travail la construction assemblages valides de composants fonctionnels. Pour atteindre cet objectif, un niveau de vérification intermédiaire sera présenté dans la section 3.5. Ce niveau intermédiaire repose sur notre métamodèle et sur la notion de cohérence introduite dans cette section. 3.3 METAMODELE DE LA PARTIE INTERNE Après avoir présenté le métamodèle présentons dans cette section le métamodèle correspondant à sa nous nous intéressons à la composition hiérarchique. Le métamodèle composant est présenté sur la Figure ARCHITECTURE Une Architecture est composée de Component et de Connection. Dans notre métamodèle les Component appartiennent à un référentiel de composants (ComponentRepository). Le ComponentRepository est formalisé dans la section Ce dernier sera utilisé dans le chapitre Page 75

76 valides. Les Connection sont étudiées dans la section 3.3.3). Nous donnons ci- Définition : Une architecture est définie comme suit :. correspond à un ensemble de composants. correspond à un ensemble de connexions entre les composants COMPOSANT Un composant peut être primitif ( ) ou composite ( ). Un PrimitiveComponent possède un contenu qui correspond à des classes qui implémentent directement les services fournis par le composant. Dans notre métamodèle, cela correspond à. Un CompositeComponent possède une architecture (Architecture) qui représente son contenu. Nous allons la détailler dans la section suivante CONNEXION ENTRE COMPOSANTS Une Connection peut être de deux sortes : AssemblyConnection ou DelegationConnection Connexion Assemblage L assemblage correspond à AssemblyConnection. La connexion est effectuée entre deux ConnectableFeature de même sorte (deux ConnectableInterface, deux PrimitivePort, deux CompositePort) dans une architecture donnée (i.e. même niveau de composition hiérarchique). ConnectableInterfaceConnection. Une ConnectableInterfaceConnection est un assemblage entre deux ConnectableInterface PrimitivePortConnection. Une PrimitivePortConnection est un assemblage entre deux PrimitivePort. Elle est composée des ConnectableInterfaceConnection A titre de rappel, la connexion est de type pair-à-pair. Une PrimitivePortConnection contient toutes les ConnectableInterfaceConnection correspondantes à chaque ConnectableInterface du PrimitivePort. Exemple simple (sans intersections). La Figure 38 illustre un assemblage entre deux ports primitifs de deux composants et. Dans cet exemple le composant possède un port primitif et le composant possède le port primitif. De plus, la relation suivante est vraie :. Il existe donc avec celles de. La connexion peut alors être effectuée puisque et puisque les cardinalités de et de sont strictement positives. Page 76

77 Figure 38 Assemblage entre deux ports primitifs Exemple (avec des intersections). -après (cf. Figure 39), le composant possède deux ports primitifs et qui partagent la même ConnectableInterface. La ConnectableInterface possède une cardinalité de valeur 4, la ConnectableInterface possède une cardinalité de valeur 2 et la ConnectableInterface possède une cardinalité de valeur 3. La cardinalité du port primitif a donc pour valeur 2 (i.e. ) et celle du port primitif a pour valeur 2 (i.e. ). Le composant possède un port primitif qui est composé des ConnectableInterface et. possède une cardinalité de valeur 2 et possède une cardinalité de valeur 2. La cardinalité du port primitif a donc pour valeur 2. et peuvent être connectés de manière automatique puisque. Figure 39 L entre deux ports primitifs avec des intersections La connexion entre et entraîne la connexion de leurs ConnectableInterface respectives : et sont alors connectées ainsi que et. et se trouvent alors dans un état dit de connexion (i.e. et chaque ConnectableInterface impliquée dans cette connexion est décrémentée de 1. Dans cet exemple, la valeur de la cardinalité de alors de 2 à 1. passe Page 77

78 CompositePortConnection. Une CompositePortConnection est une connexion complexe. Elle est PrimitivePortConnection. Contrairement à une PrimitivePortConnection qui contient toutes les ConnectableInterfaceConnection, une CompositePortConnection ne contient pas PrimitivePortConnection correspondant aux PrimitivePort directs et indirects du CompositePort. En effet, un CompositePort peut être partiellement connecté Connexion de délégation -composants (i.e. entre des plusieurs composants comme le ferait un connecteur. Par exemple des dépendances entre des ports appartenant à des composants différents. La connexion de délégation est un type de connexion particulier et propre à la composition hiérarchique. déléguer le travail de la première à la seconde. entre deux niveaux de composition hiérarchique différents et consécutifs. La plupart des modèles à composants hiérarchiques se limitent à la délégation entre interfaces (i.e. ConnectableInterface dans notre modèle). La délégation doit être sû ines propriétés et contraintes. Nous avons notamment vu devaient être comparés suivant certaines règles de sûreté. Remarque : Dans ce manuscrit n notre travail. Notre métamodèle utilise les concepts de ports primitifs et composites. Nous proposons des règles de délégation dédiées aux ports. Nous introduisons la délégation, que nous appelons multiple, c'est-à-dire et non pas simplement la ConnectableInterface vers une ConnectableInterface. Dans la suite de cette section, nous nous contenterons de décrire de manière informelle certains cas de délégation (la formalisation faisant partie des perspectives de ce travail de thèse). vers un autre ensemble de ports repose sur le fait que les contraintes imposées par peuvent être soit les mêmes soit plus fortes que celles imposées par Délégation élémentaire ConnectableInterface ConnectableInterface. La délégation entre deux ConnectableInterface constitue la délégation classiquement utilisée dans la plupart des approches à composants qui possèdent un modèle de composition hiérarchique. Exemple. La Figure 40 illustre cela. La partie gauche de cette figure illustre la délégation entre deux ConnectableInterface requises : la ConnectableInterface requise du composant est déléguée vers la ConnectableInterface requise du composant composite. La partie droite de cette figure illustre la Page 78

79 délégation entre deux ConnectableInterface fournies. La ConnectableInterface fournie composite est déléguée vers la ConnectableInterface fournie du composant. du composant Figure 40 Exemple de délégation entre deux ConnectableInterface PrimitivePort PrimitivePort. La délégation entre deux ports primitifs se ramène à une délégation entre ConnectableInterface : pour chaque ConnectableInterface du premier port on détermine une ConnectableInterface compatible au sens de la délégation (même PortType effectue la connexion entre ces deux ConnectableInterface. Figure 41 Délégation entre deux ports primitifs Exemple. La Figure 41 illustre ce cas Délégation complexe Ensemble de PrimitivePort PrimitivePort. La délégation entre un ensemble de ports primitifs et un unique port primitif est effectuée en déléguant les ConnectableInterface des deux ports primitifs vers celles du port primitif du composant composite. Exemple. La Figure 42 illustre cela. Il est intéressant de remarquer que le port primitif du composant exprime une dépendance intra-composant sur les interfaces et. De même le port primitif du composant exprime une dépendance intra-composant sur les interfaces et. Le composant -composant sur les ports primitif de et de au travers du port primitif. Page 79

80 Figure 42 CompositePort PrimitivePort. Il est possible de sur-contraindre la contrainte imposée par un port composite en une contrainte relative à un port primitif en utilisant la composition hiérarchique. Le composant composite transforme en fait le port composite en un port primitif. Figure 43 site vers un port primitif Exemple. La Figure 43 illustre cela. Le port composite du composant est envoyé sur le port primitif du composant composite ANALYSE Nous avons présenté, dans cette section, la partie du métamodèle correspondant à la vue composant. Un composant peut être primitif ou composite. Nous avons présenté, de manière informelle, la notion de délégation multiple sûre entre ports, c'est-à- autre ensemble de ports. La sûreté est basée sur le principe que les contraintes imposées par les ports de la boîte noire de plus haut niveau doivent être égales ou plus fortes que celles imposées par les ports correspondant de niveau inférieur. La formalisation de cette relation fait partie de nos perspectives. Page 80

81 3.4 SYSTÈME GLOBAL SYSTEME LOGICIEL Un système logiciel (SoftwareSystem Architecture) et possède un FunctionalObjective). Les objectifs fonctionnels sont étudiés dans la section Définition : [Système logiciel] Un système logiciel est défini comme suit : est une Architecture (cf. section 3.3.1) ) OBJECTIFS FONCTIONNELS lage. De manière concrète, un objectif fonctionnel est un ensemble de scénarii (cf ) pouvoir exécuter. De manière abstraite, un objectif fonctionnel peut être représenté par les ConnectableFeature qui interviennent dans ces scénarii locaux. Le travail présenté dans cette thèse traite en priorité des mécanismes utilisés pour construire des assemblages de composants complets. Pour cela nous prenons comme point de départ les objectifs antage au processus de Dans le cadre de ce travail (dans les algorithmes de construction) nous utilisons le port primitif comme élément de base pour représenter les objectifs fonctionnels. ConnectableInterface puis à des PrimitivePort (ou bien à des compositeport puis à des PrimitivePort). Voici ci-dessous les différents cas qui peuvent se présenter : ConnectableInterface dont le type syntaxique associé possède cette opération. Une ConnectableInterface peut permettre de déterminer un PrimitivePort qui contient cette ConnectableInterface. Un PrimitivePort peut permettre de déterminer un CompositePort exposé qui contient ce PrimitivePort. Page 81

82 On se ramène alors à des PrimitivePort de la manière suivante : A ConnectanleInterface on se ramène à un port primitif exposé qui la contient. o existe pas de port primitif exposé, on se ramène à un port composite exposé qui contient un port primitif qui la contient. sont considérés tous ses ports primitifs directs ou indirects RÉFÉRENTIEL DE COMPOSANTS Nous proposons de définir formellement le concept de référentiel de composants. Nous proposons donc ci-dessous un ensemble de définitions qui seront utilisées lors de la construction automatique (chapitre Définition : [référentiel de composants] soit un référentiel de composants. Opérateur : [ ] trouvant dans un référentiel de composants est obtenu comme suit : Opérateur : [ ] composites exposés issus de tous les composants se trouvant dans un référentiel de composants est obtenu comme suit : Opérateur : [ ] avec un port primitif de est obtenu comme suit :, Opérateur : [ ] paires primitif de est obtenu comme suit :, Notation : [ est noté. ] Propriété : Page 82

83 3.4.4 ANALYSE Nous avons présenté, dans cette section, la partie du métamodèle correspondant à la vue globale du système. et possède fonctionnels. Concept Objectif fonctionnel Qu'est ce? service qui doit être satisfait par l'assemblage de composants Représenté par quoi? un ou plusieurs ports primitifs Figure VALIDITE ET QUASI- LAGE DE COMPOSANTS composants. Nous introduisons la validité comme étant un niveau de vérification évolué basé sur la vérification classique de la correction syntaxique et sémantique (correction classique utilisée dans la plupart des approches à composants), et orientée sur la satisfaction des objectifs fonctionnels (complétude). à cause de problèmes de combinatoire induits par le calcul de la validité et par le processus de construction incrémental. La validité est définie dans cette section. Ces problèmes liés à la combinatoire seront débattus dans le chapitre consacré à la construction automatique (chapitre 5). Pour atteindre cet objectif nous introduisons donc un niveau de vérification intermédiaire que nous appelons le niveau de quasi-validité temps de calcul, la quasi-validité, considérée comme une condition nécessaire à la validité, va permettre assemblages valides de composants. La section présente les deux niveaux de vérification utilisés dans la plupart des approches à composants de composants. La section présente les niveaux de vérification que nous introduisons dans le cadre LES NIVEAUX DE VERIFICATION CLASSIQUES ADAPTES A NOTRE APPROCHE Nous présentons ici les deux niveaux de vérification que nous utilisons et qui sont utilisés dans les plupart des approches à composants. Ils cherchent à contrôler la correction syntaxique et sémantique Page 83

84 , les types syntaxique et sémantique des éléments connectés sont utilisés. Nous détaillons ci-dessous la correction syntaxique, la correction sémantique et nous proposons la propriété de correction Correction syntaxique La correction syntaxique repose sur un contrôle de la compatibilité des types syntaxiques. Elle constitue la vérification minimale A titre de rappel, elle a été étudiée en détail dans le chapitre co Dans notre approche la correction syntaxique consiste à contrôler la compatibilité des ConnectableFeatureType des ConnectableFeature impliquées dans chaque Connection. A titre de rappel un ConnectableFeatureType représente un type syntaxique. Nous rappelons que dans notre métamodèle, un ConnectableFeature peut être spécialisé en ConnectableInterface, PrimitivePort et en CompositePort. connexions simples, c'est-à-dire aux connexions entre deux ConnectableInterface ou entre deux PrimitivePort. Par conséquent, les CompositePortConnection qui sont des connexions complexes ne sont pas considérées lors de la vérification syntaxique. Voici ci-dessous les règles de compatibilité qui sont utilisées lors de la correction syntaxique : Les règles de compatibilité entre ConnectableInterface pour des connexions de type AssemblyConnection ont été présentées dans les sections et Les règles de compatibilité entre ConnectableInterface pour des connexions de type DelegationConnection ont été présentées dans la section Les règles de compatibilité entre PrimitivePort pour des connexions de type AssemblyConnection ont été présentées dans les sections et Les règles de compatibilité entre PrimitivePort pour des connexions de type DelegationConnection ont été présentées dans la section Définition : compatibilité de types syntaxique au niveau des connexions Correction sémantique La correction sémantique repose sur un contrôle de la compatibilité des types sémantiques (comparaison de protocoles de comportement). Elle vise ainsi à contrôler tous les aspects relatifs au comportement. Elle consiste à contrôler, pour chaque Connection de comportement associés à chacun des deux ConnectableFeature impliqués dans la connexion. Remarque : Les On pourra trouver, dans les travaux sur SOFA [29], les informations relatives aux protocoles de comportement. Page 84

85 s en décrivons cependant le principe de la vérification : en ce qui concerne les AssemblyConnection entre deux ConnectableInterface, leurs CommunicationProtocol respectifs sont comparés. Il en est de même pour les DelegationConnection. En ce qui concerne les AssemblyConnection entre deux PrimitivePort, leurs CommunicationProtocol respectifs sont comparés. Il en est de même pour les DelegationConnection. Définition : Un assemblage de composants est sémantiquement correct si les protocoles de traces) Propriété de correction Nous définissons ainsi la correction comme comprenant la correction syntaxique et la correction sémantique. Propriété : correct LES NOUVEAUX NIVEAUX DE VERIFICATION Nous venons de décrire les deux niveaux de vérification classiques que sont la correction syntaxique et la correction sémantique. Ces vérifications sont destinées à contrôler la cohérence du comportement de : la validité, la quasi-validité et la complétude. Ils se basent tous les trois sur la méta-information concernant les Validité devait avoir un comportement correct au niveau assemblage doit aussi garantir que tous ses objectifs fonctionnels vont être supportés. a correction syntaxique peut en fait être assimilée à la vérification de typage effectuée par un compilateur «classique». La correction sémantique peut être vue comme une couche supplémentaire permettant de détecter des erreurs comportementales. La correction syntaxique consiste à déceler statiquement des erreurs de type syntaxique. A titre de rappel, une erreur de typage est identifiée par la signalisation «message inconnu s assure une sûreté du typage au niveau de la redéfinition des méthodes (covariant sur le type de retour et contravariant sur les types des paramètres). Il est important de signaler que la vérification est effectuée au design-time et que certaines erreurs de types ne pourront être détectées que lors de Page 85

86 cast dynamiques ou encore les références nulles ne pourront pas être détectés lors de la compilation. De manière informelle, la validité artant des objectifs fonctionnels doivent être suffisantes e par une connexion) peut nécessiter autres fonctionnalités c De telles fonctionnalités (ou interfaces) sont dites dépendantes. Cette information est enfouie dans la description du comportement du composant. Avant de proposer une définition de la validité, voici ci-dessous un ensemble de définitions : Définition : messages reçus et émis par le composant et les composants de son environnement. Exemple : Client est montré sur la Figure 45. Nous -après. Définition : Nous appelons scénario local un scénario aux appels entrants et sortants du composant. Exemple : Un scénario local du composant Client est montré sur la Figure 45. Remarque : Le ComponentProtocol du composant. Remarque : Le CollaborationProtocol Port s scénarii locaux issus du port. Remarque : Le CommunicationProtocol ConnectableInterface scénarii locaux issus de cette ConnectableInterace. Important : A titre de rappel, un objectif fonctionnel est caractérisé par un ensemble de scénarii locaux e composants par rapport à un objectif fonctionnel doit s à cet objectif fonctionnel pourront bien être «joués». Définition : Un assemblage de composants est dit valide par rapport à un objectif fonctionnel si pour rencontrer de référence nulle. Page 86

87 Métaphore du puzzle. La notion de validité s appellent la fonctionnels. Il est important de bien comprendre cette notion pour la suite de ce manuscrit. Dans un souci de clarté un exemple simple et intuitif est déc aussi utilisé dans [103], est puzzle sont. Reprenons par un souhaite réaliser. Pour atteindre cet objectif, sont mises à notre disposition un ensemble de pièces de puzzle. La construction du puzzle est effectuée en assemblant des pièces compatibles en essayant : le motif. Le puzzle est alors complet lorsque le motif est atteint. Les fentes non connectées et les bouts ronds non connectés n ont important de remarquer que chercher à tout connecter entraîne une sur-contrainte. En considérant sur les pièces sont une métaphore des protocoles. Exemple avec les composants. La Figure 45 illustre une partie de la validité. Dans cet exemple, le système possède un objectif fonctionnel représenté par un scénario local composant Client (i.e.!client.[dialogue].connect;!client.[dialogue].withdrawal;!client.[dialogue].disconnect;) et un assemblage de composants formé des composants Client, MemberBank, LocalDataBase, ATM, CentralBank et DataWarehouse. Figure 45 : Exemple de validité Dans ce scénario local apparaît la ConnectableInterface Dialogue qui constitue la Page 87

88 décrit sur la Figure 45. Celui- exécuter sans rencontrer de référence nulle (i.e. pas ). Analyse. Nous venons de présenter une définition de la validité. Nous introduisons ci-après les concepts de complétude ainsi que de quasi-validité qui vont permettre de définir une propriété de validité (section ) pouvant être vérifiée de façon automatique Complétude Nous introduisons ici le concept de complétude qui constitue une condition nécessaire à la validité. Nous verrons dans la section Voici cidessous la définition de la complétude. Définition : Un assemblage de composants est complet par rapport à un FunctionalObjective les connexions suffisantes à fonctionnel. Exemple : La Figure 45 ne connectant que les interfaces strictement nécessaires. La ConnectableInterface Dialogue du composant Client représente, de manière abstraite, un objectif fonctionnel et doit donc être connectée. Toutes les ConnectableInterface dépendantes (grisées sur la Figure 45) déduites à partir de complétude. Par exemple, la ConnectableInterface Control du composant MemberBank doit être connectée alors la ConnectableInterface Question du composant Client Définition : complétude sont réalisées (pas de connexions en trop) Quasi-validité Le niveau de quasi-validité est basé sur la détection de la complétude à partir des propriétés des ports et notamment celles relatives à la cohérence des ports composites. de la quasi-validité est que le raisonnement porte sur les aspects structurels et que son calcul va pouvoir être effectué dans un temps optimal. une condition nécessaire à la validi en procédant par un pré-calcul d quasi-valides (voir chapitre 5). Remarque : A titre de rappel dans le cadre de ce travail (dans les algorithmes de construction) nous utilisons le port primitif comme élément de base pour représenter les objectifs fonctionnels. Définition : Un assemblage de composants est quasi-valide par rapport à un objectif fonctionnel si tous emblage sont cohérents et si tous les ports primitifs qui représente fonctionnel sont connectés. Un composant est dit cohérent si tous ses ports composites exposés sont cohérents. Page 88

89 Figure 46 : Exemple de quasi-validité Exemple avec les composants. proposé sur la Figure 46 représente un système bancaire. Celui- au nombre de six : et. du composant. Cet assemblage est quasi-valide objectif fonctionnel. En effet, dans cet exemple, tous les composants sont localement cohérents, et le port est connecté. Par exemple, le composant est localement cohérent puisque son port composite e par la couleur bleu). Le port composite du composant est cohérent puisque ses deux ports primitifs et sont tous les deux connectés. Il est important de suffisant pour atteindre la quasi-validité a connexion entre le port primitif du composant Client et le port primitif du composant impose la connexion du port primitf du composant. Par ailleurs, nécessaire de connecter tous les ports primitifs pour atteindre la quasi-validité du système. I nécessaire de connecter le port primitif du composant pour atteindre la quasi-validité. Il est également intéressan est strictement complet Propriété de validité et de quasi-validité Nous présentons ci-dessous les trois propriétés fondamentales : Propriété : Si un assemblage de composants A est quasi-valide par rapport à un objectif fonctionnel FO alors il est complet par rapport à FO : Page 89

90 3.2 et 3.3, les ports expriment des dépendances de connexion entre des ConnectableInterface composant. La notion de connexion pair-à-pair est exprimée par le PrimitivePort, la notion de pair-à-pair complexe est exprimée par le CompositePort des alternatives est exprimée par les intersections de CompositePort. Propriété : Un assemblage de composants A est valide par rapport à un objectif fonctionnel FO ssi il est correct et complet par rapport à FO. Propriété : La quasi-validité est une condition nécessaire à la validité. Si un assemblage de composants A est valide par rapport à un objectif fonctionnel FO alors il est quasi-valide par rapport à FO : ANALYSE composants. des connexions d Notre approche considère les objectifs fonctionnels comme étant le centre névralgique de la vérification. La Figure 47 constitue un récapitulatif des définitions de ces niveaux. Nous avons introduit la validité comme un niveau de vérification étendant les niveaux de vérifications classiques en y intégrant la vérification du respect des objectifs fonctionnels du système. Correct Complet Quasi-valide Valide Compatibilité syntaxique et sémantique des connexions Connexions suffisantes pour satisfaire les objectifs fonctionels Cohérence des composants de l'assemblage (i.e. cohérence de tous les ports composites) partant des objectifs fonctionnels pourront Figure 47 : Bilan concernant la correction, la complétude et la quasi-validité connexions suffisantes à la satisfaction des objectifs fonctionnels). La Figure 48 illustre cette propriété. Page 90

91 Complet Correct Valide Figure 48 : Bilan concernant la propriété de validité Nous avons introduit une propriété de quasi- assemblage de composants en se basant uniquement sur la cohérence des ports composites de plus haut niveau. La quasi-validité permet de résoudre le problème de de manière locale à chaque composant niveau. La Figure 49 illustre cette propriété. Quasivalide Complet Figure 49 : Bilan concernant la propriété de quasi-validité 3.6 DISCUSSION les concepts nécessaires à la construction automatique assemblages de composants satisfaisant des objectifs fonctionnels. Un métamodèle a été présenté suivant que le calcul de la complétude en utilisant les concepts actuels pour construire des assemblages complets de composants Pour atteindre cet objectif nous avons proposé une propriété de quasi-validité basée sur les ports (éléments structurels) qui permet de la calculer en analysant la cohérence des ports composites exposés tage est que le calcul est peu coûteux en temps de calcul. Malgré cela, nous verrons que le problème de la construction reste difficile. Notre objectif global est de construire des assemblages valides. Pour cela nous nous basons sur le fait que la complétude constitue une condition nécessaire à la validité. Nous allons exploiter cette propriété pour construire des assemblages valides. Notre approche consiste à construire des assemblages quasi- chaque assemblage pré-calculé. Pour conclure schématiquement, les contributions de ce chapitre sont les suivantes : Métamodèle : Partie externe Les ports composites Les propriétés exposées La direction étendue aux ports Page 91

92 Métamodèle : Partie interne Délégation multiple entre ports Métamodèle : Système global Objectifs fonctionnels Vérifications Validité Complétude Quasi-validité Page 92

93 Page 93

94 4 CONSTRUCTION AUTOMATIQUE VALIDES 4.1 INTRODUCTION de ce chapitre est de proposer des algorithmes complets (i.e. effectuant une recherche comp qui, fonctionnels, permettent la construction automatique assemblages quasi-valides (nous avons présenté une partie de ce travail dans [98]). Un deuxième objectif consiste à tous les assemblages quasi-valides de taille minimale. assemblages valides est un problème difficile. En effet, construire un assemblage valide revient à construire un assemblage syntaxiquement correct, sémantiquement correct et complet par rapport aux objectifs fonctionnels. Notre approche consiste à construire dans un premier temps des assemblages quasi-valides. Nous assemblage pré-calculé. Le processus de construction assemblages quasi-valides, que nous présentons ici, reste cependant un problème difficile. Le chapitre est organisé comme suit. La section 4.2 constitue une introduction aux différents problèmes assemblages valides. Elle pose notamment les bases des problèmes de construction et en fait ressortir les problèmes de combinatoire. Pour cela, un algorithme «naïf» de construction est esquissé. La section 4.3 vise à montrer que le problème de la rech -valide est NP-Complet. Cette preuve est réalisée en utilisant la réduction polynomiale de 3-SAT vers notre problème. 4.4 est ensuite de proposer des algorithmes effectuant une exploration ace de recherche. Une modélisation de la assemblages quasi-valides en CSP (4.4.1) (nous avons présenté une partie de ce travail dans [94]). Nous présentons un algorithme de construction de tous les assemblages quasi-valides dans la section Cet e présenté dans la section dont le but est de calculer tous les assemblages quasi-valides de taille minimale. Ce dernier utilise des stratégies, des heuristiques et des méta- exploration «intelligente La section 4.5 constitue une discussion concernant ce chapitre. 4.2 DESCRIPTION DU PROBLEME Afin de clarifier les bases de notre travail, le contexte, les hypothèses et les objectifs à atteindre sont détaillés dans la section Nous y exposons notamment trois problèmes à résoudre. Un algorithme naïf de construction est ensuite proposé dans la section afin de mettre en évidence la difficulté de résolution de tels problèmes. Cet algorithme, de type bottom-up, assemblages valides. Page 94

95 4.2.1 CONTEXTE, HYPOTHESES, OBJECTIFS assemblages sont les suivantes : un référentiel de composants et u ports primitifs initiaux. assemblages relève de trois problèmes. Ces problèmes sont énoncés suivant une complexité croissante : (problème 1) construire au moins un assemblage valide. (problème 2) construire tous les assemblages valides. (problème 3) construire tous les assemblages valides de taille minimale. Cela revient à construire tous les assemblages strictement valides de taille minimale. En effet, les assemblages valides de taille minimale sont forcément strictement valides. Le processus général de construction utilisé est de type bottom-up (voir section 2.3). La construction assemblage est réalisée de manière incrémentale uniquement piloté par les règles de validité syntaxique et de complétude au regard des objectifs fonctionnels ALGORITHME NAÏF algorithme naïf de construction permettant de trouver tous les assemblages valides afin de mettre en évidence les différents problèmes de combinatoire induits par un processus de construction in plaçons-nous dans un contexte où les composants ne disposent pas des ports. Un composant est alors décrit par des ConnectableInterface et un ComponentProtocol. Les objectifs fonctionnels sont identifiés par un ensemble de ConnectableInterface. Un algorithme naïf permettant de trouver toutes les contiennent les objectifs fonctionnels sont sélectionnés et dans une seconde étape toutes les possibilités de construction sont testées. A chaque étape du processus incrémental, sont considérés tous les composants candidats ainsi que toutes les connexions possibles. Un contrôle de la validité est alors effectué. Les trois problèmes rencontrés lors de cette construction sont les suivants : (1) Calcul de la correction (2) Calcul de la complétude (3) Choix des composants et des connexions VERS UN ALGORITHME DE CONSTRUCTION OPTIMISE Un algorithme naïf ne peut pas être utilisé directement pour construire des assemblages valides. Des optimisations doivent être envisagées. Ces optimisations peuvent intervenir à trois niveaux : calcul de la correction, calcul de la complétude et choix de construction. Nous proposons, dans les sections , Page 95

96 et r chacun de ces trois niveaux de la manière suivante : rappeler la stratégie de algorithme naïf et proposer un ensemble de stratégies Le problème de la correction Le calcul de la correction constitue le plus important problème lors du processus de construction assemblages valides. Nous avons mis en évidence da que contrôler la correction sur un assemblage déjà constitué était déjà. Nous présentons ci-dessous la stratégie. Algorithme naïf. algorithme naïf procède par un calcul de la correction à chaque itération du processus de construction. Optimisation. Le calcul de la correction se décompose en deux parties : le calcul de la correction syntaxique et le calcul de la correction sémantique (section ). Lors de la vérification syntaxique, les types et les cardinalités des points de connexions impliqués dans une connexion sont vérifiés. La correction sémantique consiste à contrôler la cohérence messages. Nous avons introduit, dans la section , une propriété permettant de déterminer la e celui-ci. Une idée est de considérer la complétude comme une condition nécessaire à la validité. La construction assemblages valides peut ainsi être réalisée en deux étapes bien distinctes : 1. Calculer des assemblages complets 2. Vérifier la correction pour chaque assemblage calculé assemblage candidat mais uniquement sur des assemblages complets. Notre contribution se situe à Nous utilisons la propriété de quasivalidité pour déterminer la complétude (section ). Pour 2, nous utilisons les algorithmes classiques proposés le travail de SOFA Les problèmes liés à la complétude Les problèmes liés à la complétude peuvent se résumer en locale à un composant,. Quelles interfaces faut-il connecter (locale au composant)? Quand sait-on que l assemblage est atteinte (global )? Nous présentons ci- analyse des protocoles de comportement. Nous proposons enfin une seconde basée sur la propriété de quasi-validité. Page 96

97 Algorithme Naïf. Une solution naïve consiste à construire un assemblage complet de manière implicite en connectant toutes les interfaces. L cette stratégie élimine la problématique liée à la première question. Mais sur-contraindre la complétude conduit souvent le processus de construction te manière, il est impossible de trouver toutes les solutions, en particulier des assemblages de taille minimale. Optimisation 1. cherche à connecter uniquement les interfaces strictement nécessaires pour atteindre la complétude. Le calcul des interfaces qui doivent être connectées ainsi que est effectuée de manière incrémentale permettre de faire ressortir des dépendances (i.e. dépendances intra-composant). Une exprime être connectées conjointement pour assurer un fonctionnement correct. que seules les interfaces qui doivent être connectées pour atteindre la complétude le sont. Un inconvénient majeur est que le calcul des dépendances est réalisé Optimisation 2. Nous avons introduit, dans la section , une propriété de quasi-validité sur les ports et notamment sur la cohérence des ports composites exposés. Les ports primitifs et composites sont des éléments structurels qui permettent de construire des assemblages quasi-valides grâce aux dépendances intra- (i.e. dépendances entre les ConnectableInterface ). Les avantages sont les suivants : les ports sont des propriétés structurelles des composants qui représentent de manière statique les dépendances existant entre leurs différentes interfaces. Les ports permettent d structurelle, la quasi Le problème lié au choix des composants et des connexions Les possibilités de connexions entre interfaces peuvent être importantes et les ports en tant s structurels permettent de réduire cette combinatoire. Les ports sont des éléments connectables de notre modèle. Un port regroupe au n et impose une sémantique de connexion sur ces interfaces : le port primitif représente une connexion pairà-pair et le port composite permet de gérer des connexions multi-tiers. Dans tous les cas, les ports cohérentes de certaines interfaces composant. Ceci réduit la combinatoire liée aux connexions BILAN assemblages valides ainsi que des optimisation. Nous résumons ci- pallier (en partie) aux trois problèmes de combinatoire énoncés dans la section Page 97

98 Stratégie la correction : calculer dans un premier temps des assemblages complets. Contrôler ensuite la correction de ces assemblages pré-calculés. la complétude : utiliser la propriété de quasi-validité (utilisant les ports comme éléments structurels pour expliciter les dépendances entre interfaces). les choix de construction : utiliser les ports pour réduire les possibilités de connexions. Malgré ces stratégies, le calcul des assemblages valides reste un problème difficile. En effet, nous allons montrer, dans la suite de ce chapitre, assemblages quasi-valides est oire. 4.3 CONSTRUIRE UN ASSEMBLAGE QUASI-VALIDE : UN PROBLEME NP-COMPLET Cette section vise à démontrer que -valide est NP-complet. Cette preuve est réalisée en utilisant la réduction polynomiale, une technique utilisée en complexité algorithmique, du problème 3-SAT vers notre problème. Le domaine de la complexité algorithmique distingue plusieurs catégories de problèmes. Nous en énumérons les trois principales : les problèmes de décision, les problèmes de comptage et les problèmes la réponse est soit oui, soit non. Par exemple, étant donné un graphe, existe-il un cycle Hamiltonien dans? Un problème de comptage est un problème la réponse est une valeur en rapport avec le comptage riété. Par exemple, étant donné un graphe, quel est le nombre de cycles Hamiltonien dans? objectif. Par exemple, étant donné un graphe, exhiber le cycle Hamiltonien de poids minimum dans. Un problème de décision peut être associé à le problème de décision est NP-Complet (resp. NP-Difficile) pour montrer que le problème -Complet (resp. NP-Difficile). -valide ptimisation. Notre démarche pour prouver la NP-complétude de ce problème est classique [111] : (1) (2) Prouver que est NP-Complet o Déterminer un problème de décision associé à o Prouver que est NP-Complet Montrer que est dans NP Choisir un problème dans la classe des problèmes NP-Complet Effectuer la réduction vers Page 98

99 4.3.1 FORMULATION DU PROBL Cette section est consacrée à Notre objectif est de déterminer une formulation du problème qui facili L principale re de données que nous appelons le graphe de compatibilité. Le graphe de compatibilité est construit à partir des ports primitifs et de leur relation de compatibilité Le graphe de compatibilité. Le graphe de compatibilité les connexions potentielles entre tous les ports primitifs du référentiel de composants. Le concept de référentiel de composants a été formalisé dans la section Chaque sommet du graphe de compatibilité représente ainsi un port primitif et chaque arête représente un lien de compatibilité entre deux ports primitifs. Voici ci-dessous la définition formelle du graphe de compatibilité associé à un référentiel de composants. Définition : [ ] Soit un référentiel de composants. On définit le graphe de compatibilité construit à partir de tel que arêtes. et sont obtenus comme suit : Remarque : et ont été définis dans la section A titre de rappel, trouvant dans le référentiel de composants. retourne paires (port primitif, de. Enoncé du problème ( ). La preuve va être effectuée en considérant que les cardinalités associées aux ports primitifs sont toutes égales à 1. (Pour simplifier la démonstration. La même idée de preuve peut être appliquée au cas général en dupliquant les sommets et leurs arêtes en fonction des cardinalités). Propriété : La quasi-valide consiste à construire un couplage dans, tel que tout port composite exposé soit cohérent représentant un objectif fonctionnel, une arête issue de celui-ci qui fasse partie du couplage PREUVE Enoncé du problème de décision. Le problème de décision que nous associons à est alors le suivant : Page 99

100 Propriété : Existe-il un couplage dans, tel que tout port composite exposé soit cohérent, et tel arête issue de celui-ci qui fasse partie du couplage? Montrer que est dans NP. Pour montrer est possible de vérifier une solution potentielle en temps polynomial dans la taille de la donnée. Cette preuve est appelé certificat. Dans notre problème, une solution potentielle est la donnée un couplage dans. Il peut être vérifié en temps polynomial que tout port composite exposé est cohérent et que pour tout sommet représentant un objectif fonctionnel, une arête issue de celui-ci fait partie de. Réduction de 3-SAT vers. Nous venons de montrer que est dans NP. Il faut maintenant choisir un problème NP-Complet et le réduire à notre problème. Il est connu que le problème 3-SAT est NP-Complet. Il faut alors iste une réduction polynomiale de 3-SAT vers de toute instance de 3-SAT en une instance de telle que et telle que si (resp. ) alors 3-SAT (resp. ). Le problème 3- normale conjonctive comportant exactement trois littéraux par clause. Un littéral est soit une variable, :. peut représenter la variable ou bien sa négation. On note suit : (i.e. ou, et, non). - Instance de 3-SAT. Une instance de 3-SAT est une formule où les littéraux obtenus à partir de l. On note des clauses.. - Instance de. Une instance de est constituée par trois éléments : sont des o un graphe de compatibilité,, o un ensemble de ports composites,, correspondant aux ports composites exposés des composants du référentiel, o un ensemble de ports représentant les objectifs fonctionnels,. - Transformation polynomiale. A une instance quelconque de 3-SAT on construit une instance de comme suit : o et de leur négation. Ainsi, pour, on introduit 3 sommets dans le graphe de compatibilité. Le premier,, représente. Le deuxième,, représente. Le troisième, est un sommet pour les relier. Ces sommets sont reliés entre eux via 2 arêtes, (, ) et (, ). Page 100

101 Figure 50 La transformation des littéraux de 3-SAT en graphe La Figure 50 que un couplage dans ce graphe, choisir arête (, ) (, ) revient à choisir une valeur vrai ou faux pour. On considère les fonctions suivantes : (i.e. ensemble des sommets construit à partir de ).. (i.e. ensemble des arêtes construit à partir de ) o Chaque clause donne deux sommets ( et ) supplémentaires dans le graphe de compatibilité arête. La clause donne trois ports composites (exposés) placés comme suit : Le premier,, contient et le sommet correspondant au littéral. Le deuxième,, contient et le sommet correspondant au littéral. Le troisième,, contient et le sommet correspondant au littéral. «ou» de chaque clause en termes de partages de ports composites. est ajouté à la liste des objectifs fonctionnels. On considère les quatre fonctions suivantes. partir de ) construit à partir de ) (i.e. ensemble des sommets construit à partir de ). (i.e. ensemble des arêtes construit à partir de ).(i.e. ensemble des ports composites construit à. (i.e. Figure 51 -SAT en graphe Page 101

102 En résumé de 3-SAT en une instance de est effectuée comme suit : Le graphe de compatibilité est construit tel que : comme suit : comme suit : La transformation est effectuée en temps polynomial. En effet, la construction du graphe de compatibilité demande pour la construction des sommets et des arêtes. La construction des ports composites peut être effectuée en fonctionnels peut être construit en. La transformation permet alors :. Le problème est donc NP-Complet. On peut en conclure que le problème est NP-Complet. Exemple. Un exemple de transformation est illustré sur la Figure 52. Dans cet exemple, soit la formule Soit l. Notons les trois clauses comme suit :, et Les sommets et les arêtes construits à partir des variables sont les suivants : est : {. est :. est : {. est :. Page 102

103 est : {. est :. Les sommets, les arêtes, les ports composites et les objectifs fonctionnels construits à partir des clauses sont les suivants : est : {. est est est. est : {. est est est. est : {. ble des arêtes contruit à partir de est est est. Figure 52 Un exemple de transformation de 3-SAT vers une instance de notre problème Page 103

104 Le couplage correspond à un assemblage quasivalide.. donc.. Nous rappelons que donc 4.4 ALGORITHMES DE CONST S QUASI-VALIDES MODELISATION CSP - décrit par un ensemble de variables, un ensemble de domaines de valeurs (un domaine par variable) et un ensemble de contraintes [113, 112] affecter une valeur à chaque variable tout en respectant certaines contraintes destinées à garantir la correspondant. Nous avons proposé, dans la section , une règle de cohérence aux ports composites exposés. Dans cette section, nous utilisons une modélisation différente pour exprimer les comme CSP. Pour un port primitif partagé par n ports composites exposés, il y aura ici n variables représentant ce port primitif, une dans chaque contexte. Ces n variables représentent le même port primitif. Ainsi, dans cette modélisation, la connexion de à un autre port primitif compatible implique que les n variables prennent chacune la valeur. Les rôles sont gér Exemple. Nous commençons par introduire un exemple qui servira à illustrer le principe de modélisation utilisé. Nous définissons ensuite les données du problème, les variables, les domaines de valeur et enfin les contraintes. Dans cet exemple, nous considérerons que tous les ports composites sont exposés. Figure 53 : Exemple illustrant les concepts introduits dans le CSP Page 104

105 Données du problème. Les données : Un référentiel de composants. FunctionalObjective). Définitions et notations. Nous introduisons ci-dessous un ensemble de définitions et de notations destinées à la formalisation du problème. Notation[ ] : On notera :.. En Notation[ ] : On notera objectifs fonctionnels. Rappel[ ] : Exemple. Sur la Figure 53,. En effet, le port primitif composite exposé. En revanche,. En effet, le port primitif est partagé par les deux ports composites exposés et. Définition [ ] : Soit. On définit comme primitifs dans qui sont compatibles avec. Variables. L du CSP est obtenu à partir de. Une variable est associée à chaque port primitif. Dans le cas où le port primitif est partagé par plusieurs ports composites exposés (i.e. cas érents), un ensemble de variables lui est associé, une par contexte. Définition : Soit connexions potentielles. Chaque variable permet Exemple. Figure 53, une seule variable est associée au port primitif variable. Par contre, deux variables sont associées au port primitif : les variables et. : la Définition : Soit connexions entre tous les composants du référentiel de composants.. Domaines. Le domaine de chaque variable est le suivant :. Une variable qui représente un port primitif donné peut ainsi prendre pour Page 105

106 valeur le port primitif auquel il est connecté ou bien nil si le port primitif représenté par la variable pas connecté. Contraintes. uivant : 1. Contraintes sur les objectifs fonctionnels. Tout port primitif sélectionné comme objectif fonctionnel doit être connecté. Donc il doit exister une variable, représentant la connexion de ce port, ayant une valeur non nulle. 2. Contraintes concernant la symétrie de la connexion de ports primitifs. primitif est connecté à un autre port primitif, alors ce dernier est réciproquement connecté te une connexion, alors une autre variable représente la connexion réciproque. Exemple. Figure 53, les ports primitifs et sont connectés ensemble. Cela se traduit par les affectations de variables suivantes : et. 3. Contraintes sur la cohérence des ports composites exposés. Pour être cohérent, un port composite doit être soit entièrement connecté, soit entièrement déconnecté. Les ports composites exposés doivent être cohérents. On associe donc une contrainte à chaque port composite exposé. Les variables qui correspondent aux connexions des port composite exposé doivent soit être toutes nulles, soit toutes non nulles. Exemple. En re Figure 53, les contraintes imposées par les ports composites exposés sont définies sous la figure. Par exemple, le port composite impose la contrainte suivante : 4. Contraintes de cohérence de connexion des ports primitifs partagés. Un port primitif toutes les variables représentant un même port primitif doivent avoir la même valeur. Exemple. Figure 53, cette contrainte peut être illustrée en considérant le port composite... Page 106

107 4.4.2 TOUS LES ASSEMBLAGES QUASI-VALIDES : La construction de tous les assemblages quasi-valides consiste à construire tous les couplages. NP-Difficile. dans Le but de cette section est de présenter un algorithme de construction de tous les assemblages quasivalides :. construit tous les assemblages quasi-valides étant donné un référentiel de composants de ports primitifs. Cet algorithme effectue un parcours complet Il servira de base à un algorithme optimisé présenté dans la section est un algorithme récursif. les suivantes : : le graphe de compatibilité,, de chaque port primitif s ports primitifs compatibles avec ) est pré-calculé à partir de. par le référentiel de composants. Nous avons montré dans [95, 96] comment un tel référentiel pouvait être construit par classification : un ensemble de contraintes à satisfaire. Les contraintes sont concrètement des ports primitifs qui doivent être connectés. contient uniquement des ports primitifs. : l assemblages solutions (i.e. les assemblages quasi-valides). est le suivant : tous les assemblages quasi-valides Voici ci-dessous la liste des fonctions et prédicats que. Fonctions. : cette fonction réalise la connexion entre les deux ports primitifs et. Lors de la connexion les cardinalités et sont chacune décrémentées de 1. : cette fonction réalise la déconnexion entre deux ports primitifs et. Lors de la déconnexion les cardinalités et sont chacune incrémentées de 1., compatibles avec le port primitif, de cardinalité courante strictement positive. : retourne la cardinalité courante du port primitif. : retourne composites exposés qui partagent le port primitif (i.e. ). Page 107

108 Prédicats. : retourne vrai si le port primitif est connecté (i.e. si ), retourne faux sinon (i.e. si, il suffit que le port primitif possède au moins une connexion avec un autre port primitif pour que retourne vrai. : retourne vrai si tous les ports primitifs directs et indirects du port composite sont connectés (i.e. si, est vrai pour chaque port primitif direct et indirect de ). est présenté sur la Figure 54. Initialisation. : contient les ports primitifs qui représentent les objectifs fonctionnels. voisins de dans le graphe de compatibilité.. Le domaine de chaque port primitif correspond aux assemblage en cours de construction est un assemblage vide. assemblages solutions est vide au départ. Une solution est trouvée lorsque est vide. En effet, dans ce cas, cela signifie que toutes les contraintes de connexion ont été satisfaites. Tous les ports primitifs qui devaient être connectés pour atteindre la quasi-validité le sont. Si doivent être réalisées. Etape 1 dans. Un des ports primitifs de est sélectionné puis extrait. Par défaut, le premier élément de est extrait. Dans la suite de cette description, représente cet élement. Etape 2 compatible avec. Un port primitif est recherché dans le domaine de. Les ports primitifs potentiellement compatibles avec sont donc des ports primitifs un composant du référentiel assemblage en cours de construction. Une itération est réalisée à la ligne 4 pour tester toutes les solutions de construction. Dans la suite de cette description, représente un élément compatible avec. Page 108

109 Etape 3 : connexion entre et. Figure 54 Etape 4 : Traitement des dépendances (ports composites) induites par la connexion entre et. Deux cas doivent être considérés : Le cas particulier où se trouve dans : dans ce cas, les dépendances ne doivent pas être rajoutées à. En effet, et les ports dont il dépend ont été ajoutés ensemble à (ligne 9). Les dépendances de sont déjà dans. (voir section ). Dans ce cas en paramètre. Le cas où ne se trouve pas dans : les dépendances induites par la connexion entre et sont récupérées dans. Ces dépendances sont les ports composites exposés auxquels appartient. Si se trouve contenu dans un seul port composite exposé (i.e. ) alors un appel récursif est effectué en passant en paramètre une copie de à laquelle sont ajoutés tous les autres ports primitifs directs et indirects de dont la cardinalité courante est strictement positive (c'est-à-dire ). Page 109

110 Si se trouve partagé par plusieurs ports composites exposés, une itération est réalisée sur cet ensemble ( ). Le traitement de chaque port composite de est effectué comme pour le cas précédent. Ceci est réalisé entre les lignes Etape 5 : déconnexion entre et. Lorsque connexion entre et est terminée, la déconnexion entre et est réalisée. Ceci est fait à la ligne 17 permet de poursuivre la recherche de nouveaux assemblages en ayant une connexion entre et un autre port compatible Invariants et propriétés -dessous. Certaines de ces propriétés seront utilisées dans certaines heuristiques de la section Propriété : est quasi-valide ssi est vide. Invariant : Tout élément de positive. est un port primitif dont la cardinalité courante est strictement Propriété : Pour tout élément de, il existe un port composite partiellement connecté et incohérent tel que est contenu dans et tel que tout port primitif direct ou indirect de (différent de ) qui se trouve dans un état non connecté se trouve aussi dans. De manière formelle, cela signifie que : En effet, un ensemble de ports primitifs est placé dans au moment du traitement des dépendances induites par la connexion entre deux ports primitifs. C dans la section ASSEMBLAGES DE TAILLE MINIMALE : assemblages quasi-valides repose sur un algorithme du type. Mais la assemblage est valide dépend du nombre de connexions de assemblage. Ainsi, la minimalité en termes de nombre de connexions dans un assemblage est un cr crucial (section 2.3.5). Aussi, une amélioration de notre stratégie de recherche consiste à construire tous les assemblages quasi-valides de taille minimale (section 4.4.3). Des stratégies et heuristiques sont également proposées le temps de calcul. N combinatoire. Dans ce domaine, il est courant de distinguer les politiques de construction des Page 110

111 se décompose en deux grandes parties : la section est dédiée aux stratégies de construction et la section est consacrée aux heuristiques Stratégie de construction Les stratégies de construction identifient les objectifs finaux à atteindre. Dans notre problématique, les stratégies présentées ci-dessous se focalisent sur la recherche de tous les assemblages de taille minimale. Branch-and-bound (BB) [114]. solutions et plus précisément minimalité en termes d dans la section Le principe du BB est relativement simple. I assemblages quasi-valides de taille mi s les assemblages construits auront plus de connexions que les assemblages solutions courant assemblage partiellement assemblage en cours de construction est strictement supérieur au assemblage minimal est présentée sur la Figure 55. Un paramètre supplémentaire a été rajouté à la fonction principale de construction : ce paramètre,, correspond au nombre de connexions assemblage représente est vide une solution est trouvée. Il faut alors comparer avec qui est la valeur du nombre minimal de connexions des assemblages solutions trouvés Cette comparaison est effectuée à la ligne 4. et sont mis à jour (lignes assemblage en cours de construction constitue une solution dont le nombre de connexions est inférieur à. Page 111

112 Figure 55 Look-ahead (LA) [115]. La stratégie LOOK-AHEAD est une optimisation de BB. Une estimation peut être assemblage en cours de construction peut ou non aboutir à un assemblage solution c'est-à-dire à un assemblage de taille minimale de la borne du BB en réalisant une estimation du nombre de connexions supplémentaires nécessaires à la construction. Page 112

113 Notation : [ ] Nous notons comme étant la borne inférieure du nombre de Notation : [ ] Nous notons comme étant une estimation de telle que. On utilise pour i assemblage quand : Toute la difficulté réside dans le calcul de la valeur de. Celle-ci doit être le plus proche possible de, pour stopper dès que possible une construction inutile. Mais il faut garantir que afin de ne pas éliminer, à priori, des solutions potentielles. Les deux versions de LOOK-AHEAD présentées ci-dessous proposent différents calculs de la valeur de. La première version est la plus simple tout en étant efficace. La deuxième est une optimisation de la première et Un même exemple sera utilisé pour illustrer la qualité de la valeur de en fonction de la version de LOOK-AHEAD. Version 1 : Look-Ahead_beta. Une première estimation de est de raisonner uniquement sur le nombre de ports primitifs qui se trouvent dans et de prendre comme hypothèses que la configuration qui demande le moins de connexions existe tous les ports primitifs de la division par deux du cardinal de. -dessous (cf. Figure 56) circulaire). contient 4 ports primitifs (représentés sous forme Figure 56 : Exemple illustrant Look-ahead-beta Page 113

114 faut au moins ajouter 2 connexions pour terminer la construction). s voir ci- Version 2 : Look-Ahead-optimized. Il rapprocher ainsi de la valeur réelle de. Une estimation plus fine consiste à regarder concrètement si les ports primitifs de sont compatibles deux à deux. La borne inférieure du nombre de connexions supplémentaires ( ) peut ainsi être affinée en tenant compte des possibilités de connexion deux à deux et celles qui doivent obligatoirement être effectuées avec un port primitif qui ne se trouve pas dans. Afin de rendre intuitive cette optimisation, considérons le cas particulier où la connexion de chaque port primitif de aura lieu avec un port au cardinal de. Dans le cas général, le calcul du nombre de connexions qui peuvent être réalisées entre ports primitifs de et le nombre de. La Figure 57 illustre la version 2 de LOOK-AHEAD. Cette figure représente une partie du graphe de compatibilité. Ainsi, chaque sommet représente un port primitif et chaque arête représente une connexion possible entre deux ports primitifs. Dans cet exemple,,,, et se trouvent dans. Un calcul de la valeur de est effectué comme suit : La valeur calculée de est donc égale à 3. Cette version donne une meilleure estimation permettant d Page 114

115 Figure 57 : Exemple illustrant Look-ahead-optimized Heuristiques Le rôle des heuristiques présentées ci- être faits à un moment donné de la construction but fixé, c'est-à- Ces heuristiques essayent chance taille minimale. MIN-DOMAIN (MD) : étape 1. MIN-DOMAIN est une heuristique connue dans le domaine des réseaux de contraintes (CSP) [116]. Son objectif est prioritairement par les branches qui conduisent probablement à un échec (rendant le reste de la construction superflu). MIN- dre de traitement des variables : elle variables est effectué en favorisant la variable qui possède le plus petit domaine de valeurs. pour orienter. à e possédant le plus petit domaine. e connexion est effectuée comme suit : La valeur du domaine compatibilité. Cette valeur est égale au nombre de successeurs dont la cardinalité courante est strictement positive. En effet, un port primitif dont la cardinalité est égale à zéro est un port primitif qui ne peut plus accepter de connexion. Les valeurs de domaine de certains ports primitifs sont mises à jour au moment de la connexion entre deux ports primitifs. Considérons deux ports primitifs et compatibles et tels que leur cardinalité respective soit strictement positive. La connexion entre et entraîne une modification de la valeur des domaines de chaque successeur de dans le cas où était égal à 1 avant la connexion, ainsi que celle des domaines de chaque successeur de (différent de ) dans le cas où était égal à 1 avant la connexion. Page 115

116 Exemple : La Figure 58 illustre cette mise à jour. La partie gauche de la figure représente une partie du graphe de compatibilité. est compatible avec et avec. est compatible avec et avec. Dans cet exemple la cardinalité courante de est égale à 1 et celle est égale à 2. On considère aussi que la cardinalité respective de chacun des autres successeurs de et de est strictement positive. La partie droite de la figure montre l et. Cette connexion a pour effet de décrémenter de 1 la cardinalité de et. Figure 58 : Exemple illustrant Min-domain La cardinalité de est alors égale à 0 et celle de est égale à 1. Le domaine de est donc décrémenté de 1 puisque la cardinalité de est nulle mais celle de cardinalité de reste strictement supérieure à 0. Min-domain-optimized. La version de MIN-DOMAIN que nous venons de présenter ci-dessus peut être optimisée. En effet, dans la première version, le choix du port primitif est réalisé de manière aléatoire s de dont le domaine est de taille minimale. Une optimisation de MIN-DOMAIN consiste à orienter ce choix vers un port primitif qui possède certaines caractéristiques. Pour ce faire nous utilisons des méta-heuristiques, tabou et roulette biaisée, qui seront présentées dans la section NO-NEW-DEPENDENCIES (NND). NO-NEW-DEPENDENCIES est une heuristique intuitive. Son objectif est qui pas de nouvelles contraintes à satisfaire. dans L chercher un port primitif compatible avec le port primitif extrait de. Le choix (par défaut) de s avec. -NEW-DEPENDENCIES consiste à orienter le choix vers un port primitif qui : Page 116

117 Propriété : Soit le port primitif extrait de et soit un port primitif appartenant au domaine de et appartenant aussi à. La connexion entre et parce que les ports dont dépend ont déjà été ajoutés à construction de (section ). -NEW-DEPENDENCIES se base sur la propriété ci-dessus. Le choix du port primitif compatible est donc effectué en priorité parmi les éléments de. Min-Effort-Etape2 (ME_E2). variable afin de minimiser son domaine afin de tendre de manière plus rapide vers la fonction objectif de BB. Concrètement, étant donné un port primitif devant être connecté et son domaine de ports primitifs compatibles, cela revient s ports primitifs compatibles afin de tendre vers un assemblage de taille minimal comme alternative à -NEW-DEPENDENCIES lorsque ne contient pas de ports compatibles. -EFFORT- port primitif de telle sorte que la connexion entre et introduise un minimum de dépendances, donc de connexions nécessaires supplémentaires.. Un exemple est proposé ci-dess graphe de compatibilité est représenté. Le port primitif. Dans cet exemple, le port primitif possède deux ports primitifs compatibles, et. est partagé par deux ports composites exposés, et. et choisi en priorité p.. La valeur MIN est égale à 2. Dans cet exemple, le port primitif sera Figure 59 : Exemple illustrant Min-Effort étape 2 Dans le cas général, il est possible que plusieurs ports primitifs compatibles répondent à ce critère de minimalité. Dans ce cas, le port primitif est sélectionné en procédant à un tirage aléatoire parmi cet ensemble. Page 117

118 Min-Effort-Optimized. La version de Min-Effort que nous venons de présenter ci-dessus peut être optimisée. En effet, le choix du port primitif compatible est réalisé de manière aléatoire parmi s qui vérifient les caractéristiques de minimalité de MIN- - sation de métaheuristiques telles que Tabou et de la roulette biaisée sont employées pour orienter le choix du port primitif compatible (section ). Min-Effort-Etape3 (ME_E3). Une heuristique du type Min- Elle a fin de minimiser a déjà été extrait de (i.e. étape 1) et un port primitif a déjà été choisi (i.e. étape 2). A titre de consiste à effectuer la connexion entre et exposés qui partagent choisir en priorité le port composite exposé composé du plus petit ensemble de ports primitifs. Ce port est celui qui introduira le moins de contraintes. La Figure 60 illustre de manière simple cette heuristique. Suite à la connexion de l. Celui qui introduit le moins de contraintes est qui sera choisi en premier. Figure 60 : Exemple illustrant Min-Effort étape Méta-heuristiques Trois méta-heuristiques sont présentées dans cette section. Elles perm heuristiques présentées dans la section précédente ( ) choix aléatoire doit être effectué parmi un ensemble de ports primitifs. Ce cas peut se présenter dans le contexte des heuristiques de la section uristique parmi -heuristiques. Le temps. Il est intéressent de considérer les aspects temporels dans la prise de décision relative au, utilisé Page 118

119 conjointement à TABOU et à la Roulette biaisée, est simple et intuitive leure solution) il est intéressa ssemblage courant ( ) vers un assemblage de taille strictement inférieure à où meilleures solutions, il est intéressant de prendre certains risques. Cela revient à choisir en priorité un solutions trouvées jusque là. Un niveau de risque est rajouté : est aussi considéré :. Cette variable est initialisée à 1 au début. Soit la variable contenant la date à laquelle la première solution de taille a été trouvée. Voici ci-dessous les valeurs que prend en fonction du delta : - si delta 2 secondes alors : et - si delta <10 secondes alors : et - si delta <30 secondes alors et et - sinon : et et TABOU [117]. Un score est associé à chaque port primitif de. Ce score correspond à un degré de est incrémenté suivant une valeur stockée dans une variable. La variable est initialisée à 1 au assemblage de taille inférieure à celle des solutions courantes est trouvée, la valeur de est incrémentée de la valeur de. Roulette biaisée. La -heuristiques que nous ports primitifs en tenant compte des deux aspects importants énoncés ci-dessous : - La qualité de chaque port primitif candidat - Le degré de risque à prendre (obtenu grâce à la méta-heuristique liée au temps) é à la prise de risque est faible, un port primitif candidat possédant u candidat dont la qualité est considérée comme inférieure. En effet, lorsque le degré de prise de risque est faible, mieux vaut effectuer un choix sûr en sélectionnant un port primitif possédant un bon score de qualité. Par contre, dans le cas où le contexte lié à la prise de risque est élevé, un port primitif candidat s par rapport à un port primitif Page 119

120 candidat dont la qualité est considérée comme inférieure. Concrètement, cette méta-heuristique simule trois roulettes qui possèdent chacune quatre couleurs : rouge, bleu, gris et noir. La répartition des équiprobable mais est fonction du degré de prise de risque. s est de choisir un port primitif parmi un ensemble de ports primitifs. Cet ensemble est partitionné suivant 4 couleurs. Pour chacune des trois roulettes la répartition des couleurs est effectuée comme suit : o Rouge s des solutions trouvées jusque là. o Bleu olutions trouvées jusque là. o Gris trouvées jusque là. o Noir. La Figure 61 illustre le pourcentage dédié à chaque couleur pour chaque roulette. Une ligne horizontale du tableau représente prise de risque choisis (80%). Dans le cas où la prise de risque doit être moyenne (roulette 2), ce sont les ports moyennement utilisés qui ont encore le s (60%). Dans le cas où la prise de risque doit être forte (roulette 3), ce sont les ports quasiment jamais utilisés qui ont le plus de chances s (85%). Figure 61 : roulette biaisée 4.5 DISCUSSION assemblages quasi-valides est un problème difficile. Nous avons montré, dans la section 4.3, que le p assemblage quasi-valide est un problème NP- Page 120

121 Complet (preuve par réduction polynômiale de 3-SAT vers notre problème). Nous avons ensuite proposé (section 4.4) des algorithmes de construction. Nous avons commencé par décrire une modélisation du assemblages en termes de modélisation CSP (section 4.4.1). Puis nous avons présenté un algorithme permettant de construire tous les assemblages quasi-valides. Un deuxième algorithme optimisé a été présenté (section 4.4.3). Ces optimisations ont pour but de rendre assemblages quasi-valides suivant un processus de construction bottom-up. Ces optimisations ont été introduites sous la forme de stratégies -heuristiques qui garantissent un parcours complet OOK-AHEAD fonction objectif e branches inutiles et LOOK- ction de branches mortes. Nous avons proposé deux versions de LOOK-AHEAD basées toutes deux sur le même principe : calculer, à partir du nombre de ) et du nombre courant de connexions assemblage du nombre de connexions la plus optimiste pour satisfaire les contraintes actuellement dans. Dans le cas où le résultat de ce calcul est supérieur au nombre minimal de connexions de ge solution trouvé présente es de cette configuration sont mortes. La première version considère le cas le plus optimiste et ne considère pas les autres. La deuxième version tient compte des connexions qui peuvent être réalisées entre des éléments de. Le rôle des heuristiques MIN-DOMAIN, NO-NEW- DEPENDENCIES, MIN-EFFORT-E2 et MIN-EFFORT- les choix qui doivent être faits r la probabilité que assemblage en cours de construction tende vers un assemblage de taille minimale. MIN-DOMAIN est dre dans lequel il faut traiter les variables. NO-NEW- DEPENDENCIES et MIN-EFFORT- lequel il faut instancier une variable. MIN-EFFORT-E3 est une heuristique qui cherche à minimiser le nombre de contraintes qui seront introduites suite à une connexion. Le rôle des méta-heuristiques TABOU et roulette biaisée optimiser les heuristiques MIN-DOMAIN, MIN-EFFORT-E2 et MIN- EFFORT-3. En effet, lorsque plusieurs ports primitifs répondent aux choix aléatoire est effectué. Ces méta-heuristiques interviennent à ce moment là pour orienter ce choix. hme permettant de trouver tous les assemblages quasi-valides de taille minimale est présentée sur la Figure 62. Cette version comporte tout de LOOK- AHEAD, qui pour des raisons de clarté utilise la version LA_beta. Pour obtenir la version optimale il suffit Il apparaît que notre algorithme de construction automatique assemblages quasi-valides, dans sa version optimale, atteint une performance acceptable. Cependant il existe des faiblesses : dans ce cas notre algorithme va parcourir tout de recherche. Page 121

122 Cas où la première solution est difficile à déterminer. possible, dans certain contextes (ra me prennent du temps pour trouver cette première solution. Figure 62 : Algorithme Research_All_Min Page 122

123 Page 123

124 5 EVOLUTION DYNAMIQUE SURE ET NON ANTICIPEE 5.1 INTRODUCTION ce chapitre est de proposer un la substitution de composant de manière automatique, sûre et non anticipée (nous avons présenté une partie de ce travail dans [97, 94]). Dans le processus de substitution, il est possible de distinguer deux étapes : la première consiste à calculer une ou plusieurs configurations solutions de substitution. La deuxième consiste à choisir une calculées puis à effectuer concrètement (physiquement) la substitution. Dans le cadre de ce travail, nous nous intéressons à la première partie 3. Dans un tel contexte, nous proposons -à-un, dite classique, à une substitution n-à-1. de composants, pour faire face au vieillissement, aux lité, Réparer un assemblage de composants valides composant est approches choisissent la stratégie de substitution un-à-un. Les substitutions trouver un tel composant sont réduites par le fait que les contraintes concernant sa structure, notamment le type des interfaces exposées, sont fortes. Dans le cas où un tel composan est plus flexible de permettre par un assemblage de composants. Le but de ce chapitre est de proposer un tel mécanisme CONTEXTE L constitue le contexte général de ce chapitre. représente un domaine à part entière, regroupant un nombre important de styles s. Il est cependant possible de distinguer deux grands axes. Le premier est dédié aux problématiques concernant les stratégies e de leurs conséquences sur le système. Le second est dédié aux problématiques concernant la réalisation concrète (i.e. présenté dans ce chapitre porte sur le premier axe. Nous verrons cependant à la fin de nos perspectives se place dans le second axe. Les mots clés de ce chapitre sont décrits ci-après. Evolution : substitution de composants. Il existe plusieurs (section 2.3.3). Dans le cadre de notre travail, nous étudions la substitution de composants. Notre problématique générale liée 3 : quel es arrêter pour que le reste du système puisse fonctionner durant la substitution. Page 124

125 : étant donné un assemblage de composants et un composant cible de cet assemblage, comment remplacer le composant cible? Evolution dynamique. Le remplacement du composant cible est effectué lors de l ela exclut un redéploiement complet du système. Evolution sûre. considérons doit être sûre, dans le sens où elle doit préserver la mblage. si est un système logiciel et si est une évolution de alors. Cela signifie que si est valide par rapport à alors est valide par rapport à. Evolution non anticipée. Elle ne doit pas être figée lors de la phase de conception, contrairement aux approches classiques anticiper (voir chapitre 2). dynamique sûre et non anticipée constitue un problème difficile à résoudre Objectifs et plan du chapitre Après avoir défini le contexte de substitution, nous exposons ci-dessous notre problématique : Etant donné un assemblage valide de composants et un référentiels de composants, comment remplacer un composant de manière dynamique, sûre et non anticipée? La substitution 1-à-1 est un cas particulier de la substitution n-à-1 que nous présentons dans ce chapitre. Le chapitre est organisé de la manière suivante : la section 5.2 propose une représentation abstraite 5.3 présente notre approche de substitution n-à-1 et enfin la section 5.4 clôt le chapitre avec une discussion EXEMPLE Nous avons introduit, dans la section , un exemple représentant un système bancaire. Nous réutilisons cet exemple afi refaire une description. ci-après (cf. Figure 63) représente un système bancaire. Page 125

126 Figure 63 : Exemple pour illustrer la substitution n-à-1 Il répondant à un objectif fonctionnel. Les composants sont au nombre de six : et du composant. Cet assemblage est quasi- tous les composants sont localement cohérents et le port est connecté. ailleurs strictement complet. 5.2 REPRESENTATION ABSTR DE COMPOSANTS Une modélisation plus abstraite assemblage de composants peut être défini composant et où chaque arête représente une interaction entre deux composants. Un lien entre deux les deux composants représentés par ces autres termes, il existe au moins une connexion entre deux de leurs ports primitifs. Ce car plusieurs connexions entre deux composants seront représentées par une seule arête. Nous distinguons aussi deux sortes de composants : ceux qui contiennent un port primitif correspondant à un objectif fonctionnel et les autres. supporte un objectif fonctionnel. Définition : [ ] Un assemblage de composants est un couple ctionnels. Page 126

127 signifie qu'il existe une connexion (réelle) et le composant représenté par le. Figure 64 : Un exemple du graphe La Figure 64 présenté dans la Figure 63. Le sommet dont le contenu est grisé supporte un objectif fonctionnel. Figure 65 : Choix du composant cible Notation : [composant cible] Soit -dessus (cf. Figure 65), le composant cible que nous avons sélectionné est le composant (noté MB), représenté par un contour noir épais. Opérateur : correspond aux arêtes issues de dans le graphe Cet ensemble est obtenu comme suit : Remarque : Le graphe est non orienté. Par abus de notation on considèrera que Exemple. Dans -dessus (cf. Figure 65), Page 127

128 5.3 SUBSTITUTION N-A-1 Cette section est consacrée à la substitution n-à-1 qui constitue une approche inédite de la substitution d rête à la substitution un-à-un. Cependant, -ci ne peut être utilisée. La substitution n-à-1 vise à pallier cet inconvénient tout en essayant de conserver certains avantages, comme par exemple un nombre de composants et de liaisons proches ou même inférieurs à ceux de complet, ce dernier peut devenir incomplet. Par a cible, certains composants deviennent inutilisés pour atteindre les objectifs fonctionnels. On dira de ces Notre plan de substitution de composants n-à-1 comporte alors quatre phases : 1. Supprimer le composant cible 2. Supprimer les composants morts résultants 3. assemblage 4. Contrôler la correction du nouvel assemblage SUPPRESSION DU COMPOSANT CIBLE Cette section est consacrée à la première phase de notre stratégie de reconstruction dynamique. Cette phase est simple et se décompose en deux étapes : Soit 1. de composants. 2. de composants. et soit une abstraction de cet assemblage avec. Un composant est choisi : Le sommet correspondant à dans est ensuite supprimé (ainsi que ses arêtes). Remarque : Une fois supprimé, le composant cible ne pourra en aucun cas être réutilisé dans le processus de reconstruction. En revanche, un certain nombre de composants morts pourront être supprimés et certains du processus de reconstruction. Exemple. présenté dans la section La Figure 66 illustre le choix du composant cible. Page 128

129 Figure 66 : Sélection Le composant est choisi comme composant cible. Dans cet exemple, la suppression du composant cible provoque la perte de la complétude. La Figure 67 la suppression du composant cible. En effet, les composants, et sont chacun devenus localement incohérents. Par exemple, le composant est incohérent puisque son port composite est incohérent (partiellement connecté). Figure 67 suite à la suppression du composant cible Page 129

130 Figure 68 : le graphe. La Figure 68 présente le graphe après la suppression du sommet. Ce graphe est donc un sous-graphe de tel que GESTION DES COMPOSANTS MORTS Cette section est consacrée à la deuxième phase de notre stratégie de reconstruction dynamique. Elle se décompose en deux étapes : 1. Détecter les composants morts 2. Supprimer les composants morts Lorsque le composant cible nes parties deviennent inutiles. En effet, certain satisfaire les sont mortes, nous utilisons un graphe représe (voir section 5.2). Considérons le (cf. Figure 68). Le graphe (i.e. ) partitionner cet ensemble en deux sous-ensembles connexes contenant correspondant à un objectif fonctionnel. Le second est complémentaire des composantes connexes qui fonctionnel Définitions Définition : Nous définissons comme étant le sous-graphe de duquel ont été ainsi que les arêtes issues de. Définition : Nous définissons comme le graphe composé de toutes les composantes connexes de qui ont au moins un correspondant à un objectif fonctionnel. Page 130

131 Définition : Nous définissons aussi comme le graphe composé de toutes les composantes connexes de qui ne correspondant à un objectif fonctionnel. Exemple. La Figure 69 illustre les définissions de et de. Figure 69 : Les composantes connexes vivantes et mortes Suppression des composants morts La suppression des composants morts est une étape nécessaire puisque conserver des composants inutiles ajoute des dépendances inutiles créant au final un assemblage ne répondant plus de manière optimale au critère de minimalité recherché, compliquant le processus de construction et de contrôle de la sémantique, fabriquant des assemblages beaucoup plus sensibles aux pannes, moins propice à Exemple. La Figure 70 identifie les composants morts. Figure 70 : La détection des composants morts Page 131

132 La Figure 71 présente le graphe de connexion abstrait correspondant. composantes connexes vivantes correspond au sous-graphe formé uniquement de la partie gauche du graphe Client). Figure 71 : Le graphe et ses composantes connexes es composantes connexes mortes correspond au sous-graphe formé de la partie droite du graphe ASSEMBLAGE INCOMPLET Cette de composants obtenu après avoir supprimé le composant cible ainsi que les composants morts. Une fois les composants morts supprimés,, mais non suffisants, pour atteindre les objectifs fonctionnels. Notre objectif est alors de construire un assemblage de composants permettant de endre cohérent. L incomplet est considéré comme un résultat intermédiaire de notre algorithme de construction décrit dans le chapitre 4. Les dépendances insatisfaites (i.e. ports composites incohérents) sont considérées comme les objectifs fonctionnels restant à satisfaire. La seconde étape consiste alors à relancer le processus de construction avec les nouveaux objectifs fonctionnels Calcul des objectifs fonctionnels initiaux La première étape consiste à calculer les objectifs fonctionnels à satisfaire dans assemblage partiel. Il est possible, à cause des intersections de ports composites, que plusieurs ensembles fonctionnels soient possibles. 1. ensemble des ports composites exposés incohérents, IncompleteExposed. 2. IncompleteExposed, PrimIncompleteExposed 3. s non connectés contenant un objectif fonctionnel : UnconnectedObjective 4. UnconnectedObjective 5. PrimIncompleteExposed et de PrimUnconnectedObjective RequiredConnection Page 132

133 6. Une configuration est un ensemble de ports exposés qui, pour chaque élément de RequiredPrimConnection, contient un unique port exposé contenant cet élément. Exemple. La Figure 72 plusieurs configurations possibles. Un composant C est considéré. Celui-ci possède 5 ports composites exposés :,, et. Dans cet exemple,,, et sont incohérents et est cohérent. Les configurations à considérer sont :,,,. Figure 72 Exemple du calcul des objectifs fonctionnels avant la reconstruction Processus de reconstruction De manière intuitive, nouveaux composants et de nouvelles connexions. Cette reconstruction est effectuée en utilisant le référentiel de composants. Exemple. En considérant le même exemple, la reconstruction repart du graphe. (cf. Figure 73) puisque le composant est incohérent (i.e. il devient incohérent suite à la suppression du composant ainsi que de ses composants morts, ). De nouveaux composants La complétude est alors recherchée en sélectionnant et connectant de nouveaux composants. Page 133

134 Figure 73 e, la configuration est constituée du port composite exposé. le port primitif. Le processus de construction commence à partir de cet objectif fonctionnel. port primitif du composant. ste, dans le référentiel de composants, un composant qui possède un port primitif compatible avec le port primitif du composant Le composant est choisi puis connecté au composant via son port primitif. La situation à ce moment est alors celle présentée dans la Figure 74. Figure 74 : Une étape intermédiaire de la reconstruction Page 134

135 L s composants ne sont pas tous localement cohérents. En effet, le composant n : le composant est connecté au composant via son port primitif. Figure 75 : Un assemblage quasi-valide a été reconstruit quasi-valide donc complet. La Figure 75 illustre cela. On peut alors considérer que le composant cible a été remplacé par un assemblage composé des composants et. En contrôlé» par contrôlé» par. La correction est finalement calculée sur les assemblages complets qui ont été reconstruits. 5.4 DISCUSSION Nous avons proposé dans ce chapitre un processus original pour la substitution de composants. Notre approche permet la substitution dynamique sûre non anticipée de composants même dans les situations où la substitution un-à-un est impossible. Nous proposons alors une substitution n-à-1, en remplaçant le composant cible par un assemblage de nouveaux composants. Lorsque le de. Le but de la substitution 1-à-1 et n-à-1 est de restaurer cette complétude. Dans le processus de substitution un-à-un, notre règle de compatibilité à la substitution entre deux composants est plus flexible que celles proposée dans les approches existantes. La compatibilité appliquée à notre modèle de ports permettrait de trouver un ensemble de candidats compatibles de taille inférieure à celui permis avec notre règle de Page 135

136 compatibilité. En effet, la compatibilité stricte imposerait de connecter tous les ports primitifs du composant. Dans le processus de substitution n-à-1, outre le composant cible, nous supprimons tous les composants devenus inutiles pour assurer la complétude (les composants morts). Remarque : Il est possible que le nouvel assemblage comporte moins de composants et de liaisons que composants ont été mis à disposition dans le référentiel de composants depuis la construction initiale. La substitution n-à-1 généralise la substitution 1-à-1. Nous privilégions la substitution 1-à-1 t possible et une substitution n-à-1 sinon. Ce travail s s configurations de reconstruction solutions. ne des perspectives de ce travail consisterait à essayer de déterminer composants à arrêter pour que le reste du système puisse fonctionner durant le processus de substitution. Page 136

137 Page 137

138 6 REALISATION ET EXPERIMENTATIONS 6.1 JULIA Julia Julia respecte scrupuleusement les concepts énoncés par celui-ci tels que : le modèle boîte noire (basé sur l des services fournis et requis fournies et requises), la composition hiérarchique ou encore le partage de composants. Notre intérêt se porte sur ce modèle car il respecte les concepts clés énoncés dans la plupart des modèles à composants, tout en restant en accord avec les nôtres, DESCRIPTION DU MODELE Généralités. Un composant Fractal possède une membrane et un contenu. La membrane permet t le contenu correspond au code métier du composant. Dans Julia, le niveau : Au niveau le plus bas, la membrane est vide et le composant est vu comme un simple objet. Au niveau suivant, un méta-objet, situé aux services métier du composant. Au niveau suivant, Julia propose un certain nombre de contrôleurs (de base) destinés à gérer divers aspects relatifs à la structure et au cycle de vie du composant. Ces contrôleurs se trouvent dans la membrane. composant. Structures de données. ation de Julia se base sur les structures de données suivantes : - Les objets qui référencent les interfaces du composant ( et les interfaces de contrôle). Ces objets sont appelés. - Les objets de la membrane : o Le méta objet o sont appelés. o Les intercepteurs (optionnels). Ces objets sont appelés. Ils permettent de gérer des aspects non fonctionnels tels que la sécurité. Page 138

139 - Les objets qui implémentent le contenu du composant (composant ou primitif) Exemple. Voici ci-dessous (cf. Figure 76) et ci-après (cf. Figure 77) deux figures illustrant le schéma t de notre exemple fil rouge. Ces deux figures vont permettre Figure 76 : Un composant Client La Figure 76 représente le composant étamodèle. La Figure 77 Client Figure 77 : Implémentation du composant Client dans Julia Un objet : - (interface ) ; - (interfaces métier) ; - (interfaces de contrôle). Interface Component. du composant (noté sur la Figure 77) (noté sur la Page 139

140 Figure 77). Cette interface donne naissance à un objet services métiers fournis et requis services de contrôle du composant. Exemple. Figure 77, le composant. possède un objet Interfaces métier. Chaque interface fournie par le composant donne naissance à un objet Exemple. Figure 76, le composant possède deux interfaces fournies : et. Dans la Figure 77, la représentation de ces interfaces correspond aux objets et. Un autre composant pourra accéder au service du composant en obtenant du composant. En ce qui concerne les interfaces requises, Julia préfère les référencer par leur nom et non pas par un objet ReferenceInterface. Dans le cas où une référence sur un service requis est demandée (par exemple question est généré. Exemple. Figure 76, le composant possède deux interfaces requises : et. Dans la Figure 77, la représentation de ces interfaces correspond à la liste et non pas a des objets. Cette liste stocke le nom des interfaces requises et est gérée par le méta-objet (noté sur la figure). Interface de contrôle. Une interface de contrôle donne naissance à un objet qui Exemple. Figure 77, le composant Client possède un objet objets référencent des interfaces de contrôle Les objets de la membrane nnels. Ils peuvent être catégorisés en trois sortes : le méta-objet, les contrôleurs et les intercepteurs. Méta-objet Component. Le méta-objet interfaces métiers et aux interfaces de contrôles passe par cet objet. Exemple. Figure 77 du composant Client est représenté par qui pointe sur le méta-objet ( sur la figure). Cette entrée rfaces correspondant aux services métiers fournis ( et ) Page 140

141 , aux interfaces correspondant aux service métiers requis (Question et Dialogue) et aux interfaces de contrôle (LCC et BC). Les contrôleurs. Dans la version standard de Fractal, il existe quatre sortes de contrôleurs :, le, le et le. Un composant primitif possède un un et un. Un composant composite possède les quatre sortes de contrôleurs. Le composant. permet de configurer les attributs d Contrôleur de contenu. Le ajout et suppression de sous- composant composite. Contrôleur de cycle de vie. Le permet de gérer composant c'est-à-dire que les méthodes de bases de ce contrôleur permettent de lancer et de Contrôleur de liaisons. Le permet de gérer les connexions du composant avec un autre composant : il permet ainsi de créer et de supprimer une connexion. Les intercepteurs. et le contenu ou bien entre un objet et une interface de contrôle. Il permet de gérer la son retour LE FICHIER DE CONFIGURATION JULIA.CFG Julia permet de configurer l. Ceci est réalisé dans un fichier de configuration :. Les interfaces de contrôle ainsi que les contrôleurs utilisés y sont notamment spécifiés. La ffectuées suivant trois étapes : Entrée dans le fichier. 6.2 FRACT-PORT : UNE EXTENSION DE JULIA Le package est une extension de Julia. Nous le présentons dans cette section. Notre package vise en premier lieu à fournir les fonctionnalités nécessaires à la gestion des ports primitifs et composites (création, suppression, connexion, déconnexion, génération automatique etc.). Il vise aussi à fournir les fonctionnalités nécessaires au calcul de la quasi-validité, puis à la construction automatique Page 141

142 6.2.1 GENERALITES Vue générale. La Figure 78 illustre de manière synthétique les parties importantes de notre modèle. Conformément à notre métamodèle, un composant possède une partie externe et une partie interne. Notre package est une extension du Julia Framework, un composant possède également une partie de contrôle. Figure 78 : Les grandes parties de La partie intitulée Ports regroupe les classes relatives aux ports primitifs et composites. La partie intitulée Référentiel de composants correspond à une base de composants disponibles et utilisables pour construire ou pour reconstruire des assemblages de composants. La partie intitulée Noyau correspond à la partie calculatoire (calcul de la quasi-validité, construction, reconstruction, génération des ports). Quant à la partie de contrôle, elle fait le lien entre toutes les autres parties. Vue sur le package. La Figure 79 illustre la structure du package : Figure 79 : Vue générale du package fractports Le package org.objectweb.fractal.fr.ema.ports - org.objectweb.fractal.fr.ema.ports.controllers contient les classes relatives au code de nos contrôleurs (la partie de contrôle sur la Figure 78). - org.objectweb.fractal.fr.ema.ports.kernel contient les classes relatives au code du noyau. Page 142

143 - org.objectweb.fractal.fr.ema.ports.ports contient les classes relatives au code des ports primitifs et composites. - org.objectweb.fractal.fr.ema.ports.randomgenerator contient les classes correspondant à un ce générateur. Il sera utilisé pour créer des bases de composants et effectuer des séries de tests. - org.objectweb.fractal.fr.ema.ports.util Stratégie. artie de contrôle du composant via la modification du fichier de configuration Juila.cfg. Comme décrit précédemment, nos contrôleurs font le lien entre les autres parties CONTROLEURS Nous avons introduit un certain nombre de contrôleurs dont le rôle est de séparer le code lié à une activité particulière, par exemple, la gestion des ports, la gestion des objectifs fonctionnels, la gestion des interactions entre le composant et le référentiel de composants, ou encore la gestion des fonctionnalités offertes par le noyau. Vue générale. La Figure 80 illustre Figure 80 : Le composant et ses contrôleurs Nous avons séparé les contrôleurs en trois catégories : les contrôleurs de base de Julia sont présentés sur la partie gauche de la figure, nos contrôleurs sont présentés au centre de la figure, et un contrôleur proposé par quipe de SOFA est présenté sur la partie droite de la figure. Page 143

144 Vue sur le package. La partie du package relative aux contrôleurs est présentée ci-dessous (cf. Figure 81). Figure 81 : Le package relatif aux contrôleurs Page 144

145 Figure 82 : Diagramme de classe des interfaces de contrôle Page 145

146 contrôle, par une implémentation (Mixin) et par une entrée dans le fichier de configuration Julia.cfg. org.objectweb.fractal.fr.ema.ports.controllers est organisé comme suit : - org.objectweb.fractal.fr.ema.ports.controllers.interfaces contient les interfaces de contrôle. - org.objectweb.fractal.fr.ema.ports.controllers.mixin contient les implémentations des contrôleurs. La Figure 82 montre le diagramme de classes relatif aux interfaces de nos contrôleurs Le manager controller Le ManagerController sées par interfaces de contrôles ManagerControllerDesigner est consacrée au ManagerControllerArchitecte ManagerControllerAdministrative est consacrée à la partie interne du système. Nous décrivons ci-dessous (cf. Figure 83) Interface de contrôle dédiée au concepteur. La Figure 83 ManagerControllerDesigner. Figure 83 : Interface de contrôle dédiée au concepteur Page 146

147 Cette interface de contrôle permet de gérer les préoccupations liées concepteur. Les méthodes adddatabasecomponent() et removecomponentfromdatabase() permettent, respectivement, et de supprimer un composant au référentiel de composants du composant. Nous verrons dans la section composants : soit celui-ci fait partie de la base de connaissance du composant (style agent), soit il est, cependant il serait relativement aisé de réaliser la deuxième modulo de légères modifications au niveau du DataBaseController. La méthode au composant. Cette méthode utilise le travail de Sofa : le BehaviorProtocolController est utilisé. Deux méthodes createprimitiveport() es sont surchargées et ne possèdent pas le même nombre de paramètres. Les paramètres communs sont les suivants: le nom du port, un tableau contenant le nom des interfaces fournies puis un tableau contenant le nom des interfaces requises. Le paramètre suppl direction du port primitif. La direction est exprimée par un paramètre de type String. La méthode removeprimitiveport paramètre. La méthode createcompositeport de cette méthode sont les suivants : le nom du port composite, un tableau contenant le nom des ports primitifs directs et un tableau contenant le nom des ports composites directs. La méthode removecompositeport La méthode perm automatiquement les ports primitifs et composites du composant à partir du protocole de comportement du composant. La Figure 84 ManagerControllerArchitecte. Les méth sont les suivantes. La méthode composant. Cette méthode prend en paramètre un port composite. Ce port composite est alors mis à plat donnant ainsi un ensemble de ports primitifs qui constituent les objectifs fonctionnels du composant. La méthode objectifs fonctionnels du composant. La méthode listfcprimitiveports() iste des ports primitifs du composant. La méthode iscompatiblefcprimitiveport() prend en paramètre le nom PrimitivePort et renvoie vrai si ces deux ports primitifs sont compatibles et faux dans le cas contraire. La méthode bindfcprimitiveport() primitifs du composant et un paramètre de type PrimitivePort t Page 147

148 Figure 84 : Interface de contrôle ManagerControllerArchitecte interface requise du premier port à unbindfcprimitiveport() paramètre de type PrimitivePort Cette méthode supprime la liaison entre ces deux ports. Une exception est déclenchée dans le cas où listfccompositeports() p composites du composant. La méthode checkcoherence() La méthode retourne un objet de type Vector. Celui-ci ne contient aucun élément cohérent. Il contient incohérents sinon. La méthode checkquasivalidity() permet de contrôler la quasi-validité de rt à ses objectifs fonctionnels. La méthode Page 148

149 getnewinputtorebuild() peut remarquer que le Vector -valide. La méthode construit tous les assemblages quasi-valides à partir des objectifs fonctionnels et du référentiel de composants. Le résultat est retourné dans un Vector. La méthode construit tous les assemblages quasi-valides de taille minimale. Le résultat est retourné dans un Vector. La méthode removeallthedeadcomponents() prend en paramètre le composant cible (i.e. le composant devant être remplacé semblage. A titre de remarque, la méthode removeallthedeadcomponents() fait appel à la méthode removedeadcomponents() de ArchitectureController. La méthode rebuild() permet de reconstruire de taille minimale quasi-valides cte doit dans un premier temps utiliser la méthode void removeallthedeadcomponents() puis, dans un second temps, la méthode rebuild(). Nous rappelons que le processus de reconstruction a été détaillé dans le chapitre 5. Voici ci-dessous la perdre sa propriété de quasi-validité. A titre de rappel un assemblage est quasi-valide par rapport à ses objectifs fonctionnels si chaque port composite fonctionnel est connecté. La méthode getnewinputtorebuild() du FunctionalObjectivesController est utilisée pour récupérer la primitifs directs et indirects devront tous être connectés. Voici concrètement la manière dont sont E des ports primitifs connectés et partagés par au moins un port composite incohérent est calculé. Une liste de listes est calculée comme suit : chaque sous- E et contient les ports composites qui le partagent. Cette liste est ensuite traitée comme suit : si une sous liste suivant alors les éléments qui ne le sont pas sont retirés de la sous-liste : un port composite incohérent représentant un objectif fonctionnel, ou bien un port composite partiellement connecté contenant un port primitif connecté et partagé par aucun autre port composite. La liste de sous-listes est ensuite développée pour finalement obtenir la liste des points CalculatorObject et le calcul de volontairement pas remis à zéro après chaque itération assemblages de taille minimale à par de Vector où fonctionnels). La méthode rebuild_ok() du Calculator est appelée de manière itérative. A chaque Page 149

150 . Durant les assemblages de taille minimale éinitialisé à chaque itération puisque le but est de trouver la meilleure solution. Implémentation. Le fichier du contrôleur principal. et Controller étend les interfaces de contrôles ManagerControllerDesigner et ManagerControllerAdministrative. Remarque : utilisées dans un programme utilisant le package fractport. Les méthodes du ManagerControllerAdministrative ne doivent en aucun cas pouvoir être utilisées directement par le programmeur. Une méthode security() a été implémentée dans le ManagerControllerMixin dans le but ManagerControllerAdministrative en fonction d Les contrôleurs de ports : 1. Le contrôleur de ports primitifs ( des ports primitifs du composant. Il permet de créer et de supprimer des ports primitifs. Il permet de tous les ports primitifs du composant. Il permet de gérer la connexion / suppression de ports primitifs. 2. Le contrôleur de ports composites (CompositePortController) des ports composites du composant. Il permet de créer et de supprimer des ports composites. Il 3. Le contrôleur de la génération des ports (GeneratePortsController) : il permet de générer et comportement. Voici ci-dessous et à la génération des ports. Interface de contrôle dédiée aux ports primitifs. Le fichier est Interface de contrôle dédiée aux ports composites. est sites. Interface de contrôle dédiée à la génération des ports. Le fichier est Page 150

151 Voici ci-dessous la description des implémentations respectives des interfaces de contrôle que nous venons de présenter. Implémentation du contrôleur de port primitif. Le fichier ntrôleur de ports primitifs.. est implémente Implémentation du contrôleur de ports composites. Le fichier. Implémentation du contrôleur de la génération des ports. Le fichier des ports Le contrôleur des objectifs fonctionnels Il permet de rajouter ou de supprimer des objectifs fonctionnels au composant. Il est également en charge de Interface. Le fichier gestion des objectifs fonctionnels du composant. Implémentation. Le fichier implémente Le contrôleur du référentiel de composants Le contrôleur dédié au référentiel de composants a pour objectif de gérer le référentiel de composants. Deux approches différentes peuvent être considérées suivant le contexte dans lequel évolue le composant. Celles-ci sont les suivantes : 1. Orienté ateliers : Un référentiel de composants est présent sur la plate forme comme un Un composant publie sa référence au près du référentiel de composants puis il peut y effectuer des requêtes. 2. Orienté agents : le composant gère lui-même sa base de composants, tel un agent qui gère sa base de connaissances. Chaque composant stocke son propre référentiel de composants. Celui-ci correspond aux comp détectés dans son environnement. La Figure 85 illustre les deux approches. Page 151

152 Figure 85 : Deux approches concernant le référentiel de composants Interface. L référentiel de composants. Implémentation. Le fichier à la gestion du référentiel de composants connexions courantes (i.e. entre les ports primitifs des composants constituant son assemblage). Interface. Le fichier la partie interne du composant PORTS Notre métamodèle fractports, des connecteurs explicites sont utilisés. Ces connexion hitecture. La Figure 86 illustre le package org.objectweb.fractal.fr.ema.ports.ports. Page 152

153 Figure 86 : Le package Ports org.objectweb.fractal.fr.ema.ports.ports est organisé comme suit : - org.objectweb.fractal.fr.ema.ports.ports.interfaces contient les interfaces relatives aux ports et aux connecteurs - org.objectweb.fractal.fr.ema.ports.ports.impl des connecteurs - org.objectweb.fractal.fr.ema.ports.ports.bindings contient les classes réifiant les connexions entre ports primitifs NOYAU Le package org.objectweb.fractal.fr.ema.ports.kernel est illustré sur la Figure 87. Page 153

154 Figure 87 : Le package Kernel org.objectweb.fractal.fr.ema.ports.kernel est organisé comme suit : - org.objectweb.fractal.fr.ema.ports.kernel.builder contient principalement la classe du CalculatorObject. - org.objectweb.fractal.fr.ema.ports.kernel.portsgeneration contient les parser dédiés à la génération des ports. Ces parser ont été créés à partir. Le package PortsGeneration contient aussi nos fichiers écrits en ANTLR. - org.objectweb.fractal.fr.ema.ports.kernel.statistics - org.objectweb.fractal.fr.ema.ports.kernel.substitution CalculatorObject. Le a pour objectif la gestion des calculs concernant la construction et la assemblages valides. Le CalculatorObject utilise une structure de données entiers et non pas directement sur les composants. Il implémente les algorithmes, les stratégies et les heuristiques qui ont été présentés dans le chapitre consacré à la construction automatique assemblage assemblages valides. Les parser pour la génération des ports. r créer les parser. Les règles de génération ont déjà été présentées dans le chapitre consacré au métamodèle. Les fichiers contenant ces règles se trouvent dans le répertoire Rules. Page 154

155 Figure 88 : Le package PortsGeneration 6.3 CREATION EFERENTIEL DE COMPOSANTS Le domaine de la recherche concernant les composants logiciels manque cruellement de base de composants facilement exploitable pour réaliser des tests sur les composants. Nous avons vu dans les chapitres précédents que notre approche de construction et de reconstruction automatique utilisait des heuristiques, méta-heuristiques et stratégies qui sont généralement employés dans le domaine de intéressant de pouvoir réaliser des tests «grandeur nature». ons dans cette section un générateur automatique de référentiel de composants : Fractal Data Base Builder (FDBB). Celui-ci se trouve dans le package org.objectweb.fractal.fr.ema.ports.randomelygenerator. FDBB applique une stratégie de calcul composée de deux parties méthodes, des interfaces, des ports primitifs, des ports composites et des composants, la seconde consiste ensuite à générer les fichiers Java compatibles avec Julia. Page 155

156 Figure 89 : Le package RandomelyGenerator CALCUL VIRTUEL Le calcul virtuel consiste à raisonner sur des objets virtuels et non sur des méthodes, interfaces, ports et composant concrets. Matrice. Une matrice nombre-de-composants X nombre-de-composants est générée. Un numéro de signifie que le composant représenté par le numéro l possède une connexion avec le composant représenté par le numéro c. Liste de méthodes. Une liste contenant des noms de méthodes est générée. méthodes choisies dans la liste de méthodes. Liste de ports primitifs générique. Une liste de ports primitifs génériques est générée. A chaque port déterminé. Liste des composants. Une liste de composants est générée. La matrice est analysée. Pour chaque ligne l de la matrice un composant est créé. Ce composant va posséder autant de ports primitifs que de 1 sur la représenté par le numéro l et celui représenté par le numéro c. Un port primitif générique est alors choisi parmi les ports primitifs génériques de la liste de ports primitifs génériques. Le rôle des interfaces du port est alors défini à ce moment la. A partir du port primitif générique sont calculés, de manière aléatoire, deux ports primitifs duaux : les interfaces de chacun des deux ports possèdent des rôles compatibles. Page 156

157 Les ports composites. Pour chaque composant, une liste de ports composites est générée GENERATION DES FICHIERS JAVA La seconde partie du processus de génération consiste à générer les fichiers Java à partir du calcul effectué dans première partie : les interfaces et les implémentations Java sont générées. La figure cidessous (cf. Figure 90) Figure 90 : Exemple de fichier Java généré par FDDB Page 157

158 6.4 UTILISATION DE FRACT-PORT UN PREMIER EXEMPLE Nous pro FRACT-PORT. Nous allons construire un mini-système bancaire. Nous proposons ainsi de décrire le code nécessaire à la proposé sur la Figure 91. Figure 91 : Un exemple de mini système bancaire Dans cet exemple plusieurs composants interviennent : un composant Client, un composant Bank, un composant ATM, un composant DataBase et un composant Provider. La Figure 92 montre les classes qui entrent en jeu dans cet exemple. Figure 92 : Exemple de reconstruction Page 158

159 La figure ci-dessous montre le code de la déclaration des différents types de composants. Ce code est écrit dans un Julia standard. Par exemple, le type de composant compclienttype est définit comme Money_interface, dont Money.java et dont le rôle est fournie. Les composants sont ensuite instanciés à partir de deux éléments : leur type respectif et une implémentation. compclient est créée à partir du type compclienttype (défini CompClientImpl.java. Une fois que les composants ont été instanciés, des ports vont leur être attribués. La figure ci-dessous correspond à ce code. Par exemple, la création de ports primitifs et composites pour le composant ATM est effectuée comme suit ManagerControllerDesigner est utilisée pour effectuer cette tâche. Page 159

160 La deuxième ligne du code ci-dessous permet de créer un port primitif de nom Dialogue_PrimitivePort_ATM possédant une interface fournie Dialogue_interface et une interface requise Money_interface. A la 6 ème ligne, un port composite est créé : son nom est CompositePort_ATM1 et il contient les ports primitifs de nom respectif Dialogue_Primitive_Port_ATM et Transaction_PrimitivePort_ATM. Un composant composite principal est ensuite créé (voir la figure ci-dessous). Ce composant va constituer le mini-système bancaire. Dans le code ci-dessous ce composant est référencé par la variable comparchi. Les 5 composants sont placés dans le composant via le ContentController de Julia. Les composants sont ensuite connectés entre eux via les ports primitifs. Par exemple, la connexion du port primitif de nom «Dialogue_PrimitivePort_C» du composant Client au port primitif de nom «Dialogue_PrimitivePort_ATM» du composant ATM est effectué comme suit ManagerControllerArchitect bindfcprimitiveport. Une fois que les composants ont été connectés, un objectif fonctionnel est ajouté au composant principal comparchi de contrôle ManagerControllerArchitecte. La figure ci-dessous illustre CompositePort_C du composant Client. Ce qui donne au final DialoguePrimitivePort_C comme objectif fonctionnel Page 160

161 concret. Nous affichons courant via la méthode displaycurrentassembly() et nous testons la quasi- checkquasivalidity() à la ligne 6 de la figure cidessous. Le composant Provider : ceci est effectué à la ligne 3 de la figure ci-dessous via la méthode removeallthedeadcomponents(). Suite à cette suppression, nous affichons displaycurrentassembly() (ligne 4) puis la quasi-validité est à nouveau contrôlée (ligne 5). Ensuite, nous recommençons la même opération avec le composant Bank displaydeadcomponents()). Ensuite nous supprimons concrètement le composant Bank ainsi que les Page 161

162 composants morts via la méthode removeallthedeadcomponents() résultant ainsi que le résultat du contrôle de la quasi-validité. Afin de tester la reconstruction automatique, nous plaçons les composants Bank, Provider et DataBase dans le référentiel de composants du composant principal. Ceci est effectué dans le code présenté cidessous. La reconstruction automatique est ensuite effectuée via la méthode rebuild(), telle que illustrée dans la figure ci-dessous. Les assemblages solutions sont alors affichés via la méthode displayarchitectures() (ligne 4). Le premier assemblage solution est instancié dans le composant principal via la méthode instanciatearchitectureth() semblage courant afin de vérifier été instancié via la méthode displaycurrentassembly() (ligne 6). Au final nous recalculons la quasivalidité via la méthode checkquasivalidity() (dernière ligne). Page 162

163 Le résultat obtenu est celui illustré sur la Figure 93. Page 163

164 Figure 93 : Résultat de la reconstruction EXEMPLE DE CONSTRUCTION AUTOMATIQUE Exemple 1 Voici ci-dessous un premier exemple de construction automatique. Dans cet exemple un premier assemblage quasi- potentiellement trouvés. Ensuite une solution de taille inférieure est trouvée : la taille est 100. Le temps (qui est paramétrable) entre deux assemblages solution de taille 100 ayant dépassé la durée maximale, : la borne est forcée à 100/2. Ensuite une solution de taille 48 : la valeur de la borne est 11 solutions de taille 19 ont été trouvées. Page 164

165 Exemple 2 Dans cet exemple un premier assemblage quasi-valide de taille cette taille sont potentiellement trouvés. Ensuite une solution de taille inférieure est trouvée : la taille utilisée est à nouveau utilisée : le message «mission non remplie!!!» est alors affiché en console. Cela signifie alors que la borne : la borne inférieure était 29 et la borne supérieure était 58 : la borne est alors forcée à (58+29)/2. Une solution est trouvée à 43, calculée à partir de 29 et de 58. Le résultat final est : 8 assemblages de taille U N DYNAMIQUE SURE ET NON ANTICIPEE Nous considérons un assemblage de composants quasi- fonctionnels. Page 165

166 sé sur la figure ci-dessous. comp0 et le second est la suppression du composant comp22. Cas 1 : On supprime le composant comp0. Le graphe (cf. Figure 94) illustre la configuration comp5) représente un objectif fonctionnel. Le numéro 41 au dessus de la liaison entre le composant 5 et le composant 35 est une abréviation de nomportprimitif41_c5_client-server. Figure 94 : Le composant Comp0 est désigné comme composant cible La Figure 95 montre les composants qui deviennent morts suite à la suppression du composant comp0. Page 166

167 Figure 95 : quatre composants sont morts La figure ci- comp0 et des composants morts. : dans cet exemple, seuls des ports composites du composant 5 se trouvent désormais dans -dessous montre le code (généré) relatif aux ports composites du composant 5 et la figure suivante illustre les ports incohérents. Sur la Figure 96 est constitué par ce port composite. Page 167

168 Figure 96 : Calcul des objectifs fonctionnels avant la reconstruction A la fin du ca donnée pour chaque composant mort. Dans cet exemple, le composant comp24 Comp22 est réutilisé dans 50% des cas. Le composant comp27 est toujours réutilisé (100% des cas). Le composant comp4 est réutilisé dans 25% des cas. Cas 2 : on supprime le composant comp22 Page 168

169 Figure 97 : Le composant Comp22 est désigné comme composant cible - sont alors calculés. Dans cet exemple, seul le composant comp0 contient des ports composites incohérents. La figure ci-dessous illustre le code concernant les ports composites du composant comp0. Figure 98 : Calcul des objectifs fonctionnels avant la reconstruction Page 169

170 6.5 EXPERIMENTATIONS Nous avons effectué des tests sur une machine Dell Intel Pentium 4 (CPU 3GHz, 2Go de RAM). Ils ont été réalisés à partir de référentiels de composants obtenus à partir de notre générateur présenté dans la section 6.3. de taille variable tel que les composants qui y sont stockés possèdent certaines caractéristiques ainsi Ci-dessous figure la liste des paramètres sur lesquels il est - nombre de composants dans le référentiel de composants, - nombre de générées, - nombre d'interfaces générées, - nombre moyen de ports primitifs par composant, - nombre maximal de ports composites par composant, - nombre maximal de ports primitifs par port composite, - nombre maximal par interface, - nombre maximal d'interfaces par port primitif, -. Nous présentons dans les deux sections suivantes des tests en rapport avec la construction automatique ections 6.4.2) ainsi que des tests en rapport avec -à-1 (section 6.4.3) CONSTRUCTION AUTOMAT E COMPOSANTS Nous présentons dans les deux sections suivantes deux suites de tests A et B dont le but est de montrer les performances obtenues en fonction des stratégies et heuristiques employées. La suite de tests A est une estimation des gains comparés moyens alors que la suite de tests B consiste à comparer les gains sur des problèmes identiques. Page 170

171 Suite de tests (A) expérimentations réalisées et présentées dans cette section est de donner un ordre de grandeur du gain qui existe entre certaines stratégies et heuristiques. Nous avons réalisé les tests dans des contextes (i.e. nombre de composants dans le référentiel, nombre moyen de ports primitifs, etc.) adaptés qui permettent de donner une idée de la contribution des stratégies et des heuristiques. Dans la 1800 secondes (30 minutes) a été interrompue : la valeur 1800 dans les graphiques et tableaux suivants identifie ces cas de figure. Le Branch-and-bound (BB). Le principe de BB est recherche pour y trouver tous les assemblages de taille minimale. BB permet ainsi de couper des branches d blage de taille minimale trouvé Des séries de tests ont été réalisées sur des référentiels de composants ayant les caractéristiques suivantes : - nombre de composants dans la base de composants : 10 à 20, - nombre moyen de ports primitifs par composants : 5 à 10, - nombre maximal de ports composites par composant : 2 à 6, - nombre maximal de ports primitifs par port composite : 5. Le graphique présenté sur la Figure 99 résume les écarts moyens qui ont été constatés entre Research- All et BB. Par exemple, lorsque Research-All met 300 secondes BB met 2 secondes. Dans ce contexte, BB permet un gain supérieur à 150 par rapport à Research-All. Figure 99 : Comparaison de Research-All et de Branch-and-bound La prediction (LA). LA consiste à essayer de prédire les situations aucune chance de fournir une solution minimale. Des tests ont été réalisés dans différents contextes sur des référentiels de composants ayant les caractéristiques suivantes : Page 171

172 - nombre de composants dans la base de composants : 15 à 30, - nombre moyen de ports primitifs par composants : 5 à 15, - nombre maximal de ports composites par composant : 2 à 15, - nombre maximal de ports primitifs par port composite : 5 à 10. possible car LA apporte une amélioration substantielle des performances, mise en évidence sur des problèmes difficiles. Le graphique présenté sur la Figure 100 résume les écarts moyens qui ont été mesurés entre BB et BB+LA. Lorsque BB atteint 1600 secondes, BB+LA prend 67 secondes. Dans ce contexte, LA permet un gain supérieur à 75 par rapport à BB. Figure 100 : Comparaison de Branch-and-bound, de Look-Ah Afin diction, nous avons réalisé des tests qui permettent de comparer une version beta (LA_beta) de la prédiction à la version évoluée (LA) de la prédiction. Ces séries de tests ont été réalisées sur des référentiels de composants ayant les caractéristiques suivantes : - nombre de composants dans la base de composants : 15 à 30, - nombre moyen de ports primitifs par composant : 9 à 15, - nombre maximal de ports composites par composant : 6 à 10, - nombre maximal de ports primitifs par port composite : 5 à 8. Dans ce contexte, LA permet un gain supérieur à 30 par rapport à la version LA_beta. Min-Domain (MD). encore plus inutiles. Concrètement, si FO-SET contient un ensemble de dépendances impossible à satisfaire, il vaut ir le plus tôt possible pour économiser du temps de calcul. Des séries de tests ont été réalisées sur des référentiels de composants ayant les caractéristiques suivantes : - nombre de composants dans la base de composants : 20 - nombre moyen de ports primitifs par composant : 9 à 19 - nombre maximal de ports composites par composant : 10 - nombre maximal de ports primitifs par port composite : 5 à 10 Page 172