modulisation UML Chapitre 1 ENSA khouribgua.pdf

METHODES D’ANALYSE
&
CONCEPTION ORIENTEE OBJET
Pr Nidal LAMGHARI
nidaliso@yahoo.fr
2020-2021

1. Introduction
 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
3
Nidal LAMGHARI

1. Introduction
Nidal LAMGHARI
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

1. Introduction
Nidal LAMGHARI
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.

1. Introduction
Nidal LAMGHARI
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

1. Introduction
Nidal LAMGHARI
7
 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

1. Introduction
Nidal LAMGHARI
8
 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.

1. Introduction
Nidal LAMGHARI
9
 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.

1. Introduction
Nidal LAMGHARI
10
 Qui doit modéliser alors?
 Il est 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.

1. Introduction
Nidal LAMGHARI
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

1. Introduction
Nidal LAMGHARI
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éfinition des 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, ...

1. Introduction
Nidal LAMGHARI
13
 UML: Historique

1. Introduction
Nidal LAMGHARI
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

1. Introduction
Nidal LAMGHARI
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

1. Introduction
Nidal LAMGHARI
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...

1. Introduction
Nidal LAMGHARI
17
 UML: Diagrammes
Activités
Cas
d’utilisation
Classes Objets
Machine à
états
Interaction Composants Paquetage Déploiement
interactions
entre le
système et les
utilisateurs
modélisation
des processus
métier +
échanges de
données
classes, types,
interfaces et
relations entre
eux
instances de
classes
états des
classes à
travers leur
cycle de vie
interactions
entre des
objets
rassemblement
de classes ou
de composants
rassemblement
d’éléments de
modélisation
unités
d’installation, de
configuration et
de déploiement

1. Introduction
Nidal LAMGHARI
18
 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

1. Introduction
Nidal LAMGHARI
19
Aspects fonctionnels
Vue logique
Vue processus
Architecture
Vue
développement
Vue physique
Vue cas des
utilisations
Classes, d’objets, de connexions
et de communications
Se rapporte aux objets actifs et
aux interactions
Organisation statique des
modules
Ressources matérielles et
implantation logicielle
Scénarios
d’utilisation
pour mettre
en œuvre les
éléments des
4 vues

1. Introduction
Nidal LAMGHARI
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

1. Introduction
Nidal LAMGHARI
21
 Le cycle de vie: étapes
Analyse
des
besoins
et
faisabili
té
Concept
ion
Généra
le
Conce
ption
détaill
ée
Codage
Tests
unitair
es
Intégrat
ion
Qualifica
tion
Documen
tation
Mise en
production
Mainten
ance
Recueil et la
formalisation
des besoins
du client
Spécifications
de
l'architecture
générale du
logiciel
Définition de
chaque sous-
ensemble du
logiciel
Traduction
dans un LP
des
fonctionnalités
définies lors
de la
conception
Vérification
de la
conformité de
des sous
ensembles
implémentés
Vérification
de
l'interfaçage
des différents
modules du
logiciel
Vérification
de la
conformité du
logiciel aux
spécifications
initiales
Production
des
informations
nécessaires
pour
l'utilisation du
logiciel
Déploiement
sur site du
logiciel
Actions
correctives et
collectives

1. Introduction
Nidal LAMGHARI
22
 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

1. Introduction
Nidal LAMGHARI
23

1. Introduction
Nidal LAMGHARI
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

1. Introduction
Nidal LAMGHARI
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.

1. Introduction
Nidal LAMGHARI
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 »

1. Introduction
Nidal LAMGHARI
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

1. Introduction
Nidal LAMGHARI
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.

1. Introduction
Nidal LAMGHARI
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.

1. Introduction
Nidal LAMGHARI
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

1. Introduction
Nidal LAMGHARI
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é.

1. Introduction
Nidal LAMGHARI
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.

1. Introduction
Nidal LAMGHARI
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

1. Introduction
Nidal LAMGHARI
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 ?

1. Introduction
Nidal LAMGHARI
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

1. Introduction
Nidal LAMGHARI
36
 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.

1. Introduction
Nidal LAMGHARI
37
 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é.

1. Introduction
Nidal LAMGHARI
38
 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

1. Introduction
Nidal LAMGHARI
39
 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

1. Introduction
Nidal LAMGHARI
40
 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

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

1. Introduction
Nidal LAMGHARI
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

1. Introduction
Nidal LAMGHARI
43
 Représentation graphique d’une classe

1. Introduction
Nidal LAMGHARI
44
 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.

1. Introduction
Nidal LAMGHARI
45
 Donner des exemples d’objets de cette classe

1. Introduction
Nidal LAMGHARI
46
 Principes de l’OO:
 L’OO est basé sur les concepts suivants:
 L’encapsulation
 L’héritage
 Le polymorphisme

1. Introduction
Nidal LAMGHARI
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.

1. Introduction
Nidal LAMGHARI
48
 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.

1. Introduction
Nidal LAMGHARI
49
 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

1. Introduction
Nidal LAMGHARI
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.

1. Introduction
Nidal LAMGHARI
51
 Principes de l’OO: Héritage
Arborescence de classes
(hiérarchie)
Héritage multiple

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

 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.
1. Introduction
Nidal LAMGHARI

modulisation UML Chapitre 1 ENSA khouribgua.pdf

Contenu connexe

Similaire à modulisation UML Chapitre 1 ENSA khouribgua.pdf

Dernier

modulisation UML Chapitre 1 ENSA khouribgua.pdf