Bibliographie & annexes
Présentation
Auteur(s)
-
Martial CHRISMENT : Ingénieur en informatique de l’École nationale supérieure d’électronique, d’électrotechnique, d’informatique et d’hydraulique de Toulouse (ENSEEIHT) Société TOOL OBJECT
Lire cet article issu d'une ressource documentaire complète, actualisée et validée par des comités scientifiques.
Lire l’articleINTRODUCTION
La programmation objet est à l’heure actuelle incontournable dans le monde industriel, comme le montre la place de plus en plus importante accordée à des technologies telles que Java, C++, EJB (Enterprise Java Bean), Corba ou DCOM (Distributed COM). En effet, ce type de programmation a l’avantage de rester proche de la conception et facilite à la fois la maintenance et l’évolutivité.
Même si, dans un modèle d’architecture 3-tiers (séparation de la présentation, du traitement et des données), les concepts objet sont aussi présents dans la couche « présentation » (par exemple, à travers la notion de Java Bean), leur couche de prédilection demeure cependant la couche « traitement » où réside le cœur même du métier. La couche « données » reste, quant à elle, très en retard dans ce domaine. Les systèmes de gestion de bases de données purement objet sont peu nombreux sur le marché, alors que les systèmes de gestion de bases de données relationnelles intégrant des concepts objet (relationnel orienté objet [1]) restent encore immatures en occultant très souvent les problématiques d’héritage.
Le problème de transposition d’applications conçues avec une approche objet et destinées à être implantées dans un contexte relationnel est, de ce fait, de plus en plus récurrent au sein des entreprises. Pour y pallier, on a souvent recours à la mise en œuvre de requêtes SQL (Standard Query Language) spécifiques qui ne tiennent pas compte du modèle objet de départ. Bien que relativement efficace, cette solution rend plus complexe toute évolution du modèle objet car les impacts au niveau de la couche « données » sont difficiles à évaluer et rarement négligeables.
Une solution intéressante consiste en la définition de règles de transposition du modèle objet en modèle relationnel, tant au niveau statique (définition des tables relationnelles) qu’au niveau dynamique (méthodes d’accès aux données).
L'expertise technique et scientifique de référence
VERSIONS
- Version courante de févr. 2012 par Martial CHRISMENT
DOI (Digital Object Identifier)
Cet article fait partie de l’offre
Technologies logicielles Architectures des systèmes
(239 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive
Présentation
Autres solutions3. Transposition dynamique
La transposition dynamique consiste à faire correspondre les traitements définis sur les objets avec les données de la base de données (BD). L’efficacité des requêtes BD dépend alors fortement des choix faits lors de la transposition statique.
Dans le contexte d’une architecture 3-tiers, la transposition dynamique se fait de la manière décrite figure 8.
La couche présentation n’intervient pas dans le processus de transposition dynamique. En effet, ce dernier nécessite deux niveaux de transposition répartis sur les couches traitement et données :
-
les méthodes API (interface de programmation d’application) d’accès aux données de la couche données. Ces méthodes gèrent l’ajout, la suppression, la modification ou la sélection des données sur les structures de stockage. Elles sont définies en fonction de la structure relationnelle ;
-
les méthodes d’accès aux données orientées objet et de gestion de persistance de la couche traitement. Ces méthodes permettent de regrouper, dans une même unité d’œuvre, un ensemble de méthodes API d’accès aux données de la couche données afin de matérialiser l’ajout, la suppression, la modification ou la sélection d’objets. Elles sont définies en fonction du modèle objet de conception.
Ce type de transposition est souvent associé à la notion de langage de manipulation de données (DML : Data Manipulation Language) qui permet de manipuler les données et non de définir des structures. Toutefois, le DML permet de trouver des solutions en ce qui concerne les méthodes API de la couche données mais ne procure pas d’aide supplémentaire en ce qui concerne la gestion de la persistance.
3.1 Définition des classes de traitement
Les structures relationnelles seront accédées par des classes implantées dans le langage de programmation orienté objet utilisé au niveau de la couche traitement. Pour illustrer les règles présentées dans cet article, le langage Java sera utilisé du fait de sa simplicité d’utilisation et de sa popularité croissante [4].
Les classes à implanter se déduisent assez simplement d’un modèle de conception objet écrit en UML par exemple. Il en est pour preuve que de nombreux outils, comme Rational Rose, proposent des générateurs automatiques de classes à...
L'expertise technique et scientifique de référence
Cet article fait partie de l’offre
Technologies logicielles Architectures des systèmes
(239 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive
Transposition dynamique
BIBLIOGRAPHIE
-
(1) - GRIMES (S.) - Modeling Object/Relational Databases. - Avr. 1998.http://dbmsmag.com/9804d13.html
-
(2) - MULLER (P.A.), GAERTNER (N.) - Modélisation objet avec UML. - Eyrolles (2000).
-
(3) - MARÉE (C.), LEDANT (G.) - SQL 2 Initiation Programmation. - Armand Colin (1994).
-
(4) - FLANAGAN (D.) - Java in a nutshell. - O’Reilly (2000).
-
(5) - SOUTOU (C.) - Objet‐relationnel sous Oracle8. - Eyrolles (1999).
DANS NOS BASES DOCUMENTAIRES
ANNEXES
(liste non exhaustive)
Rational http://www.rational.com
Popkin Software http://www.popkin.com
Softeam http://www.objecteering.com
Cognicase http://www.cognicase.com
HAUT DE PAGE
L'expertise technique et scientifique de référence
Cet article fait partie de l’offre
Technologies logicielles Architectures des systèmes
(239 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive
