
Основные принципы
Уровни автоматизации
Ограничение класса задач задачами MRP/MRPII, ERP и CRM, интенсивные процессы по их стандартизации, накопленный опыт и наработки в решении этих задач позволили нам пройти три эволюционных этапа автоматизации процесса разработки (рис.3).

Рис.3. Уровни автоматизации процесса разработки
Приведенные на рисунке три уровня автоматизации отображают три эволюционных этапа развития процесса разработки корпоративной информационной системы (КИС). На первом этапе КИС разрабатывается путем создания программного кода, отображающего логику взаимодействия програмных объектов и логику бизнес-процесов, автоматизируемых КИС. Каждый новый проект по разработке КИС – это новый программный код, разрабатываемый практически с нуля. Цикл разработки включает моделирование, проектирование и кодирование. При накоплении “критической массы” программного кода, после реализации нескольких проектов, у разработчиков появляется возможность создания системы параметризованных программных решений (ППР) или шаблонов проектирования, которые инкапсулируют в себе базовые методы решения задач разработки и по сути отображают опыт разработчиков по решению этих задач.
Создание системы ППР характеризует переход ко второму эволюционному этапу автоматизации. На этом этапе программирование заменяется конфигурированием (настройкой) системы ППР на решение конкретных задач. Результатом конфигурирования является логика работы системы ППР или металогика (логика “работы” логики). При этом система ППР имеет некий интерфейс конфигурирования (настройки) и может быть положена в основу Интерпретатора металогики, исполняющего металогику на лету. Такое решение выгодно как с точки зрения разработки (оно позволяет опробовать несколько разных прототипов системы без особых временных затрат, пример – Tcl/tk), так и с точки зрения архитектуры системы (оно позволяет использовать преимущества интернет-броузерной технологии). Цикл разработки на втором уровне автоматизации включает моделирование и проектирование, которое по своей сути выливается в конфигурирование системы ППР на языке металогики (например, XML). Выигрыш по времени разработки достигается за счет отсутствия трудоемкого полномасштабного кодирования.
Опыт разработчиков приобретает новое качество – теперь это опыт конфигурирования системы ППР на языке металогики. Со временем накапливается “критическая масса” уже конфигурационного кода и появляется возможность создания системы параметризованных конфигурационных решений (ПКР) или шаблонов моделирования, которые инкапсулируют в себе базовые принципы конфигурирования системы ППР исходя из поставленых задач. Создание системы ПКР характеризует переход к третьему эволюционному этапу автоматизации, на котором конфигурирование системы ППР заменяется конфигурированием системы ПКР. Интерфейсом конфигурирования (настройки) системы ПКР при этом служит некий язык моделирования (например, UML). Модель, построенная в рамках этого языка, интерпретируется Интерпретатором моделей в файл металогики готовый к выполнению уже в Интерпретаторе металогики. Таким образом, на третьем уровне автоматизации достаточно смоделировать задачу, после чего получить ее решение в готовом виде, т.е. цикл разработки сводится к моделированию, а выигрыш по времени разработки достигается за счет отсутствия этапов проектирования и кодирования.
Описанные эволюционные этапы становятся возможными в условиях ограничения класса задач, на решение которых рассчитаны те системы, которые разрабатываются на втором и третьем уровнях автоматизации. При этом искусство разработчика систем автоматизации заключается в расширении этого класса задач, что собственно и делает систему автоматизации сколь-нибудь ценной. Ограничения на решаемые классы задач описываются в виде ограничений на сложность языковых конструкций в рамках языка металогики (для второго уровня автоматизации) или языка моделирования (для третьего уровня автоматизации). Другими словами все упирается в возможности разработанных Интерпретатора металогики и Интерпретатора моделей.
Технологические решения
В свете вышеизложенного ключевым моментом автоматизации разработки являются принципы построения системы ППР и системы ПКР, а также принципы их взаимодействия. Здесь искусство разработчика проявляется в создании гибких жизнеспособных систем ППР и ПКР, отвечающих в первую очередь требованию функциональной полноты в рамках конкретного класса решаемых задач. Говоря о технологических решениях, разработанных командой на основании этих идей, можно утверждать следующее.
| 1. | Командой разработана и обкатана на практике система ПКР. На основе этой системы построен интерпретатор моделей, получивший название Sphere Modeler (Modeler). Входными данными для работы Интерпретатора моделей является модель задачи. Результатом работы Интерпретатора моделей является файл металогики. | | 2. |
Командой разработана и обкатана на практике система ППР. На основе этой системы построен интерпретатор металогики, получивший название Sphere Portal. В предложенной архитектуре металогика интерпретируется Sphere Portal-ом на лету, подобно тому как Internet Browser-ом интерпретируется HTML-документ. Отличие заключается в том, что результатом интерпретации является полноценный оконный интерфейс, реализующий все необходимые пользователю функции: от редактирования, сортировки и сложного поиска до составления аналитических отчетов и создания печатных форм. | | 3. |
Командой разработано решение позволяющее отделить прикладную функциональность от базовой. Т.е. удалось отделить специфическую прикладную функциональность, отображающую логику бизнес-процесса автоматизированного рабочего места (АРМ) заданного типа (например, АРМ менеджера по продажам) от базовой функциональности, отображающую логику манипулирования данными (ввод, хранение, редактирование, отображение, анализ, сортировка, поиск, составление отчетов, создание печатных форм и т.д.). Выделенная прикладная функциональность существует в виде файла металогики и обладает свойствами переносимости и модифицируемости. При этом появляется возможность параллельной разработки модулей металогики (с целью наиболее подробного описания бизнес-процессов заказчика) и базовых функциональных возможностей Sphere Portal (с целью их расширения и усовершенствования). Другими словами возможно параллельное усовершенствование Интерпретатора металогики и Интерпретатора моделей с сохранением обратной совместимости разработанных ранее модулей металогики.
|
|