Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Системный анализ и проектирование информационных систем на основе объектно-ориентированного подхода. Учебно-методическое пособие по дисциплине «Методы
.pdf
3. Создайте всех действующих лиц бизнес-процесса
«Управление учебным процессом ВУЗа» в соответствии с
описанием.
Исходя из описания бизнес-процесса, выделяются
следующие действующие лица:
Student (Студент) – записывается на курсы;
Professor (Профессор) – выбирает курсы для
преподавания и проставления оценки;
Registrar (Регистратор) – формирует учебный план и
каталог курсов, ведет все данные о курсах, профессорах и
студентах;
Billing System (Расчетная система) – получает от
данной системы информацию по оплате за курсы;
Course catalog (Каталог курсов) – передает в систему
информацию из каталогов курсов, предлагаемых
университетом;
User (Пользователь) – абстрактное действующее
лицо, служащее для входа в систему.
На рисунке 13 представлены актеры бизнес-процесса.
Рисунок 13 – Вид окна инспектора модели после
создания всех действующих лиц («Актеров»)
41
4. Создайте все сценарии поведения бизнес-процесса
«Управление учебным процессом ВУЗа» в соответствии с
описанием.
Исходя из потребностей актеров, выделяются
следующие варианты использования:
Login (Войти в систему);
Register for Courses (Зарегистрироваться на курсы);
View Report Card (Просмотреть табель
успеваемости);
Select Courses to Teach (Выбрать курсы для
преподавания);
Submit Grades (Проставить отметки);
Maintain Professor Information (Вести информацию о
профессорах);
Maintain Student Information (Вести информацию о
студентах);
Close Registration (Закрыть регистрацию).
На рисунке 14 представлены варианты использования
бизнес-процесса.
42
Рисунок 14 – Вид окна инспектора модели после создания
всех вариантов использования
5. После размещения свяжите компоненты между
собой, чтобы отобразить взаимосвязи. В нашей модели
наилучшим образом подойдут связи типа
«однонаправленная ассоциация» (Directed Association) и
«Обобщение» (Generalization).
Для создания отношения между элементами диаграммы
щелкните по изображению соответствующего отношения
на панели элементов справа, а затем проведите линию от
одного элемента к другому, удерживая левую кнопку
мыши. В результате на диаграмме возникнет стрелка.
Аналогичным образом поступают со всеми компонентами
диаграммы.
Готовая диаграмма представлена на рисунке 15.
Рисунок 15 – Диаграмма вариантов использования для
бизнес-процесса «Управление учебным процессом ВУЗа»
6. Для того чтобы создать еще одну диаграмму (любого
типа), например, детализирующую прецедент, щелкните
правой кнопкой мыши по папке Use Case Model и в
появившемся контекстном меню выберите Add Diagram,
затем выберите из списка диаграмму, которую вы хотите
43
добавить. Например, можно создать дополнительную
диаграмму прецедентов, выбрав пункт Use Case Diagram
(рисунок 16).
Рисунок 16 – Создание дополнительной диаграммы
прецедентов
Потоки событий
Диаграммы вариантов использования (Use Case
Diagram) являются самым общим представлением
функциональных требований к системе. Для последующего
проектирования системы требуются более конкретные
детали. Эти детали описываются в документе, называемом
«Поток событий» (Flow of events).
Целью описания потока событий (сценария) является
подробное документирование процесса взаимодействия
действующего лица с системой в рамках варианта
использования.
При выявлении альтернативных потоков событий
нужно проанализировать ситуации, связанные с:
некорректным действием пользователя (например,
ввод неверного пароля);
бездействием актера (например, истечение времени
ожидания пароля);
44
внутренними ошибками в разрабатываемой системе
Характеристика
Описание характеристики
Название
сценария
Название должно отражать суть
данного варианта использования
системы с точки зрения
пользователя
Список актеров
Внешние актеры,
взаимодействующие с системой при
выполнении данного сценария
Краткое описание
Зачем нужен данный сценарий,
какие события инициирует данный
сценарий, что является результатом
данного сценария
Предусловия
(precondition)
Условия, которые должны быть
выполнены прежде, чем вариант
использования начнет выполняться
Основной поток
Описание того, что должно
происходить при реализации
нормального хода событий
Альтернативный
поток событий
Описание того, что будет
происходить при отклонении от
нормального хода событий, т.е.
ошибочных ситуаций и их
обработки
(например, неправильно прописаны права пользователя,
сбой аппаратуры);
критически важными недостатками, влияющими на
производительность системы (например, среднее время
реакции системы > 5сек.).
Описание потока событий (сценария) включает
следующие разделы, представленные в таблице 3.
Таблица 3 – Разделы описания потока событий (сценария)
45
Постусловия (post
condition)
Условия, которые всегда должны
быть выполнены после завершения
варианта использования
Расширения
(extension)
Описание редко встречающихся
ситуаций в основном потоке
событий (частный случай)
Пример описания варианта использования
«Войти в систему» (Login)
Краткое описание
Этот Use Case (UC) описывает вход пользователя в
систему регистрации курсов.
Основной поток
Этот UC начинает выполняться, когда пользователь
хочет войти в систему регистрации курсов.
1. Система запрашивает имя пользователя и пароль
2. Пользователь вводит имя и пароль
3. Система подтверждает имя и пароль, после чего
открывается доступ в систему.
Альтернативные потоки
1. Неверное имя/пароль
Если во время выполнения основного потока
обнаруживается, что пользователь ввел неверное имя или
пароль, система выводит сообщение об ошибке.
Пользователь может либо вернуться к началу основного
потока, либо отказаться от входа в систему, при этом UC
завершается.
Предусловия
Отсутствуют.
Постусловия
Если UC выполнен успешно, пользователь входит в
систему. В противном случае состояние не изменяется.
46
Описание потока событий для вариантов
использования «Просмотреть оценки» (View report card),
«Выбрать курсы для преподавания» (Select courses to teach)
и «Проставить оценки» (Submit grades) представлено в
Приложении 1.
Требования к отчету
Отчет о работе должен содержать следующее:
1. Название работы
2. Описание бизнес-процесса
3. Текст задания
4. Распечатку разработанной модели
Контрольные вопросы
1. Назовите типы сущностей нотации UML и дайте им
краткую характеристику.
2. Перечислите виды отношений нотации UML.
3. Назовите варианты отображения стереотипов.
4. Что представляет собой диаграмма вариантов
использования в графической нотации UML?
5. Перечислите элементы диаграммы вариантов
использования и дайте им определения.
6. Какие виды отношений могут использоваться на
диаграмме вариантов использования?
7. Чем отношение включения отличается от отношения
расширения?
8. Что такое «Поток событий»?
47
Лабораторная работа №2. Построение диаграмм
классов для вариантов использования бизнес-процесса
«Управление учебным процессом ВУЗа»
Цель работы:
Получить практические навыки в построении диаграмм
классов UML бизнес-процесса «Управление учебным
процессом ВУЗа» средством StarUML 5.0.
Краткие теоретические сведения
Диаграмма классов (class diagram) служит для
представления статической структуры модели системы в
терминологии классов объектно-ориентированного
программирования. Диаграмма классов может отражать, в
частности, различные отношения между отдельными
сущностями предметной области, такими как объекты и
подсистемы, а также описывает их внутреннюю структуру
и типы отношений.
Класс – это дескриптор множества объектов,
обладающих общими атрибутами, операциями, методами,
отношениями и поведением. Это описание некоторой
концепции предметной области или элемента
программного решения.
Диаграмма классов в общем виде представлена графом.
Узлами графа являются элементы статической
структуры проекта:
классы (атрибуты, методы);
интерфейсы;
шаблоны (определяют семейство классов,
отличающихся значениями некоторых формальных
признаков);
объекты.
Дугами графа являются отношения между узлами:
ассоциации;
обобщения;
зависимости.
48
Каждый класс имеет название, атрибуты и операции.
Класс на диаграмме показывается в виде прямоугольника,
разделенного на 3 области (рисунок 17). В верхней
содержится название класса, в средней – описание
атрибутов (свойств), в нижней – названия операций – услуг,
предоставляемых объектами этого класса.
У каждого класса должно быть имя (текстовая строка),
уникально отличающее его от всех других классов. При
формировании имен классов в UML допускается
использование произвольной комбинации букв, цифр и
даже знаков препинания. Однако на практике
рекомендуется использовать в качестве имен классов
короткие и осмысленные прилагательные и
существительные, каждое из которых начинается с
заглавной буквы.
Рисунок 17 – Графическое изображения класса
Атрибутом класса называется именованное свойство
класса, описывающее множество значений, которые могут
принимать экземпляры этого свойства. Класс может иметь
любое число атрибутов (в частности, не иметь ни одного
атрибута). Свойство, выражаемое атрибутом, является
свойством моделируемой сущности, общим для всех
объектов данного класса. Так что атрибут является
абстракцией состояния объекта. Любой атрибут любого
объекта класса должен иметь некоторое значение. Имена
атрибутов представляются в разделе класса,
расположенном под именем класса.
Каждый атрибут имеет имя и тип, определяющий, какие
данные он представляет. При реализации объекта в
49
программном коде для атрибутов будет выделена память,
необходимая для хранения всех атрибутов, и каждый
атрибут будет иметь конкретное значение в любой момент
времени работы программы. Объектов одного класса в
программе может быть сколь угодно много, все они имеют
одинаковый набор атрибутов, описанный в классе, но
значения атрибутов у каждого объекта свои и могут
изменяться в ходе выполнения программы.
Синтаксис атрибута на языке UML
[<видимость>] [‘/’] <имя> [‘:’ <тип атрибута>]
[‘[‘<кратность>‘]’] [‘=’ <значение по умолчанию>]
[‘{‘<модификатор атрибута> [‘,’ <модификатор
атрибута>]* ’}’] , где
<видимость>::= ‘+’ | ‘–‘ | ‘#’ | ‘~’
Видимость (visibility) может принимать одно из 3-х
возможных значений и отображаться либо посредством
специального символа, либо соответствующего ключевого
слова
+ public (общедоступный). Общедоступный элемент
является видимым всеми элементами.
- private (закрытый). Закрытый элемент, является
видимым только внутри пространства имен, который им
владеет.
# protected (защищенный). Защищенный элемент
является видимым для элементов, которые имеют
отношение обобщения с пространством имен, который им
владеет.
“/” означает, что атрибут является производным
(derive).
Значение производного атрибута может быть
вычислено на основе значений других атрибутов этого или
других классов. Поэтому данный атрибут называют иногда
вычислимым. При использовании производных атрибутов
50
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]