Бурное развитие средств разработки приложений, связанных с базами данных, а также средств доступа к базам данных и, соответственно, интерфейсов породило проблему модернизации ранее спроектированных систем, либо перевода действующих проектов на новые платформы, инструменты и даже методологии.
Рассмотрим несколько конкретных примеров.
Пример перехода на CASE- и объектные средства. Проект офисной системы
"Офисная система", как это часто бывает, не совсем офисная система. Но название уже настолько приросло, что сменить его невозможно. Итак, она создавалась как система автоматизации учета торговых операций для некоего конкретного офиса (выписка счетов и торговых предложений, ведение прайс-листа, формирование заказов, контроль поступления и выдачи товара со склада и т.п.) и как основа для выполнения заказных работ "на ту же тему". При этом она, естественно, использовалась как полигон для опробирования различных средств разработки и других технологических решений.
Дело в том, что торговая система для даже не очень крупной фирмы требует разработки и применения принципиально различных интерфейсов. Здесь необходимы:
· рабочие места менеджеров, позволяющие сформировать сложный запрос вроде "когда больше продаж солидного продукта - после дождичка в четверг или перед похолоданием во вторник" и представить результаты в виде красивой диаграммы для начальника;
· рабочие места продавцов "штучного" товара, составляющих в режиме WYSIWYG счет на покупку;
· рабочие места сотрудников, занимающихся вводом больших объемов однотипной информации о потенциальных покупателях и поставщиках, изменениях в своих и чужих прайслистах, полученных и отправленных платежах и много о чем еще.
· список может быть значительно длиннее.
Если для первой группы желательно использовать рабочие места под Windows с доступом к уже привычным для пользователей наборам инструментов из Microsoft Office, для вторых годятся различные графические рабочие места как под Windows, так и под Unix, то для третьих наиболее разумным (хотя и не самым популярным) является использование алфавитно-цифровых терминалов, наиболее дешевых, надежных и безопасных для здоровья.
Соответственно, для различных рабочих мест целесообразно использование различных средств разработки.
Если для алфавитно-цифровых терминалов это безусловно Informix-4GL*), то для графических рабочих мест выбор весьма велик. Здесь и собственная разработка Informix NewEra, и ориентированный на Informix HyperScript, сочетающий черты языка высокого уровня и электронных таблиц, и популярные в России PowerBuilder и Delphi, и еще не получившая признания SuperNOVA.
Таким образом, реализация офисной системы требует использования целого спектра средств разработки. Это, естественно, затрудняет как просто общение между отдельными участниками проекта (каждая группа разработчиков говорит, в какой-то степени, на своем языке), так и применение один раз написанного кода для реализации бизнес-правил. Решение проблемы: дальнейшее увеличение числа средств разработки с их специализацией и привлечением средств автоматизации процесса проектирования и реализации.
В качестве дополнительных механизмов разработки выступили хранимые процедуры и триггеры, реализуемые непосредственно на сервере базы данных и доступные из всех приложений.
Они могут выполнять широкий круг весьма разнообразных задач. В частности, в офисном проекте на них была возложена задача репликации. Точнее, было принято решение вести параллельно две базы - оперативную и архивную. Пользователь, как правило, работает с оперативной информацией, например, о товарах, которые выписаны, заказаны, но еще не выданы покупателю. И только если ему понадобилось узнать, а что было в этот же день, но пять лет тому назад, он обращается к архивной базе. Вся информация, вносимая в оперативную базу или модифицируемая в ней, автоматически копируется в архивную. Информация, удаляемая из оперативной базы, в архивной сохраняется. Для этого не требуется никаких дополнительных усилий не только от пользователя программы, но и от самих интерфейсных программ, на чем бы они не разрабатывались.
Все необходимые действия выполняются с помощью соответствующих триггеров и хранимых процедур. Такое техническое решение позволяет, на наш взгляд, избежать длительного поиска при работе с оперативной информацией, которая составляет для систем этого назначения основную нагрузку. Вместе с тем при необходимости получить справку по архивной информации, не нужно ее предварительно разархивировать и удалять после использования, как это иногда делается. Достаточно выполнить один SQL-оператор, переключающий пользователя на работу с другой базой.
При другом решении задачи репликации потребовалось бы при всех записях в оперативную базу данных вставлять и выполнение соответствующих действий с архивной базой. Учитывая, что работа с одной и той же таблицей может осуществляться из различных приложений, в том числе написанных с использованием различных средств разработки, это потребовало бы существенного увеличения объема кода, а также привело бы к двойному увеличению загрузи сети.
Другая задача, решаемая с помощью этих средств это - контроль авторизации записей. Учитывая важность информации, хранящейся в офисной базе, необходимо хранение в каждой записи в таблицах базы данных сведений о том, кто и когда внес или изменил данную запись. Поскольку эта задача решается с использованием триггеров, даже наиболее опытные пользователи не могут обойти контроль даже при применении собственных программ или средств прямого доступа к базе типа dbaccess.
Еще одна задача, традиционно возлагаемая на сервер базы данных, это поддержание ссылочной целостности базы данных.
Как легко заметить, для решения перечисленных задач необходимо написание большого числа однотипных хранимых процедур и триггеров. Задача эта весьма ответственная и при этом требующая внимания и тщательности. К сожалению, Informix не предлагает собственных средств повышения эффективности разработки хранимых процедур и триггеров. Продукты большинства других фирм, например ERwin, позволяют быстро собрать один триггер, но не сто однотипных.
Не менее сложная задача возникает и при написании интерфейса на Informix-4GL. Дело в том, что "привлекательные и удобные современные пользовательские интерфейсы на языке 4GL" также требуют весьма объемной и кропотливой работы, причем едва ли не большая часть времени уходит при этом на согласование отдельных фрагментов интерфейса, написанных различными программистами или даже одним программистом в разное время.
Для решения подобных проблем существует средство автоматизации разработок Vantage Team Builder for Informix, выпускаемой фирмой Cayenne.
VantageTeam Builder это - Case-система, базирующаяся на методологии Йордона. Существуют и другие методологии, как для структурного подхода, так и связанные, например, с объектно-ориентированным подходом или с проектированием систем реального времени. Естественно, другая методологическая основа вносит свои коррективы в особенности разработки модели проектируемой системы и определяет возможный конечный код реализации системы. Структурный подход в этом смысле является наиболее общим, так как не накладывает специальных требований на язык реализации, который может быть любым, включая стандартные языки программирования (C, COBOL, Pascal, FORTRAN) с библиотеками доступа к базе данных, SQL и языки четвертого поколения (4GL) для разработки приложений для баз данных.
VantageTeam Builder включает в себя средства ведения проекта произвольной сложности. Он позволяет:
· осуществлять анализ задачи с использованием таких графических средств, как диаграммы потоков данных и диаграммы структуры данных;
· проектировать аппаратный комплекс с использованием диаграмм архитектуры системы;
· проектировать пользовательский интерфейс с помощью диаграмм последовательности и содержания экранных форм;
· проектировать базу данных с использованием диаграмм отношений сущностей;
· проектировать отдельные программы с помощью соответствующих структурных схем;
· автоматически генерировать на основе перечисленных диаграмм SQL-скрипт для создания таблиц и хранимых процедур базы данных, код программ на Informix-4GL, экранные формы и техническую документацию по проекту.
Но что является его наибольшим преимуществом перед некоторыми другими CASE-средствами аналогичного класса - это практически полная открытость и настраиваемость в широком диапазоне задач.
VantageTeam Builder дает возможность пользователю создавать собственные шаблоны для генерации, причем для их настройки могут применяться дополнительные атрибуты. Например, при создании офисного проекта разработаны шаблоны для генерации Informix-4GL, использующие ряд дополнительных параметров, среди которых альтернативный предметный ключ. Также созданы шаблоны для генерации триггеров, обеспечивающих репликацию базы данных.
В результате программа на Informix-4GL, предназначенная для работы практически со всеми таблицами базы данных, была сгенерирована автоматически и доработана вручную (от 5 до 20 процентов кода, в зависимости от сложности конкретной экранной формы) примерно за то же время, что и написана вручную программа на HyperScript, предназначенная для формирования и выписки счетов и коммерческих предложений.
Естественно, хочется получить такое же ускорение разработки при использовании графических средств, в первую очередь NewEra и SuperNOVA. Такое ускорение позволило бы, в частности, разработать подобную систему на заказ под графический интерфейс, а не только под алфавитно-цифровой, за приемлемое время.
Поскольку и NewEra и SuperNOVA - объектно-ориентированные языки, для них, вообще говоря, существует специальный CASE той же фирмы Cayenne VantageTeam OO Builder. Но Informix - реляционная СУБД, и применение объектно-ориентированных методов разработки проекта для него не всегда оправдано (хотя интерфейсу почему бы и не быть построенным с помощью объектно-ориентированных средств).
Именно для таких ситуаций предназначаются специально разработанные кодогенераторы Grindery для NewEra и SuperNOVA. Причем использование объектно-ориентированных средств разработки интерфейса позволяет несколько упростить задачу кодогенерации, поскольку код, который необходимо сгенерировать для Informix-4GL, теперь можно в значительной мере просто включить в соответствующую библиотеку классов (NewEra) или темплейты (SuperNOVA).
CASE-средства становятся эффективны и весьма эффективны только при их комплексном применении на всех стадиях жизненного цикла информационной системы. Этот факт является, одновременно, и важнейшим критерием "хорошего" CASE-средства - CASE-средство должно предлагать интегрированный, равно эффективный на всех стадиях жизненного цикла информационной системы инструментарий разработки и сопровождения проекта.
Можно использовать CASE-средства локально в жизненном цикле разработки ИС, но эффективность применения именно этого инструментария при этом становится неочевидна в силу необходимости состыковки различных технологий разработки. В отсутствии комплексного применения (как в силу традиций разработки, так и в силу недоступности реальных интегрированных CASE-средств) и заключается ответ на вопрос, почему CASE-средства до сих пор не получили широкого распространения среди отечественных разработчиков.
Нельзя не упомянуть о появляющейся совершенно уникальной возможности поставлять коммерческое приложение заказчику как открытую систему.
Если заказчик сам владеет CASE-технологией, включая наличие специалистов с квалификацией аналитик-предметник, он имеет полную возможность самостоятельно сопровождать и развивать проект, оперативно реагируя на потребности предметной области, интегрируя в проект собственные решения, несущие, например, закрытую фирменную информацию или заключающиеся в подключении продуктов третьих фирм. Если такой специалист заказчика подключается к группе разработчиков хотя бы на третьей стадии разработки, он становиться носителем не только всей суммы знаний о проекте, содержащейся в базе данных проекта, но и соответствующего опыта разработки.
Совершенно очевидно, что такой подход принципиально отличается от поставки приложения с исходными текстами, совершенно справедливо воспринимаемыми скептиками не как "кладезь мудрых решений", а как "кладезь ошибок".
Пример расширения и смешивания интерфейсов готовой системы. CGI-приложение в информационной системе FLORIN
Постановка задачи
Информационная система FLORIN предназначена для работы с разнообразными данными о растениях, включая названия (научные, обиходные, торговые) и систематику, коллекции, сведения о географическом распространении, полезных свойствах, выращивании и коммерческом использовании и т.д. FLORIN существует как в персональной (для научных работников, коллекционеров и т.д.), так и в многопользовательской (для гербариев, ботанических садов, питомников и т.д.) версиях.
Портируемость и масштабируемость FLORIN обеспечивается применением средств разработки и серверов БД Informix Software.
Система реализована как набор относительно независимых приложений, с возможностью создания оптимальной для конкретного заказчика конфигурации, в том числе в гетерогенной среде.
Изначально, интерфейс пользователя для ввода, просмотра информации и генерации текстовых отчетов реализован на Informix-4GL, что позволяет, в частности, в многопользовательской версии под Unix обеспечивать доступа к БД через telnet.
В то же время одним из модулей FLORIN поддерживается определенный набор функций GIS, для работы с географическими данными.
Большая часть информации, с которой работает FLORIN, представляет собой данные коллективного пользования, прежде всего в разного рода справочных системах, содержащих информацию о названиях и свойствах растений, а также каталогах и БД, где хранятся данные о коллекциях растений.
С широким распространением Internet среди действующих и потенциальных пользователей FLORIN открылись совершенно новые возможности для обмена данными и появилась необходимость обеспечить доступ пользователей к БД FLORIN из WWW.
Особенностью ботанической информации коллективного пользования является, с одной стороны, относительно узкий круг ее создателей (как правило, БД создаются и поддерживаются небольшими коллективами специалистов), с другой стороны, часто очень широкий круг ее потребителей (включая как специалистов, так и любителей).
Другой важной особенностью, которую необходимо было учитывать при постановке задачи на разработку приложения для WWW, является очень сложная порой структура информации, что влечет за собой необходимость поддержки весьма непростого, с точки зрения программиста, пользовательского интерфейса.
По перечисленным двум причинам оказалась неприемлемой идея реализации пользовательского интерфейса ввода/редактирования данных в версии для WWW. При необходимости предоставить подобные возможности удаленным пользователям, достаточно доступа к "обычному" рабочему месту пользователя через telnet.
Использовать же browser для просмотра хранящейся в БД информации оказывается очень выгодно, поскольку не требуется реализация всех деталей пользовательского интерфейса. Поэтому во FLORIN предусмотрена работа только "просмотровых" CGI-модулей для всех основных приложений, входящих в состав системы.
В настоящий момент уже почти полностью реализован работающий через CGI browser для FLORIN Taxonomy. Это приложение FLORIN работает с информацией о названиях растений, синонимике, а также разнообразными связанными с названиями данными. Аналогичные модули запланированы для просмотра информации о коллекциях, географическом распространении (включая генерацию карт) и др.
Средства разработки
В качестве средства разработки был выбран C++, с использованием INFORMIX-ESQL/C для доступа к серверу БД и соответствующей библиотеки Informix Software для реализации функций ввода/вывода по стандарту CGI. Дополнительно была реализована библиотека классов, обеспечивающая интерфейс для управления HTML-объектами, управление параметрами сессии при последовательных вызовах CGI-скрипта, управление полями данных HTML-форм (установление default-значений, сохранение значения поля в течение сессии и т.п.) и некоторые другие возможности.
Интересно, что информация в базе данных хранится в единой кодировке. Перевод кириллицы из внутренней кодировки БД в указанную пользователем кодировку CGI-скрипт осуществляет "на лету", используя специально разработанные библиотеки.
Многие из реализованных для CGI-приложения классов используются также при разработке новой версии FLORIN с графическим пользовательским интерфейсом. В частности, применение INFORMIX-ESQL/C обеспечивает единый интерфейс с сервером БД и для CGI-приложения, и для "обычного" клиентского приложения, работающего в режиме on-line.
Как это выглядит
CGI-скрипт может быть запущен или выбором соответствующей ссылки в HTML-документе или из HTML-формы, c передачей параметров сессии (названия БД, к которой нужно обращаться, имени пользователя, кодировки кириллицы и т.д.). При первом запуске CGI-скрипт предоставляет пользователю шаблон запроса (HTML-форма), где должны быть указаны критерии поиска, для передачи которых скрипту опять-таки используется метод GET. Во всех последующих формах применяется метод POST.
При необходимости пользователь может получить дополнительные поля для ввода критериев, указав необходимый их набор в конфигурации. Запрос может быть сделан практически по любому из имеющихся в БД полей, видимых для пользователя, при этом есть возможность соединения групп полей логическими условиями И/ИЛИ.
В результате запрос может быть достаточно сложным по логике и строиться на нескольких десятках таблиц.
Получив критерии поиска, CGI-скрипт конструирует по ним SQL-выражение(я), обращается к серверу БД и ждет от него ответа. По результатам запроса CGI-скрипт создает HTML-документ, пересылаемый клиенту. Пользователь получает очередную HTML-форму, содержащую список объектов, удовлетворяющих критериям поиска, набор кнопок, обеспечивающих выполнение определенных действий над отмеченными в списке объектами, а также конфигурацию отчета. Размер списка неограничен, так же, как и количество объектов, которые в нем можно выбрать. Для последних пользователь может получить список объектов нижележащего иерархического уровня (БД названий растений имеет в своей основе иерархическую структуру) или различные варианты отчетов, в соответствии с указанной конфигурацией.
При следующем вызове скрипта определяется тип документа, который необходимо сконструировать (очередной список или отчет, в указанной конфигурации), и условия поиска (отмеченные в списке позиции). Последних может быть очень много, а отчет может включать данные из десятка таблиц. Как оказалось, время, потребное на создание отчета для HTML-клиента, практически не превышает такового для клиента on-line. Однако дополнительная задержка может возникать при пересылке большого отчета HTML-клиенту по сети, поскольку CGI-скрипт способен сконструировать отчет объемом в несколько сотен килобайт примерно за минуту, за счет высокой производительности INFORMIX-OnLine и самого скрипта. Но проблема передачи отчетов большого объема легко решается разбиением их на страницы.
В настоящее время готовится версия CGI-скрипта, которая, в дополнение к вышеописанным возможностям, будет предоставлять пользователю некоторые дополнительные типы отчетов, а также поддерживать возможность включения в отчет (либо в виде HTML-ссылок, либо непосредственно, по выбору пользователя) изображений, связанных с названиями растений и хранящихся в виде больших бинарных объектов (blobs) в БД INFORMIX. Одновременно идет работа по созданию аналогичных CGI-скриптов для других приложений, входящих в состав FLORIN.
Что мы получили
С появлением CGI-скриптов, обеспечивающих просмотр информации, хранящейся во FLORIN, мы смогли, при минимуме затрат, обеспечить возможность "автоматической" публикации БД в Internet. Достаточно только установить на Web-сервер необходимый набор дополнительных модулей, и БД становится видна всем пользователям Internet, либо только зарегистрированным пользователям, если это необходимо. Все изменения, вносимые пользователями через "обычные" модули FLORIN, моментально становятся доступны для всех пользователей сети, имеющих доступ к соответствующей БД.
Возможен и другой вариант. БД, поддерживаемая персональной версией FLORIN, может периодически копироваться на любой сервер, где установлена версия FLORIN for Unix. В этом случае информационная система используется для публикации данных, в то время как вся работа с ними ведется на PC.
Итак, появление современных средств разработки и расширенных интерфейсов прикладных программ (типа CGI, HTML) потребовало пересмотра подходов к проектированию крупных информационных систем. В этой ситуации оказалось оправданным применение серьезных открытых CASE-средств, позволяющих к тому же смешивать структурные методы проектирования с объектно-ориентированными средствами реализации. Кроме того, "правильно" спроектированные системы могут быть расширены за счет организации интерфейсов к таким мощным средствам просмотра и поиска, как WWW.
Интересно, что произвести тотальный переход на однотипный интерфейс часто является неэффективным либо слишком дорогим. В приведенных выше примерах иллюстрируется возможность интеграции средств проектирования, разработки и СУБД разных производителей.
Сергей Синягов,
DataX/FLORIN, тел.: 158-95-20
*) При ориентации на продукты Informix Software. Некоторые дальнейшие рассуждения автора также основаны на этом допущении. - Прим. ред.