Dans un premier temps, nous avions traité cet exemple pour acquérir une compréhension
appro-3
fondie de la méthode présentée dans [?]. Dans les faits, cela a entraîné de nombreuses discussions
4
avec les auteures, et cette étude de cas nous conduit à effectuer une analyse critique de la
mé-5
thode et à proposer des précisions et des améliorations présentées dans la section précédente.
6
Nous avons ainsi fait plusieurs essais avant d’arriver à une version de la modélisation qui nous
7
semble satisfaisante et qui aille de pair avec les précisions et les améliorations proposées. Le texte
8
de départ est le suivant :
9
Nous souhaitons réaliser un système de paiement de parking. Le système comporte une bar-10
rière qui se lève pour laisser passer des voitures, unlecteur de ticket et de carte bancaire, un 11
détecteur de présence de voitures, un moteur de barrière, et un détecteur de position
12
de la barrière : 13
• L’utilisateur souhaite sortir du parking. Pour cela, il insère son ticket de parking dans le 14
lecteur de la borne qui le lit. Si la lecture échoue, le ticket est restitué à l’utilisateur. 15
• Si la lecture réussit, le système attend que l’utilisateur insère sa carte bancaire dans le 16
lecteur de carte pour effectuer le paiement du parking. Le système lit la carte, et contacte 17
une banque pour réaliser le paiement du parking, puis restitue la carte de l’utilisateur. 18
L’utilisateur passe à l’étape suivante si le paiement a réussi (sinon, il revient à état où le 19
système attend l’insertion d’un ticket). 20
• Le système envoie une commande au moteur de la barrière pour lever cette dernière. Dès 21
que le détecteur de position de la barrière indique que celle-ci est en position haute, le 22
système envoie un signal d’arrêt au moteur. 23
• Le système attend que le détecteur de présence de véhicules signale qu’il n’y a plus de 24
voitures pour envoyer au moteur un signal de descente. Le système envoie au moteur un 25
signal d’arrêt dès que le détecteur de position de la barrière indique que celle-ci est en 26
position basse. 27
Analyse du texte et diagramme de classes
28Lors de notre travail d’analyse, nous avons remarqué que, dans le texte ci-dessus, le système
29
agit comme un contrôleur des différentes entités en présence (lecteur de ticket et de carte 30
bancaire,détecteur de présence de voitures,moteur de barrière,détecteur de position 31
de la barrière), nous utiliserons donc le terme contrôleur. L’analyse de la version textuelle
32
(informelle) de l’exemple donne la description suivante (la Figure 4.8 montre le diagramme de
33
séquence correspondant à la description) :
34
1. Détection de l’arrivée d’une voiture à la barrière du parking (détecteur de présence de
35
voitures)
36
2. L’utilisateur insère son ticket dans le lecteur de ticket
37
3. Si la lecture échoue : le lecteur de ticket informe le contrôleur de l’échec de la lecture et le
38
contrôleur lui ordonne d’éjecter le ticket.
39
4. Si la lecture réussit : le contrôleur est informé de la réussite de la lecture par le lecteur
40
de ticket alors le contrôleur ordonne au lecteur de carte bancaire de donner la main à
41
l’utilisateur pour payer.
Événement
ticketInserted ()
ticketFailure ()
ticketSuccess ()
card_Inserted (CreditCard)
receivePaymentOk (CreditCard) receivePaymentFail (CreditCard) gateUp () gateDown () carArrives () carLeaves () Observateur
d’état Type Multiplicité
ticketActive Bool One
ticketReadOk BoolS One
cardInfo CreditCard ZeroOrOne
cardKnown Bool One
paymentOk BoolS One
gateState GateS One
carAtGate Bool One
Table 4.11 – Événements et observateurs d’état
• Nous avons décrit dans la Section 4.4.3 la notion de multiplicité qui sert à préciser si
1
un observateur d’état peut ou non avoir tout le temps une valeur. Dans le Tableau 4.11
2
tous les observateurs d’état ont une multiplicité One (c’est-à-dire ils ont tout le temps
3
une valeur) sauf l’observateur d’étatcardInfoqui a une multiplicitéZeroOrOne. En effet,
4
l’observateur d’étatcardInfoa une valeur uniquement si la carte bancaire est insérée dans
5
le lecteur de carte bancaire, autrement il n’a pas de valeur (sa valeur n’est pas définie).
6
• L’observateur d’état cardInfopeut avoir un ensemble infini de valeurs et par conséquent
7
nous ne pouvons pas l’utiliser pour définir les états car il y aurait un ensemble infini d’états
8
(voir explication dans laSection 4.4.3). Cependant, ignorer cet observateur d’état entraîne
9
un manque d’information et pour cette raison nous proposons un nouvel observateur d’état
10
cardKnownayant un type fini. L’observateur d’étatcardKnown remplaceracardInfodans
11
la table des états et aura un invariant dans la tables des invariants. L’observateur d’état
12
cardInfo n’aura donc pas d’invariant dans la table des invariants et sera ajouté comme
13
attribut dans le diagramme de classes final.
14
• Le type des valeurs d’un observateur d’état peut être un type énuméré, par exemple le type
15
GateS permet de définir les deux états de la barrière :up(quand la barrière est en haut) et
16
down(quand la barrière est en bas). Nous avons également le typeBoolSqui ressemble au
17
type Boolavec la différence que ces valeurs sonttrueS (c’est l’équivalent de true) et naS 18
(qui veut dire note available, c’est-à-dire non disponible). Le diagramme de classes (voir
19
Figure 4.7) est mise à jour avec ces types. Par exemple, pourticketReadOketpaymentOk,
20
nous avions d’abord choisi le type Bool mais constaté que l’information n’est pas toujours
21
disponible. Une opération partielle ne répondait pas non plus au problème. Finalement
22
nous avons opté pour le type BoolS avec deux valeurs trueS et naS (not available). Une
23
remarque sur le choix des noms pour true et na : true est un mot réservé pour le type
24
Bool donc nous avons changé en trueS et na devient naS par homogénéité. La valeur
25
naS (not available) signifie « non disponible », comme par exemple l’observateur d’état
26
ticketReadOk qui prend la valeurnaS dans le cas d’absence de ticket.
27
La Figure 4.7 montre le nouveau diagramme de classe avec l’ajout de deux classes de types
28
énumérésBoolS etGateS. L’outilEasySM permet ce type d’ajout et met à jour systématiquement
29
la liste des types proposés lors de la création des observateurs d’état. Les types Boolean, Integer,
30
Set, etc (présents dans les types OCL) sont prédéfinis dans l’outil.
Figure4.8 – Diagramme de séquence du déroulement du système