On peut diviser les architecture applicatives en trois parties principales :
- Les couches logiques— C’est la première étape de la définition d’une architecture informatique
- La vue modèle — La vue modèle représente tous les modèles utilisé dans l’architecture de l’application
- Les couches physiques — Cette dernière étape de la définition est étroitement liée à la phase de déploiement (UML)
Les couches Logiques
Les couches logiques sont généralement définies par leur domaine d’action . La définition de telle couches permet de garantir une meilleure réutilsabilité des composant et de faciliter leur maintenance. Il est primordial, lors de la définition des couches de l’application de porter une attention particulière sur les communication inter-couche. Un représentation généralement admise des SI repose sur les couches logiques suivantes :
- Couche de Présentation : Cette couche représente l’interface graphique utilisateur. Elle est basée sur des technologies client est est fréquemment générée coté serveur par un environnement J2EE. C’est dans cette couche qu’interviennent les validation des saisies ainsi que le formatage des affichages.
- Couche d’application : Cette couche, reliée à la couche de présentation prend en charge la gestion des événement induits par la couche de présentation (navigation entre écrans, clics, gestion des éléments graphiques…). Ces deux couches sont étroitement liées et sont souvent regroupées, ou peuvent interagir en se reposant sur des frameworks (1) dédiés.
- La couche de Service métier : C’est dans cette couche que résident les services à proprement parlé, qui sont fournis aux différentes applications. Ils implémentent les différents besoins du domaine d’activité de l’entreprise, ainsi que des services plus transverses tels que l’authentification, la gestion des autorisation, la gestion des transactions… Ces services sont utilisés dans les couches supérieures pour répondre aux besoins des utilisateurs. Ils sont implémentés sous forme de classes simples qui sont indépendantes du type des données sources. Dans ce sens il correspondent à une vison objet du domaine métier. Ils sont identifié lors de la phase de conception et sont référencé dans les spécifications techiques détaillées du projet.
- La couche d’accès aux données : Dans cette couche on encapsule des acces à des systèmes externes et aux ressources. Cette couche contient étaglement les mécénismes de persistence (implémenté par des moteurs de mapping relationnel/objet).
- La couche de données : Cette couche contient les systemes de gestion des données (SGBD) uniquement, c’est à dire qu’il ne doit pas y voir de code dans cette couche.
La vue modèle
elle recense les modèles suivants :
- Le Modèle de Présentation : il est composé d’objets non persistents fortement dépendant de l’interface graphique de l’application. Ces objets peuvent en référencer d’autre, faisant partie du modèle public de la couche service métier.
- Le modèle Public : est une représentation du modèle fonctionnel. Il est indépendant du modèle technique (private model). Ce modèle est régi par les règles suivantes :
- Les objets métiers sont utilisés pour communiquer les informations à la couche de présentation ou a des applications externes.. Les objets métiers du modèle public sont indépendant des objets du modèle privé
- Les objets métiers ne possède aucune méthid, si ce n’est des méthode totalement dédiées à l’acces au données (getters). Il ne doit y avoir aucune méthode de traitement ou validation
- Les attributs des objets métiers stockent uniquement des informations publiques, on ne doit y trouver aucune information privée ou technique.
- Un objet métier peut référencer d’autres objets métiers
- L’héritage n’est pas autoriser entre objets métiers
- Les objets métiers ne doivent utiliser que des type de données collections simples tels que les tableaux.
- Aucun cycle n’est permis dans le graphe d’association des objets métiers.
- Leur usage étant transverse à plusieurs couches, ces objets doivent etre sérialisable
- Les objets métiers sont volatiles (non persistent).
- Le modèle privé est constitué d’objets persistent plus ou moins dépendant du modèle physique (ex schéma de base de données). C’est la vue orienté objet du schéma de base de données. Ce modèle est régi par les règles suivantes :
- Il faut utiliser un system de mapping relationnel/objet.
- Le modèle privé doit etre indépendant du systeme de mapping relationnel/objet.
- Il faut incoporer des mécanismes de liaison de données non objets (jointures de tables…).
- Il faut optimiser ce modèle afin de rendre les requêtes plus performantes.
- Le modèle physique est relatif à la couche physique dans laquelle les données sont stockées. Généralement il s’agit du schéma de la base de données.
La couche physique
La couche physique est la troisième étape de la définition de l’architecture. Elle correspond à la phase de déploiement UML.
On s’accorde fréquemment à découper la couche physique en trois zone de sécurité différentes :
- DMZ Présentation : Elle inclut la couche de présentation et la couche d’application
- DMZ Application : Elle inclut la couche service métier et la couche d’accès aux données
- DMZ Données : Elle inclut la couche de données
Ces zones de sécurité, on le constate sont distinctes de la notion de couche applicative, telles qu’elles sont définies ci-dessus.
(1) cf. sur articles concernant les frameworks.
Post a Comment