Environnements de Développement

Transcription

1 Institut Supérieur des Etudes Technologiques de Kébili Unité d Enseignement : Environnements de Développement BEN ABDELJELIL HASSINE Mouna m.bnaj@yahoo.fr Développement des systèmes d Information

2 Syllabus du cours 2 Objectifs Généraux Comprendre les architectures logicielles ainsi que leurs composants; Comprendre les principaux patrons de conception (Design Patterns) Etre capable de mettre en oeuvre certains patrons de conception Décrire une architecture logicielle et produire la documentation correspondante Pré-requis POO, UML, JAVA, GL1&2

3 Organisation du cours 3 I. Fondements de l architecture logicielle II. Styles Architecturaux III.Architecture J2EE IV. Les Patrons de Conception V. Conception Architecturale VI. Thèmes Connexes de GL

4 Chapitre II: 4 Les Styles Architecturaux Unité d enseignement: Environnements de Développement

5 PLAN Veuillez nous suivre 5 Définition Styles Interactifs Conclusion Références Styles Généraux Styles Distribués

6 Définition 6 Un style architectural Est un patron (modèle) décrivant une architecture logicielle permettant de résoudre un problème particulier Définit: un ensemble de composants et de connecteurs (et leur type) Les règles de configuration des composants et connecteurs (topologie) Une spécification du comportement du patron Des exemples de systèmes construits selon ce patron Constitue un modèle éprouvé et enrichi par l expérience de plusieurs développeurs Compréhensibilité, maintenance, évolution, réutilisation, performance, documentation, etc.

7 Principales Familles 7 Les styles d architectures logicielles se répartirent sur quatre familles comme suit: 1. Styles Généraux :Filtres et Canaux, Architecture avec référentiel de données (shared data), multicouches. 2. Styles Interactifs :Basé évènement, Model View Controller (MVC). 3. Styles Distribués : n-tiers, SOA. 4. Adaptatifs : micro-kernel, réflexion

8 Styles Généraux Filtres & Canaux Architecture avec référentiel Multicouches 8 Convient bien aux systèmes de traitement et de transformation de données Composants = filtre ; Connecteur = canal Filtre: Reçoit ses données d un ou plusieurs canaux d entrée, effectue la transformation/traitement des données et envoie les données de sortie produites sur un ou plusieurs canaux de sorties Canal: Unidirectionnel au travers duquel circulent un flot de données (stream). Exemples :application de traitement de texte, de traitement de signaux, Compilateur (analyse lexicale, syntaxique, sémantique)

9 Styles Généraux Filtres & Canaux Architecture avec référentiel Multicouches 9 Exemple: Système de traitement du son Encodeur pour sortie de microphone Filtrer l écho Filtrer le bruit Retirer les fréquences non vocales Égaliser les les intervalles dynamiques Encodeur de bruit ambiant Décompresser Recevoir Transmettre Compresser Encoder la sortie des haut-parleurs

10 Styles Généraux Filtres & Canaux Architecture avec référentiel Multicouches 10 Avantages Bon pour traitement en lot (batch) Très flexible Analyse facilitée : performance, synchronisation, goulot d étranglement, Se prête bien à la décomposition fonctionnelle d un système Inconvénients Mauvais pour le traitement interactif

11 Styles Généraux Filtres & Canaux Architecture avec référentiel Multicouches 11 D un point de vue conception Diviser pour régner : les filtres peuvent être conçus séparément Cohésion : les filtres sont un type de cohésion fonctionnelle Couplage : les filtres n ont qu une entrée et une sortie en général Abstraction : les filtres cachent généralement bien leurs détails internes Réutilisabilité : les filtres peuvent très souvent être réutilisés dans d autres contextes Réutilisation : il est souvent possible d utiliser des filtres déjà existants pour les insérer dans le pipeline

12 Styles Généraux Filtres & Canaux Architecture avec référentiel Multicouches 12 Utilisée dans le cas où des données sont partagées et fréquemment échangées entre les composants Deux types de composants : référentiel de données et accesseur de données Les référentiels constituent le medium de communication entre les Accesseurs Connecteur : relie un accesseur à un référentiel Rôle de communication, mais aussi possiblement de coordination, de conversion et de facilitation

13 Styles Généraux Filtres & Canaux Architecture avec référentiel Multicouches 13 Variantes: Style tableau noir (Blackboard) :les référentiels sont des agents actifs. Lorsqu ils reçoivent une données, ils informent tous les accesseurs concernés afin de synchroniser l accès. Exemple: Environnement de programmation (compilateur), JVM (Java), Le noyau du système Linux. Style référentiel passif:les référentiels sont des simples vocations de stockage. Les composants accède aux référentiels comme ils le désirent. Exemples: application de bases de données, systèmes centrés sur les données (e.g. système bancaire, système de facturation,etc.),

14 Styles Généraux Filtres & Canaux Architecture avec référentiel Multicouches 14 Avantages: Avantageux pour les applications impliquant des tâches complexes sur les données, nombreuses et changeant souvent. Une fois le référentiel bien défini, de nouveaux services peuvent facilement être ajoutés Inconvénients: Le référentiel peut facilement constituer un goulot d étranglement, tant du point de vue de sa performance que du changement

15 Styles Généraux Filtres & Canaux Architecture avec référentiel Multicouches 15 Fondé sur la relation «peut utiliser» entre modules (etnon composants). Une couche est un incrément. vue «logique» montrant le découpage des fonctions de l application indépendante des considérations physiques une couche offre un service au couches externes met à profit la notion d abstraction, les couches externes sont plus abstraites que les couches internes. Exemple: Modèle OSI

16 Styles Généraux Filtres & Canaux Architecture avec référentiel Multicouches 16 On distingue deux variantes du système multicouche: Système fermé: une couche n a accès qu aux couches adjacentes. Les connecteurs ne relient que les couches adjacentes; Système ouvert:toutes les couches ont accès à toutes les autres. Les connecteurs peuvent relier deux couches quelconques

17 Styles Généraux Filtres & Canaux Architecture avec référentiel Multicouches 17 Système Fermé Système Ouvert

18 Styles Généraux Filtres & Canaux Architecture avec référentiel Multicouches 18 Notion de couche applicative: La structuration des applications se traduit par une décomposition logique en couches applicatives(couches logicielles) au sein d'une même application ou système. Le découpage en couche permet de modifier l'implémentation d'une couche sans impacter les autres couches applicatives. Les couches communiquent entre elles au travers d'un modèle d'échange «les contrôleurs», et chacune d'entre elles propose un ensemble de services rendus.

19 Styles Généraux Filtres & Canaux Architecture avec référentiel Multicouches 19 Couche Présentation: Elle gère et assure l'affichage des Interfaces Homme-Machine (IHM: fenêtres, pages, composants graphiques...) On distingue trois catégories d'ihm pour les applications interactives : Client léger : Aucun déploiement n'est réalisé sur le poste client à l'exception d'un navigateur Web (page HTML simple statique) Les différents écrans de l'application sont générés en temps réel côté serveur et téléchargés par le poste client. Client lourd : L'ensemble des écrans de l'application sont stockés ou générés sur le poste client et doivent avoir été déployés sur celui-ci préalablement à l'exécution: (Applets,Flash..) Client riche (Smart Client) : Compromis entre le client léger et le client lourd Plusieurs options sont disponibles pour le développement d'ihm riches, à savoir Ajax, Flex, Microsoft Silverlight, Google Web Toolkit qui permettent d exécuter directement le code dans le navigateur

20 Styles Généraux Filtres & Canaux Architecture avec référentiel Multicouches 20 Couche Métier: Elle correspond aux traitements qu effectue l application. Implémentation de la logique des cas d utilisation (use-case fonctionnels) Cette couche doit : implémenter la logique métier gérer la sécurité applicative gérer les transactions gérer les appels aux objets métiers. Exemple bancaire : Services métiers: l opération de virement de compte à compte. Objets métiers: le compte bancaire et le client et leurs règles de gestion respectives.

21 Styles Généraux Filtres & Canaux Architecture avec référentiel Multicouches 21 Couche Persistance: Nommée aussi couche d accès aux données. Elle prend en charge l'accès à la source de données (SGBDR, fichiers XML, LDAP, ). La couche Persistance offre les fonctionnalités de base qui permettent: de créer, rechercher, modifier et supprimer des composants objets métiers dans le respect des propriétés transactionnelles classiques. d utiliser le mécanisme de projection objet vers relationnel (mapping Objet / Relationnel) qui consiste en la transformation de la représentation des données en une représentation objet.

22 Styles Généraux Filtres & Canaux Architecture avec référentiel Multicouches 22 Le mapping objet relationnel crée une illusion d une BD Orientée Objet à partir d une BD relationnelle publicclassobj{ private int id; private String name; Table publicobj(){ } public Obj(String name){ this.name = name; } public void setid(int i){ id=i; }. } Classe Java correspondante

23 Styles Interactifs Basée évènements MVC 23 Composant: ils sont de nature abstraite, exposant des procédures et des événements. Procédure: Composant graphique Evénement = clic de souris, détection d un signal par un capteur, arrivée d un message, etc. Connecteur:Des liaisons entre des procédures et des événements. Un composant annonce un événement et tous les composants qui se sont enregistrés comme observateurs de cet événement sont prévenus. Appropriée pour les systèmes dont les composants doivent interagir avec l environnement. Exemples :La bibliothèque de composants graphiques Qt, Eclipse, Ajax, Erlang, JoCaml, Triggers de BD.

24 Styles Interactifs Basée évènements MVC 24 Séparer la couche interface utilisateur des autres parties du système Composé de trois types de composants Modèle : rassemble des données du domaine, des connaissances du système. Contient les classes dont les instances doivent être vues et manipulées Vue : utilisé pour présenter/afficher les données du modèle dans l interface utilisateur Contrôleur : contient les fonctionnalités nécessaires pour gérer et contrôler les interactions de l utilisateur avec la vue et le modèle

25 Styles Interactifs Basée évènements MVC 25 Est perçue par Utilisateur utilise Vue agit sur Contrôleur Met à jour Modèle Manipule

26 Styles Interactifs Basée évènements MVC 26

27 Styles Interactifs Basée évènements MVC 27 Modèle : noyau de l application Enregistre les vues et les contrôleurs qui en dépendent Notifie les composants dépendants des modifications aux données Vue : interface (graphique) de l application Crée et initialise ses contrôleurs Affiche les informations destinées aux utilisateurs Implante les procédure de mise à jour nécessaires pour demeurer cohérente Consulte les données du modèle Contrôleur : partie de l application qui prend les décisions Accepte les événement correspondant aux entrées de l utilisateur Traduit un événements (1) en demande de service adressée au modèle ou bien (2) en demande d affichage adressée à la vue Implémente les procédures indirectes de mise à jour des vues si nécessaire

28 Styles Interactifs Exemple du MVC pour le web: Basée évènements MVC 28

29 Styles Interactifs Basée évènements MVC 29 Avantages: Indépendance par rapport à l interface utilisateur, plusieurs vues pour le même modèle approprié pour les systèmes interactifs, particulièrement ceux impliquant plusieurs vues du même modèle de données. Peut être utilisé pour faciliter la maintenance de la cohérence entre les données distribuées Inconvénients: dans le cas d applications offrant des interfaces simples on aboutit à une complexité inutile

30 Styles Distribués n-tiers SOA 30 La vue en niveaux (tiers) donne une vision plus «physique» de la structuration de l application. Les niveaux peuvent être répartis physiquement sur différents composants matériels: N.b.L architecture multicouches est généralement utilisée pour décrire la structure interne (non distribuée) d un composant qui peut lui-même appartenir à une architecture (distribuée) n-partie. Composants :chaque niveaux est représenté par un composant qui joue le rôle de client et/ou de serveur Connecteurs :relient un client à un serveur. Connexion asymétrique. Doit supporter les communication distantes (e.g., requêtes RPC, HTTP, TCP/IP) Exemples: Architecture 1-tiers, Architecture 2-tiers, Architecture 3-tiers, Architecture n-tiers

31 Styles Distribués n-tiers SOA 31 Architecture Centralisée (1-tiers) Les trois couches applicatives sont liées et s'exécutent sur le même ordinateur. Serveur (Mainframe) Client léger : passif utilisé pour l affichage terminale. Inconvénients: Dépendance totale d un système centralisé Dépendance d un constructeur Coûts de maintenance très élevés Possibilités graphiques et multimédia très limitées

32 Styles Distribués n-tiers SOA 32 Architecture 2-tiers Architecture décentralisée L ensemble des traitements applicatifs est géré par le poste client : Client lourd La gestion des données est prise en charge par un SGBD centralisé. Avantages: Environnement graphique et multimédia avancé Intégration facile de la micro informatique Inconvénients Risque de surcharge du client Syndrome du «client obèse»

33 Styles Distribués n-tiers SOA 33 Architecture 3-tiers Architecture Distribuée Tous ces niveaux étant indépendants, ils peuvent être implantés sur des machines différentes Le poste client ne supporte plus l'ensemble des traitements (client riche ou léger) Facilité de déploiement Sécurité : pas d exposition du schéma de la base de données La manipulation des données est indépendante du support physique de stockage.

34 Styles Distribués n-tiers SOA 34 Architecture 3-tiers Navigateur Présentation Traitement Tier 1 : Client Tier 2:Serveur d applications Client: Gestion de la présentation Serveur applicatif:lien entre clients et plusieurs serveurs de BD Serveur de données:gestion accès à BD données Base de données Tier 3:Base de données

35 Styles Distribués n-tiers SOA 35 Architecture n-tiers La littérature parle du modèle générique «N-tiers»(ou N-niveaux) Rajoute des étages / couches en plus La couche applicative n'est pas monolithique Le modèle N-tiers est celui mis en œuvre dans le cadre des projets web Exemple : tiers impliqués dans le modèle d architecture J2EE

36 Styles Distribués n-tiers SOA 36 Résumé sur l architecture multi-tiers

37 Styles Distribués n-tiers SOA 37 SOA est apparu en 1996 dans une note de recherche du Gartner Group. «L architecture orientée service constitue un style d architecture basée sur le principe de séparation de l activité métier en une série de services.» «Ces services peuvent être assemblés et liés entre eux selon le principe de couplage lâche pour exécuter l application désirée.» «Ces services sont définis a un niveau supérieur de la traditionnelle approche composants» Gartner - Septembre 2005

38 Styles Distribués n-tiers SOA 38 Programmation structure = robuste et réutilisable Langage purement procéduraux -> Code réutilisable? = (fonctions + des procédures) Fichier sépare Programmation Orientée Objet (POO)-> Code réutilisable? = définition et l'assemblage de briques logicielles (Objets) ; Envoie des messages grâce aux appels des méthodes Solutions de transports au delà des frontière des SI --->>> Problèmes de compatibilité entre plateformes Besoin de standardisation et la mise en commun des protocoles ( SOAP, XML,.) La pensé orientée services

39 Styles Distribués n-tiers SOA 39 Dans une SOA un niveau d'indirection supplémentaire est introduit sous la forme de la couche Services. Composant: Services Connecteurs :Techniques et protocoles de communication entre service : Bus de communication, HTTP, Les services agissent comme des «boites noires», encapsule ces traitements et données et masque ainsi l hétérogénéité du système d information.

40 Styles Distribués n-tiers SOA 40 Vision POO et SOA? -> savoir où se situent les différences Modèle orienté objets (POO) Modèle orienté services (SOA)

41 Styles Distribués n-tiers SOA 41 La notion de «service» est le concept phare. Les Services Web sont juste un moyen de les implémenter. La mise en place d'une architecture SOA répond à un besoin de: réutilisation des traitements, interopérabilité, fiabilité, sécurité, hétérogénéité.

42 Styles Distribués n-tiers SOA 42 Les services: Le service est un composant clef de l'architecture Orientée Services. Consiste en une fonction ou fonctionnalité bien définie. Expose une interface qui définit le traitement offert sous la forme d un message d entrée et d un autre de réponse. Exprime un niveau «logique» d accès aux traitements et pas un niveau «physique» d implémentation.

43 Styles Distribués n-tiers SOA 43 Les services: Partage les caractéristiques suivantes d un objet: Modulaire (ensemble de fonctionnalités qui font sens) Partage les caractéristiques suivantes d un composant Boite noire (séparation interface/implémentation) Indépendant de la localisation Neutralité vis-à-vis des protocoles de transport Correspond à un périmètre fonctionnel que l on souhaite exposer à des consommateurs (il a une granularité plus forte qu un composant) Est faiblement couplé (indépendant des autres services) Expose un petit nombre d opérations offrant un traitement de bout en bout Sans état

44 Styles Distribués n-tiers SOA 44 Les 4 propriétés du service à retenir: Un Service est Autonome Un Service expose un Contrat in out Conditions Générales de Vente Règlement Intérieur Vos droits/vos devoirs Les services communiquent par Les Frontières entre services messages sont Explicites