Агрегация или состав или простая ассоциация?
Есть один пример объяснения ассоциаций в UML.
Человек работает на компанию; У компании есть несколько офисов.
Но я не могу понять отношения между людьми, компаниями и офисными классами. Мое понимание таково:
- Компания состоит из множества людей в качестве сотрудников, но эти классы существуют независимо, так что это простая связь с множественностью 0..* в конце класса Person
- У компании есть много офисов, и эти офисы не будут существовать, если не будет компании, которая является составной, имея Компанию в качестве родительского класса и множественность 0..* на конце класса Филиала.
Но я не уверен во втором пункте. Пожалуйста, поправьте меня, если я ошибаюсь.
Спасибо.
2 ответа
Зачем вообще использовать композицию или агрегацию в этой ситуации? Спецификация UML оставляет значение агрегирования для разработчика моделей. Что вы хотите, чтобы это значило для вашей аудитории? И значение композиции, вероятно, слишком сильно для этой ситуации. Таким образом, зачем использовать это здесь? Я рекомендую вам использовать простую ассоциацию.
На вашем месте я бы остался честнее в проблемной области. В мире, который я знаю, офисы не перестают существовать, когда компания выходит из бизнеса. Скорее, Компания занимает некоторое количество офисов в течение некоторого ограниченного периода времени. Если Компания выходит из бизнеса, Офисы продаются или сдаются в аренду другой Компании. Офисы не сгорели дотла.
Если вы не соответствуете проблемному домену в приложении, то используемые вами ярлыки станут недействительными, когда клиент "изменит требования" для этого приложения. Проблемная область практически не меняется, только ярлыки, которые вы можете использовать. Если вы выберете ярлыки для удовлетворения требований таким образом, чтобы они не совпадали с проблемной областью, настройка приложения обходится дорого. Ваш клиент становится несчастным, и вы работаете сверхурочно. Спасите себя и всех от неприятностей!
Хотя ответ Джима верен, я хочу добавить дополнительную информацию. Существует два основных способа агрегирования
- Управление памятью
- Управление базой данных
В первом случае он дает подсказку, как долго будут жить объекты. Это напрямую связано с использованием памяти. Если целевой язык - тот, который (как большинство современных языков) использует сборщик мусора, вы можете просто проигнорировать эту информацию модели.
Во втором случае это только частично вопрос памяти. Составное агрегирование в базе данных указывает, что агрегированные элементы необходимо удалить вместе с агрегирующим элементом. Это не столько память, сколько проблема безопасности. Так что здесь вы должны подумать дважды.
Однако общая агрегация имеет очень эзотерическое значение во всех случаях.