Naked SysML! Please, Put Some Methodology On!

In theory, you can model everything in plain SysML. But in practice? Working with “naked” SysML, that is, using only the standard without any methodological or domain-specific extensions, can quickly become limiting.

Let’s take a concrete example: the System Context.

SysML (both v1 and v2) does not include the concept of a system context as a built-in modeling element. But in systems engineering practice, the system context is fundamental. It defines the boundary between the system of interest and its environment, including all relevant external entities that interact with the system. Without explicitly modeling this, we risk missing critical interfaces and assumptions early in the development process.

Now here’s the problem:

You can create a system context in naked SysML using parts and connections (or blocks in SysML v1), and display it in a view (or diagram in SysML v1). But how can a tool understand that this particular part represents the system context? The model is probably full of part elements. A script or API client can iterate over hundreds of model elements but without semantic markers, it can’t answer the simple question:

“What is the system context of this system?”

If you follow the club’s live sessions or learning units on developing a Python server for the SysML v2 API, you have already encountered this problem.

Methodologies to the Rescue

This is where MBSE methodologies like SYSMOD come in. SYSMOD defines modeling concepts missing from naked SysML, such as system context, and provides language extensions to encode them.

Here’s how a system context is defined with the SYSMOD language extension (skipping the system of interest and actors to keep it simple):

#systemContext part def MySystemContext;

This declaration does more than just label the element for human readers. It tells tools:

• This is a system context definition.
• It includes the system of interest and relevant actors.
• It has a semantic meaning that can be interpreted programmatically.

The syntax “#systemContext” is a user-defined keyword in SysML v2, which integrates the concept of “SystemContext” modeled in SysML.

part def SystemContext {
    doc
    /* The SYSMOD System Context includes all system actors, the system of interest, 
     * the relationships between the actors and the system, as well as the use cases.
     */
    part actors [1..*];
    part <soi> systemOfInterest;
    connection act2sys [1..*] {
        end [1] part 'actor' ::> actors;
        end [1] part soi ::> soi;
    }
    use case useCases [0..*] {
        subject theSubject :> soi;
    }
}

By incorporating this information into the modeling language, we move from merely drawing models to engineering systems that enable automation, validation, and integration across the toolchain.

Why Language Extensions Matter

Language extensions are not just convenience features. They:

• Make models understandable to machines, not just humans.
• Enable automated analysis and validation based on semantics.
• Improve consistency and reusability across projects and teams.
• Bridge the gap between method and model, ensuring that best practices are embedded directly into the model structure.

Without these extensions, we rely on naming conventions or documentation, which are approaches that are fragile and prone to misinterpretation.

Conclusion

“Naked SysML” may look clean, but it often lacks the practical expressiveness needed in real-world MBSE projects. Adding a methodology like SYSMOD doesn’t just enhance clarity it enables models to be more useful, more robust, and more intelligent.

This blog post is based on the blog post by MBSE4U: https://mbse4u.com/2026/01/18/naked-sysml-please-put-some-methodology-on/.