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

Подготовка к лабораторной работе

Познакомиться с лекционным материалом по темам “Методологии моделирования предметной области” и “Моделирование бизнес-процессов средствами BPwin”.

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

Общее описание интерфейса BPwin (на основе использования сходного программного продукта Ramus Educational)

BPwin поддерживает три методологии моделирования: функциональное моделирование (IDEF0); описание бизнес-процессов (IDEF3); диаграммы потоков данных (DFD).

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

Рис. 1. Рабочее окно BPwin

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

Основные этапы работы по созданию контекстной диаграммы

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

Рис. 2. Создание нового проекта

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

На первом этапе предлагается внести сведения об авторе, названии проекта и модели. Также можно выбрать тип нотации модели: IDEF0 или DFD.

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

Рис. 4. Второй этап определения свойств проекта

На третьем этапе предлагается дать короткое описание проекту.

Рис. 5. Третий этап определения свойств проекта

На четвёртом этапе предлагается создать несколько основных классификаторов проекта. Например: «Документы», «Персонал» и т.д.

Рис. 6. Четвертый этап определения свойств проекта

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

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

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

Перед построением диаграммы целесообразно настроить свойства программы (цвет, шрифт различных элементов, рис.2.). Меню Сервис – Свойства программы.

Рис. 8. Настройка свойств диаграммы

Модель в BPwin рассматривается как совокупность работ (действий), каждая из которых оперирует с некоторым набором данных. Работа изображается в виде прямоугольников, данные – в виде стрелок. Если щелкнуть по любому объекту модели левой кнопкой мыши, появляется контекстное меню, каждый пункт которого соответствует редактору какого-либо свойства объекта.

Модель может содержать четыре типа диаграмм:

– контекстную диаграмму (в каждой модели может быть только одна контекстная диаграмма);

– диаграммы декомпозиции;

– диаграммы дерева узлов;

– диаграммы только для экспозиции (FEO).

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

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

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

Работы (Activity) обозначают поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Работы изображаются в виде прямоугольников. Все работы должны быть названы и определены. Имя работы должно быть выражено отглагольным существительным, обозначающим действие (например, “Деятельность компании”, “Прием заказа” и т.д.). Работа “Деятельность компании” может иметь, например, следующее определение: " Это учебная модель, описывающая деятельность компании". При создании новой модели (меню File/New) автоматически создается контекстная диаграмма с единственной работой, изображающей систему в целом (рис. 6).

Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, “производить услуги”). На диаграмме функциональный блок изображается прямоугольником (рис. 1). Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом:

– верхняя сторона имеет значение “Управление” (Control);

– левая сторона имеет значение “Вход” (Input);

– правая сторона имеет значение “Выход” (Output);

– нижняя сторона имеет значение “Механизм” (Mechanism).

Рис. 1.Функциональный блок

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

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

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

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

Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

Декомпозиция (Decomposition) является основным понятием стандарта IDEF0. Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

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

Для каждого из элементов IDEF0 – диаграмм, функциональных блоков, интерфейсных дуг – существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием (Glossary) и является описанием сущности данного элемента.

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

В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).

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

Рис. Пример контекстной диаграммы