2016-04-26 3 views
1

Я пытаюсь нарисовать UML класса в себе соответствующей диаграмме диаграммы прецедентов простой системы ведения блог, который отображается следующим образом: enter image description hereрисование UML диаграммы классов для системы ведения блог

Чтобы нарисовать диаграмму классов , должны быть два класса: пользователь и блог. Но мне сложно связать связь между ними, потому что в отношениях между этими двумя классами могут быть две разные множественности. Например, когда пользователь создает блог, диаграмма классов будет выглядеть так: enter image description here

Но с точки зрения просмотра пользователем блога множественность отличается, поскольку определенный блог можно просматривать не только одним пользователем, поэтому класс будет выглядеть так: enter image description here

Как решить эту проблему в домене решений?

ответ

0

В дополнение к ответу Томаса:

  • Один уверен, что является структурным 1 для многих отношения между User и Blog. Но это более неявное знание, чем анализ случайных ситуаций: ваша система ДОЛЖНА отслеживать ссылку Blog и User, которые ее создали, поэтому, чтобы включить его и позже, обновления и удаления.
  • Тем не менее, многие системы ведения блогов также отслеживают Blogs, которые User действительно консультировались (для измерения аудитории, отслеживания истории и т. Д.). Таким образом, ваша система COULD также отслеживает просмотр (но он также может работать без).

enter image description here

Вы могли бы показать навигационную стрелку. Но в вашей системе навигация, безусловно, будет двунаправленной.


Более систематический подход к анализу прецедентов заключается в использовании entity- control-boundary подход, и использовать следующие классы для проектирования:

  • лиц: постоянные данные: Blog и User как указано выше
  • Границы: связь между прецедентом и актерами: CreateOwnBlog и ViewBlog
  • Управление: посреднические занятия между двумя мирами: ViewingSubsystem и AuthoringSubsystem
1

Взаимосвязь между классами не показывает действие, которое выполняется. Это просто показывает, что они связаны.

Create и View различные действия предпринятые User. Create, скорее всего, относится к серверу, который имеет метод create, а также retrieveBlog, поэтому он может быть показан (с которым будет работать представление).

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

+0

Извините за последующий ответ, поскольку я очень занят в последнее время.Я думаю, что связь между классами должна определяться их атрибутами. Например, если класс 'Blog' имеет атрибут« Владелец »для хранения« Пользователь », который его создает, тогда должна существовать ассоциация« Создать ». И если в «Blog» есть другой атрибут коллекции «Посетители» для хранения коллекции «Пользователь», просмотрев ее, то ассоциация «Просмотр» также имеет смысл. – Ivan

+0

Вы не используете ассоциации так, как должны. Они не о поведении. Я могу порекомендовать прочитать блог Geerts об ассоциациях: https://bellekens.com/2011/08/10/uml-best-practice-attribute-or-association/ –

+0

Статья, которую вы дали, не дает мне понять из-за я думаю, что его плохая читаемость, но нам не нужно слишком много обсуждать это и вернуться к теме. В моем понимании до сих пор, должна ли быть определенная ассоциация или нет, действительно зависит от системных требований. Если в моем случае система должна отслеживать «блог», что «представление пользователя» способами, такими как хранение коллекции «Пользователь» (посетителей) в «блоге», то ассоциация просмотра имеет смысл. В противном случае он не должен существовать. – Ivan

Смежные вопросы