SysML-Sandbox-SysideViews

Syside tables and diagrams for the SysML v2 teaching model hugoormo/sysmlv2-sandbox.

The sandbox carries native SysML v2 views only, so that it works with any tool. This companion package adds, for each of the sandbox's views that Syside can render, a Syside view that shows the same elements as a table or a diagram. It holds only views: the model, your task, and the modeling conventions are in the sandbox's own guide, which sysand add installs with the sandbox (.sysand/lib/hugoormo-sysmlv2-sandbox_<version>/README.md). Read that guide first. This one extends its step 1 and adds what you need for the views.

What the companion adds

Every developed element of the sandbox has a context <Element>_ViewpointsAndViews::<Element>GenericViews with the Framework's purpose views. The companion adds a context <Element>_SysideViews::<Element>SysideViews that specializes it and gives seven of those views a Syside view:

The other purpose views (traceability, compliance, interface control and the matrices) have no Syside view yet: their columns and cells follow relationships that Syside's views cannot navigate yet. syside viz still draws the elements each native view selects, with each requirement's subsets naming the requirement it traces to.

1. Set up your project

You need sysand and the Syside CLI. Add the sandbox, as its guide shows, and the companion next to it:

mkdir transport-ship && cd transport-ship
sysand init --publisher <your-name> --name transport-ship
sysand add hugoormo/sysmlv2-sandbox "^2.0.0"
sysand add hugoormo/sysmlv2-sandbox-syside-views "^0.1.0"

Add both: your files use the sandbox's packages (MyFramework, MySystemOntology, the levels) and the companion's (SysideFrameworkViews, the _SysideViews contexts), and Syside resolves a name only in the packages your project adds itself, not in those a dependency brings along. The companion brings sensmetry/syside-views, the Syside library its views build on, which your files do not use directly.

The constraint ^0.1.0 accepts 0.1.x releases only, and the companion requires the sandbox's 2.x baseline, as ^2.0.0 does: sysand-lock.toml records the exact versions.

sensmetry/syside-views may be used only when obtained through Sysand, and may not be redistributed: never commit .sysand/. Whoever clones your project runs sysand sync, which restores it from sysand-lock.toml.

2. Render the sandbox's views

Run the Syside CLI in your project directory. A table is exported as CSV, a diagram as SVG (or PNG):

syside grid export -n MiningFrigate_SysideViews::MiningFrigateSysideViews::requirementsDefinition -o output
syside viz view -n MiningFrigate_SysideViews::MiningFrigateSysideViews::decompositionTree -f svg -o output

Each view's qualified name is <Element>_SysideViews::<Element>SysideViews::<view>, with the view names of the table above. Without -n, grid export exports every table and viz view draws every view of the model.

3. Add views for your own elements

The sandbox gives every developed element its views, and your elements need theirs too. Each element you develop gets two view files:

• <Element>_StakeholdersViews.sysml with the native views, <Element>_ViewpointsAndViews::<Element>GenericViews, as the sandbox's conventions describe (see the mining frigate's MiningFrigate_StakeholdersViews.sysml);
• <Element>_SysideViews.sysml with its Syside views, <Element>_SysideViews::<Element>SysideViews.

Add a view to both when the content it shows exists: the box views and the decomposition tree with the element's context, the requirements definition with its requirements, the verification planning with its verification context, and the interconnection with its graybox connections.

For the transport ship, right after step 3 of the sandbox's guide (its context with a blackbox), that is the blackbox contract and the decomposition tree. Level 1 - Systems/TransportShip/TransportShip_StakeholdersViews.sysml:

package TransportShip_ViewpointsAndViews {
    doc
    /* Viewpoints and views for the transport ship at L1. */

    part def TransportShipGenericViews {
        doc
        /* Context owning the generic views of the transport ship, the Framework
         * purpose views applied to this level.
         */
        view blackBox defined by MyFramework::MyFrameworkViews::BlackBoxContractView {
            doc
            /* The blackbox contract of the transport ship. */
            expose TransportShip_Configuration::TransportShipContext::*;
        }
        view decompositionTree defined by MyFramework::MyFrameworkViews::DecompositionTreeView {
            doc
            /* The element contexts below the transport ship. */
            expose TransportShip_Configuration::TransportShipContext::**;
        }
    }
}

Level 1 - Systems/TransportShip/TransportShip_SysideViews.sysml:

package TransportShip_SysideViews {
    doc
    /* Syside tool views of the transport ship at L1. */

    part def TransportShipSysideViews
        specializes TransportShip_ViewpointsAndViews::TransportShipGenericViews {
        doc
        /* Context retyping the transport ship's generic views with Syside tool
         * views.
         */
        view blackBox redefines blackBox
            defined by SysideFrameworkViews::BlackBoxContractTable {
            expose TransportShip_ViewpointsAndViews::TransportShipGenericViews::blackBox::*;
        }
        view decompositionTree redefines decompositionTree
            defined by SysideFrameworkViews::DecompositionTreeDiagram {
            expose TransportShip_Configuration::TransportShipContext::**;
            render Views::asTreeDiagram;
        }
    }
}

The decomposition tree draws nothing until the transport ship's context mounts the contexts of its constituents.

Three rules make a Syside view show what the native view selects:

• Redefine the native view under its own name (view blackBox redefines blackBox), so the view keeps its native meaning and the Framework's filter.
• A table exposes the native view, not the model: expose <Element>_ViewpointsAndViews::<Element>GenericViews::<view>::*;, with ::** for requirementsDefinition and verificationPlanning and ::* for the box tables. The scope stays written once, in the native view.
• A diagram repeats the native view's expose (Syside's diagrams do not follow an expose of another view), and the decomposition tree also states render Views::asTreeDiagram;, without which Syside draws it as nested boxes.

Then include the two files and check, as the sandbox's guide shows:

sysand include "Level 1 - Systems/TransportShip/TransportShip_StakeholdersViews.sysml"
sysand include "Level 1 - Systems/TransportShip/TransportShip_SysideViews.sysml"
sysand sources | tr '\n' '\0' | xargs -0 syside check
syside grid export -n TransportShip_SysideViews::TransportShipSysideViews::blackBox -o output

A clean syside check does not prove that a view shows the right elements: render it and compare it with what the native view should select.

Known limits

These follow from what Syside 1.0.1 and sensmetry/syside-views 1.0.0 can do:

• The box tables show a box's owned and inherited usages together in one cell, without telling them apart.
• The requirements definition table has no framed concerns column, and the verification planning table no case subject and verified requirement columns.
• syside viz prints an "unsupported render style" warning for every view whose rendering it does not know, the tables included, and draws those views as nested boxes. The warnings are harmless; the decomposition tree states its rendering so that it is drawn as a tree.
• With the sandbox installed as a sysand dependency, syside viz draws none of the flows the interface control views select. To see an interface control diagram, copy the installed sandbox out of .sysand/lib into a visible folder and render the view there.

License

The companion is licensed under the MIT License (see LICENSES/MIT.txt). The sandbox has its own licence (see its guide), and sensmetry/syside-views the Sensmetry library licence, which allows its use only when obtained through Sysand.