“Есть всего 2 типа языков: те, на которые все жалуются и те, которыми никто не пользуется.” — Бьерн Страуструп
Несколько слов в эпистолярном жанре о судьбе программирования для Essbase на CalcScipt. По мотивам статьи «Десять вещей, которые я терпеть не могу в ООП».
CalcScript, как следует из его названия, это язык расчетов данных в многомерной модели, которому чужды такие парадигмы программирования как «процедурность»( данные + алгоритмы, ), «объектность»( объекты + сообщения. ) и «функциональность» (функции + функции). Итого: CalcScript – это работа с данными, которые функционально разложены в многомерной модели или «CalcScript – это расчет данных»
Что данное определение означает с точки зрения прикладного использования: программа расчетов функциональных показателей опирается на значения справочников (метаданных) модели и жестко с ней связана. К чему это приводит , если следовать данному определению буквально : первые реализации программы на CalcScript адекватны только текущему состоянию восприятия задачи программистом, т.е. реализованный расчет находится в состоянии «мертворожденного дитя», так как не может в полной мере адаптироваться к изменению бизнес – требований (из-за умышленного ограничения требуемой «картины мира» ).
К счастью, такая ситуация не является новостью, и эти все проблемы выявляются на этапе «опытно-промышленной» эксплуатации. И при выполнении нескольких условий, есть возможность вдохнуть жизнь в этот «трупик сознания»: в последующих реализациях модели расчетов все больше опираться на признаки метаданных (атрибуты, место в иерархии, составное имя элемента) . Т.е. уйти от модели разработки «CalcScript – это расчет данных» в сторону «процедурности»( данные + алгоритмы) или «CalcScript – это получение данных и расчет ». Т.е. предлагается в существующую алгоритмическую область расчетов искусственно внести сущность управления данными.
Как подход к разработке «CalcScript – получение данных и расчет » выглядит в реальной жизни:
-
На уровне описания функциональных требований и документации: Для каждого алгоритма описывается часть «Источник данных(получение данных)» и «Часть расчет» . Например
- Шаг 1. Получить данные по оборотам (Форма 0101 Движение расходных материалов.))
- …..
- Шаг N. Рассчитать Остаток на конец = Остаток на начало + Движение материалов
- ….
- На уровне модели отдельно выделяется срез исходных данных и срез расчетов и корректировок. Для этого выделяется аналитика с соответствующими элементами (ближайший аналог направление «Value» в Hyperion Financial Management).
-
Для каждого алгоритма выделяют отдельное графическое правило (которое состоит из множества скриптов) , в котором часть «источник данных» описана как получение среза данных через функции отношения элементов в иерархии с определенным набором признаков
- Т.е. для выборки определенного элемента в справочнике используется не его семантическое значение («А1», «A2» .. ), а его функциональная часть (все элементы, помеченные как центр расходов и относящиеся к региону «Восток»)
- Часть «расчет» представляет собой отдельный скрипт, который инкапсулируется в нужных местах общего правила. Его реализация должна описывать алгоритм расчета, а не расположение элементов в модели.
Описанный подход требует особой дисциплины разработки, так как ничто не мешает программисту «упасть» в хардкод.
З.Ы. Перенос расчета из Essbase в PL-SQL физически разделяет слои «Получение данных» и «Расчет»
