설명
비즈니스 이벤트는 일상적인 비즈니스 타스크에서 발생하는 중요한 이벤트를 나타냅니다. 물론 비즈니스에서는 매일 수많은 일이 발생합니다. 비즈니스 이벤트는 실제로 중요한 이벤트에 주의를 기울여 이러한 복잡도를 관리할
수 있다는 점에서 구조적으로 중요합니다. 비즈니스 이벤트에는 다음과 같은 특성이 있습니다.
-
중요한 일(즉, 사소하지 않은)이 발생했음을 나타냅니다.
-
일정 규칙 없이 또는 예상치 못하게 발생합니다.
-
다른 이벤트와 관계 없이 독립적으로 발생합니다.
-
해당 이벤트로 인해 즉각적인 특정 비즈니스 조치가 수행됩니다.
이러한 특성을 갖고 있지 않은 경우 비즈니스 이벤트로 보기 어렵습니다.
비즈니스 이벤트는 비즈니스 유스 케이스를 실현하기 위한 상호작용 과정에서 비즈니스 액터, 비즈니스 작업자 및 비즈니스 엔티티에 의해 트리거되어 수신됩니다. 비즈니스 이벤트를 트리거하는 요소에 대한 설명은 다음과
같습니다.
-
비즈니스 액터가 비즈니스 유스 케이스의 시작 또는 끝을 나타내기 위해 트리거합니다. 예를 들어, 공급자가 상품을 배달할 때 전달 비즈니스 이벤트는 물품 전달 비즈니스 유스 케이스의 시작을 나타냅니다.
-
비즈니스 엔티티에서 상태 변경을 나타내기 위해 트리거합니다. 예를 들어, CandidateQualified 비즈니스 이벤트에서 직원 채용 비즈니스 유스 케이스의 일부로서 잠재 직원에 대한 참조를 확인한
것으로 나타냅니다.
-
비즈니스 작업자가 비즈니스 유스 케이스 실현(realization)의 특정 지점을 나타내기 위해 트리거합니다. 예를 들어, 로켓이 발사되면 발사 비즈니스 이벤트에서 로켓의 궤도 추적을 시작할 수 있음을
나타냅니다.
-
시간 경과에 따라 트리거됩니다. 예를 들어, 환자가 수술실에서 나온지 6시간이 경과하면 PatientCoherent 비즈니스 이벤트에서 간호원이 환자 상태를 확인해야 하는 것으로 나타냅니다.
비즈니스 이벤트 모델링
비즈니스 이벤트에는 이벤트가 표시하는 발생의 의미에 대한 보다 많은 컨텍스트를 제공하는 정보가 포함될 수 있습니다. 이 정보는 그림에 표시된 대로 비즈니스 이벤트 클래스의 속성으로 모델링됩니다. 비즈니스 이벤트의
속성은 이벤트 수신측에서 조치를 취하기 위해 필요로 하는 정보를 고려하여 결정될 수 있습니다.
비즈니스 엔티티의 상태 변화를 나타내는 비즈니스 이벤트는 그림과 같이 관련 해당 비즈니스 엔티티와 연관되어야 합니다. 이를 통해 비즈니스 이벤트 수신측에서 문제가 있는 비즈니스 엔티티에 액세스하여 필요한 정보를
검색할 수 있습니다.
비즈니스 액터, 비즈니스 작업자 및 비즈니스 엔티티는 비즈니스 이벤트를 트리거하고 수신할 수 있습니다. 비즈니스 이벤트를 트리거하는 클래스를 공개자라고 하며 비즈니스 이벤트를 수신하는 클래스를
등록자라고 합니다.
공개자에게는 그림과 같이 트리거할 비즈니스 이벤트에 대해 <<송신>> 스테레오타입화된 종속성이 필요합니다.
등록자에게는 그림과 같이 비즈니스 이벤트의 속성과 일치하는 매개변수 및 비즈니스 이벤트와 이름이 같은 <<비즈니스 이벤트>> 스트레오타입화된 오퍼레이션이 필요합니다. 오퍼레이션 서명은 비즈니스
이벤트 이름 및 속성과 일치해야 합니다.
또 다른 접근 방식은 표준 UML은 아니지만 등록자에서 비즈니스 이벤트로 <<수신>> 스테레오타입화된 종속성을 생성하는 것입니다. 오퍼레이션 서명은 모든 <<수신>>
종속성에서 추론할 수 있습니다. 다음 그림은 이러한 비표준 접근 방식의 한 예입니다.
비즈니스 이벤트의 실제 트리거는 상호작용 또는 활동 다이어그램에 표시됩니다. 상호작용 다이어그램에서는 공개자가 비즈니스 이벤트 이름과 함께 수신측으로 비동기 메시지를 송신합니다. 이에 대한 한 예가 그림에 표시되어
있습니다. 해당 메시지는 비동기 메시지입니다. 이는 계속하기 전에 등록자가 비즈니스 이벤트 처리를 완료할 때까지 공개자가 기다리지 않음을 나타냅니다. 즉, 공개자는 비즈니스 이벤트를 트리거한 후 다음 작업을 계속
수행합니다. 등록자는 비즈니스 이벤트를 수신한 즉시 이벤트 처리를 시작합니다. 이는 동기 메시지보다 실제적입니다.
활동 다이어그램에서는 공개자가 비즈니스 이벤트를 트리거하는 것으로 표시됩니다. 수신측은 같은 다이어그램 또는 다른 다이어그램에서 비즈니스 이벤트를 수신하는 것으로 표시됩니다. 이에 대한 한 예가 그림에 표시되어
있습니다.
비즈니스 이벤트 찾기
비즈니스 액터와 비즈니스 유스 케이스 간 연관의 이름이 지정되면 해당 비즈니스 이벤트를 사용하여 비즈니스 이벤트 시작 시점에 신호를 보내도록 설정할 수 있습니다. 이는 중요한 비즈니스 발생 요소입니다.
시퀀스 다이어그램에서 비즈니스 작업자 간의 상호작용을 분석하십시오. 비즈니스 작업자 간의 각 메시지에 대해 다음을 고려하십시오.
-
위치 - 다른 위치의 두 비즈니스 작업자 간에 전달된 메시지가 후보 비즈니스 이벤트입니다.
-
시간 - 트리거 시점과 수신 시점 사이에 상당한 차이가 있는 메시지가 후보 비즈니스 이벤트입니다.
-
목적 - 비즈니스 이벤트를 트리거한 조치와 관련하여 목적이 다른 조치를 발생시키는 메시지가 후보 비즈니스 이벤트입니다.
-
책임 - 다양한 책임의 비즈니스 작업자가 수행하는 메시지가 후보 비즈니스 이벤트입니다.
비즈니스 시스템의 경계를 분석함으로써 목적 또는 책임의 차이를 식별할 수 있습니다.
활동 다이어그램에서 각 타스크 직전 또는 직후에 특정 조치가 필요한지 여부와 특정 관계자에게 결정 결과를 알려야 하는지 여부를 고려하십시오.
비즈니스 엔티티는 또한 비즈니스 이벤트의 근거를 제공합니다. 비즈니스 엔티티의 모든 중요 오퍼레이션이 후보 비즈니스 이벤트입니다. 이러한 경우 비즈니스 엔티티에 대한 상태 차트 다이어그램이 유용합니다. 상태 전이는
비즈니스 상태 변화를 나타내므로 잠재적인 비즈니스 이벤트를 나타냅니다.
비즈니스 이벤트를 식별하는 경우, 비즈니스 엔티티가 서류인 사무실에서 직원이 해당 서류를 읽고 변경한 후 받은 편지함과 보낼 편지함으로 보내는 경우를 가정할 수 있습니다. 서류 일부를 전체 복사하여 다른 대상에게
라우트해야 하는 경우 받는 사람이 여러 명인 비즈니스 이벤트가 생성될 수 있습니다. 또한 비즈니스 작업자가 타스크를 수행한 후 다른 사람에게 알리기 위해 통지를 작성해야 하는 경우, 해당 타스크 또한 비즈니스
이벤트가 될 수 있습니다. 물론 해당 문서는 계속 책상에 두지 않고 파일로 정리합니다. 파일 캐비넷에서 서류를 제거하거나 파일 캐비넷에 다시 서류를 넣어야 하는 경우 서류를 제거하거나 다시 넣어야 하는 이유를
고려합니다. 서류를 제거하거나 다시 넣게 만드는 발생 요인이 비즈니스 이벤트가 될 수 있습니다.
비즈니스 이벤트 일반화
비즈니스 이벤트는 보다 일반적인 비즈니스 이벤트와 보다 세분화된 비즈니스 이벤트 간에 일반화 관계를 정의함으로써 이벤트 "계열"로 분류 또는 그룹화할 수 있습니다. 따라서 비즈니스 이벤트의 다른 하위 유형과 관련이
없는 관계자가 여러 유형의 비즈니스 이벤트를 동일한 방식으로 처리할 수 있습니다.
위의 다이어그램에서는 직원의 질병(Sickness), 이탈(Missing) 또는 죽음(Death)을 모두 직원 부재의 보다 세분화된 버전으로 나타냅니다. Absence 상위 유형을 정의함으로써 세 가지 하위 유형을
모두 부재로 처리할 수 있습니다. 예를 들어, 컨설팅 회사의 경우 고객 관리자가 고객에게 직원의 부재 사실을 알리고(부재 이유에 관계 없이) 다른 직원을 배치해야 하는 경우가 있습니다. 따라서 고객 관리자는
Absence 비즈니스 이벤트에만 관심을 갖습니다. 반대로 안내원은 직원이 아픈 경우 의사에게 연락하거나 꽃을 보내는 등의 특정 조치를 수행해야 합니다. 인적 자원 관리자와 해당 직원의 관리자는 직원의 죽음을
알려야 하는 대상입니다.
이 예제에서, 다양한 관계자가 여러 가지 특정 상황에 대응하여 다른 조치를 수행해야 하는 경우 비즈니스 이벤트의 세분화가 유용함을 알 수 있습니다. 반면에 특정 관계자가 특정 상황에 관계 없이 특정 비즈니스
이벤트에 대해 동일한 방식으로 대응해야 하는 경우에는 비즈니스 이벤트의 일반화가 유용합니다.
관계자에게는 물론 세분화된 실제 이벤트를 알립니다. 직원이 사망한 경우 고객 관리자에게도 이 사실을 알리고 동일한 조치가 수행됩니다. 비즈니스 이벤트 계층 구조는 보다 간단하고 쉽게 이해할 수 있는 비즈니스 분석
모델을 작성하는 데 유용합니다.
비즈니스 이벤트 자동화
비즈니스 이벤트의 정의, 트리거 및 전파 과정을 자동화하는 것이 바람직하지만 경우에 따라 실용적이지 않을 수도 있습니다. 때로는 동료에게 전자 우편을 보내는 것이 이러한 기능의 시스템을 빌드하는 것보다 비용 면에서
저렴합니다. 따라서 비즈니스 이벤트 자동화를 계획할 때는 다음 사항을 고려해야 합니다.
-
이벤트 관리 측면을 자동화하는 시스템을 구입 또는 구현하여 유지보수하기 위한 비용
-
자동화된 솔루션의 기술적 실현 가능성
-
자동화하지 않은 대안의 비용
-
특정 이벤트를 트리거 또는 수신하지 않는 데 따른 영향
-
향후 특정 이벤트가 비즈니스 경계를 벗어날 가능성
-
현재 사용 가능한 알림 채널
서비스 지향 아키텍처에서는 소프트웨어 시스템을 서로 분리하고 실제 위치에서 분리하기 위해 메시지를 사용합니다. 또한 비동기 메시지를 사용하면 소프트웨어 시스템을 필요한 시점에 분리할 수 있습니다. 비즈니스 이벤트는
이러한 소프트웨어 시스템 유형에서 메시지로 구현됩니다. 그러나 모든 메시지가 비즈니스 이벤트와 연관되는 것은 아닙니다. 유용한 비즈니스 이벤트 응용프로그램의 예는 엔터프라이즈 응용프로그램 통합(EAI)입니다.
여기서 각 응용프로그램은 다른 응용프로그램이 등록할 수 있는 여러 비즈니스 이벤트를 정의하며 이를 통해 응용프로그램이 직접 상호작용 없이 상호작용을 수행할 수 있습니다.
예를 들어, 고객 상호작용, 제안 및 계약을 단일 프론트 오피스 시스템에서 관리하는 보험 회사의 경우를 들 수 있습니다. 이 회사에는 제품 및 보험 증권을 관리하는 백오피스 시스템이 있습니다. 고객이 제안을
요청하면 프론트 오피스 시스템에서 해당 고객 및 보험 대상에 대해 필요한 정보를 수집합니다. 그런 다음 제품 관리 시스템에서 이 정보에 따라 보험료를 계산하고 제안과 관련된 보험 증권 초안을 생성합니다. 고객이
해당 제안을 승인하면 증권 관리 시스템에서 해당 증권을 완료해야 합니다. 이 예제에서는 시간, 위치 및 책임(CalculatePremiums, FinalizePolicy)에서 두 메시지가 연결되지 않습니다. 그러나
현재 컨텍스트에 관계 없이 중요하므로 FinalizePolicy만 비즈니스 이벤트로 모델링됩니다.
|