The SysML initiative is ajoint effort between the OMG” the owners ofthe UML specification ” and INCOSE ” the systems engineeringorganization. The Request for Proposal (RFP) for a UML profile suitablefor systems engineering was issued in March 2003 and the resultingsubmission effort is nearing its end. The single submission groupincludes both tool vendors and users (practicing systems engineers) andextends the UML 2.0 in some important ways for systems modeling anddevelopment.
What about UML?
Why not just UML? UML 2.0 focused on some crucial issues for systemsengineers, especially with respect to architecture and scalability tovery large and complex systems. While UML is a very flexible andpowerful modeling language and is supported by a many tools, it is, atits heart, a discrete modeling language. Also, there are parts of theUML that are too software-centric for some system engineers.
However, the UML provides a backdoor ” well, two really ” forhandling UML's limitations. The UML can be extended by using itslightweight extension mechanisms stereotypes, tagged values, andconstraints. Coherent sets of these extensions can be grouped togetherto form what is called a profile. A profile is a specialized version ofUML that may be a subset of the UML as well as an extension and newnotations.
Profiles do have some limitations though. The UML is specified bythe definition of a metamodel consisting of metaclasses (such as”class”, “state”, “event” and so on). This metamodel specifies whateach element of UML is, its semantic meaning, and its relations toother 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 bymetamodeling. While this is not a true profile, it is a legitimate wayto extend the UML and provides much more flexibility than profiles. Onthe other hand, existing UML compliant tools support profilingmechanisms but very few support metamodel extensions. Thus, it isgenerally perceived as more useful to use profiles where possible tomaximize the number of existing tools that support the specializedversion of the UML.
The UML 2.0 provides strong modeling for structural aspects,particularly with structured classes, good modeling for behavioralinteractions with decomposable sequence diagrams, first-classbehavioral modeling with statecharts and activity diagrams. However,the UML doesn't provide any good means for modeling continuous behavioror parametric relations.
|This article is excerpted from a paper ofthe same name presented atthe Embedded Systems Conference Boston 2006. Used with permission ofthe 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 thecompletion of this effort, the SysML specification is more like 90% UMLwith a few, but significant, extensions. It is also designated as aprofile with (possibly) a few metamodel extensions where necessary.Much of UML 2.0 is reused in the SysML while other parts of UML areomitted. On top of that, SysML adds new features of its own.
|Figure1: Relation between UML and SysML|
While this work is still underway, there are a number of keyfeatures that are stable from the user point of view that hold greatpromise for systems modeling. These are:
* Assemblie s
* Continuous activity diagrams
To support these new features, the SysML adds some new diagramtypes. The diagrams available in the SysML are shown in Figure 2, below. As can be clearlyseen from the figure, most of the UML diagrams are reused.
|Figure2: SysML Diagrams|
One of the weaknesses of the UML is that it has no notion of a”requirement. ” Use cases model coherent sets of operationalrequirements and are often elaborated with sequence diagrams, statemachines, and activity diagrams, but there is no direct semanticelement of a “requirement” per se.
The SysML adds such an element and a new diagram type used torepresent requirements and their taxonomic relations. The relationsamong requirements are shown with stereotyped relations such as«trace», «includes», «assign» andso on. One such diagram is shown in Figure3, below . In this figure, the requirements are related to a usecase as well as to other requirements elements.
The advantage of this modeling is not only the capture of therequirements themselves, which can be done with simple text, but alsothe explicit relationships between requirements. In addition, it is nowpossible for the first time to have model-level traceability ofrequirements to other model elements completely within the UML modelitself.
|Figure3: Requirements Diagram|
UML 2.0 has the notion of structured classes ” that is, classes thatare composed of parts (object roles), each of which is specified by aclass. Figure 4 below shows anexample structured class. Each of the internal parts is an object role,and is specified by a class. Assemblies are just structured classes. Infact, an active area of discussion within the SysML group is whetherassemblies ought to be differentiated from structured classes at all.
|Figure4: Structured Class in UML|
Structured classes are used to represent classes that are composedof internal parts. In the SysML, these classes might specify objectsthat are purely mechanical, electrical, chemical, software, or anycombination. The example in Figure 5below shows a mechanical linkage of amass suspended by a spring.
Parametric relations are relations between parameters. Newton's law “ F = ma “ is onesuch parametric relation. In many system engineering problems, it isnecessary to model the parametric relations among a set of physicalitems or quantities.
It is useful to note that while a parametric expression can beevaluated, it is not a behavior. A behavior describes a computationalalgorithm that evaluates in a specific sequence. A parametric equationis different in that binding any n-1 parameters of a parametricrelation allows use to define the remaining one. Thus, parametricrelations are not behaviors ” they are statements of the relationshipof quantifiable properties of a set of items. Figure 6 below represents therelations between the cannon and the shot that it shoots; specificallyNewton's law and the mass relation.
|Figure6: Parametric Diagram|
Continuous Activity Diagrams
The most significant extension of the UML to be found in the SysML isthe capacity to model continuous behavior. Activity diagrams in UML 2.0are based on token-execution semantics; that is, an activity executeswhen it has a token that enables it to run.
An activity has an execution token when there is data on all of itsinput pins. Input pins correspond to input parameters on a function orprocedure. When an activity completes, it puts data on all of itsoutput pins. Output pins correspond to output parameters for a functionor procedure. Such behavior is highly discrete.
In SysML, activity diagrams are extended to support continuousbehavior by adding constraints the flows between activities. Theseflows can be discrete, streaming, or control. Discrete flows arestandard UML activity diagram flows. Streaming flows allow modeling ofcontinuous movement of material. Control flows allow the switching onor off of activities.
|Figure7: Continuous Activity Diagram|
Consider the problem of modeling the behavior of a water filter thattakes in sludge and puts out clean water along one pipe and dirt alonganother. How would we model this with this with UML activity diagrams?What are the tokens? With SysML, modeling this behavior is astraightforward application of streams with control and discrete flowson an activity, as shown in Figure 7,above.
Dr. Bruce Powel Douglass, chiefevangelist at i-Logix, now the Telelogic Systemsand Software Modeling Business Unit, has over 25 years experiencedesigning safety-critical real-time applications in a variety of hardreal-time environments. He has designed and taught courses inobject-orientation, real-time, and safety-critical systems development.He is an advisory board member for the Embedded Systems Conference andco-chair for the Real-Time Analysis and Design Working Group in the OMGstandards organization.
Other resources on Embedded.com about UML and SysML :
1) Needfor 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) Howto use UML in your SoC Hardware/software design