18 Contexte logiciel spécifique à la thèsese produise (réception d’un message, alarme temporelle, etc.), scope définit unezone restreinte du workflow permettant la définition de variables, de fautes etde gestionnaires d’exception, et compensate permet d’invoquer un processus decompensation d’exception.Le listing 2.2 exhibe un exemple minimaliste de code BPEL déclarant deux partenaires(l’interface du composite et un service Web de météorologie), spécifiant deuxvariables et déclarant une activité composite de type sequence composée de trois sousactivités simples (receive, invoke et reply) dont le rôle est de recevoir le message duclient de la composition, de le transmettre au service météo, puis de renvoyer la réponseau client.< partnerLinks >< partnerLink myRole =" proxy " name =" proxyPLT " partnerLinkType =" proxyPLT "/>< partnerLink name =" Forecast " partnerLinkType =" ForecastLinkType "/>5 < variable messageType =" proxyRequest " name =" proxyRequest "/>< variable messageType =" proxyResponse " name =" proxyResponse "/>10 < receive createInstance =" yes " operation =" proxy " partnerLink =" proxyPLT "portType =" ProxyService " variable =" proxyRequest "/>< invoke inputVariable =" proxyRequest " operation =" invokeWF "outputVariable =" proxyResponse " partnerLink =" Forecast "15 portType =" invokeWFPT "/>Listing 2.2: Exemple de code BPEL2.2 Séparation des préoccupations2.2.1 PrincipesUne préoccupation correspond à un sous-ensemble d’un système logiciel rattachéà la prise en compte d’un concept, d’un objectif ou bien d’un sujet particulier. Parexemple, dans le cas d’un serveur Web, il existe des préoccupations liées à la gestiondes pages HTML ou à la gestion du protocole HTTP, ainsi que des préoccupationsliées à la gestion de la sécurité ou du logging. Un problème inhérent à la définition desystèmes logiciels est que les multiples préoccupations des systèmes ne peuvent êtrereprésentées sans être disséminées dans les différentes composantes de ces systèmes.Autrement dit, les préoccupations ne sont pas encapsulées de façon adéquate tant auniveau des modèles de conception que des langages de programmation. Or, ce sont enparticulier les interactions entre préoccupations qui sont responsables de la complexitédes systèmes logiciels. Dans le cas du serveur Web Apache, il est montré [KLM + 97]que le code implémentant la notion de session de connexion est disséminé dans unecinquantaine de classes différentes et ce malgré les mécanismes usuels de réutilisationtels que l’héritage. Le code obtenu est alors plus difficile à lire, à maintenir et à réutiliser,ce qui a également pour effet d’en réduire sa robustesse.La séparation des préoccupations (Separation of Concerns) [Dij82, HL95] est unprincipe fondamental du génie logiciel. Son objectif est de permettre la maîtrise de systèmeslogiciels complexes en adressant, de façon isolée, les diverses préoccupations quiles composent. Il s’agit pour cela que la structure des logiciels reflète le plus fidèlement
2.2. Séparation des préoccupations 19possible les relations intrinsèques entre leurs préoccupations afin de minimiser leursinteractions et, ainsi, de faciliter l’expression et la compréhension de ces interactions.« Separation of concerns is a key guiding principle of software engineering.It refers to the ability to identify, encapsulate, and manipulate onlythose parts of software that are relevant to a particular concept, goal orpurpose. Concerns are the primary criteria for decomposing software intosmaller, more manageable and comprehensible parts that have meaning tosoftware engineers. » [EFB01]Bien que, pour être mis en oeuvre l’existence, ce principe nécessite des technologiesparticulières, la séparation des préoccupations n’est pas une technologie en soi. Ils’agit d’un principe de conception qui a fortement influencé l’émergence de technologiespermettant d’isoler les préoccupations à l’aide de stratégies plus ou moins efficaces.Un premier type de décomposition permet de découper les logiciels de façon hiérarchique,selon une et une seule dimension. C’est ce type de décomposition que permettentd’effectuer la programmation modulaire, par objets, par composants et orientée serviceà présent. Cependant, ce type de décomposition conduit au problème de la « tyranniede la décomposition dominante » [OT99] : les concepteurs, ayant choisi de décomposerleur système selon une préoccupation principale (typiquement une préoccupation métier),regroupent dans cette décomposition les autres préoccupations qui n’ont pas puêtre modularisée. Ces préoccupations, qualifiées de « transverses » se retrouvent disperséesdans le reste du code et mélangées avec les autres, ce qui rend le logiciel difficileà comprendre, à maintenir et à faire évoluer. Certaines de ces préoccupations transversespeuvent être des préoccupations métier annexes, mais il s’agit pour la plupartde préoccupations dites « non-fonctionnelles » qui traitent par exemple de la sécuritéou encore des performances. Souvent, ces préoccupations ne sont d’ailleurs pas spécifiquementliées à l’application développée. Afin de modulariser ces préoccupations, legénie logiciel a développé de nouvelles techniques de programmation mettant en oeuvrele principe de séparation des préoccupations.« When writing a modular program to solve a problem, one first dividesthe problem into sub-problems, then solves the sub-problems and combinesthe solutions. The ways in which one can divide up the original problemdepend directly on the ways in which one can glue solutions together. Therefore,to increase ones ability to modularise a problem conceptually, onemust provide new kinds of glue in the progamming language. » [Hug89]2.2.2 Réflexion et méta-programmation« The most important contribution of the reflection community is toclearly illustrate the potential of separation of concerns. » [Tho02]La réflexion réfère à la capacité d’un système à raisonner et à agir sur lui-même [Smi84,Mae87]. En particulier, un système réflexif est un système qui fournit une représentationde son propre comportement qu’il est possible d’inspecter et de modifier. Pour obtenirune telle caractéristique d’un système, il faut que celui-ci dispose de deux capacités :– La capacité d’introspection, qui correspond à la capacité de pouvoir s’observer soimême.C’est grâce à cette capacité que le logiciel peut raisonner sur lui-même.En particulier, cette capacité se concrétise par la réification des structures et des