Copyright D. Revuz 1998  Top level Autres Cours  

 Les Objets du Domaine

 Quand on travaille sur le Modèle des besoins il est souvent difficile de trouver les tâches 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 du domaine nous permettent de créer un liste de noms qui nous aidera pour spécifier les cas d'utilisation.
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.

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.

Retour