Задание

1. Получите результат описания модели в отчёте Model Report (выбирайте только те поля, которые были описаны в свойствах модели).

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

3. Создайте отчет по стрелкам и отчет по диаграммам декомпозиции.

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

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

6. Сохраните свою модель для дальнейшего проектирования.

Лабораторная работа №7

Тема: Принципы построения моделей процессов в BPwin.

Цель работы: Ознакомить студентов с принципами построения модели Workflow (IDEF3), DFD.

Теоретические сведения

Диаграммы потоков данных (Data Flow Diagramming)

 Диаграммы потоков данных (Data Flow Diagramming, DFD) используются для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет модельную систему как сеть связанных между собой работ. Их можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота.

DFD описывает:

• функции обработки информации (работы);

• документы (стрелки, arrow), объекты, сотрудников или отделы, которые учувствуют в обработке информации;

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

• таблицы для хранения документов (хранилище данных, data store).

Для того чтобы дополнить модель IDEF0 диаграммой DFD, нужно в процессе декомпозиции в диалоге Activity Box Count “кликнуть” по радио-кнопке DFD. В палитре инструментов на новой диаграмме DFD появляются новые кнопки:

- добавить в диаграмму внешнюю ссылку (External Reference). Внешняя ссылка является источником или приемником данных извне модели;

- добавить в диаграмму хранилище данных (Data store). Хранилище данных позволяет описать данные, которые необходимо сохранить в памяти прежде, чем использовать в работах;

- ссылка на другую страницу. В отличие от IDEF0 инструмент offpage reference позволяет направить стрелку на любую диаграмму (а не только на верхний уровень).

В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой. Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы - движение объектов (data flow), хранение объектов (data stores), поставка и распространение объектов (external entities) (рис.7.1).

Рис. 7.1.Пример диаграммы DFD

В отличие от IDEF0, где система рассматривается как взаимосвязанные работы. DFD рассматривает систему как совокупность предметов. Контекстная диаграмма часто включает работы и внешние ссылки. Работы обычно именуются по названию системы, например "Система обработки информации". Включение внешних ссылок в контекстную диаграмму не отменяет требования методологии четко определить цель, область и единую точку зрения на моделируемую систему.

Работы в DFD представляют собой функции системы, преобразующие входы в выходы. Хотя работы изображаются прямоугольниками со скругленными углами, смысл их совпадает со смыслом работ IDEF0 и IDEF3. Так же как работы IDEF3, они имеют входы и выходы, но не поддерживают управления и механизмы, как IDEF0.

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

Стрелки описывают движение объектов из одной части системы в другую. Поскольку в DFD каждая сторона работы не имеет четкого назначения, как в IDEF0, стрелки могут подходить и выходить из любой грани прямоугольника работы. В DFD также применяются двунаправленные стрелки для описания диалогов типа "команда-ответ" между работами, между работой и внешней сущностью и между внешними сущностями (рис.7.2).

Рис 7.2. Внешняя сущность

Рис.7.3. Окно диалога задания стилей стрелок

В отличие от стрелок (рис. 7.3), описывающих объекты в движении, хранилища данных изображают объекты в покое (рис. 7.4).

Рис. 7.4. Хранилище данных

 

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

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

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

Альтернативным подходом является подход, популярный при создании программного обеспечения, называемый событийным разделением (event partitioning), в котором различные диаграммы DFD выстраивают модель системы. Во-первых, логическая модель строится как совокупность работ и документирования того, что они (эти работы) должны делать.

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

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

Нумерация объектов. В DFD номер каждой работы может включать префикс, номер родительской работы (А) и номер объекта. Номер объекта - это уникальный номер работы на диаграмме. Например, работа может иметь номер А.12.4. Уникальный номер имеют хранилища данных и внешние сущности независимо от их расположения на диаграмме. Каждое хранилище данных имеет префикс D и уникальный номер, например D5. Каждая внешняя сущность имеет префикс Е и уникальный номер, например Е5.

Метод описания процессов IDEF3

Для описания логики взаимодействия информационных потоков используют методологию IDEF3 (Workflow Diagramming) – методология моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. Диаграммы Workflow могут быть использованы в моделировании бизнес-процессов для анализа завершенности процедур обработки информации. С их помощью можно описывать сценарии действий сотрудников организации, например последовательность обработки заказа или события, которые необходимо обработать за конечное время. Каждый сценарий сопровождается описанием процесса и может быть использован для документирования каждой функции.

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

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

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

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

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

Единицы работы - Unit of Work (UOW). UOW, также называемые работами (activity), являются центральными компонентами модели. В IDEF3 работы изображаются прямоугольниками с прямыми углами и имеют имя, выраженное отглагольным существительным, обозначающим процесс действия, одиночным или в составе фразы, и номер (идентификатор); другое имя существительное в составе той же фразы обычно отображает основной выход (результат) работы. Часто имя существительное в имени работы меняется в процессе моделирования, поскольку модель может уточняться и редактироваться. Идентификатор работы присваивается при создании и не меняется никогда. Даже если работа будет удалена, ее идентификатор не будет вновь использоваться для других работ. Обычно номер работы состоит из номера родительской работы и порядкового номера на текущей диаграмме.

Связи показывают взаимоотношения работ. Все связи в IDEF3 однонаправлены и могут быть направлены куда угодно, но обычно диаграммы IDEF3 стараются построить так, чтобы связи были направлены слева направо. В IDEF3 различают три типа стрелок, изображающих связи, стиль которых устанавливается через меню Edit/Arrow Style (либо из контекстного меню):

• Старшая (Precedence) - сплошная линия, связывающая единицы работ (UOW). Рисуется слева направо или сверху вниз. Показывает, что работа-источник должна закончиться прежде, чем работа-цель начнется.

• Отношения (Relational Link) - пунктирная линия, использующаяся для изображения связей между единицами работ (UOW) а также между единицами работ и объектами ссылок.

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

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

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

Перекрестки (Junction). Окончание одной работы может служить сигналом к началу нескольких работ, или же одна работа для своего запуска может ожидать окончания нескольких работ. Перекрестки используются для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления.

Для внесения перекрестка необходимо нажать кнопку (добавить в диаграмму перекресток Junction) на палитре инструментов. Возникает диалог Junction Type Editor, в котором необходимо указать тип перекрестка (рис.7.5).

Рис.7.5. Окно диалога Junction Type Editor

Смысл каждого типа приведем в таблице 1.

 Таблица 1

Обозначение	Наименование	Смысл в случае слияния стрелок (Fan-in Junction)	Смысл в случае разветвления стрелок (Fan-out Junction)
	Asynchronous AND	Все предшествующие процессы должны быть завершены	Все следующие процессы должны быть запущены
	Synchronous AND	Все предшествующие процессы завершены одновременно	Все следующие процессы запускаются одновременно
	Asynchronous OR	Один или несколько предшествующих процессов должны быть завершены	Один или несколько следующих процессов должны быть запущены
	Synchronous OR	Один или несколько предшествующих процессов завершены одновременно	Один или несколько следующих процессов запускаются одновременно
	XOR (Exclusive OR)	Только один предшествующий процесс завершен	Только один следующий процесс запускается

 

Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J. Можно редактировать свойства перекрестка при помощи диалога Definition Editor. В IDEF3 стрелки могут сливаться и разветвляться только через перекрестки.

Объект ссылки в IDEF3 выражает некую идею, концепцию или данные, которые нельзя связать со стрелкой, перекрестком или работой. Для создания объекта ссылки необходимо щелкнуть по кнопке на палитре инструментов. Возникает диалог Referent, в котором необходимо указать имя объекта ссылки (рис. 7.6).

Рис.7.6. Окно диалога Referent

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

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

Перейдем на диаграмму А2 и декомпозируем работу "Сборка настольных компьютеров" (рис. 7.7).

Рис. 7.7. Пример диаграммы А2 с объектом декомпозиции

В диалоге Activity Box Count (рис. 7.8) установим число работ 4 и нотацию IDEF3:

Рис. 7.8 Окно диалога Activity Box Count

Возникает диаграмма IDEF3 (рис. 7.9), содержащая работы Unit of Work (UOW), также называемыми единицами работы или работами (activity).

Рис. 7.9 Пример диаграммы IDEF3, содержащей четыре работы Unit of Work

Правой кнопкой мыши щелкнем по работе с номером 1, выберем в контекстном меню Name Editor и внесем имя работы "Подготовка компонентов" (рис.7.10).

Рис.7.10 Окно диалога IDEF3 Activity Properties

Затем в закладке Definition внесем определение работы с номером 1 "Подготавливаются все компоненты компьютера согласно спецификации заказа" (рис. 7.11).

Рис.7.11. Окно диалога IDEF3 Activity Properties закладка Definition

В закладке UOW диалогового окна Activity Properties (рис. 7.12) внесем свойства работы 1 в соответствии с данными таблицы 2.

Таблица 2

Objects	Компоненты: винчестеры, корпуса, материнские платы, видеокарты, звуковые карты, дисководы CD-ROM и флоппи, модемы, программное обеспечение
Facts	Доступные операционные системы: Windows 98, Windows NT, Windows 2000
Constrains	Установка модема требует установки дополнительного программного обеспечения

Рис.7.12 Окно диалога IDEF3 Activity Properties закладка UOW

Внесем в диаграмму еще 3 работы (кнопка ) и присвоим имена работам с номерами 2…7 в соответствии с данными таблицы 3.

Таблица 3

Номер работы	Название работы
2	Установка материнской платы и винчестера
3	Установка модема
4	Установка дисковода CD-ROM
5	Установка флоппи- дисковода
6	Инсталляция операционной системы
7	Инсталляция дополнительного программного обеспечения

После этого диаграмма IDEF3 нашей модели будет выглядеть так, как показано на рисунке 7.13.

Рис.7.13 Пример диаграммы IDEF3 после присвоения работам названий

Создадим объект внешней ссылки с именем " Компоненты" и свяжем его с работой "Подготовка компонентов" (рис. 7.14).

Рис.7.14 Пример связи стрелкой объекта ссылки

и работы "Подготовка компонентов"

Свяжем стрелкой работы "Подготовка компонентов" (выход) и "Установка материнской платы и винчестера" (вход). Изменим стиль стрелки на Object Flow (рис. 7.15) На диаграммах IDEF3 имя стрелки может отсутствовать, хотя BPwin показывает отсутствие имени как ошибку.

Рис.7.15 Результат создания UOW и объекта ссылки

Внесем два перекрестка типа " Asynchronous OR " и свяжем работы с перекрестками, как показано на рисунке 7.16.

Рис.7.16 Пример диаграммы IDEF3 после создания перекрестков " Asynchronous OR "

Правой кнопкой мыши щелкнем по перекрестку для разветвления J1 (fan-out), выберем закладку Name и внесем имя "Компоненты, требуемые в спецификации заказа" (рис. 7.17).

Рис.7.17 Окно диалога Junction Properties закладка Name

Теперь с помощью кнопки палитры инструментов введем в диаграмму еще один объект ссылки и присвоим ему имя "Программное обеспечение". Создадим два перекрестка типа "XOR" и свяжем работы и соответствующие ссылки, как это показано на рисунке 16.

Рис.7.17. Пример диаграммы IDEF3 модели “Деятельность компании”

Задания.

1. Проведите декомпозицию одной из работ модели, выбрав методологию IDEF3.

2. Внесите имена, определения и свойства работ диаграммы IDEF3 в редактор задания свойств работы.

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

4. Внесите перекрестки на диаграмму и опишите их в окне свойств перекрестков.

5. Отразите ICOM-коды и настройте нумерацию на новой диаграмме декомпозиции.

6. Создайте диаграмму дерева узлов и FEO.

7. Задайте значения полей каркаса диаграммы IDEF3.

8. Для каждой работы на диаграмме IDEF3 задайте стоимость.

9. Задайте стоимость каждой работы по каждой статье расхода.

10. Настройте отображение результатов стоимостного анализа на диаграмме.

11. Каждой работе поставьте в соответствие набор UDP.

12. Сохраните свою модель для дальнейшего проектирования.

13. Создайте диаграммы в методологии DFD.

Литература

1. Зиндер Е.З. Новое системное проектирование: информационные технологии и бизнес–реинжиниринг // СУБД. 1995. N.4. 1996. N.1.

2. Зиндер Е.З. Реинжиниринг + информационные технологии = новое системное проектирование // Открытые системы. 1996. N.1.

3. Ивлев В.А. Огороднийчук Д.Л., Попова Т.В. CASE в моделировании деятельности предприятий // Компьютер ПРЕСС. 1997. Август.

4. Калянов Г.Н. CASE: структурный системный анализ (автоматизация и применение). М.: ЛОРИ, 1996.

5. Калянов Г.Н. Консалтинг при автоматизации предприятия (подходы, методы, средства). М.: СИНТЕГ, 1997.

6. Калянов Г.Н. CASE–технологии: консалтинг в автоматизации бизнес–процессов. М.: Горячая линия – Телеком, 2000.

7. Калянов Г.Н. Современные CASE–технологии. М.: ИПУ, 1992.

8. Калянов Г.Н. CASE: компьютерное проектирование программного обеспечения. М.: НИВЦ МГУ, 1994.

9. Калянов Г.Н. Методы и средства системного структурного анализа и проектирования. М.: НИВЦ МГУ, 1995.

10. Калянов Г.Н. Применение CASE–технологий для проектирования систем автоматизации предприятий и учреждений // Приборы и системы. 1997. N.8.

11. Коллинз Г., Блей Д. Структурные методы разработки систем: от стратегического планирования до тестирования. М.: Финансы и статистика, 1986.

12. Маклаков С.В. BPWin и ERWin – CASE–средства разработки информационных систем. М.:Диалог–МИФИ, 1999.

13. Марка Д.А., МакГоуэн К. Методология структурного системного анализа и проектирования SADT. М.: Метатехнология, 1993.

14. Тепляков А.Н. Создание информационной системы предприятия // ComputerDirect. 1996. N.2.

56