CC BY
99
Сер. 10. 2010. Вып. 1
ВЕСТНИК САНКТ-ПЕТЕРБУРГСКОГО УНИВЕРСИТЕТА
УДК 004.414+004.415+004.416
М. А. Бульонков, П. Г. Емельянов, Н. К. Тарабухина
BUSINESS RULE MANAGER - СРЕДСТВО АНАЛИЗА БИЗНЕС-ЛОГИКИ СТАРЫХ ПРИЛОЖЕНИЙ
Введение. Многие из используемых в настоящее время бизнес-приложений создавались в течение не одного десятка лет и до сих пор требуют постоянной поддержки и модернизации. Для этого необходимо понимание их бизнес-логики, информация о которой часто оказывается фрагментарной. Процесс восстановления бизнес-логики программных систем с учетом их размера непосилен для человека и нуждается в автоматизации. Опыт показывает, что полная автоматизация невозможна ввиду как возникающих алгоритмических проблем, так и потому что требуется непосредственное участие бизнес-аналитика, владеющего знанием предметной области. Тем не менее, инструментальная поддержка процесса анализа чрезвычайно важна.
Существует множество средств работы с бизнес-правилами, но большинство из них ориентировано на построение приложения на основе бизнес-правил, заданных человеком. Нас же интересует в некотором роде обратная задача - построение бизнес-правил на основе существующего приложения.
В данной статье рассматривается средство решения такой задачи - компонент Business Rule Manager системы Relativity Modernization Workbench компании Relativity Technologies, в разработке которой авторы принимали активное участие на протяжении многих лет [1-7]. Эта система специализируется на анализе старых приложений, написанных на языках COBOL, PL/I, Natural, JCL и др. Заметим, однако, что задача восстановления бизнес-логики по программному коду может быть применима к любому языку программирования, поэтому все решения, использованные в вышеназванном инструменте, могут быть использованы и для других языков.
В п. 1 будет сформулировано определение понятия бизнес-правила и рассмотрены вопросы стандартизации. В п. 2 кратко сформулирована задача восстановления бизнес-логики. В п. 3 описан собственно компонент Business Rule Manager, в котором реализовано решение данной задачи. В п. 4 приведен ряд аналогичных разработок.
Бульонков Михаил Алексеевич — кандидат физико-математических наук, заведующий лабораторией смешанных вычислений Института систем информатики СО РАН имени А. П. Ершова. Количество опубликованных работ: 65. Научные направления: смешанные вычисления, семантический анализ программ, реинжиниринг программных систем, информационные системы. E-mail: mike@iis.nsk.su.
Емельянов Павел Геннадьевич — кандидат физико-математических наук, старший научный сотрудник лаборатории смешанных вычислений Института систем информатики СО РАН имени А. П. Ершова. Количество опубликованных работ: 20. Научные направления: семантический анализ программ, реинжиниринг программных систем, информационные системы, дискретные экстремальные задачи, вычислительные методы дискретной математики. E-mail: emelianov@iis.nsk.su.
Тарабухина Надежда Константиновна — младший научный сотрудник лаборатории смешанных вычислений Института систем информатики СО РАН имени А. П. Ершова. Количество опубликованных работ: 8. Научные направления: семантический анализ программ, реинжиниринг программных систем. E-mail: nadinev@iis.nsk.su.
© М. А. Бульонков, П. Г. Емельянов, Н. К. Тарабухина, 2010
В заключении сформулированы основные достоинства предложенного средства.
1. Понятие бизнес-правила и вопросы стандартизации. Понятие бизнес-правила возникло в 1980-х годах. С тех пор было предложено несколько версий его определения, создавались различные группы и сообщества (такие как Business Rules Group, Business Rules Community), предлагались способы задания и хранения бизнес-правил, разрабатывались стандарты.
В процессе изучения данного понятия бизнес-правилом называли [8, 9]:
1) утверждение, которое определяет или ограничивает некий аспект бизнеса;
2) директиву, предназначенную для управления поведением бизнеса;
3) атомарную часть переиспользуемой бизнес-логики;
4) набор условий, которые управляют деловым событием, чтобы оно происходило так, как нужно для предприятия.
В процессе развития подхода к разработке систем, основанного на бизнес-правилах, создавались различные модели бизнес-правил. Собственный метод классификации бизнес-правил предложил Рональд Росс [10, 11]. Рассматривались возможности использовать расширение уже существующего языка моделирования UML [12], моделировать бизнес-правила как метаданные [13]. Разрабатывались специальные языки для стандартизации описания бизнес-правил, такие как RuleML (Rule Markup Language), BRML (Business Rules Markup Language). В начале 2008 г. организацией Object Management Group был утвержден стандарт «Семантика бизнес-словаря и бизнес-правил» [14]. В нем особо отмечено, что он предназначен в первую очередь для бизнес-аналитиков, а уже потом для реализации в программных системах.
В компоненте Business Rule Manager, которому посвящена настоящая статья, бизнес-правила строятся на основе кода программы и далее могут быть отредактированы бизнес-специалистами. Используемая в компоненте модель бизнес-правил была разработана с учетом специфики программных систем и отличается от вышеупомянутого стандарта. Она (рис. 1) содержит три основных элемента: бизнес-функцию (Business Function), множество бизнес-правил (Business Rule Set), называемое также бизнес-процедурой, и собственно бизнес-правило (Business Rule). Каждый из основных элементов может иметь входные и выходные данные (Business Rule I/O). Кроме этого, исполнение любого бизнес-правила, бизнес-процедуры и бизнес-функции может управляться условием (Business Rule Condition). Процесс модификации бизнес-правила отражается с помощью журнала активности (Rule Activity Log).
Рис. 1. Модель бизнес-правил, используемая в компоненте Business Rule Manager
Под бизнес-функцией в данной модели понимается руководство неким законченным действием. Например, бизнес-функция может содержать способ вычисления
скидки для клиента. Бизнес-функция реализуется (IsImplementedBy) с помощью одной или нескольких бизнес-процедур, каждая из которых соответствует более мелким действиям. Например, бизнес-процедура может вычислять разные составляющие суммируемой скидки. Она содержит (Contains) одно или несколько бизнес-правил, каждое из которых можно считать элементарной операцией. Бизнес-правило может производить изменение или проверку данных или вызывать (Triggers) исполнение бизнес-процедуры, причем одна и та же бизнес-процедура может вызываться для исполнения несколькими бизнес-правилами.
2. Задача восстановления бизнес-логики. Понимание бизнес-логики программы необходимо для ее эффективного использования и сопровождения. Однако для множества старых приложений одним из основных источников становится исходный код. Знания предметных специалистов также необходимы, но они полезнее в ответе на вопрос о том, как система должна работать, а не как она действительно работает. Вполне возможно, что не все изменения, произошедшие в бизнесе, были корректно отражены в приложении.
Таким образом, возникает задача восстановления бизнес-логики, для решения которой необходимо проанализировать код и отделить требования предметной области от особенностей реализации. Первые должны проверяться и изменяться бизнес-специалистами, вторые редактируются программистами.
Business Rule Manager решает задачу восстановления бизнес-логики с целью документирования и сопровождения приложения и допускает различные степени автоматизации процесса: от возможности просматривать код и создавать бизнес-правила вручную до проверки и редактирования автоматически построенного набора правил.
3. Система управления бизнес-правилами Business Rule Manager. Business Rule Manager - это компонент системы Relativity Modernization Workbench, предназначенный для создания и изменения бизнес-правил. Подобные инструменты называют системами управления бизнес-правил (Business Rules Management Systems). Они должны удовлетворять следующим требованиям [15]:
• предоставлять сервисы для хранения, просмотра, изменения, защиты и восстановления данных, называемые сервисами репозитория;
• управлять жизненным циклом бизнес-правила: создание, замена, удаление и т. п.;
• проверять бизнес-правила на соответствие стандартам (логическая корректность) и оценивать их действенность в бизнесе.
Рассмотрим, как эти и другие функциональности реализованы в компоненте Business Rule Manager.
3.1. Возможности инструмента Business Rule Manager. Помимо функциональностей, стандартно предоставляемых системами управления бизнес-правилами, Business Rule Manager позволяет осуществлять:
• поиск по различным атрибутам бизнес-правил;
• групповое редактирование бизнес-правил;
• копирование и перемещение бизнес-правил;
• валидацию сегментов - проверку на соответствие сегмента бизнес-правила и редактированного кода;
• автоматический поиск входных и выходных данных бизнес-правила;
• подстановку терминов предметной области вместо имен;
• автоматическое построение бизнес-правил;
• экспорт и импорт бизнес-правил с использованием формата XML.
Большинство из указанных возможностей помогают редактировать уже созданные бизнес-правила и облегчают их создание вручную, когда анализ кода проводится пользователем с помощью других компонентов системы. Наибольший интерес представляет автоматическое построение бизнес-правил, при котором анализ кода проводится системой, а пользователю остается только задать параметры анализа и при необходимости отредактировать построенные правила.
3.1.1. Ж изненный цикл бизнес-правила. Согласно модели, используемой в компоненте Business Rule Manager и описанной в п. 1, бизнес-правило содержится в бизнес-процедуре, которая реализует бизнес-функцию. Таким образом, для создания бизнес-правила в компоненте необходимо сначала создать бизнес-функцию и бизнес-процедуру.
Бизнес-функция имеет следующие основные атрибуты: имя, описание и предметная область (Business Area), бизнес-процедура и бизнес-правило - только имя и описание. Помимо основных атрибутов, все элементы обладают статусными атрибутами, которые заполняются бизнес-аналитиком и при создании элементов получают значения по умолчанию. К предопределенным статусным атрибутам относятся: тип (classification), проверка (audit), состояние (status) и актуальность (transition). Они, как следует из их названия, определяют текущий статус элемента. Например, бизнес-правило может быть вычислительное (тип), подтвержденное (проверка), действующее (статус), устаревшее (актуальность). Для любого элемента можно задать входные и выходные данные и условия выполнения.
Бизнес-правило может быть задано без указания соответствующего сегмента кода, но обычно это подразумевает, что сегмент будет указан позже. Хотя бизнес-правило может не иметь привязки к коду, если оно предназначено только для вызова исполнения некоторой бизнес-процедуры. Если сегмент кода был определен неверно, его можно заменить. Замена сегмента может быть необходима также в случае, если код был модифицирован после создания бизнес-правила.
В любой момент бизнес-функция, бизнес-процедура и бизнес-правило могут быть удалены. При этом бизнес-процедура удаляется вместе с содержащимися в ней бизнес-правилами, а бизнес-функция - вместе с реализующими ее бизнес-процедурами.
Если пользователь хочет сохранить только часть бизнес-правил данной бизнес-процедуры, он может как удалить только нежелательные правила, так и применить к сохраняемым правилам операцию копирования или перемещения в другую бизнес-процедуру с последующим удалением исходной бизнес-процедуры. Операции копирования и перемещения могут применяться и к бизнес-процедурам. Другой способ сохранения построенных бизнес-правил - операция экспорта в файл формата XML. Созданный в результате файл может быть импортирован в другой проект или даже использован для обмена бизнес-правилами с иными приложениями.
3.1.2. Проверки бизнес-правил. Business Rule Manager не предоставляет автоматического метода проверки логической корректности бизнес-правил и их действенности в бизнесе. Подобные проверки совершаются бизнес-аналитиком, и их результат заносится в статусные атрибуты бизнес-правил.
Автоматический метод, предоставляемый компонентом, позволяет проверять соответствие сегмента бизнес-правила текущему состоянию кода и называется валидацией сегмента. В случае редактирования кода после присваивания сегмента бизнес-правилу валидация сегмента позволяет определить, является ли данный сегмент корректным на текущий момент. Очевидно, что это частный случай задачи поиска по образцу, где образцом является сегмент бизнес-правила, а текстом - код программы.
Поскольку задача поиска по образцу изучается давно, для ее решения разработаны различные алгоритмы. Нами были рассмотрены [6] и реализованы: наивный алгоритм с предварительной обработкой шаблона, наивный алгоритм с использованием редакционного расстояния и алгоритм множественного поиска с применением суффиксных деревьев. Каждый из алгоритмов имеет некоторые преимущества, поэтому допускается выбор любого из них с помощью задания соответствующей опции.
3.1.3. Поиск по атрибутам и групповое редактирование. Business Rule Manager позволяет осуществлять поиск бизнес-функций, бизнес-процедур и бизнес-правил. Критерии поиска строятся на основе атрибутов данных элементов. Для задания значения атрибута используются операторы =, <, like и их отрицания. Возможен уточняющий поиск на результатах предыдущего поиска, а также поиск с учетом имеющихся вызовов бизнес-процедур.
К любому множеству бизнес-правил, в том числе и к результатам поиска, можно применить групповое редактирование. Данная операция позволяет изменить значение конкретного атрибута у всего множества одновременно. Еще одна возможность - задать атрибуты множества, взяв за образец указанное бизнес-правило.
3.1.4. Обнаружение входных и выходных данных и подстановка терминов предметной области. Для бизнес-правил, имеющих привязку к коду, Business Rule Manager позволяет автоматически обнаруживать набор входных и выходных данных. При этом к сегменту бизнес-правила применяется анализ потоков данных, производимый другими компонентами системы.
Еще одним из компонентов является бизнес-словарь, или глоссарий, который сопоставляет программным конструкциям (в частности, переменным) термины предметной области. Business Rule Manager обладает функциональностью подстановки данных терминов во входные и выходные данные, а также в имена бизнес-правил и условий. Подстановка терминов вместо имен переменных делает имя бизнес-правила близким к предложению на естественном языке, что облегчает задачу для бизнес-аналитика, работающего с системой.
3.1.5. Автоматическое создание бизнес-правил. Помимо интерфейса для создания бизнес-правил аналитиком, Business Rule Manager предоставляет несколько способов автоматического создания бизнес-правил: генерацию по шаблону, валидацию экранных портов и автоматическое восстановление вычислений. Валидация экранных портов и автоматическое восстановление вычислений основываются на результатах потокового анализа, предоставляемых отдельным компонентом системы.
Генерация по шаблону позволяет на основе набора программных конструкций, выбранных вручную пользователем или полученных автоматически средствами системы, создавать бизнес-правила с заданным шаблоном имени и набором атрибутов. Бизнес-правила будут помещены в указанную бизнес-процедуру. Код каждой конструкции будет сегментом соответствующего бизнес-правила.
Этот способ можно отнести к слабой автоматизации, поскольку анализ кода - поиск необходимых конструкций - проводится пользователем с помощью других компонентов системы, автоматизация касается лишь непосредственного создания бизнес-правил из каждой заданной конструкции.
Два других способа предоставляют сильную автоматизацию: проводится автоматический анализ специального информационного графа, который строится системой на основе анализа потоков данных, а также содержит дополнительную информацию об условных зависимостях, полученную на основе анализа потоков управления.
Автоматическое восстановление вычислений [5] строит набор бизнес-правил, последовательное выполнение которых (с учетом условий их выполнения) вычисляет заданную переменную.
Метод использует граф информационных зависимостей, ведущих к переменной. Вершинами графа являются переменные, необходимые для вычисления выбранной, т. е. такие переменные, значения которых либо явно используются в вычислениях, либо контролируют их. Для каждой переменной программа может определить охватывающую конструкцию языка: оператор или условие. В соответствии с этим переменные первого типа можно назвать операторными, а второго - условными. Соответственно граф имеет два типа ребер: информационные и условные. Информационные ребра соответствуют информационным зависимостям в программе: ребро из А в В показывает, что переменная В зависит от переменной А, т. е. для вычисления значения В используется значение А. Условное ребро из А в В означает, что вычисление значения переменной В зависит от значения переменной А. В этом случае А является контролирующей переменной для вычисления переменной В.
Бизнес-правила создаются из операторов, поэтому, имея граф переменных, метод восстановления вычислений на его основе строит операторный граф. Это несложно сделать переходом к охватывающим конструкциям. Вершины исходного графа, соответствующие переменным одного оператора или условия, объединяются в одну операторную вершину. Одному условию могут отвечать две вершины: для собственно условия и для его отрицания. В результате каждая вершина операторного графа обозначает либо оператор, либо условие, либо отрицание условия. Ребра также поднимаются на операторный уровень: если в исходном графе есть ребра, соединяющие переменные из двух операторов, то создается ребро между операторными вершинами. Описанное преобразование позволяет получить граф, который содержит информацию обо всех операторах, используемых для вычисления выбранной переменной, зависимостях по данным между операторами и зависимостях от условий. Заметим, что при переходе от вершин-переменных к вершинам-операторам в последние записывается вся информация о переменных оператора как о его входных и выходных данных.
Информационный граф представлен таблицей ребер. Построение операторного графа проводится в два прохода этой таблицы: сначала создаются все вершины, потом все ребра. Таким образом, сложность указанного шага линейна по числу ребер исходного графа. Однако необходимо отметить, что сложность реализации определяется также поиском охватывающих конструкций для каждой переменной. Вся необходимая информация хранится в специальной базе данных системы, и время доступа к таблицам может быть значительным для большого проекта. Кроме того, в целях уменьшения обращений к базе данных, вся информация, используемая далее, собирается в вершины операторного графа. Более точно: основным элементам модели бизнес-правил соответствуют классы, которые хранят все нужные атрибуты. Таким образом, происходит ускорение последующих шагов метода, но построение операторного графа становится самым затратным и по времени сравнимо с построением информационного графа на основе потокового анализа.
Условия исполнения операторов приписываются к бизнес-правилам в качестве дополнительной информации. Поэтому следующим шагом предлагаемого метода является нахождение корректных условий исполнения путем распространения информации с условных вершин на операторные. При проходе через условную вершину в нее собираются условия с входящих в нее ребер и вместе с условием, хранящимся в вершине, передаются на все выходящие ребра. Для операторных вершин собираются все условия
с входящих условных ребер. Для того чтобы к моменту обработки вершины на входящих в нее ребрах уже была записана вся необходимая информация об условиях, граф обходится по уровням, начиная с самого верхнего. Множество условий верхнего уровня может быть создано уже в процессе построения графа, это условные вершины, не имеющие входящих ребер.
Очередной из задач, решаемых в процессе автоматического построения последовательности бизнес-правил, является задача их корректного упорядочения. Последовательность мы будем называть корректной, если выполнение всех ее бизнес-правил (которые в рассматриваемом случае соответствуют операторам) подряд приводит к такому же результату, который выдает исходная программа. Задача корректного упорядочения сводится к задаче обхода ациклического операторного графа с учетом возможности конфликта между вершинами: если одна вершина вычисляет ту переменную, которую использует другая, то вершины должны быть пройдены в строго определенном порядке для обеспечения корректности. Более подробное описание используемого алгоритма выходит за рамки данной статьи.
В реальных приложениях количество бизнес-правил исчисляется сотнями, и демонстрировать их в виде линейной последовательности неудобно для восприятия. Потому на заключительном этапе предлагается группировать бизнес-правила по некоторым признакам и в исходной последовательности заменять их специальными бизнес-правилами, ссылочными на соответствующие группы. Такие группы бизнес-правил являются аналогами процедур в языках программирования, поэтому в модели они названы бизнес-процедурами. Ссылочные бизнес-правила, или триггеры, служат аналогами вызовов процедур. Возможны различные критерии выделения бизнес-правил в бизнес-процедуры. В текущей реализации предлагается использовать три критерия группировки бизнес-правил. Во-первых, при наличии межпрограммных вызовов в процессе вычислений бизнес-процедуры создаются из вызываемых программ. Во-вторых, группируются операторы из заданных пользователем программных блоков (например, для языка COBOL в качестве блока выступает параграф). В-третьих, объединяются в группы бизнес-правила с одинаковыми условиями выполнения с целью минимизировать повторение одного и того же условия. Данные критерии применяются последовательно: сначала создаются бизнес-процедуры из вызываемых программ, далее уже на уровне бизнес-процедур работает сначала второй критерий, а затем и третий.
Продемонстрируем работу метода на небольшом примере. Рассмотрим фрагмент программы на языке COBOL, вычисляющий скидку по некоторым правилам:
INIT.
MOVE 0 TO DISCOUNT-FACTOR1 DISCOUNT-FACTOR2.
IF UPDATE-NEEDED = "TRUE" THEN IF CURDAY > 5 THEN
COMPUTE DISCOUNT-FACTOR2 = PRICE-0 - 50 MOVE PRICE-0 TO PRICE
ELSE
COMPUTE PRICE = PRICE-0 + 10 END-IF
END-IF.
FACTOR-CALC.
IF I > MAX THEN
GO TO MAIN-CALC.
COMPUTE RES = DISCOUNT-FACTOR1 + CONST. ADD CONSTS TO RES.
COMPUTE DISCOUNT-FACTOR1 = RES * 0.25. PERFORM FACTOR-CALC.
MAIN-CALC.
COMPUTE DISCOUNT-FACTOR2 = 0.5 * DISCOUNT-FACTOR2.
COMPUTE DISCOUNT = DISCOUNT-FACTOR1 * PRICE + DISCOUNT-FACTOR2.
Будем восстанавливать вычисление переменной DISCOUNT в последней строке.
Рис. 2. Информационный граф демонстрационного примера
Информационный граф для указанного примера приведен на рис. 2. Здесь выделенные вершины соответствуют условным. Ребро, помеченное знаком ‘+’, показывает, что имеется зависимость от условия, в которое входит данная переменная. Знак ‘—’ означает зависимость от отрицания условия. Например, в случае оператора IF ‘+’-ребро отвечает ветке THEN, а ‘-’-ребро - ветке ELSE.
Построенный далее операторный граф имеет единственный выход, соответствующий оператору с интересующей нас переменной, и несколько входов. Граф может содержать циклы, поскольку ограничения на исходную программу не накладывались. Однако, как показывает практика, подавляющее большинство бизнес-правил не носят циклический характер, поэтому граф преобразуется в ациклический путем разрезания циклов. Цикличность, связанная с исполнением бизнес-правил, реализуется впоследствии с помощью триггеров.
UPDATE-HEEDED = ’’TRUE’
MOVE 0 TO DISCOUNT-FACTOR1 DISCOUNT-F ACTOR2
CURDAY > 5
Not CURDAY > 5
Ш
Ш
COMPUTE DISCOUNT-FACTOR2= PRICE-0 - 50
Ш
V И
Not I > MAX
ш У Г Ш V
COMPUTE RES =
DISCOUNT-FACTOR1 + CONST
COMPUTE PRISE= PRICE-0+10 MOVE PRICE-0 TO PRICE COMPUTE DISCOUNT-FACTOR2= DISCOUNT-FACTOR2*0.5 COMPUTE DISCOUNT-FACTOR 1= RES*0.25
АОО CONSTS ТО RES
И
COMPUTE DISCOUNT = DISCOUNT-FACTOR1 * PRICE + DISCOUNT-FACTOR2
Рис. 3. Упорядоченный операторный граф
Упорядоченный операторный граф показан на рис. 3. Условия исполнения уже собраны в операторные вершины. Достаточно очевидно, что вершины 4, 5, 6 управляются одним условием, а вершины 3, 7, 8 - парой условий.
Отметим, что в рассматриваемом примере для получения корректной последовательности важно, чтобы оператор вершины 9 выполнился раньше, чем оператор вершины 3. Построенный порядок это обеспечивает, поскольку порядок бизнес-правил получается обращением порядка вершин.
В заключение производится группировка бизнес-правил по условиям. Мы объединяем в бизнес-процедуру не менее трех операторов с одинаковыми условиями исполнения. Результат в порядке исполнения (с учетом вызова бизнес-процедур) приведен на рис. 4.
Рис. 4. Результирующие бизнес-правила для вычисления переменной DISCOUNT
Валидация экранных портов [7] реализована для языка COBOL, хотя те же алгоритмы могут быть использованы для других языков. Этот метод строит
бизнес-правила из всех проверок корректности значений, вводимых пользователем и попадающих в программу через операторы обработки экранных форм - экранные порты. Под корректностью значений можно понимать проверку соответствия типов или попадания значения в заданный диапазон. Но поскольку, вообще говоря, нам не известно, какие именно проверки проводились в исходной программе, будем искать всевозможные сравнения значений, переданных в программу с экранной формы, с любыми другими. Также заметим, что проверка значения на корректность может производиться не сразу, а после некоторых преобразований.
С учетом вышесказанного переформулируем задачу более точно: в программе на языке COBOL для указанного экранного порта RECEIVE необходимо найти все условные операторы, в которые можно попасть из переменных этого порта по информационным зависимостям. Кроме того, требуется указать последовательности операторов, ведущие из порта в условный оператор.
Для каждой переменной заданного экранного порта метод рассматривает частичные информационные графы программы, которые строятся для каждой переменной экранного порта на основе анализа потоков данных. Вершинами графа служат переменные, а ребрами - отношения между ними. Процесс построения графа обрывается при попадании в условный оператор. Таким образом, входом графа является переменная порта, а частью выходов - переменные из условных операторов, которые соответствуют интересующим нас проверкам. На основе описанного графа строится операторный граф информационных зависимостей. Более подробно процедура построения такого графа описана выше при рассмотрении метода восстановления вычислений. Отметим лишь, что для данной задачи вход графа - это исходный порт, а выходы - операторы, на которых заканчиваются вычисления, либо условные операторы.
Результатом работы метода является бизнес-функция, реализуемая единственной бизнес-процедурой, которая содержит все бизнес-правила, созданные с помощью обхода операторного графа. Сегментом каждого бизнес-правила служит код условного оператора.
Стоит отметить, что методы сильной автоматизации близки к нарезке слайсов [16, 17]. Однако слайс представляет собой исполняемую программу и содержит много вспомогательной информации, не интересной аналитику. Также в случае межпрограммных вызовов могут быть получены маленькие слайсы, показывающие лишь переход в другую программу. Представление в виде бизнес-правил более удобно для демонстрации целостной картины вычислений.
3.2. Интерфейс инструмента Business Rule Manager. Кратко рассмотрим интерфейсные средства компонента Business Rule Manager. Отметим, что этот компонент обычно используется совместно с компонентом, наглядно демонстрирующим код программы, поскольку для бизнес-правил важна привязка к коду. Средства системы позволяют компонентам работать связанно: так, при выделении бизнес-правила подсвечивается соответствующий ему сегмент кода.
Бизнес-функции, бизнес-процедуры и бизнес-правила отображаются на панели компонента в виде дерева. Все бизнес-процедуры, участвующие в реализации бизнес-функции, отображаются ее потомками в дереве. Аналогично изображается вложенность бизнес-правил в бизнес-процедуру. Вершины, соответствующие различным типам элементов, имеют разные значки. Для наглядности наличие условий выполнения у бизнес-правила обозначается значком вопроса, а бизнес-правила, вызывающие исполнение бизнес-процедуры, - стрелочкой.
Хотя в мире бизнеса считается, что набор бизнес-правил не должен быть упорядоченным, аналитики признают, что программные системы должны определять порядок правильного выполнения бизнес-правил. Поскольку мы рассматриваем последовательность бизнес-правил именно с точки зрения выполнения, Business Rule Manager имеет второе древесное представление бизнес-функции, где бизнес-процедура является потомком того бизнес-правила, которое вызывает ее исполнение (см. рис. 4). И лишь в случае, если для бизнес-процедуры нет таких бизнес-правил, она показывается как потомок бизнес-функции. Перемещение элементов, использующее информацию о вызовах бизнес-процедур, оказывается чрезвычайно полезным для восстановления бизнес-логики.
4. Аналогичные разработки. Прямой процесс, включающий построение бизнес-правил и их дальнейшее применение в разработке приложения, привлек широкое внимание исследователей более 20 лет назад, был хорошо методологически проработан [11, 18] и реализован во многих коммерческих проектах: Rational компании IBM, BizTalk компании Microsoft, Visual Rules компании Innovations Softwaretechnologie GmbH, Corticon Business Rules Modeling Studio компании Corticon, Blaze Advisor компании Fair Isaac, JRules компании ILOG и др.
Однако технологии, реализующие обратный процесс, т. е. извлечение бизнес-правил из существующего программного кода, развиты значительно меньше. Это объясняется рядом возникающих алгоритмических проблем. Однако сегодня данное направление развивается, поскольку количество старых приложений, требующих сопровождения и модернизации, обеспечивает спрос на соответствующие программные продукты.
Предлагаемые программные решения отличаются разными степенями автоматизации процесса и могут быть ориентированы как на трансформацию старых приложений на основе их бизнес-логики [19], так и на их сопровождение [20]. Существует разработка, ориентированная на извлечение бизнес-логики из приложений с трехуровневой архитектурой: пользовательский интерфейс - бизнес-логика - взаимодействие с базами данных [21]. Примерами коммерческих систем служат также SoftwareMining BRE Toolkit компании SoftwareMining, emergeIT компании blackboxIT, X-Analysis компании Databorough, Business Rule Harvester компании Trinity Millennium Group. По сравнению с Business Rule Manager данные продукты имеют следующие недостатки: SoftwareMining BRE Toolkit находит только явные использования заданной переменной, emergeIT предлагает лишь средства слабой автоматизации, X-Analysis строит бизнес-правила только из кода, не относящегося к вводу-выводу, Business Rule Harvester представляет собой набор сервисов, а не законченный продукт.
Заключение. Описанный в данной статье компонент Business Rule Manager системы Relativity Modernization Workbench успешно применяется в работе бизнес-аналитиков, позволяя строить бизнес-правила на основе анализа кода старых приложений.
Business Rule Manager обеспечивает основные функциональности систем управления бизнес-правилами, допускает различные степени автоматизации процесса создания бизнес-правил и, будучи компонентом целостной системы, использует результаты комплексного анализа программного кода. Построенные бизнес-правила могут быть сохранены в формате XML и применены в других приложениях. Хотя целью создания бизнес-правил в данном компоненте является документирование и сопровождение существующего приложения, они также могут быть использованы как база для проектирования нового.
1. Бульонков М. А., Бабурин Д. Е. HyperCode — открытая система визуализации программ // Автоматизированный реинжиниринг программ / ред. А. Н. Терехов. СПб.: Изд-во С.-Петерб. ун-та, 2001. C. 96-106.
2. Бульонков М. А., Бабурин Д. Е., Емельянов П. Г., Филаткина Н. Н. Средства визуализации при перепроектировании программ // Программирование. 2001. № 27. С. 21-33.
3. Bulyonkov M., Filatkina N. Exploring Data Flow in Legacy Systems // Proc. of the Second Asian Workshop on Programming Languages and Systems (APLAS 2001). 2001. P. 61-75.
4. Wadhwa V., Erlikh L., Oara I. et al. Method and system of business rule extraction from existing applications for integration into new applications: US Patent 6389588. Submitted 02/04/1999. Publ. 05/14/2002.
5. Вольхина Н. К. Автоматическое восстановление бизнес-логики программ // Молодая информатика. Новосибирск, 2006. Вып. 2. C. 90-102.
6. Вольхина Н. К. Поиск по образцу для валидации бизнес-правил // Технологии Microsoft в теории и практике программирования: Тез. докл. Новосибирск, 2006. C. 10-11.
7. Бульонков М. А., Тарабухина Н. К. Валидация экранных портов в программах на языке COBOL // VIII Всерос. конференция молодых ученых по математическому моделированию и информационным технологиям: Электронная публикация доклада / Институт вычислительных технологий СО РАН. Новосибирск, 2007. URL: http://www.nsc.ru/ws/YM2007/12731/Tarabukhina.htm.
8. A Brief History of the Business Rule Approach. 2nd ed. // Editors of BRCommuni-ty.com. Business Rules Journal. 2006. Vol. 7, N 11. Business Rule Community, 2006. URL: http://www.BRCommunity.com/a2006/b317.html.
9. Von Halle B. Building a Business Rules System // DM Review. 2001. URL: http://consul-ting.ru/econs_wi_130.
10. Ross R. G. Exploring Business Rules // Business Rule Community. 1999. URL: http://www.brcommunity.com/a439.php.
11. Ross R. G. Principles of the Business Rule Approach. Boston, MA: Addison-Wesley, 2003. 400 p.
12. Haggerty N. Modeling Business Rules Using the UML and CASE // Business Rules Journal. 2000. Vol. 1, N 10. Business Rule Community. URL: http://www.brcommunity.com/b016.php.
13. Perkins A. Business Rules Are Meta Data // Business Rules Journal. 2002. Vol. 3, N 1. Business Rule Community. URL: http://www.BRCommunity.com/ a2002/b097.html.
14. Semantics of Business Vocabulary and Business Rules // Object Management Group. 2008. URL: http://www.omg.org/docs/formal/08-01-02.pdf.
15. Business Rules Approach // Fifth European Business Rules Conference. 2006. URL: http://www.eurobusinessrules.com/download/EBRC2006BRA.pdf.
16. Weiser M. Program slicing // IEEE Transactions on Software Engineering. 1984. Vol. 10, Issue 4. P. 352-357.
17. Krinke J. Program Slicing // Handbook of Software Engineering and Knowledge Engineering. Vol. 3: Recent Advances. World Scientific Publishing, 2005. P. 307-332.
18. Date C. J. What Not How: The Business Rules Approach to Application Development. Boston, MA: Addison-Wesley, 2000. 144 p.
19. Sneed H. Extracting Business Logic from Existing COBOL Programs as a Basis for Redevelopment // Proc. of the 9th Intern. Workshop on Program Comprehension. 2001. P. 167-175.
20. Pocock J. Business rules Mining: Application Support, Enhancement and Forward Engineering // Transoft. 2004. URL: http://www.transoft.com/products/brm.htm.
21. Hung M., Zou Y. Extracting Business Policies and Business Data from the Three-Tier Architecture Systems // Proc. of the Intern. Workshop on Reverse Engineering to Requirements. 2005. URL: http://www.cs.toronto.edu/ km/retr/camera/hung05retr.pdf.
Статья рекомендована к печати проф. А. Н. Тереховым.
Статья принята к печати 29 сентября 2009 г.
