Modélisation Objet

Aziza EL OUAAZIZI
Faculté Polydisciplinaire de Taza
Département des Mathématiques, Physique et Informatique
Licence Informatique

1
 Introduction
 La réalisation d’un système informatique (logiciel)
nécessite::
nécessite
d’analyse comprendre et décrire de façon précise
une phase d’analyse
les besoins des utilisateurs ou des clients
clients.. Imaginer la solution
solution..
Une phase de conception  apporter plus de détails à la
solution et clarifier les aspects techniques, tels que l’installation
des différentes parties logicielles sur un matériel
matériel..
 La réalisation de ces deux phases nécessite des
méthodes, des conventions et des notations
notations..

Modèles

2
 Pourquoi modéliser?

Un modèle est une représentation graphique simplifiée et abstraite (exclut

les détails) d’une partie ou de la totalité d’un système réel, il permet:

Mieux comprendre le système à développer.

Comprendre et de décrire les besoins.
Concevoir et construire les solutions.

Faciliter la communication entre les acteurs (concepteurs, développeurs,

clients…) impliqués dans le projet grâce au illustrations graphiques et
symboliques du projet futur.

Réduire la complexité:
Elimination des détails qui n'influencent pas la compréhension du système.
Décomposition du système en sous-sous-systèmes afin de répartir les tâches
entre équipes.

3
 Modélisation fonctionnelle

Début

Décomposition du projet Instructions1

(logiciel) en une hiérarchie de Instructions11

Décision instructio4
fonctions et de données. Les
ction 12
Instructions12

fonctions fournissent les Décision Instructions14

Instructions3
services désirés et les données Instructions13
Appel sous
représentent les informations programme

manipulées. Instructions4

Fin

4
 Inconvénients de la modélisation
fonctionnelle

 Le développeur est obligé de penser de manière algorithmique

algorithmique il
doit fournir un effort supplémentaire pour bien structurer et
décomposer hiérarchiquement le programme en des fonctions.
PowerPoint
 Le code est difficile à modifier,
à maintenir: les fonctions doivent Onglet Onglet Onglet
Etc.
Fichier Accueil Insertion
être suffisamment génériques;
Page de
Enregistrer Coller
 Les fonctions et les données garde

sont traités séparément. Enregistrer

Couper
Page
sous vierge

 La difficulté de travailler en équipes. Etc. Etc. Etc.

5
 Modélisation orientés objet

 S’inspire du monde réel qui est composé d’objets,

d’êtres vivants, de matières,
matières,……
 Regroupe à la fois les données et les fonctions dans
une seule entité (objet).
 Utilise une démarche Itérative et incrémentale.
 Utilise une abstraction forte.
 Facilite l’utilisation les modules et les objets:
extensibilité, adaptabilité.

Souplesse de programmation

6
 UML (Historique)
 UML «Unified Modeling Language
anguage»» est un langage de modélisation
crée de la fusion des trois méthodes:

1991:OMT (Object
(Object Modeling Technique) de James RUM BAUGH;

1991: OOD (Object

(Object Oriented Design ) de Grady BOOCH;

1992: OOSE (Object

(Object Oriented Software Engineering)
Engineering) de Ivar
JACOBSON.

 UML est à présent un standard adopté et défini par l’OMG (Object

Management Group)

Développement d’applications avec une démarche orienté objet (Java,

Delphi, Ada,…)

7
 Langage UML
 UML est un langage de modélisation qui unifie les notations et
les concepts quels que soient le domaine d’application.
Constitué d’un ensemble de schémas, qui donnent chacun une vision
différente du projet à traiter, appelés des diagrammes:
Chaque diagramme est réalisé par un ensemble d’éléments de
visualisation (objet, classe, état, activité…) .
Un diagramme peut être réalisé soit manuellement ou à l’aide de progiciel
(Rational Rose, BoUML, StarUML, ArgoUML,…).

 Avantages de UML:
ne préconise aucune démarche: liberté dans choix des diagramme et
l’ordre de leur utilisation.
Bon moyen de visualisation du logiciel futur (projet) grâce à la
représentation graphique et textuelle des diagrammes.

8
 Cycle de vie adéquat à UML
Le cycle de vie d'un logiciel désigne toutes les étapes du développement d'un
logiciel, de son analyse à sa disparition.
Mise en place chez le client

Validation des
Définition et formulation des exigences des
besoins et utilisateurs (client) S’accorder sur ce qui
Vérification du bon déploiement doit être fait dans le système
fonctionnement de l’application

Tests de Définition des

vérification besoins

Implémentation Analyse
Traduction de la conception
Compréhension en profondeur des exigences
en code
Construction de modèles  Comprendre les
Conception besoins et les décrire  Solution

Mise au point de l’architecture du système

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

Un cycle itératif incrémentale 9

 UML : les diagrammes (1)

 Modèles UML sont manipulés au moyen de vues graphiques: 9

diagrammes essetiels:
Diagrammes des cas d’utilisation: fonctions du système du point
de vue des utilisateurs.

Diagrammes de séquence: représentation temporelle des objets

et de leurs interactions.

Diagrammes de collaboration: représentation spatiale des objets,

des liens et des interactions.

Diagrammes de classes: structure statique en terme de classes

et relations qui les lient.

10
 UML : les diagrammes (2)
 Diagrammes d’objets: représentation des objets et de leurs
relations (instanciation du diagramme de classe).

 Diagrammes d’états-transitions: comportement d’une classe en

terme d’états, lié au cycle de vie des objets.

 Diagrammes d’activités: représentation du comportement d’une

opération, d’un cas d’utilisation, ou d’un processus métier en terme
d’actions.

 Diagrammes de composants: composants physiques d’une

application, dépendance entre ces composants.

 Diagramme de déploiement: déploiement des composants sur les

dispositifs matériels, modes de connexion..

11
 Diagrammes des cas d’utilisation

 Développés par Ivar Jacobson dans la méthode Object

Object--
Oriented Software Engineering (OOSE)
Permettent d’impliquer les utilisateurs dès les premiers stades
du développement pour exprimer leurs besoins
besoins..
Décrivent un système du point de vue de l’utilisateur
l’utilisateur..
Mettent en évidence les services rendus par le système
système..
Délimitent le cadre du projet .
Servent de support visuel de communication entre les usagers et
les concepteurs, pour spécifier les besoins
besoins..

12
 Le système

 Modélisé par un ensemble de cas d’utilisations (services)

et vu au départ comme une boîte noire
noire..
 Contient tout les cas d’utilisations, mais pas les acteurs
acteurs..
 Représenté dans un diagramme par un rectangle simple
éventuellement avec son nom en entête
entête..

Borne interactive d’une banque System

13
 Elaboration du diagramme des cas

 Rechercher les acteurs qui vont interagir avec le système

système..

 Rechercher pour chaque acteur, les cas d'utilisation

d'utilisation..

 Pour chaque cas d'utilisation :

rechercher les interactions
interactions;;
rechercher les objets manipulés
manipulés..

 Faire la maquette de chaque cas d'utilisation

d'utilisation..

14
 Acteur
 Les acteurs n’appartiennent pas au système, MAIS ils
interagissent avec celui
celui--ci
ci::
fournissent de l’information en entrée
entrée;;
et/ou reçoivent de l’information en sortie
sortie..
 Les acteurs ne sont pas forcément des personnes
personnes..
acteurs principaux agissent directement sur le système
système..
acteurs secondaires n’ont pas de besoin direct d’utilisation
d’utilisation..
C’est généralement un autre système (logiciel) avec lequel le
nôtre doit échanger des informations
informations..
consultés par le système à développer,
récepteur d’informations venant du système
système..

15
 Comment identifier un acteur?

 Qui est intéressé par un certain besoin (service)?

 Par qui le système est utilisé dans l’organisation?
 Qui bénéficiera de l’utilisation du système ?
 Qui fournira l’information au système ?
 Qui va supporter et maintenir le système ?
 Quels sont les choses qui seront produit automatiquement
par le système?

16
 Comment représenter un acteur?

Les acteurs candidat sont systématiquement

systématiquement::
Des utilisateur humains (Administrateur, ingénieur de
maintenance…)

Stick man
Nom Acteur

D’ autres systèmes connexes qui interagissent avec le

système par biais de protocoles bidirectionnels.

« Actor »
Nom Acteur
«system» Stick man Mot clé
Nom Acteur
17
 Cas d’utilisation

 Représente un service complet attendu du système, il a un

début et une fin clairement identifiés .
 Décrit une séquence d’actions réalisée par le système et
produit un résultat observable pour un acteur
acteur..
 Se représente en général par une ellipse contenant le nom
du cas, et optionnellement, au
au--dessus du nom, un stéréotype
stéréotype..

Nom du cas
Nom du cas

Propriétés
« Use case »
Nom du cas

Nom du cas
Propriétés
18
Comment identifier les cas d’utilisation?

Identifier les acteurs du système et pour chaque

acteur:

Rechercher les différents intentions métier avec

lesquelles il utilise le système.

Déterminer dans le cahier des charge les services

fonctionnel attendus du système.

Remarque:
Remarque:
Nommer le cas d’utilisation par un verbe à l’infinitif
suivi d’un complément (du point de vue de l’acteur)
l’acteur)..

19
Exemple des cas d’utilisation d’un
distributeur de boissons
distributeur de boissons

Acheter une
boisson

Client

Remplir le
stock

Opérateur de
maintenance Vider la
caisse

20
 Relations entre acteurs et cas
d’utilisation

 Relation d’association: lien de communication entre un

d’association:
acteur et un cas d’utilisation, il est représenté un trait continu
et parfois par une flèche qui suit le sens de transmission de
l’information..
l’information

 Multiplicité
Multiplicité:: Lorsqu’un acteur peut interagir plusieurs fois
avec un cas d’utilisation, il est possible d’ajouter une
multiplicité sur l’association du côté du cas d’utilisation
d’utilisation::
 * : plusieurs fois
 n : exactement n fois
 n..
..m
m : entre n et m fois

21
 Relations entre acteurs et cas
d’utilisation

 Acteurs principal: «primary

primary»» obtient un résultat
observable du système (le cas d’utilisation lui rend service).
 Acteur secondaire: «secondary
secondary»» sollicité par le système
pour obtenir des informations complémentaires.

Logiciel de partage de fichier

« primary » * Télécharger * « secondary»

un fichier

Client Serveur

22
 Relations entre cas d’utilisation
 Relation d’inclusion
d’inclusion::
Un cas A inclut un cas B si le comportement décrit par le cas A
inclut le comportement du cas B: le cas A dépend de B.
Lorsque A est sollicité, B l’est obligatoirement, comme une partie
de A.
symbolisée par le stéréotype << <<include
include>>
>> et représentée par une
flèche avec un trait pointillé orienté vers le cas inclut
inclut..

distributeur de boissons
Payer
«include» boisson
Acheter une
boisson
Client

23
 Relations entre cas d’utilisation
 Relation d’extension
d’extension::
un cas B étend un cas A lorsque le cas d’utilisation B peut être
appelé au cours de l’exécution du cas d’utilisation A. Lorsque A
est sollicité, B peut éventuellement être sollicité, (B est optionnel)
optionnel)..
symbolisée par le stéréotype << <<extend
extend>>
>> et représentée par une
flèche avec un trait pointillé vers le cas de base
base..
Toujours soumise une condition exprimé graphiquement dans
une note
note..
Annuler
« extend » l’opération
Acheter une
boisson
Client {si client appuye sur bouton annuler}

24
 Relations entre cas d’utilisation
 Relation de généralisation/spécialisation
généralisation/spécialisation::
Un cas A est une généralisation d’un cas B si B est un cas
particulier de A. Symbolisée par une flèche avec un trait pleins
vers le cas le plus général
général..
distributeur de boissons

Annuler
« extend » l’opération
Acheter une
boisson Généralisation
Client Payer
« include »
boisson

Régler en Régler en
espèce CB
Spécialisation
25
 Relation entre acteur: généralisation

 un acteur A est une généralisation d’un acteur B si l’acteur A peut

être substitué par l’acteur B. Dans ce cas, tous les cas d’utilisation
accessibles à A le sont aussi à B, mais l’inverse n’est pas vrai
vrai..
Système de vente par correspondance

Passer «include»
commande
Rechercher
Préposé aux article
Suivre
commandes commande «include»

«include»
Gérer stock
Directeur
des ventes
26
 Regroupement des cas d’utilisation en
paquetages
 Un paquetage permet d’organiser les éléments de modélisation en
groupes.
groupes.
 Le regroupement peut se faire par acteur ou par fonctionnalité (cas)
(cas)..
Système de vente par correspondance
Commande
Passer Support
commande
Rechercher
Préposé aux article
Suivre
commandes commande

Stock

Gérer stock Relation de dépendance

Directeur entre paquetage reflète
l’inclusion des cas
des ventes
27
Description textuelle des cas d’utilisation
 ilest recommandé de rédiger une description textuelle pour
un cas d’utilisation car c’est une forme souple qui convient
dans bien des situations
situations.. Elle se compose de trois parties
parties::

Partie 1: Identification du cas

cas::
Nom du cascas::
Objectif : Intention principale
Acteurs principaux :
Acteurs secondaires :
Dates : notamment date de mise jour
Responsable :
Version :

28
 Description textuelle des cas d’utilisation
 Partie 2: description du fonctionnement du cas d’utilisation
Les pré
pré--conditions : elles décrivent dans quel état doit être le
système avant que ce cas d’utilisation puisse être déclenché
déclenché..
Les scénarios
scénarios:: échanges d’évènements décrivant comment les
différents acteurs vont utiliser le système
système.. On distingue des
scénarios::
scénarios
nominaux qui se déroulent quand il n’y a pas d’erreur
d’erreur;;
alternatifs qui sont des variantes du scénario nominal, l’objectif étant
malgré la variante, atteint à la fin
fin;;
d’exception qui décrivent les cas d’erreurs matériels qui contribue à
ne pas pouvoir atteindre l’objectif
l’objectif..
Des post
post--conditions : Elle décrivent l’état du système à l’issue
des différents scénarios
scénarios..

29
Description textuelle des cas d’utilisation
 Partie 3: c’est une rubrique optionnelle qui contient généralement
des spécifications non fonctionnelles (spécifications techniques, …).
Elle peut éventuellement contenir une description des besoins en
termes d’interface graphique
graphique..

 Exemple
Exemple::

distributeur de billet

Retirer
argent
Client

30
 Exemple
Pré-condition contient des billets; en attente d’une opération: ni en panne, ni
en maintenance.
Déroulement normal: scénario nominal
(1) le client introduit sa carte bancaire, (2) le système lit la carte et vérifie si
la carte est valide, (3) le système demande au client de taper son code, (4)
le client tape son code confidentiel, (5) le système vérifie que le code
correspond à la carte, (6) le client choisit une opération de retrait, (7) le
système demande le montant à retirer, etc.
Variantes: scénario d’exception
Carte invalide: au cours de l’étape (2), si la carte est jugée invalide, le
système affiche un message d ’erreur, rejette la carte et le cas d’utilisation
se termine.
Post-condition si de l’argent a pu être retiré, la somme sur le compte est
égale à la somme qu’il y avait avant moins le retrait. Sinon, la somme sur le
compte reste inchangée.
Contraintes non fonctionnelles
(A) Performance: le système doit réagir dans un délai inférieur à 4
secondes, quelque soit l’action de l’utilisateur.
(B) Sécurité: le guichet avale la carte soumise à une plainte de vol.

31
Description textuelle au service du client
 Lorsde la description de chacun des cas d’utilisation, de
nombreuses questions supplémentaires peuvent apparaître

Trouver des réponses aux questions que l’on se pose au cours

de l’analyse
l’analyse..

Découvrir des éléments que l’on n’avait pas vu ou pour lesquels
nous n’avions pas reçu d’informations au début par le client
client..

Valider l’une de nos propositions pour régler un problème de
contradiction ou incohérence de certains éléments
éléments..

Remettre en cause notre vision de certains besoins
besoins..

32
 Conclusion

 Le diagramme cas d’utilisation est le premier diagramme

qui doit être réalisé, il modélisent à la fois les
fonctionnalité (services
services)) et les communications
interactions)) entre acteurs et système.
(interactions
 Permet d’organiser les fonctionnalités attendues grâce
aux relations d’héritage, d’inclusion et d’extension.
 Avec les descriptions textuelles et les scénarios
scénarios,,
l’analyste dispose de moyens simples pour exprimer de
manière semi-
semi-formelle les besoins fonctionnels du
système étudié

33
 Exercice 1
La société royale d’archéologie automobile vous embauche pour réaliser un
système de support aux archéologues lors des fouilles
fouilles..
Un archéologue lors d’une fouille réalise le croquis d’une pièce sur son
Tablet PC et l’envoie au serveur de l’association
l’association.. Pour ce faire il ouvre un
nouveau dessin et commence à dessiner dessiner.. Il a également la possibilité de
copier des éléments à partir d’un ancien dessin
dessin.. Après avoir défini un certain
nombre de propriétés pour son dessin (résolution, nombre de couleurs, couleurs,…
…),
l’archéologue envoie son dessin au serveur de bases de données en
indiquant où le fichier doit être stocké et par qui il peut être vu
vu..
1- Proposer un diagramme des cas d'utilisations pour ce système
système..
2- On vous demande d’adapter le système dans le cas où les archéologues
de terrain sont de deux types types:: les archéologues apprentis et les
archéologues confirmés
confirmés.. Pour assurer la qualité de la base de données,
seuls les confirmés peuvent réaliser et envoyer des croquis au serveur
serveur..
Néanmoins, les archéologues apprentis peuvent prendre et envoyer des
notes de type texte (prises sur leur Tablet PC) PC).. Cette faculté est
également accessible aux confirmés
confirmés.. Ces notes seront disponibles pour
tous via le site web de l’association
l’association..

34
Correction: digramme des cas d’utilisation

Support aux archéologues

Ouvrir nouveau dessin

<<include>>

<<include>>
Réaliser croquis Définir propriétés

<<extend>>

Archéologue Utiliser anciens dessin

Envoyer croquis

«system»
SBD

35
 Correction
Support aux archéologues

Ouvrir nouveau dessin

<<include>>

<<include>>
Réaliser croquis Définir propriétés

Archéologue <<extend>>
expérimenté
Prendre note
Utiliser anciens dessin

Archéologue
Envoyer information

Archéologue
apprenti

Envoyer notes Envoyer croquis

Web site SBD

36
 Exercice 2

Dans un établissement scolaire, on désire gérer la réservation des salles de

cours ainsi que du matériel pédagogique (ordinateur portable ou/et Vidéo
projecteur)..
projecteur)
Seuls les enseignants sont habilités à effectuer des réservations (sous
réserve de disponibilité de la salle ou du matériel)
matériel)..
Le planning des salles peut quant à lui être consulté par tout le monde
(enseignants et étudiants)
étudiants)..
Par contre, le récapitulatif horaire par enseignant (calculé à partir du
planning des salles) ne peut être consulté que par les enseignants
enseignants..
Enfin, il existe pour chaque formation un enseignant responsable qui
seul peut éditer le récapitulatif horaire pour l’ensemble de la formation
formation..
Modéliser cette situation par un diagramme de cas d’utilisation

37
 Correction
Réservations de salles et du matériel

Consulter
planning
Vérifier
disponibilité
Etudiant
<<include>>
Réserver
Effectuer salle
réservation

Réserver
Enseignant
matériel
Consulter
horaire

Réserver vidéo Réserver

projecteur portable
Editer
Enseignant
responsable récapitulatif

38