Les Objets du Domaine

 

Quand on travaille sur le Modèle des besoins il est souvent difficile de trouver les taches du système et les limites du système. C'est souvent le cas quand les besoins exprimés sont vagues ou ambigus. Un excellent outil dans ce cas est de construire une vision logique du système en utilisant les objets du domaine. Ces objets sont ceux qui existent effectivement dans l'environnement d'application de notre système, les objets qu'a l'évidence le système doit connaitres.
Ces objets de domaine nous permettent de créer un liste de noms qui nous aidera pour spécifier les services.
A partir de ces objets il est possible de définir les concepts que manipule le système. Le glossaire nous aide a formuler les fonctionnalitées des services. Dans notre exemple nous utilisons généreusement Article, Bouteilles, Canettes et Boites sans les définir.
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 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. chapitre 2) 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 est assez trivial dans notre exemple Figure. 1.6 analyse.MODLe modèle des objets du domaine de l'exemple
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 services reste notre outil principal au cours du développement.