Systems Tools: SysML

Systems Engineering is about specifying functionality, where that functionality resides in the system, and there what interfaces are required – is by definition a complex activity that involves an array of players and a multitude of considerations. As if the pressure of efficiently and accurately developing systems in the face of tight budgets isn’t enough, competitive considerations are forcing companies to develop increasingly sophisticated systems faster.

(Systems Engineering Best Practices White Paper, IBM/Rational Software, December 2009, by Hoffman, Sibbald, and Chard)

Where I work, systems engineers are also system architects. They, with the rest of the development team, make day to day decisions that evolve software architecture. I can’t speak for other professions, but the disciplines are deeply entwined in the world of software.

One tool that I’ve been looking at adopting is based on an extension to the Unified Modeling Language (UML) called SysML. SysML has views that deal with multiple aspects of the system – functional and behavioral, structural, performance, and slew of other models like cost and safety.

INCOSE http://www.uml-sysml.org/documentation/sysml-tutorial-incose-2.2mo (International Council on System Engineering) defines SysML as:

• A graphical modeling language in response to the UML for Systems Engineering RFP developed by the OMG, INCOSE, and AP233a UML Profile that represents a subset of UML 2 with extensions
• Supports the specification, analysis, design, verification, and validation of systems that include hardware, software, data, personnel, procedures, and facilities
• Supports model and data interchange via XML Metadata Interchange (XMI®) and the evolving AP233 standard (in-process)

The four key diagrams of SysML structure (similar to a class diagram in UML), requirements (new to SysML), behavior (uses standard UML behavior diagrams), and parametrics (which are used to express system constraints).

Requirements can be mapped to structure and behavior as parametrics can be. Moreover, models can be customized by extending SysML with mechanisms called stereotypes.

I plan to use SysML in the near future and report back buy my success with model driven development has been poor. I’m not sure if I and the teams I work with lack the discipline and technical expertise to generate such a complex model of a system or that it simply doesn’t work.

Have any of you in the blogosphere used SysML?