Modlisation Oriente Objet UML Laurent Henocque http laurent

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: //www. sparxsystems. com. au/resourc es/uml 2_tutorial/index. html

Objectifs • Présenter une vision globale du problème et des enjeux de la modélisation jusqu'à UML 2 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 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

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 : Aspect. J

Historique UML

Evolution • 2003 : UML 1. 5 • 2004 : UML 2. 0