РАЗДЕЛ 2. МЕХАНИЗМ ГРАФОВЫХ ЗАПРОСОВ
Во втором разделе рассмотрена проблема представления неоднородной семантически связной информации при генерации прикладного ПО. Предложенный механизм графовых запросов основан на МПрО в виде специального случая семантических сетей - структурированных семантических сетей (ССС). ССС введены и исследованы как средство концептуального моделирования, обобщающее и тем самым позволяющее абстрагироваться от особенностей популярных моделей - диаграмм "сущность-связь" (ERD) и объектных диаграмм (UML). С обобщением концептуальной модели к ССС удалось формализовать требования к семантически-связного фрагменту МПрО, предложить способ его описания и визуализации в виде графового запроса и информационного графа соответственно. Графовый запрос исследован как языковой конструкт над ССС, проанализированы его мощность и ограничения с позиций концептуального и логического уровня БД. Доказана полнота графовых запросов в двух смыслах (семантическом и языковом). Предложен интерфейс пользователя графовых запросов в виде графического языка запроса по образцу ER-QBE. Разработаны алгоритмы интерпретации графового запроса и трансляции ER-QBE в SQL-подобный язык запросов широкого класса СУБД, в частности, объектно-реляционных и объектно-ориентированных. Возможности графовых запросов проанализированы и проиллюстрированы примерами.
На основе графовых запросов построены формализм и средство автоматизированного проектирования приложений - графовый прототип (ГП), ориентированный на развитие приложений по спиральной модели ЖЦ благодаря простоте генерации на первом этапе и возможности отладки, а также общей гибкости и применению визуальных формализмов.
2.1 Представление семантически-связной информации
Кроме проектной документации, CASE-системы обладают двумя основными средствами собственно автоматического программирования, во-первых, трансляторами концептуальной схемы приложения в реляционную СУБД, во-вторых, средствами генерации текстов программ. Генераторы БД, например, Visio 2000, ERwin, Designer/2000, эффективно применяются разработчиками и отлично зарекомендовали себя в разработке приложений. Генераторы кодов и языки 4GL, также входящие в известные CASE-системы, менее популярны в среде разработчиков. Это связано в первую очередь с семантической бедностью реляционной модели и, как следствие, недостатком информации для автоматической генерации достаточно сложного приложения. Классические ER-диаграммы применяются для описания данных в 1NF [90], что в смысле ПИ соответствует простой форме без учета вложенности и иерархической соподчиненности данных.
Использование ОО-нотации UML в Rational Rose [38, 98] позволило перейти при описании сущности на уровень структурированного объекта, а при описании ПИ - на уровень иерархически организованного АРМ, что значительно повысило эффективность автоматического генерирования кода. Окончательной "победе" генераторов приложений мешает основная проблема ОО-подхода - проблема декомпозиции. Современные приложения нередко основываются на БД с сотнями таблиц, а типичная ER-диаграмма системы масштаба предприятия не помещается на ватмане формата А0. Аккуратно разбить все это множество на небольшое число непересекающихся объектов, отвечающих информационным потребностям отдельных категорий пользователей - весьма трудная задача. А соотнесение объекта с формой накладывает дополнительные ограничения на допустимую сложность (вложенность) объектов. В результате сгенерированные приложения оказываются недостаточно мощными и удобными для практического вытеснения программистов из сферы поддержки ординарного бизнеса.
В качестве следующего шага в указанном направлении предлагается автоматизировать навигацию и взаимодействие между формами-объектами на основе выделения и семантического обогащения связанных фрагментов БД. Эти фрагменты, возможно, пересекающиеся, представляют собой МПрО отдельных задач, т.е. являются взглядами отдельных категорий пользователей. Введение нового (сетевого) уровня представления приложений не влияет на представления отдельных вершин сети - форм и объектов (см. табл. 2.1). Таким образом, обеспечивается совместимость с существующими средствами автоматизации программирования - как классическими, так и объектно-ориентированными.
Таблица 2.1 Средства моделирования семантических единиц МПрО
Семантические единицы МПрО и ПИСредства моделированияФрагмент сети объектов - приложение?Структурированный объект - АРМДиаграммы классов UMLТаблица в 1нф - формаER-диаграммы
Реализация механизма автоматической поддержки семантически связных фрагментов БД целесообразна только при условии решения следующих задач:
- выделение семантически связного фрагмента БД (традиционно приложение работает не со всей МПрО, а с полезной специализированной информацией, которую можно ограничить множеством логических условий, в том числе, структурно);
- поддержка разных взглядов на БД (в зависимости от конкретной задачи, прав и потребностей пользователя, специфике данных);
- поддержка семантической целостности (ограничения целостности данных, как правило, выходят за рамки автоматически поддерживаемых свойств модели данных);
- интеллектуальная навигация по БД (удобная навигация между объектами и формами в больших приложениях - одна из главных трудностей проектирования пользовательского интерфейса);
- специальная поддержка представления произвольных графов в пользовательском интерфейсе (традиционные способы визуализации информации, таблица и форма, плохо сочетаются с сетевой структурой данных).
Решение вышеперечисленных задач в известных CASE-системах в той или иной степени предполагает ручное программирование, а проблема визуализации графов (Graph Drawing) в общем случае не имеет решения, даже при условии ручного программирования [10]. Следовательно, их автоматизация позволит вывести CASE-технологию на новый уровень. Наша идея заключается в перестановке акцента с данных на приложение применительно к сети объектов, подобно тому, как это сдел
- Київ+380960830922