Tâche: Créer un diagramme de classes de composant
Cette tâche permet de préciser les détails des composants de service qui réalisent un sous-système de 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ôlesPrincipal: Complémentaire: Auxiliaire:
EntréesObligatoire: Facultatif: Externe:
  • Aucun
Sorties
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
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.

Propriétés
Plusieurs occurrences
Commandé par les événements
En cours
Facultatif
Planifié
Réitérable
Plus d'informations