проектный практикум 7 практик. Создание диаграмм прецедентов (вариантов) использования 2
 Скачать 1.86 Mb.
|
СОДЕРЖАНИЕЛабораторная работа №1 2 Тема: Создание диаграмм прецедентов (вариантов) использования 2 Лабораторная работа №2 13 Тема: Создание диаграмм последовательностей 13 Лабораторная работа №3 18 Тема: Создание кооперативной диаграммы 18 Лабораторная работа №4 24 Тема: Создание диаграммы состояний 24 Лабораторная работа №5 32 Тема: Создание диаграмм активности (деятельности) 32 Лабораторная работа №№6-7 39 Тема: Создание диаграмм классов 39 Лабораторная работа №1 Тема: Создание диаграмм прецедентов (вариантов) использованияЦель работы: изучение среды программного инструмента моделирования StarUML, поддерживающего UML, и приобретение навыков по созданию диаграмм прецедентов (вариантов) использования. Теоретическая часть Визуальное моделирование и UML Визуальным моделированием (visualmodeling)называется способ представления идей и проблем реального мира с помощью моделей. Модель – это абстракция, описывающая суть сложной проблемы или структуры без акцента на несущественных деталях, тем самым делая ее более понятной. Разработка программного обеспечения - не исключение. При построении сложной системы строятся ее абстрактные визуальные модели. В настоящее время в области проектирования информационных систем успехом применяется визуальное моделирование с помощью унифицированного языка моделирования UML. Унифицированный язык моделирования (UnifiedModelingLanguage, UML) является графическим языком для визуализации, специфицирования, конструирования и документирования систем, в которых большая роль принадлежит программному обеспечению. С помощью UML можно детально описать систему, начиная разработку с концептуальной модели с ее бизнес-функциями и процессами, а также описать особенности реализации системы, такие как классы программного обеспечения системы, схему базы данных. Используя UML, мы также можем разрабатывать сложные системы быстро и качественно. Как язык графического визуального моделирования UML имеет свою нотацию –принятые обозначения. Нотация обеспечивает семантику языка, является способом унификации обозначений визуального моделирования, обеспечивает всестороннее представление системы, которое сравнительно легко и свободно воспринимается человеком. Моделирование с помощью UML осуществляется поэтапным построением ряда диаграмм, каждая из которых отражает какую-то часть или сторону системы либо ее замысла. Диаграмма – это графическое представление множества элементов. Обычно, диаграмма изображается в виде графа с вершинами (сущностями) и ребрами (отношениями). Диаграммы подчиняются нотации UML и изображаются в соответствии с ней. Определены следующие виды диаграмм: вариантов использования (usecasediagram); классов (classdiagram); кооперации (collaborationdiagram);последовательности (sequencediagram); состояний (statechartdiagram); деятельности (activitydiagram); взаимодействия (interactiondiagrams); компонентов (componentdiagram); развертывания (deploymentdiagram). Построения этих диаграмм достаточно для полного моделирования системы. Особенности рабочего интерфейса программного комплекса StarUML StarUML ориентирован на UML версии 1.4, поддерживает одиннадцать различных типов диаграмм, принятых в нотации UML 2.0, и представляет собой интегрированный инструментарий для проектирования архитектуры, анализа, моделирования и разработки программных систем. Среда моделирования StarUML превосходно настраивается в соответствии с требованиями пользователя и имеет высокую степень расширяемости, особенно в области своих функциональных возможностей. Создание нового проекта в StarUML Основная структурная единица в StarUML – это проект. Проект сохраняется в одном файле в формате XML с расширением «.UML». Проект может содержать одну или несколько моделей и различные представления этих моделей (View) – визуальные выражения информации, содержащейся в моделях. Каждое представление модели содержит диаграммы – визуальные образы, отображающие определенные аспекты модели. Новый проект будет автоматически создан при запуске программы StarUML. При этом вам будет предложено в диалоговом окне выбрать один из подходов (Approaches), поддерживаемых StarUML (см. рис. 1).  Рисунок 1. Выбор подхода Существуют различные методологии моделирования информационных систем, компании-разработчики систем также могут разрабатывать свои методологии. Следовательно, на начальной стадии проектирования необходимо определить основные положения методологии или выбрать одну из уже существующих. Для того чтобы согласовать между собой различные элементы и этапы моделирования, StarUML предлагает концепцию подходов.  После выбора одного из предложенных подходов, появится основное окно программы (рис. 2).Рисунок 2. Основное окно программы Главное окно StarUML состоит из следующих компонентов: главное меню - находится наверху экрана. Большинство функции StarUML ™ доступны через главное меню; инструментальные панели, которые расположены ниже главного меню. Их кнопки дублируют часто используемые пункты меню; область браузера. Она расположена в верхнем правом углу экрана. Эта область содержит инструменты, облегчающие просмотр составляющих элементов проекта. Эта область включает [Навигатор модели] (ModelExplorer), который отображает модельные элементы в виде иерархической структуры, и [Навигатор диаграмм], (DiagramExplorer), который отображает диаграммы модели, сгруппированные по типам; область инспектора расположена в нижнем правом углу экрана. Эта область содержит инструменты, облегчающие редактирование детальной информации о модельных элементах. Эта область включает [Редактор свойств] (Properties), который позволяет редактировать свойства, [Документационный редактор] (Documentation), позволяющий водить детальные описания элементов, и [Редактор вложений] (Attachments), который позволяет присоединять к элементам дополнительные файлы и URL; иинформационная область расположена в нижней части экрана. Эта область содержит инструменты, отображающие различные вспомогательные данные, касающиеся приложения StarUML ™. Эта область включает [Окно Вывода] (Output), которое показывает регистрационную информацию, и [Окно Сообщений] (Message), которое отображает результаты поиска и проверки модели; область диаграммы расположена в центре экрана. Эта область содержит инструментарий, позволяющий редактировать и управлять диаграммами; палитра элементов расположена на левой стороне экрана. Палитра содержит инструменты для быстрого создания модельных элементов. В верхней части окна расположено главное меню, кнопки быстрого доступа. Слева расположена панель элементов (Toolbox) с изображениями элементов диаграммы. Элементы соответствуют типу выбранной диаграммы. В центре находится рабочее поле диаграммы, на котором она может быть построена с использованием соответствующих элементов панели инструментов. Справа находится инспектор модели, на котором можно найти вкладки навигатора модели ModelExploer, навигатора диаграмм DiagramExploer, окно редактора свойств Properties, окно документирования элементов модели Documentation и редактор вложений Attachments. Внешний вид инспектора модели с вкладками представлен ниже (рис. 3).  Рисунок 3. Инспектор модели  Рисунок 4. Пункт меню View. Управление видом инспектора модели Управлять видом инспектора модели, панели элементов, закрывать и открывать редакторы инспектора можно с помощью пункта меню View (рис.4). Если рядом с пунктом меню стоит «галочка», этот элемент активен и его можно видеть в окне программы или открыть на доступных вкладках инспектора модели. Иерархическая структура проекта отображается справа на навигаторе модели (ModelExploer). В зависимости от выбранного подхода на навигаторе модели будут отображены различные пакеты представлений модели. Каждый пакет представления будет содержать элементы моделей и диаграмм, которые мы создадим. Если при создании нового проекта моделирования выбрать подход RationalApproach, то при таком подходе в навигаторе будут присутствовать четыре пакета представлений модели системы (см. рис. 5): UseCaseView – представление требований к системе, описывает, что система должна делать; LogicalView – логическое представление системы, описывает, как система должна быть построена; ComponentView – представление реализации, описывает зависимость между программными компонентами; DeploymentView – представление развертывания, описывает аппаратные элементы, устройства и программные компоненты.  Рисунок 5. Навигатор модели Сейчас каждое представление содержит одну диаграмму с именем Main. Если щелкнуть по ней два раза, то откроется рабочее поле этой диаграммы и соответствующая панель инструментов. Пример. Если щелкнуть два раза по диаграмме Main представленияUseCaseView, то откроется рабочее этой диаграммы и ее панель элементов (рис. 6).  Рисунок 6. Рабочее поле диаграммы прецедентов Main и ее панель элементов Ниже иерархии представлений отображаются свойства выделенного элемента модели или диаграммы (в данном случае свойства диаграммы Main, так как она выделена в навигаторе модели) (см. рис. 7).  Рисунок 7. Редактор свойств Назначение кнопок специальной панели инструментов для диаграммы прецендентов использования приведено в табл. 1.1.
Порядок выполнения работы Необходимо разработать модель прецедентов (вариантов) использования, состоящую из одной или нескольких диаграмм прецедентов использования, для разрабатываемой информационной системы. Постановка задачи (описание предметной области). Магазин осуществляет продажу товаров клиенту путем оформления документов «Заказ». Директор магазина, принял решение автоматизировать документооборот продаж товара и пригласил для выполнения работ программиста. Поговорив с директором, в соответствие с концепцией жизненного цикла (ЖЦ) программы программист приступил к описанию бизнес процессов, сопровождающих продажу товара. Взяв за основу язык UML, он начал с построения контекстной диаграммы процессов- UseCasediagram. Диаграмма должна ответить на вопрос-«что должно делаться в системе и кто участник этих процессов». Окончательный вид диаграммы показан на рис.8  Рисунок 8 – Диаграмма вариантов использования задачи о заказе товара Для этого выполните следующую последовательность действий: Создайте новый проект и заполните его свойства в области Properties. Внавигаторе моделей выберите <  Рисунок 9 – Создание диаграммы прецедентов использования С помощью окна «Toobox» и вкладки «UseCase» поместите на диаграмму новый вариант использования. Назовите его «Ввести новый заказ». Повторив этапы 2 и 3, поместите на диаграмму остальные варианты использования: Изменить существующий заказ; Напечатать инвентарную опись; Обновить инвентарную опись; Оформить заказ; Отклонить заказ; Выполнить поставку заказа. С помощью кнопки Actor (Действующее лицо) панели инструментов поместите на диаграмму новое действующее лицо. Назовитеего «Продавец». Повторив шаги 4 и 5, поместите на диаграмму остальных действующих лиц: Управляющий магазином; Клерк магазина; Бухгалтерская система. Создание абстрактного варианта использования (не требующего дальнейшей декомпозиции). Щелкните мышью на варианте использования «Отклонить заказ» на диаграмме. В окне «Properties» установите флажок isAbstract (Абстрактный), чтобы сделать этот вариант использования абстрактным (рис.10).  Рисунок 10 – Создание абстрактного варианта использования Добавление ассоциаций. С помощью кнопки DirectedAssociation (Однонаправленная ассоциация) в окне «Toolbox» нарисуйте ассоциацию между действующим лицом Продавец и вариантом использования «Ввести заказ». Повторив шаг 1, поместите на диаграмму остальные ассоциации, согласно рис.8. Добавление связи расширения. С помощью кнопкиGeneralization(Обобщение) в окне «Toolbox» нарисуйте связь между вариантом использования «Отклонить заказ» и вариантом использования «Оформить заказ». Стрелка должна быть направлена от первого варианта использования ко второму. Связь расширения означает, что вариант использования «Отклонить заказ» при необходимости дополняет функциональные возможности варианта использования «Оформить заказ». Добавление описаний к вариантам использования. Выделите вариант использования «Ввести новый заказ». В окне документации введите следующее описание: «Этот вариант использования дает клиенту возможность ввести новый заказ в систему» (рис.11).  Рисунок 11 – Описание к вариантам использования С помощью окна документации добавьте описания ко всем остальным вариантам использования. Добавление описаний к действующему лицу. Выделите действующее лицо «Продавец». В окне документации введите следующее описание: «Продавец это служащий, старающийся продать товар». С помощью окна документации добавьте описания к остальным действующим лицам. Создайте еще одну или несколько диаграмм прецедентов использования, на которых отобразите все необходимые для системы прецеденты использования, актеров и все необходимые связи, например.  Рисунок 12 – Пример диаграммы описания границ системы Диаграмма обязательно должна содержать включаемый и расширяющий прецеденты и соответствующие связи зависимости прецендентов (использования и расширения) между прецедентами. Для добавления связи использования необходимо нажать кнопку Include панели инструментов и направить связь от базового прецендента к включаемому. Д < В окне свойств святи расширения не обходимо указать в текстовом виде условие (свойство ConditionсекцииGeneralобластиProperties ), при котором будет выполняться расширение. В базовом прецеденте, имеющем расширение, необходимо создать точку расширения (свойство ExtenzionPointsсекцииGeneralобластиPropertiesпрецедента). Пример фрагмента диаграммы с точкой расширения приведен на рис. 13  Рисунок 13 - Пример фрагмента диаграммы с точкой расширения На рис.14 отображен пример полной диаграммы прецедентов использования. Создайте для одного из прецендентов использования файл, содержащий спецификацию потока событий (описание сценария его выполнения) и прикрепите его к преценденту (область Attachments).  Рисунок 14 – Диаграмма прецендентов использования для банкомата Структура спецификации прецедента использования (usecasedocument) может варьироваться, однако типичное описание должно содержать следующую информацию: Краткое описание. Участвующие действующие лица. Предусловия, необходимые для инициирования прецедента использования. Детализированное описание потока событий, включающее в себя: основной поток событий, который можно разбить на несколько частей, чтобы показать подчиненные потоки событий (подчиненные потоки могут быть разделены затем на еще более мелкие потоки, с целью улучшить читабельность документа); альтернативные потоки для определения исключительных ситуаций. ■ Постусловия, определяющие состояние систем, по достижении которого прецедент использования завершается. Пример спецификации потоков событий прецедента приведен в табл. 1.2. Таблица 1.2 – Пример спецификации потоков событий
После окончания сеанса работы над проектом выполненную работу необходимо сохранить в файле проекта с расширением .UMl. Покажите разработанные диаграммы преподавателю. Оформите отчет. Сдайте выполненную и оформленную надлежащим образом работу преподавателю. Содержание отчета Индивидуальный отчет о выполненной лабораторной работе должен содержать: цель работы; наименование функционального комплекса задач или системы, для которых разработана диаграмма прецендентов использования; разработанные диаграммы прецендентов использования; спецификацию потоков событий для одного из прецендентов использования; выводы о полученных знаниях и умениях. Контрольные вопросы Какие элементы может содержать диаграмма прецендентов использования? Чем или кем могут быть представлены актеры (действующие лица) в системе? В каких случаях используют отношения включения на диаграммах Прецендентов Использования? В каких случаях используют отношения расширения на диаграммах прецендентов использования? Как определяется направленность связи ассоциации между актером и прецендентом использования? Что такое точка расширения прецедента? С помощью чего описывается динамика прецендента использования. На каком этапе разработки программной системы разрабатывается диаграмма прецедентов использования? Каково ее назначение? Сколько диаграмм прецедентов использования необходимо разрабатывать для одной программной системы? Лабораторная работа №2 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
