Как правильно смоделировать диаграмму классов MVC в UML?

Question

Я моделирую систему билетов в кино в UML.Мне нужно использовать MVC, поэтому у меня должна быть модель;который контролирует доступные билеты в базе данных, вид;который запрашивает у клиента некоторые данные и контроллер;который контролирует все и является путем между моделью и представлением.Дело в том, что я моделирую эту систему следующим образом:

, но мой учитель сказал, что я не могу использовать отношения Composition между контроллером иВид и модель.Но я не понимаю, почему, потому что, если я инициализировал Модель и Представление внутри Контроллера (чтобы он мог контролировать все), когда Контроллер умрет, оба (Модель и Представление) больше не будут существовать.Мой учитель сказал, что я должен использовать отношения Association .Можете ли вы сказать мне, что такое правильные отношения и почему?

Answer 1

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

Я бы также отметил в вашем примере модели класса UML, что термины Модель , Представление и Contoller - это конструкции решения в шаблоне проектирования , а не конкретные типы, которые вы должны иметь в своем проекте или реализации.«Модель» в вашем сценарии, вероятно, на самом деле является бизнес-сущностью Ticket , а также, вероятно, группой других сущностей.«Вид» - это, вероятно, «TicketDetailsView» или «ListTicketsView», а «Controller» будет «TicketController».В исходном шаблоне MVC, который был встроен в SmallTalk, представление считывало модель напрямую, и контроллер манипулировал моделью, в то время как в настоящее время существует много вариантов шаблона MVC, в которых ассоциации не совсем совпадают (MVP, MVVM, MVPC,Контроллер страницы и т. Д.).

Для справки я настоятельно рекомендую прочитать Фаулера (https://martinfowler.com/eaaDev/uiArchs.html).

Answer 2

Спецификации UML на стр.110 говорит:

составной - Указывает, что свойство агрегируется составным образом, т. Е. Составной объект несет ответственность за существование и хранение составных объектов (см. Определение частей в 11.2.3).

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

Таким образом, становится ясно, что контроллер не может составлять Model, потому что это то, что постоянно хранит данные.Композиция будет означать: если умрут контроллеры, модель тоже умрет.

Об используемой вами общей агрегации (то же поле на стр. 110):

shared - Указывает, чтоСвойство имеет общую семантику агрегации.Точная семантика совместной агрегации зависит от области приложения и моделирующего устройства.

Поэтому вам нужно указать, что вы на самом деле имеете в виду, когда используете его.Или (еще лучше) просто оставьте этот алмаз подальше!