Artifact:
|
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: |
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.
Important characteristics of events are:
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.
The software architect is responsible for all events, ensuring that events are being used appropriately.
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).
Rational Unified Process |