CC BY
179
№ 5 (35) 2011
Н. Н. Прокимнов, канд. техн. наук, доцент МФПУ «Синергия»
Структурно-функциональное моделирование деловых процессов
Информационные системы превратились из просто важной в фактически неотъемлемую часть деятельности любой структуры. Правильно понять и сформулировать требования к создаваемой системе помогает моделирование процессов, образующих эту деятельность.
Введение
Сделаем вначале одно замечание относительно термина, обозначающего предмет рассмотрения данной статьи и вынесенного в ее заголовок. В отечественной литературе английское название business process часто дается в транслитерированном виде — «бизнес-процесс». Слово business в английском языке означает экономическую деятельность коммерческого характера, целью которой является извлечение прибыли или иных экономических выгод, измеряемых в денежном исчислении. Вместе с тем под термином business process часто подразумеваются процессы, протекающие не обязательно в коммерческих организациях, а, например, в органах государственного управления, благотворительных организациях и в технологических цепочках на реальном производстве. На этот расширительный смысл термина авторы книг на английском языке часто обращают внимание читателя1.
В настоящей статье речь идет именно о процессах в широком смысле, об анализе и моделировании их функциональных структур [1], поэтому словосочетание «деловой процесс» более точно передает их сущность.
1 В русском языке слово «деловой» в отличие от английского business (см. словарь Merriam-Webster, http://www.merriam-webster.com) не несет коммерческого оттенка, поэтому в дополнительных разъяснениях
не нуждается.
Внедрение информационных технологий и систем относится к одному из основных направлений повышения эффективности работы предприятия. Информационную систему в настоящее время следует рассматривать не как самостоятельную сущность, а в ее тесной взаимосвязи с основной деятельностью предприятия или структуры, в которую она включается как органическая составная часть, поэтому требования к системе формулируются на основе детального рассмотрения всех протекающих в реальной системе (организации, структуре) деловых процессов, к которым будем относить любой вид регулярно выполняющихся действий или операций, направленных на достижение одной или нескольких определенных целей и имеющих (или использующих) необходимый для этого набор ресурсов.
Основные определения
Все деловые процессы направлены на достижение определенной цели. Понятие «цель» выражает желаемое состояние ресурсов, которое достигается в результате протекания процессов. Цели формулируются в виде одного или нескольких правил.
Под термином «ресурс» понимается набор объектов, которые использует или потребляет процесс. В качестве таких объектов могут выступать люди, сырье, информация или произведенный продукт. Ресурсы образуют связанные между собой структуры и могут представлять собой объекты, которые потребляются или подвергаются пре-
-ч ПРИКЛАДНАЯ ИНФОРМАТИКА
№ 5 (35) 2011 ' -
образованию, например сырье в материальном производстве. Этот вид ресурсов относится к входным ресурсам. Выходными ресурсами являются конечные результаты, имеющие ценность для их получателя и могут представлять собой совершенно новый объект или объект, получившийся как преобразование входных ресурсов2.
Правило (или деловое правило) представляет собой утверждение относительно каких-либо характеристик деловых процессов или наложенных на них ограничений. Правила могут отражать особенности внешней среды и иметь вид законов, постановлений, государственных или местных стандартов либо диктоваться внутренними условиями в виде установленных корпоративных стандартов и нормативов, распорядка или регламента. Они могут указывать способ, которым должны выполняться операции, требования к составу и параметрам промежуточных и итоговых результатов, вводить ограничения на использование ресурсов, задавать последовательность выполнения отдельных операций. Правила можно классифицировать на функциональные, поведенческие и структурные.
Формулировку целей и распределение « ресурсов осуществляет владелец деловых у процессов.
Проектирование среды протекания де-^ ловых процессов, их логической структуры § и параметров, определение потребностей § характера необходимых ресурсов, их объе-щ ма и распределения входят в задачу анали-;§ тика, которую он решает в типичном случае ^ на основе разработанной им модели. Моде-| лирование деловых процессов преследует § цель получения абстракции реально проте-§ кающих процессов, предоставив тем самым | возможность всем лицам, имеющим отноше-| ние к работе предприятия, во-первых, понять Ц текущее состояние и, во-вторых, определить пути для его улучшения и инноваций. Последние термины нуждаются в уточнении.
2 Ресурсы в задачах анализа бывает полезно клас-со сифицировать [2].
Под улучшением деловых процессов понимаются их небольшие поэтапные изменения, носящие непрерывный эволюционный характер. Инновации означают существенные изменения, носящие дискретный характер3. Инновации, дающие потенциальную возможность значительно повысить эффективность деловых процессов, вместе с тем характеризуются высоким уровнем риска неудачи. Наиболее радикальным видом инноваций является реинжиниринг деловых процессов, применение которого может, с одной стороны, повысить эффективность в несколько раз, с другой стороны, увеличивает риск.
Внедрение информационной системы — один из основных примеров инновации. Для ее реализации на начальных этапах жизненного цикла системы необходимо предварительно определить архитектуру (совокупность элементов и отношений между ними, которые формируют систему с ее основными функциями) и требования к ее параметрам. Необходимым инструментом решения этой задачи является деловая модель (рис. 1).
Построение деловой модели (более точно — модели деловой среды, предприятия, объекта) позволяет не только значительно снизить уровень риска за счет выявления предполагаемых узких мест и упущений. Применение современных методов разработки моделей дает возможность использовать одну и ту же модель для анализа и проектирования на ее основе различных реализаций информационной системы, снижая тем самым затраты на внедрение.
3 Приведенная «модельная» трактовка не противоречит экономической. Инновация (от англ. innovation) — внедренное новшество, обеспечивающее качественный рост эффективности процессов или продукции, востребованное рынком, являющееся конечным результатом интеллектуальной деятельности человека, его фантазии, творческого процесса, открытий, изобретений и рационализации (см., например, http://dic. academic.ru). Примером инновации является выведение на рынок продукции (товаров или услуг) с новыми потребительскими свойствами или качественным повышением эффективности производственных систем.
№ 5 (35) 2011
ДЕЛОВАЯ СРЕДА
/ <1
' У
Деловая модель
оо
0
1
о §
эё эй
Рис. 1. Взаимосвязи моделей и систем
Другими важными задачами, решение которых обеспечивает деловая модель, являются задачи обучения персонала предприятия и выявление вероятных вариантов для аутсорсинга — передачи каких-либо из выполняемых функций (действий процесса) сторонним исполнителям.
Задача разработчика — создание и внедрение поддерживающей деловые процессы информационной системы путем разработки новой или адаптации какой-либо существующей ее реализации.
Правильно составленная деловая модель позволяет, как отмечено выше, применять ее для определения архитектуры информационной системы. В частности, с помощью деловой модели можно достаточно точно определить следующие требования к программному обеспечению информационной системы:
• наиболее подходящий для данной деловой модели тип информационной системы (новая, типовая, наследованная);
• функции, которые должна выполнять система;
• тактико-технические характеристики системы.
Однако перенос компонентов деловой модели в модель программной архитектуры не может осуществляться чисто формально и требует приложения определенных усилий.
С другой стороны, обратившись к истории, констатируем, что задача разработки программной архитектуры возникла значительно раньше, чем задача моделирования деловых процессов, и в течение этого периода для моделирования архитектуры программного обеспечения появилось довольно много методов и инструментальных средств. Несмотря на то что прямое применение этих методов и инструментальных средств к моделированию деловых процессов невозможно, ряд подходов, предложенных для моделирования деловых процессов, основан на адаптации методологий моделирования программного обеспечения, в типичном случае — путем включения в языки моделирования специальных дополнений.
В число наиболее широко применяемых методологий моделирования деловых процессов входят методология IDEF и язык моделирования UML.
№ 5 (35) 2011
о
t
0 &
а
■а со
1
4
I
5
СО О
! §
§
<и §
t §
0
1
0
1 s
Применение методологии моделированияIDEF
Методология IDEF (Integrated DEFinition) была разработана в 1970-х гг. в рамках программы ВВС США под названием ICAM (Integrated Computer Aided Manufacturing). Первоначально она предназначалась для моделирования систем производственного назначения и включала метод функционального моделирования IDEF0, метод концептуального моделирования IDEF1 и метод спецификаций моделей динамических систем IDEF2. В дальнейшем она была дополнена другими методами и стала широко применяться для моделирования деловых процессов. В настоящее время в нее входят методы от IDEF0 до IDEF14 (IDEF7 к настоящему времени не реализован). Наиболее часто используемыми методами являются IDEF0, IDEF^, IDEF3 и IDEF4. В силу своих интуитивно понятных неподготовленному читателю изобразительных средств, упрощающих и повышающих надежность взаимодействия аналитиков и конечных пользователей, методы моделирования IDEF получили довольно широкое распространение и продолжают совершенствоваться.
Для целей моделирования деловых процессов применяются в основном методы IDEF0 и IDEF3 [4], в основу которых положены графические языки описания моделируемых объектов и процессов.
Начальный этап построения модели требует принятия решения по нескольким ключевым вопросам. В частности, разработчиками должны быть определены следующие параметры:
Назначение модели. В первую очередь, определяется тип создаваемой модели выбором из двух возможностей:
• как есть (AS IS) — описание существующей деловой среды;
• как должно быть (TO BE) — описание желаемой деловой среды;
• построенной с применением средств автоматизации деловых процессов.
Границы моделирования. Специфицируются широта охвата в смысле включаемых в рассмотрение компонентов деловой среды, деловых процессов и глубина детализации их описаний. Решения во многом предопределяются решением по назначению модели.
Целевая аудитория. Определяется круг заинтересованных лиц, для которых создается модель.
Точка зрения. Выбирается перспектива, под которой наблюдается деловая среда в процессе создания модели. При необходимости могут создаваться несколько моделей, отображающих различные точки зрения (например, пользователь услуг предприятия, системный администратор, финансовый директор).
Метод IDEF0 предназначен для разработки функциональных моделей, т. е. спецификаций того, что должна делать система. В основу метода положена методика SADT (Structured Analysis and Design Technique), разработанная в 1970-х гг. [3].
С помощью IDEF0 аналитик может описать деловые процессы, отображая также существенные для понимания объекты типа вход, выход, управление и механизм (исполнительный механизм). Эти объекты, которые, кроме того, часто именуются ICOM (Input-Control-Output-Mechanism), определяются следующим образом (рис. 2):
• входы представляют собой ресурсы, потребляемые или подвергаемые преобразованию описываемым процессом;
• выходы представляют собой некоторые объекты, появляющиеся как результат потребления или преобразования входов;
Механизмы Рис. 2. Общий вид IDEFO-диаграммы
28
• управления представляют собой некоторые объекты, организующие и контролирующие протекание процесса — стратегии, законы, правила,стандарты;
• механизмы представляют собой объекты и субъекты, участвующие в выполнении отдельных операций процесса, таких как люди или устройства и оборудование.
Название функции записывается в функциональном (процессном) блоке в виде глагола в повелительном наклонении или отглагольного существительного.
На рисунке 3 показан пример IDEF0-диа-граммы.
Правила бухучета
№ 5 (35) 2011
А.
А0
Т
со
0
1
о §
Эё
эё
А1
А2
А3
А4
А41
^ А42
>
А43
Бухгалтер КИС Рис. 3. Пример IDEF0-диаграммы
Основным методологическим приемом IDEF0 является декомпозиция — каждый функциональный блок может быть представлен своим более подробным описанием в виде отдельной (дочерней) диаграммы, на которой могут присутствовать несколько соединенных между собой функциональных блоков (рис. 4).
Иерархия связей между родительской и дочерними диаграммами отображается системой обозначений блоков диаграмм. Так, на рис. 4 блок диаграммы высшего уровня (контекстной диаграммы) обозначается А0, блоки дочерней диаграммы — А1, А2, А3, А4. Следующая диаграмма, показанная на рисунке, является декомпозицией блока А4, три блока которой обозначаются А41, А42, А43. Наконец, последняя диаграмма рисунка, дочерняя для блока А42, содержит блоки с обозначениями А421, А422, А423.
Рис. 4. Декомпозиция блоков IDEF0-диаграмм
Стрелки IDEF0-модели могут как разветвляться, так и сливаться, причем слияние сохраняет за каждой стрелкой ее содержательную идентичность.
Часть стрелок может туннелироваться, т. е. стрелки впервые появляются только на дочерней диаграмме некоторого уровня, оставаясь на всех родительских диаграммах скрытыми. Допускается также и обратное — можно отменить присутствие ненужных стрелок на всех дочерних диаграммах. Это позволяет избежать загромождения диаграмм верхних уровней излишними деталями (в первом случае) или, наоборот, сведениями слишком неконкретного харак-
№ 5 (35) 2011
Техпроцесс
Заготовка на складе
Упаковочный материал
Машиностроительные стандарты
Деталь для сборки
Брак
на переплавку
Главный Мастер Обрабатывающие Крепежное Оборудование Упаковочное
инженер участка станки оборудование контроля оборудование
Рис. 5. Контекстная диаграмма
Техпроцесс Машиностроительные стандарты С1 С2
со
0
1
0 &
а
■а со
1 Ч
I
со
0
1
¡5 €
<и §
I §
0
1
0
1
М3 М4
Обрабаты- Крепёжное
вающие обору-
станки дование
Р. 5
М2 М5 М6
Обору- Упаковочное Мастер дование обору-участка контроля дование
Рис. 6. Диаграмма декомпозиции блока А0
тера (во втором). На IDEF0-диаграммах туннели обозначаются парой круглых скобок, стоящих в начале стрелки (скрытой на родительских диаграммах) или в конце стрелки (скрытой на дочерних диаграммах).
На рисунках 5 - 9 показан пример, иллюстрирующий эти механизмы4.
4 Использована модель, разработанная на занятиях по курсу «Теория информационных процессов и систем» в Московском финансово-промышленном университете «Синергия».
Помимо примеров использования сливающихся и ветвящихся стрелок на рис. 9. Диаграмма декомпозиции блока А4 (рис. 9) присутствует пример туннеля в виде стрелки «База данных».
Однако метод IDEF0 не позволяет дать представление о хронологии протекания процессов, иначе говоря, диаграмма отражает только состав функций, но не логическую последовательность их выполнения. Элементы диаграммы могут содержать сведения относительно условий выполне-
30
№ 5 (35) 2011
Техпроцесс С1
Машиностроительные стандарты
оо
0
1
о £ 3=
э=
Vo1
М1
Обрабатывающие станки
М3 Мастер участка
М2 Крепёжное оборудование
Рис. 7. Диаграмма декомпозиции блока А2
Машино- Техпроцесс строительные стандарты С1 С2
Изготовленная
II->
Бракованная
>01
Кондиционная
> 02
М2 М1 Оборудование Мастер контроля участка
Рис. 8. Диаграмма декомпозиции блока А3
31
С2
1
№ 5 (35) 2011
Техпроцесс С1
( ) База данных
М1
Упаковочное оборудование
Рис. 9. Диаграмма декомпозиции блока А4
I1
I2
ния функций, но не сведения о том, каковы должны быть условия для того, чтобы процесс мог начаться, или в какой момент процесс будет завершен. Описание этих характеристик может быть получено с помощью средств моделирования IDEF3.
Метод IDEF3. Аналогично методу IDEF0 объектом рассмотрения метода IDEF3 являются деловые процессы предприятия. Модель IDEF3 дополняет описание систе-« мы IDEFO-модели информацией о динами-у ческих (поведенческих) аспектах протекающих в системе процессов. При этом в отли-^ чие от IDEFO-модели IDEF3-модель может со-i четать несколько описаний (представлений) g о временных предшествованиях процессов. щ По этой причине результат применения ме-;§ тода правильнее, строго говоря, характери-^ зовать как частично формализованное опи-| сание системы, но не как модель. § Изобразительные средства включают § два подхода.
| При использовании первого подхода све-| дения о процессах представляются в диа-Ц граммах протекания процесса в виде сценария, отдельными единицами описания "i которого являются действия, или работы Ц (activity), называемые UOB (Unit Of Behav-^ ior — единица поведения), или UOW (Unit Of ¿3 Work — единица работы). Применительно
к конкретной задаче UOB может представлять отдельную функцию, действие, операцию или процесс. Связи с блоками IDEF0 устанавливаются посредством механизма ссылок.
Связи между действиями (arrow, link) могут быть трех типов:
-> временное предшествование —
предыдущее действие завершается до начала действия, следующего за ним;
—» объектный поток — выход предыдущего действия передается на вход действия, следующего за ним; ........> отношение — предполагает специальное уточнение временной зависимости для каждого конкретного случая.
Аналогично имеющейся в методе IDEF0 возможности декомпозиции функциональных блоков действия (UOB) в модели IDEF3 также могут декомпозироваться, поэтому для номера действия обычно используется десятичная нотация (рис. 10).
На рисунке 11 показан пример IDEF3-диа-граммы процессов.
Действие J1 на рис. 11 означает, что в данной точке осуществляется обязатель-
№ 5 (35) 2011
Оформить счёт за выполненные работы
Название действия
Номер / родительского действия
Номер действия
Рис. 10. Нумерация действий в модели IDEF3
ный выбор ровно одного из двух возможных направлений дальнейшего протекания процесса: будет выполняться либо действие 4, либо действие 5.
Действие J1 представляет собой один из трех определяемых в методе IDEF3 видов соединений, или перекрестков (junction). Помимо показанного на рис. 11 разворачиваю-
щего соединения Исключающее (Эксклюзивное) ИЛИ в IDEF3 определены и другие типы, перечень которых приведен в табл. 1.
Буква Р в табл. 1 означает разворачивающее соединение (Fan-out Junction), буква С — сворачивающее соединение (Fanin Junction).
На рисунках 12 и 13 показаны примеры использования разворачивающих и сворачивающих соединений ИЛИ и И.
В модели IDEF3 может также отражаться зависимость между моментами начала действий, выходящих из соединения, или окончания действий, входящих в соединения. В отличие от рассмотренных в примерах асинхронных соединений, где моменты начала или окончания могут отличаться друг от друга, в синхронных соединениях, обозначаемых на диаграммах прямоугольника-
1
о £ а-а;
Рис. 11. Диаграмма протекания процесса в модели IDEF3
Таблица 1
Соединения в IDEF3
Символ Название Вид Смысл
& И Р Запуск всех последующих действий
С Завершение всех предшествующих действий
X Исключающее ИЛИ Р Запуск ровно одного последующего действия
С Завершение ровно одного предшествующего действия
О ИЛИ Р Запуск не менее одного последующего действия
С Завершение не менее одного предшествующего действия
№ 5 (35) 2011
о
t
0 &
а
■а со
1
4
I
5
СО О
! §
§
<и §
t §
0
1
0
1
S
Рис. 12. Пример использования соединений типа ИЛИ
ми с двумя вертикальными линиями вместо одной, эти моменты должны совпадать.
Второй подход основан на использовании диаграмм переходов состояний объектов, которые отражают видение происходящего в изучаемой системе с точки зрения возможных изменений состояний объекта, подвергающегося трансформации или обработке в результате процесса. Эти диаграммы состоят из символов, означающих состояние объекта (окружности), символов перехода из одного состояния в другое (стрелки) и объектов ссылок (прямоугольники). Состояния определяются как значения существенного свойства (признака) объекта и условий. Переходы осуществляются в зависимости от выполнения предусловий или постусловий.
На рисунке 14 показан пример диаграммы переходов (диаграмма процесса этого же примера показана на рис. 11).
Описание исследуемой системы, представленное средствами методики IDEF3, является достаточно подробным для построения на его основе моделей для количественного оценивания показателей системы, в частности, аналитических и имитационных моделей [2].
Применение языка моделирования UML
Язык UML (Unified Modelling Language — Единый язык моделирования) появился как результат развития методов объектно-ориентированного анализа и проектирования конца 1980-х — начала 1990-х гг. На этом языке основана, в частности, известная методология проектирования и разработки программного обеспечения фирмы IBM, называемая RUP (Rational Unified Process).
Язык UML [5] образует множество символов и правил. В нем определены девять типов диаграмм, из которых для моделирования деловых процессов применяются семь.
Диаграммы классов (class diagram) служат для описания структуры моделируемой системы и содержат спецификации классов и отношений между ними. Классами могут быть информация, продукция, документы или организации. Пример диаграммы классов показан на рис. 15 (на концах связей поставлены обозначения кратности и указаны роли, которые каждый класс играет в данном отношении).
Рис. 13. Пример использования соединений типа И
34
№ 5 (35) 2011
Рис. 14. Диаграмма состояний в модели IDEF3
Рис. 15. Пример диаграммы классов
Классы связываются друг с другом с помощью ассоциаций (связей, отношений — association), которые могут представлять собой агрегат (aggregation — целое, составленное из частей), композицию (composition — специальный тип агрегата, в котором действуют ограничения на владение и время жизни), обобщение (generalization) и зависимость (dependency). На диаграммах виды ассоциаций отображаются в виде различных окончаний у стрелок, связывающих классы. Например, на рис. 15 ассоциация обозначена треугольным маркером и дополнена именем, показывающим природу отношений между объектами.
Диаграммы объектов (object diagram) представляют множество объектов — экземпляров классов, присутствующих на диаграмме классов для специфических ситуаций (в некоторый момент времени).
Диаграммы состояний (statechart diagram) служат для описания основных этапов жизненного цикла объектов или систем путем отображения их возможных состояний и событий, которые могут перевести объекты в другое состояние (рис. 16. Здесь и на следующих рисунках крайние левй и правый символы означают начало и конец процесса).
Диаграммы деятельности, или активности (activity diagram) описывают дейст-
Рис. 16. Пример диаграммы состояний
№ 5 (35) 2011
Рис. 17. Пример диаграммы деятельности
вия и мероприятия, происходящие в системе. Их можно использовать для отображения последовательности выполнения отдельных этапов деловых процессов (рис. 17).
Диаграммы последовательностей действий (sequence diagram) описывают передачу сообщений между множеством объектов. На ней точно воспроизводятся логическая последовательность и хронология действий, сообщения могут быть как синхронными (выполняться полностью до начала каких-либо действий), так и асинхронными (отправитель не ждет ответа перед продолжением своих действий), снабжаться параметрами и указателями.
Диаграммы кооперации (collaboration « diagram) схожи с диаграммами последова-<á тельности действий, но могут отображать i? более сложные правила взаимодействия ме-^ жду объектами. Информативность достига-§ ется за счет усложнения восприятия этих g диаграмм.
Диаграммы вариантов использования, ;§ или прецедентов (use case diagram) при-^ меняются для описания функций системы. | Прецедент характеризует конкретное ис-§ пользование возможностей системы акто-§ ром, или актантом (actor), обозначающим | пользователя каких-либо возможностей сис-I темы. Диаграмма отражает взаимосвязи ме-Ц жду прецедентами, каждый из которых может включать какой-либо прецедент, расши-¿ рять какой-либо прецедент или быть обоб-Ü щением других прецедентов. ^ Диаграммы компонентов используются ¿3 для описания компонентной структуры про-
граммных систем и для моделирования деловых процессов не применяются.
Диаграммы развертывания (deployment diagram) представляют собой диаграммы классов, описывающих отображение оборудования — программное обеспечение, и для моделирования деловых процессов не используются.
Для того чтобы предоставить пользователям возможность адаптировать язык к их специфическим потребностям, в языке предусмотрены средства его расширения, в состав которых входят следующие компоненты:
Стереотипы (stereotypes), позволяющие разработчику добавлять новые конструктивные блоки на основе существующего набора.
Именованные значения (tagged values) содержат дополнительные сведения в виде пары тег-значение (tag-value), которыми можно снабжать любой элемент UML-модели.
Ограничения (constraints) отображают правила, применяемые в UML-модели, которые можно записать на языке описания ограничений OCL (Object Constraint Language), являющемся составной частью языка UML. При моделировании деловых процессов OCL применяется для описания деловых правил.
Спецификации языка содержат также «Расширения UML для моделирования деловых процессов», описывающие вероятные расширения и правила их применения для моделирования деловых процессов.
Однако в силу того, что возможностей языка для моделирования деловых процессов недостаточно, некоторыми авторами предложены расширения UML. В качестве примера
№ 5 (35) 2011
Рис. 18. Обобщенный вид диаграммы процесса
таких расширений укажем метод Эриксона-Пенкера (Eriksson-Penker) [6]. Язык OCL используется в этом методе для описания деловых правил. Деловой процесс представляется образцом на диаграмме деятельности (как деятельность со стереотипом <<process>>), процесс использует входные ресурсы (левая часть диаграммы) и формирует выходные ресурсы (правая часть диаграммы). Основными объектами в процессной модели являются объекты цели (goal), входа (input), выхода (output), поставки (supplying), управления (control). Обобщенная диаграмма процесса показана на рис. 185.
Нетрудно увидеть, что диаграмма имеет много общего с IDEFO-диаграммой, из чего можно заключить, что, несмотря на различие изобразительных средств, обе методологии строятся на одинаковых концепциях.
Диаграмма деятельности используется в модифицированном виде под названием диаграммы сборочной линии (assembly line). Обычно эти диаграммы служат для представления информационных объектов информационной системы и показывают, как осуществляется доступ к информации и как она используется в процессах, которые показываются в верхней части диаграммы. Обобщенный вид диаграммы показан на рис. 19 (R — read (чтение), W — write (запись)).
Диаграммы сборочной линии связаны с диаграммами вариантов использования, так
5 Во избежание неоднозначности на этом и следующем рисунках сохранены английские написания [6].
как отображают интерфейс между деловыми процессами и информационной системой.
С целью повторного использования разработанной модели для описания схожих процессов можно применять механизм шаблонов, или паттернов (pattern), которые классифицируются по их применению. Для целей моделирования деловых процессов также предложен ряд шаблонов.
Автоматизация моделирования деловых процессов
К настоящему времени разработано довольно много программных продуктов, поддерживающих процессы разработки моделей по различным методикам, в частности, IDEF и UML. Степень автоматизации варьируется в широком диапазоне.
Средства нижнего уровня, например MS Office Visio, предоставляют аналитику средства графического интерфейса.
Программы промежуточного уровня, например CA AllFusion Business Process Modeler — Bpwin, помимо изобразительных средств позволяют проводить проверку корректности построенных моделей.
Средства верхнего уровня (CASE-системы) автоматизируют основные этапы системного анализа с возможностью генерации схем баз данных, программного кода на различных языках и подготовки проектной документации. В качестве примера назовем системы ARIS и IBM Rational Rose.
Выбор конкретного средства зависит, в первую очередь, от масштаба проектируе-
37
«
0
1
о &
а; а;
№ 5 (35) 2011
^ <<process>> ^ <<process>> ^_
• Process X Process Y
<<assembly line> A А ! : R :W / W ч R -7 W R
>• ■о Í С
<<assembly line> B
i í ó
Рис. 19. Обобщенный вид диаграммы сборочной линии
мой системы (предприятия), а также от состава группы аналитиков (консультантов) — увеличение численных характеристик будет смещать предпочтения при выборе от наиболее простых систем автоматизации в сторону более крупных.
Пакеты распространяются как на коммерческой основе (в частности, указанные выше), так и свободно в виде дистрибутивных файлов (Design/IDEF). Некоторые продукты (например, EAM IDEF0\Doctor, http://e-a-m.ru/Docs/Help.htm) снабжаются их исходными текстами, что позволяет настраивать интерфейс и проводить функциональную адаптацию к потребностям конкретных пользователей.
Заключение
о
у Эффект внедрения информационной системы определяется в первую очередь ^ степенью ее интеграции с деловой средой. § Средством повысить вероятность успеха § внедрения, выявить архитектуру будущей щ системы и сформулировать перечень требо-;§ ваний к ней является модель деловых про-^ цессов, содержащая их максимально точ-| ное описание.
§ Создание и применение деловых моде-§ лей может вестись с использованием раз-| личных методологий и стандартов. Один | из наиболее широко распространенных Ц подходов к моделированию — методики семейства IDEF и язык UML. Преимущество первой методологии — простота примене-
Ц ния и понимания конечными пользователя-р
ми, вторая методология, базируясь на объ-¿3 ектно-ориентированном подходе, позволяет
автоматизировать преобразование созданной деловой модели в программный код.
Большинство известных подходов к моделированию деловых процессов строится на базовых принципах и методиках общей теории систем и системного анализа, в частности, таких как иерархичность и декомпозиция. Несмотря на различия в средствах описания, методологии, в частности, IDEF и UML не имеют принципиальных отличий и позволяют представить в достаточном объеме существенные сведения о моделируемых процессах.
Список литературы
1. Анфилатов В. С., Емельянов А. А., Кукушкин А. А. Системный анализ в управлении: учеб. пособие. М.: Финансы и статистика, 2005. — 368 с.
2. Емельянов А. А., Власова Е. А., Дума Р. В., Емельянова Н. З. Компьютерная имитация экономических процессов / под ред. А. А. Емельянова. М.: Маркет ДС, 2010. — 464 с.
3. Марка Д., Макгоуэн К. SADT™. Методология структурного анализа и проектирования. М.: Ме-таТехнология, 1993. — 240 с.
4. Черемных С. В., Семенов И. О., Ручкин В. С. Моделирование и анализ систем. IDEF-технологии: практикум. М.: Финансы и статистика, 2005. — 192 с.
5. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя. М.: ДМК Пресс, 2003. — 432 с.
6. Eriksson H.-E. Business Modeling with UML: Business Patterns at Work / Hans-Erik Eriksson, Magnus Penker. N. J.: John Wiley & Sons, 2000. — 459 p.
7. Noran O. Business modeling: UML vs. IDEF. Brisbane: Griffith University, 2002. — 50 p.
