Interaction Diagrams

Interaction Diagrams are a powerful procedural representation of system behaviour.  It is based on a representation of the complete system as an aggregation of  components. Each component is characterized by a protocol consisting of events, the component can trigger and messages it can process.
The components are distributed horizontally on the diagram, the timeline stretches downwards. Each component has a vertical "lifeline". Interactions are shown as horizontal arrows between the lifelines of the originator of an event to the receiver of  a  message.

Interaction diagrams incorporate no conditional branches; each sequence corresponds to one possible walkthrough (an Use Case) of the system behaviour. The representation can be augmented by  stating possible repetitions of sequences. These repetitions are indicated along the time line. When each path of the control structures has been described in an use case, the control structure can be synthesized from these representations.

The Interaction Diagrams used here differ from the UML Standard in several aspects:

·          In the UML Standard, interactions are tightly related to the program flow; so interactions represent sequences of message calls. Those message calls are originate from the internals of  the control structure of the calling component. The decision to introduce an event based interface isolates the sources of interactions resulting in an component based representation rather than a model of the internal control flow.

·          The possibility to define repetitions by specifying ranges in the timeline reduces the effort to specify complex use cases. Since the determinism of the protocols of the involved components is known, it is possible to find the correct range of interactions for any repetition. The only control instance of a repetition is the repetitive triggering of an event, thus eliminating sources of ambiguity.

·          No conditions are used to control interactions. Any states of the system are represented within the components; state changes are communicated by triggering events. Handling of conditions is typically delegated to state machines. Asynchronous events are strictly queued, so the sequence of events is maintained. In this way, racing conditions are eliminated for the price of reduced responsiveness to hard real time conditions.

The editor for the interaction diagrams is the central window for system design. In this window the basic structure of the system is defined by adding components.

Home

About me

Background

GUI Design

System Safety

System Design Toolkit

Interaction Diagrams

GUI Simulator

State Machines

Collaboration Diagrams

Code Generator

Java Applets

State Diagram Editor forMAC