Please note : This help page is not for the latest version of Enterprise Architect. The latest help can be found here.

Prev Next

Coordinating Behavior with Activities

As discussed in an earlier topic, the Systems Modeling Language (SysML) has two fundamental aspects that are analogous to two important grammatical categories in the natural languages humans use to communicate, namely nouns and verbs. In the SysML these are Structural and Behavioral Constructs; Structural Constructs being analogous to nouns in our natural languages, and Behavioral Constructs being analogous to verbs.

We referred to the structural aspects of the Language in previous topics, when we discussed both Packages and Blocks. We will now turn our attention to the main Behavioral diagram, namely the Activity diagram. There are a number of other behavior diagrams, and indeed behavior is visible in structural diagrams in the form of operations and also in the Behavior that is assigned directly to a Block.

While the newcomer to SysML, viewing the Activity diagrams for the first time, might be reminded of the flow chart, they will soon learn that the Activity diagram has powerful syntax and semantics that go far beyond the chart. The Activity diagram is formally based on a branch of mathematics called Petri Nets and it uses a system of tokens to indicate both the sequence of actions and also the items that flow through the system. The items that flow can be information items, physical items or even control signals. We will reference this token system as a way to illuminate the working of the Activity diagram.

This diagram, describing a vehicle's acceleration, shows many of the elements that are commonly seen on an Activity diagram. You will see in the subsequent topics that it is a very expressive diagram that, if crafted carefully, can rigorously convey a lot of information.

In fact the syntax of the Activity diagram is one of the richest of any of the SysML diagrams, and when you add to this the powerful mechanisms and tools that Enterprise Architect includes to work with these diagrams, the opportunities for a modeler to express themselves makes these one of the most versatile but also challenging parts of system representation.

The SysML Activity diagram is based on the UML diagram of the same name, but additional semantics have been added in two areas:

  • Continuous Flow, allowing restrictions on the rate at which entities flow along edges in an Activity, and mechanisms to ensure that the most recent information is available to Actions
  • Probability, introduced into Activities to include the likelihood that a value will be available to an edge or output on a parameter set

While the diagram might be said to be based on verb serialization mechanisms (strings of verbs connected together with nouns) in our natural language, as mentioned earlier it has its formal origins in a branch of mathematics called Petri Nets and token flow. It is imperative that a modeler understands the token flow aspect of the language, and can learn to visualize these invisible items that flow through Object Flows, are detained at buffers, and are controlled by other language mechanisms that direct how items flow from Actions. Without this understanding it is difficult to interpret an Activity diagram, including how the sequence of Actions is controlled, how the inputs are consumed and how the outputs are created.

The significant difference between Activity diagrams and any of their close cousins, such as Flow Charts or Process diagrams, is the ability to create relationships between these behavioral elements and structural elements.

A fundamental aspect of the discipline of Systems Engineering is the ability to segregate function from form, but also to be able to create a mapping between them that exposes the seams that relate these two integral parts of architecture and design. Empirical evidence on large scale, complex systems engineering problems has proven that profound benefit results from this approach.

Enterprise Architect provides a rich toolbox to work with these relationships, including the ability not only to allocate system behavior in the form of Activities and Actions to Blocks, but also to relate these elements to behavioral features owned by Blocks, such as operations.