В теме 4 ответа, и 5 участников, последнее обновление сделано пользователем 
Николай Киреев 13 г, 9 мес. назад.
Показано 4 ответа - от 1 до 4 (всего 4)
-
Сообщения
-
Пользователем нашей Системы может выступать не только оператор, который кликает по контролам визуального интерфейса, а, например, другая система, которая использует ряд функций нашей. В чём состоит отличие в описании таких прецедентов?Я тоже считаю, что кардинальных отличий как таковых тут нет.
На самом деле вопрос хороший, потому что я так и смог получить единого мнения, стоит ли такого рода взаимодействия выносить в юз кейсы. Если мы возьмем определение юз кейса типа "description of a system’s behavior as it responds to a request that originates from outside of that system", то несомненно интерфейсные взаимодействия между системами есть юз кейсы. Но с другой стороны, если показать заказчику модель, захламленную такого рода взаимодействиями, то он может впасть в ступор, ведь многие люди, знакомые c UML на неглубоком уровне, представляют юз кейс как "что человек может получить от системы".
Поэтому, я бы сначала ответил на вопрос, а стоит ли выносить данные взаимодействия в юз кейсы. А насчет шагов — тут я полностью согласен с Юрием. Вот еще дополнительная инфа по сабжу — http://www.evanetics.com/Articles/ar_usecases/uc_systemactor.htm.Лично для меня различий между актерами-людьми и актерами-внешними системами вообще нет (http://en.wikipedia.org/wiki/Actor_%28UML%29). Так уж исторически сложилось
Среди аналитиков, на сколько я знаю, по данному вопросу единого мнения тоже нет. Так или иначе, и те и другие актеры(человеки и внешние системы) оказывают воздействие на систему, побуждая ее на какую-то ответную реакцию.
Поэтому в большинстве случаев я спокойно описываю взаимодействие между двумя системами таким же образом, как и взаимодействие между пользователем и системой. Т.е. использую тот же самый шаблон описания вариантов использования.
Однако, вариант использования системы инициируемый другой системой, если его описывать только при помощи стандартного шаблона будет недостаточно нагляден и понятен, на мой взгляд.
Почему? Просто в своих описаниях "человеческих" вариантов использования я постоянно делаю ссылки на соответствующие скриншоты и поля.
Зачастую же описываемый "системный" вариант использования гораздо более навороченный. К примеру, при обмене XML сообщениями в системе должен быть реализован сложный алгоритм проверки, со сверкой контрольных сумм и т.д. Поэтому я, как правило, дополняю стандартный шаблон описания варианта использования одной или несколькими диаграммами (зависит от сложности). И, чаще всего, это sequence диаграмма. Здорово помогает сделать "системные" варианты использования более наглядными ;)Актерами, т.е. некими внешними по отношению к разрабатываемой системе пользователями, взаимодействующими с системой (посредством посылки/приема сообщения), могут быть: физические лица, взаимодействующие с системой посредством GUI; внешние системы, взаимодействующие посредством линий связи и уникального интерфейса, а также особый актер — время (системный таймер), который по смыслу аналогичен внешней системе. Взаимодействие всех этих трех типов актеров с ситемой и описывает Use Case, никаких System Case в языке UML нет и никогда не было.
Отличаются "человеческие Use Case" от "системных Use Case" только в подробном описании потоков событий (сценарий). При подробных описаниях "человеческих Use Case" необходимо обязательно использовать набросок экранных форм и обязательно предусматривать потоки событий, связанных с ошибками (включая намеренные) физического лица, в описаниях потоков событий для "системных Use Case" экранные формы не требуются и ошибочные потоки, обычно (за исключением специфических случаев), не предусматриваются. Отличий на самих диаграммах вариантов использования между актерами-физическими лицами и актерами-внешними системами нет.
Показано 4 ответа - от 1 до 4 (всего 4)
Вы должны авторизироваться для ответа в этой теме.
