Tâche: Analyse de cas d'utilisation métier (architecture SOA)
Cette tâche identifie les éléments de conception d'une solution orientée services en termes de services et de partitions et documente la spécification initiale de ces services.
Disciplines: Analyse et conception
Objet
  • Identifier les éléments de conception d'une solution orientée services en termes de services et de partitions.
  • Documenter la spécification initiale des services.
  • Déterminer les dépendances initiales et la communication entre les services.
Relations
Description principale

Cette tâche utilise l'Artefact : Réalisation de cas d'utilisation métier en tant qu'entrée et identifie un ensemble de services candidats qui sont inclus dans le portefeuille de services du projet. Ces services candidats peuvent toutefois nécessiter une amélioration supplémentaire, néanmoins, les étapes incluses dans le présent document fournissent une méthode efficace pour produire un ensemble initial de l'Artefact : Spécification de service.

Etapes
Identifier des services candidats à partir de cas d'utilisation métier

Dans le cas du développement de solutions plus classiques à base de composants ou orientées objet, il est fréquent qu'une série de transformations ait lieu dans les niveaux d'abstraction et qu'on ajoute des niveaux de détail descendant des cas d'utilisation jusqu'à la conception système. Cela se vérifie en particulier lorsqu'un cas d'utilisation métier fait office de point de départ, comme expliqué dans les Instructions Des modèles métier aux systèmes, qui indiquent comment transformer des cas d'utilisation métier en cas d'utilisation système ; il faut encore développer un véritable modèle de conception sur cette base.

Par chance, il est possible d'établir un parallèle avec les instructions fournies pour passer aux cas d'utilisation métier en définissant la façon dont un modèle de services peut être dérivé d'un modèle de cas d'utilisation métier, comme l'illustre le diagramme ci-après. En général, l'approche consiste à créer un service candidat pour chaque opération définie sur un Artefact : Travailleur métier dans l'Artefact : Modèle d'analyse métier. Il existe un parallèle distinct ici avec la Tâche : Analyse de processus métier où les tâches individuelles dans un modèle de processus sont identifiées en tant que services candidats.

Diagramme décrit dans le contenu textuel.

Ce rapport plus direct entre le modèle d'analyse métier et le modèle de services permet de ne pas disposer uniquement de services dont on peut envisager qu'ils prendront en charge les besoins métier ; en limitant les transformations entre l'expression des besoins métier et la solution, la prise en compte des changements effectués sur les modèles de cas d'utilisation métier ou d'analyse métier sera plus efficace. Autre aspect essentiel : comme le modèle de cas d'utilisation métier comporte également les objectifs métier guidant le métier, il devient beaucoup plus facile d'identifier réellement l'alignement entre les services et les objectifs. Par exemple, il est à présent possible de répertorier, pour toute spécification de service, tous les objectifs métier auxquels elle participe. Pour chaque objectif métier, nous pouvons répertorier les services réellement déployés dans notre entreprise informatique et participant à cet objectif, ceci en suivant le rapport entre un service et une spécification de service.

Détailler les spécifications de service candidat

Dans certains cas, l'ensemble des opérations définies dans la réalisation de cas d'utilisation métier peut refléter plus correctement une conversation entre des parties liées à un service unique que dans un ensemble de services distincts ; dans ce cas, les opérations peuvent être regroupées en une seule spécification de service (comme illustré ci-dessous). L'inconvénient de cette approche est qu'elle requiert une analyse et une compréhension plus détaillées de la réalisation de cas d'utilisation ainsi que du rôle des travailleurs dans cette approche, pour l'identifier en tant qu'exigence.

Le terme "conversation" signifie que l'exécution réelle d'un service requiert souvent plusieurs interactions entre les parties ; par exemple, si nous examinons le service "Passer commande", nous pouvons voir qu'il s'agit d'un ensemble complexe d'interactions comprenant des accusés de réception, des bons de transport, des refus (par exemple, si les articles ne sont pas disponibles), comme illustré dans le diagramme suivant.


 

Plus d'informations