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/resources/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