8  Contrats d’opération

Un contrat d’opération est un document décrivant les modifications permanentes à l’état du système après l’exécution d’une opération système. Les modifications permanentes à l’état du système comprennent :

Les contrats d’opération sont présentés sous forme de postconditions utilisant le vocabulaire du modèle du domaine.

Important

Le MDD est un modèle de la vraie vie. Il y a des classes conceptuelles (comme Vente), mais aussi des instances de ces classes. Dans un magasin, pour chaque nouvelle vente, on imagine une nouvelle instance de la classe Vente. S’il y a eu 72 clientes et clients qui ont acheté des choses dans un magasin dans une journée, on imagine 72 instances de Vente, une pour chaque cliente ou client.

Sur la figure 8.1, l’opération système créerNouvelleVente() provient d’un diagramme de séquence système lié au cas d’utilisation Traiter une Vente. Elle correspond au moment où le caissier ou la caissière démarre une nouvelle vente pour un client ou une cliente. Avant l’exécution de cette opération, l’instance de la classe Vente indiquée dans le modèle du domaine n’existe pas. Cependant, après l’exécution de l’opération système, l’instance de Vente devrait exister. Le contrat d’opération spécifie ce fait dans une postcondition (avec la voix passive au passé composé en français) : « une instance v de Vente a été créée ».

Un contrat d’opération permet de spécifier tous les changements dans le MDD qui doivent avoir lieu lors de l’opération système. Les postconditions du contrat saisissent l’évolution du MDD.

Figure 8.1: Pendant l’opération système créerNouvelleVente, une instance de Vente doit être créée. Le contrat d’opération le spécifie dans une postcondition : une instance v de Vente a été créée.

8.1 Les contrats en bref

Les contrats d’opération sont le sujet du chapitre 11  (2005). Voici les points importants pour la méthodologie enseignée dans le présent manuel :

  • Un contrat d’opération correspond à une opération système provenant d’un DSS.
  • On fait des contrats surtout pour les opérations système ayant une certaine complexité.
  • Une postcondition décrit les modifications de l’état des objets dans le modèle du domaine après une opération système.
  • Le vocabulaire pour les postconditions provient du modèle du domaine. Il s’agit des noms de classes, d’attributs et d’associations qu’on trouve dans le MDD.
  • Chaque postcondition doit avoir la bonne forme :
    • création (ou suppression) d’instances ;
    • modification des valeurs des attributs ;
    • formation (ou rupture) d’associations.
  • On ne spécifie pas les préconditions dans les contrats (Larman ne donne pas beaucoup de directives claires à ce propos).
  • Il ne faut pas confondre les postconditions d’un contrat d’opération et les postconditions d’un cas d’utilisation. Ce sont deux choses différentes.
  • Quand on rédige les contrats, il est normal de découvrir dans le modèle du domaine des incohérences ou des éléments manquants. Il faut les corriger (il faut donc changer le MDD), car cela fait partie d’un processus itératif et évolutif.

8.2 Exemple : Contrats d’opération pour Attaquer un pays

Voir la figure 8.2 pour les changements dans les objets du modèle du domaine correspondant aux postconditions.

Attaquer un pays

Opération : démarrerAttaque(paysAttaquant:String, paysDéfenseur:String)

Postconditions :

  • Une nouvelle instance a de Attaque a été créée.
  • a a été associée au Pays correspondant à paysAttaquant.
  • a a été associée au Pays correspondant à paysDéfenseur.

Opération : annoncerAttaque(nbRégimentsAttaquant:int)

Postcondition :

  • a.nbAttaquant est devenu nbRégimentsAttaquant.

Opération : annoncerDéfense(nbRégimentsDéfendant:int)

Postconditions :

  • a.nbDéfenseur est devenu nbRégimentsDéfendant.
  • L’attribut valeur des d1 à d5 est devenu un nombre entier aléatoire entre 1 et 6.
  • Occupation.nbRégiments est ajusté selon le résultat des valeurs correspondant à paysAttaquant.
  • Occupation.nbRégiments est ajusté selon le résultat des valeurs correspondant à paysDéfenseur.
Important

Les règles pour la résolution d’une attaque dans le jeu Risk sont complexes. Pour faire un exemple plus facile à comprendre, on en fait abstraction.

Figure 8.2: Les postconditions décrivent la manipulation d’objets dans un MDD (la partie inférieure ici est un diagramme d’objets).

8.3 Feuille de référence

Pour faire des contrats, voici une démarche générale :

  1. Faire un contrat pour chaque opération système.
  2. Porter une attention à sa signature (les arguments et leur type).
  3. Rappeler les formes de postconditions :
    1. créer/supprimer instances ;
    2. former/briser associations ;
    3. modifier attributs.
  4. Utiliser le vocabulaire du modèle du domaine dans les postconditions. Ça veut dire qu’il faut parler d’instances de classes conceptuelles, de leurs attributs et des associations entre ces classes.
  5. Ne pas créer une instance de classe qui existe déjà, par exemple un produit (connu) dans un magasin, un acteur (connu) qui se connecte au système, ou, dans l’exemple de Risk, un Pays (voir la partie inférieure de la figure 8.2).
  6. Ne rien oublier. Marquer le MDD ou dessiner un diagramme d’objets, comme à la partie inférieure de la figure 8.2 si nécessaire.

8.4 Exercices

Exercice 8.1 (terminerAttaque()) Rédigez le contrat d’opération pour terminerAttaque(). Il faut considérer les règles d’attaque (voir la page de wikiHow) et les cas où une attaque a réussi, c’est-à-dire que le paysDéfenseur change de Joueur (celui du paysAttaquant). Suivez les exemples de contrats d’opération présentés à la Section 8.2.

Exercice 8.2 (Contrats d’opération pour Traiter une vente) Rédigez un contrat d’opération pour chacune des opérations système dans le DSS (et qui doit être cohérent avec le MDD) de la Section B.1. Suivez les exemples de contrats d’opération à la Section 8.2.