Structure of a SysML model
On the first view it seems to be simple to define the package structure of a SysML model. However you’ll often get problems with a implicit built structure. A model has many – orthogonal – aspects and abstraction layers that could be mapped into the package structure, e.g. domain, modeling, or organizational aspects. You can easily mix up the aspects.
The MBSE Challenge Team SE^2 for Telescope Modeling describes a best practice for the package structure in the MBSE Cookbook. The following figure shows the concept:
Structure of a SysML model
The root package represents the complete system model. On the next level we separate the different modeling aspects like system context, requirements, structure, and so on. The list in the figure is not complete. You’ll have your own appropriate list for your projects. The prefix of each package is the enclosing namespace. Typically you have many packages of the same name, e.g. Requirements, in the model. The prefix shows the context of the specific package.
The structure package contains the structural elements of the systems, i.e. the physical blocks. Each block that has a detailed description has it’s own package on the next level, e.g. the subsystem DetectionSystem. You treat the package like the system root package and create the same package structure inside. The DS_Requirements package in the figure below contains all requirements that directly relate to the subsystem DetectionSystem. Again there is a structure package that contains further packages with the same structure.
Structure of a SysML model with recursive sub-structure
The package structure is straightforward. It works for models of any size and gives the model builder and users a good orientation. The model of the MBSE Challenge Team SE^2 is a good example of the application of this concept (note: It takes a while before the model appears when you click on the link).
