Chapitre 2 Techniques de configuration de composants

1- Limites de programmation OO

• beaucoup de tâches doivent être gérées manuellement

• définition des instances

• références directes entre les instances + appels explicites de méthodes

• gestion des dépendances entre classe

• structure des applications peu lisible ( = ens. de fichiers )

• évolutions/modifications difficiles

• changement de modes de communication

• évolution, ajout, suppression de services systèmes

• assemblage

• déploiement ( => installation ) • peu ou pas d’outils pour installer les exécutables
sur les différents sites

Limites du développement sur mesure

Avantage Très spécifique, très bien adapté quand ça marche

Inconvénients

Très coûteux

• Temps de développement considérable Solution sous-optimale par manque de

spécialistes

• Il faut tout maîtriser : la partie « métier » et les parties « techniques »

Manque d’interopérabilité Nécessite de redévelopper • Même des parties de

programmes déjà écrites dans des contextes différents

Exemples Logiciels pour les administrations

Limite des logiciels standard

Avantages Temps de mise sur le marché plus court Juste à configurer Produit
acquis

• maintenance, évolution à la charge du « vendeur »

Inconvénients Réorganisation locale du « business » (adaptation)

Les concurrents ont aussi accès aux fonctionnalités

Adaptabilité aux besoins limitée

Introduction à la programmation orientée composant

INTRODUCTION

La notion de réutilisation n’est pas nouvelle. Depuis le début de la programmation, on

cherche à réutiliser ce qui a été déjà fait afin de le combiner, de l’intégrer. Les
méthodes de réutilisation varient et se simplifient. En effet, au départ, le seul moyen
de réutiliser du code était de le recopier dans notre programme. Puis sont apparues
les premières bibliothèques de fonctions suivies des bibliothèques de classes. Mais
depuis 95, l’émergence des composants logiciels permet une réutilisation plus simple
et efficace grâce à ses interfaces et protocoles..

La notion de composant est ainsi apparue comme fondamentale pour résoudre les
problèmes posés grâce à ses bonnes caractéristiques qui complètent celles de la
notion d’objet.

3. Définition d’un composant

Le développement du modèle d’application par assemblage (interconnexion) de

composants logiciels apparaît comme une évolution nécessaire, face à la complexité
croissante des systèmes d’informations, aux besoins accrus des utilisateurs en
matière d’évolutivité, d’adaptation et de réutilisation.

La notion de composant a émergé dans le courant des années 90. Elle répond à des
préoccupations, essentiellement pratiques, et vise à pallier des insuffisances du
modèle à objets. Ces insuffisances sont apparues notamment dans le domaine de la
conception et de l’administration de systèmes ouverts, à grande échelle (« dans le
large »).

La notion de composant fait l’objet de multiples définitions informelles

Un composant est un morceau de logiciel assez petit pour que l'on puisse le créer, le
maintenir et en assurer le support. Il est également doté d'interfaces standards pour
pouvoir intéropérer. [Jed Harris 1995]
A software component is a unit of composition with contractually specified interfaces
and explicit context dependencies only. A software component can be deployed
independantly and is subject to composition by third parties. [Szyperski 1996]

au delà de leurs différences, semblent converger vers quelques caractéristiques

distinctives, motivées par un objectif global de réutilisation:

* La modularité : Pour faciliter la composition, la notion de composant conserve et

étend le principe de modularité à la base des modèles à objets. Ainsi, dans le cadre
d’une conception, un composant sera vu et manipulé à travers des interfaces

: + Une interface fournie: qui, à l’instar de l’interface d’un objet, définit les services, la
fonctionnalité, assurés par le composant. Un composant peut fournir une ou
plusieurs interfaces, correspondant à une ou plusieurs « vues » du service rendu par
le composant.

+ Une interface requise : destinée à faciliter la composition, l’interconnexion du

composant à d’autres composants, dans le cadre d’une architecture logicielle. Cette
interface permet de spécifier à l’extérieur du composant les services utilisés par le
composant, ce qui permet de considérer les composants comme des boîtes noires,
lors de la conception.

3.1 Notion de séparation Interface – Implantation

+ la séparation entre les aspects fonctionnels, réalisés par le composant et les

aspects non-fonctionnels, c’est-à-dire l’ensemble des services (interconnexion,
services système, ...) utiles à la mise en oeuvre de la logique applicative. Cette
séparation va permettre une conception « générique » des composants
indépendante des services nécessaires à leur bon fonctionnement, puis une
intégration de ces services à partir d’une spécification déclarative des besoins du
composant en terme de services, d’aspects non-fonctionnels. Ces services sont
généralement mis en oeuvre par un conteneur qui encapsule le composant et
intercepte puis interprète les appels aux services réalisés par le composants lui-
même. Les composants réutilisables sont intéressants parce qu’ils facilitent le
développement rapide d’application. Un développeur peut assembler une application
à partir de composants prédéfinis, plutôt qu’à partir d’un amas de composants.

Interface = ensemble d’opérations publiques •

 La séparation Interface – Implantation permet de

 Caractériser le protocole d’accès à un composant logiciel indépendamment de
son implantation
 Réaliser plusieurs implantations de la même interface
 Favoriser la substitution d’implantations
3.2 Notion de port

Un composant est donc une boite noire que l’on peut utiliser pour construire des
applications en connectant les interfaces clientes aux interfaces serveuses.

Le port permet de dissocier le composant de son environnement (les autres

composants). Un port est sommairement un sous-ensemble d’interfaces fournies ou
requises par son composant. Il permet d’associer cet ensemble de fonctionnalités `a
un rôle précis. Les autres composants se brancheront `a un port `a cause d’un
besoin d’un certain rôle. Le composant est relégué au statut de « conteneur de rôles
». Le port est seulement le carré posé sur le bord du composant (il peut se trouver `a
l’intérieur du composant pour indiquer que le port n’est pas visible de l’extérieur).
L’ensemble des interfaces requises sont regroupées dans une seule branche, idem
pour les interfaces fournies, cela permet de savoir si le port est unidirectionnel ou
bidirectionnel. La notion de port permet d’abstraire les collaborations. Ainsi, au lieu
d’avoir des composants qui collaborent au travers d’un ensemble de fonctionnalités,
nous avons des composants qui collaborent en fonction de leurs rôles. Le
développement d’applications par composants est fortement simplifiée car le niveau
d’abstraction est ´élevé.

3.4 Notion de connecteur

Lorsque les données échangées par deux composants ne sont pas compatibles,
ou bien que les types et signatures des méthodes ne correspondent pas,
le développeur a la possibilité de placer un connecteur entre les deux composants
qui se chargera d’adapter la collaboration. On peut voir cela comme un composant
supplémentaire dont l’unique rôle serait de traduire les appels d’un composant dans
le format de l’autre, et vice-versa.

3.5 Notion de configuration

3.5.1 Architecture logicielle

Une architecture logicielle est définie comme un niveau de conception qui contient la
description des composants à partir desquels un système est construit, les
spécifications comportementales de ces composants, les modèles et les
mécanismes de leurs interactions (connecteurs) et enfin un modèle définissant la
topologie (configuration) d’un système.

3.5.2 Langage de description d’architecture : ADL

Il n'y a pas de définition officielle de ce qu'est un ADL. La définition admise est qu'un
ADL spécifie les composants d'un système, leurs interfaces, les connecteurs (lieux
d'interaction entre les composants), et la configuration architecturale. Les langages
de description d'architecture (ADLs) sont des langages formels qui peuvent être
utilisés pour représenter l’architecture d’un système logiciel. Comme l’architecture est
devenue un thème important dans le développement de systèmes logiciels, les
méthodes pour spécifier de façon non ambiguë une architecture, deviennent
indispensables.

3.5.3 Notion de configuration

Les configurations d’architecture d’application, encore appelées topologies,

définissent les propriétés architecturales de connectivité et de conformité aux
heuristiques de conception, ainsi que des propriétés de concurrence et de répartition.
Une configuration définit la structure et le comportement d’une application formée de
composants et de connecteurs. Une composition de composants, appelée dans
certains contextes composite, est une configuration. La configuration structurelle de
l’application correspond à un graphe connexe des composants et des connecteurs
formant l’application. Elle détermine les composants et les connecteurs appropriés à
l’application et vérifie la correspondance entre les interfaces des composants et des
connecteurs. La configuration comportementale, quant à elle, modélise le
comportement en décrivant l’évolution des liens entre composants et connecteurs,
ainsi que l’évolution des propriétés non fonctionnelles comme les propriétés spatio-
temporelles ou la qualité de service. Elle définit également le schéma d’instanciation
des composants au moment de l’initialisation de l’application, ainsi que le placement
des composants sur les sites au moment du démarrage du système et leur évolution
pendant la vie de l’application. Neuf caractéristiques sont précisées par Medvidovic
et Taylor pour évaluer la configuration d’un ADL. Ces caractéristiques sont les
suivantes :

- un formalisme commun,

- la composition,

- le raffinement et la traçabilité

, - l’hétérogénéité,

- le passage à l’échelle

, - l’évolution de la configuration,

- l’aspect dynamique de l’application,

- les contraintes,

- les propriétés non-fonctionnelles.

 Un formalisme commun
Une configuration doit permettre de fournir une syntaxe simple et une sémantique
permettant de - faciliter la communication entre les différents partenaires d’un projet
(concepteurs, développeurs, testeurs, architectes),

- rendre compréhensible la structure d’une application à partir de la configuration

sans entrer dans le détail de chaque composant et de chaque connecteur,

- spécifier la dynamique d’un système, c’est-à-dire l’évolution de celui-ci au cours de

son exécution.

 La composition
La définition de la configuration d’une application doit permettre la modélisation et la
représentation de la composition à différents niveaux de détail. La notion de
configuration spécifie une application par composition hiérarchique. Ainsi un
composant peut être composé de composants, chaque composant étant spécifié lui-
même de la même manière, jusqu’au composant dit primitif, c’est-à-dire non
décomposable. L’intérêt de ce concept est qu’il permet la spécification de
l’application par une approche descendante par raffinement, allant du niveau le plus
général formé par les composants et les connecteurs principaux, définis eux mêmes
par des groupes de composants et de connecteurs, jusqu’aux détails de chaque
composant et de chaque connecteur primitifs.

 Le raffinement et la traçabilité
La configuration est également un moyen de permettre le raffinement de
l’application d’un niveau abstrait de description général vers un niveau de description
de plus en plus détaillé, et, ceci, à chaque étape du processus de développement
(conception, implantation, déploiement). Ainsi il est possible, par la définition de la
configuration, de garder trace de ce qui a été fait en amont, et de créer des liens
entre les différents niveaux de description de l’application. Cette caractéristique
permet le rapprochement entre les modèles de haut niveau et le code.

 L’hétérogénéité
La configuration d’un ADL doit permettre le développement de grands systèmes avec
des éléments préexistants de caractéristiques différentes. L’ADL doit être capable de
spécifier une application indépendamment du langage de programmation, du
système d’exploitation et du langage de modélisation.

 Le passage à l’échelle
Les ADLs se doivent de proposer une modélisation de systèmes qui peuvent grossir
en taille. Il s’agit de prévoir le nombre d’instances et leur placement dans un
environnement ainsi que la dynamique de l’application.

 L’évolution de la configuration
La configuration doit être capable d’évoluer pour prendre des nouvelles
fonctionnalités impliquant une modification ou une évolution de la structure de
l’application. Elle doit permettre de faire évoluer l’architecture d’une application de
manière incrémentale, c’est-à- dire par ajout ou retrait de composants et des
connecteurs.

 L’aspect dynamique de l’application

La configuration d’une application doit permettre la modification à l’exécution de
systèmes demandant des temps d’exécution longs ou pouvant difficilement être
stoppés. Elle doit spécifier le comportement dynamique de l’application, c’est-à-dire
les changements de l’application qui peuvent arriver pendant son exécution comme
la création, ou la suppression d’instances de composants.

 Les contraintes
Les contraintes liées à la configuration viennent en complément des contraintes
définies pour chaque composant et chaque connecteur. Elles décrivent les
dépendances entre les composants et les connecteurs et concernent des
caractéristiques liées à l’assemblage de composants que l’on qualifie de contraintes
inter composants. La spécification de ces contraintes permet de définir des
contraintes dites globales, s’appliquant à tous les éléments de l’application.

 Les propriétés non fonctionnelles

Certaines propriétés non fonctionnelles ne concernant ni les connecteurs et ni les
composants doivent être exprimées au niveau de la configuration. Ces contraintes
sont liées à l’environnement d’exécution. Un ADL doit donc être capable de spécifier
ces contraintes au niveau de la configuration.

3.6 Notion de composite

3.6.1 Assemblage de composants

Un assemblage de composants consiste à lier des composants entre eux via les
ports. Une application formée de composants est un assemblage de composants.
L’élément de base de connexion est la liaison simple : elle lie un port de services
requis à un port de services offerts compatible d’un autre composant. Un port
compatible réalise une interface qui définit au moins tous les services définis par
l’interface de services réalisée par le port offert. Le connecteur permet de relier un ou
plusieurs ports, chacun sur des composants différents. Le connecteur réalise un
certain protocole de communication. Il est lié aux ports des composants via des
liaisons.

3.6.2 Architecture interne des composants

L’architecture interne d’un composant peut être de deux natures, ce qui nous fait
définir deux types de composants :

– Le composant primitif : c’est un composant “de base”. Sa structure interne n’est

pas détaillée, il est utilisé comme un seul bloc

. – Le composant composite : c’est un ´elément dont l’architecture interne est formée

de plusieurs composants. Ces composants peuvent être soit primitifs, soit également
composites. La structure interne de ce composant ne contient que des composants
et des connecteurs.

3.6.3 Composition de composants

La composition de composants résulte en un composant composite. Il s’agit de

définir de quels composants est composé le composite, comment ces composants
sont interconnectés et liés au composite. Un composite est formé de plusieurs
composants internes. Ces composants internes peuvent être interconnectés entre
eux en suivant les mêmes règles que pour un assemblage. Il existe des relations
entre les ports du composite et ceux de ces composants internes. Un port du
composite est li´e `a un port d’un des composants internes via une liaison de type
délégation. Un port de services offerts du composite est réalisé par un composant
interne au composite, le composite le délègue à un des composants internes. Un
port de services requis par le composant est un port de services requis d’un des
composants internes qui n’est pas lié à un port de services offerts d’un des
composants internes.