1 MCOO Casutilisation

Présentation du module MCOO
Les diagrammes des aspects statiques

Les diagrammes des aspects dynamiques
Méthode de Conception Orientée

Objet
M . C. O.O.
Présentation du module MCOO
Méthodes de dével oppement
Les diagrammes des aspects statiques
Concepts objet
Les diagrammes des aspects dynamiques
U.M.L.
Plan du cours
1 Présentation du Modélisation Orientée Objet
M.C.O.O.
Méthodes de développement
Concepts objet
U.M.L.
22 Les diagrammes des aspects statiques

Diagrammes de cas d’utilisation
Diagrammes de classes
Diagrammes de composants
Diagrammes de déploiement
33 Les diagrammes des aspects dynamiques

Diagrammes de séquence
Diagrammes de collaboration
Diagrammes d’états-transition
Diagrammes d’activité
Pourquoi modéliser ?
 Importance de la modélisation
 La niche, la maison familiale et l'immeuble
 pour construire une niche :
◼ quelques planches, des clous, un marteau et
quelques outils.
 pour construire une maison familiale :
◼ + plans généraux, plans d'exécution détaillés
(pièces, électricité, plomberie, chauffage) ;
 pour construire un immeuble :
◼ + Planification détaillée, nombreux plans et études
Pourquoi modéliser ?
 D’où l’intérêt d’une modélisation pour Mieux comprendre
le système
 Objectifs :
◼ nous aider à le visualiser tel qu'il est ou tel qu'il
devrait être
◼ spécifier la structure et le comportement d'un
système
◼ avoir un "patron" pour guider la construction du
système
◼ documenter les décisions qui ont été prises
 Nous construisons des modèles de systèmes complexes
parce que nous sommes incapables d'appréhender ces
systèmes dans leur entièreté.
 Un modèle est une simplification de la réalité
M.C.O.O.
Pr ésent at i on du m odul e MCO O
Mé t h o d es d e d é v el o p p em en t
Les di agr am mes des aspect s st at i ques
C o n c ep t s o b j et
Les di agr am mes des aspect s dynam i ques U.M.L.
Qu'est-ce qu'un modèle ?

Un modèle est une abstraction de la réalité
L'abstraction est un des piliers de l'approche objet.

• Il s'agit d'un processus qui consiste à identifier les caractéristiques
intéressantes d'une entité, en vue d'une utilisation précise.
• L'abstraction désigne aussi le résultat de ce processus, c'est-à-dire
l'ensemble des caractéristiques essentielles d'une entité, retenues par un
observateur.
Un modèle est une vue subjective mais pertinente de la réalité

•Un modèle définit une frontière entre la réalité et la perspective de
l'observateur. Ce n'est pas "la réalité", mais une vue très subjective de la
réalité.
• Bien qu'un modèle ne représente pas une réalité absolue, un modèle reflète
des aspects importants de la réalité, il en donne donc une vue juste et
pertinente.
M.C.O.O.
un modèle permet :
1. de faciliter la compréhension du système étudié
→Un modèle réduit la complexité du système étudié.
2. de simuler le système étudié
→ Un modèle représente le système étudié et reproduit ses comportements.
-Un modèle réduit (décompose) la réalité, dans le but de disposer d'éléments de
travail exploitables par des moyens mathématiques ou informatiques.
M.C.O.O.

Pr ésent at i on du m odul e MCO O M.C.O.O.
Pr ésent at i on du m odul e MCO O Mé t h o d es d e d é v el o p p em en t
LLes
e s ddi iaaggrraam
mm mes
e s ddese s aassppec e cttss ssttaatti iqquueses C o n c ep t s o b j et
L e sL d
e s d i a g rm
i a g r a m e smdees sd ae ss paescpt se cdt ys ndaymn iaqm
am u ei qsu e s U.M.L.
M.C.O.O. qu’est-ce que c’est?
Modélisation
établir un modèle
Et Conception
élaborer, se représenter quelque chose
Orienté Objet
vers l’objet
MCOO : modéliser et concevoir en utilisant les objets du monde

réel.
Psr é se M . C . OM . O. C. .O.O.
Pré en t anttiaotni odnu dm
u omd ou dl eu lM
e CMOCOO O
Mé t h o dMées tdheo ddes d eo pdpéem
é v el v elen
o ptp em en t
LLeess ddi iaaggrraam
mm meess ddeess aassppeeccttss ssttaatti iqquueess C o n c e pCt os nocbejpetts o b j e t
Les di agr am m esdes aspect s dynam i ques U . M . L .U . M . L .
Les di agr am mes des aspect s dynam i ques
Historique des méthodes de développement

Liées aux langages de programmations.
Les méthodes fonctionnelles (1970 - )

Décomposition d’une fonction en plusieurs sous -fonctions.
Architecture basée sur la décomposition fonctionnelle : peu d’évolutions possibles

Peu de réutilisation des composants
Les méthodes classiques (1980 - )

Modélisation des données et des traitements.
➢JSD : Jackson System Development

➢MACH : Méthode d’Analyse et de Conception Hiérarchisée
➢MERISE : Méthode d’Etude et de Réalisation Informatique pour les Systèmes
d’Entreprise
➢SADT : Structured Analysis and Design Technique
SASD : Structured Analysis Structured Design
M.C.O.O.
Les di agr am m esdes aspect s dynam i ques
U.M.L.
Historique des méthodes de développement

Liées aux langages de programmations.
Les méthodes objet

Objet = abstraction des entités du monde réel
aide à visualiser les objets tel qu’ils sont ou tels qu’on le souhaite
permet de spécifier la structure ou le comportement d’un objet
fournit un guide pour la construction du système
documente les décisions prises lors de la construction d’un système
Quelques méthodes orientées-objet
OOA : Object Oriented Analysis, Schlaer/Mellor (1988,91,93)

OOD : Object Oriented Design, Booch (1991,93)
OMT : Obj ec t Model l i ng T ec hni que, R um baugh (1991,95 )

OOSE : Object Oriented Software Engineering, Jacobson (1992)
M.C.O.O.
U.M.L.
Unification des méthodes

M.C.O.O.
U.M.L.
Unified Method
auteurs : Booch, Rumbaugh et Jacobson
rapprochement de leurs méthodes
Historique de la création d’UML
1995 Début du travail sur la méthode unifiée

1997 UML 1.1 (normalisé par l’OMG)
1998 UML 1.2
1999 UML 1.3
2001 UML 1.4
2003 UML 1.5
2005 UML 2.0
2017UML2.5.1
M.C.O.O.
U.M.L.
Unified Method
auteurs : Booch, Rumbaugh (OMT)et Jacobson(OOSE)
rapprochement de leurs méthodes + cas d’utilisation
Object Management Group - OMG
•Organisation internationale créée en 1989

•Plus de 800 membres (informaticiens et utilisateurs)
•Vise à promouvoir la théorie et la pratique de la technologie
objet dans le développement logiciel
M.C.O.O.
Concept s obj et
U.M.L.
UML : Unified Modeling Language

M.C.O.O.
Concept s obj et
U.M.L.

M.C.O.O.
Concept s obj et
U.M.L.
Buts initiaux des concepteurs d’UML

•représenter des systèmes entiers (pas uniquement logiciels)
par des concepts objets.
•lier explicitement des concepts et le code qui les implantent.
•pouvoir modéliser des systèmes à différents niveaux
•créer un langage de modélisation utilisable à la fois par les
humains et les machines.
M.C.O.O.
U.M.L.
L’objet
Entité du monde réel (ou virtuel) centralisant les données et les traitements associés.
Objet = Identité + Etat + Comportement
Identité d’un objet

Propriété qui permet de distinguer un objet par rapport aux autres sans ambiguïtés.
Distingue deux objets dont les valeurs des différents attributs sont identiques.
Etat d’un objet

Valeur de tous ses attributs à un état donné.
Un attribut est une information qui qualifie l’objet qui la contient.
Comportement d’un objet

Définit l’ensemble des opérations que l’objet peut exécuter en réaction aux messages
envoyés par les autres objets.
L’état et le comportement sont liés.
M.C.O.O.
U.M.L.
L’Objet
M.C.O.O.
U.M.L.
Communication entre objets
•Une application, en orienté objet, est une société d'objets

collaborant.
•Comment, dans ces conditions, sont réalisées les fonctions de

l'application ? Ce sont les objets, qui travaillent en synergie, pour
parvenir à les réaliser.
•Donc, l'achèvement d'une tâche par une application repose sur la

communication entre les objets qui la composent. L'unité de
communication entre les objets est le message.
M.C.O.O.
U.M.L.
Les objets ne vivent pas en ermites

M.C.O.O.
U.M.L.
Le concept de message
Il existe cinq catégories principales de messages :
•les constructeurs qui créent des objets
•les destructeurs qui détruisent des objets (pas en Java)
•les sélecteurs qui renvoient tout ou partie de l'état d'un

objet
•les modificateurs qui changent tout ou partie de l'état

d'un objet
•les itérateurs qui visitent l'état d'un objet ou tous le

contenu d'une structure de données qui contient
plusieurs objets
M.C.O.O.
Les di agr am m es des aspect s dynam i ques
U.M.L.
La notion de classe
Une classe est une abstraction qui représente un ensemble d’objets de même nature,
c ’ es t -à-di r e pos s édant l a m êm e s truc tu re s tati que (attri b u ts ) et l e m êm e
comportement (méthodes).
Exemple : classe Point2D avec les attributs x et y.
Relation entre objet et classe
Tout objet appartient à une classe et connaît de façon implicite la classe à

laquelle il appartient.
Tout objet est une instance de sa classe.

Un objet est une instance d’une et une seule classe.
Classe abstraite
Classe conçue sans instances.
M.C.O.O.
U.M.L.
La notion de classe
M.C.O.O.
U.M.L.
La notion de classe
M.C.O.O.
U.M.L.
Relations entre classes
Association
Relation entre plusieurs classes.
Elles représentent une abstraction des différents liens qui peuvent exister entre les
différents objets.
Agrégation et composition
Forme particulière d’association entre deux classes.

Exprime le fait qu’une classe est composée d’une ou plusieurs autres classes.
Spécialisation et généralisation
Le mécanisme d’héritage permet de définir de nouvelles classes à partir de classes déjà
existantes.
Généralisation : factorisation dans une classe (appellée super-classe) de

propriétés de plusieurs classes
Spécialisation : inverse de le généralisation, consiste à créer à partir d’une classe
plusieurs classes spécialisées.
M.C.O.O.
U.M.L.
Notions relatives aux composants des classes
Encapsulation
Possibilité de masquer certains détails de l’implantation. Peut -être réalisé en
particuliers par des constituants privés” des objets.
Polymorphisme
Poly = plusieurs, morphisme = forme
Caractéristique d’un élément qui peut se présenter sous plusieurs formes.
Capacité de donner à une même opération la possibilté de s’effectuer

différemment suivant le contexte de la classe où elle se trouve.
M.C.O.O.
U.M.L.
Les diagrammes d’UML
Un diagramme donne à l’utilisateur la possibilité de visualiser et de manipuler des

éléments de modélisation.
UML 2.0 comporte 13 diagrammes permettant de modéliser différents aspects d’un
système. On se focalisera dans ce cours sur les 9 diagrammes issus d’UML 1.5.
Diagrammes des aspects statiques
1 Diagramme de cas d’utilisation : représente les fonctions du système du point

de vue de l’utilisateur.
2 Diagramme de classes : définit les classes et les relations entre les classes.
3 Diagramme d’objets : définit les instances des classes, ainsi que les liens entre
ces instances.
4 Diagramme de composants : permet de décrire les composants (ou modules)
d’un système (fichiers sources, fichiers objets, librairies exécutables).
5 Diagramme de déploiement : décrit la disposition physique du matériel et la
répartition des composants sur le matériel.
M.C.O.O.
U.M.L.

Diagrammes des aspects dynamiques
6 Diagramme de séquences : représente les interactions d’un point de vue

chronologique; d’une part, les interactions entre le système et les acteurs et,
d’autre part, les interactions entre les objets à l’intérieur du système.
7 Diagramme de collaboration : représente les interactions entre objets d’un point
de vue spacial.
8 Diagramme d’états-transitions : automates hiérarchiques permettant représenter

les comportements d’un acteur, d’un système ou d’un objet d’une certaine classe.
9 Diagramme d’activités : permet de modéliser le comportement d’une méthode
en représentant un enchaînement d’activités.
M . C . O .DOi a. g r a m m e s d e c a s d ’ u t i l i s a t i o n
P r é s e n tPartéi os ne ndt ua t m
i oond du ul e mMoCdO u lOe M C O O
Mé t h o d Diagram
es d e d ém eso p
v el de classes
p em en t et d’objets
L e s d i a gL reasmdmi aegsr adme smaesspdeecst sasstpaet ci qt su esst a t i q u e s
C o n c epDt si aogbr jaet
m m es de com posants
L es d i aL
ge r as mdm i aegsrdaemsmaessp de e c st s adsypneacm t si qduyensa m i qUu .eM
s . L .D i a g r a m m e s d e d é p l o i e m e n t

4 diagrammes UML 2.0 (non traités en cours)
Diagramme de paquetages : permet de décrire les interactions entre les

paquetages (paquetage = structure logique de regroupement et d’organisation
des éléments du modèle UML).
Diagramme de structure composite : décrit sous la forme d’une boîte blanche

les relations entre les composants d’une classe.
Diagramme global d’interaction : permet de décrire les enchaînements possibles
entre les scénarios préalablement identifiés sous forme de diagrammes de
séquences.
Diagramme de temps : permet de décrire les variations d’une donnée au cours
du temps.
Di agr am m es de cas d’ut i l i sation
Pr ésent at i on du m odul e MCO O Diagram m es de classes et d’objets
Les di agr am mes des aspect s st at i ques D i a g r am m es d e c o m p os a nt s Di agr am m es
Les di agr am mes des aspect s dynam i ques de dépl oi em ent
Les aspects statiques
•Les diagrammes de cas d’utilisation

•Les diagrammes de classes
•Les diagrammes de composants
•Les diagrammes de déploiement
Les di agr am mes des aspect s st at i ques Di agr am m es de com posants
Les di agr am m esdes aspect s dynam i ques Di agr am m es de dépl oi em ent
Modélisation des besoins

Modélisation des besoins
✓ Les fonctionnalités sont modélisées par des cas d’utilisation

✓Les cas d’utilisation permettent de décrire le système du point de vue
de l’utilisateur. Ils permettent de définir les limites du système et les
relations entre le système et son environnement.
✓ Un diagramme de cas d’utilisation définit :
•Le système
•Les cas d’utilisation (fonctionnalités)
•Les acteurs
•Les liens entre acteurs et cas d’utilisation
→ Quel acteur accède à quel cas d’utilisation ?
✓ Un modèle de cas d’utilisation se définit par :
• Des diagrammes de cas d’utilisation
• Une description textuelle des scénarios d’utilisation
Exemple de diagramme d’utilisation

Cas d’utilisation et acteurs



Relation entre acteurs et cas d’utilisation

Acteurs Principaux et secondaires

Identification des acteurs

Exemple de cas d’utilisation

Relation entre cas d’utilisation

Exemple d’inclusion et d’extension

Réutilisabilité avec les inclusions et les extensions

Décomposition grâce aux inclusions et extensions

Généralisation
Relation entre acteurs

Recenser les cas d’utilisation

Exemple de diagramme d’utilisation

Description des cas d’utilisation

relation entre le diagramme des cas d’utilisation et la description

textuelle d’un cas d’utilisation.
Description textuelle
TD 1
Diagramme de cas d’utilisation
avec correction
Exercice1
Exercice1
Station
essence
Exercice2
Exercice2
Exercice3
Diagramme de cas d’utilisation complet
On cherche à modéliser un distributeur automatique de billets (DAB).
Ce distributeur sera utilisé par des clients qui veulent pouvoir choisir une
opération parmi le retrait d’argent (rapide ou normal) et la consultation du
solde de leur compte. Pour chaque opération, il faudra s’être identifié.
Le distributeur devra permettre d’éditer des tickets pour chaque
opération si l’utilisateur le souhaite. Un système central extérieur permettra
de vérifier le solde des comptes dans le cas d’un retrait important, et de
fournir les informations nécessaires dans le cas d’une consultation.
•Proposez un diagramme de cas d’utilisation pour modéliser les
fonctionnalités attendues du système DAB.
Exercice3
distributeur automatique
<<extend>> <<include>> de billets
<<include>>
<<extend>>
Exercice4
Déterminer les cas d'utilisation d'un distributeur de billets.
On considère les scénarios où un client désire retirer de

l'argent en euros ou en dollars. Il faut traiter la situation où le stock de
billets est insuffisant. On s'intéresse également à la procédure
d'identification (de la carte et du client).
Exercice4
Exercice5
Considérons la connexion d'un client à un serveur fournissant les

protocoles HTTP, mail, telnet et FTP.
Décrire les cas d'utilisation de ce serveur en fonction des
capacités de chaque protocole à transférer des données, exécuter des
commandes, identifier un client..
Exercice5
Exercice6
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.
Exercice5
Exercice7
Dans un magasin, le processus de vente est le suivant :

le client entre, passe dans les rayons, demande éventuellement des
renseignements ou procède à des essais, prend des articles (si le stock est
suffisant), passe à la caisse où il règle ses achats (avec tout moyen de
paiement accepté). Il peut éventuellement bénéficier d’une réduction.
Modéliser cette situation par un diagramme de cas d’utilisation
Exercice7
Dans un magasin, le processus de vente est le suivant :

le client entre, passe dans les rayons, demande éventuellement des
renseignements ou procède à des essais, prend des articles (si le stock est
suffisant), passe à la caisse où il règle ses achats (avec tout moyen de
paiement accepté). Il peut éventuellement bénéficier d’une réduction.
Modéliser cette situation par un diagramme de cas d’utilisation

1 MCOO Casutilisation

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

1 MCOO Casutilisation

Transféré par

Droits d'auteur :

Formats disponibles

Présentation du module MCOO

Les diagrammes des aspects statiques

Méthode de Conception Orientée

1 Présentation du Modélisation Orientée Objet

22 Les diagrammes des aspects statiques

33 Les diagrammes des aspects dynamiques

Qu'est-ce qu'un modèle ?

L'abstraction est un des piliers de l'approche objet.

Un modèle est une vue subjective mais pertinente de la réalité

Qu'est-ce qu'un modèle ?

Qu'est-ce qu'un modèle ?

M.C.O.O. qu’est-ce que c’est?

MCOO : modéliser et concevoir en utilisant les objets du monde

Historique des méthodes de développement

Les méthodes fonctionnelles (1970 - )

Architecture basée sur la décomposition fonctionnelle : peu d’évolutions possibles

Les méthodes classiques (1980 - )

➢JSD : Jackson System Development

Historique des méthodes de développement

Les méthodes objet

documente les décisions prises lors de la construction d’un système

Quelques méthodes orientées-objet

OOA : Object Oriented Analysis, Schlaer/Mellor (1988,91,93)

OMT : Obj ec t Model l i ng T ec hni que, R um baugh (1991,95 )

Unification des méthodes

Unification des méthodes

Historique de la création d’UML

1995 Début du travail sur la méthode unifiée

Unification des méthodes

Object Management Group - OMG

•Organisation internationale créée en 1989

UML : Unified Modeling Language

UML : Unified Modeling Language

UML : Unified Modeling Language

Buts initiaux des concepteurs d’UML

Identité d’un objet

Etat d’un objet

Comportement d’un objet

Communication entre objets

•Une application, en orienté objet, est une société d'objets

•Comment, dans ces conditions, sont réalisées les fonctions de

•Donc, l'achèvement d'une tâche par une application repose sur la

Les objets ne vivent pas en ermites

Il existe cinq catégories principales de messages :

•les constructeurs qui créent des objets

•les destructeurs qui détruisent des objets (pas en Java)

•les sélecteurs qui renvoient tout ou partie de l'état d'un

•les modificateurs qui changent tout ou partie de l'état

•les itérateurs qui visitent l'état d'un objet ou tous le

Relation entre objet et classe

Tout objet appartient à une classe et connaît de façon implicite la classe à

Tout objet est une instance de sa classe.

Relations entre classes

Forme particulière d’association entre deux classes.

Généralisation : factorisation dans une classe (appellée super-classe) de

Notions relatives aux composants des classes

Caractéristique d’un élément qui peut se présenter sous plusieurs formes.

Capacité de donner à une même opération la possibilté de s’effectuer

Les diagrammes d’UML

Un diagramme donne à l’utilisateur la possibilité de visualiser et de manipuler des

Diagrammes des aspects statiques

1 Diagramme de cas d’utilisation : représente les fonctions du système du point

Les diagrammes d’UML