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

ЛИЧНЫЙ КАБИНЕТ 

 

Здравствуйте гость!

 

Логин:

Пароль:

 

Запомнить

 

 

Забыли пароль? Регистрация

Повышение уникальности

Предлагаем нашим посетителям воспользоваться бесплатным программным обеспечением «StudentHelp», которое позволит вам всего за несколько минут, выполнить повышение уникальности любого файла в формате MS Word. После такого повышения уникальности, ваша работа легко пройдете проверку в системах антиплагиат вуз, antiplagiat.ru, etxt.ru или advego.ru. Программа «StudentHelp» работает по уникальной технологии и при повышении уникальности не вставляет в текст скрытых символов, и даже если препод скопирует текст в блокнот – не увидит ни каких отличий от текста в Word файле.

Результат поиска


Наименование:


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

Информация:

Тип работы: контрольная работа. Добавлен: 05.10.2012. Сдан: 2011. Страниц: 12. Уникальность по antiplagiat.ru: < 30%

Описание (план):


 
    Министерство  образования и науки Республики Казахстан 

    Гуманитарно – техническая академия 
 
 
 
 
 
 
 
 

    Контрольная работа 

    По  дисциплине 

    Технология  разработки
    программного  обеспечения 
 
 
 
 
 
 
 
 
 
 

    Выполнила:  

    Проверила:  
 
 
 
 
 
 
 
 

    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 — основной источник информации для выполнения анализа  и проектирования системы. Очень  важно, чтобы содержание спецификации было представлено в полной и конструктивной форме. В общем случае спецификация включает главный поток, подпотоки  и альтернативные потоки поведения. В качестве шаблона спецификации представим описание элемента Use Case «Покупать  авиабилет» для модели информационной системы авиакассы.
    Предусловие: перед началом этого элемента Use Case должен быть выполнен элемент Use Case «Заполнить базу данных авиарейсов».

Главный поток

 
    Этот  элемент Use Case начинается, когда покупатель регистрируется в системе и вводит свой пароль. Система проверяет, правилен ли пароль (Е-1), и предлагает покупателю выбрать одно из действий: СОЗДАТЬ, УДАЛИТЬ, ПРОВЕРИТЬ, ВЫПОЛНИТЬ, ВЫХОД.
1. Если  выбрано действие СОЗДАТЬ, выполняется  подпоток S-1: создать заказ авиабилета.
2. Если  выбрано действие УДАЛИТЬ, выполняется  подпоток S-2: удалить заказ авиабилета.
3. Если  выбрано действие ПРОВЕРИТЬ, выполняется  подпоток S-3: проверить заказ авиабилета.
4. Если  выбрано действие ВЫПОЛНИТЬ, выполняется  подпоток S-4: реализовать заказ авиабилета.
5. Если  выбрано действие ВЫХОД, элемент  Use Case заканчивается.

Подпотоки

 
S-1: создать  заказ авиабилета. Система отображает  диалоговое окно, содержащее поля  для пункта назначения и даты  полета. Покупатель вводит пункт  назначения и дату полета (Е-2). Система отображает параметры  авиарейсов (Е-3). Покупатель выбирает  авиарейс. Система связывает покупателя  с выбранным авиарейсом (Е-4). Возврат  к началу элемента Use Case.
S-2: удалить  заказ авиабилета. Система отображает  параметры заказа. Покупатель подтверждает  решение о ликвидации заказа (Е-5). Система удаляет связь с покупателем  (Е-6). Возврат к началу элемента Use Case.
S-3: проверить  заказ авиабилета. Система выводит  (Е-7) и отображает параметры заказа  авиабилета: номер рейса, пункт  назначения, дата, время, место, цену. Когда покупатель указывает, что  он закончил проверку, выполняется  возврат к началу элемента Use Case.
S-4: реализовать  заказ авиабилета. Система запрашивает  параметры кредитной карты покупателя. Покупатель вводит параметры  своей кредитной карты (Е-8). Возврат  к началу элемента Use Case.

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

 
Е-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 отношением include. В свою очередь, самостоятельный  элемент Use Case с альтернативным потоком  подключается к базовому элементу Use Case отношением extend.

Пример  диаграммы 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. Вставка происходит, если выполняется  условие расширения:
    для расширяющего элемента 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 Состояние
сегмент //начало первого  сегмента 
принять запрос состояния //условие расширения
отобразить  информацию о состоянии счета  
сегмент //вторая точка  расширения
конец сеанса  
    Расширяющий элемент Use Case Снять
сегмент //начало первого  сегмента 
принять запрос снятия //условие расширения 
определить  сумму    
(проверка  снятия) //точка расширения 
сегмент //начало второго  сегмента 
напечатать  снимаемую сумму    
выдать  наличные деньги   
    Расширяющий элемент Use Case Захват карты
сегмент принять список подозрений
проглотить  карту 
конец сеанса
//начало единственного  сегмента  //условие  расширения 
    Включаемый  элемент Use Case Идентификация клиента
получить  имя клиента  include (Проверить  достоверность) 
получить  номер счета клиента 
    //включение 
    Включаемый  элемент 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.
    Обычно  расширения используют:
    для моделирования вариантных частей элементов 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 Возврат  элемента и Создание дневного отчета имеют общую часть — действия, обеспечивающие печать квитанции. Поэтому, как показано на рис. 6, можно выделить абстрактный элемент Use Case Печать. Этот элемент Use Case будет специализироваться на выполнении распечаток.
и т.д.................


Перейти к полному тексту работы


Скачать работу с онлайн повышением уникальности до 90% по antiplagiat.ru, etxt.ru или advego.ru


Смотреть полный текст работы бесплатно


Смотреть похожие работы


* Примечание. Уникальность работы указана на дату публикации, текущее значение может отличаться от указанного.