Yes, SysML and UML are designed to be used together in the same project, where the Software Engineers use SysML for Requirements and System Analysis, and the Software Engineers use UML for Software Design. Unfortunately, many important details about how UML-SysML joint usage will work efficiently in practice are not addressed in the OMG SysML specification. The underlying problem is not mixed UML-SysML tool support, since many SysML tool vendors are UML tool vendors who implement SysML as a UML profile. In the more detailed answer that follows we assume that most UML-SysML tool vendors will be able to provide their users with "SysML only," "UML only," and "UML-SysML combined" usage modes or perspectives (the Eclipse term).
In order to understand the pragmatic problems of SysML-UML joint usage, let's consider the case of a large engineering project with many Systems Engineers and Software Engineers collaborating, where the former choose to specify Requirements and System Analysis in SysML and the latter select to specify Software Design in UML. The problems they encounter will range from linguistic overlap, where notations and semantics are similar, but differ in subtle yet important ways, to linguistic divergence, where there is no straightforward translation between the two. An example of relatively straightforward linguistic overlap is the translation between SysML Activity diagrams and UML Activity diagrams, where both diagram types use the same naming conventions, but the former make some modest notational extensions to the latter. UML profiles and stereotypes were designed to handle this case, so mixed teams using both SysML and UML Activity diagrams should not be confused by this mixed language usage.
Less straightforward is the linguistic overlap between SysML Block Definition/Internal Block diagrams and UML Class/Internal Structure/Component diagrams, where there are several issues involved in translating the former to the latter. These range from gratuitously different naming conventions (Blocks vs. Classes vs. Components), to more substantial issues such as adding SysML constructs with ambiguous semantics (e.g., SysML Item Flows) and diverging from UML's Class-Part-Instance trichotomy. (SysML has only recently added Instance Specifications with the SysML 1.2 minor revision and the ramifications of this change have not yet been fully worked out.)
There are also substantive linguistic divergence problems associated with at least one of SyML's new diagram types, Parametric diagrams. The SysML provides notation, but sparse semantics for this new diagram type, which introduces a constraint-logic paradigm that is not fully integrated into UML's object-component paradigm. In addition, SysML's Allocation relationships and UML's Trace/Refine relationships are ambiguous and overlap, so it is frequently unclear how to map SysML System Analysis constructs to UML Software Design constructs. For these reasons, project teams who plan to use both SysML and UML on large project should be aware that they will likely encounter both subtle and substantive translation and traceability problems. Hopefully vendors and methodologists will work out these problems soon, after they gain more experience applying SysML to real projects.
Back to Top
