La modélisation des besoins
147
© Groupe Eyrolles
Sinon, il convient d’évaluer la situation sur le long terme. Le choix d’une orientation objet signifie :
◗ que l’on devra passer par une phase d’étude longue pour déterminer les candidats objets et attribuer les classes détectées ;
◗ qu’on constituera une bibliothèque de composants et d’objets qui seront réutilisés pour tous les nouveaux développements ;
◗ que l’on va privilégier un enrichissement des applications sur la base de spécifiques fondés sur des objets.
Cette démarche n’empêche nullement de fonder le système applicatif sur un progiciel intégré construit à partir d’objets.
Figure 3.11 : Le diagramme de décision DBCG/DBOC
Si des développements sont nécessaires, trois cas se présentent :
◗ Premier cas. On choisit des composants de gestion sur le marché, que l’on
mettra en œuvre. La nature de l’orientation objet est pilotée par le choix des
solutions.
◗ Deuxième cas. On souhaite intégrer des composants que l’on aura développés
soi-même, ou qui proviennent de l’héritage applicatif de l’entreprise. S’il s’agit
de séquences de code non récurrentes, elles ne seront utilisées qu’une fois et
une seule. Sinon, on a intérêt à adopter une méthode de conception qui
Autres
développements
nécessaires
Environnement
objet
éditeur
Aucune
Aucune
(déconseillé)
Définir
l’environnement
objet
Sans objet
Solution
intégralement
« progiciels »
Composants
du
marché
Approche objet
pilotée par
éditeurs
Composants
développés
spécifiquement
ou
ou
ou
ou
Éléments de gestion
spécifiques
nécessaires