La modélisation du domaine (Domain Modelling, voir encadré) est une technique très puissante que beaucoup de professionels de l'IT possèdent dans leurs bagages. Malheureusement, quelques problèmes indissociables du Domain Modelling ont suffit ces dernières années à le faire passer de mode, notamment avec l'apparition des cycles Agile. Deux principaux problèmes avec cette approche sont mis en avant : le Domain Modelling nécessite beaucoup trop de temps et il peut donner lieu à des "analyses paralysantes" conduisant à des "pertes de temps". Nous présentons ici une approche qui résout ces problèmes.
Des signaux dans votre domaine vous indiquent souvent qu'il y a probablement un problème et des questions à soulever. Nous nommons ces signaux des "indices préoccupants", ils mettent en avant le fait que nous n'avons probablement pas la compréhension totale des données gérées par notre domaine métier. Cet indice peut vouloir dire que nous sommes en train de passer à côté d'une information importante dans notre modélisation du domaine ou que nous avons modélisé incorrectement une donnée. Se concentrer sur ces indices préoccupants nous conduit à poser les questions nécessaires, ce qui se révèle être un procédé très rapide et efficace. Quand tous ces indices sont résolus ou quand nous décidons que ceux restants sont acceptables, nous nous arrêtons, ce qui évite le phénomène d'analyse paralysante.
Le processus commence avec le produit issu du système qui fournit de la valeur ajoutée à l'utilisateur. Nous n'expliquons pas comment trouver la valeur ajoutée dans cet article (nous parlerons de ce sujet dans un prochain article InfoQ nommé "Une introduction à la modélisation du domaine"). Nous cherchons ensuite les indices préoccupants dans la modélisation issue de ce produit.
Afin d'expliquer les indices préoccupants dans cet article, nous utilisons un exemple fictif inspiré de plusieurs cas réels. Nous avons un DRH qui désire comprendre comment plusieurs développeurs sont rémunérés afin de ne pas faire l'objet de poursuites judiciaires résultant d'inégalités de salaires entre plusieurs groupes démographiques.
Pendant la discussion au ours de laquelle l'équipe essaie de comprendre la demande du directeur, le schéma suivant est défini :
Les meilleurs outils à utiliser pour le Domain Modelling se révèlent être le duo papier et crayon ou feutre et fiches, ou encore whiteboard et marqueur, parce que ces outils mettent l'accent sur l'information à échanger, et non sur son apparence (pour qu'elle paraisse "jolie"). Soit dit en passant, nous avons créé des modèles en utilisant un outil de diagrammes afin de ne pas vous perdre dans notre démarche à cause de notre écriture maladroite. Voici donc une version plus claire de cet exemple:
Plusieurs choses importantes doivent être retenues sur les indices préoccupants et ce qu'ils nous disent à propos de notre modélisation du domaine.
- Un indice préoccupant n'indique pas s'il y a un problème.
- Un indice préoccupant est une signe fort qu'il y a probablement un problème.
- Un indice préoccupant n'est pas aussi fort qu'une règle qui, elle, est toujours correcte.
- Les questions mises en avant par un indicateur préoccupant doivent toujours être exprimées sous la forme "Donnez-moi SVP un exemple de..." plutôt que sous la forme "Dites-moi comment...". Nous sommes en train de rechercher des exemples afin d'explorer les détails du domaine plutôt que des généralisations du domaine qui ont tendance à cacher les détails.
Voici donc les indices préoccupants sans plus de fioritures. Si vous en trouvez d'autres, faites-le nous savoir afin que nous puissions les ajouter.
1 Un item se trouve dans le produit et n'est pas présent dans le modèle.
2 Un item est dans le modèle mais n'est pas présent dans le produit.
3 Deux informations se trouvent au même emplacement.
4 Une entité n'est reliée à aucune autre.
5 Relations de type One-to-One.
6 Relations de type Many-to-Many.
7 Fonctions non définies.
Voici une description plus complète de chaque indice.
1 Un item se trouve dans le produit et n'est pas présent dans le modèle.
Tous les items présents dans les produits doivent être aussi présents dans la modélisation du domaine. Le produit est simplement une vision des données présentes dans le modèle. Chaque information affichée dans le produit doit être un attribut ou une méthode fournie par la modélisation. Dans l'exemple ci-dessus, department, average salary, role, salary, sex et race sont absents de la modélisation du domaine. Afin de supprimer cet indice, il faut les ajouter en tant qu'attributs ou méthodes. Si l'entité appropriée est manquante, l'ajouter.
2 Un item est dans le modèle mais n'est pas présent dans le produit.
Les items présents dans le modèle mais absents du produit sont un exemple de "push" dans le processus d'analyse. L'analyste pense à tort qu'une valeur est nécessaire. Il pousse donc des valeurs dans le modèle. Cela est dangereux car vous aurez peut-être des développements supplémentaires à réaliser pour ajouter et maintenir ces valeurs superflues. Cela reste un indice et la valeur a probablement été ajoutée car l'analyste a pensé qu'elle était utile. Pour résoudre cette situation, il devrait questionner l'utilisateur sur la légitimité de cette information pour lui. Notez qu'il s'agit d'une rupture dans le processus de la part de l'analyste car il doit questionner les utilisateurs et tracer les retours dans un log et non dans le modèle. Un autre projet externe demandant des données à l'application peut être la cause de cet indice ayant fait "glissé" ces valeurs dans le modèle. Ce besoin, externe, supplémentaire devrait juste rester comme tel, et être traité comme une tâche séparée.
Dans Structured Systems Analysis and Design Mehtod (SSADM), cette situation est qualifiée de "Information Sink" : naufrage des données.
3 Deux informations se trouvant au même emplacement.
Stocker deux types de données dans un même emplacement est un pas vers le désordre. Le nom "John Smith" pourrait être enregistré en tant que prénom et nom. C'est un indice préoccuppant malgré tout. Dans certains cas, stocker un nom dans un seul emplacement est adéquat alors que dans d'autres non. La question à se poser est de savoir si l'on désire analyser ou traiter ces deux morceaux de données indépendamment ou non. Dans le cas d'une normalisation, ceci est connu sous le nom de violation de la première forme normale ("First Normal Form" : 1NF). Bien que la 1NF soit par définition une règle de design abstraite, elle peut mener à la découverte concrête que deux éléments différents d'information sont traités comme un seul et unique. En regardant les données réelles sockées, en particulier les noms choisis pour les désigner, il est possible d'identifier les violations de la première forme normale. Par exemple, la donnée nommée "Race" possède "Jedi" comme valeur possible ce qui est de l'ordre des croyances / religions, mais elle possède aussi "IC1" qui une classification ethnique utilisé par la police au Royaume-Uni.
4 Une entité n'est reliée à aucune autre.
Tous les objets métier (business objects) dans le système doivent être connectés. Quand on ne peut pas identifier de relation entre deux business objects, l'utilisateur doit être questionné. "Quel est le type de relation entre ces deux éléments ? Est-ce une relation directe ? Ou via quelque chose d'autre ?"
C'est un indice très efficace. D'expérience, cela permet d'identifier souvent l'absence d'un savoir métier important. Dans les systèmes d'entreprise, il s'agit souvent d'un manque de structure organisationnelle.
5 Relations de type One-to-One.
A chaque fois que l'on rencontre une relation de type One-to-One, il n'y a normalement que deux raisons possibles. Premièrement, la personne possédant le savoir métier a utilisé plus qu'un élément pour désigner la même chose et les deux objets métier ne devraient en fait n'en être qu'un. Deuxièmement, la relation One-to-One devrait en fait être de type One-to-Many mais on ne sait pas pourquoi. Par exemple, une voiture et un chauffeur peuvent être modélisés comme une relation de type One-to-One mais si on regarde de plus près, on se rend compte qu'un chauffeur ne peut conduire qu'une seule voiture à un instant t. Plusieurs chauffeurs peuvent conduire la même voiture à différents moments. La connaissance manquante sur ce sujet était la nature temporelle de la relation.
6 Relations de type Many-to-Many.
Les relations de type Many-to-Many représentent occasionnellement une relation valide. La plupart du temps, elles indiquent qu'il y a un lien manquant dans l'objet métier. En design relationnel, les relations Many-to-Many sont remplacées par une entité de lien. Cette entité est souvent un objet métier qui possède de l'information sur la relation elle-même. Dans l'exemple ci-dessus, un employé peut avoir plusieurs titres de métier à différentes périodes, ou bien il peut avoir plus d'une fois le même titre dans sa carrière. Une fois encore, un indice préoccuppant nous permet de cibler les absences de savoirs potentiels.
7 Fonctions non définies. (information manquante)
Chaque méthode présente dans le modèle devrait être définie. Chaque élément référencé dans la méthode doit se trouver dans le modèle métier. Voici l'exemple sur getAge :
getAge calcule l'âge en années. getAge = (today() – Employee.date of birth) / 365 La date de naissance et une fonction (définition du jour courant) manquent ici pour calculer l'age dans cette implémentation. Elles doivent être ajoutées dans le modèle.
Pour résumer le process :
- Identifier le produit qui donne de la valeur à l'utilisateur
- Si on ne possède pas de modélisation dans le modèle permettant d'obtenir ce produit, la créer.
- Traiter tous les indices préoccuppants jusqu'à ce qu'il n'y en ait plus dans le modèle.
- S'arrêter.
Cette approche devrait être bien plus rapide et beaucoup plus ciblée que celle traditionnelle du Domain Modelling. Vous épaterez vos amis en appliquant le Domain Modelling sans être pris dans des "cycles infinis".
Encadré - Domain Model Une modélisation du domaine est une simplification de certains aspects d'une organisation, qu'il s'agisse de ses produits, ses opérations ou son marché. Le modèle du domaine est spécifique à une organisation et à la manière dont elle fonctionne. Bien que le modèle puisse utiliser des termes standards de l'industrie, il créée un vocabulaire précis pour une organisation choisie et son contexte. Un modèle du domaine doit normalement décrire les informations qui sont précieuses aux personnes de cette activité. Puisque la plupart des systèmes du marché sont concernés en premier lieu par la récupération, le traitement, la délivrance de données, il est de ce fait cohérent que la definition de l'information et son découpage en plusieurs catégories soient d'une grande aide. Typiquement, un modèle du domaine comporte des entités métier avec des données associées et des comportements propres. Les interactions entre entités métier sont aussi définies. Les exemples types de modélisation du domaine contiennent les modèles de relations entre entités traditionnels et les modèles objet.
Encadré - exemple travaillé
Nous commençons avec le rapport voulu par le DRH.
1 Un item se trouve dans le produit et n'est pas présent dans le modèle.
Nous avons des éléments en sortie qui n'existent pas dans le modèle, donc nous les ajoutons.
Remarquons que le salaire moyen est calculé à partir d'autres données, nous l'appelons donc getAverageSalary afin de se rappeler qu'il s'agit d'un attribut calculé.
2 Un item est dans le modèle mais n'est pas présent dans le produit.
Quelqu'un s'emporte dans la modélisation et ajoute l'attribut Birthday à Employee.
On demande au DRH s'il désire avoir Birthday dans le rapport. La réponse est non mais il voudrait avoir "Age".
3 Deux informations se trouvent au même emplacement.
Le nom est représenté comme nom et prénom. Nous demandons au DRH s'il désire séparer les champs afin que les pesonnes avec le même nom de famille soient distingables (les noms de famille peuvent être utilisés pour identifier des groupes culturels). Il ne le désire pas.
4 Une entité n'est reliée à aucune autre.
Toutes les entités dans le modèle doivent être reliées. Nous demandons aux experts métier si les entités sont liées directement aux autres ou via une autre entité. Par exemple, est-ce que l'employé est lié directement au département ou fait-il partie d'une équipe qui se trouve, elle, liée au département.
5 Relations de type One-to-One.
Les relations One-to-One sont souvent des mauvais signes, nous demandons à l'expert quelques précisions sur ces relations. Nous NE demandons PAS ce qu'est une relation entre l'employé et le département car cela ne révèlera que le cas général. Nous demandons plutôt "Pouvez-vous nous donner un exemple d'un employé qui est affilié à plus d'un département ?" et "Pouvez-vous nous donner un exemple d'un département avec plus d'un employé ?". Appliquer cette technique rigoureusement peut créer des questions stupides mais qui se révèlent en vérité très précieuses. "Pouvez-vous me donner un exemple d'un employé avec plus d'un sexe, ou plus qu'une race ?". Les individus identifiés par ces questions devraient malheureusement être ceux les plus sujets au préjudice et à la discrimination.
Nous gardons ces questions en tête jusqu'à ce que nous trouvions un exemple. Il s'agit d'un indicateur de risque que le système pourrait être amené à changer.
6 Relations de type Many-to-Many.
Les relations Many-to-Many peuvent indiquer une absence d'information. Nous demandons à l'expert quel type de données cela pourrait être. Dans notre cas le temps de travail d'un employé est partagé entre deux départements ou plus.
Pour ce qui concerne le role, le sexe et la race, l'expert n'arrive pas à donner d'informations supplémentaires. Donc les indices restent d'actualité et soulignent un risque de changement.
Un site web spécialisé résout le problème des relations Many-to-Many concernant les relations liées au sexe en ayant sept classifications (homme, femme, homme avant opération femme, femme avant opération homme, homme après opération femme, femme après opération homme, androgyne). L'information manquante pourrait être la date à laquelle l'individu a décidé de l'opération, ou quand l'opération a eu lieu, et l'impact que cela a eu sur le salaire (augmentations et bonus).
7 Fonctions non définies. (information manquante)
Nous demandons à l'expert comment calculer getAverageSalary et getAge.
Cela provoque les ajouts de allocation.cost et employee.dateOfBirth dans le modèle.
Il ne reste plus d'indices préoccupants non résolus ou reportés arbitrairement. Nous pouvons donc arrêter notre modélisation du domaine.