Поиск

Полнотекстовый поиск:
Где искать:
везде
только в названии
только в тексте
Выводить:
описание
слова в тексте
только заголовок

Рекомендуем ознакомиться

'Программа'
Три страны, три города, три эпохи: Вена – пышный город венских вальсов, Моцарта и ароматного кофе по-венски; Прага – город-сказка, он же пивная столи...полностью>>
'Автореферат'
Защита состоится 09 ноября 2011 г. в 16.00 часов на заседании совета по защите докторских и кандидатских диссертаций Д 502.009.01 при Уральской акаде...полностью>>
'Программа'
Составители программы: кандидат искусствоведения, профессор М.П.Власов, доктор искусствоведения, профессор С.В.Дробашенко, доктор искусствоведения, п...полностью>>
'Документ'
Gil’s Jewellery – не просто ще один магазин, в якому продаються ювелірні прикраси. Прагнучи перейняти багатовікову культуру кращих ювелірних салонів ...полностью>>

Е. Б. Золотухина Методическая разработка «Основы бизнес моделирования»

Главная > Методическая разработка
Сохрани ссылку в одной из сетей:

1

Смотреть полностью

Е.Б. Золотухина

Методическая разработка

«Основы бизнес моделирования»

по курсу:

«Современные технологии анализа и проектирования
информационных систем»

Москва 2005

Предисловие

В данном пособии представлена оригинальная методика бизнес моделирования разработанная на основе Рационального унифицированного процесса создания программного обеспечения (Rational Unified Process - RUP) компании IBM. Рекомендации по бизнес моделированию, данные в RUP при создании систем, связанных с е-бизнесом, адаптированы под проекты создания систем масштаба предприятия. Методика бизнес моделирования, представленная в этом пособие, активно и успешно используется при создании ряда автоматизированных систем, в разработке которых участвовал автор. На основе методики корректно определяются требования к разрабатываемым автоматизированным системам, и разрабатывается их архитектура. Данная методика также может быть использована при описании бизнес процессов предприятия с целью их реорганизации и сертификации по международным стандартам качества и при определении требований к покупаемым системам, поддерживающим деятельность предприятий.

Оглавление

Введение 6

Тема 1. Универсальный язык моделирования UML и его
поддержка Rational Rose 7

1.1. История создания UML 7

1.2. Диаграммы UML 7

1.3. Инструментальное средство визуального моделирования Rational Rose 10

1.3.1. Основные элементы интерфейса Rational Rose 10

1.3.2. Работа в Rational Rose 14

1.4. Задания для самоконтроля 17

1.5. Практические задания 19

Тема 2. Описание дисциплины бизнес моделирования 20

2.1. Цели бизнес моделирования 20

2.2. Концепции бизнес моделирования 20

2.2.1. Функционально - стоимостной анализ (Activity-Based Costing) 20

2.2.2. Архитектура бизнеса 21

2.2.3. Типовые бизнес решения 21

2.2.4. Моделирования больших организаций 21

2.2.5. Различные сценарии бизнес моделирования 21

2.2.6. Е- бизнес 22

2.3. Виды деятельности на этапе бизнес моделирования 22

2.4. Результаты бизнес моделирования 23

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

2.6. Задания для самоконтроля 27

2.7. Практические задания 31

Тема 3. Разработка моделей бизнес процессов 33

3.1. Моделирование бизнес процессов 33

3.1.1. Цель разработки модели бизнес процессов 35

3.1.2. Использование диаграммы функций для разработки моделей бизнес процессов 35

3.1.3. Порядок построения модели бизнес процессов в Rational Rose 40

3.2. Задания для самоконтроля 44

3.3. Практические задания 46

Тема 4. Разработка моделей потоков работ 47

4.1. Цель моделирование потока работ 47

4.2. Использование диаграммы деятельности для разработки модели
потока работ 47

4.3. Порядок построения модели потока работ бизнес процессов в Rational Rose 53

4.4. Задания для самоконтроля 56

4.5. Практические задания 58

Тема 5. Разработка моделей бизнес сущностей и их состояний 59

5.1. Цель моделирование бизнес сущностей и их состояний 59

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

5.3. Использование диаграммы состояний или деятельности для разработки
модели состояний документа или бизнес сущности 62

5.4. Порядок построения модели бизнес сущности и ее состояния в Rational Rose 63

5.5. Задания для самоконтроля 67

5.5. Практические задания 69

Тема 6. Разработка моделей ролей 70

6.1. Цель моделирование ролей 70

6.2. Использование диаграммы классов/функций для разработки модели ролей 70

6.3. Порядок построения модели ролей в Rational Rose 72

6.4. Задания для самоконтроля 75

6.5. Практические задания 77

Тема 7. Разработка моделей бизнес правил 78

7.1. Цель моделирование бизнес правил 78

7.2. Использование диаграмм деятельности, классов и функций для разработки модели бизнес правил 78

7.3. Порядок построения модели бизнес правил в Rational Rose 79

7.2. Практические задания 84

Предметный указатель 85

Глоссарий 87

Заключение 88

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

Приложение 1. Технология оформления международного
перевода в банке 90

Приложение 2.
Форма заявление на перевод валютных средств клиентом банка 92

Приложение 3. Форма перевода по поручению
клиента мт100 в формате swift 93

Введение

Рациональный унифицированный процесс (Rational Unified Process - RUP) – процесс разработки программного обеспечения (ПО) фирмы IBM. RUP обеспечивает формализованный подход к определению задач и обязанностей по их решению внутри организации разработчика программного обеспечения. Рекомендации RUP также могут быть использованы консалтинговыми формами при описании процессов организации с целью их реорганизации, сертификации и т.д.

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

RUP вобрал в себя все лучшее, что существует в практике разработки современного программного обеспечения.

Основу RUP составляют его дисциплины. RUP включает следующие 9 дисциплин [1, 2] (рис. 0.1):

1. Бизнес моделирование (Business Modeling).

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

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

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

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

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

7. Управление конфигурациями и изменениями (Configuration and Change Management).

8. Управление проектом.

9. Настройка среды разработки (Enviroment).

Рис. 0.1. Дисциплины RUP

Любая дисциплина RUP включают в себя все элементы описания бизнес процесса:

  • цели;

  • концепции;

  • поток работ;

  • описание видов деятельности;

  • описание артефактов;

  • рекомендации;

  • шаблоны документов.

Где под артефактом в RUP понимается модель, элемент модели, документ, программный код, исполняемые файлы. Артефакт подлежит версионному контролю.

Основу любой дисциплины RUP составляют рекомендации по разработке различных моделей с использованием универсального языка моделирования (Unified Modeling Language - UML). Инструментальным средством поддерживающим разработку моделей в соответствие с RUP является средство визуального моделирования Rational Rose.

Данное пособие посвящено изучению универсального языка моделирования UML, освоению приемов работы со средством визуального моделирования Rational Rose, теоретическому и практическому изучению дисциплины бизнес моделирования RUP c точки зрения создания различных моделей как фундамента определения требований к системе и разработки ее архитектуры. В пособие представлены учебные примеры моделей, разработанных в Rational Rose из проектов с использованием RUP, в которых автор принимала непосредственное участие. Практические задания также используют материалы реальных проектов.

Тема 1. Универсальный язык моделирования UML и его
поддержка Rational Rose

Цели занятия:

  • изучить состав диаграмм языка UML;

  • понять место использования UML в процессе RUP;

  • освоить приемы работы со средством визуального моделирования Rational Rose.

1.1. История создания UML

Унифицированный язык моделирования (Unified Modeling Language - UML) является языком визуального моделирования, прежде всего предназначенным для разработки программных систем. Однако сфера применения этого языка гораздо шире. Создатели UML представляют его как язык для определения, представления, проектирования и документирования программных систем, бизнес-систем и других систем различной природы.

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

Разработка UML началась в октябре 1994 г. когда Грэйди Буч (Grady Booch) и Джеймс Рэмбо (James Rambaugh) начали свои работы по унификации соответственно метода Booch и OMT (Object Modeling Technique) в Rational Software Corporation. Первоначальной их целью было объединение методов Booch и OMT. В октябре 1995 г. появилось первое описание UML (версия 0.8). В июне 1996 г. появилась версия 0.9. Версия UML 1.0. была представлена для стандартизации в консорциуме Object Management Group (OMG) в июле 1997 г. OMG занимается разработкой стандартов на основе объектно-ориентированных подходов, и в ее деятельности участвуют более 500 различных компаний. Утвержденная в ноябре 1997 г. версия UML 1.1 была принята на вооружение основными компаниями - производителями программного обеспечения, такими, как Microsoft, IBM, Hewlett-Packard и производителями CASE-средств, которые реализовали поддержку UML в своих программных продуктах (Paradigm Plus, System Architect, Microsoft Visual Modeler, Microsoft Visio, ARIS Toolset, Oracle Designer, Silverrun). В июне 1998 г. появилась версия UML 1.2, осенью 1998- UML 1.3, в 2002 г. UML – 2.0.

UML имеет следующие достоинства:

  • обеспечивает формализацию и стандартизацию процесса моделирования;

  • представляет проектировщикам систем удобные средства визуального моделирования и документирования

  • поддерживает высокоуровневое проектирование с использованием различных структур, шаблонов, компонент;

  • обеспечивает поддержку множества языков программирования;

  • прост в освоении.

1.2. Диаграммы UML

UML 2.0 включает набор диаграмм (рис. 1.1.), используемых для разработки различных моделей программных и бизнес систем. Как видно из рис. 1.1. диаграммы подразделяются на две группы: структурные диаграммы и процессные диаграммы.

К структурным диаграммам относятся:

  • диаграмма классов;

  • диаграмма объектов;

  • составная структурная диаграмма;

  • диаграмма компонент;

  • диаграмма размещения;

  • диаграмма пакетов.

К процессным диаграммам относятся:

  • диаграммы взаимодействия;

  • диаграммы деятельности;

  • диаграммы функций;

  • диаграммы состояний.

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

  • диаграммы последовательностей;

  • обзорные диаграммы потоков управления;

  • коммуникационные диаграммы;

  • временнее диаграммы.

На различных этапах создания программной системы могут использоваться диаграммы UML для создания различных моделей.

Рис. 1.1. Диаграммы UML 2.0.

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

Язык UML не содержит понятие процесса разработки программной системы. Методы моделирования не имеют смысла без знания того, как они могут быть использованы процессом разработки. С языком UML можно использовать любой процесс. В данном пособие рассматривается разработка моделей с использованием UML в соответствие с рациональным унифицированный процессом (Rational Unified Process - RUP).

В табл. 1.1. представлены этапы работ по RUP, модели, разрабатываемые на каждом этапе, и используемые диаграммы UML.

Таблица.1.1.

Этапы работ по RUP, модели и диаграммы UML в Rational Rose

Этап работ по RUP

Модели

Диаграммы UML

Примечания

Бизнес
моделирование

(Business Modeling)

Бизнес процессы (business use case model)

Use case diagram

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

Описание бизнес процессов (business object model RUP 2002 или business analysis model RUP 2003)

Activity diagram

Модель отображает поток работ по бизнес процессу. Модель используется для определения модулей подсистем и их функций.

Описание бизнес сущностей (business object model RUP 2002 или business analysis model RUP 2003)

Class diagram,

Use case diagram

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

Описание состояния бизнес сущности (business object model RUP 2002 или business analysis model RUP 2003)

Activity diagram, Statechart diagram.

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

Роли и автоматизируемые виды деятельности (business object model RUP 2002 или business analysis model RUP 2003)

Class diagram,

Use case diagram

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

Структура предприятия (business object model RUP 2002 или business analysis model RUP 2003)

Class diagram,

Use case diagram

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

Бизнес правила

Class diagram, Activity diagram

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

Определение требований

(Requirements)

Функции системы (Use case model)

Use case diagram

Модель отображает функции системы

Экранные формы

Class diagram

Модель отображает экранные формы системы

Сценарии работы пользователя с системой

Activity diagram

Модель отображает сценарии работы пользователя с системой

Анализ и проектирование

(Analysis & Design)

Модель размещения (Deployment model)

Deployment diagram

Модель отображает технические средства и, размещенные на них, программные средства системы и прочие программные средства

Модель данных (Data modal)

Class diagram

Модель отображает логическую и физическую структуру данных.

Модель анализа (Analysis modal)

Class diagram

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

Модель проектирования

(Design modal)

Class diagram,

Sequence diagram,

Activity diagram,

Collaboration diagram

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

Реализация

(Implementation)

Модель реализации

(Implementation model)

Component diagram

Модель отображает подсистемы и компоненты, из которых они состоят

Тестирование

(Test)

Модель тестирования

(Test suite)

Class diagram,

Activity diagram

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

Размещение

(Deployment)

Модель размещения
(Deployment model)

Deployment diagram

Модель отображает технические средства и размещенные на них программные средства системы и прочие программные средства

1.3. Инструментальное средство визуального моделирования Rational Rose

Rational Rose инструмент, позволяющий разрабатывать модели с использованием диаграмм UML на всех этапах создания программной системы в соответствие с рациональным унифицированным процессом RUP.

1.3.1. Основные элементы интерфейса Rational Rose

Основными элементами интерфейса Rational Rose являются (рис. 1.2):

  • браузер (browser) или окно просмотра элементов модели;

  • окно документации (documentation window);

  • стандартная панель инструментов (standard panel);

  • панель инструментов диаграммы (diagram panel);

  • окно диаграммы (diagram window);

  • спецификации элементов (specification).

Рис. 1.2. Основные элементы интерфейса Rational Rose

Браузер организован в виде дерева. Каждый элемент в браузере может содержать другие элементы, находящиеся ниже его в иерархии. Щелчок левой клавиши мыши по изображению плюса "+" рядом с элементом в браузере позволяет раскрыть содержимое элемента. Щелчок мыши по изображению минуса "-" рядом с элементом в браузере позволяет скрыть содержимое элемента в браузере.

Браузер используется для:

  • создания диаграмм;

  • навигации по диаграммам;

  • добавления элементов диаграмм;

  • перемещения элементов диаграмм;

  • группировки элементов диаграмм и диаграмм в пакеты (папки);

  • работы со спецификацией элементов диаграмм;

  • открытия диаграммы;

  • удаления диаграммы.

Браузер поддерживает четыре представления (в браузере существуют четыре пакета) (рис.1.3):

  • представление функций (Use Case View);

  • логическое представление (Logical View);

  • представление компонент (Component View);

  • представление размещения (Deployment View).

Рис. 1.3. Пакеты в Rational Rose для создания диаграмм и элементов модели

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

Например, в представлении функций можно создавать следующие элементы и диаграммы (рис. 1.4):

  • пакет (Package);

  • функция (Use Case);

  • роль (Actor);

  • класс (Class);

  • диаграмма функций (Use Case Diagram);

  • диаграмма классов (Class Diagram);

  • диаграмма взаимодействия (Collaboration Diagram);

  • диаграмма последовательностей (Sequence Diagram);

  • диаграмма состояний (Statechart Diagram);

  • диаграмма деятельности (Activity Diagram).

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

Окно документации предназначено для документирования элементов модели.

Панели инструментов обеспечивают быстрый доступ к часто используемым командам. В Rational Rose существуют два вида панелей: стандартная панель (standart panel) и панель диаграммы (diagram panel) (рис. 1.5). Стандартная панель видна всегда. Ее кнопки соответствуют командам, которые могут использоваться для работы с любой диаграммой. Панель диаграммы своя для каждого типа диаграмм UML. Можно изменить и настроить любую панель инструментов. Для этого следует выбрать пункт меню Tools  пункт меню Options закладка Toolbars (рис. 1.6).

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

Спецификация элементов используется для документирования информации, связанной с элементами диаграмм.

Рис. 1.4. Элементы и диаграммы представления функций

Рис. 1.5. Стандартная панель и панель диаграмм

Рис. 1.6. Закладка для настройки панелей диаграмм

Назначение иконок стандартной панели представлено в табл. 1.2.

Таблица 1.2. Назначение иконок стандартной панели

Иконка

Название иконки

Назначение

Create New Model or File

Создание новой модели или файла

Open Existing Model

Открытие файла модели

Save Model , File or Script

Сохранение модели, файла или скрипта

Cut

Вырезка

Copy

Копирование

Paste

Вставка

Print Diagram

Печать диаграммы

Context Sensitive help

Открытие файла справки

View Documentation

Визуализация окна документации

Browse Class Diagram

Открытие диаграммы классов

Browse Interaction Diagram

Открытие диаграммы взаимодействия

Browse Component Diagram

Открытие диаграммы компонентов

Browse State Machine Diagram

Открытие диаграммы состояний

Browse Deployment Diagram

Открытие диаграммы размещения

Browse Parent

Открытие диаграммы родителя

Browse Previous Diagram

Открытие предыдущей диаграммы

Zoom In

Увеличение масштаба

Zoom Out

Уменьшение масштаба

Fit in Window

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

Undo Fit in Window

Отменить команду Поместить диаграмму в одном окне

В табл. 1.3 представлен набор иконок для построения диаграммы деятельности.

Таблица 1.3. Назначение иконок диаграммы деятельности

Иконка

Название иконки

Назначение

Selection Tool

Выбор любой иконки на панели

Text Box

Текстовое поле

Note

Примечание

Anhor Note to Item

Линия для соединения примечания с любым элементом

State

Состояние

Activity

Деятельность

Start state

Начальное состояние

End state

Конечное состояние

State Transition

Переход от одной деятельности или состояние в другое

Transition to self

Переход в текущее состояние или деятельность

Horizontal Synchronization

Горизонтальные синхронизаторы

Vertical Synchronization

Вертикальные синхронизаторы

Decision

Решение

Swimlane

Дорожка

Object Flow

Поток объектов

Object

Объект

RPW Activity

Деятельность при описании процесса создания ПС

RPW Workflow Detail

Поток работ при описании процесса создания ПС

1.3.2. Работа в Rational Rose

Создание моделей является первым шагом при работе с Rational Rose. Модели можно создавать как без использованием шаблонов, так и с их использованием. Готовая модель со всеми диаграммами сохраняется в файле с расширением .mdl (модель).

Для создания модели:

  1. Выберите в меню File пункт New .

  2. Если на экране появляется список шаблонов (рис. 1.7) выберите требуемый и нажмите кнопку Ok. Если шаблон не требуется использовать, нажмите кнопку Cancel.

Рис. 1.7. Экран Rational Rose с шаблонами

Для сохранения модели выберите в меню File пункт Save или щелкните мышью по иконке Save стандартной панели инструментов.

Для добавления новой диаграммы:

  1. В браузере щелкните правой кнопкой по пакету.

  2. Выберите пункт New, далее выберите диаграмму.

  3. Введите имя новой диаграммы. Новая диаграмма добавляется ниже выбранного пакета.

  4. Дважды щелкните по иконке созданной диаграммы для ее открытия.

  5. Для удаления диаграммы щелкните по иконке диаграммы правой кнопкой мыши в окне браузера и выберите пункт меню Delete.

Работа с иконками на диаграмме организуется следующим образом. Выбирается на панели иконка, затем щелчком левой клавиши мыши иконка помещается на поле диаграммы. Элемент именуется в соответствующей спецификации. Спецификация элемента открывается по щелчку правой клавиши мыши и выбором из появившегося контекстного меню первого пункта.

В Rational Rose можно изменять шрифты и изменять их размеры. Назначить элементам диаграмм новый шрифт или размер можно следующим образом:

  1. Выделите требуемый элемент диаграммы.

  2. Выберите в меню Format пункт Font. На экране отобразиться окно работы со шрифтами (рис. 1.8.)

В Rational Rose можно изменять не только шрифт, но и цвет.

Для изменения цвета линии элемента:

  1. Выделите требуемый элемент диаграммы.

  2. Выберите в меню Format пункт Line Color. На экране отобразиться окно работы с цветом (рис. 1.9.).

  3. Выберите требуемый цвет линии.

Рис. 1.8. Окно работы со шрифтами

Рис. 1.9. Окно работы с цветом

Для изменения цвета заливки элемента:

  1. Выделите требуемый элемент диаграммы.

  2. Выберите в меню Format пункт Fill Color. На экране отобразиться окно работы с цветом (рис. 1.9.).

  3. Выберите требуемый цвет заливки.

Коллективная работа в Rational Rose организуется через элемент Пакет (Package). Пакетом в UML называется элемент, используемый для группировки элементов модели. Пакетами можно разделить модель в Rational Rose на несколько файлов. Для этого в браузере следует щелкнуть по пакету правой клавишей мыши. В появившемся меню выбрать пункт Units  Control. Сохранить файл с пакетом и его содержимым. Сохраненный файл будет иметь расширение .cat. Открыть файл в новой модели можно выбрав, пункт Units Load. Пакет, загружаемый в пустую модель будет помешен на диаграмму классов в представлении Logical View.

1.4. Задания для самоконтроля

Тест 1. Универсальный язык моделирования UML и его поддержка Rational Rose

1. Выбор из одного

Какие диаграммы UML 2.0 относятся к структурным ?

  • диаграмма функций (Use Case Diagram);

  • диаграмма классов (Class Diagram);

  • диаграмма взаимодействия (Collaboration Diagram);

  • диаграмма последовательностей (Sequence Diagram);

диаграмма состояний (Statechart Diagram).

  • диаграммы взаимодействия;

  • диаграммы деятельности;

  • диаграммы функций;

  • диаграммы состояний.

  • диаграмма классов;

  • диаграмма объектов;

  • составная структурная диаграмма;

  • диаграмма компонент;

  • диаграмма размещения;

  • диаграмма пакетов.

2. Выбор из многих

Диаграммы UML 2.0 относятся к процессным ?

  • диаграммы взаимодействия;

  • диаграммы деятельности;

  • диаграммы функций;

  • диаграммы состояний.

  • диаграммы последовательностей;

  • обзорные диаграммы потоков управления;

  • коммуникационные диаграммы;

  • временнее диаграммы.

  • диаграмма объектов;

  • составная структурная диаграмма;

  • диаграмма компонент;

  • диаграмма размещения;

  • диаграмма пакетов.

  • диаграмма функций (Use Case Diagram);

  • диаграмма классов (Class Diagram);

  • диаграмма взаимодействия (Collaboration Diagram);

  • диаграмма последовательностей (Sequence Diagram);

  • диаграмма состояний (Statechart Diagram).

3. Выбор из одного

На ком этапе RUP используется диаграмма функций для разботки модели функциональных требований ?

бизнес моделирование

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

анализ и проектирование

реализация

4. Выбор из одного

На ком этапе RUP используется диаграмма классов для разработки модели пользовательского интерфейса?

бизнес моделирование

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

анализ и проектирование

реализация

5. Выбор из одного

На ком этапе RUP используется диаграмма деятельности для описания бизнес процессов?

бизнес моделирование

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

анализ и проектирование

реализация

6. Выбор из многих

На каком этапе RUP моделируются правила ?

бизнес моделирование

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

анализ и проектирование

реализация

7. Выбор из одного

На каком этапе RUP разрабатывается БД ?

бизнес моделирование

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

анализ и проектирование

реализация

8. Выбор из многих

На каком этапе RUP используется диаграмма размещения?

бизнес моделирование

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

анализ и проектирование

размещение

9. Выбор из одного

Какой элемент используется для обеспечения коллективной работы в Rational Rose ?

бизнес процесс

класс

пакет

функция

10. Выбор из одного

Какие элементы интерфейса являются основными в Rational Rose ?

  • браузер (browser) или окно просмотра элементов модели;

  • окно документации (documentation window);

  • стандартная панель инструментов (standard panel)..

  • браузер (browser) или окно просмотра элементов модели;

  • окно документации (documentation window);

  • стандартная панель инструментов (standard panel);

  • панель инструментов диаграммы (diagram panel);

  • окно диаграммы (diagram window);

  • спецификации элементов (specification)

  • стандартная панель инструментов (standard panel);

  • панель инструментов диаграммы (diagram panel);

  • окно диаграммы (diagram window);

  • спецификации элементов (specification)

1.5. Практические задания

Тема: Построение диаграммы деятельности в Rational Rose

Задание 1. Построить диаграмму деятельности в соответствие с примером из RUP

Рис. 1.10. Пример диаграммы деятельности из RUP

Тема 2. Описание дисциплины бизнес моделирования

Цели занятия:

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

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

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

  • изучить состав ролей, участвующих в бизнес моделировании и их основные функции;

  • получить навыки работы с визуальным средством моделирования Rational Rose;

  • моделировать потоки работ при проведении бизнес моделирования, ориентированные под собственные потребности при проведении бизнес моделирования в Rational Rose.

2.1. Цели бизнес моделирования

С точки зрения RUP целями бизнес моделирования являются:

  1. Описание бизнес процессов автоматизируемой организации для формирования единого их понимания со стороны заинтересованных в автоматизации организации лиц.

  2. Определение проблем автоматизируемой организации и способов их решения.

  3. Определение требований к автоматизированной системе организации со стороны заинтересованных лиц.

  4. Понимание процесса размещения программного обеспечения в организации.

Для достижения этих целей в RUP описаны виды деятельности проектной команды при проведении бизнес моделирования, главными из которых являются разработка моделей бизнес процессов (Business Use-Case Model) и моделей анализа бизнеса (Business Analysis Model), описывающих реализации бизнес процессов. В некоторых версиях RUP модели анализа бизнеса, описывающие реализацию бизнес процессов, называются объектными моделями бизнеса (Business Object Model).

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

2.2. Концепции бизнес моделирования

Бизнес моделирование в RUP основывается на следующих основных концепциях:

  • функционально - стоимостном анализе (Activity-Based Costing);

  • архитектуре бизнеса;

  • типовых бизнес решений;

  • моделирования больших организаций;

  • различных сценариев бизнес моделирования;

  • е – бизнесе.

2.2.1. Функционально - стоимостной анализ (Activity-Based Costing)

Функционально - стоимостной анализ (activity-based costing - ABC) является методом определения стоимости товаров и услуг на базе функций и ресурсов, задействованных в деятельности предприятия. ABC метод основывается на моделировании деятельности предприятия как множества последовательно выполняемых бизнес процессов.

Для описания бизнес процессов в RUP используются диаграммы деятельностей (activity diagrams) универсального языка моделирования (Unified Modeling Language - UML).

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

  • ресурсы, то есть работники, различные бизнес объекты;

  • стоимости ресурсов и объектов;

  • длительность;

  • накладные расходы.

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

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

На рис. 2.1. представлен пример описания деятельности с ресурсами и расчета стоимости деятельности.

Рис. 2.1. Пример описания деятельности с ресурсами и расчетом стоимости в соответствие с формулой

((1 * 200 USD)*0.5 +100USD) = 200 USD

2.2.2. Архитектура бизнеса

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

Архитектура бизнеса включает взгляд на организацию со следующих основных точек зрения:

  • бизнес процессов;

  • структуры организации.

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

2.2.3. Типовые бизнес решения

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

2.2.4. Моделирования больших организаций

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

Моделирование бизнес-процессов в соответствии с RUP производится с применением технических приемов, применяющихся в рамках собственно разработки программного обеспечения (ПО).

Использование одних и тех же методов для моделирования бизнес-процессов и разработки ПО имеет следующие преимущества:

  • используется один и тот же язык моделирования и одни и те же приемы;

  • моделирование может быть произведено с использованием одного инструментального средства;

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

2.2.5. Различные сценарии бизнес моделирования

В соответствие с RUP могут существовать следующие сценарии бизнес моделирования.

Сценарий 1. Структура организации

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

Сценарий 2. Моделирование бизнес сущностей

Бизнес процессы не рассматриваются. Моделируются только бизнес сущности. Моделирования бизнес сущностей рассматривается как работа над проектом по созданию ПО на начальной фазе проекта и фазе уточнения требований.

Сценарий 3. Бизнес моделирование для нескольких приложений

Результаты деятельности на этапе бизнес моделирования используются для разработки нескольких приложений в различных проектах по созданию ПО. На основе описания бизнес процессов определяются требования к приложениям и разрабатывается их архитектура.

Сценарий 4. Обобщенная модель бизнеса

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

Сценарий 5. Новый бизнес

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

Сценарий 6. Реорганизация

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

2.2.6. Е- бизнес

По RUP е– бизнес или по другому электронный бизнес, связан с созданием систем следующих типов:

  • Customer to business (C2B) – систем, позволяющих заказывать товар через Интернет;

  • Business to business (B2B) – систем, автоматизирующих поставки товаров между компаниями;

  • Business to customer (B2C) – систем, связанных с рассылкой информационных писем;

  • Customer to customer (C2C) – систем, позволяющих производить обмен информацией или совместно ее использовать.

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

2.3. Виды деятельности на этапе бизнес моделирования

Описание основных видов деятельности при проведении работ по бизнес моделированию представлено на рис. 2.2. Для описания видов деятельности на этапе бизнес моделирования используется диаграмма деятельности (activity diagram) универсального языка моделирования (UML). На этой диаграмме элемент представленный на рис. 2.3. обозначает деятельность, связанную с разработкой ПО. Деятельности, расположенные между горизонтальными линиями выполняются параллельно. Деятельности соединены стрелками переходов. Модель имеет начальное и конечное состояние.

Основными видами деятельности при проведении бизнес моделирования являются:

  1. Оценка бизнес статуса организации заказчика.

  2. Описание текущего состояния бизнеса в организации заказчика.

  3. Описание бизнес процессов, уточнение описания бизнес процессов, проектирование реализации бизнес процессов, определение ролей и их обязанностей.

  4. Определение автоматизируемых видов деятельности.

  5. Разработка модели предметной области.

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

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

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

На основе описания бизнес процессов определяются виды деятельности, подлежащие автоматизации.

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

Рис. 2.2. Описание основных видов деятельности при проведении работ по бизнес моделированию по RUP

Рис. 2.3. Изображение деятельности на диаграмме деятельности (activity diagram)

2.4. Результаты бизнес моделирования

С точки зрения RUP, наиболее значимыми артефактами, связанными с бизнес моделированием являются модели бизнес процессов (Business Use-Case Model), модели анализа бизнеса или объектные модели, описывающие реализации бизнес процессов (Business Analysis Model), а также набор документов, в котором отражены результаты бизнес моделирования.

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

Модели анализа показывает, как каждый бизнес процесс реализуется некоторым набором участников бизнес процесса: работниками (business worker), действующими лицами внешними по отношению к бизнес процессу (business actor) и связанными с ними бизнес сущностями (business entity).

Работник бизнес процесса (business worker) есть роль, которую играет тот или иной сотрудник организации, непосредственно участвуя в бизнес процессе.

Бизнес сущность (business entity) есть объект предметной области. Бизнес сущность либо:

  • используется или обслуживается участником бизнес-процесса;

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

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

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

Для описания моделей бизнес процессов используются диаграммы функций (Use Case Diagrams) языка UML.

Для описания реализаций бизнес процессов могут использоваться следующие диаграммы языка UML:

  • диаграммы деятельностей (Activity diagrams);

  • диаграммы классов (Class diagrams);

  • диаграммы состояний (Statechart Diagram);

  • диаграммы последовательностей действий (Sequence diagrams);

  • диаграммы взаимодействия (Collaboration diagrams).

Основными документами, в которых должны быть отражены результаты бизнес моделирования по RUP, являются следующие документы:

  • документ Оценка автоматизируемой организации (Target-Organization Assessment);

  • документ Архитектура бизнеса (Business Architecture Document);

  • документ Словарь терминов предметной области (Business Glossary);

  • документ Бизнес правила (Business Rule);

  • документ Концепция развития организации (Business Vision);

  • документ Описание бизнес процесса (Business Use Case);

  • документ Дополнительные требования к деятельности организации (Supplementary Business Specifications).

В RUP принято документы, модели, элементы модели называть артефактами.

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

Основными ролями в проектной команде по RUP, участвующими в бизнес моделирования являются:

  • бизнес аналитик (Business-Process Analyst);

  • бизнес проектировщик (Business Designer);

  • рецензент моделей бизнес процессов и моделей анализа бизнеса (Business-Model Reviewer).

Основными видами деятельности бизнес аналитика являются:

  • оценка организации заказчика;

  • определение и уточнение целей организации заказчика;

  • определение бизнес правил;

  • разработка словаря бизнес терминов;

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

  • уточнение связей между бизнес процессами;

  • описание архитектуры бизнеса;

  • разработка рекомендаций по бизнес моделированию.

Результатами деятельности бизнес аналитика являются:

  • разработанные модели бизнес процессов и модели анализа или объектные модели, описывающие реализации бизнес процессов;

  • подготовленные документы:

  • документ Оценка автоматизируемой организации (Target-Organization Assessment);

  • документ Архитектура бизнеса (Business Architecture Document);

  • документ Словарь предметной области (Business Glossary);

  • документ Бизнес правила (Business Rule);

  • документ Концепция развития организации (Business Vision);

  • документ Дополнительные требования к деятельности организации (Supplementary Business Specifications);

  • документ Рекомендации по бизнес моделированию (Guidelines).

На рис. 2.4. представлены основные виды деятельности бизнес аналитика и артефакты, за которые он ответственен. Для изображения бизнес аналитика использовался элемент диаграммы функций (use case diagram) языка UML роль бизнес процесса (role), для изображения артефактов - элемент бизнес сущность (business entity). Деятельность бизнес аналитика изображена в виде операции участника бизнес процесса.

Рис. 2.4. Основные виды деятельности бизнес аналитика и артефакты, за которые он ответственен

Основными видами деятельности бизнес проектировщика являются:

  • описание бизнес процессов;

  • определение участников бизнес процессов;

  • детальное описание участников бизнес процессов;

  • детальное описание бизнес сущностей;

  • определение требований к системе на основе документов и моделей.

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

  • документ Описание бизнес процесса (Business Use Case);

На рис. 2.5. представлены основные виды деятельности бизнес проектировщика и артефакты, за которые он ответственен.

Рис. 2.5. Основные виды деятельности бизнес проектировщика и артефакты, за которые он ответственен

Основными видами деятельности рецензента моделей бизнес процессов и моделей анализа бизнеса или объектных моделей бизнеса являются:

  • рецензирование модели бизнес процессов;

  • рецензирование моделей анализа или объектных моделей бизнеса.

Результатами деятельности рецензента моделей бизнес процессов и объектных моделей бизнеса являются:

  • рецензии на модели бизнес процессов;

  • рецензии на модели анализа бизнеса или объектные модели бизнеса.

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

Рис. 2.6. Основные виды деятельности рецензента моделей бизнес процессов и
объектных моделей бизнеса и артефакты, за которые он ответственен

2.6. Задания для самоконтроля

Тест 2. Описание дисциплины бизнес моделирования

1. Выбор из одного

Какие этапы работ включает процесс разработки программного обеспечения RUP ?

  • анализ;

  • проектирование;

  • разработка;

  • тестирование;

  • внедрение

  • бизнес моделирование;

  • определение требований к системе;

  • анализ и проектирование;

  • тестирование;

  • реализация;

  • внедрение;

  • управление проектом;

  • конфигурационное управление;

  • настройка среды проекта

  • управление проектом;

  • управление конфигурациями и изменениями

  • бизнес моделирование;

  • определение требований к системе;

  • анализ и проектирование;

  • тестирование;

  • реализация;

  • внедрение

2. Выбор из одного

Какие шаги включает поток работ дисциплины бизнес моделирования RUP ?

  • описание бизнес процессов;

  • описание бизнес сущностей;

  • описание бизнес правил.

  • оценка бизнес статуса организации заказчика;

  • определение автоматизируемых видов деятельности;

  • разработка модели предметной области;

  • описание текущего состояния бизнеса в организации заказчика

  • оценка бизнес статуса организации заказчика.

  • описание текущего состояния бизнеса в организации заказчика.

  • описание бизнес процессов, уточнение описания бизнес процессов, проектирование реализации бизнес процессов, определение ролей и их обязанностей.

  • определение автоматизируемых видов деятельности.

  • разработка модели предметной области.

  • описание состава бизнес процессов;

  • описание конкретного процесса;

  • определение автоматизируемых видов деятельности;

  • описание бизнес сущностей;

  • описание состояний бизнес сущностей;

  • описание бизнес правил

3. Выбор из одного

Какие роли задействованы при проведении бизнес моделирования?

  • системный аналитик;

  • бизнес аналитик;

  • рецензент моделей;

  • бизнес проектировщик

  • бизнес аналитик

  • бизнес проектировщик;

  • рецензент моделей бизнес процессов и объектных моделей бизнеса.

  • системный аналитик;

  • бизнес аналитик;

  • рецензент моделей бизнес процессов и объектных моделей бизнеса.

  • системный аналитик;

  • бизнес аналитик;

  • рецензент моделей;

  • бизнес проектировщик;

  • архитектор системы

4. Выбор из одного

Какие документы по результатам бизнес моделирования готовит бизнес аналитик ?

  • документ Оценка автоматизируемой организации;

  • документ Архитектура бизнеса;

  • документ Словарь предметной области;

  • документ Бизнес правила;

  • документ Концепция развития организации;

  • документ Дополнительные требования к деятельности организации;

  • документ Рекомендации по бизнес моделированию

  • документ Описание бизнес процесса;

  • документ Дополнительные требования к деятельности организации;

  • документ Рекомендации по бизнес моделированию;

  • документ Концепция развития организации.

  • документ Описание бизнес сущностей;

  • документ Описание ролей

  • документ Рекомендации по бизнес моделированию;

  • документ Рецензии моделей процессов;

  • документ Рецензии объектных моделей

5. Выбор из одного

Какие документы по результатам бизнес моделирования готовит бизнес проектировщик ?

  • документ Описание бизнес сущностей;

  • документ Описание ролей

  • документ Описание бизнес процесса

  • Описание бизнес процесса;

  • документ Дополнительные требования к деятельности организации;

  • документ Рекомендации по бизнес моделированию;

  • документ Концепция развития организации

  • документ Оценка автоматизируемой организации;

  • документ Архитектура бизнеса;

  • документ Словарь предметной области;

  • документ Бизнес правила;

  • документ Концепция развития организации

6. Выбор из одного

Какие документы по результатам бизнес моделирования готовит рецензент моделей бизнес процессов и объектных моделей бизнеса ?

  • рецензии на модели бизнес процессов;

  • рецензии на объектные модели бизнеса

  • документ Рекомендации по бизнес моделированию;

  • документ Рецензии моделей процессов

7. Выбор из одного

На каких концепциях основано бизнес моделирования ?

  • типовые бизнес решения;

  • моделирование больших организаций;

  • различных сценариев бизнес моделирования

  • использование UML;

  • описание бизнес процесса как технологического процесса

  • функционально - стоимостной анализ;

  • архитектура бизнеса;

  • типовые бизнес решения;

  • моделирование больших организаций;

  • различных сценариев бизнес моделирования;

  • е – бизнес

8. Выбор из многих

Цели бизнес моделирования ?

сертификация по ИСО 9000

описание бизнес процессов автоматизируемой организации для формирования единого их понимания со стороны заинтересованных в автоматизации организации лиц

реорганизация бизнес процессов с целью их усовершенствования

определение проблем автоматизируемой организации и способов их решения

понимание процесса размещения программного обеспечения в организации

9. Выбор из одного

Состав любой дисциплины по RUP?

  • цели;

  • концепции;

  • поток работ;

  • описание видов деятельности;

планы работ.

  • описание артефактов;

  • рекомендации;

  • шаблоны документов;

  • планы работ.

  • цели;

  • концепции;

  • поток работ;

  • описание артефактов;

  • рекомендации;

  • шаблоны документов

10. Выбор из одного

Сценарии бизнес моделирования по RUP ?

  • структура предприятия;

  • моделирование бизнес сущностей;

  • обобщенная модель бизнеса;

  • реорганизация

  • бизнес моделирование для нескольких приложений

  • cтруктура предприятия;

  • моделирование бизнес сущностей;

  • бизнес моделирование для нескольких приложений;

  • обобщенная модель бизнеса;

  • новый бизнес;

  • реорганизация

2.7. Практические задания

Тема: Построение потока работ бизнес моделирования в Rational Rose

Задание 1. Построить поток работ в соответствие с примером

Порядок построения потока работ на этапе бизнес моделирования в Rational Rose должен включать следующие шаги:

    1. Запустите Rational Rose.

    2. Создайте в папке Use Case View диаграмму деятельности (activity diagram) с названием Поток работ на этапе бизнес моделирования.

    3. Поместите на поле диаграммы соответствующие элементы как представлено на рис. 2.7.

    4. Соедините их стрелками переходов.

    5. Сохраните модель.

Рис. 2.7. Пример описания потока работ на этапе бизнес моделирования адаптированный под конкретный проект

Задание 2. Построить поток работ документирования на этапе бизнес моделирования

Порядок построения потока работ документирования в Rational Rose должен включать следующие шаги:

  1. Самостоятельно определите порядок документирования на этапе бизнес моделирования.

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

  3. Создайте в папке Use Case View диаграмму деятельности (activity diagram) с названием Порядок документирования на этапе бизнес моделирования.

  4. Поместите на поле диаграммы соответствующие элементы. Соедините их стрелками переходов.

  5. Сохраните модель.

Тема 3. Разработка моделей бизнес процессов

Цели занятия:

  • научиться разрабатывать модели бизнес процессов (Business Use Case Model);

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

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

Моделирование бизнес процессов в соответствие с RUP , для автоматизированной поддержки которых разрабатывается автоматизированная система (АС), производится на этапе Бизнес моделирования (Business Modeling) (рис. 3.1). На этом этапе разрабатываются модель бизнес процессов (Business Use Case Model) и объектные модели бизнеса (Business Object Model) или модели анализа бизнеса (Business Analysis Model).

Рис. 3.1. Этапы разработки ПО и разрабатываемые модели в соответствие с RUP

По RUP модель бизнес процессов (Business Use-Case Model) есть модель процессов, связанных с внешней деятельностью организации по отношению к клиентами и ее партнерам.

В RUP дается следующее определение этой модели: Business Use-Case Model is a model that describes the processes of a business and their interactions with external parties like customers and partners [2].

Модель описывает организацию в терминах бизнес процессов (business use cases) и действующих лиц (субъектов или объектов), внешних по отношению к бизнес процессам (business actors).

По RUP объектная модель бизнес (Business Object Model) или модель анализа бизнеса (Business Analysis Model) есть модель, описывающая реализацию бизнес процессов с точки зрения взаимодействия работников организации и их манипулирования сущностями реального мира. Кроме этих двух классов моделей на этапе бизнес моделировании могут разрабатываться и другие виды моделей. В табл. 1 представлены модели дисциплины бизнес моделирования, их назначение и диаграммы UML, используемые для их разработки.

Таблица 1.

Этапы модели дисциплины бизнес моделирования по RUP

Этап работ по RUP

Модели

Диаграммы UML

Примечания

Бизнес моделирование

(Business Modeling)

Бизнес процессы (business use case model)

Use case diagram

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

Описание бизнес процессов (business object model RUP 2002 или business analysis model RUP 2003)

Activity diagram

Модель отображает поток работ по бизнес процессу. Модель используется для определения модулей подсистем и их функций.

Описание бизнес сущностей (business object model RUP 2002 или business analysis RUP 2003)

Class diagram,

Use case diagram

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

Описание состояния бизнес сущности (business object model RUP 2002 или business analysis model RUP 2003)

Activity diagram, Statechart diagram.

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

Роли и автоматизируемые виды деятельности (business object model RUP 2002 или business analysis model RUP 2003)

Class diagram,

Use case diagram

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

Структура предприятия (business object model RUP 2002 или business analysis model RUP 2003)

Class diagram,

Use case diagram

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

Бизнес правила

Class diagram, Activity diagram

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

В RUP рассматриваются следующие три категории бизнес процессов:

  • процессы важные для организации с коммерческой точки зрения, а именно процессы, связанные с клиентами и партнерами организации;

  • бизнес процессы, связанные с поддержкой коммерческих процессов, такие процессы как, администрирование автоматизированных систем, процессы обеспечения безопасности и т.п.;

  • бизнес процессы, связанные с управлением коммерческими и поддерживающими бизнес процессами.

Для использования RUP для других категорий процессов, например, вспомогательных необходимо нотацию модели бизнес процессов (Business Use-Case Model) адаптировать под указанные процессы.

3.1.1. Цель разработки модели бизнес процессов

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

Целью разработки модели бизнес процессов (Business Use Case Model) является определение бизнес процессов, подлежащих автоматизации, связей между ними и целей, которые они поддерживают.

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

Каждому из выделенных бизнес процессов предлагается в дальнейшем на этапе Определения требований к системе (Requirements) поставить в соответствие подсистему в разрабатываемой системе.

Например, бизнес процесс учета и оформления валютных операций включает два бизнес процесса: учет и оформление валютных операций и учет и оформление депозитных операций.

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

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

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

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

  • получение прибыли Банком

  • мониторинг денежных средств;

  • получение консолидированной отчетности для принятия управленческих решений;

  • создание технологических и должностных инструкций для эффективного управления ресурсами.

Эти же цели могут и являться целями, разрабатываемой системы.

Для разработки модели бизнес процессов (Business Use Case Model), должна использоваться диаграмма функций (Use Case Diagram) унифицированного языка моделирования (UML).

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

Для построения модели бизнес процессов (Business Use Case Model), с использованием диаграммы функций (Use Case Diagram) должны использоваться следующие ее элементы:

  • пакет (package);

  • бизнес процесс (business process);

  • действующее лицо (субъект или объект), внешний по отношению к бизнес процессам - бизнес роль (business actor);

  • класс (class);

  • связи между элементами;

  • заметка (note).

Пакет (package) со стереотипом «бизнес процесс» (рис. 3.2) должен использоваться для изображения группы бизнес процессов.

Рис. 3.2. Пакет для изображения группы бизнес процессов

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

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

Для отображения связей между группами бизнес процессов должна использоваться связь зависимость (dependency) (рис. 3.4). Связь обозначается прерывистой стрелкой.

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

Рис. 3.4. Связь зависимость между двумя группами бизнес процессов

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

Элемент пакет также может использоваться и для группировки целей бизнес процессов, которые они поддерживают. Для отображения группы целей должен использоваться пакет со стереотипом «Цель» (рис. 3.5.).

Рис. 3.5. Пакет для изображения группы целей бизнес процессов

Для изображения собственно бизнес процесса должен использоваться элемент бизнес процесс (Business Use Case) (рис. 3.6).

Рис. 3.6. Пример изображения бизнес процесса

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

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

  • включает «include»;

  • расширяет «extend»;

  • родитель - потомок «generalization».

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

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

На рис. 3.7 представлен пример связи зависимость со стереотипом включает «include».

Рис. 3.7. Пример связи между процессами включает «include»

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

Рис. 3.8. Пример связи между процессами со стереотипом включает «extend»

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

На рис. 3.9 представлен пример использования связи между бизнес процессами со стереотипом родитель – потомок «generalization».

Рис. 3.9. Пример использования связи между бизнес процессами

со стереотипом родитель - потомок «generalization»

На рис. 3.9 процесс родитель есть процесс ведение журналов, процесс потомок – ведение журнала продукции.

Для изображения субъекта или объекта, являющимся инициатором бизнес процесса или потребителем результатов бизнес процесса должен использовать элемент бизнес роль (рис. 3.10).

Рис. 3.10. Изображение элемента Бизнес роль

Роль должна именоваться исходя из контекста.

Для отображения связи между ролью и бизнес процессом должна использоваться связь ассоциация. Можно задавать стереотип для этой связи, например, взаимодействует «communicate». Связь отображается сплошной линией с названием стереотипа. Для отображения этих связей также можно использовать собственные стереотипы.

На рис. 3.11 представлен пример изображения ассоциативной связи между инициатором бизнес процесса и бизнес процессом со стереотипом взаимодействует «communicate».

Рис. 3.11. Пример изображения ассоциативной связи
со стереотипом взаимодействует «communicate» между инициатором бизнес процесса и бизнес процессом

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

Для отображения целей, которые поддерживают бизнес процессы, должен использоваться элемент класс со стереотипом <<цель>>. Связь между бизнес процессом и целью должна отображаться с использованием связи зависимость (dependency) со стереотипом поддерживает (support). Связь должна иметь направление от бизнес процесса к цели, которую он поддерживает. Пример бизнес процесса и цели, которую он поддерживает, представлен на рис. 3.12.

Рис. 3.12. Пример бизнес процесса и цели, которую он поддерживает

Элемент заметка может использоваться для различных комментариев или организации навигации по моделям. Пример использования заметки в качестве комментария представлен на рис. 3. 13.

Рис. 3.13. Пример использования заметки в качестве комментария

Пример модели бизнес процессов кредитования представлен на рис. 3.14. -3.16.

Рис. 3.14. Изображение группы бизнес процессов кредитования

Рис. 3.15. Изображение состава бизнес процессов кредитования

Рис. 3.16. Изображение бизнес процесса кредитования юридических лиц
в валюте, цели, которую он поддерживает и роли, которая его инициирует

3.1.3. Порядок построения модели бизнес процессов в Rational Rose

Порядок создания моделей бизнес процессов и их целей должен включать следующие шаги:

  1. разработку моделей целей бизнес процессов;

  2. разработку модели бизнес процессов.

Состав разрабатываемых моделей должен быть отображен на отдельной диаграмме в Rational Rose, как представлено на рис. 3.17.

Рис. 3.17. Состав разрабатываемых моделей для отображения
бизнес процессов и их целей

Цели бизнес процессов

Цели бизнес процессов должны строиться в пакете «1. Цели бизнес процессов». На поле диаграммы помещаются именованные классы со стереотипом Цель. На рис. 3.18 представлен пример изображения целей кредитования.

Рис. 3.18. Пример целей кредитования

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

Иерархия бизнес процессов

Модель бизнес процессов должна строиться как иерархия диаграмм в пакете «2. Бизнес процессы». Пакет 2 должен считаться моделью первого уровня.

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

Рис. 3.19. Пример изображения групп подпроцессов

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

Последующие уровни вложенности определяется структурой бизнес процессов организации.

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

На рис. 3.20 – 3.23 представлен пример диаграмм модели бизнес процессов последнего уровня иерархии.

Рис. 3.20. Пример изображения бизнес процесса кредитования юридических лиц в рублях
и целей, которые он поддерживает

Рис. 3.21. Пример изображения бизнес процесса кредитования юридических лиц в валюте
и целей, которые он поддерживает

Рис. 3.22. Пример изображения бизнес процесса кредитования физических лиц в рублях
и целей, которые он поддерживает

Рис. 3.23. Пример изображения бизнес процесса кредитования физических лиц в валюте
и целей, которые он поддерживает

3.2. Задания для самоконтроля

Тест 3. Модель бизнес процессов

1. Выбор из одного

Какова цель использования модели бизнес процессов при создании программного обеспечения ?

модель используется для реорганизации бизнес процессов

модель используется для определения подсистем системы

модель используется для документирования целей и процессов организации

2. Выбор из одного

Какая диаграмма используется для построения модели бизнес процессов ?

диаграмма функций

диаграмма классов

диаграмма деятельности

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

3. Выбор из одного

Какие элементы диаграммы функций используются для разработки модели бизнес процессов ?

  • бизнес процесс,

  • бизнес роль

  • пакет (package);

  • бизнес процесс (business use case);

  • действующее лицо (субъект или объект), внешний по отношению к бизнес процессам т.е. бизнес роль (business actor)

  • пакет (package);

  • бизнес процесс (business use case);

  • действующее лицо (субъект или объект), внешний по отношению к бизнес процессам т.е. бизнес роль (business actor);

  • класс (class);

  • связи между элементами;

  • заметка (note)

4. Выбор из одного

Какие стереотипы связей используются между бизнес процессами ?

  • включает;

  • использует;

  • наследует;

  • поддерживает

  • включает;

  • расширяет;

  • наследует;

  • родитель-потомок.

  • включает;

  • расширяет;

  • родитель-потомок

5. Выбор из одного

Какие стереотипы связей используются между бизнес процессами и бизнес ролью ?

  • включает;

  • использует;

  • наследует;

  • поддерживает

  • взаимодействует;

  • стереотип, определенный пользователем.

  • включает;

  • расширяет;

  • поддерживает

6. Выбор из одного

Какие стереотипы связей используются между бизнес процессами и целями, которые он поддерживает?

  • включает;

  • использует;

  • наследует

  • поддерживает;

  • расширяет

  • поддерживает

7. Выбор из одного

В каких ситуациях используется связь между бизнес процессами со стереотипом <<включает>> ?

когда один процесс является общим для других процессов

когда один процесс является частью другого процесса

когда разные бизнес процессы включает в себя один и тот же бизнес процесс

8. Выбор из одного

В каких ситуациях используется связь между бизнес процессами со стереотипом <<родитель потомок >> ?

когда один процесс является общим для других процессов

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

когда один процесс наследует свойства другого процесс

9. Выбор из одного

В каких ситуациях используется связь между бизнес процессами со стереотипом <<расширяет >> ?

когда разные бизнес процессы включает в себя один и тот же бизнес процесс

когда один бизнес процесс обладает всеми свойствами другого бизнес процесса и возможно какими – то дополнительными свойствами

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

10. Выбор из многих

Для чего используется элемент заметка?

для описания бизнес процесса

для комментариев в модели

для навигации по модели

3.3. Практические задания

Тема: Построение модели бизнес процессов в Rational Rose

Задание 1. Построить модель бизнес процессов в соответствие с примером

Постройте модель бизнес процессов в Rational Rose в соответствие с примерами на рис. 3.17- 3.23.

Порядок построения потока работ при построении бизнес процессов в Rational Rose должен включать следующие шаги:

    1. Запустите Rational Rose.

    2. Поименуйте диаграмму функций Main в папке Use Case View окна просмотра элементов модели как: Все модели в разделе Use Case View.

    3. Откройте диаграмму функций Все модели в разделе Use Case View.

    4. Поле диаграммы функций Все модели в разделе Use Case View поименуйте аналогичным образом.

    5. На поле диаграммы функций Все модели в разделе Use Case View поместите два пакета 1. Цели кредитования и 2. Бизнес процессы кредитования как представлено на рис. 3.17.

    6. В пакет 1. Цели кредитования поместите класс и поименуйте его как представлено на рис. 3.18. Поименуйте название поля диаграммы и изображение иконки диаграммы в окне просмотра элементов модели как 1. Цели кредитования.

    7. В пакет 2. Бизнес процессы кредитования поместите пакеты 2.1. Кредитование юридических лиц в рублях, 2.2. Кредитование юридических лиц в валюте, 2.3. Кредитование физических лиц в рублях, 2.4. Кредитование физических лиц в валюте как представлено на рис. 3.21. Поименуйте название поля диаграммы и изображение иконки диаграммы в окне просмотра элементов модели как 2.Бизнес процессы кредитования как представлено на рис. 3.19.

    8. В пакеты 2.1. – 2.4 поместите изображения бизнес процесса, цели, которую он поддерживает, бизнес роли, как представлено на рис. 3.20.-3.23. Не забудьте именование поля диаграмм и изображение иконок диаграмм в окне просмотра элементов.

    1. Сохраните модель.

Задание 2. Построить модель бизнес процессов

Постройте модель бизнес процессов в Rational Rose для процессов международных расчетов Банка.

Процессы международных расчетов в Банке подразделяются на:

  • международный перевод;

  • аккредитивы;

  • гарантии;

  • инкассо.

Все процессы инициирует клиент Банка. Все процессы независимы друг от друга.

Тема 4. Разработка моделей потоков работ

Цели занятия:

  • научиться разрабатывать модели потока работ;

  • понять место данной модели при определении функций разрабатываемой системы на этапе определения требований к системе.

4.1. Цель моделирование потока работ

Как указывалось выше, реализация бизнес процессов по RUP описывается с использованием различных объектных моделей бизнеса или моделей анализа бизнеса. Диаграмма деятельности (activity diagram) языка UML используется в бизнес моделировании для отображения потока работ рассматриваемого бизнес процесса. По модели потока работ определяются виды деятельности, подлежащие автоматизации, те есть бизнес требования. На основе бизнес требований в дальнейшем на этапе определения требований будут определяться функции разрабатываемой системы.

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

Для разработки модели потока работ или, по другому, модели описания бизнес процессов должна использоваться диаграмма деятельности языка UML (activity diagram).

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

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

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

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

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

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

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

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

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

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

  • объект (object);

  • поток объектов (object flow);

  • заметка.

При построении модели потока работ используется нотация диаграммы деятельности, поддерживаемая Rational Rose, которая отличается от нотации этой же диаграммы изложенной в описании UML OMG.

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

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

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

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

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

Для отображения деятельности (activity), которая декомпозируется, можно использовать различные ее обозначения, например, как представлено на рис. 4.2. и 4.3.

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

которая декомпозируется

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

со стереотипом <<Декомпозирована>>

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

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

    Нельзя в одном элементе деятельность (activity) указывать несколько видов деятельности, например, формирует отчет по сделкам и регистрирует сделки в журнале.

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

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

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

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

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

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

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

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

Рис. 4.6. Пример элемента решения (decision)

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

Рис. 4.7. Пример разделительной линий (swimlane)

Синхронизаторы (synchronization) должны использоваться для отражения деятельностей, выполняемых параллельно или множественного выбора. Пример использования синхронизаторов (synchronization) для отображения деятельностей, выполняемых параллельно представлен на рис. 4.8, для отображения множественного выбора – на рис. 4.9.

Рис. 4.8. Пример горизонтальных синхронизаторов (synchronization)

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

Рис. 4.9. Пример горизонтальных синхронизаторов (synchronization)

для отображения множественного выбора

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

Объект может иметь состояние.

Объект должен связываться с деятельностью с использованием элемента поток объектов (object flow) (прерывистая стрелка).

Поток объектов имеет направление.

Если объект по отношению к деятельности является входным, то поток объектов проводится от объекта к деятельности, если выходным – то от деятельности к объекту.

На рис. 4.10 представлен пример объекта, входного потока объектов и деятельности.

Рис. 4.10. Пример деятельности со входным объектом

Для объекта, отображающего действующее лицо или роль бизнес процесса, поток объектов должен быть направлен к деятельности, которую он выполняет, как представлено на рис. 4.11.

Рис. 4.11. Пример действующего лица и его деятельности

Имя объекта должно задаваться исходя из контекста. Имя объекта должно задаваться как имя объекта : имя класса объекта.

Элемент заметка может использоваться для различных комментариев. Пример заметки для описания подразделения, в котором выполняется определенная деятельность, представлен на рис. 4.12.

Рис. 4.12. Пример заметки для описания подразделения,

в котором выполняется определенная деятельность

Заметки следует прикреплять к элементам диаграммы деятельности (activity diagram) с использованием пунктирной линии (anhor note to item).

В RUP существуют следующие рекомендации по разработке модели потока работ с использованием диаграммы деятельности (activity diagram).

Модель потока работ разрабатывается в два этапа.

В начале разрабатывается модель, отображающая основные виды деятельности (macro activity) по описываемому бизнес процессу в целом.

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

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

Однако для построения распределенных систем более удобным является использование следующих разделительных линий:

  • входная/выходная информация;

  • деятельность;

  • роль;

  • подразделение;

  • должность;

  • бизнес правило.

В разделе деятельность следует отражать шаги бизнес процесса или деятельность процесса.

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

Такое использование разделительных линий обусловлено тем, что на основе видов деятельности, отображающих шаги бизнес процесса, будут определяться функции системы, на основе входных/выходных сущностей будет разрабатываться интерфейса пользователя, альбом входных/выходных форм, БД, классы, реализующие соответствующие функции. Информация о ролях, должностях и подразделениях будет использована при рассмотрении вопросов, связанных с разграничением доступа. На основе бизнес правил будут определяться ограничения накладываемые на функции системы.

Для изображения входной/выходной информации и роли должен использоваться элемент объект с соответствующим состоянием (object).

Для изображения шага бизнес процесса должен использоваться элемент деятельность(activity).

Для изображения подразделений, должностей, ссылок на бизнес правила – заметки (note).

Роли, входная и выходная информацию должны связываться с деятельностью через потоки объектов (object flow).

Роли, подразделения должны связываться между собой через связь - пунктирная линия (anhor note to item), прикрепляющую заметки к элементам диаграммы.

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

Рис. 4.13. Декомпозиция обобщенной деятельности

На рис. 4.14 представлен пример основных шагов процесса кредитования, на рис. 4.15 – детальное описание шага Предварительное ознакомление с клиентом и его хозяйственной деятельностью и целью кредитования.

Рис. 4.14. Основные шаги процесса кредитования юридических лиц в валюте

Рис. 4.15. Детальное описание шага процесса кредитования Предварительное ознакомление с клиентом
и его хозяйственной деятельностью и целью кредитования

4.3. Порядок построения модели потока работ бизнес процессов в Rational Rose

Порядок создания моделей с описанием потока работ в Rational Rose должен включать следующие шаги:

        1. Построение диаграммы, отображающей основные виды деятельности.

        2. Построение диаграмм детализирующих основные виды деятельности.

        3. Построение ссылки из диаграммы процессов на диаграмму потока работ.

Построение диаграммы, отображающей основные виды деятельности

Диаграмма деятельности (activity diagram) с основными шагами бизнес процесса должна строиться как поддиаграмма соответствующего бизнес процесса, представленного на диаграмме функций (use case diagram). На рис 4.16. показано, что в окне просмотра элементов модели в Rational Rose диаграмма, отображающая основные шаги процесса Кредитования юридических лиц в валюте (activity diagram) находиться под изображением бизнес процесса Кредитование юридических лиц в валюте представленного на диаграмме функций (use case diagram).

Построение диаграмм, детализирующих основные виды деятельности

Диаграмма деятельности (activity diagram) с детальным описанием каждого основного шага процесса должна строиться как поддиаграмма соответствующего основного шага. На рис 4.17. показано, что в окне просмотра элементов модели в Rational Rose диаграмма деятельности (activity diagram), отображающая детальное описание основного шага процесса Предварительное ознакомление с клиентом и его хоз. деятельностью и целью кредитования, находиться под соответствующим шагом Предварительное ознакомление с клиентом и его хоз. деятельностью и целью кредитования. Деятельности на этой диаграмме, которые подлежат автоматизации, отмечены цветом.

Построение ссылки из диаграммы функций на диаграмму потока работ

Для построения ссылки на диаграмму деятельности (activity diagram) с изображением основных шагов бизнес процесса следует рядом с изображением бизнес процесса на диаграмме функций (use case diagram) поместить заметку. Прикрепить заметку к изображению бизнес процесса. Перетащить на эту заметку из окна просмотра элементов модели диаграмму деятельности (activity diagram) с изображением основных шагов бизнес процесса как представлено на рис. 4.18.

Рис. 4.16. Пример изображения диаграммы с основными шагами процесса кредитования
юридических лиц в валюте в Rational Rose

Рис. 4.17. Пример изображения диаграммы с детальным описанием шага
Предварительное ознакомление с клиентом и его хоз. деятельностью и целью кредитования в Rational Rose

Рис. 4.18. Пример диаграммы функций с изображением процесса Кредитования
юридических лиц в валюте и ссылкой на диаграмму деятельности с
изображением основных шагов соответствующего бизнес процесса в Rational Rose

4.4. Задания для самоконтроля

Тест 4. Модель потока работ

1. Выбор из одного

Какова цель использования модели потока работ при создании программного обеспечения ?

модель используется для реорганизации бизнес процессов

модель используется для определения подсистем системы

модель используется для документирования целей и процессов организации

модель используется для определения функций системы

2. Выбор из одного

Какая диаграмма используется для построения модели потока работ?

диаграмма функций

диаграмма деятельности

диаграмма состояний

диаграмма классов

3. Выбор из одного

Для каких целей в модели потока работ используется элемент деятельность?

описание роли

описание шага бизнес процесса

описание подразделения

описание бизнес правила

4. Выбор из одного

Для каких целей в модели потока работ используется элемент объект?

описание роли

описание ролей, сущностей, должностей

описание ролей, сущностей, должностей, подразделений

описание подразделений

5. Выбор из многих

Для каких целей в модели потока работ используется элемент решение ?

для отображения условия

для отображения слияния

для ветвления

6. Выбор из многих

Для каких целей в модели потока работ используется элемент синхронизатор ?

для отображения множественного выбора

для отображения параллельной деятельности

для отображения деятельностей начинающихся одновременно

для отображения деятельностей заканчивающихся одновременно

7. Выбор из одного

Для каких целей в модели потока работ используется элемент состояние ?

для отображения обобщенных видов деятельностей

для отображения состояния субъектов и объектов

8. Выбор из одного

Какие разделительные линии рекомендуется использовать на диаграммах деятельности ?

  • роль;

  • подразделение;

  • должность;

  • бизнес правило

  • роль;

  • должность;

  • деятельность

  • входная/выходная информация;

  • деятельность;

  • роль;

  • подразделение;

  • должность;

  • бизнес правило

  • роль;

  • подразделение

9. Да или нет

Диаграмма деятельности с изображением потока работ может иметь два начала ?

да

нет

10. Да или нет

Диаграмма деятельности с изображением потока работ может иметь несколько концов ?

да

нет

4.5. Практические задания

Тема: Построение модели потоков работ бизнес процессов в Rational Rose

Задание 1. Построить модель потока работ бизнес процессов в соответствие с примером

Постройте модель потока работ бизнес процесса Кредитования юридических лиц в валюте в Rational Rose в соответствие с примерами на рис. 4.13-4.17.

Порядок построения потока работ в Rational Rose должен включать следующие шаги:

    1. Запустите Rational Rose.

    2. Под изображением бизнес процесса Кредитования юридических лиц в валюте на диаграмме функций (use case diagram) постройте диаграмму деятельности с основными шагами бизнес процесса как представлено на рис. 4.13. – 4.15.

    3. Под изображением основного шага бизнес процесса Предварительное ознакомление с клиентом и его хоз. деятельностью и целью кредитования постройте поддиаграмму деятельности с детальным описанием шага бизнес процесса как представлено на рис. 4.14. – 4.16.

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

    5. Сохраните модель.

Задание 2. Построить модель потока работ

Постройте в Rational Rose модель потока работ процесса международного перевода в Банке в соответствие текстом, представленным в прил. 1. Отметьте цветом шаги бизнес процесса, которые следует автоматизировать. Модель потока работ должна включать основные шаги бизнес процесса международного перевода и детальное описание каждого шага. Обязательным является использование на диаграммах детализирующих основные шаги бизнес процесса разделительных линий и прочих объектов как представлено на рис. 4.12.

Тема 5. Разработка моделей бизнес сущностей и их состояний

Цели занятия:

  • научиться разрабатывать модели бизнес сущностей и их состояний;

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

5.1. Цель моделирование бизнес сущностей и их состояний

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

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

Для разработки модели с описанием документа или бизнес сущности в Rational Rose следует использовать диаграмму классов (class diagram) или диаграмму функций (use case diagram). Бизнес сущность (business entity), представляет абстракцию сущности реального мира. Примерами бизнес сущности могут являться заявка на кредитование, договор, сделка и т.д.

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

Для создания описания документов/бизнес сущностей используется компоненты диаграммы классов/функций:

  • пакет (package);

      • бизнес сущность (business entity);

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

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

  • связь композиция (composition);

  • связь наследование или родитель потомок (generalization).

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

Рис. 5.1. Пример пакета для группировки бизнес сущностей

Элемент бизнес сущность представлен на рис. 5.2.

Рис. 5.2. Примеры элементов диаграммы классов/функций для изображения бизнес сущностей

Бизнес сущности имеют атрибуты. При описании атрибутов бизнес сущности в Rational Rose должны указываться:

  • название атрибута;

  • тип атрибута;

  • стереотип атрибута;

  • начальное значение атрибута (опционально);

  • правила формирования атрибута;

  • примеры значений атрибута.

Пример бизнес сущности с атрибутами представлен на рис. 5.3.

Рис. 5.3. Пример модели документа Заявка клиента

Для задания типов атрибутов могут использоваться типы данных, зарезервированные в Rational Rose или другие типы, например:

  • число;

  • символ;

  • дата;

  • время;

  • логическое значение;

  • объект.

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

Тип данных символ можно использовать для описания строк символов, например, «символ (100)».

Тип данных «дата» можно использовать для атрибутов, которые являются датами.

Тип данных «время» можно использовать для атрибутов, которые являются временем.

Тип данных «логическое значение» можно использовать для атрибутов, которые могут принимать два значения, например «истина», «ложь».

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

Для задания стереотипов атрибутов можно использовать два значения обязательный «О» и необязательный «Н».

Начальное значение атрибута не является обязательным полем.

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

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

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

Если атрибут задается типом данных объект, то начальное значение может задается как имя файла, в котором храниться объект, например, фотография или чертеж.

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

Пример ассоциативной связи между бизнес сущностями представлен на рис. 5.4.

Рис. 5.4. Пример ассоциативных связей между бизнес сущностями

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

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

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

Рис. 5.5. Пример связей композиция между бизнес сущностями

Связь агрегация обозначает связь часть целого (part of), где часть может существовать без целого (контейнер). Пример связи агрегация представлен на рис. 5.6.

Рис. 5.6. Примеры связей агрегация между бизнес сущностями

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

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

1 – ровно одна бизнес сущность;

0...* - ноль или больше бизнес сущностей;

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

0..1 - ноль или одна бизнес сущность;

5..8 - специфический диапазон 5,6,7,8;

4..7, 9 - комбинация 4,5,6,7, или 9 бизнес сущностей.

Примеры мощностей связи композиция и агрегация между бизнес сущностями представлены на рис. 5.4, 5.5.

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

Мощность связи со стороны закрашенного ромба не следует указывать, так как она всегда равна 1 по нотации языка UML.

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

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

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

Рис. 5.7. Примеры связи наследование

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

Рис. 5.8. Пример организационной единицы

5.3. Использование диаграммы состояний или деятельности для разработки
модели состояний документа или бизнес сущности

В некоторых случаях для выявления скрытых атрибутов бизнес сущностей или документов необходимо описать их состояния. Описание состояний бизнес сущностей также может быть весьма полезным при проектировании функций системы, пользовательского интерфейса и БД. Для моделирования состояний бизнес сущностей можно использовать диаграмму состояний (statechart diagram) или диаграмму деятельностей (activity diagram). Модели состояний бизнес сущностей должны строиться на основе описания бизнес процесса. Для моделирования должны быть отобраны бизнес сущности и их состояния из раздела описания бизнес процесса входная/выходная информация.

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

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

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

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

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

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

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

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

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

  • заметка.

На рис. 5.9 представлена модель состояний документа Заявка клиента.

Рис. 5.9. Модель состояний документа Заявка клиента

5.4. Порядок построения модели бизнес сущности и ее состояния в Rational Rose

Порядок создания моделей бизнес сущностей и их состояний должен включать следующие шаги:

  1. Разработку моделей бизнес сущностей.

  2. Разработку моделей состояний бизнес сущностей.

  3. Построение ссылки из диаграмму описания бизнес сущности на диаграммы состояний.

Разработка моделей бизнес сущностей

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

На поле диаграммы «Все модели в разделе Use Case View» должен быть помещен пакет с наименованием:
«3. Модели бизнес сущностей и их состояния», например, как представлено на рис. 5.10.

Диаграмма Main следующего уровня иерархии и ее поле должны быть поименованы как «3. Модели бизнес сущностей и их состояния». На ее поле должны быть размещены пакеты с наименованием: «3.1. Бизнес сущности и их состояния по процессу 1», «3.N. Бизнес сущности и их состояния по процессу N», например, как представлено на рис. 5.11. для процесса кредитования.

Рис. 5.10. Состав моделей в разделе Use Case View

Рис. 5.11. Модель второго уровня при описании бизнес сущностей

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

На предпоследнем уровне иерархии следует размещать пакеты с наименованием бизнес сущностей по конкретному процессу (рис. 5.12), и на самом последнем уровне собственно модель бизнес сущности (внутри соответствующего пакета) (рис. 5.13).

Рис. 5.12.Состав моделируемых бизнес сущностей по процеccу кредитования юридических лиц в валюте

Рис. 5.13. Пример модели заявки клиента

Разработка моделей состояний бизнес сущностей

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

Рис. 5.14. Пример ссылки на модель с описанием состояния бизнес сущности

5.5. Задания для самоконтроля

Тест 5. Модели бизнес сущностей и их состояний

1. Выбор из одного

Какова цель использования модели бизнес сущностей при создании программного обеспечения ?

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

для описания бизнес правил

для проектирования БД

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

2. Выбор из многих

Какая диаграмма используется для построения модели бизнес сущностей ?

диаграмма деятельности

диаграмма классов

диаграмма функций

диаграмма компонент

3. Выбор из одного

Какие элементы используются для описания бизнес сущностей ?

  • пакет (package);

      • бизнес сущность (business entity);

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

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

  • связь композиция (composition).

  • пакет (package);

      • бизнес сущность (business entity);

  • ассоциативная связь (association).

      • бизнес сущность (business entity);

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

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

  • связь композиция (composition);

  • связь наследование (generalization).

  • пакет (package);

      • бизнес сущность (business entity);

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

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

  • связь композиция (composition);

      • связь наследование (generalization)..

4. Выбор из одного

Как в модели бизнес сущностей обозначается связь ассоциация ?

стрелка с треугольником на конце

стрелка с закрашенным ромбом

стрелка с не закрашенным ромбом

простая линия

5. Выбор из одного

Как в модели бизнес сущностей обозначается связь агрегация?

стрелка с треугольником на конце

стрелка с закрашенным ромбом

стрелка с не закрашенным ромбом

простая линия

6. Выбор из одного

Как в модели бизнес сущностей обозначается связь композиция?

стрелка с треугольником на конце

стрелка с закрашенным ромбом

стрелка с не закрашенным ромбом

простая линия

7. Выбор из одного

Как в модели бизнес сущностей обозначается связь наследование ?

стрелка с треугольником на конце

стрелка с закрашенным ромбом

стрелка с не закрашенным ромбом

простая линия

8. Выбор из одного

Что такое мощность связи?

связь между целым и его частью

зависимость между группами бизнес сущностей

количество бизнес сущностей, принимающих участие в связи

9. Да или нет

Могут ли использоваться для описания атрибутов бизнес сущности типы данных определенные пользователем инструментального средства ?

да

нет

10. Да или нет

Может ли модель состояний не иметь конечного состояния ?

да

нет

5.5. Практические задания

Тема: Построение модели бизнес сущности и ее состояния в Rational Rose

Задание 1. Построить модель бизнес сущности и ее состояния в соответствие с примером

Постройте модель бизнес сущностей процесса Кредитования юридических лиц в валюте в Rational Rose в соответствие с примерами на рис. 5.10-5.14.

Задание 2. Построить модель бизнес сущности

Постройте в Rational Rose модель сущности заявления на перевод и модель сущности МТ 100 в формате SWIFT процесса международного перевода в Банке в соответствие с примерами, представленным в прил. 2, 3.

Тема 6. Разработка моделей ролей

Цели занятия:

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

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

6.1. Цель моделирование ролей

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

6.2. Использование диаграммы классов/функций для разработки модели ролей

Для разработки модели ролей и их автоматизируемых функций в Rational Rose следует использовать диаграмму классов (class diagram) или диаграмму функций (use case diagram).Роль представляет абстракцию субъектов и объектов, участвующих в бизнес процессе. Примерами ролей могут являться клиент, продавец, банк и т.д.

Модель с описанием ролей должна строиться на основе описания бизнес процессов. Роли должны моделироваться в разбивке по бизнес процессам. При создании программной системы моделироваться должны только роли, связанные с деятельностями, подлежащими автоматизации.

Для создания описания ролей используется следующие элементы диаграммы классов/функций:

  • пакет (package);

      • бизнес роль (business actor);

      • бизнес работник (business worker);

      • бизнес сущность (business entity);

      • шаг бизнес процесса или функция роли(business use case);

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

  • связь наследование (generalization).

Пакет (рис. 6.1) используется для группировки работников и бизнес ролей.

Рис. 6.1. Пример пакета для группировки работников и ролей

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

Рис. 6.2. Пример элементов диаграммы классов/функций для изображения бизнес ролей,
работников и бизнес сущностей

Роли и работники имеют функции. Изображение функции роли представлено на рис. 6.3.

Рис. 6.3. Пример элементов диаграммы классов/функций для изображения функций бизнес ролей и работников

Связи в модели ролей имеют место между ролью и функций, функцией и сущностями, между ролями.

Между ролью и функцией устанавливается связь, которая называется ассоциацией.

Связь отражает наличие определенной функции у действующего лица. Связь обозначается сплошной линией со стрелкой или без нее. На рис. 6.4. представлен пример связи между действующим лицом и функцией.

Рис. 6.4. Пример связи между ролью и функцией

Связь между ролью и функцией может иметь стереотип, например, <<communicates>> (взаимодействует).

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

Рис. 6.5. Пример связи между ролью, функцией и сущностями

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

Рис. 6.6. Пример связи наследования между бизнес работниками

6.3. Порядок построения модели ролей в Rational Rose

Модель ролей и их автоматизируемых видов деятельности должна строиться следующим образом.

На поле диаграммы «Все модели в разделе Use Case View» должен быть помещен пакет с наименованием: «4. Роли», например, как представлено на рис. 6.7.

Диаграмма Main следующего уровня иерархии и ее поле должны быть поименованы как «4. Роли». На ее поле должны быть размещены пакеты с наименованием: «4.1. Роли по процессу 1», «4.N. Роли по процессу N», например, как представлено на рис. 6.8. для процесса кредитования.

Иерархия пакетов с описанием ролей должна повторять иерархию бизнес процессов.

На предпоследнем уровне иерархии следует размещать пакеты с наименованием ролей по конкретному процессу (рис. 6.9), и на самом последнем уровне собственно модель роли (внутри соответствующего пакета) (рис. 6.10).

Рис. 6.7. Состав моделей в разделе Use Case View

Рис. 6.8. Модель второго уровня при описании ролей

Рис. 6.8. Состав моделируемых ролей по процеccу кредитования юридических лиц в валюте

Рис. 6.10. Пример модели роли Регистратор

6.4. Задания для самоконтроля

Тест 6. Модели ролей

1. Выбор из одного

Какова цель использования модели ролей при создании программного обеспечения ?

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

для описания бизнес правил

Для проектировании функций системы с разграничением доступа

для проектирования БД

2. Выбор из многих

Какая диаграмма используется для построения модели ролей?

диаграмма деятельности

диаграмма классов

диаграмма функций

диаграмма компонент

3. Выбор из одного

Какие элементы используются для разработки модели ролей ?

  • пакет (package);

      • бизнес сущность (business entity);

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

  • связь агрегация (aggregation);

  • связь композиция (composition).

  • пакет (package);

      • бизнес сущность (business entity);

  • ассоциативная связь (association).

  • пакет (package);

      • бизнес роль (business actor);

      • бизнес работник (business worker);

      • бизнес сущность (business entity);

      • шаг бизнес процесса или функция роли (business use case);

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

  • связь наследование (generalization)..

  • пакет (package);

      • бизнес сущность (business entity);

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

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

  • связь композиция (composition);

      • связь наследование (generalization)..

5. Выбор из одного

Как в модели ролей обозначается связь ассоциация ?

стрелка с треугольником на конце

стрелка с закрашенным ромбом

стрелка с не закрашенным ромбом

простая линия

6. Выбор из одного

Как в модели ролей обозначается связь наследование?

стрелка с треугольником на конце

стрелка с закрашенным ромбом

стрелка с не закрашенным ромбом

простая линия

7. Выбор из одного

Как в модели ролей обозначается функция роли?

6.5. Практические задания

Тема: Построение модели ролей в Rational Rose

Задание 1. Построить модель ролей в соответствие с примером

Постройте модель ролей процесса Кредитования юридических лиц в валюте в Rational Rose в соответствие с примерами на рис. 6.7-6.10.

Задание 2. Построить модель ролей

Постройте в Rational Rose модель ролей процесса международного перевода в Банке.

Тема 7. Разработка моделей бизнес правил

Цели занятия:

  • научиться разрабатывать модели бизнес правил;

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

7.1. Цель моделирование бизнес правил

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

7.2. Использование диаграмм деятельности, классов и функций для разработки модели бизнес правил

В общем случае бизнес правила можно разделить на три группы:

      • правила – ограничения;

      • правила – выводы;

      • правила – утверждения.

Правила – ограничения определяют условия поведения и структуру объекта или субъекта.

Правила – выводы определяют условия вывода фактов на основе других фактов или вычисления результатов на основе других результатов.

Правила– утверждения определяют определенные факты.

Правила–ограничения можно разделить на следующие подгруппы:

  • правила перехода (правила перехода объектов или субъектов из одного состояния в другое);

  • правила пред и постусловий (правила определяющие условия, которые должны быть истинны, перед и/или после выполнения деятельности или операции объекта, для гарантии правильности ее выполнения);

  • правила структуры (правила относительно классов, объектов и связей между ними).

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

  • логические выводы (правила, определяющие, что если определенный факт является истинным, то можно сделать определенное заключение);

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

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

  • диаграмма деятельности (activity diagram);

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

  • диаграмма процессов (use case diagram).

Диаграммы деятельности (activity liagram) используются для описаний правил логического вывода, перехода, пред и постусловий, утверждений, расчетных формул. Пример бизнес правила, замоделированный с использованием диаграммы деятельности представлен на рис. 7.1.

Рис. 7.1. Пример модели правила предусловий, разработанной
с использованием диаграммы деятельности (activity diagram)

    Каждому правилу должна быть поставлена в соответствие одна диаграмма деятельности (activity diagram).

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

    Диаграмма деятельности (activity diagram), описывающая правило, должна иметь начало и конец.

    Наименование элементов диаграммы деятельность (activity diagram) должно отображать суть описываемых частей правил.

    Диаграммы классов (class diagram) и процессов (use case diagram) должны использоваться для описаний структурных правил. Пример бизнес правила, замоделированный с использованием диаграммы классов, представлен на рис. 7.2.

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

7.3. Порядок построения модели бизнес правил в Rational Rose

Порядок создания моделей бизнес правил должен включать следующие шаги:

  1. Разработку моделей бизнес правил.

  2. Построение ссылки из диаграммы процессов на диаграмму бизнес правил.

На поле диаграммы «Все модели в разделе Use Case View» должен быть помещен пакет с наименованием: «5. Бизнес правила», например, как представлено на рис. 7.3.

Диаграмма Main следующего уровня иерархии и ее поле должны быть поименованы как «5. Бизнес правила». На ее поле должны быть размещены пакеты с наименованием: «5.1. Бизнес правила по процессу 1», «5.N. Бизнес правила по процессу N», например, как представлено на рис. 7.4. для процесса кредитования.

Иерархия пакетов с описанием бизнес правил должна повторять иерархию бизнес процессов.

На предпоследнем уровне иерархии следует размещать пакеты с наименованием бизнес правила по конкретному процессу (рис. 7.5), и на самом последнем уровне собственно модель правил (внутри соответствующего пакета или под пакетом) (рис. 7.6).

Рис. 7.3. Состав моделей в разделе Use Case View

Рис. 7.4. Модель второго уровня при описании ролей

Рис. 7.5. Состав моделируемых бизнес правила по процеccу кредитования юридических лиц в валюте

Рис. 7.6. Пример модели правила вывода

Рис. 7.7. Пример модели структурного бизнес правила

7.2. Практические задания

Тема: Построение модели бизнес правил в Rational Rose

Задание 1. Построить бизнес правил в соответствие с примером

Постройте модель бизнес правил в Rational Rose в соответствие с примерами на рис. 7.3-7.7.

Задание 2. Построить модель бизнес правил

Постройте в Rational Rose модель двух бизнес правил международного перевода в Банке.

Правило 1: по одному заявлению на переводу оформляется либо одно сообщение SWIFT МТ 100 или одно сообщение TELEX МТ 100.

Правило 2.

Если банк имеет Свфит и корреспондент банка имеет Свифт, то сообщение отправляется по Сфит иначе по телексу.

Предметный указатель

R

Rational Rose 10

А

Артефакт 6

Архитектура бизнеса 21

Ассоциативная связь 61

Б

Бизнес сущность 24

Браузер 11

Д

Диаграмма деятельности 47

м

модели потока работ 47

М

Модель 8

м

модель бизнес процессов 33

М

Мощность связи 61

Н

Назначение иконок диаграммы деятельности 14

Назначение иконок стандартной панели 13

Нотация 8

О

Объекты 50

Окне диаграммы 12

Окно документации 11

П

Панели инструментов 11

Р

Работник бизнес процесса 23

С

Связь агрегация 61

Связь композиция 61

Связь наследование 62

Спецификация элементов 12

У

Унифицированный язык моделирования 7

Ф

Функционально - стоимостной анализ 20

Э

Элемент \«деятельность\» 48

Элемент состояние 48

Глоссарий

Артефакт – модель, элемент модели, документ, программный код, исполняемые файлы, все что создается при разработке программных систем и подлежит версионному контролю

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

Бизнес роль –субъект или объект, находящийся в окружении бизнеса, который инициирует бизнес процесс или получает его результаты

Бизнес сущность – абстракция сущности реального мира

Дисциплина – группа из ролей, задач, артефактов и других средств управления процессом в описании процесса

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

Модель анализа бизнеса – см. объектная модель бизнеса

Нотация - совокупность графических элементов, которые используются в моделях. Она является синтаксисом данного языка моделирования.

Объектная модель бизнес – модель, описывающая реализацию бизнес процесса

Работник – роль участника бизнес процесса, определяет поведение и ответственность индивидуума

Заключение

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

  1. На основе модели классификации бизнес процессов определяются подсистемы разрабатываемой системы.

  2. На основе основных шагов конкретных бизнес процессов определяются компоненты подсистем.

  3. На основе функций конкретных ролей определяются функции компонент.

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

  5. Бизнес правила используются определения правил системы.

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

1. Кролл П, Кратчен Ф. Rational Unified Process – это легко. Руководство по RUP для практиков, М.:КУДИЦ-ОБРАЗ, 2004. – 432.

2. The Rational Unified Process v. 2003.06.00

Приложение 1. Технология оформления международного
перевода в банке

Документы

Деятельность

Подразделения

Действующие лица

Контракт.

Менеджер фирмы заключает контракт на поставку товаров и услуг.

Фирма.

Менеджер фирмы

Контракт.

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

Отдел Банка по работе со счетами клиентов.

Менеджер фирмы

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

Экономист отдела по работе со счетами клиентов выдает менеджеру пустой бланк заявления на международный перевод.

Отдел Банка по работе со счетами клиентов.

Экономист отдела по работе со счетами клиентов.

Пустой бланк заявления на международный перевод,

заполненный бланк заявления на международный перевод.

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

Отдел Банка по работе со счетами клиентов.

Менеджер фирмы

Заполненный бланк заявления на международный перевод с печатью “Сальдо счета позволяет”.

Экономист отдела по работе со счетами клиентов проверяет средства на счете клиента;

проставляет на бланке заявления на международный перевод печать “Сальдо счета позволяет”;

бронирует средства по счету клиента на текущую дату;

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

Отдел Банка по работе со счетами клиентов.

Экономист отдела по работе со счетами клиентов.

Контракт,

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

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

Отдел международных расчетов.

Сотрудник отдела международных расчетов,

менеджер фирмы.

Заполненный бланк заявления на международный перевод с печатью “Сальдо счета позволяет”.

Сотрудник отдела международных расчетов передает бланк заявления на международный перевод в отдел корреспондентских отношений позиционеру для бронирования средств по кор. счету.

Отдел международных расчетов.

Сотрудник отдела международных расчетов.

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

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

Отдел кор. счетов.

Позиционер.

Заполненный бланк заявления на международный перевод с печатью “Сальдо счета позволяет”, кодом корреспондента банка и датой валютирования,

МТ100 в формате телекса,

МТ100 в формате СВИФТ,

Мемориальный ордер,

Контракт.

Сотрудник отдела международных расчетов получает бланк заявления на международный перевод от позиционера и оформляет заявление на перевод в формате телекса или СВИФТ МТ100 и мемориальный ордер с проводками. Оформленные документы и контракт передаются на подпись начальнику отдела международных расчетов.

Отдел международных расчетов.

Сотрудник отдела международных расчетов.

Контракт,

заполненный бланк заявления на международный перевод с печатью “Сальдо счета позволяет”, кодом корреспондента банка, датой валютирования и подписью начальника отдела международных расчетов,

МТ100 в формате телекса с подписью начальника отдела,

МТ100 в формате СВИФТ с подписью начальника отдела,

мемориальный ордер с подписью начальника отдела.

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

Отдел международных расчетов.

Начальник отдела международных расчетов.

МТ100 в формате телекса с подписью начальника отдела,

МТ100 в формате СВИФТ с подписью начальника отдела,

мемориальный ордер с подписью начальника отдела.

Сотрудник отдела международных расчетов передает МТ100 в формате телекса или СВИФТ в отдел телекса или СВИФТ, мемориальный ордер в бухгалтерию.

Отдел международных расчетов.

Сотрудник отдела международных расчетов.

МТ100 в формате телекса с подписью начальника отдела,

МТ100 в формате СВИФТ с подписью начальника отдела.

Сотрудники отдела телекса или СВИФТ отправляют заявления на перевод (МТ100) корреспонденту Банка.

Отдел телекса,

отдел СВИФТ,

Сотрудник отдела телекса,

сотрудник отдела СВИФТ.

Мемориальный ордер с подписью начальника отдела.

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

Бухгалтерия.

Бухгалтер.

Приложение 2.
Форма заявление на перевод валютных средств клиентом банка

<Наименование Банка>

г. Москва

ЗАЯВЛЕНИЕ НА ПЕРЕВОД N_________________

Клиент- перевододатель

Наименование клиента, город расположения клиента на англ. яз. и руск. яз.

В случае необходимости просим связаться с _______________

по тел. ___________________

Просим дебетовать наш счет

N_________________________

и платить

Сумма в инвалюте цифрами и прописью

Банк Бенефициара (наименование, город расположения, полный адрес) на англ яз.

Бенефициар (наименование, город расположения, полный адрес) на англ яз.

Назначение платежа на англ. яз.

Дополнительная информация для бака к переводу

Все расходы и комиссии по переводу просим:

[ ] списать с нашего счета N__________________

[ ] отнести на счет бенефициара

[ ] ваши расходы и комиссию по переводу просим списать с нашего счета

N__________________________, комиссии и расходы иностранных банков отнести на счет бенефициара.

Подпись ПЕЧАТЬ.

Приложение 3. Форма перевода по поручению
клиента мт100 в формате swift

Заголовок сообщения МТ100 должен включать:

BIC код Банка

100

BIC код банка корреспондента.

Текст сообщения:

Тип

N

Наименование поля

Формат

Примеры

М

:20:

Референс сообщения отправителя - Transaction Reference Number

16x

:20:997755XYZ

M

:32A:

Дата валютирования, Код валюты, Сумма - Value Date, Currency Code, Amount

6n3a15n

:32A:920123USD45,

M

:50:

Клиент приказодатель -

Ordering Customer

35x

:50:Fortuna comp.

O

:52:

Приказодатель сообщения -

Odering Institution

A или D

:52A:BITAITRR

O

:53a:

Корреспондент отправителя -

Sender's Correspondent

А, В, D

:53A:NATAU330

O

:54a:

Корреспондент получателя -

Sender's Correspondent

А, В или

D

O

:56a:

Корреспондент банка бенефициара -

Intermediary Bank

А, В или D

:56A:BKTRUS33

О

:57a:

Банк бенефициара -

Account With Bank

А, В или D

:57A:SYSLUS33

:57А://FW SYSLUS33

M

:59:

Клиент – бенефициар

Beneficiary Customer

[/34x]

4*35x

:59:/0123457

GRAND COMPANY

O

:70:

Детали платежа

Details of Payment

4*35x

:70:SELL OF INV 2

O

:71A:

Детали комиссионных расходов

Details of Charges

3a

:71A:OUR

O

:72:

Информация от отправителя

сообщения получателю

Sender to Receiver Information

6*35x

:72:/BNF/YOU REF

//OUR REF 222

BIC код Банка – 8 символов, например, VTBRUMM

х – один символ, кроме 1 и 0; n – цифра; а - один символ;

А - BIC код Банка;

D- адрес Банка;

B – номер счета;

а рядом с номером поля – либо A, либо B, либо D;

M – обязательное поле;

O – опциональное поле.

1

Смотреть полностью


Скачать документ

Похожие документы:

  1. Методические указания по написанию курсовых работ для студентов 1 курса дневной и заочной форм обучения

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

    Методические рекомендации
    В соответствии с учебным планом при изучении дисциплины «Теория государства и права» студенты всех форм обучения должны написать и защитить курсовую работу.
  3. Методические указания к лаб раб по курсу Навигация и лоция. Выпуск 1 17-60

    Методические указания
    «Определение характеристик, построение и анализ основных зависимостей центробежного компрессора турбокомпрессора вспомогательного дизель-генератора». Методические указания к лабораторной работе
  4. Ссная программа для старшеклассников. // Читаем. Учимся. Играем. 2007. №2. С. 75. Литвинов К. Новости обучающего и игрового по: обзор дисков// Мир пк. 2008. № С. 84

    Программа
    Хотите стать математиком?: материалы математического отделения лицея « Всероссийская заочная многопредметная школа». Задачи вступительной контрольной работы.
  5. Анастасия Сергеевна Туманова: М. Ниу вшэ. 2011. 267 с. Аннотация учебно-методический комплекс

    Учебно-методический комплекс
    УМК-ИТФ: Учебно-методический комплекс для слушателей магистерской программы «История, теория и философия права» на 2011-2012 учебный год. Автор-составитель: доктор юридических наук, доктор исторических наук, профессор Анастасия Сергеевна Туманова: М.

Другие похожие документы..