Контакты
Адрес:129110, г. Москва, ул. Гиляровского, дом 57, строение 4
Телефон:+7 (916) 0-362-362

Технологии

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРИКЛАДНЫХ ПРОГРАММНЫХ СИСТЕМ

В настоящем разделе нашего сайта приведен краткий обзор технологии Генератора Проектов, а также аннотация Языка описания проектов «Эзоп». Разумеется, размещенные здесь материалы не претендуют на полноту и не могут использоваться специалистами для практического применения в разработке программных комплексов. Эта информация приведена лишь для первичного знакомства с нашими технологиями.

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

ГЕНЕРАТОР ПРОЕКТОВ

Генератор Проектов предназначен для автоматизации разработки программных комплексов со следующими характеристиками:
1. Оконный интерфейс пользовательского приложения (окна, диалоги);
2. Использование различных реляционных СУБД;
3. Архитектура "Клиент-сервер";
4. Использование динамических интернет-сайтов для доступа к центральной базе данных (ЦБД);
5. Наличие встроенной подсистемы безопасности для целей защиты данных (ЦБД и информационных потоков) от несанкционированного чтения и искажения.

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

МОТИВАЦИЯ РАЗРАБОТКИ ГЕНЕРАТОРА И НЕМНОГО ИСТОРИИ

Генератор Проектов был разработан и впервые применен в реальных проектах в начале девяностых годов (см. раздел сайта "Проекты"). Команде разработчиков тогда пришлось реализовывать несколько больших проектов в банковской области, в которых был использован архитектурный принцип "клиент-сервер". Эта архитектура предполагала реализацию определенного протокола отправки запросов от клиентских приложений на сервер и получения ответов. В пользовательских клиентских модулях предусматривалось изображение экранных форм с отдельными полями ввода/редактирования и таблицами для просмотра. Был разработан инструментарий для визуализации таких форм и интерфейс работы с формами из программы. Для программирования сервера был использован препроцессор для обработки встроенных в Си-программы SQL-выражений. Для программирования протокола также был разработан инструментарий для клиентской и серверной стороны. Сервер разрабатывался для платформы VAX/VMS с использование СУБД RdbVMS. Клиентские программы разрабатывались для использования в средах MS DOS и VAX/VMS.

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

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

В дальнейшем, в течение вот уже более чем десяти лет подавляющее большинство проектов наш коллектив разрабатывал с использованием Генератора Проектов, который развивался и усложнялся от проекта к проекту. Кстати, данный сайт также разработан и сопровождается с помощью Генератора Проектов. Этот подход позволил в свое время с минимальными усилиями перенести множество программных комплексов с MS DOS на MS Windows 3.11 в части клиентских модулей, с сетевого протокола DECNET на TCP/IP, с VAX/VMS на Windows NT 3.51 в части реализации сервера, с RDB/VMS на MS SQL Server в части используемой СУБД, далее с сервера под Windows NT 3.51 на ALPHA/AXP под OSF (DecUnix) с использованием СУБД Oracle и т.д. и т.п. Менять пришлось, в основном, генератор. При этом, во многих случаях такие переводы осуществлялись для прикладных систем на этапе промышленной эксплуатации.

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

При рассмотрении технологии разработки ППО с помощью Генератора Проектов уместна следующая строительная аналогия. Разработка программ на традиционных языках с использованием известных библиотек напоминает строительство зданий. Обилие инструментальных средств - различные оконные интерфейсы (MFC, Delphi, Gtk), и прочие полезные библиотеки и программы - напоминает магазин стройматериалов с огромным ассортиментом. Многообразие различных материалов и приспособлений наряду с их доступностью вовсе не гарантирует успешность и быстроту постройки здания. Для этого необходимы, во-первых, навыки проектировщика и строителя, а, во-вторых - время. Использование Генератора Проектов в этой аналогии можно сравнить с домостроительным комбинатом, производящим типовые панели, блоки и прочие типовые компоненты, из которых по типовым проектам различных серий можно строить дома с большой скоростью. Вряд ли можно таким образом возвести храм Василия Блаженного или Кельнский собор. Но добротный микрорайон с развитой инфраструктурой вполне возможно и очень быстро.

История разработки Генератора Проектов характеризуется постоянным добавлением все новых и новых возможностей в модель проекта программного комплекса. Так были освоены новые типы СУБД (Sybase, Postgress, Mysql), новые платформы (Linux), новые сущности (Интернет-серверы, структурированные документы). Некоторые средства отмирали по разным причинам - VAX/VMS, протокол DECNet по причине отсутствия реальных проектов для этих платформ. Некоторые средства отмирали не потому, что они устарели, а потому, что они не используются в текущих проектах. Это означает, что они легко могут быть реализованы (восстановлены) при возникшей необходимости.

ЭТАПЫ РАЗРАБОТКИ ПРОГРАММНЫХ КОМПЛЕКСОВ

При разработке любого программного комплекса достаточной сложности прослеживаются четыре основных фазы его развития:
1) постановка задачи,
2) формализация математических моделей и методов решения этих задач,
3) программирование и, наконец,
4) сборка и получение дистрибутивов.

Постановка задачи, техническое задание являются результатом совместной работы заказчика и разработчика.

Вторая фаза, которая является собственно созданием формального проекта разрабатываемого комплекса - это результат работы аналитиков. Аналитик изучает поставленную задачу, формализует ее и предлагает методы решения. Разработка проекта на основе постановки задачи (1->2) - процесс в значительной степени творческий. Здесь чрезвычайно важен опыт аналитика и его общематематическая подготовка, а также знакомство с современными информационными технологиями. Этот процесс по своей сути неформальный и вряд ли будет автоматизирован в обозримое время.

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

Получение дистрибутива из текстов программ (3->4) - это техническая задача, решаемая использованием компиляторов и прочих вспомогательных инструментальных программ.

Основное назначение генератора, это автоматизация этапа 2->3, т.е. автоматизация процесса создания исходных текстов программ на основе описания проекта. Для этого был разработан специальный язык описания проектов, ориентированный на аналитика. Этот язык является тем формализмом, который позволяет осуществить переход 2->3 автоматически.