Mechanism to structure Model and SysML Files

SysML v2 Questions / Help
1

Hello,

What’s the best/suggested approach to structure a model? I’m attempting to structure the model with packages according to the logical architecture of the system. Simultaneously I’m attempting to have every package in a separate .sysml file (for easier collaboration and version control).

How can I achieve this with nested packages? My first thought was the following, but I am not sure:

A.sysml:
package A {
public import B;
}

B.sysml:
package B {
part def PartB;
}

C.sysml:
package C {
part def PartC {
part partB : A::B::PartB;
}
}

Thanks!

Tom

2

Hi Tom,

There are many good approaches how to model structure (as well as behavior and other things for that matter), and the best approach really depends on your situation. We do however recommend splitting model up into standalone files for different subsystems/components to enable modularity, reusability of design assets and for more effective version control and team collaboration (easier to see which design aspects are modified once they are in separate files.

Here is a few rule of thumbs that could help you with modeling large structure in SysML

  1. Keep the sysml file name consistent with the top level package name.
  2. Have only 1 top (root-level) package per file, you can have further nested packages inside.
  3. Have only definitions (i.e. context / blueprints for what you modelling) inside packages. Avoid having usages at package level, because semantics are very different for package level usages.
  4. Each definition should ideally have 1 level depth usages which are defined by other definitions (which could be imported from other packages).
  5. Definitions should not have any other owned definitions (semantically it does not matter where definition is, only usages inside definition have semantic feature membership meaning)

Having this in mind, my recommendation would be have 1 sysml file for top level system, then separate files for subsystems, and separate (or combined file/package if they are small) for components. Then folder and file structure can look something like this:

Folder/file structure:

image
image531×367 33.6 KB

ExampleTopLevel.sysml

package ExampleTopLevel {
    private import ExampleSubsystemA::*;
    private import ExampleSubsystemB::*;

    part def ExampleSystemDesign {
        part subsystemA : SubsystemA;
        part subsystemB : SubsystemB;
    }
}

ExampleSubsystemA.sysml (note, you do not necessarily need to import other packages, you can use full qualified name ExampleComponentB::ComponentB)

package ExampleSubsystemA {
    private import ExampleComponentA::*;
    
    part def SubsystemA {
        part componentA : ComponentA;
        part componentB : ExampleComponentB::ComponentB;
    }
}

ExampleSubsystemB.sysml

package ExampleSubsystemB {

    private import ExampleComponentC::*;
    private import ExampleComponentD::*;

    part def SubsystemB {
        part componentC : ComponentC;
        part componentD : ComponentD;
    }
}

And components (all the same A/B/C/D in this example):

package ExampleComponentA {
    part def ComponentA {
    }
}

Note, I used the folder structure here to group designs by their hierarchy level. That may not be optimal for larger teams/designs, as you may want to use those groups for each individual subsystem, and perhaps even have multiple levels of internal subsystems with variable depth for each. In that case the better approach to have folders ExampleSubsytemA, ExampleSubsystemB, etc.. Then the component design files could be stored under relevant subsystem folders, or somewhere else altogether. As I mentioned at the start, it all depends on your preferences and situation.

Hope this helps, let us know if you have other questions on this or related topics.

Kind regards
Kestutis Jankevicius

3

This is something I use as a pattern:

image
image614×1192 112 KB