SysML FAQ

Home
FAQ
Specifications
Tools
Training
Publications
Mailing List
News
Other Resources
Visual Modeling Forum
BPMN Forum
UML Forum

Next
  • What is the SysML?
    The SysML (Systems Modeling Language) is a general-purpose modeling language for systems engineering applications that is defined as a dialect (Profile) of UML 2. It supports the specification, analysis, design, verification and validation of a broad range of systems and systems-of-systems. These systems may include hardware, software, information, processes, personnel, and facilities.

    SysML was originally developed as an open source specification project initiated in 2003. The SysML specification is publicly available for download, and includes an open source license for distribution and use.
    BACK TO TOP
  • Why do systems engineers need yet-another-modeling-language?
     Many systems engineering processes tend to be document-intensive (a.k.a. document centric) and employ a motley mix of diagram techniques that are frequently imprecise and inconsistent. In a manner similar to how software engineers sought a general-purpose modeling language (UML) to precisely specify software-intensive systems during the last decade, systems engineers are now seeking a domain-specific modeling language to specify complex systems that include non-software components (e.g., hardware, information, processes, personnel, and facilities). UML cannot satisfy this need because of its software bias; hence the motivation for SysML. Even though SysML is based on UML, it reduces UML's size and software bias while extending its semantics to model requirements and parametric constraints. These latter capabilities are essential to support requirements engineering and performance analysis, two essential systems engineering activities.
    BACK TO TOP
  • What is the relationship between open source SysML and OMG SysML™?
    SysML was originally developed as an open source specification by the SysML Partners, an informal association of tool vendors and industry leaders. The SysML Partners submitted the SysML 1.0a open source specification to the Object Management Group (OMG) in November 2005. OMG SysML™ is derived from open source SysML and is trademarked and maintained by the OMG.
    BACK TO TOP
  • What is the current version of SysML, and how can I obtain a copy?
    The latest version of the OMG SysML specification is OMG SysML 1.1, which can be downloaded from the Specifications page of this web.
    BACK TO TOP
  • What changes were made during the last revision of OMG SysML?
    Unfortunately, OMG SysML 1.1 includes change bars, but no change summary. Note that the lack of a clear change summary (cf. change bars) appears to violate the SysML Merge Team submission's (OMG doc# ad/2006-03-01) License conditions that "All modified versions of this specification must include a prominent notice stating how and when the specification was modified." A review of the change bar sections of OMG SysML 1.1 indicates various minor editorial corrections, but no substantive technical changes.

    Such a conservative approach to minor revision control might make sense for a mature modeling language with no major design flaws or usage problems. Unfortunately, several serious design flaws and usage problems have been identified during the last several years that SysML tool implementations have been available. (Open source SysML tool implementations have been available since 2005; OMG SysML tool implementations have been available since 2006.). These problems are summarized below in response to the Question: How mature is OMG SysML 1.x and what is the roadmap for OMG SysML 2.0? Given the gravity of these issues and the glacial speed of the OMG major revision process, hopefully some of these issues will be addressed in a future minor revision.
    BACK TO TOP
  • How mature is OMG SysML 1.x and what is the roadmap for OMG SysML 2.0?
    Although OMG SysML reuses many of UML 2.x's diagrams and constructs, this new dialect (Profile) is much less mature than its linguistic parent because it suffers from the following issues:
    • Exacerbation of UML 2.x language bloat. A common and fair criticism  of UML 2.x is that it is gratuitously large and complex. While SysML marketecture indicates that SysML is a "smaller, kinder" language for systems engineers, the reality is that SysML itself suffers from bloat because it  adds two new diagrams (Requirements and Parametrics), increases the number of stereotypes with imprecise semantics (see below), and fails to explicitly exclude many redundant and software-centric UML 2 constructs from the seven UML 2 diagrams that it inherits. Stated otherwise, if you added up all the metaclasses and stereotypes for both languages it is not clear which one is more bloated!
    • Exacerbation of UML 2.x's voodoo semantics. Another common and fair criticism of UML 2.x is that its semantics are imprecise, including its executable semantics (a.k.a. the Action Semantics). While SysML marketecture indicates that SysML supports precise semantics for specifying parametric constraints, the reality is SysML only defines vague natural language semantics for the stereotypes involved (ConstraintBlocks and ConstraintProperty).  Similarly, the semantics for Activity diagram extensions related to continuous/discrete rates and probabilities lack formal precision.
    • Gozinta-gozouta constructs are complex and muddled. The semantics and notation for StandardPorts, FlowPorts, Provided/Required Interfaces, and ItemFlows are excessively complex and their usages are frequently counter-intuitive.
    • Requirement constructs are incomplete and confusing. Problems associated with Requirement diagrams include, but are not limited to, clarifying decomposition/containment semantics, categorization, defining basic properties, clarifying relationship semantics, and reducing the semantic overlap with Use Cases.
    • Allocation relationships and tables are incomplete and ambiguous. With the exception of the AllocateActivityPartition sterotype the current specification fails to leverage the architectural integrity allocations of its parent language. In addition, the definitions of the Allocate and Allocated stereotypes strongly suggest conflated dependency and flow semantics, which are indicative of novice UML modelers ("which way does the arrow point?").
    • ValueType-Type integration needs simplification. The current usage of ValueTypes with Units and Dimensions and their integration with UML Types needs to be clarified and simplified.

    Re the roadmap for OMG SysML 2.0: The "OMG SysML Roadmap" section of the OMG SysML 1.1 specification (pp. xiv-xv) stops with the OMG SysML 1.1 entry. Hopefully, the OMG is planning further ahead than this and is considering an OMG SysML major revision that will address some of the issues described above. Keep in mind that you can communicate your own OMG SysML issues to the OMG by sending email to mailto:issues@omg.org.
    BACK TO TOP

  • Who are the SysML Partners?
    The SysML Partners is the informal association of tool vendors and industry leaders who originally developed the SysML open source specification. Cris Kobryn and Sandy Friedenthal organized and co-chaired the SysML Partners in 2003 to define a dialect of UML for systems engineering that would satisfy the requirements of the OMG's "UML for Systems Engineering" RFP. The SysML specification is the result of this project. You can find out more about the SysML Partners here.
    BACK TO TOP
  • What is the relationship between UML and SysML?
    UML is a general-purpose modeling language for software engineering applications, whereas SysML is a dialect (Profile) of UML 2.x, the industry standard modeling language for software-intensive applications. The advantage of defining SysML as a UML Profile is that it can reuse the relatively mature notation and semantics of UML 2.x, which many modeling tool vendors have already implemented. The disadvantage of specifying SysML as a UML Profile is that SysML inherits many of the problems associated with UML 2.x, such as gratuitously complex notation, imprecise semantics, and a dysfunctional diagram interoperability standard (XMI).

    SysML offers systems engineers the following advantages over UML for specifying systems and systems-of-systems:

    • SysML expresses systems engineering semantics (interpretations of notations) better than than UML. It reduces UML's software bias and adds two new diagram types for requirements management and performance analysis: Requirement diagrams and Parametric diagrams, respectively.
    • SysML is smaller and easier to learn than UML. Since SysML removes many software-centric and gratuitous constructs, the overall language is smaller as measured in diagram types (9 vs. 13) and total constructs.
    • SysML allocation tables support various kinds of allocations (e.g., requirement allocation, functional allocation, structural allocation) thereby facilitating automated verification and validation (V&V) and gap analysis.
    • SysML model management constructs support the specification of models, views, and viewpoints and are architecturally aligned with IEEE-Std-1471-2000 (IEEE Recommended Practice for Architectural Description of Software-Intensive Systems).

    The following table compares SysML diagrams with their UML counterparts where one exists. Where no UML diagram counterpart exists for a SysML diagram (e.g., Parametric and Requirement diagrams), it is marked N/A; similarly, where no SysML diagram counterpart exists for UML diagram it is marked N/A (e.g., Communication diagram).

    SysML Diagram Purpose UML Diagram Analog
    Activity diagram Show system behavior as control and data flows. Useful for functional analysis. Compare Extended Functional Flow Block diagrams (EFFBDs), already commonly used among systems engineers.  Activity diagram
    Block Definition diagram Show system structure as components along with their properties, operations and relationships. Useful for system analysis and design. Class diagram
    Internal Block diagram Show the internal structures of components, including their parts and connectors. Useful for system analysis and design. Composite Structure diagram
    Package diagram Show how a model is organized into packages, views and viewpoints. Useful for model management. Package diagram
    Parametric diagram Show parametric constraints between structural elements. Useful for performance and quantitative analysis. N/A
    Requirement diagram Show system requirements and their relationships with other elements. Useful for requirements engineering. N/A
    Sequence diagram Show system behavior as interactions between system components. Useful for system analysis and design. Sequence diagram
    State Machine diagram Show system behavior as sequences of states that a component or interaction experience in response to events. Useful for system design and simulation/code generation. State Machine diagram
    Use Case diagram Show system functional requirements as transactions that are meaningful to system users. Useful for specifying functional requirements. (Note potential overlap with Requirement diagrams.) Use Case diagram
    Allocation tables*

     

    *dynamically derived tables, not really a diagram type

    		 Show various kinds of allocations (e.g., requirement allocation, functional allocation, structural allocation). Useful for  facilitating automated verification and validation (V&V) and gap analysis. N/A
    N/A   Component diagram
    N/A   Communication diagram
    N/A   Deployment diagram
    N/A   Interaction overview diagram
    N/A

    *the inability to define Block instances in SysML is frequently cited as a serious design flaw of SysML

    		   Object diagram
    N/A   Timing diagram

    BACK TO TOP

  • Can SysML and UML be used together in the same project?
    Yes, this was the SysML language designers' intent. However, many important details about how UML-SysML joint usage will work efficiently in practice have not yet been worked out. The problem is not mixed UML-SysML tool support, since the first SysML tool vendors are UML tool vendors who are implementing SysML as a UML profile. In this answer we  assume that most UML-SysML 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, where the former choose to model in SysML and the latter select to model in UML. These 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 makes 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 ambigous semantics (e.g., SysML Item Flows) and diverging from UML's Class-Part-Instance trichotomy (SysML has no Object diagrams).

    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 into UML's object-component paradigm.

    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 problems for which the SysML «allocate» dependency or the UML «refine»/«trace» dependencies are only stopgap solutions. Hopefully vendors and methodologists will work out these problems soon, after they gain more experience with real projects.
    BACK TO TOP
  • Can SysML be customized by vendors or users?
    Yes, SysML can be customized by both vendors and users with the Profile mechanism it borrows from its UML parent. It is anticipated that SysML will be customized to model more domain-specific applications, such as automotive, aerospace, communications and information systems.
    BACK TO TOP
  • Which language is easier to learn, SysML or UML?
    The answer likely depends on whether you are a systems engineer or a software engineer. If you are a systems engineer, you should expect SysML to be easier to learn, since it is smaller language and it is customized for your systems engineering applications. If you are a software engineer, you will likely prefer UML's software-centric bias.
    BACK TO TOP
  • Will there be other variations or dialects of the SysML?
    Since the SysML has been developed by an open source project, and includes an open source license for its distribution and use, others can freely modify, use and redistribute the SysML specification as long as they follow the conditions in the license. For example, the OMG adopted a variation of the SysML open source specification that they trademarked as "OMG SysML." Others may do the same as long as they follow the open source license for distribution and use.
    BACK TO TOP
  • What SysML 1.x modeling tools are available?
    Y    ou can find a selected list of SysML tools that are available on the Modeling Tools page of this web.
    BACK TO TOP
  • When will SysML 1.x tools be interoperable?
    Since most SysML tools are being implemented as UML 2.x Profiles, they are dependent upon the UML 2.x XMI (XML Metadata Interchange) format for interoperability. Unfortunately, UML 2.x tool interoperability via XMI does not work well, especially regarding diagram interchange.
    BACK TO TOP
  • Can SysML users submit new questions for this FAQ?
    Yes, please send email with your questions to FAQ@SysMLforum.com.
    BACK TO TOP

 

© 2003-2009 PivotPoint Technology Corp. | Home | Search | Sitemap | Contact