Как смоделировать агрегат, не являющийся членом в диаграмме классов UML

Question

На приведенной ниже UML-диаграмме Учетная запись содержит совокупность заказов.Основываясь на большинстве онлайн-ресурсов, это, как правило, означает, что класс Account имеет что-то похожее на List в качестве экземпляра.

Но на самом деле, для реального веб-приложения с постоянным хранилищем обычно не то, что класс Account.было бы.Он не будет иметь список заказов в качестве экземпляра.Вместо этого некоторый другой класс контроллера просто запросит хранилище данных, запрашивая все Заказы, принадлежащие Учетной записи.Таким образом, на диаграмме классов UML для такого приложения это по-прежнему правильный способ представления отношений?Мощность и, возможно, концепция агрегирования выглядят правильно с точки зрения сущности базы данных.Только то, что ромб не имеет смысла с точки зрения Класса.

Или он должен показать DataStore / DataManager с методом getOrdersForAccount () и связать его с классом Account и классом Orders через отношение зависимости (пунктирная линия со стрелкой)?

Answer 1

Это зависит от того, что вы хотите представить.

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

Что вам также может понадобиться, это предоставить представление о том, как ОО-код реализован физически .Это будет дополнительная диаграмма классов, которая более точно показывает детали реализации.На этой диаграмме у вас будет гораздо больше вариантов дизайна - использовать коллекцию или нет для заказов (например, список или какой-либо другой класс типа коллекции), каковы ваши шаблоны доступа к данным (адаптеры, менеджеры,ОРМ и т. Д.).На этом уровне вы, скорее всего, потеряете сильную агрегированную нотацию, поскольку на этом уровне мы говорим о классах, ссылающихся друг на друга, которые проще всего обозначать с помощью базовых ассоциаций.Возможно, вы захотите использовать стрелки и / или точечные обозначения, чтобы указать конечное владение и ссылочные направления, чтобы было более понятно, каковы отношения между классами.

Итак, я думаю, что ваш вопрос - классический вопрос об уровняхабстракция в моделях и анализ против дизайна.Спасибо за вопрос!

Answer 2

Это зависит от того, насколько глубоко вы хотите углубиться в UML-дизайн.

Если вы нацелены на генерацию кода из UML, то вам, вероятно, нужно добавить класс, который вы упомянули.Это будет выглядеть как шаблон реестра: Диаграмма UML

• Вы можете добавить абстракцию, чтобы вы могли изменить реализацию вашего DataManager (если ваш DataManager является сторонним, топросто вызовите API из DataManagerImplementation).

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

Пример C ++:

DataManagerImplementation *db = new DataManagerImplementation();
// Dependency injection
Account *acc = new Account(db);

Затем в классе «Account»:

Account::Account(DataManager *db)
{
  // Fetch list at creation
  // Here 'orders' could be a member
  m_db = db;
  vector<Order*> *orders = m_db->GetOrders(this);
}

PS: я также рекомендую поставить стрелку (направление) на ассоциацию / агрегацию, в противном случае это означает, что ассоциация является двунаправленной, и поэтому учетная запись имеет указатель на список заказов, и каждый заказ также имеетуказатель на учетную запись, и я не уверен, что это необходимо.

Для редактирования PlantUML: http://www.plantuml.com/plantuml/png/SoWkIImgAStDuN99B4dqJSnBJ4yjyimjo4dDJSqhIIp9pCzJqDMjiLFmBqf9BK9ImuKk05Hcfw2afGHHYIbjfL2McboINsG3bj6oKz1oJoq1iuir79EJyqlpIZIve0m5a566IfYMEgJcfG0T2m00

Answer 3

Агрегирование просто означает: «если вы удаляете учетную запись, вам также необходимо удалить заказы».

Я также рекомендую просто оставить агрегацию (в большинстве случаев), поскольку она добавляет лишь небольшую дополнительную семантику в вашу модель.В этом случае кажется очевидным удалить заказ при удалении аккаунта.Единственное, что здесь добавлено - это (как в большинстве случаев) некоторая путаница или бесполезные дискуссии о ценности этого алмаза.

Если у вас есть домен, где используется заполненный алмаз, это должно быть задокументировано вправила моделирования.При использовании общего агрегирования документация является даже обязательной, поскольку в спецификациях нет семантики как таковой (см. Вставку на стр. 110 в UML 2.5).