Содержание


Реализация системы проектирования и формирования нефтегазовой отчетности с использованием IBM Rational RequisitePro и SoDA

Comments

Исходные данные

Исходными данными для разработки нового или модификации разработанного ранее отчёта служит запрос от заказчика с прилагаемым описанием "шапки" отчёта – иначе говоря, перечня столбцов по выводимым показателям. Разработка отчёта заключается в описании правил выборки данных и формул расчёта необходимых показателей с последующим формированием на основе этих правил SQL-запросов. Для реализации отчёта привлекается аналитик, формирующий постановку на отчёт, и программист, занимающийся собственно разработкой отчёта в специальном модуле.

Описание решения

На базе IBM Rational Requisite Pro было разработано решение для проектирования отчётов, охватывающее процесс описания полей в виде постановки, и далее – формирования SQL-запросов для получения данных в отчёт. В самом RequisitePro разработана схема, включающая типы требований и ряд атрибутов для них, а также сформирована структура каталогов, группирующая описания полей БД, отчёты и их поля.

Итак, для реализации решения в системе управления требованиями IBM Rational Requisite Pro были определены следующие типы требований.

  • Field (FLD) – поле отчёта либо таблицы, или входной параметр отчёта. Для идентификации используются атрибуты (см. ниже).
  • Глоссарий (TERM) – элемент глоссария. Добавление этого типа требований было обусловлено отсутствием формализованного глоссария системы на момент разработки решения.

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

Атрибуты требований типа Field

  • Тип поля. С помощью этого атрибута указывается принадлежность поля и механизм формирования значения (рисунок 1). Атрибут принимает одно из следующих значений:
    • поле отчета – определяет, является ли поле выводимым в отчет;
    • поле таблицы – говорит о том, что поле принадлежит таблице БД;
    • поле представления – указывает на принадлежность поля к представлению БД;
    • агрегация – характеризует поле как агрегированное значение других полей;
    • параметр отчёта – поле описывает параметр, задаваемый при формировании отчёта.
  • Размер поля. Атрибут указывает на количество символов поля.
  • SQL-код. Атрибут хранит SQL-код к описанию поля, разработанный в приложении расширения – Конструктор отчёта.
Рисунок 1. Логические связи типов полей
Рисунок 1. Логические связи типов полей
Рисунок 1. Логические связи типов полей

Атрибуты требований типа TERM:

  • Архитектурная функция. Атрибут уточняет, является ли описываемый термин архитектурной функцией системы.

Для хранения требований в репозитории была организована структура каталогов, в которой верхний уровень разделял требования на описание базы данных, отчётов и глоссария. Каталог структуры базы данных разделялся на каталоги для таблиц, в которых формировались требования – описания полей. С целью точной идентификации полей разных таблиц было оговорено правило наименования полей – имя должно содержать название таблицы и имя самого поля, разделённые точкой: Таблица_1.Поле_1.

Соответственно, каталог с описанием требований к отчётам делился на подкаталоги под каждый описываемый отчёт. Правило наименования аналогично принятому для полей таблиц – имя поля содержит название отчёта и самого поля: Отчет_2.Поле_7. Для контроля связей между полями отчёта и полями отчёта и таблиц настроены представления (View). Названия представлений содержат перечисление контролируемых сущностей – например, поля отчёта к БД, агрегациям и входным параметрам отчёта (рисунок 2).

Рисунок 2. Контроль связей полей отчёта с базой данных
Рисунок 2. Контроль связей полей отчёта с базой данных
Рисунок 2. Контроль связей полей отчёта с базой данных

Процесс разработки отчёта

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

Вторая проблема – это тот факт, что сама система находилась в стадии активной доработки, причём доработка затрагивала и структуру продуктивной базы данных, изменения в которой приводили к неработоспособности разработанных ранее отчётов. Ведение описаний требований к отчёту и связанных с ними полей базы данных в RequisitePro позволили контролировать нарушения связей и прогнозировать объём работы по изменению отчётности, возникающий вследствие изменения структуры БД. Результат – значительное снижение количества дефектов в отчётности и повышение качества работ организации.

После разработки и согласования шаблона постановки был утверждён стандарт на документ "Постановка на отчёт", который удовлетворял требованиям разработчиков. Но главное достоинство этого шаблона заключалось в том, что в его основе лежал шаблон отчёта IBM Rational SoDA, и формирование самой постановки на отчёт теперь выполнялось автоматически, как формирование отчёта по указанным требованиям IBM Rational RequisitePro.

Работа аналитиков была перенесена в инструмент RequisitePro. Отныне вместо описания постановки в "плоском" виде, т.е. как обычного документа, постановщики описывали отчёт в виде требований к полям отчёта, после чего формировали отчёт по описанным требованиям с получением на выходе формализованного документа (рисунок 3).

Рисунок 3. Процесс формирования постановки
Рисунок 3. Процесс формирования постановки
Рисунок 3. Процесс формирования постановки

Следующим важным шагом в оптимизации процесса было принятие общего стандарта на описание правил формирования полей отчёта. Также были оговорены правила описания формул расчёта значений полей – иначе говоря, из описаний были исключены любые вариации описания ряда выражений и оговорен формат описания расчёта значений (рисунок 4).

Рисунок 4. Синтаксис описания поля отчёта
Рисунок 4. Синтаксис описания поля отчёта
Рисунок 4. Синтаксис описания поля отчёта

На рисунке 5 представлено окно RequisitePro с отображением дерева отчётов и требований к их полям и развёрнутое окно описания свойств требования к полю отчёта.

Рисунок 5. Структура каталогов отчётов и описание поля
Рисунок 5. Структура каталогов отчётов и описание поля
Рисунок 5. Структура каталогов отчётов и описание поля

Развёрнутое окно описания поля БД показано на рисунке 6.

Рисунок 6. Описание поля базы данных
Рисунок 6. Описание поля базы данных
Рисунок 6. Описание поля базы данных

Модуль конструкции SQL-кода

Вторая часть разработанного решения – это модуль расширения к схеме RequisitePro, автоматизирующий поиск и отметку связей от полей отчёта к полям таблиц и позволяющий на основе описания поля конструировать SQL-запросы.

Функциональность модуля

На рисунке 7 перечислены функции, выполняемые модулем.

Рисунок 7. Функциональность модуля
Рисунок 7. Функциональность модуля
Рисунок 7. Функциональность модуля

После описания требований к полям в Requisite Pro дальнейшие действия по разработке отчёта выполняются в оригинальном инструменте построения отчётов. Оригинальная разработка "Модуль конструкции SQL-кода" как надстройка к RequisitePro решает следующие основные задачи:

  • автоматизация рутинных операций проставления трассировок в репозитории RequisitePro;
  • разработка простых SQL-запросов в графическом режиме с сохранением их в репозитории RequisitePro.

Входящими данными для конструктора являются требования типа FLD репозитория требований RequisitePro. При подключении к репозиторию в правой части основной формы в древовидной структуре выводятся все каталоги отчётов и требования к их полям, описанные в репозитории.

Работа с модулем конструкции SQL-кода

Работа в модулем начинается с главной формы, на которую выведен браузер, отображающий каталоги отчётов с требованиями, описывающими их поля, окно для вывода описания поля из репозитория, окно вывода SQL-кода поля, кнопка вызова режима конструктора SQL и кнопка тестирования запроса с окном для вывода результата работы.

Упомянутая выше функция автоматического контроля трассировок полей отчёта к полям БД вызывается из контекстного меню (рисунок 8).

Рисунок 8. Основная форма модуля
Рисунок 8. Основная форма модуля
Рисунок 8. Основная форма модуля

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

Кроме того, выполняется контроль целостности проставленных трассировок. Если в проверяемом отчёте есть нарушенные трассировки, разработчик получает уведомление, а в поле дискуссий требования вносится запись о возможном нарушении связей с перечислением полей.

При выборе в браузере отчётов поля в верхнее окно основной формы выводится описание требования к полю, во второе окно – SQL-запрос из атрибутов требования к полю (рисунок 9).

Рисунок 9. Просмотр описания поля в модуле
Рисунок 9. Просмотр описания поля в модуле
Рисунок 9. Просмотр описания поля в модуле

Формирование SQL-запроса выполняется в режиме конструктора – переход в него происходит по нажатию соответствующей кнопки на форме.

Режим конструктора представляет собой форму с двумя окнами (рисунок 10). В верхнее окно выводится описание требования к полю. В нижнее окно методом drag&drop перетаскиваются и группируются в SQL-код выделенные выражения. Первое перенесённое выражение составляет искомое поле таблицы, последующие – условия выборки, критерии фильтрации записей. Служебные слова SQL-запроса добавляются по мере внесения в окно новых выражений. Полученный SQL-код можно тут же отредактировать вручную. После начала редактирования функция перетаскивания выражений из описания поля становится недоступной. Для того чтобы вновь активировать её, необходимо сбросить полученный SQL-запрос нажатием на кнопку Reset.

Рисунок 10. Конструктор SQL-запросов
Рисунок 10. Конструктор SQL-запросов
Рисунок 10. Конструктор SQL-запросов

Когда конструирование SQL-запроса завершено, нажатие на кнопку ОК возвращает пользователя на главную форму, с которой доступна функция проверки полученного SQL-запроса. Если в запросе есть входные данные (выделенные символами <>), то при инициации выполнения запроса будет запрошен их ввод (рисунок 11).

Рисунок 11. Диалог ввода параметров отчёта
Рисунок 11. Диалог ввода параметров отчёта
Рисунок 11. Диалог ввода параметров отчёта

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

Шаблон отчёта SoDA для формирования постановки состоит из названия отчёта, краткого описания и шапки отчёта – информация, полученная от заказчика отчёта. Далее следует правило выборки входных данных отчёта и описания его полей. Для формирования постановки на новый отчёт необходимо всего лишь изменить фильтр в шаблоне SoDA, определяющий корневой каталог отчёта (рисунок 12).

Рисунок 12. Шаблон SoDA для формирования постановки
Рисунок 12. Шаблон SoDA для формирования постановки
Рисунок 12. Шаблон SoDA для формирования постановки

По проставленным модулем трассировкам в отчёт выводятся все связанные с полем отчёта поля базы данных.

Заключение

Внедрение описанного решения повысило качество работы постановщика, возвраты постановок на доработку были сведены к минимуму. Мы провели анализ по работе аналитиков в течение первого месяца с начала использования решения и сделали вывод, что число постановок, отправляемых на доработку, сократилось в разы и было сведено к минимуму. Теперь, если отказ в утверждении постановки и происходил, то в силу действительно весомых причин. Кроме сокращения временных затрат это дало и чисто психологический эффект – было снижено напряжение в коллективе между группой аналитиков, архитектором системы и разработчиками.

Анализ трудозатрат на разработку отчёта в целом показал выравнивание количества затрачиваемого времени, которое составило менее усреднённого значения по сравнению с обстановкой до внедрения решения, а это в свою очередь повысило прогнозируемость процесса.


Ресурсы для скачивания


Комментарии

Войдите или зарегистрируйтесь для того чтобы оставлять комментарии или подписаться на них.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Rational
ArticleID=373185
ArticleTitle=Реализация системы проектирования и формирования нефтегазовой отчетности с использованием IBM Rational RequisitePro и SoDA
publish-date=02272009