Modélisation Orientée Objet / UML

Modélisation Orientée Objet / UML
Laurent Henocque
http://laurent.henocque.free.fr/
Enseignant Chercheur ESIL/INFO France
http://laurent.henocque.perso.esil.univmed.fr/
mis à jour en Octobre 2006
Licence Creative Commons
Cette création est mise à disposition selon le Contrat
Paternité-Partage des Conditions Initiales à
l'Identique 2.0 France disponible en ligne
http://creativecommons.org/licenses/by-sa/2.0/fr/
ou par courrier postal à Creative Commons, 559
Nathan Abbott Way, Stanford, California 94305,
USA.
Références Normatives
•
•
•
•
•
•
L'infrastructure UML
http://www.omg.org/cgi-bin/doc?formal/05-07-05
La superstructure UML
http://www.omg.org/cgi-bin/doc?formal/05-07-04
OCL
http://www.omg.org/cgi-bin/doc?ptc/05-06-06
Autres références
• Ce support de cours s'appuie sur des exemples
concrets mis à disposition librement sur internet
par différentes sources
– http://www.rational.com
– http://www.visualuml.com
– http://uml.free.fr
– http://http://www.sparxsystems.com.au/resourc
es/uml2_tutorial/index.html
Objectifs
• Présenter une vision globale du problème et
des enjeux de la modélisation jusqu'à
UML2 avec des exemples visuels.
Abstractions et Modèles
Qu'est ce qu'un modèle
Modèle <> Abstraction
• Un modèle est une représentation de la
réalité faisant abstraction de larges niveaux
de détail.
• S'il n'y a pas d'abstraction, il n'y a pas de
modèle : on parle de la réalité
• Exemple de modèle : une maquette
d'architecte
Abstractions et Modèles
Modèle <> Point de vue
• Un même problème peut avoir des modèles
selon de très nombreux points de vue
• On s'intéresse alors seulement à un aspect
du problème
• Par exemple : le schéma électrique d'un
bâtiment en architecture
Abstractions et Modèles
Modèle <> Spécification
• Les modèles ont pour utilité première de
décrire, pour communiquer
• Si l'on décrit pour communiquer avant de
construire, le modèle tient lieu de document
de spécification ou de conception
Modélisation en Informatique
Pour la conception :
• diagramme d'activités décrivant un
algorithme
• diagramme décrivant des classes avec leurs
relations héritage et les associations
• un fichier ".h" déclarant des structures,
fonctions, classes et méthodes sans préciser
leur implantation
Modélisation en Informatique
Pour la spécification
• diagrammes de cas d'utilisation
• diagrammes de séquence
• diagrammes de composants
• diagrammes de déploiement
• diagrammes d'architecture
• ...
Anciennes méthodes de
Modélisation
Merise
• Une méthode conçue pour décrire des bases
de données
• Permet de voir la base d'un coup d'œil, et de
réfléchir aux optimisations à lui apporter
(mise sous forme normale par exemple)
Merise
Merise
Merise avec Windev
Avantages / Inconvénients
• Merise n'est pas orientée objet (même si des
évolutions en ce sens sont apparues en même
temps que d'autres méthodes plus populaires
aujourd'hui)
– diagrammes lourds
– manque d'abstraction
– ce n'est pas une méthode cognitive mais une méthode
technique
• Très bien adaptée aux BD conventionnelles et
encore très utilisée
La méthode OOA
Object Oriented Analysis (Analyse Orientée
Objet)
• Inventée par Grady Booch
• Une des premières méthodes
"conceptuelles" ou cognitives
• Née dans le sillage du langage ADA
• Aujourd'hui noyée dans la méthode UML
OOA
Booch
• héritage
• associations
• multiplicités
OOA
différents
types de
relations
OOA
Avantages / Inconvénients
• Prise en compte de l'héritage
• Trop incomplète pour s'intégrer dans le
processus logiciel plus loin que dans
l'analyse (spécification avancée)
La méthode OMT
• Object Modeling Technique (Technique de
Modélisation Objet)
• Inventée par Rumbaugh
• Tournée vers la conception
• Orientée Objet
OMT
Rumbaugh
• héritage
• associations
• attributs
• méthodes
• paramètres
• accès (public
privé)
OMT
• permet la
génération
de code
Avantages / Inconvénients
• A fait apparaître l'utilisation combinée de
plusieurs diagrammes : diagrammes de classes /
diagrammes d'états / diagrammes de flots
• A décrit le processus de raffinement d'un modèle
• Les diagrammes de flots de UML n'ont jamais été
bien expliquée
• La méthode est trop près du programme
La méthode OOSE
• Object Oriented Software Engineering
• Inventée par Jacobson
• Une méthode pour l'analyse intitiale des
usages de logiciel, fondée sur les "Cas
d'utilisation" (Use case)
OOSE
Jacobson
OOSE : vue objet
• entités
• contrôle
• interfaces
OOSE Messages
OOSE
Avantages / Inconvénients
• OOSE fournit la méthode permettant
d'initier le processus de spécification /
conception
• Aucun support pour faire évoluer la
spécification vers une conception
• Ses diagrammes de composants et de flots
ne sont pas convaincants
La méthode Objecteering
• Une méthode orientée objet, propriétaire (la
société française Softeam),
• Populaire car elle était associée à un outil
de "design", capable de générer du code
• En ce sens un premier vrai challenger
orienté objet à Merise
Objecteering
Objecteering
Aujourd'hui UML 2.0
• Fusion de OOA / OOSE / OMT
• Un standard de l' OMG
• Associée à des outils : Rational Rose /
Poséidon / Borland Together / ...
• Couvre tous les aspects de la spécification,
de l'analyse la plus initiale en passant par la
génération de code au déploiement
• Très riche méthode cognitive
Approche fonctionnelle vs objet
Modularité
• Une modification élémentaire du modèle ne
doit pas engendrer de modifications
globales du logiciel
Approche Fonctionnelle
• L'approche du développement logiciel centrée sur
les fonctions est non modulaire :
• Un changement dans les données se répercute en
des changements massifs et diffus dans le code
• Exemple : gestion de bibliothèque : on doit
prendre en compte un nouveau type de média
(vidéo par exemple)
Impact des changements
Vue 4 plus 1
• Point de vue moderne sur le logiciel (plus
de fonctions)
Impact sur les Processus
• Permet de mieux
séparer des
activités qui sinon
auraient été trop
interdépendantes
Les aspects : un souci moderne de
modularité
• Un exemple moderne de prise en compte de
la modularité : la programmation orientée
aspect
• Un aspect décrit des mécanismes ou des
données qui s'étendent sur des ensembles de
classes, indépendamment de la hiérarchie
• Exemple : le profiling
• Les aspects pour Java : AspectJ
Historique UML
Evolution
• 2003 : UML 1.5
• 2004 : UML 2.0