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 La rédaction des postconditions

Voici quelques consignes pour la rédaction des postconditions dans les contrats d’opération.

1. Les postconditions doivent décrire les effets de l’opération sur l’état du système.

Cela inclut les modifications apportées aux objets, la création ou la suppression d’objets, et les changements de relations entre les objets.

Une postcondition doit donc décrire un des changements suivants :

  • création (ou suppression) d’instances ;
  • modification des valeurs des attributs ;
  • formation (ou rupture) d’associations.

Si une opération n’effectue aucun de ces changements, comme une opération de lecture ou d’affichage d’information, il n’y a donc pas de postcondition à indiquer. Il suffit alors d’écrire « Aucune » dans la section des postconditions.

2. Exprimez les postconditions au passé

Il est nécessaire de décrire les changements dans l’état du système après l’exécution de l’opération. Ce ne sont pas ceux qui ont lieu ou qui doivent avoir lieu. L’utilisation d’expressions au passé telles que : « a été créé », « a été associé », « est devenu » sont donc fréquentes.

3. Rédigez des phrases courtes et concises

Il est important de formuler des phrases courtes et concises, en se concentrant sur les changements essentiels de l’état du système sans ajouter d’informations superflues. Cela rend les postconditions plus faciles à vérifier lors des tests et de la validation des exigences. Chaque postcondition doit être traitée comme une assertion distincte pour assurer une meilleure clarté et précision.

4. Utiliser le vocabulaire du modèle du domaine dans les postconditions

Cela implique de parler des instances de classes conceptuelles, de leurs attributs et des associations entre ces classes. Par exemple, si le MDD possède une classe « Client », il ne faut pas utiliser le terme « Utilisateur » pour représenter cette classe dans une postcondition, même si un client pourrait être un utilisateur. Il est important de réutiliser les termes du MDD pour assurer la cohérence entre les différents documents de conception. Les postconditions seront utilisées par les développeurs pour concevoir et implémenter le système.

Astuce

Le but est de garder un faible écart entre le modèle du monde réel (classes conceptuelles dans le MDD) et les solutions en programmation orientée objet (classes logicielles).

5. Utiliser des noms d’instances pour simplifier les références

Utiliser des noms d’instances dans les postconditions est utile pour simplifier les références et rendre les postconditions plus claires et précises.

Par exemple, voici une première condition d’une opération :

  • Une instance lar de LigneArticles a été créée.

Le nom de l’instance lar est destiné à simplifier les références à cette nouvelle instance dans les autres postconditions.

Les autres conditions peuvent donc être rédigées comme suit :

  • lar.quantité est devenu la valeur du paramètre quantité.
  • lar a été associé à la Vente en cours.

En utilisant un nom d’instance spécifique, il devient facile de suivre et de comprendre les modifications apportées à cet objet particulier. Cela élimine les ambiguïtés sur quel objet est modifié.

8.3 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.4 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.5 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.3.

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.3.