Weaknesses of Use Cases (2)

-Не существует стандартов, определяющих размеры (объемы) сценариев.

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

результаты моделирования и его организационные аспекты.

И наоборот, слишком краткое описание своим результатом будет иметь большое число маленьких сценариев, делая их менее понятными и управляемыми.

Bhuvan Unhelkar Software Engineering with UML CRC Press 2018

Use Case Diagrams (1)

Диаграммы сценариев обеспечивают целостный наглядный обзор требований системы в пространстве проблем.

Fowler (2003) называет их «графической таблицей содержаний» сценариев.

Диаграммы сценариев включают с себя акторов, сценарии, их отношения и

заметки.

Эти диаграммы являются идеальным средством для вовлечения пользователей в

разработку и обеспечения их участия в моделировании требований.

Рисунок 6.1 показывает обозначения, используемые в диаграммах сценариев.

Bhuvan Unhelkar Software Engineering with UML CRC Press 2018

Use Case Diagrams (3)

Актор

Акторы представляют собой роли, которые играются пользователями

системы.

Акторы также представляют интерфейс с другой системой или внешнее по

отношению к системе устройство.

Акторы изображаются схематичными человечками (рисунок 6.1).

Поскольку акторы находятся вне системы, они лишь взаимодействуют с ней, но не является ее элементом.

Bhuvan Unhelkar Software Engineering with UML CRC Press 2018

Use Case Diagrams (4)

Сценарий

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

• Графически сценарий лишь обозначают взаимодействие, но не определяет его

на диаграмме.

Детали взаимодействия содержатся в документации сценария.

Bhuvan Unhelkar Software Engineering with UML CRC Press 2018

Требования: пользователя и системы

Требования пользователя – изложение ожидаемых от системы сервисов и ограничений, в рамках которых система должны действовать,

выраженных обычным языком (м.б. с представлением диаграмм).

Требования системы – более детальное изложение функций, сервисов , ограничений функционирования программной системы.

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

Этот документ может быть частью контракта между разработчиком системы и ее покупателем.

Sommerville, Ian Software engineering / Ian Sommerville. — 9th ed,. Addison-Wesley, 2011

Требования системы: функциональные и нефункциональные

Функциональные требования – представление сервисов, которые должны обеспечивать система, определение реакции системы на отдельные

входные данные, описание поведения системы в определенных ситуациях.

В некоторых случаях функциональные требования могут в явном виде представлять то, что система не должна делать.

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

Sommerville, Ian Software engineering / Ian Sommerville. — 9th ed,. Addison-Wesley, 2011

Требования к функциональным требованиям (1)

Спецификация функциональных требований должна быть полной и согласованной (непротиворечивой).

Полнота означает, что в спецификации определены все сервисы, требуемые пользователем.

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

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

Формирование спецификации функциональных требований для больших

исложных систем чревато ошибками и упущениями.

Sommerville, Ian Software engineering / Ian Sommerville. — 9th ed,. Addison-Wesley, 2011

Вариант использования (сценарий) «Войти в систему» (1)

Краткое описание

Данный вариант использования описывает вход пользователя в систему обработки заказов.

Основной поток событий

Данный вариант использования начинает выполняться, когда пользователь хочет войти в систему обработки заказов.

1. Система запрашивает имя пользователя и пароль.

http://sp.cs.msu.ru/ooap/exerbaks.html 2. Пользователь вводит имя и пароль.

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

Моделирование системы обработки заказов Малышко В.В. http://sp.cs.msu.ru/ooap/exerbaks.html

Вариант использования (сценарий) «Войти в систему» (2)

Альтернативные потоки

3А. Неправильное имя/пароль

1.Система обнаруживает, что комбинация имени и пароля не верна.

2.Система сообщает об ошибке и предлагает пользователю либо заново ввести имя и пароль, либо отказаться от входа в систему.

3.Пользователь сообщает системе свой выбор.

4.В соответствии с выбором пользователя либо выполнение переходит на начало основного потока, либо вариант использования

Предусловия

Отсутствуют.

Постусловия

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

Моделирование системы обработки заказов Малышко В.В. http://sp.cs.msu.ru/ooap/exerbaks.html