결과물:
|
![]() |
공간 및 시간 상의 발생에 대한 스펙. 덜 공식적으로는 시스템이 응답해야 하는 사항의 발생. 이 결과물: 이벤트의 목적은 이벤트(예: 빈도, 우선순위 및 응답 요구사항)가 특성을 캡처하기 위함입니다. | |
기타 관계: |
다음 파트 설계 모델
| |
---|---|---|
역할: | 소프트웨어 아키텍트 | |
선택 가능성/발생 시기: | 이벤트 식별 및 특성 부여는 주로 반응(이벤트 주도) 시스템, 동시성을 사용하는 시스템 및/또는 비동기 메시징을 사용하는 시스템에 적용됩니다. | |
템플리트 및 보고서: |
|
|
예: | ||
UML 표시: |
상태 및 활동 다이어그램의 컨텍스트에서 이벤트는 상태 전이에 대한 트리거를 나타냅니다. 그러나 이 결과물은 보다 일반적인 의미에서 신호, 호출, 상태 변경 또는 시간 이벤트와 같이 시스템이 응답해야 하는 발생으로서의 "이벤트"를 다룹니다. 결과물: 신호도 참조하십시오. |
|
자세한 정보: | ||
|
활동 정보: | 활동 결과: |
이벤트는 시스템이 인식하고 응답해야 하는 외부 발생에 대한 정보를 식별하고 캡처하는데 사용합니다. 이벤트는 예외와 같은 내부 이벤트에 대한 정보를 캡처하는데 사용할 수도 있습니다.
이벤트의 중요한 특성은 다음과 같습니다.
특히 시스템이 응답해야 하는 중요한 내부 이벤트와 외부 이벤트를 나타내는 일부 이벤트가 구현화 단계의 초기에 식별됩니다. 시스템 내에서 비동기적으로 의사소통하는데 필요한 기타 이벤트는 구현 단계의 후반부에서 식별됩니다. 구조적으로 중요한 모든 이벤트가 구현화 단계의 종료 시까지는 완전히 식별되어야 합니다.
소프트웨어 아키텍트는 모든 이벤트에 대한 책임이 있으며 이벤트가 적절하게 사용 중인지 확인합니다.
이벤트 특성이 스프레드시트, 데이터베이스, 요구사항 관리 테이블 또는 소프트웨어 구조 문서의 테이블로 캡처될 수 있습니다.
해당 특성은 <<event>>로 스테레오타입화된 클래스로도 캡처될 수 있습니다. 그러나 이 방법은 이벤트에 대한 관리 정보를 캡처하는 편리한 방법으로서 취급되어야 하며 이벤트 발생시 전송되는 데이터와 혼동되어서는 안됩니다. 호출 이벤트로 인해 데이터가 전송되는 경우, 데이터는 호출된 조작의 서명으로 표시되어야 합니다. 이벤트가 신호인 경우, 데이터는 명시적으로 모델화되어야 합니다(결과물: 신호 참조).
Rational Unified Process
|