Дефрагментация мозга

Большинство известных мне разработок КИС в России 1990-х годов шло «от бухгалтерии». Причина достаточно простая. Производство за первые 5 лет упало более чем вдвое, при этом у заводов, как правило, уже имелись свои системы, в том числе перенесённые с мейнфреймов на «персоналки» собственными силами отделов программистов, чаще всего в рамках файл-серверной технологии. В то же время рос сектор услуг, оптовой торговли и дистрибуции, многие предприятия создавались «с нуля», и для их автоматизации производственные системы не подходили за отсутствием собственно производства.

Поскольку основными потенциальными клиентами Ultima-S были именно оптово-розничные торговые компании, то функциональная архитектура системы базировалась на подходе «от бухгалтерии».

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

• минимизация числа звеньев;

• «утончение» клиентского приложения, в идеале до уровня веб-браузера;

• использование промышленной СУБД для реализации бизнес-логики;

• реализация некоторых механизмов ООП для упрощения разработки прикладными и сторонними разработчиками методом надстраивания новых классов.

Синтезом вышеназванных приоритетов явилась двухзвенная архитектура с тонким клиентом.

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

• запретить прямой доступ к таблицам базы данных;

• реализовать прикладную логику в виде хранимых процедур, функций и триггеров;

• разрешить доступ всех приложений только к соответствующим хранимым процедурам.

В технологии с тонким клиентом дополнительно потребуется:

• разработать протокол прикладного уровня для взаимодействия тонкого клиента и сервера приложений;

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

Наконец, для надстройки над процедурным расширением SQL объектно-ориентированной среды, управляющей объектами предметной области, понадобилось:

• добавить поддержку декларации классов на уровне метаданных;

• реализовать механизм обработки сообщений между объектами;

• разработать набор базовых классов уровня ядра и служб системы (см. уровни).

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

Рис. 9. Элементы логического устройства звеньев системы Ultima-S

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

Рис. 10. Внешний вид тонкого клиента в КИС Ultima-S

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

В наибольшем выигрыше оказалось прикладное программирование. Сбылась «голубая мечта» – вся… нет, не так, ВСЯ разработка сосредоточилась в одном звене и среде на декларациях классов, свойств-операций и на реализующих обработку событий хранимых процедурах.

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

В общем случае, для создания программистом новых классов в системе было необходимо:

• декларировать классы;

• создать соответствующие таблицы;

• описать возможные ограничения на уровне метаданных (например, папку для создания по умолчанию или максимальное число ссылок);

• написать обработчики стандартных событий;

• добавить привилегии, видимые администратору;

• если необходимо, инициализировать данные, например, создать служебные объекты или документы-классификаторы.

Всё перечисленное программист мог сделать на макрорасширении над языком Transact SQL, не выходя за рамки разработки соответствующих скриптов. Приведу примеры использовавшегося кода.

Пример фрагментов кода модуля учёта сотрудников