Цель работы:
- изучение основных принципов методологии IDEF0,
- создание нового проекта в BPWin,
- формирование контекстной диаграммы,
- проведение связей.
Описание системы с помощью IDEF0 называется функциональной моделью. Функциональная модель предназначена для описания существующих бизнес-процессов, в котором используются как естественный, так и графический языки. Для передачи информации о конкретной системе источником графического языка является сама методология IDEF0.
Методология IDEF0 предписывает построение иерархической системы диаграмм - единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция - система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности.
Каждая IDEF0-диаграмм а содержит блоки и дуги. Блоки изображают функции моделируемой системы. Дуги связывают блоки вместе и отображают взаимодействия и взаимосвязи между ними.
Функциональные блоки (работы) на диаграммах изображаются прямоугольниками, означающими поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Имя работы должно быть выражено отглагольным существительным, обозначающим действие.
IDEF0 требует, чтобы в диаграмме было не менее трех и не более шести блоков. Эти ограничения поддерживают сложность диаграмм и модели на уровне, доступном для чтения, понимания и использования.
Каждая сторона блока имеет особое, вполне определенное назначение. Левая сторона блока предназначена для входов, верхняя - для управления, правая - для выходов, нижняя - для механизмов. Такое обозначение отражает определенные системные принципы: входы преобразуются в выходы управление ограничивает или предписывает условия выполнения преобразований, механизмы показывают, что и как выполняет функция.
Блоки в IDEF0 размещаются по степени важности, как ее понимает автор диаграммы. Этот относительный порядок называется доминированием. Доминирование понимается как влияние, которое один блок оказывает на другие блоки диаграммы. Например, самым доминирующим блоком диаграммы может быть либо первый из требуемой последовательности функций, либо планирующая или контролирующая функция, влияющая на все другие.
Наиболее доминирующий блок обычно размещается в верхнем левом углу диаграммы, а наименее доминирующий - в правом углу.
Расположение блоков на странице отражает авторское определение доминирования. Таким образом, топология диаграммы показывает, какие функции оказывают большее влияние на остальные. Чтобы подчеркнуть это, аналитик может перенумеровать блоки в соответствии с порядком их доминирования. Порядок доминирования может обозначаться цифрой, размещенной в правом нижнем углу каждого прямоугольника: 1 будет указывать на наибольшее доминирование, 2 - на следующее и т. д.
Взаимодействие работ с внешним миром и между собой описывается в виде стрелок, изображаемых одинарными линиями со стрелками на концах. Стрелки представляют собой некую информацию и именуются существительными.
Типы стрелок
В IDEF0 различают пять типов стрелок.
Вход - объекты, используемые и преобразуемые работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Стрелка входа рисуется как входящая в левую грань работы.
Управление -.информация, управляющая действиями работы. Обычно управляющие стрелки несут информацию, которая указывает, что должна выполнять работа. Каждая работа должна иметь хотя бы одну стрелку управления, которая изображается как входящая в верхнюю грань работы.
Выход - объекты, в которые преобразуются входы. Каждая работа должна иметь хотя бы одну стрелку выхода, которая рисуется как исходящая из правой грани работы.
Механизм - ресурсы, выполняющие работу. Стрелка механизма рисуется как входящая в нижнюю грань работы. По усмотрению аналитика стрелки механизма могут не изображаться на модели.
Вызов - специальная стрелка, указывающая на другую модель работы. Стрелка вызова рисуется как исходящая из нижней части работы и используется для указания того, что некоторая работа выполняется за пределами моделируемой системы.
Рис. 2.1 Типы стрелок
В методологии IDEF0 требуется только пять типов взаимодействий между блоками для описания их отношений: управление, вход, обратная связь по управлению, обратная связь по входу, выход-механизм. Связи по управлению и входу являются простейшими, поскольку они отражают прямые воздействия, которые интуитивно понятны и очень просты.
Рис. 2.2. Связь по выходу
Рис. 2.3. Связь по управлению
Отношение управления возникает тогда, когда выход одного блока непосредственно влияет на блок с меньшим доминированием.
Обратная связь по управлению и обратная связь по входу являются более сложными, поскольку представляют собой итерацию или рекурсию. А именно выходы из одной работы влияют на будущее выполнение других работ, что впоследствии повлияет на исходную работу.
Обратная связь по управлению возникает тогда; когда выход некоторого блока влияет на блок с большим доминированием.
Связи «выход-механизм» встречаются нечасто. Они отражают ситуацию, при которой выход одной функции становится средством достижения цели для другой.
Рис. 2.4. Обратная связь по входу
Рис. 2.5. Обратная связь по управлению
Связи «выход-механизм» характерны при распределении источников ресурсов (например, требуемые инструменты, обученный персонал, физическое пространство, оборудование, финансирование, материалы).
В IDEF0 дуга редко изображает один объект. Обычно она символизирует набор объектов. Так как дуги представляют наборы объектов, они могут иметь множество начальных точек (источников) и конечных точек (назначений). Поэтому дуги могут разветвляться и соединяться различными способами. Вся дуга или ее часть может выходить из одного или нескольких блоков и заканчиваться в одном или нескольких блоках.
Разветвление дуг, изображаемое в виде расходящихся линий, означает, что все содержимое дуг или его часть может появиться в каждом ответвлении. Дуга всегда помечается до разветвления, чтобы дать название всему набору. Кроме того, каждая ветвь дуги может быть помечена или не помечена в соответствии со следующими правилами:
- непомеченные ветви содержат вес объекты, указанные в метке дугиперед разветвлением;
- ветви, помеченные после точки разветвления, содержат все объектыили их часть, указанные в метке дуги перед разветвлением.
Слияния дуг в IDEFO, изображаемое как сходящиеся вместе линии, указывает, что содержимое каждой ветви идет на формирование метки для дуги, являющейся результатом слияния исходных дуг. После слияния результирующая дуга всегда помечается для указания нового набора объектов, возникшего после объединения. Кроме того, каждая ветвь перед слиянием может помечаться или не помечаться в соответствии со следующими правилами:
Рис. 2.6. Связь выход-механизм
- непомеченные ветви содержат вес объекты, указанные в общей меткедуги после слияния;
- помеченные перед слиянием ветви содержат все или некоторые объекты из перечисленных в общей метке после слияния,
Количественный анализ диаграмм
Для проведения количественного анализа диаграмм перечислим показатели модели:
- количество блоков на диаграмме - N;
- уровень декомпозиции диаграммы - L ;
- сбалансированность диаграммы - В;
- число стрелок, соединяющихся с блоком, - А
Данный набор факторов относится к каждой диаграмме модели. Далее будут перечислены рекомендации по желательным значениям факторов диаграммы.
Необходимо стремиться к тому, чтобы количество блоков на диаграммах нижних уровней было бы ниже количества блоков на родительских диаграммах, т. е. с увеличением уровня декомпозиции убывал бы коэффициент. Таким образом, убывание этого коэффициента говорит о том. что по мере декомпозиции модели функции должны упрощаться, следовательно, количество блоков должно убывать.
Диаграммы должны быть сбалансированы. Это означает, что в рамках одной диаграммы не должно происходить ситуации, изображенной на рис. 2.7: у работы 1 входящих стрелок и стрелок управления значительно больше, чем выходящих. Следует отметить, что данная рекомендация может не выполняться в моделях, описывающих производственные процессы. Например, при описании процедуры сборки в блок может входить множество стрелок, описывающих компоненты изделия, а выходить одна стрелка -- готовое изделие.
Рис. 2.7. Пример несбалансированной диаграммы
Введем коэффициент сбалансированности диаграммы
Необходимо стремиться, чтобы Кь был минимален для диаграммы.
Помимо анализа графических элементов диаграммы необходимо рассматривать наименования блоков. Для оценки имен составляется словарь элементарных (тривиальных) функций моделируемой системы. Фактически в данный словарь должны попасть функции нижнего, уровня декомпозиции диаграмм. Например, для модели БД элементарными могут являться функции «найти запись», «добавить запись в БД», в то время как функция «регистрация пользователя» требует дальнейшего описания.
После формирования словаря и составления пакета диаграмм системы необходимо рассмотреть нижний уровень модели. Если на нем обнаружатся совпадения названий блоков диаграмм и слов из словаря, то это говорит, что достаточный уровень декомпозиции достигнут. Коэффициент, количественно отражающий данный критерий, можно записать как L*C - произведение уровня модели на число совпадений имен блоков со словами из словаря. Чем ниже уровень модели (больше L), тем ценнее совпадения.
Инструментарий BPWin
При запуске BPWin по умолчанию появляется основная панель инструментов, палитра инструментов и Model Explorer.
При создании новой модели возникает диалог, в котором следует указать, будет ли создана модель заново, или она будет открыта из репозитария ModelMart, внести имя модели и выбрать методологию, в которой будет построена модель (рис. 2.8).
Рис.2.8 Диалог создания модели
BPWin поддерживает три методологии - IDEF0, IDEF3 и DFD. В BPWin возможно построение смешанных моделей, т. е. модель может содержать одновременно как диаграммы IDEF0, так и IDEF3 и DFD. Состав палитры инструментов изменяется автоматически, когда происходит переключение с одной нотации на другую.
Модель в BPWin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Если щелкнуть по любому объекту модели левой кнопкой мыши, появляется всплывающее контекстное меню, каждый пункт которого соответствует редактору какого-либо свойства объекта.
Пример
Построение модели системы должно начинаться с изучения всех документов, описывающих ее функциональные возможности. Одним из таких документов является техническое задание, а именно разделы "Назначение разработки", "Цели и задачи системы" и "Функциональные характеристики системы " .
После изучения исходных документов и опроса заказчиков и пользователей системы необходимо сформулировать цель моделирования и определить точку зрения на модель. Рассмотрим технологию ее построения на примере системы "Служба занятости в рамках вуза", основные возможности которой были описаны в лабораторной работе № 1.
Сформулируем цель моделирования: описать функционирования системы, которое было бы понятно ее пользователю, не вдаваясь в подробности, связанные с реализацией. Модель будем строить с точки зрения пользователей (студент, преподаватель, администратор, деканат, фирма).
Начнем с построения контекстной IDEF0-диаграммы- Согласно описанию системы основной функцией является обслуживание ее клиентов посредством обработки запросов, от них поступающих. Таким образом, определим единственную работу контекстной диаграммы как «Обслужить клиента системы». Далее определим входные и выходные данные, а также механизмы и управление.
Для того чтобы обслужить клиента, необходимо зарегистрировать его в системе, открыть доступ к БД и обработать его запрос. В качестве входных данных будут использоваться «имя клиента», «пароль клиента», «исходная БД», «запрос клиента». Выполнение запроса ведет либо к получению информации от системы, либо к изменению содержимого БД (например, при составлении экспертных оценок), поэтому выходными данными будут являться «отчеты» и «измененная БД». Процесс обработки запросов будет выполняться монитором системы под контролем администратора.
Контекстная диаграмма
Таким образом, определим контекстную диаграмму системы (рис. 2.9).
Рис 2.9. Контекстная диаграмма системы
Проведем декомпозицию контекстной диаграммы, описав последовательность обслуживания клиента:
- Определение уровня доступа в систему.
- Выбор подсистемы.
- Обращение к подсистеме.
- Изменение БД (при необходимости).
Получим диаграмму, изображенную на рис. 2.10.
Закончив декомпозицию контекстной диаграммы, переходят к декомпозиции диаграммы следующего уровня. Обычно при рассмотрении третьего и более нижних уровней модели возвращаются к родительским диаграммам и корректируют их.
Рис. 2.10. Декомпозиция работы «Обслуживание, клиента системы»
Декомпозируем последовательно все блоки полученной диаграммы. Первым этапом при определении уровня доступа в систему является определение категории пользователя. По имени клиента осуществляется поиск в базе пользователей, определяя его категорию. Согласно определенной категории выясняются полномочия, предоставляемые пользователю системы. Далее проводится процедура доступа в систему, проверяя имя и пароль доступа. Объединяя информацию о полномочиях и уровне доступа в систему, для пользователя формируется набор разрешенных действий. Таким образом, определение уровня доступа в систему будет выглядеть как показано на рис. 2.11.
Рис. 2.11. Декомпозиция работы «Определение уровня доступав систему»
После прохождения процедуры доступа в систему монитор анализирует запрос клиента, выбирая подсистему, которая будет обрабатывать запрос. Декомпозиция работы «Обращение к подсистеме» не отвечает цели и точке зрения модели. Пользователя системы не интересуют внутренние алгоритмы ее работы. В данном случае ему важно, что выбор подсистемы будет произведен автоматически, без его вмешательства, поэтому декомпозиция обращения к подсистеме только усложнит модель.
Декомпозируем работу «Обработка запроса клиента», выполняемую подсистемой обработки запросов, определения категорий и полномочий пользователей. Перед осуществлением поиска ответа на запрос необходимо открыть БД (подключиться к ней). В общем случае БД может находиться на удаленном сервере, поэтому может потребоваться установление соединения с ней. Определим последовательность работ:
- Открытие БД.
- Выполнение запроса.
- Генерация отчетов.
После открытия БД необходимо сообщить системе об установлении соединения с БД, после чего выполнить запрос и сгенерировать отчеты для пользователя (рис. 2.12).
Необходимо отметить, что в «Выполнение запроса» включается работа различных подсистем. Например, если запрос включает в себя тестирование, то его будет исполнять подсистема профессиональных и психологических тестов. На этапе выполнения запроса может потребоваться изменениесодержимого БД, например при составлении экспертных оценок. Поэтому, на диаграмме необходимо предусмотреть такую возможность.
Рис. 2.12.
Корректировка диаграммы
При анализе полученной диаграммы возникает вопрос, по каким правилам происходит генерация отчетов? Необходимо наличие заранее сформированных шаблонов, по которым будет производиться выборка из БД, причем эти шаблоны должны соответствовать запросам и должны быть заранее определены. Кроме того, клиенту должна быть предоставлена возможность выбора формы отчета.
Скорректируем диаграмму, добавив в нее стрелки «Шаблоны отчетов» и «Запросы на изменение БД» и туннельную стрелку «Клиент системы». Туннелирование «Клиента системы» применено для того, чтобы не выносить стрелку на диаграмму верхнего, так как функция выбора формы отчета не является достаточно важной для отображения ее на родительской диаграмме.
Изменение диаграммы потянет за собой корректировку всех родительских диаграмм (рис. 2.13 - 2.15).
Декомпозицию работы «Выполнение запроса» целесообразно провести при помощи диаграммы DFD (лабораторная работа № 3), так как методология IDEF0 рассматривает систему как совокупность взаимосвязанных работ, что плохо отражает процессы обработки информации.
Рис. 2.13. Декомпозиция работы «Обработка запроса клиента»
Рис. 2.14. Декомпозиция работы «Обслуживание клиента системы»(вариант 2)
Рис. 2.15. Контекстная диаграмма системы (вариант 2)
Перейдем к декомпозиции последнего блока «Изменение БД». С точки зрения клиента, данные системы располагаются в одной БД. Реально в системе присутствует шесть БД:
- БД пользователей,
- БД студентов,(вариант 2)
- БД вакансий,
- БД успеваемости,
- БД тестов,
- БД экспертных оценок,
- БД резюме.
Согласно цели моделирования клиенту важно понимать, что поступившие данные не сразу обновляются в системе, а проходят дополнительный этап обработки и контроля. Алгоритм изменения можно сформулировать следующим образом:
- Определяется БД, в которой будет изменяться информация.
- Оператором формируется временный набор данных и предоставляется администратору.
- Администратор осуществляет контроль данных и вносит их в БД.
Данную модель реализовать другим способом, предоставив возможность обновления БД непосредственно по запросам, минуя процесс контроля данных. В этом случае необходимо обеспечить контроль целостности БД для избежания ее повреждения. В этом случае диаграмма будет выглядеть следующим образом (рис. 2.17).
Рис. 2.16. Декомпозиция работы «Изменение БД»
Рис. 2.17. Декомпозиция работы «Изменение БД» (вариант 2) Для первого варианта, изображенного нарис. 2.12
Проведение дальнейшей декомпозиции «Изменения БД» будет усложнять модель, объясняя, как осуществляется физическое изменение БД в системе. При этом пользователь не получит никакой дополнительной информации о работе системы службы занятости. Декомпозицию этой работы целесообразно проводить в процессе проектирования БД системы на этапе создания логической модели БД.
Декомпозиция работы «Выполнение запроса» будет проведена в следующей лабораторной работе, иллюстрируя применение диаграмм DFD для описания процессов обработки информации.
Проведем количественный анализ моделей, изображенных на рис. 2.12 и 2.13, согласно вышеописанной методике. Рассмотрим поведение коэффициента ^ у этих моделей. У родительской диаграммы «Обработка запроса клиента» коэффициент равен 4/2 = 2, а диаграммы декомпозиции 3/3 = 1. Значение коэффициента убывает, что говорит об упрощении описания функций с понижением уровня модели.
Рассмотрим изменение коэффициента К b у двух вариантов моделей.
для второго варианта
Коэффициент К b не меняет своего значения, следовательно, сбалансированность диаграммы не меняется.
Будем считать, что уровень декомпозиции рассмотренных диаграмм достаточен для отражения цели моделирования, и на диаграммах нижнего Уровня в качестве наименований работ используются элементарные функции (с точки зрения пользователя системы).
Подводя итоги рассмотренного примера необходимо отметить важность рассмотрения нескольких вариантов диаграмм при моделировании системы. Такие варианты могут возникать при корректировке диаграмм, как это было сделано с «Обработкой запроса клиента» или при создании альтернативных реализаций функций системы (декомпозиция работы «Изменение БД»). Рассмотрение вариантов позволяет выбрать наилучший и включить его в пакет диаграмм для дальнейшего рассмотрения.
Контрольные вопросы
Список Контрольных вопросов :
- Что представляет собой модель в нотации IDEF0?
- Что обозначают работы в IDEF0?
- Назовите порядок наименования работ?
- Какое количество работ должно присутствовать на одной диаграмме?
- Что называется порядком доминирования?
- Как располагаются работы по принципу доминирования?
- Каково назначение сторон прямоугольников работ на диаграммах?
- Перечислите типы стрелок.
- Назовите виды взаимосвязей.
- Что называется граничными стрелками?
- Объясните принцип именования разветвляющихся и сливающихся стрелок.
- Какие методологии поддерживаются BPWin?
- Перечислите основные элементы главного окна BPWin.
- Опишите процесс создания новой модели в BPWin.
- Как провести связь между работами?
- Как задать имя работы.
- Опишите процесс декомпозиции работы.
- Как добавить работу на диаграмму?
- Как разрешить туннелированные стрелки?
- Может ли модель BPWin содержать диаграммы нескольких методологий?
- Контроль корректности моделей. За счет встроенных средств BPwin 7 осуществляет контроль некорректных связей и представления элементов моделей. Это повышает качество моделей и улучшает возможности интеграции с другими средствами моделирования;
- Встроенный генератор отчетов. С помощью этого генератора можно создать шаблон необходимого отчета и применять этот шаблон для любых моделей BPwin 7. Отчеты могут представляться в форматах HTML, RTF, TXT, PDF.
Книги по BPwin
В настоящее время выпускается не так много книг по программному продукту BPwin. Это связано с тем, что данное CASE средство сдает свои позиции, и поддержка продукта прекращается. Тем не менее, в продаже еще существует часть популярной и полезной литературы по работе с BPwin , а также развитием этого ПО в AllFusion Process Modeler.
Книги, представленные на данной странице, можно приобрести как в бумажном, так и в электронном виде через партнера сайта – онлайн-магазин Ozon.ru
Книга выпущена в 2002г. В данной книге представлено описание работы с наиболее популярной версией BPwin 4.0. Она содержит описание методологии моделирования, лежащей в основе BPwin (методы IDEF0, DFD, IDEF3), описание программного продукта BPwin и его возможностей, методы построения отчетов с помощью BPwin , объясняется построение модели данных, и даются примеры использования BPwin и Erwin для моделирования бизнес процессов. Также, в книге даются упражнения по созданию функциональной модели деятельности предприятия.
Книга предназначена для бизнес аналитиков и специалистов, занимающихся моделированием бизнес-процессов.
Данная книга выпущена в 2007г. и представляет описание работы в пакете моделирования AllFusion Process Modeler версии 4.1.4 и All Fusion PM . Книга дает описание методологий функционального моделирования IDEF 0, IDEF 3 и моделирования данных DFD . Приводится подробное применение пакета AllFusion для целей моделирования, указываются задачи, которые могут решаться с помощью данного пакета. Также, приводятся примеры эффективного использования AllFusion в различных сферах.
Книга будет полезна для системных и бизнес аналитиков, а также всех, кто интересуется вопросами моделирования и анализа бизнес процессов.
Эта книга представляет описание и порядок работы с пакетом моделирования AllFusion Process Modeler 4.1. Книга выпущена тем же автором, что и книга «Моделирование бизнес-процессов с BPwin 4.0 » По своей сути, книга представляет обновленную редакцию предыдущего издания. В состав книги входит 5 глав. В первой главе дается описание инструментальных средств BPwin 4.1, описывается создание моделей в нотациях IDEF0, IDEF3, DFD, рассказывается о порядке проведения стоимостного анализа. Во второй главе рассказывается о порядке создания отчетов с помощью средств AllFusion Process Modeler 4.1. Третья глава посвящена вопросам связывания модели процессов и моделей данных. В четвертой главе обсуждается вопрос групповой разработки моделей в AllFusion Process Modeler 4.1. В четвертой главе собраны 16 упражнений по созданию моделей процессов для самостоятельной работы читателей.
Это более ранняя версия книги «Эффективное моделирование с AllFusion Process Modeler ». Она была выпущена в 2004 г. Содержание книги включает в себя вопросы моделирования по нотациям IDEF0, DFD, IDEF3. Дается описание пакета AllFusion Process Modeler 4.1. и его применение для целей разработки моделей бизнес процессов.
Книга может быть полезна специалистам, занимающимся вопросами реорганизации бизнес процессов, моделированием деятельности предприятий, бизнес аналитикам, специалистам по функциональному моделированию и ИТ специалистам.
Инструментарий и элементы интерфейса BPWin
При запуске BPWin по умолчанию появляется основная панель инструментов, палитра инструментов и Model Explorer.
Функциональность панели инструментов доступна из основного меню BPWin (табл. 1).
Описание элементов управления основной панели инструментов BPWin
Таблица 1
Элемент управления | Описание | Соответствующий пункт меню |
Создать новую модель | File – New | |
Открыть модель | File – Open | |
Сохранить модель | File – Save | |
Напечатать модель | File – Print | |
Выбор масштаба | View – Zoom | |
Масштабирование | View – Zoom | |
Проверка правописания | Tools - Spelling | |
Включение и выключение навигатора модели Model Explorer | View – Model Explorer | |
Включение и выключение дополнительной панели инструментов ModelMart | ModelMart |
При создании новой модели возникает диалог, в котором следует указать, будет ли создана модель заново, или она будет открыта из репозитария ModelMart, внести имя модели и выбрать методологию, в которой будет построена модель (рис. 1).
BPWin поддерживает три методологии – IDEF0, IDEF3 и DFD. В BPWin возможно построение смешанных моделей, т.е. модель может содержать одновременно как диаграммы IDEF0, так и IDEF3 и DFD. Состав палитры инструментов изменяется автоматически, когда происходит переключение с одной нотации на другую.
Модель в BPWin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Если щелкнуть по любому объекту модели левой кнопкой мыши, появляется всплывающее контекстное меню, каждый пункт которого соответствует редактору какого-либо свойства объекта.
Для построения диаграмм в BPWin используется три панели инструментов для каждого типа диаграмм:
Рис. 1. Диалог создания модели
Диаграммы IDEF0
Кнопка для добавления работы на диаграмму
Проведение новой связи
Инструмент редактирования объектов
Декомпозиция диаграммы
Диаграммы DFD
Добавление стрелки потока данных в диаграмму
Декомпозиция диаграммы
Диаграммы IDEF3
«старшая» связь
Каркас диаграммы
На рис.2 показан типичный пример контекстной диаграммы с граничными рамками, которые называются каркасом диаграммы . Каркас содержит заголовок (верхняя часть рамки, табл.2) и подвал (нижняя часть, табл.3). Заголовок каркаса используется для отслеживания диаграммы в процессе моделирования. Нижняя часть используется для идентификации и позиционирования в иерархии диаграмм.
Значения полей каркаса задаются в диалоге Diagram Properties (в меню Edit/Diagram Properties).
Рис.2. Контекстная диаграмма
Поля заголовка каркаса (слева направо)
Таблица 2
Поле | Назначение |
Used At | Используется для указания на родительскую работу в случае, если на текущую диаграмму ссылались посредством стрелки вызова. |
Author, Date, Rev, Project | Имя создателя диаграммы, дата создания и имя проекта, в рамках которого была создана диаграмма. REV - дата последнего редактирования диаграммы. |
Notes 1 2 3 4 5 6 7 8 9 10 | Используется при проведении сеанса экспертизы. Эксперт должен (на бумажной копии диаграммы) указать число замечаний, вычеркивая цифру из списка каждый раз при внесении нового замечания. |
Status | Статус отображает стадию создания диаграммы, отображая все этапы публикации. |
Working | Новая диаграмма, кардинально обновленная диаграмма или новый автор диаграммы. |
Draft | Диаграмма прошла первичную экспертизу и готова к дальнейшему обсуждению. |
Recommended | Диаграмма и все ее сопровождающие документы прошли экспертизу. Новых изменений не ожидается. |
Publication | Диаграмма готова к окончательной печати и публикации. |
Reader | Имя читателя (эксперта). |
Date | Дата прочтения (экспертизы). |
Context | Схема расположения работ в диаграмме верхнего уровня. Работа, являющаяся родительской, показана темным прямоугольником, остальные - светлым. На контекстной диаграмме (А-0) показывается надпись TOP. В левом нижнем углу показывается номер по узлу родительской диаграммы. |
Поля подвала каркаса (слева направо)
Таблица 3
Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Работы изображаются в виде прямоугольников (блоков), данные – в виде стрелок (дуг).
Основу методологий составляет графический язык описания бизнес-процессов. Функциональные модели представлены совокупностью иерархически упорядоченных и логически связанных диаграмм. Каждая диаграмма располагается на отдельном листе.
Можно выделить четыре типа диаграмм:
Контекстную диаграмму А-0 (в каждой модели может быть только одна контекстная диаграмма);
Диаграммы декомпозиции (в том числе диаграмма первого уровня декомпозиции А0, раскрывающая контекстную);
Диаграммы дерева узлов;
Диаграммы только для экспозиции (FEO).
Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой (как правило, здесь описывается основное назначение моделируемого объекта). После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией , а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции .
После декомпозиции контекстной диаграммы (т.е., получения диаграммы А0) проводится декомпозиция каждого блока диаграммы А0 на более мелкие фрагменты и так далее, до достижения нужного уровня подробности описания. После каждого сеанса декомпозиции проводятся сеансы экспертизы - эксперты предметной области (обычно это интервьюируемые аналитиками сотрудники предприятий) указывают на соответствие реальных бизнес-процессов созданным диаграммам. Найденные несоответствия исправляются, и только после прохождения экспертизы без замечаний можно приступать к следующему сеансу декомпозиции. Так достигается соответствие модели реальным бизнес-процессам на любом и каждом уровне модели. Синтаксис описания системы в целом и каждого ее фрагмента одинаков во всей модели.
Диаграмма дерева узлов показывает иерархическую зависимость работ, но не взаимосвязи между работами. Диаграмм деревьев узлов может быть в модели сколько угодно, поскольку дерево может быть построено на произвольную глубину и не обязательно с корня.
Диаграммы для экспозиции (FEO) строятся для иллюстрации отдельных фрагментов модели, для иллюстрации альтернативной точки зрения, либо для специальных целей.
Элементы диаграмм методологии IDEF0
Методология IDEF0 предписывает построение иерархической системы диаграмм – единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция – система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности.
Каждая IDEF0-диаграмма содержит блоки и дуги . Блоки изображают функции моделируемой системы. Дуги связывают блоки вместе и отображают взаимодействия и взаимосвязи между ними.
Функциональные блоки или работы (Activity) на диаграммах изображаются прямоугольниками, означающими поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Имя работы должно быть выражено отглагольным существительным, обозначающим действие (например, «Изготовить деталь», «Принять заказ» и т.д.). Работу можно добавить в диаграмму, щелкнув по кнопке на палитре инструментов, а затем по свободному месту на диаграмме.
Каждая сторона блока имеет определенное назначение. Левая сторона блока предназначена для входов, верхняя – для управления, правая – для выходов, нижняя – для механизмов. Такое обозначение отражает определенные системные принципы: входы преобразуются в выходы, управление ограничивает или предписывает условия выполнения преобразований, механизмы показывают, что и как выполняет функция.
Блоки в IDEF0 размещаются по степени важности, как ее понимает автор диаграммы. Этот относительный порядок называется доминированием . Доминирование понимается как влияние, которое один блок оказывает на другие блоки диаграммы. Наиболее доминирующий блок обычно размещается в верхнем левом углу диаграммы, а наименее доминирующий - в правом углу (рис. 5).
Расположение блоков на странице отражает авторское определение доминирования. Таким образом, топология диаграммы показывает, какие функции оказывают большее влияние на остальные. Чтобы подчеркнуть это, аналитик может перенумеровать блоки в соответствии с порядком их доминирования. Порядок доминирования может обозначаться цифрой, размещенной в правом нижнем углу каждого прямоугольника: 1 будет указывать на наибольшее доминирование, 2 - на следующее и т. д,
Для внесения имени работы следует щелкнуть по работе правой кнопкой мыши, выбрать в меню пункт Name Editor и в появившемся диалоге внести имя работы (рис.3).
Рис. 3. Внесение имени работы
Диаграммы декомпозиции (рис.5) содержат родственные работы, т.е. дочерние работы, имеющие общую родительскую работу.
Для создания диаграммы декомпозиции следует щелкнуть по кнопке и выбрать на диаграмме работу, которую необходимо декомпозировать.
Возникает диалог Activity Box Count (рис.4), в котором следует указать нотацию новой диаграммы.
Рис.4. Выбор нотации диаграммы
На диаграмме декомпозиции (рис. 5) работы нумеруются автоматически слева направо. Номер работы показывается в правом нижнем углу. В левом верхнем углу изображается небольшая диагональная черта, которая показывает, что данная работа не была декомпозирована.
Рис. 5. Диаграмма декомпозиции
Взаимодействие работ с внешним миром и между собой описывается в виде стрелок , изображаемых одинарными линиями со стрелками на концах. Стрелки представляют собой некую информацию и именуются существительными (например, «Заготовка», «Изделие», «Заказ»).
В IDEF0 различают пять типов стрелок .
Вход (Input) – объекты, используемые и преобразуемые работой для получения результата (выхода). Стрелка входа рисуется как входящая в левую грань работы.
Управление (Control) – информация, управляющая действиями работы, Обычно управляющие стрелки несут информацию, которая указывает, что должна выполнять работа. Каждая работа должна иметь хотя бы одну стрелку управления, которая изображается как входящая в верхнюю грань работы.
Выход (Output) – объекты, в которые преобразуются входы. Каждая работа должна иметь хотя бы одну стрелку выхода, которая рисуется как исходящая из правой грани работы.
Механизм (Mechanism) ресурсы, выполняющие работу. Стрелка механизма рисуется как входящая в нижнюю грань работы. По усмотрению аналитика стрелки механизма могут не изображаться на модели.
Вызов (Call) – специальная стрелка, указывающая на другую модель работы. Стрелка вызова рисуется как исходящая из нижней части работы и используется для указания того, что некоторая работа выполняется за пределами моделируемой системы.
Рис. 6. Стрелка вызова
Каждый тип стрелок подходит к определенной стороне блока, или выходит из нее. Стрелка входа рисуется как входящая в левую грань работы. Стрелка управления рисуется как входящая в верхнюю грань. Выход рисуется как исходящая стрелка из правой грани. Механизм – входит в нижнюю грань.
Граничные стрелки
Стрелки на контекстной диаграмме служат для описания взаимодействия системы с окружающим миром. Они могут начинаться у границы диаграммы и заканчиваться у работы, или наоборот. Такие стрелки называются граничными . Для внесения граничной стрелки необходимо:
Щелкнуть по кнопке с символом стрелки в палитре инструментов, затем перенести курсор к левой стороне экрана, пока не появится начальная штриховая полоска;
Щелкнуть один раз по полоске (откуда выходит стрелка) и еще раз в левой части работы со стороны входа (где заканчивается стрелка);
Вернуться в палитру инструментов и выбрать опцию редактирования стрелки ;
Щелкнуть правой кнопкой мыши на линии стрелки, во всплывающем меню выбрать пункт Name Editor и добавить имя стрелки в закладке Name диалога IDEF0 Arrow Properties.
Стрелки управления, входа, механизма и выхода изображаются аналогично.
Имена вновь внесенных стрелок автоматически заносятся в словарь (Arrow Dictionary).
Словарь стрелок (Arrow Dictionary) редактируется при помощи специального редактора Arrow Dictionary Editor (рис. 7), в котором определяется стрелка и вносится относящийся к ней комментарий.
Словарь стрелок решает очень важную задачу. Диаграммы создаются аналитиком для того, чтобы провести сеанс экспертизы, т.е. обсудить диаграмму со специалистом предметной области. В любой предметной области формируется профессиональный язык, причем очень часто такие выражения имеют нечеткий смысл и воспринимаются разными специалистами по-разному. В то же время аналитик – автор диаграмм должен употреблять те выражения, которые наиболее понятны экспертам.
Рис.7. Редактор словаря стрелок
Поскольку формальные определения часто сложны для восприятия, аналитик вынужден употреблять профессиональный язык, а чтобы не возникало неоднозначных трактовок, в словаре стрелок каждому понятию можно дать расширенное и, если это необходимо, формальное определение.
Внутренние стрелки
Для связи работ между собой используются внутренние стрелки, т.е. стрелки, которые не касаются границы диаграммы, начинаются у одной и кончаются у другой работы. Для рисования внутренней стрелки необходимо в режиме рисования стрелок щелкнуть по сегменту (например, выхода) одной работы и затем по сегменту (например, входа) другой.
В методологии IDEF0 различают только пять типов взаимодействий между блоками для описания их отношений: управление , вход , обратная связь по управлению , обратная связь по входу , выход-механизм . Связи по управлению и входу являются простейшими, поскольку они отражают прямые воздействия, которые интуитивно понятны и очень просты.
Рис. 8. Связь по выходу Рис. 9. Связь по управлению
Отношение управления возникает тогда, когда выход одного блока непосредственно влияет на блок с меньшим доминированием.
Обратная связь по управлению и обратная связь по входу являются более сложными, поскольку представляют собой итерацию или рекурсию. А именно выходы из одной работы влияют на будущее выполнение других работ, что впоследствии повлияет на исходную работу.
Обратная связь по управлению возникает тогда, когда выход некоторого блока влияет на блок с большим доминированием.
Рис. 10. Обратная связь по входу Рис. 11. Обратная связь по управлению
Связи выход-механизм встречаются нечасто. Они отражают ситуацию, при которой выход одной функции становится средством достижения цели для другой.
Связи «выход-механизм» характерны при распределении источников ресурсов (например, требуемые инструменты, обученный персонал, физическое пространство, оборудование, финансирование, материалы).
Рис. 12. Связь выход-механизм
Перед инсталляцией программы на компьютер необходимо убедится в том, что на вашем жёстком диске есть свободное место.
Для установки BPwin на Windows 7 нужно настроить режим совместимости с WinXP SP3 и запустить файл BPwin4.exe от имени администратора:
- Правой кнопкой мыши нажимаем на файл BPwin4.exe и выбираем пункт "Свойства".
- Далее переходим на вкладку "Совместимость"
- В диалоговом окне "Режим совместимости", устанавливаем галочку "Запустить программу в режиме совместимости с:"
- Выбираем пункт меню "Windows XP (пакет обновления 3)"
- Нажать "ОК"
Начнется процесс подготовки к инсталяции:
Рис 1.1. Окно BPwin 4.0 Setup
В появившемся окне BPwin 4 Setup нажимаем . Для дальнейшей установкинажимаем
Рис 1.2. Лицензионное соглашение
Указываем место установи программы. По умолчанию программа автоматически устанавливается в C:\Program Files\Computer Associates\BPwin 4.0.
Рис 1.3. Окно выбора типа установки
- Tipical отличается тем, что при таком типе установке программа устанавливает все свои компоненты (приложения).
- Compact режим необходим если на вашем жестком диске недостаточно места для всех компонентов BPwin. В таком случае будут установлены только основные компоненты необходимые для работы программы.
- Custom необходим для выбора определенных компонентов программы для установки
Для продолжения установки нажимаем .
Нажимаем кнопку . Если Вы хотите указать собственное имя папки программы в меню Пуск, то введите его и нажмите кнопку .
После того как как установится BPwin на вашем компьютере, появится окно, «Добро пожаловать в регистрацию», в котором нужно нажать кнопку .
Рис 1.4. Окно «Добро пожаловать в регистрацию»
Затем в окне RegisterIT, которое предлагает вам зарегистрировать Вашу версию BPwin 4.0, нужно выбрать позицию Register Later и нажать кнопку .
Рис 1.5. Окно Register Later
Затем в появившемся окне нажимаем . Из появляющихся окон выбираем кнопки и .
Процесс установки завершён.
Теперь необходимо зарегистрировать полную версию программы BPwin.
Для этого находим в архиве файл Keygen.exe и копируем его в каталог, куда была установлена программа BPwin (корневой каталог диска C:\СA_LIC )
Запускаем Keygen.exe расположенный в C:\СA_LIC .
В поле Product Name нужно выбрать BPwin 4.0 и нажать кнопку .
Это нужно для того, чтобы найти код программы BPwin 4.0 .
Рис 1.6. Окно Keygenerator by SlaSk/PFT
После того как ключ был сгенерирован и Вы увидели его в поле Registration ID, необходимо скопировать его.
Теперь BPwin Keygen генератор ключа можно закрыть.
Для дальнейшей работы следует запустить программу RegIT.exe из каталога CA_LIC. После запуска программы появляется окно приветствия RegIT.
Рис 1.7. Окно RegisterIT Welcome
В этом окне для продолжения работы необходимо нажать . После чего в окне RegisterIT вы выбираете пункт Register Later и нажимаете кнопку .
Рис 1.8. Окно ввода ключа
Далее появляется окно в котором в поле Product Name выбрать BPwin 4.0 , а в поле Registration ID вставляете ключ (набор цифр) ранее скопированный и нажимаете кнопку . Дальнейшего вашего участия не требуется (кроме нажатия кнопки ) программа всё сделает сама. На последнем шаге вы можете с облегчением нажать кнопку . Вот и всё программа BPwin 4.0 работоспособна.
BPwin - освоение CASE-средства BPwin в целях разработки функциональной модели информационной системы с использованием методологии IDEF0.
CASE-средство BPwin предназначено для построения функциональных моделей с использованием методологий:
- IDEF0 - функциональные модели любых систем;
- IDEF3 - функциональные модели технологических процессов;
- DFD - функциональные модели информационных систем.
Внешний вид главного окна BPwin представлен на рис.1.
Рис. 1. Интегрированная среда BPwin
Навигатор панели процессов предназначен для отображения и выбора диаграмм разрабатываемой функциональной модели.
Рабочая область предназначена для отображения и редактирования диаграммы модели, выбранной в панели процессов.
На рис.2 приведено назначение элементов управления стандартной панели инструментов (Standard Toolbar).
Рис. 2. Стандартная панель инструментов
Для создания новой модели необходимо выбрать пункт меню "File / New" или нажать на соответствующую кнопку стандартной панели инструментов (см.рис.2). На экране появится диалоговое окно (рис.3).
Рис. 3. Диалоговое окно создания или открытия модели
В диалоговом окне необходимо выбрать радиокнопку "Create model", ввести имя модели в поле "Name" и выбрать методологию, нотация которой будет использовать при построении модели (радиокнопки "Type").
Для указания общих параметры модели необходимо выбрать пункт меню "Мodel / Model Properties" и в появившемся диалоговом окне перейти на вкладку "General" (риc.4).
Рис. 4. Вкладка "General" диалогового окна "Model Properties"
На вкладке задаются следующие параметры модели:
- имя модели (Model name);
- имя проекта (Project). Имя проекта, как правило, совпадает с именем разрабатываемой информационной системы;
- фамилия автора или наименование компании (Author);
- инициалы автора (Author initials);
- тип модели - AS-IS (как есть) или TO-BE (как будет). Подробнее см. раздел "Основы функционального анализа и проектирования систем".
После нажатия на кнопку "Ok" диалогового окна создания модели автоматически создается контекстная диаграмма. Указание параметров диаграммы, выбранной в текущий момент в панели процессов, осуществляется через диалоговое окно "Diagram Property", вызываемого через пункт меню "Diagram / Diagram Property" (рис.5).
Рис. 5. Вкладка "Name" диалогового окна "Diagram Property"
На вкладке "Status" указываются статус, дата создания и дата последней редакции диаграммы (рис.6).
Рис. 6. Вкладка "Status" диалогового окна "Diagram Property"
Типы статуса диаграммы имеют следующий смысл:
- рабочая (WORKING) - диаграмма находится в стадии разработки;
- черновик (DRAFT) - диаграмма прошла некоторые стадии рассмотрения с заказчиками, но это не окончательный вариант;
- рекомендованная (RECOMMENDED) - диаграмма прошла все стадии рассмотрения с заказчиками и отвечает формальным требованиям, но это не окончательный вариант;
- готовая или публикуемая (PUBLICATION) - окончательный вариант диаграммы.
На вкладке "Page Setup" указываются единицы измерения (Units), формат листов (Sheet Size), поля, необходимость отображения заголовка (Header) и нижнего колонтитула (Footer) (рис.7).
Рис. 7. Вкладка "Page Setup" диалогового окна "Diagram Property"
На вкладке "Header/Footer" возможно задание пользовательского (custom) вида заголовка (Header) и нижнего колонтитула (Footer) диаграммы (рис.8).
Рис. 8. Вкладка "Header/Footer" диалогового окна "Diagram Property"
Для непосредственного создания элементов диаграммы и ускоренной навигации по модели используется панель инструментов "BPwin Toolbox" (отображение или скрытие панели выполняется через пункт меню "View").
На рис.9 приведено назначение элементов управления панель инструментов "BPwin Toolbox".
Рис. 9. Панель инструментов "BPwin Toolbox"
Для указания параметров функции необходимо щелкнуть по ней правой кнопкой мыши и в контекстном меню выбрать соответствующий пункт.
В результате на экране появится диалоговое окно "Activity Properties" (рис.10).
Рис. 10. Диалоговое окно "Activity Properties"
На вкладке диалогового окна можно задать:
- имя блока (вкладка "Name");
- комментарий к блоку (вкладка "Definition");
- параметры шрифта надписи блока (вкладка "Font");
- цвет блока (вкладка "Color");
- графический примитив, используемый для отображения блока (вкладка "Box style").
Для указания аналогичных параметров стрелки используется диалоговое окно "Arrow Properties" (рис.11). Вызов диалогового окна выполняется также, как и для блока.
Рис. 11. Диалоговое окно "Arrow Properties"
Если наименование стрелки расположено удаленно от самой стрелки или возникают трудности по сопоставлению наименования стрелки с самой стрелкой (в случае высокого насыщения диаграммы элементами) можно на диаграмме отобразить ассоциацию между ними. Для этого необходимо щелкнуть по стрелке правой кнопкой мыши и в контекстном меню выбрать пункт "Squiggle".
Для указания на диаграмме произвольного комментария непосредственно к элементу используются кнопки "Задание ассоциации" и "Добавление произвольного текста".
Для навигации по модели (переходу к диаграммам) используются последние четыре кнопки панели "BPwin Toolbox".
Если на диаграмме выбран блок, для которого не существует диаграммы декомпозиции, и нажата кнопка в панели инструментов ▼, то на экране появится диалоговое окно "Activity Box Count" (рис.12).
Рис. 12. Диалоговое окно "Activity Box Count"
В этом диалоговом окне требуется выбрать методологию, в соответствии с которой будет строится диаграмма декомпозиции, и предполагаемое количество блоков на диаграмме. BPwin создаст диаграмму с указанным количеством блоков и перенесет на нее все стрелки входящие и выходящие в родительский блок.
Ниже перечислены наиболее используемые приемы редактирования диаграмм и их элементов:
- создание новой стрелки - выбрать в панели инструментов "BPwin Toolbox" кнопку →, подвести указатель мыши на диаграмме к соответствующей границе диаграммы или блока, означающей начало стрелки, нажать левую кнопку мыши, подвести указатель мыши к соответствующей границе диаграммы или блока, означающей конец стрелки, и нажать левую кнопку мыши;
- соединение имеющейся стрелки с имеющимся блоком или границей диаграммы, ветвление стрелки - выбрать в панели инструментов "BPwin Toolbox" кнопку →, подвести указатель мыши на диаграмме к соответствующей стрелке (в случае ветвления - к месту ветвления стрелки), нажать левую кнопку мыши, подвести указатель мыши к соответствующей границе диаграммы или блока, означающей конец стрелки, и нажать левую кнопку мыши;
- удаление блока - выбрать блок на диаграмме или панели процессов и нажать клавишу "Delete". При этом, кроме удаления самого блока, будут удалены все входящие и выходящие из него стрелки, а также связанные с ним диаграммы декомпозиции и их элементы;
- удаление стрелки - выбрать стрелку на диаграмме и нажать клавишу "Delete". Если удаляемая стрелка была перенесена на диаграмму в результате декомпозиции родительского блока, то она будет удалена с текущей диаграммы (диаграммы декомпозиции), а на родительской диаграмме останется и примет статус затуннелированной со стороны вхождения в родительский блок (рис.13а). Если удаляемая стрелка присутствует на диаграмме декомпозиции для блока, в который она входит или выходит, то она будет удалена с текущей диаграммы (родительской диаграммы), а на диаграмме декомпозиции примет статус затуннелированной со стороны границы этой диаграммы (рис.13б). Квадратные скобки затуннелированной стрелки означают неутвержденное (предварительное) туннелирование, круглые - утвержденное (сознательное). Для изменения статуса туннелирования (с неутверденного на утвержденное) необходимо щелкнуть по ней правой кнопкой мыши, выбрать пункт "Arrow Tunell" контекстного меню и в соответствующем диалоговом окне выбрать статус;
Рис. 13. Затуннелированные стрелки
Перемещение блока или стрелки на диаграмме - выбрать в панели инструментов "BPwin Toolbox" кнопку , подвести указатель мыши на диаграмме к соответствующему элементу диаграммы, нажать левую кнопку мыши и, не отпуская ее, задать новое положение элемента.
- создание диаграммы дерева узлов - выбрать в панели процессов или на диаграмме блок (корень дерева), начиная с которого будет строится диаграмма дерева узлов, выбрать пункт меню "Diagram / Add Node Tree" и в появившемся диалоговом окне задать имя диаграммы дерева узлов и количество уровней дерева.
Рис. 14. Мастер создания диаграммы дерева узлов
Скачать книги по бизнес моделированию:
1. Марка, Д.А. Методология структурного анализа и проектирования SADT / Д.А. Марка, К. МакГоуэн. - М. : МетаТехнология, 1993. - 243 с.
2. Калянов, Г.Н. CASE. Структурный системный анализ (автоматизация и применение) / Г.Н. Калянов. - М. : Лори, 1996. - с.
3. Маклаков, С.В. BPwin и ERwin. CASE-средства разработки информационных систем / С.В. Маклаков. - М. : ДИАЛОГ-МИФИ, 2001. - 304 с.
4. Маклаков, С.В. Создание информационных систем с AllFusion Modeling Suite / С.В. Маклаков. - М. : ДИАЛОГ-МИФИ, 2005. - 432 с.
5. Дубейковский, В. И. Практика функционального моделирования с AllFusion Process Modeler 4.1. (BPwin) Где? Зачем? Как? / В.И. Дубейков-ский. - М. : ДИАЛОГ-МИФИ, 2004. - 464 с.
6. Анисимов, В.В. Проектирование информационных систем: курс лекций. В 2 ч. Ч. 1. Структурный подход / В.В. Анисимов. - Хабаровск: Изд-во ДВГУПС, 2006. - 112 с.
BPwin поддерживает три методологии моделирования: функциональное моделирование ( IDEF0 ); описание бизнес-процессов (IDEF3); диаграммы потоков данных ( DFD ).
Инструментальная среда BPwin
BPwin имеет достаточно простой и интуитивно понятный интерфейс пользователя. При запуске BPwin по умолчанию появляется основная панель инструментов , палитра инструментов (вид которой зависит от выбранной нотации) и, в левой части, навигатор модели - Model Explorer (рис. 7.1).
При создании новой модели возникает диалог, в котором следует указать, будет ли создана модель заново или она будет открыта из файла либо из репозитория ModelMart, затем внести имя модели и выбрать методологию, в которой будет построена модель (рис. 7.2).
Как было указано выше, BPwin поддерживает три методологии - IDEF0 , IDEF3 и DFD , каждая из которых решает свои специфические задачи. В BPwin возможно построение смешанных моделей, т. е. модель может содержать одновременно диаграммы как IDEF0 , так и IDEF3 и DFD . Состав палитры инструментов изменяется автоматически, когда происходит переключение с одной нотации на другую.
Рис.
7.1.
Рис. 7.2.
Модель в BPwin рассматривается как совокупность работ , каждая из которых оперирует с некоторым набором данных. Работа изображается в виде прямоугольников, данные - в виде стрелок. Если щелкнуть по любому объекту модели левой кнопкой мыши, появляется контекстное меню , каждый пункт которого соответствует редактору какого-либо свойства объекта.
Построение модели IDEF0
На начальных этапах создания ИС необходимо понять, как работает организация, которую собираются автоматизировать. Руководитель хорошо знает работу в целом, но не в состоянии вникнуть в детали работы каждого рядового сотрудника. Рядовой сотрудник хорошо знает, что творится на его рабочем месте, но может не знать, как работают коллеги. Поэтому для описания работы предприятия необходимо построить модель, которая будет адекватна предметной области и содержать в себе знания всех участников бизнес-процессов организации.
Наиболее удобным языком моделирования бизнес-процессов является IDEF0 , где система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной - функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации.
Процесс моделирования системы в IDEF0 начинается с создания контекстной диаграммы - диаграммы наиболее абстрактного уровня описания системы в целом, содержащей определение субъекта моделирования, цели и точки зрения на модель.
Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами, другими словами, определить, что будет в дальнейшем рассматриваться как компоненты системы, а что как внешнее воздействие. На определение субъекта системы будут существенно влиять позиция, с которой рассматривается система, и цель моделирования - вопросы, на которые построенная модель должна дать ответ. Другими словами, в начале необходимо определить область моделирования. Описание области как системы в целом, так и ее компонентов является основой построения модели. Хотя предполагается, что в ходе моделирования область может корректироваться, она должна быть в основном сформулирована изначально, поскольку именно область определяет направление моделирования. При формулировании области необходимо учитывать два компонента - широту и глубину. Широта подразумевает определение границ модели - что будет рассматриваться внутри системы, а что снаружи. Глубина определяет, на каком уровне детализации модель является завершенной. При определении глубины системы необходимо помнить об ограничениях времени - трудоемкость построения модели растет в геометрической прогрессии с увеличением глубины декомпозиции. После определения границ модели предполагается, что новые объекты не должны вноситься в моделируемую систему.
Цель моделирования
Цель моделирования определяется из ответов на следующие вопросы:
- Почему этот процесс должен быть смоделирован?
- Что должна показывать модель?
- Что может получить клиент?
Точка зрения (Viewpoint).
Под точкой зрения понимается перспектива, с которой наблюдалась система при построении модели. Хотя при построении модели учитываются мнения различных людей, все они должны придерживаться единой точки зрения на модель. Точка зрения должна соответствовать цели и границам моделирования. Как правило, выбирается точка зрения человека, ответственного за моделируемую работу в целом.
IDEF0 -модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения. Для внесения области, цели и точки зрения в модели IDEF0 в BPwin следует выбрать пункт меню Model/Model Properties, вызывающий диалог Model Properties (рис. 7.3). В закладке Purpose следует внести цель и точку зрения, а в закладку Definition - определение модели и описание области.
Рис. 7.3.
В закладке Status того же диалога можно описать статус модели (черновой вариант, рабочий, окончательный и т. д.), время создания и последнего редактирования (отслеживается в дальнейшем автоматически по системной дате). В закладке Source описываются источники информации для построения модели (например, "Опрос экспертов предметной области и анализ документации"). Закладка General служит для внесения имени проекта и модели, имени и инициалов автора и временных рамок модели - AS-IS и ТО-ВЕ.