<<use>> и << состав >> одновременно требуется?

Question

У меня есть следующее UML , содержащее класс School , который ( в моем примере сейчас ) может иметь только один TeacherRoom .

Мой вопрос сейчас заключается в том, какова официальная запись для этого UML , или я должен удалить ассоциацию <<use>> , потому что это очевидно?Очевидно, потому что я сохраняю экземпляр TeacherRoom в моем экземпляре School ?

Я бы определил это так:

Answer 1

Тот факт, что у вас есть атрибут teacherRoom : TeacherRoom в классе School, подразумевает, что School использует TeacherRoom, поэтому зависимость "use" не нужна.

У вас также есть композиционная ассоциация с TeacherRoom. Это означает, что помимо атрибута у вас есть вторая связь с TeacherRoom. Таким образом, вы можете удалить любой из них.

Answer 2

В соответствии с моим пониманием раздела 10.4 спецификации UML 2.5.1, зависимость от использования описывает тот факт, что для данного компонента требуется интерфейс или службы.

Поэтому я бы удалил его, так как это не имеет ничего общегос тем фактом, что «Школа» состоит из «TeacherRoom».

Мое второе замечание - это свойство «teacherRoom», которое имеет более или менее то же значение, что и ваша композиция, поэтому я бы удалил одно из них (Свойствоили композиция).

Answer 3

Так как вы написали

может иметь только одну [опечатку, исправленную мной] TeacherRoom .

вам нужно добавить кратность 1 справа от ассоциации (и, как прокомментировано и ответили, удалить алмаз). Кроме того, вместо атрибута в School следует использовать имя роли teacherRoom в ассоциации и сделать его принадлежащим свойством, добавив точку.

---

Некоторые дополнительные замечания к композиции: Композиция - это (мое личное впечатление) нечто, что вызывает больше путаницы, чем на самом деле помогает строить модели (просто ищите вопросы, задавая вопросы о ее семантике и / или обращайте внимание на ее неправильное использование). Еще хуже совместная агрегация, которая вызывала (и вызывает) еще большую путаницу. Теперь, после многих выпусков, UML 2.5 определяет эту пустую вещь как нечто: ничего. Просто прочитайте коробку на стр. 110. Итак, вернемся к заполненной совокупной совокупности. В основном речь идет о времени жизни объектов, так что есть ли владелец объекта, который отвечает за его время жизни. Когда вы делаете автомобиль, состоящий из его колес, это, очевидно, неправильно, поскольку колесо будет жить, не будучи прикрепленным к автомобилю. Только машина больше не машина. Но это будет выражаться путем присоединения кратности 4 к колесу. Любая машина с не совсем четырьмя колесами больше не является машиной. Нет композиции вообще.

Так где же тогда использовать составную агрегацию? Я имею в виду только 2 приложения. Один для хранения менеджера. Что-то, что было важно в первые дни вычислений, когда такие динозавры, как я, боролись вместе с жесткими дисками размером с буфет, которые имели 20 мегабайт! Только несколько пограничных случаев все еще нуждаются в указании для управления памятью. Вторым случаем будет безопасность. Указание, что что-то должно быть удалено вместе с его родителем. И это все еще в силе. Но тогда это единственное реальное приложение для составной агрегации.