Hello and welcome back to the Advent of SysML v2 – a daily, hands-on mini-course designed to bring you up to speed with the new SysML v2 standard and the modern Syside tooling that makes you productive from day one.

By the end of this lesson, we’ll recap and synthesize everything we’ve learned in Week 2, showing how the concepts connect to transform isolated definitions into orchestrated systems.

Links to Second Week Lessons

1. Packages and Names
2. Package Manager for SysML v2
3. Comments and Annotations
4. Attributes and Quantities
5. Connections and Special Subsettings
6. Ports, Interfaces, Items and Flows

Organizing Models at Scale

Week 2 began with a crucial question: how do you organize and manage models as they grow beyond simple examples? The answer lies in several interconnected concepts that work together to create scalable, maintainable systems.

Packages and Names: The Foundation of Model Organization

At the heart of any large model is the ability to organize elements into packages and refer to them unambiguously. Packages serve dual purposes: they provide logical groupings of related elements (like folders) and create namespaces that prevent name collisions. Every element in SysML v2 can have multiple names:

• Declared names: The simple name you give an element
• Qualified names: Path-based references using :: to navigate package hierarchies
• Short names: Concise IDs between < > for abbreviations
• Unrestricted names: Between single quotes, allowing special characters
• Aliases: Alternative names created with the alias keyword

The key to effective model organization is understanding name resolution and imports. You can import elements from other namespaces using:

• private import Package::* – Import all names privately (default, recommended)
• public import Package::* – Import all names and re-export them
• private import Package::SpecificElement – Import a specific element (best for avoiding namespace pollution)

Best practice: use private imports by default, import specific names when possible, and keep packages in separate files with matching names.

Sysand: Package Management for the SysML v2 Ecosystem

Understanding packages naturally led to the question: how do teams share and reuse model libraries across projects? Enter Sysand, the first open-source package manager for SysML v2 and KerML.

Sysand brings proven software engineering practices to systems modeling:

• Dependency management: Declare dependencies explicitly, resolve them automatically
• Version control: Ensure teams use consistent versions of shared libraries
• Distribution: Publish and consume packages through central or private indexes

The workflow mirrors software package managers:

Key use cases demonstrate the value:

• Design reuse: Publish common architectures as versioned packages
• Compliance: Distribute organizational standards as official packages
• Supplier integration: Manage subsystem models with explicit dependencies
• Rapid prototyping: Import proven components instead of building from scratch

Sysand implements the package manager-based collaboration approach defined in KerML clause 10, filling a gap that existed in the standard until now. The vision extends to building a collaborative ecosystem at sysand.org, where teams can discover, share, and build upon each other’s work.

Documenting and Describing Models

With organizational structures in place, Week 2 turned to how we communicate intent and meaning within models.

Comments and Annotations: Capturing Human-Readable Information

SysML v2 provides three distinct ways to add information to models:

1. Notes (//): Simple comments that don’t get stored in the model. Useful for structuring textual models and adding code-level explanations.
2. Comments (/* */): Stored in the model and extractable via API. Can have names, locales, and be about specific elements using the about keyword.
3. Documentation comments (doc /* */): Special comments that document the element they’re nested in. Support locales (ISO/IEC 15897) for multi-language documentation.
4. Textual representations (language /* */): Store element representations in other languages (Python, Alf, OCL, or natural languages). Useful for requirements and executable actions.

Example showing locales:

Because documentation and comments are stored in the model, they can be extracted programmatically using Syside Automator. This enables checking translation coverage across locales, generating reports, and exporting to other tools like CSV, making model documentation part of your broader engineering workflow for quality assurance and project management.

Modeling Characteristics and Values

Understanding how to model the properties and characteristics of components was the next critical step.

Attributes and Quantities: Capturing Data and Physical Properties

Attributes represent data types and characteristics, fundamentally different from structural elements: instances are abstract concepts (numbers, enumerations) without identity; two identical attribute values ARE the same value; and attribute usages are always referential (nobody “owns” the number 5).

Attributes include:

• Attribute definitions (attribute def): Define custom data types
• Enumerations (enum def): Restrict values to specific choices
• Quantities: Standard attributes from the ISQ (International System of Quantities)

Quantities are particularly important for engineering. Key points:

• Use subsets to say an attribute is “a kind of” a quantity (safer, allows other kinds)
• Use redefines to say an attribute is “the” quantity of that type (prevents other kinds)
• Always specify units in square brackets: [kg], [cm], [m]
• Conversion between units is handled automatically by the language

Feature values specify usage values in four combinations:

• Initial vs. Bound: Initial (=) for variables, Bound (:=) for the entire lifetime
• Default vs. Non-default: Default can be overridden in specializations

Example:

Connecting Components: The Architecture of Relationships

The final major theme of Week 2 was understanding how to model relationships and interactions between components.

Connections: Linking Components Together

Connections are parts that connect other elements, implementing bidirectional relationships:

Key concepts:

• End features: Declared with end keyword, specify what’s being connected
• Cross subsetting (crosses): Specifies cross-navigation features for “hopping over” the connection
• Reference subsetting (references): In connection usages, specifies which specific features are connected

Cross multiplicities control connection semantics:

• Specify how many elements on one end must connect to elements on the other end
• Placed BEFORE the connected feature name
• Example: connect [1] sleigh to [9] reindeer means each sleigh connects to 9 reindeer, each reindeer connects to 1 sleigh

Important: Connection multiplicity itself is often not recommended because cross multiplicities force the number of links.

Ports, Interfaces, Items, and Flows: Refining Connections

Week 2 concluded with a powerful pattern for recursively refining connections at multiple levels:

Ports are dedicated interaction points with standard interfaces. Key points:

• Defined with port def and used with port keyword
• Can be conjugated (~) to “flip” input/output directions
• Ports themselves are NEVER directed (only their features are)

Items are entities that flow through the system. Key points:

• Similar to parts, but represent things that are exchanged
• Every part is also an item

Interfaces are special connections that connect ports. Key points:

• Defined with interface def, used with interface keyword
• Ends are always ports
• Contain flows specifying what travels between ports

Flows represent the transfer of outputs to inputs. Key points:

• Specified with flow of Type from source to target
• Defined between directed features of ports

The complete pattern:

This recursive blueprint allows you to model connections at the high level (part-to-part), then zoom into port-level interactions, and finally specify item-level flows—all automatically instantiated when you declare a connection.

Week 2 Shift: From Parts to Systems

Week 1 taught you what systems are – parts, features, specialization. Week 2 taught you how they work together.

You started with isolated definitions. Now you have interconnected architectures:

• Packages that organize and scale
• Documentation that travels with the model and can be extracted programmatically
• Quantities that ensure precision with automatic unit conversion
• Connections that automatically set up their internal structure

This is the fundamental shift: from describing parts to orchestrating systems. Each concept builds on the others. Good organization enables sharing, documentation enables collaboration, and precision feeds into connection definitions.

Challenge for Tomorrow

Practice Week 2’s concepts by extending your models:

1. Organization: Reorganize your existing models into packages across multiple files. Add comprehensive documentation with locales.
2. Sysand: If you’re comfortable with command-line tools, try creating a simple model interchange project using Sysand in Syside Cloud.
3. Attributes: Model the physical characteristics of your components using quantities, units, and appropriate feature values.
4. Connections: Apply the full recursive refinement pattern: create connections between parts, add ports with directed items, define interfaces with flows.

The goal is to integrate all of Week 2’s concepts into cohesive, well-organized models that are ready for real engineering work.

Summary

In Week 2, we’ve built upon Week 1’s foundation to create professional, scalable models:

• Organized models at scale with packages, names, and proper imports
• Managed dependencies with Sysand, the package manager for SysML v2
• Documented models with comments, annotations, and multi-language support
• Modeled characteristics using attributes, quantities, units, and feature values
• Connected components through connections, cross subsetting, and cross multiplicities
• Refined interactions with ports, interfaces, items, and flows
• Applied professional practices for organization, documentation, and dependency management

You now have the tools to create sophisticated, well-organized SysML v2 models that scale from simple examples to complex real-world systems. Week 3 will dive deeper into behavioral modeling, requirements, and advanced concepts. Until then, keep practicing and happy modeling!