SysML – The Clay of Systems Modelling

By Alex Stevenson, Principal Consultant, Objektum Solutions Limited

“No man ever wetted clay and then left it, as if there would be bricks by chance and fortune.”

   -Plutarch

 

Whenever the subject of Model based Systems Engineering (MBSE) is raised the OMG’s Systems Modeling Language (SysML) is likely to feature in the discussion. Since its publication in 2007 SysML, like its software counterpart UML, has risen to become the de facto standard when modelling system behaviour and architecture. Prior to the introduction of SysML there were a variety of techniques and notations used; each with their own strengths and weaknesses. While SysML is, by no means, a perfect solution to all modelling needs it offers significant advantages in many areas. Some of these include:

• Its graphical nature helps to breach language constraints
• It is closely aligned to UML and therefore improves communication with software disciplines
• It is independent of toolset implementation but supported by major tool vendor
• It is process and method independent and therefore suitable for use on almost any project

SysML provides syntax for representing systems but does not impose any methodology for its use. In that I liken it to the toolbox in your garage. The toolbox provides you with everything that you require to fix your car but does not tell you how to go about making the repairs. SysML supports the specification, analysis, design, verification and validation of a broad range of complex systems with each SysML diagram lending itself to representing specific aspects of the system. An effective MBSE method ensures that the correct diagram is used for the correct purpose to produce a system model that can be used to:

• Understand and better define the problem space
• Analyse agreed requirements for consistency and completeness
• Define the necessary structures and behaviours to satisfy the requirements
• Specify requirements for system verification and validation
• Provide design context / requirements for subsystems etc.

SysML is divided into four broad aspects, often referred to as its four pillars that specify; textual requirements, system behaviour, system structure and and parametric relationships.

There are currently 9 SysML diagrams; they are:

• The block definition diagram is used to show the elements that exit within a system and the relationships that exist between them (usually system hierarchy)
• The internal block diagram identifies the internals of a block and the connections that exist between its parts (often used for modelling interfaces)
• The package diagram depicts the structure of the model (especially nesting and dependencies between packages)
• The use case diagram shows the services that are provided by the system and the external entities that interact with the system in order to initiate and support those services
• The sequence diagram shows interactions between the parts of a system as a sequential set of behaviours. It can also be used to represent the interactions specified in use cases.
• The activity diagram shows system behaviour as a flow of control or objects. It is used to represent complex logic that involves decision making and concurrent behaviour.
• The state machine diagram is used to show the states that a system exists in, the events that trigger state changes and the system response to those events.
• The parametric diagram is used to express how the properties of a system are constrained and is used to perform analysis of things such as performance and reliability.
• The requirement diagram is used to represent textual requirements and the relationships between those requirements and the other artefacts in the model

 

In the coming weeks I will take a look at each of these diagrams in further detail; providing an overview of their syntax, discussing possible usage as well as their strengths and weaknesses of each.