ABOUT APPROACH TO DEVELOPMENT OF WEB-BASED PROJECTIVE INFORMATION SYSTEMS

Abstract

It is described a solution of the problem of improvement programmer’s productivity in information system develop- ment. It is based on the author’s approach, which lies in the field of metaprogramming.

Full Text

Мпаний, снижает издержки как самих пред- приятий, так и их клиентов. Как следствие возрастает спрос на разработку информационных систем (ИС), являющихся основой автоматизации предприятий [1]. Однако существует проблема доступности про- граммного обеспечения для малых предприятий: при выборе готовых продуктов это объясняется высокой стоимостью внедрения; а при создании отдела разра- ботки - трудностями управления штатными програм- мистами, если разработка программного обеспечения не является профилем предприятия. Уже на этапе проектирования ИС возникают про- блемы нечеткого оформления технического описания со стороны заказчика. Проблема усугубляется сроком их разработки (как правило, от 0,5 до 1,5 лет), в тече- ние которого изменяются первоначальные идеи и пре- тензии потребителей ИС. Возникает противоречие - осознание смены потребительских качеств будущей ИС порой опережает сроки их создания. В этой связи, с одной стороны, труд разработчика-программиста требует интенсификации, с другой - необходимо из- менить концептуальные основы проектирования ИС. Наиболее полное удовлетворение потребностей за- казчика ИС может обеспечить проективный подход [2]. К сожалению, популярные сегодня методы разра- ботки показывают плохие результаты, при частом пе- ресмотре требований к системе (Карл И. Вигерс. Раз- работка требований к программному обеспечению). Авторы статьи сделали попытку обосновать под- ход, позволяющий существенно повысить эффектив- ность труда программиста при разработке проектив- ных ИС. Предлагаемый подход опирается на концеп- цию метапрограммирования. Были поставлены следующие задачи: Определить основные компоненты среды разра- ботки ИС с Веб-интерфейсом и разработать проектив- ный подход к их разработке на основе смешанных парадигм программирования. Осуществить оценку эффективности предло- женного метода на примере разработки конкретных проективных систем. Исследование среды. Проведен анализ 30 проек- тов, выставленных на электронной бирже weblanc- er.net в категории Web-программирование. В резуль- тате обнаружено, что в 7 из них имеется техническое задание, в котором сформулированы следующие тре- бования: какие данные должны храниться в системе; каким образом данные должны попадать в сис- тему и выводиться ею. В остальных 23 дается ссылка на готовый проект, с закрытым кодом, и выдвигается требование сделать аналогичное ПО. Второй случай сводится к первому на этапе изучения программистом продукта-образца. В ходе изучения определяются данные и их представ- ления. Пример описания, потребителя, приведен на рис. 1. Опытный программист может сформировать пред- ставление о модели данных по описанию, сделанному со слов потребителя (рис. 1). Он может привести ее в нормальную форму и описать базу данных на языке SQL или построить UML-диаграмму в CASE-системе. Заметим, что даже при незначительной корректи- ровке технического описания заказчиком, програм- мист вынужден изменять набор полей сущности одно- временно во многих местах разрабатываемой ИС. В частности, следующие случаи обязывают его это сделать: непосредственная генерация базы данных; описание полей формы ввода; проверка корректности и безопасности получае- мых из формы данных; подготовка значения к выводу в HTML; подготовка значения к вводу в базу данных; инициализация значений «по умолчанию». В то же время известно, что в большинстве случаев как в пределах одного проекта, так и в разных проек- тах, к переменной поля заданного типа (например, «Текст с форматированием в формате HTML») будут применены идентичные алгоритмы. Хранение данных Покупатели Фамилия Имя Отчество Почтовый адрес Количество покупок Телефон E-mail Услуги Название Стоимость Договоры Покупатель Услуга Ответственный Стоимость Статус сделки Возможности сотрудников Директор Вывод списка клиентов с возможностью печати Вывод активных договоров с возможностью печати Вывод суммы по выполненным договорам Возможность изменить все цены услуг на заданный процент Менеджер Ввод клиентов Ввод договора Изменение статуса договора Ввод новых услуг Администратор (ИТ-специалист) Возможность видеть и редактировать все данные Рис. 1. Пример описания будущей ИС со слов потребителя image Таким образом, если в программе указан набор по- лей для данного конкретного случая, и компилятор, или ядро программы, «знает» логику обработки полей, то описание формы для программиста будет сведено к простому перечислению полей. Но описание будущей ИС (рис. 1) определяет не только модель данных. «Возможности сотрудников» де-факто являются вербальным описанием необходи- мых форм. Однако существующие системы програм- мирования не предоставляют нам достаточного набо- ра клише для их описания. Традиционно в этом месте начинается творческий процесс. Чем больше шагов необходимо предпринять для получения работающей программы на основе словес- ного описания, и чем они сложнее, тем больше време- ни и других ресурсов потребует разработка. Следова- тельно, необходим инструмент для того, чтобы чело- веческий язык максимально близко отображался на язык формальный, интерпретируемый компьютером [3; 4]. Для этого необходимо обратиться к опыту практической разработки ИС с Веб-интерфейсом. В результате многолетней практики в данной области, в том числе в рамках исследований промышленной разработки ИС на базе ООО «Веб-ресурс», были от- мечены следующие особенности создания исследуе- мых систем: программный код содержит очень много клише, которые приходится набирать постоянно; очень многие их появления, тем не менее, не яв- ляются штампом, имея уникальные особенности, в том или ином объеме проявляющиеся во многих частях; клише встречаются на разных уровнях: а) исполнение SQL-запроса с выводом результата в HTML-шаблон; б) сложная форма, позволяющая просматривать таблицу и редактировать ее значения; в) для отладки программы используются одни и те же HTML-шаблоны, часть из которых попадает в ко- нечные версии продукта. В первых экспериментах по внедрению метапро- граммирования в разработку было решено использо- вать параметризованные макросы, т. е. макросы, пред- ставляющие собой обычные процедуры с набором параметров. Результат оказался неудовлетворитель- ным в силу ряда причин: количество параметров макросов очень быстро росло; многие значения параметров необходимо было каскадно передавать в суб-макросы; большинство из параметров не изменялись при конкретном вызове макроса, вызывая необходимость каждый раз явно перечислять ряд значений «по умол- чанию». Таким образом, выявлено противоречие. Мы ви- дим преобладание клише в программном коде ИС, но существующие методы описания макрофункций дают неприемлемое решение. Идея для разрешения противоречия была найдена в следующей аналогии. Опытный программист, поль- зующийся стандартными средствами (например, PHP, ASP.NET, Visual C++ и др.) в определенный момент обнаруживает предел собственной производительно- сти. Единственным средством преодолеть это ограни- чение является найм новых программистов. При этом координация между ними в наиболее общей форме будет происходить следующим образом: формулируется знакомая задача. Например, сде- лать форму редактирования таблицы «user»; формулируются особенности задачи. Например, при вводе нового пользователя, перед внесением дан- ных в базу данных, необходимо генерировать случай- ное число «тикет», сохраняемое в базе данных, и вы- сылать ссылку для активации записи на введенный адрес электронной почты; если подчиненный, как правило, менее опыт- ный, программист не знает решения той или иной за- дачи, он может получить решение у наставника, за- помнив его на будущее. Следовательно, смоделировав описанное поведе- ние подчиненного программиста, можно получить систему, разрешающую сформулированное ранее про- тиворечие. Для решения этой задачи необходимо соз- дание следующих механизмов: пополняемая база знаний: данная подзадача не- специфична, известны разные способы ее решения; способ описания уточнений для клише из базы знаний, не обладающих недостатками макросов. Для иллюстрации структуры макроса (рис. 2) ис- пользован язык C++ как наиболее популярный из язы- ков, имеющих встроенную поддержку макросов. Отметим также, что экспериментальная работа проводилась с использованием модифицированной среды PHP, причины выбора которой лежат за преде- лами предмета исследования, при этом стандартная версия PHP макросы не поддерживает. Если решаемая задача сводится к выводу списка пользователей с сокрытием пароля для тех из них, у которых значение поля «rights» не равно нулю, то вы- вод списка является известным алгоритмом, описан- ным ранее как макрос db_list; указание таблицы или запроса со списком полей является ожидаемым пара- метром данного макроса; описанная манипуляция с полем пароля является непрогнозируемой в общем случае модификацией алгоритма. Свойством параметра-таблицы, равно как и набора полей, является то, что их будут использовать как ми- нимум два из четырех вызываемых макроса: db_query (для запроса из указанной таблицы), fields_output_prepare (для обработки известного набо- ра полей). В связи с расточительностью явной переда- чи параметров, требующей усилий программиста, не касающихся специфики решаемой им задачи, требуется механизм каскадной передачи параметров. Таким образом, первый постулат вводимого ме- тода состоит в наличии механизма каскадной пере- дачи параметров. Практические испытания подтвер- дили целесообразность его использования. Для срав- нения объема и сложности кода на рис. 3 приводится вариант с явной каскадной передачей параметров. Информативность в этом случае не повышается, так как передаваемые объекты в памяти человека являются «текущими» вне зависимости от того, указаны они явно в коде программ или нет. Аналогично работающая ИС может содержать множество объектов, отражающих ее текущее состоя- ние. Например, объект «Текущий пользователь» тра- диционно загружается ядром ИС и попадает в набор глобальных переменных. Но каждый ее модуль не получает явной ссылки на этот объект, а сам запраши- вает ее при необходимости проверить права доступа. Сутью же модификации алгоритма, производящей манипуляции с полем пароля, является помещение алгоритма, реализующего данную модификацию, в соответствующее место макроса без повреждения структуры последнего. В данном случае это будет инъекция кода перед вызовом макроса fields_output_prepare, так как в этом месте данные уже извлечены из базы данных, но еще не обработаны для вывода в HTML. Следовательно, мы можем привязать место инъекции к макросу fields_output_prepare, потре- бовав разместить внедряемый код перед его вызовом. #define db_list db_query; while (db_fetch_row) { fields_output_prepare; call_template_item; } Условимся считать, что пример написан на языке C++. Символы «\» в конце строк для удобства чтения опущены. Все идентификаторы являются макросами, объявленными ранее при помощи директивы «define». image Рис. 2. Текст макроса db_list #define db_list(table, field_set) db_query(table, field_set); while (db_fetch_row) { fields_output_prepare(field_set); call_template_item; } image Рис. 3. Текст макроса db_list без механизма каскадной передачи параметров Таким образом, второй постулат вводимого ме- тода состоит в уточнении алгоритмов макросов пу- тем инъекций кода, привязанных к местам, иденти- фицируемым вызовами других макросов. Экспериментальная работа. Исследуемый под- ход программирования был испытан при создании серии прикладных информационных систем. Работы проходили на базе Красноярского государственного педагогического университета имени В. П. Астафьева, а также ИТ-компании «Веб-ресурс». Для практических работ была создана динамиче- ски пополняемая среда, состоящая из следующих компонентов: стандартной среды PHP, версии 5; специально изготовленного компилятора рас- ширений PHP, реализующих синтаксис макрокоманд; библиотеки шаблонов. В целях концентрации на предмете исследования второстепенные аспекты не были реализованы в ис- пытательной среде. Так, например, описание модели данных производилось при помощи стандартного син- таксиса языка PHP (рис. 4). Расширения языка представляют собой механизм генерации кода на языке PHP (рис. 5) и синтаксис макросов с поддержкой описанного ранее метода инъ- екций кода (рис. 6). Для генерации кода было использовано стандартное свойство интерпретатора PHP - выдавать любой программный код (не только HTML) непосредственно в браузер, попутно исполняя PHP-код, находящийся в пределах тегов «<? ... ?>». Так как компилятор тоже был написан на PHP, это свойство нашло применение. На рис. 5 можно видеть код, набранный обычным шрифтом - это продуцируемый код приложения, и полужирным - это код, управляющий компиляцией. Для введения механизма уточнений (рис. 6) было сформулировано несколько принципов, которые следует рассматривать только как вариант реализации, но не как базис метода. Принципы следующие: Макросы записываются в отдельных файлах, имена которых являются именем макроса. Знак дефиса в вызове макроса соответствует разделителю каталога. Например, table-list соответст- вует файлу list.tpl в каталоге table. Вызов макроса состоит из знака «%» в начале предложения, со следующим после него именем мак- роса. Заканчивается вызов знаком «;» как обычное предложение PHP. $db_defs['customer'] => array( 'title' => 'Покупатель', 'fields' => array( 'lastname' => array('string', 'Фамилия'), 'firstname' => array('string', 'Имя'), 'middlename' => array('string', 'Отчество'), 'zip' => array('string', 'Почтовый индекс', 'db_type' => 'CHAR(6)'), 'city' => array('link', 'Город', 'link_to' => 'city' ), 'address' => array('string', 'Почтовый адрес'), 'phone' => array('phone', 'Телефон'), 'email' => array('email', 'Адрес эл. почты') ); image image Рис. 4. Описание структуры данных сущности «Покупатель» средствами PHP if (!isset($cms_Transfer)) { <? if (get_param('form_enable_return_url')) { ?> $cms_Transfer['return_url'] = htmlspecialchars(@strval($_GET['url'])); <? } ?> $cms_Transfer['message'] = ''; } Рис. 5. Генерация кода при помощи встроенных средств PHP %login-session login-body>login-logout>run_after = { // Гостевой вход $GLOBALS['cmsLoginExt'] = array('login' => 'Гость', 'id' = > 0); $GLOBALS['cmsLogin'] = $GLOBALS['cmsLoginExt']['login']; }, login-is_user>replace = { return cmsLoginID() != 0; }; image Рис. 6. Вызов макроса с двумя уточнениями Вызываемый макрос может иметь произвольное число параметров, указываемых между именем мак- роса и знаком «%» в виде пар «имя параметра = зна- чение параметра». Имя параметра является алфавитно-цифровым идентификатором. Оно может содержать несколько префиксов, являющихся именами макросов и отде- ленных знаком «>». Каждый префикс обозначает зону действия параметра и последующей цепочки префик- сов. Например, «table-list>db-list>query» означает ус- тановку параметра query в пределах вызова макроса «db-list», но только в случае обращения к нему в пре- делах вызова макроса «table-list». Значение параметра может быть числом, стро- кой или одной из констант «false», «true», «null» в со- ответствии с синтаксисом PHP, а также блоком кода, заключенным в фигурные скобки (рис. 6). Параметры «run_before» - инъекция кода в нача- ле работы макроса, «run_after» - инъекция кода в кон- це работы макроса и «replace» - замещение кода мак- роса интерпретируется единовременно. Остальные параметры являются каскадными и сохраняют свои значения при вызове суб-макросов. Для получения доступа к значению параметра используется PHP-функция «get_param», вызываемая в управляющем PHP-коде (рис. 5). Предварительные результаты нами оцениваются как успешные. Отметим, что в настоящий момент мы не располагаем достаточным количеством разрабо- танных проектов, чтобы произвести полную всеобъ- емлющую оценку технологии, но по доступным на сегодня приводимым ниже оценкам продолжитель- ность разработки проекта сокращается от 4 до 8 раз. В некоторых вырожденных случаях, когда информа- ционная система целиком сводится к имеющимся шаблонам, сокращение времени разработки может достигать и десятков раз. Разработка модуля риэлтерской базы для «time-is- money CMS» заняла 4 рабочих часа, ранее подобная работа, произведенная тем же программистом, потре- бовала около 20 рабочих часов. Разработка модуля управления пользователями для «time-is-money CMS» первоначально заняла около 4 ч. Повторение этой задачи по новой технологии потре- бовало чуть менее 10 мин. Прирост производительно- сти составил 24 раза. В этом случае задача была вы- рождена до шаблона «table-edit». Тем не менее, этот случай является крайним, так как реальные задачи обычно требуют дополнительных функций и особой проработки внешнего вида. По описываемой методике создана проективная система «Тестосфера». На примере ее модулей можно проследить изменение объема кода. Модуль «tasks», по своему назначению типичный для ИС - это 139 строк (без учета пустых и незначащих) исходного кода модуля, против 800 строк PHP-кода, полученных в результате генерации и соответствующих прямому набору, и 214 строк в типовых HTML-шаблонах. Мо- дуль «test» специфичен для тестовой оболочки - 153 строки описаний против 248 строк полученного PHP-кода и 98 строк HTML-кода. Интересно отметить, что 139 строк первого модуля практически не требовали отладки, так как являются рутинным описанием требуемой функциональности с опорой на уже отлаженные шаблоны. Этим фактором объясняются и большие различия в объемах исходно- го и результирующего кода. В то же время 153 строки второго модуля потребовали длительной и кропотливой работы, так как они представляют собой уникальный код и слабо используют преимущества технологии. Другой проект, полностью созданный по описываемой технологии, - это система дистанционного образования Заочной естественно-научной школы (сегодня http://zensh.pk-studio.ru/). Функциональность уровня технического задания была в этом случае соз- дана за 2 недели. Как и в случае с «Тестосферой», ос- новное время ушло на разработку тестирующей части, алгоритмы которой не имели аналогов в ранее созда- вавшихся ИС. Таким образом, в работе представлен эффективный подход к разработке ИС с Веб-интерфейсом на основе концепции метапрограммирования. Показано, что в настоящее время наиболее разумными являются ИС проективного типа (разработка и развитие системы происходит непрерывно и эволюционно), а их созда- ние на основе предложенного подхода является эф- фективным с точки зрения производительности труда программиста.