OMG Systems Modeling Language Tutorial May, 2012 Giuseppe Scanniello Giuseppina Casalaro
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