Prototypage et mise en uvre dans les classes concretes

Les phases precedentes nous fournissent une hierarchie des classes et des operations, ainsi qu'une description des classes formelles. Le codage dans les langage a classes est decrit dans la section 7.8. Les langages de programmationont des caracteristiques propres qui posent quelques problemes speciques mais en general assez simple a resoudre. Pour une traduction automatisee, on distingue deux etapes : la traduction directe et l'optimisation.

Traduction directe

La traduction n'est en general pas completement automatisable. Il est facile de produire la declaration de la structure de la classe et de l'interface des methodes. La production automatique du code des methodes est possible si les axiomes sont orientables en regles de reecriture. Ceci est un schema simple et evidemment incomplet que l'on doit adapter suivant le langage cible choisi. Le prototype obtenu est fonctionnel et en general assez inecace.

Optimisations

Deux types d'optimisations sont pratiques jusqu'a obtenir un produit plus utilisable: ceux qui visent a changer la structure des classes ou les liens entre classes et ceux qui dependent du langage cible. Les premieres (introduction d'eets de bord, derecursivation, eco- nomie de structure) seront eectuees avec prot sur la conception abstraite en classes formelles. Les secondes seront realisees directement sur le prototype.

4.8 Conclusion

Dans ce chapitre, nous avons explore quelques concepts utiles a une conception rigoureuse en programmation a objets. Une idee majeure est d'utiliser des concepts avec une double inter- pretation (TAG = automate/TAA et CF = TAA/classe) ce qui permet de faciliter les liens entre

les niveaux de description (dynamique/fonctionnel et specication/conception). Resumons les particularites de notre approche :

{ Les composants logiciels sont des objets decrits selon trois niveaux (type abstrait, classe formelle,classe concrete) pour construire progressivement et naturellement les composants logiciels.

{ Le modele TAG associe une approche description dynamique des objets a une approche description fonctionnelle d'un type de donnee.

{ Le modele CF propose une approche algebrique de la programmation a objets pour une specication et une conception de hauts niveaux.

{ Chaque langage est formel et met en uvre des mecanismes de contr^ole et de preuve, indispensable a la qualite des specications.

{ Il y independance complete entre les langages, ce qui permet de les utiliser dans des cadres dierents et assouplit l'usage de la methode. Toutefois, nombre d'outils communs sont developpes.

{ Le passage d'un niveau d'abstraction a l'autre est guide par une demarche, partiellement automatisee, qui apporte de la rigueur dans le processus de developpement.

{ Nous utilisons d'autres environnements de specication pour supporter les preuves de theoremes et la validation.

Dans les chapitres suivants, nous detaillons les deux modeles introduits et le processus de conception des types abstraits graphiques en classes formelles. Notre but n'est pas de denir une nouvelle methode d'analyse et de conception mais des concepts et des techniques qui peuvent s'integrer dans une methode de developpement a objets.

Types abstraits graphiques

"Aimezles chosesa doublesens, mais assurez- vous qu'elles aient un sens."

SachaGuitry.

5.1 Introduction

Le modeleTAG

1est un formalisme abstrait de description a objets base sur les automates

et les specications algebriques. Le comportement dynamique est la vision la plus abstraite des objets. Cette vision est ensuite anee par une specication algebrique. La liaison entre modele fonctionnel et modele dynamique est realisee par une double interpretation du modele TAG: un TAG decrit le cycle de vie d'un objet et un TAG est un type abstrait de donnee.

Le present chapitre est organise comme suit. Dans la section 5.2, nous verrons les carac- teristiques principales d'une specication graphique de TAG. Cette specication depend d'un certain nombre d'hypotheses enoncees dans la section 5.3. Ensuite nous verrons comment ex- traire dierents elements d'une specication algebrique a partir de cette specication graphique du TAG dans la section 5.4. Ces deux descriptions forment le noyau du modele. Dans la sec- tion 5.5, nous examinons quelques points sur le contr^ole et la validation des specications. Un exemple complet est donne en annexe C. Enn, des extensions du noyau sont proposees en section 5.6, notamment l'heritage.

5.2 Specication graphique de TAG

Cette section donne la syntaxe de description des types abstraits graphiques. La notation est synthetisee dans la gure 80 de l'annexe E.

5.2.1 Representation graphique

La representation graphique est composee de quatre encarts : une ent^ete comprenant no- tamment le nom du type en cours de denition, appeletyp ed'inter^et, un ensemble de prols

d'operations, des declarations de parametrage, un automate du comportement dynamique. Un certain nombre d'informations sont ajoutees a la description (dates, notes) elles servent a com- menter la description graphique pour un archivage de la documentation. Chaque propriete est

1

Typ eAbstraitdeDonneesGraphique

nommee, et donnera lieu a la generation d'un ou plusieurs axiomes. Par exemple, modelisons un compte bancaire simple par le TAG suivant:

Zone de description

des paramètres de la spécification [p1] retirer [not p2] déposer [p2] déposer [not p1] retirer ouvrir déposer

ouvrir ( num : Entier[23], int : Intitule, v: RéelP) : Cpt déposer ( Self : Cpt, m: Réel+) : Cpt

retirer ( Self : Cpt, m: RéelP) : Cpt solde ( Self : Cpt) : Réel

numéro ( Self : Cpt) : Entier[23] intitulé ( Self : Cpt) : Intitulé

crédi-

teur débi-

teur

Descriptif : Compte bancaire Type Cpt

Auteur : Pascal Andre

Version : 4 Juin 1993 Propriétés : constantes paramètres formels contraintes p1: solde(Self) - m < 0 p2: solde(Self) + m < 0 gardes : zone de description de l’auto- mate de tement compor- dont des gardes zone

Zone d’information du TAG Zone de description

des profils des opérations

Figure 32 : TAG Compte bancaire.

5.2.2 Operations

Une

operation

est une abstraction procedurale. Elle est denie d'un point de vue syntaxique par un prol.

Denition 5.2.1 (prol d'operation)

Un prol d'operation est un triplet <nom, parametre, resultat>, ou parametre est une se-

quence de couples <variable, type>. et resultat est un type. Un prol d'operation est note:

oper (p 1 : Type 1 , ... p n : Type n ): Type r es .

Le

domaine

(resp.

codomaine

) d'un prol d'operation est le produit cartesien des types du parametre (resp. le type resultat) de ce prol d'operation. Tout prol d'operation contient au moins une fois le type d'inter^et sinon l'operation associee releverait d'une autre abstraction de donnee. Nous utilisons la convention syntaxique suivante: si le type d'inter^et appartient au domaine alors il se trouve en premiere position et le nom de la variable associee est

Self

(connotation d'objet receveur). Comme d'usage, les operations sont classees en constructeurs et observateurs. Par extension et abus de langage, operation et prol d'operation seront confondus.

Denition 5.2.2 (constructeurs, observateurs)

SoitF un ensemble de prols d'operations et un nom de typeTI. Soient ?,?

b et'trois sous-

ensembles deF denis par:

? =fpo2F jTI = codom(po)g? b=

fpo2?jTI =2dom(po)g' =fpo2F jTI6= codom(po)g.

Les operations respectives de?,?bet'sont appelees respectivement

constructeur,construc- teur de baseetobservateur de F pour le typeTI.

Il est evident que F = ?[' i.e. ? et ' forment une partition. Dans l'exemple de la gure

32, les constructeurs sont les operations nommeesouvrir, retirer et deposer. L'operation

de nomouvrirest le seul constructeur de base. Les observateurs sont les operations de nom solde, numero et intitule. Les transitions associees aux operations denies sur tous les

5.2.3 Parametres et invariant d'une specication

Un parametre d'une specication graphique et

generique

de TAG est : soit un

parametre

formel de type

(PFT), qui est en fait un nom de type

2, soit une constante , appelee

para-

Dans le document Méthodes formelles et à objets pour le développement du logiciel : (Page 111-115)