Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
AV_teoria.doc
Скачиваний:
0
Добавлен:
01.04.2025
Размер:
89.6 Кб
Скачать

Прецеденты

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

Прецеденты – это текстовые описания.

Прецедент представляет собой мн-во сценариев, объед. вместе некоторой общей целью пользователя.

Сценарий – это последовательность шагов, к-рые описыв. взаимодействие меду пользователем и системой.

Прецеденты бывают типов: - черный ящик; - белый ящик.

Прецедент желательно описывать в виде системы «черный ящик».

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

В основе описание прецедентов состоит из след частей:

  1. осн. исполнитель – это исполнитель, чьи требования удовлетворяются с помощью системы.

К ним относятся люди, внешние устройства и другие программные системы.

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

При поиске действующих лиц интересует не индивидуальная сущность, а сущность с необычнымповедением.

Каждое действующее лицо – это идеализированный пользователь, который использует некоторое подмножество функциональности системы.

  1. заинтересованные лица и их требования (необязательно)

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

  1. предусловие – это список предуслови, которые должны всегда должны выполняться до начала выполнения сценария прецедента.

Предусловие не проверяется при реализации условий прецедента.

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

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

Эти интересы должны выполняться в случае успешного завершения сценария.

  1. Основной положительный сценарий – содержит последовательность действий, которая приводит к успешному завершению сценария и удовлетворяет интересы всех заинтересованных лиц.

В разделе основного сценария описываются 3 вида деятельности:

- взаимодействие между исполнителями

- взаимодействие со стороны системы

- изменение состояния системы

/*пользователь кидает сумму, выбирает.., старт,система проверяет соответствие денг выбранному напитку, готовит кофе, наливает в стакан, сообщает о готовке, дает сдачу*/

  1. Альтернативный поток – указывает сценарий и остальные сценарии, которые приводят к успешному и неудачному результату (сдачу не дали и тд)

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

/*кофейный аппарат должен готовить кофе видов …, типы монет.. */

  1. Список ограничений и типов данных

/*технические ограничения на ввод/вывод данных от заинтересованных лиц*/

  1. Частота использования

  2. Открытые вопросы

Прецедент представляет собой:

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

  2. Это фрагмент внешне наблюдаемых функций;

  3. Ортогональный фрагмент функциональных возможностей, т.е. прецеденты могут при использовании использовать одни и те же объекты, однако выполнение каждого прецеденты независимо от других прецедентов.

  4. Это фрагмент функциональных возможностей, которые инициируются субъектом;

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

Выявление прецедента основываются на анализе требований из документа опис. требов. Или документа концепций и субъекта и их цели относительно системы.

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

Для понимания поведения для каждого прецедента необходимо выделить начальное и конечное события: такое событие инициир. «выпить кофе».

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

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

Данное событие должно осмысленное название.

Для иллюстрации имен прецедентов их зависимость UML исп. диаграмма прецедентов.

Один актер может выполнять несколько прецедентов. У прецедента может быть несколько актеров, которые его выполняют.

Осн. актеры отображаются слева на диаграмме.

Заинтересованные лица – справа.

Между заинтересованными лицами и прецедентами существуют следующие виды зависимости:

- ассоциация

- расширение

- обобщение

- включение.

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

Отношение включения отображается со стереотипом <<include>>

Используется. Когда некоторое поведение вкл. как составляющий компонент послед. привед. осн. прецедента.

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

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

Для каждого альтернативного потока дб расширеннный прецедент.

Отношение обобщения

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

Отношения обобщения может быть применено к актерам. //репка

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]