Доменные модели в UML?

Question

Я прочитал о доменной модели и ее важности, и у меня есть следующие сомнения:

• Какие проблемы можно решить с помощью моделей доменов? другими словами, для каждой проблемы я должен построить модель предметной области?

• Насколько я знаю, модели предметной области представлены с использованием диаграмм классов. Разницы между диаграммой классов и моделью предметной области нет?

• Я также хотел бы понять, каким образом словарный запас связан с моделью предметной области?

Answer 1

Какие проблемы можно решить с помощью моделей доменов?

Практически любая проблема, для которой вы хотите / нужно предоставить программное решение, поддается моделированию. На самом деле: как бы вы это ни делали, вы должны каким-то образом "смоделировать" свою проблемную область, форму или форму. Если вы как-то не фиксируете правила и политики проблемы в программном обеспечении, то вряд ли конечная система будет соответствовать запланированным требованиям.

другими словами, для каждой проблемы я должен построить модель предметной области?

Это зависит от того, что вы подразумеваете под "построить модель предметной области". Смотри выше и ниже...

Насколько я знаю, модели предметной области представлены с использованием диаграмм классов. Разницы между диаграммой классов и моделью предметной области нет?

Диаграммы классов являются одним из способов моделирования домена. На самом деле, это один из способов моделирования части домена. Основное преимущество диаграммы классов состоит в том, что она четко и ясно раскрывает отношения в проблемном пространстве. Существует мнение, что семантика предметной области возникает главным образом через отношения между понятиями (классами) - в большей степени, чем сами классы. Если вы согласитесь с этим мнением, то вполне возможно / вероятно, что вы найдете диаграмму классов полезной.

Обратите внимание, что диаграммы классов содержат только структурные элементы домена: классы, атрибуты и отношения. CD не фиксирует поведение. Модель предметной области нуждается как в структуре, так и в поведении, если она предназначена для моделирования проблемного пространства любым полезным способом. Поэтому вам нужно дополнить диаграмму классов некоторым поведенческим описанием; например, модели состояния и / или действия.

Есть и другие способы моделирования доменов. Это может быть набор классов java / C#. Основным недостатком такого подхода является снижение внимания к отношениям. В отличие от диаграмм классов, ОО-языки не предоставляют отношений в качестве конструкций первого класса. Преимущество состоит в том, что языковые среды программирования (редакторы / компиляторы / библиотеки / языковые среды выполнения) обеспечивают гораздо лучшую поддержку для определения поведенческих аспектов домена, чем большинство инструментов моделирования.

В более общем смысле нет правила, согласно которому модель предметной области должна следовать парадигме ОО. Это может быть набор функций и типов в Haskell или OCAML. Или это могут быть некоторые дифференциальные уравнения или другие математические конструкции.

Ключевым моментом является то, что модель - как бы она ни была выражена - предоставляет описание проблемного пространства. Полезно, чтобы это описание не было полным - оно будет охватывать только подмножество свойств в проблемном пространстве, относящихся к системным требованиям. Однако, чтобы быть полезным, это должно быть правильно - концепции и поведение, которые отражены, должны точно отражать моделируемый мир.

Я также хотел бы понять, каким образом словарный запас связан с моделью предметной области?

Вы можете представить модель предметной области как способ создания формализованного и высоко структурированного словаря. На самом деле, он также фиксирует некоторую грамматику; например, в нем говорится, что участниками отношения "владение" должны быть собака и человек; не две собаки или человек и ложка.

Это то, что Эрик Эванс называет "вездесущим языком" в дизайне, управляемом доменом. Это означает, что терминология, используемая в модели, должна точно отражать терминологию моделируемой проблемы. Так что, если эксперты в области реального мира используют слова "Персона" и "Собака", модель не должна использовать "Homo Sapien" и "Canine". Смысл прост: если разработчики (разработчики моделей) используют те же термины, что и эксперты в предметной области, вероятность ошибочной интерпретации значительно ниже. Это также приводит к более продуктивным и приятным разговорам, поскольку все используют знакомые слова с общим смыслом.

Резюме

• Модель предметной области - это абстракция. Он представляет собой подмножество понятий, правил и политик, присущих реальной проблеме, которую решает система.
• Диаграмма классов является одним из способов представления структурных аспектов модели предметной области. Он не отражает динамические аспекты. Это одинаково важно.
• Есть и другие способы моделирования домена. Они не ограничены объектно-ориентированной парадигмой.
• Модель предметной области должна представлять собой структурированный словарь для проблемного пространства. Следует принять терминологию, используемую экспертами в этой области.

НТН.