coursUML.pdf

Modélisation UML Christine Solnon INSA de Lyon - 3IF 2013 - 2014 1/140.  Introduction Positionnement de l’UE / IF Domaines d’enseignement du département IF : Système d’Information Réseaux Architectures matérielles Logici...

Modélisation UML Christine Solnon INSA de Lyon - 3IF 2013 - 2014 1/140.  Introduction Positionnement de l’UE / IF Domaines d’enseignement du département IF : Système d’Information Réseaux Architectures matérielles Logiciel Système Méthodes et Outils Mathématiques Formation générale Développement logiciel Unités d’Enseignement du domaine “Développement logiciel” : C++ (3IF) Génie logiciel (3IF) Modélisation UML (3IF) Qualité logiciel (4IF) Grammaires et langages (4IF) Ingénierie des IHM (4IF) Méthodologie de développement objet (4IF) 2/140.  Introduction Référentiel des compétences Utiliser des diagrammes UML pour modéliser un objet d’étude Interpréter un diagramme UML donné ; IF3-UML, IF4-DevOO, IF4-IHM Concevoir un diagramme UML modélisant un objet d’étude ; IF3-UML, IF3-C++, IF3-DASI, IF4-DevOO, IF4-IHM, IF4-LG Vérifier la cohérence de différents diagrammes modélisant un même objet d’étude ; IF3-UML, IF4-DevOO, IF4-LG Concevoir l’architecture d’un logiciel orienté objet Structurer un logiciel en paquetages et classes faiblement couplés et fortement cohésifs ; IF3-UML, IF3-C++, IF3-DASI, IF4-DevOO, IF4-LG Utiliser des Design Patterns ; IF3-UML, IF3-C++, IF3-DASI, IF4-DevOO, IF4-LG 3/140.  Introduction Organisation 6 séances de cours du 7 au 28 novembre 4 séances de travaux dirigés (TD) du 18 novembre au 18 décembre 1 devoir surveillé (DS) le 23 janvier 4/140.  Introduction Pour en savoir plus... Sur la modélisation en général : Modèles et Métamodèles Guy Caplat Sur le méta-modèle de référence d’UML : http ://www.omg.org/uml Sur UML et la modélisation objet : Modélisation Objet avec UML Pierre-Alain Muller, Nathalie Gaertner ; Chapitre sur la notation téléchargeable sur le site d’Eyrolles Sur les design patterns et la conception orientée objet : UML 2 et les design patterns Craig Larman Tête la première : Design Patterns Eric Freeman & Elizabeth Freeman...et plein d’autres ouvrages à Doc’INSA ! 5/140.  Introduction Introduction à la modélisation Plan du cours 1 Introduction Introduction à la modélisation Introduction à UML 2 Modéliser la structure avec UML 3 Modéliser le comportement avec UML 4 Principes et patrons de conception orientée objet 6/140.  Introduction Introduction à la modélisation Qu’est-ce qu’un modèle ? Modèle = Objet conçu et construit (artefact) : Pour représenter un sujet d’études Représentativité Exemple de sujet : les circuits électriques S’appliquant à plusieurs cas de ce sujet d’étude Généricité Exemple de cas : des mesures (tension, intensité,...) sur des circuits Incarnant un point de vue sur ces cas Abstraction Exemple de point de vue : U = RI ; Abstraction de la longueur des fils, la forme du circuit,... Un même sujet d’études peut avoir plusieurs modèles ; Chaque modèle donne un point de vue différent sur le sujet 7/140.  Introduction Introduction à la modélisation Langages de modélisation Langages utilisés pour exprimer un modèle : Langues naturelles : qui évoluent hors du contrôle d’une théorie Ex : Français, Anglais,... Langages artificiels : conçus pour des usages particuliers Langages formels : syntaxe définie par une grammaire Ex : Logique, langages informatique (C, Java, SQL,...),... Pouvoir d’expression d’un langage : ; Ensemble des modèles que l’on peut exprimer Le choix du langage influence la conception du modèle......et donc la perception du sujet d’études ! Interprétation d’un langage : ; Procédure pour comprendre un modèle (Sémantique) Modèle ambigü : Plusieurs interprétations différentes possibles Modèle exécutable : Interprétation exécutable par une machine 8/140.  Introduction Introduction à la modélisation Langages de modélisation basés sur les graphes Définition Un graphe est défini par un couple (N, A) tel que N est un ensemble de nœuds (aussi appelés sommets) ; Composants du modèle A ⊆ N × N est un ensemble d’arcs ; Relation binaire entre les composants du modèle Nœuds et arcs peuvent être étiquetés par des propriétés La modélisation par les graphes date de [Euler 1735] [Image empruntée à Wikipedia] 9/140.  Introduction Introduction à UML Plan du cours 1 Introduction Introduction à la modélisation Introduction à UML 2 Modéliser la structure avec UML 3 Modéliser le comportement avec UML 4 Principes et patrons de conception orientée objet 10/140.  Introduction Introduction à UML Historique d’UML [Image empruntée à Wikipedia] 11/140.  Introduction Introduction à UML UML et l’OMG OMG = Object Management Group (www.omg.org) : Fondé en 1989 pour standardiser et promouvoir l’objet Version 1.0 d’UML (Unified Modeling Language) en janvier 1997 Version 2.5 en octobre 2012 Définition d’UML selon l’OMG : Langage visuel dédié à la spécification, la construction et la documentation des artefacts d’un système logiciel L’OMG définit le méta-modèle d’UML ; Syntaxe et interprétation en partie formalisées Attention : UML est un langage... pas une méthode ; Méthode dans le cours 4IF “Développement Orienté Objet" 12/140.  Introduction Introduction à UML 3 façons d’utiliser UML selon [Fowler 2003] (On y reviendra en 4IF...) Mode esquisse (méthodes Agile) : Diagrammes tracés à la main, informels et incomplets ; Support de communication pour concevoir les parties critiques Mode plan : Diagrammes formels relativement détaillés Annotations en langue naturelle ; Génération d’un squelette de code à partir des diagrammes ; Nécessité de compléter le code pour obtenir un exécutable Mode programmation (Model Driven Architecture / MDA) : Spécification complète et formelle en UML ; Génération automatique d’un exécutable à partir des diagrammes ; Limité à des applications bien particulières ; Un peu utopique (...pour le moment ?) 13/140.  Introduction Introduction à UML Différents modèles UML UML peut être utilisé pour définir de nombreux modèles : Modèles descriptifs vs prescriptifs Descriptifs ; Décrire l’existant (domaine, métier) Prescriptifs ; Décrire le futur système à réaliser Modèles destinés à différents acteurs Pour l’utilisateur ; Décrire le quoi Pour les concepteurs/développeurs ; Décrire le comment Modèles statiques vs dynamiques Statiques ; Décrire les aspects structurels Dynamiques ; Décrire comportements et interactions Les modèles sont décrits par des diagrammes (des graphes) ; Chaque diagramme donne un point de vue différent sur le système 14/140.  Introduction Introduction à UML 14 types de diagrammes d’UML 2.2...et un langage pour exprimer des contraintes : OCL 15/140.  Introduction Introduction à UML Diagrammes UML : Points de vue sur le système [Image empruntée à Muller et Gaertner] 16/140.  Introduction Introduction à UML Notations communes à tous les diagrammes (1/2) Stéréotypes et mots-clés (on y reviendra en 4IF...) : Définition d’une utilisation particulière d’éléments de modélisation ; Interprétation (sémantique) particulière Notation : «nomDuStéréotype» ou {nomDuMotClé} ou icone Nombreux stéréotypes et mots-clés prédéfinis : «interface», «invariant», «create», «actor», {abstract}, {bind}, {use}... Valeurs marquées (on y reviendra aussi en 4IF...) : Ajout d’une propriété à un élément de modélisation Notation : { nom1 = valeur1 ,..., nomn = valeurn } Valeurs marquées prédéfinies (ex. : derived : Bool) ou personnalisées (ex. : auteur : Chaîne) Commentaires : Information en langue naturelle Notation : o- - - - - - - - - - - - - - - - - - - 17/140.  Introduction Introduction à UML Notations communes à tous les diagrammes (2/2) Relations de dépendance : Notation : [source]- - - - - - - - - >[cible] ; Modification de la source peut impliquer une modification de la cible Nombreux stéréotypes prédéfinis : «bind», «realize», «use», «create», «call»,... Contraintes (on y reviendra aussi en 4IF) : Relations entre éléments de modélisation ; Propriétés qui doivent être vérifiées ; Attention : les contraintes n’ont pas d’effet de bord Notation : o- - - - - - - -{ contrainte } 3 types de contraintes : Contraintes prédéfinies : disjoint, ordered, xor,... Contraintes exprimées en langue naturelle Ex. : temps d’exécution inférieur à 10 ms Contraintes exprimées avec OCL (Object Constraint Language) Ex. : context Pile inv : self.nbElts >= 0 Stéréotypes : «invariant», «précondition», «postcondition» 18/140.  Modéliser la structure avec UML Plan du cours 1 Introduction 2 Modéliser la structure avec UML 3 Modéliser le comportement avec UML 4 Principes et patrons de conception orientée objet 19/140.  Modéliser la structure avec UML Point de vue statique sur le système Décrire la structure du système en termes de : Composants du système ; Objets, Classes, Paquetages, Composants,... Relations entre ces composants ; Spécialisation, Association, Dépendance,... ; Pas de facteur temps Différents diagrammes statiques que nous allons voir : Diagrammes d’objets (Cours) Diagrammes de classes (Cours + TD) Diagrammes de paquetage (Cours + TD) Diagrammes de composants (Cours) Diagrammes de déploiement (Cours) 20/140.  Modéliser la structure avec UML Structuration Orientée Objet Plan du cours 1 Introduction 2 Modéliser la structure avec UML Structuration Orientée Objet Diagrammes d’objets Diagrammes de classes Diagrammes de paquetage Diagrammes de composants Diagrammes de déploiement 3 Modéliser le comportement avec UML 4 Principes et patrons de conception orientée objet 21/140.  Modéliser la structure avec UML Structuration Orientée Objet Pourquoi une structuration orientée objet ? Unicité et universalité du paradigme Réduire le décalage entre monde réel et logiciel ; Objets réels ⇒ Objets conceptuels ⇒ Objets logiciels Réutilisabilité et évolutivité facilitées par différents mécanismes Encapsulation, Modularité, Abstraction, Polymorphisme, Héritage ; Faible couplage inter-objets / Forte cohésion intra-objet Paradigme qui arrive à maturité Bibliothèques de classes, Design patterns, UML, Méthodologies de développement (UP, Agile, XP,...),... ; Environnements de développement intégrés (IDE) 22/140.  Modéliser la structure avec UML Structuration Orientée Objet Qu’est-ce qu’un objet ? Objet = Etat + Comportement + Identité Etat d’un objet : Ensemble de valeurs décrivant l’objet ; Chaque valeur est associée à un attribut (propriété) ; Les valeurs sont également des objets (⇒ liens entre objets) Comportement d’un objet : Ensemble d’opérations que l’objet peut effectuer Chaque opération est déclenchée par l’envoi d’un message ; Exécution d’une méthode Identité d’un objet : Permet de distinguer les objets indépendamment de leur état ; 2 objets différents peuvent avoir le même état Attribuée implicitement à la création de l’objet ; L’identité d’un objet ne peut être modifiée Attention : identité 6= nom de la variable qui référence l’objet 23/140.  Modéliser la structure avec UML Structuration Orientée Objet Qu’est ce qu’une classe d’objets ? Classe = regroupement d’objets similaires (appelés instances) Toutes les instances d’une classe ont les mêmes attributs et opérations ; Abstraction des caractéristiques non communes Classes sans instance Classes abstraites : ; Certaines opérations peuvent être abstraites/virtuelles (non définies) Interfaces : ; Pas d’attribut et toutes les opérations sont abstraites/virtuelles Relation de spécialisation/généralisation entre classes Une classe A est une spécialisation d’une classe B si tout attribut/opération de B est également attribut/opération de A Implémentation par héritage 24/140.  Modéliser la structure avec UML Diagrammes d’objets Plan du cours 1 Introduction 2 Modéliser la structure avec UML Structuration Orientée Objet Diagrammes d’objets Diagrammes de classes Diagrammes de paquetage Diagrammes de composants Diagrammes de déploiement 3 Modéliser le comportement avec UML 4 Principes et patrons de conception orientée objet 25/140.  Modéliser la structure avec UML Diagrammes d’objets Diagrammes d’objets Objectif : Représenter les objets et leurs liens à un instant donné Utilisation : documenter des cas de test, analyser des exemples,... Moyen : Graphe Nœuds du graphe = Objets nomObjet : ClasseObjet Possibilité de supprimer le nom, la classe et/ou nomAttr_1 = val_1 nomAttr_2 = val_2 les attributs (objet anonyme, non typé ou d’état... inconnu) Arêtes du graphe = Liens entre objets o1 : C1 o2 : C2 Lien binaire : entre 2 objets Lien n-aire : entre n objets o1 : C1 o2 : C2 Possibilité de nommer les liens et les rôles o3 : C3 Correspondance entre liens et attributs 26/140.  Modéliser la structure avec UML Diagrammes d’objets Exemple de diagramme d’objets [Image empruntée à J.-M. Jezequel] 27/140.  Modéliser la structure avec UML Diagrammes d’objets Au travail ! Pierre, Paul, Jacques, Marie et Anne sont étudiants au département IF. Robert et Suzie sont enseignants au département IF. Robert enseigne le C et le réseau ; Suzie enseigne l’anglais, les math et le Java. Pierre, Paul et Marie suivent les cours de C, de réseau et Java ; Jacques et Anne suivent les cours de C, math et anglais. 28/140.  Modéliser la structure avec UML Diagrammes de classes Plan du cours 1 Introduction 2 Modéliser la structure avec UML Structuration Orientée Objet Diagrammes d’objets Diagrammes de classes Diagrammes de paquetage Diagrammes de composants Diagrammes de déploiement 3 Modéliser le comportement avec UML 4 Principes et patrons de conception orientée objet 29/140.  Modéliser la structure avec UML Diagrammes de classes Abstraction d’un ensemble de diagrammes d’objets [Image empruntée à J.-M. Jezequel] 30/140.  Modéliser la structure avec UML Diagrammes de classes Diagrammes de classes Un diagramme de classes est un graphe : Nœud du graphe = Classe ; Abstraction d’un ensemble d’objets Arc du graphe = Relation entre des classes : Relation d’association ; Abstraction d’un d’ensemble de liens entre objets Relation de généralisation / spécialisation ; Factorisation de propriétés communes à plusieurs classes Très nombreuses utilisations, à différents niveaux : Pendant la capture des besoins : Modèle du domaine ; Classes = Objets du domaine Pendant la conception/implémentation : Modèle de conception ; Classes = Objets logiciels 31/140.  Modéliser la structure avec UML Diagrammes de classes Représentation UML des classes Rectangle composé de compartiments : Compartiment 1 : Nom de la classe (commence par une majuscule, en gras) Compartiment 2 : Attributs Compartiment 3 : Opérations Possibilité d’ajouter des compartiments (exceptions,...) Différents niveaux de détail possibles : ; Possibilité d’omettre attributs et/ou opérations NomClasse1 NomClasse2 NomClasse3 attr1 : Chaine attr1 attr2 : Entier attr2... op1(p1:Entier) : Entier op2() : Chaine... 32/140.  Modéliser la structure avec UML Diagrammes de classes Représentation UML des attributs Format de description d’un attribut : [Vis] Nom [Mult] [":" TypeAtt] ["=" Val] [Prop] Vis : + (public), - (privé), # (protégé), ∼ (package) Mult : "[" nbElt "]" ou "[" Min.. Max "]" TypeAtt : type primitif (Entier, Chaîne,...) ou classe Val : valeur initiale à la création de l’objet Prop : {gelé}, {variable}, {ajoutUniquement},... Attributs de classe (statiques) soulignés Attributs dérivés précédés de "/" Exemples : # onOff : Bouton + pi : réel = 3.14 {gelé} - x : Réel inscrits[2..8] : Personne coord : Réel /age : Entier 33/140.  Modéliser la structure avec UML Diagrammes de classes Représentation UML des opérations Format de description d’une opération : [Visibilité] Nom ["(" Arg ")"] [":" Type] Visibilité : + (public), - (privé), # (protégé) Arg : liste des arguments selon le format [Dir] NomArgument : TypeArgument où Dir = in (par défaut), out, ou inout Type : type de la valeur retournée (type primitif ou classe) Opérations abstraites/virtuelles (non implémentées) en italique Opérations de classe (statiques) soulignées Possibilité d’annoter avec des contraintes stéréotypées «precondition» et «postcondition» ; Programmation par contrats Possibilité de surcharger une opération : ; même nom, mais paramètres différents Stéréotypes d’opérations : «create» et «destroy» 34/140.  Modéliser la structure avec UML Diagrammes de classes Associations entre classes ; Abstraction des relations définies par les liens entre objets Liens entre objets : :C2 :C4 :C1 :C3 :C2 :C4 :C1 :C3 :C4 :C2 :C1 :C3 :C4 :C2 :C4 Associations entre classes d’objets : 1..* 1..* 1 0..1 0..1 0..2 C1 C2 C3 C4 35/140.  Modéliser la structure avec UML Diagrammes de classes Associations entre classes (1/2) Role de C1 dans l’association Sens de lecture role1 Nom role2 C1 C2 mult1 mult2 Nombre d’instances de C1 pouvant etre liées à une instance de C2 (ex. : 1, 0..1, *, 1..*, 4, 4..10,...) Interprétation en français : Un C1 Nom un C2 (ou un C2 Nom un C1 si sens de lecture inverse) Un C1 est rôle1 d’un C2 et mult1 C1 peuvent jouer ce rôle pour un C2 Un C2 est rôle2 d’un C1 et mult2 C2 peuvent jouer ce rôle pour un C1 Exemple : employeur Est employée par employé Entreprise Personne 0..1 1..* 36/140.  Modéliser la structure avec UML Diagrammes de classes Associations entre classes (2/2) Role de C1 dans l’association Sens de lecture role1 Nom role2 C1 C2 mult1 mult2 Nombre d’instances de C1 pouvant etre liées à une instance de C2 (ex. : 1, 0..1, *, 1..*, 4, 4..10,...) Interprétation en langage de programmation orienté objet La classe C1 a un attribut de nom rôle2 ; Type = C2 si mult2 ∈ {1, 0..1}, ou collection de C2 sinon La classe C2 a un attribut de nom rôle1 ; Type = C1 si mult1 ∈ {1, 0..1}, ou collection de C1 sinon Exemple : employeur Est employée par employé Entreprise Personne 0..1 1..* 36/140.  Modéliser la structure avec UML Diagrammes de classes Au travail ! Chaque étudiant du département IF suit un ensemble d’unités d’enseignement (UE). Chaque UE a un coefficient et est constituée de cours, de travaux dirigés (TD) et de travaux pratiques (TP). Chaque cours, TD ou TP a une date. Les cours sont faits en amphi, les TD en salle de classe et les TP en salle machine. Pour les TP et TD, les étudiants sont répartis dans des groupes. Pour chaque TP, chaque étudiant est en binôme avec un autre étudiant. Les cours et les TD sont assurés par un enseignant. Les TP sont assurés par deux enseignants. Pour chaque UE, l’étudiant a une note de devoir surveillé ; pour chaque TP, le binôme a une note de TP. 37/140.  Modéliser la structure avec UML Diagrammes de classes Navigabilité Qu’est-ce que la navigabilité d’une association entre C1 et C2 ? Capacité d’une instance de C1 (resp. C2) à accéder aux instances de C2 (resp. C1) Par défaut : C1 C2 Navigabilité dans les deux sens ; C1 a un attribut de type C2 et C2 a un attribut de type C1 Spécification de la navigabilité : Orientation de l’association C1 C2 ; C1 a un attribut du type de C2, mais pas l’inverse Attention : Dans un diagramme de classes conceptuelles, toute classe doit être accessible à partir de la classe principale 38/140.  Modéliser la structure avec UML Diagrammes de classes Propriétés et contraintes sur les associations Propriétés sur extrémités d’associations {variable} : instance modifiable (par défaut) {frozen} : instance non modifiable {addOnly} : instances ajoutables mais non retirables (si mult. > 1) Contraintes prédéfinies Sur une extrémité : {ordered}, {unique},... Entre 2 associations : {subset}, {xor},... [images extraites de Muller et Gaertner] 39/140.  Modéliser la structure avec UML Diagrammes de classes Associations qualifiées Restriction d’une relation / qualificateur : Sélection d’un sous-ensemble d’objets à l’aide d’un attribut qualificatif (clé) L’attribut qualificatif appartient à l’association Classe source qualificatif Classe destination {sous−ensemble} Exemples : 1 * Banque Compte 1 1 Banque numCpte Compte [image extraite de www.omg.org] 40/140.  Modéliser la structure avec UML Diagrammes de classes Classes-associations Association attribuée : n m 1 C3 n C1 C2 C1 attr1 C2 m 1 attr2... attr1 attr2 Le nom de la classe association peut etre omis... Une classe association peut participer à d’autres associations : C1 C2 C3 attr1 C4 attr2... 41/140.  Modéliser la structure avec UML Diagrammes de classes Associations n-aires Associations entre n classes (avec n > 2) 1 Enseignant Enseignant * * * 1 * Groupe Groupe Cours * * 1 Salle Salle Classes-Associations n-aire 1 Enseignant Enseignant * * Cours Cours * date 1 * Groupe Groupe date heure heure * 1 * Salle Salle 42/140.  Modéliser la structure avec UML Diagrammes de classes Associations particulières : composition et agrégation Composition : 1 1..n 1 1..n Livre Chapitre Paragraphe Relation transitive et antisymétrique La création (copie, destruction) du composite (container) implique la création (copie, destruction) de ses composants Un composant appartient à au plus un composite Agrégation : Polygone * 3..n Point Simple regroupement de parties dans un tout 43/140.  Modéliser la structure avec UML Diagrammes de classes Généralisation et Héritage Niveau conceptuel : Généralisation Relation transitive, non réflexive, et non symétrique La sous-classe “est-une-sorte-de” la super classe ; Toute instance de la sous-classe est instance de la super classe Niveau implémentation : Héritage Mécanisme proposé par les langages de programmation Objet "B hérite de A" signifie que B possède : Toutes les propriétés de A (attributs, op., assoc., contraintes) ; Possibilité de redéfinir les opérations de la sous-classe ; Polymorphisme Ainsi que des nouvelles propriétés qui lui sont propres ; Permet de factoriser les propriétés communes à plusieurs classes ; Une opération définie pour A est accessible aux sous-classes de A 44/140.  Modéliser la structure avec UML Diagrammes de classes Héritage et généralisation : Exemple 45/140.  Modéliser la structure avec UML Diagrammes de classes Héritage vs Composition Problème : Modéliser le fait qu’il y a des voitures bleues, des voitures rouges et des voitures vertes. Solution 1 : Héritage Créer une classe abstraite Voiture Créer 3 classes VoitureBleue, VoitureRouge et VoitureVerte qui héritent de Voiture Solution 2 : Composition Créer une classe Voiture et une classe Couleur (énumération) Créer une association entre Voiture et Couleur Comment représenter ces 2 solutions en UML ? 46/140.  Modéliser la structure avec UML Diagrammes de classes Héritage vs Composition Problème : Modéliser le fait qu’il y a des voitures bleues, des voitures rouges et des voitures vertes. Solution 1 : Héritage Créer une classe abstraite Voiture Créer 3 classes VoitureBleue, VoitureRouge et VoitureVerte qui héritent de Voiture Solution 2 : Composition Créer une classe Voiture et une classe Couleur (énumération) Créer une association entre Voiture et Couleur Comment représenter ces 2 solutions en UML ? Quelle solution choisissez-vous ? 46/140.  Modéliser la structure avec UML Diagrammes de classes Héritage vs Composition Problème : Modéliser le fait qu’il y a des voitures bleues, des voitures rouges et des voitures vertes. Solution 1 : Héritage Créer une classe abstraite Voiture Créer 3 classes VoitureBleue, VoitureRouge et VoitureVerte qui héritent de Voiture Solution 2 : Composition Créer une classe Voiture et une classe Couleur (énumération) Créer une association entre Voiture et Couleur Comment représenter ces 2 solutions en UML ? Quelle solution choisissez-vous ? Et si on veut modéliser le fait qu’il y a des personnes hommes et des personnes femmes ? 46/140.  Modéliser la structure avec UML Diagrammes de classes Héritage vs Délégation Problème : Appeler dans une classe B une opération op() d’une classe A ? Solution 1 : Héritage Faire hériter B de A op() peut être appelée depuis n’importe quelle instance de B Solution 2 : Délégation Ajouter une association de B vers A ; Ajouter dans B un attribut a de type A a.op() peut être appelée depuis n’importe quelle instance de B Comment représenter ces 2 solutions en UML ? 47/140.  Modéliser la structure avec UML Diagrammes de classes Héritage vs Délégation Problème : Appeler dans une classe B une opération op() d’une classe A ? Solution 1 : Héritage Faire hériter B de A op() peut être appelée depuis n’importe quelle instance de B Solution 2 : Délégation Ajouter une association de B vers A ; Ajouter dans B un attribut a de type A a.op() peut être appelée depuis n’importe quelle instance de B Comment représenter ces 2 solutions en UML ? Quelle solution choisissez-vous ? 47/140.  Modéliser la structure avec UML Diagrammes de classes Héritage vs Délégation Problème : Appeler dans une classe B une opération op() d’une classe A ? Solution 1 : Héritage Faire hériter B de A op() peut être appelée depuis n’importe quelle instance de B Solution 2 : Délégation Ajouter une association de B vers A ; Ajouter dans B un attribut a de type A a.op() peut être appelée depuis n’importe quelle instance de B Comment représenter ces 2 solutions en UML ? Quelle solution choisissez-vous ? ; On y reviendra avec les Design Patterns... 47/140.  Modéliser la structure avec UML Diagrammes de classes Contraintes sur les relations de généralisation {disjoint} ou {overlapping} {complete} ou {incomplete} ; {disjoint,complete} ⇒ Partition {leaf} ou {root} [Image empruntée à www.omg.org] 48/140.  Modéliser la structure avec UML Diagrammes de classes Classes génériques (templates) Qu’est-ce qu’une classe générique ? Pile T Classe paramétrée par d’autres classes (String) (Float) ; Factorisation de code PileDeString PileDeFloat Exemple de code C++ Exemple de code Java : template class Pile{ public class Pile { public: public Pile() {... } Pile() {... } public void empile(T e) {... } void empile(T e) {... }...... private... private:... }; };...... Pile p1 = new Pile(); Pile p1; Pile p2 = new Pile(); Pile p2; p1.empile(2.5); p1.empile(2.5); p2.empile(’a’); p2.empile(’a’);...... 49/140.  Modéliser la structure avec UML Diagrammes de classes Classes abstraites Qu’est-ce qu’une classe abstraite ? Classe qui ne peut être instanciée Contient des opérations non définies : ; abstract (Java) ou virtual (C++) Doit être spécialisée en une ou plusieurs classes non abstraites Notation : mot clé {abstract} ou nom en italique Pourquoi des classes abstraites ? Spécifier un comportement commun à plusieurs classes Manipuler des instances de classes différentes de façon uniforme ; Polymorphisme Bonne pratique : Dans une hiérarchie d’héritage, les classes qui ne sont pas des feuilles sont généralement abstraites 50/140.  Modéliser la structure avec UML Diagrammes de classes Classes abstraites et polymorphisme / Ex. C++ 51/140.  Modéliser la structure avec UML Diagrammes de classes Classes abstraites et polymorphisme / Ex. Java 52/140.  Modéliser la structure avec UML Diagrammes de classes Interface Qu’est-ce qu’une interface ? Classe sans attribut dont toutes les opérations sont abstraites ; Ne peut être instanciée ; Doit être réalisée (implémentée) par des classes non abstraites ; Peut hériter d’une autre interface Pourquoi des interfaces ? Utilisation similaire aux classes abstraites En Java : une classe ne peut hériter de plus d’une classe, mais elle peut réaliser plusieurs interfaces Notations UML : Nom : «interface» Itf1 Héritage : Itf1 — Itf2 Itf1 Réalisation : Class1 - - - -  Itf1 ou Class1 ——-O Itf1 Utilisation : Class2 - - «use» - - > Itf1 ou Class2 ——-C 53/140.  Modéliser la structure avec UML Diagrammes de classes Exemple [image empruntée à Craig Larman] 54/140.  Modéliser la structure avec UML Diagrammes de classes Quelques stéréotypes et mots-clés {abstract} : classe abstraite (alternative : nom en italique) «interface» : interface «énumération» : instances appartiennent à un ensemble fini de littéraux «type primitif» : instances sont des valeurs d’un type primitif «classe implémentation» : implémentation d’une classe dans un langage de programmation «utilitaire» : variables et procédures globales 55/140.  Modéliser la structure avec UML Diagrammes de classes Synthèse des différentes relations Association Navigable dans les 2 sens : —————— Navigable dans un sens : ——————> ou –X—————> Composition : —————— Agrégation : —————— Généralisation : —————— Réalisation d’une interface : ——————O ou - - - - - - - - - - - -  Utilisation d’une interface : ——————C ou - - - - «use» - - - - > Intanciation d’une classe générique : - - - - «bind» (Type) - - - - > Dépendance : - - - - - - - - - - - - > 56/140.  Modéliser la structure avec UML Diagrammes de classes Cherchez l’erreur (1/3) 1 1..* 1 1..2 Maison Pièce Fenetre 57/140.  Modéliser la structure avec UML Diagrammes de classes Cherchez l’erreur (1/3) 1 1..* 1 1..2 Maison Pièce Fenetre Navigabilité : Tout objet doit être accessible via une association 57/140.  Modéliser la structure avec UML Diagrammes de classes Cherchez l’erreur (2/3) * 1 Bagage Passager * * 1 1 Vol 58/140.  Modéliser la structure avec UML Diagrammes de classes Cherchez l’erreur (2/3) * 1 Bagage Passager * * 1 1 Vol Eviter les associations redondantes : ; Le vol d’un bagage est obtenu à partir du passager ; Les bagages d’un vol sont obtenus à partir des passagers Possibilité de spécifier que l’association Bagage-Vol est dérivée... 58/140.  Modéliser la structure avec UML Diagrammes de classes Cherchez l’erreur (3/3) Réservation 1 * * 1 Chambre dateDeb Client dateFin Personne * nom 1 1 1 Hotel Gérant 59/140.  Modéliser la structure avec UML Diagrammes de classes Cherchez l’erreur (3/3) Réservation 1 * * 1 Chambre dateDeb Client dateFin Personne * nom 1 1 1 Hotel Gérant Navigabilité : En l’absence de réservations, on ne peut accéder ni aux chambres ni aux clients 59/140.  Modéliser la structure avec UML Diagrammes de paquetage Plan du cours 1 Introduction 2 Modéliser la structure avec UML Structuration Orientée Objet Diagrammes d’objets Diagrammes de classes Diagrammes de paquetage Diagrammes de composants Diagrammes de déploiement 3 Modéliser le comportement avec UML 4 Principes et patrons de conception orientée objet 60/140.  Modéliser la structure avec UML Diagrammes de paquetage Diagrammes de paquetages Qu’est-ce qu’un paquetage (package) ? Élément de modélisation qui : Contient d’autres éléments de modélisation (classes, autres paquetages,...) ; Possibilité de ne pas représenter tous les éléments contenus Définit un espace de nom (namespace) [Image extraite de Muller et Gaertner] 61/140.  Modéliser la structure avec UML Diagrammes de paquetage Espaces de nom et visibilité 2 éléments dans 2 paquetages différents sont différents, quel que soit leur nom Nom complet = nom préfixé par les noms des paquetages englobants : Banque::Compte 6= Commerce::Compte Visibilité d’un élément E dans un package P : Public (+) : Elément visible par tous (utilisation du nom complet) Privé (-) : Elément visible uniquement par Les autres éléments de P Les éléments englobés par E (si E est un package) 62/140.  Modéliser la structure avec UML Diagrammes de paquetage Dépendances entre paquetages Reflètent les dépendances entre éléments des paquetages : Une classe A dépend d’une classe B (noté A - - - - - - - - > B) si : Il existe une association navigable de A vers B (ou A possède un attribut de type B) Une méthode de A a un paramètre ou une variable locale de type B Stéréotypes sur les dépendances inter-paquetage A - - - «accède» - - - > B : Tout élément public de B est accessible par son nom complet depuis A A - - - «importe» - - - > B : Tout élément public de B est accessible par son nom depuis A ; Création d’alias si nécessaire Valeur marquée {global} : Paquetage visible par tous les autres paquetages ; Inutile de montrer les dépendances vers ce paquetage 63/140.  Modéliser la structure avec UML Diagrammes de paquetage Architecture logique Qu’est-ce qu’une architecture logique ? Regroupement des classes logicielles en paquetages ; Point de départ pour un découpage en sous-systèmes Objectifs d’une architecture logique : Encapsuler et décomposer la complexité Faciliter le travail en équipes Faciliter la réutilisation et l’évolutivité ; Forte cohésion intra paquetage ; Faible couplage inter paquetages Exemples d’architectures logiques : Architecture en couches Architecture Modèle - Vue - Contrôleur (MVC) Architecture Multi-tiers... 64/140.  Modéliser la structure avec UML Diagrammes de composants Plan du cours 1 Introduction 2 Modéliser la structure avec UML Structuration Orientée Objet Diagrammes d’objets Diagrammes de classes Diagrammes de paquetage Diagrammes de composants Diagrammes de déploiement 3 Modéliser le comportement avec UML 4 Principes et patrons de conception orientée objet 65/140.  Modéliser la structure avec UML Diagrammes de composants Diagrammes de composants Composant : Encapsule l’état et le comportement d’un ensemble de classifiers (classes, composants...) Spécifie les services fournis et requis : Interfaces fournies : «provided interfaces» ou —–O Interfaces requises : «required interfaces» ou ——C ; Substituable à tout composant qui offre/requiert les m̂ interfaces Exemple : [Image extraite de www.ibm.com/developerworks/rational] 66/140.  Modéliser la structure avec UML Diagrammes de composants Relations entre composants ; Inclusion entre composants et Fourniture ou Utilisation d’interfaces [Image extraite de www.ibm.com/developerworks/rational] 67/140.  Modéliser la structure avec UML Diagrammes de déploiement Plan du cours 1 Introduction 2 Modéliser la structure avec UML Structuration Orientée Objet Diagrammes d’objets Diagrammes de classes Diagrammes de paquetage Diagrammes de composants Diagrammes de déploiement 3 Modéliser le comportement avec UML 4 Principes et patrons de conception orientée objet 68/140.  Modéliser la structure avec UML Diagrammes de déploiement Diagrammes de déploiement Modéliser le déploiement du système sur une architecture physique Disposition des artefacts sur les nœuds physiques Artefacts : instances de composants, processus,... Nœuds physiques : Ordinateur, Téléphone, Imprimante,... Moyens de communication entre les nœuds 69/140.  Modéliser le comportement avec UML Plan du cours 1 Introduction 2 Modéliser la structure avec UML 3 Modéliser le comportement avec UML 4 Principes et patrons de conception orientée objet 70/140.  Modéliser le comportement avec UML Modéliser le comportement avec UML Décrire le comportement du système en termes d’interactions Système vu comme une boite noire : Qui interagit avec le système, et dans quel but ? ; Diagramme de cas d’utilisation Comment interagit le système avec son environnement ? ; Diagramme de séquence système Système vu comme une boite blanche : Comment interagissent les objets du système ? ; Diagramme de séquence et/ou de communication Décrire l’évolution du système dans le temps Comment évoluent les états des objets ? ; Diagrammes d’états-transitions 71/140.  Modéliser le comportement avec UML Diagrammes d’interaction Plan du cours 1 Introduction 2 Modéliser la structure avec UML 3 Modéliser le comportement avec UML Diagrammes d’interaction Diagrammes de cas d’utilisation Diagrammes d’états-transitions 4 Principes et patrons de conception orientée objet 72/140.  Modéliser le comportement avec UML Diagrammes d’interaction Diagrammes d’interaction ; Point de vue temporel sur les interactions Pendant la capture des besoins (système = boite noire) : ; Interactions entre acteurs et système Décrire les scénarios des cas d’utilisation Pendant la conception (système = boite blanche) : ; Interactions entre objets Réfléchir à l’affectation de responsabilités aux objets Qui crée les objets ? Qui permet d’accéder à un objet ? Quel objet reçoit un message provenant de l’IHM ?... de façon à avoir un faible couplage et une forte cohésion Elaboration en parallèle avec les diagrammes de classes ; Contrôler la cohérence des diagrammes ! 73/140.  Modéliser le comportement avec UML Diagrammes d’interaction Diagrammes de séquence vs diagrammes de communication Diagrammes de séquence : Diagrammes de communication : Structuration en termes de Structuration en multigraphe temps ; axe vertical Numérotation des arcs pour objets ; axe horizontal modéliser l’ordre des interactions Exemple : Exemple : o1:T1 o2:T2 o3:T3 1: ret1=msg1(p1) o1:T1 o2:T2 msg1(p1) msg2(p2) ret2 1.1: ret2=msg2(p2) msg3(p3) 1.2: ret3=msg3(p3) ret1 ret3 o3:T3 74/140.  Modéliser le comportement avec UML Diagrammes d’interaction Diagrammes de séquence Ligne de vie et activation Message dont l’émetteur n’est pas connu Nom de l’objet Objet anonyme Type de l’objet o1:T1 :T2 Activation par envoi de message msg() msg1(p1) Temps Durée d’activation ret1 Valeur retournée (facultatif) Ligne de vie de o1 75/140.  Modéliser le comportement avec UML Diagrammes d’interaction Diagrammes de séquence Création et destruction d’objets o1:T1 Créer o2:T2...échange de messages... Durée de vie d’o2 Détruire 76/140.  Modéliser le comportement avec UML Diagrammes d’interaction Diagrammes de séquence Messages réflexifs, messages asynchrones et contraintes temporelles o1:T1 o1:T1 o2:T2 o2:T2 msg1() msg1(p1) msg2() ret1 o1:T1 o2:T2 msg1() Délai de propagation x y−x < 2s msg2() y 77/140.  Modéliser le comportement avec UML Diagrammes d’interaction Diagrammes de séquence : Cadres Mot réservé pour déclarer un diagramme de séquence Nom du diagramme de séquence sd xx o1:T1 o2:T2 o3:T3 o1:T1 o2:T2 msg1() msg1() ref xx loop [condition] msg2() ret connexions alt [condition1] Référence au msg3() diagramme xx [else] msg4() ret ; Existe aussi : par, opt, critique 78/140.  Modéliser le comportement avec UML Diagrammes d’interaction Diagrammes de séquence Messages polymorphes f: Fenetre vues[i]: VueGraphique dessiner() VueGraphique loop [i variant de 0 à f.nbVues] afficher() afficher() VueRond VueCarré :VueRond o2:T2 :VueCarré o3:T3 afficher() afficher() msg1() msg2() 79/140.  Modéliser le comportement avec UML Diagrammes d’interaction Liens entre diag. de classes et d’interaction [Figure extraite du livre de C. Larman] 80/140.  Modéliser le comportement avec UML Diagrammes d’interaction Diagrammes de communication Présentation alternative d’une séquence d’interactions 81/140.  Modéliser le comportement avec UML Diagrammes de cas d’utilisation Plan du cours 1 Introduction 2 Modéliser la structure avec UML 3 Modéliser le comportement avec UML Diagrammes d’interaction Diagrammes de cas d’utilisation Diagrammes d’états-transitions 4 Principes et patrons de conception orientée objet 82/140.  Modéliser le comportement avec UML Diagrammes de cas d’utilisation Cas d’utilisation Pourquoi faire ? Permettre au client de décrire ses besoins Parvenir à un accord (contrat) entre clients et développeurs Point d’entrée pour les étapes suivantes du développement Qu’est ce qu’un cas d’utilisation ? Usage que des acteurs font du système Acteur : Entité extérieure qui interagit avec le système ; Une même personne peut jouer le rôle de différents acteurs ; Un acteur peut être un autre système (SGBD, Horloge,...) Usage : Séquence d’interactions entre le système et les acteurs Généralement composé de plusieurs scénarios (instances) ; Scénario de base et ses variantes (cas particuliers) ; Description des scénarios à l’aide de diagrammes de séquence 83/140.  Modéliser le comportement avec UML Diagrammes de cas d’utilisation Comment découvrir les cas d’utilisation ? Délimiter le périmètre du système Identifier les acteurs interagissant avec le système : Ceux qui utilisent le système Ceux qui fournissent un service au système Identifier les acteurs principaux ; Ceux qui utilisent le système pour atteindre un but Définir les cas d’utilisation correspondant à ces buts ; Nom = Verbe à l’infinitif + Groupe nominal Comment décrire les cas d’utilisation ? Diagramme de cas d’utilisations ; Récapitulatif graphique des interactions entre acteurs et cas Diagramme de séquence ; Description de chaque scénario ; Séquences d’interactions entre les acteurs et le système 84/140.  Modéliser le comportement avec UML Diagrammes de cas d’utilisation Diagrammes de cas d’utilisation Limites du système Système XXX nom du système Client Service Traiter une vente d’autorisation des paiements Ouvrir la caisse Système des ressources humaines Caissier Traiter un retour notation alternative pour un acteur Communication acteur Gérant Gérer la sécurité cas d’utilisation Administrateur système 85/140.  Modéliser le comportement avec UML Diagrammes de cas d’utilisation Relations entre cas d’utilisation Généralisation : ———— Inclusion : - - - - - «include» - - - - - > Extension : - - - - - «extend» - - - - - > (préciser la condition) ; A utiliser avec modération Système XXX Faire un virement Client local montant > 500 euros Faire un virement par internet Vérifier solde compte Identifier client Client distant 86/140.  Modéliser le comportement avec UML Diagrammes de cas d’utilisation Diagrammes de séquence d’un cas d’utilisation Représentation graphique d’un scénario d’un cas d’utilisation : Caissier : Système créerNouvelleVente() loop [reste des articles] saisirArticle(codeArt,Qte) description, total terminerVente() total HT et TTC créerPaiement(montant) rendu de la monnaie, reçu ; Le système vu comme une boite noire 87/140.  Modéliser le comportement avec UML Diagrammes d’états-transitions Plan du cours 1 Introduction 2 Modéliser la structure avec UML 3 Modéliser le comportement avec UML Diagrammes d’interaction Diagrammes de cas d’utilisation Diagrammes d’états-transitions 4 Principes et patrons de conception orientée objet 88/140.  Modéliser le comportement avec UML Diagrammes d’états-transitions Parenthèse sur les automates finis (1/3) Un automate fini est défini par Un ensemble de symboles A Un ensemble fini d’états Q Un ensemble d’états initiaux I ⊆ Q et d’états terminaux T ⊆ Q Une relation de transition R ⊆ Q × A × Q Interprétation : (qi , s, qj ) ⇒ passer de qi à qj quand on lit s Représentation d’un automate fini par un graphe Chaque état correspond à un sommet s Chaque transition (qi , s, qj ) correspond à un arc qi −→ qj Exemple : A = {e,., 0, 1, 2, 3, 4, 5, 6, 7, 8, 9} 0|..|9 0|..|9 0|..|9 Q = {q0 , q1 , q2 , q3 , q4 , q5 } T = {q1 , q2 , q3 , q5 } 1|..|9. e 1|..|9 I = {q0 } q0 q1 q3 q4 q5. 0 q2 89/140.  Modéliser le comportement avec UML Diagrammes d’états-transitions Parenthèse sur les automates finis (2/3) Exécution d’un automate fini : Un automate est une procédure qui reconnait des mots Entrée = une suite de symboles de A Sortie = vrai ou faux Un mot < s1 ,..., sn > est reconnu s’il existe < q0 ,..., qn > tel que : q0 ∈ I, qn ∈ T et ∀i ∈ [1..n], (qi−1 , si , qi ) ∈ R ; Chemin partant d’un état de I et arrivant sur un état de F Exemple : 0|..|9 0|..|9 0|..|9 Mots reconnus : 0, 0.123e45, 125,... 1|..|9 q1. q3 e q4 1|..|9 q5 q0 Mots non reconnus :. 0 012, 4.5.6, 1e2,... q2 Comment modifier l’automate pour qu’il accepte 1e2 ? 90/140.  Modéliser le comportement avec UML Diagrammes d’états-transitions Parenthèse sur les automates finis (3/3) Automates finis déterministes et complets Un automate est déterministe si R est une fonction de Q × A dans Q ; On peut toujours rendre déterministe un automate Un automate est complet si R est une fonction totale ; On peut toujours rendre complet un automate Exemple : a|...|z a|...|z =e e a|...|z e q1 s q2 t q3 e s q2 t q3 q0 q0 q1 =e,s e =e,t 91/140.  Modéliser le comportement avec UML Diagrammes d’états-transitions Au delà des automates finis Les automates finis déterministes sont très efficaces Complexité en temps linéaire / taille du mot Mais ils ont un pouvoir d’expression limité aux langages réguliers Ne peuvent reconnaître les expressions bien parenthésées (entre autres) Un automate à pile a un pouvoir d’expression supérieur A chaque transition, on peut empiler ou dépiler des symboles Permet de reconnaître tous les langages hors-contexte ; Langages de programmation (C++, Java,...) Mais certains langages ne peuvent pas être reconnus par un automate à pile Une machine de Turing est un automate encore plus puissant A chaque transition, on peut écrire ou lire sur un ruban Permet de reconnaître tous les langages « décidables » ; Pouvoir de calcul équivalent à un ordinateur Mais certains langages sont indécidables ! 92/140.  Modéliser le comportement avec UML Diagrammes d’états-transitions Retour aux diagrammes d’états-transitions Utilisés pour modéliser : Le cycle de vie des objets Evolution de l’état des objets Comportement face à l’arrivée d’événements ; Intéressant si les réponses aux événements dépendent des états Mais aussi : protocoles complexes (GUI,...), processus métier,... Pouvoir d’expression variable : Pas d’action ni de garde ; Automates finis Pas de garde + actions limitées à l’utilisation d’une pile ; Automates à pile Machines de Turing dans le cas général 93/140.  Modéliser le comportement avec UML Diagrammes d’états-transitions Diagrammes sans gardes ni actions Automates finis un peu particuliers : Remplacement de la lecture de symboles par des événements : ; Occurrence d’un fait significatif ou remarquable Réception d’un signal Réception d’un message Expiration d’une temporisation... Les événements déclenchent les transitions d’un état vers un autre ; Evénement «perdu» si aucune transition spécifiée pour lui Il y a un état initial, mais pas toujours d’état final Exemple : Etat initial Evénement décrocher Etat Inactif Actif raccrocher 94/140.  Modéliser le comportement avec UML Diagrammes d’états-transitions Exemple de diagramme d’état Modélisation des états d’un processus Pret En attente suspendu suspendu suspendu activé suspendu activé Pret E/S arrivée En attente time sélection E/S attendue out instr En exécution util En exécution Terminé Noyau Utilisateur exit ou signal (ou zombi) instr. noyau Etat final 95/140.  Modéliser le comportement avec UML Diagrammes d’états-transitions Différents types d’événements : Signaux : nomSignal Q0 ————————————–> Q1 Appels d’opérations : nomOp(paramètres) Q0 ————————————–> Q1 ; Les paramètres peuvent être typés ou non Evénements temporels : after(qté tps) Q0 ————————————–> Q1 ; Passage dans l’état Q1 qté tps après l’arrivée dans l’état Q0 Evénements de changement : when(cond) Q0 ————————————–> Q1 ; Passage dans l’état Q1 quand cond devient vraie 96/140.  Modéliser le comportement avec UML Diagrammes d’états-transitions Etats imbriqués (ou composites) Un état peut contenir des sous-états Permet de factoriser les transitions de sortie du composite ; Chaque transition de sortie s’applique à tous les sous-états Une seule transition d’entrée Exemple : Actif décrocher Inactif EmissionTonalité Conversation chiffre chiffre connecté raccrocher Numérotation terminé Connexion Notation alternative pour l’état initial du composite : Actif décrocher Inactif EmissionTonalité Conversation chiffre chiffre connecté raccrocher terminé Numérotation Connexion 97/140.  Modéliser le comportement avec UML Diagrammes d’états-transitions Etats concurrents (1/2) Plusieurs sous-automates peuvent être concurrents : Etat courant = n-uplet de sous-états ; Etats de S = {(Z, A), (Z, B), (X, A), (X, B), (Y, A), (Y, B)} Exécution indépendante des sous-automates Un évt peut déclencher une transition dans plusieurs sous-auto. Sortie possible quand tous les sous-auto. sont dans un état final Exemple :... P... P e0 e0 S e2 S0 S1 ZA YA e3 e1 e4 e3 Z A e1 e5 X e1 XA YB Q e2 e4 e4 e1 e1 e2 e1 Y B e1 e4 XB ZB e3 e5 Q... 98/140.  Modéliser le comportement avec UML Diagrammes d’états-transitions Etats concurrents (2/2) Cas où les sous-automates sont complets : Equivalent au produit d’automates finis ; Intersection des langages reconnus par les sous-automates Exemple :... X e1 S X S0 S1 e1 0 1 P0 P1 0 P0P1 I0P1 0 0 0 1 1 1 1 1 1 0 1 I0 I1 0 P0I1 I0I1 0 e2 e2 Y... Y... 99/140.  Modéliser le comportement avec UML Diagrammes d’états-transitions Gardes et transitions composites Conditions de garde : garde = expression booléenne e1 [cond] A B Transition de A vers B réalisée si cond est vraie quand e1 arrive ; Si cond est fausse alors e1 est perdu Transitions composites : Commande validation [tot=0] [0