univ-lr.fr

Présentation au sujet: "univ-lr.fr"— Transcription de la présentation:

1

2 pascal.estraillier @ univ-lr.fr
Composants, Architectures des Logiciels Master IMA univ-lr.fr Département Informatique - Laboratoire L3i Université de La Rochelle

3 Elaboration de logiciels complexes dans un contexte distribué
Objectifs du cours Elaboration de logiciels complexes dans un contexte distribué Maîtriser la conception et le développement d’architectures logicielles Maîtriser l’intégration de composants logiciels Connaissance des problèmes Connaissance des méthodes Connaissance des techniques

4 Bibliographie - références principales
Design Patterns, E.Gamma,R.Helm,R.Johnson &J.Vlissides, Ed.International Thomson Publishing 'Testing Object-Oriented Systems, Models, Patterns and Tools' R.V. Binder; Addison-Wesley ISBN : L.Bass, P.Clement, R.Kazman (1998) Software Architecture in Practice, SEI Series in Software Engineering, Addison-Wesley. J.Bosch (2000) design and Use of Software Architectures, Addison-Wesley. F.Buschmann &al. (1996) Pattern-Oriented Software Architecture - A System of Patterns, Wiley. M.E.Fayad, D.C.Schmidt, R.E.Johnson(1999) Building Application Frameworks, Wiley. E.Gamma &al. (1995) Design Patterns - Elements of Reusable Object-Oriented Software, Addison-Wesley. A.Goldberg, K.S.Rubin (1995) Succeeding with Objects - Decision Frameworks for Project Management, Addison-Wesley. C.Hofmeister, R.Nord, D.Soni (2000) Applied Software Architecture, Object Technology Series, Addison-Wesley. Sommerville I. “Génie Logiciel”, InterEdition, 1993 Arnold A.& all. “Programmes parallèles, modèles et validation”, Armand Colin Précis de Génie Logiciel, M.-C. Gaudel et al., Masson, 96 Génie Logiciel : principes, méthodes et techniques, A. Strohmeier et al., Presses Polytechniques et Universitaires Romandes, 1996

5 Master IMA Master IMA Composants Architectures des Logiciels
1-Introduction Pourquoi doit on s’intéresser au logiciels ?

6 Risques humains/économiques dus à l’informatisation
Dans le monde de la gestion en 1993 : envoi de journaux à la même adresse : sélecteur d'adresse de l'imprimante bloqué Cartes de crédit systématiquement avalées : désaccord de 2 calculateurs sur calcul des années bissextiles Arrêt de Transpac (surcharge du système) pour entreprises et d'abonnés TAURUS, le projet d'informatisation de la bourse londonienne définitivement abandonné après 4 années de travail et 100 millions de £ de pertes Et le bogue de l’an 2000 ?

7 Risques humains/économiques dus à l’informatisation
Dans les systèmes embarqués : mission VENUS: passage à km au lieu de km : remplacement d'une virgule par un point avion F16 déclaré sur le dos au passage de l'équateur : non prise en compte du référentiel hémisphère sud faux départ de la première navette: erreur de synchronisation entre calculateurs assurant la redondance non reconnaissance de l'EXOCET dans la guerre des Malouines : Exocet non répertorié comme missile ennemi : 88 morts Airbus iranien abattu : non différenciation entre avion civil et avion militaire : guerre du Golfe morts mauvais Pilote Automatique de la commande d’une bombe au cobalt en milieu hospitalier : 6 morts échec d’Ariane 501 …

8 Rendues rares par l’évolution de la technologie...
Ariane 501 : un cas d’école ... Il existe des “erreurs grossières”... Bug FORTRAN (programme MARINER) Rendues rares par l’évolution de la technologie... Le cas étudié concerne l’aérospatiale grosses applications procédures complexes procédures rodées Ce ne peut donc être considéré comme une “erreur grossière”

9 Ariane 501 : l’échec du 4 juin 1996
Conditions météorologiques acceptables Visibilité “correcte”, pas de risque de foudre, champs électrique négligeable Chronologie de lancement correcte Arrêt du remplissage de l’étage cryotechnique de quelques minutes suite à une dégradation temporaire de la visibilité Allumage (moteur principal Vulcain et moteurs à propergol) nominal Début de vol nominal vers H0+40 secondes : déviation soudaine de la trajectoire Explosion de la fusée

10 Analyse préliminaire de l’accident
Ce qui est observé (extraits du rapport) un comportement nominal du lanceur jusqu'à H secondes ; la défaillance du système de référence inertielle de secours, suivie immédiatement par celle du système de référence inertielle actif ; le braquage en butée des tuyères des deux moteurs à propergols solides puis, quelques instants après, du moteur Vulcain, provoquant le basculement brutal du lanceur ; l'auto-destruction du lanceur déclenchée correctement par la rupture des liaisons entre les étages d'accélération à poudre et l'étage principal. A priori “On a pu remonter rapidement jusqu'à l'origine de cette défaillance dans le système de pilotage et, plus précisément, dans les systèmes de référence inertielle qui, à l'évidence, ont cessé de fonctionner presque simultanément à environ H0 + 36,7 s”

11 (Système de Référence Inertiel) (Calculateur embarqué)
Contexte technique Réplication SRI, OBC etc... doublés élément actif élément en veille Réutilisation La conception des SRI est pratiquement la même que pour Ariane 4 (notemment en ce qui concerne le logiciel) SRI (Système de Référence Inertiel) Bus OBC (Calculateur embarqué) Tuyères des étages d’ac- célération à poudre Moteur Vulcain

12 Rapport final : analyse de l’échec (1)
(1> Le lanceur a commencé à se désintégrer à environ H s sous l'effet de charges aérodynamiques élevées dues à un angle d'attaque de plus de 20°; qui a provoqué la séparation des étages d'accélération à poudre de l'étage principal, événement qui a déclenché à son tour le système d'auto-destruction du lanceur ; (2> Cet angle d'attaque avait pour origine le braquage en butée des tuyères des moteurs à propergols solides et du moteur principal Vulcain ; (3> Le braquage des tuyères a été commandé par le logiciel du calculateur de bord (OBC) agissant sur la base des données transmises par le système de référence inertielle actif (SRI2). A cet instant, une partie de ces données ne contenait pas des données de vol proprement dites mais affichait un profil de bit spécifique de la panne du calculateur du SRI 2 qui a été interprété comme étant des données de vol ; (4> La raison pour laquelle le SRI 2 actif n'a pas transmis des données d'altitude correctes tient au fait que l'unité avait déclaré une panne due à une exception logiciel ;

13 Rapport final : analyse de l’échec (2)
(5> L'OBC n'a pas pu basculer sur le SRI 1 de secours car cette unité avait déjà cessé de fonctionner durant le précédent cycle de données (période de 72 ms) pour la même raison que le SRI 2 ; (6> L'exception logiciel interne du SRI s'est produite pendant une conversion de données de représentation flottante à 64 bits en valeurs entières à 16 bits. Le nombre en représentation flottante qui a été converti avait une valeur qui était supérieure à ce que pouvait exprimer un nombre entier à 16 bits. Il en est résulté une erreur d'opérande. Les instructions de conversion de données (en code Ada) n'étaient pas protégées contre le déclenchement d'une erreur d'opérande bien que d'autres conversions de variables comparables présentes à la même place dans le code aient été protégées ; (7> L'erreur s'est produite dans une partie du logiciel qui n'assure que l'alignement de la plate-forme inertielle à composants liés. Ce module de logiciel calcule des résultats significatifs avant le décollage seulement. Dès que le lanceur décolle, cette fonction n'est plus d'aucune utilité ;

14 Rapport final : analyse de l’échec (3)
(8> La fonction d'alignement est active pendant 50 secondes après le démarrage du mode vol des SRI qui se produit à H0 - 3 secondes pour Ariane 5. En conséquence, lorsque le décollage a eu lieu, cette fonction se poursuit pendant environ 40 secondes de vol. Cette séquence est une exigence Ariane 4 mais n'est pas demandé sur Ariane 5 ; (9> L'erreur d'opérande s'est produite sous l'effet d'une valeur élevée non prévue d'un résultat de la fonction d'alignement interne appelé BH (Biais Horizontal) et lié à la vitesse horizontale détectée par la plate-forme. Le calcul de cette valeur sert d'indicateur pour la précision de l'alignement en fonction du temps ; (10> La valeur BH était nettement plus élevée que la valeur escomptée car la première partie de la trajectoire d'Ariane 5 diffère de celle d'Ariane 4, ce qui se traduit par des valeurs de vitesse horizontale considérablement supérieures. Ce scénario a été reproduit après coup avec les données du vol en séance de simulation

15 Autres remarques (1> Le système de référence inertielle d'Ariane 5 est, pour l'essentiel, identique à un système actuellement utilisé sur Ariane 4. La partie du logiciel qui a interrompu le fonctionnement des calculateurs des systèmes de référence inertielle est utilisée avant le lancement pour aligner le système de référence inertielle, mais aussi, sur Ariane 4, pour permettre un réalignement rapide du système en cas d'interruption tardive de la chronologie. Cette fonction de réalignement, qui n'a aucune utilité sur Ariane 5, a néanmoins été maintenue pour des raisons de communité et pouvait, comme sur Ariane 4, rester active pendant une quarantaine de secondes après le décollage. (2> Lors de la conception du logiciel du système de référence inertielle d'Ariane 4 et d'Ariane 5, il a été décidé qu'il n'était pas nécessaire de protéger le calculateur de la centrale inertielle contre un arrêt de fonctionnement dû à une valeur excessive de la variable liée à la vitesse horizontale, laquelle protection a été prévue pour plusieurs autres variables du logiciel d'alignement. Cette décision de conception a été prise sans que l'on analyse ou comprenne parfaitement les valeurs que cette variable particulière pourrait prendre lorsque le logiciel d'alignement est autorisé à fonctionner après le décollage.

16 Autres remarques (3> Une telle défaillance ne s'est pas produite sur les vols Ariane 4 utilisant le même système de référence inertielle, car la trajectoire pendant les 40 premières secondes du vol est telle que la variable particulière liée à la vitesse horizontale ne peut dépasser, même en tenant compte d'une marge opérationnelle adéquate, la limite inscrite dans le logiciel. (4> Ariane 5 a une accélération initiale élevée et une trajectoire telle que sa vitesse horizontale s'accroît cinq fois plus rapidement que celle d'Ariane 4. La vitesse horizontale supérieure d'Ariane 5 a généré, en l'espace de ces 40 secondes, la valeur excessive qui a entraîné l'arrêt de fonctionnement des calculateurs des systèmes de référence inertielle. (5> Le processus des revues, auquel tous les grands partenaires d'Ariane 5 participent, a pour objet de valider les décisions de conception et d'obtenir la qualification pour le vol. Au cours de ce processus, les limitations du logiciel d'alignement n'ont pas été pleinement analysées et l'on n'a pas mesuré les conséquences que pouvait avoir le maintien de cette fonction en vol.

17 Autres remarques (6> Les données de trajectoire d'Ariane 5 n'étaient pas expressément prévues dans la spécification relative au système de référence inertielle ni dans les essais au niveau équipements. En conséquence, la fonction de réalignement n'a pas été testée dans les conditions de vol simulées d'Ariane 5 et l'erreur de conception n'a pas été décelée. (7> Il aurait été techniquement possible d'inclure la quasi-totalité du système de référence inertielle dans les simulations du système complet. Pour un certain nombre de raisons, il a été décidé d'utiliser les résultats simulés du système de référence inertielle, et non le système proprement dit ou sa simulation détaillée. Si l'on avait inclus ce système, la défaillance aurait pu être décelée. (8> Des simulations après vol ont été conduites à l'aide d'un calculateur doté du logiciel du système de référence inertielle et dans un environnement simulé, en intégrant les données de trajectoire réelles du vol Ariane 501. Ces simulations ont fidèlement reproduit la séquence des événements qui ont conduit à la défaillance des systèmes de référence inertielle.

18 Attention à la réutilisation et aux conditions de réutilisation
Conclusions à tirer † Le problème a pour origine une séquence compliquée de circonstances (décisions, oublis...) Attention à la réutilisation et aux conditions de réutilisation Le logiciel embarqué d’Ariane 5 constitue plusieurs centaines de milliers de lignes de code

19 Rapport final : quelques recommandations
† inhiber la fonction incriminée Etendre l’installation d’essais (utilisations de données réalistes) Interdire aux instruments de cesser d’envoyer des données cohérentes Autant que possible, confiner les exceptions à l’intérieur des tâches et prévoir des solutions de secours † Intégrer les données de trajectoire dans les exigences d’essais Revoir la couverture des essais réalisés sur les équipements existants Traiter les documents justificatifs avec autant d’attention que le code ... Et le développement de ce type de logiciel se déroulait déjà dans des conditiosn draconiènnes!!!

20 Master IMA Master IMA Composants, Architectures des Logiciels
Une évolution à contrôler ?

21 Différences en développements logiciels et matériels
”Hardware is, Software will” Matériel Logiciel Rapidité d’expression + - Niveaux d’abstraction - + Rigidité +/- +/- Les deux peuvent ne pas être fiables En matériel, cela ne pardonne pas! En logiciel, on peut bricoler...

22 Pourquoi le matériel semble-t-il plus sûr?
On observe une absence de standard des problèmes de maintenance et d’évolution une absence totale de réutilisabilité Pas de méthode les chiffres s’expliquent la différence matériel/logiciel aussi Explication Les coûts de production, Le besoin de grande séries, La difficulté de correction ou d’évolution... forcent les gens à “mieux” travailler Le logiciel souffre de ses qualités

23 Qualité des Logiciels La validation de Windows 2000 avait fait appel à 600 000 bêta testeurs, il restait pourtant au lancement de sa commercialisation 63 000 problèmes potentiels dans le code, dont 28 000 sont réels.

24 Logiciel : un produit spécifique ?
Définition : Ensemble des programmes, procédés et règles, et éventuellement de la documentation, relatifs au fonctionnement d'un ensemble de traitement de l'information (selon le Larousse 96 et IEEE Std 729). Le logiciel est un produit (industriel ?) très différent des produits classiques : il ne vieillit pas , ne s'use pas il n'est pas détérioré par le test il est fabriqué artisanalement et souvent original mais Le processus de développement logiciel n’est pas standardisé (standardisable?) il est facilement reproductible et surtout il est trop facile à modifier il coûte très (trop ?) cher

25 Le coût du logiciel De 1965 à 1995, en 30 ans, le volume de chaque logiciel a été multiplié 100, alors que la productivité des développeurs n'augmentait que d'un facteur 3. Coût logiciel vs matériel 100% 50% 50 60 70 80 90 2000

26 Une observation sur la production de logiciels
Etude du Government Accounting Office en 1979 sur neuf projets de taille moyenne ($7 000 000) 19% 3% 2% 29% 47% L i v r é m a s j u t l P y n o U p è e b d q

27 Un drôle de marché

28 Taille des logiciels développés
Montre téléphone mobile automobile central téléphonique noyau Linux   Syst. combat du Ch. de Gaulle portail Yahoo Windows 95 Windows NT Windows 2000 Office VX pour Mac Linux D.Générale compta. publique (Bercy)  2 K instructions 150 K instructions 1 M instructions 3,7 M instructions 8 M instructions 11 M instructions 10 M instructions 16,5 M instructions 30 à 50 M instructions 25 M instructions 100 M instructions 160 M instructions Cobol  

29 Que faire ? Organiser le développement : - équipe de développement :
* définition de rôles spécifiques (spécifieur, concepteur, développeur,) * reconnaissance de qualifications * formation complémentaire - introduction d'un plan qualité : mise en place de procédures très strictes de contrôles Introduire des cycles de vie : * choix de méthodes rigoureuses * choix de notations spécialisées selon la nature des problèmes * utilisation d'environnements riches et d'outils supports

30 Alors, le développement de logiciel c’est ...
C’est le regroupement de “règles” en vue d’assurer un bon développement d’une application Travail en équipe, Analyse du problème Techniques de programmation Gestion de versions Qu’est ce que cela apporte? Analyse des comportements dans le développement de logiciels Définition de normes (Langage, sécurité...) Définition des caractéristiques d’une “bonne approche” Définition de méthodes

31 Master IMA Master IMA Composants, Architectures des Logiciels
Découper les logiciels, Pourquoi-Comment ?

32 Logiciels : Point de Vue des Développeurs
Portabilité Utilisation d'un langage standardisé. Indépendance du matériel Indépendance du système d'exploitation Utilité sous sa forme actuelle Fiabilité Précision. Intégrité. Tests réussis pour tous les cas. Uniformité de conduite. Efficacité Economie de mémoire. Rapidité d'exécution. Aspect humain Facilité d'utilisation. Accessibilité. Documentation pour l'utilisateur. Facilité de maintenance Facilité de vérification Facilité d'utilisation. Accessibilité. Autodocumentation. Vérif. formelles statiques possibles. Structuration. Clarté Concision. Lisibilité. Facilité d'adaptation Facilité d'extension. Documentation technique

33 Logiciels : Point de Vue du Système
Ouverture Interopérabilité, portabilité,fédération : réutilisation de l’existant Coopération, Coordination, Partage Vision commune cohérente d’informations partagées Interaction en temps-réel, support multimédia Transparence Accès (mobilité des usagers avec préservation de l’environnement) Localisation (de l’information, des services, …) Qualité de service Disponibilité, délais, coûts, qualité de perception … avec niveau garanti Sécurité Authentification, intégrité, confidentialité, … Evolutivité, Administration aisée Reconfiguration, gestion dynamique de services

34 Composants Définition Propriétés Intérêt module logiciel autonome
unité de déploiement (installation sur différentes plates­formes) unité de composition (combinaison avec d'autres composants) Propriétés spécifie explicitement la ou les interface(s) fournie(s) spécifie explicitement la ou les interface(s) requise(s) peut être configuré capable de s'auto­décrire Intérêt permettre la construction d'applications par composition de briques de base configurables séparer les fonctions des fournisseur et d'assembleur (conditions pour le développement d'une industrie des composants)

35 Composants : modèle générique
Propriété configurables (interfaces spéciales avec accès restreint) Composant synchrone synchrone Interfaces requises (fournies par d’autres composants) Interfaces fournies (fournies par le composant) asynchrone asynchrone Contraintes techniques placement, sécurité transactionnel, persistance interfaces fournies par le système (bibliothèques, etc.)

36 Composants : utilisation
Composition hiérarchique et encapsulation (composants construits, sous­composants) A B A2 A1 B1 B2 A3 Interconnexion de composants (connecteurs, ou objets de communication) Interfaces d’entrée (fournies) Interfaces de sortie (requises)

37 Support logiciel pour composants
Pour assurer leurs fonctions : support logiciel Conteneur encapsulation d'un composant prise en charge des services du système nommage, sécurité, transactions, persistance, etc. prise en charge partielle des relations entre composants (connecteurs) invocations, événements techniques utilisées : interposition, délégation Structure d'accueil espace d'exécution des conteneurs et composants médiateur entre conteneurs et services du système

38 Interactions entre composants
Ensemble des composants logiciels d'une application identification des composants désignation des composants Structuration des composants composition hiérarchique (sous­composants) Interconnexion des composants dépendances entre composants (fournit ­ requiert) modes de communication (synchrone, asynchrone) protocoles de communication Autres aspects contraintes globales (environnement requis) règles d'usage

39 Exemple d’interaction
Structure d’accueil Structure d’accueil Conteneur Composant Conteneur Composant Client Conteneur Composant Bus logiciel + services (désignation, persistance, transaction, sécurité,etc.)

40 The Specification Model
External description of a service Local Properties Environment hypotheses Provided service exported user manual Exported operations Imported operation Required service + imported user manual

41 Internal Description Resources Exceptions Triggers

42 Local properties + Environment hypotheses LoEnvironment hypothess
Interactions Current Component Component Environment Resources Operation Exported Usage Constraints (User -Manual) Operations T rigger Imported Usage Constraints (User -Manual) Expectations on Interactions (Extension of User -Manual) Exception Local properties + Environment hypotheses LoEnvironment hypothess

43 Master IMA Master IMA Composants, Architectures des Logiciels
Un assemblage de composants ?

44 Architecture Description de l'ensemble des composants logiciels
qui constituent une ou plusieurs applications. Séparation et fusion Sûreté : Des assemblages De l’adaptation De la coordination De l’intégration De composants logiciels Contraintes Séparation des préoccupations mais cohérence locale, cohérence globale Indépendance vis-à-vis des technologies mais adéquation des mises en oeuvre Une première réponse : les interactions logicielles Besoins, Modèle, Implémentation, Formalisation…

45 Intérêt d'une description globale d'architecture
Facilite la conception et la réalisation réalise la synthèse entre : le cahier des charges (fonctions requises) les méthodes de conception la mise en oeuvre le déploiement en environnement réparti Facilite la compréhension globale du système outil de documentation Facilite le processus d'évolution modification des composants (interface, réalisation) modification des relations entre composants modification du déploiement

46 Architectures Architecture technique: ensemble de composants techniques (machines, réseaux, logiciels de base) permettant de bâtir une solution informatique. Poste de travail: terminal ou micro-ordinateur Serveur: site central, serveur HTTP, serveur d ’applications, serveur de données, serveur d ’administration,... Architecture d ’exécution: regroupement de composants logiciels remplissant une fonction parmi: Interface homme-machine: présentation + dialogue Traitement: fonctions applicatives Données: gestion de données Architecture applicative: décomposition d ’un système d ’information ou d ’une applicative en composants. IHM T D

47 Les composants d'une architecture
La présentation : C'est l'interface avec l'utilisateur Caractéristique principale : variété Différents paradigmes Ecrans, Fenêtres, Documents … Différents systèmes de présentation Problématique Aucune solution universelle de présentation Evolution rapide des dispositifs d'interface utilisateur Intégration de nouveaux dispositifs Reconnaissance vocale, écriture ... Le stockage Comment garantir qu'une information n'est jamais "égarée" Caractéristique principale : évolution des volumes Problématique : coût La logique métier Permet de définir les fonctionnalités propre au métier Caractéristique principale : Spécificité absolue Problématique : Pas de standardisation Pas de solution clé en main Choix de la méthode d'implantation …

48 Besoins notification collaboration security storage
Enrichir les comportement des composants, assembler et coordonner des composants Sans modification des composants Réutilisation De manière dynamique Sans recompilation Sans arrêt de l’application

49

50 Plates-formes composites : l'exemple de Dotnet
Eiffel C++ C# JScript … Common Language Specification ASP.NET Windows Forms Data and XML Class Loader IL to Native Compilers Code Manager Garbage Collector Security Engine Debug Engine Type Checker Exception Manager Thread Support COM Marshaler Base Class Library Support Base Class Library Common Language Runtime Windows COM+ Services

51 Une autre plate-forme CORBA Domains Common Business Objects*
CORBAservices CORBAfacilities Business Object Facility* Common Business Objects* CORBA Domains SECURITY IDL Interfaces, Mappings, & ORB Realtime*, Embedded* options Interoperability: IIOP, Asynch* Components*, Scripting* Finally, for your enterprise, you need support extending into your application level itself. OMG’s Business Object Facility, now in final vote, provides the basis for this; specifications in various domains or vertical markets complete the picture. By th e way, domains active now include Business Objects, Finance/Insurance, Electronic Commerce, Healthcare, Manufacturing, Transportation, Healthcare, and Life Sciences Research. Getting ready are Utilitiies (primarily Electric Power) and Statistics.

52 Master IMA Master IMA Composants, Architectures des Logiciels
5- Construction d’architectures Cahier des charges ?

53 Construction d'applications réparties adaptables
Objectifs Fournir des outils et services pour la construction, le déploiement, et l'exécution d'applications réparties adaptables Et plus particulièrement pour assembler dynamiquement les composants d’une application Composants métiers Composants techniques Composants d’interface Homme-Machine

54 Construction d'applications réparties adaptables
Adaptabilité Adaptation à l'évolution de l'application et/ou aux besoins des utilisateurs Personnalisation d'une application Réutilisation et configuration Changement de la structure d'une application Reconfiguration Utilisation de services techniques Association dynamique Adaptation aux conditions de l'environnement d'exécution (hétérogénéité, QoS) Utilisation de la mobilité (code et/ou données) Modification de l’Interface Homme-Machine

55 Construction d'applications réparties adaptables
Principes directeurs Application = {assemblage composants} Les interactions entre les composants sont explicitées Utilisation pour ... Enrichir les comportements des composants De manière dynamique Sans recompilation de l’application Sans arrêt du système Sans modification des composants Afin de réutiliser les composants existants

56 Construction d'applications réparties adaptables
Domaines d'applications Intégration et extension d'applications existantes Interconnexion de logiciels existants Insertion de fonctions complémentaires Utilisation de services techniques adaptés Personnalisation pour un scénario d'utilisation donné Applications pour l'Internet Utiliser l'Internet comme un environnement d'exécution pour les applications réparties

57 Interactions logicielles
Sont décrites par des schémas Indépendamment des langages de programmation ISL (Interaction Specification Language) Programmation déclarative, règle de réécriture message notifiant  action Description incrémentale des schémas Peuvent être créés ou supprimés à l’exécution Utilisation de l’héritage Interactions = instance des schémas Contrôle uniquement les interfaces des objets Indépendant du modèle d’objet ou de composants Peuvent être posées ou enlevées à l’exécution

58

59

60

61