<<
>>

Предлагаемый подход

Для повышения скорости создания и легкости модернизации ПБД в работе предлагается использовать подход к разработке, ориентированный на модель, содержащую достаточную информацию для автоматического создания пользовательских интерфейсов приложений БД, обеспечивающих поддержку выполнения CRUD-функций, построения запросов, взаимодействия с ПД, а также возможность решения специфических задач.

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

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

Рассмотрим предлагаемую технологию разработки приложения БД. Процесс разработки ПБД предлагается разбить на следующие этапы (Рисунок 1):

1. Структурный анализ предметной области.

2. Проектирование БД.

3. Создание модели ПБД при помощи инструментального средства «ГеоАРМ» [8, 11, 12, 15, 20, 51, 55, 56].

4. Автоматическое создание ПБД, обладающего ГИС-функциональностью, на

основе спецификации инструментальной системой «ГеоАРМ».

Рисунок 1. Этапы технологии разработки ПБД

На первом этапе ИТ-специалистом проводится структурный анализ предметной области, в результате которого выявляются сущности, формулируются требования к структуре, описываются бизнес-процессы, выявляются функциональные зависимости.

Далее следует этап проектирования БД, результатом которого является схема БД для разрабатываемой системы, реализованная в определенной СУБД. Для автоматизации этого этапа можно использовать уже зарекомендовавшее себя ПО от ведущих компаний- разработчиков, позволяющее строить ER-модели данных и генерировать схемы БД (например, интегрированные утилиты СУБД MS SQL Server, Oracle или CASE-средства такие, как Sybase Power Designer [88], IBM Rational Rose [78]).

На третьем этапе строится модель приложения БД [49, 53, 55, 57, 58]. При этом в качестве входных данных используется метаданные о структуре БД (схема БД) хранящиеся в СУБД. Схема данных является уже структурированными знаниями о сущностях и связях между ними, но этих знаний недостаточно для создания полноценного ПБД. Структурную информацию БД необходимо расширить знаниями о бизнес-процессах и способах представления информации пользователю разрабатываемого ПБД.

В процессе создания модели ПБД разработчику необходимо сформировать следующие объекты: «Таблицы», «Представления», «Правила», «Надстройки» (Рисунок 2). «Таблицы» содержат структурную информацию, обеспечивающую взаимодействие (выполнение CRUD-операций) с соответствующими объектами (таблицами) БД, а именно информацию о полях таблиц с их типами данных и связях с другими таблицами БД. В случае грамотно спроектированной БД структурные метаданные таблиц можно получить автоматически из СУБД. Но необходимо отметить, что встречаются БД, в которых отсутствует информация о связях (например, унаследованные БД), поэтому должна быть возможность уточнения такой информации при формировании объектов модели приложения БД. Та же возможность необходима при реализации работы в приложении с несколькими БД.

34

Рисунок 2. Объекты модели приложения БД

«Представления» - это более сложные, чем «Таблицы», объекты модели ПБД, отвечающие за формирование наборов данных для последующего отображения.

«Представления» необходимы для формирования пользовательского интерфейса, поскольку только структурной информации о таблицах БД для этого недостаточно. Например, при наличии в таблице внешнего ключа (ссылка на справочник) пользователь должен иметь возможность выбирать значения из справочника, а если справочник сложный (состоит из нескольких полей или содержит в свою очередь ссылки на другие справочники), то необходимо знать, какая комбинация полей справочника позволяет однозначно идентифицировать нужную запись (по каким полям выбирать запись) и есть ли необходимость при этом отображать значения через несколько уровней ссылок. Кроме того, структурной информации о связях бывает недостаточно для

35 понимания желаемого механизма работы пользователя с данными. Например, ссылка из списка A в справочник B (внешний ключ) при работе с записями списка A обеспечивает выбор значений из B, а для каждой записи B позволяет формировать список значений из A (механизм «Мастер-детали»). В описании «Представлений» содержится информация о декодировании значений по ссылкам и способах интерпретации связей, что обеспечивает автоматическое построение удобного пользовательского интерфейса.

Для большинства ПБД, предназначенных для решения сугубо реестровых задач (например, регистр населения, реестр объектов недвижимости), при создании приложения БД достаточно описать «Таблицы» и «Представления». Объекты модели «Надстройки» необходимы для поддержки взаимодействия с внешними модулями, отвечающими за решение не заложенных в ПБД задач (например, сложные вычисления, построение графиков).

Объекты модели «Правила» отвечают за реализацию специфических бизнес-функций между различными объектами модели ПБД, например, установка режимов модификации данных, проверка на уникальность, взаимодействие с ПД. Правила могут влиять как на работу с конкретными таблицами БД, так и на формирование пользовательского интерфейса. Например, при наличии в таблице координат пространственного объекта формируются специальные элементы пользовательского интерфейса для поддержки функций связи с цифровыми картами и автоматического построения пространственных объектов.

Для поддержки процесса создания моделей ПБД применяется специально разработанная инструментальная система «ГеоАРМ» [8, 11, 12, 15, 20, 51, 55, 56]. Инструментальная система обеспечивает поддержку следующих процессов: подключение к БД, загрузка структурных метаданных таблиц БД, уточнение структуры и связей таблиц, формирование представлений, задание правил, описание взаимодействия с надстройками, а также уточнение механизмов отображения (для формирования пользовательского интерфейса). Необходимо отметить, что такое уточнение не является необходимым, поскольку структурной информации о таблицах и представлениях в предлагаемой технологии достаточно

36 для создания работоспособного ПБД. В результате созданные модели ПБД инструментальная система позволяет сохранить в виде декларативных спецификаций [15, 47, 51, 55].

Часто в информационных технологиях спецификации являются описанием архитектуры и функций ППС, создаваемые для согласования действий разработчиков и тестирования прототипов. В предлагаемом подходе спецификация является средством представления и хранения модели ПБД, которая в декларативном виде содержит информацию о предметной области в виде соответствующих структурных метаданных БД, правилах формирования пользовательского интерфейса, бизнес-логике приложения, методах взаимодействия с ПД и способах взаимодействия с внешними приложениями.

На четвёртом этапе при помощи спецификации инструментальная система автоматически настраивается, становясь предметным ПБД, обеспечивающем поддержку всех функций работы с базой данных и возможность взаимодействия с пространственной информацией. Весь пользовательский интерфейс ПБД формируется динамически при интерпретации спецификации системой «ГеоАРМ» (Рисунок 3). Преимущества такого подхода состоит в отсутствии необходимости специально разрабатывать (создавать элементы интерфейса, связывать их с данными, компилировать, отлаживать) формы пользовательского интерфейса для каждой таблицы и представления. Механизм создания элементов пользовательского интерфейса, связывания их со структурами данных унифицирован и встроен в интерпретатор системы.

Интеграция функций создания спецификаций и их интерпретации в одной системе даёт возможность разработчику сразу оценивать адекватность создаваемой модели ПБД и позволяет повысить скорость разработки в целом.

Рисунок 3 Инструментальная система «Г еоАРМ»

Развитие и модернизация ПБД в предлагаемой технологии упрощается за счет отсутствия потребности в изменении программного кода, его отладки и компиляции с применением специализированных средств разработки ПО. Разработанная в рамках данной работы инструментальная система обеспечивает поддержку как создания, так и модернизации спецификации ПБД за счет встроенных визуальных инструментальных средств формирования спецификаций, что позволяет сократить сроки доработки ПБД на каждом этапе жизненного цикла

системы.

2.2.

<< | >>
Источник: Фереферов Евгений Сергеевич. ТЕХНОЛОГИЯ АВТОМАТИЗАЦИИ СОЗДАНИЯ ПРИЛОЖЕНИЙ БАЗ ДАННЫХ С ГИС-ФУНКЦИОНАЛЬНОСТЬЮ НА ОСНОВЕ ИХ ДЕКЛАРАТИВНЫХ СПЕЦИФИКАЦИЙ. ДИССЕРТАЦИЯ на соискание ученой степени кандидата технических наук. Иркутск - 2014. 2014

Еще по теме Предлагаемый подход:

  1. Экономический подход
  2. Рыночный подход
  3. Теоретические и методические подходы к расчету ставки восстановления
  4. О методологических подходах к изучению языка поэзии П.А. Вяземского
  5. 1 ТЕОРЕТИЧЕСКИЕ ПОДХОДЫ И ИСТОРИЯ ИЗУЧЕНИЯ ПРОБЛЕМЫ КРН НА МАГИСТРАЛЬНЫХ ГАЗОПРОВОДАХ
  6. Подходы к оценке опасности дефектов КРН, реализуемые в нормативной доку­ментации
  7. Глава 1 Понятие, область применения и подходы к расчету ставки восстановления по корпоративным облигациям
  8. Ставка восстановления как ключевой параметр расчета требований к капиталу и резервирования
  9. Исследование информативности современной медианоминации
  10. ВЫВОДЫ ПО ГЛАВЕ 1
  11. Вопрос о семантической систематизации славянизмов (церковнославяно-русских полисемантов)
  12. 1.6. Исполнительная власть и государственное управление.
  13. Заключение
  14. Основные результаты и выводы исследования
  15. Перемещение твердых частиц аэрозолей в воздушных пространствах конструкций вентилируемых фасадов
  16. Введение
  17. Отраслевые факторы
  18. 38. Акционерное общество как участник гражданских правоотношений.
  19. 4.2. Виды органов исполнительной власти
  20. Моделирование теплопередачи через наружные стены с учетом отражательных свойств внутренних поверхностей помещения