А.2.1.1.2. Последовательности процедур

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

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

На рис. 25 часть древовидного индекса, приведенного на рис. 19а, представлена в виде процедуры. Это подтверждает, что изначально описать контекст процедуры на основании древовидного индекса нельзя. После соответствующих расчетов, для которых необходимо знать «приближенные показатели» (например, ставки заработной платы) и стоимость заказываемого оборудования, описывается узел решений с тремя альтернативными исходящими ветвями: составление нового технического предложения, если вычисленная цена нереальна; отказ от выполнения, если есть основания полагать, что предложение не будет принято; выполнение заказа, поскольку клиент принял предложение. Вероятность каждой альтернативы можно привязать в качестве атрибута. Поскольку эти альтернативы взаимоисключающие, их максимальная мощность должна равняться 1.

Рис. 25. Процедурная последовательность функций

Эта концепция из GERT (графический метод оценки и анализа; см. Elmaghraby. Activity Networks. 1977; Scheer. Projektsteuerung. 1978).

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

Упорядоченные отношения образуют в рамках класса ФУНКЦИЯ новую ассоциацию - ПОЗИЦИОНИРОВАНИЕ. Каждое ^ношение позиционирования можно идентифицировать по предыдущему и последующему этапу функции. Добавление на рис. 26 ассоциативного класса ПОЗИЦИОНИРОВАНИЕ позволяет присваивать в качестве атрибутов метрики расстояния для наложений, задержки или коэффициенты (их значения помещаются на соответствующие ветви).

Рис. 26. Учет позиционных отношений

Логические зависимости между ребрами соответствующего графа присваивают-я отношениям позиционирования в качестве атрибутов.

Для функций, преобразующих материалы, процедурные последовательности

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

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

График работ для изделий из листового металла
Номер операции	Название операции	Продолжительность (средняя)	Группа производственных ресурсов
1	Сверление	1	ГПР 1
2	Фрезерование	2	ГПР5
3	Снятие заусенцев	3	ГПР 4
4	Промывка	4	ГПР 7

Рис. 27а. График работ на уровне типов деталей

Операции соответствуют техническим процедурам. Технические процедуры можно описывать независимо от контекста графика работ, а затем уточнять их в контексте этого графика или процесса на более позднем этапе. Диаграммы классов соответствуют рис. 276. С технической точки зрения, эта диаграмма идентична метаструктуре функции, показанной на рис. 21 (БИЗНЕС-ПРОЦЕСС, ОБЩАЯ ФУНКЦИЯ, ФУНКЦИЯ). Таким образом, последовательности технических функций можно рассматривать так же, как последовательности административных функций.

Документирование графиков работ – одна из классических задач планирования и управления производством в информационных системах. Графики работ анализируются на уровне деталей с привлечением экземпляров классов деталей и заполнением соответствующих баз данных.

Рис. 27б. Диаграмма классов для графиков работ

Диаграмма классов для администрирования графиков работ, относящихся к изготовлению деталей, представлена на рис. 27б (Scheer. Business Process Engineering. 1994, с. 216). Контекст процесса становится ясен из описания отношения между деталями, которое теперь становится подэкземпляром.

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

Графики работ на уровне типов и экземпляров, которые мы рассматривали до сих пор, аналогичны эталонным данным; том смысле, что они не зависят от контекста заказов, привязанных к фактору времени, хотя экземпляры, управляемые системами workflow, привязаны к заказам. Здесь эталонные графики работ, оперирующие типами и экземплярами, являются своего рода шаблонами. В системах ПиУП эталонные графики работ, соответственно оперирующие данными и заказами, также рассматриваются параллельно.