Modélisation Orientée Objet / UML

Présentation au sujet: "Modélisation Orientée Objet / UML"— Transcription de la présentation:

1 Modélisation Orientée Objet / UML
Laurent Henocque Enseignant Chercheur ESIL/INFO France mis à jour en Octobre 2006

2 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 ou par courrier postal à Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.

3 Références Normatives
L'infrastructure UML La superstructure UML OCL

4 Autres références Ce support de cours s'appuie sur des exemples concrets mis à disposition librement sur internet par différentes sources

5 Objectifs Présenter une vision globale du problème et des enjeux de la modélisation jusqu'à UML2 avec des exemples visuels.

6 Abstractions et Modèles
Qu'est ce qu'un modèle

7 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

8 Abstractions et Modèles

9 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

10 Abstractions et Modèles

11 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

12 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

13 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 ...

14 Anciennes méthodes de Modélisation

15 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)

16 Merise

17 Merise

18 Merise avec Windev

19 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

20 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

21 OOA Booch héritage associations multiplicités

22 OOA différents types de relations

23 OOA

24 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)

25 La méthode OMT Object Modeling Technique (Technique de Modélisation Objet) Inventée par Rumbaugh Tournée vers la conception Orientée Objet

26 OMT Rumbaugh héritage associations attributs méthodes paramètres
accès (public privé)

27 OMT permet la génération de code

28 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

29 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)

30 OOSE Jacobson

31 OOSE : vue objet entités contrôle interfaces

32 OOSE Messages

33 OOSE

34 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

35 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

36 Objecteering

37 Objecteering

38 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

39 Approche fonctionnelle vs objet

40 Modularité Une modification élémentaire du modèle ne doit pas engendrer de modifications globales du logiciel

41 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)

42 Impact des changements

43 Vue 4 plus 1 Point de vue moderne sur le logiciel (plus de fonctions)

44 Impact sur les Processus
Permet de mieux séparer des activités qui sinon auraient été trop interdépendantes

45 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

46 Historique UML

47 Evolution 2003 : UML 1.5 2004 : UML 2.0