Ingénierie informatique

• est une discipline qui traite de la conception, du développement et de la fabrication de systèmes informatiques, à la fois matériels et logiciels.
• L’ingénierie des systèmes répartis consiste à rendre la tache de développement des applications réparties plus simple en facilitant la gestion de la complexité inhérente aux applications.
• Notre but dans un premier temps est de voir une approche de modélisation dite : MDA (Model Driven Architecture) pour le développement des applications réparties.

Systèmes répartis

Définitions

• Déf1 :"Un système réparti est un ensemble de machines autonomes connectées par un réseau, et équipées d’un logiciel dédié à la coordination des activités du système ainsi qu’au partage de ses ressources."
• Déf2 : "Un système réparti est un système qui s’exécute sur un ensemble de machines sans mémoire partagée, mais que pourtant l’utilisateur voit comme une seule et unique machine."
• L’image de la fourmilière permet d’illustrer les systèmes répartis :
  • chaque ordinateur est une fourmi, et l’ensemble des ordinateurs collaborant est la fourmilière.
  • Chaque fourmi, prise seule, semble avoir un comportement simple et rudimentaire. Mais d’un point de vue global, la fourmilière a un comportement cohérent et efficace.
  • Le plus impressionnant est d’observer la robustesse d’une telle structure : si l’on écrase la moitié des fourmis composant la fourmilière, elle continuera à fonctionner.

Pourquoi un système réparti ?

1. Partage des ressources (données, applications, périphériques chers).
2. Tolérance aux pannes (fiabilité, disponibilité).
3. Facilite la communication entre utilisateurs.
4. Concurrence, parallélisme.
5. Prix des processeurs de petite puissance inférieur à ceux de grande puissance =⇒raisons économiques.
6. Flexibilité, facilité d’extension du système (matériels, logiciels).

Inconvénients des systèmes répartis/distribués

1. Logiciel
   1. relativement peu d’expérience de conception, mise en œuvre et utilisation de logiciels distribués
   2. la distribution doit elle être transparente aux utilisateurs ?
   1. Réseau de communication
      1. saturation
      2. perte de messages
   2. Sécurité
      1. facilité de partage de données rend nécessaire la protection des données confidentielles
   [ Sommaire ]

   ---

   Les principaux problèmes à résoudre

   • Répartition de l’application:
     • Partitionnement de l'application en différents composants.
     • Equilibrer la charge de l’application à travers différents composants répartis (client, nœuds de la grappe), statiquement ou dynamiquement.
     • Architecture simple, propice à l'évolutivité et au maintien de la sécurité
   • Hétérogénéité des équipements et technologies, besoin d’interopérabilité:
     • Réseaux et protocoles utilisés.
     • Matériel;
     • Systèmes d’exploitation.
     • Langages de programmation.
     • Implémentations.
     • Représentations internes.
     • Solution : Protocoles et formats de stockage normalisés en plus les intergiciels d'adaptation (e.g. CORBA, Java RMI, .NET).
   • Ouverture de système:
     • Possibilité d'évoluer, de re-développer le système en tout ou en partie.
     • Interopérabilité avec des systèmes complémentaires.
     • Portabilité vers du nouveau matériel.
     • Services développés selon des règles normalisées, formalisées à l'intérieur de protocoles, formats de stockage et interfaces de programmation.
   • Sécurité:
     • Transmettre des informations sensibles sur un lien de communication non sécuritaire et non fiable de manière sécuritaire.
     • Confidentialité, intégrité, disponibilité.
   • Évolutivité:
     • Le système doit demeurer performant lorsque le nombre d’utilisateurs et/ou de ressources augmente.
     • Taille du système.
     • Etendue géographique.
     • Architecture du logiciel réparti.
   • Tolérance aux fautes et la fiabilité/ Détection et isolation des fautes/défaillances:
     • Les fautes et les défaillances sont plus courantes que dans les systèmes centralisés.
     • Les défaillances sont habituellement indépendantes.
     • Détection des fautes/défaillances.
     • Masquage ou tolérance des fautes/défaillances.
     • Redondance et réplication.
   • Concurrence, Synchronisation et Interblocage:
     • Permettre au système de traiter simultanément plusieurs requêtes à une même ressource.
     • Les opérations doivent être sérialisées ou donner un résultat cohérent équivalent.
   • Transparence:
     • Masquer à l’utilisateur tous les aspects reliés à la répartition du système.
     • Accès, localisation, concurrence, réplication, défaillance, mobilité, performance, évolutivité.
   • Validation et tests:
     • Comment tester le système complet? Chaque composante?
     • Les fautes lors des tests pourraient être masquées par la tolérance aux pannes?
     • Validation formelle de certaines portions.
       • SPIN, modelchecker développé par Bell Labs, http://spinroot.com/spin/whatispin.html.
       • UPPAAL est un modelchecker développé par l'Université Uppsala, en Suède et l'Université d'Aalborg en Danemark, http://www.uppaal.com/.
       • Standard OpenSource pour la fiabilité et interopérabilité:
   [ Sommaire ]

   ---