Module 305 Mthodes orientes objets d'analyse et de conception

Analyse et conception oriente objet

Session2_1 - Notions de base Session2_2 - Techniques et dmarche de modlisation par objets Session2_3 - Les mthodes orientes objets Session2_4 - Introduction au langage UML

Exercices

Corine Cauvet corine.cauvet@wanadoo.fr

Analyse et conception oriente objet

1 - Notions de base
Objectifs : Comprendre les principes de l'approche objet Savoir utiliser et comprendre les concepts de l'approche objet avec un point de vue systme d'information Mots cls : Classe, objet, hritage, liens entre classes

1. L'approche objet : Origine et principes

Les principes de la programmation objet sont ns de deux motivations : La difficult de concevoir et de maintenir des programmes de taille importante, du point de vue du gnie logiciel (la notion de programmation structure) La modlisation du raisonnement humain du point de vue de l'Intelligence Artificielle et le besoin de structurer une masse de connaissance (la notion de proprits relatives un mme objet.) Au dbut de la programmation, les premiers langages s'excutaient de faon linaire, chaque ligne du programme tait lue puis excute jusqu' la dernire. Cette approche pouvait difficilement s'appliquer des programmes complexes et les dveloppeurs ne pouvaient pas rutiliser des outils de programmation dj crits. Le langage fortran et l'assembleur sont des langages linaires. Avec les rseaux informatiques et les systmes rpartis, les systmes logiciels ont atteint un niveau de complexit croissant et de ce fait, ils ncessitent des outils de programmation sophistiqus. De plus, la taille des programmes et les problmes de maintenance ont mis en vidence la ncessit de promouvoir : l'abstraction de donnes, la modularit et la rutilisabilit des logiciels. Ainsi, beaucoup de langages ont vu le jour, chacun tentant sa manire d'apporter une solution satisfaisante. Afin de rutiliser le code et d'viter les redondances, les langages dits modulaires voient tout d'abord le jour. Le principe est de regrouper un ensemble d'instructions dans des fonctions ou procdures. En effet, chaque tche excute par un programme reprsente un nombre variable d'instructions. Ces instructions sont runies (en bibliothques) afin de pouvoir segmenter le code et favoriser la rutilisation de celui-ci. Le langage C fait partie de ces langages. Les mthodes d'analyse associes ce principe consistent alors "diviser un problme pour mieux rgner". C'est ce que l'on appelle, la programmation dirige par les traitements ou mthode

fonctionnelle descendante. Toutefois, cette technique atteint ses limites lorsque l'univers sur lequel oprent les programmes volue. La notion d'encapsulation permet alors de pallier cet inconvnient : les donnes et les procdures qui les manipulent sont regroupes dans une mme entit appele OBJET. Les LANGAGES OBJET (ou langages orients objet) sont alors apparus pour apporter une volution de l'approche modulaire. Ces langages de programmation orients objet apportent avec eux leur mthode d'analyse approprie : L'APPROCHE OBJET. Cette approche introduit un nouveau modle de programmation dont les objectifs sont : Construire du logiciel de meilleure qualit. Les critres de qualit viss sont l'extensibilit, la rutilisabilit et la compatibilit. Amliorer la productivit des programmeurs Amliorer la lisibilit du logiciel Rduire les temps de maintenance des logiciels Ainsi, dans l'approche objet, l'lment de dcomposition unique est l'OBJET . L'objet se veut alors une reprsentation (abstraite) d'une chose (concrte) du monde rel. Un objet regroupe donc la fois les donnes qui le caractrise et les actions qu'on peut effectuer sur lui. Un objet regroupe une partie statique (un ensemble de donnes) et une partie dynamique (un ensemble de procdures manipulant ces donnes). L'objet est alors dfini par son comportement et non sa structure. C'est ce que l'on appelle la programmation dirige par les donnes. Ainsi, pour traiter une application, le dveloppeur commence par dfinir les types d'objets appropris et leurs oprations spcifiques. C'est ce que l'on appelle dfinir les CLASSES d'objet. L'univers d'une application informatique devient alors une structure compose d'un ensemble d'objets qui dtiennent chacun les cls de leur comportement et qui changent des messages. Ces principes offrent ainsi des qualits pour mettre en uvre des mthodes de programmation rigoureuses : Abstraction des donnes : l'objet dcide la manire d'effectuer les oprations. Il n'est pas besoin de connatre l'implantation interne d'un objet. Modularit/Modifiabilit : les objets sont faciles changer. Rutilisabilit : l'intgration de bibliothques d'objets permet de construire des objets de mme type, des objets plus spcifiques, etc. Lisibilit/Comprhensibilit : l'encapsulation, la possibilit de surcharge et la modularit renforcent la lisibilit des programmes. Les dtails d'implantation sont cachs.

2. L'approche objet : les concepts

Dans cette section, nous prsentons les concepts de base de l'approche objet du point de vue du gnie logiciel puis du point de vue des systmes d'informations. 2.1 Du point de vue gnie logiciel Les objectifs et les difficults du Gnie logiciel sont les suivants : Difficult de matrise des cots. Difficult de ralisation de plannings. Difficult de matrise des dlais de ralisation. Difficult d'amlioration de la productivit et de la qualit des logiciels. Difficult de gestion de projets logiciels de grande ampleur (Programming in the Large). Nombreux checs : rsultats fournis par les logiciels insatisfaisants pour les clients finaux. Tout ceci dans un contexte de comptition internationale svre. Ainsi, l'approche objet trouve de droit une place intressante dans le domaine du gnie logiciel de par les qualits avances de maintenabilit, de modularit, de rutilisabilit etc. Trois aspects sont alors primordiaux dans l'approche objet : L'encapsulation : cette technique permet de runir des variables et des fonctions au sein d'une mme entit nomme classe. Les variables sont appeles les donnes membres, les fonctions sont appeles les mthodes. L'accs aux donnes et mthodes peut tre aussi rglement. L'hritage : cette technique permet de dfinir une hirarchie de classe. Chaque classe fille hrite des mthodes et des donnes de ses "mres". En pratique, la classe de base est une classe gnrique, ainsi plus on descend dans la hirarchie, plus on spcialise cette classe. Le polymorphisme : ce nom vient du grec et signifie "qui peut prendre plusieurs formes". Cette caractristique offre la possibilit de dfinir plusieurs fonctions de mme nom mais possdant des paramtres diffrents. La bonne fonction est choisie en fonction de ses paramtres lors de l'appel. Un ensemble concepts constitue les fondements de cette approche : Tout objet a une identit, une structure et un comportement Les objets communiquent par envoi de messages La classe est une unit de spcification d 'un ensemble de services. Elle comporte deux parties : une interface et une implantation.

De ce fait, l'approche objet est alors base sur le principe qu'il est possible de structurer un systme logiciel sous forme d'une collection de classes et de liens entre classes . A l'excution, le fonctionnement du systme est ralis par les objets des classes qui changent des messages. Dans cette section 2, nous allons voir dans un premier temps en quoi consiste une classe et un objet. Dans un deuxime temps, nous verrons comment la classe permet de grer l'envoi et la rception des messages, grce cette sparation entre son interface et son implantation. Enfin, dans un troisime temps, nous prsentons les deux types de liens entre classe qui permettent de terminer al description d'un systme logiciel : les liens d'hritage et les liens d'utilisation. 2.1.1 Classes et Objets Une classe se dfinit comme une spcification d'un ensemble d'objets de mme nature, ces objets ayant la mme structure et le mme comportement. Une CLASSE est donc une sorte de moule partir duquel sont gnrs les objets. Les objets gnrs s'appellent des INSTANCES de la classe. Ainsi, dans une classe, la structure de l'objet est dfinie par une partie statique dans laquelle les donnes sont dcrites. De mme, le comportement de l'objet est identifi dans sa classe par une partie dynamique qui regroupe les mthodes associes l'objet et aux donnes qu'il renferme. L'ensemble des mthodes d'une classe constitue alors son interface. La figure 1 ci-dessous, propose l'exemple d'une classe COMPTE qui reprsente un compte bancaire. Celui-ci est alors caractris par une partie statique, refermant deux donnes. Ces deux donnes sont les valeurs de dbit et de crdit du compte bancaire en question. Dans cette classe, on retrouve galement une partie dynamique, qui regroupe les mthodes appliques aux donnes de l'objet. On retrouve notamment la mthode appele Dposer(), qui permet d'ajouter de l'argent sur le compte bancaire. Cette mthode est alors lie la valeur de crdit et peut avoir, en pseudocode, la spcification suivante ; Mthode dposer (v : rel) Crdit := crdit + V Fin Bien videmment, la plupart des mthodes ne se rsument pas de simples calculs arithmtiques. Gnralement, les messages consistent mettre des messages d'autres objets situs dans des champs, des variables globales ou locales.

Figure 1 : Exemple de classe et d'instances Enfin, dans la figure 1, on peut voir que le systme peut crer autant d'objet que souhait partir de la classe compte. C'est notamment le cas dans cette figure des comptes intituls C1 et C2 ; C1 et C2 sont des instances de la classe COMPTE. Ainsi, programmer un systme logiciel selon l'approche objet revient dcrire des classes d'objets et caractriser leur structure et leur comportement et instancier ces classes pour crer des objets.

2.1.2 Interface et implantation Du point de vue gnie logiciel, la classe est un module fournisseur de services. Ces services sont spcifis sous forme de mthodes. Comme le montre la figure 2 ci-dessous, chaque classe comporte : Une partie visible appele interface qui contient tous les services offerts par la classe (les mthodes). Une partie cache appele implantation qui contient les structures de donnes et les ralisations des mthodes ncessaires l'implantation des services.

Figure 2 : Partie visible et cache d'un objet Dans le systme, un objet A ne peut accder autre objet B qu' travers l'interface de cet objet B. Il s'agit alors pour un objet A, d'activer l'une des mthodes de l' objet B, et c'est seulement travers cette activation, que la structure de donnes interne de l'objet B pourra tre modifie. Ce principe d'activation des mthodes des autres objets est souvent apparent dans la littrature l'envoi de messages entre l'objet A et l'objet B. Envoyer un message un objet, c'est lui dire ce qu'il doit faire. Le fait que B rponde au message de A, consiste pour B excuter une mthode demande par A. Ce principe de sparation entre l'implantation interne d'un objet et son interface visible, permet de protger les objets clients des changements de structures de donnes ou d'algorithmes qui pourraient survenir dans les objets fournisseurs . Ce principe est essentiel pour rduire les temps de maintenance du logiciel. N.B. La notion de mthode diffre quelque peu de la notion de procdure d'un langage classique. Par exemple, si l'on dispose d'objets graphiques, comme des boutons, des fentres ou encore des icnes, on peut envoyer le mme intitul de mthodes deux objets diffrents, car chaque objet implmente sa propre mthode de visualisation : c'est la liaison dynamique de message. La mthode qui rpond un certain message est recherche au moment de l'excution. 2.1.3 Lien d'utilisation et lien d'hritage Comme nous l'avons voqu prcdemment, concevoir un systme logiciel selon l'approche objet, consiste dcrire le systme sous forme de classes et de liens entre ces classes. Dans l'approche objet, on distingue principalement deux formes de liens entre les classes : le lien d'utilisation (ou client fournisseur) et le lien d'hritage . Le lien d'utilisation permet un objet de la classe cliente de demander un service une classe fournisseur . Cette demande se fait au moment o la classe cliente doit elle-mme raliser un service pour un autre objet. On dit qu'elle dlgue une partie de son travail . Dans la figure 3 ci-dessous, un exemple de lien d'utilisation concerne le lien entre les classes Fentre et Modle. Le lien d'hritage permet d'tendre dans uns sous-classe les services d'une super classe.

Cette extension consiste ajouter dans la sous-classe de nouveaux services ou redfinir des services existants. Par exemple le service surface qui calcule la surface d'un modle gomtrique peut tre redfini (pour tre prcis) dans la classe Rectangle. Une des caractristiques importantes des classes dans une reprsentation objet : la notion d'HERITAGE. On peut ainsi dcrire des structures gnriques ou abstraites. Ainsi, une classe peut engendrer une autre classe, les sous classes possdent par dfaut l'ensemble des caractristiques de la classe mre.

Figure 3 : Liens d'hritage et liens d'utilisation Ces deux formes de liens et leurs proprits sont essentielles pour satisfaire aux objectifs de rutilisabilit, d'extensibilit et de robustesse du logiciel. Il est vivement conseill de lire le livre de Bertrand Meyer [Meyer 90] dans lequel le lecteur trouvera une bonne description des concepts objet et un bon argumentaire sur leurs intrts dans la conception et la programmation de logiciels de qualit. N.B. L'hritage perme notamment de dfinir des classifications d'objets, de modliser des mondes rels, de procder par affinages successifs de classes pr-dfinies. Si l'on reprend l'exemple de la classe compte prsente dans la figure 1, on peut dfinir une sous-classe EPARGNE identifiant un compte pargne. En effet, on peut notamment dire qu'un compte Epargne a comme caractristiques celles d'un Compte + des particularits propres, qui peuvent tre lies au taux de rmunration annuel du compte. La sous classe EPARGNE hrite alors des caractristiques de la classe COMPTE et implmente galement ses propres spcificits (taux de rmunration etc). Dans la partie suivante, nous prsentons les concepts de l'approche objet du point de vue des systmes d'information. 2.2 Du point de vue systmes d'information Le S.I. est vu comme une collection d 'objets qui cooprent pour fournir les services attendus. Assez naturellement on distingue les objets de la conception et les objets techniques. Les objets de la conception sont les objets mtiers ou les objets de gestion. On dfinit un objet mtier comme, un sujet :

 D'intrt pertinent au sein d'une organisation, Porteur de connaissances partages entre les acteurs Sur lequel vont tre dfinis des objectifs Qui a une capacit oprer sur ces connaissances (filtrage, agrgation, dduction, dtection d'anomalie) et une capacit restituer les connaissances de situation ncessaires l 'activit de l 'organisation La classe est une unit de spcification d'un ensemble d'objets de mme nature. Cette spcification dfinit la structure et le comportement de ces objets. La classe devient alors une nouvelle forme d'abstraction pour la conception de systmes d'information .

Figure 4 : La classe CHAMBRE dans un systme de rservation de chambres d'htel La classe introduit une nouvelle unit de raisonnement qui intgre les dimensions donnes et traitements. Le concept de classe devient une nouvelle unit de raisonnement pour le concepteur qui permet: De considrer et raisonner sur une classe d'objets de manire isole. D'tudier le cycle de vie d'un objet. D'identifier des oprations localement chaque objet. De spcifier des oprations sans contrainte temporelle, sans condition de dclenchement, sans ordre d'excution. La classe supporte alors, l'intgration des donnes et des traitements, de par le regroupement sous une mme entit d'un structure des donnes et de la dfinition de leur comportement (comme le montre la figure 5 ci-dessous) :

Figure 5 : Classe, structure et comportement Enfin, grce en particulier la notion d'hritage, on peut avoir une vision ensembliste de la notion de classe. En effet, si l'on considre qu'une classe peut tre vue comme un ensemble d 'objets persistants, alors, de ce point de vue, une sous-classe est galement un ensemble d'objets persistants. Il se trouve simplement que cet ensemble peut tre vu comme un sous-ensemble de la super-classe. Si l'on reprend l'exemple de la classe COMPTE, on considre que la classe COMPTE reprsente un ensemble A de comptes bancaires. De mme, on peut considrer que la classe COMPTE EPARGNE reprsente un ensemble B de comptes pargne. Alors, il s'avre bien que B est un sous-ensemble de A, puisque l'ensemble des comptes pargnes est bien inclus dans celui des comptes bancaires.

Conclusion
Dans cette unit d'enseignement, nous avons prsent les notions de base de l'approche objet, et notamment l'aspect historique de cette approche, issue d'une volution des langages de programmation. Les concepts de classe, d'objet, d'interface et de liens entre les classes ont t prsents, du point de vue du gnie logiciel et de celui des systmes d'information.

Bibliographie
[Meyer 90] Conception et programmation par objets , B. Meyer, InterEditions, 1990 [Bouzeghoud Gardarin - Valduriez 97] Les objets , M. Bouzeghoud, G. Gardarin, P. Valduriez, Eyrolles, 1997

Analyse et conception oriente objet

2 - Techniques et dmarche de modlisation par objets

Objectifs : Comprendre les principes de la modlisation objet indpendamment de toute mthode particulire Comprendre les principes d'une dmarche objet indpendamment de toute mthode particulire Mots cls : Modle objet, modle dynamique, modle fonctionnel, pattern de modlisation objet

1. Modlisation objet et modle objets

1.1 La modlisation objet La modlisation objet utilise des modles de reprsentation adapts aux diffrentes dimensions et aux diffrents niveaux d'abstraction d'un systme d'information. Ces modles sont composs d'un jeu de concepts et de rgles d'utilisation de ces concepts. Le concepteur doit instancier les concepts proposs pour produire les reprsentations souhaites. En gnral les concepteurs utilisent un langage graphique pour spcifier les rsultats de la modlisation. Une nouvelle technique de modlisation semble merger : les patterns de modlisation. Cette technique consiste utiliser des solutions prtes l'emploi pour traiter des problmes rcurrents de modlisation. Le dveloppement de cette technique a commenc avec l'arrive des mthodes objet et les solutions proposes sont exprimes avec des langages objet (OMT, UML, Java). Bien sr cette technique de modlisation peut tout fait tre utilise avec d'autres approches de conception que l'approche objet. Il existe aujourd'hui de nombreux catalogues de patterns qui s'utilisent en complment de la simple notation UML. Les deux techniques ne s'opposent pas ; elles sont plutt complmentaires. En gnral les parties solution des patterns utilisent des modles objet. L'utilisation de patterns dans le dveloppement des systmes d'information manque encore de maturit et de nombreux problmes restent poss : la difficult de rechercher et de trouver le bon pattern , la difficult de composer des patterns 1.2 Les modles orients objet La plupart des mthodes objets ont une approche commune base sur une triple perception du Systme d'Information (comme le montre la figure 1 ci-dessous).

 Une dimension statique qui dcrit les objets du systme. Une dimension dynamique qui contrle les changements d'tats des objets face certains vnements. Une dimension fonctionnelle qui dcrit les processus de transformation des applications.

Figure 1 : Trois dimensions dans un SI Ces trois dimensions sont complmentaires, elles concourent toutes dcrire de faon aussi complte que possible le systme d'information. Certaines mthodes ne supportent que la dimension statique, d'autres y ajoutent la dimension dynamique ou fonctionnelle. La dimension statique dcrit les objets du SI, les associations entre ces objets, les contraintes et les oprations associes. Le modle objet utilis dpend de la catgorie de la mthode : dans les mthodes de programmation (OOD, HOOD), un objet est un processus et le formalisme de structuration des processus est relativement simple (un graphe d'appel de processus). Dans les mthodes de conception de SI, un objet est gnralement une entit de bases de donnes, les formalismes de structurations des donnes sont nombreux et riches en concepts (le modle entitassociation avec ses diffrentes variantes et extensions). La dimension dynamique reprsente les types d'vnements qui peuvent survenir dans les SI et les changements d'tats rsultant du traitement de ces vnements. Le modle dynamique le plus utilis est sans doute le modle bas sur les diagrammes d'tat/transition (OOD, OOA, OMT). La dimension fonctionnelle n'est pas comprise de la mme faon dans toutes les mthodes. Certaines assimilent cette dimension la description des fonctionnalits du systme d'information. D'autres associent cette dimension la spcification dtaille des oprations dfinies par les

objets. Le modle fonctionnel le plus utilis est celui bas sur les Diagrammes de Flux des Donnes ou DFD (OOA, OMT). Un des problmes majeurs rencontrs dans les mthodes utilisant simultanment ces trois axes est sans doute la cohrence entre les modles associs. Ainsi, il est utile de modliser un systme selon trois points de vue principaux, lis mais distincts, chacun saisissant des aspects importants du systme, tous ncessaires une description complte. Ces trois points de vue sont exprims dans le modle statique (ou objet), le modle dynamique et le modle fonctionnel. Ces trois modles ont t introduits pas J. Rumbaugh dans la mthode OMT [Rumbaugh 95] et sont repris avec quelques variantes dans UML. Dans les trois parties suivantes, nous apportons un clairage sur ces trois point de vue. 1.2.1 Le modle statique (ou objet) Le modle objet reprsente les aspects statiques et structurels d'un systme. Il dcrit la structure des objets dans un systme : leur identit, leurs relations avec les autres objets, leurs attributs et leurs oprations. Le modle objet fournit le cadre essentiel sur lequel les modles dynamique et fonctionnel peuvent tre placs. Le modle objet dcrit les concepts qui sont importants pour l'application. Il est usuel de considrer qu'il existe un modle objet d'analyse (ou mtier) et un modle objet de conception (ou informatique). Le premier contient les objets mtier et le second, les objets techniques. Le modle objet est reprsent par des diagrammes de classes. Les classes sont organises en hirarchies et sont associes d'autres classes. Elles dfinissent les valeurs des attributs des objets et les oprations que chacun des objets peut subir ou accomplir. Les concepts cls de la modlisation objet sont donns dans la figure 2 ci-dessous.

Figure 2 : concepts cl de la modlisation objet Nous avons vu jusqu' prsent la partie modlisation objets. Nous allons maintenant passer une autre modlisation : la modlisation dynamique. La modlisation objets dcrit la structure du domaine sur laquelle sera aussi base la structure de l'application. La modlisation dynamique va tre surtout utilise pour dcrire les itrations entre l'application et le monde extrieur (utilisateurs, autre application, ...). Elle est surtout utile pour les applications interactives. 1.2.2 Le modle dynamique

Le modle dynamique dcrit les aspects du systme en relation avec le temps et les squencements des oprations. Il contient les descriptions des vnements qui provoquent les changements du systme, les squences d'vnements, les tats qui dfinissent les contextes de survenance des vnements. Ce modle exprime le contrle d'un systme sans attacher d'intrt ce qu'effectuent les oprations et sur quoi elles oprent, ou la faon dont elles sont implantes. Il est usuel de considrer la dynamique un niveau local (dynamique de chaque objet considr de manire isole) et un niveau global (dynamique d'un ensemble d'objets en interaction). Le modle dynamique est reprsent par des diagrammes d'tats (niveau local) et des diagrammes d'interaction (niveau global). Chaque diagramme d'tats met en vidence pour les objets des classes les squences d'tats et d'vnements permises dans le systme. Les diagrammes d'interaction montrent les squences de messages entre des objets. Les concepts cls de la modlisation dynamique sont donns dans la figure 3 ci-dessous.

Figure 3 : concepts cls de la modlisation dynamique vnements et scnarios On va dire que l'extrieur (e.g. un utilisateur) interagit avec l'application en lui envoyant des vnements . Un vnement est quelque chose qui se produit un moment donn dans le temps. On considre qu'un vnement n'a pas de dure, il est instantan. On est seulement intress savoir qu'il se produit. Par exemple, frapper la touche ENTER du clavier va tre un vnement pour l'application, dplacer la souris en est une autre. Si on mesure en continue la temprature de l'eau dans une casserole, tout changement de temprature en plus ou en moins est une vnement. Un vnement sert transmettre une information d'un objet vers un autre objet. Puisqu'on considre qu'on dfini l'interaction de notre application avec l'extrieur l'un des objets (source ou destination de l'vnement) sera dans le domaine (e.g. l'utilisateur) et l'autre dans l'application (une instance d'une classe). Un vnement communique de l'information dans un sens seulement. Si un objet (e.g. l'utilisateur) attend une rponse la suite d'un vnement qu'il a mis (e.g. appuyer sur la touche RETURN), l'vnement ``retour'' qui communique de l'information de l'application vers l'utilisateur est indpendant. L'application ``dcide'' elle-mme si elle veut rpondre au premier vnement ou pas. Un scnario d'crit une suite normale d'vnements entre l'application et l'extrieur pour accomplir une tche donne. Le but du scnario est de permettre de vrifier avec l'utilisateur que vous avez bien compris les interactions qu'il souhaite. tats et diagramme d'tats

On considre qu' un moment donn, chaque instance de l'application est dans un tat donn. L'tat d'un objet est l'ensemble des valeurs de ses attributs et associations un moment donn. Si rien ne se produit dans l'application ou avec l'extrieur, l'tat des objets reste inchang. L'tat d'un objet va tre modifi par l'arrive d'vnement(s). Par exemple, quelqu'un peut-tre dans l'tat ``dormant''. Tant que rien ne se produit, la personne reste dans cet tat. Quand l'vnement ``rveil-sonne'' arrive, la personne va passer dans l'tat ``rveill''. Le changement d'tat peut aussi se produire avec d'autres vnements (``tlphone-sonne'', ``maison-explose'', ...). Un vnement spare deux tats diffrent d'un objet, un tat spare deux vnements (entre les deux vnements, l'objet est dans cet tat). Un vnement dcrit quelque chose qui se passe un instant donn, un tat correspond une ``activit'' (comme dormir) continue. Si toutes les valeurs d'attribut et d'association d'un objet dcrivent sont ``tat global'', on n'a besoin en gnral de considrer que certaines attributs/associations particulier(res) pour dfinir un tat prcis. Par exemple, une casserole d'eau est dans l'tat liquide (attribut temprature > 0 et < 100). On ne s'occupe pas de la couleur de l'eau. L'tat ``transparent'' est dfini par l'attribut couleur et ne s'occupe pas de la temprature. Les deux tats et attributs sont indpendants l'un de l'autre. Si un vnement ``ajout-colorant'' se produit, l'tat ``liquide'' ne va pas tre affect Plusieurs valeurs diffrentes d'un attribut peuvent correspondre un mme tat (attribut temprature, tat ``liquide''), de mme que chaque valeur peut correspondre un tat. On peut dcrire un tat par son nom, une description en texte, l'ensemble des valeurs des attributs qui le dfinissent ou l'ensemble des vnements qui vont amen l'objet dans cet tat. On dcrit le comportement d'un objet en dfinissant son diagramme d'tats. Le diagramme d'tats donne tous les tats possible d'un objet et quels vnements font passer d'un tat un autre. N.B. Ne pas confondre le diagramme d'tats d'un objets avec un scnario qui dcrit une suite logique d'vnements entre l'application et l'extrieur. Un scnario peut impliquer plusieurs objets de l'application ou du domaine, en montrant lequel envoi et reoit quels vnements. Un diagramme d'tats se concentre sur un objet (en fait une classe d'objets) et dcrit tous les tats et les vnements qui permettent d'en changer. On ne s'inquite pas de savoir qui envoi ces vnements. Nous allons dcrire maintenant comment conduire l'analyse pour obtenir le modle dynamique. Dmarche d'analyse dynamique Les diffrentes tapes sont les suivantes : ETAPE 1 / Dfinir des scnarios typiques. N'essayez pas de dcrire le fonctionnement de l'application en gnral. Occupez vous de tches prcises et dfinissez pour chacune d'elles un scnario typique. Dfinissez d'abord les scenari ``normaux'', dfinissez ensuite les scenari pour les erreurs, les interruptions, les fausses rponses, etc. ETAPE 2 / Identifier les vnements entre les objets. Les vnements sont tous les signaux, entres/sorties, interruptions, etc. qui proviennent des utilisateurs ou vont les informer. Certaines ``actions'' doivent tre regroupes dans un mme vnements, comme par exemple le fait d'appuyer sur la touche ``a'' ou la touche ``b'' du clavier, d'autres, devront tre considres sparment comme appuyer sur la touche ``ENTER''. La diffrence n'est pas toujours claire, il faut gnralement prendre la dcision. En mme temps que vous identifiez les vnements, identifiez les objets qui reoivent ou envoient ces vnements.

ETAPE 3 / Crer les diagrammes d'tats. Pour chaque classe, d'un scnario vous allez dfinir un diagramme d'tats. Dans le scnario, l'espace entre deux vnements correspond un tat. Essayez de trouvez un nom pour cet tat, mais n'insistez pas trop si vous n'en trouvez pas. Puis incluez d'autres scenari, concernant la mme classe, dans le diagramme. Vous devrez dcider quand un nouveau scnario se spare d'un scnario existant (facile habituellement) et ajoute de nouveaux tats, mais aussi quand deux scenari se rejoignent dans un tat qui existe dj. Cette deuxime tche est plus difficile, assurez vous que les deux tats des deux scenari sont bien un seul et unique. Cela suppose par exemple que l'objet ne fait pas de diffrence dans cet tat sur la faon dont il est arriv ici (en suivant lequel des deux scenari). Par exemple si un distributeur de billet autorise l'utilisateur r-entrer son code au clavier si il s'est tromp, on peut penser qu'on revient dans l'tat initial (``Saisie du code''), mais en fait ce n'est pas vrai, parce que habituellement, les distributeurs n'autorisent qu'un nombre limit d'erreur, donc, l'entre du code aprs une erreur n'est pas exactement la mme que tout au dbut. Tout au dbut, on a le droit deux erreurs, aprs une erreur, on n'a plus le droit qu' une seule. ce sont deux tats diffrents. Traitez d'abord les scenari normaux, incorporez ensuite ceux pour les cas spciaux (erreur, abandon, ...). ETAPE 4 / Vrifier la consistance des diagrammes. Vrifier que tous les vnements sont envoys et reu par quelqu'un, vrifiez que les scnarios originaux sont compltement reprsents en essayant de les ``drouler'' dans tous les diagrammes de classes concerns. Nous avons vu jusqu' prsent la partie modlisation objets et la modlisation dynamique. Le modle objets dcrit la structure du domaine, avec quoi on va travailler. Le modle dynamique dcrit les interactions avec l'utilisateur, quand on doit faire telle ou telle action. Le modle fonctionnel va dcrire comment faire les actions. Ce dernier est prsent dans la partie suivante. 1.2.3. Le modle fonctionnel Le modle fonctionnel dcrit les aspects relatifs aux transformations des valeurs d'objets. Il modlise ce que fait le systme sans s'occuper du moment o il le fait. Il contient les descriptions des fonctions d'un systme. Il est usuel de dcrire les fonctions diffrents niveaux d'abstraction, il peut s'agir des processus mtier que doit supporter le systme ou des oprations dfinies sur les objets. Le modle fonctionnel est reprsent par des diagrammes de flots de donnes ou des diagrammes d'activits. Les concepts cls de la modlisation fonctionnelle sont donns dans la table ci-dessous.

Figure 4 : concepts cls de la modlisation fonctionnelle Rappelons que modle objets est compos de diagramme de classes , le modle dynamique est compos de diagrammes d'tats , le modle fonctionnel est compos de diagrammes de flot de donnes (DFD, ``data flow diagram'').

Un diagramme de flot de donnes dcrit le ``flot des donnes'' ( variables), c'est--dire qu'il dcrit d'o vient chaque variable (entre), et comment elle est modifie pour produire le rsultat voulu (sortie). Un diagramme de flot de donnes se compose de : Processus : C'est la partie qui va faire les calculs. On peut voir chaque processus comme une fonction a qui on donne des donnes en entre (paramtres') et qui calcul des valeurs en sortie. Flot de donne : C'est simplement le passage d'une donne d'un point vers un autre, sans aucune modification. Une donne peut par exemple tre la sortie d'un processus et tre passe en entre un autre processus. Acteur : Les acteurs sont des objets qui produisent ou consomment les donnes. Les flots de donne partent en gnral d'un acteur, pour traverser quelques processus et finir dans un autre acteur. Entrept de donne : C'est aussi un objet, mais il n'a aucune part active dans le diagramme de flots de donnes. Les ``entrepts'' servent uniquement a stocker des valeurs temporaires pour les restituer ensuite. Nous allons maintenant dcrire plus en dtail chacune des quatre composants des diagrammes de flots de donnes. Processus : les processus sont reprsents par un ovale avec le nom du processeur. Un processus prend un certain nombre de donnes en entre et retourne un certain nombre de donnes en sortie. Exemples de processus : une addition (nom = ``+'', entres = nombres--additionner, sortie = rsultat), un compilateur (nom=``gcc'', entre = fichiers-sources, sortie = fichier-excutable), ... Un processus doit tre comme une fonction il ne peut faire qu'une seule chose. C'est--dire essentiellement qu'on doit pouvoir le dcrire en un mot ou une expression de deux ou trois mots. Ce que fait le processus peut tre compliqu et ncessiter d'tre dvelopp dans un sous-DFD. Mais ce qu'il fait doit tre une seule chose de faon abstraite. Par exemple, iconiser une fentre l'cran est une action (un processus) complexe qui ncessite plusieurs tapes qu'on peut dcrire dans un sous-DFD. Mais abstraitement c'est une seule action : iconiser une fentre. Un processus dans un DFD est un peu une boite noire, on voit les donnes en entre et en sortie, le nom du processus. Dans le DFD mme, on ne sait pas comment le processus fonctionne. Pour dcrire un processus, il y a deux mthodes : Dans le cas d'un processus complexe, on peut le dcomposer dans un sous-DFD. Les entres et sorties du processus deviennent les flots de donnes en entre et sorties du sous-DFD et le sousDFD dcrit avec plus de dtail comment calculer les sorties partir des entres. Chaque processus du sous-DFD pourra ventuellement tre aussi dcompose dans un autre DFD. Dans le cas d'un processus simple, on peut le dcrire par crit (texte) ou par une formule mathmatique, ou autre. Acteurs : Les acteurs sont reprsents par des boites carres. Ce sont des objets (du modle objets) qui produisent ou consomment les donnes. C'est--dire qu'ils sont souvent au dbut et la fin d'un DFD. Le nom d'acteurs indique qu'ils ont une part active dans le processus dcrit par un

DFD. Les acteurs sont au dbut ou la fin d'un DFD. Au contraire des ``entrepts'', ils ne ragissent pas une requte, mais fournissent d'eux-mmes les donnes, initiant ainsi un processus. l'autre bout d'un DFD, ils ne reoivent pas une donne pour la restituer plus tard dans le DFD. On utilise les DFD pour donner le dtail d'une action du modle dynamique. Les acteurs du DFD seront alors l'objet qui fait l'action ou l'objet sur lequel l'action est faite. Entrept de donnes : Un autre composant des DFD est ``l'entrept'' (data store). On le reprsente par deux lignes avec le nom de ``l'entrept'' crit entre les lignes. Les ``entrepts'' peuvent tre des objets, comme les acteurs, mais ils sont passifs. Ils ne servent qu' stocker les donnes (rsultats intermdiaires) et les retourner la demande d'un processus. Un acteur peux aussi tre un attribut d'un objet. On peut stocker une ou des donnes dans un ``entrept'' par une flche entrante. Et on peut ensuite restituer les donnes stockes dans le mme ou dans un autre ordre, ou bien seulement certaines des valeurs entres (maximum/minimum, moyenne, ...). Un objet dans un DFD est un ``entrept'' si il sert stocker des rsultats intermdiaires qui sont ensuite restituer (flots de donnes en entre et en sortie). On peut aussi avoir un ``entrept'' qui ne fait que fournir des donnes (pas de flots de donnes en entre pour ``l'entrept'') si il est implicite que ces donnes sont fournies la demande d'un processus. Le DFD ne reprsente pas une action faite sur ou par un ``entrept''. 4. Flot de donnes : C'est le composant le plus simple. Il est reprsent par une flche avec le nom de la ``variable'' transmise au-dessus. Un flot de donne est un gnral une valeur simple comme un entier ou une chane de caractres. Nous verrons plus loin qu'on accepte aussi des valeurs ``structures''. Un flot de donnes reprsente le passage d'une donne d'un composant (processus, acteur ou ``entrept'') un autre. Il ne fait aucune modification sur la donne, mais la passe seulement de la sortie d'un composant vers l'entre d'un autre. Si on veut envoyer la sortie d'un composant en entre de deux diffrents composants, on peut le reprsenter par une fourche. Le nom de la donne est indiqu sur la flche avant la fourche, mais pas aprs sur les flches divergentes car elle reprsentent la mme donnes. Le contraire n'est pas possible, plusieurs processus, acteurs ou ``entrepts'' ne peuvent pas donner en sorties la mme donne. La mthode propose aussi de dcomposer une donne complexe (structure) dans ses composants. On le reprsente aussi par une fourche avec le nom de la donne (structure) avant la fourche. Mais cette fois ci, on indique en plus le nom de chaque composant sur la flche qui le concerne. L'inverse est possible dans ce cas, plusieurs composants peuvent produire en sortie des parties qui vont tre regroupes dans une donne structure. On reprsente cela par plusieurs flches avec le nom des parties qui se runissent en une flche avec le nom de la donne structure. Cette partie est discutable car une donne structure est en fait un objet (instance d'une classe). On peut donc plutt penser reprsenter la mme information en utilisant les acteurs. Finalement, notons que la mthode OMT autorise la cration d'un objet partir d'un processus. Ce n'est pas une ide habituelle dans les DFDs. Un flot de donne qui gnre un nouvel objet est not diffremment, c'est une flche avec un triangle vide (non plein) au bout. Dans la partie suivante nous dressons un bilan des trois modlisations que nous venons de prsenter. 1.2.4. Un bilan

Comme le montre la figure 5 ci-dessous, les trois modles sont complmentaires et chaque modle fait rfrence aux autres.

Figure 5 : Interactions entre les trois modles Par exemple les oprations du modle objet correspondent aux vnements du modle dynamique et aux fonctions du modle fonctionnel. Le modle fonctionnel donne un peu les algorithmes des actions (du modle dynamique) ou oprations (du modle objets). Mais attention, ce n'est pas vraiment un algorithme, il n'y a pas de structure de contrle comme les boucles ou le test. 1.3 Les patterns orients objet Les design patterns sont des modles de solution pour des problmes spcifiques que l'on retrouve dans de nombreux systmes orients-objets et qui rendent la conception plus maniable et plus facilement rutilisable Les design patterns proposs dans [Gamma 95] marquent le dbut de l'utilisation des patterns dans le domaine du dveloppement des systmes d'information. Ces patterns sont utiliss dans la conception dtaille et visent la production de solutions orientes objet rutilisables. Depuis, de nombreuses propositions ont t faites, soit pour tendre l'utilisation de ce mcanisme d'autres phases du dveloppement, soit pour proposer dans la partie solution des fragments de dmarche. Les design patterns de Gamma Les analysis patterns de Fowler UML et les patterns Les uses cases et les patterns

2. Dmarche de conception oriente objet

L'approche objet est base sur le principe qu'il est possible de structurer un systme logiciel sous forme de classes organises avec des liens. Une dmarche de modlisation objet est guide par deux principes : le principe de localisation qui permet de raisonner sur une classe indpendamment des autres classes, le principe de conception ascendante selon lequel un systme est obtenu par assemblage de classes. Le style de conception par objets est caractris par un ensemble de techniques distinctives. 2.1. La philosophie de la conception : la conception ascendante Revoyons certaines ides de base de la conception par objets. En pure approche objets, les classes fournissent le seul mcanisme de structuration par objets. Elles doivent tre considres comme des entits autonomes relies entre elles par des relations : Cette autonomie est essentielle pour la rutilisabilit. Quoique l'on pourrait imaginer des techniques descendantes de conception par objets, la conception ascendante s'allie mieux ces types de conception. "Descendant" et "ascendant" sont des caractristiques extrmes : Car on ne se met jamais construire un systme sans considrer l'ensemble des composants disponibles. "Descendant" et "ascendant" sont en fait des caractristiques. La diffrence rside dans le fait, que : Le concepteur descendant se concentre sur son problme spcifique, alors que le concepteur ascendant essaie autant que possible d'utiliser des composants existants. Lorsqu'il dcouvre qu'un nouveau composant doit tout de mme tre produit, il essaie de lui donner un caractre gnral, afin que les futurs dveloppements puissent le rutiliser. Les classes se prtent naturellement la rutilisation ascendante, l'extension et la combinaison. 2.2. Les grandes tapes de la conception La conception par objets est une dmarche simple, et qui s'avre relativement naturelle une fois utilise. La difficult rside plus dans le mode de pense "objet" que dans le fait de disposer ou non de mthode, qui ne constitue de toute faon qu'un garde fou ou mieux un guide pour la ralisation d'une application. C'est donc au mode de pense lui mme qu'il est important de se consacrer. Les principes de la conception reposent sur quatre principes essentiels : La notion de rification, ou comment faire un objet de quelque chose. L'autonomie et la localit, ou comment penser dans les propres termes de l'objet.

 La composition et l'affinage, ou comment structurer les objets. La gnricit, ou comment dvelopper des applications de manire abstraite. 2.2.1. La notion de rification Les conceptions traditionnelles se focalisent sur les traitements. Ces conceptions s'opposent aux conceptions par objets qui se focalisent sur "la chose", ce qui doit tre manipul. Ainsi, concevoir par objets c'est rpondre la question : "De quoi parle t-on?". Dfinition : La rification est l'opration essentielle du paradigme objet par lequel quelque chose (physique, relation, vnement) est reprsente informatiquement sous la forme d'objets. 2.2.2. Autonomie et localit Concevoir un programme par une mthode objets, c'est, dcomposer le logiciel en units indpendantes o chaque unit dispose de sa propre mmoire locale et des oprations qu'elle sait effectuer. Chaque objet est une cellule, une "brique" de base pour la conception d'un objet (classe) complexe. La grosse difficult rside dans le fait que si les concepts de bases ne sont pas compliqus, leur mise en uvre ncessite une vritable conversion de pense. C'est ce que l'on appelle l'autonomie et la localit . L'autonomie permet de considrer les objets comme des entits part entire. La localit permet, par opposition au global, de considrer les objets comme des entits individuelles. 2.2.3. La composition et l'affinage L'art de la conception par objets, c'est : savoir utiliser ce qui a dj t crit. En utilisant la composition des "classes - objets", et de "l'hritage", le concepteur n'crit que la diffrence ncessaire la ralisation de son application. Ainsi, il compose pour constituer des entits part entire et il affine pour dcrire un logiciel en terme de logiciels dj existants, on utilise les hritages des objets gnriques. Au dbut, il dfinit les classes les plus spcifiques et au fur et mesure que l'on remonte dans la hirarchie, il gnralise les entits. 2.3. Le cycle gnral Un cycle de conception s'effectue en cinq tapes : Identifier les entits du domaine. Structurer le domaine en analysant les proprits des entits et des relations. Identifier les oprations que savent effectuer ces entits. Dcrire prcisment ces oprations en les reliant des messages. Dcrire le lancement du programme.

Identifier les entits du domaine C'est la phase la plus importante, car on dtermine les classes les plus importantes. Au fur et mesure, les classes sont enrichies, distingues et fusionnes. Les classes principales correspondent aux principaux concepts du domaine. La difficult rside dans l'obtention des "bonnes" classes. Gnralement, on prend un noyau minimal que l'on enrichit. On essaie de donner une liste exhaustive des entits et on les reprsente. Structurer le domaine Une fois les classes dfinies, il faut ensuite les organiser et les relier. Dans un premier temps, on fait apparatre les relations de type taxonomique. Dans un deuxime temps, on fait apparatre les relations de type mronomique. Ces relations de type mronomique peuvent tre l'intrieur d'une mme hirarchie ou relier deux hirarchies diffrentes. Identifier les oprations Dans un premier temps, il faut analyser les aspects dynamiques. C'est--dire, identifier les oprations que l'on veut effectuer sur les objets, puis les implmenter sous forme de mthodes. On s'intresse alors, l'ensemble des messages, sans distinction apparentes, puis on individualise en tenant compte de l'interaction entre les objets. Gnralement, les oprations remontent vers les classes suprieures. Dcrire les oprations Cette phase consiste coder dans le langage choisi, les classes, les objets et les mthodes. Gnralement, il vient se greffer des classes et des mthodes annexes la programmation. Lancer l'excution Cette phase consiste crer des instances initiales, leur envoyer des messages pour dmarrer le processus.

Le programme se droule ensuite par envoi de messages classes. C'est ce niveau qu'intervient les mises au point.

Conclusion
Dans cet squence nous avons prsent les concepts gnraux de la modlisation objet ainsi qu'une dmarche de conception, et ce indpendamment de toute mthode particulire. Dans la squence suivante nous commenons aborder l'histoire des mthodes de conception, la gense du langage de modlisation UML (Unified Modelling Language), rsultat de l'unification de plusieurs mthodes objet, et l'impact (grandissant) de UML aujourd'hui.

Bibliographie
[Rumbaugh 95] OMT modlisation et conception orientes objet , J. Rumbaugh et Al, dition franaise, Masson 1995.

Analyse et conception oriente objet

3 - Les mthodes orientes objets

Objectifs : Donner un historique des mthodes d'analyse et de conception orientes objet Donner les origines d'UML, le poids de ce langage dans le dveloppement des systmes

1. Les mthodes O.O. avant UML

Vers le milieu des annes 80, les bien faits de la programmation objet commencent tre largement reconnus, et la conception objet semble une approche raisonnable pour qui veut mettre en uvre des langages de programmation objet comme Smalltalk. Du ct de l'analyse par contre, la notion d'analyse objet reste peu vidente. Les entreprises ont en effet dvelopp cette poque une solide connaissance des mthodes d'analyse fonctionnelle et de modlisation smantique des donnes. Les informaticiens s'emploient donc tout naturellement juxtaposer une phase de conception objet une phase d'analyse fonctionnelle. Cette manire de procder prsente de nombreux inconvnients lis au changement de paradigme. Le passage de l'analyse fonctionnelle la conception objet ncessite une traduction des lments de modlisation fonctionnelle aux lments de modlisation objet, qui est loin d'tre vident et naturel. Il faut casser les lments de modlisation d'une approche pour construire les fragments de modlisation de l'autre approche. Tout ceci implique beaucoup d'efforts pour un rsultat gnralement assez peu satisfaisant. Durant la dernire dcennie, des applications objet depuis l'analyse des besoins jusqu' la ralisation- ont t dveloppes dans tous les secteurs d'application. L'exprience acquise sur ces projets permet de savoir comment enchaner les diffrentes activits selon une approche totalement objet. 1.1. La prolifration des mthodes objet La premire moiti des annes 90 a vu fleurir une cinquantaine de mthodes objet. Cette prolifration est le signe d'une grande vitalit de l'objet mais aussi le fruit d'une multitude d'interprtations de ce qui est objet, de ce qui l'est moins, et de ce qui ne l'est pas du tout. L'examen des mthodes dominantes permet alors de dgager un consensus autour d'ides communes. Les grands traits des objets, repris par de nombreuses mthodes, s'articulent autour de la notion de classe, d'association (dcrite par James Rumbaugh), de partition en sous-systmes (Grady Booch) et

autour de l'expression de besoins partir de l'tude de l'interaction entre l'utilisateur et le systme (les use case d'Ivar Jacobson). Enfin, les mthodes bien implantes comme celles de Booch et OMT (Object Modelling Tachnique) se sont renforces par l'exprience, en adoptant les lments mthodologiques les plus apprcis par les utilisateurs. 1.2. Rapprochement de Booch et OMT Les deuximes moutures des mthodes de Booch et OMT, appeles respectivement Booch'93 et OMT-2, se sont rapproches tant est si bien qu'elles sont devenues plus ressemblantes que diffrentes. Les variations subsistantes sont minimes et concentres principalement dans la terminologie et dans la notation. Booch'93 s'inspire d'OMT et adopte les associations, les diagrammes de Harel, les traces d'vnements etc. OMT-2 s'inspire de Booch et introduit les flots de messages, les modles hirarchiques et les sous-systmes, les composants modles, et surtout, retire du modle fonctionnel les diagrammes de flot de donnes, hrits d'un pass fonctionnel et peu intgrs avec la forme gnrale d'OMT. A ce stade, les deux mthodes offrent une couverture complte du cycle de vie, avec toutefois une diffrence notable dans l'clairage. Booch'93 insiste plus sur la construction alors qu'OMT-2 se concentre sur l'analyse et l'abstraction. Nanmoins, il n'existe pas entre les deux mthodes aucune incompatibilit majeure. Les concepts objet ont souvent une histoire complique et imbrique. Les lments prsents dans le tableau ci-dessous se sont dgags de l'exprience de mise en uvre des diffrentes mthodes et ont marqu l'effort d'unification des mthodes de Booch et OMT. Origine Elment Catgories et sous-systmes Classes singletons et objets composites Description des oprations, numrotation des messages Frameworks, patterns et notes Automates (Statecharts) Cas d'utilisation (use cases) Pr et post-conditions Classification dynamique, clairage sur les vnements Associations Cycle de vie des objets Responsabilits (CRC)

Booch Embley Fusion Gamma et al. Harel Jacobson Meyer Odell OMT Shlear-Mellor Wirfs-Brock

1.3. Vers un langage unifi pour la modlisation L'unification des mthodes de modlisation objet est rendue possible parce que l'exprience a permis de faire le tri entre les diffrents concepts proposs par les mthodes existantes. Partant de la constatation que les diffrences entre les mthodes s'amenuisent et que la guerre des mthodes ne fait plus progresser la technologie objet, Jim Rumbaugh et Grady Booch dcident fin 94 d'unifier leurs travaux au sein d'une mthode unique : la mthode unifie (the Unified Method). Une anne plus tard, ils sont rejoints par Ivar Ajcobson, le crateur des cas d'utilisation (uses cases), une technique trs efficace pour dtermination des besoins. Booch, Jacobson et Rumbaugh se fixent quatre objectifs : Reprsenter des systmes entiers (au-del d'un seul logiciel) par des concepts objets, tablir un couplage explicite entre les concepts et les artefacts excutables, Prendre en compte les facteurs d'chelle inhrents aux systmes complexes et critiques, Crer un langage de modlisation utilisable la fois par des humains et les machines. Les auteurs de la mthode unifie atteignent trs rapidement un consensus sur les concepts fondamentaux de l'objet. En revanche, la convergence sur les lments de notation est plus difficile obtenir et la reprsentation graphique retenue pour les diffrents lments de modlisation connatre plusieurs modifications. La premire version de la description de la mthode unifie a t prsente en octobre 1995, dans un document intitul Unified Method V0.8. Ce document a t largement diffus et les auteurs ont recueilli plus d'un millier de commentaires dtaills de la part de la communaut des utilisateurs. Ces commentaires ont t pris en compte dans la version 0.9 parue en juin 1996, amis c'est surtout la version 0.91, disponible depuis octobre 1996, qui permet de noter l'volution de la mthode unifie. La principale modification consiste en la rorientation de la porte de l'effort d'unification, d'abord vers la dfinition d'un langage universel pour la modlisation objet, et ventuellement ensuite vers la standardisation du processus de dveloppement objet. La mthode unifie (Unified Method) se transforme en UML (The Unified Modelling Language for object-oriented developpment). En 1996, il apparat clairement qu'UML est peru comme un lment de base de plusieurs grandes entreprises. C'est ainsi que se cre un consortium de partenaires pour travailler la dfinition de la version 1.0 d'UML. De cette collaboration nat la description d'UML version 1.0, remise l'OMG le 17 janvier 1997, en vue de sa standardisation durant l'anne 1997.

1.4. En rsum, UML en quelques dates : Annes 70, les premires mthodes d'analyse apparaissent. Ces mthodes privilgient la dcoupe cartsienne fonctionnelle et hirarchique d'un systme. Annes 80, l'approche systmique apparat. Cette approche privilgie la modlisation des donnes et la modlisation des traitements (Merise, Axial, IE...). 1990-1995, les mthodes objet mergent. Il y a alors une prise de conscience de l'importance d'une mthode spcifiquement objet. Les dveloppeurs veulent alors structurer un systme sans centrer l'analyse uniquement sur les donnes ou sur les traitements. Plus de 50 mthodes objet sont apparues durant cette priode (Booch, Classe-Relation, Fusion, OOD, OMT, OOA, OOD, OOM, OOSE...) ! Aucune mthode ne s'est rellement impose. 1995, les premiers consensus naissent : OMT / OOD / OOSE. OMT (James Rumbaugh) : vues statiques, vues dynamiques et vues fonctionnelles d'un systme. Cette mthode est issue du centre de R&D de General Electric ; sa notation graphique est riche et lisible. OOD (Grady Booch) : vues logiques et vues physiques du systme. Cette mthode est dfinie pour le DOD, afin de rationaliser de dveloppement d'applications ADA, puis C++, mais ne couvre pas la phase d'analyse dans ses 1res versions (prconise SADT). Cependant, elle introduit le concept de package (lment d'organisation des modles). OOSE (Ivar Jacobson) : couvre tout le cycle de dveloppement. Cette mthode est issue d'un centre de dveloppement d'Ericsson, en Sude et repose sur l'analyse des besoins des utilisateurs. 1995-1997, l'unification et la normalisation des mthodes existent et UML (Unified Modeling Langage) est cr. Aujourd'hui, UML possde un poids important dans le monde de la conception d'application tout objet.

2. Le poids d'UML aujourd'hui

2.1. UML aujourd'hui : un standard incontournable UML est le rsultat d'un large consensus (industriels, analystes, concepteurs, ) et constitue le fruit d'un travail d'experts reconnus, issu du terrain. De plus, UML est riche car il couvre toutes les phases d'un cycle de dveloppement. Il est ouvert et indpendant du domaine d'application et des langages d'implmentation).

Aprs l'unification et la standardisation, nous verrons bientt l'industrialisation d'UML. En effet, les outils qui supportent UML se multiplient (GDPro, ObjectTeam, Objecteering, OpenTool, Rational Rose, Rhapsody, STP, Visio, Visual Modeler, WithClass...). De plus, il est apparu XMI (format d'change standard de modles UML). UML volue, mais reste stable. En effet, l'OMG RTF (regroupant de nombreux acteurs industriels) centralise, et normalise les volutions d'UML au niveau international. Les groupes d'utilisateurs UML favorisent alors le partage des expriences et de version en version, UML gagne en maturit et prcision, tout en restant stable. UML inclut des mcanismes standard d'auto-extension. La description du mtamodle d'UML devient aussi standardise (OMG-MOF). 2.2. Que permet UML UML n'est pas une mthode ou un processus ! Si l'on parle de mthode objet pour UML, c'est par abus de langage ! Ce constat vaut aussi pour OMT ou d'autres techniques et langages de modlisation. Une mthode propose aussi un processus, qui rgit notamment l'enchanement des activits de production d'une entreprise. UML a donc t pens pour permettre de modliser les activits de l'entreprise, pas pour les rgir (ce n'est pas CMM ou SPICE). Un processus de dveloppement logiciel universel reste encore une utopie, car il est impossible de prendre en compte toutes les organisations et cultures d'entreprises. Un processus est adapt et donc trs li au domaine d'activit de l'entreprise. De plus, mme si un processus constitue un cadre gnral, il faut l'adapter de manire prcise au contexte de l'entreprise. Ainsi, on peut dire que UML est un langage pseudo-formel, fond sur un mtamodle, qui dfinit : Les lments de modlisation (les concepts manipuls par le langage). La smantique de ces lments (leur dfinition et le sens de leur utilisation). Un mtamodle est alors une description trs formelle de tous les concepts d'un langage. Il limite les ambiguts et encourage la construction d'outils. Le mtamodle d'UML permet galement de classer les concepts du langage (selon leur niveau d'abstraction ou domaine d'application) et expose sa structure. Il est est lui-mme dcrit par un mta-mtamodle (OMG-MOF). UML propose aussi une notation, qui permet de reprsenter graphiquement les lments de modlisation du mtamodle. Cette notation graphique est le support du langage UML. De plus UML cadre l'analyse objet, en offrant les diffrentes vues complmentaires d'un systme, qui guident l'utilisation des concept objets et en offrant galement plusieurs niveaux d'abstraction, qui permettent de mieux contrler la complexit dans l'expression des solutions objets. UML peut aussi tre considr comme un support de communication, car sa notation graphique permet d'exprimer visuellement une solution objet. L'aspect formel de sa notation limite aussi les ambiguts et les incomprhensions. Son aspect visuel facilite la comparaison et l'valuation de solutions. Enfin, son indpendance (par rapport aux langages d'implmentation, domaine d'application, processus...) en font un langage universel.

2.3. Les points forts et points faibles d'UML On peut rsumer les points forts en disant que : UML est un langage formel et normalis, que c'est un gain de prcision et un gage de stabilit. UML est un support de communication performant, qu'il permet de cadrer l'analyse et qu'il facilite la comprhension de reprsentations abstraites complexes. Enfin, son caractre polyvalent et sa souplesse en font un langage universel. On peut rsumer les points faibles en disant que : La mise en pratique d'UML ncessite un apprentissage et passe par une priode d'adaptation et que UML n'est pas l'origine des concepts objets, mais en constitue une tape majeure, car il unifie les diffrentes approches et en donne une dfinition plus formelle. Le processus (non couvert par UML) est une autre cl de la russite d'un projet. Or, l'intgration d'UML dans un processus n'est pas triviale et amliorer un processus est un tche complexe et longue. Les auteurs d'UML sont tout fait conscients de l'importance du processus, mais l'acceptabilit industrielle de la modlisation objet passe d'abord par la disponibilit d'un langage d'analyse objet performant et standard.

3. Quelques tmoignages
On peut trouver sur Internet quelques tmoignages d'utilisateurs, qui ont adopts UML dans le cadre de la conception objet. Ci-dessous un exemple de tmoignage recueilli. http://www.ecoswitch.fr/support.html http://www.ecoswitch.fr/developpement.html http://www.ecoswitch.fr/publications.html Thierry Coq, dfricheur de mthodes / Dveloppeur Rfrence | v2.15 | 26 juin 2002 Emmanuel Fayet - efayet@ecoswitch.fr Thierry Coq est responsable du ple Techniques Logicielles Avances de la socit de services Dassault Data Services. Passionn de Gnie Logiciel depuis plus de 10 ans, il retrace sa qute d'une mthode de modlisation des systmes informatiques et nous parle de son coup de cur pour UML. Thierry Coq : Centralien de formation, Thierry Coq a dbut sa carrire en 1988 comme ingnieur la CISI (Compagnie Internationale de Services Informatiques). Il y ralise ses premires missions de conception et d'analyse de systmes dans diffrents domaines scientifiques : nuclaire, aronautique et spatial. En 1993, il est Chef de Projet et Responsable Technique du dveloppement du logiciel de gestion des satellites TDMA (Time Division Multiple Access) de tlcommunication d'Eutelsat. En 1995, il rejoint Dassault Data Services o il pilote la conception et la

mise au point d'un prototype d'atelier systme temps rel. En 1997, il cre et organise un ple Techniques Logicielles Avances ddi la collecte et la diffusion de connaissances de Gnie Logiciel. Aller plus loin sur UML : UML (Unified Modeling Language) est un langage visuel de modlisation de systmes. UML a t invent en 1996 par Booch, Rumbaugh et Jacobson (dont le trio est connu sous le nom des " trois amigos ") puis standardis par l'OMG (Object Management Group) en 1997. UML fournit une boite outils compose de 12 diagrammes types pour tablir la cartographie d'un systme construire. Quelles sont fonctions chez Dassault Data Services ? A Dassault Data Services, j'anime un ple de consultants. Ce ple s'appele : Techniques Logicielles Avances. Il a pour vocation de faire de la veille technologique, de diffuser le savoir-faire ainsi cr, de mettre en place des formations, de soutenir les projets et l'action commerciale de la socit. Dans le cadre de la formation, le ple anime entre 6 et 8 formations UML chaque anne. Aujourd'hui, le ple est form de 5 consultants. Ce sont de vrais consultants qui ont tous entre 8 et 10 ans d'exprience en dveloppement orient objet. Comment avez-vous connu la mthode UML ? Je fais de la mthode depuis trs longtemps. Il faut que je remonte en arrire : je ne suis pas informaticien d'origine mais ingnieur gnraliste. J'ai commenc ma carrire dans la physique nuclaire et celle des plasmas. Puis je me suis tourn vers l'aronautique. Dans les 2 cas, je me suis trouv assez insatisfait des techniques de travail avec mon outil principal qui tait l'informatique. Progressivement, j'en suis venu chercher des moyens d'amliorer ma manire de travailler sur des projets et celle de mes collaborateurs. Quelles difficults rencontriez-vous cette poque ? Je me suis aperu que c'tait trs difficile de dire ce que je voulais et de communiquer ce que j'avais fait. J'ai trouv aussi par certains symptmes que nous avions des moyens informatiques qui n'taient pas la hauteur de ce que l'on voulait faire. Par exemple au dbut de ma carrire, le FORTRAN nous limitait 6 ou 8 caractres pour un nom de variable. Pour moi, c'tait un symptme d'une non-expression. Cette limitation nous billonnait et en nous billonnant, nous perdions un effet norme de communication avec un autre informaticien ou avec un client. J'ai cherch des outils et des moyens pour pouvoir parler nouveau avec le code. Un autre symptme, c'tait ces gens qui me demandaient des taux de commentaire norme dans le code. En fait, c'tait le symptme de l'chec du langage que je voulais utiliser. Si le langage que j'utilisais en informatique avait t bien fait, je n'aurais pas ou presque pas eu besoin de commentaires. Comment rsumeriez-vous cette situation ? En informatique, je n'avais pas de mthodes de travail mais plutt des recettes de cuisine. Ce n'est pas tout fait la mme chose ! J'ai eu la chance de partir sur des projets importants notamment le projet europen HERMES pour lequel j'ai fait du gnie systme et de l'analyse fonctionnelle. Il s'agissait de la modlisation d'un vhicule spatial. Nous l'avons modlis dans une mthode qui s'appelait SADT (Structured Analysis and Design Technique). C'est une mthode d'analyse fonctionnelle qui permet d'avoir une reprsentation abstraite d'un systme : un

logiciel, un matriel ou une combinaison des deux. J'ai pu constater sur le projet HERMES la fragilit de l'analyse fonctionnelle un changement de spcification. Il ne faut pas se le cacher : HERMES a t un projet formidable mais trs ambitieux, peut-tre trop ambitieux pour les moyens financiers de l'Europe. Les chiffrages des demandes dpassaient les budgets disponibles. Du coup, les spcifications changeaient de manire trs rgulire. Nous avons eu le passage de 5 astronautes 3 astronautes, une rduction de la charge utile et du poids de la navette, une diminution de la dure de la mission de 1 mois 15 jours. Tous ces changements avaient de nombreux impacts sur l'analyse fonctionnelle. Nous travaillions un an une modlisation. Nous obtenions quelque chose qui tenait peu prs la route et nous avions la visite d'un ministre et puisil fallait tout recommencer. Dans quel tat d'esprit tiez-vous aprs ce projet ? A l'poque, je ne l'ai pas peru clairement, mais cela m'a permis d'tre assez insatisfait sur les analyses fonctionnelles. Je trouvais que la modlisation tait trs bien. J'ai pu voir par exemple que le diagramme SADT passait trs bien auprs de gens qui n'avaient pas lu ou fait du SADT. Le diagramme tait un bon moyen de communication. Plus tard, j'ai fait du HOOD (Hierarchical Object Oriented Design) qui est la mthode objets du CNES (Centre National d'Etudes Spatiales). L'ide de HOOD l'poque tait de faire une analyse fonctionnelle pour le besoin avec SADT et ensuite de passer en orient objet uniquement au moment de la phase de conception. HOOD tait calqu conceptuellement sur un langage formidable qui tait ADA 83 qui avait t conu comme un langage de conception objets. HOOD a t pour moi une vritable rvlation : j'ai travaill en HOOD plus tard je suis devenu formateur en HOOD. J'ai t amen crire, pour le compte de Maurice Heitz qui tait l'un des co-inventeurs de HOOD, une premire version du manuel pdagogique de la mthode. A l'poque, j'ai commenc investiguer OMT (Object Modelling Technique) parce que je n'tais pas satisfait de SADT en tant que mthode d'analyse. OMT, qui provenait du travail de Rumbaugh collait bien avec les nouveaux concepts orients objets que j'avais dans mes langages C++ et Pascal Objet. En 1995, quand je suis venu DDS (Dassault Data Services), j'ai t missionn pour raliser un atelier de gnie logiciel temps rel et orient objet. Il a d'abord fallu dfinir la mthode du projet. Nous avons utilis OMT pour dfinir une mthode en faisant ce qui s'appelle un mta-modle, c'est dire un modle du modle en quelque sorte. Ce mta-modle a t construit entre 1995 et 1996. Cette priode a concid avec l'arrive sur le Web des premiers mta-modles UML (Unified Modeling Language). Nous les avons confronts avec les notres et nous nous sommes dit : " Faisons pareil ! " Ds 1997, nous avons donc migr nos travaux vers UML. A partir de 1998, nous avons initi un plan de formation UML qui s'est largi depuis un maximum de collaborateurs de la socit. Quelle place a pris UML dans vos projets ? Il faut distinguer la doctrine et la pratique en la matire. La doctrine de DDS est claire : l'avantage principal d'UML, c'est la communication que cela procure. Le point cl, c'est d'avoir une notation graphique que nous pouvons utiliser pour communiquer entre les dveloppeurs et surtout entre les dveloppeurs et les non-dveloppeurs. Aprs, il y a les conditions opratoires sur le terrain. Pour mettre en place UML, il faut convaincre les dveloppeurs, les chefs de projets, les clients. Donc les moyens pour remporter la conviction vont tre trs pragmatiques et vont dpendre de la culture du client, du projet et des objectifs atteindre. UML n'est pas une fin en soi mais un outil dans la conduite des projets. Par exemple dans certains projets, nous btissons le plan de dveloppement en fixant des priorits sur les diffrents cas d'utilisation d'UML du projet. D'autres clients auront des besoins de tests importants : nous nous servons alors des diagrammes de squence d'UML comme moyen de spcifier les tests. Certains clients nous fournissent des logiciels dj crits et nous demandent de faire du maintien en condition oprationnel ou de la mise en place d'volution. Nous utilisons alors UML pour faire de la rtro-conception et gnrer des diagrammes de classes qui fournissent une vision conceptuelle du code source et de

l'architecture gnrale du logiciel. Nous pouvons alors dire avec UML : " Voil l'tat actuel du logiciel. Voil ce que vous souhaitez obtenir et le processus pour y parvenir. " UML est donc pour vous une bonne surprise ? Ce n'est certainement pas la panace ni la fin de l'innovation mthodologique. Mais nous sommes sur une bonne voie. UML est pour nous plus qu'une notation : c'est un vritable changement de paradigme. Beaucoup de nos dveloppeurs ou de nos clients utilisent des langages orients objets comme C++ ou Java mais sans y associer de conception objet. L'intrt d'UML pour nous, c'est de fournir l'approche objet sur les projets avec une certaine indpendance des langages d'implmentation. Le changement de paradigme se traduit par la mise en place d'une dmarche nouvelle qui passe par la promotion du travail sur l'architecture, la modularit et sur la communication avec le client. Le fait de rflchir un modle et de se poser des questions nous donnent des moyens de diagnostic dans la conduite des projets. Le modle UML n'aime pas les zones d'ombre. Quels sont vos espoirs ou vos craintes pour UML aujourd'hui ? Je prfrerais plutt parler de danger. Le danger serait que UML soit approprie par les informaticiens et qu'il devienne un outil purement d'informaticien. Je voudrais au contraire qu'UML sorte du milieu informaticien pour gagner le milieu gnral du Gnie Systme, du Gnie Electronique ou du Gnie mcatronique. UML a vocation une certaine universalit dans la conception des systmes et pas seulement des systmes logiciels. Le problme est qu'UML peut rater la marche s'il devient un nouveau jargon informatique.

Hormis ce tmoignage difiant, une visite sur le site internet www.uml.org peut permettre de mesurer l'impact d'UML aujourd'hui. Dans cet esprit, on pourra notamment trouver sur ce site, un ensemble de success stories d'entreprises reconnues qui ont adhr au langage unifi et qui communiquent sur cet aspect de leur travail.

Bibliographie
[ Muller 97 ] Muller P.A., Modlisation objet avec UML , Eyrolles, 1997 [ Kettani et al. 2000 ] , Kettani N., Mignet D., Par P., Rosenthal-Sabroux C., De Merise UML , Eyrolles, 2000.

Analyse et conception oriente objet

4 - Introduction au langage UML

Objectifs : Acqurir les principes du langage UML et la notation associe. Comprendre la philosophie de ce langage et ses principes d'utilisation dans le contexte de la conception des systmes d'information. Mots cls : Noyau du langage UML, Elments de base, relations, diagrammes, modles, vues

Caractristiques du langage UML

UML est un langage de modlisation graphique et textuel destin comprendre et dcrire les besoins, spcifier et documenter des systmes, dfinir des architectures logicielles, concevoir des solutions et communiquer des points de vue. Ce langage prsente les caractristiques suivantes :

L'orientation objet ..mais pas seulement

UML est bas sur les principes du paradigme objet. Les principaux concepts de ce paradigme sont pris en compte. Par ailleurs, il existe dans UML des outils de reprsentation qui ne sont pas directement issus de l'approche objet. Par exemple les cas d'utilisation dcrivent les fonctionnalits d'un systme sous la forme d'interactions utilisateur/systme; il s'agit d'une description relativement loigne d'une description en termes d'objets.

Une boite outils mais pas une mthode

UML est un ensemble cohrent de dfinitions de concepts avec leurs interrelations. UML dfinit un langage commun qui peut tre utilis pour les changes entre les outils de modlisation visuelle sans imposer aux diteurs et aux dveloppeurs une mthodologie particulire. Cette approche laisse ses utilisateurs une grande libert et leur permet de conserver leurs propres styles et leur propre dmarche en assurant un haut niveau de cohrence et de partage. UML tablit des standards de notation mais n'impose pas une faon de les appliquer. UML ne prdfinit ni de dmarche de dveloppement ni de niveaux d'abstraction. De ce point de vue UML doit tre considre comme une "boite outils" que ses utilisateurs peuvent utiliser pour dfinir leur propre dmarche de dveloppement et leurs propres modles de produit.

La gnricit de l'approche
UML, en tant que boite outils dfinit un langage commun de modlisation. Ce langage est compos d'un jeu de concepts (noyau) utilisables dans de nombreux contextes. Un autre point fort de cette approche est sa gnricit. En effet il est possible d'adapter certains concepts du noyau pour prendre en compte les particularits des diffrents contextes d'application. Le mcanisme qui autorise ces adaptations est appel strotype. Le caractre gnrique de cette approche a conduit progressivement proposer des adaptations d'UML pour prendre en compte les spcificits de tel ou tel type d'architecture, de telle ou telle classe de systme Chaque adaptation appele un "profile" est construite par extension des concepts du noyau. Dans les adaptations aujourd'hui existantes on peut citer l'adaptation aux systmes temps rel [ ] et aux systmes multi-agents [ ]. Il existe dans le manuel de rfrence d'UML deux extensions proposes, celle qui dfinit les concepts mis en uvre dans le processus de dveloppement d'Objectory (Extension for Software Development Process) et celle qui dfinit les concepts mis en uvre dans l'activit de modlisation conceptuelle (Extension for Business Modelling).

Une capitalisation des bonnes pratiques de la conception oriente objet

UML reprsente l'tat actuel de l'volution des techniques et mthodes de dveloppement de logiciels. Ce langage runit les techniques et les pratiques mises en uvre par les dveloppeurs de logiciels. Il constitue donc le rsultat d'un travail de capitalisation d'expriences dans le domaine de la conception oriente objet. Il intgre les techniques de modlisation pour lles diffrentes dimensions d'un systme (structure, comportement, fontion.). Il intgre aussi des techniques de modlisation de structures gnriques (patterns, frameworks.).

L'unification des concepts

Les concepts proposs sont utilisables travers les diffrentes activits d'un processus de dveloppement. Ainsi l'espace du problme (objets mtier) et l'espace de la solution (objets informatiques) peuvent tre reprsents avec la mme notation. Cette unification des concepts est parfois droutante pour ceux qui ont l'habitude d'utiliser des formalismes diffrents aux diffrentes tapes du dveloppement. Elle facilite cependant une meilleure traabilit des dcisions depuis la spcification jusqu'au codage.