METHODES D’ANALYSE

&
CONCEPTION ORIENTEE OBJET

Pr Nidal LAMGHARI
[email protected]

2020-2021
2 Introduction

Nidal LAMGHARI
 1. Introduction
3

 Principe de la modélisation
 Enjeux modélisation orientée objet
 UML : Présentation, Les principaux diagrammes UML
 Les 4+1 Vues de Kruchten
 Phases de la modélisation : Modèle linéaire
 Rôle de l'expression des besoins : Règles de gestion,
contraintes fonctionnelles, Exemple
 Rôle de l'analyse
 Rôle de la conception
Nidal LAMGHARI
 1. Introduction
4

 Qu’est-ce qu’un modèle ?

 Une représentation abstraite et simplifiée d’une entité du
monde réel en vue de le décrire, de l’expliquer ou de le
prévoir.
 Maîtriser la complexité
 Modéliser = abstraire la réalité pour mieux comprendre
le système à réaliser / réalisé
 Modèle météorologique
 Modèle économique
 Modèle démographique
 Plans

Nidal LAMGHARI
 1. Introduction
5

 Qu’est-ce qu’un modèle ?

 Une phase de modélisation est une aide au développement du
système informatique.
 Le processus de modélisation est nécessaire pendant toute la durée
de vie du projet :
 discussion avec les clients,
 analyse du système à réaliser,
 documentation commune entre les développeurs,
 etc.

Nidal LAMGHARI
 1. Introduction
6

 Enjeux de la modélisation
 Une simplification du monde réel
 Relier le modèle au monde réel par la notion d’objet

 Mieux comprendre le fonctionnement du système

 Maîtriser la complexité et assurer la cohérence

Nidal LAMGHARI
 1. Introduction
7

 Enjeux de la modélisation
 Prédire un fonctionnement ou des événements à venir.
 Mieux comprendre, expliquer et maitriser le
fonctionnement d’un système
 Faciliter sa réalisation puis sa maintenance.

 Permettre dans certains cas d’automatiser des tâches

Nidal LAMGHARI
 1. Introduction
8

 Enjeux de la modélisation
 Le code source d’un système logiciel = un modèle du
système.
 ne fournit qu’un seul niveau d’abstraction=niveau de
la mise en œuvre sur une infrastructure matérielle
particulière

Les développeurs
 Un modèle = un langage commun connu par tous les
intervenants et privilégié pour communiquer.
Nidal LAMGHARI
 1. Introduction
9

 Enjeux de la modélisation
 De disposer d’un langage commun entre les différents
intervenants, de la maitrise d’ouvrage (MOA) à la
maitrise d’œuvre (MOE).
 La MOA : experts métier
 est le commanditaire du projet.
 Il connait exactement les besoins mais il n’a pas toujours les
compétences techniques pour la réalisation.
 La MOE : développeurs
 s’occupe de la réalisation technique du projet.
 Soit réalise elle-même le projet
 Soit elle sous-traite une partie ou la totalité du projet.

Nidal LAMGHARI
 1. Introduction
10

 Enjeux de la modélisation
 Qui doit modéliser alors?
 Ilest préférable que la modélisation soit réalisée par la
maîtrise d'ouvrage (MOA).
 La MOE doit intervenir dans le modèle quand on doit
introduire les contraintes propres à la plateforme
informatique.

Nidal LAMGHARI
 1. Introduction
11

 Enjeux de la modélisation OO
 Indépendance du modèle par rapport aux fonctions
demandées
 Capacité d’adaptation et d’évolution du modèle quand
des fonctionnalités sont modifiées ou ajoutées
 Rechercher les objets du système puis leurs interactions

Nidal LAMGHARI
 1. Introduction
12

 Enjeux de la modélisation OO
 Modélisation = démarche antérieure à l’implémentation
 La description de la POO nécessite un travail
conceptuel :
 définitiondes classes, de leurs relations,
 des attributs,
 des opérations (implémentées par des méthodes),
 des interfaces,
 ...
 Il faut organiser ses idées, les documenter, organiser la
réalisation, définir des modules, ...
Nidal LAMGHARI
 1. Introduction
13

 UML: Historique

Nidal LAMGHARI
 1. Introduction
14

 UML: Présentation
 Unified Modeling Language
 Langage unifié pour la modélisation objet
 Langage universel de modélisation objet
 Notation, un outil de communication visuelle (diagrammes)
 Langage de modélisation des applications construites à
l’aide d’objets
 N’est pas un langage de programmation
 Indépendant d’un langage de programmation
 N’est pas un processus de développement
 La version actuelle de UML est disponible sur le site de
l’OMG: www.omg.org

Nidal LAMGHARI
 1. Introduction
15

 UML: Présentation
 N’est pas une méthode
 A été adopté par toutes les méthodes orientées objet
 UML est dans le domaine public ; c’est un standard
 Est un langage pour :
 Visualiser
 Chaque symbole graphique possède une sémantique
 Spécifier
 De manière précise et complète, sans ambiguïté
 Construire
 Une partie du code des classes peut être générée automatiquement
 Documenter
 Les différents diagrammes, notes, contraintes, exigences sont conservés dans
un document

Nidal LAMGHARI
 1. Introduction
16

 UML: Diagrammes
 Les 14 diagrammes peuvent être regroupés selon les trois
aspects suivants :
 Les aspects fonctionnels :
 Qui utilisera le logiciel et pourquoi faire ?
 Comment les actions devront-elles se dérouler ?
 Quelles informations seront utilisées pour cela ?
 Les aspects liés à l’architecture (statique) :
 Quels seront les différents composants logiciels à utiliser (base de
données, librairies, interfaces, etc.) ?
 Sur quel matériel chacun des composants sera installé ?
 Les aspects dynamiques :
 Quels sont les différents états que peut prendre un objet, dans quel
ordre ?
 Quels sont les enchaînements de messages envisageables...

Nidal LAMGHARI
 1. Introduction
17

 UML: Diagrammes
Cas Machine à
d’utilisation Activités Classes Objets
états

interactions modélisation classes, types, états des

des processus
entre le interfaces et instances de classes à
métier +
système et les échanges de relations entre classes travers leur
utilisateurs données eux unitéscycle de vie
interactions rassemblement rassemblement
d’installation, de
entre des de classes ou d’éléments de
configuration et
objets de composants modélisation
de déploiement

Interaction Composants Paquetage Déploiement

Nidal LAMGHARI
 1. Introduction
18

 Les 4+1 Vues de Kruchten

 Permet d’organiser la description du système en
plusieurs vues complémentaires
 L’utilisation de vues permet de traiter séparément les
intérêts des divers groupes d’intervenants
 Séparer les préoccupations fonctionnelles et les
préoccupations extra-fonctionnelles

Nidal LAMGHARI
 1. Introduction
19

 Les 4+1 Vues de Kruchten

Classes, d’objets, de connexions Organisation statique des
et de communications Scénarios modules
d’utilisation
pour mettre
Aspects fonctionnels en œuvre les Architecture
éléments des
4 vues
Vue
Vue logique
Vue cas des développement
utilisations

Vue processus Vue physique

SeNidal
rapporte aux objets actifs et
LAMGHARI Ressources matérielles et
aux interactions implantation logicielle
 1. Introduction
20

 Le cycle de vie:
 Les étapes du développement d'un logiciel, de sa
conception à sa disparition
 Permettre la validation du développement logiciel
= la conformité du logiciel avec les besoins exprimés
 Permettre de détecter les erreurs au plus tôt

Nidal LAMGHARI
 1. Introduction Production
Traduction
Vérification
Spécifications
dansdes
Recueil
de
un LP
Définition
delaet de
Déploiement
informations
Actions
des
de
la
conformité
formalisation
chaque
l'interfaçage
sous-
de
du
21 fonctionnalités
correctives
l'architecture
nécessaires
sur site duet
des
ensemble
logiciel
des
des
différents
besoins
sousaux
du
générale
définies
collectives
logiciel
pour lors
du
 Le cycle de vie: étapes spécifications
modules
ensembles
du
logiciel
clientdu
l'utilisation
logiciel
de la du
implémentés
initiales
logiciel
conception
logiciel

Analyse Conce Tests Qualifica Mise en

des ption unitair tion production
besoins détaill es
et ée
faisabili
té
Codage Documen
tation
Concept Intégrat
Mainten
ion ion
ance
Généra
le
Nidal LAMGHARI
 1. Introduction
22

 Le cycle de vie:
 Le cycle de vie permet de prendre en compte, en plus
des aspects techniques, l'organisation et les aspects
humains
 Il existe plusieurs modèles de cycle de vie:
 Cycle en cascade
 Cycle en V
 Cycle en spirale
 Cycle par incrément

Nidal LAMGHARI
 1. Introduction
23

 Le cycle de vie:

Nidal LAMGHARI
 1. Introduction
24

 Rôle de l’expression des besoins:

 Comprendre mieux le système
 Structurer les besoins du client
 Clarifier, filtrer et organiser les besoins
 Les besoins identifiés et structurés permettent de :
 Définir le périmètre du système à modéliser
 D’identifier les fonctionnalités principales du système

Nidal LAMGHARI
 1. Introduction
25

 Rôle de l’expression des besoins: Exemple1/cahier

des charges
 APRPD : Application d’aide à la planification de
réunions et à la prise de décision.
 Exprimer des préférences parmi plusieurs choix:
 des plages horaires (dates avec heures de début et de fin)
 des votes concernant une liste de choix.

Nidal LAMGHARI
 1. Introduction
26

 Rôle de l’expression des besoins: Exemple/cahier des

charges
 Pour le 1er type: (plages horaires):
 Une personne qui désire organiser une réunion (l’organisateur)
 Elle crée un scrutin,
 Renseigner les plages horaires possibles
 Ajouter les participants à la réunion.
 Les participants peuvent exprimer dans un bulletin leurs préférences
 Indiquer pour chaque plage horaire s’ils sont disponibles et pourront
participer (voter « pour » ou « contre ».
 L’organisateur récupère les résultats du scrutin à la fin du vote et
annonce la plage horaire choisie.
 La décision n’est pas prise automatiquement par APRPD , mais
« manuellement »

Nidal LAMGHARI
 1. Introduction
27

 Rôle de l’expression des besoins: Exemple/cahier des

charges
 Pour le 2ème type: (votes concernant une liste de choix):
 une personne qui désire consulter avant de prendre une décision
 L’organisateur crée un scrutin,
 Renseigne les différentes réponses possibles à la question posée
 Ajoute les participants à la consultation.
 Les participants expriment dans un bulletin leurs préférences
 Indiquer pour chaque réponse s’ils votent « pour » ou « contre »
 L’organisateur récupère les résultats du scrutin et annonce la
décision prise (par exemple, en maximisant le nombre de vote
« pour »).
 La décision n’est pas prise automatiquement par APRPD , mais en
fonction des résultats fournis par APRPD

Nidal LAMGHARI
 1. Introduction
28

 Rôle de l’expression des besoins: Exemple/règles de

gestion
 Toutes les personnes peuvent créer des scrutins
 elles peuvent donc être des organisateurs
 L’organisateur est de facto un participant au scrutin
 Seul l’organisateur est autorisé à gérer un scrutin
 Seuls les participants enregistrés peuvent participer au scrutin et
consulter les résultats.
 Pour pouvoir voter, il faut que le scrutin soit ouvert (dateDuJour ≥
dateDebutScrutin).
 La durée d’ouverture du scrutin est limitée.
 L’organisateur doit indiquer la date de destruction automatique
du scrutin.
Nidal LAMGHARI
 1. Introduction
29

 Rôle de l’expression des besoins: Exemple2/cahier des

charges
 Cette étude de cas concerne un système simplifié de gestion des
comptes bancaires (SGCB) offrant les services suivants :
 Retrait d’argent au guichet automatique de billets (GAB) de la
banque pour les porteurs d’une carte bancaire ;
 Consultation de solde de compte et retrait d’argent au GAB de la
banque pour les porteurs d’une carte bancaire ;
 Les clients porteurs d’une carte bancaire peuvent faire un dépôt en
numéraire ou en chèques et consulter leurs comptes sur internet.
 Un client qui effectue un virement peut demander à vérifier le solde
de son compte. Cette demande est autorisée si le solde est supérieur
à 200 MAD.
 Toute transaction est sécurisée et nécessite par conséquent une
authentification.

Nidal LAMGHARI
 1. Introduction
30

 Rôle de l’analyse:
 Traduire dans un langage près de celui des informaticiens les
modèles exprimés dans l’expression des besoins
 L’analyse ne prend en considération que des entités du domaine
(métier)
 Elle sert d’interface, avec l’expression des besoins, aux dialogues
avec les clients et les utilisateurs
 Elle sert de support pour la conception, l’implantation et la
maintenance
 Le modèle de l’analyse décrit le problème
 ce que doit faire le système et
 comment il le fait tel que vu d’un point de vue métier
 sans spécifier la solution technique (avec les canevas logiciels)
 Analyse = LE-QUOI

Nidal LAMGHARI
 1. Introduction
31

 Rôle de l’analyse:

Les modèles produits pendant l’analyse décrivent ce que

doit faire le système indépendamment de la façon dont il
sera réalisé.

Nidal LAMGHARI
 1. Introduction
32

 Rôle de la conception:
 Organiser le développement du système informatique
 Adresser des questions comme les dépendances entre
modules, la configuration, la gestion des versions
 Distribuer physiquement les différentes parties
logicielles du système
 Définir les langages de programmation, les schémas de
bases de données pour la persistance des données, etc.

Nidal LAMGHARI
 1. Introduction
33

 Rôle de la conception:
 Le modèle de la conception décrit la solution
 comment le problème est résolu
 Conception = LE-COMMENT
 La conception sert de support pour l’implantation et la
maintenance
 Le modèle de la conception n’est pas destiné à être
compréhensible par les utilisateurs mais par les
développeurs

Nidal LAMGHARI
 1. Introduction
34

 Questions
 Le code source d’une application est-il un modèle de
l’application ?
 UML est-il un processus de développement ?

 Un client demandant une informatisation est-il censé

comprendre les diagrammes UML ?
 Un développeur / programmeur est-il censé
comprendre les diagrammes UML ?

Nidal LAMGHARI
 1. Introduction
35

 Principes de l’OO: L’objet

 Un objet une entité informatique qui modélise un
élément du monde réel.
 Peut correspondre à une entité « concrète » ou «
abstraite»
 Il se caractérise par
 Une identité (référence ou handle)
 Un état
 Un comportement

Nidal LAMGHARI
 1. Introduction
36

 Principes de l’OO: L’objet

 Possède une identité unique qui le distingue des autres
objets.
 Maintient son état dans des variables appelées
attributs ou champs.
 Implémente son comportement à l'aide de fonctions ou
procédures appelées méthodes.

Nidal LAMGHARI
 1. Introduction
37

 Principes de l’OO: L’objet

 Deux objets peuvent avoir le même état et le même
comportement mais ont toujours des identités
différentes
 Le comportement et l’état d’un objet peuvent changer
durant l’exécution sans que cela affecte son identité.

Nidal LAMGHARI
 1. Introduction
38

 Principes de l’OO: L’objet

 Objet Etat Comportement Identité
 État d’un objet les valeurs des attributs de l’objet à un
instant donné
 L’état évolue au cours du temps

Nidal LAMGHARI
 1. Introduction
39

 Principes de l’OO: L’objet

 Objet Etat Comportement Identité
 Comportement d’un objet les compétences , les actions et
réactions d’un objet:
 démarrer, rouler, ajouter_essence, s’arrêter…
 Chaque opération est déclenchée par l’envoi d’un message
 L’état et le comportement sont liés:
 L’état est modifié par le comportement
 Le comportement à un instant t dépend de l’état courant:
 Mavoiture.demarrer() ne va pas marcher si

 Mavoiture.volume_essence==0

Nidal LAMGHARI
 1. Introduction
40

 Principes de l’OO: L’objet

 Objet Etat Comportement Identité
 Identité d’un objet l’existence propre de l’objet
 Identifie l’objet de manière non-ambigüe
 Attribuée implicitement à la création de l’objet
 Indépendante de l’état:
 2 objets différents peuvent avoir le même état

Nidal LAMGHARI
 1. Introduction
41

 Principes de l’OO: L’objet

 Cycle de vie d’un objet
 Construction (en mémoire).
 Utilisation (changement d’état par affectations,
comportements par exécution de méthodes)
 Destruction

Nidal LAMGHARI
 1. Introduction
42

 Principes de l’OO: La classe

 La définition de la structure d'un objet
 Description d’une famille d’objets ayant une même
structure et un même comportement.
 Une classe est caractérisée par:
 Un nom
 Des attributs
 Des méthodes

Nidal LAMGHARI
 1. Introduction
43

 Principes de l’OO: La classe

 Représentation graphique d’une classe

Nidal LAMGHARI
 1. Introduction
44

 Principes de l’OO: La classe

 La classe est la machine qui fabrique les objets
 Un moule ou un modèle à partir duquel on peut créer
des objets.
 Des objets créés à partir de la même classe auront des
aspects semblables (mêmes attributs et méthodes).
 Un objet d’une classe est aussi appelé instance de
cette classe.

Nidal LAMGHARI
 1. Introduction
45

 Principes de l’OO: La classe

 Donner des exemples d’objets de cette classe

Nidal LAMGHARI
 1. Introduction
46

 Principes de l’OO:
 L’OO est basé sur les concepts suivants:
 L’encapsulation
 L’héritage
 Le polymorphisme

Nidal LAMGHARI
 1. Introduction
47

 Principes de l’OO: Encapsulation

 Regrouper des données(attributs)et un comportement
(méthodes) dans une même classe
 Réglementer l’accès aux données de l’extérieur (par
d’autres objets).

 Impossible d’agir directement sur les données d’un objet

 Il est nécessaire de passer par ses méthodes.

Nidal LAMGHARI
 1. Introduction
48

 Principes de l’OO: Encapsulation

 L'encapsulation permet de définir des niveaux de

visibilité des éléments de la classe.

 Définir les droits d'accès aux données.

Nidal LAMGHARI
 1. Introduction
49

 Principes de l’OO: Encapsulation

 Niveaux de visibilité
 Publique: plus bas niveau de protection.
 les fonctions de toutes les classes peuvent accéder aux données
ou aux méthodes
 Protégée: niveau moyen de protection
 l'accès aux données est réservé aux fonctions des classes
héritières = fonctions membres de la classe ainsi que des classes
dérivées.
 Privée: le plus élevé niveau de protection
 l'accès aux données est limité aux méthodes de la classe elle-
même

Nidal LAMGHARI
 1. Introduction
50

 Principes de l’OO: Héritage

 Permet de créer une nouvelle classe à partir d'une
classe existante.
 Nouvelle classe classe dérivée/classe fille/sous classe
 Classe existante classe de base/classe mère/super classe
 L’héritage facilite largement la réutilisation de produits
existants

 Un avantage important de la POO.

Nidal LAMGHARI
 1. Introduction
51

 Principes de l’OO: Héritage

Arborescence de classes Héritage multiple

(hiérarchie)

Nidal LAMGHARI
1. Introduction

 Principes de l’OO: Polymorphisme

 Polymorphisme qu’une chose peut prendre plusieurs
formes.
 Trois types de polymorphisme :
 Le polymorphisme ad hoc
Le polymorphisme
Permet d'héritage
d'avoir des fonctions de
même nom, avec des
Le polymorphisme
Permet de redéfinir fonctionnalités
paramétrique
une
similaires,
méthode dansdans des
des classes
classes qui n’ont
héritant
aucun
Permet
d'une rapport entre
de définir
superclasse. elles
plusieurs
fonctions de même nom, mais
possédant des paramètres
différents (en nombre et/ou en type).
Nidal LAMGHARI
1. Introduction

 Principes de l’OO: Polymorphisme

 La classe complexe, la classe image et la classe lien
peuvent avoir chacune une fonction « afficher ». Cela
permettra de ne pas avoir à se soucier du type de
l’objet que l’on a, si on souhaite l’afficher à l’écran.

Nidal LAMGHARI