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. |
|
Objet
Relations
Rôles | Principal:
| Complémentaire:
| Auxiliaire:
|
Entrées | Obligatoire:
| Facultatif:
| Externe:
|
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
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 :
-
Propriétés ou attributs
-
Règles
-
Variations
-
Dépend d'<autres composants>
-
Composition de composants fonctionnels et techniques
-
Services fournis
-
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 :
-
Séparer et modéliser les aspects évolutifs de ceux plus stables du domaine : Identifier, séparer, encapsuler et
externaliser les variations croissantes.
-
Créer des hiérarchies de types pour chaque point de variation.
-
Attribuer des types de règle à chaque type de variation.
-
Implémenter trois niveaux d'abstraction ; utiliser le métapattern d'héritage d'agrégat.
-
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).
-
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.
|
|
Propriétés
Plusieurs occurrences |  |
Commandé par les événements |  |
En cours |  |
Facultatif |  |
Planifié |  |
Réitérable |  |
Plus d'informations
© Copyright IBM Corp. 1987, 2006. All Rights Reserved.
|
|