Artifact: Signal
|
A signal is an asynchronous stimulus from one object or instance to another. | |
| Other Relationships: |
Part Of Design Model
| |
|---|---|---|
| Role: | Software Architect | |
| Optionality/Occurrence: | Signals are a suitable model for communication in distributed, concurrent systems, and/or reactive (event-driven) systems. | |
| Templates and Reports: |
|
|
| Examples: | ||
| UML Representation: |
Signal. Also commonly represented as a class stereotyped <<signal>>. |
|
| More Information: | ||
| Input to Activities: | Output from Activities: |
Purpose 
The purpose of a signal is to provide one-way asynchronous communication from one object or instance to another.
Signals are a specialization of Artifact: Event that can have operations, attributes, and relationships.
Properties
The following are properties of Signal that are in addition to those inherited from Artifact: Event.
|
Property Name |
Brief Description |
UML Representation |
|---|---|---|
| Name | The name of the signal. | attribute |
| Brief Description | A brief description of the role and purpose of the signal. | Tagged value, of type "short text". |
| Responsibilities | The responsibilities defined by the class. | tagged value |
| Relationships | The generalizations in which the signal participates. | generalization relationship |
| Operations | The operations defined by the signal. | operation |
| Attributes | The attributes defined by the signal. | attributes |
Timing
Some signals, 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 signals needed to communicate asynchronously within the system are identified in the latter part of the elaboration phase. All signals and events are architecturally significant and should be completely identified by the end of the elaboration phase.
Responsibility
The software architect is responsible for all signals, ensuring that signals are being used appropriately.
Tailoring
Signals are used to define entities for asynchronous messaging. They are suitable
for communication in distributed and concurrent systems. Avoid naming signals
in a 'receiver-specific' manner - this limits their generality and usefulness,
bearing in mind that signals may be broadcasted to a set of objects. The important
thing is to communicate the interesting occurrence the sender has detected (which
prompted it to send the signal). A signal may also have a list of parameters
which are represented as its attributes. Operations may be provided on a signal
to access these attributes.
Since Signals are a specialization of Artifact: Event, signal tailoring is
dependent on the tailoring for Artifact: Event. For example, the Artifact: Event
information can be captured in textual form (such as a table in the Software
Architecture Document), while the Signal-specific properties are captured in
a visual model.
