Architectures Ouvertes pour l Adaptation des Logiciels

Transcription

1 Architectures Ouvertes pour l Adaptation des Logiciels Frédéric Duclos 1, Jacky Estublier 2, Rémy Sanlaville 1 Published in review Génie Logiciel And proceedings ICSSEA, Paris Dassault Systèmes C/O LSR - IMAG 220 Rue de la Chimie, Domaine Universitaire - B.P Grenoble Cedex 9 {frederic_duclos, remy_sanlaville}@ds-fr.com 2 Laboratoire Logiciels, Systèmes Réseaux - IMAG 220 Rue de la Chimie, Domaine Universitaire - B.P Grenoble Cedex 9 Jacky. Estublier@imag.fr Résumé : Les logiciels de grande taille ont de plus en plus besoin d être adaptés par le client. Chaque client a en effet ses besoins propres en terme de fonctionnalité. Pour des raisons de temps de développement et de coûts, le fournisseur ne peut pas adapter le logiciel à chaque client. Les fournisseurs de logiciels ont ainsi commencé à proposer au client diverses techniques lui permettant d adapter le logiciel à ses besoins. Nous décrivons les diverses techniques existantes pour l adaptabilité des logiciels, en partant des technologies les plus simples (API, langages de scripts, ) jusqu à des technologies aujourd hui beaucoup plus avancées et flexibles. Nous montrons ensuite une façon de combiner deux technologie permettant de couvrir complètement différents critères d évaluation de l adaptabilité. Nous étudions ensuite les choix et les résultats de la société Dassault Systèmes, leader mondial de la CAO avec son logiciel Catia V5, pour ce qui est de leurs contraintes d adaptabilité au sein de Catia. Mots clés : adaptabilité, évolution décentralisée de logiciels, composant, architecture, Dassault Systèmes. Abstract : Customers of big software have their own requirements in terms of functionality. For this reason, the software manufacturer has to provide Decentralised Software Evolution mechanisms, because it s very difficult to deliver a customised version for each client. In this paper, we show existing technologies for software adaptation which range from simple ones (API, script languages) to the present technologies based on software architecture. We show how a combination of architectural technologies allows to cover all adaptability characteristics, which are defined in this paper. We then study CatiaV5, a software form Dassault Systèmes (world leader in CAD), in terms of adaptability results. Keywords : adaptability, Decentralized Software Evolution, component, architecture, Dassault Systèmes. I. Introduction L utilisation de progiciels sur étagère (COTS) se généralisant, les clients exigent de plus en plus de pouvoir les modifier, afin de les adapter aux contraintes et besoins spécifiques de l entreprise. Or, les mécanismes habituels des langages de programmation exigent généralement d avoir, pour cela, accès au code source, ce qui n est pas possible dans le cas de COTS et évidemment pas souhaitable pour les éditeurs. De nouvelles techniques pour l adaptation décentralisée des logiciels [1] sont alors nécessaires. Ces techniques sont relativement variées. Elles vont de l utilisation d une API (Application Programming Interface) jusqu aux architectures de composants en passant par l utilisation de langages de script, de plug-ins et d architectures à événements. Elles sont souvent basées sur l utilisation d interfaces pré-définies, ce qui est le cas des APIs (ensemble fini de services), des plug-ins (ajout de nouveaux comportements via des «prises» préalablement définies) et des architectures à évènements (proposant des interfaces d événements en réception et émission). D autres techniques plus flexibles utilisent en outre les langages de script (l application possède son propre langage et interpréteur) et les architectures de composants (possibilité d enrichir les fonctionnalités et de modifier la structure des composants grâce à un langage d architecture). Certaines de ces techniques ont déjà été développées et intégrées dans des logiciels commerciaux ou non (GNU Emacs, Adobe Photoshop, Microsoft Office, Linux, Apache,...).

2 Ce besoin d adaptation d un logiciel est vécu quotidiennement par Dassault Systèmes, leader mondial de la CAO avec son logiciel CATIA V5. Les clients de Dassault Systèmes doivent pouvoir étendre et adapter CATIA à leur métier : aéronautique, automobile, biens de consommations,... Dassault Systèmes a donc été amené à définir de nouveaux mécanismes permettant à ses clients d étendre des composants existants sans pour autant modifier ni disposer du code source. De plus, pour résoudre des problèmes d ingénierie concurrente, Dassault Systèmes a été amené à utiliser ses propres techniques en interne. La taille du logiciel (plus de 4 millions de lignes de code) et le nombre de développeurs (plus de 1000 ingénieurs) font qu il n est pas possible de recompiler toute l application à chaque modification du code. Dassault Systèmes a donc appliqué ses mécanismes d adaptation dans son processus de développement ; ce qui a permis de créer des techniques de compilation incrémentales avec des délais acceptables. Utiliser en interne des mécanismes offerts à ses clients est d ailleurs un très bon critère pour juger de la qualité, de la souplesse et de la fiabilité de ces mécanismes. Ce papier expose la problématique de l adaptation décentralisée des logiciels, pour cela, nous présentons les conventions, hypothèses et les critères choisis pour évaluer l adaptabilité dans la section 2. Ensuite, la section 3 présente un état de l art sur les mécanismes d adaptation actuels. La section 3 introduit en outre les mécanismes d adaptation basés sur l architecture du logiciel et plus particulièrement une manière de combiner deux technologies basées autour des architectures ouvertes pour couvrir tous les critères fixés dans la section 2. La section 4 présente les solutions adoptées par Dassault Systèmes par rapport à cet état de l art. Ce papier cherche à montrer en quoi les recherches sur les architectures logicielles contribuent à l adaptation. Il suggère aux éditeurs l emploi de techniques d architectures ouvertes afin de rendre leur produit facilement adaptable par leurs clients, sans pour autant dévoiler leur code source. 2. Conventions et hypothèses Dans la suite de l article, nous allons présenter différentes technologies. Pour cela, nous nous baserons sur des conventions et hypothèses que nous décrivons ci-dessous : 2.1. Hypothèses - Un logiciel est composé de composants pouvant communiquer entre eux. Ces composants peuvent être compilés de manière indépendante. - Un composant est constitué de sous-composants et déclare implémenter différentes interfaces, - Un composant élémentaire correspond à un morceau de code fournissant des services pour implémenter les interfaces associées, - Une interface correspond à un contrat de service entre une application cliente et un composant serveur, elle est composée de fonctions (méthodes) publiques. - Nous nous plaçons du côté du client qui souhaite modifier le comportement du logiciel. Le client peut avoir écrit ses propres composants, dans lesquels sont codés les nouveaux comportements souhaités par le client. - Le client n a pas accès au code source des composants du fournisseur, ceci pour des raison de confidentialité dans un contexte industriel. Le modèle de composant proposé possède des points en commun avec COM [4] et Corba Components [5], notamment dans le sens où chaque composant est compilé de manière indépendante. Ce modèle n est certes pas universel mais il est suffisamment général pour notre propos Critères de classification Nous classifierons les diverses technologies selon leur capacité à fournir les services suivants. Module et composant 1. Ajout d un composant client : Le client est il capable de rajouter ses propres composants, 2. Remplacer un composant par un autre : Le client peut-il substituer certains composants par les siens, 3. Retirer un composant, incluant ses liens avec les autres composants : Le client peut-il supprimer des fonctionnalités initialement offertes par le fournisseur, 4. Ajouter / retirer / rediriger un lien entre deux composants client ou fournisseur : Le client est-il autorisé à modifier en profondeur l architecture globale du logiciel en jouant sur les liens inter-composants,

3 Interface 5. Ajout d interface, 6. Retrait d interface. Fonction 7. Ajout retrait de fonctions dans une interface 8. Enrichissement du comportement d une fonction Convention des schémas Soit un produit logiciel, et ses composants représentés par des rectangles. Les interfaces sont représentées par un rond et une barre la liant à un composant. La couleur grise représente les parties du logiciel dont l architecture ou le code source sont invisible au client, cela représente en fait ce qui vient du fournisseur ; les parties en blanc sont développées par le client. Interface Logiciel Composant (client) Composant (fournisseur) 2.4. Terminologie. On parle d évolution lorsque c est le concepteur/réalisateur du logiciel qui effectue la modification. On parle de customisation lorsque la modification est réalisée exclusivement au moyen de l API du logiciel et/ou en exploitant les diverses options fournies. On parle d adaptation lorsque le client modifie le comportement du logiciel pour l adapter à ses besoins, au moindre coût. On s intéresse essentiellement à l adaptation dans cet exposé. En effet, la customisation est souvent trop limitée, et l évolution ne concerne que ceux qui connaissent très bien le code, et qui donc vont certainement le modifier, chose que le client ne doit pas pouvoir faire. L adaptation est donc un compromis entre l évolution, qui exige le code source et son expertise, mais permet une très grande liberté et une efficacité de la solution, et la facilité mais les limitations de la customisation. Bien sûr, l entreprise productrice du logiciel peut elle même utiliser les mécanismes d adaptation qu elle fournit aux clients. C est d ailleurs un très bon critère pour juger de la qualité, de la souplesse et de la fiabilité d un mécanisme d adaptation. 3. Etat de l art sur les techniques d adaptation 3.1. Application Programming Interface (API) Une API correspond à un sous-ensemble de toutes les interfaces des composants du logiciel. Le client ajoute des composants qui utilisent ces interfaces.

4 composant client Seul le point 1, ajout d un composant client, est satisfait. Le logiciel n est en aucune façon modifié, le client n a aucun accès à l architecture interne du logiciel du fournisseur, il se contente de l utiliser. La marge de manœuvre est très faible Langages de Scripts. Un langage de script est un langage spécifique d un domaine pour implémenter des «add-on». Composant Client Interpréteur de Script Le mécanisme est le même que pour les APIs ; les possibilités d adaptation sont les mêmes mais le client dispose d un langage mieux adapté : seul le point 1 est couvert Les «plug-ins» ou «framework» Le logiciel livré, appelé framework, s attend à ce que des composants clients (appelés plug-in ) fournissent des interfaces prédéfinies, que le logiciel utilisera selon un protocole prédéfini. En général le logiciel ne dispose pas d un moyen général pour découvrir des interfaces additionnelles que le plug-in pourrait offrir, ni un mécanisme général pour définir le protocole de liaison et d utilisation de ces nouvelles interfaces. Le client ne peut que lier ses plug-ins aux interface prédéfinies du logiciel. Le pattern «visiteur» [3] rentre dans ce cadre. Plug In Le points 1 est couvert : De la même façon qu avec les APIs, le client est capable de rajouter ses propres composants. L adaptation est dans ce cas encore très minime, c est le logiciel qui offre cette ouverture, la marge de manœuvre est donc encore très faible Les architectures à événement Le logiciel fournit une interface d évènements qui décrit les messages reçus et interprétés par le logiciel et ceux qui en sont émis en direction des composants client. Selon les services fournis par le serveur d événement, on pourra rediriger, inhiber, modifier les liens entre des composants clients et le logiciel.

5 Serveur d événement Par exemple, un événement envoyé par le client (6) pourra : - être interprété et redirigé sur les interfaces du logiciel (1 et 2), nous sommes alors dans le même cas que l API, - pourra être envoyé à un composant particulier (4), le module du client se fait passer pour le composant envoyant l événement (3), nous sommes donc dans le cas du remplacement d un composant par un module, L événement (5) envoyé par le logiciel pourra, selon la politique du serveur d événement : - être redistribué au composant client, nous sommes alors dans le cas du plug-in, - être inhibé, nous sommes alors dans le cas où les composants destinataires de cet événement sont supprimés du logiciel, au moins en ce qui concerne cet événement. Ainsi, le serveur d événement offre la possibilité de court-circuiter et de traiter les communications événementielles entre les composants fournisseurs et clients. L adaptation dans ce cas est donc possible, mais elle est encore limitée car le client ne possède pas forcement le contrôle sur le serveur d événement et il ne peut agir que sur un sous-ensemble des communications. Cette architecture peut ainsi satisfaire les points de 1 à Adaptation dans une architecture à composants ouverte. Nous présentons ici une autre approche liée à l architecture à composants décrite dans la section 2. L idée de travailler au niveau architecture logicielle n est pas récente[6] [7], elle est appliquée ici à l adaptation. Nos diagrammes ne montrent plus le niveau logiciel / Composants Fournisseur / Composants Client, mais le niveau Composants Fournisseur / Composant Client / Sous-Composants. Ici, le composant doit être vue comme une couche permettant d administrer différentes unités logicielles. Ici, nous supposerons que le client peut avoir la connaissance du contenu des composants et des connections entre leurs sous-composants ; il peut ainsi connaître l architecture du logiciel, i.e. de tout ou partie des composant qui constitue ce logiciel. L ouverture de l architecture à composant permet de modifer la structure interne d un composant (présence des sous-composants, liaisons internes entre les sous-composants, ) L extension Le composant du fournisseur (en gris) est enrichi d une ou plusieurs interfaces implantées par un ou plusieurs composant client (en blanc). Ainsi, nous obtenons un nouveau composant qui propose les mêmes interfaces qu initialement complétées par celles du ou des composants clients. Le composant obtenu peut ne pas exposer toutes les interfaces de ses constituants, ces choix sont fait au moment de la définition de l architecture ; le client peut alors masquer certaines interfaces. Enfin, le module extension peut avoir connaissance des sous-composants pour communiquer éventuellement avec eux (lien en pointillé).

6 L extension satisfait les points 1 et 5 car elle permet d ajouter un module, de retirer des fonctionnalités, et par ce biais, d ajouter une ou plusieurs interfaces. Délégation Un composant propose l interface déléguée (Délégation) sans fournir, par défaut, le code exécutif correspondant. Le choix du composant devant exécuter les services de cette interface peut être fait dynamiquement. Le schéma suivant montre en pointillé un lien défini dynamiquement pour lier une interface à un composant, dans ce cas, extérieur au composant délégant l interface. La délégation couvre les critères d adaptation 1, 2, 3 et 4 : ajout de composant client, remplacement d un composant fournisseur par un composant client dans le cas où un composant avait déjà été désigné pour effectuer les services ; retirer un composant en annulant le lien de délégation et enfin, modification de lien entre composants Le wrapping Un wrapper est un composant client qui s insère en amont des composants fournisseurs et qui constitue un nouveau composant. Les interfaces fournies peuvent être les mêmes ou être différentes de celles du composant original. Un wrapper tel que défini ici implique une capacité à définir un nouveau composant, si ce n est pas le cas, on est ramené au point 1 : Usage d une API. Wrapper Les points 5 et 6 sont satisfaits car le Wrapper permet d ajouter / supprimer des interfaces.

7 Architecture ouverte Le client est habilité à constituer de nouveau composants en ajoutant ses propres sous-composants (en blanc), en substituant les composants, en modifiant les liens internes etc. Il n est pas habilité, par contre, à modifier le contenu des constituants élémentaires ni des interfaces existantes, le code source du fournisseur n étant pas accessible. A notre connaissance, il n existe pas d exemple complet d architecture ouverte. L approche peut être «statique» i.e. on dispose de l architecture du logiciel définie dans un langage d architecture ; on modifie cette description et on recompile le tout. Cela peut être «dynamique» si on dispose en plus d un interpréteur architectural. Les points 1, 2, 3, 4, 5 et 6 sont couverts : L architecture ouverte permet de rajouter des composants clients, de remplacer, retirer des composants, de modifier les liens entre les composants / modules et d ajouter ou retirer des interfaces. Interfaces actives. L interface est «programmable», et le client, pour chacune des méthodes de l interface du logiciel peut ajouter un appel (call-back) vers ses propres composants, avant et/ou après l appel. La méthode du client peut alors analyser les arguments et les modifier, rediriger l appel vers une autre méthode, refuser l appel, exécuter des actions avant / après etc. Ce modèle est proche du modèle avec serveur d événements mais le choix des politiques de gestion des messages est donné à celui qui implémente l interface active, le client peut donc obtenir ce pouvoir. L interface active ressemble aussi fortement au pattern «Proxy» [3]. Pre M1 () Post Interface Active. Dans cet exemple, seule la méthode M1 de l interface est enrichie (active). Nous avons donc la possibilité de diminuer la granularité au niveau de la méthode. Nous notons que l interface active peut être réalisée dynamiquement en Java grâce à la classe java.lang.reflect.proxy associée à l interface java.lang.reflect.invocationhandler. Les points 7 et 8 sont couverts du fait de la granularité de l adaptation permise, mais le logiciel reste un paquet monolithique, les composants substitués restent présents même s ils ne sont pas appelés. Ce modèle est aussi très proche de celui des Wrappers. Une grande différence subsiste tout de même : Du point de vue d une application cliente, le composant est toujours le même, sa structure n est pas modifiée. Dans le cas

8 des wrappers, un nouveau composant est créé, sans proposer forcement les mêmes interfaces que le composant original, l application cliente doit en être informée. Interface active et architecture ouverte Si l approche interface active est combinée avec celle de l architecture ouverte, nous obtenons une architecture permettant de couvrir tous les critères d adaptabilité définis dans le paragraphe 2. Le logiciel peut être profondément adapté et optimisé bien que le code source de l application reste caché. Cette approche doit être complétée de mécanismes de sécurité, en tout cas pour être utilisé au niveau industriel, car mal contrôlée, elle peut être très permissive. 4. L adaptation chez Dassault Systèmes : Dassault Systèmes (DS) est le leader mondial de la CAO avec son logiciel Catia. Celui-ci est distribué auprès de plus de clients représentants des métiers très différents (mécanique, hydraulique, électronique, ). Chaque client souhaite adapter Catia pour ses propres exigences en terme de fonctionnalités (design, analyse, simulation, ). DS est donc très fortement confronté à ce besoin d adaptation pour Catia afin de répondre à cette diversité dans les exigences des clients. Lors de la récente sortie de la version 5 de Catia, DS a offert un tel mécanisme à ses clients. DS a choisi le modèle «Extension» décrit précédemment car il permet de satisfaire les contraintes d adaptabilité tout en gardant un grand contrôle sur l architecture globale. En effet, ce mécanisme permet en même temps de maintenir l architecture dans un état stable [2] tout en laissant une grande flexibilité aux clients. Nous avons vu que l Extension satisfaisait aux critères 1 et 5 ; le client peut rajouter ses propres composants et interfaces (cf figure ci-dessous). En outre, il ne peut pas, dans ce modèle, satisfaire les critères 2, 3 et 4 : remplacer un composant, retirer un composant et modifier les liens entre les composants. Par contre, d autres mécanismes comme la délégation et une forme d interface active sont offerts afin de répondre à ces manques. Catia est un logiciel complexe et de grande taille (plus de 4 millions de lignes de code) avec un développement coopératif fort (1000 ingénieurs). Ceci a poussé DS à utiliser ces mécanismes d adaptation en interne. Après plusieurs années d utilisation, les résultats ont été à la hauteur des espérances. La figure ci-dessous illustre l utilisation du mécanisme d extension par deux clients de DS. Chacun d entre eux adapte le composant fourni par DS pour son propre métier : l avionique pour Boeing et l automobile pour Chrysler. DS Component i DS site DS Component i DS Component i Boeing Extension Boeing Interface Chrysler Extension Chrysler Interface Chrysler Interface Boeing site Chrysler site

9 5. Conclusion Un même logiciel étant utilisé par de nombreux clients de métier différents, il est évident que ceux-ci souhaitent l adapter à leurs propres besoins. Il a donc fallu créer divers mécanismes afin de répondre à cette attente. Au cours du temps, ceux-ci se sont améliorés afin de fournir toujours plus de flexibilité au client. Ces mécanismes vont du simple appel des fonctionnalités offertes par l application (API, langages de scripts, ) jusqu à des modèles où l architecture de l application intègre les composants du client (plug-ins, extension, architecture ouverte, ). Nous avons montré les différentes technologies, en correspondance avec leur degré et leur granularité d adaptabilité. L adaptabilité permet une meilleure flexibilité pour le client, une meilleure réutilisation des composants existants tout en préservant un degré de sécurité suffisant. Nous avons montré les nouvelles approches basées sur l ouverture de l architecture ; approches très prometteuse qui n a pas encore été beaucoup expérimentée tant au niveau académique qu industriel. DS a été précurseur dans ses choix de technologies pour l adaptation. Les résultats de CatiaV5 montrent la pertinence, la viabilité et la nécessité de ces technologies. Il semble donc clair que les clients seront de plus en plus exigeants quant à la personnalisation des logiciels, autant au niveau du degré d adaptabilité recherché qu au niveau de la facilité d adaptation. L adaptabilité sera un challenge toujours plus important pour les entreprises productrices de logiciels. 6. Références : [1] Peyman Oreizy, Decentralised Software Evolution ; International Workshop on the Principles of Software Evolution (IWPSE1) ; Kyoto, Japan, April 20-21, 1998 [2] Peyman Oreizy, Richard N. Taylor : Coping with Application Inconsistency in Decentralized Software Evolution ; International Workshop on the Principles of Software Evolution (IWPSE2); Fukuta, Japan, July [3] E. Gamma, R. Helm, R. Johnson, J. Vlissides : Design Patterns ; Addison-Wesley, 1995 [4] Thuan L. Thai : Learning DCOM ; O Reilly, 1999, isbn [5] Object Management Group. Corba Components, ; August 2, 1999 [6] D. E. Perry, A. L. Wolf ; Foundation for the study of software architecture ; Software Engineering notes, vol 17, no 4, October 1992 [7] D. Garlan. Software Architecture: a Roadmap. In A. Finkelstein, editor, The Future of Software Engineering, 22 nd International Conference on Software Engineering (ICSE 2000), , Limerick, Ireland, June 2000.