Должен ли я поместить актеров в доменную модель / диаграмму классов?

Question

При проектировании как доменной модели, так и диаграмм классов у меня возникают некоторые затруднения с пониманием того, что в них включать.

Я приведу пример того, что я имею в виду:

Я делаю программу планировщика отпусков, которая имеет Administrator и End-Users. Administrator делает пару вещей, таких как регистрация End-Users в программе, изменение их привилегий и т. Д. End-User может выбирать дни отпуска и т. Д.

Сначала я определил Administrator и End-User как понятия в доменной модели, а позже как классы в диаграмме классов. На диаграмме классов оба класса получили пару методов, таких как

Administrator.RegisterNewUser();
Administrator.UnregisterUser(int id);

и т.д.

Только через некоторое время я понял, что на самом деле и Administrator, и End-User являются актерами, и, возможно, я совершенно неправильно понял этот дизайн. Вместо того, чтобы заполнять классы Administrator и End-User методами для выполнения того, что запрашивает мой Use-Cases, я мог бы определить другие классы из домена для их выполнения и иметь контроллеры для обработки Use-Cases (на самом деле, я решил сделать один для каждого Используйте-Case). Например, я мог бы иметь UserDatabase.RegisterNewUser() и UserDatabase.UnregisterUser(int id); вместо этих методов в классе Administrator.

Идея состоит в том, чтобы попытаться представить весь планировщик отпуска как «закрытую программу», которая имеет набор функций и не беспокоится о таких вещах, как аутентификация, которая должна быть внутренней / защищенной, будучи единственные публичные вещи, которые я позволил бы увидеть внешнему миру, это его контролеры.

Это правильный подход? Или я все понял неправильно? Это вообще плохая идея, чтобы положить актеров в доменной модели / диаграммы классов? Каковы хорошие правила для этого?

Мой лектор следит за Применением UML и шаблонов , что я нахожу ужасным, поэтому я хотел бы знать, где я мог бы найти больше информации об этой описанной ситуации с актерскими моделями.

Я все еще немного озадачен всем этим, поскольку этот новый подход радикально отличается от всего, что я делал раньше.

Answer 1

Я бы не сказал, что ваш дизайн, как вы предполагаете, совершенно неправильный, на самом деле Администратор и Конечный пользователь являются допустимыми объектами домена, которые должны быть каким-то образом представлены в диаграммах классов. То, что вы идентифицируете эти две сущности как актеров, не означает, что они должны быть исключены из домена, помните, что ваш домен - это ваша область действия или «соответствующий контекст», то есть набор полезных объектов, которые играют важную роль в вашем решение.

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

• Отпуск
• Местоположение
• Турагент
• Расписание
• Пользователь
• Бронирование
• Служба бронирования (Это может быть интерфейс для доступа к материалам бронирования каникул)

Затем попытайтесь установить отношения между этими объектами, если вы не можете найти никаких отношений, которые означают, что вы не выбираете правильные объекты, если они являются частью одной и той же проблемной области, то они должны быть как-то связаны.

Через некоторое время вы обнаружите, что отсутствуют объекты, постараетесь как можно больше инкапсулировать и представить правильные абстракции, в этом вам могут помочь шаблоны проектирования.

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

Я знаю, что у вас в голове должно быть много теории, так что начинайте без страха, я сам много раз успешно использовал этот подход на работе.

Наконец получите копию UML Distilled

С уважением,

Answer 2

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