Analyse Orientée Objet - Modélisation Objet avec UML - krizkardiak

EPFC Bachelier en Informatique
Cours d'Analyse Principes et Méthodes
Analyse Orientée Objet - Modélisation Objet avec UML (Unified Modeling Language)
Brigitte Herpigny - Bruno Lacroix Sommaire
Modélisation Objet avec UML
1. Introduction générale
2. Approche objet 2.1. Les objets
2.1.1. Diagrammes d'objets
2.1.2. Diagrammes de collaborations
2.1.3. Diagrammes de séquences 2.2. Les classes
-Classes entités, interfaces, contrôles - stéréotypes
2.2.1. Diagrammes de classes
- Associations
- Agrégations
- Qualifications
- Classes associations
- Généralisations / Spécialisations
- Contraintes sur associations
- Classes abstraites
2.2.2. Règles de bonne modélisation
3. Modèle de cas d'utilisation 3.1. Les acteurs 3.2. Les cas d'utilisation 3.3. Les diagrammes de cas d'utilisation 3.4. La transition vers les objets 3.5. Règles de bonne modélisation
4. Modèle dynamique 4.1. Introduction 4.2. Les automates 4.3. Les états 4.4. Diagrammes d'états-transitions 4.5. Opérations, actions et activités 4.6. Diagrammes d'états imbriqués - Généralisations 4.7. Concurrence et Agrégation d'états 4.8. Diagrammes d'interactions versus Diagrammes d'états 4.9. Règles de bonne modélisation 4.10. Diagrammes d'activités + TP ponctuels
+ TP - études de cas
Bibliographie Analyse Orientée Objet - UML > Ian Graham, Méthodes Orientées Objet, 2ème édition, 1997, Thomson
Publishing
> Pierre-Alain Muller, Modélisation Objet avec UML, 2ème édition 2000,
Eyrolles
> N. Lopez, J. Migueis, E. Pichon, Intéger UML dans vos Projets, 1998,
Eyrolles
> G. Booch, J. Rumbaugh, I. Jacobson, Le Guide de l'Utilisateur UML,
2000, Eyrolles
> T. Quatrani, Modélisation UML avec Rational Rose 2000, 2000, Eyrolles
> J. Rumbaugh et al. , OMT, Modélisation et Conception Orientées Objet,
1995, Masson
> Pascal Roques, UML par la pratique - 2001 - Eyrolles
> Craig Larman, UML2 et les design patterns -2005 - Pearson Education 1. Introduction
Les systèmes logiciels actuels sont devenus d'une complexité telle qu'ils
nécessitent de véritables méthodes d'élaboration. Celles-ci doivent
permettre de modéliser et de construire ces systèmes logiciels de manière
fiable et reproductible. Elles permettent également un travail en équipe en
facilitant la communication entre tous ses membres, informaticiens et non
informaticiens, via un langage commun.
Les méthodes structurées et fonctionnelles se sont imposées les premières.
Dans celles-ci, les sous-programmes constituent les éléments structurants.
D'une manière générale, la construction d'un logiciel peut être vue comme
une suite d'itérations du genre "divisions/réunions". En effet, l'étude du
système doit progresser à différents niveaux d'abstraction et s'intéresser
aux détails comme à l'ordonnancement de l'ensemble de manière à faire
émerger le comportement macroscopique complexe du système à réaliser.
Il s'agira donc de décomposer pour comprendre (divisions) et de composer
pour construire (réunions).
Les décompositions sont traditionnellement dirigées par un critère
fonctionnel: décomposer en une hiérarchie de nombreux sous-programmes les
plus simples possibles s'appelant les uns les autres. Ces fonctions les
plus simples sont alors facilement implémentables dans les langages de
programmation.
Ce procédé donne en effet des résultats satisfaisants quand les fonctions
peuvent être bien identifiées et qu'elles sont stables dans le temps.
Lorsqu'il n'en est pas ainsi (les fonctionnalités du problème ont changé!),
les évolutions des fonctions peuvent impliquer des modifications
structurelles très lourdes dans les programmes dues au couplage statique
entre l'architecture du programme et les fonctions. Plusieurs études ont
d'ailleurs montré que la maintenance adaptative d'un logiciel était la plus
grande source d'injection d'erreurs dans un logiciel. (Ainsi, des versions
ultérieures de logiciels possèdent souvent certains bugs que les versions
précédentes ne possédaient pas!)
Les méthodes objets commencent à émerger dans les années 80. Dans celles-ci
les élément structurants seront des objets collaborants entre eux.
Il est à noter que pendant longtemps, on a constaté un mélange des 2
paradigmes (approche fonctionnelle et approche objet) au cours du cycle de
vie des logiciels. Ainsi, il était habituel de réaliser une analyse
(description du problème) fonctionnelle suivie d'une conception
(description de la solution au problème) et d'une programmation objets. Les
conséquences en étaient un manque d'abstraction, abstraction limitée à
l'encapsulation des objets de bas niveaux.
Les années 90 ont vu une prolifération de méthodes objet (+/- 50). Durant
ces années de discussions afin de déterminer ce qui était "objet" et ce qui
ne l'était pas, les utilisateurs ont préféré attendre.
Certaines idées dominantes communes animaient néanmoins les divers groupes
de chercheurs:
. notions de classes et associations : James Rumbaugh et sa méthode OMT
(object modeling technique)
. notions de partitions en sous-systèmes : Grady Booch
. notions de "cas d'utilisations" (interactions entre utilisateur et
système): Ivar Jacobson et ses use cases
Fin 1994, Rumbaugh et Booch décident d'unifier leurs méthodes; un an plus
tard Jacobson les rejoint.
Ils fixent ainsi des objectifs communs:
. représenter des systèmes entiers par des concepts O.
. créer un langage de modélisation utilisable à la fois par les humains
et par des machines (besoin d'un véritable "langage de modélisation")
La standardisation d'UML, Unified Modeling Language date de 1997. La
définition de la version 1.0 est due à un consortium de partenaires
regroupant DEC, HP, i-Logix, IntelliCorp, IBM, ICON, MCI, Microsoft,
Oracle, Rational Software, TI, Unisys. Remarque: UML 1.3, juin 1999 La notation UML est conçue pour servir de langage de modélisation O,
indépendamment de la méthode mise en oeuvre (Booch, OMT, ...). En fait,
elle sous-tend la méthode.
Le langage UML est composé d'éléments graphiques, chacun avec une
sémantique clairement définie. Il peut être utilisé dans tous les domaines
informatiques. La représentation des sytèmes ne se contente habituellement pas d'un seul
élément de modèle.
Ces différents modèles proposés peuvent se comparer à des "vues" différents
d'une même chose, chacune insistant sur des caractéristiques différentes.
On trouve une comparaison facile dans la construction d'une maison. Celle-
ci réclame une série de plans différents selon qu'ils sont destinés au
plombier, à l'électricien, au menuisier... Pourtant, il s'agit toujours des
plans de la même maison. Parfois, on remarque des informations permettant
de naviguer d'une vue à une autre (de manière à ne pas placer les conduites
d'eau là où passent les gaines électriques). De la même manière, UML définit plusieurs modèles pour la représentation
des systèmes:
. un modèle de classes qui capture la structure statique
. un modèle de cas d'utilisation décrivant les besoins des utilisateurs
. un modèle d'interactions représentant les scénarios et les flots de
messages
. un modèle de réalisation montrant les unités de travail
. un modèle de déploiement précisant la répartition des processus
Ceux-ci s'appuient sur 9 diagrammes différents: V diagrammes de classes: représentent la structure statique en termes de
classes et de relations
V diagrammes d'objets: représentent la structure statique en termes
d'objets et de relations
V diagrammes de séquence: sont une représentation temporelle des objets
et de leurs interactions
V diagrammes de collaboration: sont une représentation spatiale des
objets, des liens et de leurs interactions
V diagrammes de cas d'utilisation : représentent les fonctions du
système du point de vue de l'utilisateur
V diagrammes d'états-transitions: représentent le comportement d'une
classe en termes d'états
V diagrammes d'activités: représentent le comportement d'une opération
en termes d'actions. V diagrammes de composants: représentent les composants physiques d'une
application
V diagrammes de déploiement: représentent le déploiement des composants
sur les dispositifs matériels La modélisation de tous les systèmes ne comporte pas nécessairement ces 9
vues.
2. Approche Objet Avantages: . Stabilité de la modélisation par rapport aux entités du monde réel
. Construction itérative facilitée par un faible couplage statique entre
les différents composants (( approche fonctionnelle)
. possibilité de réutiliser des éléments d'un développement à un autre
. simplicité du modèle basé sur 5 concepts de base : objets, messages,
classes, héritage, polymorphisme) L'approche O est basée sur une démarche cartésienne rationnelle ainsi que
sur une démarche "systémique" qui considère un système comme une totalité
organisée dont les éléments solidaires ne peuvent être définis que les uns
par rapport aux autres.
Ici, la méthode de décomposition sera basée sur l'intégration de ce que le
système est et fait.
exemple: Système d'ascenseur
Les objets qui sont des abstractions du monde réel intègrent une structure
et un comportement.
La modélisation est donc une modélisation statique et dynamique de
l'environnement (le "domaine") dans lequel sont définis les besoins.
Les fonctionnalités se représentent comme des formes de collaborations
entre les objets qui composent le système et ce couplage devient dynamique.
Si les fonctionnalités changent, l'architecture du système n'est pas
mod