Управление бизнес-логикой с помощью символьных вычислений

Руслан Шевченко
Email: rssh@gradsoft.com.ua

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

1. Введение.

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

Посмотрим на типичную структуру распределенного приложения. Мы увидим следующие части:

Все это обычно собранно в один пакет, с помощью определенной стандартной инфраструктуры, такой как сервер приложений или CCM контейнер внедрения. В процессе разработки приложения нам доступны высокоуровневые технологии моделирования (UML, OOD), позволяющие разработчику быстро и аккуратно описать предметную область, нам доступны RAD технологии для быстрого построения интерфейса пользователя, но в то же время у нас нет высокоуровневых технологий для описания собственно бизнес-логики приложения. То есть у нас есть техники для всего, кроме ответа на вопрос: что наше приложение должно делать. Существуют ряд подходов, но все они пока трудно применимы на практике - если мы пытаемся использовать UML, то случаи использования неконструктивны, а диаграммы состояния слишком низкоуровневны. IDEF тоже неконструктивен - он предназначен только для понимания. Существуют стандарты описания бизнес-процессов основанные на XML , такие как WSDL и BPML, но стоимость поддержки нетривиальной спецификации на XML сравнима со стоимостю поддержки соответствующей программы на 3GL языке.

Мы можем сказать, что в современном процессе разработки ПО именно описание бизнес-логики является бутылочным горлышком, сдерживающим скорость изменений ПО. Что можно сделать -- мы предлагаем следующий путь: построить и использовать для описания бизнес-логики некоторый стандартный элемент архитектуры, основанный на символьной логике. Действительно, в компьютерных науках символьная логика используется с основания.

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

2. TermWare: окружение символьной логики, встраиваемое в приложение.

TermWare [RS02, SD03] это расширяемая среда для символьных вычислений, основанная на переписывании термов и поставляемая в виде Java библиотеки. Две основные части этой среды:
1) основные структуры данных и алгоритмы для технологий переписывания, такие как термы, переписывающие правила, унификация, стратегии применения правил и др.
2) механизмы для расширения TermWare: добавления парсеров для язіков программирования, правил переписывания и процедурных описаний действий, вызываемых из правил переписывания.

Формальное описание семантики TermWare можно найти в [RS02], здесь мы ограничимся беглым обзором основных концепций. В мире переписывающих систем TermWare занимает промежуточное положение между генераторами разбора, такими как ATerm+ASDF [Br00] или FermaT [Wa95] с одной стороны, и системами алгебраического программирования, такими как Maude [Wi93] или APS [Ka95] с другой стороны. В отличие от первой группы, термы в TermWare не просто деревья разбора, а настоящие термы в алгебраическом смысле, со встроенной унификацией, пропозициональными переменными и проч. Основные отличия от второй группы заключаются в том, что TermWare не является полностью-определенной формальной системой и не предоставляет полного окружения программировагия; TermWare оформленна не как интерпритатор или транслятор, но как библиотека для встраивания в приложения. Основными объектами TermWare являются так называемые "Системы термов", занимающие такую-же роль, как классы в объектно-ориентированном программировании. Что такое термальная система - набор переписывающих правил плюс взаимодействие с внешним миром, который выглядит в логическом окружении как дедуктивная немонотонная база фактов.

2.1 Встраивание семантики приложения в среду логики.

Обычно мы думаем о приложении в терминах объектной модели, когда мы думаем о бизнес-логике, мы думаем с точки зрения логики. Вопрос - как связать эти две модели мышления:
1. Уровень постоянного хранения и основные сущности могут быть отображены в логической среде как база знанией.
2. Уровень представления, т. е. взаимодействие с пользователем, может быть отображено как набор оракулов.

То есть не просто логика, но логика с поведением. С точки зрения теории систем, поведение приложения может быть представлено как функция: X × E × S → Y × S × E′ где X, Y это соответственно входные и выходные реации, S это состояние и E - окружение. И процесс определения логического описания прикладной логики может быть представлен как следующая последовательность шагов:
1) отображаем входные воздействия в множество возможных входных термов;
2) отображаем действия (выходные воздействия) в множество выходных термов;
3) отображаем сущности модели в базу знаний.

Высокоуровневое представление терминальной системы это четверка < S,E, φs, φe > где S= < St, Sr > пара из множеств термов St и множества активных переписывающих правил Sr, E это представление внешней среды в системе; φs : S × X × E → S × Y эта функция переходов системы, φe: E × Y → E это функция реакции внешней среды. Функция переходов системы определяется набором переписывающих правил и стратегией их применения. Правило это четверка в форме (x, ein) → (y, eout), где x, y это входные и выходные термы, ein это запрос к внешней среде и eout это операция влияния на внешнюю среду .

2.2 Встраивание логической среды в инфраструктуру приложения.

Сейчас обратим внимание на техническую сторону дела: как правила будут применяться внутри приложения. TermWare поставляется не как стандартное приложение, но как Java библиотека, предоставляющая программисту строить и выполнять термальные системы. Что такое термальная система с точки зрения логики мы описали выше. А с точки зрения физики, это просто совокупность

Системы термов могут быть организованны в иерархические пространства имен, использовать определения друг из друга в объектно-ориентированном стиле и создаваться из уже существующих с помощью таких опреаций, как суперпозиция или декартовое произведение. Для разработчика Java приложения системы термов выглядят как экземпляры класса Java ItermSystem со следуйщей сигнатурой:

public class ITermSystem
{
public ITermSystem(ITermRewritingStrategy strategy,

                     IFacts facts,
                     IEnv   env);

  ...

  public boolean checkFact(ITerm t) throws TermWareException;

  public void setFact(ITerm t) throws TermWareException;

  public void addRule(ITerm t) throws TermWareException;

  public ITerm reduce(ITerm x) throws TermWareException;

  ......
 
};

ITerm это Java инкарнация алгебраических термов. Разработчик приложения может создавать экземпляры термов из строк или потоков ввода с помощью средств разбора, включенных в библиотеку.

База знаний представленна интерфейсом IFacts:

public interface IFacts
{     
                              
 public String   getDomainName();

 public boolean  check(ITerm t) throws TermWareException;

 public ITerm    ask(ITerm t) throws TermWareException;

 public void     set(ITerm t) throws TermWareException;
                  
 public void     remove(ITerm t) throws TermWareException;
                             
}

Обычно работа IFacts в приложении состоит в отображении операций над термами в операции над реляционной БД и операции интеракции с пользователем.

Стратегия это алгоритм применения переписывающих правил. TermWare предоставляет пользователю множество предопределенніх стратегий, которые можно использовать а приложениях.

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

3. Пример приложения

Проиллюстрируем обработку бизнес-процессов с помощью TermWare на следующем примере:

System(BugFixing,DevelopmentProcess,
 ruleset(

 received($bug_id) -> check_confirmation($bug_id) 
                                 // human_task(check_bug($bug_id)),

 check_confirmation($bug_id) [|confirmed($tester,$bug_id)|]
                          -> known($bug_id)
                                 // human_task(fix_bug($bug_id),
                                               write_regression($bug_id)
                                              ),

 check_confirmation($bug_id) [|not_confirmed($tester,$bug_id)|]
                          -> true // send_not_confirmed($bug_id,$tester),


 known($bug_id) [|
                                fixed($developer1, $bug_id) && 
                                added_regression($developer2,$bug_id)
                            |]
                               -> true // send_closed($bug_id,$developer1)
 ),
 FirstTop)

Этот пример описывает бизнес-процесс. Читатель может догадаться что это процесс обработки сообщений от пользователей во время сопровождения програмного пакета. Обратите внимание на обращение к БД фактов, которые отвечают на следующие вопросы:

И могут интерпретировать следующие сообщения:

Заметьте, что данные из окружения передаются в систему переписывающих правил посредством заполнения пропозициональных переменных в условиях.

Со стороны Java отображение логической унификации в обращение к реляционной БД может быть выраженно следующим образом:

class DevelopmentProcessFacts extends DefaultFacts
{

  /*
  * $x$ person confirmed $y$ error message
  */
  boolean check_confirmed(ITerm x,ITerm y) throws TermWareException
  {                          
   BindSet bs= getEnv().dbPool().createBindSet();
   bs.add(y.getAsInt());
   ResultSet rs = getEnv().dbPool().evaluate(
        "select confirmator_id from bugs_confirmed where bug_id=?"
                                            );
   if (rs.getLength()==0) return false;
   else if (x.isX()) {
     x.set(ITermParser.createInt(rs.getAsInt(0))); 
     return true;
   }else {
     return x.getAsInt()==rs.getAsInt(0);
   }
  }

..........

};

Когда TermWare обрабатывает в условии логический терм check_confirmed, она вызывает соответствующий метод из БД фактов, используя Java API рефлексии. Взаимодействие с пользователем может быть организованно с помощью workflow-инфраструктуры приложения:

class DevelopmentProcessFacts extends DefaultFacts
{

 ..............

  /*
  * ask somebody to perform $x$
  */
  boolean set_human_task(ITerm x) throws TermWareException
  {                          
   for(int i=0; i<x.arity(); ++i) {
      getEnv().workflow().put("unassigned",generateTaskURL(x.getSubtermAt(0)));
   }
  }

..........

};

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

4. Выводы

В этой работе предлагается новый подход к описанию слоя бизнес-логики с помощью высокоуровнего языка в среде символьных вычислений. Суть подхода в привлечении логических средств для описания и выполнения логической семантики приложения. Это может изменить традиционную технологию разработки приложений - таким образом мы можем элиминировать узкие места традиционной разработки ПО -- низкоуровневое программирование логики приложения можно заменить использованием логических компонент. Разделение поведения и архитектуры прилоджения приводит к возможности изменять поведенческую часть в любой точке жизненного цикла программы. Таким образом реорганизация бизнеса больше не обозначает полное переписывание соответствующего ПО. И последнее -- процесс разработки и уточнения требований может быть более интерактивным.

Дальнейшее развитие этого подхода видится в логической верификации бизнес-правил, автоматизации отображения логических запросов к реляционной БД и построением мостов между логическими правилами и какой-то графической нотации бизнес-процессов, такой как IDEF или UML workflow прфайл.

Система TermWare реализованна в ООО "Град-Софт", и во время написания этой статьи находится в стадии адаптации к применению в реальных проектах. Более детальное описание и некоторые приложения доступны на нашей Web-странице: http://www.gradsoft.kiev.ua

Библиография

[Br00]

M. G. J. van den Brand, H. de Jong, P. Klint, and P. Olivier. Efficient annotated terms, Software, Practice & Experience, 30(3):259-291, 2000.

[CO99]

The Common Object Request Broker: Architecture & Specification", OMG,1999,formal/99-10-07.

[Ga95]

Gamma E. Helm R. Jonhson R. Vlissides J. Design Patterns: Elements of Reusable Object Oriented Software, Addison-Wesley, 1995.

[Ka95]

J.V.Kapitonova A.A.Letichevsky M.S.L'vov and V.A.Volkov, Tools for solving problems in the scope of algebraic programming, LNCS, vol. 958, Springer- Verlag,1995.

[Li00]

D.Liang, M.J. Harrold, Light-Wight Context Recovery for Efficient and Accurate Program Analysis, ICSE 2000, Proc. 22-nd Int. Conf. Software Engineering, June 4-11, 2000, Limerick, Ireland, ACM Press, 2000, pp. 366-406.

[SH02]

R. Shevchenko, A. Doroshenko, A time cost model for distributed objects parallel computation. Future Generation Computer Systems, 18, (2002) 807-812. 17.

[RS02]

R. Shevchenko, TermWare: Semantics Description, GradSoft Ltd, Kiev, Ukraine, GradSoft-TermWare-e-Sm-7.10.2002.1, 2002, http://www.gradsoft.kiev.ua

[SD03]

R. Shevchenko, A. Doroshenko, Symbolic Transformations Framework for Distributed Systems Analysis, submitted for "Parallel Computing Technologies" conf., Sept. 2003, Novosibirsk, Russia.

[SD02]

R. Shevchenko, A. Doroshenko, Evolution of CORBA Framework: An Experience Study, Case studies of CSMR 2002, Workshop Proc. 6-th European Conf. on Software Maintenance and Reengineering, March 11-13, 2002, Budapest, Hungary,2002,pp.3-9.

[SD01]

R. Shevchenko, A. Doroshenko,A Method of Mediators for Building Web Interfaces of CORBA Distributed Enterprise Applications, Lecture Notes in Informatics, vol. 4, Proc. Int. Conf. ISTA-2001 on Information Systems Technology and its Applications, June 13-15, 2001, Kharkiv, Ukraine (M. Godlevsky, H. Mayr, eds.), Gesellschaft fuer Informatik, 2001, pp. 53-63.

[SH01]

Shevchenko, A. Doroshenko, Techniques to Increasing Performance of CORBA Parallel Distributed Applications, in PACT-2001, Proc. 6-th Int. Conf. on Parallel Computing Technologies, Novosibirsk, Russia,2001 , LNCS, 2001 , vol. 2127.- pp. 319-328.

[UM00]

Unified Modeling Language (UML) v 1.4, Object Management Group, 2001,formal/2001-09-67.

[Vi01]

E. Visser. Stratego: A language for program transformation based on rewriting strategies. System description of Stratego 0.5. In A. Middeldorp, editor, Rewriting Techniques and Applications (RTA'01), LNCS, vol. 2051, pp. 357-361, Springer- Verlag, 2001.

[Wa95]

M. Ward and K.H. Bennett, Formal Methods to Aid the Evolution of Software, International Journal of Software Engineering and Knowledge Engineering, Special Issue on "Software Evolution", 1995, vol. 5, No 1, pp 25-47.

[Wi93]

T. Winkler, Programming in OBJ and Maude, in Peter Lauer, ed., Functional Programming, Concurrency, Simulation and Automated Reasoning,1993, LNCS, Springer-Verlag, vol. 693, pp.229-277.