2015-06-16
438
Помимо описания структуры функций, цель этапа формулировки требований заключается в установлении процедурной последовательности функций, что фактически прокладывает путь к описанию процессов. В отличие от описания процессов на уровне модели управления, которое выполняется позже, на этом этапе описываются логические последовательности функций, но не их активизаторы (т.е. события). Это рекомендуется в тех случаях, когда активизирующие события или сообщения носят настолько рутинный характер, что не вносят никакой дополнительной информации на этапе определения требований, или когда события, активизирующие функцию, добавляются позже — на стадии проектирования.
Для описания процедур можно воспользоваться методами сетевых диаграмм, представляющих различные отношения типа предшествующая-последующая, метрики расстояний, возможные наложения и минимальные расстояния между событиями. Кроме того, можно описать логические связи между входящими и исходящими элементами соответственно входящих и исходящих отношений.
На рис. 25 часть древовидного индекса, приведенного на рис. 19а, представлена в виде процедуры. Это подтверждает, что изначально описать контекст процедуры на основании древовидного индекса нельзя. После соответствующих расчетов, для которых необходимо знать «приближенные показатели» (например, ставки заработной платы) и стоимость заказываемого оборудования, описывается узел решений с тремя альтернативными исходящими ветвями: составление нового технического предложения, если вычисленная цена нереальна; отказ от выполнения, если есть основания полагать, что предложение не будет принято; выполнение заказа, поскольку клиент принял предложение. Вероятность каждой альтернативы можно привязать в качестве атрибута. Поскольку эти альтернативы взаимоисключающие, их максимальная мощность должна равняться 1.
Рис. 25. Процедурная последовательность функций
Эта концепция из GERT (графический метод оценки и анализа; см. Elmaghraby. Activity Networks. 1977; Scheer. Projektsteuerung. 1978).
Введенный здесь узел решений может быть выделен в отдельный элемент, но может интерпретироваться и как нормальное событие с нулевой временной продолжительностью либо как часть предыдущего события.
Упорядоченные отношения образуют в рамках класса ФУНКЦИЯ новую ассоциацию - ПОЗИЦИОНИРОВАНИЕ. Каждое ^ношение позиционирования можно идентифицировать по предыдущему и последующему этапу функции. Добавление на рис. 26 ассоциативного класса ПОЗИЦИОНИРОВАНИЕ позволяет присваивать в качестве атрибутов метрики расстояния для наложений, задержки или коэффициенты (их значения помещаются на соответствующие ветви).
Рис. 26. Учет позиционных отношений
Логические зависимости между ребрами соответствующего графа присваивают-я отношениям позиционирования в качестве атрибутов.
Для функций, преобразующих материалы, процедурные последовательности
описываются в графиках работ. Понятие «график работ» уже предполагает описание некоего процесса, особенно в силу того, что такие графики содержат элементы других моделей ARIS (организационные единицы, ресурсы, материальные выходы). Однако в график работ явным образом не входит управление событиями, поэтому динамика процесса, описываемая позже в модели управления, тоже не находит в нем явного отражения.
Графики работ относятся к изготовлению деталей и могут составляться применительно к разным уровням их описания. Графики работ для подклассов создаются на уровне типов, как показано в упрощенном примере на рис. 27а. Каждая операция описывает функцию, а график работ, как она включается в процесс.
| График работ для изделий из листового металла | |||
| Номер операции | Название операции | Продолжительность (средняя) | Группа производственных ресурсов |
| Сверление | ГПР 1 | ||
| Фрезерование | ГПР5 | ||
| Снятие заусенцев | ГПР 4 | ||
| Промывка | ГПР 7 |
Рис. 27а. График работ на уровне типов деталей
Операции соответствуют техническим процедурам. Технические процедуры можно описывать независимо от контекста графика работ, а затем уточнять их в контексте этого графика или процесса на более позднем этапе. Диаграммы классов соответствуют рис. 276. С технической точки зрения, эта диаграмма идентична метаструктуре функции, показанной на рис. 21 (БИЗНЕС-ПРОЦЕСС, ОБЩАЯ ФУНКЦИЯ, ФУНКЦИЯ). Таким образом, последовательности технических функций можно рассматривать так же, как последовательности административных функций.
Документирование графиков работ – одна из классических задач планирования и управления производством в информационных системах. Графики работ анализируются на уровне деталей с привлечением экземпляров классов деталей и заполнением соответствующих баз данных.
Рис. 27б. Диаграмма классов для графиков работ
Диаграмма классов для администрирования графиков работ, относящихся к изготовлению деталей, представлена на рис. 27б (Scheer. Business Process Engineering. 1994, с. 216). Контекст процесса становится ясен из описания отношения между деталями, которое теперь становится подэкземпляром.
Обычно в моделировании бизнес-процессов не принято использовать функции, связанные с деталями. Если это и делается, то лишь применительно к особо важным конечным продуктам.
Графики работ на уровне типов и экземпляров, которые мы рассматривали до сих пор, аналогичны эталонным данным; том смысле, что они не зависят от контекста заказов, привязанных к фактору времени, хотя экземпляры, управляемые системами workflow, привязаны к заказам. Здесь эталонные графики работ, оперирующие типами и экземплярами, являются своего рода шаблонами. В системах ПиУП эталонные графики работ, соответственно оперирующие данными и заказами, также рассматриваются параллельно.
