Живые уведомления Диаграмма классов UML

15

Я пытаюсь внедрить систему живых уведомлений (например, fb, xing, twitter..). Поэтому перед созданием сущностей я создал диаграмму классов UML. Витрина такова:

EDIT: Я думал об этом подходе, и кажется, что это неверно. Позвольте проверить следующий сценарий: Пользователь U добавляет в изображение E E Я комментарий C. Как сохранить это правильно, я имею в виду, что EventNotification имеет только ссылку на событие E, но не на я и C. Поэтому мне нужно будет создать "EventImageNotification", и это будет беспорядок. Было бы более приятным решением просто иметь один класс "Уведомление" и добавить в него поле "метаданные", в котором хранятся ссылки на все связанные поля?

(Я использую OR-Mapper для реализации отношений позже).

[1] Один пользователь может создавать события, например. "Silvester Party 2015". (Один ко многим). Это событие имеет панель мониторинга, на которой пользователи могут подписаться на получение обновлений, когда создатель сообщает что-то в этом событии (ManyToMany).

[2] Когда пользователь публикует что-то на панели мониторинга события, подписчики должны получать уведомление. Поэтому я создал класс EventNotification. Связь между пользователем и EventNotification - это ManyToMany.

[3] Чтобы сохранить его в чистоте, я создал класс AbstractNotification, относящийся к типу Notification. Тип уведомления - это что-то вроде name = "EventPost" и template = "Пользователь пользователь разместил что-то новое на событии __event".

[4] Абстрактный класс NotificationConnector предоставляет поля классу сопоставления между EventNotification и User (UserEventNotification). Я создал их, чтобы облегчить его в будущем, например. Пользователь может создавать книги, которые также запускают события и т.д. Затем мне нужно создать один класс "BookNotification" и один класс "UserBookNotification" для хранения уведомлений для этого нового объекта.

Является ли этот подход хорошим или полностью испорченным? Расскажите, пожалуйста, ваши идеи об этой диаграмме:

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

Изображение 15397

  • 0
    Обновление: сейчас я использую поле метаданных в сочетании с NotificationType, и оно работает для всех видов вложенных уведомлений.
Теги:
entity-relationship
notifications
uml

1 ответ

0

Всего несколько наблюдений:

  • Два абстрактных класса кажутся излишними, поскольку вы используете их только в одном контексте.
  • Соединение has из User должно перейти к UserEndNotification, а не к абстрактному классу (который я рекомендую вообще отказаться).
  • Я бы сделал NotificationType a <<enumeration>>
  • вместо использования отношения owns я бы использовал класс ассоциации между User и Event и добавил свойство isOwner и isSubscriber.
Поделиться
  • 0
    Привет Томас, спасибо за твои мысли. Я буду комментировать ваши очки. [1] Я создал абстрактные классы, потому что в будущем появится больше сущностей, которые будут связаны с абстрагированными классами. [2] Это звучит более логично! [3] Также прочитайте это, но тогда было бы сложнее управлять именами и шаблонами через область администратора? [4] это звучит довольно хорошо, я тоже думал об этом, но не знал, какой будет рекомендуемый / более производительный способ. Обычно у вас может быть несколько отдельных отношений между двумя классами, но я думаю, что оба подхода должны работать.
  • 0
    3) Зависит Есть плюсы и минусы. Просто мысль. 4) Не говорит о производительности. Это оставлено для реализации. Ваше отношение mn уже является классом ассоциации (хотя и простым), который вы, скорее всего, отобразите через таблицу с двумя внешними ключами.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню