Unified Modeling Language. langage de modelisation... langage et non pas méthode approche orientée objet attentif aux utilisateurs

Transcription

1 Unified Modeling Language langage de modelisation... langage et non pas méthode approche orientée objet attentif aux utilisateurs Je remercie Laurent Audibert qui m a permis de reproduire certains de ses schémas. Vous trouverez son polycopié, très très complet, sur le site UML n est pas une méthode. UML Néanmoins, pour les concepteurs d UML, tout processus de développement devrait être piloté par les cas d utilisation centré sur l architecture itératif et incrémental

2 Cycle de vie AUP Les phases Commencement, Elaboration, Construction, Transition se succèdent et, divisées en itérations, constituent le cycle de vie du projet. Une itération contient les disciplines Modélisation, Implémentation,... dans des proportions relatives à l itération. voir le schéma sur Les Phases A.U.P. Commencement : le but est d identifier la portée initiale du projet, une architecture potentielle pour l application, de s accorder sur le financement initial du projet et l acceptation des dépositaires (utilisateurs, managers,...). Elaboration : le but est de valider l architecture de l application. Construction : le but est de construire, de façon régulière et progressive, le logiciel qui répond aux besoins les plus prioritaires des dépositaires. Transition : le but est de valider et d installer l application dans l environnement de production.

3 Les Disciplines A.U.P. Modélisation : comprendre le domaine de l application, l environnement du projet et identifier une solution viable pour le problème. Implémentation : transformer le modèle en code exécutable et mettre en œuvre des tests de bas niveau (unit tests) Test : exécuter une évaluation objective pour assurer la qualité (recherche de défauts, vérification de l adéquation aux exigences initiales). Installation : Livraison de l application et mise à disposition des utilisateurs finaux. Gestion de configuration : gestion des prototypes. Gestion de projet : assignation des tâches, suivi de progression dans le but de ne pas dépasser les délais et le budget. Environnement. vérification de la disponibilité matérielle et logicielle, suivi des directives et des normes. Remarques Les concepteurs de méthodes essaient de formaliser une réalité évidente : il est difficile de trop figer les phases d un développement logiciel, les activités se chevauchent, les points de vue sont multiples... Un cycle itératif semble refléter mieux la réalité du développement logiciel. Il n y a pas une démarche absolue. Il faut adapter selon le projet. Pour un petit projet, il est possible que l analyse soit satisfaisante dès la première itération. Plus le projet est conséquent, plus il faut revenir sur l analyse et la conception. Même à l intérieur de la conception, une démarche itérative est souvent bien adaptée : décrire les besoins, décrire les classes, puis décrire les scénarios qui affinent les classes, qui eux-mêmes affinent les scénarios...

4 Une démarche possible... à gros traits étude d opportunité : description générale de l application à réaliser, faisabilité, analyse (quoi faire) : mise en évidence des principaux cas d utilisation, scénarios (au minimum inal), diagrammes de séquences, conception (comment) : description détaillée de l application (architecture), éventuellement maquette de l application, validation par l utilisateur 4. plan de développement, formation d une équipe, environnement de travail (bacs à sable, gestionnaire de versions...), 5. mise en œuvre des itérations jusqu à obtenir satisfaction de l utilisateur (a) description des scénarios traités par l itération (nouveaux ou/et à corriger) (b) affectation des tâches (c) définition des critères d évaluation (d) implémentation (dans les bacs à sable) (e) test des unités, des classes (f) intégration dans le prototype, documentation (g) présentation à l utilisateur futur, validation/évolution 6. intégration de l application dans l environnement final, tests, formations Phase d élaboration à gros traits (avec les diagrammes UML) 1. description générale de l application à réaliser (pas de matériel, logiciel...) 2. mise en évidence des principaux cas d utilisation 3. itérations, pour chaque cas d utilisation, jusqu à description assez fine (a) description des scénarios, scénario inal et exceptions description textuelle, définition de tests à passer diagramme de collaboration (de communication), diagramme de séquence (b) identification des classes diagramme des classes (c) utilisation possible de diagrammes d états/transitions (d) intégration des classes dans le modèle du domaine 4. réalisation d une maquette/prototype, documentation de cette architecture 5. plan de développement pour le projet (les itérations, cahier des charges, évaluations...) 6. validation par l utilisateur

5 plan de présentation objets, messages, application...description avec UML. diagrammes de classes diagrammes de cas d utilisation diagrammes d activités diagrammes de séquence diagrammes d états/transitions objet Un objet, au sens informatique, est une représentation abstraite d entités du monde réel ou virtuel. moi :individu = Terlutte pré = Alain le fichier du poly daten = 13/07/1951 = poly.pdf taille = 375 Ko mon vélo type = randonneur couleur = blanc poids = 7kg plateau = 22 pignon = 28 moi :enseignant = Terlutte pré = Alain statut = MdC

6 objet Un objet est caractérisé par un état : les informations qui le caractérisent un comportement : les opérations (actions) qu il peut faire une identité, caractéristique de son existence mon vélo type = randonneur couleur = blanc poids = 7kg plateau = 22 pignon = 28 changerbraquet(plateau,pignon) freiner() moi :individu = Terlutte pré = Alain daten = 13/07/1951 vue statique : objet, lien Des informations caractérisent les objets. Il existe une structure, une répartition de toutes les informations dans des objets différents. Il existe des liens entre les objets. mon vélo type = randonneur couleur = blanc poids = 7kg plateau = 22 pignon = 28 chbraquet(plt,pgn) freiner() propriétaire de moi :individu = Terlutte pré = Alain daten = 13/07/1951

7 vue statique : objet, lien Il peut exister des liens ayant des significations différentes. mon vélo type = randonneur couleur = blanc poids = 7kg plateau = 22 pignon = 28 chbraquet(plt,pgn) freiner() propriétaire de utilisateur de utilisateur de moi :individu = Terlutte pré = Alain daten = 13/07/1951 alter ego :individu = Troublé pré = Amédée daten = 21/10/1996 Tout dépend du système à décrire : les utilisations ou/et les possessions de vélos... La vue statique conduira au diagramme de classes. vue dynamique : objet, message Les objets peuvent communiquer, interagir. Il existe des liens entre les objets. L un peut demander à l autre de réaliser une opération. Les objets échangent des messages. mon vélo type = randonneur couleur = blanc poids = 7kg plateau = 22 pignon = 28 chbraquet(plt,pgn) freiner() chbraquet(32,28) moi :individu = Terlutte pré = Alain daten = 13/07/1951

8 objet, message Si l objet est correctement réalisé, après réception et traitement du message, l objet aura changé d état. mon vélo type = randonneur couleur = blanc poids = 7kg plateau = 32 pignon = 28 chbraquet(plt,pgn) freiner() moi :individu = Terlutte pré = Alain daten = 13/07/1951 cas d utilisation La description dynamique commencera par la description des besoins client Commander boisson Demander remboursement Réparer service maintenance Approvisionner Système à développer

9 diagramme de collaboration ou diagramme de communication Diagramme montrant des objets dans une situation de communication particulière (insistence sur l organisation des objets). :utilisateur 1: choixboisson(petit café sucré) panneau commande 3: chauffereau() distributeur 2: PréparerCafé(0.5,0.2) Ce diagramme se lit : l utilisateur envoie d abord le message choixboisson(petit café sucré) à l objet panneau de commande, puis l objet panneau de commande envoie le message préparercafé(0.5,0.2) à l objet distributeur, enfin l objet distributeur s envoie (réalise) le message chaufereau(). Ce diagramme décrit un scénario. diagramme de séquence Diagramme proche permettant de décrire une séquence beaucoup plus détaillée. Il n est pas nécessaire d indiquer la chronologie (elle est implicite). :utilisateur panneau commande distributeur choixboisson(petit café sucré) préparercafé(0.5,0.2) chauffereau() t

10 UML : les diagrammes UML propose neuf types de diagrammes pour décrire les vues statiques (structure) et dynamiques (comportement) d un système. diagrammes structurels diagramme de classes diagramme d objets diagramme de composants diagramme de déploiement diagrammes comportementaux diagramme des cas d utilisation diagramme états/transitions diagramme d activités diagramme de séquences diagramme de collaboration (de communication) classes Les objets appartiennent souvent à des ensembles qui ont les mêmes caractéristiques. Une classe est une abstraction décrivant l ensemble. Tous les objets d une même classe auront les mêmes attributs (avec des valeurs particulières) et les mêmes opérations (les mêmes possibilités de comportement). Un objet est une instance d une classe. vélo type couleur poids plateau pignon chbraquet(plt,pgn) freiner() instance de mon vélo : vélo type = randonneur couleur = blanc poids = 7kg plateau = 22 pignon = 28 chbraquet(plt,pgn) freiner() Selon le contexte, on peut ne pas faire apparaître la description complète d une classe.

11 classes On doit parfois faire référence à une instance quelconque d un objet. vélo type couleur poids plateau pignon chbraquet(plt,pgn) freiner() instance de : vélo type couleur poids plateau pignon chbraquet(plt,pgn) freiner() Le rectangle de droite (:classe) représente un objet quelconque de la classe vélo. classes, visibilité des attributs et des opérations Certains attributs peuvent être inaccessibles à l utilisateur. Il est fréquent de ne pas donner un accès direct aux attributs mais de contrôler cet accès par les opérations. De la même façon, certaines opérations peuvent être inaccessibles à l utilisateur. + attribut ou opération public, visisble par tous les objets # attribut ou opération protégé, visible par les objets de la même classe et ceux des sous-classes - attribut ou opération privé, visible par les objets de la même classe individu - - pré - daten + poids + getnom() + setnom(nv)

12 classes, syntaxe simplifiée des attributs Visibilité Nom Attribut : Type = Valeur Initiale Le type peut être un type prédéfini (entier, booléen, chaîne de caractères,...) ou une classe... un tableau, une énumération... Il est possible de définir des attributs dérivés, c est à dire calculé à partir d autres attributs. Il est possible de préciser qu un attribut n est pas modifiable (constante, gelé). individu - : Cha^ıne - pré : Cha^ıne - daten : Date + poids : Réel + sexe : Sexes + célibataire : Booléen = Vrai + préenfants [0..*] : Cha^ıne + /^age : Réel énumération Sexes féminin masculin ^age = DateCourante - daten

13 classes, syntaxe simplifiée des opérations Visibilité Nom Opération ( Arguments ) : Type Retourné Les arguments forment une liste précisant le de l argument et son type. On peut aussi préciser sa direction (in (par défaut), out, inout). individu - : Cha^ıne - pré : Cha^ıne + GetNom() : Cha^ıne + SetNom ( nv : Cha^ıne ) : void Il est aussi possible d avoir des attributs ou des opérations de classe, c est à dire partagés par toutes les instances de la classe. Cela permet, par exemple, des mécanismes pour débrer les instances d une classe. associations Une association représente une relation entre des classes. La plupart des associations sont binaires. Les associations peuvent être mées et un triangle peut en préciser le sens de lecture. cours intitulé jour heure fait enseignant pré

14 associations Une association peut être réflexive. individu enfant de pré Des classes peuvent être reliées par plusieurs associations, si elles ont des significations différentes. départ de trajetsncf noligne jour heure ville gare arrivée de associations Lorsqu une association concerne les instances de la classe avec une signification particulière, il est possible de préciser le rôle de l association à cette extrémité. cours intitulé jour heure fait enseignant individu pré suit étudiant individu parent pré enfant enfant de

15 classe-associations On peut avoir envie d affecter des attributs à une association. étudiant pré est évalué sur discipline libellé date note classe-associations On peut remplacer cette classe-association par une association. étudiant pré discipline libellé passe concerne épreuve date note Le diagramme est souvent plus simple à lire en faisant cette transformation.

16 associations Une association peut relier plus de deux classes. lieu rue ville acheteur pré <> vendeur pré associations De la même façon, on peut remplacer l association par une classe, surtout quand l association utilise une classe-association qui fait apparaître des attributs. rue ville lieu acheteur pré date contrat vendeur pré

17 navigabilité dans les associations Par défaut, une association est navigable dans les deux sens. Une notion de navigabilité peut être indiquée par une flèche. Elle signifie que les instances d une classe voient les objets instances de l autre classe, mais pas l inverse. Par exemple, pour un forum de discussion, abonné pré voit message texte signifie l anonymat : un abonné peut avoir accès aux messages mais on ne peut pas retrouver l abonné à partir du message. multiplicité des associations Chaque extrémité d une association peut porter une indication de multiplicité indiquant combien d objets d une classe peuvent être liés à un objet de l autre classe cours intitulé jour heure 0..* fait 1 enseignant pré Un cours est fait par un seul enseignant. Un enseignant fait un bre de cours qu on ne peut pas limiter ; il peut ne pas faire de cours.

18 multiplicité des associations La multiplicité peut être une valeur, un intervalle ou un bre indéterminé (symbole ). A 2 B signifie à une instance de la classe A correspondent un bre indéterminé d instances de la classe B et à une instance de la classe B correspondent 2 instances de la classe A A 0, B signifie à une instance de la classe A correspondent de 1 à 10 instances de la classe B et à une instance de la classe B correspond 0 ou 1 instance de la classe A A B signifie à une instance de la classe A correspond exactement 1 instance de la classe B et à une instance de la classe B correspond au moins 1 instance de la classe A multiplicité des associations Les multiplicités courantes sont les suivantes 1 un et un seul 0..1 zéro ou un * de zéro à plusieurs 0..* de zéro à plusieurs 1..* de un à plusieurs x un bre entier x (par exemple 2 ou 7 ou...) x..y de x à y (par exemple 2..7) x..* x et plus (par exemple 2..*)

19 multiplicité des associations étudiant pré 0..* suit 1..* cours discipline jour heure 0..* fait 1 enseignant pré Ticket Quinté PMU numéro ticket heure du pari 0..* concerne 5 cheval partant no dossard couleur casaque multiplicité des associations Les multiplicités des relations n-aires, avec n > 2, ne sont pas simples à lire. Prenons le cas d une relation ternaire. Pour déterminer les multiplicités, il faut se poser la question si je choisis un couple dans deux classes, combien d objets lui sont associés, dans la troisième? lieu/annonce rue ville acheteur pré <> vendeur pré

20 multiplicité des associations lieu/annonce rue ville * acheteur pré <> vendeur pré Si je prends un lieu et un acheteur, combien puis-je leur associer de vendeurs? 1 seul. Si je prends un vendeur et un acheteur, combien puis-je leur associer de lieux? 0 à plusieurs. Le client peut n avoir rien acheté ou, fortuné, avoir acheté plusieurs lieux. Si je prends un lieu et un vendeur, combien puis-je leur associer d acheteurs? 0 ou 1. Si on considère le lieu comme une annonce, le fait qu un lieu puisse être vendu plusieurs fois serait impossible... ce n est plus le même lieu ; le temps a passé, le prix est différent. contraintes sur les associations Il est possible de préciser des contraintes sur des associations. Par exemple, pour indiquer qu un directeur d UFR est forcément un enseignant mé dans l UFR. mé dans enseignant noligne jour heure {sous-ensemble} ville UFR directeur de Le langage OCL permet d écrire de multiples types de contraintes que l on peut faire porter sur les associations ou sur les classes.

21 agrégation L agrégation est une association particulière. Elle indique une relation de dépendance plus forte (type maître/esclave ou contenance) ; une classe domine l autre. équipe d équipe 0..* 1..* pré individu L agrégation n implique pas une réalisation particulière (pas de traduction en SQL). composition Une composition est une agrégation particulière. Dans le cas d une composition, l objet contenu ne peut être partagé ; il n appartient qu à un objet contenant. De plus, une composition implique une durée de vie. La suppression d un objet contenant implique la suppression des objets contenus. ville hôtel 1 1..* chambre numéro étage bre de lits La composition ne produit pas non plus une traduction particulière en SQL mais on devrait se poser la question des suppressions...

22 généralisation/spécialisation Une généralisation est une association de classification. Elle permet d indiquer qu une classe est une forme particulière d une autre classe. Le donnant la sémantique de cette association pourrait être est une sorte de. titre oeuvre film durée livre bre de pages roman personnage principal Cela signifie qu un livre est une oeuvre, que toute attribut/opération d une œuvre est valide pour un livre. Par exemple, un livre a un titre et un roman a un bre de pages. On parle d héritage : la sous-classe hérite des attributs de la classe supérieure. Il peut y avoir héritage multiple quand une classe est sous-classe de plusieurs classes principales. Elle hérite des attributs et des opérations des classes principales. diagramme des cas d utilisation Représentation des besoins exprimés par les utilisateurs. Identifier les acteurs. Identifier les besoins. Mettre en évidence des parties de cas d utilisation. inclusion : notion de sous-programme qui sera exécuté par le scénario principal extension : notion de sous-programme optionnel du scénario principal généralisation, spécialisation : cas particuliers du cas d utilisation (retirer des euros est une spécialisation de retirer de l argent) L analyse des besoins par les cas d utilisation s accommode très bien d une approche itérative et incrémentale.

23 diagramme des cas d utilisation Première description des fonctionnalités du système, on représente les acteurs et leurs besoins Acteur Cas d utilisation = fonctionnalité du système Système à développer qu on détaille progressivement... Figure 1: exemple de diagramme des cas d utilisation (L. Audibert)

24 diagramme des cas d utilisation Un cas d utilisation synthétise un ensemble de scénarios avec des traitements optionnels et des traitements d erreurs. Un scénario est une instance de cas d utilisation (une description de ce qui doit se passer). Le scénario inal est le scénario le plus court, celui où tout se passe correctement. Les traitements optionnels sont des extensions du scénario inal. Ils peuvent apparaître dans le diagramme sous forme de traitements d extension. Mettre en évidence des parties de scénario qu on peut isoler conduit aux inclusions. Mettre en évidence des cas particuliers conduit à des spécialisations. Ne pas hésiter à décrire les scénarios de façon textuelle. Chaque scénario sera décrit plus tard par un diagramme d activités et/ou par un diagramme de communication et/ou par un diagramme de séquence. cas d utilisation, description textuelle cas d utilisation : retrait d argent (première ébauche) scénario inal : 1. l utilisateur introduit sa carte 2. l utilisateur s identifie 3. le système propose différentes sommes 4. l utilisateur choisit une somme 5. le système donne la somme inclusion (commune à plusieurs opérations) : l utilisateur introduit sa carte et s identifie point d extension 4 : l utilisateur désire une autre somme exception 4 : l utilisateur peut annuler l opération Il faudra affiner : le système a-t-il du stock de billets?, l utilisateur a-t-il fait d autres retraits durant la semaine?...

25 Figure 2: exemple de diagramme des cas d utilisation (L. Audibert) Figure 3: exemple de diagramme des cas d utilisation. Relations d inclusion pour décomposer un cas complexe (L. Audibert)

26 diagramme de séquence simplifié Un cas d utilisation représente un ensemble de scénarios. Ces scénarios devraient être décrits de façon textuelle. Pour formaliser la description d un scénario, il est possible d utiliser une forme simplifiée de diagramme de séquence. Le diagramme de séquence montre les interactions entre objets en insistant sur la séquence des interactions. Il va donc permettre de décrire les interactions entre les acteurs et le système, sans rentrer dans la description du système. diagramme de séquence simplifié :utilisateur :système demandelisteetudiants() liste() choixetudiant(noss) informationsetudiants() modifierpré(nvpré) t

27 diagramme d activités Si le cas d utilisation n est pas un simple échange entre le système et l utilisateur, s il fait intervenir plusieurs acteurs, il peut être intéressant de le décrire avec un diagramme d activités. Les états représente des actions. Les transitions assurent la chronologie des actions ; quand l une est terminée, la suivante commence. transition [condition] action 1 action 2 Figure 4: exemple de diagramme d activité (L. Audibert)

28 Figure 5: exemple de diagramme d activité (L. Audibert) diagramme d activités Les diagrammes d activités permettent aussi de représenter des flux de données. On décore les actions par des pins indiquant les données nécessaires aux actions ou produites par les actions. Enfin, ces diagrammes peuvent représenter le fait qu une activité peut générer des exceptions.

29 diagramme de séquence Il décrit la décomposition d un scénario en opérations. Principe général : un objet reçoit un message qui déclenche une opération. L opération a un résultat qui constitue un message envoyé à un autre objet. La numérotation des messages indique la chronologie. Le temps apparaît aussi dans la dimension verticale. :individu :Trésor public :Compta déclaration(salaires) montant:=calcul(salaires) imp^ot(montant) t

30 Les messages Dans les diagrammes de communication et dans les diagrammes de séquence, la communication se fait par envoi de messages. Voici la syntaxe des messages : synchro/ garde séquence: itération résultat:= message (paramètres) La synchronisation indique la liste des messages qui doivent être envoyés avant que celui-ci ne le soit. La garde est une expression booléenne, une condition à l envoi du message. La séquence est un numéro qui indique le rang du message, c est-à-dire son numéro d ordre par rapport aux autres messages. Les messages sont numérotés à la façon de chapitres dans un document, à l aide de chiffres séparés par des points. L itération permet de répéter un message. Il permet d envoyer ces messages en séquence ou en parallèle. Et enfin, on a les paramètres (optionnels) du message. Les messages La synchronisation permet d indiquer qu un message doit attendre d autres messages. Il existe une autre forme de synchronisation. message simple : aucune caractéristique d envoi ou de réception particulière. message minuté (timeout) : bloque l expéditeur pendant un temps donné (qui peut être spécifié dans une contrainte), en attendant la prise en compte du message par le récepteur. L expéditeur est libéré si la prise en compte n a pas eu lieu pendant le délai spécifié. message synchrone : bloque l expéditeur jusqu à prise en compte du message par le destinataire. Le flot de contrôle passe de l émetteur au récepteur (l émetteur devient passif et le récepteur actif) à la prise en compte du message. L émetteur redevient actif lorsqu il reçoit la réponse ou lorsque le destinataire a fini de traiter le message. C est le type de messages le plus utilisé ; il correspond aux appels de procédure. message asynchrone : n interrompt pas l exécution de l expéditeur. Le message envoyé peut être pris en compte par le récepteur à tout moment ou ignoré (jamais traité).

31 Les messages :acteur :class1 :class2 objet3 :class3 message1() res:=message2() message3(res) message4(res) t Les messages Dans le schéma précédent, le message2 est un message synchrone. On peut supposer qu il s agit, par exemple, d un appel de fonction qui renvoie un résultat. Ce résultat est mémorisé dans la variable res. Un objet1 de la class1 qui enverra le message2 devra attendre la fin du traitement du message avant de poursuivre son exécution. Le message3 ne pourra être envoyé qu après retour du résultat. Par contre, ce message3 est asynchrone. Il sera envoyé à l objet3 de la class3 sans s occuper de savoir s il est reçu, traité... Et l objet1 enchaînera en envoyant le message4.

32 Les messages Les messages synchrones sont les plus fréquents. On envoie un message et on attend sa réponse. Dans ce cas, les deux représentations suivantes sont équivalentes. :class1 :class2 res:=message2() :class1 :class2 message2() res

33 Les messages :acteur :class1 message1() create objet2:class2 message2() destroy Des messages spécifiques peuvent créer des instances d objets ou les détruire. Les fragments combinés UML 2.0 a introduit les fragments combinés dans les diagrammes de séquence. Ils permettent de décrire les scénarios de façon plus compacte. On peut ainsi décrire un scénario contenant des parties optionnelles, des parties conditionnelles, des parties itérées. On peut décrire des parties qui doivent absolument se succéder, s exécuter en parallèle ou encore des parties qui doivent se dérouler sans interruption. Il existe ainsi 12 opérateurs de fragments.

34 Les fragments combinés :acteur :class2 :class3 message1() opt message2() message3() message4() La partie encadrée est optionnelle. Il est possible que l acteur envoie le message2. Dans ce cas, il faudra le traiter. Mais il est aussi possible qu il envoie directement le message4. Les fragments combinés :class1 :class2 :class3 message1() alt [condition1] message2() message3() [condition2] message4() La partie encadrée est une alternative à deux options ; il pourrait y en avoir plus. Si la condition1 est vérifiée, on exécutera cette sous-partie. Si la condition1 n est pas vérifiée, on examinera la condition2. On peut utiliser le terme else pour exécuter la deuxième sous-partie lorsque la condition1 n est pas vérifiée.

35 Les fragments combinés :class1 :class2 :class3 message1() loop[5] message2() message3() message4() La partie encadrée est répétée 5 fois. Les fragments combinés :class1 :class2 :class3 message1() critical message2() message3() message4() La partie encadrée ne peut pas être interrompue.

36 diagramme de communication ou diagramme de collaboration Il décrit les communications entre objets, comme le diagramme de séquence. Il insiste plus sur les objets, moins sur la chronologie. Figure 6: exemple de diagramme de communication ou diagramme de collaboration (L. Audibert)

37 diagramme des états et transitions Il décrit les changements d états d un objet. Une transition est un changement d état, provoqué par un événement. La transition peut être gardée par une condition. On peut lui associer une action. Une action est une opération instantanée, sans interruption. On peut associer une activité à l état. Une activité est une opération que fait l objet quand il est dans cet état. Une activité peut être interrompue. état activité transition [condition] / action état activité Figure 7: exemple de diagramme d états/transitions (L. Audibert)