Tâche: Exécuter une analyse orientée vers les écarts
Cette tâche est applicable à un certains nombre d'éléments d'analyse et de conception où l'exclusion de la factorisation de la variabilité de ces éléments et l'inclusion de la factorisation de la communité fournissent un résultat plus souple et plus solide.
Objet

Analyser les éléments de modèle fournis, identifier lesquels de ces éléments sont communs aux différentes applications et les séparer des éléments qui varient d'une application à une autre. En identifiant les éléments qui varient selon les applications, nous pouvons modéliser explicitement les types de variabilité et les documenter pour les clients des éléments de modèle.

Relations
RôlesPrincipal: Complémentaire: Auxiliaire:
EntréesObligatoire:
  • Aucun
Facultatif: Externe:
  • Aucun
Sorties
Description principale

Cette tâche peut être appliquée à tout modèle d'analyse ou de conception où les éléments du modèle peuvent tirer parti des techniques décrites ici. Les techniques sont dérivées de l'expérience des deux conceptions de lignes de progiciels où les éléments communs unissent les produits dans la ligne de produits et la variabilité distingue les produits les uns des autres. Dans le développement de patterns, les éléments communs représentent la structure du pattern et la variabilité permet de définir les paramètres du pattern.

L'approche consiste d'abord à identifier les éléments de la conception qui sont communs à toutes les applications de l'élément, puis à identifier les éléments qui varient dans chaque application et enfin à documenter la variabilité (ici différentes approches sont utilisées par différents domaines).

Exemple

Dans le diagramme de classes suivant, les éléments d'un contrat légal identifient que le contrat est établi entre deux parties ou plus. En identifiant les éléments communs, nous pouvons voir que les éléments principaux sont la structure du contrat même et les différentes relations avec les parties.

Toutefois, un contrat légal peut être établi entre plusieurs personnes, organisations ou agences gouvernementales et nous notons donc que Partie est un élément variable de par son type. En déclarant cela, nous définissons une hiérarchie de types pour Partie et identifions également Partie en tant que classe abstraite afin que des types concrets soient utilisés dans une conception réelle.

Etapes
Identifier les éléments communs et les éléments variables

Identifier les éléments d'une conception qui ne changent pas lorsqu'ils sont utilisés dans différentes situations est souvent mieux réalisable de façon itérative. A l'aide d'un ensemble de scénarios, créez des diagrammes d'instances et notez, lorsque vous comparez les diagrammes d'instances pour différents scénarios, quels éléments sont communs dans tous les cas. Plus le nombre de scénarios disponibles est élevé, plus vous disposez de points de données qui vous permettent donc de valider plus rapidement des résultats et des hypothèses.

Lors de la description des éléments communs d'un modèle, il est souvent utile de fournir des éléments d'encapsulation afin de séparer ces éléments du reste de la conception. Le choix de la technique d'encapsulation dépend évidemment du contexte, mais il peut s'agir des choix suivants :

  • Introduction d'un package propriétaire des éléments : cela modifie uniquement le propriétaire des éléments mais pas la relation entre les éléments ou les éléments hors du package - cela est plus généralement appliqué aux modèles d'analyse.
  • Introduction d'un composant propriétaire des éléments : cela modifie non seulement le propriétaire des éléments mais introduit également une encapsulation formelle afin que vous puissiez choisir de définir une interface exposant les éléments pertinents vers l'extérieur.
  • L'introduction d'une collaboration UML 2.0 permet aux éléments communs d'être définis dans le cadre de la structure composite de la collaboration et aux élément variables d'être définis en tant que rôles ; ultérieurement, une liaison peut être effectuée depuis des rôles d'élément variables vers des éléments concrets. Il s'agit d'une approche courante pour définir des patterns de conception en langage UML. Notez qu'une collaboration ne possède pas les éléments mêmes mais uniquement les rôles correspondant aux éléments.
  • Introduction d'une classe canevas où le canevas correspond au type du ou des éléments de variable ; il s'agit d'une approche courante dans des langages tels que Ada, C++, Eiffel et actuellement Java qui prennent en charge la programmation générique.
  • Vous simplement choisir d'utiliser un signal visuel. Il est courant, par exemple, d'utiliser un diagramme unique (comme illustré dans la description principale) et de colorer différemment les éléments communs et les éléments variables.

Exemple

Dans le cas de notre contrat légal, nous choisissons d'introduire un composant qui sera propriétaire des éléments, comme illustré dans la figure ci-dessous.

Documenter les formes de variabilité

La variabilité même revêt plusieurs formes, dont chacune peut être appropriée et, dans certains cas, plusieurs formes sont représentées dans une situation donnée. Les types courants de variabilité sont les suivants :

  • Variabilité par type : par exemple, dans le cas de notre contrat légal, la variabilité est basée sur la hiérarchie de types utilisée pour représenter le concept "Partie" ; il s'agit d'une forme très courante qui peut être aisément décrite en langage UML en tant que diagramme de classes (comme illustré dans la description principale).
  • Variabilité par rôle : dans ce cas, le type de l'élément est généralement immatériel (ou au moins d'importance secondaire) ; c'est le rôle qu'il joue qui a de la valeur. Ce type de variabilité se trouve souvent dans le développement de patterns lorsqu'il doit être possible d'appliquer le pattern au plus grand nombre de possibilités ; les paramètres du pattern sont alors définis en termes de rôles que jouent uniquement les éléments indiqués.
  • Variabilité d'implémentation : dans ce cas, l'élément fourni doit avoir un comportement donné et doit donc implémenter une interface donnée (ou plus formellement un protocole) pour pouvoir être applicable. Dans ce cas, il est courant que le conteneur des éléments communs décrive l'interface et possède un paramètre canevas du type d'interface ou un paramètre pour demander l'interface.

Exemples

Le diagramme suivant montre la notion de variabilité par rôle, où nous avons une nouvelle "Vente" de collaboration qui reflète la relation entre un vendeur et un acheteur en tan que parties d'un contrat. En langage UML, il est possible de créer une occurrence de collaboration qui relie les rôles "acheteur" et "vendeur" aux éléments de modèle réels.

Nous pouvons également examiner le processus de vente à l'aide d'un service de compartiment. Nous capturons les capacités requises d'un service de compartiment en tant qu'interface, avec un ensemble d'opérations correspondant aux responsabilités que le service de compartiment doit assumer. Nous créons également une collaboration canevas où nous utilisons l'interface de compartiment en tant que type du paramètre de canevas. Il est alors possible d'instancier le canevas en indiquant une classe ou un composant qui réalise l'interface IEscrowService.

Enfin, nous pouvons plus simplement utiliser un composant (ou une classe) pour contenir nos éléments communs et le paramétrer pour qu'il requiert l'interface IEscrowService à l'aide de la relation <<use>> UML 2.0, comme illustré dans le diagramme ci-dessous. Cette approche est certainement utile au niveau conceptuel car il s'agit également d'une approche de programmation courante dans le développement basé sur les composants ou simplement dans des langages comme Java.

Le choix de la technique dépend, bien entendu, de la situation et de considérations telles que :

  • Le type de variabilité exprimée, comme nous l'avons vu plus haut.
  • Si l'élément fait partie d'une analyse, d'une conception ou d'un modèle d'implémentation.
  • Les compétences et les attentes des intervenants dans le modèle.

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