La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

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

Présentations similaires


Présentation au sujet: "1. 2 Composants, Architectures des Logiciels univ-lr.fr Département Informatique - Laboratoire L3i Université de La Rochelle Master."— Transcription de la présentation:

1 1

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

3 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 4 Bibliographie - références principales 1.Design Patterns, E.Gamma,R.Helm,R.Johnson &J.Vlissides, Ed.International Thomson Publishing 2.'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. 4.J.Bosch (2000) design and Use of Software Architectures, Addison-Wesley. 5.F.Buschmann &al. (1996) Pattern-Oriented Software Architecture - A System of Patterns, Wiley. 6.M.E.Fayad, D.C.Schmidt, R.E.Johnson(1999) Building Application Frameworks, Wiley. 7.E.Gamma &al. (1995) Design Patterns - Elements of Reusable Object- Oriented Software, Addison-Wesley. 8.A.Goldberg, K.S.Rubin (1995) Succeeding with Objects - Decision Frameworks for Project Management, Addison-Wesley. 9.C.Hofmeister, R.Nord, D.Soni (2000) Applied Software Architecture, Object Technology Series, Addison-Wesley. 10.Sommerville I. “Génie Logiciel”, InterEdition, Arnold A.& all. “Programmes parallèles, modèles et validation”, Armand Colin 12.Précis de Génie Logiciel, M.-C. Gaudel et al., Masson, Génie Logiciel : principes, méthodes et techniques, A. Strohmeier et al., Presses Polytechniques et Universitaires Romandes, 1996

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

6 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é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 bissextilesCartes 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ésArrê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 pertesTAURUS, 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 ?Et le bogue de l’an 2000 ?

7 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 pointmission 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 sudavion 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 redondancefaux 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 mortsnon 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 mortsAirbus 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 mortsmauvais Pilote Automatique de la commande d’une bombe au cobalt en milieu hospitalier : 6 morts échec d’Ariane 501 …échec d’Ariane 501 …

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

9 9 Ariane 501 : l’échec du 4 juin 1996 Conditions météorologiques acceptables Conditions météorologiques acceptables  Visibilité “correcte”, pas de risque de foudre, champs électrique négligeable Chronologie de lancement correcte 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 H secondes : vers H secondes :  déviation soudaine de la trajectoire  Explosion de la fusée

10 10 Analyse préliminaire de l’accident Ce qui est observé (extraits du rapport) un comportement nominal du lanceur jusqu'à H secondes ; 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 ; 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 ; 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. 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 H ,7 s”

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

12 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 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 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 à H 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 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 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 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 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 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 20 2- Logiciels Une évolution à contrôler ? Composants, Architectures des Logiciels Master IMA

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

22 22 Pourquoi le matériel semble-t-il plus sûr? On observe une absence de standard une absence de standard des problèmes de maintenance et d’évolution des problèmes de maintenance et d’évolution une absence totale de réutilisabilité 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, Les coûts de production, Le besoin de grande séries, Le besoin de grande séries, La difficulté de correction ou d’évolution... La difficulté de correction ou d’évolution... forcent les gens à “mieux” travailler Le logiciel souffre de ses qualités

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

24 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 25 Le coût du logiciel 100% 50% Coût logiciel vs matériel 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.

26 26 Une observation sur la production de logiciels Etude du Government Accounting Office en 1979 sur neuf projets de taille moyenne ($ ) 47% 29% 19% 3% 2% Livré mais jamais utilisé Payé mais non livré Utilisé après remaniements puis abandonné Utilisé après remaniements Utilisé tel quel

27 27 Un drôle de marché

28 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 29 Que faire ? Organiser le développement : 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 : 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 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, Travail en équipe, Analyse du problème Analyse du problème Techniques de programmation Techniques de programmation Gestion de versions Gestion de versions Qu’est ce que cela apporte? Analyse des comportements dans le développement de logiciels Analyse des comportements dans le développement de logiciels Définition de normes (Langage, sécurité...) Définition de normes (Langage, sécurité...) Définition des caractéristiques d’une “bonne approche” Définition des caractéristiques d’une “bonne approche” Définition de méthodes Définition de méthodes

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

32 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é Autodocumentation. Structuration. Concision. Lisibilité. Facilité d'adaptation Structuration. Facilité d'extension. Documentation technique

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

34 34 Composants Définition module logiciel autonome 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) fournie(s) spécifie explicitement la ou les interface(s) requise(s) spécifie explicitement la ou les interface(s) requise(s) peut être configuré peut être configuré capable de s'auto­décrire capable de s'auto­décrireIntérêt permettre la construction d'applications par composition de briques de base configurables 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) séparer les fonctions des fournisseur et d'assembleur (conditions pour le développement d'une industrie des composants)

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

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

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

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

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

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

41 41 Triggers Exceptions Internal Description Resources

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

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

44 44 Architecture Séparation et fusion Sûreté : Des assemblages Des assemblages De l’adaptation De l’adaptation De la coordination De la coordination De l’intégration De l’intégration De composants logiciels 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… Description de l'ensemble des composants logiciels qui constituent une ou plusieurs applications.

45 45 Intérêt d'une description globale d'architecture Facilite la conception et la réalisation réalise la synthèse entre : 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 outil de documentation Facilite le processus d'évolution modification des composants (interface, réalisation) modification des composants (interface, réalisation) modification des relations entre composants modification des relations entre composants modification du déploiement modification du déploiement

46 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 Poste de travail: terminal ou micro-ordinateur Serveur: site central, serveur HTTP, serveur d ’applications, serveur de données, serveur d ’administration,... 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 Interface homme-machine: présentation + dialogue Traitement: fonctions applicatives Traitement: fonctions applicatives Données: gestion de données 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 47 Les composants d'une architecture La présentation : C'est l'interface avec l'utilisateur C'est l'interface avec l'utilisateur Caractéristique principale : variété Caractéristique principale : variété  Différents paradigmes Ecrans, Fenêtres, Documents …  Différents systèmes de présentation Problématique 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" Comment garantir qu'une information n'est jamais "égarée" Caractéristique principale : évolution des volumes Caractéristique principale : évolution des volumes Problématique : coût Problématique : coût La logique métier Permet de définir les fonctionnalités propre au métier Permet de définir les fonctionnalités propre au métier Caractéristique principale : Spécificité absolue Caractéristique principale : Spécificité absolue Problématique : Problématique :  Pas de standardisation  Pas de solution clé en main  Choix de la méthode d'implantation  …

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

49 49

50 50 Plates-formes composites : l'exemple de Dotnet WindowsCOM+ Services Common Language Runtime Base Class Library Data and XML ASP.NETWindows Forms Common Language Specification EiffelC++C#JScript… Class Loader IL to Native Compilers Code Manager Garbage Collector Security EngineDebug Engine Type CheckerException Manager Thread SupportCOM Marshaler Base Class Library Support

51 51 Une autre plate-forme CORBAservices CORBAfacilities Business Object Facility* Common Business Objects* CORBA Domains CORBA Domains CORBA Domains SECURITY IDL Interfaces, Mappings, & ORB Realtime*, Embedded* options Interoperability: IIOP, Asynch* Components*, Scripting*

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

53 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 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 Et plus particulièrement pour assembler dynamiquement les composants d’une application  Composants métiers  Composants techniques  Composants d’interface Homme-Machine

54 54 Construction d'applications réparties adaptables Adaptabilité Adaptation à l'évolution de l'application et/ou aux besoins des utilisateurs 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) Adaptation aux conditions de l'environnement d'exécution (hétérogénéité, QoS)  Utilisation de la mobilité (code et/ou données)  Utilisation de services techniques  Modification de l’Interface Homme-Machine

55 55 Construction d'applications réparties adaptables Principes directeurs Application = {assemblage composants} Application = {assemblage composants} Les interactions entre les composants sont explicitées Les interactions entre les composants sont explicitées Utilisation pour... Enrichir les comportements des composants 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 56 Construction d'applications réparties adaptables Domaines d'applications Intégration et extension d'applications existantes 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 Applications pour l'Internet  Utiliser l'Internet comme un environnement d'exécution pour les applications réparties

57 57 Interactions logicielles Sont décrites par des schémas Indépendamment des langages de programmation 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 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 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 Peuvent être posées ou enlevées à l’exécution

58 58

59 Stéphane Frénot

60

61 61


Télécharger ppt "1. 2 Composants, Architectures des Logiciels univ-lr.fr Département Informatique - Laboratoire L3i Université de La Rochelle Master."

Présentations similaires


Annonces Google