Par essence, un systeme a objets a un contr^ole decentralise, sans ma^trise de l'ensemble des communications. Il faut donc de la rigueur dans le protocole d'interaction entre les objets. Une fois donnee la description des composants, il faut exprimer \la colle" entre les composants. Cette colle exprime les relations entre des objets de niveau d'abstraction di erents. Au niveau atomique, la communication se fait par envoi de message. A des niveaux plus abstraits, des ensembles de communications et des collaborations d'objets synthetisent les communications. Nous examinons quatre voies, non exclusives, pour contr^oler l'evolution du systeme.
Formaliser les interactions
Un e ort est fait pour preciser les interfaces entre les objets et la speci cation des liens. Des contrats etablissent clairement les services o erts [Mey92] et les obligations de chacune des parties (le client et le serveur). Ces contrats peuvent se traduire axiomatiquement par des pre-conditions, des post-conditions et des invariants. Dans la methode OORASS [AR92a], les communications sont modelisees par des r^oles. Un modele de r^ole est une unite de conception. Il comprend plusieurs entites, appelees r^oles, participant a l'execution d'un comportement exprime dans le modele. Par exemple, l'adherent A rend une cassette video CV a l'employe du magasin M. Comme pour les vues multiples, les r^oles sont ensuite composes jusqu'a obtenir les objets \complets". Les collaborateurs habituels sont ainsi regroupes. Les collaborations de la methode CRC [WBWW90] representent des requ^etes d'un client vers un serveur. Une collaboration supporte un ot de contr^ole et d'information entre deux objets. Un objet collabore avec d'autres objets pour assumer une responsabilite (i.e. connaissance et actions d'un objet) [Gir91].Etablir des liaisons abstraites
Une liaison abstraite est une abstraction des communica- tions entre deux objets. Elle peut ^etre symbolisee soit par des canaux de communication comme en CSP [Hoa85], soit par des methodes abstraites regroupant un ensemble de communications avec un protocole particulier pour exprimer la semantique abstraite comme dans les couches ISO des reseaux de donnees. Les deux types pouvant aussi ^etre ranges dans des classes abs- traites. Si la methode contient une modelisation des donnees, les associations peuvent parfois ^etre interpretees comme des canaux statiques de communication.Les liaisons abstraites peuvent parfois ^etre decrites via des objets interface, comme dans le paragraphe ci-dessous. Ainsi, le retour de la cassette se fait par une personne representant le client (souvent le client lui-m^eme) et un employe representant le magasin.De nir des objets de contr^ole
Des grandes fonctions peuvent ^etre a ectees a des objets dits d'application dans [MP92] qui prennent en charge le contr^ole d'une t^ache complexe de nie pour un ensemble d'objets et pour laquelle aucun objet n'est \logiquement" responsable. Ainsi de nir et imprimer les statistiques d'emprunts du magasin video est une t^ache globale, prise en charge par un objet de classeStatistiqueappele periodiquement. Cette idee se retrouve dansla methode Objectory [JCJO91]. Dans la methode MCO [Cas91], des administrateurs d'objets et des serveurs d'objets centralisent le service et les communications des objets. Les notions de classe et d'administrateur sont assez proches.
Regrouper les objets en sous-systemes
Un graphe de collaboration de la methode CRC [WBJ90, WBWW90] analyse les chemins de communication et identi e les sous-systemes po- tentiels. Une notation graphique exprime ces collaborations entre classes et sous-systemes. De Champeaux de nit des ensemblescomme une sorte d'objet haut niveau avec parallelisme in-terne [WBJ90]. Un ensemble est un module avec une interface abstraite, eventuellement des attributs et un diagramme de transition d'etats. Une di erence importante entre objets et en- sembles est que les ensembles ont un mecanisme de retardement pour les declencheurs et les messages entre des entites externes (objet ou ensemble) et des constituants de l'ensemble. Ralph Johnson propose une structuration similaire avec lesframework[WBJ90]. Unframeworkest est
une collection de classes et les interfaces entre elles. La triade MVCmodele/vue/contr^oleur
de Smalltalk en est un exemple [LP90]. Un framework est di erent d'un sous-systeme dans la mesure ou il peut ^etre rane, comme une classe abstraite. Un dernier terme devient a la mode, ce sont les motifs ou pattern. Un motif est une abstraction d'un ensemble de classes,
souvent reutilisables dans un developpement a objets [Coa92]. Les motifs sont decouverts par \essais successifs" et par observation de correlations entre classes dans divers systemes existants. L'auteur distingue et motive sept motifs: descriptif, temporel, evenementiel, r^ole, participation a l'etat, participation au comportement, di usion. La conception par identi ca- tion/placement/generalisation de motifs devient une demarche de conception et de gestion de classes. Reenskaug de nit les objets par un ensemble de r^oles, c'est-a-dire d'interactions avec
des objets di erents [AR92a]. Ces r^oles peuvent ^etre abstraits dans des hierarchies. Dans la methode HOOD/PNO[Pal91], les objets decrits par des reseaux de Petri sont composes (et donc synchronise) pour faire des objets de plus haut niveau.