Vous êtes sur la page 1sur 101

Analyse et Conception

Orientées Objet
UML

OFPPT/ EL KASSMI

1
2

Comment modéliser avec UML ?


UML est un langage qui permet de représenter des modèles, mais il ne
définit pas le processus d'élaboration des modèles !

Dans le cadre de la modalisation d’une application informatique, les


auteurs d’UML préconisent d’utiliser une démarche :
 Itérative et incrémentale,
 Guidée par les besoins des utilisateurs du système,
 Centrée sur l'architecture logicielle

D'après les auteurs d'UML, un processus de développement qui possède


ces qualités devrait favoriser la réussite d'un projet.

2013 - 2014 OFPPT/ EL KASSMI


Pourquoi des méthodes ?
3

Rien ne dicte a priori comment modéliser


un système de manière pertinente

• Besoin de méthodologie

Outils
Entreprise Informatiques

2013 - 2014 OFPPT/ EL KASSMI


Pourquoi des méthodes ?
4

Démarche reproductible pour obtenir des résultats fiables


Construire des modèles à partir d'éléments (concepts)
Possibilité de représenter à partir de formalismes
Mise en œuvre

Démarche qui distingue les étapes du développement dans le cycle de vie du logiciel
Modularité, réduction de la complexité, réutilisabilité, abstraction
Un formalisme de représentation qui facilite la communication, l’organisation
et la vérification
Production de documents (modèles) qui facilitent les retours sur conception
et l’évolution des applications

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Atouts
5

Universalité de l’Objet
La notion d’objet, plus proche du monde réel, est compréhensible par tous et
facilite la communication entre tous les intervenants d’un projet.

Omniprésence technique de l’Objet


dans les langages de programmation, les bases de données, les interfaces
graphiques, ... et les méthodes d’analyse et de conception.

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Approche fonctionnelle
6

Décomposition fonctionnelle depuis le cahier


des charges jusqu’au sous-programmes

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Approche Objet
7

1966 une idée à Oslo


1980 : Smalltalk
1988 : Schlaer/Mellor (OOSA)
Les objets sont des entités autonomes qui collaborent afin
de fournir les fonctionnalités du système
Les objets représentent des entités du monde réel de
l’application

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Objectifs de l’approche Objet
8

Architecture Flexible
Evolution du système
Réutilisation des objets
Etc

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Unification des méthodes orientées objet
9

Méthode = Processus + Langage

La guerre des méthodes ne fait plus avancer la


technologie des objets

Recherche d’un langage commun unique


Utilisable par toutes les méthodes
Adapté à toutes les phases du développement
Compatible avec toutes les techniques de réalisation

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Unification des langages de modélisation orientés objet
10

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Unification des langages de modélisation orientés objet
11

Basée sur les méthodes de BOOCH, OMT et OOSE


Influencée par les bonnes idées des autres méthodes
Mûrie par le travail en commun

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Résumé
12

En résumé

UML est un langage de modélisation, pas une méthode


UML est un langage de modélisation objet
UML convient pour toutes les méthodes objet
UML est dans le domaine public

UML est le langage standard


de modélisation orientée objet

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Diagrammes UML

OFPPT/ EL KASSMI

13
Qu’est ce que UML
14

la structuration
des objets les
Vue statique Vue composants
implantation logiciels
Diagrammes
classes, objets Diagrammes
composants

les fonctions Vue externe


du système Cas
d’utilisation
Vue Vue
dynamique déploiement
le Diagrammes
comportement collaborations Diagrammes l’architecture
des objets séquences, déploiement physique
états, activités
Concepts utilisables tout au long du projet :
analyse conception implantation
2013 - 2014 OFPPT/ EL KASSMI
2013 - 2014 OFPPT/ EL KASSMI
Diagrammes des cas d’utilisation

OFPPT/ EL KASSMI

15
Origine
16

Formalisés par Ivar Jacobson : Object-Oriented


Software Engineering (Addison-Wesley, 1992)

Décrivent le comportement du système (actions


et de réactions), selon le point de vue de
l’utilisateur

Chaque cas d’utilisation décrit le comportement


du système suite à une stimulation externe

Modèle
Acteurs + Cas d’utilisation + Relations

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Intérêts
17

Déterminer les besoins fonctionnels du système

Utilisés par les utilisateurs pour exprimer leur


attentes et leur besoins

Permettent d’impliquer les utilisateurs dès les


premiers stades du développement

Constituent une base pour les tests fonctionnels

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Acteurs
18

Un acteur est une entité externe qui interagit avec


le système (fournir, recevoir, échanger de
l’information)

On trouve les acteurs en observant les utilisateurs


directs du système ainsi que les autres systèmes
qui interagissent avec le système

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Acteurs – Les utilisateurs-
19

Un acteur représente un rôle joué par un


utilisateur qui interagit avec le système

La même personne physique peut jouer le rôle de


plusieurs acteurs (vendeur, client)

Plusieurs personnes peuvent également jouer le


même rôle, et donc agir comme le même acteur
(tous les clients)

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Cas d’utilisation
20

Notation

Les cas d’utilisations représentent le dialogue


entre l’acteur et le système de manière abstraite

Ensemble de scénarios au sein d’une description


unique

Les cas d’utilisations doivent être vus comme


des classes de scénarios

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Détermination des cas d’utilisation
21

Quelles sont les tâches de l’acteur ?

Quelles informations l’acteur doit-il créer,


sauvegarder, modifier, détruire ou simplement
lire?
L’acteur devra-t-il informer le système de
changements externes?

Le système devra-t-il informer l’acteur de


conditions internes au système

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Relations
22

Include

Le comportement de B est obligatoire pour réaliser le


comportement de A

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Relations (suite)
23

Extend
Le comportement de B est optionnel et ne se déclenche que
par une condition dans le comportement de A

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Relations (suite)
24

Généralisation:
Le cas B est une abstraction du cas A

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Mise en œuvre des cas d’utilisations
25

Identifier la plupart des cas d’utilisations (<20)

Décrire brièvement chaque cas d’utilisation (2 à


3 phrases)

Décrire en détails chaque cas d’utilisation


-Début
-Fin
- Interaction entre acteur et le cas d’utilisation
- Chronologie
- Echange d’informations

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Précautions
26

Un cas d’utilisation est une abstraction d’un


ensemble de comportement (Scénarios)
fonctionnellement liés

Un cas d’utilisation est un outil d’analyse et non pas


de conception
Eviter l’utilisation des expressions floues telles que
faible, assez, moyen dans la description d’un cas
d’utilisation

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Etude de cas (guichet automatique de banque GAB)
27

On considère le système suivant de gestion d’un GAB :

- le distributeur délivre de l’argent à tout porteur d’une carte de la


banque (autorisation d’un certain montant par le Système
d’Information de la banque) ou d’une carte de crédit (autorisation à
distance par le Système d’Autorisation),

- Pour les clients de la banque, il permet en plus :


 la consultation du solde du compte
 le dépôt d’argent (chèque ou numéraire)

- Toute transaction est sécurisée et nécessite par conséquent une


authentification (code personnel vérifié avec le code enregistré sur la
puce de la carte - la carte est avalée après trois échecs).

- Dans le cas où une carte est avalée par le distributeur, un opérateur de


maintenance se charge de la récupérer. C’est la même personne qui
collecte également les dépôts d’argent et qui recharge le distributeur.
2013 - 2014 OFPPT/ EL KASSMI
2013 - 2014 OFPPT/ EL KASSMI
Étape 1 - Identification des acteurs du GAB
28

Quelles sont les entités externes qui interagissent directement avec le GAB ?

tout Porteur de carte . . .


Les clients de la banque porteurs d’une carte de crédit de cette dernière.
le Système d’autorisation global Carte Bancaire, pour les transactions de retrait
le Système d’information de la banque, pour autoriser toutes les transactions effectuées
par un client avec sa carte de la banque, mais également pour accéder au solde des
comptes
Opérateur de maintenance pour le rechargement en billets du
distributeur, la récupération des cartes avalées, etc.

Attention !
le lecteur de carte et le distributeur de billets font partie du GAB ) ce ne
sont pas des acteurs !

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Étape 2 - Identification des cas d’utilisation
29

Préparez une liste préliminaire des cas d’utilisation du GAB, par acteur.

Porteur de carte :
Retirer de l’argent.
Client de la banque :
Retirer de l’argent.
Consulter le solde de son compte courant.
Déposer de l’argent (du numéraire ou des chèques).
Opérateur de maintenance :
Recharger le distributeur.
Maintenir l’état opérationnel (récupérer les cartes avalées, récupérer les
chèques déposés, remplacer le ruban de papier, etc.).

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Étape 3 - Réalisation de diagrammes de cas d’utilisation
30

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Acteurs secondaires
31

Complétez le diagramme de cas d’utilisation préliminaire en


ajoutant les acteurs secondaires.

Un problème se pose pour le cas d’utilisation partagé Retirer de l’argent.


Pour le Porteur de carte non client, il faudra faire appel au Sys.
Auto. (qui se chargera de contacter le SI de la banque du porteur),
Pour un client de la banque, le GAB contactera directement le SI
banque.
2013 - 2014 OFPPT/ EL KASSMI
2013 - 2014 OFPPT/ EL KASSMI
Acteurs secondaires
32

Solution : distinguer deux cas d’utilisation pour le retrait d’argent :


Retirer de l’argent
Retirer de l’argent avec une carte de la banque.

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Étape 4 - Description textuelle des cas d’utilisation
33

Description du cas d’utilisation RETIRER DE L’ARGENT (pour l’acteur


non client de la banque).

Sommaire d’identification
Titre : Retirer de l’argent
Résumé : ce cas d’utilisation permet à un Porteur de carte, qui n’est pas client
de la banque, de retirer de l’argent, si son crédit hebdomadaire le permet.
Acteurs : Porteur de carte (principal), Système d’autorisation (secondaire).

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Pré-Conditions
34

Préconditions

• La caisse du GAB est alimentée (il reste au moins un billet !).


• Aucune carte ne se trouve déjà coincée dans le lecteur.
• La connexion avec le Système d’autorisation est opérationnelle.

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Scénario nominal
35

Scénario nominal
1. Le Porteur de carte introduit sa carte dans le lecteur de cartes du GAB.
2. Le GAB vérifie que la carte introduite est bien une carte bancaire.
3. Le GAB demande au Porteur de carte de saisir son code d’identification.
4. Le Porteur de carte saisit son code d’identification.
5. Le GAB compare le code d’identification avec celui qui est codé sur la
puce de la carte.
6. Le GAB demande une autorisation au Système d’autorisation.
7. Le Système d’autorisation donne son accord et indique le solde hebdomadaire.
8. Le GAB demande au Porteur de carte de saisir le montant désiré du retrait.
9. Le Porteur de carte saisit le montant désiré du retrait.
10. Le GAB contrôle le montant demandé par rapport au solde hebdomadaire.
11. Le GAB demande au Porteur de carte s’il veut un ticket.
12. Le Porteur de carte demande un ticket.
13. Le GAB rend sa carte au Porteur de carte.
14. Le Porteur de carte reprend sa carte.
15. Le GAB délivre les billets et un ticket.
16. Le Porteur de carte prend les billets et le ticket.
2013 - 2014 OFPPT/ EL KASSMI
2013 - 2014 OFPPT/ EL KASSMI
Scénario nominal
36

2a. Carte illisible ou non valable :


Le GAB avertit le Porteur et éjecte la carte ; le cas d’utilisation se termine en échec.
2b. Carte périmée :
Le GAB avertit le Porteur et confisque la carte ; le cas d’utilisation se termine en échec.
4a. Délai de saisie du code expiré :
Le GAB avertit le porteur et éjecte la carte ; le cas d’utilisation se termine en échec.
4a2. Le Porteur annule la transaction :
Le GAB éjecte la carte ; le cas d’utilisation se termine en échec.
5a. Code d’identification erroné pour la première ou deuxième fois :
5a1. Le GAB enregistre l’échec sur la carte.
5a2. Le GAB avertit le Porteur et le scénario nominal reprend à l’étape 3.
5b. Code d’identification erroné pour la troisième fois :
Le GAB avertit le Porteur et confisque la carte ; le cas d’utilisation se termine en échec.
7a. Transaction refusée par le Système d’autorisation :
Le GAB avertit le Porteur et éjecte la carte ; le cas d’utilisation se termine en échec.

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Scénario nominal
37

7b. Délai de réponse du Système d’autorisation expiré :


Le GAB avertit le Porteur et éjecte la carte ; le cas d’utilisation se termine en échec.
9a. Délai de saisie du montant expiré :
Le GAB avertit le Porteur et éjecte la carte ; le cas d’utilisation se termine en échec.
10a. Montant demandé supérieur au solde hebdomadaire :
10a1. Le GAB avertit le Porteur et le scénario nominal reprend à l’étape 8.
10b. Solde hebdomadaire insuffisant :
Le GAB avertit le Porteur et éjecte la carte ; le cas d’utilisation se termine en échec.
12a. Le Porteur ne demande pas de ticket :
Le cas d’utilisation continue à l’identique, sauf l’impression du ticket.
14a. Délai de retrait de la carte expiré :
14a1. Le GAB confisque la carte et annule la transaction ;
14a2. Le GAB avertit le Système d’autorisation et le cas d’utilisation se termine en échec
16a. Délai de retrait des billets expiré :
Le GAB confisque les billets et annule la transaction ; le cas d’utilisation se termine en
échec.
1-7a. Coupure réseau avec le Système d’autorisation :
Le GAB avertit le Porteur et éjecte la carte ; le cas d’utilisation se termine en échec.
2013 - 2014 OFPPT/ EL KASSMI
2013 - 2014 OFPPT/ EL KASSMI
Diagrammes d’interaction
Les scénarios

OFPPT/ EL KASSMI

38
Définition
39

Un scénario est une instance d’un cas


d’utilisation

Chaque cas d’utilisation a un WEB de scénarios

Les scénarios sont modélisés par les diagrammes


d’interaction:

Diagrammes de séquence
Diagrammes de collaboration

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Scénarios du cas d’utilisation: Inscription-cours
40

On distingue deux types de scénarios

Scénarios principaux
Cas normaux de fonctionnement du système
Scénarios secondaires
Exceptions des scénarios principaux

Créer un calendrier
Consulter son calendrier
Changer son calendrier

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Scénarios et Objets
41

Les objets représentent des entités concrètes


(Physique) ou abstraites (concept)

Notation

Un objet est caractérisé par:

Son état
Son comportement
Son identité

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Etat d’un objet
42

L’état d’un objet est représenté par les valeurs


des propriétés de l’objet à un instant donné

L’état évolue au cours du temps

Exemple :
L’objet Cours de l’application SIA
Si nombre d’étudiants inscris>10 => Cours est fermé
Si nombre d’étudiants inscris 3<..<10 => Cours ouvert

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Comportement d’un objet
43

Le comportement décrit les actions et les


réactions d’un objet avec les autres objets

Le comportement est déterminé par les


opérations qu’un objet peut réaliser

Exemple :
L’objet Cours de l’application SIA
Ajouter-étudiant
Suprimer-étudiant
Affecter-enseignant

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Comportement d’un objet(suite)
44

L’état et le comportement sont liés

L’état est modifié par le comportement

Le comportement dépend de l’état

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Identité d’un objet
45

Tout objet possède une identité qui lui est


propre et qui le caractérise

L’identité permet de distinguer tout objet de


façon non ambiguë, indépendamment de l’état

Les langages objets utilisent généralement des


clés pour réaliser un identifiant

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Détermination des objets
46

Les objets sont déterminés à partir des cas


d’utilisation et des scénarios (entités manipulées)

Exemples: SIA

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Interaction entre Objets
47

Application = société d'objets collaborants

Les objets travaillent en synergie afin de réaliser


les fonctions de l’application

Le comportement global d’une application


repose donc sur la communication entre les
objets qui la composent

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Scénarios et Interaction entre Objets
48

Scénario = Interaction entre un sous ensemble


d'objets de l’application

Les scénarios sont modélisés par les diagrammes


d’interaction
Diagrammes de séquence
Se basent sur l’aspect temporel
Diagrammes de collaboration
Montrent les flots de données

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Diagrammes de séquence
49

Les diagrammes de séquence montrent les


interactions qui surviennent dans une séquence
de temps d’un scénario donné.

Caractéristiques d’un diagramme de séquence:

Dimension verticale qui représente le temps ainsi que la


durée de vie des objets

Dimension horizontale qui représente les différents objets

Les messages échangés entre les objets sont représentés


horizontalement par une ligne fléchée.

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Exercices: Diagrammes de séquence
50

Identifier les objets du scénario Créer-calendrier

Donner le diagramme de séquence du scénario


Créer-calendrier.

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Diagrammes de séquence (suite)
51

Exemple: Scénario Créer-calendrier

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Intérêts des diagrammes de séquence
52

Permettre de mieux comprendre le système

Représenter les différents types d’envoi de


messages (synchrones, asynchrones, time-out, etc.)

D’être utiles dans la description des cas d’erreur


et des cas limites d’utilisation du système

D’être une aide précieuse pour documenter les


méthodes des classes

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Diagrammes de collaboration
53

Les diagrammes de collaboration montrent les


interactions et les liens entre les objets

Diagrammes de collaboration vs Diagrammes de


Séquence

Montrent les liens entre les objets


Les flots de données entre les objets.

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Diagrammes de collaboration
54

Donner le diagramme de collaboration du


scénario Créer-calendrier en indiquant les flots
de données entre certains objets

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Diagrammes de collaboration (suite)
55

Exemple: Scénario créer-calendrier

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Diagrammes de classes

OFPPT/ EL KASSMI

56
Préalable
57

Les diagrammes de classes proviennent principalement de OMT de


Rumbaugh et de OOD de Booch

Une classe est une description d’un ensemble d’objets ayant:

Les mêmes propriétés (attributs)


Les mêmes comportements (opérations)
Les mêmes relations avec d’autres objets

Notation

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Recherche des classes
58

Examiner et regrouper les objets identifiés à partir


des cas d’utilisation et des scénarios

Une classe doit indiquer un et un seul niveau


d’abstraction
Classe Etudiant dans SIA
Mauvaise conception : la classe Etudiant contient les
informations relatives à l’étudiant et aussi le calendrier de
l’étudiant
Bonne conception: deux classes associées: Etudiant
et Calendrier.

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Stéréotype
59

Un stéréotype est un mécanisme qui permet la


classification d’une classe lorsque la sémantique
de base est insuffisante.
 Boundary class
 Entity class
 Controller class
 Exception class
 Surrogate class
 Parameterized class
 Utility class

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Stéréotype (suite)
60

Classe << Boundary >>

Modélise la communication entre le système et son


environnement externe

Classes des différentes interfaces du système avec son


environnement (Acteurs)

Exemple: SIA

Classes: Registration form et Billing form

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Stéréotype (suite)
61

Classe <<Utility>>

Contient un ensemble de méthodes à accès libre

Ces méthodes n’appartiennent à aucune classe

En général, ces méthodes offrent un ensemble de


fonctionnalités utiles dans plusieurs contextes:

Fonctions mathématiques,
Algorithmes de tri
Algorithmes de recherche,
Etc.

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Relations entre classes
62

Trois types de relations:

 Association
 Agrégation
 Généralisation

Les liens entre les objets dans les scénarios sont


des instances des relations reliant les classes

Un lien entre deux objets implique une relation


entre les classes des deux objets

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Association
63

Une association est une abstraction des liens qui


existent entre les objets instances des classes
associées

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Nom, Rôles, Multiplicité d’une association
64

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Associations multiples
65

Deux classes peuvent être liées par plusieurs


associations indépendantes

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Contraintes sur une association
66

Une contrainte est une condition sur une


association qui doit être préservée. Elle est
placée entre accolades.

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Clé d’une association
67

Une clé permet la sélection d’un sous


ensemble d’objets parmi l’ensemble d’objets
qui participent à une association

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Association réflexive
68

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Association représentée par une classe
69

Une association peut être représentée par


une classe

Besoin : on veut pour chaque étudiant


mentionner la note obtenue dans un cours

Problème : Où on va placer l’attribut “Note”?

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Association représentée par une classe (suite)
70

Solution : Créer une classe pour représenter


l’association

Une seule classe par association

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Agrégation
71

Une agrégation est une forme particulière


d’une association dans laquelle une classe
joue un rôle prédominant que l’autre

Une agrégation exprime souvent la relation


« composant-composé »

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Indicateurs d’une Agrégation
72

Si l’expression « est un composant » est


utilisée pour décrire la relation
La porte est un composant de la voiture
S’il existe des opérations, s’appliquant sur le
tout, s’appliquent aussi sur les composants
La voiture se déplace, la porte se déplace
S’il existe des attributs dont les valeurs se
propagent à ceux des composants
La voiture est bleue, la porte est bleue
Si la relation est asymétrique
La porte est un composant de la voiture, la voiture n’est
pas un composant de la porte

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Agrégation
73

Les parties (les composants) sont séparables de L’agrégat (le tout)

La suppression d’une équipe n’implique pas la suppression des personnes qui


la composent

T itre

0..1

1..1

Destinataire E-Mail Fichier


1..* 0..*
* 0..*

Ici, on exprime qu'un fichier peut être attaché à un email (ou a


1..1 plusieurs, ou même à aucun) et qu'un email peut (ou non)
attacher (contenir une copie) une ou plusieurs fichiers.

0..1

T exte

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Composition
74

La composition est un cas particulier d’une agrégation dans laquelle la


vie des composants (élément) est liée à celle de l’agrégat (composé) : si
l’agrégat est détruit (ou déplacé), ses composants le sont aussi.

D’un autre côté, et contrairement à l’agrégation, une instance de


composant ne peut être liée qu’a un seul agrégat.

La composition se représente par un losange noir (plein).

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Composition
75

Un document est composé de plusieurs paragraphes, qui, à son tour, est


composé de plusieurs phrases

Remarquer la propagation des opérations (copie, suppression,…)

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Agrégation réflexive
76

Une agrégation peut être réflexive

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Association vs Agrégation
77

Si les objets des deux classes sont considérés


indépendants => Association

Si les objets des deux classes sont


inséparables => agrégation

L’agrégation entraîne un couplage très fort


entre les objets => effets sur la maintenabilité
de l’application

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Navigation d’une Association et d’une Agrégation
78

Dans l’étape d’analyse, une association et une


agrégation sont supposées être bi-directionnelle

Dans l’étape de conception, l’association et


l‘agrégation peuvent être uni-directionnelle

Indicateurs de navigation

Etant un objet de la classe A, est-il nécessaire de


connaître les objets associés de la classe B?

Etant un objet de la classe B, est-il nécessaire de


connaître les objets associés de la classe A?

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Navigation d’une Association et d’une Agrégation (suite)
79

Exemple

Si dans l’application, je m’intéresse à chercher tous


les fournisseurs d’un produit particulier

Si dans l’application, je m’intéresse à chercher tous


les produit d’un fournisseur particulier

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Navigation d’une Association et d’une Agrégation (suite)
80

Une agrégation ne peut être naviguée que dans le


sens de la classe composante

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Généralisation et Spécialisation
81

La généralisation permet la création de super-classes


regroupant les propriétés et les comportements
communs aux sous-classes (factorisation).

La spécialisation permet la création de sous-classes


afin d’ajouter ou modifier certaines propriétés ou
comportements définis dans les super-classes

Elles permettent donc la création d’arborescences de


classes d’abstraction croissante

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Généralisation et Spécialisation (suite)
82

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Généralisation et Spécialisation (suite)
83

Factorisation des relations

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Généralisation et Spécialisation (suite)
84

Propriétés de la généralisation: non-réflexive, non-


symétrique et transitive

Généralisation vs Composition

Généralisation = est un: un Windows-avec-


scrolbar est un Windows

Composition = a un: un Windows-avec-scrolbar a un


scrolbar
2013 - 2014 OFPPT/ EL KASSMI
2013 - 2014 OFPPT/ EL KASSMI
Généralisation Multiple
85

A utiliser seulement quand c’est nécessaire et avec


précautions!!

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Héritage
86

L’héritage est propre aux langages orientés objet

C’est la technique la plus utilisée pour réaliser la


Généralisation

Consommateur en temps de calcul

Problème des Langages ne supportant pas


l’héritage?

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Héritage
87

L’héritage est propre aux langages orientés objet

C’est la technique la plus utilisée pour réaliser la


Généralisation

Consommateur en temps de calcul

Problème des Langages ne supportant pas


l’héritage?

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Diagrammes d’états-transitions

OFPPT/ EL KASSMI

88
Définition
89

Les diagrammes d’états-transitions sont utilisés pour décrire

les états qu’un objet d’une classe peut prendre au cours de


sa vie

Les événements causant les transitions entre les états


possibles d’un objet

Les actions déclenchées suite à un changement d’états

L’ensemble des états possibles des objets d’une classe constitue l’espace
d’états de cette classe.

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Notation
90

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Etats et Attributs
91

Les états d’un objet d’une classe peuvent être distingués par les valeurs de
certains attributs de l’objet

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Etats et Liens
92

Les états d’un objet d’une classe peuvent être distingués par l’existence de
certains liens avec d’autres objets

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Événements
93

Un événement est une occurrence d’une situation


particulière dans le domaine du problème

L’état en cours de l’objet détermine la réaction de


l’objet
Exemples

Ajouter-étudiants dans un cours

Ajouter-cours dans le catalogue

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Transitions
94

Une transition est le changement d’états d’un objet


suite à un événement

Le nouveau état peut être le même que le précédent

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Actions
95

Une action est une opération exécutée lorsque la


transition est déclenchée:

Atomique: non-interruptible

Rapide: temps d’exécution très court

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Activités
96

Une activité est une opération qui prend un temps


non négligeable et qui est exécutée pendant que
l’objet est dans un état donné:

Une activité est associée à un état plutôt qu’à une transition

Une activité peut être interrompue par une transition

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Transition automatique
97

Le but d’un état est d’exécuter une activité

Activité achevée => Transition

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Actions Entry et Exit
98

Une action du type Entry (resp. Exit) est exécutée


de manière instantanée dès l’entré (resp. sortie)
dans l’état

Ces actions sont indépendantes des transitions


ayant générées l’état

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Imbrications des états
99

L’objectif est de simplifier un diagramme d’états


quand le nombre de connexions devient très élevé

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Imbrications des états avec un historique
10
0

Le mécanisme d’historique permet de mémoriser le


dernier sous-état visité et le rejoindre lors d’une
transition entrant dans le super-état qui l’englobe

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI
Exemple
101

2013 - 2014 OFPPT/ EL KASSMI


2013 - 2014 OFPPT/ EL KASSMI