Cours UML PDF

Ecole Nationale Supérieure d‘Ingénieurs de Tunis
Université de Tunis
Conception Orientée
Objets (COO)
2ème année Génie Informatique
Responsable du cours:
Sonda Chtourou Sellami
Sonda Chtourou Sellami COO 2019 - 2020
Etapes du cycle de vie d’un logiciel
Sonda Chtourou Sellami COO 2019 - 2020 2

Exemples de cycle de vie d’un logiciel
Le cycle de vie en < V > Le cycle de vie en spirale

Conception
 La phase de conception permet de décrire le fonctionnement futur du
système de manière non ambiguë en utilisant un langage de modélisation:
 Identification de la structure globale du système
 Les principaux composants
 Leurs relations
 La base de données
 ….
Une bonne conception participe largement à la production d'un logiciel qui

répond aux facteurs de qualité.

Modélisation

Modélisation
 Un modèle est une abstraction de la réalité.
 Description de tout ou partie d’un système.
 Un modèle est une vue subjective mais pertinente de la réalité.

Modélisation
 Pourquoi la modélisation?
 Aider à visualiser le système
 Spécifier la structure et le comportement
 Servir de plan pour la construction effective
 Permettre de documenter les choix
Abstraction et compréhension:
 niveau communication avec le client
 niveau mise en place, évolution et prise en main de l’application
Maîtriser la complexité et d'assurer sa cohérence
L’énergie déployée pour modéliser révèle les difficultés
Les erreurs sur les modèles coûtent bien moins cher

Plan général
1 Introduction aux méthodes de conception
 Méthodes de conception
 UML
 Concepts de l'objet
2 Modélisation Statique
 Diagrammes de cas d'utilisation
 Diagrammes de classes
 Diagrammes d'objets
3 Modélisation Dynamique
 Diagrammes de séquences

Chapitre 1: Introduction aux
méthodes de conception

Méthodes de conception
 Définitions :
 Une méthode définit des règles de mise en œuvre qui décrivent
l’enchaînement des actions, l’ordonnancement des tâches et la répartition des
responsabilités.
 Une méthode de conception de logiciel décrit comment modéliser le
système de manière qui facilitent l’implémentation et l’évolution du logiciel.
 On distingue principalement de trois de méthodes de conception:

 Méthodes fonctionnelles (Année 70)
 Méthodes systémiques (Année 80)
 Méthodes orientées objets (Année 90)

Méthodes fonctionnelles
 Les méthodes fonctionnelles (ou cartésiennes) consistent à décomposer
hiérarchiquement une application en un ensemble de sous applications.
 Ces méthodes utilisent les raffinements successifs pour produire des
spécifications dont l’essentiel est sous forme de notation graphique en diagramme
de flots de données.
 Exemples: Data-flow, SASD(Structured Analysis and Structured Design)…
Représentation graphique d'une approche fonctionnelle

Méthodes fonctionnelles
 Les méthodes fonctionnelles (ou cartésiennes) consistent à décomposer
hiérarchiquement une application en un ensemble de sous applications.
 Ces méthodes utilisent les raffinements successifs pour produire des
spécifications dont l’essentiel est sous forme de notation graphique en diagramme
de flots de données.
 Exemples: Data-flow, SASD(Structured Analysis and Structured Design)…
 Points forts:
 Simplicité du processus de conception
 Capacité à répondre rapidement aux besoins des utilisateurs
 Points faibles:
 Redondance (éventuelle) des données
…

Méthodes systémiques
 Les méthodes systémiques sont influencés par les systèmes de gestion de
bases de données en proposant une double démarche de modélisation:
 La modélisation des données
 La modélisation des traitements
 Exemples: Merise, Axial,...
 Points forts
 Approche globale prenant en compte la modélisation des données et des
traitements.
 Bonne adaptation à la modélisation des données et à la conception des BDs
 Points faibles:
 Double démarche de conception: données et traitements
 Séparation entre les modèles des données et des traitements
…

Méthodes fonctionnelles et systémiques
 Les méthodes fonctionnelles et systémiques sont de type descendant (Top-
Down).
 Inconvénients:
 Réutilisabilité: Modules non généraux mais adaptés aux sous problèmes pour
lesquels ils ont été conçus.
 Extensibilité: L’architecture du logiciel est fondée sur les traitements qui sont
moins stables que les données; par conséquent cette approche est inadaptée à
la conception de gros logiciel.
Comment structurer un système sans centrer la conception uniquement sur

les données ou uniquement sur les traitements (mais sur les deux) ?
Prise de conscience de l'importance d'une méthode spécifiquement objet.

Méthodes orientées objets
 Dans une Conception Orientée Objet (COO), le logiciel est considéré comme
une collection d’objets.
 Contrairement aux méthodes fonctionnelles et systémiques, les méthodes
orientées objets sont ascendantes.
 Avantages:
 Reflète plus finement les objets du monde réel
 Faciliter la modélisation.
 Réutilisation des composantes
 Extensibilité: architecture logicielle fondée sur les objets du système, plutôt
que sur la fonction qu'il est censé réaliser
Faciliter la modification et les changements / approche est adaptée à la
conception de gros logiciel.
Méthodes orientées objets - Historique
 Apparition de plus de 50 méthodes (1990-1995): Booch, Classe-Relation,
Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE...) !
 Chacune de ces méthodes fournie une notation graphique et des règles pour
élaborer les modèles.
Aucun méthode ne s'est réellement imposée.

Toutes les méthodes avaient pourtant d’énormes points communs (objets,
méthode, paramètres, …)
Sans arriver à remplir les besoins et à modéliser correctement les divers
domaines d’application.

Méthodes orientées objets - Historique
 L’unification et la normalisation des méthodes (1995-1997)
Recherche d’un langage de modélisation commun et unique.
 Consensus sur 3 méthodes pour créer un langage de modélisation unifié:

 OMT de James Rumbaugh: représentation graphique des aspects statiques,
dynamiques et fonctionnels d’un système
 OOD de Grady Booch: Introduit le concept de package.
 OOSE de Ivar Jacobson: méthodologie qui repose sur l'analyse des besoins
des utilisateurs. Elle introduit notion de cas d’utilisation (use cases).
UML: Unified Modeling Language (Langage de Modélisation Unifié)

UML - Historique
 UML a pris le meilleur de chacune des méthode:
 OMT: expressive pour l’analyse et la conception de SI à base de données
 OOD: expressive durant les phases de design et d’implantation des projets
 OOSE: expressive pour l’analyse des besoins grâce aux cas d’utilisation
 De version en version, UML évolue, gagne en maturité et précision, tout en

restant stable.

UML - Historique
L'OMG est un consortium à but non lucratif,

créé en 1989 à l'initiative de grandes sociétés
(HP, Sun...).
Son rôle est de promouvoir des standards qui
garantissent l'interopérabilité entre
applications orientées objet.

Unified Modeling Language (UML)
 UML signifie Unified Modelling Language
 UML est un langage unifié pour la modélisation objet.
 UML est standard pour spécifier, visualiser, concevoir et documenter tous les
aspects d'un système d'information:
Facilite la comparaison et l'évaluation de solutions.
 UML permet d'exprimer et d'élaborer des modèles objet, indépendamment de

tout langage de programmation.

Points forts d’UML
 UML est un langage formel et normalisé.
 UML est ouvert (il est indépendant du domaine d'application et des langages
d'implémentation).
 UML est soutenu par Microsoft, IBM, Oracle, HP, …
 Les outils qui supportent UML se multiplient (GDPro, ObjectTeam, Objecteering,
OpenTool, Rational Rose, Rhapsody, STP, Visio, Visual Modeler, WithClass...).
 UML est employé dans l’ensemble des secteurs du développement
informatique:
 Systèmes d’information
 Télécommunication, défense
 Transport, aéronautique, aérospatial
 Domaines scientifique

Points faibles d’UML
 La mise en pratique d'UML nécessite un apprentissage
 UML est un langage qui permet de représenter des modèles, mais il ne définit
pas le processus d'élaboration des modèles !
 Si l'on parle de méthode objet pour UML, c'est par abus de langage !
Le processus est une clé de la réussite d'un projet.
 Les auteurs d'UML préconisent d'utiliser une démarche:

 Itérative et incrémentale,
 Guidée par les besoins des utilisateurs du système,
 Centrée sur l'architecture logicielle

Modéliser avec UML
 Un modèle influence énormément la façon d’aborder le problème et la solution.
 Est-ce qu’un seul modèle est suffisant?

Modéliser avec UML
 Un modèle influence énormément la façon d’aborder le problème et la solution
 Chaque modèle peut être exprimer à différents niveaux de précision

 Modèles permettent de choisir le niveau de détail en fonction de qui regarde et
pourquoi il le regarde
 Créer un ou plusieurs modèles différents mais avec un point commun pour

assurer la cohérence entre les modèles.
Un seul modèle n’est jamais suffisant!!!

Les diagrammes d’UML
 Les diagrammes UML servent à visualiser un système sous différents angles:
 L’ensemble des diagrammes réunis permet d’obtenir une vue globale du
système à concevoir
 Chaque diagramme va permettre de modéliser ou spécifier une vue
(spécificité) du système à concevoir

 Diagramme des cas d’utilisation: Représente des fonctions du système de
point de vue de l’utilisateur (Besoins de l’utilisateur).
 Diagramme de classes: Représente la structure statique en termes
de classes et de relations.
 Diagramme d’objets: Représente les objets et leurs relations (Instances de
classes).
 Diagramme des composants: Représente les composants et leurs
dépendances dans l’environnement de réalisation.
 Diagramme de déploiement: Représente le déploiement des composants sur
les dispositifs matériels.

 Diagramme de séquence: Représentation temporelle des objets et de leurs
interactions.
 Diagramme de collaboration: Représentation spatiale des objets des liens et
des interactions.
 Diagramme états-transitions: Représente le comportement d'une classe
d'objet en termes d'états.
 Diagramme d’activités: Représente le comportement des opérations en termes
d’actions.


Qu’est ce qu’un Objet?
 Définitions:
 Entité cohérente rassemblant des données et du code travaillant sur ces
données
 L’objet informatique est une projection de l’objet du monde réel
 Caractérisé par :
 son état: comment réagit l’objet quand on applique ces méthodes?
Attributs (Champs)
 son comportement: que peut-on faire avec cet objet?
 Méthodes
 son identité: comment distinguer les objets qui ont le même état et le même
comportement?
 Identifiant

Etat d’un objet
 Il regroupe les valeurs instantanées de tous les attributs (propriétés ou
informations qualifiant l’objet)
 L’état d’un objet peut changer dans le temps

Comportement d’un objet
 Le comportement détermine comment l’objet agit ou réagit
 L’état et le comportement sont liés : le comportement à un instant donné dépend
de l’état courant et l’état peut être modifié par le comportement.

Identité d’un objet
 L’identité caractérise l’existence propre d’un objet et permet de le distinguer
des autres.

Concepts fondamentaux de la COO
 Abstraction:
 Caractéristiques qui différencie une entité (objet) des autres
 Classe:
 Une abstraction d’un ensemble d’objets qui possèdent une structure identique
(liste de propriétés ou attributs) et un même comportement (liste de méthodes)

 Encapsulation:
 Consiste à cacher l’implémentation – Uniquement les signatures des méthodes
sont visibles de l’extérieur

 Héritage:
 Un objet spécialisé bénéficie ou hérite des caractéristiques de l’objet le plus
général, auquel il rajoute ses éléments propres
Création de nouvelles classes basées sur des classes existantes
Transmission des propriétés (attributs et méthodes) de la classe mère vers la
classe fille.

 Polymorphisme :
 Poly : plusieurs
 Morphisme : Forme
 Capacité d’une classe à redéfinir une méthode héritée à partir d’une classe
mère.
 Polymorphisme d’opération: la possibilité de déclencher des opérations

différentes en réponse à un même message.
 Modularité:
 Casser un système en sous modules

Chapitre 2: Diagrammes de
cas d'utilisation (DCU)

Problématique
 La détermination et la compréhension des besoins sont souvent difficiles car les
intervenants sont noyés sous de grandes quantités d’informations:
 Les besoins souvent exprimés dans un cahier des charges de manière:

 non structurée,
 longues paragraphes,
 risque de contradictions …
 Lorsque les besoins évoluent (ce qui est toujours le cas), il devient très difficile
d’apprécier l’impact et le coût d’une modification.

Objectifs du diagramme de cas d'utilisation
 Les diagrammes de cas d'utilisation (DCU) permettent d'organiser les
besoins, et de recenser les grandes fonctionnalités d'un système.
Moyen simple pour modéliser comment les utilisateurs veulent interagir avec
le système.
 DCU se base sur le cahier des charges:

Objectifs du diagramme de cas d'utilisation
 DCU décrit le système du point de vue de l’utilisateur.
 DCU décrit l’interaction entre l’utilisateur et le système présenté sous forme
d’un ensemble de fonctionnalités.
 DCU identifie et représente:

 Les cas d’utilisation: les fonctionnalités d’un système
 Les acteurs: les utilisateurs de système
 Les relations entre les acteurs et les cas d’utilisation

Exemple
 DCU modélisant une borne d’accès à une banque
Relation
Acteur
Cas
d’utilisation

Exemple
 DCU modélisant un système de vente en ligne

Importance du diagramme de cas d'utilisation
 Pourquoi les DCU sont nécessaire ?
 Permettent aux utilisateurs de structurer et d’articuler leurs désirs.
 Obligent les utilisateurs à définir comment ils voudrait interagir avec le système
 Favorisent la reformulation du cahier des charges afin de refléter réellement les
besoins.
 Permettent de définir les limites du système et les relations entre le système et
son environnement.

Les acteurs - Définition
 Un acteur définit un rôle qu’une entité extérieure assume lors de son interaction
avec le système.
 Un acteur est un utilisateur du système qui peut être un humain, logiciel, ….
 Ne pas confondre acteur et personne utilisant le système :

 Une même personne peut jouer plusieurs rôles (vendeur, client)
 Plusieurs personne peuvent jouer un même rôle (tous les clients)
 Un acteur n’est pas forcément une personne physique.

Les acteurs - Notation
 Acteur humain: (individu ou groupe d’individus) est représenté ainsi:
Nom de l’acteur
 Acteur système: (matériel ou logiciel ...) est généralement représenté ainsi:
« acteur »
Nom de l’acteur

Les acteurs - Types
 Types d’acteurs :
 Acteurs principaux: cette catégorie regroupe les personnes qui utilisent les
fonctions principales du système. Ils représentent les utilisateurs du système.
 Acteurs secondaires: cette catégorie regroupe les personnes qui
administrent ou font de la maintenance. Le plus souvent, les acteurs secondaires
sont d'autres systèmes informatiques avec lesquels le système développé est
interconnecté.
Remarque: un même acteur peut être principal pour un cas d’utilisation et

secondaire pour un autre cas.
Relation: acteurs
 On peut définir une relation de généralisation entre les acteurs (notion
d’héritage).

Exercice 1
 Soit le DCU suivant:
Créer un compte
Guichetier Fermer un compte
Déposer de
l’argent sur un
compte
Guichetier Annuler un
Chef compte
 Que remarquez vous? On remarque que ‘Guichetier Chef’ est un ‘Guichetier’

spécialisé qui peut faire tout ce que peut faire un Guichetier et, en plus, il peut
annuler un compte.
 Corrigez le DCU
Exercice 1
 Correction:
Créer un compte
Guichetier Fermer un compte
Déposer de
l’argent sur un
compte
Guichetier Annuler un
Chef compte

Exercice 2
 Enoncé: Gestion des réservations des salles de cours
 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 (réservations,
planning …).
 Questions:
 Q1: Identifiez les acteurs et les relations entre eux.
 Q2: Définissez le DCU correspondant.

Exercice 2
 Solution Q1:
 On identifie 3 acteurs:
Utilisateur Enseignant Responsable

de salle de salle
Utilisateur de salle
 Existe-t-il une relation entre les acteurs ? Oui
Enseignant
Responsable de salle

Les cas d’utilisation
 Le cas d’utilisation est un classificateur qui modélise une fonctionnalité d'un
système.
 Fonctionnalité visible de l’extérieur du système dont on désire décrire le
fonctionnement
 L'instanciation d'un cas d'utilisation se traduit par l'échange de messages entre
le système et ses acteurs.
 Notation:
Nom du cas
d’utilsation
 Recommandation: Nommer les cas d’utilisation par un verbe à l’infinitif suivi

d’un complément.
Les cas d’utilisation
 Remarques de mise en forme:
 L'ensemble des cas d’utilisation décrit les objectifs du système.
 Les cas d’utilisations peuvent être contenus dans un rectangle qui représente
les limites du système. Les acteurs sont alors forcement à l’extérieur du rectangle
puisqu’ils ne font pas partie du système.
 Les cas d’utilisation peuvent être organisés en paquetages (packages).
 Il est possible de préciser les comportements d’un cas d’utilisation via du texte,
des diagrammes d’activités, des machines à état, des méthodes….

Recenser les cas d'utilisation
 Il n'y a pas une manière totalement objective pour repérer les cas d'utilisation.
 Il faut se placer du point de vue de chaque acteur et déterminer comment il se
sert du système, dans quels cas il l'utilise, et à quelles fonctionnalités il doit avoir
accès.
 Il faut éviter les redondances et limiter le nombre de cas d’utilisation.
 Il ne faut pas faire apparaître les détails des cas d'utilisation, mais il faut rester
au niveau des grandes fonctions du système.

Relations: cas d'utilisation et acteurs
 Les acteurs impliqués dans un cas d'utilisation lui sont liés par une Association.
 Cette association décrit une interaction potentielle sans entrer dans les détails
de l’implémentation.
 Cas d’utilisation – Acteur: relation d’association
 Chemin de communication entre un acteur et un cas d’utilisation
 Est représentée par un trait continu
On dit qu’un acteur (principal) déclenche le cas d’utilisation
. 56
Sonda Chtourou Sellami COO 2019 - 2020
Relations: cas d'utilisation et acteurs
 Cas d’utilisation – Acteur secondaire
 Ajout du stéréotype « secondary » sur la relation
 Remarque: Un acteur peut utiliser plusieurs fois le même cas d'utilisation

 Il est possible d'ajouter une multiplicité sur l'association du côté du cas
d'utilisation.
 Le symbole * signifie plusieurs, exactement n s'écrit tout simplement n, n..m
signifie entre n et m, etc.
 La notion de multiplicité n'est pas propre au diagramme de cas
d'utilisation. Nous en reparlerons dans le chapitre consacré au diagramme de
classes.
Exercice 3:
 Énoncé: Système de validation de carte de crédit
 On souhaite modéliser les interactions de différents utilisateurs avec un
système de validation de cartes de crédit (basiquement un terminal avec un
lecteur de cartes).
 Les cartes de crédit sont détenues par des clients, pouvant être soit des
personnes individuelles ou une entreprise, et sont utilisées sous la supervision
d’une institution.
 Une institution commerciale supervise les transactions et le traitement de
factures des clients.
 Une institution financière supervise également ces factures, mais s’occupe
aussi de gérer le compte du client, avec son accord.

Exercice 3
 Solution: Système de validation de carte de crédit :
Système de validation de carte de crédit
Réaliser transaction <<Secondary>> <<Actor>>

carte
Institution
Client Commerciale
Traiter facture client

<<Actor>>
Institution
Client Entreprise Financière
Caution
Individuel Cliente Gérer compte client

Relations entre cas d’utilisation
 Généralisation:
 L’héritage est un concept fondamental en programmation, en analyse et en
conception orientée objet
 Cette idée appliquée aux acteurs et aux cas d’utilisation est appelée
généralisation/spécialisation :
 Le CU enfant est une spécialisation du CU parent.
 Le CU enfant hérite du comportement de CU parent.
 Le cas général est considéré comme un cas abstrait
CU parent
CU enfant

 Généralisation:
 « Payer par CB » est un cas

particulier de « Payer ».

 Inclusion:
 CU A utilise CU B ⇒ toute activation de CU A entraîne une activation de CU B
 Le CU A comprend le comportement du CU B.
 Le CU A dépend du CU B, le CU B n’existe pas tout seul et le CU A n’existe pas
sans le CU B.
 Cette dépendance est symbolisée par le stéréotype << include>>
CU A
<<include>>
CU B

 Inclusion:
<<include>>
<<include>>

 Extension:
 On dit qu'un cas d'utilisation B étend un cas d'utilisation A lorsque le cas
d'utilisation B peut être appelé au cours de l'exécution du cas d'utilisation A.
 L’extension permet d’identifier des comportements alternatifs optionnels.
 Cette dépendance est symbolisée par le stéréotype << extend >>
 L’extension peut être soumise à une condition.
CU A
<<extend>>
CU B

 Extension:
Client Commander
<<extend>>
Demander
catalogue

 Extension:
 Il est possible de définir un point d’extension: Indique la condition où intervient
l’extension.
 Une condition liée à un point d’extension est spécifiée dans une note.
Exemple: la vérification du solde du compte n'intervient que si la demande de

virement dépasse 20 euros.

Décomposition avec les inclusions et les extensions
 Quand un cas est trop complexe (faisant intervenir un trop grand nombre
d'actions), on peut procéder à sa décomposition en cas plus simples.

Réutilisabilité avec les inclusions et les extensions
 Les relations entre cas permettent la réutilisabilité du cas « s'authentifier »: il
sera inutile de développer plusieurs fois un module d'authentification.

Relations - Résumé
 Relation acteur-acteur
 Généralisation/spécialisation
 Relation acteur-cas d’utilisation

 Relation d’association
 Relations cas d’utilisation-cas d’utilisation

 Dépendances explicitées par des stéréotypes: Inclusion et extension
 Généralisation/spécialisation

Exercice 4
 Enoncé: Étude d'un système de gestion de stock d’articles d’un magasin
 Dans un magasin, un commerçant dispose d’un système de gestion de son
stock d’articles, dont les fonctionnalités sont les suivantes :
 Edition de la fiche d’un fournisseur
 Possibilité d’ajouter un nouvel article (dans ce cas, la fiche fournisseur est
automatiquement éditée. Si le fournisseur n’existe pas, on peut alors le créer)
 Edition de l’inventaire. Depuis cet écran, on a le choix d’imprimer l’inventaire,
d’effacer un article ou d’éditer la fiche d’un article).
 Question: Définissez le DCU correspondant

Les scénarios
 Un cas d’utilisation doit avoir un début et une fin clairement identifiés
 Un cas d’utilisation est une abstraction de plusieurs chemins d’exécution.
 Un scénario représente une succession d’enchaînements qui s’exécute du

début à la fin du cas d’utilisation
 Chaque résultat possible de l’exécution d’un cas d’utilisation représente un

scénario

Les scénarios
 Chaque cas d’utilisation possède :
 Un (et un seul) scénario nominal (se termine sans erreurs)
 Zéro ou plusieurs scénarios alternatifs
 Zéro ou plusieurs scénarios d’exception (échec)

Les scénarios
 Après la description des cas d’utilisation, il est nécessaire de sélectionner un
ensemble de scénarios qui vont servir à piloter l’itération en cours de
développement.
 Les scénarios sont utiles pour :

 analyser et concevoir le système
 justifier les choix effectués (ils serviront à la documentation des cas
d’utilisation)
 tester : les scénarios constituent le meilleur moyen de spécifier les tests.
 Le choix et le nombre de scénarios à retenir est une étape difficile à réaliser :

l’exhaustivité est difficile, voire impossible à atteindre.

Les scénarios
 Les différents scénarios d’un cas d’utilisation
peuvent être décrits par un :
 Description textuelle
 Diagramme d’activité
 Diagramme d’états
 Chaque scénario peut être décrit par un ou

plusieurs diagrammes d’interaction
 Diagramme de séquence
 Diagramme de communication

Description textuelle
 Chaque cas d’utilisation doit être précisé par une description textuelle qui peut
être structurée en plusieurs sections :
 conditions au démarrage (pré-conditions),
 conditions à la terminaison (post-conditions),
 étapes du déroulement normal (Scénario nominal),
 variantes possibles et les cas d’erreurs,
 informations échangées entre acteur et système,
 …
 Exemple:
Passer
commande
Client
Client

 Sommaire d’identification
 Titre: Fonctionnalité rendue par le cas d’utilisation (CU)
 Acteurs: Lister les acteurs et mentionner s’ils sont principaux ou secondaires
 Résumé: Une description résumée permettant de comprendre l’intention
principale de ce cas d’utilisation
 Description des enchainements

 Pré-conditions: Ce qui doit être vérifié avant le déclenchement du cas
d’utilisation
 Post-conditions: ce qui est vrai après déroulement du cas d’utilisation
 Scénario nominal: Description du scénario nominal sous forme d’actions
(acteurs) et réactions (système)

 Enchainements alternatifs: Description des scénarios alternatifs qui amènent
le scénario nominal à une autre séquence de traitement et qui se termine de
façon normale
 Enchainements d’erreurs: Description des scénarios d’exception qui
décrivent les cas d’erreurs
 Rubriques optionnelles
 Contraintes non fonctionnelles:
 Fiabilité : les accès doivent être sécurisés
 Confidentialité : les informations concernant le client ne doivent pas etre divulgués
 Contraintes liées à l'interface homme-machine:
 Toujours demander la validation des opérations bancaires
 ….

Description textuelle - Exemple
 Description textuelle de cas d’utilisation « Passer commande»:
Titre Passer commande
Acteur Client
Résumé Cas d’utilisation permettant à un client de passer une
commande
Pré-conditions - Client connecté sur le système
- Stock mis à jour
Prost- - Les articles sont réservés dans le stock
conditions - Liste des articles mise à jour
Scénario 1. Le client demande à accéder à la liste des articles
nominal 2. Le système affiche la page demandée
3. Le client choisit les articles et valide son choix
4. Le système calcule le montant de la facture
5. Le système affiche le devis de la commande
6. Le client choisit de valider la commande
7. Le système réserve les produits commandés

Enchaînements A1 : Le client décide de changer la commande et

alternatifs ne valide pas le devis en cours
- Dans l’étape 6 du scénario nominal, le client
choisit de modifier la commande
- L’enchaînement reprend au point 1 du scénario
nominal
A2 ….
Enchaînements E1 : Le client décide d’annuler la commande et
d’erreurs d’annuler l’achat
-Dans l’étape 6 du scénario nominal, le client
choisit d’annuler la commande
- Le système affiche un message et le cas
d’utilisation se termine

 Description textuelle de cas d’utilisation « Retirer Argent Distributeur »:
Titre Retirer Argent Distributeur
Acteur Client
Résumé Cas d’utilisation permettant à un client de retirer de
l’argent d’un distributeur bancaire
Pré-conditions Le distributeur contient des billets ; en attente d’une
opération : ni en panne, ni en maintenance.
Prost- si de l’argent a pu être retiré, la somme sur le compte est
conditions égale à la somme qu’il y avait avant moins le retrait. Sinon,
la somme sur le compte est inchangée
Scénario 1. le client introduit sa carte bancaire,
nominal 2. le système lit la carte et vérifie si la carte est valide,
3. le système demande au client de taper son code,
4. le client tape son code confidentiel,
5. le système vérifie que le code correspond à la carte,
6. le client choisit une opération de retrait,
7. le système demande le montant à retirer, etc.
Enchaînements A1: Informations sont erronées

alternatifs -Dans l’étape 5 du scénario nominal, si les
informations sont erronées, le client est averti de
l'erreur.
- Le client est invité à recommencer à l’étape 3.
Enchaînements E1 : Carte invalide :

d’erreurs -Dans l’étape 2 du scénario nominal, si la carte est
jugée invalide, le système affiche un message
d’erreur, rejette la carte et le cas d’utilisation se
termine.

classe

Introduction au diagramme de classes
 Un diagramme de classes (DCL) représente la structure statique du système
en termes de classes et de relations entre classes
 Une classe décrit un ensemble d’objets (instances de classes)
 Une association décrit un ensemble de liens (instances d’associations)
 Le diagramme de classes est le plus important dans une modélisation objet. Il

est utilisé :
 Durant la conception pour la définition formelle des objets composant le
système.
 Durant l’implémentation pour la génération automatique des structures
statiques du système (classes, relations).

Exemple
Cardinalité
Classe
Association

Exemple

Classe - Définition
 Une classe est une description d’un ensemble d’objets partageant les mêmes
attributs, opérations.
 Une classe est un concept abstrait représentant des éléments variés :

 Éléments concrets (ex: des avions, …)
 Éléments abstraits (ex: des commandes, …)
 Des éléments comportementaux (ex: des tâches, …)
 Des composants d’une application (ex: des boutons, …)
 ….

Classe - Notation
 Une classe est représentée par un rectangle découpé en 3 parties qui sont :
 Le nom de la classe
 La liste de ses attributs
 La liste de ses opérations

Classe - Notation
 Exemple:
Remarque: Tout est facultatif sauf le nom de la classe

Classe - Notation
 Un stéréotype permet d’étendre les classes déjà existantes en leur donnant
une signification sémantique différente.
 Quelques stéréotypes prédéfinis :

 « acteur »: classe modélisant un ensemble de rôles joués par un acteur
 « énumération »: classe définissant un ensemble d’identificateurs formant le
domaine de valeur d’un type.
 « interface »: classe contenant uniquement une description des opérations
visibles.
 ….

Visibilité des attributs/opérations
 Pour l’accessibilité aux attributs et opérations d’une classe, l’ UML définit 3
niveaux de protections :
 Public (+) : L’élément est visible par toutes les classes utilisables.
 Protégé (#) : L’élément est visible par les sous classes et à l’intérieur.
 Privé (-) : L’élément est visible par la classe uniquement.

Attributs
 Un attribut est une propriété définie par un nom, un type et éventuellement une
valeur initiale.
 Syntaxe:
[ visibilité ] nom_attribut [ multiplicité] : type_attribut [= valeur initiale]
 visibilité: + (Par défaut) / # / -

 nom_attribut: identificateur de l’attribut, unique au sein de la classe.
 multiplicité: l’attribut représente un ensemble de valeurs; exemple de tableau:
Parents [ 1..10 ]: Personne.
 valeur initiale: valeur prise par l’attribut lors de l’instanciation de la classe
(valeur en concordance avec le type de l’attribut).

Attributs
 type_attribut: ensemble des valeurs pouvant être prises par l’attribut. Il peut
être: une classe (Rectangle, Cercle, Personne,…), un type primitif (Entier, Chaîne
de caractères, Booléen,...) …
Télévision
+ no_television : int
+ marque: String
+ prix : float = 0
+ chaine [1 ..10]: Canal

Attributs
 Attribut dérivé:
 Un attribut dérivé est une propriété redondante qui peut être calculée à partir
d’autres attributs.
 Un attribut dérivé peut être traduit par une opération.
 Exemple:

Opération
 C’est une spécification du comportement des instances de la classe
 Syntaxe:
[ visibilité ] nom_opération ( [ arguments]) : Type retourné
 visibilité : + (Par défaut) / # / -

 nom opération: identificateur de l’opération, unique au sein de la classe.
 arguments: description des arguments nécessaires à l’opération.
 type retourné: type de la valeur retournée par l’opération.

Types de relation entre classes

Types de relation : Association
 Une association est une relation entre au moins deux classes qui entraînent des
connexions entre leurs instances.
 Syntaxe: trait reliant les deux classes en relation.
Nom association
Classe A Classe B
 Exemple:
Travailler pour
Personne Société
 En cas d’ambiguïté, indiquer le sens de lecture avec les signes ou (par

défaut lecture de gauche à droite).
Travailler pour
Personne Société

 Association à navigabilité restreinte:
 Restreint l'accessibilité des objets
 Depuis un objet A, on a accès aux objets de B qui lui sont associés, mais pas
l'inverse
 Par défaut, associations navigables dans les deux sens (pas de flèche)
Nom association
Classe A Classe B
Exemple:
 Chaque personne a accès aux films qu’elle a
déjà vus, mais à partir d’un film, on interdit de
retrouver la liste des personnes l’ayant vu.
 Incidence sur l’implémentation: la classe

Personne contiendra une collection de
Films. La classe Film ne contiendra aucun
attribut de type Personne.
 Rôles de l’association Syntaxe:
 Les extrémités des associations peuvent être qualités par des rôles.
 Un rôle permet de décrire à l’aide d’un nom comment une classe perçoit une
autre classe à travers l’association.
 Le rôle est un pseudo-attribut de la classe source (utilisé comme un attribut).
 Recommandation: ne pas utiliser des rôles et le nommage ensemble
 Notation et exemple:
Rôle de A
A B
Rôle de B

 Multiplicité
 La multiplicité précise le nombre d’instances pouvant être liées par une
extrémité d’association à une instance pour chaque autre extrémité d’association
 Multiplicités définies par UML:

1 Un et un seul
0..1 Zéro ou Un
M..N De M à N (entiers naturels)
0..* De Zéro à plusieurs
*
1..* De Un à plusieurs
N..* De N à plusieurs
N Exactement N (entier naturel)

 Exemples:
Une voiture est achetée par une Une personne peut acheter
et une seule personne 0 ou n voitures
1 *
1 .. *
PERSONNE rattacher à 0 .. 1 SERVICE
1 0 .. 1
diriger

 Résumé: Nom, rôle et Multiplicité
 Nom: forme verbale

 Sens de lecture de l’association indiqué éventuellement par une flèche
 Multiplicité: nombre (ou intervalle de nombres) d’instance(s) que l’association
peut impliquer
 Rôle: forme nominale d’écrivant le statut de la classe dans l’association.

 Contraintes sur les associations:
 Contrainte {sous-ensemble} {subset}: Ce type de contrainte permet de
modéliser le cas où un ensemble d’associations est inclus dans un autre
ensemble d’association
Cela signifie que les délégués d’un groupe font nécessairement

partie du groupe

 Contraintes sur les associations:
 Contrainte {ou-exclusif} {XOR}: Ce type de contrainte permet de modéliser le
cas où pour une instance donnée d’une classe, une seule association prise parmi
plusieurs possibles, peut être valide à un instant donné
Cela signifie qu’une personne peut être soit un employé dans une société
soit l’employeur de la société. Mais ne peut pas être à la fois employé et
employeur.

 Types d’association:
 Association binaire: associe 2 classes
 Association n-aire: associe plus de 2 classes
Etudiant Professeur Exemple:

1
 Pour une paire (salle, étudiant), il n’existe
qu’un professeur.
*
 Pour une paire (étudiant, professeur), il existe
Cours
plusieurs salles.
* Salle
 Pour une paire (salle, professeur), il existe

plusieurs étudiants.
Remarque: Les associations n-aires sont peu fréquentes. Dans la plupart des cas, on utilise
les classes-associations et plusieurs relations binaires.

 Types d’association:
 Association binaire: associe 2 classes
 Association n-aire: associe plus de 2 classes
 Association réflexive: associe une classe à elle même
Exemples: Les associations de parenté et

d’amitié sont réflexives: elles associent la classe
Personne avec elle-même
 La relation de parenté est asymétrique, donc

orientée (si une instance A est parent d’une
instance B, l’inverse ne peut pas être possible
simultanément)
 La relation d’amitié est symétrique. Deux
personnes peuvent être amies (on considère
que l’amitié est réciproque).

 Classe d’association:
 Une association peut être raffinée et avoir ses propres attributs, qui ne
sont disponibles dans aucune des classes qu'elle lie.
Cette association devient alors une classe appelée « classe-association ».
 Syntaxe:
 Exemple:
Personne 0..* 0..* Entreprise
Travaille dans
employé employeur
Poste
Titre : String
Salaire: double

 Une classe-association ou classe associative possède les mêmes
caractéristiques qu’une classe et qu’une association et peut participer
à ce titre à d’autres relations dans le modèle
 Remarque: Une classe d’association peut être remplacée par une classe
intermédiaire.

 Exemple:
Personne 0..* 0..* Entreprise
Travaille dans
employé employeur
Poste
Titre : String
Salaire: double
Personne 1 0..* Poste 0..* 1 Entreprise
occupe Titre : String pourvoit

Salaire: double

Types de relation : Contenance
 Cas particulier d’association exprimant une relation de contenance
 Exemples:
 Une voiture a 4 roues
 Un dessin contient un ensemble de figures géométriques
 Une présentation PowerPoint est composé de transparents
 Une équipe de recherche est composée d’un ensemble de personnes
 Deux types de relations de contenance en UML

 Agrégation
 Composition (Agrégation forte)

 Agrégation: «made of» ou «part of »
 L’agrégation est une relation non symétrique dans laquelle une des extrémités
joue un rôle prédominant.
 L’agrégation représente une relation de contenance « ensemble/élément »
 La création ou destruction du composite est indépendante de la création ou
destruction de ses composants
 Une classe peut appartenir à plusieurs composites à la fois
 Syntaxe:
A - composite B

 Agrégation:
 Exemple:
Département
Enseignant

 Composition :
 La composition est une forme particulière d’agrégation avec une relation
d’appartenance forte et coïncidence des durées de vie.
 La classe ayant le rôle prédominant est la classe composite.
 La composition fait souvent référence à une contenance physique.
 Une coïncidence des durées de vie: la destruction du composite implique
automatiquement la destruction de tous ses composants.
 Un composant appartient à au plus un composite
1 / 0..1
 Syntaxe: A - composite B

 Composition :
 Exemple:
 «Une présentation PowerPoint est composé de transparents »
 La suppression de la présentation entraine la disparition des transparents qui
la compose.
 Les composants n'ont pas d'autonomie vis-à-vis des composites.

 Composition :
 Exemple:
VOITURE
4..4 1..1 1..1 1..1
Roue Chassis Moteur Carrosserie

 Agrégation vs. Composition :

Types de relation : Héritage
 Héritage simple
 Permet de créer une nouvelle classe à partir d'une classe existante
 La classe dérivée contient les attributs et les méthodes de sa superclasse, et
peut contenir d’autres.
Chaque personne de l’université est identifiée par son nom, prénom

 Les étudiants ont plus un noEtudiant
 Les enseignants ont un numéro de téléphone interne

 Héritage multiple
 Mécanisme permettant à une classe d’avoir plusieurs classes mères
 Les superclasses n’ont pas forcement d’ancêtres communs

 Contraintes sur les généralisations:
 {disjoint } = les sous-classes n’ont aucune instance en commun
 {overlapping} = les sous-classes peuvent avoir une ou plusieurs instances en
commun
{overlapping} précise ici qu’il existe des véhicules amphibie qui sont issus
d’un croisement des sous-classes de véhicule.
 Contraintes sur les généralisations:
 {complete} (liste exhaustive de classe) / {incomplete} (les sous-classes
spécifiées ne couvrent pas la super-classe)
 {incomplete} exprime l’idée que des instances de la classe Personne sont

des avocats, des vendeurs, des enseignants ou d’autres personnes ...
 {complete} exprime l’idée qu’un enseignant ne peut être autre chose qu’un
permanent ou vacataire
Classes abstraites
 Présentation:
 Une méthode est dite abstraite lorsqu'on connaît son entête mais pas
la manière dont elle peut être réalisée.
 Une classe est dite abstraite lorsqu'elle définit au moins une méthode abstraite
 Intérêt:
 Permet d'imposer des fonctionnalités qu'on souhaite avoir dans toutes les sous-
classes instanciables.
 Imposer les signatures des méthodes abstraites pour différentes
implémentations.

Classes abstraites
Syntaxe:
 Notation: mot clé {abstract} ou nom en italique
Nom classe Nom classe

{abstract}
 Exemple:

Polymorphisme
 Mécanisme permettant à une classe fille la spécification d’opérations.
 Exemple:

Une classe particulière: Interface
 Définition:
 Une interface est en fait une classe particulière (avec le stéréotype « interface»).
 Classe dont toutes les opérations sont abstraites
 Le rôle d'une interface est de regrouper un ensemble d'opérations assurant un
service.
 Syntaxe:
<<Interface>>
Nom interface
Nom d’interface
Op1()

 Relations:
 Les classes qui utilisent l’interface peuvent exploiter tout ou une
partie de l’interface.
 Les opérations décrites dans l’interface sont implémentée par une classe
réalisatrice.

 Exemple:
Classe réalisatrice
Classes
utilisatrices

Exercice 1
 Question : Dessinez le diagramme de classe correspondant à chaque phrase
 1) Un répertoire contient des fichiers
 2) Une pièce contient des murs
 3) Les modems et les claviers sont des périphériques d’entrée/sortie
 4) Une transaction boursière est un achat ou une vente
 5) Un compte bancaire peut appartenir à une personne physique ou morale
 6) Deux personnes peuvent être mariées

Exercice 2
 Enoncé:
« Un stylo et un feutre sont deux concepts proches ayant des caractéristiques
communes : couleur, marque, etc. Un feutre possède un bouchon. Un stylo et un
feutre possèdent tous les deux un corps ayant certaines propriétés. Un stylo ou un
feutre sont utilisés par une personne et appartiennent à une personne. Il existe un
feutre particulier qui est un feutre effaceur. »
 Question : Dessinez le diagramme de classe correspondant

Exercice 3
 Enoncé: Etude d’un système de réservation de vol
Cette étude de cas concerne un système simplifié de réservation de vols pour une agence de
voyages. Les interviews des experts métier auxquelles on a procédé ont permis de résumer
leur connaissance du domaine sous la forme des phrases suivantes:
1. Des compagnies aériennes proposent différents vols.
2. Un vol est ouvert à la réservation et refermé sur ordre de la compagnie
3. Un client peut réserver un ou plusieurs vols, pour des passagers différents
4. Une réservation concerne un seul vol et un seul passager.
5. Une réservation peut être annulée ou confirmée.
6. Un vol a un aéroport de départ et un aéroport d’arrivée.
7. Un vol a un jour et une heure de départ, et un jour et une heure d’arrivée.
8. Un vol peut comporter des escales dans des aéroports.
9. Une escale a une heure d’arrivée et une heure de départ.
10. Chaque aéroport dessert une ou plusieurs villes

Chapitre 4: Passage de
diagramme de
classe au code Java

Introduction
 UML est un langage de modélisation visuelle, Java est un langage de
programmation textuel.
 UML est plus riche que les langages de programmation dans le sens où il offre
des moyens d’expression plus abstraits et plus puissants.
 Cependant, il existe généralement une façon privilégiée de traduire les concepts

UML en déclarations Java.
 Les diagrammes de classe réalisés permettent de produire, d’une manière

aisée, la squelette du code dans un langage de programmation objet tel que Java

Règle 1: Classe
 Par défaut chaque classe UML devient un fichier .java (Java)
UML JAVA
public class Catalogue {

Catalogue …
}

Règle 2: Attribut
 Les attributs deviennent des variables en Java.
 Leur type est soit un type primitif (int, etc.), soit une classe fournie par la plate-
forme (String, Date, etc.). Attention à ne pas oublier dans ce cas la directive
d’importation du package correspondant.
 La visibilité des attributs est montrée en les faisant précéder par + pour public, #
pour protégé ( protected ), - pour privé ( private ).
UML JAVA
import java.util.Date;
Article public class Article{
- nom: String private String nom;
- dateCreation: Date private Date dateCreation;
- Nbpage:int=50 private static int nbpage = 50;
…
}

Règle 3: Opération
 Les opérations deviennent des méthodes en Java.
 Leur visibilité est définie avec les mêmes conventions que les attributs.
UML JAVA
public class Catalogue {
Catalogue private String nom;

private Date dateCreation;
- nom: String
- dateCreation: Date public Livre chercherLivre(ISBN isbn) {
+chercherLivre(isbn:ISBN):Livre …
}
…
}

Règle 4: Interface
 La notion interface dans UML (représentée sous ses deux formes graphiques)
se traduit par le mot-clé correspondant en Java.
UML JAVA
interface Affichable {
…
Affichable void imprimer()
}

Règle 4: Interface
UML JAVA
public class Livre implements

IImprimable, Iempruntable
{
private String titre;
private String auteur;
private ISBN isbn;
public void imprimer()
{…}
public void emprunter()
{…}
public void retourner()
{… }
}

Règle 5: Classe abstraite
UML JAVA
abstract public class
Personne Personne {
…
public abstract void fonct ()

// fonct n’est pas définie
}

Règle 6: Généralisation
 Le concept UML de généralisation se traduit directement par le mécanisme de
l’héritage dans les langages objet.
UML JAVA
public class Adherent extends Personne

{
private int iD;
}

Règle 7: Association
 On ne traduit que les extrémités navigables.
 Quand une extrémité a une cardinalité inferieure ou égale à 1, on traduit
l’extrémité par un attribut.
 Quand on a une extrémité de cardinalité strictement supérieure à 1, on utilise les
types de bibliothèque représentant des collections : listes, tableaux, ...
UML JAVA
public class A1 {
private B1 b1;
…
}
public class A2 {
private B2 b2[];
…
}

Règle 8: Association bidirectionnelle
 Une association bidirectionnelle se traduit simplement par une paire de
références, une dans chaque classe impliquée dans l’association.
 Les noms des rôles aux extrémités d’une association servent à nommer les
variables de type référence.
UML JAVA
public class Homme {
private Femme epouse;
…
}
public class Femme {
private Homme mari;
…
}

Règle 9: Association Réflexive
 Une association réflexive se traduit simplement par une référence sur un objet
de la même classe.
UML JAVA
public class Personne {
private Personne subordonne[];
private Personne chef ;
…
}

Règle 10: Agrégation/Composition
 La sémantique des agrégations n’est pas fondamentalement différente de celle
des associations simples, elles se traduisent donc comme indiqué précédemment
en Java.
 La notion de classe imbriquée peut s’avérer intéressante pour traduire la
composition.
UML JAVA
public class Voiture {
private String modele;
private Moteur moteur;
private static class Moteur {
private int puissance;
}
…
}

Règle 11: Classe d’association
 Ce concept UML avancé n’existe pas dans les langages de programmation
objet.
 Il faut donc le traduire en le transformant en classe normale, et en ajoutant des
variables de type référence.
UML JAVA
public class Emploi {
public String titre;

public double salaire;
public Personne employe;
public Societe employeur ;
…
}

Chapitre 5: Passage de
diagramme de classe au base
de données relationnelle

Règle 1: Classe
 La classe se transforme en une table.
 Les attributs de la classe deviennent des attributs de la table.
 Choisir un attribut (ou groupe d'attribut) de la classe pouvant jouer le rôle de clé
primaire; si aucun attribut ne convient, il faut en ajouter un à la table.
 Exemple:
Etudiant (codeE, nom,adresse)

Filière (code,thème,nbheures)

Règle 2: Association (0..* ou 1..*) à (0..1 ou 1..1)
 Ajouter un attribut de type clé étrangère dans la relation à multiplicité plusieurs
de l’association.
 Exemple:
Etudiant(codeE, nom,adresse, code#)
Filière(code,thème,nbheures)

Règle 3: Association de (0..1 ou 1..1) à (0..1 ou 1..1)
 Ajouter un attribut de type clé étrangère dans la relation dérivée de la classe
ayant la multiplicité minimale égale à un.
 Dans le cas où les deux multiplicités minimales sont à 1, il est préférable de
fusionner les deux entités.
Etudiant (numEt, nomEt, numSta#)
Stage (numSta, theme, responsable)

Règle 4: Association (0..* ou 1..*) à (0..* ou 1..*)
 L’association ou la classe-association devient une relation.
 La clé primaire est composée des clés primaires des relations obtenues.
 Exemple:
Fournisseur(codeF, nomFour, ville)
Fournir(codeF#, numProd #)
Produits (numProd, libellé)

Règle 5: Classe d’association
 Exemple:
Personne (Code-Personne, Nom, Prenom, Adresse)

Livre(Code-livre, Auteur, Titre, Edition)
Emprunte(Code-livre#, Code-Personne#,Date, Date-Retour)

Règle 6: Association réflexive
Piece (numpièce, designation)
Composer( numpièce-composante#,
numpièce-composite# )
Pilote (numP, nom, fonction, compagine,

numChef#)

 Méthode 1:
 Créer une table avec tous les attributs des classes (super classe et sous
classe).
 Ajouter un attribut pour distinguer les types des objets.
 Méthode 2:
Transformer chaque sous classe en une table.
Tous les attributs de la super classe deviennent des attributs de chaque sous
classe.
 Méthode 3:
Transformer la super classe en une table
Transformer chaque sous classe en une table.
 La clé primaire de la superclasse devient clé primaire de chaque sous classe
 Exemple
Personne
Code-Personne
Nom
Prenom
Adresse
Professeur Etudiant
Salaire Noma
Note-Moyenne

 Méthode 1:
Personne(code-Personne, Nom, Prenom, Adresse, Salaire, Noma, Note-Moyenne,
type-personne)
 Méthode 2:
Etudiant (code-Personne, Nom, Prenom, Adresse, Noma, Note-Moyenne)
Professeur (code-Personne, Nom, Prenom, Adresse, Salaire)
 Méthode 3:
Personne (code-Personne,Nom,Prenom,Adresse)
Professeur (code-Personne#, Salaire)
Etudiant (code-Personne#, Noma, Note-Moyenne)

Règle 8: Agrégation et composition
 Traiter comme une association

Exercice 1
 Construire le modèle relationnel correspondant au diagramme de classe suivant:

Exercice 2
Occupation
Date
Heure
Durée
Cours
Code-Cours Salle
Nom-Cours est occupée par occupe Code-Salle
Description 0..n 1..n Localisation
Nombre-ECT
Auditoire SalleInfo
Nombre-Places Nombre-Ordinateurs

Exercice 3

Chapitre 6: Diagrammes
d’Objets

Introduction au diagramme d’objets
 Un diagramme d’objets est une instance d’un diagramme de classes et illustre
l’état d’un système à un moment donné.
 Le diagramme de classes modélise les règles et le diagramme d'objets modélise

des faits.
 Un diagramme d’objets est une représentation d’un ensemble d’objets et de

liens exprimant la structure statique.
 Un diagramme d’objets est composé :

 Objets (instances de classes),
 Liens (instances d’associations).

Introduction au diagramme d’objets
 Un diagramme d'objets peut être utilisé pour:
 montrer un contexte (avant ou après une interaction)
 faciliter la compréhension des structures de données complexes e.g.,
structures récursives
 illustrer un exemple qui explique le modèle de classes
 exprimer une exception en modélisant des cas particuliers ou des
connaissances non généralisables qui ne sont pas modélisés dans un
diagramme de classes

Objet
 Un objet est une instance d’une classe: il représente “l’état” d’une classe à un
instant précis.
 Représentation :
 L’ état d’un objet est déterminé par les valeurs de ses attributs.
 Il est possible de nommer un état afin d’indiquer clairement dans quel état se
trouve un objet.

Objet
 Possibilité de modéliser les changements d’états des objets:
 Possibilité d’utiliser des liens stéréotypés (exemple copie d’objet )

Objet
 Représentation des objets composites

Lien
 Les objets sont relies par des instances d’associations: les liens.
 Un lien représente une relation entre objets à un instant donné.
 ATTENTION: la multiplicité des extrémités des liens est toujours de 1.
 Exemple: représentation de la structure générale d’une voiture

Lien
 Les rôles des associations peuvent être représentés

Exercice
 Enoncé: Soit le diagramme de classe du système de sécurité limitant les accès
à des parties à l’aide de cartes magnétiques

Exercice
 Suite de l’énoncé:
 Le système gère un seul bâtiment contenant trois portes.
 Le système peut être gère par une personne nommée Ali.
 Deux utilisateurs peuvent accéder au bâtiment :
 Sami a accès a la première (8h-18h) et seconde porte (12h-24h)
 Omar a accès a la troisième porte toute la journée.
 Question: Donnez le diagramme d’objet correspondant au:

Exercice
 Solution:

séquences

Introduction au diagramme de séquences
 Les diagrammes de séquences permettent:
 Modéliser les aspects dynamiques des systèmes et les scénarios
complexes.
 Représenter les interactions entre objets selon un point de vue temporel
(ordre chronologique).
 L’interaction se traduit par les échanges de messages entre les objets.
 Les diagrammes séquences permettent de décrire la réalisation des cas

d'utilisation sur le système décrit par le diagramme de classes:
 Description de scénarios / Documentation sur le fonctionnement du système
 Représentation des échanges de messages selon un point de vue temporel
 Entre les acteurs et le système,
 Entre les objets du système
 Dans un diagramme de séquences, on trouve:
 Les objets intervenant dans l’interaction (acteurs ou objets appartenant au
système)
 La description de l’interaction (messages)
 Des Fragments combinés (les cadres d’interaction): alternatives, boucles,
référence a un autre diagramme de séquences …
 Le diagramme de séquences a deux dimensions:

 Dimension horizontale représentant les objets
 Dimension verticale représentant l’écoulement du temps

 Exemple:

 Exemple:

Objets - Définition
 Les objets sont des entités appartenant au système (instances) ou se trouvant
à ses limites (instances d’acteurs).
 Ils peuvent être du type acteur, système ou constituant du système, suivant le

degré d'approfondissement dans la description du système.
 Les objets sont identifiés à partir de diagrammes de classes et de diagrammes

de cas d’utilisation

Objets - Représentation
 Les objets sont représentés:
 Un rectangle: nom_instance: Classe
 Un petit personnage pour les acteurs: le rôle de l’acteur
 Remarques:
 Généralement, l’objet qui commence l’interaction est placé le premier à
gauche.
 Les acteurs peuvent être représentés par des rectangles (stéréotypés)

Objets - Ligne de vie des objets
 Une ligne de vie est associée à chaque objet.
 La ligne de vie (life line) est représentée par une ligne verticale en traits
pointillés placée sous le symbole de l’objet concerné.
 Cette ligne de vie précise l’existence d’un objet pendant une période de temps.
 En général, la ligne de vie d’un objet est représentée sur toute la hauteur du
diagramme.
 Elle peut débuter et s’interrompre dans un diagramme de séquence, si l’objet est

créé et/ou détruit pendant la durée définie par ce diagramme.

Objets - Ligne de vie des objets
 La création d’un objet se représente en faisant pointer le message de création
sur le rectangle de l’objet créé.
 La destruction est indiquée par la fin de la ligne de vie de l’objet concerné
(l’objet n’est plus actif) et représentée par une croix ()

Objets - Période d’activité
 Le diagramme de séquences permet de représenter les périodes d’activation
des objets.
 Une période d’activité correspond au temps pendant lequel un objet effectue
une action.
 Les périodes d’activité se représentent par des bandes rectangulaires placées
sur les lignes de vie.
A B
Message d’activation
période d’activité
A active B, la période d’activité
de A recouvre celle de B

Message - Définition
 La communication entre objets est représentée par les échanges de messages
 Les messages sont ordonnés selon leurs positions sur les lignes de vie.
 Exemple:

Message – Types de messages
 Message synchrone: Émetteur bloqué en attente du retour. Le flot de contrôle
passe de l'émetteur au récepteur.

 Typiquement un message synchrone est l’invocation d’une opération (Si un
objet A invoque une méthode d’un objet B, A reste bloqué tant que B n’a pas
terminé.
 Il est représenté par une flèche avec un triangle plein à son extrémité.

 Message asynchrone: L'émetteur envoie un message sans attendre de
réponse de la part du récepteur (Émetteur non bloqué). Il peut être:

 Envoi d’un signal pour la gestion événementielle.
 Appel de méthode dans un système multi-threads où l’objet expéditeur
n’étant pas bloqué pendant l’exécution de la méthode, il peut continuer ainsi à

envoyer d’autres messages.
 Il est représenté par une flèche simple

 Message de retour: Le récepteur d’un message synchrone rend la main à
l’émetteur du message en lui envoyant un message de retour.

 Le message de réponse est asynchrone, puisqu'il n'attend pas de réponse.
 Le message retour porte généralement le nom de l’élément retourné
 Il est représenté par une flèche simple en pointillés.

 Message réflexif / récursif :
 Un message réflexif: Un objet peut s’envoyer un message
 Un message récursif: Se représente par un dédoublement de la bande
d’activation.

 Message trouvé / Message perdu:
 En UML 2.0, il est possible également de présenter les messages trouvés
(source indéterminée) et les messages perdus.

 Exemple: modéliser les scenarios de pertes de message sur un réseau.
Évènement de A
réception est connu Évènement d’envoi
est connu
Message
trouvé
Message perdu

Message - Syntaxe générale
 Syntaxe des messages synchrones et asynchrones :
 Son nom qui est le nom de la méthode appelée ou du signal envoyé
 Une numérotation devant le nom message. La numérotation s’effectue
séquentiellement à partir de 1 (La numérotation est optionnelle)
 Les paramètres passés à la méthode ou au signal

Message - Syntaxe générale
 Syntaxe des messages de retour:
ValeurDeRetour
Ou
ValeurDeRetour = nomMessage (paramètres)

Message - Contraintes temporelles
 Les contraintes temporelles peuvent représenter les délais de transmission non
négligeables par rapport à la dynamique générale de l’application: flèches
obliques.
A B
t
{t’-t<7s}
t’

UML 2.0: Fragments combinés
 Les fragments combinés (les cadres d’interaction) permettent de décomposer
les interactions complexes.
 Définis par:
 Un opérateur d’interaction
 L’opérateur conditionne la signification du fragment combiné (exp ref,
opt, alt, loop, critical, parallel..)
 Condition de garde
 Présentée entre [ ]
 Une ou plusieurs opérandes d’interaction
 Conditionnée par la condition de garde (la condition doit être vraie)

 Fragment combiné opt: Instructions de test sans alternatives (Si [cond] vraie
Alors traitements)
A B C
opt [condition]
message1()
message2()
188

 Fragment combiné opt: Instructions de test sans alternatives (Si [cond] vraie
Alors traitements)
 Exemple:

 Fragment combiné alt: structure de contrôle « si .. alors .. sinon »
A B C
Séparation des
opérandes
alt H()
[Condition1]
E()
[Condition2]
G()
Cadre d’interaction
[else] F()

 Fragment combiné alt: structure de contrôle « si .. alors .. sinon »
 Exemple:

 Fragment combiné loop: répétition du fragment un nombre fini de fois ou tant
qu’une condition est vraie
A B
loop (0,n)
message()
loop [condition]
message()

qu’une condition est vraie.
 Exemple:

qu’une condition est vraie.
 Exemple:

 Fragment combiné par: au moins deux fragments qui s’exécutent en parallèle
A B C
par T()
M()
N()
E()
H()
R()

 Fragment combiné critical: pour les fragments qui doivent se dérouler sans
être interrompus
A B C
critical message1()
message2()
message3()

 Fragment combiné break: fragment exécuté en situation d’exception qui met
fin au fragment englobant.
A B
break [condition]
E()

 Fragment combiné sd:
A B C
sd : operation1
message1()
message2()

 Fragment combiné ref: Référencer un autre diagramme de séquence
A B C
ref
Nom du diagramme référencé

 Fragment combiné ref: Référencer un autre diagramme de séquence
 Exemple:

Exemple de diagramme de séquences








Exercice 1: Jeu de démineur
 Enoncé: Ecrire le diagramme de séquence quand un joueur dévoile une case :
 Si la case est minée, la partie est perdue
 Si la case est numérotée, il faut tester si la partie est gagnée
 Si la case est vide, on découvre toutes les cases voisines
 Question: Donner le diagramme de séquences

Exercice 2: Robot
 Enoncé: On veut modéliser le comportement d’un robot mobile, doté d’une
caméra et d’un détecteur de chocs. Pendant son fonctionnement normal, le robot
doit analyser l’image qui provient de la caméra et le détecteur de chocs doit lui
permettre d’éviter les obstacles. En cas d’urgence, à tout moment un pilote humain
peut faire arrêter le robot, ce qui entraine l’arrêt immédiat de son moteur : cette
opération doit être accomplie de façon atomique.
 Question: Donner le diagramme de séquences

Exercice 3: Banque - Retrait d'espèces
 Enoncé: Dans un système bancaire, le cas d'utilisation «retrait d'espèces»
contient les éléments suivants:
1. Le guichetier saisit le numéro de compte du client
2. L'application valide le compte auprès du système central et affiche les types
d’actions
3. Le guichetier demande un retrait en espèces de 100 euros
4. Le système « guichet » interroge le système central pour s'assurer que le
compte est suffisamment approvisionné
5. Le système central effectue le débit du compte
6. En retour, le système notifie au guichetier qu'il peut délivrer le montant
demandé.
 Question: Donner le diagramme de séquences associé à cette description
textuelle.

Cours UML 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

Cours UML PDF

Transféré par

Droits d'auteur :

Formats disponibles

Ecole Nationale Supérieure d‘Ingénieurs de Tunis

Sonda Chtourou Sellami COO 2019 - 2020 2

Le cycle de vie en < V > Le cycle de vie en spirale

Sonda Chtourou Sellami COO 2019 - 2020 3

Une bonne conception participe largement à la production d'un logiciel qui

Sonda Chtourou Sellami COO 2019 - 2020 4

Sonda Chtourou Sellami COO 2019 - 2020 5

Sonda Chtourou Sellami COO 2019 - 2020 6

Sonda Chtourou Sellami COO 2019 - 2020 7

Sonda Chtourou Sellami COO 2019 - 2020 8

Sonda Chtourou Sellami COO 2019 - 2020 9

 On distingue principalement de trois de méthodes de conception:

Sonda Chtourou Sellami COO 2019 - 2020 10

Représentation graphique d'une approche fonctionnelle

Sonda Chtourou Sellami COO 2019 - 2020 12

Sonda Chtourou Sellami COO 2019 - 2020 13

Comment structurer un système sans centrer la conception uniquement sur

Sonda Chtourou Sellami COO 2019 - 2020 14

Aucun méthode ne s'est réellement imposée.

Sonda Chtourou Sellami COO 2019 - 2020 16

 Consensus sur 3 méthodes pour créer un langage de modélisation unifié:

Sonda Chtourou Sellami COO 2019 - 2020 17

 De version en version, UML évolue, gagne en maturité et précision, tout en

Sonda Chtourou Sellami COO 2019 - 2020 18

L'OMG est un consortium à but non lucratif,

Sonda Chtourou Sellami COO 2019 - 2020 19

 UML est un langage unifié pour la modélisation objet.

 UML permet d'exprimer et d'élaborer des modèles objet, indépendamment de

Sonda Chtourou Sellami COO 2019 - 2020 20

Sonda Chtourou Sellami COO 2019 - 2020 21

 Les auteurs d'UML préconisent d'utiliser une démarche:

Sonda Chtourou Sellami COO 2019 - 2020 22

 Est-ce qu’un seul modèle est suffisant?

Sonda Chtourou Sellami COO 2019 - 2020 23

 Chaque modèle peut être exprimer à différents niveaux de précision

 Créer un ou plusieurs modèles différents mais avec un point commun pour

Un seul modèle n’est jamais suffisant!!!

Sonda Chtourou Sellami COO 2019 - 2020 24

Sonda Chtourou Sellami COO 2019 - 2020 25

Sonda Chtourou Sellami COO 2019 - 2020 26

Sonda Chtourou Sellami COO 2019 - 2020 27

Sonda Chtourou Sellami COO 2019 - 2020 28

Sonda Chtourou Sellami COO 2019 - 2020 29

Sonda Chtourou Sellami COO 2019 - 2020 30

Sonda Chtourou Sellami COO 2019 - 2020 31

Sonda Chtourou Sellami COO 2019 - 2020 32

Sonda Chtourou Sellami COO 2019 - 2020 33

Sonda Chtourou Sellami COO 2019 - 2020 34

Sonda Chtourou Sellami COO 2019 - 2020 35

 Polymorphisme d’opération: la possibilité de déclencher des opérations

Sonda Chtourou Sellami COO 2019 - 2020 37

Sonda Chtourou Sellami COO 2019 - 2020 38

 Les besoins souvent exprimés dans un cahier des charges de manière:

Sonda Chtourou Sellami COO 2019 - 2020 39

 DCU se base sur le cahier des charges:

Sonda Chtourou Sellami COO 2019 - 2020 40

 DCU identifie et représente:

Sonda Chtourou Sellami COO 2019 - 2020 41

Sonda Chtourou Sellami COO 2019 - 2020 42

Sonda Chtourou Sellami COO 2019 - 2020 43

Sonda Chtourou Sellami COO 2019 - 2020 44

 Un acteur est un utilisateur du système qui peut être un humain, logiciel, ….

 Ne pas confondre acteur et personne utilisant le système :