Code : SEG-FR110505

Support de cours Version : 00

SMQ Date : 12/05/2008

Mastère spécialisé - CREMASI

M tiè :
Matière
UML: Unified Modeling Language

Intervenant : Saïd GOURRAM

gourram@yahoo.fr

Année Universitaire 2009-2010

Objectifs
OBJECTIFS
L'objectif principal de ce cours est de maîtriser la conception d'applications
logicielles d'envergure selon les principes fondamentaux du langage UML
en se basant sur les concepts de l’Orienté Objet.
Des outils de modélisation «EclipseUML» et «QSEE» sont utilisés pour
atteindre cet objectif.

À la fin du cours, l'étudiant devrait pouvoir :

9Collaborer et communiquer, en utilisant UML, avec les membres d'une équipe de
conception de logiciel dans la réalisation d'un projet complexe. Cela implique la
participation à l'élaboration d'un projet logiciel, de son cahier des charges, de son
échéancier de sa réalisation,
échéancier, réalisation de sa mise à l'épreuve
l'épre e et de sa documentation.
doc mentation
9Être en mesure de mener simultanément une démarche qui combine créativité dans
la conception de logiciel, rigueur dans la modélisation et dans l'implantation du
logiciel et dans le suivi d'un projet, et pragmatisme dans l'atteinte des objectifs d'un
projet en tenant compte de contraintes temporelles et budgétaires.

9Les illustrations seront basées sur l’étude d’un système de gestion comptable.

1
 Contenu (Conception d'applications logicielles par objets)
# Durée Date Observations
1 Gestion de projet logiciel.
2 Conception du cahier des charges,
spécification et exigences
• organisation de l'équipe de conception,
• planification des activités
activités,
• supervision du personnel de
conception et de l'avancement du
projet.
3 Outils facilitant la conception d'applications
logicielles
UML, OCL, design patherns, Methode
"Unifief sof tware process" de Jacobson ,
Booch et Rumbaugh.
4 Documentation
5 Contrôle et évaluation de la qualité
6 Vérification et validation
7 Entretien et modifications

Bibliographie
Craig Larman, "Applying UML and Patterns: An Introduction to
Object−Oriented Analysis and Design and Iterative Development", 3rd
Edition, Prentice Hall, ISBN: 0131489062, 736 pages, 2004.
Craig Larman, "UML 2 et les Design Patterns", 3e édition, Pearson
Education,, ISBN: 2744070904,, 850 pages,
p g , 2005.
Eric S. Raymond, "The Art of UNIX Programming", Addison−Wesley
Professional, ISBN: 0131429019, 512 pages, 2003.
Eric S. Raymond, "The Art of UNIX Programming",
http://www.catb.org/~esr/writings/taoup/
I. Sommerville, "Software Engineering", Addison−Wesley, 1995 (5e
Édition), 742 pages, ISBN 0−201−42765−6.

2
 Projets (max 4 / projet)
# Sujets Equipe
1
2
3
4
5
6
7
8

Modalités d'évaluation
Partie % Date
Livrable : 100
Diagramme Gantt Chart – WBS
Diagramme de cas d’utilisation (use cases)
Diagramme de classes
Diagramme d’objets
Diagramme de collaboration
Diagramme de séquence
Diagramme d’états-transitions (state-charts)
Diagramme d’activités
Diagramme de composants
Diagramme de déploiement

Livrable : électronique et sur papier le 11 mai 2010 (2 jours

avant la dernière séance).
Avec -1 par jour de retard

Equipe projet:
1. chef d’équipe
2. architecte.
3. ingénieur de conception
4. responsable de la documentation

3
 7

Mesure de la qualité du logiciel de gestion

Critère comptable
‘Avr 2010 ‘Oct 2010
Robustesse 5 5
Efficacité 2 3
Portabilité 4 4
Evolutivité 0 2
Réutilisabilité 1 2
Exactitude 3 3

4
 Robustesse
5
4
3
Exactitude Efficacité
2
1
‘Avr 2010
0
‘Oct 2010

Réutilisabilité Portabilité

Evolutivité

Emergence des TI

10

5
 Définition de la gestion de projet
Académiquement par . J.R. Meredith et S. Mantel :
• «la gestion des interfaces entre la performance, le temps et les coûts»

« Un projet est une entreprise temporaire décidée dans le but de créer un

produit, un service ou un résultat unique »
PMBOK

PMBOK : Project Management Body Of Knowledge / Management Project Institute

11

PBS : Product Breakdown Structure

Le PBS est une décomposition
Logiciel
hiérarchique et organisée du
Comptable logiciel cible

Gestion des Etats de

Editions Référentiel
Ecritures synthèse

Journal Bilan Plan Comptable

Grand Livre CPC Périodes
Balance ESG Journaux

Structuration des tâches – WBS identifiera les tâches nécessaires à la réalisation

du produit et à la conduite du projet.
L’identifier des tâches de réalisation du logiciel, dépendra de la démarche visée
(Cascade, V, Spirale), mais UML en est uniquement pour la communication.

12

6
 Projet SI
• Projet TI
– Mise en place de l’infrastructure et les aspects technologiques de la
sécurité.
• Projet de développement de logiciels
– Basé sur le cycle de vie d’un logiciel: (spécification, analyse,
conception, codage (programmation si réalisation, paramétrage si
achat d’un ERP), test, intégration, validation, formation.
• Projet multimédia
– Réalisation d’un site web ou d’un CD
• Projet SI
– Source: réorganisation
réorganisation, privatisation
privatisation, fusion,
fusion nouveau processus de
fabrication, nouveau cadre réglementaire, nouveau modèle métier.
– Se compose de plusieurs projets TI et de projets fonctionnels
(gestion du changement: documentation, formation,
accompagnement…)

13

Rappels des caractéristiques d’un projet SI

• Un projet SI est unique; ce n’est pas
une opération répétitive.

• Un projet SI est délimité; il a un début Contenu

et une fin définie.
définie

• Un projet SI est précis; il a des Objectif

objectifs clairement définis.
Délai Coût
• Un projet SI est complexe; il implique
des acteurs d’unités différentes.

• Un projet SI est risqué; il faut Risques

anticiper

14

7
 Les notions à bien maîtriser
Projet Contrainte

Délais Ressource

Durée Maître d'ouvrage

d ouvrage

Charge de travail Maître d'oeuvre

Jalon

Livrable

Phase

15

Phasing

GO or
NO GO

Contrôle

Contrôle (Suivi et gestion des demandes de changement)

16

8
 PMI : Processus et Disciplines de Gestion de Projet

Coûts Qualité

Délais Contenu

2
1 Démarrage Planification
Intégration Communication
3

Contrôle Réalisation
Approvisionnement

Clôture
4 RH
5

Risques

Adaptée et adoptée par IEEE pour la spécification SWEBOK (Software Engineering

Body of Knowledge).

17

Normes et Référentiels
Norme Domaine
ISO 10.006 Management de la qualité dans les projets
ISO 12.207 Projets de développement de logiciels
ITIL Information Technology Infrastructure Library
Référentiel de bonnes pratiques dédiées à la fourniture
de services informatiques (surtout exploitation)
CMM Capability Maturity Model
Référentiels de bonnes pratiques en matière de
développement des logiciels
(puis CMMI – intégration: plus vaste)
Cobit Control Objectives for Business and related IT)
Référentiel d’audit et de maîtrise des SI
PMBOK Project Management Body Of Knowledge
PMP: Project Management Professional (Référentiel de
certification de management des projets)
Prince2 PRoject IN Control Environment

18

9
 ISO 10.006 : management de la qualité dans les projets
(version 2003)
Domaine Sous-domaine
5 La responsabilité de la gestion. 5.2 Processus stratégique
6 Management des ressources 6.1 Processus liés aux Ressources
6.2 Processus liés au personnel
7 Réalisation du produit 7.2 Processus liés aux interdépendances

7.3 Processus liés au contenu

7.4 Processus liés à la durée

7.5 Processus liés aux coûts

7.6 Processus liés à la communication

7.7 Processus liés aux risques

7.8 processus liés aux acquisitions

8 Mesurer, analyser et améliorer 8.1 Processus liés à l’amélioration

8.2 Mesurer et analyser

8.3 Amélioration Continue

19

Le cycle de vie du logiciel

• Spécification
• Analyse
• Conception
• C d
Codage
• Test
• Recette
• Implémentation
• Revue après installation

SDLC: Software Developpement Life Cycle 20

10
 Cahier des Cycle de vie d’un logiciel
Charges

• Définitions de l'IEEE «Computer Society» :

Spécification – Le cycle de vie débute avec la spécification et s'achève
sur les phases d'exploitation et de maintenance.
– Le cycle de développement prend en compte la partie
amont (pré-étude) et s'achève lorsque le logiciel est
Conception
p C livré.
d
V • Cycle avec retour
Codage
– La maîtrise du projet conduit à une révision de
certains choix faits initialement.
– La spécification peut déceler l’irréalisation de certains
Intégration C éléments du cahier des charges (effet d’anticipation).
d – La spécification peut conduire à des modifications de
certains aspects du cahier des charges (l’utilisateur
Test D change d'avis).
– La conception peut présenter des solutions
avantageuses non prévues dans la spécification.
Utilisation – L’intégration permet de détecter des anomalies
procédurales.
– Le test offre un meilleur moyen d’observation du
système avant sa mise en service, en cas d’anomalie;
le retour aux étapes précédentes s’avère nécessaire.

Maintenance

21

Cycle de vie d’un projet S.I.

6
1 2 3 4
Etapes 5 Mise en 7
Analyse de Spécification Conception Conception
ou phases Réalisation oeuvre Maintenance
la demande projet générale détaillée
Déploiement

Temps
Dossier Dossier
Documents Schéma Dossier Code
d ’étude de de
directeur B vs B
préalable conception conception
fonctionnelle
détaillée V& V
Dossier
Etude d ’ de
opportunité planification Dossier de
Dossier
d’architecture
conception Manuels
technique utilisateurs
détaillée

Capture des besoins Formation

Décisions
Accord sur Choix d’une Accord sur les
l’inscription procédures, Recette Réception
organisation logicielle système
du projet du projet l ’architecture ...

V& V: Vérification et Validation B vs B : Buy Versus Build

22

11
 Cycle de vie de logiciel en cascade
Proposé par Royce au début des années 70.
– Dans ce modèle, chaque phase se termine à une
date précise par la production de certains documents
ou logiciels.
– on ne passe à la phase suivante que si les résultats
de l’étape précédente sont jugés satisfaisants
– D'autres activités interviennent, par exemple le
Spécification contrôle technique et la gestion de la configuration
sont présents tout au long du processus.
Analye des besoins

Conception préliminaire
Risques élevés et non contrôlés:
Conception détaillée •Identification tardive des
problèmes
Codage •Preuve tardive de bon
fonctionnement
Intégration

maintenance

23

Exemple : DFD – niveau 0

a
Etudiant e
Parent

Inscription Absences

b
0 Prof esseur
d
MEN Programm e Ecole
Contrat

Résultats
tdB
f
Directeur
Relev é Chèque
q

c
Banque

24

12
 DFD Niveau 1
a e
Etudiant Parent

Inscription
Absences

2
Inscription 3
Génération
Message

6
d Ins
Résultats Ev aluation Abs
MEN
4
Ev al f
Elaboration tdB
Programm e Directeur
de TdB
1 Direction Pédagogique
Pgm
Analy se des
Programmes
b Résultat des Analy ses
tres
Prof esseur Contrat

5
Com ptabilité

Relev é Chèque

c
Banque

25

Cycle de vie de logiciel en V

• Dès le démarrage du projet, une procédure globale de
validation est présentée et le début du processus de
développement conditionne ses dernières étapes.
• Toute
To te décomposition correspond à une ne recomposition.
recomposition
• Toute description d'un composant est accompagnée de
tests qui permettront de s'assurer qu'il correspond à sa
description.
• Ceci rend explicite la préparation des dernières phases
(validation-vérification) par les premières (construction du
logiciel),
g ),
• Le cycle en V est le cycle qui a été normalisé
• Cette démarche est largement utilisée pour les grands
projets qui font appel à plusieurs équipes de différents
niveaux de décision.

26

13
 Cycle en V dans le développement d’un SI

Branche conception Branche réalisation

Etude Plan de tests en service Mise en
d’opportunité charge
Spécifications
de domaine

Plan de tests de recette Validation

Spécification Dossiers de
Spécifications validation
Conceptuelles
Plan de tests
Conception d ’intégration Intégration
générale
Spécifications Plan de
Logiques tests
Conception unitaires Tests
Difficultés :
détaillée unitaires
• hypothèses difficiles à
Spécications respecter
Techniques
de Réalisation
• difficulté à prendre en
compte des évolutions du
Codage cahier des charges
des • visibilité tardive des
modules résultats
• peu ou pas de
maquettage et/ou de 27
t t

Cycle de vie de logiciel en Spirale

Proposé par B. Boehm en 1988.
• Il met l'accent sur l'activité d'analyse des risques: chaque
cycle de la spirale se déroule en quatre phases :
1. détermination, à partir des résultats des cycles précédents ou de
l'analyse préliminaire des besoins, des objectifs du cycle, des
alternatives pour les atteindre et des contraintes;
2. analyse des risques, évaluation des alternatives et, éventuellement
maquettage ;
3. développement et vérification de la solution retenue, un modèle
«classique» (cascade ou en V) peut être utilisé ici ;
4. revue des résultats et vérification du cycle suivant.

28

14
 Logiciel et Génie logiciel
Evaluer les alternatives;
Déterminer Identifier et résoudre les
Les objectifs, Analye risques
Les alternatives Des risques
et les contraintes
Analye
y
Des risques
Analye
Des risques
Analye Prototype
des risques Prot Prot opérationnel
Revue 2
prototype1 3
Planification
Simulation, modèles et
Des besoins et Concept Tests de performance
Du cycle de vie De l’opération
Conception
Plan de détaillée
Validation
développement Des besoins code
Plan de test et Test
D’intégration Test unitaire
Test D’intégration
Mise en Développer
D’acceptation
Planification de la service
Et vérifier le produit
Prochaine phase De prochain niveau

29

Exercice d’Application
• Il s’agit de concrétiser la méthode en spirale pour la
réalisation d’un système d’information Comptable.
• Il est demandé de spécifier ce qui suit:
1 Les membres de l’équipe
1. l équipe projet
– Ressources
– Fonctions (au sein du projet)
– Compétences (pour le projet)
2. Les étapes du projet

30

15
 Merise: 3 Niveaux d’abstraction
Axe d’abstraction et 2 Domaines
Statique Dynamiqu
e
Niveau Quoi, Pourquoi
conceptuel MCD MCT

Niveau Qui, Où, Quand

MLD MOT
logique organisationnel

Niveau Comment
physique Base de Données Codes de Programme

Domaine des Données Domaine des Traitements

Axe des Domaines

31

Exercice
• Préciser les différents traitements et données cités ci-
dessous:
– Un client lance une commande, en se basant sur le catalogue
f
fournii par l’l’entreprise
t i d de di
distribution;
t ib ti ett en précisant
é i t lles quantités
tité
d’articles. Sachant que le prix est déterminé selon la quantité en
stock.

Informations: Traitement:

32

16
 Exercice
• Préciser les différents traitements et données cités ci-
dessous:
– Un client lance une commande, en se basant sur le catalogue
f
fournii par l’l’entreprise
t i d de di
distribution;
t ib ti ett en précisant
é i t lles quantités
tité
d’articles. Sachant que le prix est déterminé selon la quantité en
stock.

Données: Traitement:
9 Article 9 Consulter catalogue
9 Client 9 Déterminer prix
9 Commande 9 Commander

33

Approches fonctionnelles de MERISE

• Merise est une méthode d'analyse et de conception de
systèmes d'information, élaborée durant les années 1978 et
1979, conçue par un ensemble de sociétés de service, sous
l'égide du ministère de l'industrie français

• Merise couvre tout le cycle de vie du logiciel: schéma

directeur, étude préalable, étude détaillée, étude technique,
production de logiciels, mise en oeuvre, maintenance

• La méthode préconise la séparation entre

– les modèles de données, analysés avec une approche
entité association
entité-association,
– et les modèles des traitements, présentés avec un
formalisme proche de celui des réseaux de Petri

• La méthode conduit à réaliser les six modèles

– MCD,MCT, MLD, MOT, MPD, MPT.

34

17
 35

Quelques réalités
• Réalité de l’utilisateur:
– Une définition insuffisante des besoins des usagers est la cause majeure d'un
logiciel de mauvaise qualité et en retard.
– Les coûts pour un changement au logiciel pour corriger une erreur augmente
dramatiquement dans les dernières phases de la vie d'un
d un logiciel.
logiciel

• Réalité du développeur
– 50%-70% de l'effort consacré à un programme se produit après qu'il a été livré à
l'usager.
– Les revues de logiciel peuvent être plus efficaces pour détecter les erreurs que
les jeux d'essais.
– Une configuration de logiciel inclut de la documentation, des fichiers de
régénération,
g , des données d'entrée pour
p des tests,, et les résultats des tests sur
ces données

• Réalité du gestionnaire
– Les standards sont-ils utilisés, appropriés et complets.
– Il faut plus que des outils pour réaliser de la qualité. Il faut une meilleure pratique.
– Le développement du logiciel n ’est pas une activité mécanique.

36

18
 Besoins
Un besoin est toute expression sur le comportement du système dans
l’environnement organisationnel de son fonctionnement, tels que:
- Une exigence usager
- Une contrainte fonctionnelle
- Une contrainte non fonctionnelle
- Un but organisationnel

Typologie des besoins

- Besoins fonctionnels : ce que le système doit faire
- Besoins non fonctionnels : sous quel contrainte le système doit
le faire
Exprimer Quoi?
¾ Les objectifs, stratégie d’évolution à atteindre en utilisant le
nouveau système
¾ Les problèmes métier issus d’utilisation du système actuel
(démarche, performance, outils de supports, …)
¾ Les attentes de la part du nouveau système et les besoins en
terme de solutions
37

Expression et cahier des charges

• Expression des besoins
– Elle est du ressort du MOA, elle suit les étapes suivantes:
• Recueil des besoins auprès des utilisateurs
• Établissement
tab sse e t et cchoix
o d d’un
u object
objectif g
global
oba
• Mise en forme des besoins, afin qu’ils soient
suffisamment précis et compréhensibles par le maître
d’œuvre.
– Les besoins sont exprimés dans un cahier des charges.

• Cahier des charges

– Fixe les obligations réciproques du MOA et du MOE, il est
un recueil de caractéristiques que présentent un produit en
cours d’étude ou de réalisation. À partir d’un cahier de
charges, un MOA doit pouvoir s’engager sur un budget, un
délai et un contenu.
– Le cahier des charges est établi à la fin de l’étude préalable.
38

19
 Problèmes d’expression des besoins
• Les problèmes liés à l’expression des besoins peuvent être
source de litiges entre le MOE et le MOA.

Question a se poser :
– Les besoins formalisés par le MOA sont-ils exhaustifs ?
– Sont ils compréhensibles par le MOE?
– Le MOA à t-il les moyens nécessaires pour valider la solution ?

• Les solutions :
– Utilisation de méthodes d’analyse et de spécification des besoins
– Adaptation du cycle de développement du projet aux caractéristiques du
domaine
– Utilisation d’un langage commun fondé sur les modèles
– Adoption d’un langage commun et par une participation accrue des 2
parties.

39

Rédaction du cahier des charges

• Description générale du futur SI
– Objectif du futur SI
– Frontières du domaine d’étude avec d’autres domaines
– Collaboration avec d’autres domaines
– Décomposition en sous-domaines
– Les décideurs du SI
– Les principes de reconfiguration du SI
• Description détaillée du futur SI, pour chaque sous-systèmes identifié:
– Les fonctionnalités, service du système (ex. utilisation use case)
– Qualification de chaque fonctionnalité (métier, support, pilotage)
– Description de chaque fonctionnalité (use case, scénarios, diagrammes de
séquence, diagramme d’activité)
– La structure statique sous forme d’un diagramme de classe, description de
chaque attribut.
– Le cycle de vie (stats charts) de chaque entité de gestion
• Description des interfaces homme-machine
– Maquettes papier
– Formulaire, menus
– Graphisme
– Liens de navigation
– Prototype réalisé à l’aide d’un outil
40

20
 Expression des besoins et cahier des charges
1- Recherche, identification et expression du besoin
Réunir le maximum d'informations sur le système d’information actuels et futur, pour bien
définir la cible. L'expression du besoin nécessite de répondre aux questions suivantes :
9 Quelles sont les fonctionnalités du système ?
9 Quels sont les documents et les données manipulés ?
9 Quelles sont les procédures utilisées ?

2- Traduction des besoins en « fonctions à assurer »

Une fonction exprime le besoin des utilisateurs en terme de finalité, mais aussi les
contraintes de l'environnement du projet.
La fonction principale est la fonction pour laquelle le système est créé.
Les fonctions secondaires traduisent des besoins complémentaires et sont liées à des
utilisations particulières.

3- Hiérarchisation des fonctions et définition de critères d'appréciation des fonctions.

4- Rédaction du cahier des charges fonctionnel : le contenu du cahier des charges

fonctionnelles s'articule autour des quatre paragraphes suivants :
¾ La présentation générale du problème.
¾ L'énoncé fonctionnel du besoin.
¾ L'appel à variantes.
¾ Le cadre de réponse

41

Les Comptes-rendus
Compte-rendu de développement Compte-rendu concernant les
¾Fournitures relatives au domaine cible procédures d’assurance qualité
¾États d’avancement ¾Enregistrement des procédures
¾Effectifs utilisés et coûts d’assurance qualité
¾Ressource du MOA impliquées ¾Fourniture concernée
¾Ressources du MOE impliquées ¾Protocole des p
procédures
d’assurance qualité
¾Infrastructure utilisée
¾Évaluation de l’assurance qualité
¾Description des procédures
d’assurances qualité
¾Déviation par rapport au plan de Compte-rendu de gestion des
développement configurations
¾Proposition d’actions correctives ¾Fourniture relatives au domaine cible
concerné
¾Propositions de modification du plan
de développement
pp ¾Demande de modification concernant
ces fournitures
f it

Compte-rendu de gestion de projet

¾État d’avancement du projet
¾Déviation par rapport au plan de base
¾Question concernant le projet

42

21
 UML: Orientée Objet et ses 9 diagrammes
(puis 13 en version UML 2.x)

43

Approche orientée objet d’UML

• UML est la forme contractée de Unified Modeling Language qui peut se
traduire en français par langage unifié pour la modélisation

• C'est un langage de modélisation objet

• Il fournit les fondements pour spécifier, construire, visualiser et décrire les

composants d'un système logiciel

• UML se base sur une sémantique précise et sur une notation graphique
expressive. Il permet de modéliser de manière claire et précise la
structure et le comportement d'un système indépendamment de toute
méthode ou de tout langage de programmation

• La notation UML repose sur plusieurs diagrammes adaptés au

développement logiciel pour les phases de spécification, conception et
implémentation du cycle de vie. Certains de ces diagrammes peuvent être
tracés dans différentes phases de développement, d'autres sont plus
spécifiques à une phase donnée. Par exemple, les cas d'utilisation sont
bien adaptés à la formalisation de l'analyse des besoins.

44

22
 Exercice
• Préciser les différents objets avec les actions associées
cités ci-dessous:
– Un client lance une commande, en se basant sur le catalogue
f
fournii par l’l’entreprise
t i d de di
distribution;
t ib ti ett en précisant
é i t lles quantités
tité
d’articles. Sachant que le prix est déterminé selon la quantité en
stock.

45

Exercice
• Préciser les différents objets avec les actions associées
cités ci-dessous:
– Un client lance une commande, en se basant sur la catalogue
f
fournii par l’l’entreprise
t i d de di
distribution;
t ib ti ett en précisant
é i t lles quantités
tité
d’articles. Sachant que le prix est déterminé selon la quantité en
stock.

Objets (Actions)
9 Article (gérer, déterminer_prix, scanner)
9 Client (gérer, contacter, editer_stat, commander)
9 Commande (gérer, valider, livrer, suivre)
9 Société de distribution (gérer, fournir)

NB. : Gérer: créer, consulter, modifier, supprimer, lister, archiver

46

23
 47

UML
Unified Modeling Language

Outil d’Analyse et de
Modélisation
des Systèmes
y d’Information
S. Gourram
gourram@yahoo.fr

48

24
 UML: définition
• UML est un langage formel basé sur des concepts
orienté-objets
– gain de précision
– encourage l'utilisation d'outils
• UML est un support de communication performant
– Il cadre l'analyse
– Il facilite la compréhension de représentations abstraites
complexes
• Dans le cadre de la modélisation d'une application
informatique, 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.

49

Historique SOAML Nov 2008

UML 2.1.2 Nov 2007

Définition des versions par l’OMG 13 diagrammes UML 2.0 Oct 2004
(Object Management Group)
9 diagrammes 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
OOPSLA 95 Méthode unifiée
nifiée 0
0.8
8 Octobre 1995

Booch’93 OMT-2

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

50

25
 Exercice: Définir les aspects statique et dynamique des objets
Aspect Statique Objet Aspect Dynamique

Écriture
Comptable

Salarié

Article en Stock

51

Exercice: Définir les aspects statique et dynamique des objets

Aspect Statique Objet Aspect Dynamique
9 Sens (Débit/Crédit) 9 Gérer
9 Montant Écriture 9 Valider
9 Date 9 Envoyer
Comptable
9 Référence 9 Archiver
9 Libellé 9 Scanner
9 …

9 Nom 9 Gérer
9 Adresse 9 Affecter travail
9 ID 9 Affecter prime
Salarié
9 Date Recrutement 9 Former
9 CIN 9 Licencier
9 CNSS 9 Départ
9 Salaire de Base …
9 Référence 9 Gérer
9 Désignation 9 Stocker
9 Quantité en stock 9 Commander
9 Prix Article en Stock 9 Livrer
9 Qualité 9 Facturer
9 Scanner …

52

26
 Axes de modélisation d’un système
Statique (ce que le système EST)

• diagramme de classes
• diagramme d’objets
• diagramme de
composants
• diagramme de
Dynamique déploiement
(comment le système
EVOLUE) Fonctionnel
(ce que le système FAIT)
• diagramme de séquence
• diagramme de collaboration • diagramme de cas d’utilisation
• diagramme d’états- • diagramme de collaboration
transitions
• diagramme d’activités
53

Diagrammes et Vues
Use Case
Class Diagrams
Diagrams Deployment
Diagrams
Objects
Diagrams
Structure Implémentation

Utilisateur

Sequence Comportement Environnement

Diagrams

Collaboration Component
Diagrams Diagrams
Activity
Statechart Diagrams
Diagrams

54

27
 Les diagrammes UML
1. Le diagramme de cas d’utilisation (use cases):
représentation des fonctions du système du point de vue de l’utilisateur
(acteurs)

2. Le diagramme de classes :
représentation de la structure statique en terme de classes et de relations

3. Le diagramme d’objets :
représentation des objets et de leurs relations, correspond à un diagramme
de collaboration simplifié, sans représentation des envois de message

4. Le diagramme de collaboration :
représentation spatiale des objets, des liens et des interactions. Il montre
les interactions entre les objets en insistant sur la structure spatiale statique
qui permet la mise en collaboration d’un
d un groupe d’objets
d objets.

5. Le diagramme de séquence :
représentation temporelle des objets et de leurs interactions. Il montre les
objets participants à l’interaction par leur « lignes de vie » et les messages
qu’ils échangent, ordonnancés dans le temps. Il ne montre pas les
associations entre objets.

55

Les diagrammes UML

6. Le diagramme d’états-transitions (state-charts):
représentation du comportement d’une classe en terme d’états. Il
visualise des automates d’états finis du point de vue des états et des
transitions.
Les transitions sont déclenchées par des instances d’événements.

7. Le diagramme d’activités :
représentation du comportement d’une opération en terme d’action. Il
représente l’état d’exécution d’une méthode sous la forme d’un
déroulement d’étapes.

8. Le diagramme de composants :
représentation des composants d’implémentation et leurs relations. Il
s’attache à l’architecture logicielle d’une application en termes de
modules.

9. Le diagramme de déploiement :
représentation du déploiement des composants sur les dispositifs
matériels.
Il s’attache à l’architecture physique et matérielle.

56

28
 Nouveaux diagrammes UML 2.x
• Diagramme des paquetages (cf. Package Diagram) : un paquetage étant un
conteneur logique permettant de regrouper et d'organiser les éléments dans
le modèle UML, le Diagramme de paquetage sert à représenter les
dépendances entre paquetages, c’est-à-dire les dépendances entre
ensembles de définitions.

• Diagramme de structure composite : permet de décrire sous forme de boîte

blanche les relations entre composants d'une classe.

• Diagramme de communication : représentation simplifiée d'un diagramme

de séquence se concentrant sur les échanges de messages entre les
objets.

• 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 (variante du diagramme d'activité).

• Diagramme de temps : permet de décrire les variations d'une donnée au

cours du temps.

57

Exemple de séquence de création des diagrammes

Diagramme étape
1. Diagramme de cas d'utilisation
2. Diagramme de séquence Spécification, cahier des charges
3 Diagramme d'activité
3. d'acti ité (processus
(process s métiers)
4. Diagramme d'activité
5. Diagramme de classe
6. Diagramme d'objet
Conception Architecturale
7. Diagramme de communication
8. Diagramme de déploiement
9 Diagramme de composant
9.

58

29
 59

Le diagramme de cas d’utilisation

9 Le «Diagramme de cas d’utilisation » permet aux utilisateurs de décrire les
fonctions du système qu’ils désirent utiliser en effectuant une délimitation du
système et en décrivant son comportement.
9 Deux concepts fondamentaux interviennent :
9 Les acteurs : utilisateurs du système (qu’ils soient humains ; logiciels ou automates)..

Package
Client

9 Les uses cases : utilisations du système

«utilise»

Nom de la relation
Un cas
d’utilisation
«étend»
Nom de l’acteur
Nom du cas d’utilisation

60

30
 Exemple de Cas d’utilisation
Gestion Commerciale

Recevoir Bon de
Commande F Commander
Fournisseur

Client

Vérifier Régler
le Stock
Controleur

Imputation
Gérer le Comptable Packages Gestion
Stock Comptable

Magasinier Traiter les

Exécuter les
Entrées
Livraisons C

Livreur
Traiter les
Saisie des Livraisons
Sorties
Exécutées

61

Exemple Gestion d’un Ecole

Gestion Ecole
+ Ecrit
+ Inscription
+ Présentation Support
+ Etudiant
+ Professeur

+ Présentation Evaluation
+ Evaluation + Oral

+ Binome
<<extend>>
+ TP

+ Correction

+ Directeur
+ Informer absence
+ Parents
+ Tableau de Bord

+ Informer Résultat

+ Commission d'Orientation
+ Présentation Dossiers + MEN
+ Orientation
Dossier

62

31
 Relation « Include »
• Découpage fonctionnel d’un cas d’utilisation en plusieurs « sous
cas d’utilisation ».
• Objectif : mise en facteur d’un cas d’utilisation (commun à
d’autres cas d’utilisation).
• Comme
C il n’a
’ pas d’
d’acteur dé
déclencheur
l h ou receveur
d’évènement, le cas d’utilisation inclus n’est pas un vrai cas
d’utilisation
+ Présenter Support
<<include>>

+ Professeur + Envoyer Message

<<include>>

+ Présenter Evaluation

63

Relation « Extend »
• Extend présente une sémantique métier (alors que
include et généralisation sont des artifices
d’informaticiens).
• X étend Y si X est appelé lors de l’exécution
l exécution de Y
(on dit X est un complément facultatif du Y.

Y X

+ Imputer Ecriture + Mettre à Jour Solde du Compte

<<extend>>

64

32
 Exercice: Paiement de Chèque
Élaborer le Diagramme d’utilisation décrivant le processus suivant:
• Un guichetier d’une banque a pour activité l’accueil et le traitement des
chèques émis par sa banque.
• A la rencontre du client, le guichetier présente les informations d’ordre
organisationnel et jamais d’ordre décisionnel pour lesquelles, il fait
appell à son responsable bl quii suitit lla procédure
éd avec lle client.
li t
• Dans le cas d’une demande de paiement de chèque émis par sa
banque, le guichetier demande la présentation de l’identité du client
afin de vérifier s’il n’est pas mineur. Puis procède aux actions
suivantes:
– Saisie des informations du chèque et du client
– Si la signature n’est pas conforme avec la signature affichée par l’ordinateur, il rejette
le paiement
– Si le compte est opposé, il rejette le paiement
– Si le chèque est déclaré perdu
perdu, il fait appel à son responsable pour le suivi de
l’opération et il rejette le paiement
– Si le solde du client n’est pas suffisant, il procède à une déclaration d’incident de
paiement du chèque, et il rejette le paiement
– L’ordinateur imprime un reçu de paiement, qui doit être signé par le client
– Il procède au paiement effectif du chèque

65

Guichet
Analyse du système guichet
+ Responsable + Accueil
+ Info Décisionnelle

<<include>>

+ Guichetier + Info Organisationnelles

+ Demande
e a de Information
o a o
<<include>>

+ Clien

+ Traitement Chèque

+ Comptabilité + Contrôle de Forme

+ Ctl Solde <<incl ude>>

Cpta + Présenter Chèque

<<include>>

+ Contrôle de Fond <<include>>

+ Signature + Ctl Signature <<incl ude>>

Sign

<<include>>
+ Paiement

+ Opposition + Ctl Opposition

Oppo

66

33
 67

Diagramme de classes
Nom classe
• Un diagramme de classe inclut : Attributs
¾ Des classes, qui représentent les concepts de nom_Attribut :type
base (client, compte, produit, etc.).
Opérations
nom_opération (list-arg): type
¾Des attributs, qui décrivent les retour
caractéristiques des classes et, dans
certains cas, des associations.
Exemple de Classe:
¾ Des opérations, qui peuvent être ETUDIANT
effectuées sur les objets de la classe. + Num CNE : char10
+ Nom : String
¾ Des associations,
associations qui définissent les relations + Prénom : String
entre les différentes classes
+ Gérer ()
+ Inscrire ()
Notation de la visibilité des attributs et des opérations : + Evaluer ()
Public, ‘+’ : L’élément est visible par tous
Protégé, ‘#’ : L’élément est visible par les sous-classes
Privé, ‘-’ : L’élément est visible à la classe seule

68

34
 Exercice
z Cahier des charges:
– Un commerçant propose à ses clients des articles de différentes
marques.
– Il envoie les factures par courrier à l’adresse du client,
client cette adresse est
déterminée lors de la première relation commerciale.
1. Identifier les classes de ce « cahier des charges »
2. Dessiner les différentes classes présentes dans ce domaine de gestion,
en proposant pour chaque classe:
– Des attributs,
– Des opérations

69

Première forme normale (1NF)

1FN a pour but d'éliminer les propriétés qui possèdent
plusieurs valeurs.
• On dit qu’un objet est en 1ere FN si :
1. toutes les propriétés sont atomiques
2 toute entité a un identifiant
2.
3. toutes les propriétés qui sont en dehors de l’identifiant (la clé)
dépendent fonctionnellement de l’identifiant
l’identifiant.
• Exemple :

Etudiant Etudiant
normaliser Matière
Num CNE N10 Num CNE N10
Code Matière N3
Nom Prénom TXT40 Nom TXT30
Lib Matière A20
Matières A20 Pé
Prénom TXT30
Date Nais D Date Nais D

1.« Nom Prénom » non atomique,

2.« Matière » ne dépend pas fonctionnellement du « N° CNE ».

70

35
 Deuxième forme normale (2NF)
2FN a pour but d'éliminer les propriétés qui ne dépendent
pas ou partiellement de l’identifiant.
• On dit qu’un objet est en 2ème FN si :
1. il est déjà en 1ère FN
2 chaque propriété dépend de la totalité de ll’identifiant
2. identifiant
identifiant.
• Exemple :
Commande
Num Client N5
Réf Produit A6
Mnt Commande DC13,2
Adr Client TXT60

Commande Produit
Client
Num CommandeN6 Réf Produit A6
Num Client1 N5
Mnt Commande DC13,2
Adr Client TXT60

71

Troisième forme normale (3NF)

3FN a pour but d'éliminer les propriétés qui dépendent d’une
propriété autre que l’identifiant.
• On dit qu’un objet est en 3ème FN si :
1. il est déjà en 2ère FN
2
2. toutes les propriétés qui sont en dehors de ll’identifiant
identifiant sont en dépendance
l’identifiant..
fonctionnelle élémentaire et directe avec l’identifiant
• Exemple :
Voiture
Matricule A10
Marque TXT15
Modèle TXT15
Puissance N5
Date Circ D
Poids Vide N5

Modèle
Voiture Marque
Code Mod TXT5
Matricule A10 Code Mque TXT5
Désignation Ml TXT15
Date Circ D Désignation Mq TXT15
Puissance N5
Poids Vide N5

72

36
 Association
• Relation structurelle entre classes d ’objets
• L’association est une relation sémantique ayant une syntaxe spécifique

Direction d’association Sens de lecture

Nom d’association Multiplicité

Salarié Entreprise
Est Employé Chez > 0..1
*
Employé Employeur

Rôle Orientation

73

Association / Multiplicité
Un devoir correspond
DEVOIR à une matière
MATIERE
+ Code Dev : char 3
+ Intitulé : Stringg 1 + Code Mat : char 3
+ Date : Date + Lib Mat : String
+ Heure : int 4
*
+ Gérer Mat ()
+ Gérer Dev ()

Une matière
correspond à
plusieurs devoirs 1 Un et un seul

La multiplicité: 0..1 Zéro ou un

• est une information portée par le
M..N De M à N (entiers naturels)
rôle
• est une expression entière bornée * De zéro à plusieurs
Les valeurs de multiplicité expriment les
0..* De zéro à plusieurs
contraintes liées au domaine de
l ’application 1..* D ’un à plusieurs

74

37
 Exercice : Déterminer les Multiplicités pour Diagramme des Classes Suivant
Livre
Editeur

Facture

Auteur

Magasin de Vente
Personnel

75

Associations –Détail-
Intérêt des rôles: Éléments associés triés:
Cours Enseignant Personne Salarié Poste
* 1..*
Ordonné
Étudiant

L’Agrégation indique que l’une des classes La Composition indique que le composant
contient l’autre. n’existera plus si le composé est supprimé

Ecole Etudiant Facture 1..1 Ligne Facture

1..1 1..* 1..*

Classe d’association (Porteuse de donnée): Association récursive

Étudiant Devoir Personne 1..1
* *
Père

+Note : int Fils 0..*

76

38
 Généralisation / spécialisation, héritage, hiérarchie (is a, est un)

• Une classe héritière est une spécialisation de sa classe mère

• Toutes les propriétés d’une super-classe sont reproduites pour la
classe héritière (attributs, opérations et associations)

77

Recherche des classes (3)

• L’approche « séparation modèle

modèle--vue » (model-view-
controller) est aussi une excellente approche pour bien
séparer les classes associées à chaque couche

Présentation View

Domaine Controller

Domaine Model

78

39
 Types classiques de classes
• Entity:
Entity servent à modéliser des catégories d ’objets
quii ontt une durée
d é ded vie t t dans
i importante
i d lle
système (i.e. elles sont des parties intégrantes du
système)
• Boundary
Boundary: servent à faciliter la communication des
classes Entity avec l ’extérieur du système (soit un
autre système, avec l ’utilisateur ou encore avec un
périphérique)
• Control
Control: servent à coordonner les échanges de
messages entre les autres classes pour réaliser un
Use case

79

Cas: Système de Gestion Commerciale

Il s’agit d’élaborer un Diagramme des Classes à partir du cahier des charges
textuel suivant:
• L’agent de comptoir reçoit les clients et leur présente le catalogue pour le
choix d’articles qu’ils désirent acheter.
• Une fois que le client décide de la liste des quantités des articles qu’il désire
acheter peut demander l’élaboration
acheter, l élaboration d’un
d un devis; et si le montant global lui
convient ce devis se transforme en commande puis en livraison et finalement
en facture et en règlement.
• Ces différents documents commerciaux se ressemblent en forme et en
contenu, ils présentent:
1. Entête: les informations qui y figurent sont: la raison sociale de la société, le logo, la date, le
nom du document (devis, commande, …), le matricule du client, son adresse et la devise. Le
numéro et la devise restent fixes pour tout document commercial avec ses différents types
(devis, commande, …).
2. Corps: constitué des lignes du document; pour chaque ligne est déterminée la référence d’un
article sa désignation
article, désignation, la quantité
quantité, le prix unitaire,
unitaire la remise
remise, le prix total
total.
3. Pied: les informations qui y figurent sont: les totaux des prix et des remises, le taux de la TVA
(qui peut changer), la montant de la TVA, le montant net et une ligne d’observation. Et sur la
dernière ligne l’adresse et les référence de l’entreprise.

80

40
 PROJET
• Elaborer le diagramme de classe spécifique au projet

81

Diagramme de séquence
• Chaque cas d'utilisation apparaît comme un scénario, décrit par un ou plusieurs
diagrammes de séquence.
• Un diagramme de séquences montre les interactions entre les acteurs, le système et
les objets selon un point de vue temporel pour accomplir une fonctionnalité attendue du
système (un cas d ’utilisation). C’est une ensemble de messages échangés entre les
acteurs et le système
système, ordonnés chronologiquement.
chronologiquement

Système
Message (Comptable
Comptable

Ecriture

Contrôle
Résultat du Contrôle

Validation

82

41
 Interactions entre les objets (messages)
• En programmation orientée
objet les interactions entre
objet,
les objets sont modélisées
comme des messages Synchrone
envoyés d ’un objet à un
autre Asynchrone
• Ces messages sont
simplement des appels Simple
d ’opérations
p d ’un objet
j p par Synchrone
un autre avec le contrôle qui avec retour
revient à l ’objet appelant immédiat
avec une valeur de retour

83

Diagramme de séquence
(en réalité: après diagramme de classe et d’objet)

84

42
UML Sequence Model

: Professeur

Administrateur / Saisie des Données : aa Eudiant : Etudiant Dev001 : Devoir

[Vraie] Données()

abc()

aa()

ac()
aaabb()

aab()

aah()
aaaa()

85

Exercice: Paiement de Chèque

Élaborer le Diagramme de séquence décrivant le processus entre le
client et le guichet (que nous désirons automatiser dans sa totalité):
• Un guichetier d’une banque a pour activité l’accueil et le traitement des
chèques émis par sa banque.
• A la rencontre du client, le guichetier présente les informations d’ordre
organisationnel
g et jjamais d’ordre décisionnel p
pour lesquelles,
q , il fait
appel à son responsable qui suit la procédure avec le client.
• Dans le cas d’une demande de paiement de chèque émis par sa
banque, le guichetier demande la présentation de l’identité du client
afin de vérifier s’il n’est pas mineur. Puis procède aux actions
suivantes:
– Saisie des informations du chèque et du client
– Si la signature n’est pas conforme avec la signature affiché par l’ordinateur, il rejette le
paiement
– Si le compte est opposé, il rejette le paiement
– Si le chèque est déclaré perdu, il fait appel à son responsable pour le suivi de
ll’opération
opération et il rejette le paiement
– Si le solde du client n’est pas suffisant, il procède à une déclaration d’incident de
paiement du chèque, et il rejette le paiement
– L’ordinateur imprime un reçu de paiement, qui doit être signé par le client
– Il procède au paiement effectif du chèque

86

43
 Diagramme de Collaboration
• Comme les diagrammes de séquence : interactions entre objets du système
avec un accent particulier sur la structure spatiale statique des objets
(contexte des objets). Les messages peuvent être numérotés pour indiquer
l ’ordre des envois.
• Message: Simple, Asynchrone, Synchrone,, Minuté

Types de message

87

Exercice: Paiement de Chèque

Élaborer le Diagramme de Collaboration décrivant le processus suivant:
• Un guichetier d’une banque a pour activité l’accueil et le traitement des
chèques émis par sa banque.
• A la rencontre du client, le guichetier présente les informations d’ordre
organisationnel et jamais d’ordre décisionnel pour lesquelles, il fait
appel
pp à son responsable
p q
qui suit la p
procédure avec le client.
• Dans le cas d’une demande de paiement de chèque émis par sa
banque, le guichetier demande la présentation de l’identité du client
afin de vérifier s’il n’est pas mineur. Puis procède aux actions
suivantes:
– Saisie des informations du chèque et du client
– Si la signature n’est pas conforme avec la signature affiché par l’ordinateur, il rejette le
paiement
– Si le compte est opposé, il rejette le paiement
– Si le chèque est déclaré perdu, il fait appel à son responsable pour le suivi de
l’opération et il rejette le paiement
– Si le solde du client n’est
n est pas suffisant
suffisant, il procède à une déclaration d’incident
d incident de
paiement du chèque, et il rejette le paiement
– L’ordinateur imprime un reçu de paiement, qui doit être signé par le client
– Il procède au paiement effectif du chèque

88

44
 Exemple

UML Collaboration Model : ProfesseurC

: TP 1-Dépose

<<become>>
: Devoir {new }
<<become>>
: Ecrit

<<become>> 2-Ev aluer

: Etudiant
: Oral

89

Diagramme d’états-Transition
• Description des séquences
possibles d’états et d ’actions par
lesquelles un objet peut passer tout
au long de sa vie. Ces séquences
résultent de sa réaction à des
événements discrets.

• Ci-contre: Diagramme d’états-

transition de l’objet
« Document Commercial ».

90

45
 Exemple - Ascenseur
Transition
Nom de l ’état
EnAscension
AuPremierEtage mont e( noEtage )
entry: delai = 0
do: MonteAL'etage
exit: ^sonette.ring(bip)
EnDescente
arrivé
do: descendAL'etage
arrivé arrivé monte( noEtage )
Etat de départ
EnDeplacementVersLePremierE tage PointMort

Actions
descend( noEtage )
As censeur
etageCourant : Integer = 1
delai : Integer = 0 [ delai=delaiMinutes ]
<<const> > delaiMinut es : Integer = 3

monte()
descend()

91

GAB

[ Swit chOn]

Autové rifié
ent ry / Billet -Ligne-Papier
exit / Logging
Anom alie()

Hor s Se rvice
Sans Erreur()

Nor m al
do / At tenteC arte

/ RejetC art e
C art eI nt ro()
/ Logging

V é r ifCarte N onVal() Car te NonV alide

ent ry / Logging

PI N I nt roduit ()

V e r ifPIN AvalCarte
do / Verif Pin PinInc orrec t()

PinC orrec t()

De m ande Se rvice
Etc.…

92

46
 Reservation

[Initié Par Client]

Dem andée

Contrôlée() /Intégration Sy stèm e

Enregistrée
entry / Ecrire
exit / GénérerFlag

NOK()
OK()

Reje té
do / Inf ormerClient Accéptée
exit / Inf ormerClient
do / FlaguerChmabre

/Archiv er
Signature()

Validée

93

Diagrammes d ’états - détails

• Ces diagrammes peuvent
avoir un seul point de
départ et plusieurs points Point de départ
d ’arrivée
• Un point de départ est
Point d ’arrivée
symbolisé par un disque
disque.
• Un point d ’arrivée est
symbolisé par un cercle Etat
circonscrivant un disque
Transition
• Un état est symbolisé par un
rectangle aux coins
arrondis
• Les transitions sont
symbolisées par une flèche

94

47
 Etats
• En UML
UML, un état comprend 3
compartiments. Seulement 2 • Les événements peuvent
sont disponibles dans Rose être des actions (do) ou des
(notation de State Charts de « send »
Harel).
• Le premier compartiment
Actions
contient le nom de l ’état EnAscensi on
• Le second compartiment entry: delai = 0
contient les actions (aussi do: MonteAL'e tage
appelées
pp événements))
événements exit: ^sonette
^sonette.riri ng(bi p)
effectuées en entrant
(entry
entry), durant (dodo), en
quittant l ’état (exit
exit), ou sur
une condition Send

95

Exemple d ’un diagramme d ’état

d’une montre
Mo ntre N u m e riq u e Mo ntreN um e riqu e

bo u ton D e Mo d e() b o uto nD eMo d e ()

in c rem e nte () in c re m e n te()

boutonDeM ode

Affichage boutonDeM ode A justeHeures boutonDeM ode

AjusteM inutes
do: affiche tem ps actuel d afficheHeures
do: ffi h H do: afficheHeures

inc / heures:=heures+1 inc / m inutes:=m inutes+1

96

48
Exemple pour l’ascenseur :Collaboration
Collaboration
:
A sc ens eur
p e rsi ste n t
5: Rec upereJob( )
nex t job

: L

Requête P

tran si e n t : Queue
A s c ens eur
tra n si e n t

4: A ppelleJob(job)
3: CreeDem ande( )

: Controle ur : B outon
A s c ens eur A s c e nseur
p e rsi ste n t p e rsi ste n t
2: A ppelA s c ens eur(int) 1: press er( )
: A c teur

97

Exercice: Paiement de Chèque

Élaborer le Diagramme d’états-Transition décrivant les situations d’un
client.
• Un guichetier d’une banque a pour activité l’accueil et le traitement des
chèques émis par sa banque.
• A la rencontre du client, le guichetier présente les informations d’ordre
organisationnel
g et jjamais d’ordre décisionnel p
pour lesquelles,
q , il fait
appel à son responsable qui suit la procédure avec le client.
• Dans le cas d’une demande de paiement de chèque émis par sa
banque, le guichetier demande la présentation de l’identité du client
afin de vérifier s’il n’est pas mineur. Puis procède aux actions
suivantes:
– Saisie des informations du chèque et du client
– Si la signature n’est pas conforme avec la signature affiché par l’ordinateur, il rejette le
paiement
– Si le compte est opposé, il rejette le paiement
– Si le chèque est déclaré perdu, il fait appel à son responsable pour le suivi de
ll’opération
opération et il rejette le paiement
– Si le solde du client n’est pas suffisant, il procède à une déclaration d’incident de
paiement du chèque, et il rejette le paiement
– L’ordinateur imprime un reçu de paiement, qui doit être signé par le client
– Il procède au paiement effectif du chèque

98

49
 Diagramme d ’Activités
Variante des
diagrammes
d’états-transition,
organisé par
rapport aux actions
et destiné à
représenter le
comportement
interne d’une
opération ou d’un
cas d ’utilisation.

99

Le diagramme d ’activités
• Focalise son attention sur l ’implantation des
opérations dans les classes.
• Représente donc une façon de visualiser l ’activité
interne d ’un
un objet non pas en fonction des ses
changements d ’états mais plutôt en termes des
activités effectuées dans ces états.
• L ’implantation d ’une opération est vue comme une
suite d ’actions reliées entre elles. Ces actions sont
par la suite transcrites en lignes de code.

100

50
 Le diagramme d ’activités. Exemple...
Événement
FenetreClients.Im prim eTousLesClients()
A ffiche M essage d'im press ion à l'écran

CréeFichierP osts cript

Départ Transition
EffaceM es sageE cran ^Im prim ante.Im prim eFichier()

Action
Arrivée
F enet reC lient s
Send-clause
ImprimeTousLesClients()

Classe

101

Exemple

102

51
 Exercice: Paiement de Chèque
Élaborer le Diagramme d ’Activités décrivant les situations d’un
client:
• Un guichetier d’une banque a pour activité l’accueil et le
traitement des chèques émis par sa banque.
• Dans
D lle cas d’
d’une d
demanded d de paiement
i td
de chèque
hè é
émis
i par
sa banque, le guichetier demande la présentation de l’identité
du client afin de vérifier s’il n’est pas mineur. Puis procède aux
actions suivantes:
– Saisie des informations du chèque et du client
– Contrôle
– Paiement

103

Diagrammes de composants et de déploiement

• Diagramme de composants :
– représente l’architecture logicielle
– décrit les spécifications des modules qui vont contenir le code des
classes ainsi que le programme principal. L’identification des
modules est réalisée pour chaque sous-système du système
global.
• Diagramme de déploiement :
– représente l’architecture matérielle
– décrit la disposition physique des différents nœuds (processeurs)
dans la composition d’un système et la répartition des programmes
principales du diagramme des composants, sur ces processeurs.

104

52
 Le diagramme de composantes
• Il décrit les composantes logicielles et leur
interdépendance.
interdépendance
• Il représente par conséquent la structure du code
code.
• Les composantes sont les implantations
physiques des concepts et fonctionnalités définis
dans le modèle logique du système (i.e., les
classes, les objets
classes objets, les liens et les collaborations
collaborations).
• Les composantes sont typiquement les fichiers
d ’implantation des éléments logiques du système.

105

Les composantes
• UML définit trois types principaux de composantes
composantes:
– les composantes sources:
sources ce type de composante prend
toute sa signification lors de la compilation
compilation. Elle est un
fichier source implantant une ou plusieurs classes
classes.
– Les composantes binaires:
binaires elles représentent le code
objet résultant de la compilation des sources.
sources Il peut
s ’agir d ’un fichier objet,
objet d ’une librairie statique,
statique ou
d ’une librairie dynamique.
dynamique Une composante binaire
prend toute sa signification lors de l ’édition des liens,
liens dans
le cas des librairies statiques,
statiques ou au run time, dans le cas
run--time
des librairies dynamiques.
dynamiques
– Les
L composantes t exécutables:
exécutables
é t bl programmes résultant
é lt t ded
l ’édition des liens des composantes binaires.
binaires

106

53
Exemple de diagramme de composantes de code source

<< page> >

Composante
hom e.htm l

Dépendance

< < file> > < < docum ent>>

l ogoA ni ma tion.j ava l ogoA nim at ion .doc

< < file>> < <doc um ent> >

anim ateur.java anim ateur.doc

107

Exemple de diagramme de composantes run-

run-time

< < library>

y > < < library>
y > < <library>
y >
c om m m anip.dll graphic s.dll dbhandler.dll

< < applic ation> >

browser.exe

108

54
 Diagramme de Déploiement
Déploiement...
• Il comprend:
– des nœuds
– des connexions
– des composantes
– des objets

109

Diagramme de Déploiement …exemple simple

Nœud
P roces seur I P roc es s eur II
E c ran < <V idéo> > < < TCP /IP> >

p re e mp ti ve m anual

tr a ite Da ta a cq u i si ti o n

Scheduling < <P arall èle> >

Lien < < B NC> >

Im prim ante É c hantillonneur

Process A/N

Périphérique (device)

110

55
Un dernier exemple: le pattern proxy en UML
unClient : unProx y : unS ujetRéel :
Client Prox y S ujetRéel

Requête( ) Requête( )

111

56