7478 - Cour Uml (Tutoriel) PDF

Méthode de conception orientée objet
http://www.docsflood.com 1
Plan
• Présentation d’UML
• Les cas d’utilisation
• Les diagramme de classes et diagrammes d’objets
• Les diagrammes d’états-transitions
• Les diagrammes d’activités
• Les diagrammes de séquences
• Les diagrammes de communication
Présentation d’UML
• Les méthode systémiques comme Merise ont marqué
une première évolution dans les années 80 autour
des idées de SI, de bases de données, de niveaux
de modélisation (conceptuel, organisationnel,
logique, physique) et de séparation données-
traitements.
• Depuis la fin des années 90, l’ACSI connaît une
deuxième évolution autour des idées d’objet
(regroupant données et traitement), de réutilisation
(code et conception).
• La démarche ne constitue plus à réécrire un modèle

d’un certain niveau dans les termes du niveau suivant
au moyen de règles de traduction.
• On passe d’un niveau à un autre par enrichissement
des éléments existants et adjonction d’éléments
nouveaux, en conservant le même formalisme.
Histoire
 L’apparition du paradigme objet a permis la naissance de
plusieurs méthodes de modélisation

OMT (Object Modeling Technique), OOSE (Object Oriented
Software Engineering), Booch, …
 Chacune de ces méthodes fournie une notation
graphique et des règles pour élaborer les modèles
Présentation d’UML - Histoire
 Entre 89 et 94 : le nombre de méthodes orientées objet

est passé de 10 à plus de 50
 Toutes les méthodes avaient pourtant d’énormes points
communs (objets, méthode, paramètres, …)
 Au milieu des années 90, G. Booch, I. Jacobson et J.
Rumbaugh ont chacun commencé à adopter les idées
des autres. Les 3 auteurs ont souhaité créer un langage
de modélisation unifié
Présentation d’UML - Histoire
http://www.docsflood.com
7
Les différents diagrammes d’UML
Un Diagramme est une représentation graphique d'un
ensemble d'éléments et de relations qui constituent un
système.
• UML définit neuf types de diagrammes divisés en
deux catégories :
1.diagrammes statiques (appelés aussi diagrammes
structurels) : diagrammes de classes, d'objets, de
composants, de déploiements et de cas d'utilisation.
2.diagrammes dynamiques (appelés aussi
diagrammes comportementaux) : diagrammes
d'activités, de séquences, d'états-transitions et de
collaborations.
Les cas d’utilisation (use cases)
• Un cas d’utilisation représente un ensemble de séquence
d’actions qui sont réalisées par le système et qui produisent un
résultat observable intéressant pour un acteur particulier.
• Diagramme de cas d’utilisation (use case): il représente les
interactions entre le système et les acteurs.
Acteur
• Un acteur représente un rôle joué par une entité externe
Les cas d’utilisation
(utilisateur humain, dispositif matériel ou autre système)

qui interagit directement avec le système étudié.
• Un acteur peut consulter et/ou modifier l’état du système,
en émettant et/ou en recevant des messages susceptibles
d’être porteurs de données.
• La même personne physique peut jouer le rôle de
Les cas d’utilisation - Acteur
plusieurs acteurs.
• D’autre part, plusieurs personnes peuvent jouer le même
rôle, et donc agir comme un même acteur.
comment identifier les acteurs
• Les acteurs candidats sont systématiquement :
oLes utilisateurs humains directs : faites donc en sorte

d’identifier tous les profils possibles, sans oublier
l’administrateur, l’opérateur de maintenance, etc.
oLes autres systèmes connexes qui interagissent aussi
directement avec le système étudié
comment représenter les acteurs
• La représentation graphique standard de l’acteur en UML est

l’icône appelé « stick man », avec le nom de l’acteur sous le
dessin.
• Autres représentations sont possibles : (1)
comment représenter les
acteurs
• Autres représentations sont possibles : (2)

acteurs
• Une bonne recommandation consiste à faire prévaloir

l’utilisation de la forme graphique du "stick man" pour
les acteurs humains et une représentation rectangulaire
pour les systèmes connectés.
acteurs
comment identifier les cas d’utilisation
• L’objectif est le suivant : l’ensemble des cas d’utilisation
doit décrire exhaustivement les exigences fonctionnelles

du système.
• Chaque cas d’utilisation correspond donc à une fonction
métier du système, selon le point de vue d’un de ses
acteurs.
comment identifier Les cas
• Pour chaque acteur, il convient de :

 Rechercher les différentes intentions métier avec
lesquelles il utilise le système
 Déterminer dans le cahier des charges les services
fonctionnels attendus du système.
d’utilisation
Nommer les cas d’utilisation par un verbe à l’infinitif

suivi d’un complément, du point de vue de l’acteur (et
non pas du point de vue du système).
Les cas d’utilisations :comment les analyser
Pour détailler la dynamique du cas d’utilisation, la procédure la

plus évidente consiste à recenser de façon textuelle toutes les
interactions entre les acteurs et le système.
• Le cas d’utilisation doit avoir un début et une fin
clairement identifiés.
• Il faut également préciser les variantes possibles,
telles que le cas nominal, les différents cas alternatifs
et d’erreurs, tout en essayant d’ordonner
séquentiellement les descriptions, afin d’améliorer
leur lisibilité.
Les cas d’utilisation :comment les représenter
• Le diagramme de cas d’utilisation est un schéma qui montre les
cas d’utilisation (ovales) reliés par des associations (lignes) à
leurs acteurs (icône du « stick man » ou représentation
graphique équivalente).
• Chaque association signifie simplement
« participe à »
• Un cas d’utilisation doit être relié à au moins un acteur.
comment représenter Les
cas d’utilisation
http://www.docsflood.com
21
scénario
Une fois les cas d’utilisation identifiés, il faut encore les
décrire.
• Scénario :
un scénario représente une succession particulière
d’enchaînements, s’exécutant du début à la fin du cas
d’utilisation. Un cas d’utilisation contient en général
un scénario nominal et plusieurs scénarios alternatifs
(qui se terminent de façon normale) ou d’erreur (qui
se terminent en échec).
• On peut d’ailleurs proposer une définition différente
pour un cas d’utilisation :
Les cas d’utilisation -
« ensemble de scénarios d’utilisation d’un système

reliés par un but commun du point de vue d’un
acteur »
scénario
Les cas d’utilisation :fiche de description
• La fiche de description textuelle d’un cas d’utilisation
n’étant pas normalisée par UML, on peut adopter la
structuration suivante :
Sommaire d’identification Inclut titre, résumé, date de création et de modification, version, responsable,
(obligatoire) acteurs…
Description des scénarios Décrit le scénario nominal, les scénarios (ou enchaînements d’erreur), mais aussi
(obligatoire) les préconditions et les postconditions.
Ajoute, si c’est pertinent, les informations suivantes : fréquence, volumétrie,

Exigences non-
disponibilité, fiabilité, intégrité, confidentialité, performances, concurrence, etc.
fonctionnelles
Précise également les contraintes d’interface homme-machine comme des règles
(optionnel)
d’ergonomie, une charte graphique, etc.
Les cas d’utilisation - Etude de cas
Etude d’un guichet automatique de banque (GAB)
• Cette étude de cas concerne un système simplifié de Guichet

Automatique de Banque (GAB), Le GAB offre les services suivants :
1.Distribution d’argent à tout Porteur de carte de crédit, via un lecteur
de cartes et un distributeur de billets.
2.Consultation de solde de compte, dépôt en numéraire et dépôt de
chèques pour les clients porteurs d’une carte de crédit de la banque
adossée au GAB.
N’oubliez pas non plus que :

3.Toutes les transactions sont sécurisées.
4.Il est parfois nécessaire de recharger le distributeur, etc.
• À partir de ces quatre phrases, nous allons

progressivement :
•Identifier les acteurs;
•Identifier les cas d’utilisation;
•Construire un diagramme de cas d’utilisation.
•Question :
•Identifier les acteurs
Étape 1 : Identification des acteurs du GAB

• Quelles sont les entités externes qui interagissent
directement avec le GAB ?
Porteur de carte
Lecteur de cartes
Distributeur de billets
Carte bancaire
Client banque
Les transactions sont sécurisées
Opérateur de maintenance
Porteur de carte (externe)

Lecteur de cartes (interne)
Distributeur de billets (interne)
Carte bancaire (externe)
Client banque (externe)
Les transactions sont sécurisées (par des externes)
Opérateur de maintenance (externe)

Les transactions sont sécurisées (par des externes)

Les transactions sont sécurisées (par qui ?)
Porteur de carte
Client banque
Opérateur de maintenance
•Question :
•Identifier les cas d’utilisation
•Question :
•Construire un diagramme de cas

d’utilisation
Diagramme de cas d’utilisation
Relations entre cas d'utilisation
• Trois types de relations standard entre cas d'utilisation

sont proposés par UML :
<<include>> : le cas d'utilisation incorpore explicitement
et de manière obligatoire un autre cas d'utilisation à
l'endroit spécifié;
<<extend>> : le cas d'utilisation incorpore implicitement
de manière facultative un autre cas d'utilisation à l'endroit
spécifié;
généralisation : les cas d'utilisation descendants héritent
des propriétés de leur parent.
• Autrement dit :
<<include>> : le cas d'utilisation A inclut obligatoirement
le cas d’utilisation B; ceci permet de factoriser des
fonctionnalités partagées.
<<extend>> : le cas d'utilisation d’utilisation A est une
extension optionnelle du cas d’utilisation B à un certain
point de son exécution.
généralisation : notion d’héritage en orienté-objet.
On peut également avoir de l’héritage entre acteurs et

entre cas d’utilisation (généralisation/spécialisation).
Revenons à notre étude de cas (GAB)
• Le Diagramme de cas d’utilisation peut présenter

l’héritage comme suit
Ancien diagramme
Nouveau diagramme
Etude d’une Station Service
• Considérons le système informatique qui gère une

station-service de distribution d’essence. On
s’intéresse à la modélisation de la prise d’essence
par un client.
Etude d’une Station Service
1. Le client se sert de l’essence de la façon suivante. Il prend un pistolet
accroché à une pompe et appuie sur la gâchette pour prendre de
l’essence. Qui est l’acteur du système ? Est-ce le client, le pistolet ou la
gâchette ?
2. Le pompiste peut se servir de l’essence pour sa voiture. Est-ce un nouvel
acteur ?
3. La station a un gérant qui utilise le système informatique pour des
opérations de gestion. Est-ce un nouvel acteur ?
4. La station-service a un petit atelier d’entretien de véhicules dont s’occupe
un mécanicien. Le gérant est remplacé par un chef d’atelier qui, en plus
d’assurer la gestion, est aussi mécanicien. Comment modéliser cela ?
Etude d’une Station Service - Correction
1. Le client est l’acteur du système. Le pistolet et la gâchette sont
des ressources utilisées par le système.
2. Si le pompiste fait uniquement les tâches d’un client, il est
inutile de créer un nouvel acteur. Il sera lui-même client.
3. Oui, le gérant est un nouvel acteur.
4. Un nouvel acteur, le chef d’atelier, est créé à la place du gérant.
Il hérite d’un autre acteur: le mécanicien.
Etude d’une Station Service - Correction
Etude d’une Agence de voyages
Choisissez et dessinez les relations entre les cas suivants :
1. Une agence de voyages organise des voyages où l’hébergement se fait en
hôtel. Le client doit disposer d’un taxi quand il arrive à la gare pour se
rendre à l’hôtel.
Etude d’une Agence de voyages
2. Certains clients demandent à l’agent de voyages d’établir une facture

détaillée. Cela donne lieu à un nouveau cas d’utilisation appelé « Etablir
une facture détaillée ». Comment mettre ce cas en relation avec les cas
existants ?
3. Le voyage se fait soit par avion, soit par train. Comment modéliser cela ?
Etude d’une Agence de voyages –
Correction
Correction
• Certains clients demandent à l’agent de voyages d’établir une facture
détaillée. Cela donne lieu à un nouveau cas d’utilisation appelé «
Etablir une facture détaillée ». Comment mettre ce cas en relation
avec les cas existants ?
Correction
Correction
• Le voyage se fait soit par avion, soit par train. Comment
modéliser cela ?
Etude d’une Agence de voyages – Correction
Etude d’un Etablissement scolaire
 Dans un établissement scolaire, on désire gérer la réservation des salles de
cours ainsi que du matériel pédagogique (ordinateur portable ou/et Vidéo
projecteur). Seuls les enseignants sont habilités à effectuer des
réservations (sous réserve de disponibilité de la salle ou du matériel).
 Le planning des salles peut quant à lui être consulté par tout le monde
(enseignants et étudiants).
 Par contre, le récapitulatif horaire par enseignant (calculé à partir du
planning des salles) ne peut être consulté que par les enseignants.
 Enfin, il existe pour chaque formation un enseignant responsable qui seul
peut éditer le récapitulatif horaire pour l’ensemble de la formation.
Etude d’un Etablissement scolaire - Correction
Logiciel dédié à l’industrie textile
• En vue de la mise en place d’un logiciel dédié à l’industrie
textile, nous étudions principalement quelques fonctionnalités
permettant de recueillir l’information sur les produits
développés dans l’entreprise. Tout le personnel de l’entreprise
peut consulter le système, soit pour vérifier qu’un produit
particulier existe, soit pour un parcours libre des informations.
Toute consultation doit être précédée par une authentification
légère dans laquelle la personne précise son nom et son service
à des fins de statistiques ultérieures.
• Les ingénieurs peuvent effectuer différentes opérations de mise

à jour pour les produits dont ils sont responsables : ajout, retrait
et modification des informations sur les produits. Ces opérations
doivent être précédées d’une authentification plus approfondie
lors de laquelle l’ingénieur précise son nom, son service et
introduit un mot de passe qui est vérifié en contactant le
système de gestion du personnel.
• Toutes les opérations (consultations et mises à jour) donnent
lieu à un enregistrement dans un journal des accès et peuvent
optionnellement s’accompagner d’une impression des
documents accédés.
• Représenter le diagramme des cas d'utilisation de ce système.
Description textuelle d’un cas d’utilisation
• À chaque cas d’utilisation doit être associée une description textuelle
des interactions entre l’acteur et le système et les actions que le
système doit réaliser en vue de produire les résultats attendus par les
acteurs.
• La description textuelle d’un cas d’utilisation est articulée

en six points :
 Objectif
 Acteurs concernés
 Pré conditions
 Post conditions
 Scénario nominal
 Scénarios alternatifs
• Objectif – Décrire succinctement le contexte et les

résultats attendus du cas d’utilisation.
• Acteurs concernés – Le ou les acteurs concernés par le cas
doivent être identifiés en précisant globalement leur rôle.
• Pré conditions – Si certaines conditions particulières sont
requises avant l’exécution du cas, elles sont à exprimer à
ce niveau.
• Post conditions – Par symétrie, si certaines conditions

particulières doivent être réunies après l’exécution du cas, elles
sont à exprimer à ce niveau. Par souci de simplification, ce
point n’est pas toujours traité.
• Scénario nominal – Il s’agit là du scénario principal qui doit se
dérouler sans incident et qui permet d’aboutir au résultat
souhaité.
• Scénarios alternatifs – Les autres scénarios, secondaires ou
correspondant à la résolution d’anomalies, sont à décrire à ce
niveau. Le lien avec le scénario principal se fait à l’aide d’une
numérotation hiérarchisée (1.1a, 1.1b...) rappelant le numéro
de l’action concernée.
• D’autres concepteurs préfèrent décomposer la fiche

descriptive du cas d’utilisation en 4 volets :
1. L’identification
2. La description des scénarios
3. La fin et les post-conditions
4. Les compléments
Nom : ……………………………………......
Acteur(s) : ……………………………………......
Description : ……………………………………......
Auteur : ……………………………………......
Date(s) : ……………………………………......
Préconditions : ……………………………………......
Démarrage : ……………………………………......
• Le scénario nominal
• Les scénarios alternatifs
• Les scénarios d’exception
• La fin du cas d’utilisation
• Les post-conditions
4. Les compléments
Les compléments peuvent porter sur des sujets variés :
• L’ergonomie
• La performance attendue
• Des contraintes (techniques ou non) à respecter
• Des problèmes non résolus (ou questions à poser au client et aux
futurs utilisateurs)
Exemple de description textuelle d’un cas
d’utilisation
• Nous allons nous intéresser à un cas d’utilisation simple (sans relation
avec d’autres cas d’utilisation), par exemple :
« Consulter catalogue produits ».
• Nous allons voir la fiche descriptive du cas d’utilisation « Consulter
catalogue produits » dont voici le diagramme correspondant.
• Voici la synthèse des 4 volets de la fiche

descriptive du cas d’utilisation
« Consulter catalogue produits ».
Cas n°1
Nom : Consulter catalogue produit (package « Gestion des achats »)
Acteur(s) : Acheteur (client ou commercial)
Description : La consultation du catalogue doit être possible pour un
client ainsi que pour les commerciaux de l’entreprise.
Auteur : Prénom & Nom de l’auteur
Date(s) : 23/12/2014 (première rédaction)
Préconditions : L’utilisateur doit être authentifié en tant que client ou
commercial (Cas d’utilisation « S’authentifier » – package «
Authentification »)
Démarrage : L’utilisateur a demandé la page
« Consultation catalogue »
Le scénario nominal :
1. Le système affiche une page contenant la liste des catégories de
produits.
2. L’utilisateur sélectionne une des catégories.
3. Le système recherche les produits qui appartiennent à cette catégorie.
4. Le système affiche une description et une photo pour chaque produit
trouvé.
5. L’utilisateur peut sélectionner un produit parmi ceux affichés.
6. Le système affiche les informations détaillées du produit choisi.
7. L’utilisateur peut ensuite quitter cette description détaillée.
8. Le système retourne à l’affichage des produits de la catégorie (retour à
l’étape 4)
Les scénarios alternatifs
2.a L’utilisateur décide de quitter la consultation de la liste des catégorie
de produits.
2.b L’utilisateur décide de quitter la consultation du catalogue.
5.a L’utilisateur décide de quitter la consultation de la catégorie de
produits choisie.
7.a L’utilisateur décide de quitter la consultation de la catégorie de
produits choisie.
Fin : Scénario nominal : aux étapes 2, 5 ou 7, sur décision de

l’utilisateur
Post-conditions : Aucun
4. Les compléments
Ergonomie
L’affichage des produits d’une catégorie devra se faire par groupe de 15 produits. Toutefois, afin d’éviter
à l’utilisateur d’avoir à demander trop de pages, il devra être possible de choisir des pages avec 30, 45
ou 60 produits.
Performance attendue
La recherche des produits, après sélection de la catégorie, doit se faire de façon à afficher la page des
produits en moins de 5 secondes.
Problèmes non résolus
Nous avons fait la description basée sur l’information que les produits appartiennent à une catégorie.
Est-ce qu’il existe des sous-catégories ?
Si tel est le cas, la description devra être revue.
Est-ce que la consultation du catalogue doit être possible uniquement par catégorie ou est-ce qu’on
doit prévoir d’autres critères de recherche de produits ?
Doit-on prévoir un affichage trié sur des critères choisis par l’utilisateur (par exemple : par tranche de
prix, par disponibilité, etc.) ?
Exemple de description textuelle d’un cas
d’utilisation complexe
• Il s’agit dans ce cas de cas d’utilisation dont le scénario renvoie vers
d’autre cas d’utilisation.
• Etudions le cas suivant : « enregistrer un achat ».
• La particularité de ce cas d’utilisation est qu’il soit lié à plusieurs
autres cas d’utilisation avec des relations « include » et « extend »
comme on a vu précédemment sur le diagramme de cas d’utilisation
correspondant :
Cas n°2
Nom : Enregistrer un achat (package « Gestion des achats »)
Acteur(s) : Acheteur (client ou commercial)
Description : L’enregistrement d’un achat doit pouvoir être utilisé en
ligne, par un client ainsi que par les commerciaux de l’entreprise.
L’enregistrement comprend les produits demandés et le règlement de
l’achat.
Auteur : Prénom & Nom de l’auteur
Date(s) : 23/12/2014 (première rédaction)
Préconditions : L’utilisateur doit être authentifié en tant que client ou
commercial (Cas d’utilisation « S’authentifier » – package «
Authentification »)
Démarrage : L’utilisateur a demandé la page
« Enregistrer des achats »
Le scénario nominal :
1. Le système vérifie le type d’utilisateur connecté (si commercial ou
client)
2. Si l’utilisateur est le commercial, le système fait appel au cas
d’utilisation interne « sélectionner un client »
3. Le système affiche des informations concernant le client
4. Le système fait appel au cas d’utilisation interne
« Constituer panier »
5. Le système fait appel au cas d’utilisation interne
« Saisir information pour livraison»
6 Le système fait appel au cas d’utilisation interne
« Enregistrer le règlement»
7. Le système enregistre définitivement l’achat
8. Le système affiche le récapitulatif de l’achat.
Les scénarios d’exception
2.a Le système n’affiche aucun utilisateur sélectionné.
Il affiche « Veuillez sélectionner le client concerné par l’achat » (retour à
l’étape 2)
6.a L’enregistrement du règlement n’a pas réussi.
Le système récapitule les informations dans un message qui est envoyé au
département commercial.
(Arrêt du cas d’utilisation)
7.a L’enregistrement définitif de l’achat n’a pas réussi.
Le système récapitule les informations dans un message qui est envoyé au
département commercial.
(Arrêt du cas d’utilisation)
Fin
• Scénario nominal : sur décision de l’utilisateur, après le point 8
(affichage du récapitulatif de l’achat)
• Scénario d’exception : après le point 6 ou 7, si l’enregistrement du
règlement ou de l’achat définitif ne réussit pas.
Post-conditions
• Scénario nominal : l’achat et son règlement ont été enregistrés en
base de données.
• Scénario d’exception : l’achat a été récapitulé dans un message et a
été envoyé au service commercial de l’entreprise.
4. Les compléments
Ergonomie
L’enregistrement d’un achat doit pouvoir se faire avec un
maximum de 3 pages. Les éventuels messages aux utilisateurs
doivent être fournis à l’aide de fenêtres pop-up.
Problèmes non résolus
Nous avons décrit le cas où un utilisateur est soit un
commercial, soit un client connu (indiqué par la précondition).
Est-ce bien ainsi que cela devra fonctionner ? Serait-il
envisageable de dérouler l’ensemble des actions liées à la
constitution du panier avant de s’enregistrer comme client ?
Les diagrammes structurels
(ou statiques)
• DIAGRAMME DE CLASSE
ET
DIAGRAMME D’OBJET
DIAGRAMME DE CLASSE ET DIAGRAMME
D’OBJET
Objet :
Un objet est un concept, une abstraction ou
une chose qui a un sens dans le contexte du
système à modéliser.
• Chaque objet a une identité et peut être distingué
des autres sans considérer a priori les valeurs de
ses propriétés.
D’OBJET
Objet :
Exemples d’objets physiques (une chaise, une
voiture, une personne, un vélo) et d’objets de
gestion (la Commande n° 12,
le Client Durand).
D’OBJET
Objet :
D’OBJET
Objet :
• Un objet est caractérisé par les valeurs de ses
propriétés qui lui confèrent des états significatifs
suivant les instants considérés.
D’OBJET
Classe :
Une classe décrit un groupe d’objets ayant les
mêmes propriétés (attributs), un même
comportement (opérations), et une sémantique
commune (domaine de définition).
D’OBJET
Classe :
• Un objet est une instance d’une classe.
• La classe représente l’abstraction de ses objets.
• Au niveau de l’implémentation, c’est-à-dire au cours de
l’exécution d’un programme, à l’identificateur d’un objet
correspond une adresse mémoire.
D’OBJET
Classe : Formalisme général et exemple
• Une classe se représente à l’aide d’un rectangle
comportant plusieurs compartiments.
• Les trois compartiments de base sont :
• la désignation de la classe,
• la description des attributs,
• la description des opérations.
D’OBJET
• Deux autres compartiments peuvent être aussi indiqués :
• la description des responsabilités de la classe,
• la description des exceptions traitées par la classe.
D’OBJET
D’OBJET
Attribut :
• Un attribut est une propriété élémentaire d’une classe.
Pour chaque objet d’une classe, l’attribut prend une valeur
(sauf cas d’attributs multivalués).
D’OBJET
Attribut : Formalisme et exemple
D’OBJET
Attribut : Caractéristiques
• La description complète des attributs d’une classe
comporte un certain nombre de caractéristiques
qui doivent respecter le formalisme suivant :
Visibilité/Nom attribut : type [= valeur initiale
{propriétés}]
D’OBJET
– Visibilité : ….
– Nom d’attribut : nom unique dans sa classe.
– Type : type primitif (entier, chaîne de caractères…) dépendant
des types disponibles dans le langage d’implémentation ou type
classe matérialisant un lien avec une autre classe.
– Valeur initiale : valeur facultative donnée à l’initialisation d’un
objet de la classe.
– {propriétés} : valeurs marquées facultatives (ex. : « interdit »
pour mise à jour interdite).
D’OBJET
• Un attribut peut avoir des valeurs multiples. Dans ce cas, cette
caractéristique est indiquée après le nom de l’attribut (ex. : prénom
[3] pour une personne qui peut avoir trois prénoms).
• Un attribut dont la valeur peut être calculée à partir d’autres
attributs de la classe est un attribut dérivé qui se note « /nom de
l’attribut dérivé »
D’OBJET
Opération :
• Une opération est une fonction applicable aux objets
d’une classe. Une opération permet de décrire le
comportement d’un objet.
• Une méthode est l’implémentation d’une opération.
D’OBJET
Opération : Formalisme et exemple
D’OBJET
Opération : Caractéristiques
• La description complète des opérations d’une
classe comporte un certain nombre de
caractéristiques qui doivent respecter le
formalisme suivant :
Visibilité Nom d’opération (paramètres) [:[type
résultat] {propriétés}]
D’OBJET
Opération : Caractéristiques
– Visibilité : ….
– Nom d’opération : utiliser un verbe représentant l’action à réaliser.
– Paramètres : liste de paramètres (chaque paramètre peut être décrit, en
plus de son nom, par son type et sa valeur par défaut). L’absence de
paramètre est indiquée par ( ).
– Type résultat : type de(s) valeur(s) retournée(s) dépendant des types
disponibles dans le langage d’implémentation. Par défaut, une opération
ne retourne pas de valeur, ceci est indiqué par exemple par le mot réservé
« void » dans le langage C++ ou Java.
– {propriétés} : valeurs facultatives applicables (ex. : {query} pour un
comportement sans influence sur l’état du système)
D’OBJET
Exemples de classes et représentation d’objets
(1) Le nom d’un objet peut être désigné sous trois
formes :
nom de l’objet, désignation directe et
explicite d’un objet ;
nom de l’objet : nom de la classe, désignation
incluant le nom de la classe ;
: nom de la classe, désignation anonyme d’un
objet d’une classe donnée.
Exemples d’objets
D’OBJET
Classe : Visibilité des attributs et opérations
• Chaque attribut ou opération d’une classe peut être de
type public, protégé, privé ou paquetage.
• Les symboles + (public), # (protégé), - (privé) et ~
(paquetage) sont indiqués devant chaque attribut ou
opération pour signifier le type de visibilité autorisée pour
les autres classes.
D’OBJET
• Les droits associés à chaque niveau de confidentialité sont :
• Public (+) – Attribut ou opération visible par tous.
• Protégé (#) – Attribut ou opération visible seulement à
l’intérieur de la classe et pour toutes les sous-classes de la classe.
• Privé (-) – Attribut ou opération seulement visible à l’intérieur
de la classe.
• Paquetage (~) – Attribut ou opération ou classe seulement
visible à l’intérieur du paquetage où se trouve la classe.
D’OBJET
Dans cet exemple, tous les

attributs sont déclarés de type
privé, les opérations
« démarrer » et « freiner » sont de
type public, l’opération
« rouler » est de type
privé et l’opération « arrêter » est
de type protégé.
D’OBJET
Attribut ou opération de niveau classe
• Un attribut ou une opération peut être défini non pas au
niveau des instances d’une classe, mais au niveau de la
classe. Il s’agit soit d’un attribut qui est une constante pour
toutes les instances d’une classe soit d’une opération
d’une classe abstraite ou soit par exemple d’une opération
« créer » qui peut être définie au niveau de la classe et
applicable à la classe elle-même.
Attribut ou opération de niveau classe :
Formalisme et exemple
C’est le soulignement de l’attribut

ou de l’opération qui caractérise
cette propriété.
Dans cet exemple, l’attribut
« ristourne » est de type classe et
l’opération
« créer » est une opération
exécutable au niveau de la classe.
D’OBJET
Association, multiplicité, navigabilité et contraintes
:
Lien et association
• Un lien est une connexion physique ou
conceptuelle entre instances de classes donc entre
objets. Une association décrit un groupe de liens
ayant une même structure et une même
sémantique. Un lien est une instance d’une
association. Chaque association peut être
identifiée par son nom.
• Une association entre classes représente les liens
qui existent entre les instances de ces classes.
Lien et association : Rôle d’association
• Le rôle tenu par une classe vis-à-vis d’une
association peut être précisé sur l’association. Par
exemple :
Multiplicité
• La multiplicité indique un domaine de valeurs pour
préciser le nombre d’instances d’une classe vis-à-
vis d’une autre classe pour une association donnée.
La multiplicité peut aussi être utilisée pour d’autres
usages comme par exemple un attribut multi-
valué.
• Le domaine de valeurs est décrit selon plusieurs
formes :
Multiplicité
• Intervalle fermé – Exemple : 3 ..15
• Valeurs exactes – Exemple : 3, 5, 8
• Valeur indéterminée notée * – Exemple : 1..*
• Dans le cas où l’on utilise seulement *, cela traduit
une multiplicité 0..*
• Dans le cas de multiplicité d’associations, il faut
indiquer les valeurs minimale et maximale
d’instances d’une classe vis-à-vis d’une instance
d’une autre classe.
Multiplicité : Formalisme et exemple
Navigabilité
• La navigabilité indique si l’association fonctionne
de manière unidirectionnelle ou bidirectionnelle,
elle est matérialisée par une ou deux extrémités
fléchées. La non-navigabilité se représente par un «
X»
• Les situations possibles de navigabilité sont
représentées comme suit :
Navigabilité
Navigabilité : Exemple
Contraintes
• D’autres propriétés particulières (contraintes) sont
proposées dans UML pour préciser la sémantique
d’une association.
Contraintes
Ordre de tri
• Pour une association de multiplicité supérieure à 1,
les liens peuvent être :
• non ordonnés (valeur par défaut),
• ordonnés ou triés lorsque l’on est au niveau de
l’implémentation (tri sur une valeur interne).
Contraintes
Propriétés de mise à jour de liens
• Il est possible d’indiquer des contraintes
particulières relatives aux conditions de mise à jour
des liens.
• {interdit} : interdit l’ajout, la suppression ou la mise
à jour des liens.
• {ajout seul} : n’autorise que l’ajout de liens.
Association de dimension supérieure à 2 et
classe-association
• Une association de dimension supérieure à 2 se
représente en utilisant un losange permettant de
relier toutes les classes concernées.
• Une classe-association permet de décrire soit des
attributs soit des opérations propres à l’association.
Cette classe-association est elle-même reliée par
un trait en pointillé au losange de connexion. Une
classe-association peut être reliée à d’autres
classes d’un diagramme de classes.
Association de dimension supérieure à 2 et
classe-association
Exemple
• Exemple d’une association de dimension 3
comprenant une classe-association
« Affectation ». La classe-association Affectation
permet de décrire les attributs propres à
l’association de dimension 3 représentée.
D’OBJET
Agrégation et composition entre classes
Agrégation
• L’agrégation est une association qui permet de
représenter un lien de type
« ensemble » comprenant des « éléments ». Il s’agit
d’une relation entre une classe représentant le
niveau « ensemble » et 1 à n classes de niveau «
éléments ».
Agrégation : Formalisme
Agrégation : Exemple
Dans cet exemple, nous avons modélisé le fait qu’un ordinateur

comprend une UC, un clavier et un écran.
Composition
• La composition est une relation d’agrégation dans
laquelle il existe une contrainte de durée de vie
entre la classe « composant » et la classe « composé
». Autrement dit la suppression de la classe
« composé » implique la suppression de la ou des
classes « composant ».
Composition : Formalisme
Composition : Exemple
Composition : Autre formalisme peut être
utilisé
D’OBJET
Association qualifiée, dépendance et classe
d’interface
Qualification
• La qualification d’une relation entre deux classes
permet de préciser la sémantique de l’association et
de qualifier de manière restrictive les liens entre les
instances.
• Seules les instances possédant l’attribut indiqué
dans la qualification sont concernées par
l’association.
Qualification : Formalisme et exemple
Qualification : Formalisme et exemple
Dépendance
• La dépendance entre deux classes permet de
représenter l’existence d’un lien sémantique.
• Une classe B est en dépendance de la classe A si des
éléments de la classe A sont nécessaires pour
construire la classe B.
Dépendance
• Une dépendance est une relation unidirectionnelle
exprimant une dépendance sémantique entre des
éléments du modèle. Elle est représentée par un
trait discontinu orienté. Elle indique que la
modification de la cible peut impliquer une
modification de la source. La dépendance est
souvent stéréotypée pour mieux expliciter le lien
sémantique entre les éléments du modèle
Dépendance
Interface
• Une classe d’interface permet de décrire la vue externe
d’une classe. La classe d’interface, identifiée par un
nom, comporte la liste des opérations accessibles par
les autres classes. Le compartiment des attributs ne fait
pas partie de la description d’une interface.
• L’interface peut être aussi matérialisée plus
globalement par un petit cercle associé à la classe
source.
• La classe utilisatrice de l’interface est reliée au symbole
de l’interface par une flèche en pointillé. La classe
d’interface est une spécification et non une classe
réelle.
D’OBJET
Généralisation et spécialisation
Généralisation et spécialisation
D’OBJET
Classe abstraite
• Une classe abstraite est une classe qui n’a pas
d’instance directe mais dont les classes
descendantes ont des instances. Dans une relation
d’héritage, la super-classe est par définition une
classe abstraite. C’est le cas de la classe Employé
dans l’exemple suivant :
D’OBJET
L’héritage multiple
• Dans certains cas, il est nécessaire de faire hériter
une même classe de deux classes
« parentes » distinctes. Ce cas correspond à un
héritage multiple.
Exercice
• Il est demandé de représenter le diagramme de classe d’une
gestion technique de documents. Chaque document est
composé d’un ou plusieurs feuillets. Un feuillet comporte du
texte et des objets géométriques qui constituent deux types
d’objets graphiques supportant des opérations de type :
sélectionner, copier, couper, coller et déplacer.
• Nous considérons les quatre objets géométriques suivants :
cercle, ellipse, carré, rectangle. Il est demandé d’utiliser les
propriétés de la généralisation et la spécialisation afin de
représenter au mieux ces objets géométriques.
DIAGRAMME D’ÉTAT-TRANSITION
• L’état d’un objet est défini, à un instant donné, par

l’ensemble des valeurs de ses propriétés.
• Le passage d’un état à un autre état s’appelle
transition. Un événement est un fait survenu qui
déclenche une transition.
• Une condition, peut être associée à une transition.
• La figure suivante donne un premier exemple d’état-transition.
• Dans cet exemple, pour un employé donné d’une entreprise, nous
pouvons considérer les deux états significatifs suivants :
état recruté, état en activité.
Action et activité :
• Une action est une opération instantanée qui ne peut ê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.
Exemple :
Représentation du diagramme d’état-
transition d’un objet
• L’enchaînement de tous les états caractéristiques d’un objet constitue
le diagramme d’état.
• 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.
Exemple :
• L’exemple suivant donne un premier exemple fictif d’une gestion

commerciale qui montre le diagramme d’état-transition de l’objet
client.
Exercice :
• Soit à représenter le diagramme d’état-transition d’un objet
personnel en suivant les événements de gestion depuis le
recrutement jusqu’à la mise en retraite.
• Après le recrutement, une personne est considérée en activité dès sa
prise de fonction dans l’entreprise. Au cours de sa carrière, nous
retiendrons seulement les événements : congé de maladie et prise de
congé annuel. En fin de carrière, nous retiendrons deux situations : la
démission et la retraite.
Corrigé :
Ce corrigé ne représente qu’une solution parmi d’autres variantes
possibles suivant la lecture faite de l’énoncé. Ici, nous avons retenu les
états caractéristiques : recruté, activité, en congé, en arrêt, parti et
retraite.
DIAGRAMME D’ACTIVITÉ
• Le diagramme d’activité présente un certain nombre

de points communs avec le diagramme d’état-
transition. Cependant le comportement visé ici
s’applique aux flots de contrôle et aux flots de
données propres à un ensemble d’activités et non à
une seule classe.
Action :
• Une action correspond à un traitement qui modifie
l’état du système.
• Une action est représentée par un rectangle dont les
coins sont arrondis comme pour les états du
diagramme d’état-transition
Action :
Transition et flot de contrôle :

• Dès qu’une action est achevée, une transition
automatique est déclenchée vers l’action suivante. Il
n’y a donc pas d’événement associé à la transition.
• L’enchaînement des actions constitue le flot de
contrôle.
Transition et flot de contrôle :
Activité :
• Une activité représente le comportement d’une partie
du système en termes d’actions et de transitions. Une
activité est composée de trois types de nœuds :
• nœud d’exécution (action, transition),
• nœud de contrôle (nœud initial, nœud final, flux de
sortie, nœud de bifurcation, nœud de jonction, nœud de
fusion-test, nœud de test-décision, pin d’entrée et de
sortie),
• nœud d’objet.
Activité :
Symbole de représentation d’un état

http://www.docsflood.com composite 175
Nœud de bifurcation (fourche) :

• Un nœud de bifurcation (fourche) permet à partir d’un flot
unique entrant de créer plusieurs flots concurrents en sortie
de la barre de synchronisation.
Nœud de jonction (synchronisation) :

• Un nœud de jonction (synchronisation) permet, à partir de
plusieurs flots concurrents en entrée de la synchronisation,
de produire un flot unique sortant. Le nœud de jonction est
le symétrique du nœud de bifurcation.
Nœud de test-décision :
• Un nœud de test-décision permet de faire un choix
entre plusieurs flots sortants en fonction des
conditions de garde de chaque flot. Un nœud de
test-décision n’a qu’un seul flot en entrée. On peut
aussi utiliser seulement deux flots de sortie : le
premier correspondant à la condition vérifiée et
l’autre traitant le cas sinon.
Nœud de fusion-test :
• Un nœud de fusion-test permet d’avoir plusieurs
flots entrants possibles et un seul flot sortant. Le flot
sortant est donc exécuté dès qu’un des flots entrants
est activé.
Flot de données et nœud d’objet :

• Un nœud d’objet permet de représenter le flot de
données véhiculé entre les actions. Les objets
peuvent se représenter de deux manières différentes
: soit en utilisant le pin d’objet soit en représentant
explicitement un objet.
Partition :
• UML permet aussi d’organiser la présentation du

diagramme d’activité en couloir d’activités. Chaque
couloir correspond à un domaine de responsabilité
d’un certain nombre d’actions.
• Les flots d’objets sont aussi représentés dans le
diagramme. L’ordre relatif des couloirs de
responsabilité n’est pas significatif.
Représentation du diagramme d’activité

7478 - Cour Uml (Tutoriel) PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

7478 - Cour Uml (Tutoriel) PDF

Transféré par

Droits d'auteur :

Formats disponibles

Méthode de conception orientée objet

• La démarche ne constitue plus à réécrire un modèle

plusieurs méthodes de modélisation

 Entre 89 et 94 : le nombre de méthodes orientées objet

(utilisateur humain, dispositif matériel ou autre système)

oLes utilisateurs humains directs : faites donc en sorte

• La représentation graphique standard de l’acteur en UML est

• Autres représentations sont possibles : (2)

• Une bonne recommandation consiste à faire prévaloir

doit décrire exhaustivement les exigences fonctionnelles

• Pour chaque acteur, il convient de :

Nommer les cas d’utilisation par un verbe à l’infinitif

Pour détailler la dynamique du cas d’utilisation, la procédure la

« ensemble de scénarios d’utilisation d’un système

Ajoute, si c’est pertinent, les informations suivantes : fréquence, volumétrie,

• Cette étude de cas concerne un système simplifié de Guichet

N’oubliez pas non plus que :

• À partir de ces quatre phrases, nous allons

•Identifier les acteurs

Étape 1 : Identification des acteurs du GAB

Porteur de carte (externe)

Porteur de carte (externe)

Porteur de carte (externe)

•Identifier les cas d’utilisation

•Construire un diagramme de cas

• Trois types de relations standard entre cas d'utilisation

On peut également avoir de l’héritage entre acteurs et

• Le Diagramme de cas d’utilisation peut présenter

• Considérons le système informatique qui gère une

2. Certains clients demandent à l’agent de voyages d’établir une facture

• Les ingénieurs peuvent effectuer différentes opérations de mise

• Représenter le diagramme des cas d'utilisation de ce système.

• La description textuelle d’un cas d’utilisation est articulée

• Objectif – Décrire succinctement le contexte et les

• Post conditions – Par symétrie, si certaines conditions

• D’autres concepteurs préfèrent décomposer la fiche

• Les scénarios alternatifs

• Les scénarios d’exception

• Voici la synthèse des 4 volets de la fiche

Fin : Scénario nominal : aux étapes 2, 5 ou 7, sur décision de

Exemples de classes et représentation d’objets

Dans cet exemple, tous les

C’est le soulignement de l’attribut

Dans cet exemple, nous avons modélisé le fait qu’un ordinateur

• L’état d’un objet est défini, à un instant donné, par

• L’exemple suivant donne un premier exemple fictif d’une gestion

• Le diagramme d’activité présente un certain nombre

Transition et flot de contrôle :

Transition et flot de contrôle :

Symbole de représentation d’un état

Nœud de bifurcation (fourche) :

Nœud de jonction (synchronisation) :

Flot de données et nœud d’objet :

• UML permet aussi d’organiser la présentation du

Représentation du diagramme d’activité

Vous aimerez peut-être aussi