Module: Modélisation

Orientée Objet
(volume 1)

BELASLA El Mehdi
elmehdi.belasla@gmail.com

08/05/2023 1
Structure du Cours
 Cours
 Etudes de Cas (ateliers)
 Projets de Modélisation
 TD
 TP (Enterprise Architect)

08/05/2023 2
08/05/2023 3
Contenu Du cours (volume 1)
 Modélisation
(Introduction, Définitions, Historique)

 Approche Objet

08/05/2023 4
 1 - Introduction

08/05/2023 5
Objectif d’une méthodologie
 Entrée :
une spécification floue, réduite, éventuellement
inconsistante du projet

 Sortie :
une description complète, consistante, compréhensible
 des caractéristiques
 du comportement
 du (des buts) du projet

08/05/2023 6
 Méthode Optimisant

« Une méthode est une Encadré

démarche reproductible
permettant d’obtenir des
résultats fiables » Défini
Le Capability Maturity Model (CMM) défini
par
le Software Engineering Institute (SEI)

Reproductible

Initial

08/05/2023 7
Méthodologie orientée objet
 Une méthode se présente sous la forme de phases,
associée à des concepts et notations adaptées à chaque
phase
 Les phases sont organisées dans un cycle de vie,
comprenant plusieurs phase

UML ne décrit pas de phases ou d'étapes

En fonction du type de projet, et du type de risque, il convient de
définir des étapes appropriées
Les projets Objets se caractérisent par un cycle de développement
incrémental et itératif

08/05/2023 8
Des Modèles
 Un modèle est la simplification/abstraction de la réalité

 Nous construisons donc des modèles afin de mieux

comprendre les systèmes que nous développons

 Nous modélisons des systèmes complexes parce que

nous somme incapables de les comprendre dans leur
totalité

 Le code ne permet pas de simplifier/abstraire la réalité

08/05/2023 9
Modélisation: sens plus large

Modélisation ( Analyse , Conception , Réalisation )

 Analyse ( description des besoins )

 Conception (de la solution satisfaction de ses
besoins )
 Réalisation (détail physique)

08/05/2023 10
Des Méthodes de modélisation
 L’apparition du paradigme objet à permis
la naissance de plusieurs méthodes de
modélisation
 OMT, OOSE, Booch, Fusion, …
 Chacune de ces méthodes fournie une
notation graphique et des règles pour
élaborer les modèles
 Certaines méthodes sont outillées

08/05/2023 11
Trop de Méthodes
 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é
08/05/2023 12
 Historique
Définition en cours par une UML 2.0
commission de révision
Soumission à l’OMG UML 1.x 1999-2002

UML 1.2 Juin 1998

Standardisation par l’OMG
Novembre 1997
Soumission à l’OMG UML 1.1
Septembre 1997
Soumission à l’OMG UML 1.0 Janvier 1997
Version bêta OOPSLA’96 UML 0.9 Juin 1996

OOPSLA’95 Méthode unifiée 0.8 Octobre 1995

Booch’93 OMT-2

Autres méthodes Booch’91 OMT-1 OOSE Partenaires

08/05/2023 13
Aujourd’hui
 UML est le langage de modélisation orienté objet le plus
connu et le plus utilisé au monde
 UML s’applique à plusieurs domaines
 OO, RT, Deployment, …
 UML n’est pas une méthode
 RUP
 Peut d’utilisateurs connaissent le standard, ils ont une
vision outillée d’UML (Vision Utilisateur)
 5% forte compréhension, 45% faible compréhension, 50%
aucune compréhension
 UML est fortement critiqué car pas assez formel
 Le marché UML est important et s’accroît
 UML2.0, IBM a racheté Rational !!! 14
08/05/2023
 2 – Approche Objet

08/05/2023 15
Pourquoi?
 Représentatif de la réalité

 Construction itérative (évolutif)

 Réutilisation (effort de codage et de tests en

moins)

 Simplicité (nombre d’instructions par méthode)

08/05/2023 16
Objet
Objet = état + comportement + Identité

État : Valeurs d’un objets à un moment donné (attributs)

Identité :attribut distinguant l’objet

Avion
Atterrir
Comportement : compétences (actions réactions) en vol

Décoller
Avion
Tour de
contrôle au sol
08/05/2023 17
Objets :Contraintes de réalisation

 Persistance
 Transmission
 Objets miroirs

08/05/2023 18
Communication entre objets
 Une application, en orienté objet, est une
société d'objets collaborant
 Catégories de comportements:
 Acteur
 Serveur
 Agent

Unité de communication = Message

Messages = données + contrôles

08/05/2023 19
Messages (catégories)

 Constructeurs (créent des objets)

 Destructeurs ( détruisent des objets)

 Sélecteurs (renvoient tout ou une partie de l’état d’un objet)

 Modificateurs (changent tout ou une partie de l’état d’un objet)

 Itérateurs (visitent l'état d'un objet ou le contenu d'une structure de

données qui contient plusieurs objets)

08/05/2023 20
Messages (synchronisation)
 Envoi simple Expéditeur destinataire

 Envoi synchrone Expéditeur destinataire

 Envoi dérobant Expéditeur destinataire

 Envoi minuté Expéditeur destinataire

 Envoi asynchrone Expéditeur destinataire

08/05/2023 21
Les objets ne vivent pas en ermites
Message B

Message A
Objet 1

Objet 2

Message C
Message E

Objet 4
Objet 3

Message D

08/05/2023 22
Classes d’objets
 Classe :sert à regrouper sous un même terme générique
les objets partageant la même structure de données et le
même comportement. On dit qu'un objet est une instance
d'une classe.

 La classe est séparée en deux parties :

- la spécification : décrit le domaine de définition et les
propriétés des instances de la classe
- la réalisation : décrit comment la spécification est
réalisée

08/05/2023 23
Relations entre classes (association)
Association:
 Connexion sémantique bidirectionnelle entre classes
 Abstraction des lien des liens qui existent entre les objets
instances des classes associés

Caratéristiques des associations :

 Roles
 Multiplicités
 Composantes (classes)

08/05/2023 24
Relations entre classes (agrégation)
Agrégation :
 Cas particulier d’association
 Couplage fort entre abstractions (classes)
 Une des classes joue le rôle plus importent
 Maître / esclave
 Tout / Partie
 Composé / composant

08/05/2023 25
Diagrammes des classes

Agrégation
 Une agrégation représente une
association non symétrique dans laquelle
l ’une des classes joue un rôle
prédominant par rapport à l ’autre.
Il y a agrégation lorsque:
• les objets d ’une classe « font partie » d ’un objet d ’une autre classe.
• les valeurs d ’attributs d ’une classe se propagent au niveau des objets d ’une
autre classe
• une action sur un objet d ’une classe implique une action sur les objets d ’une
autre classe
• les objets d ’une classe sont subordonnés aux objets d ’une autre classe.

08/05/2023 26
Hiérarchies des classes
 Classifications Permettent de gérer la complexité en
ordonnant les objets au sein d’arborescence de classes
d’abstraction croissante. Les classes descendantes
héritent des propriétés des classes ancêtres (exemple :
vertébrés, mammifères, hominidés, hommes).

généraliser spécialiser

une sous-classe peut être vue comme un sous-type du

type défini par la classe ancêtre
08/05/2023 27
Héritage
 L’héritage est une relation entre un élément plus
général et un élément plus spécifique. L’héritage
existe entre des classes, des packages, …
Hérite
Classe fils Classe parent
Attributs / operations()

 Utilisations principales :
 Classifications
 Construction

08/05/2023 28
Héritage: exemple

Véhicule

Véhicule Véhicule
roulant aérien Bateau

Voiture Camion Avion Hélicoptère Navire

Navire de Navire de
guerre pêche

08/05/2023 29
Héritage et redéfinition
 Une sous-classe peut spécialiser les fonctionnalités de sa super-
classe en définissant de nouveaux attributs et/ou de nouvelles
méthodes dont elle hérite de deux manières :

 en remplaçant complètement la méthode héritée par une nouvelle

implémentation

 en spécialisant la méthode héritée en proposant une nouvelle

implémentation qui réutilise celle héritée

 Exemple : calculer la surface d’un polygone, d’un quadrilatère, d’un

triangle, d’un carré, d’un rectangle, d’un triangle isocèle, d’un triangle
rectangle, ...
08/05/2023 30
Redéfinition : réutilisation
Etudiant

Nom
Prenom
Age

Affiche()

EtudiantSportif

SportPratique

Affiche() 31
08/05/2023
 Redéfinition : substitution
Principe:

Il doit être possible de substituer

n’importe quel objet d’une Sous-Classe Polygone

à n’importe quel objet instance d’une CalculSurface()

SuperClasse sans que la sémantique
du programme écrit dans les termes
de la super classe ne soit affecté Quadrilatere Triangle

CalculSurface() CalculSurface()

Rectangle Carre TriangleRectgle TriangleIsocele

CalculSurface() CalculSurface() CalculSurface() CalculSurface()

08/05/2023 32
Polymorphisme
 Idée de base : - pouvoir faire exécuter un message par
un objet dont le type varie dynamiquement

 le système doit déterminer dynamiquement l'implantation

de l'opération à exécuter

08/05/2023 33
Le polymorphisme
 Une même opération peut se traduire différemment selon l'objet sur
laquelle elle s'applique 

 Capacité d’un objet à prendre plusieurs formes.

 On parle également de liaison dynamique.

 Simplicité du code (plus besoin de distinguer les cas en fonction des classes)
 Facilité d’évolution du code (programmes facilement extensibles :on peut
redéfinir une opération appartenant à une classe dont on hérite, appartenant
à une sur-classe).

08/05/2023 34
 Polymorphisme : classes abstraites
 Pour exploiter pleinement le polymorphisme, il est courant de définir des
classes dont le seul rôle est de spécifier une interface (un ensemble de
méthodes) commune pour toutes les classes qui en seront dérivées.

 Dans de telles classes, les méthodes qui servent à définir cette interface
commune sont le plus souvent muettes (elles ne contiennent pas de
code effectif).

08/05/2023 35
Liaison dynamique : Exemple

Polygone

CalculSurface()

Quadrilatere Triangle

CalculSurface() CalculSurface()

Rectangle Carre TriangleRectgle TriangleIsocele

CalculSurface() CalculSurface() CalculSurface() CalculSurface()

08/05/2023 36
Encapsulation

Trois niveaux de visibilité :

 privé

 protégé

 public

 Cela permet de limiter les effets de bord.

08/05/2023 37
Autres différences
 La surcharge (prototype de fonctions : plusieurs méthodes portant le
même nom à l’intérieur d’une classe)

 La généricité (« template » en C++)

08/05/2023 38
Objectifs et qualités d’un
développement par objet
Attention :
 Les exigences de qualité ne sont pas les mêmes pour le
produit et pour le développement.

 Qualités essentielles d'un développement de logiciel :

 homogénéité (seamlessness !)
 simplicité
 réversibilité / traçabilité
 maintenabilité / extensibilité
 fiabilité / contractualisation

08/05/2023 39
Réutilisation et l’Orienté Objet
 Avant l'objet : réutilisation limitée au code exécutable
généralement stocké en bibliothèque => production de
composants logiciels (industrie).

 Avec l'objet : réutilisation enrichie par la classe,

l'héritage, la généricité et le polymorphisme.

 Aujourd'hui : réutilisation de l'expérience accumulée au

cours des projets

08/05/2023 40
Méthodologie orientée objet
 Processus
 Spécification initiale du système
 Analyse
 Conception du système
 Conception des classes
 Implémentation

08/05/2023 41
08/05/2023 42
 Module: Modélisation
Orientée Objet
(volume 2)

BELASLA El Mehdi
Belasla2@yahoo.fr

2006/2007
08/05/2023 43
 1 – Survol d’UML

08/05/2023 44
Éléments de modélisation

08/05/2023 45
Éléments de modélisation

08/05/2023 46
Éléments de modélisation

08/05/2023 47
Relations

08/05/2023 48
Mécanismes communs

08/05/2023 49
Types primitifs

08/05/2023 50
 2 – Notation UML

08/05/2023 51
Notation

08/05/2023 52
Les diagrammes d’UML

08/05/2023 53
Principaux diagrammes
 Diagramme de classes (Class diagram) : il représente les classes intervenant dans
le système
 Diagramme d'objets (Object diagram) : il sert à représenter les instances de classes
(objets) utilisées dans le système
 Diagramme de composants (Component diagram) : il permet de montrer les
composants du système d'un point de vue physique, tels qu'ils sont mis en œuvre
(fichiers, bibliothèques, bases de données...)
 Diagramme de déploiement : il sert à représenter les éléments matériels
(ordinateurs, périphériques, réseaux, systèmes de stockage...) et la manière dont les
composants du système sont répartis sur ces éléments matériels et interagissent
avec eux

08/05/2023 54
Diagrammes (suite)
 Diagramme des paquetages (Package Diagram) : permet de représenter la
hiérarchie des paquetages du projet, leur organisation et leurs interdépendances,
simplifie les diagrammes (donc plus simple à comprendre)
 Diagramme de structures composites (Composite Structure Diagram) : permet de
décrire la structure interne d'un objet complexe lors de son exécution (c'est à dire,
décrire l'exécution du programme), dont ses points d'interaction avec le reste du
système

08/05/2023 55
Diagrammes (suite)
 Diagramme des cas d'utilisation (Use case diagram) : il décrit les possibilités
d'interaction entre le système et les acteurs, c'est-à-dire toutes les fonctionnalités que
doit fournir le système
 Diagramme états-transitions (State Machine Diagram) : il montre la manière dont
l'état du système (ou de sous-parties) est modifié en fonction des événements du
système
 Diagramme d'activité (Activity Diagram) : variante du diagramme d'états-transitions,
il permet de représenter le déclenchement d'événements en fonction des états du
système et de modéliser des comportements parallélisables (multithreads ou multi-
processus)

08/05/2023 56
Diagrammes (suite)
 Diagramme d'interactions (Interaction Diagram) : " Diagramme de séquence
(Sequence Diagram) : la représentation séquentielle du déroulement des traitements
et des interactions entre les éléments du système et/ou des acteurs
 Diagramme de communication (Communication Diagram) : la représentation
simplifiée d'un diagramme de séquence se concentrant sur les échanges de
messages entre les objets
 Diagramme global d'interaction (Interaction Overview Diagram) : variante du
diagramme d'activité où les nœuds sont des interactions, permet d'associer les
notations du diagramme de séquence à celle du diagramme d'activité, ce qui permet
de décrire une méthode complexe

08/05/2023 57
Diagrammes (suite)

 Diagramme de temps (Timing Diagram) : la représentationdes interactions où

l'aspect temporel est mis en valeur; il permet de modéliser les contraintes

d'interaction entre plusieurs objets, comme le changement d'état en réponse à un

évènement extérieur

08/05/2023 58
Paquetages

08/05/2023 59
Diagramme de classes
 Le diagramme de classes va permettre de définir
l’ensemble des classes et les relations entre les classes
 Il représente une vue statique du système.
 Lors de la conception, on s’attachera à identifier
l’ensemble des classes du modèle et à les lier entre
elles par différents types de liens.

08/05/2023 60
Diagrammes de classes

08/05/2023 61
 Diagrammes des classes Visibilité

+ défini un attribut/opération public

Accessible à toutes les classes
# défini un attribut/opération protégé
Accessible uniquement aux fonctions de classes
héritières
- défini un attribut/opération privé
Accessible uniquement aux méthodes de la classe
elle même.

08/05/2023 62
Diagrammes de classes

08/05/2023 63
Diagrammes des classes
Les association
 Une association représente une relation
structurelle entre classes d’objets.
 On représente une association en traçant une ligne
entre les classes associées.

08/05/2023 64
Diagrammes de classes

08/05/2023 65
Diagrammes de classes

08/05/2023 66
Diagramme des classes
Cardinalités
 La CARDINALITE ( ou MULTIPLICITE) d’une
association est le nombre d’instances mises en jeu pour une
classe dans le lien avec chaque instance de l’autre classe.
 On précisera généralement la cardinalité minimum et la
cardinalité maximum.

08/05/2023 67
Diagrammes de classes

Exemple

08/05/2023 68
Exemple de cardinalité

08/05/2023 69
Diagrammes de classes

08/05/2023 70
Diagrammes de classes

08/05/2023 71
Diagrammes de classes

08/05/2023 72
Diagrammes des classes

Agrégation
 Une agrégation représente une
association non symétrique dans laquelle
l ’une des classes joue un rôle
prédominant par rapport à l ’autre.
Il y a agrégation lorsque:
• les objets d ’une classe « font partie » d ’un objet d ’une autre classe.
• les valeurs d ’attributs d ’une classe se propagent au niveau des objets d ’une
autre classe
• une action sur un objet d ’une classe implique une action sur les objets d ’une
autre classe
• les objets d ’une classe sont subordonnés aux objets d ’une autre classe.

08/05/2023 73
Diagrammes de classes

08/05/2023 74
Diagramme des classes
Composition
•La composition est une forme d ’agrégation.
•Lorsqu’il y a une relation de composition entre 2
classes, l ’existence de la classe composante est
conditionnée par celles des instances de la classe
composée.

08/05/2023 75
Diagramme de Classes
 Un diagramme de classes est un graphe
d’éléments connectés par des relations.
 Un diagramme de classes est une vue
graphique de la structure statique d’un système.
Company

Person

members
Company Employee
0..1 *

08/05/2023 76
Diagrammes de classes

08/05/2023 77
Diagrammes de classes

08/05/2023 78
Diagrammes de classes

08/05/2023 79
Diagrammes de classe

08/05/2023 80
Diagrammes de classes
 Une interface est la spécification externe (en
terme d’opérations) d’une classe.
 Une interface peut donc contenir des opérations
 Une classe réalise une interface si elle est
capable d’exécuter toutes les opérations de
l’interface
 On utilisera une relation de dépendance pour
exprimer le fait qu’une classe est cliente d’une
interface.

08/05/2023 81
Interfaces
Element
Parser
+addChild(In child:Element)
Engine
+getChildren(): [*] Element

Parser
Element
Engine

08/05/2023 82
Contraintes et Notes
 Il est possible de contraindre ou d’annoter
n’importe quel élément du modèle
 Les contraintes et les notes sont bien souvent
écrites en langage naturel
 Le langage OCL est cependant préconiser pour
décrire des contraintes
 self.age<60

08/05/2023 83
Contraintes et Notes
<<comment>>
Une association n'est pas
une company

Company Employee
* 1..*

ageLimit
{self.age<60}

08/05/2023 84
Packages
 Un package permet de grouper des
éléments
 Un package sert d’espace de désignation
 Un package peut inclure d’autres package
 Un package peut importer d’autres
package
 L’héritage entre package est possible

08/05/2023 85
Packages

08/05/2023 86
Diagramme de Classe
 Les diagrammes de classes sont les
diagrammes les plus utilisés
 Ils permettent la décrire des programmes objet
 Ils permettent de décrire le schéma logique de bases
de données
 Ils permettent de décrire des relations de concepts
(modèle métier)
 Les diagrammes de classes peuvent être de
différents niveaux d’abstraction

08/05/2023 87
 Les diagrammes des cas
d’utilisation

08/05/2023 88
Diagramme de Cas d’Utilisation
 Un diagramme de cas d’utilisation décrit des
acteurs et leurs relations avec des cas
d’utilisation
 Les diagrammes de cas d’utilisation décrivent
les fonctionnalités d’un système

08/05/2023 89
Acteurs
 Un acteur représente un utilisateur externe
du système
 Un acteur est en relation avec un ou
plusieurs cas d’utilisation
 Il est possible de définir des relations
d’héritage entre Acteurs

08/05/2023 90
Cas d’Utilisation
 Un cas d’utilisation représente une fonctionnalité
du système
 Il est possible de définir des relations de
dépendance entre cas d’utilisation
 Il est possible de définir des relations d’inclusion
entre cas d’utilisation
 Il est possible de définir des relations d’héritage
entre cas d’utilisation

08/05/2023 91
Les diagrammes de cas
d’utilisation

08/05/2023 92
Diagramme de Cas d’Utilisation
M agisterTest1

Bill customer

Place order <<include>>

Customer
Validate user
<<include>>

Ship order

<<extend>> Check Password

CommercialCustomer
Ship partial order

08/05/2023 93
Cas d’Utilisation
 Les diagrammes de cas d’utilisation sont
souvent employés
 Ils permettent de décrire le système de façon très
abstraite
 Ils offrent une vue fonctionnelle (par opposition à une
vue Orienté Objet)
 Ils sont très simples
 La difficulté consiste à passer des cas
d’utilisation aux classes

08/05/2023 94
Les diagrammes de cas
d’utilisation

08/05/2023 95
Diagramme d’Objets
 Un diagramme d’objet représente la vue
statique d’un ensemble d’instance de classes

08/05/2023 96
Diagrammes d’objets

08/05/2023 97
Diagrammes d’objets

08/05/2023 98
Diagrammes d’objets

08/05/2023 99
Diagramme de Collaboration
 Un diagramme de collaboration représente la vue
statique et la vue dynamique d’un ensemble
d’élément
 Une collaboration définit des rôles (et non pas des
classes!)

08/05/2023 100
Diagrammes de collaboration

08/05/2023 101
Diagrammes de collaboration

08/05/2023 102
Diagrammes de collaboration

08/05/2023 103
Diagrammes de collaboration

08/05/2023 104
Diagrammes de collaboration

08/05/2023 105
Diagrammes de collaboration

08/05/2023 106
Diagramme de séquence
 Le diagramme de séquence montre les
interactions entre objets tout comme le
diagramme de collaboration.
 La séquence des interactions fait ressortir
l’aspect temporel.
 Plus apte à modéliser des aspects dynamiques
de scénarios complexes mettant en œuvre peu
d’objets.
08/05/2023 107
Instances
 Un diagramme de séquence met en œuvre des instances
 Instance de classe, Instance d’acteur
 Graphiquement une instance se distingue de son type car elle
est soulignée
 Il est possible de définir des instances sans préciser leur classe
 La durée de vie des instances est définie sur l’axe vertical du
diagramme
 Graphiquement l’activité d’une instance se voit grâce à un
rectangle sur l’axe du temp

08/05/2023 108
Diagrammes de séquence

08/05/2023 109
Diagrammes de séquence

08/05/2023 110
Diagrammes de séquence

08/05/2023 111
Diagramme d’Etat

08/05/2023 112
Diagramme d’états-transitions
 Utile pour représenter le comportement
dynamique d’une classe.

 Intéressant lorsque la classe contient des états

entre lesquels un objet transite durant sa durée
de vie.

 Description des états possibles d’un objet et des

transitions en fonction des événements.

08/05/2023 113
08/05/2023 114
08/05/2023 115
08/05/2023 116
08/05/2023 117
08/05/2023 118
08/05/2023 119
08/05/2023 120
08/05/2023 121
08/05/2023 122
08/05/2023 123
08/05/2023 124
08/05/2023 125
08/05/2023 126
Diagramme d’Activité

08/05/2023 127
08/05/2023 128
Diagrammes d’activités

08/05/2023 129
08/05/2023 130
08/05/2023 131
08/05/2023 132
Notion du diagramme d’activité

Itération
08/05/2023 133
Notion du diagramme d’activité

Swimlanes

08/05/2023 134
Construction un diagramme
d’activité
1. Identifiez la portée (« scope ») du diagramme d'activité
Commencez en identifiant ce que vous allez modéliser. Un seul use
case? Une partie d'un use case ? Un « workflow » qui inclut
plusieurs use cases ? Une méthode de classe ?
2. Ajouter l’état de départ et de terminaison
3. Ajouter les activités
Si vous modélisez un use case, introduisez une activité pour
chaque use case principal. Si vous modélisez un « workflow »,
introduisez une activité pour chaque processus principal, souvent
un use case. Enfin, si vous modélisez une méthode, il est souvent
nécessaire d’avoir une activité pour chaque grand étape de la
méthode.
4. Ajouter des transitions (séquentielles), des transitions
alternatives (conditionelles), des synchronisations entre des
activités, des itérations.
5. Identifier des swimlanes et répartir des activités identifiées
dans ces swimlanes.
08/05/2023 135
Exercice 1: Cafetière
 Construire un diagramme d’activité
représentant l’utilisation d’une cafetière
électrique:
 premier état: chercher du café
 dernier état: Servir du café

08/05/2023 136
Cafetière: Solution possible

08/05/2023 137
Exercice 2: Commander un produit
 Construire un diagramme d’activité pour
modéliser le processus de commander d’un
produit. Le processus concerne les acteurs
suivants:
 Client:qui commande un produit et qui paie la facture
 Caisse: qui encaisse l’argent du client
 Vente: qui s’occupe de traiter et de facturer la
commande du client
 Entrepôt: qui est responsable de sortir les articles et
d’expédier la commande.
08/05/2023 138
Commander un Produit: Solution
possible

08/05/2023 139
Diagramme de composant
 Un diagramme de composant représente les
composants logiciels d’un système

08/05/2023 140
Diagrammes de composants

08/05/2023 141
Diagrammes de composants

08/05/2023 142
Diagramme de déploiement
 Un diagramme de déploiement représente la
façon dont déployer les différentes éléments
d’un système

08/05/2023 143
Diagrammes de déploiement

08/05/2023 144
Diagrammes de déploiement

08/05/2023 145
Pour en savoir plus

08/05/2023 146