Должен ли я ставить актеров в Domain-Model/Class-Diagram?

Question

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

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

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

я первоначально определил Administrator и End-User как концепции в области-модели, и позже как классы в диаграмме классов. В классе-диаграмме, оба класса закончили тем, что несколько методов, как

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

т.д.

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

С уважением,

Answer 2

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