Le processus d’une m´ethode d’analyse et de conception par objetsconception par objets

Le processus d’une m´ethode d’analyse et de conception par objets d´ecrit les ac-tivit´es n´ecessaires `a l’obtention des diff´erentes mod`eles sous forme de diagrammes, formulaires et textes, ainsi que l’enchaˆınement de ces activit´es. Autant les outils peuvent ˆetre utiles (et mˆeme n´ecessaires) pour l’obtention des mod`eles, autant, pour le processus, il est difficile d’aider l’utilisateur et d’automatiser certaines tˆaches. Cela r´eduit bien souvent la mise en œuvre du processus `a l’application de quelques r`egles de bon sens, car sans support informatique il est tr`es difficile de respecter tous les d´etails. Dans le travail sur UML, le processus n’est d’ailleurs pas pris en compte pour l’instant (voir 4.5.1)9. Comme pour les mod`eles et leurs notations, nous d´ecrivons ci-dessous le processus de la m´ethode OMT.

4.3.1 Le processus de la m´ethode OMT

La m´ethode OMTs’int´eresse aux phases d’analyse, de conception et de codage d’un syst`eme. La figure 4.7 r´esume le processus de cette m´ethode.

IMPLÉMENTATION ANALYSE MODÈLE À OBJETS MODÈLE DYNAMIQUE MODÈLE FONCTIONNEL CONCEPTION DU SYSTÈME CONCEPTION DES OBJETS CONCEPTION FIG. 4.7: Le processus de la m´ethode OMT La phase d’analyse

La phase d’analyse consiste `a d´ecrire le syst`eme (`a partir d’une d´efinition des be-soins obtenue pr´ec´edemment) en produisant des mod`eles d´ecrits dans la section 4.2 : le mod`ele `a objets, le mod`ele dynamique et le mod`ele fonctionnel. La fl`eche de re-tour dans la casANALYSEindique que cette description peut (et doit) ˆetre am´elior´ee jusqu’`a l’obtention d’un ensemble de diagrammes satisfaisants. Pour produire cha-que mod`ele, la m´ethode OMT donne une liste de tˆaches `a r´ealiser et des conseils

9. Il faut d’ailleurs noter le changement d’appellation : au d´ebut des travaux sur l’unification des m´ethodes, UMLs’appelait m´ethode unifi´ee.

pratiques pour y parvenir. Nous donnons ci-dessous `a titre d’exemple les tˆaches propos´ees par OMTpour construire le mod`ele `a objets :

• identifier les objets et les classes ;

• ´etablir un dictionnaires de donn´ees ;

• identifier les relations (dont les agr´egations) entre les objets ;

• identifier les attributs des objets et des relations ;

• organiser et simplifier les classes en utilisant l’h´eritage ;

• v´erifier que toutes les donn´ees pourront ˆetre acc´ed´ees correctement ;

• am´eliorer le mod`ele par it´erations successives ;

• regrouper les classes dans des modules.

Il s’agit simplement de la liste de ce qui est r´ealis´e naturellement quand on cherche `a produire un mod`ele `a objets d’une situation r´eelle. Pour quelqu’un qui aborde ce type d’activit´e, les conseils qui sont associ´es `a ces tˆaches peuvent permet-tre de gagner un peu de temps. Par exemple, pour la premi`ere tˆache il est pr´econis´e d’´eliminer les classes vagues (pour lesquelles on n’est pas capable de donner une d´efinition claire et non ambig ¨ue), redondantes (qui ont par exemple des attributs en commun) ou hors domaine.

La phase de conception

Dans la m´ethode OMT, la phase de conception se d´ecompose en deux ´etapes : la conception du syst`eme et la conception des objets, qui doivent constituer des affine-ments successifs des mod`eles issus de la phase d’analyse, en prenant en compte des contraintes d’impl´ementation.

La conception du syst`eme

La conception du syst`eme traite de la modularit´e de l’application r´esultante : elle doit organiser les vues du syst`eme issues de la phase d’analyse, en les d´ecomposant en sous-syst`emes selon des crit`eres fonctionnels ou physiques. Cette d´ecomposition a ´egalement pour objectif d’obtenir une bonne modularit´e du syst`eme. Si cela est pertinent pour le syst`eme, c’est durant cette ´etape que les probl`emes de concurrence et d’allocation de processeurs sont trait´es. Le stockage des donn´ees doit ´egalement ˆetre abord´e. Il s’agit de probl`emes d’architecture informatique du syst`eme, assez ind´ependants des mod`eles `a objets.

La conception des objets

L’objectif de la conception des objets est de d´efinir pr´ecis´ement les classes d’ob-jets avec leurs attributs et m´ethodes. Cette d´efinition se fait principalement `a partir du mod`ele `a objets obtenu durant la phase d’analyse, mais les mod`eles dynamiques et fonctionnels doivent aussi ˆetre utilis´es. Elle doit prendre en compte les possi-bilit´es et les limites du langage qui sera utilis´e pour l’impl´ementation. Par exem-ple, si le langage ne g`ere pas l’h´eritage multiexem-ple, et que celui-ci est utilis´e dans le

mod`ele `a objets de la phase d’analyse, il faut modifier le diagramme de classes en cons´equence. Le mod`ele `a objets obtenu doit ˆetre le plus proche possible de celui qui sera impl´ement´e dans le langage. C’est ´egalement durant cette ´etape que sont r´ealis´es les optimisations de la hi´erarchie des classes (par exemple, la cr´eation de classes abstraites regroupant des attributs et des m´ethodes abstraites communes `a plusieurs classes), la conception des algorithmes impl´ement´es dans les m´ethodes, les choix d’impl´ementation des associations (attributs, classes, etc.). La description des activit´es de cette ´etape dans la m´ethode OMTest du type((conseils g´en´eraux)). Par exemple, pour le choix et la mise en œuvre d’un algorithme la m´ethode OMT

pr´econise de :

• choisir des algorithmes qui minimisent le co ˆut d’impl´ementation des op´e-rations ;

• utiliser des structures de donn´ees adapt´ees aux algorithmes ;

• d´efinir de nouvelles classes et de nouvelles op´erations si n´ecessaire ;

• mettre les op´erations dans les bonnes classes.

C’est `a partir des mod`eles obtenus durant cette phase, et principalement du mod`ele `a objets, que le code sera g´en´er´e par les outils proposant cette fonction-nalit´e.

La phase d’impl´ementation

La phase d’impl´ementation des m´ethodes d’analyse et de conception par objets consiste `a produire le code `a partir des mod`eles issues de la phase de conception. Deux aspects sont `a consid´erer pour cette phase : les conseils donn´es par les auteurs des m´ethodes, et l’utilisation d’outils pour produire du code automatiquement.

En ce qui concerne OMTet le premier aspect, [Rumbaugh et al., 1991] donne no-tamment des exemples pour trois langages `a objets, C++ (voirchapitre 3), SMALL

-TALKet EIFFEL(voirchapitre 2). Il explique comment sont r´ealis´ees les fonction-nalit´es suivantes dans ces trois langages : la d´efinition des classes, la cr´eation des objets, l’appel de m´ethodes, l’utilisation de l’h´eritage, l’impl´ementation des associa-tions. Les auteurs donnent ´egalement des conseils pour r´ealiser une impl´ementation dans un langage sans objets comme C, ADA, ou FORTRAN, par exemple.

Le mod`ele `a objets peut ´egalement ˆetre utilis´e pour g´en´erer un sch´ema de base de donn´ees. Pour les bases de donn´ees `a objets (BDO), la g´en´eration peut ˆetre d´elicate sur des points comme la gestion des associations ou l’h´eritage multiple si ces fonctionnalit´es n’existent pas dans la base. Pour les bases de donn´ees re-lationnelles, il existe des mani`eres de faire correspondre des d´efinitions de clas-ses et de tables relationnelles [Wald´en et Nerson, 1995 ; Rumbaugh et al., 1991 ; Demphlous et Lebastard, 1996].

La production automatique de code au sein d’outils10 se r´eduit `a la g´en´eration de squelettes de d´efinition de classes ; dans le meilleur des cas (suivant le langage

10. appel´es AGL – Atelier de G´enie Logiciel, en franc¸ais ; CASE tool – Computer Aided Software

cible), la traduction des associations est ´egalement r´ealis´ee. Cela s’explique par le fait que les ´el´ements du mod`ele `a objets (les classes, les attributs, les op´erations, et, avec certains langages, les associations) sont les seuls qui existent dans les langages `a objets. Par exemple, l’´etat d’un objet n’est pas manipulable en tant que tel dans les langages `a objets. D’o `u la difficult´e des concepteurs d’AGL pour r´ealiser des outils permettant de produire du code `a partir d’une description issue d’une m´ethode.

La notion d’association n’existe pas dans les langages C++ (voirchapitre 3) ou EIFFEL(voirchapitre 2) : l’impl´ementation doit ˆetre faite au moyen de pointeurs, dont la gestion doit ˆetre assur´ee soit de fac¸on ad hoc par le programmeur, soit grˆace `a des biblioth`eques de classes sp´ecifiques. Les AGL tentent de pallier ce manque en int´egrant par exemple des biblioth`eques de classes C++ offrant les fonctionnalit´es n´ecessaires. Cette approche pose deux probl`emes ; d’une part, toutes les fonction-nalit´es ne peuvent pas ˆetre impl´ement´ees sous forme de biblioth`eques externes : il faudrait parfois intervenir sur le langage lui-mˆeme (par exemple en ajoutant des mots-cl´es pour la d´efinition des classes) ; d’autre part, cette approche lie le concep-teur `a un outil, voire `a un type de machine. Certains langages offrent des fonctionna-lit´es ´equivalentes aux associations (YAFOOL[Ducournau, 1991], voirchapitre 14), ou peuvent les offrir grˆace `a des extensions du langage (CLOS) [Masini et al., 1989]. Les traits de repr´esentation des m´ethodes d’analyse et de conception par objets sont donc plus proches de ceux des langages dits hybrides (voir [Masini et al., 1989]) uti-lis´es pour repr´esenter des connaissances de fac¸on plus naturelle. De plus, bien des traits de repr´esentation sont absents des m´ethodes actuelles : les modalit´es (ou fa-cettes) des langages de frames, les points de vue ou perspectives, etc. (voirchapitre 10, section 3).

Il y a donc une diff´erence importante entre la repr´esentation d´efinie dans le cadre de la m´ethode, et sa traduction dans un langage de programmation. Le code produit doit ˆetre tr`es enrichi pour obtenir un syst`eme complet, car le mod`ele dynamique n’est pas pris en compte lors de la g´en´eration automatique de code. L’utilisation de techniques formelles (voir 4.2.1), bien que tr`es lourde, peut ˆetre une solution, mais la production de code directement `a partir des diagrammes d’´etats serait cer-tainement pr´ef´erable [Andr´e, 1996]. Il est donc extrˆemement difficile de mainte-nir une coh´erence compl`ete entre les mod`eles issus de la m´ethode, d’une part, et le code du syst`eme, d’autre part. Certains outils ins`erent des commentaires par-ticuliers dans le code produit pour retrouver les parties qu’ils ont g´en´er´es, mais ces commentaires peuvent ˆetre d´etruits ou d´eplac´es lors de l’´edition des fichiers source. D’autres, commeOBJECTEERINGqui met en œuvre la m´ethode CLASSE -RELATION, int`egrent des fonctions d’´edition de code, ce qui leur permet de mieux contrˆoler les modifications apport´ees par le programmeur.

4.3.2 Les processus d’autres m´ethodes

Le processus de la m´ethode FUSION est constitu´e des trois phases classiques : analyse, conception et impl´ementation. La phase d’analyse doit ´elaborer le mod`ele `a objets¹¹ et le mod`ele d’interface (mod`eles des op´erations et du cycle de vie). La

11. La traduction franc¸aise de l’ouvrage de r´ef´erence sur la m´ethode FUSIONutilise en fait((mod`eles des objets)).

phase de conception r´ealise les diagrammes d’interaction des objets, et les graphes de visibilit´e ; elle compl`ete ´egalement le mod`ele `a objets par des descriptions de classe (en utilisant les informations des diagrammes d’interaction des objets et de visibilit´e), et des graphes d’h´eritage. Les auteurs donnent aussi un ensemble de conseils pour les trois phases.

La m´ethode BONpropose un processus tr`es d´etaill´e en neuf tˆaches regroup´ees en trois phases :

• collecte : d´eterminer les limites du syst`eme, faire la liste des classes

candi-dates, s´electionner des classes et les regrouper en clusters ;

• description : d´efinir les classes, ´ebaucher les comportements du syst`eme,

d´efinir les interfaces ;

• conception : affiner les entit´es existantes, g´en´eraliser, compl´eter et r´eviser le

syst`eme.

Des mod`eles (sous forme de diagrammes et de formulaires) sont cr´e´es ou mo-difi´es par chaque tˆache ; par exemple, la troisi`eme tˆache de la premi`ere phase (s´elec-tion et regroupement des classes) doit cr´eer l’architecture statique (vue graphique des clusters et des classes) et le dictionnaire des classes, et doit modifier le for-mulaire du syst`eme (description g´en´erale du syst`eme) et les forfor-mulaires des

clus-ters. Comme la m´ethode OMT, la m´ethode BONdonne par ailleurs un ensemble de conseils pour trouver les((bonnes classes)).

Comme on l’a vu, les m´ethodes d’analyse et de conception par objets s’int´eres-sent peu `a la phase de d´efinition des besoins. Dans le meilleur des cas (voir la m´ethode BON ci-dessus), elles identifient des actions dans leur processus. Pour pallier cela, des utilisations conjointes de la m´ethodologie d’acquisition des con-naissances KADS [Schreiber et al., 1993] et de la m´ethode OMTont ´et´e r´ealis´ees. Dans un cas [Ayache et al., 1995], la m´ethode KADS a ´et´e utilis´ee pr´ealablement `a la m´ethode OMT afin de d´efinir les besoins du syst`eme ; dans l’autre cas [Si-boni, 1994], les deux m´ethodes ont ´et´e utilis´ees simultan´ement pour des aspects diff´erents du syst`eme. Une utilisation s´equentielle est une d´emarche assez naturelle : acquisition des connaissances avec KADS, puis analyse et conception avec OMT; cette d´emarche a de plus l’int´erˆet de limiter l’interface entre les deux m´ethodes. La deuxi`eme approche est plus discutable car l’int´egration de KADS et de OMT

doit ˆetre beaucoup plus ´etroite : il faut ´etablir des correspondances entre les entit´es internes des deux m´ethodes, ce qui n’est pas toujours possible selon [Siboni, 1994].

4.4 La r´eutilisation

C’est durant la phase de conception que doivent ˆetre d´etermin´es les moyens informatiques n´ecessaires `a la r´ealisation du syst`eme vis´e. C’est donc lors de cette phase que se pose la question de la r´eutilisation ´eventuelle d’´el´ements existants. Les concepts du mod`ele objet doivent a priori favoriser la r´eutilisation :

• la sp´ecialisation est essentiellement un concept qui permet le partage d’infor-mation et de comportements ;

• la modularit´e permet de r´epartir les informations et les traitements dans diff´e-rentes entit´es ;

• l’encapsulation donne une interface unique et bien d´efinie aux objets. Malgr´e ses qualit´es intrins`eques, l’utilisation du mod`ele objet n’implique pas de pouvoir r´eutiliser imm´ediatement et facilement. Ces derni`eres ann´ees plusieurs propositions tendant `a faciliter la r´eutilisation lors de la r´ealisation d’applications avec les techniques objet ont ´et´e propos´ees. Nous d´ecrivons bri`evement ci-dessous trois types de r´eutilisation : les design patterns, les frameworks et les composants

logiciels, ainsi que les travaux autour de CORBA.

4.4.1 Les design patterns

L’id´ee des design patterns [Gamma et al., 1994] est de capitaliser et de do-cumenter des solutions `a des probl`emes de conception qui apparaissent de fac¸on r´ecurrente dans les applications. Un design pattern est constitu´e d’une part d’un diagramme repr´esentant les classes g´en´eriques qui le constitue, ainsi que les asso-ciations et les envois de messages n´ecessaires, et d’autre part d’un texte d´ecrivant le design pattern avec un exemple et des conseils d’utilisation. UML(voir 4.5.1) propose une notation sp´ecifique pour repr´esenter les design patterns.

Appareil état contrôle EvenementMemorisé dateHeure valeur 0, m 1 0, m 1 SondeTempérature étatOpérationnel contrôleDépasseSeuil seuil DépasseSeuil dateHeure valeurMesurée seuilContrôlé créer

FIG. 4.8: Un exemple de design patterns

La figure 4.8 montre un exemple de design pattern. Il s’agit du probl`eme de contrˆole d’un appareil au moyen de m´emorisation d’´ev´enements. Deux classes sont d´efinies : la classeAppareilet la classeEv´enementM´emoris´e(voir partie sup´e-rieure de la figure 4.8). Il existe une association entre ces deux classes : une instance de la classeAppareilpeut ˆetre associ´ee `a un nombre quelconque d’instances de

la classeEv´enementM´emoris´e. Ce design pattern peut ˆetre appliqu´e au contrˆole d’une sonde de temp´erature avec des d´epassements de seuils de temp´erature. Les propri´et´es´etat,contr^oleetvaleursont transpos´ees dans ce cas respectivement en´etatOp´erationnel,contr^oleD´epasseSeuiletvaleurMesur´ee(voir partie inf´erieure de la figure 4.8).

L’utilisation de ces techniques peut ˆetre utile pour la conception si on est capable de retrouver dans un catalogue la description du design pattern qui correspond au probl`eme pos´e. Mais il peut ˆetre tr`es difficile de retrouver le bon design pattern, mˆeme s’il existe, si la formulation du probl`eme est ´eloign´ee de la d´efinition du

design pattern. Ensuite, si un design pattern a ´et´e consid´er´e comme pertinent, il faut

transposer la solution propos´ee dans le contexte particulier, ce qui doit ˆetre r´ealis´e par le programmeur. Concernant la recherche d’un design pattern r´epondant `a un probl`eme particulier, l’indexation par mots-cl´es est une solution possible mais bien limit´ee. Pour la transposition d’un design pattern donn´e, une proposition consiste `a enrichir le m´eta-mod`ele d’un langage `a objets par des constructions permettant d’exprimer des design patterns. Par exemple, [Ducasse, 1997] propose d’int´egrer un m´eta-mod`ele d’interaction dans un langage `a objets.

4.4.2 Les frameworks

Un framework est constitu´e d’un ensemble de classes offrant des fonctionnalit´es pour un domaine particulier. L’int´erˆet des frameworks est de proposer des points de personnalisation (hot spots), tout en faisant b´en´eficier de fonctionnalit´es com-munes (frozen spots). Cette partie commune peut ˆetre r´eutilis´ee sans adaptation par le syst`eme construit dans le framework. Le m´ecanisme d’h´eritage peut ˆetre un moyen de sp´ecialiser les points de personnalisation et de b´en´eficier des fonctionna-lit´es communes.

CASSIS[Dao et Richard, 1990] est un exemple de tel environnement. Il d´efinit un ensemble de classes repr´esentant une structure g´en´erale de r´eseau (des graphes contenant des sommets et des arˆetes, qui peuvent eux-mˆemes contenir des graphes, et peuvent ˆetre partag´es par plusieurs graphes), sur laquelle sont impl´ement´ees des fonctionnalit´es d’´edition et de manipulation graphiques. R´ealiser une application avecCASSIS, c’est d´efinir ses propres classes de graphes, de sommets et d’arˆetes, en personnalisant certains aspects ; il est par exemple possible de pr´eciser quels sommets et quelles arˆetes peuvent appartenir `a certains graphes, de particulariser la visualisation graphique des sommets et des arˆetes, etc. Les classes de la figure 4.1 (Reseau,FaisceauetNoeud) qui font partie d’une application qui a ´et´e r´ealis´ee avecCASSISh´eritent directement des classes correspondantes de l’environnement (Graphe-k6,Arete-k6etNoeud-k6).

L’avantage d’un framework est que, si celui-ci est bien adapt´e `a l’application `a r´ealiser, le d´eveloppement peut ˆetre tr`es rapide. En revanche, l’utilisateur est tr`es contraint dans la r´ealisation de son application avec un framework. De plus, la r´ealisation d’un framework est une op´eration co ˆuteuse.

4.4.3 Les composants logiciels

Les composants logiciels sont des ´el´ements logiciels r´eutilisables offrant un ser-vice particulier. Ils peuvent ˆetre des biblioth`eques de classes sp´ecialis´ees dans une technique particuli`ere (graphique, structures de donn´ees, etc.) ou de classes m´etier, c’est-`a-dire sp´ecifiques d’un domaine d’activit´e (t´el´ecommunications, gestion ban-caire, etc.). Ces composants peuvent ˆetre r´eutilis´es directement (par h´eritage ou par association) en int´egrant les classes n´ecessaires au syst`eme `a r´ealiser, ou en cr´eant et utilisant des instances de ces classes sur un r´eseau, par exemple. Dans le premier cas, il peut s’agir d’une utilisation conjointe avec les techniques de design pattern ou