Modélisation Orientée Objet / UML

Laurent Henocquehttp://laurent.henocque.free.fr/

Enseignant Chercheur ESIL/INFO Francehttp://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 derelations

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

OMTRumbaugh

• héritage• associations• attributs• méthodes• paramètres• accès (publicprivé)

OMT

• permet lagénérationde 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)

OOSEJacobson

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