Диаграмма использования - PullRequest
       4

Диаграмма использования

0 голосов
/ 03 октября 2011

Я новичок в UML. У меня есть вопрос. У нас есть пользователь, который может изменить пользовательскую спецификацию (изменить пароль пользователя, предоставить доступ, ...) для диаграммы вариантов использования, какая из этих двух картинок верна: 1001 *

1) enter image description here

2) enter image description here

если номер 1 верен, на какой диаграмме мы должны показать детали? Спасибо

Ответы [ 3 ]

2 голосов
/ 03 октября 2011

Я склонен сказать, что диаграмма # 1 верна, но это зависит от ваших конкретных требований.Учитывая пример использования, я бы предпочел что-то вроде этого:

  1. Actor Admin -> Изменить авторизацию пользователя (соответствует разрешению / запрету доступа)
  2. Actor Администратор -> Изменить пароль пользователя
  3. Актер Администратор -> Изменить данные пользователя (спецификация пользователя)
  4. Актер Конечный пользователь -> Изменить пароль пользователя (вариант # 2)
  5. Актер Конечный пользователь -> Изменить данные пользователя (вариант # 3)

Для подробного описания вариантов использованияв UML-диаграммах у вас есть две опции: диаграмма действий и / или диаграмма последовательности.Тем не менее, я буду осторожен в этом направлении, во время вашего проекта вам придется приложить немало усилий для поддержания этих диаграмм.По моему опыту, как только будут написаны первые строки кода, никто не будет больше смотреть на красивые диаграммы.Практическое правило - формальная спецификация является функцией сложности команды.Если у вас есть глобальная команда разработчиков с разными часовыми поясами, возможно, имеет смысл приложить больше усилий к этому виду спецификации.

Это сработало для меня:

  1. Создать вариант использованияобзор (как графический, как у вас, так и просто текстовый документ)
  2. Примеры использования документа в виде пользовательских историй
  3. Использование диаграмм действий для сложных процессов, возможно, охватывающих более одногопример использования, например, процесс заказа
  4. Создание нескольких диаграмм последовательности для документирования важных технических аспектов вашей системы, таких как авторизация, управление транзакциями, сквозное взаимодействие между всеми различными уровнями

Редактировать: UML предлагает несколько типов диаграмм для документирования и моделирования различных представлений в вашей системе. Диаграмма вариантов использования сама по себе не предназначена для документирования подробных низкоуровневых аспектов вашей системы.Согласно WikiPedia:

Диаграмма вариантов использования: описывает функциональные возможности, предоставляемые системой с точки зрения действующих лиц, их цели представлены в виде вариантов использования и любые зависимости между этими вариантами использования.

1 голос
/ 03 октября 2011

Диаграмма просто для того, чтобы дать вам обзор. Тяжелый вес варианта использования - текстовое описание, которое сопровождает его. Там вы описываете сценарий использования, задействованные субъекты, предварительные и постусловия и фактические шаги варианта использования в последовательности. Взгляните на текстовую спецификацию и обратите внимание на заголовки разделов. Это довольно хороший пример того, как должны быть описаны варианты использования. По сути, вы хотите, чтобы ваши описания были разделены, как в # 2, но для общего представления о «большой» картине может быть полезно также сгруппировать их. Так что у вас есть, например используйте вариант "# 1 Изменить пользовательскую спецификацию", а затем у вас будет "# 1a Изменить пароль пользователя", "# 1b Предоставить доступ" и т. д.

Будьте осторожны с вариантами использования и пользовательскими историями !

  • Варианты использования представлены в виде диаграммы, как вы показали, и описаны в довольно строгом формате. Они предназначены для спецификации определенного действия пользователя и позволяют документировать и назначать функцию на достаточно подробном уровне (с точки зрения пользователя, но иногда и с точки зрения системы).
  • С другой стороны, пользовательские истории происходят из гибкого мира и представляют собой гораздо более упрощенное описание «функции». Важно уточнить, что пользовательские истории не предназначены для спецификации! Они не включают предварительные и последующие условия или подробное описание основных и альтернативных потоков! Они должны быть такими маленькими, чтобы их можно было описать одним предложением.

С пользовательскими историями программист свободен / обязан самостоятельно решать вопросы, например, что делать в случае ошибки и тому подобное. С вариантами использования все это документировано, само сообщение об ошибке и что должно произойти.

0 голосов
/ 06 октября 2011

Первый вариант лучше, вариант использования не должен использоваться для некоторого функционального разложения , это просто варианты использования :). Если действия как «изменить пароль» можно рассматривать как отдельные варианты использования или, скажем, более или менее независимые части других вариантов использования, то вы можете <<include>> их.

...