Channels ▼
RSS

Design

SysML - The Systems Modeling Language


The SysML initiative is a joint effort between the OMG " the owners of the UML specification " and INCOSE " the systems engineering organization. The Request for Proposal (RFP) for a UML profile suitable for systems engineering was issued in March 2003 and the resulting submission effort is nearing its end. The single submission group includes both tool vendors and users (practicing systems engineers) and extends the UML 2.0 in some important ways for systems modeling and development.

What about UML?
Why not just UML? UML 2.0 focused on some crucial issues for systems engineers, especially with respect to architecture and scalability to very large and complex systems. While UML is a very flexible and powerful modeling language and is supported by a many tools, it is, at its heart, a discrete modeling language. Also, there are parts of the UML that are too software-centric for some system engineers.

However, the UML provides a backdoor " well, two really " for handling UML's limitations. The UML can be extended by using its lightweight extension mechanisms stereotypes, tagged values, and constraints. Coherent sets of these extensions can be grouped together to form what is called a profile. A profile is a specialized version of UML that may be a subset of the UML as well as an extension and new notations.

Profiles do have some limitations though. The UML is specified by the definition of a metamodel consisting of metaclasses (such as "class", "state", "event" and so on). This metamodel specifies what each element of UML is, its semantic meaning, and its relations to other UML elements. A profile is not allowed to add new metaclasses, but only to extend existing metaclasses.

When this approach is insufficient, the UML can be extended by metamodeling. While this is not a true profile, it is a legitimate way to extend the UML and provides much more flexibility than profiles. On the other hand, existing UML compliant tools support profiling mechanisms but very few support metamodel extensions. Thus, it is generally perceived as more useful to use profiles where possible to maximize the number of existing tools that support the specialized version of the UML.

The UML 2.0 provides strong modeling for structural aspects, particularly with structured classes, good modeling for behavioral interactions with decomposable sequence diagrams, first-class behavioral modeling with statecharts and activity diagrams. However, the UML doesn't provide any good means for modeling continuous behavior or parametric relations.

This article is excerpted from a paper of the same name presented at the Embedded Systems Conference Boston 2006. Used with permission of the Embedded Systems Conference. For more information, please visit www.embedded.com/esc/boston/

Enter the SysML
One of the goals of the SYSML was to be 80% UML. As we near the completion of this effort, the SysML specification is more like 90% UML with a few, but significant, extensions. It is also designated as a profile with (possibly) a few metamodel extensions where necessary. Much of UML 2.0 is reused in the SysML while other parts of UML are omitted. On top of that, SysML adds new features of its own.

Figure 1: Relation between UML and SysML

While this work is still underway, there are a number of key features that are stable from the user point of view that hold great promise for systems modeling. These are:

* Requirements
* Assemblies
* Parametrics
* Continuous activity diagrams

To support these new features, the SysML adds some new diagram types. The diagrams available in the SysML are shown in Figure 2, below. As can be clearly seen from the figure, most of the UML diagrams are reused.

Figure 2: SysML Diagrams

Requirements
One of the weaknesses of the UML is that it has no notion of a "requirement. " Use cases model coherent sets of operational requirements and are often elaborated with sequence diagrams, state machines, and activity diagrams, but there is no direct semantic element of a "requirement" per se.

The SysML adds such an element and a new diagram type used to represent requirements and their taxonomic relations. The relations among requirements are shown with stereotyped relations such as «trace», «includes», «assign» and so on. One such diagram is shown in Figure 3, below. In this figure, the requirements are related to a use case as well as to other requirements elements.

The advantage of this modeling is not only the capture of the requirements themselves, which can be done with simple text, but also the explicit relationships between requirements. In addition, it is now possible for the first time to have model-level traceability of requirements to other model elements completely within the UML model itself.

Figure 3: Requirements Diagram

Assemblies
UML 2.0 has the notion of structured classes " that is, classes that are composed of parts (object roles), each of which is specified by a class. Figure 4 below shows an example structured class. Each of the internal parts is an object role, and is specified by a class. Assemblies are just structured classes. In fact, an active area of discussion within the SysML group is whether assemblies ought to be differentiated from structured classes at all.

Figure 4: Structured Class in UML

Structured classes are used to represent classes that are composed of internal parts. In the SysML, these classes might specify objects that are purely mechanical, electrical, chemical, software, or any combination. The example in Figure 5 below shows a mechanical linkage of a mass suspended by a spring.

Figure 5: Assemblies

Parametrics
Parametric relations are relations between parameters. Newton's law "F = ma" is one such parametric relation. In many system engineering problems, it is necessary to model the parametric relations among a set of physical items or quantities.

It is useful to note that while a parametric expression can be evaluated, it is not a behavior. A behavior describes a computational algorithm that evaluates in a specific sequence. A parametric equation is different in that binding any n-1 parameters of a parametric relation allows use to define the remaining one. Thus, parametric relations are not behaviors " they are statements of the relationship of quantifiable properties of a set of items. Figure 6 below represents the relations between the cannon and the shot that it shoots; specifically Newton's law and the mass relation.

Figure 6: Parametric Diagram

Continuous Activity Diagrams
The most significant extension of the UML to be found in the SysML is the capacity to model continuous behavior. Activity diagrams in UML 2.0 are based on token-execution semantics; that is, an activity executes when it has a token that enables it to run.

An activity has an execution token when there is data on all of its input pins. Input pins correspond to input parameters on a function or procedure. When an activity completes, it puts data on all of its output pins. Output pins correspond to output parameters for a function or procedure. Such behavior is highly discrete.

In SysML, activity diagrams are extended to support continuous behavior by adding constraints the flows between activities. These flows can be discrete, streaming, or control. Discrete flows are standard UML activity diagram flows. Streaming flows allow modeling of continuous movement of material. Control flows allow the switching on or off of activities.

Figure 7: Continuous Activity Diagram

Consider the problem of modeling the behavior of a water filter that takes in sludge and puts out clean water along one pipe and dirt along another. How would we model this with this with UML activity diagrams? What are the tokens? With SysML, modeling this behavior is a straightforward application of streams with control and discrete flows on an activity, as shown in Figure 7, above.

Dr. Bruce Powel Douglass, chief evangelist at i-Logix, now the Telelogic Systems and Software Modeling Business Unit, has over 25 years experience designing safety-critical real-time applications in a variety of hard real-time environments. He has designed and taught courses in object-orientation, real-time, and safety-critical systems development. He is an advisory board member for the Embedded Systems Conference and co-chair for the Real-Time Analysis and Design Working Group in the OMG standards organization.

Other resources on Embedded.com about UML and SysML:

1) Need for modeling tools rises with design complexity
2) In Focus: Unified Modeling Language
3) Introduction to UML statecharts
4) UML evolves total system perspective
5) Introduction to UML Class Diagrams
6) State machine shortcuts
7) From UML to embedded system: Is it possible?
8)  How to use UML in your  SoC Hardware/software design


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video