Le composant est une unité de calcul ou de stockage à laquelle est associée une unité d’implémentation. Il peut être simple ou composé et se décompose en deux parties. L’extérieur qui correspond à son interface ; comprend la description des interfaces fournies et requises par le composant, et définit les interactions du composant avec son environnement.
La seconde partie, correspondant à son implémentation, permet la description du fonctionnement interne du composant [LEG 09]. Le composant est aussi au même titre que l’objet, un paradigme de programmation pour la conception et l’implémentation des systèmes logiciels.
1.1.1 Définition et Défi
Le CBSE ((Component-based software engineering) appeler aussi component-based development (CBD)) est une branche de la technologie de programmation, et aussi est une approche de séparation des préoccupations. Son but est de développer les systèmes logiciels en composant les composants réutilisables à un niveau plus fin de granularité que les applications [LEG 09]. Naturellement, ces composants ont besoin des standards pour l’interaction et la composition.
Le défi de CBSE est de définir des modèles de composants avec de tels standards et de fournir des implémentations des modèles de composants associées pour permettre à des composants et des application à base de composants d‟être conçu, d‟être mis en application, et d‟être déployés [LEG 09].
1.1.2 L’ingénierie des logiciels basée composant et la séparation des préoccupations
Selon le paradigme de séparation avancée des préoccupations, un système est un ensemble de préoccupations fonctionnelles et extra-fonctionnelles (aspects). Les préoccupations fonctionnelles sont les fonctionnalités métiers que le système doit assurer, alors que les préoccupations extra-fonctionnelles sont des services dont le système a besoin pour effectuer ses fonctionnalités métiers.
Comme exemple de préoccupations extra-fonctionnelles, on peut citer la sécurité, la synchronisation, la gestion de la persistance, etc. Dans les approches de développement de logiciels, notamment dans le cas de la programmation orientée objet, il apparaît que les deux types de préoccupations sont enchevêtrés et le code relatif aux préoccupations extra-fonctionnelles est éparpillé dans le code fonctionnel.
Cette situation augmente la complexité, empêche la réutilisation et gêne l‟évolution des systèmes. La séparation avancée des préoccupations permet de séparer les parties extra-fonctionnelles des parties fonctionnelles d‟un système. L‟objectif escompté étant d‟offrir une meilleure réutilisation, faciliter la maintenance, réduire la complexité des systèmes et augmenter leur évolutivité.
Parmi les approches les plus utilisées, Nous citons : la programmation orientée aspect, la composition de filtres et la séparation multidimensionnelle des préoccupations. L‟ingénierie des logiciels basée composant fait une séparation des préoccupations du système en des entités clairement définies, appelées composants. Ces composants réutilisables sont définis et composés ensemble.
Cependant, cette décomposition entraîne l‟éparpillement de certaines préoccupations dans différents composants du système; ces préoccupations, qu‟on qualifie d‟entrecoupantes, empêchent la réutilisation, la maintenance et l‟évolution des composants, et par conséquent, l‟évolution du système [MES 08]. La séparation avancée des préoccupations de son côté, propose des approches offrant des mécanismes qui permettent de séparer les préoccupations entrecoupantes des préoccupations métiers [MES 08].
La combinaison de l‟approche basée composant et de la séparation des préoccupations permet un développement rapide des systèmes, basé sur des composants certifiés et dont les préoccupations non fonctionnelles sont factorisées en dehors de ces composants, ce qui permet d‟avoir des systèmes évolutifs, et maintenables [MES 08].
1.1.3 De la programmation oriente objet vers la programmation à base de composant
Le génie logiciel vise à la définition et l’application de méthodes et l’utilisation d’outils pour la production du logiciel et de son suivi. Les techniques de programmation évoluent pour tenir compte de la complexité et de la taille croissante des systèmes logiciels développés et des nouvelles exigences en termes de qualité et de fiabilité.
La programmation par objets, qui a émergé depuis une vingtaine d’année [LEG 09], s’est ainsi imposée comme une évolution majeure par rapport à la programmation procédurale pour répondre à ces exigences avec des langages comme Smalltalk, C++ puis Java.
Le paradigme objet apporte, en effet, de bonnes propriétés, telles qu’un niveau d’abstraction plus élevé (concepts de classes et d’instances), une meilleure réutilisabilité du code et flexibilité de conception (notion de canevas logiciels avec l’héritage et le polymorphisme), l’encapsulation des données et du comportement avec la possibilité de séparer les interfaces et l‟implémentation [LEG 09].
Cependant, l’objet n’est pas suffisamment abstrait et reste à un niveau de granularité trop fin pour maitriser aisément la structuration des systèmes complexes; structuration notamment nécessaire à leur maintenance [LEG 09]. Le concept d’architecture logicielle est ainsi défini comme :
« L’architecture d’un système logiciel définit le système en terme de composants et interactions entre ces composants. Les exemples des composants incluent des clients, des serveurs, des filtres et des couches d’un système hiérarchique.
Les interactions entre les composants peuvent se composer des appelles de procédures, des variables partagées, et des événements asynchrones» [RlK 99]. La prise en compte des limitations de l’approche objet pour la conception et l’implémentation des architectures logicielles et le besoin d’une structuration à granularité variable, éventuellement à grosse granularité suivant le principe du « programming in the large » [LEG 09], ont mené à la création d’un nouveau paradigme de programmation : le composant.
Le concept de composant logiciel est relativement ancien [LEG 09]. Il est décrit comme une brique logicielle composable et facilement réutilisable, d’où l’appellation de composant sur l’étagère (Composant Off The Shell ou COTS). Il n’existe pas de réel consensus pour définir le composant. Pour Szyperski [SZY 02], un composant est ainsi « une unité de composition dont les interfaces et les dépendances contextuelles sont spécifiées sous forme de contrats explicites. Il peut être déployé indépendamment et peut être composable par des autres composants ».
Pour Heineman et Council [HEI 00], un composant « est un élément logiciel conforme à un modèle appelé modèle de composants qui définit des standards de composition et d’interactions ». Un modèle de composant est habituellement indépendant de tout langage d’implémentation. L’implémentation d’un modèle fournit un environnement dédié au support de l’exécution des composants conformes au modèle.
L’apport des composants par rapport à l’objet est notamment une plus grande modularité et facilité de réutilisation grâce à une encapsulation plus forte (notion de boîte noire) et un couplage plus faible entre entités logicielles avec une représentation explicite des dépendances requises et fournies.
La séparation des préoccupations entre architecture logicielle et implémentation est un point fort de la programmation par composants pour mieux structurer les logiciels sous forme d’assemblage de briques logicielles.
Le cycle de vie du logiciel peut ainsi être plus clairement décomposé en des phases de conception de l’architecture, de développement du code métier des composants, du déploiement de ces composants et enfin de leur exécution.
1.1.3.1 Composants et objets
Il n’étonne pas que les composants sont souvent liés aux objets, et parfois, le terme composant est simplement employé comme synonyme pour l’objet. Cependant, les concepts de composants et des objets sont indépendants, bien que la plupart des modèles sont basés sur des concepts orientés objet. Pour éviter plus de confusion, nous caractériserons brièvement les objets et les composants et décrirons leurs différences. Selon [LEG 09] les objets sont des entités qui encapsulent l’état et le comportement et ont une identité unique.
Le comportement et la structure des objets sont définis par des classes. Une classe atteint des objectifs multiples; d’abord, elle met en application le concept d’un type de données abstrait ADT (Abstract Data Type) et fournit une description abstraite du comportement de ses objets [LEG 09]. Les noms de classe sont souvent utilisés comme nom de type dans les systèmes fortement typés.
En second lieu, une classe fournit l’implémentation du comportement d’objet. Troisièmement, une classe est utilisée pour créer les objets, c.-à-d., instances de la classe.
Presque tous les modèles de composants modernes sont basés sur le paradigme de programmation orienté objet. Les principes de base de l’orientation objet est de construire des programmes par des ensembles d’objets agissants l’un sur l’autre et collaborant entre eaux.
Ceci ne change pas avec des approches basées composant. Les composants sont semblables aux classes. Comme les classes, les composants définissent le comportement d’objet et créent des objets. Les objets créés au moyen de composants s’appellent les instances de composants. Les composants et les classes font la mise en application de leur fonctionnalité par des descriptions abstraites de comportement appelées les interfaces [LEG 09].
À la différence des classes, l’implémentation d’un composant est généralement complètement cachée et parfois disponible seulement en forme binaire [LEG 09]. Intérieurement, un composant peut être mis en application par une classe simple, des classes multiples, ou même par des procédures traditionnelles dans un langage de programmation non orienté objet.
À la différence des classes, les noms des composants ne peuvent être utilisés comme noms de type [LEG 09]. Au lieu de cela, le concept du type (interface) et le concept de l’implémentation sont complètement séparés. En conclusion, la distinction la plus importante est que les composants logiciels se conforment aux standards définis par un modèle de composant.
1.1.4 Le Problème de Composant logiciel
Le problème le plus fondamental des composants est comment un système peut être conçu de sorte que les composants de différents fournisseurs, écrits dans différentes régions du monde et à différents temps, puissent interoperés ? Pour résoudre ce problème, nous devons d’abord trouver des réponses à ces quatre questions [MIC 11]:
Interopérabilité de base. Comment les développeurs peuvent créer leurs propres composants binaires uniques, et assurer que ces composants binaires veulent interoperer avec d’autres composants binaires établis par différents développeurs ?
Versioning. Comment un composant de système peut être amélioré sans exiger que tous les composants de système soient améliorés ?
L’indépendance de langage. Comment les composants écrits en différentes langages peuvent communiquer ?
Interopérabilité transparente d’interprocessus. Comment nous donnons aux développeurs la flexibilité d’écrire des composants à exécuter dans un même processus ou dans un processus différent dans la même machine, ou dans une machine différente, en utilisant un modèle de programmation simple ?
Page suivante : 1.2 Modèles de Composants
Retour au menu : UTILISATION DES SCRIPTS POUR LE DEVELOPPEMENT DES COMPOSANTS COM ADAPTABLES