Системы сквозного проектирования
А. Закис, Н. Приезжий, DataX/FLORIN
В предшествующих выступлениях и публикации мы неоднократно рассматривали технологию сквозного проектирования информационных систем, основанную на использовании CASE инструментария фирмы Cayenne (VantageTeam), сред разработки приложений фирм Informix (4GL и NewEra) и Four Seasons (SuperNova) и кодогенераторов фирмы DataX/FLORIN (GRINDERY OneStep 4GL, GRINDERY NewEra/Yourdon, GRINDERY SuperNova/Yourdon). В данном выступлении мы хотели бы рассказать о новом продукте нашей фирмы - среде быстрой разработки GRINDERY Grabber.
Технология
Прежде всего, мы хотели бы ответить на вопрос, который нам неоднократно задавали во время UnixExpo, где был представлен этот продукт: почему мы взялись за его разработку в то время, когда на рынке имеется достаточное количество разнообразных CASE средств и билдеров. Ответ прост - этот продукт "создался сам" из тех технических решений, которые мы использовали при работе над собственными проектами или предлагали нашим клиентам для того, чтобы соединить различные средства автоматизации проектирования и программирования в единый технологический процесс, и которые отсутствовали (или были недостаточно развиты) в готовых продуктах .
Что же не устраивало нас в стандартных подходах? Для ответа на этот вопрос рассмотрим две модели использования средств автоматизации: "до и от" и "от и до".
Первый подход (пропагандируемый разработчиками билдеров и "легких" CASE средств) предполагает, что CASE используется только для проектирования и ("до") создания базы данных, а разработка приложения осуществляется ("от" готовой базы) с помощью билдеров, которые обладают собственными средствами реверсинжениринга модели данных, библиотеками классов и многими другими достоинствами. На наш взгляд, основными недостатками этого подхода является то, что технологический процесс разорван - модель данных, используемая билдером, значительно беднее модели, разработанной аналитиком в CASE (или "в голове", если CASE вообще не использовался), и аналитик вынужден передавать недостающую информацию "голосом".
При использовании билдера выясняется, что стандартные библиотеки классов недостаточны для полнофункционального приложения, и каждый программист по-своему наращивает функциональность, что приводит к "лоскутному" интерфейсу. Стандартизация интерфейса может быть осуществлена либо организационными методами, либо за счет использования написанной "на коленке" библиотеки классов. В итоге, аналитик и программисты получают удобный инструментарий, но его использование не приводит ни к улучшению качества системы, ни к ускорению разработки.
Второй подход (реализованный в "тяжелых" CASE средствах, например, в VantageTeam) предполагает, что в CASE поддерживает разработку "от" анализа "до" логических моделей данных и приложения, на основе которых создается база данных и осуществляется автоматическая генерация программного кода. VantageTeam предоставляет пользователю прекрасный инструментарий для проектирования приложения:
- диаграммы содержания экранных форм (FCD - Form Contence Diagram), которые позволяют описать структуру и (в значительной степени) функциональность сложных экранных форм (предназначенных для работы с несколькими таблицами);
- диаграммы структурных схем (SCD - Structure Charts Diagram), которые позволяют описать алгоритмы программных модулей и методы работы с экранными формами (последняя задача в рамках структурного подхода достаточно элегантно решена с помощью так называемых "предопределенных модулей");
- диаграммы последовательности экранных форм (FSD - Form Sequence Diagram), которая задает общую структуру приложения. а также связывает формы и алгоритмы (методы).
Но и это не панацея. Главный недостаток этого подхода состоит в том, что идеология проектирования не учитывает реальные потребности проектировщика, который должен разработать информационную систему со стандартным интерфейсом (поскольку заказчику нужна система с легко осваиваемыми рабочими местами). Проектировщику нужны средства построения логической модели стандарта интерфейса, а не полной модели всех элементов интерфейса. Детальное проектирование каждой экранной формы (средствами FCD или в билдере) при создании стандартного интерфейса является не только нудной, но и (в большинстве случаев) вредной работой (немногочисленные, как правило, "уникальные" рабочие места гораздо быстрее и проще создавать на основе типового рабочего места, а не "с чистого листа").
Наша фирма пошла по пути проектирования стандарта. Результатом этой работы стала технология сквозного проектирования и семейство кодогенераторов GRINDERY.
Однако их область их применения существенно ограничивалась тем, что они были настроены на логическую модель данных, формируемую VantageTeam. Затраты на приобретение и освоение "тяжелого" CASE окупаются только при создании достаточно крупных систем или при "поточном" производстве, а многие возможности, предоставляемые продуктами этого класса, не столь уж необходимы для создания небольшой системы разработчиками, хорошо знающими предметную область ( и, тем более, для воспроизведения существующей системы на другой платформе, что является весьма актуальной задачей для многих систем ). И мы занялись разработкой "легкой" технологии сквозного проектирования "от" существующей базы данных. Ее основные отличия от рассмотренной выше технологии "до и от" состоят в следующем:
- при реверсинжениринге создается не физическая, а логическая модель данных, на основе которой осуществляется генерация стандартного интерфейса ;
- билдеры используются только в режиме модификации, причем внесенные изменения автоматически фиксируются и воспроизводятся при повторной генерации.
Продукт (GRINDERY Grabber v.1.0) и проект (GRINDERY Grabber v.2.x)
GRINDERY Grabber v1.0 обеспечивает:
- восстановление логической модели базы данных на основе информации, хранящейся в системных каталогах;
- интерфейс для ввода параметров, описывающих стандарт приложения;
- генерацию приложения на любом языке, поддерживаемом семейством кодогенераторов GRINDERY (в настоящее время - Informix- 4GL, NewEra, SuperNova);
- фиксацию изменений, внесенных в программный код пользователем и их воспроизведение при повторной генерации;
- модификацию структуры базы данных в объеме, необходимом для эффективной работы стандартного приложения.
- GRINDERY Grabber v1.0 поддерживает:
- групповую работу над проектами и управление версиями проектов, в том числе:
- разграничение прав доступа;
- независимую разработку частей проекта;
- сборку проекта ;
- документирование проекта.
GRINDERY Grabber v1. 0 поддерживает разработку приложений для СУБД Informix, Oracle, CA OpenIngres и может работать на основных Unix и всех Windows платформах.
Принципы построения стандартного интерфейса
- Для каждой сущности (предметной таблицы базы данных) создается "рабочее место", позволяющее выполнять основные операции (INSERT, UPDATE, DELETE, QBE) с данными, содержащимися в этой таблице.
- Рабочее место позволяет работать не только с "главной" таблицей, но и с другими ("вспомогательными" для данного рабочего места) таблицами базы данных. В том случае, когда реляционная модель данных адекватно отражает связи и бизнес-правила предметной области, вспомогательными являются "таблицы-словари" ( Master tables - таблицы, из которых импортирует ключи "главная" таблица), "таблицы-потомки" (Detail tables - таблицы, которые содержат ссылки на "главную") и "таблицы-партнеры" (связанные с "главной" таблицей отношением "многое ко многому"). Вспомогательные таблицы доступны как в режиме просмотра, так и в режиме модификации (если это необходимо для данного рабочего места).
- Каждая таблица имеет в интерфейсе два представления:
- в виде одной записи, содержащей полный набор полей - детальное представление.Оно используется для добавления записей в "главную" таблицу и их модификации;
- в виде списка (браузера), который используется для навигации (поиска) по главной и вспомогательным таблицам, а также для выполнения групповых операций. При этом используется краткое представление - определяемый пользователем набор полей, достаточный для однозначной идентификации записи и содержащий наиболее часто используемую информацию (например, для таблицы "Фирма" в краткое представление целесообразно включить название фирмы и ее банковские реквизиты). Краткое представление таблицы для всех рабочих мест одинаково.
При таком подходе основная информация, необходимая для генерации приложения "считывается" из логической модели данных. Пользователю необходимо задать незначительное количество атрибутов:
- имена, под которыми должны отображаться таблицы и их колонки;
- состав предметного ключа (кодогенерация рассчитана на то, что в качестве первичного используется искусственный ключ - колонка типа SERIAL);
- форму представления колонок в графическом интерфейсе (Entry, Label etc)
- состав краткого представления таблиц;
- возможность модификации таблицы-словаря;
- необходимость и форму представления информации из таблиц-потомков и таблиц-партнеров в детальной форме;
- политику поддержки целостности при удалении.
Структура GRINDERY Grabber
GRINDERY Grabber включает:
- модуль Reverse Engineering;
- модуль DB Designer;
- модуль Access;
- модуль Tuner (v.2.x);
- модуль App Designer;
- кодогенераторы GRINDERY;
- модуль Target Bridge;
- модуль Test Designer (v.2.x).
Модуль Reverse Engineering обеспечивает построение логической модели данных.
Модуль DB Designer предназначен для проектирования (v.2.x) и модификации модели базы данных.
В версии 1.0 поддерживается:
- модификация базы данных в минимальном объеме, необходимом для эффективной работы приложения (переход от предметных ключей к искусственным, создание UNIQUE CONSTRAINTS для предметных ключей, создание триггеров, поддерживающих политику Nullify, создание служебных таблиц для SuperNova);
- ведение архива пользовательского DDL.
В версии 2.х предполагается:
- навигационный интерфейс, обеспечивающий представление всех объектов базы данных, включая триггера и хранимые процедуры;
- конструктор логической модели данных;
- конструктор триггеров и хранимых процедур, основанный на синтаксической декомпозиции DDL, библиотеке шаблонов и языке подстановок.
Модуль Access обеспечивает:
- автоматическую генерацию DDL (в версии 1.0 - по шаблонам, в 2.х - генерация DDL для любой из поддерживаемых СУБД по логической модели данных, триггеров и хранимых процедур);
- исполнение DDL и ведение журнала модификации базы данных;
- синхронизацию логической модели с актуальным состоянием базы данных.
Модуль Tuner обеспечивает:
- трассировку SQL запросов;
- фиксацию времени исполнения SQL запросов;
- проведение исторических тестов (сравнение результатов исполнения SQL запросов с эталоном);
- ведение архива тестов и результатов их исполнения;
- генерацию стандартного или задаваемого пользователем структурированного отчета по результатам трассировки;
- статистическую обработку и графическое представление результатов замеров производительности.
Модуль App Designer предназначен для построения логической модели приложения и содержит:
- графический (навигационный) интерфейс ввода информации;
- генератор текстовых отчетов .
Кодогенераторы Grindery обеспечивают генерацию исходных кодов приложений на языках Informix- 4GL, NewEra, SuperNova. В состав всех кодогенераторов входят расширенные библиотеки классов (функций). Генератор для SuperNova содержит открытую библиотеку шаблонов.
Модуль Target Bridge обеспечивает:
- фиксацию изменений, внесенных пользователем (только для NewEra; для Informix- 4GL и SuperNova эта функция реализована в кодогенераторе);
- генерацию make-файла;
- оптимизацию процесса трансляции WIF-файлов (утилита 4GLGEN для NewEra).
Модуль Test Designer включает :
- конструктор тестов, основанный на открытой библиотеке шаблонов и языке подстановок;
- средства контроля полноты тестов, основанные на синтаксическом анализе SQL и логической модели базы данных;
- генератор тестов на производительность (имитация многопользовательского режима и "клонирование" SQL запросов,
- графический интерфейс представления теста и его воздействия на объекты базы данных.
Сценарии использования GRINDERY Grabber
Наша фирма предлагает следующие сценарии использования GRINDERY Grabber v.1.0
- при работе над большими проектами (и фирм занимающихся индустриальной разработкой информационных систем) GRINDERY Grabber v.1.0 может использоваться как дополнение к "тяжелому" CASE (при использовании VantageTeam, в силу совместимости формата хранения модели данных, разработка стандарта приложения не требует создания целевой базы данных).
Такое использование не только позволяет сократить количество дорогих рабочих мест, но и позволяет изменить подход к проектированию базы данных. В CASE достаточно разработать концептуальную модель данных (используя такие составные предметные ключи, ассоциативные объекты, субтипы), а ее приведения к "удобному для СУБД" виду будет сделано автоматически. Кроме того, GRINDERY Grabber позволяет провести быстрое прототипирование приложения, что позволяет провести окончательную верификацию модели данных;
- при разработке средних систем и решении задач миграции существующих систем в новую среду разработки GRINDERY Grabber может использоваться не только как средство создания конечного приложения, но и как средство сравнительной оценки разных средств разработки (поскольку приложение может быть создано и протестировано в пределах срока демо лицензии);
- при решении проблем сопровождения плохо документированных систем .
Дополнения, предусмотренные в GRINDERY Grabber v.2.x позволят использовать его:
- в качестве инструмента проектирования и отладки серверной части приложения;
- как инструмент поддерживающий миграцию существующих систем на новую СУБД. При этом поддерживается не только миграция на выбранную СУБД но и ее выбор по результатам сравнительного тестирования;
- как инструмент тестирования существующих систем. .
[]
[]
[]
