KR101864673B1 - 비지니스 룰의 편집 및 컴파일 - Google Patents

Abstract

데이터 흐름을 나타내는 링크 소자에 의해 연결된 데이터 처리 구성요소를 가진 그래프 기반의 연산(130) 내의 구성요소(136, 138, 140)가, 룰 사양(152)를 수신하고, 룰 사양에 기초하여 데이터를 변환하기 위한 변환(156)를 생성하며, 그 변환을 그래프 기반의 연산 내의 구성요소와 연관시키고, 새로운 룰 사양이 수신되었거나 또는 기존의 룰 사양이 편집되었다는 것을 판정한 것에 응답하여 그 새로운 또는 편집된 룰 사양에 따라 그래프 기반의 연산 내의 구성요소와 연관된 변환을 갱신함으로써, 갱신된다.

Description

비지니스 룰의 편집 및 컴파일{EDITING AND COMPILING BUSINESS RULES}

본 발명은 비지니스 룰의 편집 및 컴파일하는 것에 관한 것이다.

복잡한 연산은 종종 유향 그래프(directed graph)를 통해 데이터 흐름으로서 나타내어질 수 있으며, 연산의 구성요소(components)는 그래프의 꼭짓점과 연관되어 있고 구성요소들 간의 데이터 흐름은 그래프의 링크(호, 변)에 대응한다. 이러한 그래프 기반 연산을 실행하는 시스템이 미국특허 제5,966,072호, "EXECUTING COMPUTATIONS EXPRESSED AS GRAPHS"에 개시되어 있다. 몇몇의 경우, 꼭짓점에 연결된 연산은, "비지니스 룰(business rules)"로서 언급되는, 사람이 판독가능한 형태로 기술된다.

일반적으로, 하나의 관점에서, 데이터 흐름을 나타내는 링크 요소에 의해 연결된 데이터 처리 구성요소를 가진 그래프 기반 연산에서의 한 구성요소는, 룰 사양(rule specification)을 수신하고, 이 룰 사양에 기초하여 데이터를 변환하는 변환(transform)을 발생시키고, 이 변환을 그래프 기반 연산에서의 구성요소와 연관시키며, 새로운 룰 사양이 수신되었거나 또는 기존의 룰 사양이 편집되었음을 판정한 것에 응답하여 그 새로운 룰 사양 또는 편집된 룰 사양에 따라 상기 그래프 기반 연산에서의 구성요소와 연관된 변환을 갱신한다.

구현예는 이하의 특징 중 하나 이상을 포함할 수 있다.

룰 사양를 수신하는 것은 룰 사양 테이블의 행(row)을 사용자로부터 수신하는 것을 포함하는데, 그 행은 룰 케이스(rule case)를 정의하며 하나 이상의 입력으로 된 한 세트의 잠재적인 입력 각각에 대한 관계를 포함한다.

룰 사양을 수신하는 것은 또한 사용자로부터 제2 행의 룰 사양 테이블을 수신하는 것을 포함하는데, 이 제2 행의 룰 사양 테이블은 제2 룰 케이스를 정의하고 제2 세트의 하나 이상의 잠재적 입력 각각에 대한 제2 관계를 포함한다. 관계(relationship)는, 임계치와 동등한 값을 갖거나, 임계치 초과의 값을 갖거나, 임계치 미만의 값을 갖거나, 한 세트의 값에 속하는 값을 갖거나, 한 패턴에 매칭되는 값을 갖거나, 다른 입력의 값에 대한 관계를 갖거나, 다른 룰 사양의 출력의 값에 대한 관계를 갖거나, 또는 메모리 내의 하나의 값에 대한 관계를 갖거나, 또는 상기한 것들 중 둘 이상에 해당하는 경우를 포함한다. 상기한 일련의 룰 사양 테이블은 또한 입력 값들 중 하나 이상 또는 그 입력 값들의 조합, 미리 결정된 값, 또는 입력 값들 중 하나 이상으로부터 연산된 값을 포함하는 출력을 포함한다. 하나 이상의 잠재적 입력들에 대한 값을 각각 포함하는 한 세트의 테스트 컬럼을 포함하는 테이블을 수신하고, 그리고 각각의 테스트 컬럼에 있어서, 테스트 컬럼의 입력값들이 부여된 출력을 생성할 일렬의 룰 사양을 식별하고, 그리고 각각의 테스트 컬럼에 있어서 그 식별된 행의 식별을 사용자에게 출력한다. 각각의 테스트 컬럼에 대한 결과 행(results row)를 포함하는 테이블을 생성한다. 각각의 결과 행은 테스트 컬럼의 입력 값들이 부여된 상태에서 발생될 출력을 나타낸다. 테이블을 생성하는 것은, 각각의 결과 행에서, 발생될 출력이 이전 버전의 룰 사양에서 나타났던 출력으로부터 변경된 것인지 여부를 나타내는 것을 포함한다. 결과 행과의 사용자 상호작용에 응답해서, 룰 사양의 어느 룰 케이스가 그 결과 행에서 출력을 생성할지를 나타낸다.

각각의 행의 룰 사양에 대응하는 평가 행(evaluation row)을 포함하는 테이블을 생성하고, 테이블의 각각의 평가 행에서, 각각의 잠재적 입력에 대해, 그 잠재적 입력에 대한 제1 테스트 컬럼이 그 잠재적 입력에 대한 관계를 만족했는지의 여부를 나타내고, 주어진 제1 테스트 컬럼의 입력 값들에 대해 출력을 생성할 룰 사양의 행에 대응하는 평가 행에서, 그 생성될 출력을 나타낸다. 평가 행은 룰 사양의 행들의 순서에 대응하는 순서를 가지며, 그 출력이 나타나는 평가 행은, 잠재적 입력에 대한 각각의 관계가 만족되는 룰 사양의 제1 행에 대응하고, 또 잠재적 입력에 대한 각각의 관계가 만족되는 룰 사양의 행에 대응하는 각각의 평가 행에서 발생될 출력을 나타낸다. 룰 사양의 각각의 행에 대응하는 평가 행을 포함하는 테이블을 생성하고, 각각의 평가 행에서, 룰 사양의 대응하는 행에서 얼마나 많은 테스트 컬럼이 그 관계를 만족하는 입력을 가지는지를 나타낸다. 각각의 테스트 컬럼은 또한 기대 출력값을 포함하고, 각각의 결과 행은, 대응하는 테스트 컬럼의 입력 값들이 주어진 상태에서 발생될 출력이 그 테스트 컬럼에서 그 예측된 출력과 일치하는지를 나타낸다. 각각의 테스트 컬럼에 있어서, 제2 룰 사양의 적어도 하나의 행이 테스트 컬럼의 입력 값들이 부여된 출력을 생성할 것인지를 결정하는 것에 응답해서, 제1 룰 사양 및 제2 룰 사양을 포함하는 룰 세트가 유효한 것으로 판정한다.

각각의 테스트 컬럼에 대한 결과 행을 포함하는 테이블을 생성하고, 각각의 결과 행은 테스트 컬럼의 입력 값들이 주어진 상태에서 룰 사양 중 하나에서의 행에 의해 발생된 각각의 출력을 나타낸다. 제1 테스크 컬럼의 입력 값들이 주어진 상태에서 발생될 출력에 있어서, 그 출력의 생성을 가져올 룰 사양의 입력과 출력 사이의 상호관계의 그래픽 디스플레이를 생성한다. 테스트 컬럼의 테이블을 수신하는 것은 사용자로부터 한 세트의 입력 값을 수신하는 것과, 이 한 세트의 입력 값과 룰 사양의 잠재적 입력 값을 매칭하는 것과, 이 한 세트의 입력 값을 테이블의 컬럼에 저장하는 것을 포함한다. 잠재적 입력 값들의 식별을 디스플레이 하는 것에 응답하여 한 세트의 입력 값을 수신한다. 한 세트의 룰 사양에서의 각각의 룰 사양이 적어도 하나의 출력을 생성할 것으로 판정한 것에 따라, 이 한 세트의 룰 사양이 유효한 것으로 판정한다. 룰 사양이 유효하지 않다는 판정에 응답해서는, 룰 사양이 유효하지 않다는 것을 룰 사양의 소스에 전달한다.

변환을 갱신하는 것은, 룰 사양이 유효하다는 것을 확인하는 단계와, 새로운 또는 편집된 룰 사양에 기초하여 새로운 변환을 생성하는 단계와, 제1 변환을 구성요소와 분리시키는 단계와, 새로운 변환을 구성요소와 연관시키는 단계를 포함한다. 변환을 갱신하는 것은, 룰 사양이 유효하다는 것을 확인하는 단계와, 구성요소가 활성화되었을 때 실행될 그래픽 기반의 연산을 대기하는 단계와, 새로운 또는 편집된 사양 룰에 기초하여 새로운 변환을 생성하는 단계와, 새로운 변환을 구성요소와 연관시키는 단계를 포함한다. 변환을 생성하는 것은, 복수의 논리적 표현을 생성하기 위해 룰 사양 내의 복수의 룰 케이스 각각을 논리 식(logical expression)으로 변환(convert)하는 단계와, 이 복수의 논리 식을 컴퓨터-실행 가능한 코드로 컴파일링하는 단계를 포함한다. 복수의 논리 식을 컴파일링하는 것은, 식을 조합하는 것, 개별의 식을 최저화하는 것, 및 식의 그룹들을 최적화하는 것 중 하나 이상을 포함한다. 복수의 논리 식을 컴파일링하는 것은 이 식들을 그래픽 기반의 연산에서 사용하기에 적절한 구성요소와 연결시키는 것을 포함한다.

일반적으로, 한 측면에 따르면, 잠재적 입력과 대응하는 출력에 대한 관계를 각각 포함하는 한 세트의 룰 케이스를 포함하는 룰 사양을 수신하고, 하나 이상의 잠재적 입력에 대한 값을 각각 포함하는 한 세트의 테스트 케이스를 수신하며, 그리고 각각의 테스트 케이스에 있어서, 테스트 케이스의 입력 값이 주어진 상태에서 출력을 생성할 룰 케이스 중 하나를 식별함으로써, 연산을 테스트한다.

실행은 이하의 특징 중 하나 이상을 포함할 수 있다.

각각의 테스트 케이스에 대한 출력을 생성할 룰 케이스를 식별하는 것에 응답해서, 룰 사양이 유효하다는 것을 나타내는 표시를 저장하거나 출력한다. 각각의 테스트 케이스에 대해 출력을 발생시킬 룰 케이스를 식별하는 것에 응답해서, 발생될 출력의 표시를 저장하거나 출력한다. 한 세트의 테스트 케이스를 수신하는 것은 한 세트의 테스트 컬럼을 포함하는 테이블을 수신하는 것을 포함하며, 각각의 테스트 컬럼은 테스트 케이스 중 대응하는 것에 대한 하나 이상의 잠재적 입력에 대한 값을 포함한다. 각각의 테스트 케이스 및 그 테스트 케이스에 대한 식별된 룰 케이스에 있어서, 그 식별된 룰 케이스에 의해 어떤 출력이 발생될 것인지를 나타낸다. 각각의 테스트 케이스 및 그 테스트 데이터 세트에 대한 식별된 룰 케이스에 있어서, 그 식별된 룰 케이스로 하여금 출력을 발생시키게 한, 테스트 케이스 내의 하나 이상의 입력 값을 식별하고, 또한 각각의 테스트 케이스에 있어서, 테스트 케이스의 값에 의해 만족된 룰 케이스의 관계와 만족되지 않은 관계를 가진 각각의 룰 케이스를 나타낸다.

룰 케이스는 순서를 가지며, 각각의 테스트 케이스에 대한 식별된 룰 케이스는 잠재적 입력에 대한 각각의 관계가 만족되는 순서로 제1 룰 케이스에 대응한다. 제2 세트의 룰 케이스를 포함하는 제2 룰 사양을 수신하고, 하나 이상의 룰 케이스는 제1 룰 사양의 하나 이상의 출력과 제2 룰 사양의 대응하는 출력에 대한 관계를 포함한다. 각각의 테스트 케이스에 있어서, 테스트 케이스의 입력 값이 주어진 상태에서 출력을 생성할 제2 룰 사양의 룰 케이스 중 하나와 제1 룰 사양의 식별된 룰 케이스의 출력을 식별한다. 각각의 테스트 케이스에 있어서, 제2 룰 사양의 출력을 발생하게 될 제1 및 제2 룰 사양의 입력과 출력 사이의 상호관계에 대한 그래픽 디스플레이를 발생시킨다. 각각의 테스트 케이스에 있어서, 테스트 케이스의 입력 값이 주어진 상태에서 출력을 발생할 각각의 룰 케이스를 표시한다. 각각의 룰 케이스에 있어서, 그 룰 케이스로 하여금 출력을 발생하게 할 잠재적 입력에 대한 값을, 얼마나 많은 테스트 케이스가 갖는지를 나타낸다.

각각의 테스트 케이스는 출력을 포함한다. 식별된 룰 케이스에 의해 발생된 출력이 테스트 케이스에 포함된 출력과 매칭하는지의 여부를 결정하고, 그 결정 결과를 저장하거나 전달한다. 각각의 테스트 케이스에 대한 결과 행을 포함하는 테이블을 생성하고, 각각의 결과 행은 테스트 케이스의 입력 값들이 주어된 상태에서 룰 사양에 의해 발생될 출력을 나타낸다. 각각이 결과 행에서, 발생될 출력이 이전 버전의 룰 사양이 나타낸 출력과 다르게 되는지를 나타낸다. 결과 행과의 사용자 상호작용에 응답해서, 그 결과 행에서 출력을 생성할 그 식별된 룰 케이스를 나타낸다. 테스트 케이스 중 하나에 있어서, 룰 사양의 각각의 룰 케이스에 대응하는 평가 행을 포함하는 테이블을 생성하고, 이 테이블의 각각의 평가 행에서, 각각의 잠재적 입력에 있어서, 테스트 케이스에서 잠재적 입력에 대한 값이 그 평가 행에 대응하는 케이스 룰에서 그 잠재적 입력에 대한 관계를 만족했는지를 나타낸다. 테스트 케이스에 대한 그 식별된 룰 케이스에 대응하는 테이블의 평가 행에서, 그 룰 케이스에 의해 발생될 출력을 나타낸다.

평가 행은 룰 사양 내의 룰 케이스의 순서에 대응하는 순서를 가지며, 그 출력이 나타내는 평가 행은, 잠재적 입력에 대한 각각의 관계가 만족되는 제1 룰 케이스에 대응한다. 각각의 잠재 입력에 대한 각각의 관계가 테스트 케이스에 의해 만족되는 룰 케이스에 대응하는 각각의 평가 행에서 발생될 출력을 나타낸다. 제2 세트의 룰 케이스를 포함하는 제2 룰 사양을 수신하고, 각각의 테스트 케이스에 있어서, 각각의 룰 사양에 의해 발생될 출력을 나타낸다. 각각의 테스트 케이스에 대한 결과 행을 포함하는 테이블을 생성하고, 각각의 결과 행은 테스트 케이스의 입력 값들이 주어진 상태에서 룰 사양에 의해 발생되는 각각의 출력을 나타낸다. 결과 행에서 표시된 출력에 대한 사용자 상호작용에 응답해서, 어떤 룰 케이스가 그 표시된 출력을 생성할 것인지를 나타낸다. 그 표시된 룰 케이스는 제2 룰 사양에서 나온 것이며, 그 표시된 룰 케이스를 나타내는 것은, 제1 룰 사양으로부터의 룰 케이스로서 그 룰 케이스의 출력이 그 표시된 룰 케이스의 입력 상호관계를 만족하는 룰 케이스를 나타내는 것을 포함한다. 상기 한 세트의 테스트 케이스를 수신하는 것은 사용자로부터 한 세트의 입력 값을 수신하는 단계와, 그 한 세트의 입력 값을 룰 사양의 잠재적 입력 값과 매칭시키는 단계와, 그리고 그 한 세트의 입력 값을 테이블의 컬럼에 저장하는 단계를 포함한다. 한 세트의 입력 값을 수신하는 것은 잠재적 입력 값의 식별을 디스플레이하는 것에 응답하여 이루어진다.

일반적으로, 일 측면에 따르면, 그래프 기반의 연산에서 구성요소는 데이터 흐름을 나타내는 요소를 연결함으로써 연결되는 데이터 처리 구성요소를 가지며, 이 데이터 처리 구성요소은 한 세트의 룰 케이스를 포함하는 룰 사양에 기초하여 데이터를 변환하는 변환을 포함하며, 잠재적 입력 및 대응하는 출력에 대한 관계를 포함하는 각각의 룰 케이스는, 실행 환경에서 한 세트의 입력 데이터에 대한 그래프 기반 연산을 실행하고, 입력 데이터 및 한 세트의 입력 데이터에서 데이터의 각각의 항목에 대한 연산에 의해 생성된 출력을 로깅하고, 실행 환경과는 별도의 테스트 환경에서, 그 로깅된 세트의 입력 데이터에서의 데이터의 각각의 항목에 있어서, 그 항목에서 입력 값이 주어진 상태에서 로깅된 출력을 발생시킬 룰 케이스 중 하나를 식별한다.

본 발명의 하나 이상의 실시예에 대해 첨부된 도면 및 이하의 상세한 설명에 상세히 개시한다. 본 발명의 다른 특징, 목적, 및 이점은 상세한 설명 및 도면, 그리고 청구의 범위로부터 분명하게 될 것이다.

데이터 흐름을 나타내는 링크 요소에 의해 연결된 데이터 처리 구성요소를 가진 그래프 기반 연산에서의 한 구성요소는, 룰 사양(rule specification)을 수신하고, 이 룰 사양에 기초하여 데이터를 변환하는 변환(transform)을 발생시키고, 이 변환을 그래프 기반 연산에서의 구성요소와 연관시키며, 새로운 룰 사양이 수신되었거나 또는 기존의 룰 사양이 편집되었음을 판정한 것에 응답하여 그 새로운 룰 사양 또는 편집된 룰 사양에 따라 상기 그래프 기반 연산에서의 구성요소와 연관된 변환을 갱신한다.

도 1a는 변환의 일례이다.
도 1b는 그래프의 일례이다.
도 1c는 변환의 생성 및 갱신에 대한 블록도이다.
도 2a는 스프레드시트 기반의 룰 엔트리에 대한 예이다.
도 2b는 개별 룰에 대한 예이다.
도 3은 테스트 데이터 세트이다.
도 4a는 테스트 결과이다.
도 4b 및 도 4c는 테스트 결과의 상세이다.
도 5는 흐름도이다.
도 6은 변환 코드의 예이다.
도 7은 흐름도이다.

비지니스 룰은, 예를 들어 데이터를 한 포맷으로부터 다른 포맷으로 전환하거나, 데이터에 관한 결정을 내리거나, 한 세트의 입력 데이터에 기초하여 새로운 데이터를 발생시키기 위한 한 세트의 판단기준(criteria)으로서 표현될 수 있다. 예를 들어, 도 1a에서, 항공 예약 시스템에서의 레코드(rocord)(102)는 승객의 이름(104)과, 승객이 금년에 몇 마일을 여행했는지(106)와, 승객 좌석표의 등급(108)과, 승객이 앉는 줄(110)을 나타내고 있다. 비지니스 룰은 이러한 승객이 탑승 그룹(boarding group) 1에 들어가 있어야 한다는 것을 나타낸다. 비지니스 룰은 일반적으로 사람이 이해하기 쉽지만(즉, "1등석 승객은 그룹 1에 있습니다"), 데이터를 조작(manipulate)하는 데 사용될 수 있기 전에 컴퓨터가 이해할 수 있는 것으로 번역되어야 한다. 그래프 기반 연산 환경에서 비지니스 룰을 구현하기 위해, 변환(112)이 일어나는데, 하나 이상의 데이터 소스, 예를 들어 입력 데이터 세트(100)로부터, 레코드(102)와 같은 입력 레코드를 수신하고, 출력 레코드, 예를 들어 승객의 이름(104)을 나타내는 레코드(114) 및 승객이 어느 그룹에 속해 있는지(118)를 출력 데이터 세트(120)에 삽입한다. 입력 데이터 세트 및 출력 데이터 세트는 또한 데이터 스트림이라고도 한다. 그런 다음 변환은, 데이터 흐름을 나타내는 링크 요소에 의해 연결된 데이터 처리 구성요소를 가진 그래프 기반 연산에서 구현될 수 있다. 예를 들어, 도 1b의 간단한 연산 그래프(130)는 두개의 입력 데이터 세트들(132, 134)(예를 들어, 고객 데이터 및 항공 예약 데이터)을 취하고, 그 데이터를 함께 사용될 수 있도록 별개의 포맷 구성요소(136, 138) 내에서 각각의 세트로 포맷하며, 이들을 결합 구성요소(140)에서 결합시켜 출력 데이터 세트(142)를 생성한다. 변환은 그 자체가 그래프(130)에서의 연산과 같은 그래프 기반 연산일 수 있거나, 또는 그래프(130)를 구성하는 개별적인 구성요소(136, 138, 및 140)와 같은 그래프의 구성요소 내에서 실행될 수도 있다.

비전문의 사용자를 위해 변환의 생성을 간단하게 하려면, 이러한 사용자가 원하는 변환을 컴퓨터 시스템에게 알려주도록, 그들에게 친숙한 포맷으로 '룰 세트'라고도 하는 비지니스 룰의 세트를 입력하기 위한 툴을 제공한다. 룰 세트는 단일 변환을 생성하는 한 세트의 룰이다. 룰은, 입력에 의존하여 상이한 값을 룰의 출력으로서 연산하는 하나 이상의 룰 케이스로 이루어질 수 있다. 룰은 또한 다른 룰들을 포함할 수 있다. 룰 세트에서의 다른 룰들은 부가하거나 또는 대체하여 출력할 값을 생성할 수 있다. 룰 세트는 다른 룰 세트를 포함할 수 있는데, 이것을 여기서는 "포함된 룰 세트(included rule set)"라고 칭한다.

변환 생성 시스템의 일반적 모델이 도 1c에 도시되어 있다. 생성기(150)는 편집기(154)로부터 룰 세트(152)를 입력으로서 수신하고 변환(156)을 생성한다. 생성된 변환(156)은, 시스템의 아키텍처, 및 변환과 비지니스 룰의 목적에 기초하여, 그래프에서 사용되는 구성요소로서 또는 전체 그래프 자체로서 그래프 기반 연산 시스템(158)에 제공된다. 생성기(150)는, 예를 들어 컴파일러일 수도, 주문 프로그램(custom-built program)일 수도, 또는 룰 세트(152)를 수신하고 변환(156)을 출력하는 표준 툴을 사용해서 구성된 다른 그래프 기반 연산일 수 있다.

생성기(150)는 또한 룰 세트(152)가 편집될 때 변환(156)을 갱신할 수 있다. 룰 세트(152)가 편집될 때, 편집기(154)는 전체 룰 세트를 편집기에 제공하거나, 또는 그 새로운 또는 수정된 룰들 또는 룰 케이스들(152a)만을 제공할 수도 있다. 생성기(150)는 원래의 변환(156)을 대체하기 위해 전체적으로 새로운 변환을 생성하거나, 변환을 사용하는 시스템의 성능 및 필요에 따라 변환을 포함하는 구성요소(16a)를 제공할 수 있다.

일부의 예에서, 룰은, 도 2a에 도시된 바와 같이, 스프레드시트 포맷으로 입력될 수 있다. 스트레드시트(200) 내의 트리거 컬럼(trigger column)(202, 204, 206, 208)은 사용 가능한 데이터 값에 대응하고, 행(210a-210h)은 룰 케이스, 즉 사용 가능한 데이터 값을 관련시키는 판단기준 세트에 대응한다. 룰 케이스(210n)는, 그 레코드의 데이터 값들이, 그 룰 케이스가 판단기준을 가진 각각의 트리거 컬럼에 있어서, 트리거링 판단기준을 충족하는 경우, 주어진 레코드(예를 들어 도 1a에서 102)에 적용된다. 룰 케이스(210n)가 적용되면, 출력은 하나 이상의 출력 컬럼(212)에 기초하여 생성된다. 모든 입력 관계가 만족된 룰 케이스는 "트리거링된(triggered)"이라고 표현될 수 있다. 각각의 출력 컬럼(212)은 잠재적 출력 변수에 대응하고, 적용 가능한 행(210n)의 대응하는 셀에서의 값이 그 출력(만일 있다면 그 변수를 위한 출력)을 결정한다. 셀은 변수에 할당되는 값을 포함할 수 있고 또는 전술한 바와 같이, 출력 값을 생성하기 위해 평가되는 식(expression)을 포함할 수 있다. 도 2a에는 단지 하나만이 도시되어 있지만, 하나의 출력 컬럼보다 더 많이 있을 수 있다.

변수에 대응하는 컬럼, 식을 포함하되 한번 계산된 후에는 변수로 취급되는 컬럼, 및 식만을 포함하는 컬럼을 포함하여, 여러가지 형태의 트리거 컬럼이 있을 수 있다. 다른 컬럼 형태로서는, 데이터만을 포함하는 컬럼, 그리고 이 데이터만을 포함하는 컬럼에 기초하여, 모든 행에 대해 평가되는 식을 특정하는 컬럼이 있다. 식만을 포함하는 컬럼은 변수에 대응하거나 변수로서 취급되는 컬럼들보다 더 간단한다. 이러한 컬럼은 이하의 것 중 하나를 포함할 수 있다:

● 식(expression). 그 조건(condition)은, 그 식을 평가하여 값을 구했을 때 제로가 아니고(논-제로(non-zero)), NULL 값이 아닌(논-널 값(non-NULL value)) 경우에 참(true)인 것으로 간주될 것이다.

● 키워드 "any" 또는 엠프티 스트링(empty string). 그 조건은 항상 참이다. 트리거 컬럼에서 각각의 비어 있는(empty) 셀은 키워드 "any"를 명시적으로 포함하는 것과 균등하다.

● 키워드 "else". 좌측으로의 모든 셀이 동일한 행에서, "else"를 포함하는 셀 보다 위의 셀들이 참인 것이 없으면, 그 조건은 참이다.

● 키워드 "same". 위의 셀이 참이면 그 조건은 참이다.

변수에 대응하는 컬럼은 두 가지 타입의 셀을 가질 수 있다. 한 가지 타입의 셀은 식 셀(expression cell)이다. 이러한 셀들은 정확하게 전술한 바와 같이, 식만을 포함하는 컬럼 내의 셀처럼 동작한다. 그렇지만, 키워드 "this"는 컬럼 변수를 언급하기 위해 그 식에서 사용될 수 있다. 다른 타입의 셀은 비교 값이다. 비교 값에 대한 예시적 문법은 이하와 같다:

여기서 "*"는 항(term)이 제로 또는 그 이상 반복된다는 것을 의미한다.

임의의 적절한 프로그래밍 언어 또는 신택스(syntax)가 사용될 수 있다. 예를 들어 C, 자바, DML 또는 프롤로그(Prolog)를 들 수 있다. 컬럼 변수는 연산자(operator), 함수(function), 또는 멤버쉽 식(membership expression)에 따라 비교 값에 대해 비교된다. 도 2a의 예에서, 두 개의 제1 컬럼(202 및 204)은 ">=" 연산자에 따른 비교값을 포함하고, 그러므로 판단기준은 그 컬럼의 값이 대응하는 수보다 크거나 같으면 충족된다. "좌석의 등급(Class of Seat)" 컬럼에서와 같이, 연산자가 없는 경우, "등가(equal)"로 간주된다. 근본이 된 시스템에서 어떤 프로그래밍 언어 또는 신택스가 사용되든지 간에 상수는 임의의 적법한 상수(legal constant)가 될 수 있다. 다른 상수 및 변수는 후술된 바와 같이 룰 세트 내에 정의된 비지니스 용어(business terms)이다. 식(expression)은, 사용되는 언어에서 임의의 적법한 표현인데, 컬럼 변수에 대해 비교될 호환가능한 테이터 타입을 돌려준다(return). 일부의 예에서, 비교값 내의 식은 모호함을 회피하기 위해 괄호로 묶여진다. smiple_function에 있어서, 함수는 컬럼 변수에 적용되고, 그래서 "is_null" 키워드는 식 "is_null(this)"과 동일하다.

도 2a의 예에서, 제1 행(210a)는 단 하나의 컬럼(202)에서 판단기준을 가지며, 이것은 여행자에 대한 마일리지(frequent flier miles)의 총수가 1,000,000 이상이면, 그 룰 케이스는 임의의 다른 컬럼이 가질 수 있는 어떤 값에 관계 없이 적용된다는 것을 나타낸다. 이 경우, 그 사용자에 대한 "탑승 그룹(Boarding Group)" 출력 변수는 그룹 1에 설정된다. 마찬가지로, 제2 룰 케이스(210b)는 1등석의 고객이 그룹 1에 있다는 것을 나타내고 있다. 일부의 예에서, 룰이 차례대로 평가되고, 그래서 마일리지가 1,000,000 마일 이상이고 1등석 비행기표를 가진 여행자가 그룹 1에 있을 것이지만, 제1 룰 케이스(210a)만이 트리거링될 것이다. 룰 케이스가 트리거링되면, 그 룰 내의 다른 룰 케이스는 평가될 필요가 없다.

다음의 룰 케이스(210c)는 두 개의 입력값(202 및 204)에 기초한 것이며, 전체 마일리지 및 금년의 마일리지 모두에 대해 정의된 판단기준이 충족되는 경우, 그 고객은 그룹 2에 있게 된다. 제4 룰 케이스(210d)에서, 비지니스 클래스 고객은 모두 그룹 2에 있게 된다. 나머지 룰 케이스(210e-h)는 다른 룰 케이스, 즉 "else" 및 "same"과 연관된 판단기준을 포함한다. 전술한 바와 같이, "else"는 그 행보다 위에 있었던 그리고 좌측으로 동일한 판단기준을 가졌던 행들(즉, 룰(210b 및 210d))에서, 그 컬럼의 판단기준이 충족되는 것이 없다는 것을 나타내고, "same"은 그 행보다 위에 있는 룰 케이스가 그 컬럼에 관해 적용되는 경우에 적용된다. 그러므로 제5 룰 케이스(210e)는, (룰 케이스(210a) 또는 룰 케이스(210c)에 의해 다루어질 것이었지만 다루지 않았기 때문에) 두 개의 제1 컬럼(202 또는204)에서 어떠한 판단기준에도 매칭되지 않았고, "좌석 등급" 컬럼에서의 "first" 또는 "business"를 가지지 않았으며, 그리고 10보다 작거나 같은 "좌석 줄(row of seat)" 값(208)을 가진, 모든 레코드에 적용된다. 나머지 룰 케이스(210f-h) 각각은, 컬럼(202 또는 204)에서의 값들을 가지는 그 위의 룰 케이스와도 일치하지 않고, "좌석 등급" 컬럼에서 "first" 또는 "business"을 가지지 않으며, 그리고 적절한 "좌석 줄" 값을 가진 레코드에 적용된다.

도 2a의 예에서의 룰 케이스(210a-h)는 또한 개개의 간단한 룰으로서 나타내어질 수 있는데, 도 2b에 도시된 바와 같이, 스프레드시트에 각각 나타내어질 수 있다. 룰(220a-d)은 도 2a의 행(210a-d)에 각각 대응하고, 룰(220e)은 행(210e-h)에 모두 대응하는 네 개의 룰 케이스를 가진다. 사용자는 도 2a에 도시된 전체 테이블을 생성하기보다는, 이러한 개개의 룰을 별도로 생성할 수 있다. 각각의 룰 케이스는 모드 트리거 컬럼에 대한 값 및 모든 출력 컬럼에 대한 값을 포함한다(값은 공백(blank)일 수 있으며, 즉 "any"로 유효하게 설정될 수 있다). 복수의 룰이 동일한 출력을 발생시킬 때, 룰에는 순서가 정해지며, 입력에 대해, 하나의 룰 트리거, 하나의 룰 케이스가 있게 될 때까지 순서대로 고려된 다음 출력을 발생한다. 하나의 룰 트리거에 룰 케이스가 없는 경우, 동일한 출력을 생성하는 다음의 룰이 처리된다. 하나의 출력에 있어서 어떠한 룰 트리거에도 룰 케이스가 없는 경우, 디폴트 값이 사용된다.

일부의 예에서는, 편집기 인터페이스는 식을 포함하는 셀들을 그래픽적으로 식별할 수 있다. 이것은 그 자체에서 참인지 거짓인지를 평가받는 식과 컬럼 변수와 비교되는 값을 되돌려보내는 식 간의 차이를 사용자가 이해할 수 있게 해준다. 사용자가 타이핑하는 때, 사용자는 예를 들어 그 앞에 별표(asterisk)를 타이핑함으로써, 특정한 셀이 식 셀(expression cell)이 될 것이라는 것을 나타낼 수 있다.

일부의 예에서, 값 및 식은 DML로 표현된 것이다. DML 언어가 완벽하게 지원될 수 있다. 필드에 대한 특별한 키워드 및 비지니스 명칭은 DML 표식으로 사전 처리(pre-processed)되는 스트링으로서 부호화된다. 식은 논리적(비지니스) 명칭(logical name)을 변수로서 사용할 수 잇지만, 또한, 비록 테스트에서 방해가 될 수 있을지라도, 실제의 물리적 명칭을 언급할 수도 있다.

출력 변수에 대응하는 컬럼에 있어서, 셀들은 이하의 것 중 하나를 포함할 수 있다:

● 값. 출력 변수에 할당되는 값.

● 식. 식의 값은 출력 변수에 할당된다. 식이 NULL로 평가되면, 출력 필드가 NULL이 아닌 경우를 제외하곤, 필드는 NUL 값을 얻는다. 이 경우, 에러가 발생된다.

● 키워드 "null". 출력 필드가 널(NULL)일 수 있는 경우, 그 필드는 NULL에 할당될 것이다. 그렇지 않으면, 에러가 발생된다.

● 엠프티 스트링(emply string). 출력 필드가 디폴트 값을 갖는 경우, 디폴트 값이 할당된다. 그렇지 않으면, 셀은 키워드 "널(NULL)"을 포함하는 것처럼 취급된다.

● 키워드 "same". 출력 필드는 위의 셀에서 연산된 동일한 값에 할당된다.

가능하다면, 에러는 가능한 빨리 보고된다(즉, 널이 될 수 없는 필드(non-nullable field)에 대한 출력 컬럼에 "null"을 넣는다). 그렇지만, 어떤 에러들은 테스트-타임 또는 런-타임때까지 보고되지 않을 수 있다.

식 외에, 사용자는 룰 내의 셀에 코멘트(comments)를 붙일 수 있다. 코멘트는 마이크로소프트사의 엑셀과 같은 공통의 스프레드시트 프로그램에서 셀에 부착된 코멘트처럼 디스플레이될 수 있다.

일부의 예에서, 룰 편집기 인터페이스는 인터페이스의 기술적 요구사항에 의해 요구되는 것보다 더 엄격하게 사용자가 입력하는 것을 제한하도록 구성될 수 있다. 예를 들어, 인터페이스는, 더 간단하고 더 제한된 사용자 인터페이스를 제공하도록 소정 타입의 변수만을 또는 소정 타입의 식만을 허용하도록 구성될 수 있다. 인터페이스는 또한, 사용자의 역할 또는 사용자 ID에 기초하여 하나의 룰 내에서 변경될 수 있는 셀을 제한하도록 구성될 수 있다. 이러한 제한은 관리자에 의해 룰 세트에 적용될 수 있다.

테이블의 행로서 생성되든지 또는 개개의 룰으로서 생성되든지 간에, 각각의 룰은 소정 세트의 속성(attributes)을 가진다. 룰 세트는 자신들이 포함하는 룰에 대한 이러한 속성을 결정할 수 있다. 이러한 속성으로는, 명칭, 룰 타입, 설명 및 코멘트 필드, 출력 변수의 리스트, 입력 변수의 리스트, 트리거 컬럼의 리스트, 수정 이력, 테스트 데이터 세트, 및 에러 취급 동작(error handling behavior)을 들 수 있다. 명칭은 그 자체로서 설명적이며 룰 세트 내에 룰을 리스트화하는 데에 사용된다. 룰 타입은, 예를 들어 "표준(normal)" 또는 "함수(function)"일 수 있다. 일부의 예에서, 룰 타입은 룰 세트의 특성이다. 출력 변수의 리스트는 룰에 의해 값들이 생성된 또는 할당된 한 세트의 변수이다. 이것은 룰 세트로부터 승계될 수 있으며, 하나 이상의 출력이 있을 수 있다. 입력 변수의 리스트는, 룰이 레코드를 평가할 필요가 있는, 컬럼의 맨 위에 변수들과 식 내부에서 사용된 변수들(예를 들어, 도 2a의 210c에서 사용된 "작년 마일리지" 값은 식에서 사용되지만 그 자체가 컬럼을 갖지는 않는다)을 포함하는 모든 변수를 일컫는다.

일부의 예에서, 복수의 룰 케이스는 단일의 입력 레코드에 대한 복수의 출력 레코드를 생성하는 데 사용될 수 있다. 이러한 룰 세트는 '일반화 룰 세트'로 지칭된다. 일반화 룰 세트에서, 출력 중 하나는 키 출력으로서 식별된다. 키 출력을 연산하는 룰이 평가되면, 입력에 대해 트리거링된 그리고 출력을 생성한 룰 케이스를 발견한다. 그런 다음, 어떤 다른 룰 케이스가 트리거링되어 출력을 생성하는지를 알기 위해, 이전에 트리거링된 룰 케이스는 디스에이블(disable)시킨 상태에서 룰들을 다시 평가한다. 이것은 룰 케이스가 트리거링되지 않을 때까지 반복된다. 각각의 출력은 별도의 출력 레코드로서 저장될 수 있다. 일부의 예에서, 룰 케이스는 그룹화되어, 하나가 트리거링되면, 그 그룹 내의 다른 것들도 동일한 입력에 대해 후속하는 반복 실행에서 디스에이블된다.

일부의 예에서, 룰은 전술한 바와 반대의 방식으로 평가될 수 있는데, 행 내의 룰 케이스들은 'AND' 연산되거나 컬럼 내의 룰 케이스들은 'OR' 연산된다. 즉, 룰은, 모든 행이 트리거되고(행을 AND 연산), 각각의 행이 트리거링되기 위해 하나의 셀만이 참이면 될 때(컬럼을 OR 실행), 출력을 생성한다.

인수(argument)의 리스트는 함수 룰에 대해서만 제공된다. 룰에 대한 입력인 파라미터의 이름 및 타입을 식별하고, 룰 세트의 특성이기도 하다. 트리거 컬럼의 리스트는 어느 컬럼들이 룰의 적용을 트리거링하는지를 식별한다. 도 2a 및 도 2b의 예에 도시된 입력 변수를 넘어, 트리거 컬럼은 파라미터, 룩업 변수, 이전의 룰로부터의 출력 변수, 포함된 룰 세트의 출력 변수, 룰 세트에 대한 파라미터, 또는 식에 대응할 수 있다. 이것들은 또한 함수 룰로부터의 변수, 즉 인수를 포함할 수 있다.

수정 이력(modification history)은 수정 명칭, 날짜, 및 코멘트를 포함한다. 일부의 예에서, 각각의 룰에 대해 하나의 수정 이력이 있고, 각각의 테스트 세트에 대해 하나의 수정 이력이 있다(후술됨).

에러 취급은 룰 세트로부터 생성된 변환이 룰을 평가할 때 생기는 에러를 어떻게 처리할지를 결정한다. 트리거 식에서 에러를 처리하기 위한 선택사항으로서, 먼저 에러를 허용하는 것이 있는데, 이 경우에는 변환이 에러를 야기한 레코드를 거부한다. 그리고, 또 다른 선택은, 에러를 무시하는 것인데, 이것은 트리거 식이 틀린 것으로 간주하는 것으로 다음의 룰로 이동하는 것과 같다. 출력 식에 있어서, 에러를 허용하고 레코드를 거절함으로써, 또는 에러를 무시하고 출력을 NULL로 설정함으로써, 또는 룰 내의 행을 무시하고 다음의 행로 이동함으로써, 에러를 처리할 수 있다.

테스트 데이터

룰 세트가 의도한 대로 작동되는지를 평가하는 것을 지원하기 위해 테스트 데이터 세트가 포함될 수 있다. 룰 세트에 대한 테스트 데이터 세트는, 예를 들어 도 3에 도시된 바와 같이, 한 세트의 견본 입력(prototypical inputs) 및 예측된 출력이다. 테스트 데이터 세트는 스프레드시트형 테이블(400)로 구성되고, 이 테이블(400)은, 룰에 의해 참조되는 각각의 필드를 가진 하나의 행(420a-e) 및 각각의 출력을 나타낸 하나의 행(404)(본 예에서는 하나만으로 했다)로 이루어져 있다. 그런 다음 사용자는 테스트 데이터 및 예측된 결과의 컬럼(406a-r)에서 나타난 테스트 케이스를 생성한다. 이 테스트 데이터는 룰과 함께 저장될 수 있다. 도 3의 예는 도 2a 및 도 2b의 룰에 대한 가능한 입력(402a-e) 및 의도된 출력(404)을 포함한다. 마일리지 및 좌석 배정에 대한 다양한 조합(406)에 대해 어떤 탑승 그룹(404)이 연산되어야 하는지를 보여준다(도시된 것보다 더 많은 조합의 입력이 있다). 일부의 예에서, 테스트 입력은 모든 룩업 내의 모든 변수에 대한 값을 포함한다. 테스트 입력은 또한, 모든 파라미터에 대한 값과, 현재 날짜 또는 시간을 참조하는 임의의 룰에 대해 "now"로서 사용할 값을 포함한다. 각각의 유닛을 테스트하기 위해, 테스트 입력은, '포함하는 룰 세트(including rule set)'가 테스트될 때는 그 '포함된 룰 세트(included rule set)'는 평가될 필요가 없으므로, 모든 포함된 룰 세트에 대한 값을 포함할 수 있다.

일부의 실시예에서, 유닛 테스트 테이블 내의 컬럼(402, 404)은 사용자의 행동에 따라 소프트웨어에 의해 결정된다. 사용자가 룰을 편집할 때, 룰의 상세는 파싱되고, 참조된 입력 변수에 대한 정의 리스트가 생성된다. 이 리스트는 컬럼 헤딩에서 사용된 변수와 식에 내포되어 있는 변수를 포함하다. 각각의 변수, 식에 내포되어 있는 각각의 기술적 변수, 및 각각의 룩업 식에 대해 하나의 컬럼이 생성된다. 일부의 예에서, 사용자는 테스트 케이스를 한 번에 하나씩 제공함으로써 테스트 테이블(400)을 생성한다. 예를 들어, 사용자는 총 2,000,000 마일, 금년 200,000 마일, 작년 150,000 마일, 및 5번째 행에서 1등석(first) 비행기표를 가진 고객이 탑승 그룹 1에 있어야 한다는 것을 지정할 수 있다. 소프트웨어는 행 402a-e 및 404 중 어느 것이 이러한 입력 및 출력에 대응하는지를 결정하고 테이블(400) 내의 대응하는 컬럼(406a)을 생성한다. 이것은 사용자가 입력하기를 원하는 만큼 많은 테스트 케이스에 대해 반복될 수 있다. 일부의 경우, 소프트웨어는, 사용자가 어떤 변수가 그 값들을 필요로 하는지는 모르고 그냥 그 값을 입력 또는 선택할 수 있도록, 각각의 잠재적 입력 또는 출력 변수를 사용자에게 제공하는 인터페이스를 제공할 수 있다.

그런 다음 사용자는 테스트 케이스를 작성하고 테스트를 실행할 수 있다. 그리고, 소프트웨어는 테스트 데이터 세트 테이블의 각각의 라인에 대한 룰을 평가하고 그 결과 값을 연산한다. 그 결과 값이 그 기대 값(출력 변수에 대응하는 컬럼 내에서 사용자에 의해 입력된 값)과 매칭하는 경우, 예를 들어 출력 셀이 녹색으로 표시되는 것과 같이, 그 룰이 유효하다는 것을 나타내는 표시가 제공된다. 그 결과 값이 그 기대 값에 매칭하지 않는 경우, 이것은 예를 들어 셀이 적색으로 표시될 수 있고, 그 기대 값 및 실제 값 모두가 디스플레이되는 것으로 나타내어 질 수 있다. 그러면, 사용자는 테스트 케이스를 갱신하거나 룰을 수정할 수 있다. 다른 사용자 인터페이스 메커니즘도 물론 사용될 수 있다. 예를 들어, 입력되어 있는 예측된 출력과 연산된 출력을 서로 비교하기 보다는, 연산된 출력을 디스플레이하고 사용자가 그것이 정확한지 아닌지를 평가할 수 있도록 하여 테스트 과정을 간단하게 할 수도 있다.

일부의 예에서, 사용자는 테스트 데이터를 생성하기 위해 사용할 수 있는 실제의 데이터를 가진다. 비지니스 룰의 최종 사용자(ultimate users)는 테스트할 때 사용하도록 이러한 데이터를 개발자에게 제공할 수 있다. 사용자가 테스트용의 실제의 데이터를 갖고 있지 않은 경우를 대비하여, 소프트웨어는 테스트 데이터를 한 번에 하나의 레코드에 입력하기 위한 간단한 데이터 엔트리 타입을 제공할 수 있다. 사용자는 입력 데이터 세트 내의 필드 각각에 대한 값들을 타이핑하여 입력할 수 있고 이러한 레코드는 그 테스트 데이터 세트에 부여된다.

일부의 예에서, 룰들은 그 값들이 입력됨으로써 유효하게 되고, 워드 프로세서가 단어를 입력할 때 철자가 잘못된 단어를 표시하듯이 예측된 출력을 생성하지 못하는 룰은 인터페이스에서 즉각 식별될 수 있다.

일부의 예에서, 테스트가 실행된 후, 사용자는 테스트 데이터 세트 테이블에서 임의의 행(테스트 케이스)을 선택할 수 있다. 하나의 행이 선택되면, 그 테스트 케이스에 대해 출력을 생성한 룰 테이블 내의 대응하는 행이 디스플레이될 것이다. 식 외에, 사용자는 테스트 데이터 세트 테이블 내의 임의의 셀에 코멘트를 첨부할 수 있다.

룰 세트에 부가되는 것들

전술한 바와 같이, 변환은 룰 세트로부터 생성된다. 룰 세트는 이하의 속성을 가질 수 있다:

명칭, 설명, 및 코멘트 - 이들은 룰 세트를 식별하는 데 도움을 준다. 백엔드 구현(back-end implementation)에 따라, 룰 세트는 시스템 내의 그 위치에 대한 식별 정보를 포함할 수 있다. 일부의 예에서, 룰 세트의 위치는 프로젝트 내의 경로이다. 일부의 예에서, 룰 세트는 관계 데이터베이스(relational database)에서 구성될 수 있고 명칭에 의해 찾아질 수 있다. 수정 이력은 수정 명칭, 날짜, 및 체크-인 코멘트를 포함한다.

변환 타입 - 이것은 어떤 타입의 변환이 룰 세트로부터 생성되는지를 결정하다. 가능한 값은 후술되는 바와 같이, 리포맷(reformat), 결합(join), 롤업(rollup), 및 필터(filter)를 포함한다.

입력 데이터 세트 - 이들은 편집을 위해 필드 및 상수명(named constant)의 리스트를 제공한다. 일부의 예에서, 변환이 생성될 때 입력 데이터 세트 중 하나에 대한 레코드 포맷을 디폴트에 의해 정한다. 복수의 입력 데이터 세트가 있을 수 있으며, 이것은 룰 세트가 서로 다른 환경에서도 변환을 생성할 수 있도록 한다. 이것은 또한 복수 세트의 논리 대 물리 매핑, 즉 상이한 세트의 물리적 명칭을 허용한다. 일부의 예에서는, 하나 이상의 데이터 세트를 가진 입력 매핑 테이블(mapping table)이 있을 수 있다. 일부의 예에서, 결합 구성요소는 복수의 입력 매핑 테이블을 가질 수 있으며, 각각의 테이블은 복수의 데이터 세트를 가질 수 있다.

출력 데이터 세트 - 이들은 출력 필드명의 리스트를 제공한다. 디폴트에 의해, 변환이 발생될 때, 출력 데이터 세트 중 하나의 레코드 포맷을 정할 수 있다. 출력 데이터 세트는 입력 데이터 세트와 같을 수 있다. 포함된 룰 세트는 출력 데이터 세트를 가지지 않을 것이다. 일부의 예에서는, 입력 데이터 세트와 같이, 복수의 출력 데이터 세트가 존재하여, 룰 세트가 서로 다른 환경에 대한 변환을 생성할 수 있도록 한다.

포함된 룰 세트의 리스트 - 하나의 룰 세트는 다른 룰 세트에 의해 연산된 출력 필드(출력 레코드 포맷의 필드가 아닌, 명시적으로 리스트된 출력 필드)를 사용할 수 있다. '포함된 룰 세트(included rule set)' 내의 출력 변수는, 포함된 룰 세트로부터의 출력 변수로서 '포함하는 룰 세트(including rule set)'에서 보여질 수 있는 출력 변수의 세트를 정의하는 포함된 룰 세트 매핑 테이블에 기초하여, 포함하는 룰 세트 내의 변수로서 사용될 수 있다.

포함된 변환 파일의 리스트 - 룰 세트를 처리할 때 사용되는 변환을 특정하는 하나 이상의 파일이 선택적으로 포함될 수 있다.

변수 및 상수를 열거하는 일련의 매핑 테이블들 - 이 테이블들은 입력 데이터 세트와 출력 데이터 세트가 서로 뒤엉키어 있다. 이들은 편집자에게 알려진 변수들로 이루어진 리스트를 만들고 비지니스 명칭과 기술 명칭(DML 표식) 간의 매핑을 보여준다. 각각의 변수는 비지니스 명칭, 기술적 명칭(DML 표식), 및 기본 타입(base type)(스트링, 번호, 날짜 또는 시각)을 가진다. 각각의 변수는 비지니스 명칭과 DML 상수값 간의 매핑을 나타내는 상수의 선택 리스트와 연관되어 있다. 변수 테이블은 이하에 더 상세히 설명된다.

외부 테스트 데이터 파일에 대한 참조 - 테스트 파일은 룰을 테스트하는 데 사용되고, 전술한 내장된 테스트 데이터 세트와 유사하다.

No-reject 플래그 - 이 플래그가 설정되면, 룰 세트에 의해 생성된 변환은 레코드를 거절하지 않을 것이다(에러를 배출한다). 이것은 마치 룰이 결코 트리거링되지 않은 것처럼, 에러를 배출하는 룰이 무시되도록 사용될 수 있다.

전개 테이블(deployment table) - 이것은 하나 이상의 전개를 열거하고, 이 전개는 어느 룰이 각각의 빌드(build)에 포함되어야 하는지를 (간접적으로) 나타낸다. 전개 테이블은 나중에 더 상세히 설명한다.

옵션 키 - 이것은 결합 타입의 룰 세트(join-type rule set) 및 롤업 타입의 룰 세트(rollup-type rule set)에 대한 키를 나타내는 특별한 입력 필드의 비지니스 명칭을 사용자가 특정하도록 한다. 일부의 예에서, 이 키는, 키의 타입을 가지고 입력 변수의 테이블에서의 엔트리로서 실제로 구현된다.

룩업 파일의 옵션 리스트 - 이것은, 입력 변수 및 상수의 완전한 테이블, 비지니스 명칭, 및 키 정보를 제공하며, 이 테이블 룩업 파일당 하나씩이다. 룩업 파일 지원에 대해서는 이하에 더 상세히 설명한다.

파라미터의 테이블 - 이것은 변수를 열거하며, 그 변수의 값은 환경으로부터 나오거나 런-타임(run-time)에서 설정된 파라미터로부터 나온다.

변수 및 상수의 테이블

언급한 바와 같이, 각각의 룰 세트는 변수와 상수로 이루어지는 관련 테이블 세트를 가진다. 일부의 예에서, 이러한 테이블은 그 룰 세트에 전용되며, 룰 세트들 간에 공유될 수 없다. 변수와 상수의 테이블은 몇 가지 목적으로 사용된다:

1. 룰 세트에 의해 사용되는 입력 변수 및 룰 세트에 의해 연산되어 생성된 출력 변수의 정의 리스트로서 사용된다.

2. 편집하는 동안 이용 가능한 비지니스 명칭의 리스트로서. 편집하는 동안, 시스템은 변수 및 상수에 대한 비지니스 명칭의 제안된 리스트를 제공할 것이다. 이 리스트는 변수와 상수로 이루어지는 테이블로부터 나온다.

3. 비지니스 명칭을 기술적 명칭으로 변환하기 위한 매핑 테이블로서. 룰은 비지니스 명칭을 포함할 것이다(본문에서, 후술되는 바와 같이 DML 사전-처리기 지령의 안쪽). 변환이 생성될 때, 비지니스 명칭은 기술적 명칭 또는 DML 표식으로 대체된다. 일부의 테이블은, 입력 변수 및 출력 변수처럼, 비지니스 명칭에 대한 서로 상이한 기술적 명칭을 각각 가지는 복수의 데이터 세트를 가질 수 있다. 사용된 변환은 전개(deployment)에 의존한다(후술함).

룰 세트는 수 개의 상이한 테이블을 가질 것이다. 그 테이블들은 대체로 유사하지만 일부 약간의 차이가 있다. 그 테이블들은 이하를 포함한다:

1. 입력 변수 및 상수로 이루어지는 테이블. 변환-타입 룰 세트(transform-type rule set)에 있어서, 이 테이블은 룰에서 참조될 입력 레코드 포맷의 필드들을 포함한다. 레코드 포맷의 모든 모든 필드가 열거될 필요는 없지만 통상적으로는 열거된다. 결합-타입 룰 세트(join-type rule set)에 있어서, 각각의 테이블은 결합 동작(join operation)에 대해 하나의 입력 데이터 세트를 나타낸다.

2. 모든 포함된 룰 세트에 대한 입력 변수 및 상수로 이루어지는 테이블. 포함된 룰 세트를 사용할 때, 각각의 포함된 룰 세트는 입력 변수 및 상수로 이루어지는 그 자체의 테이블을 가진다. 변환이 이루어지면, '포함된 룰 세트'에 의해 사용된 입력 변수는 '포함하는 룰 세트'의 컨텍스트(context)(context)내의 실제의 입력에 매핑되어야만 한다. 그러므로 이 리스트는 그 포함하는 룰 세트로 승격된다. 복수의 포함된 룰 세트가 포함되는 경우, 각각의 입력 변수 테이블이 승격된다. (어떤 포함된 룰 세트 자체가 룰 세트를 포함하는 경우, 2차-레벨의 변수는 승격되지 않는다. 포함된 룰 세트로부터 승격된 입력 변수 및 상수는 그 포함하는 룰 세트에서 사용하기에 유용하지 않다. 이 테이블은, 그 포함된 룰 세트에 대한 입력들과 그 포함하는 룰 세트에 대한 입력들 사이에 매핑이 구축될 수 있도록 하기 위해 포함될 뿐이다. 보다 상세한 설명을 위해 이하를 참조한다.

3. 모든 포함된 룰 세트에 대한 출력 변수 및 상수로 이루어지는 테이블. 룰 세트가 포함되었을 때, 그 포함된 룰 세트의 출력들은 그 포함하는 룰 세트에 대한 입력이 된다. 이 테이블은 모든 변수를 열거한다. 그것은, 모든 그 포함된 룰 세트 내의 출력 변수 및 상수로 이루어지는 테이블로부터 초기에 옮겨져 온다. 그렇지만, 비지니스 명칭은 명칭 충돌을 회피하기 위해 변경될 수 있다. 이 테이블에 있어서, 기술적 명칭은 그 포함된 룰 세트 내에서 실제로 비지니스 명칭이다.

4. 출력 변수 및 상수로 이루어지는 테이블. 변환-타입 룰 세트에 있어서, 이 테이블은 룰 세트에 의해 연산될 출력 레코드 포맷의 필드를 포함한다. 연산되지 않는 출력 변수도 또한 포함될 수 있으며, 룰 세트에 의해 무시될 것이다. (생성된 변환은 입력을 출력에 복사하기 위해 와일드카드 룰을 가진다. 또한, 출력은 디폴트 값들을 가질 수 있다.)

출력 변수는 또한 중간 변수로서 사용될 수 있으며, 하나의 룰로부터 생성된 출력의 값은 이후의 룰에서 참조될 수 있다. 때때로, 출력은 이러한 방식으로만 사용되며, 변환으로부터의 출력 레코드에 결코 직접적으로 포함되지 않는다.

5. 파라미터들로 이루어지는 테이블. 룰은 파라미터들에 대한 참조를 포함할 수 있다. 파라미터는 그래프의 파라미터 세트의 컨텍스트(context)에서 런타임에서 분석(resolve)된다. 다른 변수와 같이, 룰 세트에서의 파라미터는 비지니스 명칭, 기술적 명칭(예를 들어, $RUNDATE) 및 타입을 가진다.

6. 각각의 룩업 파일에 대한 변수 매핑으로 이루어지는 테이블. 이것들은 입력 테이블들과 유사하지만, 룩업 파일에 대한 레코드 포맷의 필드에 매핑된다.

비-공유 룰 세트(이것은 변환을 생성하도록 설계되어 있다)는 통상적으로 입력 및 출력 데이터 세트 모두에 묶여 있다. 입력 데이터 세트는 입력 변수의 소스이다. 출력 데이터 세트는 출력 변수의 소스이다. 때때로 하나의 룰 세트는 복수의 입력 데이터 세트 및/또는 복수의 출력 데이터 세트를 가질 것이다. 이 경우, 각각의 입력 데이터 세트 및 출력 데이터 세트는 변환의 가능한 입력 또는 출력이다. (결합 동작은 제외하고) 한 세트의 입력 변수가 있게 될 뿐이지만, 서로 다른 데이터 세트에 대해 비지니스 명칭과 기술적 명칭 간에 서로 다른 매칭이 있을 수 있다. 어떤 경우에는, 입력 변수는 룰 세트에 의해 사용될 수 있으며 제1 입력 데이터 세트에 제공될 수 있지만 제2 입력 데이터 세트에는 제공되지 않는다. 이 경우, DML 표식은 제2 입력 데이터 세트에는 없는 변수의 기술적 명칭으로서 특정되어야 한다. 룰 세트가 입력 변수를 사용하지 않는 경우, 모든 입력 데이터 세트에 기술적 명칭을 제공할 필요는 없다.

마찬가지로, 한 세트의 출력 변수만이 있을 수 있다. 주어진 출력 데이터 세트가 출력 변수에 대응하는 필드를 가지지 않는 경우(즉, 기술적 명칭이 없는 경우), 그 출력은 그 출력 데이터 세트에 대한 변환이 생성될 때 무시될 것이다.

포함된 룰 세트들은 어느 정도 다르게 취급된다. 포함된 룰 세트는 입력 및 출력 데이터 세트와 연관되어 있지 않다. 대신, 이것들은 입력 변수 및 출력 변수를 가질 뿐이다. 포함된 룰 세트를 포함하는 룰 세트는 입력 및 출력을 매핑하는 것을 책임진다. 이것에 대해서는 나중에 상세히 설명한다.

변수

변수는 이하의 속성을 가질 수 있고, 사용자에게 테이블 형태로 제공될 수 있다:

1. 비지니스 명칭(논리적 명칭). 비지니스 명칭은 룰에서 사용되는 명칭이다. 일부의 예에서는, 두 개의 입력 변수가 동일한 명칭을 가질 수 없고, 두 개의 출력 변수가 동일한 명칭을 가질 수 없고, 포함된 룰 세트로부터 두 개의 출력이 동일한 명칭을 가질 수 없으며, 동일한 룩업 파일 내의 두 개의 룩업 변수가 동일한 명칭을 가질 수 없는 제약이 주어진다. 입력 변수는 출력 변수로서 동일한 명칭을 가질 수 있다. 그러한 경우, 사용자 인터페이스는 컨텍스트에 기초하여 또는 출력 변수 명칭 앞에 "out."와 같은 접두사를 사용함으로써 입력 및 출력을 구분할 수 있다. 서로 다른 룩업 파일에서의 룩업 변수는 동일한 명칭을 가질 수 있다. 이 경우, 룩업 파일 자체의 명칭과 같은 접두사를 사용하여 그들을 구분할 것이다.

2. 간단한 타입. 일부의 예에서, 네 개의 기본적인 타입이 지원된다 - 스트링, 번호, 날짜, 및 시각. 이것들은 DML 타입 스트링(int), 10진수(20), 날짜("YYYY-MM-DD") 및 시각("YYYY-MM-DD HH24:MI:SS.nnnnnn")에 대응한다. 변환에서 사용되는 기본적인 타입과 실제의 타입 간의 변환은, 예를 들어, 그 생성된 변환 구성요소에 의해, 비지니스 룰의 편집과는 별도로 처리될 것이다.

3. 디폴트 값. 디폴트 값은 출력 변수에 대해 필요할 뿐이다. 이것은 (1) 그 출력에 대한 룰에서 출력 컬럼 내에 비어 있는(empty) 셀이 존재할 때, 또는 (2) 그 출력에 대한 값을 연산하기 위한 룰 트리거가 존재하지 않을 때 사용되는 값이다. 디폴트 값은, 출력 변수가 NULL이 될 수 있는 것이라면, NULL일 수 있다(그리고 비어 있는(empty) 셀은 NULL로 해석된다).

디폴트 값은 룰 식 테이블에서 출력 컬럼에서 사용되는 식과 같은 식(expression)이다. 이것은, 디폴트 값이 입력 변수 또는 출력 상수를 참조할 수 있거나 식을 포함할 수 있다는 것을 의미한다. 디폴트 값은 또한, 순환성을 채용하고 잇지 않는 한, 다른 출력을 참조할 수 있다.

4. 기술적 명칭(물리적 명칭) 또는 식(expression). 이것은 변수를 특정하는 식이다. 입력 및 포함된 변수들에 대한 필드명 대신 식을 사용하는 것이 가능하다. 일부의 예에서, 출력 변수에 대해 식을 사용하는 것은 허용되지 않는다. 벡터의 경우, 그 식은 완전하게 검정되어야 한다.

포함된 룰 세트로부터, 승격된 변수, 및 입력 및 출력 변수를 취급할 때, 변수와 관련된 기술적 명칭은 실제로 그 공유된 룰 세트 안에서 사용된 비지니스 명칭일 뿐이다. 내부적으로만 사용되는 출력 변수를 사용할 때(중간 변수는 하나의 룰에서 연산되고 후속의 룰에서 사용된다), 기술적 명칭은 공백(blank)일 수 있다.

5. 선택적 설명 및 코멘트

상수

변수들로 이루어지는 다양한 테이블은 상수뿐만 아니라 변수에 대한 매핑을 포함한다. 상수는 C++에서의 "enums"에 대응한다. 소프트웨어는 유효값 및 무효값으로부터 초기에 온 상수값, 및 유효 범위 및 무효 범위로부터 초기에 온 상수 범위를 지지한다. 또한, 별개의 값 및/또는 범위의 세트를 나타내는 상수를 생성하는 것이 가능하다.

상수는 변수와 관련된다. 이것은 상수의 비지니스 명칭이 전체 룰 세트에 대해 고유한 것일 필요는 없다는 것을 의미한다. 편집기는 통상 룰에서 어느 컬럼에서 상수가 나타나는지에 기초하여 임의의 상수에 대한 컨텍스트를 알게 될 것이며, 그렇지만, 식 내의 다른 변수에 속하는 상수를 사용자가 선택하는 것이 가능하다. 이 경우, 상수는 변수 명칭이 부여될 것이다(예를 들어, "에어라인 클래스.비지니스(Airline class.business)")

출력 변수를 연산할 때, 단일 값의 상수만이 사용된다(출력 필드에 범위를 할당하는 것은 이치에 닿지 않는다).

상수는 이하의 속성을 가지며, 표의 형태로 사용자에게 제공될 것이다. (변수 및 상수는 하나의 테이블을 다른 테이블에 매립하는 것과 같이, 뒤섞일 것이다.)

1. 변수 명칭. 모든 상수는 정확하게 하나의 변수에 적용된다. 변수 명칭은 실제로 관련된 변수 자체의 부분이다.

2. 비지니스 명칭. 비지니스 명칭은 룰에서 사용되는 명칭이다. 명칭이 값 식별자일 필요는 없고, 특히, 자간 띄움(interal spaces) 및 구두점(punctuation)이 허용된다. 상수에 대한 비지니스 명칭들만이, 자신들이 적용되는 변수 내에서 고유해야 한다.

3. 상수 타입. 값, 범위 또는 세트 중 하나. 전술한 바와 같이, 범위 및 세트는 비교(입력)에서 사용될 때만 적합하며, 할당(출력)에서는 적합하지 않다.

4. 값에 대해: 실제의 값의 경우. 본 예에서, 스트링은 인용 부호(quotes) 내에 있어야 하지만 숫자는 그렇지 않다. 날짜 및 시간은 디폴트 형태의 인용 부호 내에 있어야 한다(예를 들어, "YYYY-MM-DD"). 그 식이 변수 형태로 자동으로 변환될 수 있는 단순한 형태를 리턴하는 한, 그 식을 사용하는 것이 허용된다.

하나의 상수가, 포함된 룰 세트에 대한 입력 또는 출력의 테이블의 일부일 때, 값은 없다. 대신, 그 값은, 대응하는 입력 또는 출력 변수에 대한 관련된 상수의 비지니스 명칭이다.

5. 범위에 대해: 최대값 및 최소값. 최대값 및 최소값은 전술한 실제의 값과 같이, 상수 또는 식이다. 범위는 룰의 비교에 있어서 약기(shorthand)로서 사용된다. 동등 비교만이 범위에서는 허용되며, 소프트웨어는 범위를 "변수 >= 최소 및 변수 <= 최대"로 해석할 것이다. 최소가 지정되지 않은 경우, 그 비교의 부분은 건너뛰게 될 것이다. 최대에서도 마찬가지이다. 범위는 실제로 최소값과 최대값을 분리하는 콤마(comma)로 저장된다.

6. 세트에 대해: 값을 콤마로 구분한 리스트. 리스트의 각각의 요소는 전술한 실제의 값과 같이, 상수이거나 식이다. 동등 비교만이 세트에 허용되며, 소프트웨어는 세트를, "[값의 벡터 리스트]의 변수 멤버"의 형태의 식으로 변환할 것이다.

7. 선택적 설명 및 논평.

공유된 룰 세트로부터, 승격된 변수를 취급할 때, 상수도 승격된다. 공유 룰 세트에 대한 입력 및 출력 변수를 나타내는 테이블에서는, 이러한 변수와 관련된 상수도 나타내어진다. 이러한 상수들에 대한 디폴트 매핑은 승격된 정보의 일부이지만, 사용자는 상수값들을 번복할 수 있다.

소프트웨어는 불일치 상수(mismatching constants) 때문에 변수의 사용에서 가능성 있는 충돌이 있는 경우를 검출할 것이다. 구체적으로, (1) 임의의 변수의 값이 다른 변수에 복사되는 경우, (2) 정의된 상수를 양쪽의 변수가 가지는 경우, 및 (3) 상수 세트가 명칭 및 값 모두에 있어 일치하지 않는 경우.

에러가 발생될 것이고 사용자는 하나의 변수의 값을 다른 변수의 값들로 변환시킬 필요가 있다. 소스 변수는 입력 변수, 룩업 변수, 포함된 룰 세트로부터의 출력, 및 입력으로서 사용된 출력 변수를 포함한다. 타겟 변수는 포함된 룰 세트에 대한 출력 변수 및 입력을 포함한다. 룰 식 또는 변수 테이블에서 할당이 일어날 수 있다.

제약(restriction)에 명칭붙이기

입력으로서 사용될 수 있는 모든 것은 일반적으로 전체 룰 세트 내에서 고유한 명칭을 가질 필요가 있다. 이것은 입력 변수의 비지니스 명칭, 파라미터의 비지니스 명칭, 및 모든 포함된 룰 세트의 출력에 매핑된 비지니스 명칭을 포함한다. 결합 동작에서, 상이한 세트의 입력 내의 입력 변수들은 동일한 명칭을 가질 수 있다. 이것들은 예를 들어 입력 세트에 대한 비지니스 명칭에 대응하는 접두사로 구분될 수 있다.

출력 변수들도 또한 고유해야 한다. 그렇지만, 출력 변수는 입력 변수와 동일한 명칭을 가질 수 있다. 출력 변수가 입력 변수와 동일한 명칭을 가지는 경우, 그리고 (룰에 대한 트리거 컬럼에서와 같이) 입력 변수가 허용되는 곳에서 변수 명칭이 사용되는 경우, 입력 변수로 추정된다. 출력 변수를 대신 사용하기 위해, 명칭은 변수 명칭을 입력할 때, 예를 들어 "out.<variable-name>"를 입력함으로써, 자격을 부여받을 수 있다. 이것은 인터페이스 표기(interface notation)일 뿐이고 - 변수를 내부적 나타내는 데는 불명료함이 없다.

동일한 명칭을 가지는 변수와 상수 사이에는 여전히 불명료함이 존재할 수 있다. 이 경우, 소프트웨어는 상수 및 변수가 모두 동일한 명칭을 가져도 문제가 없는 컨텍스트에서는 상수를 선호할 것이다. 사용자는 예를 들어 신택스 "in.<variable-name>"을 사용하는 변수 명칭에 자격을 부여함으로써 그것을 극복할 수 있다.

일부의 예에서, 비지니스 명칭은 UTF-8에 있는 것으로 간주되므로 국제적 캐릭터(international character)를 포함할 수 있다. 비지니스 명칭은 띄움(space), 마침표(period), 괄호(parenthesis)를 포함한다. 그렇지만, 이러한 예에서, 비지니스 명칭은 0x00 내지 0x31 사이의 임의의 캐릭터(제어 캐릭터들)를 포함하는 것이 허용되지 않는다. 사용자 인터페이스를 통해 사용자는 잘못된 대문자 사용으로 비지니스 명칭을 입력할 수 있고, 그러면 예를 들어 자동-완성 메커니즘을 이용하여 정확한 대문자 사용을 제시한다고 하더라도, 모든 비지니스 명칭의 매칭은 문법상 격에 민감하다(case sensitive).

변수의 정렬(Ordering of Variables)

순환 로직을 회피하기 위해, 소프트웨어는 변수 및 룰을 엄격하게 정렬한다. 전체적인 순서는 이하와 같다:

1. 입력 변수 및 파라미터.

2. 제1 '포함된 룰 세트'의 입력 매핑.

3. 제1 '포함된 룰 세트'의 출력값.

...

4. 제N '포함된 룰 세트'의 입력 매핑.

5. 제N '포함된 룰 세트'의 출력값.

6. 제1 룩업 파일의 디폴트 키 값.

7. 제1 룩업 파일의 출력 필드

...

8. 제N 룩업 파일의 디폴트 키 값.

9. 제N 파일의 출력 필드.

10. 모든 출력 변수의 디폴트 값.

각 항목의 연산은 이전 단계에서 연산된 값들을 사용한다. 이것은 예를 들어 제1 포함된 룰이 그 매핑 테이블의 입력 변수 및 파라미터를 참조할 수 있다는 것을 의미한다. 그렇지만, 제2 포함된 룰은 그 입력을 제1 포함된 룰으로부터 연산된 출력에 매핑할 수 있다. 마찬가지로, 각각의 출력 변수에 대한 디폴트 값은 모든 룰 이전에 연산되므로, 이들은 입력 변수의 값, 파라미터, 룩업 파일, 또는 모든 포함된 룰으로부터의 출력에 기초한다. 룰의 출력을 실제로 연산할 때가 되면, 나중의 룰들이 이전의 룰들로부터 연산된 값들을 사용할 수 있도록 룰들이 평가된다.

데이터 세트를 변수에 링크하기

일부의 예에서, 입력 변수의 테이블은 직접적으로 입력 데이터 세트 레코드 포맷으로부터 나오고 비지니스 명칭은 그 입력 데이터 세트에 대한 메타 데이터로부터 나온다. 그렇지만, 일부의 예에서, 룰 세트의 내에서 이 매핑의 복사본을 가지고 있으면 다음과 같은 이점이 있다. 첫째, 룰 세트에서 변수 매핑 테이블의 복사본을 갖는 것은 생성 환경의 컨텍스트 밖에서 룰 세트를 편집하는 것이 가능하다. 룰 세트 및 관련 룰은 샌드박스(sandbox)로 시나리오화될 수 있고 샌드박트 프로젝트의 일부로서 편집될 수 있다. 둘째, 입력 변수 매핑 테이블의 복사본을 갖는 것은 사용자가 충돌을 해결하는 것이 가능하거나 그렇지 않으면 기존의 메타 데이터에 대해 최종 결정권을 가질 수 있다. 예를 들어, 입력 데이터 세트 내의 두 개의 필드가 동일한 비지니스 명칭에 매핑되는 경우, 이 비지니스 명칭 중 하나는 입력 변수의 테이블에서 변경될 수 있다.

룰 세트가 먼저 생성되면, 입력 변수 테이블은 비어 있다. 사용자가 입력 데이터 세트를 식별하자마자, 입력 변수 테이블은 입력 데이터 세트의 메타 데이터로부터 자동으로 표시된다. (동일한 논리가 출력 변수 및 출력 데이터 세트에 적용되지만, 본 논의의 나머지는 간략화를 위해 입력 데이터 세트에 초점을 맞출 것이다.)

단일 용어인 "입력 데이터 세트"는 간략화를 위해 본 설명에서 사용된다. 입력 변수에 연결될 수 있는 제로 또는 그 이상의 입력 데이터 세트가 존재하고, 또 출력 데이터 세트에 연결될 수 있는 별도 세트의 제로 또는 그 이상의 데이터 세트가 존재한다. 구체적으로, 입력 변수 테이블은, 비지니스 명칭에 대한 하나의 컬럼, 타입 등에 대한 하나의 컬럼, 및 입력 데이터 세트당 하나씩하여 기술적 명칭에 대한 많은 컬럼을 가진다. 단일의 입력 데이터가 지정되면, 유사한 기술을 이용하여 제2 데이터 세트가 부가될 수 있다. 그렇지만, 제2 또는 후속의 데이터 세트의 경우, 기술적 명칭과 비지니스 명칭 사이의 매핑은 불완전할 수 있는데, 특히 시스템은 제2 그리고 후속의 데이터 세트에서의 각각의 필드가 어느 변수에 매핑하는지를 알아낼 수 없기 때문이다. 이러한 예에서, 사용자는 어떠한 손실 정보도 수동으로 바로잡을 수 있다.

입력 데이터 세트로부터 입력 테이블을 초기에 생성할 때, 입력 데이터 세트 내의 각각의 필드는 하나의 입력 변수가 생성되도록 할 것이다. 입력 변수에 대한 기술적 명칭은 필드의 명칭이 될 것이다. 타입은 필드 타입에 기초하여 할당될 것이다. 보이드(voids)는 스트링처럼 취급될 것이고, 릴(reals)은 숫자처럼 취급될 것이다. 서브 레코드는 서브 레코드 내의 필드들이 입력 변수를 가질지라도 대응하는 입력 변수를 갖지 않을 것이다. 유니온(union)의 그 유니온의 각각의 브랜치에 대한 입력 변수들을 낳을 것이다. 요소가 벡터이면, 대응하는 입력 변수의 기술적 명칭은 벡터의 제1 요소("in.vect[0]")를 취할 것이다. 사용자는 이것을 무시할 수 있다. 예를 들어, 표준화-타입 변환(normalize-type transform)에서, 사용자는 기술적 명칭을 in.vect[index]로 되도록 변경할 수 있다. 또는, 사용자는 그 벡터의 길이가 고정되어 있는 경우, 그 벡터의 다른 요소에 대응하는 추가의 입력 변수들을 생성할 수 있다. 유니온 및 벡터는 출력 데이터 세트에서 지지되지 않을 수도 있다(출력 변수는 이들에 대해 생성되지 않을 것이다). 일부의 예에서, 표준화 구성요소의 변동은 복수의 출력 기록 대신에 출력 벡터를 출력할 수 있다.

일부의 예에서, 비지니스 명칭은 메타 데이터로부터 연산된다. 필드에 대한 비지니스 명칭을 결정하는 논리는 이하와 같다:

1. 필드(물리적 요소)가 디스플레이_명칭을 가지고 있는 경우, 필드의 디스플레이_명칭은 비지니스 명칭으로서 사용된다.

2. 그렇지 않으면, 필드가 논리적 요소를 가지고 있고 이 논리적 요소가 디스플레이_명칭을 가지고 있는 경우, 논리적 요소의 디스플레이_명칭이 비지니스 명칭으로서 사용된다.

3. 그렇지 않으면, 필드가 논리적 요소를 가지고 있는 경우, 이 논리적 요소의 명칭은 비지니스 명칭으로서 사용된다.

4. 그렇지 않으면, 비지니스 명칭은 기술적 명칭으로부터 연산된다.

충돌이 있는 경우(이중 명칭), 단지 하나의 비지니스 명칭만이 부여될 것이다. 다른 필드들에는 어떠한 비지니스 명칭도 부여되지 않을 것이다.

일부의 예에서, 룰 세트와 데이터 세트 메타 데이터 간의 동적 링크는 존재하지 않는다. 사용자가 메타 데이터를 변경하는 경우(예를 들어, 논리적 요소(Logical Element)에 다시 명칭을 붙이는 경우), 그 변경은 소프트웨어에 의해 자동으로 입수되지 않는다. 일부의 예에서, 데이터 간의 2 방향(two-way) 관계는 이러한 변경이 검출되도록 사용될 수 있다.

사용자가 제2 데이터 세트를 룰 세트에 부가하는 경우, 소프트웨어는 위에서 열거한 바와 같이 동일한 물리적-논리적 매핑을 이용하여 비지니스 명칭 각각에 대한 필드를 채우려 할 것이다. 변수가 매핑될 수 없는 경우, 그 변수에 대한 기술적 명칭은 부가된 데이터 세트에 대해 공백으로 남겨둘 것이고, 사용자는 필드명 또는 식을 수동으로 채워야만 할 것이다. 변수 필드는 풀-다운 방식으로 사용자에 열거될 것이다.

입력 변수 테이블이 데이터 세트 메타 데이터로부터 생성되는 것과 동시에, 상수는 마찬가지로 데이터 세트 메타 데이터로부터 입력 변수 테이블에 부가될 것이다. 소프트웨어는, 각각의 논리적 요소 또는 물리적 요소와 연관된 유효화 명세와 연관된 모든 유용한 값 및 무용한 값과 모든 유용한 범위 및 무용한 범위를 생성할 것이다.

상수에 대한 비지니스 명칭을 결정하는 논리는 이하와 같다:

1. 유용한 값(유용한 범위 등)이 디스플레이_명칭을 가지는 경우, 디스플레이_명칭은 비지니스 명칭으로서 사용될 것이다.

2. 그렇지 않으면, 유용한 값(유용한 범위 등)이 설명(description)을 가지는 경우, 그 설명은 비지니스 명칭으로서 사용될 것이다.

3. 그렇지 않으면, 상수는 비지니스 명칭 없이 가변 테이블에 포함될 것이다.

데이터 세트로 시작하는 변수를 생성할 필요가 없다. 입력 변수의 리스트를 생성하는 제2의 방법은 기본 시스템에서 논리적 엔티티(Logical Entity)를 식별하는 것이다. 논리적 엔티티가 선택되면, 소프트웨어는 논리적 엔티티 내의 각각의 논리적 요소(Logical Element)에 대해 하나의 변수를 가진 테이블을 생성할 것이다. 변수의 비지니스 명칭은 논리적 요소의 디스플레이_명칭일 것이다. 논리적 요소가 유효화 명세(Validations Spec)를 가지는 경우, 이전의 문서 룰(document rules)을 이용하여 상수도 생성될 것이다.

최종적으로, 입력 변수 및 출력 변수가 수동으로 부가될 수 있는데, 이 입력 변수 및 출력 변수를 변수 테이블에 부가하거나, 룰을 편집하는 동안 입력 변수 및 출력 변수를 생성함으로써, 부가될 수 있다. 예를 들어, 사용자가 컬럼을 룰에 부여할 때, 사용자는 어느 입력 변수가 그 컬럼에 대해 사용되어야 하는지를 결정한다. 그러나 사용자는 또한 "new..."을 선택하여 신속하게 입력 변수를 생성할 수 있다. 소프트웨어는 그런 다음 데이터 타입 및 옵션 코멘트을 입력하도록 사용자를 재촉할 것이다. 어떤 기술적 명칭도 나중에 채워져야할 필요는 없다.

소프트웨어는 룰이 편집될 수 있도록 하기 위해 변수의 리스트를 필요로 한다. 그렇지만, 비지니스 명칭과 기술적 명칭 간의 매핑은 나중에 완료될 필요가 없다. 매핑은 사용자가 외부 테스트 파일에 대한 전체적인 룰 세트를 테스트하거나 룰 세트로부터 변환을 생성할 준비를 할 때 필요할 뿐이다.

포함된 룰 세트

일부의 예에서, 룰 세트는 공유될 수 있다. 구체적으로, 포함된 룰 세트는 다른 룰 세트 내에 포함되도록 설계되어 그 논리는 포함하는 룰 세트의 생성된 변환의 일부가 된다.

포함된 룰 세트가 통상적으로 공유되도록 명확히 설계될지라도, 포함된 룰 세트도 또한 변환을 생성하는 데 독립적으로 사용될 수 있다. 예를 들어, 사용자는 필터-타입 변환에 대한 불리언 출력(Boolean output)을 연산하는 룰 세트를 생성할 수 있다. 그러나 동시에, 그 룰 세트는 다른 변환 내에 포함될 수 있고 불리언 출력(포함하는 룰 세트에서 유용한, 공유된 룰 세트의 출력 변수)은 더 복잡한 출력을 연산하는 데 사용될 수 있다.

포함된 룰 세트는 다른 형태의 룰 세트와 유사하다. 포함된 룰 세트는 입력 변수와 출력 변수를 가진다. 포함된 룰 세트는 스스로 다른 포함된 룰 세트를 포함할 수 있다. 그러나 포함된 룰 세트 내의 입력 변수 및 출력 변수의 취급은 변환-타입 룰 세트와는 다르다. 변환-타입 룰 세트에서, 입력 변수 및 출력 변수는 기술적 명칭에 매핑되기 때문에 변환이 생성될 수 있다. 그러나 포함된 룰 세트에서, 입력 변수 및 출력 변수를 기술적 명칭에 매핑할 필요가 없다(룰 세트가 변환을 생성하는데 공유되거나 사용되는 경우, 입력 변수 및 출력 변수는 변환을 발생하는 전개를 위해 기술적 명칭에 매핑될 것이다).

사용자가 포함된 룰 세트를 다른 룰 세트로 포함할 때, 포함하는 룰 세트는 그 포함된 룰 세트의 입력 및 출력을 매핑하기 위해 변수 매핑 테이블을 가질 필요가 있다. 포함하는 룰 세트의 컨텍스트에서, 그 공유된 룰 세트의 입력 변수 및 출력 변수만이 보여질 수 있다. 공유된 룰 세트에 포함된 임의의 룰 세트의 임의의 변수는 포함하는 룰 세트에 노출되지 않는다.

포함하는 룰 세트의 컨텍스트에서, 공유된 룰 세트의 입력 변수는 포함하는 룰 세트의 변수들, 또는 이러한 변수들을 사용하는 식에 매핑될 필요가 있다. 고유한 룰 세트의 비지니스 명칭은 변수 매핑 테이블에 열거될 것이지만, 이들 명칭은 포함하는 룰 세트 내의 룰들에 사용되는 것이 유용하지 않을 것이다. 대신, 포함하는 룰 세트는 공유된 룰 세트의 (비지니스 명칭에 의한) 각각의 입력 변수를 포함하는 룰 세트에서의 식에 매칭시킬 필요가 있을 뿐이다.

포함된 룰 세트는 입력 변수, 파라미터 및 룩업보다 앞서 평가되는 것으로 되므로, 포함된 룰 세트의 출력은 룩업에 대한 키(key)로서 사용될 수 있다. 일부의 예에서, 평가의 순서는 더 유연성이 있으며, 룩업의 정렬 대(vs) 포함된 룰 세트의 평가는, 의존성 분석(dependency analysis)에 기초하여 자동으로 결정될 수 있다. 포함된 룰 세트는 모든 출력 변수들이 연산되기 전에 평가되기 때문에, 포함하는 룰 세트 내의 출력 변수들은 그 포함된 룰 세트 내의 입력들에 매핑될 수 없다. 포함된 룰 세트 입력에 대한 매핑이 간단한 입력 변수로 수행될 수 없는 경우, 식이 대신 사용될 수 있다.

포함된 룰 세트 내의 입력 변수가 널(null)이 될 수 있는 것인 한, 포함된 룰 세트 입력 변수에 대한 매핑은 NUL일 수 있다. 매핑도 또한 공백으로 남겨질 수 있다. 매핑이 공백으로 남겨지면, 입력 변수가 '포함하는 룰 세트'의 출력의 연산에서 필요하게 된 경우 그리고 필요할 때만, 변환 생성 시에 에러가 보고될 것이다. 일부의 예에서, 모든 것이 널(null)이 될 수 있는 것으로 간주되며, 이것은 사용자 인터페이스를 간단하게 한다.

포함하는 룰 세트의 컨텍스트에서, 공유된 룰 세트의 출력 변수도 또한 포함하는 룰 세트에서의 비지니스 명칭에 매핑될 필요가 있다. 이 매핑 테이블은 전술한 것의 반대이다. 공유된 룰 세트의 입력 변수를 매핑할 때, 테이블은 공유된 룰 세트의 입력 변수의 비지니스 명칭을, 포함하는 룰 세트 내의 기존의 변수에 매핑한다. 공유된 룰 세트의 출력 변수를 매핑할 때, 포함하는 룰 세트는 공유된 룰 세트의 출력에 대한 비지니스 명칭을 지정하는 테이블을 가지며, 포함하는 룰 세트 내의 명칭을 그 공유된 룰 세트 내의 대응하는 명칭에 매핑한다.

출력 변수 매핑은 잠재적인 명칭 붙이기에서의 충돌(potential naming conflicts)을 해결할 필요가 있다. 디폴트 매핑은 포함하는 룰 세트 및 공유된 룰 세트 모두에서, 동일한 비지니스 명칭을 간단히 사용하는 것이다. 그러나 공유된 룰 세트 내의 출력 변수의 명칭은 포함하는 룰 세트에서 이미 정의된 변수들의 비지니스 명칭과 충돌할 수 있으므로, 포함하는 룰 세트 내에서의 그 매핑된 명칭이 부여된 것은 변경될 수 있다.

공유된 룰으로부터의 모든 출력이 매핑될 필요가 있는 것은 아니다. 출력이 매핑되지 않은 채로 남겨 있는 경우, 그 출력은 포함하는 룰 세트에서 사용될 수 없고, 그 공유된 룰 세트로부터의 대응하는 논리는 무시될 것이다. 한편, 룰 세트 설계자가 입력이 필요하지 않은 것으로 확신하는 경우 관심의 대상이 아닌 변수에 매핑될 수 있을지라도, 그 공유된 룰 세트로부터의 입력 모두는 매핑되어야 한다. 일부의 예에서, 시스템 자체는 어느 입력이 실제로 매핑될 필요가 있는지를 결정할 수 있다.

일부의 예에서, 매핑 테이블은 참조에 의해서가 아닌 비지니스 명칭에 의해 수행된다. 공유된 룰 세트가 다른 룰 세트에 포함되는 경우, 그 포함하는 룰 세트는 그 공유된 룰 세트로부터 입력 및 출력의 복사본을 얻는다. 이러한 명칭들은 매핑 정보와 함께 그 포함하는 룰 세트에 저장된다. 공유된 룰 세트가 변하여, 일부의 입력 또는 출력이 부가되거나, 삭제되거나 또는 명칭을 다시 부여하는 것이 가능하다.

포함하는 룰 세트와 포함된 룰 세트 간의 참조 통합 문제는 그 룰 세트가 시스템으로부터 로딩될 때 그 포함하는 룰 세트에 의해 다루어질 수 있다. 공유된 룰 세트로부터 사라진 입력 변수는 그 포함하는 룰 세트로부터 삭제된다. 공유된 룰 세트에 부가되는 입력 변수는 그 포함하는 룰 세트 내의 매핑 테이블에 부가되지만, 매핑되지 않은 채로 유지된다. 마찬가지로, 공유된 룰 세트에 부가되는 출력 변수도 그 포함하는 룰 세트 내의 매핑 테이블에 부가되지만, 매핑되지 않은 채로 유지된다. 출력 변수가 그 공유된 룰 세트로부터 삭제되고, 포함하는 룰 세트에서 사용되지 않으면, 단순히 매핑 테이블로부터 삭제되지만, 포함하는 룰 세트에서 사용되면, 사용자는, 변수가 더 이상 이용 가능하지 않다고 하는 에러를 얻게 된다.

포함하는 룰 세트는 실제적으로 공유된 룰 세트로부터의 리던던트(redundant) 정보를 유지한다. 구체적으로는, 입력 및 출력 변수 매핑 테이블에서, 포함하는 룰 세트는 공유된 룰 세트 내의 비지니스 명칭의 리스트를 자신의 대응하는 명칭과 함께 유지하기만 하면 된다. 효율성을 위해, 포함하는 룰 세트는 또한 공유된 룰 세트의 타입, 디폴트 값, 설명 및 코멘트, 모든 복사본을 유지한다. 이들 값은 포함하는 룰 세트를 편집할 때만 독출되지만, 보고서 생성 및 다른 분석을 위해 효율성의 측면에서 포함된다.

공유된 룰 세트 매핑 테이블은 또한, 부가 코멘트로서, 포함된 룰 세트 내에 하나의 부가 엔트리를 가진다. 이것은 사용자로 하여금 매핑된 값에 추가의 코멘트를 부가할 수 있도록 한다.

공유된 룰 세트를 위한 상수

공유된 룰 세트의 입력 및 출력 변수에 대한 상수가 포함된 룰 세트를 위한 매핑 테이블 내에 포함된다. 공유된 룰 세트에 의해 사용되는 상수는 그 변수들 자체에 매핑되어야 할 수도 있다. 입력 변수에 대해, 공유된 룰 세트는, 내부적으로, 상수에 대하여, 그 입력 테이블에서 정의된 필드를 비교할 수 있다. 공유된 룰 세트가 다른 룰 세트에 포함되어 있으면, 그 입력 변수에 대한 상수는 포함하는 룰 세트로 복사되어 넘어간다. 그러면, 사용자는 포함하는 룰 세트의 컨텍스트 내의 값을 교체할 수 있다. 통상, 사용자가 공유된 룰 세트 입력 변수와 포함하는 룰 세트의 변수 사이의 매핑을 정의한 경우, 두 변수간의 상수는 매칭될 것이다. 그렇지 않은 경우에는, 사용자는 공유된 룰 세트에 의해 정의된 모든 상수 값에 대해 기술적 값을 제공할 필요가 있을 것이다.

룩업 파일

룰 세트는 선택적으로 하나 이상의 룩업 파일을 가질 수 있다. 룰 세트 내의 각각의 룩업 파일은 다음과 같은 정보를 포함한다.

1. 룩업 파일의 비지니스 명칭

2. 선택적인(optional) 설명 및 코멘트

3. 키를 구성하는 필드에 대한 비지니스 명칭의 리스트. 이들 명칭은 룩업 파일이 식에 부가될 때 사용되어, 사용자가 "lookup(My Lookup File, <customer name key>, <account type key>)"와 같은 것을 보게 된다.

4. 각각의 키에 대한 디폴트 식의 리스트

5. 룩업 파일의 기술적 명칭. 몇몇 예에서, 이것은 전개(deployment)에서 대체될 수 있다.

6. 하나 이상의 룩업 데이터 세트. 각각의 룩업 파일은, 룰 세트가 입력 데이터 세트에 구속되듯이, 시스템 내에서 데이터 세트에 느슨하게 구속된다. 디폴트로서, 룰 세트의 각 룩업 파일과 연관된 하나의 룩업 데이터 세트가 있지만 대체 전개에서 사용하기 위해 더 많은 룩업 데이터 세트가 있을 수 있다.

7. 입력 변수 및 상수의 테이블. 이것은, 각 룩업 파일에 대해 하나의 테이블이 있는 경우를 제외한, 룰 세트에 대한 입력 변수 및 상수의 테이블과 같다. 입력 변수에 대해, 룩업 파일에 대한 입력 변수 및 상수의 테이블은 연관된 룩업 데이터 세트 각각에 대응하여 다수의 기술적 명칭을 가질 수 있다.

룩업 파일은, 하나 이상의 룩업 파일이 있을 수 있다는 것을 제외하면, 입력 변수와 같이 취급된다. 각각의 룩업 파일은, 한 페이지 상에서 편집되고, 비지니스 명칭과 기술적 명칭 간의 매핑 테이블을 가지며, 다수의 데이터 세트와 연결될 수 있다. 그들은 또한 각 필드와 연관된 상수를 가진다. 룩업 파일에 대한 매핑은, 입력 변수에 대한 메타 데이터가 입력 데이터 세트로부터 로드되는 것 처럼, 입력 데이터 세트를 위한 메타 데이터를 독출함으로써 개시될 수 있다.

만일 사용자가 룩업 필드 변수를 사용하고 그 룩업 내에서 키가 발견되지 않으면, 필드의 값은 널(null)로 간주된다. 필드가 널(null)이어서 룰 케이스가 명확하게 트리거하지 않으면, 그 룰 케이스는 거짓(false)로 평가되어 건너뛰어질(skipped) 것이다. 이러한 경우, 에러는 생성되지 않는다. 만일 사용자라 룩업 파일 변수(필드가 아니라 룩업 파일 그 자체)를 사용하는 경우, 함수 lookup_match가 나타나 그 룩업 파일 변수가 참 또는 거짓으로 평가된다. 두 가지 경우는 모두 입력 또는 출력 컬럼 중 하나에 대한 룰 식에 적용된다. 사용자가 룩업 필드 변수를 출력 변수 디폴트로서 사용한다면, 룩업 찾기를 실패한 것은 NULL로 해석된다.

파라미터

룰 세트를 파라미터를 참조할 수 있다. 몇몇 예이서, 각 룰 세트는 선택적으로 파라미터 테이블을 가질 수 있는데, 이것은, 변수 테이블처럼, 파라미터의 비지니스 명칭을 그것의 기술적 명칭에 매핑시킨다. 파라미터 테이블의 각 엔트리는 다음과 같은 속성을 가진다.

1. 비지니스 명칭. 이것은 파라미터의 명칭이고, 룰 본문에 나타날 것이다. 일반적으로 파라미터는 입력 변수가 사용되는 곳이라면 어디든 사용될 수 있다.

2. 기술적 명칭. 이것은 전개 환경에서의 파라미터의 명칭이다.

3. 파라미터의 타입(스트링, 10진수, 날짜 또는 일시). 생성된 변환에서, 파라미터는 필요에 따라 다른 타입으로 변환될 수 있다.

4. 선택적인 설명 및 코멘트

파라미터는, 그 값이 전체 입력 파일에 걸쳐 상수이고 프로세싱이 시작되면 외부적으로 특정된다는 것을 제외하면 변수와 같다.

테스트 룰

변환을 생성하거나 갱신하는 것의 일부로서 그것이 대응하는 룰을 테스트하는 것이 있다. 룰은 또한 유효하게 되는데, 다시 말해 신택스(syntax) 와 시멘틱(semantic) 일관성이 검증된다. 유효화에 대비하여, 테스트는 룰의 실행을 포함하고, 사용자에 의해 교정이 결정되는데, 예컨대 기대되는 출력을 제공하거나 또는 출력을 기대 값과 수작업으로 비교함으로써 행해진다.

소프트웨어는 두개의 레벨로 테스트를 지원한다. 상술한 바와 같이, 각 룰은, 기대되는 결과와 값을 가진 테이블이 내장된 형태의 연관된 테스트 데이터 세트를 가질 수 있다. 이것은 유닛 테스트로 칭해진다. 룰을 편집할 때, 테스트 데이터의 각 라인 별로 룰의 출력을 재평가하는 것이 가능하다. 실제 결과와 기대한 결과 사이의 불일치나 유효한 결과의 생성에 실패한 것은 해결을 위해 강조하여 표시된다.

몇몇 예에서, 외부 입력 테스트 파일은 표준 메커니즘을 사용하는 서버 프로세스로 액세스 가능하다. 외부 파일을 이용한 테스트는 파일 테스트라고 칭해진다. 테스트 파일은 룰 세트를 위한 입력 데이터 세트와 매칭하는 레코드 포맷을 가진다. 몇몇 예에서, 대체하는 다른 레코드 포맷이 제공될 수 있다. 선택적으로, 사용자는 기대되는 결과를 포함하는 데이터 세트를 식별할 수 있다. 소프트웨어는 그 테스트 데이터에 대해 룰 세트를 실행하고, 어떤 결과가 왜 나왔는지 디스플레이한다. 만일 기대한 결과가 포함되어 잇으면 소프트웨어는 실제 결과를 그 기대한 결과와 비교하고 상이한 레코드를 열거한다. 일부 예에서, 사용자로 하여금 개별 값을 보다 많이 보유할 수 있도록 인터페이스가 확장될 수 있다.

유닛 테스트와 파일 테스트 간에 다음과 같은 차이가 있다.

1. 룩업 파일: 유닛 테스트 모드에서는, 각각의 테스트 케이스에 대해, 각 룩업 변수에 대한 값이 테스트의 일부로서 정의된다. 어떤 키도 특정되지 않으며, 테스트가 실행된 때, 각 테스트 케이스에 대해 각 룩업 변수에 대해 동일한 값이 취해진다. 테스트 데이터 세트는 다수의 테스트 케이스를 포함하고, 각 테스트 케이스는 각 룩업 변수에 대해 상이한 값을 특정할 수 있다. 파일 테스트 모드에서는, 실제 룩업 파일이 사용된다. 이것은 상이한 키들이 상이한 값을 리턴한다는 것을 의미하지만, 이것은 또한 특정 키에 대해 임의의 주어진 룩업 변수에 대해 사용된 값이 테스트 중에는 변경될 수 없다는 것을 의미한다.

2. 포함된 룰 세트: 유닛 테스트 모드에서는, 포함된 룰 세트는 실행되지 않고 심지어 완성될 필요도 없다. 대신, 각 포함된 룰 세트로부터의 각 출력을 위해 테스트 데이터 세트 내에서 값이 특정된다. 파일 테스트 모드에서는, 포함된 룰 세트는, 실제 실행되는 것과 같은 방식으로 실행된다. 이것은, 포함된 룰 세트에 의해 필요한 모든 룩업 파일 또는 파라미터가 테스트시에 특정되어야 한다는 것을 의미한다.

3. 파라미터: 유닛 테스트 모드에서, 상이한 값이 각 테스트 케이스에 대한 각 파라미터에 대해 설정될 수 있다. 파일 테스트 모드에서는, 각 파라미터의 값은 전체 테스트에서 상수이다.

4. 현재 날짜: 테스트시, 룰이 현재의 날짜와 시간을 참조하면 사용자는 현재의 날짜와 시간을 위해 취해야 할 값을 특정한다. 유닛 테스트 모드에서는, 날짜 및 시간은 각 테스트 케이스마다 다르게 될 수 있다. 파일 테스트 모드에서는, 하나의 날짜 및 시간이 모든 테스트에 대해 설정된다(이 값은, 테스트가 실행될 때의 머신의 날짜 및 시간과 다를 수 있다).

5. 레코드 포맷 및 매핑: 유닛 테스트에서 매핑은 특정될 필요가 전혀 없다. 테스트는 순전히 변수의 비지니스 명칭에 기초하여 행해진다. 파일 테스트에서, 모든 변수는 기술적 명칭에 매핑되고, 입력, 출력, 룩업의 레코드 포맷이 특정된다.

도 4a의 출력 화면의 예에서, 결과 테이블(410)이 도시되어 있고, 여기에는 각 테스트 케이스의 출력이 각 행(412i)에, 각각에 대해 연산된 결과 및 테스트 케이스를 보여주는 컬럼(413a-d)과 함께 표시되어 있다. 하나의 행(412b)이 선택된 때(도 4a에서 점선으로 표시된), 대응하는 테스트 케이스로부터의 입력 값(414a-141g)이 입력 테이블(414)에 나타나 있다. 그 테스트 케이스에 대한 출력(416a-416c)이 출력 테이블(416)에 나타나 있다. 테이블(416)에 나타난 출력(416i)은 테스트 케이스로부터의 기대되는 출력일 수도, 연산된 실제 출력일 수도, 양자일 수도 있다. 여러가지 인터페이스 큐이(cue)가 테스트의 상태에 대해 사용자에게 통지하기 위해 사용될 수 있다. 예컨대, 아이콘(419)은 테스트 케이스(2,4)에 대한 행(412b, 412d)에서의 출력이 가장 최근에 룰 세트가 테스트된 것으로부터 변경되었다는 것을 나타낸다. 다른 어떤 룰과도 매칭되지 않는 입력 값의 조합을 취하는 "디폴트" 룰이 없다면, 그러한 입력을 가진 테스트 케이스는 널(null) 출력(418)을 생성한다. 만일 입력 레코드가, 예컨대 0(영)으로 나누어지거나 하는, 처리 에러로 거절된다면, 동일한 방식으로 에러가 표시될 수 있다. 만일 하나 이상의 룰 케이스가 테스트 케이스에 의해 트리거링된다면, 트리거링된 룰 케이스의 수가 표시된다(422). 표시된 출력 중 하나와 상호작용함으로써(예컨대, 그것을 클릭하는 것에 의해), 사용자는, 도 4b에 도시된 바와 같이, 그 출력이 어떻게 결정된 것인지에 대해 상세하게 나타내는 화면을 볼 수도 있다.

도 4b의 출력 화면의 예에서, 테이블(430)은 도 4a에서의 단일 테스트 케이스(412)의 룰을 표시하고, 모든 룰 케이스(434i)에서 참이었던 각 입력 판단기준(436i)을 굵은 선으로 나타내고 있다. 예컨대, 여섯번째 룰 케이스(434f)에서, 세번째 및 네번째 입력(436c, 436d)에 대한 값을 포함하는 셀이 강조되어 표시되는데, 왜냐하면 이 테스트 케이스(412)에서 이들 입력에 대한 값(412f, 412g)이 룰 케이스의 값과 매칭되기 때문이다(등급은 1등석(first)도 비지니스석(business)도 아니고, 좌석열은 40이하다). 실제로는, 하이라이트, 색깔, 폰트 또는 경계선 등의 임의의 다양한 그래픽 기술이 참과 거짓 셀을 구별하기 위해 사용될 수 있다. 모든 값이 테스트 케이스와 매칭되는 제1 룰 케이스(434c)가, 룰을 트리거링하고 도 4a에서 412b에 의해 나타난 출력을 생성한 룰 케이스와 같이, 점선으로 된 경계선으로 표시되어 있다. 트리거링된 룰 케이스(434c)뿐 아니라 다른 룰 케이스도 표시함으로써 사용자로 하여금 어떤 룰 케이스가 적용되었고 원하는 출력을 얻기 위해 어떤 변화가 필요한지를 빠르게 결정할 수 있도록 한다. 몇몇 예에서, (예컨대, 상위의 것들이 없었더라면) 트리거링될 수 있었던 다수의 룰 케이스가 표시될 수 있다. (만일 트리거링되었더라면) 각 룰 케이스에 의해 생성되었을 출력이 컬럼(438)에 표시될 수 있다. 이러한 특징은, 예컨대 룰 케이스를 디버깅하는 것을 지원할 수 있다.

몇몇 예에서, 하나의 룰 세트의 출력은 다른 룰 세크의 입력이 될 수 있다. 그러한 경우에 주어진 테스트 케이스가 다른 룰 세트에 의해 어떻게 평가되는지가 도 4c에 도식적으로 나타나 있다. 도 4a 및 4b로부터 테스트 케이스 탑승객을 탑승 그룹 2에 넣은 비지니스 룰이 박스(442)로 표시된다. 박스(442)는 테스트 케이스 테이블(412)로부터 입력을 수신하고 출력 테이블(416)에 출력을 제공한다. 이 예에서, 연간 마일리지가 증가하는 탑승객이 보상되어야 한다는 것을 제2 비지니스 룰이 나타낸다. 이 룰은 테이스 케이스로부터의 입력 외에도 입력으로서 제2 룰로부터 마일리지가 증가하고 있다는 판정을 수신하며, 박스(444)로서 도시되어 있다. 탑승객이 2등석(coach)이기 때문에, 이 룰은 고객에게 무료 음료를 준다(만일 고객이 1등석이었다면, 그녀는 이미 무료 음료를 받았을 것이고 다른 보상이 주문될 것이다). 몇몇 예에서, 표시된 룰을 클릭함으로써 사용자로 하여금 그 룰이 어떻게 트리거링되었는지를, 제1 룰(442)에 대한 도 4b에 나타낸 바와 같이, 볼 수 있게 한다.

룰 세트는, 도 5에 도시된 과정에 따라 테스트되고 유효화된다. 하나 이상의 룰 세트(602) 및 대응하는 테스트 데이터(604)는 이 과정에 대한 입력이다. 소프트웨어는 룰 세트에 기초하여 변환(606)을 생성하고, 그것을 이용하여 테스트 데이터 내의 모든 레코드에 대한 출력 값을 연산한다. 그래프 연산에서, 관련된 구성요소의 'log' 포트는 출력을 테스트하기 위해 사용된다. 테스트용으로 생성된 변환은 실행을 위해 생성될 변환과는 약간 다를 수 있다. 이 출원은, 실제 출력을 생성한 룰 세트의 식별과 그 룰 세트의 어느 룰 케이스가 그 출력에 관여되었는지를 포함하는 어레이이다. 다수의 출력이 각 테스트 케이스에 대해, 즉 상이한 룰 세트로부터 상이한 출력이, 생성될 수 있다. 이 어레이는, 상술한 바와 같이, 도 4a 및 4b에 도시된 출력 테이블을 생성하기 위해 사용될 수 있다. 몇몇 예에서, 테스트 출력은 단순한 어레이보다 더 복잡하다. 출력은, 주어진 레코드에 대한 모든 입력의 값, 모든 파라미터의 값, 포함된 룰 세트로부터의 모든 출력의 값, 모든 룩업 파일로부터 독출된 값(그 룩업을 위해 어느 키가 사용되었는지를 나타내는 것을 포함)을 포함한다.

제1 테스트 케이스를 가지고 시작한다(608). 테스트 케이스의 입력은 변환으로 입력된다(610). 그리고 출력은, 어느 룰이 그것을 생성했는지에 대한 표시와 함께, 출력 어레이에 기록된다(612). 이 과정은 각 행에 대해 반복되는데(614, 616), 마지막 행이 평가될 때까지 반복된다(614). 출력 어레이는 상술한 결과 테이블(410, 420)을 생성하는데 사용될 수 있다. 출력 어레이는, 도 5의 나머지 단계에 나타나 있듯이, 룰 세트가 유효한지 결정하기 위해 평가될 수 있다. 하나의 테스트로부터 생성된 출력 값이 이전 테스트에서 생성된 값과 비교될 수 있으므로, 출력 값은 테스트 데이터에 포함될 수 있다. 출력 어레이의 제1 행을 가지고 시작한다(618). 생성된 출력은 테스트 데이터(604)로부터 또는 이전의 테스트 결과(617)로부터의 기대 출력과 비교된다(620). 만일 매칭되는 출력이 없으면, 불일치(mismatch)가 기록(로그(log))된다. 이것은 각 행(624, 626)에 대해 반복된다. 몇몇 예에서, 평가 단계는 출력 생성 단계에 통합되고, 각각의 생성된 출력은 생성되는 대로 대응하는 기대 출력과 비교된다. 테스트 데이터 결과를 처리함에 있어서의 어떠한 불일치 또는 다른 에러는 기록(log)된다. 상술한 바와 같이, 하나의 룰 세트의 출력은 다른 룰 세트에의 입력이 될 수 있고, 여기서 포함된 룰 세트는 포함하는 룰 세트의 일부로서 평가된다.

사용자는 출력 필드에 의해 테스트되는 룰을 제한할 수 있다. 몇몇 예에서, 사용자는 테스트 동안 디스에이블할 룰을 선택할 수 있다. 몇몇 에에서, 사용자는 모든 테스트 파일이 처리되기를 기다릴 필요가 없다. 테스트 결과는, 처음 몇몇 레코드가 제대로 동작하여 출력하기만 해도 사용가능하게 된다.

테스트 데이터 그 자체에 더하여, 다음의 정보 중 어느 것이든 파일 테스트를 위해 사용될 수 있고, 룰 세트의 일부로서 포함될 수 있다.

1. 입력 데이터 세트의 물리적 위치. 이것은 각 입력 데이터 세트의 입력 변수 테이블 내의 룰 세트 내에 저장된다. 결합-타입 데이터 세트에 있어서는, 모든 물리적 위치가 필요하다. 물리적 위치가 필요할 때마다, 데이터베이스 내의 테이블 명칭이 사용될 수 있다.

2. 입력 데이터 세트의 레코드 포맷. 이것은 디폴트로 입력 데이터 세트를 위한 데이터 세트 정의로부터 얻어진다. 샌드박스(sandbox) 내로 들어간 상이한 레코드 포맷으로 이것을 대체하기 위해 입력 변수 내에 공간이 있다. 결합-타입 변환에서, 모든 레코드 포맷이 필요하다.

3. 어느 전개가 사용될 것인가

4. 모든 룩업 파일에 대한 물리적 위치. 이것은 룩업 파일 테이블 내에 저장된다.

5. 각 룩업 파일에 대한 레코드 포맷. 각 룩업 파일과 연관된 데이터 세트 정의로부터 얻어지거나 또는 대체 레코드 포맷 파일로부터 얻어진다.

6. 각 파라미터에 대한 값. 이것은 테스트 파라미터 다이얼로그 내에서 설정될 것이다.

7. 출력 파일의 물리적 위치. 이것은 복귀(regression)(비교(comparison)) 테스트를 하는 때에 필요할 뿐이다. 이것은 출력 변수 테이블 내에 저장된다.

8. 출력 파일의 레코드 포맷. 이 또한 복귀(비교) 테스트를 하는 때에 필요할 뿐이다. 출력 데이터 세트 정의 또는 옵션인 대체 레코드 포맷 파일로부터 얻어진다.

9. 프로젝트 샌드박스의 위치. 테스트는 샌드박스 또는 호스트로부터 수행되어야 한다. 샌드박스는 룰 세트를 포함하는 프로젝트의 일치된 복사본이어야 한다. 모든 레코드 포맷 파일은 샌드박스로부터 얻어질 것이다.

10. 룰이 "now", "today", 또는 이와 유사한 값을 참조할 때, 날짜 및 시간으로 사용할 값.

세가지의 가능한 변환 타입이 있다. 하나는 기록(logging)이 없는 것, 또 하나는 모든 입력, 출력, 실행된 룰 등을 기록하는 것, 나머지는 추가적으로 각 룰에서 어느 셀이 거짓 또는 널(null)인지에 대한 상세를 포함하는 것이다. 테스트는 후자의 기록을 동반하는 두가지 타입 중 하나를 이용할 수 있다. 만일 변환이 셀 상태를 기록하지 않으면, 이것은 단지 사용자 인터페이스에 나타나지 않을 뿐이다. 입력, 출력 등을 기록하는 것은 실행 속도를 느리게 하지만 그 정도는 크지 않다. 셀의 상태를 기록하는 것은 실행 속도를 상당히 느리게 하는데, 아마도 크기에 비례할 것이다.

테스트를 하지 않을 때, 사용자는 여전히 입력, 출력 등을 기록하는 변환을 생성할 수 있고, 결과를 내기 위해 그 변환을 사용할 수 있다. 향상된 변환은 동일한 결과를 생성하는데, 물론 실행후에 어느 룰이 실행되었는지 결정하기 위해 분석될 수 있는 일련의 로그 메시지도 생성한다. 사용자가 생성된 로그를 저장하면, 비지니스 룰 환경(Business Rule Environment)은, 테스트 입력이 사용되지 않았어도, 그 후에, 도 4a, 4b 및 4c의 정보를 연산하기 위해 로그 내의 정보를 이용하여 결과를 얻기 위해 설정된 룰의 실행을 재연하기 위해 사용될 수 있다. 우리는 이 실행을 재생(playback)이라고 하며 이것은 감사를 위해 유용하다.

오버랩 분석(Overlap Analysis)

몇몇 예에서, 상술한 바와 같이, 사용자가 테스트 데이터 세트를 룰 세트에 대해 실행할 때, 트리거링된 모든 룰이 추적될 수 있다. 즉, 모든 입력 조건이 만족되었고, 상위 우선도를 가진 룰 케이스가 또한 모든 입력 조건을 만족하지 않았다면 결과를 생산해 내었을 룰 케이스가 추적될 수 있다. 테스트 데이터를 처리한 후, 소프트웨어는 테스트 출력 데이터를 사후 처리(post-process)하고 임의의 테스트 케이스에 의해 트리거링되지 않은 모든 룰 또는 룰 케이스의 리스트를 생성할 수 있다. 이 정보는, 어느 룰이 트리거링되지 않았는지 사용자에게 신속하게 보여주기 위해 편집기 내에서 룰의 표시 상에 중첩되어 나타내어진다. 이 정보로부터, 사용자는 다른 룰에 의해 가려질 가능성이 있는 룰, 즉 중첩하는 룰를 찾을 수 있다. 각 룰 케이스에 대한 카운트(count)가 보여질 수 있다. 카운트는, 특히 원하는 출력의 분포를 달성하기 위해 값을 조정하고 또 성능을 조정하기에 가장 적합한 룰 케이스를 식별하기 위해, 룰 케이스가 트리거링했는지를 아는 것만큰 유용할 수 있다.

변환 생성

비니지스 룰은 각 룰 세트를 변환으로 전환함으로써 어플리케이션(그래프)에서 평가된다. 그런 다음, 변환은 그래프 내의 구성요소에 부여된다. 그러한 구성요소는, 그 변환을 실행하는 특정 방법으로 연결된 한 세트의 표준 구성요소를 포함하는 서브그래프일 수 있다. 그러면, 이들 서브그래프는, 예컨대 결합과 롤업을 위한 키를 사용하기 위한 추가의 구성요소와 함께 사용될 수 있다.

변환 코드는 여러 가지 방법으로 비지니스 룰로부터 생성될 수 있다. 변환의 내부가 사용자에 의해 편집되도록 설계되지 않은 예에서, 생성 프로세스는 이해하기 어려운 변환을 낳을 수 있지만, 룰을 하나씩 적용하는 것보다 효율적으로 그 룰을 실행한다. 몇몇 예에서, 도 6에 도시된 바와 같이, 간단한 if-then-else 연결문(500)은 룰 세트 내의 논리를 파악하기 위해 사용될 수 있다(참고를 위해, 도 2a의 룰 세트 테이블(200)이 반복된다). 연결문(500)에서, 각각의 룰 케이스(210a)에는 하나의 'if...then...'문(502i)이 있다. 이러한 연결문은 그대로 사용될 수도 있고 또는 시스템의 사용자의 속송 및 적절한 연산 리소스의 가용성에 기초하여 더 최적화될 수 있다. 몇몇 예에서, 생성된 변환의 성능을 향상시키기 위해 보다 특수화된 룩업 파일 및 다른 기술이 사용될 수 있다. 변환이 어떻게 생성되는지에 대한 어느 정도의 상세가 전개 내에 저장될 수 있다. 다수의 그래프에서 사용될 수 있는 룰 세트는 상이한 가능한 사용자를 위한 여러 가지 전개를 가진다. 룰 세트는 또한 룰의 수퍼 세트를 포함할 수 있고, 오직 몇몇만이 각 전개(이 전개는 변환이 생성될 때 어느 룰이 사용될 것인지 식별한다)에서 요구된다.

일부 예에서, 룰이 십진수인 컬럼을 포함하고 그 컬럼에 매칭된 수많은 상이한 값이 있다면, 우리는 지정된 컬럼에 연결하여 '스위치(switch)'문을 기입함으로써 변환의 성능을 향상시킬 수 있다. 예컨대, 다음과 같은 룰을 가정하자.

비행 번호(fligh number)	좌석 열(Row of Seat)	탑승 그룹(출력)
1	<10	1
1		2
2	<15	1
2		2
3		1
4		1
5	<10	1
5	<20	2
5		3

이 룰에 대한 변환은, 이하와 같이 두가지 방식으로 생성될 수 있다.

if(NUM==1 and ROW<10) then BG=1

else if(NUM==1) then BG=2

else if(NUM==2 and ROW<15) then BG=1

else if(NUM==2) then BG=2

else if...

또는,

Switch(NUM)

Case 1: if(ROW<10) then BG=1 else BG=2

Case 2: if(ROW<15) then BG=1 else BG=2

...

우리가 이용할 수 있는 다른 테크닉은 메모리내 룩업 파일(in-memory lookup file)이다. 만일 룰이 대신, 우리는 룩업 테이블을 사용할 수 있다. 이 경우, 룩업 테이블은 룰의 일부이다(별도로 저장되지 않는다). 예컨대, 다음 룰을 가정하자.

출발도시	도착도시	서비스 등급	식	마일리지(출력)
BOS	LAX	First		6000
BOS	LAX	Business		3000
BOS	LAX	Coach	Is Using Miles = yes	0
BOS	LAX	Coach	else	3000
BOS	CHI	First		2000
BOS	CHI	Coach		1000
BOS	NYC	First		1500
BOS	NYC	Business		1000
BOS	NYC	Coach		500

이 룰은 다음의 정보를 가진 메모리내 룩업 테이블을 구축함으로써 처리된다.

from	dest	class	expr	miles
BOS	LAX	1	0	6000
BOS	LAX	2	0	3000
BOS	LAX	3	1	3000
BOS	CHI	1	0	2000
BOS	CHI	2	0	1000
BOS	NYC	1	0	1500
BOS	NYC	2	0	1000
BOS	NYC	3	0	500

그러면, 변환은 다음과 같이 된다.

int expr=lookup(from, dest, class).expr

int miles=lookup(from, dest, class).miles

if(expr==1 and is_using_miles) miles=0

return miles

각 룰 세트는 전개 테이블을 가진다. 전개 테이블은 그 전개의 구성에 대한 상세에 명칭을 매핑시킨다. 전개 테이블의 각 엔트리는 다음 정보를 포함한다.

1. 전개 명칭. 룰 세트 내에서 유일해야 하는 임의의 스트링(arbitrary string).

2. 입력 데이터 세트 명칭. 입력 변수 테이블 내에 열거된 다수의 입력 데이터 세트가 있다면, 전개 테이블의 각 엔트리는 어느 입력 데이터 세트가 이 전개에서 사용되는지를 나타낸다.

3. 출력 데이터 세트 명칭. 출력 변수 테이블 내에 열거된 다수의 출력 데이터 세트가 있다면, 전개 테이블의 각 엔트리는 어느 출력 데이터 세트가 이 전개에서 사용되는지를 나타낸다.

4. 각 포함된 룰 세트에 대한 전개 명칭. 각각의 포함된 룰 세트에 대해, 우리는, 포함하는 룰 세트의 대응하는 각 전개를 위해 어느 전개가 사용되어야 하는지를 나타낼 필요가 있다.

5. 구성요소 및 생성될 변환 파일의 타겟 위치

몇몇 예에서, 디폴트라고 하는 적어도 하나의 전개가 항상 있다. 이것은 다른 어떤 전개도 특정되어 있지 않을 때 사용되는 전개이다.

하나의 실시예로서, 변환 생성의 기본에 대해 설명한다. 첫째, 소프트웨어가 룰 세트에서 연산되는 출력에 대해 룰을 생성하기만 할 것이다. 모든 다른 출력은 변환에서 와일드카드 룰로 처리될 것이다. 일반적으로, 내부적으로만 사용되는 출력 변수는 생성된 변환에서 로컬 변수가 생성되도록 한다. 즉, 생성된 변환은, 필요하다면, 중복 연산을 피하기 위해(예컨대, 공간보다 속도를 최적화하는 경우) 보다 많은 로컬 변수를 포함할 수 있다.

도 7은 생성된 변환 내에서 룰 세트가 어떻게 평가되는지를 보여준다. 각 출력(702)에 대해, 관련 룰은 순서대로 평가된다. 연결되지 않은 출력을 생성하는 룰에 대해, 변환 생성기는 의존성 분석(dependency analysis)에 기초하여 룰의 평가 순서를 정한다. 순환성은 허용되지 않으며, 에러로서 보고된다. 만일 둘 이상의 룰이 동일한 출력을 생성한다면, 그들의 실행 순서는 룰 세트 내에서, 리스트 상의 열거 순서와 동일하다. 각 룰(704) 내에서, 룰 케이스는 위에서 아래로 순서래도 평가된다. 각 룰 케이스(706)에서, 각 룰의 트리거 컬럼은 정의되지 않은 순서(예컨대, 소프트웨어가 단일 케이스의 룰 내에서 평가의 순서를 보장하지 않는다)로 평가될 수 있다(708). 모든 트리거가 참인(0(영)이나 거짓이 아니고, 널(null)도 아닌) 하나의 룰 케이스가 발견되는 즉시(704), 대응하는 출력 값이 사용된다(716). 룰 케이스가 거짓을 평가하는 한, 프로세스는 계속된다(718, 712, 720, 722). 주어진 출력에 대해 트리거링되는 룰이 전혀 없다면(720), 변환은 출력 값을 명백하게 NULL로 설정하거나 적절하다면 디폴트 값으로 설정할 것이다(724).

변환 타입에 따라 몇몇 차이점이 있다.

● 리포맷(Reformat) - 입력은 "in,"이라고 불리고, 입력 변수는 "in.field."와 같은 기술적 명칭을 가질 수 있다. 출력은 "out,"라고 불리고, 출력 변수는 "out.field."와 같은 기술적 명칭을 가질 수 있다.

● 결합(Join) - 두개의 입력은 "in0" 및 "in1"로 불리며, 출력은 "out,"으로 불리고, 와일드카드 룰은 in0가 "out."으로 복사되는 것으로 가정한다. 모든 파라미터는, 구성요소가 생성된 때 설정될 수 있다. 룰 세트는, 결합으로의 각 입력에 대해 하나씩, 다수의 입력 세트를 가질 것이다. 룰 세트는 또한, 어느 입력이 중복제거되어야 하는지의 결합 타입과, 결합에 키로서 사용된 필드의 비지니스 명칭을 특정할 것이다(몇몇 예에서, 이것은 각 입력 세트에 나타나 있어야 한다). 또한, 사용자는 입력 필터로 사용되는 각 입력에 대한 식을 특정할 수 있다.

● 롤업(Rollup) - 입력은 "in"이라 불리고, 출력은 "out."으로 불린다. 롤업-타입 룰 세트의 경우, 사용자는 수집 함수(aggregation function)(다른 변환 타입에서는 지원되지 않는다)을 사용하는 것이 허용된다. 만일 사용자가 기술적 명칭이 "input_select" 또는 "output_select"인 출력 변수를 생성하면, "input_select" 및/또는 "output_select" 함수가, 그 출력을 연산하는 룰의 로직을 가진 변환에 부가된다. 그러한 함수 모두의 입력은 "in"으로 불린다(비록 output_select는 그의 파라미터를 "out"로 칭하지만). 결합 타입에서, 모든 파라미터는 구성요소가 생성될 때 설정될 수 있다.

● 필터(Filter) - 미리 정의된 두 개의 상수 중 하는 출력이다. 필터-타입 변환에서의 유일한 출력 변수는 타입 구성요소의 "select,"이고, 이것은 출력을 보내기 위해 0이 아니고 NULL도 아니다(non-zero, non-NULL). 몇몇 예에서, 이것은 서브그래프에서 리포맷 구성요소로서 실행된다.

추가적인 변환 타입이 또한 구현될 수 있다.

● 스캔(Scan) - 스캔 함수는 두개의 입력을 취하는데, 그 입력의 이름은 "temp" 및 "in"이고, "out."의 이름을 가진 출력을 생성한다. 룰 세트 내의 룰은 temp 및 in의 양측 레코드로부터의 필드를 사용할 수 있다. 이것은 입력 변수의 기술적 명칭으로 결정될 수 있다(예컨대, 기술적 명칭은 "temp.field" 또는 "in.field"와 같은 스트링으로 설정될 수 있다).

변환의 임시 변수("temp")에 대한 레코드 포맷은 룰 세트에 의해 성성된 모든 출력을 포함한다. 초기화 함수는 임시 레코드 포맷의 모든 필드를 디폴트 값으로 초기화하기 위해 소프트웨어에 의해 자동으로 생성된다. 파이널라이즈 함수 또한 소프트웨어에 의해 자동으로 생성될 수 있는데, 이 함수는 단순히 임시 레코드를 출력에 복수하고 와이드카드 룰을 부가한다. 스캔-타입 변환은 또한 롤업의 경우처럼, 기술적 명칭을 가진 변수들이 출력 변수 테이블 내에 있는 경우, input_select 함수 및 output_select 함수의 생성을 지원한다.

● 표준화(Normalize) - 표준화 함수는 "in"과 "index"의 두개의 입력을 가진다. 그리고 "out."의 이름을 가진 출력을 생성한다. index 입력은 레코드가 아니며, 대신 사용자는, 그들이 룰 내에서 인덱스를 사용하기를 원한다면, 인덱스의 기술적 명칭에 매핑되는 입력 변수를 생성한다. 인덱스 변수는 다양한 DML 식에서 사용될 수 있다. 소프트웨어는 상술한 바와 같이 룰을 통해 나아가는 만큼 길이를 가진다.

표준화-타입 룰 세트는 또한, 롤업-타입 룰 세트와 마찬가지로, "input_select" 및 "output_select"의 이름으로 된 출력 변수를 지원한다.

● 분류(Classification) - 룰은 N개의 추력을 가지고, 변환은 각 레코드에 대해 어느 출력이 사용되어야 하는지를 결정한다. 이 구성요소를 위해, 소프트웨어는 출력 분류 함수를 생성한다. 출력은 단일의 정수 값이며, 이것은 어느 출력 포트(하나 이상일 수 있다)가 사용되어야 하는지 나타낸다. 0(영)의 출력은 0번째 포트를 의미하고, 1의 출력은 첫번째 포트를 의미하는 식이다.

분류-타입 변환에서의 유일한 출력 변수는 "select,"의 타입 구성요소이며, 이것은 출력 포트(0을 시작으로 하는)의 인덱스로 될 것이다. 이것은 출력을 위해 두개가 아닌 N개의 값이 사용된다는 것을 제외하면 필터와 유사하다.

● 함수(Function) - 함수-타입 룰 세트는, 구성요소 변환처럼은 아니지만, DML 변환 파일로 바뀔 수 있다. 대신, 함수-타입 룰 세트는 변환으로 바뀌고, 구축된 변환 파일은 다른 변환에 포함되도록 설계된다. 각 출력 변수는 DML 함수로 바뀐다. 그 함수들에 대한 입력은 룰의 타입에 의돈한다. 함수-타입 룰에 있어서, 입력은 테이블 내에서 나열된 순서대로의 룰에 대한 입력이다. 비함수-타입(non-function-type) 룰에 있어서, 각 출력 함수는 in으로 불리는 단일 입력을 취하는데, 이 입력은 입력 변수에 대응하는 모든 필드를 가진 레코드이다.

룰 세트가 그래프의 일부로 될 변환을 생성하는데 사용될 때, 그래프 구성요소는 그 룰 세트의 명칭과 전개를 포함한다. 그러면, 그래프 처리기(graph developer)는 구성요소 내의 생성된 변환 대신에 룰 세트를 편집할 수 있다. 룰 세트에 대한 변경은 변환이 재생성되도록 한다.

다른 특징이나 변형으로서, 예컨대 일부 사용자에게 입력을 더하지 않고 룰을 편집할 수 있도록 허용하는 것과 같이, 보다 정밀하게 짜여진 허가 모델로서, 특정 룰 세트에서 사용되는 룰에 대해 보고서를 생성하는 것을 포함한다. 인트라-룰 의존성 트리(intra-rule dependency tree)가 각 출력에 대해 구현될 수 있다. 룰 또는 룰 세트는 유효 날짜 또는 만료 날짜를 가질 수 있다. 단일의 입력 레코드는 다수의 출력을 생산할 수 있는데, 예컨대, 만일 다수의 룰이 그들의 판단기준이 만족된다면, 첫번째 것만이 아니라 그들 모두가 동작할 수 있다. 벡터 출력에 대한 지원이 제공될 수 있다. 사용자는 비지니스 사용자를 더 보호하거나 억제하기 위해, 편집하는 동안 자신의 유효화 함수를 특정할 수 있다.

위에서 설명한 비지니스 룰 관리 접근법(business rule management approach)은 컴퓨터 상에서 실행되는 소프트웨어를 사용하여 구현될 수 있다. 예컨대, 소프트웨어는, 적어도 하나의 프로세서, 적어도 하나의 데이터 저장 시스템(휘발성 및 비휘발성 메모리 및/또는 저장 소자를 포함한다), 적어도 하나의 입력 디바이스 또는 포트, 및 적어도 하나의 출력 디바이스 또는 포트를 각각 포함하는 하나 이상의 프로그램된 또는 프로그램 가능한 컴퓨터 시스템(분산, 클라이언트/서버, 또는 그리드(grid)와 같은 다양한 아키텍처일 수 있다)에서 실행되는 하나 이상의 컴퓨터 프로그램에서의 처리절차를 구성한다. 소프트웨어는, 예컨대 연산 그래프 디자인 및 구성에 관계된 다른 서비스를 제공하는 더 큰 프로그램의 하나 이상의 모듈을 구성할 수 있다. 그래프의 노드 및 요소는, 컴퓨터 판독가능한 매체에 저장된 데이터 구조 또는 데이터 저장소에 저장된 데이터 모델에 합치하는 다른 조직화된 데이터로서 구현된다.

소프트웨어는 CD-ROM과 같은 매체로서 일반 또는 특수 용도의 프로그램 가능한 컴퓨터에 의해 판독가능한 매체로 제공되거나 도는 그것이 실행되는 컴퓨터에 네트워크를 통해(전달 신호로 부호화되어) 제공될 수 있다. 모든 함수는 특수 용도 컴퓨터, 또는 코프로세서(coprocessor)와 같은 특수 목적의 하드웨어를 사용하여 수행될 수 있다. 소프트웨어는, 소프트웨어에 의해 특정된 연산의 상이한 부분이 상이한 컴퓨터에서 실행되는 분산 방식으로 구현될 수 있다. 각각의 그러한 컴퓨터 프로그램은, 바람직하게는, 일반 용도 또는 특수 용도의 프로그램 가능한 컴퓨터에 의해 판독가능한 저장 매체 또는 디바이스(예컨대, 고체(solic state) 메모리 또는 매체, 또는 자기 매체 또는 광학 매체)에 저장되거나 다운로드되어, 그 저장 매체 또는 디바이스가 컴퓨터 시스템에 의해 판독되어 그 기술된 처리를 수행할 때 그 컴퓨터를 구성하고 작동시킨다. 본 발명에 따른 시스템은 또한 컴퓨터 프로그램과 함께 구성된 컴퓨터 판독 가능한 저장 매체로서 구현될 수 있으며, 여기서 그렇게 구성된 저장 매체는 컴퓨터 시스템으로 하여금 그 저장 매체에 기술된 함수를 수행하도록 특정되고 미리 정해진 방식으로 동작하도록 한다.

본 발명의 많은 실시예가 여기서 설명되었다. 그럼에도 불구하고, 여러 가지 변형예가 본 발명의 기술적 사상이나 권리 범위 내에 있을 수 있다. 예컨대, 상술한 일부 단계들은 순서에 의존하지 않으므로, 상술한 것과 다른 순서로 실행될 수 있다.

앞선 설명은 본 발명의 범위를 한정하기 위한 것이 아니라 본 발명을 설명하기 위한 것임을 분명히 해두는 바이다. 본 발명의 범위를 첨부된 청구범위에 의해 정의된다. 예컨대, 전술한 많은 함수 단계는 전체 처리에 실질적인 영향을 주지 않으면서 다른 순서로 실행될 수 있다. 다른 실시예들이 이하의 청구범위의 권리범위에 포함된다.

150: 생성기
152: 룰 세트
152a: 룰 케이스
154: 편집기
156: 변환
158: 연산 시스템

Claims (40)

1. 데이터 저장 시스템의 데이터에 적용된 하나 이상의 룰을 관리하는 방법으로서,
   입력 디바이스 또는 포트를 통해 상기 데이터 저장 시스템으로부터 데이터를 수신하는 단계; 및
   룰 사양의 부분 또는 전부에 의해 특정된 룰에 따라, 수신된 데이터의 부분 또는 전부를 하나 이상의 프로세서로 처리하는 단계
   를 포함하고,
   상기 처리하는 단계는,
   편집기 인터페이스에, 상기 룰 사양의 복수의 부분들을 디스플레이하는 단계;
   결과 정보를 획득하도록 상기 수신된 데이터의 하나 이상의 레코드에 상기 룰을 적용하는 단계로서, 출력 값을 생성하도록 상기 수신된 데이터의 입력 값에 상기 룰을 적용하는 단계를 포함하는, 룰을 적용하는 단계; 및
   상기 편집기 인터페이스에, 상기 룰 사양의 특정의 디스플레이된 부분과 연관된 상기 결과 정보의 부분 또는 전부를 디스플레이하는 단계로서, 생성된 출력 값을 다른 출력 값과 비교한 결과를 디스플레이하는 단계를 포함하는, 결과 정보의 부분 또는 전부를 디스플레이하는 단계를 포함하고,
   상기 다른 출력 값은 상기 룰 사양의 이전 버전에 대해 생성된 출력 값을 포함하는,
   데이터에 적용된 하나 이상의 룰 관리 방법.
2. 제1항에 있어서,
   상기 룰 사양의 부분은 하나 이상의 룰 케이스를 포함하고, 하나 이상의 룰 케이스는 하나 이상의 잠재적인 입력의 각각에 대한 상태를 정의하고, 하나 이상의 룰 케이스는 정의된 상태를 평가한 결과와 연관된 출력을 정의하는, 데이터에 적용된 하나 이상의 룰 관리 방법.
3. 제1항에 있어서,
   상기 룰 사양의 부분은 하나 이상의 룰 케이스를 포함하고, 하나 이상의 룰 케이스는 하나 이상의 잠재적인 입력의 각각에 대한 상태를 정의하고,
   상기 처리하는 단계는, 상기 편집기 인터페이스에, 상기 룰 케이스의 정의된 상태가 상기 수신된 데이터의 입력 값을 상기 잠재적인 입력으로서 만족했다는 트리거링된(triggered) 룰 케이스의 표시(indication)를 디스플레이하는 단계를 더 포함하는, 데이터에 적용된 하나 이상의 룰 관리 방법.
4. 제2항에 있어서,
   상기 결과 정보의 부분 또는 전부를 디스플레이하는 단계는, 상기 수신된 데이터의 입력 값의 상이한 세트에 대해 트리거링되었다는 트리거링된 룰 케이스의 여러 번의 카운트를 디스플레이하는 단계를 포함하는, 데이터에 적용된 하나 이상의 룰 관리 방법.
5. 제2항에 있어서,
   상기 결과 정보의 부분 또는 전부를 디스플레이하는 단계는, 트리거링된 룰 케이스가 트리거링되는 방법에 대한 정보를 디스플레이하는 단계를 포함하는,
   데이터에 적용된 하나 이상의 룰 관리 방법.
6. 제5항에 있어서,
   디스플레이된 결과 정보의 부분 또는 전부와의 사용자 상호작용에 응답하여 트리거링된 룰 케이스가 트리거링되는 방법에 대한 정보를 디스플레이하는 단계를 더 포함하는, 데이터에 적용된 하나 이상의 룰 관리 방법.
7. 제5항에 있어서,
   상기 트리거링된 룰 케이스가 트리거링되는 방법에 대한 정보는 룰 케이스의 정의된 상태를 평가하도록 사용된 수신된 데이터의 입력 값을 포함하는, 데이터에 적용된 하나 이상의 룰 관리 방법.
8. 제1항에 있어서,
   상기 룰 사양의 부분은 하나 이상의 룰 케이스를 포함하고, 하나 이상의 룰 케이스는 하나 이상의 잠재적인 입력의 각각에 대한 상태를 정의하고,
   상기 처리하는 단계는, 상기 편집기 인터페이스에, 상기 룰 케이스의 정의된 상태가 상기 수신된 데이터의 입력 값을 상기 잠재적인 입력으로서 만족하지 않았다는 트리거링 되지 않은(non-triggered) 룰 케이스의 표시를 디스플레이하는 단계를 더 포함하는, 데이터에 적용된 하나 이상의 룰 관리 방법.
9. 제8항에 있어서,
   상기 결과 정보의 부분 또는 전부를 디스플레이하는 단계는, 상기 수신된 데이터의 입력 값의 상이한 세트에 대해 트리거링 되지 않았다는 트리거링 되지 않은 룰 케이스의 여러 번의 카운트를 디스플레이하는 단계를 포함하는, 데이터에 적용된 하나 이상의 룰 관리 방법.
10. 제1항에 있어서,
    상기 처리하는 단계는, 상기 편집기 인터페이스에, 상기 룰 사양의 특정의 디스플레이된 부분의 디스플레이 상에 덮어 씌워진 결과 정보의 부분 또는 전부를 디스플레이하는 단계를 더 포함하는, 데이터에 적용된 하나 이상의 룰 관리 방법.
11. 제1항에 있어서,
    상기 편집기 인터페이스는, 상기 룰 사양을 편집하고, 편집된 상기 룰 사양의 부분 또는 전부에 의해 특정된 룰을 재적용한(re-applying) 결과를 디스플레이할 수 있게 하는, 데이터에 적용된 하나 이상의 룰 관리 방법.
12. 제1항에 있어서,
    상기 처리하는 단계는,
    상기 편집기 인터페이스에, 상기 룰 사양의 부분 또는 전부를 재정의한(re-define) 정보를 수신하는 단계;
    업데이트된 결과 정보를 획득하도록 상기 수신된 데이터의 하나 이상의 레코드에 상기 룰을 재적용하는 단계; 및
    상기 편집기 인터페이스에, 상기 룰 사양의 특정의 디스플레이된 부분과 연관된 상기 업데이트된 결과 정보를 디스플레이하는 단계를 더 포함하는, 데이터에 적용된 하나 이상의 룰 관리 방법.
13. 제1항에 있어서,
    상기 처리하는 단계는,
    상기 수신된 데이터의 복수의 레코드에 상기 룰 사양의 부분 또는 전부에 의해 특정된 룰을 적용하는 단계; 및
    상기 편집기 인터페이스에, 특정 결과가 상기 수신된 데이터의 레코드에 대해 달성되었다는 여러 번의 카운트를 디스플레이하는 단계를 더 포함하는, 데이터에 적용된 하나 이상의 룰 관리 방법.
14. 데이터 저장 시스템의 데이터에 적용된 하나 이상의 룰을 관리하기 위한 소프트웨어가 내부에 저장된 컴퓨터 판독가능 매체로서,
    상기 소프트웨어는, 컴퓨팅 시스템으로 하여금,
    입력 디바이스 또는 포트를 통해 상기 데이터 저장 시스템으로부터 데이터를 수신하는 단계; 및
    룰 사양의 부분 또는 전부에 의해 특정된 룰에 따라, 수신된 데이터의 부분 또는 전부를 하나 이상의 프로세서로 처리하는 단계
    를 수행하도록 하는 명령어를 포함하고,
    상기 처리하는 단계는,
    편집기 인터페이스에, 상기 룰 사양의 복수의 부분들을 디스플레이하는 단계;
    결과 정보를 획득하도록 상기 수신된 데이터의 하나 이상의 레코드에 상기 룰을 적용하는 단계로서, 출력 값을 생성하도록 상기 수신된 데이터의 입력 값에 상기 룰을 적용하는 단계를 포함하는, 룰을 적용하는 단계; 및
    상기 편집기 인터페이스에, 상기 룰 사양의 특정의 디스플레이된 부분과 연관된 상기 결과 정보의 부분 또는 전부를 디스플레이하는 단계로서, 생성된 출력 값을 다른 출력 값과 비교한 결과를 디스플레이하는 단계를 포함하는, 결과 정보의 부분 또는 전부를 디스플레이하는 단계를 포함하고,
    상기 다른 출력 값은 상기 룰 사양의 이전 버전에 대해 생성된 출력 값을 포함하는,
    데이터에 적용된 하나 이상의 룰을 관리하기 위한 소프트웨어가 내부에 저장된 컴퓨터 판독가능 매체.
15. 제14항에 있어서,
    상기 룰 사양의 부분은 하나 이상의 룰 케이스를 포함하고, 하나 이상의 룰 케이스는 하나 이상의 잠재적인 입력의 각각에 대한 상태를 정의하고, 하나 이상의 룰 케이스는 정의된 상태를 평가한 결과와 연관된 출력을 정의하는, 데이터에 적용된 하나 이상의 룰을 관리하기 위한 소프트웨어가 내부에 저장된 컴퓨터 판독가능 매체.
16. 제14항에 있어서,
    상기 룰 사양의 부분은 하나 이상의 룰 케이스를 포함하고, 하나 이상의 룰 케이스는 하나 이상의 잠재적인 입력의 각각에 대한 상태를 정의하고,
    상기 처리하는 단계는, 상기 편집기 인터페이스에, 상기 룰 케이스의 정의된 상태가 상기 수신된 데이터의 입력 값을 상기 잠재적인 입력으로서 만족했다는 트리거링된 룰 케이스의 표시를 디스플레이하는 단계를 더 포함하는, 데이터에 적용된 하나 이상의 룰을 관리하기 위한 소프트웨어가 내부에 저장된 컴퓨터 판독가능 매체.
17. 제16항에 있어서,
    상기 결과 정보의 부분 또는 전부를 디스플레이하는 단계는, 트리거링된 룰 케이스가 트리거링되는 방법에 대한 정보를 디스플레이하는 단계를 포함하는, 데이터에 적용된 하나 이상의 룰을 관리하기 위한 소프트웨어가 내부에 저장된 컴퓨터 판독가능 매체.
18. 제17항에 있어서,
    상기 트리거링된 룰 케이스가 트리거링되는 방법에 대한 정보는 룰 케이스의 정의된 상태를 평가하도록 사용된 수신된 데이터의 입력 값을 포함하는, 데이터에 적용된 하나 이상의 룰을 관리하기 위한 소프트웨어가 내부에 저장된 컴퓨터 판독가능 매체.
19. 데이터 저장 시스템의 데이터에 적용된 하나 이상의 룰을 관리하기 위한 컴퓨팅 시스템으로서,
    상기 데이터 저장 시스템으로부터 데이터를 수신하도록 구성된 입력 디바이스 또는 포트; 및
    룰 사양의 부분 또는 전부에 의해 특정된 룰에 따라, 수신된 데이터의 부분 또는 전부를 처리하도록 구성된 하나 이상의 프로세서
    를 포함하고,
    상기 처리는,
    편집기 인터페이스에, 상기 룰 사양의 복수의 부분들을 디스플레이하는 것,
    결과 정보를 획득하도록 상기 수신된 데이터의 하나 이상의 레코드에 상기 룰을 적용하는 것으로서, 출력 값을 생성하도록 상기 수신된 데이터의 입력 값에 상기 룰을 적용하는 것을 포함하는, 룰을 적용하는 것, 및
    상기 편집기 인터페이스에, 상기 룰 사양의 특정의 디스플레이된 부분과 연관된 결과 정보의 부분 또는 전부를 디스플레이하는 것으로서, 생성된 출력 값을 다른 출력 값과 비교한 결과를 디스플레이하는 것을 포함하는, 결과 정보의 부분 또는 전부를 디스플레이하는 것을 포함하고,
    상기 다른 출력 값은 상기 룰 사양의 이전 버전에 대해 생성된 출력 값을 포함하는,
    컴퓨팅 시스템.
20. 제19항에 있어서,
    상기 룰 사양의 부분은 하나 이상의 룰 케이스를 포함하고, 하나 이상의 룰 케이스는 하나 이상의 잠재적인 입력의 각각에 대한 상태를 정의하고, 하나 이상의 룰 케이스는 정의된 상태를 평가한 결과와 연관된 출력을 정의하는, 컴퓨팅 시스템.
21. 제19항에 있어서,
    상기 룰 사양의 부분은 하나 이상의 룰 케이스를 포함하고, 하나 이상의 룰 케이스는 하나 이상의 잠재적인 입력의 각각에 대한 상태를 정의하고,
    상기 처리는, 상기 편집기 인터페이스에, 상기 룰 케이스의 정의된 상태가 상기 수신된 데이터의 입력 값을 상기 잠재적인 입력으로서 만족했다는 트리거링된 룰 케이스의 표시를 디스플레이하는 것을 더 포함하는, 컴퓨팅 시스템.
22. 제21항에 있어서,
    상기 결과 정보의 부분 또는 전부를 디스플레이하는 것은, 트리거링된 룰 케이스가 트리거링되는 방법에 대한 정보를 디스플레이하는 것을 포함하는, 컴퓨팅 시스템.
23. 제22항에 있어서,
    상기 트리거링된 룰 케이스가 트리거링되는 방법에 대한 정보는 룰 케이스의 정의된 상태를 평가하도록 사용된 수신된 데이터의 입력 값을 포함하는, 컴퓨팅 시스템.
24. 데이터 저장 시스템의 데이터에 적용된 하나 이상의 룰을 관리하는 컴퓨팅 시스템으로서,
    데이터 저장 시스템으로부터 데이터를 수신하기 위한 수단; 및
    룰 사양의 부분 또는 전부에 의해 특정된 룰에 따라, 수신된 데이터의 부분 또는 전부를 처리하기 위한 수단
    을 포함하고,
    상기 처리는,
    편집기 인터페이스에, 상기 룰 사양의 복수의 부분들을 디스플레이하는 것,
    결과 정보를 획득하도록 상기 수신된 데이터의 하나 이상의 레코드에 상기 룰을 적용하는 것으로서, 출력 값을 생성하도록 상기 수신된 데이터의 입력 값에 상기 룰을 적용하는 것을 포함하는, 룰을 적용하는 것, 및
    상기 편집기 인터페이스에, 상기 룰 사양의 특정의 디스플레이된 부분과 연관된 상기 결과 정보의 부분 또는 전부를 디스플레이하는 것으로서, 생성된 출력 값을 다른 출력 값과 비교한 결과를 디스플레이하는 것을 포함하고,
    상기 다른 출력 값은 상기 룰 사양의 이전 버전에 대해 생성된 출력 값을 포함하는,
    컴퓨팅 시스템.
25. 제24항에 있어서,
    상기 룰 사양의 부분은 하나 이상의 룰 케이스를 포함하고, 하나 이상의 룰 케이스는 하나 이상의 잠재적인 입력의 각각에 대한 상태를 정의하고, 하나 이상의 룰 케이스는 정의된 상태를 평가한 결과와 연관된 출력을 정의하는, 컴퓨팅 시스템.
26. 제24항에 있어서,
    상기 룰 사양의 부분은 하나 이상의 룰 케이스를 포함하고, 하나 이상의 룰 케이스는 하나 이상의 잠재적인 입력의 각각에 대한 상태를 정의하고,
    상기 처리는, 상기 편집기 인터페이스에, 상기 룰 케이스의 정의된 상태가 상기 수신된 데이터의 입력 값을 상기 잠재적인 입력으로서 만족했다는 트리거링된 룰 케이스의 표시를 디스플레이하는 것을 더 포함하는, 컴퓨팅 시스템.
27. 제26항에 있어서,
    상기 결과 정보의 부분 또는 전부를 디스플레이하는 것은, 트리거링된 룰 케이스가 트리거링되는 방법에 대한 정보를 디스플레이하는 것을 포함하는, 컴퓨팅 시스템.
28. 제27항에 있어서,
    상기 트리거링된 룰 케이스가 트리거링되는 방법에 대한 정보는 룰 케이스의 정의된 상태를 평가하도록 사용된 수신된 데이터의 입력 값을 포함하는, 컴퓨팅 시스템.
29. 제15항에 있어서,
    상기 결과 정보의 부분 또는 전부를 디스플레이하는 단계는, 상기 수신된 데이터의 입력 값의 상이한 세트에 대해 트리거링되었다는 트리거링된 룰 케이스의 여러 번의 카운트를 디스플레이하는 단계를 포함하는, 데이터에 적용된 하나 이상의 룰을 관리하기 위한 소프트웨어가 내부에 저장된 컴퓨터 판독가능 매체.
30. 제15항에 있어서,
    상기 결과 정보의 부분 또는 전부를 디스플레이하는 단계는, 트리거링된 룰 케이스가 트리거링되는 방법에 대한 정보를 디스플레이하는 단계를 포함하는, 데이터에 적용된 하나 이상의 룰을 관리하기 위한 소프트웨어가 내부에 저장된 컴퓨터 판독가능 매체.
31. 제30항에 있어서,
    디스플레이된 결과 정보의 부분 또는 전부와의 사용자 상호작용에 응답하여 트리거링된 룰 케이스가 트리거링되는 방법에 대한 정보를 디스플레이하는 단계를 더 포함하는, 데이터에 적용된 하나 이상의 룰을 관리하기 위한 소프트웨어가 내부에 저장된 컴퓨터 판독가능 매체.
32. 제30항에 있어서,
    상기 트리거링된 룰 케이스가 트리거링되는 방법에 대한 정보는 룰 케이스의 정의된 상태를 평가하도록 사용된 수신된 데이터의 입력 값을 포함하는, 데이터에 적용된 하나 이상의 룰을 관리하기 위한 소프트웨어가 내부에 저장된 컴퓨터 판독가능 매체.
33. 제20항에 있어서,
    상기 결과 정보의 부분 또는 전부를 디스플레이하는 것은, 상기 수신된 데이터의 입력 값의 상이한 세트에 대해 트리거링되었다는 트리거링된 룰 케이스의 여러 번의 카운트를 디스플레이하는 것을 포함하는, 컴퓨팅 시스템.
34. 제20항에 있어서,
    상기 결과 정보의 부분 또는 전부를 디스플레이하는 것은, 트리거링된 룰 케이스가 트리거링되는 방법에 대한 정보를 디스플레이하는 것을 포함하는, 컴퓨팅 시스템.
35. 제34항에 있어서,
    디스플레이된 결과 정보의 부분 또는 전부와의 사용자 상호작용에 응답하여 트리거링된 룰 케이스가 트리거링되는 방법에 대한 정보를 디스플레이하는 것을 더 포함하는, 컴퓨팅 시스템.
36. 제34항에 있어서,
    상기 트리거링된 룰 케이스가 트리거링되는 방법에 대한 정보는 룰 케이스의 정의된 상태를 평가하도록 사용된 수신된 데이터의 입력 값을 포함하는, 컴퓨팅 시스템.
37. 제1항에 있어서,
    상기 결과 정보의 부분 또는 전부를 디스플레이하는 단계는, 상기 수신된 데이터의 입력 값의 상이한 세트에 대해 트리거링되었다는 트리거링된 룰 케이스의 여러 번의 카운트를 디스플레이하는 단계를 포함하는, 데이터에 적용된 하나 이상의 룰 관리 방법.
38. 제1항에 있어서,
    상기 결과 정보의 부분 또는 전부를 디스플레이하는 단계는, 트리거링된 룰 케이스가 트리거링되는 방법에 대한 정보를 디스플레이하는 단계를 포함하는, 데이터에 적용된 하나 이상의 룰 관리 방법.
39. 제38항에 있어서,
    디스플레이된 결과 정보의 부분 또는 전부와의 사용자 상호작용에 응답하여 트리거링된 룰 케이스가 트리거링되는 방법에 대한 정보를 디스플레이하는 단계를 더 포함하는, 데이터에 적용된 하나 이상의 룰 관리 방법.
40. 제38항에 있어서,
    상기 트리거링된 룰 케이스가 트리거링되는 방법에 대한 정보는 룰 케이스의 정의된 상태를 평가하도록 사용된 수신된 데이터의 입력 값을 포함하는, 데이터에 적용된 하나 이상의 룰 관리 방법.

Images