A Paper Presentation from ARTiSAN Software Tools

On April 3 2006, the SysMLTM Merge Team (SMT), chaired by Sanford Friedenthal of Lockheed Martin Corp, submitted draft SysMLv1.0 to the OMG (Object Management Group) for adoption. The SysML specification was in response to the joint Request for Proposal issued by the OMG and INCOSE (the International Council on Systems Engineering) for a customized version of UML 2 designed to address the specific needs of system engineers. The SysML specification was developed by a broad-based team including tool vendors, leading industry users, government agencies and professional organizations over a period of 3 years. The draft specification has gone through an extensive review process by both INCOSE and the OMG. OMG SysMLTM is a visual modeling language that extends UML 2 in order to support the specification, analysis, design, verification and validation of complex systems that include components for hardware, software, data, personnel, procedures, and facilities. SysML is intended to be used with different methodologies including structured analysis, object orientation, and others. SysML reuses a subset of UML 2 concepts and diagrams and augments them with some new diagrams and constructs appropriate for systems modeling. This paper will look at the background of OMG SysMLTM, and will summarizes the SysML specification including, the modifications to UML 2.0 that are being proposed, along with the new requirement and parametric diagrams. INTRODUCTION The Unified Modeling language (UML) has, since its adoption in 1997, proved immensely popular with software engineers to the point where it is now the only widely used visual modeling language for software engineering. In the past, UML’s software focus has discouraged many system engineers from adopting it in earnest. There were various approaches used to address the shortcomings of UML for Systems Engineers. Some made use of the stereotypes provided in UML to create “libraries” or profiles of entities in their application domain. By applying these, they were able to express non-software concepts (Hause, 2003). Others used tools such as Visio to model their Systems Engineering concepts, in conjunction with their UML model. However, with this approach they were left with two separate models that they were unable to integrate or cross-reference. Some simply ignored the problem or used words to fill the gap. Some tool manufacturers such as Artisan Software Tools extended UML, allowing integration of Hardware, Software, and Systems Engineering concepts in a single model (Hause 2001). This left them open to a charge of being “nonstandard”. However, as most Systems Engineers are pragmatists, this argument was not usually effective. In fact, most of the concepts outlined in Hause (2001) have in fact been integrated into UML 2.0 and OMG SysMLTM. Lykins (2000) provides an early paper on trying to adapt UML to SE and some of the issues. Shortcomings of UML Those who know UML, find it to be an effective modeling language. The roots of UML are firmly in software. OMG (1997) states that the “Unified Modeling Language (UML) is a general-purpose visual modeling language that is designed to specify, visualize, construct and document the artifacts of a software system” (italics mine). (In the UML 2.0 version of the specification, software system has been replaced by system [OMG, 2003a]. This reflects the increased use of UML by systems engineers and users from other domains.) However, many Systems Engineers believed the UML to be sufficiently flexible and robust to support extensions to address the needs of systems engineering. One of the strengths of UML is its built-in mechanisms for specializing the generic forms of its modeling elements to more application-specific variants. Collectively, these provide a capability for UML “Profiles” that package specific terminology and substructures for a particular application domain. Exploiting this achieves a “standard modeling language for Systems Engineering to analyze, specify, design, and verify complex systems, intended to enhance system quality, improve the ability to exchange Systems Engineering information amongst tools, and help bridge the semantic gap between systems, software, and other engineering disciplines” (SysML, 2003). However, the modifications to UML needed for Systems Engineers require more than just the addition of stereotypes. Problems with UML 1.x The starting point for many Systems Engineers is the System Context Diagram, which includes a depiction of the input/output flow between the system and/or components, interfaces, and the elements in its environment. The only UML 1.x diagram capable of modeling physical nodes is the Deployment