Analyse Orientée Objet – Modélisation Objet avec UML

Analyse Orientée Objet – Modélisation Objet avec UML

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