Cours d'Analyse Principes et Méthodes
télécharger 448.21 Kb.
|
| 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
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:
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:
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:
Ceux-ci s'appuient sur 9 diagrammes différents:
La modélisation de tous les systèmes ne comporte pas nécessairement ces 9 vues. 2. Approche Objet Avantages:
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  aller au Rez 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 modifiée: il suffira d'ajouter les composants nécessaires et de modifier la collaboration entre les composants existants. 2.1 Les objets Les objets informatiques sont des images simplifiées des objets du monde réel, objets matériels de toutes sortes (chaises, livres,...) ou objets "sans masse" ou même virtuels (comptes en banque, déplacements virtuels d'argent, équations, fenêtres d'un environnement Windows, ...). Ils sont des unités atomiques réunissant un état (ce qu'il "est") et un comportement (ce qu'il "fait").  L'objet va révéler son rôle dans l'environnement en envoyant des messages à d'autres objets et en s'insérant ainsi dans un scénario de communication. Notation UML d'un objet: Un objet est représenté par un rectangle. On en souligne le nom. Les traits entre les objets symbolisent les liens. Les rectangles avec coin supérieur droit replié sont des annotations explicatives. Les liens avec ces notes sont alors des traits discontinus. 2.1.1. Diagrammes d'objets : = Vues statiques représentent les objets participant à une interaction et leurs liens. Les diagrammes d'objets sont toujours des fragments d'un immense diagramme qui indiquerait les relations entre tous les objets. exemple: Clients d'une banque et leurs comptes  La notation permet d'indiquer un nom générique plutôt que leur nom individuel. On peut également représenter des objets anonymes avec un ":nom " exemple : Un objet du "genre" Etudiant  La plupart des liens sont binaires. Néanmoins on peut rencontrer des liens d'arité supérieure.   Un objet = 1 état + 1 comportement + 1 identité l'état : représente les valeurs instantanées de tous les "attributs" d'un objet. Ceux-ci peuvent prendre des valeurs dans un domaine de définition donné. L'état peut évoluer dans le temps en conséquence de ses comportements passés.   le comportement: regroupe les "compétences" d'un objet et décrit les actions et les réactions de cet objet. Le comportement d'un objet regroupe donc une série d'opérations qui peuvent être déclenchées en réponse à un stimulus externe = un message envoyé par un autre objet. Pour recevoir un message d'un autre objet, il faut que celui-ci soit "vu". On représentera cette reconnaissance mutuelle par un lien entre les objets. Les messages voyagent le long des liens, à priori dans les 2 directions. Ils sont représentés par des flèches au dessus des liens et accompagnés d'un nom décrivant le message. 2.1.2. Diagrammes de collaboration : = Diagrammes des interactions (messages) entre objets en plus de la structure statique (objets, liens).  Paul demande à Nicolas d'étudier. Nicolas demande à Hélène de cuisiner. Ceci sous-entend bien sûr que Nicolas a la faculté d'étudier (une des ses opérations est "étudier") et que Hélène sait faire la cuisine. L'ordre d'envoi des messages est précisé par un n° placé en tête de message. D'autre part, le comportement à un instant donné dépend de l'état courant qui lui-même peut être modifié par le comportement. Ainsi pour pouvoir étudier, il faut être dans un état "éveillé", sinon l'opération "étudier" n'a pas de sens. Et lorsque l'on reçoit le message de dormir, on passe dans l'état "endormi". l'identité: En plus de son état, tout objet possède une identité de manière à le distinguer de manière non ambiguë de tous les autres objets, même s'il possède les mêmes valeurs d'attributs. En phase de modélisation, l'identité ne se représentera pas de manière spécifique mais restera implicite. 3 catégories de comportement: Les acteurs, les serveurs et les agents Les systèmes informatiques à objets sont donc des collections d'objets qui travaillent en synergie pour réaliser les fonctionnalités de l'application informatique. En fonction de la direction des messages échangés, on peut dès lors regrouper les objets en 3 grandes catégories.
Remarque: Souvent agent ou acteur dépend de l'angle sous lequel on se place, ou du niveau d'abstraction envisagé. Dans une école secondaire, une sonnerie signale le changement d'heure de cours. Celle-ci est en réalité reliée à une horloge. En conséquence de la sonnerie, les élèves se déplacent vers d'autres classes. L'horloge apparaît donc comme un acteur envoyant un message à l'agent sonnerie qui transmet le message aux élèves (serveurs) de se déplacer. Le concierge pourtant peut considérer l'horloge comme un agent puisqu'il la coupe le WE. Les élèves eux peuvent considérer la sonnerie comme un acteur qui s'auto-déclenche toutes les heures. Le concept de message Les messages vont donc permettre aux objets de communiquer. Ils vont relier dynamiquement ces objets séparés par le processus de décomposition. Ils regroupent les flots de contrôle et les flots de données au sein d'un concept unique (qui sera mis en oeuvre selon de nombreuses variantes (appel de procédures, événement discret, interruption, ...)). Ils représentent conceptuellement les actions effectuées dans le cadre du Use Case étudié (cf plus loin). Souvent les messages portent le nom d'une opération définie dans la classe (cf + loin) de l'objet destinataire du message. La notation UML permet de différencier les flots de contrôle (flèches simples) des flots de données (flèches + petits cercles)  De manière générale, UML offre une syntaxe extrêmement complète pour les messages: synchronisation sequence ':' résultat ':=' nom arguments L'expression de synchronisation permet de préciser les envois d'autres messages qui doivent avoir été satisfaits préalablement. La séquence indique le niveau d'emboîtement de l'envoi du message au sein de l'interaction et contient des notations d'itérations éventuelles et de conditions. Le résultat est constitué d'une liste de valeurs retournés par le message. Le nom du message (une opération de l'objet destinataire bien souvent) les arguments= liste des paramètres du message. exemples:
5 catégories principales de messages
Remarque : Un objet est dit actif quand il possède le flot de contrôle. Il peut alors activer des objets passifs pendant le temps d'un opération en leur envoyant un message. Une fois le message traité, le flot de contrôle est rendu à l'objet actif. Dans un environnment multitâche, plusieurs objets peuvent être actifs simultanément. Lorsque plusieurs objets communiquent simultanément, il est important de discuter la notion de synchronisation afin entre autres de protéger l'accès à des objets partagés (exemple une imprimante) 2 grandes catégories d'envoi de messages
On distingue également:
 Les diagrammes de collaboration qui représentent bien spatialement des situations avec un nombre de messages réduit deviennent extrêment confus lorsque les messages se multiplient:  Ici nous avons en plus illustré un message réflexif (8:) d'un objet à lui-même. De tels messages peuvent également indiquer un point d'entrée dans une activité de plus bas niveau qui s'exerce au sein de l'objet. |
nvoi de message asynchrone : n'interrompt en rien l'activité de l'expéditeur. Celui-ci envoie le message et ne se préoccupe plus de rien. Il ne sait pas quand ni même si le message sera traité par le destinataire.
nvoi de message dérobant : ne déclenche une opération que si le destinataire s'est préalablement mis en attente du message. Le destinataire accepte d'attendre.
