А.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, привязаны к заказам. Здесь эталонные графики работ, оперирующие типами и экземплярами, являются своего рода шаблонами. В системах ПиУП эталонные графики работ, соответственно оперирующие данными и заказами, также рассматриваются параллельно.
А.2.1.1.3. Типы обработки
Для того чтобы описать способ реализации функции (средствами ИТ или вручную), при спецификации понятия ФУНКЦИЯ можно разграничить СИСТЕМНУЮ ФУНКЦИЮ и РУЧНУЮ ФУНКЦИЮ (см. рис. 28).
Рис. 28. Спецификация понятия «функция»
Системные функции порождают заказы клиентов, сопровождают данные о клиентах, ведут статистику и т.п. при помощи информационных систем. Если ПРИКЛАДНАЯ СИСТЕМА уже известна, то эта информация также приобщается к системной функции. Однако такие сведения должны носить лишь общий характер (например, имя бизнес-приложения), чтобы заранее не предопределять описание на уровне спецификации проекта.
Этап определения требований включает также описание типа предварительной обработки для системных функций. Один из ключевых параметров типа обработки определяется в зависимости от ситуации: могут ли пользователи вносить коррективы в процесс (оперативная обработка) или же функции выполняются без вмешательства со стороны пользователей (пакетная обработка). Чтобы решить, подходит ли данная функция для оперативной обработки, можно воспользоваться параметрами, приведенными и на рис. 29. Исходя из этих соображений, мы подразделяем класс СИСТЕМНАЯ ФУНКЦИЯ на подклассы ОПЕРАТИВНАЯ ФУНКЦИЯ и ГРУППОВАЯ ФУНКЦИЯ.
| Свойства Цели | Управляемость событиями | Возможность интеграции функции | Допускает интерактивные решения | Устраняет пиковые нагрузки | Позволяет вносить улучшения | Позволяет повышать качество |
| Экономия времени | • | • | • | • | • | |
| Экономия рабочей силы | • | • | • | |||
| Получение Информации | • | • | • | |||
| Создание благоприятных условий работы | • | • | • | • | • | |
| Оптимизация организационных процессов | • | • | • |
Рис . 29. Параметры и цели оперативной обработки
А.2.1.1.4. Модели решений
Помимо административных целей, информационные системы используются также для поддержки решений, например, для оптимизации производственного планирования.
В качестве примера приведем типичную структуру модели решеня и рассмотрим метод линейного программирования (ЛП). В моделях ЛП — при соблюдении всех вторичных условий — переменные задаются таким образом, чтобы максимизировать целевые функции (см. рис. 30). Структуры ЛП не связаны с каким-либо конкретным приложением и располагаются на метауровне описания моделей решений. На рис. 31 представлена модель ЛП на 2-ом уровне абстракции, относящаяся к приложению для планирования производства (уровни абстракции в моделировании см. Scheer. ARIS — Business Process Frameworks. 1998, с. 120-125; в русском издании с. 109-115).
| Целевая функция: | 
|
| Вторичные условия: |  для всех i
 для всех j
|
| Переменные: | 
|
| Коэффициенты: | 
|
Рис . 30. Структура модели ЛП
|  = вклад j-ro продукта
 = объем производства j-ro продукта
|
 (для всех I)
|  = потребности в мощностях 1-го типа на еденицу j-ro продукта
 = предельные мощности 1-го типа
|
 (для всех j)
|  = максимальный объем продаж j-ro продукта
|
Рис. 31. Модель ЛП для планирования производства
В представлении модели ЛП как диаграммы классов внимание фокусируется на объектах метамодели ЛП (см. рис. 30). Модели ЛП состоят из элементов ПЕРЕМЕННАЯ, УРАВНЕНИЕ (вторичные условия и целевые функции) и КОЭФФИЦИЕНТ.
Для отдельных моделей решений формируется класс МОДЕЛЬ РЕШЕНИЙ (см. j рис. 32). В одной ФУНКЦИИ (например, в планировании производства) можно использовать несколько моделей решений. И наоборот, одну модель решений можно » применять к нескольким разным функциям. Мощности отношений равны соответственно, (0,..*).
С одной моделью решений связывается несколько уравнений, при этом одни и те же уравнения могут встречаться в разных моделях (например, потребность во вспомогательных мощностях может фигурировать как в модели краткосрочного планирования производства, так и в модели планирования инвестиций).
Различные переменные, такие как, например, объем производства, объем продаж и размер инвестиций, могут использоваться в нескольких моделях решений
Отношение между заданными переменными (столбцы матрицы ЛП) и уравнениями (строки матрицы ЛП) устанавливается с помощью коэффициентов. В каждом столбце (т.е. для каждой переменной) коэффициенты можно подставлять во множество уравнений. И наоборот, в каждой "Роке (уравнении) можно рассматривать несколько переменных.
Генераторы матриц, переменные, уравнения и коэффициенты модели можно получить из базы данных, описав все допустимые индексные комбинации переменной на основе хранящегося в ней логического контекста (Scheer. Business Process Engineering. 1994, с. 525). Формат системы математического программирования (MPS) позволяет стандартизировать описание.
Рис . 32. Логическая структура моделей решений
Логическая структура модели решений, изображенная на рис. 32, представляет собой структуру данных для репозитория, где хранятся модели приложений (Scheer. Principles of Efficient Information Management. 1991, c. 157).
Дата добавления: 2019-02-26; просмотров: 170; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!