Московский государственный институт электроники и математики

(технический университет)

Кафедра

«электронно-вычислительная аппаратура»

Лабораторный практикум

по моделированию бизнес-процессов, бизнес-функций, описанию документов при моделировании, моделированию сценария поведения объектов с использованием CASE-средства Rational Rose

по дисциплине «Информационные технологии»

Москва 2007 г.

Содержание

«Моделирование бизнес-процессов при проектировании программных систем с использованием CASE-средства Rational Rose». 2

Теоретическая часть. 2

Принципы Case-технологий разработки ИС.. 4

Практическая часть. 6

Запуск и настройка системы.. 6

Моделирование диаграмм бизнес процессов. 7

Определение автоматизируемых бизнес процессов. 11

Порядок выполнения работы.. 11

«Моделирование бизнес-функций предметной области при проектировании программных систем с использованием CASE-средства Rational Rose». 13

Теоретическая часть. 13

Моделирование предметной области. 13

Практическая часть. 16

Запуск и настройка системы. 16

Моделирование диаграмм производственных функций (business use case diagram) с использованием Rose. 18

«Описание документов при моделировании. 21

предметной области с использованием CASE-средства Rational Rose». 21

Теоретическая часть. 21

Разработка описания документов. 21

Практическая часть. 23

Запуск и настройка системы. 23

Описание документов. 23

Создание модели описания документов «Документы на заказ товара в магазины». 26

«Моделирование сценария поведения объектов предметной области при проектировании программных систем с использованием CASE-средства Rational Rose». 26

НЕ нашли? Не то? Что вы ищете?

Теоретическая часть. 26

Моделирование поведения сущностей реального мира. 26

Практическая часть. 29

Запуск и настройка системы. 29

Моделирование поведения объекта. 29

Список литературы.. 32


«Моделирование бизнес-процессов при проектировании программных систем с использованием CASE-средства Rational Rose»

Теоретическая часть.

Решаемая задача (формулировка и цель)

Цель работы - построение модели бизнес процессов для описания предметной области, подлежащей автоматизации, с использованием диа­граммы деятельности (activity diagram) CASE - средства Rational Rose 2001.

Введение

Процесс создания программных систем (ПС) по методологии разработки программных систем Rational Unified Process фирмы Rational Software Corporation включает следующие шесть этапов:

1.  Моделирование предметной области (Business Modeling);

2.  Определение требований к системе (Requirements);

3.  Анализ и проектирование (Analysis & Design);

4.  Разработку (Implementation);

5.  Тестирование (Test);

6.  Внедрение (Deployment).

Моделирование бизнес или, по-другому, производственных процессов для описания предметной области, для которой разрабатывается программная сис­тема, производится собственно на этапе разработке ПС моделирования пред­метной области (Business Modeling) с использованием диаграмм деятельности (activity diagram) CASE - средства Rational Rose 2001.

Описание бизнес процессов с использованием диаграммы деятельно­сти (activity diagramm)

Для описания бизнес процессов будем использовать следующие элемен­ты диаграммы деятельности (activity diagram):

-  начальное состояние (start state);

-  конечное состояние (end state);

-  деятельность (activity);

-  состояние (state);

-  переход (state transition);

-  решение (decision);

-  горизонтальные синхронизаторы (horizontal synchronization);

-  вертикальные синхронизаторы (vertical synchronization);

-  разделительные линии (swimlane);

-  объект (object);

-  поток объектов (object flow).

Начальное состояние (start state) обозначается черным маленьким круж­ком, с которым может быть связано название, например, «Точка начала».

Конечное состояние (end state) обозначается большим черным кружком внутри круга, с которым может быть связано название, например, «Точка конца».

Рис. 1. Пример начального (start state) и конечного состояния (end state).

Диаграмма деятельности (activity diagram) может иметь только одно начальное состояние. Конечных же состояний может существовать множество.

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

Деятельность (activity) обозначается прямоугольником с закругленными сторонами.

Рис. 2. Пример элемента «деятельность» (activity).

Элемент «деятельность» (activity) используется собственно для описания определенной деятельности субъекта или объекта. С этим элементом должно быть связано наименование. Наименование должно отражать цель деятельности. Деятельность именуется глаголом в настоящем времени. На диаграммах деятельности (activity diagram) элементы с одним и тем же именем используются для обозначения одного и того же вида деятельности.

С элементом «деятельность» (activity) могут быть связаны определенные действия, которые происходят на входе этого элемента, на выходе, внутри него или при наступлении определенного события. Действия можно добавить к элементу «деятельность» (activity) при использовании спецификации.

Действие может быть описано в форме свободного текста.

 

Рис. 3. Пример элемента «деятельность» (activity) с действиями по наступлению события, на входе, выходе и внутри элемента.

Состояние (state) обозначается прямоугольником с закругленными углами.

 

Рис. 4. Пример элемента «состояние» (state).

Элемент «состояние» (state) используется для описания определенных состояний какого-либо субъекта или объекта, например состояния ожидания. С этим элементом должно быть связано имя. Имя должно отражать состояние субъекта или объекта. С элементом «состояние» (state) могут быть также связаны определенные действия, которые происходят на входе этого элемента, на выходе, внутри него или при наступлении определенного события. Действия можно добавить к элементу «состояние» (state) при использовании спецификации.

Переход (state transition) используется для описания связи между элементами диаграммы «деятельность» (activity), «состояние» (state). Переход (state transition) обозначается сплошной линией со стрелкой. Стрелка указывает на следующее действие или состояние.

 

Рис. 5. Пример элемента «переход» (state transition).

Переход (state transition) может иметь имя, связанное с событием, его вызвавшим. Событием называется любое происшествие, которое может быть причиной изменения состояния субъекта или объекта, или перехода от одного вида деятельности к другому виду. События могут вызывать некоторые действия. Одному событию соответствует ровно одно действие.

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

Для отображения действий, выполняемых по условию, используется элемент решение (decision). Элемент решение (decision) обозначается в виде ромба.

 

Рис. 6. Пример элемента «решение» (decision).

Разделительные линии (swimlane) используются для разделения диа­граммы на части, например, с целью отражения на диаграммах, ответственных за выполнение определенных действий.

Рис. 7. Пример разделительных линий (swimlane).

Синхронизаторы (synchronization) используются для отражения выполнения параллельной деятельности.

Принципы Case-технологий разработки ИС

Методологии, технологии и инструментальные средства проектирования (CASE-средства) составляют основу проекта любой ИС. Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов ЖЦ.

Технология проектирования определяется как совокупность трех составляющих:

·  пошаговой процедуры, определяющей последовательность технологических операций проектирования;

·  критериев и правил, используемых для оценки результатов выполнения технологических операций;

·  нотаций (графических и текстовых средств), используемых для описания проектируемой системы.

Рис. 9. Представление технологической операции проектирования

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

Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованиям:

- технология должна поддерживать полный ЖЦ ПО;

- технология должна обеспечивать гарантированное достижение целей разработки ИС с заданным качеством и в установленное время;

- технология должна обеспечивать возможность выполнения крупных проектов в виде подсистем (т. е. возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности с последующей интеграцией составных частей). Опыт разработки крупных ИС показывает, что для повышения эффективности работ необходимо разбить проект на отдельные слабо связанные по данным и функциям подсистемы. Реализация подсистем должна выполняться отдельными группами специалистов. При этом необходимо обеспечить координацию ведения общего проекта и исключить дублирование результатов работ каждой проектной группы, которое может возникнуть в силу наличия общих данных и функций;

- технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек). Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей;

- технология должна обеспечивать минимальное время получения работоспособной ИС. Речь идет не о сроках готовности всей ИС, а о сроках реализации отдельных подсистем. Реализация ИС в целом в короткие сроки может потребовать привлечения большого числа разработчиков, при этом эффект может оказаться ниже, чем при реализации в более короткие сроки отдельных подсистем меньшим числом разработчиков. Практика показывает, что даже при наличии полностью завершенного проекта, внедрение идет последовательно по отдельным подсистемам;

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

- технология должна обеспечивать независимость выполняемых проектных решений от средств реализации ИС (систем управления базами данных (СУБД), операционных систем, языков и систем программирования);

- технология должна быть поддержана комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ. Реальное применение любой технологии проектирования, разработки и сопровождения ИС в конкретной организации и конкретном проекте невозможно без выработки ряда стандартов (правил, соглашений), которые должны соблюдаться всеми участниками проекта.

К таким стандартам относятся следующие:

- стандарт проектирования;

- стандарт оформления проектной документации;

- стандарт пользовательского интерфейса.

Стандарт проектирования должен устанавливать:

- набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации;

- правила фиксации проектных решений на диаграммах, в том числе: правила именования объектов (включая соглашения по терминологии), набор атрибутов для всех объектов и правила их заполнения на каждой стадии, правила оформления диаграмм, включая требования к форме и размерам объектов, и т. д.;

- требования к конфигурации рабочих мест разработчиков, включая настройки операционной системы, настройки CASE-средств, общие настройки проекта и т. д.;

- механизм обеспечения совместной работы над проектом, в том числе: правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии (регламент обмена проектной информацией, механизм фиксации общих объектов и т. д.), правила проверки проектных решений на непротиворечивость и т. д.

Стандарт оформления проектной документации должен устанавливать:

- комплектность, состав и структуру документации на каждой стадии проектирования;

- требования к ее оформлению (включая требования к содержанию разделов, подразделов, пунктов, таблиц и т. д.),

- правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков для каждой стадии;

- требования к настройке издательской системы, используемой в качестве встроенного средства подготовки документации;

- требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями.

Стандарт интерфейса пользователя должен устанавливать:

правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;

- правила использования клавиатуры и мыши;

- правила оформления текстов помощи;

- перечень стандартных сообщений;

- правила обработки реакции пользователя.

Практическая часть

Описание работы с CASE-средством Rational rose 2001 при моделировании бизнес процессов

Запуск и настройка системы

Запуск Rational Rose (Rose) производится из меню Пуск Microsoft Windows (Программы>Rational Rose Enterprise Edition=> Rational Rose Enterprise Edition).

При запуске Rose на экран выводится окно шаблонов.

Рис. 10. Окно шаблонов.

Нажмите кнопку «Cancel» для отмены их ввода. На экране появляется окно с диаграммой клас­сов.

Диаграмма бизнес деятельности должна создаваться в окне просмотра в разделе Use Case View.

Щелкните по пакету Use Case View в окне просмотра, выберите из поя­вившегося меню пункт New, а затем из вновь появившегося меню пункт Activ­ity Diagram. В окне просмотра появится поле NewDiagram.

В поле с именем NewDiagram введите наименование диаграммы бизнес деятельности (activity diagram). Далее щелкните правой клавишей мыши по наименованию диаграммы и выберите команду Open. На экране появится окно рисования диа­граммы деятельности (activity diagram).

Моделирование диаграмм бизнес процессов

Моделирование диаграмм бизнес процессов с использованием Rose должно включать рисование:

1.  Разделительных линий;

2.  Начального состояния;

3.  Деятельностей (состояний), если требуется решений, синхронизаторов;

4.  Переходов соединяющих деятельности (состояния);

5.  Конечных состояний;

6.  Декомпозицию отдельных видов деятельности

Рисование элементов диаграммы деятельности должно производиться следующим об­разом.

Щелкните по иконке с изображением разделительной линии (swimlane) на панели инструментов. Щелкните мышью в окне рисования диаграммы в месте, где должно находиться изображение разделительной линии (swimlane) Повторяйте эти действия до тех пор, пока четыре разделительные линии (swimlane) не будут размещены на поле диаграммы.

Рис. 12. Пример разделительной линии.

Поименуйте первую разделительную линию, как «документы», вторую как - «действия», третью как - «подразделения», четвертую как - «сотрудни­ки».

Для этого щелкните правой клавишей мыши по заголовку разделительной линии (swimlane), например, «New Swimlane», и в появившемся меню выбери­те пункт Open Specification. В окне спецификации разделительной линии на вкладке General в поле Name внесите название линии, например, «докумен­ты».

Рис. 13. Поименование разделительной линии.

Аналогично именуются остальные разделительные линии.

Рисование элементов диаграммы «деятельность», «состояние», в том числе «начальное» и «конечное состояние», решение, синхронизаторы, производиться следующим образом.

Щелкните по иконке с изображением требуемого элемента диаграммы на панели инструментов.

Щелкните мышью в окне рисования диаграммы в месте, где должно находиться изображение выбранного элемента.

В нашей диаграмме использовалось одно «начальное» и одно «конечное состояние». Чтобы создать «начальное состояние» необходимо нажать кнопку нажать иконку (start state) и щелкнуть мышкой в нужном месте окна рисования диаграммы, а затем, через правую кнопку мыши, в поле Name написать название «Пополнение ассортимента».

Рис. 15. Поименование начального состояния.

Для создания «конечного состояния» необходимо нажать иконку (end state) и щелкнуть в нужном месте окна рисования. Именуется «конечное состояние» через правую кнопку мыши.

В итоге получаем:

Рис. 16. Начальное и конечное состояния.

Чтобы создать необходимые нам диаграммы «состояния», нужно нажать на иконку (state) и щелкнуть в нужном месте окна. Имя данной диаграмме присваивается через правую кнопку мыши в поле Name.

В результате данных действий получаем:

Рис. 17. Элемент «состояние» с именем «Ожидает привоз заказа».

Для создания диаграммы «деятельность» щелкаем на панели инструментов на иконку (activity). Далее подводим к нужному месту в окне рисования и, щелкнув мышкой, устанавливаем там диаграмму «деятельности».

Чтобы дать этой диаграмме имя, нажимаем на правую кнопку мыши и в поле Name прописываем имя.

Получаем диаграмму «деятельности» с именем «Делает заказ в издательство».

Аналогично строятся остальные диаграммы «деятельности» с именами «Получает книги от издательства», «Относит книги на склад», «Регистрирует книги в Базе Данных», «Привозит книги в магазин», «Определяет цену книг», «Регистрирует товар в Базе Данных», «Наклеивает ценники на книги», «Расставляет товар по полкам».

Для того чтобы создать наименование документов, подразделений, сотрудников щелкните по иконке с изображением заметки (note). Затем щелкните мышью в окне рисования диаграммы в месте, где должно находиться изображение выбранного элемента.

Именование документа производится в окне спецификации в поле Name.

Аналогично создаются документы «Накладная на привоз товара», «Приемный акт для издательства», «Приемный акт для склада», «Накладная на полученный товар», «Приемный акт магазина», «Накладная на запрашиваемый товар», «Процентная ставка».

По той же аналогии создаются подразделения: «Отдел заказов», «Склад», «Бухгалтерия», «Магазин», а также действующие лица: «Менеджер по закупкам», «Снабженец», «Кладовщик», «Оператор Базы Данных», «Бухгалтер», «Продавец».

Рисование перехода должно производиться следующим образом. Щелк­ните по иконке с изображением перехода (Anchor Note to Item) на панели инструментов. Соедините требуемые элементы диаграммы переходом.

Как уже говорилось именование элементов диаграммы должно производиться в окне специ­фикации в поле Name.

Вызов окна спецификации производиться по двойному щелчку левой клавишей мыши по элементу диаграммы. А краткое описание элемента диаграммы можно производить в окне специ­фикации элемента диаграммы на вкладке General в разделе Documentation.

Рис. 22. Окно спецификации.

Декомпозиция отдельных видов деятельности должна производиться сле­дующим образом.

Щелкните правой кнопкой мыши по деятельности, которую следует де­композировать, и в появившемся меню выберите пункт Select in Browser. В ок­не просмотра щелкните по деятельности правой кнопкой мыши и в появившем­ся меню выберите пункт меню New, а затем во вновь появившемся меню пункт Activity Diagram. Задайте наименование диаграммы, а затем откройте диа­грамму.

Определение автоматизируемых бизнес процессов

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

Пометка производится следующим образом. Щелкните правой кнопкой мыши по деятельности. В появившемся меню выберите пункт Format. Далее в появившемся меню выберите пункт Fill Color. Из палитры выберите требуемый цвет. Нажмите кнопку ОК.

Порядок выполнения работы

·  Включите компьютер.

·  Запустите Rose, руководствуясь 1 пунктом 2 части.

·  Настройте Rose, руководствуясь 1 пунктом 2 части.

·  Постройте модель производственной деятельности в соответствии с выбранной темой (рис. 24) , руководствуясь 2 пунктом 2 части.

·  Выделите в модели каким-либо цветом виды деятельности, которые
будут автоматизированы, руководствуясь 3 пунктом 2 части.

В результате мы получили такую диаграмму деятельности для описания бизнес процесса «Пополнение ассортимента магазина».

Рис. 24. Пример диаграммы деятельности для описания бизнес процессов.

В данной лабораторной работе мы построили модель пополнения ассортимента книжного магазина, которая должна быть автоматизирована. Для построения модели мы использовали диаграмму деятельности Case-средства Rational Rose.

В диаграмме деятельности мы выделили 4 области – Документы, Действия, Подразделения и Действующие лица. Для этого мы использовали Разделительные линии.

Последовательность действий такова: если книжный магазин хочет пополнить свой ассортимент (подтверждением этого является бланк заказа, отосланный в издательство менеджером по закупкам), то издательство привозит книги в магазин, вместе с накладной на приём товара. Затем снабженец получает книги, а кладовщик относит их на склад. При этом оформляются накладная на приём товара, приёмный акт для издательства и приёмный акт для склада. На складе оператор Базы данных регистрирует полученные книги с помощью накладной на полученный товар. Если из магазина поступил запрос на привезённые книги, то снабженец приносит нужные книги в магазин и оформляется приёмный акт магазина. Далее бухгалтер определяет цену книг с помощью процентной ставки, оператор Базы Данных регистрирует полученный товар в базе Данных магазина на основе накладной на запрашиваемый товар и, наконец, продавец клеит ценники и расставляет книги по полкам.

На рис. 24 представлен пример диаграммы деятельности для описания технологии пополнения ассортимента книжного магазина.

На рис. 24 изображены подразделения - склад, магазин и бухгалтерия – и бизнес процессы, которые следует автоматизировать.

Бизнес процессы – это:

1.  делает заказ в издательство;

2.  получает книги от издательства;

3.  регистрирует книги в Базе Данных склада;

4.  регистрирует товар в Базе Данных магазина

5.  определяет цену на книги.

При описании документооборота при пополнении ассортимента книжного магазина должны быть детально рассмотрены и описаны следующие документы:

1.  бланк заказа;

2.  накладная на привоз товара;

3.  приемный акт для издательства;

4.  приемный акт для склада;

5.  накладная на полученный товар;

6.  накладная на запрашиваемый товар;

7.  приемный акт магазина;

8.  процентная ставка магазина.

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

«Моделирование бизнес-функций предметной области при проектировании программных систем с использованием CASE-средства Rational Rose»

Теоретическая часть.

Решаемая задача (формулировка и цель)

Цель работы - построение модели бизнес-функций (business use case model) для описания предметной области, подлежащей автоматизации, с использованием диаграммы функций (use case diagram) CASE - средства Rational Rose 2001.

Моделирование предметной области

Целями моделирования бизнес-функций предметной области являются:

·  Понимание структуры и динамики поведения автоматизируемой организации заказчиками, конечными пользователям, и разработчикам автоматизированных систем;

·  Определение требований к автоматизированной системе, поддерживающей работу организации.

Модель бизнес-функций (business use case model) определяется как иерархия диаграмм.

Первый уровень иерархии должен включать одну или несколько организационных единиц (organization unit) - например, предприятие, подлежащее автоматизации.

Последующие уровни иерархии могут включать также одну или несколько организационных единиц (organization unit), например, это могут быть подразделения автоматизируемого предприятия. Или могут включать действующих лиц производственного процесса: субъектов (business worker) и объектов (business actor), их производственные функции (business use case), связи (relationships) между действующими лицами и их функциями и между функциями.

Отдельные бизнес функции также могут быть декомпозированы моделями бизнес функций (business use case model), включающими исключительно действующих лиц производственного процесса, их функции, связи между действующими лицами и их функциями и между функциями. Организационные единицы в моделях, декомпозирующих функции отражаться не должны.

Модель бизнес функций строится с использованием диаграммы функций (use case diagram).

Для изображения организационных единиц (organization unit) на диаграммах функций (use case diagram) используется изображение следующего вида:

Рис. 1. Изображение организационных единиц (organization unit) на диаграммах функций (use case diagram)

Действующее лицо - субъект производственного процесса (business worker) обозначается на диаграммах функций (use case diagram) как представлено на рис. 2.

Рис. 2. Изображение субъекта производственного процесса (business worker) на диаграммах функций (use case diagram)

Действующее лицо - объект (business actor) производственного процесса - как представлено на рис. 3.

Рис. 3. Изображение объекта производственного процесса (business actor) на диаграммах функций (use case diagram)

Изображение объекта производственного процесса также можно использовать и для обозначения субъекта производственного процесса.

Под изображением действующего лица указываются его наименование. Наименование действующего лица есть роль, которую он выполняет в производственном процессе, например, менеджер по закупкам (business worker), автоматизированная система закупка книг (business actor).


Рис. 4. Изображение действующего лица с его наименованием (business worker) в автоматизированной системе (business actor) на диаграммах функций (use case diagram)

Бизнес-функции или функции производственного процесса (business use case) изображаются на диаграммах функций (use case diagram) как овал следующего вида (рис.5):

Рис. 5. Изображение бизнес или производственной функции (business use-case) на диаграммах функций (use case diagram)

Декомпозированные бизнес функции или функции производственного процесса (business use case realization) изображаются на диаграммах функций (use case diagram) как пунктирный овал, представленный на рис.6.

Рис. 6. Изображение декомпозированной бизнес или производственной функции (business use-case realization) на диаграммах функций (use case diagram)

Под овалом указывается имя функции.

Имя функции может включать неформальное описание последовательности действий.

Выписка приемного акта
 

Рис. 7. Изображение декомпозированной бизнес или производственной функции с именем, включающим описание действий (business use-case realization) на диаграммах функций (use case diagram)

Также в диаграмме бизнес-функций используется деловой объект (business entity), который является пассивным, то есть не производит самостоятельно никаких действий. Он может использоваться при любой деловой деятельности и обычно переживает одно единственное взаимодействие. Деловой объект может совместно использоваться действующими лицами, участвующими в различных процессах.

Рис. 8. Изображение декомпозированной бизнес или производственной функции с именем, включающим описание действий (business entity) на диаграммах функций (use case diagram)

Связи на диаграммах бизнес или производственных функций (business case diagram) имеют место:

1.  Между организационными единицами;

2.  Между действующим лицом и функцией;

3.  Между функциями.

На диаграммах производственных функций (business use case diagram) допускается отражать и связи между действующими лицами.

Рис. 9. Изображение связи между действующими лицами (unidirectional association) на диаграммах функций (use case diagram)

Между организационными единицами может иметь место связь, которая является зависимостью. Связь обозначается прерывистой линией со стрелкой. Связь должна проводится от зависимой организационной единицы к независимой. Связь может быть двусторонней.

Рис. 10. Изображение связи, обозначающей зависимость между организационными единицами (dependency or instantiates) на диаграммах функций (use case diagram)

Между действующим лицом производственного процесса (business worker или business actor) и функцией устанавливается связь, которая называется ассоциацией.

Рис. 11. Изображение связи ассоциации между действующим лицом производственного процесса и его функцией (unidirectional association) на диаграммах функций (use case diagram)

Связь отражает наличие определенной функции у действующего лица. Связь обозначается сплошной линией со стрелкой или без нее. В двойных скобках «» может указывается стереотип связи, например, «communicates» (взаимодействует).

На диаграммах производственных функций могут также используются и другие типы связей. Например, между функциями могут существовать связи типа «include» (использует) и «extends» (расширяет).

То есть, некоторые функции в системе могут использовать другие функции. Некоторые функции могут выполняться при наступлении определенных условий или быть опциональными. В первом случае используются связь «include», во втором случае - «extends».

Связи «include» и «extends» по нотации RUP обозначают прерывистой линией со стрелкой, рядом с которой указан стереотип. Для связи «include» стрелка направлена к функции, которую используют.

Рис. 12. Изображение связи использования между функциями, которая выполняется при наступлении определенных условий (dependency or instantiates include) на диаграммах функций (use case diagram)

Для связи «extends» стрелка направлена к функции, которая включает функцию, используемую опционально или по наступлению определенного условия.

Рис. 13. Изображение связи расширения между функциями, которые выполняются опционально (dependency or instantiates extends) на диаграммах функций (use case diagram)

Практическая часть.

Запуск и настройка системы.

Запуск Rational Rose (Rose) производится из меню Пуск Microsoft Windows (Программы>Rational Rose Enterprise Edition=> Rational Rose Enterprise Edition).

При запуске Rose на экран выводится окно шаблонов.

Рис. 14. Изображение окна шаблонов при запуске системы.

Нажмите кнопку «Cancel» для отмены их ввода. На экране появляется окно с диаграммой клас­сов.

Диаграмма бизнес деятельности должна создаваться в окне просмотра в разделе Use Case View.

Щелкните по пакету Use Case View в окне просмотра, выберите из поя­вившегося меню пункт New, а затем из вновь появившегося меню пункт Use Case Diagram. В окне просмотра появится поле NewDiagram Activity Diagram.

В поле с именем New Diagram введите наименование диаграммы произ­водственных функций. Далее щелкните правой клавишей мыши по наименова­нию диаграммы и выберите команду Open. На экране появится окно рисования диаграммы функций (diagram: use case diagram view).

В меню Tools выберите пункт Options... На вкладке Generel задайте шрифты с кириллицей.

Для рисования диаграмм производственных функций можно использо­вать диаграмму use case с именем Main. Для этого щелкните по изображению «+» рядом с пакетом Use Case View левой клавишей мыши в окне просмотра. Далее щелкните правой клавишей мыши по пиктограмме с изображением диа­граммы с именем Main и выберите команду Open. Окно для рисования диа­грамм готово.

Диаграмму с именем Main можно переименовать. Щелкните пра­вой клавишей мыши по пиктограмме с изображением диаграммы с именем Main и выберите команду Rename. Введите новое наименование диаграммы. Также можно и нужно добавить дополнительные иконки на панель инструментов. Для этого щелкните по панели инструментов два раза, и на экране появится окно настраиваемой панели инструментов следующего вида:

Рис. 16. Окно настраиваемой панели инструментов.

Из имеющихся иконок в окне слева выберите необходимые для дальнейшего использования при построении иконки, нажмите кнопку добавить. В окне панели инструментов появится выбранная иконка. После добавления всех необходимых кнопок нажмите кнопку закрыть.

Моделирование диаграмм производственных функций (business use case diagram) с использованием Rose.

Если на диаграмме требуется разместить какой-либо текст, то исполь­зуйте иконки на панели инструментов с изображением заметки (Note), и текста (TextBox) .

Если на главной диаграмме необходимо разместить действующее ли­цо, щелкните по иконке с изображением работника (business worker) или акте­ра (business actor) на панели инструментов. В нашей диаграмме бизнес-функции закупка книг в магазин всего одно действующее лицо – менеджер по закупкам.

Щелкните мышью в окне рисования диаграммы в месте, где должно находиться изображение действующего ли­ца. Повторяйте эти действия до тех пор, пока все действующие лица не будут размещены на поле диаграммы.


Рис. 17. Действующее лицо менеджер по закупкам для диаграммы бизнес-функции закупка книг в магазин.

Краткое описание действующего лица можно производить в окне специ­фикации действующего лица на вкладке General в разделе Documentation. Ок­но спецификации действующего лица вызывается по двойному щелчку по дей­ствующему лицу.

Если на главной диаграмме необходимо разместить функцию дейст­вующего лица (business use case), щелкните по иконке с изображением функ­ции (business use case) на панели инструментов. В нашей диаграмме всего одна функция действующего лица – составление бланка заказа.

Щелкните мышью в окне ри­сования диаграммы в месте, где должно находиться изображение функции. Если необходимо, повторяйте эти действия до тех пор, пока все функции не будут размещены на по­ле диаграммы.

 

Рис. 19. Функция действующего лица – составление бланка заказа, для диаграммы бизнес-функции закупка книг в магазин.

Краткое описание функции можно производить в окне спецификации функции на вкладке General в разделе Documentation. Окно спецификации функции вызывается по двойному щелчку по функции. Такое поименование было проиллюстрировано для присваивания имени действующему лицу. Функция действующего лица именуется аналогично.

Детальное описание функции можно производить с использованием ре­дактора Word. Файлы с детальным описанием можно подключить к специфи­кации функции.

При построении ассоциативной связи между действующим лицом и функцией выберите иконку с изображением ассоциативной связи на панели ин­струментов. Если требуемой иконки на панели инструментов нет, ее можно вы­брать из настраиваемой панели инструментов. Соедините действующее лицо с функцией.


Рис. 20. Ассоциативная связь между действующим лицом менеджер по закупкам и функцией действующего лица – составление бланка заказа.

Для того чтобы добавить стереотип к связи, щелкните по связи два раза. На экране появится окно спецификации связи.

На вкладке General спецификации связи в поле Stereotype занесите вруч­ную стереотип связи, или если стереотип связи уже существует, выберите его из выпадающего меню. Закройте окно спецификации.

При построении связей использования «include» или расширения «extends» между функциями выберите иконку с изображением связи Generalization на панели инструментов. Если требуемой иконки на панели ин­струментов нет, ее можно выбрать из настраиваемой панели инструментов.

Соедините две функции. Проведите связь от функции, которая использует другую функцию, к используемой функции, или от функции, которая выполня­ется по условию к функции, которая ее использует. Добавьте стереотип связи. В нашей диаграмме бизнес-функции данный вид связи не используется.

Порядок выполнения работы

1.  Включите компьютер.

2.  Запустите Rose.

3.  Настройте Rose.

4.  Постройте модель предметной области в соответствии с примером
представленном на рисунке 22.

5.  Выделите в модели каким-либо цветом функции, которые будут авто­матизированы: составление бланка заказа, выписка приемного акта, регистрация в базе данных.

Рис. 22. Пример построение модели бизнес-функций (business use case model) закупка книг в магазин для описания предметной области, подлежащей автоматизации, с использованием диаграммы функций (use case diagram) CASE - средства Rational Rose 2001.

В данной лабораторной работе построена модель закупки книг для магазина, которую надо автоматизировать, с использованием диаграммы функций. Следует автоматизировать следующие функции: составление бланка заказа, выписка приемного акта, регистрация в базе данных. Во всех этих функциях объектом производственного процесса является менеджер по закупкам. Составление, выписка, регистрация являются производственными процессами. При этом выписка и регистрация являются декомпозированными производственными процессами. Субъектами производственной функции являются бланк заказа, накладная на привезенный товар, приемный акт для издательства, накладная для склада, приемный акт для склада, накладная для магазина.

«Описание документов при моделировании

предметной области с использованием CASE-средства Rational Rose»

Теоретическая часть.

Решаемая задача (формулировка и цель)

Цель работы - разработать описание документов при моделировании предметной области, подлежащей автоматизации, для использования их при проектировании входных/выходных форм, баз данных (БД), пользовательского интерфейса программных систем с использованием диаграммы классов (class diagram) CASE - средства Rational Rose 2001.

Разработка описания документов

Целью описания документов является создание описания документов такой степени подробности, которая позволила использовать это описание при проектировании пользовательского интерфейса программных систем, баз данных (БД), выходных форм.

Для создания описания документов используется компоненты:

·  диаграммы классов (class diagram);

·  производственная сущность (business entity);

·  ассоциативная связь (association);

·  связи агрегация (agregation);

·  наследование (generalization).

Производственная сущность (business entity) представляет абстракцию сущности реального мира.

Пример изображения производственной сущности (business entity) на диаграммах классов представлен на рис. 1

Рис.1. Изображение декомпозированной бизнес или производственной функции с именем, включающим описание действий (business entity) на диаграммах функций (use case diagram).

Примерами производственной сущности могут являться:

·  бланк заказа;

·  приёмный акт;

·  накладная на привезённый товар и т. п.

Производственные сущности (business entity) могут иметь атрибуты. Ассоциативная связь (association) между производственными сущностями (business entity) есть смысловая связь. Связь не объясняет, как сущности общаются друг с другом, отмечается только смысловая зависимость между ними. Ассоциативная связь (association) изображается на диаграмме классов сплошной прямой линией как представлено на рис. 2.

РРис.2. Пример ассоциативной связи (association) между производственными сущностями (business entity).

Ассоциативная связь (association) может быть поименована. Имя ассоциации обозначается глаголом, например, учит, управляет. Рекомендуется указывать имя ассоциации так, чтобы оно читалось корректно слева направо или сверху вниз.

Количество сущностей, принимающих участие в связи, называется мощностью связи. Мощность указывается на каждом конце ассоциативной связи. Мощность означает число связей между одной производственной сущностью в начале линии связи с производственными сущностями в конце линии связи.

Мощность может обозначаться следующим образом:

1 - точно одна производственная сущность;

0...* - ноль или больше производственных сущностей;

1..*- одна или больше производственных сущностей;

ноль или одна производственная сущность;

5..8 - специфический диапазон 5,6,7,8;4..7, 9 - комбинация 4,5,6,7, или 9 производственных сущностей.

Связь «агрегация» (aggregation) обозначает связь часть целого (part of). При этом часть может существовать без целого. Например, пакет документов включает бланк заказа, накланые на товар, приемные акты на товар. Агрегация есть частный случай ассоциации.

Агрегация (aggregation) изображается сплошной прямой линией с добавлением на конце не закрашенного ромба как представлено на рис. 3. Незакрашенный ромб указывает на целое.

Рис. 3. Пример агрегации (aggregation) между бизнес сущностями.

Существует еще один вид агрегации (aggregation), который называется композицией (composite aggregation). Композиция также обозначает связь часть-целое (part of), нo при этом часть не может существовать без целого. Например, бланк заказа включает заголовок, строки и подписи заказа.

Композиция (composite aggregation) изображается сплошной прямой линией с добавлением на конце закрашенного ромба как представлено на рис. 4. Закрашенный ромб указывает на целое.

Рис. 4. Пример композиции (composite aggregation) между бизнес сущностями.

Наследование (generalization) между производственными сущностями - это такое отношение между ними, когда одна производственная сущность повторяет структуру другой производственной сущности (одиночное наследование) или других сущностей (множественное наследование).

Так как наследование (generalization) не является связью между разными сущностями, она может не именоваться, на ней также не указывается мощность.

На диаграммах классов наследование (generalization) изображается стрелкой с незакрашенным треугольником, обращенным к сущности, от которой наследуются свойства. Для объединения производственных сущностей, сходных по назначению, на диаграммах классов используется изображение организационной единицы (organization unit). Пример организационной единици приведен на рис.5.

Рис. 5. Изображение организационных единиц (organization unit) на диаграммах классов (class diagram).

Архитектура диаграммы классов при описании документов может иметь вид: на первом уровне диаграммы классов отображается организационная единица (organization unit) с наименованием: первичных документов отдела и наименованием отдела. На втором уровне (внутри организационной единицы первичных документов и наименования отдела) организационные единицы с наименованиями Документ 1, Документ 2, ... Документ N, например, входящие письма, распоряжения, исходящие письма и т. п. На третьем уровне (внутри организационной единицы «Документ») должны отображаться собственно документы, например, наклалная на полученный товар.

Практическая часть.

Запуск и настройка системы.

Запуск Rational Rose (Rose) производится из меню Пуск Microsoft Windows (Программы>Rational Rose Enterprise Edition=> Rational Rose Enterprise Edition).

Описание документов должна создаваться в окне просмотра в разделе Use Case View.

Щелкните по пакету Use Case View в окне просмотра, выберите из появившегося меню пункт New, а затем из вновь появившегося меню пункт Use Case Diagram. В окне просмотра появится поле New Diagram.

В поле с именем New Diagram введите наименование диаграммы классов, например, «Документы на заказ товара в магазины». Далее щелкните правой клавишей мыши по наименованию диаграммы и выберите команду Open. На экране появится окно рисования диаграммы деятельности (class diagram).

В меню Tools выберите пункт Options... На вкладке Generel задайте шрифты с кириллицей.

Можно и нужно добавить дополнительные иконки на панель инструментов. Для этого щелкните по панели инструментов два раза, и на экране появится окно настраиваемой панели инструментов следующего вида:

Рис. 7. Окно настраиваемой панели инструментов.

Из имеющихся иконок в окне слева выберите необходимые для дальнейшего использования при построении иконки, нажмите кнопку добавить. В окне панели инструментов появится выбранная иконка. После добавления всех необходимых кнопок нажмите кнопку закрыть.

Описание документов

Описание документов должно включать следующие шаги:

1.  Проектирование диаграммы верхнего уровня («Первичные документы
отдела «Наименование отдела»»);

2.  Проектирование диаграммы следующего уровня (организационные единицы с наименованиями Документ 1, Документ 2, ..., ДокументN);

3. Проектирование диаграмм с отдельными документами.

Щелкните по иконке с изображением организационной единицы (organization unit) на панели инструментов. Щелкните мышью в окне рисования диаграммы в месте, где должно находиться изображение организационной единицы (organization unit).

Далее дважды щелкните левой клавишей мыши по изображению организационной единицы (organization unit). На экране появится поле для рисования организационных единиц следующего уровня.

Снова щелкните по иконке с изображением организационной единицы (organization unit) на панели инструментов. Щелкните мышью в окне рисования диаграммы в месте, где должно находиться изображение организационной единицы (organization unit).

Повторяйте эти действия до тех пор, пока все организационные единицы (organization unit) не будут размещены на поле диаграммы.

Далее дважды щелкните левой клавишей мыши по изображению какой-либо организационной единицы (organization unit). На экране появится поле для рисования организационных единиц последующего уровня. Затем щелкните по иконке с изображением производственной сущности (business entity) на панели инструментов. Щелкните мышью в окне рисования диаграммы в месте, где должно находиться изображение производственной сущности (business entity). Повторяйте эти действия до тех пор, пока все производственной сущно­сти (business entity) не будут размещены на поле диаграммы организационной единицы (organization unit).

Если требуется, соедините производственные сущности (business entity) связями. Пример приводится на рис.8.

РРис. 8. Пример ассоциативной связи (association) между производственными сущностями (business entity).

При построении связи между сущностями, выберите на панели инстру­ментов иконку с изображением соответствующей связи. Соедините связью тре­буемые производственные сущности.

Поименуйте все организационные единицы (organization unit) и произ­водственные сущности (business entity).

Для этого щелкните правой клавишей мыши по изображению организационной единицы или сущности и в появившемся меню выберите пункт Open Specification. В окне спецификации на вкладке General в поле Name внесите название организационной единицы или производственной сущности.

Далее определите атрибуты производственных сущностей (business entity).

Определение атрибутов производится следующим образом.

В окне спецификации производственной сущности выберите вкладку Attributes. Щелкните правой клавишей мыши по белому полю на вкладке и в появившемся меню выберите пункт Insert. Щелкните правой клавишей по появившейся новой строке в списке атрибутов, а затем в меню выберите пункт Specification. На экране появится окно спецификации атрибута.

Поле спецификации Name используется для написания имени атрибута. Поле Class определяет, где определен атрибут. Поле спецификации Туре ис­пользуется для описания типа атрибута, Stereotype - описания стереотипа ат­рибута, поле Initial value - для задания начального значения атрибута, Docu­mentation - документирования.

При описании документа должен быть включен переключатель Public.

Краткое описание производственной сущности (business entity) можно производить в окне спецификации сущности на вкладке General в поле Documentation.

Прочий текст на диаграммах можно разместить с использованием иконки на панели инструментов с изображением заметки (Note), и текста (TextBox).


Рис. 9. Пример окна спецификации (Open Specification) с именем атрибута.

Изображение заметки может крепиться к любому элементу диаграммы с ис­пользованием специальной линии Anchor Note to Decision Item.

Детальное описание производственной сущности (business entity) можно производить с использованием редактора Word. Файлы с детальным описанием можно подключить к спецификации производственной функции (business entity).

Для включения описания производственной сущности (business entity) в редакторе Word в спецификацию следует:

1.  Выбрать закладку File в окне спецификации;

2.  Щелкнуть правой кнопкой по внутренней части окна;

3.  В появившемся меню выбрать пункт Insert File;

4.  В окне просмотра файлов выбрать требуемый файл;

5.  Нажать кнопку Open;

6.  Нажать кнопку ОК в окне спецификации.

Рекомендуется при описании документов в файл, подготовленный в ре­дакторе Word, включать изображение описываемого документа.

Создание модели описания документов «Документы на заказ товара в магазины»

Порядок выполнения работы.

1.  Включите компьютер.

2.  Запустите Rose.

3.  Настройте Rose.

4.  Постройте описание документа в соответствии с примером, представленном на рис.11.

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

Рис. 11. Пример построение модели описания документов (business use case model), подлежащих автоматизации, с использованием диаграммы функций (use case diagram) CASE - средства Rational Rose 2001.«Документы на заказ товара в магазины»

В данной лабораторной работе построена модель описания документов, необходимых для заказа книг в магазины, которые надо автоматизировать, с использованием диаграммы классов (class diagram).

. Следует автоматизировать следующие документы: составление бланка заказа, выписка приемного акта, регистрация в базе данных. Во всех этих функциях объектом производственного процесса является менеджер по закупкам. Была составлена структура автоматизируемого документа «Бланк заказа книг», который состоит из заголовка, строк, подписи и примечания.

«Моделирование сценария поведения объектов предметной области при проектировании программных систем с использованием CASE-средства Rational Rose»

Теоретическая часть

Решаемая задача (формулировка и цель)

Цель работы – описать поведение сущностей реального мира (объектов) при моделировании предметной области, подлежащей автоматизации, с использованием диаграммы состояний (statechart diagram) CASE - средства Rational Rose 2001.

Моделирование поведения сущностей реального мира

При моделировании поведения сущностей реального мира с использованием диаграмм состояний (statechart diagram) показываются состояния сущности, события, которые влекут за собой переход из одного состояния в другое, действия, которые происходят при изменении состояния.

Диаграммы состояний (statechart diagram) включают следующие элементы:

·  начальное состояние (start state);

·  конечное состояние (end state);

·  состояние (state);

·  переход (state transition).

Начальное состояние (start state) обозначается черным маленьким кружочком, с которым может быть связано название «Начало».

Конечное состояние (end state) обозначается большим чёрным кружком внутри круга, с которым может быть связано название «Конец».

Пример начального (start state) и конечного (end state) состояний представлен на рисунке 1.

Рис. 1. Пример начального (start state) и конечного (end state) состояний.

Каждая диаграмма состояний (statechart diagram) должна иметь только одно начальное состояние (start state). Конечных же состояний (end state) может существовать множество.

Состояние (state) обозначается прямоугольником с закругленными углами. Пример элемента состояния (state) представлен на рисунке 2.

Рис. 2. Пример элемента состояние (state).

Элемент состояние (state) используется собственно для описания определённых состояний какого-либо субъекта или объекта, например, состояния ожидания. С этим элементом должно быть связано имя. Имя должно отражать состояние субъекта или объекта.

С элементом состояние (state) могут быть также связаны определённые действия, которые происходят на входе этого элемента, на выходе, внутри него или при наступлении определённого события. Действие можно добавить к элементу состояния (state) при использовании спецификации.

Пример диаграммы состояние (state) с добавленными действиями на входе, выходе, внутри события представлен на рисунке 3.

Рис. 3. Пример элемента состояние (state) с добавленными действиями на входе, выходе, внутри события.

Возможна вложенность состояний. Семантика вложенности подразумевает для вложенных состояний «исключающее или». Объемлющее состояние называется суперсостоянием, а вложенное состояние – подсостоянием.

Пример вложенных состояний представлен на рисунке 4.

Рис. 4. Пример вложенных состояний.

Для вложенных состояний, начальное состояние должно определяться в каждом контексте отдельно.

Иногда после возвращения к суперсостоянию требуется попасть в то же подсостояние, в котором находились в последний раз. Эта семантика изображается значком истории (буква Н (History) внутри кружка) на изображении состояния. Пример значка истории (History) представлен на рисунке 5.

Рис. 5. Пример вложенных состояний со значком истории (History).

Переходом (state transition) называется изменение состояния системы и её элементов. Изменение состояния происходит под воздействием определённых событий. Событием называется любое происшествие, которое может быть причиной изменения состояния субъекта или объекта. События могут вызывать некоторые действия. Действием называется операция, которая, с практической точки зрения, требует нулевого времени выполнения, например, включение сигнала тревоги. На диаграмме состояний и переходов переход изображается сплошной линией со стрелкой, над которой могут указываться названия события и действия. Стрелка указывает на следующее состояние. Каждый переход соединяет два состояния. Состояние может иметь переход само в себя.

Переход в следующее состояние может происходить и после окончания нахождения в предыдущем состоянии.

Переход из одного состояния в другое состояние может происходить по условию. Условие есть логическое выражение, включающее некоторые величины. Переход в следующее состояние допускается только в случае истинности этого выражения. Пример элемента переход (state transition) представлен на рисунке 6.

Рис. 6. Пример элемента переход (state transition).

Переход (state transition) должен иметь имя, связанное с действием или событием, его вызвавшим. Событие, условие, действие можно добавить к элементу переход (state transition) при использовании спецификации. Пример элемента переход с добавлением события, условия, действия представлен на рисунке 7.

Рис. 7. Пример элемента переход с добавлением события, условия, действия.

Отдельные состояния можно декомпозировать с использованием другой диаграммы состояний (statechart diagram) и диаграммы деятельности (activity diagram).

Практическая часть

Запуск и настройка системы.

Запуск Rational Rose 2001 (Rose) производится из меню Пуск Microsoft Windows (Программы>Rational Rose Enterprise Edition=> Rational Rose Enterprise Edition).

При запуске Rose на экран выводится окно шаблонов.

Нажмите кнопку «Cancel» для отмены их ввода. На экране появляется окно с диаграммой классов.

Диаграмма состояний (statechart diagram) должна создаваться в окне просмотра Rose в разделе Use Case View.

Перед рисованием диаграммы в окне просмотра должен быть создан объект предметной области, а именно производственная сущность (business entity)!!!

В окне просмотра, выберите сущность, поведение которой следует описать с использованием диаграммы состояний. Далее щелкните правой клавишей мыши по изображению сущности. В появившемся меню выберите пункт New. Далее из вновь появившегося меню выберите пункт Statechart Diagram. В поле с именем NewDiagram введите наименование диаграммы состояний. Далее щелкните правой клавишей мыши по наименованию диаграммы и выберите команду Open. На экране появится окно рисования диаграммы состояний (Statechart Diagram).

Также можно добавить дополнительные иконки на панель инструментов. Для этого щелкните по панели инструментов два раза, и на экране появится окно настраиваемой панели инструментов следующего вида:

Рис. 10. Окно настраиваемой панели инструментов.

Моделирование поведения объекта.

Моделирование поведения объекта с использованием Rose должно включать рисование:

1.  Начального состояния;

2.  Состояний (если требуется вложенных состояний);

3.  Переходов соединяющих состояний;

4.  Конечных состояний.

Рисование элементов диаграммы состояний за исключением переходов с использованием Rose производится следующим образом.

Щелкните по иконке с изображением требуемого элемента диаграммы на панели инструментов. Щелкните мышью в окне рисования диаграммы в месте, где должно находится изображение выбранного элемента.

Рисование перехода (state transition) должно производится следующим образом. Щелкните по иконке с изображением перехода на панели инструментов. Соедините требуемые элементы диаграммы.


Рис. 11. Пример соединения двух элементов с помощью перехода (state transition).

Именование элементов диаграммы должно производится в окне спецификации на вкладке General в поле Name. Вызов окна спецификации производится по двойному щелчку левой клавиши мыши по элементу диаграммы.

События, действия, условия, связанные с переходом могут задаваться следующим образом.

Дважды щелкните левой клавишей мыши по переходу. На экране появится окно спецификации перехода.

В окне спецификации перехода на вкладке General в поле Event задайте имя события.


В окне спецификации перехода на вкладке Detail в поле Guard Condition задайте условие, в поле Action – действие.

Рис. 13. Пример поименования перехода (state transition).

Краткое описание элемента диаграммы можно производить в окне спецификации элемента диаграммы на вкладке General в разделе Documentation.


Значок истории (H (History)) задается в окне спецификации на вкладке General включением флага State/Activity History.

Рис. 14. Пример включения флага State/Activity History.

Текст на диаграмме можно разместить с использованием иконки на панели инструментов с изображением заметки (Note) и текста (TextBox) . Изображение заметки может крепиться к любому элементу диаграммы с использованием специальной линии (Anchor Note to Decision Item).

Декомпозиция отдельных видов состояний с использованием других диаграмм состояний (state transition) и диаграмм деятельности (activity diagram) может производиться следующим образом.

Щелкните правой кнопкой мыши по состоянию, которое следует декомпозировать. В появившемся меню выберите пункт Sub Diagrams. Во вновь появившемся меню выберите пункт New Statechart Diagram или New Activity Diagram. На экране появится окно для рисования новой диаграммы.

Декомпозированное состояние следует пометить каким-либо цветом.

Пометка производится следующим образом. Щелкните правой кнопкой мыши по состоянию. В появившемся меню выберите пункт Format. Далее в появившемся меню выберите пункт Fill Color. Из палитры выберите требуемый цвет. Нажмите кнопку OK.

Далее щелкните правой кнопкой мыши по деятельности, которую декомпозировали. В появившемся меню выберите пункт Select in Browser. Декомпозирующая диаграмма находится в окне просмотра ниже декомпозируемого элемента. В окне просмотра щелкните по изображению декомпозирующей диаграммы правой кнопкой мыши и в появившемся меню выберите пункт меню Rename. Задайте наименование диаграммы.

Пример. Создание диаграммы состояний для описания состояния бланка заказ книг для магазина в издательство

Порядок выполнения работы

·  Включите компьютер.

·  Запустите Rose.

·  Настройте Rose.

·  Задайте в окне просмотра Rose в разделе Use Case View график сущности.

·  Спроектируйте в окне просмотра Rose в разделе Use Case View модель состояний бланка заказа книг в соответствии с рисунком 16.

·  Задайте в окне просмотра Rose в разделе Use Case View сущность передачи менеджером по закупкам бланка заказа.

·  Спроектируйте в окне просмотра Rose в разделе Use Case View модель состояний бланка заказа книг для магазина в издательство в соответствии с правилами составления заказа книг для магазина у издательства.

Ниже приведён пример построения диаграммы состояний для описания состояния бланка заказ книг для магазина в издательство, которую надо автоматизировать с использованием диаграммы состояний (Statechart diagram) CASE - средства Rational Rose 2001. Автоматизируется передача составленного менеджером по закупкам бланка заказа книг директору магазина, главному бухгалтеру и секретарю издательства через курьера магазина.

Рис. 16. Пример диаграммы состояний для описания состояния бланка заказ книг для магазина в издательство, с использованием диаграммы состояний (Statechart diagram) CASE - средства Rational Rose 2001.

Список литературы

Сайт корпорации Rational Software http://www. /; Зиндер -реинжиниринг и технологии системного проектирования. Учебное пособие. М., Центр Информационных Технологий, 1996; CASE. Структурный системный анализ (автоматизация и применение). М., "Лори", 1996.

4. Дмитрий Рамодин http://www. *****/articles/rose1.html