La modlisation contractuelle

1
La modélisation contractuelle
 La théorie sans la pratique est inutile la
pratique sans la théorie est aveugle.  Immanuel
Kant
2
Objectif de la séquence

• Compétence visée
• Pré-requis
• Connaître le diagramme détats défini dans UML

Être capable dexprimer les transformations
Durée de la séquence 1 h
Protection des documents
3
Contenu de la séquence

• La modélisation contractuelle
• Les contraintes
• Lautomate à états
• La cohabitation avec les règles dorganisation
• Approfondissement
• Hors séquence

4
La modélisation contractuelle
1

• Le besoin
• Les notions

5
La dimension du devenir

• Une des trois dimensions de la modélisation
• Appréhender le changement
• Une source importante de la complication des
  logiciels
• Elle prend toute son importance dans lapproche
  orientée objet
• Prolongée par larchitecture de services
• SOA (Software Oriented Architecture)
• Concevoir les classes comme des machines
  autonomes
• Responsable de leur état interne
• Concevoir les systèmes comme résultant de la
  coopération entre les objets

6
Sa nécessité dans la logique objet
Encapsulation
Contrat
Coopération
7
Une règle de modélisation

• Lencapsulation des contraintes
• Les règles de gestion
• Les règles dorganisation
• Les dépendances fonctionnelles
• CIF (Merise)
• Contrainte dintégrité fonctionnelle
• Les dépendances structurelles
• Conséquence de la règle dencapsulation
• Dégager de nouvelles opérations
• Utiliser la dérivation

Toute contrainte doit être localisée sur le modèle
8
Lexpression des contrats

• Au niveau de la classe
• Linvariant de classe
• Lautomate à états
• Au niveau de lopération
• Les pré et post-conditions
• Autres contraintes

9
Le contrat de classe

• Le contrat de la classe appartient à sa
  définition
• Il permet dutiliser la classe sans connaître son
  contenu
• Boîte noire
• Il spécifie ce que lon peut attendre de la
  classe
• Information
• État interne
• Intégrité toujours garantie
• Action
• Services
• Transformations
• En fonction des conditions
• Conditions dexécution
• Garantie de service

10
La constitution du contrat de classe

• Le contrat de la classe est constitué de
• La liste des propriétés publiques
• Attributs
• Opérations
• Associations navigables
• La machine à états
• Parce quelle exprime les contraintes de
  fonctionnement
• Linvariant de la classe

11
L'invariant de classe

• L'invariant de la classe regroupe les conditions
  que doivent vérifier toutes les instances de la
  classe à tout moment de leur existence
• Classe " Carré"
•  longueur largeur 
• Classe " Auto 1 ère catégorie"
• Véhicule automobile 4 roues, pouvant transporter
  5 personnes maximum
• Cet invariant permet d'exprimer les contraintes
  sur la définition de la classe
• Il pourra être réalisé sous la forme dune
  opération spéciale

12
Le contrat de lopération

• Le contrat de lopération appartient à la
  définition de lopération
• Contrat de service
• Boîte noire
• Il spécifie les conditions de fonctionnement
  de lopération et ses garanties de service
• Cest une définition fonctionnelle
• Ce que fait lopération, non comment elle le fait
• Masquage des conditions internes de réalisation
• Échange minimal entre le demandeur et le
  fournisseur

13
La constitution du contrat de lopération

• Le contrat de lopération est constitué de
• Sa signature complète
• Ses pré-conditions
• Ses post-conditions

14
Les pré-conditions

• Ce sont les conditions qui doivent être réunies
  pour que lopération  accepte  de rendre
  le service spécifié
• Conditions dentrée
• Elles sexpriment dans les termes
• Des valeurs détat de lobjet
• Référence à la machine à états
• Des valeurs des attributs de lobjet
• Des liens à partir de lobjet
• Des états des objets liés
• Des valeurs des paramètres reçus

15
Les post-conditions

• Ce sont les conditions que lopération garantit
  en sortie, quand les pré-conditions sont réunies
• Conditions de sortie
• Garantie
• Elles sexpriment
• dans les mêmes termes que les pré-conditions
• ou en termes de résultats fournis
• Par exemple, formule de calcul pour la valeur
  retournée
• Dans tous les cas, les pré et post-conditions
  sexpriment sur le même plan dabstraction
  que lopération elle-même
• Si classe  métier  alors conditions purement
  fonctionnelles

16
Exemple 1

• Classe Ascenseur, opération  monter 
• Pré-conditions
• État de marche
• Porte  fermée  état de lobjet composant
• Charge totale lt X état interne (attribut) de
  lobjet ascenseur
• Post-condition
• Étage d'arrivée étage demandé

17
Exemple 2

• Classe Contrat (en assurance), opération
   Établir Prime 
• Pré-conditions
• Contrat  en cours  état de lobjet (cycle
  long)
• Contrat  à tarification périodique 
  codification
• ? Si sous-classe
• Contrat  à tarifer  sous-état (cycle annuel)
• Post-conditions
• Date de maj du contrat Date du traitement
• Montant prime gt x et lt y (ou mention des règles
  de calcul)
• État du contrat  tarifé 

18
Lautomate à états

• Une partie des contraintes sexprime en termes
  détats de lobjet
• Le comportement de lobjet dépend de son état
  interne
• Ou de son histoire
• Ou de ses relations
• Lautomate à états est le meilleur moyen
  pour modéliser les transformations
• Machine à états, state machine
• Attaché à la classe
• Possible aussi sur le cas dutilisation
• Peut être représenté par un ou plusieurs
  diagrammes détats

19
Un exemple physique le téléviseur
20
Le téléviseur discussion

• État allumé
• Sous Tension
• En état de marche ?
• Poste réglé
• Canal
• Volume

• État éteint
• Hors tension
• En état de marche ?
• Poste réglé
• Canal
• Volume

21
Lautomobile

• Le diagramme détats pour lautomobile
• Début de la réflexion
• La prise en compte des événements

22
Lautomobile (suite)

• Le diagramme détats-transitions du pneu
• Communication entre machines à états

Diagramme à améliorer
23
Le collaborateur
Etat initial
Etat final
Etats
Transitions déclenchées par des évènements
24
Les contraintes
2

• Les règles et contraintes
• Un exemple
• Quelques considérations formelles
• La structuration des règles
• Lidentification des règles
• La documentation des règles
• La localisation des règles
• Loutillage la fonctionnalité de gestion des
  exigences
• La réification des règles

25
La classe Sinistre
26
Les règles (1)
Reformuler ces règles

• Prélèvement sur le commentaire de lautomate
• Le sinistre peut être créé à l'état " Déclaré" si
  le gestionnaire décide (en fonction des données
  dont il dispose) d'effectuer l'opération
  "enregistrer déclaration". Dans ce cas, le
  sinistre est assimilé à une déclaration, il
  n'existe pas encore fonctionnellement en tant que
  sinistre.
• Le sinistre peut être créé directement à l'état "
  Ouvert en gestion" dès qu'une première garantie
  (couverture) est évaluée si le gestionnaire
  décide (en fonction des données dont il dispose)
  d'effectuer l'opération "ouvrir".
• Un sinistre à l'état " Déclaré" passe à l'état
  "Ouvert en gestion" dès qu'une première garantie
  (couverture) est évaluée.

27
Les règles (2)
Localiser ces règles

• La date de survenance doit être antérieure ou
  égale à la date de déclaration
• La date de déclaration doit être antérieure ou
  égale à la date d'enregistrement
• Le département de survenance du sinistre doit
  être renseigné si le pays de survenance est la
  France.
• Le département de survenance du sinistre ne doit
  pas être renseigné si le pays de survenance n'est
  pas la France.
• Contrôle des doublons s'il existe déjà un
  sinistre (même sans numéro fonctionnel) de même
  famille de sinistre, qui porte à la fois sur le
  même client, le même contrat, le même objet
  assuré et dont la date de survenance est la même
  que pour celui que l'on souhaite ouvrir, afficher
  le message d'alerte suivant " Attention il
  existe déjà un sinistre ayant les mêmes
  caractéristiques, souhaitez vous continuer ou
  abandonner ? "
• Le souscripteur (le client) est obligatoire
• Le contrat est obligatoire .
• Si la date de parution CATNAT est renseignée, et
  le numéro de l'arrêté CATNAT n'est pas renseigné
  émettre un message informatif.
• Si le numéro de l'arrêté CATNAT est renseigné et
  la date de parution CATNAT n'est pas renseignée
  émettre un message informatif.

28
Les règles (3)

• Les règles précédentes étaient données comme
  générales
• Sappliquant à tous les sinistres
• Il existe des règles qui ne sappliquent quà
  certains types de sinistres
• Exemples Règles de gestion Données Spécifiques
  Dommage Ouvrage
• Si la DROC se situe avant la date d'effet du
  contrat ou après la date de résiliation du
  contrat envoyer un message d'alerte.
• La Convention de règlement doit obligatoirement
  être renseignée.
• La Nature de désordre doit obligatoirement être
  renseignée.
• Le Régime doit obligatoirement être renseigné. La
  valeur par défaut est " 3 Futur ".
• La Référence assureur DO doit obligatoirement
  être renseignée si le code de la convention est
  égal à E ou à I.
• Règles de gestion Données Spécifiques Chantier
  Le Type ouvrage doit obligatoirement être
  renseigné.

29
Les règles (4)

• Prélèvement sur le commentaire de lopération
   annuler 
• Seul un sinistre dans un état "Déclaré" peut être
  annulé.
• Sur lopération  mettre à jour 
• On retrouve les règles qui ont été citées pour
  lopération  ouvrir 
• Sur lopération  coût 
•  calculer le coût du sinistre 
• Le calcul du coût d'un sinistre est obtenu en
  effectuant la somme des coûts de toutes les
  garanties de ce sinistre ouvertes à l'instant T
  ou ayant eu des règlements

Comment mieux structurer ces règles
30
La modélisation des règles

• Collecter les règles
• Formuler les règles
• Le plus simplement possible
• Phrases simples, dans un contexte élucidé
• Qualifier les règles
• Séparer les règles de gestion et les autres
• Cf. typologie des exigences
• Localiser les règles
• Cela amène parfois à modifier la structure du
  modèle
• Formaliser les règles
• Les exprimer dans les termes du modèle
• Au moins, vérifier que le modèle suffit pour les
  interpréter

31
La réification des règles

• Le problème
• Des règles  métier  peuvent varier
• Des vraies règles de gestion
• Exemples
• Le pricing
• Le nombre de lignes de commande
• Les solutions
• Par la modélisation
• Par un moteur de règles

32
Lautomate à états
3

• Les possibilités de la notation
• Le mode demploi
• Selon le niveau de qualité visé

33
Létat

• Définition
• Létat dun objet caractérise une situation
  durable dans laquelle il se trouve
• Étape, jalon, stabilité, unité de comportement
• Le comportement de lobjet
• Dépend de létat dans lequel il se trouve lors de
  la sollicitation
• Dans un état donné, le comportement est connu
• Un état se décrit par
• Un nom
• Des valeurs particulières pour un ou plusieurs
  attributs

34
Les états remarquables

• État initial
• Premier état de lobjet
• Cet état est unique Lobjet ne peut pas revenir
  à son état initial lorsquil la quitté
• État final
• Dernier état de lobjet
• Létat final correspond à un état où lobjet
  nest plus nécessaire dans le système

35
La transition

• Définition
• La transition est le passage entre deux états
• Cest une relation orientée
• Une transition se définit par
• Un état source
• Létat actif dans lequel se trouve lobjet avant
  la réalisation de la transition
• Un état cible
• Létat actif dans lequel se trouve lobjet après
  la réalisation de la transition

36
La description dune transition

• Une transition se décrit par
• Un évènement déclencheur
• Et/ ou
• Une condition de garde
• Une action éventuelle ( invocation dopérations,
  création ou suppression dobjets .)

37
La condition de garde

• La condition de garde est représentée par une
  expression booléenne entre crochets
• Elle sévalue après réception de lévènement
  déclencheur, sil y en a un
• La condition de garde est évaluée une seule fois
  pour chaque transition

38
Le diagramme détats

• Ce diagramme permet
• didentifier les différents états stables des
  objets
• dexprimer, au moyen des transitions, les
  changements détats
• didentifier les actions (opérations ou
  activités) liées aux changements détats
• Il fait partie de la description dune classe
• Cest un complément indispensable au diagramme de
  classes pour toutes les classes qui ont un cycle
  de vie
• Une machine à états peut être décrites par
  plusieurs diagrammes détats-transitions
• Par exemple effet de zoom
• Une classe peut avoir plusieurs machines à états
• Rare

39
Les détails de la notation

• Sur les états
• Contenu dun état
• Historique
• Sur les transitions
• La composition détats
• Sous-états
• États concurrents

40
La description complète dun état

• Les états peuvent contenir des actions
• À l'entrée de l'état
• Durant le déroulement de l'état
• À la sortie de l'état
• Au déclenchement dun événement
• La syntaxe
• Entrée/Opération
• Faire/Opération
• Sortie/Opération
• Sur évènement/ Opération

41
Exemple

• Le distributeur de boisson état  Vide 
• Entry ( à l'entrée)
• Afficher message PLUS DE BOISSON FRAICHE
• On Event ( que faire si des événements se
  produisent)
• Si évènement introduction de pièce
• Rendre la pièce
• Afficher message en surbrillance
• Si évènement choix d'une boisson
• Faire clignoter message plus de boisson
  disponible
• Do ( que faire pendant cet état)
• Transmettre message à maintenance distributeur
• Distributeur non disponible
• Exit ( opération à faire en fin d'État )
• Retirer message PLUS DE BOISSON FRAICHE

42
La transition automatique

• Cest une transition qui se déclenche dès que
  lactivité en cours dans létat sachève
• L'objet quitte son état actif pour passer dans un
  nouvel état
• Il ny a ni événement déclencheur ni condition de
  garde
• Exemple Limprimante

43
La transition réflexive

• Une transition qui ne modifie pas létat de
  lobjet
• Exemple sur le téléviseur

44
La notion détat composé

• Un état composé ou super-état est un état qui
  englobe d'autres états
• Exemple La machine à laver

45
La notion dhistorique d'état

• La notion dhistorique permet de conserver la
  valeur du sous-état dorigine
• Exemple du téléviseur
• On conserve le fait que nous sommes sur la
  chaîne-2
• Quand l'opérateur allumera, la chaîne-2 sera
  automatiquement pré-servie

Historique
46
Les différents types de sous-états

• Un état composé contient des sous-états
• Soit séquentiels ou disjoints
• Ils sont alors reliés entre eux par des
  transitions
• Exemple de la machine à laver
• Soit concurrents ou orthogonaux
• Ils ne sont pas reliés entre eux et fonctionnent
  en parallèle
• Fonctionnement dune boîte à musique

47
Exemple détats concurrents

• La boîte à musique

Régions concurrentes
48
Les états de synchronisation des états
concurrents

• Ces états permettent de synchroniser deux régions
  concurrentes

Synchronisation
49
Les apports du diagramme

• Meilleure compréhension du comportement des
  objets
• Les états ne sont pas identifiés comme attributs
  dans la construction du diagramme de classe
• Encapsulation dune partie des contraintes
• Identification dopérations complémentaires
• La transformation des automates vers le logiciel
• Le modèle de données
• Le logiciel
• Il existe un design pattern

50
Linterprétation de lautomate

• UML distingue deux types dautomates
• Lautomate protocolaire
• Il exprime les contraintes à respecter pour
  obtenir les services fournis par lobjet
• Cest ainsi quil est utilisé, majoritairement,
  en informatique de gestion
• Lautomate comportemental
• Il pilote le comportement de lobjet plongé dans
  son environnement
• Il décrit les réactions de lobjet face aux
  stimuli quil reçoit

51
Le recours aux automates

• La modélisation sémantique recourt aux automates
  pour tout ce qui touche aux changements, aux
  étapes, aux transformations
• En général, les objets centraux ont un cycle de
  vie
• Les indices
• Notions de jalon, détat, dattente
• Signes linguistiques
• Adjectifs ou  gérondifs  associés au nom de
  lobjet
• Lautomate est un moyen pour dégager les
  opérations sémantiques

52
Le niveau de formalisme

• Lautomate à états peut se construire
  progressivement, selon le niveau de détail quil
  porte
• Débroussaillage
• Uniquement les noms détats
• Les transitions dessinées mais pas commentées
• Il faut savoir à partir de quel moment elles sont
  complètes
• À la fin, toutes les transitions licites doivent
  être représentées
• Expression de la sémantique
• Les événements et conditions apparaissent
• Exprimés informellement
• Formalisation de la sémantique
• Les événement peuvent être conservés
• Dans ce cas, ils sont rattachés à des signaux
• Les conditions sont formulées dans les termes du
  modèles
• Les opérations apparaissent

53
La cohabitation
4

• Les règles dorganisation introduisent
  de nouveaux états potentiels
• Cela risque de polluer le modèle sémantique
• Comment sy prendre ?

54
Exemple CVO

• Cycle de vie de lopération financière
• Létat  validé  est décomposé
• /

55
Exemple (suite) état  validé 
Que penser de cet automate ?
56
Un danger

• La tentation est grande dinclure à lautomate
  des états de nature organisationnelle
• Cas fréquent en informatique de gestion
• Pollution du modèle sémantique
• Il perd en stabilité et en universalité
• Comment faire cohabiter le modèle pragmatique
  et le modèle sémantique ?

57
La solution formelle

• Pas détat de nature organisationnelle dans le
  modèle sémantique
• Il est nettoyé de toute considération sur les
  procédures
• Aucune mention des acteurs et des fonctions
• Donc, un automate plus simple
• À partir duquel on pourra se poser les bonnes
  questions sur lorganisation
• Dans le modèle pragmatique, on indique les
  conditions pour franchir les transitions sur le
  CVO
• Éventuellement, sous la forme dun autre automate
• Qui décrit la procédure
• Éventuellement attaché à un cas dutilisation
• Si plusieurs acteurs ? processus

Faire lexercice
58
Approfondissement
5

• Les machines à états et les contrats
• Les contrats et lhéritage

59
La machine à états et les contrats

• Chaque état fait lobjet dune définition
  formelle
• Il y a un lien intime entre les valeurs détats
  et le contrat de la classe
•  État interne  de lobjet
• Cette définition sexprime en utilisant les
  propriétés de la classe
• Valeur des attributs
• Valeur non renseignée
• Valeur à lintérieur dune plage
• Valeur imposée
• Présence de liens

60
Les contrats et lhéritage

• Au fur et à mesure que les classes
  se spécialisent
• Les garanties contractuelles devraient
  saugmenter
• Post-conditions
• Ce à quoi on sattend à partir de la classe mère
  doit être assuré par les classes filles
• La classe fille peut fournir davantage de
  garanties
• Les conditions contractuelles dentrée devraient
  se relâcher
• Pré-conditions
• Si les conditions sont réunies pour que
  lopération sexécute conformément au contrat
  défini sur la classe mère,alors elle doit
  sexécuter également sur la classe fille
• Conséquence on ne peut que retirer des
  pré-conditions en descendant dans larbre
  dhéritage

Cf. Philippe DESFRAY
61
La conception des tests

• Les spécifications contractuelles fournissent
  la matière pour la conception des cas de test
• Test fonctionnel
• Vue externe, boîte noire
• Test unitaire
• Les cas de test devraient faire partie
  de la documentation danalyse ou de conception

62
Récapitulatif des acquis

• Rappel de la compétence visée
• Test des connaissances
• De quelles catégories de représentation dispose
  le modélisateur pour exprimer les transformations
  et les contraintes ?
• Quels sont les niveaux de formalismes applicables
  aux automates à états du modèle sémantique ?
• Étude de cas
• 4ème étape

Être capable dexprimer les transformations
Compétence Performance