Introduction
SysML was developed in response to the same issues that MDSD addresses—the need to be able to promote shared understanding across a wide set of stakeholders and participants in the systems development process, the need to manage complexity through separation of concerns with multiple views of a system, and the need to provide traceability through a hierarchy of models, among other things.2
MDSD (RUP SE) as contributor to SysML
MDSD, like RUP SE and object-oriented software engineering (OOSE), predates SysML. In fact, MDSD was developed in response to the same kinds of pressures that Rational and then IBM clients were feeling as they developed large, complex, systems of systems. SysML was developed by a consortium of industry participants. IBM and their SysML partner EmbeddedPlus Engineering played an active role in its development (especially IBM participants Murray Cantor and Laurent Balmelli, and EmbeddedPlus participants Salah Obeid, Cory Bialowas, Jim Hummell, and Kumar Marimuthu) contributing concepts and writing parts of the specification. Concepts from RUP SE influenced the development of SysML, for instance, the need for means to express semantics of localities, distribution of responsibilities, and ability to reason about non-functional requirements and a wide variety of stakeholder concerns.
MDSD with SysML
Because SysML was developed in response to the same kinds of issues that MDSD wants to address, it makes sense to use SysML to do MDSD. In essence, SysML is optimized to address the very concerns of MDSD, as noted before. In particular, the use of SysML makes reasoning about parametrics much more effective than trying to do the same in UML. Likewise, traceability between requirements and design elements can be done in SysML, whereas there are no explicit semantics in UML for handling the relationship between requirements and design elements. Finally, the concept of a block transcends the software domain and is intended to express multiple kinds of system elements—while classes can be used to express many of the semantics expressed by blocks, they have a software flavor to them which seems to be antithetical to systems engineers. Furthermore, classes cannot express the kinds of semantics that blocks can, especially in the area of parametrics.
2S. Friedenthal, A. Moore, and R. Steiner, OMG SysML Tutorial, pg. 8, http://www.omgsysml.org/INCOSE-2007-OMG-SysML-Tutorial.pdf
