COSA

COSA décrit l’architecture logicielle d’un système comme une collection de composants qui interagissent par l’intermédiaire de connecteurs. Il intègre la plupart des mécanismes opérationnels inhérents à l'approche objet comme l’instanciation, l’héritage, la généricité ou la composition [OUS04].

La figure 1.12 présente le diagramme de classes du méta modèle de COSA montrant les éléments architecturaux de base qui sont les composants, les connecteurs et les configurations [SME04].

5.1.

Les composants représentent les éléments de calcul et de stockage des donné es d'un système. Chaque composant peut avoir une interface avec plusieurs ports et plusieurs services. L'interface se compose d'un ensemble de points d'interaction entre le composant et le monde extérieur qui permettent l'invocation des services. Un composant peut avoir plusieurs implémentations. Un composant peut être simple ou composé [OUS04].

Composant

5.2.

Les connecteurs définissent des abstractions qui encapsulent les mécanismes de communication, de coordination et de conversion entre les composants. Un connecteur est représenté par une interface et une glu [OUS04, AMI08]. En principe, un rôle est une interface générique d’un connecteur qui doit être lié à

Page 48

un port d’un composant. Un rôle est soit de type « Fourni » soit de type « Requis ». Un connecteur peut être simple ou composé.

Figure 1.12. Méta-modèle de COSA [OLI09]

5.3.

Une configuration possède un nom et peut avoir une interface. Cette interface décrit les informations nécessaires à la configuration, y compris les ports et les services. La configuration est définie par des composants, des interfaces et des connecteurs qui permettent les interactions entre les composants.

Configuration

Il existe trois types de connecteurs utilisés pour lier les composants et les connecteurs :

- Attachment : est un lien entre les ports d’un composant et les rôles d’un connecteur (un port de type « Fourni » doit être liée seulement avec un rôle de type « Requis », un port de type « Requis » doit être liée seulement avec un rôle de type « Fourni »).

- Binding : relie le comportement externe d’un composant (port) à une réalisation interne de ce composant (le comportement externe d’un connecteur (rôle) à une réalisation interne de ce connecteur).

– Utilisation : relie des services aux ports des composants ou aux rôles des connecteurs. Par exemple, un port fourni d’un composant est associé à un service fourni de ce composant et un port requis est associé à un service requis.

Page 49

5.4.

La prise en compte des propriétés sémantiques proposées dans le cadre de l'ADL COSA (Component- Object based Software Architecture) présente un avantage par rapport aux autres ADL. Ainsi COSA est un ADL hybride qui réifie les concepts communément admis par la majorité des langages de description d'architectures logicielles.

Evaluation

Dans COSA, les connecteurs sont définis comme des entités de première classe et sont utilisés pour connecter des composants, des configurations et des interfaces. COSA distingue deux catégories de connecteurs : les connecteurs utilisateur et les connecteurs de construction.

Le tableau 1.5 résume les avantages et les inconvénients de l’ADL COSA :

Avantage

• La définition des configurations comme des classes instanciables permet la construction de différentes architectures du même système.

• La définition explicite des connecteurs est le support fort de leur réutilisation.

• COSA supporte l’évolution statique et dynamique des systèmes. Il supporte l’évolution statique grâce aux mécanismes opérationnels tels que l’instanciation, l’héritage et la composition. Il supporte l’évolution dynamique d’un système grâce aux connecteurs actifs qui sont utilisés dans le modèle d’évolution SAEV [NAS07].

Inconvénient

• COSA est un ADL semi formel et reste ainsi limité pour l’expression de la sémantique • COSA manque de spécifications formelles explicites pour représenter les propriétés et les contraintes.

• COSA ne propose pas explicitement de manière pour définir des styles architecturaux. • Non prise en compte de la vérification de la compatibilité entre composants lors de l’assemblage.

TABLE 1.5. AVANTAGES ET INCONVENIENTS DE COSA

Ingénierie dirigée par les modèles

L’ingénierie dirigée par les modèles et, en particulier, les processus de développement logiciel à base de modèles ont toujours été au centre des préoccupations des chercheurs. Ils correspondent à un paradigme dans lequel le code source n’est plus considéré comme l’élément central d’un logiciel, mais comme un élément dérivé d’éléments de modélisation.

Cette approche prend toute son importance dans le cadre des architectures logicielles et matérielles en utilisant des standards tels que les spécifications MDA (Model-Driven Architecture) proposées par l’OMG. De telles architectures s’intègrent tout naturellement dans un processus de développement à base de modèles s’assurant, à chaque niveau de modélisation, que les modèles obtenus ont les qualités requises. Cette démarche dirigée par les modèles met le modèle au centre des préoccupations des analystes/concepteurs. Leur élaboration devient donc centrale et le choix du formalisme revêt une importance capitale. Actuellement deux tendances se dégagent : la première est plus généraliste comme UML, la seconde répond davantage aux exigences d’un domaine avec les « Domain Specific Languages »

Page 50

(DSL) et les « Domain Specific Model Language » (DSML). Dans le premier cas le processus de développement est plus long car on part d’un modèle plus abstrait, le second est plus ciblé car les concepteurs peuvent s’appuyer sur des technologies propres à un domaine. Cependant, en débutant le processus avec UML, les modèles pourront être plus facilement réutilisables, par contre en se basant, dès le départ du processus, sur un langage de modélisation spécifique au domaine, le processus restera l'affaire des experts du domaine. Quelle attitude avoir quand on cherche à mettre en place un processus de développement dirigé par les modèles ? Les recherches, menées jusqu’à ce jour dans le cadre de collaborations académiques/industrielles montrent que ces technologies intéressent de plus en plus d’industriels. Elles ont pour effet non négligeable de réduire le temps entre conception, mise au point, production et maintenance des logiciels tout en garantissant toutes les qualités que l’on exige d’eux.