CONSTRAIN YOUR DESIGN BY CHOICE, NOT BY CHANCE

Jim Albers, Albers Aerospace Engineering Solutions

When designing a system with SysML, some choices have non-intuitive implications and consequences. For example: should inter-component interfaces be modeled using Pins and Object Flows, or using Ports with Flow Properties that pass Signals? And as a corollary, do the exchanges of messages / objects using either method trigger asynchronous behaviors?A principle of good modular design is to design modules with loose coupling with other modules, and high internal cohesion of functions and parts. A good module should be a black box with well-defined externally accessible state and behavior, and well-defined interfaces with managed access points by which modules interact.High internal cohesion means that internal parts can be wired together in stable configurations that don't change much. Using Pins, Connectors, and ObjectFlows are a good way to define internal wiring between parts that have synchronous interactions, for example, where an action can block until an input pin is active.Low external coupling means that external interfaces should not depend on a priori knowledge about other module's connection points via pins. Good module design allows modules to respond asynchronously to events in their environment communicated via Signals.Ports provide an explicit way to expose and access internal state and behavior, and should always be used on the boundaries of modules.Signals provide a way to 'wrap' an object or message in a way that provides events associated with the sending and receiving of the object/message. Signals provide a clean way to model asynchronous interactions among modules. Asynchronous messaging via Signals scales to very large systems, and can support any 'message exchange pattern', from a 'call/return' remote procedure call exchange, to a 'publish/subscribe' streaming exchange, or a 'command/response' exchange that may involve a highly specific protocol of command, ack, nak, wilco, haveco, status, and completion messages.Because Signals have associated Accept/Receive events that can be used as triggers, they are ideal for triggering transitions in State Machine models, a commonly used and powerful way to model behaviors, especially external, testable module behaviors.In SysML 1.5 it is possible to connect an Object Flow Property on a Port on the boundary of a module with an Object Pin internal to the module with Adjunct and Principal relationships, so it is possible to wire together modules using only Object Flows and not use Signals. However, this is complex, and the arrival of an Object on a Port doesn't give the same event support that a Signal does. Signals have a special behavioral feature called a Reception that makes it easy to design systems and software to handle Signals.In SysML 2.0 Object Flows on Pins will gain the same event support that Signals have in SysML 1.5, so in SysML 2.0 the difference between Pins and Object Flows and Ports and Signal Flow Properties may become irrelevant, and the need for Signals per se may disappear.So what do Signal-based interactions look like in subsystem Activity models with multiple modules and swimlanes? Instead of direct wiring of pins across swimlanes, the swimlanes can show SendSignal and AcceptSignal actions that describe how modules interact via Signals. Interaction models and their associated Sequence diagrams then become a natural way to show multi-module interactions, emphasizing interaction on interfaces rather than control flows within Activity swimlanes.