이벤트 파티셔닝

이벤트 파티셔닝은 적용하기 쉬운 시스템 분석 기법입니다.분석가는 대규모 시스템의 요건을 보다 작고 단순하며 최소한의 연결로 이해하기 쉬운 "미니 시스템"/사용 사례 모음으로 정리할 수 있습니다.

개요

사건 분할 접근법은 Stephen M. McMenamin과 John F에 의해 설명된다.Essential Systems ^[1]Analysis의 Palmer입니다.접근법의 간단한 버전은 Data Flow Diagram(DFD; 데이터 흐름도)에 관한 기사에 설명되어 있습니다.보다 자세한 내용은 에드워드 유든의 Just Enough Structured Analysis에서 ^[2]확인할 수 있습니다.이 설명에서는 이 기술을 사용하여 데이터 흐름도를 작성하는 데 중점을 두고 있지만, 사용 사례를 식별하는 데도 사용할 수 있습니다.

이벤트 파티셔닝의 전제는 시스템이 외부 이벤트에 대응하기 위해 존재하는 것입니다.즉, 계획된 대응을 필요로 하는 비즈니스 환경에서 무슨 일이 일어나는지 파악한 후 비즈니스 규칙에 따라 대응하도록 시스템을 정의 및 구축합니다.특히, 고객의 요구에 응하기 위한 비즈니스 시스템이 존재합니다.고객은 Unified Modeling Language(UML)의 전문용어로 '액터'입니다.

이벤트 파티셔닝 항목

배우 → 이벤트 → 탐지 → 응답

이 방법에는 다음 단계가 있습니다.

• 1. 외부 이벤트의 원인인 '액터'(외부 시스템) 목록을 브레인스토밍하여 외부 시스템을 식별합니다.도움이 되는 그래픽이 있으면 조사 대상 시스템 외부의 액터 및 액터 간의 흐름/신호를 나타내는 컨텍스트 다이어그램을 작성합니다.
• 2. '배우'의 입장이 되어 (또는 배우 대표와 함께 작업) 시스템이 계획적으로 대응하기를 원하는 '외부 이벤트' / '트리거' 목록을 브레인스토밍합니다.(이 시스템은 외부 이벤트를 발생시킬 수 없으며 배우만이 수행할 수 있습니다.)
• 3. 시스템이 외부 이벤트를 감지할 수 있는 요소를 식별합니다.
  • 하나 이상의 데이터(메시지 형식으로 표시됨)의 도착
  • 하나 이상의 시점 도착(M&P에 의해 "일시적" 사건이라고 불리며 외부 사건과 구별됨)
• 4. 이벤트가 발생했을 때 시스템이 실행할 수 있는 계획적인 대응을 특정합니다.시스템이 목표를 달성할 수 있도록 하는 것은 응답/사용 사례입니다.

이 기술은 Paul T에 의해 "비사건" 이벤트로 확장되었습니다.실시간 시스템을 위한 구조화 개발의 Ward와 Stephen J. Mellor: 필수 모델링 ^[3]기법

"터미네이터[액터]는 정의상 모델로 대표되는 시스템 구축 작업의 범위를 벗어나기 때문에, 구현자는 터미네이터[액터] 기술을 임의로 수정하여 신뢰성을 향상시킬 수 없습니다.대신, 그들은 터미네이터[액터] 문제에 대한 대응을 시스템의 필수 모델에 구축해야 한다.터미네이터(actor) 문제에 대한 반응을 모델링하는 유용한 접근법은 '정상' 이벤트 목록을 작성한 다음 각 이벤트에 대해 '이 이벤트가 예상대로 발생하지 않을 경우 시스템이 응답해야 합니까?'," [강조 추가]

데이터 사전 표기법

데이터 사전 표기법의 Yourdon/DeMarco 스타일은 데이터의 구성과 구조를 설명하는 데 사용될 수 있습니다.

기호.	의미.
=	"complete", "is" 또는 "is"는 다음과 같이 구성됩니다.
+	"and", "well" 또는 "together" (산술 "plus"가 아님)
[x ; y ; z]	"x, y 또는 z 중 하나만 선택합니다."리스트내의 항목을 구분하려면 , 세미콜론(;) 또는 세로 막대( )를 사용할 수 있습니다.
m{x}또는 m:n{x} 또는 ${\displaystyle {}_{m}^{n}\{x\}}$	"x의 m ~ n회 반복"m 또는 n이 지정되지 않은 경우 하한 또는 상한은 단순히 "알 수 없음" 또는 "지정되지 않음"입니다.다차원 배열은 예를 들어 10 { 10 { x } 10 } 10은 10개의 열을 가진 10개의 행으로 이루어진 2차원 행렬을 정의하여 지정할 수 있습니다.
(x)	"옵션 x"이는 0{x}1 또는 0:1{x} ${\displaystyle {}_{\mathrm{}}^{}}$ ${\displaystyle {\mathrm{}}_{}^{}}$ $}{displaystyle${}$_{0}^{1}\{x$에 해당합니다.
@	ID 프리픽스를 지정합니다.예를 들어 {@i+@j+x}에서 i와 j는 식별자입니다.
* ... *	하나의 별자리 사이에 있는 모든 것은 코멘트로 간주됩니다.데이터 요소 수준에서 코멘트에는 "range :", "limits :", "precision :", "unit :" 또는 "values :"와 같은 유형 태그를 포함할 수 있습니다.

데이터 구조 요소는 구조화된 프로그래밍의 제어 구조에 매핑할 수 있습니다.

• "+"는 문장의 "시퀀스"에 매핑할 수 있습니다(반드시 그렇지는 않습니다만).
• [ ]는 "conditions" (조건, switch 문)에 매핑할 수 있습니다.
• "{}", "("")는 "스위치"에 매핑할 수 있습니다(스위치 루프, 사전 테스트 루프, 중간 테스트 루프, 사후 테스트 루프 및 무한 루프).

NB. 정의된 항목은 "재료"(예: 객실 키) 및 "데이터"(예: 도착 날짜-시간)일 수 있습니다.

요건과 그 이유의 특정

이벤트 응답 정보는 테이블로 캡처할 수 있습니다.이 이벤트는, 환경에의 대응으로부터 「추적성」을 얻을 수 있는 응답의 근거입니다.

1. 배우	2. 외부 이벤트/트리거	3. 검출자	4. 대응 / 사용 사례
손님	투숙객은 특정 유형의 객실, 특정 도착 날짜, 출발 날짜, 일정 비율로 요청한다.	예약 요청 + (결제 확인) + (*예약시스템* 예약확인)	북룸(보증된 예약, 대체 호텔 예약, 대기 예약 포함)
손님	객실 예약 취소를 요청하셨습니다.	취소 요구	예약 취소
손님	손님이 호텔에 도착합니다.	도착 메시지 = * * = [게스트명, 예약안내]	게스트 체크인
시간/스케줄러	손님이 호텔에 도착하지 못했습니다.[이건 '비이벤트' 이벤트]	오후 11시(현지시간) ['비이벤트' 이벤트는 마감 시점 도착에 의해 검출됩니다]	게스트 청구서 작성, 예약 갱신
손님	투숙객이 호텔에서 체크아웃을 요청합니다.	체크아웃 요청 = * * = [손님 이름; 방 번호]	게스트 청구서 작성, 회의실 점유율 업데이트
시간/스케줄러	투숙객이 호텔에서 체크아웃하지 못했습니다.[이건 '비이벤트' 이벤트]	오전 11시(현지시간) ['비이벤트' 이벤트는 마감 시점 도착에 의해 검출됩니다]	게스트 청구서 작성
손님	손님은 요금 지불을 제안합니다.	결제차량 = * * = [현금; 수표; 신용카드; 직불카드] + (게스트 ID)	게스트 결제 승인
시간/스케줄러	전날 밤 객실 사용 현황 보고서 작성 시간	오전 8시(현지시간)	객실 점유율 보고서
호텔 매니저	호텔 매니저가 객실 사용 보고서를 요청합니다.	입주 신고 요구	객실 점유율 보고서
Smoke / CO 알람	경보가 연기를 감지합니다.	스모크 경보 메시지	연기 경보 보고
Smoke / CO 알람	경보가 CO(일산화탄소)를 감지합니다.	CO 알람 메시지	CO 알람 보고

요건의 정의

이 접근방식을 통해 분석가는 계획된 대응이 필요한 이벤트를 사용하여 시스템을 "정신적으로 한 입 크기의" 미니 시스템으로 분해할 수 있습니다.각 응답의 세부 수준은 "주요 사용 사례" 수준입니다.각 계획된 대응은 DFD 표기법을 사용하여 모델링하거나 사용 사례도 표기법을 사용하여 단일 활용 사례로 모델링할 수 있습니다.

프로세스 또는 유스케이스 내의 기본적인 흐름은 보통 20~30개 미만의 비교적 적은 수의 스텝으로 기술할 수 있으며, "구조화된 영어"와 같은 것을 사용할 수 있습니다.모든 스텝이 한 번에 표시되는 것이 이상적입니다(대개 1페이지 이내).그 목적은 단기 기억과 관련된 위험 중 하나를 줄이는 것이다. 즉, 즉시 보이지 않는 것을 잊어버리는 것이다("눈에서 멀어지면 마음에서 멀어진다")

또는 구조화된 기법의 표기를 사용하여 분석가는 "나시-"를 생성할 수 있다.Shneiderman 다이어그램"을 참조하십시오.UML에서는 활동도, 시퀀스도 또는 통신도를 사용하여 사용 사례를 모델링할 수 있습니다.이는 많은 사용 사례 시나리오가 복잡한 경우 문제가 될 수 있습니다. 분석가는 전체 또는 대부분의 시나리오를 모델링할 수 있습니다.

복잡성 대 단편화

응답이 장황하거나 복잡할 경우(즉, 텍스트 페이지 이상), 분석가는 "부모"의 주요 사용 사례를 보다 작고 단순하게 유지하기 위해 더 작은 "보조 사용 사례"로 분해(인수 배제 또는 중복 제외)할 수 있습니다.이러한 세컨더리 사용 사례는 재사용 가능한 것으로 판명될 수도 있습니다(UML 사용 사례 다이어그램에서는 확장 또는 포함 사용 사례로 나타나며, 이는 하나 이상의 주요 사용 사례와 관련이 있습니다).

분석가는 사용 사례를 설명하는 동안 "비즈니스 규칙"을 발견할 수도 있습니다.일부 분석가는 개체 제약 조건 언어 또는 다른 형식 표기법을 사용하여 별도의 문서에서 비즈니스 규칙을 캡처할 것을 제안합니다.그런 다음, 활용 사례에서 비즈니스 규칙을 준수해야 하는 경우 분석가가 이를 참조합니다.이렇게 하면 규격 내에서 반복이 최소화되지만 규격의 단편화가 발생할 위험이 있습니다.이 장력을 줄일 수 있는 방법 중 하나는 사양 문서의 하이퍼링크를 사용하는 것입니다.

이 환원주의적 접근법은 피터 체크랜드의 소프트 시스템 방법론으로 대표되는 시스템 사고 접근법과 다소 대조적입니다.

활용 사례 설명에서 파악한 기능 요건 외에, 분석가는 응답 시간, 학습 가능성 등과 같은 비기능 요건을 포함할 수 있습니다.

「 」를 참조해 주세요.

• 비즈니스 케이스
• SIPOC
• 사용 사례
• 사용 사례도
• 사용자 사례

레퍼런스

외부 링크

• 이벤트 파티셔닝 Structured Analysis Wiki