Большинство известных мне разработок КИС в России 1990-х годов шло «от бухгалтерии». Причина достаточно простая. Производство за первые 5 лет упало более чем вдвое, при этом у заводов, как правило, уже имелись свои системы, в том числе перенесённые с мейнфреймов на «персоналки» собственными силами отделов программистов, чаще всего в рамках файл-серверной технологии. В то же время рос сектор услуг, оптовой торговли и дистрибуции, многие предприятия создавались «с нуля», и для их автоматизации производственные системы не подходили за отсутствием собственно производства.
Поскольку основными потенциальными клиентами Ultima-S были именно оптово-розничные торговые компании, то функциональная архитектура системы базировалась на подходе «от бухгалтерии».
Запустив в эксплуатацию и получив в сопровождение систему, кратко описанную в предыдущей главе, программисты на собственном опыте убедились, что каждый физический слой увеличивает трудоёмкость разработки, тестирования и последующих модификаций системы. Поэтому, с учётом предполагаемого тиражирования, развивать продукт было решено в следующих направлениях:
• минимизация числа звеньев;
• «утончение» клиентского приложения, в идеале до уровня веб-браузера;
• использование промышленной СУБД для реализации бизнес-логики;
• реализация некоторых механизмов ООП для упрощения разработки прикладными и сторонними разработчиками методом надстраивания новых классов.
Синтезом вышеназванных приоритетов явилась двухзвенная архитектура с тонким клиентом.
Превратить промышленную СУБД в сервер приложений с технологической точки зрения просто. Для этого вам необходимо:
• запретить прямой доступ к таблицам базы данных;
• реализовать прикладную логику в виде хранимых процедур, функций и триггеров;
• разрешить доступ всех приложений только к соответствующим хранимым процедурам.
В технологии с тонким клиентом дополнительно потребуется:
• разработать протокол прикладного уровня для взаимодействия тонкого клиента и сервера приложений;
• запретить доступ ко всем объектам базы данных вообще, за исключением нескольких реализующих этот протокол хранимых процедур и, возможно, буферных таблиц.
Наконец, для надстройки над процедурным расширением SQL объектно-ориентированной среды, управляющей объектами предметной области, понадобилось:
• добавить поддержку декларации классов на уровне метаданных;
• реализовать механизм обработки сообщений между объектами;
• разработать набор базовых классов уровня ядра и служб системы (см. уровни).
Я не буду подробно останавливаться на сравнении преимуществ и недостатков использованной в продукте архитектуры, они достаточно известны и не раз обсуждались в разных формах. Скажу лишь, что для нас сумма преимуществ тогда перевесила. Во многих случаях перевесит и сейчас, даже если добавить ещё одно промежуточное звено из простейшей веб-службы, занимающейся ретрансляцией сообщений между терминалом и СУБД.
Рис. 9. Элементы логического устройства звеньев системы Ultima-S
В качестве базовой абстракции был выбран документ. То есть все объекты в системе – это документы, относящиеся к какому-либо их классу. Каждый документ хранился в одной из папок, составляющих иерархию, напоминающую вид обычного проводника Windows.
Рис. 10. Внешний вид тонкого клиента в КИС Ultima-S
В рамках механизма ООП, надстроенного над процедурным, поддерживалось одиночное наследование реализации. Вместо формальных конструкторов, деструкторов и методов основу составил механизм событий, вызывающий процедуры-обработчики в порядке, зависящем от иерархии классов.
В наибольшем выигрыше оказалось прикладное программирование. Сбылась «голубая мечта» – вся… нет, не так, ВСЯ разработка сосредоточилась в одном звене и среде на декларациях классов, свойств-операций и на реализующих обработку событий хранимых процедурах.
Тонкий клиент отображал в динамике результаты обработки события сервером. Большинство экранных форм, таким образом, формировалось автоматически, программист только объявлял в процедуре соответствующие поля ввода и сетки. Для специфичных случаев расположения элементов управления было необходимо визуально проектировать форму либо во встроенном в приложение редакторе, либо в среде Visual Basic, загрузив затем описание формы на сервер.
В общем случае, для создания программистом новых классов в системе было необходимо:
• декларировать классы;
• создать соответствующие таблицы;
• описать возможные ограничения на уровне метаданных (например, папку для создания по умолчанию или максимальное число ссылок);
• написать обработчики стандартных событий;
• добавить привилегии, видимые администратору;
• если необходимо, инициализировать данные, например, создать служебные объекты или документы-классификаторы.
Всё перечисленное программист мог сделать на макрорасширении над языком Transact SQL, не выходя за рамки разработки соответствующих скриптов. Приведу примеры использовавшегося кода.
Пример фрагментов кода модуля учёта сотрудников
