Composants, Architectures des Logiciels

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

3. 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 - 2000. ISBN : 0.201.80938.9 • 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. Composants Architectures des Logiciels Master IMA Master IMA 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 20.000 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 7.000 entreprises et 1.000.000 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 à 500.000 km au lieu de 5.000 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 - 280 morts • mauvais Pilote Automatique de la commande d’une bombe au cobalt en milieu hospitalier : 6 morts • échec d’Ariane 501 …

8. Ariane 501 : un cas d’école ... • Il existe des “erreurs grossières”... • Bug FORTRAN (programme MARINER) • Rendues rares parl’é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'à H0 + 36 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. SRI (Système de Référence Inertiel) SRI (Système de Référence Inertiel) OBC (Calculateur embarqué) OBC (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) Bus 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 H0 + 39 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 5et 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. 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. Composants, Architectures des Logiciels Master IMA Master IMA 2- 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. On observe une absence de standard des problèmes de maintenance et d’évolution une absence totale de réutilisabilité Pas de méthodeles chiffres s’expliquentla 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 Pourquoi le matériel semble-t-il plus sûr? 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. L i v r é m a i s j a m a i s u t i l i s é P a y é m a i s n o n l i v r é U t i l i s é a p r è s r e m a n i e m e n t s p u i s a b a n d o n n é U t i l i s é a p r è s r e m a n i e m e n t s U t i l i s é t e l q u e l Une observation surla production de logiciels • Etude du Government Accounting Office en 1979 sur neuf projets de taille moyenne ($7 000 000) 3% 19% 2% 29% 47%

27. Un drôle de marché

28. 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 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   Taille des logiciels développés

29. 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 Que faire ?

30. 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 Alors, le développement de logiciel c’est ...

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

32. 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é Autodocumentation. Structuration. Concision. Lisibilité. Facilité d'adaptation Structuration. Facilité d'extension. Documentation technique Logiciels : Point de Vue des Développeurs

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 • 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. Conteneur Conteneur Conteneur Structure d’accueil Structure d’accueil Exemple d’interaction Composant Composant Client 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. Interactions Current Component Component Environment Resources Exported Usage Constraints Operation (User -Manual) Operations T rigger Imported Usage Constraints (User -Manual) Expectations on Interactions (Extension of User -Manual) Exception LoEnvironment hypothess Local properties + Environment hypotheses

43. Composants, Architectures des Logiciels Master IMA Master IMA 4- Architecture Un assemblage de composants ?

44. Architecture Description de l'ensemble des composants logiciels qui constituent une ou plusieurs applications. • Séparation et fusionSûreté : • Des assemblages • De l’adaptation • De la coordination • De l’intégration • De composants logiciels • Contraintes • Séparation des préoccupationsmais cohérence locale, cohérence globale • Indépendance vis-à-vis des technologiesmais 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. 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 … Les composants d'une architecture

48. collaboration notification security storage notification storage Besoins 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

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