© Éditions Eyrolles
15
Introduction
de la part de communautés comme SDO (Service Data Object), JDO (Java Data Object) et JPA
(Java Persistance API), il y a fort à penser que beaucoup d’approches seront « hors norme ».
En effet, chaque éditeur ou communauté voudra surtout mettre en avant son environnement
(.Net avec Microsoft, Java pour Sun, etc.).
Concernant la conception, le bon sens me fait penser qu’il est nécessaire de préserver certains
aspects qui ont fait la force des systèmes relationnels (normalisation et indépendance données/
traitements) tout en mettant en œuvre des avantages indéniables qu’offre l’approche objet
(modularité, réutilisation et encapsulation). C’est l’idée générale dans cet ouvrage que nous
développerons.
Du modèle entité-association à UML
Comme nous l’avons évoqué dans l’avant-propos, le modèle entité-association a près de 30 ans
d’existence. Il a fait ses preuves puisque tous les outils de conception l’ont employé jusqu’à
récemment, certains produits continuent à l’utiliser en parallèle à UML. L’adoption généralisée
de la notation UML dépasse le simple effet de mode.
Pourquoi faudra-t-il utiliser UML ?
Tout simplement parce que la majorité des nouveaux projets industriels utilisent la notation
UML. Pour convaincre les récalcitrants, je pourrais citer le nom des entreprises appartenant au
consortium ayant mis en place UML : DEC, HP, IBM, Microsoft, Oracle et Unisys pour parler
des plus connues. Tous les cursus universitaires informatique, qu’ils soient théoriques ou plus
techniques, incluent l’étude d’UML. Je pourrais enfin évoquer le nombre d’ouvrages et d’articles
parus sur le sujet… Cela ne signifie pas qu’UML soit la panacée, mais que cette notation est
devenue incontournable. La dernière version de la spécification UML, sortie en 2006, est la 2.1
(la précédente était la 2.0 en 2003).
Ce succès s’explique par la réussite de la normalisation des concepts objet, qui ont des avantages
indéniables au niveau des applications informatiques. Ses principaux avantages sont la
réutilisabilité de composants logiciels, la facilité de maintenance, de prototypage et d’extension
des applications. Il aura fallu ainsi près de 30 ans (depuis 1966 avec les deux Norvégiens Dahl
et Nygaard et leur langage objet SIMULA) pour que l’approche objet devienne incontournable.
Alors que UML 1.x définit neuf diagrammes : cinq pour les aspects statiques (classes, objets,
cas d’utilisation, composants et déploiement) et quatre pour les aspects dynamiques
(séquence, collaboration, états-transition, activités), UML 2 ajoute ceux d’interaction, de
structure composite et le timing diagram. Ce livre ne s’intéressera qu’à celui convenant à la
conception d’une base de données, à savoir le diagramme de classes, qui fait partie de l’aspect
statique d’UML.
15
Introduction
de la part de communautés comme SDO (Service Data Object), JDO (Java Data Object) et JPA
(Java Persistance API), il y a fort à penser que beaucoup d’approches seront « hors norme ».
En effet, chaque éditeur ou communauté voudra surtout mettre en avant son environnement
(.Net avec Microsoft, Java pour Sun, etc.).
Concernant la conception, le bon sens me fait penser qu’il est nécessaire de préserver certains
aspects qui ont fait la force des systèmes relationnels (normalisation et indépendance données/
traitements) tout en mettant en œuvre des avantages indéniables qu’offre l’approche objet
(modularité, réutilisation et encapsulation). C’est l’idée générale dans cet ouvrage que nous
développerons.
Du modèle entité-association à UML
Comme nous l’avons évoqué dans l’avant-propos, le modèle entité-association a près de 30 ans
d’existence. Il a fait ses preuves puisque tous les outils de conception l’ont employé jusqu’à
récemment, certains produits continuent à l’utiliser en parallèle à UML. L’adoption généralisée
de la notation UML dépasse le simple effet de mode.
Pourquoi faudra-t-il utiliser UML ?
Tout simplement parce que la majorité des nouveaux projets industriels utilisent la notation
UML. Pour convaincre les récalcitrants, je pourrais citer le nom des entreprises appartenant au
consortium ayant mis en place UML : DEC, HP, IBM, Microsoft, Oracle et Unisys pour parler
des plus connues. Tous les cursus universitaires informatique, qu’ils soient théoriques ou plus
techniques, incluent l’étude d’UML. Je pourrais enfin évoquer le nombre d’ouvrages et d’articles
parus sur le sujet… Cela ne signifie pas qu’UML soit la panacée, mais que cette notation est
devenue incontournable. La dernière version de la spécification UML, sortie en 2006, est la 2.1
(la précédente était la 2.0 en 2003).
Ce succès s’explique par la réussite de la normalisation des concepts objet, qui ont des avantages
indéniables au niveau des applications informatiques. Ses principaux avantages sont la
réutilisabilité de composants logiciels, la facilité de maintenance, de prototypage et d’extension
des applications. Il aura fallu ainsi près de 30 ans (depuis 1966 avec les deux Norvégiens Dahl
et Nygaard et leur langage objet SIMULA) pour que l’approche objet devienne incontournable.
Alors que UML 1.x définit neuf diagrammes : cinq pour les aspects statiques (classes, objets,
cas d’utilisation, composants et déploiement) et quatre pour les aspects dynamiques
(séquence, collaboration, états-transition, activités), UML 2 ajoute ceux d’interaction, de
structure composite et le timing diagram. Ce livre ne s’intéressera qu’à celui convenant à la
conception d’une base de données, à savoir le diagramme de classes, qui fait partie de l’aspect
statique d’UML.