Сергей Тарасов - Дефрагментация мозга. Софтостроение изнутри

В другом случае четыре с половиной программиста сумели в короткие сроки создать и в течение многих лет сопровождать КИС для французского туроператора национального (один из крупнейших) и европейского уровня. Это уже потом к ней приделали веб-интерфейс для заказов клиентов и B2B [106] -шлюз с партнёрами.

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

На дворе стоял 1996 год, падение экономики если уже не прекратилось, то сильно замедлилось, но компания «Ниеншанц» приступила не просто к разработке очередной, третьей версии внутренней системы управления предприятием, а к созданию тиражируемого коробочного продукта. Словно в подтверждение мысли М. Донского о том, что техническая культура – это не производства и знания, а люди, умеющие это делать и применять [11].

Название у нового продукта возникло не сразу. К концу первого полугодия разработки продукта с кодовым названием Seller 3 руководство решило, что для широкого круга потенциальных клиентов название должно быть более «брендовым». Так появилась Ultima-S, где буква «S» перешла по наследству в качестве инициала прежнего имени.

Существует два основных подхода к разработке КИС, условно называемых « от производства » и « от бухгалтерии ».

В первом случае функциональным ядром системы становится планирование ресурсов производства. Упрощенно: на предприятии есть сотрудники, оборудование и сырьё (материалы, компоненты), с одной стороны, а с другой – план выпуска – «чего и сколько?» вкупе с технологией – «как?», то есть правилами, нормами и прочими ограничениями процесса преобразования сырья в готовую продукцию. В первом приближении, необходимо составить оптимальный по загрузке персонала и оборудования план этого процесса. После того как система научилась составлять производственный план, она тянет за собой все остальные функции: от кадров, ведь персонал не из воздуха появляется, и снабжения сырьём до складирования и сбыта готовой продукции.

Альтернативный путь проходит через бухгалтерию. Под термином «бухгалтерия» имеется в виду прежде всего внутренний, управленческий учёт на предприятии, а не фискальная её часть. Дело в том, что механизмы бухучёта придумали ещё в XV веке вовсе не ради подачи отчётности в средневековую налоговую инспекцию, а для понимания состояния дел на своём предприятии. Бухгалтерский учёт – хорошо формализуемая аппаратом матричной алгебры[13] абстракция для отражения и анализа хозяйственных операций в дискретных периодах времени, в том числе и будущих.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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