Point de vue cas d’utilisation :

• Vue de système par ses utilisateurs finaux.

• Regroupe le comportement du system selon :
o Priorité : critique, important, accessoire
o Risque à circonscrire
o Options disponibles
o Couverture de l’architecture
o Autres objectifs tactiques et contraintes

Point de vue logique :

Décomposition orienté-objet :

• Décomposition en objet et classes

• Regroupement en paquetages
• Connexion par héritage, association … etc
• Accent sur l’abstraction, l’encapsulation, l’uniformité.
• Réalisation des scénarios des cas d’utilisation

Point de vue de processus

• Décomposition en tache et en processus
• Regroupement des groupes de processus
• Communication
• Informations sur les caractéristiques suivantes :
o Disponibilité fiabilité
o Intégrité, performance
o Contrôle

Point de vue implantation

• Décomposition en modules et niveaux
• Regroupement de modules en paquetages
• Organisation des sous-systèmes en niveaux pour :
o Réduire le couplage et la visibilité
 o Augmenter la robustesse
• Informations sur les caractéristiques suivantes :
o Facilité de développement.
o Potentiel de réutilisation.
o Gestion de configuration.

Point de vue déploiement

• Décomposition en nœuds d’exécution
• Rôle d’un nœud
• Inter-connectivité, topologie
• Information sur les caractéristiques suivantes :
o Performance, disponibilité
o Installation, maintenance
Les trois composantes d’une modélisation
Modèle fonctionnel
Aspect dynamique : diagramme
d’interaction (séquences, Que fais le système
collaboration) d’états-transitions Aspect fonctionnel : diagrammes des cas
et d’activité d’utilisation

Séquence des actions dans le

système
Modèle structurel (objet)

Sur quoi le système agit

Modèle temporel
Aspect statique : diagramme de
classes et d’objets

Phase de la modélisation
Cahier des
charges

Expression des besoins S’accorder sur ce qui doit être fait dans le système

Analyse Comprendre les besoins et les décrire dans le système

Conception S’accorder sur la manière dont le système doit être construit

Implémentation Codage du résultat de la conception

Teste Le système est-il conforme au cahier des charges ?

Code
exécutable
 Les différentes étapes :
✓ Expression des besoins
✓ Spécification
✓ Analyse
✓ Conception
✓ Implémentation
✓ Testes de vérification
✓ Validation
✓ Maintenance et évolution

Rôle de l’expression des besoins

• Permettre une meilleure compréhension du système
• Comprendre et structurer les besoins du client
o Clarifier, filtrer et organiser les besoins, ne pas chercher
l’exhaustivité
• Une fois identifiés et structurés, ces besoins :
o Définissent le contour du système à modéliser (ils précisent le but
à éteindre),
o Permettent d’identifier les fonctionnalités principales (critiques)
du système.

Expression des besoins

✓ Comprendre le contexte du système en définissant un modèle du
domaine et de métier ;
✓ Recenser les besoins fonctionnels et les définir par des cas d’utilisations.
✓ Noter les contraintes,, exigences non fonctionnelles.

Le modèle du domaine regroupe les objets qui se situent dans le contexte

du système :

- Entités existantes ou événements qui s’y produisent.

 Exigences non fonctionnelles
✓ Contraintes e concurrence
✓ Contraintes de temps de réponse
✓ Contraintes de distribution
✓ Contraintes de performance
✓ Contraintes de répartition

Dépendances entre les phases de modélisation

Modèle cas
d’utilisation
Vérifié par

Modèle cas de
Spécifié par teste
Implémenté par

Modèle
Réalisé par
d’analyse

Modèle
d’implémentation

Modèle de
conception

✓ Spécification :
- Ce que le système doit être et comment il peut être utilisé.
✓ Analyse :
- L’objectif de déterminer les éléments intervenant dans le
système a construire, ainsi que leur structure et leurs
relations.
• Elle doit décrire chaque objet selon 3 axes :
o Axe fonctionnel : savoir-faire de l’objet.
o Axe statique : structure de l’objet.
 o Axe dynamique : cycle de vie de l’objet au cour de l’application
(états et messages de l’objet).

Ces descriptions ne tiennent pas compte de contraintes techniques

(Informatique).

L’analyse
➢ Le but de l’analyse est de traduire dans un langage proche de celui des
informaticiens les modèles dans l’expression des besoins.
➢ Cependant pour rester compréhensible par les clients ou utilisateurs, il
n’intervient que des entités de domaine (métier) considéré.
➢ Elle sert d’interface, avec l’expression des besoins, aux dialogues et aux
contrats avec les clients et les utilisateurs.
➢ L’analyse doit servir de support pour la conception, l’implémentation et
la maintenance.

La notation graphique
BUT :

➢ Modéliser les objets, les relations entre objets, les interfaces avec le
système.
➢ Servir de support de communication entre l’analyste, le client et les
utilisateurs.

✓ La conception :
- Elle consiste à apporter des solutions techniques aux descriptions
définies lors de l’analyse : architecture technique ; performances et
optimisation ; stratégie de programmation.
- On y définit les structures et les algorithmes.
- Cette phase sera validée lors des testes.
✓ L’implémentation :
- Ils permettent de réaliser des contrôles pour la qualité technique
du système.
 - Il s’agit de relever les éventuels défauts de conception et de
programmation (revue de code, teste des composants, …)
➢ Il faut instaurer ces tests tout au long du cycle de développement et non
à la fin pour éviter des reprises conséquentes du travail (programmes de
tests robustes ; logiciels de tests).
✓ Validation :
➢ Le développement d’une application doit être lié à un contrat ayant une
forme de cahier de charges, où doivent se trouver tous les besoins de
l’utilisateur. Ce cahier de charges doit être rédigé avec la collaboration
de l’utilisateur et peut être par ailleurs complété par la suite.
➢ Tout au long de ces étapes, il doit y avoir des validations en collaboration
également avec l’utilisateur.
➢ Une autre validation doit aussi être envisagée lors de l’achèvement du
travail de développement, une fois que la qualité technique du système
est démontrée. Elle permettra de garantir la logique et la complétude du
système.
✓ Maintenance et évolution :
➢ Deux sortes de maintenance sont à considérer :
o Une maintenance corrective, qui consiste à traiter
les « buggs ».
o Une maintenance évolutive, qui permet au système d’intégrera
de nouveau besoins ou des changements technologiques.

Cahier des charges : gestion de bibliothèque

• Un gérant de bibliothèque désire automatiser la gestion des prêts.
• Il commande un logiciel permettant aux utilisateurs de connaitre les
livres présents, d’en réserver jusqu’à 2. L’adhérent peut connaitre la liste
des livres qu’il a empruntés ou réservés.
• L’adhérent possède un mot de passe qui lui est donné à son inscription.
• L’emprunte est toujours réalisé par les employés qui travaillent à la
bibliothèque. Après avoir identifié l’emprunteur, ils savent si le prêt est
possible (nombre maximum de prêts est 5), et s’il a la priorité (il est celui
qui a réservé le livre).
 • Ce sont les employés qui mettent en bibliothèque les livres rendus et les
nouveaux livres. Il leur est possible de connaitre l’ensemble des prêts
réalisés dans la bibliothèque.

2) Le diagramme des Use Cases ou des cas

d’utilisation.
Ce que doit faire le système sans spécifier comment
il le fait

But des Use Cases

Les cas d’utilisation représentent les fonctionnalités que le système doit savoir
faire.

Chaque cas d’utilisation peut être complété par un ensemble d’’interactions

successives d’une entité en dehors du système (l’utilisateur) avec le système
lui-même.

Système

Les Uses Cases permettent :

- De connaitre le développement du système sans spécifier comment

ce comportement sera réalisé.
- De définir les limites précises du système
- Au développeur de bien comprendre l’attente des utilisateurs et les
experts du domaine.

De plus les Use Cases sont :

- Des instruments de validation et de test du système en cours en fin

de construction.

Modèle des cas d’utilisations

• Un diagramme de cas d’utilisation définit :

 o Le système
o Les acteurs
o Les cas d’utilisations
o Les liens entre acteurs et cas d’utilisations.
• Un modèle de cas d’utilisation se définit par :
o Des diagrammes de cas d’utilisation
o Une description textuelle des scénarios d’utilisation
o Une description de cas scénario d’utilisation.
o Une description de ces scénarios par :
- Les diagrammes de séquences.
- Les diagrammes de collaboration.

Les acteurs

• Un acteur représente une personne ou un périphérique qui joue le rôle

(interagit) avec le système.
• Relation entre acteurs : généralisation (héritage).
Héritage

Relations entre acteurs

Un bibliothécaire est un abonné

Abonné Bibliothécaire Abonné Un administrateur est un

bibliothécaire

Acteur
Acteur Bibliothécaire Administrateur

Les cas d’utilisation (use-case)

• Un cas d’utilisation est un moyen de représenter les différentes

possibilités d’utiliser un système.
• Il exprime toujours une suite d’interactions entre un acteur et
l’application.
• Il définit une fonctionnalité utilisable par un acteur.

Emprunteur Regarder la liste des

livres

Réserver

Organisation des Use Cases : Include

• La relation « include » qu’un cas d’utilisation comporte le comportement
définit dans un autre cas d’utilisation.
• Cette relation permet de mettre en commun des comportements
communs à plusieurs cas d’utilisation.

Emprunt
Regarder la liste
des livres

Réserver

Organisation des Use Cases : extend

• La relation « extend » précise qu’un cas d’utilisation peut dans certains
cas augmenter le comportement d’un autre cas d’utilisation.
• Une condition devra valider cette augmentation.
• Le point d’utilisation de cette augmentation peut être défini dans « point
d’extension ».

Réservation
Extension points Regarder la liste
« Extend » des livres
Avant le choix du livre
Avant le choix du livre

• Dans cet exemple, le cas d’utilisation « regarder la liste des livres »

augmente le cas d’utilisation d’une réservation avant le choix du livre
Organisation des Use Cases : généralisation

• Cette relation « est un » introduit la notion d’héritage.

• Les cas d’utilisation « Vérification par mot de passe » et « vérification
par carte » sont des spécialisations du cas d’utilisation « Identification
abonné ».
• Autrement dit : si l’on dit que l’on fait une « identification abonné », ce
peut être une vérification par carte » ou une « vérification par mot de
passe ».

Héritage Vérification par

mot de passe

Identification
abonné
Vérification par
carte

Modalisation d’un système : Obtenir les cas

d’utilisation
• Identifier les acteurs qui utilisent, qui gèrent, qui exécutent des fonctions
spécifiques.
• Organiser les acteurs par relation d’héritage.
• Pour chaque acteur rechercher les cas d’utilisation avec le système.
• Ne pas oublier les variantes d’interaction (cas d’erreur, cas d’interdits).
• Organiser ces interactions par héritage, par utilisation et par extension.

Les diagrammes de cas d’utilisation

Le système définit l’application informatique, il ne contient pas donc les acteurs
mais les cas d’utilisations et leurs associations.
 Réserver un livre

Connaitre les livres

empruntés

Connaitre les livres

présents

Ajouter de nouveaux
livres

Remettre un livre

Réaliser un emprunt

Les diagrammes de cas d’utilisation

Bibliothèque

Réserver un livre

Client Cas d’utilisation

Connaitre les livres
empruntés

Acteurs Connaitre les livres

présents

Ajouter de nouveaux
livres
Employé
Remettre un livre

Réaliser un emprunt
 Les diagrammes de cas d’utilisation

Connaitre les livres

empruntés
Identification
Réserver un livre
Client
Extension point avant la réservation

Identification
par carte
Connaitre les livres
présents

Identification par
mot de passe

Employé Ajouter de nouveaux

livres

Remettre un livre

Réaliser un emprunt

Scénario d’un cas d’utilisation

• La description d’un cas d’utilisation se fait par des scénarios qui
définissent la suite logique des interactions qui constituent ce cas.
• On peut définir des scénarios simples ou des scénarios plus détaillés
faisant intervenir les variantes, les cas d’erreurs, etc.
• Cette description se fait manière simple, par un texte compréhensible
par les personnes du domaine de l’application.
• Elle précise ce que fait l’acteur et ce que fait le système.
• La description détaillée pourra préciser les contraintes de l’acteur et celle
du système.
 Scénario d’un cas d’utilisation
Réservation Description simplifiée
d’un livre

Le client se présente devant un terminal :

• (1) Le système qui affiche un message d’accueil.

• (2) Le client choisit l’opération parmi les différentes opérations
proposées.
• (3) Le système lui demande de s’identifier.
• (4) Le client donne son identification (nom, mot de passe).
• (5) Le système lui demande de choisir un livre.
• (6) Le client précise le livre qu’il désire.
• (7) Le système lui précise si un exemple du livre lui est réservé.

Scénarios d’un cas d’utilisation

Réservation Description détaillée
d’un livre

• Pré-conditions : Le client doit être inscrit à la bibliothèque

Le client ne doit pas avoir atteint le nombre
maximum de réservations.
Un exemplaire du livre doit être enregistré.

• Post-conditions : (Si l’opération s’est bien déroulée)

Le client a une réservation supplémentaire
Le nombre d’exemplaires disponibles du livre est
décrémenté de 1.

Scénarios d’un cas d’utilisation

Réservation
d’un livre Description détaillée
Cas normal
1. Le système affiche un message d’accueil sur le terminal avec un choix
d’opération.
2. Le client choisit l’opération « réservation » parmi les les différentes
opérations proposées.
3. Le système lui demande de s’identifier.
4. Le client donne son identification (nom, mot de passe).
5. Le système demande le titre du livre en donnant la possibilité de choisir
dans une liste.
6. Le client précise le livre qu’il désir.
7. Le système lui précise qu’un exemplaire du livre lui est réservé.

Scénario d’un cas d’utilisation

Variante 1 En (6) le client demande à connaitre les livres présents.

Variante 2 En (4) le client n’est pas reconnu, dans ce cas, tant qu’il n’est
pas reconnu, n lui redemande de s’authentifier.

Variante 3 En (4) le client est reconnu mais le mot de passe est incorrect, il
peut avoir 5 essais, par suite le client sera interdit pendant 1 h.

Variante 4 En (4) le client n’a plus le droit de réserver..

Variante 5 En (7) le livre n’est pas libre.

Scénario par diagramme e séquences

• Suite aux descriptions textuelles, le scénario peut être représenté en
utilisant un diagramme de séquences.
Le diagramme de séquences permet :
- De visualiser l’aspect temporel des interactions.
 - De connaitre le sens des interactions (acteur vers system ou
l’inverse).

Scénario par diagramme de séquences

Afficher les messages d’accueil

Choix de l’opération : réservation

Demande d’identification du client Temps

Réserver Identification du client
un livre
Demande d’identification du livre

Identification du livre

Message : « le livre est réservé »

Variation du scénario

Système de prêts
Client

Afficher message d’accueil

Choix de l’opération : réserver un livre

Demande d’identification du client

Réserver Identification du client
un livre

Refus : trop de livres réservées

 Cas d’utilisation : Distributeur de billets
Distributeur de billets
Cas d’utilisation
Effectuer un virement

Retirer l’argent
Acteur client
Banque
Consulter un compte
Acteurs gestionnaires
Gérer le distributeur

Effectuer la
maintenance

Diagramme de séquences Use Case Retirer de

l’argent

Afficher message d’accueil

Distributeur de
Insérer la carte billets

Demander le mot de passe

Entrer le mot de passe

Demander type de l’opération

Entrer demande retrait

Retirer
l’argent Demande somme

Entrer somme

Distribue l’argent

Demande prendre les billets

 Prendre les billets

Imprimer les reçus

Ejecter la carte

Demande de prendre la carte

Prendre la carte

Afficher message d’accueil

Exemple 2 :

Créer compte Déposer l’argent

Client
Acteur client Consulter
compte Retirer de
l’argent du
distributeur Cas d’utilisation

Gérer les
Retirer
comptes
l’argent

Use Case : « Retrait en espèce » :

1. Le guichetier saisit le n° de compte du client.
2. L’application valide le compte au près du système central.
3. L’application demande le type d’opération au guichetier.
4. Le guichetier sélectionne un retrait d’espèces de 2000 Dh.
5. Le système « guichetier » interroge le système central pour s’assurer que
le compte est suffisamment approvisionné.
6. Le système central effectue le débit du compte.
7. Le système notifie au guichetier qu’il peut délivrer le montant demandé.
Description à l’aide de diagramme de séquences

Saisie compte

Demande type d’opération

Validation compte

Retrait liquide (2000 DH)

Vérification solde compte

Débit compte

Autorisation délivrance

Guichetier Système guichet Système central

Descriptions

/.

Cahier des charges

Pour faciliter sa gestion, un entrepôt de stockage envisage de s’informatiser. Le
logiciel a produit doit allouer de façon automatique un emplacement pour le
chargement des camions qui convoient le stock à entreposer. Le
fonctionnement du système informatique doit être le suivant :

• Déchargement d’un camion : lors de l’arrivée d’un camion, un employé

doit saisir dans le système les caractéristiques de chaque article ; le
système produit alors une liste où figure un emplacement pour chaque
article.
 • Chargement d’un camion : les caractéristiques des articles à charger dans
un camion sont saisies par un employé afin d’indiquer au système de
libérer des emplacements.
Le chargement et déchargement sont réalisés manuellement.
Les employés de l’entrepôt sont sous la responsabilité d’un chef dont le
rôle est de superviser la bonne application des consignes.

Recensement des acteurs

L’étude du cahier des charges ainsi qu’un dialogue avec les employés et leur
chef a abouti à retenir 3 acteurs :

• Un employé dont le rôle est de saisir les caractéristiques des articles lors
du chargement/déchargement
• Un superviseur dont le rôle est de pouvoir contrôler l’état du stock.
• Un administrateur du système dont le rôle est de gérer des comptes
utilisateurs pour les employés et le superviseur.

(La séance de vendredi 6 Novembre)

Attributs et opérations de classe :

Personne Le nombre de livres empruntés n’est pas une caractéristique
d’Alain Dupont (objet).
- Nom
- Age C’est caractéristique valable pour l’ensemble des personnes
- Adresse (la class).
- Mot de passe
Une_personne : Personne
- Nbr eLivreEmpruntés
- NbreLivrsEmpuntable = 5
- Nom
- Age : 45
- Changer adresse()
- Adresse = France
- ObtenirAge()
- Mot de passe = LFT62
- obtenirAdresse()
- nmbLivresEmpruntés = 4
- verifierMotDePass()
- getNbLivresEmpruntable

La méthode getnbrLivresEmpruntables() utilise la valeur nbrLivreEmpruntables connue par la classe.

Cette méthode peut être appliquées directement à la classe Personne et bien sûr aussi aux objets
instance de cette classe.
 Attributs et opérations de classe : Notation UML
CLASSE :
Personne + : attribut public

- Nom # : attribut protected

- Age - : attribut private
- Adresse
- Mot de passe _ : attribut de classe
- NombrePersonne

- # changerAdresse() + : opération public

- # obtenirRue() # : opération protected
- + obtenirAge()
- + obtenirNombrePersonne() - : opération private

_ : opération de classe

La réification
La réification consiste à transformer ou à transposer une abstraction en un
objet concret. En informatique elle consiste à transformer un concept en un
objet informatique.

Chien Mariage

- Race - Epoux
- Age - Epouse
- Couleur - Date
Entité physique Evénement
- Aboyer() - seMarier()
- Mordre() - divorcer()
- Obéir()

Appartenir Cours

- Propriétaire - Professeur
- Date - Salle
- Voiture Situation - Elève
Relation
- Vendre() - Assister()
- Acheter() - Quitter()
- Prêter()
 Surcharge et polymorphisme
Personne Fichier

- Nom : String - Nom : String

- Age : Integer - Age : Integer
- Adresse : String - Propriétaire : String

- changerAdresse(nvlAdrs : String) Imprimer()

- obtenirAge() : entier
- obtenirAdress() : String
Imprimer(nbrDeLignes : entier)
Imprimer()

Polymorphisme : Représente la faculté d’une méthode à pouvoir s’appliquer

(différemment) à des objets de classe différentes (ex : méthode : manger()
classes : lion, vache).
Element
Pile
Taille : Integer

- + Pile()
- + Empiler(valeur : élement)
- + Dépiler() : élément
- + nbrElements() : Integer
Return :
- + estVide() : boolean
- + estPleine() : boolean nbrElements() == taille

Pile Pile Pile

<integer,34> <Point,20> <classA,10>

 Association entre classes
les associations représentent les liens unissant les instances de classe.

Nom de l’association Sens de lecture du nom

d’association

Livre Auteur
titre aPourAuteur nom

UnLivre : Livre UnLivre : Livre

Titre = La peste Titre = La peste

Séance de 20/11/09

Agrégation
Titre

Destinataire

E-mail
Texte

Fichier

Polycopié

Composition : agrégation forte

 Agrégation, composition ou association
1. Règles obligatoires pour la composition :
o Est-ce qu’une partie de ?
o Les opérations appliquées aux composants sont elles appliquées
aux composant ?
o Les changements d’état sont-ils liés ?
2. Règles obligatoires pour la composition
o La suppression du composé entraine-t-elle la suppression des
composants.
o Les attributs du composé sont ils utilisés dans les composants ?
o Les composants sont des instances du composé ?
o Un composant ne peut pas être en relation avec d’autres classes
externes au composé.

Héritage : buts et principes 2/3

Ajout d’une classe de base (analyse)
BUT 2

Permettre une fonction

PRINCIPE

Lorsque plusieurs classes ont des caractéristiques et des comportements

communs la création d’une classe ancêtre permet de regrouper ce qui est
commun.

Cette classe ancêtre peut correspondre à une classe concrète ou à une

classe abstraite

Héritage : généralisation Factorisation des

propriétés
Permanent Vacataire

numBureau nombreVacation
spécialité spécialité
nombreCours nombreCours
nom nom
 Héritage : généralisation Factorisation des
propriétés

Enseignant

nombreCours
spécialité
nom
numeroSécu

Permanent Vacataire

numBureau nombreVacation

Héritage : généralisation Factorisation des

propriétés

Avocat Vendeur Enseignant

nombreAffaires ancienneté nombreCours
adressCabinet nomDuStand spécialité
nom nom nom
numeroSécu numeroSécu numeroSécu

Permanent Vacataire

numBureau nombreVacation
 Héritage : généralisation Factorisation des propriétés

Personne

nom
numeroSécu

Disjoint, incomplète

Avocat Vendeur Enseignant

nombreAffaires ancienneté nombreCours
adressCabinet nomDuStand spécialité
nom nom nom
numeroSécu numeroSécu numeroSécu

Disjoint, incomplète

Permanent Vacataire

numBureau nombreVacation

Classe abstraite
• Un média peut être transporté, dupliqué, affiché.
• Le transport et la duplication sont indépendants du type du media (copie
lde fichier).
• Par contre, tout media peut être affiché et ce n’est pas la même chose
pour l’audio la vidéo le graphisme le texte.
• Un média ne peut pas définir commeent s’afficher tant qu’il ne sait pas
ce qu’il est.
• Il n’y pas d’instance classe media
• Un media n’existe qu’en tant
Notation UML : nom de Media
classe italique ou stériotype
Auteur
<<abstract>>
titre
datecréation

Transporter()
dupliquer()
afficher()

Héritage : buts et principes 3/3 Polymorphisme

BUT 3

Créer des sous-types (sous-classes). Une sous classe sera du même type de ma
classe dont elle hérite (super-classe).

Ceci permet de mettre en œuvre le polymorphisme et la liaison dynamique

PRINCIPE

Un objet d’une classe donnée pourra toujours faire référence à des objet de ses
sous-classes (polymorphisme).

Une opération exécutée par un objet sera celle que connait l’objet dont il fait
référence (liaison dynamique).

Les interfaces :
Une interface permet de décrire le comportement d’une unité (classe,
paquetage ou composant), c'est-à-dire un savoir faire sous la forme d’une liste
d’opérations.

• Une interface ne peut donner lieu à aucune implémentation.

• Une interface est équivalente à une classe abstraite sans attributs où
toutes les méthodes sont abstraites.
• Une classe peut déclarer qu’elle implémente une interface. Elle doit alors
implémenter toutes les opérations de cette interface. Elle peut ensuite
être utilisée partout où ce comportement est exigé.
 <<interface>>
Interface : Déplaçable
Opération, saPlace()
méthôde, avancer()
service reculer()
sans corp monter()
descendre()

Une interface n’est pas une classe c’est Elle ne peut pas servir à créer un objet
une liste de services.

Une interface exprime un savoir faire

TYPE = CLASSE + INTERFACE

Les Paquetages
• Une application est constituée de plusieurs classes, des dizaines ou des
centaines. Il n’est important de les organiser en groupes (en fonction de
certains critères surtout logique).
• C’est le paquetage (package) qui permet ce regroupement.
• Un paquetage regroupe des classes des interfaces et des paquetages.
• Il permet d’encapsuler certains éléments de la modélisation un élément
du paquetage peut être inaccessible de l’extérieur de paquetage, il n’est
alors connu que par les éléments du même paquetage.
• Il met en œuvre un espace de nommage.

Diagramme e classes de la gestion de la

bibliothèque recherche à partir du cahier des
charges recherche par responsabilité.
Phases de modélisation objet :
• Identifier les clases candidates.
• Préparer le dictionnaire de données : classes retenues.
 • Identifier les associations entre casses (en incluant les agrégations)
• Identifier les attributs.
• Organiser et simplifier les classes en utilisant l’héritage.
• Supprimer les associations inutiles.
• Vérifier que le diagramme inclut toutes les demandes de cahier des
charges.
• Itérer et affiner les classes en modules (paquetages).

Identifier les classes : classes candidates

• Un gérant e bibliothèque désire automatiser la gestion des prêts.

• Il commande un logiciel permettant aux utilisateurs de connaitre les
livres présents, d’en réserver jusqu’à 2, l’adhérent peut connaitre la liste
des livres qu’il a empruntés ou réservés.
• L’adhérent possède un mot de passe qui lui est donné à son inscription.
• L’emprunt est toujours réalisé par le

Gérant bibliothèque gestion prêts logiciel utilisateur

Livres . . .

Les classes retenues :

• Gérant n non pertinents, n’intervient pas

• Bibliothèque oui responsabilité : gérer les livres adhérents, prêts
• Gestion non vague
• Prêts oui responsabilité : contenir les infos et action sur les
prêts
• Logiciel non vague.
• Utilisateur (choix entre utilisateur, adhérent ou emprunteur)
• Livres oui responsabilité : permettre e connaitre de état.
• Adhérent oui responsabilité : permettre à la personne d’étre
identifié
• Liste non implémentation ou conception.
• Mot de passe non attribut
• Inscription non action
• Emprunt non action
 • Employé oui responsabilité :

Dictionnaire des données :

• organisme gérant une collection de livres qui peuvent être empruntés

par ses adhérents. Une bibliothèque est gérée par ses employés.
• Prêt :

Chercher les associations :

Un gérant de bibliothèque désire automatiser la gestion des prêts.

• Il commande un logiciel permettant aux utilisateurs de connaitre les

livres présents d’en réserver jusqu’à 2. L’adhérent peut connaitre la liste
des livres qu’il a empruntés ou réservés.
• L’adhérent possède un mot de passe qui lui est donné à son inscription.
• L’emprunt est toujours réalisé par les employés qui travaillent à la
bibliothèque. Après avoir identifié l’emprunteur, ils savent si le prêt est
possible (nombre max de prêts = 5), et s’il a la priorité

Associations sous- entendues :

• Un adhérent est inscrit à la bibliothèque.

• La bibliothèque contient des livres.

les associations :
Bibliothèque

Bibliothécair Livre Adhérent

e

Prêt
Diagramme d’objet :

- Les valeurs des attributs sont optionnelles ainsi que les liens entre
objet

Exercice :

Préparer un diagramme d’objet montrant au moins 10 relations parmi les

classes d’objets suivantes. Inclure les associations les agrégations et les
généralisations.

Placer les ordres de multiplicité.

A- Ecole, Terrain de jeu, Proviseur, Conseil de classe, Salle de classe, Livre,

Elève, Professeur, Cafétéria, Ordinateur, Bureau, Chaise, Porte.