Ecole Centrale Paris – année 2012/13 Conception Dirigée par les Modèles TP Conception Dirigée par les Modèles – Diagrammes de comportement1 Description du système à modéliser Cette étude de cas est conçue en trois parties. On s’intéressera tout d’abord à la modélisation du fonctionnement d’une (antique) cabine téléphonique à pièces. Le comportement supposé étant décrit sous forme textuelle, il faudra le formaliser sous la forme d’une machine à états UML. Dans une deuxième partie, on réalisera une version UML de la recette de la mousse au chocolat en s’appuyant sur les diagrammes d’activité. Enfin, pour les plus rapides, et en guise de révisions, une troisième partie consistera à reprendre le comportement de la cabine téléphonique mais en le modélisant cette fois à l’aide des diagrammes de cas d’utilisation et de séquence. Ci-‐dessous les spécifications de la cabine téléphonique à pièces : 1. Le prix minimal d’une communication interurbaine est de 0,2 euros. 2. Après introduction de la monnaie, l’utilisateur a 2 minutes pour composer son numéro. 3. La ligne peut être libre ou occupée. 4. Le correspondant peut raccrocher le premier. 5. Le publiphone consomme de l’argent dès que l’appelé décroche et à chaque unité de temps générée par le standard. 6. On peut ajouter des pièces à tout moment. 7. Lors du raccrochage, le solde de monnaie est rendu. Question n°1 Réalisez la machine à états de la cabine téléphonique dans le cas nominal : l’utilisateur décroche, insère des pièces pour un crédit supérieur à 0,2 euros, appelle son correspondant qui décroche, et mène sa communication. Proposition de correction Ci-‐dessous une modélisation possible conforme à ce premier énoncé. On rappelle que les évènements de déclenchement des transitions sont des appels de méthode (Call event) lorsqu’ils sont suivis de parenthèses (ex : « décroche() »), et des signaux (Signal event) en l’absence de parenthèses (ex : « correspondantDécroche »). Le fait de privilégier l’un ou l’autre est à ce stade arbitraire. En effet, nous ne disposons pas de la modélisation de la classe (ou plus généralement du Classifier) dont cette machine à états est supposée représenter le comportement. Si c’était le cas, alors toute ambiguïté serait levée : on devrait pour les évènements se mettre en conformité avec les opérations et réceptions de signaux 1 Ce sujet est repris du livre « UML2 par la pratique – 7ème édition» (Pascal Roques, éditions Eyrolles, 2009) Diagrammes de comportement Ecole Centrale Paris – année 2012/13 Conception Dirigée par les Modèles affichées dans la classe. Un corollaire est que dans un cas réel, il aurait été nécessaire de modéliser au préalable cette classe… Question n°2 Ajoutez à la modélisation la possibilité qu’a l’utilisateur de raccrocher à tout moment de la conversation (on pourra faire appel à un état composite)…et que le correspondant peut ne pas décrocher. N’oubliez pas, si ce n’est déjà fait, d’ajouter les éventuels états initiaux. Proposition de correction On propose de transformer l’état « Decroché » en un état composite. Ainsi, la transition déclenchée par l’évènenement « raccroche() » s’applique à tous les états contenus dans cet état composite. On évite ainsi de construire une transition déclenchée par « raccroche() » et revenant vers « Raccroché » dans chacun des états traversés depuis le décrochage. On ajoute également un état « Attente crédit » pour la lisibilité, mais il n’est pas obligatoire : on aurait pu placer la transition « insérerPièces() » directement entre l’état initial et l’état « Attente numérotation ». Enfin, l’énoncé est manifestement incomplet : on ne sait pas ce qui se passe lorsque le correspondant ne décroche pas. On fait donc l’hypothèse que dans ce cas, la conversation est coupée lorsque le téléphone du correspondant sonne depuis 90 secondes (d’où l’introduction du timer et de l’état « Conversation coupée »). Question n°3 Ajoutez à la machine à états la modélisation de l’insertion des pièces et la condition de crédit minimal de 0,20 euros. Proposition de correction Pour cette question, on fait l’hypothèse que la classe liée à la machine à états dispose d’un attribut « crédit » qui stocke la valeur du crédit de l’utilisateur. Ce crédit est incrémenté à chaque fois que l’on insère une pièce. L’énoncé indique que l’utilisateur peut à tout moment ajouter une pièce : afin de prendre en compte cette donnée, on place la transition « insérePièce() » sur l’état composite « Décroché » (on suppose donc tout de même que l’insertion de pièces n’est pas prise en compte lorsque le combiné est raccroché…). Notez qu’afin d’éviter qu’à chaque insertion de pièce on se retrouve dans l’état initial, il est Diagrammes de comportement Ecole Centrale Paris – année 2012/13 Conception Dirigée par les Modèles nécessaire d’introduire un pseudo-‐état History qui va nous ramener dans l’état où l’on se trouvait avant le déclenchement de la transition. Question n°4 Affiner la gestion du crédit restant, en cohérence avec les spécifications données plus haut : le crédit diminue à chaque unité de temps (évènement « UT »), et l’utilisateur a la possibilité d’ajouter des pièces à tout instant. Proposition de correction On a déjà modélisé dans la question précédente le fait que l’utilisateur peut ajouter des pièces à tout moment. Pour prendre en compte la diminution de crédit à chaque unité de temps, il suffit simplement d’ajouter une transition déclenchée par UT sur l’état « Conversation ». Question n°5 Diagrammes de comportement Ecole Centrale Paris – année 2012/13 Conception Dirigée par les Modèles Prenez enfin en compte la contrainte temporelle énoncée dans le point 2, en vous appuyant sur la construction de votre choix (une possibilité est d’ajouter le lancement d’un « timer » à une fois le crédit minimal atteint) Proposition de correction On ajoute le déclenchement du timer avant d’entrer dans l’état « Attente Numérotation » comme demandé dans l’énoncé. Cependant, ceci impose que le timer soit stoppé en sortie d’état, par exemple sur les transitions sortantes. Et donc, sur la transition entre « Attente Numérotation » et « Appel en cours », on n’a plus le déclenchement du timer sensé surveiller le délai d’attente du décrochage du correspondant. On propose donc de placer ce démarrage de timer dans une « Entry action » de l’état « Appel en cours ». Voir ci-‐dessous le résultat. Question n°6 Passons maintenant à la modélisation culinaire à base de diagrammes d’activité. On considère la recette ci-‐dessous : -‐ Commencer par casser le chocolat en morceaux, puis le faire fondre. -‐ En parallèle, casser les oeufs en séparant les blancs des jaunes. -‐ Quand le chocolat est fondu, ajouter les jaunes d’œuf. -‐ Battre les blancs en neige jusqu’à qu’ils soient bien fermes. -‐ Les incorporer délicatement à la préparation chocolatée sans les briser. -‐ Verser dans des ramequins individuels. -‐ Mettre au frais au moins 3 heures au réfrigérateur avant de servir. Modélisez la recette à l’aide d’un diagramme d’activité. Note : Dans un premier temps, on fera l’hypothèse que le cuisinier est seul, et on utilisera uniquement des éléments basiques (Opaque Action, Control Flow, Fork / Join Node, Input/Output Pins). On pourra ensuite rendre le modèle plus complexe, en supposant par exemple que deux personnes réalisent la recette (utilisation des Partitions), en modélisation les actions répétées plusieurs fois à l’aide d’Expansion regions, etc. Diagrammes de comportement Ecole Centrale Paris – année 2012/13 Conception Dirigée par les Modèles Proposition de correction Ci-‐dessous un diagramme d’activité présentant le déroulement de la recette dans sa forme la plus simple. Le diagramme suivant (extrait de l’ouvrage « UML2 par la pratique) présente une version plus évoluée, faisant apparaître les données qui transitent entre les actions (les ingrédients, ici : œufs, chocolat, etc) à l’aide d’input/output pins, les actions répétées (ex : casser le œufs) à l’aide d’expansion regions, des nœuds de décision (decision node), etc. Diagrammes de comportement Ecole Centrale Paris – année 2012/13 Diagrammes de comportement Conception Dirigée par les Modèles