Les couches d’une application

    Les couches d’une application

  1. Objectifs

    • Connaître les différentes catégories de services d’application
    • Connaître l’architecture logicielle en couches.
    1. Présentation

      • L’objectif premier d’un système d’information quel qu’il soit est de permettre à plusieurs utilisateurs d’accéder aux mêmes informations. Pour cela il faut donc regrouper les informations utilisées par l’entreprise. En terme technique, cela se traduit par la centralisation des données au sein d’une base de données.
      • L’évolution des systèmes d’information s’est donc basée sur une meilleure subdivision entre les tâches à réaliser pour permettre l’exploitation de ces données par les utilisateurs finaux. Ceci permet de structurer plus efficacement les informations ce qui entraîne à la fois une meilleure organisation de l’entreprise et une meilleure efficacité technique. Cette subdivision a été facilitée par l’avènement des technologies orientées objets qui s’appliquent aussi bien au modèle client-serveur qu’au modèle Internet.
      • Ces technologies permettent une séparation entre les différents composants du système. Il devient alors possible de réaliser de nouvelles architectures permettant la mise à disposition des informations sous différentes formes tout en diminuant les temps de développement. Ces technologies permettent également de faire collaborer une grande diversité de systèmes. On parle alors de la notion d’architecture distribuée.
      • L’architecture logicielle décrit d’une manière symbolique et schématique les différents éléments d’un ou de plusieurs systèmes informatiques, leurs relations et leurs interactions
      • Cette séparation par couches de responsabilités sert à découpler au maximum une couche de l’autre afin d’éviter l’impact d’évolutions futures de l’application.
    2. Exigences de qualité d’un système logiciel

      • La norme ISO 9126 ("Technologies de l’Information : Qualités des produits logiciels") définit un ensemble d’indicateurs pour la qualité logicielle, et "facilite" ainsi le processus d’évaluation logiciel et la spécification d’exigences fonctionnelles ou non-fonctionnelles. Cette norme est en application depuis 1992.
      • La qualité d’un logiciel se mesure par rapport à plusieurs critères :
      • Exigences fonctionnelles:
        • Une application est créée pour répondre , tout d’abord, aux besoins fonctionnels des entreprises.
      • Exigences Techniques :
        • Les performances:
          • La rapidité d’exécution et Le temps de réponse
          • Eviter le problème de montée en charge
        • La maintenance:
          • Une application doit évoluer dans le temps.
          • Doit être fermée à la modification et ouverte à l’extension
        • Sécurité
        • Portabilité
          • Cette caractéristique décrit la possibilité de transférer le logiciel d’une plateforme à une autre, et les efforts nécessaires pour le faire : facilité d’adaptation et d’installation, coexistence, interchangeabilité.
        • Capacité de communiquer avec d’autres applications distantes.
        • Disponibilité et tolérance aux pannes
        • Capacité de fournir le service à différents type de clients
        • Design des ses interfaces graphiques
        • Coût du logiciel
      • Au niveau technique pour répondre à ces spécificités on adopte pour une architecture de trois tiers qui a pour objectif de répondre aux préoccupations suivantes :
        • l’allègement du poste de travail client (notamment vis-à-vis des architectures classiques client-serveur de données – typiques des applications dans un contexte Oracle/Unix) ;
        • la prise en compte de l’hétérogénéité des plates-formes (serveurs, clients, langages, etc.) ;
        • l’introduction de clients dits "légers" (plus liée aux technologies Intranet/HTML qu’à l’architecture trois tiers proprement dite) ;
        • L’amélioration de la sécurité des données, en supprimant le lien entre le client et les données. Le serveur a pour tâche, en plus des traitements purement métiers, de vérifier l’intégrité et la validité des données avant de les envoyer dans la couche d’accès aux données ;
        • La rupture du lien de propriété exclusive entre application et données. Dans ce modèle, la base de données peut être plus facilement normalisée et intégrée à un entrepôt de données ;
        • Une meilleure répartition de la charge entre différents serveurs d’applications.

        Les couches d’une application

    3. Couche Présentation

      • Elle implémente la logique présentation de l’application
      • La couche présentation est liée au type de client utilisé :
        • Client Lourd java Desktop:
          • Interfaces graphiques java SWING, AWT, SWT.
          • Ce genre de client peut communiquer directement avec les composants métiers déployés dans le conteneur EJB en utilisant le middleware RMI (Remote Method Invocation)
        • Client Leger Web
          • HTML, Java Script, CSS.
          • Un client web communique avec les composants web Servlet déployés dans le conteneur web du serveur d’application en utilisant le protocole HTTP.
        • Un client .Net, PHP, C++, …
          • Ce genre de clients développés avec un autre langage de programmation autre que java,
          • communiquent généralement avec les composants Web Services déployés dans le conteneur Web du serveur d’application en utilisant le protocole SOAP (HTTP+XML)
        • Client Mobile
          • Androide, iPhone, Tablette etc..
          • Généralement ce genre de clients communique avec les composants Web Services en utilisant le protocole HTTP ou SOAP
    4. Couche Métier

      • La couche métier est la couche principale de toute application
      • Elle implémente la logique métier d’une entreprise
      • Elle se charge de récupérer, à partir des différences sources de données, les données nécessaires pour assure les traitement métiers déclenchés par la couche application.
      • Elle assure la gestion du WorkFlow (Processus de traitement métier en plusieurs étapes)
      • Il est cependant important de séparer la partie accès aux données (Couche DAO) de la partie traitement de la logique métier (Couche Métier ) pour les raisons suivantes :
      • Ne pas se perdre entre le code métier, qui est parfois complexe, et le code d’accès aux données qui est élémentaire mais conséquent.
      • Ajouter un niveau d’abstraction sur l’accès aux données pour être plus modulable et par conséquent indépendant de la nature des unités de stockage de données.
      • La couche métier est souvent stable. Il est rare qu’on change les processus métier. Alors que la couche DAO n’est pas stable. Il arrive souvent qu’on est contrait de changer de SGBD ou de répartir et distribués les bases de données.
      • Faciliter la répartition des tâches entre les équipes de développement.
      • Déléguer la couche DAO à frameworks spécialisés dans l’accès aux données (Hibernate, Toplink, etc…)



    5. Couche Présentation

      • Appelée également couche web.
      • La couche application sert de médiateur entre la couche présentation et la couche métier.
      • Elle contrôle l’enchaînement des tâches offertes par l’application
        • Elle reçoit les requêtes http clientes
        • Assure le suivie des sessions
        • Vérifier les autorisations d’accès de chaque session
        • Assure la validation des données envoyées par le client
        • Fait appel au composants métier pour assurer les traitements nécessaires
        • Génère une vue qui sera envoyée à la couche présentation.
      • Elle utilise les composants web Servlet et JSP
      • Elle respecte le modèle MVC (Modèle Vue Contrôleur)
      • Des framework comme JSF, SpringMVC ou Struts sont généralement utilisés dans cette couche.
    6. Exemple

      • Les couches d’une application



Abonnez vous à notre chaîne YouTube gratuitement