I- Démarche méthodologique de

construction d’une application

par l’approche objet
1) Les différentes étapes: (Boussaid)
 Expression des besoins
 Spécification
 Analyse
 Conception
 Implémentation
 Tests de vérification
 Validation
 Maintenance
√ Expression des besoins:
…
√ Spécification:
Ce que le système doit être et comment il peut être utilisé.
√ Analyse:
L’objectif est de déterminer les éléments intervenant dans le
système à construire, ainsi que leur structure et leurs relations.

Elle doit décrire chaque objet selon 3 axes:

• Axe fonctionnel: savoir faire de l’objet;
• Axe statique: structure de l’objet;
• Axe dynamique : cycle de vie de l’objet au cours de l’application
(Etats et messages de l’objet).
Ces descriptions ne tiennent pas compte de contraintes techniques
(informatiques)
√ La conception:
Elle consiste à apporter des solutions
techniques aux descriptions définies lors de
l’analyse: architecture technique, performances
et optimisation; et stratégie de programmation.
On y définit les structures et les algorithmes.

√ L’implémentation:
C’est la réalisation de la programmation
√ Les tests de vérification:
Ils permettent de réaliser des contrôles pour la qualité technique du système.
Il s’agit de relever les éventuels défauts de conception et de programmation
(revue de code, tests des composants,…)
Il faut instaurer ces tests tout au long du cycle de développement et non à la fin
pour éviter des reprises conséquentes du travail .
√ 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 et peut ê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:

Une maintenance corrective, qui consiste à

traiter les « buggs ».

Une maintenance évolutive, qui permet au

système d’intégrer de nouveaux besoins ou des
changements technologiques.
2) L’U.M.L
• Modeling
En pratique l’analyse est toujours orientée par
des contraintes de faisabilité qui relèvent de la
conception choix du terme de modélisation
(modeling)
• Language
UML n’est pas une méthode , mais un langage.
==> Une notation.
Unification
UML 1.1 ->1.2->1.3-
>1.4->1.5->2.0

Soumission à l’OMG 1/97 UML 1.0

UML 0.9

Unified Method 0.8

… Booch’93 OMT-2 OOSE

Booch OMT
3) Les points de vue de la modélisation par UML

UML permet la modélisation du monde réel selon trois points de vue

de modélisation: fonctionnel, statique et dynamique.

Fonctionnel
Diagramme des cas
d’utilisation
Diagramme des
séquences
Diagramme de
Collaboration

Statique Dynamique
Diagrammes des classes Diagramme Etat transition
Diagramme d’objets Diagramme d’activités
Diagramme de composants Diagramme de depoiement
 II- Le modèle fonctionnel

Il englobe:

Le diagramme des cas d’utilisation

Le diagramme de séquences
Le diagramme de collaboration
1)Le diagramme des cas d’utilisation
= Les USE CASES
Idée:
Les USE cases (cas d’utilisation) sont un concept de la
méthode OOSE de Ivar Jacobson.
 Ils permettent d’effectuer une délimitation du système et
de décrire son comportement.
 Ils constituent une représentation orientée «
fonctionnalités » du système.

Dans la modélisation par les use cases: 2 concepts

fondamentaux interviennent:

 Les acteurs: utilisateurs du système.

 Les uses cases: utilisation du système
 Les acteurs
Ce sont les utilisateurs du système

Ils ont une bonne connaissance des fonctionnalités du

système. Ils constituent les éléments extérieurs du
système.
Ils peuvent être:
Soit des humains;
Soit des logiciels;
Soit des systémes.
On distingue :
• Les acteurs primaires: ce sont les utilisateurs du
système;
• Les acteurs secondaires: qui administrent le système.
 Les uses cases
Les utilisateurs du système:
Il s’agit de déterminer les éléments constitutifs d’un point de vue fonctionnel.
On pourra trouver des uses cases pour décrire:
• Chaque tâche de l’utilisateur;
• Les fonctionnalités mal décrites lors des spécifications;
• Les E/S des données;
• Les cas d’anomalie.

Représentation des acteurs dans un modèle Use Cases:

 ? 
 
Exemple de Use case
 Description d’un Use Case
Il existe plusieurs façons de décrire un use case.
Description textuelle (informelle):
Exemple:
Use case: « Retrait en espèce »:
• Le guichetier saisit le n° de compte du client;
• L’application valide le compte auprès du système central;
• L’application demande le type d’opération au guichetier;
• Le guichetier sélectionne un retrait d’espèces de 1000DH;
• Le système « guichetier » interroge le système central pour
s’assurer que le compte est suffisamment approvisionné;
• Le système central effectue le débit du compte;
• Le système notifie au guichetier qu’il peut délivrer le montant
demandé.
 2)Les diagrammes de séquences et de collaboration

 Exemple de diagramme de sequences

Saisie compte
Validation compte
Demande type d’opération
Retrait liquide (1000dh)
Vérification solde compte

Autorisation délivrance Débit compte

t Guichetier Système guichet Système central

 Exemple de diagramme de collaboration

(6) Débit compte
(4) Retrait espèces
Guichetier (1000dh) Système Central

(3) Demande type (7) Autorisation (5) vérification solde

d’opération délivrance compte

(2) Validation compte

(1) Saisie compte Système guichetier
 Diagramme des Use Case
Guichetier Application bancaire (système) Responsable
Devises

 Retrait Dirhams
Saisie cours

devises
Retrait devises

Directeur Emprunt
Système central

 Bilan

L’intégration dans l’Use Case « Application bancaire » des use
cases de chaque opération permet d’avoir une vision globale du
système. Elle permet également de comprendre le rôle de chaque
acteur.
 3)Relation « extends »
La relation « extends »
Un ou plusieurs use cases peuvent hériter des caractéristiques d’un
autre use case.
Application bancaire (système)
Système central
Guichetier Retrait dirhams « Extends »

 Retrait 
Retrait devises « Extends »

Les Uses Cases fils ont les mêmes liens avec les acteurs et les
autres use cases que le use case dont ils héritent.
Ce sont des cas particuliers des Uses Case père.
 4)Relation « uses »
La relation « uses »:include
Soit l’use case « Saisie n° compte »
• Le guichetier saisit le code de la banque du compte.
• Il saisit le numéro du compte.
• Il saisit la clé du compte.
• Le système calcule la clé du compte et vérifie qu’elle est bonne.
• Le système interroge le compte sur le système central.
• Le système affiche le compte ainsi que son détenteur.

Application bancaire (système)

Retrait dirhams Retrait devises Emprunt

« uses »
« uses » « uses »
Saisie n° compte
.
 Relation « uses »
Lorsque une ou plusieurs tâches sont utilisées
régulièrement, on peut les factoriser dans un
même use case et faire de telle sorte que
d’autres use cases l’utilisent en le pointant par
une flèche.

Cet use case est en fait une sous partie de

chaque use case qui l’utilise. Ce qui permet de
décomposer un use case complexe en plusieurs
uses cases.
 Le modèle Objet

 exprime comprend  Analyste

Utilisateur
Cas d’utilisation
Réalise
conçoit


programmeur

Concepteur

Vérifie

Testeur

Les cas d’utilisation servent de fil conducteur

pour l’ensemble du systéme
 Etude de cas 1
Cette étude de cas concerne un système simplifié de Guichet automatique de
Banque (GAB). Le GAB offre les services suivants :
•Distribution d’argent à tout porteur de carte de crédit (carte Visa ou carte de la
banque), via un lecteur de carte et un distributeur de billets ;
•Consultation de solde de compte, dépôt en numéraire et dépôt de chèques pour
les clients de la banque porteurs d’une carte de crédit de la banque ;
N’oubliez pas non plus que :
•Toutes les transactions sont sécurisées ;
•Il est parfois nécessaire de recharger le distributeur.
Travail demandé :
•Identifiez les acteurs ;
•Identifiez les cas d’utilisation ;
•Construire un diagramme de cas d’utilisation ;
•Décrire textuellement les cas d’utilisation ;
•Réalisez un diagramme de séquence système qui décrit le scénario nominal du cas
d’utilisation : Retrait de l’argent avec une carte visa.
 Etude de cas 2
Ce cas concerne un système simplifié de caisse enregistreuse de supermarché. Le déroulement nominal
d'utilisation de la caisse est le suivant :
•Un client arrive à la caisse avec des articles à payer ;
•Le caissier enregistre le numéro d'identification de chaque article, ainsi que la quantité si elle est
supérieure à un ;
•Lorsque tous les achats sont enregistrés, le caissier signale la fin de la vente ;
•La caisse affiche le total des achats ;
•Le client choisit son mode de paiement :
-Liquide : le caissier encaisse l'argent reçu, la caisse indique la monnaie à rendre au client ;
-Chèque : le courtier vérifie la solvabilité du client en transmettant une requête à un centre
d’autorisation via la caisse ;
-Carte crédit : un terminal bancaire fait partie de la caisse. Il transmet une demande d’autorisation en
fonction du type de la carte ;
-La caisse enregistre la vente et imprime un ticket ;
-Le caissier donne le ticket de caisse au client.
Après la saisie des articles, le client peut présenter au caissier des coupons de réduction pour certains
articles. Lorsque le paiement est terminé, la caisse transmet les informations sur le nombre des articles
vendus au système de gestion de stocks. Tous les matins, le responsable du magasin initialise les caisses
pour la journée.
Travail à faire :
•Elaborez un diagramme de cas d'utilisation détaillé de la caisse enregistreuse ;
•Ecrivez une description de cas d’utilisation principal : traiter le passage du client en caisse ;
•Réaliser un diagramme de séquence système qui décrit le scénario nominal du cas d'utilisation
essentiel: traiter le passage du client en caisse; en ne considérant que le paiement en cash.
III: Le modèle statique
 1)Les différents concepts
Concept de Classe et d’Objet

Les objets du modèle statique sont une représentation (modélisation)

des objets (monde réel), qui seront en général ceux qu’on retrouve
lors de l’implémentation sous la même forme ou sous une forme
différente.
Ils sont munis de données encapsulées dans les objets, représentant
leurs attributs et leurs opérations (méthodes).
Lecteur 0.1 Emprunter 0.3 Exemplaire d’Ouvrage
Emprunteur Objet prêté

Exemple de classes

Chaque objet d’une classe a une identité propre et n’a donc pas
besoin d’un identificateur, sauf si celui-ci est un identificateur métier
préexistant comme un n° Ouvrage.
 Multiplicité des rôles
Personne Compagnie
Travaille pour

Personne Compagnie
employé employeur

Personne Compagnie

1..* *
1 Un et un seul
O..1 Zéro ou un
M..N De M à N (entiers naturels)
* Un nombre quelconque
0..* Un nombre quelconque
1..* Un ou plusieurs
 Les différents concepts
Le nombre d’attributs et de méthodes qu’on définira
dépend du niveau de détail qu’on veut obtenir.
Exemple:
Lecteur 0.1 Emprunter 0.3 Exemplaire d’Ouvrage
Emprunteur Objet prêté

Ibrahim: Lecteur 0.1 Emprunter 0.3

« Les B.D.R » Ouvrage
Nom: « Ibrahim »
Prénom: « Abdellah »
Adresse: « Inconnue »

Exemple de classes et d’objet

 Association et classe d’associations
Entre les 2 classes Lecteur et exemplaire d’ouvrage, il
existe un lien qui représente un emprunt d’ouvrages par un
lecteur. Il est matérialisé par un lien entre les 2 classes et il
peut être caractérisé par:
• Un nom
• Deux noms de rôle facultatifs
• Un sens de lecture
• Deux cardinalités.
Une cardinalité peut être représentée par un nombre, une
« * » ou un intervalle.
Une association peut nécessiter des données et aussi des
opérations: il est alors tout indiqué de lui construire une
classe.
 Lecteur 0.1 Emprunter 0.3
Exemplaire d’Ouvrage
Nom
Prénom Prêt
Adresse
Durée
Date

Prolonger

Classe d’association

On peut choisir parfois entre rajouter une donnée dans une classe
ou créer une classe propre.
D’autre part, il est possible de mettre la donnée dans une structure
classique mais ceci peut s’avérer lourd à gérer et ne peut d’autre
part assurer la persistance de la donnée.
 2)Diagramme des Classes
Le modèle objet sera représenté par un diagramme de classes où chacune
sera décrite avec ses attributs et ses méthodes :

Nom de la classe
attribut : type
opération (liste d’arguments):
Résultat renvoyé

•La détermination des classes lors de la phase d’analyse n’est pas évidente.
Elle suit une méthode plutôt intuitive. Basée sur l’expérience de l’analyste
qui a (ou n’a pas) l’habitude de reconnaître plus ou moins facilement les
classes, les objets, les associations, les attributs et les méthodes de classe.
•L’analyste pourra se demander alors quels sont les objets de gestion dans le
problème étudié et se référer également aux règles de gestion pour identifier les
objets réels ainsi que leur lien et qu’il va falloir modéliser sous formes de
classes et d’associations.
3)Généralisation; Spécialisation
Classe mère

Spécialisation Généralisation

Classe fille

Concepts de Spécialisation et de Généralisation

La modélisation de la notion d’héritage dans un modèle

statique peut se faire par l’intermédiaire de la
généralisation qui permet une organisation des classes
et des regroupements sémantiques de classes.
Généralisation; Spécialisation
Œuvre

durée

Support
Matériel nécessaire

Livre CD Audio Cassette Vidéo

Exemple de classe abstraite

La généralisation permet de simplifier le diagramme

des classes. La spécialisation permet d’établir une
relation de type « est un » ou « est une sorte de ».
 4) Classes abstraites

Il existe des classes qu’on ne peut instancier, car elle

sont trop générales .
Elles servent à mettre en commun des
caractéristiques communes à certaines classes, c’est
le cas de la classe Support : c’est une classe abstraite.
Celle-ci doit toujours être suivie de classes dérivées.
Dans l’exemple précédent les classes dérivées sont
livre, CD Audio et Cassette vidéo.
Elles permettent de représenter des concepts importants
dans une application.
 5)Agrégation
Lorsqu’une’ association entre deux instances d’une classe a en plus
une particularité dont le sens est du style: « une instance est
composée d’une ou plusieurs autres instances », on peut alors
qualifier cette association d’agrégation.
On peut dire également qu’une agrégation est une association de type
« Composé-Composant ». Où, l’instance composé est l’agrégat et
les composants sont les instances agrégées. Lorsque la durée de
vie du composant dépend de la durée de vie du composé
l’agrégation devient une composition
Exemple:

Université Facultés Départements

1
gère
*
Etudiants Agrégation
 6)Association unaire et
agrégation récursive
Une classe peut avoir des instances qui
sont en association entre elles.

Electeur
* Elément

*
1
Etudiant
Délégué Collection Objet simple
1
Représente

Association unaire Agrégation récursive

(réflexive)
 7)Qualificateurs
Le rôle d’un qualificateur est de réduire la
cardinalité d’une association et joue le rôle
semblable à une clé primaire dans une BDR.
Il permet de tenir un dictionnaire composé de:
Qualificateur  Object(s) qualifié(s)
1
Enseignement UV Enseignant
 8)Packages
Un package permet de regrouper un ensemble de classes,
d’associations et éventuellement d’autres packages.
Il permet de découper un système en plusieurs parties
représentées chacune par un package.
Les packages peuvent avoir des actions entre eux.

Client
Facturation

Organisation par packages

 Packages (2)
Facture Client

Facturation: Facture

1 * 1 Société
concerner
Client
1
1 Acheter
*

Commande Produit

Contenu d’un package

Une classe peut apparaître dans différents packages (avec le même

nom).
On y trouve même des classes qui n’appartiennent pas au package mais
qui sont référencées par les classes propres.
On désigne une classe d’un package par:
nomPackage: nomClasse
 Etude de cas 1

Considérons les phrases suivantes :

1. Un répertoire contient des fichiers ;

2. Une pièce contient des murs ;
3. Les modems et les claviers sont des périphériques d'entrée/sortie ;
4. Une transaction boursière est un achat ou une vente ;
5. Un compte bancaire peut appartenir à une personne physique ou morale ;
6. Deux personnes peuvent être mariées.

Déterminez la relation statique appropriée (généralisation, composition,

agrégation ou association) dans chaque phrase de l'énoncé précédent.
Dessinez le diagramme de classe correspondant.
 Etude de cas 2
Cette étude de cas concerne un système simplifié de réservation de vols pour
une agence de voyages.
Les interviews des experts métier auxquelles on a procédé ont permis de
résumer leur connaissance du domaine sous la forme des phrases suivantes :
1.des compagnies aériennes proposent des vols par semaine ;
2.un client peut réserver un ou plusieurs vols, pour des passagers
différents ;
3.un vol est ouvert à la réservation et fermé sur ordre de la compagnie ;
4.une réservation concerne un seul vol et un seul passager ;
5.une réservation peut être annulée ou confirmée ;
6.un vol a un aéroport de départ et un aéroport d'arrivée ;
7.un vol a un jour et une heure de départ et un jour et une heure
d'arrivée ;
8.un vol peut comporter des escales dans des aéroports ;
9.une escale a une heure d'arrivée et une heure de départ ;
10.chaque aéroport dessert une ou plusieurs villes.
Faire le modèle Statique Correspondant.