SysML Concept Reference
Browse reference
On this page

Research and methods

Shared rules for the parts-and-ports slice

Research date: 2026-10-21. This note separates model meaning from graphical rendering choices. It supports the parts-and-ports guide and notation audit; it is not a parser, model execution result, or a claim of complete SysML graphical coverage.

Source and review method

The source is OMG SysML 2.0 Part 1, formal/2026-03-02, original PDF, pinned in data/source-manifest.json and data/notation-source-index.json. SHA-256: 46e6c0476a6f1f34f367d57e039d56659bff75e41d2e4b3d37ca4cadea84a83a. The current PDF has 691 pages. Below, printed means the number printed on the specification page; PDF means the one-based viewer page used in #page= links. In this edition PDF page = printed page + 32. Existing notation-reviews.json evidence_pages use PDF pages; their overview 225/226 and name-production 231/233 references agree with this edition.

Review used the pinned PDF's extracted text and inspected rendered pages for Table 4 (PDF 66–68), common relationship grammar (PDF 232), port geometry and restrictions (PDF 243–246), and the proxy label definition (PDF 239). The research also read docs/research/property-rules.md, the connected example, concept profiles, source index, and notation reviews. Rendered copies remain ignored under sandbox/shared-rules-pages/.

Source evidence 1 location

Meaning, names, and ownership

Rule Consequence for the guide or renderer Original evidence
A definition classifies a kind; a usage applies a definition in a context. A usage can inherit features from its definition. Explain Wheel and wheel : Wheel separately. Do not describe a usage declaration as a concrete runtime object or execution result. §7.6.1, printed 31–32 / PDF 63–64.
Declaring an element in a namespace body generally creates an owning membership; an alias is a non-owning membership and can give the same element a different name relative to a namespace. An alias is another name for an element, not a second owned declaration or a second modeled part value. §7.5.2, printed 27 / PDF 59.
Usages declared inside a definition body are owned usages specifying its features. Usages declared inside a usage body are owned nested usages specifying features of the owning usage. Distinguish the declaration's ownership from whether its values are composite. §7.6.2–3, printed 40 and 42 / PDF 72, PDF 74.
ref makes a usage referential. Composite values are subject to lifetime and sharing restrictions relative to their featuring instance. Directed usages are referential even without explicit ref. ref part spare remains a part usage and remains an owned declaration of its context. Its values do not receive the composite-lifetime rule from that usage. §7.6.3, printed 42 / PDF 74.
ReferenceUsage is the kind declared without a kind keyword and is always referential. Do not equate every referential PartUsage with metaclass ReferenceUsage. §7.6.4, printed 42 / PDF 74.
Feature typing (:), subsetting (:>), and redefinition (:>>) are distinct relationships; redefinition is a kind of subsetting. Do not treat every colon-like annotation as ownership or inheritance. §7.6.3, printed 40 / PDF 72.
Missing usage multiplicity inherits existing constraints; otherwise the broad default is [0..*]. A tighter [1..1] applies only to the listed usage kinds, owned by a definition or usage, without explicit owned subsetting or redefinition. Connections are excluded from the item/part branch of that tighter default. Explain example defaults per declaration/context, independently of UML metamodel-property serialization defaults. §7.6.3, printed 41 / PDF 73; see also property normalization rules.
A feature chain records a path through usages; subsequent names resolve in the preceding usage's namespace using public memberships. It differs from a qualified name that identifies a namespace member. Explain axle.mount as a path through the axle feature to its inherited port, not merely as a package-qualified name. §7.6.6, printed 43 / PDF 75.
Source evidence 6 locations
  • SysML 2.0 LanguagePDF 63–64formal/2026-03-02
  • SysML 2.0 LanguagePDF 59formal/2026-03-02
  • SysML 2.0 LanguagePDF 72formal/2026-03-02
  • SysML 2.0 LanguagePDF 74formal/2026-03-02
  • SysML 2.0 LanguagePDF 73formal/2026-03-02
  • SysML 2.0 LanguagePDF 75formal/2026-03-02

Name compartments and marker dependencies

The common graphical productions reuse textual declarations; labels are not an independent miniature language. Each row below is a separate dependency or presentation alternative, not a new metaclass.

Graphical rule Meaning and implementation boundary Original evidence
definition-name-with-alias reuses DefinitionDeclaration and optionally appends an «alias» label with qualified names. usage-name-with-alias similarly reuses UsageDeclaration, with an optional leading ^. Preserve declared names, short names, typing/specialization declarations, and optional aliases as separate information. A reusable SVG accepting only one plain label supports a subset, not this entire production. §8.2.3.6, printed 199 / PDF 231; textual declarations §8.2.2.6.1–2, printed 169–171 / PDF 201.
Table 4 explicitly shows short-name, qualified-name, abstract, variation, variant, inherited, subsetted, and redefined examples. Its inherited usage example carries ^. ^ can be explained as the inherited-usage indication demonstrated by Table 4. It is not a textual keyword for declaring inheritance. Abstract definition examples also show italic styling. §7.6.1 Table 4, printed 34–36 / PDF 66–68.
el-prefix is the alternative ^ or /, and some compartment-element productions make it optional. Record the two grammar terminals. This review did not locate a SysML prose rule explicitly assigning / a derived-feature meaning. Do not present that interpretation as newly verified evidence or infer the ability to combine both terminals from this alternative. §8.2.3.6, printed 201 / PDF 233; parts and ports compartment productions §8.2.3.11–12, printed 210–211 / PDF 242–243.
The textual usage prefix has a defined order: direction, derived, abstract/variation, constant, then optional reference; occurrence prefixes add individual/portion and extension dependencies. Definition prefixes allow abstract or variation, plus extensions. A label API should not promise arbitrary combinations of flags. derived is a model property whose values are typically expected to be determined by a bound expression, not evidence that this browser computes them. §7.6.3, printed 41–42 / PDF 73–74; §8.2.2.6.1–2, printed 168–169 / PDF 200–201; §8.2.2.9.2, printed 174 / PDF 206.
Source evidence 8 locations

Graphical containment and compartments

  • A graphical view renders nodes and edges; definition and usage nodes may have connection points. Each compartment is itself a view selecting members, rendered textually or graphically according to the grammar. This gives graphical containment and selection a different job from owning membership or composition of instance values. (§8.2.3.1, printed 193–194 / PDF 225–226.)
  • A part's interconnection compartment may render nested parts as nodes and connections as edges; a textual parts compartment can render the same kind of selected members as a list. Boundary symbols can represent ports and parameters. Consequently, a screenshot omitting a member is not proof that the member does not exist in the model. (§7.26.5, printed 154 / PDF 186.)
  • The grammar generally prescribes containment and connectivity; graphical elements may generally be relocated and stretched. Original reusable SVG coordinates are a layout choice, not normative pixel coordinates. (§8.2.3.1, printed 194 / PDF 226.)
  • Composite and noncomposite feature-membership lines are separate productions. The rendered composite form has a filled diamond at the type end; the noncomposite form continues onto the next page without that diamond. Do not use screen nesting alone to select a semantic membership relationship. (§8.2.3.6, printed 200–201 / PDF 232–233; Table 4's three feature-membership examples, printed 38 / PDF 70.)
Source evidence 5 locations

Ports, conjugation, and direction

Rule Consequence Original evidence
A port definition defines an interaction connection point; a port usage is a usage of a port definition. Features specify possible exchanges; nested ports are allowed. A port is an explicit concept, not any arbitrary rectangle positioned on a border. §7.12.1, printed 61 / PDF 93.
A port usage may only be defined by port definitions. The conditional default multiplicity is [1..1]. Features of a port definition or usage, other than nested port usages, must be referential. Keep feature-kind constraints separate from the visual compact/full-node alternative. §7.12.2, printed 63 / PDF 95.
Every ordinary port definition implicitly declares a nested conjugated definition. Conjugation exchanges in and out, retaining inout. port p : ~P is shorthand for typing by P::'~P'. ~ on a type is conjugated typing, not a direction arrow or a reversal of which diagram side the port occupies. §7.12.3, printed 63 / PDF 95.
Matching port features require conforming definitions and either no directions or conjugate directions. A port connection can enable flows between matching features; connection alone does not declare a particular transferred quantity. Do not label the Assembly connection as a fuel/data/material flow or claim compatibility checking from its drawing. §7.12.1, printed 61 / PDF 93.
Port definitions use a definition name compartment; full usages use the rounded usage-node form. Both provide boundary positions and compartment stacks. Horizontal pdh and vertical pdv arrow productions have bidirectional and either single-direction alternatives. Record full-node, compact-boundary, orientation and direction indications separately. An undirected glyph does not imply an inout declaration. §8.2.3.12, printed 210–213 / PDF 242–245; representative Table 10, printed 62 / PDF 94.
Dotted reference-port alternatives are restricted to nested ports. Proxy alternatives are valid only on a part usage contained in an interconnection view. These are scoped alternatives, not unrestricted border-style settings. §8.2.3.12 notes, printed 214 / PDF 246.

Resolved proxy-label dependency

proxy-label is defined earlier in the same specification, §8.2.3.9, printed 207 / PDF 239, as an optional literal dot followed by FeatureChainMember. The latter is imported from textual §8.2.2.17.5, printed 183 / PDF 215, where it is either membership referencing a qualified name or an owned feature-chain member. Thus the existing review's statement that this dependency remains unresolved can be retired after reconciliation. This does not by itself audit every possible feature-chain resolution or every context restriction.

Source inconsistency to retain

The §8.3.12.6 description says a PortUsage and all its nested usages must be referential (printed 295 / PDF 327). The same class includes checkPortUsageSubportSpecialization, explicitly conditional on a composite PortUsage owned by a PortDefinition or PortUsage (printed 295–296 / PDF 327–328). The next page also contains validatePortUsageIsReference, which requires referential status unless the owner is a PortDefinition or PortUsage, and validatePortUsageNestedUsagesNotComposite, which exempts nested PortUsages. Meanwhile §7.12.2 exempts nested port usages from the referential-only feature rule. This review does not resolve that tension. Preserve the exact scopes and avoid a blanket claim that every port is necessarily referential or necessarily composite.

Source evidence 8 locations
  • SysML 2.0 LanguagePDF 93formal/2026-03-02
  • SysML 2.0 LanguagePDF 95formal/2026-03-02
  • SysML 2.0 LanguagePDF 242–245formal/2026-03-02
  • SysML 2.0 LanguagePDF 94formal/2026-03-02
  • SysML 2.0 LanguagePDF 246formal/2026-03-02
  • SysML 2.0 LanguagePDF 239formal/2026-03-02
  • SysML 2.0 LanguagePDF 215formal/2026-03-02
  • SysML 2.0 LanguagePDF 327–328formal/2026-03-02

Review of AssemblyExample

The existing data/examples/assembly.sysml is an original documentation example marked source-reviewed and not parser-validated. Under the cited rules:

  • Mount, Wheel, Axle, and Assembly are definitions. hub, mount, wheel, axle, spare, link, and package-level assembly are usage declarations in their respective contexts. Wheel's hub and Axle's mount can be inherited through their usages. (§7.6.1–3, printed 31–32, 40–42 / PDF 63, PDF 72.)
  • wheel and axle are ordinary composite part features without explicit multiplicity and meet the conditional [1..1] rule. spare explicitly has [0..1] and is referential; it is still an owned part declaration. Package-level assembly does not meet the ownership condition for implicit [1..1]. (§7.6.3, printed 41–42 / PDF 73–74.)
  • axle.mount and wheel.hub are feature paths used as connection ends. The connection syntax is consistent with the binary-connection notation described in §7.13.2, printed 70–72 / PDF 102–104, together with feature-chain §7.6.6, printed 43 / PDF 75. No executed check is claimed.
  • Mount is empty. The example demonstrates structural declarations and port connection, without declared directed payload features. It does not demonstrate conjugation, transfer direction, physical mating geometry, interface compatibility validation, or runtime creation of exactly one assembly. Those would need distinct original examples and evidence. (§7.12.1–3, printed 61–63 / PDF 93–95.)
Source evidence 6 locations

Is a PortDefinition profile required?

A guide explanation and a reusable port-definition SVG need direct source citations, but they do not require pretending PortDefinition already has a full property profile. It is outside the current focused metamodel slice. Adding an effective-property profile would be a separate extraction/reconciliation expansion, including ancestors, constraints and conjugation dependencies.

The exact source for that future work is §8.3.12.5, printed 294–295 / PDF 326–327, and official XMI PortDefinition. Its general classes are Structure and OccurrenceDefinition. Its locally listed property is derived conjugatedPortDefinition : ConjugatedPortDefinition [0..1], subsetting ownedMember; the XMI property identity is Systems-Ports-PortDefinition-conjugatedPortDefinition. The class constraints require library specialization Ports::Port, derive the conjugated member, require exactly one conjugated member for a non-ConjugatedPortDefinition, and restrict non-port owned usages from being composite. The property's optional declared multiplicity must not be rewritten to [1..1] merely to encode that class-level conditional constraint.

Source evidence 3 locations

Explicit remaining dependencies

  • / graphical-prefix semantics: terminal occurrence verified; an explicit meaning rule was not located in this pass.
  • Full metadata keyword extension applicability: the graphical notes refer to metadata definitions specializing KerML SemanticMetadata; this remains a cross-language dependency beyond this slice (§8.2.3.6, printed 201 / PDF 233).
  • Complete textual expression/value and feature-chain semantics, all standard-view filters, and whole-language conformance remain outside this shared-rule review.
  • The PortUsage composite/referential description-versus-constraint tension above remains unresolved; no correction to normative prose is silently assumed.
Source evidence 1 location
  • SysML 2.0 LanguagePDF 233formal/2026-03-02

View this page’s source on GitHub