Cours 2 UML C'est Quoi Pourquoi Modéliser

UML ? MODÉLISER ?
FGST
Business Plan Google Slides Template
Analyse et conception orientée objet
www.elbahihassan.com
[email protected] ISTA Oulad Teima

Pourquoi modéliser ?
● Modéliser, c’est décrire de manière visuelle et graphique les besoins et, les solutions
fonctionnelles et techniques de votre projet logiciel. Mais modéliser pour quoi faire ?
● Avez-vous déjà eu à constituer un meuble en kit? Cette tâche sera très difficile
constituons page de texte.
3
Hassan EL BAHI www.elbahihassan.com ISTA OULED TEIMA
● Toutefois, vous serez d’accord que c’est plus facile à partir de schéma plutôt qu’une page
de texte.
● Cet exemple nous démontre que l’utilisation de schémas et d’illustrations rend quelque
chose de complexe plus compréhensible.
4
● C’est exactement ce à quoi UML sert dans des projets de réalisation de logiciels.
● Un document de texte décrivant de façon précise ce qui doit être réalisé contiendrait
plusieurs dizaines de pages. En général, peu de personnes ont envie de lire ce genre de
document. De plus, un long texte de plusieurs pages est source d’interprétations et
d’incompréhension.
● UML nous aide à faire cette description de façon graphique et devient alors un excellent
moyen pour « visualiser » le(s) futur(s) logiciel(s).
5
● Un logiciel qui a été réalisé sans analyse et sans conception (étapes où l’on modélise le
futur logiciel) risque lui aussi de ne pas répondre aux besoins, de comporter des
anomalies et d’être très difficile à maintenir.
● Tout comme la construction d’une maison nécessite des plans à différents niveaux
(vision extérieure, plan des différents étages, plans techniques…), la réalisation d’un
logiciel ou d’un ensemble de logiciels a besoin d’un certain nombre de diagrammes.
6
Méthodes de conception
On parle principalement de trois types de méthodes de conception :
MÉTHODES MÉTHODES MÉTHODES ORIENTÉES

FONCTIONNELLES SYSTÉMIQUES OBJETS
• SADT, • MERISE,
• Warnier, • AXIAL, • UML
• ... • ...
7
Méthodes fonctionnelles
● Les méthodes fonctionnelles (également qualifiées de méthodes structurées) trouvent

leur origine dans les langages procéduraux. Elles mettent en évidence les fonctions à
assurer et proposent une approche hiérarchique descendante et modulaire.
● Les méthodes fonctionnelles ou cartésiennes consistent à décomposer
hiérarchiquement une application en un ensemble de sous applications. Les fonctions de
chacune de ces dernières sont affinées successivement en sous fonctions simples à
coder dans un langage de programmation donné.
8
Représentation graphique d'une approche fonctionnelle.

9
Les points forts des méthodes fonctionnelles sont les suivants :

● Simplicité du processus de conception préconisé,
● Capacité à répondre rapidement aux besoins ponctuels de leurs utilisateurs.
Les points faibles des méthodes fonctionnelles sont les suivants :

● Une simple mise à jour du logiciel à un point donné, peut impacter en cascade une
multitude d'autres fonctions.
● Éventuelle redondance des données
10
Méthodes systémiques
● Les méthodes systémiques proposent une double démarche de modélisation : la

modélisation des données et celle des traitements. Elle est influencée par les systèmes
de gestion de bases de données.
● MERISE est un exemple d’une méthode systémique. Elle permet de faire l'analyse et la
conception des systèmes d'information basée sur le principe de la séparation des
données et des traitements.
● Elle possède plusieurs modèles qui sont répartis sur 3 niveaux : Le niveau conceptuel, le
niveau logique ou organisationnel, le niveau physique.
11
Méthodes systémiques
Les points forts des méthodes systémiques sont les suivants :

● Approche globale qui prend en compte la modélisation des données et des traitements.
● Introduction des niveaux d'abstraction dans le processus de conception (niveau
conceptuel, niveau logique et niveau physique),
Les points faibles des méthodes systémiques sont les suivants :

● Double démarche de conception : les données et les traitements.
● Pas de fusion possible des deux aspects (données et traitements).
12
Méthodes fonctionnelles et systémiques
● Les méthodes fonctionnelles et systémiques sont potentiellement de type descendant.

● Elles ne favorisent pas les critères de :
○ Réutilisabilité : les modules ne sont pas généraux, mais adaptés aux sous problèmes pour
lesquels ils ont été conçus.
○ Extensibilité : l'architecture du logiciel est fondée sur les traitements. Or ces derniers sont
moins stables que les données d'où cette approche est inadaptée à la conception de gros
logiciels.
13
Méthodes orientées objets
● L'approche orientée objet considère le logiciel comme une collection d'objets dissociés
définis par des propriétés. Une propriété est soit un attribut soit une opération. Un objet
comprend donc à la fois une structure de données et une collection d'opérations (son
comportement).
14
Vendeur de véhicules
Voiture Bâton sauteur Bicyclette
Voiture de sport voiture familiale

15
16
● L'approche orientée objet est potentiellement de type ascendant : un effort de

regroupement basé sur l'abstraction des données est entretenu tout au long du
processus de conception.
● En effet, on commence par l'identification des objets. Ces objets sont regroupés dans
des classes selon leurs propriétés. Ensuite ces classes sont à nouveau regroupées en
classes plus abstraites appelées modules ou sous-systèmes jusqu'à la modélisation du
problème posé.
17
Les points forts des méthodes orientées objets sont les suivants :
● Intégrer dans l'objet des données et des traitements
● Profiter des avantages des concepts objets : phase d'analyse et de conception
● Prendre en compte une plus large gamme d'applications
● Favoriser la conception et la réutilisation des composants : concevoir dans un but de
réutilisation et non pas pour répondre à un besoin ponctuel.
● Améliorer la productivité et la rentabilité en utilisant des bibliothèques de composants
réutilisables
● Simplifier le passage conceptuel/physique.
● Faciliter le prototypage.
18
Principes fondamentaux d'une approche objet.
• L’approche objet est une démarche qui s’organise autour de 4 principes fondamentaux.
C’est une démarche :
CENTRÉE SUR
ITÉRATIVE ET
L’ARCHITECTURE DU
INCRÉMENTALE
LOGICIEL
GUIDÉE PAR LES BESOINS DÉCRIT LES ACTIONS ET

DU CLIENT ET DES LES INFORMATIONS DANS
UTILISATEURS UNE SEULE ENTITÉ
19
Itérative et incrémentale
● La modélisation d’un logiciel se fera en plusieurs fois.

● Les diagrammes ne seront pas réalisés de façon complètement satisfaisante dès la
première fois. Il nous faudra plusieurs versions d’un même diagramme pour obtenir la
version finale.
● Chaque version est le fruit d’une itération (un nouveau passage sur les diagrammes).
● Une itération permet donc d’affiner la compréhension du futur logiciel.
20
Guidée par les Besoins du client
● Les besoins d’un client, dans un projet logiciel sont les exigences exprimées par le client
au niveau des fonctionnalités, du rendu et des actions d’un logiciel.
● Par exemple, lors de la réalisation du progiciel Word, les clients ont probablement
souhaité un logiciel qui leur permettrait d’écrire du texte, de l’effacer, d’intégrer des
images, enregistrer le contenu, le supprimer, etc.
21
Guidée par les Besoins du client
Les besoins des utilisateurs servent de fil rouge, tout au long du cycle de développement :
● Lors de la phase d'analyse pour la clarification, l’affinage et la validation des besoins des
utilisateurs ;
● Lors de la phase de conception et de réalisation pour la vérification de la prise en compte
des besoins des utilisateurs ;
● Lors de la phase de test afin de garantir la satisfaction des besoins.
22
Centrée sur l'architecture du logiciel
● L’architecture logicielle décrit les choix stratégiques qui déterminent en grande partie les
qualités du logiciel (adaptabilité, performances, fiabilité...).
● On peut citer l’architecture client serveur.
23
Entité = Informations + actions
● Les différents diagrammes utilisés en UML donnent tous une vision particulière du
logiciel à développer.
● Parmi ces diagrammes, il en est un qui représente particulièrement bien ce qui est à
développer si on opte pour un développement objet. Il s’agit du diagramme de classes.
● le diagramme de classes donnera une vision assez claire des informations qui seront
utilisées par le logiciel, mais également des fonctions (ou opérations) qui devront
s’appuyer sur ces informations.
● L’approche objet mélange donc habillement l’analyse des informations et des actions au
lieu de les analyser séparément.
24
Projet informatique
● Un projet informatique nécessite une phase d’analyse, suivi d’une étape de conception.
ANALYSE CONCEPTION
25
La phase d’analyse
● Dans cette phase, on cherche d’abord à bien comprendre et à décrire de façon précise les
besoins des utilisateurs ou des clients.
○ Que souhaitent-ils faire avec le logiciel ?
○ Quelles fonctionnalités veulent-ils ?
○ Pour quel usage ?
○ Comment l’action devrait-elle fonctionner ?

● C’est ce qu’on appelle « l’analyse des besoins ». Après validation de notre compréhension
du besoin, nous imaginons la solution. C’est la partie analyse de la solution.
26
La phase de conception
● Dans cette phase, on apporte plus de détails à la solution et on cherche à clarifier des
aspects techniques, tels que l’installation des différentes parties logicielles à installer sur
du matériel.
● Pour réaliser ces deux phases dans un projet informatique, nous utilisons des méthodes,
des conventions et des notations. UML fait partie des notations les plus utilisées
aujourd’hui.
27
Langage UML
● UML, c’est l’acronyme anglais pour « Unified Modeling Language ». On le traduit par «
Langage de modélisation unifié ».
● UML est né de la fusion des trois méthodes qui ont influencé la modélisation objet au
milieu des années 90 : OMT, Booch et OOSE.
● Il est proposé par : Grady Booch, James Rumbaugh et Ivar Jacobson.
28
Langage UML
● UML est surtout utilisé lorsqu’on prévoit de développer des applications avec une
démarche objet (développement en Java, en C++, etc.).
● La notation UML est un langage visuel constitué d’un ensemble de schémas, appelés des
diagrammes, qui donnent chacun une vision différente du projet à traiter.
● UML nous fournit donc des diagrammes pour représenter le logiciel à développer : son
fonctionnement, sa mise en route, les actions susceptibles d’être effectuées par le
logiciel, etc..
29
Langage UML
● Réaliser ces diagrammes revient donc à modéliser les

besoins du logiciel à développer.
● Le langage UML ne demande aucune démarche, ce n’est donc
pas une méthode.
● Chacun est libre d’utiliser les types de diagramme qu’il
souhaite, dans l’ordre qu’il veut.
● Il suffit que les diagrammes réalisés soient cohérents entre
eux, avant de passer à la réalisation du logiciel.
30
Positionnement de ce cours
ANALYSE CONCEPTION
Analyse des besoins Analyse du domaine Analyse applicative Conception de la solution
Diagramme de Diagramme des cas Diagramme de Affichage de tous

contexte d'utilisation détaillé séquence les diagrammes
Diagramme des Diagramme Diagramme Diagramme de

cas d'utilisation d'activité états-transitions composants
Diagramme Diagramme de Diagramme de

de classes collaboration déploiement
31
Résumé
● UML c’est un langage de modélisation qui permet de représenter graphiquement les

besoins des utilisateurs. On utilise pour cela des diagrammes.
● UML est une démarche qui se base sur une approche objet. Cette approche s’appuie sur
4 principes fondamentaux :
○ L’approche objet nécessite une démarche itérative et incrémentale.
○ L’approche objet est guidée par les besoins du client.
○ La démarche est également centrée sur l'architecture du logiciel.
○ L’approche objet décrit les informations et les actions dans une seul entité.
32

Cours 2 UML C'est Quoi Pourquoi Modéliser

Transféré par

Droits d'auteur :

Formats disponibles

Cours 2 UML C'est Quoi Pourquoi Modéliser

Transféré par

Informations du document

Description originale:

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 2 UML C'est Quoi Pourquoi Modéliser

Transféré par

Droits d'auteur :

Formats disponibles

UML ? MODÉLISER ?

[email protected] ISTA Oulad Teima

On parle principalement de trois types de méthodes de conception :

MÉTHODES MÉTHODES MÉTHODES ORIENTÉES

● Les méthodes fonctionnelles (également qualifiées de méthodes structurées) trouvent

Représentation graphique d'une approche fonctionnelle.

Les points forts des méthodes fonctionnelles sont les suivants :

Les points faibles des méthodes fonctionnelles sont les suivants :

● Les méthodes systémiques proposent une double démarche de modélisation : la

Les points forts des méthodes systémiques sont les suivants :

Les points faibles des méthodes systémiques sont les suivants :

● Les méthodes fonctionnelles et systémiques sont potentiellement de type descendant.

Voiture Bâton sauteur Bicyclette

Voiture de sport voiture familiale

● L'approche orientée objet est potentiellement de type ascendant : un effort de

GUIDÉE PAR LES BESOINS DÉCRIT LES ACTIONS ET

● La modélisation d’un logiciel se fera en plusieurs fois.

○ Que souhaitent-ils faire avec le logiciel ?

○ Quelles fonctionnalités veulent-ils ?

○ Pour quel usage ?

○ Comment l’action devrait-elle fonctionner ?

● Réaliser ces diagrammes revient donc à modéliser les

Diagramme de Diagramme des cas Diagramme de Affichage de tous

Diagramme des Diagramme Diagramme Diagramme de

Diagramme Diagramme de Diagramme de

● UML c’est un langage de modélisation qui permet de représenter graphiquement les

○ L’approche objet nécessite une démarche itérative et incrémentale.

○ L’approche objet est guidée par les besoins du client.

○ La démarche est également centrée sur l'architecture du logiciel.

Vous aimerez peut-être aussi