Для моделирования процесса диалоговые языки типа английского языка слишком неоднозначны. Формальные языки, включая языки программирования, могут быть менее неоднозначны, но будут непонятными большинству экспертов. Между этими двумя вариантами должны быть найдены точки соприкосновения, требуются и стандартный диалоговый язык, чтобы устранить неоднозначность и облегчать диалог, и обычный хорошо понятный язык для широких пользователей.
Ряд методов, направленных на достижение этой цели, был разработан ВВС США (USAF) в 1970 году как часть ``Программы встраиваемых средств разработки'' (Integrated Computer-aided Manufacturing Program). Цель этой программы состояла в том, чтобы разработать ``обобщенные подсистемы'', которые могли бы многократно использоваться большим количеством фирм и компаний. Чтобы создавать эти подсистемы, язык был разработан таким, чтобы описать только общие функции. Результатом этой программы явилась методология IDEF0, с базисными понятиями, являющимися графическим, кратким, и точным представлением бизнеспроцессов.
Компонент графического представления - вероятно, наиболее очевидная характеристика стандарта IDEF0. Поля, используемые для представления действий и операций, и стрелки для представления данных, ресурсов, средств управления или интерфейсов к этим средствам - вот основные элементы IDEF0.
Возможность создания IDEF0-совместимых диаграмм с элементами рисования и приложениями составления блок-схем, поддержания целостности ссылок между диаграммами (то есть стрелка, упоминаемая в одной диаграмме, должна быть упомянута во всех других соответствующих диаграммах) в BPWin очень легка, в то время как ``ручная'' разработка таких диаграмм подвержена ошибкам и очень трудоемка. Использование BPwin для графического моделирования процесса обеспечивает легкое использование связей и диаграмм и автоматизирует запись IDEF0 для достижения проверки целостности модели.
Краткое введение в стандарты IDEF0
В IDEF0 диаграмме прямоугольниками обозначаются действия, активности (activities), которые помечаются соответствующим глаголом или глагольной формой.
Стрелками, как уже было сказано, помечаются различные ресурсы.
Существует пять типов стрелок, сгруппированных по их отношениям к конкретным активностям.
Input Arrow (Входная стрелка). Входные данные трансформируются активностью в выходные. Возможно, что некоторые активности могут не иметь входных стрелок. Они относятся к левой стороне прямоугольника на диаграмме IDEF0.
Control Arrow (Управляющая стрелка). Элементы управления, регулирующие, как, когда и на каких условиях срабатывает активность. Они относятся к верхней стороне прямоугольника IDEF0.
Output Arrow (Выходная стрелка). Выходные данные - результат работы активности. Каждая активность должна иметь, по крайней мере, одну выходную стрелку. Они относятся к правой стороне прямоугольника IDEF0.
Mechanism Arrow (Стрелка механизма). Механизмы - это ресурсы или системы, которые производят действие. Они относятся к нижней стороне прямоугольника IDEF0.
Call Arrow (Стрелка вызова). Ссылка на присоединенную модель, являющаяся некоторого рода целостностью.
Диаграммы IDEF0 являются некоторым подобием диаграмм потоков данных одновременно. Серьезным отличием этого стандарта от других является его жесткая специфицированность, благодаря которой обработка и оценка таких диаграмм выполняется полностью автоматически. Хорошо видно, что диаграмма IDEF0 просты и понятны даже экспертам, не имеющим отношения к программированию, но, в то же время, они являются мощным и универсальным средством описания моделей. Лучше всего диаграммы такого типа применимы к описанию процессов в бизнесе и производстве.
Ценовая оценка, основанная на стандарте IDEF0
Было сказано, что каждый прямоугольник на IDEF0-диаграмме обозначает собой определенное действие (активность). Активности могут быть связаны между собой различными отношениями. Рассмотрим два из них: отношение FOL (following - когда вход одной активности является выходом другой), и отношение POF (a part of - когда несколько активностей иерархически абстрагируются до одной активности, являясь ее составными частями). Наличие уже этих двух соотношений дает возможности широкого анализа. Предположим, что каждой активности приписана некоторая оценка, например, ценовая. Тогда ценовая оценка активности, включающей в себя другие активности по отношению POF, получается как сумма всех активностей нижнего уровня. Напротив, если имеется временная оценка активностей, то общее время, требуемое для выполнения всех активностей, связанных отношением FOL, вычисляется как сумма времени выполнения каждой из активностей. Благодаря только таким средствам анализа, можно выявить критический путь по времени внутри процесса или найти активности, на выполнение которых затрачивается максимальное количество средств. Анализ происходит автоматически, причем, имеется возможность анимации модели и просмотра выполнения активностей в реальном масштабе времени.
CA BPwin, таким образом, является классической верхней CASE-системой, предназначенной для оптимизации по различным параметрам моделей процессов, связанных с затратами времени и иных ресурсов.