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:
* 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|
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|
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|
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,
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
Other resources on Embedded.com about UML and SysML:
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