In last month’s blog, Modeling SysML Activities in GENESYS, I discussed how to model behavior using activity diagrams. What, though, are interactions?
Interactions are a UML concept brought over into SysML that can be used as an alternative approach for modeling behavior in SysML. Interactions are distinct from activities and are modeled in SysML using sequence diagrams. Some SysML tools also provide access to the UML interaction diagram as well and allow modeling of the flow between interactions.
While the notion of an interaction is essential to software engineering, the use of an interaction for systems engineering as a distinct idea from an activity can be troublesome. Fortunately, GENESYS makes this process easy. I’ll first describe how behavior is modeled with SysML using interactions. I’ll then describe how to model behavior in GENESYS using interactions.
Interactions in SysML
While activities in SysML represent functional elements that transform inputs into outputs as depicted on activity diagrams, interactions are defined as an expression of behavior in a sequence of message exchanges between elements of the system design. Interactions are represented on a sequence diagram using a set of constructs called lifelines, activations, and messages.
In SysML a modeler working with sequence diagrams thinks in terms of the physical design and chooses a set of blocks, or components of a system design. Next, the modeler defines message exchanges between the blocks and depicts a series of synchronous or asynchronous message exchanges. Activations representing internal functionality can be added to a lifeline to denote functional processing. Once a sequence diagram is complete, the system modeler ensures that all block behavior is defined to initiate and respond to messages on the sequence diagram.
Interactions in GENESYS
In GENESYS, interactions are aligned with the system metamodel class Function. Lifelines are aligned with the GENESYS class Component, activations with the GENESYS class Function, and messages with the GENESYS class Item.
Recall that flows on activity diagrams are also modeled as Items in GENESYS and activities are modeled as Functions. Since interactions are not a distinct metamodel element in GENESYS, the message flow between functions in GENESYS may be depicted using activity diagrams, and the message exchange between associated design elements may be depicted on sequence diagrams. Alignment of interactions and activities in this way creates a complementary pairing of activity and sequence diagrams that streamlines the work of the systems engineer.
In GENESYS, once allocations of activities (functions) to blocks (components) is complete, a sequence diagram is rendered for the systems engineer based on the information contained in the corresponding activity diagram.
Take, for example, the activity diagram shown in Figure 1. In Figure 1, Activity Y.1 and Activity Y.2 are allocated to the ABC assembly; Activity Y.3 and Activity Y.4 are allocated to the HIJ assembly; and Activity Y.5 is allocated to the QRS assembly. (Note that the node template has been set to Name/Allocation.) The flow of behavior is shown as well. First, there is a select control that provides exclusive OR logic. Next, there is a parallel control that provides AND logic. There is also a looping construct surrounding Activity Y.4.
Figure 1. An activity diagram showing allocations of behavior
From the same database information used to construct the activity diagram in Figure 1, GENESYS is able to generate an equivalent sequence diagram as shown in Figure 2. Once the allocations of the activities (functions) to the blocks (components) are in place, GENESYS can create lifelines to depict blocks and uses the same constructs shown in activity diagrams to derive sequencing and message exchanges.
Items that trigger behavior will usually begin an activation while non-triggering items are typically received during execution. In Figure 1, note that Item 001 is triggering Activity Y.3 (Recall that flows on activity diagrams that do not trigger activities are decorated with the <<optional>> decorator, while triggering flows do not display a decorator.) In the model depicted in Figure 1, Activity Y.1 is not decomposed and Item 001 is treated as sent at the completion of Activity Y.1. Since Activity Y.3 is on a parallel branch, it is enabled, but cannot execute until receiving the triggering Item 001.
Figure 2 depicts the same functional flow, but using a sequence diagram to show the message exchanges between lifelines. Notice that in GENESYS, the activations are labeled to show the sub-functionality of the interaction (i.e. function). We can now see that same behavior depicted in Figure 1 as it is sequenced in time. Referring to Figure 2, once Activity Y.1 completes its operation within Assembly ABC, the message Item 001 is sent to Assembly HIJ, triggering the execution of Activity Y.3.
Also, as shown in Figure 2, GENESYS will automatically insert the appropriate partitions for OR, AND or looping logic depicted in Figure 1. Activity and sequence diagrams can form a pair for any given function modeled within GENESYS. The aspect of timing is better communicated with the sequence diagram, while the logical flow is better communicated using the activity diagram.
Figure 2. A sequence diagram
Summary
SysML uses several terms to describe behavior. Activities, actions, interactions, activations, and methods are all modeled in GENESYS using the metamodel class Function. Flows, signals, events and messages are aligned with the GENESYS metamodel class Item. More importantly, using GENESYS, a systems engineer models behavior only once and has confidence that both activity and sequence diagrams are internally consistent.
The mutually compatible relationship between activity and sequence diagrams makes the modeling of behavior easier and allows you to create simpler and more consistent models of behavior without any loss of fidelity. This allows you to better understand and communicate system behavior to stakeholders.
If you have any questions about activities and SysML in general, feel free to contact me at mark.simons@vitechcorp.com. Remember, too, that I’m available as part of your CORE or GENESYS maintenance agreement to help explain the systems engineering uses of Vitech tools.
