Есть ли языки для описания технического задания по формирования сложных отчетов в табличной форме?

Question

[Дмитрий Лузин]

По базе данных формируются отчеты в большом количестве. Отчеты от маленьких до больших. "Технические задания" на правила для расчета значений ячеек может занимать по 50 страниц и более. Задания пишутся, чуть ли не формально (для строк.., графов ... реквизиты таки-то, условия такие-то, исключения такие-то,...). Написать автоматический парсер невозможно из-за формального подхода в описании условий. Я так думаю, чтобы не изобретать велосипед, что уже существуют способы или языки для написания таких заданий, по которым потом строятся в автоматическом режиме запросы. Подскажите направление, куда смотреть? Т.к. когда приходят "задания" в таком виде, уходит уйма времени на его изучение, трудно понять, что изменилось, что добавили.

Answer 1

[Dimonchik]

SQL

Comments

[Дмитрий Лузин]

Проблема в том, что ТЗ спускают из Москвы в регионы в абстрактной форме. В Москве базы нет, там только сочиняют условия формирований таблиц. В регионах у всех по разному. По этому чистый SQL отпадает.

Answer 2

[Doc44]

Изначально SQL придуман для менеджеров.
Не для программистов.

Есть также графические построители запросов SQL.
Вполне пригодны для использования самыми что ни на есть рядовыми пользователями.

https://www.quora.com/What-are-some-good-visual-SQ...
Их на самом деле очень и очень много...

Но тут возникает вопрос -
а будут ли пользователи достаточно формально подходить к постановке задачи,
чтобы можно было все эти формальные инструменты автоматически использовать.

Полагаю, что им проще свалить это все же на программистов.

Comments

[Дмитрий Лузин]

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

[Doc44]

Дмитрий Лузин, их все равно вручную обрабатывать.
Ну например Rational RequisitePro

Answer 3

[kn0ckn0ck]

Помимо того, что потребуется найти и договориться об использовании какого-то языка описания, потребуется еще и обучить постановщиков использованию этого языка. Вот эта вторая задача может быть куда более неподъемная чем первая.

Что касается языков для описания/моделирования отчетных форм, то общеизвестных стандартов нет. Все это всегда привязано к конкретному BI-инструменту и встроено в его графическую IDE, при помощи которой эти отчеты создаются: MS SSRS, Crystal Reports, Cogons BI, Oracle BI и т.п.

В простых случаях можно было бы обойтись обычным UML с добавлением OCL, но разве вам этого будет достаточно?

Если попробовать решать другую проблему - увидеть изменения в ТЗ на отчетную форму, то вам не язык нужен, а инструмент для ведения требований (или ALM систему).

Answer 4

[Alexander Ivanov]

Странное задание. Кажется немного неправдоподобным.

Прежде чем городить в языках, попробуйте формазизовать саму вашу проблему.

# Контроль версий

Всеволод Владимиров обязательно обратил бы внимание на последнюю фразу "уходит уйма времени на его изучение, трудно понять, что изменилось, что добавили". С большой вероятностью, у вас проблемы с таск/баг трекером. Его нет. Как нет и системы хранения заданий и версионирования решений. Следовательно, вы не можете проследить историю изменений и основные конструкционные нагрузки на формальные структуры и применяемые алгоритмы. Из этого следует, что при описании никто особо не использует

# Структуры данных

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

# Алгоритмы

Чего проще, указать на схеме "срез последних"? Никогда не было остатков на "конец периода"? Уникальные. Поиск дубликатов. Поиск первого вхождения. Сортировка.

# Классификация

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

# Увеличения уровня абстракции

После каждого (или каждой группы) цикла разработки отчета было бы не плохо увеличивать (стараться это делать) уровень абстракции описания проблемы. Ведь в конечном счете ваша цель в автоматизации. А что может быть приятнее, чем точный ответ на запрос: "Выгрузи самых активных клиентов каждого первого квартала за 10 лет".

Получается, что лучший инструмент, опять карандаш.