1. 1 ACCESS ARCHITECTURE the general method data models access / business modules definitions models construction the access modules, the test programs, the documentation define describe generate

2. 2 PRODUCT num_prod Descr prix id:num_prod Detail num_com num_prod qte id: num_com ref:num_com ref:num_prod ORDER num_com num_cli Date id:num_com ref:num_cli Cust Num_cli nom id:Num_cli Access mod « customer » programs ACCESS MODULES VS BUSINESS MODULES BUSINESS MODULE COM-PRIX-TOTAL IS CALCULATED BY THE BUSINESS OBJECTS Access mod detail Access mod order Access mod « product » PRODUCT PROD-NUM PROD-DESC PROD-PRICE id:PROD-NUM DETAIL DET-NUM-ORD DET-NUM-PROD DET-QTY id:DET-NUM-ORD DET-NUM-PROD ref:DET-NUM-ORD ref:DET-NUM-PROD ORDER ORD-NUM ORD-NUM-CUS ORD-DATE id:ORD-NUM ref:ORD-NUM-CUS CUSt CLI-NUM CLI-NOM id:CLI-NUM

3. 3  Access modules roles  To garantee some independance to the programs vs the DB  To homogenise DB access (if different DBMS)  To centralize the data access in a single module  To verify the integrity constraints  To garantee confidentiality and access control  To manage the transactions  To put measure points in place ( for statistical or invoicing purpose) Program n … Program 3 Program 2 Program 1 Business modules  Business modules roles  Same role as access modules +  Programs are totally independant from the DB  Programs are getting simpler  The management rules for the business objects are written once and by business specialists.  Maintenance improvement  Performances optimization Access modules Access modules vs business modules

4. 4 ACCESS ARCHITECTURE the general method data models access / business modules definitions models construction the access modules, the test programs, the documentation define describe generate

5. 5 BUSINESS MODULE CONSTRUCTION LOGICAL MODEL The business module is derived from the logical model  by transformation within DB-MAIN  Keeps the mapping between the 2 schemas BUSINESS MODULE 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 The instructions depend on the technological platform

6. 6  Formalism to represent business module  Close to an entity-relationship schema  Keeps the link between the logical schema and the business schema  Allows an automatic generation of the components concept association 0-N (between concepts) attribute (simple) Decomposable attribute Access criteria method/function BUSINESS MODULE CONSTRUCTION

7. 7 name :component name sem :component description select : selection (clause where) order_by : sort key updatable:true/false var : varaibles declaration in working host_var : déclaration of "host variables" insert_pre:code to be executed before an insertion insert_post:code to be executed after an insertion tech : code to be added at the end of the program BUSINESS MODULE CONSTRUCTION sem :attribute description select :selection (where clause ) order_by :sort key sem :criteria description name : criteria name tech : selection (clause where) order_by :sort key name : method name sem :method description tech : method code compte-10-mvt num solde mouvement[10-10] date valeur id:num acc:solde id(mouvement): date method Complementary informations name :relation name sem :relation description Model enrichment by simply adding meta- properties in DB-Main.

8. 8 ACCESS ARCHITECTURE the general method data models access / business modules definitions models construction the access modules, the test programs, the documentation define describe generate

9. 9 ACCESS MODULE GENERATION  Modules generation  Depends on the technical platform language (COBOL, C, C++, JAVA,…)  The generation of business modules can be done simultaneously in different languages( eg: JAVA and COBOL)  The same base can be accessed following the same logic by different applications ( back-end application in Cobol and front-end application in Java for the internet)  Ducumentation generation  Test program generation  Allow to test the generated modules

10. 10 BUSINESS MODULES ADDED VALUE At conception time  Conception environment  method  formalism  Independence vs the physical structure  If change in the DB without busines change  modification of the business modules  no modification in the programs  If a busines change implies a change in the DB  busines modules modifications  very often, programs modifications  Automatic generation  code  documentation  Test programs At maintenance time  Modification of the logical and business models  Automtic (re-) generation  Impact analysis  Impacted components list  Programs list using the impacted components

11. 11  A large part of the constraints are not managed by the DBMS  50% of the implicit constraints  The implicit constraints have to be managed by the programs  Error risks :  Duplicated code  The programmer doens’t know all the constraints to verify  Maintenance problems  If DBMS change  If DB structure change Program n … Program 3 Program 2 Program 1 Program n … Program 3 Program 2 Program 1 modules WITHOUT THE MODULESWITH THE MODULES  Procesing and data dissociation  Programs simplification  Less duplicated code  The programmer doesn’t have to know the constraints  Drastic reduction of the errors risks ( less code and code written by specialists)  Constraints are better coded ( more readable, more efficient..;)  Easier maintenance BUSINESS MODULES ADDED VALUE