Si plusieurs développeurs réalisent l'analyse, ce glossaire est d'une grande aide. C'est un excellent outils pour écrire le cahier des charges (modèle des besoins) en effet les utilisateurs et le client (acheteur) reconnaissent les concepts et ils les utilisent pour décrire ce que doit faire le système (et le service qui les intéressent). Ce modèle des Objets du Domaine est la base de nombreuses approches objets, où il est en suite injecté directement sous forme de classes dans l'application. Ce n'est pas notre approche, en effet, le Modèle des Objets du Domaine ne nous fournis pas une structure robuste et évolutive mais seulement une base pour fabriquer un tel modèle, qu'est pour nous le modèle d'analyse.
Quel degré de détail doit t-on atteindre dans le Modèle des Objets du Domaine ?
1.Noms d'Objets
2.Attributs Logiques
3.Associations Statiques
4.Héritage
5.Associations dynamiques
6.Opérations
Comme notre Objectif principal est de comprendre et non de définir
le système. Le niveau 3 semble en général suffisant.
Il est évidement possible et parfois nécessaire de décrire
avec un niveau supérieur de détail mais on risque en faisant
cela de ne plus pouvoir définir une architecture robuste et maintenable
de notre système. Trop de travail ici risque de bloquer la progression
dans la suite des modélisations. L'expérience montre que
les objets du domaine se
retrouvent souvent comme Entités (cf. vue en trois-tiers, modèle
MVC) dans le modèle d'analyse. Mais il est dangereux de réaliser
une copie trop mécanique. Les informations d'un objet ne sont pas
toujours nécessaires au système.
Le Modèle des Objets du Domaine peut-être utile dans plusieurs tâches :
Pour décrire les services
Dans la définition/construction des I.H.M.
Pour mieux définir le système
Il forme une bonne représentation des Besoins.
Mais le modèle des Cas d'Utilisation reste notre outil principal au cours du développement.