Artifact: Event
|
| The specification of an occurrence in space and time; less formally, an occurrence of something to which the system must respond. The purpose of this Artifact: Event is to capture characteristics of events, such as frequency, priority, and response requirements. | |
| Other Relationships: |
Part Of Design Model
| |
|---|---|---|
| Role: | Software Architect | |
| Optionality/Occurrence: | Identifying and characterizing events is mainly applicable to reactive (event-driven) systems, systems that use concurrency, and/or systems that use asynchronous messaging. | |
| Templates and Reports: |
| |
| Examples: |
| |
| UML Representation: |
In the context of state and activity diagrams, Event refers to a trigger for a state transition. However, this artifact covers "event" in the more general sense, as occurrences to which the system must respond, including signals, calls, state changes, or time events. Also see Artifact: Signal. | |
| More Information: | ||
|
| ||
| Input to Activities:
| Output from Activities:
|
Purpose
An event is used to identify and capture information about external occurrences that the system is aware of and to which it must respond. Events can also be used to capture information about internal events, such as exceptions.
Brief Outline
Important characteristics of events are:
- internal vs. external - Is the event external or internal?
- priority - Does this event need to cause the suspension of other processing in order to be handled?
- frequency - How often does the event occur?
- frequency distribution - Does the event occur at regular intervals, or are there spikes?
- response requirements - How the quickly the system must respond to the event (may need to distinguish between average and worst case).
- kind - Is this a Call Event, Time Event, Signal Event, or Change Event (see
Concepts: Events and Signals
for definitions)?
Timing
Some events, specifically those representing the external events and the significant internal events to which the system must respond, are identified early in the elaboration phase. Other events needed to communicate asynchronously within the system are identified in the latter part of the elaboration phase. All architecturally significant events should be completely identified by the end of the elaboration phase.
Responsibility
The software architect is responsible for all events, ensuring that events are being used appropriately.
Tailoring
Event characteristics can be captured in a spreadsheet, database, requirements management database, or as a table in the Software Architecture Document.
They can even be captured as classes, stereotyped <<event>>, although this should be treated as a convenient way of capturing management information about events, and not be confused with data transmitted when the event occurs. If a call event results in the transmission of data, the data should be represented by the signature of the called operation. If the event is a signal, its data can be modeled explicitly (see Artifact: Signal).
