OMG Systems Modeling Language

Tutorial

May, 2012

Giuseppe Scanniello

Giuseppina Casalaro

System Engineering Overview

• System Engineering (SE) is a discipline to deal with complex system realised

through software and hardware solutions.

• System Engineering applies to the following areas and industries: embedded

systems, automotive, rail, aerospace, military, telecommunication, healthcare,

energy, etc.

• System Engineering relies on modelling and simulation methods to validate

requirements or to evaluate the system.

SysML vs UML

SysML reuses a subset of the UML2 (UML4SysML), and defines its own extensions.

Therefore SysML includes nine diagrams instead of the thirteen diagrams from the UML 2.0,

making it a smaller language that is easier to learn and apply.

Structure of SysML Language

SysML is defined on a modular basis. We can distinguish between elements of the

Structural Model (Structure) used to describe the structure of the system, elements of the

Behavioral Model (Behavior) used to describe the functions of the system, and other model

elements that relate to both (structural and behavioral).

Structure of SysML Language

Specifically:

• The classes are called blocks (the UML Class Diagram becomes

Block Definition Diagram in SysML);

• The Composite Structure Diagram of the UML is called Internal Block

Diagram in SysML. With this diagram you can model the flows

between the various blocks (item flows);

• Two new types of diagrams: Requirement Diagram and Parametric

Diagram;

Behavior Diagram – Activity Diagram

• The Activity Diagram is used to describe the flows in a sequence of actions.

• The flows involving input data and output (required or created within the

stream itself).

• The stream scan run in parallel, to be synchronized, or divided according to

specific conditions.

• The basic elements of this diagram are the activities.

Structure Diagram – Block Definition Diagram

• The Block Definition Diagram defines the properties, operations and relations between

the blocks, giving a hierarchical system.

• It’s based on the UML Class Diagram with restrictions and extensions.

• The elements of the model underlying this graph are the blocks and the

elements attached to it: attributes, data types, units, dimensions, and relations

between the blocks (association: aggregation and composition, dependency and

generalization).

Structure Diagram – Internal Block Diagram

• The Internal Block Diagram describes the internal structure of a block in terms of properties and

connections between them.

• It can be used to represent the interfaces of the system.

• It is based on the Composite Structure Diagram of the UML, with restrictions and extensions.

• The elements of the model at the base of this diagram are always the blocks.

• In particular, the common elements with the Block Definition Diagram (attributes, data types, units,

dimensions, aggregation and composition relationships, dependency, generalization). In the more

they considered the elements role, connectors, ports,

interfaces, item flows, block association, and signals.

Structure Diagram – Parametric Diagram

• The Parametric Diagram is a special form of Internal Block Diagram, in which the blocks

used are of Constraint Blocks through which it is possible to specify constraints that are present in the

properties of a block, i.e. in a part of the system.

• The elements of the model at the base of this diagram are the constraint blocks, and blocks.

But our focus is on…

REQUIREMENT DIAGRAMS

• While the functional requirements can be modeled with the use

cases, present both in the UML that in the SysML:

• Special stereotypes could be defined for use cases to represent non-

functional requirements.

• SysML, has introduced a new type of diagram: the Requirement Diagram,

which allows you to define and describe the requirements and model the

relationships with other requirements or elements of the model.

• The graphical elements are the requirements with model elements related to

it, and relations with other requirements and/or other elements: Containment,

Satisfy, Verify, Derive, Refine, Trace, Copy.

Example of Requirement Diagram 1/2

Example of Requirement Diagram 2/2

Individual Requirement Attributes

• Unambiguous – every requirement has only one interpretation

• Understandable – the interpretation of each requirement is clear

• Correct – the requirement states something required of the system, as judged by the

stakeholders

• Concise – no unnecessary information is included in the requirement

• Traced – each stakeholder’s requirement is traced to some document or statement of

the stakeholders

• Traceable – each derived requirement must be traceable to a higher level requirement

via some unique name or number

• Design independent – each requirement does not specify a particular solution or a

portion of a particular solution

• Verifiable – a finite, cost-effective process can be defined to check that the requirement

has been attained

Attributes of a Set of Requirements

• Unique – there is no overlapping or redundancy among requirements

• Complete – (a) everything the system is required to do throughout the system’s life

cycle is included, (b) responses to all possible inputs throughout the system’s life cycle

are defined, (c) the document is defined clearly and self-contained, and (d) there are no

“to be defined” or “to be reviewed” statements

• Consistent – (a) internal -no two subsets of requirements conflict, and (b) external –no

subset of requirements conflicts with external documents from which the requirements

are traced

• Comparable – the relative necessity of the requirements is included

• Attainable – solutions exist within performance, cost, and schedule constraints

• Organized – grouped according to a hierarchical set of concepts

Definition of Requirement

• A requirement specifies a capability, a function, a service or a condition that the system

must satisfy. This is a stereotype of <<requirement>> element of the UML class.

• The two basic properties of requirement are an ID (unique identifier) and a descriptive

text (text). Both are strings. The text contains a description of the requirement itself

or references to external sources.

• Note: ID and text are attributes of the stereotype <<requirement>> can then

be defined for any requirement.

Representing Relationships

There are three ways to depict requirement relationships in SysML:

• Direct

• Compartment

• Callout

Direct Notation

• Used when the requirement and the related model element appear on the

same diagram.

• Establishes dependency of model element to requirement in model.

• Read figure below as: “The camera satisfies the Sensor Decision

requirement”.

Compartment Notation

• Used when the requirement and model element do not appear on the same

diagram.

• Used for model elements such as blocks or requirements that support

compartments.

Callout Notation

• Used when the requirement and model element do not appear on the same

diagram Uses ‘Note’ box, rather than model element.

• Can be used when the model element or tool does not support compartments.

Requirement Relationships in SysML

There are seven types of relationships in SysML:

1. Containment

2. Satisfy

3. Verify

4. Derive

5. Refine

6. Trace

7. Copy

Containment Relationship

• Depicts Requirement Hierarchy.

• Crosshair points to the parent requirement.

• Parent requirement and Child requirements may not have the same name.

• The relationship containment precludes the reuse of requirements, then SysML

provides the relationship copy (>>).

Satisfy Relationship

• Depicts when a model element satisfies a requirement.

• It says if a requirement is satisfied in full or in part. We can add this information using a

comment or a stereotype.

Verify Relationship

• Used to depict a test case (>>) that is used to verify a requirement.

• The relationship can be represented either by Direct Notation that with the

Compartment Notation.

"Test Case" is an element that controls whether a certain element of the system satisfies a

requirement or not. In SysML, the "test case" can be used as a general mechanism for

representing methods of verification. So, a "test case" is often referenced by a

requirement to report "verify".

Derive Relationship

• Used when a requirement is derived from another requirement based on analysis.

• This report may be used only between requirements.

• Arrowhead points to the source requirement.

Refine Relationship

• Used to depict a model element that clarifies a requirement.

• Typically, a use case or behavioral diagram.

• Arrowhead points to the requirement.

• The relationship can be represented either by Direct Notation that with the

Compartment Notation.

Trace Relationship

• Used to relate requirements to a model element that represents a source for the

requirement.

• It is used only for reasons of traceability.

• Arrowhead points to the model element.

Copy Relationship

•The relationship Copy describes a condition that a requirement is copy of

another requirement.

• It was introduced by SysML because sometimes you need to reuse a requirement in

another context; and use a Containment Requirement may lead to formal problems.

• This relationship allows you to create a copy of the original requirement.

• Name and ID can be different, instead of text must be equal to the original.

Finally… Depicting Rationale

Used to explain or justify a requirement or a requirement relationship

Bibliography:

• A pratica guide to SysML – Friedenthal, Moore, Steiner, Morgan Kaufmann

• Couse Material by Joe Wolfrom, APL

• OMG System Modeling Language Tutorial