PUMA    processus Agile optimal
Techniques complémentaires     
    

SOA Architecture applicative Agile

Services : identification et granularité

L’architecture applicative SOA consiste à décomposer les fonctionnalités, telles que les appréhende un utilisateur, en un ensemble d’éléments basiques nommés « services ». L’étape suivante de la mise en œuvre consiste à décrire finement leur schéma d'interactions dans le cadre d’un processus métier. Les services seront ensuite développés et déployés sous forme de composants logiciels indépendants. L’objectif de ce type d’architecture est de supprimer la construction d’applications lourdes incapables de supporter une logique métier en évolution. Idéalement, l’encapsulation de chaque service doit garantir sa réutilisabilité et son interopérabilité. Finalement, l’avantage le plus appréciable du « service » est la facilité d’évolution de l’ensemble dans lequel il s’inscrit. Il n'existe pas actuellement de spécifications officielles d'une architecture SOA mais un ensemble de notions fédératrices et de standards trop techniques pour être abordés ici.

PUMA propose en réponse deux dérivations effectuées à partir de deux modèles UML s’auto-validant et une classification des composants des services prenant en compte leur stabilité :

La dérivation fonctionnelle-organisationnelle (côté couche présentation). Elle s’instrumente à partir des cas d’utilisation. La granularité idéale du « service utile» correspond à la plus petite décomposition d’un cas, dont la demande de « service » permet d’obtenir en retour une information fonctionnellement utilisable, c'est-à-dire un service complet de type « client-utile ».

La dérivation métier (sémantique / stabilité) (côté couche données). Elle s’instrumente à partir des classes (ou E-R). La granularité du « service utile» représente une possibilité de composition entre des classes dont la portée sémantique avait autorisée une mise en relation (généralement un objet métier regroupement de classes fonctionnellement insécables).

Stabilité des objets

Pour aborder ce concept, il est nécessaire de comprendre les axes de modélisation. L’approche objet a imposé la prédominance des axes de modélisation dans la conception d’un système d’information. La réutilisation des composants, le redéploiement et l’adaptation étant devenus les principales caractéristiques recherchées, Il faut pour assurer la pérennité d’un système, mettre en œuvre des techniques de conception « en vue de modification ». Une conception efficace s’appuie alors sur la complémentarité de trois axes de modélisation distincts :
- l’axe statique fixe la structure des données,
- l’axe dynamique définit les processus,
- l’axe fonctionnel détaille les traitements.

La notion d’adaptation est la cible visée dans la maîtrise de ces axes. Une organisation est dans l’incapacité de muter rapidement si son système d’information impose de lourdes refontes à chaque étape de sa marche forcée vers la productivité. Le rôle des axes est de limiter la portée des changements en cours de développement et durant tout le cycle de vie applicatif.

L’axe statique est le plus stable. Par définition, il faut pour l’atteindre dans ses bases, un changement majeur du métier de l’entreprise. L’axe dynamique colle à l’aspect organisationnel. Seule une réorganisation des acteurs et des processus doit avoir un impact sur sa définition. Les autres changements superficiels, dans la manière de traiter les produits ou services offerts, se limitent à une redéfinition des traitements à travers l’axe fonctionnel .

La composition des objets métiers assemblés pour répondre à une demande de « service » cherchera à limiter les associations de classes appartenant à des couches de stabilité différentes.

Dans une architecture multicouches, les autres règles sont éventuellement utilisées comme contraintes ou comme assertions facilitant la validation de la solution.
Cette approche a été publiée à plusieurs reprises et en premier lieu en 1999 dans le rapport opérationnel du Gartner Group « Réingénierie du Développement d’Applications … », puis dans « Piloter les projets informatiques de la nouvelle économie » (Editions d’Organisation, 2000) sous le titre de « Concept de stabilité des objets ».