Cours UML (Tous Les Chapitres) [PDF]

Zitiervorschau

Cours : Modélisation Orientée Objet (MOO avec UML)

Responsable : Achraf MTIBAA

1

Introduction : Rappel sur les concepts orientés objet

Responsable : Achraf MTIBAA

2

1-Approches de conception

Approche Fonctionnelle (60-70) - Décomposition du système en des fonctions Approche Systémique (70-8x) - Dichotomie Données / Traitement Approche Objet (8x- ….) - Se base sur les concepts Objets 3

2-Concepts des Objets

Le monde est composé d’entités qui « collaborent » chauffeur

Feu direction

Boîte de vitesse roue

moteur roue Freins

• L’approche objet consiste à résoudre un problème en termes d’objets qui collaborent. • Ces objets sont des abstractions des objets réels

4

2-Concepts orientés objet L’OBJET Est un élément du réel à modéliser : Posséde sa propre identité : OID (Object Identifier) : OID : est une valeur indépendante des valeurs des prorpriétés de l’objet Attribuée par le système et elle est totalement transparante à l’utilisateur Peut avoir plusieurs états durant son cycle de vie : Etat d’un objet : situation significative que peut prendre un objet, déterminée en fonction des valeurs des différents attributs et liens de l’objet Cycle de vie : les états que peut prendre un objet, entre sa création et sa suppression (et les conditions de passage d’un état à un autre). Exemples : La facture 100567 : {100567, 27/1/2005, ...} Les états que peut prendre la facture : {saisie, livrée, en attente de livraison, soldée, …} 5

2-Concepts orientés objet La CLASSE Regroupe un ensemble d'objets semblables : les mêmes propriétés structurelles (attributs); le même comportement (opérations, méthodes); les mêmes liens avec les autres objets; et ayant un intérêt pour l'application. Encapsule les données et les traitements : La classe Facture : {NumFacture, DateFacture, …, Imprimer(), Solder(), ...}

6

2-Concepts orientés objet L’ENCAPSULATION Est un principe qui consiste à : cacher les données et les détails d'implantation (algorithmes) et laisser visible la partie interface (signatures des opérations publiques) des classes Approche classique

Approche objets Inte rfac e

Encapsulation

Inte rfac e

Inte rfac e

Données

Traitements

Echange de messages

7

2-Concepts orientés objet L’HERITAGE Est un mécanisme permettant le partage des caractéristiques d’une classe (généralisation) par une ou plusieurs autres classes (spécialisations).

Personne

Nom, Prénom, Adresse, ...

Héritage simple Cours, Diplôme, ...

Enseignant

Etudiant

Année, ...

Héritage multiple

Etudiant_Enseignant Numéro, TD, ...

8

3-Démarche Orientée objet Principales étapes de conception objet Le cycle de vie du logiciel suivant une approche objet est Itératif et Incrémental. Itératif : l’architecture subit plusieurs cycles d’analyse, de conception et d’implémentation. Incrémental : les décisions sont raffinées à chaque cycle d’analyse / conception / implémentation, menant à un système qui répond plus aux exigences. Dans chaque itération, on s’intéresse aux activités suivantes : Identifier les classes et les objets à un niveau donné d’abstraction Identifier les relations entre classes Spécifier l’interface des classes. Phase Conception

9

4-Démarche Orientée objet Analyse : Modéliser le domaine d’activité du client. Conception : Choisir l’architecture du système et définir la responsabilité de chaque composant. Implémentation : Définir l’algorithme de chaque programme

10

4-Démarche Orientée objet Les différents points de perception d’un système : La vision statique : Description des entités représentant l’univers de discours et de leurs relations. De quoi est fait le système ? La vision dynamique : Description des évolutions, dans le temps, des entités représentant l’univers de discours. Comment il peut évoluer ? La vision fonctionnelle : Description du fonctionnement (des différentes fonctionnalités) du système. Comment il fonctionne ?

11

4-Démarche Orientée objet Modèle statique Décrire les objets : . structures de données . opérations . liens entre les classes

Modèle fonctionnel

Contrôler les évolutions, dans le temps, des objets du système Modèle dynamique

Décrire le fonctionnement du système 12

5-UML - Le langage Objet unifié Unified Modeling Language UML est un langage formel (ou pseudo-formel) basé sur un métamodèle. Le métamodèle permet de définir : • les concepts et éléments de modélisation • la sémantique de ces éléments

UML se base sur une notation graphique UML propose neuf types de diagrammes • représentent les aspects statiques et dynamique • couvrent l’ensemble des phases de développement

UML est ouvert et extensible

13

6-UML - Le langage Objet unifié Historique UML est un langage de modélisation objet et non une méthode 2005

UML 2.0 UML 1.4

01/ 99

révision 1.3

UML 1.3

11/ 97

Adoption par l ’OMG

UML 1.1

01/ 97

Soumission à l ’OMG

UML 1.0

10/ 96

UML 0.91

06/ 96

UML 0.9 Unified Method 0.8 Booch 93

OMT-2

Booch 91

OMT-1

OOSE 14

7-Les différents diagrammes du langage UML

Spécifications de besoins - Diagramme de cas d’utilisation, - Diagramme d’activités. Le modèle structurel - Le diagramme de classes, - Le diagramme d’objets.

15

7-Les différents diagrammes du langage UML Le modèle dynamique - Le diagramme de cas d’utilisation, - Le diagramme d’interaction (collaboration, séquence), - Le diagramme d’états. Architecture - le diagramme de composants, - le diagramme de déploiement. 16

8-Ateliers UML Critères de sélection • Nombre de diagrammes supportés • Génération automatique de diagrammes • Génération de code - langages supportés • Rétro ingénierie (reverse engineering) • Prototypage • Synchronisation du code avec modifications extérieures • API • Echanges avec d’autres AGL UML ou IDE • Utilisation pratique (schémas de qualité, convivialité, générer des images, ... ) • Patterns de conception - et création de patterns • ...

17

8-Ateliers UML

Quelques AGL : • StarUML : http://staruml.io/

•Together ( Togethersoft) http://www.togethersoft.com • Rational ROSE (Rational corp.) http://www.rational.com • Paradigm (Platinium) http://www.platinium.com • Magic Draw UML (NoMagic) http://www.nomagic.com • DOM (ObjetDirect) http://www.objetdirect.com • Objecteering (SoftTeam) http://www.objecteering.com • Aonix Life Cycle Desktop (Aonix) http://www.aonix.com, .fr • UML Studio (Pragsoft) http://www.pragsoft.com

18

Bibliographie Livres : Modélisation objet avec UML JA Muller, N. Gaertner. Editions Eyrolles. UML par la pratique UML en action De Merise à UML, … Cours : MM : F.Gargouri & K.Haddar

Sur le Web : http://www.omg.org/uml/ http:// www.rational.com http://www.uml.free Sous google : UML

Français

19

MOO (UML) Chapitre 1: Le diagramme de cas d’utilisation

Responsable : Achraf MTIBAA

20

Chapitre 1: Le diagramme de cas d’utilisation Les cas d’utilisation (use cases) ont été formalisés par Ivar Jacobson. Les cas d’utilisation décrivent, sous la forme d’actions et de réactions, le comportement d’un système du point de vue d’un utilisateur. Un cas d’utilisation est une manière spécifique d’utiliser un système. C’est l’image d’une fonctionnalité du système, déclenchée en réponse à la stimulation d’un acteur externe.

21

1-Définitions Définition 1: Un cas d’utilisation (use case) modélise une interaction entre le système informatique à développer et un utilisateur ou acteur interagissant avec le système. Définition 2: Un cas d’utilisation décrit un ensemble d’actions réalisées par le système qui produit un résultat observable pour un acteur.

Spécifications

Use Cases

Analyse

Tests 22

Définitions Les cas d’utilisation : servent de base à la traçabilité des exigences d'un système dans un processus de développement intégrant UML. se limitent aux préoccupations "réelles" des utilisateurs : ne présentent pas de solutions d'implémentation et ne forment pas un inventaire fonctionnel du système. Un cas d’utilisation avec UML : est la solution pour représenter au niveau conceptuel, les besoins des utilisateurs (Merise ne permet pas cette modélisation). permet de structurer les besoins des utilisateurs et les objectifs (fonctionnalités) correspondants d'un système. identifie les utilisateurs du système (acteurs) et leurs interactions avec le système. permet de classer les acteurs et structurer les objectifs du système. 23

Définitions Les cas d’utilisation : Recentrent l’expression des besoins sur les utilisateurs ne doivent pas chercher l'exhaustivité, mais clarifier, filtrer et organiser les besoins Partitionnent l’ensemble des besoins d’un système. Les besoins: définissent le contour du système à modéliser ils précisent le but à atteindre, permettent d'identifier les fonctionnalités principales (critiques) du système.

24

2-Intérêt des cas d’utilisation Utilisateur C

Ensemble des besoins

Utilisateur A

Utilisateur B

Les cas d’utilisation partitionnent l’ensemble des besoins d’un système

Cahier des charges

25

3-Concepts de base : les acteurs Définition 1 : Représente un rôle joué par une entité externe (utilisateur humain, dispositif matériel, ou autre système) qui interagit directement avec le système étudié Définition 2 : Une entité externe agissant sur le système qui peut : Échanger de l’information avec ce système consulter ou modifier l'état du système, Les acteurs sont : Déterminés en examinant les : Utilisateurs directs du système Responsables de l’exploitation et/ou de la maintenance Autres systèmes interagissant avec le système Représentés sous forme de petits personnages ou sous forme de rectangle avec le mot clé 26

4-Grandes catégories d’acteurs Les acteurs principaux…les personnes qui utilisent les fonctions principales du système. Les acteurs secondaires…les personnes qui effectuent des tâches administratives ou de maintenance. Le matériel externe…les dispositifs matériels incontournables qui font partie du domaine de l’application et qui doivent être utilisés. Les autres systèmes… les systèmes avec lesquels le système doit interagir.

27

5-Concepts de base : les cas d’utilisation Définition 1 : Un ensemble d'actions réalisées par le système, en réponse à une action d'un acteur Définition 2 : Modélise une fonctionnalité d’un système ou d’une classe Les cas d’utilisation : sont représentés par des ellipses Peuvent être contenus dans un rectangle (représentant le système) Sont déterminés en observant et en précisant Acteur par acteur les scénarios du point de vue utilisateur Sont décrits en termes : d’informations échangées et d’étapes d’utilisation du système.

28

Concepts de base : les cas d’utilisation Un cas d’utilisation : Regroupe une famille de scénarios d’utilisation Est une abstraction du dialogue système/utilisateurs Quand un acteur interagit avec le système: Le cas d’utilisation instancie un scénario L'ensemble des cas d’utilisation décrit les objectifs du système Utilité des cas d’utilisation pour : les utilisateurs : exprimer les besoins Les analystes : comprendre Les programmeurs : réaliser Les testeurs : vérifier 29

Concepts de base : les cas d’utilisation Une fois identifiés, les acteurs doivent être décrits d’une manière claire et concise, en trois ou quatre lignes maximum. Lorsqu’il y a beaucoup d’acteurs dans un système, il est conseillé de les regrouper par catégories afin de faciliter la navigation dans le modèle des cas d’utilisation Les cas d’utilisation doivent être vus comme des classes dont les instances sont les scénarios. Un scénario correspond au flot de messages échangés par les objets. 30

Concepts de base : relations entre cas d’utilisation Association (relation de communication): Relation entre un acteur et un cas d’utilisation Un acteur déclenche un cas d’utilisation : Acteur

CasUtilisation

Relation d’inclusion : Entre cas d'utilisation CasUtilisation1 L’instance du CU source contient aussi le comportement décrit par le CU destination.

CasUtilisation2

31

Concepts de base : relations entre cas d’utilisation

Relation d’inclusion (suite) : La relation d’inclusion a un caractère obligatoire: La source doit indiquer à quel endroit le CU cible doit être inclus Permet de : Décomposer les comportements et Définir des comportements partageables entre plusieurs CU. Relation d’extension : Entre cas d'utilisation L’instance du CU source ajoute son comportement au CU destination (si la condition est réalisée). Le CU destination étend son comportement par l’ajout de celui du CU source, si la condition est vérifiée.

[condition d'extension]

CasUtilisation1

CasUtilisation2

32

Concepts de base : relations entre cas d’utilisation Relation d’extension (suite) : Peut être soumise à une condition : Le comportement ajouté est inséré au niveau d’un point d’extension Ce point d’extension est défini dans le CU destination Permet de modéliser des variantes de comportement d’un CU Selon les interactions des acteurs et l’environnement du système la condition d’extension peut être spécifiée à côté du mot-clés Point d’extension : Possède un nom Décrit : Un emplacement dans le CU destination où le comportement du CU source sera inséré. UML ne définit aucun format de description de point d’extension 33

Concepts de base : relations entre cas d’utilisation Relation de généralisation : Entre cas d'utilisation Le cas d’utilisation Fils est une spécialisation du cas d’utilisation Parent

CasUtilisationParent Virement

CasUtilsationEnfant

VirementParInternet

Exemple : On désire représenter par un diagramme de CU les virements bancaires effectués par des clients: Un client peut être local ou distant Un client peut effectuer un virement via Internet ou direct (banque) Dans tous les cas, on doit procéder à une identification du client Dans le cas d’un virement dont le montant dépasse 500, on procède à une vérification du solde du compte du client. 34

Exemple Client Local

Virement Client Distant

Montant > 500

VirementInternet

Identification

Vérification solde compte 35

Exemple

Et voici le point d’extension : Virement Points d’extension

• Vérification supplémentaire: après identification

36

MOO (UML) Description des cas d’utilisation (Suite Chapitre I)

Responsable : Achraf MTIBAA

37

Description des cas d’utilisation Il n’existe pas de norme (UML) établie pour la description textuelle des cas d’utilisation. Généralement, on y trouve pour chaque cas d’utilisation : son nom, un bref résumé de son déroulement, le contexte dans lequel il s’applique, les acteurs qu’il met en jeu, une description détaillée : le déroulement nominal de toutes les interactions, les cas nécessitant des traitements d’exception, les effets du déroulement sur l’ensemble du système, etc. 38

Description des cas d’utilisation Sommaire d’identification Titre : ……………….. Type : ………………… Résumé :……………………………………………………………………………… Acteurs : Date de création : Date de mise à jour :………………………………… Version : Auteur(s) : Description des Enchaînements : Pré conditions : Scénario nominal : 1. 2. … Enchaînements alternatifs : A1… A2… Contraintes …. 39

Exemple de Cas d’utilisation Sommaire d’identification Titre : Traiter le passage en caisse Résumé : un client arrive à une caisse avec des articles à acheter. Le caissier enregistre les achats et récupère le paiement. A la fin de l’opération, le client part avec les articles. Acteurs : Caissier (P), Client (S), Gestion des stock (S) Date de création : Date de mise à jour :………………………………… Version : 1 Auteur(s) : Etudiants 2ème année Description des Enchaînements : Pré conditions : La caisse est en service : un caissier y est connecté Scénario nominal : Représente le déroulement normal d’un cas d’utilisation : les différentes interactions utilisateur / système permettant l’exécution réussie du traitement (voir suite)

40

Exemple de Cas d’utilisation 1. Ce CU commence quand un client arrive à la caisse avec des articles qu’il veut acheter. 2. Le caissier enregistre chaque article. S’il y a plus d’un exemplaire par article, le caissier indique également la quantité.

3. La caisse détermine le prix de l’article et ajoute des informations sur l’article à la vente en cours. La caisse affiche la description et le prix de l’article en question.

4. Après avoir enregistré tous les articles, le caissier indique que la vente est terminée.

5. La caisse calcule et affiche le montant total de la vente.

6. Le caissier annonce le montant total au client. 7. Le client choisit le type de paiement : a. En cas de paiement … b. En cas de … c. En cas … 8. La caisse enregistre la vente et imprime … 9. Le caissier donne le ticket de caisse au client.

41

Exemple de Cas d’utilisation Enchaînement alternatif : Quand l’enchaînement précisé par le scénario nominal ne peut pas se dérouler comme prévu : Le cas d’utilisation converge tout de même. Exemple: Numéro d’identification d’un article est inconnu l’enchaînement démarre au point 2 du scénario nominal. 3. La caisse indique que le numéro d’identification de l’article est inconnu. L’article ne peut alors pas être pris en compte dans la vente encours. Le scénario reprend au point 2.

42

Exemple de Cas d’utilisation Enchaînement d’erreur : Quand l’enchaînement précisé par le scénario nominal ne peut pas se dérouler : Le cas d’utilisation se termine par un échec. Exemple: Client ne pouvant payer (ou le centre d’autorisation refuse le payement) l’enchaînement démarre au point 6 du scénario nominal. 7. Le client ne peut pas payer le total avec aucun des moyens autorisés. 8. Le caissier annule l’ensemble de la vente et le cas d’utilisation se termine en échec : la vente ne peut pas avoir lieu

43

Fonctionnement des caisses enregistreuses d’un super marché : Un client arrive à la caisse avec des articles à payer. Le caissier enregistre le numéro d’identification de chaque article, ainsi que la quantité si elle est > 1. La caisse affiche le prix de chaque article et son libellé. Quand tous les achats sont enregistrés, le caissier signale la fin de la vente. La caisse affiche alors la fin des achats et le prix total à payer. Après la saisie des articles, le client peut présenter des coupons de réduction pour certains articles Le client choisit son mode de paiement : Liquide : le caissier encaisse l’argent reçu, la caisse indique le montant à rendre au client. Chèque : le caissier vérifie la solvabilité du client en transmettant une requête à un centre d’autorisation via la caisse. Carte de crédit : un terminal bancaire fait partie de la caisse et transmet une demande d’autorisation en fonction du type de la carte. La caisse enregistre la vente et imprime le ticket. Le caissier donne le ticket au client. Quand le paiement est terminé, la caisse transmet l’information sur le nombre d’articles vendus au système de gestion des stocks. chaque matin, le responsable du magasin initialise les caisses pour la 44 journée.

Exemple de Cas d’utilisation

Initialier la caisse

Responsable Magasin

Caissier

Traiter le passage en caisse

Prendre en compte coupons

Gestion des stocks



Centre autorisation cartes

Client Traiter le Paiement

Paiement Liquide

Paiement Chèque

Paiement Carte

Centre autorisation chèques 45

MOO (UML) Chapitre II: Diagramme de classes

Responsable : Achraf MTIBAA

46

Chapitre 2 : Les diagrammes de classes Les diagrammes de classes expriment la structure statique d’un système en termes : De classes et de relations entre elles et Un ensemble d’interfaces et de paquetages ainsi que leurs relations. Une classe décrit un ensemble d’objets, une association décrit un ensemble de liens Les objets sont instances des classes et les liens sont instances des associations Un diagramme de classes décrit de manière abstraite les liens potentiels

d’un objet vers d’autres objets.

Lien

1,N Objet 1, N

Est une instance de Relation

0,N Classe 1, N

Est une instance de 47

1- Concepts de base AVEC UML, UNE CLASSE : est un type abstrait avec des caractéristiques communes à un ensemble d'objets. permet de créer des objets ayant ces caractéristiques Est représentée par un rectangle avec: Nom de Classe Propriétés Méthodes et Propriétés Exceptions / Conditions.

Méthodes

Classe = propriétés + méthodes + instanciation 48

Concepts de base LES ATTRIBUTS ET LES OPÉRATIONS : Sont décrits dans le deuxième et troisième compartiments Peuvent être précisés par : attributs et opérations Nom de Classe NomAttribut [: type = valeur initiale] Opération ()

Remarques : L’ordre opération / attribut = attribut / opération Opération = méthode = fonction-membre, … Attribut = propriété = donnée-membre, …

49

Concepts de base La syntaxe de description des attributs est : Visibilité NomAttribut [[Multiplicité] : Type [=ValeurInitiale] [{Propriété}]] Visibilité = type d'accessibilité : Public : visible et modifiable par tout objet du même paquetage Private : seulement visible et modifiable par les opérations de l'objet auquel il appartient. Protected : seulement accessible et modifiable par les opérations des classes descendantes Multiplicité : intervalle ou nombre Propriété : mutabilité (gelé, variable, ajout Uniquement, …) 50

2- Les relations entre classes Association Agrégation Composition Remarque : par rapport au modèle E/A de base Héritage RC UML + riches sémantiquement et + proches de la réalité Les associations : Une association exprime une connexion sémantique bidirectionnelle entre n classes (n>=1). Une association est instanciable dans un diagramme d'objets ou de collaboration sous forme de liens entre objets issus des classes associées. ADHERENT Nom Prénom Adresse

emprunter

EXEMPLAIRE

51

2- Les relations entre classes LES ASSOCIATIONS : représentent des relations statiques/conceptuelles entre objets et à longue durée de vie (n’est pas un lien instantané ni passager). Relient une ou plusieurs classes : arité 1 ou plus Par rapport au modèle Entité / Association : Entité 1

Diag. Entité / Association Diag. De classes

Card1

P11, P12 …

CEntité1

Card2

Ass

Card2

Entité 2 P21, P22 …

Card1

CEntité2 52

2- Les relations entre classes Arités des associations : Une association peut être binaire ou naire. Exemple : on désire représenter le fait suivant : un Professeur enseigne dans une salle des étudiants. PROFESSEUR Enseigner

SALLE

ETUDIANT

Si on veut matérialiser le cours

COURS Association porteuse de données 53

2- Les relations entre classes Les associations : Nommage Une association peut être nommée

Classe1

[ Nom Association ]

Classe2

Comment justifier la non obligation du nom de l’association : Aux niveaux conception et implantation Sens de lecture d’une association : Association en forme verbale active (ou passive) : précise le sens principal de lecture d'une association (> ou

HÔTEL

héberge>

PERSONNE

Association en forme verbale active

PERSONNE

SOCIÉTÉ

Association en forme verbale Passive 54

2- Les relations entre classes Association à navigabilité restreinte : Par défaut, une association est navigable dans les deux sens. On peut la limiter à un seul sens dans un modèle (et non lors de d'implémentation). indique que les instances d'une classe ne "connaissent" pas les instances d'une autre.

ELECTEUR

vote

ETUDIANT

Connaître

CANDIDAT

ENSEIGNANT

Les associations : Notion de rôle Rôle des associations (utilisé pour les associations ambiguës) : spécifie la fonction d'une classe pour une association donnée

Client HÔTEL

PERSONNE Directeur

PERSONNE

Parents

Enfants 55

2- Les relations entre classes La notion de rôle :

Classe1

[ Nom Association ]

[Rôle1]

Classe2

[Rôle2]

Rôle 1 : le rôle joué par Classe 1 dans l’association Rôle 2 : le rôle joué par Classe 2 dans l’association

Etudiant

Professeur

Enseigne

Est Enseigné 56

2- Les relations entre classes LES ASSOCIATIONS : CARDINALITÉS précisent le nombre d'instances qui participent à une relation. Combien d’objets de la classe considérée peuvent être liés à un objet de l’autre classe? 1

Un et un seul

0 .. 1

Zéro ou un

N

N (entier naturel)

M .. N

De M à N (entiers naturels)

*

De 0 à plusieurs

0 .. *

De 0 à plusieurs

1 .. *

De 1 à plusieurs 57

Un exemple illustratif

58

2- Les relations entre classes L’agrégation : Est une association non symétrique, Exprime un couplage fort et une relation de subordination. Représente une relation de type "ensemble/élément". Peut notamment (mais pas nécessairement) exprimer : qu'une classe (un "élément") fait partie d'une autre ("l'agrégat"), qu'un changement d'état d'une classe, entraîne un changement d'état d'une autre, qu'une action sur une classe, entraîne une action sur une autre. Une instance d'élément agrégé peut : être liée à plusieurs instances d'autres classes : l'élément agrégé peut être partagé (dans le temps) exister sans agrégat (et inversement) les CV de l'agrégat et de ses éléments agrégés peuvent être indépendants : La création de l’un n’implique pas celle de l’autre 59

2- Les relations entre classes Composition : La composition est une agrégation forte. Les cycles de vie des éléments (les "composants") et du composé coïncident : si le composé est détruit (ou copié), ses composants le sont aussi. une instance de composant ne peut être liée qu'à un seul composé. Les "objets composites" sont des instances de classes composées. LIVRE

COUVERTURE

Agrégation

CHAPITRE

Composition

Remarque : toutes les conventions relatives aux cardinalités restent valables pour les Agrégations et les compositions

60

Propriétés de la composition La composition implique une contrainte sur la valeur de la multiplicité du côté de l’agrégat : elle ne peut prendre que les valeurs 0 ou 1. La composition et les attributs sont sémantiquement équivalents.

Cylindre

Voiture

Immeuble

Moteur

Chambre

Cercle Carburateur

Point Rectangle

61

2- Les relations entre classes LA GÉNÉRALISATION : L’héritage, avec UML, est désigné par GENERALISATION Elle représente une relation de classification entre élément plus général et un élément plus spécifique. Elle peut être appliquée aux classes, aux paquetages et aux cas d’utilisations La généralisation peut être Simple ou GENARALISATION

SPECIALISATION

Remarque : une classe généralisée peut être spécialisée selon ≠ critères

Multiple : La spécialisation a plus qu’une généralisation 62

2- Les relations entre classes Contraintes et propriétés de la généralisation : Les attributs, les opérations, les relations et les contraintes définies dans les super-classes sont hérités dans les sous-classes La contrainte exprimée par le mot-clé {disjoint} Tout objet est au plus instance d’une seule sous-classe La généralisation, par défaut, symbolise une décomposition exclusive. La contrainte exprimée par le mot-clé {chevauchement} Une classe descendante au produit cartésien de ses classes généralisées VEHICULE

Premier critère

Motorisation

Milieu

Deuxième critère

{chevauchement} A VOILE

A MOTEUR

TERRSETRE

LES DEUX

MARIN 63

2- Les relations entre classes Contraintes et propriétés de la généralisation : La contrainte exprimée par le mot-clé {complet} Indique que la généralisation est terminée : Il n’est pas possible d’ajouter d’autres sous-classes La contrainte exprimée par le mot-clé {incomplet} Indique que la généralisation est extensible : elle peut avoir d’autres spécialisations COURS

{incomplet} COOSI

IA

GL

BDA

64

2- Les relations entre classes LES ASSOCIATIONS : CONTRAINTES La multiplicité représente un exemple de contrainte sur le nombre de liens qui peuvent exister entre deux objets. permettent d'étendre ou de préciser la sémantique permettent de restreindre le nombre d'instances visées

peuvent s'exprimer en : Langage Naturel ou graphiquement avec un {texte} ou

En OCL (Object Constraint Language) Les types de contraintes exprimables sur les associations : Ordonné; Sous-ensemble;

Ou-exclusif, … 65

2- Les relations entre classes Les associations : Contraintes Ordonné : PERSONNE

1

0..*

COMPTE

{ordonné}

La collection des comptes d’une personne est triée

Sous-ensemble : SERVICE

1

Numéro_S Nom_S ...

affecter

1..*

Numéro Nom

{sous-ensemble}

0..1

diriger

EMPLOYE

1

....

66

2- Les relations entre classes Les associations : Contraintes Ou-exclusif : Indique que pour un objet donné, une seule association est valide BATTERIE

PORTABLE

{Ou-exclusif} SECTEUR

Alimenter

Cette contrainte permet d’éviter l’introduction de classes artificielles

PORTABLE

Alimenter

ENERGIE

SECTEUR

BATTERIE 67

2- Les relations entre classes Classe d'association : est une classe qui réalise la navigation entre les instances d'autres classes. représente les associations porteuses de données. Passe >

ETUDIANT

EXAMEN

NOTE Remarque : classe d’association (Cde, Client, Facture)& attribut de lien (Cde, produit, QteCdée) Qualification : permet de sélectionner un sous-{} d'objets, parmi ceux participant à une association. est définie par une clé, qui permet de sélectionner les objets ciblés.

Personne 0..1

E-mail

Réseau 68

Grammaire OCL : Object Constraint Language

Langage formel pour l’expression de contraintes, standardisé par l’OMG. Supprimer des ambiguïtés en se basant sur une grammaire précise. OCL permet l’expression des contraintes suivantes : - Les invariants au sein d’une classe ou d’un type, - Les contraintes au sein d’une opération, - les pré- et post-conditions d’opération Chaque contrainte OCL est liée à un contexte définissant le type auquel la contrainte se rapporte. Exemple : Context Classe d’école : : ajouter (unElève : Personne) pre classeD’écoleNonSurchargée : nbr_élèves 0..*

CIN{unique } ...

Adhésion Date Type

Bibliothèque Nom …

Personne (CIN, …) Bibliothèque(Id_bib, …) Adhésion(CIN#, Id_bib#, Date, Type)

Table Adhésion

Colonne Clé primaire OiD de Bibliothèque

CIN Id_bib Date Type

Domaine String(13) Identifiant Date String(13)

Non Null Oui Oui Oui Oui

Transformation de l’héritage Héritage Personne CIN Nom Prénom

Etudiant NumEtudiant AnnéeEtude

Les sous classes ont la même clé primaire que la superclasse Remarque: Un attribut « type » est ajouté à la superclasse dans le cas d’une spécialisation complète Il existe trois choix : •

Aplatir vers le haut

•

Aplatir vers le bas

•

Conserver les niveaux

Enseignant Grade Spécialité

Transformation de l’héritage Aplatir vers le haut Personne (CIN, Nom, Prénom, NumEt, AnnéeEtude, Grade, Spécialité, T) Dom(T)={Étudiant, Enseignant, Autre} Contraintes: SI Type = Autre ALORS NumEt=AnnéeEtude= Grade=Spécialité=Null SI Type = Étudiant ALORS Grade=Spécialité=Null SI Type = Enseignant ALORS NumEt=AnnéeEtude= Null

Aplatir vers le bas Personne (CIN, Nom, Prénom) Étudiant (CIN, Nom, Prénom, NumEt, AnnéeEtude) Enseignant (CIN, Nom, Prénom, Grade, Spécialité) Contraintes: La classe Personne est concrète.

Transformation de l’héritage

Conserver les niveaux: Personne (CIN, Nom, Prénom) Étudiant (CIN, NumEt, AnnéeEtude) Enseignant (CIN, Grade, Spécialité) Contraintes: Projection(Etudiant, CIN) incluse Projection(Personne, CIN) Projection(Enseignant, CIN) incluse Projection(Personne, CIN)

MOO (UML) Chapitre III: Diagramme d’Objets

Responsable : Achraf MTIBAA

83

CHAPITRE 4 : DIAGRAMME D’OBJETS

Servent durant la phase exploratoire de l’analyse Représentent la structure statique du système modélisé. Montrent : des objets (instances de classes) dans un état particulier et des liens (relations sémantiques) entre ces objets. Position des diagrammes objets dans un processus de modélisation : Use Cases

Spécifications Diag. objet

Conception

Modèles dynamiques

84

Concepts de base Un diagramme d’objets: est une instance d’un diagramme de classes Montre un contexte particulier (objet + lien) facilite la compréhension des structures de données complexes. Représentation des objets : Un objet est représenté par un rectangle qui contient : le nom de l'objet ou, le nom et la classe de l'objet ou la classe de l'objet. Le nom de la classe peut contenir le chemin complet, composé à partir des noms différents paquetages englobants repérés par deux points Nom Objet Mohamed

Nom Objet : Classe

Mohamed : PERSONNE

:Classe :PERSONNE

85

1- Concepts de base Représentation des objets : Un groupe d’objets :

:Personne

Le rectangle représentant un objet peut comporter une partie contenant les valeurs des attributs de l’objet : Ahmed : ADHERENT Nom = Mohamed Prénom = Ahmed Adresse = Sfax

: VOITURE Couleur = rouge Puissance = 4 Marque = Peugeot

86

Concepts de base

Représentation des liens entre objets : Les liens entre objets sont : Des instances des associations entre les classes des objets participants Permettent une représentation plus concrète que celle produite par les diagrammes de classes. Exemple : V1:Voiture

:Moteur

Voiture

1

1

Moteur

1

4 R1:Roue

R3:Roue R2:Roue Diagramme d’objets

R4:Roue

Roue Diagramme de Classes 87

Concepts de base Représentation des liens entre objets : Les liens entre objets peuvent être naires. Exemple :

: Professeur

: Salle

: Etudiant

On peut indiquer les noms des objets et des liens :

Ahmed : ADHERENT Nom = Mohamed Prénom = Ahmed Adresse = Sfax

emprunter

UML en Action : EXEMPLAIRE

88

1- Concepts de base Représentation des objets composites : Un objet composite est composé d’autres objets (sous-objets) Le nombre d’instances du composant peut être spécifié

Un Composite Exemple:

:Partie1

:Partie2 : Fenêtre

: Zone de dessin : ascHorizontal

Remarque : Ces diagrammes ne sont utiles que durant la phase exploratoire d’un domaine. Ils deviennent vite compliqués et illisibles 89

MOO (UML) Chapitre IV: Diagramme de Collaboration

Responsable : Achraf MTIBAA

90

CHAPITRE 4: DIAGRAMME DE COLLABORATION (DCO) Les diagrammes de collaboration : représentent : Une extension des diagrammes d’objets le contexte d'une interaction en y précisant les états des objets en collaboration (interaction). présentent : des rôles joués par des objets dans un contexte particulier et les liens entre ces objets. montrent : des interactions entre objets (instances de classes et acteurs). les interactions entre ces objets par des envois de messages

91

1-Sémantique Les diagrammes de collaboration : permettent : une représentation (structure) spatiale des objets, des liens et des interactions (graphe dont les nœuds = intervenants et les arcs = les interactions). Une dimension temporelle (ordre de déclenchement) par l’ajout de numéros de séquence des messages échangés (on ne représente pas le t de déclenchement ni la durée). L’objectif est de construire un modèle expliquant la coopération entre les objets utilisés pour la réalisation d’une fonctionnalité. Autrement : Décrire le comportement collectif d’un ensemble d’objets En vue de réaliser une opération en décrivant leurs interactions modélisées par des envois (éventuellement numérotés) de messages

92

Sémantique Dans un diagramme de collaboration : les interactions sont représentées par les échanges de messages. l’ordre des messages peut être indiqué par leur énumération. Plusieurs types de messages existent : simples, synchrones, asynchrones et minutés. Conventions graphiques : les objets sont représentés par un rectangle dont le nom et la classe sont soulignés.

Nom Objet

Nom Objet : Classe

:Classe 93

Sémantique Représentation Générale : 3: opération (paramètre) 2 : opération

1 : événement

Objet1 : nom classe

Objet 2

4 : opération 5 : opération (paramètres)

Nom acteur : Nom de la classe

Objet 3

:nom de la classe Flux de données 94

2-Concepts de base

Une collaboration : Est la réalisation d’une opération ou d’un cas d’utilisation dans un contexte particulier. Possède deux types de descriptions : Une description générale au niveau spécification, donnant: Les rôles joués par les intervenants et les rôles des associations Une interaction : une séquence de messages partiellement ordonnés échangés entre les rôles des intervenants Une description spécifique au niveau instance, représentant : Une instance particulière d’une interaction avec les objets et les liens respectant les rôles définis au niveau spécification, et les stimulus (instances des messages) échangés entre ces objets.

PA Muller, N. Gaertner

95

Concepts de base La notion de rôle : Les objets et les associations jouent des rôles particuliers dans une collaboration. Exemples :

:C

/R:C /R

Un rôle anonyme de la C Un rôle R de la classe C Un rôle R

:C

Objet anonyme, instance de C

/R:C O. anonyme de C jouant le rôle R

/R

O. anonyme jouant le rôle R

O/R:C Objet O, instance de la classe C, jouant le rôle R 96

Concepts de base Représentation au niveau spécification: Forme un graphe de rôles des intervenants (nœuds) liés à des rôles d’association (arcs) Exemple : Collaboration représentant le fait qu’une maison peut être louée à un ou plusieurs locataires pour un loyer donné.

/Locataire : Personne

*

+habitant

1

+habitation

/Maison : Logement

1 1

*

1 + adresse

:Lieu

1 +loyer :Coût

1

+loueur

/Propriétaire : Personne

97

Concepts de base Représentation au niveau instance : Forme un graphe d’instances qui se conforment aux rôles des intervenants et des associations définis au niveau spécification On peut y ajouter des instances de messages échangés Les objets et les liens utiles pour réaliser une action sont ajoutés Exemple : Une instance du diagramme précédent avec : Un acteur qui déclenche l’opération et des Stimuli (communication entre objets) 1: revenuDeLocation(pourLesMaisons) Loueur / Propriétaire : Personne :Client

:Coût

1.1 *[i:=1..n]:loyer() 1.1.i : valeur()

/Maison:Logement

98

Concepts de base Représentation au niveau instance : Généralement : Les rôles ne sont pas indiqués Les objets, les liens et les stimuli sont représentés Exemple :

1:total:=valeurStock()

:Entreprise :Client

1.1.1 : Créer(0,0) 1.1.2.i : ajout(p)

2:afficher(total) 1.1 : calculValeur()

:Afficheur

:Stock

:SRéel

:Produit 1.1.2 * [i:=1..n]:p:=ValeurP() 99

Concepts de base Les messages : Le terme Stimulus désigne : Une communication entre objets invoquant une opération ou L’émission d’un signal ou la création et destruction d’un objet Le terme message : Un message est la spécification d’un stimulus définissant : Le rôle des objets émetteur et récepteur L’action qui envoie un stimulus quand elle s’exécute. Un message est l’avènement d’une communication permettant : La transmission de certaines informations et Éventuellement avoir des résultats. Un envoi de message entre un émetteur et un récepteur nécessite que le dernier puisse réaliser l’activité définie par le message. 100

3.2 : afficher (liste) 2.3 : afficher ("prêt accordé") 1.3 : afficher("autorisé") 4 : retrait des cassettes obtenues 1.2 : afficher ("refus", raison) 2. référence_film(titre_film) 1 : emprunter des cassettes

:F.Gestion des prêts

3 :rep := demande de réservation : Adhérent

1.1 : res, raison := vérifier droits (adhérent)

Contrôleur des droits

2.2 : dispo, cass_id := recherche_cassettes(id_film, boutiq_id)

3.3 rep, boutique :=choix_boutique 3.1 : liste := liste_boutique_dispo

3.5 : rep := recherche étendue

2.1 : existe, id_film := recherche_film(titre) 2.4 : réserver(adh_id, boutiq_id) 3.6 : recherche_film(titre)

Film

3.4 : réserver (adh_id, boutique) Ens Films

2.2.1 :*[i=mes_cassettes] dispo : = dispo(boutiq_id)

: Catalogue général :Empr unt

Ens Cassette 2.4.1 : créer (adh_id, cass_id, bouti_id) 3.4.1 : créer (adh_id, cass_id, boutique)

Diagramme de collaboration emprunt – club vidéo

101

Remarques Les acteurs du diagramme de cas d’utilisation sont aussi présents au niveau du diagramme de collaboration Les cas d’utilisation se transforment en un ou plusieurs messages échangés entre les intervenants du diagramme de collaboration Il y a plus d’intervenants et de liens au niveau du diagramme de collaboration qu’au niveau du diagramme de cas d’utilisation

102

MOO (UML) Chapitre V: Diagramme de Séquences

Responsable : Achraf MTIBAA

103

CHAPITRE 5 :DIAGRAMME DE SEQUENCES (DES) Les diagrammes de cas d’utilisation ont permis : aux utilisateurs d’exprimer leurs besoins. De dresser une première liste des objets et des acteurs constituant le système. Les diagrammes de collaboration ont permis de : détailler les diagrammes de cas d’utilisation. Préciser comment les objets et les acteurs doivent collaborer ensemble pour réaliser chacun de ces cas d’utilisation. Les diagrammes de séquence : Ajoutent une dimension temporelle aux diagrammes de collaboration. Se concentrent sur la séquence des interactions selon un point de vue temporel (durée, arrivée, séquencement, …)

104

1-Formalisme DSE est une version plus complète du diagramme « trace d’événements » de la méthode (OO) OMT. Permet de présenter les scénarios d’un cas d’utilisation donné. Un message reçu par un objet déclenche l’exécution d’une opération et en général renvoie un message qui correspond au résultat de l’opération.

105

2-Sémantique Les diagrammes de séquence : permettent de représenter des collaborations entre objets selon un point de vue temporel : on s’occupe de la chronologie des envois de messages (durée et instant). on n'y décrit pas le contexte ou l'état des objets : la représentation se concentre sur l'expression des interactions servent à illustrer un cas d'utilisation. Représentent les aspects dynamiques d’un système. Représentation Générale : Objet 2 : classe de l’objet

Objet 1 Annotations While Y loop

Evt 1

Objet 3

[x] Opération 1

: classe de l’objet

Opération 2 (paramètres)

End loop

[non x] opération 3

106

3-Concepts de base Remarques : Les objets étudiés sont placés sur la première ligne Tout objet a une ligne de vie : une barre verticale en pointillée L’axe temps, dans chaque diagramme, est représenté (implicitement) de haut vers le bas L'ordre d'envoi d'un message est déterminé par sa position sur l'axe vertical du diagramme Les messages sont représentés par des flèches orientées : émetteur – destinataire. La disposition des objets sur l'axe horizontal n'a pas de conséquence pour la sémantique du diagramme. Les branchements conditionnels sont indiqués par un pseudocode ou par [ ] On peut aussi placer en pseudo –code les boucles d’itération. 107

Exemple Appelant

Ligne Téléphonique décrocher

Appelé

tonalité Numérotation Indication de sonnerie Sonnerie

décroche allô

108

4- Les activations et envois de messages

Une période d’activité correspond au temps pendant lequel un objet effectue une action. Un Objet

Activation Durée d’activation

On distingue trois grandes catégories d’envois de message 1- Flot de contrôle à plat : est utilisé pour indiquer la progression vers la prochaine étape d’une séquence

109

Envois de messages Objet émetteur

Objet destinataire

Flot de contrôle à plat

2- Appel de procédure ou flot de contrôle emboîté : la séquence emboîtées doit se terminer pour que la séquence englobante reprenne le contrôle A

B

C

procédure

B récupère le contrôle après que C a fini sa tâche

une sous-procédure

A récupère le contrôle après que B a fini sa tâche

110

envois de messages 3- Retour d’un appel de procédure : le retour de message est explicite à la fin de l’exécution d’une sous-procédure et le retour éventuel de paramètres. A

B

retour explicite

Dans un DSE, deux types de messages peuvent être distingués Message synchrone : dans ce cas l’émetteur reste en attente de la réponse à son message. La flèche standard symbolise ce type de message. Le message retour peut ne peut être représenté, il est en fait inclus dans la fin d’exécution de l’opération déclenchée dans l’objet destinataire du message

111

5- Message synchrone et asynchrone -

Message asynchrone : dans ce cas, l’émetteur n’attend pas la réponse à son message, il poursuit l’éxecution de ses opérations. C’est la demi-flèche qui symbolise ce type de message. A

B

Message synchrone

Message asynchrone

Un objet peut également s’envoyer un message. Cette situation se représente par une flèche qui boucle sur la Un Objet ligne de vie de l’objet. Message réflexif

112

6-Complément sur le DSE Création et destruction d’objet Si un objet est crée au cours de l’exécution d’un scénario, celui-ci n’apparaît qu’au moment où il est créé. Si l’objet est détruit dans un scénario, la destruction se présente par X. Objet 1 Objet 2

113

6-Complément sur le DSE Contrainte temporelle Des contraintes de chronologie entre les messages peuvent être spécifiés. De plus lorsque l’émission d’un message a besoin d’une certaine durée, il se représente sous la forme d’un trait oblique.

objet1:classe1

Objet2 : classe2

Un message

114

6-Complément sur le DSE Lorsque le diagramme de séquence est utilisé pour représenter un sous-ensemble du logiciel à réaliser, il est possible d’indiquer le pseudo-code exécuté par un objet pendant le déroulement d’une opération. Le diagramme de séquence est dit diagramme de séquence système quand il met en jeu acteurs et système. Le système reste une boîte noire (voir exemple (Nouvelle entrée).

Système

: Magasinier nouvelleEntrée(prod,qté)

vérifier_référence(prod) entréeEnregistrée entréeRefusée

si référence(prod) alors sinon finsi

115

7- Exemple : Diagramme de séquence retour – club vidéo F.Gestion des prêts

: Adhérent retour de cassettes(adh_id)

Cassette

Ens. Statistiques

Emprunt

afficher ("numéro cassette") Pour chaque cassette rendue afficher(mnt saisie(cass_id)

vérifier_réservation(adh_id)

réservé_pour(adh_id)

^(existe) ^(confirme) si confirme alors date_emprunt_et_tarif calcul(date_e,tarif_j)

calculer_prix_à_payer() stat:=créer (cass_id, adh_id,ma_boutiq, durée)

Statistique

[non_nul(stat)]ajouter(stat) supprimer()

disponible(ma_boutiq, aujourd'hui) finsi

fin_saisie mt:=calculer_prix_total() afficher(mt)

116

MOO (UML) Chapitre VI: Diagramme d’états transitions

Responsable : Achraf MTIBAA

117

Chapitre 7- Diagramme d’états transitions (DET) Les objets d’une classe ne sont pas figés : Ils peuvent évoluer et changer d’états au cours de leur CV. CV : cycle de vie = durée de vie : depuis sa création jusqu’à sa suppression Un DET d’une classe est une description des évolutions possibles de ses objets donnant : la liste des états que peut prendre l’objet durant son CV ; les événements déclenchant les changements d’états; les éventuelles conditions qu’il doit vérifier avant de changer d’états et les opérations qui le font passer d'un état à un autre. Un DET est une description des changements d'états d'un objet (ou d'un composant) : en réponse aux interactions avec d'autres objets/composants ou avec des acteurs. 118

1 Etat-transition et événement

L’état d’un objet est défini, à un instant donné, par l’ensemble des valeurs de ses propriétés. Seuls, certains états caractéristiques du domaine étudié sont considérés. Le passage d’un état à un autre état s’appelle transition Un événement est un fait survenu qui déclenche une transition. 119

Etat-transition et événement Un objet reste dans un état pendant une certaine durée. La durée d’un état correspond au temps qui s’écoule entre le début d’un état déclenché par une transition i et à la fin de l’état déclenché par la transition i+1. Une condition, appelée garde, peut être associée à une transition. Le formalisme de représentation d’état-transition est le suivant :

Etat i

Evt([Att]) [Condition(s)]/Action

Etat j 120

Etat d’un objet Un état : se caractérise par sa durée et sa stabilité, est une conjonction instantanée des valeurs des caractéristiques d'un objet. Dans un DET, on distingue trois états : - L’état initial :état avant la création de l’objet et - L’état final :état après la destruction de l’objet.

- L’état intermédiaire

Etat intermédiaire

121

2- Action et activité Une action est une opération instantanée qui ne peut pas être interrompue; elle est associée à une transition. Une activité est une opération d’une certaine durée qui peut être interrompue, elle est associée à un état d’un objet. Etat 1 do/ activité 1

transition [condition]/action

Etat 2 entry/ activité 2

122

3- Émission d’événement Après exécution d’une opération déclenchée par l’arrivée d’un événement, un nouvel résultat peut être émis vers un objet cible. Le formalisme de représentation de l’émission d’un événement est le suivant : Etat 1 do/ activité 1

transition [condition]/action ^cible.événement

Etat 2 entry/ activité 2

123

4-Représentation du diagramme étattransition d’un objet L’enchaînement de tous les états caractéristiques d’un objet constitue le digramme d’états. Un diagramme d’états débute toujours par un état initial et se termine par un ou plusieurs états finaux sauf dans le cas où le diagramme d’états représente une boucle. A un événement peut être associé un message composé d’attributs. 124

Exemple paiement Client prospect

passer 1ere commande

Client actif

Client douteux non paiement

limite financière dépassée Client en contentieux

Client inactif

une année sans commande

Client supprimé

Fin du contentieux

125

5- Super-Etat (ou généralisation d’états) état composite Dans le cas où une succession d’états peut se répéter plusieurs fois dans un même diagramme, il est possible de considérer cette succession d’états comme un super-état qui ne sera décrit qu’une seule fois dans le détail et utilisé dans sa globalité plusieurs fois. Un état composite est décomposé en sous-états, chaque sous-état peut également être un composite.

Super-état état 1

état 2 état 3

126

6- Exemple ordre de récrutement d'un personnel [date prévisionnelle > date du jour] crée()

En prévision d'arrivée

prise en fonction

En activité do/ renseigner la date d'arrivée à l'agence

départ de l'agence

Parti do/ renseigner la date de départ de la personne

127

Chapitre VII:

Diagrammes d’activités

Enseignant responsable : Achraf Mtibaa

Introduction Un diagramme d’activités (DA) représente le flot d’une activité à l’autre. Les activités : sont des opérations non atomiques. Elles finissent par exécuter une action composée de calculs atomiques qui aboutissent à un changement de l’état du système ou au retour d’une valeur.

129

Introduction Le DA est une variante du DET : Les DA utilisent beaucoup d’éléments du DET. Dans le DET, les états et les transitions sont mis en avant alors que dans le DA se sont les activités et les transitions qui sont mises en avant. Un DA correspond à un diagramme d’états vu sous forme « procédurale » avec une mise en évidence des actions/activités (d’où son nom).

130

Introduction Un diagramme d’activités peut être rattaché à un CU, à la réalisation d’une opération, ou à un processus impliquant l’utilisation d’un ou de plusieurs objets. En théorie, tous les mécanismes dynamiques pourraient être décrits par un diagramme d'activités, mais seuls les mécanismes complexes ou intéressants méritent d'être représentés (faisant intervenir plusieurs objets, créant ou modifiant divers objets, …). Une activité : plusieurs opérations DA : représente l’enchaînement des différentes opérations

La fin d’une opération engendre le début d’une autre 131

Les états d’action (et d’activités) Un état d’action modélise une étape dans l’exécution d’un algorithme ou d’un flot. C’est un état simplifié dans lequel figure une action d’entrée et duquel part au moins une transition automatique vers un autre état, déclenchée par la fin de l’action. Etudier devis

Index = recherche(e)+7

Exemples d’états d’action 132

Les transitions Une transition peut être automatique ou gardée. Une transition automatique est : franchie quand l’activité précédente est finie. Une transition gardée est franchie : quand l’activité précédente est finie et si la condition est vérifiée. Activité

Autre Activité

Transitions automatiques

133

Les transitions Demande dossier Recevoir dossier

Compléter dossier Enregistrer Transitions automatiques

134

Les transitions Transitions gardées

Examen candidature

/i=0 Afficher(i)

[rejetée]

[i