Les mod`eles et leurs notations

L’objectif de chacune des phases d’analyse et de conception est de produire un ensemble de mod`eles. Chaque mod`ele permet de repr´esenter tout ou partie des diff´erentes vues que l’on peut avoir sur le syst`eme `a r´ealiser :

• la vue structurelle qui d´ecrit l’ensemble des entit´es utilis´ees dans le syst`eme ;

• la vue comportementale qui d´ecrit les modifications du syst`eme `a la r´eception d’´ev´enements externes ou internes ;

4. Fin 1995, pr`es de la moiti´e des utilisateurs d’une m´ethode d’analyse et de conception par objets utilisaient OMT(source : IDC, march´e nord-am´ericain).

• la vue architecturale qui d´ecompose le syst`eme en sous-syst`emes afin d’en faciliter la compr´ehension.

Chacun des mod`eles est ´elabor´e en utilisant une ou plusieurs notations constitu´ees de formulaires et de diagrammes. Ces notations favorisent la communication entre les diff´erents intervenants, soit au sein d’un outil, soit par l’interm´ediaire de co-pie sur paco-pier. Si ces notations sont mises en œuvre dans un outil informatique, les mod`eles obtenus peuvent ˆetre l’objet de v´erifications automatiques et servir de base `a la production du code de l’application et de la documentation. Nous d´ecrivons ci-dessous les notations des mod`eles propos´es par la m´ethode OMT.

Dans la m´ethode OMT, chacune des vues est repr´esent´ee par un mod`ele diff´erent : le mod`ele `a objets pour la vue structurelle, le mod`ele dynamique pour la vue com-portementale et le mod`ele fonctionnel pour la vue architecturale.

Dans la suite, nous utiliserons le terme m´eta-mod`ele pour d´esigner l’ensemble des concepts permettant de produire un certain type de mod`eles. En particulier, nous appellerons mod`ele objet l’ensemble des concepts communs aux diff´erentes tech-niques objet : les objets regroup´es en classes poss´edant des propri´et´es (attributs ou

m´ethodes), les classes ´etant hi´erarchis´ees par une relation de sp´ecialisation

permet-tant un h´eritage des propri´et´es [Carr´e et al., 1995] (voirchapitres 1 et 12).

4.2.1 Le mod`ele `a objets en OMT

Pour construire des mod`eles `a objets, OMTpropose le mod`ele objet enrichi du concept d’association, issu du m´eta-mod`ele entit´e-association (ER :

Entity-Relation-ship [Chen, 1976]). Ce dernier concept n’existe pas dans les m´eta-mod`eles des

langages `a objets((purs)), comme SMALLTALK ou EIFFEL (voirchapitre 2). En revanche, le concept d’association est pr´esent dans des langages hybrides comme YAFOOL(voirchapitre 14, section 4), ainsi que dans les syst`emes de repr´esentation des connaissances par objets comme TROEPS(voirchapitre 10, section 2).

La notation des mod`eles `a objets propose deux diagrammes : le diagramme de

classes et le diagramme d’instances.

Le diagramme de classes d´ecrit les classes, c’est-`a-dire leurs attributs et leurs

op´erations (les m´ethodes), ainsi que leurs relations (sp´ecialisation, agr´egation,

as-sociation). Le diagramme d’instances montre comment des objets sont reli´es afin de d´ecrire une utilisation typique ou des cas particuliers. Ces diagrammes sont uti-lis´es pour montrer l’existence de classes, d’objets et de relations dans un syst`eme. `A chaque classe peuvent ˆetre associ´es des diagrammes d’´etats (dynamique interne) et des diagrammes de trace d’´ev´enements (dynamique externe) (voir 4.2.2). Les deux composants essentiels de la notation sont les classes et leurs relations. La figure 4.1 montre quelques exemples de notations qui sont comment´es ci-dessous ; les nota-tions compl`etes peuvent ˆetre consult´ees dans [Rumbaugh et al., 1991].

Les classes et les instances

Une classe est repr´esent´ee par un rectangle compos´e de trois parties : le nom de la classe, ses attributs, ses op´erations (voir par exemple les classesFaisceauou

Reseaude la figure 4.1). Une instance est repr´esent´ee par un rectangle aux coins arrondis comportant le nom de la classe de l’instance, et la liste des attributs valu´es (voir figure 4.2). Noeud-simple Noeud-transit capacite : integer {}Noeud numero : integer image : string nom : string Flux trafic : real decider-faisceau() Faisceau capacite : integer blocage : real trafic-offert : real

calculer-blocage(traf : real,capa : integer) : real calculer-capacite() : integer

{blocage = erlang(capacite, trafic-offert)}

Reseau capacite-totale : integer nom : string mailler() dimensionner() editer() afficher()

{capacite-totale = somme des "capacite" de ses faisceaux}

destination origine mes-noeuds mes-flux mes-faisceaux mon-reseau

FIG. 4.1: Un exemple de diagramme de classes OMT

Une classe porte un nom et poss`ede ´eventuellement des attributs et op´erations :

• les attributs de classe ont un nom et un type, voir par exemple l’attribut capa-citede la classeFaisceau) ;

• les op´erations de classe ont un nom et une signature (des param`etres typ´es en entr´ee, et un type de r´esultat en sortie), voir par exemple la m´ethode calcu-ler-blocagede la classeFaisceau).

On voit donc que les op´erations et les attributs sont trait´es pratiquement uni-form´ement comme des propri´et´es dans le mod`ele `a objets.

La figure 4.2 est un exemple de diagramme d’instances. Il montre comment sont li´ees les instances constituant un r´eseau. L’instance de la classeFluxest li´ee `a deux instances de la classeNoeud-simplequi ont les rˆolesorigineetdestination. L’instance de la classeReseauest li´ee aux deux instances pr´ec´edentes de la classe

Noeud-simple, et `a une instance de la classeNoeud-transit; ces trois instances ont le rˆolemes-noeudset dans chacune de ces instances, l’instance de la classe

Reseau a pour rˆolemon-reseau. Ainsi, les diagrammes d’instances ne peuvent gu`ere servir qu’`a repr´esenter de petits exemples d’utilisation du mod`ele `a objets.

Les relations

Les relations entre les classes peuvent ˆetre de type association, agr´egation (ou composition) ou sp´ecialisation. L’association traduit un lien s´emantique entre deux

(Flux) trafic = 10. (Noeud-simple) numero = 3 nom = Nancy (Noeud-transit) numero = 1 nom = Paris (Noeud-simple) numero = 2 nom = Montpellier (Reseau)

nom = Petit reseau _mon-reseau

mes-noeuds mon-reseau mes-noeuds mon-reseau mes-noeuds mes-flux destination origine

FIG. 4.2: Un exemple de diagramme d’instances OMT

classes, alors que l’agr´egation traduit en plus une relation partie/tout ou de compo-sition [Magnan, 1994]. Ce type de relation peut comporter des rˆoles jou´es par les classes dans la relation. La cardinalit´e des rˆoles peut ˆetre exactement un (1), illi-mit´ee (n), z´ero ou un (0,1), z´ero ou plus [0..n], un au moins [1..n], rang sp´ecifique [3..7] et rang sp´ecifique et nombres exacts ([1..3], 7). Les relations sont repr´esent´ees par des traits entre les classes et portent optionnellement un nom ; une notation gra-phique permet, dans certains cas, de sp´ecifier la cardinalit´e pour chaque rˆole de la relation (voir ci-dessous). La relation d’agr´egation est not´ee par un losange du cˆot´e de la classe composite et la relation de sp´ecialisation par un triangle dont la base est orient´ee vers les sous-classes.

En plus de la cardinalit´e, une relation de type association ou agr´egation peut ˆetre enrichie des notions de qualificatif ou cl´e prise par un attribut dans la relation et de

contrainte conditionnant la relation (ou la classe). Une association peut ´egalement

avoir des propri´et´es et peut ˆetre mod´elis´ee comme une classe, c’est-`a-dire poss´eder des attributs, des op´erations ainsi que des relations avec d’autres classes. OMT per-met de d´eclarer une classe abstraite, c’est-`a-dire une classe qui ne pourra pas ˆetre instanci´ee, et dont l’utilit´e est de d´eclarer des attributs ou op´erations communes `a ses sous-classes (voirchapitre 3, section 5,chapitre 2,chapitre 1) ; dans notre exemple la classeNoeudest abstraite (pr´efix´ee par{}dans l’outil utilis´e ici). De plus, OMT

permet de d´eclarer d´eriv´ee une classe, une relation, ou un attribut d’une classe. Cette notion de d´erivation exprime une id´ee de((calcul))ou de((contrainte))sur l’exis-tence des objets, liens ou valeur d’attribut. Cette notion est diff´erente de la notion de d´erivation en C++ o `u elle correspond au concept de sp´ecialisation (voirchapitre 3, section 5).

Dans notre exemple de la figure 4.1, on indique qu’une instance de la classe

Fluxest reli´ee `a deux instances de la classeNoeudpar l’interm´ediaire de deux asso-ciations, et qu’une instance joue le rˆole d’origineet l’autre le rˆole dedestination. Le rond noir `a l’extr´emit´e droite de ces associations indique qu’une instance de la classeNoeudpeut ˆetre l’origine ou la destination de 0 ou plus instances de la classe

Flux. Les relations entre la classe Reseauet les classesFaisceauetNoeudsont des relations d’agr´egation (ou de composition). Comme pour les asociations, une cardinalit´e et un rˆole peuvent ˆetre indiqu´es au moyen des mˆemes notations. Enfin, les derni`eres relations du diagramme montrent que les classesNoeud-transitet

Noeud-simplesp´ecialisent la classeNoeud.

Il faut noter que si les cardinalit´es des associations peuvent ˆetre pertinentes en phase d’analyse, il n’est pas toujours facile d’utiliser ces d´efinitions durant les phases de conception et de codage pour effectuer des contrˆoles de cardinalit´es. Par exemple, pour une association dont la cardinalit´e est 1 (voir les associations de rˆolesorigineetdestinationentre les classesFluxetNoeud), il est clair que imm´ediatement apr`es la cr´eation d’un instance de la classeFluxles cardinalit´es des deux associations avec la classeNoeudseront nulles. Dans ce cas, il serait unique-ment possible de contraindre l’association `a ne pas d´epasser une cardinalit´e maxi-male ´egale `a 1.

Une solution possible dans les langages poss´edant des constructeurs5serait de forcer la cr´eation des instances par un constructeur ayant au moins comme pa-ram`etres les instances `a associer `a l’instance `a cr´eer, le constructeur assurant la mise en relation. Par exemple, la classeFluxdevrait avoir un constructeur ayant au moins comme param`etres les deux instances de la classeNoeudorigine et destination de l’instance de la classeFlux`a cr´eer. Pour forcer l’utilisation du bon constructeur, on peut, au niveau de la programmation, interdire l’utilisation d’autres constructeurs (en levant une exception, par exemple – voirchapitre 3, section 7), ou, dans un outil de g´en´eration de code, g´en´erer toujours l’appel au bon constructeur.

Les modules

`

A un niveau d’abstraction plus ´elev´e, OMTpropose le concept de module, afin de regrouper les classes. Un module mat´erialise une perspective ou un point de vue sur une situation. Un mod`ele `a objets peut ˆetre d´ecoup´e en plusieurs modules. `A l’int´erieur d’un module, les noms de classes et d’associations doivent ˆetre uniques, mais une classe peut ˆetre r´ef´erenc´ee dans plusieurs modules (ce qui permet de lier les modules entre eux). Cette notion de module est ´equivalente `a la notion de cat´egorie dans OOD de Booch [Booch, 1994a], mais en OMT il n’y a pas de d´eclaration sp´ecifique des relations entre modules, bien qu’il soit pr´ecis´e dans [Rumbaugh et

al., 1991] qu’il doit y avoir moins de liens entre des modules qu’`a l’int´erieur des

modules. La notion de module n’a pas de repr´esentation graphique officielle. La m´ethode BONpropose un concept ´equivalent aux modules OMT: les clusters. Ces entit´es, comme les classes, peuvent ˆetre d´ecrites par des formulaires textuels et par une notation graphique sp´ecifique. La notation textuelle permet de d´ecrire

5. Il s’agit de fonctions de cr´eation d’instances associ´ees aux classes et ayant des param`etres permet-tant d’initialiser les attributs, comme en JAVAou C++ (voirchapitre 3).

ces entit´es en termes de d´efinition des besoins ou d’analyse, alors que la notation graphique, plus pr´ecise, est plus adapt´ee `a la conception.

Le concept de module est similaire, du point de vue structurel, aux perspectives des syst`emes de repr´esentations de connaissance par objets comme TROEPS; mais il n’offre pas de s´emantique ni de m´ecanisme d’utilisation de ces perpectives, comme les passerelles ou la multi-instanciation de TROEPS(voirchapitre 10, section 4).

Les contraintes

La m´ethode OMTpermet de d´eclarer des contraintes (relations fonctionnelles) entre des entit´es du mod`ele `a objets : les objets, les classes, les attributs et les rela-tions. Une contrainte sert `a restreindre les valeurs qu’une entit´e peut prendre. La syntaxe de ces contraintes n’est pas d´efinie par la m´ethode qui sp´ecifie unique-ment que celles-ci doivent apparaˆıtre entre accolades((pr`es))de l’entit´e contrainte. Nous donnons dans la figure 4.1 deux exemples de contraintes : le premier, sur la classeReseau, indique que la capacit´e totale d’un r´eseau doit ˆetre ´egale `a la somme des capacit´es de ses faisceaux ; le second, sur la classeFaisceau, lie les attributs

blocage,capaciteettrafic-offertde cette classe (la fonction d’Erlang per-met de calculer la probabilit´e de perte sur un faisceau en fonction de sa capacit´e et du trafic qu’il doit ´ecouler).

Si l’int´erˆet de ces contraintes est ´evident pour la documentation d’une appli-cation, il l’est moins pour la production de code. En effet, dans la m´ethode OMT, il n’existe pas de syntaxe pour ces contraintes, et il n’est donc pas envisageable de g´en´erer automatiquement le code permettant de les d´efinir et maintenir. La no-tion d’asserno-tion6de la m´ethode BONpermet de d´eclarer des propri´et´es que doivent v´erifier les objets d’une classe `a certains moments : par exemple des pr´econditions et des postconditions de routines, ou des invariants de classes. Les assertions sont d´efinies avec un langage `a la fois textuel et graphique comprenant des op´erateurs arithm´etiques et logiques. Une extension d’OMT, la m´ethode SYNTROPY[Cook et Daniels, 1994], offre des fonctionnalit´es ´equivalentes. Le probl`eme de ces exten-sions est l’impossibilit´e de produire automatiquement le code correspondant sauf dans des cas relativement limit´es ; une possibilit´e est l’utilisation de syst`emes de propagation de contraintes fonctionnelles sur des attributs d’objets pour impl´ementer certains types de contraintes. Nous utilisons un tel syst`eme pour maintenir les deux contraintes (et d’autres) de la figure 4.1 [Myers et al., 1990 ; Myers et al., 1992 ; Pelenc, 1994]. Malheureusement, il n’y a pas de traduction automatique entre les contraintes d´ecrites dans le mod`ele `a objets OMTet l’application.

Ces possibilit´es sont `a rapprocher du domaine des techniques ou m´ethodes

for-melles [Monin, 1996]. Celles-ci cherchent `a offrir un cadre formel rigoureux pour la

sp´ecification de syst`emes informatiques pour pouvoir produire automatiquement le code correspondant ainsi que les programmes de tests. Ces techniques restent assez difficiles `a utiliser car elles demandent de maˆıtriser des formalismes tr`es complexes. Il existe des tentatives pour int´egrer les formalismes de ces m´ethodes et les objets

6. Les assertions proviennent du langage EIFFEL(voirchapitre 2), qui est le langage cible privil´egi´e de la m´ethode BON.

[Ruiz-Delgado et al., 1995 ; Moreira et Clark, 1994], mais elles sont plutˆot des ap-ports pour la structuration des informations dans les m´ethodes formelles que des enrichissements de m´ethodes d’analyse et de conception par objets.

4.2.2 Le mod`ele dynamique en OMT

Un mod`ele dynamique est constitu´e de diagrammes d’´etats et de diagrammes de

trace d’´ev´enements. Il exprime tous les aspects de contrˆole d´ecrits par des s´equences

d’op´erations qui se r´ealisent sur les objets du syst`eme en r´eaction `a des ´ev´enements internes ou externes.

Les diagrammes d’´etats

Les diagrammes d’´etats sont utilis´es pour montrer les changements d’´etats oc-casionn´es par des ´ev´enements pour les objets d’une certaine classe. La r´eunion des diagrammes d’´etats des classes traduit l’activit´e du syst`eme vu dans son ensemble. Le diagramme d’´etats d´ecrit le cycle de vie des instances d’une classe (dynamique interne), c’est-`a-dire comment les instances d’une classe sont cr´e´ees, d´etruites et modifi´ees au cours de l’activit´e du syst`eme. Il montre comment des ´ev´enements d´eclenchent des transitions d’un ´etat vers un autre. Chaque ´etat peut se d´ecomposer en sous-´etats ; les transitions sont d´eclench´ees par des ´ev´enements sous certaines conditions ; des actions peuvent ˆetre attach´ees aux transitions comme aux ´etats, et des messages peuvent ˆetre envoy´es `a des objets.

Un ´etat correspond aux valeurs d’attributs et de relations d’un objet `a un instant donn´e. Une transition est un changement d’´etat occasionn´e par un ´ev´enement. Un ´ev´enement se passe `a un instant donn´e et n’a pas de dur´ee ; il peut ˆetre interne au syst`eme (le d´ebut ou la fin d’une m´ethode, par exemple), ou externe (une action `a la souris, ou un choix d’item de menu). Un message est l’invocation d’une op´eration d’un objet.

Nous reprenons notre exemple de r´eseau pour illustrer ce type de diagramme dans la figure 4.3. Ce diagramme d´ecrit les diff´erents ´etats dans lesquels peut ˆetre une instance de la classeReseau, et les ´ev´enements qui d´eclenchent les change-ments d’´etats, durant les op´erations de maillage (d´etermination des faisceaux tants du r´eseau), et de dimensionnement (calcul de la capacit´e des faisceaux exis-tants).

Certains ´etats (initial,maill´e,dimensionn´e) du diagramme correspondent effectivement `a des ´etats des instances au sens o `u, par exemple, on peut sauvegarder l’ensemble des instances constituant le r´eseau (instances des classesReseau,Flux,

NoeudetFaisceau), avec toutes les valeurs d’attributs et de relations coh´erentes. Cela ´etant, il est difficile de caract´eriser un tel ´etat : par exemple pour l’´etatmaill´e, on peut d´efinir cet ´etat par le fait que le r´eseau poss`ede au moins un faisceau, mais en cours de maillage le r´eseau sera ´egalement dans cet ´etat. Un artifice consiste `a d´eclarer un attribut bool´een dans la classeReseau(maill´e?, par exemple), qui prendra la valeurvrai`a la fin de la m´ethodemailler.

Les transitions d’´etats peuvent ´egalement d´eclencher des actions (voirafficher

dimensionné do: editer dimensionnement exit/afficher maillé do: editer maillage do: mailler exit/afficher initial do: editer Reseau /afficher creer(nom ) Menu creation: fin_dimensionner fin_maillage dimensionner(capacite-totale) Menu dimensionner: [Reseau non vide]

mailler(mes-faisceaux) ^{Menu maillage:}

FIG. 4.3: Un exemple de diagramme d’´etats OMT

condition est satisfaite ; par exemple, le passage de l’´etatinitial`a l’´etatmaillage

ne peut ˆetre r´ealis´e que si le r´eseau est non vide. Il est ´egalement possible d’indi-quer des cr´eations d’instances de classe (voir la classeReseauli´ee `a l’´ev´enement

creer). La notation compl`ete peut ˆetre consult´ee dans [Rumbaugh et al., 1991]. D’autres ´etats du diagramme correspondent au fait qu’une op´eration est en cours d’ex´ecution (maillage,dimensionnement) ou au fait qu’il n’est ni maill´e, ni di-mensionn´e (initial). Les ´ev´enements du diagramme correspondent soit `a des ac-tivations, soit `a des fins d’op´erations. Si les activations d’op´erations peuvent ef-fectivement ˆetre des ´ev´enements ext´erieurs (choix dans un menu, par exemple), en revanche, les fins d’op´erations n’en sont jamais. Il n’est pas toujours imm´ediat de repr´esenter par ce type de diagramme les changements d’´etats des instances du-rant le d´eroulement d’algorithmes. En effet, il n’est par exemple pas envisageable d’avoir autant d’´etats que de valeurs possibles pour un attribut d’objet durant le d´eroulement d’un algorithme. Ces diagrammes permettent donc de repr´esenter un mod`ele global du comportement des classes du syst`eme `a r´ealiser ; ils sont mieux adapt´es `a la description du fonctionnement de syst`emes `a base d’automates.