А.3.7.2. Конфигурирование
Включив все представления ARIS, можно скомпилировать сконфигурированные приложения и уже скомпонованные модульные приложения.
А.3.7.2.1. Конфигурирование на базе моделей бизнес-процессов
На рис. 160 показаны конфигурации, возможные в рамках модели бизнес-процессов на базе ARIS. Инфраструктура ARTS Framework поддерживает возможности конфигурирования в реальных приложениях (IDS. ARIS-Framework. 1997).
Рис. 160. Конфигурирование бизнес-процессов
Часть (а) представляет фрагмент существующей цепочки процессов для приложения, связанного с закупками. При активизации определенным событием возможна реализация обоих вариантов выполнения функции «обновить данные о закупках/продажах». ARIS Framework внедряет эту модель процесса в прототип действующей системы.
Часть (б) показывает, как пользователи могут манипулировать системой, изменяя ее конфигурацию путем обновления модели. При добавлении функции «проверить стоимость товара», которая выбирается из дерева функций, эта функция дополняется соответствующими функциональными модулями системы.
Используя атрибут «стоимость товара», организационное подразделение по приемке товара проверяет эти данные, после чего полученная информация интерпретируется системой workflow.
Если стоимость товара превышает заданный критерий, функция «обновить данные о закупках/продажах» выполняется руководителем подразделения.
Эта функция объединяет в себе две другие функции: «обновление данных о закупках» и «обновление данных о продажах». Эта новая ветвь включается в модель и интерпретируется системой workflow и инфраструктурой ARIS Framework. К функции «обновить данные о закупках/продажах» привязывается новый модуль от дерева модулей.
Компиляция функций обусловливает и выделение нового экрана. ARIS Framework и система workflow ARIS реализуют эти обновления модели в прототипах действующих систем.
Приведенный пример иллюстрирует такие возможности конфигурирования, как:
• модификация процессов,
• добавление функций,
• интеграция функций,
• обновление структуры организационной отчетности,
• обновление экранов.
В нем наглядно представлены также функциональные возможности для адаптации систем, открывающие широкие перспективы для непрерывного совершенствования процессов.
А.3.7.2.2. Конфигурирование бизнес-объектов
Если в качестве отправной точки конфигурирования выбраны бизнес-объекты, мы можем обратиться непосредственно к рис. 157.
На рис. 161 показано, как изменять элементы бизнес-объекта для настройки стандартного бизнес-объекта в соответствии с требованиями конкретного пользователя.
Рис. 161. Возможности индивидуальной настройки бизнес-объекта
А.3.7.3. Спецификация проекта
Если в описании на уровне определения требований модель процессов и модель объектов были «на равных» (модели процессов даже отдавалось предпочтение), то в последующих описаниях будут доминировать представления объектов. Это облегчает такие задачи реализации, как многократная применимость программ и повышение сопровождаемости системы.
Для настройки системы в соответствии со спецификацией проекта бизнес-элементы (функции, организационные единицы, объекты данных, выходы и т.д.) переносятся на уровень элементного модуля, узла, отношения и выходного объекта.
Кроме того, к бизнес-объекту привязываются межплатформные интерфейсы, являющиеся «посредниками» между прикладными программами и аппаратными средствами.
Особенно важны коммуникационные интерфейсы, предоставляемые определенными бизнес-объектами для доступа к другим бизнес-объектам, например, CORBA (общая архитектура брокера запросов к объектам), COM/DCOM (компонентная объектная модель/распределенная компонентная объектная модель) и вызов удаленных методов (RMI) для Java (см. рис. 162).
Рис. 162. Интерфейсы для бизнес-объектов
Затем различные элементы можно скомпоновать в бизнес-объект в соответствии со спецификацией проекта.