Using Blocks to Model Structure and Constraints

The language constructs and expressions in SysML, as with our natural languages, can be divided into structural and behavioral types. In languages such as English, German or Japanese, nouns describe structure and verbs describe behavior. Sentences typically contain a combination of nouns and verbs that bring to light some aspect of the speaker's world. The SysML has a similar division, with elements that describe Structure and other elements that describe Behavior. In SysML the structural things (nouns) are described using a Block. When engineers create diagrams they will often have a mixture of behavior or structure elements and they will describe a particular aspect of a system - bringing to light some aspect of the system being modeled.

The Block is the fundamental unit of system structure; it can be used to describe an entire system, a subsystem, a component, an item that flows through a system, a constraint, or entities that reside outside a system. In a similar way to our natural languages, a Block can represent something abstract, logical or physical. This is an important concept, and writers and readers of the SysML must be clear as to the intention of the representation. For example, in a logical architecture there are typically Blocks representing conceptual ideas or designs that at the time of detailed design and construction might be realized by physical and tangible components. A systems architect might define a Block called Collision Detection Subsystem that is an expression of a logical system component that could at the detailed design phase, be in part, realized by a set of radar and laser transmitters, detectors and cameras.

A number of our natural languages have a grammatical term called classifiers, which group the things (nouns) of a lexicon into classes of things that share common characteristics and behavior. This same principle applies to Blocks, which are essentially a type of classifier that groups a collection of instances that share the same structural and behavioral features. Instances of a Block can be modeled in a generic way or they can be given precise values, such as the volume of petrol contained in a fuel tank at a particular point in a journey or at the time of an accident.

In the Fuel Tank diagram the car is modeled as a classifier (Block) level, where the model is describing a generic vehicle and representing the fact that a vehicle could have one, or a maximum of two, fuel tanks. This Fuel Tank Instances diagram, however, describes a particular vehicle that has two fuel tanks that have different capacities and reserve volumes.

A Block defines a collection (or set) of features that are used to  describe a system, subsystem, component or other element of interest. These features can include both structural and behavioral features, such as properties, operations and receptions, to represent the state of the system and the behavior that the system is capable of exhibiting.

Enterprise Architect has a powerful set of tools that help the systems engineer to work with Blocks and to visualize the structure and behavior of these all-important elements in a system's definition. These facilities include the:

• Block Definition Diagram, which describes the Blocks, their features, interaction points and structural relationships
• Internal Block Diagram, which captures the internal structure of a Block in terms of properties and connectors between properties

This Internal Block Diagram shows how a number of sub-systems cooperate to create the structure of the vehicle. For example the Lighting Subsystem has a connection with the Interior Subsystem which in turn has a connection to the Body Subsystem.

Some relationships have been suppressed in the diagram; for example, the Power Subsystem would typically have a connection to the Lighting Subsystem. This point is important, as newcomers to SysML and Enterprise Architect often think that every defined relationship should be displayed in a diagram. While this statement appears to be true it is important to remember that a modeler, like a cartoonist creating a caricature, will often leave details out of illustrations to focus the viewer's attention on other subjectively more important elements and connectors.

This screen capture shows how an engineer can set the visible relationships for a diagram.

If a connector is not checked in this dialog it will not be displayed in the current diagram. It might, however, be visible in other diagrams where the connected elements are displayed. This can be set from the 'Layout > Diagram > Appearance > Visibility > Set Visible Relationships' ribbon option.

Regardless of which connectors are displayed in a diagram, a modeler can always view all of an element's connectors by selecting the element in the diagram and viewing the Traceability window. In this screen capture the Power Subsystem has been selected, and even though the connector between the  Power Subsystem and the Lighting Subsystem has been set to 'not Visible' in the diagram, the relationship can be seen in the Traceability window.

The features of a Block are either structural or behavioral.

The structural features are of three kinds:

• Parts - that describe the composition of a Block; for example, that a vehicle's chassis is composed of two axles and four wheel assemblies
• References - that describe the Block's relationship with other Blocks (including itself); for example, that a metropolitan train has a relationship to a station and an overhead wiring system
• Values - that describe quantifiable aspects of a Block; for example, such things as dimensions, temperature and luminosity

The Behavioral features include:

• Operations  - typically representing synchronous requests
• Receptions - representing asynchronous requests from a signal