1 ARCHITECTURE DACCÈS la méthode générale modèle de données définitions module daccès / modules métiers construction des modèles les modules daccès, les.

Présentation au sujet: "1 ARCHITECTURE DACCÈS la méthode générale modèle de données définitions module daccès / modules métiers construction des modèles les modules daccès, les."— Transcription de la présentation:

1 1 ARCHITECTURE DACCÈS la méthode générale modèle de données définitions module daccès / modules métiers construction des modèles les modules daccès, les programmes de test, la documentation définir décrire générer

2 2 Produit num_prod libelle prix id:num_prod Detail num_com num_prod qte id: num_com ref:num_com ref:num_prod Commande num_com num_cli Date id:num_com ref:num_cli Client Num_cli nom id:Num_cli mod. accès « client » programmes MODULES DACCÈS VS MODULES « METIERS » module métier COM-PRIX-TOTAL est calculé par le composant métier mod. accès « détail » mod. accès commande mod. accès « produit »

3 3 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) Programme n … Programme 3 Programme 2 Programme 1 modules métier 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 MODULES DACCÈS VS MODULES « METIERS »

4 4 ARCHITECTURE DACCÈS la méthode générale modèle de données définitions module daccès / modules métiers construction des modèles les modules daccès, les programmes de test, la documentation définir décrire générer

5 5 CONSTRUCTION DU MODELE METIER MODELE LOGIQUE 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 MODELE METIER sem :la dernière commande select : date in (select max(date) from commande) sem : retourne les commandes passées le "DATE" name : DATE tech : COMMANDE.DATE = :TB-COMMANDE.TB-DATE tech : PERFORM COMPUTE-PRIX-TOTAL. tech : COMPUTE-PRIX-TOTAL..... 1-1 0-N PASSE-LAST 1-1 0-N PASSE acc:COMMANDE COMMANDE-LAST NUM-COM NOM PRENOM ADRESSE DATE DETAIL[0-20] NUM-PROD LIBELLE QTE PRIX PRIX-TOTAL id:NUM-COM COMMANDE NUM-COM NOM PRENOM ADRESSE DATE DETAIL[0-20] NUM-PROD LIBELLE QTE PRIX PRIX-TOTAL id:NUM-COM acc:DATE ADD-DETAIL DEL-DETAIL CLIENT NUM-CLI NOM PRENOM ADRESSE TELEPHONE id:NUM-CLI acc:NOM les instructions dépendent de la plateforme technologique

6 6 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 concept association 0-N (entre concepts) attribut (simple) attribut décomposable critère d'accès méthode/fonction CONSTRUCTION DU MODELE METIER

7 7 name :nom du composant sem :description du composant select : sélection (clause where) order_by : clé de tri updatable:true/false 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 CONSTRUCTION DU MODELE METIER sem :description de l'attribut select :sélection (clause where) order_by :clé de tri sem :description du critère name : nom du critère tech : 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 compte-10-mvt num solde mouvement[10-10] date valeur id:num acc:solde id(mouvement): date method informations complémentaires name :nom de la relation sem :description de la relation enrichissement du modèle par simple ajout de méta-propriétés dans DB-MAIN

8 8 ARCHITECTURE DACCÈS la méthode générale modèle de données définitions module daccès / modules métiers construction des modèles les modules daccès, les programmes de test, la documentation définir décrire générer

9 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 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 11 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 Programme n … Programme 3 Programme 2 Programme 1 Programme n … Programme 3 Programme 2 Programme 1 modules SANS LES MODULESAVEC LES MODULES 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 INTERETS DES MODULES METIERS