close

Вход

Забыли?

вход по аккаунту

?

Lab 1 UML

код для вставкиСкачать
Лабораторная работа 1
Определение требований к системе при помощи
Use Case Diagram
Цель работы: освоить элементы языка UML и соответствующие инструменты Rational Rose для составления концептуальной модели проектируемой системы, содержащей перечень исполнителей, взаимодействующих с системой, описание её функций в форме диаграмм, позволяющих формально специфицировать сценарии поведения и моделировать требования к системе.
Контрольные вопросы
1.Каково назначение диаграммы Use Case?
2.Для чего введено понятие прецедента, т.е. варианта использования?
3.Что означает термин "включение прецедента"?
4.Что означает термин "расширение прецедента"?
5. Можно ли сказать, что прецедент - это сценарий?
6.В чём преимущества визуализации прецедентов?
7.Что понимается под действующим лицом системы?
8.Чем отличается подход, основанный на вариантах использования, от метода функциональной декомпозиции задачи?
Методические указания
Основное назначение диаграмм Use Case - определение требований заказчика к будущему программному приложению, т.е. построение модели требований. В качестве примера простого для понимания рассмотрим разработку программного обеспечения для машины утилизации, которая автоматизирует приём использованной тары в виде бутылок, банок, ящиков. Выбор актеров. В начале, как правило, определяют актеров. В первую очередь выделяют первичных актеров, использующих проектируемую систему по прямому назначению. Каждый из первичных актеров участвует в выполнении одной или нескольких главных задач системы. В нашем примере первичным актером является Клиент, который кладет в машину сдаваемую тару и получает квитанцию от машины. Кроме первичных, существуют и вторичные актеры. Они наблюдают и обслуживают систему. Вторичные актеры существуют только для того, чтобы первичные актёры могли использовать систему. В данном примере вторичным актёром является Оператор, который обслуживает машину и получает дневные отчёты о её работе. Внешняя среда машины утилизации имеет вид (рис.1.)
КлиентОператор
Рис. 1. Внешняя среда машины утилизации тары
Деление актёров на первичных и вторичных облегчает выбор системной архитектуры в терминах основного функционального назначения. Системную структуру определяют в основном первичные актёры. Именно от них в систему приходят главные изменения. Поэтому полное выделение первичных актёров гарантирует, что архитектура системы будет построена на большинство важных пользователей.
Каждое действующее лицо имеет подробные спецификации. В окне спецификации действующего лица можно определить его имя, стереотип, количество экземпляров (множественность) и другие детали. Открыть окно спецификации действующего лица можно следующим образом: 1) щелкните правой кнопкой мыши на действующем лице в диаграмме вариантов использования или браузере;
2) в открывшемся меню выберите пункт Open Specification. Появится окно спецификации для действующего лица (актёра).
Каждому актёру должно быть дано уникальное имя. Для актёров, как правило, назначается только один стереотип Actor. Можно ввести текстовое описание для актёра в главном окне документации, предварительно выделив действующее лицо в браузере, или в области Documentation окна спецификации.
В среде Rose можно указать количество экземпляров конкретного актёра, которое будет использоваться. Чтобы зафиксировать этот факт, можно использовать поле Cardinality (множественность) на вкладке Detail в окне спецификации актёра.
С действующим лицом можно связать файл или Web - адрес. Это делается на вкладке Files окна спецификации актёра. Связываемые с актёром файлы или Web - страницы должны содержать документы, касающиеся этого действующего лица, например диаграмму потока работ, иллюстрирующую задачи действующего лица и процесс, в котором он участвует. Если действующим лицом является другая система, то с ним целесообразно связать относящуюся к ней спецификацию и документацию. Все связываемые с действующим лицом и ссылки появляются в браузере под именем этого действующего лица. Двойной щелчок мыши на файле или ссылки в браузере приводит к запуску соответствующего приложения и загрузке в него требуемого файла или ссылки. Для прикрепления к актёру файла необходимо:
1) щелкнуть правой кнопкой мыши где-нибудь в свободном белом поле вкладки Files;
2) в открывшемся меню выберите пункт Insert File;
3) в диалоговом окне найдите файл, который нужно прикрепить;
4) нажмите кнопку Open, чтобы прикрепить файл к действующему лицу.
Имя и путь этого файла появятся во вкладке Files и в браузере ниже имени действующего лица. Для удаления связанного с актёром файла или ссылки щёлкните правой кнопкой мыши на файле или ссылки в браузере и в открывшемся меню выберите пункт Delete.
Определение элементов Use Case (прецедентов). После определения внешней среды следует выявить внутренние функциональные возможности проектируемой системы. Для этого определяют элементы Use Case. Каждый элемент Use Case задаёт некоторый путь использования системы, т.е. выполнение некоторой части её функциональных возможностей. Полная совокупность элементов Use Case определяет все существующие пути использования системы.
Элемент Use Case - это последовательность взаимодействий между актёром и системой, происходящих в диалоге. Так как элемент Use Case запускается действующим лицом, то удобно выявлять эти элементы, называемые также прецедентами, с помощью актёров.
Раcсматривая каждого актёра, необходимо определять, какие элементы Use Case он может выполнять. Для этого изучается описание системы ( с точки зрения актёра) или проводится обсуждение с теми, кто будет действовать как актёр. В нашем примере Клиент - это первичный актёр, поэтому целесообразно начать с этой роли. Этот актёр должен выполнять возврат утилизируемых элементов. Поэтому формируется элемент Use Case "Приём элемента тары". Приведём его текстовое описание:
Активизируется, когда клиент начинает возвращать банки, бутылки или ящики. Для каждого элемента, помещенного в машину утилизации, система увеличивает количество элементов, принятых от клиента, и общее количество элементов этого типа за день. Поле сдачи всех элементов Клиент нажимает кнопку квитанции, чтобы получить квитанцию, на которой напечатаны названия возвращенных (принятых) элементов и общая сумма возврата.
Следующий актёр - Оператор. Он должен получать дневной отчёт об элементах, сданных за день. Это образует элемент Use Case с названием "Создание дневного отчёта". Внешние спецификации этого прецедента могут быть представлены в следующем виде:
Начинается Оператором, когда он хочет получить информацию об элементах, сданных за день. Система печатает количество элементов каждого типа и общее количество элементов, полученных за день. Для подготовки к созданию нового дневного отчёта сбрасывается в ноль параметр Общее количество.
Кроме того, актёр Оператор может изменять параметры сдаваемых элементов. Назовём соответствующий элемент Use Case "Изменение условий приёма". Его описание:
Могут изменяться цена и размер каждого возвращаемого элемента. Могут добавляться новые типы элементов.
После выявления описанным способом всех прецедентов получаем диаграмму Use Case проектируемой системы:
Клиент
Оператор
Рис.2. Диаграмма Use Case для машины утилизации тары
Чаще всего полные описания элементов Use Case формируются за несколько итераций этапов анализа и проектирования. На каждой итерации в описание вводятся дополнительные детали. Например, более полное описание прецедента "Приём элемента тары" может иметь следующий вид:
Когда клиент возвращает сдаваемый элемент, элемент измеряется системой. Измерения позволяют определить тип элемента. Если тип допустим, то увеличивается количество элементов этого типа, принятых от Клиента, и общее количество элементов этого типа за день.
Если тип не допустим, то на панели машины высвечивается "недействительно". Когда Клиент нажимает кнопку "Квитанция", принтер печатает дату. Производятся вычисления. По каждому типу принятых элементов печатается информация: название, принятое количество элементов тары, цена, итого для каждого типа. В конце печатается сумма, которую должен получить Клиент.
Не всегда бывает очевидно, как распределить функциональные возможности системы между отдельными элементами Use Case и что является вариантом одного и того же элемента Use Case. В этой ситуации основной критерий правильной декомпозиции - сложность создаваемого элемента Use Case. При анализе вариантов поведения в первую очередь рассматривают их различия. Если различия малы, то варианты встраивают (объединяют) в один элемент Use Case. Если различия велики, то варианты описываются как отдельные прецеденты. Обычно элемент Use Case задаёт одну основную и несколько альтернативных последовательностей событий.
Каждый элемент Use Case выделяет частный аспект функциональных возможностей проектируемой системы. Поэтому элементы Use Case обеспечивают инкрементную схему анализа функций системы. Можно независимо разрабатывать элементы Use Case для разных функциональных особенностей работы системы, а позднее соединить их вместе для формирования полной модели требований. Таким образом, на основе теории декомпозиции и представления функциональности системы в виде иерархии прецедентов (вариантов использования) имеется возможность в каждый момент времени концентрировать внимание на одной частной подзадаче, что позволяет вести параллельную разработку сложной системы.
Расширение функциональных возможностей системы. Для описания дополнительных возможностей прецедента можно к нему добавить с помощью отношения расширения новые абстрактные элементы Use Case. В рассматриваемом примере не определено поведение системы для ситуации, когда сдаваемый элемент застрял в машине. Поэтому целесообразно ввести новый прецедент "Элемент застрял", который будет расширять базовый элемент "Приём элемента тары" (рис. 3).
<<extend>>
Рис. 3. Расширение прецедента "Приём элемента тары"
Описание прецедента "Элемент застрял" может иметь следующий вид:
Если элемент застрял, то вырабатывается сигнал тревоги для вызова Оператора. После удаления застрявшего элемента Оператор сбрасывает сигнал тревоги. В результате Клиент может продолжить сдачу тары. Величина ИТОГО сохраняет правильное значение. Цена застрявшего элемента тары не засчитывается.
В результате, описание базового прецедента остается прежним и простым.
Задание к лабораторной работе
Создать диаграмму вариантов использования (Use Case Diagram) в CASE-среде Rational Rose для последующей разработки заданной автоматизированной системы.
№
Проектируемая автоматизированная система1.Пульт дистанционного управления телевизора2.Система продажи компьютерной техники в супермаркете3.Управление мобильным телефоном4.Система оперативного контроля потребления электроэнергии5.Автоматизация междугородних телефонных разговоров6.Система диспетчеризации работы такси7.Система автоматизированной продажи железнодорожных билетов8.Система управления отопления жилого дома9.Автоматизация работы деканата ВУЗа10.Повременной учет телефонных разговоров11.Система регистрации ошибок в сопровождаемых программных системах12.Система управления движением железнодорожного поезда13.Система управления теплицей для выращивания овощей14.Система компьютерного управления движением автомобиля15.Визуализация в реальном времени движения автомобиля по текущим координатам.16Программное обеспечение для контроллера пульта управления кондиционером типа "сплит-система".17Компьютерная система видеонаблюдения, доступа и охраны.18Компьютеризированная система охранной и пожарной сигнализации (электронная система безопасности).19Система обработки заказов покупателей в магазине20Банкомат21Информационная система продажи авиабилетов в кассах аэрофлота22Автомат по продажи лимонада23Система обслуживания проживания в гостинице24Интернет-магазин25Оценка кредитных и инвестиционных рисков26Оценка стоимости недвижимости27Прогнозирование оптовых и розничных цен на товар28Система маркетинговых исследований.29Оценка эффективности инвестиционных проектов30Моделирование управленческого учета на предприятии31Система анализа и прогнозирования налоговых поступлений32Функционирование приемной комиссии ВУЗа33Оценка и управление рыночными (валютными) рисками Порядок выполнения работы
1. Внимательно ознакомьтесь с постановкой задачи и прочитайте документацию заказчика. Это позволит лучше обнаружить варианты использования. Варианты использования должны заострять внимание на том, что должна делать система, а не на том, как она должна это делать. Часто помогает также рассмотрение области использования системы на высоком уровне и документов концептуального характера. Учтите мнение каждого из заинтересованных лиц проекта. Осмыслите, что они ожидают от готового программного продукта. Каждому заинтересованному лицу можно задать следующие вопросы:
- что он хочет делать с системой ?
- будет ли он с её помощью работать с информацией (вводить, получать, обновлять, удалять)?
- нужно ли будет информировать систему о каких-либо внешних событиях?
- должна ли система в свою очередь информировать пользователя о каких-либо изменениях или событиях?
2. Выявите всех действующих лиц, взаимодействующих с проектируемой системой автоматизации. Определяя (называя) действующих лиц, используйте их ролевые имена, а не те, что соответствуют их должности. Это обеспечит более стабильную картину действующих лиц (актёров). Рекомендуемое общее количество актеров в модели - не более 20, а вариантов использования - не более 50.
На этом этапе полезно изобразить выявленных пользователей системы в иерархии обобщения.
Для введения в диаграмму Use Case действующих лиц необходимо выполнить следующее:
1) с помощью кнопки Actor панели инструментов поместите на диаграмму новое действующее лицо;
2) назовите его, например, "Клиент" (см. рис. 1);
3) повторив шаги 1 и 2, поместите на диаграмму остальных действующих лиц: "Оператор" и т.п.
3. Путем системного анализа поставленной задачи и интервьюирования потенциальных пользователей системы, выявите высокоуровневые прецеденты, описывающие функциональные требования в общих терминах (рис. 2). В дальнейшем, при необходимости, любой прецедент может быть подвергнут дальнейшей декомпозиции на множество подвариантов использования, которые детализируют исходную сущность.
Необходимо учитывать, что прецедент - это конструкция, позволяющая описать систему с точки зрения потенциальных пользователей. Прецедент представляет собой набор сценариев, инициируемых исполнителями (людьми, аппаратными средствами, другими системами, интервалами времени). Результат прецедента должен быть полезен исполнителю, инициировавшему этот прецедент, либо какому-то другому исполнителю.
Для создания прецедента на диаграмме Use Case следует:
1) с помощью кнопки Use Case панели инструментов поместите на диаграмму новый вариант использования;
2) назовите его, допустим, "Прием элемента тары" (см. рис 2);
3) повторив шаги 1 и 2 поместите на диаграмму остальные прецеденты;
- "Создание дневного отчета";
- "Изменение условий приема".
Далее определите отношения ассоциации между прецедентами. Для этого с помощью кнопки "Однонаправленная ассоциация" панели инструментов нарисуйте все ассоциации (стрелки) между актёрами и прецедентами, с которыми они взаимодействуют (рис 2). Чтобы показать дополнительные функциональные возможности системы, надо применить отношение расширения или включения между основным и дополнительным элементом Use Case (см. рис. 3 и 4).
Для этого:
1) создайте дополнительный прецедент "Возврат элемента" (рис 3);
2) щелкните правой кнопкой мыши на прецеденте "Элемент застрял" и в меню выберите пункт Open Specification;
3) установите флажок Abstract (абстрактный) чтобы сделать прецедент абстрактным;
4) с помощью кнопки "Обобщение" нарисуйте связь между прецедентами "Элемент застрял" и "Возврат элемента". Стрелка должна идти от первого прецедента ко второму;
5) щелкните правой кнопкой мыши на новой связи между прецедентами "Элемент застрял" и "Возврат элемента" и в открывшемся меню выберите пункт "Open Specification";
6) в раскрывающемся списке стереотипов введите нужное слово "extend" (расширение) или "include" (включение) и нажмите ОК. (соответствующая надпись появится на линии данной связи.)
4. Для повышения информативности диаграммы Use Case целесообразно добавлять описания и примечания к прецендентам и актерам. С этой целью:
1) выделите в браузере прецедент (например, "Прием элемента тары" на рис.2);
2) в окне документации введите нужное описание, например "Этот вариант использования дает клиенту возможность возвращать использованную тару".
С помощью окна документации или инструмента Note (примечание) добавьте описание ко всем остальным прецедентам и актёрам.
5. Опишите более подробно поведение элементов Use Case с помощью потока событий. На начальном этапе составления внешних спецификаций прецедентов можно ограничится оформлением их в текстовой форме, прозрачной для пользователя системы. Например, в файле spec.doc можно описать основной поток событий для некоторого варианта использования под названием "Ввести новый заказ" в виде следующей последовательности шагов:
1) продавец выбирает в имеющемся меню пункт "Создать новый заказ";
2) система выводит форму "Детали заказа";
3) продавец вводит номер заказа, заказчика и то, что заказано;
4) продавец сохраняет заказ;
5) система создает новый заказ и сохраняет его в базе данных.
Такой файл необходимо прикрепить к соответствующему прецеденту, для чего:
1) щелкните правой кнопкой мыши на прецедент "Введите новый заказ";
2) в открывающемся меню выберите пункт Open Specification;
3) перейдите на вкладку Files;
4) щелкните правой кнопкой мыши в белой области и в открывающемся меню выберите пункт Insert File;
5) укажите файл spec.doc и нажмите кнопку Open, чтобы прикрепить файл к варианту использования;
6. Убедитесь, что вы обнаружили все варианты использования. Для этого следует ответить на следующие вопросы:
- Присутствует ли каждое функциональное требование хотя бы в одном варианте использования? Если требование не нашло отражения в прецеденте, то оно не будет реализовано.
- Учтено ли, как с системой будет работать каждое заинтересованное лицо?
- Какую информацию будет передавать системе каждое заинтересованное лицо?
- Какую информацию будет получать от системы каждое заинтересованное лицо?
- Учтены ли проблемы, связанные с эксплуатацией (кто-то должен будет запускать готовую систему и выключать её)?
- Учтены ли все внешние системы, с которыми будет взаимодействовать данная?
- Какой информацией каждая внешняя система будет обмениваться с данной?
Содержание отчёта
1. Название и цель работы.
2. Постановка задачи, назначение системы автоматизации.
3. Диаграммы вариантов использования проектируемой системы.
4. Спецификация элементов Use Case. 
Документ
Категория
Рефераты
Просмотров
209
Размер файла
109 Кб
Теги
uml, lab
1/--страниц
Пожаловаться на содержимое документа