CalcScript : казнить нельзя помиловать (,)

“Есть всего 2 типа языков: те, на которые все жалуются и те, которыми никто не пользуется.” — Бьерн Страуструп

Несколько слов в эпистолярном жанре о судьбе программирования для Essbase на CalcScipt. По мотивам статьи «Десять вещей, которые я терпеть не могу в ООП».

 
 

CalcScript, как следует из его названия, это язык расчетов данных в многомерной модели, которому чужды такие парадигмы программирования как «процедурность»( данные + алгоритмы, ), «объектность»( объекты + сообщения. ) и «функциональность» (функции + функции). Итого: CalcScript – это работа с данными, которые функционально разложены в многомерной модели или «CalcScript – это расчет данных»

Что данное определение означает с точки зрения прикладного использования: программа расчетов функциональных показателей опирается на значения справочников (метаданных) модели и жестко с ней связана. К чему это приводит , если следовать данному определению буквально : первые реализации программы на CalcScript адекватны только текущему состоянию восприятия задачи программистом, т.е. реализованный расчет находится в состоянии «мертворожденного дитя», так как не может в полной мере адаптироваться к изменению бизнес – требований (из-за умышленного ограничения требуемой «картины мира» ).

К счастью, такая ситуация не является новостью, и эти все проблемы выявляются на этапе «опытно-промышленной» эксплуатации. И при выполнении нескольких условий, есть возможность вдохнуть жизнь в этот «трупик сознания»: в последующих реализациях модели расчетов все больше опираться на признаки метаданных (атрибуты, место в иерархии, составное имя элемента) . Т.е. уйти от модели разработки «CalcScript – это расчет данных» в сторону «процедурности»( данные + алгоритмы) или «CalcScript – это получение данных и расчет ». Т.е. предлагается в существующую алгоритмическую область расчетов искусственно внести сущность управления данными.

Как подход к разработке «CalcScript – получение данных и расчет » выглядит в реальной жизни:

  • На уровне описания функциональных требований и документации: Для каждого алгоритма описывается часть «Источник данных(получение данных)» и «Часть расчет» . Например
    • Шаг 1. Получить данные по оборотам (Форма 0101 Движение расходных материалов.))
    • …..
    • Шаг N. Рассчитать Остаток на конец = Остаток на начало + Движение материалов
    • ….
  • На уровне модели отдельно выделяется срез исходных данных и срез расчетов и корректировок. Для этого выделяется аналитика с соответствующими элементами (ближайший аналог направление «Value» в Hyperion Financial Management).
  • Для каждого алгоритма выделяют отдельное графическое правило (которое состоит из множества скриптов) , в котором часть «источник данных» описана как получение среза данных через функции отношения элементов в иерархии с определенным набором признаков
    • Т.е. для выборки определенного элемента в справочнике используется не его семантическое значение («А1», «A2» .. ), а его функциональная часть (все элементы, помеченные как центр расходов и относящиеся к региону «Восток»)
    • Часть «расчет» представляет собой отдельный скрипт, который инкапсулируется в нужных местах общего правила. Его реализация должна описывать алгоритм расчета, а не расположение элементов в модели.

 
 

Описанный подход требует особой дисциплины разработки, так как ничто не мешает программисту «упасть» в хардкод.

З.Ы. Перенос расчета из Essbase в PL-SQL физически разделяет слои «Получение данных» и «Расчет»