Автор работы: Пользователь скрыл имя, 24 Ноября 2011 в 12:23, контрольная работа
Элемент Use Case описывает, что должна делать система, но не определяет, как она должна это делать. При моделировании это позволяет отделять внешнее представление системы от ее внутреннего представления.
Поведение элемента Use Case описывается потоком событий. Начальное описание выполняется в текстовой форме, прозрачной для пользователя системы. В потоке событий выделяют:
Работа с элементами Use Case 3
Спецификация элементов Use Case 3
Главный поток 3
Подпотоки 4
Альтернативные потоки 4
Пример диаграммы Use Case 5
Построение модели требований 7
Определение элементов Use Case 8
Расширение функциональных возможностей 10
Уточнение модели требований 11
Выводы 12
Кооперации и паттерны 12
Министерство
образования и науки Республики
Казахстан
Гуманитарно
– техническая академия
Контрольная
работа
По
дисциплине
Технология разработки
программного
обеспечения
Выполнила:
Проверила:
2011 – 2012 уч.год
Содержание:
Работа с элементами Use Case 3
Спецификация элементов Use Case 3
Главный поток 3
Подпотоки 4
Альтернативные потоки 4
Пример диаграммы Use Case 5
Построение модели требований 7
Определение элементов Use Case 8
Расширение функциональных возможностей 10
Уточнение модели требований 11
Выводы 12
Кооперации
и паттерны 12
Элемент Use Case описывает, что должна делать система, но не определяет, как она должна это делать. При моделировании это позволяет отделять внешнее представление системы от ее внутреннего представления.
Поведение элемента Use Case описывается потоком событий. Начальное описание выполняется в текстовой форме, прозрачной для пользователя системы. В потоке событий выделяют:
Для уточнения и формализации потоков событий используют диаграммы последовательности. Обычно одна диаграмма последовательности определяет главный поток в элементе Use Case, а другие диаграммы — потоки исключений.
В общем случае один элемент Use Case описывает набор последовательностей, в котором каждая последовательность представляет возможный поток событий. Каждая последовательность называется сценарием. Сценарий — конкретная последовательность действий, которая иллюстрирует поведение. Сценарии являются для элемента Use Case почти тем же, чем являются экземпляры для класса. Говорят, что сценарий — это экземпляр элемента Use Case.
Спецификация элемента Use Case — основной источник информации для выполнения анализа и проектирования системы. Очень важно, чтобы содержание спецификации было представлено в полной и конструктивной форме. В общем случае спецификация включает главный поток, подпотоки и альтернативные потоки поведения. В качестве шаблона спецификации представим описание элемента Use Case «Покупать авиабилет» для модели информационной системы авиакассы.
Предусловие: перед началом этого элемента Use Case должен быть выполнен элемент Use Case «Заполнить базу данных авиарейсов».
Этот элемент Use Case начинается, когда покупатель регистрируется в системе и вводит свой пароль. Система проверяет, правилен ли пароль (Е-1), и предлагает покупателю выбрать одно из действий: СОЗДАТЬ, УДАЛИТЬ, ПРОВЕРИТЬ, ВЫПОЛНИТЬ, ВЫХОД.
1. Если
выбрано действие СОЗДАТЬ,
2. Если
выбрано действие УДАЛИТЬ,
3. Если
выбрано действие ПРОВЕРИТЬ,
4. Если
выбрано действие ВЫПОЛНИТЬ,
5. Если
выбрано действие ВЫХОД,
S-1: создать заказ авиабилета. Система отображает диалоговое окно, содержащее поля для пункта назначения и даты полета. Покупатель вводит пункт назначения и дату полета (Е-2). Система отображает параметры авиарейсов (Е-3). Покупатель выбирает авиарейс. Система связывает покупателя с выбранным авиарейсом (Е-4). Возврат к началу элемента Use Case.
S-2: удалить
заказ авиабилета. Система отображает
параметры заказа. Покупатель подтверждает
решение о ликвидации заказа (Е-5).
Система удаляет связь с
S-3: проверить
заказ авиабилета. Система выводит
(Е-7) и отображает параметры заказа
авиабилета: номер рейса, пункт
назначения, дата, время, место, цену.
Когда покупатель указывает,
S-4: реализовать
заказ авиабилета. Система запрашивает
параметры кредитной карты
Е-1: введен неправильный ID-номер покупателя. Покупатель может повторить ввод ID-номера или прекратить элемент Use Case.
Е-2: введены неправильные пункт назначения/дата полета. Покупатель может повторить ввод пункта назначения/даты полета или прекратить элемент Use Case.
Е-3: нет подходящих авиарейсов. Покупатель информируется, что в данное время такой полет невозможен. Возврат к началу элемента Use Case.
Е-4: не может быть создана связь между покупателем и авиарейсом. Информация сохраняется, система создаст эту связь позже. Элемент Use Case продолжается.
Е-5: введен неправильный номер заказа. Покупатель может повторить ввод правильного номера заказа или прекратить элемент Use Case.
Е-6: не может быть удалена связь между покупателем и авиарейсом. Информация сохраняется, система будет удалять эту связь позже. Элемент Use Case продолжается.
Е-7: система не может вывести информацию заказа. Возврат к началу элемента Use Case.
Е-8: некорректные параметры кредитной карты. Покупатель может повторить ввод параметров карты или прекратить элемент 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 Снять и Проверить
Рис.
1. Использование включения и расширения
Для
расширяемого (базового) элемента Use Case
эти условия являются внешними, то
есть формируемыми вне его. Иными
словами, элементу Use Case Сеанс банкомата
ничего не известно об условиях запрос
состояния и запрос снятия, а элементам
Use Case Снять и Проверить
Стрелки расширения в диаграмме подписаны. Помимо стереотипа, здесь указаны:
Описание расширяющего элемента Use Case разделено на сегменты, каждый сегмент обслуживает одну точку расширения базового элемента Use Case.
Количество сегментов расширяющего элемента Use Case равно количеству точек расширения базового элемента Use Case. Первый сегмент расширяющего элемента Use Case начинается с условия расширения, условие записывается только один раз, его действие распространяется и на все остальные сегменты.
Поведение базового элемента Use Case задается внутренним потоком событий, вплоть до точки расширения. В точке расширения возможно выполнение расширяющего элемента Use Case, после чего возобновляется работа внутреннего потока.
Спецификации элементов Use Case рассматриваемой диаграммы имеют следующий вид:
Элемент Use Case Сеанс банкомата
include
(Идентификация клиента)
include (Проверка счета) (диалог возможен) напечатать заголовок квитанции (выдача квитанции) конец сеанса |
//включение
//включение //первая
точка расширения //вторая точка расширения |
Расширяющий элемент Use Case Состояние
сегмент | //начало первого сегмента |
принять запрос состояния | //условие расширения |
отобразить информацию о состоянии счета | |
сегмент | //вторая точка расширения |
конец сеанса |