ARCHITECTURE DACCS la mthode gnrale

1
ARCHITECTURE DACCÈSla méthode générale
modèle de données
définir
définitions module daccès / modules métiers
décrire
construction des modèles
générer
les modules daccès, les programmes de test, la
documentation
2
MODULES DACCÈS VS MODULES  METIERS 
programmes
mod. accès  client 
mod. accès  détail 
mod. accès  produit 
mod. accès commande
3
MODULES DACCÈS VS MODULES  METIERS 

• Rôles d'un module d'accès
• assurer une certaine indépendance des programmes
  par rapport à la BD
• homogénéiser l'accès aux BD (si différents types
  de SGBD)
• centraliser les accès aux données dans un seul
  module
• vérifier les contraintes d'intégrité
• assurer la confidentialité et le contrôle d'accès
• gérer les transactions
• mettre en place de points de mesures (pour
  statistique ou facturation)

• Rôles d'un module  métier 
• mêmes rôles qu'un module d'accès
• indépendance des programmes par rapport à la BD
• simplification des programmes
• les règles de gestion des composants métiers sont
  écrites une seule fois de manière centralisée et
  par des  spécialistes 
• amélioration de la maintenance
• optimisation des performances

modules daccès
Programme n

Programme 3
Programme 2
modules métier
Programme 1
4
ARCHITECTURE DACCÈSla méthode générale
modèle de données
définir
définitions module daccès / modules métiers
décrire
construction des modèles
générer
les modules daccès, les programmes de test, la
documentation
5
CONSTRUCTION DU MODELE METIER

• Le modèle métier est dérivé du modèle logique
• par transformation dans DB-MAIN
• conserve le mapping entre les deux schémas

les instructions dépendent de la plateforme
technologique
6
CONSTRUCTION DU MODELE METIER

• formalisme pour représenter un schéma métier
• proche d'un schéma entité-association
• garde le lien entre le schéma logique et le
  schéma métier
• permet une génération automatique des composants

association 0-N(entre concepts)
concept
attribut décomposable
attribut (simple)
critère d'accès
méthode/fonction
7
CONSTRUCTION DU MODELE METIER
enrichissement du modèle par simple ajout de
méta-propriétés dans DB-MAIN
informations complémentaires
name nom du composant sem description du
composant select sélection (clause
where) order_by clé de tri updatable true/fals
e var déclaration de variables en
working host_var déclaration de "host
variables" insert_pre code à exécuter avant une
insertion insert_post code à exécuter après une
insertion tech code à ajouter à la fin du
programme
name nom de la relation sem description de la
relation
sem description de l'attribut select
sélection (clause where) order_by clé de tri
name nom de la méthode sem description de la
méthode tech code de la méthode
sem description du critère name nom du
critère tech sélection (clause where)
order_by clé de tri
8
ARCHITECTURE DACCÈSla méthode générale
modèle de données
définir
définitions module daccès / modules métiers
décrire
construction des modèles
générer
les modules daccès, les programmes de test, la
documentation
9
GÉNÉRATION DES MODULES DACCÈS

• génération des modules
• dépend du langage de la plateforme technique
  (COBOL, C, C, JAVA,)
• la génération des modules métiers peut se faire
  simultanément dans plusieurs langages (ex JAVA
  et COBOL)
• ? une même base peut-être accédée suivant la même
  logique par des applications différentes et/ou
  complémentaires (application  back-end  en
  COBOL et  front-end  en JAVA pour linternet)
• génération de la documentation
• génération des programmes de test
• permet de valider les modules générés

10
INTERETS DES MODULES METIERS

• lors de la conception
• environnement de conception
• méthode
• formalisme
• indépendance par rapport aux structures physiques
• si changement de la BD sans changement du métier
• ? modification des composants métier
• ? pas de répercussion dans les programmes
• si un changement du métier entraîne une
  modification de la base de données
• ? modification des composants métiers
• ? souvent répercussion dans les programmes
• génération automatique
• du code
• de la documentation
• de programmes de test

• lors de la maintenance
• modification des modèles logique et métier
• (re-) génération automatique
• analyse d'impact
• liste des composants impactés
• liste des programmes utilisant les composants
  impactés

11
INTERETS DES MODULES METIERS
SANS LES MODULES
AVEC LES MODULES

• une grande partie des contraintes ne sont pas
  gérées par le SGBD
• ? 50 de contraintes implicites
• les contraintes implicites doivent être gérées
  par les programmes
• ? risques derreurs
• code dupliqué
• programmeur ne connaît pas toutes les contraintes
  à vérifier
• ? problèmes de maintenance
• si changement du SGBD
• si changement de la structure de la BD

• dissociation des traitements et des données
• simplification des programmes
• moins de code dupliqué
• pas de nécessité pour le programmeur de connaître
  les contraintes
• diminution drastique du risque derreurs (moins
  de code et code écrit par des  spécialistes )
• meilleur codage des contraintes (plus efficaces,
  plus lisibles, )
• maintenance aisée