|
MODULE No 25 |
|
Titre : États |
|
But : Introduire les « états » et les transitions à l’aide d’un exemple |
|
Antécédents : Module 11 |
|
Corps : On appelle automate, une machine qui change (se meut) en fonction de lois internes et d’événements qui la font passer d’un « état » à un autre. Les automates qui nous intéressent dans le cadre de notre cours sont les automates à états finis, c’est-à-dire les automates qui ont un nombre fini d’états possibles. Est-ce que les machines[1] (les automates) ayant un nombre fini d’états sont assez nombreuses pour qu’elles méritent une place à part ? Oui. Le nombre d’états possibles d’un objet d’analyse, dépend de comment nous (nous, les humains, qui décrivons ou concevons la machine) choisissons les états : de la manière que nous avons d’oublier les détails dans l’évolution temporelle de l’objet (abstraction). Nous considérerons les automates qui passent d’un état à l’autre de manière déterministe via ce qu’on appelle des transitions qui sont déclenchées par des événements. Si on considère que toute notre analyse « baigne » dans une approche objet, on peut considérer les automates comme des moyens pour décrire le comportement d’un objet (des objets d’une classe donnée). Voici quelques définitions : Événement : « Quelque chose » qui arrive à un certain moment et dans une certaine place et qui n’a pas de durée (du point de vu du problème que l’on est en train de considérer). Exemples d’événements : arrivé du train, mort du père, click d’un bouton. En UML un événement peut avoir des paramètres pour transmettre des informations de l’objet qui a créé l’événement à celui qui le reçoit. L’événement « click de souris », par exemple, aura minimalement comme paramètre la position du curseur au moment du click. Le temps auquel l’événement se produit est un paramètre implicite toujours présent. Une instance d’un événement a une valeur pour chaque paramètre. Des événements peuvent être ou ne pas être corrélés. Ils peuvent aussi être organisés en classe d’événement. Un événement pour être un « événement » doit être significatif dans le cadre du problème que l’on analyse. Le choix des événements est souvent assez subjectif (une autre difficulté de l’analyse). Le passage du temps est un événement spécial : fort spécial ! Un événement peut provoquer un changement d’état. Un événement peut être différé s’il n’implique pas une transition d’état : c’est-à-dire qu’il n’est pas traité dans l’état quand il y arrive mais il est mis dans une file d’attente et traité quand les conditions dans l’état le permettent. État : représente une situation stable d’un objet. Une situation dans laquelle l’objet répond toujours de la même manière aux événements. Dans un état un objet peut exécuter des activités ou attendre des événements. Un état (dans l’analyse) doit avoir une signification par rapport au domaine et un objet doit réagir différemment dans deux états différents : s’il n’y a pas des différences dans ses réactions, il ne s’agit pas de deux états mais d’un seul état. Si on veut conserver deux états, malgré le manque de différences, il faut trouver de bonnes motivations. Exemple 1 : pour un livre dans une librairie on peut considérer deux états : - Bon état - Mauvais état. Un livre dans un mauvais état est retiré de la vente ou est vendu en solde (donc un objet de la classe livre réagit différemment à la vente en fonction de son état). Facile d’imaginer la même chose pour une personne ayant deux états de santé : bon et mauvais. Exemple 2. Domaine bancaire. On pourrait imaginer que chaque changement de 0,01$ dans un compte cause un changement d’état — il y a bien quelque chose qui a changé ! Dans une telle définition d’état de compte, pour un étudiant moyen de l’UQAM qui a dans son compte en banque 100 000$, on aurait 10 millions d’états différents : ce qui est un peu trop surtout si on veut représenter graphiquement les changements d’état (comme on fait très souvent en génie logiciel). Ce qui est certain, par exemple, c’est que le compte ne réagit pas différemment quand il est dans l’état 110,04 ou 110,06. Définir un état différent pour chaque changement de 0,01 $ n’a aucune signification pour la banque (pour le client non plus), mais quand le compte passe de + 0,01 à - 0,01 le compte peut réagir différemment. Pourquoi ? Parce que dans le premier état on a de l’argent en banque et dans le deuxième on a une dette. Puisque le changement de quantité d’argent positive à quantité négative est significatif on peut considérer deux états. Ces deux états sont sans doute plus importants pour la banque que pour le client (nos deux parties prenantes principales) : le fait que le client ait un cent à la banque ou qu’il soit débiteur d’un cent ne change pas grand-chose à sa richesse ! C’est parce que le passage en négatif est important pour la banque qu’il devient important pour le client. Même si je ne suis pas un expert (ni théorique ni pratique) des banques, je suis sûr qu’il y a des frontières dans la quantité d’argent d’un compte au-delà desquelles le comportement du compte change (augmentation du taux d’intérêt, par exemple). Transition : une relation entre deux états représentée par un arc dans le diagramme d’état. Une transition peut être protégée (guarded) par une condition logique. La transition est causée par un événement. Diagramme d’état de l’automate (de la machine) (DE) : un diagramme qui relie les états à l’aide de transitions causées par des événements. Un objet simple (qui n’est pas un agrégat) est dans un seul état à la fois (état actif). Action : Une opération instantanée associée avec un événement. Il s’agit du plus petit pas computationnel définissable en UML. Note Encore une fois « instantané » et « certain temps » n’ont pas de définition objective mais dépendent du domaine. Fin de la note Activité : Spécification d’un comportement exécutable constitué de sous-unités qui s’exécutent de manière séquentielle ou concourante. Une séquence d’action par exemple. Condition (condition de garde) : une fonction booléenne qui conditionne la transition. Effet : Une action ou une activité qui est exécuté quand une transition est déclenchée Voici un exemple de DE avec deux états et une transition.
Pour essayer de mieux comprendre les états des objets et leurs transitions nous allons parler de « État civil », ce dont vous avez tous entendu parler. Mariage et tout le
tralala (Italie 1960) Voici un exemple très simple des changements d’état (du point de vue de l’état civil) dans une société catholique comme la société italienne, avant l’introduction du divorce. (Je n’emploie pas l’exemple du Québec car, à cause du partage de compétences avec Ottawa, avant 1968, le divorce était une « chose » fort complexe) Voici un premier exemple assez simple
Le cercle noir est l’état initial, l’état dans lequel un objet entre lors de sa création. Dans notre exemple on suppose que, après la naissance, l’objet (l’individu) passe dans l’état célibataire si un événement est envoyé à la municipalité (Municipalité.Née) avec comme paramètres le nom de l’enfant, les noms des parents et la date de naissance. Et un enfant mort-né ? Devient-il célibataire ? Il est clair qu’une trace doit rester dans l’état civil. En effet, dans certains pays l’enfant mort-né est enregistré lorsqu’il a plus de trois mois (de vie intra-utérine). Ce qui implique qu’il sort automatiquement de l’état de Célibataire pour passer dans l’état Mort mais dans « son passage rapide » il a acquis un nom. Ce cas particulier (ou ce détail si vous voulez) est un bon exemple du dicton « le diable est dans les détails ». L’individu reste dans l’état célibataire jusqu’à l’événement AccordAutre. Mais pour que la transition puisse s’opérer il faut que les conditions suivantes soient vraies : 1) l’autre est de sexe différent ; 2) les deux ont l’âge légal. Et, surtout ! il faut qu’un autre individu accepte de marier « notre objet » (ce qui est dit implicitement par AccordAutre) Lors de la sortie de l’état l’individu envoie un événement (désire mariage) à l’église avec les noms (I1 et I2) des deux individus qui veulent se marier Lors de la transition ils signent l’acte de mariage (SAM) ce qui les fait passer officiellement à l’état Marié(e). Dans l’état Marié(e) est indiquée l’activité que, selon l’Église catholique, les mariés doivent faire. Il y a une seule
façon de sortir de l’état Marié : Un individu qui est dans l’état Veuf(ve) peut se remarier. Note En ce qui concerne le mariage, dans notre exemple, il n’y a pas de différence entre hommes et femmes même si en Italie l’âge légal pour le mariage était différent. Fin de la note Ci-dessous nous avons un diagramme réalisé avec RR qui a été un peu plus complexifié avec l’ajout d’état de prêtre et de sœur. On peut bien sûr passer à l’état de sœur et de prêtre même (surtout) en partant de célibataire (nous ne l’avons pas représenté parce que l’image devenait trop complexe pour la mettre dans ce document-ci).
Dans ce cas pour se marier il faut ajouter la condition : 3) ils ne sont ni prêtre ni sœur catholiques. Dans l’état Prêtre on a deux activités principales : Célébrer messe et Prier tandis que dans l’état Sœur on n’a que Prier. Nous allons expliquer le formalisme UML tel que mis en œuvre par RR à l’aide des éléments du diagramme. État. Un état est représenté par un rectangle aux coins arrondis, Le nom de l’état est en haut (Célibataire) et en dessous de la ligne il y a les actions qui peuvent être faite en entrant dans l’état (mot clef entry), en sortant (mon clef exit, comme dans l’exemple ci-dessous), suite à la réception d’un événement (mot clef event) ou bien l’activité faite « normalement » dans l’état (mot clef do)
La figure ci-dessus dit qu’à la sortie de l’état l’événement Désire mariage est envoyé à Église (le mot qui suit le symbole « ^ » est le nom de l’objet auquel est envoyé l’événement dont le nom est séparé par un « . »). Ident1 et Ident2 sont les arguments de l’événement Désire mariage et sont mis entre parenthèses. Transition Premier exemple. Dans le diagramme d’état, sur la transition entre Début et Célibataire, apparaît la spécification de la transition : Naissance (ident) ^ Municipalié.Née (Ident, date, Parents) où : Naissance est l’identificateur de l’événement qui cause la transition vers Célibataire ; Ident est l’argument de l’événement (nom de celui qui est né) Municipalité est l’objet auquel est envoyé l’événement Née. Née est l’événement envoyé à Municipalité. Ident, date, Parents sont les arguments de l’événement Née Deuxième exemple. La transition
entre Veuf(ve) et Marié(e) (Accord de l’autre (Ident) [sexe diffèrent et
l’âge de l’autre ok]/SAM) nous permet de montre […] nous donne les conditions qui doivent être vraies afin que la transition puisse s’effectuer. Dans ce cas être de sexe différents et le bon âge pour le mariage. /SAM donne l’action qui est faite lors de la transition. Dans votre SEL chaque état du diagramme devra être décrit par la fiche suivante : Gabarit pour les États Nom : nom de l’état Description : Une description de l’état avec les conditions qui le caractérisent. Événements : événements qui conduisent dans l’état avec les arguments éventuels Action à l’entrée : action à exécuter lors de l’entrée dans l’état. Action à la sortie : action à exécuter lors de la sortie de l’état Conséquences des événements acceptés : pour chaque événement l’action à faire et le prochain état à atteindre. Exemple d’emploi du gabarit pour l’état Veuf(ve) Nom : Veuf(ve) Description : Il s’agit de l’état dans lequel un individu qui était marié à perdu son conjoint(e). Il est un état différent de Célibataire car l’individu a des responsabilités et des droits différents (Héritage, enfants, etc.) Événements : Mort du (de la) conjoint(e) Action à l’entrée : Pleure Action à la sortie : envoie de l’événement Désire Mariage à l’église avec le nom des deux personnes qui désirent se marier. Conséquences des événements acceptés : Événement 1 : Accord de l’autre Conditions : âge de l’autre ok et sexe différent Nouvel état : marié(e) Pas d’autres événements. Mais, est-ce vrai que quand l’individu meurt il doit « sortir » du diagramme d’état, ou est-ce qu’il entre dans un nouvel état (mort) comme il est montré dans le diagramme suivant ?
Il est sans doute préférable cette deuxième solution : l’individu entre dans un nouvel état car du point de vue légal il continue à « exister » même s’il n’existe plus en chair et en os. Un individu du point de vue du diagramme d’état pour l’état civil est… immortel. Le diagramme suivant montre le nouvel état de divorcé qui a été introduit en 1976 en Italie :
Si au lieu de considérer l’Italie en 1980 on considère le Québec en 2007 non seulement la condition [sexe différents] est disparue, mais il y a un autre état pour ceux qui sont en couple : « conjoint de fait ». Cette prolifération (relative) d’états nous incite à nous demander s’il ne faudrait pas introduire des généralisations pour les états (comme pour les concepts). On pourrait représenter à l’aide de deux états « macro » notre problème de l’évolution de l’état civil d’un individu.
Lorsque l’objet sort de l’état célibataire (il y a quatre sorties dans le diagramme) il passe au début de l’état de couple où il va à « marié » si SAM est vrai et à « vie commune » si SAM est faux. De « vie commune » l’objet passe à « conjoint de fait » après un période fixé par la loi. « Couple » a à son intérieur une autre généralisation celle qui contient les états différents de « marié ». À la sortie de cet état il y a une décision : ou bien l’objet tombe dans l’état marié suite à SAM ou il revient à l’état célibataire. Note Célibataire englobe veuf. Fin de la note
|
|
Conséquents : Avoir une idée claire sur ce qu’est un état et une transition. |
|
Notes : 1) À partir de tous les états (malheureusement !) on peut passer à l’état… final. L’événement qui cause la mort, dans notre cas, est sans importance. 2) À ne pas oublier que tandis que les diagrammes d’interaction décrivent le comportement d’un ensemble d’objets, les diagrammes d’état décrivent le comportement d’un seul objet (objet « générique » d’une classe donnée). 3) il ne faut pas essayer de représenter les états de tous les objets, il faut choisir les objets dont l’évolution est significative dans le sens qu’elle permet de comprendre le domaine. Nous sommes des analystes et tout ce que nous voulons faire c’est comprendre et décrire ! Dans certains systèmes, il est inutile de faire des diagrammes d’état. 4) Tandis que dans les descriptions des CU la partie textuelle est fondamentale et les diagrammes sont moins importants lorsqu’on décrit les états, les diagrammes sont fondamentaux car la partie visuelle nous permet de suivre plus facilement l’objet dans son évolution. |
