Основное назначение - скоростное внедрение приложения.
Традиционый способ (систем класса ERP) требует проводить подготовку и планирование всего пакета требований к приложению целиком.
Причина - архитектура системы устроена "монолитным" способом и не позволяет проводить изменения в короткие сроки и с сохранением ее стабильности.
RAD платформа спроектирована специально для сохранения "живучести" как приложения, так и накопленных в базе данных - в условиях непрерывного изменения
структуры и функциональности приложения. Эта особенность позволяет использовать скоростную эволюционную технологию,
получая в кратчайшие сроки полностью работающий прототип, который в процессе работы позволяет осмысленно и по шагам сформулировать Заказчику следующий пакет требований к расширению функциональности приложения.
После каждого такого изменения не требуется процедура остановки пользователей и конвертация базы данных, эту операцию платформа производит автоматически.
За счет чего достигаются эти возможности ?
В платформе использованы архитектурные и научные решения, которые позволяют строить приложения методологически "правильно", т.е. при развитии задачи избежать проблем и конфликтов,
возникающих по причине НЕИСПОЛЬЗОВАНИЯ в проекте (платформе) фундаментальных системных решений.
Во многих современных коммерческих IT-продуктах на такие системные решения тратить ресурсы не считается рентабельным - важен сиюминутный успех.
Например, системный реестр распространенной операционной системы на этапе создания первых ее версий был спроектирован "без затей" - как простой текстовый файл с разделителями - не БД и даже не таблица.
В результате, большое количество ресурсов системы тратится на эмуляцию технологии БД внутри огромного текстового файла, а заменить механизм уже поздно - с ним связана поддержка внешних продуктов и стандартов.
В качестве другого важного примера можно указать на практику применения т.н. "первичных ключей".
Их теории баз данных известно, что каждая запись (и любой объект) должен обладать от рождения "паспортом" - уникальным идентификатором - id.
Изначальное отсутствие такого id при усложении задачи (переходе данных в оффлайн и возврате их в центральную БД, интеграции, и пр.) вызывает фактический паралич проекта или невозможность его развития - т.к. данные и объекты невозможно сопоставлять и восстанавливать связи.
Фундаментальная наука для БД гласит, что первичный ключ должен "рождаться" вместе с новой записью (объектом), причем этот механизм должен быть невидим разработчику (внутрисистемный).
На практике, даже в БД Oracle первичные ключи отданы на откуп разработчику - это либо сцепка (конкатенация) значений нескольких полей
плюс проверка на уникальность посредством unique index,
либо первичного ключа как такового вообще нет (разработчик/консультант "не обременен" знанием о его необходимости).
Де факто вместо них (и в Oracle) используются простые автоинкрементные поля (число-счетчик в блокируемой таблице),
про уникальность и ведение реплик БД в оффлайне в этом случае серьезно говорить уже не приходится.
Для платформы DBRAD32 был разработан и протестирован зарегистрированный алгоритм генерации истинно глобальных уникальных идентификаторов GUID.
Аннотация
Настоящий проект системы реализует законченный цикл скоростной разработки приложений в условиях меняющихся структур данных. Первой задачей при автоматизации низового процесса является получение СРАЗУ работающего приложения, в которое загружены данные для обработки (сразу доступны функции: 1)работы с записями, 2)получения отчетов). Завершенная и отлаженная реализация данной идеи (постановка задачи) была получена средствами СУБД MS VFP Visual Studio. Отладка технологии заняла более 8 лет, в течении которых разными группами разработчиков было внедрено несколько сотен задач в различных областях (начиная с платежки, заканчивая системами для фондовой биржи и банка). Мощным инструментом система становится при решении задач обработки имеющихся данных (линейных информационных систем – выборки, замены, пересчеты, отчеты), пилотные варианты которых можно построить в течение несколько часов.
Платформа DBRAD32 состоит из Конструктора разработки приложения и Базового Исполняющего Ядра приложения. Архитектура и идеология платформы в основном сходна с модульными системами SAP R/3. Axapta, 1C. С помощью Конструктора Приложений создается Структура приложения (словарь данных), в которое входит описание таблиц (их полей) и экранные формы. Приложение получается путем соединения этой Структуры и неизменного Базового Ядра (EXE-файла). Шаблоны отчетов настраиваются непосредственно в приложении совместно с пользователем, работа с генератором отчетов проста и доступная пользователю. В качестве внутреннего метаязыка программирования используется язык VFP. Для обмена данными с внешними системами могут использоваться форматы файлов XLS (Excel v5.0), CSV, DBF.
Основное различие между "тяжелыми" системами класса SAP R/3 и DBRAD32 состоит в том, что DBRAD32 относится к развитой клиентской части и предназначено для скоростного построения и сопровождения низкоуровневых «легких» приложений frontend, которые решают проблему стоимости лицензий для «легких» рабочих мест и адаптации их упрощенной функциональности для конкретного случая, отличного от базовой бизнес логики модуля "тяжелой" системы.
Для изменения структуры приложения системы "тяжелого" класса требуется значительное время и привлечение дорогих консультантов, после чего необходима операция конвертации старой БД. Модификация структуры приложения DBRAD32 проводится "на лету". Понятие "легкости" системы буквально выражается и в том, что Ядро DBRAD32 имеет размер чуть более 2МБ (RunTime библиотека ок. 5мб). Развитая структура приложения также не превышает 1МБ, что позволяет свободно рассылать обновления структур по пользователям.
Важным качеством платформы является то, что после изменения структуры приложений (таблиц, форм) не требуется операция конвертации данных БД из старого формата в новый. Такое преобразование БД пользователя после получения новой версии структуры из Центра происходит автоматически и незаметно для пользователя.
Специальный режим Ядра позволяет при каждом пуске пользовательского приложения проверить по назначенному сетевому пути появление обновленной версии структуры или Ядра и при его обнаружении автоматически скопировать их на место пользователя и затем уже запустить ядро(модуль NetStart). Этот режим избавляет от необходимости вручную тиражировать изменения по рабочим местам.
Главным полезным качеством является возможность вести в Центре Разработке оперативное создание и коррекцию структуры приложений (таблиц и экранных форм) и сопровождение последующих версий. Понятие оперативности является ключевым для данной системы и реализуется в технологии RAD (Rapid Application Development).
Эти качества в сочетании с возможностями отлаженного Базового Ядра реализуют оперативный и эффективный механизм поддержки распределенных приложений в условиях непрерывно изменяющихся структур данных и форм представления.
Наиболее типичной задачей является перекачка данных из старых приложений в приложение DBRAD32 и использование его в качестве инструмента для обработки этих данных (правка, унификация, массовые пересчеты). Этот режим эффективно решает проблемы инструментальной обработки и подготовки Нормативно-Справочной Информации (НСИ) с целью ее дальнейшей загрузки в хранилище данных. Встроенный компактный генератор отчетов позволяет легко без программирования настроить любые отчеты прямо в MS Word (сложные справки, аналитические, сводные). В качестве шаблонов отчетов можно использовать имеющиеся документы MS Word, в которые вставляются макровызовы значений полей и функций.
Другой актуальной корпоративной задачей является ведение централизованной БД и разобщенных по филиалам приложений. Ввод первичных данных происходит в филиалах, которые по регламенту сбрасывают порции данных в центральную БД. После анализа в Центре порции данных могут отсоединяться и направляться обратно в филиалы для корректировки. Подобный цикл обмена данными между изолированными (offline, без online связи) системами реализует модель Разобщенной БД. Задача авторизация записей, принадлежащих разным филиалам, решена на основе встроенных уникальных идентификаторов записей (т.н. GUID – истинных первичных ключей). Ключи GUID в компактном виде содержат дату и время создания и код компьютера.
При использовании Базового Ядра без какой-либо структуры приложения оно переходит в режим Универсального Навигатора внешних DBF-файлов и Генератора Отчетов. В этом режиме происходит автоматическая перекачка данных из внешних dbf-файлов в систему, которые открываются в режиме Универсального GRID для аналитической обработки, правки и создания аналитических отчетов и документов MS Word.
Первый уровень автоматизации (наиболее высокий) обеспечивается возможностями Базового Ядра (системной оболочки), построителем структуры, генератором отчетов и полнофункциональным классом работы с таблицами (табличным интерфейсом eEgrid), обеспечивающим основной набор манипуляций с записями таблицы:
Гибкая модель автоматизации реляционных механизмов и блокировок получена за счет применения компактных первичных ключей идентификаторов GUID, что позволило большинство механизмов автоматизировать и спрятать от разработчика и пользователя. Следующий нижний уровень реализуется набором visual--объектов и функциями разработчика, позволяющими более гибко построить модель задачи вручную. Самый нижний уровень реализуется средствами языка СУБД.
Подробное описание (opis.zip) функций универсального ядра UAE здесь
(обновление от 10.01.2011)
Run-Time библиотека поддержки клиентских приложений DBRAD32 (VFP 8.0)
На каждый ПК, где будет запускаться приложение DBRAD32, надо установить библиотеку поддержки. Файл скачать, распаковать и затем запустить disk1\setup.exe.
Исполняемое Ядро DBRAD32 под версию 8.0
При создании своих приложений на платформе DBRAD32 в каждом из этих приложений будет одно и то же исполняемое Ядро - EXE-файл (dbrad32.exe) и
библиотека поддержки (SUPPORT).
Примеры приложений
Чтобы посмотреть эти задачи в работе, поместите в один каталог ядро (dbrad32.exe и каталог SUPPORT) и структуру одной из задач (\STRUCT) и запустите dbrad32.exe. В простейшей задаче "Платежки" использована таблица документов и три подключенных к ней справочника (Поставщики, Получатели, Виды связи). Выбор из справочника (организация ссылок и показа по ссылкам) реализован системным механизмом.
Средства разработки структуры задачи
Структуру свой задачи (таблицы, справочники, триггеры и процедуры - STRUCT\KERNEL\) Вы будете разрабатывать в Конструкторе Структур. Для простой задачи есть шаблон простой формы. Усовершенствование форм проводится на основе классов (универсальных eGRID, элементов ввода и пр., поддерживающих авторские локальные триггера и сетевое разделение) и штатных средств VFP. Отчеты создаются и настраиваются уже в рабочей задаче. В структуре Вы можете регулировать число бесплатных записей (или вообще отключать их ограничение) для демо-версии при распространении своих задач. Удаленную регистрацию своих свободно распространяемых демо-версий Вы сможете проводить с помощью модуля регистрации-привязки по кодам идентификатора ПК клиента (это просто задача-структура - см. reg.zip, декодирующая коды от клиента). Подробнее см. OPIS.RAR. (Заметим, что существует секретная кнопка, позволяющая снять демо-режим прямо в задаче клиента без регистрации).
Примечание:Если в вашей старой версии появляется сообщение "Run time expiration period is expired ..." - sorry :((, Вы можете отключить его - зайдите в пункт меню S, выберите "Параметры системы", найдите строку с параметром dExpiration, установите флажок Коррекция, встаньте на окно со значением даты и увеличьте ее (можно пробелом вызвать календарь). Этим механизмом Вы можете блокировать свои разработки у нерадивого заказчика после указанной даты.
Статьи
How to obtain the 8-byte Time-Stamped Unique value GUID (primary key)
How to build the Cross Referencial Table (advanced function). Source code (cross.prg 12k)
How to read, edit and write back set-based data in a large source table. Source code (bufview.prg 7k)
Исходные авторские тексты проектов и решений