Cours 3 PDF

Méthode de conception Orientée Objet UML
Méthode de conception Orientée Objet

UML
Bennani Mohamed Taj
Faculté des sciences Dhar El Mahraz Fes 1/54
2019/2020
Bennani Mohamed Taj Faculté des sciences Dhar El Mahraz Fes 1/54
1 Section I : Introduction
2 Section I : Le génie logiciel
Présentation
Les objectifs du génie logiciel
Les étapes de réalisation d’un logiciel
Autres modèles de développements logiciels
3 Section I : Méthode de conception orienté objet UML
Introduction à l’UML
Les diagrammes de UML
La partie structurelle
La partie comportementale
Notion d’objet
Les cas d’utilisation
Section I : Introduction
Contexte
L’appréhension d’une problématique complexe telle que

le développement d’applications repose de plus en plus sur
le recours à la modélisation informatique.
L’accélération du renouvellement des technologies conjuguée
avec la pression économique et concurrentielle qui s’exerce
sur les entreprises, obligent les acteurs du monde informa-
tique à produire des solutions de plus en plus rapidement,
dans un contexte d’amélioration continue de la qualité et de
la performance des systèmes d’information.
Internet a été un vecteur favorisant le développement de très
nombreuses applications dont une grande partie utilise des
solutions à base de langage de programmation objet comme
Java, C++ ou C#.
Objectif
Depuis longtemps, le langage UML (Unified Modelling Lan-

guage) est développé pour formaliser des besoins clients aux
programmes qu’ils réalisent.
Cette méthode est proposé comme moyen de communication
entre modélisateurs ou informaticiens et les autres métiers
indépendamment des disciplines et de la technique informa-
tique.
UML a apporté tout naturellement le support méthodologique
qui manquait à tous les concepteurs et développeurs, qui
voulaient formaliser l’analyse et la conception technique de
leur logiciel.
Spécifications
Depuis plus de 30 ans, la conception des bases de données

est réalisée à l’aide du modèle entité-association. Ce modèle
a fait ses preuves et la plupart des outils informatiques de
conception l’utilisent encore aujourd’hui.
La notation UML s’est imposée depuis quelques années pour
la modélisation et le développement d’applications écrites
dans un langage objet (C++ et Java principalement).
Initialement, UML n’a pas été conçue pour les bases de
données. Cependant, elle offre un même formalisme aux concep-
teurs d’objets métiers et aux concepteurs de bases de données.
UML s’est imposée en tant que langage graphique de modélisation
puisqu’il répond à un véritable besoin et devenu un standard
car il s’appuie sur une norme très structurante.
Historique de l’UML
Il hérite principalement des méthodes objets de Booch ,
OMT (Object Modeling Technique en français Technique de
modélisation objet) et OOSE (Object Oriented Software En-
gineering) inventées respectivement par Grady Booch, Rum-
baugh et Jacobson
UML est une fusion de OOA/OOSE/OMT ;
Adopté par l’ OMG en Novembre 1997 devient un standard.
Section I : Le génie logiciel
Présentation
Présentation du génie logiciel
Définition d’un logiciel

Un logiciel est un ensemble d’appels de sous-programmes.
Génie logiciel
Un Ensemble de méthodes, de techniques et d’outils dédiés à la
conception, au développement et à la maintenance des systèmes
informatiques.
Les objectifs du génie logiciel
Objectifs du génie logiciel

Avoir des procédures systématiques pour créer des logiciels de
grande taille qui respectent les règles imposées par CQFD :
Coûts : les coûts alloués à la réalisation soient respectés
Qualité : il doit respecter les qualités suivantes :
Validité : capacité à exécuter les tâches pour lesquelles il a
été créé.
Fiabilité : capacité de fournir les résultats attendus.
Extensibilité : capacité d’ajouter de nouvelles fonctionnalités.
Compatibilité : capacité de coopérer avec d’autres logiciels.
Efficacité : capacité de fournir de bon résultats dans les délais
prévus.
Portabilité : capacité d’être porté sur d’autre OS.
Fonctionnalités : La spécification doit correspondre aux be-
soins réels du client.
Délais : le délais ne doit pas être dépassé.
Les phases de réalisation d’un logiciel
La réalisation d’un logiciel se résume en 6 phases :

1 La phase d’analyse.
2 La phase de conception.
3 La phase de réalisation.
4 La phase de mise en place.
5 La phase d’exploitation et maintenance.
6 La phase de démontage.
La phase d’analyse
Pour créer un nouveau logiciel, On effectue l’étude de faisabilité

qui consiste à déterminer :
Les avantages.
Les inconvénients.
Elle est destinée aux décideurs qui :
Valident les orientations.
Chiffrent l’effort, coût de réalisation, gestion des délais, temps
de formation des utilisateurs, coûts d’achat de nouveaux
matériels, récupération des anciennes données.
La phase d’analyse
Le Cahier des charges est une phase importante qui permet de :

Faire une étude de l’existence des logiciels.
Est un guide qui permet de définir les logiciels dans ses
grandes lignes (pas trop techniques)
Indique ce qui doit être fait mais sans dire vraiment com-
ment.
Permettra au concepteur de valider chaque étape de la réalisation
du logiciel.
Indique les spécifications du projet.
La phase de conception
C’est la phase la plus importante, elle définit l’architecture du
logiciel (son squelette, son comportement, etc.). Il y’a 2
architectures :
L’architecture global du logiciel : qui consiste à faire une
représentation globale du logiciel (décrire le logiciel de façon
global).
L’architecture détaillée : décrit les composants du logiciel et
le lien entre les différents composants du logiciel.
L’architecture d’un logiciel concerne 2 aspects :
L’aspect statique : décrit les parties non variables du logiciel
une fois validé .
L’aspect dynamique : décrit le comportement du logiciel de
façon globale et de chaque composant du logiciel.
La phase de réalisation
Une fois la conception terminée et validée, la réalisation du

logiciel doit être effective.
Il s’agit de transformer le schéma du logiciel en un produit
(exécutable).
Cette phase consiste à conduire le logiciel.
La spécification consiste à décrire toutes les spécifications :

Fonctionnelles : ce que doit réaliser le logiciel (sous- pro-
grammes / traitements à réaliser)
Non fonctionnelles : contraintes d’environnements, perfor-
mance, sécurité.
La conception consiste à apporter une réponse à l’étape
Précédente :
Architecture (modules, objets, classes, fonctions).
Matériel (environnement de développement, application ex-
ternes utilisées).
L’implantation ( implémentation ou codage) consiste à coder
les données.
La validation sert à vérifier chaque module.
Il faut garder la trace de ce qui a été fait.
La phase de mise en place
Maintenant que le logiciel est réalisé (l’exécutable obtenu),

il faut passer à sa mise en œuvre.
Mettre en œuvre un logiciel veut dire le déployer :
Installer le logiciel dans l’environnement de production.
Dès le début de la phase de réalisation, il faudrait pouvoir
disposer d’une machine dans l’environnement de production.
Le déploiement d’un logiciel exige la préparation de son en-
vironnement de production.
Interconnecter tous les systèmes et processus devant com-
muniquer avec le logiciel.
Transfert de données et conversion dans un nouveau format
(Récupération).
La phase d’exploitation
Une fois le logiciel est en place, son exploitation devient fon-

damentale.
Cette phase résume deux tâches qui doivent se réaliser depuis
la mise en place du logiciel jusqu’à sa fin.
Pour commencer l’exploitation du logiciel, on fait le paramétrage
du logiciel (l’insertion des données).
Ensuite faire le traitement de données (tester le logiciel) pour
détecter les erreurs s’ils y existent.
La phase de maintenance
Une fois les erreurs détectées, il faut passer à la correction

(la maintenance du logiciel).
La maintenance doit se tenir régulièrement.
Il existe 3 types de maintenance :
Corrective : consiste à corriger les erreurs détectées lors de
l’exploitation. Bugs qui apparaissent.
Adaptative : consiste à adapter le logiciel à un besoin ou à
un environnement : Besoins exprimés par les utilisateurs pour
faciliter leurs travail.
Perfective : le logiciel satisfaisant toutes les exigences du ca-
hier des charges, il est nécessaire de penser à son évolution.
Il s’agit de le rendre plus performant. Mise en place d’un
système de traçage des bugs (date/conditions de reproduc-
tion/solution et correction).
La phase de démontage
Malgré toutes les maintenances réalisées, le logiciel ne peut

plus satisfaire les besoins du client , donc révolue : c’est la
fin de vie du logiciel, on parle alors de démontage.
Un logiciel est qualifié de révolue lorsque :
Il ne satisfait plus les besoins des utilisateurs et aucune main-
tenance ne peut palier au problème.
Il est dépassé par la technologie.
Le client n’a plus besoin du logiciel.
Le démontage du logiciel est assimilé comme la fin de vie du
logiciel.
Il faut donc supprimer les exécutables, les drivers et les
données.
Le modèle en cascade
Le modèle en V
Section I : Méthode de conception orienté objet UML
Présentation de UML
UML (Unified Modeling Language) est normalisé par l’OMG

(Object Management Group).
http://www.omg.org/spec/UML/
Dernière version : 2.5.1 (Décembre 2017)
UML est une notation standard pour la modélisation d’ap-
plications à base d’objets (et de composants depuis la version
2).
UML est utilisable dans de nombreux autres contextes de
conception ou spécification.
Exemple : schéma de BDD.
UML est un langage utilisant une notation graphique.
Le modèle(diagramme)
Un modèle est une représentation partielle de la réalité.

Abstraction de ce qui est intéressant pour un contexte donné.
Vue subjective et simplifiée d’un système.
Avec UML, on va s’intéresser principalement aux modèles
d’applications informatiques :
Un modèle UML = des diagrammes UML
L’utilité des modèles
Faciliter la compréhension d’un système :

Permettre également la communication avec le client.
Vision de communication, de documentation.
Définir voire simuler le fonctionnement d’un système :
Dans ce cas, on se doit d’être le plus précis possible dans le
contenu des modèles pour s’approcher du code.
Vision de développement, de production.
Introduction
Afin d’assurer un bon niveau de cohérence et d’homogénéité

sur l’ensemble des modèles, UML propose :
D’une part un certain nombre de règles d’écriture ou de
représentations graphiques normalisées
Et d’autre part des mécanismes ou des concepts communs
applicables à l’ensemble des diagrammes.
Certains éléments, comme les stéréotypes, sont spécifiquement
prévus pour assurer une réelle capacité :
D’adaptation.
Et d’évolution.
La notation pour prendre en compte les particularités des
différentes situations à modéliser.
Les différents types de diagrammes
UML, dans sa version 2, propose 13 diagrammes qui peuvent

être utilisés dans la description d’un système.
Les diagrammes sont regroupés dans deux grands ensembles.
Les diagrammes Structurels.

Les diagrammes comportementaux.
Les diagrammes d’interactions.
Diagrammes selon les axes de modélisation
Hiérarchie des diagrammes UML
Les 5 vues de Kruchten
Les diagrammes structurelles
Ces diagrammes, au nombre de six, ont vocation à représenter

l’aspect statique d’un système (classes, objets, composants. . . ).
Diagramme de classes : représente la description statique
du système en intégrant dans chaque classe la partie dédiée
aux données et celle consacrée aux traitements. C’est le dia-
gramme pivot de l’ensemble de la modélisation d’un système.
Diagramme d’objets : permet la représentation d’instances
des classes et des liens entre instances.
Diagramme de composant (modifié dans UML 2) : représente
les différents constituants du logiciel au niveau de l’implémentation
d’un système.
Les diagrammes structurelles
Diagramme de déploiement (modifié dans UML 2) : décrit

l’architecture technique d’un système avec une vue centrée
sur la répartition des composants dans la configuration d’ex-
ploitation.
Diagramme de paquetage (nouveau dans UML 2) : donne
une vue d’ensemble du système structuré en paquetage. Chaque
paquetage représente un ensemble homogène d’éléments du
système (classes, composants. . . ).
Diagramme de structure composite : permet de décrire la
structure interne d’un ensemble complexe composé par exemple
de classes ou d’objets et de composants techniques. Ce dia-
gramme met aussi l’accent sur les liens entre les sous en-
sembles qui collaborent.
Les diagrammes comportementaux
Ces diagrammes représentent la partie dynamique d’un système

réagissant aux événements et permettant de produire les
résultats attendus par les utilisateurs. Sept diagrammes sont
proposés par UML :
Diagramme des cas d’utilisation : est destiné à représenter les
besoins des utilisateurs par rapport au système. Il constitue
un des diagrammes les plus structurants dans l’analyse d’un
système.
Diagramme d’état-transition (machine d’état) : montre les
différents états des objets en réaction aux événements.
Les diagrammes comportementaux
Diagramme d’activités (modifié dans UML 2) : donne une vi-

sion des enchaı̂nements des activités propres à une opération
ou à un cas d’utilisation. Il permet aussi de représenter les
flots de contrôle et les flots de données.
Diagramme global d’interaction (nouveau dans UML 2) :
fournit une vue générale des interactions décrites dans le
diagramme de séquence et des flots de contrôle décrits dans
le diagramme d’activités.
Diagramme de temps (nouveau dans UML 2) : permet de
représenter les états et les interactions d’objets dans un contexte
où le temps a une forte influence sur le comportement du
système à gérer.
Notion d’objet
Introduction
On construit des modèles de systèmes complexes parce que nous

ne pouvons pas comprendre un système dans sa totalité. Des
techniques de modélisation performantes sont nécessaires face à
l’augmentation de la complexité des systèmes. Il y a de
nombreux facteurs à la réussite d’un projet et avoir une
méthodologie rigoureuse est un facteur essentiel. Un langage de
modélisation doit comprendre :
Les éléments du modèle : des concepts de modélisation fon-
damentaux et une sémantique.
Une notation : une interprétation visuelle des éléments du
modèle ;
Notion d’objet
Objets et classes en informatique
Une classe : c’est une abstraction d’objets (ne pas confondre

avec l’abstraction des concepts objets). C’est à dire une
structure qui rassemble des propriétés communes à une
collection d’objets.
Un objet : c’est une entité élémentaire formée de l’union d’un
identifiant, d’un état et d’un comportement
Objet = Identité + Etat + Comportement
Notion d’objet
Objets et classes en informatique
Notion d’objet
Objets et classes en UML
Un objet : Se présente sous la forme d’un rectangle. Dans la

première cartouche se présente figure le nom de l’objet. Dans la
deuxième cartouche se trouve les attributs et leurs valeurs.
Un attribut : Est est constitué d’un couple (nom, valeurs). Les
valeurs prisent par les attributs et les associations qui les relient
déterminent l’état d’un objet a un moment donnée.
Le comportement : Se sont les compétences d’un
objet(Messages envoyées par un autre objet).
Notion d’objet
Les messages en UML
La communication entre objets s’effectue au moyen de messages.
Notion d’objet
Notion de synchronisation
présentation des cas d’utilisation
Un diagramme de cas d’utilisation capture le comportement

d’un système, d’un sous-système, d’une classe ou d’un
composant tel qu’un utilisateur extérieur le voit. Il scinde la
fonctionnalité du système en unités cohérentes, les cas
d’utilisation, ayant un sens pour les acteurs. Les cas
d’utilisation permettent d’exprimer le besoin des utilisateurs
d’un système, ils sont donc une vision orientée utilisateur de ce
besoin au contraire d’une vision informatique.
Il ne faut pas négliger cette première étape pour produire un
logiciel conforme aux attentes des utilisateurs. Pour élaborer les
cas d’utilisation, il faut se fonder sur des entretiens avec les
utilisateurs.
présentation des cas d’utilisation
Les acteurs
Un acteur est un type stéréotypé représentant une abstraction

qui réside juste en dehors du système à modéliser.
Un acteur représente un rôle joué par une personne ou une
chose qui interagit avec le système. (la même personne physique
peut donc être représentée par plusieurs acteurs en fonction des
rôles qu’elle joue).
Les acteurs
Il existe 4 types d’acteurs :

les acteurs principaux : les personnes qui utilisent les fonc-
tions principales du système.
les acteurs secondaires : les personnes qui effectuent des
tâches administratives ou de maintenance , ou encore qui
réagissent aux taches initiés par las acteurs principaux.
le matériel externe : les dispositifs matériels incontournables
qui font partie du domaine de l’application et qui doivent
être utilisés.
les autres systèmes : les systèmes avec lesquels le système
doit interagir.
Le cas d’utilisation
Le cas d’utilisation (ou use case) correspond à un objectif du

système, motivé par un besoin d’un ou plusieurs acteurs.
L’ensemble des use cases décrit les objectifs (le but) du système.
La relation
Elle exprime l’interaction existant entre un acteur et un cas
d’utilisation.
Relation de multiplicité
Les acteurs et les cas d’utilisation sont reliés par des associations
qui peuvent être primaires ou secondaires.
L’association primaire est réservée à l’acteur primaire pour
lequel la fonctionnalité est produite et l’association secondaire
est utilisée pour le ou les acteurs secondaires utilisés par le
système pour réaliser la fonctionnalité.
L’utilisation des multiplicités est possible pour définir le nombre
(0..1, 1, 1..*, 0..*, n, n..m, *) d’utilisations possibles du cas d’uti-
lisation. Cette multiplicité ne donne aucune indication de simul-
tanéité.
La relation
Il existe 3 types de relations entre cas d’utilisation :

la relation de généralisation.
la relation d’extension.
la relation d’inclusion.
La relation de généralisation
Dans une relation de généralisation entre 2 cas d’utilisation, le

cas d’utilisation enfant est une spécialisation du cas d’utilisation
parent.
La relation de généralisation entre acteurs

Un acteur peut également participer à des relations de généralisation
avec d’autres acteurs. Les acteurs enfant seront alors capables
de communiquer avec les mêmes cas d’utilisation que les acteurs
parents .
Le stéréotype include l’inclusion

Elle indique que le cas d’utilisation source contient aussi le com-
portement décrit dans le cas d’utilisation destination. L’inclusion
a un caractère obligatoire, la source spécifiant à quel endroit le cas
d’utilisation cible doit être inclus. Cette relation permet ainsi de
décomposer des comportements et de définir des comportements
partageables entre plusieurs cas d’utilisation.
Pour réaliser l’objectif virement , on utilise obligatoirement

Bennani identification .
Mohamed Taj Faculté des sciences Dhar El Mahraz Fes 50/54
Le stéréotype extendou l’extension
Elle indique que le cas d’utilisation source ajoute son comporte-

ment au cas d’utilisation destination. L’extension peut être sou-
mise à condition. Le comportement ajouté est inséré au niveau
d’un point d’extension défini dans le cas d’utilisation destination.
Cette relation permet de modéliser les variantes de comporte-
ment d’un cas d’utilisation (selon les interactions des acteurs et
l’environnement du système).
Le stéréotype extendou l’extension
Dans cet exemple le Virement peut parfois utiliser la vérification

du solde. Cependant, c’est pas une obligation.
Exemple d’application
Dans un établissement scolaire, on désire gérer la réservation des

salles de cours ainsi que du matériel pédagogique (ordinateur
portable ou/et Vidéo projecteur). Seuls les enseignants sont ha-
bilités à effectuer des réservations (sous réserve de disponibilité
de la salle ou du matériel). Le planning des salles peut quant à
lui être consulté par tout le monde (enseignants et étudiants).
Par contre, le récapitulatif horaire par enseignant (calculé à par-
tir du planning des salles) ne peut être consulté que par les en-
seignants. Enfin, il existe pour chaque formation un enseignant
responsable qui seul peut éditer le récapitulatif horaire pour l’en-
semble de la formation.
Modéliser cette situation par un diagramme de cas d’utilisation.
Correction de l’exemple d’application

Cours 3 PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours 3 PDF

Transféré par

Droits d'auteur :

Formats disponibles

Méthode de conception Orientée Objet UML

Méthode de conception Orientée Objet

Bennani Mohamed Taj

Faculté des sciences Dhar El Mahraz Fes 1/54

L’appréhension d’une problématique complexe telle que

Depuis longtemps, le langage UML (Unified Modelling Lan-

Depuis plus de 30 ans, la conception des bases de données

Présentation du génie logiciel

Définition d’un logiciel

Objectifs du génie logiciel

Les phases de réalisation d’un logiciel

La réalisation d’un logiciel se résume en 6 phases :

Pour créer un nouveau logiciel, On effectue l’étude de faisabilité

Le Cahier des charges est une phase importante qui permet de :

Une fois la conception terminée et validée, la réalisation du

La spécification consiste à décrire toutes les spécifications :

La validation sert à vérifier chaque module.

Il faut garder la trace de ce qui a été fait.

La phase de mise en place

Maintenant que le logiciel est réalisé (l’exécutable obtenu),

Une fois le logiciel est en place, son exploitation devient fon-

Une fois les erreurs détectées, il faut passer à la correction

Malgré toutes les maintenances réalisées, le logiciel ne peut

UML (Unified Modeling Language) est normalisé par l’OMG

Un modèle est une représentation partielle de la réalité.

L’utilité des modèles

Faciliter la compréhension d’un système :

Afin d’assurer un bon niveau de cohérence et d’homogénéité

Les différents types de diagrammes

UML, dans sa version 2, propose 13 diagrammes qui peuvent

Les diagrammes Structurels.

Diagrammes selon les axes de modélisation

Hiérarchie des diagrammes UML

Les 5 vues de Kruchten

Les diagrammes structurelles

Ces diagrammes, au nombre de six, ont vocation à représenter

Les diagrammes structurelles

Diagramme de déploiement (modifié dans UML 2) : décrit

Les diagrammes comportementaux

Ces diagrammes représentent la partie dynamique d’un système

Les diagrammes comportementaux

Diagramme d’activités (modifié dans UML 2) : donne une vi-

On construit des modèles de systèmes complexes parce que nous

Objets et classes en informatique

Une classe : c’est une abstraction d’objets (ne pas confondre

Objets et classes en informatique

Objets et classes en UML

Un objet : Se présente sous la forme d’un rectangle. Dans la

Les messages en UML

La communication entre objets s’effectue au moyen de messages.

présentation des cas d’utilisation

Un diagramme de cas d’utilisation capture le comportement

présentation des cas d’utilisation

Un acteur est un type stéréotypé représentant une abstraction

Il existe 4 types d’acteurs :

Le cas d’utilisation (ou use case) correspond à un objectif du

Il existe 3 types de relations entre cas d’utilisation :

Dans une relation de généralisation entre 2 cas d’utilisation, le

La relation de généralisation entre acteurs

Le stéréotype include l’inclusion

Pour réaliser l’objectif  virement  , on utilise obligatoirement

Le stéréotype extendou l’extension

Elle indique que le cas d’utilisation source ajoute son comporte-

Pour réaliser l’objectif virement , on utilise obligatoirement