Вердикт заказчика: размышления после “треугольного стола”

ТРЕУГОЛЬНЫЙ СТОЛ

Уже после завершения “треугольного стола” удалось собрать мнения по поводу систем-конструторов. Сначала это были заметки на половину общей тетради. А теперь все свелось к нескольким абзацам+

Об определениях, ядрах и инвариантах

Начну с определения и предложу альтернативное по отношению к выдвинутому Еленой Монаховой (PC Week/ RE, №11/2002, с. 29).

Николай Лумпов, аналитик торговой компании CONSUL

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

На мой взгляд, ядро, упомянутое в определении Е. Монаховой, входит в инвариант, но инвариант этим не исчерпывается.

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

Чем мощнее конструктор, чем выразительнее его средства, тем у’же инвариант и шире преобразование. Вообще, для мощных конструкторов область значений преобразования может быть охарактеризована лишь от противного - “что невозможно”. (Для примера: в СУБД инвариантом является реляционная алгебра. Более того, доказано, что и объектно-ориентированные СУБД также сводятся к реляционной алгебре.)

На пути к быстрому созданию приложений

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

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

О предметной области, веере технологий и его применении

Присутствующее в определении словосочетание “деловое приложение” явно или неявно указывает на предметную область. Конечно, ввести в определение предметную область - дело соблазнительное, но уж слишком общий термин - предметная область. А начнешь уточнять, какая конкретно область, тут же попадешь пальцем в небо. Лучше использовать термин “деловое приложение” - к этому, пожалуй, не сильно придерешься.

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

Инвариант методологий и технологий подразумевает, что конструктор должен нести в себе “веер технологий”, стержнем которого является базовое решение. Качественный (в смысле - хороший) инвариант несет в себе ряд сопутствующих полезностей. В частности, для достаточно технологичных и абстрактных моделей возможны следующие изыски:

1) с его помощью потребитель может реализовать любую собственную (так и хочется сказать - самостийную) технологию бизнеса;

2) или более тяжелый случай - потребитель находится в поиске, он “ищет” свою, единственно верную технологию бизнеса. Такую, которая станет его конкурентным преимуществом. И в конструкторе их находит;

3) однако даже потребителю, у которого все нормально с бизнес-процессами, требуются изменения. Для прототипирования, проверки ключевых моментов изменений вполне может использоваться система-конструктор. Если, конечно, она под рукой.

Коммерческий - значит отторгаемый от разработчика

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

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

О масштабных ограничениях и сложностях апгрейда

Возможности организации распределенной работы пользователей определяют “вес” системы и соответственно масштаб предприятия, которое может быть автоматизировано на базе конструктора. Чудес не бывает - не может файл-серверная система обеспечить одновременную работу даже сотни пользователей. (Уточняю: если сто пользователей одновременно начнут формировать отчеты, то увы+) Но независимо от того, как реализована распределенная работа и реализована ли она вообще, свойство инвариантности должно выполняться для системы любого “веса” или масштаба.

В заключение хотелось бы остановиться на одном парадоксальном свойстве конструктора, а именно исследовать возможность поддержки пользователей после апгрейда конструктора. Можно впасть в крайность и потребовать от разработчика поддержки модификаций конечных приложений. Так вот, более вдумчивое рассмотрение свойств конструктора позволяет выдвинуть неутешительную для потребителя гипотезу. Чем конструктор выразительнее и мощнее, тем сложнее модифицировать конечное приложение в соответствии с модификацией среды разработки и инварианта. Эту гипотезу, если она верна, можно применять для проверки состоятельности конструктора. Если разработчик изменяет конечные приложения, вероятно, он имеет не систему-конструктор, а всего лишь развитую систему конфигурирования пусть большого, но ограниченного функционала. Ну, просто много параметров конфигурирования. А где же “веер технологий”?

В пользу этой гипотезы приведу следующие соображения. Потребитель может использовать конструктор “неправильным” способом. Пусть он сделал это неосознанно, пусть это ошибка, которая не оказала никакого влияния на принятие решений. Разработчик готовит апгрейд исходя из представлений о правильном применении конструктора. Он даже не представляет себе, что можно сделать как-то иначе. Как разрешить коллизию, которая может возникнуть в ходе апгрейда? А то еще хуже. Апгрейд пройдет, приложение запустится, и тут-то все начнется! Да, скорее всего, как и в случае с программами, при переходе от одной среды программирования к другой все придется или переписывать, или перекомпилировать, или заново проводить сборку.

Как бы резюме

И какой же из всего этого вывод? Кому нужны конструкторы? Есть субъективное мнение, которое с помощью маркетинга можно превратить в объективное. Конструктор прежде всего нужен потребителям, пытающимся перевести разработку собственного программного обеспечения в более контролируемое русло. С прогнозируемым результатом, с прогнозируемым бюджетом и с обычным персоналом (без гениев).