Концепция системы комплексной автоматизации "Оберон"

Как уже упоминалось во вступлении, создание Системы комплексной автоматизации "Оберон" преследовало цель подготовки инструмента для специалиста, занятого реорганизацией бизнес-процессов некоего объекта автоматизации. Поскольку в роли этого специалиста авторы видели и продолжают видеть прежде всего себя, то дальше в этом разделе, применительно к этому специалисту, будут использоваться местоимения первого лица.

Итак, нам предстоит прийти на объект автоматизации, разобраться в деталях предметной области (ознакомившись с нашими прикладными решениями, созданными менее чем за 7 лет силами, в основном, двух человек, легко убедиться, что никакие ограничения на предметную область исполняемым ядром СКА "Оберон" никоим образом не накладываются), на основании полученных данных и собственного опыта составить первое приближение к модели будущего бизнес-процесса, создать прототип автоматизированной системы, этот бизнес-процесс обслуживающей, довести этот прототип до состояния программного комплекса, переданного в промышленную эксплуатацию, постепенно передать его для текущего обслуживания специалистам объекта автоматизации и в дальнейшем развивать его во взаимодействии с заказчиком. В общем, создать методом последовательных приближений "под ключ" автоматизированную систему, способную модернизироваться в процессе эксплуатации.

И что нам для этого нужно?

Необходимая гибкость

Создать систему, которая будет все уметь и ничего от пользователя не требовать, невозможно. Нужно понимать, что чем более универсальна программа, тем менее она эффективна и эргономична. Чудес, увы не бывает: из одной мухи можно сделать только одного слона.

Потому, для начала, определим, что должен уметь инструмент, который мы для себя готовим.

Прежде всего, он должен обеспечивать работу с базой данных. При этом мы отдаем себе отчет, что в разных случаях это будут очень сильно разные базы данных - и по объему данных, и по частоте обновления, и по требованиям к безопасности, и по характеру превалирующих запросов, и по допустимым требованиям к обслуживающему персоналу. То есть, наш инструмент должен давать возможность взаимодействовать с базами данных под управлением различных систем управления базами данных (СУБД).

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

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

В некоторых случаях нет технической возможности, а иногда совершенно недопустимо по нетехническим соображениям делать сложную систему, затрагивающую многочисленные территориально распределенные структуры, в виде единого приложения, работающего на единой базе данных. Инструментальный комплекс долежн позволять создавать распределенные системы, состоящие из сети более или менее автономных узлов, каждый из которых работает на собственной базе данных, но все они существуют в единой информационной системе, с единой системой нормативно-справочной информации (и системой ее автоматического распределения по заданной топологии!), с распределенной обработкой объектов предметной области, с единой централизованной системой обновления версий.

Не зависимо от того, под управлением какой СУБД будет работать прикладное приложение, оно должно обеспечить защиту этой базы данных от злоумышленника. Многие создатели СУБД приложили немало усилий, чтобы защитить свои СУБД, будет уместно при создании прикладного решения на базе такой СУБД воспользоваться плодами их усилий и организовать авторизацию пользователей средствами СУБД. А вот систему разграничения полномочий на доступ к данным и функционалу прикладного решения, а также систему жесткого протоколирования действий конечного пользователя и последующего их аудита создать нужно уже самостоятельно.

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

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

Отделение инструментального слоя

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

И в то же время, нам, как создателям СКА "Оберон", не хочется априори отказываться ни от каких возможностей. Мы оставляем за собой право и возможность вернуться и к экранным, и к триггерным "рюшечкам".

Просто в другое время. "Есть время собирать камни и есть время разбрасывать камни". Работая с прикладным специалистом, мы хотим разговаривать на его языке.

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

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

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

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

Это позволяет, работая с прикладным специалистом, забыть на время весь кошмар инструментальной поддержки и сосредоточиться на прикладном решении. И в то же время, продолжать полностью контролировать инструментальные средства и иметь возможность, если нужно, подстроиться под новые требования. При этом все полезные нововведения сразу автоматически станут доступны во всех прикладных приложениях.

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

Метаданные

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

Модификация метаданных производится при помощи двух программ-дизайнеров, условно названных АРМом Технолога и АРМом Администратора. В АРМе Технолога описываются сущности системы, их реквизитный состав и взаимосвязь между ними. (Подробнее с терминами, применяемыми в контексте СКА "Оберон", можно ознакомиться в разделе "Терминология"). АРМ Администратора предназначен для описания экранов системы, их взаимного соотнесения и меню, появляющегося на каждом из них.

Метаданные системы используются на этапе проектирования, прототипирования, для построения SQL-скрипта для создания базы данных системы, и они же интерпретируются и используются Универсальным АРМом Пользователя в ходе эксплуатации системы.

Версионность

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

И все это время она изменяется.

С момента, когда первый прикладной специалист увидел первый прототип, и до момента полного уничтожения прикладной системы когда-нибудь в светлой (надеемся) дали, система непрерывно модифицируется. Это характерно для любой живой системы, но СКА "Оберон" создана специально с расчетом на эти изменения.

"На местности" это означает, что в любой момент времени существует версия метаданных системы (из Универсального АРМа Пользователя номер версии можно увидеть из пункта меню "Разное" -> "О системе" главного окна любого АРМа). Новая версия автоматически создается, когда наживается кнопка "Сохранить" на главном экране АРМа Технолога.

Помимо этого, АРМ Технолога содержит специальный режим сравнения версий метаданных, который, помимо собственно сравнения версий, имеет режим генерации SQL-скрипта для корректного перехода прикладной системы от одной версии к другой. Разумеется, SQL-скрипт строится для любой из поддерживаемых СКА "Оберон" СУБД.

Ну и, разумеется, в состав исполняющего ядра прикладной системы, построенной с использованием СКА "Оберон", входит механизм автоматической смены версий. Он включает в себя: централизованную рассылку навой версии на удаленные узлы распределенной системы; загрузку новой версии в базу данных узла; выполнение SQL-скриптов для смены структуры базы данных и переноса данных в новую структуру; сверку при каждом запуске Универсального АРМа Пользователя версии, хранимой в базе данных, с той, что установлена на рабочем месте пользователя и обновление при необходимости локальной версии программы на компьютере пользователя.

Бизнес-логика

Бизнес-логика прикладной системы, как правило, привязана к манипуляциям пользователя над объектами базы данных. Нужно не просто сохранить введенные значения в базе данных, но и выполнить по ходу некоторые проверки и произвести определенные действия. Для реализации подобного функционала служат триггерные точки входа в систему, описываемые в АРМе Технолога при описании сущностей прикладной системы.

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

Как в процедурных, так и в триггерных точках входа работают макрозадания, созданные на одном из интерпретируемых ("скриптовых") языков, поддерживаемых СКА "Оберон". Эти языки, особенно "родной" для операционных систем семейства MS Windows язык VisualBasic, имеют неограниченные возможности для организации взаимодействия СКА "Оберон" с внешними системами - от электронной почты до офисных приложений. Там же, где этих возможностей не хватает или их использование избыточно сложно, возможности этих языков значительно расширены средствами собственно исполняющего ядра СКА "Оберон".

Подробнее о создании макрозаданий и о доступных в них инструментах прикладного программиста, рассказано в разделе "Программисту".

Масштабируемость

Масштабируемость прикладного решения достигается при помощи использования для хранения базы данных прикладной системы целой линейки Систем управления базами данных - от простейшей настольной не требующей администрирования в принципе SQLite, и до мощных промышленных СУБД, работающих на больших компьютерах или на кластерах компьютеров.

При этом само по себе прикладное решение, выполненное с использованием СКА "Оберон", является полностью независимым от используемой СУБД. В порядке вещея использование различных СУБД на различных узлах одной и той же прикладной системы, в том числе и на узлах, идентичных по используемому функционалу. В разделе "Решения" описано прикладное решение Национального депозитария Украины, в рамках единой системы депочитарного учета которого часть узлов хранителей ценных бумаг работает под управлением СУБД MS SQL (от 2000 до 2008), а часть - под управлением СУБД Oracle (от 8i до 10g).

Исполняющее же ядро прикладной системы построено так, что сохраняет работоспособность при всех мыслимых вариантах конфигурации операционных систем семейства MS Windows - от "Windows 95 OSR2" до 64-разрядных "Windows 7" и "Windows 2008 Server", в том числе и на виртуальных машинах. Оно крайне неприхотливо и само по себе нетребовательно к ресурсам компьютера. Требования к ресурсам компьютера пользователя растут лишь с ростом сложности прикладной системы, увеличением количества сущностей и сложности выполняемых функций.

Пошаговая обработка

Бизнес-логика прикладной системы, связанная с объектами сущностей, в большинстве случаев привязана к базовым событиям этих сущностей. Так, создание в системе объекта сущности "Проводка" всегда влечет немедленные изменения в объектах сущности "Остаток на счете". Удаление объекта сущности "Проводка" также влечет изменения - обратные. Для реализации такого функционала идеально подходят триггерные входы в систему, о которых упоминалось ранее.

В более сложных случаях, когда, например, документ складского учета может быть сначала просто введен, потом многократно скорректирован, "расценен", завизирован и только потом проведен (в соответствии с его реквизитами, создан один или более объект сущности "Проводка"), для отслеживания выполненных над таким документом операций, а также для отслеживание документов, обработка которых не завершена, вводится отдельный атрибут сущности - состояние: "Введен", "Завизирован", "Проведен" и т.п.

Иногда для хранения перечня возможных состояний объекта некоторой сущности достаточно перечисления (см. раздел " Терминология"). Однако встречаются очень сложные случаи, когда алгоритм обработки экземпляра сущности нелинеен, в нем встречаются ветвления, возможно, даже циклы.

В таком случае применяется механизм пошаговой обработки.

Он состоит в том, что создается, по сути, достаточно сложный конечный автомат Мили (см. "Теорию конечных автоматов"), на вход которого подается все состояние базы данных узла, а также пользователь системы. Автомат, в зависимости от состояния объекта и состояния базы данных, выполняет некоторые действия над базой данных и изменяет состояние объекта. После чего новое состояние объекта подается на вход того же автомата - и так до тех пор, пока объект не перейдет в одно из состояний, являющихся финальными (состояниями, из которых не предусмотрено переходов).

Возможно, на словах это очень сложно и отдает псевдонаучной чертовщиной, но на самом деле это очень просто и прозрачно. Сложный алгоритм обработки объектов сущности разбивается на фрагменты, каждый из которых относительно прост, и реализуется этот фрагмент. Каждый фрагмент алгоритма выполняется над объектом, оказавшемся в некотором состоянии (справочник состояний, в которых может находиться объект, описывается в этом случае как достаточно простая самостоятельная сущность системы). После выполнения этого фрагмента объект переходит в одно из следующих состояний. Например, из состояния документа "Введен" фрагмент алгоритма может, в зависимости от реквизитов документа, перевести его в состояние "Нуждается в визировании" или сразу в состояние "Готов к проводке". Из состояния "Нуждается в визировании" уполномоченный сотрудник может перевести его в состояние "Готов к проводке" (завизировать) или "Отклонен". Документ в состоянии "Готов к проводке" проводится (что бы ни означал этот термин применительно к этому документу) не зависимо от того, отправлялся он на визирование и прошел его - или миновал этот этап обработки.

Таким образом выстраивается некоторый направленный граф переходов состояний объекта сущности, вершинами которого являются допустимые состояния объекта, а ребрами - допустимые переходы. Фрагмент же алгоритма, применяемый к объекту, находящемуся в определенном состоянии и переводящий его в другое состояние (возможно, производя попутно и другие действия в системе), называется шагом. Различают активные, пассивные и интерактивные шаги.

Активный шаг выполняется немедленно при переходе объекта в соответствующее состояние (например, шаг, выполняемый на состоянии "Готов к проводке" в приведенном выше примере).

Пассивный шаг выполняется после прихода реакции из внешней системы или с другого узла распределенной системы. Например, отправить платежный документ в расчетный банк и ожидать реакции банковской системы; по получении реакции - продолжить обработку.

Интерактивный шаг выполняется пользователем. Примером такого шага является шаг визирования в приведенном выше примере. Как правило, он реализуется как экранное окно типа "Грид" с несколькими кнопками, означающими принятое пользователем решение ("Разрешить", "Отклонить", "Вернуть на доработку" и т.п.).

Графы переходов состояний объектов конкретных сущностей прикладных систем могут быть достаточно сложными, цикличными, несвязными. Все зависит от предметной области. Никаких огланичений на возможный граф перехода состояний СКА "Оберон" не накладывает.

В большинстве случаев для построения прикладной системы вполне достаточно одной сущности, на которой реализован механизм пошаговой обработки. Однако, и здесь Система комплексной автоматизации "Оберон" никаких ограничений не накладывает. Например, в описанном в разделе "Решения" системе канцелярского документооборота, самостоятельные графы переходов состояний построены для нескольких сущностей: "Документ", "Узел маршрута", "Оповещение", "Дело". В описанной там же Биржевой электронной торговой системе собственные графы переходов состояний (правда, относительно простые) имеют две сущности - "Заявка" и "Сделка".

Распределенная обработка

Особым случаем пошаговой обработки объекта системы является его распределенная обработка. Под распределенной понимается последовательная или паралельная обработка одного и того же объекта на нескольких узлах распределенной системы.

Проблема распределенной обработки распадается на две части: передача на нужные узлы объекта, подлежащего распределенной обработке, и синхронизация обработки на разных узлах.

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

В случае выбора варианта с подпиской и последующей репликацией, проблема синхронизации обработки решается автоматически: двусторонняя репликация изменений объекта обеспечивает ретрансляцию изменения состояния объекта на все узлы, на которые он был доставлен.

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

Каждая из систем распределенной обработки имеет свои преимущества, обе они реализованы в законченных проектах (так, на системе репликаций построена Биржевая электронная торговая система "Оберон-БЛИЦ", а на электронном документообороте - Система депозитарного учета Национального депозитария Украины - см. раздел "Решения"). Выбор той или иной системы распределенной обработки осуществляется в зависимости от особенностей предмета автоматизации.

Защита

Защита - очень многогранное понятие. О мероприятиях, относящихся к различным граням этого понятия, и предпринимаемым в рамках СКА "Оберон" в целом и в каждом из прикладных решений в частности, можно говорить много. Но лучше не надо. Мы лишь напомним, что авторы системы долгое время работали над созданием банковского программного обеспечения, где вопросам защиты уделяется особое, на грани паранойи, внимание, и вкратце остановимся на некоторых аспектах защиты прикладных систем, созданных с использованием СКА "Оберон".

Авторизация пользователей осуществляется средствами СУБД. Там, где в базе данных хранится информация, представляющая коммерческое значение, для обслуживания базы данных используется промышленная СУБД с высокой степенью защиты паролей пользователей.

SQL-скрипты, генерируемые в АРМе Технолога для создания или модификации базы данных, построены таким образом, что пользователь СУБД (и прикладной системы, соответственно) не имеет доступа к таблицам базы данных. Доступ осуществляется только посредством хранимых процедур и представлений.

В АРМе Технолога, на правах метаданных системы, ведется перечень полномочий, которыми оперирует прикладная система. Некоторые из этих полномочий скалярные, другие предоставляются в разрезе объектов одной из сущностей прикладной системы. Для каждой сущности и/или грида сущности может быть описано полномочие, которым должен быть наделен пользователь для того, чтобы получить доступ к объектам этой сущности. Если полномочие предоставляется в разрезе сущности, то должно быть указано поле сущности, хранящее идентификатор соответствующего объекта. Все действия, необходимые для проверки полномочий пользователя, закладываются АРМом Технолога в соответствующие хранимые процедуры и представления, потому пользователь, даже получив доступ к базе данных минуя исполняющее ядро системы, имеет только те же возможности, что и посредством системы.

Полномочия распределяются в процессе эксплуатации системы и записи о их присвоении являются частью данных, а не метаданных системы.

Те же полномочия служат и для разграничения доступа к функционалу системы. Каждому пункту любого меню, описываемого в АРМе Администратора, может быть поставлено в соответствие определенное полномочие. В случае, если это полномочие определено, соответствующий пункт меню (или целое подменю) будет доступен только тем пользователям, которым это полномочие присвоено.

Хранимые процедуры, генерируемые АРМом Технолога для доступа к объектам любой из сущностей, обязательно содержат программный код для подробного протоколирования действия пользователя: кто, когда, какой объект создавал/изменял/удалял, какие поля менял, какие значения на какие значения заменил. Поскольку пользователь средствами СУБД лишен прямого доступа к таблицам базы данных, то протоколирование ведется и в том случае, если доступ к базе данных будет осуществлен минуя исполняющее ядро системы. Система, разумеется, включает средства аудита, позволяющие разобраться, кто и что натворил с данными.

Криптографическая защита данных применяется в прикладных системах по мере необходимости. СКА "Оберон" не имеет собственной системы криптозащиты информации и при необходимости использует внешние системы по выбору заказчика. Подключение внешней системы криптозащиты осуществляется при помощи унифицированного механизма плагинов. Схема использования криптозащиты в каждом случае строится с учетом специфики предметной области.

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

Расширяемость

Там, где для обеспечения необходимых для функционирования прикладной системы функций не хватает возможности, гибкости или эффективности реализации интерпретируемых ("скриптовых") языков, применяется механизм плагинов (или идаче блоков расширения бизнес-логики).

Наиболее характерными примерами являются специфическое взаимодействие между узлами распределенной системы в режиме on-line и криптографические преобразования.

Подробное освещение механизма плагинов выходит за рамки настоящего повествования, в завершение можно лишь сообщить, что плагины представляют собой динамические библиотеки (DLL) специальной структуры, помещаемые в определенную директорию и автоматически "поднимаемые" исполняющим ядром Системы комплексной автоматизации "Оберон". Доступ же к их функционалу осуществляется посредством пунктов меню отдельного типа, описываемых при в АРМе Администратора, или из макрозадания, посредством вызова функции RunDisp.

Перевод, языки

Базовым языком СКА "Оберон" по историческим причинам является русский, а не украинский, за что авторы приносят отдельные извинения.

Однако, прикладное решение, разработанное при помощи СКА "Оберон", может быть переведено на любой язык или на любые языки.

Для этой цели как в АРМе Технолога, так и в АРМе Администратора предусмотрена возможность работы со словарем. В словаре (так же, как и метаданные системы, хранится в файле формата XML) перечисляются рабочие языки прикладной системы и дается перевод на каждый из этих языков каждого из строчных литералов, как системных, так и привнесенных Технологом и Администратором (названия пунктов меню, подсказки к полям сущностей и форм и т.д.).

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

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