Packages and .sysml Files

SysML v2 Questions / Help
1

Hello!

I’m trying to break up the model into more granular .sysml files to have fewer lines of text per file (makes it easier to work on the model together with merge conflicts, etc.). Here’s an example of a way that is kind of working for me:

Animals.sysml

package Animals {
    public import Dogs;
    public import Cats;
}

Dogs.sysml

package Dogs {
    part def GermanShepherd;
    part def GoldenRetriever;
}

Cats.sysml

package Cats {
    part def PersianCat;
    part def BritishShorthair;
}

Usages.sysml

package Usages {

    part def Context {
        part persianCat : Animals::Cats::PersianCat;
        part anotherPersianCat : Cats::PersianCat;
    }

}

This works quite nicely, but I’m not too happy that I can refer to the PersianCat in two different ways. Is there a way where I can disallow the direct Cats::PersianCat reference (anotherPersianCat) and forcing the reference via the Animals package (persianCat)?

Thanks!

Tom

2

Hi Tom,

There’s no language mechanism for this – what you’re seeing is a side effect of the modeling style, and SysML v2 gives you no way to disallow the direct path.

The reason both paths work: every top-level element of every file lives in a single unnamed global namespace, and the name resolution rules treat all top-level elements as directly and globally visible (KerML spec 7.2.5.3, mirrored in SysML 7.5.5). There are no visibility modifiers for top-level elements – the only visibility rule at the root level goes in the opposite direction (file-level imports must be private, so a file can’t re-export things). And since a package body can’t be split across multiple files, you also can’t physically nest Cats inside Animals while keeping one file per package.

So the realistic options are conventions rather than enforcement:

  1. Flip which path is canonical: make the imports in Animals private (or drop the Animals wrapper entirely). Then Animals::Cats::PersianCat stops resolving from outside and Cats::PersianCat is the only path. You lose the grouping, but it’s the only way to actually get down to a single path.

  2. Keep Animals::Cats::PersianCat canonical by team convention and enforce it with tooling instead. Since the rule is purely about which textual path is used, even a CI text scan for references starting with Cats:: would catch most of it; for something more robust you can write a small Python validation script with Syside Automator and run it as a custom check in CI.