Контрольная работа по дисциплине "Технология разработки программного обеспечения "

    Расширяющий элемент Use Case Снять

    Расширяющий элемент Use Case Захват карты

    Включаемый  элемент Use Case Идентификация клиента

    Включаемый  элемент Use Case Проверка счета

    Включаемый  элемент Use Case Проверить достоверность

    Опишем  возможное поведение  модели, задаваемое этой диаграммой.

    Актер Клиент инициирует действия базового элемента Use Case Сеанс банкомата. На первом шаге запускается включаемый элемент Use Case Идентификация клиента. Этот элемент Use Case получает имя клиента и запускает  элемент Use Case Проверить достоверность, в результате чего устанавливается  соединение с базой данных клиентов и получаются параметры клиента.

    Если  к этому моменту исполняется  условие расширения список подозрений, то «срабатывает» расширяющий элемент Use Case Захват карты, карта арестовывается и работа системы прекращается.

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

    Базовый элемент Use Case переходит ко второму  шагу работы — вызывает включаемый элемент Use Case Проверка счета, который  устанавливает соединение с базой  данных счетов и получает состояние  и ограничения счета.

    Управление  опять возвращается к базовому элементу Use Case. Базовый элемент Use Case переходит  к первой точке расширения диалог возможен. В этой точке возможно подключение одного из двух расширяющих  элементов Use Case.

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

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

    В последний раз управление возвращается к базовому элементу Use Case — завершается  сеанс работы банкомата.

Построение  модели требований

 

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

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

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

    Таким образом, внешняя среда машины утилизации имеет вид, представленный на рис. 2.

    

    Рис. 2. Внешняя среда машины утилизации

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

Определение элементов Use Case

 

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

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

    Элемент Use Case — это последовательность взаимодействий в диалоге, выполняемом актером  и системой. Запускается элемент Use Case актером, поэтому удобно выявлять элементы Use Case с помощью актеров.

    Рассматривая  каждого актера, мы решаем, какие  элементы Use Case он может выполнять. Для  этого изучается описание системы (с точки зрения актера) или проводится обсуждение с теми, кто будет действовать  как актер.

    Перейдем  к примеру. Потребитель — первичный актер, поэтому начнем с этой роли. Этот актер должен выполнять возврат утилизируемых элементов. Так формируется элемент Use Case Возврат элемента. Приведем его текстовое описание:

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

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

    Следующий актер — Оператор. Он получает дневной  отчет об элементах, сданных за день. Это образует элемент Use Case Создание дневного отчета. Его описание:

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

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

    Доля подготовки к созданию нового дневного отчета сбрасывается в ноль параметр Общее количество.

    Кроме того, актер Оператор может изменять параметры сдаваемых элементов. Назовем соответствующий элемент Use Case Изменение элемента. Его описание:

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

    После выявления всех элементов диаграмма Use Case для системы принимает вид, показанный на рис. 3.

    

    Рис. 3. Диаграмма Use Case для машины утилизации

    Чаще  всего полные описания элементов Use Case формируются за несколько итераций. На каждом шаге в описание вводятся дополнительные детали. Например, окончательное  описание Возврата элемента может иметь  следующий вид:

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

    Если  тип недопустим, то на панели машины высвечивается «недействительно».

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

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

    Обычно  элемент Use Case задает одну основную и  несколько альтернативных последовательностей  событий.

    Каждый  элемент Use Case выделяет частный аспект функциональных возможностей системы. Поэтому элементы Use Case обеспечивают инкрементную схему анализа функций  системы. Можно независимо разрабатывать  элементы Use Case для разных функциональных областей, а позднее соединить  их вместе (для формирования полной модели требований).

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

Расширение  функциональных возможностей

 

    Для добавления в элемент Use Case новых  действий удобно применять отношение  расширения. С его помощью базовый  элемент Use Case может быть расширен новым  элементом Use Case.

    В нашем примере поведение системы  не определено для случая, когда  сдаваемый элемент застрял. Введем элемент Use Case Элемент Застрял, который  будет расширять базовый элемент Use Case Возврат Элемента (рис. 4).

    

    Рис 4. Расширение элемента Use Case возврат элемента

    Описание  элемента Use Case Элемент застрял может  иметь следующий вид:

    Если  элемент застрял, для вызова Оператора  вырабатывается сигнал тревоги. После  удаления застрявшего элемента Оператор сбрасывает сигнал тревоги. В результате Потребитель может продолжить сдачу  элементов. Величина ИТОГО сохраняет  правильное значение. Цена застрявшего  элемента не засчитывается.

    Таким образом, описание базового элемента остается прежним, простым. Еще один пример приведен на рис. 5.

    Здесь мы видим только один базовый элемент Use Case Сеанс работы. Все остальные  элементы Use Case могут добавляться  как расширения. Базовый элемент Use Case при этом остается почти без  изменений.

    

    Рис. 5. Применение отношения расширения

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

    В расширяющем элементе Use Case указывается  ссылка на то место базового элемента Use Case, куда он будет вставляться (при  прерывании). После выполнения расширяющего элемента Use Case продолжается выполнение базового элемента Use Case.