Introduction to SysML and systems modelling 79

of thousands of applications available for the more popular models, it is impossible

to know, without powering-up the device and looking to see what is installed and
trying the applications out to understand what they do, just what else the smart-
phone is capable of. Also, what about the infrastructure needed to support the
creation and delivery of such applications, let alone that needed to allow the phone
to be used for its most fundamental purpose of making phone calls? How compli-
cated is the infrastructure? Who runs it? How is it paid for? The fact is that all
projects that involve complex systems will have an intangible element about them,
whether it is a control system, a process or whatever.
The important term that is used here is ‘‘complexity’’ rather than size, as size is
not necessarily a reflection of the complexity of a system. The next section dis-
cusses complexity in more detail.

4.3 The three evils

Projects fail and disasters occur for many reasons. However, there are three
underlying reasons why things go wrong, the ‘‘three evils’’ of complexity, a lack of
understanding and communication issues.

4.3.1 Complexity
The concept of complexity will be illustrated in two ways – one that emphasises the
importance of relationships and one that uses a brontosaurus to visualise the nature
of the evolution of complexity.
For the first example, consider five boxes that may represent five elements
within a System, as shown in Figure 4.4(a). Each element may represent almost
anything, ranging from a text sentence that represents a Requirement, to an
assembly that makes up a System, to users that relate to a System. Each of these
elements may very well be understood by whoever is reading the diagram, but this
does not necessarily mean that the System itself is understood.

Block 1 Block 1 Block 1

Block 2 Block 4 Block 2 Block 4 Block 2 Block 4

Block 3 Block 5 Block 3 Block 5 Block 3 Block 5

(a) (b) (c)

Figure 4.4 Complexity manifesting through relationships

80 SysML for systems engineering

Consider now Figure 4.4(b) and it is quite clear that this diagram is more
complex than the previous one, although nothing has changed in the elements
themselves, only the relationships between them.
Consider now Figure 4.4(c) where it is, again, obvious that this diagram is
more complex than its predecessor and far more complex than the first.
In fact, the more relationships are added between the System Elements, the
higher the complexity of the overall System. More and more lines could be drawn
onto this diagram and the complexity will increase dramatically, despite the fact
that the complexity of each of the five elements has not actually increased.
The point that is being communicated here is that just because someone
understands each element within a System, this does not mean that the System itself
is understood. The complexity of a System manifests itself by relationships
between things – in this case the System Elements. It should be borne in mind,
however, that these elements may exist at any level of abstraction of the System,
depending on what they represent; therefore, the complexity may manifest itself at
any point in the System. The complexity of the whole of the System is certainly
higher than the complexity of the sum of its parts.
This may be thought of as being able to see both the woods and the trees.
The second way that complexity is illustrated is through the concept of the
‘‘Brontosaurus of Complexity’’. In this slightly bizarre analogy, the magnitude of
the complexity is analogous to the thickness of the brontosaurus, in that the com-
plexity of a System at the outset is represented by the dinosaur’s head and, as the
Project Life Cycle progresses, this complexity increases (travelling down the neck),
increases even further (through the belly) before reducing and finally ending up at
the tail of the brontosaurus.

Figure 4.5 A brontosaurus

This fits with the shape of the brontosaurus, which is ‘‘thin at one end, much
much thicker in the middle, and then thin again at the far end’’ [2]. The perceived
complexity of a Project is almost always low to begin with, but balloons during the
 Introduction to SysML and systems modelling 81

analysis of a Project, as the understanding of the full impact of the Requirements

and the constraints is fully understood. By the time the problem is fully understood,
a Project is well and truly in the ‘‘belly of the brontosaurus’’, whereas when the
design begins and becomes optimised, then the Project should be heading towards
the ‘‘tail of the brontosaurus’’. By applying the brontosaurus of complexity analogy,
it is shown that one must go from the head (initial ideas and Requirements) to the
tail (System) but that it is impossible to do this without going through the belly of
the brontosaurus.
Consider the situation when a Project is at the head of the brontosaurus, then
this may be visualised as the illustration in Figure 4.4(a). As the complexity of the
Project increases and we move down the neck of the brontosaurus, the complexity
increases, as shown in Figure 4.4(b). In fact, the more relationships are added
between the System Elements (and, hence, the more interactions between them),
the closer to the belly of the brontosaurus we actually get.
Many Projects will fail because the Project never left the belly or, in some
cases, was left even higher up in the neck. If a Project stays in the head or neck,
then there is a great danger of the System being oversimplified and the complexity
inherent in the System is never uncovered until it is too late. If the Project remains
in the belly, however, then the complexity has been realised, but it has not been
managed effectively.
Unfortunately, when a Project is in the belly of the brontosaurus, then it may
seem to the Project personnel that the world is at an end and that there is no
understanding of the Project as a whole. Successfully developing a System is about
being able to see the brontosaurus as a whole and that there is life after the belly.
In a final twist to this analogy, there is major difference between complexity
and the brontosaurus. Complexity is difficult to visualise, but definitely exists in
any System. A brontosaurus, on the other hand, is easy to visualise (see Figure 4.5)
but never actually existed (it was demonstrated in 1974 that the brontosaurus was
actually the body of the Apatosaurus and the head of the Camarasaurus).

4.3.2 Lack of understanding

A lack of understanding may occur at any Stage of the System Life Cycle and also
may occur during any Process. Consider the following examples of a lack of
understating affecting a Project.

● A lack of understating may occur during the conception Stage of a Project,

during a Requirement-related Process. If the Requirements are not stated in a
concise and unambiguous fashion (or, in reality, as unambiguous possible),
then this lack of understanding will cascade throughout the whole Project. It is
widely accepted that mistakes made during early Stages of the Life Cycle cost
many times more to fix during later Stages of the Life Cycle, so it makes sense
to get things right as early as possible [3].
● A lack of understanding may occur during the development Stage of a Project,
during an analysis-related Process. For example, there may be a lack of domain
82 SysML for systems engineering

knowledge during analysis that may lead someone to state false assumptions,
or to actually get something completely wrong due to insufficient knowledge.
Again, uncorrected mistakes here will lead to larger problems further down the
development Life Cycle.
● A lack of understanding may occur during the operational Stage of a Project,
during an operation-related Process. Incorrect usage of a System may lead to a
System failure or disaster. For example, people not following safety procedures
and people not using the correct tools.
Of course, these examples are a merely a representation of some ways that a lack of
understanding can manifest itself in a System – there are many other places in the
Life Cycle where problems may occur.

4.3.3 Communication
The third of the three evils is the problem of communication or, more correctly,
ineffective communication. The richness and complexity of human communica-
tion is what separates humans from other species. One of the earliest recorded
examples of Project failure is that of the Tower of Babel, as described wonderfully
by Fred Brookes [4]. The Tower of Babel started life as a very successful Project
and the first few Stages of the Project went off without a hitch and the Project was
running on schedule, within budget and was meeting all the Project Requirements.
However, one of the key stakeholder’s Requirements was not considered properly,
which was to cause the downfall of the Project. When the stakeholder intervened
in a divine fashion, the communication between Project personnel was effectively
destroyed.
Communication problems may occur at any level of an Organisation or Project,
for example:
● Person-to-person level. If individuals cannot communicate on a personal level,
then there is little hope for Project success. This may be because people have
different spoken languages, technical backgrounds or even a clash of
personalities.
● Group-to-group level. Groups, or Organisational Units within an Organisation,
must be able to communicate effectively with one another. These groups may
be from different technical areas, such as hardware and software groups, or the
groups may span boundaries, such as management and technical groups, or
marketing and engineering. Such groups often use language specific to them-
selves, making inter-group communication difficult.
● Organisation-to-organisation level. Different Organisations speak different
languages – each will have their own specific terms for different concepts, as
well as having an industry-specific terminology. When two Organisations are
working in a customer–supplier relationship, the onus is often on the supplier
to speak the customer’s language so that communication can be effective,
rather than the customer having to speak the supplier’s language. After all, if
the supplier won’t make an effort to speak the customer’s language, it is quite
likely that they will not retain customers for very long.
 Introduction to SysML and systems modelling 83

● System-to-system level. Even non-human Systems must be able to commu-

nicate with one another. Technical Systems must be able to communicate with
technical Systems, but also with financial Systems, accountancy Systems,
environmental Systems, etc.
● Any combination of the above. Just to make matters even more confusing, just
about any combination of the above communication types is also possible.
These problems, therefore, lead to ambiguities in interpreting any sort of commu-
nication, whether it is a spoken language or an application-specific or technical
language.

4.3.4 The vicious triangle

Having established that these three evils exist, matters become even worse. Each of
these three evils does not exist in isolation, but will feed into one another. There-
fore, unmanaged complexity will lead to a lack of understanding and communica-
tion problems. Communication problems will lead to unidentified complexity and a
lack of understanding. Finally, a lack of understanding will lead to communication
problems and complexity.
The three evils, therefore, form a triangle of evil that is impossible to eliminate.
In fact, the best that one may hope for is to address each of these evils individually
when looking at any view of a system.

4.4 What is SysML?

SysML is defined on the website of the OMG (the Object Management Group – the
industry standards body which manages and configures the SysML) as ‘a general-
purpose graphical modeling language for specifying, analyzing, designing, and
verifying complex systems that may include hardware, software, information,
personnel, procedures, and facilities. In particular, the language provides graphi-
cal representations with a semantic foundation for modeling system requirements,
behavior, structure, and parametrics’ [5].
The language originated from an initiative between the OMG and the Inter-
national Council on Systems Engineering (INCOSE) in 2003 to adapt the UML
for systems engineering applications. For more on the history of SysML, see
Section 4.4.2. The primary audience for SysML is systems engineers and the
SysML is intended to provide a general-purpose systems engineering modelling
language.

4.4.1 SysML’s Relationship with UML

The SysML is based on the UML, a general-purpose graphical modelling language
aimed at software engineers and which, on its appearance in 1997, represented a
major unification of the large number of such languages that sprang up in the late
1980s and early 1990s.
The UML defines 13 types of diagram that allow the requirements, behaviour
and structure of a software system to be defined. Because of its appearance the