Quelle est la différence entre un diagramme de classes de domaine et un diagramme de classes de conception?
Quelqu'un peut-il expliquer brièvement la différence entre un diagramme de classes de domaine et un diagramme de classes de conception?
J'ai trouvé une explication sur réponses Yahoo , mais je trouve cela assez déroutant.
Un modèle de domaine est appelé modèle conceptuel dans la modélisation de base de données, tandis qu'un modèle de conception est appelé modèle logique .
Ces distinctions sont également utilisées dans le développement axé sur les modèles, où nous avons une succession de trois types de modèles:
- (indépendant de la solution) modèles de domaine résultant de l'ingénierie du domaine/des exigences dans l'analyse du système, ou la phase de démarrage, de un projet de développement
- (indépendant de la plate-forme) modèles de conception résultant des activités de conception du système dans la phase d'élaboration
- (spécifique à la plate-forme) modèles d'implémentation, qui sont dérivés d'un modèle de conception
Alors que la modélisation système inclut à la fois la modélisation des informations et des processus, vous semblez ne vous préoccuper que de la modélisation des informations. Ici, nous pouvons utiliser les termes "diagramme de classe de domaine" et "diagramme de classe de conception" pour le modèle d'information conceptuel et le modèle de conception d'information réalisés sous la forme de diagrammes de classe UML.
[Les explications/diagrammes suivants ont été ajoutés plus tard, en septembre 2016 et mars 2019]
Les relations un à plusieurs entre les modèles conceptuels et les modèles de conception, et entre les modèles de conception et les modèles d'implémentation sont illustrées dans la figure suivante:
En considérant la modélisation des informations/classes/données, nous obtenons l'image suivante:
À titre d'exemple qui illustre le fonctionnement de la chaîne de dérivation du concept via la conception à la mise en œuvre, considérons le modèle suivant de concept/classe de personnes/personnes:
Les modèles de domaine sont des descriptions indépendantes de la solution d'un domaine problématique produites dans la phase d'analyse d'un projet d'ingénierie logicielle. Le terme "modèle conceptuel" est souvent utilisé comme synonyme de "modèle de domaine". Un modèle de domaine peut inclure à la fois des descriptions de la structure d'état du domaine (dans les modèles d'informations conceptuelles) et des descriptions de ses processus (dans les modèles de processus conceptuels). Ils sont indépendants de la solution ou "indépendants du calcul", en ce sens qu’ils ne sont pas concernés par les choix de conception de système ou par d’autres problèmes de calcul. Ils se concentrent plutôt sur la perspective et la langue des experts en la matière pour le domaine considéré.
Dans la phase de conception, un modèle de conception indépendant de la plate-forme, en tant que solution de calcul général au problème d'ingénierie logicielle donné, est d'abord développé sur la base du modèle de domaine. Le même modèle de domaine peut potentiellement être utilisé pour produire un certain nombre (même radicalement) de modèles de conception différents représentant différents choix de conception. Ensuite, en prenant en considération un certain nombre de problèmes de mise en œuvre allant des styles architecturaux, des critères de qualité non fonctionnels à maximiser (par exemple, les performances, l'adaptabilité) et des plates-formes technologiques cibles, un ou plusieurs modèles de mise en œuvre spécifiques à la plate-forme sont dérivés du modèle de conception.
Voir aussi http://web-engineering.info/book/WebApp1/ch05s03.html
Si vous vous concentrez sur le diagramme lui-même, il y a deux grandes différences entre les diagrammes sur le modèle de domaine et les diagrammes sur le modèle de conception: (Au moins, c'est ce que le livre Larman Application d'UML et de modèles dit)
Dans les diagrammes UML qui représentent le modèle de domaine, vous ne pouvez pas utiliser de flèches. Toutes les classes sont liées entre elles par une ligne, ce qui signifie "relation", et vous devez utiliser des annotations de texte sur les lignes pour illustrer de quelle relation il s'agit exactement. Dans les modèles de conception, vous devez utiliser des flèches, tous types de flèches: association, héritage ... etc
Dans le modèle de conception, vous devez spécifier le type de propriétés et de méthodes, etc., tandis que dans le modèle de domaine, vous n'avez qu'à les écrire sans rien de plus (comme dans le monde réel). Par exemple,
value: intdans le modèle de conception sera écrit commevaluedans le modèle de domaine.
Référence: Application d'UML et de modèles 3e édition Chapitre 9 et 16.
UML n'a PAS de tels diagrammes
Enterprise Architect a un modèle de domaine - regardez wiki .
Quant au "diagramme de conception de classe", il n'est tout simplement pas connu ni par EA, ni par VP UML, ni par UML lui-même. Je pense que le schéma de classe habituel de l'UML est destiné.