Окончательное построение диаграммы деятельности модели банкомата 


Мы поможем в написании ваших работ!



ЗНАЕТЕ ЛИ ВЫ?

Окончательное построение диаграммы деятельности модели банкомата



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

  1. Добавить деятельности с именами: Ввести ПИН-код, Выбрать тип транзакции, Ввести сумму, Получить справку о состоянии счета, Получить наличные, Получить чек,Получить карточку и финальное состояние.
  2. Добавить символы ветвления (решения), расположив их между деятельностями с именами: Ввести ПИН-код и Выбрать тип транзакции, Выбрать тип транзакции и Ввести сумму, Ввести сумму и Получить справку о состоянии счета, Получить наличные и Получить чек, Получить чек и Получить карточку. При этом последний символ решения будет использоваться в качестве символа соединения.
  3. Добавить переход, направленный от деятельности Ввести ПИН-код к символу решения.
  4. Добавить переход со сторожевым условием: [ПИН-код верный], направленный от символа решения к деятельности Выбрать тип транзакции. Для задания сторожевого условия данного перехода следует ввести текст ПИН-код верный в поле ввода Guard Condition (Сторожевое условие) на вкладке Detail (Подробно) окна спецификации свойств данного перехода (рис. 10.4). При этом текст сторожевого условия следует вводить без скобок.


Рис. 10.4. Диалоговое окно спецификации свойств перехода при задании сторожевого условия

Для продолжения построения диаграммы деятельности следует выполнить следующие действия:

  1. Добавить переход со сторожевым условием: [ПИН-код неверный], направленный от символа решения к символу соединения.
  2. Добавить переход, направленный от деятельности Выбрать тип транзакции к символу решения.
  3. Добавить переход со сторожевым условием: [выбор снятия суммы], направленный от символа решения к деятельности Ввести сумму.
  4. Добавить переход со сторожевым условием: [выбор получения справки], направленный от символа решения к деятельности Получить справку о состоянии счета.
  5. Добавить переход, направленный от деятельности Ввести сумму к символу решения.
  6. Добавить переход со сторожевым условием: [сумма не превышает кредит], направленный от символа решения к деятельности Получить наличные.
  7. Добавить переход со сторожевым условием: [сумма превышает кредит], направленный от символа решения к символу соединения.
  8. Добавить переход, направленный от деятельности Получить наличные к символу решения.
  9. Добавить переход со сторожевым условием: [выбрана печать чека], направленный от символа решения к деятельности Получить чек.
  10. Добавить переход со сторожевым условием: [печать чека не выбрана], направленный от символа решения к символу соединения.
  11. Добавить переход, направленный от деятельности Получить чек к символу соединения.
  12. Добавить переход, направленный от деятельности Получить справку о состоянии счета к символу соединения.
  13. Добавить переход, направленный от символа соединения к деятельности Получить карточку.
  14. Добавить переход, направленный от деятельности Получить карточку к финальному состоянию.

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


Рис. 10.5. Окончательный вид диаграммы деятельности для модели банкомата

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

Следует помнить, что в среде IBM Rational Rose 2003 диаграмма деятельности не является необходимой для генерации программного кода. Поэтому разработку диаграмм этого типа, особенно в условиях дефицита времени, отпущенного на выполнение проекта, иногда опускают. В то же время следует отметить, что в проектах реинжиниринга и документирования бизнес-процессов диаграмма деятельности является основным средством визуализации бизнес-процессов в контексте языка UML. Особенности разработки проектов по моделированию бизнес-процессов в среде IBM Rational Rose 2003 рассматриваются далее в лекции 11.

 


 

3. Диаграммы деятельности для моделирования бизнес-процессов 1. Особенности проектов по моделированию бизнес-процессов в среде IBM Rational Rose 2003. 2. Добавление дорожек на диаграмму деятельности. 3. Построение диаграммы деятельности с дорожками и потоком объектов. 4. Пример построения диаграммы деятельности с дорожками и потоком объектов для модели бизнес-процесса.
Особенности проектов по моделированию бизнес-процессов в среде IBM Rational Rose 2003 Продолжая рассмотрение особенностей разработки диаграмм деятельности, следует отметить, что программа IBM Rational Rose 2003 может быть успешно использована для выполнения проектов по моделированию бизнес-процессов. Наиболее подходящим типом диаграмм для визуального представления схем выполнения бизнес-процессов являются диаграммы деятельности, на которых дополнительно размещаются так называемые дорожки (Swimlane). Назначение дорожек состоит в том, чтобы указать зоны ответственности за выполнения отдельных деятельностей в рамках моделируемого бизнес-процесса. В качестве имен дорожек используются либо названия подразделений (департаментов) рассматриваемой компании, либо названия отдельных должностей сотрудников тех или иных подразделений. Проекты по моделированию бизнес-процессов могут выполняться либо с целью реорганизации или реинжиниринга компании, либо с целью собственно документирования бизнес-процессов. Особенности данных проектов заключаются в том, что в обоих случаях необходимо построить модели бизнес-процессов некоторой существующей компании. Чтобы акцентировать внимание на подобных проектах, их часто называют проектами типа «As is» («Как есть»). Соответственно проекты по разработке новых продуктов или моделей новых систем называют проектами типа «To be» («Как должно быть»). В данном контексте рассматриваемый ранее проект по разработке системы управления банкоматом следует отнести к проектам типа «Как есть», поскольку при построении диаграмм предполагалась известной существующая технология использования банкоматов для обслуживания клиентов. С другой стороны, если бы стояла цель разработки новой модели банкомата с некоторой дополнительной функциональностью или, например, разработки нового Интернет-магазина, то подобные проекты можно было бы отнести к проектам типа «Как должно быть». Именно этот тип проектов служит базовым для принятой в курсе лекций последовательности разработки канонических диаграмм в нотации UML, начиная от представления диаграмм вариантов использования и заканчивая диаграммами физического представления. Выполнение проектов типа «Как есть» по моделированию бизнес-процессов в большинстве случаев начинают с построения диаграмм деятельности, которые служат для графического представления схем выполнения бизнес-процессов и документооборота рассматриваемой компании. После этого, исходя из требований проекта, разрабатывается модель диаграммы вариантов использования и выполняется реорганизация бизнес-процессов. Наконец, в случае необходимости разработки или внедрения корпоративной информационной системы, строятся диаграмма классов, диаграммы взаимодействия и компонентов, которые служат основой для программной реализации соответствующего проекта. Таким образом, первый этап выполнения проектов типа «Как есть» связан с построением моделей существующих бизнес-процессов компании в форме диаграмм деятельности. В качестве примера проекта этого типа в данной лекции рассматривается модель бизнес-процесса по оптовой продаже товаров со склада торговой компании. Хотя данный пример имеет упрощенный характер, он позволяет наглядно представить основные особенности моделирования бизнес-процессов в нотации языка UML с использованием средства IBM Rational Rose 2003. Для вновь разрабатываемого проекта по моделированию бизнес-процессов торговой компании в среде IBM Rational Rose 2003 создадим новый проект с именем: МодельБП. В качестве первой диаграммы проекта будет служить диаграмма деятельности, которая описывает отдельный бизнес-процесс в виде последовательности выполнения действий подразделениями компании при оптовой продаже товаров клиентам. Для удобства можно включить эту диаграмму в логическое представление, для чего необходимо в браузере проекта выделить логическое представление (Logical View) и выполнить операцию контекстного меню: New Activity Diagram (Новая Диаграмма деятельности). Добавление дорожек на диаграмму деятельности Для представления модели бизнес-процесса в форме диаграммы деятельности первоначально необходимо добавить на нее дорожки. Для добавления дорожки на диаграмму деятельности нужно с помощью левой кнопки мыши нажать кнопку с изображением пиктограммы дорожки на специальной панели инструментов, отпустить левую кнопку мыши и щелкнуть левой кнопкой мыши на свободном месте рабочего листа диаграммы. Добавить дорожку на диаграмму можно также с помощью операции главного меню: Tools Create Swimlane или с помощью операции контекстного меню: New Swimlane, предварительно выделив диаграмму деятельности в браузере проекта. В результате этих действий на диаграмме в области диаграммы появится изображение дорожки с вертикальной линией и именем дорожки NewSwimlane в верхней части, предложенное программой по умолчанию. Для задания имени дорожки следует открыть диалоговое окно спецификации ее свойств и ввести ее имя в поле ввода Name (рис. 11.1). Рис. 11.1. Диалоговое окно спецификации свойств дорожки Начиная практическую разработку модели бизнес-процесса оптовой продажи товаров со склада компании, последовательно добавим на диаграмму деятельности дорожки с именами отдельных подразделений компании: Отдел приема заказов, Бухгалтерия, Склад и Отдел доставки (рис. 11.2). Рис. 11.2. Диаграмма деятельности после добавления на нее дорожек После добавления дорожек на диаграмму состояний можно перейти к добавлению деятельностей и переходов. В качестве первой деятельности добавим деятельность с именемПринять заказ по факсу, которую разместим в первой дорожке с именем Отдел приема заказов. Этот факт будет означать, что деятельность Принять заказ по факсувыполняется в Отделе приема заказов или, другими словами, сотрудники этого отдела несут ответственность за выполнение данной деятельности. Деятельности Принять заказ по факсу должно предшествовать начальное состояние, которое также следует добавить в эту же дорожку и соединить переходом с этой деятельностью. После добавления начального состояния и перехода диаграмма деятельности будет иметь следующий вид (рис. 11.3). Рис. 11.3. Диаграмма деятельности после добавления на нее перехода из изначального состояния в деятельность Принять заказ по факсу Построение диаграммы деятельности с дорожками для модели бизнес-процесса Для построения диаграммы деятельности с дорожками для рассматриваемой модели бизнес-процесса следует добавить оставшиеся деятельности и переходы. С этой целью следует выполнить следующие действия:
  1. Добавить деятельность с именем: Заказать товар на складе в дорожку Отдел приема заказов.
  2. Добавить деятельности с именами: Выставить счет к оплате и Получить оплату за товар в дорожку Бухгалтерия.
  3. Добавить деятельности с именами: Подобрать товар и Подготовить товар к отправке в дорожку Склад.
  4. Добавить деятельность с именем: Отправить товар клиенту в дорожку Отдел доставки.
  5. Добавить символ горизонтальной синхронизации в дорожки Отдел приема заказов и Склад. Следует заметить, что первый символ будет использован для разделения параллельных потоков деятельностей, а второй - для слияния этих потоков.
  6. Добавить переход, направленный от деятельности Принять заказ по факсу к деятельности Заказать товар на складе.
  7. Добавить переход, направленный от деятельности Заказать товар на складе к символу горизонтальной синхронизации.
  8. Добавить переход, направленный от символа горизонтальной синхронизации к деятельности Выставить счет к оплате.
  9. Добавить переход, направленный от символа горизонтальной синхронизации к деятельности Подобрать товар.
  10. Добавить переход, направленный от деятельности Выставить счет к оплате к деятельности Получить оплату за товар.
  11. Добавить переход, направленный от деятельности Подобрать товар к деятельности Подготовить товар к отправке.
  12. Добавить переход, направленный от деятельности Получить оплату за товар к символу горизонтальной синхронизации.
  13. Добавить переход, направленный от деятельности Подготовить товар к отправке к символу горизонтальной синхронизации.
  14. Добавить переход, направленный от символа горизонтальной синхронизации к деятельности Отправить товар клиенту.
  15. Добавить переход, направленный от деятельности Отправить товар клиенту к финальному состоянию.
Построенная таким образом диаграмма деятельности с дорожками будет иметь следующий вид (рис. 11.4). Рис. 11.4. Диаграмма деятельности с дорожками для модели бизнес-процесса Следует заметить, что в разрабатываемой модели диаграмма деятельности не описывает ситуацию, когда заказанного клиентом товара не окажется на складе. Дополнить данную диаграмму, которая учитывает данное условие в форме проверки отдельного условия, предлагается читателям самостоятельно в качестве упражнения. Построение диаграммы деятельности с дорожками и потоком объектов Для построения диаграммы деятельности с дорожками и потоком объектов для рассматриваемой модели бизнес-процесса следует добавить на диаграмму объекты и стрелки потоков объектов. Объекты на диаграмме деятельности могут обозначать отдельные документы, которые необходимы для выполнения моделируемого бизнес-процесса. Соответственно поток объектов служит моделью документооборота рассматриваемой компании. Для добавления на диаграмму объекта следует воспользоваться соответствующей кнопкой на специальной панели инструментов. При этом данную кнопку предварительно следует на нее добавить, поскольку по умолчанию на панели она отсутствует. В качестве первого объекта добавим на диаграмму деятельности объект с именем заказ, для которого зададим состояние: получен. Для задания состояния добавленного объекта следует открыть диалоговое окно свойств данного объекта, во вложенном списке State (Состояние) выбрать нужное состояние или задать новое (рис. 11.5). При этом будет открыто дополнительное окно свойств состояния, в которое можно занести всю информацию по данному состоянию. Рис. 11.5. Диалоговое окно спецификации свойств объекта Для завершения построения диаграммы деятельности рассматриваемого примера следует описанным выше способом добавить оставшиеся объекты и стрелки потоков объектов. С этой целью следует выполнить следующие действия:
  1. Добавить стрелку потока объектов, направленную от деятельности Принять заказ по факсу к объекту заказ в состоянии получен.
  2. Добавить стрелку потока объектов, направленную от объекта заказ в состоянии получен к деятельности Заказать товар на складе.
  3. Добавим объект с именем заказ, для которого зададим состояние: оформлен. Следует заметить, что для добавления на диаграмму деятельности уже существующего в модели объекта его следует просто перетащить из браузера проекта на диаграмму и задать ему новое состояние.
  4. Добавить стрелку потока объектов, направленную от деятельности Заказать товар на складе к объекту заказ в состоянии оформлен.
  5. Добавить стрелку потока объектов, направленную от объекта заказ в состоянии оформлен к деятельности Выставить счет к оплате.
  6. Добавим объект с именем счет, для которого зададим состояние: выставлен.
  7. Добавить стрелку потока объектов, направленную от деятельности Выставить счет к оплате к объекту счет в состоянии выставлен.
  8. Добавить стрелку потока объектов, направленную от объекта счет в состоянии выставлен к деятельности Получить оплату за товар.
  9. Добавим объект с именем счет, для которого зададим состояние: оплачен.
  10. Добавить стрелку потока объектов, направленную от деятельности Получить оплату за товар к объекту счет в состоянии оплачен.
  11. Добавить стрелку потока объектов, направленную от объекта счет в состоянии оплачен к деятельности Отправить товар клиенту.
  12. Добавим объект с именем накладная, для которого зададим состояние: выписана.
  13. Добавить стрелку потока объектов, направленную от деятельности Заказать товар на складе к объекту накладная в состоянии выписана.
  14. Добавить стрелку потока объектов, направленную от объекта накладная в состоянии выписана к деятельности Подобрать товар.
  15. Добавим объект с именем накладная, для которого зададим состояние: оформлена.
  16. Добавить стрелку потока объектов, направленную от деятельности Подготовить товар к отправке к объекту накладная в состоянии оформлена.
  17. Добавить стрелку потока объектов, направленную от объекта накладная в состоянии оформлена к деятельности Отправить товар клиенту.
Построенная таким образом диаграмма деятельности с дорожками и потоком объектов будет иметь следующий вид (рис. 11.6). Рис. 11.6. Окончательный вид диаграммы деятельности для модели бизнес-процесса Для большей наглядности представления данной модели можно задать для всех деятельностей стереотип Business Activity (Бизнес-деятельность), который будет означать в данном контексте деятельность, выполняемую в рамках некоторого бизнес-процесса. Напомним, что изменить стереотип деятельности можно с помощью выбора нужного варианта стереотипа в окне спецификации свойств деятельности. Соответствующий вариант изображения диаграммы деятельности представлен на рис. 11.7. Рис. 11.7. Окончательный вид диаграммы деятельности для модели бизнес-процесса со стереотипами деятельностей Следует заметить, что в разрабатываемой модели диаграмма деятельности не описывает ситуацию, когда клиент отказался от оплаты товара после выставления ему счета. Дополнить данную диаграмму деятельности, которая учитывает данное условие, предлагается читателям самостоятельно в качестве упражнения. Хотя в среде IBM Rational Rose 2003 диаграмма деятельности не является необходимой для генерации программного кода, диаграммы данного типа имеют большое значение для документирования бизнес-процессов и их последующей сертификации по международному стандарту ISO 9000. Поэтому разработка диаграмм этого типа занимает центральное место при выполнении проектов по реинжинирингу и оптимизации бизнес-процессов с использованием нотации UML.


 

Лабораторная работа №6 Диаграммы компонентов и развертывания 1. Диаграммы компонентов 1. Особенности разработки диаграммы компонентов в среде IBM Rational Rose 2003. 2. Добавление компонента на диаграмму компонентов и редактирование его свойств. 3. Добавление отношения зависимости и редактирование его свойств. 4. Пример диаграммы компонентов модели банкомата.
Особенности разработки диаграммы компонентов в среде IBM Rational Rose 2003 Диаграмма компонентов служит частью физического представления модели, играет важную роль в процессе ООАП и является необходимой для генерации программного кода. Общие рекомендации по построению диаграммы компонентов были рассмотрены в лекции 12 курса «Основы объектно-ориентированного моделирования в нотации UML». Для разработки диаграмм компонентов в браузере проекта предназначено отдельное представление компонентов (Component View), в котором уже содержится диаграмма компонентов с пустым содержанием и именем по умолчанию Main (Главная). Активизация диаграммы компонентов может быть выполнена одним из следующих способов:
  • Щелкнуть на кнопке с изображением диаграммы компонентов на стандартной панели инструментов.
  • Раскрыть представление компонентов в браузере (Component View) и дважды щелкнуть на пиктограмме Main (Главная).
  • Через пункт меню Browse Component Diagram (Браузер Диаграмма компонентов).
В результате выполнения этих действий появляется новое окно с чистым рабочим листом диаграммы компонентов и специальная панель инструментов, содержащая кнопки с изображением графических примитивов, необходимых для разработки диаграммы компонентов (табл. 12.1).
Таблица 12.1. Назначение кнопок специальной панели инструментов диаграммы компонентов
Графическое изображение Всплывающая подсказка Назначение кнопки
Selection Tool Превращает изображение курсора в форму стрелки для последующего выделения элементов на диаграмме
Text Box Добавляет на диаграмму текстовую область
Note Добавляет на диаграмму примечание
Anchor Note to Item Добавляет на диаграмму связь примечания с соответствующим графическим элементом диаграммы
Component Добавляет на диаграмму компонент
Package Добавляет на диаграмму пакет
Dependency Добавляет на диаграмму отношение зависимости
Subprogram Specification Добавляет на диаграмму спецификацию подпрограммы
Subprogram Body Добавляет на диаграмму тело подпрограммы
Main Program Добавляет на диаграмму главную программу
Package Specification Добавляет на диаграмму спецификацию пакета
Package Body Добавляет на диаграмму тело пакета
Task Specification Добавляет на диаграмму спецификацию задачи
Task Body Добавляет на диаграмму тело задачи
Generic Subprogram Добавляет на диаграмму типовую подпрограммы(по умолчанию отсутствует)
Generic Package Добавляет на диаграмму типовой пакет (по умолчанию отсутствует)
Database Добавляет на диаграмму базу данных (по умолчанию отсутствует)

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

Программа IBM Rational Rose 2003 не поддерживает графические стереотипы, рассмотренные в лекции 12 курса «Основы объектно-ориентированного моделирования в нотации UML», и предлагает целый ряд собственных стереотипов. Графическое изображение этих стереотипов и их краткая характеристика приводятся в следующей таблице (табл. 12.2). При этом каждому из компонентов, как правило, соответствует отдельный файл исходной сборки программного приложения.

Таблица 12.2. Графическое изображение стереотипов компонентов и их характеристика
Графическое изображение и имя по умолчанию Название стереотипа Характеристика стереотипа компонента
Subprogram Specification Спецификация подпрограммы. Содержит описание переменных, процедур и функций и не содержит определений классов
Subprogram Body Тело подпрограммы. Содержит реализацию процедур и функций, не относящихся к каким-то классам, при этом не содержит определений классов или реализаций операций других классов
Main Program Главная программа. Реализует базовую логику работы программного приложения и содержит ссылки на другие компоненты модели
Package Specification Спецификация пакета. Содержит определение класса, его атрибутов и операций. В языке программирования С++ спецификации пакета соответствует отдельный файл с расширением «h»
Package Body Тело пакета. Содержит код реализации операций класса. В языке программирования С++ спецификации пакета соответствует отдельный файл с расширением «cpp»
Task Specification Спецификация задачи. Может содержать определение класса, его атрибутов и операций, которые предполагается использовать в независимом потоке управления
Task Body Тело задачи. Может содержать реализацию операций класса, которые имеют независимый поток управления.
Generic Subprogram Типовая подпрограмма. Содержит описание переменных, процедур и функций, которые могут быть использованы в нескольких программных приложениях. При этом типовая подпрограмма не содержит определений классов
Generic Package Типовой пакет. Содержит определение класса, его атрибутов и операций, которое может быть использовано в нескольких программных приложениях
Database База данных. Содержит определение одного или нескольких классов, их атрибутов и, возможно, операций. При этом соответствующие классы могут быть реализованы в форме одной или нескольких таблиц базы данных

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



Поделиться:


Последнее изменение этой страницы: 2017-01-25; просмотров: 919; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.15.174.76 (0.015 с.)