The sixth part of the blogpost series about the changes in SysML 1.4 presents the updated concepts for blocks and ports. The new concept of bound references is already covered in the special blogpost What’s new in SysML 1.4 – Constraining decompositions.
A SysML block can own behaviors. For instance a state machine or an interaction. A special behavior owned by the block is the so-called classifier behavior. It represents the autonomous behavior of a block and is executed when an instance of the block is created and terminates with the deletion of the instance.
With the new SysML 1.4 the owned or classifier behavior can be depicted in special compartments of the block rectangle. The following figure shows a block that represents a forest fire detection system (FFDS). The compartment classifier behavior depicts a state machine that specifies the states of the FFDS including the reaction when events are received. The compartment owned behavior depicts an activity that specifies how the FFDS switches to the maintenance mode.
Each compartment of a block could also be shown as part of the shape of a property typed by that block, i.e. the classifier behavior and owned behavior compartments could also be depicted in a internal block diagram.
With a generalization relationship from one block to another block the block at the source side of the relationship inherits the features (properties, operations) of the block at the target side. The following figure shows parts of the definition of the sensors of our forest fire detection system. The sensors are specializations of the abstract sensor that specifies some general properties. These properties are inherited, i.e. they are also part of the definition of the special sensors. To overlook all features of a block in a block definition diagram you must see the complete generalization hierarchy and visually collect the features along the generalization paths.
In SysML 1.4 the new notation of inherited features displays all inherited features of a block in the appropriate compartments. The next figure depicts the specific sensors with the new notation. The syntax of inherited features is like “normal” features with a leading ^ symbol.
Parts in a internal block diagram are properties. Inherited parts are shown the same way as properties or operations in the block compartments with a leading ^ symbol before the name of the part. The next figure depicts a simple example of the inherited part notation.
The adjunct property constraints the values of the property to other values in the model. The values are instances of association blocks, call actions, object nodes, variables, parameters, interaction uses, or submachine states..
An application of adjunct properties is the activity tree. The activity tree shows the call hierarchy of activities in a block definition diagram. The following figure depicts a activity tree of the FFDS use case activitiy Detect and report fire.
The properties of the association ends are adjunct properties depicted by the stereotype «adjunct». The values of those properties are constrained to the values of the appropriate call behavior actions defined in the context of the activity. Next figures depicts the activity diagram of Detect and report fire:
Ports with Compartments
Any notation available for parts is also available for ports. That includes compartments with textual or graphical representations. The port shape is accordingly large and still placed on the border of the appropriate part rectangle.