UML вопросы схемы вариантов использования - PullRequest
Новая
       43

UML вопросы схемы вариантов использования

1 голос
/ 08 января 2012

У меня есть несколько вопросов относительно схемы использования:

  • Если в моей системе есть сценарий использования регистра / входа для гостя, должен ли он быть включен для администратора, пользователя (я просто хочу уточнить, если у меня есть система входа в систему, могу ли я считать, что администратор, пользователь и т. Д. - это люди кто уже вошел в систему, так что я пропускаю их с журналированием)?

  • Если в моей системе есть учащийся-актер, который подписывает контракт на отдельные семинары / курсы, должен ли я (или мне позволено) использовать этот случай для «занятия» после пения для них, и должны ли быть отношения между этими 2

  • Должен ли мой учитель унаследовать от студента актера, поскольку он также может просматривать курсы? (и так по админке?)

  • Правильно ли настроены мои платежи?

enter image description here

Ответы [ 2 ]

1 голос
/ 10 января 2012
  1. Помните, что это роли, а не люди. Администратор может быть гостем, если он ведет себя как догадка, без специальных функций или правил. Однако при входе в систему роль пользователя может измениться, стать администратором. Обратите внимание, что в некотором смысле вы пропускаете аутентифицируемого пользователя, каждый сценарий использования, который требует безопасности, должен включать его, как правило, не расширять.
  2. Только если, например, оно взаимодействует с системой, запускает автозаполнение или каким-либо образом отслеживается. Отношения вообще не нужны, ассоциации могут помочь сообщить что-то неоднозначное, но я не уверен, что будет в этом случае.
  3. Нет, на самом деле тогда роль - это то, что любой пользователь может просматривать курсы после их аутентификации. Вы можете предложить студентам, администраторам и учителям подтипы аутентифицированного или связанного с ним лица и т. Д.
  4. Зависит. Во-первых, вы никогда не платите и не регистрируетесь одновременно, так что с точки зрения пользователя это не работает. В UML есть и другие способы связать это ограничение оплаты курсов. Диаграмма процессов, диаграмма состояний и т. Д. Поскольку платеж - это действительно длительная транзакция, которую сложно определить. Я лично показал бы студенту и внешней платежной системе, взаимодействующей с вариантами использования «оплаты».

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

1 голос
/ 10 января 2012
  1. Если вы хотите, чтобы администратор мог войти в систему, у него был бы вариант использования для этого.Я согласен, что он, скорее всего, не будет регистрироваться, поэтому, может быть, вы хотите разбить регистр / вход в систему на два варианта использования?
  2. Вам не нужно создавать вариант использования "Take Class".Сделайте это, только если пользователь будет взаимодействовать с системой.Я предполагаю, что он не будет "брать" класс с системой, в этом случае это не будет вариант использования системы.
  3. Я думаю, что вы не захотите наследоватьот студента.Прежде всего, с реалистической точки зрения это не имеет смысла.Это будет означать, что учитель - студент.Вы можете извлечь это поведение из другого родительского класса, но это может сделать иерархию слишком большой и запутанной.
  4. Если вы спрашиваете, правильно ли говорить, что «подписаться на курс» включает «оплатить курс», тогдавозможно, лучше использовать расширение.

Еще одно предложение.Черная стрелка (обычно означает «зависимость» в UML) между актерами и сценариями использования, вероятно, должна быть двунаправленной, без стрелки, линия (обычно это называется «ассоциация»). По крайней мере, так говорит стандарт UML..

...