Cours Uml 1

ROYAUME DU MAROC
Office de la Formation Professionnelle et de la Promotion du
OFPPT
Travail
Centre NTIC Settat
RESUME THEORIQUE
&
GUIDE DES TRAVAUX PRATIQUES
MODULE N° : 8
TITRE DU MODULE : Spécification fonctionnelle d’une

application informatique
SECTEUR : NTIC
SPECIALITE : TSDI
Niveau : TECHNICIEN Spécialisé
Décembre 2006
1
REMERCIEMENT
La DRIF remercie les personnes qui ont contribué à l’élaboration du présent
document.
Pour la supervision :
MME.BENNANI WAFAE DIRECTRICE CDC TERTIAIRE & TIC

M. ESSABKI NOURDDINE CHEF DE DIVISION CCFF
Pour la conception :
- MR MOHAMMED EL OUMAMI
Pour la validation :
- JELLAL ABDELILAH
Les utilisateurs de ce document sont invités à

communiquer à la DRIF toutes les remarques
et suggestions afin de les prendre en
considération pour l’enrichissement et
l’amélioration de ce programme.
Said Slaoui
DRIF
2
MODULE 8 : Spécification fonctionnelle d’une application
informatique
Durée : 95 h
OBJECTIF OPERATIONNELS DE PREMIER NIVEAU

DE COMPORTEMENT
COMPORTEMENT ATTENDU
Pour démontrer sa compétence, le stagiaire doit spécifier

fonctionnellement une application selon les conditions, les critères et les
précisions qui suivent.
CONDITIONS D’EVALUATION
• Epreuve écrite de type étude de cas
CRITERES GENERAUX DE PERFORMANCE
• Utilisation des commandes appropriées.

• Respect du temps alloué.
• Respect des règles d’utilisation du matériel et logiciel Informatique.
3
OBJECTIF OPERATIONNELS DE PREMIER NIVEAU
DE COMPORTEMENT
PRECISIONS SUR LE COMPORTEMENT CRITERES PARTICULIERS DE
ATTENDU PERFORMANCE
A. Analyser le cahier des charges • Description précise des limites du projet

• Précision exacte de la liste des éléments
fonctionnels à réaliser
• Organisation optimisée des travaux à
effectuer
• Enumération exacte des éléments
techniques constitutifs du projet
B. Créer et gérer le dictionnaire des • Formalisation exacte du dictionnaire des

données et des règles de gestion données et des règles de gestion à partir
des éléments techniques extraits du cahier
des charges
C. Modéliser • Application judicieuse de la démarche et

du formalisme de la méthode UML pour
l’analyse des traitements.
• Mise en oeuvre pertinente du modèle
entité/association pour l’analyse des
données et des règles de passage au
modèle logique des données (Merise).
D. Installer et Utiliser un outil de

modélisation • Installation et paramétrage correct de
l’outil de modélisation
E. Créer le dossier de spécification

• Utilisation adéquate des contrôles
sémantiques pour présenter les
fonctionnalités de l’application à développer
à l’aide de l’outil de modélisation.
• Documentation judicieuse des fiches de
chaque modèle conçu.
4
OBJECTIFS OPERATIONNELS DE SECOND NIVEAU
LE STAGIARE DOIT MAITRISER LES SAVOIR, SAVOIR-FAIRE, SAVOIR -PERCEVOIR OU

SAVOIR-ETRE JUGES PREALABLES AUX APPRENTISSAGES DIRECTEMENT REQUIS POUR
L’ATTEINTE DE L’OBJECTIF DE PREMIER NIVEAU, TELS QUE :
Avant d’apprendre à analyser le cahier des charges (A) :
1. Expliquer l’intérêt d’un cahier de charge

2. Analyser les données de la situation présentée
Avant d’apprendre à Créer et gérer le dictionnaire des données et des

règles de gestion (B)
3. Expliquer l’intérêt du dictionnaire des données et des règles de gestion
Avant d’apprendre à Modéliser (C ) :
4. Expliquer le formalisme de chaque méthode (Merise et UML)

5. Expliquer l’intérêt du model Entités/Association
Avant d’apprendre à Utiliser un outil de modélisation (D) :
6. Expliquer l’intérêt d’utilisation d’un outil de modélisation

7. Utiliser un outil de présentation graphique.
5
– Introduction :
• Constatations et état du marché
• Approche objet
• Inconvénients et remèdes
• Historique d’UML
– Les diagrammes UML
• Diagramme des cas d'utilisation
• Diagramme de classes, objets
• Diagramme de séquence
• Diagramme de collaboration
• Diagramme d'états – transition
• Diagramme de composants
• Diagramme de déploiement
6
L’état du Marché
• Quelle est la réalité du développement aujourd’hui ?
• Est-ce que je peux partager mes systèmes existants ?
• Puis-je intégrer de nouvelles applications ?
• Quelle est l’adaptabilité de mon application (souplesse) ?
Le rythme effréné des changements technologiques:
• Internet/Intranet, ERP
• CORBA , COM/DCOM, ActiveX, Java, ...
• Système Distribués à N-niveau
• Etat actuel : des dépendances ingérables entre des applications peu ou pas
documentées
L’approche objet : une solution ?
• Maîtrise de la complexité
Une décomposition objet décrit et décompose le problème étudié comme un ensemble
d’objets autonomes qui collaborent pour réaliser certaines opérations.
Chaque objet décrit un certain objet du monde réel et incorpore son propre comportement.
Les objets inter-agissent en s’envoyant des messages demandant l’exécution de telle ou telle
opération
• Réutilisation
Les inconvénients de l’approche objet
• Moins intuitive que l’approche fonctionnelle ou chaque fonction du système est

identifiée puis décomposée en sous-fonctions
• Dérive inévitable car rien dans les concepts de base de l’approche objet ne dicte
comment modéliser la structure objet d’un système de manière pertinente
• Nécessité d’une grande rigueur dans l’application des concepts
UML : le remède
Pour penser et concevoir objet, il faut savoir prendre de la hauteur, jongler avec des
concepts abstraits, indépendants des langages d’implémentation et des contraintes purement
techniques.
Il nous faut donc :

• Un langage qui permette de
représenter des concepts abstraits (graphiquement par exemple)
De limiter les ambiguïtés en permettant un discours commun avec un

vocabulaire précis indépendant des langages orientés objet.
De faciliter l’analyse
7
De définir des vues décrivant tous les aspects du système avec des concepts
objets
Historique d’UML
8
9
Nom/Prénom :
Etablissement :
Spécialité :
Niveau d’étude :
Bloc modulaire :
Thème de la leçon : Les cycles de vie
Objectifs de la leçon :
Le stagiaire doit être capable de
Tracer un chemin au court de son analyse a fin de bien facilité son travail cela en passant
d’une étape de cycle de vie a l’autre
Maintenance et évolution
Validation
Tests de vérification
Implémentation
Conception
Analyse
Spécifications
Expression des besoins
Matériels et matière d’œuvre : Exercices
10
INTRODUCTION
Activités d’apprentissage
Rappel
Une démarche de développement repose sur :
• Un formalisme,
• Une méthode,
• Un processus et un cycle de vie,
• Des buts.
Les étapes du cycle de vie d'une application :
• Expression des besoins : Il traduit l'apport du futur système.

• Spécifications : Précision avec schémas, modèles et enchaînements
d'écrans.
• Analyse : Détermination des éléments du système.
• Conception : Comprend tous les choix techniques.
• Implémentation : Génération des squelettes d'une application.
• Tests de vérification : Tests unitaires et finals.
• Validation : Utilisation d'un cahier de recettes.
• Maintenance et évolution : Suivi du logiciel en production.
Transition
Il est important de déterminer chaque cycle de vie étape par étape

Pour bien réaliser une application
DEROULEMENT DU COURS
Les différents cycles de vie

Il existe 2 cycles de vie utilisées dans les approches traditionnelles : le modèle linéaire et le
modèle en “ V ”.
Le modèle linéaire
11
Expression des besoins :
...
Spécification :
Ce que le système doit être et comment il peut être utilisé.
Analyse :
L’objectif est de déterminer les éléments intervenant dans le système à construire, ainsi
que leur structure et leurs relations.
Elle doit décrire chaque objet selon 3 axes :
• Axe fonctionnel : savoir-faire de l’objet.

• Axe statique : structure de l’objet.
• Axe dynamique : cycle de vie de l’objet au cours de l’application (Etats
et
messages de l’objet).
Ces descriptions ne tiennent pas compte de contraintes techniques (informatique).
La conception :
• Elle consiste à apporter des solutions techniques aux descriptions définies lors de
l’analyse : architecture technique ; performances et optimisation ; stratégie de
programmation.
• On y définit les structures et les algorithmes.
• Cette phase sera validée lors des tests.
L’implémentation :
C’est la réalisation de la programmation.
Les tests de vérification :
12
Ils permettent de réaliser des contrôles pour la qualité technique du système.
Il s’agit de relever les éventuels défauts de conception et de programmation (revue de
code, tests des composants,...).
Il faut instaurer ces tests tout au long du cycle de développement et non à la fin pour
éviter des reprises conséquentes du travail (programmes de tests robustes ; Logiciels de
tests).
Validation :
Le développement d’une application doit être lié à un contrat ayant une forme de
cahier de charges, où doivent se trouver tous les besoins de l’utilisateur. Ce cahier de
charge doit être rédigé avec la collaboration de l’utilisateur et peut être par ailleurs
complété par la suite.
Tout au long des ces étapes, il doit y avoir des validations en collaboration également
avec l’utilisateur.
Une autre validation doit aussi être envisagée lors de l’achèvement du travail de
développement, une fois que la qualité technique du système est démontrée. Elle
permettra de garantir la logique et la complétude du système.
Maintenance et évolution
Deux sortes de maintenances sont à considérer :
Une maintenance corrective, qui consiste à traiter les “bugs ”.
Une maintenance évolutive, qui permet au système d’intégrer de nouveaux besoins

ou des changements technologiques.
Le principe de cette démarche est que chaque phase est traitée complètement avant que la
suivante ne soit entamée.
Ce qui renvoie les tests de vérification et la validation en fin du processus de développement.
Le modèle en v
13
Expression des Validation des
besoins besoins
Spécifications
fonctionnelles Validation
fonctionnelle
du
Conception
système Tests du
système
Conception des Tests des

composants
composants
Implémentation
Autre représentation de cycle en V

Etude préalable Validation des besoins
Etude détaillée Validation fonctionnelle
Etude technique Tests d’intégration
Réalisation logicielle
Le modèle en “V” permet une organisation modulaire.

• A chaque étape de l’analyse et de la conception correspond une étape de tests ou de
validation.
• A chaque étape fonctionnelle correspond ainsi une étape technique.
Le processus s’accomplit en deux phases :
14
• Une phase descendante : de spécifications et de conception.
• Une phase ascendante : de tests et de validation.
Comme pour le modèle linéaire, l’inconvénient est que la validation et les tests interviennent
tardivement.
Il y a aussi
Modèle en spiral
Evaluation 2
Evaluation
Prototype 1 Prototype 2
Spécifs Spécifs 2
Le cycle en cascade
15
Schéma directeur Plan de développement à moyen terme des systèmes
d’informations
Etude préalable Dossier de choix avec proposition et évaluation de

n solutions
Etude détaillée Spécifications fonctionnelles complètes futur S.I.

(vue utilisateur)
Spécifications techniques complètes du futur
Etude technique S.I. (vue info.) pour la réalisation
Réalisation logicielle
Mise en service Application informatique installée

dans la nouvelle organisation
Maintenance
Le cycle de vie Objet

Dans un projet Objet, le cycle de vie répond à 3 caractéristiques essentielles :
• La traçabilité entre les étapes
• Un cycle itératif
• Un cycle incrémental
La traçabilité entre les étapes :
• Les concepts utilisés au cours des différentes étapes sont quasiment identiques
(Classes, Objets, Attributs, Méthodes, Héritage, Polymorphisme, ...).
• Ce qui n’est pas le cas dans les approches traditionnelles, où l’on utilise une
méthode d’analyse et de conception avec des concepts et un langage de
programmation avec d’autres concepts.
• Ceci permet de conserver le même discours lors de toutes les étapes :
« Analyse - Conception - Implémentation ».
Un cycle itératif :
16
Validation des besoins
Tests de Expression des

vérification besoins
Implémentation Spécifications
fonctionnelles
Conception
Analyse
Un cycle incrémental :
• Lors du développement, une maquette doit être réalisée pour valider l’ergonomie
de l’application et l’enchaînement des écrans.
• Plusieurs versions peuvent être développées. Lors de chacune d’elle, chaque

fonctionnalité est améliorée jusqu’à optimisation rendant ainsi le système
progressivement robuste.
17
CONCLUSION
Récapitulation et synthèse
Donner les différents cycles de vie?
Exercice d’évaluation
1) Définir les cycles de vie en ordre et en expliquant leur étapes ?

2) Donner les types des modèles de cycle de vie ?
3) Définir la déférence entre les modèles de cycle de vie ?
4) Le cycle de vie répond à 3 caractéristiques essentielles
dans un projet, les quelles ?
5) Le processus de cycle en V s’accomplit en deux phases les quelles ?
18
19
Nom/Prénom :
Etablissement :
Spécialité :
Niveau d’étude :
Bloc modulaire :
Thème de la leçon : cas d’utilisation (use case)
Le stagiaire doit être capable de :
* Bien comprendre le cahier de charge
* Définir les acteurs avec leurs intentions
* comment rechercher les acteurs et leurs cas d’utilisation
20
Rappel
Diagramme de cas d’utilisation (DCU)
Il est destiné à représenter les besoins des utilisateurs par rapport au système
• Il s’agit de la solution UML pour représenter le modèle
conceptuel
• Les uses cases permettent de structurer les besoins des
utilisateurs et les objectifs correspondants d’un système.
• Ils identifient les utilisateurs du système (acteurs) et leur
interaction avec le système
Eléments de base :
Acteur : entité externe qui agit sur le système (utilisateur, autre système)
• Il possède un rôle par rapport au système
• Il peut consulter ou modifier l’état d’un système
Un acteur est défini à travers son rôle
Typologie des acteurs : primaire ou secondaire
Cas d’utilisation : ensemble des actions réalisées par le système en réponse à une action d’un
acteur;
• Moyen de recueillir et de décrire les besoins des acteurs du système;
• Les uses cases peuvent être organisée en paquetages (packages).
Transition
Le chemin à suivre pour réaliser un diagramme de cas d’utilisation
1) Faire un tableau d’exigences

2) Diagramme des acteurs
3) Diagramme contexte dynamique
4) Diagramme contexte statique
5) Intentions d’acteurs
6) Et en fin Diagramme de uses case
21
Schèma des étapes à suivre
Processus de définition des besoins
re fonction
R payer achat
… …
Exigences Diagramme des acteurs
0..*
payer
retourn est dans
magasi
magasi
Diagramme contexte Diagramme contexte statique
ref fonctio intenti acteur
Intentions d’acteurs Diagramme de uses cases
nom : effectuer un achat

acteur principal : client
acteur secondaire : caissier
événement déclencheur : …
rôle du use case : …
terminaison du use case : …
Use case haut niveau
22
Les use cases (cas d’utilisation) sont un concept de la méthode OOSE de Ivar Jacobon.
Ils permettent d’effectuer une délimitation du système et de décrire son
comportement.
Ils constituent une représentation orientée “ fonctionnalités ” du
système.
Dans la modélisation par les use cases :
2 concepts fondamentaux interviennent :
Les acteurs : utilisateurs du système.
Les uses cases : utilisation du système
Ceux sont les utilisateurs du système
Tout système peut être décrit par un certain nombre de cas d’utilisation représentant les
besoins exprimés par l’ensemble d’utilisateur.
1 système=n cas d’utilisation

Acteur 1
Acteur2
Acteur 3
Exemple de représentation d’un système en cas d’utilisation
La représentation d’un cas d’utilisation met en jour trois concepts.

L’acteur.
Le cas d’utilisation.
l’interaction entre l’acteur et le cas d’utilisation
23
- Recherche des Acteurs :
Qu’est ce qu’un acteur
• Quelqu’un ou quelque chose
• EXTERNE au système
• qui interagit avec le << Acteur >>
système
Client
Client
Un acteur est une personne ou une chose qui va interagir avec le système
Il peut être :
» soit un humain;
» soit un logiciel ;
» soit un automate.
On distingue :
• les acteurs primaires : ceux sont les utilisateurs du système ;
• les acteurs secondaires : ceux qui administrent le système.
• Un acteur est défini à travers son rôle

• Typologie des acteurs : primaire ou secondaire
Acteurs Acteur
primaires Guichetier Application bancaire secondaire
Responsabl
e des
Directeur
Exemple 1 :
<<actor>>
Client
Client Stick-man
24
- Recherche des Use Case :
Un cas d’utilisation est
• Séquence de transactions entre un acteur et le système

• PAS un module du système
* plutôt une fonctionnalité du système
• Un use case est une intention d'acteur. Quand un acteur démarre un use case, il a une
intention précise. Quelle est cette intention? Effectuer un achat est une intention qui
recouvre un certain nombre d'exigences. C'est une unité d'intention complète d'un
acteur: c'est donc un use case. Payer ses achats n'est pas une intention complète
d'acteur. Nous n'allons pas dans un magasin pour payer, mais bien pour faire des
achats. C'est donc une partie (et pas la plus agréable) de effectuer un achat. Ce n'est
donc pas un use case.
Représentation générale de DCU
Exemple 1:
Le système permet à l’acteur
Client de consulter son compte
Consulter compte
Client
Exemple 2 :
25
Exemple 3
Application bancaire (système)
Retrait Saisie cours

euros devise
Retrait Responsable
Guichetier des devises
devises
Emprunt
Bilan
Directeur
L’intégration dans l’Use Case “ Application bancaire ” des use cases de chaque opération
permet d’avoir une vision globale du système. Elle permet également de comprendre le rôle
de chaque acteur.
26
Exemple 4
Effectuer un achat
Client
Retourner un article
les flêches unidirectionnelles

Cais s ier indiquent un lien principal,
Se connecter
c'es t à dire l'acteur principal du
us e case.
Gérer le catalogue
Salarié
Manager Initialis er la cais s e
Editer un rapport
adminis trateur
Définir les profils
Relations entre cas d’utilisation
Les cas d’utilisation peuvent être liés par des relations :

- d’utilisation « include » (le cas origine contient obligatoirement l’autre)
- de raffinement « extend » (le cas origine peut être ajouté optionnellement)
• Des fonctionnalités bien précises qui se retrouvent parmi plusieurs uses cases. Nous
parlerons alors de use case included ou subalterne.
Relation d’utilisation : indique que le cas d’utilisation

Source contient aussi le comportement décrit dans
le cas d’utilisation destination.
En d’autres termes, pour réaliser l’objectif
« Imprimer solde compte », on utilise les objectifs
« Consulter compte » et « imprimer un ticket » du
système
27
Un tel use case ne peut être lié qu'à un use case, pas à un acteur. (Nous mettrons alors le
stéréotype include sur le lien use case vers use case subalterne).
exem ple de use case

avoir solde retrait
subalterne pour un
<<include>> guichet autom atique
<<include>> de banque
authentification
Exemple
Relation d’extension
Un use case peut nécessiter le service d'un autre use case. Le use case dont nous avons
besoin du service étend le use case demandeur. Nous utiliserons le stéréotype extend. Ici
les uses cases peuvent être sollicités par des acteurs.
28
<<extend>>
ges tion com m ande ges tion client
exem ple de us e cas e étendu pour un

s ys tèm e de ges tion de com m ande.
Quand nous rentrons une com m ande, il
faut pouvoir créer le client s 'il n'existe
pas .
Donc la relation extend dit que :

Un ou plusieurs use cases peuvent hériter des caractéristiques d’un autre use case.
Guichetie Retrait francs “Extends” Systèm
Retrait
“Extends”
Retrait devises
Les Uses Cases fils ont les mêmes liens avec les acteurs et les autres use cases que le use case
dont ils héritent.
Ceux sont de cas particuliers du Uses Case père.
Exemple :
Exemple (distributeur des boissons)
29
monnaie
uses
Usager
Boisson
uses extends extends
Servir Boisson
Coca
Relation d’extension : indique que le cas d’utilisation source étend

(Précise) les objectifs (le comportement) du cas d’utilisation destination.
La relation “uses”
Soit l’use case “Saisie n° compte”
• Le guichetier saisit le code de la banque du compte.
• Il saisit le numéro du compte.
• Il saisit la clé du compte.
• Le système calcule la clé du compte et vérifie qu’elle est bonne.
• Le système interroge le compte sur le système central.
• Le système affiche le compte ainsi que son détenteur.
Application bancaire (système)
Retrait devises Emprunt

Retrait
“uses” “uses”
“uses”
Saisie n° compte
Lorsque une ou plusieurs tâches sont utilisées régulièrement, on peut les factoriser dans un
même use case et faire de telle sorte que d’autres use cases l’utilisent en le pointant par une
flèche.
Cet use case est en fait une sous partie de chaque use case qui l’utilise. Ce qui permet de
décomposer un use case complexe en plusieurs uses cases.
30
Use case description bat niveau :
C’est ou en défini :
• nom :
• acteur principal :
• acteur secondaire :
• événement déclencheur :
• rôle du use case :
• terminaison du use case :
Use case description haut niveau :

C’est ou en défini :
• nom :
• acteur principal :
• acteur secondaire :
• événement déclencheur :
• rôle du use case :
• terminaison du use case :
• références croisées :
• pré conditions :
• scénarios et alternatives :
31
CONCLUSION
1) Donner la définition d’un acteur et de use case ?

2) Quel est le type du diagramme suivant :
♀
Guichetier Interroger compte
EXERCICE 1
On considère un système simplifié de Guichet Automatique de Banque (G.A.B.). Le GAB

offre les services suivants:
1. Distribution d'argent à tout porteur de carte de crédit (carte Visa, ou de la banque), via
un lecteur de carte et un distributeur de billets.
2. Consultation de solde de compte, dépôt en numéraire et dépôt de chèques pour les
clients de la banque porteurs d'une carte de crédit de la banque.
Par ailleurs:
• Toutes les transactions sont sécurisées, via:
Le Système d'Autorisation Visa, pour les retraits effectués avec une carte Visa;
QUESTIONS
Elaborez un Diagramme de Cas d'Utilisation détaillé du GAB
EXERCICE 2
Cet exercice traite d'un système simplifié de caisse enregistreuse de supermarché. Le

déroulement normal d'utilisation de la caisse est le suivant:
• Un client arrive à la caisse avec des articles à payer.

• Le caissier enregistre le n° d'identification de chaque article, ainsi que la quantité si
elle est supérieure à 1.
• La caisse affiche le prix de chaque article et son libellé.
• Lorsque tous les achats sont enregistrés, le caissier signale la fin de la vente.
32
• La caisse affiche le total des achats.
• Le client choisit son mode de paiement.
1. Liquide: le caissier encaisse l'argent reçu, la caisse indique la monnaie à rendre
au client.
2. Chèque: le caissier vérifie la solvabilité du client en transmettant une requête à
un centre d'autorisation via la caisse.
3. Carte de crédit: un terminal bancaire fait partie de la caisse. Il transmet une
demande d'autorisation en fonction du type de la carte.
• La caisse enregistre la vente et imprime un ticket.

• Le caissier donne le ticket de caisse au client.
Lorsque le paiement est terminé, la caisse transmet les informations sur le nombre d'articles
vendus au système de gestion des stocks.
Tous les matins, le responsable du magasin initialise les caisses pour la journée.
QUESTIONS
1. Elaborez un Diagramme de Cas d'Utilisation détaillé de la Caisse enregistreuse.

N'hésitez pas à utiliser les relations entre cas d'utilisation pour rendre le diagramme
plus précis.
Exercice 2
Voila des cas d’utilisations d’un système de messagerie faire les liens entre les acteur et ces
cas d’utilisation
Les acteurs
Personne A (un utilisateur du public)

Administrateur
Les cas d’utilisations
Connexion
Lecteur de boite
Envoi d’un message
Changement de boite
33
34
Nom/Prénom :
Etablissement :
Spécialité :
Niveau d’étude :
Bloc modulaire :
Thème de la leçon : Objet, classe et association
• Différencier entre un objet et une classe

• Reconnaître les différents types de relations
• Reconnaître les multicipités
• Rappeler l’héritage…etc.
35
INTRODUCTION
Rappel
- Rappel sur les modèles de merise

- Rappel sur la façon pour trouvez les entités
- Rappel sur les différentes relations ainsi que les cardinalités
Diagramme de classe d’analyse
Le diagramme de classes est un des documents les plus importants, voire le plus important de
l'analyse d'un logiciel par une méthode objet. C'est le premier document qui est dans le monde
des objets (les acteurs n'étant pas forcément représentés dans le système informatique). C'est
donc l'entrée dans le monde des objets.
Ce diagramme est un diagramme de classe d'analyse. Il ne représente pas les classes Java ou
C++ que nous développerons par la suite.
Ici nous nous intéressons aux classes du domaine métier, c'est à dire des objets dont on parle
dans le cahier des charges et dans les uses cases principalement. Nous ne nous intéressons pas
aux objets informatiques dans ce diagramme (sauf bien entendu si le métier est l'informatique
!!). Cela viendra en son temps, dans le diagramme de classe de conception. Quand nous
passerons à la conception des classes disparaîtront, d'autres apparaîtront, dont les classes
informatiques (collections, …). C'est normal. En phase d'analyse, nous voulons simplement
faire un diagramme de classe d'objets manipulés dans le domaine métier considéré.
Dans ce diagramme de classe les opérations ne sont pas représentées (ce sera lors de la
conception).
Ce diagramme montrera les concepts du domaine métier, les liens (associations) entre ces
concepts (avec leur cardinalité ou multiplicité), et les attributs de ces concepts ( souvent sous
forme de données simples ).
Le but de ce diagramme est de clarifier le domaine métier du client, et de se familiariser avec
ce domaine.
Dans une analyse structurée nous décomposons l'analyse suivant les tâches ou les fonctions.
Dans une application à dominante gestion, nous décomposerons notre application suivant les
données, et les traitements. Ici nous analyserons la complexité du domaine en regardant les
objets métier et leurs interactions entre eux.
Partie -I-
-Notion d’objet :
Un objet est défini à la fois par des informations : données ou attributs ou variables
d’instances.
36
Comportements : traitements ou méthodes ou opérations.
Exemple :
Partie -II-
-Notion de classe :
Lorsque des objets ont les mêmes attributs et comportements : ils sont regroupés dans une
famille appelée : Classe.
Les objets appartenant à celle-ci sont les instances de cette classe.
L’instanciation est la création d’un objet d’une classe.
Deux instances d’une même classe peuvent avoir des attributs avec des valeurs différentes et
mais partagent les mêmes méthodes.
Partie -III-
Les relations :
L’association représente une relation entre plusieurs classes. Elle correspond à

l’abstraction des liens qui existent les objets dans le monde réel.
Client Achète
Produit
37
Agrégation est une forme particulière d’association entre plusieurs classes. Elle
exprime le fait qu’une classe est composée d’une ou plusieurs autres classes.
Bouteille Vin
La composition est une relation d’agrégation dans laquelle il existe une contrainte de
durée de vie entre la classe ‘composant’ et la ou les ‘composé’. Autrement dit la
suppression de la classe ‘composé’ implique la suppression de la des classes
‘composant’.
Exemple :
Commande LigneDeCommande
Généralisation de classe consiste à factoriser dans une classe, appelée superclasse, les
attributs et/ou opérations des classes considérées.
Exemple 1:
Généralisation
Classe A
Sous-Classe Sous-Classe
A1 A2
La spécialisation représente la démarche inverse de la généralisation puisqu’elle

consiste à créer à partir d’une classe, plusieurs classes spécialisées.
Exemple 2:
Classe A
A1 A2
Spécialisation
38
L’encapsulation : les données ne sont accessibles qu’à partir des opérations définies
dans la classe. Le principe d’encapsulation renforce l’autonomie et l’indépendance de
chaque classe et donne une forte potentialité de définition de classe réutilisable.
Exemple 3:
Accès aux données I Classe x

via l’interface N Traitements
(Partie visible de T Données :
La classe) E Liste des
R attributs
F
A Liste des attributs
C
E
Le polymorphisme : est la capacité donnée à une opération de s’exécuter

différemment suivant le contexte de la classe où elle se trouve.
La persistance est la propriété donnée à un objet de continuer à exister après la fin de

l’exécution du programme qui l’a créé.
Par défaut dans l’approche objet, aucun objet n’est persistant. Les modèles décrivent
le système en exécution en mémoire centrale et ne tiennent pas compte a priori de
l’état du système qui doit être stocké sur disque.
L’héritage est un mécanisme qui permet d’assurer une grande variabilité dans la
réutilisation des objets. Il existe deux techniques liées à l’héritage : les classes
abstraites et l’héritage multiple.
Exemple 4:
Passager
poids:reel
donnerPoids():reel
Voiture
Super-classe
Conducteur Sous-classe
bouge(dir,vit):void
39
Exemple d’héritage multiple :
La classe C50 hérite des classes C1, C2 et C3.
Partie -IV-
Comment identifier les bons objets métier pour construire notre diagramme de classe
d'analyse?
Il va falloir recenser dans les documents de définition des besoins et dans les documents
d'analyse l'ensemble des objets métier.
Les noms ou groupes nominaux vont être de bons candidats pour être élus au titre de classe,
objet ou attribut. Cependant, il faut être prudent car il y aura aussi un certain nombre de faux
amis et de doublons.
40
Voici une démarche de sélection des classes candidates:
Par use case, nous réaliserons un diagramme de classe, le diagramme final étant la
superposition de tous ces diagrammes.
Pour un use case nous recenserons les groupes nominaux rencontrés. Nous identifierons alors:
• Les classes (noms communs).
• Les objets (noms propres ou nom référencés).
• Les attributs (données simples qui qualifient une classe ou un objet).
• Les éléments qui sont étrangers à notre problème ou qui n'y ont pas de rôle réel.
• Les " classes fonctionnelles " qui ne sont porteuses d'aucune information, mais seulement
de traitement, qui ne sont souvent pas des classes de notre diagramme. Par exemple
gestionnaire du planning, décodeur de message, …
• Il est parfois difficile de savoir si une information est un attribut d'une classe ou une
classe (avec une association avec la classe). Dans le doute il vaut mieux faire une classe,
quitte à revenir en arrière dans une itération ultérieure. Par exemple pour la classe personne
l'âge est un attribut (donnée simple) l'adresse étant à priori une donnée complexe sera plutôt
une autre classe associée à la personne.
• Les entités suivantes peuvent prétendre à devenir des classes :

- les objets physiques (produit…),
- les transactions (réservation, commande,….),
- les lignes de transaction (ligne de commande…),
- les conteneurs (catalogues, lots,…),
- les organisations (services, départements,….),
- les acteurs ou les rôles (client, fournisseur….),
- les regroupements en abstraction (modèle, genre, type, catégorie….),
- les évènements (vol,…)
Pour le use case " effectuer un achat " voici la liste des classes sélectionnées:
caissier
caisse
Paiement catalogue
vente
article
ticket
ligne de vente
41
Nous ne gèrerons pas les exemplaires des articles. Nous appèlerons article un ensemble
d’exemplaires identifiés par le même code barre, et comportant des informations identiques
(prix …).
Nous allons maintenant rajouter les associations entre les classes, en donnant un intitulé
et des cardinalités à ces associations.
Notre but n'est pas de mettre à jour toutes les associations entre les différentes classes, mais
de noter les associations pertinentes pour comprendre le problème. Il faut privilégier les
associations qui durent dans le temps, et dont la connaissance est nécessaire à la
compréhension du problème.
Il faut éviter les associations redondantes ou dérivables d'autres associations.
L'établissement de ces associations nous amène à poser des questions au client. C'est un des
buts recherchés. Voici une possibilité de diagramme de classe avec ses associations.
caissier
0..1
catalogue
utilise
1 1
0..1
caisse
se fait à partir
1
Paiement 1 effectue
payée par 0..1
1 1
vente
génèr 1 1
e contient
ticket comprend
1
1..*
ligne de
vente
0..*
est décrite par
1 0..*
article
Sur ce diagramme de classe d'analyse il faut maintenant mettre les attributs des classes qui ont
été repérés dans le cahier des charges, le diagramme de use case, ou dans le diagramme de
séquence boîte noire du use case.
42
A priori, les attributs présents dans notre diagramme de classe d'analyse sont des attributs
simples. On pourra faire exception des données pures qui sont des regroupements de données
simples ( ici code, adresse, prix ) .
Les attributs qui ont un comportement sont des classes associées à notre classe. Ceci ne
présage en rien du diagramme de classe de conception. Nous verrons ultérieurement ce que
deviennent les associations dans ce schéma…
Dans les attributs, il ne doit pas y avoir de clef sur un autre objet. Cela se représente par une
association.
Voici notre diagramme de classe enrichi des attributs d'analyse.
caissier
0..1
catalogue
utilise
1 1
0..1
caisse
se fait à partir
1
Paiement
effectue
somme : réel 1 0..1
payée par 1
1 Vente
date : Date
heure : Heure
génère 1 contient
1
ticket
1 comprend
1...*
1..*
ligne de vente
quantité : entier
0..*
le prix ou la
somme devraient est décrite par
0..*
se donner par 1
rapport à une description article
monnaie...
description : text
prix : réel
code : codebarre
43
CONCLUSION
Donner les différents types de relation avec des exemples ?

En UML une composition est :
* une opération entre trois classes
* une association d’héritage entre deux classes
* une association qui indique qu’une classe en contient une autre
* un attribut composé de plusieurs attributs
3) En UML, quelle est l’expression vraie exprimée par le diagramme suivant :
Client Compte
1..1
0..*
4) En UML quelle est la signification d’une généralisation :

* relation d’inclusion entre 2 classes
* génération d’une opération conceptuelle
* relation de dépendance hiérarchique entre deux classes
* n’existe pas en UML.
Exercice «classification »
Classer les relations suivantes en généralisation, instanciation, agrégation, lien ou association.

Argumenter les réponses.
(a) Un pays possède une capitale.
(b) Un philosophe qui dîne utilise une fourchette.
(c) Un joueur de rugby est un avant, un demi ou un arrière.
(d) Une équipe de rugby est composée de 8 avants, 2 demis et 5 arrières.
(e) Dédé programme son simulateur de vol en Java sur son PC.
(f) Java, C++ et Eiffel sont des langages orientés objet.
(g) La Tour Eiffel a 3 étages et 3 millions de boulons.
(h) L'agrégation est un examen.
Exercice
Dessiner les diagrammes (d’objets, de classes) correspondant aux situations suivantes :
(a) La France est frontalière de l’Espagne. Le Canada est frontalier des Etats-Unis.
(b) Un polygone est constitué de points. Un point possède une abscisse et une ordonnée.
(c) Une médiathèque possède des médias, empruntables par les abonnés de la médiathèque.
(d) Un client demande une réparation. Une réparation est effectuée par un mécanicien. Elle
nécessite des compétences. Un mécanicien possède des compétences.
(e) Une galerie expose des oeuvres, faites par des créateurs, et représentant des thèmes. Des
clients, accueillis par la galerie, achètent des oeuvres.
Dessiner les diagrammes (d’objets, de classes, de généralisation) correspondant à la situation
44
suivante :
(f) Un bateau contient des cabines, occupées par des personnes qui effectuent des activités.
Les
personnes sont ou bien des guides, ou bien des animateurs, ou bien des passagers. Les
guides expliquent des visites aux passagers et les animateurs animent des animations pour
les passagers.
Exercice « JARDINIER »
Un jardinier effectue deux types de travaux : l’arrosage et le piochage. L’arrosage consiste à

arroser des plantes (tulipes, eucalyptus ou géraniums) avec un outil (arrosoir ou tuyau)
contenant de l’eau et le piochage consiste à retourner la terre avec un outil (pioche ou pelle)
pour y mettre de l’engrais. Autrement dit, le jardinier utilise un outil (arrosoir, tuyau, pelle ou
pioche) pour mettre une ressource (eau ou engrais) sur un objet naturel (terre ou plante) ;
celuici
est produit par un travail (arrosage ou piochage).
1) Dessiner le diagramme de généralisation des classes. On généralisera les classes du
domaine avec une classe « Objet ».
2) Dessiner un diagramme d’objets correspondant au texte suivant :
Jacques est un jardinier qui arrose 3 géraniums avec un arrosoir rempli d’eau.
Jules est un jardinier qui pioche la terre avec une pelle pour y mettre de l’engrais.
3) Dessiner un premier diagramme de classes avec les classes Jardinier, Arrosage, Arrosoir,
Eau, Geranium. Puis dessiner un autre diagramme de classes similaire au premier mais avec
des classes plus générales : Jardinier, Travail, Outil, Ressource, ObjetNaturel.
4) Quelle difficulté posent les classe Eau, Terre, Engrais ?
5) Placer les ordres de multiplicité sur les 2 diagrammes de classes précédents. Quelle
Remarque peut-on faire ?
Exercice :

suivante :
Les personnes sont ou bien des guides, ou bien des animateurs, ou bien des passagers. Les
guides expliquent des visites aux passagers et les animateurs animent des animations pour les
passagers.
45
46
Nom/Prénom :
Etablissement :
Spécialité :
Niveau d’étude :
Bloc modulaire :
Thème de la leçon : notion des classes
• Fournir un premier contact avec la modélisation des
données en montrant la difficulté et l'importance de
cette activité.
• Montrer la différence entre modèle du domaine et
modèle du problème.
• Montrer comment faire la liaison entre le dictionnaire
et les modèle du domaine / du problème.
• Montrer la relation entre les cas d'utilisation et la
modélisation des données pour souligner une certaine
continuité et éviter que les diagrammes de cas
d'utilisation soit élaborés mais aussitôt abandonnés.
• Simplicité
• Facilité pour coder et réutiliser
• Modèle plus proche de la réalité
– description plus précise des combinaisons
(Données, opérations)
– décomposition basée sur “classification naturelle”
f il à d tà i t i
47
INTRODUCTION
Rappel
Une classe Ensemble d’objets ayant :

- des propriétés (attributs) similaires
- un comportement (opérations) commun
- des relations communes avec d’autres objets
- des sémantiques communes (domaines de
Définitions)
Donc : une classe décrit un groupe d’objet ayant les mêmes propriétés, un même
comportement et une sémantique commune.
Une classe se représente à l’aide d’un rectangle comportant les trois compartiments.
La désignation de la classe
Attributs
Nom de la calasse
La description des attributs
Opération
La description des opérations
Un modèle de domaine : fait référence à des connotatives métier

Ce dernier ce trouve dans le dictionnaire de données (il à une forme d’un tableau qui peut
contient les colonnes suivants : nom d’attribut ; signification ; type –N, A, AN- ; longueur ;
nature –E, CO, CA /M, SIG, SITU- ; règle de calcule ou d’intégrité)
Modèle de problème : il est variable selon l’application demandée il étude les problèmes à
résoudre
Un objet est une instance d’une classe, est caractérisé
par des attributs, des méthodes, et l’identité
Transition
Pour que le stagiaire soit capable de réaliser des classe il faut qu’il défini premièrement
le modèle de domaine et le modèle de problème pour pouvoir étudier les problèmes à
résoudre et en fin extraire les classes et leurs attributs et méthodes
48
Partie1
Identification des classes et des attributs :
(1) Explication : sur la différence entre modèle du domaine et modèle du

problème
• Modèle du domaine. Stable. Indépendant d'une l'application particulière. Peut être partagé
entre entreprises, fait référence à des connaissances métiers et se retrouve dans le dictionnaire.
• Modèle du problème : instable. Dépend de l'application à réaliser. Fortement lié au
diagramme de cas d'utilisation et du problème à résoudre.
En réalité, la séparation n'est pas si simple à obtenir. Du moment que l'on modélise de
manière un peu détaillée, on se concentre déjà sur le modèle du problème en choisissant par
exemple de représenter une information sous la forme d'un attribut plutôt que d'une classe par
exemple, car l'on sait que peu d'information sont nécessaires dans le problème auquel on
s'intéresse.
Pour le déroulement de la séance, on peut commencer en partant du dictionnaire et/ou du texte
et essayer de voir pour chaque élément quels sont leur modélisation en UML en s'attachant
aux classes et aux attributs
A ce stade les différents concepts UML vus sont les suivants
• acteur
• cas d'utilisation
• classe
• attribut
• association
• opération
Il s'agit donc pour chaque terme dans le dictionnaire de déterminer la catégorie
correspondante. Différentes alternatives de modélisation sont possibles. Par exemple on peut
représenter la Ville comme un attribut ou comme une classe en fonction du niveau de détail
que l'on souhaite modéliser. On peut représenter Inscription comme une classe ou une
association. On choisira la modélisation exacte par la suite en faisant un diagramme de classe.
49
Représentation graphique d'une classe :
Le premier compartiment contient le nom de la classe, le second les

Nom de la classe attributs et le dernier les opérations.
Attributs Les compartiments peuvent être supprimés pour alléger les
diagrammes.
Opérations Par défaut, les attributs sont cachés et les opérations sont visibles.
Exemple 2
Le nom de la classe
Compte
Exemple 3
Compte
Les attributs Numéro : String
Solde : Float
Attributs de la classe
• est une propriété élémentaire d’une classe;

• prend une valeur pour chaque objet d’une classe
Les noms d’attributs d’une classe sont uniques

Le type de l’attribut (entier, texte…) dépendant des types
disponibles dans le langage d’implémentation
Un attribut dont la valeur peut être calculée à partir d’autres
attributs de la classe est un attribut dérivé qui se note « / Nom de l’attribut dérivé »
Attributs
50
Un attribut est une valeur de donnée détenue par les objets d'une classe.
Chaque nom d'attribut est unique à l'intérieur d'une classe (par opposition au fait
d'être unique parmi toutes les classes). Ainsi la classe Personne et la classe Société peuvent
avoir chacune un attribut adresse.
Syntaxe complète : visibilité nom : type = valeur -initiale
Seul le nom est obligatoire en analyse.
Visibilité : marqueur optionnel utilisé en conception

+ Public
# protégé
- privé
Type : type d'un langage de programmation en conception détaillée.
Valeur -initiale : servira à donner la valeur initiale d'un attribut à la création d'un nouvel objet.
Exemple 4 :
Opérations de la classe
- Est une fonction applicable aux objets d’une classe;
- Permet de décrire le comportement d’un objet
* Une méthode est l’implémentation d’une opération
Compte
numero : String public class Compte {
solde : Float
String numero;
Les méthodes
Float solde;
debiter () : void
crediter () : void
getSolde () : Float
void debiter() {}
void crediter() {}
Float getSolde() {}
}
Opérations
Une opération est un service que l'on peut demander à un objet pour réaliser un
comportement. Tous les objets d'une classe partagent les mêmes opérations.
En analyse, on parle plutôt d’opération. En conception, on parle plutôt de méthode. Une
méthode est l'algorithme ou la procédure qui produit le résultat de l'opération.
Syntaxe complète : visibilité nom (liste -paramètres) : type -retour
Seul le nom est obligatoire en analyse.

Visibilité : marqueur optionnel utilisé en conception
+ Public
# protégé
- privé
Liste -paramètres : liste de paramètres formels, chacun étant spécifié comme suit :
Nom : type = valeur -défaut
51
Type -retour : optionnel si l'opération ne retourne pas de résultat (void du C++).
Fenêtre Objet géométrique
+ afficher ( ) : Position + déplacer (delta: Vecteur)

+ cacher ( ) + sélectionner (p: Point) : Booléen
+ tourner (angle)
Exemple 2
Nom de la
classe
Voitur Attributs
type : string
marque : string opérations
couleur : string
repeindre(c: Couleur)
déplacer(d : Méthode
Des attributs complémentaires peuvent être nécessaires
Exemple 3
Compte
numero : String
solde : Float
debiter () : void
crediter () : void
getSolde () : Float
52
Compte
- numero : String
- solde : Float
+ debiter (montant : Float) : void

+ crediter (montant : Float) : void public class Compte {
+ getSolde () : Float private String numero;
- modifierSolde (montant : Float) : void private Float solde;
# calculerNouveauNumero () : String
public void debiter() {}
public void crediter() {}
public Float getSolde() {}
static protected
calculerNouveauNumero()
{}
}
Exemple 4
Propriétés des attributs et des opérations
- Accessibilité aux attributs et opérations d’une classe

Trois niveaux de protection :
• Public (+) : accès à partir de toute entité interne ou externe à la
classe
• Protégé (#) : accès à partir de la classe ou des sous-classes
• Privé (-) : accès à partir des opérations de la classe
53
Synthèse
note (peut contenir un
complément de
description, un
commentaire, …)
adhérent de la
bibliothèque
Adhérent
privé valeur initiale
- adresse : String = 'adresse inconnue'
- numeroINSEE[6] : Integer
type d'attribut
# changeAdresse(nouvelleAdresse : String)
+ cotisationAJour() : Boolean
type de
public paramètre
Association entre classes

• représente les liens qui existent entre les instances de
ces classes.
• Chaque association peut être identifié par son nom
Multiplicité des associations
- est une information portée par le rôle, qui quantifie le

nombre de fois où un objet participe à une instance de
relation.
54
Agrégation entre classes
• est une association qui permet de représenter un lien

de type « ensemble » comprenant des « éléments »
• est une association non symétrique :
L’une des extrémités joue un rôle prédominant
par rapport à l’autre
Agrégation particulière : Composition
• est une relation d’agrégation dans laquelle il existe une contrainte

de durée de vie entre la classe « composant » et la ou les classes
« Composé »
• La suppression de la classe composé implique la suppression de
la ou des classes composant.
• La valeur maximale de multiplicité du côté du conteneur ne doit
pas excéder 1 puisque les objets, instances de la classe des
composants, doivent tous appartenir au même objet conteneur.
55
Généralisation, Spécialisation et héritage simple
• La généralisation consiste à créer une « superclasse »

à partir de classes
• La spécialisation consiste à créer des « sous-classes »
à partir d’une classe
• Les attributs et opérations d’une superclasse sont
transmis aux sous-classes par héritage
• Sous-classes = instances d’une seule classe (héritage
simple)
• La généralisation facilite la modélisation en regroupant
ce qui commun aux classes de ce qui ne l’est pas.
56
Exemple 2
Véhicule
Véhicule Véhicule
Auto Véhicule Batea
Héritage multiple
- consiste à hériter une même classe de deux classes

« Parentes » distinctes
57
CONCLUSION
1) Donner les étapes nécessaires pour définir les classes avec les attributs?
2) En conception technique, comment implémente t-on les associations entre des classes du
diagramme de classe :
Par exemple :
Compte
Client
• On créé une nouvelle classe pour traduire l’association posséder

• On crée une méthode dans l’une des deux classes concernées Client ou Compte
• Ce n’est pas nécessaire, le diagramme de classes suffit
• on crée un attribut dans une des classes qui référencera un objet de ’autre classe
Un ordinateur et composé de plusieurs périphériques ; donner un diagramme de classe que
montre un archetière d’un ordinateur en spécifiant le type d’association entre les classes
Exercices
Exercice « TRIATHLON »
Un triathlète utilise trois types de moyens de déplacement : la nage, le cyclisme et la course à
pied. La nage consiste à nager une distance courte avec un maillot de bain dans un liquide (lac
ou mer). Le cyclisme consiste à pédaler sur une distance longue avec un vélo sur une route.
La
course a pied consiste à courir une distance moyenne avec des chaussures sur une route.
Autrement dit, le triathlète possède des équipements (vélo, maillot ou chaussure) pour
effectuer
une distance (courte distance, moyenne distance ou longue distance) sur un site (liquide ou
Route) en utilisant un moyen de déplacement (nage, cyclisme ou course à pied).
domaine avec une classe « Objet » .
Thierry est un triathlète qui court à pied une moyenne distance sur la route
Départementale 3 avec ses chaussures.
Timothée est un triathlète qui nage une courte distance dans la mer méditerranée avec
un maillot de bain.
3) Dessiner un premier diagramme de classes avec les classes Triathlète, Nage, Maillot, Mer,
CourteDistance. Puis dessiner un autre diagramme de classes similaire au premier mais avec
des classes plus générales : Triathlète, MoyenDeplacement, Equipement, Site, Distance.
remarque peut-on faire ?
UML Exercices de base
58
Exercice « EXPRESSION »
Soit l’expression suivante : (X+Y/2)/(X/3+Y)
1) Identifier des classes pertinentes correspondant à cette expression.

2) Faire un diagramme de généralisation.
3) Faire un diagramme de classes.
4) Préparer le diagramme d’objets correspondant à l’expression.
Exercice « classification »
(f) Java, C++, Eiffel sont des langages orientés objet.
Exercice « brain-storming »
Préparer un diagramme d’objets montrant au moins 10 relations parmi les classes d’objets
suivantes. Inclure les associations les agrégations et les généralisations. Placer les ordre de
multiplicité.
(a) école, terrain de jeu, proviseur, conseil de classe, salle de classe, livre, élève, professeur,
cafétéria, ordinateur, bureau, chaise, porte.
(b) château, douve, pont-levis, tour, fantôme, escalier, donjon, plancher, couloir, salle, fenêtre,
Pierre, seigneur, dame, cuisinier.
(c) Automobile, roue, frein, moteur, porte, batterie, silencieux, pot d’échappement.
Exercice « attributs méthodes de classe ou d’instance »
Pour chaque propriété des classes UML suivantes, nous avons volontairement omis de la
souligner quand cela était nécessaire. En vous aidant du nom de la propriété et de sa
signification, indiquer si la propriété est "d'instance" ou bien "de classe".
Château
muraille : Muraille ;
listeTours : Liste ;
listeChateaux : Liste ;
void imprimerMuraille() ;
Objet
nombreObjets : int ;
mesObjets : Liste ;
numéro : int ;
59
60
Nom/Prénom :
Etablissement :
Spécialité :
Niveau d’étude :
Bloc modulaire :
Thème de la leçon : Objet, classe et association
• Différencier entre un objet et une classe

• Reconnaître les différents types de relations
• Reconnaître les multicipités
• Rappeler l’héritage…etc.
61
INTRODUCTION
Rappel
- Rappel sur les modèles de merise

- Rappel sur la façon pour trouvez les entités
- Rappel sur les différentes relations ainsi que les cardinalités
Diagramme de classe d’analyse
Le diagramme de classes est un des documents les plus importants, voire le plus important de
l'analyse d'un logiciel par une méthode objet. C'est le premier document qui est dans le monde
des objets (les acteurs n'étant pas forcément représentés dans le système informatique). C'est
donc l'entrée dans le monde des objets.
Ce diagramme est un diagramme de classe d'analyse. Il ne représente pas les classes Java ou
C++ que nous développerons par la suite.
Ici nous nous intéressons aux classes du domaine métier, c'est à dire des objets dont on parle
dans le cahier des charges et dans les uses cases principalement. Nous ne nous intéressons pas
aux objets informatiques dans ce diagramme (sauf bien entendu si le métier est l'informatique
!!). Cela viendra en son temps, dans le diagramme de classe de conception. Quand nous
passerons à la conception des classes disparaîtront, d'autres apparaîtront, dont les classes
informatiques (collections, …). C'est normal. En phase d'analyse, nous voulons simplement
faire un diagramme de classe d'objets manipulés dans le domaine métier considéré.
Dans ce diagramme de classe les opérations ne sont pas représentées (ce sera lors de la
conception).
Ce diagramme montrera les concepts du domaine métier, les liens (associations) entre ces
concepts (avec leur cardinalité ou multiplicité), et les attributs de ces concepts ( souvent sous
forme de données simples ).
Le but de ce diagramme est de clarifier le domaine métier du client, et de se familiariser avec
ce domaine.
Dans une analyse structurée nous décomposons l'analyse suivant les tâches ou les fonctions.
Dans une application à dominante gestion, nous décomposerons notre application suivant les
données, et les traitements. Ici nous analyserons la complexité du domaine en regardant les
objets métier et leurs interactions entre eux.
Partie -I-
-Notion d’objet :
Un objet est défini à la fois par des informations : données ou attributs ou variables
d’instances.
62
Comportements : traitements ou méthodes ou opérations.
Exemple :
Partie -II-
-Notion de classe :
Lorsque des objets ont les mêmes attributs et comportements : ils sont regroupés dans une
famille appelée : Classe.
Les objets appartenant à celle-ci sont les instances de cette classe.
L’instanciation est la création d’un objet d’une classe.
Deux instances d’une même classe peuvent avoir des attributs avec des valeurs différentes et
mais partagent les mêmes méthodes.
Partie -III-
Les relations :
L’association représente une relation entre plusieurs classes. Elle correspond à

l’abstraction des liens qui existent les objets dans le monde réel.
Client Achète
Produit
63
Agrégation est une forme particulière d’association entre plusieurs classes. Elle
exprime le fait qu’une classe est composée d’une ou plusieurs autres classes.
Bouteille Vin
La composition est une relation d’agrégation dans laquelle il existe une contrainte de
durée de vie entre la classe ‘composant’ et la ou les ‘composé’. Autrement dit la
suppression de la classe ‘composé’ implique la suppression de la des classes
‘composant’.
Exemple :
Commande LigneDeCommande
Généralisation de classe consiste à factoriser dans une classe, appelée superclasse, les
attributs et/ou opérations des classes considérées.
Exemple 1:
Généralisation
Classe A
A1 A2
La spécialisation représente la démarche inverse de la généralisation puisqu’elle

consiste à créer à partir d’une classe, plusieurs classes spécialisées.
Exemple 2:
Classe A
A1 A2
Spécialisation
64
L’encapsulation : les données ne sont accessibles qu’à partir des opérations définies
dans la classe. Le principe d’encapsulation renforce l’autonomie et l’indépendance de
chaque classe et donne une forte potentialité de définition de classe réutilisable.
Exemple 3:
Accès aux données I Classe x

via l’interface N Traitements
(Partie visible de T Données :
La classe) E Liste des
R attributs
F
A Liste des attributs
C
E
Le polymorphisme : est la capacité donnée à une opération de s’exécuter

différemment suivant le contexte de la classe où elle se trouve.
La persistance est la propriété donnée à un objet de continuer à exister après la fin de

l’exécution du programme qui l’a créé.
Par défaut dans l’approche objet, aucun objet n’est persistant. Les modèles décrivent
le système en exécution en mémoire centrale et ne tiennent pas compte a priori de
l’état du système qui doit être stocké sur disque.
L’héritage est un mécanisme qui permet d’assurer une grande variabilité dans la
réutilisation des objets. Il existe deux techniques liées à l’héritage : les classes
abstraites et l’héritage multiple.
Exemple 4:
Passager
poids:reel
donnerPoids():reel
Voiture
Super-classe
Conducteur Sous-classe
bouge(dir,vit):void
65
Exemple d’héritage multiple :
La classe C50 hérite des classes C1, C2 et C3.
Partie -IV-
Comment identifier les bons objets métier pour construire notre diagramme de classe
d'analyse?
Il va falloir recenser dans les documents de définition des besoins et dans les documents
d'analyse l'ensemble des objets métier.
Les noms ou groupes nominaux vont être de bons candidats pour être élus au titre de classe,
objet ou attribut. Cependant, il faut être prudent car il y aura aussi un certain nombre de faux
amis et de doublons.
66
Voici une démarche de sélection des classes candidates:
Par use case, nous réaliserons un diagramme de classe, le diagramme final étant la
superposition de tous ces diagrammes.
Pour un use case nous recenserons les groupes nominaux rencontrés. Nous identifierons alors:
• Les classes (noms communs).
• Les objets (noms propres ou nom référencés).
• Les attributs (données simples qui qualifient une classe ou un objet).
• Les éléments qui sont étrangers à notre problème ou qui n'y ont pas de rôle réel.
• Les " classes fonctionnelles " qui ne sont porteuses d'aucune information, mais seulement
de traitement, qui ne sont souvent pas des classes de notre diagramme. Par exemple
gestionnaire du planning, décodeur de message, …
• Il est parfois difficile de savoir si une information est un attribut d'une classe ou une
classe (avec une association avec la classe). Dans le doute il vaut mieux faire une classe,
quitte à revenir en arrière dans une itération ultérieure. Par exemple pour la classe personne
l'âge est un attribut (donnée simple) l'adresse étant à priori une donnée complexe sera plutôt
une autre classe associée à la personne.
• Les entités suivantes peuvent prétendre à devenir des classes :

- les objets physiques (produit…),
- les transactions (réservation, commande,….),
- les lignes de transaction (ligne de commande…),
- les conteneurs (catalogues, lots,…),
- les organisations (services, départements,….),
- les acteurs ou les rôles (client, fournisseur….),
- les regroupements en abstraction (modèle, genre, type, catégorie….),
- les évènements (vol,…)
Pour le use case " effectuer un achat " voici la liste des classes sélectionnées:
caissier
caisse
Paiement catalogue
vente
article
ticket
ligne de vente
67
Nous ne gèrerons pas les exemplaires des articles. Nous appèlerons article un ensemble
d’exemplaires identifiés par le même code barre, et comportant des informations identiques
(prix …).
Nous allons maintenant rajouter les associations entre les classes, en donnant un intitulé
et des cardinalités à ces associations.
Notre but n'est pas de mettre à jour toutes les associations entre les différentes classes, mais
de noter les associations pertinentes pour comprendre le problème. Il faut privilégier les
associations qui durent dans le temps, et dont la connaissance est nécessaire à la
compréhension du problème.
Il faut éviter les associations redondantes ou dérivables d'autres associations.
L'établissement de ces associations nous amène à poser des questions au client. C'est un des
buts recherchés. Voici une possibilité de diagramme de classe avec ses associations.
caissier
0..1
catalogue
utilise
1 1
0..1
caisse
se fait à partir
1
Paiement 1 effectue
payée par 0..1
1 1
vente
génèr 1 1
e contient
ticket comprend
1
1..*
ligne de
vente
0..*
est décrite par
1 0..*
article
Sur ce diagramme de classe d'analyse il faut maintenant mettre les attributs des classes qui ont
été repérés dans le cahier des charges, le diagramme de use case, ou dans le diagramme de
séquence boîte noire du use case.
A priori, les attributs présents dans notre diagramme de classe d'analyse sont des attributs
simples. On pourra faire exception des données pures qui sont des regroupements de données
simples ( ici code, adresse, prix ) .
68
Les attributs qui ont un comportement sont des classes associées à notre classe. Ceci ne
présage en rien du diagramme de classe de conception. Nous verrons ultérieurement ce que
deviennent les associations dans ce schéma…
Dans les attributs, il ne doit pas y avoir de clef sur un autre objet. Cela se représente par une
association.
Voici notre diagramme de classe enrichi des attributs d'analyse.
caissier
0..1
catalogue
utilise
1 1
0..1
caisse
se fait à partir
1
Paiement
effectue
somme : réel 1 0..1
payée par 1
1 Vente
date : Date
heure : Heure
génère 1 contient
1
ticket
1 comprend
1...*
1..*
ligne de vente
quantité : entier
0..*
le prix ou la
somme devraient est décrite par
0..*
se donner par 1
rapport à une description article
monnaie...
description : text
prix : réel
code : codebarre
69
CONCLUSION
Donner les différents types de relation avec des exemples ?

En UML une composition est :
* une opération entre trois classes
* une association d’héritage entre deux classes
* une association qui indique qu’une classe en contient une autre
* un attribut composé de plusieurs attributs
3) En UML, quelle est l’expression vraie exprimée par le diagramme suivant :
Client Compte
1..1
0..*
4) En UML quelle est la signification d’une généralisation :

* relation d’inclusion entre 2 classes
* génération d’une opération conceptuelle
* relation de dépendance hiérarchique entre deux classes
* n’existe pas en UML.
Exercice «classification »

(f) Java, C++ et Eiffel sont des langages orientés objet.
Exercice
70
suivante :
Les
personnes sont ou bien des guides, ou bien des animateurs, ou bien des passagers. Les
guides expliquent des visites aux passagers et les animateurs animent des animations pour
les passagers.
Exercice « JARDINIER »
Un jardinier effectue deux types de travaux : l’arrosage et le piochage. L’arrosage consiste à

arroser des plantes (tulipes, eucalyptus ou géraniums) avec un outil (arrosoir ou tuyau)
contenant de l’eau et le piochage consiste à retourner la terre avec un outil (pioche ou pelle)
pour y mettre de l’engrais. Autrement dit, le jardinier utilise un outil (arrosoir, tuyau, pelle ou
pioche) pour mettre une ressource (eau ou engrais) sur un objet naturel (terre ou plante) ;
celuici
est produit par un travail (arrosage ou piochage).
domaine avec une classe « Objet ».
Jacques est un jardinier qui arrose 3 géraniums avec un arrosoir rempli d’eau.
Jules est un jardinier qui pioche la terre avec une pelle pour y mettre de l’engrais.
3) Dessiner un premier diagramme de classes avec les classes Jardinier, Arrosage, Arrosoir,
Eau, Geranium. Puis dessiner un autre diagramme de classes similaire au premier mais avec
des classes plus générales : Jardinier, Travail, Outil, Ressource, ObjetNaturel.
4) Quelle difficulté posent les classe Eau, Terre, Engrais ?
Remarque peut-on faire ?
Exercice :

suivante :
Les personnes sont ou bien des guides, ou bien des animateurs, ou bien des passagers. Les
guides expliquent des visites aux passagers et les animateurs animent des animations pour les
passagers.
71
72
Nom/Prénom :
Etablissement :
Spécialité :
Niveau d’étude :
Bloc modulaire :
Thème de leçon : Diagramme de contexte
• Déterminer la frontière du système
• Définir les cardinalités des acteurs par rapport au système
• Préciser les rôles de chaque acteur
• Définir les événements des acteurs vers le système
73
INTRODUCTION
Rappel
Le diagramme de contexte
Le diagramme de contexte définit les intentions entre les acteurs et le système, et les
différents rôles de chaque acteur vers le système ainsi que les cardinalités
Diagramme de contexte
Les objets déterminés serviront lors des phases analyse, conception et plus tard à
l’implémentation.
Les objets du modèle statique sont une représentation (modélisation) des objets (monde réel),
qui seront en général ceux qu’on retrouve lors de l’implémentation sous la même forme ou
sous une forme différente.
Ils sont munis de données encapsulées dans les objets, représentant leurs attributs et leurs
opérations (méthodes).
La notation du diagramme de contexte

La notation du diagramme de contexte est une forme modifiée de la notation des DFDs, ne
différant que par le niveau des détails qu'elle fournit et par l'ajout d'un symbole spécial - le
terminateur (terminator). Les symboles contextuels sont illustrés à la figure 6
Les symboles du diagramme de contexte
74
Les définitions de ces symboles sont les suivantes:
• Une transformation de contexte représente la totalité du comportement exigé du

système. Elle reçoit le numéro 0 (zéro), bien que ce numéro ne soit normalement pas
représenté. Son nom suit le format d'une phrase comportant un verbe et un objet,
définissant la fonction complète du système.
• Les terminateurs représentent les composants de l'environnement d'un système,
organisés en groupes aux comportements prédéfinis. Ils peuvent avoir des noms
physiques, puisqu'ils représentent habituellement le comportement d'équipements
existants.
• Les magasins ou dépôts externes représentent les interfaces dans lesquelles
l'information a été entreposée. Ce sont des composants qui font partie de
l'environnement et non du système!
Règles du diagramme de contexte
Les règles pour l'interconnexion des composants des diagrammes contextuels sont
illustrées à cette figure.
Connexions autorisées dans les diagrammes de contexte
Définition de ses règles
Les règles qui s'appliquent au diagramme de contexte sont:
75
* Une seule transformation de contexte peut apparaître sur le diagramme contextuel d'un
système donné.
* Les terminateurs peuvent figurer à plusieurs exemplaires pour plus de commodité, cela
étant indiqué par un astérisque accolé à leur nom
(Utilisé lorsqu'ils ont des interfaces complexes).

* Les terminateurs ne peuvent pas être connectés les uns aux autres sur ce diagramme.
Toute interconnexion sera définie dans un modèle
stratégique approprié.
* Un diagramme contextuel donné peut être dessiné sur plusieurs pages, chacune comportant
la même transformation de contexte, mais un ensemble différent de terminateurs (n'est
utilisé que lorsque des interfaces très complexes sont rencontrées).
Exemple 1 :
Acteur 1 Acteur 2
Système
Acteur 3
Les événement externes ( ) sont envoyés des acteurs vers le système. Alors ce qu’il
nous permet d’identifier les déférents use cases.
Exemple d’un diagramme de contexte correct
76
CONCLUSION
Généralement le diagramme de contexte n'existe pas dans UML, mais est néanmoins très
intéressant
Il emprunte le même formalisme qu'un diagramme de collaboration.
Compléter le diagramme de contexte du SI Approvisionnement
Bon de Fournisseur
Commande
Fournisseur
Si
Achats
Corrigé
Bon de Fournisseur
Commande
77
Fournisseur Catalogue de produits
Bon de livraison Si Achats Rapport de

conformité Responsable
78
79
Nom/Prénom :
Etablissement :
Spécialité :
Niveau d’étude :
Bloc modulaire :
Thème de la leçon : Diagramme de séquence
- Déterminer la classifications des événements ou bien les uses cases
- Préciser les acteurs qui ont participés dans ce diagramme
80
INTRODUCTION
Rappel
Les diagrammes de séquences
• Les diagrammes de séquences permettent de représenter des collaborations entre

objets selon un point de vue temporel, on y met l'accent sur la chronologie des envois
de messages.
• Contrairement au diagramme de collaboration, on n'y décrit pas le contexte ou l'état

des objets, la représentation se concentre sur l'expression des interactions.
• Les diagrammes de séquences peuvent servir à illustrer un cas d'utilisation.
• L'ordre d'envoi d'un message est déterminé par sa position sur l'axe vertical du
diagramme ; le temps s'écoule "de haut en bas" de cet axe.
• La disposition des objets sur l'axe horizontal n'a pas de conséquence pour la
sémantique du diagramme.
Les diagrammes de séquences et les diagrammes d'état transitions sont les vues
dynamiques les plus importantes d'UML.
81
Diagramme de séquence
Objet :
• objet dédié: une instance particulière d'une classe
• objet anonyme : n'importe quelle instance d'une classe
Stimulus :
• une instance de message i.e. représentation de l'échange d'information entre objets
Supporte des flots de données et divers types de synchronisation
Déroulement temporel :
• vertical: représente la ligne de vie des objets et les périodes d'activité des objets
• horizontal: représente l'enchaînement des stimuli entre 1 objet émetteur et 1 objet
récepteur i.e. les flots de contrôle (séquence, répétition, alternative)
Syntaxe générale d’un diagramme de séquence
En résume deux types de diagramme de séquence :
Diagramme de séquence boite noir : c’est le diagramme simple c'est-à-dire on ne détaille

pas les événements.
Diagramme de séquence boite blanche : son principe est de détailler le diagramme de
séquence boite noir c'est-à-dire il détaille chaque opération qui a un sens vers le système (
)
Par exemple on a ci dessous un diagramme de séquence boite noir qui décrit tous les
événements entre le system et les acteurs (client, caissier)
82
Client Cassier Système
Présenter article
Lire article (code)
Affiche (prix et désignation) Plusieurs

Si qte>0
Saisir quantité
Plusieurs Calcule sous
Affichage (sous total) total
Finir vente
Calcule total
Affichage (total)
Paiement
Payer (somme)
Calcule
Affichage (monaie) monaie
Impression (ticket)
Rendre (ticket, monaie)
Temps
Pour faire un diagramme de séquence boite blanche il suffit de détailler chaque opération (
)
Dans un diagramme
Comme exemple on détaille l’opération (FINIR VENTE)
Caissier Caisse System
Finir vente
Set terminer (true)
Set (total)
Total
83
Temps
La différence entre un diagramme de séquence d’analyse et un diagramme
de séquences de conception
Calculer (total)
Temps
– Un diagramme de séquences (ici, il s’agit d’un diagramme de séquence

d’analyse)
de vie d’un objet. Par exemple, sur la figure 17, on a fait apparaître le délai de 250
millisecondes entre le moment où l’utilisateur appuie sur un bouton et le moment où le
voyant correspondant s’allume.
Deux notions, liées au contrôle des interactions s’avèrent utiles :
– la première est la condition qui indique quand un message doit être envoyé. Le
message ne sera transmis que si la condition est vérifiée. On indique les conditions
entre crochets au-dessus de l’arc du message ;
84
– la seconde est la façon de marquer la répétitivité d’un envoi de message. Par
exemple, si l’on doit répéter un appel pour toute une collection d’objets (pour
tous les éléments de la liste des demandes), on fera précéder le dénominateur du
message par un « * ».
Un diagramme des séquences permet de vérifier que tous les acteurs, les classes, les
associations et les opérations ont bien été identifiés dans les diagrammes de cas et de
classes. Il constitue par ailleurs une spécification utile pour le codage d’un algorithme
ou la conception d’un automate.
Le diagramme de séquence de conception ci-dessous permet de voir un exemple
dans lequel la signature des méthodes est à peu près formalisée.
Temps
Un diagramme de séquences de conception
Autre exemple du diagramme de séquence
Exemple 1
85
Saisie compte
Validation compte
Demande type
Retrait liquide (220F)

Vérification solde compte
Autorisation délivrance Débit compte
temps Guichetier Système guichet Système central
Exemple2
Appelant Ligne Appelé
décrocher
a
{b-a < 1 sec}
tonalité
b
{c-b < 10 sec}
Taper chiffre
c
d
routage
{d’-d < 5 sec}
d’
sonner sonner
décrocher
Arrêt sonnerie Arrêt sonnerie
86
Exemple 3
Durant : Objet SA :
ANPE
Personne Société
Demande développeur C++

Proposition
Demande d’entrevue
Convocation
Entrevue
Bilan
Attribution du poste
Notification d’embauche
Exemple 4
87
Interface Objet 1 : Objet 3 :
Frontière
Acteur Classe1 Classe3
du système
commenceSession
(nom, pass) vérifieMotPasse
(pass)
Objet 2 :
^MotPasseOk Classe2
créé ajouteSession
ouvreSession
Retour
de
fermeSession
Temps Message
sur
l’objet
Bloc Destruction
d’opération De l’objet
Exemple 5
Dupont : OOsoft : ConseilRecrut

Personne Société
Propose poste consultant objet
Convocation Proposition CV Dupont pour ce poste
Entrevue
Bilan
Embauche
Notification d’embauche
88
• Chaque réception de message donne lieu à une durée d'activation : le temps de
traitement du message
• La durée d'activation de l'émetteur recouvre celle du récepteur
• Type de messages :
• flot de contrôle à plat :
• message synchrone
• message asynchrone
• flot de contrôle emboîté ou appel de procédure (avec attente implicite du
retour)
• retour d'un appel de procédure, avec ou sans paramètre de retour
Exemple 6
89
90
CONCLUSION
Un diagramme de séquence détaillé UML en conception technique est utilisé pour :

• comporter un diagramme de classes en trouvant de nouveaux attributs
• ce diagramme n’est utilisé en conception technique
• structure la logique d’une application informatique
• ordonner la séquence des composants graphiques dans une fenêtre Windows
Exercice d’évaluation N°1
Dessiner le diagramme de séquences du simulateur de voitures de la création du

simulateur jusqu’au déroulement de la simulation.
Pour vérifier votre bonne compréhension, on vous demande de nommer les objets de votre
diagramme avec les noms utilisés dans le corrigé en C++.
Remarque : Dans ce diagramme, on suppose ne pas connaître ni la classe du fournisseur,

ni la classe de la voiture.
Corrigé
91
Exercice d’évaluation N°2
Ouvrir et sauvegarder
A) Enoncé
Dans un programme interactif développé avec le pattern MVC, on donne la possibilité à
l’utilisateur :
- de sauvegarder un document sur un support permanent,

- de charger en mémoire un document existant sur un support permanent.
1) Des trois classes Modèle, Vue et Contrôleur qui intercepte les demandes
de sauvegarde ou de chargement de l’utilisateur.
2) On pourrait en poussant la philosophie un peu loin confier l’exécution des

demandes à une vue dédiée à la communication vers le support permanent.
Pourquoi, cependant, il est plus naturel de donner la mission au

modèle ?
3) Donner le diagramme de séquence relative à une demande de

chargement d’un document en mémoire.
B) Corrigé
1) Une demande de sauvegarde ou de chargement est faite par l'utilisateur.

C'est donc le contrôleur qui doit intercepter cette demande.
2) Etudions séparément les deux cas : Sauvegarde et Chargement :
Charger un document consiste à redéfinir complètement le contenu du

document en mémoire.
Il paraît donc naturel que cette action soit une méthode du modèle.
La sauvegarde du document met à jour le document sur le support

permanent.
L'état d'un document est donc toujours une certaine conjonction entre son état
en mémoire et son état sur le support permanent.
Le document sur le support permanent est donc un prolongement du document
en mémoire.
92
93
Nom/Prénom :
Etablissement :
Spécialité :
Niveau d’étude :
Bloc modulaire :
Thème de la leçon : Diagramme d’activité
Objectif de la leçon :
Connaître la déférence entre les états et les activités
Ainsi que les événements qui déclanche des résultats
entre toutes les activités possibles
Prévoir les itérations
Associer la synchronisation (disjonction et conjonction d’activités)
94
INTRODUCTION
Rappel
UML permet de représenter graphiquement le comportement d'une méthode ou le

déroulement d'un cas d'utilisation, à l'aide de diagrammes d'activités (une variante des
diagrammes d'états transitions).
Une activité représente une exécution d'un mécanisme, un déroulement d'étapes
séquentielles.
Le passage d'une activité vers une autre est matérialisé par une transition.
Les transitions sont déclenchées par la fin d'une activité et provoquent le début immédiat
d'une autre (elles sont automatiques).
Transition
Pour passer au diagramme d’activité il faut tenu compte au condition et les événements ainsi
que les différents type de transition.
Diagramme d’activité
Le diagramme d’activité est très proche du diagramme état transition puisqu’il représente le
comportement interne d’une opération ou d’un d’utilisation en termes d’actions.
Les concepts de base d’activités et de transition déjà définis sont repris dans le diagramme
d’activités. Cependant, le diagramme d’activité utilise le concept d’état action qui correspond
à un état dans lequel se déroule une action et au minimum une transition automatique vers un
autre état.
Représentation d’un diagramme d'activité :
Transition
Activité1 Activité1
Comment construire 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
95
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 grande étape de la
méthode.
4. Ajouter des transitions (séquentielles), des transitions alternatives (conditionnelles),
des synchronisations entre des activités, des itérations.
5. Identifier des swimlanes et répartir des activités identifiées dans ces swimlanes
Notion d’activité
• Etat de départ
• Etat de terminaison
• Transition
• Transition Alternative
Notion de diagramme d’activité

Synchronisation disjonctive et conjonctive
96
Exemple 1 :
Représentons le cycle de vue d'une entreprise :
Etat initial
Croissance
-Innovation
Création
Matricule
Chute
Faillite
Exemple 2:
Diagramme d'activité avec synchronisation
97
[plus de
Chercher un café
jus d’orange]
[il reste du
jus d’orange]
Mettre un filtre Remplir Prendre une tasse

Le réservoir
D’eau
Prendre
Mettre du café un jus d’orange
Allumer la cafetière
Le café passe
Servir
Synchronisation
Déguster
Exemple 3:
L'exemple suivant illustre l'utilisation des barres de synchronisation :
98
Couloirs d'activités :
Afin d'organiser un diagramme d'activités selon les différents responsables des actions
représentées, il est possible de définir des "couloirs d'activités".
Il est même possible d'identifier les objets principaux, qui sont manipulés d'activités en
activités et de visualiser leur changement d'état
.
99
CONCLUSION
En théorie, tous les mécanismes dynamiques pourraient être décrits par un diagramme
d'activités, mais seuls les mécanismes complexes ou intéressants méritent d'être représentés.
Exercice 1
Elaborer un diagramme d’activité représentant la saisie d’un texte sous Word, et l’impression
Exercice 2
Construire un diagramme d’activité représentant l’utilisation d’une cafetière électrique:
– premier état: chercher du café
– dernier état: Servir du café
Solution
100
Exercice 3
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.
Solution
Commander
produit
Traiter
commande
Sortir
articles
Expédier
commande Facturer Payer
client facture
Encaisser
101
102
Nom/Prénom :
Etablissement :
Spécialité :
Niveau d’étude :
Bloc modulaire :
Thème de leçon : diagramme de collaboration
• Décrire le comportement collectif d’un ensemble d’objet

• En vue de réaliser une opération
En décrivant leurs interactions modélisées par des envois
(Éventuellement numérotés) de messages
103
INTRODUCTION
Rappel
Diagramme de collaboration :
• Les diagrammes de collaboration montrent des interactions entre objets (instances de

classes et acteurs).
• Ils permettent de représenter le contexte d'une interaction, car on peut y préciser les
états des objets qui interagissent.
Transition
Attente
Actif
Diagramme d’état
1 : m() :o1
1.1 : msg()
:o2
Diagramme collaboration
A partir d’un diagramme d’état en passe à réaliser un diagramme de collaboration
104
Utilité de diagramme de collaboration
Le diagramme de collaboration va nous montrer comment les objets interagissent entre eux
pour rendre le service demandé par le contrat d'opération. Nous allons d'abord observer la
syntaxe, et la forme que prend ce diagramme d'opération. Les objets doivent demander des
services à d'autres objets. Il leur faut donc connaître ces objets pour pouvoir leur adresser des
messages. Nous allons donc regarder la visibilité des objets (c’est à dire comment un objet
peut connaître d'autres objets). Enfin quand une ligne du contrat d'opération est réalisée il faut
se poser la question de savoir quel objet agit pour réaliser cette ligne (qui crée tel objet, qui
reçoit l'événement initial). En un mot il est nécessaire de définir les responsabilités des objets.
L'expérience et le savoir faire des professionnels nous ont permis de définir des règles, des
modèles de pensée, qui nous permettrons de nous guider pour définir les responsabilités des
objets. Ce sont les GRASP patterns que nous verrons enfin, avant de traiter notre caisse.
La notion collaboration
Deux notions fondamentales :

• Le contexte : vue statique partielle des objets
• Les interactions : séquences de messages échangés par les objets
Représentation générale de diagramme de collaboration :
Syntaxe du diagramme de collaboration

Nous allons prendre un exemple de diagramme de collaboration pour introduire toutes les
notions véhiculées dans ce diagramme. Rappelons nous que ce diagramme, dans le contexte
de la conception, nous montre comment les objets coopèrent entre eux pour réaliser les
opérations définies par les contrats d'opération.
Modifierprix(code,prix) :caisse 1 :Modifierprix( :catalog
code,prix)
1.2 : setprix(prix)
art : article
: article
105
Les objets
Ici nous représentons la coopération des objets pour rendre le service demandé. Il s’agit
donc bien d’objets. Ces objets apparaissent sous trois formes :
Les objets anonymes ( : caisse, :catalogue). A comprendre la caisse courante, où le

catalogue courant…
Les objets nommés (art : article). A comprendre que c’est bien le type d’article qui
correspond au code cherché.
Les multi objets ( : article). A comprendre comme la collection des types d’article
associée
au catalogue
Objet
1 :Modifierprix
Modifierprix(c :caisse (code,prix) :catalog
ode,prix)
1.1 :art :=
1.2 : Multi objet
Objet setprix(prix)
nommé
art : article
: article
Conditions sur l’envoi des messages
L’envoi d’un message peut être assorti d’une condition
• UML permet de spécifier de manière très précise l'ordre et les conditions d'envoi des
messages sur un diagramme dynamique.
• Pour chaque message, il est possible d'indiquer :

o les clauses qui conditionnent son envoi,
o son rang (son numéro d'ordre par rapport aux autres messages),
o sa récurrence,
o ses arguments.
106
• Retour d’une liste de valeurs à l’issue d’un envoi de
• Message
Une liste de valeurs peut être retournée suite à l’envoi d’un message
-NB :
Pour rendre les messages plus spécifiques il est de préférable de les affecter des conditions et
des attributs comme ci-dessus :
• Pour chaque message, il est possible d'indiquer :

o les clauses qui conditionnent son envoi,
o son rang (son numéro d'ordre par rapport aux autres messages),
o sa récurrence,
o ses arguments.
• La syntaxe d'un message est la suivante :
[pré "/"] [["["cond"]"] [séq] ["*"["||"]["["iter"]"]] ":"] [r ":="] msg"("[par]")"
o pré : prédécesseurs (liste de numéros de séquence de messages séparés par une

virgule ; voir aussi "séq").
Indique que le message courant ne sera envoyé que lorsque tous ses
prédécesseurs le seront aussi (permet de synchroniser l'envoi de messages).
107
o cond : garde, expression booléenne.
Permet de conditionner l'envoi du message, à l'aide d'une clause exprimée en
langage naturel.
o séq : numéro de séquence du message.

Indique le rang du message, c'est-à-dire son numéro d'ordre par rapport aux
autres messages. Les messages sont numérotés à la façon de chapitres dans un
document, à l'aide de chiffres séparés par des points. Ainsi, il est possible de
représenter le niveau d'emboîtement des messages et leur précédence.
Exemple : l'envoi du message 1.3.5 suit immédiatement celui du message 1.3.4
et ces deux messages font partie du flot (de la famille de messages) 1.3.
Pour représenter l'envoi simultané de deux messages, il suffit de les indexer
par une lettre.
Exemple : l'envoi des messages 1.3.a et 1.3.b est simultané.
o iter : récurrence du message.

Permet de spécifier en langage naturel l'envoi séquentiel (ou en parallèle, avec
"||") de messages. Notez qu'il est aussi possible de spécifier qu'un message est
récurrent en omettant la clause d'itération (en n'utilisant que "*" ou "*||").
o r : valeur de retour du message.

Permet d'affecter la valeur de retour d'un message, pour par exemple la
retransmettre dans un autre message, en tant que paramètre.
o msg : nom du message.
o par : paramètres (optionnels) du message.
3 : bonjour ()
Ce message a pour numéro de séquence "3".
[heure = midi] 1 : manger()
Ce message n'est envoyé que s'il est midi.
1.3.6 * : ouvrir()
Ce message est envoyé de manière séquentielle un certain nombre de fois.
3 / *||[i := 1..5] : fermer()
Représente l'envoi en parallèle de 5 messages. Ces messages ne seront envoyés qu'après

l'envoi du message 3.
1.3,2.1 / [t < 10s] 2.5 : age := demanderAge(nom,prenom)
108
Ce message (numéro 2.5) ne sera envoyé qu'après les messages 1.3 et 2.1, et que si "t < 10s".
1.3 / [disk full] 1.7.a * : deleteTempFiles()

1.3 / [disk full] 1.7.b : reduceSwapFile(20%)
Ces messages ne seront envoyés qu'après l'envoi du message 1.3 et si la condition "disk full"
est réalisée. Si cela est le cas, les messages 1.7.a et 1.7.b seront envoyés simultanément.
Plusieurs messages 1.7.a peuvent être envoyés
Conclusion sur les messages :
La syntaxe des messages

Message D’abord le
initial Caisse catalogue
issu du envoie un cherche
Modifierprix(code
,prix) 1 :modifierprix(cod
:caisse :catalogu
e,prix)
Puis il
modifie le 1.1 :art := chercher(code) :
prix de article
1.2 :
l’article
trouvé
art : article
: article
109
Le message initial est non numéroté par convention. Ce message est un des événements issu
du diagramme de séquence boîte noire, dont nous avons fait un contrat d’opération.
Les opérations effectuées en réponse à ce message seront numérotées de 1 à n (notons qu’en

général n n’est pas très élevé, si la conception est bien faite).
Les opérations effectuées en réaction à un message numéro x seront numérotées de x.1 à x.n.
Et ainsi de suite pour les opérations effectuées en réaction à un message numéro x.y (x.y.1 à
x.y.n).
Un message a la forme suivante
Un lien entre deux objets est directionnel. La flèche indique le receveur du message. Ce lien
implique que l’objet qui envoie le message connaisse celui qui le reçoit. Un objet ne peut en
effet envoyer un message qu’à un objet qu’il connaît (rappelez-vous que l’on envoie un
message à un objet en lui parlant : moncatalogue, modifie le prix de l’article de code moncode
à monprix.). Chaque flèche implique une visibilité orientée entre les objets.
Exemple 1 :
:ihmClient 5: consulter compte
4: entrer n° compte
3:
:consultationController
sinon:Client
6: obtenir solde
:Compte
Exemple 2
110
Exemple 3 :
Exemple 4 :
111
(6) Débit compte
(4) Retrait espèces

Guichetier Système Central
(3) Demande type (7) Autorisation (5) vérification solde

d’opération délivrance compte
(2) Validation compte

(1) Saisie compte Système guichetier
Exemple 5 :
Dupont: estCandidat Conseil Recrut:

Personne CabinetRecrutement
Convoquer(unPoste) ProposerPoste
(unPoste)
ProposerCandidats
signer PasserEntrevue()
(desCandidats,unPoste)
signer estClient
New OOsoft:Sociéte
Ct1:ContratTravail
Embaucher(unPoste) NotifierEmbauche(unPoste)
EffectuerBilan()
CONCLUSION
Un diagramme de collaboration est utilisé pour :

* schématiser la collaboration entre un composant et une base de données
* montrer comment les objets participent avec une interface graphique
* montrer comment les objets inter -agissement entre eux
ce diagramme n’est pas utilisé en conception technique.
Exercice 1
112
Définir un diagramme d’état du déroulement d’une voiture (marche avant,
marche arrière, point mort …)
A partir de ce diagramme réaliser un diagramme de collaboration
Exercice 2
A partir de ce diagramme d’état distributeur de boisson réalisé un diagramme

collaboration
113
114
Nom/Prénom :
Etablissement :
Spécialité :
Niveau d’étude :
Bloc modulaire :
Thème de la leçon : Diagramme d ’Etat
- Faire tous les états possibles d’un objet
- Etudier les conditions de transition
- Définir la durée d’un état
115
INTRODUCTION
Rappel
Diagramme d’un état : il montre les différents états des objets en réaction aux événements.
L’état d’un objet et défini, à un instant donné, par l’ensemble des valeurs de ses propriétés.
Transition : c’est le passage d’un état à un autre.
Un événement : est un fait survenu qui déclanche une transition.
Une action : est une opération instantané qui ne peut être interrompue ; elle est associée à
une transition.
Une activité : est une opération d’une certaine durée qui peut être interrompue,
Elle est associée à un état d’un objet.
Transition
A fin d’extraire les classes et les objets il faut réfléchir de tous les cas possibles
de ce dernier
116
C’est un graphe composé de nœuds représentant des états d’un objet d’une classe et
les arcs sont les transitions portant des événements.
Un diagramme d’états est propre à une classe d’objets.
Un état d’un objet peut correspondre à des sous états. Cela dépend du niveau de
granularité qu’on désire.
Exemple :
L’état Sportif peut être représenté par trois sous états : Athlète Haut Niveau ; Sélection en E.N.
et Compétition.
Les sous états sont représentés comme des états.

Dans un diagramme d’états on peut développer un état d’un objet par un sous
diagramme d’états avec des points d’entrée et des points de sortie. De telle sorte on
peut passer d’un état à un sous état et inversement.
Convocation
Athlète Haut Niveau
Sélection en Equipe
Nationalle
Disputer
Suivre parallèlement
Compétition
Changer carrière
La notion d’état
Un état d’un objet est défini à la fois par la valeur de ses attributs et de ses liens avec les
autres objets.
Il représente ainsi un intervalle de temps.

L’objet est dans un état initial et peut alors changer d’état.
Etat
• Abstraction des valeurs d'attributs et de liens d'un objet
• Un état a une durée (intervalle de temps entre deux événements)
• spécifie la réponse à un événement
• État et événement sont duaux
Un événement sépare deux états
117
Un état sépare deux événements
Schéma général :
Etat 1 transition [condition]/action Etat 2

Faire: activité 1 faire : activité 2
Exemple : cette figure montre un des actions et activités d’états ainsi que la description
complète d’une transition
Etat 1 maladie [arrêt]/réception arrêt Etat 2

Faire : travaille faire : mise en arrêt
Etudiant Pratiquer
InscritEn * *
Nom
Prénom
Âge
Statut 0..*
*
Diplôme Sport
Ici l’objet Etudiant peut passer d’un état Etudiant à un état de diplômé à un état de sportif,
C’est l’attribut Statut qui va changer de valeur.
Représentation d’un état :
Etudiant
Diplômé Sportif
Un événement est produit par un fait et véhicule une information qui va
solliciter un ou plusieurs objets.
Soit ils répondront en activant une méthode ; soit ils ne réagiront pas du tout.
Cela dépend de l’état dans lequel se trouve (nt) l’ (les) objet(s).
Un événement peut être interne ou externe au système.
118
Lorsqu’un objet provoque un événement en direction d’un autre objet, ce dernier
peut répondre en déclenchant une de ses méthodes
C’est une interaction entre ces deux objets. L’événement est qualifié alors de
message entre ces deux objets.
Exemple 1 :
Exemple 2 :
Etat Etat final
Evénement condition
Naissance Décès
Anniversaire (âge) [âge=18]

Mineur Majeur
Etat transitio
Exemple 3 :
Demande création fermeture fermeture accomplie
retrait (s) dépôt(s)
[Solde >0] [Solde >0]

Créditeur
En dépôt
[Solde ≤0] [Solde ≤0]

Débiteur
119
Exemple 4 :
Raccroché
État initial Décroché

Attente Pièce Taper numéro urgence
Insérer pièce/
En communication
credit=0
Taper un numéro
Attente nontant
État final
Exemple de distributeur de boisson
Remarque :
Plusieurs sous diagrammes d’états peuvent intervenir en même temps. Ils se déroulent en
concurrence ou en synchronisation.
120
Lorsqu’ils sont en concurrence, le premier sous diagramme
d’état bloque les autres et fait quitter l’état englobant vers un
autre état.
Lorsqu’ils sont en synchronisation, la transition de l’état

englobant vers un autre état ne s’effectue que lorsque tous les
sous diagrammes le permettent. Aucun sous diagramme ne peut
être interrompu.
Sous diagramme d’état en concurrence.
Inscrit ANPE
AcceptationInsciption Petites annonces
Allocation
chômage
Proposition ANPE
OU Proposition Entrevue
En PhaseEmbauche
- Sous diagramme d’état en synchronisation
Demander Congé Assurer Fonctions
ET
En congé
Synthèse
Etat
Un état spécifie la réponse de l'objet aux événements d'entrée. Il est stable.
Il peut être caractérisé par un ensemble de valeurs d'attributs et de liens d'un objet.
Il correspond à l'intervalle de temps entre deux événements reçu par l'objet.
Transition :
Relation entre deux états indiquant qu’un objet dans le premier état va passer dans le
deuxième quand un événement particulier apparaîtra, et que certaines conditions seront
satisfaites.
Evénement:
121
Un événement est un stimulus pouvant transporter des informations (sous forme de
paramètres). Il est considéré comme n'ayant pas de durée.
Un événement peut être émis par un objet du système ou par un objet externe au système. Il
peut également provenir de l’interface du système, par exemple un clic de souris. Quelle que
soit son origine, un événement peut être soit dirigé vers un ou plusieurs objets, soit émis sans
destination précise dans le système, certains objets du système pouvant alors le capter.
La réponse d’un objet à un événement dépend de l'état dans lequel il se trouve autant que de
l'événement.
Remarque : la plupart des ouvrages et des outils de modélisation objet emploie les termes
événement et message indifféremment. En UML, un message est un événement particulier,
issu de l’interaction entre deux objets (un objet appelle une méthode d’un autre objet). Tout
événement n’est donc pas forcément un message.
Etats initial et final :
Chaque automate de classe doit préciser un état initial (état d’une instance juste après sa
création).
On peut également préciser les conditions de destruction en ajoutant un état final.
(création)
(néant) Etat initial
Evénement
Etat X (état
Condition
Une condition est une expression booléenne, attachée à un événement, qui doit être vraie pour
le déclenchement de la transition.
Elle est indiquée entre crochets à la suite du nom de l'événement
Refroidissement [temp < temp référence]

Chauffage Chauffage
à l'arrêt en marche
Réchauffement [temp > temp référence]
Action :
Une action est une opération instantanée. Elle est associée à un événement.
Elle représente une opération dont la durée est insignifiante comparée à la résolution (niveau
de définition) du diagramme d'état.
La notation d'une action sur une transition est précédée d’une barre oblique ("/").
Bouton droit activé / afficher menu

En attente Menu
visible
Bouton droit non activé / effacer menu
Curseur bougé / item de menu en

Activité :
122
Une activité est une opération qui dure un certain temps.
Elle est associée à un état. Elle peut être continue ou finie (se termine d’elle même).
Notation : "Do : activité".
Retrait [solde - retrait < 0]

Compte Compte débiteur
Créditeur Do: CalculAgio
Dépôt [solde + dépôt > 0]
Les diagrammes d’état peuvent s’exécuter une seule fois ou en boucle continue
Les diagrammes "une seule fois" (one–step-diagrams) représentent les objets qui ont une vie
finie.
Un diagramme "une seule fois" possède un état initial et un état final..
L'état initial est entré à la création de l'objet; l'entrée dans l'état final (qui peut éventuellement
prendre plusieurs conditions) implique, elle, la destruction de l'objet
Tour Echec et mat

Début Noir gagne
des blancs
pat
noir blanc
bouge bouge Partie nulle
pat
Tour
des noirs
Echec et mat Blanc
Diagramme en boucle continue
Ce diagramme qui décrit le comportement d'une ligne téléphonique, est une boucle continue.
On ne se soucie pas de savoir comment la boucle a démarré.
123
Combiné En attente Combiné
En tonalité Fin de En délai dépassé

Faire: jouer Faire: jouer bip
Fin de
Chiffre
En numérotation Message
Faux enregistré
Bon
Message
En connexion
Faire: trouver
Numéro
Acheminé
Sonnant Tonalité:
Faire: sonner "occupé"
Appelé répond / connecter
Connecté
Appelé raccroche / déconnecter
Déconnecté Fin de
L'événement "Combiné raccroché" provoque une transition de n'importe quel état vers l'état
"En attente".
Noter que les états ne définissent pas toutes les valeurs d'un objet; par exemple, l'état "En
numérotation" inclut toutes les séquences de numéros incomplets.
Ce n'est pas la peine de les différencier puisqu'ils ont tous le même comportement
Conclusion
124
1) Un diagramme d’états UML en conception technique est utilisé pour :

• Indiquer l’état d’une transaction dans une application avec base de données
• Définir la structure d’un état imprimé
• Découvrir certaines méthodes dans une classe données
• Ce diagramme n’est jamais utilisé en conception technique
Exercice
La montre
Bouton mode
22 :15 :35
Bouton avance
En fonctionnement normal, la montre affiche les heures, les minutes et les

secondes qui défilent.
Une pression sur le bouton mode sélectionne le chiffre des heures qui se
met à clignoter. A ce moment une pression sur le bouton avance
incrémente le compteur d’une heure.
Une nouvelle pression sur le bouton mode sélectionne le chiffre des
minutes qui se met à clignoter. A ce moment une pression sur le bouton
avance incrémente le compteur d’une minute.
Une nouvelle pression sur le bouton mode revient à l’affichage normal.
1) Dessiner le diagramme état -transition de cette montre.
2) On veut modifier le comportement de la montre pour que si on maintient la pression
sur le bouton avance au moins deux secondes, l’avancement des heures ou des minutes
se fasse en continu
Exercice 2
2-donner tous les états possibles d’un compte bancaire

2-donner les conditions pour passer d’un état à l’autre débuteur, créditeur…
(Exp.:mineur majeur il faut que age=18)
Exercice 3
Faire les transitions convenables aux états suivants pour faire un diagramme d’état de l’objet
client d’une gestion commerciale
125
Voici les états de client
client perspectif
client actif
client douteux
client inactif
client en contentieux
client supprimer
Exercice 4
D’écrire un diagramme d’état d’une bouteille avec toutes les conditions de passer d’un
état a l’autre
126
127
Nom/Prénom :
Etablissement :
Spécialité :
Niveau d’étude :
Bloc modulaire :
Thème de leçon : Diagramme de composants et déploiement
128
INTRODUCTION
Rappel
Le diagramme de déploiement « Où ranger les composant ? »
Le diagramme de déploiement montre la disposition physique des matériels qui

composent le système et la répartition des composants sur ces matériels.
Les ressources matérielles sont représentées sous forme de noeuds.
Les noeuds sont connectés entre eux, à l'aide d'un support de communication.
La nature des lignes de communication et leurs caractéristiques peuvent être précisées.
⇒ Les diagrammes de déploiement peuvent montrer des instances de noeuds (un matériel
précis), ou des classes de noeuds.
Le diagramme de composant « Le physique du système »
• Les diagrammes de composants permettent de décrire l'architecture physique et statique

d'une application en terme de modules : fichiers sources, librairies, exécutables, etc.
Ils montrent la mise en oeuvre physique des modèles de la vue logique avec
l'environnement de développement.
• Les dépendances entre composants permettent notamment d'identifier les contraintes de
compilation et de mettre en évidence la réutilisation de composants
• Les composants peuvent être organisés en paquetages, qui définissent des sous-systèmes.
Les sous-systèmes organisent la vue des composants (de réalisation) d'un système. Ils
permettent de gérer la complexité, par encapsulation des détails d'implémentation.
129
Diagramme de composants
Un système informatique comprend des composants physiques propres à l’environnement de

réalisation choisi. Le diagramme de composants permet de décrire ces composants qui sont :
le sous-système, le module, le programme et le sous-programme, le processus et la tâche.
Sous-systèmes : cette notion a déjà été présentée au paragraphe consacré aux paquetages.
Les trois icônes utilisées
Main Spécification
Exemple 1 :
130
Exemple 2 :
Diagramme de déploiement
Le diagramme de déploiement représente l’architecture physique des composants matériels

qui supportent l’exécution du système.
Chaque composant matériel, appelé aussi nœud est symbolisé par un cube. Les liens entre ces
composants permettent de décrire les supports physiques de communication.
Le diagramme de déploiement permet de représenter les classes de composants matériels ainsi
que des instances particulières de ces classes (objet). Un objet, instance d’une classe de
composant physique, est distingué dans le diagramme en soulignant le nom attribué à l’objet.
131
Exemple 1 :
Détermine le schéma général d’un diagramme de déploiement
Client SGBD
ServeurApplication
Exemple 2 :
132
Routeur IP
Uranus
Serveur BDD
ORACLE V7 Venus << RNIS Internet >>
Serveur exchange
Passerelle Internet
Saturne
Stockage << ligne spécialisée 64 IBM
de fichiers Kbps >> grand système
<< ethernet 100Mb >>
MVS
Station Mercure
d’administration Passerelle
SNA << Token Ring >> IBM
AS/400
Jupiter
Serveur
logiciels << Réseau téléphonique commuté >>
Pluton
Serveur impression
et communication Elara
Imprimante
Neptune
Serveur BDD
SQL Server
Exemple 3 :
133
Poste Client Serveur de BDD
BDD
Procédures
Pages stockées
WEB d’insertion
Serveur de
Serveur WEB traitement
ODBC
HTML
Objet
métier
ActiveX
Un diagramme de déploiement peut spécifier la répartition des traitements dans une

architecture client-serveur.
134
Bibliographie et Ressources
Penser Objet avec UML et Java de Michel Lai de chez Dunod
http://fr.wikipedia.org/wiki/Unified_Modeling_Language
UML Quick Reference Card (http://tnerual.eriogerg.free.fr/uml.html)
UML Quick Reference (http://www.holub.com/goodies/uml/index.html)
Grady Booch, James Rumbaugh, Ivar Jacobson (2000). Le guide de l'utilisateur

UML, ISBN 2212091036
UML 2 et les Design Patterns - Craig Larman (3ème édition), ISBN

2744070904
Martin Fowler et al. (2004). UML 2.0, ISBN 2744017132 : initiation aux aspects
essentiels de la notation
"http://developpeur.journaldunet.com/dossiers/alg_uml.shtml", UML en 5
étapes, MORLON J, avril, 2004.
"http://developpeur.journaldunet.com/tutoriel/cpt/031013cpt_uml5conseils.shtm
l", Cinq petits conseils pour un
schéma UML efficace, BORDERIE X, avril, 2004.
"http://eric.univ-lyon2.fr/~jdarmont/docs/sise-bd-ex_rel.pdf", Exercices -
Modèle Relationnel, DARMONT J, janvier,
2004.
"http://eric.univ-lyon2.fr/~jdarmont/docs/sise-bd-ex_uml.pdf", Exercices -
Modèle UML, DARMONT J, janvier,
2004.
Récupérée de « http://fr.wikipedia.org/wiki/Unified_Modeling_Language »
135
Logiciels de modélisation UML
Logiciels libres
• ATL solution open source pour faire des transformations de modèles vers ou depuis
UML (entre autres); ATL est un langage de type QVT.
• Dia
• Umbrello un modeleur UML sous GPL. Ne fonctionne pas correctement sous
Windows ;
• ArgoUml un modeleur UML sous Licence BSD ;
• Gaphor un modeleur UML sous GPL la version actuelle est 0.7.1 ;;
• BOUML, un modeleur UML sous GPL pour Windows, Linux, MacOS X et Solaris;
• Eclipse GMT-XUML, en version betâ.
• Eclipse UML2, Méta modèle UML2, sans interface graphique.
• Netbeans 5.5, en version preview.
• Staruml, en version libre.
• Acceleo, générateur de code source à partir de modèles UML.
Logiciels propriétaires
• Together, de Borland ;
• Poseidon, basé sur ArgoUml (version commerciale) ;
• Rational Software Architect / Rational Software Modeler (et toujours Rose/XDE), de
IBM Software Rational ;
• PowerDesigner, de Sybase (un outil de modélisation complet intégrant l'UML en plus
des classiques MCD, MPD ...) ;
• Objecteering de Softeam ;
• Visual Paradigm for UML, de Visual Paradigm Internation Ltd. ;
• SDE for Eclipse, un plugin UML pour Eclipse ;
• Omondo EclipseUML, un plugin UML pour Eclipse ;
• Jude [1], en Java ;
• MagicDraw, un éditeur de diagrammes UML ;
• Enterprise Architect, un outil de modélisation UML ;
136
Modélisation objet avec UML
Etude de cas : Application de contrôle d'accès à un bâtiment
Le but est de protéger un bâtiment en restreignant l'accès à certaines salles.

L'ouverture de chacune des portes de ces salles est commandée par un lecteur de
Badges placé à proximité. Les badges qui permettent l'ouverture des portes ne sont
Délivrés qu'aux personnes qui doivent accéder aux locaux protégés dans l'exercice de
leurs fonctions. Les droits d'accès sont alloués entre les groupes de personnes et les
Groupes de portes, de sorte qu'une personne ou une porte doit toujours être au moins
dans un groupe (le sien).
Un groupe de portes peut contenir des portes dispersées dans tout le bâtiment. Une
porte donnée ne peut appartenir qu'à un seul groupe de portes.
La même personne peut appartenir à plusieurs groupes, de sorte que ses droits d'accès
Correspondent à l'union des droits d'accès de chacun des groupes qui la contiennent.
La définition des droits d'accès est effectuée en décrivant pour chaque groupe de
personnes les différents groupes de portes qui sont accessibles et sous quelle
contrainte horaire. Les droits d'accès sont décrits dans un calendrier annuel qui décrit
la situation semaine par semaine. Vu la faible variation des droits dans le temps, un
Calendrier peut être initialisé au moyen de semaines types qui décrivent une
configuration de droits donnée. Le superviseur peut créer autant de semaines type
qu'il le désire. Les changements apportés à une semaine sont automatiquement
propagés dans tous les calendriers qui utilisent cette semaine type.
Le système de contrôle d'accès doit fonctionner de la manière la plus autonome
possible. Un superviseur est responsable de la configuration initiale et de la mise à
jour des différentes informations de définition des groupes de personnes et de portes.
Un gardien dispose d'un écran de contrôle et est informé des tentatives de passage
infructueuses. Les alarmes sont transmises en temps légèrement différé: la mise à jour
de l'information sur l'écran de contrôle est effectuée toutes les
minutes.
1. Décrire la vue des besoins (use case view) de ce système de contrôle d'accès.
Cette analyse des besoins consiste à définir :
les acteurs de ce système.
le diagramme des cas d'utilisation du système.
les principaux scénarios de chaque cas d'utilisation qui seront décrits par des
diagrammes de séquence (point de vue temporel).
2. Décrire la vue logique (logical view) de ce système. Cette analyse du domaine
consiste à définir :
le diagramme des classes.
décrire les principaux scénarios par des diagrammes de collaboration
(interactions entre objets d’un point de vue spatial). Il est bien évidemment
possible de représenter les interactions entre objets par des diagrammes de
séquence.
Corrigé
137
138
139
140
141
Etude de cas : Application gestion de caisse
Un commerçant de produits touristique (souvenirs, livres régionaux,…) désire
informatiser sa caisse. Chaque type de produit possède un code unique (étiquette à code à
barres), et un même prix pour tous les produits de ce type. L'objectif est de faciliter la
maintenance des prix des articles.
142
Chaque type de produit est référencé dans un catalogue, puis sur l'étagère ou il est rangé.
Le cassier s'identifie pour démarrer la caisse (avec mot de passe).
La caisse fera les fonctions habituelles d'une caisse : calcul du sous total, calcul du total,
possibilité de rentrer plusieurs articles ayant un même code, retour d'une marchandise avec le
ticket de caisse. Le paiement se fera en monnaie seulement.
La caisse permet d'éditer des rapports:

• Le reçu qui sera donné uniquement pour une vente effective. Il contient le
Nom du magasin, un message de bienvenue, la date et l'heure. Puis pour chaque vente il
donne le code du produit, la description du produit, le prix unitaire, la qualité et le sous
total.
Enfin nous y trouvons le total TTC.
• Le rapport quotidien de l'ensemble des ventes (date, heure, total).
• Le rapport quotidien détaillé : liste de l'ensemble détaillé des ventes de la journée.
La caisse s'exécute sur un PC. Une douchette permettra de lire les codes à barres. Les
informations peuvent être rentrées au clavier, ou à la souris.
Première étape : les exigences et les acteurs

Les exigences que nous allons découvrir sont les exigences fonctionnelles. A partir du
problème posé, c'est-à-dire de tout ce qui est écrit, plus tout ce qui ne l'est pas, nous
allons lister l'ensemble des fonctions qui pourront être réalisées par le logiciel. Ces
exigences seront numérotées pour pouvoir les tracer dans les intentions d'acteur puis dans
les uses cases.
143
référence fonction
R1 Modifier le prix d'un produit
R2 Calculer le total d'une vente
R3 Rentrer une quantité par article
R4 Calculer le sous total d'un produit
R5 Retourner une marchandise
R6 Payer l'achat
R7 Editer un ticket de vente
R8 Editer un rapport succinct
R9 Editer un rapport détaillé
R 10 Se connecter à la caisse
R 11 Se connecter en gérant
R 12 Définir les droits des usagers
R 13 Entrer un produit au catalogue
R 14 Supprimer un produit du catalogue
R 15 Enregistrer un produit à la caisse
R 16 Initialiser la caisse
Regardons maintenant les acteurs qui gravitent autour de notre application.

Un acteur humain a bien une intention quand il fait quelque chose.
♀
Caissier
♀Client
♀
Manager
♀
Salarié
♀
Administrateur
Les acteurs de l'application
Ce diagramme est un diagramme de classe qui permet de lister les différents acteurs. Il se
peut que notre liste ne soit pas complète, une itération suivante du processus nous permettra
de compléter ce schéma.
144
Nous avons défini 5 acteurs. N'oublions pas qu'un acteur représente un rôle, et non pas une
personne.
Le manager peut être aussi l'Administrateur (notion de rôle).

Un salarié est soit un caissier, soit le Manager. Il se peut que dans la première itération
l'analyse ne remarque pas ceci. C'est souvent dans une itération ultérieure que nous verrons
les généralisations d'acteurs.
Nous connaissons les acteurs, et les exigences de l'application. Nous pouvons donc faire un
diagramme de contexte dynamique.
Gérer un retour d'article

Editer un ticket
Enregistrer un produit
Enregistrer un produit
Gérer un paiement
♀ Client
♀
caissier
Retourner un article gérer la catalogue

Payer un achat initialiser les caisses
Editer des rapports
Magasin
Se connecter
♀
Salarié définir les droits des usagers
♀
manager
♀
Administrateur
Diagramme de contexte de magasin
♀
Client
♀
Caissier
Est à la caisse
Est dans
145
magasin
Gère
Travaille dans
♀
Salarié
administre ♀
Manager
♀
Administrateur
Diagramme de contexte statique (capture initiale des besoins)
Deuxième étape : les intentions d'acteurs
Nous allons maintenant regrouper les exigences en intentions d'acteurs. Une intention d'acteur
est un enchaînement de fonctions qui rend un service complet à un acteur (et pas une fraction
de service).
Référence Fonction Intention d'acteur acteurs
146
R1 Modifier le prix d'un produit Gérer le catalogue Manager
R 13 Entrer un produit au catalogue Gérer le catalogue
R 14 Supprimer un produit du catalogue Gérer le catalogue
R 16 Initialiser la caisse Initialiser la caisse Manager
R5 Retourner une marchandise Retourner un article Client, Caissier
R 10 Se connecter à la caisse Se connecter Salarié
R 11 Se connecter en gérant Se connecter
R8 Editer un rapport succinct Editer un rapport Manager
R9 Editer un rapport détaillé Editer un rapport
R 12 Définir les droits des usagers Définir les profils Administrateur
R7 Editer un ticket de vente Effectuer un achat Client, Caissier
R6 Payer l'achat Effectuer un achat
R2 Calculer le total d'une vente Effectuer un achat
R3 Rentrer une quantité par article Effectuer un achat
R 15 Enregistrer un produit à la caisse Effectuer un achat
R4 Calculer le sous total d'un produit Effectuer un achat
Ici dans le tableau la notion d'acteur repose sur l'intention d'acteur, pas sur la fonction. Ainsi
toutes les lignes d'une même intention d'acteur ne sont-elles pas renseignées pour les acteurs.
Ici nous distinguerons l'acteur principal des acteurs secondaires en soulignant l'acteur qui est à
l'origine de l'intention.
Nous allons bien sûr vérifier que les exigences définies précédemment sont toutes incluses
dans les intentions d'acteur. La traçabilité est un facteur essentiel des phases de définition des
besoins et de celle d'analyse.
Nous avons les intentions d'acteurs, nous pouvons donc faire un diagramme de Use Case.
Toute cette démarche peut être faite d'une autre manière:

*nous déterminons les acteurs et les exigences.
*A partir des exigences nous faisons un diagramme d'activité (UML) en colonnes
(swimlane). Chaque colonne correspond à un acteur. Cela nous permet de définir les
responsabilités des acteurs, donc de définir les Uses Cases correspondants.
Gestion d’une bibliothèque municipale
Objectifs : établir le diagramme de cas d’utilisation, le diagramme de classe
Il s’agit de réaliser un logiciel de gestion des prêts de documents aux lecteurs d’une
bibliothèque municipale. L’usager demande sur poste informatique qu’un document lui soit
communiqué. Le
lecteur se voit attribué un numéro lors de son inscription. Un système de fiches existe pour la
recherche
documentaire qui n’est pas informatisée actuellement.
147
Si le lecteur est déjà inscrit, il s’identifie puis remplit. Sur le terminal informatique la
demande de document souhaité. il sélectionne le document désire et le lieu ou il souhaite
consulter le document (sur place ou à domicile).
Il existe en fait plusieurs type de documents : journaux, livres et microfilm. Chaque usager
dispose de droits différents en fonction de sa profession et de son employeur. Ces droits sont
valides pour une année et correspondent à des niveaux de confidentialité. Certains documents
sont consultables uniquement sur place, d’autres peuvent être emportés à domicile. Pour
consulter sur place, un emplacement doit être affecté au lecteur dans une salle adaptée au
document.
Si le document n’est pas disponible pour le moment, le système fournit au lecteur une fiche
de réservation comprenant une date de disponibilité et une place réservé (en cas de
consultation sur place).le lecteur peut ensuit venir à la date prévue utiliser sa réservation.
Si le document est disponible, le système imprime une fiche qui permet au lecteur de retirer
son document au guichet. L’employé valide alors le prêt sur son poste informatique et
enregistre le retour lorsque le lecteur rend le document. En cas d’emprunter à domicile.
L’usager à une semaine pour rendre le document.
L’usager peut à tout moment consulter l’état de ses demandes (prêts et/ou réservation en
cours). Il ne pourra effectuer un emprunt que s’il a rendu les document déjà empruntes.
Chaque document possède une cote. Un journal possède un titre, une date et un numéro. Un
livre possède un titre et un ou plusieurs auteurs. Les microfilms ont été tirés à partir de
certains journaux.
Le système fournit à l’employé, chaque soir après le départ du dernier client, la liste des
documents consultés sur place qui n’ont pas rendu. Le responsable du service des prêts peut à
tout moment demander au système la liste des prêts à domicile non rendu à la date prévue.
Ceux-ci seront classés par nombre de jours de retard, afin de pouvoir éditer les lettres de
relance. Il peut aussi obtenir différentes statistiques.
Corrigé
Définition des besoins
Liste des exigences
référence Fonction
R1 Inscrire un nouveau lecteur
R2 Enregistrer la cotisation d’un lecteur
R3 Enregistrer un nouveau document
R4 Sortir un document
R5 Vérifier la disponibilité d’un document
R6 Restituer un document
R7 Consulter la liste des documentation rendus
R8 Editer une lettre de relance
148
R9 Emprunter un document
Liste des acteurs
Les acteurs principaux de ce système sont :

L’usager
L’employé
Les intentions d’acteur
On classera les références ci–dessus dans ce tableau d’exigences :
Référence Fonction Intension Acteur

R1 -Inscrire un nouveau Gestion des lecteurs L’employé
lecteur
R2 -Enregistrer la
cotisation d’un
lecteur
R3 - Enregistrer un Gestion des L’employé
nouveau document documents
R4 - Sortir un document Gestion des L’employé
R6 - Restituer un emprunts/restitutions
document
R7 - Consulter la liste Gestion des relances L’employé
des documentation
rendus
R8 - Editer une lettre de
relance
R5 -Vérifier la Vérification de la L’employé
disponibilité d’un disponibilité d’un L’usager
document document
R9 -Emprunter un Emprunter un L’usager
document document
Diagramme de cas d’utilisation ( use case )
L’employé L’usager
149
Gérer les lecteurs
Gérer les documents
Verrifier la disponibilité
D’un document
Gérer les emprunts /restitutions
Gérer les relances
Emprunter un document
*Use case description haut niveau :
1-Gérer les lecteurs
• Nom de use case : gérer les lecteurs

• Acteur principale : l’employé
• Acteur secondaire : l’usager
• Evénement déclencheur de use case : le nouveau lecteur arrive chez l’employé et
demande d’emprunter un document
• Rôle de use case : l’employé saisit les informations du lecteur ,enregistrer sa cotisation
et lui demande de remplir la demande de document souhaité
• Références croisées exigences :R1,R2
• Terminaison de use case : l électeur prend son document et s’en va pour le consulter
soit sur place soit à domicile.
2-Gérer les documents
• Nom de use case : gérer les documents

150
• Acteur secondaire : ----------
• Evénement déclencheur de use case : un nouveau document arrive à la bibliothèque
• Rôle de use case : l’employé enregistre le nouveau document et lui donne un numéro
• Références croisées exigences :R3
• Terminaison de use case : le document est enregistré et placé avec les autres de même
type
3-vérification la disponibilité d’un document
• Nom de use case : vérifier la disponibilité d’un document

• Evénement déclencheur de use case : un lecteur arrive et demande un document pour
l’emprunter
• Rôle de use case : l’employé entrer le numéro de document pour le rechercher
• Références croisées exigences :R5
• Terminaison de use case : le système renvoi a l’employé le résultat de recherche
4-gérer les emprunte /restitution
• Nom de use case : gérer les emprunte /restitution

• Evénement déclencheur de use case : un usager représente chez l’employé pour
emprunter un document ou restituer
• Rôle de use case : en cas d’emprunt l’employé enregistre le document dans la liste des
documents prêts , en cas de restitution il place le document dans sa propre place
• Références croisées exigences :R4,R6
• Terminaison de use case : le document est soit prêt soit restitué à la bibliothèque
5-Gérer les relances

• Nom du use case : gérer les relances.
• Acteur principal : l’employé.
• Acteurs secondaires : -------
• Evénement déclencheur du use case : l’employé demande au système la liste des
usagers n’ayant pas rendu les documents dans leur propriété.
• Terminaison du use case : l’employé imprime des lettres de relance pour
les envoyer.
• Références croisées des exigences : R7, R8
*Analyse
+Diagramme de séquence boite noire :
151
-pour le use case détaillé « Emprunter un document » :
L’usager l’employé le système
Se présente pour emprunter un document
Entrer le n° du document pour vérifier

Sa disponibilité
Si le
Recherche
document est
document
disponible
Répond l’employé
Lui donne une fiche pour la remplir
Remplit la fiche et la rend à l’employé
Enregistre le document dans la liste

lui donne le document
des prêts avec le nom de l’usager
- pour les use case détaillé « Gérer les lectures »
L’usager L’employé le système
Se présente pour emprunter un document
Lui demande de fournir ses informations
Si nouveau
lecteur Enregistre les informations du lecteur
Lui demande le document qu’il souhaite
Fournit le nom du document
Si le
document est Enregistre les cotisations de l’usager
disponible
Prête le document au lecteur
152
+Diagramme de classe d’analyse :
Employé lecteur
-code int
-Matricule int 1..1 inscrire 1..* -Nom String
-Nom String -Prénom String
-Prénom String -Adresse String
+Employé() +void lecteur()

+void gérer lecteur() +void emprunter()
1..* 1..*
Bibliothèque emprunter
Travaille pour 1..1
-Nom String
-Adresse String
+void bibliothèque
1..*
1..1 Document
1..* -code int
-type String
Se trouve dans
+void document
+Contrat d’opération :
-l’opération :inscrire un lecteur
• Nom : inscrire un lecteur

• Responsabilité : inscrire un nouveau lecteur dans la bibliothèque
• Exigences : R1, R2
• Notes : une fois le lecteur inscrit, il peut emprunter des livres quand il
veut
• Pré conditions : le lecteur doit payer une cotisation
• Post conditions : le lecteur peut emprunter le livre ou le document qu’il veut
-l’opération :emprunter un document
• Nom : emprunter un document

• Responsabilité : emprunter un document pour le consulter sur place ou à domicile
153
• Notes : --------
• Pré conditions : le document doit être disponible, et le lecteur ne doit avoir aucun
document non restitué
• Post conditions : le document et enregistré emprunté par le lecteur
*Conception
+Diagramme de classe de conception :
Employé lecteur
-code int
-Matricule int 1..1 inscrire 1..* -Nom String
-Nom String -Prénom String
-Prénom String -Adresse String
+Employé () +void lecteur()

+void gérerlecteur () +void emprunter ()
1..* 1..*
Bibliothèque emprunter
Travaille pour 1..1
-Nom String
-Adresse String
+void bibliothèque ()
1..*
1..1 Document
1..* -code int
-type String
Se trouve dans
+void document ()
Journal Livre Microfilm

-Titre String -titre String -journal String
-date Date -auteur String
-numéro int +microfilm ()
+livre ()
+journal ()
154

Cours Uml 1

Transféré par

Droits d'auteur :

Formats disponibles

Cours Uml 1

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours Uml 1

Transféré par

Droits d'auteur :

Formats disponibles

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du

TITRE DU MODULE : Spécification fonctionnelle d’une

Niveau : TECHNICIEN Spécialisé

MME.BENNANI WAFAE DIRECTRICE CDC TERTIAIRE & TIC

Les utilisateurs de ce document sont invités à

OBJECTIF OPERATIONNELS DE PREMIER NIVEAU

Pour démontrer sa compétence, le stagiaire doit spécifier

• Epreuve écrite de type étude de cas

CRITERES GENERAUX DE PERFORMANCE

• Utilisation des commandes appropriées.

A. Analyser le cahier des charges • Description précise des limites du projet

B. Créer et gérer le dictionnaire des • Formalisation exacte du dictionnaire des

C. Modéliser • Application judicieuse de la démarche et

D. Installer et Utiliser un outil de

E. Créer le dossier de spécification

LE STAGIARE DOIT MAITRISER LES SAVOIR, SAVOIR-FAIRE, SAVOIR -PERCEVOIR OU

Avant d’apprendre à analyser le cahier des charges (A) :

1. Expliquer l’intérêt d’un cahier de charge

Avant d’apprendre à Créer et gérer le dictionnaire des données et des

3. Expliquer l’intérêt du dictionnaire des données et des règles de gestion

Avant d’apprendre à Modéliser (C ) :

4. Expliquer le formalisme de chaque méthode (Merise et UML)

Avant d’apprendre à Utiliser un outil de modélisation (D) :

6. Expliquer l’intérêt d’utilisation d’un outil de modélisation

L’approche objet : une solution ?

Les inconvénients de l’approche objet

• Moins intuitive que l’approche fonctionnelle ou chaque fonction du système est

Il nous faut donc :

De limiter les ambiguïtés en permettant un discours commun avec un

Thème de la leçon : Les cycles de vie

Matériels et matière d’œuvre : Exercices

Une démarche de développement repose sur :

Les étapes du cycle de vie d'une application :

• Expression des besoins : Il traduit l'apport du futur système.

Il est important de déterminer chaque cycle de vie étape par étape

Les différents cycles de vie

Ce que le système doit être et comment il peut être utilisé.

Elle doit décrire chaque objet selon 3 axes :

• Axe fonctionnel : savoir-faire de l’objet.

• On y définit les structures et les algorithmes.

• Cette phase sera validée lors des tests.

C’est la réalisation de la programmation.

Les tests de vérification :

Deux sortes de maintenances sont à considérer :

Une maintenance corrective, qui consiste à traiter les “bugs ”.

Une maintenance évolutive, qui permet au système d’intégrer de nouveaux besoins

Conception des Tests des

Autre représentation de cycle en V

Etude détaillée Validation fonctionnelle

Etude technique Tests d’intégration

Le modèle en “V” permet une organisation modulaire.

Le processus s’accomplit en deux phases :

Etude préalable Dossier de choix avec proposition et évaluation de

Etude détaillée Spécifications fonctionnelles complètes futur S.I.

Mise en service Application informatique installée

Le cycle de vie Objet

La traçabilité entre les étapes :

Tests de Expression des