UML
Chapitre 2 Introduction
Projet informatique
Un projet informatique nécessite une phase d’analyse, suivi d’une étape de
conception
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.
La phase de conception
▪ La phase de conception vise à décrire de manière précise et détaillée
comment le logiciel sera construit pour répondre aux besoins identifiés
lors de la phase d'analyse.
▪ Le résultat final de la phase de conception est souvent un ensemble
de spécifications techniques, de modeles et de plans qui seront utilisés
dans la phase de développement pour construire le système.
Pourquoi modéliser ?
▪ Modéliser, c’est décrire de manière visuelle et graphique les
besoins et, les solutions fonctionnelles et techniques du 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.
Pourquoi modéliser ?
▪ 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.
Pourquoi modéliser ?
▪ Un logiciel qui a été réalisé sans analyse et sans conception risque 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.
Pourquoi modéliser ?
Un modèle est une simplification de la réalité qui permet de mieux
comprendre le système à développer.
Il permet :
▪ De visualiser le système comme il est ou devrait être ;
▪ De valider le modèle vis à vis des clients ;
▪ De spécifier les structures de données et le comportement du système ;
▪ De fournir un guide pour la construction du système ;
▪ De documenter le système et les décisions prises.
Méthodes de conception
▪ Le développement de logiciels implique une série d'étapes critiques,
au cœur desquelles se trouvent l'analyse et la conception.
▪ Ces phases sont cruciales pour définir les besoins, les fonctionnalités
attendues du système, et la manière dont ces fonctionnalités seront
techniquement mises en œuvre.
▪ Dans ce contexte, les méthodes de conception jouent un rôle
fondamental en offrant des cadres et des pratiques pour la
modélisation et le développement logiciel de manière structurée et
efficace.
Méthodes de conception
Trois approches dominent le paysage de la conception logicielle
Chacune propose une vision et des techniques spécifiques pour la modélisation et
l'implémentation des systèmes logiciels
Méthodes fonctionnelles
(années 70)
▪ La modélisation via les méthodes fonctionnelles ou la programmation
fonctionnelle consiste à diviser le problème en un ensemble de fonctions
avec une séparation complète des données et des méthodes
▪ Cette approche met l'accent sur la manière dont les données sont
transformées en utilisant des fonctions et sur la construction de logiciels en
composant ces fonctions.
▪ Ainsi une application est décomposée hiérarchiquement 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é.
Méthodes fonctionnelles
(années 70)
Représentation graphique d'une approche fonctionnelle
Méthodes fonctionnelles
▪ La première étape dans la modélisation fonctionnelle est de décomposer le
problème global en une série de sous-problèmes plus petits, chacun pouvant
être résolu par une fonction spécifique.
▪ Cette division est guidée par la nature du problème et par l'objectif de créer
des fonctions qui sont:
- Cohérentes : Chaque fonction a un objectif clair et bien défini.
- Composables : Les fonctions peuvent être combinées de
diverse manières pour construire des solutions à des problèmes plus
complexes.
- Réutilisables : Les fonctions sont conçues pour être génériques
et indépendantes de leur contexte peur être réutilisées dans
différents scénarios.
Méthodes fonctionnelles
Avantages
▪ Simplicité : La programmation fonctionnelle favorise une conception claire, rendant
le processus de développement plus simple et plus direct.
▪ Réactivité : Elle permet une réponse rapide aux besoins spécifiques grâce à la
réutilisation et à la composition facile des fonctions.
Inconvénients
▪ Volume de Code : Le code peut devenir volumineux et moins clair, surtout pour des
programmes complexes, en raison de la nécessité de définir de nombreuses
fonctions.
▪ Difficultés d‘optimisation et d‘extension : Il peut être plus difficile d'optimiser et
d'étendre le code, particulièrement quand les exigences du projet évoluent ou
deviennent plus complexes.
Méthodes systémiques
(années 80)
▪ Les méthodes systémiques sont orientées vers une vision globale du SI
d'information à concevoir, plutôt que vers une vision purement fonctionnelle.
▪ Elle 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.
▪ La méthodologie Merise propose une approche structurée pour décrire les
différents niveaux d'abstraction d'un SI, en prenant en compte à la fois les
aspects fonctionnels, organisationnels et techniques.
Méthodes systémiques
▪ Avantages :
- Merise propose une structuration du projet en modules, facilitant ainsi la gestion de sa
complexité et met un fort accent sur l'analyse des besoins des utilisateurs, assurant
que les solutions développées répondent précisément à leurs attentes
- Grâce à sa structure modulaire et à ses différents niveaux de modélisation
(conceptuel, logique, et physique), Merise s'adapte bien à divers types de projets, des
plus simples aux plus complexes.
▪ Inconvénients :
- Merise est considérée comme une méthode rigide et lourde vue qu’elle suit une
approche très structurée et descendante de la conception des SI
- La méthode Merise, avec sa séparation stricte entre données et traitements, présente
un défi pour le développement de systèmes complexes. Cette division peut rendre le
processus de conception moins fluide, surtout dans des cas où les données et les
traitements sont fortement interdépendants.
Méthodes orientées objets
▪ Les méthodes OO ou la POO est un paradigme de programmation qui
modélise les logiciels autour d'objets représentant des entités ou des
concepts du monde réel.
▪ Chaque objet encapsule à la fois des données (attributs) et des
comportements (méthodes) qui opèrent sur ces données.
▪ L'une des particularités de cette approche est qu'elle rapproche les données
et leurs traitements associés au sein d'un unique objet.
Méthodes orientées objets
La modélisation basés sur les méthodes orientée objet :
▪ Reflète la manière dont nous percevons le monde réel, avec des entités
ayant à la fois des caractéristiques et des capacités. Cela rend le code
plus intuitif et facile à comprendre.
▪ Conduit à des architectures logicielles fondées sur les objets du
système, plutôt que sur la fonction qu'il est censé réaliser
▪ Consiste à créer une représentation abstraite, sous forme d'objets,
d'entités ayant une existence matérielle ou virtuelle (chien, voiture,
personne, séance…)
Méthodes orientées objets
Méthodes orientées objets
Méthodes orientées objets
▪ 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é.
Méthodes orientées objets
Les concepts de base
▪ Objets : unités de base organisées en classes et partageant des
traits communs (attributs ou procédures). Peuvent être des entités du
monde réel, des concepts de l’application ou du domaine traité.
▪ Encapsulation :
- Les structures de données et les détails de l’implémentation sont
cachés aux autres objets du système.
- La seule façon d’accéder à l’état d’un objet est de lui envoyer un
message qui déclenche l’exécution de l’une de ses méthodes
publics.
Méthodes orientées objets
Les concepts de base
▪ Héritage : chaque instance d’une classe d’objet hérite des caractéristiques
(attributs et méthodes) de sa classe mais aussi d’une éventuelle super-classe.
L’héritage est un des moyens d’organiser le monde c.-à-d. de décrire les liens
qui unissent les différents objets
▪ Polymorphisme : possibilité de recourir à la même expression pour dénoter
différentes opérations. L’héritage est une forme particulière du polymorphisme
caractéristique des systèmes orientés objet
Méthodes orientées objets
Les points forts des méthodes orientées objets sont les suivants :
▪ Intégrer dans l'objet des données et des traitements
▪ Permet de mieux organiser son code & facilite le travail coopératif et la
maintenance à long terme.
▪ 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
L'émergence des méthodes objet
(années 1990-1995)
▪ L'émergence des méthodes de modélisation orientée objet conduit à la création
de nombreux langages de modélisation OO (Plus de 50 méthodes oo sont
apparues durant cette période (Booch, Classe-Relation, Fusion, HOOD, OMT,
OOA, OOD, OOM,OOSE...)! Mais aucun méthode ne s'est réellement imposée.
▪ Trois méthodologies principales dominent le scène :
- La méthode de modélisation des objets de Grady Booch (Booch method),
- la méthode d'analyse et de conception orientée objet (Object Modeling
Technique, OMT) de James Rumbaugh,
- et la méthode de modélisation des classes et des objets (Object-Oriented
Software Engineering, OOSE) d'Ivar Jacobson.
L'unification et la normalisation des méthodes
▪ En octobre 1994 : G. Booch (père fondateur de la méthode Booch) et J.
Rumbaugh (principal auteur de la méthode OMT) ont décidé de travailler
ensemble pour unifier leurs méthodes au sein de la société Rational
Software.
▪ Un an après : I . Jacobson (auteur de la méthode OOSE et des cas
d’utilisation) a rejoint Rational Software pour travailler avec G. Booch et J.
Rumbaugh souvent appelés "les Trois Amigos« pour unifier leurs
méthodes respectives. Cette collaboration vise à développer un langage
de modélisation standard
▪ Juin 1996 : La première version de l'UML, UML 0.9, est proposée au
public
UML 2 2004
Soumission OMG UML 1.3 juin 1999
UML 1.2 juin 1998
Standardisation OMG Novembre 1997
Soumission OMG UML 1.1
Septembre 1997
Soumission OMG UML 1.0 Janvier 1997
OOPSLA ‘ 96 UML 0.9
Juin 1996
OOPSLA ‘ 95 Méthode Unifiée 0.8 Octobre 1995
Booch ’93 OMT-2
Autres méthodes Booch ’91 OMT-1 OOSE Partenaires : IBM, HP, Microsoft, Oracle
OMG (Object Management Group) est une organisation internationale composée de membres provenant de diverses industries et
gouvernements, travaillant ensemble pour développer des normes et des spécifications pour les technologies de l'information et de
la communication (TIC).
Langage UML
UML permet de modéliser toutes les
étapes du développement d’une
application de l’analyse au
déploiement (en utilisant plusieurs
diagrammes).
Le langage UML
▪ UML, c’est l’acronyme anglais pour « Unified Modeling Language ». On le
traduit par « Langage de modélisation unifié ».
▪ L’UML a été conçu avec l'objectif principal de fournir un langage de
modélisation standardisé pour aider les développeurs de logiciels dans la
spécification, la visualisation, la construction et la documentation des aspects
des systèmes logiciels.
▪ Proposé par Grady Booch, James Rumbaugh et Ivar Jacobson et 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.
Langage UML
UML : Unified Modeling Language
▪ Un langage de modélisation unifié
▪ Ce n’est pas un langage de programmation
▪ Indépendant de tout langage de programmation (objet ou autre)
▪ Un langage basé sur des notations graphiques
▪ Constitués de plusieurs graphes (diagrammes) permettant de visualiser la
future application de plusieurs angles différents
▪ Une norme maintenue par l’OMG (Object Management Group : organisation
mondiale créée en 1989 pour standardiser le modèle objet)
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.
▪ Réaliser ces diagrammes revient donc à modéliser les besoins du logiciel
à développer.
Langage UML
▪ 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.
UML
▪ 14 diagrammes depuis UML 2.3 classés en deux catégories
▪ 7 diagrammes de structure (statiques) :
- Qui sont utilisés pour représenter les aspects statiques d'un système,
c'est-à-dire les entités et les relations qui composent le système.
- Ces diagrammes permettent de modéliser la structure statique du
système, tels que les classes, les objets, les interfaces, les packages,
etc.
- Les principaux diagrammes de structure d'UML sont les diagrammes
de classes, les diagrammes d'objets, les diagrammes de composants,
les diagrammes de déploiement et les diagrammes de paquetages.
UML
▪ 7 diagrammes de comportement (dynamiques) :
- Les diagrammes de comportement, quant à eux, sont utilisés pour
représenter les aspects dynamiques d'un système, c'est-à-dire le
comportement du système au fil du temps.
- Ces diagrammes permettent de modéliser les interactions entre les
entités du système, les flux de contrôle, les états et les événements.
- Les principaux diagrammes de comportement d'UML sont les
diagrammes de cas d'utilisation, les diagrammes de séquence, les
diagrammes d'activités, les diagrammes d'états-transitions et les
diagrammes de communication..
UML
UML
UML
Notations communes :
▪ Classeur : a une forme rectangulaire et permet de représenter les classes dans un
diagramme UML
▪ Package (paquetage) : est un regroupement de éléments de système ou de diagrammes
▪ Stéréotype : annotation entourée par <<nomAnnotation>> permettant d’ajouter une
précision sur l’ élément annote
Classeur Package Stéréotype
UML
Les flèches en UML
Association bidirectionnelle
Association unidirectionnelle
Dépendance
Héritage
Implémentation
Agrégation
Composition
UML
❖ Quelques logiciels pour faire la modélisation UML :
▪ Power Designer (payant - version d’essai 30 jours)
▪ StarUML
▪ BoUML
▪ Visual Paradigm (payant - version d’essai 30 jours)
▪ Astah (payant - version d’essai 30 jours)
▪ ArgoUML (Open source)
▪ PlantUML