Aoo Uml

ANALYSE ET DESIGN AVEC UML
UNE INTRODUCTION
© 2006, Philippe Kouao, NTIC/DED/SNDI, Abidjan
1
Table des matières
 Introduction à l’analyse orientée objets et au design

 Historique
 Développement Itératif et Incrémental
 Cycle de vie du développement d’un système
 Comportement du système
 Analyse du comportement requis avec l’approche des
cas d’utilisation
 Scénarii et objets
 Développement de scénarii pour les cas d’utilisation
 Recherche d’objets pour les scenarii identifiés
2
Table des matières (suite 1)
 Interactions entre objets

 Représentation graphique d’un scénario
 Classes et paquetages
 Définition des classes, stéréotypes et paquetages
 Diagrammes de classes
 Relations
 Recherche des relations requises pour
interactions entre objets
 Opérations
 Structure et comportement
3
 Héritage
 Recherche de facteurs communs entre les classes
 Comportement d l’objet
 Les diagrammes de transition
 Design de l’architecture
 Les « 4+1 » vues architecturales
 Mécanismes clés
4
 Design des classes

 Interface utilisateur
 Les « patterns »
 Design des relations

 Design des attributs
 Design pour l’héritage
5
Introduction à l’analyse orientée objets et au
design
6
Introduction à l’analyse orientée objet
Objectifs:
 A la fin de ce chapitre, vous devez pouvoir:

 Décrire les méthodologies usuelles de développement
 Expliquer la crise liée aux logiciels
 Discuter des atouts de la technologie orientée objet (00)
 Discuter des domaines dans lesquels la technologie OO
peut être utilisée

 Définir l’analyse et le design
 Expliquer les origines de UML
7
Introduction à l’analyse orientée
objet
Les méthodologies usuelles de
développement
 Le modèle en cascade
 Le modèle en spirale
 Le modèle itératif et incrémental
8
objet
Les méthodologies de
développement
Le modèle en cascade
 Chaque étape doit être bouclée avant que la

suivante ne soit entamée
 Ce modèle simpliste (et facile a gérer) s’avère
inadéquat quand la taille et la complexité du projet
augmentent.
o Les problèmes majeures sont:

o Les larges systèmes doivent être entièrement compris et analysés avant le design.
La complexité croit et devient difficile a gérer au niveau des développeurs
o Les risques croissent avec le temps. Les problèmes majeurs surviennent dans les
dernières phases surtout lors de l’intégration
o Les coûts de rectification augmentent exponentiellement avec le temps
o Pour les grands projets, chaque étape prends un temps considérable (maintient
d’une équipe sur +1 ans pour des tests???)
© 2006, Philippe Kouao, NTIC/DED/SNDI, Abidjan 9

Introduction à l’analyse orientée Introduction à l’analyse orientée objet
objet
développement
 Vu que l’analyse n’est effectuée uniquement qu’en amont, nous courrons le grand risque
de ne pas réellement comprendre les besoins du client
 Malgré le suivi de procédures rigoureuses et la signature de documents par le client, les
chances que le produit final après le design, l’implémentation, l’intégration et les tests ne
réponde pas aux attentes du client restent élevées

10
objet
développement
 Le modèle en cascade n’est pas mauvais en soi.

 Il est efficace quand le projet est relativement « petit » :
 Piloté par une petite équipe
 Chaque personne de l’équipe comprends tous les aspect du
système
 La durée du développement est courte (quelques mois)
 Ce modèle vaut beaucoup mieux que le chaos.

 Il devient moins adéquat quand la complexité s’accroît.
11
objet
développement
Le modèle en spirale
 Dans ce modèle, le projet est divisé

en une suite de petits cycles,
aboutissant chacun à la production
d’un logiciel exécutable.
12
objet
développement
Avantages:
 L’équipe projet travaille sur tout le cycle de vie du projet (analyse,
design, code test) au lieu de passer beaucoup du temps sur une seule
phase
 Le feedback client peut de faire beaucoup plus tôt et ce de façon
régulière
 Les problèmes majeurs peuvent être identifiés plus tôt avant que le
développement ne soit trop avancé.
 L’entendue et la complexité du travail peuvent être très tôt identifiés
 Les évolutions technologiques peuvent être facilement incorporées
 La production régulière d’exécutables est bonne pour le moral
LeKouao,
©2006, Philippe statut du projet
NTIC/DED/SNDI, Abidjan (% de réalisation) peut être mieux estimé.
13
objet
développement
Inconvénients:
 Ce modèle est communément associé au développement rapide
d’application
 Le processus est plus difficile a gérer. Les techniques classiques
de gestion de projet telles que les chartes de GANTT ne peuvent
plus s’appliquer. D’autres techniques sont requises.

14
objet
développement
Le modèle itératif et incrémental
 Ce modèle est une extension logique du modèle en spirale a la

différence qu’il introduit du formalisme et de la rigueur.
 Ce modèle comprends 4 phases:
 Initiation
 Élaboration
 Construction
 Transition
Initiation Construction
Élaboration Transition

15
objet
développement
Initiation:
 Cette phase défini les contours du projet et sa charte
 Les livrables possibles sont:
 La charte du projet
 Une exploration initiale des besoins du client
 Dossier financier (prévisions financières, critères de succès, retour
sur investissement etc.)
 Évaluation des risques associés au projet
 Plan du projet

16
objet
développement
Élaboration:
 Cette phase permet d’analyser le problème, d’agrémenter le plan du
projet et d’éliminer les parties risquées du projet.
 A la fin de cette phase, l’équipe projet a une compréhension global du
projet (pas encore en profondeur)
 2 modèles de UML aident dans cette phase:
 Les cas d’utilisation (Use Case Model), permettent de comprendre
les besoins du client
 Les diagrammes de classes qui permettent d’explorer les concepts
majeurs soumis par le client

17
objet
développement
Construction:
 Dans cette phase, le produit est construit
 Elle ne se fait pas de façon linéaire mais suit le modèle en
spirale, en passant par une série d’itérations.

 Chaque itération suit le modèle en cascade.
 En réduisant la durée de chacune des itérations, les

problèmes liés au modèle en cascade peuvent être évités.

18
objet
développement
Construction:
•L’objectif à l’issue de chaque itération est de disposé d’un système

exécutable.
•Le système devient de plus en plus opérationnel avec les itérations
•Les fonctionnalités sont ajoutées par incréments.

19
objet
développement
Transition:
 Cette phase finale concerne le transfert de l’application chez le client
 Les activités typiques sont:
 Les versions bêta
 Les tests d’intégration
 La reprise des données
 La formation des utilisateurs
 Le marketing, la distribution et la vente
 Cette phase ne correspond pas a la phase de test dans le
modèle en cascade. Avant cette phase, le produit doit
déjà être testé.
20
objet
développement
Exemples de modèles itératifs

 Le RUP (Rational Unified Process)
 http://www-306.ibm.com/software/awdtools/rup/
 Le XP (eXtreme Programming)
 http://www.extremeprogramming.org/
 Le AUP (Agile Unified Process)
 http://www.ambysoft.com/unifiedprocess/agileUP.html
 Le EUP (Enterprise Unified Process)
 http://www.enterpriseunifiedprocess.com/

21
objet
La crise logicielle
Less than 5% Used with no changes
Used With
Changes
More than 95% Required

Major Rework Req’d changes or
was unusable
Delivered But Unusable
Paid for But Not Delivered

Source: US. Government Data
22
objet
La crise logicielle
 Le département des véhicules motorisés de l’État de Californie
a dépensé plus de $ 43 millions pour fusionner le fichier des
permis de conduire avec celui de l’immatriculation de véhicules
 Le système a été abandonné sans jamais avoir été utilisé
 American Airlines a perdu $ 165 millions pour relier son système
de réservation avec celui de Mariott, Hilton et Budget.
 L’aéroport de Denver a perdu des millions de dollars US avec le
report de son ouverture suite au dysfonctionnement du système
informatique des bagages
Source:
Rapport sur les échecs logiciels par W. WaytGibbs,
Scientific American, Septembre 1994
23
objet
La crise logicielle
 En mars 1989, la cabinet Arthur Andersen a rapporté que
 plus de $300 milliards par an sont dépensés dans des activités
tournant autour des logiciels aux USA
 Les logiciels livrés et fonctionnels ne représentent que 8% de cette
manne
 Les raisons de la crise logicielle
 Évolutivité des besoins
 Échecs dans la gestion des risques
 Complexité des logiciels
24
objet
La crise logicielle
Évolutivité des besoins

 Les besoins initiaux sont généralement mal définis ou exprimés
 Les cycles de développement courts sont une nécessité
 Les clients attendent plus en termes de flexibilité
25
objet
La crise logicielle
Échec dans la gestion du risque

 Le modèle en cascade peut retarder l’identification des
problèmes
 Rien ne prouve que le système fonctionnera en fin de cycle
 Le résultat est l’augmentation du risque
26
objet
La crise logicielle
La complexité des logiciels

 La demande de solutions métiers augmente sans cesse
 Personne ne comprend totalement le système
 La maintenance des systèmes doit être assurée mais les
développeurs initiaux sont partis
27
objet
Les atouts de la technologie 00

 Un seul paradigme
 Langage simple utilisé par les utilisateurs, les analystes, les
designers, les développeurs
 Facilite la réutilisation de l’architecture et du code
 Modélise mieux le monde réel
 Décrit plus précisément les données et processus
 Décompose sur la base de partitionnements naturels
 Facile a comprendre et a maintenir
 Stabilité
 Une modification mineur dans les besoins ne nécessite pas
forcement des changements importants du système en
construction
28
objet
Simple exemple de commande
29
objet
Diagramme de classes
30
objet
Effet d’un changement dans les besoins

Au cas ou une nouvelle compagnie de transport doit être prise en compte…
© 2006, Philippe Kouao, NTIC/DED/SNDI, Abidjan …seule la classe Camion doit être modifié
31
objet
Domaines d’application
 Systèmes Graphique
 L’approche 00 facilite le design et l’implémentation
de systèmes avec Interface Graphique (Mac OS,
Windows XP, Gnome etc.)
32
objet
 Systèmes Embarqués
 Les méthodes 00 permettent aux systèmes
embarqués et temps réel d’être développés avec
qualité et flexibilité
33
objet
 Traitements Client/Serveur
 Les approches 00 permettent d’encapsuler les
informations dans des objets, réduisant la taille
des application a livrer
34
objet
 Re-engineering
 Les méthodes 00 permettent de faire du re-
engineering sur des parties d’un système,
protégeant ainsi les investissements en logiciels
existants
35
objet
Analyse et Design Orientés Objet
36
objet
Analyse et Design 00
Qu’est ce que UML?

 Unified Modeling Language (Langage de Modélisation Unifié)
 Langage décrit dans « The Unified Modeling Language for
Object Oriented Development » écrit par Grady Booch, Jim
Rumbaugh et Ivar Jacobson
 Disponible depuis http://www.rational.com/
 Basé sur les expériences personnelles des auteurs

 Inclus les contributions d’autres méthodologistes
 Soumis à l’OMG (Object Management Group) par Rational
Software (IBM), Microsoft, HP, Oracle, Texas Instrument, MCI
Systemhouse et autres.
37
objet
Origines de UML
38
objet
Origine de UML (2)
39
objet
Les 4+1 vues d’un modèle UML
40
objet
Avantages de UML
 Permet une transition fluide de l’analyse au design et à
l’implémentation
 Défini une notation consistante et expressive:
 Facilite la communication
 Aide à isoler les omissions et inconsistances
 S’applique aux petites et larges analyses
41
objet
Conclusion
 De nouvelles techniques de développement sont requises
pour juguler la crise logicielle
 Les besoins ne sont pas stables
 Les logiciels deviennent complexes
 Les clients exigent le maximum de flexibilité
 La technologie 00 a plusieurs atouts
 Paradigme unique
 Les modèles sont calqués sur le monde réel
 Elle facilite la réutilisation de l’architecture et du code
 Elle offre plus de flexibilité
 Un changement mineur dans les besoins n’implique pas des
modifications majeures du système en développement
42
objet
Conclusion
 La technologie OO est utilisée pour différents types de
systèmes
 Systèmes graphiques, embarqués, client serveur et re-
engineering
 L’analyse OO est une méthode dans laquelle les besoins
sont exprimés en termes des objets décrits par le problème
 S’appuie sur le QUOI
 Dans le design 00, le modèle issue de l’analyse est raffiné,
avec l’ajout de détails et des décisions de design requises
pour implémenter le modèle
 S’appui sur le COMMENT
43
objet
Conclusion
 La méthodologie UML a été développé par Grady Booch, Jim
Rumbaugh et Ivar Jacobson en collaboration avec plusieurs
autres sur la base de leurs expériences collectives.
 UML support 4+1 vue architecturales
 La vue Logique
 La vue de Développement
 La vue des Traitements
 La vue Physique
 La vue des cas d’utilisation/scenarii
44
45
Développement itératif et incrémental
46
Objectifs:

 Définir le processus de développement itératif et
incrémental (PDII)
 Lister les étapes, résultats et activités majeures
pour chacune des phases d’un PDII
 Définir une itération et lister ses activités
47
Le Développement Itératif et incrémental

 Le Développement Itératif et incrémental (DII) est le
processus de construction d’un logiciel par petites étapes
 Avantages
 Réduction des risques sur la base d’un feedback
 Flexibilité dans la prise en compte des changements de besoins
et de nouveaux besoins
 Amélioration de la qualité des logiciels
48
Le Développement Itératif et Incrémental
Le Cycle de Vie Logiciel

 Le cycle de vie logiciel est divisé en cycles ou le livrable d’un
cycle donné est la création d’un produit
 Chaque cycle est une succession des phases:
 Initiation
 Élaboration
 Construction
 Transition
49
Le cycle de vie logiciel
La phase d’Initiation
 Utilité
 Établir le cadre légal, juridique et financier pour la mise en place
d’un nouveau système ou la mise a jour d’un système existant
 Livrables requis
 Les besoins essentiels pour le projet
 Une évaluation initiale des risques
 Livrables optionnels
 Un prototype conceptuel
 Un domaine de modèle initial (10~20% terminé)
50
La phase d’Élaboration
 Utilité
 Analyser le domaine du problème
 Établir une solide architecture de base
 Aborder les sections les plus risquées du projet
 Élaborer un plan de projet montrant comment le projet sera
exécuté
51
La phase d’Élaboration
 Livrables
 Un modèle du comportement du système incluant le contexte,
les scenarii, un domaine de modèle (80% terminé)
 Une architecture
 Une ébauche de la vision du produit sur la base du domaine de
modèle
 Un évaluation révisée des risques
 Un plan de développement
 Des critères d’évaluation du système
 Descriptions des
 Une première version du manuel d’utilisation (optionnel)
52
La phase de Construction
 Utilité
 Développer de façon incrémentale un logiciel complet prêt a
être transférer chez le client
 Livrables
 Une série de versions exécutables du produit
 Des prototypes
 Les résultats Assurance Qualité
 La documentation
 Le plan de déploiement
 Les critères d’évaluation pour l’itération suivante
53
La phase de Transition
 Utilité
 Transférer le logiciel chez le client
 Livrables
 Une série de versions exécutables du produit
 Les résultats Assurance Qualité
 La documentation
 Analyses des performances du projet
54
Planification des itérations

 Identifier et prioriser les risques majeurs du projet
 Sélectionner un nombre de scénarii qui adresse directement
les risques de plus haute priorité
 Les scenarii sélectionnés seront utilisés :
 Par les développeurs pour identifier ce qui doit être implémenter
dans l’itération.
 Par les responsables des tests pour développer les plans de
tests et les procédures pour l’itération
 A la fin de l’itération, déterminer les risques ayant été réduits
ou éliminés. Mettre le plan a jour pour les itérations restantes
55
Planification des itérations
56
Conclusion
 Le développement itératif et incrémental est le processus de
construction de logiciels par petites étapes. Le développement
passe par une série de publication de versions qui aboutissent
en la version finale.
 Le cycle de vie logiciel est divisé en cycles ou le résultat d’un
cycle est la production d’une version du logiciel
 Chaque cycle est une succession de phases
 Initiation -- fondement légal, juridique et financier
 Élaboration – analyse du domaine du problème, fondation
architecturale, évaluation préliminaire des risques
 Construction – développement incrémental d’un logiciel complet
prêt a être transférer chez le client
 Transition – transfert du produit chez le client
57
Conclusion
 Une itération est un circuit fermé de développement
aboutissant en une version du produit final et comprenant tous
les aspects du développement de logiciel:
 Analyse des besoins
 Design
 Implémentation
 Tests
 Documentation
58
59
Comportement du Système
60
Comportement du Système
Objectifs:

 Définir le comportement du système
 Définir les cas d’utilisation et les acteurs
 Comprendre comment documenter les cas
d’utilisation
 Utiliser un diagramme de cas d’utilisation pour
montrer les acteurs, le système et les cas
d’utilisation identifiés.
61
Comportement du système
Qu’est que le comportement d’un Système?
 Le comportement d’un système défini comment le système

se comporte et réagi
 C’est l’activité visible et testable du système
 Le comportement du système est capturé par les cas
d’utilisation
 Ils décrivent le système, son environnement et les relation entre
le système et son environnement
62
Concepts majeurs du MCU

 Un acteur représente toute entité qui
interagi avec le système
 Un Cas d’Utilisation (CU) est une

séquence de transactions effectuées
par un système et qui abouti en un
résultat mesurable ayant de la valeur
pour un acteur particulier
63
Modèle de Cas d’Utilisation (MCU)

 Un modèle de cas d’utilisation est un modèle des fonctions
attendues du système (cas d’utilisation) et de son
environnement (acteurs)
 Les cas d’utilisation servent de fil conducteur pendant le
développement du système
 Le même cas d’utilisation est utilisé dans l’analyse des
besoins, dans le design et dans les tests.
Le rôle le plus important d’un modèle de cas d’utilisation

est de communiquer les fonctionnalités et le
comportement du système au client ou utilisateur final
64
Avantages du MCU
 Le modèle de cas d’utilisation
 Est utilisé pour communiquer avec les utilisateurs finaux et les
experts du domaine
 Garantie la compréhension mutuelle des besoins
 Est utilisé pour identifier
 Qui interagira avec le système et ce que le système doit faire
 Quelles interfaces le système devra posséder
 Est utilisé pour vérifier
 Que les besoins ont été capturés
 Que les développeurs ont compris les besoins
65
Qu’est qu’un acteur?

 Les acteurs ne font pas partie du système,
ils représentent les rôles qu’un utilisateur
du système peut jouer
 Un acteur peut échanger des informations

avec le système
66
Recherche des acteurs: quelques
indices
 Qui est concerné par certains besoins ?
 Ou dans l’organisation le système est il utilisé?
 Qui fournira les informations au système, utilisera l’information,
supprimera l’information?
 Qui utilisera cette fonction?
 Qui s’occupera du support et de la maintenance du système?
 Le système utilise t’il des ressources externes
 De quels acteurs le CU a-t-il besoin?
 Est-ce qu’un acteur jour plusieurs différents rôles? Le même rôle
est il joué par plusieurs acteurs?
67
Instances d’acteurs
68
Un utilisateur pour plusieurs rôles
69
Qu’est ce qu’un cas d’utilisation ?

 Un cas d’utilisation modélise un
dialogue entre les acteurs et le
système.
 Un cas d’utilisation est initié par un
acteur pour invoquer une
fonctionnalité dans le système
 Un cas d’utilisation est un flux
complèt et sensé d’événements
 Pris ensemble, tous les cas
d’utilisation constituent les voies
possible d’utilisation du système
70
Recherche des CU: quelques indices

 Quelles sont les taches de cet acteur?
 L’acteur va-t-il créer, enregistrer, modifier, supprimer ou lire des
informations du système
 Quel cas d’utilisation pourra créer, enregistrer, modifier,
supprimer ou lire cette information?
 L’acteur devra t’il informer le système de changement soudains
et/ou externes?
 L’acteur devra t’il être informé de certains événements du
système?
 Quel cas d’utilisation devront supporter et maintenir le système
 Les cas d’utilisation peuvent ils adresser tous les besoins
fonctionnels?
71
Source d’information pour les CU

 Spécifications du système/énoncé du problème
 Littérature relative au domaine
 Interviews avec les experts du domaine
 Connaissances personnelles du domaine
72
Le Diagramme de CU (DCU)
 Un diagramme de cas d’utilisation peut être dessiné pour illustrer que les
cas d’utilisation et les acteurs interagissent en s’envoyant des stimuli.
73
Documentation des CU
 Les cas d’Utilisation sont documentés avec:
 Une brève description
 Le but du cas d’utilisation en quelques lignes
 Le flux détaillé des événements
 Description du flux primaire et du flux alternatif des événements qui auront lieu
quand le CU sera initié
 Les 2 documents sont écrits en des termes que le client comprends
74
Flux des événements dans un CU

 Chaque cas d’utilisation
 A une séquence normale de transactions
 Peut avoir plusieurs séquences alternatives de transactions
 A généralement plusieurs séquences exceptionnelles traitant des situations
d’erreurs
 Peut avoir des pré et post conditions bien définies.
75
Pour qui est la documentation des CU?

 Client – approuve ce que le système doit faire
 Utilisateur – fourni une compréhension du système
 Développeur – documente le comportement du système
 Vérificateur – Examine le flux des événements
 Analyste – fourni les bases pour l’analyse et le design
 Chargés des tests – comme base pour les cas de tests
 Chef de projet – planification du projet
 Documentaliste – pour la rédaction du manuel des utilisateurs finaux.
76
Conclusion
 Le comportement du système défini comment le système agit et réagit
 Le comportement d’un système peut être caractérisé par un groupe de
cas d’utilisation
 Un cas d’utilisation représente une fonctionnalité fournie pat le système
en réponse au stimulus d’un acteur externe
 Ils offrent un véhicule pour capturer les besoins d’un système du point de
vue utilisateur
 Un acteur est quelqu’un ou quelque chose qui doit s’ interfacer avec le
système en développement
 Un cas d’utilisation est une représentation graphique du système qui
montre les acteurs et les cas d’utilisation identifiés par le système.
 La documentation d’un cas d’utilisation consiste en une brève
description et un flux d’événements
77
Exemple: Inscription académique

 Au début de chaque semestre, les étudiants peuvent demander un
catalogue contenant la liste des cours dispensables. Les informations
relatives a chaque cours, telles que le professeur, le département et les
pré requis y sont mentionnées pour aider l’étudiant.
 Le nouveau système doit aider les étudiants a sélectionner dans un
premier temps, quatre matières pour le semestre a venir. Ensuite,
chaque étudiant doit sélectionner deux autres matières pour le cas ou il
n’y aurait plus de place disponible pour l’une des matières de premier
choix ou que la matière en question ait été annulée. Une fois
l’inscription terminée pour un étudiant donné, le système d’inscription
envoie l’information au système de facturation pour que l’étudiant
reçoive la facture du semestre.
78
Exemple: Inscription académique

 Les professeurs doivent pouvoir accéder au système pour
mentionner les cours qu’ils dispenseront. Il devront aussi
connaitre les étudiants s’étant inscrits pour leurs cours.
 Pour chaque semestre, il y a une période de temps pendant
laquelle les étudiants peuvent modifier leurs emploi du temps.
Les étudiants doivent pouvoir accéder au système pendant cette
période pour ajouter ou supprimer des cours.
79
Les acteurs: Inscription académique

 Les acteurs sont
 Étudiant
 Professeur
 Système de facturation
 Chargé des inscriptions
80
Les CU: Inscription académique

 Étudiant
 S’inscrit pour des cours
 Chargé d’inscriptions
 Maintient les informations sur les matières dispensées, les
étudiants, les professeurs et génère le catalogue des matières
dispensées
 Professeur
 Dispose des contenus des cours, choisi les cours a enseigner
81
Le DCU: Inscription académique
82
Brève description: CU Inscription
académique
 Ce CU est initié par un étudiant. Il permet à l’étudiant de créer,

supprimer, modifier et/ou réviser un emploi du temps pour un
semestre donné.
83
Flux des événements: CU Inscription
académique
 Ce CU démarre quand l’étudiant saisi son matricule. Le système

vérifie que le matricule est valide et demande à l’étudiant de
choisir le semestre en cours ou un semestre future. L’étudiant
choisi le semestre qui l’intéresse. Le système demande a
l’étudiant de choisir entre les activités suivantes
 La création d’un emploi du temps
 La consultation d’un emploi du temps
 La modification d’un emploi du temps
 Suppression d’une matière
 Ajout d’une matière
 L’étudiant indique la fin de l’activité choisie. Le système édite
l’emploi du temps de l’étudiant et informe ce dernier de la fin de
l’inscription. Le système envoie des éléments de facturation au
système de facturation pour traitement.
84
académique
 Flux alternatif
 Si le matricule est invalide, le système ne permet aucun accès.
 Si l’étudiant tente de créer un emploi du temps pour un semestre
donnée alors qu’un emploi du temps existe, demandera de faire un
autre choix
 Ajoute l’étudiant a la liste relative a ce cours s’il y a encore de la place
 Création d’un emploi du temps
 L’étudiant sélectionne d’abord 4 matières de premier choix, puis 2
matières alternatives. L’étudiant soumet ses choix. Le système
 Vérifie que les pré requis sont satisfaits
 Flux alternatif
 Si une matière de premier choix n’est pas disponible, le système la
remplace par une matière alternative
85
académique
 Consultation d’un emploi du temps

 L’étudiant demande des informations sur tous les course pour lesquels il
peut s’inscrire pour un semestre donné. Le système affiche tous les cours
pour lesquels l’étudiant est inscrit avec la dénomination du cours, le numéro
du cours, les jours de la semaine, les horaires, les salles et les unités de
valeur.
 Modification
 Suppression d’un cours. L’étudiant indique le cours qu’il aimerait supprimer.
Le système vérifie que la date butoir pour la modification n’est pas passée.
Le système informe l’étudiant que sa demande a été traitée.
 Ajout d’un cours. L’étudiant indique le cours qu’il aimerait ajouter. Le
système vérifie que la date butoir pour la modification n’est pas passée et
 Vérifie que le nombre maximal des cours n’est pas dépassée
 Vérifie que les pré requis sont satisfaits
 Ajoute l’étudiant a la liste au cas ou il y a encore de la place
86
87
Scénarii et Objets
88
Scénarii et Objets
Objectifs:
 A la fin de ce chapitre, vous devez

pouvoir:
 Définir et développer des scenarii de cas
d’utilisation
 Définir et donner des exemples d’objet
89
Scénarii et Objets
Scénarii
Qu’est ce qu’un scénario ?
 Un scénario est un instance de cas d’utilisation

 C’est le contour des événements qui arrivent pendant l’exécution du
système
 Chaque CU contient plusieurs scenarii
 Les scenarii primaires (meilleur des mondes)
 Les flux normaux, le fonctionnement idéal
 Les scenarii secondaires
 Les exceptions au scenarii primaires
 Les scenarii sont modélisés avec les diagrammes de séquences
et/ou mes diagrammes de collaboration
90
Scénarii et Objets
Scénarii
Un Scénario pour CU « S’inscrit pour les
cours »
Kouassi saisi le matricule 1234 56 et le système valide le numéro.

Le système demande le semestre. Kouassi choisi le semestre en
cours et opte pour créer un nouvel emploi du temps.
De la liste des cours disponibles, Kouassi choisi dans un premier
temps les cours primaires ‘Anglais 101’, ‘Géologie 110’, ‘Histoire
200’, ‘Algèbre 110’. Il choisi ensuite les cours additionnels
‘Théorie Musicale 110’ et ‘Introduction a Java 180’
Le système détermine que Kouassi a les pré requis nécessaires et
l’ajoute a la liste des élèves
Le système indique la fin des activités. Le système édite l’emploi du
temps et envoie les informations de facturation pour les 4 cours
au système de facturation
91
Scénarii et Objets
Scénarii
Scénarii secondaires
Quels sont les scénarii secondaires pour le CU ‘S’inscrit pour les cours’
?
92
Scénarii et Objets
Scénarii
 Quelques scenarii a considérer sont:

 L’étudiant ne sélectionne pas 4 cours primaires
 Le cours primaire n’est pas disponible
 Les cours primaires et secondaires ne sont pas disponibles
 Impossibilité d’ajouter l’étudiant a la liste
 Impossibilité de créer l’emploi du temps de l’étudiant
93
Scénarii et Objets
Scénarii
 Quelques scenarii a considérer sont:

 L’étudiant ne sélectionne pas 4 cours primaires
 Le cours primaire n’est pas disponible
 Les cours primaires et secondaires ne sont pas disponibles
 Impossibilité d’ajouter l’étudiant a la liste
 Impossibilité de créer l’emploi du temps de l’étudiant
94
Scénarii et Objets
Scénarii
Combien de scénarii sont nécessaires ?
 Simple réponse: autant qu’il en faut pour comprendre le

système a développer
 Règle d’Or:
 Scenarii primaires
 Élaborer près de 80% des scenarii
 Scenarii secondaires
 Élaborer quelques un des cas intéressants et hautement risqués des
scenarii secondaires
95
Scénarii et Objets
Scénarii
Qu’est ce qu’un objet?
 De façon informelle, un objet représente une entité soit physique,

conceptuelle ou logicielle
 Entité Physique
 Entité Conceptuelle
 Entité Logicielle
96
Scénarii et Objets
Objets
Qu’est ce qu’un objet?
 Un objet est un concept, une abstraction ou une entité avec un

contour bien défini et un sens pour une application
 Un objet est une entité qui a:
 Un état
 Un comportement
 Une identité
 Le terme INSTANCE est fréquemment utilisé pour decrire un
objet particulier
97
Scénarii et Objets
Objets
Un objet a un État
 L’État d’un objet est l’une des conditions dans lesquelles l’objet
peut exister
 L’État est représenté par la valeur des propriétés d’un objet a un
instant donné
 L’État d’un objet change normalement avec le temps
98
Scénarii et Objets
Objets
Un objet a un Comportement
 Le comportement détermine comment un objet agit et réagit: ses

changements d’État et ses interactions avec d’autres objets
 Le comportement défini comment un objet réagit aux requêtes
d’autres objets
 Le comportement est déterminé par le groupe des opérations
qu’un objet peut effectuer
99
Scénarii et Objets
Objets
Un objet a une Identité
 Chaque objet a une identité unique, même si sont état est

identique a celui d’un autre objet
100
Scénarii et Objets
Objets
Recherche des Objets
 Les objets sont identifiés en examinant les noms dans les cas
d’utilisation et les scenarii
 Les noms trouvés peuvent être
 Des objets
 La description de l’état d’un objet
 Des entités externes et/ou acteurs
101
Scénarii et Objets
Objets
Filtrage des noms
 Dans le choix des nom, il faut considérer que:

 Plusieurs termes peuvent designer le même objet
 Un terme peut être mieux approprié
 Le langage naturel est assez ambigu
 Le filtrage permet d’identifier plusieurs objets sans importance
 La liste des noms doit être filtrée
 Chaque nom doit être considéré dans le contexte du problème
posé. Un nom ne tient pas en lui-même
102
Scénarii et Objets
Objets
Les noms du scénario « S’inscrit pour des
cours »
 Dans le choix des nom, il faut considérer que:

 Plusieurs termes peuvent designer le même objet
 Un terme peut être mieux approprié
 Le langage naturel est assez ambigu
 Le filtrage permet d’identifier plusieurs objets sans importance
 La liste des noms doit être filtrée
 Chaque nom doit être considéré dans le contexte du problème
posé. Un nom ne tient pas en lui-même
103
Scénarii et Objets
Objets
Les noms du scénario « S’inscrit pour des
cours »
 Quels noms doivent être filtrés ?
Kouassi Matricule 1234 56

Système Numéro
Semestre Semestre en cours
Nouvel emploi du temps Liste des cours disponibles
Cours primaires Anglais 101
Géologie 110 Histoire 200
Algèbre 110 Cours additionnels
Théorie Musicale 110 Introduction a Java 180
Pré requis nécessaires Liste des élèves
Activités Emploi du temps
Informations de facturation 4 cours
Système de facturation
104
Scénarii et Objets
Objets
Décision de filtrage
Kouassi Acteur
Matricule 1234 56 Propriété d’un étudiant
Système Ce qui est en construction
Numéro Identique au matricule
Semestre Etat après sélection
Semestre en cours Identique au semestre
Nouvel emploi du temps Objet
Liste des cours disponibles Objet
Cours primaires État des cours sélectionnés
Anglais 101 Objet
Géologie 110 Objet
Histoire 200 Objet
Algèbre 110 Objet
Cours additionnels Etat des cours sélectionnés
105
Scénarii et Objets
Objets
Décision de filtrage
Cours additionnels État des cours sélectionnés

Théorie Musicale 110 Objet
Introduction a Java Objet
Pré requis nécessaires Objet
Liste des élèves Objet
Activités Expression linguistique
Emploi du temps Identique a Nouvel emploi du temps
Information de facturation Information requise par le système de facturation
Système de facturation Acteur
106
Scénarii et Objets
Conclusion
 Un scénario est une instance d’un cas d’utilisation

 C’est le contour des événements qui se produisent lors de
l’exécution du système
 Chaque cas d’utilisation identifié est composé de
plusieurs scenarii
 Les scénarii primaires – cours normal des événements
 Les scenarii secondaires – exceptions au scenarii primaires
107
Scénarii et Objets
Conclusion
 Un objet est une entité qui a un État, un

comportement et une identité
 L’État d’un objet est l’une des condition dans lesquelles il
peut exister
 Le comportement détermine comment un objet agit et réagit
aux requêtes des autres objets
 Chaque objet a une identité unique – même si son état est
similaire à un autre objet
 Les objets sont découverts en examinant les noms
contenus dans les cas d’utilisation et les scenarii
108
109
Interactions des objets
110
Interaction des Objets
Objectifs:
 A la fin de ce chapitre, vous devez

pouvoir:
 Modéliser un scénario avec les
diagrammes d’interaction
111
Diagrammes d’interaction
 Les scenarii sont typiquement schématisés par les
 Il existe 2 type de diagrammes d’interaction
 Les diagrammes de séquence
 Les diagrammes de collaboration
 Chacun des diagrammes offre un vue différente de la
même interaction
 Les diagrammes de séquence sont ordonnés dans le temps
 Les diagrammes de collaboration peuvent inclure des flux de
données
112
Le Diagramme de Séquence (DS)
 Le diagramme de séquence représente les messages

échangés par un groupe d’objets pendant un scénario
 Un diagramme de séquence contient
 Les objets avec leur « ligne de vie »
 Les messages échangés entre objets dans une séquence
ordonnée
 Les focus de contrôle (optionnel)
113
Un Diagramme de Séquence (DS)
114
Nomenclature de objets (DS)
 Les objets sont représentés par des rectangles avec

leurs noms soulignés
 Les lignes de vie des objets sont représentées par
des lignes discontinues
115
Interactions entre objets

 Les interactions entre objets sont indiquées par les flèches
horizontales partant de la ligne horizontale représentant l’objet
client vers la ligne représentant l’objet fournisseur.
 Les lignes horizontales sont annotées avec le message
 La séquence des événements dans le temps sont indiqués par la
position verticale, avec le premier événement au dessus
 La numérotation est optionnelle dans la mesure ou la séquence
débute du haut
116
Focus de contrôle
 Le focus de contrôle représente la durée relative

pendant laquelle un objet est le point focal du flux de
contrôle
 Il représente le temps pendant lequel un objet initie les
messages
 Le focus de control peut être mentionné dans un
diagramme de séquence
117
Notes
 Des notes peuvent être ajoutées pour donner plus

d’information au diagramme
118
Le Diagramme de Collaboration (DC)
 Un scénario peut être aussi représenté

graphiquement par un diagramme de collaboration
 Le DC représente aussi les message échangés par
un groupe d’objets durant un scénario
 Un DC contient
 Des objets
 Des liens entre objets
 Des messages échangés entre objets de façon séquentielle
 Le flux de données entre objets le cas échéant
119
Exemple de Diagramme de
Collaboration
120
Représentation des objets dans un DC
 Les objets sont représentés par des

rectangles avec leurs noms soulignés
121
Représentation des liens dans un DC
 Un lien d’interaction dans un diagramme de

collaboration est représenté par une ligne
interconnectant des icônes d’objets
 Un lien indique qu’il y a échange entre les
objets connectés
122
Annotation des liens dans un DC

 Un lien d’interaction dans un DC peut être annoté
avec:
 Une flèche partant de l’objet client à l’objet fournisseur
 Le nom d’un message avec une liste optionnelle de
paramètres et/ou des valeurs de retour
 Une séquence optionnelle de numéros montrant l’ordre dans
lequel les messages sont émis
123
Création des DC
 Les cas d’utilisation sont examinés pour

déterminer les scenarii
 Des informations additionnelles peuvent être
nécessaires pour terminer les scenarii
 Détails du système ayant été omis du CU
 Par exemple, Kouassi saisit le numéro
2345676
 Question: Dans quoi le numéro est il saisi?
 Réponse: Un formulaire d’enregistrement est
ajouté
124
Diagramme de séquence pour le
scénario «inscription académique »
125
Diagramme de collaboration pour le
scénario «inscription académique »
126
Résumé: Interaction d’objets

 Un scénario peut être graphiquement représenté
dans un diagramme de séquence qui démontre
l’existence d’objets et les interactions entre les objets
identifiés
 Les objets sont représentés par des rectangles avec les
noms soulignés
 La ligne de vie d’un objet est représentée par une ligne
discontinue, descendant de l’objet
 Les messages sont indiqués par des flèches horizontales
dirigées de l’objet client vers l’objet fournisseur
 Les lignes horizontales sont annotées avec le nom du
message
127
Résumé: Interaction d’objets

 Un diagramme de collaboration est une
représentation alternative graphique d’un
scénario
 Les objets sont représentés par des rectangles
 Un lien d’interaction (ligne) est dessiné entre les
objets communicants
 Le lien peut être annoté avec une flèche contenant le
nom du message et pointant de l’objet client vers l’objet
fournisseur
 Le lien peut être aussi annoté avec une flèche de retour
de données
128
129
CLASSES ET PAQUETAGES
130
Classes et paquetages
Objectifs:

 Définir et donner des exemples de classes
 Décrire les relations entre classes et objets
 Identifier les classes potentielles
 Définir les stéréotypes
 Définir et donner des exemples de paquetages
 Créer des paquetages
 Créer des diagrammes de classes
131
Les classes
 Plusieurs objets sont identifiés pour un problème
particulier
 Une classe est une description d’un groupe d’objet
ayant des propriétés similaires (attributs), des
comportements communs (opérations), des relations
communes avec d’autres objets (associations et
agrégations), et une sémantique commune
 Un objet est une instance d’une classe
 Une classe est une abstraction qui
 Met en relief les importantes caractéristiques
 Supprime les autres caractéristiques
 L’abstraction nous aide a gérer la complexité
132
Les classes
Exemple de classe
133
Les classes
Classes d’objets
 Combien de classes distinguez vous?
134
Les classes
Indications pour la recherche de
classes
 Une classe doit capturer une et une seule abstraction clé
 Mauvaise abstraction: une classe Etudiant qui détient les informations
de l’étudiant et son emploi du temps pour le semestre en cours
 Bonne abstractions: Des classes séparées pour Etudiant et Emploi du
temps
135
Les classes
Nomenclature des classes
 Le nom d’une classe doit être un nom

singulier qui caractérise au mieux l’abstraction
 Des difficultés dans le choix d’un nom de
classe sont l’indication d’un mauvaise
abstraction
 Les noms doivent découler du vocabulaire du
domaine du problème.
136
Les classes
Style de nomenclature des classes

 Un style de nomenclature définit les conventions dans
le choix des noms de classes
 Exemple de style
 Les classes sont nommées avec des noms singuliers
 Les noms de classe commencent avec une lettre majuscule
 Les sous tirets ne sont pas utilisés
 Les noms composés sont concaténés avec les premières lettres
en capital
 Exemples: Etudiant, Professeur, SystemeDeFacturation
137
Les classes
Sémantique de définition des classes

 Après avoir nommé une classe, une description brève
et concise doit être faite
 Le focus est sur le rôle et non l’implémentation
 Le nom de la classe est la base du dictionnaire du modèle
 A ce stade, les classes ne sont que liées au domaine du
problème
On recherche le « QUOI » et on ignore le « COMMENT

»
138
Les classes
Exemple de dictionnaire de modele
 Nom: InformationEtudiant
 Définition: information relative a une personne
s’etant inscrit pour suivre des cours a l’université
 Nom: Cours
 Définition: Session de formation offerte par
l’Université
Au fur et a mesure qu’on comprend le problème, on
raffine les définitions de classes et on ajoute de
nouvelles classes au dictionnaire du modèle
139
Les classes
Représentation des classes
 Une classe est représentée par un

rectangle compartimenté
140
Les classes
Compartiments des classes

 Une classe comprends 3 sections
 La 1ere section contient le nom de la classe
 La 2e montre la structure de la classe (attributs)
 La 3e montre le comportement (opérations)
 La 2e et 3e section peuvent être omises d’un diagramme si elles
ne sont pas utiles
141
Les classes
Relations entre classes et objets

 Une classe est une définition abstraite d’un objet
 Elle définit la structure et le comportement de chaque objet de la
classe
 Elle sert de moule pour la création d’objets
 Les objets trouvés dans les scenarii peuvent être regroupés en
classes
142
Les classes
Les cartes CRC

 Classes-Responsabilité-Collaboration
 Les CRC peuvent aider a découvrir les classes
 Introduites en 1989 par Kent et Ward
 Une carte CRC est une carte index qui contient
 Le nom et la définition de la classe
 Les responsabilités de la classe
 Information internes a la classe
 Services offerts par la classe
 Les collaborateurs pour les responsabilités
 Un collaborateur est une classe dont les services sont requis par
une responsabilité
143
Les classes
Une session de carte CRC

 Un groupe de personnes est désigné pour jouer un
scénario
 Une carte est crée pour chaque objet d’un scénario
 Un groupe de cartes est assigné a chaque participant
 Le participant devient une classe
 Les scenarii définis sont exécutés par les participants
 Les cartes sont annotées avec les responsabilités et
les collaborations
 Des cartes sont crées pour les nouveaux objets
découverts
144
Les classes
Carte CRC pour la classe COURS
145
Les classes
Avantages d’une carte CRC

 Au fur et a mesure que les scenarii se terminent, les
schémas de collaboration se rendent évidents
 Les cartes peuvent être physiquement disposées
pour représenter les collaborations
 Il est possible d’identifier les
généralisation/spécialisation ou hiérarchies
d’agrégation entre les classes
 Les cartes CRC sont plus effectives avec les groupes
nouvellement introduits aux techniques OO :
 Évitent de se focaliser sur les problèmes liées à la
programmation OO
 Évitent les généralisations prématurées
 Encourage le raisonnement en termes d’objets
146
Les classes
Évaluations
 Les choses vont bien si
 Toutes les classes ont des noms significatifs et spécifique au domaine
du problème
 Chaque classe a un petit nombre de collaborateurs
 Il n’y a pas de classe « indispensable » (God Class) (une classe qui
collabore avec tout le monde doit être redéfinie)
 L’information de chaque classe tient sur la carte
 Un changement dans les besoins peut être géré par les classes
 Les choses vont mal si
 Un certain nombre de classes n’ont aucune responsabilité
 Une même responsabilité est assignée a plusieurs classes en même
temps
 Toutes les classes collaborent avec toutes les autres classes
147
Les classes
Stéréotypes
 Un stéréotype représente la classification d’une classe
 Chaque classe peut avoir tout au plus un stéréotype
 Les stéréotypes communs
 Classe d’interfaçage (boundary class)
 Classe d’ entité
 Classe de contrôle
 Classe d’exception
 Metaclass
 Classe paramétrique
 Classe utilitaire
 Les stéréotypes sont représentés par le nom de classe entre
guillemets «»
148
Les classes
Classes d’interfaçage
 Une classe d’interfaçage modélise la communication
entre l’environnement du système et son
fonctionnement interne
 Les classes d’interfaçage typiques sont
 Les fenêtres (interface utilisateur)
 Les protocoles de communication (interface système)
 Les interfaces d’imprimantes
 Les sondes
149
Les classes
Recherche de classes d’interfaçage

 Toutes les informations échangées entre un acteur et le
système sont contenues dans les classes d’interfaçage
 Les scenarii sont examinés pour identifier le contenu de la
classe
150
Les classes
Prototypes et brouillons
 Des prototypes et/ou brouillons peuvent être crées pour
communiquer les aspects esthétiques de la classe
d’interfaçage a l’utilisateur
151
Les classes
Interface aux autres systèmes

 Une classe d’interfaçage est aussi utilisée pour modéliser une
interface a un autre système.
 Les caractéristiques importantes de ce type de classes
d’interfaçage sont:
 L’information a véhiculer a l’autre système
 Le protocole de communication utilisé pour « parler » avec l’autre
système
 Dans le scénario « s’inscrire pour les cours », le système de
facturation est de ce type de classe d’interfaçage
152
Les classes
Classe d’entité
 Une classe d’entité modélise l’information persistante et le
comportement y étant associé (dure dans le temps)
 Elle peut refléter un phénomène réel
 Elle peut être requise pour les taches internes du système
 Les valeurs de ses attributs sont souvent fournies par un acteur
 Le comportement est indépendant de l’environnement
 Les classes d’entité dans le CU « inscription académique » sont
 Cours
 EmploiDuTemp
 Catalogue
153
Les classes
Classe de contrôle
 Une classe de contrôle modélise le
comportement spécifique à un ou plusieurs CU
 Une classe de contrôle
 Crée, initialise et supprime les objets contrôlés
 Contrôle la séquence ou coordination de l’exécution
des objets contrôlés
 Contrôle les aspects liés à la concurrence des
classes contrôlées
 Est la plupart du temps, l’implémentation d’un objet
intangible
154
Les classes
Classe de contrôle pour CU «
inscription académique »
 Une classe appelée GestionnaireDesInscriptions des ajoutée
 Le GestionnaireDesInscriptions
 Reçoit les informations d’inscription de IHM quand le bouton OK est
appuyé
 Il vérifie les pré requis pour le cours sélectionné
 Il ajoute l’étudiant aux premiers cours disponibles
 Sait quoi faire quand les 4 cours ne sont pas disponibles
 Crée l’ EmploiDuTemp qui mentionne les cours
 Crée l’objet SystemeDeFacturation pour l’étudiant
155
Les classes
Diagrammes de séquence
 Les diagrammes de séquence sont mis a

jour
 Les classes additionnelles sont ajoutées au
diagramme
 Les objets dans le diagrammes sont
assignés aux classes
156
Les classes
Exemple: Objets dans le scénario «
s’inscrit pour les cours »
 FormulaireEnregistrement – formulaire qui affiche
les options d’inscription
 FormulaireEmploiDuTemps – formulaire qui permet
a l’étudiant de sélectionner les cours
 Cours disponibles – liste des cours enseignés dans
un semestre
 Anglais – cours disponible dans un semestre
 …
 Information de facturation – information requise par
le système de facturation (acteur)
157
Les paquetages
 La plupart des modèles contiennent plusieurs classes
 Ces classes peuvent être regroupées dans des paquetages
 Un paquetage est une collection logique de classes et/ou
d’autres paquetages
 Le paquetage « possède » les classes qu’il contient
 Un paquetage est représenté par un répertoire avec onglet
158
Paquetages dans le système

d’inscription
 Les classes dans le système d’inscription peuvent
être regroupés en 3 paquetages
 ElementsUniversitaires, Règles métier et Interfaces
 ElementsUniversitaires
 Catalogue, Cours, DossierEtudiant, ListeCours,
EmploiDuTemps
 ReglesMetier
 GestionnnaireInscription
 Interfaces
 FormulaireEnregistrement, FormulaireEmploiDuTemps,
SystemeFacturation
159
Le diagramme de classe
 La vue logique est composée de plusieurs paquetages et
classes
 Un diagramme de classes est une vue partielle ou complète
des paquetages et classes dans la vue logique
 Il y a généralement plusieurs diagrammes de classe
 Le diagramme de classe principal est typiquement une vue de
l’ensemble des paquetages dans la vue logique
 Chaque paquetage a généralement son diagramme de classe
principal
 Des diagrammes de classes additionnels sont ajouté si besoin
est
 Vue des classes participant dans un scénario
 Vue des classes « privées » dans un paquetage
 Vue d’une classe avec ses attributs et opérations
 Vue d’une hiérarchie d’héritage
160
Diagramme de classe principal pour le

système d’inscriptions
161
Diagramme de classe principal pour

les interfaces
162

les éléments universitaires
163

les règles métier
164
Métamorphose
 A l’université, il y a les étudiants a temps plein et les étudiants a
temps partiel
 Les étudiants a temps plein on un numéro matricule et une date
probable de fin de cycle pendant que ceux a temps partiel n’en ont
pas
 Les étudiants a temps partiel peuvent prendre un maximum de 3
cours pendant qu’aucune restriction ne s’impose aux étudiants a
temps plein
Qu’advient-il lorsqu’un étudiant passe du stade de temps

partiel a temps plein?
165
Métamorphose
 Il est très difficile de modifier la classe d’un objet
 Meilleur technique de modélisation
 Placer la structure et le comportement qui « changent »
dans leur propre classe
 Cela permet a un objet de « parler » à différents objets pour
accomplir la métamorphose
166
Métamorphose
167
Métamorphose
 Cette technique ajoute aussi de la flexibilité au
modèle
 Exemple: un étudiant a temps plein peut aussi
résider sur le campus. Dans ce cas, il y a le nom du
bâtiment, le numéro de la chambre et le numéro de
la clé de la chambre
168
Résumé: Classes et paquetages

 Une classe est une définition abstraite d’un groupe d’objets qui
partagent une structure et un comportement communs.
 Les noms de classes doivent caractériser au mieux l’abstraction
 Les classes sont représentées avec des rectangles
compartimentés
 Le 1er compartiment contient le nom de la classe
 Le 2e montre la structure (attributs)
 Le 3e montre le comportement (opérations)
 Les classes sont découvertes en analysant les CU et les scenarii
développés pour le système.
 Les cartes CRC peuvent être utilisées pour découvrir les classes
169

 Un stéréotype représente une classification d’une classe
 Chaque classe peut avoir tout au plus un stéréotype
 Les stéréotypes communs sont: les classes d’interfaçage, les
classes d’entité, les classes de contrôle, les classes d’exception,
les méta-classes, les classes paramétriques, les classes utilitaires
 Une classe d’interfaçage modélise la communication entre
l’environnement d’un système et son fonctionnement interne
 Une classe d’entité modélise l’information et le comportement
associé qui doit être enregistrer
 Une classe de contrôle modélise l’aspect de contrôle spécifique à
un ou plusieurs CU
 Un paquetage est une collection logique de classes et/ou autres
paquetages
170
 Un diagramme de classe est une vue logique

partielle ou complète des paquetages et classes
dans une vue logique
 Il y a généralement plusieurs diagrammes de classes
 Si un objet doit être modifié, il faut placer la
structure et le comportement qui « changent »
dans une classe a part.
 Cela permet a un objet de « parler » avec différents
objets pour accomplir la métamorphose
171
172
LES RELATIONS
173
Les relations
Objectifs:

 Nommer les 2 principaux types de relations entre classes:
association et agrégation
 Définir l’association et la représenter sur un diagramme de classe
 Utiliser les noms d’association et de rôle pour clarifier les
associations
 Définir et spécifier la multiplicité d’une association
 Définir l’agrégation et la représenter sur un diagramme
 Définir et représenter une association réflective ou agrégée
 Utiliser les attributs d’association
 Définir les qualifiants et les représenter sur un diagramme de
classes
 Découvrir les association depuis les scenarii
174
Les relations
La nécessité des relations

 Tout système comprends plusieurs classes et objets
 Les objets contribuent au comportement du système en
collaborant entre eux
 La collaboration est accomplie par le biais des relatons
 Il y a 2 principaux types de relations pendant l’analyse
 L’association
 L’agrégation
175
Les relations
L’association
 Une association est une connexion entre 2 classes
 Cela implique qu’il y a un lien entre les objets des classes associées
 Les associations sont représentées sur un diagramme de classe
par une ligne connectant les classes associées
 Le flux des données peut être dans l’une des directions ou dans
les 2 directions
176
Les relations
L’association
Navigation
 Une association est une relation bi-directionnelle
 Pour une instance donnée de GestionnaireInscriptions, il existe
un objet associé Cours
 Pour une instance donnée de Cours, il existe un objet associé
GestionnaireInscriptions
177
Les relations
L’association
Nomenclature des associations

 Pour clarifier son sens, une association peut être
nommées
 Le nom est représenté par un label placé le long de la
ligne d’association, entre les icônes des classes
 Le nom d’une association est généralement un verbe
178
Les relations
L’association
Les rôles
 Un rôle indique la raison pour laquelle une classe est associée a
une autre
 Les noms de rôles sont typiquement des noms
 Un nom de rôle est placé sur la ligne de l’association du coté de la
classe concernée
 L’un ou les deux bouts de l’association peuvent avoir des noms de rôle
179
Les relations
L’association
Associations multiples
 Plus d’une association peut exister entre 2 classes
 Dans ce cas, ces association DOIVENT être nommées
 Les associations multiples doivent être remises en

cause
180
Les relations
L’association
Associations multiples
 Ce modèle est-il bon ou mauvais
181
Les relations
L’association
Multiplicité des associations

 La multiplicité est le nombre d’instance d’une classe lié
au UNE instance de l’autre classe
 Pour chacune des associations, il y a 2 décisions de
multiplicité a prendre: une pour chaque bout de
l’association
 Par exemple, pour la connexion entre Personne jouant
le rôle de professeur et Cours
 Pour chaque instance de Personne, plusieurs (c’est-à-dire zéro
ou plus) Cours peuvent être enseignés
 Pour chaque instance de Cours, il faut exactement une
Personne qui est le professeur
182
Les relations
L’association
Indicateur de multiplicité
 Chaque bout de l’association contient un

indicateur de multiplicité
 Il indique le nombre d’objets participants dans la
relation
183
Les relations
L’association
Exemple de multiplicité
 Les décisions de multiplicité exposent plusieurs

hypothèse (cachées) relatives au problème en question
 Un professeur peut il ne pas avoir de cours a donner?
 Un cours peut il avoir deux professeurs?
184
Les relations
L’association
Le sens de la multiplicité
 La multiplicité réponds a 2 questions

 L’association est elle obligatoire ou optionnelle?
 Quels sont les nombre minimum et maximum des instances qui
peuvent être liés à une instance?
 Que nous enseigne ce diagramme ?
185
Les relations
L’agrégation
 L’agrégation est une forme spécialisée de l’association dans

laquelle un tout est lié a sa/ses partie/parties
 L’agrégation est aussi connue comme « partie-de »
 Une agrégation est représentée comme une association avec un
diamant près de la classe matérialisant le tout
 La multiplicité est représentée de la même manière que dans les
associations
186
Les relations
L’agrégation
Test d’agrégation
 L’expression « partie-de » est elle utilisée pour décrire la relations?

 Une Portière fait « partie-de » une Voiture
 Existe-t-il des opérations qui appliquées au tout s’appliquent
automatiquement aux parties
 Déplacer la Voiture, déplacer la Portière
 Existe il des valeurs d’attributs propagées du tout aux parties ?
 La Voiture est bleue, la Portière est bleue
 Existe-t-il une asymétrie (intrinsèque) dans la relation ou une classe
est subordonnée a une autre
 Une Portière fait partie d’une Voiture, une Voiture ne fait pas partie d’une
Portière
187
Les relations
Agrégation ou Association?
 Si 2 objets sont intimement liés par la relation « tout-

partie »
 La relation est une agrégation
 Si 2 objets sont généralement considérés comme
indépendant, même si il sont liés
 La relation est une association
188
Les relations
Association réflective
 Dans une association réflective, les objets d’une même classe sont
liés
 Cela indique que plusieurs objets dans la même classe collaborent entre
elles
Un cours peut avoir plusieurs pré-réquis

Un cours peut être un pré-réquis a plusieurs autres cours
189
Les relations
Classes d’association
 Nous souhaitons suivre les notes de tous les cours auxquels un étudiant
s’est inscrit
 La relation entre Etudiant et Cours est une relation de plusieurs à plusieurs
 Ou allons nous placer l’attribut note?
190
Les relations
Représentation des classes

d’association
 L’attribut note ne peut être placé dans Cours parce qu’il y a (potentiellement)
plusieurs liens avec plusieurs objets Etudiant
 L’attribut grade ne peut être placé dans Etudiant parce qu’il y a
(potentiellement) plusieurs liens avec plusieurs objets Cours
 Par conséquent, l’attribut appartient réellement au lien entre Etudiant et
Cours
 Une classe d’association est utilisée matérialiser cette information du lien
191
Les relations
Classes d’association et
multiplicité
 Les classes d’association sont souvent utilisées pour les relations de
plusieurs à plusieurs
 Si la multiplicité a l’un des bouts est « à un »
 L’attribut peut être placé dans la classe du bout « à plusieurs » de la
relation
 Une classe d’association peut être utilisée
192
Les relations
Qualificateur
 Un qualificateur est un attribut d’une classe qui peut être
utilisé pour réduire la multiplicité d’une association
193
Les relations
Recherche des Associations et

Agrégations
 Les scenarii peuvent être examinés pour déterminer si une relation
doit exister entre 2 classes
 Deux objets ne peuvent communiquer que s’ils se connaissent
 Les associations et/ou agrégation offrent un canal de communication
FormInscription « parle »
à FormEmploiTemps
FormEmploiTemps « parle »
à GestInscriptions
194
Les relations
Associations ou Agrégations
195
Les relations
Relations entre paquetages
 Les paquetages sont liés les uns aux autres par

les relations de dépendance
 Si une classe dans un paquetage « parle » à une
classe dans un autre paquetage, alors une
relation de dépendance est ajoutée au niveau
paquetage
 Les scenarii et diagrammes de classe sont
évalués pour déterminer les relations entre
paquetages
196
Les relations
Relations durant l’Analyse et le

Design
 Pendant l’analyse, on établit les connexions (associations et
agrégation) entre les classes
 Ces connexions existent a cause de la nature des classes et non leur
implémentation spécifique
 On fait des estimations initiales de la multiplicité dans le but d’exposer
les suppositions cachées
 Les diagrammes de classes sont mis a jour pour montrer les relations
ajoutées
 Pendant le design:
 Les multiplicités sont raffinées et mis a jour
 Les associations et agrégations sont évaluées et raffinées
 Les relations entre paquetages sont réévaluées et raffinées
 Les diagrammes de classes sont mis a jour
197
Les relations
Diagramme de classes mis à jour

pour le système d’inscriptions
198
Les relations

pour les interfaces
199
Les relations

pour les Éléments Universitaires
200
Les relations

pour les Règles Métier
201
Les relations
Résumé: Relations
 Tous les systèmes traitent de plusieurs objets qui collaborent les uns
avec les autres pour offrir la fonctionnalité requise
 Les 2 types importants de relations sont les associations et les
agrégations
 Une association est une connexion entre 2 classes qui représente la
communication
 Une association peut avoir un nom
 Des noms de rôles peuvent être utilisés
 La communication peut être uni ou bi directionnelle
 La multiplicité est le nombre d’instances qui participent a une relation
 Elle est mentionnée en bout de la ligne de relation
 Chaque bout de la relation doit avoir un indicateur de multiplicité
202
Les relations
Résumé: Relations
 L’agrégation est une forme spécialisée de

l’association dans laquelle un TOUT est lié à ses
PARTIES
 Chaque bout de la ligne d’agrégation doit avoir un
indicateur de multiplicité
 Une classe peut avoir une association réflective
 Deux objets dans la même classe sont liés
 Les informations appartenant au lien entre objets
sont représentées dans une classe d’association
203
Les relations
Résumé: Relations
 Un qualificateur est un attribut d’une classe

qui peut être utilisé pour réduire la
multiplicité d’une association
 Les relations peuvent être déterminées en
examinant les scenarii pour découvrir les
besoins de communication des objets
204
205
OPERATIONS ET ATTRIBUTS
206
Opérations et Attributs
Objectifs: Opérations et Attributs

 Définir les opérations de classes
 Définir les attributs de classes
 Définir l’encapsulation et en énoncer les

avantages
 Représenter les attributs et opérations sur les
diagrammes de classes
207
Qu’est ce qu’une opération?
 Une classe comprends un ensemble de responsabilités

qui définissent le comportement des objets de la classe
 Les responsabilités de la classe sont assumées par ses
opérations
 Il ne s’agit pas nécessairement d’un mappage un à un
 Responsabilité de la classe Produit  fournir prix
 Opérations pour cette responsabilité
 Rechercher l’information dans une base de données
 Calculer le prix
Les opérations doivent assumer un fonction simple et cohésive

208
Les Opérations dépendent du

domaine
 Lister toutes les opérations relevantes au domaine du

problème
 Les opérations d’une classe Personne seront différentes en
fonction de qui il s’agit
209
Nomenclature des opérations
 Les Opérations doivent être nommées en

indiquant leur résultat, et non les étapes derrière
ces opérations. Exemples:
 calculerSolde()
 Mauvais nom
 Indique que le solde doit être calculer – ceci est une décision
d’implémentation et/ou d’optimisation
 getBalance()
 Bon nom
 Indique uniquement le résultat
210
Nomenclature des opérations
 Les opérations doivent être nommées de la

perspective du fournisseur et non de celle du
client
 Dans une station d’essence, l’essence est reçue
depuis la pompe
 Une opération de la pompe à cette responsabilité – quel
nom aura-t-elle?
 Bon noms: livre(), donneEssence()
 Mauvais noms: recoitEssence()
 La pompe fourni l’essence, elle ne reçoit pas l’essence
211
Opération primitive
 Une opération primitive est une opération qui ne peut être

implémentée qu’avec les éléments internes d’une classe
 Toutes les opérations d’une classe sont typiquement primitives
 Exemple:
 Ajout d’un élément a un ensemble (opération primitive)
 Ajout de 4 éléments à un ensemble (opération non primitive)
 Peut être implémentée avec plusieurs appels de l’opération « ajout
d’un élément à un ensemble)
212
Signatures des Opérations
 La signature d’une opération consiste en:

 Une liste optionnelle de paramètres
 Une classe de retour
 Pendant l’analyse, il n’est PAS
OBLIGATOIRE de renseigner la signature
des opérations
 Cette information peut être reportée jusqu’au
design
213
Affichage des Opérations
 Les opérations sont présentées dans le 3e

compartiment d’une classe
214
Découverte des Opérations depuis les

 Les messages affichés dans les diagrammes d’interactions

(séquence et collaboration) sont généralement des
opérations de la classe qui reçoit ces messages
 Ces messages sont traduits en opérations et ajoutés au
diagrammes de classes
215
Découverte des classes additionnelles
 Quand on spécifie la signature d’une opération,

des classes additionnelles peuvent être
découvertes
 Arguments de l’opération
 Classes de retour
 Exemples:
 getPrerequis(): ListeDeMatieres
 ajouterEtudiant(kouassi: InformationEtudiant)
 Les classes découvertes sont ajoutées au modèle
 Elles sont affichées dans le diagramme de classe au
besoin
216
Découverte des relations

additionnelles
 Les arguments et classes de retour des

opérations dénotent d’une relation entre la classe
et les arguments et/ou la classe de retour
 Exemple:
 La classe ListeEtudiant possède une opération
ajouterEtudiant(kouassi:InformationEtudiant)
 Cela implique qu’il existe une relation entre
ListeEtudiant et InformationEtudiant
 Les relations découvertes sont affichées sur les
diagrammes de classe au besoin
217
Qu’est ce qu’un attribut?
 Un attribut est une caractéristique d’une classe

 Les attributs n’ont pas d’identité – ce ne sont pas des
objets
 Les noms d’attributs sont simplement des « noms »
 Les noms doivent être uniques dans la classe
 Chaque attribut doit avoir une définition claire et concise
 Bons attributs pour la classe Etudiant
 Noms – nom et prénoms
 MatiereDeBase – matière de base
 Mauvais attribut
 MatieresSelectionnées
 Il s’agit ici d’une relation et non d’un attribut
218
Valeurs des attributs
 La valeur d’un attribut est la valeur d’un attribut pour un

objet particulier
 Chaque objet a une valeur pour chacun des attributs
définis pour sa classe
 Par exemple, pour un objet de la classe Professeur:
219
Les attributs dépendent du domaine
 Lister tous les attributs relevant du domaine du

problème
 Les attributs d’une classe Personne seront différents
en fonction de la personne concernée
220
Affichage des attributs
 Les attributs sont affichés dans le second

compartiment d’une classe
221
Attributs dérivés
 Un attribut dérivé est un attribut dont la valeur peut être

calculée sur la base des valeurs d’autres attributs
 Il est utilisé quand il n’y a pas suffisamment de temps pour
recalculer la valeur quand on en a besoin
 Des compromis entre performance et mémoire sont requis
222
Type de données et valeur initiale d’un

attribut
 Chaque attribut à:
 Un type de données
 Une valeur initiale (optionnelle)
 Pendant l’analyse, il n’est PAS OBLIGATOIRE de
donner la définition complète de l’attribut
 Cette information peut être reportée jusqu’au design
223
Découverte des attributs
 Plusieurs attributs sont découverts dans le texte de

l’énoncé du problème
 Rechercher dans les noms qui n’ont pas été jugés bon candidats
pour les classes
 Les autres attributs sont découverts quand la classe est
crée
 L’expertise du domaine peut aussi fournir de bons
attributs
Il ne faut modéliser que les attributs relevants du domaine du problème
224
Exemple: attributs dans le problème

d’inscriptions académiques
 Chaque Matière doit avoir une description dans le

catalogue
 Un attribut appelé description est ajouté a la classe
Matiere
225
Style pour la nomenclature des

attributs et opérations
 Un style établit les conventions de nomenclature des

attributs et opérations
 Fournit de la consistance tout le long du projet
 Débouche sur des modèles et des code facile a maintenir
 Exemple:
 Les attributs et les opérations commencent avec une lettre
minuscule
 Les sous tirets ne sont pas utilisés
 Les noms composés sont concaténés avec la première lettre de
chaque mot additionnel en capital
226
Affichage des attributs et opérations
 Les attributs et/ou opérations peuvent être

affichés dans une classe
 Des classes additionnelles peuvent être crées
pour afficher attributs et opérations
 Les relations ne sont typiquement pas affichées dans
ces types de diagrammes
227
Encapsulation
 Une manière de visualiser les classes les décompose en

2 parties: l’interface et l’implémentation
 L’interface peut être vue et utilisée par d’autres objets
 L’implémentation est cachée des autres objets
 Le fait de cacher les détails de l’implémentation est
appelé « encapsulation »
 L’encapsulation offre 2 types de protection:
 L’état interne d’un objet est protégé (de corruption par les clients)
 Le code client est protégé des modification dans l’implémentation
de l’objet
228
Exemple d’encapsulation
229
Encapsulation
 Le code client peut utiliser l’interface d’une opération

 Le code client ne peut prendre avantage de l’implémentation d’une
opération
 L’implémentation peut changer pour par exemple:
 Corriger un bug
 Améliorer les performances
 Refléter un changement dans la politique
 Le code client ne sera pas affecté par les modifications dans
l’implémentation, réduisant ainsi l’effet « vague » selon lequel, des
corrections dans une opération nécessitent des corrections dans le
code client et ainsi de suite…
 La maintenance est plus simple et moins coûteuse
230
Résumé:
 Les attributs sont découverts dans le texte de l’énoncé du

problème, quand la classe est créée et pendant
l’expertise du domaine
 Seuls les attributs appropriés et les méthodes doivent
être modélisés
 L’encapsulation est le fait de cacher les détails de
l’implémentation du monde extérieur
 Elle protège l’état interne d’un objet
 Elle protège le code client des modifications dans
l’implémentation des objets
231
232
HERITAGE
233
Héritage
Objectifs: Héritage
A la fin de ce chapitre, vous devez pouvoir

 Définir l’héritage, la généralisation et la spécialisation
 Représenter les hiérarchies d’héritage sur un

diagramme de classes
 Comprendre les techniques de découverte de
l’héritage
234
Héritage
Héritage
 L’héritage définit une relation entre classes ou l’une

partage la structure et/ou le comportement avec l’autre ou
les autres
 L’héritage définit une hiérarchie d’abstraction dans
laquelle une sous classe hérite d’une ou de plusieurs
superclasses
 Avec l’héritage simple, la sous classe hérite d’une et une seule
superclasse
 Avec l’héritage multiple, la sous classe hérite d’une ou de
plusieurs superclasses
 L’héritage est une relation « est-un » ou « type de »
235
Héritage
Représentation d’une hiérarchie

d’héritage
236
Héritage
Héritage
 Dans la mesure ou la relation d’héritage ne lie

pas individuellement les objets
 La relation n’est pas nommée
 La multiplicité n’a pas de sens
 Théoriquement, il n’y a pas de limite de niveaux
dans une hiérarchie
237
Héritage
Qu’est ce qui est hérité?
 Une sous classe hérite de ses parents:

 Attributs
 Opération
 Relations
 Une sous classe peut:
 Ajouter des attributs, opération, relations
 Redéfinir les opération héritées (à utiliser avec
précaution)
L’héritage met en relief les similarités entre les classes
238
Héritage
Héritage des attributs

 Les attributs sont définis au plus haut niveau de la hiérarchie auquel
ils s’appliquent
 Les sous classes d’une classe héritent de tous les attributs
 Chaque sous classe peut ajouter des attributs
Un camion à 3 attributs:
immatriculation
poids
tonnage
239
Héritage
Héritage des opérations

 Les opérations sont définies au plus haut niveau de la hiérarchie auquel elles
s’appliquent
 Les sous classes d’une classe héritent de toutes les opérations
 Chaque sous classe peut ajouter des opération ou redéfinir les opérations
héritées
Un camion à 3 attributs:
immatriculation
poids
tonnage
et 2 opérations:
immatriculer()
getTaxe()
240
Héritage
Héritage des relations

 Les relations sont aussi héritées et doivent être définies au plus au
niveau de la hiérarchie auquel elles sont applicables
 Les sous classes d’une classe héritent de toutes les relations
 Chaque sous classe peut aussi participer a des relations
additionnelles
Une voiture est liée à un propriétaire
Un camion est lié a un propriétaire
Un camion possède aussi une remorque
241
Héritage
Généralisation des classes
 La généralisation offre la possibilité de créer une

superclasse qui va encapsuler la structure et/ou le
comportement communs a plusieurs sous classes
 Procédure de généralisation
 Identifier les similitudes dans la structure et la comportement entre
plusieurs classes
 Créer une superclasse pour encapsuler la structure et le
comportement commun
 Les classes originales sont sous classées a la nouvelle
superclasse
 Les superclasses sont plus abstraites que leurs sous
classes
242
Héritage
Exemple de généralisation
243
Héritage
Spécialisation des classes
 La spécialisation fournit la possibilité de créer des

sous classes représentant des raffinements dans
lesquels la structure et comportement de la
superclasse sont complétés ou modifiés
 Procédure de spécialisation
 Remarquer que certaines instances exhibent une
structure ou comportement spécialisés
 Créer des sous classes pour regrouper les instances
en fonction de leur spécialisation
244
Héritage
Exemple de spécialisation
245
Héritage
Hiérarchies d’héritage
 La généralisation et la spécialisation sont utilisées

pour développer une hiérarchie d’héritage
 Pendant l’analyse, les hiérarchies d’héritages
entre les abstractions clés (classes) sont établies
si nécessaire
 Pendant le design, les hiérarchies sont raffinées
pour:
 Augmenter la réutilisation
 Incorporer les classes
 Incorporer les librairies (bibliothèques) disponibles
246
Héritage
Niveaux d’abstraction
Les classes au même niveau

d’héritage doivent être au même
niveau d’abstraction
247
Héritage
Recherche de l’héritage
 Il est important d’évaluer toutes les classes pour détecter

les possibilités d’héritage
 Rechercher les comportements communs (opérations) et états
communs (attributs) dans les classes
 Technique d’ajout
 Ajouter les nouveaux attributs et opérations aux sous classes
 Technique de modification
 Redéfinir les opérations
 Il faut être vigilant pour ne pas changer la sémantique
248
Héritage
Héritage et composition
 L’héritage et la composition sont souvent

confondus
 L’héritage représente une relation « est-un » ou « est-
un-type-de »
 La composition ou agrégation représente une relation «
a-un » (possède-un)
Les mots clés « est-un » et « a un » aident dans la détermination

de la relation appropriée
249
Héritage
Fenêtre et barre de défilement
Une FenetreAvecBarreDeDefilement « est-une » Fenetre

Une FenetreAvecBarreDeDEfilement « a-une » BarreDeDefilement
Quelles relations utiliser?
250
Héritage
Fenêtre et barre de défilement
Une FenetreAvecBarreDeDefilement « est-une » Fenetre

Une FenetreAvecBarreDeDefilement « a-une » BarreDeDefilement
251
Héritage
Héritage et composition
252
Héritage
Résumé:
 L’héritage définit une relation entre classes ou une classe partage la
structure et/ou le comportement d’une ou de plusieurs autres classes
 Elle définit la hiérarchie des abstractions dans laquelle une sous classe
hérite d’une ou de plusieurs superclasses
 Héritage simple: une classe hérite d’une superclasse
 Héritage multiple: une classe hérite de plus d’une superclasse
 Une sous classe hérite des attributs, opérations et relations de sa
superclasse
 Une sous classe peut
 Ajouter des attributs, opérations et relations
 Redéfinir les opérations héritées
253
Héritage
Résumé:
 La généralisation offre la possibilité de créer des

superclasses qui encapsulent la structure et/ou le
comportement communs a plusieurs sous classes
 La spécialisation offre la possibilité de créer des sous
classes qui représentent des raffinements dans lesquels
la structure et le comportement des superclasses sont
complétés ou modifiés
 L’héritage et la composition sont souvent confondus
 L’héritage représente la relation « est-un » ou « est un type de »
 La composition représente la relation « a-un »
254
255
COMPORTEMENT DE L’OBJET
256
Comportement de l’Objet
Objectifs:
A la fin de ce chapitre, vous devez pouvoir

 Expliquer la nécessité des diagrammes d’état
 Comprendre comment découvrir les états
 Développer un simple diagramme d’état comprenant
 Les états et transitions
 Les événements
 Les conditions
 Les Actions et activités
 Comprendre le concept d’état imbriqués
 Expliquer les relations entre diagrammes d’états, diagrammes
d’interaction et diagrammes de classe
257
Qu’est qu’un diagramme d’état ?
 Un diagramme d’état est utilisé pour montrer la ligne

de vie d’une classe donnée, les événements qui
provoquent la transition d’un état a l’autre et les
actions qui résultent du changement d’état.
 L’espace d’état d’une classe donnée est l’énumération
de tous les états dans lesquels un objet peut exister
 L’état d’un objet est une des possibles conditions
dans lesquelles un objet peut exister
 Il comprends les propriétés d’un objet
 Généralement statique
 Et aussi les valeurs courantes de chacune de ces propriétés
 Généralement dynamique
258
Représentation des états
 Un état est représenté par un rectangle au bords

arrondis dans un diagramme d’état (DE)
259
État et attributs
 Les états peuvent être distingués par la valeur de certains

attributs
260
État et liens
 Les états peuvent aussi être distingués par l’existence de certains

liens
 Les instances de la classe Professeur peuvent avoir 2 états:
 Occupé quand un lien à un cours existe
 Libre quand aucun lien n’existe
261
États spéciaux
 L’état initial est l’état dans lequel un objet se trouve au moment de sa

création
 L’état initial est obligatoire
 Un seul état initial est permis
 L’état initial est représenté par un cercle solide
 L’état final indique l’état dans lequel un objet se trouve en fin de vie
 L’état final est optionnel
 Plus d’un état final peut exister
 Un état final est indiqué par un cercle solide entouré d’un autre cercle (œil de
boeuf)
262
Événements
 Un événement est une occurrence qui

intervient à un moment donné
 L’état d’un objet détermine sa réponse à différents
événements
 Exemple:
 Ajout d’un étudiant à une matière
 Création d’une nouvelle matière
263
Transitions
 Une transition est un changement d’un état original à un état

suivant, en réponse a quelque stimulus
 L’état suivant pourrait bien être l’état original
 Une transition intervient en réponse a un événement
 Les transitions peuvent être annotées avec les événements
264
Conditions
 Une condition est une expression booléenne de

valeurs d’attribut qui permet la transition si et
seulement si la condition est vraie
265
Actions
 Une action est une opération associée à une transition

 Le temps nécessaire pour son exécution est insignifiant
 Elle est considérée non interruptible
 Les noms d’action sont représentés sur la flèche de transition
précédés d’un slash
266
Activités
 Une activité est une opération qui prends du temps pour

s’exécuter
 Les activités sont associées à un état
 Une activité
 Commence avec un état initial
 Peut s’exécuter jusqu’à la fin ou peut être arrêtée par une autre
transition
267
Transitions automatiques
 Souvent, la seule raison d’existence d’un état est d’exécuter une

activité
 Une transition automatique se produit quand cette activité prends
fin
 Si il y a plusieurs transitions automatiques
 Une condition est requise pour chacune des transitions
 Ces conditions doivent être mutuellement exclusives
268
Actions d’entrée et de sortie
 Une action peut être associée à un état quand cette action doit
avoir lieu, que l’état soit en phase initiale ou finale
 En réalité, l’action est associée à toute transition entrant ou sortant
de l’état en cours
 L’action est présentée dans l’icône de l’état, précédée du mot clé
entry (entrée) ou exit (sortie)
269
États imbriqués
 Les diagrammes de transition peuvent devenir très larges et complexes

 Les états imbriqués peuvent être utilisés pour simplifier des diagrammes
complexes
 Un super état est un état qui contient des état imbriqués appelés sous
états
 Les transitions communes des sous états sont représentés au niveau du
super état
 Il n’y a pas de limite au nombre d’états imbriqués
 Les états imbriqués peuvent aboutir a la réduction de complexité
graphique, nous permettant de modéliser des problèmes plus larges et
plus complexes
270
Diagrammes de transition pour la classe

Matière sans les états imbriqués
271
Diagrammes de transition pour la classe

Matière avec les états imbriqués
272
États imbriqués avec historique
 L’utilisation de l’historique indique qu’au retour

d’un super état, le sous état visité le plus
récemment sera utilisé
 On utilise un H entouré pour dénoter que
l’historique s’applique au super état
 Si l’historique n’est pas utilisé, le sous état
initial sera utilisé à l’entrée du super état
273
Exemple d’états imbriqués avec

historique
 Dans le système d’inscriptions, la classe SelectionMatiere

 Accepte les cours de premier choix
 Accepte les cours de second choix
 L’utilisateur quitter a n’importe quel moment
 L’utilisateur peut suspendre une session pour un maximum de 30
minutes pendant la sélection des matières
 Le formulaire est enregistré après que tous les cours aient été
sélectionnés
 Le formulaire est soumis pour traitement après avoir été
enregistré
274
Exemple d’états imbriqués avec

historique
275
Ou commencer ?
 Pendant l’analyse, on se concentre initialement sur le

comportement des classes ayant un comportement dynamique
significatif
 Pour une classe donnée, on recherche les états possibles en
 Évaluant les valeurs des attributs
 Évaluant les opérations
 Définissent les règles pour chaque état et
 Identifiant les transitions valides entre états
 Examiner les diagrammes des messages impliquant la classe
 L’intervalle entre 2 opérations peut être un état
276
Exercice
 Développer un diagramme d’état pour un ascenseur ayant le

comportement suivant:
 Quand il ne se rend pas à un étage, l’ascenseur attends à l’étage courant
 Quand l’ascenseur est appelé d’un étage supérieur a l’étage courant, il monte
vers l’étage spécifié
 Quand l’ascenseur est appelé d’un étage inférieur, il descends vers l’étage
spécifié
 Quand l’ascenseur arrive à l’étage demandé, il ouvre automatiquement la
porte et la referme après 30 secondes
 Quand l’ascenseur est appelé de l’étage courant, il ouvre sa porte pour 30
secondes
 Assumer que les requêtes se font sur la base de « premier venu, premier
servi »
277
Exercice
278
Résumé:
 Un diagramme d’état représente le cycle de vie de
l’objet en termes
 Des états possibles de l’objet
 Des transitions entre ces états
 Il existe 2 états spéciaux
 L’état initial est l’état d’un objet à sa création
 L’état final indique la fin de la vie de l’objet
 Une transition est un changement d’un état original à
un autre état, possiblement le même.
279
Résumé:
 Une transition résulte
 De l’occurrence d’un événement
 D’une condition satisfaite
 Une action est une opération qui se produit en un
temps insignifiant
 Une activité est une opération qui s’exécute pendant
que l’objet est dans un état
 Les états imbriqués permettent de gérer les complexités
associées aux diagrammes d’état
 L’historique permet la visualisation du plus récent sous
état dans un état
280
281

Aoo Uml

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

Aoo Uml

Transféré par

Droits d'auteur :

Formats disponibles

ANALYSE ET DESIGN AVEC UML

© 2006, Philippe Kouao, NTIC/DED/SNDI, Abidjan

 Introduction à l’analyse orientée objets et au design

© 2006, Philippe Kouao, NTIC/DED/SNDI, Abidjan

 Interactions entre objets

© 2006, Philippe Kouao, NTIC/DED/SNDI, Abidjan

 Design des classes

 Design des relations

© 2006, Philippe Kouao, NTIC/DED/SNDI, Abidjan

© 2006, Philippe Kouao, NTIC/DED/SNDI, Abidjan

 A la fin de ce chapitre, vous devez pouvoir:

 Expliquer la crise liée aux logiciels

 Discuter des atouts de la technologie orientée objet (00)

 Discuter des domaines dans lesquels la technologie OO

peut être utilisée

 Expliquer les origines de UML

© 2006, Philippe Kouao, NTIC/DED/SNDI, Abidjan

© 2006, Philippe Kouao, NTIC/DED/SNDI, Abidjan

 Chaque étape doit être bouclée avant que la

o Les problèmes majeures sont:

© 2006, Philippe Kouao, NTIC/DED/SNDI, Abidjan 9

© 2006, Philippe Kouao, NTIC/DED/SNDI, Abidjan

 Le modèle en cascade n’est pas mauvais en soi.

 Ce modèle vaut beaucoup mieux que le chaos.

© 2006, Philippe Kouao, NTIC/DED/SNDI, Abidjan

 Dans ce modèle, le projet est divisé

© 2006, Philippe Kouao, NTIC/DED/SNDI, Abidjan

© 2006, Philippe Kouao, NTIC/DED/SNDI, Abidjan

Le modèle itératif et incrémental

 Ce modèle est une extension logique du modèle en spirale a la

© 2006, Philippe Kouao, NTIC/DED/SNDI, Abidjan

Le modèle itératif et incrémental

 Les livrables possibles sont:

© 2006, Philippe Kouao, NTIC/DED/SNDI, Abidjan

Le modèle itératif et incrémental

© 2006, Philippe Kouao, NTIC/DED/SNDI, Abidjan

Le modèle itératif et incrémental

 Elle ne se fait pas de façon linéaire mais suit le modèle en

spirale, en passant par une série d’itérations.

 En réduisant la durée de chacune des itérations, les

© 2006, Philippe Kouao, NTIC/DED/SNDI, Abidjan

Le modèle itératif et incrémental

•L’objectif à l’issue de chaque itération est de disposé d’un système

© 2006, Philippe Kouao, NTIC/DED/SNDI, Abidjan

Le modèle itératif et incrémental

Le modèle itératif et incrémental

Exemples de modèles itératifs

© 2006, Philippe Kouao, NTIC/DED/SNDI, Abidjan

Less than 5% Used with no changes

More than 95% Required

Delivered But Unusable

Paid for But Not Delivered

© 2006, Philippe Kouao, NTIC/DED/SNDI, Abidjan

© 2006, Philippe Kouao, NTIC/DED/SNDI, Abidjan

Évolutivité des besoins

© 2006, Philippe Kouao, NTIC/DED/SNDI, Abidjan

Échec dans la gestion du risque

© 2006, Philippe Kouao, NTIC/DED/SNDI, Abidjan

La complexité des logiciels

© 2006, Philippe Kouao, NTIC/DED/SNDI, Abidjan

Les atouts de la technologie 00

© 2006, Philippe Kouao, NTIC/DED/SNDI, Abidjan

Simple exemple de commande