Concept: Conception de domaine
Dans ce concept, la notion de domaine est définie comme étant le contexte ou la zone de problème dans laquelle le développement a lieu. Trois aspects sont développés plus en détails : la modélisation de domaine, l'analyse de domaine et l'ingénierie de domaine.
Relations
Description principale

Introduction

Une partie essentielle d'un projet de développement consiste à obtenir une bonne compréhension du contexte ou du domaine ; c'est en effet un élément pertinent pour le logiciel ou le système en cours de développement. Le domaine fait toujours référence au domaine du problème, qui est considéré comme un élément précurseur de la définition du domaine de la solution. La description du domaine peut prendre plusieurs formes. Toutefois, créer un modèle de ce domaine facilite la compréhension, permet aux parties prenantes à avoir la même vue du domaine, fournit la base pour évaluer la portée du domaine de la solution et procure des données d'entrée qui seront utiles pour l'analyse et les tâches de conception futures.

Plusieurs personnes peuvent avoir une conception différente de ce qu'est la modélisation de domaine et le terme "modèle de domaine" est souvent utilisé à tort et à travers : il peut aussi bien décrire les différentes fonctions d'un domaine spécifique, que la banalisation et la variabilité des fonctions d'un domaine ou encore les informations traitées dans un domaine, et ainsi de suite. Le modèle de domaine peut donc aisément être divisé en trois activités principales :

Modélisation de domaine

Un modèle de domaine est un modèle du domaine dans lequel une organisation gère ses affaires. En théorie, le domaine d'une organisation doit donc être le même que celui des autres organisations appartenant au même domaine. Cependant, en pratique, les variations dans la modélisation de domaine sont la conséquence de deux facteurs : le niveau de détail du modèle de domaine et la façon dont le modèle est utilisé dans le contexte de méthodologies particulières. Dans son sens le plus simple, le terme modèle de domaine est utilisé pour faire référence au diagramme de classes créé pour représenter des concepts et leurs relations primaires dans le domaine. En général, cela impliquera les classes avec des attributs et des opérations pour représenter les éléments de domaine conceptuels. Ces modèles peuvent être complétés par des informations informelles, prises en charge par les cas d'utilisation métier de niveau supérieur, etc.

La modélisation de domaine requiert souvent une bonne compréhension des systèmes logiciels existants utilisés dans un domaine. Dans ces instances, la modélisation de domaine est axée sur l'identification et la modélisation des points communs et des différences qui caractérisent les systèmes logiciels dans le domaine, afin de comprendre les aspects du domaine du problème gérés par le logiciel. La modélisation de domaine est utilisée pour définir les systèmes logiciels en procédant de manière systématique à la modélisation des fonctions, des objets, des données et des relations des systèmes logiciels dans le domaine. Cela permet :

  • de comprendre les fonctions des systèmes logiciels utilisés dans le domaine ;
  • de créer un vocabulaire commun enregistrant les différentes compréhensions du domaine par les parties prenantes ;
  • de documenter les systèmes logiciels utilisés, à l'aide de leur fonction primaire et de leurs relations.

Un élément clé résultant de la modélisation de domaine est un dictionnaire de domaine approfondi qui enregistre les éléments utilisés pour décrire les fonctions et les entités dans le modèle de domaine et qui présente leurs objectifs primaires.

Pour plus d'informations, voir aussi le Modèle d'analyse métier.

Analyse de domaine

L'analyse de domaine est le processus qui vise à "identifier, collecter, organiser et représenter les informations pertinentes d'un domaine, selon l'étude de systèmes existants et de leur développement, mais aussi d'après les connaissances acquises auprès d'experts du domaine, les théories sous-jacentes et la technologie émergente dans un domaine"[CMU/SEI-90-TR-21].

L'analyse de domaine doit "délimiter précisément le domaine concerné, prendre en compte les points communs et les différences des systèmes dans le domaine, expliquer les différentes relations entre les différents éléments du domaine et présenter cette explication de manière pratique"[CARDS94].

Il existe de nombreuses façons d'analyser le domaine, selon la forme des modèles de domaine en cours d'analyse et selon les différents objectifs de l'analyse. Par exemple, certaines techniques portent sur l'analyse des similarités et des différences dans les familles de produits. L'analyse de domaine orientée fonction (Feature Oriented Domain Analysis - FODA) a pour objectif d'identifier les différentes caractéristiques visibles des utilisateurs dans une classe de systèmes logiciels connexes. Les autres techniques d'analyse de domaine portent sur des questions et des points de vue particuliers dans un domaine. L'analyse de travail cognitif et de sécurité porte principalement sur le travail effectué par les personnes, sur les décisions qu'ils prennent et sur les stratégies qu'ils utilisent pour prendre en charge les problèmes de sécurité dans un système.

Ingénierie de domaine

L'ingénierie de domaine est une approche permettant d'obtenir une meilleure efficacité et une meilleure réutilisation pour réaliser une famille ou des systèmes similaires. L'ingénierie de domaine couvre toutes les tâches de la construction des éléments principaux d'un logiciel. Ces tâches incluent le fait d'identifier un ou plusieurs domaines, de mettre au point une conception adaptable et de définir les mécanismes permettant de transformer les exigences en systèmes créés à partir des composants réutilisables. Les produits (ou éléments logiciels) de ces tâches sont les modèles de domaine, les modèles de conception, les langages spécifiques au domaine, les générateurs de code et les composants des codes. Cet ensemble de tâches est essentiel pour la création d'une approche systématique pouvant être réutilisée dans une organisation.

Références

[CARDS94] CARDS: Nilson, Roslyn; Kogut, Paul; & Jackelen, George Component Provider's and Tool Developer's Handbook Central Archive for Reusable Defense Software (CARDS). STARS Informal Technical Report STARS-VC-B017/001/00. Unisys Corporation, mars 1994.

[CMU/SEI-90-TR-21]Feasibility Study (CMU/SEI-90-TR-21, ADA 235785).

[EVANS03] E. Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley, 2003.

[FODA] Kang, Kyo C.; Cohen, Sholom G.; Hess, James A.; Novak, William E.; & Peterson, A. Spencer Feature-Oriented Domain Analysis (FODA)

[SEI] Domain Engineering at the Software Engineering Institute: http://www.sei.cmu.edu/domain-engineering/domain_eng.html