Tâche: Spécification de composants (architecture SOA)
Cette tâche permet de préciser les détails des composants de service qui réalisent un sous-système de conception.
Disciplines: Analyse et conception
Objet

Elaborer un ou plusieurs Artefact : Sous-systèmes de conception décrits pendant la Tâche : Conception de sous-système (architecture SOA)  et fournir des conceptions détaillées d'Artefact : Composant de service.

Relations
RôlesExécutant principal: Exécutant supplémentaires:
EntréesObligatoire: Facultatif:
Sorties
Utilisation des processus
Description principale

Les services utilisés dans une solution basée sur SOA sont réalisés via l'Artefact : Composants de service qui appartient à un sous-système spécifique, aligné sur les fonctions métier. Chaque composant de service est chargé d'assurer la qualité des services qu'il réalise. En tant qu'actif à l'échelle de l'entreprise, chaque composant de service est qualifié pour le financement, la gouvernance et la maintenance qui lui sont associés. La gestion de l'infrastructure doit être en place pour assurer la disponibilité, l'équilibrage de charge, la sécurité, les performances, la gestion des versions et la santé globale du composant de service qui sera responsable de l'implémentation de la fonctionnalité d'un ensemble de services et de l'assurance de sa qualité de service. Les composants fonctionnels et les composants techniques peuvent être utilisés sur plusieurs composants de service.

Etapes
Interfaces de composant de modèle

Les composants, et notamment les composants de service, ne doivent pas fournir d'opérations directement ; ils doivent, en revanche, utiliser des interfaces pour décrire un ensemble d'opérations, puis pour fournir/réaliser l'interface. Ce mécanisme fait l'objet d'une description générale dans RUP, voir Tâche : Conception de sous-système (architecture SOA) et Tâche : Identifier les éléments de conception.

Exemple

Dans notre exemple d'agence de location de véhicules, nous avons identifié (via l'analyse de sous-système), le besoin d'un composant de service de réservation. Pour assurer une conception réutilisable et souple, nous pouvons également créer une interface de réservation correspondante ou utiliser la spécification de service (dans Tâche : Spécification de service) pour décrire l'interface au composant de service. Le composant va réaliser (en termes UML) chaque interface fournie et peut également indiquer sa dépendance à d'autres interfaces de composant à l'aide de la relation d'utilisation UML, comme illustré dans le diagramme ci-dessous.

Notez que, pour plus de clarté, nous avons élidé les détails des interfaces mêmes.

Attributs de composant de modèle
Dans cette étape, nous allons définir les détails de chaque composant de service, y compris les attributs, les services et les règles. Le canevas devant documenter la spécification du composant de service inclut les attributs suivants :
  1. Propriétés ou attributs
  2. Règles
  3. Variations
  4. Dépend d'<autres composants>
  5. Composition de composants fonctionnels et techniques
  6. Services fournis
  7. Services requis
Evénements et messages de composant de modèle
Pendant cette activité, nous identifions les événements que le composant doit détecter et auxquels il doit réagir lorsqu'ils sont déclenchés. Les messages de composant entrants et sortants sont également indiqués. Pour les services pilotés par les modifications de données, une vue centrée sur les données doit être générée et les processus métier hors de la portée de la solution orientée services doivent être identifiés et évalués pour la génération d'événements et la fourniture de données aux services de consommateur, dans la solution orientée services. Par exemple, un nouveau exemple peut être ajouté par plusieurs processus métier dans un package ISV. Dans tous les cas, les mêmes données peuvent ne pas être capturées pour le client, en fonction du contexte spécifique du processus métier. Les services consommateur devant connaître les nouveaux clients via un service de fournisseur doivent être en mesure de gérer l'appel du nouveau service client quel que soit le processus métier qui le génère.
Structure interne de composant de modèle

Pendant cette activité, il est important de créer au moins un diagramme de classes montrant les relations entre les composants fonctionnels et techniques de chaque composant de service. La modélisation UML standard est appliquée à cette étape. L'utilisation de patterns est conseillée pour structurer le graphique d'objet obtenu afin qu'il soit extensible et ouvert aux changements. Si des changements importants sont anticipés, il est recommandé d'effectuer une analyse de variabilité à ce stade.

Comme décrit dans la tâche précédente, lors de la conception en vue des changements ou de l'anticipation de l'impact significatif sur la conception et la structure du système informatique résultant des changements métier à venir, il est conseillé d'appliquer les techniques d'Analyse de variabilité. Ces techniques restructurent les points communs et externalisent les variations à l'aide de patterns de conception. Les points communs et les variations détectés précédemment peuvent être utilisés en tant que point de départ et enrichis à l'aide de patterns de conception communs tels que la stratégie, l'état [i], l'objet règle [ii], l'objet type, etc.

L'analyse effectuée pendant la conception détaillée identifie les points communs et se concentre sur la construction de variations connectables ; elle implique en outre six principes aidant à distinguer les aspects évolutifs de ceux moins évolutifs des systèmes logiciels ainsi qu'à isoler et encapsuler les changements :

  1. Séparer et modéliser les aspects évolutifs de ceux plus stables du domaine : Identifier, séparer, encapsuler et externaliser les variations croissantes.
  2. Créer des hiérarchies de types pour chaque point de variation.
  3. Attribuer des types de règle à chaque type de variation.
  4. Implémenter trois niveaux d'abstraction ; utiliser le métapattern d'héritage d'agrégat.
  5. Commencer par les niveaux de réutilisation supérieurs aux objets et construire des actifs à chaque niveau de réutilisation ; construire de petites infrastructures préfabriquées à chaque niveau de réutilisation ; construire de petites infrastructures préfabriquées autour des points de variation. En général, chaque infrastructure préfabriquée ne doit pas comporter plus de 7 classes (+ ou - 2).
  6. Chaque élément de réutilisation a ses propres comportements. Externaliser le comportement en tant que données configurables pouvant être lues dans l'application afin de permettre le câblage virtuel.

[i] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns, Addision-Wesley 1994.

[ii] Arsanjani, A., Rule Object: A Pattern Language for Flexible Modeling and Construction of Business Rules, Washington University Technical Report number:  wucs-00-29, Proceedings of the Pattern Languages of Program Design, 2000.

Flux de composant de modèle

Pendant cette activité, nous identifions le flux interne de contrôle au sein du composant de service. Cela peut être représenté sous forme de séquence ou de diagramme d'activité.

Considération ISV : Le flux interne de composant dans un composant de package ISV peut être ou ne pas être exposé et/ou configurable en fonction du package. Si les objets dans le composant ISV sont exposés et configurables, leur flux peut être personnalisé afin d'être mieux adapté à la solution. Toutefois, il faut avoir connaissance de tous les problèmes de maintenance permanents potentiels associés à ces actions. Dans de nombreux cas, il ne sera pas possible, ni même nécessaire, d'identifier le flux interne de composant au sein d'un package ISV. Dans ce cas, le composant ISV doit être considéré comme une "boîte noire" dont seuls les services exposés et réalisés sont documentés.

Allouer des composants aux couches

Les couches offrent les avantages suivants :

  • Les couches aident à apporter des attributs qualité de modifiabilité et de portabilité à un système informatique. Une modification d'une couche inférieure qui n'affecte pas son interface ne requiert aucune modification d'une couche supérieure. Par exemple, un serveur d'applications conforme à la norme J2EE™ peut être librement remplacé sans modification du logiciel de niveau applicatif. Une modification d'une couche supérieure qui n'affecte pas les fonctions qu'elle requiert des couches inférieures n'affectera aucune couche inférieure. En général, les modifications d'un système logiciel en couches qui n'affectent aucune interface sont limitées à une seule couche.
  • Les couches font partie du rôle de plan que joue l'architecture dans la construction du système. Connaissant les couches dans lesquelles se trouve leur logiciel, les développeurs savent quels services ils peuvent utiliser dans l'environnement de codage. Les couches peuvent définir des affectations de travail pour les équipes de développement (mais pas toujours).
  • Les couches font partie du rôle de communication joué par l'architecture. Dans un grand système, le nombre de dépendances parmi les modules s'accroît rapidement. L'organisation du logiciel en couches avec des interfaces constitue un outil important pour gérer la complexité et communiquer la structure aux développeurs.
  • Les couches aident au rôle d'analyse joué par l'architecture. Elles peuvent être utilisées pour l'analyse de l'impact des modifications de la conception.

Les couches peuvent être strictes ou non strictes. Dans un schéma de couches strictes, les composants peuvent uniquement utiliser des composants dans la ou les mêmes couches situées immédiatement dessous. Dans un schéma de couches non strictes, les composants peuvent utiliser des composants dans la même couche ou dans toute couche inférieure. Notez qu'en règle générale, toutefois, les composants ne doivent pas être autorisés à utiliser des composants des couches supérieures. Si des composants ont des dépendances sur des composants des couches supérieures, il devient alors difficile de remplacer les composants des couches supérieures sans avoir à modifier les composants des couches inférieures. Pour plus d'informations, y compris sur les techniques de modélisation des couches, voir Concept : Partitionnement de solution.

Un point important à noter est que les couches logicielles sont différentes des niveaux. L'affectation à des machines dans un environnement réparti, le flux de données dans les éléments et la présence et l'utilisation de canaux de communication ont tous tendance à être illustrés dans des figures de niveaux qui peuvent être confondues avec des diagrammes de couches. Les diagrammes de niveaux montrent plutôt des flèches à deux sens, indiquant une communication bidirectionnelle d'un type donné. La communication bidirectionnelle (symétrique) n'est pas bon signe dans un diagramme de couches. En outre, l'attribution d'un composant à un niveau est basée sur les règles de positionnement prises en compte lors de la définition de l'architecture opérationnelle et elle est définie par les caractéristiques de niveau de service requises par le système. La différence principale entre les diagrammes d'organisation en couches et les images de niveaux est que les premiers ne comportent pas de notion de positionnement alors les secondes en tiennent compte.

Règles empiriques d'organisation en couches

  • Tous les composants qui fournissent une fonctionnalité métier indépendante des applications peuvent être disposés en une seule couche. Les fonctions métier indépendantes des applications sont, par exemple, la "gestion client" et la "gestion des produits" qui s'appliquent à une gamme d'applications différentes.
  • Tous les composants qui fournissent des fonctions techniques telles que le traitement d'erreurs, l'authentification, la consignation et l'audit peuvent être placés dans une autre couche (logique). Ces composants sont indépendants du métier et des applications. Dans certains cas, la proximité entre des composants techniques et fonctionnels peut nécessiter leur placement dans une couche commune. Il s'agit de décisions liées à l'architecture et elles doivent être documentées en tant que telles.
  • Les composants intermédiaires tels que la mise en file d'attente de messages et le logiciel SGBD relationnel peuvent être placés dans une autre couche. Cela est également désigné par le terme "Matrice".

Exemple

Voici une vue en couches d'une architecture SOA montrant les couches standard (et recommandées) des différents éléments présents dans une solution.

Dans ce schéma d'organisation en couches, il est assez simple de déterminer où nos composants doivent être placés ; nous plaçons les composants associés à notre exemple d'agence de location de véhicules dans la couche Composants de service, comme illustré ci-dessous. Notez que nous souhaitons utiliser des couches strictes dans notre modèle, nous utilisons donc une composition UML contenant nos composants dans la couche Composants de service et nous exposons uniquement la fonctionnalité des composants de service à l'aide de ports délégués où le port fournit la même interface que le composant de service même.

Plus d'informations