Conception Orientée Objet

Ce document porte sur la conception orientée objet, plus précisément sur les diagrammes état-transition. Il s'agit d'une présentation des connaissances et compétences en génie logiciel, visant à expliquer les concepts fondamentaux liés aux états, transitions, événements, gardes, actions, activités, ainsi que la modélisation des comportements dynamiques des objets à travers ces diagrammes.

Concepts de base du diagramme état-transition

Le diagramme état-transition est un modèle dynamique décrivant l'enchaînement des états d'un objet propre à une classe donnée.

Il décrit :

• Les états des objets de cette classe
• Les événements auxquels ils réagissent
• Les transitions qu'ils effectuent

Les concepts fondamentaux sont :

• État : abstraction des valeurs ou des liens d’un objet. Par exemple, l’état d’une banque est solvable si ses actifs excèdent ses dettes.
• Transition : passage instantané d’un état à un autre, franchi lors du passage de l’état source à l’état cible.
• Événement : occurrence ou fait qui a lieu à un moment donné, par exemple un utilisateur qui appuie sur un bouton.
• Garde : condition booléenne qui doit être vraie pour que la transition soit franchie.
• Action : opération sans durée associée à un état ou une transition.
• Activité : opération de durée, exécutée tant que l’objet est dans un état.

Les types d’états

Dans un diagramme état-transition, chaque objet évolue à travers différents types d'états au cours de son cycle de vie.

Pour chaque objet, on distingue :

• État initial : état dans lequel se trouve l’objet à sa création. Un objet a un et un seul état initial.
• États intermédiaires : états par lesquels l’objet peut passer entre sa création et sa destruction. Un objet peut en avoir plusieurs.
• État final : état qui met fin à la vie de l’objet. Un objet peut ne pas en avoir, ou en avoir un ou plusieurs.

Les événements et leurs types

Un événement représente une occurrence qui survient à un instant précis et déclenche des réactions dans le système.

Les différents types d'événements sont :

• Événements d’appel d’opération : déclenchent une opération.
• Événements de signal : émission ou réception d’un signal, qui est un message entre objets. Exemple : départ de vol, bouton souris enfoncé.
• Événements de changement : causés par la satisfaction d’une expression booléenne (mot-clé UML : when). Exemple : when (charge de la batterie < limite inférieure).
• Événements temporels : causés par un temps absolu ou une durée écoulée (mot-clé UML : when ou after). Exemple : when(date = 01/01/2006), after(10 secondes).

La notion de garde

Une garde est une expression booléenne qui conditionne le franchissement d'une transition.

Une garde doit être vraie pour qu’une transition soit franchie après un événement. Elle est notée entre crochets après l’événement.

Exemple :

Disponibleretour[bon état]
retour[mauvais état]

Actions et activités dans un état

Les comportements exécutés au sein d'un état se divisent entre opérations instantanées et opérations durables.

Une action est une opération sans durée, associée à un état ou une transition. Une activité est une opération de durée, exécutée tant que l’objet est dans l’état.

Les actions peuvent intervenir :

• À l’entrée de l’état (préfixe : entry/)
• À la sortie de l’état (préfixe : exit/)
• En réponse à un événement (préfixe : on non evt/)

Une activité est notée par le préfixe do/ dans l’état. Elle peut être interrompue par un événement. À la fin d’une activité, des transitions automatiques (sans événement) protégées par des gardes peuvent être déclenchées.

do/traitementLong

Effet dans une transition

Un effet désigne le comportement optionnel exécuté par l'objet lors du franchissement d'une transition.

En UML 2, un effet peut être une action simple ou une séquence d’actions.

Une action élémentaire peut représenter :

• La mise à jour d’un attribut
• Un appel d’opération
• La création ou destruction d’un objet
• L’envoi d’un signal à un autre objet

Points de décision dans un diagramme état-transition

Les points de décision organisent le flux des transitions en gérant les branchements et les regroupements.

Ils permettent de représenter des partages ou des alternatives dans les transitions :

• Points de jonction : petit cercle plein, utilisés pour partager des segments de transition.
• Points de choix : losange, utilisés pour choisir entre plusieurs transitions alternatives.

États composites

Un état composite, ou super état, regroupe plusieurs sous-états afin de hiérarchiser et de simplifier la modélisation.

Ses objectifs sont :

• Hiérarchiser les états
• Structurer les comportements complexes
• Factoriser les actions

Notation : un état composite est représenté comme un état simple, mais avec ses sous-états contenus dans un compartiment inférieur.

Comportement des transitions :

• Une transition vers la frontière d’un état composite équivaut à une transition vers son état initial.
• Une transition ayant pour source la frontière d’un état composite s’applique à tous ses sous-états.
• Une transition sans déclencheur explicite depuis la frontière d’un état composite est franchissable quand l’état final du composite est atteint.
• Les transitions peuvent traverser les frontières d’états composites à différents niveaux d’imbrication.

États concurrents et historique

Les états composites permettent de gérer à la fois l'exécution parallèle et la mémorisation des états passés.

États concurrents : Un état composite peut représenter l’exécution simultanée de plusieurs automates indépendants. On utilise un séparateur en pointillés pour indiquer les régions concurrentes. L’objet peut être simultanément dans plusieurs sous-états concurrents.

État historique : représenté par un H cerclé, il permet de revenir au dernier état visité dans une région donnée. Un état historique profond (H*) est valable pour tous les niveaux d’imbrication.

Démarche d’élaboration d’un diagramme état-transition

La construction d'un diagramme état-transition efficace nécessite d'appliquer une méthode structurée et progressive.

La démarche comprend :

1. Ne pas modéliser trop de classes simultanément.
2. Identifier les états par une recherche intuitive, l’étude des attributs et associations, et l’analyse des diagrammes d’interactions (séquence et communication) pour chaque scénario.
3. Représenter d’abord la séquence d’états décrivant le comportement nominal de l’objet.
4. Ajouter les transitions correspondant aux comportements alternatifs.
5. Intégrer les comportements d’erreurs.
6. Ajouter les actions et activités.
7. Structurer en sous-états si le diagramme devient trop complexe.

Conseils importants :

• L’automate doit être déterministe : si plusieurs transitions partent d’un état avec le même événement, des gardes doivent garantir le déterminisme.
• Tous les états doivent être accessibles depuis l’état initial.
• Si des états terminaux existent, chaque état non terminal doit pouvoir atteindre un état terminal.

Exemple : Diagramme d’états d’une classe Mission

L'application de la démarche d'élaboration s'illustre à travers la modélisation du cycle de vie d'une classe Mission.

Le comportement nominal est :

• État initial : En attente
• Création avec create(nom,nature)
• Validation avec valider(DateDepartPrevue)
• Départ
• En cours
• Terminé
• Arrivée

Transitions alternatives :

• Possibilité de modifier ou annuler une mission jusqu’à une heure avant le départ prévu.
• Au bout de 48h, une mission terminée est archivée et supprimée de la mémoire vive.

Actions et activités :

• Activité : définir une mission dans l’état "En attente".
• Actions : création d’une FeuilleDeRoute ou d’un SuiviMission, notification du répartiteur, libération des ressources, archivage.
• L’activité définirMission comprend un traitement complexe avec :
• Affectation de commande
• Affectation de ressources, comprenant en parallèle la recherche d’un véhicule libre de tonnage suffisant et la recherche d’un chauffeur qualifié.

Méthode : bonnes pratiques et erreurs à éviter

La conception de diagrammes état-transition repose sur la maîtrise des notations et la rigueur dans l'enchaînement logique.

Les bonnes pratiques incluent :

• La maîtrise précise des concepts fondamentaux (état, transition, événement, garde, action, activité).
• La capacité à expliquer clairement chaque notion avec des exemples concrets.
• La rigueur dans la démarche d’élaboration, notamment la progression du comportement nominal vers les cas alternatifs et erreurs.
• L’attention portée au déterminisme de l’automate, avec l’usage correct des gardes pour éviter les ambiguïtés.
• La structuration des diagrammes complexes par états composites et concurrents.
• La bonne utilisation des notations UML spécifiques (points de jonction, points de choix, états historiques).

Les erreurs courantes à éviter :

• Confusion entre action et activité.
• Omission des gardes nécessaires pour garantir le déterminisme.
• Transitions mal définies vers ou depuis des états composites.
• États inaccessibles depuis l’état initial.
• Manque de clarté dans la présentation des concepts ou dans la démarche d’élaboration.

En résumé, la méthode consiste à bien comprendre et appliquer les définitions, utiliser la notation UML adéquate, et construire un diagramme clair, complet et déterministe.