IMPORT X INTO CLASS
3.3.4 Support formel
Le support formel comprend la semantique du ou des langages, les outils de preuve, le ranement et le prototypage.
Langage semantique raisonnement executabilite
Object-Z basee sur Z deduction via C++
une logique temporelle logique
de nie en Z est utilisee pour les historiques
OOZE operationnelle en OBJ3 reecriture oui
la logique de de nition induction via
des methodes est restreinte theorie FOOPS
aux equations conditionnelles equationnelle et
pour les modules interpretables OBJ
les regles sont celles d'OBJ
VDM++ operationnelle en VDM deduction non
sauf pour les construction resolution
concurrentes, incompletement, de nies aide a aucune regle n'est introduite la preuve pour les objets ou la concurrence
OSDL operationnelle en termes calculs oui
de machines abstraites et de processus
de processus communicants
OS/OP algebres partiellement reecriture oui pour OP
ordonnees induction
PLUSS variantes algebres initiales, reecriture oui en
partielles, exceptions, erreurs induction partie
contrainte hierarchique equation
COLD axiomes premier ordre induction par oui
operateur de point xe point xe
algebres multi-sortes equationnel
semantique \loose"
GSBL algebres partiellement reecriture en partie
ordonnees induction
Z++ Z pour les methodes et objets W non a-priori
algebres pour les classes deduction via B
et l'heritage
MooZ semantique Z incomlete deduction non a-priori
induction via B
Fresco outils VDM avec conformance inference pre/post partie
de type pour les classes et clientele Smalltalk
Semantique: un langage bien de ni est base sur une semantique formelle. La semantique
des extensions est fonction du langage formel support. Si le langage comporte des aspects or- thogonaux une autre semantique est donnee et la coherence entre les deux n'est pas triviale. C'est le cas pour VDM de ni a partir de VDM, CSP et les machines abstraites. La semantique d'Object-Z, Z++ et MooZ comporte des lacunes [LH93]. Pour Z++, une theorie du sous-typage et du ranement a ete developpee mais n'integre pas les extensions algebriques et concurrentes. L'ajout de caracteristiques imlique l'ajout de nouvelles regles de contr^ole.
Contr^ole*: l'environnement support doit permettre des contr^oles syntaxiques mais aussi de
coherence et si possible de completude. En ce sens les speci cations algebriques ont un avantage certain sur les speci cations par modele, dont la logique est par nature incomplete.
Raisonnement: mecanismes de preuve et de validation. La logique est le principal support
du raisonnement pour les preuves equationnelles, inductives, par l'absurde, etc. Pour ^etre uti- lisable, elle doit ^etre supportee par un systeme de raisonnement. Pour les langages issus de Z, citons l'outil B [Abr84, LLS91] (preuve de theoremes, inference, machines abstraites) ou encore le systeme de raisonnement W de deduction naturelle [LH93]. Pour VDM, l'environnement
mural [JJLM91, Jon93] fournit l'assistance a la preuve de theoremes, l'aide au ranement de speci cation, etc. D'autres langages utilisent Prolog, les langages fonctionnels, ou la reecriture [JL86]. C'est notamment le cas des outils des speci cations algebriques.
Executabilite: possibilite d'executer la speci cation. Cette propriete est parfois contestee,
comme etant trop proche d'un modele operationnel. Le prototypage est la transformation plus ou moins directe en un code donne pour executer la speci cation.
Typage: plusieurs parametres distinguent les politiques de typage
{ quels types* : types de base, classes, types complexes,
{ politique de typage choisie*: statique/dynamique, fort/faible,
{ veri cations de type*: quelles veri cations possibles? interface, comportement, code. { base du contr^ole de type*: structure, comportement.
{ polymorphisme*: implicite, explicite,
{ voir aussi le tableau page 81 sur comportement/methode/polymorphisme. { regles de sous-typage* (statique)[PS92]:
Quand untyp ep ortesur: Lesous-typage devient:
classe et sous-classe simple relation d'heritage compatibilite de nom plus de methodes de nies
interface conformite des partametres des pro ls
comportement preconditions et postconditions renforcees ou a aiblies
Les deux derniers points impliquent une notion de variance. La politique adoptee est souvent contravariante: le type des arguments est generalise dans la sous-classe et la pre-condition est a aiblie; le type du resultat est specialise dans la sous classe et la post- condition est renforcee.
Abstraction : separation e ective entre les niveaux d'abstraction, plusieurs langages, separa-
Ranement: moyens o erts pour passer d'un niveau d'abstraction a un autre. Des travaux
existent tant au niveau des langages inspires de Z ou VDM que des fonctions d'abstraction pour les speci cations algebriques.
Langage typage abstraction ranement
Object-Z regles de Z non modi cation de
la structure / theorie de l'equivalence
dynamique
OOZE sous-typage des methodes non relation par predicat
pour les classes et vues
inclusion ensembliste pour les types de donnees
VDM++ sous-typage base sur non theorie de VDM
l'heritage de representation
OSDL variables, processus structurel / separation
et blocs sont types processus interface/realisation
OS/OP sous-typage : inclusion langage de base sur
d'ensembles support speci cation / l'heritage (fonctions
heritage : regles et langage de de transformation)
compatibilite de speci cation programmation
PLUSS types abstraits non par speci cation
uniquement incomplete
COLD pas de sous-typage un seul langage fonction d'abstraction
pour algebres et etats
GSBL pas de sous-typage non par speci cation
voir heritage incomplete
Z++ les classes de nissent non relation par predicat /
des types par l'ensemble passage vers Uniform
de leurs intances (sorte de Pascal), Prolog
MooZ types sont des ensembles non Z
de valeurs pas de sous-typage
de comportement
Fresco base sur les inference sur les ranement de modeles
classes pre-/post-conditions / par theoreme et decom- execution explicite position d'operations
Figure 27 : Synthese : Techniques formelles de la methode 2/2
3.3.5 Methode de developpement
{ processus : L'approche est-elle ascendante, descendante ou mixte. Une demarche precise doit guider le speci eur. Les operations sont speci ees par disjonction ou par promotion i.e. delegation a une operation d'un des composants.
{ environnement: description de l'environnement supportant le langage . { outils: outils d'ecriture, de contr^ole, de preuve, de gestion de classes. { documentation*: description.
Langage pro cessus environ. outils
Object-Z approche en cours editeurs, prouveurs
ascendante
OOZE approche systeme veri cation syntaxique et
mixte FOOPS de types
Interpreteur, Base de donnees Assistance a la preuve
VDM++ approche surcouche editeur
ascendante de Mural traducteur en VDM
OSDL emboitement SDL Tool editeur graphique
descendant ^aneur de structure
analyseur
OS/OP compatibilite en cours editeurs, preuve de conformite
des relations sous-typage/ prototypage, strategies de preuve
clientele/heritage traducteurs OP - languages objets
PLUSS mixte Asspro editeurs, aide a la preuve
prototypage, generation de code
COLD ascendante (indus- librairie de speci cations
triel) editeurs, bases de connaissance generateur de documents
contr^ole et preuve, etc.
GSBL mixte { {
Z++ approche plutot descendante outil B editeur interactif
une re exion existe pretty printer (C++, Z-style)
sur le processus raneur
MooZ approche ForMooZ langage d'interrogation de speci-
ascendante (Smalltalk) cations, ^aneur graphiques
en cours generateur de code Smalltalk generateur de documents LaTEX
aide a la preuve interactive
Fresco de nition des capsules { interpreteur Fresco/Smalltalk
ranement de l'implantation ^aneur graphique
ation proveur Mural en Smalltalk
Figure 28 : Synthese : Methodes de developpement
3.4 Bilan
Actuellement les methodes formelles a objets sont soit des langages de programmation a objets de haut niveau soit des langages de speci cation formelle traditionnels etendus aux objets. Ces derniers se classent principalement en deux p^oles, les methodes par modele abstrait et les methodes algebriques.
Les methodes par modele ont pour inconvenient une surspeci cation, m^eme si elle est abs- traite (en termes mathematiques) et la diculte d'exhiber certaines proprietes des speci cations que sont la coherence et la completude. A priori, l'inter^et de ce style reside dans la facilite a structurer les systemes a speci er et aussi dans la possibilite de traduire assez simplement les modeles statiques des methodes d'analyse et conception. Mais la tendance est de donner une version operationnelle du systeme et le ranement n'est pas trivial pour autant. Notons en- n un avantage indeniable: la plupart de ces langages ont ete concu en collaboration etroite universite/industrie dans des projets Esprit (REDO, Afrodite, Procos, etc.).
Les methodes \plut^ot" algebriques correspondent directement a une abstraction des concepts a objets, bien que pour Cook, les types abstraits de donnees sont des ensembles avec des opera- tions alors que les objets sont des ensembles d'operations [BP94]. La separation entre interface et implantation apparait plus clairement, ce qui facilite la preuve de proprietes abstraites et la validation. Un des problemes majeurs est l'expression de la communication et de la concurrence
dans des systemes a objets cooperants.
Quelque soit le style choisi, un certain nombre de dicultes persistent :
{ la persistance des objets par un identi ant unique reste un choix dicile: facilite de speci cation et diculte de preuve.
{ expression du contr^ole (de la colle) entre les objets : centralise ou non, explicite ou non. { cohesion entre les di erents modeles formels exprimant des aspects di erents du modele
a objets (structure, comportement, cycle de vie, communication).
{ manque de guide et de contr^ole dans les methodes. Le ranement reste une operation delicate, la di erence entre speci cation et implantation doit ^etre bien marquee.
{ diculte d'ecriture et de preuve. Les formalismes utilises necessitent un long temps d'ap- prentissage, les speci cations sont parfois complexes a aborder. Un formalisme simple et expressif facilite les preuves de la speci cation. L'examen ses preuves, lorsqu'elles sont donnees dans la litterature, montre le besoin d'automatisation mais aussi de documenta- tion de ces preuves. Le degre d'abstraction est aussi un critere important pour quali er les speci cations, mais il est dicile a mesurer.
{ dicultes dans la presentation de systemes complexes. Il faut des outils de structuration en modules, de gestion des classes, de methode logicielle (que reutiliser, comment le faire). { speci cation globale de systemes : l'aspect speci cation de composants est de plus en plus ma^trise, m^eme si certains points sont encore a ameliorer. Par contre, l'expression d'un en- semble d'objets communicants reste une gageure dans les modeles actuels. Si l'expression des contraintes temporelles ou de synchronisation et communication (en logique tempo- relle ou en CSP par exemple) est connue, les liens avec les objets de la speci cation ne sont pas bien ma^trises.
{ la semantique des modeles proposes n'est pas toujours facile a comprendre. Les regles a appliquer pour respecter des proprietes telles que le sous-typage ou l'heritage Le vocabu- laire varie d'un auteur a l'autre. Il y a un besoin de normalisation.
{ Un dernier besoin se fait sentir, l'interoperabilite entre les langages de speci cation. Quelque soit la methode de speci cation choisie, une methode d'analyse telle que OMT ou OOAS est necessaire a l'identi cation des objets du domaine d'inter^et. Le formalisme de speci cation doit permettre de traiter les trois plans (structure/fonction/comportement dyna- mique) des objets, mais a des niveaux d'abstraction susants (pas besoin de voir la structure d'un objet, ou a qui sont envoyes les methodes). Une approche ascendante-descendante est ne- cessaire dans l'identi cation/realisation des composants: concevoir en reutilisant et concevoir pour reutiliser.