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.
