Agile Data L'apport de JDO a un processus AgileXP

1
Agile DataL'apport de JDO a un processus Agile/XP
Régis Le BrettevilloisCTOLIBeLIS  Transparent
Persistence for Java 
2
Vue densemble

• Constat / Principes
• JDO
• Application au Processus Agile
• Du modèle vers les données
• Considérations
• Conclusion

3
Constat/Principes
4
Le constat

• 65-85 des projets importants échouent
  (StandishGroup)
• Modélisation et accès aux données.
• Mauvaise coordination/compréhension dans les
  équipes
• Développeur applicatif
• Administrateur de données

5
Rôles

• Développeur Applicatif
• Administrateur de données
• Architecte dEntreprise
• Administrateur dEntreprise

6
Valeurs XP et Agile Modeling

• Simplicité
• Communication
• Interaction
• Courage
• Humilité

7
Principes

• Tester
• Développement incrémental
• Feedback rapide
• Construire avec simplicité

8
Modèle en couches
Application
Logique de Présentation
Objet de Présentation
Système dinformation
Logique Métier
Objets Métier
Objets Données
9
JDOJava Data Objects
10
JDO Une approche transparente

• JSR-012 JDO
• Initié par des acteurs de la base de donnée.
• Voté par le JCP en avril 2002.
• Mécanismes de gestion du stockage des objets
  (persistance)
• Non intrusif.
• Indépendant de lenvironnement dexécution
• architecture client/serveur, conteneur WEB ou
  EJB
• source de données SGBDR, SGBDO, XML, fichiers
  semi structurés, gros systèmes

11
Support des  champs  Java

• Types primitifs
• boolean, byte, short, int, long, float, double
• Types objets considérés comme des primitifs
• Boolean, Byte, Short, Integer, Long, Float,
  Double
• java.math.BigInteger, java.math.BigDecimal
• java.lang.String, java.util.Date, java.util.Locale

12
Support des  relations  Java

• Unaire
• PersistenceCapable
• Object
• Interface
• N-aire
• Collections Java2 (Set, List, Map)
• Vector, Hashtable
• Aggregation (cascade), Composition (embedded)
• Support des objets non PersistenceCapable.

13
Chaîne de production JDO
JDO enhancer
code source
byte code
javac compilateur
byte code

• Instrumentation du code par ajout dinstructions
  au sein du byte code.

Mapping (xml file)
implémentation JDO
Definition (xml file)
JVM
14
Requêtes en JDO

• Mécanisme déclaratif (JDOQL)
• Navigationnel
• Tri
• Exemple
• Query q pm.newQuery(Compte.class, "solde gt
  100000")
• Collection emps (Collection)q.execute()
• Exemple Paramétré
• q pm.newQuery(Compte.class, "solde gt
  baseSolde")
• q.declareParameters("double baseSolde")
• emps (Collection)q.execute(new Double(100000))

15
Indépendant de la source
16
Indépendant de l'architecture
17
Application au Processus Agile
18
Modélisation du domaine
19
Prototype non persistent

• Valider le modèle
• try
• compte1 trouverCompte(id1)
• compte2 trouverCompte(id2)
• debit compte1.debit(montant)
• compte2.credit(debit)
• catch ()

20
Mapping Top-Down

• ltjdogt
• ltclass name"Compte"/gt
• ltclass name"Client"/gt
• ltclass name"ClientEntreprise"/gt
• lt/jdogt

21
Prototype persistant

• Tester le modèle persistant sans se préoccuper du
  modèle physique
• PersistenceManager pm factory.getPersistenceMana
  ger()
• Transaction tx pm.currentTransaction()
• try
• compte1 trouverCompte(id1)
• compte2 trouverCompte(id2)
• debit compte1.debit(montant)
• compte2.credit(debit)
• tx.commit()
• catch ()
• tx.rollback()

22
Considérer les contraintes

• Modèle de données existant
• Conversion
• Agrégation de données
• Nouveau modèle de données
• Contraintes dEntreprise

23
Interfaçage avec lexistant
24
Mapping bottom-up

• ltjdogt
• ltclass name"Client"gt
• ltfield name"id" primary-key"true"/gt
• lt/classgt
• lt/jdogt

25
Mapping

• ltmappinggt
• ltclass name"ClientParticulier"
  table"CLIPART"gt
• ltfield name"id" column"ID"
  primary"true"/gt
• lt/classgt
• lt/mappinggt

26
Considérer les performances

• Modèle logique ? Modèle physique
• Points important
• Cardinalité des collections
• Chargement de groupes dobjets (cluster)
• Requêtes

27
Collections paginées

• Ne pas charger l'ensemble des objets en mémoire.
• N'instancier que le stricte nécessaire
• Utiliser les mécanismes de résultats paginés de
  la base.

28
Chargement de groupe dobjets (1)

• Optimiser le chargement d'objet dans des cas
  d'utilisation particuliers.
• helper.addFetchingStrategy("usecase1")
• try
• client1 trouverClient(id1)
• // itérer sur lensemble des comptes du client
• catch ()

29
Chargement de groupe d'objets (2)

• ltrepositorygt
• ltfetching-strategy name"usecase1"gt
• ltclass name"Client"gt
• ltfield name"comptes"/gt
• lt/classgt
• lt/fetching-strategygt
• lt/repositorygt

30
Requêtes (1)

• S'abstraire des optimisations et des langages
  sous-jacents.
• try
• Query q helper.newQuery("query3")
• catch ()

31
Requêtes (2)

• ltrepositorygt
• ltquery name"query3"gt
• ltuse-fetching-strategy"query3strategy"/gt
• ltjdoql
• parameters"String unNom" filter "nom
  unNom"/gt
• lt/querygt
• lt/repositorygt

32
Requêtes (3)

• ltrepositorygt
• ltquery name"query3"gt
• ltsql
• parameters"String unNom" filter
• "NOM unNom"/gt
• lt/querygt
• lt/repositorygt

33
Considérer la concurrence

• La transparence n'enlève pas les problèmes de
  concurrence et d'isolation!
• Stratégie pessimiste
• Stratégie optimiste
• Stratégies de détection
• Stratégies de résolution

34
Conclusion
35
Conclusion

• Processus souple et évolutif
• Permet de séparer les rôles
• Framework "normalisé"
• Evolution vers une abstraction totale du système
  de données sous-jacent

36
Références

• http//java.sun.com/products/jdo
• http//jdocentral.com
• http//www.agiledata.com
• http//www.agilemodeling.com

37
Livres

• Planning Extreme Programming
• Kent Beck, Martin Fowler
• Java Data Objects
• Robin Roos
• Agile Modeling Effective Practices for Extreme
  Programming and the Unified Process
• Scott Ambler