비즈니스 규칙은 비즈니스 도구를 포함하여 비즈니스 운영에 필요한 요구사항의 유형입니다. 비즈니스 규칙의 예로는 비즈니스에 적용되는 법률 및 규정을 들 수 있으며 선택한 비즈니스 아키텍처 및 스타일을 나타내기도
합니다. 비즈니스 규칙은 다음과 같은 두 가지 방법으로 캡처합니다.
-
모델 기반 - 비즈니스 규칙을 UML 모델에 스테레오타입화된 제한조건으로서 캡처합니다. 규칙은 자연어 또는 OCL(Object Constraint Language)과 같은 보다 형식적인 표기법을
사용하여 선언할 수 있습니다. 이 기법의 이점은 비즈니스 규칙이 해당 소스에서 캡처되고 표시된다는 것입니다. 반면에 가장 큰 단점은 비즈니스 규칙이 모델에 분산되어 관련 비즈니스 규칙을 쉽게 확인할 수
없다는 것입니다. 보고서:
비즈니스 규칙 조사는 모델의 모든 비즈니스 규칙에 대한 개요를 제공합니다.
-
문서 기반 - 비즈니스 규칙을 별도 문서에서 캡처합니다. 비즈니스 규칙은 문서에 포함되지만 이 규칙은 모델 기반 접근 방식에서 사용되는 비즈니스 규칙이 아닙니다. 문서 기반 접근 방식은 재무
상품과 같이 많은 비즈니스 규칙이 적용될 때 유용합니다. 이 방법의 단점은 비즈니스 규칙이 해당 소스와 다른 아티팩트에서 캡처된다는 것입니다.
비즈니스 규칙은 문서 및 모델 양식으로 모두 캡처할 수 있습니다. 비즈니스 규칙의 개요를 모델로 파악하려면 보고서: 비즈니스
규칙 조사를 생성하면 됩니다.
비즈니스 규칙 문서는 특히 법률과 같이 설명이 긴 비즈니스 규칙에 유용합니다. 문서 기반 비즈니스 규칙의 단점은 비즈니스 규칙을 해당 모델의 모든 파트(여러 파트인 경우)로 추적해야 한다는 것입니다. 이러한 단점은
해당 모델에서 직접 캡처할 수 있는 모델 기반 비즈니스 규칙을 선택함으로써 해결할 수 있습니다. 그러나 이 역시 "모델에 표시되지 않는" 단점이 있으며 이로 인해 특정 공통 특성(예: 특정 카테고리에 속함)이 있는
모든 비즈니스 규칙의 개요를 파악하기 어렵습니다.
비즈니스 규칙은 엄격하고 공식적으로 표현되어야 자동화의 기초를 형성할 수 있습니다. 한 가지 대안으로 UML(Unified Modeling Language)에 지정된 대로 OCL(Object Constraint
Language)을 사용할 수 있습니다[RUM98]. 비즈니스 규칙은
항상 해당 독자를 고려해야 합니다. 규칙을 읽는 독자에 초점을 맞춤으로써 비즈니스 규칙을 캡처하는 방식(문서 또는 모델), 선택한 스타일 및 형식화 레벨을 대상 독자에 맞게 일치시킬 수 있습니다. 대상 독자가
이해할 수 없는 비즈니스 규칙은 프로젝트 시간을 낭비할 뿐입니다.
예제:
팀 크기를 10명 미만의 구성원으로 제한하여 표시하려고 합니다. OCL을 사용하는 경우 이 비즈니스 규칙을 불변으로 지정할 수 있습니다.
context Team inv:
self.numberOfMembers <= 10
그러나 이러한 정규 유형의 언어는 많은 이해 당사자(stakeholder)가 쉽게 이해할 수 없으므로 좀 더 자연어에 가까운 스타일을 사용하는 것이 좋습니다. 규칙을 정의하기 위해 사용하는 예약 표현식 세트를
정의할 수 있습니다. 이 표현식은 다음과 같이 [ODL98]에 정의된 표현식과 같을 수
있습니다.
-
IF
-
ONLY IF
-
WHEN
-
THEN
-
ELSE
-
IT MUST ALWAYS HOLD THAT
-
IS CORRECTLY COMPLETED
예제:
이러한 형식성이 약한 언어를 사용하면 위 예제를 다음과 같이 표시할 수 있습니다.
(IT MUST ALWAYS HOLD THAT) 팀 구성원의 수는 항상 10명 이하여야 합니다.
규칙을 일반적으로는 제한조건 규칙과 도출 규칙으로 나누지만, 여러 가지 방법으로 분류할 수 있습니다. [ODL98] 두 카테고리 모두 다음과
같은 방식으로 세부적으로 다시 분류될 수 있습니다.
-
제한조건 규칙은 오브젝트 구조 및 동작을 제한하는 정책 또는 조건을 지정합니다. 제한조건 규칙은 항상 적용되거나 특정 조건에서만 적용될 수 있습니다. 항상
적용되는 제한조건을 불변사항이라고 합니다.
-
자극(stimulus) 및 응답 규칙은 동작을 트리거할 수 있는 조건이 성립되는지 여부와 해당 시점을 지정하여 동작을 제한합니다.
-
오퍼레이션 제한조건 규칙은 오퍼레이션의 올바른 수행을 위해 오퍼레이션 전후에 충족되어야 하는 조건을 지정합니다.
-
구조 제한조건 규칙은 반드시 준수해야 하는 클래스, 오브젝트 및 해당 관계에 대한 정책 또는 조건을 지정합니다.
-
도출 규칙은 다른 사실에서 사실을 추론 또는 계산하기 위한 정책이나 조건을 지정합니다.
-
추론 규칙은 특정 사실이 참인 경우 결론을 이끌어낼 수 있는 것으로 지정합니다.
-
계산 규칙은 알고리즘을 처리하여 해당 결과를 도출합니다. 추론 규칙의 보다 정교한 변형입니다.
이러한 비즈니스 규칙의 분류는 비즈니스 규칙의 정의, 규칙을 찾는 방법 및 규칙 사용 방법에 대해 설명할 때 유용합니다. 그러나 이러한 분류가 모든 경우에 강제적으로 적용되는 것은 아닙니다. 따라서 비즈니스 규칙
아티팩트의 템플리트에서는 이 분류를 나타내지 않습니다. 실제 프로젝트에서는 보다 실질적인 다른 분류(도메인, 사용자 또는 제품 그룹별)를 사용할 수 있습니다. 비즈니스 규칙의 분류 및 적용에 대한 자세한 정보는
[ROS97]을 참조하십시오.
비즈니스 규칙은 모델의 모양에 영향을 줍니다. 또한 활동 다이어그램에서의 타스크 순서는 물론 비즈니스 엔티티 간의 연관에도 영향을 줍니다. 일부 규칙은 다이어그램 모양으로 쉽게 변환되지 못하므로 모델 요소의 설명에
포함시켜야 합니다.
UML 다이어그램의 비즈니스 규칙은 영향을 받는 모델 요소와 링크되어야 합니다.
또한 추적성 및 보고를 위해서는 요구사항 속성의 비즈니스 규칙을 추적하는 것이 효과적입니다.
자극(stimulus) 및 응답 규칙
이 비즈니스 규칙 유형은 비즈니스 유스 케이스의 워크플로우에 영향을 주며 해당 비즈니스 유스 케이스로 추적할 수 있습니다. 워크플로우를 통해 조건 경로 또는 대체 경로를 표시할 수 있습니다. 관련 조치가 그다지
중요하지 않은 경우, 비즈니스 규칙 평가를 활동 상태에 포함시키는 것으로 충분할 수 있습니다.
비즈니스 분석 모델에서 이러한 유형의 규칙은 예를 들어 라이프사이클을 비즈니스 엔티티로 설명하는 방식에 영향을 주거나 비즈니스 작업자에 대한 오퍼레이션 설명의 일부로 포함될 수 있습니다. 식별된 비즈니스
이벤트를 점검함으로써 이러한 유형의 비즈니스 규칙을 효과적으로 정의할 수 있습니다. 이벤트 발생 자체가 관심의 대상이므로 비즈니스 이벤트는 일반적으로 식별됩니다. "이벤트 발생 시 적용되는 조건 또는 동작"에 대해
생각해 봅니다.
예제:
주문 관리 조직에서 다음과 같은 규칙을 사용합니다.
(WHEN) 주문을 취소하고
(IF) 주문 내역을 운송하지 않으면
(THEN) 주문이 종료됩니다.
이 비즈니스 규칙은 워크플로우에 두 대체 경로를 표시하고 특히 출력 전이에 대한 결정 및 보호 조건을 사용하여 반영됩니다.
이 경우 비즈니스 규칙은 워크플로우를 통해 대체 경로로 변환됩니다.
오퍼레이션 제한조건 규칙
이 비즈니스 규칙 유형은 일반적으로 워크플로우의 전제 조건 및 사후 조건으로 변환되거나 워크플로우 내 조건 또는 대체 경로로 변환됩니다. 이는 또한 해당 비즈니스 유스 케이스로 추적해야 하는 일부 다른
비동작 규칙 또는 성과 목적이 될 수 있습니다.
예제:
주문 관리 조직에서 다음과 같은 규칙을 사용합니다.
(ONLY IF) 고객의 운송 주소가 있는 경우에만
주문 상품을 고객에게 운송합니다.
비즈니스 규칙은 워크플로우의 대체 경로로 변환됩니다.
예제:
다음은 또 다른 오퍼레이션 제한조건 규칙입니다.
IT MUST ALWAYS HOLD THAT
모든 고객 조회는 요청을 받은 후 24시간 이내에 응답해야 합니다.
이 비즈니스 규칙은 비즈니스 유스 케이스의 성과 목적으로 변환됩니다. 가이드라인:
비즈니스 유스 케이스에서 성과 목적에 대한 섹션을 참조하십시오.
구조 제한조건 규칙
이 비즈니스 규칙 유형은 비즈니스 엔티티 인스턴스 간의 관계에 영향을 줍니다. 이러한 관계는 두 비즈니스 엔티티 간 연관의 존재로 표현할 수 있으며 연관에 대한 다중성으로 표현될 수 있습니다.
예제:
주문 관리 조직에서 다음과 같은 규칙을 사용합니다.
IT MUST ALWAYS HOLD THAT
하나의 주문은 하나 이상의 제품을 참조해야 합니다.
이 비즈니스 규칙은 다중성이 1..*인 연관으로 변환됩니다.
추론 규칙
추론 규칙은 일반적으로 자극(stimulus) 및 응답 규칙과 유사하며 오퍼레이션 제한조건 또는 구조 제한조건 규칙 유형과도 유사합니다. 차이점은 결론에 도달하기 위해 몇 가지 단계를 고려해야 한다는 것입니다. 이
규칙에는 워크플로우의 활동 상태와 비즈니스 작업자 또는 비즈니스 엔티티에 대한 오퍼레이션에 반영해야 하는 방법이 포함됩니다.
예제:
고객 상태를 판별하기 위해 다음 규칙을 설정할 수 있습니다.
우수 고객은(IF AND ONLY IF)
이 고객에게 송신된 미지불 송장 기한이 30일 미만인 고객입니다.
이 비즈니스 규칙은 워크플로우의 대체 경로에 해당하며, 규정된 방법은 고객 평가 타스크의 일부로 포함됩니다.
계산 규칙
계산 규칙은 추론 규칙과 유사합니다. 차이점은 방법이 보다 정규적이고 알고리즘과 유사하다는 것입니다. 이 방법은 추론 규칙과 같이 워크플로우의 타스크와 결과적으로 비즈니스 작업자 또는 비즈니스 엔티티에 대한
오퍼레이션으로 추적해야 합니다.
예제:
계산 규칙은 다음과 같이 값 계산을 지정할 수 있습니다.
제품의 정가는 다음과 같이 계산합니다(IS COMPUTED AS FOLLOWS).
제품 가격 * (1 + 세율 / 100)
정가 평가는 주문과 함께 보낼 청구서를 생성할 때 주문 운송 타스크의 일부로 포함될 수 있습니다. 비즈니스 분석 모델에서 이 규칙은 연관 및 오퍼레이션으로 변환됩니다.
규칙은 정가 계산 오퍼레이션의 방법으로 반영되어야 하지만 또한 모델의 클래스 간 관계에 대한 필요성을 나타냅니다.
|