From fdd7debfd92e1a4ec2732b4c461324a4b69e4ce5 Mon Sep 17 00:00:00 2001 From: samatstarion Date: Tue, 30 Jun 2026 17:21:23 +0200 Subject: [PATCH 1/5] [Update] document Hypha plugin grounding step in CLAUDE.md --- CLAUDE.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/CLAUDE.md b/CLAUDE.md index 832cf78e..766e50b3 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -91,6 +91,23 @@ The XMI files (`Resources/KerML_only_xmi.uml`, `Resources/SysML_only_xmi.uml`) d These text files are large (PDF-converted, up to 1.3 MB) and the conversion is not always clean. Read them with `Read` `offset`/`limit` and use `Grep` to jump to chapter/section anchors (e.g. `^7\.\d+`, `Clause 8\.`, or a metaclass name) rather than loading whole files into context. +### Grounding SysML v2 / KerML work with the Hypha plugin + +If the **Hypha** plugin is installed, treat it as the grounding step **before** implementing or reviewing anything that depends on the SysML v2 / KerML metamodel — do not rely on a sibling analogue, the doc-comment OCL, or prior knowledge as the source of truth. The metamodel is large and precise; a plausible prior is exactly what produces confident-but-wrong derivations. + +This applies whenever you are about to: +- implement or modify a `Compute*` derived-property / OCL computation under `SysML2.NET/Extend/`, +- reason about a metaclass's features, multiplicities, ordering, redefinitions/subsettings, or constraints, +- implement or review a textual-notation / lexical rule, or +- make a claim about what the SysML v2 / KerML specification requires. + +Use: +- **`hypha:metamodel-lookup`** — structure: a metaclass's type, multiplicity, **ordering**, redefinitions/subsettings, supertypes/subtypes, and the derivation/constraint OCL. (For cross-cutting fan-out questions spanning many metaclasses, the `hypha:metamodel-navigator` agent.) +- **`hypha:spec-citation`** — the normative wording and intent/semantics behind a metaclass or constraint, with an exact clause reference. +- **`hypha:sysml-validation`** — validate `.sysml` / `.kerml` textual notation against the grammar and metamodel. + +Ground first, then implement against the verified contract. Concrete example of why: a derived property such as `ActionDefinition::action` is declared `ordered` in the metamodel — a fact the OCL comment alone does not surface and a sibling analogue may only satisfy by accident. Confirm such contracts via `hypha:metamodel-lookup` rather than inferring them. + ### Project Dependency Graph ``` From 2c857b55edf9bff4d965d18a9fd60dd1edee1606 Mon Sep 17 00:00:00 2001 From: samatstarion Date: Wed, 1 Jul 2026 08:15:49 +0200 Subject: [PATCH 2/5] [Update] emphasize spec-intent inspection alongside metamodel structure --- CLAUDE.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index 766e50b3..65ad1284 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -101,12 +101,15 @@ This applies whenever you are about to: - implement or review a textual-notation / lexical rule, or - make a claim about what the SysML v2 / KerML specification requires. -Use: -- **`hypha:metamodel-lookup`** — structure: a metaclass's type, multiplicity, **ordering**, redefinitions/subsettings, supertypes/subtypes, and the derivation/constraint OCL. (For cross-cutting fan-out questions spanning many metaclasses, the `hypha:metamodel-navigator` agent.) -- **`hypha:spec-citation`** — the normative wording and intent/semantics behind a metaclass or constraint, with an exact clause reference. +Ground on **two axes** — structure *and* intent — because the metamodel gives you the *what* but not the *why*: + +- **`hypha:metamodel-lookup` — structure (always).** A metaclass's type, multiplicity, **ordering**, redefinitions/subsettings, supertypes/subtypes, and the derivation/constraint OCL. This is the default, always-on step. (For cross-cutting fan-out questions spanning many metaclasses, the `hypha:metamodel-navigator` agent.) +- **`hypha:spec-citation` — intent (when the derivation involves interpretation).** The OCL is a *formalization, not an explanation*: it says what to compute, not why the concept exists, what a defined term means, or how an underspecified edge case should behave. Consult the specification for the rationale and semantics whenever the OCL is terse, ambiguous, leans on a defined term (e.g. `namingFeature`, `redefinedFeature`, connector `end`, feature typing/inheritance resolution), or otherwise needs interpretation beyond a mechanical filter — so the C# translation is not merely syntactically faithful but semantically correct. Skip it only when the OCL is genuinely mechanical (e.g. a plain `selectByKind`) and unambiguous. - **`hypha:sysml-validation`** — validate `.sysml` / `.kerml` textual notation against the grammar and metamodel. -Ground first, then implement against the verified contract. Concrete example of why: a derived property such as `ActionDefinition::action` is declared `ordered` in the metamodel — a fact the OCL comment alone does not surface and a sibling analogue may only satisfy by accident. Confirm such contracts via `hypha:metamodel-lookup` rather than inferring them. +Ground first, then implement against the verified contract. Two concrete examples of why: +- **Structure the OCL comment hides:** `ActionDefinition::action` is declared `ordered` in the metamodel — a fact the OCL comment alone does not surface and a sibling analogue may satisfy only by accident. Confirm via `hypha:metamodel-lookup`. +- **Intent the OCL comment cannot express:** an OCL body that reads `->first()` or `->at(1)` is picking *one* of many, but only the spec prose says *on what basis* (e.g. the most specific redefinition) — translate it faithfully to that intent, not as an arbitrary first-element grab. Confirm via `hypha:spec-citation`. ### Project Dependency Graph From a7ad83bb380306bab62cbc114953f4853767036c Mon Sep 17 00:00:00 2001 From: samatstarion Date: Wed, 1 Jul 2026 08:19:31 +0200 Subject: [PATCH 3/5] [Update] recommend installing Hypha plugin when absent --- CLAUDE.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CLAUDE.md b/CLAUDE.md index 65ad1284..f69dae1c 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -95,6 +95,8 @@ These text files are large (PDF-converted, up to 1.3 MB) and the conversion is n If the **Hypha** plugin is installed, treat it as the grounding step **before** implementing or reviewing anything that depends on the SysML v2 / KerML metamodel — do not rely on a sibling analogue, the doc-comment OCL, or prior knowledge as the source of truth. The metamodel is large and precise; a plausible prior is exactly what produces confident-but-wrong derivations. +**If the Hypha plugin is *not* installed:** the first time a task in this session would benefit from this grounding (any of the situations below), inform the user once that the Hypha plugin exists and that installing it is recommended for accurate SysML v2 / KerML work — it surfaces the metamodel structure and normative spec text on demand. Then proceed using the checked-in sources as the fallback source of truth: the XMI metamodel (`Resources/KerML_only_xmi.uml`, `Resources/SysML_only_xmi.uml`) for structure and OCL, and `Resources/specification/` for intent. Do not repeat the recommendation on every subsequent task. + This applies whenever you are about to: - implement or modify a `Compute*` derived-property / OCL computation under `SysML2.NET/Extend/`, - reason about a metaclass's features, multiplicities, ordering, redefinitions/subsettings, or constraints, From fa235e23dd5987f96c72bc378205c63abc2257fd Mon Sep 17 00:00:00 2001 From: atheate Date: Thu, 2 Jul 2026 09:21:00 +0200 Subject: [PATCH 4/5] Updated implement-extensions commands to uses Hypha when possible --- .../commands/implement-extensions-batch.md | 199 +++++++- .claude/commands/implement-extensions.md | 264 ++++++++++- .claude/team-templates/extension-impl.md | 428 ++++++++++++++++-- 3 files changed, 807 insertions(+), 84 deletions(-) diff --git a/.claude/commands/implement-extensions-batch.md b/.claude/commands/implement-extensions-batch.md index ff294312..15be8eff 100644 --- a/.claude/commands/implement-extensions-batch.md +++ b/.claude/commands/implement-extensions-batch.md @@ -91,6 +91,33 @@ prompt as follows BEFORE the `Agent(...)` call: The team template itself does NOT need to change. The single-file `/implement-extensions` command continues to use the unadapted prompts. +## Sub-agent spawn mode (applies to EVERY `Agent(...)` call below) + +Every `Agent(...)` call in this command MUST pass `mode: "acceptEdits"` +explicitly. Same rule as the single-file command — see the "Sub-agent spawn +mode" section in `.claude/commands/implement-extensions.md` for the +rationale. Applies to: legacy researcher (8a), Hypha researcher (8b), +comparator (8.5), implementer (9), tester (9), regression-sweep tester (11), +reviewer (12). + +## Pre-flight: Hypha plugin detection (runs before step 1) + +Identical semantics to the single-file command's Hypha pre-flight (see +`.claude/commands/implement-extensions.md` → "Pre-flight: Hypha plugin +detection"). Summary: + +- Record `hypha_available: bool` at the very start of the invocation. +- When `hypha_available == true`, both researchers run in parallel at Phase R + (step 8), followed by the comparator (step 8.5), followed by the new + Gate B-C (batch-scoped, one pick across all N files). +- When `hypha_available == false`, surface a one-line install recommendation + once and continue with the legacy-only flow — steps 8, 9, ..., 14 as + written. Skip step 8b, step 8.5, and Gate B-C entirely. +- On mid-run downgrade (Hypha errors between 8b and 8.5), stop dispatching + Hypha work, skip 8.5 + Gate B-C, proceed with `active_notes_file` per + file = its legacy `NOTES_FILE`. Surface the downgrade in step 14's final + summary. + ## Workflow ### 1. Parse `$ARGUMENTS` and validate the batch @@ -125,7 +152,10 @@ step 2: | `TARGET_INTERFACE` | `I` — find via Glob `SysML2.NET/Core/AutoGenPoco/**/I.cs` | | `TARGET_METACLASS` | `` | | `SUBJECT_PARAM_NAME` | lowercase first char of `` + `[1..]` + `Subject` | -| `NOTES_FILE` | `.team-notes/-extensions-spec.md` (kebab-case) | +| `NOTES_FILE` | `.team-notes/-extensions-spec.md` (kebab-case) — legacy researcher output | +| `HYPHA_NOTES_FILE` | `.team-notes/-extensions-spec-hypha.md` — only when `hypha_available == true` | +| `COMPARISON_FILE` | `.team-notes/-extensions-comparison.md` — only when `hypha_available == true` | +| `ACTIVE_NOTES_FILE` | per-file, computed at Gate B-C (or defaulted to the legacy `NOTES_FILE` when Hypha is off). Substituted into implementer/tester/reviewer prompts. | | `TEAM_NAME` | `batch-extensions-impl` (one team name for the whole batch) | | `ISSUE_NUMBER` | from `gh issue list … --search "SysML2.NET/Extend/Extensions.cs in:body"` | @@ -211,15 +241,20 @@ Idempotent — re-assigning is a no-op on `gh`. Report success/failure per issue on failure, log and continue (an unassignable issue is not a blocker for the implementation itself). -### 8. Phase R — Spawn the batch researcher (ONE agent) +### 8. Phase R — Spawn the batch researcher(s) + +Split into 8a + 8b based on `hypha_available` from the pre-flight. + +#### 8a. Legacy batch researcher (ALWAYS run) **One `Agent(...)` call** for the entire batch: - `subagent_type: "general-purpose"` - `model: ` per the batch-wide step-5 grade. - Foreground. -- Prompt: the v2 researcher prompt from `.claude/team-templates/extension-impl.md`, - adapted per "Prompt adaptation rules" above: +- Prompt: the v2 legacy researcher prompt from + `.claude/team-templates/extension-impl.md`, adapted per "Prompt adaptation + rules" above: - Allowed-write list: ALL N notes files (`.team-notes/-extensions-spec.md`, …, `.team-notes/-extensions-spec.md`). @@ -228,9 +263,106 @@ implementation itself). - "When done" SendMessage payload: a per-file summary (file → derivation source → transitive stub-blocker flags), not a single blob. -After the agent returns, **read each notes file** yourself to verify coverage, -spec-text-only flags, and stub-blocker flags. If a notes file is missing or -empty, re-dispatch the researcher with a focused brief naming only that file. +#### 8b. Hypha batch researcher (ONLY when `hypha_available == true`) + +**Spawn 8a and 8b in the SAME orchestrator message** — one message, two +`Agent(...)` calls, both foreground. They run in parallel with completely +independent contexts. + +- `subagent_type: "general-purpose"` +- `model: ` — same tier as legacy. +- Foreground. +- Prompt: the v2 `hypha-researcher` prompt, adapted per "Prompt adaptation + rules": + - Allowed-write list: ALL N Hypha notes files + (`.team-notes/-extensions-spec-hypha.md`, …, + `.team-notes/-extensions-spec-hypha.md`). + - "Methods to research" enumeration: same as legacy (identical union of + all N method lists, grouped per file). + - The forbidden-reads list is UNCHANGED from the single-file prompt — + the batch still MUST NOT touch `Resources/*.uml` or + `Resources/specification/*.pdf.txt` regardless of file count. + - Same per-file summary payload shape as 8a, plus explicit flags on + methods where Hypha returned "not found" or had to fall back to a + spec citation. + +#### 8c. Post-researcher coverage check + +After BOTH agents return (or just 8a in a legacy-only run), read each notes +file yourself to verify coverage. Re-dispatch the individual researcher whose +file(s) are empty / missing sections. Do NOT proceed until all files +(N legacy + N Hypha, or just N legacy) are complete. + +If `hypha_available == false`, skip 8b + 8c-Hypha, skip step 8.5 + Gate B-C, +and proceed directly to step 9 (Phase IT) with each file's `ACTIVE_NOTES_FILE` +defaulted to its legacy `NOTES_FILE`. + +### 8.5. Phase C — Spawn the batch comparator (ONLY when `hypha_available == true`) + +**One `Agent(...)` call** for the whole batch: + +- `subagent_type: "general-purpose"` +- `model: ` — same tier as the researchers. +- Foreground. +- Prompt: the v2 `comparator` prompt, adapted per "Prompt adaptation rules": + - Allowed-write list: ALL N comparison files + (`.team-notes/-extensions-comparison.md`, …, + `.team-notes/-extensions-comparison.md`). + - Input pairs: for each of the N files, the pair + (`.team-notes/-extensions-spec.md`, + `.team-notes/-extensions-spec-hypha.md`). + - "When done" SendMessage payload: per-file overall verdict + counts, + followed by a top-level batch verdict roll-up (majority-verdict wins, + with the count of files in each bucket surfaced). + +After it returns, read each `COMPARISON_FILE` yourself to build the batch-wide +inline preview for Gate B-C. + +### 8.7. Gate B-C — Batch-Comparison gate (ONLY when `hypha_available == true`) + +Before Phase IT, present the batch-wide comparison inline and ask for a +**single batch-wide pick** (Hypha vs. legacy) that applies to ALL N files. +This intentionally differs from the single-file Gate R-C: at N=6, per-file +picking is unusable — the gate would become 6 sequential +`AskUserQuestion` calls. A single batch-wide pick is the pragmatic tradeoff; +the per-file comparison files remain on disk regardless so the user can +audit each file's fit after the run. + +1. **Render** an inline preview: + - Batch-wide verdict roll-up (e.g. "Hypha stronger for 4/6 files, legacy + stronger for 1/6, equivalent for 1/6"). + - Per-file table: + + | File | Verdict | Counts (agree/disagree/legacy-only/hypha-only) | Top concern | + |---|---|---|---| + | `Extensions.cs` | hypha stronger | 6/1/0/0 | — | + | `Extensions.cs` | mixed | 3/2/1/0 | `ComputeX` — different OCL translation | + | … | … | … | … | + + - Paths to all N `COMPARISON_FILE`s so the user can dive in per file. + - Cap at ~120 lines (higher than single-file since the table scales with N). + +2. **Ask** via `AskUserQuestion` (single question, 3 options): + - **Use Hypha notes across the batch** — every file's + `ACTIVE_NOTES_FILE` = its `HYPHA_NOTES_FILE`. + - **Use legacy notes across the batch** — every file's + `ACTIVE_NOTES_FILE` = its `NOTES_FILE`. + - **Abort — re-research with feedback** — free-form `Other` text is + forwarded to the still-addressable researcher(s) via `SendMessage`; + after they return, re-run 8.5 and this gate. + +3. **On pick**, record the per-file `ACTIVE_NOTES_FILE` map on orchestrator + state (the pick is batch-wide but the map is per-file so downstream can + substitute the correct path per file). Proceed to Phase IT (step 9). + +4. **On abort without re-research**, stop the orchestration. All + `.team-notes/*.md` files remain for the user's reference. The branch + created in step 6 stays; no Phase IT edits happen. + +Rationale: Gate B-C is the batch analogue of the single-file Gate R-C, with +a single-question shape because per-file picking at N=6 is impractical. The +per-file `COMPARISON_FILE`s stay on disk regardless of the pick so a mixed +verdict is still auditable file-by-file after the run. ### 9. Phase IT — Spawn the batch implementer + tester in parallel (TWO agents) @@ -245,14 +377,16 @@ to the N test fixtures (disjoint sets). - "Methods to implement" section: enumerate ALL methods across ALL N files, grouped under an `## File: ` heading per file. Order files by dependency tier (file A's stubs that file B depends on come first). - - Reads ALL N notes files before starting. + - Reads ALL N `ACTIVE_NOTES_FILE`s before starting (per-file, from the + Gate B-C pick — either legacy or Hypha; in a legacy-only run, all + files' `ACTIVE_NOTES_FILE` = their legacy `NOTES_FILE`). - **Tester prompt**: the v2 tester prompt, adapted similarly. - Allowed-write list: ALL N test fixtures. - "Methods to test" section: enumerate per file. - **Parallel-mode caveat still applies** — tester runs only `dotnet build` of the test project, NEVER `dotnet test` (production lacks the implementer's parallel-turn edits in the tester's disk view). - - Reads ALL N notes files before starting. + - Reads ALL N `ACTIVE_NOTES_FILE`s before starting. ### 10. Phase V — Orchestrator verification (sequential) @@ -305,8 +439,11 @@ Iterate until the full solution test run is 0 failures. per "Prompt adaptation rules": - Read-only across the repo (unchanged from the template). -- Files to review: ALL N notes files + ALL N production files + ALL N test - fixtures + any sibling fixtures touched in Phase S. +- Files to review: ALL N `ACTIVE_NOTES_FILE`s (per-file, from Gate B-C) + + ALL N production files + ALL N test fixtures + any sibling fixtures + touched in Phase S. The Hypha notes file / legacy notes file that was + NOT picked at Gate B-C is not part of the reviewer's contract for that + file, but is still preserved on disk for the A/B corpus. - "Output format" SendMessage payload: per-file `OK / NEEDS FIX` verdicts, then a batch-wide summary line. The orchestrator needs to know which files need re-dispatch and which are clean. @@ -352,6 +489,19 @@ Print to the user: - Spec-text-only methods flagged separately (grounded in spec prose, not OCL). - Out-of-scope blockers surfaced. +- **Hypha comparison block** (ONLY when `hypha_available == true`): + - Batch-wide verdict roll-up from the N `COMPARISON_FILE`s + (e.g. "Hypha stronger for 4/6 files, legacy stronger for 1/6, + equivalent for 1/6"). + - Which notes path drove implementation (batch-wide: Hypha or legacy, + per Gate B-C). + - Repo-relative paths to all N `.team-notes/-extensions-comparison.md` + files for the user to inspect after the run — the A/B corpus lives on + disk regardless of the Gate B-C pick. + - If the run downgraded mid-flight (Hypha errored between 8b and 8.5), + a short note saying "Hypha comparison unavailable for the batch — + downgraded to legacy-only at step X" and skip the rest of the block. + - **Pre-filled commit message** (MANDATORY — append at the very end of the final-summary message in a fenced code block, ready to copy): ``` @@ -376,7 +526,9 @@ After the handoff line, the orchestrator stops. The run is complete. The user ma | Dirty working tree | Step 4 | Abort, ask user to commit/stash. | | Branch already exists | Step 6 | Abort; ask user to pick a different batch or delete the stale branch. | | `gh issue edit --add-assignee` fails for one issue | Step 7 | Log + continue (non-blocking; implementation still proceeds). | -| Researcher's notes file missing/empty for one file | Step 8 | Re-dispatch THE researcher with a focused brief naming only that file. | +| Researcher's notes file missing/empty for one file | Step 8a / 8b | Re-dispatch THE affected researcher (legacy or Hypha) with a focused brief naming only that file. | +| Hypha plugin errors mid-run (between 8b and 8.5) | Step 8 / 8.5 | Skip step 8.5 + Gate B-C. Set every file's `ACTIVE_NOTES_FILE` = its legacy `NOTES_FILE`. Surface downgrade in step 14. | +| Comparator's report missing/empty for one file | Step 8.5 | Re-dispatch THE comparator with a focused brief naming only that file's pair. | | Production build fails | Step 10.1 | Re-dispatch THE implementer with a focused brief naming the broken file(s) + compile errors. | | Targeted test fails | Step 10.2 | Attribute (OCL vs test bug), re-dispatch THE implementer or THE tester with a focused brief. | | Sibling test failure in regression sweep | Step 11 | Dispatch ONE regression-sweep tester with the full sibling list. | @@ -390,7 +542,13 @@ After the handoff line, the orchestrator stops. The run is complete. The user ma ## Parallelism caps (orchestrator self-enforced) - N ≤ 6 files per batch (single-context working set limit for each agent). -- Phase R: **1** agent. +- Phase R: + - Legacy-only run (`hypha_available == false`): **1** agent. + - Hypha run (`hypha_available == true`): **2** agents in parallel + (1 legacy researcher + 1 Hypha researcher). Same-message dual + `Agent(...)` calls; disjoint output paths (legacy → `NOTES_FILE`, + Hypha → `HYPHA_NOTES_FILE`). +- Phase C (comparator, only in Hypha runs): **1** agent. - Phase IT: **2** agents in parallel (1 implementer + 1 tester). - Phase S regression-sweep tester: **1** agent. - Phase RV: **1** agent. @@ -406,9 +564,18 @@ context per role. expansion, multi-file allowed-write list, per-file method grouping). Do not invent new role prompts from scratch. - All paths in agent prompts must be repo-relative with forward slashes. -- Researcher is **mandatory** for the batch, even when one or more files have - been seen before via `/implement-extensions`. The researcher is cheap and - produces the contract the implementer/tester/reviewer read. +- Legacy researcher is **mandatory** for the batch, even when one or more + files have been seen before via `/implement-extensions`. It is cheap and + produces the contract the implementer/tester/reviewer read (when Gate B-C + picks legacy, or the run is legacy-only). +- **Hypha researcher + comparator + Gate B-C run when `hypha_available == true`.** + Both researchers spawn in the same orchestrator message (parallel, + disjoint outputs), the comparator diffs their N pairs, and Gate B-C + presents a single batch-wide pick to the user. Neither researcher may + cross-contaminate: legacy MUST NOT use Hypha, Hypha MUST NOT read raw + `Resources/*.uml` or `Resources/specification/*.pdf.txt`. See the + pre-flight section at the top of this file and the template's "How Hypha + comparison plugs in" section. - Reviewer is **mandatory** for the batch — cheap insurance against subtle OCL mistranslation. - The branch and the assignments persist even on partial failure. Be explicit diff --git a/.claude/commands/implement-extensions.md b/.claude/commands/implement-extensions.md index fc941a89..41860cd5 100644 --- a/.claude/commands/implement-extensions.md +++ b/.claude/commands/implement-extensions.md @@ -45,6 +45,86 @@ This is the user-memory `feedback_scope_discipline.md` rule. Even when an adjace stub blocks dependent test coverage, surface the blocker; do not silently expand scope. Use the stub-blocker test pattern (see template). +## Sub-agent spawn mode (applies to EVERY `Agent(...)` call below) + +Every `Agent(...)` call in this command MUST pass `mode: "acceptEdits"` +explicitly: + +``` +Agent({ + subagent_type: "general-purpose", + model: "", + mode: "acceptEdits", // MANDATORY — see rationale below + prompt: "" +}) +``` + +**Rationale**: sub-agents inherit the parent orchestrator's permission mode +at spawn time. If the parent is in (or has been in) plan mode, the sub-agent +inherits plan-mode enforcement, and plan mode's built-in pre-tool-use hook +blocks `Skill(...)` calls. This makes the Hypha researcher's grounding path +(`Skill(hypha:metamodel-lookup)`, `Skill(hypha:spec-citation)`) completely +unreachable from the sub-agent, and the researcher also cannot `Write` its +notes file. `mode: "acceptEdits"` overrides the inheritance so the sub-agent +can invoke both Skills and Writes as its role requires. Discovered during a +dry-run against `SysML2.NET/Extend/StepExtensions.cs` (2026-07-01). + +Applies to: legacy researcher (5a), Hypha researcher (5b), comparator (5.4), +implementer (6), targeted-fixture tester (6), regression-sweep tester (8), +reviewer (9). If any spawn omits `mode: "acceptEdits"`, the run may silently +degrade to the deferred-write workaround (see the team template's +"Plan-mode-aware prompting" section), which is much slower and requires the +orchestrator to apply on-behalf writes. + +## Pre-flight: Hypha plugin detection (runs before Gate 0) + +The Hypha plugin is a WIP grounding source for SysML v2 / KerML lookups +(`hypha:metamodel-lookup` for structure, `hypha:spec-citation` for intent). +This command uses it to A/B-validate a Hypha-grounded researcher against the +legacy XMI-grounded researcher on every invocation where the plugin is +installed. See `.claude/team-templates/extension-impl.md` → "How Hypha +comparison plugs in" for the design. + +At the very start of the invocation, BEFORE Gate 0 or any other step: + +1. **Detect availability**. Record `hypha_available: bool` on the + orchestrator's per-run state. The signal: is the `hypha:metamodel-lookup` + skill / `hypha:metamodel-navigator` agent listed in the current session's + toolset (the `` block at session start enumerates + available skills and agents; the deferred-tool list plus that reminder + are the authoritative check). + +2. **When `hypha_available == true`** — no user interaction needed. The + Hypha researcher will run in parallel with the legacy researcher at + step 5, followed by the comparator at step 5.4, followed by Gate R-C. + +3. **When `hypha_available == false`** — surface a one-line recommendation + to the user (once per invocation, in the same orchestrator turn as the + Gate 0 plan / step 4 sanity check, whichever comes first): + > The Hypha plugin isn't installed in this session. It grounds + > SysML v2 / KerML lookups in the metamodel + normative spec text and is + > this command's A/B counterpart to the legacy XMI researcher. + > Installing it is optional — the legacy-only flow works fine — but the + > per-run comparison corpus won't grow while it's off. + + Do NOT block the run. Do NOT loop the recommendation. If the user + ignores it, silently accept refusal and continue. + +4. **On refusal (or `hypha_available == false` after the recommendation)**: + the run proceeds with the legacy-only flow — steps 5, 5.5, 6, ..., 11 as + written. Skip steps 5b, 5.4, and Gate R-C entirely. The single-file + downstream (implementer, tester, reviewer) reads `{{NOTES_FILE}}` in the + normal way. + +5. **Mid-run downgrade**: if a Hypha tool call errors between steps 5 and + 5.4 (plugin removed / knowledge base not built / auth failure), stop + dispatching Hypha work. Skip the comparator + Gate R-C. Proceed with the + legacy researcher's notes as `active_notes_file`. Surface the downgrade + explicitly in step 10's final summary so the user knows the run didn't + exercise Hypha. + +The rest of this command's pre-flight (plan mode Gate 0) is unaffected. + ## Pre-flight: plan mode IS the pre-execution approval gate (Gate 0) If the orchestrator session is in **plan mode** when `/implement-extensions` is invoked, use plan mode as the natural pre-execution approval gate. Do NOT spawn any sub-agent. Instead: @@ -61,8 +141,9 @@ If the orchestrator session is in **plan mode** when `/implement-extensions` is - The one production file + its derived test fixture + notes file + GitHub issue number. - Per-role model picks (from step 3.5). Note that `ExitPlanMode` is binary (approve / reject), so the user cannot override models from inside the plan-approval UI. Two override paths are supported: (a) reject the plan and re-invoke with an explicit model preference in the prompt, OR (b) accept the plan and the orchestrator fires a follow-up `AskUserQuestion` BEFORE step 5's researcher spawn. - Stub method count + complexity grade. - - Workflow shape: step 5 (researcher) → step 5.5 (Gate R-A approval) → step 6 (implementer + tester) → step 7 (verification) → step 8 (regression sweep) → step 9 (reviewer) → step 10 (final summary) → step 11 (issue checklist sync). - - Explicit mention that step 5.5 will pause for `AskUserQuestion` after the researcher returns its `spec ready` (so the user knows there is exactly ONE more structural checkpoint after this one). + - Workflow shape: step 5 (researcher spawn — legacy + Hypha in parallel when `hypha_available`, else legacy only) → step 5.4 (comparator, only when `hypha_available`) → new Gate R-C (only when `hypha_available`; user picks Hypha vs. legacy notes) → step 5.5 (Gate R-A approval on the picked notes file) → step 6 (implementer + tester) → step 7 (verification) → step 8 (regression sweep) → step 9 (reviewer) → step 10 (final summary) → step 11 (issue checklist sync). + - `hypha_available` value from the pre-flight above, so the user sees the workflow shape they'll actually get. + - Explicit mention of the structural checkpoints after this one: **when `hypha_available`**, Gate R-C fires after the comparator returns (user picks Hypha vs. legacy notes), then Gate R-A fires after the picked notes are inline-previewed. **When Hypha is off**, only Gate R-A fires (one more checkpoint after this one). 3. **Call `ExitPlanMode`.** The user reviews the plan in the standard plan-approval UI: - **Approve (unchanged)** → plan mode exits, orchestrator proceeds (model-override `AskUserQuestion` per step 2 above, then step 5 → 5.5 → 6 → 7 → 8 → 9 → 10 → 11). @@ -99,10 +180,18 @@ From the normalized canonical path `SysML2.NET/Extend/Extensions.cs`: - **Target interface**: `I` — find via Glob `SysML2.NET/Core/AutoGenPoco/**/I.cs`. - **Target metaclass name**: ``. - **Subject param name**: lowercase first char of `` + `[1..]` + `Subject` (e.g. `Type` → `typeSubject`, `Feature` → `featureSubject`). -- **Notes file**: `.team-notes/-extensions-spec.md` (kebab-case ``). The - `.team-notes/` directory is gitignored at `.gitignore` line `/.team-notes/*`, so - the file is per-contributor scratch. Create the directory if it doesn't exist - (`mkdir -p .team-notes`). +- **Notes file (legacy)**: `.team-notes/-extensions-spec.md` (kebab-case + ``). The `.team-notes/` directory is gitignored at `.gitignore` line + `/.team-notes/*`, so all three per-run files are per-contributor scratch. + Create the directory if it doesn't exist (`mkdir -p .team-notes`). +- **Notes file (Hypha)** — only when `hypha_available == true`: + `.team-notes/-extensions-spec-hypha.md`. +- **Comparison file** — only when `hypha_available == true`: + `.team-notes/-extensions-comparison.md`. +- **Active notes file** — computed at Gate R-C (or defaulted to the legacy + notes file when Hypha is off). Held on orchestrator state as + `active_notes_file` and substituted for `{{ACTIVE_NOTES_FILE}}` in the + implementer / tester / reviewer prompts. - **Team name**: `-extensions-impl`. - **GitHub issue number**: discover via ```bash @@ -177,7 +266,15 @@ applied at every `Agent(...)` spawn in steps 5–9. ### 4. Sanity check with the user Use `AskUserQuestion` to present: -- The auto-derived paths (test fixture, interface, reference template, notes file). +- The auto-derived paths (test fixture, interface, reference template, notes + files: legacy `{{NOTES_FILE}}`, and — when `hypha_available` — Hypha + `{{HYPHA_NOTES_FILE}}` and comparison `{{COMPARISON_FILE}}`). +- `hypha_available` (`true` / `false`) and the resulting workflow shape + (either legacy+Hypha+comparator+Gate R-C or legacy-only). When + `hypha_available == false` and this session has not been recommended the + plugin yet, include the one-line install recommendation from the pre-flight + in the sanity-check text — do NOT add it as a question option (it's + informational; the user acts on it out-of-band). - The list of stub methods (or a count if there are many). - The complexity grade and the per-role model selection from step 3.5. - Two questions: @@ -191,37 +288,132 @@ If they pick subset, narrow the method list. If they override the model selection, apply that override at every `Agent(...)` spawn below. Otherwise proceed with the dynamic defaults. -### 5. Spawn the researcher (FIRST role — produces the notes file the others read) +### 5. Spawn the researcher(s) (FIRST role — produces the notes file(s) the others read) Read the v2 team template at `.claude/team-templates/extension-impl.md` to refresh the role prompts. Substitute the placeholders from step 2 + the method list from step 4. -Spawn the **researcher** as +Split into 5a + 5b based on `hypha_available` from the pre-flight: + +#### 5a. Legacy researcher (ALWAYS run) + +Spawn the **legacy researcher** as `Agent({subagent_type: "general-purpose", model: })` -with the v2 researcher prompt, where `` is the model picked -in step 3.5 (Haiku for trivial, Sonnet for standard, Opus for complex — or the -user's step-4 override). Foreground (not `run_in_background`) — the next roles -depend on the notes file. +with the v2 legacy researcher prompt, where `` is the model +picked in step 3.5 (Haiku for trivial, Sonnet for standard, Opus for complex +— or the user's step-4 override). Foreground. -The researcher MUST: +The legacy researcher MUST: - Treat the OCL ``/`` body in the XMI as the canonical source of truth. - Fall back to the OCL block in the production file's `` (mirrored from XMI by codegen). - For methods with NO OCL body (e.g. `Type::isConjugated`), record a short prose - derivation rule + spec citation, and EXPLICITLY FLAG the spec-text-only origin - in the notes. + derivation rule + spec citation to `Resources/specification/*.pdf.txt`, and + EXPLICITLY FLAG the spec-text-only origin in the notes. - Flag any method whose OCL transitively reads a still-stubbed sibling `Compute*` so the tester knows to use the stub-blocker pattern. -After the researcher finishes, read `{{NOTES_FILE}}` yourself to verify it covers all methods + flags spec-text-only and stub-blocker cases. Proceed to step 5.5 (Phase R-A approval gate) — DO NOT spawn implementer + tester directly. +#### 5b. Hypha researcher (ONLY when `hypha_available == true`) + +**Spawn 5a and 5b in the same orchestrator message** — one message, two +`Agent(...)` calls, both foreground. They run in parallel with completely +independent contexts: the legacy researcher never sees Hypha's output and +the Hypha researcher never sees `{{NOTES_FILE}}`. This is the whole point +of the A/B setup. + +Spawn the **Hypha researcher** as +`Agent({subagent_type: "general-purpose", model: })` with +the v2 `hypha-researcher` prompt (same model tier as legacy — OCL complexity +is the same input for both). The prompt MUST enforce: +- Only Hypha skills / agents (`hypha:metamodel-lookup`, `hypha:spec-citation`, + `hypha:metamodel-navigator`) as grounding sources. +- **Forbidden reads**: `Resources/*.uml` and `Resources/specification/*.pdf.txt` + — those are the legacy researcher's grounding sources. Cross-contamination + defeats the comparison. +- Same output section layout as the legacy researcher so the comparator can + align entries structurally. +- Notes-file target: `{{HYPHA_NOTES_FILE}}` (never `{{NOTES_FILE}}`). + +#### 5c. Post-researcher coverage check + +After both agents return (or just 5a in a legacy-only run), read each notes +file yourself to verify coverage. Re-dispatch the individual researcher whose +file is empty / missing sections / didn't flag spec-text-only cases where +applicable. Do NOT proceed until both files (or the legacy file, in a +legacy-only run) are complete. + +If `hypha_available == false`: skip 5b and 5c-Hypha, proceed directly to +step 5.5 (Gate R-A) with `active_notes_file = {{NOTES_FILE}}`. Otherwise +proceed to step 5.4 (comparator) before Gate R-C. + +### 5.4. Spawn the comparator (ONLY when `hypha_available == true`) + +Single `Agent({subagent_type: "general-purpose", model: })` +call for the `comparator` role (same model tier as the researchers — +comprehension needs are similar). Foreground. + +The comparator MUST: +- Read ONLY `{{NOTES_FILE}}` and `{{HYPHA_NOTES_FILE}}`. No other file is + necessary. +- Emit `agree` / `disagree` / `legacy-only` / `hypha-only` per method + an + overall verdict (`hypha stronger` / `legacy stronger` / `equivalent` / + `mixed`) backed by counts. +- Write the report to `{{COMPARISON_FILE}}` (the ONLY file it may Write) and + send a compact summary back to the orchestrator with summary + `comparison ready`. +- NOT recommend a winner — the user picks at Gate R-C. + +After it returns, read `{{COMPARISON_FILE}}` yourself to build the inline +preview for Gate R-C. + +### 5.45. Gate R-C — Researcher-Comparison gate (ONLY when `hypha_available == true`) + +Before Gate R-A, present the comparator's report inline and let the user pick +which researcher's notes drive the downstream implementer / tester / reviewer. + +1. **Render** an inline preview from `{{COMPARISON_FILE}}` in the chat response: + - Overall verdict + counts (`agree: N, disagree: N, legacy-only: N, + hypha-only: N`). + - Per-method verdict table (compact — one row per method, `agree` + collapsed to a single count line at the top if the majority agree). + - Top 3 disagreements by materiality with one-line concerns. + - Paths to `{{NOTES_FILE}}`, `{{HYPHA_NOTES_FILE}}`, `{{COMPARISON_FILE}}` + so the user can dive in. + - Cap the preview at ~80 lines. + +2. **Ask** via `AskUserQuestion` (single question, 3 options): + - **Use Hypha notes** — Hypha drives implementer/tester/reviewer. + Sets `active_notes_file = {{HYPHA_NOTES_FILE}}`. + - **Use legacy notes** — legacy drives. + Sets `active_notes_file = {{NOTES_FILE}}`. + - **Abort — re-research with feedback** — the free-form `Other` text is + forwarded to whichever researcher(s) are still addressable via + `SendMessage`. After they return fresh `spec ready` / + `hypha spec ready` payloads, re-run step 5.4 (comparator) and this gate. + +3. **On pick**, record `active_notes_file` on orchestrator state and proceed + to Gate R-A (step 5.5). The comparator report is preserved on disk + regardless of the pick — it feeds the accumulating A/B corpus. + +4. **On abort without re-research** (user rejects both notes files and does + not request re-research), stop the orchestration. All three + `.team-notes/` files remain for the user's reference. + +Rationale: Gate R-C exists ONLY in Hypha-available runs. It is the user's +one and only choice-point between the two grounding paths — after this, the +downstream flow is grounded solely in the picked notes file. The comparator +report itself is a durable artifact; Gate R-C's decision does not delete +either notes file. ### 5.5. Phase R-A — Researcher-plan approval gate (MANDATORY, every run) Before spawning implementer + tester, the orchestrator MUST render an inline spec preview and ask for explicit approval. This is non-skippable, even when the researcher reports zero ambiguities. It is the only chance the user gets to inspect the per-method derivation plan before any code is written to disk. -1. **Render** an inline preview in the chat response. Pull from `{{NOTES_FILE}}`: +1. **Render** an inline preview in the chat response. Pull from + `active_notes_file` (either `{{NOTES_FILE}}` or `{{HYPHA_NOTES_FILE}}`, + per Gate R-C — or `{{NOTES_FILE}}` in a legacy-only run): - File path + GitHub issue number (link to issue if practical). - Per method: - Signature line (`internal static Compute(this {{TARGET_INTERFACE}} {{SUBJECT_PARAM}})`). @@ -233,13 +425,13 @@ Before spawning implementer + tester, the orchestrator MUST render an inline spe 2. **Ask** via `AskUserQuestion` (single question, 2 options — "drop files" collapses out in single-file mode): - **Approve — spawn implementer + tester now** *(Recommended)*. Proceeds to step 6. - - **Abort — research again with feedback**. Orchestrator forwards the user's free-form `Other` text to the still-addressable `researcher` via `SendMessage`, waits for a fresh `spec ready`, then re-runs step 5.5. + - **Abort — research again with feedback**. Orchestrator forwards the user's free-form `Other` text to the researcher whose notes are `active_notes_file` (either legacy or Hypha) via `SendMessage`, waits for a fresh `spec ready` / `hypha spec ready`, then re-runs step 5.5. When Hypha is available, ALSO re-run step 5.4 (comparator) if the re-research changed the active notes file — the disk-side artifact needs to stay in sync. 3. **On Approve**, proceed to step 6. Do NOT re-ask until the run completes. 4. **On Abort (user rejects without requesting re-research)**, stop the orchestration. The notes file remains for the user's reference. -Rationale: the previous "After the researcher finishes, read `{{NOTES_FILE}}` yourself to verify" instruction was an internal check by the orchestrator, with no user-visible gate. This gate runs *every time*, so the user always sees the researcher's contract before any code is committed to disk. The gate governs STRUCTURAL approval only — individual tool-permission prompts that the user's `settings.json` requires (e.g. `Bash(dotnet build *)`) continue to surface during steps 6 / 7 / 8 / 9 / 11. +Rationale: the previous "After the researcher finishes, read `{{NOTES_FILE}}` yourself to verify" instruction was an internal check by the orchestrator, with no user-visible gate. This gate runs *every time*, so the user always sees the researcher's contract before any code is committed to disk. When Hypha is available, Gate R-C ran BEFORE this gate to let the user pick which grounding path drives the implementation; this gate then displays that picked notes file's per-method contract. The gate governs STRUCTURAL approval only — individual tool-permission prompts that the user's `settings.json` requires (e.g. `Bash(dotnet build *)`) continue to surface during steps 6 / 7 / 8 / 9 / 11. ### 6. Spawn the implementer and tester in parallel @@ -254,8 +446,9 @@ Spawn 1 — **implementer**: `Agent({subagent_type: "general-purpose", model: })` with the v2 implementer prompt, where `` is the model picked in step 3.5 (Sonnet for trivial/standard, Opus for complex — or the user's step-4 -override). The prompt MUST instruct the implementer to read `{{NOTES_FILE}}` -first. +override). The prompt MUST instruct the implementer to read `active_notes_file` +first (either `{{NOTES_FILE}}` or `{{HYPHA_NOTES_FILE}}`, per Gate R-C — +substitute the concrete path before spawning). Spawn 2 — **tester (targeted fixture)**: `Agent({subagent_type: "general-purpose", model: })` with the v2 @@ -361,8 +554,8 @@ Iterate until 100% green or the user opts out. reviewer prompt, where `` is the model picked in step 3.5 (Sonnet for trivial/standard, Opus for complex — or the user's step-4 override). Foreground. The reviewer cross-checks `{{PRODUCTION_FILE}}` and -`{{TEST_FILE}}` against `{{NOTES_FILE}}` and produces an "OK / NEEDS FIX" -verdict. +`{{TEST_FILE}}` against `active_notes_file` (either `{{NOTES_FILE}}` or +`{{HYPHA_NOTES_FILE}}`, per Gate R-C) and produces an "OK / NEEDS FIX" verdict. If the verdict is "NEEDS FIX", dispatch the implementer or tester back to action the findings (the reviewer never edits). @@ -375,6 +568,17 @@ Report to the user: - Modified files (production + test fixture + notes + any regression-sweep test fixtures). - Test counts (X/Y green for the targeted fixture; A/B green for the full solution). - Reviewer verdict + any unresolved findings. +- **Hypha comparison block** (ONLY when `hypha_available == true`): + - Overall verdict from `{{COMPARISON_FILE}}` (`hypha stronger` / + `legacy stronger` / `equivalent` / `mixed`) + counts + (`agree / disagree / legacy-only / hypha-only`). + - Which notes file drove implementation (`active_notes_file`). + - Repo-relative path to `{{COMPARISON_FILE}}` for the user to inspect + after the run — the A/B corpus lives on disk regardless of the Gate R-C + pick. + - If the run downgraded mid-flight (Hypha errored after step 5b), a short + note saying "Hypha comparison unavailable — downgraded to legacy-only + at step X" and skip the rest of the block. - Out-of-scope blockers surfaced (e.g. "5 populated cases use the stub-blocker pattern because `` in `.cs` is still a stub — consider a follow-up issue"). @@ -476,7 +680,16 @@ unresolved findings are separately surfaced in the final-summary report. The - The researcher runs **FIRST and is mandatory** — even when the production file's `` already carries OCL, the researcher's notes file gives the implementer/tester/reviewer a single shared contract document, AND it's the only - role that handles spec-text-only methods cleanly. + role that handles spec-text-only methods cleanly. **When the Hypha plugin is + installed**, an additional `hypha-researcher` role runs IN PARALLEL with the + legacy researcher, followed by a `comparator` agent and Gate R-C where the + user picks which notes drive downstream. See the pre-flight section at the + top of this file and steps 5b / 5.4 / 5.45. +- **No cross-contamination**: legacy researcher MUST NOT use Hypha; Hypha + researcher MUST NOT read `Resources/*.uml` or + `Resources/specification/*.pdf.txt`. Both may read the production file's + C# signature. This is enforced in the team-template role prompts, not by + the tool sandbox — respect it when substituting placeholders. - The reviewer is **mandatory** even when in past runs it caught no bugs the tester missed — the user explicitly wants it as cheap insurance against subtle OCL mistranslation. @@ -492,5 +705,6 @@ unresolved findings are separately surfaced in the final-summary report. The - **Push + PR are the user's job too** — the agent does NOT proactively push commits or open PRs. It only performs those if the user explicitly asks in a follow-up turn (rare; user-initiated only). Unlike `/implement-extensions-batch`, this command does NOT create a branch, so there is no empty-branch push to perform — the user owns branch creation and remote setup. - **Plan mode is handled by Gate 0 at the top of this file** — the orchestrator writes the proposed-execution plan to the plan file, calls `ExitPlanMode`, and proceeds on approval. The orchestrator never spawns sub-agents while plan mode is active, so the previous "degraded mode" workaround is no longer needed and has been removed. - **Gate R-A (step 5.5) is mandatory every run.** It is the only structural checkpoint between the researcher returning `spec ready` and the implementer + tester being spawned. Do not skip it even when the researcher reports zero ambiguities — the user explicitly asked for an unconditional gate so they can review per-method derivations before code is written. +- **Gate R-C (step 5.45) is mandatory ONLY when `hypha_available == true`.** It runs BEFORE Gate R-A and is the user's one choice-point between the two grounding paths (Hypha vs. legacy). Do not skip it when Hypha is on. Do not add it when Hypha is off (there's nothing to compare). The pre-flight `hypha_available` flag is the single source of truth for whether Gate R-C fires. - **Tool-level prompts (`Bash(...)`, `Edit(...)`, `Write(...)`, `Agent(...)`) still surface per the user's `settings.json`.** Gate 0 and Gate R-A govern STRUCTURAL approval only. The user has explicitly chosen to keep handling tool-level prompts manually rather than auto-allowing them via permission rules or hooks. - **Sub-agent-side deadlocks**: if an implementer or tester gets parked on a harness UI permission prompt the user cannot action, the orchestrator should take over the deadlocked work directly from its own permission scope (running `dotnet build` / `dotnet test` / `gh issue edit` itself). Send `shutdown_request` to the parked sub-agent. Surface clearly in the final summary. diff --git a/.claude/team-templates/extension-impl.md b/.claude/team-templates/extension-impl.md index d8fa1a2d..e2a1a16b 100644 --- a/.claude/team-templates/extension-impl.md +++ b/.claude/team-templates/extension-impl.md @@ -49,37 +49,65 @@ Don't use this template when: | `{{REFERENCE_PRODUCTION_FILE}}` | Working reference (repo-relative) | `SysML2.NET/Extend/NamespaceExtensions.cs` | | `{{REFERENCE_TEST_FILE}}` | Working test reference (repo-relative) | `SysML2.NET.Tests/Extend/NamespaceExtensionsTestFixture.cs` | | `{{INTERFACE_FILE}}` | Auto-gen POCO interface (repo-relative) | `SysML2.NET/Core/AutoGenPoco/IFeature.cs` | -| `{{NOTES_FILE}}` | Researcher's contract notes (repo-relative, optional) | `.team-notes/feature-extensions-spec.md` | +| `{{NOTES_FILE}}` | Legacy researcher's contract notes (repo-relative) | `.team-notes/feature-extensions-spec.md` | +| `{{HYPHA_NOTES_FILE}}` | Hypha researcher's contract notes (repo-relative, only when Hypha plugin installed) | `.team-notes/feature-extensions-spec-hypha.md` | +| `{{COMPARISON_FILE}}` | Comparator's diff report between legacy and Hypha notes (repo-relative, only when Hypha plugin installed) | `.team-notes/feature-extensions-comparison.md` | +| `{{ACTIVE_NOTES_FILE}}` | Whichever of `{{NOTES_FILE}}` / `{{HYPHA_NOTES_FILE}}` the user picked at Gate R-C (in Hypha-available runs) — or `{{NOTES_FILE}}` in legacy-only runs | `.team-notes/feature-extensions-spec-hypha.md` | | `{{METHOD_LIST}}` | Bullet list of methods to implement, in dependency order | (per-task) | | `{{ORCHESTRATOR_NAME}}` | Team-lead name for SendMessage | `team-lead` | ## Workflow ``` -1. Researcher → writes contract notes to {{NOTES_FILE}}: per method, the OCL - (or, if absent, the spec-text derivation), prose, dependencies, - suggested implementation, and test plan. ALWAYS RUN — it covers - the case where a method has no OCL body (e.g. Type::isConjugated - in the recent TypeExtensions task) and surfaces transitive - stub-blockers before the implementer hits them. - -2. Implementer → implements all methods in {{PRODUCTION_FILE}}, sliced by - dependency tier (Tier 1: direct OfType filters; Tier 2: - chains over Tier 1; Tier 3: depends on operations; Tier 4: - closures with cycle protection). Reads {{NOTES_FILE}} first. - -3. Tester → rewrites {{TEST_FILE}} with one [Test] per method-under-test, - multiple Assert.That covering null + empty + populated. Reads - {{NOTES_FILE}} first for each method's test plan. - -4. Reviewer → READ-ONLY verdict against the OCL blocks AND the - researcher's notes; flags any mistranslation; never edits. - -5. Orchestrator → dotnet build, targeted dotnet test, REGRESSION SWEEP - (full solution test). Stub-blocker assertions in sibling - fixtures that now fail get updated as part of the same PR. +1. Researcher → writes contract notes to {{NOTES_FILE}}, grounded in +(legacy) Resources/KerML_only_xmi.uml + Resources/SysML_only_xmi.uml + + Resources/specification/*.pdf.txt. ALWAYS RUN. + +1b. Hypha-researcher → writes parallel contract notes to {{HYPHA_NOTES_FILE}}, +(only when Hypha grounded in hypha:metamodel-lookup + hypha:spec-citation + plugin installed) ONLY (must NOT touch raw XMI or PDF-text files). + Spawned in parallel with (1). Independent — does NOT read + (1)'s output. + +1c. Comparator → READ-ONLY. Diffs {{NOTES_FILE}} vs {{HYPHA_NOTES_FILE}} +(only when Hypha per method; writes a report to {{COMPARISON_FILE}} and + plugin installed) surfaces a summary. The user picks which notes drive + downstream (Gate R-C). + +2. Implementer → implements all methods in {{PRODUCTION_FILE}}, sliced by + dependency tier. Reads {{ACTIVE_NOTES_FILE}} first + (the user-picked notes file — legacy or Hypha). + +3. Tester → rewrites {{TEST_FILE}} with one [Test] per + method-under-test, multiple Assert.That covering + null + empty + populated. Reads {{ACTIVE_NOTES_FILE}} + first for each method's test plan. + +4. Reviewer → READ-ONLY verdict against the OCL blocks AND + {{ACTIVE_NOTES_FILE}}; flags any mistranslation; never edits. + +5. Orchestrator → dotnet build, targeted dotnet test, REGRESSION SWEEP + (full solution test). Stub-blocker assertions in sibling + fixtures that now fail get updated as part of the same PR. ``` +## Sub-agent spawn mode (primary path — added 2026-07-01) + +The orchestrator MUST pass `mode: "acceptEdits"` explicitly on every +`Agent(...)` spawn that uses this template. Reason: sub-agents inherit the +parent's plan-mode state at spawn time; plan mode's built-in pre-tool-use +hook blocks `Skill(...)` calls, which makes the Hypha researcher's grounding +path unreachable AND blocks the sub-agent's `Write` of its notes/production/ +test file. `mode: "acceptEdits"` overrides the inheritance for that specific +sub-agent, letting it use `Skill(hypha:*)` and `Write` its allowed-write file +freely. The role prompts themselves are unchanged — this is a spawn-time +concern, not a prompt-time one. + +The section below ("Plan-mode-aware prompting") documents the FALLBACK path +used when the orchestrator itself is in plan mode and cannot bypass the +sub-agent's inherited restriction. That fallback stays as insurance but is +no longer the primary flow. + ## Plan-mode-aware prompting (added 2026-05-28) If the orchestrator session is in plan mode when this template is used, sub-agents @@ -135,14 +163,21 @@ Out-of-scope changes (refuse and surface): The Agent SDK has no per-file ACL, so each role's prompt restates the rule and tells the agent to refuse or escalate when a tool call would violate it. -- **Researcher**: read-only everywhere except `{{NOTES_FILE}}`. +- **Researcher (legacy)**: read-only everywhere except `{{NOTES_FILE}}`. +- **Hypha-researcher** (only when Hypha plugin installed): read-only + everywhere except `{{HYPHA_NOTES_FILE}}`. MUST NOT read + `Resources/KerML_only_xmi.uml`, `Resources/SysML_only_xmi.uml`, or + `Resources/specification/*.pdf.txt` — that would collapse the two + grounding paths into one and defeat the A/B comparison. +- **Comparator** (only when Hypha plugin installed): FULLY READ-ONLY across + the repo — except for `{{COMPARISON_FILE}}` (the ONLY file it may Write). - **Implementer**: read-only everywhere except `{{PRODUCTION_FILE}}`. MUST read - `{{NOTES_FILE}}` before starting. + `{{ACTIVE_NOTES_FILE}}` before starting. - **Tester**: read-only everywhere except `{{TEST_FILE}}`. MUST read - `{{NOTES_FILE}}` before starting. + `{{ACTIVE_NOTES_FILE}}` before starting. - **Reviewer**: read-only everywhere — no Write/Edit at all. Cross-checks both - `{{PRODUCTION_FILE}}` against `{{NOTES_FILE}}` and `{{TEST_FILE}}` against the - test plans in `{{NOTES_FILE}}`. + `{{PRODUCTION_FILE}}` against `{{ACTIVE_NOTES_FILE}}` and `{{TEST_FILE}}` + against the test plans in `{{ACTIVE_NOTES_FILE}}`. No `>` redirects, `tee`, `sed -i`, `cp`, or `mv` into files outside the allowed target. If a tool call would violate the rule, the agent must abort and message @@ -237,10 +272,15 @@ hand-reformat of `FeatureExtensions.cs`. All four roles must enforce these. --- -## Role prompt: researcher (DEFAULT — always run) +## Role prompt: researcher — legacy (DEFAULT — always run) + +Grounded in the raw XMI + `Resources/specification/*.pdf.txt` files that live in +the repo. Runs unconditionally on every invocation. When the Hypha plugin is +installed, this researcher runs in parallel with the `hypha-researcher` role +below (independent contexts, no cross-contamination). ``` -You are the **spec-researcher** on the `{{TEAM_NAME}}` team. +You are the **legacy spec-researcher** on the `{{TEAM_NAME}}` team. ## Hard rule on file edits You are READ-ONLY across the entire repository EXCEPT for ONE file: @@ -320,8 +360,255 @@ Begin. --- +## Role prompt: hypha-researcher (ONLY when Hypha plugin installed) + +Mirror of the legacy researcher's contract, but grounded exclusively via the +Hypha plugin skills / agents (`hypha:metamodel-lookup`, `hypha:spec-citation`, +`hypha:metamodel-navigator`). Runs in parallel with the legacy researcher — +independent contexts, no cross-contamination. + +``` +You are the **hypha spec-researcher** on the `{{TEAM_NAME}}` team. + +## Hard rule on file edits +You are READ-ONLY across the entire repository EXCEPT for ONE file: + + `{{HYPHA_NOTES_FILE}}` + +You may use Write/Edit ONLY on that notes file. Do not Edit, Write, or +NotebookEdit any .cs, .uml, .xmi, .json, .csproj, .md, or any other file in the +repo. Do not use Bash to create or modify any other file (no `>` redirects, no +`tee`, no `sed -i`, no `cp`/`mv` into source). If a tool call would violate +this, do NOT make it — instead message `{{ORCHESTRATOR_NAME}}` via SendMessage +and ask. + +## Hard rule on grounding sources +You MUST ground exclusively in the Hypha plugin's outputs. This is the whole +point of the role — you are the A/B counterpart to the legacy researcher, and +the comparison is meaningless if you also read the same raw sources. + +**Forbidden reads** (any of these collapses the two paths into one): +- `Resources/KerML_only_xmi.uml` +- `Resources/SysML_only_xmi.uml` +- `Resources/specification/1-Kernel_Modeling_Language.pdf.txt` +- `Resources/specification/2a-OMG_Systems_Modeling_Language.pdf.txt` +- `Resources/specification/3-Systems_Modeling_API_and_Services.pdf.txt` +- `Resources/specification/Intro to the SysML v2 Language-Textual Notation.pdf.txt` +- `Resources/specification/Intro to the SysML v2 Language-Graphical Notation.pdf.txt` +- Any other `.pdf.txt` / `.pdf` / `.uml` / `.xmi` under `Resources/`. + +**Allowed reads**: +- Every Hypha skill and Hypha agent: `hypha:metamodel-lookup`, + `hypha:spec-citation`, `hypha:sysml-validation`, and the deep agents + `hypha:metamodel-navigator`, `hypha:spec-citation`, `hypha:sysml-validator`. +- The production file `{{PRODUCTION_FILE}}` — but ONLY for the C# signatures + of the methods listed below. The `` OCL block that appears in that + file is a codegen artifact of the same XMI you are forbidden to read + directly; treat it as informational (you can see it because you must read + the signature) but do NOT use it as your derivation source. Every claim in + your notes must be traceable back to a Hypha lookup, not the `` + block. +- The reference production file `{{REFERENCE_PRODUCTION_FILE}}` — for + canonical C# style / null-check patterns only. Do NOT copy OCL from there. +- The auto-generated interface `{{INTERFACE_FILE}}` — for the property + signature and return type. Do NOT use its doc-comment OCL as derivation. + +If a Hypha lookup returns "not found" or is ambiguous, EXPLICITLY FLAG that +in the notes rather than silently falling back to the forbidden sources. + +## Goal +For each method in the list below, produce a contract entry in +`{{HYPHA_NOTES_FILE}}` that mirrors the legacy researcher's output format +exactly (same section layout, same fields), so the comparator agent can diff +them structurally. + +**Grounding methodology** — this is the CLAUDE.md "Grounding SysML v2 / KerML +work with the Hypha plugin" section applied to a researcher role: + +- **Structure (always)** — `hypha:metamodel-lookup` for each metaclass's: + - features (type, multiplicity, ordering, redefinitions, subsettings) + - supertypes and subtypes + - OCL derivation body (`` equivalent) + - OCL constraint bodies (`` equivalent) + - primitive types and enumerations referenced by the property + For cross-cutting fan-out (a chain that hops across several metaclasses, + e.g. "which metaclasses have a feature typed by Expression?"), delegate + to the `hypha:metamodel-navigator` agent so the bulk file reading stays + out of your context. + +- **Intent (when the OCL is not mechanical)** — `hypha:spec-citation` for + the normative spec prose whenever the OCL: + - is terse (`->first()` / `->at(1)` without a stated ordering) + - leans on a defined term (`namingFeature`, `redefinedFeature`, connector + `end`, feature typing/inheritance resolution) + - has an underspecified edge case + - otherwise needs interpretation beyond a mechanical filter + Skip only when the OCL is a plain `selectByKind(T)` / trivial filter. + +- **Validation (when useful)** — `hypha:sysml-validation` (or the + `hypha:sysml-validator` agent) when you want to confirm the C# translation + you'd suggest matches the metamodel constraint on a sample snippet. + +## Methods to research +{{METHOD_LIST}} + +## Output format +Append to `{{HYPHA_NOTES_FILE}}` (do NOT overwrite — same rule as the legacy +researcher). One section per method, using EXACTLY the same section layout as +the legacy researcher so the comparator can align them side-by-side: + +- Method signature line. +- **Derivation source tag** — `hypha:metamodel-lookup(::)`, + `hypha:spec-citation()`, or `spec-text only via hypha` when the + Hypha spec-citation is what carries the definition. NEVER `OCL in XMI` or + `OCL in ` — those are legacy-researcher-only tags. +- Suggested C# code block. +- Dependencies summary (sibling derived properties used; upstream stubs hit). +- Stub-blocker flag if applicable. +- Any Hypha "not found" / ambiguity flag encountered. + +If a Hypha lookup returns something that conflicts with what you'd expect +from your prior knowledge of KerML/SysML v2, prefer Hypha's answer and FLAG +the conflict in the notes — the comparator + user will judge whose grounding +is right. + +## When done +Send a SendMessage to `{{ORCHESTRATOR_NAME}}` with summary `hypha spec ready` +and a list of: +- methods where Hypha returned "not found" or an ambiguous answer, +- methods where you had to fall back to a spec-citation because the metamodel + lookup was insufficient, +- methods where Hypha's answer differs from what the `` OCL block + suggests (flag WITHOUT resolving — the comparator surfaces this). + +Begin. +``` + +--- + +## Role prompt: comparator (ONLY when Hypha plugin installed) + +READ-ONLY diff agent. Runs after both the legacy researcher and the +`hypha-researcher` return. Produces a per-method delta report and a batch-wide +summary; the user picks which notes drive downstream at Gate R-C. + +``` +You are the **comparator** on the `{{TEAM_NAME}}` team. + +## Hard rule on file edits +You are READ-ONLY across the entire repository EXCEPT for ONE file: + + `{{COMPARISON_FILE}}` + +You may use Write/Edit ONLY on that comparison file. Do not Edit, Write, or +NotebookEdit any other file. No `>` redirects, no `tee`, no `sed -i`, no +`cp`/`mv` into other locations. If a tool call would violate this, do NOT +make it — instead message `{{ORCHESTRATOR_NAME}}` via SendMessage and ask. + +You may freely Read, Grep, Glob across the repo — but the only files you NEED +to read are the two notes files listed under "Files to compare" below. + +## Goal +Diff the two researcher outputs per method and produce a structured report +that lets the user pick which notes drive downstream implementation at +Gate R-C. You do NOT grade correctness yourself — you surface deltas so the +user can grade. If asked to pick a winner in your report, refuse and defer to +the user. + +## Files to compare +- `{{NOTES_FILE}}` — legacy researcher output, grounded in raw XMI + PDF-text. +- `{{HYPHA_NOTES_FILE}}` — Hypha researcher output, grounded in + `hypha:metamodel-lookup` + `hypha:spec-citation`. + +Both files use the same per-method section layout — use that structure to +align the entries. + +## Per-method verdict schema +For each method, pick exactly ONE of: + +- **agree** — both researchers reached the same derivation, same dependencies, + same stub-blocker flags, same return-type shape. Minor prose wording + differences are fine. +- **disagree** — both cover the method but propose different derivations, + different C# code, different dependency sets, different stub-blocker + flags, or one flags an ambiguity the other resolved. One-line concern + required. +- **legacy-only** — the method appears in `{{NOTES_FILE}}` but not in + `{{HYPHA_NOTES_FILE}}` (or is empty on the Hypha side). +- **hypha-only** — the method appears in `{{HYPHA_NOTES_FILE}}` but not in + `{{NOTES_FILE}}` (or is empty on the legacy side). + +For **disagree** entries, add a one-line reason describing the specific delta: +- "different OCL translation: legacy uses `.Union(...)`, Hypha uses `SelectMany`" +- "different stub-blocker flag: legacy says upstream `X` is a stub, Hypha + doesn't mention it" +- "different spec citation: legacy cites clause 7.4.2, Hypha cites 7.4.3" +- "different dependency set: legacy includes `ownedMember`, Hypha uses + `OwnedRelationship.OfType()`" + +## Overall verdict schema +Roll the per-method verdicts up into ONE of: + +- **hypha stronger** — more coverage, tighter dependency sets, sharper spec + citations, fewer "not found" flags. +- **legacy stronger** — mirror of the above. +- **equivalent** — same conclusions across the board (most methods `agree`). +- **mixed** — some methods favor Hypha, others favor legacy; no clear winner. + +Back the overall verdict with counts: +`agree: N, disagree: N, legacy-only: N, hypha-only: N`. + +## Output format +Write to `{{COMPARISON_FILE}}` (overwrite is fine — this file is regenerated +per run). Structure: + +```markdown +# Comparison: {{PRODUCTION_FILE}} + +## Summary +- Overall verdict: +- Counts: agree=N, disagree=N, legacy-only=N, hypha-only=N +- Legacy notes: {{NOTES_FILE}} +- Hypha notes: {{HYPHA_NOTES_FILE}} + +## Per-method deltas + +### +- Verdict: +- Concern (if disagree): +- Legacy derivation: +- Hypha derivation: +``` + +Cap the whole file at ~200 lines. If two researchers wrote lengthy +per-method sections, distill each to the ONE-LINE derivation paraphrase for +the report — the full text lives in the two source notes files. + +## When done +Send a SendMessage to `{{ORCHESTRATOR_NAME}}` with summary `comparison ready` +and a compact payload: +- Overall verdict + counts. +- Top 3 disagreements by concern severity (materiality — flag anything that + would produce measurably different C# code or test coverage). +- Any "researcher missing entire methods" flags. + +Do NOT include a recommendation on which notes to pick. The user chooses at +Gate R-C. + +Begin by reading `{{NOTES_FILE}}` and `{{HYPHA_NOTES_FILE}}`, then writing +the report. +``` + +--- + ## Role prompt: implementer +The `{{ACTIVE_NOTES_FILE}}` placeholder resolves to either `{{NOTES_FILE}}` +(legacy researcher's notes) or `{{HYPHA_NOTES_FILE}}` (Hypha researcher's notes), +based on the user's Gate R-C pick when Hypha is installed. In legacy-only runs +(no Hypha plugin) it is always `{{NOTES_FILE}}`. The orchestrator substitutes +the concrete path before spawning the implementer. + ``` You are the **implementer** on the `{{TEAM_NAME}}` team. @@ -355,10 +642,10 @@ on operations like `DirectionOf`; Tier 4 = closures with cycle protection. Imple in tier order.) ## Implementation rules -1. **Read `{{NOTES_FILE}}` first** — the researcher has already extracted the - derivation source for each method (OCL body when present, prose + spec - citation when not). Then cross-check against the method's `` block - in `{{PRODUCTION_FILE}}`. +1. **Read `{{ACTIVE_NOTES_FILE}}` first** — the researcher has already + extracted the derivation source for each method (OCL body when present, + prose + spec citation when not). Then cross-check against the method's + `` block in `{{PRODUCTION_FILE}}`. 2. **Match the canonical coding style** (see template's "Coding conventions" section above). 3. **Null-check uniformly**: every method must throw @@ -398,8 +685,8 @@ Send a SendMessage to `{{ORCHESTRATOR_NAME}}` with: whose OCL referenced a still-stubbed sibling (and how you handled it), and any build warnings you introduced. -Begin by reading `{{NOTES_FILE}}`, then the method `` blocks in -{{PRODUCTION_FILE}}, then the reference template ({{REFERENCE_PRODUCTION_FILE}}), +Begin by reading `{{ACTIVE_NOTES_FILE}}`, then the method `` blocks +in {{PRODUCTION_FILE}}, then the reference template ({{REFERENCE_PRODUCTION_FILE}}), then making the edits. ``` @@ -509,8 +796,8 @@ Send a SendMessage to `{{ORCHESTRATOR_NAME}}` with: upstream stub is the blocker), any methods where the populated case is weaker than ideal because a richer fixture is needed, and any anticipated test failures. -Begin by reading `{{NOTES_FILE}}` (each method has a "Test plan" section), the -production methods you need to test, the reference fixture +Begin by reading `{{ACTIVE_NOTES_FILE}}` (each method has a "Test plan" +section), the production methods you need to test, the reference fixture (`{{REFERENCE_TEST_FILE}}`), the current `{{TEST_FILE}}`, then making the edits. ``` @@ -532,16 +819,17 @@ You are FULLY READ-ONLY. No Edit, no Write, no NotebookEdit, no Bash with `>` / If a tool call would violate this, do NOT make it. ## Files to review -1. `{{NOTES_FILE}}` — researcher's contract notes. This is the contract you - verify the implementation and tests against. For each method, note whether - the derivation source is OCL or spec-text-only. +1. `{{ACTIVE_NOTES_FILE}}` — the picked researcher's contract notes (legacy + or Hypha, depending on Gate R-C). This is the contract you verify the + implementation and tests against. For each method, note whether the + derivation source is OCL or spec-text-only. 2. `{{PRODUCTION_FILE}}` — newly implemented `Compute*` methods. Each method should faithfully implement either (a) the OCL body in its `` block - or (b) the prose derivation in `{{NOTES_FILE}}` (for spec-text-only + or (b) the prose derivation in `{{ACTIVE_NOTES_FILE}}` (for spec-text-only methods). Use the conventions in `{{REFERENCE_PRODUCTION_FILE}}`. 3. `{{TEST_FILE}}` — newly written/updated tests. Verify per-test that null-guard + empty + populated coverage matches the test plan in - `{{NOTES_FILE}}` for the method-under-test. + `{{ACTIVE_NOTES_FILE}}` for the method-under-test. ## OCL → C# translation checklist (per implemented method) @@ -632,6 +920,60 @@ re-dispatched by the orchestrator) will action your findings. --- +## How Hypha comparison plugs in + +Added on top of the v2 four-role core (researcher / implementer / tester / +reviewer) to A/B-validate the WIP Hypha plugin against the legacy +XMI-grounded researcher. Nothing about the four core roles changes when Hypha +is off — the two new roles are purely additive. + +**Activation**: the orchestrator detects the Hypha plugin at pre-flight (by +checking whether the `hypha:metamodel-lookup` skill / `hypha:metamodel-navigator` +agent is present in the current session's toolset). If installed, both +researchers run every invocation. If NOT installed, the orchestrator +recommends installing it once per invocation and, on refusal, falls back to +the legacy-only flow (no `hypha-researcher`, no `comparator`, no Gate R-C). + +**Two new roles**: + +- `hypha-researcher` — mirror of the legacy researcher's contract, grounded + EXCLUSIVELY via the Hypha plugin (`hypha:metamodel-lookup` + + `hypha:spec-citation` + `hypha:metamodel-navigator`). Prohibited from + reading `Resources/*.uml` and `Resources/specification/*.pdf.txt` — that + would collapse the two grounding paths into one and defeat the A/B + comparison. Notes-file target: `{{HYPHA_NOTES_FILE}}` + (`.team-notes/-extensions-spec-hypha.md`). +- `comparator` — read-only diff agent. Aligns the per-method sections of + `{{NOTES_FILE}}` and `{{HYPHA_NOTES_FILE}}`, emits a `agree` / + `disagree` / `legacy-only` / `hypha-only` verdict per method plus an + overall verdict, and writes a compact report to `{{COMPARISON_FILE}}` + (`.team-notes/-extensions-comparison.md`). Does NOT recommend a + winner — the user picks at Gate R-C. + +**No cross-contamination rule** (enforced in both new role prompts): + +- Legacy MUST NOT use the Hypha plugin skills. +- Hypha MUST NOT read raw XMI (`Resources/*.uml`) or the PDF-text files + (`Resources/specification/*.pdf.txt`). + +Both may read `{{PRODUCTION_FILE}}` (the C# signature is unavoidable), the +`{{INTERFACE_FILE}}`, and the `{{REFERENCE_PRODUCTION_FILE}}`. + +**Downstream driver — `{{ACTIVE_NOTES_FILE}}`**: at Gate R-C, the user picks +Hypha or legacy. The orchestrator substitutes the picked file's path for the +`{{ACTIVE_NOTES_FILE}}` placeholder before spawning implementer, tester, +and reviewer. The other-side notes file is kept on disk regardless — that is +the comparison corpus. + +**Corpus location**: `.team-notes/` (already gitignored at `.gitignore` +line `/.team-notes/*`). The three per-run files are: +- `-extensions-spec.md` (legacy) +- `-extensions-spec-hypha.md` (Hypha) +- `-extensions-comparison.md` (comparator) + +**Rationale**: this lets us build up an A/B corpus so the user can eventually +retire the legacy researcher once Hypha is proven end-to-end. + ## How to instantiate In a fresh conversation, when the user asks to implement methods in another From e8f09b8ef780d16a8d1bbab994e4212456d30dbf Mon Sep 17 00:00:00 2001 From: atheate Date: Tue, 28 Jul 2026 13:40:25 +0200 Subject: [PATCH 5/5] hypha grounding finalization --- .claude/team-templates/extension-impl.md | 515 ++++--------- CLAUDE.md | 18 +- .../1-Kernel_Modeling_Language.pdf.txt | 454 ------------ .../2a-OMG_Systems_Modeling_Language.pdf.txt | 691 ------------------ ...-Systems_Modeling_API_and_Services.pdf.txt | 107 --- ...sML v2 Language-Graphical Notation.pdf.txt | 123 ---- ...SysML v2 Language-Textual Notation.pdf.txt | 185 ----- 7 files changed, 151 insertions(+), 1942 deletions(-) delete mode 100644 Resources/specification/1-Kernel_Modeling_Language.pdf.txt delete mode 100644 Resources/specification/2a-OMG_Systems_Modeling_Language.pdf.txt delete mode 100644 Resources/specification/3-Systems_Modeling_API_and_Services.pdf.txt delete mode 100644 Resources/specification/Intro to the SysML v2 Language-Graphical Notation.pdf.txt delete mode 100644 Resources/specification/Intro to the SysML v2 Language-Textual Notation.pdf.txt diff --git a/.claude/team-templates/extension-impl.md b/.claude/team-templates/extension-impl.md index e2a1a16b..8ee4e3bc 100644 --- a/.claude/team-templates/extension-impl.md +++ b/.claude/team-templates/extension-impl.md @@ -49,42 +49,32 @@ Don't use this template when: | `{{REFERENCE_PRODUCTION_FILE}}` | Working reference (repo-relative) | `SysML2.NET/Extend/NamespaceExtensions.cs` | | `{{REFERENCE_TEST_FILE}}` | Working test reference (repo-relative) | `SysML2.NET.Tests/Extend/NamespaceExtensionsTestFixture.cs` | | `{{INTERFACE_FILE}}` | Auto-gen POCO interface (repo-relative) | `SysML2.NET/Core/AutoGenPoco/IFeature.cs` | -| `{{NOTES_FILE}}` | Legacy researcher's contract notes (repo-relative) | `.team-notes/feature-extensions-spec.md` | -| `{{HYPHA_NOTES_FILE}}` | Hypha researcher's contract notes (repo-relative, only when Hypha plugin installed) | `.team-notes/feature-extensions-spec-hypha.md` | -| `{{COMPARISON_FILE}}` | Comparator's diff report between legacy and Hypha notes (repo-relative, only when Hypha plugin installed) | `.team-notes/feature-extensions-comparison.md` | -| `{{ACTIVE_NOTES_FILE}}` | Whichever of `{{NOTES_FILE}}` / `{{HYPHA_NOTES_FILE}}` the user picked at Gate R-C (in Hypha-available runs) — or `{{NOTES_FILE}}` in legacy-only runs | `.team-notes/feature-extensions-spec-hypha.md` | +| `{{NOTES_FILE}}` | Researcher's contract notes (repo-relative) | `.team-notes/feature-extensions-spec.md` | +| `{{GROUNDING_MODE}}` | `hypha` when the Hypha plugin is installed (detected at pre-flight), else `xmi` | `hypha` | | `{{METHOD_LIST}}` | Bullet list of methods to implement, in dependency order | (per-task) | | `{{ORCHESTRATOR_NAME}}` | Team-lead name for SendMessage | `team-lead` | ## Workflow ``` -1. Researcher → writes contract notes to {{NOTES_FILE}}, grounded in -(legacy) Resources/KerML_only_xmi.uml + Resources/SysML_only_xmi.uml - + Resources/specification/*.pdf.txt. ALWAYS RUN. - -1b. Hypha-researcher → writes parallel contract notes to {{HYPHA_NOTES_FILE}}, -(only when Hypha grounded in hypha:metamodel-lookup + hypha:spec-citation - plugin installed) ONLY (must NOT touch raw XMI or PDF-text files). - Spawned in parallel with (1). Independent — does NOT read - (1)'s output. - -1c. Comparator → READ-ONLY. Diffs {{NOTES_FILE}} vs {{HYPHA_NOTES_FILE}} -(only when Hypha per method; writes a report to {{COMPARISON_FILE}} and - plugin installed) surfaces a summary. The user picks which notes drive - downstream (Gate R-C). +1. Researcher → writes contract notes to {{NOTES_FILE}}. + Grounding depends on {{GROUNDING_MODE}}: + - hypha: hypha:metamodel-lookup + hypha:spec-citation + (+ hypha:metamodel-navigator agent for fan-out, + hypha:sysml-validation when useful) + - xmi: Resources/KerML_only_xmi.uml + + Resources/SysML_only_xmi.uml only 2. Implementer → implements all methods in {{PRODUCTION_FILE}}, sliced by - dependency tier. Reads {{ACTIVE_NOTES_FILE}} first - (the user-picked notes file — legacy or Hypha). + dependency tier. Reads {{NOTES_FILE}} first. 3. Tester → rewrites {{TEST_FILE}} with one [Test] per method-under-test, multiple Assert.That covering - null + empty + populated. Reads {{ACTIVE_NOTES_FILE}} + null + empty + populated. Reads {{NOTES_FILE}} first for each method's test plan. 4. Reviewer → READ-ONLY verdict against the OCL blocks AND - {{ACTIVE_NOTES_FILE}}; flags any mistranslation; never edits. + {{NOTES_FILE}}; flags any mistranslation; never edits. 5. Orchestrator → dotnet build, targeted dotnet test, REGRESSION SWEEP (full solution test). Stub-blocker assertions in sibling @@ -96,23 +86,29 @@ Don't use this template when: The orchestrator MUST pass `mode: "acceptEdits"` explicitly on every `Agent(...)` spawn that uses this template. Reason: sub-agents inherit the parent's plan-mode state at spawn time; plan mode's built-in pre-tool-use -hook blocks `Skill(...)` calls, which makes the Hypha researcher's grounding -path unreachable AND blocks the sub-agent's `Write` of its notes/production/ -test file. `mode: "acceptEdits"` overrides the inheritance for that specific -sub-agent, letting it use `Skill(hypha:*)` and `Write` its allowed-write file -freely. The role prompts themselves are unchanged — this is a spawn-time -concern, not a prompt-time one. +hook blocks `Skill(...)` calls, which makes the researcher's Hypha grounding +path (when `{{GROUNDING_MODE}} == hypha`) unreachable AND blocks the +sub-agent's `Write` of its notes/production/test file. `mode: "acceptEdits"` +overrides the inheritance for that specific sub-agent, letting it use +`Skill(hypha:*)` and `Write` its allowed-write file freely. The role prompts +themselves are unchanged — this is a spawn-time concern, not a prompt-time one. + +If a `Skill(hypha:*)` call is still denied inside the sub-agent, the +researcher must NOT fall back to reading raw sources on its own — it messages +the orchestrator, which performs the Hypha lookup from its own context and +returns the result via SendMessage (or, if the researcher is wedged, writes +the notes file itself). The section below ("Plan-mode-aware prompting") documents the FALLBACK path used when the orchestrator itself is in plan mode and cannot bypass the sub-agent's inherited restriction. That fallback stays as insurance but is no longer the primary flow. -## Plan-mode-aware prompting (added 2026-05-28) +## Plan-mode-aware prompting (FALLBACK — added 2026-05-28) If the orchestrator session is in plan mode when this template is used, sub-agents -will inherit it and cannot apply edits. The Agent-tool `mode: "acceptEdits"` -parameter does NOT override the inherited state on the current Claude Code build. +will inherit it and cannot apply edits. On some Claude Code builds the Agent-tool +`mode: "acceptEdits"` parameter may not override the inherited state. Role prompts in this template are written so that the orchestrator can fall back to applying edits itself when this happens: @@ -163,21 +159,14 @@ Out-of-scope changes (refuse and surface): The Agent SDK has no per-file ACL, so each role's prompt restates the rule and tells the agent to refuse or escalate when a tool call would violate it. -- **Researcher (legacy)**: read-only everywhere except `{{NOTES_FILE}}`. -- **Hypha-researcher** (only when Hypha plugin installed): read-only - everywhere except `{{HYPHA_NOTES_FILE}}`. MUST NOT read - `Resources/KerML_only_xmi.uml`, `Resources/SysML_only_xmi.uml`, or - `Resources/specification/*.pdf.txt` — that would collapse the two - grounding paths into one and defeat the A/B comparison. -- **Comparator** (only when Hypha plugin installed): FULLY READ-ONLY across - the repo — except for `{{COMPARISON_FILE}}` (the ONLY file it may Write). +- **Researcher**: read-only everywhere except `{{NOTES_FILE}}`. - **Implementer**: read-only everywhere except `{{PRODUCTION_FILE}}`. MUST read - `{{ACTIVE_NOTES_FILE}}` before starting. + `{{NOTES_FILE}}` before starting. - **Tester**: read-only everywhere except `{{TEST_FILE}}`. MUST read - `{{ACTIVE_NOTES_FILE}}` before starting. + `{{NOTES_FILE}}` before starting. - **Reviewer**: read-only everywhere — no Write/Edit at all. Cross-checks both - `{{PRODUCTION_FILE}}` against `{{ACTIVE_NOTES_FILE}}` and `{{TEST_FILE}}` - against the test plans in `{{ACTIVE_NOTES_FILE}}`. + `{{PRODUCTION_FILE}}` against `{{NOTES_FILE}}` and `{{TEST_FILE}}` + against the test plans in `{{NOTES_FILE}}`. No `>` redirects, `tee`, `sed -i`, `cp`, or `mv` into files outside the allowed target. If a tool call would violate the rule, the agent must abort and message @@ -272,15 +261,14 @@ hand-reformat of `FeatureExtensions.cs`. All four roles must enforce these. --- -## Role prompt: researcher — legacy (DEFAULT — always run) +## Role prompt: researcher -Grounded in the raw XMI + `Resources/specification/*.pdf.txt` files that live in -the repo. Runs unconditionally on every invocation. When the Hypha plugin is -installed, this researcher runs in parallel with the `hypha-researcher` role -below (independent contexts, no cross-contamination). +One researcher per run. The orchestrator includes exactly ONE of the two +"Grounding" sections below, selected by `{{GROUNDING_MODE}}` from the +pre-flight detection (`hypha` when the Hypha plugin is installed, else `xmi`). ``` -You are the **legacy spec-researcher** on the `{{TEAM_NAME}}` team. +You are the **spec-researcher** on the `{{TEAM_NAME}}` team. ## Hard rule on file edits You are READ-ONLY across the entire repository EXCEPT for ONE file: @@ -303,17 +291,69 @@ so be specific about types, navigation, edge cases, and the derivation source. **Order of preference for the derivation source** (use the first that exists): 1. **OCL body in the XMI** — `` for derived properties, - `` body for operations. This is the canonical source. + `` body for operations. This is the canonical source. In `hypha` + mode, retrieve it via `hypha:metamodel-lookup` (do not open the XMI unless a + lookup fails); in `xmi` mode, grep the XMI directly. 2. **OCL block in the method's `` XML doc** in `{{PRODUCTION_FILE}}`. These are mirrored from the XMI by the codegen — quote them in the notes. -3. **Spec-text-only methods** — when neither (1) nor (2) carries an OCL body +3. **Methods with no OCL body** — when neither (1) nor (2) carries an OCL body (e.g. `Type::isConjugated` says only "Indicates whether this Type has an - ownedConjugator"), record a short prose derivation rule plus a citation to - the spec PDF/text. EXPLICITLY FLAG these in the notes so the implementer - doesn't search for OCL that isn't there. + ownedConjugator"): in `hypha` mode, record a short prose derivation rule + grounded in `hypha:spec-citation` and tag it with the clause; in `xmi` mode, + ground the prose rule in the XMI `ownedComment` / interface doc-comment + prose, EXPLICITLY FLAG it as `prose-only (no OCL; Hypha not installed)`, + and note it deserves extra scrutiny at Gate R-A. Either way, FLAG these in + the notes so the implementer doesn't search for OCL that isn't there. + +Do not skip the no-OCL case — that's the failure mode this researcher role +exists to prevent. + +## Grounding — hypha mode (orchestrator includes this section when {{GROUNDING_MODE}} == hypha) + +This is the CLAUDE.md "Grounding SysML v2 / KerML work with the Hypha plugin" +section applied to a researcher role: + +- **Structure (always)** — `hypha:metamodel-lookup` for each metaclass's: + - features (type, multiplicity, ordering, redefinitions, subsettings) + - supertypes and subtypes + - OCL derivation body (`` equivalent) + - OCL constraint bodies (`` equivalent) + - primitive types and enumerations referenced by the property + For cross-cutting fan-out (a chain that hops across several metaclasses, + e.g. "which metaclasses have a feature typed by Expression?"), delegate + to the `hypha:metamodel-navigator` agent so the bulk file reading stays + out of your context. + +- **Intent (when the OCL is not mechanical)** — `hypha:spec-citation` for + the normative spec prose whenever the OCL: + - is terse (`->first()` / `->at(1)` without a stated ordering) + - leans on a defined term (`namingFeature`, `redefinedFeature`, connector + `end`, feature typing/inheritance resolution) + - has an underspecified edge case + - otherwise needs interpretation beyond a mechanical filter + Skip only when the OCL is a plain `selectByKind(T)` / trivial filter. + +- **Validation (when useful)** — `hypha:sysml-validation` when you want to + confirm the C# translation you'd suggest matches the metamodel constraint + on a sample snippet. -Do not skip the spec-text-only case — that's the failure mode this researcher -role exists to prevent. +The checked-in XMI files (`Resources/KerML_only_xmi.uml`, +`Resources/SysML_only_xmi.uml`) remain available as a cross-check, but Hypha +is the primary source: prefer its answers, and FLAG any conflict between a +Hypha lookup and the raw XMI / `` block in the notes rather than +silently resolving it yourself. + +If a `Skill(hypha:*)` call is denied by the harness, do NOT silently fall +back to file reads — message `{{ORCHESTRATOR_NAME}}`, who will run the lookup +from the orchestrator context and return the result. + +## Grounding — xmi mode (orchestrator includes this section when {{GROUNDING_MODE}} == xmi) + +`Resources/KerML_only_xmi.uml` and `Resources/SysML_only_xmi.uml` are the ONLY +source of truth — structure, OCL bodies, and the `ownedComment` prose they +carry. Do NOT invent spec citations from prior knowledge of KerML/SysML v2 — +if the intent of a derivation cannot be established from the XMI, flag the +ambiguity in the notes instead of resolving it from memory. ## Methods to research {{METHOD_LIST}} @@ -323,13 +363,14 @@ role exists to prevent. metaclasses). Search for the property/operation name, then for the nearby `` or `` containing the body. - `Resources/SysML_only_xmi.uml` — for SysML-specific metaclasses. -- `Resources/specification/1-Kernel_Modeling_Language.pdf.txt` — - natural-language description of the same constraints. - `{{INTERFACE_FILE}}` — already-generated interface; doc-comments often contain the OCL prose. - `{{REFERENCE_PRODUCTION_FILE}}` — example of how derived properties are implemented in this codebase. +(In `hypha` mode the XMI bullets are cross-check only — the primary lookups go +through the Hypha skills.) + ## Implementation-readiness notes (per method) - Whether the implementation can use a sibling derived property that is itself stubbed (in which case the dev should bypass and filter `OwnedRelationship` @@ -345,270 +386,33 @@ role exists to prevent. discipline). The tester will assert `Throws.TypeOf()` for the populated case of any test whose populated path hits the blocker. +## Derivation-source tags +Tag every entry with exactly one of: +- `OCL in XMI` +- `OCL in ` +- `hypha:metamodel-lookup(::)` +- `hypha:spec-citation()` +- `prose-only (no OCL; Hypha not installed)` + ## Output format Append to `{{NOTES_FILE}}` (do NOT overwrite — the file may already contain entries from prior phases of this task). One section per method. See the v1 template for the -exact section structure. +exact section structure. Every section carries its derivation-source tag, the +suggested C# code block, a dependencies summary, a stub-blocker flag when +applicable, and any "not found" / ambiguity flag encountered. ## When done Send a SendMessage to `{{ORCHESTRATOR_NAME}}` with summary `spec ready` and a list -of methods where the OCL is ambiguous, missing, or transitively depends on other -stubbed extensions. - -Begin. -``` - ---- - -## Role prompt: hypha-researcher (ONLY when Hypha plugin installed) - -Mirror of the legacy researcher's contract, but grounded exclusively via the -Hypha plugin skills / agents (`hypha:metamodel-lookup`, `hypha:spec-citation`, -`hypha:metamodel-navigator`). Runs in parallel with the legacy researcher — -independent contexts, no cross-contamination. - -``` -You are the **hypha spec-researcher** on the `{{TEAM_NAME}}` team. - -## Hard rule on file edits -You are READ-ONLY across the entire repository EXCEPT for ONE file: - - `{{HYPHA_NOTES_FILE}}` - -You may use Write/Edit ONLY on that notes file. Do not Edit, Write, or -NotebookEdit any .cs, .uml, .xmi, .json, .csproj, .md, or any other file in the -repo. Do not use Bash to create or modify any other file (no `>` redirects, no -`tee`, no `sed -i`, no `cp`/`mv` into source). If a tool call would violate -this, do NOT make it — instead message `{{ORCHESTRATOR_NAME}}` via SendMessage -and ask. - -## Hard rule on grounding sources -You MUST ground exclusively in the Hypha plugin's outputs. This is the whole -point of the role — you are the A/B counterpart to the legacy researcher, and -the comparison is meaningless if you also read the same raw sources. - -**Forbidden reads** (any of these collapses the two paths into one): -- `Resources/KerML_only_xmi.uml` -- `Resources/SysML_only_xmi.uml` -- `Resources/specification/1-Kernel_Modeling_Language.pdf.txt` -- `Resources/specification/2a-OMG_Systems_Modeling_Language.pdf.txt` -- `Resources/specification/3-Systems_Modeling_API_and_Services.pdf.txt` -- `Resources/specification/Intro to the SysML v2 Language-Textual Notation.pdf.txt` -- `Resources/specification/Intro to the SysML v2 Language-Graphical Notation.pdf.txt` -- Any other `.pdf.txt` / `.pdf` / `.uml` / `.xmi` under `Resources/`. - -**Allowed reads**: -- Every Hypha skill and Hypha agent: `hypha:metamodel-lookup`, - `hypha:spec-citation`, `hypha:sysml-validation`, and the deep agents - `hypha:metamodel-navigator`, `hypha:spec-citation`, `hypha:sysml-validator`. -- The production file `{{PRODUCTION_FILE}}` — but ONLY for the C# signatures - of the methods listed below. The `` OCL block that appears in that - file is a codegen artifact of the same XMI you are forbidden to read - directly; treat it as informational (you can see it because you must read - the signature) but do NOT use it as your derivation source. Every claim in - your notes must be traceable back to a Hypha lookup, not the `` - block. -- The reference production file `{{REFERENCE_PRODUCTION_FILE}}` — for - canonical C# style / null-check patterns only. Do NOT copy OCL from there. -- The auto-generated interface `{{INTERFACE_FILE}}` — for the property - signature and return type. Do NOT use its doc-comment OCL as derivation. - -If a Hypha lookup returns "not found" or is ambiguous, EXPLICITLY FLAG that -in the notes rather than silently falling back to the forbidden sources. - -## Goal -For each method in the list below, produce a contract entry in -`{{HYPHA_NOTES_FILE}}` that mirrors the legacy researcher's output format -exactly (same section layout, same fields), so the comparator agent can diff -them structurally. - -**Grounding methodology** — this is the CLAUDE.md "Grounding SysML v2 / KerML -work with the Hypha plugin" section applied to a researcher role: - -- **Structure (always)** — `hypha:metamodel-lookup` for each metaclass's: - - features (type, multiplicity, ordering, redefinitions, subsettings) - - supertypes and subtypes - - OCL derivation body (`` equivalent) - - OCL constraint bodies (`` equivalent) - - primitive types and enumerations referenced by the property - For cross-cutting fan-out (a chain that hops across several metaclasses, - e.g. "which metaclasses have a feature typed by Expression?"), delegate - to the `hypha:metamodel-navigator` agent so the bulk file reading stays - out of your context. - -- **Intent (when the OCL is not mechanical)** — `hypha:spec-citation` for - the normative spec prose whenever the OCL: - - is terse (`->first()` / `->at(1)` without a stated ordering) - - leans on a defined term (`namingFeature`, `redefinedFeature`, connector - `end`, feature typing/inheritance resolution) - - has an underspecified edge case - - otherwise needs interpretation beyond a mechanical filter - Skip only when the OCL is a plain `selectByKind(T)` / trivial filter. - -- **Validation (when useful)** — `hypha:sysml-validation` (or the - `hypha:sysml-validator` agent) when you want to confirm the C# translation - you'd suggest matches the metamodel constraint on a sample snippet. - -## Methods to research -{{METHOD_LIST}} - -## Output format -Append to `{{HYPHA_NOTES_FILE}}` (do NOT overwrite — same rule as the legacy -researcher). One section per method, using EXACTLY the same section layout as -the legacy researcher so the comparator can align them side-by-side: - -- Method signature line. -- **Derivation source tag** — `hypha:metamodel-lookup(::)`, - `hypha:spec-citation()`, or `spec-text only via hypha` when the - Hypha spec-citation is what carries the definition. NEVER `OCL in XMI` or - `OCL in ` — those are legacy-researcher-only tags. -- Suggested C# code block. -- Dependencies summary (sibling derived properties used; upstream stubs hit). -- Stub-blocker flag if applicable. -- Any Hypha "not found" / ambiguity flag encountered. - -If a Hypha lookup returns something that conflicts with what you'd expect -from your prior knowledge of KerML/SysML v2, prefer Hypha's answer and FLAG -the conflict in the notes — the comparator + user will judge whose grounding -is right. - -## When done -Send a SendMessage to `{{ORCHESTRATOR_NAME}}` with summary `hypha spec ready` -and a list of: -- methods where Hypha returned "not found" or an ambiguous answer, -- methods where you had to fall back to a spec-citation because the metamodel - lookup was insufficient, -- methods where Hypha's answer differs from what the `` OCL block - suggests (flag WITHOUT resolving — the comparator surfaces this). +of methods where the derivation is ambiguous, missing, or transitively depends on +other stubbed extensions (and, in hypha mode, any lookup that returned "not found"). Begin. ``` --- -## Role prompt: comparator (ONLY when Hypha plugin installed) - -READ-ONLY diff agent. Runs after both the legacy researcher and the -`hypha-researcher` return. Produces a per-method delta report and a batch-wide -summary; the user picks which notes drive downstream at Gate R-C. - -``` -You are the **comparator** on the `{{TEAM_NAME}}` team. - -## Hard rule on file edits -You are READ-ONLY across the entire repository EXCEPT for ONE file: - - `{{COMPARISON_FILE}}` - -You may use Write/Edit ONLY on that comparison file. Do not Edit, Write, or -NotebookEdit any other file. No `>` redirects, no `tee`, no `sed -i`, no -`cp`/`mv` into other locations. If a tool call would violate this, do NOT -make it — instead message `{{ORCHESTRATOR_NAME}}` via SendMessage and ask. - -You may freely Read, Grep, Glob across the repo — but the only files you NEED -to read are the two notes files listed under "Files to compare" below. - -## Goal -Diff the two researcher outputs per method and produce a structured report -that lets the user pick which notes drive downstream implementation at -Gate R-C. You do NOT grade correctness yourself — you surface deltas so the -user can grade. If asked to pick a winner in your report, refuse and defer to -the user. - -## Files to compare -- `{{NOTES_FILE}}` — legacy researcher output, grounded in raw XMI + PDF-text. -- `{{HYPHA_NOTES_FILE}}` — Hypha researcher output, grounded in - `hypha:metamodel-lookup` + `hypha:spec-citation`. - -Both files use the same per-method section layout — use that structure to -align the entries. - -## Per-method verdict schema -For each method, pick exactly ONE of: - -- **agree** — both researchers reached the same derivation, same dependencies, - same stub-blocker flags, same return-type shape. Minor prose wording - differences are fine. -- **disagree** — both cover the method but propose different derivations, - different C# code, different dependency sets, different stub-blocker - flags, or one flags an ambiguity the other resolved. One-line concern - required. -- **legacy-only** — the method appears in `{{NOTES_FILE}}` but not in - `{{HYPHA_NOTES_FILE}}` (or is empty on the Hypha side). -- **hypha-only** — the method appears in `{{HYPHA_NOTES_FILE}}` but not in - `{{NOTES_FILE}}` (or is empty on the legacy side). - -For **disagree** entries, add a one-line reason describing the specific delta: -- "different OCL translation: legacy uses `.Union(...)`, Hypha uses `SelectMany`" -- "different stub-blocker flag: legacy says upstream `X` is a stub, Hypha - doesn't mention it" -- "different spec citation: legacy cites clause 7.4.2, Hypha cites 7.4.3" -- "different dependency set: legacy includes `ownedMember`, Hypha uses - `OwnedRelationship.OfType()`" - -## Overall verdict schema -Roll the per-method verdicts up into ONE of: - -- **hypha stronger** — more coverage, tighter dependency sets, sharper spec - citations, fewer "not found" flags. -- **legacy stronger** — mirror of the above. -- **equivalent** — same conclusions across the board (most methods `agree`). -- **mixed** — some methods favor Hypha, others favor legacy; no clear winner. - -Back the overall verdict with counts: -`agree: N, disagree: N, legacy-only: N, hypha-only: N`. - -## Output format -Write to `{{COMPARISON_FILE}}` (overwrite is fine — this file is regenerated -per run). Structure: - -```markdown -# Comparison: {{PRODUCTION_FILE}} - -## Summary -- Overall verdict: -- Counts: agree=N, disagree=N, legacy-only=N, hypha-only=N -- Legacy notes: {{NOTES_FILE}} -- Hypha notes: {{HYPHA_NOTES_FILE}} - -## Per-method deltas - -### -- Verdict: -- Concern (if disagree): -- Legacy derivation: -- Hypha derivation: -``` - -Cap the whole file at ~200 lines. If two researchers wrote lengthy -per-method sections, distill each to the ONE-LINE derivation paraphrase for -the report — the full text lives in the two source notes files. - -## When done -Send a SendMessage to `{{ORCHESTRATOR_NAME}}` with summary `comparison ready` -and a compact payload: -- Overall verdict + counts. -- Top 3 disagreements by concern severity (materiality — flag anything that - would produce measurably different C# code or test coverage). -- Any "researcher missing entire methods" flags. - -Do NOT include a recommendation on which notes to pick. The user chooses at -Gate R-C. - -Begin by reading `{{NOTES_FILE}}` and `{{HYPHA_NOTES_FILE}}`, then writing -the report. -``` - ---- - ## Role prompt: implementer -The `{{ACTIVE_NOTES_FILE}}` placeholder resolves to either `{{NOTES_FILE}}` -(legacy researcher's notes) or `{{HYPHA_NOTES_FILE}}` (Hypha researcher's notes), -based on the user's Gate R-C pick when Hypha is installed. In legacy-only runs -(no Hypha plugin) it is always `{{NOTES_FILE}}`. The orchestrator substitutes -the concrete path before spawning the implementer. - ``` You are the **implementer** on the `{{TEAM_NAME}}` team. @@ -642,7 +446,7 @@ on operations like `DirectionOf`; Tier 4 = closures with cycle protection. Imple in tier order.) ## Implementation rules -1. **Read `{{ACTIVE_NOTES_FILE}}` first** — the researcher has already +1. **Read `{{NOTES_FILE}}` first** — the researcher has already extracted the derivation source for each method (OCL body when present, prose + spec citation when not). Then cross-check against the method's `` block in `{{PRODUCTION_FILE}}`. @@ -685,7 +489,7 @@ Send a SendMessage to `{{ORCHESTRATOR_NAME}}` with: whose OCL referenced a still-stubbed sibling (and how you handled it), and any build warnings you introduced. -Begin by reading `{{ACTIVE_NOTES_FILE}}`, then the method `` blocks +Begin by reading `{{NOTES_FILE}}`, then the method `` blocks in {{PRODUCTION_FILE}}, then the reference template ({{REFERENCE_PRODUCTION_FILE}}), then making the edits. ``` @@ -796,7 +600,7 @@ Send a SendMessage to `{{ORCHESTRATOR_NAME}}` with: upstream stub is the blocker), any methods where the populated case is weaker than ideal because a richer fixture is needed, and any anticipated test failures. -Begin by reading `{{ACTIVE_NOTES_FILE}}` (each method has a "Test plan" +Begin by reading `{{NOTES_FILE}}` (each method has a "Test plan" section), the production methods you need to test, the reference fixture (`{{REFERENCE_TEST_FILE}}`), the current `{{TEST_FILE}}`, then making the edits. ``` @@ -819,17 +623,16 @@ You are FULLY READ-ONLY. No Edit, no Write, no NotebookEdit, no Bash with `>` / If a tool call would violate this, do NOT make it. ## Files to review -1. `{{ACTIVE_NOTES_FILE}}` — the picked researcher's contract notes (legacy - or Hypha, depending on Gate R-C). This is the contract you verify the - implementation and tests against. For each method, note whether the - derivation source is OCL or spec-text-only. +1. `{{NOTES_FILE}}` — the researcher's contract notes. This is the contract + you verify the implementation and tests against. For each method, note + whether the derivation source is OCL or a prose-only derivation. 2. `{{PRODUCTION_FILE}}` — newly implemented `Compute*` methods. Each method should faithfully implement either (a) the OCL body in its `` block - or (b) the prose derivation in `{{ACTIVE_NOTES_FILE}}` (for spec-text-only - methods). Use the conventions in `{{REFERENCE_PRODUCTION_FILE}}`. + or (b) the prose derivation in `{{NOTES_FILE}}` (for methods with no OCL + body). Use the conventions in `{{REFERENCE_PRODUCTION_FILE}}`. 3. `{{TEST_FILE}}` — newly written/updated tests. Verify per-test that null-guard + empty + populated coverage matches the test plan in - `{{ACTIVE_NOTES_FILE}}` for the method-under-test. + `{{NOTES_FILE}}` for the method-under-test. ## OCL → C# translation checklist (per implemented method) @@ -920,59 +723,35 @@ re-dispatched by the orchestrator) will action your findings. --- -## How Hypha comparison plugs in - -Added on top of the v2 four-role core (researcher / implementer / tester / -reviewer) to A/B-validate the WIP Hypha plugin against the legacy -XMI-grounded researcher. Nothing about the four core roles changes when Hypha -is off — the two new roles are purely additive. +## How Hypha grounding plugs in **Activation**: the orchestrator detects the Hypha plugin at pre-flight (by checking whether the `hypha:metamodel-lookup` skill / `hypha:metamodel-navigator` -agent is present in the current session's toolset). If installed, both -researchers run every invocation. If NOT installed, the orchestrator -recommends installing it once per invocation and, on refusal, falls back to -the legacy-only flow (no `hypha-researcher`, no `comparator`, no Gate R-C). - -**Two new roles**: - -- `hypha-researcher` — mirror of the legacy researcher's contract, grounded - EXCLUSIVELY via the Hypha plugin (`hypha:metamodel-lookup` + - `hypha:spec-citation` + `hypha:metamodel-navigator`). Prohibited from - reading `Resources/*.uml` and `Resources/specification/*.pdf.txt` — that - would collapse the two grounding paths into one and defeat the A/B - comparison. Notes-file target: `{{HYPHA_NOTES_FILE}}` - (`.team-notes/-extensions-spec-hypha.md`). -- `comparator` — read-only diff agent. Aligns the per-method sections of - `{{NOTES_FILE}}` and `{{HYPHA_NOTES_FILE}}`, emits a `agree` / - `disagree` / `legacy-only` / `hypha-only` verdict per method plus an - overall verdict, and writes a compact report to `{{COMPARISON_FILE}}` - (`.team-notes/-extensions-comparison.md`). Does NOT recommend a - winner — the user picks at Gate R-C. - -**No cross-contamination rule** (enforced in both new role prompts): - -- Legacy MUST NOT use the Hypha plugin skills. -- Hypha MUST NOT read raw XMI (`Resources/*.uml`) or the PDF-text files - (`Resources/specification/*.pdf.txt`). - -Both may read `{{PRODUCTION_FILE}}` (the C# signature is unavoidable), the -`{{INTERFACE_FILE}}`, and the `{{REFERENCE_PRODUCTION_FILE}}`. - -**Downstream driver — `{{ACTIVE_NOTES_FILE}}`**: at Gate R-C, the user picks -Hypha or legacy. The orchestrator substitutes the picked file's path for the -`{{ACTIVE_NOTES_FILE}}` placeholder before spawning implementer, tester, -and reviewer. The other-side notes file is kept on disk regardless — that is -the comparison corpus. - -**Corpus location**: `.team-notes/` (already gitignored at `.gitignore` -line `/.team-notes/*`). The three per-run files are: -- `-extensions-spec.md` (legacy) -- `-extensions-spec-hypha.md` (Hypha) -- `-extensions-comparison.md` (comparator) - -**Rationale**: this lets us build up an A/B corpus so the user can eventually -retire the legacy researcher once Hypha is proven end-to-end. +agent is present in the current session's toolset) and sets +`{{GROUNDING_MODE}}` accordingly: `hypha` when installed, `xmi` otherwise. + +**One researcher**: the single researcher role's prompt carries the grounding +section selected by `{{GROUNDING_MODE}}` — Hypha skills when installed, the +checked-in XMI metamodel otherwise. + +**When Hypha is not installed**: the orchestrator tells the user once, in one +or two lines, that installing the Hypha plugin is recommended for accurate +SysML v2 / KerML grounding, then proceeds in `xmi` mode without blocking. + +**Mid-run Hypha failure**: if a Hypha skill starts erroring partway through, +the researcher finishes the remaining methods in `xmi` mode, flags each +affected method in `{{NOTES_FILE}}`, and the orchestrator surfaces the +downgrade in the final summary. + +**Skill denied inside the sub-agent**: the researcher does not silently fall +back to file reads — it messages the orchestrator, which runs the Hypha +lookups from its own context and returns the results (or writes the notes +file itself). See "Sub-agent spawn mode" above. + +**Notes location**: `.team-notes/` (already gitignored at `.gitignore` line +`/.team-notes/*`); one file per run: `-extensions-spec.md`. Historical +`-extensions-spec-hypha.md` / `-extensions-comparison.md` files +from the retired A/B-comparison era are inert — leave them alone. ## How to instantiate diff --git a/CLAUDE.md b/CLAUDE.md index f69dae1c..6f2b7637 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -79,23 +79,13 @@ Generator classes in `SysML2.NET.CodeGenerator/Generators/UmlHandleBarsGenerator - Extension methods (Extend) → `SysML2.NET/Extend/` - DAL factories → `SysML2.NET.Dal/Core/` -### Formal specification references - -The XMI files (`Resources/KerML_only_xmi.uml`, `Resources/SysML_only_xmi.uml`) define the **structure** of the metamodel and the OCL constraints. The KEBNF files (`Resources/SysML-textual-bnf.kebnf`, `Resources/KerML-textual-bnf.kebnf`) define the **concrete textual syntax**. Neither narrates the *semantics* or *intent* of a metaclass, the rationale behind an OCL constraint, the contract of the REST API, or the idiomatic use of a notation construct. For that, this repo carries the formal OMG specification texts (PDF→text) under `Resources/specification/`. Treat them as cross-references — not as a generation input. - -- `Resources/specification/1-Kernel_Modeling_Language.pdf.txt` — *Kernel Modeling Language (KerML) Version 1.0* (OMG formal/2026-03-01). Consult when working with metaclasses in the `Root.*`, `Core.*`, and `Kernel.*` namespaces (under `SysML2.NET/Core/AutoGenDto/` and `AutoGenPoco/`), when an OCL constraint is unclear, or when reasoning about element/relationship/feature/classification semantics that the XMI does not spell out. -- `Resources/specification/2a-OMG_Systems_Modeling_Language.pdf.txt` — *OMG Systems Modeling Language (SysML) Version 2.0, Part 1: Language Specification* (OMG formal/2026-03-02). Consult when working with the systems-engineering-specific metaclasses in `Systems.*` namespaces — Parts, Ports, Connections, Interfaces, Actions, States, Interactions, Requirements, Constraints, Use Cases, Analysis/Verification Cases, Views, Metadata — and to ground the Definition/Usage pattern. -- `Resources/specification/3-Systems_Modeling_API_and_Services.pdf.txt` — *Systems Modeling API and Services Version 1.0* (OMG formal/2026-03-04). Consult when working in `SysML2.NET.REST/`, `SysML2.NET/PIM/`, `SysML2.NET.Serializer.Dictionary/`, or `SysML2.NET/ModelInterchange/`. Defines the Platform-Independent Model (ProjectService, ElementNavigationService, ProjectDataVersioningService, QueryService, ExternalRelationshipService, ProjectUsageService) and the REST/HTTP and OSLC PSMs. -- `Resources/specification/Intro to the SysML v2 Language-Textual Notation.pdf.txt` — SST tutorial, Release 2026-03. Informative companion to the KEBNF grammar; consult for canonical examples and idioms when implementing or reviewing rules under `SysML2.NET.Serializer.TextualNotation/Writers/` and `SysML2.NET/LexicalRules/`. -- `Resources/specification/Intro to the SysML v2 Language-Graphical Notation.pdf.txt` — SST tutorial, Release 2026-03. Consult when working on `SysML2.NET.Viewer/` (Blazor) for the visual-rendering conventions of each metaclass family. - -These text files are large (PDF-converted, up to 1.3 MB) and the conversion is not always clean. Read them with `Read` `offset`/`limit` and use `Grep` to jump to chapter/section anchors (e.g. `^7\.\d+`, `Clause 8\.`, or a metaclass name) rather than loading whole files into context. - ### Grounding SysML v2 / KerML work with the Hypha plugin -If the **Hypha** plugin is installed, treat it as the grounding step **before** implementing or reviewing anything that depends on the SysML v2 / KerML metamodel — do not rely on a sibling analogue, the doc-comment OCL, or prior knowledge as the source of truth. The metamodel is large and precise; a plausible prior is exactly what produces confident-but-wrong derivations. +If the **Hypha** plugin is installed, it is the **preferred grounding source for every SysML v2 / KerML semantic question** — metamodel structure (`hypha:metamodel-lookup`, or the `hypha:metamodel-navigator` agent for cross-cutting fan-out), normative specification intent (`hypha:spec-citation`), and textual-notation validity (`hypha:sysml-validation`). Use it **before** implementing or reviewing anything that depends on the SysML v2 / KerML metamodel — do not rely on a sibling analogue, the doc-comment OCL, or prior knowledge as the source of truth. The metamodel is large and precise; a plausible prior is exactly what produces confident-but-wrong derivations. + +This repository does **not** carry the OMG specification texts. Spec-intent lookups go through `hypha:spec-citation`; cite spec content by document name and clause (e.g. "OMG SysML v2 spec, Clause 8.2.2.1.1"), never by a file path. -**If the Hypha plugin is *not* installed:** the first time a task in this session would benefit from this grounding (any of the situations below), inform the user once that the Hypha plugin exists and that installing it is recommended for accurate SysML v2 / KerML work — it surfaces the metamodel structure and normative spec text on demand. Then proceed using the checked-in sources as the fallback source of truth: the XMI metamodel (`Resources/KerML_only_xmi.uml`, `Resources/SysML_only_xmi.uml`) for structure and OCL, and `Resources/specification/` for intent. Do not repeat the recommendation on every subsequent task. +**If the Hypha plugin is *not* installed:** the fallback source of truth is the XMI metamodel only — `Resources/KerML_only_xmi.uml` and `Resources/SysML_only_xmi.uml` — for structure, OCL bodies, and the `ownedComment` prose they carry. The first time a task in the session would have benefited from Hypha grounding (any of the situations below), tell the user once, in one or two lines, that installing the Hypha plugin is recommended for accurate SysML v2 / KerML work; then proceed with the XMI. Do not repeat the recommendation on every subsequent task. This applies whenever you are about to: - implement or modify a `Compute*` derived-property / OCL computation under `SysML2.NET/Extend/`, diff --git a/Resources/specification/1-Kernel_Modeling_Language.pdf.txt b/Resources/specification/1-Kernel_Modeling_Language.pdf.txt deleted file mode 100644 index b6224c92..00000000 --- a/Resources/specification/1-Kernel_Modeling_Language.pdf.txt +++ /dev/null @@ -1,454 +0,0 @@ -® An OMG Systems Modeling Publication Kernel Modeling Language™ (KerML™) Version 1.0 _______________________________________________________________________________ OMG Document Number: formal/2026-03-01 Date: March 2026 Standard document URL: https://www.omg.org/spec/KerML/1.0/ _______________________________________________________________________________ - -Copyright © 2019-2025, 88solutions Corporation Copyright © 2023-2025, Adaptive Analytics, Inc. Copyright © 2023-2025, Aerospace Corporation Copyright © 2019-2025, Airbus Copyright © 2023-2025, Ansys Government Initiatives Copyright © 2019-2025, Aras Corporation Copyright © 2019-2025, Association of Universities for Research in Astronomy (AURA) Copyright © 2019-2025, BigLever Software Copyright © 2019-2025, Boeing Copyright © 2022-2025, Budapest University of Technology and Economics Copyright © 2021-2025, Commissariat à l'énergie atomique et aux énergies alternatives (CEA) Copyright © 2019-2025, Contact Software GmbH Copyright © 2019-2025, Dassault Systèmes (No Magic) Copyright © 2019-2025, DSC Corporation Copyright © 2020-2025, DEKonsult Copyright © 2020-2025, Delligatti Associates LLC Copyright © 2019-2025, The Charles Stark Draper Laboratory, Inc. Copyright © 2024-2025, Elemental Reasoning Copyright © 2020-2025, ESTACA Copyright © 2023-2025, Galois, Inc. Copyright © 2019-2025, GfSE e.V. Copyright © 2019-2025, George Mason University Copyright © 2019-2025, IBM Copyright © 2019-2025, Idaho National Laboratory Copyright © 2019-2025, INCOSE Copyright © 2023-2024, IncQuery Labs cPlc Copyright © 2019-2025, Intercax LLC Copyright © 2019-2025, Jet Propulsion Laboratory (California Institute of Technology) Copyright © 2019-2025, Kenntnis LLC Copyright © 2020-2025, Kungliga Tekniska högskolon (KTH) Copyright © 2019-2025, LightStreet Consulting LLC Copyright © 2019-2025, Lockheed Martin Corporation Copyright © 2019-2025, Maplesoft Copyright © 2021-2025, MID GmbH Copyright © 2020-2025, MITRE Copyright © 2019-2025, Model Alchemy Consulting Copyright © 2019-2025, Model Driven Solutions, Inc. Copyright © 2019-2025, Model Foundry Pty. Ltd. Copyright © 2023-2025, Object Management Group, Inc. Copyright © 2019-2025, On-Line Application Research Corporation (OAC) Copyright © 2024-2025, OntoAge Copyright © 2024-2025, Ontogenesis Copyright © 2019-2025, oose eG Copyright © 2019-2025, Østfold University College Copyright © 2019-2025, PTC Copyright © 2020-2025, Qualtech Systems, Inc. Copyright © 2024-2025, Rocket Software Copyright © 2023-2025, RTX Copyright © 2019-2025, SAF Consulting Copyright © 2024-2025, Sensmetry Copyright © 2023-2025, Siemens Copyright © 2023-2025, Sierra Nevada Copyright © 2019-2025, Simula Research Laboratory AS Copyright © 2023-2025, Sparx Systems Copyright © 2024-2025, Systems and Software Engineering Group -Copyright © 2019-2025, System Strategy, Inc. Copyright © 2019-2025, Thematix Partners, LLC Copyright © 2019-2025, Tom Sawyer Copyright © 2023-2025, Tucson Embedded Systems, Inc. Copyright © 2019-2025, Universidad de Cantabria Copyright © 2019-2025, University of Alabama in Huntsville Copyright © 2023-2025, University of Arizona Copyright © 2019-2025, University of Detroit Mercy Copyright © 2019-2025, University of Kaiserslauten Copyright © 2020-2025, Willert Software Tools GmbH (SodiusWillert) -USE OF SPECIFICATION - TERMS, CONDITIONS & NOTICES The material in this document details an Object Management Group specification in accordance with the terms, conditions and notices set forth below. This document does not represent a commitment to implement any portion of this specification in any companys products. The information contained in this document is subject to change without notice. LICENSES The companies listed above have granted to the Object Management Group, Inc. (OMG) a nonexclusive, royalty-free, paid up, worldwide license to copy and distribute this document and to modify this document and distribute copies of the modified version. Each of the copyright holders listed above has agreed that no person shall be deemed to have infringed the copyright in the included material of any such copyright holder by reason of having used the specification set forth herein or having conformed any computer software to the specification. Subject to all of the terms and conditions below, the owners of the copyright in this specification hereby grant you a fully-paid up, non-exclusive, nontransferable, perpetual, worldwide license (without the right to sublicense), to use this specification to create and distribute software and special purpose specifications that are based upon this specification, and to use, copy, and distribute this specification as provided under the Copyright Act; provided that: (1) both the copyright notice identified above and this permission notice appear on any copies of this specification; (2) the use of the specifications is for informational purposes and will not be copied or posted on any network computer or broadcast in any media and will not be otherwise resold or transferred for commercial purposes; and (3) no modifications are made to this specification. This limited permission automatically terminates without notice if you breach any of these terms or conditions. Upon termination, you will destroy immediately any copies of the specifications in your possession or control. PATENTS The attention of adopters is directed to the possibility that compliance with or adoption of OMG specifications may require use of an invention covered by patent rights. OMG shall not be responsible for identifying patents for which a license may be required by any OMG specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. OMG specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. GENERAL USE RESTRICTIONS Any unauthorized use of this specification may violate copyright laws, trademark laws, and communications regulations and statutes. This document contains information which is protected by copyright. All Rights Reserved. No part of this work covered by copyright herein may be reproduced or used in any form or by any means--graphic, electronic, or mechanical, including photocopying, recording, taping, or information storage and retrieval systems--without permission of the copyright owner. DISCLAIMER OF WARRANTY WHILE THIS PUBLICATION IS BELIEVED TO BE ACCURATE, IT IS PROVIDED "AS IS" AND MAY CONTAIN ERRORS OR MISPRINTS. THE OBJECT MANAGEMENT GROUP AND THE COMPANIES LISTED ABOVE MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS PUBLICATION, INCLUDING BUT NOT LIMITED TO ANY WARRANTY OF TITLE OR -OWNERSHIP, IMPLIED WARRANTY OF MERCHANTABILITY OR WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE OR USE. IN NO EVENT SHALL THE OBJECT MANAGEMENT GROUP OR ANY OF THE COMPANIES LISTED ABOVE BE LIABLE FOR ERRORS CONTAINED HEREIN OR FOR DIRECT, INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, RELIANCE OR COVER DAMAGES, INCLUDING LOSS OF PROFITS, REVENUE, DATA OR USE, INCURRED BY ANY USER OR ANY THIRD PARTY IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS MATERIAL, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. The entire risk as to the quality and performance of software developed using this specification is borne by you. This disclaimer of warranty constitutes an essential part of the license granted to you to use this specification. RESTRICTED RIGHTS LEGEND Use, duplication or disclosure by the U.S. Government is subject to the restrictions set forth in subparagraph (c) (1) (ii) of The Rights in Technical Data and Computer Software Clause at DFARS 252.227-7013 or in subparagraph (c)(1) and (2) of the Commercial Computer Software - Restricted Rights clauses at 48 C.F.R. 52.227-19 or as specified in 48 C.F.R. 227-7202-2 of the DoD F.A.R. Supplement and its successors, or as specified in 48 C.F.R. 12.212 of the Federal Acquisition Regulations and its successors, as applicable. The specification copyright owners are as indicated above and may be contacted through the Object Management Group, 9C Medway Road, PMB 274, Milford, MA 01757, U.S.A. TRADEMARKS ® ® ® ® CORBA , CORBA logos , FIBO , Financial Industry Business Ontology , Financial Instrument Global ® ® ® ® ® ® ® Identifier , IIOP , IMM , Model Driven Architecture , MDA , Object Management Group , OMG , OMG ® ® ® ® ® ® ® Logo , SoaML , SOAML , SysML , UAF , Unified Modeling Language™, UML , UML Cube Logo , ® ® VSIPL , and XMI are registered trademarks of the Object Management Group, Inc. For a complete list of trademarks, see: https://www.omg.org/legal/tm_list.htm. All other products or company names mentioned are used for identification purposes only, and may be trademarks of their respective owners. COMPLIANCE The copyright holders listed above acknowledge that the Object Management Group (acting itself or through its designees) is and shall at all times be the sole entity that may authorize developers, suppliers and sellers of computer software to use certification marks, trademarks or other special designations to indicate compliance with these materials. Software developed under the terms of this license may claim compliance or conformance with this specification if and only if the software compliance is of a nature fully matching the applicable compliance points as stated in the specification. Software developed only partially matching the applicable compliance points may claim only that the software was based on this specification, but may not claim compliance or conformance with this specification. In the event that testing suites are implemented or approved by Object Management Group, Inc., software developed using this specification may claim compliance or conformance with the specification only if the software satisfactorily completes the testing suites. -OMG’S ISSUE REPORTING PROCEDURE All OMG specifications are subject to continuous review and improvement. As part of this process we encourage readers to report any ambiguities, inconsistencies, or inaccuracies they may find by completing the Issue Reporting Form listed on the main web page https://www.omg.org, under Documents, Report a Bug/Issue. - -Preface OMG Founded in 1989, the Object Management Group, Inc. (OMG) is an open membership, not-for-profit computer industry standards consortium that produces and maintains computer industry specifications for interoperable, portable, and reusable enterprise applications in distributed, heterogeneous environments. Membership includes Information Technology vendors, end users, government agencies, and academia. OMG member companies write, adopt, and maintain its specifications following a mature, open process. ® ® OMG’s specifications implement the Model Driven Architecture (MDA ), maximizing ROI through a full- lifecycle approach to enterprise integration that covers multiple operating systems, programming languages, middleware and networking infrastructures, and software development environments. OMG’s ® ® specifications include: UML (Unified Modeling Language™); CORBA (Common Object Request Broker Architecture); CWM™ (Common Warehouse Metamodel); and industry-specific standards for dozens of vertical markets. More information on the OMG is available at https://www.omg.org/. OMG Specifications As noted, OMG specifications address middleware, modeling, and vertical domain frameworks. All OMG Specifications are available from the OMG website at: https://www.omg.org/spec All of OMG’s formal specifications may be downloaded without charge from our website. (Products implementing OMG specifications are available from individual suppliers.) Copies of specifications, available in PostScript and PDF format, may be obtained from the Specifications Catalog cited above or by contacting the Object Management Group, Inc. at: OMG Headquarters 9C Medway Road, PMB 274 Milford, MA 01757 USA Tel: +1-781-444-0404 Fax: +1-781-444-0320 Email: pubs@omg.org Certain OMG specifications are also available as ISO standards. Please consult https://www.iso.org Issues All OMG specifications are subject to continuous review and improvement. As part of this process we encourage readers to report any ambiguities, inconsistencies, or inaccuracies they may find by completing the Issue Reporting Form listed on the main web page https://www.omg.org, under Specifications, Report an Issue. - -Table of Contents 1 Scope.................................................................................................................................................................................................1 2 Conformance.....................................................................................................................................................................................3 3 Normative References.......................................................................................................................................................................5 4 Terms and Definitions.......................................................................................................................................................................7 5 Symbols ............................................................................................................................................................................................9 6 Introduction.....................................................................................................................................................................................11 6.1 Language Architecture ........................................................................................................................................................11 6.2 Document Organization ......................................................................................................................................................11 6.3 Acknowledgements .............................................................................................................................................................12 7 Language Description .....................................................................................................................................................................15 7.1 Language Description Overview ........................................................................................................................................15 7.2 Root.....................................................................................................................................................................................15 7.2.1 Root Overview ........................................................................................................................................................15 7.2.2 Elements and Relationships ....................................................................................................................................15 7.2.2.1 Elements and Relationships Overview........................................................................................................15 7.2.2.2 Elements ......................................................................................................................................................16 7.2.2.3 Relationships ...............................................................................................................................................17 7.2.3 Dependencies ..........................................................................................................................................................17 7.2.3.1 Dependencies Overview..............................................................................................................................17 7.2.3.2 Dependency Declaration .............................................................................................................................18 7.2.4 Annotations .............................................................................................................................................................18 7.2.4.1 Annotations Overview.................................................................................................................................18 7.2.4.2 Comments and Documentation ...................................................................................................................19 7.2.4.3 Textual Representations ..............................................................................................................................20 7.2.5 Namespaces.............................................................................................................................................................21 7.2.5.1 Namespaces Overview ................................................................................................................................21 7.2.5.2 Namespace Declaration...............................................................................................................................21 7.2.5.3 Root Namespaces ........................................................................................................................................23 7.2.5.4 Imports ........................................................................................................................................................23 7.3 Core .....................................................................................................................................................................................25 7.3.1 Core Overview ........................................................................................................................................................25 7.3.2 Types .......................................................................................................................................................................26 7.3.2.1 Types Overview ..........................................................................................................................................26 7.3.2.2 Type Declaration .........................................................................................................................................26 7.3.2.3 Specialization ..............................................................................................................................................27 7.3.2.4 Conjugation .................................................................................................................................................28 7.3.2.5 Disjoining ....................................................................................................................................................29 7.3.2.6 Feature Membership....................................................................................................................................30 7.3.2.7 Unioning, Intersecting, and Differencing....................................................................................................30 7.3.3 Classifiers ................................................................................................................................................................31 7.3.3.1 Classifiers Overview ...................................................................................................................................31 7.3.3.2 Classifier Declaration ..................................................................................................................................31 7.3.3.3 Subclassification..........................................................................................................................................31 7.3.4 Features ...................................................................................................................................................................32 7.3.4.1 Features Overview.......................................................................................................................................32 7.3.4.2 Feature Declaration .....................................................................................................................................32 7.3.4.3 Feature Typing ............................................................................................................................................34 7.3.4.4 Subsetting ....................................................................................................................................................35 7.3.4.5 Redefinition .................................................................................................................................................36 7.3.4.6 Feature Chaining .........................................................................................................................................37 7.3.4.7 Feature Inverting .........................................................................................................................................38 7.3.4.8 Type Featuring ............................................................................................................................................39 7.4 Kernel..................................................................................................................................................................................40 7.4.1 Kernel Overview .....................................................................................................................................................40 Kernel Modeling Language v1.0 i -7.4.2 Data Types ..............................................................................................................................................................40 7.4.3 Classes.....................................................................................................................................................................41 7.4.4 Structures.................................................................................................................................................................42 7.4.5 Associations ............................................................................................................................................................42 7.4.5.1 Associations Overview................................................................................................................................42 7.4.5.2 Association Declaration ..............................................................................................................................43 7.4.5.3 Association Structures.................................................................................................................................45 7.4.6 Connectors...............................................................................................................................................................46 7.4.6.1 Connectors Overview ..................................................................................................................................46 7.4.6.2 Connector Declaration.................................................................................................................................47 7.4.6.3 Binding Connector Declaration...................................................................................................................50 7.4.6.4 Succession Declaration ...............................................................................................................................51 7.4.7 Behaviors.................................................................................................................................................................51 7.4.7.1 Behaviors Overview ....................................................................................................................................51 7.4.7.2 Behavior Declaration...................................................................................................................................52 7.4.7.3 Step Declaration ..........................................................................................................................................53 7.4.8 Functions .................................................................................................................................................................53 7.4.8.1 Functions Overview ....................................................................................................................................53 7.4.8.2 Function Declaration ...................................................................................................................................54 7.4.8.3 Expression Declaration ...............................................................................................................................55 7.4.8.4 Predicate Declaration ..................................................................................................................................56 7.4.8.5 Boolean Expression and Invariant Declaration ...........................................................................................56 7.4.9 Expressions .............................................................................................................................................................57 7.4.9.1 Expressions Overview.................................................................................................................................57 7.4.9.2 Operator Expressions ..................................................................................................................................57 7.4.9.3 Primary Expressions....................................................................................................................................59 7.4.9.4 Base Expressions.........................................................................................................................................61 7.4.9.5 Literal Expressions ......................................................................................................................................63 7.4.10 Interactions ............................................................................................................................................................64 7.4.10.1 Interactions Overview ...............................................................................................................................64 7.4.10.2 Interaction Declaration ..............................................................................................................................64 7.4.10.3 Flow Declaration .......................................................................................................................................64 7.4.11 Feature Values.......................................................................................................................................................66 7.4.12 Multiplicities .........................................................................................................................................................67 7.4.13 Metadata ................................................................................................................................................................68 7.4.14 Packages ................................................................................................................................................................71 8 Metamodel ......................................................................................................................................................................................73 8.1 Metamodel Overview..........................................................................................................................................................73 8.2 Concrete Syntax ..................................................................................................................................................................74 8.2.1 Concrete Syntax Overview .....................................................................................................................................74 8.2.2 Lexical Structure .....................................................................................................................................................75 8.2.2.1 Line Terminators and White Space .............................................................................................................75 8.2.2.2 Notes and Comments ..................................................................................................................................76 8.2.2.3 Names..........................................................................................................................................................76 8.2.2.4 Numeric Values...........................................................................................................................................77 8.2.2.5 String Value.................................................................................................................................................77 8.2.2.6 Reserved Words ..........................................................................................................................................77 8.2.2.7 Symbols .......................................................................................................................................................78 8.2.3 Root Concrete Syntax .............................................................................................................................................78 8.2.3.1 Elements and Relationships Concrete Syntax .............................................................................................78 8.2.3.2 Dependencies Concrete Syntax ...................................................................................................................78 8.2.3.3 Annotations Concrete Syntax......................................................................................................................79 8.2.3.3.1 Annotations .....................................................................................................................................79 8.2.3.3.2 Comments and Documentation .......................................................................................................79 8.2.3.3.3 Textual Representation....................................................................................................................80 ii Kernel Modeling Language v1.0 -8.2.3.4 Namespaces Concrete Syntax .....................................................................................................................80 8.2.3.4.1 Namespaces .....................................................................................................................................80 8.2.3.4.2 Imports.............................................................................................................................................81 8.2.3.4.3 Namespace Elements.......................................................................................................................82 8.2.3.5 Name Resolution .........................................................................................................................................82 8.2.3.5.1 Name Resolution Overview ............................................................................................................82 8.2.3.5.2 Local and Global Namespaces ........................................................................................................83 8.2.3.5.3 Local and Visible Resolution ..........................................................................................................85 8.2.3.5.4 Full Resolution ................................................................................................................................85 8.2.4 Core Concrete Syntax .............................................................................................................................................86 8.2.4.1 Types Concrete Syntax................................................................................................................................86 8.2.4.1.1 Types ...............................................................................................................................................86 8.2.4.1.2 Specialization ..................................................................................................................................86 8.2.4.1.3 Conjugation .....................................................................................................................................87 8.2.4.1.4 Disjoining ........................................................................................................................................87 8.2.4.1.5 Unioning, Intersecting and Differencing.........................................................................................87 8.2.4.1.6 Feature Membership........................................................................................................................88 8.2.4.2 Classifiers Concrete Syntax ........................................................................................................................88 8.2.4.2.1 Classifiers ........................................................................................................................................88 8.2.4.2.2 Subclassification..............................................................................................................................88 8.2.4.3 Features Concrete Syntax............................................................................................................................88 8.2.4.3.1 Features ...........................................................................................................................................88 8.2.4.3.2 Feature Typing ................................................................................................................................90 8.2.4.3.3 Subsetting ........................................................................................................................................90 8.2.4.3.4 Redefinition .....................................................................................................................................91 8.2.4.3.5 Feature Chaining .............................................................................................................................91 8.2.4.3.6 Feature Inverting .............................................................................................................................91 8.2.4.3.7 Type Featuring ................................................................................................................................91 8.2.5 Kernel Concrete Syntax ..........................................................................................................................................92 8.2.5.1 Data Types Concrete Syntax .......................................................................................................................92 8.2.5.2 Classes Concrete Syntax .............................................................................................................................92 8.2.5.3 Structures Concrete Syntax .........................................................................................................................92 8.2.5.4 Associations Concrete Syntax .....................................................................................................................92 8.2.5.5 Connectors Concrete Syntax .......................................................................................................................92 8.2.5.5.1 Connectors.......................................................................................................................................92 8.2.5.5.2 Binding Connectors .........................................................................................................................93 8.2.5.5.3 Successions......................................................................................................................................93 8.2.5.6 Behaviors Concrete Syntax .........................................................................................................................93 8.2.5.6.1 Behaviors.........................................................................................................................................93 8.2.5.6.2 Steps ................................................................................................................................................93 8.2.5.7 Functions Concrete Syntax..........................................................................................................................93 8.2.5.7.1 Functions .........................................................................................................................................93 8.2.5.7.2 Expressions......................................................................................................................................94 8.2.5.7.3 Predicates.........................................................................................................................................94 8.2.5.7.4 Boolean Expressions and Invariants................................................................................................94 8.2.5.8 Expressions Concrete Syntax ......................................................................................................................94 8.2.5.8.1 Operator Expressions ......................................................................................................................94 8.2.5.8.2 Primary Expressions........................................................................................................................99 8.2.5.8.3 Base Expressions ...........................................................................................................................101 8.2.5.8.4 Literal Expressions ........................................................................................................................102 8.2.5.9 Interactions Concrete Syntax ....................................................................................................................103 8.2.5.9.1 Interactions ....................................................................................................................................103 8.2.5.9.2 Flows .............................................................................................................................................103 8.2.5.10 Feature Values Concrete Syntax .............................................................................................................104 8.2.5.11 Multiplicities Concrete Syntax................................................................................................................104 8.2.5.12 Metadata Concrete Syntax ......................................................................................................................105 Kernel Modeling Language v1.0 iii -8.2.5.13 Packages Concrete Syntax ......................................................................................................................105 8.3 Abstract Syntax .................................................................................................................................................................106 8.3.1 Abstract Syntax Overview ....................................................................................................................................106 8.3.2 Root Abstract Syntax ............................................................................................................................................109 8.3.2.1 Elements and Relationships Abstract Syntax............................................................................................109 8.3.2.1.1 Overview .......................................................................................................................................109 8.3.2.1.2 Element..........................................................................................................................................109 8.3.2.1.3 Relationship...................................................................................................................................114 8.3.2.2 Dependencies Abstract Syntax..................................................................................................................115 8.3.2.2.1 Overview .......................................................................................................................................115 8.3.2.2.2 Dependency ...................................................................................................................................116 8.3.2.3 Annotations Abstract Syntax.....................................................................................................................117 8.3.2.3.1 Overview .......................................................................................................................................117 8.3.2.3.2 AnnotatingElement........................................................................................................................117 8.3.2.3.3 Annotation .....................................................................................................................................118 8.3.2.3.4 Comment .......................................................................................................................................120 8.3.2.3.5 Documentation ..............................................................................................................................120 8.3.2.3.6 TextualRepresentation...................................................................................................................121 8.3.2.4 Namespaces Abstract Syntax ....................................................................................................................123 8.3.2.4.1 Overview .......................................................................................................................................123 8.3.2.4.2 Import ............................................................................................................................................124 8.3.2.4.3 Membership...................................................................................................................................125 8.3.2.4.4 MembershipImport........................................................................................................................126 8.3.2.4.5 Namespace.....................................................................................................................................127 8.3.2.4.6 NamespaceImport..........................................................................................................................131 8.3.2.4.7 VisibilityKind................................................................................................................................131 8.3.2.4.8 OwningMembership......................................................................................................................132 8.3.3 Core Abstract Syntax ............................................................................................................................................134 8.3.3.1 Types Abstract Syntax ..............................................................................................................................134 8.3.3.1.1 Overview .......................................................................................................................................134 8.3.3.1.2 Conjugation ...................................................................................................................................137 8.3.3.1.3 Differencing...................................................................................................................................138 8.3.3.1.4 Disjoining ......................................................................................................................................138 8.3.3.1.5 FeatureDirectionKind....................................................................................................................139 8.3.3.1.6 FeatureMembership.......................................................................................................................139 8.3.3.1.7 Intersecting ....................................................................................................................................140 8.3.3.1.8 Specialization ................................................................................................................................140 8.3.3.1.9 Multiplicity....................................................................................................................................141 8.3.3.1.10 Type.............................................................................................................................................142 8.3.3.1.11 Unioning......................................................................................................................................151 8.3.3.2 Classifiers Abstract Syntax .......................................................................................................................152 8.3.3.2.1 Overview .......................................................................................................................................152 8.3.3.2.2 Classifier........................................................................................................................................152 8.3.3.2.3 Subclassification............................................................................................................................153 8.3.3.3 Features Abstract Syntax...........................................................................................................................154 8.3.3.3.1 Overview .......................................................................................................................................154 8.3.3.3.2 CrossSubsetting .............................................................................................................................157 8.3.3.3.3 EndFeatureMembership ................................................................................................................158 8.3.3.3.4 Feature ...........................................................................................................................................158 8.3.3.3.5 FeatureChaining ............................................................................................................................173 8.3.3.3.6 FeatureInverting ............................................................................................................................173 8.3.3.3.7 FeatureTyping ...............................................................................................................................174 8.3.3.3.8 Redefinition ...................................................................................................................................174 8.3.3.3.9 ReferenceSubsetting......................................................................................................................176 8.3.3.3.10 Subsetting ....................................................................................................................................176 8.3.3.3.11 TypeFeaturing .............................................................................................................................177 iv Kernel Modeling Language v1.0 -8.3.4 Kernel Abstract Syntax .........................................................................................................................................178 8.3.4.1 Data Types Abstract Syntax ......................................................................................................................178 8.3.4.1.1 Overview .......................................................................................................................................178 8.3.4.1.2 DataType .......................................................................................................................................178 8.3.4.2 Classes Abstract Syntax ............................................................................................................................179 8.3.4.2.1 Overview .......................................................................................................................................179 8.3.4.2.2 Class ..............................................................................................................................................179 8.3.4.3 Structures Abstract Syntax ........................................................................................................................180 8.3.4.3.1 Overview .......................................................................................................................................180 8.3.4.3.2 Structure ........................................................................................................................................180 8.3.4.4 Associations Abstract Syntax....................................................................................................................181 8.3.4.4.1 Overview .......................................................................................................................................181 8.3.4.4.2 Association ....................................................................................................................................181 8.3.4.4.3 AssociationStructure .....................................................................................................................183 8.3.4.5 Connectors Abstract Syntax ......................................................................................................................185 8.3.4.5.1 Overview .......................................................................................................................................185 8.3.4.5.2 Binding Connector ........................................................................................................................185 8.3.4.5.3 Connector ......................................................................................................................................186 8.3.4.5.4 Succession .....................................................................................................................................189 8.3.4.6 Behaviors Abstract Syntax ........................................................................................................................190 8.3.4.6.1 Overview .......................................................................................................................................190 8.3.4.6.2 Behavior ........................................................................................................................................191 8.3.4.6.3 Step................................................................................................................................................191 8.3.4.6.4 ParameterMembership...................................................................................................................193 8.3.4.7 Functions Abstract Syntax ........................................................................................................................194 8.3.4.7.1 Overview .......................................................................................................................................194 8.3.4.7.2 BooleanExpression ........................................................................................................................195 8.3.4.7.3 Expression .....................................................................................................................................195 8.3.4.7.4 Function.........................................................................................................................................198 8.3.4.7.5 Invariant.........................................................................................................................................199 8.3.4.7.6 Predicate ........................................................................................................................................200 8.3.4.7.7 ResultExpressionMembership.......................................................................................................200 8.3.4.7.8 ReturnParameterMembership........................................................................................................201 8.3.4.8 Expressions Abstract Syntax .....................................................................................................................202 8.3.4.8.1 Overview .......................................................................................................................................202 8.3.4.8.2 CollectExpression..........................................................................................................................202 8.3.4.8.3 ConstructorExpression ..................................................................................................................203 8.3.4.8.4 FeatureChainExpression................................................................................................................204 8.3.4.8.5 FeatureReferenceExpression .........................................................................................................206 8.3.4.8.6 IndexExpression ............................................................................................................................208 8.3.4.8.7 InstantiationExpression .................................................................................................................209 8.3.4.8.8 InvocationExpression ....................................................................................................................210 8.3.4.8.9 LiteralBoolean ...............................................................................................................................212 8.3.4.8.10 LiteralExpression.........................................................................................................................213 8.3.4.8.11 LiteralInfinity ..............................................................................................................................214 8.3.4.8.12 LiteralInteger ...............................................................................................................................214 8.3.4.8.13 LiteralRational.............................................................................................................................215 8.3.4.8.14 LiteralString.................................................................................................................................215 8.3.4.8.15 MetadataAccessExpression .........................................................................................................216 8.3.4.8.16 NullExpression ............................................................................................................................217 8.3.4.8.17 OperatorExpression .....................................................................................................................218 8.3.4.8.18 SelectExpression .........................................................................................................................218 8.3.4.9 Interactions Abstract Syntax .....................................................................................................................219 8.3.4.9.1 Overview .......................................................................................................................................219 8.3.4.9.2 Flow...............................................................................................................................................220 8.3.4.9.3 FlowEnd ........................................................................................................................................222 Kernel Modeling Language v1.0 v -8.3.4.9.4 Interaction......................................................................................................................................223 8.3.4.9.5 PayloadFeature ..............................................................................................................................223 8.3.4.9.6 SuccessionFlow .............................................................................................................................224 8.3.4.10 Feature Values Abstract Syntax ..............................................................................................................225 8.3.4.10.1 Overview .....................................................................................................................................225 8.3.4.10.2 FeatureValue ...............................................................................................................................225 8.3.4.11 Multiplicities Abstract Syntax.................................................................................................................227 8.3.4.11.1 Overview .....................................................................................................................................227 8.3.4.11.2 MultiplicityRange........................................................................................................................227 8.3.4.12 Metadata Abstract Syntax .......................................................................................................................230 8.3.4.12.1 Overview .....................................................................................................................................230 8.3.4.12.2 Metaclass .....................................................................................................................................230 8.3.4.12.3 MetadataFeature ..........................................................................................................................230 8.3.4.13 Packages Abstract Syntax .......................................................................................................................233 8.3.4.13.1 Overview .....................................................................................................................................233 8.3.4.13.2 ElementFilterMembership...........................................................................................................233 8.3.4.13.3 LibraryPackage............................................................................................................................234 8.3.4.13.4 Package........................................................................................................................................235 8.4 Semantics ..........................................................................................................................................................................236 8.4.1 Semantics Overview..............................................................................................................................................236 8.4.2 Semantic Constraints and Implied Relationships..................................................................................................237 8.4.3 Core Semantics......................................................................................................................................................239 8.4.3.1 Core Semantics Overview .........................................................................................................................239 8.4.3.1.1 Core Semantic Constraints ............................................................................................................239 8.4.3.1.2 Core Semantics Mathematical Preliminaries ................................................................................241 8.4.3.2 Types Semantics........................................................................................................................................243 8.4.3.3 Classifiers Semantics.................................................................................................................................244 8.4.3.4 Features Semantics ....................................................................................................................................244 8.4.4 Kernel Semantics ..................................................................................................................................................247 8.4.4.1 Kernel Semantics Overview......................................................................................................................247 8.4.4.2 Data Types Semantics ...............................................................................................................................253 8.4.4.3 Classes Semantics .....................................................................................................................................253 8.4.4.4 Structures Semantics .................................................................................................................................255 8.4.4.5 Associations Semantics .............................................................................................................................255 8.4.4.5.1 Associations...................................................................................................................................255 8.4.4.5.2 Association Structures ...................................................................................................................259 8.4.4.6 Connectors Semantics ...............................................................................................................................260 8.4.4.6.1 Connectors.....................................................................................................................................260 8.4.4.6.2 Binding Connectors .......................................................................................................................262 8.4.4.6.3 Successions....................................................................................................................................263 8.4.4.7 Behaviors Semantics .................................................................................................................................263 8.4.4.7.1 Behaviors.......................................................................................................................................263 8.4.4.7.2 Steps ..............................................................................................................................................263 8.4.4.8 Functions Semantics..................................................................................................................................264 8.4.4.8.1 Functions and Predicates ...............................................................................................................264 8.4.4.8.2 Expressions and Invariants ............................................................................................................265 8.4.4.9 Expressions Semantics ..............................................................................................................................266 8.4.4.9.1 Null Expressions............................................................................................................................266 8.4.4.9.2 Literal Expressions ........................................................................................................................266 8.4.4.9.3 Feature Reference Expressions .....................................................................................................266 8.4.4.9.4 Constructor Expressions................................................................................................................267 8.4.4.9.5 Invocation Expressions..................................................................................................................268 8.4.4.9.6 Operator Expressions ....................................................................................................................269 8.4.4.9.7 Metadata Access Expressions .......................................................................................................271 8.4.4.9.8 Model-Level Evaluable Expressions.............................................................................................271 vi Kernel Modeling Language v1.0 -8.4.4.10 Interactions Semantics.............................................................................................................................272 8.4.4.10.1 Interactions ..................................................................................................................................272 8.4.4.10.2 Flows ...........................................................................................................................................273 8.4.4.11 Feature Values Semantics .......................................................................................................................274 8.4.4.12 Multiplicities Semantics ..........................................................................................................................275 8.4.4.12.1 Multiplicities ...............................................................................................................................276 8.4.4.12.2 Multiplicity Ranges .....................................................................................................................277 8.4.4.13 Metadata Semantics.................................................................................................................................278 8.4.4.13.1 Metaclasses..................................................................................................................................278 8.4.4.13.2 Metadata Features........................................................................................................................278 8.4.4.13.3 Semantic Metadata ......................................................................................................................278 8.4.4.14 Packages Semantics.................................................................................................................................279 9 Model Libraries.............................................................................................................................................................................281 9.1 Model Libraries Overview ................................................................................................................................................281 9.2 Semantic Library...............................................................................................................................................................281 9.2.1 Semantic Library Overview ..................................................................................................................................281 9.2.2 Base .......................................................................................................................................................................282 9.2.2.1 Base Overview ..........................................................................................................................................282 9.2.2.2 Elements ....................................................................................................................................................282 9.2.2.2.1 Anything........................................................................................................................................282 9.2.2.2.2 DataValue ......................................................................................................................................283 9.2.2.2.3 dataValues .....................................................................................................................................283 9.2.2.2.4 exactlyOne.....................................................................................................................................284 9.2.2.2.5 naturals ..........................................................................................................................................284 9.2.2.2.6 oneToMany ...................................................................................................................................285 9.2.2.2.7 things .............................................................................................................................................285 9.2.2.2.8 zeroOrOne .....................................................................................................................................285 9.2.2.2.9 zeroToMany ..................................................................................................................................286 9.2.3 Links......................................................................................................................................................................286 9.2.3.1 Links Overview .........................................................................................................................................286 9.2.3.2 Elements ....................................................................................................................................................287 9.2.3.2.1 BinaryLink.....................................................................................................................................287 9.2.3.2.2 binaryLinks....................................................................................................................................287 9.2.3.2.3 Link ...............................................................................................................................................288 9.2.3.2.4 links ...............................................................................................................................................288 9.2.3.2.5 SelfLink .........................................................................................................................................288 9.2.3.2.6 selfLinks ........................................................................................................................................289 9.2.4 Occurrences...........................................................................................................................................................290 9.2.4.1 Occurrences Overview ..............................................................................................................................290 9.2.4.2 Elements ....................................................................................................................................................292 9.2.4.2.1 HappensBefore ..............................................................................................................................292 9.2.4.2.2 happensBeforeLinks ......................................................................................................................293 9.2.4.2.3 HappensDuring..............................................................................................................................293 9.2.4.2.4 HappensJustBefore ........................................................................................................................294 9.2.4.2.5 HappensLink .................................................................................................................................295 9.2.4.2.6 HappensWhile ...............................................................................................................................295 9.2.4.2.7 IncomingTransferSort ...................................................................................................................296 9.2.4.2.8 InnerSpaceOf.................................................................................................................................296 9.2.4.2.9 InsideOf .........................................................................................................................................297 9.2.4.2.10 JustOutsideOf ..............................................................................................................................297 9.2.4.2.11 Life ..............................................................................................................................................298 9.2.4.2.12 MatesWith ...................................................................................................................................298 9.2.4.2.13 Occurrence...................................................................................................................................299 9.2.4.2.14 occurrences ..................................................................................................................................305 9.2.4.2.15 OutsideOf ....................................................................................................................................305 9.2.4.2.16 PortionOf .....................................................................................................................................306 Kernel Modeling Language v1.0 vii -9.2.4.2.17 SelfSameLifeLink .......................................................................................................................306 9.2.4.2.18 SnapshotOf ..................................................................................................................................307 9.2.4.2.19 SpaceLink....................................................................................................................................308 9.2.4.2.20 SpaceShotOf................................................................................................................................308 9.2.4.2.21 SpaceSliceOf ...............................................................................................................................309 9.2.4.2.22 SurroundedBy..............................................................................................................................309 9.2.4.2.23 TimeSliceOf ................................................................................................................................310 9.2.4.2.24 Within ..........................................................................................................................................310 9.2.4.2.25 WithinBoth ..................................................................................................................................311 9.2.4.2.26 Without........................................................................................................................................312 9.2.5 Objects...................................................................................................................................................................312 9.2.5.1 Objects Overview ......................................................................................................................................312 9.2.5.2 Elements ....................................................................................................................................................313 9.2.5.2.1 BinaryLinkObject..........................................................................................................................313 9.2.5.2.2 binaryLinkObjects .........................................................................................................................314 9.2.5.2.3 Body ..............................................................................................................................................314 9.2.5.2.4 Curve .............................................................................................................................................314 9.2.5.2.5 LinkObject.....................................................................................................................................315 9.2.5.2.6 linkObjects.....................................................................................................................................315 9.2.5.2.7 Object ............................................................................................................................................316 9.2.5.2.8 objects............................................................................................................................................317 9.2.5.2.9 Point ..............................................................................................................................................317 9.2.5.2.10 StructuredSpaceObject ................................................................................................................317 9.2.5.2.11 Surface.........................................................................................................................................318 9.2.6 Performances.........................................................................................................................................................319 9.2.6.1 Performances Overview ............................................................................................................................319 9.2.6.2 Elements ....................................................................................................................................................320 9.2.6.2.1 BooleanEvaluation ........................................................................................................................320 9.2.6.2.2 booleanEvaluations .......................................................................................................................320 9.2.6.2.3 constructorEvaluations ..................................................................................................................320 9.2.6.2.4 Evaluation......................................................................................................................................321 9.2.6.2.5 evaluations.....................................................................................................................................321 9.2.6.2.6 falseEvaluations.............................................................................................................................322 9.2.6.2.7 InvolvedIn .....................................................................................................................................322 9.2.6.2.8 LiteralEvaluation ...........................................................................................................................323 9.2.6.2.9 literalEvaluations...........................................................................................................................323 9.2.6.2.10 MetadataAccessEvaluation .........................................................................................................323 9.2.6.2.11 metadataAccessEvaluations ........................................................................................................324 9.2.6.2.12 NullEvaluation.............................................................................................................................324 9.2.6.2.13 nullEvaluations ............................................................................................................................325 9.2.6.2.14 Performance.................................................................................................................................325 9.2.6.2.15 performances ...............................................................................................................................326 9.2.6.2.16 Performs ......................................................................................................................................326 9.2.6.2.17 trueEvaluations ............................................................................................................................327 9.2.7 Transfers................................................................................................................................................................327 9.2.7.1 Transfers Overview ...................................................................................................................................327 9.2.7.2 Elements ....................................................................................................................................................328 9.2.7.2.1 AcceptPerformance .......................................................................................................................328 9.2.7.2.2 FlowTransfer .................................................................................................................................329 9.2.7.2.3 FlowTransferBefore ......................................................................................................................329 9.2.7.2.4 flowTransfers.................................................................................................................................330 9.2.7.2.5 flowTransfersBefore......................................................................................................................330 9.2.7.2.6 MessageTransfer ...........................................................................................................................331 9.2.7.2.7 messageTransfers ..........................................................................................................................331 9.2.7.2.8 SendPerformance...........................................................................................................................331 9.2.7.2.9 Transfer .........................................................................................................................................332 viii Kernel Modeling Language v1.0 -9.2.7.2.10 TransferBefore.............................................................................................................................333 9.2.7.2.11 transfers .......................................................................................................................................333 9.2.7.2.12 transfersBefore ............................................................................................................................334 9.2.8 Feature Referencing Performances .......................................................................................................................334 9.2.8.1 Feature Referencing Performances Overview...........................................................................................334 9.2.8.2 Elements ....................................................................................................................................................334 9.2.8.2.1 BooleanEvaluationResultMonitorPerformance.............................................................................334 9.2.8.2.2 BooleanEvaluationResultToMonitorPerformance ........................................................................335 9.2.8.2.3 EvaluationResultMonitorPerformance ..........................................................................................336 9.2.8.2.4 FeatureAccessPerformance ...........................................................................................................336 9.2.8.2.5 FeatureMonitorPerformance .........................................................................................................337 9.2.8.2.6 FeatureReadEvaluation .................................................................................................................338 9.2.8.2.7 FeatureReferencingPerformance ...................................................................................................338 9.2.8.2.8 FeatureWritePerformance .............................................................................................................339 9.2.9 Control Performances............................................................................................................................................339 9.2.9.1 Control Performances Overview ...............................................................................................................339 9.2.9.2 Elements ....................................................................................................................................................340 9.2.9.2.1 DecisionPerformance ....................................................................................................................340 9.2.9.2.2 IfElsePerformance .........................................................................................................................341 9.2.9.2.3 IfPerformance ................................................................................................................................341 9.2.9.2.4 IfThenElsePerformance.................................................................................................................341 9.2.9.2.5 IfThenPerformance........................................................................................................................342 9.2.9.2.6 LoopPerformance ..........................................................................................................................342 9.2.9.2.7 MergePerformance ........................................................................................................................343 9.2.10 Transition Performances .....................................................................................................................................343 9.2.10.1 Transition Performances Overview.........................................................................................................343 9.2.10.2 Elements ..................................................................................................................................................344 9.2.10.2.1 NonStateTransitionPerformance .................................................................................................344 9.2.10.2.2 TPCGuardConstraint ...................................................................................................................345 9.2.10.2.3 TransitionPerformance ................................................................................................................345 9.2.11 State Performances..............................................................................................................................................346 9.2.11.1 State Performances Overview .................................................................................................................346 9.2.11.2 Elements ..................................................................................................................................................347 9.2.11.2.1 StatePerformance.........................................................................................................................347 9.2.11.2.2 StateTransitionPerformance ........................................................................................................348 9.2.12 Clocks..................................................................................................................................................................349 9.2.12.1 Clocks Overview .....................................................................................................................................349 9.2.12.2 Elements ..................................................................................................................................................349 9.2.12.2.1 BasicClock...................................................................................................................................349 9.2.12.2.2 BasicDurationOf..........................................................................................................................349 9.2.12.2.3 BasicTimeOf ...............................................................................................................................350 9.2.12.2.4 Clock ...........................................................................................................................................350 9.2.12.2.5 DurationOf...................................................................................................................................351 9.2.12.2.6 TimeOf ........................................................................................................................................351 9.2.12.2.7 universalClock.............................................................................................................................352 9.2.12.2.8 UniversalClockLife .....................................................................................................................352 9.2.13 Observation .........................................................................................................................................................353 9.2.13.1 Observation Overview.............................................................................................................................353 9.2.13.2 Elements ..................................................................................................................................................353 9.2.13.2.1 CancelObservation ......................................................................................................................353 9.2.13.2.2 ChangeMonitor............................................................................................................................353 9.2.13.2.3 ChangeSignal...............................................................................................................................354 9.2.13.2.4 defaultMonitor.............................................................................................................................354 9.2.13.2.5 DefaultMonitorLife .....................................................................................................................355 9.2.13.2.6 ObserveChange ...........................................................................................................................355 9.2.13.2.7 StartObservation ..........................................................................................................................356 Kernel Modeling Language v1.0 ix -9.2.14 Triggers ...............................................................................................................................................................356 9.2.14.1 Triggers Overview...................................................................................................................................356 9.2.14.2 Elements ..................................................................................................................................................356 9.2.14.2.1 TimeSignal ..................................................................................................................................356 9.2.14.2.2 TriggerAfter.................................................................................................................................357 9.2.14.2.3 TriggerAt .....................................................................................................................................358 9.2.14.2.4 TriggerWhen ...............................................................................................................................358 9.2.15 SpatialFrames ......................................................................................................................................................359 9.2.15.1 SpatialFrames Overview .........................................................................................................................359 9.2.15.2 Elements ..................................................................................................................................................359 9.2.15.2.1 CartesianCurrentDisplacementOf ...............................................................................................359 9.2.15.2.2 CartesianCurrentPositionOf ........................................................................................................360 9.2.15.2.3 CartesianDisplacementOf............................................................................................................360 9.2.15.2.4 CartesianPositionOf.....................................................................................................................361 9.2.15.2.5 CartesianSpatialFrame.................................................................................................................362 9.2.15.2.6 CurrentDisplacementOf...............................................................................................................362 9.2.15.2.7 CurrentPositionOf .......................................................................................................................363 9.2.15.2.8 defaultFrame................................................................................................................................363 9.2.15.2.9 DefaultFrameLife ........................................................................................................................363 9.2.15.2.10 DisplacementOf.........................................................................................................................364 9.2.15.2.11 PositionOf..................................................................................................................................365 9.2.15.2.12 SpatialFrame..............................................................................................................................366 9.2.16 Metaobjects .........................................................................................................................................................366 9.2.16.1 Metaobjects Overview.............................................................................................................................366 9.2.16.2 Elements ..................................................................................................................................................366 9.2.16.2.1 Metaobject ...................................................................................................................................366 9.2.16.2.2 metaobjects ..................................................................................................................................367 9.2.16.2.3 SemanticMetadata .......................................................................................................................367 9.2.17 KerML.................................................................................................................................................................368 9.3 Data Type Library.............................................................................................................................................................368 9.3.1 Data Types Library Overview...............................................................................................................................368 9.3.2 Scalar Values.........................................................................................................................................................369 9.3.2.1 Scalar Values Overview ............................................................................................................................369 9.3.2.2 Elements ....................................................................................................................................................369 9.3.2.2.1 Boolean..........................................................................................................................................369 9.3.2.2.2 Complex ........................................................................................................................................369 9.3.2.2.3 Integer............................................................................................................................................369 9.3.2.2.4 Natural ...........................................................................................................................................370 9.3.2.2.5 Number ..........................................................................................................................................370 9.3.2.2.6 NumericalValue.............................................................................................................................371 9.3.2.2.7 Positive ..........................................................................................................................................371 9.3.2.2.8 Rational .........................................................................................................................................371 9.3.2.2.9 Real................................................................................................................................................372 9.3.2.2.10 ScalarValue .................................................................................................................................372 9.3.2.2.11 String ...........................................................................................................................................373 9.3.3 Collections.............................................................................................................................................................373 9.3.3.1 Collections Overview ................................................................................................................................373 9.3.3.2 Elements ....................................................................................................................................................373 9.3.3.2.1 Array..............................................................................................................................................373 9.3.3.2.2 Bag.................................................................................................................................................374 9.3.3.2.3 Collection ......................................................................................................................................374 9.3.3.2.4 KeyValuePair ................................................................................................................................375 9.3.3.2.5 List.................................................................................................................................................375 9.3.3.2.6 Map................................................................................................................................................375 9.3.3.2.7 OrderedCollection .........................................................................................................................376 9.3.3.2.8 OrderedMap...................................................................................................................................376 x Kernel Modeling Language v1.0 -9.3.3.2.9 OrderedSet.....................................................................................................................................377 9.3.3.2.10 Set................................................................................................................................................377 9.3.3.2.11 UniqueCollection.........................................................................................................................378 9.3.4 Vector Values........................................................................................................................................................378 9.3.4.1 Vector Values Overview ...........................................................................................................................378 9.3.4.2 Elements ....................................................................................................................................................378 9.3.4.2.1 CartesianThreeVectorValue ..........................................................................................................378 9.3.4.2.2 CartesianVectorValue ...................................................................................................................379 9.3.4.2.3 NumericalVectorValue..................................................................................................................379 9.3.4.2.4 ThreeVectorValue .........................................................................................................................379 9.3.4.2.5 VectorValue...................................................................................................................................380 9.4 Function Library ...............................................................................................................................................................380 9.4.1 Function Library Overview...................................................................................................................................380 9.4.2 Base Functions ......................................................................................................................................................381 9.4.2.1 Base Functions Overview..........................................................................................................................381 9.4.2.2 Elements ....................................................................................................................................................381 9.4.3 Data Functions ......................................................................................................................................................382 9.4.3.1 Data Functions Overview..........................................................................................................................382 9.4.3.2 Elements ....................................................................................................................................................382 9.4.4 Scalar Functions ....................................................................................................................................................383 9.4.4.1 Scalar Functions Overview .......................................................................................................................383 9.4.4.2 Elements ....................................................................................................................................................383 9.4.5 Boolean Functions.................................................................................................................................................384 9.4.5.1 Boolean Functions Overview ....................................................................................................................384 9.4.5.2 Elements ....................................................................................................................................................384 9.4.6 String Functions ....................................................................................................................................................384 9.4.6.1 String Functions Overview........................................................................................................................384 9.4.6.2 Elements ....................................................................................................................................................384 9.4.7 Numerical Functions .............................................................................................................................................385 9.4.7.1 Numerical Functions Overview ................................................................................................................385 9.4.7.2 Elements ....................................................................................................................................................385 9.4.8 Complex Functions ...............................................................................................................................................386 9.4.8.1 Complex Functions Overview...................................................................................................................386 9.4.8.2 Elements ....................................................................................................................................................386 9.4.9 Real Functions.......................................................................................................................................................387 9.4.9.1 Real Functions Overview ..........................................................................................................................387 9.4.9.2 Elements ....................................................................................................................................................387 9.4.10 Rational Functions ..............................................................................................................................................388 9.4.10.1 Rational Functions Overview..................................................................................................................388 9.4.10.2 Elements ..................................................................................................................................................388 9.4.11 Integer Functions.................................................................................................................................................389 9.4.11.1 Integer Functions Overview ....................................................................................................................389 9.4.11.2 Elements ..................................................................................................................................................389 9.4.12 Natural Functions ................................................................................................................................................390 9.4.12.1 Natural Functions Overview ...................................................................................................................390 9.4.12.2 Elements ..................................................................................................................................................390 9.4.13 Trig Functions .....................................................................................................................................................391 9.4.13.1 Trig Functions Overview ........................................................................................................................391 9.4.13.2 Elements ..................................................................................................................................................391 9.4.14 Sequence Functions.............................................................................................................................................392 9.4.14.1 Sequence Functions Overview ................................................................................................................392 9.4.14.2 Elements ..................................................................................................................................................392 9.4.15 Collection Functions ...........................................................................................................................................394 9.4.15.1 Collection Functions Overview...............................................................................................................394 9.4.15.2 Elements ..................................................................................................................................................394 Kernel Modeling Language v1.0 xi -9.4.16 Vector Functions .................................................................................................................................................395 9.4.16.1 Vector Functions Overview ....................................................................................................................395 9.4.16.2 Elements ..................................................................................................................................................395 9.4.17 Control Functions................................................................................................................................................399 9.4.17.1 Control Functions Overview ...................................................................................................................399 9.4.17.2 Elements ..................................................................................................................................................399 9.4.18 Occurrence Functions..........................................................................................................................................401 9.4.18.1 Occurrence Functions Overview .............................................................................................................401 9.4.18.2 Elements ..................................................................................................................................................401 10 Model Interchange ......................................................................................................................................................................405 10.1 Model Interchange Overview..........................................................................................................................................405 10.2 Model Interchange Formats ............................................................................................................................................405 10.3 Model Interchange Projects ............................................................................................................................................406 10.4 JSON Serialization ..........................................................................................................................................................409 10.4.1 Serialization Overview........................................................................................................................................409 10.4.2 Primitive Type Serialization ...............................................................................................................................409 10.4.3 Enumeration Serialization ...................................................................................................................................410 10.4.4 Element Reference Serialization .........................................................................................................................410 10.4.5 Element Serialization ..........................................................................................................................................410 10.4.6 Model Serialization .............................................................................................................................................410 A Annex: Model Execution .............................................................................................................................................................411 A.1 Overview ..........................................................................................................................................................................411 A.2 Modeling Instances and Feature Values ..........................................................................................................................411 A.3 Instantiation Procedure.....................................................................................................................................................412 A.3.1 Overview ..............................................................................................................................................................412 A.3.2 Without connectors ..............................................................................................................................................412 A.3.3 One-to-one connectors .........................................................................................................................................413 A.3.4 One-to-unrestricted connectors ............................................................................................................................414 A.3.5 Timing for structures ............................................................................................................................................416 A.3.6 Timing for behaviors, Sequences .........................................................................................................................419 A.3.7 Timing for behaviors, Decisions and merges.......................................................................................................421 A.3.8 Timing for behavior, Changing feature values.....................................................................................................424 xii Kernel Modeling Language v1.0 -List of Tables 1. Grammar Production Definitions...................................................................................................................................................74 2. EBNF Notation Conventions .........................................................................................................................................................74 3. Abstract Syntax Synthesis Notation...............................................................................................................................................74 4. Escape Sequences ..........................................................................................................................................................................76 5. Operator Mapping..........................................................................................................................................................................97 6. Operator Precedence (highest to lowest) .......................................................................................................................................98 7. Primary Expression Operator Mapping .......................................................................................................................................101 8. Core Semantics Implied Relationships ........................................................................................................................................239 9. Core Semantics Implied Relationships Supporting Kernel Semantics ........................................................................................239 10. Kernel Semantics Implied Specializations.................................................................................................................................247 11. Kernel Semantics Other Implied Relationships .........................................................................................................................251 12. Interchange Project Information ................................................................................................................................................407 13. Interchange Project Metadata ....................................................................................................................................................408 14. UML Primitive Type Serialization ............................................................................................................................................409 Kernel Modeling Language v1.0 xiii -List of Figures 1. KerML Syntax Layers..................................................................................................................................................................106 2. KerML Element Hierarchy ..........................................................................................................................................................107 3. KerML Relationship Hierarchy ...................................................................................................................................................107 4. Elements.......................................................................................................................................................................................109 5. Dependencies ...............................................................................................................................................................................115 6. Annotation....................................................................................................................................................................................117 7. Namespaces..................................................................................................................................................................................123 8. Imports .........................................................................................................................................................................................124 9. Types............................................................................................................................................................................................134 10. Specialization .............................................................................................................................................................................135 11. Conjugation................................................................................................................................................................................135 12. Disjoining...................................................................................................................................................................................136 13. Unioning ....................................................................................................................................................................................136 14. Intersecting.................................................................................................................................................................................136 15. Differencing ...............................................................................................................................................................................137 16. Classifiers...................................................................................................................................................................................152 17. Features ......................................................................................................................................................................................154 18. Subsetting...................................................................................................................................................................................155 19. Feature Chaining........................................................................................................................................................................155 20. Feature Inverting........................................................................................................................................................................156 21. End Feature Membership...........................................................................................................................................................156 22. Cross Subsetting ........................................................................................................................................................................156 23. Data Types .................................................................................................................................................................................178 24. Classes........................................................................................................................................................................................179 25. Structures ...................................................................................................................................................................................180 26. Associations ...............................................................................................................................................................................181 27. Connectors .................................................................................................................................................................................185 28. Behaviors ...................................................................................................................................................................................190 29. Parameter Memberships.............................................................................................................................................................190 30. Functions....................................................................................................................................................................................194 31. Predicates ...................................................................................................................................................................................194 32. Function Memberships...............................................................................................................................................................194 33. Expressions ................................................................................................................................................................................202 34. Literal Expressions.....................................................................................................................................................................202 35. Interactions.................................................................................................................................................................................219 36. Flows..........................................................................................................................................................................................220 37. Feature Values ...........................................................................................................................................................................225 38. Multiplicities ..............................................................................................................................................................................227 39. Metadata Annotation..................................................................................................................................................................230 40. Packages.....................................................................................................................................................................................233 41. KerML Semantic Layers............................................................................................................................................................237 42. Interchange Projects...................................................................................................................................................................407 xiv Kernel Modeling Language v1.0 -Kernel Modeling Language v1.0 xv -xvi Kernel Modeling Language v1.0 -1Scope The Kernel Modeling Language (KerML) is an application-independent modeling language with a well-grounded formal semantics for modeling existing or planned systems. The language includes general syntactic constructs for structuring models, such as relationships, annotations and namespaces; core semantic constructs that have semantics based on classification; and additional constructs for commonly needed modeling capabilities, such as associations and behaviors. System models are expressed in KerML using a textual concrete syntax. This can be parsed to an abstract syntax representation, which is then given a semantic interpretation for the system being modeled. The semantics for the KerML core constructs is grounded in formal mathematical logic, providing a consistent basis for mathematical reasoning about KerML models. However, beyond this, the semantics of KerML constructs are specified by the relationship of user model elements to the KerML Semantic Library. The Semantic Library models, also expressed in KerML, provide an ontological model of the meaning of KerML models. Indeed, all KerML models can be semantically expressed using solely core modeling constructs referencing the appropriate semantic concepts defined in the Semantic Library. KerML semantic constructs beyond the core are essentially just syntactic conveniences for reusing specific library concepts: structures for modeling objects, behaviors for modeling performances, associations for modeling links, etc. Indeed, the full KerML language can be considered to be simply a syntactic extension of the core, which is semantically extended using library models. By intent, this approach can also be used to build on KerML to create more specific modeling languages. Application specific modeling languages can be built on KerML by extending the KerML abstract syntax, specializing its semantics, with concrete syntaxes similar to or entirely different from KerML's. To support this, the KerML Semantic Library also includes additional library models beyond those directly providing semantics for KerML syntactic constructs, capturing typical semantic patterns (such as asynchronous transfers and state-based behavior) that can be reused by languages built on KerML. Specialized modeling languages can provide additional syntax for these libraries, tailored to their applications, with semantics based largely or entirely on the KerML libraries. In this way, KerML can provide the kernel for a family of syntactically diverse but semantically integrated modeling languages. Kernel Modeling Language v1.0 i -ii Kernel Modeling Language v1.0 -2Conformance This specification defines the Kernel Modeling Language (KerML), a language used to construct models of (real or virtual, planned or imagined) things. The specification includes this document and the content of the machine- readable files listed on the cover page. If there are any conflicts between this document and the machine-readable files, the machine-readable files take precedence. A KerML model shall conform to this specification only if it can be represented according to the syntactic requirements specified in Clause 8 . The model may be represented in a form consistent with the requirements for the KerML concrete syntax, in which case it can be parsed (as specified in Clause 8 ) into an abstract syntax form, or may be represented only in an abstract syntax form (see also 8.2 and 8.3 ). A KerML modeling tool is a software application that creates, manages, analyzes, visualizes, executes or performs other services on KerML models. A tool can conform to this specification in one or more of the following ways. 1. Abstract Syntax Conformance. A tool demonstrating Abstract Syntax Conformance provides a user interface and/or API that enables instances of KerML abstract syntax metaclasses to be created, read, updated, and deleted. The tool must also provide a way to validate the well-formedness of models that corresponds to the constraints defined in the KerML metamodel. A well-formed model represented according to the abstract syntax is syntactically conformant to KerML as defined above. (See Clause 8 .) 2. Concrete Syntax Conformance. A tool demonstrating Concrete Syntax Conformance provides a user interface and/or API that enables instances of KerML concrete syntax notation to be created, read, updated, and deleted. Note that a conforming tool may also provide the ability to create, read, update and delete additional notational elements that are not defined in KerML. Concrete Syntax Conformance implies Abstract Syntax Conformance, in that creating models in the concrete syntax acts as a user interface for the abstract syntax. However, a tool demonstrating Concrete Syntax Conformance need not represent a model internally in exactly the form modeled for the abstract syntax in this specification. (See Clause 8 .) 3. Semantic Conformance. A tool demonstrating Semantic Conformance provides a demonstrable way to interpret a syntactically conformant model (as defined above) according to the KerML semantics, e.g., via model execution, simulation, or reasoning, when and only when such interpretations are possible. Semantic Conformance implies Abstract Syntax Conformance, in that the semantics for KerML are only defined on models represented in the abstract syntax. (See Clause 8 and Clause 9 . See also 6.1 for further discussion of the interpretation of models and their syntactic and semantic conformance.) 4. Model Interchange Conformance. A tool demonstrating model interchange conformance can import and/ or export syntactically conformant KerML models (as defined above) as specified in Clause 10 . Every conformant KerML modeling tool shall demonstrate at least Abstract Syntax Conformance and Model Interchange Conformance. In addition, such a tool may demonstrate Concrete Syntax Conformance and/or Semantic Conformance, both of which are dependent on Abstract Syntax Conformance. Kernel Modeling Language v1.0 3 -4 Kernel Modeling Language v1.0 -3Normative References The following normative documents contain provisions which, through reference in this text, constitute provisions of this specification. [ADLER] ZLIB Compressed Data Format Specification, Version 3.3 https://datatracker.ietf.org/doc/html/rfc1950 [Alf] Action Language for Foundational UML (Alf), Version 1.1 https://www.omg.org/spec/ALF/1.1 [BLAKE] The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC) https://www.rfc-editor.org/rfc/rfc7693 BLAKE3 https://github.com/BLAKE3-team/BLAKE3-specs/blob/master/blake3.pdf [fUML] Semantics of a Foundational Subset for Executable UML Models (fUML), Version 1.4 https://www.omg.org/spec/fUML/1.4 [ISO8601] ISO 8601-1:2019 (First edition) Date and time – Representations for information interchange — Part 1: Basic rules https://www.iso.org/standard/70907.html [ISO10646] ISO/IEC 10646:2010 (Second edition) Information technology – Universal Coded Character Set (UCS) [ISO15897] ISO/IEC 15897:2011 Information technology – User interfaces – Procedures for the registration of cultural elements https://www.iso.org/standard/50707.html [JSON] ISO/IEC 21778:2017 Information technology – The JSON data interchange syntax https://www.iso.org/standard/71616.html (see also IECMA-404 The JSON data interchange syntax https://www.ecma-international.org/publications-and-standards/standards/ecma-404/) [MD] The MD2 Message-Digest Algorithm https://datatracker.ietf.org/doc/html/rfc1319 The MD4 Message-Digest Algorithm https://www.rfc-editor.org/rfc/rfc1320 The MD5 Message-Digest Algorithm https://www.rfc-editor.org/rfc/rfc1321 [MOF] Meta Object Facility, Version 2.5.1 https://www.omg.org/spec/MOF/2.5.1 [OCL] Object Constraint Language, Version 2.4 https://www.omg.org/spec/OCL/2.4 [SHS] FIPS Pub 180-4 Secure Hash Standard https://csrc.nist.gov/publications/detail/fips/180/4/final [SMOF] MOF Support for Semantic Structures, Version 1.0 https://www.omg.org/spec/SMOF/1.0 [SysAPI] Systems Modeling Application Programming Interface (API) and Services (as submitted contemporaneously with this proposed KerML specification) Kernel Modeling Language v1.0 5 -[UUID] ITU-T X.667 (10/2012) Information technology – Procedures for the operation of object identifier registration authorities: Generation of universally unique identifiers and their use in object identifiers https://www.itu.int/rec/T-REC-X.667-201210-I (see also A Universally Unique IDentifier (UUID) URN Namespace https://tools.ietf.org/html/rfc4122) [XMI] XML Metadata Interchange, Version 2.5.1 https://www.omg.org/spec/XMI/2.5.1 [ZIP] .ZIP File Format Specification https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT 6 Kernel Modeling Language v1.0 -4Terms and Definitions Various terms and definitions are specified throughout the body of this specification. Kernel Modeling Language v1.0 7 -8 Kernel Modeling Language v1.0 -5Symbols A concrete syntax for KerML is specified in subclause 8.2 of this specification. Kernel Modeling Language v1.0 9 -10 Kernel Modeling Language v1.0 -6Introduction 6.1 Language Architecture Developing systems generally involves creating a number of different specifications. For instance, a requirements specification gives the intended effects of a system, while a design specification determines how the system will bring about those effects. Many designs might be developed and evaluated against the same requirements. A test specification then describes test procedures that check whether requirements are met by real or virtual systems built and operated according to some design. A model is a representation in some modeling language of all or part of any of the above kinds of system specification. The semantics of such models defines what it means for real or virtual things in a modeled system to conform to the specification given by the model. KerML is a foundational modeling language for expressing various kinds of system models with consistent semantics. Syntactically, KerML is divided into three layers, with each layer building increasingly specific constructs on the previous layer. These layers are, from general to specific: 1. The Root Layer includes the most general syntactic constructs for structuring models, such as elements, relationships, annotations, and packaging. 2. The Core Layer includes the most general constructs that have semantics based on classification. 3. The Kernel Layer provides commonly needed modeling capabilities, such as associations and behavior. The Core Layer grounds KerML semantics by interpreting it using mathematical logic. However, additional semantics are then specified through the relationship of Kernel abstract syntax constructs to model elements in the Kernel Semantic Library, which is written in KerML itself. Models expressed in KerML thus essentially reuse elements of the Semantic Library to give them semantics. The Semantic Library models give the basic conditions for the conformance of modeled things to the model, which are then augmented in the user model as appropriate. Having a consistent specification of semantics helps people interpret models in the same way. In particular, because the Semantic Library models are expressed in the same language as user models, engineers and tool builders can inspect the library models to formally understand what real or virtual effects are actually being specified by their models for systems being modeled. More uniform model interpretation improves communication between everyone involved in modeling, including modelers and tool builders. 6.2 Document Organization The remainder of this document is organized into four major clauses. • Clause 7 describes KerML from a user point of view, covering all the modeling constructs in the language. It is an informative reference for the normative language specification given in the following three subclauses. • Clause 8 specifies the normative metamodel for the KerML language. This includes the complete grammar for the concrete syntax, which is a textual notation (see 8.2 ), the abstract syntax, which is a MOF model (see 8.3 ), and formal semantics (see 8.4 ). • Clause 9 specifies the normative Kernel Model Libraries, each of which is a set of library models available to be used in all KerML user models. They include the Semantic Library, which is a set of KerML models used to provide Kernel-layer semantics to user models (see 9.2 ), the Data Type Library of standard data types (see 9.3 ) and the Function Library of functions on those data types (see 9.4 ). • Clause 10 specifies the format for standard file-based interchange of KerML models between tools. Kernel Modeling Language v1.0 11 -In addition, Annex A provides basic (non-normative) guidance on incrementally instantiating models for execution, in a way that conforms to the formal semantics as (normatively) specified in the metamodel (see 8.4 ), as supported by the Semantic Model Library (see 9.2 ). 6.3 Acknowledgements This specification represents the work of many organizations and individuals. The Kernel Model Language concept, as developed for use with SysML v2, is based on earlier work of the KerML Working Group, which was led by: • Conrad Bock, US National Institute of Standards and Technology (NIST) • Charles Galey, Jet Propulsion Laboratory • Bjorn Cole, Lockheed Martin Corporation The primary authors of this specification document and the syntactic and library models described in it are: • Ed Seidewitz, Model Driven Solutions • Conrad Bock, US National Institute of Standards and Technology (NIST) • Bjorn Cole, Lockheed Martin Corporation • Ivan Gomes, Twingineer • Hans Peter de Koning, DEKonsult • Vince Molnár, Budpest University of Technology and Economics Other contributors include: • Manfred Koethe, 88solutions • Karen Ryan, Siemens The specification was formally submitted for standardization by the following organizations: • 88solutions Corporation • Dassault Systèmes • GfSE e.V. • IBM • INCOSE • Intercax LLC • Lockheed Martin Corporation • MITRE • Model Driven Solutions, Inc. • PTC • Simula Research Laboratory AS • Thematix Partners LLC However, work on the specification was also supported by over 200 people in over 80 organizations that participated in the SysML v2 Submission Team (SST). The following individuals had leadership roles in the SST: • Manas Bajaj, Intercax LLC (API and services development lead) • Yves Bernard, Airbus (v1 to v2 transformation co-lead) • Bjorn Cole, Lockheed Martin Corporation (metamodel development co-lead) • Sanford Friedenthal, SAF Consulting (SST co-lead, requirements V&V lead) • Charles Galey, Lockheed Martin Corporation (metamodel development co-lead) • Karen Ryan, Siemens (metamodel development co-lead) • Ed Seidewitz, Model Driven Solutions (SST co-lead, pilot implementation lead) • Tim Weilkiens, oose (v1 to v2 transformation co-lead) 12 Kernel Modeling Language v1.0 -The specification was prepared using CATIA Magic/No Magic modeling tools and the OpenMBEE system for model publication (http://www.openmbee.org), supported by the 3DEXPERIENCE platform, with the invaluable support of the following individuals: • Tyler Anderson, Dassault Systèmes • Christopher Delp, Jet Propulsion Laboratory • Jackson Galloway, Dassault Systèmes • Ivan Gomes, Twingineer • Doris Lam, Jet Propulsion Laboratory • Robert Karban, Jet Propulsion Laboratory • Christopher Klotz, Dassault Systèmes • John Watson, Lightstreet Consulting Kernel Modeling Language v1.0 13 -14 Kernel Modeling Language v1.0 -7 Language Description (Informative) 7.1 Language Description Overview This clause provides an informative description of KerML. Clause 8 gives the full definition of the KerML metamodel, which is the normative specification for implementing the language. In contrast, the description in this clause focuses on how the various constructs of the language are used, along with the Kernel Model Library (see Clause 9 ), to construct models. While non-normative, it is intended to be precise and consistent with the normative specification of the language. The following subclauses present the language features in each of the Root, Core and Kernel Layers of KerML (as described in 6.1). Each layer is then further subdivided, following a parallel structure to the packaging of the metamodel (see 8.1 ). Each subclause within a layer includes references to the corresponding concrete syntax, abstract syntax and semantics subclauses from the normative metamodel specification. In this way, the clause can be used as a general reference for KerML as well as a guide for better understanding of the formal specification of the metamodel. This clause contains many examples of the KerML textual notation. In order to distinguish this text from normal body text, the following stylistic conventions are used in this clause. 1. Textual notation appears in " code " font. This includes references to individual element names from both example models (such as Vehicle and wheels ) and the Kernel Model Library (such as Performance and performances ), as well as more extensive model snippets. 2. Keywords appear in boldface , both when referenced in-line in body text ("Features are declared using the feature keyword.") and when used within complete notation examples. 3. Longer samples of textual notation are written in separate paragraphs, indented relative to body paragraphs. 7.2 Root 7.2.1 Root Overview The Root layer provides the most general syntactic capabilities of the language: elements and relationships between them, annotations of elements, and membership of elements in namespaces. These capabilities are the syntactic foundation for structuring models in KerML, but they do not actually represent anything about a modeled system, and so have no semantic specification. The Core and Kernel layers build on the foundation provided by Root to provide constructs with modeling semantics (see 7.3 and 7.4 ). 7.2.2 Elements and Relationships 7.2.2.1 Elements and Relationships Overview Metamodel references: • Concrete syntax, 8.2.3.1 • Abstract syntax, 8.3.2.1 • Semantics, none Elements are the constituents of a model. Some elements represent relationships between other elements, known as the related elements of the relationship. In general terms, a model is constructed as a graph structure in which relationships form the edges connecting non-relationship elements constituting the nodes. However, since relationships are themselves elements, it is also possible in KerML for a relationship to be a related element in a relationship and for there to be relationships between relationships. Kernel Modeling Language v1.0 15 -One of the related elements of a relationship may be the owning related element of the relationship. If the owning related element of a relationship is deleted from a model, then the relationship is also deleted. Some of the related elements of a relationship (distinct from the owning related element, if any) may be owned related elements. If a relationship has owned related elements, then, if the relationship is deleted from a model, all its owned related elements are also deleted. The owned relationships of an element are all those relationships for which the element is the owning related element. The owned elements of an element are all those elements that are owned related elements of the owned relationships of the element (notice the extra level of indirection through the owned relationships). The owning relationship of an element (if any) is the relationship for which the element is an owned related element (of which the element can have at most one). The owner of an element (if any) is the owning related element of the owning relationship of the element (again, notice the extra level of indirection through the owning relationship). The deletion rules for relationships imply that, if an element is deleted from a model, then all its owned relationships are also deleted and, therefore, all its owned elements. This may result in a further cascade of deletions until all deletion rules are satisfied. An element that has no owner acts as the root element of an ownership tree structure, such that all elements and relationships in the structure are deleted if the root element is deleted. Deleting any element other than the root element results in the deletion of the entire subtree rooted in that element. 7.2.2.2 Elements Every element has a unique identifier known as its element ID. The properties of an element can change over its lifetime, but its element ID does not change after the element is created. An element may also have additional identifiers, its alias IDs, which may be assigned for tool-specific purposes. The KerML textual notation, however, does not have any provision for specifying element or alias IDs, since these are expected to be managed by the underlying modeling tooling. Instead, an element may also have a name and/or a short name, by which it can be referenced in the notation. While the language makes no formal distinction between names and short names, the intent is that the name of an element should be fully descriptive, particularly in the context of the definition of the element, while the short name, if given, should be an abbreviated name useful for referring to the element. (For further discussion of naming, see also 7.2.5 ). In most cases, an element is declared using a keyword indicating the kind of element it is (e.g., classifier or feature ). The declaration of an element may also specify a short name and/or name for it, in that order. The short name is distinguished by being surrounded by the delimiting characters < and > . classifier AClassifier; feature aFeature; Note that it is not required to specify either a short name or a name for an element. However, unless at least one of these is given, it is not possible to reference the element from elsewhere in the textual notation. Names and short names have the same lexical structure, which has two variants. 1. A basic name is one that can be lexically distinguished in itself from other parts of the notation. The initial character of a basic name must be a lowercase letter, an uppercase letter or an underscore. The remaining characters of a basic name can be any character allowed as an initial character or any digit. However, a reserved keyword may not be used as a name, even though it has the form of a basic name (see 8.2.2.6 for the list of reserved words). Vehicle power_line 2. An unrestricted name provides a way to represent a name that contains any character. It is represented as a non-empty sequence of characters surrounded by single quotes. The name consists of the characters within the single quotes – the single quotes are not included as part of the represented name. The characters within the single quotes may not include non-printable characters (including backspace, tab and newline). 16 Kernel Modeling Language v1.0 -However, these characters may be included as part of the name itself through use of an escape sequence. In addition, the single quote character or the backslash character may only be included within the name by using an escape sequence. '+' 'circuits in line' 'On/Off Switch' 'Ångström' An escape sequence is a sequence of two text characters starting with a backslash as an escape character, which actually denotes only a single character (except for the newline escape sequence, which represents however many characters is necessary to represent an end of line in a specific implementation). Table 4 in subclause 8.2.2.3 shows the meaning of the allowed escape sequences. In addition to the declaration notated as above, the representation for an element may include a body, which is a list of owned elements delimited by curly braces { ... } . It is a general principle of the KerML textual concrete syntax that the representation of owned elements are nested inside the body of the representation of the owning element. In this way, when the notation for the owning element is removed in its entirety from the representation of a model, the owned elements are also removed. namespace P { // This is the body of the namespace, declaring its owned members. classifier A; classifier B { // This is the body of the classifier, declaring its owned features. feature x; feature y; } } 7.2.2.3 Relationships The related elements of a relationship are divided into source and target elements. A relationship is said to be directed from its source elements to its target elements. It is allowed for a relationship to have only source or only target elements. However, by convention, an undirected relationship is usually represented as having only target elements. A relationship must have at least two related elements. A relationship with exactly two related elements is known as a binary relationship. A directed binary relationship is a binary relationship in which one related element is the source and one is the target. Most specialized kinds of relationship in KerML are directed binary relationships (the principal exceptions being dependencies, associations and connectors, see 7.2.3 , 7.4.5 , and 7.4.6 ). Various kinds of relationships are declared with special notations showing their related elements. A relationship may also have a body that specifies owned related elements of the relationship, which may include any kind of element other than an annotating element (see 7.2.4 ). If an annotating element (i.e., a comment, textual representation or metadata feature) is included in the body of a relationship, then, rather than being directly an owned related element of the containing relationship, the annotating element is an owned related element of an annotation relationship owned by the containing relationship (see 7.2.3.2 for an example). 7.2.3 Dependencies 7.2.3.1 Dependencies Overview Metamodel references: • Concrete syntax, 8.2.3.2 • Abstract syntax, 8.3.2.2 • Semantics, none Kernel Modeling Language v1.0 17 -A dependency is a kind of relationship between any number of client (source) and supplier (target) elements. It implies that a change to a supplier element may result in a change to a client element. Dependencies can be useful for representing relationships between elements in an abstract way. For example, a dependency can be used to represent that an upper layer of an architecture stack may depend on a lower layer of the stack. 7.2.3.2 Dependency Declaration A dependency is declared using the keyword dependency , optionally followed by a short name and/or name (see 7.2.2 ). The client elements of the dependency are then given as a comma-separated list of qualified names following the keyword from , followed by a similar list of the supplier elements after the keyword to . If no short name or name is given for the dependency, then the keyword from may be omitted. dependency Use from 'Application Layer' to 'Service Layer'; // 'Service Layer' is the client of this dependency, not its name. dependency 'Service Layer' to 'Data Layer', 'External Interface Layer'; A dependency declaration may also optionally have a relationship body (see 7.2.2.3 ) containing any additional owned related elements (which act as suppliers) and annotating elements owned by the dependency via annotation relationships (see 7.2.4 ). dependency 'Service Layer' to 'Data Layer', 'External Interface Layer' { /* 'Service Layer' is the client of this dependency, * not its name. */ } 7.2.4 Annotations 7.2.4.1 Annotations Overview Metamodel references: • Concrete syntax, 8.2.3.3 • Abstract syntax, 8.3.2.3 • Semantics, none An annotation is a relationship between an annotated element and an annotating element that provides additional information about the element being annotated. Any kind of element may be annotated, but only certain kinds of elements may be annotating elements. Specific kinds of annotating elements include comments and textual representations (see 7.2.4.2 and 7.2.4.3 ). A further kind of annotating element for user-defined metadata is defined in the Kernel layer (see 7.4.13 ). Each annotation relationship is between a single annotating element and a single annotated element, but an annotating element may have multiple annotation relationships with different annotated elements, and any element may have multiple annotations. The annotated element of an annotation can optionally be the owning related element of the annotation, in which case the annotation is an owned annotation of the owning annotated element. If an annotating element is an owned member of a namespace (see 7.2.5 ) and is not involved in any annotation relationships, then its owning namespace is considered to be its annotated element without the need for an explicit annotation relationship. 18 Kernel Modeling Language v1.0 -7.2.4.2 Comments and Documentation A comment is an annotating element with a textual body that in some way describes its annotated element. Documentation is a kind of comment that has the special status of documenting the annotated element, known in this case as the documented element. A documentation comment is always an owned element of its documented element. The full declaration of a comment begins with the keyword comment , optionally followed by a short name and/or name (see 7.2.2.2 ). One or more annotated elements are then identified for the comment after the keyword about , indicating that the comment has annotation relationships to each of the identified elements. The body of the comment is written lexically as regular comment text between /* and */ delimiters (see also 8.2.2.2 ). classifier A; classifier B; comment Comment1 about A, B /* This is the comment body text. */ If the comment is an owned member of a namespace (see 7.2.5 ), then the explicit identification of annotated elements can be omitted, in which case the annotated element is implicitly the containing namespace. Further, in this case, if no short name or name is given for the comment, then the comment keyword can also be omitted. namespace N { comment C /* This is a comment about N. */ /* This is also a comment about N. */ } A locale can also be specified for a comment, using the keyword locale followed by the locale string, placed immediately before the comment body (whether or not the comment keyword is used). The locale identifies the language of the body text and, optionally, the region and/or encoding. The format is language[_territory][.codeset][@modifier] (conformant to [ISO15897]). comment C_US_English locale "en_US" /* This is US English comment text */ A documentation comment is notated similarly to a regular comment, but using the keyword doc rather than comment . The documented element of a documentation comment is always the owning element of the documentation. dependency X from A to B { doc X_Comment /* This is a documentation comment about X. */ doc /* This is more documentation about X. */ } namespace P { doc P_Comment /* This is a documentation comment about P. */ } The actual body text of a comment does not include the initial /* and final */ characters. Further, the written text is processed to allow formatting using * characters to delimit consistent initial indentation of a comment lines. For example, the comment notation in: namespace CommentExample { /* * This is an example of multiline * comment text with typical formatting * for readable display in a text editor. */ } Kernel Modeling Language v1.0 19 -would result in the following body text in the comment element in the represented model: This is an example of multiline comment text with typical formatting for readable display in a text editor. The body text of a comment can include markup information (such as HTML), and a tool may (but is not required to) display such text as rendered according to the markup. (See 8.2.3.3.2 for the complete rules for processing comment text.) 7.2.4.3 Textual Representations A textual representation is an annotating element whose textual body represents its annotated element (known in this case as the represented element) in a given language. A textual representation is notated similarly to a documentation comment (see 7.2.4.2 ), but with the keyword rep used instead of comment . As for documentation, a textual representation is always owned by its represented element. In particular, if the textual representation is an owned member of a namespace (see 7.2.5 ), the represented element is the containing Namespace. A textual representation declaration must also specify the language used for the textual body as a literal string (see 8.2.2.5 ) following the keyword language . If the textual representation has no short name or name, then the rep keyword can also be omitted. class C { feature x: Real; inv x_constraint { rep inOCL language "ocl" /* self.x > 0.0 */ } } behavior setX(c : C, newX : Real) { language "alf" /* c.x = newX; * WriteLine("Set new x"); */ } The lexical comment text given for a textual representation is processed as for regular comment text (see 7.2.4.2 ), and it is the result after such processing that is the textual representation body expected to conform to the named language. Note. Since the lexical form of a comment is used to specify the textual representation body , it is not possible to include comments of a similar form in the body text. The language name in a textual representation is case insensitive. The name can be of a natural language, but will often be for a machine-parsable language. In particular, there are recognized standard language names. If the language is "kerml" , then the body of the textual representation must be a legal representation of the represented element in the KerML textual notation. A tool can use such a textual representation to record the original KerML notation text from which an element is parsed. Other standard language names that can be used in a textual representation include "ocl" and "alf" , in which case the body of the textual representation must be written in the Object Constraint Language [OCL] or the Action Language for fUML [Alf], respectively. However, for any other language than "kerml" , the KerML specification does not define how the body text is to be semantically interpreted as part of the model being represented. An element with no other definition than a textual representation in a language other than KerML is essentially a semantically "opaque" element specified in the other language. Nevertheless, a conforming KerML tool may (but is not required to) interpret such an element consistently with the specification of the named language. 20 Kernel Modeling Language v1.0 -7.2.5 Namespaces 7.2.5.1 Namespaces Overview Metamodel references: • Concrete syntax, 8.2.3.4 • Abstract syntax, 8.3.2.4 • Semantics, none A namespace is an element that contains other elements via membership relationships with those elements. The namespace is the source element and owner of the membership. The target of a membership can be any kind of element, known as the member element of the membership. If the membership is an owning membership, then the member element is known as an owned member element, which is the only owned related element of the membership. A namespace may also import memberships from other namespaces. Further, a type, which is kind of namespace, may inherit memberships from other types that it specializes (see 7.3.2 ). The members of a namespace are the member elements of all the memberships of the namespace (whether owned, imported or inherited). The owned members of a namespace are the owned member elements of all the owned memberships of the namespace that are owning memberships. If an element is a member of a namespace, then any name for that element relative to the namespace is known as an unqualified name for that element in the namespace. If the containing namespace is not a root namespace (see 7.2.5.3 ), then the qualified name for the member element consists of a name for the containing namespace, known as the qualifier, followed by an unqualified name for the element. Since a namespace is an element that may itself be a member of another namespace, a qualifier may be a qualified name. Therefore, a qualified name of an element, in general, has the form of a list of unqualified names of namespaces, each relative to the previous one, followed by the unqualified name of the element in the final namespace. A qualified name is notated as a sequence of segment names separated by " :: " punctuation. An unqualified name can be considered the degenerate case of a qualified name with a single segment name. A qualified name is used in the KerML textual concrete syntax to identify an element that is being referred to in the representation of another element. A qualified name used in this way does not appear in the corresponding abstract syntax—instead, the abstract syntax representation contains an actual reference to the identified element. Name resolution is the process of determining the element that is identified by a qualified name (see 8.2.3.5 ). Normally, name resolution begins by searching in the local namespace containing the qualified name reference. If local name resolution is not successful, the search proceeds outwards to successive containing namespaces until a root namespace is reached (see 7.2.5.3 ), at which point a final attempt is made to search the global namespace consisting of all available root namespaces. However, if a qualified name is preceded by the global scope qualification $:: , then name resolution begins in the global namespace, regardless of the location of the qualified name reference. Since namespaces and their members may have aliases (see 7.2.5.2 ), it is possible for there to be multiple qualified names for an element even if it does not itself have aliases. On the other hand, if a namespace does not have any name, then its members will have no qualified names, even if they are themselves named. 7.2.5.2 Namespace Declaration A namespace that is not a root namespace (see 7.2.5.3 ), and does not represent any more specialized modeling construct (such as a type—see 7.3.2 ) is declared using the keyword namespace , optionally followed by a short name and/or name (see 7.2.2.2 ). The body of the namespace is notated as a list of representations of the content of the namespace delimited between curly braces { ... } . If the namespace is empty, then the body may be omitted and the declaration ended instead with a semicolon. Kernel Modeling Language v1.0 21 -namespace <'1.1'> N1; // This is an empty namespace. namespace <'1.2'> N2 { doc /* This is an example of a namespace body. */ class C; datatype D; feature f : C; namespace N3; // This is a nested namespace. } Declaring an element within the body of a namespace denotes that the element is an owned member of the namespace—that is, that there is an owning membership relationship between the namespace and the member element. The visibility of the membership can be specified by placing one of the keywords public , protected or private before the public element declaration. If the membership is public (the default), then it is visible outside of the namespace. If it is private , then it is not visible. For namespaces other than types, protected visibility is equivalent to private . For types, protected visibility has a special meaning relating to member inheritance (see 7.3.2 ). namespace N3 { public class C; private datatype D; feature f : C; // public by default } An alias for an element is a non-owning membership of the element in a namespace, which may or may not be the same namespace that owns the element. An alias name or short name is determined only relative to its membership in the namespace, and can therefore be different than the name or short name defined on the element itself. Note that the same element may be related to a namespace by multiple alias memberships, allowing the element to have multiple, different names relative to that namespace. An alias is declared using the keyword alias followed by the alias short name and/or name, with a qualified name identifying the element given after the keyword for . The alias declaration may optionally include a body as described for relationships in 7.2.2.3 . The visibility of the alias membership can be specified as for an owned member. namespace N4 { class A; class B; alias CCC for B { doc /* Documentation of the alias. */ } private alias D for B; } A comment (see 7.2.4.2 ), including documentation, declared within a namespace body also becomes an owned member of the namespace. If no annotated elements are specified for the comment (with an about clause), then, by default, the comment is considered to be about the containing namespace. namespace N5 { class A; comment Comment1 about A /* This is a comment about class A. */ comment Comment2 /* This is a comment about namespace N5. */ /* This is also a comment about namespace N5. */ 22 Kernel Modeling Language v1.0 -doc N9_Doc /* This is documentation about namespace N5. */ } With the ability to specify names, short names and aliases for elements, any element can potentially have several names relative to a namespace. However, the set of names provided for any one member of a namespace must be disjoint from the set of names provided for any other member of the namespace. That is, a namespace effectively provides a "space" of names, each one of which uniquely identifies a single member element of the namespace (though there may be multiple names that identify the same element). This is known as the distinguishibility of namespace memberships. 7.2.5.3 Root Namespaces A root namespace is a namespace that has no owner. The owned members of a root namespace are known as top- level elements. Any element that is not a root namespace has an owner and, therefore, must be in the ownership tree of a top-level element of some root namespace. The declaration of a root namespace is implicit and no identification of it is provided in the KerML textual notation. Instead, the body of a root namespace is given simply by the list of representations of its top-level elements. doc /* This is a model notated in KerML concrete syntax. */ classifier A { feature c : C; } class C; datatype D; feature f: C; package P; Since the notation does not provide a means for naming a root namespace, the name of a top-level element is not qualified by the name of its containing root namespace. The name resolution rules consider all top-level elements to be directly and globally visible without qualification (see 8.2.3.5 ). Therefore, the fully qualified name of an element relative to a root namespace always begins with the name of a top-level element in the root namespace, without regard to the name (if any) of the root namespace. 7.2.5.4 Imports A namespace may import visible memberships from other namespaces. The complete set of memberships of a namespace include all its owned memberships and all its imported memberships, and the member elements of imported memberships are included in the set of members of the namespace. Various kinds of namespaces may also define additional memberships to be included in the set of memberships of that kind of namespace (for instance, the memberships of a type also include its inherited members – see 7.3.2 ) and which of those are visible (e.g., public inherited memberships). If the member name or member short name of any imported membership conflicts with the name of any owned member, or with the name of any visible membership from any other imported namespace, then the conflicting membership is hidden and is not included in the set of imported memberships of the importing namespace. As a result of this rule and the distinguishability rule for owned members (see 7.2.5.2 ), the names of all owned and imported members will always be distinct from each other. Any specialized kind of namespace that adds further kinds of memberships (e.g., inherited memberships of types) always maintains the property that the names of all memberships of a namespace are distinct from each other. The namespace that is the source of an import relationship, known as the importing namespace, also owns it. There are two types of import relationships. A membership import is a relationship between the importing namespace and a single membership, which becomes an imported membership of the importing namespace. A namespace import is a relationship between the importing namespace and an imported namespace, in which all visible memberships of the imported namespace become imported memberships of the importing namespace. Kernel Modeling Language v1.0 23 -A membership import is denoted using the keyword import followed by a qualified name, which identifies the imported membership (be member name or member short name). The member element of the imported membership becomes an imported member of the importing namespace. Note that the imported membership may be for an alias of the imported member (see 7.2.5.2 ), in which case the element will be known by that name in the importing namespace. namespace N6 { private import N4::A; private import N4::C; // Imported with name "C". namespace M { import C; // "C" is re-imported from N4 into M. } } A namespace import is also denoted using the keyword import followed by a qualified name, but with the qualified name suffixed by "::* ". In this case, the qualified name identifies the imported namespace. All visible memberships of the imported namespace then become imported memberships of the importing namespace. namespace N7 { // Memberships A, B and C are all imported from N4. private import N4::*; } If the declaration of either a membership or namespace import is further suffixed by " ::** ", then the import is recursive. Such an import is equivalent to importing memberships as described above for either an imported membership or namespace, followed by further recursively importing from each imported member that is itself a namespace, with the following limitations: 1. Recursive import only continues with a namespace that is either the imported element of an original recursive membership import or an owned member of an imported namespace. 2. Memberships inherited via implied specializations (of any kind) are not imported by recursive imports (see also 7.3.2.3 on Specialization and 8.4.2 on Semantic Constraints and Implied Relationships). namespace N8 { class A; class B; namespace M { class C; } } namespace N9 { private import N8::**; // The above recursive import is equivalent to all // of the following taken together: // import N8; // import N8::*; // import N8::M::*; } namespace N10 { private import N8::*::**; // The above recursive import is equivalent to all // of the following taken together: // import N8::*; // import N8::M::*; // (Note that N8 itself is not imported.) } The visibility of an import is always shown explicitly by placing the keyword private , protected , or public before the import declaration. If the import is private (which is the default in the abstract syntax), then the imported memberships become private relative to the importing namespace. A visibility of protected is the 24 Kernel Modeling Language v1.0 -same as private , unless the importing namespace is a type, in which case the imported memberships are also visible in all specializations of the type (see also 7.3.2.3 on protected visibility). If the import is public , then all the imported memberships become public for the importing namespace. An import declaration may optionally have a body, as described for relationships in 7.2.2.3 . namespace N11 { public import N4::A { /* The imported membership is visible outside N11. */ } private import N5::* { doc /* None of the imported memberships are visible * outside of N11. */ } } If an import is owned by a root namespace (see 7.2.5.3 ), then the memberships imported by it are visible to and within all the top-level elements of the root namespace. However, an import owned by a root namespace is required to be private, so none of the imported memberships become globally visible outside of the root namespace. (This rule disallows the "re-export" of the same element from multiple different root namespaces, which would cause ambiguity that could complicate the resolution of unqualified, globally-visible names.) An import may also be declared with one or more filter conditions. Given as model-level evaluable Boolean expressions (see 7.4.9 ), listed after the imported membership or namespace specification, each surrounded by square brackets [ ... ] . Such a filtered import is equivalent to importing an implicit package that then both imports the given imported membership or namespace and has all the given filter conditions. The effect is such that, for a filtered import, memberships are imported if and only if they satisfy all the given filter conditions. (While filtered imports may be used in any namespace, packages and filter conditions are actually Kernel-layer concepts, because expressions are only defined in that layer. See 7.4.14 .) namespace N12 { private import Annotations::*; // Only import elements of NA that are annotated as Approved. private import NA::*[@Approved]; } 7.3 Core 7.3.1 Core Overview The Core layer builds on the Root layer to add the minimum constructs for modeling systems as designed, built and operated. Semantics is about how models are interpreted as giving conditions on how things should be (i.e., as a specification of a modeled system) or as a reflection of how things are (i.e, as a description of a modeled system). KerML semantics are based on classification: a model has elements that classify things in the modeled system. A type is the most general kind of model element that classifies things (see 8.2.4.1.1 ). Classifiers are types that classify things, such as cars, people and processes being carried out, as well as how they are related by features (see 7.3.3 ). Features are also types, classifying relations between things (see 8.2.4.3.1 ). In addition to simple relations between two things, KerML allows features to classify longer chains of relations. For example, cars owned by people who live in a particular city might be required to be registered. These cars are identified by a chain of two relations, first the ownership of the car, then the residence of the owner. KerML also supports taxonomies of classifications using specialization relationships between types. All the things classified by a specialized type are also classified by the general types it is related to via specialization relationships. This means that all the things classified by a specialized type have all the features of its general types, referred to as inheriting features from general to specific types. KerML includes several special kinds of specialization, Kernel Modeling Language v1.0 25 -including subclassification between classifiers, subsetting and redefinition between features, and feature typing between a feature and another type. 7.3.2 Types 7.3.2.1 Types Overview Metamodel references: • Concrete syntax, 8.2.4.1 • Abstract syntax, 8.3.3.1 • Semantics, 8.4.3.2 Types classify things in a modeled system. The set of things classified by a type is the extent of the type, each member of which is an instance of the type. Everything being modeled is an instance of the type Anything from the Base library model (see 9.2.2 ). A type gives conditions for what things must be in or not in its extent (sufficient and necessary conditions, respectively). The simplest conditions directly identify instances that must be in or not in the extent. Other conditions can give characteristics of instances indicating they must be in or not in the extent. These conditions apply to all procedures that determine the extents of types, including logical solving, inference, and execution. For example, a type Car could require every instance in its extent (everything it classifies) to have four wheels, which means anything that does not have four wheels is not in its extent (necessary condition). It does not mean all four wheeled things are in the extent (are cars), however. (Note that necessary conditions are usually stated as what must be true of all instances in the extent, even though they really only determine what is not.) Alternatively, Car could require all four wheeled things to be in its extent (sufficient condition). Types are namespaces, enabling them to have members via membership relationships to other elements identified as their members (see 7.2.5 ). These include inherited memberships, which are certain memberships from the general types of their owned specializations (see 7.3.2.3 ). The member names of all inherited memberships must be distinct from each other and from the member names of all owned memberships. A membership that would otherwise be imported is hidden by an inherited membership with the same member name, similarly to how it would be hidden by a conflicting owned membership (see 7.2.5 ). Note. Name conflicts due to inherited memberships can be resolved by redefining them to give non-conflicting member names (see 7.3.4 ). 7.3.2.2 Type Declaration A type is declared using the keyword type , optionally followed by a short name and/or name. In addition, a type declaration defines either one or more owned specializations for the type (see 7.3.2.3 ) or a conjugator for the type (see 7.3.2.4 ). This may optionally be followed by the definition of one or more owned disjoinings (see 7.3.2.5 ). type A specializes Base::Anything disjoint from B; type C conjugates A; A type is specified as abstract by placing the keyword abstract before the keyword type . A type that is not abstract is called a concrete type. Declaring a type to be abstract means that all instances of the type must also be instances of at least one concrete type that directly or indirectly specializes the abstract type. abstract type A specializes Base::Anything; type A1 specializes A; type A2 specializes A; The multiplicity constrains the number of instances in the extent of a type (the cardinality of the extent). A multiplicity is a feature whose values are natural numbers (extended with infinity, see 9.3.2.1 ) that are the only ones 26 Kernel Modeling Language v1.0 -allowed for the cardinality of its featuring type (each multiplicity is the feature of exactly one Type). A type can have at most one feature that is its multiplicity. Cardinality for classifiers is the number of things it classifies. For features that are not end features (see below), cardinality is the number of values of the feature for a specific instance of its featuring types. Note. The semantics of multiplicity is different for features that are identified as end features. End Features are used primarily in the definition of associations and connectors, and the semantics of end features is discussed in conjunction with them (see 7.4.5 and 7.4.6 , respectively). The multiplicity of a type can be specified as a range after any identification of the Type, between square brackets [ ... ] . (See 7.4.12 for a complete description of multiplicity ranges, including declaring named multiplicity features.) // This Type has exactly one instance. type Singleton[1] specializes Base::Anything; The body of a type is specified as for a generic namespace, by listing the members between curly braces { ... } (see 7.2.5.2 ). However, for types, protected members, indicated using the keyword protected instead of public or private , have special visibility rules for inheritance (see 7.3.2.3 ). A feature declared as an owned member of a type is automatically considered to be an owned feature of the type, related by a feature membership, unless its declaration is preceded by the keyword member , in which case it is related by regular membership (see 7.3.2.6 for details). type Super specializes Base::Anything { private namespace N { type Sub specializes Super; } protected feature f : N::Sub; member feature f1 : Super featured by N::Sub; } The conditions that a type places on its instances (e.g., what feature it has) are always considered necessary. They can be indicated as sufficient by placing the keyword all after the keyword type . In this case, the type places additional sufficiency conditions on its instances corresponding to all the necessary conditions. For example, if Car requires all instances to be four-wheeled (necessary), and then is also indicated as sufficient, its extent will include all four wheeled things and no others. (See also the discussion in 7.3.2.1 .) type all Car specializes MaterialThing { feature wheels[4] : Wheel; } 7.3.2.3 Specialization Specializations are relationships between types, identified as specific and general, indicating that all instances of the specific type are instances of the general one (that is, the extent of the specific type is a subset of the extent of the general one, which might be the same set). This means instances of the specific type have all the features of the general one, referred to syntactically as inheriting features from general to specific types. A type may participate in multiple specialization relationships, both as specific and general types. A specialization relationship is declared using the keyword specialization , optionally followed by a short name and/or a name. The qualified name of the specific type, or a feature chain (see 7.3.4.6 ) if the specific type is such a feature, is then given after the keyword subtype , followed by the qualified name of the general type, or a feature chain if the general type is such a feature, after the keyword specializes . The symbol :> can be used interchangeably with the keyword specializes . A specialization declaration can also optionally have a relationship body (see 7.2.2.3 ) for, e.g., nested annotations. Kernel Modeling Language v1.0 27 -specialization Gen subtype A specializes B; specialization subtype x :> Base::things { doc /* This specialization is unnamed. */ } If no shortName or name is given, then the keyword specialization may be omitted. subtype C specializes A; subtype C specializes B; The direct supertypes of a type are all the general types in specializations for which the type is the specific type, and the direct subtypes of a type are all the specific types in specializations for which the type is the general type. Indirect supertypes include, recursively, the supertypes of the direct supertypes of a type, and similarly for indirect subtypes. Specialization relationships can form cycles, which means all types in the cycle have the same instances (same extent). However, since all types are required to specialize the base type Anything (directly or indirectly), no cycle of valid types can be entirely closed, unless it includes the type Anything . The owned specializations of a type are those specializations that are owned relationships of the type (see 7.2.2 ), for which the type is the specific type. An owned specialization of a type is defined as part of the declaration of the type, rather than in a separate declaration, by including the qualified name or feature chain of the general type in a list after the keyword specializes (or the symbol :> ). type C specializes A, B; type f :> Base::things; A type inherits all visible and protected memberships of the general types of its owned specializations. Protected memberships are all owned and inherited memberships of the general type whose visibility is declared as protected (see also 7.3.2.2 on protected visibility) and all memberships imported via imports with visibility protected (see also 7.2.5.4 on import visibility). This means protected memberships are memberships that are only visible to their owning type and to (direct or indirect) specializations of it. type A specializes Base::Anything { feature f; // Public by default. protected feature g; private feature h; } type B specializes A { // B inherits feature memberships for // f and g, but not h. } 7.3.2.4 Conjugation Conjugation is a relationship between types, identified as the original type and the conjugated type, indicating the conjugated type inherits visible and protected memberships from the original type, except the direction of input and output features is reversed (see 7.3.4.1 on features with direction). Features with direction in relative to the original type are treated as having direction out relative to the conjugated type, and vice versa for direction out treated as in . Features with no direction or direction inout in the original type are inherited without change. A conjugation relationship is declared using the keyword conjugation , followed by a short name and/or a name. The qualified name of the conjugated type, or a feature chain (see 7.3.4.6 ) if the conjugated type is such a feature, is then given after the keyword conjugate , followed by the qualified name of the original type, or a feature chain if the original type is such a feature, after the keyword conjugates . The symbol ~ can be used interchangeably with the keyword conjugates . A conjugation declaration can also optionally have a relationship body (see 7.2.2.3 ) for, e.g., nested annotations. 28 Kernel Modeling Language v1.0 -type Original specializes Base::Anything { in feature Input; } type Conjugate1 specializes Base::Anything; type Conjugate2 specializes Base::Anything; conjugation c1 conjugate Conjugate1 conjugates Original; conjugation c2 conjugate Conjugate2 ~ Original { doc /* This conjugation is equivalent to c1. */ } If no short name or name is given, then the keyword conjugation may be omitted. conjugate Conjugate1 conjugates Original; conjugate Conjugate2 ~ Original; An owned conjugation is an owned relationship of a type ( 7.2.2 ) that is a conjugation relationship, for which the type is the conjugated type. An owned conjugation for a type is defined as part of the declaration of the type, rather than in a separate declaration, by including the qualified name or feature chain of the original type after the keyword conjugates (or the symbol ~ ). type Conjugate1 conjugates Original; type Conjugate2 ~ Conjugate1; A type can be the conjugated type of at most one conjugation relationship, and a conjugated type cannot be the specific type in any specialization relationship. 7.3.2.5 Disjoining Types related by disjoining do not share instances (instances cannot be in more than one of the extents; the extents are disjoint). For example, a classifier for mammals is disjoint from a classifier for minerals, and a feature for people's parents is disjoint from a feature for their children. A disjoining relationship is declared using the keyword disjoining , optionally followed by a short name and/or a name. The qualified name of the first type, or a feature chain (see 7.3.4.6 ) if the type is such a feature, is then given after the keyword disjoint , followed by the qualified name of the second type, or a feature chain, if the the type is such a feature, after the keyword from . A disjoining declaration can also optionally have a relationship body (see 7.2.2.3 ) for, e.g., nested annotations. disjoining Disj disjoint A from B; disjoining disjoint Mammal from Mineral; disjoining disjoint Person::parents from Person::children { doc /* No Person can have a parent as a child. */ } If no short name or name is given, then the keyword disjoining may be omitted. disjoint A from B; disjoint Mammal from Mineral; disjoint Person::parents from Person::children; An owned disjoining of a type is an owned relationship of the type (see 7.2.2 ) that is a disjoining relationship. An owned disjoining is defined as part of the declaration of the type, rather than in a separate declaration, by including the qualified name or feature chain of the disjoining type in a list after the keyword disjoint from , placed after any owned specializations. type C specializes Anything disjoint from A, B; type Mammal :> Animal disjoint from Mineral; Kernel Modeling Language v1.0 29 -7.3.2.6 Feature Membership A feature membership is a relationship between a type and a feature that is a kind of owning membership that also implies type featuring (see 7.3.4.8 ). Features related to a type via feature membership are identified as owned features of the type. The owning type is one of the feature's featuring types, meaning that the feature specifies a relation between the owning type and the type of the feature. A feature that is declared within the body of a type is normally an owned feature of that type, so it automatically has that type as a featuring type. This also applies to the bodies of classifiers (see 7.3.3 ) and features (see 7.3.4 ), since they are kinds of types. A feature may also be aliased in a type like any other Element (see 7.2.5 ), in which case it is related to the aliasing type by a regular membership relationship, not a feature membership, and, so, does not become one of the owned features of the type. feature person[*] : Person; classifier Person { // This declares an owned feature using a feature membership. feature age[1] : ScalarValues::Integer; // This is not a feature membership. alias personAlias for person; } However, if a feature declaration in the body of type is preceded by the keyword member , then the feature is owned by the containing type via a membership relationship, not a feature membership. In this case, the feature is not an owned feature of the containing type, and it does not automatically have the containing type as a featuring type, though it may have featuring types declared in its featured by list (see 7.3.4.1 on declaring the owned typings of a feature). classifier A; classifier B { // Feature f has B as its featuring type. feature f; // Feature g has A as its featuring type, not B. member feature g featured by A; } 7.3.2.7 Unioning, Intersecting, and Differencing Unioning, intersecting, and differencing are relationships between an owning type and a set of other types. 1. Unioning specifies that the owning type classifies everything that is classified by any of the unioned types. 2. Intersecting specifies that the owning type classifies everything that is classified by all of the intersecting types. 3. Differencing specifies that the owning type classifies everything that is classified by the first of the differenced types but not by any of the remaining types. Since these relationships are always owned by the source type, they are defined as part of the declaration of that type, using the keywords unions , intersects , and differences , respectively, followed by a list of qualified names (or feature chains, if appropriate, see 7.3.4.6 ) of the related types. These relationship clauses are placed after any owned specializations (see 7.3.2.3 ) but may otherwise appear in any order with each other and with any disjoining clause (see 7.3.2.5 ). classifier Adult; classifier Child; classifier Person unions Adult, Child { feature dependents : Child[*]; feature offspring : Person[*]; 30 Kernel Modeling Language v1.0 -feature grownOffspring : Adult[*] :> offspring; feature dependentOffspring : Child[*] :> dependents, offspring differences offspring, grownOffspring intersects dependents, offspring; } Multiple relationships of each kind can be specified using multiple clauses in a single declaration. In the case of differencing, any additional differences clauses after the first one mean that the owning type does not classify anything classified by any of the related types. It is not allowable, though, for a type to have just one of any of these relationships over all. // This is valid. classifier Person unions Adult unions Child; // This is NOT valid. classifier Person unions Adult; 7.3.3 Classifiers 7.3.3.1 Classifiers Overview Metamodel references: • Concrete syntax, 8.2.4.2 • Abstract syntax, 8.3.3.2 • Semantics, 8.4.3.3 Classifiers are types that classify things in the modeled system, as distinct from features, which model the relations between them (see 7.3.4 ). Subclassification is a kind of specialization that specifically relates classifiers. 7.3.3.2 Classifier Declaration The notation for a classifier is the same as the generic notation for a type (see 7.3.2.2 ), except using the keyword classifier rather than type . However, any general types referenced in a specializes list must be Classifiers, and the specializations defined are specifically subclassifications (see 7.3.3.3 ). A classifier is also not required to have any owned subclassifications explicitly specified. If no explicit subclassification is given for a classifier, and the classifier is not conjugated, then the classifier is given a default subclassification to the most general base classifier Anything from the Base library model (see 9.2.2 ). classifier Person { // Default superclassifier is Base::Anything. feature age : ScalarValues::Integer; } classifier Child specializes Person; The declaration of a classifier may also specify that the classifier is a conjugated type (see 7.3.2.4 ), in which case the original type must also be a classifier. classifier FuelInPort { in feature fuelFlow : Fuel; } classifier FuelOutPort conjugates FuelInPort; 7.3.3.3 Subclassification A subclassification relationship is declared using the keyword specialization , optionally followed by a short name and/or a name. The qualified name of the subclassifier is then given after the keyword subclassifier , followed by the qualified name of the superclassifier after the keyword specializes . The symbol :> can be used Kernel Modeling Language v1.0 31 -interchangeably with the keyword specializes . A subclassification declaration can also optionally have a relationship body (see 7.2.2.3 ) for, e.g., nested annotations. specialization Super subclassifier A specializes B; specialization subclassifier B :> A { /* This subclassification is unnamed. */ } If no short name or name is given, then the keyword specialization may be omitted. subclassifier C specializes A; subclassifier C specializes B; An owned subclassification of a classifier is defined as part of the declaration of the classifier, rather than in a separate declaration, by including the qualified name of the superclassifier in a list after the keyword specializes (or the symbol :> ). classifier C specializes A, B; 7.3.4 Features 7.3.4.1 Features Overview Metamodel references: • Concrete syntax, 8.2.4.3 • Abstract syntax, 8.3.3.3 • Semantics, 8.4.3.4 Features are types that classify how things in a modeled system are related, including by chains of relations. Relations between things can also be treated as things, allowing relations between relations, recurring as many times as needed. A feature relates instances in the intersection of the extents of its featuring types (the domain) with instances in the intersection of the extents of its featured types (the co-domain). Instances in the domain of a feature are said to "have values" that are instances of the co-domain. The domain of features with no explicit featuring types is the type Anything from the Base library model (see 9.2.2 ). Type featuring is a relationship between a feature and a type that identifies the type as a featuring type of the feature. Feature membership is a kind of owning membership that also implies type featuring, by which a type owns a feature and becomes a featuring type of that feature (see 7.3.2.6 ). There are also several forms of specialization that apply specifically to features. • Feature typing is a relationship between a feature and a type that identifies the type as a featured type of the feature. • Subsetting is a relationship between a specific feature (the subsetting feature) and a more general feature (the subsetted feature), where the specific feature may further constrain the featuring types, featured types and multiplicity of the general feature. • Redefinition is a kind of subsetting in which the specific feature (the redefining feature) also replaces an otherwise inherited general feature (the redefined feature) in the context of the owning type of the specific feature. 7.3.4.2 Feature Declaration The notation for a feature is similar to the generic notation for a type (see 7.3.2.2 ), except using the keyword feature rather than type . Further, a feature can have any of three kinds of specialization, each identified by a specific keyword or equivalent symbol: 32 Kernel Modeling Language v1.0 -• typed by or : – Specifies FeatureTyping (see 7.3.4.3 ). • subsets or :> – Specifies Subsetting (see 7.3.4.4 ). • redefines or :>> – Specifies Redefinition (see 7.3.4.5 ). In general, clauses for the different kinds of Specialization can appear in any order in a Feature declaration. feature x typed by A, B subsets f redefines g; // Equivalent declaration: feature x redefines g typed by A subsets f typed by B; If no subsetting (or redefinition) is explicitly specified for a feature, and the feature is not conjugated, then the feature is given a default subsetting of the most general base feature things from the Base library model (see 9.2.2 ). This is true even if a feature typing is given for the feature. abstract feature person : Person; // Default subsets Base::things. feature child subsets person; The declaration of a feature may also specify that the feature is a conjugated type (see 7.3.2.4 ), in which case the original type must also be a feature. In this case, the feature must not have any owned specializations. classifier Tanks { feature fuelInPort { in feature fuelFlow : Fuel; } feature fuelOutPort ~ fuelInPort; } As for any type, the multiplicity of a feature can be given in square brackets [ ... ] after any identification of the feature (see also 7.3.2.2 ). However, the multiplicity for a feature can also be placed after one of the specialization clauses in the feature declaration, but, in all cases, only one multiplicity may be specified. In particular, this allows a notation style for multiplicity consistent with that used in previous modeling languages (such as [UML]). It is also useful when redefining a Feature without giving an explicit name (see 7.3.4.5 ). feature parent[2] : Person; feature mother : Person[1] :> parent; feature redefines children[0]; In addition to, or instead of, an explicit multiplicity, a feature declaration can include either or both of the following keywords (in either order). The properties flagged by these keywords are only meaningful if the feature has a multiplicity upper bound greater than one. • nonunique – If a feature is non-unique, then, for any domain instance, the same co-domain instance may appear more than once as a value of the feature. The default is that the feature is unique. • ordered – If a feature is ordered, then for any domain instance, the values of the feature can be placed in order, indexed from 1 to the number of values. The default is that the feature is unordered. feature sensorReadings : ScalarValues::Real [*] nonunique ordered; There are four other kinds of relationships that can be declared as owned relationships of a feature, each indicated by a specific keyword: • disjoint from – Specifies disjoining (see 7.3.2.5 ). • chains – Specifies feature chaining (see 7.3.4.6 ). • inverse of – Specifies feature inverting (see 7.3.4.7 ). • featured by – Specifies type featuring (see 7.3.4.7 ). Kernel Modeling Language v1.0 33 -The clauses for these relationships must appear after any specialization or conjugation part, but can otherwise appear in any order. feature cousins : Person[*] chains parents.siblings.children featured by Person; feature children : Person[*] featured by Person inverse of parents; There are a number of additional properties of a feature that can be flagged by adding specific keywords to its declaration. If present, these are always specified in the following order, before the keyword feature : 1. in , out , inout – Specifies the direction of a feature, which determines what is allowed to change its values on instances of its domain: ◦ in – Things "outside" the instance. These features identify things input to an instance. ◦ out – The instance itself or things "inside" it. These features identify things output by an instance. ◦ inout – Both things "outside" and "inside" the instance. These features identify things that are both input to and output by an instance. 2. derived – Specifies that the feature is derived. Such a feature is typically expected to have a bound feature value expression that completely determines its value at all times (see 7.4.11 on feature values, which is a kernel concept). 3. abstract – Specifies that the feature is abstract (see 7.3.2.2 on abstract types in general). 4. composite or portion – Specifies that the feature is either a composite or portion feature (specifying both is not allowed). ◦ Values of a composite feature, on each instance of the feature's domain, cannot exist after the featuring instance ceases to exist. This only applies to values at the time the instance goes out of existence, not to other things in the co-domain that might have been values before that. Values of a composite feature also cannot be values of another composite feature that is not on the same instance of the feature's domain. Values of a composite feature also cannot be values of another composite feature that is not on the same instance of the feature's domain. ◦ Portions are features whose values cannot exist without the whole, because they are the “same thing” as the whole. (For example, the portion of a person's life when they are a child cannot be added or removed from that person's life.) 5. var or const – Specifies that the feature is variable or constant (specifying both is not allowed). Portions cannot be variable or constant. ◦ Values of a variable feature may vary in time over the duration of a featuring instance. ◦ A constant feature is one that is potentially variable but has been constrained to have the same values over the entire duration of a featuring instance. (This is useful, for example, to redefine a variable feature to be constant over some temporal portion of a featuring instance.) (Note that the semantics of composite , portion , var and const require a model of things existing in time, which is provided in the Kernel layer, see 7.4.3 . See also the discussion of end features in 7.4.5 .) abstract classifier Account { abstract feature ntries : Entry[*] ordered; derived feature balance = sum(entries.amount); } classifier Tank specializes Object { in var feature fuelFlow: Fuel; var feature fuel : Fuel { portion feature fuelPortion : Fuel; } } 7.3.4.3 Feature Typing A feature typing relationship is declared using the keyword specialization , optionally followed by a short name and/or a name. The qualified name of the typed feature is then given after the keyword typing , followed by the 34 Kernel Modeling Language v1.0 -qualified name of the type, or a feature chain (see 7.3.4.6 ), after the keyword typed by . The symbol : can be used interchangeably with the keyword typed by . A feature typing declaration can also optionally have a relationship body (see 7.2.2.3 ) for, e.g., nested annotations. specialization t1 typing customer typed by Person; specialization t2 typing employer : Organization { doc /* An employer is an Organization. */ } If no short name or name is given, then the keyword specialization may be omitted. typing customer typed by Person; typing employer : Organization; An owned feature typing is a feature typing that is an owned relationship of its type feature. An owned feature typing is defined as part of the declaration of the typed feature, rather than in a separate declaration, by including the qualified name or feature chain for the type in a list after the keyword typed by (or the symbol : ). feature foodItem typed by Food, InventoryItem; 7.3.4.4 Subsetting Subsetting is a kind of specialization between two features. This means that the values of the subsetting feature are also values of the subsetted feature on each instance (separately) of the domain of the subsetting feature. A subsetting relationship is declared using the keyword specialization , optionally followed by a short name and/or a name. The qualified name of the subsetting feature, or a feature chain (see 7.3.4.6 ), is then given after the keyword subset , followed by the qualified name of the subsetted feature, or a feature chain, after the keyword subsets . The symbol :> can be used interchangeably with the keyword subsets . A subsetting declaration can also optionally have a relationship body (see 7.2.2.3 ) for, e.g., nested annotations. specialization Sub subset parent subsets person; specialization subset mother subsets parent { doc /* All mothers are parents. */ } If no short name or name is given, then the keyword specialization may be omitted. subset rearWheels subsets wheels; subset rearWheels subsets driveWheels; An owned subsetting is a subsetting that is an owned relationship of the subsetting feature. An owned subsetting is defined as part of the declaration of the subsetting feature, rather than in a separate declaration, by including the qualified name or feature chain of the subsetted feature in a list after the keyword subsets (or the symbol :> ). feature rearWheels subsets wheels, driveWheels; A subsetting feature can restrict aspects of the subsetted feature, otherwise it will, by default, have the same properties as the subsetted feature. In particular, a subsetting feature can constrain its featured types to be specializations of those of the subsetted feature and add additional feature types. A subsetting feature can also restrict the multiplicity of its subsetted feature to allow cardinalities that are smaller than those of the subsetted feature (e.g., by specifying smaller lower and/or upper bounds). classifier Wheel; classifier DriveWheel specializes Wheel; feature anyWheels[*] : Wheel; classifier Automobile { Kernel Modeling Language v1.0 35 -// Restricts multiplicity composite feature wheels[4] subsets anyWheels; // Restricts multiplicity and type. composite feature driveWheels[2] : DriveWheel subsets wheels; } If a subsetted feature is ordered, then the subsetting feature must also be ordered. If the subsetted feature is unordered, then the subsetting feature will be unordered by default, unless explicitly flagged as ordered . classifier Automobile { composite feature wheels[4] ordered subsets anyWheels; // driveWheels must be ordered because wheels is ordered. composite feature driveWheels[2] ordered : DriveWheel subsets wheels; } If a subsetted feature is unique, then the subsetting feature must not be specified as non-unique. If the subsetted feature is non-unique, then the subsetting feature will still be unique by default, unless specifically flagged as nonunique . feature urls[*] nonunique : URL; classifier Server { feature accessibleURLs subsets urls; // Unique by default. feature visibleURLs subsets accessibleURLs; // Cannot be nonunique. } 7.3.4.5 Redefinition Redefinition is a kind of subsetting that requires the values of the redefining feature and the redefined feature to be the same on each instance (separately) of the domain of the redefining feature. This means any restrictions on the values of the redefining feature relative to the redefined feature, such as typing or multiplicity, also apply to the values of the redefined feature, and vice versa. A redefinition relationship is declared using the keyword specialization , optionally followed by a short name and/or a name. The qualified name of the redefining feature, or a feature chain (see 7.3.4.6 ), is then given after the keyword redefinition , followed by the qualified name of the redefined feature, or a feature chain, after the keyword redefines . The symbol :>> can be used interchangeably with the keyword redefines . A redefinition declaration can also optionally have a relationship body (see 7.2.2.3 ) for, e.g., nested annotations. specialization Redef redefinition LegalRecord::guardian redefines parent; specialization redefinition Vehicle::vin redefines RegisteredAsset::identifier { doc /* A "vin" is a Vehicle Identification Number. */ } If no short name or name is given, then the keyword specialization may be omitted. redefinition Vehicle::vin redefines RegisteredAsset::identifier; redefinition Vehicle::vin redefines legalIdentification; A feature can only be redefined once for any featuring type. A feature without any feature types is considered to be implicitly featured by the most general base type Anything (see 7.3.4.1 ). It is therefore allowable to redefine such a feature by a redefining feature that does have some other featuring type. It is, however, illegal for one such feature to redefine another, because that would correspond to a semantically inconsistent redefinition of one feature of Anything by another. The restrictions on the specification of the multiplicity, ordering and uniqueness of a subsetting feature (see 7.3.4.4 ) also apply to a redefining feature. In addition, the multiplicity of a redefining feature must only allow cardinalities that are consistent with the multiplicity of the redefined feature (e.g., it cannot have a multiplicity lower bound that is less than that of the redefined feature). 36 Kernel Modeling Language v1.0 -An owned redefinition is a redefinition that is an owned relationship of its redefining feature. An owned redefinition of a feature is defined as part of the declaration of the feature, rather than in a separate declaration, by including the qualified name or feature chain of the redefined feature in a list after the keyword redefines (or the symbol :>> ). feature vin redefines RegisteredAsset::identifier, legalIdentification; If a redefining feature is declared as an owned feature of a type (see 7.3.2.6 ), then each of the redefined features of its owned redefinitions must be features that would otherwise be inherited from supertypes of its owning type. When redefined, however, these otherwise inheritable features are not inherited and are, instead, replaced by the redefining feature. This enables the redefining feature to have the same name as a redefined feature, if desired. (Note, however, that even though a redefined feature is not in the namespace of the owning type of the redefining feature, the redefined feature still has values on instances of that type, particularly when they are considered as instances of the supertype that owns the redefined feature. The values will be the same as for the redefining feature, as described above.) In general, the resolution of a qualified name begins with the namespace in which the name appears and proceeds outwards from there to containing namespaces (see 8.2.3.5 ). However, the resolution of the qualified names of redefined features of owned redefinitions follow special rules. In particular, the local namespace of the owning type of the redefining feature is not included in the name resolution of the redefined features, with resolution beginning instead with the direct supertypes of the owning type. Since redefined features are not inherited, they would not be included in the local namespace of the owning type and, therefore, could not be referenced by an unqualified name. The special rules for redefined features, however, allow such a reference, because the name resolution begins with the namespaces of the supertypes of the owning type, one of which must contain the redefined feature. classifier RegisteredAsset { feature identifier : Identifier; } classifier Vehicle : RegisteredAsset { // Owning type. // Legal even though "identifier" is not inherited. feature vin redefines identifier; } If neither a name nor a short name is given in the declaration of a feature with an owned redefinition, then the feature is implicitly given the same name and short name as the first redefined feature (which may itself have implicit names, if the redefined feature is itself a redefining feature). These implicit names are used in name resolution, just as explicitly declared names would be. This is useful when declaring a feature that redefines another feature in order to constrain it, while maintaining the same naming. classifier WheeledVehicle { // The declared name is "wheels". composite feature wheels[1..*] : Wheel; } classifier MotorizedVehicle specializes WheeledVehicle { // The effective name is "wheels", the same name as // WheeledVehicle::wheels, which is being redefined. composite feature redefines wheels[2..4]; } classifier Automobile specializes MotorizedVehicle { // The effecive name is "wheels", the same (effective) name // as "MotorizedVehicle::wheels", which is being redefined. composite feature redefines wheels[4] : AutomobileWheel; } 7.3.4.6 Feature Chaining Feature chaining is an owned relationship between the owning chained feature and a chaining feature. If a feature has any chaining features, then it must have at least two. The list of chaining features of a chained feature is called its feature chain. Kernel Modeling Language v1.0 37 -The meaning of a chained feature depends on its feature chain. The values of a chained feature are the same as the values of the last feature in the chain. These can be found by starting with the values of the first feature (for each instance of the chained feature's domain), then on each of those, finding the values of the second feature in the chain, and so on, to values of the last feature. If a chained feature is ordered, any ordering of values earlier in the chain are imposed on values found later in the chain. If a chained feature is non-unique, duplicate values found in the last feature of the chain (which might be due to multiple values of the earlier features) are preserved in the chained feature, otherwise the last feature can have no duplicates. A feature chain is notated as a sequence of two or more qualified names separated by dot ( . ) symbols. Each qualified name in a feature chain must resolve to a feature. The first qualified name in a feature chain is resolved in the local namespace as usual (see 8.2.3.5 ). Subsequent qualified names are then resolved using the previously resolved feature as the context namespace (but considering only visible memberships). This notation specifies a list of chaining features, as given by the resolution of the qualified names in the chain, in order. The feature chain notation can be placed after the keyword chains in the declaration of the Feature, appearing after any specialization or conjugation part, but before any disjoining or type featuring part (see also 7.3.4.2 ). feature cousins chains parents.siblings.children; The featuring types of the chaining feature are implicitly considered to include the featuring types of the first chaining feature. Similarly, the featured types of the chaining feature are implicitly considered to include the featured types of the last chaining feature. The feature chain notation may also be used to specify a related element in the declaration of any of the following relationships: 1. Specialization (see 7.3.2.3 ) 2. Conugation (see 7.3.2.4 ) 3. Unioning, intersecting and differencing (see 7.3.2.7 ) 4. Disjoining (see 7.3.2.5 ) 5. Subsetting (see 7.3.4.4 ) 6. Redefinition (see 7.3.4.5 ) 7. Feature inverting (see 7.3.4.7 ) 8. Connector (see 7.4.6 , in the Kernel layer) In this case, the related element specified using the feature chain notation becomes an owned related feature of the relationship with the feature chain as notated. feature uncles subsets parents.siblings; feature cousins redefines parents.siblings.children; connector vehicle.wheelAssembly.wheels to vehicle.road; Note. A similar dot notation is also used for the related Kernel-layer concept of a feature chain expression (see 7.4.9.3 ). However, it is always syntactically unambiguous as to whether the notation should be parsed as a plain feature chain or as a feature chain expression. 7.3.4.7 Feature Inverting Feature inverting is a relationship between two features whose interpretations as relations are the inverse of each other. For example, a feature identifying each person's parents is the inverse of a feature identifying each person's children. A person identified as a parent of another will identify that other as one of their children. A feature inverting relationship is declared using the keyword inverting , optionally followed by a short name and/or a name. The qualified name of the first feature, or a feature chain (see 7.3.4.6 ), is then given after the keyword inverse , followed by the qualified name of the second feature, or a feature chain, after the keyword of . A feature inverting declaration can also optionally have a relationship body (see 7.2.2.3 ) for, e.g., nested annotations. 38 Kernel Modeling Language v1.0 -inverting parent_child inverse Person::parent of Person::child { doc /* A Person is the parent of their children. */ } If no short name or name is given, then the keyword inverting may be omitted. inverse Person::parents of Person::children; An owned feature inverting is a feature inverting that is an owned relationship of its first feature. An owned feature inverting is defined as part of the declaration of the inverted feature, rather than in a separate declaration, by giving the qualified name or feature chain of the other feature after the keyword inverse of . classifier Person { feature children : Person[*]; feature parents : Person[*] inverse of children; } Note that only a single feature identification is allowed after inverse of . While it is possible to declare multiple feature inverting relationships for a single feature, this is generally not useful. Inverse features can be arbitrarily nested. However, while it is allowable to use feature chains in the declaration of a feature inverting relationship, note that a feature chain is a separate feature from any of the features it chains. In order to indicate that two declared features are inverses, one should use qualified names rather than feature chains. classifier A { feature b1: B { feature c1: C; } } classifier C { feature b2: B { feature a2: A inverse of A::b1::c1; } } 7.3.4.8 Type Featuring Type featuring is a relationship between a feature and a type, identifying the type as a featuring type of the feature (see also 7.3.4.1 ). Feature membership is a kind of type featuring that also makes the feature an owned member of the featuring type (see 7.3.2.6 ). A type featuring relationship is declared using the keyword featuring , optionally followed by a short name and/or a name, and the keyword of . The qualified name of the featured feature is then given, followed by the qualified name of the featuring type after the keyword featured by . A type featuring declaration can also optionally have a relationship body (see 7.2.2.3 ) for, e.g., nested annotations. featuring engine_by_Vehicle of engine featured by Vehicle; featuring power featured by engine { doc /* The engine of a Vehicle has power. */ } An owned type featuring is a type featuring that is an owned relationship of the featured feature. An owned type featuring is defined as part of the declaration of the feature, rather than in a separate declaration, by including the qualified name of the featuring type in a list after the keyword featured by . classifier Vehicle; classifier PoweredComponent; feature engine : Engine featured by Vehicle, PoweredComponent; Kernel Modeling Language v1.0 39 -Note that the domain of a feature is given by the intersection of its featuring types. That is, in the above example, an instance in the domain of engine must be both a Vehicle and a PoweredComponent . 7.4 Kernel 7.4.1 Kernel Overview The Kernel layer completes KerML. It extends the Core layer to add modeling capabilities beyond basic classification. These include specialized classifiers for things that have the semantics of data values (data types) from others that have an independent existence over time and space (classes), and for reified relationships between things (associations). Classes have instances that exist or happen in time and space. They are divided into those for structure and behavior. Structures typically limit how things and relations between them might change over time, while behaviors specify changes within those limits. Structures and behaviors do not overlap, but structures can be involved in, perform, and own behaviors. Behaviors can coordinate other behaviors via steps (usages of behaviors). Functions are behaviors that yield a single result, which can be used to form trees of expressions. Interactions combine behaviors and associations. Some associations are also structures. The Kernel layer adds semantics beyond the Core primarily by specifying how model elements use the Kernel model library (see Clause 9 ), rather than be specified mathematically as in the Core. The Kernel textual syntax introduces keywords that translate to patterns of using Core abstract syntax and library models, acting as syntactic "markers" for modeling patterns tying Kernel to the Core. In the simplest case, this involves introducing implicit specializations of model library types. For example, classes must directly or indirectly subclassify the library class Occurrence , while behaviors must directly or indirectly subclassify the library class Performance . Sometimes more complicated reuse patterns are needed. For example, binary associations (with exactly two ends) specialize BinaryLink from the library, and additionally require the ends of the association to redefine the source and target ends of BinaryLink . This is also how other modeling languages can be built on KerML. Domain-specific metamodels and libraries can also reuse Kernel metamodel and libraries, inheriting the patterns of library reuse above, as well as the mathematical semantics they inherit from Core. This enables domain-specific modelers to use terms and syntax familiar to them and still benefit from automated assistance based on mathematically-defined semantics. 7.4.2 Data Types Metamodel references: • Concrete syntax, 8.2.5.1 • Abstract syntax, 8.3.4.1 • Semantics, 8.4.4.2 Data types are classifiers that classify data values (see 9.2.2.2.2 ). Certain primitive data types have specified extents of values, such as the numerical and other types from the ScalarValues library model (see 9.3.2 ). Other data types have features whose values can distinguish one instance of the data type from another. But, otherwise, different data values are not distinguishable. This means that data types cannot also be classes or associations, or share instances with them. It also means that data types classify things that do not exist in time or space, because they require changing relations to other things. The feature values of a data value cannot change over time, because different feature values would inherently identify a different data value. A data type is declared as a classifier (see 7.3.3 ), using the keyword datatype . If no owned superclassing is explicitly given for the data type, then it is implicitly given a default superclassing to the data type DataValue from the Base library model (see 9.2.2 ). 40 Kernel Modeling Language v1.0 -If any of the types of a feature are data types, then none of its types can be classes or associations, because classes and associations are disjoint from data types (see 8.4.4.2 ). If a feature has data types as its types, and no owned subsetting or owned redefinition is explicitly given in the feature declaration, then the feature is implicitly given a default subsetting to the Feature dataValues from the Base model library (see 9.2.2 ). datatype IdNumber specializes ScalarValues::Integer; datatype Reading { // Subtypes Base::DataValue by default feature sensorId : IdNumber; // Subsets Base::dataValues by default. feature value : ScalarValues::Real; } 7.4.3 Classes Metamodel references: • Concrete syntax, 8.2.5.2 • Abstract syntax, 8.3.4.2 • Semantics, 8.4.4.3 Classes are classifiers that classify occurrences, which exist in time and space (see 9.2.4 ). Relations between an occurrence and other things can change over time and space, while the occurrence still maintains an independent identity. A class is declared as a classifier (see 7.3.3 ), using the keyword class . If no owned superclassing is explicitly given for the class, then it is implicitly given a default superclassing to the class Occurrence from the Occurrences model library (see 9.2.4 ). If any of the types of a feature are classes, then none of its types can be data types, because data types are disjoint from classes (see 8.4.4.3 ). If a feature has class types, and no owned subsetting or owned redefinition is explicitly given in the feature declaration, then the feature is implicitly given a default subsetting to the feature occurrences from the Occurrences library model (see 9.2.4 ), unless at least one of the types is an association structure, in which case the default subclassing is as described in 7.4.5 . Some or all of the features of a class may be specified as variable features using the keyword var (see also 7.3.4.2 ). A variable feature is one whose values may vary over the lifetime of its featuring occurrence. A variable feature may subset a non-variable feature or a variable feature, but a non-variable feature may not subset a variable feature. class Situation { // Specializes Occurrences::Occurrence by default. feature kind : SituationCode; var feature condition : ConditionCode; var feature alarmSounding : ScalarValues::Boolean; } class SituationStatusMonitor specializes StatusMonitor { // Subsets Occurrences::occurrences by default. abstract feature lifetimeSituations : Situation[*]; var feature currentSituation : Situation subsets lifetimeSituations; } Alternatively, a features may be specified as a constant feature using the keyword const (see also 7.3.4.2 ). A constant feature is a potentially variable feature which has nevertheless been constrained to have unchanging values, perhaps within some limited context. A constant feature may subset any constant, variable or non-variable feature, but any subsetting feature of a constant feature must also be constant. class ControlledSituation specializes Situation { var feature underControl : ScalarValues::Boolean; portion controlPeriods[*] subsets timeSlices { const feature redefines underControl = true; const feature redefines condition; Kernel Modeling Language v1.0 41 -} } 7.4.4 Structures Metamodel references: • Concrete syntax, 8.2.5.3 • Abstract syntax, 8.3.4.3 • Semantics, 8.4.4.4 Structures are classes that classify objects, which are kinds of occurrences. Structures typically limit how their instances and relations between them can change over time, as opposed to Behaviors, which indicate how objects and their relations change. Structures and behaviors do not overlap, but structures can own behaviors, and the objects they classify can be involved in and perform behaviors. A structure is declared as a classifier (see 7.3.3 ), using the keyword struct . If no owned superclassing is explicitly given for the structure, then it is implicitly given a default superclassing to the structure Object from the Objects library model (see 9.2.5 ). If any of the types of a feature are structures, then all of them must be. If a feature has structure types, and no owned subsetting or owned redefinition is explicitly given in the feature declaration, then the feature is implicitly given a default subsetting to the feature objects from the Objects library model (see 9.2.5 ), unless at least one of the types is an association structure, in which case the default subsetting shall be as specified in 7.4.5 . struct Sensor { // Specializes Objects::Object by default. feature id : IdNumber; var feature currentReading : ScalarValues::Real; step updateReading { ... } // Performed behavior } struct SensorAssembly specializes Assembly { composite var feature sensors[*] : Sensor; // Subsets Objects::objects by default. } 7.4.5 Associations 7.4.5.1 Associations Overview Metamodel references: • Concrete syntax, 8.2.5.4 • Abstract syntax, 8.3.4.4 • Semantics, 8.4.4.5 Associations are classifiers that classify links between things (see 9.2.3.1 ). Unless the association is abstract, at least two of its features must be association ends, which identify the things being linked by (at the "ends" of) each link (exactly one thing per end, which might be the same thing). Associations with exactly two association ends are called binary associations. The end features of an association identify the participants in the links that are instances of the association and must have multiplicity 1..1 . Associations can also have features that are not end features, which characterize each instance of the association separately from the things it links. An association is also a relationship between the types of its association ends, called its related types (which need not be unique). Links are between instances of an association's related types. For binary associations, the two related types are identified as the source type and the target type (which may be the same). For associations with more than two association ends ("n-ary"), the first related type is the source type and all the remaining related types are target types. 42 Kernel Modeling Language v1.0 -7.4.5.2 Association Declaration An association is declared as a classifier (see 7.3.3 ), using the keyword assoc . Association ends are declared as features (see 7.3.4.2 ), prefixed by the keyword end . If no owned superclassification is explicitly given for the association, then it is implicitly given a default superclassification to either the association BinaryLink (if it is a binary association) or the association Link (otherwise), both of which are from the Links library model (see 9.2.3 ). assoc Ownership { // Specializes Links::BinaryLink by default. end feature owner[1] : LegalEntity; // Redefines BinaryLink::source. end feature ownedAsset[1] : Asset; // Redefines BinaryLink::target. feature valuationOnPurchase : MonetaryValue; } The keyword feature may also be omitted from an association end declaration (unless it has an owned cross feature, as described later). assoc Ownership { end owner[1] : LegalEntity; end ownedAsset[1] : Asset; feature valuationOnPurchase : MonetaryValue; } Note. For a binary association, the source and target ends are already declared to have multiplicity 1..1 , so this does not need to be redeclared in redefinitions of these features. However, for non-binary associations, the end multiplicity must be explicitly declared as 1..1 to override the usual default of 0..* . For a binary association, one or both association ends can be explicitly declared to subset a cross feature owned by the other related type. This is done with cross subsetting, which is a special kind of subsetting relationship specified using the keyword crosses or the symbol => . Only end features may have cross subsetting relationships, and an end feature can have at most one owned cross subsetting. classifier LegalEntity { feature assetsOwned [*] ordered : Asset; } classifier Asset { feature owningEntities [1..*] : LegalEntity; } assoc AssetOwnership { end feature owner : LegalEntity crosses ownedAsset.owningEntities; end feature ownedAsset : Asset => owner.assetsOwned; feature valuationOnPurchase : MonetaryValue; } This specifies that each instance of the AssetOwnership association must link a value of the owningEntities feature of the ownedAsset with a value of the assetsOwned feature of the owner . That is, creating a AssetOwnership link between a LegalEntity and an Asset means that the Asset must be one of the assetsOwned by the LegalEntity and that the LegalEntity must be one of the owningEntities of the Asset . As shown above, the target of a cross subsetting relationship must be a feature chain (see 7.3.4.6 ) in which the first feature is the other association end and the second feature is the cross feature for that end. Cross feature multiplicity effectively constrains the number of instances of an association. It applies to each set of instances (links) of the association that have the same (single) values for each of the other ends. For a binary association, this is the same as the number of values resulting from "navigating" across the association from an instance of one related type to instances of the other related type. Cross feature uniqueness and ordering apply to the instances navigated to, preventing duplication among them and ordering them to form a sequence. For example, given a specific Asset , navigating across all AssetOwnership links with that Asset as the ownedAsset to the corresponding owner gives a collection of LegalEntities that must be the same as the Kernel Modeling Language v1.0 43 -owningEntities of the Asset . The owningEntities feature has a multiplicity lower bound of 1 , requiring that there must be at least one AssetOwnership link for every Asset . Similarly, given a specific LegalEntity , navigating across all AssetOwnership links with that LegalEntity as the owner to the corresponding ownedAssets gives a collection of Assets that must be the same as the assetsOwned of the LegalEntity . The declaration of assetsOwned as ordered means that this collection is ordered in the same order as the assetsOwned of the LegalEntity . Similarly, if assetsOwned were non-unique, the collection could contain duplicate Assets . Note that these semantics presume that values of cross features are exclusively due to the existence of links between them. However, it is still possible for the cross features to have values that do not correspond to any links, allowing the cross features to meet their multiplicity constraints without requiring corresponding links exist. That is, the declaration of cross features imposes necessary but not sufficient conditions on links that are instances of the association (see 7.3.2.1 ). To make these conditions also sufficient, requiring instances of the association to exist when cross feature values do, the association declaration can include the all keyword (see 7.3.2.2 ). For example, as declared above, it is possible for a LegalEntity to have assetsOwned for which there are no instances of AssetOwnership linking the LegalEntity to the corresponding Assets . But with the declaration below, adding just an all keyword, a LegalEntity having an Asset as one of its assetsOwned is sufficient to require that an AssetOwnership link exists between that LegalEntity and that Asset , and, therefore, that the LegalEntity is also one of the owningEntities of the Asset . assoc all AssetOwnership { end feature owner : LegalEntity crosses ownedAsset.owningEntities; end feature ownedAsset : Asset => owner.assetsOwned; feature valuationOnPurchase : MonetaryValue; } It is also possible to declare cross features directly in the declaration of the ends of an association, rather than nested in the related types of the association. Such owned cross features are declared between the end and feature keywords of the association end declarations (and, in this case, the feature keyword is required). These may be full feature declarations, including declared name and or short name, owned subsettings and redefinitions, etc., but without bodies and nested elements (see 7.3.4.2 on feature declaration). assoc LegalAssetOwnership { end owningEntities[1..*] feature owner : LegalEntity; end assetsOwned[*] ordered feature ownedAsset : Asset; feature valuationOnPurchase : MonetaryValue; } Note. Owned cross features are in the namespace of the owning association ends, so their names are qualified by the name of the association ends, e,g., LegalAssetOwnership::owner::owningEntities . For a binary association, an owned cross feature is implied to be featured by the type of the other association end, rather than its owning association end. Further, an association end with a cross feature has an implied cross subsetting relationship to the cross feature through the other end feature. This ensures owned cross features have the same semantics as cross features that are nested directly in the related types of the association. (For further details, see 8.4.4.5 on association semantics.) Note. If an association end has an owned cross feature, then it may not have an explicit cross subsetting relationship declared to an unowned cross feature. While owned cross features can have full feature declarations, it is often sufficient to just include the cross multiplicity, ordering, and/or uniqueness on one or more association ends. assoc LegalAssetOwnership { end [1..*] feature owner : LegalEntity; end [*] ordered feature ownedAsset : Asset; 44 Kernel Modeling Language v1.0 -feature valuationOnPurchase : MonetaryValue; } This specifies that every Asset must have one or more LegalEntities as its owners , and that every LegalEntity may have zero or more Assets as ownedAssets , which are ordered. Note that the association ends themselves, as participants of the association, still always have multiplicity 1..1 , whether or not this is included in the declaration. Cross features can also be used in associations with more than two ends. In general, the cross multiplicity, ordering, and uniqueness of an association end apply to the the collection of its values from each set of instances of the association that have the same (single) values for each of the other ends. assoc AgreedAssetOwnership { end [*] feature owner : LegalEntity; end [*] ordered feature ownedAsset : Asset; end [0..1] feature agreement : OwnershipAgreement; } The cross multiplicity 0..1 for agreement requires that, for every pair of a LegalEntity and an Asset , at most one AgreedAssetOwnership instance may link that LegalEntity as its owner and Asset as its ownedAsset to an OwnershipAgreement as its agreement . Similarly, every pair of a LegalEntity as owner and an OwnershipAgreement as agreement may be linked to any number of Assets as ownedAsset , including none at all, as declared by the cross multiplicity of ownedAsset . This collection of linked Assests is ordered, as declared by the cross ordering of ownedAsset . The same applies to the cross multiplicity of owner . (For further details, see 8.4.4.5 on association semantics.) If an association has a single superclassifier that is an association, it may inherit association ends from this superclassifier association. However, if it declares any owned association ends, then each of these must redefine an association end of the superclassifier association, in order, up to the number of association ends of the superclassifier. If no redefinition is given explicitly for an owned association end, then it is considered to implicitly redefine the association end at the same position, in order, of the superclassifier Association (including implicit defaults), if any. An implicitly or explicitly redefining association end may also further constrain the cross multiplicity (if any) of the superclassifier association ends that it redefines. assoc SoleAssetOwnership specializes LegalAssetOwnership { end [1] feature owner; // Redefines LegalAssetOwnership::owner. // ownedAsset is inherited as an association end. // valuationOnPurchase is inherited as a non-end feature. } If an association has more than one superclassifier that is an association, then the association must declare a number of owned association ends at least equal to the maximum number of association ends of any of its superclassifier associations. Each of these owned association ends must then redefine the corresponding association end (if any) at the same position, in order, of each of the superclassifier associations. If a feature has one or more association types, then it must subset the feature links from the Links library model (see 9.2.3 ). If any of the types are binary associations, then it must subset the feature binaryLinks from the Links library model (see 9.2.3 ). If necessary, the feature is given implicit subsettings to meet these requirements. (See also 7.4.6 on connectors as features typed by associations.) 7.4.5.3 Association Structures Association structures are both associations and structures (see 7.4.4 on structures), classifying link objects, which are both links and objects (see 9.2.5.1 on objects). As objects, link objects can be created and destroyed, and their non-end features can change over time if they are variable and not constant (see also 7.3.4.2 ). However, the end features of a link object are always constant, their values cannot change over its lifetime. Kernel Modeling Language v1.0 45 -An association structure is declared like a regular association (see 7.4.5.2 ), but using the keyword assoc struct . An association structure must directly or indirectly specialize the base associations structure LinkObject . If this is not the case due to the explicit owned superclassifications in its declaration, then it is implicitly given a default superclassification to either the association structure BinaryLinkObject (if it is a binary association structure) or the association structure LinkObject (otherwise), both of which are from the Objects library model (see 9.2.5 ). The same rules on association ends described in 7.4.5.2 for associations also apply to association structures. An association structure may specialize an association that is not an association structure, but all subclassifications of an association structure must be association structures. struct LegalEntity { var feature assetsOwned [*] ordered : Asset; } struct Asset { var feature owningEntities [1..*] : LegalEntity; } assoc struct ExtendedAssetOwnership { // Specializes Objects::BinaryLinkObject by default. end feature owner : LegalEntity crosses ownedAsset.owningEntities; end feature ownedAsset : Asset crosses owner.assetsOwned; feature valuationOnPurchase : MonetaryValue; // The values of the feature "revaluations" may change over time. var feature revaluations[*] ordered : MonetaryValue; } The end features of an association structure may also be declared as constant features by placing the keyword const before the keyword end . Whether or not an end feature is declared as constant, its value cannot change for the lifetime of an instance of the owning association structure. However, a constant end feature may subset or redefine a variable feature, while a regular end feature cannot. struct AssetOwnershipRecord { var feature owner : LegalEntity [1]; var feature ownedAsset : Asset [1]; } assoc struct AssetOwnershipRelationship specializes AssetOwnershipRecord { const end feature redefines owner; const end feature redefines ownedAsset; } If a feature has one or more types that are association structures, then it must subset the feature linkObjects from the Objects library model (see 9.2.5 ). If any of the types are binary association structures, then it must subset the feature binaryLinkObjects from the Objects library model (see 9.2.5 ). If necessary, the feature is given implicit subsettings to meet these requirements. 7.4.6 Connectors 7.4.6.1 Connectors Overview Metamodel references: • Concrete syntax, 8.2.5.5 • Abstract syntax, 8.3.4.5 • Semantics, 8.4.4.6 Connectors are features that are typed by associations (see 7.4.5 ), having values that are links (see 9.2.3.1 ). Like an association, a connector has end features, known as its connector ends. Each connector end redefines an association end from each of the associations that type the connector and subsets a feature that becomes a related feature of the connector. Connectors typed by binary associations are called binary connectors. 46 Kernel Modeling Language v1.0 -A connector is also a relationship between its related features. For binary connectors, the two related features are identified as the source feature and the target feature, which might be the same. For connectors with more that two connector ends ("n-ary"), the first related feature is the source feature and all the remaining related features are target features. Connectors can be thought of as "instance-specific" associations, because their values (which are links) are each limited to linking things identified via related features on the same instance of the connector's domain (or by things identified by that instance, recursively, see below). For example, an association could be used to model an engine driving wheels, and to type a connector in the car model. This connector specifies an engine driving wheels only in the same car, not in another car, as would be allowed with just the association. Specifically, the values (links) of a connector are restricted to those that link things 1. classified by the types of its association ends, regardless of the domain of the connector 2. identified by its related features for the same instance of the domain of the connector (or by things identified by that instance, recursively). For example, if the wheels in a car are taken to be part of its drive train, rather than part of the car directly, then the engine in each car will drive wheels identified by that car's drive train, rather than a feature of the car directly. This requires that each related feature of a connector have some featuring type of the connector as a direct or indirect featuring type (where a feature with no featuring type is treated as if the classifier Anything was its featuring type). In particular, this condition is satisfied if a connector has an owned type that either also directly owns the related features of the connector or from which the related features can be reached by chaining (see 7.3.4.6 ). Otherwise, explicit owned type featurings (see 7.3.4.8 ) should be used to ensure that the connector has a sufficiently general domain. Binding connectors are binary connectors that require their source and target features to have the same values on each instance of their domain. They are typed by the library association SelfLink , which only links things in the modeled universe to themselves (see 9.2.3.1 ). To be meaningful, the declared co-domains of the related features of a binding connector must at least overlap. Since the interpretations of data types are disjoint from those of classes, this means that a feature typed by data types can only be bound to another feature typed by data types. In the determination of the equivalence of such features, indistinguishable data values are considered equivalent. The binding of features typed by classes to another feature typed by classes, on the other hand indicates that the same occurrences play the roles represented by each of the related features. Successions are binary connectors requiring their source and target features to identify Occurrences that are ordered in time. They are typed by the library association HappensBefore (see 9.2.4.1 ), which links occurrences that happen completely separately in time, with the connector's source feature being the earlier occurrence and the target feature being the later occurrence. 7.4.6.2 Connector Declaration A connector is declared as a feature (see 7.3.4.2 ) using the keyword connector . If no owned subsetting or owned redefinition is explicitly given for a connector, and none of its types are association structures, then the connector is implicitly given a default subsetting to the feature binaryLinks from the Links library model (see 9.2.3 ), if it is a binary connector, or to the feature links from the Links library model, otherwise. If at least one of the types of a connector is an association structure, then the default subsetting is instead to the feature binaryLinkObjects from the Objects library model (see 9.2.5 ), if it is a binary connector, or to the feature linkObjects from the Objects library model, otherwise. In addition, a connector declaration includes connector end features that reference the features related by the connector. The connector ends may either be owned by the connector or inherited from the associations that type it or other connectors that it subsets (see also the description of association ends in 7.4.5 ). Each owned end of a connector redefines the end at the corresponding position (if any) of each of the associations or connectors it specializes. A connector with more than two ends can also have more ends than any of its supertypes. However, a connector that specializes a binary association or connector must itself be binary, with exactly two ends. Kernel Modeling Language v1.0 47 -The related feature referenced by a connector end is specified using the keyword references or the equivalent symbol ::> . The number of connector ends is the same as the number of related features (including duplicates). // Specializes Objects::BinaryLinkObject by default. assoc struct Mounting { end feature mountingAxle : Axle; end feature mountedWheel : Wheel; } struct WheelAssembly { composite feature axle[1] : Axle; composite feature wheels[2] : Wheel; // Subsets Objects::binaryLinkObjects by default. connector mount[2] : Mounting { end feature mountingAxle references axle; end feature mountedWheel references wheels; } } The references notation indicates that connector end features have reference subsetting relationships to the features related by the connector. Reference subsetting has the same semantics as regular subsetting (see 7.3.4.4 ) but is used to syntactically differentiate one of the owned subsettings of a feature. While reference subsetting is used primarily for connector ends in KerML, it can actually be specified as an owned subsetting in the declaration of any kind of feature, using the references or ::> symbol. A feature is allowed to have at most one owned subsetting that is a reference subsetting. Instead of explicitly declaring connector ends in the body of the connector, they can be listed between parentheses, after the regular feature declaration part and before the body of the connector (if any). In this case, the end declarations are limited to be of the form e references f or e ::> f , where e is the name of an association end and f is the qualified name of a related feature. struct WheelAssembly { composite feature axle[1] : Axle; composite feature wheels[2] : Wheel; connector mount[2] : Mounting ( mountingAxle ::> axle, mountedWheel ::> wheels ); } The association end names can also be omitted, in which case the connector ends are matched in order to corresponding association ends. struct WheelAssembly { composite feature axle[1] : Axle; composite feature wheels[2] : Wheel; connector mount[2] : Mounting (axle, wheels); } By default, the connector ends of a connector are declared in the same order as the association ends of the types of the connector. However, if the connector has a single type, then the related features can be given in any order, with each related feature paired with an association end of the type using a notation of the form e references f or e ::> f , where e is the name of an association end and f is the qualified name of a related feature. In this case, the name of each association end must appear exactly once in the list of connector end declarations. A special notation can be used for a binary connector, in which the source related feature is referenced after the keyword from , and the target related feature is referenced after the keyword to . 48 Kernel Modeling Language v1.0 -struct WheelAssembly { composite feature axle[1] : Axle; composite feature wheels[2] : Wheel; connector mount : Mounting from axle to wheels; } If a binary connector declaration includes only the related features part, then the keyword from can be omitted. struct WheelAssembly { composite feature axle[1] : Axle; composite feature wheels[2] : Wheel; // Subsets Links::binaryLinks by default. connector axle to wheels; } If a binary connector has a single type, then the names of the association ends of the type can also be used in the declaration of the connector ends in the special notation for binary connectors. However, since the connector ends are always declared in order from source to target in this notation, the association end names given must match those from the type in the order they are declared for that type. struct WheelAssembly { composite feature axle[1] : Axle; composite feature wheels[2] : Wheel; connector mount[2] : Mounting from mountingAxle ::> axle to mountedWheel ::> wheels; } Connector ends may have cross features, specified using cross subsetting, as for association ends (see 7.4.5.2 ). The cross feature for the connector end further constrains any inherited cross feature(s). struct WheelAssembly { composite feature axle[1] : Axle { feature mountedWheels[2] : Wheel; } composite feature wheels[2] : Wheel; connector mount[2] : Mounting { end mountingAxle references axle; end mountedWheel references wheels crosses mountingAxle.mountedWheels; } } Connector ends may also have owned cross features. In the full notation for the end declaration, this is specified just as for an association end (see 7.4.5.2 ). struct WheelAssembly { composite feature halfAxles[2] : Axle; composite feature wheels[2] : Wheel; // Connects each one of the halfAxles to a different one of the wheels. connector mount[2] : Mounting { end [1] feature mountingAxle references halfAxles; end [1] feature mountedWheel references wheels; } } In the shorthand notations, a cross multiplicity (but not ordering or non-uniqueness) can be given at the beginning of the end declaration. Kernel Modeling Language v1.0 49 -struct WheelAssembly { composite feature halfAxles[2] : Axle; composite feature wheels[2] : Wheel; // Connects each one of the halfAxles to a different one of the wheels. connector mount[2] : Mounting from [1] halfAxles to [1] wheels; } Note that, if a connector is an owned feature of a type (as above), the context consistency condition for the related features of the connector (see 7.4.6.1 ) requires that these features also be directly or indirectly nested within the owning type. The feature chain dot notation (see 7.3.4.6 ) should be used when connecting so-called "deeply nested" features. While the resolution of a feature chain is similar to a qualified name, the feature path contextualizes the resolution of the final feature. Thus, for example, while the qualified name axle::halfAxles statically resolves to Axle::halfAxles , in the Feature chain axle.halfAxles , halfAxles is understood to be specifically the feature as nested in axle . struct Axle { composite feature halfAxles[2] : HalfAxle; } struct Wheel { composite feature hub : Hub[1]; composite feature tire : Tire[1]; } struct WheelAssembly { composite feature axle[1] : Axle; composite feature wheels[2] : Wheel; connector mount : Mounting from axle.halfAxles to wheels.hub; } 7.4.6.3 Binding Connector Declaration A binding connector is declared as a feature (see 7.3.4.2 ) using the keyword binding . In addition, a binding connector declaration gives, after the keyword of , the qualified names of the two related features that are bound by the binding connector, separated by the symbol = , after the regular feature declaration part and before the body of the binding connector (if any). If no owned subsetting or owned redefinition is explicitly given, then the binding connector is implicitly given a default subsetting to the feature selfLinks from the Links library model (see 9.2.3 ). Note that, due to this default subsetting, if no type is explicitly given for a binding connector, then it will implicitly have the type SelfLink (the type of selfLinks ). struct Vehicle { composite feature fuelTank { out var feature fuelFlowOut : Fuel; } composite feature engine { in var feature fuelFlowIn : Fuel; } // Subsets Links::selfLinks by default. binding fuelFlowBinding of fuelTank.fuelFlowOut = engine.fuelFlowIn; } If a binding connector declaration includes only the related features part, then the keyword of can be omitted. struct Vehicle { composite feature fuelTank { out var feature fuelFlowOut : Fuel; } 50 Kernel Modeling Language v1.0 -composite feature engine { in var feature fuelFlowIn : Fuel; } binding fuelTank.fuelFlowOut = engine.fuelFlowIn; } (See also 7.4.11 on the use of binding connectors with feature values.) 7.4.6.4 Succession Declaration A succession is declared as a feature (see 7.3.4.2 ) using the keyword succession . In addition, the succession declaration gives the qualified name of the source feature after the keyword first and the qualified name of the target feature after the keyword then . If no owned subsetting or owned redefinition is explicitly given, then the succession is implicitly given a default subsetting to the feature happensBeforeLinks from the Occurrences library model (see 9.2.4 ). Note that, due to this default subsetting, if no type is explicitly given for a succession, then it will implicitly have the type HappensBefore (the type of happensBeforeLinks ). behavior TakePicture { composite step focus : Focus; composite step shoot : Shoot; succession controlFlow first focus then shoot; } If a succession declaration includes only the related features part, then the keyword first can be omitted. behavior TakePicture { composite step focus : Focus; composite step shoot : Shoot; succession focus then shoot; } As for connector ends on regular connectors, constraining multiplicities can also be defined for the connector ends of successions. behavior TakePicture { composite step focus[*] : Focus; composite step shoot[1] : Shoot; // A focus may be preceded by a previous focus. succession [0..1] focus then [0..1] focus; // A shoot must follow a focus. succession [1] focus then [0..1] shoot; } 7.4.7 Behaviors 7.4.7.1 Behaviors Overview Metamodel references: • Concrete syntax, 8.2.5.6 • Abstract syntax, 8.3.4.6 • Semantics, 8.4.4.7 Behaviors are classes that classify performances, which are kinds of occurrences that can be spread out in disconnected portions of space and time (see 9.2.6 ). The performance of behaviors can cause effects on other things, including their existence and relations, some of which might be accepted as input to or provided as output from the behavior. Kernel Modeling Language v1.0 51 -Behaviors can have steps, which are features typed by behaviors, allowing the containing behavior to coordinate the performance of other behaviors. Steps can be ordered in time using succession connectors (see 7.4.6.4 ). They can also be connected by flows to model things flowing between the output of one step and the input of another. Steps can also nest other steps to augment or redefine steps inherited from their behavior types. 7.4.7.2 Behavior Declaration A behavior is declared as a classifier (see 7.3.3 ), using the keyword behavior . If no owned superclassing is explicitly given for the behavior, then it is implicitly given a default superclassing to the behavior Performance from the Performances library model (see 9.2.6 ). Features declared in the body of a behavior with a non-null direction (see 7.3.4.2 ) are considered to be the owned parameters of the behavior. Features with direction in are input parameters, those with direction out are output parameters, and those with direction inout are both input and output parameters. // Specializes Performances::Performance by default. behavior TakePicture { in scene : Scene; out picture : Picture; } Parameters are ordered in the lexical order they are declared in the body of a behavior. They may appear at any location within the body. If a behavior has owned subclassifications whose superclassifiers are behaviors, then each of the owned parameters of the subclassifier behavior must, in order, redefine the parameter at the same position of each of the superclassifier behaviors. The redefining parameters shall have the same direction as the redefined parameters. behavior A { in a1; out a2; } behavior B { in b1; out b2; } behavior C specializes A, B { in c1 redefines a1, b1; out c2 redefines a2, b2; } If there is a single superclassifier behavior, then the subclassifier behavior can declare fewer owned parameters than the superclassifier behavior, inheriting any additional parameters from the superclassifier (which are considered to be ordered after any owned parameters). If there is more than one superclassifier behavior, then every parameter from every superclassifier must be redefined by an owned parameter of the subclassifier. If every superclassifier parameter is redefined, then the subclassifier behavior may also declare additional parameters, ordered after the redefining parameters. If no redefinitions are given explicitly for a parameter, then the parameter is implicitly given owned redefinitions of superclassifier parameters sufficient to meet the previously stated requirements. behavior A1 :> A { in aa; } // aa redefines A::a1, A::a2 is inherited. behavior B1 :> B { in b1; out b2; inout b3; } // Redefinitions are implicit. behavior C1 :> A1, B1 { in c1; out c2; inout c3; } Steps (see 7.4.7.3 ) declared in the body of a behavior are the owned steps of the containing behavior. A behavior can also inherit or redefine non-private steps from any superclassifier Behavior. behavior Focus { in scene : Scene; out image : Image; } behavior Shoot { in image : Image; out picture : Picture; } behavior TakePicture { in scene : Scene; out picture : Picture; composite step focus : Focus; composite step shoot : Shoot; } 52 Kernel Modeling Language v1.0 -Though the performance of a behavior takes place over time, the order in which its steps are declared has no implication for temporal ordering of the performance of those steps. Any restriction on temporal order, or any other connections between the steps, must be modeled explicitly. behavior TakePicture { in scene : Scene; out picture : Picture; binding focus.scene = scene; composite step focus : Focus; succession focus then shoot; composite flow focus.image to shoot.image; composite step shoot : Shoot; binding picture = shoot.picture; } 7.4.7.3 Step Declaration A step is declared as a feature (see 7.3.4.2 ) using the keyword step . If no owned subsetting or owned redefinition is explicitly given, then the step is implicitly given a default subsetting to the feature performances from the Performances library model (see 9.2.6 ). As for a behavior, directed features declared in the body of a step are considered to be parameters of the step (see 7.4.7.2 ). If a step has owned specializations (including all feature typings, subsettings, and redefinitions), whose general type is a behavior or a step. then the rules for the redefinition of parameters of the behaviors and steps are the same as for the redefinition of the parameters of superclassifier behaviors by a subclassifier behavior (see 7.4.7.2 ). step focus : Focus { // Parameters redefine parameters of Focus. in scene; out image; } // Parameters are inherited. step refocus subsets focus; A step can also have a body, which may have steps in it. A step can inherit or redefine steps from its behavior types or any other steps it subsets. step takePictureWithAutoFocus : TakePicture { in feature unfocusedScene redefines scene; step redefines focus : AutoFocus; out feature focusedPicture redefines picture; } 7.4.8 Functions 7.4.8.1 Functions Overview Metamodel references: • Concrete syntax, 8.2.5.7 • Abstract syntax, 8.3.4.7 • Semantics, 8.4.4.8 Functions are behaviors (see 7.4.7 ) with one out parameter designated as the result parameter. Functions classify evaluations (see 9.2.6.2.4 ), which are kinds of performances that produce results as values of the result parameter. Like all behaviors, functions can change things, often referred to as "side effects". A pure function is one that has no Kernel Modeling Language v1.0 53 -side effects and always produces the same results given the same input values, similarly to a function in the mathematical sense. The numerical functions in the Kernel Function Library (see 9.4 ), for example, are pure functions. Expressions are steps (see 7.4.7 ) typed by only a single function, which means that their values are evaluations. An expression whose value is an evaluation with results is said to evaluate to those results. They can be steps in any behavior, but a function, in particular, can designate one of its expression steps as the result expression that gives the value of its result parameter. Expressions can have their own nested parameters, to augment or redefine those of their functions, including the result parameter. They can also own other expressions and designate a result expression, similarly to a function. (See also 7.4.9 for more on expressions). Predicates are functions whose result is a single Boolean value (that is, true or false). A predicate determines whether the values of its input parameters meet particular conditions at the time of its evaluation, resulting in true if they do, and false otherwise. Predicates classify boolean evaluations, which are specialized evaluations giving a Boolean result (see 9.2.6.2.1 ). Boolean expressions are expressions whose function is a predicate and, so, evaluate to a Boolean result. A boolean expression might, in general, evaluate to true at some times and false at other times. An invariant, though, is a boolean expression that must always evaluate to either true at all times or false at all times. By default, an invariant is asserted to always evaluate to true, while a negated invariant is asserted to always evaluate to false. 7.4.8.2 Function Declaration A function is declared as a behavior (see 7.4.7.2 ), using the keyword function . If no owned superclassing is explicitly given for a function, then it is implicitly given a default subclassification to the function Evaluation from the Performances library model (see 9.2.6 ). As for a behavior, any feature declared in the body of a function with an explicit direction is considered to be a parameter of the function. In addition, the result parameter of a function may be declared in its body by beginning the declaration with the keyword return (instead of a direction keyword). // Specializes Performances::Evaluation by default. function Velocity { in v_i : VelocityValue; in a : AccelerationValue; in dt : TimeValue; return v_f : VelocityValue; } If a function has owned subclassifications that are behaviors, then the rules for redefinition or inheritance of non- result parameters are the same as for a behavior (see 7.4.7.2 ). If some of the superclassifier behaviors are functions, then the result parameter of the subclassifier function must redefine the result parameters of the superclassifier functions. If, in this case, the result parameter of the subclassifier function has no owned redefinitions, then it is implicitly given redefinitions of the result parameter of each of the superclassifier functions. abstract function Dynamics { in initialState : DynamicState; in time : TimeValue; return : DynamicState; } function VehicleDynamics specializes Dynamics { // Each parameter redefines the corresponding superclassifier parameter in initialState : VehicleState; in time : TimeValue; return : VehicleState; } The body of a function is like the body of a behavior (see 7.4.7.2 ), with the optional addition of the declaration of a result expression at the end. A result expression is always written using the Expression notation described in 7.4.9 , 54 Kernel Modeling Language v1.0 -not using the Expression declaration notation from 7.4.8.3 . The result of the result expression is implicitly bound to the result parameter of the containing function. function Average { in scores[1..*] : Rational; return : Rational; sum(scores) / size(scores) } Note. A result expression is written without a final semicolon. The result of a function can also be explicitly bound, either using a binding connector (see 7.4.6.3 ) or a feature value on the result parameter declaration (see 7.4.11 ). In this case, the body of the function should not include a result expression. function Average { in scores[1..*] : Rational; return : Rational = sum(scores) / size(scores); } 7.4.8.3 Expression Declaration An expression can be declared as a step (see 7.4.7.3 ) using the keyword expr (see also 7.4.9 for more traditional expression notation). If no owned subsetting or owned redefinition is explicitly given, then the expression is implicitly given a default subsetting to the feature evaluations from the Performances library model (see 9.2.6 ). As for a step, directed features declared in the body of an expression are considered to be parameters of the expression (see 7.4.7.3 ). If an expression has owned specializations (including all feature typings, subsettings, and redefinitions) whose general type is a behavior (including a function) or a step (including an expression), then the rules for the redefinition of the parameters of those behaviors and steps are the same as for the redefinition of the parameters of superclassifier behaviors by a subclassifier function (see 7.4.8.2 ). expr computation : ComputeDynamics { // Parameters redefined parameters of ComputeDynamics. in state; in dt; return result; } expr vehicleComputation subsets computation { // Input parameters are inherited, result is redefined. return : VehicleState; } Like a function body, an expression body can also specify a result expression. expr : VehicleDynamics { in initialState; in time; return result; vehicleComputation(initialState, time) } Or the result can be explicitly bound. expr : Dynamics { in initialState; in time; Kernel Modeling Language v1.0 55 -return result : VehicleState = vehicleComputation(initialState, time); } 7.4.8.4 Predicate Declaration A predicate is declared as a function (see 7.4.8 ), using the keyword predicate . If no owned subclassification is explicitly given for a predicate, then it is implicitly given a default subclassification to the predicate BooleanEvaluation from the Performances library model (see 9.2.6 ). If a predicate has owned subclassifications that are behaviors, then the rules for redefinition or inheritance of non-result parameters are the same as for a function (see 7.4.8.2 ). Since a predicate must always return a Boolean result, it is not necessary to explicitly declare a result parameter for it. However, if a result parameter is declared, then it must have type Boolean from the ScalarValues library model (see 9.3.2 ) and multiplicity 1..1 (see 7.4.12 ). predicate isAssembled { in assembly : Assembly; in subassemblies[*] : Assembly; } The body of a predicate is the same as a function body (see 7.4.8 ). If a result expression is included, then it must have a Boolean result. predicate isFull { in tank : FuelTank; tank.fuelLevel == tank.maxFuelLevel } 7.4.8.5 Boolean Expression and Invariant Declaration A boolean expression is declared as an expression (see 7.4.8.3 ), using the keyword bool . If no owned subsetting or owned redefinition is explicitly given, then the boolean expression is implicitly given a default subsetting to the feature booleanEvaluations from the Performances library model (see 9.2.6 ). As for an expression, directed features declared in the body of a boolean expression are considered to be parameters of the boolean expression (see 7.4.8.3 ). If a boolean expression has owned specializations (including all feature typings, subsettings, and redefinitions) whose general type is a behavior or step, then the rules for the redefinition of the parameters of those behaviors and steps are the same as for a regular expression declaration (see 7.4.8.3 ). The requirements on, and default for, the result parameter of a boolean expression are the same as for a predicate (see 7.4.8.4 ). // All input parameters are inherited. bool assemblyChecks[*] : isAssembled; Like a predicate body (see 7.4.8.4 ), a boolean expression body can specify a Boolean result expression. class FuelTank { feature fuelLevel : Real; feature readonly maxFuelLevel : Real; bool isFull { fuelLevel == maxFuelLevel } } An invariant is declared like any other boolean expression, except using the keyword inv instead of bool , and, additionally, this keyword may be optionally followed by one of the keywords true or false , to indicate whether the invariant is asserted to be true or false (i.e., is negated). The default is true . class FuelTank { feature fuelLevel : Real; feature readonly maxFuelLevel : Real; 56 Kernel Modeling Language v1.0 -// The invariant is asserted true by default. inv { fuelLevel >= 0 & fuelLevel <= maxFuelLevel } // The invariant is explicitly asserted false, that is, it is negated. inv false { fuelLevel > maxFuelLevel } } 7.4.9 Expressions 7.4.9.1 Expressions Overview Metamodel references: • Concrete syntax, 8.2.5.8 • Abstract syntax, 8.3.4.8 • Semantics, 8.4.4.9 As described in 7.4.8 , expressions are steps typed by functions, and 7.4.8.3 covers the general notation for declaring an expression as a step. However, expressions are commonly organized into tree structures, with expressions as the nodes, and the input parameters of each expression bound to the result of each of its child expressions. KerML includes extensive textual notation for constructing expression trees, including traditional operator notations for functions in the Kernel Model Library (see Clause 9 ). These expression notations map entirely to an abstract syntax involving just a few specialized kinds of expressions: • The non-leaf nodes of an expression tree are invocation expressions, a kind of expression that specifies its input values as the results of other expressions (its argument expressions), one for each of the input parameters of its invoked function. • The edges of the tree are binding connectors between the input parameters of an invocation expression (redefining those of its function ) and the results of its argument expressions. • The leaf nodes are these kinds of expressions: ◦ Feature reference expressions evaluate to values of a referenced feature that is not part of the expression tree. ◦ Literal expressions evaluate to the literal value of one of the primitive data types from the ScalarValues model library (see 9.3.2 ). ◦ Null expressions evaluate to the empty set. An expression can also be the referent of a feature reference expression in an expression tree, as above. This enables the evaluation of the referent expression to be taken as the value of the argument of an invocation, rather than passing the value of the result of the evaluation. As a shorthand for doing this, the concrete syntax for an expression body (as described in 7.4.8.3 ) can be used as a leaf node in the expression syntax tree. A model-level evaluable expression is an expression that refers to metadata, which is data about model elements, rather than the things being modeled. Model-level evaluable expressions can give values to the features of metadata (see 7.4.13 ) and be used as element filtering conditions in packages (see 7.4.14 ). The expressiveness of model-level evaluable expressions is restricted to support this: • All null expressions, literal expressions and feature reference expressions are model-level evaluable. • An invocation expression is model-level evaluable if and only if it meets the following conditions: 1. All its argument expressions are model-level evaluable. 2. It invokes a function that is listed as being model-level evaluable in Table 5 (in 8.2.5.8.1 ) or Table 7 (in 8.2.5.8.2 ). 7.4.9.2 Operator Expressions Operator expression notation provides a shorthand for invocation expressions that invoke a library function represented as an operator symbol. ( Table 5 in 8.2.5.8.1 shows the mapping from operator symbols to the functions Kernel Modeling Language v1.0 57 -they represent from the Kernel Model Library.) An operator expression contains subexpressions called its operands that generally correspond to the argument expressions of the invocation expression, except in the case of operators representing control functions, in which case the evaluation of certain operands is as determined by the function. Operator expressions include the following: • Conditional expressions. The conditional test operator if is followed by three operands, with the symbol ? after the first operand and the keyword else after the second operand. A conditional expression evaluates to the value of its second or third operand, depending on whether the result of its first operand is true or false. Note that only one of the second or third operand is actually evaluated. if x >= 0? x else -x • Binary operator expressions. A binary operator is one that has two operands. The binary operators include numerical operators ( + , - , * , / , % , ^ , ** ), logical operators ( & , | , xor ), comparison operators ( == , != , < , > , <= , >= , === , !== ), and the range construction operator ( .. ). In general, both operands become arguments of the invocation expression, with their results being passed to the invocation of the function represented by the operator. However, the null-coalescing ( ?? ), conditional and ( and ), conditional or ( or ) and implication ( implies ) operators all correspond to control functions in which their second operand is only evaluated depending on a certain condition of the value of their first operand (whether it is null, true, false, or true, respectively). x + y list#(i) ?? default i > 0 and sensor#(i) != null sensor == null or sensor.reading > 0 The operators == and != apply to operands that have single values, testing whether they are equal or unequal, respectively. They also evaluate to true or false, respectively, if their operands are both null (no values). The operators === and !== apply specifically to values that are occurrences (see 9.2.4 ). They test whether two occurrences are portions (in space and/or time) of the same life occurrence. Informally, these operators test whether or not two occurrences have the same "identity". For data values (values that are not occurrences), === and !== are the same as == and != . currentPortion == tripPortion // True for same trip portions currentPortion === tripPortion // True for any two portions of same trip • Unary operator expressions. A unary operator is one that has a single operand. The result of evaluating the operand is passed to the invocation of the Function represented by the operator. The unary operators include the numerical operators + and - and the logical operator not . -x not isOutOfRange(sensor) not completed • Classification expressions. The classification operators are syntactically similar to binary operators, but, instead of an expression as their second operand, they take a type name. The classification operators istype and hastype test whether all of the values of their first operand is classified by the named type (either including or not including subtypes, respectively). The @ operator is similar to istype , but tests whether at least one of the values of its first operand is classified by the named type. Note that this means that istype and hastype evaluate to true on a null (empty list) value, while @ evaluates to false. sensors istype ThermalSensor // Are all sensors ThermalSensors? sensors @ ThermalSensor // Is any sensor a ThermalSensor? person hastype Administrator The classification operator as , known as the cast operator, performs an isType test of whether each of the values of its first operand is classified by the named type, and then it selects only those values that pass 58 Kernel Modeling Language v1.0 -the test to include in its result. The result values of such a cast expression (if any) are always guaranteed to be instances of the named type. sensors as ThermalSensor person as Administrator The classification operators may also be used without a first operand, in which case the first operand is implicitly Anything::self (see 9.2.2.2.1 ). This is useful, in particular, when used as a test within an element filter condition expression (see 7.4.14 ). istype ThermalSensor @ThermalSensor hastype Administrator as Supervisor • Metaclassification expressions. The metaclassification operators @@ and meta take the qualified name of any kind of element as their first operand and a metaclass (see 7.4.13 ) as their second operand. They are shorthands for classification expressions with the operators @ and as , respectively, and a metadata access expression (see 7.4.9.4 ) as their first operand. As such, @@ tests whether any metadata associated with an element are classified by the given metaclass, while meta filters the metadata associated with an element and evaluates to those that are classified by the given metaclass. // Shorthand for designModel.metadata @ ApprovalAnnotation designModel @@ ApprovalAnnotation // Shorthand for sensors.metadata as KerML::Feature sensors meta KerML::Feature // Evaluates to the string "sensors". (sensors meta KerML::Feature).name • Extent expressions. The extent operator all is syntactically similar to a unary operator, but, instead of an expression as its operand, it takes a type name. An extent expression evaluates to a sequence of all instances of the named type. all Sensor In an operator expression containing nested operator expressions, the nested expressions are implicitly grouped according to the precedence of the operators involved, as given in Table 6 (in 8.2.5.8.1 ). Operator expressions with higher precedence operators are grouped more tightly than those with lower precedence operators. In addition, all binary operators other than exponentiation group to the left. The exponentiation operators ( ^ and ** ) group to the right. For example, the operator expression: -w + x * y * z + a ^ b ^ c is considered equivalent to: ( (-w) + ( (x * y) * z ) ) + ( a ^ (b ^ c) ) 7.4.9.3 Primary Expressions Primary expression notation provides additional shorthands for certain kinds of invocation expressions.For those cases in which the invoked function is represented by an operator symbol, the symbol is mapped to the appropriate library function as given in Table 7 (in 8.2.5.8.2 ). Primary expressions include the following: • Index expression. An index expression specifies the invocation of the indexing function '#' from the BaseFunctions library model (see 9.4.2 ). The default behavior for this function is given by the Kernel Modeling Language v1.0 59 -specialization SequenceFunctions::'#' , for which the first operand is expected to evaluate to a sequence of values, and the second operand is expected to evaluate to an index into that sequence. Default indexing is from 1 using Natural numbers. Note that parentheses are required around the second operand. sensors#(activeSensorIndex) However, the behavior of the '#' operator is specialized for the OrderedCollection (see 9.3.3.2.7 ) and Array (see 9.3.3.2.1 ) data types from the Collections library model. In this case, the first operand must be a single value of one of these data types. For an Array , the second operand is a sequence of indexes whose size is the rank of the Array (i.e., the number of dimensions of the Array ). detectorArray#(n, m) • Sequence expression. A sequence expression consists of a list of one or more expressions separated by comma ( , ) symbols, optionally terminated by a final comma, all surrounded by parentheses ( ... ) . Such an expression specifies sequential invocations of the sequence concatenation function ',' from the BaseFunctions library model (see 9.4.2 ). The default behavior for this Function is given by the specialization SequenceFunctions::',' , which concatenates the sequence of values resulting from evaluating its two arguments. With this behavior, a sequence expression concatenates, in order, the results of evaluating all the listed expressions. (temperatureSensor, windSensor, precipitationSensor) ( 1, 3, 5, 7, 11, 13, ) A sequence expression with a single constituent expression simply evaluates to the value of the contained expression, as would be expected for a parenthesized expression. The empty sequence () is not actually a sequence expression, but, rather, an alternative notation for a null expression (see 7.4.9.4 ). (highValue + lowValue) / 2 Sequences of values are not themselves values. Therefore, sequences are "flat", with no element of a sequence itself being a sequence. For example, ((1, 2, 3), 4), (1, (2, 3), 4) and (1, null, (2, 3, 4)) all evaluate to the same sequence of values as (1, 2, 3, 4) . To model nested collection values, use the data types from the Collections library model (see 9.3.3 ). • Feature chain expression. A feature chain expression consists of a primary expression and a feature qualified name or a feature chain ( 7.3.4.6 ), separated by a dot ( . ) symbol. The referenced feature is evaluated in the context of each of the result values of the primary expression, in order. The resulting feature values are then collected into a sequence in order of evaluation. The qualified name for the referent feature is resolved using the result parameter of the primary expression as the context namespace (see 8.2.3.5 ), but considering only visible memberships. // The primary expression is "getPlatform(id)". // The feature chain is "sensors.isActive". // Results in a sequence of Boolean values, // one for each platform sensor. getPlatform(id).sensors.isActive To avoid ambiguity, the primary expression of a feature chain expression cannot be itself a feature chain expression. To read a list of features sequentially, rather than in a single evaluation, delimit nested feature chain expressions using parentheses. // First evaluate "getPlaform(id).sensors", // then evaluate ".isActive" on the result of that. (getPlatform(id).sensors).isActive • Collect expression. A collect expression consists of a primary expression and an expression body (see 7.4.9.4 ) separated by a dot ( . ) symbol. The expression body must have a single input parameter. The 60 Kernel Modeling Language v1.0 -expression body is evaluated on each of the result values from the primary expression, in order, and each of the results are collected into a sequence in order of evaluation (that is, a collect expression is a shorthand for invoking the ControlFunctions::collect function). sensors.{in s: Sensor; s.reading} // results in a sequence of // readings of each of the sensors • Select expression. A select expression consists of a primary expression and an expression body (see 7.4.9.4 ) separated by a dot-question-mark ( .? ) symbol. The expression body must have a single input parameter and a Boolean result. The expression body is evaluated on each of the result values from the primary expression, in order, and those for which the expression body evaluates to true are selected for inclusion in the result of the select expression (that is, a select expression is a shorthand for invoking the ControlFunctions::select function). sensors.?{in s: Sensor; s.isActive} // results in the subsequence of // sensors that are active • Function operation expression. A function operation expression is a special syntax for an invocation expression in which the first argument is given before the arrow ( -> ) symbol, which is followed by the name of the function to be invoked and an argument list for any remaining arguments (see 7.4.9.4 ). This is useful for chaining invocations in an effective data flow. sensors -> selectSensorsOver(limit) -> computeCriticalValue() If the invoked function has exactly two input parameters, and the second input parameter is an expression, then an expression body (see 7.4.9.4 ) can be used as the argument for the second argument without surrounding parentheses. The argument expression body should declare parameters consistent with those on the parameter expression (if any). This is particularly useful when invoking functions from the ControlFunctions library model (see 9.4.17 ). sensors -> select {in s: Sensor; s::isActive} members -> reject {in member: Member; not member->isInGoodStanding()} factors -> reduce {in x: Real; in y: Real; x * y} If the argument expression is simply the direct invocation of another function, then the argument expression may be specified using simply the name of the invoked function. factors -> reduce RealFunctions::'*' 7.4.9.4 Base Expressions Base expression notation includes representations for literal expressions, null expressions, invocation expressions, feature reference expressions (including using expression bodies as base expressions). • Literal expressions are described in 7.4.9.5 . • A null expression is notated by the keyword null. A null expression always evaluates to a result of "no values", which is equivalent to the empty sequence () . • An invocation expression can be directly represented by giving the qualified name for the function to be invoked followed by a list of argument expressions, surrounded by parentheses () and separated by commas. The parentheses must be included, even if the argument list is empty. IntegerFunctions::'+'(i, j) isInGoodStanding(member#(n)) AddMember(org, member) The arguments are matched to the input parameters of the given function in order. Alternatively, the arguments may be matched to parameters by name, using the form paramName = argExpression , in Kernel Modeling Language v1.0 61 -which case they may be given in any order. Note that, if the named argument notation is used, it must be used for all arguments. AddMember(newMember = member, organization = org) If the qualified name given for an invocation expression resolves to an expression instead of a function, then the invocation expression is considered to subset the named expression, meaning that, effectively, the invocation is taken to be for the function of the named expression, as specialized by that expression. function UnaryFunction {in x : Anything; return: Anything;} function apply { in expr fn : UnaryFunction; in value : Anything; // Invokes UnaryFunction as specified by parameter fn. return : Anything = fn(value); } It is also possible to specify an expression to be invoked using a feature chain (see 7.3.4.6 ). class Stats { feature vales[1..*] : Real; expr avg { sum(values)/size(values) } } feature myStats : States { redefines feature values = (1.0, 2.0, 3.0); } feature myAvg = myStats.avg(); If the qualified name given for an invocation expression resolves to a behavior that is not a function (or a feature typed by a behavior that is not a function), then that behavior is performed and the result of the expression is the performance itself. This allows, for example, access to the values of the out parameters of the behavior computed during its performance. behavior RefineImage { in image : Image; out refinedImage : Image; out logMessages : String[*]; } feature run1 = RefineImage(image1); feature refinedImage1 = run1.refinedImage; feature log1 = run1.logMessages; • A constructor expression is represented by the keyword new followed by the qualified name of a type to be instantiated invoked followed by a parenthesized list of argument expressions, similarly to an invocation expression. The result of the expression is a new instance of the target type, with the results of the argument expressions bound to the public features of the type, in order or by name. class Member { feature firstName : String; feature lastName : String; feature memberNumber : Integer; feature sponsor : Member[0..1]; } feature thisMember = new Member("Jane", "Doe", 1234, null); feature nextMember = new Member( firstName = "John", lastName = "Doe", sponsor = thisMember, memberNumber = thisMember.memberNumber + 1); • A feature reference expression is represented simply by the qualified name of the feature being referenced. 62 Kernel Modeling Language v1.0 -member spacecraft::mainAssembly::sensors sensor::isActive Note that the referenced feature may be an expression. The notation for a reference to an expression is distinguished from the notation for an invocation by not having following parentheses. expr addOne : UnaryFunction { if x istype Integer? (x as Integer) + 1 else 0 } feature two = apply(addOne, 1); // "addOne" is a reference to expr addOne Rather than declaring a named expression in order to pass it as an argument, an expression body may be used directly as a base expression. In this case, any parameters must be declared as features with direction within the expression body (see 7.4.8.3 ). Such body expressions are particularly useful when used for the second argument of a function operation expression (see 7.4.9.3 ). feature two = apply({in x; if x istype Integer? (x as Integer) + 1 else 0}, 1); feature incrementedValues = values -> collect {in x: Number; x + 1}; • A metadata access expression is represented by suffixing the qualified name of any kind of element with the notation .metadata . This is a reflective expression that evaluates to the sequence of metadata features associated with the named element in the model itself, as instances of their respective metaclasses (see 7.4.13 on metadata and metaclasses). In addition, the last value in the sequence is an instance of the metaclass for the named element from the KerML reflective abstract syntax model (see 9.2.17 ), representing its instantiation as a model element. metaclass SecurityAnnotation; class SecureSystem { metadata SecurityAnnotation; } // Two values: an instance of SecurityAnnotation // and an instance of type KerML::Class. feature sysMetadata = SecureSystem.metadata; 7.4.9.5 Literal Expressions A literal expression is represented by giving a lexical literal for the value of the expression. • A literal Boolean is represented by either of the keywords true or false . • A literal string is represented by a lexical string value surrounded by double quotes " … " as specified in 8.2.2.5 . "This is a string literal." • A literal integer is represented by a lexical decimal value as specified in 8.2.2.4 . Note that notation is only provided for non-negative integers (i.e., natural numbers). Negative integers can be represented by applying the unary negation operator - (see 7.4.9.2 ) to an unsigned decimal literal. 0 1234 • A literal rational is represented with a syntax constructed from lexical decimal values and exponential values (see 8.2.2.4 ). The full rational number notation allows for a literal with a decimal point, with or without an exponential part, as well as an exponential value without a decimal point. Kernel Modeling Language v1.0 63 -3.14 .5 2.5E-10 1E+3 • A literal infinity is represented by the symbol * . 7.4.10 Interactions 7.4.10.1 Interactions Overview Metamodel references: • Concrete syntax, 8.2.5.9 • Abstract syntax, 8.3.4.9 • Semantics, 8.4.4.10 Interactions are behaviors that are also associations (see 7.4.7 and 7.4.5 , respectively), classifying performances that are also links between occurrences (see 9.2.3 through 9.2.6 ). They specify how the linked participants affect each other and collaborate. Transfers are interactions between two participants that carry payload values from one occurrence to another, with payload values optionally identified by output and input features of the source and target occurrence, respectively (see 9.2.7 ). Flows are steps that are also binary connectors (see 7.4.7 and 7.4.6 , respectively), with values that are transfers. A flow optionally ensures that a payload is transferred from an output feature of the connected source feature to an input feature of the target feature. Succession flows are flows that are also successions (see 7.4.6 ). They identify transfers that happen after their source (that is, after the end of the occurrence where the payload comes from) and before their target (that is, before the start of the occurrence where the payload goes to). 7.4.10.2 Interaction Declaration An interaction is declared as a behavior (see 7.4.7 ), using the keyword interaction . If no owned subclassification is explicitly given for the interaction, then it is implicitly given default subclassifications to both the behavior Performance from the Performances library model (see 9.2.6 ) and the association BinaryLink or the association Link from the Links library model (see 9.2.3 ), depending on whether it is a binary interaction or not. As a kind of behavior, if the interaction has owned subclassifications whose superclasses are behaviors, then the rules related to their parameters are the same as for any subclassifier behavior (see 7.4.7 ). As a kind of association, the body of an interaction must declare at least two association ends. If the interaction has owned subclassifications whose superclassifiers are associations, the rules related to their association ends are the same as for any association that is a subclassifier (see 7.4.5 ). interaction Authorization { end feature client[*] : Computer; end feature server[*] : Computer; composite step login; composite step authorize; composite succession login then authorize; } 7.4.10.3 Flow Declaration A flow declaration is syntactically similar to a binary connector declaration (see 7.4.6 ), using the keyword flow , or succession flow for a succession flow. If no owned subsetting or owned redefinition is explicitly given, then the 64 Kernel Modeling Language v1.0 -flow is implicitly given a default subsetting to the flow transfers from the Transfers model library (see 9.2.7 ), or to the succession flow transfersBefore , if a succession flow is being declared. If a flow has owned specializations (including all feature typings, subsettings, and redefinitions) whose general type is a behavior or a step, then the rules for the redefinition of the parameters of those behaviors and steps are the same as for the redefinition of the parameters of general behavior or step by a specializing step (see 7.4.7.3 ). Unlike a regular binary connector declaration, though, a flow declaration does not directly specify the related features for the flow. Instead, the declaration gives the source output feature for the transfer after the keyword from and the target input Feature for the transfer after the keyword to . The related features are then determined as the owning features of the features given in the flow declaration. It is these related features that are constrained to have a common context with the flow (see 7.4.6 ), not the features actually given in the declaration. struct Vehicle { composite feature fuelTank[1] { out var feature fuelOut[1] : Fuel; } composite feature engine { in var feature fuelIn[1] : Fuel; } // The flow actually connects the fuelTank to the engine. // The transfer moves Fuel from fuelOut to fuelIn. flow fuelFlow from fuelTank::fuelOut to engine::fuelIn; } The source output and target input features of a flow can also be specified using feature chains (see 7.3.4.6 ). In this case, the related features are determined as the features identified by the chains, excluding the last feature. This is particularly useful when the desired related features are inherited features. struct Vehicle { composite feature fuelTank[1] { out feature fuelOut[1] : Fuel; } composite feature engine[1] { in feature fuelIn[1] : Fuel; } } feature vehicle : Vehicle { // The flow actually connects the inherited fuelTank // feature to the inherited engine feature. flow fuelFlow from fuelTank.fuelOut to engine.fuelIn; } A flow declaration can also include an explicit declaration of the type and/or multiplicity of the payload that is flowing, after the keyword of . This asserts that anything transferred by the flow have the declared type. In the absence of an payload declaration, any values may flow across the flow, consistent with the types of the source output and target input features. flow of flowingFuel : Fuel from fuelTank.fuelOut to engine.fuelIn; If no feature declaration or payload declaration details are included in a flow declaration, then the keyword from may also be omitted. flow fuelTank.fuelOut to engine.fuelIn; Flows are also commonly used to move anything from the output parameters of one step to the input parameters of another step. Kernel Modeling Language v1.0 65 -behavior TakePicture { composite step focus : Focus { out image[1] : Image; } composite step shoot : Shoot { in image[1] : Image; } // The use of a succession flow means that focus must complete before // the image is transferred, after which shoot can begin. succession flow focus.image to shoot.image; } 7.4.11 Feature Values Metamodel references: • Concrete syntax, 8.2.5.10 • Abstract syntax, 8.3.4.10 • Semantics, 8.4.4.11 A feature value is a membership relationship (see 7.2.5 ) between an owning feature and a value expression, whose result provides values for the feature. The feature value relationship is specified as either bound or initial, and as either fixed or a default. A feature can have at most one feature value relationship. A fixed, bound feature value relationship is declared using the symbol = followed by a representation of the value expression using the concrete syntax described in 7.4.9 . This notation is appended to the declaration of the owning feature of the feature value. feature monthsInYear : Natural = 12; struct TestRecord { feature scores[1..*] : Integer; derived feature averageScore[1] : Rational = sum(scores)/size(scores); } Features that have a feature value relationship of this form implicitly have a nested binding connector (see 7.4.6 ) between the feature and the result of the value expression, with the binding connector having the same featuring types as the declared feature (i.e., TestRecord , in the example above). Note. The semantics of binding mean that such a feature value asserts that a feature is equivalent to the result of the value expression. To highlight this, a feature with such a feature value can be flagged as derived (though this is not required, nor is it required that the value of a derived feature be computed using a feature value – see also 7.3.4.2 ). A fixed, initial feature value relationship is declared as above but using the symbol := instead of = . var feature count[1] : Natural := 0; In this case, the feature also has an implicit nested binding connector, but the featuring types of the binding connector are the starting snapshots of the featuring types of the declared feature. That is, the result of the value expression gives the initial values of the declared feature but, unlike in the case of a bound value, these initial values may subsequently change. This means that only variable features (see 7.3.4.2 ) may have initial feature values. A default feature value relationship is declared similarly to the above, but with the keyword default preceding the symbol = or := , depending on whether it is bound or initial. However, for a default, bound feature value, the symbol = may be elided. struct Vehicle { var feature mass[1] : Real default 1500.0; var feature engine[1] : Engine default := standardEngine; } struct TestWithCutoff :> TestRecord { 66 Kernel Modeling Language v1.0 -feature cutoff[1] : Rational default = 0.75 * averageScore; } For a default feature value relationship, no binding connector is added to the feature declaration, but the default will apply when an instance of the featuring type is constructed, if no other explicit values are given for the feature. A feature value relationship can be included with the following kinds of feature declaration: • Feature (see 7.3.4.2 ) • Step (see 7.4.7.3 ) • Expression (see 7.4.8.3 ) • Boolean expression and invariant (see 7.4.8.5 ) behavior ProvidePower { in cmd[1] : Command; out wheelTorque[1] : Torque; composite step generate : GenerateTorque { in cmd = ProvidePower::cmd; out generatedTorque; } composite step apply : ApplyTorque { in generatedTorque = generate.generatedTorque; out appliedTorque = ProvidePower::wheelTorque; } } 7.4.12 Multiplicities Metamodel references: • Concrete syntax, 8.2.5.11 • Abstract syntax, 8.3.4.11 • Semantics, 8.4.4.12 Multiplicity is defined in the Core layer as a feature for specifying cardinalities (number of instances) of a type by enumerating all numbers the cardinality might be (see 7.3.2.2 ). The Kernel layer provides a specific way to do this by specifying a range of cardinalities. A multiplicity range has lower bound and upper bound expressions that are evaluated to determine the lowest and highest cardinalities, with both expression evaluating to natural numbers (that is, of type Natural from the ScalarValues library model, see 9.3.2 ). An upper bound value of * (infinity) means that the cardinality includes all numbers greater than or equal to the lower bound value. A multiplicity range is written in the form [lowerBound..upperBound], where each of lowerBound and upperBound is either a literal expression or a feature reference expression represented in the notation described in 7.4.9 . Literal expressions can be used to specify a multiplicity range with fixed lower and/or upper bounds. If the result of the lowerBound expression is * , then the meaning of the multiplicity range is not defined. A multiplicity range can also be written without the lower bound (or .. ). In this case, the result of the single expression is used as both the lower and upper bound of the range, unless the result is the infinite value * , in which case the lower bound is taken to be 0. Multiplicity ranges can be used in the declaration of types, particularly features (see 7.3.4.2 ). struct Automobile { feature n : Positive[1]; composite feature wheels : Wheel[n]; // Equivalent to [n..n] for n < * feature driveWheels[2..n] subsets wheels; Kernel Modeling Language v1.0 67 -} feature autoCollection : Automobile[*]; // Equivalent to [0..*] It is also possible to declared a multiplicity feature using the keyword multiplicity , optionally followed by a short name and/or name, and including either a multiplicity range or a subsetting of another multiplicity. A multiplicity declaration is a kind of feature declaration, and it can optionally include a body as in a generic feature declaration (see 7.3.4.2 ). multiplicity zeroOrMore [0..*]; multiplicity m subsets zeroOrMore; If a multiplicity feature is declared in the body of a type, then this becomes the multiplicity of the type. A type can have at most one multiplicity, whether this is given in the declaration or the body of the type. feature driveWheels subsets wheels { multiplicity [2..n]; } feature autoCollection { multiplicity subsets zeroOrMore; } 7.4.13 Metadata Metamodel references: • Concrete syntax, 8.2.5.12 • Abstract syntax, 8.3.4.12 • Semantics, 8.4.4.13 Metadata is additional information on elements of a model that does not have any instance-level semantics (in the sense described in 7.3.1 ). In general, metadata is specified in annotating elements (including comments and textual representations) attached to annotated elements (see 7.2.4 ). A metadata feature is a kind of annotating element that allows for the definition of structured metadata with modeler-specified features. This may be used, for example, to add tool-specific information to a model that can be relevant to the function of various kinds of tooling that may use or process a model, or domain-specific information relevant to a certain project or organization. A metadata feature is syntactically a feature (see 7.3.4 ) that is typed by a single metaclass, which is a kind of structure (see 7.4.4 ), with implicit multiplicity 1..1 . If the metaclass has no features, then the metadata feature simply acts as a user-defined syntactic tag on the annotated element. If the metaclass has features, then the metadata feature must have nested features that redefine each of the features of its type, binding them to the results of model- level evaluable expressions (see 7.4.9 ), which provide the values of the specified attributive metadata for the annotated element. A metaclass is declared like a structure (see 7.4.4 ), but using the keyword metaclass . If no owned subclassification is explicitly given for the metaclass, then it is implicitly given a default subclassification to the metaclass Metaobject from the Metaobjects library model (see 9.2.16 ). metaclass SecurityRelated; metaclass ApprovalAnnotation { feature approved[1] : Boolean; feature approver[1] : String; } A metadata feature is declared using the keyword metadata (or the symbol @ ), optionally followed by a short name and/or name, followed by the keyword typed by (or the symbol : ) and the qualified name of exactly one metaclass. If no short name or name is given, then the keyword typed by (or the symbol : ) may also be omitted. 68 Kernel Modeling Language v1.0 -One or more annotated elements are then identified for the metadata feature after the keyword about , indicating that the metadata feature has annotation relationships to each of the identified elements (see 7.2.4 ). metadata securityDesignAnnotation : SecurityRelated about SecurityDesign; Any owned feature of a metadata feature must be a redefinition of a feature of the typing metaclass, with a feature value binding it to the result of a model-level evaluable expressions (see 7.4.9 ). The owned features of a metadata feature must always have the same names as the names of the typing metaclass, so the shorthand prefix redefines notation (see 7.3.4.5 ) is always used. metadata ApprovalAnnotation about Design { feature redefines approved = true; feature redefines approver = "John Smith"; } The keywords feature and/or redefines (or the equivalent symbol :>> ) may be omitted in the declaration of a metadata feature. metadata ApprovalAnnotation about Design { approved = true; approver = "John Smith"; } If the metadata feature is an owned member of a namespace (see 7.2.5 ), then the explicit identification of annotated elements (following the about keyword) can be omitted, in which case the annotated element is implicitly the containing namespace (see 7.2.4 ). class Design { // This metadata feature is implicitly about the class Design. @ApprovalAnnotation { approved = true; approver = "John Smith"; } } If a metadata feature has one or more concrete features that directly or indirectly subset Metaobject::annotatedElement , then, for each annotated element of the metadata feature, there must be at least one such feature for which the metaclass of the annotated element conforms to all the types of the feature (which must all be specializations of the reflective metaclass KerML::Element , see 9.2.17 ). metaclass Command { // A metadata feature of this metaclass may annotate // a behavior or a step. subsets annotatedElement : KerML::Behavior; subsets annotatedElement : KerML::Step; } behavior Save specializes UserAction { @Command; // This is valid. redefine step doAction { @Command; // This is valid. } } struct Options { @Command; // This is INVALID. } If the metaclass of a metadata feature is a direct or indirect specialization of Metaobjects::SemanticMetadata (see 9.2.16.2.3 ), then the annotated elements must all be types and the feature SemanticMetadata::baseType Kernel Modeling Language v1.0 69 -must be bound to a value of type KerML::Type (see 9.2.17 ). Each type annotated by such semantic metadata has an implicit specialization added to a type determined from the baseType value as follows: • If the annotated type is neither a classifier nor a feature, then the annotated type implicitly specializes the baseType . • If the annotated type is a classifier and the baseType is a classifier, then annotated classifier implicitly subclassifies the baseType . • If the annotated type is a classifier and the baseType is a feature, then the annotated classifier implicitly subclassifies each type of the baseType . • If the annotated type is a feature and the baseType is a feature, then the annotated feature shall implicitly subset the baseType . • In all other cases, no implicit specialization is added. When evaluated in a model-level evaluable expression, the meta-cast operator meta (see 7.4.9.2 ) may be used to cast a feature referenced as its first operand to the actual reflective metaclass value for this feature, which may then be bound to the baseType feature of SemanticMetadata . behavior UserAction; step userActions : UserAction[*] nonunique; metaclass Command specializes SemanticMetadata { // The cast operation "userAction meta KerML::Feature" has // type KerML::Feature, which conforms to the type Type of // baseType. Since userActions is a step, the expression // evaluates at model level to a value of type KerML::Step. redefines baseType = userActions meta KerML::Feature; } // Save implicitly subclassifies UserAction (which is the // type of userActions). behavior Save { @Command; } // previousAction implicitly subsets userActions. step previousAction[1] { @Command; } User-Defined Keywords A user-defined keyword is a (possibly qualified) metaclass name or short name preceded by the symbol # . The user- defined keyword is placed immediately before the language-defined (reserved) keyword for the declaration and specifies a metadata feature annotation of the declared element. Note that this notation can only be used for metadata features that do not have nested features. If the named metaclass is a kind of SemanticMetadata , then the implicit specialization rules given above for semantic metadata apply. // It is often convenient to use a lower-case initial name or // short name for semantic metadata intended to be used as a keyword. metaclass CommandMetadata :> SemanticMetadata { redefines baseType = userActions meta KerML::Feature; } #command behavior Save; #command step previousAction[1]; It is also possible to include more than one user defined-keyword in a declaration. #SecurityRelated #command behavior Save; 70 Kernel Modeling Language v1.0 -7.4.14 Packages Metamodel references: • Concrete syntax, 8.2.5.13 • Abstract syntax, 8.3.4.13 • Semantics, 8.4.4.14 Packages are namespaces used to group elements, without any instance-level semantics (as opposed to types, which are namespaces with classification semantics, see 7.3.2 ). A package is notated like a generic namespace (see 7.2.5.2 ), but using the keyword package instead of namespace . package AddressBooks { datatype Entry { feature name[1]: String; feature address[1]: String; } struct AddressBook { composite feature entries[*]: Entry; } } A package may also have one or more filter conditions for selecting a subset of its imported memberships. A filter condition is a Boolean-valued, model-level evaluable expression (see 7.4.9 ) that must evaluate to true for any imported member of the package. These are notated using the keyword filter followed by the filter condition expression. package Annotations { metaclass ApprovalAnnotation { feature approved[1] : Boolean; feature approver[1] : String; feature level[1] : Natural; } ... } package DesignModel { public import Annotations::*; struct System { @ApprovalAnnotation { approved = true; approver = "John Smith"; level = 2; } } ... } package UpperLevelApprovals { // This package imports all direct or indirect members // of the DesignModel package that have been approved // at a level greater than 1. public import DesignModel::**; filter @Annotations::ApprovalAnnotation and Annotations::ApprovalAnnotation::approved and Annotations::ApprovalAnnotation::level > 1; } A filter condition can operate on metadata on elements (see 7.4.13 ), such as checking for a metadata feature of a particular type or accessing the values of the features of a metadata feature. For the purposes of filter condition Kernel Modeling Language v1.0 71 -expressions, every element is also considered to have an implicit metadata feature that is typed by a metaclass from the reflective library model of the KerML abstract syntax (see 9.2.17 ). This enables filter conditions to test for the abstract syntax metaclass of an element and to access the values of abstract syntax meta-attributes. Note that a filter condition in a package will filter all imports of that Package. That is why full qualification is used for Annotations::ApprovalAnnotation in the example above, since imported elements of the Annotations package would be filtered out by the very filter condition in which the elements are intended to be used. This may be avoided by combining one or more filter conditions with a specific import, using the filtered import notation described in 7.2.5.4 ). package UpperLevelApprovals { // Recursively import all annotation data types and all // features of those types. private import Annotations::**; // The filter condition for this import applies only to // elements imported from the DesignModel package. public import DesignModel::**[@ApprovalAnnotation and approved and level > 1]; } The KerML library package contains a complete model of the KerML abstract syntax represented in KerML itself. When a filter condition is evaluated on an element, abstract syntax metadata for the element can be tested as if the element had an implicit metadata feature typed by the type from the KerML package corresponding to the metaclass of the element. package PackageApprovals { private import Annotations::*; private import KerML::*; // This imports all structures from the DesignModel that have // at least one owned feature and have been marked as approved. public import DesignModel::**[@Structure and Structure::ownedFeature != null and @ApprovalAnnotation and ApprovalAnnotation::approved]; } In general, a library package is a package that is expected to be commonly available and reused across many user models. A package can be explicitly identified as a library package using the keyword library . This allows tooling to identify any element contained directly in a library package as being a library element from that specific library package. library package AddressBooks { ... } The standard library packages in the Kernel Model Libraries (see Clause 9 ) are further identified using the keyword standard . However, only library packages from the Kernel Model Libraries, or from other recognized standard model libraries, should be identified as standard library packages. 72 Kernel Modeling Language v1.0 -8Metamodel 8.1 Metamodel Overview This clause presents the normative specification of the metamodel for KerML, which includes the KerML concrete syntax, abstract syntax and semantics (though the complete semantics depends on the model library specified in Clause 9 ). 1. Concrete syntax specifies how the language appears to modelers. Modelers construct and review models using a textual notation that conforms to the concrete syntax specification (see 8.2 ). 2. Abstract syntax specifies linguistic terms and relations between them (as opposed to library model terms), which may be expressed in the concrete syntax (see 8.3 ). The abstract syntax omits aspects of the concrete syntax, such as delimiters and formatting, that are do not affect what modelers are trying to expression. A concrete syntax representation of a model can be parsed into an abstract syntax representation, or an abstract syntax representation can be serialized into the concrete syntax notation. The mapping between the concrete and abstract syntax is given as part of the grammar specification for the concrete syntax (see 8.2.1 on the conventions for this). 3. Semantics specifies the interpretation of models as representations of or specifications for modeled systems (see 8.4 ). The semantics for a core subset of the abstract syntax are specified using mathematical logic. Semantics for the rest of KerML are specified by mapping complicated abstract syntax constructs into equivalent models using the core subset, and, in particular, introducing implied relationships to required elements from the KerML model library (see 8.4.1 on this approach). As described in 6.1, KerML is divided into Root, Core and Kernel Layers, which cut across each of the above facets. The subclauses on Concrete Syntax ( 8.2 ) and Abstract Syntax ( 8.3 ) are each further subdivided into subclauses on the three layers, and then, within each layer, into subclauses following the package structure of the abstract syntax. Subclause 8.4 on Semantics only covers the Core and Kernel Layers, because Root Layer constructs do not have model-level semantics. Throughout this clause, the names of elements from the KerML abstract syntax model appear in a " code " font. Further: 1. Names of metaclasses appear exactly as in the abstract syntax, including capitalization, except possibly with added pluralization. When used as English common nouns, e.g., "an Element ", "multiple FeatureTypings ", they refer to instances of the metaclass. E.g., " Elements can own other Elements " refers to instances of the metaclass Element that reside in models. This can be modified with the term "metaclass" as necessary to refer to the metaclass itself instead of its instances, e.g., "The Element metaclass is contained in the Elements package." 2. Names of properties of metaclasses, when used as English common nouns, e.g., “an ownedRelatedElement ”, “multiple featuringTypes ”, refer to values of the properties. This can be modified using the term "metaproperty" as necessary to refer to the metaproperty itself instead of its values, e.g., "The ownedRelatedElement metaproperty is contained in the Elements package." Similar stylistic conventions apply to text about KerML models, except that an " italic code " front is used. 1. Convention 1 above applies to KerML Types (e.g., Performance ), using "type" (or a more specialized term) instead of "metaclass" (e.g., "the Performance behavior"). 2. Convention 2 above applies to KerML Features (e.g, performances ), using "feature" (or a more specialized term) instead of "metaproperty" (e.g., "the performances step"). Kernel Modeling Language v1.0 73 -8.2 Concrete Syntax 8.2.1 Concrete Syntax Overview The concrete syntax for KerML is a textual notation that can be used to express or construct an abstract syntax representation of a model. The lexical structure of the KerML textual notation defines how the string of characters in a text is divided into a set of lexical elements. Such lexical elements can be categorized as whitespace, notes, or tokens. Only tokens are significant for the mapping of the notation to the abstract syntax. The syntactic structure of the KerML textual notation defines how lexical tokens are grouped and mapped to an abstract syntax representation of a model. Both the lexical and syntactic structures are specified as grammars consisting of productions for lexical elements or non-terminal syntactic elements (see Table 1 ). The body of a production is specified using an Extended Backus Naur Form (EBNF) notation (see Table 2 ). The syntactic grammar includes further notations to describe how the concrete syntax maps to the abstract syntax element being synthesized (see Table 3 ). Subclause 8.2.2 presents the lexical grammar for KerML. Subclauses 8.2.3 , 8.2.4 , and 8.2.5 then each present the portion of the syntactic grammar for KerML covering the Root, Core and Kernel Layers of KerML (see 6.1). Each of these subclauses is further divided into subclauses corresponding to each of the packages from the abstract syntax model (see 8.3 ). The starting production for the syntactic grammar is RootNamespace (see 8.2.3.4.1 ). Table 1. Grammar Production Definitions LEXICAL_ELEMENT = ... Define a production for the LEXICAL_ELEMENT . Define a production for the NonterminalElement that synthesizes the AbstractSyntaxElement . If the NonterminalElement : NonterminalElement has the same name as the AbstractSyntaxElement = ... AbstractSyntaxElement , then " : AbstractSyntaxElement " may be omitted. Table 2. EBNF Notation Conventions LEXICAL_ELEMENT Lexical element 'terminal' Terminal element NonterminalElement Non-terminal element Element1 Element2 Sequential elements Element1 | Element2 Alternative elements Element ? Optional elements (zero or one) Element * Repeated elements (zero or more) Element + Repeated elements (one or more) ( Elements ... ) Grouping Table 3. Abstract Syntax Synthesis Notation Assign the result of parsing the concrete syntax Element to abstract p = Element Property assignment syntax property p . 74 Kernel Modeling Language v1.0 -Add the result of parsing the concrete syntax Element to the p += Element List property construction abstract syntax list property p . If the concrete syntax Element is p ?= Element Boolean property assignment parsed, then set the abstract Boolean property p to true. Assign (or add) the given value to the abstract syntax property p , without parsing any input. The { p = value } Non-parsing assignment value may be a literal or a reference { p += value } to another abstract syntax property. The symbol " this " refers to the element being synthesized. Parse a QualifiedName , then resolve that name to an Element [QualifiedName] Name resolution reference (see 8.2.3.5 ) for use as a value in an assignment as above. 8.2.2 Lexical Structure 8.2.2.1 Line Terminators and White Space LINE_TERMINATOR = implementation defined character sequence LINE_TEXT = character sequence excluding LINE_TERMINATORs WHITE_SPACE = space | tab | form_feed | LINE_TERMINATOR Notes 1. Notation text is divided up into lines separated by line terminators. A line terminator may be a single character (such as a line feed) or a sequence of characters (such as a carriage return/line feed combination). This specification does not require any specific encoding for a line terminator, but any encoding used must be consistent throughout any specific input text. 2. Any characters in text line that are not a part of the line terminator are referred to as line text. 3. A white space character is a space, tab, form feed or line terminator. Any contiguous sequence of white space characters can be used to separate tokens that would otherwise be considered to be part of a single token. It is otherwise ignored, with the single exception that a line terminator is used to mark the end of a single-line note (see 8.2.2.2 ). Kernel Modeling Language v1.0 75 -8.2.2.2 Notes and Comments SINGLE_LINE_NOTE = '//' LINE_TEXT MULTILINE_NOTE = '//*' COMMENT_TEXT '*/' REGULAR_COMMENT = '/*' COMMENT_TEXT '*/' COMMENT_TEXT = ( COMMENT_LINE_TEXT | LINE_TERMINATOR )* COMMENT_LINE_TEXT = LINE_TEXT excluding the sequence '*/' 8.2.2.3 Names NAME = BASIC_NAME | UNRESTRICTED_NAME BASIC_NAME = BASIC_INITIAL_CHARACTER BASIC_NAME_CHARACTER* UNRESTRICTED_NAME = single_quote ( NAME_CHARACTER | ESCAPE_SEQUENCE )* single_quote (see Note 1) BASIC_INITIAL_CHARACTER = ALPHABETIC_CHARACTER | '_' BASIC_NAME_CHARACTER = BASIC_INITIAL_CHARACTER | DECIMAL_DIGIT ALPHABETIC_CHARACTER = any character 'a' through 'z' or 'A' through 'Z' DECIMAL_DIGIT = any character '0' through '9' NAME_CHARACTER = any printable character other than backslash or single_quote ESCAPE_SEQUENCE = see Note 2 Notes 1. The single_quote character is ' . The name represented by an UNRESTRICTED_NAME shall consist of the characters within the single quotes, with escape characters resolved as described below. The surrounding single quote characters are not part of the represented name. 2. An ESCAPE_SEQUENCE is a sequence of two text characters starting with a backslash that actually denotes only a single character, except for the newline escape sequence, which represents however many characters is necessary to represent an end of line in a specific implementation (see also 8.2.2.1 ). Table 4 shows the meaning of the allowed escape sequences. The ESCAPE_SEQUENCES in an UNRESTRICTED_NAME shall be replaced by the characters specified as their meanings in the actual represented name. 76 Kernel Modeling Language v1.0 -Table 4. Escape Sequences Escape Sequence Meaning \' Single Quote \" Double Quote \b Backspace \f Form Feed \t Tab \n Line Terminator \\ Backslash 8.2.2.4 Numeric Values DECIMAL_VALUE = DECIMAL_DIGIT+ EXPONENTIAL_VALUE = DECIMAL_VALUE ('e' | 'E') ('+' | '-')? DECIMAL_VALUE Notes 1. A DECIMAL_VALUE may specify a natural literal, or it may be part of the specification of a real literal (see 8.2.5.8.4 ). Note that a DECIMAL_VALUE does not include a sign, because negating a literal is an operator in the KerML Expression syntax. 2. An EXPONENTIAL_VALUE may be used in the specification of a real literal (see 8.2.5.8.4 ). Note that a decimal point and fractional part are not included in the lexical structure of an exponential value. They are handled as part of the syntax of real literals. 8.2.2.5 String Value STRING_VALUE = '"' ( STRING_CHARACTER | ESCAPE_SEQUENCE )* '"' STRING_CHARACTER = any printable character other than backslash or '"' Notes 1. ESCAPE_SEQUENCE is specified in 8.2.2.3 . 8.2.2.6 Reserved Words A reserved keyword is a token that has the lexical structure of a basic name but cannot actually be used as a basic name. The following keywords are so reserved in KerML. about abstract alias all and as assoc behavior binding bool by chains class classifier comment composite conjugate conjugates conjugation connector const crosses datatype default dependency derived differences disjoining disjoint doc else end expr false feature featured featuring filter first flow for from function hastype if implies import in inout interaction intersects inv inverse Kernel Modeling Language v1.0 77 -inverting istype language library locale member meta metaclass metadata multiplicity namespace nonunique not null of or ordered out package portion predicate private protected public redefines redefinition references rep return specialization specializes standard step struct subclassifier subset subsets subtype succession then to true type typed typing unions var xor Tooling for the KerML textual notation should generally highlight keywords relative to other text, for example by using boldface and/or distinctive coloring. However, while keywords are shown in boldface in this specification, the specification does not require any specific highlighting (or any highlighting at all), and KerML textual notation documents are expected to be interchanged as plain text (see also Clause 10 on Model Interchange). 8.2.2.7 Symbols The symbols shown below are non-name tokens composed entirely of characters that are not alphanumeric. In some cases these symbols have no meaning themselves, but are used to allow unambiguous separation between other tokens that do have meaning. In other cases, they are distinguished notations in the KerML Expression sublanguage (see 8.2.5.8 ) that map to particular library Functions or symbolic shorthand for meaningful relationships. ( ) { } [ ] ; , ~ @ # % & ^ | * ** + - / -> $ . .. : :: :> :>> ::> => < <= = := == === != !== > >= ? ?? .? Some symbols are made of of multiple characters that may themselves individually be valid symbol tokens. Nevertheless, a multi-symbol token is not considered a combination of the individual symbol tokens. For example, “ :: ” is considered a single token, not a combination of two “ : ” tokens. Input characters shall be grouped from left to right to form the longest possible sequence of characters to be grouped into a single token. So “ a:::b ” would be analyzed into four tokens: “ a ”, “ :: ”, “ : ” and “ b ” (which, as it turns out, is not a valid sequence of tokens in the KerML textual concrete syntax). Certain keywords in the concrete syntax have an equivalent symbolic representation. For convenience, the concrete syntax grammar uses the following special lexical terminals, which match either the symbol or the corresponding keyword. TYPED_BY = ':' | 'typed' 'by' SPECIALIZES = ':>' | 'specializes' SUBSETS = ':>' | 'subsets' REFERENCES = '::>' | 'references' CROSSES = '=>' | 'crosses' REDEFINES = ':>>' | 'redefines' CONJUGATES = '~' | 'conjugates' 8.2.3 Root Concrete Syntax 8.2.3.1 Elements and Relationships Concrete Syntax Identification : Element = ( '<' declaredShortName = NAME '>' )? ( declaredName = NAME )? RelationshipBody : Relationship = ';' | '{' RelationshipOwnedElement* '}' RelationshipOwnedElement : Relationship = ownedRelatedElement += OwnedRelatedElement | ownedRelationship += OwnedAnnotation OwnedRelatedElement : Element = NonFeatureElement | FeatureElement 8.2.3.2 Dependencies Concrete Syntax 78 Kernel Modeling Language v1.0 -Dependency = ( ownedRelationship += PrefixMetadataAnnotation )* 'dependency' ( Identification? 'from' )? client += [QualifiedName] ( ',' client += [QualifiedName] )* 'to' supplier += [QualifiedName] ( ',' supplier += [QualifiedName] )* RelationshipBody Notes 1. PrefixMetadataAnnotation is defined in the Kernel layer (see 8.2.5.12 ). 8.2.3.3 Annotations Concrete Syntax 8.2.3.3.1 Annotations Annotation = annotatedElement = [QualifiedName] OwnedAnnotation : Annotation = ownedRelatedElement += AnnotatingElement AnnotatingElement = Comment | Documentation | TextualRepresentation | MetadataFeature Notes 1. MetadataFeature is defined in the Kernel layer (see 8.2.5.12 ). 8.2.3.3.2 Comments and Documentation Comment = ( 'comment' Identification ( 'about' ownedRelationsip += Annotation ( ',' ownedRelationship += Annotation )* )? )? ( 'locale' locale = STRING_VALUE )? body = REGULAR_COMMENT Documentation = 'doc' Identification ( 'locale' locale = STRING_VALUE )? body = REGULAR_COMMENT Notes 1. The text of a lexical REGULAR_COMMENT or PREFIX_COMMENT shall be processed as follows before it is included as the body of a Comment or Documentation : 1. Remove the initial /* and final */ characters. 2. Remove any white space immediately after the initial /* , up to and including the first line terminator (if any). 3. On each subsequent line of the text: 1. Strip initial white space other than line terminators. Kernel Modeling Language v1.0 79 -2. Then, if the first remaining character is " * ", remove it. 3. Then, if the first remaining character is now a space, remove it. 2. The body text of a Comment can include markup information (such as HTML), and a conforming tool may display such text as rendered according to the markup. However, marked up "rich text" for a Comment written using the KerML textual concrete syntax shall be stored in the Comment body in plain text including all mark up text, with all line terminators and white space included as entered, other than what is removed according to the rules above. 8.2.3.3.3 Textual Representation TextualRepresentation = ( 'rep' Identification )? 'language' language = STRING_VALUE body = REGULAR_COMMENT Notes 1. The lexical text of a REGULAR_COMMENT shall be processed as specified in 8.2.3.3.2 for Comments before being included as the body of a TextualRepresentation . 2. See also 8.3.2.3.6 on the standard language names recognized for a TextualRepresentation . 8.2.3.4 Namespaces Concrete Syntax 8.2.3.4.1 Namespaces RootNamespace : Namespace = NamespaceBodyElement* (See Note 1) Namespace = ( ownedRelationship += PrefixMetadataMember )* NamespaceDeclaration NamespaceBody (See Note 2) NamespaceDeclaration : Namespace = 'namespace' Identification NamespaceBody : Namespace = ';' | '{' NamespaceBodyElement* '}' NamespaceBodyElement : Namespace = ownedRelationship += NamespaceMember | ownedRelationship += AliasMember | ownedRelationship += Import MemberPrefix : Membership = ( visibility = VisibilityIndicator )? VisibilityIndicator : VisibilityKind = 'public' | 'private' | 'protected' NamespaceMember : OwningMembership = NonFeatureMember | NamespaceFeatureMember NonFeatureMember : OwningMembership = MemberPrefix ownedRelatedElement += MemberElement 80 Kernel Modeling Language v1.0 -NamespaceFeatureMember : OwningMembership = MemberPrefix ownedRelatedElement += FeatureElement AliasMember : Membership = MemberPrefix 'alias' ( '<' memberShortName = NAME '>' )? ( memberName = NAME )? 'for' memberElement = [QualifiedName] RelationshipBody QualifiedName = ( '$' '::' )? ( NAME '::' )* NAME (See Note 3) Notes 1. A root Namespace is a Namespace that has no owningNamespace (see 8.3.2.4 ). Every Element other than a root Namespace must be contained, directly or indirectly, within some root Namespace . Therefore, every valid KerML concrete syntax text can be parsed starting from the RootNamespace production. 2. PrefixMetadataMember is defined in the Kernel layer (see 8.2.5.12 ). 3. A qualified name is notated as a sequence of segment names separated by " :: " punctuation, optionally with the global scope qualifier " $ " as an initial segment. An unqualified name can be considered the degenerate case of a qualified name with a single segment name. A qualified name is used in the KerML textual concrete syntax to identify an Element that is being referred to in the representation of another Element . A qualified name used in this way does not appear in the corresponding abstract syntax—instead, the abstract syntax representation contains an actual reference to the identified Element . Name resolution is the process of determining the Element that is identified by a qualified name. The segment names of the qualified name other than the last identify a sequence of nested Namespaces that provide the context for resolving the final segment name (see 8.2.3.5 ). The notation [QualifiedName] is used in concrete syntax grammar productions to indicate the result of resolving text parsed as a QualifiedName (see also 8.2.1 ). 8.2.3.4.2 Imports Import = visibility = VisibilityIndicator 'import' ( isImportAll ?= 'all' )? ImportDeclaration RelationshipBody ImportDeclaration : Import MembershipImport | NamespaceImport MembershipImport = importedMembership = [QualifiedName] ( '::' isRecursive ?= '**' )? (see Note 1) NamespaceImport = importedNamespace = [QualifiedName] '::' '*' ( '::' isRecursive ?= '**' )? | importedNamespace = FilterPackage { ownedRelatedElement += importedNamespace } FilterPackage : Package = ownedRelationship += ImportDeclaration ( ownedRelationship += FilterPackageMember )+ FilterPackageMember : ElementFilterMembership = '[' ownedRelatedElement += OwnedExpression ']' Kernel Modeling Language v1.0 81 -Notes 1. The importedMembership of a MembershipImport is the single case in which the Element required from the resolution [QualifiedName] is the actual Membership identified by the QualifedName , not the memberElement of that Membership (see 8.2.3.5 ). 8.2.3.4.3 Namespace Elements MemberElement : Element = AnnotatingElement | NonFeatureElement NonFeatureElement : Element = Dependency | Namespace | Type | Classifier | DataType | Class | Structure | Metaclass | Association | AssociationStructure | Interaction | Behavior | Function | Predicate | Multiplicity | Package | LibraryPackage | Specialization | Conjugation | Subclassification | Disjoining | FeatureInverting | FeatureTyping | Subsetting | Redefinition | TypeFeaturing FeatureElement : Feature = Feature | Step | Expression | BooleanExpression | Invariant | Connector | BindingConnector | Succession | Flow | SuccessionFlow 8.2.3.5 Name Resolution 8.2.3.5.1 Name Resolution Overview A qualified name consists of a sequence of one or more segment names (see 8.2.3.4.1 ). Each segment names is a simple name, that is, it is a lexical NAME token (see 8.2.2.3 ). The qualification part of a qualified name with more than one segment name is itself a qualified name, consisting of all the segment names of the original qualified name except for the last. For example the qualified name A::B::C consists of the segment names A , B and C , and its qualification part is A::B . A qualified name may also have the global scope qualifier " $ " as an initial segment, for example, $::A::B::C . 82 Kernel Modeling Language v1.0 -Name resolution is a process for determining the Element that is identified by a qualified name. The result of the process is actually a Membership relationship identified by the qualified name. However, in all cases but one, the required Element to be inserted into the abstract syntax is the memberElement of that Membership , in which case the metaclass of the memberElement must conform to the expected metaclass in the context of the name resolution. The one exception is the resolution of the qualified name for the importedMembership of a MembershipImport (see 8.2.3.4.2 ), in which case the required Element is the identified Membership itself. The basic name resolution process consists of the following two steps. The terms "local Namespace ", "visible resolution" and "full resolution" used below are defined in 8.2.3.5.2 , 8.2.3.5.3 , and 8.2.3.5.4 . 1. If the qualified name has only one segment name, with no global scope qualifier, then the resolution of the qualified name is the full resolution of that segment name relative to the local Namespace for the qualified name – unless the local Namespace is a root Namespace , in which case the global Namespace is used instead. 2. If the qualified name consists of a global scope qualifier and a single segment name, the resolution of the qualified name is the resolution of the segment name relative to the global Namespace . 3. Otherwise, resolve the qualification part of the qualified name relative to the local Namespace of the original qualified name. This must resolve to a Namespace , and the resolution of the original qualified name is then the visible resolution of its last segment name relative to this Namespace . If the above steps fail, or if the resulting Element does not have the proper type for its context, then the qualified name has no resolution, and the parsing of the text containing it fails with a name resolution error. Note. Invoking the Namespace::resolve , as defined in the abstract syntax (see 8.3.2.4.5 ), carries out the above basic resolution process with the target Namespace considered as the local Namespace for the given qualified name. The basic name resolution process is used directly to resolve a qualified name in all cases except when the qualified name specifies the redefinedFeature of a Redefinition with an owningFeature that has an owningType . In this case, the basic name resolution processes is repeated with the general Type of each ownedSpecialization of the owningType considered in turn as the local Namespace , until a resolution is found. If no resolution is found for any of these, then the overall resolution fails. Note. When implementing the name resolution process as specified here, some additional points need to be considered. • The descriptions given in 8.2.3.5.2 , 8.2.3.5.3 , and 8.2.3.5.4 presume that the derived membership , importedMembership and (for a Type ) inheritedMembership properties of a Namespace have been fully computed, including memberships resulting from implied Relationships (see 8.4.2 ). However, when parsing a complete KerML concrete syntax text, the values of these properties may themselves be based on other Relationships (e.g., alias Memberships , Imports and Specializations ) whose target references are given by qualified names that must be resolved. Name resolution must therefore proceed incrementally during a parse, avoiding infinite loops caused by attempting to resolve again names that are already pending resolution. Note, however, that it is possible to at least locally resolve a name to a Membership in a Namespace without immediately resolving the memberElement of that Membership . • Circularity is allowed for Imports and Specializations . Therefore, when traversing the graph of these Relationships , an implementation must avoid re-processing a Namespace that has already been visited. 8.2.3.5.2 Local and Global Namespaces Every Namespace other than a root Namespace (see 8.2.3.4.1 ) is nested in a containing Namespace called its owningNamespace (see 8.3.2.4 ). Kernel Modeling Language v1.0 83 -A root Namespace has an implicit containing Namespace known as its global Namespace . The global Namespace for a root Namespace includes all the visible Memberships of all other root Namespaces that are available to the first Namespace , which shall include at least all the root Namespaces from the KerML Model Libraries (see Clause 9 ). If a tool imports a model interchange project (see 10.3 ), then the available Namespaces shall also include all the root Namespaces from any used project of the imported project. A conforming tool can also provide means for making additional Namespaces available to a root Namespace , such as by creating a new root Namespace or adding an additional used project. A qualified name is always used to identify an Element that is a target Element of some context Relationship . The local Namespace for resolving the qualified name is then determined depending on the kind of context Relationship , as given in the following. Import (see 8.3.2.4.2 ) • The local Namespace is the importOwningNamespace . Membership (see 8.3.2.4.3 ) • If the membershipOwningNamespace is a FeatureReferenceExpression (see 8.3.4.8.5 ), then the local Namespace is the non-invocation Namespace for the membershipOwningNamespace , which is defined to be the nearest containing Namespace that is none of the following: ◦ FeatureReferenceExpression ◦ InstantiationExpression ◦ ownedFeature of an InstantiationExpression ◦ ownedFeature of the result of a ConstructorExpression • If the Membership is not a FeatureMembership and the membershipOwningNamespace is an InstantiationExpression (see 8.3.4.8.7 ), then the local Namespace is the non-invocation Namespace for the membershipOwningNamespace , determined as for a FeatureReferenceExpression above. • If the membershipOwningNamespace is a FeatureChainExpression see 8.3.4.8.4 , then the local Namespace is the result parameter of the argument Expression of the FeatureChainExpression . • Otherwise, the local Namespace is the membershipOwningNamespace . Specialization (see 8.3.3.1.8 ) • If the Specialization is a ReferenceSubsetting (see 8.3.3.3.9 ), and its referencingFeature is an end Feature whose owningType is a Connector , then the local Namespace is the owningNamespace of the Connector . • Otherwise, if the owningType is not null, then the local Namespace is the owningNamespace of the owningType . • Otherwise, the local Namespace is the owningNamespace of the Specialization . Conjugation (see 8.3.3.1.2 ) • If the owningType is not null, the local Namespace is the owningNamespace of the owningType . • Otherwise, the local Namespace is the owningNamespace of the Conjugation . FeatureChaining (see 8.3.3.3.5 ) • If the FeatureChaining is the first ownedFeatureChaining of its featureChained , then the local Namespace is determined as if the owningRelationship of the featureChained (which will be a Membership , Subsetting or Conjugation ) was the context Relationship (see above). • Otherwise, the local Namespace is the chainingFeature of the previous FeatureChaining in the ownedFeatureChaining list. 84 Kernel Modeling Language v1.0 -8.2.3.5.3 Local and Visible Resolution A Namespace defines a mapping from names to its memberships , know as the local resolution of those names. Each membership of a Namespace is the local resolution for its memberShortName and memberName (if non- null). Note that this includes owned, imported and (if the Namespace is a Type ) inherited Memberships . Note. If the Namespace is well formed, then there can be at most one Membership that is the local resolution of any given name. The visible resolution of a name is similar to its local resolution, but the memberships considered are restricted to those that are visible outside the Namespace . The visible Memberships of a Namespace shall comprise the following: • All ownedMemberships of the Namespace with visibility = public . • All importedMemberships of the Namespace that are derived from Import Relationships with visibility = public . • If the Namespace is a Type , then all inheritedMemberships of the Type with visibility = public . 8.2.3.5.4 Full Resolution The full resolution of a simple name relative to a Namespace considers Memberships not only in that Namespace , but also in directly or indirectly containing Namespaces , all the way out to the global Namespace . Full resolution relative to a Namespace other than the global Namespace proceeds as follows: 1. If the name has a local resolution relative to a Namespace (see 8.2.3.5.3 ), then that is also its full resolution relative to that Namespace . 2. Otherwise: ◦ If the Namespace is not a root Namespace , then the full resolution of the name relative to the original Namespace is determined as its full resolution relative to the owningNamespace of the original Namespace . ◦ If the Namespace is a root Namespace , then the full resolution of the name resolution relative to the original Namespace is its resolution in the global Namespace . The resolution of a simple name in the global Namespace is the the Membership in the global Namespace (as defined in 8.2.3.5.2 ) whose (non-null) shortMemberName or memberName is equal to the simple name. Note. It is possible that there will be more than one Membership in the global Namespace that resolves a given simple name. In this case, one of these Memberships is chosen for the resolution of the name, but which one is chosen is not otherwise determined by this specification. Kernel Modeling Language v1.0 85 -8.2.4 Core Concrete Syntax 8.2.4.1 Types Concrete Syntax 8.2.4.1.1 Types Type = TypePrefix 'type' TypeDeclaration TypeBody TypePrefix : Type = ( isAbstract ?= 'abstract' )? ( ownedRelationship += PrefixMetadataMember )* TypeDeclaration : Type = ( isSufficient ?= 'all' )? Identification ( ownedRelationship += OwnedMultiplicity )? ( SpecializationPart | ConjugationPart )+ TypeRelationshipPart* SpecializationPart : Type = SPECIALIZES ownedRelationship += OwnedSpecialization ( ',' ownedRelationship += OwnedSpecialization )* ConjugationPart : Type = CONJUGATES ownedRelationship += OwnedConjugation TypeRelationshipPart : Type = DisjoiningPart | UnioningPart | IntersectingPart | DifferencingPart DisjoiningPart : Type = 'disjoint' 'from' ownedRelationship += OwnedDisjoining ( ',' ownedRelationship += OwnedDisjoining )* UnioningPart : Type = 'unions' ownedRelationship += Unioning ( ',' ownedRelationship += Unioning )* IntersectingPart : Type = 'intersects' ownedRelationship += Intersecting ( ',' ownedRelationship += Intersecting )* DifferencingPart : Type = 'differences' ownedRelationship += Differencing ( ',' ownedRelationship += Differencing )* TypeBody : Type = ';' | '{' TypeBodyElement* '}' TypeBodyElement : Type = ownedRelationship += NonFeatureMember | ownedRelationship += FeatureMember | ownedRelationship += AliasMember | ownedRelationship += Import 8.2.4.1.2 Specialization Specialization = ( 'specialization' Identification )? 'subtype' SpecificType 86 Kernel Modeling Language v1.0 -SPECIALIZES GeneralType RelationshipBody OwnedSpecialization : Specialization = GeneralType SpecificType : Specialization : specific = [QualifiedName] | specific += OwnedFeatureChain { ownedRelatedElement += specific } GeneralType : Specialization = general = [QualifiedName] | general += OwnedFeatureChain { ownedRelatedElement += general } 8.2.4.1.3 Conjugation Conjugation = ( 'conjugation' Identification )? 'conjugate' ( conjugatedType = [QualifiedName] | conjugatedType = FeatureChain { ownedRelatedElement += conjugatedType } ) CONJUGATES ( originalType = [QualifiedName] | originalType = FeatureChain { ownedRelatedElement += originalType } ) RelationshipBody OwnedConjugation : Conjugation = originalType = [QualifiedName] | originalType = FeatureChain { ownedRelatedElement += originalType } 8.2.4.1.4 Disjoining Disjoining = ( 'disjoining' Identification )? 'disjoint' ( typeDisjoined = [QualifiedName] | typeDisjoined = FeatureChain { ownedRelatedElement += typeDisjoined } ) 'from' ( disjoiningType = [QualifiedName] | disjoiningType = FeatureChain { ownedRelatedElement += disjoiningType } ) RelationshipBody OwnedDisjoining : Disjoining = disjoiningType = [QualifiedName] | disjoiningType = FeatureChain { ownedRelatedElement += disjoiningType } 8.2.4.1.5 Unioning, Intersecting and Differencing Unioning = unioningType = [QualifiedName] Kernel Modeling Language v1.0 87 -| ownedRelatedElement += OwnedFeatureChain Intersecting = intersectingType = [QualifiedName] | ownedRelatedElement += OwnedFeatureChain Differencing = differencingType = [QualifiedName] | ownedRelatedElement += OwnedFeatureChain 8.2.4.1.6 Feature Membership FeatureMember : OwningMembership = TypeFeatureMember | OwnedFeatureMember TypeFeatureMember : OwningMembership = MemberPrefix 'member' ownedRelatedElement += FeatureElement OwnedFeatureMember : FeatureMembership = MemberPrefix ownedRelatedElement += FeatureElement 8.2.4.2 Classifiers Concrete Syntax 8.2.4.2.1 Classifiers Classifier = TypePrefix 'classifier' ClassifierDeclaration TypeBody ClassifierDeclaration : Classifier = ( isSufficient ?= 'all' )? Identification ( ownedRelationship += OwnedMultiplicity )? ( SuperclassingPart | ConjugationPart )? TypeRelationshipPart* SuperclassingPart : Classifier = SPECIALIZES ownedRelationship += OwnedSubclassification ( ',' ownedRelationship += OwnedSubclassification )* 8.2.4.2.2 Subclassification Subclassification = ( 'specialization' Identification )? 'subclassifier' subclassifier = [QualifiedName] SPECIALIZES superclassifier = [QualifiedName] RelationshipBody OwnedSubclassification : Subclassification = superclassifier = [QualifiedName] 8.2.4.3 Features Concrete Syntax 8.2.4.3.1 Features Feature = ( FeaturePrefix ( 'feature' | ownedRelationship += PrefixMetadataMember ) FeatureDeclaration? ) | ( EndFeaturePrefix | BasicFeaturePrefix ) FeatureDeclaration 88 Kernel Modeling Language v1.0 -) ValuePart? TypeBody (See Note 1) EndFeaturePrefix : Feature = ( isConstant ?= 'const' { isVariable = true } )? isEnd ?= 'end' BasicFeaturePrefix : Feature : ( direction = FeatureDirection )? ( isDerived ?= 'derived' )? ( isAbstract ?= 'abstract' )? ( isComposite ?= 'composite' | isPortion ?= 'portion' )? ( isVariable ?= 'var' | isConstant ?= 'const' { isVariable = true } )? FeaturePrefix : ( EndFeaturePrefix ( ownedRelationship += OwnedCrossFeatureMember )? | BasicFeaturePrefix ) ( ownedRelationship += PrefixMetadataMember )* (see Note 1) OwnedCrossFeatureMember : OwningMembership = ownedRelatedElement += OwnedCrossFeature OwnedCrossFeature : Feature = BasicFeaturePrefix FeatureDeclaration FeatureDirection : FeatureDirectionKind = 'in' | 'out' | 'inout' FeatureDeclaration : Feature = ( isSufficient ?= 'all' )? ( FeatureIdentification ( FeatureSpecializationPart | ConjugationPart )? | FeatureSpecializationPart | ConjugationPart ) FeatureRelationshipPart* FeatureIdentification : Feature = '<' declaredShortName = NAME '>' ( declaredName = NAME )? | declaredName = NAME FeatureRelationshipPart : Feature = TypeRelationshipPart | ChainingPart | InvertingPart | TypeFeaturingPart ChainingPart : Feature = 'chains' ( ownedRelationship += OwnedFeatureChaining | FeatureChain ) InvertingPart : Feature = 'inverse' 'of' ownedRelationship += OwnedFeatureInverting TypeFeaturingPart : Feature = 'featured' 'by' ownedRelatioship += OwnedTypeFeaturing ( ',' ownedTypeFeaturing += OwnedTypeFeaturing )* FeatureSpecializationPart : Feature = Kernel Modeling Language v1.0 89 -FeatureSpecialization+ MultiplicityPart? FeatureSpecialization* | MultiplicityPart FeatureSpecialization* MultiplicityPart : Feature = ownedRelationship += OwnedMultiplicity | ( ownedRelationship += OwnedMultiplicity )? ( isOrdered ?= 'ordered' ( {isUnique = false} 'nonunique' )? | {isUnique = false} 'nonunique' ( isOrdered ?= 'ordered' )? ) FeatureSpecialization : Feature = Typings | Subsettings | References | Crosses | Redefinitions Typings : Feature = TypedBy ( ',' ownedRelationship += OwnedFeatureTyping )* TypedBy : Feature = TYPED_BY ownedRelationship += OwnedFeatureTyping Subsettings : Feature = Subsets ( ',' ownedRelationship += OwnedSubsetting )* Subsets : Feature = SUBSETS ownedRelationship += OwnedSubsetting References : Feature = REFERENCES ownedRelationship += OwnedReferenceSubsetting Crosses : Feature = CROSSES ownedRelationship += OwnedCrossSubsetting Redefinitions : Feature = Redefines ( ',' ownedRelationship += OwnedRedefinition )* Redefines : Feature = REDEFINES ownedRelationship += OwnedRedefinition Notes 1. PrefixMetadataMember is defined in the Kernel layer (see 8.3.4.12 ). 8.2.4.3.2 Feature Typing FeatureTyping = ( 'specialization' Identification )? 'typing' typedFeature = [QualifiedName] TYPED_BY GeneralType RelationshipBody OwnedFeatureTyping : FeatureTyping = GeneralType 8.2.4.3.3 Subsetting Subsetting = ( 'specialization' Identification )? 'subset' SpecificType SUBSETS GeneralType RelationshipBody OwnedSubsetting : Subsetting = GeneralType 90 Kernel Modeling Language v1.0 -OwnedReferenceSubsetting : ReferenceSubsetting = GeneralType OwnedCrossSubsetting : CrossSubsetting = GeneralType 8.2.4.3.4 Redefinition Redefinition = ( 'specialization' Identification )? 'redefinition' SpecificType REDEFINES GeneralType RelationshipBody OwnedRedefinition : Redefinition = GeneralType 8.2.4.3.5 Feature Chaining OwnedFeatureChain : Feature = FeatureChain FeatureChain : Feature = ownedRelationship += OwnedFeatureChaining ( '.' ownedRelationship += OwnedFeatureChaining )+ OwnedFeatureChaining : FeatureChaining = chainingFeature = [QualifiedName] 8.2.4.3.6 Feature Inverting FeatureInverting = ( 'inverting' Identification? )? 'inverse' ( featureInverted = [QualifiedName] | featureInverted = OwnedFeatureChain { ownedRelatedElement += featureInverted } ) 'of' ( invertingFeature = [QualifiedName] | ownedRelatedElement += OwnedFeatureChain { ownedRelatedElement += invertingFeature } ) RelationshipBody OwnedFeatureInverting : FeatureInverting = invertingFeature = [QualifiedName] | invertingFeature = OwnedFeatureChain { ownedRelatedElement += invertingFeature } 8.2.4.3.7 Type Featuring TypeFeaturing = 'featuring' ( Identification 'of' )? featureOfType = [QualifiedName] 'by' featuringType = [QualifiedName] RelationshipBody OwnedTypeFeaturing : TypeFeaturing = featuringType = [QualifiedName] Kernel Modeling Language v1.0 91 -8.2.5 Kernel Concrete Syntax 8.2.5.1 Data Types Concrete Syntax DataType = TypePrefix 'datatype' ClassifierDeclaration TypeBody 8.2.5.2 Classes Concrete Syntax Class = TypePrefix 'class' ClassifierDeclaration TypeBody 8.2.5.3 Structures Concrete Syntax Structure = TypePrefix 'struct' ClassifierDeclaration TypeBody 8.2.5.4 Associations Concrete Syntax Association = TypePrefix 'assoc' ClassifierDeclaration TypeBody AssociationStructure = TypePrefix 'assoc' 'struct' ClassifierDeclaration TypeBody 8.2.5.5 Connectors Concrete Syntax 8.2.5.5.1 Connectors Connector = FeaturePrefix 'connector' ( FeatureDeclaration? ValuePart? | ConnectorDeclaration ) TypeBody ConnectorDeclaration : Connector = BinaryConnectorDeclaration | NaryConnectorDeclaration BinaryConnectorDeclaration : Connector = ( FeatureDeclaration? 'from' | isSufficient ?= 'all' 'from'? )? ownedRelationship += ConnectorEndMember 'to' ownedRelationship += ConnectorEndMember NaryConnectorDeclaration : Connector = FeatureDeclaration? '(' ownedRelationship += ConnectorEndMember ',' ownedRelationship += ConnectorEndMember ( ',' ownedRelationship += ConnectorEndMember )* ')' ConnectorEndMember : EndFeatureMembership = ownedRelatedElement += ConnectorEnd ConnectorEnd : Feature = ( ownedRelationship += OwnedCrossMultiplicityMember )? ( declaredName = NAME REFERENCES )? 92 Kernel Modeling Language v1.0 -ownedRelationship += OwnedReferenceSubsetting OwnedCrossMultiplicityMember : OwningMembership = ownedRelatedElement += OwnedCrossMultiplicity OwnedCrossMultiplicity : Feature = ownedRelationship += OwnedMultiplicity 8.2.5.5.2 Binding Connectors BindingConnector = FeaturePrefix 'binding' BindingConnectorDeclaration TypeBody BindingConnectorDeclaration : BindingConnector = FeatureDeclaration ( 'of' ownedRelationship += ConnectorEndMember '=' ownedRelationship += ConnectorEndMember )? | ( isSufficient ?= 'all' )? ( 'of'? ownedRelationship += ConnectorEndMember '=' ownedRelationship += ConnectorEndMember )? 8.2.5.5.3 Successions Succession = FeaturePrefix 'succession' SuccessionDeclaration TypeBody SuccessionDeclaration : Succession = FeatureDeclaration ( 'first' ownedRelationship += ConnectorEndMember 'then' ownedRelationship += ConnectorEndMember )? | ( s.isSufficient ?= 'all' )? ( 'first'? ownedRelationship += ConnectorEndMember 'then' ownedRelationship += ConnectorEndMember )? 8.2.5.6 Behaviors Concrete Syntax 8.2.5.6.1 Behaviors Behavior = TypePrefix 'behavior' ClassifierDeclaration TypeBody 8.2.5.6.2 Steps Step = FeaturePrefix 'step' FeatureDeclaration ValuePart? TypeBody 8.2.5.7 Functions Concrete Syntax 8.2.5.7.1 Functions Function = TypePrefix 'function' ClassifierDeclaration FunctionBody FunctionBody : Type = ';' | '{' FunctionBodyPart '}' Kernel Modeling Language v1.0 93 -FunctionBodyPart : Type = ( TypeBodyElement | ownedRelationship += ReturnFeatureMember )* ( ownedRelationship += ResultExpressionMember )? ReturnFeatureMember : ReturnParameterMembership = MemberPrefix 'return' ownedRelatedElement += FeatureElement ResultExpressionMember : ResultExpressionMembership = MemberPrefix ownedRelatedElement += OwnedExpression 8.2.5.7.2 Expressions Expression = FeaturePrefix 'expr' FeatureDeclaration ValuePart? FunctionBody 8.2.5.7.3 Predicates Predicate = TypePrefix 'predicate' ClassifierDeclaration FunctionBody 8.2.5.7.4 Boolean Expressions and Invariants BooleanExpression = FeaturePrefix 'bool' FeatureDeclaration ValuePart? FunctionBody Invariant = FeaturePrefix 'inv' ( 'true' | isNegated ?= 'false' )? FeatureDeclaration ValuePart? FunctionBody 8.2.5.8 Expressions Concrete Syntax 8.2.5.8.1 Operator Expressions OwnedExpressionReferenceMember : FeatureMembership = ownedRelationship += OwnedExpressionReference OwnedExpressionReference : FeatureReferenceExpression = ownedRelationship += OwnedExpressionMember OwnedExpressionMember : FeatureMembership = ownedFeatureMember = OwnedExpression OwnedExpression : Expression = ConditionalExpression | ConditionalBinaryOperatorExpression | BinaryOperatorExpression | UnaryOperatorExpression | ClassificationExpression | MetaclassificationExpression | ExtentExpression | PrimaryExpression 94 Kernel Modeling Language v1.0 -ConditionalExpression : OperatorExpression = operator = 'if' ownedRelationship += ArgumentMember '?' ownedRelationship += ArgumentExpressionMember 'else' ownedRelationship += ArgumentExpressionMember ownedRelationship += EmptyResultMember ConditionalBinaryOperatorExpression : OperatorExpression = ownedRelationship += ArgumentMember operator = ConditionalBinaryOperator ownedRelationship += ArgumentExpressionMember ownedRelationship += EmptyResultMember ConditionalBinaryOperator = '??' | 'or' | 'and' | 'implies' BinaryOperatorExpression : OperatorExpression = ownedRelationship += ArgumentMember operator = BinaryOperator ownedRelationship += ArgumentMember ownedRelationship += EmptyResultMember BinaryOperator = '|' | '&' | 'xor' | '..' | '==' | '!=' | '===' | '!==' | '<' | '>' | '<=' | '>=' | '+' | '-' | '*' | '/' | '%' | '^' | '**' UnaryOperatorExpression : OperatorExpression = operator = UnaryOperator ownedRelationship += ArgumentMember ownedRelationship += EmptyResultMember UnaryOperator = '+' | '-' | '~' | 'not' ClassificationExpression : OperatorExpression = ( ownedRelationship += ArgumentMember )? ( operator = ClassificationTestOperator ownedRelationship += TypeReferenceMember | operator = CastOperator ownedRelationship += TypeResultMember ) ownedRelationship += EmptyResultMember ClassificationTestOperator = 'istype' | 'hastype' | '@' CastOperator = 'as' MetaclassificationExpression : OperatorExpression = ownedRelationship += MetadataArgumentMember ( operator = MetaClassificationTestOperator ownedRelationship += TypeReferenceMember | operator = MetaCastOperator ownedRelationship += TypeResultMember ) ownedRelationship += EmptyResultMember ArgumentMember : ParameterMembership = Kernel Modeling Language v1.0 95 -ownedMemberParameter = Argument Argument : Feature = ownedRelationship += ArgumentValue ArgumentValue : FeatureValue = value = OwnedExpression ArgumentExpressionMember : FeatureMembership = ownedRelatedElement += ArgumentExpression ArgumentExpression : Feature = ownedRelationship += ArgumentExpressionValue ArgumentExpressionValue : FeatureValue = value = OwnedExpressionReference MetadataArgumentMember : ParameterMembership = ownedRelatedElement += MetadataArgument MetadataArgument : Feature = ownedRelationship += MetadataValue MetadataValue : FeatureValue = value = MetadataReference MetadataReference : MetadataAccessExpression = ownedRelationship += ElementReferenceMember MetaclassificationTestOperator = '@@' MetaCastOperator = 'meta' ExtentExpression : OperatorExpression = operator = 'all' ownedRelationship += TypeReferenceMember TypeReferenceMember : ParameterMembership = ownedMemberFeature = TypeReference TypeResultMember : ResultParameterMembership = ownedMemberFeature = TypeReference TypeReference : Feature = ownedRelationship += ReferenceTyping ReferenceTyping : FeatureTyping = type = [QualifiedName] EmptyResultMember : ReturnParameterMembership = ownedRelatedElement += EmptyFeature EmptyFeature : Feature = { } Notes 1. OperatorExpressions provide a shorthand notation for InvocationExpressions that invoke a library Function represented as an operator symbol. Table 5 shows the mapping from operator symbols to the Functions they represent from the Kernel Model Library (see Clause 9 ). An 96 Kernel Modeling Language v1.0 -OperatorExpression contains subexpressions called its operands that generally correspond to the argument Expressions of the OperatorExpression , except in the case of operators representing control Functions , in which case the evaluation of certain operands is as determined by the Function (see 8.4.4.9 for details). 2. Though not directly expressed in the syntactic productions given above, in any OperatorExpression containing nested OperatorExpressions , the nested OperatorExpressions shall be implicitly grouped according to the precedence of the operators involved, as given in Table 6 . OperatorExpressions with higher precedence operators shall be grouped more tightly than those with lower precedence operators . Further, all BinaryOperators other than exponentiation are left- associative (i.e, they group to the left), while the exponentiation operators ( ^ and ** ) are right-associative (i.e., they group to the right). 3. The unary operator symbol ~ maps to the library Function DataFunctions::'~' , as shown in Table 5 . This abstract Function may be given a concrete definition in a domain-specific Function library, but no default definition is provided in the Kernel Functions Library. If no domain-specific definition is available, a tool should give a warning if this operator is used. Table 5. Operator Mapping Operator Library Function Description Model-Level Evaluable? all BaseFunctions::'all' Type extent No All argument values are istype BaseFunctions::'istype' directly or indirectly instances Yes of a type All argument values are hastype BaseFunctions::'hastype' Yes directly instances of a type Any argument value is @ BaseFunctions::'@' directly or indirectly an Yes instance of a type Any argument value is @@ BaseFunctions::'@@' directly or indirectly an Yes instance of a metaclass as BaseFunctions::as Select instances of type (cast) Yes Select instances of a meta BaseFunctions::meta Yes metaclass (metacast) == BaseFunctions::'==' Equality Yes != BaseFunctions::'!=' Inequality Yes Same (equality for data === BaseFunctions::'===' values, same lives for Yes occurrences) !== BaseFunctions::'!==' Not same Yes xor DataFunctions::'xor' Logical "exclusive or" Yes not DataFunctions::'not' Logical "not" Yes ~ DataFunctions::'~' Undefined No | DataFunctions::'|' Logical "inclusive or" Yes & DataFunctions::'&' Logical "and" Yes < DataFunctions::'<' Less than Yes Kernel Modeling Language v1.0 97 -Operator Library Function Description Model-Level Evaluable? > DataFunctions::'>' Greater than Yes <= DataFunctions::'<=' Less than or equal to Yes >= DataFunctions::'>=' Greater than or equal to Yes + DataFunctions::'+' Addition Yes - DataFunctions::'-' Subtraction Yes * DataFunctions::'*' Multiplication Yes / DataFunctions::'/' Division Yes % DataFunctions::'%' Remainder Yes ^ ** DataFunctions::'^' Exponentiation Yes .. DataFunctions::'..' Range construction Yes ?? ControlFunctions::'??' Null coalescing Yes if ControlFunctions::'if' Conditional test (ternary) Yes or ControlFunctions::'or' Conditional "or" Yes and ControlFunctions::'and' Conditional "and" Yes implies ControlFunctions::'implies' Conditional "implication" Yes Table 6. Operator Precedence (highest to lowest) Unary all + - ~ not Binary ^ ** * / % + - .. < > <= >= istype hastype @ @@ as meta == != === !== & and 98 Kernel Modeling Language v1.0 -xor | or implies ?? Ternary if 8.2.5.8.2 Primary Expressions PrimaryExpression : Expression = FeatureChainExpression | NonFeatureChainPrimaryExpression PrimaryArgumentValue : FeatureValue = value = PrimaryExpression PrimaryArgument : Feature = ownedRelationship += PrimaryArgumentValue PrimaryArgumentMember : ParameterMembership = ownedMemberParameter = PrimaryArgument NonFeatureChainPrimaryExpression : Expression = BracketExpression | IndexExpression | SequenceExpression | SelectExpression | CollectExpression | FunctionOperationExpression | BaseExpression NonFeatureChainPrimaryArgumentValue : FeatureValue = value = NonFeatureChainPrimaryExpression NonFeatureChainPrimaryArgument : Feature = ownedRelationship += NonFeatureChainPrimaryArgumentValue NonFeatureChainPrimaryArgumentMember : ParameterMembership = ownedMemberParameter = PrimaryArgument BracketExpression : OperatorExpression = ownedRelationship += PrimaryArgumentMember operator = '[' ownedRelationship += SequenceExpressionListMember ']' IndexExpression = ownedRelationship += PrimaryArgumentMember '#' '(' ownedRelationship += SequenceExpressionListMember ')' SequenceExpression : Expression = '(' SequenceExpressionList ')' SequenceExpressionList : Expression = Kernel Modeling Language v1.0 99 -OwnedExpression ','? | SequenceOperatorExpression SequenceOperatorExpression : OperatorExpression = ownedRelationship += OwnedExpressionMember operator = ',' ownedRelationship += SequenceExpressionListMember SequenceExpressionListMember : FeatureMembership = ownedMemberFeature = SequenceExpressionList FeatureChainExpression = ownedRelationship += NonFeatureChainPrimaryArgumentMember '.' ownedRelationship += FeatureChainMember CollectExpression = ownedRelationship += PrimaryArgumentMember '.' ownedRelationship += BodyArgumentMember SelectExpression = ownedRelationship += PrimaryArgumentMember '.?' ownedRelationship += BodyArgumentMember FunctionOperationExpression : InvocationExpression = ownedRelationship += PrimaryArgumentMember '->' ownedRelationship += InvocationTypeMember ( ownedRelationship += BodyArgumentMember | ownedRelationship += FunctionReferenceArgumentMember | ArgumentList ) ownedRelationship += EmptyResultMember BodyArgumentMember : ParameterMembership = ownedMemberParameter = BodyArgument BodyArgument : Feature = ownedRelationship += BodyArgumentValue BodyArgumentValue : FeatureValue = value = BodyExpression FunctionReferenceArgumentMember : ParameterMembership = ownedMemberParameter = FunctionReferenceArgument FunctionReferenceArgument : Feature = ownedRelationship += FunctionReferenceArgumentValue FunctionReferenceArgumentValue : FeatureValue = value = FunctionReferenceExpression FunctionReferenceExpression : FeatureReferenceExpression = ownedRelationship += FunctionReferenceMember FunctionReferenceMember : FeatureMembership = ownedMemberFeature = FunctionReference FunctionReference : Expression = ownedRelationship += ReferenceTyping FeatureChainMember : Membership = FeatureReferenceMember | OwnedFeatureChainMember OwnedFeatureChainMember : OwningMembership = ownedMemberElement = FeatureChain 100 Kernel Modeling Language v1.0 -Notes 1. Primary expressions provide additional shorthand notations for certain kinds of InvocationExpressions . For those cases in which the InvocationExpression is an OperatorExpression , its operator shall be resolved to the appropriate library function as given in Table 7 . Note also that, for a CollectionExpression or SelectExpression , the abstract syntax constrains the operator to be collect and select , respectively, separately from the . and .? symbols used in their concrete syntax notation (see 8.3.4.8.2 and 8.3.4.8.18 ). 2. The grammar allows a bracket syntax [ ... ] that parses to an invocation of the library Function BaseFunctions::'[' , as shown in Table 7 . This notation is available for use with domain-specific library models that given a concrete definition to the abstract base '[' Function , but no default definition is provided in the Kernel Functions Library. If no domain-specific definition is available, a tool should give a warning if this operator is used. Table 7. Primary Expression Operator Mapping Operator Library Function Description Model-level Evaluable? [ BaseFunctions::'[' Undefined No # BaseFunctions::'#' Indexing Yes , BaseFunctions::',' Sequence construction Yes . ControlFunctions::'.' Feature chaining Yes collect ControlFunctions::collect Sequence collection Yes select ControlFunctions::select Sequence selection Yes 8.2.5.8.3 Base Expressions BaseExpression : Expression = NullExpression | LiteralExpression | FeatureReferenceExpression | MetadataAccessExpression | InvocationExpression | ConstructorExpression | BodyExpression NullExpression : NullExpression = 'null' | '(' ')' FeatureReferenceExpression : FeatureReferenceExpression = ownedRelationship += FeatureReferenceMember ownedRelationship += EmptyResultMember FeatureReferenceMember : Membership = memberElement = FeatureReference FeatureReference : Feature = [QualifiedName] MetadataAccessExpression = ownedRelationship += ElementReferenceMember '.' 'metadata' ElementReferenceMember : Membership = memberElement = [QualifiedName] InvocationExpression : InvocationExpression = ownedRelationship += InstatiatedTypeMember Kernel Modeling Language v1.0 101 -ArgumentList ownedRelationship += EmptyResultMember ConstructorExpression = 'new' ownedRelationship += InstantiatedTypeMember ownedRelationship += ConstructorResultMember ConstructorResultMember : ReturnParameterMembership = ownedRelatedElement += ConstructorResult ConstructorResult : Feature = ArgumentList InstantiatedTypeMember : Membership = memberElement = InstantiatedTypeReference | OwnedFeatureChainMember InstantiatedTypeReference : Type = [QualifiedName] ArgumentList : Feature = '(' ( PositionalArgumentList | NamedArgumentList )? ')' PositionalArgumentList : Feature = e.ownedRelationship += ArgumentMember ( ',' e.ownedRelationship += ArgumentMember )* NamedArgumentList : Feature = ownedRelationship += NamedArgumentMember ( ',' ownedRelationship += NamedArgumentMember )* NamedArgumentMember : FeatureMembership = ownedMemberFeature = NamedArgument NamedArgument : Feature = ownedRelationship += ParameterRedefinition '=' ownedRelationship += ArgumentValue ParameterRedefinition : Redefinition = redefinedFeature = [QualifiedName] BodyExpression : FeatureReferenceExpression = ownedRelationship += ExpressionBodyMember ExpressionBodyMember : FeatureMembership = ownedMemberFeature = ExpressionBody ExpressionBody : Expression = '{' FunctionBodyPart '}' 8.2.5.8.4 Literal Expressions LiteralExpression = LiteralBoolean | LiteralString | LiteralInteger | LiteralReal | LiteralInfinity LiteralBoolean = value = BooleanValue BooleanValue : Boolean = 102 Kernel Modeling Language v1.0 -'true' | 'false' LiteralString = value = STRING_VALUE LiteralInteger = value = DECIMAL_VALUE LiteralReal = value = RealValue RealValue : Real = DECIMAL_VALUE? '.' ( DECIMAL_VALUE | EXPONENTIAL_VALUE ) | EXPONENTIAL_VALUE LiteralInfinity = '*' 8.2.5.9 Interactions Concrete Syntax 8.2.5.9.1 Interactions Interaction = TypePrefix 'interaction' ClassifierDeclaration TypeBody 8.2.5.9.2 Flows Flow = FeaturePrefix 'flow' ItemFlowDeclaration TypeBody SuccessionFlow = FeaturePrefix 'succession' 'flow' ItemFlowDeclaration TypeBody FlowDeclaration : Flow = FeatureDeclaration ValuePart? ( 'of' ownedRelationship += PayloadFeatureMember )? ( 'from' ownedRelationship += FlowEndMember 'to' ownedRelationship += FlowEndMember )? | ( isSufficient ?= 'all' )? ownedRelationship += FlowEndMember 'to' ownedRelationship += FlowEndMember PayloadFeatureMember : FeatureMembership = ownedRelatedElement = PayloadFeature PayloadFeature = Identification PayloadFeatureSpecializationPart ValuePart? | Identification ValuePart | ( ownedRelationship += OwnedFeatureTyping ( ownedRelationship += OwnedMultiplicity )? | ownedRelationship += OwnedMultiplicity ( ownedRelationship += OwnedFeatureTyping )? PayloadFeatureSpecializationPart : Feature = FeatureSpecialization+ MultiplicityPart? FeatureSpecialization* | MultiplicityPart FeatureSpecialization+ FlowEndMember : EndFeatureMembership = ownedRelatedElement += FlowEnd Kernel Modeling Language v1.0 103 -FlowEnd = ( ownedRelationship += OwnedReferenceSubsetting '.' )? ownedRelationship += FlowFeatureMember FlowFeatureMember : FeatureMembership = ownedRelatedElement += FlowFeature FlowFeature : Feature = ownedRelationship += FlowFeatureRedefinition (See Note 1) FlowFeatureRedefinition : Redefinition = redefinedFeature = [QualifiedName] Notes 1. To ensure that an FlowFeature passes the validateRedefinitionDirectionConformance constraint (see 8.3.3.3.8 ), its direction must be set to the direction of its redefinedFeature , relative to its owning FlowEnd , that is, the result of the following OCL expression: owningType.directionOf(ownedRedefinition->at(1).redefinedFeature) 8.2.5.10 Feature Values Concrete Syntax ValuePart : Feature = ownedRelationship += FeatureValue FeatureValue = ( '=' | isInitial ?= ':=' | isDefault ?= 'default' ( '=' | isInitial ?= ':=' )? ) ownedRelatedElement += OwnedExpression 8.2.5.11 Multiplicities Concrete Syntax Multiplicity = MultiplicitySubset | MultiplicityRange MultiplicitySubset : Multiplicity = 'multiplicity' Identification Subsets TypeBody MultiplicityRange = 'multiplicity' Identification MultiplicityBounds TypeBody OwnedMultiplicity : OwningMembership = ownedRelatedElement += OwnedMultiplicityRange OwnedMultiplicityRange : MultiplicityRange = MultiplicityBounds MultiplicityBounds : MultiplicityRange = '[' ( ownedRelationship += MultiplicityExpressionMember '..' )? ownedRelationship += MultiplicityExpressionMember ']' MultiplicityExpressionMember : OwningMembership = ownedRelatedElement += ( LiteralExpression | FeatureReferenceExpression ) 104 Kernel Modeling Language v1.0 -8.2.5.12 Metadata Concrete Syntax Metaclass = TypePrefix 'metaclass' ClassifierDeclaration TypeBody PrefixMetadataAnnotation : Annotation = '#' ownedRelatedElement += PrefixMetadataFeature PrefixMetadataMember : OwningMembership = '#' ownedRelatedElement += PrefixMetadataFeature PrefixMetadataFeature : MetadataFeature : ownedRelationship += OwnedFeatureTyping MetadataFeature = ( ownedRelationship += PrefixMetadataMember )* ( '@' | 'metadata' ) MetadataFeatureDeclaration ( 'about' ownedRelationship += Annotation ( ',' ownedRelationship += Annotation )* )? MetadataBody MetadataFeatureDeclaration : MetadataFeature = ( Identification ( ':' | 'typed' 'by' ) )? ownedRelationship += OwnedFeatureTyping MetadataBody : Feature = ';' | '{' ( ownedRelationship += MetadataBodyElement )* '}' MetadataBodyElement : Membership = NonFeatureMember | MetadataBodyFeatureMember | AliasMember | Import MetadataBodyFeatureMember : FeatureMembership = ownedMemberFeature = MetadataBodyFeature MetadataBodyFeature : Feature = 'feature'? ( ':>>' | 'redefines')? ownedRelationship += OwnedRedefinition FeatureSpecializationPart? ValuePart? MetadataBody 8.2.5.13 Packages Concrete Syntax Package = ( ownedRelationship += PrefixMetadataMember )* PackageDeclaration PackageBody LibraryPackage = ( isStandard ?= 'standard' ) 'library' ( ownedRelationship += PrefixMetadataMember )* PackageDeclaration PackageBody PackageDeclaration : Package = 'package' Identification PackageBody : Package = ';' | '{' ( NamespaceBodyElement | ownedRelationship += ElementFilterMember Kernel Modeling Language v1.0 105 -)* '}' ElementFilterMember : ElementFilterMembership = MemberPrefix 'filter' condition = OwnedExpression ';' 8.3 Abstract Syntax 8.3.1 Abstract Syntax Overview Kernel DataTypes Classes Structures Associations Connectors The Kernel layer completes the KerML metamodel. Behaviors Functions Expressions Interactions FeatureValues Multiplicities Metadata Packages «import» Core The Core layer provides the Types semantic foundation for KerML. Classifiers Features «import» Root Elements The Root layer provides the Dependencies syntactic foundation for KerML. Annotations Namespaces Figure 1. KerML Syntax Layers The KerML abstract syntax is specified as a UML model conforming to the CMOF conformance point of the Meta Object Facility Core Specification [MOF]. As shown in Fig. 1 , this model is divided into three top-level packages corresponding to the three layers of KerML (see 8.1 ). Each top-level package contains nested packages for the modeling areas it addresses. Further, the Core package imports the Root package and the Kernel package imports the Core package, so that the Kernel package contains (as owned or imported members) all abstract syntax elements. 106 Kernel Modeling Language v1.0 -Fig. 2 shows the generalization hierarchy for all abstract syntax elements, other than those that represent KerML Relationships, and Fig. 3 shows a similar hierarchy for all abstract syntax elements that represent Relationships. Element Namespace AnnotatingElement Type Package MetadataFeature Comment TextualRepresentation Classifier Feature Documentation Association Class DataType Multiplicity Step Connector Interaction AssociationStructure Structure Behavior MultiplicityRange Expression Flow Succession BindingConnector Metaclass Function SuccessionFlow Predicate NullExpression LiteralExpression InstantiationExpression BooleanExpression MetadataAccessExpression FeatureReferenceExpression LiteralBoolean LiteralString LiteralInteger LiteralRational LiteralInfinity Invariant InvocationExpression ConstructorExpression OperatorExpression FeatureChainExpression CollectExpression SelectExpression IndexExpression Figure 2. KerML Element Hierarchy Element Relationship Import Membership TypeFeaturing Annotation Unioning Differencing Intersecting Association MembershipImport NamespaceImport OwningMembership FeatureChaining Specialization Conjugation Disjoining Connector FeatureValue ElementFilterMembership FeatureMembership FeatureTyping Subclassification Subsetting EndFeatureMembership ParameterMembership ResultExpressionMembership ReturnParameterMembership Redefinition ReferenceSubsetting CrossSubsetting Figure 3. KerML Relationship Hierarchy The MOF-compliant class model for the abstract syntax defines the basic structural representation for any KerML model. It is also the basis for the textual concrete syntax (see 8.2 ) and for other forms of serialization used for interchanging models (see Clause 10 ). In addition to this basic structure, the abstract syntax also includes constraints defined on various metaclasses. A conformant tool shall be able to accept any KerML model that conforms to the structural abstract syntax class model, and it may then additionally report on and/or enforce the constraints on a model so represented (as further described below). Kernel Modeling Language v1.0 107 -The abstract syntax model includes three kinds of constraints: 1. Derivation constraints. These constraints specify the how the values of the derived properties of a metaclass are computed from the values of other properties in the abstract syntax model. A tool conformant to the KerML abstract syntax shall always enforce derivation constraints. However, the computed values of derived properties may depend on whether implied relationships are included in the model or not (see below). A derivation constraint has a name starting with the word derive , followed by the name of the metaclass it constrains, followed by the name of the derived property it is for. The OCL specification of such a constraint always has the form of an equality, with the derived property on the left- hand side and the derivation expression on the right-hand side. For example, the derivation constraint for the derived property Element::ownedElement is called deriveElementOwnedElement and has the OCL specification ownedElement = ownedRelationship.ownedRelatedElement . Note. Derivation constraints are not included for derived properties in the following cases: ◦ The derived property subsets a property with multiplicity upper bound 1. In this case, if the derived property has a value, it must be the same as that of the subsetted property. ◦ The derived property redefines another derived property. In this case, the derivation of the redefined property also applies to the redefining property, though the redefining property will generally place additional constraints on type and/or multiplicity. 2. Semantic constraints. These constraints specify relationships that are semantically required in a KerML model (see 8.4.2 ), particularly relationships with elements in the Kernel Semantic Library (see 9.2 ). These constraints may be violated by a model as entered by a user or as interchanged. In this case, a tool may satisfy the constraints by introducing implied relationships into the model, it may simply report their violation, or it may ignore the violations. Semantic constraints have names that start with the word check , followed by the name of the constrained metaclass, followed by a descriptive word or phrase. For example, checkTypeSpecialization . 3. Validation constraints. These constraints specify additional syntactic conditions that must be satisfied in order to give a model a proper semantic interpretation. They are written presuming that all semantic constraints are satisfied. A valid model is a model that satisfies all validation constraints. A tool conformant to the KerML abstract syntax should report violations of validation constraints. A tool conformant to the KerML semantics is only required to operate on valid models. Validation constraints have names that start with the word validate , followed by the name of the metaclass, followed by a descriptive word or phrase. For example, validateConnectorRelatedFeatures . 108 Kernel Modeling Language v1.0 -8.3.2 Root Abstract Syntax 8.3.2.1 Elements and Relationships Abstract Syntax 8.3.2.1.1 Overview {ordered} +/ownedElement 0..* +/owner 0..1 Element +target +elementId : String{id} +ownedRelatedElement 0..* +aliasIds : String [0..*]{ordered} {subsets relatedElement, 0..* +declaredShortName : String [0..1] ordered} {subsets relatedElement, +declaredName : String [0..1] +source ordered} +/shortName : String [0..1] 0..* +/name : String [0..1] {subsets relatedElement, +/qualifiedName : String [0..1] +owningRelatedElement ordered} +isImpliedIncluded : Boolean = false 0..1 +/isLibraryElement : Boolean +/relatedElement {subsets +escapedName() : String [0..1] 0..* relatedElement} +effectiveShortName() : String [0..1] {ordered, nonunique} +effectiveName() : String [0..1] +libraryNamespace() : Namespace [0..1] +path() : String +/relationship Relationship 0..* +ownedRelationship +isImplied : Boolean = false {union, nonunique} 0..* +libraryNamespace() : Namespace [0..1]{redefines libraryNamespace} {subsets relationship, +sourceRelationship +path() : String{redefines path} ordered} 0..* +owningRelationship {subsets relationship} 0..1 +targetRelationship {subsets relationship} 0..* {subsets relationship} Figure 4. Elements It is a general design principle of the KerML abstract syntax that non- Relationship Elements are related only by reified instances of Relationships . All other meta-associations between Elements are derived from these reified Relationships . For example, the owningRelatedElement / ownedRelationship meta-association between an Element and a Relationship is fundamental to establishing the structure of a model. However, the owner / ownedElement meta-association between two Elements is derived, based on the Relationship structure between them. 8.3.2.1.2 Element Description An Element is a constituent of a model that is uniquely identified relative to all other Elements . It can have Relationships with other Elements . Some of these Relationships might imply ownership of other Elements , which means that if an Element is deleted from a model, then so are all the Elements that it owns. General Classes None. Kernel Modeling Language v1.0 109 -Attributes aliasIds : String [0..*] {ordered} Various alternative identifiers for this Element. Generally, these will be set by tools. declaredName : String [0..1] The declared name of this Element . declaredShortName : String [0..1] An optional alternative name for the Element that is intended to be shorter or in some way more succinct than its primary name . It may act as a modeler-specified identifier for the Element , though it is then the responsibility of the modeler to maintain the uniqueness of this identifier within a model or relative to some other context. /documentation : Documentation [0..*] {subsets ownedElement, annotatingElement, ordered} The Documentation owned by this Element. elementId : String The globally unique identifier for this Element. This is intended to be set by tooling, and it must not change during the lifetime of the Element. isImpliedIncluded : Boolean Whether all necessary implied Relationships have been included in the ownedRelationships of this Element. This property may be true, even if there are not actually any ownedRelationships with isImplied = true , meaning that no such Relationships are actually implied for this Element. However, if it is false, then ownedRelationships may not contain any implied Relationships. That is, either all required implied Relationships must be included, or none of them. /isLibraryElement : Boolean Whether this Element is contained in the ownership tree of a library model. /name : String [0..1] The name to be used for this Element during name resolution within its owningNamespace . This is derived using the effectiveName() operation. By default, it is the same as the declaredName , but this is overridden for certain kinds of Elements to compute a name even when the declaredName is null. /ownedAnnotation : Annotation [0..*] {subsets ownedRelationship, annotation, ordered} The ownedRelationships of this Element that are Annotations , for which this Element is the annotatedElement . /ownedElement : Element [0..*] {ordered} The Elements owned by this Element, derived as the ownedRelatedElements of the ownedRelationships of this Element. ownedRelationship : Relationship [0..*] {subsets relationship, ordered} The Relationships for which this Element is the owningRelatedElement. 110 Kernel Modeling Language v1.0 -/owner : Element [0..1] The owner of this Element, derived as the owningRelatedElement of the owningRelationship of this Element, if any. /owningMembership : OwningMembership [0..1] {subsets owningRelationship, membership} The owningRelationship of this Element , if that Relationship is a Membership . /owningNamespace : Namespace [0..1] {subsets namespace} The Namespace that owns this Element , which is the membershipOwningNamespace of the owningMembership of this Element , if any. owningRelationship : Relationship [0..1] {subsets relationship} The Relationship for which this Element is an ownedRelatedElement, if any. /qualifiedName : String [0..1] The full ownership-qualified name of this Element , represented in a form that is valid according to the KerML textual concrete syntax for qualified names (including use of unrestricted name notation and escaped characters, as necessary). The qualifiedName is null if this Element has no owningNamespace or if there is not a complete ownership chain of named Namespaces from a root Namespace to this Element . If the owningNamespace has other Elements with the same name as this one, then the qualifiedName is null for all such Elements other than the first. /shortName : String [0..1] The short name to be used for this Element during name resolution within its owningNamespace . This is derived using the effectiveShortName() operation. By default, it is the same as the declaredShortName , but this is overridden for certain kinds of Elements to compute a shortName even when the declaredName is null. /textualRepresentation : TextualRepresentation [0..*] {subsets ownedElement, annotatingElement, ordered} The TextualRepresentations that annotate this Element . Operations effectiveName() : String [0..1] Return an effective name for this Element . By default this is the same as its declaredName . body: declaredName effectiveShortName() : String [0..1] Return an effective shortName for this Element . By default this is the same as its declaredShortName . body: declaredShortName escapedName() : String [0..1] Return name , if that is not null, otherwise the shortName , if that is not null, otherwise null. If the returned value is non-null, it is returned as-is if it has the form of a basic name, or, otherwise, represented as a restricted name Kernel Modeling Language v1.0 111 -according to the lexical structure of the KerML textual notation (i.e., surrounded by single quote characters and with special characters escaped). libraryNamespace() : Namespace [0..1] By default, return the library Namespace of the owningRelationship of this Element, if it has one. body: if owningRelationship <> null then owningRelationship.libraryNamespace() else null endif path() : String Return a unique description of the location of this Element in the containment structure rooted in a root Namespace . If the Element has a non-null qualifiedName , then return that. Otherwise, if it has an owningRelationship , then return the string constructed by appending to the path of it's owningRelationship the character / followed by the string representation of its position in the list of ownedRelatedElements of the owningRelationship (indexed starting at 1). Otherwise, return the empty string. (Note that this operation is overridden for Relationships to use owningRelatedElement when appropriate.) body: if qualifiedName <> null then qualifiedName else if owningRelationship <> null then owningRelationship.path() + '/' + owningRelationship.ownedRelatedElement->indexOf(self).toString() -- A position index shall be converted to a decimal string representation -- consisting of only decimal digits, with no sign, leading zeros or leading -- or trailing whitespace. else '' endif endif Constraints deriveElementDocumentation The documentation of an Element is its ownedElements that are Documentation . documentation = ownedElement->selectByKind(Documentation) deriveElementIsLibraryElement An Element isLibraryElement if libraryNamespace() is not null. isLibraryElement = libraryNamespace() <> null deriveElementName The name of an Element is given by the result of the effectiveName() operation. name = effectiveName() deriveElementOwnedAnnotation The ownedAnnotations of an Element are its ownedRelationships that are Annotations , for which the Element is the annotatedElement . ownedAnnotation = ownedRelationship-> selectByKind(Annotation)-> select(a | a.annotatedElement = self) 112 Kernel Modeling Language v1.0 -deriveElementOwnedElement The ownedElements of an Element are the ownedRelatedElements of its ownedRelationships . ownedElement = ownedRelationship.ownedRelatedElement deriveElementOwner The owner of an Element is the owningRelatedElement of its owningRelationship . owner = owningRelationship.owningRelatedElement deriveElementQualifiedName If this Element does not have an owningNamespace , then its qualifiedName is null. If the owningNamespace of this Element is a root Namespace , then the qualifiedName of the Element is the escaped name of the Element (if any). If the owningNamespace is non-null but not a root Namespace , then the qualifiedName of this Element is constructed from the qualifiedName of the owningNamespace and the escaped name of the Element , unless the qualifiedName of the owningNamespace is null or the escaped name is null, in which case the qualifiedName of this Element is also null. Further, if the owningNamespace has other ownedMembers with the same non-null name as this Element , and this Element is not the first, then the qualifiedName of this Element is null. qualifiedName = if owningNamespace = null then null else if name <> null and owningNamespace.ownedMember-> select(m | m.name = name).indexOf(self) <> 1 then null else if owningNamespace.owner = null then escapedName() else if owningNamespace.qualifiedName = null or escapedName() = null then null else owningNamespace.qualifiedName + '::' + escapedName() endif endif endif endif deriveElementShortName The shortName of an Element is given by the result of the effectiveShortName() operation. shortName = effectiveShortName() deriveElementTextualRepresentation The textualRepresentations of an Element are its ownedElements that are TextualRepresentations . textualRepresentation = ownedElement->selectByKind(TextualRepresentation) deriveOwningNamespace The owningNamespace of an Element is the membershipOwningNamspace of its owningMembership (if any). owningNamespace = if owningMembership = null then null else owningMembership.membershipOwningNamespace endif validateElementIsImpliedIncluded Kernel Modeling Language v1.0 113 -If an Element has any ownedRelationships for which isImplied = true , then the Element must also have isImpliedIncluded = true . (Note that an Element can have isImplied = true even if no ownedRelationships have isImplied = true , indicating the Element simply has no implied Relationships . ownedRelationship->exists(isImplied) implies isImpliedIncluded 8.3.2.1.3 Relationship Description A Relationship is an Element that relates other Element . Some of its relatedElements may be owned, in which case those ownedRelatedElements will be deleted from a model if their owningRelationship is. A Relationship may also be owned by another Element , in which case the ownedRelatedElements of the Relationship are also considered to be transitively owned by the owningRelatedElement of the Relationship . The relatedElements of a Relationship are divided into source and target Elements . The Relationship is considered to be directed from the source to the target Elements . An undirected Relationship may have either all source or all target Elements . A "relationship Element " in the abstract syntax is generically any Element that is an instance of either Relationship or a direct or indirect specialization of Relationship . Any other kind of Element is a "non- relationship Element ". It is a convention of that non-relationship Elements are only related via reified relationship Elements . Any meta-associations directly between non-relationship Elements must be derived from underlying reified Relationship . General Classes Element Attributes isImplied : Boolean Whether this Relationship was generated by tooling to meet semantic rules, rather than being directly created by a modeler. ownedRelatedElement : Element [0..*] {subsets relatedElement, ordered} The relatedElements of this Relationship that are owned by the Relationship. owningRelatedElement : Element [0..1] {subsets relatedElement} The relatedElement of this Relationship that owns the Relationship, if any. /relatedElement : Element [0..*] {ordered, nonunique} The Elements that are related by this Relationship, derived as the union of the source and target Elements of the Relationship. source : Element [0..*] {subsets relatedElement, ordered} The relatedElements from which this Relationship is considered to be directed. target : Element [0..*] {subsets relatedElement, ordered} 114 Kernel Modeling Language v1.0 -The relatedElements to which this Relationship is considered to be directed. Operations libraryNamespace() : Namespace [0..1] {redefines libraryNamespace} Return whether this Relationship has either an owningRelatedElement or owningRelationship that is a library element. body: if owningRelatedElement <> null then owningRelatedElement.libraryNamespace() else if owningRelationship <> null then owningRelationship.libraryNamespace() else null endif endif path() : String {redefines path} If the owningRelationship of the Relationship is null but its owningRelatedElement is non-null, construct the path using the position of the Relationship in the list of ownedRelationships of its owningRelatedElement . Otherwise, return the path of the Relationship as specified for an Element in general. body: if owningRelationship = null and owningRelatedElement <> null then owningRelatedElement.path() + '/' + owningRelatedElement.ownedRelationship->indexOf(self).toString() -- A position index shall be converted to a decimal string representation -- consisting of only decimal digits, with no sign, leading zeros or leading -- or trailing whitespace. else self.oclAsType(Element).path() endif Constraints deriveRelationshipRelatedElement The relatedElements of a Relationship consist of all of its source Elements followed by all of its target Elements . relatedElement = source->union(target) 8.3.2.2 Dependencies Abstract Syntax 8.3.2.2.1 Overview +client +supplier Element 1..* 1..* {redefines source, {redefines ordered} target, ordered} Relationship +clientDependency +supplierDependency Dependency 0..* 0..* {subsets sourceRelationship} {subsets targetRelationship} Figure 5. Dependencies Kernel Modeling Language v1.0 115 -8.3.2.2.2 Dependency Description A Dependency is a Relationship that indicates that one or more client Elements require one more supplier Elements for their complete specification. In general, this means that a change to one of the supplier Elements may necessitate a change to, or re-specification of, the client Elements . Note that a Dependency is entirely a model-level Relationship , without instance-level semantics. General Classes Relationship Attributes client : Element [1..*] {redefines source, ordered} The Element or Elements dependent on the supplier Elements . supplier : Element [1..*] {redefines target, ordered} The Element or Elements on which the client Elements depend in some respect. Operations None. Constraints None. 116 Kernel Modeling Language v1.0 -8.3.2.3 Annotations Abstract Syntax 8.3.2.3.1 Overview +/representedElement Element +/documentedElement 1 {subsets owner, redefines annotatedElement} 1 +/owningAnnotatedElement {subsets owner, redefines annotatedElement} 0..1 +/annotatedElement {subsets annotatedElement, subsets owningRelatedElement} 1..* +annotatedElement {subsets annotation, {ordered} subsets 1 ownedRelationship, {subsets targetRelationship, {redefines target} ordered} ordered} +annotation 0..* 0..* +/ownedAnnotation +/annotatingElement +/annotation AnnotatingElement Annotation 1 0..* +/annotatingElement {redefines source} {subsets sourceRelationship, 0..* ordered} {ordered} +/ownedAnnotatingElement +/owningAnnotatingRelationship 0..1 0..1 {subsets annotatingElement, {subsets annotation, subsets ownedRelatedElement} subsets owningRelationship} +/owningAnnotatingElement +/ownedAnnotatingRelationship 0..1 0..* {subsets annotatingElement, {subsets annotation, subsets owningRelatedElement} subsets ownedRelationship, ordered} Relationship Comment TextualRepresentation +/textualRepresentation +locale : String [0..1] +language : String [1] 0..* +body : String [1] +body : String [1] {subsets annotatingElement, subsets ownedElement, ordered} +/documentation Documentation 0..* {subsets annotatingElement, subsets ownedElement, ordered} Figure 6. Annotation 8.3.2.3.2 AnnotatingElement Description An AnnotatingElement is an Element that provides additional description of or metadata on some other Element . An AnnotatingElement is either attached to its annotatedElements by Annotation Relationships , or it implicitly annotates its owningNamespace . General Classes Element Attributes /annotatedElement : Element [1..*] {ordered} The Elements that are annotated by this AnnotatingElement . If annotation is not empty, these are the annotatedElements of the annotations . If annotation is empty, then it is the owningNamespace of the AnnotatingElement . /annotation : Annotation [0..*] {subsets sourceRelationship, ordered} Kernel Modeling Language v1.0 117 -The Annotations that relate this AnnotatingElement to its annotatedElements . This includes the owningAnnotatingRelationship (if any) followed by all the ownedAnnotatingRelationshps . /ownedAnnotatingRelationship : Annotation [0..*] {subsets annotation, ownedRelationship, ordered} The ownedRelationships of this AnnotatingElement that are Annotations , for which this AnnotatingElement is the annotatingElement . /owningAnnotatingRelationship : Annotation [0..1] {subsets owningRelationship, annotation} The owningRelationship of this AnnotatingRelationship , if it is an Annotation Operations None. Constraints deriveAnnotatingElementAnnotatedElement If an AnnotatingElement has annotations , then its annotatedElements are the annotatedElements of all its annotations . Otherwise, it's single annotatedElement is its owningNamespace . annotatedElement = if annotation->notEmpty() then annotation.annotatedElement else Sequence{owningNamespace} endif deriveAnnotatingElementAnnotation The annotations of an AnnotatingElement are its owningAnnotatingRelationship (if any) followed by all its ownedAnnotatingRelationships . annotation = if owningAnnotatingRelationship = null then ownedAnnotatingRelationship else owningAnnotatingRelationship->prepend(owningAnnotatingRelationship) endif deriveAnnotatingElementOwnedAnnotatingRelationship The ownedAnnotatingRelationships of an AnnotatingElement are its ownedRelationships that are Annotations , for which the AnnotatingElement is not the annotatedElement . ownedAnnotatingRelationship = ownedRelationship-> selectByKind(Annotation)-> select(a | a.annotatedElement <> self) 8.3.2.3.3 Annotation Description An Annotation is a Relationship between an AnnotatingElement and the Element that is annotated by that AnnotatingElement . General Classes Relationship 118 Kernel Modeling Language v1.0 -Attributes annotatedElement : Element {redefines target} The Element that is annotated by the annotatingElement of this Annotation. /annotatingElement : AnnotatingElement {redefines source} The AnnotatingElement that annotates the annotatedElement of this Annotation . This is always either the ownedAnnotatingElement or the owningAnnotatingElement . /ownedAnnotatingElement : AnnotatingElement [0..1] {subsets annotatingElement, ownedRelatedElement} The annotatingElement of this Annotation , when it is an ownedRelatedElement . /owningAnnotatedElement : Element [0..1] {subsets annotatedElement, owningRelatedElement} The annotatedElement of this Annotation , when it is also the owningRelatedElement . /owningAnnotatingElement : AnnotatingElement [0..1] {subsets annotatingElement, owningRelatedElement} The annotatingElement of this Annotation , when it is the owningRelatedElement . Operations None. Constraints deriveAnnotationAnnotatingElement The annotatingElement of an Annotation is either its ownedAnnotatingElement or its owningAnnotatingElement . annotatingElement = if ownedAnnotatingElement <> null then ownedAnnotatingElement else owningAnnotatingElement endif deriveAnnotationOwnedAnnotatingElement The ownedAnnotatingElement of an Annotation is the first ownedRelatedElement that is an AnnotatingElement , if any. ownedAnnotatingElement = let ownedAnnotatingElements : Sequence(AnnotatingElement) = ownedRelatedElement->selectByKind(AnnotatingElement) in if ownedAnnotatingElements->isEmpty() then null else ownedAnnotatingElements->first() endif validateAnnotationAnnotatedElementOwnership An Annotation owns its annotatingElement if and only if it is owned by its annotatedElement . (owningAnnotatedElement <> null) = (ownedAnnotatingElement <> null) Kernel Modeling Language v1.0 119 -validateAnnotationAnnotatingElement Either the ownedAnnotatingElement of an Annotation must be non-null, or the owningAnnotatingElement must be non-null, but not both. ownedAnnotatingElement <> null xor owningAnnotatingElement <> null 8.3.2.3.4 Comment Description A Comment is an AnnotatingElement whose body in some way describes its annotatedElements . General Classes AnnotatingElement Attributes body : String The annotation text for the Comment . locale : String [0..1] Identification of the language of the body text and, optionally, the region and/or encoding. The format shall be a POSIX locale conformant to ISO/IEC 15897, with the format [language[_territory][.codeset][@modifier]] . Operations None. Constraints None. 8.3.2.3.5 Documentation Description Documentation is a Comment that specifically documents a documentedElement , which must be its owner . General Classes Comment Attributes /documentedElement : Element {subsets owner, redefines annotatedElement} The Element that is documented by this Documentation . Operations None. 120 Kernel Modeling Language v1.0 -Constraints None. 8.3.2.3.6 TextualRepresentation Description A TextualRepresentation is an AnnotatingElement whose body represents the representedElement in a given language . The representedElement must be the owner of the TextualRepresentation . The named language can be a natural language, in which case the body is an informal representation, or an artificial language, in which case the body is expected to be a formal, machine-parsable representation. If the named language of a TextualRepresentation is machine-parsable, then the body text should be legal input text as defined for that language . The interpretation of the named language string shall be case insensitive. The following language names are defined to correspond to the given standard languages: kerml Kernel Modeling Language ocl Object Constraint Language alf Action Language for fUML Other specifications may define specific language strings, other than those shown above, to be used to indicate the use of languages from those specifications in KerML TextualRepresentation . If the language of a TextualRepresentation is " kerml ", then the body text shall be a legal representation of the representedElement in the KerML textual concrete syntax. A conforming tool can use such a TextualRepresentation Annotation to record the original KerML concrete syntax text from which an Element was parsed. In this case, it is a tool responsibility to ensure that the body of the TextualRepresentation remains correct (or the Annotation is removed) if the annotated Element changes other than by re-parsing the body text. An Element with a TextualRepresentation in a language other than KerML is essentially a semantically "opaque" Element specified in the other language. However, a conforming KerML tool may interpret such an element consistently with the specification of the named language. General Classes AnnotatingElement Attributes body : String The textual representation of the representedElement in the given language . language : String The natural or artifical language in which the body text is written. /representedElement : Element {subsets owner, redefines annotatedElement} The Element that is represented by this TextualRepresentation . Kernel Modeling Language v1.0 121 -Operations None. Constraints None. 122 Kernel Modeling Language v1.0 -8.3.2.4 Namespaces Abstract Syntax 8.3.2.4.1 Overview +/ownedMemberElement Element 1 {subsets ownedRelatedElement, redefines memberElement} +memberElement 1 {redefines target} +/ownedMember 0..* 0..* +/member {subsets member, ordered} {ordered} {subsets namespace} 0..1 0..* +/owningNamespace +/namespace Namespace +namesOf( element : Element ) : String [0..*] +visibilityOf( mem : Membership ) : VisibilityKind +visibleMemberships( excluded : Namespace [0..*], isRecursive : Boolean, includeAll : Boolean ) : Membership [0..*] +importedMemberships( excluded : Namespace [0..*] ) : Membership [0..*] +membershipsOfVisibility( visibility : VisibilityKind [0..1], excluded : Namespace [0..*] ) : Membership [0..*] +resolve( qualifiedName : String ) : Membership [0..1] +resolveGlobal( qualifiedName : String ) : Membership [0..1] +resolveLocal( name : String ) : Membership [0..1] +resolveVisible( name : String ) : Membership [0..1] +qualificationOf( qualifiedName : String ) : String [0..1] +unqualifiedNameOf( qualifiedName : String ) : String 1..* +/membershipNamespace +/membershipOwningNamespace +/importingNamespace 0..* 1 {union} {subsets membershipNamespace, {subsets subsets owningRelatedElement, membershipNamespace} «enumeration» redefines source} VisibilityKind {subsets membership, subsets private {subsets membership, ownedRelationship, subsets protected ordered} sourceRelationship, ordered} public {union, ordered} +/importedMembership 0..* 0..* 0..* +/ownedMembership +/membership Membership +/memberElementId : String +memberShortName : String [0..1] +membership Relationship +memberName : String [0..1] 0..* +visibility : VisibilityKind = public {subsets targetRelationship} +isDistinguishableFrom( other : Membership ) : Boolean OwningMembership +/ownedMemberElementId : String{redefines memberElementId} +/owningMembership +/ownedMemberShortName : String [0..1]{redefines memberShortName} 0..1 +/ownedMemberName : String [0..1]{redefines memberName} {subsets membership, +path() : String{redefines path} subsets owningRelationship} Figure 7. Namespaces Kernel Modeling Language v1.0 123 -Relationship Import +visibility : VisibilityKind = private +/ownedImport +/importOwningNamespace +/importedElement +/membershipImport +isRecursive : Boolean = false Namespace Element 0..* 1 +isImportAll : Boolean = false 1 0..* {subsets ownedRelationship, {subsets owningRelatedElement, +importedMemberships( excluded : Namespace [0..*] ) : Membership [0..*] +memberElement 1 1 +importedNamespace subsets sourceRelationship, redefines source} {redefines target} {redefines target} ordered} +import MembershipImport NamespaceImport 0..* +importedMemberships( excluded : Namespace [0..*] ) : Membership [0..*]{redefines importedMemberships} +importedMemberships( excluded : Namespace [0..*] ) : Membership [0..*]{redefines importedMemberships} {subsets targetRelationship} +import 0..* {redefines targetRelationship} {redefines target} +importedMembership 1 +membership Membership 0..* {subsets targetRelationship} Figure 8. Imports 8.3.2.4.2 Import Description An Import is an Relationship between its importOwningNamespace and either a Membership (for a MembershipImport ) or another Namespace (for a NamespaceImport ), which determines a set of Memberships that become importedMemberships of the importOwningNamespace . If isImportAll = false (the default), then only public Memberships are considered "visible". If isImportAll = true , then all Memberships are considered "visible", regardless of their declared visibility . If isRecursive = true , then visible Memberships are also recursively imported from owned sub- Namespaces . General Classes Relationship Attributes /importedElement : Element The effectively imported Element for this Import. For a MembershipImport , this is the memberElement of the importedMembership . For a NamespaceImport , it is the importedNamespace . /importOwningNamespace : Namespace {subsets owningRelatedElement, redefines source} The Namespace into which Memberships are imported by this Import, which must be the owningRelatedElement of the Import. isImportAll : Boolean Whether to import memberships without regard to declared visibility. isRecursive : Boolean Whether to recursively import Memberships from visible, owned sub-Namespaces. visibility : VisibilityKind The visibility level of the imported members from this Import relative to the importOwningNamespace . The default is private . Operations 124 Kernel Modeling Language v1.0 -importedMemberships(excluded : Namespace [0..*]) : Membership [0..*] Returns Memberships that are to become importedMemberships of the importOwningNamespace . (The excluded parameter is used to handle the possibility of circular Import Relationships.) Constraints validateImportTopLevelVisibility A top-level Import (that is, one that is owned by a root Namespace ) must have a visibility of private . importOwningNamespace.owner = null implies visibility = VisibilityKind::private 8.3.2.4.3 Membership Description A Membership is a Relationship between a Namespace and an Element that indicates the Element is a member of (i.e., is contained in) the Namespace. Any memberNames specify how the memberElement is identified in the Namespace and the visibility specifies whether or not the memberElement is publicly visible from outside the Namespace . If a Membership is an OwningMembership , then it owns its memberElement , which becomes an ownedMember of the membershipOwningNamespace . Otherwise, the memberNames of a Membership are effectively aliases within the membershipOwningNamespace for an Element with a separate OwningMembership in the same or a different Namespace . General Classes Relationship Attributes memberElement : Element {redefines target} The Element that becomes a member of the membershipOwningNamespace due to this Membership . /memberElementId : String The elementId of the memberElement . memberName : String [0..1] The name of the memberElement relative to the membershipOwningNamespace . /membershipOwningNamespace : Namespace {subsets membershipNamespace, owningRelatedElement, redefines source} The Namespace of which the memberElement becomes a member due to this Membership . memberShortName : String [0..1] The short name of the memberElement relative to the membershipOwningNamespace . visibility : VisibilityKind Kernel Modeling Language v1.0 125 -Whether or not the Membership of the memberElement in the membershipOwningNamespace is publicly visible outside that Namespace . Operations isDistinguishableFrom(other : Membership) : Boolean Whether this Membership is distinguishable from a given other Membership . By default, this is true if this Membership has no memberShortName or memberName ; or each of the memberShortName and memberName are different than both of those of the other Membership ; or neither of the metaclasses of the memberElement of this Membership and the memberElement of the other Membership conform to the other. But this may be overridden in specializations of Membership . body: not (memberElement.oclKindOf(other.memberElement.oclType()) or other.memberElement.oclKindOf(memberElement.oclType())) or (shortMemberName = null or (shortMemberName <> other.shortMemberName and shortMemberName <> other.memberName)) and (memberName = null or (memberName <> other.shortMemberName and memberName <> other.memberName))) Constraints deriveMembershipMemberElementId The memberElementId of a Membership is the elementId of its memberElement . memberElementId = memberElement.elementId 8.3.2.4.4 MembershipImport Description A MembershipImport is an Import that imports its importedMembership into the importOwningNamespace . If isRecursive = true and the memberElement of the importedMembership is a Namespace , then the equivalent of a recursive NamespaceImport is also performed on that Namespace . General Classes Import Attributes importedMembership : Membership {redefines target} The Membership to be imported. Operations importedMemberships(excluded : Namespace [0..*]) : Membership [0..*] {redefines importedMemberships} Returns at least the importedMembership . If isRecursive = true and the memberElement of the importedMembership is a Namespace , then Memberships are also recursively imported from that Namespace . body: if not isRecursive or not importedElement.oclIsKindOf(Namespace) or 126 Kernel Modeling Language v1.0 -excluded->includes(importedElement) then Sequence{importedMembership} else importedElement.oclAsType(Namespace). visibleMemberships(excluded, true, importAll)-> prepend(importedMembership) endif Constraints deriveMembershipImportImportedElement The importedElement of a MembershipImport is the memberElement of its importedMembership . importedElement = importedMembership.memberElement 8.3.2.4.5 Namespace Description A Namespace is an Element that contains other Elements , known as its members , via Membership Relationships with those Elements . The members of a Namespace may be owned by the Namespace , aliased in the Namespace , or imported into the Namespace via Import Relationships . A Namespace can provide names for its members via the memberNames and memberShortNames specified by the Memberships in the Namespace . If a Membership specifies a memberName and/or memberShortName , then those are names of the corresponding memberElement relative to the Namespace . For an OwningMembership , the ownedMemberName and ownedMemberShortName are given by the Element name and shortName . Note that the same Element may be the memberElement of multiple Memberships in a Namespace (though it may be owned at most once), each of which may define a separate alias for the Element relative to the Namespace . General Classes Element Attributes /importedMembership : Membership [0..*] {subsets membership, ordered} The Memberships in this Namespace that result from the ownedImports of this Namespace . /member : Element [0..*] {ordered} The set of all member Elements of this Namespace , which are the memberElements of all memberships of the Namespace . /membership : Membership [0..*] {ordered, union} All Memberships in this Namespace , including (at least) the union of ownedMemberships and importedMemberships . /ownedImport : Import [0..*] {subsets sourceRelationship, ownedRelationship, ordered} The ownedRelationships of this Namespace that are Imports , for which the Namespace is the importOwningNamespace . /ownedMember : Element [0..*] {subsets member, ordered} Kernel Modeling Language v1.0 127 -The owned members of this Namespace , which are the ownedMemberElements of the ownedMemberships of the Namespace . /ownedMembership : Membership [0..*] {subsets membership, sourceRelationship, ownedRelationship, ordered} The ownedRelationships of this Namespace that are Memberships , for which the Namespace is the membershipOwningNamespace . Operations importedMemberships(excluded : Namespace [0..*]) : Membership [0..*] Derive the imported Memberships of this Namespace as the importedMembership of all ownedImports , excluding those Imports whose importOwningNamespace is in the excluded set, and excluding Memberships that have distinguisibility collisions with each other or with any ownedMembership . body: ownedImport.importedMemberships(excluded->including(self)) membershipsOfVisibility(visibility : VisibilityKind [0..1], excluded : Namespace [0..*]) : Membership [0..*] If visibility is not null, return the Memberships of this Namespace with the given visibility , including ownedMemberships with the given visibility and Memberships imported with the given visibility . If visibility is null, return all ownedMemberships and imported Memberships regardless of visibility. When computing imported Memberships , ignore this Namespace and any Namespaces in the given excluded set. body: ownedMembership-> select(mem | visibility = null or mem.visibility = visibility)-> union(ownedImport-> select(imp | visibility = null or imp.visibility = visibility). importedMemberships(excluded->including(self))) namesOf(element : Element) : String [0..*] Return the names of the given element as it is known in this Namespace . body: let elementMemberships : Sequence(Membership) = memberships->select(memberElement = element) in memberships.memberShortName-> union(memberships.memberName)-> asSet() qualificationOf(qualifiedName : String) : String [0..1] Return a string with valid KerML syntax representing the qualification part of a given qualifiedName , that is, a qualified name with all the segment names of the given name except the last. If the given qualifiedName has only one segment, then return null. body: No OCL resolve(qualifiedName : String) : Membership [0..1] Resolve the given qualified name to the named Membership (if any), starting with this Namespace as the local scope. The qualified name string must conform to the concrete syntax of the KerML textual notation. According to the KerML name resolution rules every qualified name will resolve to either a single Membership , or to none. body: let qualification : String = qualificationOf(qualifiedName) in let name : String = unqualifiedNameOf(qualifiedName) in if qualification = null then resolveLocal(name) 128 Kernel Modeling Language v1.0 -else if qualification = '$' then resolveGlobal(name) else let namespaceMembership : Membership = resolve(qualification) in if namespaceMembership = null or not namespaceMembership.memberElement.oclIsKindOf(Namespace) then null else namespaceMembership.memberElement.oclAsType(Namespace). resolveVisible(name) endif endif endif resolveGlobal(qualifiedName : String) : Membership [0..1] Resolve the given qualified name to the named Membership (if any) in the effective global Namespace that is the outermost naming scope. The qualified name string must conform to the concrete syntax of the KerML textual notation. body: No OCL resolveLocal(name : String) : Membership [0..1] Resolve a simple name starting with this Namespace as the local scope, and continuing with containing outer scopes as necessary. However, if this Namespace is a root Namespace , then the resolution is done directly in global scope. body: if owningNamespace = null then resolveGlobal(name) else let memberships : Membership = membership-> select(memberShortName = name or memberName = name) in if memberships->notEmpty() then memberships->first() else owningNamspace.resolveLocal(name) endif endif resolveVisible(name : String) : Membership [0..1] Resolve a simple name from the visible Memberships of this Namespace . body: let memberships : Sequence(Membership) = visibleMemberships(Set{}, false, false)-> select(memberShortName = name or memberName = name) in if memberships->isEmpty() then null else memberships->first() endif unqualifiedNameOf(qualifiedName : String) : String Return the simple name that is the last segment name of the given qualifiedName . If this segment name has the form of a KerML unrestricted name, then "unescape" it by removing the surrounding single quotes and replacing all escape sequences with the specified character. body: No OCL visibilityOf(mem : Membership) : VisibilityKind Returns this visibility of mem relative to this Namespace . If mem is an importedMembership , this is the visibility of its Import. Otherwise it is the visibility of the Membership itself. Kernel Modeling Language v1.0 129 -body: if importedMembership->includes(mem) then ownedImport-> select(importedMemberships(Set{})->includes(mem)). first().visibility else if memberships->includes(mem) then mem.visibility else VisibilityKind::private endif visibleMemberships(excluded : Namespace [0..*], isRecursive : Boolean, includeAll : Boolean) : Membership [0..*] If includeAll = true , then return all the Memberships of this Namespace . Otherwise, return only the publicly visible Memberships of this Namespace , including ownedMemberships that have a visibility of public and Memberships imported with a visibility of public . If isRecursive = true , also recursively include all visible Memberships of any public owned Namespaces , or, if IncludeAll = true , all Memberships of all owned Namespaces . When computing imported Memberships , ignore this Namespace and any Namespaces in the given excluded set. body: let visibleMemberships : OrderedSet(Membership) = if includeAll then membershipsOfVisibility(null, excluded) else membershipsOfVisibility(VisibilityKind::public, excluded) endif in if not isRecursive then visibleMemberships else visibleMemberships->union(ownedMember-> selectAsKind(Namespace). select(includeAll or owningMembership.visibility = VisibilityKind::public)-> visibleMemberships(excluded->including(self), true, includeAll)) endif Constraints deriveNamespaceImportedMembership The importedMemberships of a Namespace are derived using the importedMemberships() operation, with no initially excluded Namespaces . importedMembership = importedMemberships(Set{}) deriveNamespaceMembers The members of a Namespace are the memberElements of all its memberships . member = membership.memberElement deriveNamespaceOwnedImport The ownedImports of a Namespace are all its ownedRelationships that are Imports . ownedImport = ownedRelationship->selectByKind(Import) deriveNamespaceOwnedMember The ownedMembers of a Namespace are the ownedMemberElements of all its ownedMemberships that are OwningMemberships ownedMember = ownedMembership->selectByKind(OwningMembership).ownedMemberElement deriveNamespaceOwnedMembership 130 Kernel Modeling Language v1.0 -The ownedMemberships of a Namespace are all its ownedRelationships that are Memberships . ownedMembership = ownedRelationship->selectByKind(Membership) validateNamespaceDistinguishibility All memberships of a Namespace must be distinguishable from each other. membership->forAll(m1 | membership->forAll(m2 | m1 <> m2 implies m1.isDistinguishableFrom(m2))) 8.3.2.4.6 NamespaceImport Description A NamespaceImport is an Import that imports Memberships from its importedNamespace into the importOwningNamespace . If isRecursive = false , then only the visible Memberships of the importedNamespace are imported. If isRecursive = true , then, in addition, Memberships are recursively imported from any ownedMembers of the importedNamespace that are Namespaces . General Classes Import Attributes importedNamespace : Namespace {redefines target} The Namespace whose visible Memberships are imported by this NamespaceImport . Operations importedMemberships(excluded : Namespace [0..*]) : Membership [0..*] {redefines importedMemberships} Returns at least the visible Memberships of the importedNamespace . If isRecursive = true , then Memberships are also recursively imported from any ownedMembers of the importedNamespace that are themselves Namespaces . body: if excluded->includes(importedNamespace) then Sequence{} else importedNamespace.visibleMemberships(excluded, isRecursive, isImportAll) Constraints deriveNamespaceImportImportedElement The importedElement of a NamespaceImport is its importedNamespace . importedElement = importedNamespace 8.3.2.4.7 VisibilityKind Description VisibilityKind is an enumeration whose literals specify the visibility of a Membership of an Element in a Namespace outside of that Namespace . Note that "visibility" specifically restricts whether an Element in a Namespace may be referenced by name from outside the Namespace and only otherwise restricts access to an Kernel Modeling Language v1.0 131 -Element as provided by specific constraints in the abstract syntax (e.g., preventing the import or inheritance of private Elements ). General Classes None. Literal Values private Indicates a Membership is not visible outside its owning Namespace . protected An intermediate level of visibility between public and private . By default, it is equivalent to private for the purposes of normal access to and import of Elements from a Namespace . However, other Relationships may be specified to include Memberships with protected visibility in the list of memberships for a Namespace (e.g., Specialization ). public Indicates that a Membership is publicly visible outside its owning Namespace . 8.3.2.4.8 OwningMembership Description An OwningMembership is a Membership that owns its memberElement as a ownedRelatedElement . The ownedMemberElement becomes an ownedMember of the membershipOwningNamespace . General Classes Membership Attributes /ownedMemberElement : Element {subsets ownedRelatedElement, redefines memberElement} The Element that becomes an ownedMember of the membershipOwningNamespace due to this OwningMembership . /ownedMemberElementId : String {redefines memberElementId} The elementId of the ownedMemberElement . /ownedMemberName : String [0..1] {redefines memberName} The name of the ownedMemberElement . /ownedMemberShortName : String [0..1] {redefines memberShortName} The shortName of the ownedMemberElement . 132 Kernel Modeling Language v1.0 -Operations path() : String {redefines path} If the ownedMemberElement of this OwningMembership has a non-null qualifiedName , then return the string constructed by appending to that qualifiedName the string "/owningMembership" . Otherwise, return the path of the OwningMembership as specified for a Relationship body: if ownedElement.qualifiedName <> null then ownedElement.qualifiedName + '/owningMembership' else self.oclAsType(Relationship).path() endif Constraints deriveOwningMembershipOwnedMemberName The ownedMemberName of an OwningMembership is the name of its ownedMemberElement . ownedMemberName = ownedMemberElement.name deriveOwningMembershipOwnedMemberShortName The ownedMemberShortName of an OwningMembership is the shortName of its ownedMemberElement . ownedMemberShortName = ownedMemberElement.shortName Kernel Modeling Language v1.0 133 -8.3.3 Core Abstract Syntax 8.3.3.1 Types Abstract Syntax 8.3.3.1.1 Overview {subsets membership, ordered} +/inheritedMembership Membership 0..* Namespace OwningMembership {subsets membershipNamespace} {ordered} +/inheritingType 0..* +/type +/featureMembership Type FeatureMembership 1..* 0..* +isAbstract : Boolean = false {subsets featureMembership, +isSufficient : Boolean = false subsets ownedMembership, +/isConjugated : Boolean ordered} +visibleMemberships( excluded : Namespace [0..*], isRecursive : Boolean, includeAll : Boolean ) : Membership [0..*]{redefines visibleMemberships} +/owningType +/ownedFeatureMembership +inheritedMemberships( excludedNamespaces : Namespace [0..*], excludedTypes : Type [0..*], excludeImplied : Boolean ) : Membership [0..*] 1 0..* +inheritableMemberships( excludedNamespaces : Namespace [0..*], excludedTypes : Type [0..*], excludeImplied : Boolean ) : Membership [0..*] {subsets type, redefines +nonPrivateMemberships( excludedNamespaces : Namespace [0..*], excludedTypes : Type [0..*], excludeImplied : Boolean ) : Membership [0..*] +/owningFeatureMembership 0..1 membershipOwningNamespace} +removeRedefinedFeatures( memberships : Membership [0..*] ) : Membership [0..*] {subsets +allRedefinedFeaturesOf( membership : Membership ) : Feature [0..*] owningMembership} +directionOf( feature : Feature ) : FeatureDirectionKind [0..1] +directionOfExcluding( feature : Feature, excluded : Type [0..*] ) : FeatureDirectionKind [0..1] {redefines +supertypes( excludeImplied : Boolean ) : Type [0..*] ownedMemberElement} +allSupertypes() : Type [0..*] +/ownedMemberFeature 1 +specializes( supertype : Type ) : Boolean +specializesFromLibrary( libraryTypeName : String ) : Boolean +/typeWithFeature +/feature Feature +isCompatibleWith( otherType : Type ) 0..* 0..* +multiplicities() : Multiplicity [0..*] {subsets namespace} {subsets member, ordered} +/owningType +/ownedFeature 0..1 0..* {subsets featuringType, {subsets ownedMember, subsets owningNamespace, ordered} subsets typeWithFeature} +/directedFeature +/typeWithDirectedFeature 0..* 0..* {subsets typeWithFeature} {subsets feature, ordered} +/typeWithInput +/input 0..* 0..* {subsets typeWithFeature} {subsets directedFeature, ordered} +/typeWithOutput +/output 0..* 0..* {subsets typeWithFeature} {subsets directedFeature, ordered} +/endFeature +/typeWithEndFeature 0..* 0..* {subsets typeWithFeature} {subsets feature, ordered} +/endOwningType +/ownedEndFeature 0..1 0..* {subsets owningType, {subsets endFeature, subsets typeWithEndFeature} subsets ownedFeature, ordered} +/inheritingType +/inheritedFeature 0..* 0..* {subsets typeWithFeature} {subsets feature, ordered} +/typeWithMultiplicity +/multiplicity Multiplicity 0..1 0..1 {subsets namespace} {subsets ownedMember} Figure 9. Types 134 Kernel Modeling Language v1.0 -Relationship +general Specialization +generalization Type 0..* 1 {redefines targetRelationship} {redefines target} +specialization +specific 0..* 1 {subsets sourceRelationship} {redefines source} +/ownedSpecialization +/owningType 0..* 0..1 {subsets ownedRelationship, {subsets owningRelatedElement, subsets specialization, subsets specific} ordered} Figure 10. Specialization Relationship +conjugation +originalType Conjugation Type 0..* 1 {subsets targetRelationship} {redefines target} +conjugator +conjugatedType 0..1 1 {subsets sourceRelationship} {redefines source} +/ownedConjugator +/owningType 0..1 0..1 {subsets conjugator, subsets {subsets conjugatedType, ownedRelationship} subsets owningRelatedElement} Figure 11. Conjugation Kernel Modeling Language v1.0 135 -Relationship +typeDisjoined +disjoiningTypeDisjoining Type Disjoining 1 0..* {redefines source} {subsets sourceRelationship} +disjoiningType +disjoinedTypeDisjoining 1 0..* {redefines target} {subsets targetRelationship} +/owningType +/ownedDisjoining 0..1 0..* {subsets {subsets disjoiningTypeDisjoining, owningRelatedElement, subsets ownedRelationship} subsets typeDisjoined} Figure 12. Disjoining Relationship +/typeUnioned +/ownedUnioning Unioning +/unionedType Type 1 0..* 0..* {subsets owningRelatedElement, {subsets ownedRelationship, redefines source} subsets sourceRelationship, ordered} +/unioningType +unioningType +unionedUnioning 0..* 1 0..* {ordered} {redefines target} {subsets targetRelationship} Figure 13. Unioning Relationship +/typeIntersected +/ownedIntersecting +/intersectedType Type Intersecting 1 0..* 0..* {subsets owningRelatedElement, {subsets ownedRelationship, redefines source} subsets sourceRelationship, ordered} +/intersectingType +intersectingType +intersectedIntersecting 0..* 1 0..* {ordered} {redefines target} {subsets targetRelationship} Figure 14. Intersecting 136 Kernel Modeling Language v1.0 -Relationship +/typeDifferenced +/ownedDifferencing Type Differencing +/differencedType 1 0..* 0..* {subsets owningRelatedElement, {subsets ownedRelationship, redefines source} subsets sourceRelationship, ordered} +/differencingType +differencingType +differencedDifferencing 0..* {ordered} 1 0..* {redefines target} {subsets targetRelationship} Figure 15. Differencing 8.3.3.1.2 Conjugation Description Conjugation is a Relationship between two types in which the conjugatedType inherits all the Features of the originalType , but with all input and output Features reversed. That is, any Features with a direction in relative to the originalType are considered to have an effective direction of out relative to the conjugatedType and, similarly, Features with direction out in the originalType are considered to have an effective direction of in in the conjugatedType . Features with direction inout, or with no direction , in the originalType , are inherited without change. A Type may participate as a conjugatedType in at most one Conjugation relationship, and such a Type may not also be the specific Type in any Specialization relationship. General Classes Relationship Attributes conjugatedType : Type {redefines source} The Type that is the result of applying Conjugation to the originalType . originalType : Type {redefines target} The Type to be conjugated. /owningType : Type [0..1] {subsets conjugatedType, owningRelatedElement} The conjugatedType of this Conjugation that is also its owningRelatedElement . Operations None. Constraints None. Kernel Modeling Language v1.0 137 -8.3.3.1.3 Differencing Description Differencing is a Relationship that makes its differencingType one of the differencingTypes of its typeDifferenced . General Classes Relationship Attributes differencingType : Type {redefines target} Type that partly determines interpretations of typeDifferenced , as described in Type::differencingType . /typeDifferenced : Type {subsets owningRelatedElement, redefines source} Type with interpretations partly determined by differencingType , as described in Type::differencingType . Operations None. Constraints None. 8.3.3.1.4 Disjoining Description A Disjoining is a Relationship between Types asserted to have interpretations that are not shared (disjoint) between them, identified as typeDisjoined and disjoiningType . For example, a Classifier for mammals is disjoint from a Classifier for minerals, and a Feature for people's parents is disjoint from a Feature for their children. General Classes Relationship Attributes disjoiningType : Type {redefines target} Type asserted to be disjoint with the typeDisjoined . /owningType : Type [0..1] {subsets typeDisjoined, owningRelatedElement} A typeDisjoined that is also an owningRelatedElement . typeDisjoined : Type {redefines source} Type asserted to be disjoint with the disjoiningType . 138 Kernel Modeling Language v1.0 -Operations None. Constraints None. 8.3.3.1.5 FeatureDirectionKind Description FeatureDirectionKind enumerates the possible kinds of direction that a Feature may be given as a member of a Type . General Classes None. Literal Values in Values of the Feature on each instance of its domain are determined externally to that instance and used internally. inout Values of the Feature on each instance are determined either as in or out directions, or both. out Values of the Feature on each instance of its domain are determined internally to that instance and used externally. 8.3.3.1.6 FeatureMembership Description A FeatureMembership is an OwningMembership between an ownedMemberFeature and an owningType . If the ownedMemberFeature has isVariable = false , then the FeatureMembership implies that the owningType is also a featuringType of the ownedMemberFeature . If the ownedMemberFeature has isVariable = true , then the FeatureMembership implies that the ownedMemberFeature is featured by the snapshots of the owningType , which must specialize the Kernel Semantic Library base class Occurrence . General Classes OwningMembership Attributes /ownedMemberFeature : Feature {redefines ownedMemberElement} The Feature that this FeatureMembership relates to its owningType , making it an ownedFeature of the owningType . /owningType : Type {subsets type, redefines membershipOwningNamespace} Kernel Modeling Language v1.0 139 -The Type that owns this FeatureMembership . Operations None. Constraints None. 8.3.3.1.7 Intersecting Description Intersecting is a Relationship that makes its intersectingType one of the intersectingTypes of its typeIntersected . General Classes Relationship Attributes intersectingType : Type {redefines target} Type that partly determines interpretations of typeIntersected , as described in Type::intersectingType . /typeIntersected : Type {subsets owningRelatedElement, redefines source} Type with interpretations partly determined by intersectingType , as described in Type::intersectingType . Operations None. Constraints None. 8.3.3.1.8 Specialization Description Specialization is a Relationship between two Types that requires all instances of the specific type to also be instances of the general Type (i.e., the set of instances of the specific Type is a subset of those of the general Type, which might be the same set). General Classes Relationship Attributes general : Type {redefines target} A Type with a superset of all instances of the specific Type , which might be the same set. 140 Kernel Modeling Language v1.0 -/owningType : Type [0..1] {subsets specific, owningRelatedElement} The Type that is the specific Type of this Specialization and owns it as its owningRelatedElement . specific : Type {redefines source} A Type with a subset of all instances of the general Type , which might be the same set. Operations None. Constraints validateSpecificationSpecificNotConjugated The specific Type of a Specialization cannot be a conjugated Type . not specific.isConjugated 8.3.3.1.9 Multiplicity Description A Multiplicity is a Feature whose co-domain is a set of natural numbers giving the allowed cardinalities of each typeWithMultiplicity . The cardinality of a Type is defined as follows, depending on whether the Type is a Classifier or Feature . • Classifier – The number of basic instances of the Classifier , that is, those instances representing things, which are not instances of any subtypes of the Classifier that are Features . • Features – The number of instances with the same featuring instances. In the case of a Feature with a Classifier as its featuringType , this is the number of values of Feature for each basic instance of the Classifier . Note that, for non-unique Features , all duplicate values are included in this count. Multiplicity co-domains (in models) can be specified by Expression that might vary in their results. If the typeWithMultiplicity is a Classifier , the domain of the Multiplicity shall be Base::Anything . If the typeWithMultiplicity is a Feature , the Multiplicity shall have the same domain as the typeWithMultiplicity . General Classes Feature Attributes None. Operations None. Constraints checkMultiplicitySpecialization Kernel Modeling Language v1.0 141 -A Multiplicity must directly or indirectly specialize the Feature Base::naturals from the Kernel Semantic Library. specializesFromLibrary('Base::naturals') checkMultiplicityTypeFeaturing If the owningType of a Multiplicity is a Feature , then the Multiplicity must have the same featuringTypes as that Feature . Otherwise, it must have no featuringTypes (meaning that it is implicitly featured by the base Classifier Anything ). if owningType <> null and owningType.oclIsKindOf(Feature) then featuringType = owningType.oclAsType(Feature).featuringType else featuringType->isEmpty() endif 8.3.3.1.10 Type Description A Type is a Namespace that is the most general kind of Element supporting the semantics of classification. A Type may be a Classifier or a Feature , defining conditions on what is classified by the Type (see also the description of isSufficient ). General Classes Namespace Attributes /differencingType : Type [0..*] {ordered} The interpretations of a Type with differencingTypes are asserted to be those of the first of those Types , but not including those of the remaining Types . For example, a Classifier might be the difference of a Classifier for people and another for people of a particular nationality, leaving people who are not of that nationality. Similarly, a feature of people might be the difference between a feature for their children and a Classifier for people of a particular sex, identifying their children not of that sex (because the interpretations of the children Feature that identify those of that sex are also interpretations of the Classifier for that sex). /directedFeature : Feature [0..*] {subsets feature, ordered} The features of this Type that have a non-null direction . /endFeature : Feature [0..*] {subsets feature, ordered} All features of this Type with isEnd = true . /feature : Feature [0..*] {subsets member, ordered} The ownedMemberFeatures of the featureMemberships of this Type . /featureMembership : FeatureMembership [0..*] {ordered} 142 Kernel Modeling Language v1.0 -The FeatureMemberships for features of this Type , which include all ownedFeatureMemberships and those inheritedMemberships that are FeatureMemberships (but does not include any importedMemberships ). /inheritedFeature : Feature [0..*] {subsets feature, ordered} All the memberFeatures of the inheritedMemberships of this Type that are FeatureMemberships . /inheritedMembership : Membership [0..*] {subsets membership, ordered} All Memberships inherited by this Type via Specialization or Conjugation . These are included in the derived union for the memberships of the Type . /input : Feature [0..*] {subsets directedFeature, ordered} All features related to this Type by FeatureMemberships that have direction in or inout . /intersectingType : Type [0..*] {ordered} The interpretations of a Type with intersectingTypes are asserted to be those in common among the intersectingTypes , which are the Types derived from the intersectingType of the ownedIntersectings of this Type . For example, a Classifier might be an intersection of Classifiers for people of a particular sex and of a particular nationality. Similarly, a feature for people's children of a particular sex might be the intersection of a Feature for their children and a Classifier for people of that sex (because the interpretations of the children Feature that identify those of that sex are also interpretations of the Classifier for that sex). isAbstract : Boolean Indicates whether instances of this Type must also be instances of at least one of its specialized Types . /isConjugated : Boolean Indicates whether this Type has an ownedConjugator . isSufficient : Boolean Whether all things that meet the classification conditions of this Type must be classified by the Type . (A Type gives conditions that must be met by whatever it classifies, but when isSufficient is false, things may meet those conditions but still not be classified by the Type . For example, a Type Car that is not sufficient could require everything it classifies to have four wheels, but not all four wheeled things would classify as cars. However, if the Type Car were sufficient, it would classify all four-wheeled things.) /multiplicity : Multiplicity [0..1] {subsets ownedMember} An ownedMember of this Type that is a Multiplicity , which constraints the cardinality of the Type . If there is no such ownedMember , then the cardinality of this Type is constrained by all the Multiplicity constraints applicable to any direct supertypes. /output : Feature [0..*] {subsets directedFeature, ordered} All features related to this Type by FeatureMemberships that have direction out or inout . /ownedConjugator : Conjugation [0..1] {subsets ownedRelationship, conjugator} A Conjugation owned by this Type for which the Type is the originalType . Kernel Modeling Language v1.0 143 -/ownedDifferencing : Differencing [0..*] {subsets sourceRelationship, ownedRelationship, ordered} The ownedRelationships of this Type that are Differencings , having this Type as their typeDifferenced . /ownedDisjoining : Disjoining [0..*] {subsets ownedRelationship, disjoiningTypeDisjoining} The ownedRelationships of this Type that are Disjoinings , for which the Type is the typeDisjoined Type . /ownedEndFeature : Feature [0..*] {subsets endFeature, ownedFeature, ordered} All endFeatures of this Type that are ownedFeatures . /ownedFeature : Feature [0..*] {subsets ownedMember, ordered} The ownedMemberFeatures of the ownedFeatureMemberships of this Type . /ownedFeatureMembership : FeatureMembership [0..*] {subsets ownedMembership, featureMembership, ordered} The ownedMemberships of this Type that are FeatureMemberships , for which the Type is the owningType . Each such FeatureMembership identifies an ownedFeature of the Type . /ownedIntersecting : Intersecting [0..*] {subsets ownedRelationship, sourceRelationship, ordered} The ownedRelationships of this Type that are Intersectings , have the Type as their typeIntersected . /ownedSpecialization : Specialization [0..*] {subsets specialization, ownedRelationship, ordered} The ownedRelationships of this Type that are Specializations , for which the Type is the specific Type . /ownedUnioning : Unioning [0..*] {subsets ownedRelationship, sourceRelationship, ordered} The ownedRelationships of this Type that are Unionings , having the Type as their typeUnioned . /unioningType : Type [0..*] {ordered} The interpretations of a Type with unioningTypes are asserted to be the same as those of all the unioningTypes together, which are the Types derived from the unioningType of the ownedUnionings of this Type . For example, a Classifier for people might be the union of Classifiers for all the sexes. Similarly, a feature for people's children might be the union of features dividing them in the same ways as people in general. Operations allRedefinedFeaturesOf(membership : Membership) : Feature [0..*] If the memberElement of the given membership is a Feature , then return all Features directly or indirectly redefined by the memberElement . body: if not membership.memberElement.oclIsType(Feature) then Set{} else membership.memberElement.oclAsType(Feature).allRedefinedFeatures() endif allSupertypes() : Type [0..*] Return this Type and all Types that are directly or transitively supertypes of this Type (as determined by the supertypes operation with excludeImplied = false ). 144 Kernel Modeling Language v1.0 -body: OrderedSet{self}->closure(supertypes(false)) directionOf(feature : Feature) : FeatureDirectionKind [0..1] If the given feature is a feature of this Type , then return its direction relative to this Type , taking conjugation into account. body: directionOfExcluding(f, Set{}) directionOfExcluding(feature : Feature, excluded : Type [0..*]) : FeatureDirectionKind [0..1] Return the direction of the given feature relative to this Type , excluding a given set of Types from the search of supertypes of this Type . body: let excludedSelf : Set(Type) = excluded->including(self) in if feature.owningType = self then feature.direction else let directions : Sequence(FeatureDirectionKind) = supertypes(false)->excluding(excludedSelf). directionOfExcluding(feature, excludedSelf)-> select(d | d <> null) in if directions->isEmpty() then null else let direction : FeatureDirectionKind = directions->first() in if not isConjugated then direction else if direction = FeatureDirectionKind::_'in' then FeatureDirectionKind::out else if direction = FeatureDirectionKind::out then FeatureDirectionKind::_'in' else direction endif endif endif endif endif inheritableMemberships(excludedNamespaces : Namespace [0..*], excludedTypes : Type [0..*], excludeImplied : Boolean) : Membership [0..*] Return all the non- private Memberships of all the supertypes of this Type , excluding any supertypes that are this Type or are in the given set of excludedTypes . If excludeImplied = true , then also transitively exclude any supertypes from implied Specializations . body: let excludingSelf : Set(Type) = excludedType->including(self) in supertypes(excludeImplied)->reject(t | excludingSelf->includes(t)). nonPrivateMemberships(excludedNamespaces, excludingSelf, excludeImplied) inheritedMemberships(excludedNamespaces : Namespace [0..*], excludedTypes : Type [0..*], excludeImplied : Boolean) : Membership [0..*] Return the Memberships inheritable from supertypes of this Type with redefined Features removed. When computing inheritable Memberships , exclude Imports of excludedNamespaces , Specializations of excludedTypes , and, if excludeImplied = true , all implied Specializations . body: removeRedefinedFeatures( inheritableMemberships(excludedNamespaces, excludedTypes, excludeImplied)) isCompatibleWith(otherType : Type) By default, this Type is compatible with an otherType if it directly or indirectly specializes the otherType . body: specializes(otherType) multiplicities() : Multiplicity [0..*] Kernel Modeling Language v1.0 145 -Return the owned or inherited Multiplicities for this Type<./code>. body: if multiplicity <> null then OrderedSet{multiplicity} else ownedSpecialization.general->closure(t | if t.multiplicity <> null then OrderedSet{} else ownedSpecialization.general )->select(multiplicity <> null).multiplicity->asOrderedSet() endif nonPrivateMemberships(excludedNamespaces : Namespace [0..*], excludedTypes : Type [0..*], excludeImplied : Boolean) : Membership [0..*] Return the public , protected and inherited Memberships of this Type . When computing imported Memberships , exclude the given set of excludedNamespaces . When computing inherited Memberships , exclude Types in the given set of excludedTypes . If excludeImplied = true , then also exclude any supertypes from implied Specializations . body: let publicMemberships : OrderedSet(Membership) = membershipsOfVisibility(VisibilityKind::public, excludedNamespaces) in let protectedMemberships : OrderedSet(Membership) = membershipsOfVisibility(VisibilityKind::protected, excludedNamespaces) in let inheritedMemberships : OrderedSet(Membership) = inheritedMemberships(excludedNamespaces, excludedTypes, excludeImplied) in publicMemberships-> union(protectedMemberships)-> union(inheritedMemberships) removeRedefinedFeatures(memberships : Membership [0..*]) : Membership [0..*] Return a subset of memberships , removing those Memberships whose memberElements are Features and for which either of the following two conditions holds: 1. The memberElement of the Membership is included in redefined Features of another Membership in memberships . 2. One of the redefined Features of the Membership is a directly redefinedFeature of an ownedFeature of this Type . For this purpose, the redefined Features of a Membership whose memberElement is a Feature includes the memberElement and all Features directly or indirectly redefined by the memberElement . body: let reducedMemberships : Sequence(Membership) = memberships->reject(mem1 | memberships->excluding(mem1)-> exists(mem2 | allRedefinedFeaturesOf(mem2)-> includes(mem1.memberElement))) in let redefinedFeatures : Set(Feature) = ownedFeature.redefinition.redefinedFeature->asSet() in reducedMemberships->reject(mem | allRedefinedFeaturesOf(mem)-> exists(feature | redefinedFeatures->includes(feature))) specializes(supertype : Type) : Boolean Check whether this Type is a direct or indirect specialization of the given supertype. body: if isConjugated then ownedConjugator.originalType.specializes(supertype) else 146 Kernel Modeling Language v1.0 -allSupertypes()->includes(supertype) endif specializesFromLibrary(libraryTypeName : String) : Boolean Check whether this Type is a direct or indirect specialization of the named library Type . libraryTypeName must conform to the syntax of a KerML qualified name and must resolve to a Type in global scope. body: let mem : Membership = resolveGlobal(libraryTypeName) in mem <> null and mem.memberElement.oclIsKindOf(Type) and specializes(mem.memberElement.oclAsType(Type)) supertypes(excludeImplied : Boolean) : Type [0..*] If this Type is conjugated, then return just the originalType of the Conjugation . Otherwise, return the general Types from all ownedSpecializations of this type, if excludeImplied = false , or all non- implied ownedSpecializations , if excludeImplied = true . body: if isConjugated then Sequence{conjugator.originalType} else if not excludeImplied then ownedSpecialization.general else ownedSpecialization->reject(isImplied).general endif endif visibleMemberships(excluded : Namespace [0..*], isRecursive : Boolean, includeAll : Boolean) : Membership [0..*] {redefines visibleMemberships} The visible Memberships of a Type include inheritedMemberships . body: let visibleMemberships : OrderedSet(Membership) = self.oclAsType(Namespace). visibleMemberships(excluded, isRecursive, includeAll) in let visibleInheritedMemberships : OrderedSet(Membership) = inheritedMemberships(excluded->including(self), Set{}, isRecursive)-> select(includeAll or visibility = VisibilityKind::public) in visibleMemberships->union(visibleInheritedMemberships) Constraints checkTypeSpecialization A Type must directly or indirectly specialize Base::Anything from the Kernel Semantic Library. specializesFromLibrary('Base::Anything') deriveTypeDifferencingType The differencingTypes of a Type are the differencingTypes of its ownedDifferencings , in the same order. differencingType = ownedDifferencing.differencingType deriveTypeDirectedFeature The directedFeatures of a Type are those features for which the direction is non-null. directedFeature = feature->select(f | directionOf(f) <> null) Kernel Modeling Language v1.0 147 -deriveTypeEndFeature The endFeatures of a Type are all its features for which isEnd = true . endFeature = feature->select(isEnd) deriveTypeFeature The features of a Type are the ownedMemberFeatures of its featureMemberships feature = featureMembership.ownedMemberFeature deriveTypeFeatureMembership The featureMemberships of a Type is the union of the ownedFeatureMemberships and those inheritedMemberships that are FeatureMemberships . featureMembership = ownedFeatureMembership->union( inheritedMembership->selectByKind(FeatureMembership)) deriveTypeInheritedFeature The inheritedFeatures of this Type are the memberFeatures of the inheritedMemberships that are FeatureMemberships . inheritedFeature = inheritedMemberships-> selectByKind(FeatureMembership).memberFeature deriveTypeInheritedMembership The inheritedMemberships of a Type are determined by the inheritedMemberships() operation. inheritedMembership = inheritedMemberships(Set{}, Set{}, false) deriveTypeInput The inputs of a Type are those of its features that have a direction of in or inout relative to the Type , taking conjugation into account. input = feature->select(f | let direction: FeatureDirectionKind = directionOf(f) in direction = FeatureDirectionKind::_'in' or direction = FeatureDirectionKind::inout) deriveTypeIntersectingType The intersectingTypes of a Type are the intersectingTypes of its ownedIntersectings . intersectingType = ownedIntersecting.intersectingType deriveTypeMultiplicity If a Type has an owned Multiplicity , then that is its multiplicity . Otherwise, if the Type has an ownedSpecialization , then its multiplicity is the multiplicity of the general Type of that Specialization . 148 Kernel Modeling Language v1.0 -multiplicity = let ownedMultiplicities: Sequence(Multiplicity) = ownedMember->selectByKind(Multiplicity) in if ownedMultiplicities->isEmpty() then null else ownedMultiplicities->first() endif deriveTypeOutput The outputs of a Type are those of its features that have a direction of out or inout relative to the Type , taking conjugation into account. output = feature->select(f | let direction: FeatureDirectionKind = directionOf(f) in direction = FeatureDirectionKind::out or direction = FeatureDirectionKind::inout) deriveTypeOwnedConjugator The ownedConjugator of a Type is the its single ownedRelationship that is a Conjugation . ownedConjugator = let ownedConjugators: Sequence(Conjugator) = ownedRelationship->selectByKind(Conjugation) in if ownedConjugators->isEmpty() then null else ownedConjugators->at(1) endif deriveTypeOwnedDifferencing The ownedDifferencings of a Type are its ownedRelationships that are Differencings . ownedDifferencing = ownedRelationship->selectByKind(Differencing) deriveTypeOwnedDisjoining The ownedDisjoinings of a Type are the ownedRelationships that are Disjoinings . ownedDisjoining = ownedRelationship->selectByKind(Disjoining) deriveTypeOwnedEndFeature The ownedEndFeatures of a Type are all its ownedFeatures for which isEnd = true . ownedEndFeature = ownedFeature->select(isEnd) deriveTypeOwnedFeature The ownedFeatures of a Type are the ownedMemberFeatures of its ownedFeatureMemberships ownedFeature = ownedFeatureMembership.ownedMemberFeature deriveTypeOwnedFeatureMembership The ownedFeatureMemberships of a Type are its ownedMemberships that are FeatureMemberships . ownedFeatureMembership = ownedRelationship->selectByKind(FeatureMembership) Kernel Modeling Language v1.0 149 -deriveTypeOwnedIntersecting The ownedIntersectings of a Type are the ownedRelationships that are Intersectings . ownedRelationship->selectByKind(Intersecting) deriveTypeOwnedSpecialization The ownedSpecializations of a Type are the ownedRelationships that are Specializations whose special Type is the owning Type . ownedSpecialization = ownedRelationship->selectByKind(Specialization)-> select(s | s.special = self) deriveTypeOwnedUnioning The ownedUnionings of a Type are the ownedRelationships that are Unionings . ownedUnioning = ownedRelationship->selectByKind(Unioning) deriveTypeUnioningType The unioningTypes of a Type are the unioningTypes of its ownedUnionings . unioningType = ownedUnioning.unioningType validateTypeAtMostOneConjugator A Type must have at most one owned Conjugation Relationship . ownedRelationship->selectByKind(Conjugation)->size() <= 1 validateTypeDifferencingTypesNotSelf A Type cannot be one of its own differencingTypes . differencingType->excludes(self) validateTypeIntersectingTypesNotSelf A Type cannot be one of its own intersectingTypes . intersectingType->excludes(self) validateTypeOwnedDifferencingNotOne A Type must not have exactly one ownedDifferencing . ownedDifferencing->size() <> 1 validateTypeOwnedIntersectingNotOne A Type must not have exactly one ownedIntersecting . ownedIntersecting->size() <> 1 150 Kernel Modeling Language v1.0 -validateTypeOwnedMultiplicity A Type may have at most one ownedMember that is a Multiplicity . ownedMember->selectByKind(Multiplicity)->size() <= 1 validateTypeOwnedUnioningNotOne A Type must not have exactly one ownedUnioning . ownedUnioning->size() <> 1 validateTypeUnioningTypesNotSelf A Type cannot be one of its own unioningTypes . unioningType->excludes(self) 8.3.3.1.11 Unioning Description Unioning is a Relationship that makes its unioningType one of the unioningTypes of its typeUnioned . General Classes Relationship Attributes /typeUnioned : Type {subsets owningRelatedElement, redefines source} Type with interpretations partly determined by unioningType , as described in Type::unioningType . unioningType : Type {redefines target} Type that partly determines interpretations of typeUnioned , as described in Type::unioningType . Operations None. Constraints None. Kernel Modeling Language v1.0 151 -8.3.3.2 Classifiers Abstract Syntax 8.3.3.2.1 Overview Specialization Type +superclassification +superclassifier Subclassification Classifier 0..* 1 {redefines general} {subsets generalization} +subclassification +subclassifier 0..* 1 {subsets specialization} {redefines specific} +/ownedSubclassification +/owningClassifier 0..* 0..1 {subsets ownedSpecialization} {redefines owningType} Figure 16. Classifiers 8.3.3.2.2 Classifier Description A Classifier is a Type that classifies: • Things (in the universe) regardless of how Features relate them. (These are interpreted semantically as sequences of exactly one thing.) • How the above things are related by Features. (These are interpreted semantically as sequences of multiple things, such that the last thing in the sequence is also classified by the Classifier . Note that this means that a Classifier modeled as specializing a Feature cannot classify anything.) General Classes Type Attributes /ownedSubclassification : Subclassification [0..*] {subsets ownedSpecialization} The ownedSpecializations of this Classifier that are Subclassifications , for which this Classifier is the subclassifier . Operations None. Constraints deriveClassifierOwnedSubclassification 152 Kernel Modeling Language v1.0 -The ownedSubclassifications of a Classifier are its ownedSpecializations that are Subclassifications . ownedSubclassification = ownedSpecialization->selectByKind(Subclassification) validateClassifierMultiplicityDomain If a Classifier has a multiplicity , then the multiplicity must have no featuringTypes (meaning that its domain is implicitly Base::Anything). multiplicity <> null implies multiplicity.featuringType->isEmpty() 8.3.3.2.3 Subclassification Description Subclassification is Specialization in which both the specific and general Types are Classifier . This means all instances of the specific Classifier are also instances of the general Classifier . General Classes Specialization Attributes /owningClassifier : Classifier [0..1] {redefines owningType} The Classifier that owns this Subclassification relationship, which must also be its subclassifier . subclassifier : Classifier {redefines specific} The more specific Classifier in this Subclassification . superclassifier : Classifier {redefines general} The more general Classifier in this Subclassification . Operations None. Constraints None. Kernel Modeling Language v1.0 153 -8.3.3.3 Features Abstract Syntax 8.3.3.3.1 Overview {redefines target} {redefines general} +type +featuringType Relationship Type Specialization 1 1 0..* +/type +/featuringType 0..* {ordered} {ordered} {subsets targetRelationship} 0..* +/typedFeature {subsets generalization} +/featureOfType 0..* +typeFeaturingOfType +typingByType TypeFeaturing Feature FeatureTyping 0..* 0..* +isUnique : Boolean = true +typeFeaturing +featureOfType +typedFeature typing +isOrdered : Boolean = false +isComposite : Boolean = false 0..* 1 1 0..* +isEnd : Boolean = false {subsets sourceRelationship} {redefines source} {redefines specific} {subsets specialization} +isDerived : Boolean = false +isPortion : Boolean = false +/owningFeature +/ownedTyping +/ownedTypeFeaturing +/owningFeatureOfType +isVariable : Boolean = false +isConstant : Boolean = false 0..1 0..* 0..* 0..1 +direction : FeatureDirectionKind [0..1] {subsets ownedSpecialization, {subsets typedFeature, {subsets ownedRelationship, {subsets featureOfType, subsets typing, ordered} redefines owningType} subsets typeFeaturing, subsets owningRelatedElement} +directionFor( type : Type ) : FeatureDirectionKind [0..1] ordered} +effectiveShortName() : String [0..1]{redefines effectiveShortName} +effectiveName() : String [0..1]{redefines effectiveName} +namingFeature() : Feature [0..1] +supertypes( excludeImplied : Boolean ) : Type [0..*]{redefines supertypes} +redefines( redefinedFeature : Feature ) : Boolean +redefinesFromLibrary( libraryFeatureName : String ) : Boolean +subsetsChain( first : Feature, second : Feature ) : Boolean +isCompatibleWith( otherType : Type ){redefines isCompatibleWith} +typingFeatures() : Feature [0..*] +asCartesianProduct() : Type [0..*] +isCartesianProduct() : Boolean +isOwnedCrossFeature() : Boolean +ownedCrossFeature() : Feature [0..1] +allRedefinedFeatures() : Feature [0..*] +isFeaturedWithin( type : Type [0..1] ) : Boolean +canAccess( feature : Feature ) : Boolean +isFeaturingType( type : Type ) : Boolean «enumeration» FeatureDirectionKind in inout out Figure 17. Features 154 Kernel Modeling Language v1.0 -Specialization +subsettedFeature +supersetting Subsetting Feature 0..* 1 {subsets generalization} {redefines general} +subsetting +subsettingFeature 0..* 1 {subsets specialization} {redefines specific} +/ownedSubsetting +/owningFeature 0..* 0..1 {subsets ownedSpecialization, {subsets subsettingFeature, subsets subsetting} redefines owningType} +redefining +redefinedFeature Redefinition 0..* 1 {subsets supersetting} {redefines subsettedFeature} +redefinition +redefiningFeature 0..* 1 {subsets subsetting} {redefines subsettingFeature} +/ownedRedefinition +/owningFeature 0..* 0..1 {subsets ownedSubsetting} {subsets owningFeature} ReferenceSubsetting +referencing +referencedFeature 0..* 1 {subsets supersetting} {redefines subsettedFeature} +/ownedReferenceSubsetting +/referencingFeature 0..1 1 {subsets ownedSubsetting} {redefines owningFeature, redefines subsettingFeature} Figure 18. Subsetting Relationship +/featureTarget 1 +/baseFeature 0..* +/chainedFeature +/featureChained +/ownedFeatureChaining Feature FeatureChaining 0..* 1 0..* {subsets {subsets ownedRelationship, owningRelatedElement, subsets sourceRelationship, redefines source} ordered} +/chainingFeature +chainingFeature +chainedFeatureChaining 0..* 1 0..* {ordered, {redefines target} {subsets targetRelationship} nonunique} Figure 19. Feature Chaining Kernel Modeling Language v1.0 155 -Relationship +invertingFeatureInverting +featureInverted Feature FeatureInverting 1 0..* {redefines source} {subsets sourceRelationship} +invertedFeatureInverting +invertingFeature 1 0..* {redefines target} {subsets targetRelationship} +/owningFeature +/ownedFeatureInverting 0..1 0..* {subsets featureInverted, {subsets invertingFeatureInverting, subsets owningRelatedElement} subsets ownedRelationship} Figure 20. Feature Inverting FeatureMembership EndFeatureMembership +/owningEndFeatureMembership 0..1 {subsets owningFeatureMembership} {redefines ownedMemberFeature} +/ownedMemberFeature 1 Feature Figure 21. End Feature Membership Subsetting +crossSupersetting +crossedFeature +/crossFeature CrossSubsetting Feature 0..1 1 0..1 {subsets supersetting} {redefines subsettedFeature} +/ownedCrossSubsetting +/crossingFeature +/featureCrossing 0..1 1 0..* {subsets ownedSubsetting} {redefines owningFeature, redefines subsettingFeature} Figure 22. Cross Subsetting 156 Kernel Modeling Language v1.0 -8.3.3.3.2 CrossSubsetting Description CrossSubsetting is a kind of Subsetting for end Features , as identified by crossingFeature , to subset a chained Feature , identified by crossedFeature. It navigates to instances of the end Feature ’s type from instances of other end Feature types on the same owningType (at least two end Features are required for any of them to have a CrossSubsetting ). The crossedFeature of a CrossSubsetting must have a feature chain of exactly two Features . The second Feature in the chain is the crossFeature of the crossingFeature (end Feature ), which has the same type as the crossingFeature . When the owningType of the crossingFeature has exactly two end Features , the first Feature in the chain of the crossedFeature is the other end Feature . The crossFeature ’s featuringType in this case is the other end Feature . When the owningType has more than two end Features , the first Feature in the chain is a Feature that CrossMultiplies all the other end Features , which is also the featuringType of the crossFeature . A crossFeature must be owned by its featureCrossing (end Feature ) when the featureCrossing owningType has more than two end Features . Otherwise, for exactly two end Features , the crossFeatures of each the ends can instead optionally be inherited by the other end from one of its types or a subsetted Feature . General Classes Subsetting Attributes crossedFeature : Feature {redefines subsettedFeature} The chained Feature that is cross subset by the crossingFeature of this CrossSubsetting . /crossingFeature : Feature {redefines owningFeature, subsettingFeature} The end Feature that owns this CrossSubsetting relationship and is also its subsettingFeature. Operations None. Constraints validateCrossSubsettingCrossedFeature The crossedFeature of a CrossSubsetting must have exactly two chainingFeatures . If the crossingFeature of the CrossSubsetting is one of two end Features , then the first chainingFeature must be the other end Feature . crossingFeature.isEnd and crossingFeature.owningType <> null implies let endFeatures: Sequence(Feature) = crossingFeature.owningType.endFeature in let chainingFeatures: Sequence(Feature) = crossedFeature.chainingFeature in chainingFeatures->size() = 2 and endFeatures->size() = 2 implies chainingFeatures->at(1) = endFeatures->excluding(crossingFeature)->at(1) validateCrossSubsettingCrossingFeature Kernel Modeling Language v1.0 157 -The crossingFeature of a CrossSubsetting must be an end Feature that is owned by a Type with at least two end Features . crossingFeature.isEnd and crossingFeature.owningType<>null and crossingFeature.owningType.endFeature ->size() > 1 8.3.3.3.3 EndFeatureMembership Description EndFeatureMembership is a FeatureMembership that requires its memberFeature be owned and have isEnd = true . General Classes FeatureMembership Attributes /ownedMemberFeature : Feature {redefines ownedMemberFeature} Operations None. Constraints validateEndFeatureMembershipIsEnd The ownedMemberFeature of an EndFeatureMembership must be an end Feature . ownedMemberFeature.isEnd 8.3.3.3.4 Feature Description A Feature is a Type that classifies relations between multiple things (in the universe). The domain of the relation is the intersection of the featuringTypes of the Feature . (The domain of a Feature with no featuringTyps is implicitly the most general Type Base::Anything from the Kernel Semantic Library.) The co-domain of the relation is the intersection of the types of the Feature . In the simplest cases, the featuringTypes and types are Classifiers and the Feature relates two things, one from the domain and one from the range. Examples include cars paired with wheels, people paired with other people, and cars paired with numbers representing the car length. Since Features are Types , their featuringTypes and types can be Features . In this case, the Feature effectively classifies relations between relations, which can be interpreted as the sequence of things related by the domain Feature concatenated with the sequence of things related by the co-domain Feature . The values of a Feature for a given instance of its domain are all the instances of its co-domain that are related to that domain instance by the Feature . The values of a Feature with chainingFeatures are the same as values of the last Feature in the chain, which can be found by starting with values of the first Feature , then using those values as domain instances to obtain valus of the second Feature , and so on, to values of the last Feature . 158 Kernel Modeling Language v1.0 -General Classes Type Attributes /chainingFeature : Feature [0..*] {ordered, nonunique} The Feature that are chained together to determine the values of this Feature , derived from the chainingFeatures of the ownedFeatureChainings of this Feature , in the same order. The values of a Feature with chainingFeatures are the same as values of the last Feature in the chain, which can be found by starting with the values of the first Feature (for each instance of the domain of the original Feature ), then using each of those as domain instances to find the values of the second Feature in chainingFeatures, and so on, to values of the last Feature . /crossFeature : Feature [0..1] The second chainingFeature of the crossedFeature of the ownedCrossSubsetting of this Feature , if it has one. Semantically, the values of the crossFeature of an end Feature must include all values of the end Feature obtained when navigating from values of the other end Features of the same owningType . direction : FeatureDirectionKind [0..1] Indicates how values of this Feature are determined or used (as specified for the FeatureDirectionKind ). /endOwningType : Type [0..1] {subsets typeWithEndFeature, owningType} The Type that is related to this Feature by an EndFeatureMembership in which the Feature is an ownedMemberFeature . /featureTarget : Feature The last of the chainingFeatures of this Feature , if it has any. Otherwise, this Feature itself. /featuringType : Type [0..*] {ordered} Types that feature this Feature , such that any instance in the domain of the Feature must be classified by all of these Types , including at least all the featuringTypes of its typeFeaturings . If the Feature is chained, then the featuringTypes of the first Feature in the chain are also featuringTypes of the chained Feature . isComposite : Boolean Whether the Feature is a composite feature of its featuringType . If so, the values of the Feature cannot exist after its featuring instance no longer does and cannot be values of another composite feature that is not on the same featuring instance. isConstant : Boolean If isVariable is true, then whether the value of this Feature nevertheless does not change over all snapshots of its owningType . isDerived : Boolean Whether the values of this Feature can always be computed from the values of other Features . isEnd : Boolean Kernel Modeling Language v1.0 159 -Whether or not this Feature is an end Feature . An end Feature always has multiplicity 1, mapping each of its domain instances to a single co-domain instance. However, it may have a crossFeature , in which case values of the crossFeature must be the same as those found by navigation across instances of the owningType from values of other end Features to values of this Feature. If the owningType has n end Features , then the multiplicity, ordering, and uniqueness declared for the crossFeature of any one of these end Features constrains the cardinality, ordering, and uniqueness of the collection of values of that Feature reached by navigation when the values of the other n-1 end Features are held fixed. isOrdered : Boolean Whether an order exists for the values of this Feature or not. isPortion : Boolean Whether the values of this Feature are contained in the space and time of instances of the domain of the Feature and represent the same thing as those instances. isUnique : Boolean Whether or not values for this Feature must have no duplicates or not. isVariable : Boolean Whether the value of this Feature might vary over time. That is, whether the Feature may have a different value for each snapshot of an owningType that is an Occurrence . /ownedCrossSubsetting : CrossSubsetting [0..1] {subsets ownedSubsetting} The one ownedSubsetting of this Feature , if any, that is a CrossSubsetting}, for which the Feature is the crossingFeature. /ownedFeatureChaining : FeatureChaining [0..*] {subsets sourceRelationship, ownedRelationship, ordered} The ownedRelationships of this Feature that are FeatureChainings , for which the Feature will be the featureChained . /ownedFeatureInverting : FeatureInverting [0..*] {subsets ownedRelationship, invertingFeatureInverting} The ownedRelationships of this Feature that are FeatureInvertings and for which the Feature is the featureInverted . /ownedRedefinition : Redefinition [0..*] {subsets ownedSubsetting} The ownedSubsettings of this Feature that are Redefinitions , for which the Feature is the redefiningFeature . /ownedReferenceSubsetting : ReferenceSubsetting [0..1] {subsets ownedSubsetting} The one ownedSubsetting of this Feature , if any, that is a ReferenceSubsetting , for which the Feature is the referencingFeature . /ownedSubsetting : Subsetting [0..*] {subsets ownedSpecialization, subsetting} The ownedSpecializations of this Feature that are Subsettings , for which the Feature is the subsettingFeature . 160 Kernel Modeling Language v1.0 -/ownedTypeFeaturing : TypeFeaturing [0..*] {subsets ownedRelationship, typeFeaturing, ordered} The ownedRelationships of this Feature that are TypeFeaturings and for which the Feature is the featureOfType . /ownedTyping : FeatureTyping [0..*] {subsets ownedSpecialization, typing, ordered} The ownedSpecializations of this Feature that are FeatureTypings , for which the Feature is the typedFeature . /owningFeatureMembership : FeatureMembership [0..1] {subsets owningMembership} The FeatureMembership that owns this Feature as an ownedMemberFeature , determining its owningType . /owningType : Type [0..1] {subsets typeWithFeature, owningNamespace, featuringType} The Type that is the owningType of the owningFeatureMembership of this Feature . /type : Type [0..*] {ordered} Types that restrict the values of this Feature , such that the values must be instances of all the types . The types of a Feature are derived from its typings and the types of its subsettings . If the Feature is chained, then the types of the last Feature in the chain are also types of the chained Feature . Operations allRedefinedFeatures() : Feature [0..*] Return this Feature and all the Features that are directly or indirectly Redefined by this Feature . body: ownedRedefinition.redefinedFeature-> closure(ownedRedefinition.redefinedFeature)-> asOrderedSet()->prepend(self) asCartesianProduct() : Type [0..*] If isCartesianProduct is true, then return the list of Types whose Cartesian product can be represented by this Feature . (If isCartesianProduct is not true, the operation will still return a valid value, it will just not represent anything useful.) body: featuringType->select(t | t.owner <> self)-> union(featuringType->select(t | t.owner = self)-> selectByKind(Feature).asCartesianProduct())-> union(type) canAccess(feature : Feature) : Boolean A Feature can access another feature if the other feature is featured within one of the direct or indirect featuringTypes of this Feature . body: let anythingType: Element = subsettingFeature.resolveGlobal('Base::Anything').memberElement in let allFeaturingTypes : Sequence(Type) = featuringTypes->closure(t | if not t.oclIsKindOf(Feature) then Sequence{} else let featuringTypes : OrderedSet(Type) = t.oclAsType(Feature).featuringType in if featuringTypes->isEmpty() then Sequence{anythingType} Kernel Modeling Language v1.0 161 -else featuringTypes endif endif) in allFeaturingTypes->exists(t | feature.isFeaturedWithin(t)) directionFor(type : Type) : FeatureDirectionKind [0..1] Return the directionOf this Feature relative to the given type . body: type.directionOf(self) effectiveName() : String [0..1] {redefines effectiveName} If a Feature has no declaredName or declaredShortName , then its effective name is given by the effective name of the Feature returned by the namingFeature() operation, if any. body: if declaredShortName <> null or declaredName <> null then declaredName else let namingFeature : Feature = namingFeature() in if namingFeature = null then null else namingFeature.effectiveName() endif endif effectiveShortName() : String [0..1] {redefines effectiveShortName} If a Feature has no declaredShortName or declaredName , then its effective shortName is given by the effective shortName of the Feature returned by the namingFeature() operation, if any. body: if declaredShortName <> null or declaredName <> null then declaredShortName else let namingFeature : Feature = namingFeature() in if namingFeature = null then null else namingFeature.effectiveShortName() endif endif isCartesianProduct() : Boolean Check whether this Feature can be used to represent a Cartesian product of Types . body: type->size() = 1 and featuringType.size() = 1 and (featuringType.first().owner = self implies featuringType.first().oclIsKindOf(Feature) and featuringType.first().oclAsType(Feature).isCartesianProduct()) isCompatibleWith(otherType : Type) {redefines isCompatibleWith} A Feature is compatible with an otherType if it either directly or indirectly specializes the otherType or if the otherType is also a Feature and all of the following are true. 1. Neither this Feature or the otherType have any ownedFeatures . 162 Kernel Modeling Language v1.0 -2. This Feature directly or indirectly redefines a Feature that is also directly or indirectly redefined by the otherType . 3. This Feature can access the otherType . body: specializes(otherType) or supertype.oclIsKindOf(Feature) and ownedFeature->isEmpty() and otherType.ownedFeature->isEmpty() and ownedRedefinitions.allRedefinedFeatures()->exists(f | otherType.oclAsType(Feature).allRedefinedFeatures()->includes(f)) and canAccess(otherType.oclAsType(Feature)) isFeaturedWithin(type : Type [0..1]) : Boolean Return if the featuringTypes of this Feature are compatible with the given type . If type is null, then check if this Feature is explicitly or implicitly featured by Base::Anything . If this Feature has isVariable = true , then also consider it to be featured within its owningType . If this Feature is a feature chain whose first chainingFeature has isVariable = true , then also consider it to be featured within the owningType of its first chainingFeature . body: if type = null then featuringType->forAll(f | f = resolveGlobal('Base::Anything').memberElement) else featuringType->forAll(f | type.isCompatibleWith(f)) or isVariable and type.specializes(owningType) or chainingFeature->notEmpty() and chainingFeature->first().isVariable and type.specializes(chainingFeature->first().owningType) endif isFeaturingType(type : Type) : Boolean Return whether the given type must be a featuringType of this Feature . If this Feature has isVariable = false , then return true if the type is the owningType of the Feature . If isVariable = true , then return true if the type is a Feature representing the snapshots of the owningType of this Feature . body: owningType <> null and if not isVariable then type = owningType else if owningType = resolveGlobal('Occurrences::Occurrence').memberElement then type = resolveGlobal('Occurrences::Occurrence::snapshots').memberElement else type.oclIsKindOf(Feature) and let feature : Feature = type.oclAsType(Feature) in feature.featuringType->includes(owningType) and feature.redefinesFromLibrary('Occurrences::Occurrence::snapshots') endif isOwnedCrossFeature() : Boolean Return whether this Feature is an owned cross Feature of an end Feature . body: owningNamespace <> null and owningNamespace.oclIsKindOf(Feature) and owningNamespace.oclAsType(Feature).ownedCrossFeature() = self namingFeature() : Feature [0..1] By default, the naming Feature of a Feature is given by its first redefinedFeature of its first ownedRedefinition , if any. Kernel Modeling Language v1.0 163 -body: if ownedRedefinition->isEmpty() then null else ownedRedefinition->at(1).redefinedFeature endif ownedCrossFeature() : Feature [0..1] If this Feature is an end Feature of its owningType , then return the first ownedMember of the Feature that is a Feature , but not a Multiplicity or a MetadataFeature , and whose owningMembership is not a FeatureMembership . If this exists, it is the crossFeature of the end Feature . body: if not isEnd or owningType = null then null else let ownedMemberFeatures: Sequence(Feature) = ownedMember->selectByKind(Feature)-> reject(oclIsKindOf(Multiplicity) or oclIsKindOf(MetadataFeature) or oclIsKindOf(FeatureValue))-> reject(owningMembership.oclIsKindOf(FeatureMembership)) in if ownedMemberFeatures.isEmpty() then null else ownedMemberFeatures->first() endif redefines(redefinedFeature : Feature) : Boolean Check whether this Feature directly redefines the given redefinedFeature . body: ownedRedefinition.redefinedFeature->includes(redefinedFeature) redefinesFromLibrary(libraryFeatureName : String) : Boolean Check whether this Feature directly redefines the named library Feature . libraryFeatureName must conform to the syntax of a KerML qualified name and must resolve to a Feature in global scope. body: let mem: Membership = resolveGlobal(libraryFeatureName) in mem <> null and mem.memberElement.oclIsKindOf(Feature) and redefines(mem.memberElement.oclAsType(Feature)) subsetsChain(first : Feature, second : Feature) : Boolean Check whether this Feature directly or indirectly specializes a Feature whose last two chainingFeatures are the given Features first and second . body: allSuperTypes()->selectAsKind(Feature)-> exists(f | let n: Integer = f.chainingFeature->size() in n >= 2 and f.chainingFeature->at(n-1) = first and f.chainingFeature->at(n) = second) supertypes(excludeImplied : Boolean) : Type [0..*] {redefines supertypes} body: let supertypes : OrderedSet(Type) = self.oclAsType(Type).supertypes(excludeImplied) in if featureTarget = self then supertypes else supertypes->append(featureTarget) endif typingFeatures() : Feature [0..*] 164 Kernel Modeling Language v1.0 -Return the Features used to determine the types of this Feature (other than this Feature itself). If this Feature is not conjugated, then the typingFeatures consist of all subsetted Features , except from CrossSubsetting , and the last chainingFeature (if any). If this Feature is conjugated, then the typingFeatures are only its originalType (if the originalType is a Feature ). Note. CrossSubsetting is excluded from the determination of the type of a Feature in order to avoid circularity in the construction of implied CrossSubsetting relationships. The validateFeatureCrossFeatureType requires that the crossFeature of a Feature have the same type as the Feature . body: if not isConjugated then let subsettedFeatures : OrderedSet(Feature) = subsetting->reject(s | s.oclIsKindOf(CrossSubsetting)).subsettedFeatures in if chainingFeature->isEmpty() or subsettedFeature->includes(chainingFeature->last()) then subsettedFeatures else subsettedFeatures->append(chainingFeature->last()) endif else if conjugator.originalType.oclIsKindOf(Feature) then OrderedSet{conjugator.originalType.oclAsType(Feature)} else OrderedSet{} endif endif Constraints checkFeatureCrossingSpecialization If this Feature has isEnd = true and ownedCrossFeature returns a non-null value, then the crossFeature of the Feature must be the Feature returned from ownedCrossFeature (which implies that this Feature has an appropriate ownedCrossSubsetting to realize this). ownedCrossFeature() <> null implies crossFeature = ownedCrossFeature() checkFeatureDataValueSpecialization If a Feature has an ownedTyping relationship to a DataType , then it must directly or indirectly specialize Base::dataValues from the Kernel Semantic Library. ownedTyping.type->exists(selectByKind(DataType)) implies specializesFromLibrary('Base::dataValues') checkFeatureEndRedefinition If a Feature has isEnd = true and an owningType that is not empty, then, for each direct supertype of its owningType , it must redefine the endFeature at the same position, if any. isEnd and owningType <> null implies let i : Integer = owningType.ownedEndFeature->indexOf(self) in owningType.ownedSpecialization.general-> forAll(supertype | supertype.endFeature->size() >= i implies redefines(supertype.endFeature->at(i)) checkFeatureEndSpecialization Kernel Modeling Language v1.0 165 -If a Feature has isEnd = true and an owningType that is an Association or a Connector , then it must directly or indirectly specialize Links::Link::participant from the Kernel Semantic Library. isEnd and owningType <> null and (owningType.oclIsKindOf(Association) or owningType.oclIsKindOf(Connector)) implies specializesFromLibrary('Links::Link::participant') checkFeatureFeatureMembershipTypeFeaturing If a Feature is owned via a FeatureMembership , then it must have a featuringType for which the operation isFeaturingType returns true. owningFeatureMembership <> null implies featuringTypes->exists(t | isFeaturingType(t)) checkFeatureFlowFeatureRedefinition If a Feature is the first ownedFeature of a first or second FlowEnd , then it must directly or indirectly specialize either Transfers::Transfer::source::sourceOutput or Transfers::Transfer::target::targetInput , respectively, from the Kernel Semantic Library. owningType <> null and owningType.oclIsKindOf(FlowEnd) and owningType.ownedFeature->at(1) = self implies let flowType : Type = owningType.owningType in flowType <> null implies let i : Integer = flowType.ownedFeature.indexOf(owningType) in (i = 1 implies redefinesFromLibrary('Transfers::Transfer::source::sourceOutput')) and (i = 2 implies redefinesFromLibrary('Transfers::Transfer::source::targetInput')) checkFeatureObjectSpecialization If a Feature has an ownedTyping relationship to a Structure , then it must directly or indirectly specialize Objects::objects from the Kernel Semantics Library. ownedTyping.type->exists(selectByKind(Structure)) implies specializesFromLibary('Objects::objects') checkFeatureOccurrenceSpecialization If a Feature has an ownedTyping relationship to a Class , then it must directly or indirectly specialize Occurrences::occurrences from the Kernel Semantic Library. ownedTyping.type->exists(selectByKind(Class)) implies specializesFromLibrary('Occurrences::occurrences') checkFeatureOwnedCrossFeatureRedefinitionSpecialization If this Feature is the ownedCrossFeature of an end Feature , then, for any end Feature that is redefined by the owning end Feature of this Feature , this Feature must subset the crossFeature of the redefined end Feature , if this exists. isOwnedCrossFeature() implies ownedSubsetting.subsettedFeature->includesAll( 166 Kernel Modeling Language v1.0 -owner.oclAsType(Feature).ownedRedefinition.redefinedFeature-> select(crossFeature <> null).crossFeature) checkFeatureOwnedCrossFeatureSpecialization If this Feature is the ownedCrossFeature of an end Feature , then it must directly or indirectly specialize the types of its owning end Feature . isOwnedCrossFeature() implies owner.oclAsType(Feature).type->forAll(t | self.specializes(t)) checkFeatureOwnedCrossFeatureTypeFeaturing If this Feature is the ownedCrossFeature of an end Feature , then it must have featuringTypes consistent with the crossing from other end Features of the owningType of its end Feature . isOwnedCrossFeature() implies let otherEnds : OrderedSet(Feature) = owner.oclAsType(Feature).owningType.endFeature->excluding(self) in if (otherEnds->size() = 1) then featuringType = otherEnds->first().type else featuringType->size() = 1 and featuringType->first().isCartesianProduct() and featuringType->first().asCartesianProduct() = otherEnds.type and featuringType->first().allSupertypes()->includesAll( owner.oclAsType(Feature).ownedRedefinition.redefinedFeature-> select(crossFeature() <> null).crossFeature().featuringType) endif checkFeatureParameterRedefinition If a Feature is a parameter of an owningType that is a Behavior or Step , but not • A result parameter • A parameter of an InvocationExpression , with at least one non-implied ownedRedefinition then, for each direct supertype of its owningType that is also a Behavior or Step , it must redefine the parameter at the same position, if any. owningType <> null and not owningFeatureMembership. oclIsKindOf(ReturnParameterMembership) and (owningType.oclIsKindOf(Behavior) or owningType.oclIsKindOf(Step) and (owningType.oclIsKindOf(InvocationExpression) implies not ownedRedefinition->exists(not isImplied)) implies let i : Integer = owningType.ownedFeature->select(direction <> null)-> reject(owningFeatureMembership. oclIsKindOf(ReturnParameterMembership))-> indexOf(self) in owningType.ownedSpecialization.general-> forAll(supertype | let ownedParameters : Sequence(Feature) = supertype.ownedFeature->select(direction <> null)-> reject(owningFeatureMembership. oclIsKindOf(ReturnParameterMembership)) in Kernel Modeling Language v1.0 167 -ownedParameters->size() >= i implies redefines(ownedParameters->at(i)) checkFeaturePortionSpecialization If a Feature has isPortion = true , an ownedTyping relationship to a Class , and an owningType that is a Class or another Feature typed by a Class , then it must directly or indirectly specialize Occurrences::Occurrence::portions from the Kernel Semantic Library. isPortion and ownedTyping.type->includes(oclIsKindOf(Class)) and owningType <> null and (owningType.oclIsKindOf(Class) or owningType.oclIsKindOf(Feature) and owningType.oclAsType(Feature).type-> exists(oclIsKindOf(Class))) implies specializesFromLibrary('Occurrence::Occurrence::portions') checkFeatureResultRedefinition If a Feature is a result parameter of an owningType that is a Function or Expression , then, for each direct supertype of its owningType that is also a Function or Expression , it must redefine the result parameter . owningType <> null and (owningType.oclIsKindOf(Function) and self = owningType.oclAsType(Function).result or owningType.oclIsKindOf(Expression) and self = owningType.oclAsType(Expression).result) implies owningType.ownedSpecialization.general-> select(oclIsKindOf(Function) or oclIsKindOf(Expression))-> forAll(supertype | redefines( if superType.oclIsKindOf(Function) then superType.oclAsType(Function).result else superType.oclAsType(Expression).result endif) checkFeatureSpecialization A Feature must directly or indirectly specialize Base::things from the Kernel Semantic Library. specializesFromLibrary('Base::things') checkFeatureSubobjectSpecialization A composite Feature typed by a Structure , and whose ownedType is a Structure or another Feature typed by a Structure must directly or indirectly specialize Objects::Object::subobjects isComposite and ownedTyping.type->includes(oclIsKindOf(Structure)) and owningType <> null and (owningType.oclIsKindOf(Structure) or owningType.type->includes(oclIsKindOf(Structure))) implies specializesFromLibrary('Occurrence::Occurrence::suboccurrences') checkFeatureSuboccurrenceSpecialization 168 Kernel Modeling Language v1.0 -A composite Feature that has an ownedTyping relationship to a Class , and whose ownedType is a Class or another Feature typed by a Class , must directly or indirectly specialize Occurrences::Occurrence::suboccurrences isComposite and ownedTyping.type->includes(oclIsKindOf(Class)) and owningType <> null and (owningType.oclIsKindOf(Class) or owningType.oclIsKindOf(Feature) and owningType.oclAsType(Feature).type-> exists(oclIsKindOf(Class))) implies specializesFromLibrary('Occurrence::Occurrence::suboccurrences') checkFeatureValuationSpecialization If a Feature has a FeatureValue , no ownedSpecializations that are not implied, and is not directed, then it must specialize the result of the value Expression of the FeatureValue . direction = null and ownedSpecializations->forAll(isImplied) implies ownedMembership-> selectByKind(FeatureValue)-> forAll(fv | specializes(fv.value.result)) deriveFeatureChainingFeature The chainingFeatures of a Feature are the chainingFeatures of its ownedFeatureChainings . chainingFeature = ownedFeatureChaining.chainingFeature deriveFeatureCrossFeature The crossFeature of a Feature is the second chainingFeature of the crossedFeature of the ownedCrossSubsetting of the Feature , if any. crossFeature = if ownedCrossSubsetting = null then null else let chainingFeatures: Sequence(Feature) = ownedCrossSubsetting.crossedFeature.chainingFeature in if chainingFeatures->size() < 2 then null else chainingFeatures->at(2) endif deriveFeatureFeatureTarget If a Feature has no chainingFeatures , then its featureTarget is the Feature itself, otherwise the featureTarget is the last of the chainingFeatures . featureTarget = if chainingFeature->isEmpty() then self else chainingFeature->last() endif deriveFeatureFeaturingType The featuringTypes of a Feature include the featuringTypes of all the typeFeaturings of the Feature . If the Feature has chainingFeatures , then its featuringTypes also include the featuringTypes of the first chainingFeature . featuringType = let featuringTypes : OrderedSet(Type) = Kernel Modeling Language v1.0 169 -featuring.type->asOrderedSet() in if chainingFeature->isEmpty() then featuringTypes else featuringTypes-> union(chainingFeature->first().featuringType)-> asOrderedSet() endif deriveFeatureOwnedCrossSubsetting The ownedCrossSubsetting of a Feature is the ownedSubsetting that is a CrossSubsetting , if any. ownedCrossSubsetting = let crossSubsettings: Sequence(CrossSubsetting) = ownedSubsetting->selectByKind(CrossSubsetting) in if crossSubsettings->isEmpty() then null else crossSubsettings->first() endif deriveFeatureOwnedFeatureChaining The ownedFeatureChainings of a Feature are the ownedRelationships that are FeatureChainings . ownedFeatureChaining = ownedRelationship->selectByKind(FeatureChaining) deriveFeatureOwnedFeatureInverting The ownedFeatureInvertings of a Feature are its ownedRelationships that are FeatureInvertings . ownedFeatureInverting = ownedRelationship->selectByKind(FeatureInverting)-> select(fi | fi.featureInverted = self) deriveFeatureOwnedRedefinition The ownedRedefinitions of a Feature are its ownedSubsettings that are Redefinitions . ownedRedefinition = ownedSubsetting->selectByKind(Redefinition) deriveFeatureOwnedReferenceSubsetting The ownedReferenceSubsetting of a Feature is the first ownedSubsetting that is a ReferenceSubsetting (if any). ownedReferenceSubsetting = let referenceSubsettings : OrderedSet(ReferenceSubsetting) = ownedSubsetting->selectByKind(ReferenceSubsetting) in if referenceSubsettings->isEmpty() then null else referenceSubsettings->first() endif deriveFeatureOwnedSubsetting The ownedSubsettings of a Feature are its ownedSpecializations that are Subsettings . ownedSubsetting = ownedSpecialization->selectByKind(Subsetting) deriveFeatureOwnedTypeFeaturing The ownedTypeFeaturings of a Feature are its ownedRelationships that are TypeFeaturings and which have the Feature as their featureOfType . 170 Kernel Modeling Language v1.0 -ownedTypeFeaturing = ownedRelationship->selectByKind(TypeFeaturing)-> select(tf | tf.featureOfType = self) deriveFeatureOwnedTyping The ownedTypings of a Feature are its ownedSpecializations that are FeatureTypings . ownedTyping = ownedGeneralization->selectByKind(FeatureTyping) deriveFeatureType The types of a Feature are the union of the types of its typings and the types of the Features it subsets, with all redundant supertypes removed. If the Feature has chainingFeatures , then the union also includes the types of the last chainingFeature . type = let types : OrderedSet(Types) = OrderedSet{self}-> -- Note: The closure operation automatically handles circular relationships. closure(typingFeatures()).typing.type->asOrderedSet() in types->reject(t1 | types->exist(t2 | t2 <> t1 and t2.specializes(t1))) validateFeatureChainingFeatureConformance Each chainingFeature (other than the first) must be featured within the previous chainingFeature . Sequence{2..chainingFeature->size()}->forAll(i | chainingFeature->at(i).isFeaturedWithin(chainingFeature->at(i-1))) validateFeatureChainingFeatureNotOne A Feature must have either no chainingFeatures or more than one. chainingFeature->size() <> 1 validateFeatureChainingFeaturesNotSelf A Feature cannot be one of its own chainingFeatures . chainingFeature->excludes(self) validateFeatureConstantIsVariable A Feature with isConstant = true must have isVariable = true isConstant implies isVariable validateFeatureCrossFeatureSpecialization If this Feature has a crossFeature , then, for any Feature that is redefined by this Feature , the crossFeature must specialize the crossFeature of the redefined end Feature , if this exists. crossFeature <> null implies ownedRedefinition.redefinedFeature.crossFeature-> forAll(f | f <> null implies crossFeature.specializes(f)) validateFeatureCrossFeatureType The crossFeature of a Feature must have the same types as the Feature . Kernel Modeling Language v1.0 171 -crossFeature <> null implies crossFeature.type->asSet() = type->asSet() validateFeatureEndIsConstant A Feature with isEnd = true and isVariable = true must have isConstant = true . isEnd and isVariable implies isConstant validateFeatureEndMultiplicity If a Feature has isEnd = true , then it must have multiplicity 1..1 . isEnd implies multiplicities().allSuperTypes()->flatten()-> selectByKind(MultiplicityRange)->exists(hasBounds(1,1)) validateFeatureEndNoDirection A Feature with isEnd = true must have no direction. isEnd implied direction = null validateFeatureEndNotDerivedAbstractCompositeOrPortion A Feature with isEnd = true must have all of isDerived = false , isAbstract = false , isComposite = false , and isPortion = false . isEnd implies not (isDerived or isAbstract or isComposite or isPortion) validateFeatureIsVariable A Feature with isVariable = true must have an owningType that directly or indirectly specializes the Class Occurrences::Occurrence from the Kernel Semantic Library. isVariable implies owningType <> null and owningType.specializes('Occurrences::Occurrence') validateFeatureMultiplicityDomain If a Feature has a multiplicity , then the featuringTypes of the multiplicity must be the same as those of the Feature itself. multiplicity <> null implies multiplicity.featuringType = featuringType validateFeatureOwnedCrossSubsetting A Feature must have at most one ownedSubsetting that is a CrossSubsetting . ownedSubsetting->selectByKind(CrossSubsetting)->size() <= 1 validateFeatureOwnedReferenceSubsetting A Feature must have at most one ownedSubsetting that is an ReferenceSubsetting . ownedSubsetting->selectByKind(ReferenceSubsetting)->size() <= 1 172 Kernel Modeling Language v1.0 -validateFeaturePortionNotVariable isPortion implies not isVariable 8.3.3.3.5 FeatureChaining Description FeatureChaining is a Relationship that makes its target Feature one of the chainingFeatures of its owning Feature . General Classes Relationship Attributes chainingFeature : Feature {redefines target} The Feature whose values partly determine values of featureChained , as described in Feature::chainingFeature . /featureChained : Feature {subsets owningRelatedElement, redefines source} The Feature whose values are partly determined by values of the chainingFeature , as described in Feature::chainingFeature . Operations None. Constraints None. 8.3.3.3.6 FeatureInverting Description A FeatureInverting is a Relationship between Features asserting that their interpretations (sequences) are the reverse of each other, identified as featureInverted and invertingFeature . For example, a Feature identifying each person's parents is the inverse of a Feature identifying each person's children. A person identified as a parent of another will identify that other as one of their children. General Classes Relationship Attributes featureInverted : Feature {redefines source} The Feature that is an inverse of the invertingFeature . invertingFeature : Feature {redefines target} Kernel Modeling Language v1.0 173 -The Feature that is an inverse of the invertedFeature . /owningFeature : Feature [0..1] {subsets owningRelatedElement, featureInverted} A featureInverted that is also the owningRelatedElement of this FeatureInverting . Operations None. Constraints None. 8.3.3.3.7 FeatureTyping Description FeatureTyping is Specialization in which the specific Type is a Feature . This means the set of instances of the (specific) typedFeature is a subset of the set of instances of the (general) type . In the simplest case, the type is a Classifier , whereupon the typedFeature has values that are instances of the Classifier . General Classes Specialization Attributes /owningFeature : Feature [0..1] {subsets typedFeature, redefines owningType} A typedFeature that is also the owningRelatedElement of this FeatureTyping . type : Type {redefines general} The Type that is being applied by this FeatureTyping . typedFeature : Feature {redefines specific} The Feature that has a type determined by this FeatureTyping . Operations None. Constraints None. 8.3.3.3.8 Redefinition Description Redefinition is a kind of Subsetting that requires the redefinedFeature and the redefiningFeature to have the same values (on each instance of the domain of the redefiningFeature ). This means any restrictions on the redefiningFeature , such as type or multiplicity , also apply to the redefinedFeature (on each instance of the domain of the redefiningFeature ), and vice versa. The redefinedFeature might have values 174 Kernel Modeling Language v1.0 -for instances of the domain of the redefiningFeature , but only as instances of the domain of the redefinedFeature that happen to also be instances of the domain of the redefiningFeature . This is supported by the constraints inherited from Subsetting on the domains of the redefiningFeature and redefinedFeature . However, these constraints are narrowed for Redefinition to require the owningTypes of the redefiningFeature and redefinedFeature to be different and the redefinedFeature to not be inherited into the owningNamespace of the redefiningFeature .This enables the redefiningFeature to have the same name as the redefinedFeature , if desired. General Classes Subsetting Attributes redefinedFeature : Feature {redefines subsettedFeature} The Feature that is redefined by the redefiningFeature of this Redefinition . redefiningFeature : Feature {redefines subsettingFeature} The Feature that is redefining the redefinedFeature of this Redefinition . Operations None. Constraints validateRedefinitionDirectionConformance If the redefinedFeature of a Redefinition has a direction of in or out (relative to any featuringType of the redefiningFeature or the owningType , if the redefiningFeature has isVariable = true ), then the redefiningFeature must have the same direction . If the redefinedFeature has a direction of inout , then the redefiningFeature must have a non-null direction . (Note: the direction of the redefinedFeature relative to a featuringType of the redefiningFeature is the direction it would have if it had been inherited and not redefined.) let featuringTypes : Sequence(Type) = if redefiningFeature.isVariable then Sequence{redefiningFeature.owningType} else redefiningFeature.featuringType endif in featuringTypes->forAll(t | let direction : FeatureDirectionKind = t.directionOf(redefinedFeature) in ((direction = FeatureDirectionKind::_'in' or direction = FeatureDirectionKind::out) implies redefiningFeature.direction = direction) and (direction = FeatureDirectionKind::inout implies redefiningFeature.direction <> null)) validateRedefinitionEndConformance If the redefinedFeature of a Redefinition has isEnd = true, then the redefiningFeature must have isEnd = true. redefinedFeature.isEnd implies redefiningFeature.isEnd validateRedefinitionFeaturingTypes Kernel Modeling Language v1.0 175 -The redefiningFeature of a Redefinition must have at least one featuringType that is not also a featuringType of the redefinedFeature . let anythingType: Type = redefiningFeature.resolveGlobal('Base::Anything').modelElement.oclAsType(Type) in -- Including "Anything" accounts for implicit featuringType of Features -- with no explicit featuringType. let redefiningFeaturingTypes: Set(Type) = if redefiningFeature.isVariable then Set{redefiningFeature.owningType} else redefiningFeature.featuringTypes->asSet()->including(anythingType) endif in let redefinedFeaturingTypes: Set(Type) = if redefinedFeature.isVariable then Set{redefinedFeature.owningType} else redefinedFeature.featuringTypes->asSet()->including(anythingType) endif in redefiningFeaturingTypes <> redefinedFeaturingType 8.3.3.3.9 ReferenceSubsetting Description ReferenceSubsetting is a kind of Subsetting in which the referencedFeature is syntactically distinguished from other Features subsetted by the referencingFeature . ReferenceSubsetting has the same semantics as Subsetting , but the referencedFeature may have a special purpose relative to the referencingFeature . For instance, ReferenceSubsetting is used to identify the relatedFeatures of a Connector . ReferenceSubsetting is always an ownedRelationship of its referencingFeature . A Feature can have at most one ownedReferenceSubsetting . General Classes Subsetting Attributes referencedFeature : Feature {redefines subsettedFeature} The Feature that is referenced by the referencingFeature of this ReferenceSubsetting . /referencingFeature : Feature {redefines subsettingFeature, owningFeature} The Feature that owns this ReferenceSubsetting relationship, which is also its subsettingFeature . Operations None. Constraints None. 8.3.3.3.10 Subsetting Description Subsetting is Specialization in which the specific and general Types are Features . This means all values of the subsettingFeature (on instances of its domain, i.e., the intersection of its featuringTypes ) are 176 Kernel Modeling Language v1.0 -values of the subsettedFeature on instances of its domain. To support this the domain of the subsettingFeature must be the same or specialize (at least indirectly) the domain of the subsettedFeature (via Specialization ), and the co-domain (intersection of the types ) of the subsettingFeature must specialize the co-domain of the subsettedFeature . General Classes Specialization Attributes /owningFeature : Feature [0..1] {subsets subsettingFeature, redefines owningType} A subsettingFeature that is also the owningRelatedElement of this Subsetting . subsettedFeature : Feature {redefines general} The Feature that is subsetted by the subsettingFeature of this Subsetting . subsettingFeature : Feature {redefines specific} The Feature that is a subset of the subsettedFeature of this Subsetting . Operations None. Constraints validateSubsettingConstantConformance If the subsettedFeature of a Subsetting has isConstant = true and the subsettingFeature has isVariable = true , then the subsettingFeature must have isConstant = true . subsettedFeature.isConstant and subsettingFeature.isVariable implies subsettingFeature.isConstant validateSubsettingFeaturingTypes The subsettedFeature must be accessible by the subsettingFeature . subsettingFeature.canAccess(subsettedFeature) validateSubsettingUniquenessConformance If the subsettedFeature of a Subsetting has isUnique = true , then the subsettingFeature must have isUnique = true . subsettedFeature.isUnique implies subsettingFeature.isUnique 8.3.3.3.11 TypeFeaturing Description A TypeFeaturing is a Featuring Relationship in which the featureOfType is the source and the featuringType is the target . Kernel Modeling Language v1.0 177 -General Classes Relationship Attributes featureOfType : Feature {redefines source} The Feature that is featured by the featuringType . It is the source of the TypeFeaturing . featuringType : Type {redefines target} The Type that features the featureOfType . It is the target of the TypeFeaturing . /owningFeatureOfType : Feature [0..1] {subsets featureOfType, owningRelatedElement} A featureOfType that is also the owningRelatedElement of this TypeFeaturing . Operations None. Constraints None. 8.3.4 Kernel Abstract Syntax 8.3.4.1 Data Types Abstract Syntax 8.3.4.1.1 Overview Classifier DataType Figure 23. Data Types 8.3.4.1.2 DataType Description A DataType is a Classifier of things (in the universe) that can only be distinguished by how they are related to other things (via Features). This means multiple things classified by the same DataType • Cannot be distinguished when they are related to other things in exactly the same way, even when they are intended to be about different things. • Can be distinguished when they are related to other things in different ways, even when they are intended to be about the same thing. 178 Kernel Modeling Language v1.0 -General Classes Classifier Attributes None. Operations None. Constraints checkDataTypeSpecialization A DataType must directly or indirectly specialize the base DataType Base::DataValue from the Kernel Semantic Library. specializesFromLibrary('Base::DataValue') validateDataTypeSpecialization A DataType must not specialize a Class or an Association . ownedSpecialization.general-> forAll(not oclIsKindOf(Class) and not oclIsKindOf(Association)) 8.3.4.2 Classes Abstract Syntax 8.3.4.2.1 Overview Classifier Class Figure 24. Classes 8.3.4.2.2 Class Description A Class is a Classifier of things (in the universe) that can be distinguished without regard to how they are related to other things (via Features ). This means multiple things classified by the same Class can be distinguished, even when they are related other things in exactly the same way. General Classes Classifier Kernel Modeling Language v1.0 179 -Attributes None. Operations None. Constraints checkClassSpecialization A Class must directly or indirectly specialize the base Class Occurrences::Occurrence from the Kernel Semantic Library. specializesFromLibrary('Occurrences::Occurrence') validateClassSpecialization A Class must not specialize a DataType and it can only specialize an Association if it is also itself a kind of Association (such as an AssociationStructure or Interaction ). ownedSpecialization.general-> forAll(not oclIsKindOf(DataType)) and not oclIsKindOf(Association) implies ownedSpecialization.general-> forAll(not oclIsKindOf(Association)) 8.3.4.3 Structures Abstract Syntax 8.3.4.3.1 Overview Class Structure Figure 25. Structures 8.3.4.3.2 Structure Description A Structure is a Class of objects in the modeled universe that are primarily structural in nature. While such an object is not itself behavioral, it may be involved in and acted on by Behaviors , and it may be the performer of some of them. General Classes Class Attributes None. 180 Kernel Modeling Language v1.0 -Operations None. Constraints checkStructureSpecialization A Structure must directly or indirectly specialize the base Structure Objects::Object from the Kernel Semantic Library. specializesFromLibrary('Objects::Object') validateStructureSpecialization A Structure must not specialize a Behavior . ownedSpecialization.general->forAll(not oclIsKindOf(Behavior)) 8.3.4.4 Associations Abstract Syntax 8.3.4.4.1 Overview Relationship Classifier Class +/association +/relatedType Type Association {redefines relatedElement, 0..* 0..* {subsets ordered, nonunique} Structure relationship} +/sourceAssociation +/sourceType 0..* {subsets relatedType, 0..1 {subsets association, redefines source} subsets sourceRelationship} AssociationStructure +/targetAssociation +/targetType 0..* 0..* {subsets relatedType, {subsets association, redefines target} subsets targetAssociation} +/associationEnd +/associationWithEnd Feature 0..* 0..* {subsets {redefines typeWithEndFeature} endFeature} Figure 26. Associations 8.3.4.4.2 Association Description An Association is a Relationship and a Classifier to enable classification of links between things (in the universe). The co-domains ( types ) of the associationEnd Features are the relatedTypes , as co-domain and participants (linked things) of an Association identify each other. Kernel Modeling Language v1.0 181 -General Classes Classifier Relationship Attributes /associationEnd : Feature [0..*] {redefines endFeature} The features of the Association that identify the things that can be related by it. A concrete Association must have at least two associationEnds . When it has exactly two, the Association is called a binary Association . /relatedType : Type [0..*] {redefines relatedElement, ordered, nonunique} The types of the associationEnds of the Association , which are the relatedElements of the Association considered as a Relationship . /sourceType : Type [0..1] {subsets relatedType, redefines source} The source relatedType for this Association . It is the first relatedType of the Association . /targetType : Type [0..*] {subsets relatedType, redefines target} The target relatedTypes for this Association . This includes all the relatedTypes other than the sourceType . Operations None. Constraints checkAssociationBinarySpecialization A binary Association must directly or indirectly specialize the base Association Links::binaryLink from the Kernel Semantic Library. associationEnd->size() = 2 implies specializesFromLibrary('Links::BinaryLink') checkAssociationSpecialization An Association must directly or indirectly specialize the base Association Links::Link from the Kernel Semantic Library. specializesFromLibrary('Links::Link') deriveAssociationRelatedType The relatedTypes of an Association are the types of its associationEnds . relatedType = associationEnd.type deriveAssociationSourceType The sourceType of an Association is its first relatedType (if any). 182 Kernel Modeling Language v1.0 -sourceType = if relatedType->isEmpty() then null else relatedType->first() endif deriveAssociationTargetType targetType = if relatedType->size() < 2 then OrderedSet{} else relatedType-> subSequence(2, relatedType->size())-> asOrderedSet() endif validateAssociationBinarySpecialization If an Association has more than two associationEnds , then it must not specialize, directly or indirectly, the Association BinaryLink from the Kernel Semantic Library. associationEnds->size() > 2 implies not specializesFromLibrary('Links::BinaryLink') validateAssociationEndTypes The ownedEndFeatures of an Association must have exactly one type ownedEndFeature->forAll(type->size() = 1) validateAssociationRelatedTypes If an Association is concrete (not abstract), then it must have at least two relatedTypes . not isAbstract implies relatedType->size() >= 2 validateAssociationStructureIntersection If an Association is also a kind of Structure , then it must be an AssociationStructure . oclIsKindOf(Structure) = oclIsKindOf(AssociationStructure) 8.3.4.4.3 AssociationStructure Description An AssociationStructure is an Association that is also a Structure , classifying link objects that are both links and objects. As objects, link objects can be created and destroyed, and their non-end Features can change over time. However, the values of the end Features of a link object are fixed and cannot change over its lifetime. General Classes Association Structure Attributes None. Kernel Modeling Language v1.0 183 -Operations None. Constraints checkAssociationStructureBinarySpecialization A binary AssociationStructure must directly or indirectly specialize the base AssociationStructure Objects::BinaryLinkObject from the Kernel Semantic Library. endFeature->size() = 2 implies specializesFromLibrary('Objects::BinaryLinkObject') checkAssociationStructureSpecialization An AssociationStructure must directly or indirectly specialize the base AssociationStructure Objects::LinkObject from the Kernel Semantic Library. specializesFromLibrary('Objects::LinkObject') 184 Kernel Modeling Language v1.0 -8.3.4.5 Connectors Abstract Syntax 8.3.4.5.1 Overview Relationship Connector Feature +/featuringConnector +/connectorEnd 0..* 0..* {subsets typeWithEndFeature} {redefines endFeature, ordered} +/connector +/relatedFeature 0..* 0..* {subsets relationship} {redefines relatedElement, ordered, nonunique} +/sourceConnector +/sourceFeature 0..* 0..1 {subsets connector, {subsets relatedFeature, subsets sourceRelationship} redefines source, ordered} +/targetConnector +/targetFeature 0..* 0..* {subsets connector, {subsets relatedFeature, subsets targetRelationship} redefines target, ordered} +/association +/typedConnector Association 0..* 0..* {subsets typedFeature} {redefines type, ordered} +/featuredConnector +/defaultFeaturingType Type 0..* 0..1 BindingConnector Succession Figure 27. Connectors 8.3.4.5.2 Binding Connector Description A BindingConnector is a binary Connector that requires its relatedFeatures to identify the same things (have the same values). General Classes Connector Kernel Modeling Language v1.0 185 -Attributes None. Operations None. Constraints checkBindingConnectorSpecialization A BindingConnector must directly or indirectly specialize the base BindingConnector Links::selfLinks from the Kernel Semantic Library. specializesFromLibrary('Links::selfLinks') validateBindingConnectorIsBinary A BindingConnector must be binary. relatedFeature->size() = 2 8.3.4.5.3 Connector Description A Connector is a usage of Associations , with links restricted according to instances of the Type in which they are used (domain of the Connector ). The associations of the Connector restrict what kinds of things might be linked. The Connector further restricts these links to be between values of Features on instances of its domain. General Classes Relationship Feature Attributes /association : Association [0..*] {redefines type, ordered} The Associations that type the Connector . /connectorEnd : Feature [0..*] {redefines endFeature, ordered} The endFeatures of a Connector , which redefine the endFeatures of the associations of the Connector . The connectorEnds determine via ReferenceSubsetting Relationships which Features are related by the Connector . /defaultFeaturingType : Type [0..1] The innermost Type that is a common direct or indirect featuringType of the relatedFeatures , such that, if it exists and was the featuringType of this Connector , the Connector would satisfy the checkConnectorTypeFeaturing constraint. /relatedFeature : Feature [0..*] {redefines relatedElement, ordered, nonunique} 186 Kernel Modeling Language v1.0 -The Features that are related by this Connector considered as a Relationship and that restrict the links it identifies, given by the referenced Features of the connectorEnds of the Connector . /sourceFeature : Feature [0..1] {subsets relatedFeature, redefines source, ordered} The source relatedFeature for this Connector . It is the first relatedFeature . /targetFeature : Feature [0..*] {subsets relatedFeature, redefines target, ordered} The target relatedFeatures for this Connector . This includes all the relatedFeatures other than the sourceFeature . Operations None. Constraints checkConnectorBinaryObjectSpecialization A binary Connector for an AssociationStructure must directly or indirectly specialize the base Connector Objects::binaryLinkObjects from the Kernel Semantic Library. connectorEnds->size() = 2 and association->exists(oclIsKindOf(AssociationStructure)) implies specializesFromLibrary('Objects::binaryLinkObjects') checkConnectorBinarySpecialization A binary Connector must directly or indirectly specialize the base Connector Links::binaryLinks from the Kernel Semantic Library. connectorEnd->size() = 2 implies specializesFromLibrary('Links::binaryLinks') checkConnectorObjectSpecialization A Connector for an AssociationStructure must directly or indirectly specialize the base Connector Objects::linkObjects from the Kernel Semantic Library. association->exists(oclIsKindOf(AssociationStructure)) implies specializesFromLibrary('Objects::linkObjects') checkConnectorSpecialization A Connector must directly or indirectly specialize the base Connector Links::links from the Kernel Semantic Library. specializesFromLibrary('Links::links') checkConnectorTypeFeaturing Each relatedFeature of a Connector must have each featuringType of the Connector as a direct or indirect featuringType (where a Feature with no featuringType is treated as if the Classifier Base::Anything was its featuringType ). Kernel Modeling Language v1.0 187 -relatedFeature->forAll(f | if featuringType->isEmpty() then f.isFeaturedWithin(null) else featuringType->forAll(t | f.isFeaturedWithin(t)) endif) deriveConnectorDefaultFeaturingType The defaultFeaturingType of a Connector is the innermost common direct or indirect featuringType of the relatedFeatures of the Connector , so that each relatedElement is featured within the defaultFeaturingType , if such exists. let commonFeaturingTypes : OrderedSet(Type) = relatedFeature->closure(featuringType)->select(t | relatedFeature->forAll(f | f.isFeaturedWithin(t)) ) in let nearestCommonFeaturingTypes : OrderedSet(Type) = commonFeaturingTypes->reject(t1 | commonFeaturingTypes->exists(t2 | t2 <> t1 and t2->closure(featuringType)->contains(t1) )) in if nearestCommonFeaturingTypes->isEmpty() then null else nearestCommonFeaturingTypes->first() endif deriveConnectorRelatedFeature The relatedFeatures of a Connector are the referenced Features of its connectorEnds . relatedFeature = connectorEnd.ownedReferenceSubsetting-> select(s | s <> null).subsettedFeature deriveConnectorSourceFeature The sourceFeature of a Connector is its first relatedFeature (if any). sourceFeature = if relatedFeature->isEmpty() then null else relatedFeature->first() endif deriveConnectorTargetFeature The targetFeatures of a Connector are the relatedFeatures other than the sourceFeature . targetFeature = if relatedFeature->size() < 2 then OrderedSet{} else relatedFeature-> subSequence(2, relatedFeature->size())-> asOrderedSet() endif validateConnectorBinarySpecialization If a Connector has more than two connectorEnds , then it must not specialize, directly or indirectly, the Association BinaryLink from the Kernel Semantic Library. connectorEnds->size() > 2 implies not specializesFromLibrary('Links::BinaryLink') 188 Kernel Modeling Language v1.0 -validateConnectorRelatedFeatures If a Connector is concrete (not abstract), then it must have at least two relatedFeatures . not isAbstract implies relatedFeature->size() >= 2 8.3.4.5.4 Succession Description A Succession is a binary Connector that requires its relatedFeatures to happen separately in time. General Classes Connector Attributes None. Operations None. Constraints checkSuccessionSpecialization A Succession must directly or indirectly specialize the Feature Occurrences::happensBeforeLinks from the Kernel Semantic Library. specializesFromLibrary('Occurrences::happensBeforeLinks') Kernel Modeling Language v1.0 189 -8.3.4.6 Behaviors Abstract Syntax 8.3.4.6.1 Overview +/typeWithFeature +/feature Type Feature 0..* 0..* +/typeWithDirectedFeature +/directedFeature 0..* 0..* +/type +/typedFeature 0..* 0..* {ordered} +/parameter +/parameter Classifier 0..* 0..* {redefines {redefines directedFeature, directedFeature, Class ordered} ordered} +/parameteredStep +/parameteredBehavior Behavior Step 0..* 0..* {subsets typeWithFeature} {subsets typeWithFeature} +/featuringBehavior +/step 0..* 0..* {subsets typeWithFeature} {subsets feature} +/typedStep +/behavior 0..* 0..* {subsets type, {subsets typedFeature} ordered} Figure 28. Behaviors FeatureMembership ParameterMembership +parameterDirection() : FeatureDirectionKind [1] +/owningParameterMembership 0..1 {subsets owningFeatureMembership} {redefines ownedMemberFeature} +/ownedMemberParameter 1 Feature Figure 29. Parameter Memberships 190 Kernel Modeling Language v1.0 -8.3.4.6.2 Behavior Description A Behavior coordinates occurrences of other Behaviors , as well as changes in objects. Behaviors can be decomposed into Steps and be characterized by parameters . General Classes Class Attributes /parameter : Feature [0..*] {redefines directedFeature, ordered} The parameters of this Behavior , which are defined as its directedFeatures , whose values are passed into and/ or out of a performance of the Behavior . /step : Step [0..*] {subsets feature} The Steps that make up this Behavior . Operations None. Constraints checkBehaviorSpecialization A Behavior must directly or indirectly specialize the base Behavior Performances::Performance from the Kernel Semantic Library. specializesFromLibrary('Performances::Performance') deriveBehaviorStep The steps of a Behavior are its features that are Steps . step = feature->selectByKind(Step) validateBehaviorSpecialization A Behavior must not specialize a Structure . ownedSpecialization.general->forAll(not oclIsKindOf(Structure)) 8.3.4.6.3 Step Description A Step is a Feature that is typed by one or more Behaviors . Steps may be used by one Behavior to coordinate the performance of other Behaviors , supporting a steady refinement of behavioral descriptions. Steps can be ordered in time and can be connected using Flows to specify things flowing between their parameters . Kernel Modeling Language v1.0 191 -General Classes Feature Attributes /behavior : Behavior [0..*] {subsets type, ordered} The Behaviors that type this Step . /parameter : Feature [0..*] {redefines directedFeature, ordered} The parameters of this Step , which are defined as its directedFeatures , whose values are passed into and/or out of a performance of the Step . Operations None. Constraints checkStepEnclosedPerformanceSpecialization A Step whose owningType is a Behavior or another Step must directly or indirectly specialize the Step Performances::Performance::enclosedPerformance . owningType <> null and (owningType.oclIsKindOf(Behavior) or owningType.oclIsKindOf(Step)) implies specializesFromLibrary('Performances::Performance::enclosedPerformance') checkStepOwnedPerformanceSpecialization A composite Step whose owningType is a Structure or a Feature typed by a Structure must directly or indirectly specialize the Step Objects::Object::ownedPerformance . isComposite and owningType <> null and (owningType.oclIsKindOf(Structure) or owningType.oclIsKindOf(Feature) and owningType.oclAsType(Feature).type-> exists(oclIsKindOf(Structure)) implies specializesFromLibrary('Objects::Object::ownedPerformance') checkStepSpecialization A Step must directly or indirectly specialize the base Step Performances::performances from the Kernel Semantic Library. specializesFromLibrary('Performances::performances') checkStepSubperformanceSpecialization A Step whose owningType is a Behavior or another Step , and which is composite, must directly or indirectly specialize the Step Performances::Performance::subperformance . owningType <> null and (owningType.oclIsKindOf(Behavior) or owningType.oclIsKindOf(Step)) and 192 Kernel Modeling Language v1.0 -self.isComposite implies specializesFromLibrary('Performances::Performance::subperformance') deriveStepBehavior The behaviors of a Step are all its types that are Behaviors . behavior = type->selectByKind(Behavior) 8.3.4.6.4 ParameterMembership Description A ParameterMembership is a FeatureMembership that identifies its memberFeature as a parameter, which is always owned, and must have a direction . A ParameterMembership must be owned by a Behavior , a Step , or the result parameter of a ConstructorExpression . General Classes FeatureMembership Attributes /ownedMemberParameter : Feature {redefines ownedMemberFeature} The Feature that is identified as a parameter by this ParameterMembership . Operations parameterDirection() : FeatureDirectionKind Return the required value of the direction of the ownedMemberParameter . By default, this is in . body: FeatureDirectionKind::_'in' Constraints validateParameterMembershipOwningType A ParameterMembership must be owned by a Behavior , Step , or the result parameter of a ConstructorExpression . owningType.oclIsKindOf(Behavior) or owningType.oclIsKindOf(Step) or owningType.owningMembership.oclIsKindOf(ReturnParameterMembership) and owningType.owningNamespace.oclIsKindOf(ConstructorExpression) validateParameterMembershipParameterDirection The ownedMemberParameter of a ParameterMembership must have a direction equal to the result of the parameterDirection() operation. ownedMemberParameter.direction = parameterDirection() Kernel Modeling Language v1.0 193 -8.3.4.7 Functions Abstract Syntax 8.3.4.7.1 Overview Behavior Feature Step +/result 1 1 +/result {subsets output, {subsets output, subsets parameter} subsets parameter} +/computingFunction +/computingExpression Function Expression 0..* 0..* +/isModelLevelEvaluable : Boolean +/isModelLevelEvaluable : Boolean {subsets parameteredBehavior} {subsets parameteredStep} +modelLevelEvaluable( visited : Feature [0..*] ) : Boolean +computedFunction +/expression +evaluate( target : Element ) : Element [0..*] +checkCondition( target : Element ) : Boolean 0..* 0..* {subsets featuringBehavior} {subsets step} +/function +/typedExpression 0..1 0..* {redefines behavior} {subsets typedStep} Figure 30. Functions +/function +/typedExpression Function Expression 0..1 0..* {redefines behavior} {subsets typedStep} +/predicate +/typedBooleanExpression Predicate BooleanExpression 0..1 0..* {redefines function} {subsets typedExpression} Invariant +isNegated : Boolean = false Figure 31. Predicates FeatureMembership ParameterMembership ResultExpressionMembership +parameterDirection() : FeatureDirectionKind [1] +/owningResultExpressionMembership 0..1 {subsets owningFeatureMembership} {redefines ownedMemberFeature} +/ownedResultExpression 1 ReturnParameterMembership Expression +parameterDirection() : FeatureDirectionKind [1]{redefines parameterDirection} Figure 32. Function Memberships 194 Kernel Modeling Language v1.0 -8.3.4.7.2 BooleanExpression Description A BooleanExpression is a Boolean -valued Expression whose type is a Predicate . It represents a logical condition resulting from the evaluation of the Predicate . General Classes Expression Attributes /predicate : Predicate [0..1] {redefines function} The Predicate that types this BooleanExpression . The Predicate that types the Expression. Operations None. Constraints checkBooleanExpressionSpecialization A BooleanExpression must directly or indirectly specialize the base BooleanExpression Performances::booleanEvaluations from the Kernel Semantic Library. specializesFromLibrary('Performances::booleanEvaluations') 8.3.4.7.3 Expression Description An Expression is a Step that is typed by a Function . An Expression that also has a Function as its featuringType is a computational step within that Function . An Expression always has a single result parameter, which redefines the result parameter of its defining function . This allows Expressions to be interconnected in tree structures, in which inputs to each Expression in the tree are determined as the results of other Expression in the tree. General Classes Step Attributes /function : Function [0..1] {redefines behavior} The Function that types this Expression . This is the Function that types the Expression. /isModelLevelEvaluable : Boolean Kernel Modeling Language v1.0 195 -Whether this Expression meets the constraints necessary to be evaluated at model level, that is, using metadata within the model. /result : Feature {subsets parameter, output} An output parameter of the Expression whose value is the result of the Expression . The result of an Expression is either inherited from its function or it is related to the Expression via a ReturnParameterMembership , in which case it redefines the result parameter of its function . Operations checkCondition(target : Element) : Boolean Model-level evaluate this Expression with the given target . If the result is a LiteralBoolean , return its value . Otherwise return false . body: let results: Sequence(Element) = evaluate(target) in result->size() = 1 and results->first().oclIsKindOf(LiteralBoolean) and results->first().oclAsType(LiteralBoolean).value evaluate(target : Element) : Element [0..*] If this Expression isModelLevelEvaluable , then evaluate it using the target as the context Element for resolving Feature names and testing classification. The result is a collection of Elements , which, for a fully evaluable Expression , will be a LiteralExpression or a Feature that is not an Expression . pre: isModelLevelEvaluable body: let resultExprs : Sequence(Expression) = ownedFeatureMembership-> selectByKind(ResultExpressionMembership). ownedResultExpression in if resultExpr->isEmpty() then Sequence{} else resultExprs->first().evaluate(target) endif modelLevelEvaluable(visited : Feature [0..*]) : Boolean Return whether this Expression is model-level evaluable. The visited parameter is used to track possible circular Feature references made from FeatureReferenceExpressions (see the redefinition of this operation for FeatureReferenceExpression ). Such circular references are not allowed in model-level evaluable expressions. An Expression that is not otherwise specialized is model-level evaluable if it has no (non-implied) ownedSpecializations and all its ownedFeatures are either in parameters, the result parameter or a result Expression owned via a ResultExpressionMembership . The parameters must not have any ownedFeatures or a FeatureValue , and the result Expression must be model-level evaluable. body: ownedSpecialization->forAll(isImplied) and ownedFeature->forAll(f | (directionOf(f) = FeatureDirectionKind::_'in' or f = result) and f.ownedFeature->isEmpty() and f.valuation = null or f.owningFeatureMembership.oclIsKindOf(ResultExpressionMembership) and f.oclAsType(Expression).modelLevelEvaluable(visited) 196 Kernel Modeling Language v1.0 -Constraints checkExpressionResultBindingConnector If an Expression has an Expression owned via a ResultExpressionMembership , then the owning Expression must also own a BindingConnector between its result parameter and the result parameter of the result Expression . ownedMembership.selectByKind(ResultExpressionMembership)-> forAll(mem | ownedFeature.selectByKind(BindingConnector)-> exists(binding | binding.relatedFeature->includes(result) and binding.relatedFeature->includes(mem.ownedResultExpression.result))) checkExpressionSpecialization An Expression must directly or indirectly specialize the base Expression Performances::evaluations from the Kernel Semantic Library. specializesFromLibrary('Performances::evaluations') checkExpressionTypeFeaturing If this Expression is owned by a FeatureValue , then it must have the same featuringTypes as the featureWithValue of the FeatureValue . owningMembership <> null and owningMembership.oclIsKindOf(FeatureValue) implies let featureWithValue : Feature = owningMembership.oclAsType(FeatureValue).featureWithValue in featuringType = featureWithValue.featuringType deriveExpressionIsModelLevelEvaluable Whether an Expression isModelLevelEvaluable is determined by the modelLevelEvaluable() operation. isModelLevelEvaluable = modelLevelEvaluable(Set(Element){}) deriveExpressionResult The result parameter of an Expression is its parameter owned (possibly in a supertype) via a ReturnParameterMembership (if any). result = let resultParams : Sequence(Feature) = featureMemberships-> selectByKind(ReturnParameterMembership). ownedMemberParameter in if resultParams->notEmpty() then resultParams->first() else null endif validateExpressionResultExpressionMembership An Expression must have at most one ResultExpressionMembership . membership->selectByKind(ResultExpressionMembership)->size() <= 1 Kernel Modeling Language v1.0 197 -validateExpressionResultParameterMembership An Expression must have exactly one featureMembership (owned or inherited) that is a ResultParameterMembership . featureMembership-> selectByKind(ReturnParameterMembership)-> size() = 1 8.3.4.7.4 Function Description A Function is a Behavior that has an out parameter that is identified as its result . A Function represents the performance of a calculation that produces the values of its result parameter . This calculation may be decomposed into Expressions that are steps of the Function . General Classes Behavior Attributes /expression : Expression [0..*] {subsets step} The set of expressions that represent computational steps or parts of a system of equations within the Function. The Expressions that are steps in the calculation of the result of this Function . /isModelLevelEvaluable : Boolean Whether this Function can be used as the function of a model-level evaluable InvocationExpression . Certain Functions from the Kernel Functions Library are considered to have isModelLevelEvaluable = true . For all other Functions it is false . Note: See the specification of the KerML concrete syntax notation for Expressions for an identification of which library Functions are model-level evaluable. /result : Feature {subsets parameter, output} The object or value that is the result of evaluating the Function. The result parameter of the Function , which is owned by the Function via a ReturnParameterMembership . Operations None. Constraints checkFunctionResultBindingConnector If a Function has an Expression owned via a ResultExpressionMembership , then the owning Function must also own a BindingConnector between its result parameter and the result parameter of the result Expression . 198 Kernel Modeling Language v1.0 -ownedMembership.selectByKind(ResultExpressionMembership)-> forAll(mem | ownedFeature.selectByKind(BindingConnector)-> exists(binding | binding.relatedFeature->includes(result) and binding.relatedFeature->includes(mem.ownedResultExpression.result))) checkFunctionSpecialization A Function must directly or indirectly specialize the base Function Performances::Evaluation from the Kernel Semantic Library. specializesFromLibrary('Performances::Evaluation') deriveFunctionResult The result parameter of a Function is its parameter owned (possibly in a supertype) via a ReturnParameterMembership (if any). result = let resultParams : Sequence(Feature) = featureMemberships-> selectByKind(ReturnParameterMembership). ownedMemberParameter in if resultParams->notEmpty() then resultParams->first() else null endif validateFunctionResultExpressionMembership A Function must have at most one ResultExpressionMembership . membership->selectByKind(ResultExpressionMembership)->size() <= 1 validateFunctionResultParameterMembership A Function must have exactly one featureMembership (owned or inherited) that is a ResultParameterMembership . featureMembership-> selectByKind(ReturnParameterMembership)-> size() = 1 8.3.4.7.5 Invariant Description An Invariant is a BooleanExpression that is asserted to have a specific Boolean result value. If isNegated = false , then the result is asserted to be true. If isNegated = true , then the result is asserted to be false. General Classes BooleanExpression Attributes isNegated : Boolean Whether this Invariant is asserted to be false rather than true. Kernel Modeling Language v1.0 199 -Operations None. Constraints checkInvariantSpecialization An Invariant must directly or indirectly specialize either of the following BooleanExpressions from the Kernel Semantic Library: Performances::trueEvaluations , if isNegated = false , or Performances::falseEvaluations , if isNegated = true . if isNegated then specializesFromLibrary('Performances::falseEvaluations') else specializesFromLibrary('Performances::trueEvaluations') endif 8.3.4.7.6 Predicate Description A Predicate is a Function whose result parameter has type Boolean and multiplicity 1..1 . General Classes Function Attributes None. Operations None. Constraints checkPredicateSpecialization A Predicate must directly or indirectly specialize the base Predicate Performances::BooleanEvaluation from the Kernel Semantic Library. specializesFromLibrary('Performances::BooleanEvaluation') 8.3.4.7.7 ResultExpressionMembership Description A ResultExpressionMembership is a FeatureMembership that indicates that the ownedResultExpression provides the result values for the Function or Expression that owns it. The owning Function or Expression must contain a BindingConnector between the result parameter of the ownedResultExpression and the result parameter of the owning Function or Expression . General Classes FeatureMembership 200 Kernel Modeling Language v1.0 -Attributes /ownedResultExpression : Expression {redefines ownedMemberFeature} The Expression that provides the result for the owner of the ResultExpressionMembership . Operations None. Constraints validateResultExpressionMembershipOwningType The owningType of a ResultExpressionMembership must be a Function or Expression . owningType.oclIsKindOf(Function) or owningType.oclIsKindOf(Expression) 8.3.4.7.8 ReturnParameterMembership Description A ReturnParameterMembership is a ParameterMembership that indicates that the ownedMemberParameter is the result parameter of a Function or Expression . The direction of the ownedMemberParameter must be out . General Classes ParameterMembership Attributes None. Operations parameterDirection() : FeatureDirectionKind {redefines parameterDirection, leaf} The ownedMemberParameter of a ReturnParameterMembership must have direction out . (This is a leaf operation that cannot be further redefined.) body: FeatureDirectionKind::out Constraints validateReturnParameterMembershipOwningType The owningType of a ReturnParameterMembership must be a Function or Expression . owningType.oclIsKindOf(Function) or owningType.oclIsKindOf(Expression) Kernel Modeling Language v1.0 201 -8.3.4.8 Expressions Abstract Syntax 8.3.4.8.1 Overview Step Expression +/isModelLevelEvaluable : Boolean +/argument +modelLevelEvaluable( visited : Feature [0..*] ) : Boolean 0..* +evaluate( target : Element ) : Element [0..*] {ordered} +checkCondition( target : Element ) : Boolean +/instantiation 0..1 +/instantiationExpression +/instantiatedType NullExpression FeatureReferenceExpression InstantiationExpression Type 0..* 1 +instantiatedType() : Type [0..1] +modelLevelEvaluable( visited : Feature [0..*] ) : Boolean{redefines modelLevelEvaluable} +modelLevelEvaluable( visited : Feature [0..*] ) : Boolean{redefines modelLevelEvaluable} +evaluate( target : Element ) : Element [0..*]{redefines evaluate} +evaluate( target : Element ) : Element [0..*]{redefines evaluate} {subsets namespace} {subsets member} +/referenceExpression 0..* {subsets namespace} LiteralExpression MetadataAccessExpression ConstructorExpression +modelLevelEvaluable( visited : Feature [0..*] ) : Boolean{redefines modelLevelEvaluable} +modelLevelEvaluable( visited : Feature [0..*] ) : Boolean{redefines modelLevelEvaluable} +evaluate( target : Element ) : Element [0..*]{redefines evaluate} +evaluate( target : Element ) : Element [0..*]{redefines evaluate} +modelLevelEvaluable( visited : Feature [0..*] ) : Boolean{redefines modelLevelEvaluable} +metaclassFeature() : MetadataFeature +/accessExpression 0..* {subsets member} {subsets namespace} InvocationExpression +/referent 1 +modelLevelEvaluable( visited : Feature [0..*] ) : Boolean{redefines modelLevelEvaluable} Feature +evaluate( target : Element ) : Element [0..*]{redefines evaluate} {subsets member} +/targetFeature 1 +/referencedElement 1 {subsets member} Element OperatorExpression +operator : String +instantiatedType() : Type{redefines instantiatedType} {subsets namespace} +/chainExpression 0..* FeatureChainExpression CollectExpression SelectExpression IndexExpression +operator : String = .{redefines operator} +operator : String = collect{redefines operator} +operator : String = select{redefines operator} +operator : String = #{redefines operator} Figure 33. Expressions Expression LiteralExpression +modelLevelEvaluable( visited : Feature [0..*] ) : Boolean{redefines modelLevelEvaluable} +evaluate( target : Element ) : Element [0..*]{redefines evaluate} LiteralString LiteralRational LiteralInfinity +value : String +value : Real LiteralBoolean LiteralInteger +value : Boolean +value : Integer Figure 34. Literal Expressions 8.3.4.8.2 CollectExpression Description A CollectExpression is an OperatorExpression whose operator is "collect" , which resolves to the Function ControlFunctions::collect from the Kernel Functions Library. General Classes OperatorExpression 202 Kernel Modeling Language v1.0 -Attributes operator : String {redefines operator} Operations None. Constraints validateCollectExpressionOperator The operator of a CollectExpression must be "collect" . operator = 'collect' 8.3.4.8.3 ConstructorExpression Description A ConstructorExpression is an InstantiationExpression whose result specializes its instantiatedType , binding some or all of the features of the instantiatedType to the results of its argument Expressions . General Classes InstantiationExpression Attributes None. Operations modelLevelEvaluable(visited : Feature [0..*]) : Boolean {redefines modelLevelEvaluable} A ConstructorExpression is model-level evaluable if all its argument Expressions are model-level evaluable. body: argument->forAll(modelLevelEvaluable(visited)) Constraints checkConstructorExpressionResultDefaultValueBindingConnector The result of a ConstructorExpression must own a BindingConnector between the featureWithValue and value Expression of any FeatureValue that is the effective default value for a feature of the instantiatedType of the InvocationExpression . TBD checkConstructorExpressionResultFeatureRedefinition Each ownedFeature of the result of a ConstructionExpression must redefine exactly one public feature of the instantiatedType of the ConstructorExpression . let features : OrderedSet(Feature) = instantiatedType.feature-> select(owningMembership.visibility = VisibilityKind::public) in Kernel Modeling Language v1.0 203 -result.ownedFeature->forAll(f | f.ownedRedefinition.redefinedFeature-> intersection(features)->size() = 1) checkConstructorExpressionResultSpecialization The result of a ConstructorExpression must specialize the instantiatedType of the ConstructorExpression . result.specializes(instantiatedType) checkConstructorExpressionSpecialization A ConstructorExpression must directly or indirectly specialize the Expression Performances::constructorEvaluations from the Kernel Semantic Library. specializes('Performances::constructorEvaluations') deriveConstructorExpressionArgument The arguments of a ConstructorExpression are the value Expressions of the FeatureValues of the ownedFeatures of its result parameter, in an order corresponding to the order of the features of the instantiatedType that the result ownedFeatures redefine. instantiatedType.feature->collect(f | result.ownedFeatures->select(redefines(f)).valuation-> select(v | v <> null).value ) validateConstructorExpressionNoDuplicateFeatureRedefinition Two different ownedFeatures of the result of a ConstructorExpression must not redefine the same feature of the instantiatedType of the ConstructorExpression . let features : OrderedSet(Feature) = instantiatedType.feature-> select(visibility = VisibilityKind::public) in result.ownedFeature->forAll(f1 | result.ownedFeature->forAll(f2 | f1 <> f2 implies f1.ownedRedefinition.redefinedFeature-> intersection(f2.ownedRedefinition.redefinedFeature)-> intersection(features)->isEmpty())) validateConstructorExpressionOwnedFeatures A ConstructorExpression must not have any ownedFeatures other than its result . ownedFeatures->excluding(result)->isEmpty() 8.3.4.8.4 FeatureChainExpression Description A FeatureChainExpression is an OperatorExpression whose operator is "." , which resolves to the Function ControlFunctions::'.' from the Kernel Functions Library. It evaluates to the result of chaining the result Feature of its single argument Expression with its targetFeature . 204 Kernel Modeling Language v1.0 -General Classes OperatorExpression Attributes operator : String {redefines operator} /targetFeature : Feature {subsets member} The Feature that is accessed by this FeatureChainExpression, which is its first non-parameter member. Operations sourceTargetFeature() : Feature [0..1] Return the first ownedFeature of the first owned input parameter of this FeatureChainExpression (if any). body: let inputParameters : Feature = ownedFeatures-> select(direction = _'in') in if inputParameters->isEmpty() or inputParameters->first().ownedFeature->isEmpty() then null else inputParameters->first().ownedFeature->first() endif Constraints checkFeatureChainExpressionResultSpecialization The result parameter of a FeatureChainExpression must specialize the feature chain of the FeatureChainExpression . let inputParameters : Sequence(Feature) = ownedFeatures->select(direction = _'in') in let sourceTargetFeature : Feature = owningExpression.sourceTargetFeature() in sourceTargetFeature <> null and result.subsetsChain(inputParameters->first(), sourceTargetFeature) and result.owningType = self checkFeatureChainExpressionSourceTargetRedefinition The first ownedFeature of the first owned input parameter of a FeatureChainExpression must redefine its targetFeature . let sourceParameter : Feature = sourceTargetFeature() in sourceTargetFeature <> null and sourceTargetFeature.redefines(targetFeature) checkFeatureChainExpressionTargetRedefinition The first ownedFeature of the first owned input parameter of a FeatureChainExpression must redefine the Feature ControlFunctions::'.'::source::target from the Kernel Functions Library. Kernel Modeling Language v1.0 205 -let sourceParameter : Feature = sourceTargetFeature() in sourceTargetFeature <> null and sourceTargetFeature.redefinesFromLibrary('ControlFunctions::\'.\'::source::target') deriveFeatureChainExpressionTargetFeature The targetFeature of a FeatureChainExpression is the memberElement of its first ownedMembership that is not a ParameterMembership . targetFeature = let nonParameterMemberships : Sequence(Membership) = ownedMembership-> reject(oclIsKindOf(ParameterMembership)) in if nonParameterMemberships->isEmpty() or not nonParameterMemberships->first().memberElement.oclIsKindOf(Feature) then null else nonParameterMemberships->first().memberElement.oclAsType(Feature) endif validateFeatureChainExpressionConformance The targetFeature of a FeatureChainExpression must be featured within the result parameter of the argument Expression of the FeatureChainExpression . argument->notEmpty() implies targetFeature.isFeaturedWithin(argument->first().result) validateFeatureChainExpressionOperator The operator of a FeatureChainExpression must be "." . operator = '.' 8.3.4.8.5 FeatureReferenceExpression Description A FeatureReferenceExpression is an Expression whose result is bound to a referent Feature . General Classes Expression Attributes /referent : Feature {subsets member} The Feature that is referenced by this FeatureReferenceExpression , which is its first non- parameter member . Operations evaluate(target : Element) : Element [0..*] {redefines evaluate} First, determine a value Expression for the referent : • If the target Element is a Type that has a feature that is the referent or (directly or indirectly) redefines it, then the value Expression of the FeatureValue for that feature (if any). 206 Kernel Modeling Language v1.0 -• Else, if the referent has no featuringTypes , the value Expression of the FeatureValue for the referent (if any). Then: • If such a value Expression exists, return the result of evaluating that Expression on the target . • Else, if the referent is not an Expression , return the referent . • Else return the empty sequence. body: if not target.oclIsKindOf(Type) then Sequence{} else let feature: Sequence(Feature) = target.oclAsType(Type).feature->select(f | f.ownedRedefinition.redefinedFeature-> includes(referent)) in if feature->notEmpty() then feature.valuation.value.evaluate(target) else if referent.featuringType->isEmpty() then referent else Sequence{} endif endif endif modelLevelEvaluable(visited : Feature [0..*]) : Boolean {redefines modelLevelEvaluable} A FeatureReferenceExpression is model-level evaluable if it's referent • conforms to the self-reference feature Anything::self ; • is an Expression that is model-level evaluable; • has an owningType that is a Metaclass or MetadataFeature ; or • has no featuringTypes and, if it has a FeatureValue , the value Expression is model-level evaluable. body: referent.conformsTo('Anything::self') or visited->excludes(referent) and (referent.oclIsKindOf(Expression) and referent.oclAsType(Expression).modelLevelEvaluable(visited->including(referent)) or referent.owningType <> null and (referent.owningType.isOclKindOf(MetaClass) or referent.owningType.isOclKindOf(MetadataFeature)) or referent.featuringType->isEmpty() and (referent.valuation = null or referent.valuation.modelLevelEvaluable(visited->including(referent)))) Constraints checkFeatureReferenceExpressionBindingConnector A FeatureReferenceExpression must have an ownedMember that is a BindingConnector between the referent and result of the FeatureReferenceExpression . ownedMember->selectByKind(BindingConnector)->exists(b | b.relatedFeatures->includes(targetFeature) and b.relatedFeatures->includes(result)) checkFeatureReferenceExpressionResultSpecialization The result parameter of a FeatureReferenceExpression must specialize the referent of the FeatureReferenceExpression . Kernel Modeling Language v1.0 207 -result.owningType() = self and result.specializes(referent) deriveFeatureReferenceExpressionReferent The referent of a FeatureReferenceExpression is the memberElement of its first ownedMembership that is not a ParameterMembership . referent = let nonParameterMemberships : Sequence(Membership) = ownedMembership-> reject(oclIsKindOf(ParameterMembership)) in if nonParameterMemberships->isEmpty() or not nonParameterMemberships->first().memberElement.oclIsKindOf(Feature) then null else nonParameterMemberships->first().memberElement.oclAsType(Feature) endif validateFeatureReferenceExpressionReferentIsFeature The first ownedMembership of a FeatureReferenceExpression that is not a ParameterMembership must have a Feature as its memberElement . let membership : Membership = ownedMembership->reject(m | m.oclIsKindOf(ParameterMembership)) in membership->notEmpty() and membership->at(1).memberElement.oclIsKindOf(Feature) validateFeatureReferenceExpressionResult A FeatureReferenceExpression must own its result parameter. result.owningType = self 8.3.4.8.6 IndexExpression Description An IndexExpression is an OperatorExpression whose operator is "#" , which resolves to the Function BasicFunctions::'#' from the Kernel Functions Library. General Classes OperatorExpression Attributes operator : String {redefines operator} Operations None. Constraints checkIndexExpressionResultSpecialization The result of an IndexExpression must specialize the result parameter of the first argument of the IndexExpression , unless that result already directly or indirectly specializes the DataType Collections::Array from the Kernel Data Type Library. 208 Kernel Modeling Language v1.0 -arguments->notEmpty() and not arguments->first().result.specializesFromLibrary('Collections::Array') implies result.specializes(arguments->first().result) validateIndexExpressionOperator The operator of an IndexExpression must be "#" . operator = '#' 8.3.4.8.7 InstantiationExpression Description An InstantiationExpression is an Expression that instantiates its instantiatedType , binding some or all of the features of that Type to the results of its arguments . InstantiationExpression is abstract, with concrete subclasses InvocationExpression and ConstructorExpression . General Classes Expression Attributes /argument : Expression [0..*] {ordered} The Expressions whose results are bound to features of the instantiatedType . The arguments are ordered consistent with the order of the features , though they may not be one-to-one with all the features . Note. The derivation of argument is given in the concrete subclasses of InstantiationExpression . /instantiatedType : Type {subsets member} The Type that is being instantiated. Operations instantiatedType() : Type [0..1] Return the Type to act as the instantiatedType for this InstantiationExpression . By default, this is the memberElement of the first ownedMembership that is not a FeatureMembership , which must be a Type . Note. This operation is overridden in the subclass OperatorExpression . body: let members : Sequence(Element) = ownedMembership-> reject(oclIsKindOf(FeatureMembership)).memberElement in if members->isEmpty() or not members->first().oclIsKindOf(Type) then null else typeMembers->first().oclAsType(Type) endif Kernel Modeling Language v1.0 209 -Constraints deriveInstantiationExpressionInstantiatedType The instantiatedType of an InstantiationExpression is given by the result of the instantiatedType() operation. instantiatedType = instantiatedType() validateInstantiationExpressionInstantiatedType An InstantiationExpression must have an InstantiatedType . instantiatedType() <> null validateInstantiationExpressionResult An InstantiationExpression must own its result parameter. result.owningType = self 8.3.4.8.8 InvocationExpression Description An InvocationExpression is an InstantiationExpression whose instantiatedType must be a Behavior or a Feature typed by a single Behavior (such as a Step ). Each of the input parameters of the instantiatedType are bound to the result of an argument Expression . If the instantiatedType is a Function or a Feature typed by a Function , then the result of the InvocationExpression is the result of the invoked Function . Otherwise, the result is an instance of the instantiatedType (essentially like a behavioral ConstructorExpression ). General Classes InstantiationExpression Attributes None. Operations evaluate(target : Element) : Element [0..*] {redefines evaluate} Apply the Function that is the type of this InvocationExpression to the argument values resulting from evaluating each of the argument Expressions on the given target . If the application is not possible, then return an empty sequence. modelLevelEvaluable(visited : Feature [0..*]) : Boolean {redefines modelLevelEvaluable} An InvocationExpression is model-level evaluable if all its argument Expressions are model-level evaluable and its function is model-level evaluable. body: argument->forAll(modelLevelEvaluable(visited)) and function.isModelLevelEvaluable 210 Kernel Modeling Language v1.0 -Constraints checkInvocationExpressionBehaviorBindingConnector If the instantiatedType of an InvocationExpression is neither a Function nor a Feature whose type is a Function , then the InvocationExpression must own a BindingConnector between itself and its result parameter. not instantiatedType.oclIsKindOf(Function) and not (instantiatedType.oclIsKindOf(Feature) and instantiatedType.oclAsType(Feature).type->exists(oclIsKindOf(Function))) implies ownedFeature.selectByKind(BindingConnector)->exists( relatedFeature->includes(self) and relatedFeature->includes(result)) checkInvocationExpressionBehaviorResultSpecialization If the instantiatedType of an InvocationExpression is neither a Function nor a Feature whose type is a Function , then the result of the InvocationExpression must specialize the instantiatedType . not instantiatedType.oclIsKindOf(Function) and not (instantiatedType.oclIsKindOf(Feature) and instantiatedType.oclAsType(Feature).type->exists(oclIsKindOf(Function))) implies result.specializes(instantiatedType) checkInvocationExpressionDefaultValueBindingConnector An InvocationExpression must own a BindingConnector between the featureWithValue and value Expression of any FeatureValue that is the effective default value for a feature of the instantiatedType of the InvocationExpression . TBD checkInvocationExpressionSpecialization An InvocationExpression must specialize its instantiatedType . specializes(instantiatedType) deriveInvocationExpressionArgument The arguments of an InvocationExpression are the value Expressions of the FeatureValues of its ownedFeatures , in an order corresponding to the order of the input parameters of the instantiatedType that the ownedFeatures redefine. instantiatedType.input->collect(inp | ownedFeatures->select(redefines(inp)).valuation-> select(v | v <> null).value ) validateInvocationExpressionInstantiatedType The instantiatedType of an InvocationExpression must be either a Behavior or a Feature with a single type , which is a Behavior . instantiatedType.oclIsKindOf(Behavior) or instantiatedType.oclIsKindOf(Feature) and Kernel Modeling Language v1.0 211 -instantiatedType.type->exists(oclIsKindOf(Behavior)) and instantiatedType.type->size(1) validateInvocationExpressionNoDuplicateParameterRedefinition Two different ownedFeatures of an InvocationExpression must not redefine the same feature of the instantiatedType of the InvocationExpression . let features : OrderedSet(Feature) = instantiatedType.feature in input->forAll(inp1 | input->forAll(inp2 | inp1 <> inp2 implies inp1.ownedRedefinition.redefinedFeature-> intersection(inp2.ownedRedefinition.redefinedFeature)-> intersection(features)->isEmpty())) validateInvocationExpressionOwnedFeatures Other than its result , all the ownedFeatures of an InvocationExpression must have direction = in . ownedFeature->forAll(f | f <> result implies f.direction = FeatureDirectionKind::_'in') validateInvocationExpressionParameterRedefinition Each input parameter of an InvocationExpression must redefine exactly one input parameter of the instantiatedType of the InvocationExpression . let parameters : OrderedSet(Feature) = instantiatedType.input in input->forAll(inp | inp.ownedRedefinition.redefinedFeature-> intersection(parameters)->size() = 1) 8.3.4.8.9 LiteralBoolean Description LiteralBoolean is a LiteralExpression that provides a Boolean value as a result. Its result parameter must have type Boolean . General Classes LiteralExpression Attributes value : Boolean The Boolean value that is the result of evaluating this LiteralBoolean . The Boolean value that is the result of evaluating this Expression. Operations None. 212 Kernel Modeling Language v1.0 -Constraints checkLiteralBooleanSpecialization A LiteralBoolean must directly or indirectly specialize Performances::literalBooleanEvaluations from the Kernel Semantic Library. specializesFromLibrary('Performances::literalBooleanEvaluations') 8.3.4.8.10 LiteralExpression Description A LiteralExpression is an Expression that provides a basic DataValue as a result. General Classes Expression Attributes None. Operations evaluate(target : Element) : Element [0..*] {redefines evaluate} The model-level value of a LiteralExpression is itself. body: Sequence{self} modelLevelEvaluable(visited : Feature [0..*]) : Boolean {redefines modelLevelEvaluable} A LiteralExpression is always model-level evaluable. body: true Constraints checkLiteralExpressionSpecialization A LiteralExpression must directly or indirectly specialize the base LiteralExpression Performances::literalEvaluations from the Kernel Semantic Library. specializesFromLibrary('Performances::literalEvaluations') deriveLiteralExpressionIsModelLevelEvaluable A LiteralExpression is always model-level evaluable. isModelLevelEvaluable = true Kernel Modeling Language v1.0 213 -8.3.4.8.11 LiteralInfinity Description A LiteralInfinity is a LiteralExpression that provides the positive infinity value ( * ). It's result must have the type Positive . General Classes LiteralExpression Attributes None. Operations None. Constraints checkLiteralInfinitySpecialization A LiteralInfinity must directly or indirectly specialize Performances::literalIntegerEvaluations from the Kernel Semantic Library. specializesFromLibrary('Performances::literalIntegerEvaluations') 8.3.4.8.12 LiteralInteger Description A LiteralInteger is a LiteralExpression that provides an Integer value as a result. Its result parameter must have the type Integer . General Classes LiteralExpression Attributes value : Integer The Integer value that is the result of evaluating this LiteralInteger . The Integer value that is the result of evaluating this Expression. Operations None. Constraints checkLiteralIntegerSpecialization A LiteralInteger must directly or indirectly specialize Performances::literalIntegerEvaluations from the Kernel Semantic Library. 214 Kernel Modeling Language v1.0 -specializesFromLibrary('Performances::literalIntegerEvaluations') 8.3.4.8.13 LiteralRational Description A LiteralRational is a LiteralExpression that provides a Rational value as a result. Its result parameter must have the type Rational . General Classes LiteralExpression Attributes value : Real The Real value that is the result of evaluating this Expression. The value whose rational approximation is the result of evaluating this LiteralRational . Operations None. Constraints checkLiteralRationalSpecialization A LiteralRational must directly or indirectly specialize Performances::literalRationalEvaluations from the Kernel Semantic Library. specializesFromLibrary('Performances::literalRationalEvaluations') 8.3.4.8.14 LiteralString Description A LiteralString is a LiteralExpression that provides a String value as a result. Its result parameter must have the type String . General Classes LiteralExpression Attributes value : String The String value that is the result of evaluating this LiteralString . The String value that is the result of evaluating this Expression. Operations None. Kernel Modeling Language v1.0 215 -Constraints checkLiteralStringSpecialization A LiteralString must directly or indirectly specialize Performances::literalStringEvaluations from the Kernel Semantic Library. specializesFromLibrary('Performances::literalStringEvaluations') 8.3.4.8.15 MetadataAccessExpression Description A MetadataAccessExpression is an Expression whose result is a sequence of instances of Metaclasses representing all the MetadataFeature annotations of the referencedElement . In addition, the sequence includes an instance of the reflective Metaclass corresponding to the MOF class of the referencedElement , with values for all the abstract syntax properties of the referencedElement . General Classes Expression Attributes /referencedElement : Element {subsets member} The Element whose metadata is being accessed. Operations evaluate(target : Element) : Element [0..*] {redefines evaluate} Return the ownedElements of the referencedElement that are MetadataFeatures and have the referencedElement as an annotatedElement , plus a MetadataFeature whose annotatedElement is the referencedElement , whose metaclass is the reflective Metaclass corresponding to the MOF class of the referencedElement and whose ownedFeatures are bound to the values of the MOF properties of the referencedElement . body: referencedElement.ownedElement-> select(oclIsKindOf(MetadataFeature) and annotatedElement->includes(referencedElement))-> including(metaclassFeature()) metaclassFeature() : MetadataFeature Return a MetadataFeature whose annotatedElement is the referencedElement , whose metaclass is the reflective Metaclass corresponding to the MOF class of the referencedElement and whose ownedFeatures are bound to the MOF properties of the referencedElement . modelLevelEvaluable(visited : Feature [0..*]) : Boolean {redefines modelLevelEvaluable} A MetadataAccessExpression is always model-level evaluable. body: true 216 Kernel Modeling Language v1.0 -Constraints checkMetadataAccessExpressionSpecialization A MetadataAccessExpression must directly or indirectly specialize the base MetadataAccessExpression Performances::metadataAccessEvaluations from the Kernel Semantic Library. specializesFromLibrary('Performances::metadataAccessEvaluations') deriveMetadataAccessExpressionReferencdElement The referencedElement of a MetadataAccessExpression is the memberElement of its first ownedMembership that is not a FeatureMembership . referencedElement = let elements : Sequence(Element) = ownedMembership-> reject(oclIsKindOf(FeatureMembership)).memberElement in if elements->isEmpty() then null else elements->first() endif validateMetadataAccessExpressionReferencedElement A MetadataAccessExpression must have at least one ownedMember that is not a FeatureMembership . ownedMembership->exists(not oclIsKindOf(FeatureMembership)) 8.3.4.8.16 NullExpression Description A NullExpression is an Expression that results in a null value. General Classes Expression Attributes None. Operations evaluate(target : Element) : Element [0..*] {redefines evaluate} The model-level value of a NullExpression is an empty sequence. body: Sequence{} modelLevelEvaluable(visited : Feature [0..*]) : Boolean {redefines modelLevelEvaluable} A NullExpression is always model-level evaluable. body: true Kernel Modeling Language v1.0 217 -Constraints checkNullExpressionSpecialization A NullExpression must directly or indirectly specialize the base NullExpression Performances::nullEvaluations from the Kernel Semantic Library. specializesFromLibrary('Performances::nullEvaluations') 8.3.4.8.17 OperatorExpression Description An OperatorExpression is an InvocationExpression whose function is determined by resolving its operator in the context of one of the standard packages from the Kernel Function Library. General Classes InvocationExpression Attributes operator : String An operator symbol that names a corresponding Function from one of the standard packages from the Kernel Function Library . Operations instantiatedType() : Type {redefines instantiatedType} The instantiatedType of an OperatorExpression is the resolution of it's operator from one of the packages BaseFunctions , DataFunctions , or ControlFunctions from the Kernel Function Library. body: let libFunctions : Sequence(Element) = Sequence{'BaseFunctions', 'DataFunctions', 'ControlFunctions'}-> collect(ns | resolveGlobal(ns + "::'" + operator + "'"). memberElement) in if libFunctions->isEmpty() then null else libFunctions->first().oclAsType(Type) endif Constraints None. 8.3.4.8.18 SelectExpression Description A SelectExpression is an OperatorExpression whose operator is "select" , which resolves to the Function ControlFunctions::select from the Kernel Functions Library. General Classes OperatorExpression 218 Kernel Modeling Language v1.0 -Attributes operator : String {redefines operator} Operations None. Constraints checkSelectExpressionResultSpecialization The result of a SelectExpression must specialize the result parameter of the first argument of the SelectExpression . arguments->notEmpty() implies result.specializes(arguments->first().result) validateSelectExpressionOperator The operator of a SelectExpression must be 'select' . operator = 'select' 8.3.4.9 Interactions Abstract Syntax 8.3.4.9.1 Overview Behavior Association Interaction Figure 35. Interactions Kernel Modeling Language v1.0 219 -Connector Step +/interaction +/typedFlow Succession Flow Interaction 0..* 0..* {subsets typedConnector, {redefines association, subsets typedStep} redefines behavior, ordered} +/flowForPayloadType +/payloadType Classifier 0..* 0..* {ordered, nonunique} +/flowWithPayloadFeature +/payloadFeature PayloadFeature 0..1 0..1 {subsets owningType} {subsets ownedFeature} +/flowFromOutput +/sourceOutputFeature Feature 0..* 0..1 {ordered, nonunique} +/flowToInput +/targetInputFeature 0..* 0..1 {ordered, nonunique} +/featuringFlow +/flowEnd FlowEnd 0..* 0..2 {subsets featuringConnector} {subsets connectorEnd, ordered} SuccessionFlow Figure 36. Flows 8.3.4.9.2 Flow Description An Flow is a Step that represents the transfer of values from one Feature to another. Flows can take non-zero time to complete. General Classes Step Connector Attributes /flowEnd : FlowEnd [0..2] {subsets connectorEnd, ordered} The connectorEnds of this Flow that are FlowEnds . /interaction : Interaction [0..*] {redefines association, behavior, ordered} 220 Kernel Modeling Language v1.0 -The Interactions that type this Flow . Interactions are both Associations and Behaviors , which can type Connectors and Steps , respectively. /payloadFeature : PayloadFeature [0..1] {subsets ownedFeature} The ownedFeature of the Flow that is a PayloadFeature (if any). /payloadType : Classifier [0..*] {ordered, nonunique} The type of values transferred, which is the type of the payloadFeature of the Flow . /sourceOutputFeature : Feature [0..1] {ordered, nonunique} The Feature that provides the items carried by the Flow . It must be a feature of the source of the Flow . /targetInputFeature : Feature [0..1] {ordered, nonunique} The Feature that receives the values carried by the Flow . It must be a feature of the target of the Flow . Operations None. Constraints checkFlowSpecialization A Flow must directly or indirectly specialize the Step Transfers::transfers from the Kernel Semantic Library. specializesFromLibrary('Transfers::transfers') checkFlowWithEndsSpecialization A Flow with ownedEndFeatures must specialize the Step Transfers::flowTransfers from the Kernel Semantic Library. ownedEndFeatures->notEmpty() implies specializesFromLibrary('Transfers::flowTransfers') deriveFlowFlowEnd The flowEnds of a Flow are all its connectorEnds that are FlowEnds . flowEnd = connectorEnd->selectByKind(FlowEnd) deriveFlowPayloadFeature The payloadFeature of a Flow is the single one of its ownedFeatures that is a PayloadFeature . payloadFeature = let payloadFeatures : Sequence(PayloadFeature) = ownedFeature->selectByKind(PayloadFeature) in if payloadFeatures->isEmpty() then null else payloadFeatures->first() endif Kernel Modeling Language v1.0 221 -deriveFlowPayloadType The payloadTypes of a Flow are the types of the payloadFeature of the Flow (if any). payloadType = if payloadFeature = null then Sequence{} else payloadFeature.type endif deriveFlowSourceOutputFeature The sourceOutputFeature of a Flow is the first ownedFeature of the first connectorEnd of the Flow . sourceOutputFeature = if connectorEnd->isEmpty() or connectorEnd.ownedFeature->isEmpty() then null else connectorEnd.ownedFeature->first() endif deriveFlowTargetInputFeature The targetInputFeature of a Flow is the first ownedFeature of the second connectorEnd of the Flow . targetInputFeature = if connectorEnd->size() < 2 or connectorEnd->at(2).ownedFeature->isEmpty() then null else connectorEnd->at(2).ownedFeature->first() endif validateFlowPayloadFeature A Flow must have at most one ownedFeature that is an PayloadFeature . ownedFeature->selectByKind(PayloadFeature)->size() <= 1 8.3.4.9.3 FlowEnd Description A FlowEnd is a Feature that is one of the connectorEnds giving the source or target of a Flow . For Flows typed by FlowTransfer or its specializations, FlowEnds must have exactly one ownedFeature , which redefines Transfer::source::sourceOutput or Transfer::target::targetInput and redefines the corresponding feature of the relatedElement for its end. General Classes Feature Attributes None. Operations None. 222 Kernel Modeling Language v1.0 -Constraints validateFlowEndIsEnd A FlowEnd must be an end Feature . isEnd validateFlowEndNestedFeature A FlowEnd must have exactly one ownedFeature . ownedFeature->size() = 1 validateFlowEndOwningType The owningType of a FlowEnd must be a Flow . owningType <> null and owningType.oclIsKindOf(Flow) 8.3.4.9.4 Interaction Description An Interaction is a Behavior that is also an Association , providing a context for multiple objects that have behaviors that impact one another. General Classes Behavior Association Attributes None. Operations None. Constraints None. 8.3.4.9.5 PayloadFeature Description A PayloadFeature is the ownedFeature of a Flow that identifies the things carried by the kinds of transfers that are instances of the Flow . General Classes Feature Kernel Modeling Language v1.0 223 -Attributes None. Operations None. Constraints checkPayloadFeatureRedefinition A PayloadFeature must redefine the Feature Transfers::Transfer::payload from the Kernel Semantic Library. redefinesFromLibrary('Transfers::Transfer::payload') 8.3.4.9.6 SuccessionFlow Description A SuccessionFlow is a Flow that also provides temporal ordering. It classifies Transfers that cannot start until the source Occurrence has completed and that must complete before the target Occurrence can start. General Classes Flow Succession Attributes None. Operations None. Constraints checkSuccessionFlowSpecialization A SuccessionFlow must directly or indirectly specialize the Step Transfers::flowTransfersBefore from the Kernel Semantic Library. specializesFromLibrary('Transfers::flowTransfersBefore') 224 Kernel Modeling Language v1.0 -8.3.4.10 Feature Values Abstract Syntax 8.3.4.10.1 Overview OwningMembership {subsets ownedMembership} FeatureValue +/featureWithValue +/valuation +/expressedValuation +/value Feature Expression +isInitial : Boolean = false 1 0..1 0..1 1 +isDefault : Boolean = false {subsets {subsets {redefines membershipOwningNamespace} owningMembership} ownedMemberElement} Figure 37. Feature Values 8.3.4.10.2 FeatureValue Description A FeatureValue is a Membership that identifies a particular member Expression that provides the value of the Feature that owns the FeatureValue . The value is specified as either a bound value or an initial value, and as either a concrete or default value. A Feature can have at most one FeatureValue . The result of the value Expression is bound to the featureWithValue using a BindingConnector . If isInitial = false , then the featuringType of the BindingConnector is the same as the featuringType of the featureWithValue . If isInitial = true , then the featuringType of the BindingConnector is restricted to its startShot . If isDefault = false , then the above semantics of the FeatureValue are realized for the given featureWithValue . Otherwise, the semantics are realized for any individual of the featuringType of the featureWithValue , unless another value is explicitly given for the featureWithValue for that individual. General Classes OwningMembership Attributes /featureWithValue : Feature {subsets membershipOwningNamespace} The Feature to be provided a value. The Feature to be provided a value. isDefault : Boolean Whether this FeatureValue is a concrete specification of the bound or initial value of the featureWithValue , or just a default value that may be overridden. isInitial : Boolean Whether this FeatureValue specifies a bound value or an initial value for the featureWithValue . /value : Expression {redefines ownedMemberElement} The Expression that provides the value of the featureWithValue as its result . Kernel Modeling Language v1.0 225 -The Expression that provides the value as a result. Operations None. Constraints checkFeatureValueBindingConnector If isDefault = false , then the featureWithValue must have an ownedMember that is a BindingConnector whose relatedElements are the featureWithValue and a feature chain consisting of the value Expression and its result . If isInitial = false , then this BindingConnector must have featuringTypes that are the same as those of the featureWithValue . If isInitial = true , then the BindingConnector must have that.startShot as its featuringType. not isDefault implies featureWithValue.ownedMember-> selectByKind(BindingConnector)->exists(b | b.relatedFeature->includes(featureWithValue) and b.relatedFeature->exists(f | f.chainingFeature = Sequence{value, value.result}) and if not isInitial then b.featuringType = featureWithValue.featuringType else b.featuringType->exists(t | t.oclIsKindOf(Feature) and t.oclAsType(Feature).chainingFeature = Sequence{ resolveGlobal('Base::things::that'). memberElement, resolveGlobal('Occurrences::Occurrence::startShot'). memberElement } ) endif) validateFeatureValueIsInitial If a FeatureValue has isInitial = true , then its featureWithValue must have isVariable = true . isInitial implies featureWithValue.isVariable validateFeatureValueOverriding All Features directly or indirectly redefined by the featureWithValue of a FeatureValue must have only default FeatureValues . featureWithValue.redefinition.redefinedFeature-> closure(redefinition.redefinedFeature).valuation-> forAll(isDefault) 226 Kernel Modeling Language v1.0 -8.3.4.11 Multiplicities Abstract Syntax 8.3.4.11.1 Overview Multiplicity {subsets owningType} MultiplicityRange +/multiplicity +hasBounds( lower : Integer, upper : UnlimitedNatural ) : Boolean 0..1 +valueOf( bound : Expression [0..1] ) : UnlimitedNatural [0..1] +/multiplicity 0..1 +/multiplicity 0..1 {subsets {subsets multiplicity} multiplicity} {subsets bound} {subsets bound} +/lowerBound 0..1 +/upperBound 1 +/bound Expression 1..2 {subsets ownedMember, ordered} Figure 38. Multiplicities 8.3.4.11.2 MultiplicityRange Description A MultiplicityRange is a Multiplicity whose value is defined to be the (inclusive) range of natural numbers given by the result of a lowerBound Expression and the result of an upperBound Expression . The result of these Expressions shall be of type Natural . If the result of the upperBound Expression is the unbounded value * , then the specified range includes all natural numbers greater than or equal to the lowerBound value. If no lowerBound Expression , then the default is that the lower bound has the same value as the upper bound, except if the upperBound evaluates to * , in which case the default for the lower bound is 0. General Classes Multiplicity Attributes /bound : Expression [1..2] {subsets ownedMember, ordered} The owned Expressions of the MultiplicityRange whose results provide its bounds. These must be the first ownedMembers of the MultiplicityRange . /lowerBound : Expression [0..1] {subsets bound} The Expression whose result provides the lower bound of the MultiplicityRange . If no lowerBound Expression is given, then the lower bound shall have the same value as the upper bound, unless the upper bound is unbounded ( * ), in which case the lower bound shall be 0. /upperBound : Expression {subsets bound} The Expression whose result is the upper bound of the MultiplicityRange . Kernel Modeling Language v1.0 227 -Operations hasBounds(lower : Integer, upper : UnlimitedNatural) : Boolean Check whether this MultiplicityRange represents the range bounded by the given values lower and upper , presuming the lowerBound and upperBound Expressions are model-level evaluable. body: valueOf(upperBound) = upper and let lowerValue: UnlimitedNatural = valueOf(lowerBound) in (lowerValue = lower or lowerValue = null and (lower = upper or lower = 0 and upper = *)) valueOf(bound : Expression [0..1]) : UnlimitedNatural [0..1] Evaluate the given bound Expression (at model level) and return the result represented as a MOF UnlimitedNatural value. body: if bound = null or not bound.isModelLevelEvaluable then null else let boundEval: Sequence(Element) = bound.evaluate(owningType) in if boundEval->size() <> 1 then null else let valueEval: Element = boundEval->at(1) in if valueEval.oclIsKindOf(LiteralInfinity) then * else if valueEval.oclIsKindOf(LiteralInteger) then let value : Integer = valueEval.oclAsKindOf(LiteralInteger).value in if value >= 0 then value else null endif else null endif endif endif endif Constraints checkMultiplicityRangeExpressionTypeFeaturing The bounds of a MultiplicityRange must have the same featuringTypes as the MultiplicityRange . bound->forAll(b | b.featuringType = self.featuringType) deriveMultiplicityRangeBound The bounds of a MultiplicityRange are the lowerBound (if any) followed by the upperBound . bound = if upperBound = null then Sequence{} else if lowerBound = null then Sequence{upperBound} else Sequence{lowerBound, upperBound} endif endif deriveMultiplicityRangeLowerBound If a MultiplicityRange has two ownedMembers that are Expressions , then the lowerBound is the first of these, otherwise it is null . 228 Kernel Modeling Language v1.0 -lowerBound = let ownedExpressions : Sequence(Expression) = ownedMember->selectByKind(Expression) in if ownedExpressions->size() < 2 then null else ownedExpressions->first() endif deriveMultiplicityRangeUpperBound If a MultiplicityRange has one ownedMember that is an Expression , then this is the upperBound . If it has more than one ownedMember that is an Expression , then the upperBound is the second of those. Otherwise, it is null. upperBound = let ownedExpressions : Sequence(Expression) = ownedMember->selectByKind(Expression) in if ownedExpressions->isEmpty() then null else if ownedExpressions->size() = 1 then ownedExpressions->at(1) else ownedExpressions->at(2) endif endif validateMultiplicityRangeBoundResultTypes The results of the bound Expression(s) of a MultiplicityRange must be typed by ScalarValues::Intger from the Kernel Data Types Library. If a bound is model-level evaluable, then it must evaluate to a non-negative value. bound->forAll(b | b.result.specializesFromLibrary('ScalarValues::Integer') and let value : UnlimitedNatural = valueOf(b) in value <> null implies value >= 0 ) validateMultiplicityRangeBounds The lowerBound (if any) and upperBound Expressions must be the first ownedMembers of a MultiplicityRange . if lowerBound = null then ownedMember->notEmpty() and ownedMember->at(1) = upperBound else ownedMember->size() > 1 and ownedMember->at(1) = lowerBound and ownedMember->at(2) = upperBound endif Kernel Modeling Language v1.0 229 -8.3.4.12 Metadata Abstract Syntax 8.3.4.12.1 Overview Feature Structure MetadataFeature +evaluateFeature( baseFeature : Feature ) : Element [0..*] +/metaclass +/typedMetadata +isSemantic() : Boolean Metaclass 0..1 0..* +isSyntactic() : Boolean +syntaxElement() : Element [0..1] {subsets type} {subsets typedFeature} AnnotatingElement Figure 39. Metadata Annotation 8.3.4.12.2 Metaclass Description A Metaclass is a Structure used to type MetadataFeatures . General Classes Structure Attributes None. Operations None. Constraints checkMetaclassSpecialization A Metaclass must directly or indirectly specialize the base Metaclass Metaobjects::Metaobject from the Kernel Semantic Library. specializesFromLibrary('Metaobjects::Metaobject') 8.3.4.12.3 MetadataFeature Description A MetadataFeature is a Feature that is an AnnotatingElement used to annotate another Element with metadata. It is typed by a Metaclass . All its ownedFeatures must redefine features of its metaclass and any feature bindings must be model-level evaluable. 230 Kernel Modeling Language v1.0 -General Classes AnnotatingElement Feature Attributes /metaclass : Metaclass [0..1] {subsets type} The type of this MetadataFeature , which must be a Metaclass . Operations evaluateFeature(baseFeature : Feature) : Element [0..*] If the given baseFeature is a feature of this MetadataFeature , or is directly or indirectly redefined by a feature , then return the result of evaluating the appropriate (model-level evaluable) value Expression for it (if any), with the MetadataFeature as the target. body: let selectedFeatures : Sequence(Feature) = feature-> select(closure(ownedRedefinition.redefinedFeature)-> includes(baseFeature)) in if selectedFeatures->isEmpty() then null else let selectedFeature : Feature = selectedFeatures->first() in let featureValues : FeatureValue = selectedFeature-> closure(ownedRedefinition.redefinedFeature).ownedMember-> selectAsKind(FeatureValue) in if featureValues->isEmpty() then null else featureValues->first().value.evaluate(self) endif isSemantic() : Boolean Check if this MetadataFeature has a metaclass which is a kind of SemanticMetadata . body: specializesFromLibrary('Metaobjects::SemanticMetadata') isSyntactic() : Boolean Check if this MetadataFeature has a metaclass that is a kind of KerML::Element (that is, it is from the reflective abstract syntax model). body: specializesFromLibrary('KerML::Element') syntaxElement() : Element [0..1] If this MetadataFeature reflectively represents a model element, then return the corresponding Element instance from the MOF abstract syntax representation of the model. pre: isSyntactic() body: No OCL Constraints checkMetadataFeatureSemanticSpecialization Kernel Modeling Language v1.0 231 -If this MetadataFeature is an application of SemanticMetadata , then its annotatingElement must be a Type . The annotated Type must then directly or indirectly specialize the specified value of the baseType , unless the Type is a Classifier and the baseType represents a kind of Feature , in which case the Classifier must directly or indirectly specialize each of the types of the Feature . isSemantic() implies let annotatedTypes : Sequence(Type) = annotatedElement->selectAsKind(Type) in let baseTypes : Sequence(MetadataFeature) = evaluateFeature(resolveGlobal( 'Metaobjects::SemanticMetadata::baseType'). memberElement. oclAsType(Feature))-> selectAsKind(MetadataFeature) in annotatedTypes->notEmpty() and baseTypes()->notEmpty() and baseTypes()->first().isSyntactic() implies let annotatedType : Type = annotatedTypes->first() in let baseType : Element = baseTypes->first().syntaxElement() in if annotatedType.oclIsKindOf(Classifier) and baseType.oclIsKindOf(Feature) then baseType.oclAsType(Feature).type-> forAll(t | annotatedType.specializes(t)) else if baseType.oclIsKindOf(Type) then annotatedType.specializes(baseType.oclAsType(Type)) else true endif checkMetadataFeatureSpecialization A MetadataFeature must directly or indirectly specialize the base MetadataFeature Metaobjects::metaobjects from the Kernel Semantic Library. specializesFromLibrary('Metaobjects::metaobjects') deriveMetadataFeatureMetaclass The metaclass of a MetadataFeature is one of its types that is a Metaclass metaclass = let metaclassTypes : Sequence(Type) = type->selectByKind(Metaclass) in if metaclassTypes->isEmpty() then null else metaClassTypes->first() endif validateMetadataFeatureAnnotatedElement The annotatedElements of a MetadataFeature must have an abstract syntax metaclass consistent with the annotatedElement declarations for the MetadataFeature . let baseAnnotatedElementFeature : Feature = resolveGlobal('Metaobjects::Metaobject::annotatedElement').memberElement. oclAsType(Feature) in let annotatedElementFeatures : OrderedSet(Feature) = feature-> select(specializes(baseAnnotatedElementFeature))-> excluding(baseAnnotatedElementFeature) in annotatedElementFeatures->notEmpty() implies let annotatedElementTypes : Set(Feature) = annotatedElementFeatures.typing.type->asSet() in 232 Kernel Modeling Language v1.0 -let metaclasses : Set(Metaclass) = annotatedElement.oclType().qualifiedName->collect(qn | resolveGlobal(qn).memberElement.oclAsType(Metaclass)) in metaclasses->forAll(m | annotatedElementTypes->exists(t | m.specializes(t))) validateMetadataFeatureBody Each ownedFeature of a MetadataFeature must have no declared name, redefine a single Feature , either have no featureValue or a featureValue with a value Expression that is model-level evaluable, and only have ownedFeatures that also meet these restrictions. ownedFeature->closure(ownedFeature)->forAll(f | f.declaredName = null and f.declaredShortName = null and f.valuation <> null implies f.valuation.value.isModelLevelEvaluable and f.redefinition.redefinedFeature->size() = 1) validateMetadataFeatureMetaclass A MetadataFeature must have exactly one type that is a Metaclass . type->selectByKind(Metaclass).size() = 1 validateMetadataFeatureMetaclassNotAbstract The metaclass of a MetadataFeature must not be abstract. not metaclass.isAbstract 8.3.4.13 Packages Abstract Syntax 8.3.4.13.1 Overview Namespace OwningMembership Package +importedMemberships( excluded : Namespace [0..*] ) : Membership [0..*]{redefines importedMemberships} ElementFilterMembership +includeAsMember( element : Element ) : Boolean +/conditionedPackage 0..1 +/owningFilter 0..1 {subsets owningNamespace} {subsets owningMembership} {redefines ownedMemberElement} +/condition 1 LibraryPackage +/filterCondition +isStandard : Boolean = false Expression 0..* +libraryNamespace() : Namespace [0..1]{redefines libraryNamespace} {subsets ownedMember, ordered} Figure 40. Packages 8.3.4.13.2 ElementFilterMembership Description ElementFilterMembership is a Membership between a Namespace and a model-level evaluable Boolean -valued Expression , asserting that imported members of the Namespace should be filtered using the condition Expression . A general Namespace does not define any specific filtering behavior, but such behavior may be defined for various specialized kinds of Namespaces . Kernel Modeling Language v1.0 233 -General Classes OwningMembership Attributes /condition : Expression {redefines ownedMemberElement} The model-level evaluable Boolean -valued Expression used to filter the imported members of the membershipOwningNamespace of this ElementFilterMembership . Operations None. Constraints validateElementFilterMembershipConditionIsBoolean The result parameter of the condition Expression must directly or indirectly specialize ScalarValues::Boolean . condition.result.specializesFromLibrary('ScalarValues::Boolean') validateElementFilterMembershipConditionIsModelLevelEvaluable The condition Expression must be model-level evaluable. condition.isModelLevelEvaluable 8.3.4.13.3 LibraryPackage Description A LibraryPackage is a Package that is the container for a model library. A LibraryPackage is itself a library Element as are all Elements that are directly or indirectly contained in it. General Classes Package Attributes isStandard : Boolean Whether this LibraryPackage contains a standard library model. This should only be set to true for LibraryPackages in the standard Kernel Model Libraries or in normative model libraries for a language built on KerML. Operations libraryNamespace() : Namespace [0..1] {redefines libraryNamespace} The libraryNamespace for a LibraryPackage is itself. body: self 234 Kernel Modeling Language v1.0 -Constraints None. 8.3.4.13.4 Package Description A Package is a Namespace used to group Elements , without any instance-level semantics. It may have one or more model-level evaluable filterCondition Expressions used to filter its importedMemberships . Any imported member must meet all of the filterConditions . General Classes Namespace Attributes /filterCondition : Expression [0..*] {subsets ownedMember, ordered} The model-level evaluable Boolean -valued Expression used to filter the members of this Package , which are owned by the Package are via ElementFilterMemberships . Operations importedMemberships(excluded : Namespace [0..*]) : Membership [0..*] {redefines importedMemberships} Exclude Elements that do not meet all the filterConditions . body: self.oclAsType(Namespace).importedMemberships(excluded)-> select(m | self.includeAsMember(m.memberElement)) includeAsMember(element : Element) : Boolean Determine whether the given element meets all the filterConditions . body: let metadataFeatures: Sequence(AnnotatingElement) = element.ownedAnnotation.annotatingElement-> selectByKind(MetadataFeature) in self.filterCondition->forAll(cond | metadataFeatures->exists(elem | cond.checkCondition(elem))) Constraints derivePackageFilterCondition The filterConditions of a Package are the conditions of its owned ElementFilterMemberships . filterCondition = ownedMembership-> selectByKind(ElementFilterMembership).condition Kernel Modeling Language v1.0 235 -8.4 Semantics 8.4.1 Semantics Overview A KerML model is intended to represent a system being modeled. The model is interpreted to make statements about the modeled system. The model may describe an existing system, in which case, if the model is correct, the statements it is interpreted to make about the system should all be true. A model may also be used to specify an imagined or planned system, in which case the statements the model is interpreted to make should be true for any system that is properly constructed and operated according to the model. The semantics of KerML specify how a KerML model is to be interpreted. The semantics are defined in terms of the abstract syntax representation of the model, and only for models which are valid relative to the structure and constraints specified for the KerML abstract syntax (see 8.3 ). As further specified in this subclause, models expressed in KerML are given semantics by implicitly reusing elements from the semantic models in the Kernel Model Library (see Clause 9 ). These library models represent conditions on the structure and behavior of the system being modeled, which are further augmented in a user model as appropriate. A formal specification of semantics allows models to be interpreted consistently. In particular, all KerML models extend library models expressed in KerML itself, understandable by KerML modelers. These library models can then be ultimately reduced to a small, core subset of KerML, which is grounded in mathematical logic. The goal is to provide uniform model interpretation, which improves communication between everyone involved in modeling, including modelers and tool builders. KerML semantics are specified by a combination of mathematics and model libraries, as illustrated in Fig. 41 . The left side of this diagram shows the abstract syntax packages corresponding to the three layers of KerML (see 6.1). The right side shows the corresponding semantic layering. 1. The Root Layer defines the syntactic foundation KerML and, as such, does not have a semantic interpretation relative to the modeled system. 2. The Core Layer is grounded in mathematical semantics, supported by the Base package from the Kernel Model Library (see 9.2.2 ). Subclause 8.4.3 specifies the semantics of the Core layer. 3. The Kernel Layer is given semantics fully through its relationship to the Model Library (see Clause 9 ). Subclause 8.4.4 specifies the semantics of the Kernel layer . 236 Kernel Modeling Language v1.0 -Kernel DataTypes Classes Structures Associations metamodel Connectors Kernel Behaviors Semantic semantic library Functions Library Expressions Interactions FeatureValues Multiplicities Metadata Packages «import» metamodel Core Base semantic library Types Classifiers Features mathematical semantics «import» Root Core Semantics Elements Dependencies Annotations Namespaces Figure 41. KerML Semantic Layers 8.4.2 Semantic Constraints and Implied Relationships As described in 8.4.1 , KerML semantics are specified by a combination of a mathematical interpretation of the Core layer and a set of required relationships between Core and Kernel model elements and elements of the Kernel Semantic Library (see 9.2 ). The latter requirements are formalized by semantic constraints included in the KerML abstract syntax (see also 8.3.1 on the various kinds of constraints in the abstract syntax). Additionally, other semantic constraints require relationships between elements within a user model necessary for the model to be semantically well formed. Specifically, there are four categories of semantic constraints, each dealing with a different kind of relationship. 1. Specialization constraints. These constraints require that Type elements of a certain kind directly or indirectly specialize some specific base Type from the Kernel Semantic Library. They are the fundamental means for providing semantics to abstract syntax elements in the Kernel layer. Specialization constraints always have the word Specialization in their name. For example, checkDataTypeSpecialization requires that a DataType directly or indirectly specialize the Semantic Library DataType Base::DataValue . Kernel Modeling Language v1.0 237 -2. Redefinition constraints. These constraints require that certain Features in a model have Redefinition relationships with certain other Features in the model. While Redefinitions are kinds of Specializations , redefinition constraints differ from the specialization constraints described above in that they are between two elements of a user model, rather than between an element of a user model and an element of a library model. Redefinition constraints always have the word Redefinition in their name. For example, checkConnectorEndRedefinition requires that the ends of a Connector redefine any ends of the Types that it specializes. 3. Type-featuring constraints. These constraints require that certain Features in a model have TypeFeaturing relationships with certain other Types in the model. They arise at points in a model in which the OwningMembership structure is different than the required Featuring relationship, so FeatureMembership cannot be used. Type-featuring constraints always have the words TypeFeaturing in their name. For example, checkFeatureValueExpressionTypeFeaturing requires that the value Expression owned by a FeatureValue relationship (a kind of OwningMembership ) have the same featuringTypes as the owning featureWithValue of the FeatureValue , rather than being featured by the featureWithValue itself (as would have been the case for a FeatureMembership ). 4. Binding-connector constraints. These constraints require that BindingConnectors exist between certain Features in a model. The primary example of such a constraint is checkFeatureValueBindingConnector , which requires that the featureWithValue of a FeatureValue own a BindingConnector between itself and the result parameter of the value Expression of the FeatureValue . A KerML model parsed from the textual concrete syntax (see 8.2 ) or obtained through model interchange (see Clause 10 ) will not necessarily meet the semantic constraints specified for the abstract syntax. In this case, a tool may insert certain implied Relationships into the model in order to meet the semantic constraints. The overview subclauses for the Core Semantics (see 8.4.3.1 ) and Kernel Semantics (see 8.4.4.1 ) include tables that define what implied Relationships should be included to satisfy each semantic constraint when it would otherwise be violated. In all cases, the semantics of a model are only defined if it meets all semantic and validation constraints (see 8.3.1 ). When including implied Relationships for specialization constraints, it is possible that multiple such constraints may apply to a single element. For example, a Structure is a kind of Class , which is a kind of Classifier , and there are specialization constraints for all three of these metaclasses, with corresponding implied Subclassification Relationships . However, simply including all three implied Subclassification would be redundant, because the Subclassification implied by the checkStructureSpecialization constraint will also automatically satisfy the checkClassSpecialization and checkClassifierSpecialization constraints. Therefore, in order to avoid redundant Relationships , a tool should observe the following rules when selecting which Specializations to actually include for a certain specific Type , out of the set of those implied by all specialization constraints applicable to the Type : 1. If there is any ownedSpecialization or other implied Specialization whose general Type is a direct or indirect subtype of (but not the same as) the general Type of an implied Specialization , or if there is an ownedSpecialization with the same general Type , then that implied Specialization should not be included. 2. If there are two implied Specializations with the same general Type , then only one should be included. Note that the above rules do not apply to Redefinitions implied by redefinition constraints, because Redefinition relationships have semantics beyond just basic Specialization . 238 Kernel Modeling Language v1.0 -8.4.3 Core Semantics 8.4.3.1 Core Semantics Overview 8.4.3.1.1 Core Semantic Constraints The Core semantics are primarily specified mathematically, but the Core metaclasses Type , Classifier , and Feature also have certain semantic constraints (see 8.4.2 ). Subclause 8.4.3.1.2 describes the general mathematical framework for Core semantics, with specific rules for Types , Classifiers and Features given in 8.4.3.2 , 8.4.3.3 , and 8.4.3.4 , respectively. The following summarizes the corresponding semantic constraints. The checkTypeSpecialization and checkFeatureSpecialization constraints are actually already implied by the mathematical semantics for Types and Features , but they are included in the abstract syntax so that they can also be reflected syntactically in models by the implied Relationships shown in Table 8 . In addition, Table 9 lists the implied Relationships for semantic constraints on the Core metaclass Feature that actually support the semantics of various Kernel-layer constructs, as further described in the Kernel Semantics ( 8.4.4 ) subclauses referenced in the table entries for those constraints. In all cases, the source and owningRelatedElement of the Relationship is the Element being constrained, with the target being as given in the last column of the table. Table 8. Core Semantics Implied Relationships Semantic Constraint Implied Relationship Target checkTypeSpecialization Subclassification Base::Anything (see 9.2.2.2.1 ) checkFeatureSpecialization Subsetting Base::things (see 9.2.2.2.7 ) Notes 1. The checkTypeSpecialization constraint applies to all Types , but the Subclassification Relationship is only implied for Classifiers (see 8.4.3.3 ). 2. Satisfaction of the checkFeatureSpecialization constraint implies satisfaction of the checkTypeSpecialization constraint (see 8.4.3.4 ). Table 9. Core Semantics Implied Relationships Supporting Kernel Semantics Semantic Constraint Implied Relationship Target Base::dataValues (see 9.2.2.2.3 ) checkFeatureDataValue Subsetting Supports Data Types Semantics (see Specialization 8.4.4.2 ) Occurrences::occurrences (see checkFeatureOccurrence 9.2.4.2.14 ) Subsetting Specialization Supports Classes Semantics (see 8.4.4.3 ) Occurrences::Occurrence:: checkFeatureSuboccurrence suboccurrences (see 9.2.4.2.13 ) Subsetting Specialization Supports Classes Semantics (see 8.4.4.3 ) A Type for which isFeaturingType checkFeatureFeatureMembership is true on the Feature TypeFeaturing TypeFeaturing Supports Classes Semantics (see 8.4.4.3 ) (See Note 1) Kernel Modeling Language v1.0 239 -Semantic Constraint Implied Relationship Target Objects::objects (see 9.2.5.2.8 ) checkFeatureObject Subsetting Supports Structures Semantics (see Specialization 8.4.4.4 ) Objects::Object::subobjects checkFeatureSubobject (see 9.2.5.2.7 ) Subsetting Specialization Supports Structures Semantics (see 8.4.4.4 ) Links::Link::participant (see checkFeatureEnd 9.2.3.2.3 ) Subsetting Specialization Supports Associations Semantics (see 8.4.4.5 ) endFeatures of supertypes of the owning Type of the Feature checkFeatureEndRedefinition Redefinition Supports Associations and Connectors Semantics (see 8.4.4.5 and 8.4.4.6 ) Feature chain (see Note 2) checkFeatureCrossing CrossSubsetting Supports Associations and Specialization Connectors Semantics (see 8.4.4.5 and 8.4.4.6 ) Cross Feature of the redefined end Feature (if any) checkFeatureOwnedCrossFeature Subsetting RedefinitionSpecialization Supports Associations and Connectors Semantics (see 8.4.4.5 and 8.4.4.6 ) types of the owning end Feature checkFeatureOwnedCrossFeature FeatureTyping Specialization Supports Associations and Connectors Semantics (see 8.4.4.5 and 8.4.4.6 ) See Note 3 checkFeatureOwnedCrossFeature TypeFeaturing Supports Associations and TypeFeaturing Connectors Semantics (see 8.4.4.5 and 8.4.4.6 ) parameters of supertypes of the owning Behavior or Step of the checkFeatureParameter Redefinition Feature Redefinition Supports Behaviors and Steps Semantics (see 8.4.4.7 ) result parameters of supertypes of the owning Function or checkFeatureResult Redefinition Expression of the Feature Redefinition Supports Functions and Expressions Semantics (see 8.4.4.8 ) 240 Kernel Modeling Language v1.0 -Semantic Constraint Implied Relationship Target Transfer::source:: sourceOutput or checkFeatureFlowFeature Transfer::target:: Redefinition Redefinition targetInput (see 9.2.7.2.9 ) Supports Flows Semantics (see 8.4.4.10.2 ) The result of the value Expression of an owned checkFeatureValuation Subsetting FeatureValue of a Feature Specialization Supports Feature Values Semantics (see 8.4.4.11 ) Notes 1. For the checkFeatureFeatureMembershipTypeFeaturing constraint, if the Feature has isVariable = false , then the target Type is the owningType of the Feature . If the Feature has isVariable = true and the owningType is the base Class Occurrences::Occurrence , then the target is Occurrences::Occurrence::snapshots (see 9.2.4.2.13 ). Otherwise, the target Type shall be constructed so as to satisfy the constraint and shall be owned as an ownedRelatedElement of the implied TypeFeaturing relationship. For further details, see 8.4.4.3 . 2. For the checkFeatureCrossingSpecialization constraint on an end Feature , the target feature chain shall consist of two Features . The first Feature is owned by the chain, is typed by the featuringType of the ownedCrossFeature of the end Feature , and is featured by the owningType of the end Feature . The second Feature is the ownedCrossFeature of the end Feature . For further details, see 8.4.4.5.1 . 3. For the checkFeatureOwnedCrossFeatureTypeFeaturing constraint, if the owningType of the owning end Feature has exactly two endFeatures , then an ownedCrossFeature shall be featured by the types of the other end than its owning end Feature . If the owningType has more than two endFeatures , then the ownedCrossFeature shall be featured by a Feature representing a Cartesian product of the types of the other end Features of the owningType than the owning end Feature of the ownedCrossFeature . For further details, see 8.4.4.5.1 . 8.4.3.1.2 Core Semantics Mathematical Preliminaries The mathematical specification of Core semantics uses a model-theoretic approach. Core mathematical semantics are expressed in first order logic notation, extended as follows: 1. A conjunction specifying that multiple variables are members of the same set can be shortened to a ∈ comma-delimited series of variables followed by a single membership symbol (s , s S is short for 1 2 ∈ ∧ ∈ s S s S). Quantifiers can use this in variable declarations, rather than leaving it to the body of 1 2 ∀ ∈ ∀ ∈ ∧ ∈ ⇒ the statement before an implication ( t , t V ... is short for t , t t V t V ...). g s T g s g T s T 2. Dots (.) appearing between metaproperty names have the same meaning as in OCL, including implicit collections [OCL]. 3. Sets are identified in the usual set-builder notation, which specifies members of a set between curly braces ("{}"). The notation is extended with "#" before an opening brace to refer to the cardinality of a set. Element names appearing in the mathematical semantics refer to the Element itself, rather than its instances, using the same font conventions as given in 8.1 . The mathematical semantics use the following model-theoretic terms, explained in terms of this specification: Kernel Modeling Language v1.0 241 -• Vocabulary: Model elements conforming to the KerML abstract syntax, with additional restrictions given in this subclause. • Universe: All actual or potential things the vocabulary could possibly be about. • Interpretation: The relationship between vocabulary and mathematical structures made of elements of the universe. The above terms are mathematically defined below. • A vocabulary V = ( V , V , V ) is a 3-tuple where: T C F ◦ V is a set of types (model elements classified by Type or its specializations, see 8.3.3.1 ). T ◦ V ⊆ V is a set of classifiers (model elements classified by Classifier or its specializations, C T see 8.3.3.2 ), including at least Base::Anything from KerML Semantic Model Library, see 9.2.2 ). ◦ V ⊆V is a set of features (model elements classified by Feature or its specializations, see F T 8.3.3.3 ), including at least Base::things from the KerML Semantic Model Library (see 9.2.2 ). ◦ V = V ∪ V T C F T • An interpretation I = ( Δ, Σ , ⋅ ) for V is a 3-tuple where: ◦ Δ is a non-empty set (universe), Σ = (P, < ) ◦ is a non-empty set P with a strict partial ordering < (marking set), and P P T ◦ ⋅ is an (interpretation) function relating elements of the vocabulary to sets of all non-empty tuples (sequences) of elements of the universe, with an element of the marking set in between each one for sequences of multiple elements. It has domain V and co-domain that is the power T set of S: 1 S = Δ Δ × P × Δ Δ × P × Δ × P × Δ … ∪ ∪ 1 where Δ is the set of sets of size 1 covering all the elements of the universe (a unary Cartesian power). The semantics of KerML are restrictions on the interpretation relationship, as given mathematically in this and subsequent subclauses on the Core semantics. The phrase result of interpreting a model (vocabulary) element refers T to sequences paired with the element by ⋅ , also called the interpretation of the model element, for short. minT T The (minimal interpretation) function ⋅ specializes ⋅ to the subset of sequences that have no others in the interpretation as tails, except when applied to Anything . minT T T ∀t ∈ Type, s ∈ S s ∈ (t) ≡ s ∈ (t) ∧ (t ≠ Anything ⇒ (∀s ∈ S s ∈ (t) ∧ s ≠ s ⇒ ¬tail(s , s ))) 1 1 1 2 2 2 1 2 1 Functions and predicates for sequences are introduced below. Predicates prefixed with form: are defined in [fUML], Clause 10 (Base Semantics). • length is a function version of fUML's sequence-length. ∀s, n n = length(s) ≡ (form:sequence-length s n) • at is a function version of fUML's in-position-count. ∀x, s, n x = at(s, n) ≡ (form:in-position-count s n x) • head is true if the first sequence is the same as the second for some or all of the second starting at the beginning, otherwise is false. 242 Kernel Modeling Language v1.0 -∀s , s head(s , s ) ⇒ form:Sequence(s ) ∧ form:Sequence(s ) 1 2 1 2 1 2 ∀s , s head(s , s ) ≡ (length(s ) ≤ length(s )) ∧ 1 2 1 2 1 2 + (∀i ∈ Z i ≥ 1 ∧ i ≤ length(s ) ⇒ at(s , i) = at(s , i)) 1 1 2 • tail is true if the first sequence is the same as the second for some or all of the second finishing at the end, otherwise is false: ∀ ⇒ form:Sequence ∧ form:Sequence s , s tail(s , s ) (s ) (s ) 1 2 1 2 1 2 ∀ ∧ s , s tail(s , s ) ≡ (length(s ) ≤ length(s )) 1 2 1 2 1 2 + (∀h, i ∈ Z (h = length(s ) − length(s )) ∧ i > h ∧ i ≤ length(s ) ⇒ at(s , i − h) = at(s , i) 2 1 2 1 2 • head-tail is true if the first and second sequences are the head and tail of the third sequence, respectively, otherwise is false: ∀s , s head-tail(s , s , s ) ⇒ 1 2 1 2 0 form:Sequence(s ) ∧ form:Sequence(s ) ∧ form:Sequence(s ) 1 2 0 ∀ ∧ s , s head-tail(s , s , s ) ≡ head(s , s ) tail(s , s ) 1 2 1 2 0 1 0 2 0 • concat is true if the first sequence has the second as head, the third as tail, and its length is the sum of the lengths of the other two, otherwise is false. ∀s , s , s concat(s , s , s ) ⇒ form:Sequence (s0) ∧ form:Sequence (s1) ∧ form:Sequence (s2) 0 1 2 0 1 2 ∀s , s , s concat(s , s , s ) ≡ (length(s ) = length(s ) + length(s )) ∧ head-tail(s , s , s ) 0 1 2 0 1 2 0 1 2 1 2 0 • concat-around is true if the first sequence has the second as head, the fourth as tail, and the third element in between. s , s , p, s concat-around(s , s , p, s ) ∀ ⇒ 0 1 2 0 1 2 (s ) ∧ (s ) ∧ (s ) form:Sequence form:Sequence form:Sequence 0 1 2 ∀s , s , p, s concat-around(s , s , p, s ) ≡ (length(s ) = length(s ) + length(s ) + 1) ∧ 0 1 2 0 1 2 0 1 2 head-tail(s , s , s ) ∧ at(p, length(s )+1) 1 2 0 1 • reverse is true if the sequences have the same elements, but in reverse order, otherwise is false. ∀s , s reverse(s , s ) ⇒ form:Sequence(s1) ∧ form:Sequence(s2) 1 2 1 2 ∀s , s reverse(s , s ) ≡ (length(s ) = length(s )) ∧ 1 2 1 2 1 2 + (∀i ∈ Z i ≥ 1 ∧ i ≤ length(s ) ⇒ at(s , (length(s ) − i+1) = at(s , i)) 1 1 1 2 8.4.3.2 Types Semantics Abstract syntax reference: 8.3.3.1 The checkTypeSpecialization constraint requires that all Types directly or indirectly specialize Base::Anything (see 9.2.2.2.1 ). However, there is no implied relationship shall be inserted to satisfy this constraint for a Type that is not a Classifier or a Feature (see also 8.4.3.3 and 8.4.3.4 on Classifiers and Features, respectively). The mathematical interpretation (see 8.4.3.1.2 ) of Types in a model shall satisfy the following rules: 1. All sequences in the interpretation of a Type are in the interpretations of the Types it specializes. T T ∀t , t ∈ V t ∈ t .specialization.general ⇒ (t ) ⊆ (t ) g s T g s s g 2. No sequences in the interpretation of a Type are in the interpretations of its disjoining Types . Kernel Modeling Language v1.0 243 -T T ∀t, t ∈ V t ∈ t.disjoiningTypeDisjoining.disjoiningType ⇒ ( (t) ∩ (t ) = ∅ ) d T d d 3. The interpretations of a Type that has unioningTypes are all and only the interpretations of those Types . ∀t ∈ V , utl (utl) ∧ utl = t. ∧ length(utl) > 0 ⇒ form:Sequence unioningTypes T length(utl) T T (t) = ∪ (at(utl, i)) i = 1 4. The interpretations of a Type that has intersectingTypes are all and only the interpretations in common between all the Types . ∀ ∈ form:Sequence ∧ intersectingTypes ∧ ⇒ t V , itl (itl) itl = t. length(itl) > 0 T T length(itl) T (t) = ∩ (at(itl, i)) i = 1 5. The interpretations of a Type that has differencingTypes are all and only the interpretations of the first differencingType that are not interpretations of the remaining ones. t V , dtl (dtl) dtl = t. length(dtl) > 0 ∀ ∈ form:Sequence ∧ differencingTypes ∧ ⇒ T length(dtl) T T T (t) = (at(dtl, 1)) ∪ (at(dtl, i)) ∖ i = 2 8.4.3.3 Classifiers Semantics Abstract syntax reference: 8.3.3.2 The checkTypeSpecialization constraint is semantically required for Classifiers by the rules below. If necessary, it may be syntactically satisfied in a model by inserting an implied Subclassification Relationship to Base::Anything (see also Table 8 ). The mathematical interpretation (see 8.4.3.1.2 ) of the Classifiers in a model shall satisfy the following rules: 1. If the interpretation of a Classifier includes a sequence, it also includes the 1-tail of that sequence. T T ∀c ∈ V , s ∈ S s ∈ (c) ⇒ (∀s ∈ S tail(s , s ) ∧ length(s ) = 1 ⇒ s ∈ (c) ) C 1 1 2 2 1 2 2 2. The interpretation of the Classifier Anything includes all sequences of all elements of the universe and markings. T ( ) = S Anything 8.4.3.4 Features Semantics Abstract syntax reference: 8.3.3.3 The checkFeatureSpecialization constraint is semantically required by the first two rules below, combined T with the definition of . in 8.4.3.1.2 . If necessary, it may be syntactically satisfied in a model by inserting an implied Subsetting Relationship to Base::things (see also Table 8 ). Note that satisfaction of the checkFeatureSpecialization constraint implies satisfaction of the checkTypeSpecialization constraint, because Base::things is a FeatureTyping specialization of Base::Anything . The mathematical interpretation (see 8.4.3.1.2 ) of the Features in a model shall satisfy the following rules: 1. The interpretations of Features must have length greater than two. T ∀s ∈ S, f ∈ V s ∈ (f) ⇒ length(s) > 2 F 244 Kernel Modeling Language v1.0 -2. The interpretation of the Feature things is all sequences of length greater than two. T (things) = { s | s ∈ S ∧ length(s) > 2 } See other rules below. Features interpreted as sequences of length three or more can be treated as if they were interpreted as ordered triples ("marked" binary relations), where the first and third elements are interpretations of the domain and co- domain of the Feature , respectively, while the second element is a marking from P. The predicate feature-pair below determines whether two sequences can be treated in this way. Two sequences are a feature pair of a Feature if and only if the interpretation of the Feature includes a sequence s such that following are true: 0 • s is the concatenation of the two sequences, in order, with an elements of P (marking) marking in 0 between them. • The first sequence is in the minimal interpretation of all featuringTypes of the Feature . • The second sequence is in the minimal interpretations of all types of the Feature . s , s S, p P, f V feature-pair(s , p, s , f) ≡ ∀ ∈ ∈ ∈ 1 2 F 1 2 T s S s (f) concat-around(s , s , p, s ) ∃ ∈ ∈ ∧ ∧ 0 0 0 1 2 minT (∀t ∈ V t ∈ f. ⇒ s ∈ (t ) ) ∧ featuringType 1 T 1 1 1 minT (∀t ∈ V t ∈ f.type ⇒ s ∈ (t ) ) 2 T 2 2 2 Markings for the same s above can be related by < to order s across multiple interpretations (values) of f. 1 P 2 Interpretations of f can have the same s and s , differing only in p to distinguish duplicate s (values of f). 1 2 2 The interpretation of the Features in a model shall satisfy the following rules: 3. All sequences in an interpretation of a Feature have a tail with non-overlapping head and tail that are feature pairs of the Feature . T ∀s ∈ S, f ∈ V s ∈ (f) ⇒ ∃s , s , s ∈ S, p ∈ P tail(s , s ) ∧ head-tail(s , s , s ) ∧ 0 F 0 t 1 2 t 0 1 2 t (length(s ) > length(s ) + length(s )) ∧ feature-pair(s , p, s , f) t 1 2 1 2 4. Values of redefiningFeatures are the same as the values of their redefinedFeatures restricted to the domain of the redefiningFeature . ∀ ∈ ∈ redefinedFeature ⇒ f , f V f f . g s F g s minT ∀ ∈ ∀ ∈ ∈ featuringType ⇒ ∈ ⇒ ( s S ( ft V ft f . s (ft ) ) 1 s T s s 1 s ( s S, p P (feature-pair(s , p, s , f ) ≡ feature-pair(s , p, s , f )))) ∀ ∈ ∈ 2 1 2 s 1 2 g 5. The multiplicity of a Feature includes the cardinality of its values, counting duplicates. + minT ∀ ∈ ∈ ∈ ∀ ∈ ∈ featuringType ⇒ ∈ ∧ s S, f V , n Z ( t V t f. s (t ) ) 1 F 1 T 1 1 1 ⇒ n = #{(p, s ) | feature-pair(s , p, s , f)} 2 1 2 ∃ ∈ multiplicity p P feature-pair(s , p, (n), f. ) 1 6. If a Feature is unique, there are no values with the same markings. ∀s , s ∈ S, p , p ∈ P, f ∈ V f. ⇒ isUnique 1 2 1 2 F (feature-pair(s , p , s , f) ∧ feature-pair(s , p , s , f) ⇒ p =p ) 1 1 2 1 2 2 1 2 Kernel Modeling Language v1.0 245 -7. If a Feature is ordered, the markings of its values are totally ordered and mark exactly one value each. ∀ ∈ ∈ ∈ isOrdered ⇒ s , s , s S, p , p P, f V f. 1 2 3 1 2 F (feature-pair(s , p , s , f) feature-pair(s , p , s , f) (p =p s =s ) p < p p < p ) ∧ ⇒ ∧ ∨ ∨ 1 1 2 1 2 3 1 2 2 3 1 P 2 2 P 1 8. Sequences in the interpretation of an inverting feature are the reverse of those in the inverted feature. f , f V f f . ∀ ∈ ∈ invertingFeatureInverting.invertingFeature ⇒ 1 2 F 2 1 T T (∀s ∈ S s ∈ (f ) ≡ (∃s ∈ S s ∈ (f ) ∧ reverse(s , s ))) 1 1 1 2 2 2 2 1 9. The interpretation of a Feature with a chain is determined by the interpretations of the subchains, see additional predicates below. ∀f ∈ V , cfl cfl = f.chainingFeature ∧ form:Sequence (cfl) ∧ length(cfl) > 1 ⇒ chain-feature-n(f, cfl) F The interpretations of a Feature (f) specified as a chain of two others (f and f ) are all sequences formed from 1 2 Feature pairs of the two others that share the same sequence as second and first in their pairs, respectively. If f is ordered, marking order in interpretations of f applies the order of f values to those of f found via each value of f . 1 2 1 If f is non-unique, duplicate values of f (which might be due to multiple values of f ) are preserved in f, otherwise f 2 1 2 can have no duplicate values (including any due to multiple values of f ). 1 ∀paths, sd, f , f , scd paths = all-chain-path-2(sd, f , f , scd) ⇒ 1 2 1 2 form:Set(paths) ∧ sd, scd ∈ S ∧ f , f ∈ V 1 2 F sd, f , f , scd all-chain-path-2(sd, f , f , scd) = ∀ 1 2 1 2 { (pm, sm, pm11) | pm, pm11 ∈ P ∧ sm ∈ S ∧ feature-pair(sd, pm, sm, f ) ∧ feature-pair(sm, pm11, scd, f ) } 1 2 f, f , f chain-feature-2(f, f , f ) f, f , f V ∀ ⇒ ∈ 1 2 1 2 1 2 F f, f , f chain-feature-2(f, f , f ) ∀ ⇒ 1 2 1 2 (∀sd, scd ∈ S #{ pcd | feature-pair(sd, pcd, scd, f) = #all-chain-path-2(f , f , scd)) 1 2 f, f , f chain-feature-2(f, f , f ) ∀ ⇒ 1 2 1 2 (∀sd, scd , scd , ppath , ppath ∧ 1 2 1 2 ppath all-chain-path-2(f , f , scd ) ∈ ∧ 1 1 2 1 ppath all-chain-path-2(f , f , scd ) ∈ ∧ 2 1 2 2 ( pm , pm P, sm , sm S ∀ ∈ ∈ 1 11 1 2 ∧ ∧ ∧ pm =at(ppath , 1) sm =at(ppath , 2) pm =at(ppath , 3) 1 1 1 1 11 1 pm =at(ppath , 1) ∧ sm =at(ppath , 2) ∧ pm =at(ppath , 3) ∧ 2 2 2 2 21 2 ( (pm < pm ) ∨ (pm =pm ∧ sm =sm ∧ pm < pm ) ⇒ P P 1 2 1 2 1 2 11 21 (∃pcd , pcd ∈ P pcd < pcd ∧ P 1 2 1 2 ∧ feature-pair(sd, pcd , scd , f) feature-pair(sd, pcd , scd , f)))) 1 1 2 2 A Feature (f) specified as a chain of two or more others (fl, a list of features longer than 1) is the last in a series of Features specified by incremental subchains (flc), starting with the first two Features in fl, (specifying the first Feature in flc), then the first three in fl (specifying the second Feature in flc), and so on, to all the Features in fl (specifying the last feature in flc, which is the original Feature f). If f is ordered, marking order in interpretations of each subchain apply to values of later subchains. If f is non-unique, duplicate values of the last Feature in fl (which might be due to multiple values of the other Features ) are preserved in f, otherwise the last Feature in fl can have no duplicates (including any due to multiple values of the other Features ). 246 Kernel Modeling Language v1.0 -∀f, fl chain-feature-n(f, fl) ⇒ ∈ ∧ ⊆ ∧ form:Sequence ∧ f V fl V (fl) length(fl) > 1 F F ∀f, fl chain-feature-n(f, fl) ≡ ∃ ⊆ ∧ ∧ ∧ flc V (flc) length(flc) = length(fl) − 1 form:Sequence F + (∀i ∈ Z i > 1 ∧ i <= length(fl) ⇒ chain-feature-2(at(flc, i-1), at(fl, i-1), at(fl, i)) ∧ f = at(flc, length(flc)) 8.4.4 Kernel Semantics 8.4.4.1 Kernel Semantics Overview The semantics of constructs in the Kernel Layer are specified in terms of the foundational constructs defined in the Core layer supported by reuse of model elements from the Kernel Semantic Model Library (see 9.2 ). The most common way in which library model elements are used is through specialization, in order to meet subtyping constraints specified in the abstract syntax. For example, Structures are required to (directly or indirectly) subclassify Object from the Objects library model, while Features typed by Structures must subset objects . Similarly, Behaviors must subclassify Performance from the Performances library model, while Steps ( Features typed by Behaviors ) must subset performances . The requirement for such specialization is specified by specialization constraints in the abstract syntax, as listed in Table 10 along with the implied Specializations that may be used to satisfy them (see 8.4.2 for discussion of specialization constraints and implied Relationships ). Sometimes more complicated reuse patterns are needed. For example, binary Associations (with exactly two ends) specialize BinaryLink from the library, and additionally require the ends of the Association to redefine the source and target ends of BinaryLink . Such patterns are specified by redefinition constraints and other kinds of semantic constraints in the abstract syntax, as listed in Table 11 along with the implied Relationships that may be used to satisfy them (see also 8.4.2 ). In addition the Core semantic constraints listed in Table 9 actually support the semantics of Kernel layer constructs. In all cases, all Kernel syntactic constructs can be ultimately reduced to semantically equivalent Core patterns. Various elements of the Kernel abstract syntax essentially act as "markers" for modeling patterns typing the Kernel to the Core. The following subclauses specify the semantics for each syntactic area of the Kernel Layer in terms of the semantic constraints that must be satisfied for various Kernel elements, the pattern of relationships these imply, and the model library elements that are reused to support this. Table 10. Kernel Semantics Implied Specializations Semantic Constraint Implied Relationship Target checkDataTypeSpecialization Subclassification Base::DataValue (see 9.2.2.2.2 ) Occurrences::Occurrence (see checkClassSpecialization Subclassification 9.2.4.2.13 ) checkStructureSpecialization Subclassification Objects::Object (see 9.2.5.2.7 ) checkAssociation Subclassification Links::Link (see 9.2.3.2.3 ) Specialization Kernel Modeling Language v1.0 247 -Semantic Constraint Implied Relationship Target checkAssociationBinary Subclassification Links::BinaryLink (see 9.2.3.2.1 ) Specialization checkAssociationStructure Objects::LinkObject (see 9.2.5.2.5 Subclassification Specialization ) checkAssociationStructure Objects::BinaryLinkObject (see Subclassification BinarySpecialization 9.2.5.2.1 ) checkConnectorSpecialization Subsetting Links::links (see 9.2.3.2.4 ) checkConnectorBinary Subsetting Links::binaryLinks (see 9.2.3.2.2 ) Specialization checkConnectorObject Objects::linkObjects (see Subsetting Specialization 9.2.5.2.6 ) checkConnectorBinaryObject Objects::binaryLinkObjects (see Subsetting Specialization 9.2.5.2.2 ) checkBindingConnector Subsetting Links::selfLinks (see 9.2.3.2.6 ) Specialization checkSuccession Occurrences:: Subsetting Specialization happensBeforeLinks (see 9.2.4.2.2 ) Performances::Performance (see checkBehaviorSpecialization Subclassification 9.2.6.2.14 ) Performances::performances (see checkStepSpecialization Subsetting 9.2.6.2.15 ) Performances::Performance:: checkStepEnclosedPerformance Subsetting enclosedPerformance (see Specialization 9.2.6.2.14 ) checkStepSubperformance Performances::Performance:: Subsetting Specialization subperformance (see 9.2.6.2.14 ) checkStepOwnedPerformance Objects::Object:: Subsetting Specialization ownedPerformance (see 9.2.5.2.7 ) Performances::Evaluation (see checkFunctionSpecialization Subclassification 9.2.6.2.4 ) 248 Kernel Modeling Language v1.0 -Semantic Constraint Implied Relationship Target Performances:: checkPredicateSpecialization Subclassification BooleanEvaluation (see 9.2.6.2.1 ) checkExpression Performances::evaluations (see Subsetting Specialization 9.2.6.2.5 ) checkBooleanExpression Performances:: Subsetting Specialization booleanEvaluations (see 9.2.6.2.2 ) Performances:: trueEvaluations (see 9.2.6.2.17 ), for checkInvariantSpecialization Subsetting true Invariants , or Performances:: falseEvaluations (see 9.2.6.2.6 ), for false (negated) Invariants checkNullExpression Performances:: Subsetting Specialization nullEvaluations (see 9.2.6.2.13 ) checkLiteralExpression Performances:: Subsetting Specialization literalEvaluations (see 9.2.6.2.9 ) Performances:: checkLiteralBoolean Subsetting literalBooleanEvaluations Specialization (see 9.2.6 ) Performances:: checkLiteralInfinity Subsetting literalIntegerEvaluations Specialization (see 9.2.6 ) Performances:: checkLiteralInteger Subsetting literalIntegerEvaluations Specialization (see 9.2.6 ) Performances:: checkLiteralRational Subsetting literalRationalEvaluations Specialization (see 9.2.6 ) Performances:: checkLiteralString Subsetting literalStringEvaluations (see Specialization 9.2.6 ) checkFeatureReference The referent of the ExpressionResult Subsetting FeatureReferenceExpression Specialization (see Note 1) Performances:: CheckConstructorExpression Subsetting constructorEvaluations (see Specialization 9.2.6.2.3 ) Kernel Modeling Language v1.0 249 -Semantic Constraint Implied Relationship Target FeatureTyping CheckConstructorExpression Subsetting The instantiatedType of the ResultSpecialization Specialization ConstructorExpression (see Note 3) FeatureTyping CheckInvocationExpression Subsetting The instantiatedType of the Specialization Specialization InvocationExpression (see Note 3) FeatureTyping The instantiatedType of the CheckInvocationExpression Subsetting InvocationExpression BehaviorResultSpecialization Specialization (see Note 1) (see Note 3) A feature chain of the input checkFeatureChainExpression parameter and sourceTarget() of Subsetting ResultSpecialization the FeatureChainExpression (see Note 1) The result parameter of the first checkSelectExpressionResult Subsetting argument of the SelectExpression Specialization (see Note 1) The result parameter of the first checkIndexExpressionResult Subsetting argument of the IndexExpression Specialization (see Note 1) Performances:: checkMetadataAccess Subsetting metadataAccessEvaluations (see ExpressionSpecialization 9.2.6.2.11 ) Transfers::transfers (see checkFlowSpecialization Subsetting 9.2.7.2.11 ) Transfers::flowTransfers (see checkFlowWithEndsSpecializatiSounbsetting 9.2.7.2.4 ) checkSuccessionFlow Transfers::flowTransfersBefore Subsetting Specialization (see 9.2.7.2.5 ) checkMultiplicity Subsetting Base::naturals (see 9.2.2.2.5 ) Specialization Metaobjects::Metaobject (see checkMetaclassSpecialization Subclassification 9.2.16.2.1 ) checkMetadataFeature Metaobjects::metaobjects (see Subsetting Specialization 9.2.16.2.2 ) 250 Kernel Modeling Language v1.0 -Semantic Constraint Implied Relationship Target Specialization Subclassification checkMetadataFeatureSemantic FeatureTyping (See Note 2 and 8.4.4.13 ) Specialization Subsetting (see Note 2) Notes. 1. For all constraints other than checkMetadataFeatureSemanticSpecialization and the other constraints listed below, the source of any implied Relationship is the annotated element of the constraint, with the target as given in the table. For checkMetadataFeatureSemanticSpecialization , see Note 2. For the following constraints, the source is the result parameter of the Expression that is the annotated element of the constraint. ◦ checkFeatureReferenceExpressionResultSpecialization ◦ checkConstructorExpressionResultSpecialization ◦ checkInvocationExpressionResultSpecialization ◦ checkFeatureChainExpressionResultSpecialization ◦ checkSelectExpressionResultSpecialization ◦ checkIndexExpressionResultSpecialization 2. The checkMetadataFeatureSemanticSpecialization constraint only applies to a MetadataFeature that has a metaclass that is a kind of SemanticMetadata (see 9.2.16.2.3 ). The source of the implied Relationship for this constraint is not the MetadataFeature but, rather, the Type annotated by the MetadataFeature , and a conforming tool need only insert the Relationship if the MetadataFeature is an ownedMember of the Type . The kind of Relationship that is implied and its target are determined as follows: ◦ If the annotated Type and the baseType are both Classifiers , then Subclassification targeting the baseType . ◦ If the annotated Type is a Feature and the baseType is a Classifier , then FeatureTyping targeting the baseType . ◦ If the annotated Type and the baseType are both Features , then Subsetting targeting the baseType . ◦ If the annotated Type is a Classifier and the baseType is a Feature , then Subclassifications targeting each of the types of the Feature . 3. For the checkConstructorExpressionResultSpecialization and checkInvocationExpressionSpecialization constraints, the implied Relationship is a Subclassification if the instantiatedType is a Classifier , a Subsetting if the instantiatedType is a Feature , and a Specialization otherwise. Table 11. Kernel Semantics Other Implied Relationships Target Semantic Constraint Implied Relationship (or source and target for binding) checkPayloadFeature Transfers::Transfer::payload Redefinition Redefinition (see 9.2.7.2.9 ) The defaultFeaturingType of checkConnectorTypeFeaturing TypeFeaturing the Connector (see Note 2) Kernel Modeling Language v1.0 251 -Target Semantic Constraint Implied Relationship (or source and target for binding) The featuringTypes of the featureWithValue of the checkExpressionTypeFeaturing TypeFeaturing FeatureValue that owns the Expression From the result of the result checkFunctionResult BindingConnector Expression of the Function to its BindingConnector result parameter . From the result of the result checkExpressionResult Expression of the constrained BindingConnector BindingConnector Expression to its result parameter . Between the referent and result checkFeatureReference BindingConnector of the ExpressionBindingConnector FeatureReferenceExpression feature of the checkConstructorExpression instantiatedType of the Redefinition ResultFeatureRedefinition ConstructorExpression (see Note 6) Between features of the result checkConstructorExpression of the ConstructorExpression and ResultDefaultValue BindingConnector results of default value BindingConnector Expressions (see Note 4) for those features . checkInvocationExpression Between the InvocationExpression itself and BindingConnector BehaviorBindingConnector its result parameter . (see Note 3) Between features of the checkInvocationExpression InvocationExpression and BindingConnector DefaultValueBindingConnector results of default value (see Note 4) Expressions for those features . checkFeatureChainExpression ControlFunctions::'.':: Redefinition TargetRedefinition source::target (see Note 5) (see 9.4.17 ) checkFeatureChainExpression The targetFeature of the Redefinition SourceTargetRedefinition FeatureChainExpression (see Note 5) Between the featureWithValue checkFeatureValue of the FeatureValue and a feature BindingConnector BindingConnector chain of the value Expression and its result Notes 1. For redefinition and type featuring constraints, except for checkConstructorExpressionResultFeatureRedefinition , the annotated element of the 252 Kernel Modeling Language v1.0 -constraint is the source and owningRelatedElement of the implied Relationship , with the target as given in the last column table. For the checkConstructorExpressionResultFeatureRedefnition constraint, the source is an ownedFeature of the result parameter of the ConstructorExpression . For binding connector constraints, the annotated element of the constraint is the owningNamespace of the implied Relationship , with the source and target of the Relationship as given in the last column of the table. 2. For the checkConnectorTypeFeaturing constraint, an implied TypeFeaturing shall only be included to satisfy the constraint if the Connector has no owningType , no non-implied ownedTypeFeaturings , and a non-null defaultFeaturingType . 3. The checkInvocationExpressionBehaviorBindingConnector constraint only applies if the instantiatedType is not a Function or a Feature typed by a Function . 4. The checkConstructorExpressionResultDefaultValueBindingConnector and checkInvocationExpressionDefaultValueBindingConnector constraints apply to each ownedFeature that redefines a Feature for which there is an effective default value (see 8.4.4.11 ). 5. For the checkFeatureChainExpressionTargetRedefinition and checkFeatureChainExpressionSourceTargetRedefinition constraints, the redefiningFeature of the implied Redefinition is a nested Feature of the first owned input parameter of the FeatureChainExpression (corresponding to the source parameter of the '.' Function ). 6. For the checkConstructorExpressionResultFeatureRedefinition constraint, the target of the Redefinition shall be the feature of the instantiatedType at the same position in order in the instantiatingType that as the position of the redefining ownedFeature in the ConstructorExpression result parameter . 8.4.4.2 Data Types Semantics Abstract syntax reference: 8.3.4.1 The checkDataTypeSpecialization constraint requires that DataTypes specialize the base DataType Base::DataValue (see 9.2.2.2.2 ). The checkFeatureDataValueSpecialization constraint requires that Features typed by a DataType specialize the Feature Base::dataValues (see 9.2.2.2.3 ), which is typed by Base::DataValue . datatype D specializes Base::DataValue { feature a : ScalarValue::String subsets Base::dataValues; feature b : D subsets Base::dataValues; } The Type Base::DataValue is disjoint with Occurrences::Occurrence and Links::Link , the base Types for Classes and Associations (see 8.4.4.3 and 8.4.4.5 , respectively). This means that a DataType cannot specialize a Class or Association and that a Feature typed by a DataType cannot also be typed by a Class or Association . 8.4.4.3 Classes Semantics Abstract syntax reference: 8.3.4.2 The checkClassSpecialization constraint requires that Classes specialize the base Class Occurrences::Occurrence (see 9.2.4.2.13 ). The checkFeatureOccurrenceSpecialization constraint requires that Features typed by a Class specialize the Feature Occurrences::occurrences (see 9.2.4.2.14 ), which is typed by Occurrences::Occurrence . Further, the checkFeatureSuboccurrenceSpecialization constraint requires that composite Features typed by a Class , and whose ownedType is a Class or another Feature typed by a Class , specialize the Feature Occurrences::Occurrence::suboccurrences (see 9.2.4.2.13 ), which subsets Occurrences::occurrences . Kernel Modeling Language v1.0 253 -class C specializes Occurrences::Occurrence { feature a : C subsets Occurrences::occurrences; composite feature b : C subsets Occurrences::Occurrence::suboccurrences; } The Class Occurrences::Occurrence is disjoint with Base::DataValues , the base Type for DataTypes (see 8.4.4.2 ). This means that a Class cannot specialize a DataType and that a Feature typed by a Class cannot also be typed by a DataType . Note that Occurrences::Occurrence is not disjoint with Link::Links , because an AssociationStructure is both an Association and a Structure (which is a kind of Class ), so the base AssociationStructure Objects::LinkObject specializes both Link::Links and (indirectly) Occurrences::Occurrence . Unlike DataValues , Occurrences are modeled as occurring in three-dimensional space and persisting over time. The Occurrences library model includes an extensive set of Associations between Occurrences that model various spatial and temporal relations, such as InsideOf , OutsideOf , HappensBefore , HappensDuring , etc. In particular, the Association HappensBefore is the base Type for Successions , the basic modeling construct for time-ordering Occurrences (see 8.4.4.6 on the semantics of Successions ). For further detail on the Occurrences model, see 9.2.4.1 . A Class (or any Type that directly or indirectly specializes Occurrence ) may have ownedFeatures with isVariable = true . The checkFeatureFeatureMembershipTypeFeaturing constraint requires that such variable Features are featured by the snapshots of their owningType . A snapshot covers the entire spatial extent of an Occurrence at a specific point in time. Therefore, an instance of the owningType can potentially have a different value for the variable Feature at each point in time during its Life . (See 9.2.4.1 for more on snapshots and Lives .) For example, a variable Feature declared as in the following is required to have as its featuringType a Feature that redefines Occurrence::snapshots and is itself featured by the owningType of the variable Feature . class C1 { var feature v1; } Thus, the above variable Feature declaration is semantically equivalent to (with implied Specializations also shown): class C1 specializes Occurrences::Occurrence{ var feature v1 subsets Base::things featured by C1_snapshots { member feature C1_snapshots redefines Occurrences::Occurrence::snapshots featured by C1; } } The Feature C1_snapshots is shown above as nested in the corresponding variable Feature v1 for purposes of presentation in the textual notation. However, when an implied TypeFeaturing relationship is added to satisfy the checkFeatureFeatureMembershipTypeFeaturing constraint, the "snapshots" featuringType is included as an ownedRelatedFeature of the implied TypeFeaturing . That is, the implied abstract syntax ownership structure for, e.g., the variable Feature C1::v1 above is: Feature v1 [Subsetting (IMPLIED)] Feature Base::things [TypeFeaturing (IMPLIED)] Feature C1_snapshots (OWNED) [Redefinition] Occurrences::snapshots [TypeFeaturing] C1 254 Kernel Modeling Language v1.0 -(The name C1_snapshots is used here for correspondence to the earlier textual notation presentation. This Feature would not be expected to be named in an actual implementation.) 8.4.4.4 Structures Semantics Abstract syntax reference: 8.3.4.3 The checkStructureSpecialization constraint requires that Structures specialize the base Structure Objects::Object (see 9.2.5.2.7 ). The checkFeatureObjectSpecialization constraint requires that Features typed by a Structure specialize the Feature Objects::object s (see 9.2.5.2.8 ), which is typed by Objects::Object . Further, the checkFeatureSubobjectSpecialization constraint requires that composite Features typed by a Structure , and whose ownedType is a Structure or another Feature typed by a Structure , specialize the Feature Objects::Object::subobjects (see 9.2.5.2.7 ), which subsets Object::objects . struct S specializes Objects::Object { feature a : S subsets Object::objects; composite feature b : S subsets Objects::Object::subobjects; } Objects are Occurrences representing physical or virtual structures that occur over time. For physical structures, the Objects library model also provides a the specialization StructuredSpaceObject , which models Objects that can be spatial decomposed into cells of the same or lower dimension. The Type Object is disjoint with the Type Performance , another specialization of Occurrence , which is the base Type for Behaviors (see 8.4.4.7 on the semantics of Behaviors ). For further detail on the Objects model, see 9.2.5.1 . 8.4.4.5 Associations Semantics Abstract Syntax Reference: 8.3.4.4 8.4.4.5.1 Associations The checkAssociationSpecialization and checkFeatureEndSpecialization constraints require that an Association specialize the base Association Links::Link (see 9.2.3.2.3 ) and that its associationEnds subset Links::Link::participant . In addition, the validateFeatureEndMultiplicity constraint requires that the associationEnds must have multiplicity 1..1 . These constraints essentially require an N-ary Association to have the form (with implied relationships included): assoc A specializes Links::Link { end feature e1[1..1] subsets Links::Link::participant; end feature e2[1..1] subsets Links::Link::participant; ... end feature eN[1..1] subsets Links::Link::participant; } The Link instance for an Association is thus a tuple of participants , where each participant is a single value of an associationEnd of the Association . Note also that the Feature Link::participant is declared readonly , meaning that the participants in a link cannot change once the link is created. The checkFeatureEndRedefinition constraint requires that, if an Association has an ownedSubclassification to another Association , then its associationEnds redefine the associationEnds of the superclassifier Association . In this case, the subclassifier Association will indirectly specialize Link through a chain of Subclassifications , and each of its associationEnds will indirectly subset Links::participant through a chain of Redefinition and Subsetting . Kernel Modeling Language v1.0 255 -The checkAssociationBinarySpecialization constraint requires that a binary Association (one with exactly two associationEnds ) specialize Links::BinaryLink . BinaryLink specializes Link to have exactly two participants corresponding to two ends called source and target . As required by the checkFeatureEndRedefinition constraint, the first associationEnd of a binary Association will redefine Links::BinaryLink::source and its second associationEnd will redefine Links::BinaryLink::target . assoc B specializes Links::BinaryLink { end feature e1 redefines Links::BinaryLink::source; end feature e2 redefines Links::BinaryLink::target; } Note that, as associationEnds of BinaryLink , source and target already have multiplicities of 1..1 , which ensures that the ends of any binary Association do too. A binary Association can also specify cross features for one or both of its associationEnds using CrossSubsetting . Such a cross feature must be a feature of the type of the other associationEnd than the one for the cross feature. The validateCrossSubsettingCrossedFeature constraint requires that the target of a CrossSubsetting be a feature chain consisting of the other associationEnd and the cross feature. CrossSubsetting is a kind of Subsetting , so it semantically requires that the value of an associationEnd be one of the values of the cross feature for the other associationEnd . This also means that, if an associationEnd of a binary Association has a cross feature, then the cross-feature multiplicity applies to each set of instances (links) of the Association that have the same (singleton) value for the associationEnd . Cross feature uniqueness and ordering apply to the collection of values of the other associationEnd in each of those link sets, preventing duplication in each collection and ordering them to form a sequence. For example, the binary Association B1 below specifies cross features for both its ends (without implied relationships included): classifier T1 { feature e2_cross[0..1] : T2; } classifier T2 { feature e1_cross[1..4] nonunique ordered : T1; } assoc B1 { end feature e1 : T1 crosses e2.e1_cross; end feature e2 : T2 crosses e1.e2_cross; } The multiplicities specified for e1_cross and e2_cross then mean that: ▪ For each value of e1_cross , there is at most one instance of B1 for which e1 has that value and e2 has the corresponding value of e2_cross (multiplicity 0..1 ). ▪ For each value of e2_cross , there are one to four instances of B1 for which e2 has that value and e1 has the corresponding value of e1_cross (multiplicity 1..4 ). Further, there may be more than one of these instances with the same value of e1 ( nonunique ) and the instances have an implied ordering ( ordered ). Note. Ordering and uniqueness are irrelevant on the associationEnds themselves, since they must always have multiplicity 1..1 . Note that cross features impose only necessary conditions on the instances of an Association , which do not require existence of instances of the Association for all values of its cross features. To make these conditions also sufficient, requiring existence of these instances, the Association must have isSufficient = true (see 256 Kernel Modeling Language v1.0 -8.3.3.1.10 ). For example, if B1 above has isSufficient = true , then an instance t1 of T1 having a value t2 for e2_cross is sufficient to require that an instance of B1 exist linking t1 to t2 and, therefore, that t1 is a value of e1_cross for t2. assoc all B1 { // "all" declares isSufficient = true end feature e1 : T1 crosses e2.e1_cross; end feature e2 : T2 crosses e1.e2_cross; } Cross features may also be directly owned by the corresponding associationEnd . The checkFeatureOwnedCrossFeatureTypeFeaturing constraint requires such an owned cross feature (for a binary Association ) be featured by the type of the other associationEnd (which means it must be owned by the associationEnd via OwnedMembership but not FeatureMembership ). Further, the checkFeatureCrossingSpecialization constraint requires that the associationEnd has a CrossSubsetting that targets a feature chain whose first Feature is the other associationEnd and whose second Feature is the owned cross feature. An owned cross feature may be declared with the declaration of the corresponding associationEnd . For example, the following binary Association declaration (the cross feature names are optional, but they are included here for convenience of reference): assoc B2 end e1_cross [1..4] nonunique ordered feature e1 : T1; end e2_cross [0..1] feature e2 : T2; } is parsed (with implied relationships included) as: assoc B2 specializes Links::BinaryLink { end feature e1 : T1 redefines Links::BinaryLink::source; crosses e2.e1_cross { member feature e1_cross[1..4] nonunique ordered : T1 featured by T2; } end feature e2 : T2 redefines Links::BinaryLink::target; crosses e1.e2_cross { member feature e2_cross[0..1] : T2 featured by T1; } } Note. The feature chain notations e2.e1_cross and e2.e1_cross in the above notional equivalent will actually not parse, because e1_cross is not in the namespace of e2 and e2_cross is not in the namespace of e1 . However, the Features meet the semantic requirements for a feature chain (i.e., the type of the first Feature is the featuringType of the second Feature ), so the construct is valid in the abstract syntax. An Association with three or more associationEnds may also have ends with cross features, but, in this case, the cross features must be owned by their corresponding associationEnds . For example, the ternary Association assoc Ternary { end a_cross[1] feature a[1] : A; end b_cross[0..2] feature b[1] : B; end c_cross[*] nonunique ordered feature c[1] : C; } is effectively parsed (including implied relationships) as assoc Ternary specializes Links::Link { end feature a[1] : A subsets Links::Link::participant Kernel Modeling Language v1.0 257 -crosses b_c.a_cross { member feature b_c : B_C featured by Ternary; member feature B_C : C featured by B; member feature a_cross[1] : A featured by B_C; } end feature b[1] : B subsets Links::Link::participant crosses a_c.b_cross { member feature a_c : A_C featured by Ternary; member feature A_C : C featured by A; member feature b_cross[0..2] : B featured by A_C; } end feature c[1] : C subsets Links::Link::participant crosses a_b.c_cross { member feature a_b : A_B featured by Ternary; member feature A_B : C featured by B; member feature c_cross[*] : C featured by A_B; } } Consider specifically the assocationEnd a in the above Association . Since the Association is not binary, there is no longer a single other assocationEnd to a . So, in order to satisfy the checkFeatureOwnedCrossFeatureTypeFeaturing constraint, the cross feature a_cross is featured by the Feature B_C , which is constructed as being typed by C and featured by B . According to the Core semantics for Features (see 8.4.3.4 ), the Feature B_C is (minimally) interpreted as having instances that are pairs of instances of B and C , in that order. That is, the feature can be considered to semantically represent a Cartesian product of the set of instances of B and the set of instances of C . The associationEnd a then has a CrossSubsetting of a feature chain that starts with the Feature b_c , which is typed by B_C , followed by the cross feature a_cross , which is featured by B_C . As a result, the values of a_cross for each instance of Ternary are the values of the associationEnd a on all the instances of Ternary that have the same values for the other two associationEnds . Note also that the Features B_C and b_c are shown above as nested in the associationEnd a for purposes of presentation in the textual notation. However, when added with the implied relationships needed to satisfy semantic constraints, these Features are actually ownedRelatedElements of, respectively, the implied TypeFeaturing relationship on owned cross feature a_cross and the first FeatureChaining relationship in the target feature chain of the implied CrossSubsetting relationship on the associationEnd a . That is, the implied abstract syntax ownership structure is: Feature a [CrossSubsetting (IMPLIED)] Feature (OWNED) [FeatureChaining] Feature b_c (OWNED) [FeatureTyping] Feature B_C [TypeFeaturing] Association Ternary [FeatureChaining] a_cross [OwningMembership] Feature a_cross (OWNED) [FeatureTyping (IMPLIED)] Classifier A [TypeFeaturing (IMPLIED)] Feature B_C (OWNED) [TypeFeaturing] Classifier B [FeatureTyping] Classifier C (The names B_C and b_c are included here for correspondence to the earlier textual notation presentation. These Features would not be expected to be named in an actual implementation.) Similar syntax and semantics apply to all three of the associationEnds of Ternary . Each instance of Ternary consists of three participants , one value for each of the associationEnds a , b and c . But the multiplicities specified for the owned cross features of the associationEnds then assert that: 258 Kernel Modeling Language v1.0 -1. For any specific values of b and c , there must be exactly one instance of Ternary , with the single value allowed for a . 2. For any specific values of a and c , there may be up to two instances of Ternary , all of which must have different values for b (default uniqueness). 3. For any specific values of a and b , there may be any number of instance of Ternary , which are ordered and allow repeated values for c . This approach is applied to any N-ary Association with N of 3 or greater by extending the pattern for representing a Cartesian product of Classifiers using a Feature to any number of Classifiers . The operation Feature::isCartesianProduct checks whether a Feature meets the pattern for representing a Cartesian product. If so, then the operation Feature::asCartesianProduct returns the ordered list of Classifiers in the product. (See 8.3.3.3.4 for the specifications of these operations.) This gives the following general semantics for owned cross feature multiplicity: For an Association with N associationEnds , with N of 2 or greater, consider the i-th associationEnd e . The multiplicity of the owned i cross feature of e applies to each set of instances of the Association that have the same (singleton) values for i each of the N-1 associationEnds other than e . Uniqueness and ordering of the owned cross feature apply to the i collection of values of e in each of those link sets, preventing duplication in each collection and ordering them to i form a sequence. As described previously, the checkFeatureEndRedefinition constraint requires the associationEnds of an specialized Association to redefine the ends of the Associations it specializes. If a redefining associationEnd has an owned cross feature, the checkFeatureOwnedCrossFeatureRedefinitionSpecialization constraint further requires that the owned cross feature of the redefining associationEnd must subset the cross feature of the redefined associationEnd . Note that this constraint must be satisfied even of the cross feature of the redefined associationEnd is not owned by that associationEnd . For example, consider the following specialization of the Association B2 shown earlier: assoc B2a specializes B2 { end e1a_cross [0..2] nonunique ordered feature e1a : T1; end e2a_cross [1..1] feature e2a : T2; } This is parsed (with implied relationships included) as: assoc B2a specializes B2 { end feature e1a : T1 redefines B2::e1 crosses e2a.e1a_cross { member feature e1a_cross[0..2] nonunique ordered : T1 subsets B2::e1::e1_cross featured by T2; } end feature e2 : T2 redefines B2::e2 crosses e1.e2a_cross { member feature e2a_cross[1..1] : T2 subsets B2::e2::e2_cross featured by T1; } }Type 8.4.4.5.2 Association Structures An AssociationStructure is both an Association and a Structure and, therefore, the semantic constraints of both Associations and Structures (see 8.4.4.4 ) apply to AssociationStructures . The checkAssociationStructureSpecialization constraint requires an AssociationStructure to specialize Objects::LinkObject (see 9.2.5.2.5 ), which specializes both Links::Link and Objects::Object . The checkAssociationStructureBinarySpecialization constraint requires a binary AssociationStructure Kernel Modeling Language v1.0 259 -to specialize Objects::BinaryLinkObject (see 9.2.5.2.1 ), which specializes both Links::BinaryLink and an Objects::LinkObject . 8.4.4.6 Connectors Semantics Abstract syntax reference: 8.3.4.5 8.4.4.6.1 Connectors A Connector can only be typed by Associations . The checkConnectorSpecialization constraint then requires that Connectors specialize the base Feature Link::links (see 9.2.3.2.4 ), which is typed by the base Association Links::Link (see 9.2.3.2.3 ). Further, the checkFeatureEndRedefinition constraint requires that the connectorEnds of a Connector redefine the associationEnds of its typing Associations . As a result, a Connector typed by an N-ary Association is essentially required to have the form (with implicit relationships included): connector a : A subsets Links::links { end feature e1 redefines A::e1 references f1; end feature e2 redefines A::e2 references f2; ... end feature eN redefines A::eN references fN; } where e1 , e2 , ..., eN are the names of associationEnds of the Association A , in the order they are defined in A , and the f1 , f2 , ..., fN are the relatedFeatures of the Connector . Multiplicities declared for connectorEnds have the same special semantics as for associationEnds (see 8.4.4.5 ). If A is an AssociationStructure , then the checkConnectorObjectSpecialization constraint requires that the Connector subsets Objects::linkObjects (see 9.2.5.2.6 ) instead of Links::link . A binary Connector is a Connector with exactly two connectorEnds , that is, a Connector typed by a binary Association . The checkConnectorBinarySpecialization constraint requires that binary Connectors specialize the base Feature Link::binaryLinks (see 9.2.3.2.2 ), which is typed by the Association Links::BinaryLink (see 9.2.3.2.1 ). In particular, if no type is explicitly declared for a binary Connector , then its connectorEnds simply redefine the source and target ends of the Association BinaryLink , which are inherited by the Feature binaryLinks . connector b : B subsets Links::binaryLinks { end feature source redefines B::source references f1; end feature target redefines B::target references f2; } If B is an AssociationStructure , then the checkConnectorBinaryObjectSpecialization constraint requires that the Connector subsets Objects::binaryLinkObjects (see 9.2.5.2.2 ) instead of Links::binaryLinks . A connectorEnd may also have an owned cross feature, with the same syntax and semantics as for an owned cross feature of an associationEnd (see 8.4.4.5.1 ). If the connectorEnd redefines an associationEnd (or other connnectorEnd ), then it's owned cross feature must meet the same semantic constraints as for the owned cross feature of an associationEnd that redefines another associationEnd (see 8.4.4.5.1 ). For example, the declaration connector b2 : B2 { end e1a_cross [0..2] nonunique ordered feature e1a references f1; end e2a_cross [1..1] feature e2a references f2; } 260 Kernel Modeling Language v1.0 -is parsed (with implied relationships included) as: connector b2 : B2 subsets Links::binaryLinks { end feature e1a redefines B2::e1 references f1 crosses e2a.e1a_cross { member feature e1a_cross[0..2] nonunique ordered : T1 subsets B2::e1::e1_cross featured by T2; } end feature e2 redefines B2::e2 references f2 crosses e1.e2_cross { member feature e2a_cross[1..1] : T2 subsets B2::e2::e2_cross featured by T1; } } A Connector specifies a subset of the Links of its typing Associations for which the participants are values of the relatedFeatures of the Connector . In addition, the checkConnectorTypeFeaturing constraint requires that the featuringTypes of a Connector be consistent with those of its relatedFeatures . Typically, a Connector will have an owningType that is its featuringType , in which case all of its relatedFeatures must also be featured in the context of this Type . // This is the simplest case of a Connector satisfying checkConnectorTypeFeaturing, // in which the Connector and its relatedFeatures all have the same owningType. classifier C1 { feature f1; feature f2; connector cc1 { end feature references f1; end feature references f2; } } An implied TypeFeaturing may be included to satisfy the checkConnectorTypeFeaturing constraint, but only if the Connector has no explicit owningType or ownedTypeFeaturings , and the defaultFeaturingType of the Connector is not null. The target of the implied TypeFeaturing is then given by the defaultFeaturingType . The deriveConnectorDefaultFeaturingType constraint ensures that, if defaultFeaturingType is non null, then it is the innermost Type such that, if it is the featuringType of a Connector , the checkConnectorTypeFeaturing constraint will be met. classifier C2 { feature f1; feature f2 { // The defaultFeaturingType for Connector cc2 is Classifier C2, which is the // common featuringType of the relatedFeatures of cc2. member connector cc2 featured by C2 { end feature references f1; end feature references f2; } } } The primary case in which an implicit TypeFeaturing is necessary is for a BindingConnector that is itself added implicitly for a FeatureValue (see 8.4.4.11 ). The checkConnectorTypeFeaturing and deriveConnectorDefaultFeaturingType constraint uses the Feature::isFeaturedWithin operation (see 8.3.3.3.4 ), which specially handles variable features. The semantics of variable Features requires them to have featuringTypes that represent the snapshots of their owningTypes . For example, consider the following: Kernel Modeling Language v1.0 261 -class CL1 { var feature v1 featured by CL1_snapshots { member feature CL1_snapshots featured by CL1; } } class CL2 specializes CL1 { var feature v2 featured by CL2_snapshots { member feature CL2_snapshots featured by CL2; } member connector ccv featured by CL2_snapshots { end feature references v1; end feature references v2; } } While the class CL2 specializes CL1 , there is no explicit Specialization relationship between CL1_snapshots and CL2_snapshots . However, any instance of CL2 is an instance of CL1 , and CL1_snapshots and CL2_snapshots are both redefinitions of the same base Feature Occurrences::Occurrence::snapshots , so, semantically, C2_snapshots can be considered to be a redefinition of CL1_snapshots . The isFeaturedWithin operation takes this into account by using the Type::isCompatibleWith operation. By default, isCompatibleWith is just the same as specializes , but it is overriden in Feature to also treat Features such as CL1_snapshots and CL2_snapshots as being compatible (see 9.2.5.2.7 ). This is why, in the example above, the defaultFeaturingType for ccv is CL2_snapshots , which satisfies the checkConnectorTypeFeaturing constraint for ccv . In addition, the isFeaturedWithin operation specially considers a variable Feature to be featured within its owningType , even though it is not directly featured by the owningType . This allows variable and non-variable Features to be connected within a common featuring context. class CL3 { feature f; var feature v; connector cfv featured by CL3 { end feature references f; end feature references v; } } Semantically, this means that, within an instance of CL3 each value of cfv links a value f and a value of v for some specific snapshot of CL3 . However, which snapshot this is for each value of cfv is not determined in this specification, unless additional temporal constraints are explicitly included in the model. 8.4.4.6.2 Binding Connectors The checkBindingConnectorSpecialization constraint requires that BindingConnectors specialize the Feature Links::selfLinks (see 9.2.3.2.6 ), which is typed by the Association SelfLink (see 9.2.3.2.5 ). SelfLink has two associationEnds that subset each other, meaning they identify the same things (have the same values), which then also applies to BindingConnector connectorEnds that redefine the associationEnds of SelfLink . The general semantic constraints for Connectors also apply to BindingConnectors . Thus, a BindingConnector declaration of the form binding f1 = f2; is, with implied Relationships included, semantically equivalent to 262 Kernel Modeling Language v1.0 -connector subsets Links::selfLinks { end feature thisThing redefines Links::SelfLink::thisThing references f1; end feature sameThing redefines Links::SelfLink::sameThing references f2; } 8.4.4.6.3 Successions The checkSuccessionSpecialization constraint requires that Successions specialize the Feature Occurrences::happensBeforeLinks (see 9.2.4.2.2 ), which is typed by the Association HappensBefore (see 9.2.4.2.1 ). HappensBefore (see 9.2.4.2.1 ) has two associationEnds , asserting that the Occurrence identified by its first associationEnd ( earlierOccurrence ) temporally precedes the one identified by its second ( laterOccurrence ), which then also applies to Succession connectorEnds that redefine the associationEnds of HappensBefore . The general semantic constraints for Connectors also apply to Successions . This, a Succession declaration of the form succession first f1 then f2; is, with implied Relationships included, semantically equivalent to connector subsets Occurrences::happensBeforeLinks { end feature earlierOccurrence references f1 redefines Occurrences::HappensBefore::earlierOccurrence; end feature laterOccurrence references f2 redefines Occurrences::HappensBefore::laterOccurrence; } 8.4.4.7 Behaviors Semantics Abstract syntax reference: 8.3.4.6 8.4.4.7.1 Behaviors The checkBehaviorSpecialization constraint requires that Behaviors specialize Performances::Performance (see 9.2.6.2.14 ). In addition, the checkFeatureParameterRedefinition constraint requires that any owned parameters (i.e., directed ownedFeatures ) of a Behavior redefine corresponding parameters of any other Behaviors it specializes. behavior B specializes Performances::Performance { in feature x[0..*] subsets Base::things; out feature y[0..1] subsets Base::things; inout feature z subsets Base::things; } behavior B1 specializes B { in feature x1[1] redefines B::x; out feature y1[1] redefines B::y; // z is inherited without redefinition } 8.4.4.7.2 Steps The checkStepSpecialization constraint requires that Steps specialize Performances::performances (see 9.2.6.2.15 ). In addition, the checkFeatureParameterRedefinition constraint requires that any owned parameters (i.e., directed ownedFeatures ) of a Step redefine corresponding parameters of any other Steps or Behaviors it specializes. In particular, a Step explicitly typed by a Behavior will generally redefine the parameters of that Behavior . Kernel Modeling Language v1.0 263 -step b : B subsets Performances::performances { in feature x redefines B::x = x1; out feature y redefines B::y; inout feature z redefines B::z := z1 ; } step b1 : B1 subsets b { in feature x redefines B1::x, b::x; out feature y redefines B2::y, b::y; } Further, the checkStepEnclosedPerformanceSpecialization and checkStepSubperformanceSpecialization constraints require that a Step whose owningType is a Behavior or another Step specialize Performances::Performance::enclosedPerformance or, if it is composite, Performances::Performance::subperformance (see 9.2.6.2.14 ). Finally, the checkStepOwnedPerformanceSpecialization constraint requires that a composite Step whose owningType is a Structure or a Feature typed by a Structure specialize Objects::Object::ownedPerformance (see 9.2.5.2.7 ). step s subsets Performances::performances { step s1 subsets Performances::Performance::enclosedPerformance; composite step s2 subsets Performances::Performance::subperformance; } struct S specializes Objects::Object { composite step ss subsets Objects::Object::ownedPerformance; } 8.4.4.8 Functions Semantics Abstract syntax reference: 8.3.4.7 8.4.4.8.1 Functions and Predicates Functions are kinds of Behaviors . The checkFunctionSpecialization constraint requires that Functions specialize the base Function Performances::Evaluation (see 9.2.6.2.4 ), which is a specialization of Performances::Performance . All other semantic constraints on Behaviors (see 8.4.4.7 ) also apply to Functions . In addition, the checkFeatureResultRedefinition constraint requires that the result parameter of a Function always redefine the result of any its supertypes that are also Functions , regardless of their parameter position. function F specializes Performances::Evaluation { in a; in b; return result redefines Performances::Evaluation::result; } function G specializes F { in a redefines F::a; return result redefines F::result; in b redefines F::b; } Further, if a Function owns an Expression via a ResultExpressionMembership , then the checkFunctionResultBindingConnector constraint requires that the Function have, as an ownedFeature , a BindingConnector between the result parameter of the Expression and the result parameter of the Function . function H specializes Performances::Evaluation { return redefines Performances::Evaluation::result; binding result = resultExpr.result; // Implied 264 Kernel Modeling Language v1.0 -resultExpr } where resultExpr is an arbitrary Expression and resultExpr.result represents a Feature chain to the Expression result . A Predicate is a kind of Function , so all semantic constraints for Functions also apply to Predicates . In addition, the checkPredicateSpecialization constraint requires that Predicates specialize the base Predicate Performances::BooleanEvaluation (see 9.2.6.2.1 ), which is a specialization of Performances::Evaluation . BooleanEvaluation has a result parameter typed by Boolean , so Predicates always have a Boolean result. predicate P specializes Performances::BooleanEvaluation { in x : ScalarValues::Real; return redefines Performances::BooleanEvaluation::result; x > 0 } 8.4.4.8.2 Expressions and Invariants Expressions are kinds of Steps . The checkExpressionSpecialization constraint requires that Expressions specialize the base Expression Performances::evaluation s (see 9.2.6.2.5 ), which is a specialization of Performances::performances . All other semantic constraints on Steps (see 8.4.4.7 ) also apply to Functions . In addition, the checkFeatureResultRedefinition constraint requires that the result parameter of an Expression always redefine the result of any its supertypes that are Functions or other Expressions , regardless of their parameter position. expr f : F subsets Performances::evaluations { in a redefines F::a; in b redefines F::b; return result redefines F::result, Performances::evaluations::result; } expr g : G subsets f { return result redefines G::result, f::result; } Further, if an Expression owns another Expression via a ResultExpressionMembership , then the checkExpressionResultBindingConnector constraint requires that the Expression have, as an ownedFeature , a BindingConnector between the result parameter of the owned Expression and the result parameter of the owning Expression . expr h subsets Performances::Evaluation { binding result = resultExpr.result; // Implied resultExpr } where resultExpr is an arbitrary Expression and resultExpr.result represents a Feature chain to the Expression result . A BooleanExpression is a kind of Expression , so all semantic constraints for Expressions also apply to BooleanExpressions . In addition, the checkBooleanExpressionSpecialization constraint requires that BooleanExpressions specialize the base BooleanExpression Performances::booleanEvaluations (see 9.2.6.2.2 ), which is a specialization of Performances::evaluation s. expr p : P subsets Performances::booleanEvaluations { in x : ScalarValues::Integer redefines P::x; return redefines P::x, Performance::BooleanEvaluation::result; } Kernel Modeling Language v1.0 265 -An Invariant is a kind of BooleanExpression , so all semantic constraints for BooleanExpressions also apply to Invariants . In addition, the checkInvariantSpecialization constraint requires that Invariants specialize either the BooleanExpression Performances::trueEvaluations (see 9.2.6.2.17 ) or, if the Invariant is negated, the BooleanExpression Performances::falseEvaluations (see 9.2.6.2.6 ), both of which are specializations of Performances::booleanEvaluations . The BooleanExpression trueEvaluations has its result bound to true , while the BooleanExpression falseEvaluations has its result bound to false . inv true i1 subsets Performances::trueEvaluations { p(3) } inv false i2 subsets Performances::falseEvaluations { p(-3) } 8.4.4.9 Expressions Semantics Abstract syntax reference: 8.3.4.8 8.4.4.9.1 Null Expressions The checkNullExpressionSpecialization constraint requires that NullExpressions specialize the Expression Performances::nullEvaluations (see 9.2.6.2.13 ), which is typed by the Function Performances::NullEvaluation (see 9.2.6.2.12 ). The result parameter of NullEvaluation has multiplicity 0..0 , which means that a NullExpression always produces an empty result. The general semantic constraints for Expressions (see 8.4.4.8 ) also apply to NullExpressions . 8.4.4.9.2 Literal Expressions The checkLiteralExpressionSpecialization constraint requires that LiteralExpressions specialize the Expression Performances::literalEvaluations (see 9.2.6.2.9 ), which is typed by the Function Performances::LiteralEvaluation (see 9.2.6.2.8 ). The result parameter of LiteralEvaluation has multiplicity 1..1 and is typed by Base::DataValue (see 9.2.2.2.2 ). This means that a LiteralExpression always produces a single DataValue as its result. What value is actually produced depends on the kind of LiteralExpression . The general semantic constraints for Expressions (see 8.4.4.8 ) also apply to LiteralExpressions . With the exception of LiteralInfinity , each kind of LiteralExpression has a value property typed by a UML primitive type [UML, MOF]. The result produced by such a LiteralExpression is given by this value . LiteralInfinity does not have a value property, because its result is always "infinity" (written * the KerML textual notation; see 8.2.5.8.4 ), which is a number from the DataType ScalarValues::Positive that is greater than all the integers. Note. In the abstract syntax, the value property of LiteralRational has type Real (see 8.3.4.8.13 ), because that is the available UML/MOF primitive type. However, only the rational-number subset of the real numbers can be represented using a finite literal. So the result of a LiteralRational is actually always classified in the KerML DataType Rational . 8.4.4.9.3 Feature Reference Expressions There is no specific specialization requirement for a FeatureReferenceExpression . However, the general checkExpressionSpecialization constraint (see 8.4.4.8 ) requires that a FeatureReferenceExpression specialize Performances::Evaluation (see 9.2.6.2.4 ). All other general semantic constraints for Expressions (see 8.4.4.8 ) also apply to FeatureReferenceExpressions . 266 Kernel Modeling Language v1.0 -A FeatureReferenceExpression is parsed with a non-owning Membership relationship to its referent Feature (see 8.2.5.8.3 ). The checkFeatureReferenceExpressionBindingConnector constraint then requires that there be a BindingConnector between this member Feature and the result parameter of the FeatureReferenceExpression . The checkFeatureReferenceExpressionResultSpecialization constraint further requires that the result parameter also subset the Feature . While this subsetting is technically implied by the semantics of the BindingConnector (see 8.4.4.6 ), including the Subsetting relationship allows for simpler static type checking of the result of the FeatureReferenceExpression . Given the above, a FeatureReferenceExpression whose referent is a Feature f is semantically equivalent to the Expression expr subsets Performances::evaluations { alias for f; return result redefines Performances::Evaluation::result subsets f; member binding result = f; } A body Expression (see 8.2.5.8.3 ) is parsed as a FeatureReferenceExpression that contains the Expression body as its owned referent . That is, a body Expression of the form { body } is semantically equivalent to expr subsets Performances::evaluations { expr e subsets Performances::evaluation { body } return result redefines Performances::Evaluation::result subsets e; binding result = e; } This means that the result of the Expression is the Evaluation of the body Expression itself, rather than the result of actually evaluating the body. If and when this Evaluation actually occurs can then be further constrained, e.g., within an invoked Function for which the body Expression is an argument (as done, for example, by ControlFunctions – see 8.4.4.9.6 ). 8.4.4.9.4 Constructor Expressions A ConstructorExpression of the form new T(e1, e2, ...) , where T is the name of a Type and e1 , e2 , ... are argument Expressions , is parsed with a Membership to T (its instantiatedType ) and a result parameter having nested ownedFeatures of the result that have FeatureValue relationships to the arguments (see 8.2.5.8.3 ). The checkConstructorExpressionSpecialization constraint requires that ConstructorExpressions specialize the Expression Performances::constuctorEvaluations (see 9.2.6.2.3 ), which subsets Performances::evaluations (see 9.2.6.2.5 ), redefining its result parameter to have multiplicity 1..1 . This means that a ConstructorExpression always produces a single value as its result. In addition, the checkConstructorExpressionResultSpecialization constraint requires that the result of a ConstructorExpression specialize the instantiatedType (via a FeatureTyping if the instantiatedType is a Classifier or a Subsetting if it is a Feature ), and the checkConstructorExpressionResultFeatureRedefinition constraint requires that the nested ownedFeatures of the result each redefine a public feature of the instantiatedType . Thus, a ConstructorExpression of this form is semantically equivalent to expr subsets Performances::constructorEvaluations { alias of T; // If T is a feature chain, this is an OwningMembership. Kernel Modeling Language v1.0 267 -return result : T [1] redefines Performances::constructorEvaluations::result; feature a redefines T::a = e1; feature b redefines T::b = e2; ... } } where, in the positional-argument notation, the features of T are defined in order. If the named-argument notation new T(a = e1, b = e2, ...) is used, then the nested ownedFeatures redefine the named features of T , regardless of order. The semantic constraints for FeatureValues (see 8.4.4.11 ) then require that each nested ownedFeature is bound to the result of the corresponding Expression (i.e., a is bound to e1.result , etc.). Thus, a ConstructorExpression represents an Evaluation that results in a single instance of Type T whose features have values determined by the results of the argument Expressions . 8.4.4.9.5 Invocation Expressions An InvocationExpression of the form F(e1, e2, ...) , where F is the name of a Function and e1 , e2 , ... are argument Expressions , is parsed with a Membership to F (its instantiatedType ) and input parameters that have FeatureValue relationships to the arguments (see 8.2.5.8.3 ). The general semantic constraints for Expressions (see 8.4.4.8.2 ) also apply to InvocationExpressions . In addition, the checkInvocationExpressionSpecialization constraint requires that an InvocationExpression specialize its instantiatedType (via a FeatureTyping ). Thus, an InvocationExpression of this form is semantically equivalent to expr : F subsets Performances::evaluations { alias of F; feature a redefines F::a = e1; feature b redefines F::b = e2; ... return result redefines F::result; } If, instead of a Function F , the instantiatedType is a non- Function Behavior B , then B has no result parameter for the InvocationExpression result to redefine. Instead, the checkInvocationExpressionBehaviorBindingConnector constraint requires that the InvocationExpression have an owned BindingConnector between itself and its result parameter – that is, the InvocationExpression evaluates, as an Expression , to itself, as an instance of B . In addition, the checkInvocationExpressionBehaviorResultSpecialization constraint requires that the result parameter of the expression specialize the instantiatedType . expr e : B subsets Performances::evaluations { alias of B; feature a redefines B::a = e1; feature b redefines B::b = e2; ... return result : B redefines Performances::evaluations::result; binding result = e; } Note that, in this case, the derived function of the InvocationExpression will always be Performances::Evaluation , the type of Performances::evaluations . If the instantiatedType is a Feature , the semantics are similar, except that the InvocationExpression has a Subsetting relationship with the instantiatedType , instead of a FeatureTyping relationship. If the Feature is typed by a Function , then the InvocationExpression is effectively treated as an invocation of that Function . If the Feature is typed by a non- Function Behavior , then the InvocationExpression is treated a 268 Kernel Modeling Language v1.0 -Performance of that Behavior , returning itself as the result. Note also that, if the instantiatedType is a Feature with chainingFeatures , then it will be related to the InvocationExpression by an OwningMembership (but not a FeatureMembership ). 8.4.4.9.6 Operator Expressions An OperatorExpression is an InvocationExpression in which the invoked Function is identified by an operator symbol. The instantiatedType of an OperatorExpression is specially derived to be the Function that is the resolution of the operator symbol as a name in the first one of the library Packages BaseFunctions , DataFunctions or ControlFunctions . The general semantic constraints for Expressions (see 8.4.4.9 ) also apply to OperatorExpressions . With the exception of operators for ControlFunctions (see below), the concrete syntax for OperatorExpressions (see 8.2.5.8.1 ) is thus essentially just a special surface syntax for InvocationExpressions of the standard library Functions identified by their operator symbols. For example, a unary OperatorExpression such as not expr is equivalent to the InvocationExpression DataFunctions::'not' (expr) and a binary OperatorExpression such as expr_1 + expr_2 is equivalent to the InvocationExpression DataFunctions::'+' (expr_1, expr_2) where these InvocationExpressions are then semantically interpreted as in 8.4.4.9.5 . The + and - operators are the only operators that have both unary and binary usages. However, the corresponding library Functions have optional 0..1 multiplicity on their second parameters , so it is acceptable to simply not provide an input for the second argument when mapping the unary usages of these operators. Functions in the library models BaseFunctions and ScalarFunctions are extensively specialized in other library models to constrain their parameter types (e.g., the Package RealFunctions constrains parameter types to be Real , etc.). The result values the evaluation of such a Function shall be determined by the most specialized of its subtypes that is consistent with the types of its the dynamics result values from evaluating its argument Expressions . Control Functions Certain OperatorExpressions denote invocations of Functions in the ControlFunctions library model (see 9.4.17 ) that have one or more parameters that are Expressions . In the concrete syntax for such OperatorExpressions (see 8.2.5.8.1 ), the arguments corresponding to these parameters are parsed as if they were body Expressions (as described in 8.4.4.9.3 ), so they can effectively be passed without being immediately evaluated. The second and third arguments of the ternary conditional test operator if are for Expression parameters . Therefore, the notation for a conditional test OperatorExpression of the form if expr_1 ? expr_2 else expr_3 Kernel Modeling Language v1.0 269 -is parsed as ControlFunctions::'if' (expr_1, { expr_2 }, { expr_3 }) The second arguments of the binary conditional logical operators and , or , and implies are for Expression parameters . Therefore, the notation for a conditional logical OperatorExpression of the form expr_1 and expr_2 is parsed as ControlFunctions::'and' (expr_1, { expr_2 }) and similarly for or and implies . A FeatureChainExpression is an OperatorExpression whose operator corresponds to the Function ControlFunctions::'.' . This Function has a single parameter called source , but this parameter has a nested Feature called target . A FeatureChainExpression is parsed with an argument Expression for the source parameter and, additionally, a non- parameter Membership for its targetFeature , which is an alias Membership if the targetFeature is not a chain and an OwningMembership if the targetFeature is a chain. The checkFeatureChainExpressionTargetRedefinition constraint requires that the source parameter of the FeatureChainExpression have a nested Feature that redefines ControlFunctions::'.'::source::target , and the checkFeatureChainExpressionSourceTargetRedefinition requires that this nested Feature also redefine the targetFeature . The checkFeatureChainExpressionResultSpecialization constraint requires that the result parameter of a FeatureChainExpression subset the feature chain consisting of the redefining source parameter of the FeatureChainExpression and the nested Feature of that parameter . Given the above, a FeatureChainExpression of the form src.f (where src is an Expression ) is semantically equivalent to the Expression expr : ControlFunctions::'.' subsets Performances::evaluations { feature redefines ControlFunctions::'.'::source = src { feature redefines ControlFunctions::'.'::source::target redefines f; } alias for f; return subsets source.f; } A FeatureChainExpression whose targetFeature is a Feature chain, of the form src.f.g.h is semantically equivalent to the Expression expr : ControlFunctions::'.' subsets Performances::evaluations { feature redefines ControlFunctions::'.'::source = src { feature redefines ControlFunctions::'.'::source::target redefines tgt; } feature tgt chains f.g.h; return subsets source.tgt; } 270 Kernel Modeling Language v1.0 -The performance of the Function '.' then results in the effective chaining of the value of its source parameter (which will be the result of the argument Expression of the FeatureChainExpression ) and the source::target Feature (which will be the targetFeature of the FeatureChainExpression ). 8.4.4.9.7 Metadata Access Expressions The checkMetadataAccessExpressionSpecialization constraint requires that a MetadataAccessExpression specialize the Expression Performances::metadataAccessEvaluations (see 9.2.6.2.11 ), which is typed by the Function Performances::MetadataAccessEvaluation (see 9.2.6.2.10 ). The result parameter of MetadataAccessEvaluation is ordered and typed by Metaobjects :: Metaobject (see 9.2.16.2.1 ). The general semantic constraints for Expressions (see 8.4.4.9 ) also apply to MetadataAccessExpressions . A MetadataAccessExpression evaluates to an ordered set of Metaobjects , which are determined as follows: • A Metaobject representing each MetadataFeature (see 8.3.4.12.3 ) owned by the referencedElement of the MetadataAccessExpression that has the referenceElement as an annotatedElement , in the order that the MetadataFeatures appear in the model. Each of these Metaobjects is an instance of the metaclass of the corresponding MetadataFeature , with the features of each instance having values determined by evaluating the bound Expressions of the features in the MetadataFeature as model-level evaluable Expressions (see below). • Followed by a Metaobject that is an instance of the Metaclass from the reflective KerML abstract syntax library model (see 9.2.17 ) corresponding to the MOF metaclass of the referencedElement of the MetadataAccessExpression , with features having values corresponding to the values of the MOF properties for the referencedElement . Note that every Metaclass is required to specialize Metaobjects::Metaobject, so the typing of the results of a MetadataAccessExpression is consistent. For example, the MetadataAccessExpression C.metadata for the following referencedElement : class C { metadata M; } would evaluate to two Metaobjects : an instance of the Metaclass M representing the MetadataFeature annotation on C and an instance of KerML::Class representing the referencedElement C itself. 8.4.4.9.8 Model-Level Evaluable Expressions A model-level evaluable Expression is an Expression that can be evaluated using metadata available within a model itself. This means that the evaluation rules for such an Expression can be defined entirely within the abstract syntax. A model-level evaluable Expression is evaluated on a given target Element (see 8.4.4.13 and 8.4.4.14 for the targets used in the case of metadata values and filterConditions , respectively), using the Expression::evaluate operation, resulting in an ordered list of Elements . The rules for this operation are specified in the abstract syntax (see 8.3.4.8 ) and are summarized below: 1. A NullExpression evaluates to the empty list. 2. A LiteralExpression evaluates to itself. 3. A FeatureReferenceExpression is evaluated by first determining a value Expression for the referent : ◦ If the target Element is a Type that has a feature that is the referent or (directly or indirectly) redefines it, then use the value Expression of the FeatureValue for that feature (if any). Kernel Modeling Language v1.0 271 -◦ Else, if the referent has no featuringTypes , then use the value Expression of the FeatureValue for the referent (if any). Then: ◦ If such a value Expression exists, the FeatureReferenceExpression evaluates to the result of evaluating that Expression on the target . ◦ Else, if the referent is not an Expression , the FeatureReferenceExpression evaluates to the referent . ◦ Else, the FeatureReferenceExpression evaluates to the empty list. 4. A MetadataAccessExpression evaluates to the ownedElements of the referencedFeature that are MetadataFeatures and have the referencedElement as an annotatedElement , plus a MetadataFeature whose annotatedElement is the referencedElement , whose metaclass is the reflective Metaclass in the KerML library model (see 9.2.17 ) corresponding to the MOF class of the referencedElement , and whose ownedFeatures are bound to the values of the MOF properties of the referencedElement . 5. An InvocationExpression evaluates to an application of its function to argument values corresponding to the results of evaluating each of the argument Expressions of the InvocationExpression , with the correspondence as given below. Every Element in the list resulting from a model-level evaluation of an Expression according to the above rules will be either a LiteralExpression or a Feature that is not an Expression . If each of these Elements is further evaluated according to its regular instance-level semantics, then the resulting list of instances will correspond to the result that would be obtained by evaluating the original Expression using its regular semantics on the referenced metadata of the target Element . 8.4.4.10 Interactions Semantics Abstract syntax reference: 8.3.4.9 8.4.4.10.1 Interactions An Interaction is both an Association and a Behavior , and, therefore, the semantic constraints for both Associations (see 8.4.4.5 ) and Behaviors (see 8.4.4.7 ) apply. In particular, the checkAssociationSpecialization constraint requires that an Interaction specialize Links::Link (see 9.2.3.2.3 ), or, if it is a binary Interaction (with exactly two end Features ), the checkAssociationBinarySpecialization constraint requires that it specializes Links::BinaryLink (see 9.2.3.2.1 ). And the checkBehaviorSpecialization constraint requires that it also specialize Performances::Performance (see 9.2.6.2.14 ). These constraints require an N-ary Interaction to have the form (with implied relationships included) interaction I specializes Link::Link, Performances::Performance { end feature e1 subsets Links::Link::participant; end feature e2 subsets Links::Link::participant; ... end feature eN subsets Links::Link::participant; } with a binary Interaction having the form interaction B specializes Links::BinaryLink, Performances::Performance { end feature e1 redefines Links::BinaryLink::source; end feature e2 redefines Links::BinaryLink::target; } The checkFeatureEndRedefinition and checkFeatureParameterRefinition constraints also apply to Interactions . 272 Kernel Modeling Language v1.0 -interaction I1 specializes Links::BinaryLink, Performances::Performance { in feature x1; out feature y1; end feature e1; end feature f1; } interaction I2 specializes I1 { in feature x2 redefines x1; out feature y2 redefines y1; end feature e2 redefines e1; end feature f2 redefines f1; } 8.4.4.10.2 Flows A Flow is both a Connector and a Step and, therefore, the semantic constraints for both Connectors (see 8.4.4.6 ) and Steps (see 8.4.4.7 ) also apply to Flows . In addition, the checkFlowSpecialization constraint requires that Flows specialize Transfers::transfers (see 9.2.7.2.11 ). In addition, if the Flow has ownedEndFeatures (see below), then it must specialize Transfers::flowTransfers (see 9.2.7.2.4 ). The textual notation for an Flow , of the form flow of i : T from f1.f1_out to f2.f2_in; is parsed with i : T as a PayloadFeature and having two FlowEnds , one referencing f1 with an owned Feature redefining f1_out and one referencing f2 with an owned Feature redefining f2_in (see 8.2.5.9.2 ). A PayloadFeature is just a Feature owned by a Flow that has the special semantic constraint checkPayloadFeatureRedefinition that requires that a PayloadFeature redefine Transfers::Transfer::payload (see 9.2.7.2.9 ). A FlowEnd is an end Feature owned by a Flow that is required to have a single ownedFeature . The general checkFeatureEndRedefinition constraint (see 8.4.4.6 ) requires that the two FlowEnds of a Flow redefine Transfers::Transfer::source and Transfers::Transfer::target (see 9.2.7.2.9 ), respectively. The checkFeatureFlowFeatureRedefinition constraint then requires that the ownedFeatures of the FlowEnds redefine Transfer::source::sourceOutput or Transfer::target::targetInput . flow subsets Transfers::flowTransfers { // PayloadFeature feature i : T redefines Transfers::Transfer::item; // First FlowEnd end feature redefines Transfers::Transfer::source references f1 { feature redefines Transfers::Transfer::source::sourceOutput, f1_out; } // Second FlowEnd end feature references f2 redefines Transfers::Transfer::target { feature redefines Transfers::Transfer::target::targetInput, f2_in; } } A SuccessionFlow is semantically the same, except that the checkSuccessionFlowSpecialization constraint requires that it specialize Transfers::flowTransfersBefore (see 9.2.7.2.5 ), which means that the SuccessionFlow additionally has the semantics of a Succession between it source and target (see 8.4.4.6.3 on the semantics of Successions ). Kernel Modeling Language v1.0 273 -8.4.4.11 Feature Values Semantics Abstract syntax reference: 8.3.4.10 A FeatureValue is a kind of OwningMembership between a Feature and an Expression . Note that the FeatureValue relationship is not a Featuring relationship, so its featureWithValue (that is, its owning Feature ) is not the featuringType of the the value Expression . Instead, the checkExpressionFeaturingType constraint requires that the value Expression have the same featuringTypes as the featureWithValue . Most commonly, if the featureWithValue is an ownedFeature of a Type , this means that the Expression will have that Type as its featuringType . The checkFeatureValuationSpecialization constraint requires that, if the featureWithValue has no explicit ownedSpecializations and is not directed, then it subsets the result parameter of the value Expression . This reflects the semantics that the values of the featureWithValue is determined by the value Expression , giving the featureWithValue an implied typing that is useful for static type checking. On the other hand, if the featureWithValue has ownedSpecializations or is directed, then its static typing can be considered determined by its declaration excluding the FeatureValue (but including any implied Specializations ), which should then be validated against the typing of the result of the value Expression . If the FeatureValue has isDefault = false , the checkFeatureValueBindingConnector constraint requires that its featureWithValue have an ownedMember that is a BindingConnector between that Feature and the result parameter of the value Expression of the FeatureValue . In addition, if the FeatureValue has isInitial = false , then the featuringTypes of this BindingConnector must be the same as those of the featureWithValue . Most commonly, if the featureWithValue is an ownedFeature of a Type , then the BindingConnector will have that Type as its featuringType . Other general semantic constraints for Connectors (see 8.4.4.6 ) also apply to the BindingConnector required for a FeatureValue . Given the above, the textual notation for a FeatureValue with isDefault = false and isInitial = false , of the form type T { feature f = expr; } is semantically equivalent to type T { feature f { member expr e featured by T { ... } member binding b featured by T of f = e.result; } } where e is the semantic interpretation of expr as described in 8.4.4.9 . If a FeatureValue has isDefault = false but isInitial = true , then the validateFeatureValueIsInitial constraint requires that the featureWithValue of the featureValue have isVariable = true , and the checkFeatureValueBindingConnector constraint requires different featuringTypes for the BindingConnector than when isInitial = false . In this case, the BindingConnector must be featured by the startShot (see 9.2.4.2.13 ) of the that reference of its owning featureWithValue (see 9.2.2.2.7 ). Note that this is only possible if the featureWithValue is featured by a Class (see also 8.4.4.3 on the semantics of Classes ). Most commonly, if the featureWithValue is an ownedFeature of a Class or a Feature typed by a Class , then the BindingConnector will have the startShot of that Class as its featuringType , meaning that the binding only applies initially, that is, at the very start of an Occurrence that is an instance of the Class . 274 Kernel Modeling Language v1.0 -Thus, the textual notation for a FeatureValue with isDefault = false and isInitial = true , of the form class C { var feature f := expr; } is semantically equivalent to (see also 8.4.4.3 on the semantics of variable features) class C specializes Occurrences::Occurrence { feature f specializes Base::things featured by C_snapshots { member feature C_snapshots redefines Occurrences::snapshots featured by C; member expr e featured by C_snapshots { ... } member binding b featured by that.startShot of f = e.result; } } (note that the that is considered to be implicitly typed by Occurrence in this case). If a FeatureValue has isDefault = true , then no BindingConnector is required for the featureWithValue at its point of declaration. Instead, the checkInvocationExpressionDefaultValueBindingConnector constraint requires that an InvocationExpression own a BindingConnector between the featureWithValue and value Expression of any FeatureValue that is the effective default value for a Feature of the invoked Type of the InvocationExpression , where effective default value is defined as follows: • If the Feature has an owned FeatureValue with isDefault = true , then this is its effective default value. • If the Feature does not have an owned FeatureValue , but the set of effective default values of the Features it redefines has a single unique member, then this is the effective default value of the original Feature . • Otherwise the Feature does not have an effective default value. For example, given the Type declaration type T { feature f default = e; } a binding for f is included for the invocation T() , which is then semantically equivalent to expr : T { binding f = f::e.result; } where f:: e.result is the result of the value Expression from the default FeatureValue . On the other hand, for the invocation T(f = 1) , the Feature f will be bound to 1 rather than the FeatureValue default. A similar construction applies for FeatureValues with i sDefault = true and isInitial = true . (See also 8.4.4.9 on the general semantics of InvocationExpressions .) 8.4.4.12 Multiplicities Semantics Abstract syntax reference: 8.3.4.11 Kernel Modeling Language v1.0 275 -8.4.4.12.1 Multiplicities A Multiplicity is a kind of Feature, so the general semantics of Features (see 8.4.3.4 also apply to a Multiplicity . In addition, the checkMultiplicitySpecialization constraint requires that a Multiplicity specialize the Feature Base::naturals (see 9.2.2.2.5 ), which is typed by the DataType ScalarValues::Natural (see 9.3.2.2.4 ). This constraint effectively requires that the co-domain of a Multiplicity be a subset of the natural numbers, which can be specified by reference to a library Multiplicity (such as Base:exactlyOne or Base::oneToMany ) or using a MultiplicityRange from the Kernel layer (see 8.4.4.12.2 ). The validateTypeOwnedMultiplicity constraint requires that a Type have at most one ownedMember that is a Multiplicity . If a Type has such an owned Multiplicity , then it is the typeWithMultiplicity of that Multiplicity . The value of the Multiplicity is then the cardinality of its typeWithMultiplicity and, therefore, the type (co-domain) of the Multiplicity restricts that cardinality. The cardinality of a Type is defined generally as follows: • For a Classifier , the cardinality is the number of basic instances of the Classifier , that is, those instances that represent the things classified by the Classifier and are not instances of any subtype of the Classifier that is a Feature . • For a Feature , the cardinality is the number of values of the Feature for any specific featuring instance (where duplicate features are included in the count, if the Feature is non-unique). However, there are special rules for the semantics of Multiplicity for end Features (see 8.4.4.5 ). The checkMultiplicityTypeFeaturing constraint requires that a Multiplicity with a Feature as its owningNamespace have the same featuringTypes (domain) as that Feature , and, otherwise, have no featuringTypes . In particular, a Multiplicity is owned by a Feature that has an owningType , then the featuringType of the Multiplicity is the owningType of its owning Feature . This means that the Multiplicity has a value for each instance of the featuringType that is the cardinality of the instances of its owning Feature that are featured by that same instance of the featuringType . classifier C1 { feature f { // Implied TypeFeaturing by C2. // Gives the cardinality of the values of f for each // instance of C2 (which is constrained to be 1). multiplicity subsets Base::exactlyOne; } } If a Type does not have an owned Multiplicity , but has ownedSpecializations , then its cardinality is constrained by the Multiplicities for all of the general Types of those ownedSpecializations (i.e., its direct supertypes). In practice, this means that the effective Multiplicity of the Type is the most restrictive Multiplicity of its direct supertypes. classifier C2 { feature f { multiplicity subsets Base::exactlyOne; } feature g { multiplicity subsets Base::oneToMany; } // The multiplicities exactlyOne and oneToMany both apply // to h, which means that, effectively, it has a multiplicity // of exactlyOne. feature h subsets f,g; } 276 Kernel Modeling Language v1.0 -8.4.4.12.2 Multiplicity Ranges A MultiplicityRange is a Multiplicity whose co-domain is given as an inclusive range of values of the type Natural . It thus constrains the cardinality of its typeWithMultiplicity to be within this range. A MultiplicityRange of the form [expr_1.. expr_2] represents the range of values that are greater than or equal to the result of the Expression expr_1 and less than or equal to the result of the Expression expr_2 . Note that all other Natural values are less than the value of * , representing positive infinity, so the MultiplicityRange [0..*] is the range of all values of Natural (that is, no restriction on cardinality). A MultiplicityRange having only a single expression: [expr] is interpreted in one of the following ways: • If expr evaluates to * , then it is equivalent to the range [0..*] (i.e., the entire extent of Natural). • Otherwise, it is equivalent to [expr..expr] (that is, the cardinality is restricted to the single value given by the result of expr ). Note. The KerML textual notation grammar only allows LiteralExpressions and FeatureReferenceExpressions as the bound Expressions in a MultiplicityRange (see 8.2.5.11 ). However, the abstract syntax allows arbitrary Expressions (see 8.3.4.11 ). The checkMultiplicityRangeExpressionTypeFeaturing constraint requires that the bound Expressions of a MultiplicityRange have the same featuringTypes as the MultiplicityRange . The featuringTypes of a MultiplicityRange are determined by the checkMultiplicityTypeFeaturing constraint ( 8.4.4.12.1 ). If the MultiplicityRange has an owningNamespace that is not a Feature , then it has no featuringTypes , so its domain is implicitly Base::Anything , and its bound Expressions can only reference other Features in that context. package P { // Implicitly featured by Anything. feature n : ScalarValues::Natural; classifier C3 { // An ownedMember, not an ownedFeature. // Implicitly featured by Anything. // Implied Subsetting of Base::naturals. multiplicity [P::n]; } } If the MultiplicityRange has an owningNamespace that is a Feature , then it is required to have featuringTypes that are the same as the owning Feature . In particular, if its owning Feature has an owningType , then the featuringType of the MultiplicityRange (and its bound Expressions ) is the owningType of its owning Feature . classifier C4 { feature n : ScalarValues::Natural; feature m : Member { // Implied TypeFeaturing by C4. // Implied Subsetting of Base::naturals. multiplicity [1..C4::n]; Kernel Modeling Language v1.0 277 -} } 8.4.4.13 Metadata Semantics Abstact syntax reference: 8.3.4.12 8.4.4.13.1 Metaclasses The checkMetaclassSpecialization constraint requires that Metaclasses specialize the base Metaclass Metaobjects::Metaobject (see 9.2.16.2.1 ). A Metaclass is a kind of Structure (see 8.4.4.4 ), but it's instances are Metaobjects that are part of the structure of a model itself, rather than as an instance in the system represented by the model. The KerML library model is a reflective model of the MOF abstract syntax for KerML, containing one KerML Metaclass corresponding to each MOF metaclass in the abstract syntax model (see 9.2.17 for more details on the relationship between the KerML model and the abstract syntax). 8.4.4.13.2 Metadata Features A MetadataFeature is both a Feature typed by a Metaclass and an AnnotatingElement that annotates other Elements in a model. The checkMetadataFeatureSpecialization requires that MetadataFeatures specialize the Feature Metaobjects::metaobjects (see 9.2.16.2.2 ). At a meta-level, a MetadataFeature can be treated as if the reflective Metaclasses of its annotatedElements were its featuringTypes . In this case, the MetadataFeature defines a map from its annotatedElements , as instances of their Metaclasses , to a single instance of the metaclass of the MetadataFeature . Further, a model-level evaluable Expression is an Expression that can be evaluated using metadata available within a model itself (see 8.4.4.9 ). If a model-level evaluable Expression is evaluated on such metadata according to the regular semantics of Expressions , then the result will correspond to the static evaluation of the Expression within the model. Therefore, if a MetadataFeature is instantiated as above, the binding of its features to the results of evaluating the model-level evaluable value Expressions of its FeatureValues can be interpreted according to the regular semantics of FeatureValues (see 8.4.4.11 ) and BindingConnectors (see 8.4.4.6 ). When a value Expression is model-level evaluated (as described in 8.4.4.9 ), its target is the MetadataFeature that owns the featureWithValue . This means that the value Expression for a nested Feature of a MetadataFeature may reference other Features of the MetadataFeature , as well as Features with no featuringTypes or Anything as a featuringType . 8.4.4.13.3 Semantic Metadata A semantic MetadataFeature is one that directly or indirectly specializes Metaobjects::SemanticMetadata (see 9.2.16.2.3 ) It is used to introduce a user-defined specialization constraint on the Type annotated by the MetadataFeature . SemanticMetadata has the Feature baseType typed by the reflective Metaclass KerML::Type (see 9.2.17 ) that is redefined by a semantic MetadataFeature . The target of the effective specialization constraint defined by a semantic MetadataFeature is determined by the value Expression bound to its baseType Feature using a FeatureValue (see 8.4.4.11 ), which is evaluated as a model-level evaluable Expression (see 8.4.4.9 ). Specifically, for each semantic MetadataFeature annotating a Type , the checkMetadataFeatureSemanticSpecialization constraint requires that the annotated Type directly or indirectly specialize the Type bound to the baseType of the MetadataFeature , unless the annotated Type is a Classifier and the baseType is a Feature . For the case when the Type is a Classifier and the baseType is a Feature , the constraint requires that the annotated Classifier directly or indirectly specialize each type of the baseType Feature . 278 Kernel Modeling Language v1.0 -8.4.4.14 Packages Semantics Abstract syntax reference: 8.3.4.13 Packages do not have instance-level semantics (they do not affect instances). The filterConditions of a Package are model-level evaluable Expressions that are evaluated as described in 8.4.4.9 . All filterConditions are checked against every Membership that would otherwise be imported into the Package if it had no filterConditions . A Membership shall be imported into the Package if and only if every filterCondition evaluates to true either with no target Element , or with any MetadataFeature of the memberElement of the Membership as the target Element . Kernel Modeling Language v1.0 279 -280 Kernel Modeling Language v1.0 -9Model Libraries 9.1 Model Libraries Overview A model library is a collection of library models that can be reused across many user models. KerML includes three standard model libraries: the Semantic Library (see 9.2 ), the Data Type Library (see 9.3 ), and the Function Library (see 9.4 ). Each library model in these standard model libraries consists of a single root namespace with one top- level element that is a standard library package, with no subpackages. All of these library models are described for reference in subclauses of this clause. The normative machine-readable representation for each of these model libraries is a project interchange file, formatted according to the standard for KerML model interchange given in Clause 10 . Each library model is packaged as a model interchange file in the project interchange file for its corresponding model library. Regardless of whether such a library model is interchanged in textual notation, XMI or JSON format, the elementId for any Element in the library model shall be a name-based (version 5, using SHA-1) UUID (see [UUID, 14.3]), which are constructed from a name space identifier and a name determined as follows: • For the top-level standard library package: ◦ name space identifier shall be the NameSpace_URL UUID, as given in [UUID, D.9] (which is 6ba7b811-9dad-11d1-80b4-00c04fd430c8 ). ◦ name shall be the URL constructed by prepending https://www.omg.org/spec/KerML/ to the name of the package, converted to bytes using a UTF-8 encoding (see [ISO10646, Annex D]). • For any element directly or indirectly contained in the top-level standard library package (for which that package will be the libraryNamespace ): ◦ name space identifier shall be the UUID of the top-level standard library package (as determined above). ◦ name shall be the string returned by the path() operation of the element, converted to bytes using a UTF-8 encoding (see [ISO10646, Annex D]). (See 8.3.2.1.2 for the specification of the path() operation for Element and 8.3.2.1.3 and 8.3.2.4.8 for its overridings for Relationship and owningMembership , respectively.) The elementIds constructed as given above shall be normative across all forms of interchange of the library models. For Elements with non-null qualifiedNames , in particular, the elementIds shall remain stable for future versions of the library models, though future revisions of this specification may deprecate certain existing Elements and their names, or introduce new Elements with new names and hence UUIDS that are distinct (with a high probability). A tool may also use the above approach for generating the UUIDS for Elements of models other than standard library models. However, it is then the responsibility of the tool to assign a unique URL to each top-level element in a model, since this is required in order to ensure the uniqueness of the generated UUIDs. Note also that, if a model undergoes frequent changes in the names and/or ordering of Elements , this may result in unexpected changes or reassignment of generated UUIDs. 9.2 Semantic Library 9.2.1 Semantic Library Overview The Semantic Library is a collection of KerML models that are part of the semantics of the metamodel (see Clause 8 ). They are reused when constructing KerML user models (instantiating the abstract syntax), as specified by constraints and semantics of metaelements, such as Types being required to specialize Anything from the library and Behaviors specializing Performance (see 8.4 ). The library can be specialized for particular applications, such as systems modeling. Kernel Modeling Language v1.0 281 -The Semantic Library contains a set of packages, one for each library model, as described in a subsequent subclauses. The following are the major areas covered in the Semantic Library. 1. The Base library model (see 9.2.2 ) begins the Specialization hierarchy for all KerML Types , including the most general Classifier Anything and the most general Feature things . It also contains the most general DataType DataValue and its corresponding Feature dataValues . The Links library model (see 9.2.3 ) specializes Base to provide the semantics for Associations between things. 2. The Occurrences library model (see 9.2.4 ) introduces Occurrence , the most general Class of things that exist or happen in time and space, as well as the basic temporal Associations between them. The Objects library model (see 9.2.5 ) specializes Occurrences to provide a model of Objects and LinkObjects , giving semantics to Structures and AssociationStructures , respectively. The Performances library model (see 9.2.6 ) specializes Occurrences to provide a model of Performances and Evaluations , giving semantics to Behaviors and Expressions , respectively. Temporal associations can be used by Successions to specify the order in which Performances are carried out during other Performances , or when Objects exist in relation to each other, or combinations involving Performances and Objects . The Transfers library model (see 9.2.7 ) models flow of things between Occurrences , giving semantics to Interactions and Flows . The FeatureAccessPerformances library model (see 9.2.8 ) defines specialized Performances for access and modifying the values of features at specific points in time. 3. The ControlPerformances , TransitionPerformances and StatePerformances library models (see 9.2.9 , 9.2.10 , and 9.2.11 ) provide for coordination of multiple Performances to carry out some task by using them as types of Steps in an overall containing Behavior . KerML does not provide syntax specific to these library elements (e.g., KerML does not have any "control node" or "state machine" syntax), though it is expected that other languages built on KerML, and using these library models, can add syntax as needed by their applications. 9.2.2 Base 9.2.2.1 Base Overview This library model begins the Specialization hierarchy for all KerML Types (see 8.3.3.1 and 8.4.3.2 ), starting with the most general Classifier Anything , the type of the most general Feature things , which classify everything in the modeled universe and the relations between them, respectively. Being the most general library elements for their metaclasses means all Classifiers and Features in models, including in libraries, specialize them, respectively. They are specialized into the most general DataType DataValue , the type of dataValues , the most general Feature typed by DataTypes , respectively (see 8.3.4.1 ). DataValues are Anything that can only be distinguished by how they are related to other things (via Features and Assocations ). These are further specialized into Natural and naturals , respectively, an extension for mathematical natural numbers (integers zero and greater) extended with a number greater than all the integers ("infinity"), but treated like one, notated as * (see 9.3.2.1 ). The Feature self of Anything relates each thing in the universe to itself only (see SelfLinks in 9.2.3.1 ). 9.2.2.2 Elements 9.2.2.2.1 Anything Element Classifier Description Anything is the most general Classifier (M1 instance of M2 Classifier ). All other M1 Elements (in libraries or user models) specialize it (directly or indirectly). Anything is the type for things , the most general 282 Kernel Modeling Language v1.0 -Feature . Since FeatureTyping is a kind of Specialization , this means that things also specializes Anything . General Types None. Features self : Anything {subsets things} The source of a SelfLink of this thing to itself. self is thus a feature that relates everything to itself. It is also the value of the nested that feature of all other things featured by this thing. Constraints None. 9.2.2.2.2 DataValue Element DataType Description A DataValue is Anything that can only be distinguished by how it is related to other things (via Features ). DataValue is the most general Datatype (M1 instance of M2 Datatype ). All other M1 Datatypes (in libraries or user models) specialize it (directly or indirectly). General Types Anything Features None. Constraints None. 9.2.2.2.3 dataValues Element Feature Description dataValues is a specialization of things restricted to type DataValue . All other Features typed by DataValue or its specializations (in libraries or user models) specialize it (directly or indirectly). General Types DataValue Kernel Modeling Language v1.0 283 -things Features None. Constraints None. 9.2.2.2.4 exactlyOne Element MultiplicityRange Description exactlyOne is a MultiplicityRange requiring a cardinality of exactly one. General Types naturals Features None. Constraints None. 9.2.2.2.5 naturals Element Feature Description naturals is a specialization of dataValues restricted to type Natural . It is the root Feature of all multiplicities, which map from a Feature to the set of Natural numbers representing allowable cardinalities of the Feature . General Types dataValues Natural Features None. Constraints 284 Kernel Modeling Language v1.0 -None. 9.2.2.2.6 oneToMany Element MultiplicityRange Description oneToMany is a MultiplicityRange requiring a cardinality of one or more. General Types naturals Features None. Constraints None. 9.2.2.2.7 things Element Feature Description things is the most general Feature (M1 instance of M2 Feature ). All other Features (in libraries or user models) specialize it (subset or redefine, directly or indirectly). It is typed by Anything . things has multiplicity lower bound 1 because, for any featuring instance, it includes at least that instance as the value of Anything::self . General Types Anything Features that : Anything For each value of things , the "featuring instance" of that value. Formally, for any sequence s classified by things , the that includes a sequence whose prefix is s, followed by the second-to-last element of s. This is enforced by declaring Anything::self to be the chaining of things.that , restricting that to the single value of self for all things . Constraints None. 9.2.2.2.8 zeroOrOne Kernel Modeling Language v1.0 285 -Element MultiplicityRange Description zeroOrOne is a MultiplicityRange requiring a cardinality of zero or one. General Types naturals Features None. Constraints None. 9.2.2.2.9 zeroToMany Element MultiplicityRange Description zeroToMany is a MultiplicityRange requiring a cardinality of zero or more. General Types naturals Features None. Constraints None. 9.2.3 Links 9.2.3.1 Links Overview This library model introduces the most general Association Link , the type of links , the most general Feature typed by Associations (see 8.3.4.4 and 8.4.4.5 ). The participant Feature of Link generalizes all associationEnds (directly or indirectly), identifying the things being linked by (at the "ends" of) each Link (exactly one thing per end, which might be the same things). Link is specialized into BinaryLink , the most general Association with exactly two associationEnds , source and target , which subset participant and identify the two things linked, which might be the same thing. BinaryLink is the type of binaryLinks , the most general Feature typed by binary Associations . They are specialized into SelfLink and selfLinks , respectively, for links that have the same thing on both ends, identified by thisThing and thatThing , redefining source and target , respectively. These are used by BindingConnectors to specify that Features have the same values (see 7.4.6.3 ). SelfLinks are not in time or space (they are not Occurrences , see 9.2.4 ). 286 Kernel Modeling Language v1.0 -9.2.3.2 Elements 9.2.3.2.1 BinaryLink Element Association Description BinaryLink is a Link with exactly two participant Features ("binary" Association ). All other binary Associations (in libraries or user models) specialize it (directly or indirectly). General Types Link Features participant : Anything [2] {redefines participant, ordered, nonunique} The participants of this BinaryLink , which are restricted to be exactly two. source : Anything {subsets participant} The participant that is the source of this BinaryLink . target : Anything {subsets participant} The participant that is the target of this BinaryLink . Constraints None. 9.2.3.2.2 binaryLinks Element Feature Description binaryLinks is a specialization of links restricted to type BinaryLink . All other Features typed by BinaryLink or its specializations (in libraries or user models) specialize it (directly or indirectly). General Types links BinaryLink Features None. Constraints Kernel Modeling Language v1.0 287 -None. 9.2.3.2.3 Link Element Association Description Link is the most general Association (M1 instance of M2 Association ). All other Associations (in libraries or user models) specialize it (directly or indirectly). Specializations of Link are domains of Features subsetting Link::participant , exactly as many as associationEnds of the Association classifying it, each with multiplicity 1. Values of Link::participant on specialized Links must be a value of at least one of its subsetting Features . General Types Anything Features participant : Anything [2..*] {ordered, nonunique} The participants that are associated by this Link . Constraints None. 9.2.3.2.4 links Element Feature Description links is a specialization of things restricted to type Link . It is the most general feature typed by Link . All other Features typed by Link or its specializations (in libraries or user models) specialize it (directly or indirectly). General Types things Link Features None. Constraints None. 9.2.3.2.5 SelfLink 288 Kernel Modeling Language v1.0 -Element Association Description SelfLink is a BinaryLink where the sourceParticipant and targetParticipant are the same. All other BinaryLinks where this is the case specialize it (directly or indirectly). General Types SelfSameLifeLink BinaryLink Features sameThing : Anything {subsets thisThing, redefines target} The target participant of this SelfLink , which must be the same as the source participant . Crosses thisThing.self2 . self2 : Anything Owned cross feature for sameThing , with cross multiplicity 1...1 thisThing : Anything {subsets sameThing, redefines source} The source participant of this SelfLink , which must be the same as the target participant . Crosses sameThing.self . Constraints None. 9.2.3.2.6 selfLinks Element Feature Description selfLinks is a specialization of binaryLinks restricted to type SelfLink . It is the most general BindingConnector . All other BindingConnectors (in libraries or user models) specialize it (directly or indirectly). General Types SelfLink binaryLinks Features sameThing : Anything {redefines sameThing, target} Kernel Modeling Language v1.0 289 -thisThing : Anything {redefines source, thisThing} Constraints None. 9.2.4 Occurrences 9.2.4.1 Occurrences Overview Occurrences This library adds a model of things existing in time and space, starting with Occurrence , the most general Class (see 8.3.4.2 ), which classifies Anything that takes up time and space, and occurrences , the most general Feature typed by Classes . Occurrences can take up the same or overlapping time and space when they represent different things happening or existing in it. For example, the time and space taken by a room might have air moving in it, as well as light, radio waves, and so on. Occurrences divide into Objects and Performances (see 9.2.5.1 and 9.2.6.1 , respectively), corresponding to Classes dividing into Structures and Behaviors (see 7.4.4 and 7.4.7.1 , respectively). This subclause covers what is in common between Objects and Performances . Lives and Portions A Life is an Occurrence that takes up the entire time and space of anything that happens or exists. All Occurences , including Lives , identify other Occurrences as their portions (the most general portion Feature , see 9.2.4.2.13 and 8.3.3.3.4 ), which happen or exist in some or all of their time and space. Portions are the same "thing" as the Occurrences they are a portionOf , just considered for a potentially smaller period of time and region in space. Occurrences are always a portionOf themselves, with Lives being a portionOf only themselves. Occurrences have the same Life as those they are a portionOf , identified by portionOfLife . This means following portionOf repeatedly will always reach a single Life , even though some Occurrences along the way might be a portionOf of more than one other Occurrence . SelfSameLifeLinks include SelfLinks ( Links between each thing and itself, see 9.2.3.1 ), as well as Links between Occurrences that are a portionOf the same Life (have the same portionOfLife ). Time and Space Slices Time slices are portions that take up all the space of their larger Occurrences within a potentially smaller period of time than the whole Occurrence , identified as timeSlices of the Occurrences they are a portionOf . Time slices might have Feature values and Links to other things peculiar to their smaller period of time. Occurrences are always timeSlicesOf themselves. The snapShots of Occurrences are timeSlices that take no time. The earliest snapShot of an Occurrence is its startShot , the latest is its endShot . All the others happen during its middleTimeSlice . Occurrences with a startShot the same as their endShot take no time, have no middleTimeSlice , and vice-versa. Space slices are portions that include all the time of their larger Occurrences , but not necessary all their space, identified as spaceSlices of the Occurrences they are a portionOf . Space slices might have Feature values and Links to other things peculiar to their smaller region in space. Occurrences are always spaceSlicesOf themselves. The spaceShots of Occurrences are spaceSlices that have a lower innerSpaceDimension than the Occurrences they are spaceSlicesOf , which is the number of variables needed to identify any space point occupied by an Occurrence , without regard to higher dimensional spaces in which it might be embedded. For example, the innerSpaceDimension of a Curve is 1 (see 9.2.5.1 ), because points on it can be identified by the distance from one end, even if the curve bends in two or three dimensions. A Curve can be a spaceShot of a Surface or Body , which have innerSpaceDimension of 2 and 3, respectively. The spaceSlices of an 290 Kernel Modeling Language v1.0 -Occurrence that are not spaceShots must have the same innerSpaceDimension as the Occurrence . How much an Occurrence bends in higher dimensions is its outerSpaceDimension (see 9.2.5.1 ). For example, the outerSpaceDimension of a planar curve is 2 or 1 ( Line ), while it is 3 for non-planar. Temporal and Spatial Associations Occurrences can be completely separated in time or space, or both, as indicated by these specialized Links : • HappensBefore Links between Occurrences indicate they are completely separate in time, with one happening or existing completely before another. The predecessors and successors of Occurrences are those that HappenBefore them and after them (those that they HappenBefore ), respectively. HappensJustBefore Links are HappensBefore Links between Occurrences where there is no possibility of other Occurrences happening or existing in the time between them. The immediatePredecessors and immediateSuccessors of Occurrences are those that HappenJustBefore them and just after them (those that they HappenJustBefore ), respectively. Occurrences separated in time are not necessarily separated in space. • OutsideOf Links between Occurrences indicate they are completely separate in space, without specifying their relative positions (such as above or to the left). The outsideOccurrences of Occurrences are those that exist OutsideOf them. JustOutsideOf Links are OutsideOf Links between Occurrences where there is no possibility of other Occurrences happening or existing in the space between at least some of their spaceBoundaries , see space boundaries below. The justOutsideOccurrences of Occurrences are those that exist JustOutsideOf them. Occurrences separated in space are not necessarily separated in time. Without Links between Occurrences are provided as a convenience to indicate one HappenBefore another or is OutsideOf the other or both (they do not overlap at all in space-time), with the withoutOccurrences of an Occurrence being the ones that are Without it. Occurrences can completely overlap others in time or space, or both, as indicated by these specialized Links : • HappensDuring Links between Occurrences indicate one happens or exists completely within the time taken by another, with the timeEnclosedOccurrences of an Occurrence being the ones that HappenDuring it. Occurrences overlapping in time do not necessarily overlap in space. • InsideOf Links between Occurrences indicate one happens or exists completely within the space taken by another, with the spaceEnclosedOccurrences of an Occurrence being the ones that InsideOf it. Occurrences overlapping in space do not necessarily overlap in time. Within Links between Occurrences are provided as a convenience to indicate one HappensDuring another and is InsideOf that other (one is completely overlapped by the other in space-time), with the spaceTimeEnclosedOccurrences of an Occurrence being the ones that are WithIn it. Occurrences cannot be linked by both HappensBefore and HappensDuring , OutsideOf and InsideOf , or Within and Without . They also cannot HappenBefore or be OutsideOf or Without themselves, but always HappensDuring and are InsideOf and Within themselves. When an Occurrence HappensBefore another, all Occurrences that HappenDuring the earlier one (including itself) also HappenBefore those that HappenDuring the later one (including itself). Occurrences that HappenDuring each other both ways (circularly) happen or exist at the same time, which is provided for convenience by HappensWhile , a specialization of HappensDuring , with the timeCoincidentOccurrences of an Occurrence being the ones that HappenWhile it. Occurrences that are InsideOf each other both ways occupy exactly the same space, even though they might happen or exist at separate times. Occurrences that are Within each other both ways happen at exactly the same time and occupy exactly the Kernel Modeling Language v1.0 291 -same space, which is provided for convenience by WithinBoth , a specialization of Within , with the spaceTimeCoincidentOccurrences of an Occurrence being the ones that are WithinBoth it. The Links above to do not take up time or space, they are temporal and spatial relations between things that do (they are disjoint with LinkObject , see 9.2.5.1 ). Other Time-Space Relations The time and space taken by an Occurrence can be related in three ways to the time and space taken by others, identified by the Features below. An Occurrence with values for these Features takes the same time and space as • unionOf : taken by all the other Occurrences together. • intersectionOf : is common to all the other Occurrences . • differencesOf : the first other Occurrence that is not taken by the rest. The values of the above Features are Sets of Occurrences to enable the time and space of an Occurrence to be specified in multiple ways, with each set taken as a complete specification of the time and space taken by the Occurrence . Space Boundaries and Interiors The spaceSlices of each Occurrence are divided into a spaceBoundary , which is a spaceShot , and a spaceInterior , which is a spaceSlice that is not a spaceShot (has the same innerSpaceDimension as the Occurrence ). They are JustOutsideOf each other and union (see below) to the entire Occurrence . Space boundaries cannot have a spaceBoundary , which means they also cannot have a spaceInterior , indicated by isClosed=true , For example, a ball has a sphere as its spaceBoundary , but the sphere isClosed . A spaceBoundary might have spaceSlices that are also closed and have the same innerSpaceDimension as the spaceBoundary (not among its spaceShots ). In some cases one of these spaceSlices surrounds the others, identified as the outer , a nested feature of spaceBoundary , and the others as the inner ones. This means the outer one can be taken as the spaceBoundary of another Occurrence with a spaceInterior that completely includes the inners . The inner spaceBoundaries can also be taken as spaceBoundaries of their own Occurrences , the spaceInteriors of which are identified as the innerSpaceOccurrences ("holes") of the Occurrence having the spaceBoundary . These two cases are covered by SurroundedBy Links between Occurrences , with the surroundedByOccurrences of an Occurrence being the ones they are SurroundedBy . MatesWith Links are JustOutsideOf Links between Occurrences indicating that they union (see below) to an Occurrence with a spaceBoundary but no spaceInterior . This means there is no possibility of other Occurrences happening or existing in the space between them. JustOutsideOf Links additionally include those between Occurrences where only some of their spaceSlices (of their spaceBoundaries ) are linked by MatesWith . 9.2.4.2 Elements 9.2.4.2.1 HappensBefore Element Association Description HappensBefore is a Without Association linking an earlierOccurrence to a laterOccurrence , indicating that the Occurrences do not overlap in time (not necessarily in space, see OutsideOf ; none of their snapshots happen at the same time), and the earlierOccurrence happens first. This means no Occurrence 292 Kernel Modeling Language v1.0 -HappensBefore itself. Every Occurrence that HappensDuring the earlierOccurrence (including itself) also HappensBefore every Occurrence that HappensDuring the laterOccurrence (including itself). General Types Without HappensLink Features earlierOccurrence : Occurrence {subsets sourceOccurrence, redefines separateOccurrenceToo} The participant of this HappensBefore link that happens (ends) earlier than the other participant (starts). Crosses laterOccurrence.predecessors . laterOccurrence : Occurrence {subsets targetOccurrence, redefines separateOccurrence} The participant of this HappensBefore link that happens later than (starts after) the other participant (ends). Crosses earlierOccurrence.successors . Constraints None. 9.2.4.2.2 happensBeforeLinks Element Feature Description happensBeforeLinks is a specialization of binaryLinks restricted to type earlierOccurrence . It is the most general Succession (M1 instance of M2 Succession ). All other Successions (in libraries or user models) specialize it (directly or indirectly). General Types HappensBefore binaryLinks Features earlierOccurrence : Occurrence {redefines source, earlierOccurrence} laterOccurrence : Occurrence {redefines laterOccurrence, target} Constraints None. 9.2.4.2.3 HappensDuring Element Kernel Modeling Language v1.0 293 -Association Description HappensDuring links its shorterOccurrence to its longerOccurrence , indicating that the shorterOccurrence completely overlaps the longerOccurrence in time (not necessarily in space, see InsideOf ; all snapshots of the shorterOccurrence happen at the same time as some snapshot of the longerOccurrence ). This means every Occurrence HappensDuring itself and that HappensDuring is transitive. Every Occurrence that HappensDuring the longerOccurrence also HappensBefore the shorterOccurrence . The shorterOccurrence also HappensBefore every Occurrence that the longerOccurrence does. General Types HappensLink Features happensDuring : Occurrence [1..*] Occurrences that completely overlap a shorterOccurrence in time (not necessarily in space, see insideOf ; they start when this shorterOccurrence does or earlier and end when the shorterOccurrence does or later), including the shorterOccurrence . Owned cross feature for longerOccurrence . longerOccurrence : Occurrence {redefines targetOccurrence} The participant in this HappensDuring Link that completely overlaps the other in time. Crosses shorterOccurrence.happensDuring . shorterOccurrence : Occurrence {redefines sourceOccurrence} The participant in this HappensDuring Link that is completely overlapped by the other in time. Crosses longerOccurrence.timeEnclosedOccurrences . Constraints None. 9.2.4.2.4 HappensJustBefore Element Association Description HappensJustBefore is HappensBefore asserting that there is no possibility of other Occurrences happening in the time between the earlierOccurrence and laterOccurrence . General Types HappensBefore Features earlierOccurrence : Occurrence {redefines earlierOccurrence} 294 Kernel Modeling Language v1.0 -Crosses laterOccurrence.immediatePredecessors . laterOccurrence : Occurrence {redefines laterOccurrence} Crosses earlierOccurrence.immediateSuccessors . Constraints None. 9.2.4.2.5 HappensLink Element Association Description HappensLink is the most general Association that asserts temporal relationships between a sourceOccurrence and a targetOccurrence . They cannot happen in time (be Occurrences ), making them disjoint with LinkObject . General Types BinaryLink Features sourceOccurrence : Occurrence {redefines source} targetOccurrence : Occurrence {redefines target} Constraints None. 9.2.4.2.6 HappensWhile Element Association Description HappensWhile is a HappensDuring and its inverse. This means the linked Occurrences completely overlap each other in time (they happen at the same time) all snapshots of each Occurrence happen at the same time as one of the snapshots of other. This means every Occurrence HappensWhile itself and that HappensWhile is transitive. General Types HappensDuring Features happensWhile : Occurrence [1..*] {subsets happensDuring, timeCoincidentOccurrences} Kernel Modeling Language v1.0 295 -thatOccurrence : Occurrence {redefines longerOccurrence} Crosses thisOccurrence.timeCoincidentOccurrences . thisOccurrence : Occurrence {redefines shorterOccurrence} Crosses thatOccurrence.timeCoincidentOccurrences . Constraints None. 9.2.4.2.7 IncomingTransferSort Element Predicate Description A Predicate of two Transfers that is true when the first should be accepted instead of the other. General Types BooleanEvaluation Features in t1 : Transfer In parameter. in t2 : Transfer In parameter. return t1First : Boolean Return parameter. Constraints None. 9.2.4.2.8 InnerSpaceOf Element Association Description InnerSpace is an OutsideOf asserting that the space surrounded by an inner space boundary of one occurrence ( outerSpace ) is completely occupied by another occurrence ( innerSpace ). General Types 296 Kernel Modeling Language v1.0 -OutsideOf Features innerSpace : Occurrence {redefines separateSpace} The participant of this InnerSpaceOf Link that completely occupies the space surrounded by an inner space boundary of the other. Crosses outerSpace.innerSpaceOccurrences . outerSpace : Occurrence {redefines separateSpaceToo} The participant of this InnerSpaceOf Link with an inner space boundary is completely occupied by the other. Constraints None. 9.2.4.2.9 InsideOf Element Association Description InsideOf is a BinaryLink between its smallerSpace and largerSpace , indicating that the largerSpace completely overlaps the smallerSpace in space (not necessarily in time, see HappensDuring; all four dimensional points of the smallerSpace are in the spatial extent of the largerSpace ). This means every Occurrence is InsideOf itself and that InsideOf is transitive. General Types SpaceLink Features insideOf : Occurrence [1..*] Occurrences that completely overlap a smallerSpace in space (not necessarily in time, see happensDuring ), including the smallerSpace . Owned cross feature for largerSpace . largerSpace : Occurrence {redefines target} The participant in this InsideOf Link that completely overlaps the other in space. Crosses smallerSpace.insideOf . smallerSpace : Occurrence {redefines source} The participant in this InsideOf Link that is completely overlapped by the other in space. Crosses largerSpace.spaceEnclosedOccurrences . Constraints None. 9.2.4.2.10 JustOutsideOf Kernel Modeling Language v1.0 297 -Element Association Description JustInsideOf is an OutsideOf Association linking two Occurrences that have some space slices with no space between them. General Types OutsideOf Features separateSpace : Occurrence {redefines separateSpace} Crosses separateSpaceToo.justOutsideOfOccurrences . separateSpaceToo : Occurrence {redefines separateSpaceToo} Crosses separateSpace.justOutsideOfOccurrences . Constraints None. 9.2.4.2.11 Life Element Class Description Life is the class of Occurrences that are "maximal portions". That is, they are only portions of themselves. General Types Occurrence Features None. Constraints None. 9.2.4.2.12 MatesWith Element Association Description 298 Kernel Modeling Language v1.0 -General Types JustOutsideOf Features matingSpace : Occurrence {redefines separateSpace} Crosses matingSpaceToo.matingOccurrences . matingSpaceToo : Occurrence {redefines separateSpaceToo} Crosses matingSpace.matingOccurrences . Constraints None. 9.2.4.2.13 Occurrence Element Class Description An Occurrence is Anything that happens over time and space (the four physical dimensions). Occurrences can be portions of another Occurrence within time and space, including slices in time, leading to snapshots that take zero time. General Types Anything Features difference : Occurrence [0..1] A (nested) Feature of differencesOf identifying an Occurrence that is the intersectionsOf of the Occurrences identified by interdiff ( minuend and interdiff.notSubtrahend ). differencesOf : OrderedSet [0..*] Ordered sets of Occurrences , where the time and space taken by first Occurrence in each set ( minuend ) that is not in the time and space taken by the remaining Occurrences ( subtrahend , resulting in difference ) is the same as taken by this Occurrence (all four dimensional points in the minuend that are not in any subtrahend are at the same time and space as those in this Occurrence ). dispatchScope : Occurrence elements : Occurrence [0..*] A nested Feature of unionsOf , intersectionsOf , and differencesOf for the elements of each of their (Ordered)Sets endShot : Occurrence {subsets snapshots} Kernel Modeling Language v1.0 299 -The snapshot of this Occurrence that happensAfter all its other snapshots . immediatePredecessors : Occurrence [0..*] {subsets predecessors} Occurrences that start just after this Occurrence ends, with no possibility of other Occurrences happening in the time between them. immediateSuccessors : Occurrence [0..*] {subsets successors} Occurrences that end just before this Occurrence starts, with no possibility of other Occurrences happening in the time between them. incomingTransfer : Transfer [0..*] incomingTransferSort : IncomingTransferSort [0..*] Determines which Transfers to accept when multiple are available and which of the unaccepted Transfers are never to be accepted (dispatched), by comparing two Transfers at a time. Defaults to earlierFirstIncomingTransferSort , which is true if the first Transfer ends (arrives) before the other. incomingTransferToSelf : Transfer [0..*] {subsets incomingTransfer} Transfers for which this Occurrence is the targetParticipant . inner : Occurrence [0..*] A spaceSlice of spaceBoundary , see spaceBoundary . innerSpaceDimension : Natural The number of variables needed to identify space points in this Occurrence , from 0 to 3, without regard to higher dimensional spaces it might be embedded in. For example, the innerSpaceDimension of a curve is 1, even if it twists in three dimensions, see outerSpaceDimension . innerSpaceOccurrences : Occurrence [0..*] {subsets outsideOfOccurrences} Occurrences that completely occupy the space surrounded by an inner space boundary of this occurrence. interdiff : Set [0..*] A (nested) Feature of differencesOf identifying a set that includes its minuend and all Occurrences that are not in its subtrahend . intersection : Occurrence [0..1] A (nested) Feature of intersectionsOf identifying an Occurrence that a) is completely Within (the space and time of) all intersectionsOf elements , and b) satisfies the conditions of the same element 's nonIntersection . intersectionsOf : Set [0..*] Sets of Occurrences , where the time and space taken in common between the Occurrences in each set ( intersectionsOf::intersection ) is at the same as taken by this Occurrence (all four dimensional points common to the Occurrences in each set are at the same time and space as those in this Occurrence ). /isClosed : Boolean 300 Kernel Modeling Language v1.0 -True if this Occurrence has a spaceBoundary , false otherwise. isDispatch : Boolean Determines whether the same incoming transfer can be accepted more than once by StatePerformances composed under dispatchScope . It defaults to true for Performances , and false for other Occurrences (including Objects ). isRunToCompletion : Boolean Determines whether TransitionPerformances composed under runToCompletionScope can happen during StatePerformance entry Performances composed under this Occurrence . justOutsideOfOccurrences : Occurrence [0..*] {subsets outsideOfOccurrences} Occurrences that have no space between some of their spaceSlices and some spaceSlices of this Occurrence . localClock : Clock A local Clock to be used as the corresponding time reference for this Occurrence and, by default, all ownedOccurrences . By default this is the singleton Clocks::universalClock matingOccurrences : Occurrence [0..*] {subsets justOutsideOfOccurrences} Occurrences that have no space between them and this one. middleTimeSlice : Occurrence [0..1] {subsets timeSlices} timeSlice of this Occurrence that takes all of the time between its startShot and endShot . Occurrences do not have middleTimeSlice if their startShot is the same as their endShot (such as being a snapShot of another Occurrence ), otherwise they do. minuend : Occurrence [0..1] {subsets elements, ordered} A (nested) Feature of differencesOf that identifies the first Occurrence in its elements . nonIntersection : Occurrence [0..*] {subsets spaceTimeEnclosedPoints} A nested Feature of intersectionsOf.elements identifying all the spaceTimeEnclosedPoints of each element that are not identified by intersection . These must be Without (separate in space or time from) at least one other element . notSubtrahend : Occurrence [0..*] A (nested) Feature of differencesOf.interdiff identifying all Occurrences that are not identified by the subtrahend in each value differencesOf separately. outer : Occurrence [0..1] A spaceSlice of spaceBoundary , see spaceBoundary . outerSpaceDimension : Natural [0..1] For Occurrence of innerSpaceDimension 1 or 2, the number of variables needed to identify their space points in higher dimensional spaces they might be embedded in, from the innerSpaceDimension to 3. For example , an Kernel Modeling Language v1.0 301 -outerSpaceDimension 3 for a curve indicates it twists in three dimensions. An outerSpaceDimension equal to innerSpaceDimension indicates the occurrence is spatially straight ( innerSpaceDimension 1 embedded in 2 or 3 dimensions) or flat ( innerSpaceDimension 2 embedded in 3 dimensions). outgoingTransfer : Transfer [0..*] outgoingTransferFromSelf : Transfer [0..*] {subsets outgoingTransfer} Transfers for which this Occurrence is the sourceParticipant . outsideOfOccurrences : Occurrence [0..*] {subsets withoutOccurrences} Occurrences that are completely separate from this one in space (not necessarily in time, see successors and predecessors ). portionOf : Occurrence [1..*] {subsets within} All Occurrences that this one is Within that are considered the same thing occurring (same portionOfLife ), including this one. portionOfLife : Life The Life of which this Occurrence is a portion . By default, portion is self (that is, the Occurrence is itself a Life ). portions : Occurrence [1..*] {subsets spaceTimeEnclosedOccurrences} All Occurrences Within this one that are considered the same thing occurring (same portionOfLife ), including this one. predecessors : Occurrence [0..*] {subsets withoutOccurrences} Occurrences that are completely separate from this one in time (not necessarily in space, see outsideOfOccurrences ) and that happen before this one (end earlier than this one starts). runToCompletionScope : Occurrence sameLifeOccurrences : Occurrence [1..*] self : Occurrence {subsets timeSlices, spaceSlices, spaceTimeCoincidentOccurrences, sameLifeOccurrences, redefines self} This Occurrence (related to itself via a SelfLink ). snapshotOf : Occurrence [0..*] {subsets timeSliceOf} Occurrences of which this Occurrence is a snapshot . snapshots : Occurrence [1..*] {subsets timeSlices} All timeSlices of this Occurrence that happen at a single instant of time (zero duration). spaceBoundary : Occurrence [0..1] {subsets spaceShots} 302 Kernel Modeling Language v1.0 -A spaceShot of this Occurrence that is not among those of its spaceInterior , which it must be OutsideOf . It must not have a spaceBoundary ( isClosed = true). It can be divided into spaceSlices that also have no spaceBoundary , where the inner ones are SurroundedBy the outer one. spaceEnclosedOccurrences : Occurrence [1..*] Occurrences that this one completely overlaps in space (not necessarily in time, see timeEnclosedOccurrences ), including this one. spaceInterior : Occurrence [0..1] {subsets spaceSlices} A spaceSlice of this Occurrence that includes all its spaceShots except the spaceBoundary , which must exist and be outsideOf it. The spaceInterior must be of the same innerSpaceDimension as this Occurrence , except if it is zero, whereupon there is no spaceInterior . spaceShotOf : Occurrence [1..*] {subsets spaceSliceOf} All Occurrences of which this Occurrence is a spaceShot . spaceShots : Occurrence [1..*] {subsets spaceSlices} All spaceSlices of this Occurrence that are of a lower innerSpaceDimension than it. spaceSliceOf : Occurrence [1..*] {subsets portionOf} An Occurrence this one is a spaceSlices of. spaceSlices : Occurrence [1..*] {subsets portions} All portions of this Occurrence that extend for exactly the same time and some or all the space, relative to spatial location of this Occurrence . This means every Occurrence is a spaceSlice of itself. spaceTimeCoincidentOccurrences : Occurrence [1..*] {subsets timeCoincidentOccurrences, spaceEnclosedOccurrences} Occurrences that this one completely includes in both space and time, and vice-versa, including this one. spaceTimeEnclosedOccurrences : Occurrence [1..*] {subsets spaceEnclosedOccurrences, timeEnclosedOccurrences} All timeEnclosedOccurrences of this Occurrence that are also spaceEnclosedOccurrences , including itself. spaceTimeEnclosedPoints : Occurrence [1..*] {subsets spaceTimeEnclosedOccurrences} All spaceTimeEnclosedOccurrences of this Occurrence that take up no time or space ( innerSpaceDimension 0 and startShot the same as endShot ). startShot : Occurrence {subsets snapshots} The snapshot of this Occurrence that happensBefore all its other snapshots . suboccurrences : Occurrence [0..*] Composite suboccurrences of this Occurrence . The localClock of all suboccurrences defaults to the localClock of its containing Occurrence . Kernel Modeling Language v1.0 303 -subtrahend : Occurrence [0..*] {subsets elements} A (nested) Feature of differencesOf that identifies all the Occurrences in its elements except the first one. successors : Occurrence [0..*] {subsets withoutOccurrences} Occurrences that are completely separate from this one in time (not necessarily in space, see <code>outsideOfOccurrences) and that happen after this one (start later than this one ends). surroundedByOccurrences : Occurrence {subsets outsideOfOccurrences} Occurrences that have inner spaces that completely include this Occurrence . this : Occurrence The "context" Occurrence within which this Occurrence takes place. By default, it is this Occurrence itself. However, this is overridden for ownedPerformances of Objects and subperformances of Performances timeCoincidentOccurrences : Occurrence [1..*] {subsets timeEnclosedOccurrences} Occurrences that HappenWhile this one does ( Occurrences that start and end at the same time as this one). timeEnclosedOccurrences : Occurrence [1..*] Occurrences that this one completely overlaps in time (not necessarily in space, see spaceEnclosedOccurrences ; they start at the same time or later and end at the same time or earlier), including this one. timeSliceOf : Occurrence [1..*] {subsets portionOf} Occurrences of which this one is a timeSlice , including this one. timeSlices : Occurrence [1..*] {subsets portions} portions that extend for some or all the time of this Occurrence , but all its space during that time, including itself. union : Occurrence [0..1] A (nested) Feature of unionsOf identifying an Occurrence with a) spaceTimeEnclosedOccurrences including all those identified by a unionsOf element , and b) all the Occurrence's spaceTimeEnclosedPoints Within (the space and time of) at least one of the elements . unionsOf : Set [0..*] Sets of Occurrences , where the time and space taken by all the Occurrences in each set together ( unionsOf::union ) is the same as taken by this Occurrence (all four dimensional points in the Occurrences of each set are at the same time and space as those of this Occurrence ). withoutOccurrences : Occurrence [0..*] All Occurrences that are successors , successors , and/or OutsideOf of this one. Constraints None. 304 Kernel Modeling Language v1.0 -9.2.4.2.14 occurrences Element Feature Description occurrences is a specialization of things restricted to type Occurrence . It is the most general Feature typed by Occurrence . All other Features typed by Occurrence or its specializations (in libraries or user models) specialize it (directly or indirectly). General Types things Occurrence Features None. Constraints None. 9.2.4.2.15 OutsideOf Element Association Description OutsideOf is a Without Association linking its separateSpaceToo and its separateOccurrence, indicating that these Occurrences do not overlap in space (not necessarily in time, see HappensBefore; no four dimensional points of the Occurrences are in the spatial extent of both of them). This means no Occurrence is OutsideOf itself. General Types SpaceLink Without Features separateSpace : Occurrence {redefines separateOccurrence} The second participant in this OutsideOf Link . Crosses separateSpaceToo.outsideOfOccurrences . separateSpaceToo : Occurrence {redefines separateOccurrenceToo} The first participant in this OutsideOf Link . Crosses separateSpace.outsideOfOccurrences . Kernel Modeling Language v1.0 305 -Constraints None. 9.2.4.2.16 PortionOf Element Association Description PortionOf is a Within Association that links its portionOccurrence to its portionedOccurrence , indicating they are considered the same thing occurring (same portionOfLife ), but with the portionOccurrence potentially taking up less time and space than the portionedOccurrence . This means every Occurrence is a PortionOf itself. The innerSpaceDimension of portionOccurrence is the same or lower than of the portionedOccurrence . General Types Within Features portionedOccurrence : Occurrence {redefines largerOccurrence} The participant in this PortionOf Link that is the largerOccurrence . Crosses portionOccurrence.portionOf . portionOccurrence : Occurrence {redefines smallerOccurrence} The participant in this PortionOf Link that is the smallerOccurrence . Crosses portionedOccurrence.portions . Constraints None. 9.2.4.2.17 SelfSameLifeLink Element Association Description SelfSameLinks are all the BinaryLinks such that the sourceParticipant and targetParticipant are either • Occurrences (which might be lives) that are portions of the same life, or • DataValues that are equal. General Types BinaryLink 306 Kernel Modeling Language v1.0 -Features mySelfSameLife : Anything {redefines source} The source end of a SelfLifeLink. Crosses selfSameLife.myselfSameLives . myselfSameLives : Anything [1..*] Owned cross feature of myselfSameLife . selfSameLife : Anything {redefines target} The target end of a SelfLifeLink. Crosses myselfSameLife.selfSameLives . selfSameLives : Anything [1..*] Owned cross feature of selfSameLife . sourceDataValue : DataValue {subsets mySelfSameLife} Same as the mySelfSameLife when it is an DataValue . sourceOccurrence : Occurrence {subsets mySelfSameLife} Same as the mySelfSameLife when it is an Occurrence . targetDataValue : DataValue {subsets selfSameLife} Same as the selfSameLife when it is an DataValue . targetOccurrence : Occurrence {subsets selfSameLife} Same as the selfSameLife when it is an Occurrence . Also subsets sourceOccurrence.sameLifeOccurrences . Constraints None. 9.2.4.2.18 SnapshotOf Element Association Description SnapshotOf is a TimeSliceOf that links its snapshotOccurrence to its snapshottedOccurrence , indicating that snapshotOccurrence takes no time ( startShot and endShot are the same). General Types TimeSliceOf Features Kernel Modeling Language v1.0 307 -snapshotOcccurrence : Occurrence {redefines timeSliceOccurrence} The participant in this SnapshotOf Link that is the timeSliceOccurrence . Crosses snapshottedOccurrence.snapshots . snapshottedOccurrence : Occurrence {redefines timeSlicedOccurrence} The participant in this SnapshotOf Link that is the timeSlicedOccurrence . Crosses snapshotOccurrence.snapshotOf . Constraints None. 9.2.4.2.19 SpaceLink Element Association Description SpaceLink is the most general association that asserts spatial relationships between a sourceOccurrence and a targetOccurrence . Because SpaceLinks assert spatial relationships, they cannot also be Occurrences that happen in space. Therefore SpaceLink is disjoint with LinkObject , that is, no SpaceLink can also be a LinkObject . General Types BinaryLink Features sourceOccurrence : Occurrence {redefines source} targetOccurrence : Occurrence {redefines target} Constraints None. 9.2.4.2.20 SpaceShotOf Element Association Description SpaceShotOf is a SpaceSliceOf that links its spaceShotOccurrence to its spaceSnapshottedOccurrence , indicating the spaceShotOccurrence is of a lower innerSpaceDimension than the spaceShottedOccurrence General Types SpaceSliceOf 308 Kernel Modeling Language v1.0 -Features spaceShotOccurrence : Occurrence {redefines spaceSliceOccurrence} The participant in this SpaceShotOf Link that is the spaceSliceOccurrence . Crosses spaceShottedOccurrence.spaceShots . spaceShottedOccurrence : Occurrence {redefines spaceSlicedOccurrence} The participant in this SpaceShotOf Link that is the spaceSlicedOccurrence . Crosses spaceShotOccurrence.spaceShotOf . Constraints None. 9.2.4.2.21 SpaceSliceOf Element Association Description SpaceSliceOf is a PortionOf that links its spaceSliceOccurrence to its spaceSlicedOccurrence , indicating the spaceSliceOccurrence extends for exactly the same time and some or all the space of the spaceSlicedOccurrence and that the spaceSliceOccurrence is of the same of lower innerSpaceDimension than the spaceSliceOccurrence . This means every Occurrence is a SpaceSliceOf itself and SpaceSliceOf is transitive. General Types PortionOf Features spaceSlicedOccurrence : Occurrence {redefines portionedOccurrence} The participant in this SpaceSliceOf Link that is the portionedOccurrence . Crosses spaceSliceOccurrence.spaceSliceOf . spaceSliceOccurrence : Occurrence {redefines portionOccurrence} The participant in this SpaceSliceOf Link that is the portionOccurrence . Crosses spaceSlicedOccurrence.spaceSlices . Constraints None. 9.2.4.2.22 SurroundedBy Element Association Kernel Modeling Language v1.0 309 -Description SurroundedBy is an OutsideOf asserting that one occurrence ( surroundedSpace ) is included in space by an innerSpaceOccurrence of another ( surroundingSpace ). General Types OutsideOf Features surroundedSpace : Occurrence {redefines separateSpaceToo} The participant in this SurroundedBy Link that is completely included in the inner space of the other. surroundingSpace : Occurrence {redefines separateSpace} The participant in this SurroundedBy Link that has an inner space that completely includes the other. Constraints None. 9.2.4.2.23 TimeSliceOf Element Association Description TimeSliceOf is a PortionOf that links its timeSliceOccurrence to its timeSlicedOccurrence , indicating that extend for exactly the same time and some or all the space of this Occurrence , including itself. This means every Occurrence is a TimeSliceOf itself. General Types PortionOf Features timeSlicedOccurrence : Occurrence {redefines portionedOccurrence} The participant in this TimeSliceOf Link that is the portionedOccurrence . Crosses timeSliceOccurrence.timeSliceOf . timeSliceOccurrence : Occurrence {redefines portionOccurrence} The participant in this TimeSliceOf Link that is the portionOccurrence . Crosses timeSlicedOccurrence.timeSlices . Constraints None. 9.2.4.2.24 Within 310 Kernel Modeling Language v1.0 -Element Association Description Within classifies all and only links that are HappensDuring and InsideOf . They link their largerOccurrence to their smallerOccurrence , indicating the largerOccurrence completely overlaps the smallerOccurrence in time and space (all four dimensional points of the smallerOccurrence HappensDuring and InsideOf the largerOccurrence ). This means every Occurrence is Within itself and Within is transitive. General Types HappensDuring InsideOf Features largerOccurrence : Occurrence {redefines largerSpace, longerOccurrence} The participant in this Within Link that is the longerOccurrence and largerSpace . Crosses shorterOccurrence.within . smallerOccurrence : Occurrence {redefines shorterOccurrence, smallerSpace} The participant in this Within Link that is the shorterOccurrence and smallerSpace . Crosses largerOccurrence.spaceTimeEnclosedOccurrences . within : Occurrence [1..*] {subsets insideOf, happensDuring} All Occurrences that the smallerOccurrence happensDuring and is insideOf , including the smallerOccurrence . Owned cross feature of _ largerOccurrence . Constraints None. 9.2.4.2.25 WithinBoth Element Association Description WithinBoth is a Within and its inverse. This means the linked Occurrences completely overlap each other in space and time (they occupy the same four dimensional region). This means every Occurrence is Within with itself and Within is transitive. General Types Within HappensWhile Kernel Modeling Language v1.0 311 -Features thatOccurrence : Occurrence {redefines largerOccurrence} Crosses thisOccurrence.spaceTimeCoincidentOccurrences . thisOccurrence : Occurrence {redefines smallerOccurrence} Crosses thatOccurrence.spaceTimeCoincidentOccurrences . Constraints None. 9.2.4.2.26 Without Element Association Description Without classifies all links that are HappensDuring or InsideOf , or both. They link their separateOccurrenceToo to their separateOccurrence , indicating that the Occurrences do not overlap in time and/or space (no four dimensional point is in both Occurrences ). This means no Occurrence is Without itself. General Types BinaryLink Features separateOccurrence : Occurrence {redefines target} The second participant in this Without Link . Crosss separateOccurrenceToo.withoutOccurrences . separateOccurrenceToo : Occurrence {redefines source} The first participant in this Without Link . Crosses separateOccurrence.withoutOccurrences . Constraints None. 9.2.5 Objects 9.2.5.1 Objects Overview Objects are Occurrences that take up a single region of time and space, even though they might be in multiple places over time. Object is the most general Structure, while objects is the most general Feature typed by Structures (see 8.3.4.3 and compare to Performances in 9.2.6.1 ). Objects and Performances do not overlap, but Performances can Involve Objects, which can Perform Performances. LinkObjects are Objects that are also Links, and linkObjects is the most general Feature typed by LinkObject. LinkObjects occupy time and space, like other Objects, with potentially varying relationships to other things over 312 Kernel Modeling Language v1.0 -time, except for which things are its participants (the things being linked), identified by its associationEnd Features (the "ends" of a link are permanent, though participants can be Occurrences with changing relationships to other things). The values of LinkObject Features that are not associationEnds can change over time. LinkObjects can exist between the same Occurrences for only some of the time those Occurrences exist, reflecting changing relationships of those Occurrences. BinaryLinkObjects are BinaryLinks that are also LinkObjects, and binaryLinkObjects is the most general Feature typed by BinaryLinkObject. Body(s), Surfaces, Curves, and Points are Objects with innerSpaceDimension of 3, 2, 1, and 0, respectively. Structured Space Objects StructuredSpaceObjects are Objects with three Features Subsetting spaceSlices : • faces , identifying Surfaces. • edges , identifying Curves. • vertices , identifying Points. The above are collectively structuredSpaceCells , which are also StructuredSpaceObjects, enabling faces to identify edges and vertices among the spaceSlices of their spaceBoundaries , if any, and edges to identify vertices among theirs. Cells of closed StructuredSpaceObjects ( isClosed = true ) must be JustOutside others along their entire spaceBoundary (every cell's spaceSlices must MateWith some spaceSlice of another cell, see Space Boundaries and Interiors in 9.2.4.1 ), which usually means all the edges and vertices of cells MateWith those of other cells, enabling the StructuredSpaceObject to be the spaceBoundary for other Objects. The innerSpaceDimension of a StructuredSpaceObject is the highest innerSpaceDimension of its structuredSpaceCells . Models can specialize the three Features above for various kinds of Objects, for example, one for cylinders would include: • Three Features Subsetting faces for the top, bottom, and middle Surfaces of a cylinder. The edges of these Features are Curves (circles) that are spaceBoundaries of the top and bottom Surfaces (discs), and spaceSlices of the spaceBoundary of the middle Surface (a rectangle joined at two opposite sides). • Two Features Subsetting edges for the top and bottom of the cylinder. Each Feature identifies two Curves that are the edges of adjacent faces, specified by BindingConnectors between the Feature and required edges . These two Curves must mate, specified by a MateWith Connector between the Feature and itself. • A Feature redefining vertices to multiplicity 0. 9.2.5.2 Elements 9.2.5.2.1 BinaryLinkObject Element AssociationStructure Description General Types LinkObject BinaryLink Features toSources : Anything [0..*] {redefines } Kernel Modeling Language v1.0 313 -toTargets : Anything [0..*] {redefines } Constraints None. 9.2.5.2.2 binaryLinkObjects Element Feature Description General Types linkObjects BinaryLinkObject binaryLinks Features None. Constraints None. 9.2.5.2.3 Body Element Structure Description Objects of innerSpaceDimension 3. General Types Object Features innerSpaceDimension : Integer {redefines innerSpaceDimension} Constraints None. 9.2.5.2.4 Curve Element Structure 314 Kernel Modeling Language v1.0 -Description Objects of innerSpaceDimension 1. General Types Object Features innerSpaceDimension : Integer {redefines innerSpaceDimension} Constraints None. 9.2.5.2.5 LinkObject Element AssociationStructure Description LinkObject is the most general AssociationStructure (M1 instance of M2 AssociationStructure ). All other AssociationStructures (in libraries or user models) specialize it (directly or indirectly). General Types Object Link Features None. Constraints None. 9.2.5.2.6 linkObjects Element Feature Description linkObjects is a specialization of links and objects restricted to type LinkObject . It is the most general feature typed by LinkObject . All other Features typed by LinkObject or its specializations (in libraries or user models) specialize it (directly or indirectly). General Types objects Kernel Modeling Language v1.0 315 -LinkObject links Features None. Constraints None. 9.2.5.2.7 Object Element Structure Description An Object is an Occurrence that is not a Performance . It is the most general Structure . All other Structures specialize it directly or indirectly. General Types Occurrence Features enactedPerformances : Performance [0..*] {subsets timeEnclosedOccurrences, involvingPerformances} Performances that are enacted by this Object . involvingPerformances : Performance [0..*] Performances in which this Object is involved. ownedPerformances : Performance [0..*] {subsets timeEnclosedOccurrences, involvingPerformances, suboccurrences} Performances that are owned by this Object . The owning Object is the default this reference for all ownedPerformances . self : Object {redefines self} structuredSpaceBoundary : StructuredSpaceObject [0..1] {subsets spaceBoundary} A spaceBoundary that is a StructuredSpaceObject . subobjects : Object [0..*] {subsets suboccurrences} The suboccurrences of this Object that are also Objects . Constraints None. 316 Kernel Modeling Language v1.0 -9.2.5.2.8 objects Element Feature Description objects is a specialization of occurrences restricted to type Object . It is the most general Feature typed by Object . All other Features typed by Object or its specializations (in libraries or user models) specialize it (directly or indirectly). General Types occurrences Object Features None. Constraints None. 9.2.5.2.9 Point Element Structure Description Objects of innerSpaceDimension 0. General Types Object Features innerSpaceDimension : Integer {redefines innerSpaceDimension} Constraints None. 9.2.5.2.10 StructuredSpaceObject Element Structure Description Kernel Modeling Language v1.0 317 -A StructuredSpaceObject is an Object that is broken up into smaller structuredSpaceCells of the same or lower innerSpaceDimension : faces of innerSpaceDimension 2, edges of innerSpaceDimension 1, and vertices of innerSpaceDimension 0, with the highest of these being the innerSpaceDimension of the StructuredSpaceObject. Boundaries of structuredSpaceObjectCells are the union of others of lower innerSpaceDimension ( edges and vertices on the boundary of faces , and vertices on the boundary of edges ), some of which meet when this StructuredSpaceObject isClosed ( faces meet at their edges and/or vertices , while edges meet at their vertices ), as required to be a spaceBoundary of an Object . General Types Object Features cellOrientation : Integer [0..1] A nested Feature of structuredSpaceObjectCell that gives them a "direction" (1 or -1) or none (0). For example, the cellOrientation of a face indicates to which side the "positive" normal vector points, of an edge the positive direction along the edge , and of a vertex the positive direction "in or out" of it. When the cellOrientation of all edges and vertices are given, and the StructuredSpaceObject isClosed , the cellOrientations of the (completely) overlapping ones sum to zero. edges : Curve [0..*] {subsets structuredSpaceObjectCells, ordered} The structuredSpaceObjectCells of innerSpaceDimension 1 in this StructuredSpaceObject . faces : Surface [0..*] {subsets structuredSpaceObjectCells, ordered} The structuredSpaceObjectCells of innerSpaceDimension 2 in this StructuredSpaceObject . /innerSpaceDimension : Integer {redefines innerSpaceDimension} Highest innerSpaceDimension of the structuredSpaceObjectCells . structuredSpaceObjectCells : StructuredSpaceObject [1..*] {subsets spaceSlices} All and only the spaceSlices of this StructuredSpaceObject that are its faces , edges , and vertices . vertices : Point [0..*] {subsets structuredSpaceObjectCells, ordered} The structuredSpaceObjectCells of innerSpaceDimension 0 in this StructuredSpaceObject . Constraints None. 9.2.5.2.11 Surface Element Structure Description Objects of innerSpaceDimension 2. 318 Kernel Modeling Language v1.0 -General Types Object Features genus : Integer [0..1] The number of "holes" in this Surface , assuming it isClosed . For example, it is 0 for spheres and 1 for toruses, including one-handled coffee cups. innerSpaceDimension : Integer {redefines innerSpaceDimension} Constraints None. 9.2.6 Performances 9.2.6.1 Performances Overview Performances Performances are Occurrences that can be spread out in disconnected portions of space and time. Performance is the most general Behavior, while performances is the most general Feature typed by Behaviors (see 8.3.4.6 and compare to Objects in 9.2.5 ). Performances can coordinate others that HappenDuring them, identified as their subperformances (see Steps in 8.3.4.6 and 8.4.4.7 ). Performances also coordinate and potentially affect other things, some of which might come into existence (start, be "created") or cease to exist (end, be "destroyed") during a Performance, and some that might be used without being affected at all ("catalysts"). Some of these other things might be Objects, identified as a Performance's involvedObjects , some of which might be "responsible" for (enact, Perform) a Performance, identified as its performers . Performances can also accept things as input or provide them as output (as parameters , see 8.3.4.6 ). Evaluations Evaluations are Performances that produce at most one thing (value) identified by their result parameter. Evaluation is the most general Function, while evaluations is the most general Feature identifying them, typed by Functions (see 8.3.4.7 ). In other respects Evaluations are like any other Performance. LiteralEvaluations are Evaluations with exactly one result , specified as a constant in a model via classification by LiteralExpression (see 8.3.4.8 for this and the rest of the paragraph). LiteralEvaluation is the most general LiteralExpression, specialized in the same way, and literalEvaluations is the most general feature identifying them, also similarly specialized. BooleanEvaluations are Evaluations (but not LiteralEvaluations) with exactly one true or false result . BooleanEvaluation is the most general Predicate, and booleanEvaluations is the most general feature identifying them, specialized (incompletely) into those that always have true or always false results , trueEvaluations and falseEvaluations , respectively. LiteralBooleanEvaluations are LiteralEvaluations and BooleanEvaluations, with result specified in a model, potentially identified by trueEvaluations or falseEvaluations , or one of their specializations. NullEvaluations are Evaluations that produce no values for their result . NullEvaluation is the most general NullExpression, and nullEvalutions is the most general Feature typed by NullExpression (see 8.3.4.8 ). Kernel Modeling Language v1.0 319 -9.2.6.2 Elements 9.2.6.2.1 BooleanEvaluation Element Predicate Description BooleanEvaluation is a specialization of Evaluation that is the most general Predicate that may be evaluated to produce a Boolean truth value. General Types Evaluation Features result : Boolean {redefines result} The Boolean result of this BooleanExpression . Constraints None. 9.2.6.2.2 booleanEvaluations Element BooleanExpression Description booleanEvaluations is a specialization of evaluations restricted to type BooleanEvaluation . General Types evaluations BooleanEvaluation Features None. Constraints None. 9.2.6.2.3 constructorEvaluations Element Expression 320 Kernel Modeling Language v1.0 -Description constructorEvaluations is a specialization of evaluations that restricts the multiplicity of its result parameter to 1..1 , requiring a constructorEvaluation to result in a single value. General Types evaluations Features result : Anything {redefines result} Constraints None. 9.2.6.2.4 Evaluation Element Function Description An Evaluation is a Performance that ends with the production of a result . General Types Performance Features result : Anything [0..*] {nonunique} The outcome of the Evaluation . Constraints None. 9.2.6.2.5 evaluations Element Expression Description evaluations is a specialization of performances for Evaluations of functions. General Types Evaluation performances Kernel Modeling Language v1.0 321 -Features None. Constraints None. 9.2.6.2.6 falseEvaluations Element BooleanExpression Description falseEvaluations is a subset of booleanEvaluations that result in false. It is the most general Feature of Invariants that are negated. General Types booleanEvaluations Features [no name] : LiteralEvaluation Constraints None. 9.2.6.2.7 InvolvedIn Element Association Description InvolvedIn asserts that the involvedObject is involved in the involvingPerformance . General Types BinaryLink Features involvedObject : Object {redefines source} Crosses involvingPerformance.involvedObjects . involvingPerformance : Performance {redefines target} Crosses involvedObject.involvingPerformances . Constraints 322 Kernel Modeling Language v1.0 -None. 9.2.6.2.8 LiteralEvaluation Element Function Description LiteralEvaluation is a specialization of Evaluation for the case of LiteralExpressions . General Types Evaluation Features result : DataValue {redefines result} The result of this LiteralEvaluation , which is always a single DataValue . Constraints None. 9.2.6.2.9 literalEvaluations Element Expression Description literalEvaluations is a specialization of evaluations restricted to type LiteralEvaluation . General Types evaluations LiteralEvaluation Features None. Constraints None. 9.2.6.2.10 MetadataAccessEvaluation Element Function Kernel Modeling Language v1.0 323 -Description MetadataAccessEvaluation is a specialization of Evaluation for the case of MetadataAccessExpressions. General Types Evaluation Features result : Metaobject [0..*] {redefines result} The result of this MetadataEvaluation . Constraints None. 9.2.6.2.11 metadataAccessEvaluations Element Expression Description metadataAccessEvaluations is a specialization of evaluations restricted to type MetadataAccessEvaluation . General Types evaluations MetadataAccessEvaluation Features None. Constraints None. 9.2.6.2.12 NullEvaluation Element Function Description NullEvaluation is a specialization of Evaluation for the case of NullExpressions . General Types 324 Kernel Modeling Language v1.0 -Evaluation Features result : Anything [0] {redefines result} The result of this NullEvaluation , which always must be empty (i.e., "null"). Constraints None. 9.2.6.2.13 nullEvaluations Element Expression Description nullEvaluations is a specialization of evaluations restricted to type NullEvaluation . General Types NullEvaluation evaluations Features None. Constraints None. 9.2.6.2.14 Performance Element Behavior Description A Performance is an Occurrence that is not a Object . It is the most general Behavior . All other Behaviors specialize it directly or indirectly. General Types Occurrence Features enclosedPerformances : Performance [0..*] {subsets timeEnclosedOccurrences} <code>timeEnclosedOccurrences of this Performance that are also Performances . Kernel Modeling Language v1.0 325 -involvedObjects : Object [0..*] Objects that are involved in this Performance . performers : Object [0..*] {subsets involvedObjects} Objects that enact this Performance . self : Performance {redefines self} subperformances : Performance [0..*] {subsets enclosedPerformances, suboccurrences} enclosedPerformances that are composite. The default this context of a subperformance is by default the same as that of its owning Performance . This means that the context for any Performance that is in a composition tree rooted in a Performance that is not itself owned by an Object is the root Performance . If the root Performance is an ownedPerformance of an Object , then that Object is the context. thisPeformance : Performance The "context" Performance during which this Performance takes place. It defaults to the root of the subperformances composition tree. It is the default dispatchScope for Performances . Constraints None. 9.2.6.2.15 performances Element Step Description performances is the most general feature for Performances of Behaviors . General Types things Performance Features None. Constraints None. 9.2.6.2.16 Performs Element Association 326 Kernel Modeling Language v1.0 -Description Performs is a specialization of InvolvedIn that asserts that the performer enacts the enactedPerformance . General Types InvolvedIn Features performance : Performance {redefines involvingPerformance} Crosses performerObject.enactedPerformances . performerObject : Object {redefines involvedObject} Crosses performance.performers . Constraints None. 9.2.6.2.17 trueEvaluations Element BooleanExpression Description falseEvaluations is a subset of booleanEvaluations that result in false. It is the most general Feature of Invariants that are not negated. General Types booleanEvaluations Features None. Constraints None. 9.2.7 Transfers 9.2.7.1 Transfers Overview Transfers are Performances and BinaryLinks that carry payloads from their source Occurrence to their target Occurrence . FlowTransfers are Transfers that start by "picking up" their payload from the sourceOutput Feature (or one of its redefinitions) of the source and end with "dropping it off" at the targetInput Feature of the target (or one of its redefinitions, see 8.3.3.1.5 about outputs and inputs). FlowTransfers do this by specifying the existence of BinaryLinkObjects between their source / target and values of sourceOutput / targetInput Features of those, identified by the Connectors sourceOutputLink and targetOutputLink , respectively (these can be redefined to specialized associations when FlowTransfer is Kernel Modeling Language v1.0 327 -used). Each sourceOutputLink identifies an output as its transferPayload (one of the values of sourceOutput on the source at the time a FlowTransfer starts) . Each targetInputLink identifies an input also as its transferPayload (one of the values of targetInput on the target at the time a Transfer ends). Both collections of transferPayloads are the same as the FlowTransfer 's payloads , and do not change while it is carried out. Transfers are required to take zero time when their isInstant Feature is true ( startShot and endShot are the same, see Portions and Time Slices in 9.2.4.1 ), otherwise they might take time to carry out. Two Boolean Features of FlowTransfers affect timing of their sourceOutputLinks and targetOutputLinks : • isMove true requires sourceOutputLinks to end (cease to exist) when the Transfer starts, otherwise the Transfer has no effect on the sourceOutputLinks . • isPush true requires the Transfer to start when its sourceOutputLinks do (begin to exist), otherwise the Transfer can start anytime after the sourceOutputLinks do. MessageTransfers are Transfers that do not have the additional capabilities of FlowTransfers . SendPerformances and AcceptPerformances are Performances for specifying when MessageTransfers come into and go out of Occurrences , respectively. SendPerformances require a MessageTransfer as outgoingTransferFromSelf from a designated sender (defaulting to this , see Clause ), carrying a payload , optionally to a designated receiver . AcceptPerformances require an incomingTransferToSelf to a designated receiver (defaulting to this ), carrying a payload . Transfer and its specializations are binary Interactions , while transfers is the most general Feature typed by Transfer or its specializations, and the most general Flow (see 8.3.4.9 ). Transfer is not the most general binary Interaction , and transfers is not the most general feature typed by binary Interactions , because binary Interactions can include more than one Flow , as well as other Interactions . Flow 's payloadType gives the kind of things being transferred (most generally the type of payload , above). For FlowTransfers , Flow 's sourceOutputFeature and targetInputFeature specify which Features of its connected Feature Occurrences identify outputs and inputs, respectively (most generally sourceOutput and targetInput above, respectively). 9.2.7.2 Elements 9.2.7.2.1 AcceptPerformance Element Behavior Description AcceptPerformances are Performances that require an incomingTransferToSelf of a designated receiver Occurrence (defaulting to this ), providing a payload as output. General Types Performance Features acceptedTransfer : MessageTransfer [0..1] {subsets receiver.incomingTransfersToSelf} payload : Anything [0..*] 328 Kernel Modeling Language v1.0 -receiver : Occurrence receiver.incomingTransfersToSelf : Transfer [0..*] Constraints None. 9.2.7.2.2 FlowTransfer Element Interaction Description A FlowTransfer is a Transfer identifying an output feature of the source from which to pick up a payload and an input feature of the target to which to drop it off. They can start when the payload is available at the source and move or copy it to the target . General Types Transfer Features isMove : Boolean If isMove is true, then the entire payload leaves the source at the start of the Transfer . isPush : Boolean If isPush is true, then the Transfer begins when the payload is available at the source . sourceOutputLink : BinaryLinkObject [1..*] The output of the payload from source.sourceOutput . targetInputLink : BinaryLinkObject [1..*] The input of the payload to target.targetInput . Constraints None. 9.2.7.2.3 FlowTransferBefore Element Interaction Description General Types Kernel Modeling Language v1.0 329 -FlowTransfer TransferBefore Features source : Occurrence {redefines source, source} target : Occurrence {redefines target, target} Constraints None. 9.2.7.2.4 flowTransfers Element Flow Description General Types FlowTransfer transfers Features source : Occurrence {redefines source, source} target : Occurrence {redefines target, target} Constraints None. 9.2.7.2.5 flowTransfersBefore Element Flow Description General Types FlowTransferBefore flowTransfers transfersBefore Features source : Occurrence {redefines source, source, source} 330 Kernel Modeling Language v1.0 -target : Occurrence {redefines target, target, target} Constraints None. 9.2.7.2.6 MessageTransfer Element Interaction Description A MessageTransfer is a Transfer that does not specify where the payload is picked up and dropped off (see FlowTransfer ). They are sent by SendPerformances and accepted by AcceptPerformances . General Types Transfer Features None. Constraints None. 9.2.7.2.7 messageTransfers Element Flow Description General Types transfers MessageTransfer Features source : Occurrence {redefines source, source} target : Occurrence {redefines target, target} Constraints None. 9.2.7.2.8 SendPerformance Element Kernel Modeling Language v1.0 331 -Behavior Description SendPerformances are Performances that require an outgoingTransferFromSelf from a designated sender Occurrence (defaulting to this ), carrying a given payload , optionally to a designated receiver . General Types Performance Features payload : Anything [0..*] receiver : Occurrence [0..1] receiver.incomingTransfersToSelf : Transfer [0..*] sender : Occurrence sender.outgoingTransfersToSelf : Transfer [0..*] sentTransfer : MessageTransfer {subsets sender.outgoingTransfersToSelf} Constraints None. 9.2.7.2.9 Transfer Element Interaction Description A Transfer is a Performance and BinaryLink that carries a Payload from its source to its target . General Types Performance BinaryLink Features isInstant : Boolean If isInstance is true, then the Transfer is instantaneous. payload : Anything [1..*] The things that are to be transferred. source : Occurrence {redefines source} 332 Kernel Modeling Language v1.0 -The entity whose output is the source of the payload to be transferred. target : Occurrence {redefines target} The entity whose input is the target of the payload to be transferred. Constraints None. 9.2.7.2.10 TransferBefore Element Interaction Description A TransferBefore is Transfer that happens after its source and before its target . General Types HappensBefore Transfer Features self : TransferBefore {redefines self} source : Occurrence {redefines earlierOccurrence, source} target : Occurrence {redefines laterOccurrence, target} Constraints None. 9.2.7.2.11 transfers Element Flow Description General Types Transfer performances binaryLinks Features Kernel Modeling Language v1.0 333 -source : Occurrence {redefines source, source} target : Occurrence {redefines target, target} Constraints None. 9.2.7.2.12 transfersBefore Element Flow Description General Types transfers happensBeforeLinks TransferBefore Features source : Occurrence {redefines source, source, earlierOccurrence} target : Occurrence {redefines target, target, laterOccurrence} Constraints None. 9.2.8 Feature Referencing Performances 9.2.8.1 Feature Referencing Performances Overview The FeatureReferencingPerformances package defines Behaviors used to read and write values of a referenced Feature of an Occurrence as of the time the Performance of the Behavior ends. 9.2.8.2 Elements 9.2.8.2.1 BooleanEvaluationResultMonitorPerformance Element Description A BooleanEvaluationResultMonitorPerformance is a EvaluationResultMonitorPerformance that waits for changes in the result of a BooleanEvaluation identified by onOccurrence . General Types EvaluationResultMonitorPerformance Features 334 Kernel Modeling Language v1.0 -afterValues : Boolean {redefines afterValues} beforeValues : Boolean {redefines beforeValues} monitoredOccurrence : BooleanEvaluation {subsets timeSlices, redefines monitoredOccurrence} A timeSlice of onOccurrence during which its values for result change. onOccurrence : BooleanEvaluation {redefines onOccurrence} The BooleanEvaluation being monitored for changes in its result values. result : Boolean {redefines result, nonunique} Redefines BooleanEvaluation::result and monitoredFeature . Constraints None. 9.2.8.2.2 BooleanEvaluationResultToMonitorPerformance Element Description A BooleanEvaluationResultToMonitorPerformance is a FeatureReferencingPerformance that waits for the result of a BooleanEvaluation (identified by onOccurrence ) to change to either true or false, as indicated by isToTrue (defaulting to true). If the result is already true (or false), the performance waits for the result to become false (or true) before waiting again for it to change back. General Types FeatureReferencingPerformance Features afterValues : Boolean {redefines values, nonunique} The values of monitoredFeature for onOccurrence immediately after they change. Always the same as isToTrue . endWhen : HappensJustBefore See FeatureMonitorPerformance::endWhen . It is restricted to HappensJustBefore in monitor1 and monitor2 . isToTrue : Boolean monitor1 : BooleanEvaluationResultMonitorPerformance Waits for the result of onOccurrence to change. monitor2 : BooleanEvaluationResultMonitorPerformance [0..1] Kernel Modeling Language v1.0 335 -Waits for the result of onOccurrence to change again, only if the change detected by monitor1 was not the same as isToTrue . onOccurrence : BooleanEvaluation {redefines onOccurrence} The BooleanEvaluation being monitored for changes in its result values. Constraints bertmpMonitor1ElseMonitor2 isEmpty(monitor2) == (monitor1.afterValues == isToTrue) 9.2.8.2.3 EvaluationResultMonitorPerformance Element Behavior Description An EvaluationResultMonitorPerformance is a FeatureMonitorPerformance that waits for changes in result of an Evaluation identified by onOccurrence . The Predicate being evaluated must be able to produce multiple results over time, for example by only using BindingConnectors ( SelfLinks ) between Steps , rather than Successions or Flows , including in its Step behaviors . General Types FeatureMonitorPerformance Features monitoredOccurrence : Evaluation {subsets timeSlices, redefines monitoredOccurrence} A timeSlice of onOccurrence during which its values for result change. onOccurrence : Evaluation {redefines onOccurrence} The Evaluation being monitored for changes in its result values. result : Anything [0..*] {redefines monitoredFeature, nonunique} Redefines Evaluation::result and monitoredFeature Constraints None. 9.2.8.2.4 FeatureAccessPerformance Element Behavior Description 336 Kernel Modeling Language v1.0 -A FeatureAccessPerformance is a FeatureReferencingPerformance where values are all the values of accessedFeature for onOccurrence at the time the Performance ends . Specializations or usages of this narrow accessedFeature to particular Features . General Types FeatureReferencingPerformance Features accessedFeature : Anything [0..*] {nonunique} The Feature of onOccurrence that has values at the time this FeatureAccessPerformance ends. startingAt : Occurrence {subsets timeSlices} A timeslice of onOccurrence that starts when this FeatureAccessPerformance ends. Constraints None. 9.2.8.2.5 FeatureMonitorPerformance Element Behavior Description A FeatureMonitorPerformance is a FeatureReferencingPerformance that waits for values of monitoredFeature to change on onOccurrence from what they were when the Performance started. The values before and after the change are given by beforeValues and afterValues . General Types FeatureReferencingPerformance Features afterSnapshot : Occurrence {subsets snapshots} A snapshot of monitoredOccurrence just after its values for monitoredFeature change. afterValues : Anything [0..*] {redefines values} The values of monitoredFeature for monitoredOccurrence immediately after they change beforeTimeSlice : Occurrence {subsets timeSlices} A timeSlice of monitoredOccurrence , starting at the same time, and ending just before its values for monitoredFeature change. beforeValues : Anything [0..*] The values of monitoredFeature for monitoredOccurrence before any change Kernel Modeling Language v1.0 337 -endWhen : HappensBefore A Succession ( Connector typed by HappensBefore ) from afterSnapshot to the endShot of this FeatureMonitorPerformance . Can be specialized to specify how soon the Performance should end after the change in monitoredFeature . monitoredFeature : Anything [0..*] {nonunique} The Feature being monitored for changes in values on monitoredOccurrence . monitoredOccurrence : Occurrence {subsets timeSlices} A timeSlice of onOccurrence , starting when this FeatureMonitorPerformance starts, during which the values of monitoredFeature change. Constraints fmpBeforeAfterValuesNotSame not beforeValues == afterValues 9.2.8.2.6 FeatureReadEvaluation Element Function Description A FeatureReadEvaluation is a FeatureAccessPerformance that is a Function providing as its result the values of accessedFeature of onOccurrence at the time the Evaluation ends. General Types Evaluation FeatureAccessPerformance Features result : Anything [0..*] {redefines result, values, nonunique} Values of the Feature being accessed, as an out parameter. Constraints None. 9.2.8.2.7 FeatureReferencingPerformance Element Behavior Description 338 Kernel Modeling Language v1.0 -A FeatureReferencingPerformance is a Performance generalizing other Behaviors relating to values of a Feature of onOccurrence , as specified in the specialized Behaviors . General Types Performance Features onOccurrence : Occurrence An Occurrence that has values for a Feature determined in specializations of this Behavior . values : Anything [0..*] {nonunique} Values of a Feature of onOccurrence , determined in specializations of this Behavior . Constraints None. 9.2.8.2.8 FeatureWritePerformance Element Behavior Description A FeatureWritePerformance is a FeatureAccessPerformance that ensures the values of accessedFeature of onOccurrence are exactly the replacementValues at the time the Performance ends . General Types FeatureAccessPerformance Features replacementValues : Anything [0..*] {redefines values, nonunique} Values of the Feature being accessed, as an inout parameter to replace all the values. Constraints None. 9.2.9 Control Performances 9.2.9.1 Control Performances Overview The ControlPerformances package defines Behaviors used to type Steps that control the sequencing of performance of other Steps , including the following. DecisionPerformances are Performances used by ("decision") Steps to ensure that each DecisionPerformance (value) of the Step is the earlierOccurrence of exactly one HappensBefore link of Kernel Modeling Language v1.0 339 -the Successions going out of the Step . Successions going out of Steps typed by DecisionPerformance or its specializations must: • have connector end multiplicities of 1 towards the Step, and 0..1 away from it. • be included in a Feature of its featuringBehavior that unions (see 7.3.2.7 ) all the outgoing Successions , and is bound to the outgoingHBLink of the Step (see 7.3.4.6 on feature chaining). MergePerformances are Performances used by ("merge") Steps to ensure that each MergePerformance (value) of the Step is the laterOccurrence of exactly one HappensBefore link of the Successions coming into the step. Successions coming into Steps typed by MergePerformance or its specializations must: • have connector end multiplicities of 1 towards the Step , and 0..1 away from it. • subset a Feature of its featuringBehavior that unions all the incoming Successions , and is bound to the incomingHBLink of the Step . IfPerformances are Performances that determine whether a clause occurs based on the result of a BooleanEvaluation (see 9.2.6.1 ). Two specializations IfThenPerformance and IfElsePerformance have one clause each, thenClause and elseClause , respectively, that occur when the BooleanEvaluation is true or false , respectively. IfThenElsePerformance is an IfPerformance that has both a thenClause and an elseClause . LoopPerformances are Performances with a body that occurs iteratively as determined by BooleanEvaluations whileTest and untilTest . The body occurs repeatedly in sequence (iteratively) as long as the result of whileTest is true before each iteration (and after the previous one, if any), and the result of untilTest is false after each iteration and before the next one (except after the last one, when it is false ). 9.2.9.2 Elements 9.2.9.2.1 DecisionPerformance Element Behavior Description A DecisionPerformance is a Performance that represents the selection of one of the Successions that have the DecisionPerformance behavior as their source. All such Successions must subset the outgoingHBLink feature of the source DecisionPerformance . For each instance of DecisionPerformance , the outgoingHBLink is an instance of exactly one of the Successions , ordering the DecisionPerformance as happening before an instance of the target of that Succession . General Types Performance Features outgoingHBLink : HappensBefore Specializations subset this from the union of all Successions going out of a decision step. Constraints None. 340 Kernel Modeling Language v1.0 -9.2.9.2.2 IfElsePerformance Element Behavior Description An IfElsePerformance is an IfPerformance where elseClause occurs after and only after the ifTest Evaluation result is not true. General Types IfPerformance Features elseClause : Occurrence [0..1] Constraints None. 9.2.9.2.3 IfPerformance Element Behavior Description An IfPerformance is a Performance that determines whether the ifTest Evaluation result is true (by whether the ifTrue connector has a value). General Types Performance Features ifTest : BooleanEvaluation trueLiteral : LiteralEvaluation Constraints None. 9.2.9.2.4 IfThenElsePerformance Element Behavior Description Kernel Modeling Language v1.0 341 -An IfThenElsePerformance is an IfPerformance that has both a thenClause and an elseClause . General Types IfThenPerformance Features elseClause : Occurrence [0..1] Constraints None. 9.2.9.2.5 IfThenPerformance Element Behavior Description An IfThenPerformance is an IfPerformance where thenClause occurs after and only after the ifTest Evaluation result is true. General Types IfPerformance Features thenClause : Occurrence [0..1] Constraints None. 9.2.9.2.6 LoopPerformance Element Behavior Description A LoopPerformance is a Performance where body occurs repeatedly in sequence (iterates) as long as the while evaluation result is true before each iteration (and after the previous one, except the first time) and the until evaluation result is not true after each iteration and before the next one (except the last one). General Types Performance Features body : Occurrence [0..*] 342 Kernel Modeling Language v1.0 -untilDecision : IfElsePerformance [0..*] untilTest : BooleanEvaluation [0..*] whileDecision : IfThenPerformance [1..*] whileTest : BooleanEvaluation [1..*] Constraints None. 9.2.9.2.7 MergePerformance Element Behavior Description A MergePerformance is a Performance that represents the merging of all Successions that target the MergePerformance behavior. All such Successions must subset the incomingHBLink feature of the target MergePerformance . For each instance of MergePerformance , the incomingHBLink is an instance of exactly one of the Successions , ordering the MergePerformance as happening after an instance of the source of that Succession . General Types Performance Features incomingHBLink : HappensBefore Specializations subset this from the union of all successions coming into a merge step. Constraints None. 9.2.10 Transition Performances 9.2.10.1 Transition Performances Overview The TransitionPerformances package contains a library model of the semantics of conditional transitions between Occurrences , including the performance of specified Behaviors when the transition occurs. TransitionPerformances are Performances used to • determine whether a Succession (see 7.4.6.4 ) going out of an Occurrence Feature ( Succession::sourceFeature ) has values ( HappensBefore links), based on values of sourceFeature ( Occurrences ) and other conditions, including ending of Transfers . • perform specified Behaviors for each value of the Succession above. Kernel Modeling Language v1.0 343 -Values of the Succession above are determined by values of a Step typed by TransitionPerformance or a specialization of it, owned by the same Behavior as the Succession . A BindingConnector links the Succession and the transition step's transitionLink , ensuring • Each transition step determines the values of exactly one Succession that is not constrained by any other transition step. • All conditions of exactly one TransitionPerformance must be satisfied for each HappensBefore link, while all conditions of the other TransitionPerformances (values) fail, leaving no values for their transitionLink . The transitionLinkSource of the transition step is connected to the sourceFeature of the Succession by a BindingConnector , because conditions on the Succession depend on each Occurrence of its sourceFeature separately, which TransitionPerformances identify as their transitionLinkSource . This ensures every Occurrence of the sourceFeature of the Succession is paired with a unique TransitionPerformance , and vice-versa, that determines whether the Succession has a value ( HappensBefore link) for that Occurrence . TransitionPerformances with a transitionLink must satisfy these conditions: • identify at least one Transfer trigger that targets triggerTarget . • all Transfers identified by trigger must happen before all Evaluations identified by guard . • all Evaluations identified by guard must have result value true . The effect of a TransitionPerformance can have values ( Performances ) only if the above conditions hold. The effect Performances must happen after the guards and before the laterOccurrence of transitionLink . Usages of ( Steps typed by) TransitionPerformance or its specializations can redefine or subset guard and effect to specify how they are carried out, as well as specify how triggers are identified. These usages can • be steps of any Behavior (not only "state machines"), as well as constrain Successions going out of any kind of Step (not only those identifying StatePerformances , see ). • employ any method of identifying triggers , including requiring none at all, as well as constraining Transfer targets to be, for example, the StatePerformance itself, or a Performance it is a subperformance of, or an Object enacting that Performance . TransitionPerformances are either StateTransitionPerformances or NonStateTransitionPerformances , depending on whether the transitionLinkSource is a StatePerformance or not. Both ensure guards happen before the laterOccurrence of transitionLink , in case there are no effects , but do this in different ways. NonStateTransitionPerformances require their guards to happen after transitionLinkSource (see 9.2.11.1 about StateTransitionPerformances ). 9.2.10.2 Elements 9.2.10.2.1 NonStateTransitionPerformance Element Behavior Description General Types TransitionPerformance Features 344 Kernel Modeling Language v1.0 -isTriggerAfter : Boolean Constraints None. 9.2.10.2.2 TPCGuardConstraint Element AssociationStructure Description General Types BinaryLinkObject Features constrainedGuard : Evaluation {redefines target} constrainedHBLink : HappensBefore {redefines source} Crosses constrainedGuard.guardedLink . guardedLink : HappensBefore [0..1] {redefines } Owned cross feature for constrainedHBLink . Constraints None. 9.2.10.2.3 TransitionPerformance Element Behavior Description General Types Performance Features accept : AcceptPerformance [0..1] {subsets enclosedPerformances} effect : Performance [0..*] {subsets enclosedPerformances} guard : Evaluation [0..*] {subsets enclosedPerformances} guardConstraint : TPCGuardConstraint [0..*] transitionLink : HappensBefore [0..1] Kernel Modeling Language v1.0 345 -transitionLinkSource : Performance trigger : MessageTransfer [0..*] triggerTarget : Occurrence Constraints None. 9.2.11 State Performances 9.2.11.1 State Performances Overview The StatePerformances package contains a library model for the semantics of state-based behavior, including StatePerformances and StateTransitionPerformances . StatePerformances are DecisionPerformances (see 9.2.9.1 ) that • only have Steps defined in this library, or specialized from them. • can identify Transfers that might be followed by taking the last of the above Steps (see exit below). Usages of StatePerformance can specialize its library-defined Steps to specify how they are carried out, as well as how the Transfers above are identified. Any Behavior can use (have steps typed by) StatePerformances , not only "state machines". The StatePerformance Steps defined in this library are: • entry [1]: happens before all Performances of middle . • middle [1..*]: happen before the exit Performance (see below). Additional modeler-defined Steps must subset this one. • do [1]: a middle Performance that starts before the others. • exit [1]: happens after the end of Transfers identified by the StatePerformance (see acceptable below). StatePerformances identify Transfers that happen before (potentially "trigger") their exit with these Features : • acceptable [*]: candidates for being identified as accepted . • accepted [0..1]: one of the acceptable transfers that enables exit to start. This must have a value if acceptable does. The accepted Transfer must end (arrive) during a StatePerformance when its isTriggerDuring is true . StateTransitionPerformances are one way to determine which Transfers are acceptable to a StatePerformance . They are TransitionPerformances (see 9.2.10.1 ) that • have a StatePerformance as their transitionLinkSource . • are the type of Steps connected to Successions (see 7.4.6.4 ) going out of a StatePerformance Step (as in "state machines"). StateTransitionPerformances identify MessageTransfers (see 9.2.7.1 ) by these Features : • acceptable [*]: candidates for being identified as trigger . This subsets acceptable of their transitionLinkSource . 346 Kernel Modeling Language v1.0 -• trigger [0..1]: one of the acceptable transfers. This subsets accepted of their transitionLinkSource . The trigger Transfer must end (arrive) during the transitionLinkSource when StateTransitionPerformance::isTriggerDuring is true . The Subsettings above enable a StatePerformance Step to constrain all the StateTransitionPerformances Steps connected to its outgoing Successions , including to decide which of the MessageTransfers acceptable to those StateTransitionPerformances will be accepted by the StatePerformance and trigger which outgoing Succession (will have a HappenBeforeLink value). StateTransitionPerformances require their guards to happen after the nonDoMiddle Step of the transitionLinkSource (all the middle Performances except for do ) and before the exit Step (compare to NonStateTransitionPerformances in 9.2.10.1 ). StatePerformances identify the Transfer that triggered a transition into it (a StateTransitionPerformance trigger ), if any, by the Feature incomingTransitionTrigger . Some Features of Occurrences constrain StatePerformances and TransitionPerformances composed under them, as sometimes needed in state machines: • incomingTransferSort determines which Transfer should be accepted when multiple are acceptable ones, by comparing two Transfer at a time. It defaults to earlierFirstIncomingTransferSort for Occurrences , including StatePerformances , which is true if the first Transfer ends (arrives) before the other. • isDispatch being true prevents the same Transfer from being accepted more than once by StatePerformances composed under dispatchScope , and prevents from being accepted at all any acceptable Transfers that are not accepted and are higher in incomingTransferSort order than the one that is. It defaults to true for Performances , including StatePerformances , and false for other Occurrences , while dispatchScope defaults to thisPerformance for StatePerformances , the top Performance (indirectly) composing the StatePerformance (see 9.2.6.2.14 ), and self for other Occurrences (see 9.2.2.1 ). • isRunToCompletion being true prevents TransitionPerformances composed under runToCompletionScope from happening during entry . It defaults to the same as it is on this for StatePerformances , the Object directly composing thisPerformance , or thisPerformance if there is none (see 9.2.4.2.13 ), and true for other Occurrences , while runToCompletionScope defaults to the same as it is on this for StatePerformances , and self for other Occurrences . 9.2.11.2 Elements 9.2.11.2.1 StatePerformance Element Behavior Description General Types DecisionPerformance Features acceptable : MessageTransfer [0..*] {union} Kernel Modeling Language v1.0 347 -accepted : MessageTransfer [0..1] {subsets acceptable} deferrable : MessageTransfer [0..*] {subsets acceptable} do : Performance {subsets middle} entry : Performance {subsets timeEnclosedOccurrences} exit : Performance {subsets timeEnclosedOccurrences} incomingTransitionTrigger : MessageTransfer [0..1] Transfer that triggered a transition into this state performance. isTriggerDuring : Boolean /middle : Performance [1..*] {subsets timeEnclosedOccurrences, union} /nonDoMiddle : Performance [0..*] {subsets middle} Constraints None. 9.2.11.2.2 StateTransitionPerformance Element Behavior Description General Types TransitionPerformance Features acceptable : MessageTransfer [0..*] {subsets triggerTarget.incomingTransfersToSelf, transitionLinkSource.acceptable} isTriggerDuring : Boolean transitionLinkSource : StatePerformance {redefines transitionLinkSource} transitionLinkSource.acceptable : MessageTransfer [0..*] transitionLinkSource.accepted : MessageTransfer [0..1] transitionLinkTarget : Occurrence [0..1] trigger : MessageTransfer [0..1] {subsets acceptable, transitionLinkSource.accepted, redefines trigger} triggerTarget.incomingTransfersToSelf : Transfer [0..*] Constraints 348 Kernel Modeling Language v1.0 -None. 9.2.12 Clocks 9.2.12.1 Clocks Overview This package models Clocks that provide an advancing numerical reference usable for quantifying the time of an Occurrence . 9.2.12.2 Elements 9.2.12.2.1 BasicClock Element Structure Description A BasicClock is a Clock whose currentTime is a Real number. General Types Clock Features currentTime : Real {redefines currentTime} Constraints None. 9.2.12.2.2 BasicDurationOf Element Function Description BasicDurationOf returns the DurationOf an Occurrence as a Real number relative to a BasicClock . General Types DurationOf Features clock : BasicClock {redefines clock} Default is inherited Occurrence::localClock . duration : Real {redefines duration} o : Occurrence {redefines o} Kernel Modeling Language v1.0 349 -Constraints None. 9.2.12.2.3 BasicTimeOf Element Function Description BasicTimeOf returns the TimeOf an Occurrence as a Real number relative to a BasicClock . General Types TimeOf Features clock : BasicClock {redefines clock} Default is inherited Occurrence::localClock . o : Occurrence {redefines o} timeValue : Real {redefines timeInstant} Constraints None. 9.2.12.2.4 Clock Element Structure Description A Clock provides a scalar currentTime that advances montonically over its lifetime. Clock is an abstract base Structure that can be specialized for different kinds of time quantification (e.g., discrete time, continuous time, time with units, etc.). General Types Object Features currentTime : NumericalValue A numerical time reference that advances over the lifetime of the Clock . Constraints 350 Kernel Modeling Language v1.0 -timeFlowConstraint The currentTime of a snapshot of a Clock is equal to the TimeOf the snapshot relative to that Clock . 9.2.12.2.5 DurationOf Element Function Description DurationOf returns the duration of a given Occurrence relative to a given Clock , which is equal to the TimeOf the end snapshot of the Occurrence minus the TimeOf its start snapshot. General Types Evaluation Features clock : Clock Default is inherited Occurrence::localClock . duration : NumericalValue o : Occurrence Constraints None. 9.2.12.2.6 TimeOf Element Function Description TimeOf returns a scalar timeValue for a given Occurrence relative to a given Clock . The timeValue is the time of the start of the Occurrence , which is considered to be synchronized with the snapshot of the Clock with a currentTimetimeValue General Types Evaluation Features clock : Clock Default is inherited Occurrence::localClock . o : Occurrence Kernel Modeling Language v1.0 351 -timeInstant : NumericalValue Constraints startTimeConstraint The TimeOf an Occurrence timeContinuityConstraint If one Occurrence happens immediately before another, then the TimeOf the end snapshot of the first Occurrence equals the TimeOf the second Occurrence . timeOrderingConstraint If one Occurrence happens before another, then the TimeOf the end snapshot of the first Occurrence is no greater than the TimeOf the second Occurrence . 9.2.12.2.7 universalClock Element Feature Description universalClock is a single Clock that can be used as a default universal time reference. General Types objects UniversalClockLife Features None. Constraints None. 9.2.12.2.8 UniversalClockLife Element Structure Description UniversalClockLife is the classifier of the singleton Life of the universalClock General Types Life 352 Kernel Modeling Language v1.0 -Clock Features None. Constraints None. 9.2.13 Observation 9.2.13.1 Observation Overview This package models a framework for monitoring Boolean conditions and notifying registered observers when they change from false to true. 9.2.13.2 Elements 9.2.13.2.1 CancelObservation Element Behavior Description Cancel all observations of a given ChangeSignal for a given Occurrence . General Types Performance Features observer : Occurrence signal : ChangeSignal Constraints None. 9.2.13.2.2 ChangeMonitor Element Structure Description A ChangeMonitor is a collection of ongoing ChangeSignal observations for various observer Occurrences . It provides convenient operations for starting and canceling the observations it manages. General Types Object Kernel Modeling Language v1.0 353 -Features cancelObservation : CancelObservation [0..*] Cancel all observations of a given ChangeSignal for a given Occurrence . observations : ObserveChange [0..*] startObservation : StartObservation [0..*] Start an observation of a given ChangeSignal for a given Occurrence . Constraints None. 9.2.13.2.3 ChangeSignal Element Structure Description A ChangeSignal is a signal to be sent when the Boolean result of its changeCondition Expression changes from false to true. General Types Object Features signalCondition : BooleanEvaluation A BooleanExpression whose result is being monitored. signalMonitor : ChangeMonitor The ChangeMonitor responsible for monitoring the signalCondition. Constraints None. 9.2.13.2.4 defaultMonitor Element Feature Description defaultMonitor is a single ChangeMonitor that can be used as a default. General Types 354 Kernel Modeling Language v1.0 -DefaultMonitorLife objects Features None. Constraints None. 9.2.13.2.5 DefaultMonitorLife Element Structure Description DefaultMonitorLife is the classifier of the singleton Life of the defaultMonitor . General Types Life ChangeMonitor Features None. Constraints None. 9.2.13.2.6 ObserveChange Element Behavior Description Each Performance of ObserveChange waits for the result of the Boolean changeCondition of a given ChangeSignal to change from false to true, and, when it does, sends the ChangeSignal to a given observer Occurrence . General Types Performance Features changeObserver : Occurrence Kernel Modeling Language v1.0 355 -changeSignal : ChangeSignal transfer : TransferBefore [0..1] After waiting for the condition change (if necessary), then send changeSignal to changeObserver . wait : IfThenPerformance If the result of the changeSignal.signalCondition is false, then wait for it to become true: in ifTest { not changeSignal.signalCondition() } in thenClause : BooleanEvaluationResultToMonitorPerformance { in onOccurrence = changeSignal.signalCondition; } Constraints None. 9.2.13.2.7 StartObservation Element Behavior Description Start an observation of a given ChangeSignal for a given Occurrence . General Types Performance Features observer : Occurrence signal : ChangeSignal Constraints None. 9.2.14 Triggers 9.2.14.1 Triggers Overview This package contains functions that return ChangeSignals for triggering when a Boolean condition changes from false to true, at a specific time or after a specific time delay. 9.2.14.2 Elements 9.2.14.2.1 TimeSignal Element Structure 356 Kernel Modeling Language v1.0 -Description A TimeSignal is a ChangeSignal whose condition is the currentTime of a given Clock reaching a specific signalTime . General Types ChangeSignal Features signalClock : Clock The Clock whose currentTime is being monitored. signalCondition : BooleanEvaluation {redefines signalCondition} The Boolean condition of the currentTime of the signalClock being equal to the signalTime . signalTime : NumericalValue The time at which the TimeSignal should be sent. Constraints None. 9.2.14.2.2 TriggerAfter Element Function Description TriggerAfter returns a monitored TimeSignal to be sent to a receiver after a certain time delay relative to a given Clock. General Types Evaluation Features clock : Clock The Clock to be used as the reference for the time delay . The default is the localClock , which will be bound when the function is invoked. delay : NumericalValue The time duration, relative to the clock , after which the TimeSignal is sent. monitor : ChangeMonitor Kernel Modeling Language v1.0 357 -The ChangeMonitor to be used to monitor the TimeSignal condition. The default is the Observation::defaultMonitor receiver : Occurrence The Occurrence to which the TimeSignal is to be sent. signal : TimeSignal Constraints None. 9.2.14.2.3 TriggerAt Element Function Description TriggerAt returns a monitored TimeSignal to be sent to a receiver when the currentTime of a given Clock reaches a specific time. General Types Evaluation Features clock : Clock The Clock to be used as the reference for the timeInstant . The default is the localClock , which will be bound when the function is invoked. monitor : ChangeMonitor The ChangeMonitor to be used to monitor the TimeSignal condition. The default is the Observation::defaultMonitor receiver : Occurrence The Occurrence to which the TimeSignal is to be sent. signal : TimeSignal timeInstant : NumericalValue The time instant, relative to the clock , at which the TimeSignal should be sent. Constraints None. 9.2.14.2.4 TriggerWhen 358 Kernel Modeling Language v1.0 -Element Function Description TriggerWhen returns a monitored ChangeSignal for a given condition , to be sent to a given receiver when the condition occurs. General Types Evaluation Features condition : BooleanEvaluation The BooleanExpression to be monitored for changing from false to true. monitor : ChangeMonitor The ChangeMonitor to be used to monitor the ChangeSignal condition. The default is the Observation::defaultMonitor receiver : Occurrence The Occurrence to which the ChangeSignal is to be sent. signal : ChangeSignal Constraints None. 9.2.15 SpatialFrames 9.2.15.1 SpatialFrames Overview This package models spatial frames of reference for quantifying the position of points in a three-dimensional space. 9.2.15.2 Elements 9.2.15.2.1 CartesianCurrentDisplacementOf Element Function Description The CurrentDisplacementOf two Points relative to a CartesianSpatialFrame is a CartesianThreeVectorValue . General Types CurrentDisplacementOf Kernel Modeling Language v1.0 359 -Features clock : Clock {redefines clock} displacementVector : CartesianThreeVectorValue {redefines displacementVector} frame : CartesianSpatialFrame {redefines frame} point1 : Point {redefines point1} point2 : Point {redefines point2} Constraints None. 9.2.15.2.2 CartesianCurrentPositionOf Element Function Description The CurrentPositionOf a Point relative to a CartesianSpatialFrame is a CartesianThreeVectorValue . General Types CurrentPositionOf Features clock : Clock {redefines clock} Defaults to the localClock of the frame. frame : CartesianSpatialFrame {redefines frame} point : Point {redefines point} positionVector : CartesianThreeVectorValue {redefines positionVector} Constraints None. 9.2.15.2.3 CartesianDisplacementOf Element Function Description The DisplacementOf two Points relative to a CartesianSpatialFrame is a CartesianThreeVectorValue . 360 Kernel Modeling Language v1.0 -General Types DisplacementOf Features clock : Clock {redefines clock} Defaults to the localClock of the frame. displacementVector : CartesianThreeVectorValue {redefines displacementVector} frame : CartesianSpatialFrame {redefines frame} point1 : Point {redefines point1} point2 : Point {redefines point2} time : NumericalValue {redefines time} Constraints None. 9.2.15.2.4 CartesianPositionOf Element Function Description The PositionOf a Point relative to a CartesianSpatialFrame is a CartesianThreeVectorValue . General Types PositionOf Features clock : Clock {redefines clock} Defaults to the localClock of the frame. frame : CartesianSpatialFrame {redefines frame} point : Point {redefines point} positionVector : CartesianThreeVectorValue {redefines positionVector} time : NumericalValue {redefines time} Constraints None. Kernel Modeling Language v1.0 361 -9.2.15.2.5 CartesianSpatialFrame Element Structure Description A CartesianSpatialFrame is a SpatialFrame relative to which all position and displacement vectors can be represented as CartesianThreeVectorValues . General Types SpatialFrame Features None. Constraints None. 9.2.15.2.6 CurrentDisplacementOf Element Function Description The CurrentDisplacementOf two Points relative to a SpatialFrame and Clock is the DisplacementOf the Points relative to the SpacialFrame at the currentTime of the Clock . General Types Evaluation Features clock : Clock Defaults to the localClock of the frame. displacementVector : ThreeVectorValue frame : SpatialFrame point1 : Point point2 : Point Constraints None. 362 Kernel Modeling Language v1.0 -9.2.15.2.7 CurrentPositionOf Element Function Description The CurrentPositionOf a Point relative to a SpatialFrame and a Clock is the PositionOf the Point relative to the SpatialFrame at the currentTime of the Clock . General Types Evaluation Features clock : Clock Defaults to the localClock of the frame. frame : SpatialFrame point : Point positionVector : ThreeVectorValue Constraints None. 9.2.15.2.8 defaultFrame Element Feature Description defaultFrame is a fixed SpatialFrame used as a universal default. General Types objects DefaultFrameLife Features None. Constraints None. 9.2.15.2.9 DefaultFrameLife Kernel Modeling Language v1.0 363 -Element Structure Description DefaultFrameLife is the classifier of the singleton Life of the defaultFrame . General Types SpatialFrame Life Features None. Constraints None. 9.2.15.2.10 DisplacementOf Element Function Description The DisplacementOf two Points relative to a SpatialFrame , at a specific time relative to a given Clock , is the displacementVector computed as the difference between the PositionOf the first Point and PositionOf the second Point , relative to that SpatialFrame , at that time General Types Evaluation Features clock : Clock Defaults to the localClock of the frame. displacementVector : ThreeVectorValue frame : SpatialFrame point1 : Point point2 : Point time : NumericalValue Constraints 364 Kernel Modeling Language v1.0 -zeroDisplacementConstraint If either point1 or point2 occurs within the other, then the displacementVector is the zero vector. (point1.spaceTimeEnclosedOccurrences->includes(point2) or point2.spaceTimeEnclosedOccurrences->includes(point1)) implies isZeroVector(displacementVector) 9.2.15.2.11 PositionOf Element Function Description The PositionOf a Point relative to a SpatialFrame , at a specific time relative to a given Clock , as a positionVector that is a ThreeVectorValue . General Types Evaluation Features clock : Clock Defaults to the localClock of the frame. frame : SpatialFrame point : Point positionVector : ThreeVectorValue time : NumericalValue Constraints positionTimePrecondition The given point must exist at the given time . TimeOf(point.startShot) <= time and time <= TimeOf(point.endShot) spacePositionConstraint The result positionVector is equal to the PositionOf the Point spaceShot of the frame that encloses the given point , at the given time . (frame.spaceShots as Point)->forAll{in p : Point; p.spaceTimeEnclosedOccurrences->includes(point) implies positionVector == PositionOf(p, time, frame) } Kernel Modeling Language v1.0 365 -9.2.15.2.12 SpatialFrame Element Structure Description A SpatialFrame is a three-dimensional Body that provides a spatial extent that acts as a frame of reference for defining the physical position and displacement vectors of Points over time. General Types Body Features None. Constraints None. 9.2.16 Metaobjects 9.2.16.1 Metaobjects Overview This package defines Metaclasses and Features that are related to the typing of syntactic and semantic metadata. 9.2.16.2 Elements 9.2.16.2.1 Metaobject Element Metaclass Description A Metaobject contains syntactic or semantic information about one or more annotatedElements . It is the most general Metaclass . All other Metaclasses must subclassify it directly or indirectly. General Types Object Features annotatedElement : Element [1..*] The Elements annotated by this Metaobject . This is set automatically when a Metaobject is instantiated as the value of a MetadataFeature . Constraints None. 366 Kernel Modeling Language v1.0 -9.2.16.2.2 metaobjects Element Feature Description metaobjects is a specialization of objects restricted to type Metaobject . It is the most general MetadataFeature . All other MetadataFeatures must subset it directly or indirectly. General Types objects Metaobject Features None. Constraints None. 9.2.16.2.3 SemanticMetadata Element Metaclass Description SemanticMetadata is Metadata that requires its single annotatedElement to directly or indirectly specialize a baseType that models the semantics for the annotatedElement. General Types Metaobject Features annotatedElement : Type {redefines annotatedElement} The single annotatedElement of this SemanticMetadata, which must be a Type . baseType : Type The required base Type for the annotatedElement . Constraints None. Kernel Modeling Language v1.0 367 -9.2.17 KerML This package contains a reflective KerML model of the KerML abstract syntax. It is generated from the normative MOF abstract syntax model (see 8.3 ) as follows. 1. The KerML model contains subpackages for Root , Core , and Kernel , but all elements are also imported into the top-level package, so they can be referenced directly from the KerML namespace. 2. A metaclass from the MOF model is mapped into a Metaclass in the KerML package. ◦ The MOF metaclass name is mapped unchanged. ◦ Generalizations of the MOF metaclass are mapped to ownedSpecializations . ◦ All properties from the MOF metaclass are mapped to features of the corresponding KerML Metaclass (see below). All non-association-end properties are grouped before association-end properties. 3. A property from the MOF model is mapped into a Feature . ◦ The feature property isVariable is set to true . ◦ The following feature properties are set as appropriate: ▪ isAbstract = true if the MOF property is a derived union ▪ isComposite = true if the MOF property is composite. ▪ isConstant = true if the MOF property is read-only. ▪ isDerived = true if the MOF property is derived. ▪ isOrdered = true if the MOF property is ordered. ▪ isUnique = false if the MOF property is non-unique. ◦ The MOF property name is mapped unchanged. ◦ The MOF property type is mapped to an ownedTyping relationship. ▪ If the MOF property type is a primitive type, the relationship is to the corresponding type from the ScalarValues package (see 9.3.2 ). ▪ If the MOF property type is a metaclass, the relationship is to the corresponding reflective Metaclass . ◦ The MOF property multiplicity is mapped to an owned MultiplicityRange with bounds given by LiteralExpressions . ◦ Subsetted properties from the MOF property are mapped to ownedSubsettings of the corresponding reflective Features . ◦ Redefined properties from the MOF property are mapped to ownedRedefinitions of the corresponding reflective Features . ◦ If the MOF property is annotatedElement , then Metaobject::annotatedElement is added to the list of redefined properties for the mapping. 4. An enumeration from the MOF model is mapped into a DataType . ◦ The MOF enumeration name is mapped unchanged. ◦ Each enumeration literal from the MOF enumeration is mapped into an ownedMember Feature (not an ownedFeature ). ▪ The MOF enumeration literal name is mapped unchanged. ▪ The member Feature is given an owned MultiplicityRange of 1..1 . Note that associations are not mapped from the MOF model and, hence, non-navigable association-owned end properties are not included in the reflective model. 9.3 Data Type Library 9.3.1 Data Types Library Overview The Data Types Library provides a standard set of commonly used DataTypes for scalar, vector and collection values. 368 Kernel Modeling Language v1.0 -9.3.2 Scalar Values 9.3.2.1 Scalar Values Overview This package contains a basic set of primitive scalar (non-collection) data types. These include Boolean and String types and a hierarchy of concrete Number types, from the most general type of Complex numbers to the most specific type of Positive integers. 9.3.2.2 Elements 9.3.2.2.1 Boolean Element DataType Description Boolean is a ScalarValue type whose instances are true and false. General Types ScalarValue Features None. Constraints None. 9.3.2.2.2 Complex Element DataType Description Complex is the type of complex numbers. General Types Number Features None. Constraints None. 9.3.2.2.3 Integer Element Kernel Modeling Language v1.0 369 -DataType Description Integer is the type of mathematical integers, extended with values for positive and negative infinity. General Types Rational Features None. Constraints None. 9.3.2.2.4 Natural Element DataType Description Natural is the type of non-negative integers, extended with a value for positive infinity. General Types Integer Features None. Constraints None. 9.3.2.2.5 Number Element DataType Description Number is the base type for all NumericalValue types that represent numbers. General Types NumericalValue Features 370 Kernel Modeling Language v1.0 -None. Constraints None. 9.3.2.2.6 NumericalValue Element DataType Description NumericalValue is the base type for all ScalarValue types that represent numerical values. General Types ScalarValue Features None. Constraints None. 9.3.2.2.7 Positive Element DataType Description Positive is the type of positive integers (not including zero), extended with a value for positive infinity. General Types Natural Features None. Constraints None. 9.3.2.2.8 Rational Element DataType Description Kernel Modeling Language v1.0 371 -Rational is the type of rational numbers, extended with values for positive and negative infinity. General Types Real Features None. Constraints None. 9.3.2.2.9 Real Element DataType Description Real Real is the type of mathematical (extended) real numbers. This includes both rational and irrational numbers, and values for positive and negative infinity. General Types Complex Features None. Constraints None. 9.3.2.2.10 ScalarValue Element DataType Description A ScalarValue is a DataValue whose instances are considered to be primitive, not collections or structures of other values. General Types DataValue Features None. 372 Kernel Modeling Language v1.0 -Constraints None. 9.3.2.2.11 String Element DataType Description em> String is a ScalarValue type whose instances are strings of characters. General Types ScalarValue Features None. Constraints None. 9.3.3 Collections 9.3.3.1 Collections Overview This package defines a standard set of Collection data types. Unlike sequences of values defined directly using multiplicity, these data types allow for the possibility of collections as elements of collections. 9.3.3.2 Elements 9.3.3.2.1 Array Element DataType Description An Array is a fixed size, multi-dimensional Collection of which the elements are nonunique and ordered. Its dimensions specify how many dimensions the array has, and how many elements there are in each dimension. The rank is equal to the number of dimensions . The flattenedSize is equal to the total number of elements in the array. Feature elements is a flattened sequence of all elements of an Array and can be accessed by a tuple of indices. The number of indices is equal to rank . The elements are packed according to row-major convention, as in the C programming language. Note 1. Feature dimensions may be empty, which denotes a zero dimensional Array , allowing an Array to collapse to a single element. This is useful to allow for specialization of an Array into a type restricted to represent a scalar. The flattenedSize of a zero dimensional Array is 1. Kernel Modeling Language v1.0 373 -Note 2. An Array can also represent the generalized concept of a mathematical matrix of any rank, i.e. not limited to rank two. General Types OrderedCollection Features dimensions : Positive [0..*] {ordered, nonunique} flattenedSize : Positive rank : Natural Constraints sizeConstraint flattenedSize == size(elements) 9.3.3.2.2 Bag Element DataType Description A Bag is a variable size Collection of which the elements are unordered and nonunique. General Types Collection Features None. Constraints None. 9.3.3.2.3 Collection Element DataType Description A Collection is an abstract DataType that represents a collection of elements of a given type. General Types Anything 374 Kernel Modeling Language v1.0 -Features elements : Anything [0..*] {nonunique} Constraints None. 9.3.3.2.4 KeyValuePair Element DataType Description A KeyValuePair is an abstract DataType that represents a tuple of a key and an associated value val . General Types DataValue Features key : Anything val : Anything Constraints None. 9.3.3.2.5 List Element DataType Description A List is a variable size Collection of which the elements are nonunique and ordered. General Types OrderedCollection Features None. Constraints None. 9.3.3.2.6 Map Element Kernel Modeling Language v1.0 375 -DataType Description A Map is a variable size Collection of which the elements are KeyValuePairs . The keys must be unique within in the Map. The vakyues need not be unique. General Types UniqueCollection Features elements : KeyValuePair [0..*] {redefines elements} Constraints None. 9.3.3.2.7 OrderedCollection Element DataType Description An OrderedCollection is a Collection of which the elements are ordered and not necessarily unique. General Types Collection Features elements : Anything [0..*] {redefines elements, ordered, nonunique} Constraints None. 9.3.3.2.8 OrderedMap Element DataType Description An OrderedMap is a variable size Map that maintains ordering of its elements. The ordering may be by key of the KeyValuePair elements, or by order of construction, or any other method. The essential aspect is that ordering is maintained and guaranteed across accesses to the OrderedMap . General Types 376 Kernel Modeling Language v1.0 -OrderedCollection Map Features elements : KeyValuePair [0..*] {redefines elements, ordered} Constraints None. 9.3.3.2.9 OrderedSet Element DataType Description An OrderedSet is a variable size Collection of which the elements are unique and ordered. General Types OrderedCollection UniqueCollection Features elements : Anything [0..*] {redefines elements, ordered} Constraints None. 9.3.3.2.10 Set Element DataType Description A Set is a variable size Collection of which the elements are unique and unordered. General Types UniqueCollection Features None. Constraints None. Kernel Modeling Language v1.0 377 -9.3.3.2.11 UniqueCollection Element DataType Description A UniqueCollection is a Collection of which the elements are unique and not necessarily ordered. General Types Collection Features elements : Anything [0..*] {redefines elements} Constraints None. 9.3.4 Vector Values 9.3.4.1 Vector Values Overview This package provides a basic model of abstract vectors as well as concrete vectors whose components are NumericalValues . The package VectorFunctions defines the corresponding vector-space functions. 9.3.4.2 Elements 9.3.4.2.1 CartesianThreeVectorValue Element DataType Description A CartesianThreeVectorValue is a NumericalVectorValue that is both Cartesian and has dimension 3. General Types CartesianVectorValue ThreeVectorValue Features None. Constraints None. 378 Kernel Modeling Language v1.0 -9.3.4.2.2 CartesianVectorValue Element DataType Description A CartesianVectorValue is a NumericalVectorValue for which there are specific implementations in VectorFunctions of the abstract vector-space functions. Note: The restriction of the element type to Real is to facilitate the complete definition of these functions. General Types NumericalVectorValue Features elements : Real [0..*] {redefines elements} Constraints None. 9.3.4.2.3 NumericalVectorValue Element DataType Description A NumericalVectorValue is a kind of VectorValue that is specifically represented as a one-dimensional Array of NumericalValues . The dimension is allowed to be empty, permitting a NumericalVectorValue of rank 0, which is essentially isomorphic to a scalar NumericalValue . General Types Array VectorValue Features dimension : Positive [0..1] {redefines dimensions} elements : NumericalValue [0..*] {redefines elements} Constraints None. 9.3.4.2.4 ThreeVectorValue Element Kernel Modeling Language v1.0 379 -DataType Description A ThreeVectorValue is a NumericalVectorValue that has dimension 3. General Types NumericalVectorValue Features dimension : Positive [0..*] {redefines elements} Constraints None. 9.3.4.2.5 VectorValue Element DataType Description A VectorValue is an abstract data type whose values may be operated on using VectorFunctions . General Types None. Features None. Constraints None. 9.4 Function Library The Function Library includes library models of basic Functions that operate on DataTypes from the Data Type Library (see 9.3 ). The KerML operator expression notation translates to invocations of some of these library Functions . It is expected that other languages built on KerML will provide additional domain models as needed by their applications, which can include specializations of the library Functions for domain-specific DataTypes . The same KerML concrete syntax for Expressions can be used with these specialized Functions and DataTypes , extended with domain-specific semantics. 9.4.1 Function Library Overview The Function Library includes library models of basic Functions that operate on DataTypes from the Data Type Library (see 9.3 ). The KerML operator expression notation translates to invocations of some of these library Functions . It is expected that other languages built on KerML will provide additional domain models as needed by their applications, which can include specializations of the library Functions for domain-specific DataTypes . The 380 Kernel Modeling Language v1.0 -same KerML concrete syntax for Expressions can be used with these specialized Functions and DataTypes , extended with domain-specific semantics. 9.4.2 Base Functions 9.4.2.1 Base Functions Overview This package defines a basic set of Functions defined on all kinds of values. Most correspond to similarly named operators in the KerML expression notation. 9.4.2.2 Elements abstract function '=='{ in x: Anything[0..1]; in y: Anything[0..1]; return : Boolean[1]; } function '!='{ in x: Anything[0..1]; in y: Anything[0..1]; return : Boolean[1] = not (x == y); } abstract function '==='{ in x: Anything[0..1]; in y: Anything[0..1]; return : Boolean[1]; } function '!=='{ in x: Anything[0..1]; in y: Anything[0..1]; return : Boolean[1] = not (x === y); } function ToString{ in x: Anything[0..1]; return : String; } function '['{ in x: Anything[0..*] nonunique; in y: Anything[0..*] nonunique; return : Anything[0..*] nonunique; } function '#'{ in seq: Anything[0..*] ordered nonunique; in index: Positive[1..*] ordered nonunique; return : Anything[0..1]; } function ','{ in seq1: Anything[0..*] ordered nonunique; in seq2: Anything[0..*] ordered nonunique; return : Anything[0..*] ordered nonunique; } abstract function 'all'{ return : Object[0..*]; } Kernel Modeling Language v1.0 381 -abstract function 'istype'{ in seq: Anything[0..*]; abstract feature 'type': Anything; return : Boolean[1]; } abstract function 'hastype'{ in seq: Anything[0..*]; abstract feature 'type': Anything; return : Boolean; } abstract function '@'{ in seq: Anything[0..*]; abstract feature 'type': Anything; return : Boolean[1]; } abstract function '@@'{ in seq: Metaobject[0..*]; abstract feature 'type': Metaobject; return : Boolean[1]; } abstract function 'as'{ in seq: Anything[0..*] ordered nonunique; return : Anything[0..*] ordered nonunique; } abstract function 'meta'{ in seq: Metaobject[0..*] ordered nonunique; return : Metaobject[0..*] ordered nonunique; } 9.4.3 Data Functions 9.4.3.1 Data Functions Overview This package defines the abstract base Functions corresponding to all the unary and binary operators in the KerML expression notation that might be defined on various kinds of DataValues. 9.4.3.2 Elements abstract function '==' specializes BaseFunctions::'==' { in x: DataValue[0..1]; in y: DataValue[0..1]; return : Boolean[1]; } abstract function '===' specializes BaseFunctions::'===' { in x: DataValue[0..1]; in y: DataValue[0..1]; return : Boolean[1]; } abstract function '+' { in x: DataValue[1]; in y: DataValue[0..1]; return : DataValue[1]; } abstract function '-' { in x: DataValue[1]; in y: DataValue[0..1]; return : DataValue[1]; } abstract function '*' { in x: DataValue[1]; in y: DataValue[1]; return : DataValue[1]; } abstract function '/' { in x: DataValue[1]; in y: DataValue[1]; return : DataValue[1]; } abstract function '**' { in x: DataValue[1]; in y: DataValue[1]; return : DataValue[1]; } abstract function '^' { in x: DataValue[1]; in y: DataValue[1]; return : DataValue[1]; } abstract function '%' 382 Kernel Modeling Language v1.0 -{ in x: DataValue[1]; in y: DataValue[1]; return : DataValue[1]; } abstract function 'not' { in x: DataValue[1]; return : DataValue[1]; } abstract function 'xor' { in x: DataValue[1]; in y: DataValue[1]; return : DataValue[1]; } abstract function '~' { in x: DataValue[1]; return : DataValue[1]; } abstract function '|' { in x: DataValue[1]; in y: DataValue[1]; return : DataValue[1]; } abstract function '&' { in x: DataValue[1]; in y: DataValue[1]; return : DataValue[1]; } abstract function '<' { in x: DataValue[1]; in y: DataValue[1]; return : Boolean[1]; } abstract function '>' { in x: DataValue[1]; in y: DataValue[1]; return : Boolean[1]; } abstract function '<=' { in x: DataValue[1]; in y: DataValue[1]; return : Boolean[1]; } abstract function '>=' { in x: DataValue[1]; in y: DataValue[1]; return : Boolean[1]; } abstract function max { in x: DataValue[1]; in y: DataValue[1]; return : DataValue[1]; } abstract function min { in x: DataValue[1]; in y: DataValue[1]; return : DataValue[1]; } abstract function '..' { in lower: DataValue[1]; in upper: DataValue[1]; return : DataValue[0..*] ordered; } 9.4.4 Scalar Functions 9.4.4.1 Scalar Functions Overview This package defines abstract Functions that specialize the DataFunctions for use with ScalarValues. 9.4.4.2 Elements abstract function '+' specializes DataFunctions::'+' { in x: ScalarValue[1]; in y: ScalarValue[0..1]; return : ScalarValue[1]; } abstract function '-' specializes DataFunctions::'-' { in x: ScalarValue[1]; in y: ScalarValue[0..1]; return : ScalarValue[1]; } abstract function '*' specializes DataFunctions::'*' { in x: ScalarValue[1]; in y: ScalarValue[1]; return : ScalarValue[1]; } abstract function '/' specializes DataFunctions::'/' { in x: ScalarValue[1]; in y: ScalarValue[1]; return : ScalarValue[1]; } abstract function '**' specializes DataFunctions::'**' { in x: ScalarValue[1]; in y: ScalarValue[1]; return : ScalarValue[1]; } abstract function '^' specializes DataFunctions::'^' { in x: ScalarValue[1]; in y: ScalarValue[1]; return : ScalarValue[1]; } abstract function '%' specializes DataFunctions::'%' { in x: ScalarValue[1]; in y: ScalarValue[1]; return : ScalarValue[1]; } abstract function 'not' specializes DataFunctions::'not' { in x: ScalarValue[1]; return : ScalarValue[1]; } abstract function 'xor' specializes DataFunctions::'xor' { in x: ScalarValue[1]; in y: ScalarValue[1]; return : ScalarValue[1]; } abstract function '~' specializes DataFunctions::'~' { in x: ScalarValue[1]; return : ScalarValue[1]; } abstract function '|' specializes DataFunctions::'|' Kernel Modeling Language v1.0 383 -{ in x: ScalarValue[1]; in y: ScalarValue[1]; return : ScalarValue[1]; } abstract function '&' specializes DataFunctions::'&' { in x: ScalarValue[1]; in y: ScalarValue[1]; return : ScalarValue[1]; } abstract function '<' specializes DataFunctions::'<' { in x: ScalarValue[1]; in y: ScalarValue[1]; return : Boolean[1]; } abstract function '>' specializes DataFunctions::'>' { in x: ScalarValue[1]; in y: ScalarValue[1]; return : Boolean[1]; } abstract function '<=' specializes DataFunctions::'<=' { in x: ScalarValue[1]; in y: ScalarValue[1]; return : Boolean[1]; } abstract function '>=' specializes DataFunctions::'>=' { in x: ScalarValue[1]; in y: ScalarValue[1]; return : Boolean[1]; } abstract function max specializes DataFunctions::max { in x: ScalarValue[1]; in y: ScalarValue[1]; return : ScalarValue[1]; } abstract function min specializes DataFunctions::min { in x: ScalarValue[1]; in y: ScalarValue[1]; return : ScalarValue[1]; } abstract function '..' specializes DataFunctions::'..' { in lower: ScalarValue[1]; in upper: ScalarValue[1]; return : ScalarValue[0..*]; } 9.4.5 Boolean Functions 9.4.5.1 Boolean Functions Overview This package defines Functions on Boolean values, including those corresponding to (non-conditional) logical operators in the KerML expression notation. 9.4.5.2 Elements function 'not' specializes ScalarFunctions::'not' { in x: Boolean[1]; return : Boolean[1]; } function 'xor' specializes ScalarFunctions::'xor' { in x: Boolean[1]; in y: Boolean[1]; return : Boolean[1]; } function '|' specializes ScalarFunctions::'|' { in x: Boolean[1]; in y: Boolean[1]; return : Boolean[1]; } function '&' specializes ScalarFunctions::'&' { in x: Boolean[1]; in y: Boolean[1]; return : Boolean[1]; } function '==' specializes DataFunctions::'==' { in x: Boolean[0..1]; in y: Boolean[0..1]; return : Boolean[1]; } function ToString specializes BaseFunctions::ToString { in x: Boolean[1]; return : String[1]; } function ToBoolean { in x: String[1]; return : Boolean[1]; } 9.4.6 String Functions 9.4.6.1 String Functions Overview This package defines Functions on String values, including those corresponding to string concatenation and comparison operators in the KerML expression notation. 9.4.6.2 Elements function '+' specializes ScalarFunctions::'+' { in x: String[1]; in y:String[1]; return : String[1]; } 384 Kernel Modeling Language v1.0 -function Length { in x: String[1]; return : Natural[1]; } function Substring { in x: String[1]; in lower: Integer[1]; in upper: Integer[1]; return : String[1]; } function '<' specializes ScalarFunctions::'<' { in x: String[1]; in y: String[1]; return : Boolean[1]; } function '>' specializes ScalarFunctions::'>' { in x: String[1]; in y: String[1]; return : Boolean[1]; } function '<=' specializes ScalarFunctions::'<=' { in x: String[1]; in y: String[1]; return : Boolean[1]; } function '>=' specializes ScalarFunctions::'>=' { in x: String[1]; in y: String[1]; return : Boolean[1]; } function '==' specializes DataFunctions::'==' { in x: String[0..1]; in y: String[0..1]; return : Boolean[1]; } function ToString specializes BaseFunctions::ToString { in x: String[1]; } 9.4.7 Numerical Functions 9.4.7.1 Numerical Functions Overview This package defines abstract Functions on Numerical values for general arithmetic and comparison operations. 9.4.7.2 Elements abstract function isZero { in x: NumericalValue[1]; return : Boolean; } abstract function isUnit { in x : NumericalValue[1]; return : Boolean; } abstract function abs { in x: NumericalValue[1]; return : NumericalValue[1]; } abstract function '+' specializes ScalarFunctions::'+' { in x: NumericalValue[1]; in y: NumericalValue[0..1]; return : NumericalValue[1]; } abstract function '-' specializes ScalarFunctions::'-' { in x: NumericalValue[1]; in y: NumericalValue[0..1]; return : NumericalValue[1]; } abstract function '*' specializes ScalarFunctions::'*' { in x: NumericalValue[1]; in y: NumericalValue[1]; return : NumericalValue[1]; } abstract function '/' specializes ScalarFunctions::'/' { in x: NumericalValue[1]; in y: NumericalValue[1]; return : NumericalValue[1]; } abstract function '**' specializes ScalarFunctions::'**' { in x: NumericalValue[1]; in y: NumericalValue[1]; return : NumericalValue[1]; } abstract function '^' specializes ScalarFunctions::'^' { in x: NumericalValue[1]; in y: NumericalValue[1]; return : NumericalValue[1]; } abstract function '%' specializes ScalarFunctions::'%' { in x: NumericalValue[1]; in y: NumericalValue[1]; return : NumericalValue[1]; } abstract function '<' specializes ScalarFunctions::'<' { in x: NumericalValue[1]; in y: NumericalValue[1]; return : Boolean[1]; } abstract function '>' specializes ScalarFunctions::'>' Kernel Modeling Language v1.0 385 -{ in x: NumericalValue[1]; in y: NumericalValue[1]; return : Boolean[1]; } abstract function '<=' specializes ScalarFunctions::'<=' { in x: NumericalValue[1]; in y: NumericalValue[1]; return : Boolean[1]; } abstract function '>=' specializes ScalarFunctions::'>=' { in x: NumericalValue[1]; in y: NumericalValue[1]; return : Boolean[1]; } abstract function max specializes ScalarFunctions::max { in x: NumericalValue[1]; in y: NumericalValue[1]; return : NumericalValue[1]; } abstract function min specializes ScalarFunctions::min { in x: NumericalValue[1]; in y: NumericalValue[1]; return : NumericalValue[1]; } abstract function sum { in collection: ScalarValue[0..*]; return : ScalarValue[1]; } abstract function product { in collection: ScalarValue[0..*]; return : ScalarValue[1]; } 9.4.8 Complex Functions 9.4.8.1 Complex Functions Overview This package defines Functions on Complex values, including concrete specializations of the general arithmetic and comparison operations. 9.4.8.2 Elements feature i: Complex[1] = rect(0.0, 1.0); function rect { in re: Real[1]; in im: Real[1]; return : Complex[1]; } function polar { in abs: Real[1]; in arg: Real[1]; return : Complex[1]; } function re { in x: Complex[1]; return : Real[1]; } function im { in x: Complex[1]; return : Real[1]; } function isZero specializes NumericalFunctions::isZero { in x : Complex[1]; return : Boolean[1]; } function isUnit specializes NumericalFunctions::isUnit { in x : Complex[1]; return : Boolean[1]; } function abs specializes NumericalFunctions::abs { in x: Complex[1]; return : Real[1]; } function arg { in x: Complex[1]; return : Real[1]; } function '+' specializes NumericalFunctions::'+' { in x: Complex[1]; in y: Complex[0..1]; return : Complex[1]; } function '-' specializes NumericalFunctions::'-' { in x: Complex[1]; in y: Complex[0..1]; return : Complex[1]; } function '*' specializes NumericalFunctions::'*' { in x: Complex[1]; in y: Complex[1]; return : Complex[1]; } function '/' specializes NumericalFunctions::'/' { in x: Complex[1]; in y: Complex[1]; return : Complex[1]; } function '**' specializes NumericalFunctions::'**' { in x: Complex[1]; in y: Complex[1]; return : Complex[1]; } function '^' specializes NumericalFunctions::'^' { in x: Complex[1]; in y: Complex[1]; return : Complex[1]; } 386 Kernel Modeling Language v1.0 -function '==' specializes DataFunctions::'==' { in x: Complex[0..1]; in y: Complex[0..1]; return : Boolean[1]; } function ToString specializes BaseFunctions::ToString { in x: Complex[1]; return : String[1]; } function ToComplex { in x: String[1]; return : Complex[1]; } function sum specializes NumericalFunctions::sum { in collection: Complex[0..*]; return : Complex[1]; } function product specializes NumericalFunctions::product { in collection: Complex[0..*]; return : Complex[1]; } 9.4.9 Real Functions 9.4.9.1 Real Functions Overview This package defines Functions on Real values, including concrete specializations of the general arithmetic and comparison operations. 9.4.9.2 Elements function re :> ComplexFunctions::re { in x: Real[1]; return : Real[1] = x; } function im :> ComplexFunctions::im { in x: Real[1]; return : Real[1] = 0.0; } function abs specializes ComplexFunctions::abs { in x: Real[1]; return : Real[1]; } function arg specializes ComplexFunctions::arg { in x: Real[1]; return : Real[1] = 0.0; } function '+' specializes ComplexFunctions::'+' { in x: Real[1]; in y: Real[0..1]; return : Real[1]; } function '-' specializes ComplexFunctions::'-' { in x: Real[1]; in y: Real[0..1]; return : Real[1]; } function '*' specializes ComplexFunctions::'*' { in x: Real[1]; in y: Real[1]; return : Real[1]; } function '/' specializes ComplexFunctions::'/' { in x: Real[1]; in y: Real[1]; return : Real[1]; } function '**' specializes ComplexFunctions::'**' { in x: Real[1]; in y: Real[1]; return : Real[1]; } function '^' specializes ComplexFunctions::'^' { in x: Real[1]; in y: Real[1]; return : Real[1]; } function '<' specializes NumericalFunctions::'<' { in x: Real[1]; in y: Real[1]; return : Boolean[1]; } function '>' specializes NumericalFunctions::'>' { in x: Real[1]; in y: Real[1]; return : Boolean[1]; } function '<=' specializes NumericalFunctions::'<=' { in x: Real[1]; in y: Real[1]; return : Boolean[1]; } function '>=' specializes NumericalFunctions::'>=' { in x: Real[1]; in y: Real[1]; return : Boolean[1]; } function max specializes NumericalFunctions::max { in x: Real[1]; in y: Real[1]; return : Real[1]; } function min specializes NumericalFunctions::min { in x: Real[1]; in y: Real[1]; return : Real[1]; } function '==' specializes ComplexFunctions::'==' { in x: Real[0..1]; in y: Real[0..1]; return : Boolean[1]; } Kernel Modeling Language v1.0 387 -function sqrt { in x: Real[1]; return : Real[1]; } function floor { in x: Real[1]; return : Integer[1]; } function round { in x: Real[1]; return : Integer[1]; } function ToString specializes ComplexFunctions::ToString { in x: Real[1]; return : String[1]; } function ToInteger { in x: Real[1]; return : Integer[1]; } function ToRational { in x: Real[1]; return : Rational[1]; } function ToReal { in x: String[1]; return : Real[1]; } function sum specializes ComplexFunctions::sum { in collection: Real[0..*]; return : Real; } function product specializes ComplexFunctions::product { in collection: Real[0..*]; return : Real; } 9.4.10 Rational Functions 9.4.10.1 Rational Functions Overview This package defines Functions on Rational values, including concrete specializations of the general arithmetic and comparison operations. 9.4.10.2 Elements function rat { in numer: Integer[1]; in denum: Integer[1]; return : Rational[1]; } function numer { in rat: Rational[1]; return : Integer[1]; } function denom { in rat: Rational[1]; return : Integer[1]; } function abs specializes RealFunctions::abs { in x: Rational[1]; return : Rational[1]; } function '+' specializes RealFunctions::'+' { in x: Rational[1]; in y: Rational[0..1]; return : Rational[1]; } function '-' specializes RealFunctions::'-' { in x: Rational[1]; in y: Rational[0..1]; return : Rational[1]; } function '*' specializes RealFunctions::'*' { in x: Rational[1]; in y: Rational[1]; return : Rational[1]; } function '/' specializes RealFunctions::'/' { in x: Rational[1]; in y: Rational[1]; return : Rational[1]; } function '**' specializes RealFunctions::'**' { in x: Rational[1]; in y: Rational[1]; return : Rational[1]; } function '^' specializes RealFunctions::'^' { in x: Rational[1]; in y: Rational[1]; return : Rational[1]; } function '<' specializes RealFunctions::'<' { in x: Rational[1]; in y: Rational[1]; return : Boolean[1]; } function '>' specializes RealFunctions::'>' { in x: Rational[1]; in y: Rational[1]; return : Boolean[1]; } function '<=' specializes RealFunctions::'<=' { in x: Rational[1]; in y: Rational[1]; return : Boolean[1]; } 388 Kernel Modeling Language v1.0 -function '>=' specializes RealFunctions::'>=' { in x: Rational[1]; in y: Rational[1]; return : Boolean[1]; } function max specializes RealFunctions::max { in x: Rational[1]; in y: Rational[1]; return : Rational[1]; } function min specializes RealFunctions::min { in x: Rational[1]; in y: Rational[1]; return : Rational[1]; } function '==' specializes RealFunctions::'==' { in x: Rational[0..1]; in y: Rational[0..1]; return : Boolean[1]; } function gcd { in x: Rational[1]; in y: Rational[1]; return : Integer[1]; } function floor specializes RealFunctions::floor { in x: Rational[1]; return : Integer[1]; } function round specializes RealFunctions::round { in x: Rational[1]; return : Integer[1]; } function ToString specializes RealFunctions::ToString { in x: Rational[1]; return : String[1]; } function ToInteger { in x: Rational[1]; return : Integer[1]; } function ToRational { in x: String[1]; return : Rational[1]; } function sum specializes RealFunctions::sum { in collection: Rational[0..*]; return : Rational[1]; } function product specializes RealFunctions::product { in collection: Rational[0..*]; return : Rational[1]; } 9.4.11 Integer Functions 9.4.11.1 Integer Functions Overview This package defines Functions on Integer values, including concrete specializations of the general arithmetic and comparison operations. 9.4.11.2 Elements function abs specializes RationalFunctions::abs { in x: Integer[1]; return : Natural[1]; } function '+' specializes RationalFunctions::'+' { in x: Integer[1]; in y: Integer[0..1]; return : Integer[1]; } function '-' specializes RationalFunctions::'-' { in x: Integer[1]; in y: Integer[0..1]; return : Integer[1]; } function '*' specializes RationalFunctions::'*' { in x: Integer[1]; in y: Integer[1]; return : Integer[1]; } function '/' specializes RationalFunctions::'/' { in x: Integer[1]; in y: Integer[1]; return : Rational[1]; } function '**' specializes RationalFunctions::'**' { in x: Integer[1]; in y: Natural[1]; return : Integer[1]; } function '^' specializes RationalFunctions::'^' { in x: Integer[1]; in y: Natural[1]; return : Integer[1]; } function '%' specializes NumericalFunctions::'%' { in x: Integer[1]; in y: Integer[1]; return : Integer[1]; } function '<' specializes RationalFunctions::'<' { in x: Integer[1]; in y: Integer[1]; return : Boolean[1]; } function '>' specializes RationalFunctions::'>' Kernel Modeling Language v1.0 389 -{ in x: Integer[1]; in y: Integer[1]; return : Boolean[1]; } function '<=' specializes RationalFunctions::'<=' { in x: Integer[1]; in y: Integer[1]; return : Boolean[1]; } function '>=' specializes RationalFunctions::'>=' { in x: Integer[1]; in y: Integer[1]; return : Boolean[1]; } function max specializes RationalFunctions::max { in x: Integer[1]; in y: Integer[1]; return : Integer[1]; } function min specializes RationalFunctions::min { in x: Integer[1]; in y: Integer[1]; return : Integer[1]; } function '==' specializes DataFunctions::'==' { in x: Integer[0..1]; in y: Integer[0..1]; return : Boolean[1]; } function '..' specializes ScalarFunctions::'..' { in lower: Integer[1]; in upper: Integer[1]; return : Integer[0..*]; } function ToString specializes RationalFunctions::ToString { in x: Integer[1]; return : String[1]; } function ToNatural { in x: Integer[1]; return : Natural[1]; } function ToInteger { in x: String[1]; return : Integer[1]; } function sum specializes RationalFunctions::sum { in collection: Integer[0..*]; return : Integer[1]; } function product specializes RationalFunctions::product { in collection: Integer[0..*]; return : Integer[1]; } 9.4.12 Natural Functions 9.4.12.1 Natural Functions Overview This package defines Functions on Natural values, including concrete specializations of the general arithmetic and comparison operations. 9.4.12.2 Elements function '+' specializes IntegerFunctions::'+' { in x: Natural[1]; in y: Natural[0..1]; return : Natural[1]; } function '*' specializes IntegerFunctions::'*' { in x: Natural[1]; in y: Natural[1]; return : Natural[1]; } function '/' specializes IntegerFunctions::'/' { in x: Natural[1]; in y: Natural[1]; return : Natural[1]; } function '%' specializes IntegerFunctions::'%' { in x: Natural[1]; in y: Natural[1]; return : Natural[1]; } function '<' specializes IntegerFunctions::'<' { in x: Natural[1]; in y: Natural[1]; return : Boolean[1]; } function '>' specializes IntegerFunctions::'>' { in x: Natural[1]; in y: Natural[1]; return : Boolean[1]; } function '<=' specializes IntegerFunctions::'<=' { in x: Natural[1]; in y: Natural[1]; return : Boolean[1]; } function '>=' specializes IntegerFunctions::'>=' { in x: Natural[1]; in y: Natural[1]; return : Boolean[1]; } function max specializes IntegerFunctions::max { in x: Natural[1]; in y: Natural[1]; return : Natural[1]; } function min specializes IntegerFunctions::min { in x: Natural[1]; in y: Natural[1]; return : Natural[1]; } 390 Kernel Modeling Language v1.0 -function '==' specializes IntegerFunctions::'==' { in x: Natural[0..1]; in y: Natural[0..1]; return : Boolean[1]; } function ToString specializes IntegerFunctions::ToString { in x: Natural[1]; return : String[1]; } function ToNatural { in x: String[1]; return : Natural[1]; } 9.4.13 Trig Functions 9.4.13.1 Trig Functions Overview This package defines basic trigonometric functions on real numbers. 9.4.13.2 Elements feature pi : Real; inv piPrecision { RealFunctions::round(pi * 1E20) == 314159265358979323846.0 } function deg { in theta_rad : Real[1]; return : Real[1] = theta_rad * 180 / pi; } function rad { in theta_deg : Real; return : Real[1] = theta_deg * pi / 180; } datatype UnitBoundedReal :> Real { inv unitBound { -1.0 <= that & that <= 1.0 } } function sin { in theta : Real[1]; return : UnitBoundedReal[1]; } function cos { in theta : Real[1]; return : UnitBoundedReal[1]; } function tan { in theta : Real[1]; return : Real = sin(theta) / cos(theta); } function cot { in theta : Real; return : Real = cos(theta) / sin(theta); } function arcsin { in x : UnitBoundedReal[1]; return : Real[1]; } function arccos { in x : UnitBoundedReal[1]; return : Real[1]; } function arctan { in x : Real[1]; return : Real[1]; } Kernel Modeling Language v1.0 391 -9.4.14 Sequence Functions 9.4.14.1 Sequence Functions Overview This package defines Functions that operate on general sequences of values. (For Functions that operate on Collection values, see CollectionFunctions.) 9.4.14.2 Elements function '#' specializes BaseFunctions::'#' { in seq: Anything[0..*] ordered nonunique; in index: Positive[1]; return : Anything[0..1]; } function equals{ in x: Anything[0..*] ordered nonunique; in y: Anything[0..*] ordered nonunique; return : Boolean[1]; } function same{ in x: Anything[0..*] ordered nonunique; in y: Anything[0..*] ordered nonunique; return : Boolean[1]; } function size{ in seq: Anything[0..*] nonunique; return : Natural[1]; } function isEmpty{ in seq: Anything[0..*] nonunique; return : Boolean[1]; } function notEmpty{ in seq: Anything[0..*] nonunique; return : Boolean[1]; } function includes{ in seq1: Anything[0..*] nonunique; in seq2: Anything[0..*] nonunique; return : Boolean[1]; } function includesOnly{ in seq1: Anything[0..*] nonunique; in seq2: Anything[0..*] nonunique; return : Boolean[1]; } function excludes{ in seq1: Anything[0..*] nonunique; in seq2: Anything[0..*] nonunique; return : Boolean[1]; } function union{ in seq1: Anything[0..*] ordered nonunique; in seq2: Anything[0..*] ordered nonunique; return : Anything[0..*] ordered nonunique; } function intersection{ in seq1: Anything[0..*] ordered nonunique; 392 Kernel Modeling Language v1.0 -in seq2: Anything[0..*] ordered nonunique; return : Anything[0..*] ordered nonunique; } function including{ in seq1: Anything[0..*] ordered nonunique; in seq2: Anything[0..*] ordered nonunique; return : Anything[0..*] ordered nonunique; } function includingAt{ in seq1: Anything[0..*] ordered nonunique; in seq2: Anything[0..*] ordered nonunique; in index: Positive[1]; return : Anything[0..*] ordered nonunique; } function excluding{ in seq1: Anything[0..*] ordered nonunique; in seq2: Anything[0..*] ordered nonunique; return : Anything[0..*] ordered nonunique; } function excludingAt{ in seq1: Anything[0..*] ordered nonunique; in seq2: Anything[0..*] ordered nonunique; in startIndex: Positive[1]; in endIndex: Positive[1] default startIndex; return : Anything[0..*] ordered nonunique; } function subsequence{ in seq: Anything[0..*] ordered nonunique; in startIndex: Positive[1]; in endIndex: Positive[1] default size(seq); return : Anything[0..*]; } function head{ in seq: Anything[0..*] ordered nonunique; return : Anything[0..1] = seq[1]; } function tail{ in seq: Anything[0..*] ordered nonunique; return : Anything[0..*] ordered nonunique; } function last{ in seq: Anything[0..*] ordered nonunique; return : Anything[0..1]; } behavior add { inout seq: Anything[0..*] ordered nonunique; in values: Anything[0..*] ordered nonunique; } behavior addAt { inout seq: Anything[0..*] ordered nonunique; in values: Anything[0..*] ordered nonunique; in index: Positive[1]; } behavior remove{ inout seq: Anything[0..*] ordered nonunique; in values: Anything[0..*]; } behavior removeAt{ Kernel Modeling Language v1.0 393 -inout seq: Anything[0..*] ordered nonunique; in startIndex: Positive[1]; in endIndex: Positive[1] default startIndex; } 9.4.15 Collection Functions 9.4.15.1 Collection Functions Overview This package defines Functions on Collections (as defined in the Collections package). For Functions on general sequences of values, see the SequenceFunctions package. 9.4.15.2 Elements function '==' specializes BaseFunctions::'==' { in col1: Collection[0..1]; in col2: Collection[0..1]; return : Boolean[1]; } function size { in col: Collection[1]; return : Natural[1]; } function isEmpty { in col: Collection[1]; return : Boolean[1]; } function notEmpty { in col: Collection[1]; return : Boolean[1]; } function contains { in col: Collection[1]; in values: Anything[*]; return : Boolean[1]; } function containsAll { in col1: Collection[1]; in col2: Collection[2]; return : Boolean[1]; } function head { in col: OrderedCollection[1]; return : Anything[0..1]; } function tail { in col: OrderedCollection[1]; return : Anything[0..*] ordered nonunique; } function last { in col: OrderedCollection[1]; return : Anything[0..1]; } 394 Kernel Modeling Language v1.0 -function '#' specializes BaseFunctions::'#' { in col: OrderedCollection[1]; in index: Positive[1]; return : Anything[0..1]; } function 'array#' specializes BaseFunctions::'#' { in arr: Array[1]; in indexes: Positive[n] ordered nonunique; return : Anything[0..1]; private feature n: Natural[1] = arr.rank; } 9.4.16 Vector Functions 9.4.16.1 Vector Functions Overview This package defines abstract functions on VectorValues corresponding to the algebraic operations provided by a vector space with inner product. It also includes concrete implementations of these functions specifically for CartesianVectorValues . 9.4.16.2 Elements abstract function isZeroVector { doc /* * Return whether a VectorValue is a zero vector. */ in v: VectorValue[1]; return : Boolean[1]; } abstract function '+' specializes DataFunctions::'+' { doc /* * With two arguments, returns the sum of two VectorValues. * With one argument, returns that VectorValue. */ in v: VectorValue[1]; in w: VectorValue[0..1]; return u: VectorValue[1]; inv zeroAddition { w == null or isZeroVector(w) implies u == w } inv commutivity { w != null implies u == w + v } } abstract function '-' specializes DataFunctions::'-' { doc /* * With two arguments, returns the difference of two VectorValues. * With one arguments, returns the inverse * of the given VectorValue, that is, the VectorValue that, * when added to the original VectorValue, results in * the zeroVector. */ in v: VectorValue[1]; in w: VectorValue[0..1]; return u: VectorValue[1]; inv negation { w == null implies isZeroVector(v + u) } inv difference { w != null implies v + u == w } Kernel Modeling Language v1.0 395 -} abstract function sum0 { doc /* * Return the sum of a collection of VectorValues. * If the collection is empty, return a given zero vector. */ in coll: VectorValue[*] nonunique; in zero: VectorValue[1]; inv precondition { isZeroVector(zero) } return s: VectorValue[1] = coll->reduce '+' ?? zero; } /* Functions specific to NumericalVectorValues. */ function VectorOf { doc /* * Construct a NumericalVectorValue whose elements are a * non-empty list of component NumericalValues. * The dimension of the NumericalVectorValue is equal to * the number of components. */ in components: NumericalValue[1..*] ordered nonunique; return : NumericalVectorValue[1] { :>> dimension = size(components); :>> elements = components; } } abstract function scalarVectorMult specializes DataFunctions::'*' { doc /* * Scalar product of a NumericalValue and a NumericalVectorValue. */ in x: NumericalValue[1]; in v: NumericalVectorValue[1]; return w: NumericalVectorValue[1]; inv scaling { norm(w) == x * norm(v) } inv zeroLength { isZeroVector(w) implies isZero(norm(w))} } alias '*' for scalarVectorMult; abstract function vectorScalarMult specializes DataFunctions::'*' { doc /* * Scalar product of a NumericalVectorValue and a NumericalValue, * which has the same value as the scalar product of the * NumericalValue and the NumericalVectorValue. */ in v: NumericalVectorValue[1]; in x: NumericalValue[1]; return w: NumericalVectorValue[1] = scalarVectorMult(x, v); } abstract function vectorScalarDiv specializes DataFunctions::'/' { doc /* 396 Kernel Modeling Language v1.0 -* Scalar quotient of a NumericalVectorValue and a NumericalValue, * defined as the scalar product of the inverse of the * NumericalValue and the NumericalVectorValue. */ in v: NumericalVectorValue[1]; in x: NumericalValue[1]; return w: NumericalVectorValue[1] = scalarVectorMult(1.0 / x, v); } abstract function inner specializes DataFunctions::'*' { doc /* * Inner product of two NumericalVectorValues. */ in v: NumericalVectorValue[1]; in w: NumericalVectorValue[1]; return x: NumericalValue[1]; inv commmutivity { x == inner(w, v) } inv zeroInner { isZeroVector(v) or isZeroVector(w) implies isZero(x)} } abstract function norm { doc /* * The norm (magnitude) of a NumericalVectorValue, as a NumericalValue. */ in v: NumericalVectorValue[1]; return l : NumericalValue[1]; inv squareNorm { l * l == inner(v,v) } inv lengthZero { isZero(l) == isZeroVector(v) } } abstract function angle { doc /* * The angle between two NumericalVectorValues, as a NumericalValue. */ in v: NumericalVectorValue[1]; in w: NumericalVectorValue[1]; return theta: NumericalValue[1]; inv commutivity { theta == angle(w, v) } inv lengthInsensitive { theta == angle(w / norm(w), v / norm(v)) } } /* Specialized functions with concrete definitions for CartesianVectorValues. */ function CartesianVectorOf { doc /* * Construct a CartesianVectorValue whose elements are * a non-empty list of Real components. * The dimension of the NumericalVectorValue is equal * to the number of components. */ in components: Real[*] ordered nonunique; return : CartesianVectorValue[1] { :>> dimension = size(components); :>> elements = components; Kernel Modeling Language v1.0 397 -} } function CartesianThreeVectorOf specializes CartesianVectorOf { in components: Real[3] ordered nonunique; return : CartesianThreeVectorValue[1]; } feature cartesianZeroVector: CartesianVectorValue[3] = ( CartesianVectorOf(0.0), CartesianVectorOf((0.0, 0.0)), CartesianThreeVectorOf((0.0, 0.0, 0.0)) ) { doc /* * Cartesian zero vectors of 1, 2 and 3 dimensions. */ } feature cartesian3DZeroVector: CartesianThreeVectorValue[1] = cartesianZeroVector[3]; function isCartesianZeroVector specializes isZeroVector { doc /* * A CartesianVectorValue is a zero vector if all its elements are zero. */ in v: CartesianVectorValue[1]; return : Boolean[1] = v.elements->forAll{in x; x == 0.0}; } function 'cartesian+' specializes '+' { in v: CartesianVectorValue[1]; in w: CartesianVectorValue[0..1]; inv precondition { w != null implies v.dimension == w.dimension } return u: CartesianVectorValue[1] = if w == null? v else CartesianVectorOf( (1..w.dimension)->collect{in i : Positive; v[i] + w[i]} ); } function 'cartesian-' specializes '-' { in v: CartesianVectorValue[1]; in w: CartesianVectorValue[0..1]; inv precondition { w != null implies v.dimension == w.dimension } return u: CartesianVectorValue[1] = CartesianVectorOf( if w == null? CartesianVectorOf(v.elements->collect{in x : Real; -x}) else CartesianVectorOf( (1..v.dimension)->collect{in i : Positive; v[i] - w[i]} ) ); } function cartesianScalarVectorMult specializes scalarVectorMult { in x: Real[1]; in v: CartesianVectorValue[1]; return w: CartesianVectorValue[1] = CartesianVectorOf( v.elements->collect{in y : Real; x * y} ); 398 Kernel Modeling Language v1.0 -} function cartesianVectorScalarMult specializes vectorScalarMult { in v: CartesianVectorValue[1]; in x: Real[1]; return w: CartesianVectorValue[1] = cartesianScalarVectorMult(x, v); } function cartesianInner specializes inner { in v: CartesianVectorValue[1]; in w : CartesianVectorValue[1]; inv precondition { v.dimension == w.dimension } return x: Real[1] = (1..v.dimension)->collect{in i : Positive; v[i] * w[i]}->reduce RealFunctions::'+'; } function cartesianNorm specializes norm { in v: CartesianVectorValue[1]; return l : NumericalValue[1] = sqrt(cartesianInner(v, v)); } function cartesianAngle specializes angle { in v: CartesianVectorValue[1]; in w: CartesianVectorValue[1]; inv precondition { v.dimension == w.dimension } return theta: Real[1] = arccos(cartesianInner(v, w) / (norm(v) * norm(w))); } function sum { in coll: CartesianThreeVectorValue[*]; return : CartesianThreeVectorValue[1] = sum0(coll, cartesian3DZeroVector); } 9.4.17 Control Functions 9.4.17.1 Control Functions Overview This package defines Functions that correspond to operators in the KerML expression notation for which one or more operands are Expressions whose evaluation is determined by another operand. 9.4.17.2 Elements abstract function '.' { in feature source : Anything[0..*] nonunique { abstract feature target : Anything[0..*] nonunique; } private feature chain chains source.target; chain } abstract function 'if' { in test: Boolean[1]; in expr thenValue[0..1] { return : Anything[0..*] ordered nonunique; } in expr elseValue[0..1] { return : Anything[0..*] ordered nonunique; } return : Anything[0..*] ordered nonunique; } abstract function '??' { in firstValue: Anything[0..*] ordered nonunique; in expr secondValue[0..1] { return : Anything[0..*] ordered nonunique; } return : Anything[0..*] ordered nonunique; } function 'and' { Kernel Modeling Language v1.0 399 -in firstValue: Boolean[1]; in expr secondValue[0..1] { return : Boolean[1]; } return : Boolean[1]; } function 'or'{ in firstValue: Boolean[1]; in expr secondValue[0..1] { return : Boolean[1]; } return : Boolean[1]; } function 'implies'{ in firstValue: Boolean[1]; in expr secondValue[0..1] { return : Boolean[1]; } return : Boolean[1]; } abstract function collect { in collection: Anything[0..*] ordered nonunique; in expr mapper[0..*] { in argument: Anything[1]; return : Anything[0..*] ordered nonunique; } return : Anything[0..*] ordered nonunique; } abstract function select { in collection: Anything[0..*] ordered nonunique; in expr selector[0..*] { in argument: Anything[1]; return : Boolean[1]; } return : Anything[0..*] ordered nonunique; } function selectOne { in collection: Anything[0..*] ordered nonunique; in expr selector1[0..*] { in argument: Anything[1]; return : Boolean[1]; } return : Anything[0..1] = collection->select {in x; selector1(x)}[1]; } abstract function reject{ in collection: Anything[0..*] ordered nonunique; in expr rejector[0..*] { in argument: Anything[1]; return : Boolean[1]; } return : Anything[0..*] ordered nonunique; } abstract function reduce { in collection: Anything[0..*] ordered nonunique; in expr reducer[0..*] { in firstArg: Anything[1]; in secondArg: Anything[1]; return : Anything[1]; } return : Anything[0..*] ordered nonunique; } 400 Kernel Modeling Language v1.0 -abstract function forAll { in collection: Anything[0..*] ordered nonunique; in expr test[0..*] { in argument: Anything[1]; return : Boolean[1]; } return : Boolean[1]; } abstract function exists { in collection: Anything[0..*] ordered nonunique; in expr test[0..*] { in argument: Anything[1]; return : Boolean[1]; } return : Boolean[1]; } function allTrue { in collection: Boolean[0..*]; return : Boolean[1] = collection->forAll {in x; x}; } function anyTrue { in collection: Boolean[0..*]; return : Boolean[1] = collection->exists {in x; x}; } function minimize { in collection: ScalarValue[1..*]; in expr fn[0..*] { in argument: ScalarValue[1]; return : ScalarValue[1]; } return : ScalarValue[1] = collection->collect {in x; fn(x)}->reduce min; } function maximize { in collection: ScalarValue[1..*]; in expr fn[0..*] { in argument: ScalarValue[1]; return : ScalarValue[1]; } return : ScalarValue = collection->collect {in x; fn(x)}->reduce max; } 9.4.18 Occurrence Functions 9.4.18.1 Occurrence Functions Overview This package defines utility functions that operate on occurrences, primarily related to the time during which those occurrences exist. 9.4.18.2 Elements function '===' specializes BaseFunctions::'===' { doc /* * Test whether two occurrences are portions of the same life. That is, whether they * represent different portions of the same entity (colloquially, whether they have Kernel Modeling Language v1.0 401 -* the same "identity"). */ in x: Occurrence[0..1]; in y: Occurrence[0..1]; return : Boolean[1] = x.portionOfLife == y.portionOfLife; } function isDuring { doc /* * Test whether a performance of this function happens during the input occurrence. */ in occ: Occurrence[1]; private connector all during: HappensDuring[0..1] from self to occ; return : Boolean[1] = notEmpty(during); } function create { doc /* * Ensure that the start of a given occurrence happens during a performance of this * function. The occurrence is also returned from the function. */ inout occ: Occurrence[1]; private connector : HappensDuring from occ.startShot to self; return : Occurrence[1] = occ; } function destroy { doc /* * Ensure that the end of a given occurrence happens during a performance of this * function. The occurrence is also returned from the function. */ inout occ: Occurrence[0..1]; private connector : HappensDuring from occ.endShot[0..1] to self; return : Occurrence[0..1] = occ; } function addNew { doc /* * Add a newly created occurrence to the given group of occurrences and return the * new occurrence. */ inout group: Occurrence[0..*] nonunique; inout occ: Occurrence[1]; private composite step : add { inout seq1 = group; in seq2 = create(occ); 402 Kernel Modeling Language v1.0 -} return : Occurrence[1] = occ; } function addNewAt { doc /* * Add a newly created occurrence to the given ordered group of occurrences at the given * index and return the new occurrence. */ inout group: Occurrence[0..*] ordered nonunique; inout occ: Occurrence[1]; in index: Positive[1]; private composite step : addAt { inout seq = group; in values = create(occ); in startIndex = index; } return : Occurrence[1] = occ; } behavior removeOld { doc /* * Remove a given occurrence from a group of occurrences and destroy it. */ inout group: Occurrence[0..*] nonunique; inout occ: Occurrence[0..1]; private composite step removeStep : remove { inout seq = group; in values = occ; } private succession removeStep then destroyStep; private composite step destroyStep : destroy { inout occ = removeOld::occ; } } behavior removeOldAt { doc /* * Removes the occurrence at a given index in an ordered group of occurrences * and destroy it. */ inout group: Occurrence[0..*] ordered nonunique; in index: Positive[1]; private feature oldOcc = group[index]; private composite step removeStep : remove { inout seq = group; in index = removeOldAt::index; } private succession removeStep then destroyStep; private composite step destroyStep : destroy { inout occ = oldOcc; Kernel Modeling Language v1.0 403 -} } 404 Kernel Modeling Language v1.0 -10Model Interchange 10.1 Model Interchange Overview Model interchange is the capability to interchange models between tools using file-base resources (see Clause 2 ). The unit of interchange is the project, which is defined as follows: A project is a set of root namespaces (see 7.2.5.3 and 8.2.3.4.1 ), including all elements in the ownership trees of those namespaces, and a set of references to used projects, such that every cross reference from an element in the project is to another element in that project or to an element in one of the used projects. The root namespaces in a project may be serialized into model interchange files, using any of the formats given in 10.2 . A project interchange file is then a compressed archive of model interchange files and additional required metadata, as described in 10.3 . KerML is intended to be used as the basis for building other modeling languages. Project-based model interchange as defined in this clause may also be used to interchange models in such languages. Each of the following subclauses includes descriptions of the allowed adaptations for interchanging models in KerML-based languages. 10.2 Model Interchange Formats A model interchange file contains a textual representation (known as a serialization) of a single root namespace (see 7.2.5.3 and 8.2.3.4.1 ) and all the elements in the ownership tree root in that namespace. A model interchange file shall have one of the following formats: 1. Textual notation, using the textual concrete syntax defined in this specification. Note that in certain limited cases, models conformant with the KerML syntax, but prepared by a means other than using the KerML textual concrete syntax, may not be fully serializable into the standard textual notation. In this case, a tool may either not export such model at all using the textual notation, or export the model as closely as possible, informing the user of any changes from the original model. A model interchange file in this format shall have the file extension .kerml . 2. JSON, using a format according to the JSON serialization mapping defined in 10.4 . A model interchange file in this format shall have the file extension .json . 3. XML, using the XML Metadata Interchange [XMI] format based on the MOF-conformant abstract syntax metamodel for KerML. A model interchange file in this format shall have the file extension .xmi . Every conformant KerML modeling tool shall provide the ability to import and/or export (as appropriate) models in at least one of the first two formats. For a KerML-based language: 1. Textual Notation. If the language has a textual concrete syntax, then this textual notation may be used as a model interchange file format. The language shall define a distinguishing file extension for files of its textual notation. 2. JSON. It shall always be possible to use JSON format as a model interchange file format, using the mapping strategy defined in 10.4 , as applied to the abstract syntax of the language. 3. XML. If the language is defined using a MOF-conformat abstract syntax, then XMI may be used as a model interchange file format. A KerML-based-language specification may specify further requirements on what interchange formats must be supported by conforming language tools. Kernel Modeling Language v1.0 405 -10.3 Model Interchange Projects A project interchange file is contains a single project serialized as a set of model interchange files, archived using the ZIP format [ZIP]. The archive shall contain a model interchange file for each of the root namespaces in the project, each formatted in one of the formats listed in 10.2 . In addition, the archive shall contain, at its top level, exactly one file named .project.json and exactly one file named .meta.json . A KerML project interchange file shall have the file extension .kpar (KerML Project Archive). Other than the use of the file extensions given in 10.2 , there are no requirements on the naming of the model interchange files. Nevertheless, they should be named in a way that is compatible across different file systems and that allows for easy reference using International Resource Identifiers (IRIs). The model interchange files may be organized into subdirectories, but this has no impact on the global scope for the project, which is always a flat namespace derived from the root namespaces of the project (see 8.2.3.5 ). However, each model interchange file shall be identifiable by a unique path in the archive directory structure. The .project.json file shall contain the InterchangeProject information shown in Fig. 42 , serialized as a single JSON object according to the Project schema definition in the ModelInterchange.json artifact provided with this specification. Table 12 gives all the properties of the InterchangeProject and InterchangeProjectUsage elements, consistent with the normative JSON schema. Every element referenced in a model interchange file in a project interchange file shall either also be contained in a model interchange file in that project interchange file, or in one of the projects referenced in the usage list for the project interchange file. The usage information for each used project includes an optional versionConstraint property. If given, then only versions of the project identified by the resource property that meet this constraint may be used. For an interchanged project, the version is as given in its version property. It is recommended, but not required, that semantic versioning (see https://semver.org/) be used for the version numbering of interchange projects and semantic versioning ranges (see, e.g., https://docs.npmjs.com/cli/v6/using-npm/semver#ranges) be used for version constraints. Tools that support such version formatting should report any version constraint violations when importing an interchange project, for any used projects with dereferencable resource IRIs. The .meta.json file shall contain further metadata on the project interchange file, serialized as a single JSON object according to the Meta schema definition in the ModelInterchange.json artifact provided with this specification. Table 13 describes all the fields specified in the normative JSON schema. A project interchange file for a KerML-based language shall include model interchange files specific to that language (as described in 10.2 ). Such a project interchange file may use the generic .kpar extension, or it may define its own language-specific extension. If it uses the .kpar extension, then the metadata for the file shall identify the KerML-based language metamodel (see Table 13 ). Each project interchange file shall only contain models in a single language, but it shall be able to have used projects both in the same language and in KerML (such as from the Kernel Model Libraries). A KerML-based-language specification may also allow for project interchange files that use projects in other KerML-based languages. 406 Kernel Modeling Language v1.0 -+usingProject ProjectBase ProjectUsageBase 1 0..* +name : String +usedProject +description : String [0..1] 1 0..* InterchangeProject +/usingProject +usage InterchangeProjectUsage +version : String 1 0..* +resource : IRI +license : String [0..1] {redefines usingProject} +versionConstraint : String [0..1] +maintainer : String [0..*] +website : IRI [0..1] +/usedProject +topic : String [0..*] 1 0..* {redefines usedProject} Figure 42. Interchange Projects Table 12. Interchange Project Information Property Type Mandatory Description name string yes The name of the project. A description of the description string no project. The version of the project version string yes being interchanged. The license by which license string no project content may be used. A list of names of maintainer array (of strings) no maintainers of the project. An IRI for a Web site with website IRI no further information on the project. A list of topics relevant to topic array (of strings) no the project. A list of project usage entries, one for each usage array (of objects) no project used by the project being interchanged, with properties as given below. An IRI identifying the project being used. If the yes IRI is dereferenceable, it resource IRI (within a usage ) should resolve to a project interchange file for the used project. Kernel Modeling Language v1.0 407 -Property Type Mandatory Description A constraint on the no versionConstraint string allowable versions of a (within a usage ) used project. Table 13. Interchange Project Metadata Name Type Mandatory Description An index of the global scope of the project, specified as a JSON object with a key for each name, whose associated value is index object yes the path to the model interchange file containing the root namespace for the named element. (See Notes 1 and 2.) The date and time of the creation of the project created string yes interchange file, in ISO 8601 format [ISO8601]. An IRI identifying the metamodel of the modeling language of the metamodel IRI no models being interchanged in this project interchange file. (See Note 3.) Whether derived property values are included in the includesDerived Boolean no model interchange files. (See Note 4.) Whether implied relationships are included includesImplied Boolean no in the model interchange files. (See Note 5.) A dictionary mapping paths to some or all of the model interchange files to checksum object no a list of one or more objects with the two properties given below. (See Note 2.) The checksum computed yes value according to the checksum string (within a checksum ) algorithm . Identification of the yes algorithm used to algorithm string (within a checksum ) computed the checksum value . (See Note 6.) 408 Kernel Modeling Language v1.0 -Notes 1. The index cross-references all the non-null shortNames and names of all the top-level elements of the root namespaces of the project (see 7.2.5.3 and 8.2.3.5 ) to the model interchange file of the root namespace that contains the element. Note that, while the names of all top-level elements in a root namespace must be unique, it is allowable (though not recommended) for top-level elements in different root namespaces of a project to have the same name. 2. File paths are always relative to the root of the project interchange file archive, with path segments separated by the forward slash symbol / , ending in a file name with extension (e.g., structure/ assembly/Body.json ) 3. For an OMG-standardized language, metamodel shall be the version-specific URI specified by OMG to identify the language. For KerML, this URI has the form https://www.omg.org/spec/KerML/ yyyymmxx , with a version-specific date stamp " yyyymmxx ". If metamodel is not given, the default is KerML (for a project interchange file with the .kpar extension). 4. If includesDerived = true , then the serializations in all XMI and JSON format model interchange files in the project interchange file shall include values for all derived properties. If i ncludesDerived = false , then XMI and JSON formatted model interchanges files shall not include values for any derived properties. If includesDerived is not given, then whether derived property values are included may vary one model interchange file to another, and it is also allowable for some values to be included for some derived properties and not others. 5. If includesImplied = true , then the serializations in all XMI and JSON formatted model interchange files in the project interchange file shall include all implied relationships, and the isImpliedIncluded property shall have the value true for all elements (see 8.3.2.1 on isImpliedIncluded ). If includesImplied = false , then XMI and JSON formatted model interchange files shall not include any implied relationships, and the isImpliedIncluded property shall have the value false for all elements. If includesImplied is not given, then whether implied relationships are included may vary from one model interchange file to another, and from element to element, as recorded by the value of the includesImplied property for each element. 6. Valid values for the checksum algorithm are ◦ SHA1 , SHA224 , SHA256 , SHA-384 , SHA3-256 , SHA3-384 , SHA3-512 [SHS] ◦ BLAKE2b-256 , BLAKE2b-384 , BLAKE2b-512 , BLAKE3 [BLAKE] ◦ MD2 , MD4 , MD5 , MD6 [MD] ◦ ADLER32 [ADLER] 10.4 JSON Serialization 10.4.1 Serialization Overview The JSON serialization format can be used to interchange any model conformant with the KerML abstract syntax. Each root namespace shall correspond with a model interchange file with the file extension .json and contain serializations of all model elements in the ownership tree root in that namespace. The contents of this file shall be in the JSON (JavaScript Object Notation) format [JSON] and, for KerML, conform to the JSON schema definitions in the KerML.json artifact provided with this specification. Other KerML-based languages may extend this schema or define their own schema, consistent with the serialization strategy defined here as applied to the abstract syntax of those languages. The following subclauses describe the serialization strategy, as realized in the normative JSON schema for KerML. 10.4.2 Primitive Type Serialization The UML primitive types used in the KerML abstract syntax map directly to core JSON Schema types, as shown in Table 14 . Kernel Modeling Language v1.0 409 -Table 14. UML Primitive Type Serialization UML Primitive Type JSON Schema Type Boolean boolean Integer integer Real number String string 10.4.3 Enumeration Serialization Enumeration values map to a JSON Schema string with a value that is the name of the enumeration literal, with the same capitalization as defined for the literal in the abstract syntax. For example, VisibilityKind::public maps to the string "public" . 10.4.4 Element Reference Serialization Values of abstract syntax properties typed by a metaclass (that is, Element or one of its subclasses) map to a JSON Schema object with a single field @id . The value of @id is a JSON Schema string with a value equal to the value of the elementId of the Element . For example: { "@id": "15fe7607-ceb8-38bb-bd04-dde8ca657cec" } 10.4.5 Element Serialization A model element maps to a JSON Schema object with fields @id , @type , and a set of its attributes. The field @id has a string value equal to the value of Element::elementId . The field @type has a string value equal to the name of the specific MOF type of the element, e.g. "Structure" . The remaining JSON Schema fields are mapped from the set of MOF properties specified as attributes of the MOF type of the element. This shall include all owned and inherited properties. In addition, while redefined properties are not inherited under MOF/UML rules, they shall be included in the set of properties serialized for the element if they have a different name than the redefining property. Each of these maps to a JSON Schema field, where the name of the field is equal to the name of the attribute and the value is equal to the serialization of the attribute value as described in the preceding subclauses. The value must adhere to the allowed multiplicity of the MOF attribute: • A multiplicity of [1..1] requires a non-null value. • A multiplicity of [0..1] allows a value or null • A multiplicity with an upper bound greater than 1 maps to a JSON Schema array with values equal to the serialization of the attribute values described in the preceding subclauses. 10.4.6 Model Serialization A root namespace maps to a JSON Schema array with values equal to the serialization, as described in the preceding subclauses, of all model elements in the ownership tree rooted in that namespace. 410 Kernel Modeling Language v1.0 -AAnnex: Model Execution (Informative) A.1 Overview The language semantics in this specification give conditions to check whether classifiers have been instantiated properly (see 7.3.2.1 ). For structures this includes their parts and other required objects, as well as feature values and links between them. For behaviors, this includes their steps and other required performances, as well as timing links between them. These two kinds of classifiers are typically interrelated, structures can require behaviors for proper instantiation and vice-versa. This annex outlines a procedure for incrementally instantiating (executing) classifiers to ensure the completed instances will pass the check above (satisfy classifier conditions). The order of instantiation obeys any timing specified by the classifier. For example, some structures might require others to exist first, such as parents before their children, or parts of a car before assembly, while behaviors typically require some steps to happen only after others finish, such as painting objects before drying them. It covers the basic patterns needed to aid development of a complete execution procedure. A.2 Modeling Instances and Feature Values Instances in this annex are modeled in KerML, rather than as runtime data structures. Execution is taken to be creating these modeled instances in an order specified by their classifiers. Instances are also modeled as classifiers (called atoms in this annex) that each correspond to their own single (runtime) instance. Atoms are all disjoint from each other, but not necessarily from other (non-atom) classifiers (such as the ones being instantiated). In the example below, MyBike and YourBike are atoms. They are both classified by Bicycle (and Vehicle by specialization). classifier Vehicle; classifier Bicycle specializes Vehicle; classifier MyBike [1] specializes Bicycle; classifier YourBike [1] specializes Bicycle disjoint from MyBike; Atoms in this annex are indicated by a user-defined keyword before classifier definitions, with multiplicity and disjointness implied by the keyword, as below. classifier Atom; metaclass AtomMetadata specializes Metaobject { baseType = Atom meta KerML::Classifier; } classifier Vehicle; classifier Bicycle specializes Vehicle; #atom classifier MyBike specializes Bicycle; #atom classifier YourBike specializes Bicycle; Atoms are assigned as feature values by typing a feature with them, or a union of atoms, and restricting the feature multiplicity as needed to match the number of atoms being assigned. The example below creates a classifier for the bicycle atoms above (OurBicycle), then redefines a feature ( stores ) to be typed by it. The multiplicity is restricted to the exact number of atoms creating during execution (2). Kernel Modeling Language v1.0 411 -classifier Garage { feature stores : Bicycle [*]; } classifier OurBicycle unions MyBike, YourBike; #atom classifier OurGarage specializes Garage { feature redefines stores : OurBicycle [2]; } A.3 Instantiation Procedure The instantiation procedure is described in cases of increasing capability. A.3.2 through A.3.4 cover features, including connectors, without any timing specified. These are applicable to structure and behavior, though the examples are structural. The rest of the procedure adds timing, first for structures, then behaviors. A.3.1 Overview The instantiation procedure is described in cases of increasing capability. A.3.2 through A.3.4 cover features, including connectors, without any timing specified. These are applicable to structure and behavior, though the examples are structural. The rest of the procedure adds timing, first for structures, then behaviors. A.3.2 Without connectors Take the example below to illustrate the procedure, a (non-association) classifier without connectors (features typed by associations). classifier Bicycle { feature rollsOn : Wheel [2]; feature holdsWheel : BikeFork [*]; } classifier Wheel; classifier BikeFork; The instantiation procedure starts with: 1. Create an atom of the classifier being instantiated (Bicycle). 2. Identify features of the instantiated classifier with lower multiplicity greater than zero that are not connectors or other features typed by associations ( rollsOn ). 3. Create atoms for the types of the above features (Wheel), at least up to the lower multiplicity of each feature (2), and assign them as values of the feature. The model being executed in this example does not specify timing, though it is typically expected that: • classifiers are produced before their atoms. • Atoms are produced before they are assigned as values or otherwise used by another atom. The first instantiation step produces the first atom below: #atom classifier MyBike specializes Bicycle; The third creates the rest and modifies the one above. Atoms appear each time they are modified (MyBike), to highlight execution order. #atom classifier MyWheel1 specializes Wheel; #atom 412 Kernel Modeling Language v1.0 -classifier MyWheel2 specializes Wheel; classifier MyWheel unions MyWheel1, MyWheel2; #atom classifier MyBike specializes Bicycle { feature redefines rollsOn : MyWheel; } A.3.3 One-to-one connectors This covers connectors that: • have multiplicity 1 at both ends, but unrestricted (∗) overall. • are not timing or binding connectors. The first above requires the connected features to have the same number of values. When this is not possible, such as the multiplicities of the connected features being incompatible (do not overlap, as in 0..1 and 2..*), the classifier is not instantiable (satisfiable). The example below adds a connector to the example in Without Connectors, with end multiplicities requiring each wheel to be fixed to its own fork, and vice-versa. classifier Bicycle { feature rollsOn : Wheel [2]; feature holdsWheel : BikeFork [*]; connector fixWheel : BikeWheelFixed from rollsOn [1] to holdsWheel [1]; } assoc BikeWheelFixed { end feature wheel : Wheel; end feature fixedTo : BikeFork; } The instantiation procedure from Without connectors continues with: 4. Identify connectors of the classifier being instantiated ( fixWheel ). 5. For each connector above a. Create association atoms for the types of the connectors identified in step 4 (BikeWheelFixed). See below for how many. b. Assign the two participant (end) features ( wheel and fixed ) in each association atom, with values taken from the corresponding connected feature ( rollsOn and holdsWheel ). See below for which values are taken. c. Assign the association atoms above as values of the corresponding connectors. For end multiplicity 1 on both ends ◦ Create the same number of association atoms as there are values of the connected features with the most values at the time the association atoms are created (2). ◦ Assign each connected feature value as participant in exactly one association atom. If one connected feature has fewer values than the other, create atoms for the type of that feature ( holdsWheel ) up to the number in the other feature ( rollsOn , 2), and assign them as values of the feature with fewer values. The model being executed in this example does not specify timing, though it is typically expected that: • association atoms are created just after values are assigned to connected features, whereupon the instantiation steps above could be taken on each connector right after its connected features are assigned values during step 3, see A.3.2 . Kernel Modeling Language v1.0 413 -After the instantiations in Without connectors, the steps above produce the following atoms. First, 5.a creates as many association atoms for the connector ( fixWheel ) as the connected feature with the most values (2 in rollsOn , assigned in Without connectors). #atom assoc MyBikeWheel1_Fork1_BWF_Link specializes BikeWheelFixed; #atom assoc MyBikeWheel2_Fork2_BWF_Link specializes BikeWheelFixed; Before 5.b assigns participant features, the one-to-one connector end multiplicities require additional atoms for the connected feature with fewer values ( holdsWheel ), to match the number of the values of the other connected feature ( rollsOn ). #atom classifier MyBikeFork1 specializes BikeFork; #atom classifier MyBikeFork2 specializes BikeFork; classifier MyBikeFork unions MyBikeFork1, MyBikeFork2; #atom classifier MyBike specializes Bicycle { feature redefines rollsOn : MyWheel; feature redefines holdsWheel : MyBikeFork; } Then 5.b assigns participant feature values to the association atoms created in 5.a, choosing in this execution to fix the first and second wheels to the first and second forks, respectively, #atom assoc MyBikeWheel1_Fork1_BWF_Link specializes BikeWheelFixed { end feature redefines wheel : MyWheel1; end feature redefines fixedTo : MyBikeFork1; } #atom assoc MyBikeWheel2_Fork2_BWF_Link specializes BikeWheelFixed { end feature redefines wheel : MyWheel2; end feature redefines fixedTo : MyBikeFork2; } Finally 5.c assigns the association atoms to the connector. classifier MyBikeWheel_Fork_BWF_Link unions MyBikeWheel1_Fork1_BWF_Link, MyBikeWheel2_Fork2_BWF_Link; #atom classifier MyBike specializes Bicycle { feature redefines rollsOn : MyWheel; feature redefines holdsWheel : MyBikeFork; connector redefines fixWheel : MyBikeWheel_Fork_BWF_Link [2] from rollsOn [1] to holdsWheel [1]; } A.3.4 One-to-unrestricted connectors This covers connectors that: • have multiplicity 1 at one end and unrestricted (∗) at the other, and unrestricted overall. • are not timing or binding connectors. 414 Kernel Modeling Language v1.0 -The first above enables the feature connected at the unrestricted end to have any number of values in satisfiable models, but if it has any values, all those values must be linked to exactly one (not necessarily unique) value of the other connected feature (at the multiplicity 1 end) in the same instance of the classifier being instantiated. When this is not possible, for example due to the connector's association multiplicities being too restrictive (such as not allowing for links to all the values of the connected features), the classifier is not instantiable (satisfiable). The example below adds another feature and connector to the example in A.3.3 . Every basket is intended to be fixed to one of the forks, though more than one basket might be fixed to the same fork, or some forks might have no baskets, ot there might be no baskets at all. classifier Bicycle { feature carrier : BikeBasket [*]; connector carrierFixed : BikeBasketFixed from carrier [*] to holdsWheel [1]; } classifier BikeBasket; assoc BikeBasketFixed { end feature basket : BikeBasket; end feature fixedTo : BikeFork; } Then the instantiation procedure from A.3.3 is amended for one unrestricted end: 5. For each connector above a. .., b. ..., c. ..., ... For end multiplicity 1 on one end and unrestricted on the other ◦ Create the same number of association atoms as there are values of the connected feature at the unrestricted end ( carrier ) at the time the association atoms are created. ◦ Assign each connected feature value at the unrestricted end as participant in exactly one association atom. Instantiation proceeds as in A.3.3 , modifying the classifier atom created there (MyBike), except the number of association atoms created is determined by the number of values of the connected feature at the unrestricted end ( carrier ), choosing in this execution to fix two baskets to the same fork. #atom classifier MyBikeBasket1 specializes BikeBasket; #atom classifier MyBikeBasket2 specializes BikeBasket; classifier MyBikeBasket unions MyBikeBasket1, MyBikeBasket2; #atom classifier MyBike specializes Bicycle { feature redefines carrier : MyBikeBasket [2]; } #atom assoc MyBikeBasket1_Fork1_BBF_Link specializes BikeBasketFixed { end feature redefines basket : MyBikeBasket1; end feature redefines fixedTo : MyBikeFork1; } #atom assoc MyBikeBasket2_Fork1_BBF_Link specializes BikeBasketFixed { end feature redefines basket : MyBikeBasket2; end feature redefines fixedTo : MyBikeFork1; } classifier MyBikeBasket_Fork_BBF_Link unions MyBikeBasket1_Fork1_BBF_Link, MyBikeBasket2_Fork1_BBF_Link; Kernel Modeling Language v1.0 415 -#atom classifier MyBike specializes Bicycle { feature redefines carrier : MyBikeBasket [2]; connector redefines carrierFixed : MyBikeBasket_Fork_BBF_Link [2] from carrier [*] to holdsWheel [1]; } A.3.5 Timing for structures Classes are classifiers for things that exist in time (occurrences), as compared to numbers or other mathematical entities. It usually matters when these things come into and go out of existence, at least relative to each other. For example, in structures it is typically intended that parts exist for at least as long as the thing they are part of. In the bicycle example above, the wheel atoms should exist at least as long as the bicycle atom. A simple way to do this is for a structure and its parts to all exist at exactly the same time, as show below. Bicycle is class with its part features subset from timeCoincidentOccurrences , ensuring the values of rollsOn and holdsWheel happen (start and end) at exactly the same time as the bicycle occurrence they are part of, see 9.2.4.1 . class Bicycle specializes Occurrence { feature rollsOn : Wheel [2] subsets timeCoincidentOccurrences; feature holdsWheel : BikeFork [2] subsets timeCoincidentOccurrences; } The keyword struct implies specialization from Occurrence and highlights the structural application of classes. With it the example above becomes: struct Bicycle { feature rollsOn : Wheel [2] subsets timeCoincidentOccurrences; feature holdsWheel : BikeFork [2] subsets timeCoincidentOccurrences; } Some features always include the thing featuring them as a value (logically reflexive), such as self (see 9.2.2.1 ), which subsets timeCoincidentOccurrences , because occurrences always exist at the same time as themselves (see 7.3.4.4 about feature subsetting). The instantiation procedure in A.3.2 is amended below assign values to reflexive features when it creates atoms for features with lower multiplicity greater than zero (3a), as well as assign values to features being subsetted (3b). 3. ... a. For features that always have their featuring thing as a value (at least self and the features it subsets), assign that atom as a value. b. If a feature subsets others ( rollsOn and holdsWheel subset timeCoincidentOccurrences , which subsets self ), assign values to the others also. The additional instantiation steps produce the atom below by: • Assigning MyBike with itself for self . • Introducing a class for all part atoms of MyBike, as well as the assembled MyBike, and assigning timeCoincidentOccurrences with it. The model being executed requires all the occurrences to come into and go out of existence at the same time, but since this is not possible when sequentially creating atoms, the ones below appear before they are assigned as values or otherwise used by another atom. struct MyBikeTimeCoincident unions MyWheel, MyBikeFork, MyBike; #atom struct MyBike specializes Bicycle { feature redefines self : MyBike; feature redefines timeCoincidentOccurrences : MyBikeTimeCoincident [5]; 416 Kernel Modeling Language v1.0 -feature redefines rollsOn : MyWheel; feature redefines holdsWheel : MyBikeFork; } It is more realistic for parts to exist before the things they they are a part of, such as the wheels and forks above existing before they are assembled into a bicycle. It also might be that the parts outlive the bicycle, if it's only disassembled rather than completely destroyed. A simple way to do this is for parts to exist longer than their assembly, as specified below by a HappensDuring connector (see 9.2.4.1 ) linking the bicycle ( self ) to all its parts ( allParts ), specified as a union of the part features (equivalent to part features subsetting the union feature, but excluding values that are not in the part features). This ensures each bicycle exists during the time their parts do, but enables the parts to exist before assembly into a bicycle, and after disassembly, when the bicycle no longer exists. They still might all exist at the exactly the same time, as in the previous example, because things that exist at the same time all happen during each other. struct Bicycle { feature rollsOn : Wheel [2]; feature holdsWheel : BikeFork [2]; feature allParts : Occurrence unions rollsOn, holdsWheel; connector b_during_ap : HappensDuring from [1] self to [*] allParts; } The instantiation procedure above is amended again to assign values to union features. 3. ... a. ..., b ... c. If a feature unions others ( allParts unions rollsOn and holdsWheel ), treat the others as subsetting the union feature, but only assigning values that are in the subsets. The instantiation procedure in A.3.4 , with the amendments above to A.3.2 , produces the additional or modified atoms below. #atom assoc MyBike_During_Wheel1_Link specializes HappensDuring { end feature redefines shorterOccurrence : MyBike; end feature redefines longerOccurrence : MyWheel1; } #atom assoc MyBike_During_Wheel2_Link specializes HappensDuring { end feature redefines shorterOccurrence : MyBike; end feature redefines longerOccurrence : MyWheel2; } #atom assoc MyBike_During_Fork1_Link specializes HappensDuring { end feature redefines shorterOccurrence : MyBike; end feature redefines longerOccurrence : MyBikeFork1; } #atom assoc MyBike_During_Fork2_Link specializes HappensDuring { end feature redefines shorterOccurrence : MyBike; end feature redefines longerOccurrence : MyBikeFork2; } assoc MyBike_During_Parts_Link specializes HappensDuring unions MyBike_During_Wheel1_Link, MyBike_During_Fork1_Link, MyBike_During_Wheel2_Link, MyBike_During_Fork2_Link; struct MyBikeParts unions MyWheel, MyBikeFork; #atom struct MyBike specializes Bicycle { Kernel Modeling Language v1.0 417 -feature redefines rollsOn : MyWheel; feature redefines holdsWheel : MyBikeFork; feature redefines allParts : MyBikeParts [4]; feature redefines self : MyBike; connector redefines b_during_ap : MyBike_During_Parts_Link [4] from [1] self to [*] allParts; } Parts are sometimes expected not to exist after their structures, such as when a bicycle is completely destroyed, rather than just disassembled. The wheels and forks above would not exist after the bicycle they are part of, even though they might have existed before it (was assembled). Since parts can be replaced over time, the only ones destroyed are those in the bicycle at the time it is destroyed (the parts replaced earlier are not affected because they are no longer in the bicycle). This is specified below by a HappensWhile connector, equivalent to a HappenDuring connector in both directions, ensuring the ends ( endShot ) of the parts (at the time the bicycle ends) happen at the same time as the bicycle (the connected feature values are timeCoincidentOccurrences of each other). End shots are instantaneous occurrences that happen at the end of another occurrence (life), but represent the same thing as that occurrence, see 9.2.4.1 . The ends of the parts are identified by "navigating" (chaining) through a series of features, each providing a value on which to get the next value in the navigation, starting with the end of the bicycle, see 7.3.4.6 . struct Bicycle { ... feature redefines endShot : Bicycle; connector be_while_pe : HappensWhile from [1] endShot to [*] endShot.allParts.endShot; } The keyword composite implies the end timing above when used in defining rollsOn and holdsWheel , as below. struct Bicycle { composite feature rollsOn : Wheel [2]; composite feature holdsWheel : BikeFork [2]; ... } The instantiation steps in A.3.2 will assign a value to endShot , because it has multiplicity [1], but this is delayed until everything else required in the structure has occurred, due to mandatory HappensBefore connectors to endShot . With the amendments above, the steps in A.3.4 produce the additional or modified atoms below. /* End atoms */ #atom struct MyWheel1End specializes Wheel; #atom struct MyWheel1 specializes Wheel { feature redefines endShot : MyWheel1End; } #atom struct MyWheel2End specializes Wheel; #atom struct MyWheel2 specializes Wheel { feature redefines endShot : MyWheel2End; } struct MyBikeFork1End specializes BikeFork; #atom struct MyBikeFork1 specializes BikeFork { feature redefines endShot : MyBikeFork1End; } struct MyBikeFork2End specializes BikeFork; 418 Kernel Modeling Language v1.0 -#atom struct MyBikeFork2 specializes BikeFork { feature redefines endShot : MyBikeFork2End; } #atom struct MyBikeEnd specializes Bicycle; /* HappensWhile atoms */ #atom assoc MyBikeEnd_While_Wheel1End_Link specializes HappensWhile { end feature redefines thisOccurrence : MyBikeEnd; end feature redefines thatOccurrence : MyWheel1End; } #atom assoc MyBikeEnd_While_Wheel2End_Link specializes HappensWhile { end feature redefines thisOccurrence : MyBikeEnd; end feature redefines thatOccurrence : MyWheel2End; } #atom assoc MyBikeEnd_While_Fork1End_Link specializes HappensWhile { end feature redefines thisOccurrence : MyBikeEnd; end feature redefines thatOccurrence : MyBikeFork1End; } #atom assoc MyBikeEnd_While_Fork2End_Link specializes HappensWhile { end feature redefines thisOccurrence : MyBikeEnd; end feature redefines thatOccurrence : MyBikeFork2End; } assoc MyBikeEnd_While_PartsEnd_Link specializes HappensWhile unions MyBikeEnd_While_Wheel1End_Link, MyBikeEnd_While_Fork1End_Link, MyBikeEnd_While_Wheel2End_Link, MyBikeEnd_While_Fork2End_Link; #atom struct MyBike specializes Bicycle { ... feature redefines endShot : MyBikeEnd; connector redefines be_while_pe : MyBikeEnd_While_PartsEnd_Link [4] from [1] endShot to [*] endShot.allParts.endShot; } A.3.6 Timing for behaviors, Sequences Behaviors also exist in time, but they come into and go out of existence differently than structures, relative to each other. For example, in behaviors it is typically intended that its steps happen: • during the behavior occurrence they are part of, but not last as long as it does. • before or after other steps in the same behavior occurrence. These can be modeled by: • subsetting step features (those typed by behaviors) from timeEnclosedOccurrences , ensuring they happen during the occurrence they are a step of, but are not required to happen the entire time, as with timeCoincidentOccurrences . • linking steps by HappensBefore connectors to specify the order they should occur in. The example below does this for a behavior with three steps. Only the first one ( paint ) is required (by its multiplicity), indicating the behavior starts there, while the rest ( dry and ship ) are unrestricted, to prevent the instantiation procedure from giving values to (performing) them too early. This is left to the end multiplicities of the Kernel Modeling Language v1.0 419 -timing connectors ( p_before_d and d_before_s ), which require their later step to happen once each time the earlier step does, and vice-versa, see A.3.3 . class Manufacture specializes Occurrence { feature paint : Paint [1] subsets timeEnclosedOccurrences; feature dry : Dry [*] subsets timeEnclosedOccurrences; connector p_before_d: HappensBefore from [1] paint to [1] dry; feature ship : Ship [*] subsets timeEnclosedOccurrences; connector d_before_s: HappensBefore from [1] dry to [1] ship; } behavior Paint; behavior Dry; behavior Ship; The keyword: • step implies subsetting timeEnclosedOccurrences . These are features of behaviors typed by behaviors. • succession implies typing connectors by HappensBefore, and indicates the ends with first and then , instead of from and to , respectively. With these the example above becomes: behavior Manufacture { step paint : Paint [1]; step dry : Dry [*]; succession p_before_d first [1] paint then [1] dry; step ship : Ship [*]; succession d_before_s first [1] dry then [1] ship; } The instantiation procedure in A.3.3 produces the atoms below, including: • creating step atoms required by one-to-one connectors, and • the typically expected order to create associaton atoms (association atoms are created and assigned just after values are assigned to connected features), taken as required for behavioral connectors. In this example, it results in creating the atoms below ("taking" steps) in the order typically expected for behavioral execution, even though the procedure is the same as for structural execution. Atoms appear below each time they are modified (MyManufacture), to highlight this. It starts by creating and assigning an atom for paint , to satisfy its multiplicity, see A.3.2 . The procedure ignores the others because their multiplicities do not require any values. #atom behavior MyManufacture specializes Manufacture; #atom behavior MyPaint specializes Paint; #atom behavior MyManufacture specializes Manufacture { feature redefines timeEnclosedOccurrences : MyPaint [1]; step redefines paint : MyPaint; } Step 5 in A.3.3 reacts to the new step atom above by looking for connectors from it with multiplicity [1] at the opposite end, finding p_before_d , then creating and assigning an atom for the step connected at that end ( dry ), to satisfy that end's multiplicity. 420 Kernel Modeling Language v1.0 -#atom behavior MyDry specializes Dry; #atom assoc MyPaint_Before_Dry_Link specializes HappensBefore { end feature redefines earlierOccurrence : MyPaint; end feature redefines laterOccurrence : MyDry; } behavior MyManufactureStepsPD unions MyPaint, MyDry; #atom behavior MyManufacture specializes Manufacture { feature redefines timeEnclosedOccurrences : MyManufactureStepsPD [2]; step redefines paint : MyPaint; step redefines dry : MyDry [1]; succession redefines p_before_d : MyPaint_Before_Dry_Link [1] first paint then dry; } Step 5 repeats for the remaining connector and step ( d_before_s and ship ). #atom behavior MyShip specializes Ship; #atom assoc MyDry_Before_Ship_Link specializes HappensBefore { end feature redefines earlierOccurrence : MyDry; end feature redefines laterOccurrence : MyShip; } behavior MyManufactureStepsPDS unions MyManufactureStepsPD, MyShip; #atom behavior MyManufacture specializes Manufacture { feature redefines timeEnclosedOccurrences : MyManufactureStepsPDS [3]; step redefines paint : MyPaint; step redefines dry : MyDry [1]; succession redefines p_before_d : MyPaint_Before_Dry_Link [1] first paint then dry; step redefines ship : MyShip [1]; succession redefines d_before_s : MyDry_Before_Ship_Link [1] first dry then ship; } A.3.7 Timing for behaviors, Decisions and merges Decisions and merges are steps that enable sequences to be selected during execution, rather than ahead of time in models, as in A.3.6 : • Decisions are steps with multiple outgoing successions, but only one is traversed during each execution of the decision. • Merges are steps with multiple incoming successions, but only one is traversed during each execution of the merge. These are modeled by: • Optional connector end multiplicities ([0..1]) on ends of the outgoing and incoming successions opposite decision and merge steps, respectively. This enables execution to determine which succession is traversed for each decision and merge. Kernel Modeling Language v1.0 421 -• Decision and merges steps typed by DecisionPerformance and MergePerformance from the Kernel library, respectively. These enable additional timing constraints that require exactly one succession to be traversed for each decision and merge. The example below includes a decision and merge, which appear in sequence like other steps, except with optional branching successions out and in, respectively. The timing constraints at the end ensure successions going out of the decision step and coming into the merge step have exactly one value (HappensBefore link) for each time those steps happen, identified by the library features outgoingHBLink and incomingHBLink of DecisionPerformance and MergePerformance, respectively, which are required to have exactly one value for each performance. behavior Manufacture { /* Before decision. */ step admit : Admit [1]; succession a_before_i first [1] admit then [1] inspect; /* Decision. */ step inspect : DecisionPerformance [*]; /* Two decision branches. */ succession i_before_f first [1] inspect then [0..1] finish; step finish : Touchup [*]; succession i_before_r first [1] inspect then [0..1] recycle; step recycle : MarkForRecycling [*]; /* Two merge branches. */ succession f_before_ms first [0..1] finish then [1] mShip; succession r_before_ms first [0..1] recycle then [1] mShip; /* Merge */ step mShip : MergePerformance [*]; /* After merge */ succession ms_before_s first [1] mShip then [1] ship; step ship : Ship [*]; /* Decision and merge timing constraints. */ feature inspectOutgoingHBLinks : HappensBefore [*] unions i_before_f, i_before_r; connector bindIOHBL : SelfLink from [1] inspectOutgoingHBLinks to [1] inspect.outgoingHBLink; feature mShipIncomingHBLinks : HappensBefore [*] unions f_before_ms, r_before_ms; connector bindmSIHBL : SelfLink from [1] mShipIncomingHBLinks to [1] mShip.incomingHBLink; } behavior Admit; behavior Touchup; behavior MarkForRecycling; behavior Ship; The instantiation procedure in A.3.3 is amended for decisions and merges: 5. For each connector above a. .., b. ..., c. ..., ... For succession connectors with decision steps as their source or merge steps as their target ◦ Create the same number of association atoms as there are values of all the connected features opposite the decision or merge step (1 for each in this example). ◦ Assign each connected feature value as participant in exactly one association atom. If all the connected features together opposite the decision or merge step has more or fewer values than the decision or merge step, create atoms for the type of the feature with fewer values up to the number in the other feature, and assign them as values of the first feature. 422 Kernel Modeling Language v1.0 -The instantiation steps above produce the following atoms, choosing in this execution to touchup, rather than mark for recycling. Only the final result of execution is shown, at the end for brevity (MyManufacture), while the other atoms appear in the order created. /* Before decision. */ #atom behavior MyAdmit specializes Admit; /* Decision. */ #atom behavior MyInspect specializes DecisionPerformance; #atom assoc MyAdmit_Before_Inspect_Link specializes HappensBefore { end feature redefines earlierOccurrence : MyAdmit; end feature redefines laterOccurrence : MyInspect; } /* One decision branch taken. */ #atom behavior MyTouchup specializes Touchup; #atom assoc MyInspect_Before_Touchup_Link specializes HappensBefore { end feature redefines earlierOccurrence : MyInspect; end feature redefines laterOccurrence : MyTouchup; } /* One merge branch taken. Merge. */ #atom behavior MyMergeToShip specializes MergePerformance; #atom assoc MyTouchup_Before_Merge_Link specializes HappensBefore { end feature redefines earlierOccurrence : MyTouchup; end feature redefines laterOccurrence : MyMergeToShip; } /* After merge. */ #atom behavior MyShip specializes Ship; #atom assoc MyMerge_Before_Ship_Link specializes HappensBefore { end feature redefines earlierOccurrence : MyMergeToShip; end feature redefines laterOccurrence : Ship; } behavior MyManufactureSteps unions MyAdmit, MyInspect, MyTouchup, MyMergeToShip, MyShip; #atom behavior MyManufacture specializes Manufacture { feature redefines timeEnclosedOccurrences : MyManufactureSteps [5]; /* Before decision. */ step redefines admit : MyAdmit [1]; /* Decision. */ step redefines inspect : MyInspect [1]; succession redefines a_before_i : MyAdmit_Before_Inspect_Link [1] first admit then inspect; /* One decision branch taken. */ step redefines finish : MyTouchup [1]; succession redefines i_before_f : MyInspect_Before_Touchup_Link [1] first inspect then finish; /* One merge branch taken. */ succession redefines f_before_ms : MyTouchup_Before_Merge_Link [1] first finish then mShip; Kernel Modeling Language v1.0 423 -/* Merge. */ step redefines mShip: MyMergeToShip [1]; /* After merge */ step redefines ship : MyShip [1]; succession redefines ms_before_s : MyMerge_Before_Ship_Link [1] first mShip then ship; /* Decision and merge timing constraints. */ feature redefines inspectOutgoingHBLinks : MyInspect_Before_Touchup_Link; feature redefines mShipIncomingHBLinks : MyTouchup_Before_Merge_Link; } A.3.8 Timing for behavior, Changing feature values This covers changes in feature values of occurrences. Change execution requires creating additional atoms for the periods (time slices) when feature values are unchanged for each occurrence (life), and ordering the slices in time as feature values change. Time slice atoms are also occurrences, but represent the same thing as their life occurrence, just for a potentially smaller period of time, see 9.2.4.1 . Changes to occurrence feature values is modeled using the library behavior FeatureWritePerformance as a step, specifying when the change is to happen, see 9.2.8.1 . Time slices are created each time it is performed. The example below adds to the example in A.3.6 . • A class with changeable features (MyProduct with isPainted , isDry , isShipped ). • Features of behaviors to identify the above ( objectToFinish ). • FeatureWritePerformance steps specifying when and how to change its feature values (in Paint, Dry, and Ship). FeatureWritePerformances ensure when they finish that the occurrence has a time slice starting right then with the feature values specified, though the values might change immediately afterwards. Execution must define time slice atoms that prevent feature values from changing between FeatureWritePerformances, see below. behavior Manufacture { feature objectToFinish : Product [1]; step paint : Paint [1]{ redefines objectToPaint = objectToFinish; } step dry : Dry [*] { redefines objectToDry = objectToFinish; } succession p_before_d first [1] paint then [1] dry; step ship : Ship [*] { redefines objectToShip = objectToFinish; } succession d_before_s first [1] dry then [1] ship; } struct Product { feature isPainted : Boolean [1] := false; feature isDry : Boolean [1] := true; feature isShipped : Boolean [1] := false; } behavior Paint { feature objectToPaint : Product [1]; step painting : FeatureWritePerformance [1] { 424 Kernel Modeling Language v1.0 -in redefines onOccurrence : Product = objectToPaint { redefines startingAt : Product { redefines accessedFeature : Boolean [1] subsets isDry; } } in redefines replacementValues = false; } succession p_before_p first [1] painting then [1] painted; step painted : FeatureWritePerformance [*] { in redefines onOccurrence : Product = objectToPaint { redefines startingAt : Product { redefines accessedFeature : Boolean [1] subsets isPainted; } } in redefines replacementValues = true; } } behavior Dry { feature objectToDry : Product [1]; step dried : FeatureWritePerformance [1] { in redefines onOccurrence : Product = objectToDry { redefines startingAt : Product { redefines accessedFeature : Boolean [1] subsets isDry; } } in redefines replacementValues = true; } } behavior Ship { feature objectToShip : Product [1]; step shipped : FeatureWritePerformance [1] { in redefines onOccurrence : Product = objectToShip { redefines startingAt : Product { redefines accessedFeature : Boolean [1] subsets isShipped; } } in redefines replacementValues = true; } } The instantiation procedure is amended with: 6. For behaviors with FeatureWritePerformances a. Create classes for time slices (ProductTimeSlice) specializing the kinds of things they are slicing (Product), and redefining the features being modified as readonly ( isPainted , isDry , isShipped ). b. Add time slice features to atoms of the kinds of things being modified (MyProduct): i. Before the first FeatureWritePerformance ( beforePaint ), ii. Between each successive FeatureWritePerformance ( whilePainting , afterPaint , afterDry ), iii. After the last FeatureWritePerformance ( afterShip ) c. In the behavior atom using FeatureWritePerformance (MyManufacture), create atoms for the above time slice features in order, assigning values to all the features, even if they were not modified, and specify that i. The first time slice above (i) ▪ Starts ( startShot ) at the same time ( timeCoincidentOccurrences ) as the behavior. ▪ Ends just before ( immediateSuccessors ) the first FeatureWritePerformance does ( paint.painting.endShot ). ii. The middle time slices (ii) ▪ Start at the same time a FeatureWritePerformance ends. Kernel Modeling Language v1.0 425 -▪ End just before the next one does. iii. The last time slice (iii) ▪ Starts at the same time the last FeatureWritePerformance ends ( ship.shipped.endShot ). ▪ Ends at the same times as the behavior. The instantiation steps above produce the following atoms, adding to (or modifying) those created in A.3.3 . Step 6.a produces: #atom struct MyProduct specializes Product; #atom behavior MyManufacture specializes Manufacture; struct ProductTimeSlice specializes Product { readonly feature redefines isPainted; readonly feature redefines isDry; readonly feature redefines isShipped; } Instantiation step 6.b.i. the start of 6.c.i produces the first time slice ( beforePaint ) and starts it. #atom struct MyProduct specializes Product { feature beforePaint : ProductTimeSlice [1] subsets timeSlices; } #atom behavior MyManufacture specializes Manufacture { feature redefines objectToFinish : MyProduct; feature redefines startShot subsets objectToFinish.beforePaint.startShot.timeCoincidentOccurrences; feature obPiP chains objectToFinish.beforePaint.isPainted = false; feature obPiD chains objectToFinish.beforePaint.isDry = true; feature obPiS chains objectToFinish.beforePaint.isShipped = false; } The first of instantiation step 6.b.ii and first start of 6.c.ii produces the second time slice ( whilePainting ), while the end of 6.c.i ends the first ( beforePaint ). The MyManufacture features above are omitted for brevity. #atom struct MyProduct specializes Product { feature beforePaint : ProductTimeSlice [1] subsets timeSlices; feature whilePainting : ProductTimeSlice [1] subsets timeSlices; } behavior MyProductFeatureWrite specializes FeatureWritePerformance { in redefines onOccurrence : MyProduct; } #atom behavior PaintingMyProductFeatureWrite specializes MyProductFeatureWrite; #atom behavior MyPaint specializes Paint { feature redefines objectToPaint : MyProduct; step redefines painting : PaintingMyProductFeatureWrite; } #atom behavior MyManufacture specializes Manufacture { ... step redefines paint : MyPaint; feature subsets objectToFinish.beforePaint.immediateSuccessors, objectToFinish.whilePainting.startShot.timeCoincidentOccurrences 426 Kernel Modeling Language v1.0 -chains paint.painting.endShot; feature owPiP chains objectToFinish.whilePainting.isPainted = false; feature owPiD chains objectToFinish.whilePainting.isDry = false; feature owPiS chains objectToFinish.whilePainting.isShipped = false; } The second of instantiation step 6.b.ii and second start of 6.c.ii produces the third time slice ( afterPaint ), while the end of the first 6.c.ii ends the second ( whilePainting ). #atom struct MyProduct specializes Product { feature beforePaint : ProductTimeSlice [1] subsets timeSlices; feature whilePainting : ProductTimeSlice [1] subsets timeSlices; feature afterPaint : ProductTimeSlice [1] subsets timeSlices; } #atom behavior PaintedMyProductFeatureWrite specializes MyProductFeatureWrite; #atom assoc MyPaintingFW_Before_PaintFW_Link specializes HappensBefore { end feature redefines earlierOccurrence : PaintingMyProductFeatureWrite; end feature redefines laterOccurrence : PaintedMyProductFeatureWrite; } #atom behavior MyPaint specializes Paint { feature redefines objectToPaint : MyProduct; step redefines painting : PaintingMyProductFeatureWrite; step redefines painted : PaintedMyProductFeatureWrite; succession redefines p_before_p : MyPaintingFW_Before_PaintFW_Link first painting then painted; } #atom behavior MyManufacture specializes Manufacture { ... feature subsets objectToFinish.whilePainting.immediateSuccessors, objectToFinish.afterPaint.startShot.timeCoincidentOccurrences chains paint.painted.endShot; feature oaPiP chains objectToFinish.afterPaint.isPainted = true; feature oaPiD chains objectToFinish.afterPaint.isDry = false; feature oaPiS chains objectToFinish.afterPaint.isShipped = false; } The third of instantiation step 6.b.ii and third start of 6.c.ii produces the fourth time slice ( afterDry ), while the end of the second 6.c.ii ends the third ( afterPaint ). #atom struct MyProduct specializes Product { feature beforePaint : ProductTimeSlice [1] subsets timeSlices; feature whilePainting : ProductTimeSlice [1] subsets timeSlices; feature afterPaint : ProductTimeSlice [1] subsets timeSlices; feature afterDry : ProductTimeSlice [1] subsets timeSlices; } #atom behavior MyDry specializes Dry { feature redefines objectToDry : MyProduct; step redefines dried : MyProductFeatureWrite; } #atom assoc MyPaint_Before_Dry_Link specializes HappensBefore { end feature redefines earlierOccurrence : MyPaint; end feature redefines laterOccurrence : MyDry; } behavior MyManufacture specializes Manufacture { Kernel Modeling Language v1.0 427 -... step redefines dry : MyDry; succession redefines p_before_d : MyPaint_Before_Dry_Link [1] first paint then dry; feature subsets objectToFinish.afterPaint.immediateSuccessors, objectToFinish.afterDry.startShot.timeCoincidentOccurrences chains dry.dried.endShot; feature oaDiP chains objectToFinish.afterDry.isPainted = true; feature oaDiD chains objectToFinish.afterDry.isDry = true; feature oaDiS chains objectToFinish.afterDry.isShipped = false; } Instantiation step 6.b.iii and 6.c.iii produce the fifth time slice ( afterShip ), while the end of the third 6.c.ii ends the fourth ( afterDry ). #atom struct MyProduct specializes Product { feature beforePaint : ProductTimeSlice [1] subsets timeSlices; feature whilePainting : ProductTimeSlice [1] subsets timeSlices; feature afterPaint : ProductTimeSlice [1] subsets timeSlices; feature afterDry : ProductTimeSlice [1] subsets timeSlices; feature afterShip : ProductTimeSlice [1] subsets timeSlices; } #atom behavior MyShip specializes Ship { feature redefines objectToShip : MyProduct; step redefines shipped : MyProductFeatureWrite; } #atom assoc MyDry_Before_Ship_Link specializes HappensBefore { end feature redefines earlierOccurrence : MyDry; end feature redefines laterOccurrence : MyShip; } #atom behavior MyManufacture specializes Manufacture { ... step redefines ship : MyShip; succession redefines d_before_s : MyDry_Before_Ship_Link [1] first dry then ship; feature subsets objectToFinish.afterDry.immediateSuccessors, objectToFinish.afterShip.startShot.timeCoincidentOccurrences chains ship.shipped.endShot; feature redefines endShot subsets objectToFinish.afterShip.timeCoincidentOccurrences; feature oaSiP chains objectToFinish.afterShip.isPainted = true; feature oaSiD chains objectToFinish.afterShip.isDry = true; feature oaSiS chains objectToFinish.afterShip.isShipped = true; } 428 Kernel Modeling Language v1.0 diff --git a/Resources/specification/2a-OMG_Systems_Modeling_Language.pdf.txt b/Resources/specification/2a-OMG_Systems_Modeling_Language.pdf.txt deleted file mode 100644 index f3c66af5..00000000 --- a/Resources/specification/2a-OMG_Systems_Modeling_Language.pdf.txt +++ /dev/null @@ -1,691 +0,0 @@ -® An OMG Systems Modeling Publication OMG Systems Modeling Language™ ® (SysML ) Version 2.0 Part 1: Language Specification _______________________________________________________________________________ OMG Document Number: formal/2026-03-02 Date: March 2026 Standard document URL: https://www.omg.org/spec/SysML/2.0/ _______________________________________________________________________________ - -Copyright © 2019-2025, 88solutions Corporation Copyright © 2023-2025, Aerospace Corporation Copyright © 2019-2025, Airbus Copyright © 2023-2025, Ansys Government Initiatives Copyright © 2019-2025, Aras Corporation Copyright © 2019-2025, Association of Universities for Research in Astronomy (AURA) Copyright © 2019-2025, BigLever Software Copyright © 2019-2025, Boeing Copyright © 2022-2025, Budapest University of Technology and Economics Copyright © 2021-2025, Commissariat à l'énergie atomique et aux énergies alternatives (CEA) Copyright © 2019-2025, Contact Software GmbH Copyright © 2019-2025, Dassault Systèmes (No Magic) Copyright © 2019-2025, DSC Corporation Copyright © 2020-2025, DEKonsult Copyright © 2020-2025, Delligatti Associates LLC Copyright © 2019-2025, The Charles Stark Draper Laboratory, Inc. Copyright © 2020-2025, ESTACA Copyright © 2023-2025, Galois, Inc. Copyright © 2019-2025, GfSE e.V. Copyright © 2019-2025, George Mason University Copyright © 2023-2025, Georgia Institute of Technology Copyright © 2024-2025, Integration Innovation, Inc. (i3) Copyright © 2019-2025, IBM Copyright © 2019-2025, Idaho National Laboratory Copyright © 2019-2025, INCOSE Copyright © 2023-2025, IncQuery Labs cPlc Copyright © 2019-2025, Intercax LLC Copyright © 2019-2025, Jet Propulsion Laboratory (California Institute of Technology) Copyright © 2024-2025, KDM Analytics Copyright © 2019-2025, Kenntnis LLC Copyright © 2020-2025, Kungliga Tekniska högskolon (KTH) Copyright © 2019-2025, LightStreet Consulting LLC Copyright © 2019-2025, Lockheed Martin Corporation Copyright © 2019-2025, Maplesoft Copyright © 2021-2025, MID GmbH Copyright © 2020-2025, MITRE Copyright © 2019-2025, Model Alchemy Consulting Copyright © 2019-2025, Model Driven Solutions, Inc. Copyright © 2019-2025, Model Foundry Pty. Ltd. Copyright © 2023-2025, Object Management Group, Inc. Copyright © 2019-2025, On-Line Application Research Corporation (OAC) Copyright © 2019-2025, oose eG Copyright © 2019-2025, Østfold University College Copyright © 2019-2025, PTC Copyright © 2020-2025, Qualtech Systems, Inc. Copyright © 2023-2025, RTX Copyright © 2019-2025, SAF Consulting Copyright © 2024-2025, Sensmetry Copyright © 2023-2025, Siemens Copyright © 2023-2025, Sierra Nevada Copyright © 2019-2025, Simula Research Laboratory AS Copyright © 2023-2025, Sparx Systems Copyright © 2024-2025, Systems and Software Engineering Group Copyright © 2019-2025, System Strategy, Inc. Copyright © 2024-2025, The MathWorks -Copyright © 2019-2025, Thematix Partners, LLC Copyright © 2019-2025, Tom Sawyer Copyright © 2023-2025, Tucson Embedded Systems, Inc. Copyright © 2019-2025, Universidad de Cantabria Copyright © 2019-2025, University of Alabama in Huntsville Copyright © 2023-2025, University of Arizona Copyright © 2019-2025, University of Detroit Mercy Copyright © 2019-2025, University of Kaiserslauten Copyright © 2020-2025, Willert Software Tools GmbH (SodiusWillert) Copyright © 2023-2024, Zuken Vitech Inc. -USE OF SPECIFICATION - TERMS, CONDITIONS & NOTICES The material in this document details an Object Management Group specification in accordance with the terms, conditions and notices set forth below. This document does not represent a commitment to implement any portion of this specification in any companys products. The information contained in this document is subject to change without notice. LICENSES The companies listed above have granted to the Object Management Group, Inc. (OMG) a nonexclusive, royalty-free, paid up, worldwide license to copy and distribute this document and to modify this document and distribute copies of the modified version. Each of the copyright holders listed above has agreed that no person shall be deemed to have infringed the copyright in the included material of any such copyright holder by reason of having used the specification set forth herein or having conformed any computer software to the specification. Subject to all of the terms and conditions below, the owners of the copyright in this specification hereby grant you a fully-paid up, non-exclusive, nontransferable, perpetual, worldwide license (without the right to sublicense), to use this specification to create and distribute software and special purpose specifications that are based upon this specification, and to use, copy, and distribute this specification as provided under the Copyright Act; provided that: (1) both the copyright notice identified above and this permission notice appear on any copies of this specification; (2) the use of the specifications is for informational purposes and will not be copied or posted on any network computer or broadcast in any media and will not be otherwise resold or transferred for commercial purposes; and (3) no modifications are made to this specification. This limited permission automatically terminates without notice if you breach any of these terms or conditions. Upon termination, you will destroy immediately any copies of the specifications in your possession or control. PATENTS The attention of adopters is directed to the possibility that compliance with or adoption of OMG specifications may require use of an invention covered by patent rights. OMG shall not be responsible for identifying patents for which a license may be required by any OMG specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. OMG specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. GENERAL USE RESTRICTIONS Any unauthorized use of this specification may violate copyright laws, trademark laws, and communications regulations and statutes. This document contains information which is protected by copyright. All Rights Reserved. No part of this work covered by copyright herein may be reproduced or used in any form or by any means--graphic, electronic, or mechanical, including photocopying, recording, taping, or information storage and retrieval systems--without permission of the copyright owner. DISCLAIMER OF WARRANTY WHILE THIS PUBLICATION IS BELIEVED TO BE ACCURATE, IT IS PROVIDED "AS IS" AND MAY CONTAIN ERRORS OR MISPRINTS. THE OBJECT MANAGEMENT GROUP AND THE COMPANIES LISTED ABOVE MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS PUBLICATION, INCLUDING BUT NOT LIMITED TO ANY WARRANTY OF TITLE OR -OWNERSHIP, IMPLIED WARRANTY OF MERCHANTABILITY OR WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE OR USE. IN NO EVENT SHALL THE OBJECT MANAGEMENT GROUP OR ANY OF THE COMPANIES LISTED ABOVE BE LIABLE FOR ERRORS CONTAINED HEREIN OR FOR DIRECT, INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, RELIANCE OR COVER DAMAGES, INCLUDING LOSS OF PROFITS, REVENUE, DATA OR USE, INCURRED BY ANY USER OR ANY THIRD PARTY IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS MATERIAL, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. The entire risk as to the quality and performance of software developed using this specification is borne by you. This disclaimer of warranty constitutes an essential part of the license granted to you to use this specification. RESTRICTED RIGHTS LEGEND Use, duplication or disclosure by the U.S. Government is subject to the restrictions set forth in subparagraph (c) (1) (ii) of The Rights in Technical Data and Computer Software Clause at DFARS 252.227-7013 or in subparagraph (c)(1) and (2) of the Commercial Computer Software - Restricted Rights clauses at 48 C.F.R. 52.227-19 or as specified in 48 C.F.R. 227-7202-2 of the DoD F.A.R. Supplement and its successors, or as specified in 48 C.F.R. 12.212 of the Federal Acquisition Regulations and its successors, as applicable. The specification copyright owners are as indicated above and may be contacted through the Object Management Group, 9C Medway Road, PMB 274, Milford, MA 01757, U.S.A. TRADEMARKS ® ® ® ® CORBA , CORBA logos , FIBO , Financial Industry Business Ontology , Financial Instrument Global ® ® ® ® ® ® ® Identifier , IIOP , IMM , Model Driven Architecture , MDA , Object Management Group , OMG , OMG ® ® ® ® ® ® ® Logo , SoaML , SOAML , SysML , UAF , Unified Modeling Language™, UML , UML Cube Logo , ® ® VSIPL , and XMI are registered trademarks of the Object Management Group, Inc. For a complete list of trademarks, see: https://www.omg.org/legal/tm_list.htm. All other products or company names mentioned are used for identification purposes only, and may be trademarks of their respective owners. COMPLIANCE The copyright holders listed above acknowledge that the Object Management Group (acting itself or through its designees) is and shall at all times be the sole entity that may authorize developers, suppliers and sellers of computer software to use certification marks, trademarks or other special designations to indicate compliance with these materials. Software developed under the terms of this license may claim compliance or conformance with this specification if and only if the software compliance is of a nature fully matching the applicable compliance points as stated in the specification. Software developed only partially matching the applicable compliance points may claim only that the software was based on this specification, but may not claim compliance or conformance with this specification. In the event that testing suites are implemented or approved by Object Management Group, Inc., software developed using this specification may claim compliance or conformance with the specification only if the software satisfactorily completes the testing suites. -OMG’S ISSUE REPORTING PROCEDURE All OMG specifications are subject to continuous review and improvement. As part of this process we encourage readers to report any ambiguities, inconsistencies, or inaccuracies they may find by completing the Issue Reporting Form listed on the main web page https://www.omg.org, under Documents, Report a Bug/Issue. - -Preface OMG Founded in 1989, the Object Management Group, Inc. (OMG) is an open membership, not-for-profit computer industry standards consortium that produces and maintains computer industry specifications for interoperable, portable, and reusable enterprise applications in distributed, heterogeneous environments. Membership includes Information Technology vendors, end users, government agencies, and academia. OMG member companies write, adopt, and maintain its specifications following a mature, open process. ® ® OMG’s specifications implement the Model Driven Architecture (MDA ), maximizing ROI through a full- lifecycle approach to enterprise integration that covers multiple operating systems, programming languages, middleware and networking infrastructures, and software development environments. OMG’s ® ® specifications include: UML (Unified Modeling Language™); CORBA (Common Object Request Broker Architecture); CWM™ (Common Warehouse Metamodel); and industry-specific standards for dozens of vertical markets. More information on the OMG is available at https://www.omg.org/. OMG Specifications As noted, OMG specifications address middleware, modeling, and vertical domain frameworks. All OMG Specifications are available from the OMG website at: https://www.omg.org/spec All of OMG’s formal specifications may be downloaded without charge from our website. (Products implementing OMG specifications are available from individual suppliers.) Copies of specifications, available in PostScript and PDF format, may be obtained from the Specifications Catalog cited above or by contacting the Object Management Group, Inc. at: OMG Headquarters 9C Medway Road, PMB 274 Milford, MA 01757 USA Tel: +1-781-444-0404 Fax: +1-781-444-0320 Email: pubs@omg.org Certain OMG specifications are also available as ISO standards. Please consult https://www.iso.org Issues All OMG specifications are subject to continuous review and improvement. As part of this process we encourage readers to report any ambiguities, inconsistencies, or inaccuracies they may find by completing the Issue Reporting Form listed on the main web page https://www.omg.org, under Specifications, Report an Issue. - -Table of Contents 1 Scope.................................................................................................................................................................................................1 2 Conformance.....................................................................................................................................................................................3 3 Normative References.......................................................................................................................................................................5 4 Terms and Definitions.......................................................................................................................................................................7 5 Symbols ............................................................................................................................................................................................9 6 Introduction.....................................................................................................................................................................................11 6.1 Document Overview ...........................................................................................................................................................11 6.2 Document Organization ......................................................................................................................................................12 6.3 Acknowledgements .............................................................................................................................................................13 7 Language Description .....................................................................................................................................................................15 7.1 Language Overview ............................................................................................................................................................15 7.2 Elements and Relationships ................................................................................................................................................16 7.2.1 Elements and Relationships Overview....................................................................................................................16 7.2.2 Elements ..................................................................................................................................................................17 7.2.3 Relationships ...........................................................................................................................................................18 7.3 Dependencies ......................................................................................................................................................................18 7.3.1 Dependencies Overview..........................................................................................................................................18 7.3.2 Dependency Declaration .........................................................................................................................................19 7.4 Annotations .........................................................................................................................................................................19 7.4.1 Annotations Overview ............................................................................................................................................19 7.4.2 Comments and Documentation ...............................................................................................................................21 7.4.3 Textual Representation............................................................................................................................................22 7.5 Namespaces and Packages ..................................................................................................................................................23 7.5.1 Namespaces Overview ............................................................................................................................................23 7.5.2 Owned Members and Aliases..................................................................................................................................26 7.5.3 Imports ....................................................................................................................................................................27 7.5.4 Import Filtering .......................................................................................................................................................29 7.5.5 Root Namespaces ....................................................................................................................................................30 7.6 Definition and Usage ..........................................................................................................................................................31 7.6.1 Definition and Usage Overview..............................................................................................................................31 7.6.2 Definitions...............................................................................................................................................................39 7.6.3 Usages .....................................................................................................................................................................40 7.6.4 Reference Usages ....................................................................................................................................................42 7.6.5 Effective Names ......................................................................................................................................................42 7.6.6 Feature Chains.........................................................................................................................................................43 7.6.7 Variations and Variants...........................................................................................................................................43 7.6.8 Implicit Specialization ............................................................................................................................................44 7.7 Attributes.............................................................................................................................................................................45 7.7.1 Attributes Overview ................................................................................................................................................45 7.7.2 Attribute Definitions and Usages ............................................................................................................................46 7.8 Enumerations ......................................................................................................................................................................47 7.8.1 Enumerations Overview..........................................................................................................................................47 7.8.2 Enumeration Definitions and Usages......................................................................................................................48 7.9 Occurrences.........................................................................................................................................................................49 7.9.1 Occurrences Overview ............................................................................................................................................49 7.9.2 Occurrence Definitions and Usages ........................................................................................................................54 7.9.3 Time Slices and Snapshots......................................................................................................................................54 7.9.4 Individual Definitions and Usages ..........................................................................................................................55 7.9.5 Event Occurrence Usages .......................................................................................................................................55 7.10 Items..................................................................................................................................................................................56 7.10.1 Items Overview .....................................................................................................................................................56 7.10.2 Item Definitions and Usages .................................................................................................................................57 7.11 Parts...................................................................................................................................................................................58 7.11.1 Parts Overview ......................................................................................................................................................58 Systems Modeling Language v2.0, Part 1 i -7.11.2 Part Definitions and Usages ..................................................................................................................................60 7.12 Ports ..................................................................................................................................................................................61 7.12.1 Ports Overview......................................................................................................................................................61 7.12.2 Port Definitions and Usages..................................................................................................................................63 7.12.3 Conjugated Port Definitions and Usages ..............................................................................................................63 7.13 Connections.......................................................................................................................................................................63 7.13.1 Connections Overview ..........................................................................................................................................63 7.13.2 Connection Definitions and Usages ......................................................................................................................68 7.13.3 Bindings as Usages ...............................................................................................................................................72 7.13.4 Feature Values.......................................................................................................................................................72 7.13.5 Successions as Usages...........................................................................................................................................73 7.14 Interfaces ...........................................................................................................................................................................74 7.14.1 Interfaces Overview ..............................................................................................................................................74 7.14.2 Interface Definitions and Usages ..........................................................................................................................77 7.15 Allocations ........................................................................................................................................................................78 7.15.1 Allocations Overview............................................................................................................................................78 7.15.2 Allocation Definitions and Usages........................................................................................................................80 7.16 Flows and Messages..........................................................................................................................................................80 7.16.1 Flows and Messages Overview .............................................................................................................................80 7.16.2 Flow Definitions and Usages ................................................................................................................................83 7.17 Actions ..............................................................................................................................................................................85 7.17.1 Actions Overview..................................................................................................................................................85 7.17.2 Action Definitions and Usages..............................................................................................................................99 7.17.3 Control Nodes .....................................................................................................................................................101 7.17.4 Succession Shorthands ........................................................................................................................................102 7.17.5 Conditional Successions......................................................................................................................................103 7.17.6 Perform Action Usages .......................................................................................................................................104 7.17.7 Send Action Usages ............................................................................................................................................105 7.17.8 Accept Action Usages .........................................................................................................................................106 7.17.9 Assignment Action Usages .................................................................................................................................109 7.17.10 Terminate Action Usages ..................................................................................................................................110 7.17.11 If Action Usages................................................................................................................................................111 7.17.12 Loop Action Usages ..........................................................................................................................................111 7.18 States ...............................................................................................................................................................................113 7.18.1 States Overview ..................................................................................................................................................113 7.18.2 State Definitions and Usages ..............................................................................................................................117 7.18.3 Transition Usages................................................................................................................................................119 7.18.4 Exhibit State Usages ...........................................................................................................................................122 7.19 Calculations.....................................................................................................................................................................122 7.19.1 Calculations Overview ........................................................................................................................................122 7.19.2 Calculation Definitions and Usages ....................................................................................................................124 7.20 Constraints ......................................................................................................................................................................125 7.20.1 Constraints Overview..........................................................................................................................................125 7.20.2 Constraint Definitions and Usages......................................................................................................................127 7.20.3 Assert Constraint Usages ....................................................................................................................................128 7.21 Requirements ..................................................................................................................................................................129 7.21.1 Requirements Overview......................................................................................................................................129 7.21.2 Requirement Definition and Usage .....................................................................................................................133 7.21.3 Concern Definitions and Usages .........................................................................................................................135 7.21.4 Satisfy Requirement Usages ...............................................................................................................................136 7.22 Cases ...............................................................................................................................................................................137 7.22.1 Cases Overview...................................................................................................................................................137 7.22.2 Case Definitions and Usages...............................................................................................................................137 7.23 Analysis Cases ................................................................................................................................................................138 7.23.1 Analysis Cases Overview....................................................................................................................................138 7.23.2 Analysis Case Definitions and Usages................................................................................................................140 ii Systems Modeling Language v2.0, Part 1 -7.23.3 Trade-Off Analyses .............................................................................................................................................140 7.24 Verification Cases ...........................................................................................................................................................141 7.24.1 Verification Cases Overview ..............................................................................................................................141 7.24.2 Verification Case Definitions and Usages ..........................................................................................................144 7.25 Use Cases ........................................................................................................................................................................145 7.25.1 Use Cases Overview ...........................................................................................................................................145 7.25.2 Use Case Definitions and Usages .......................................................................................................................147 7.25.3 Include Use Case Usages ....................................................................................................................................148 7.26 Views and Viewpoints ....................................................................................................................................................149 7.26.1 Views and Viewpoints Overview........................................................................................................................149 7.26.2 View Definitions and Usages..............................................................................................................................152 7.26.3 Viewpoint Definitions and Usages......................................................................................................................153 7.26.4 Rendering Definitions and Usages......................................................................................................................154 7.26.5 Compartments and Diagrams as View Usages ...................................................................................................154 7.27 Metadata..........................................................................................................................................................................157 7.27.1 Metadata Overview .............................................................................................................................................157 7.27.2 Metadata Definitions and Usages........................................................................................................................159 7.27.3 Semantic Metadata ..............................................................................................................................................160 7.27.4 User-Defined Keywords......................................................................................................................................161 8 Metamodel ....................................................................................................................................................................................163 8.1 Metamodel Overview........................................................................................................................................................163 8.2 Concrete Syntax ................................................................................................................................................................163 8.2.1 Concrete Syntax Overview ...................................................................................................................................163 8.2.2 Textual Notation....................................................................................................................................................163 8.2.2.1 Textual Notation Overview .......................................................................................................................163 8.2.2.1.1 EBNF Conventions .......................................................................................................................163 8.2.2.1.2 Lexical Structure ...........................................................................................................................165 8.2.2.2 Elements and Relationships Textual Notation ..........................................................................................166 8.2.2.3 Dependencies Textual Notation ................................................................................................................166 8.2.2.4 Annotations Textual Notation ...................................................................................................................166 8.2.2.4.1 Annotations ...................................................................................................................................166 8.2.2.4.2 Comments and Documentation .....................................................................................................166 8.2.2.4.3 Textual Representation..................................................................................................................166 8.2.2.5 Namespaces and Packages Textual Notation ............................................................................................167 8.2.2.5.1 Packages ........................................................................................................................................167 8.2.2.5.2 Package Elements..........................................................................................................................168 8.2.2.6 Definition and Usage Textual Notation ....................................................................................................168 8.2.2.6.1 Definitions .....................................................................................................................................168 8.2.2.6.2 Usages ...........................................................................................................................................169 8.2.2.6.3 Reference Usages ..........................................................................................................................170 8.2.2.6.4 Body Elements ..............................................................................................................................170 8.2.2.6.5 Specialization ................................................................................................................................172 8.2.2.6.6 Multiplicity....................................................................................................................................173 8.2.2.7 Attributes Textual Notation.......................................................................................................................173 8.2.2.8 Enumerations Textual Notation ................................................................................................................173 8.2.2.9 Occurrences Textual Notation...................................................................................................................174 8.2.2.9.1 Occurrence Definitions..................................................................................................................174 8.2.2.9.2 Occurrence Usages ........................................................................................................................174 8.2.2.9.3 Occurrence Successions ................................................................................................................174 8.2.2.10 Items Textual Notation............................................................................................................................175 8.2.2.11 Parts Textual Notation.............................................................................................................................175 8.2.2.12 Ports Textual Notation ............................................................................................................................175 8.2.2.13 Connections Textual Notation.................................................................................................................176 8.2.2.13.1 Connection Definition and Usage ...............................................................................................176 8.2.2.13.2 Binding Connectors .....................................................................................................................176 8.2.2.13.3 Successions..................................................................................................................................176 Systems Modeling Language v2.0, Part 1 iii -8.2.2.14 Interfaces Textual Notation .....................................................................................................................177 8.2.2.14.1 Interface Definitions....................................................................................................................177 8.2.2.14.2 Interface Usages ..........................................................................................................................177 8.2.2.15 Allocations Textual Notation ..................................................................................................................178 8.2.2.16 Flows Textual Notation ...........................................................................................................................178 8.2.2.17 Actions Textual Notation ........................................................................................................................179 8.2.2.17.1 Action Definitions .......................................................................................................................179 8.2.2.17.2 Action Usages..............................................................................................................................180 8.2.2.17.3 Control Nodes..............................................................................................................................181 8.2.2.17.4 Send and Accept Action Usages .................................................................................................181 8.2.2.17.5 Assignment Action Usages .........................................................................................................183 8.2.2.17.6 Terminate Action Usages ............................................................................................................183 8.2.2.17.7 Structured Control Action Usages...............................................................................................183 8.2.2.17.8 Action Successions......................................................................................................................184 8.2.2.18 States Textual Notation ...........................................................................................................................184 8.2.2.18.1 State Definitions ..........................................................................................................................184 8.2.2.18.2 State Usages ................................................................................................................................185 8.2.2.18.3 Transition Usages ........................................................................................................................186 8.2.2.19 Calculations Textual Notation.................................................................................................................187 8.2.2.20 Constraints Textual Notation ..................................................................................................................187 8.2.2.21 Requirements Textual Notation ..............................................................................................................188 8.2.2.21.1 Requirement Definitions .............................................................................................................188 8.2.2.21.2 Requirement Usages....................................................................................................................189 8.2.2.21.3 Concerns ......................................................................................................................................189 8.2.2.22 Cases Textual Notation ...........................................................................................................................189 8.2.2.23 Analysis Cases Textual Notation ............................................................................................................190 8.2.2.24 Verification Cases Textual Notation .......................................................................................................190 8.2.2.25 Use Cases Textual Notation ....................................................................................................................190 8.2.2.26 Views and Viewpoints Textual Notation ................................................................................................190 8.2.2.26.1 View Definitions .........................................................................................................................190 8.2.2.26.2 View Usages................................................................................................................................191 8.2.2.26.3 Viewpoints...................................................................................................................................191 8.2.2.26.4 Renderings...................................................................................................................................191 8.2.2.27 Metadata Textual Notation......................................................................................................................192 8.2.3 Graphical Notation ................................................................................................................................................193 8.2.3.1 Graphical Notation Overview ...................................................................................................................193 8.2.3.2 Elements and Relationships Graphical Notation.......................................................................................194 8.2.3.3 Dependencies Graphical Notation.............................................................................................................195 8.2.3.4 Annotations Graphical Notation................................................................................................................195 8.2.3.5 Namespaces and Packages Graphical Notation ........................................................................................197 8.2.3.6 Definition and Usage Graphical Notation .................................................................................................199 8.2.3.7 Attributes Graphical Notation ...................................................................................................................201 8.2.3.8 Enumerations Graphical Notation .............................................................................................................202 8.2.3.9 Occurrences Graphical Notation ...............................................................................................................203 8.2.3.10 Items Graphical Notation ........................................................................................................................207 8.2.3.11 Parts Graphical Notation .........................................................................................................................208 8.2.3.12 Ports Graphical Notation .........................................................................................................................210 8.2.3.13 Connections Graphical Notation .............................................................................................................214 8.2.3.14 Interfaces Graphical Notation .................................................................................................................217 8.2.3.15 Allocations Graphical Notation...............................................................................................................218 8.2.3.16 Flows Graphical Notation .......................................................................................................................219 8.2.3.17 Actions Graphical Notation.....................................................................................................................222 8.2.3.18 States Graphical Notation........................................................................................................................232 8.2.3.19 Calculations Graphical Notation .............................................................................................................236 8.2.3.20 Constraints Graphical Notation ...............................................................................................................238 8.2.3.21 Requirements Graphical Notation ...........................................................................................................240 iv Systems Modeling Language v2.0, Part 1 -8.2.3.22 Cases Graphical Notation........................................................................................................................246 8.2.3.23 Analysis Cases Graphical Notation.........................................................................................................246 8.2.3.24 Verification Cases Graphical Notation ...................................................................................................248 8.2.3.25 Use Cases Graphical Notation.................................................................................................................249 8.2.3.26 Views and Viewpoints Graphical Notation.............................................................................................251 8.2.3.27 Metadata Graphical Notation ..................................................................................................................255 8.3 Abstract Syntax .................................................................................................................................................................255 8.3.1 Abstract Syntax Overview ....................................................................................................................................255 8.3.2 Elements and Relationships Abstract Syntax........................................................................................................257 8.3.3 Dependencies Abstract Syntax..............................................................................................................................258 8.3.4 Annotations Abstract Syntax.................................................................................................................................258 8.3.5 Namespaces and Packages Abstract Syntax .........................................................................................................259 8.3.6 Definition and Usage Abstract Syntax ..................................................................................................................261 8.3.6.1 Overview ...................................................................................................................................................261 8.3.6.2 Definition ..................................................................................................................................................261 8.3.6.3 ReferenceUsage.........................................................................................................................................268 8.3.6.4 Usage .........................................................................................................................................................269 8.3.6.5 VariantMembership...................................................................................................................................277 8.3.7 Attributes Abstract Syntax ....................................................................................................................................278 8.3.7.1 Overview ...................................................................................................................................................278 8.3.7.2 AttributeDefinition ....................................................................................................................................278 8.3.7.3 AttributeUsage ..........................................................................................................................................279 8.3.8 Enumerations Abstract Syntax ..............................................................................................................................280 8.3.8.1 Overview ...................................................................................................................................................280 8.3.8.2 EnumerationDefinition..............................................................................................................................280 8.3.8.3 EnumerationUsage ....................................................................................................................................281 8.3.9 Occurrences Abstract Syntax ................................................................................................................................281 8.3.9.1 Overview ...................................................................................................................................................281 8.3.9.2 EventOccurrenceUsage .............................................................................................................................282 8.3.9.3 OccurrenceDefinition ................................................................................................................................283 8.3.9.4 OccurrenceUsage ......................................................................................................................................284 8.3.9.5 PortionKind ...............................................................................................................................................286 8.3.10 Items Abstract Syntax .........................................................................................................................................287 8.3.10.1 Overview .................................................................................................................................................287 8.3.10.2 ItemDefinition .........................................................................................................................................287 8.3.10.3 ItemUsage................................................................................................................................................288 8.3.11 Parts Abstract Syntax ..........................................................................................................................................289 8.3.11.1 Overview .................................................................................................................................................289 8.3.11.2 PartDefinition ..........................................................................................................................................289 8.3.11.3 PartUsage ................................................................................................................................................289 8.3.12 Ports Abstract Syntax ..........................................................................................................................................291 8.3.12.1 Overview .................................................................................................................................................291 8.3.12.2 ConjugatedPortDefinition .......................................................................................................................292 8.3.12.3 ConjugatedPortTyping ............................................................................................................................292 8.3.12.4 PortConjugation ......................................................................................................................................293 8.3.12.5 PortDefinition..........................................................................................................................................294 8.3.12.6 PortUsage ................................................................................................................................................295 8.3.13 Connections Abstract Syntax ..............................................................................................................................296 8.3.13.1 Overview .................................................................................................................................................296 8.3.13.2 BindingConnectorAsUsage .....................................................................................................................297 8.3.13.3 ConnectionDefinition ..............................................................................................................................297 8.3.13.4 ConnectionUsage ....................................................................................................................................298 8.3.13.5 ConnectorAsUsage..................................................................................................................................299 8.3.13.6 SuccessionAsUsage.................................................................................................................................299 8.3.14 Interfaces Abstract Syntax ..................................................................................................................................300 8.3.14.1 Overview .................................................................................................................................................300 Systems Modeling Language v2.0, Part 1 v -8.3.14.2 InterfaceDefinition ..................................................................................................................................300 8.3.14.3 InterfaceUsage.........................................................................................................................................301 8.3.15 Allocations Abstract Syntax................................................................................................................................302 8.3.15.1 Overview .................................................................................................................................................302 8.3.15.2 AllocationDefinition................................................................................................................................302 8.3.15.3 AllocationUsage ......................................................................................................................................303 8.3.16 Flow Abstract Syntax .........................................................................................................................................304 8.3.16.1 Overview .................................................................................................................................................304 8.3.16.2 FlowDefinition ........................................................................................................................................304 8.3.16.3 FlowUsage...............................................................................................................................................305 8.3.16.4 SuccessionFlowUsage .............................................................................................................................306 8.3.17 Actions Abstract Syntax......................................................................................................................................306 8.3.17.1 Overview .................................................................................................................................................306 8.3.17.2 AcceptActionUsage.................................................................................................................................309 8.3.17.3 ActionDefinition......................................................................................................................................311 8.3.17.4 ActionUsage ............................................................................................................................................312 8.3.17.5 AssignmentActionUsage .........................................................................................................................314 8.3.17.6 ControlNode ............................................................................................................................................316 8.3.17.7 DecisionNode ..........................................................................................................................................317 8.3.17.8 ForkNode.................................................................................................................................................318 8.3.17.9 ForLoopActionUsage ..............................................................................................................................319 8.3.17.10 IfActionUsage .......................................................................................................................................320 8.3.17.11 JoinNode................................................................................................................................................322 8.3.17.12 LoopActionUsage..................................................................................................................................322 8.3.17.13 MergeNode............................................................................................................................................323 8.3.17.14 PerformActionUsage .............................................................................................................................324 8.3.17.15 SendActionUsage ..................................................................................................................................325 8.3.17.16 TerminateActionUsage..........................................................................................................................326 8.3.17.17 TriggerInvocationExpression ................................................................................................................327 8.3.17.18 TriggerKind...........................................................................................................................................328 8.3.17.19 WhileLoopActionUsage........................................................................................................................329 8.3.18 States Abstract Syntax.........................................................................................................................................331 8.3.18.1 Overview .................................................................................................................................................331 8.3.18.2 ExhibitStateUsage ...................................................................................................................................332 8.3.18.3 StateSubactionKind.................................................................................................................................333 8.3.18.4 StateSubactionMembership.....................................................................................................................334 8.3.18.5 StateDefinition ........................................................................................................................................334 8.3.18.6 StateUsage ...............................................................................................................................................336 8.3.18.7 TransitionFeatureKind ............................................................................................................................339 8.3.18.8 TransitionFeatureMembership ................................................................................................................339 8.3.18.9 TransitionUsage ......................................................................................................................................340 8.3.19 Calculations Abstract Syntax ..............................................................................................................................345 8.3.19.1 Overview .................................................................................................................................................345 8.3.19.2 CalculationDefinition ..............................................................................................................................345 8.3.19.3 CalculationUsage ....................................................................................................................................346 8.3.20 Constraints Abstract Syntax ................................................................................................................................347 8.3.20.1 Overview .................................................................................................................................................347 8.3.20.2 AssertConstraintUsage ............................................................................................................................347 8.3.20.3 ConstraintDefinition................................................................................................................................348 8.3.20.4 ConstraintUsage ......................................................................................................................................349 8.3.21 Requirements Abstract Syntax ............................................................................................................................351 8.3.21.1 Overview .................................................................................................................................................351 8.3.21.2 ActorMembership....................................................................................................................................353 8.3.21.3 ConcernDefinition ...................................................................................................................................353 8.3.21.4 ConcernUsage .........................................................................................................................................354 8.3.21.5 FramedConcernMembership...................................................................................................................355 vi Systems Modeling Language v2.0, Part 1 -8.3.21.6 RequirementConstraintKind....................................................................................................................355 8.3.21.7 RequirementConstraintMembership .......................................................................................................356 8.3.21.8 RequirementDefinition............................................................................................................................357 8.3.21.9 RequirementUsage ..................................................................................................................................359 8.3.21.10 SatisfyRequirementUsage .....................................................................................................................363 8.3.21.11 SubjectMembership...............................................................................................................................364 8.3.21.12 StakeholderMembership........................................................................................................................365 8.3.22 Cases Abstract Syntax.........................................................................................................................................366 8.3.22.1 Overview .................................................................................................................................................366 8.3.22.2 CaseDefinition.........................................................................................................................................367 8.3.22.3 CaseUsage ...............................................................................................................................................368 8.3.22.4 ObjectiveMembership .............................................................................................................................370 8.3.23 Analysis Cases Abstract Syntax..........................................................................................................................371 8.3.23.1 Overview .................................................................................................................................................371 8.3.23.2 AnalysisCaseDefinition...........................................................................................................................371 8.3.23.3 AnalysisCaseUsage .................................................................................................................................372 8.3.24 Verification Cases Abstract Syntax ....................................................................................................................374 8.3.24.1 Overview .................................................................................................................................................374 8.3.24.2 RequirementVerificationMembership.....................................................................................................375 8.3.24.3 VerificationCaseDefinition .....................................................................................................................375 8.3.24.4 VerificationCaseUsage............................................................................................................................376 8.3.25 Use Cases Abstract Syntax..................................................................................................................................378 8.3.25.1 Overview .................................................................................................................................................378 8.3.25.2 IncludeUseCaseUsage .............................................................................................................................378 8.3.25.3 UseCaseDefinition ..................................................................................................................................379 8.3.25.4 UseCaseUsage .........................................................................................................................................380 8.3.26 Views and Viewpoints Abstract Syntax..............................................................................................................381 8.3.26.1 Overview .................................................................................................................................................381 8.3.26.2 Expose .....................................................................................................................................................383 8.3.26.3 MembershipExpose .................................................................................................................................384 8.3.26.4 NamespaceExpose...................................................................................................................................385 8.3.26.5 RenderingDefinition................................................................................................................................385 8.3.26.6 RenderingUsage ......................................................................................................................................386 8.3.26.7 ViewDefinition........................................................................................................................................387 8.3.26.8 ViewpointDefinition................................................................................................................................388 8.3.26.9 ViewpointUsage ......................................................................................................................................389 8.3.26.10 ViewRenderingMembership .................................................................................................................390 8.3.26.11 ViewUsage ............................................................................................................................................391 8.3.27 Metadata Abstract Syntax ...................................................................................................................................393 8.3.27.1 Overview .................................................................................................................................................393 8.3.27.2 MetadataDefinition..................................................................................................................................393 8.3.27.3 MetadataUsage ........................................................................................................................................394 8.4 Semantics ..........................................................................................................................................................................394 8.4.1 Semantics Overview..............................................................................................................................................394 8.4.2 Definition and Usage Semantics ...........................................................................................................................402 8.4.2.1 Definitions .................................................................................................................................................402 8.4.2.2 Usages .......................................................................................................................................................402 8.4.2.3 Variation Definitions and Usages .............................................................................................................403 8.4.3 Attributes Semantics .............................................................................................................................................404 8.4.3.1 Attribute Definitions .................................................................................................................................404 8.4.3.2 Attribute Usages ........................................................................................................................................404 8.4.4 Enumerations Semantics .......................................................................................................................................404 8.4.5 Occurrences Semantics .........................................................................................................................................405 8.4.5.1 Occurrence Definitions .............................................................................................................................405 8.4.5.2 Occurrence Usages ....................................................................................................................................406 8.4.5.3 Event Occurrence Usages..........................................................................................................................407 Systems Modeling Language v2.0, Part 1 vii -8.4.6 Items Semantics ....................................................................................................................................................407 8.4.6.1 Item Definitions.........................................................................................................................................407 8.4.6.2 Item Usages ...............................................................................................................................................408 8.4.7 Parts Semantics .....................................................................................................................................................408 8.4.7.1 Part Definitions .........................................................................................................................................408 8.4.7.2 Part Usages ................................................................................................................................................409 8.4.8 Ports Semantics .....................................................................................................................................................409 8.4.8.1 Port Definitions .........................................................................................................................................409 8.4.8.2 Port Usages................................................................................................................................................410 8.4.9 Connections Semantics .........................................................................................................................................411 8.4.9.1 Connection Definitions .............................................................................................................................411 8.4.9.2 Connection Usages ....................................................................................................................................413 8.4.9.3 Binding Connectors As Usages.................................................................................................................414 8.4.9.4 Successions As Usages..............................................................................................................................414 8.4.10 Interfaces Semantics............................................................................................................................................415 8.4.10.1 Interface Definitions................................................................................................................................415 8.4.10.2 Interface Usages ......................................................................................................................................416 8.4.11 Allocations Semantics .........................................................................................................................................416 8.4.11.1 Allocation Definitions .............................................................................................................................416 8.4.11.2 Allocation Usages ...................................................................................................................................417 8.4.12 Flows Semantics .................................................................................................................................................417 8.4.12.1 Flow Definitions......................................................................................................................................417 8.4.12.2 Flow Usages ............................................................................................................................................418 8.4.12.3 Succession Flow Usages .........................................................................................................................420 8.4.13 Actions Semantics ...............................................................................................................................................420 8.4.13.1 Action Definitions ...................................................................................................................................420 8.4.13.2 Action Usages .........................................................................................................................................421 8.4.13.3 Decision Transition Usages.....................................................................................................................423 8.4.13.4 Control Nodes .........................................................................................................................................424 8.4.13.5 Send Action Usages ................................................................................................................................428 8.4.13.6 Accept Action Usages .............................................................................................................................430 8.4.13.7 Assignment Action Usages .....................................................................................................................432 8.4.13.8 Terminate Action Usages ........................................................................................................................433 8.4.13.9 If Action Usages......................................................................................................................................434 8.4.13.10 Loop Action Usages ..............................................................................................................................435 8.4.13.11 Perform Action Usages .........................................................................................................................437 8.4.14 States Semantics..................................................................................................................................................438 8.4.14.1 State Definitions ......................................................................................................................................438 8.4.14.2 State Usages ............................................................................................................................................439 8.4.14.3 Transition Usages ....................................................................................................................................440 8.4.14.4 Exhibit State Usages................................................................................................................................442 8.4.15 Calculations Semantics .......................................................................................................................................443 8.4.15.1 Calculation Definitions ...........................................................................................................................443 8.4.15.2 Calculation Usages ..................................................................................................................................444 8.4.16 Constraints Semantics .........................................................................................................................................445 8.4.16.1 Constraint Definitions .............................................................................................................................445 8.4.16.2 Constraint Usages....................................................................................................................................446 8.4.16.3 Assert Constraint Usages ........................................................................................................................446 8.4.17 Requirements Semantics .....................................................................................................................................447 8.4.17.1 Requirement Definitions .........................................................................................................................447 8.4.17.2 Requirement Usages................................................................................................................................448 8.4.17.3 Satisfy Requirement Usages....................................................................................................................449 8.4.17.4 Concern Definitions ................................................................................................................................450 8.4.17.5 Concern Usages.......................................................................................................................................450 8.4.18 Cases Semantics ..................................................................................................................................................450 8.4.18.1 Case Definitions ......................................................................................................................................450 viii Systems Modeling Language v2.0, Part 1 -8.4.18.2 Case Usages.............................................................................................................................................451 8.4.19 Analysis Cases Semantics ...................................................................................................................................452 8.4.19.1 Analysis Case Definitions .......................................................................................................................452 8.4.19.2 Analysis Case Usages..............................................................................................................................453 8.4.20 Verification Cases Semantics..............................................................................................................................454 8.4.20.1 Verification Case Definitions..................................................................................................................454 8.4.20.2 Verification Case Usages ........................................................................................................................455 8.4.21 Use Cases Semantics...........................................................................................................................................455 8.4.21.1 Use Case Definitions ...............................................................................................................................456 8.4.21.2 Use Case Usages .....................................................................................................................................456 8.4.21.3 Include Use Case Usages ........................................................................................................................456 8.4.22 Views and Viewpoints Semantics .......................................................................................................................457 8.4.22.1 View Definitions .....................................................................................................................................457 8.4.22.2 View Usages............................................................................................................................................457 8.4.22.3 Viewpoint Definitions .............................................................................................................................457 8.4.22.4 Viewpoint Usages ...................................................................................................................................458 8.4.22.5 Rendering Definitions .............................................................................................................................458 8.4.22.6 Rendering Usages....................................................................................................................................458 8.4.23 Metadata Semantics ............................................................................................................................................459 8.4.23.1 Metadata Definitions ...............................................................................................................................459 8.4.23.2 Metadata Usages .....................................................................................................................................459 9 Model Libraries.............................................................................................................................................................................461 9.1 Model Libraries Overview ................................................................................................................................................461 9.2 Systems Model Library.....................................................................................................................................................461 9.2.1 Systems Model Library Overview ........................................................................................................................461 9.2.2 Attributes...............................................................................................................................................................462 9.2.2.1 Attributes Overview ..................................................................................................................................462 9.2.2.2 Elements ....................................................................................................................................................462 9.2.2.2.1 AttributeValue ...............................................................................................................................462 9.2.2.2.2 attributeValues...............................................................................................................................462 9.2.3 Items ......................................................................................................................................................................463 9.2.3.1 Items Overview .........................................................................................................................................463 9.2.3.2 Elements ....................................................................................................................................................463 9.2.3.2.1 Item................................................................................................................................................463 9.2.3.2.2 items ..............................................................................................................................................464 9.2.3.2.3 Touches .........................................................................................................................................464 9.2.4 Parts.......................................................................................................................................................................465 9.2.4.1 Parts Overview ..........................................................................................................................................465 9.2.4.2 Elements ....................................................................................................................................................465 9.2.4.2.1 Part.................................................................................................................................................465 9.2.4.2.2 parts ...............................................................................................................................................466 9.2.5 Ports ......................................................................................................................................................................466 9.2.5.1 Ports Overview ..........................................................................................................................................466 9.2.5.2 Elements ....................................................................................................................................................466 9.2.5.2.1 Port ................................................................................................................................................466 9.2.5.2.2 ports ...............................................................................................................................................467 9.2.6 Connections...........................................................................................................................................................467 9.2.6.1 Connections Overview ..............................................................................................................................467 9.2.6.2 Elements ....................................................................................................................................................467 9.2.6.2.1 BinaryConnection..........................................................................................................................467 9.2.6.2.2 binaryConnections.........................................................................................................................468 9.2.6.2.3 Connection.....................................................................................................................................468 9.2.6.2.4 connections ....................................................................................................................................468 9.2.7 Interfaces ...............................................................................................................................................................469 9.2.7.1 Interfaces Overview ..................................................................................................................................469 Systems Modeling Language v2.0, Part 1 ix -9.2.7.2 Elements ....................................................................................................................................................469 9.2.7.2.1 BinaryInterface ..............................................................................................................................469 9.2.7.2.2 binaryInterfaces .............................................................................................................................470 9.2.7.2.3 Interface.........................................................................................................................................470 9.2.7.2.4 interfaces .......................................................................................................................................470 9.2.8 Allocations ............................................................................................................................................................471 9.2.8.1 Allocations Overview................................................................................................................................471 9.2.8.2 Elements ....................................................................................................................................................471 9.2.8.2.1 Allocation ......................................................................................................................................471 9.2.8.2.2 allocations......................................................................................................................................471 9.2.9 Flows .....................................................................................................................................................................472 9.2.9.1 Flows Overview ........................................................................................................................................472 9.2.9.2 Elements ....................................................................................................................................................472 9.2.9.2.1 Flow...............................................................................................................................................472 9.2.9.2.2 flows ..............................................................................................................................................472 9.2.9.2.3 Message .........................................................................................................................................473 9.2.9.2.4 MessageAction ..............................................................................................................................474 9.2.9.2.5 messages ........................................................................................................................................474 9.2.9.2.6 SuccessionFlow .............................................................................................................................475 9.2.9.2.7 successionFlows ............................................................................................................................475 9.2.10 Actions ................................................................................................................................................................476 9.2.10.1 Actions Overview....................................................................................................................................476 9.2.10.2 Elements ..................................................................................................................................................476 9.2.10.2.1 AcceptAction...............................................................................................................................476 9.2.10.2.2 acceptActions ..............................................................................................................................476 9.2.10.2.3 AcceptMessageAction.................................................................................................................477 9.2.10.2.4 Action ..........................................................................................................................................477 9.2.10.2.5 actions..........................................................................................................................................479 9.2.10.2.6 AssignmentAction .......................................................................................................................479 9.2.10.2.7 assignmentActions.......................................................................................................................480 9.2.10.2.8 ControlAction ..............................................................................................................................480 9.2.10.2.9 DecisionAction ............................................................................................................................481 9.2.10.2.10 DecisionTransitionAction .........................................................................................................481 9.2.10.2.11 ForkAction.................................................................................................................................482 9.2.10.2.12 ForLoopAction ..........................................................................................................................482 9.2.10.2.13 forLoopActions .........................................................................................................................483 9.2.10.2.14 IfThenAction .............................................................................................................................483 9.2.10.2.15 ifThenActions ............................................................................................................................484 9.2.10.2.16 IfThenElseAction ......................................................................................................................484 9.2.10.2.17 ifThenElseActions .....................................................................................................................485 9.2.10.2.18 JoinAction .................................................................................................................................485 9.2.10.2.19 LoopAction................................................................................................................................486 9.2.10.2.20 loopActions ...............................................................................................................................486 9.2.10.2.21 MergeAction..............................................................................................................................486 9.2.10.2.22 SendAction ................................................................................................................................487 9.2.10.2.23 sendActions ...............................................................................................................................487 9.2.10.2.24 TerminateAction........................................................................................................................488 9.2.10.2.25 terminateActions .......................................................................................................................488 9.2.10.2.26 TransitionAction........................................................................................................................489 9.2.10.2.27 transitionActions .......................................................................................................................489 9.2.10.2.28 WhileLoopAction ......................................................................................................................490 9.2.10.2.29 whileLoopActions .....................................................................................................................490 9.2.11 States ...................................................................................................................................................................491 9.2.11.1 States Overview.......................................................................................................................................491 9.2.11.2 Elements ..................................................................................................................................................491 9.2.11.2.1 StateAction ..................................................................................................................................491 x Systems Modeling Language v2.0, Part 1 -9.2.11.2.2 stateActions .................................................................................................................................492 9.2.11.2.3 StateTransitionAction..................................................................................................................492 9.2.12 Calculations.........................................................................................................................................................493 9.2.12.1 Calculations Overview ............................................................................................................................493 9.2.12.2 Elements ..................................................................................................................................................493 9.2.12.2.1 Calculation...................................................................................................................................493 9.2.12.2.2 calculations ..................................................................................................................................493 9.2.13 Constraints ..........................................................................................................................................................494 9.2.13.1 Constraints Overview ..............................................................................................................................494 9.2.13.2 Elements ..................................................................................................................................................494 9.2.13.2.1 assertedConstraintChecks............................................................................................................494 9.2.13.2.2 ConstraintCheck ..........................................................................................................................494 9.2.13.2.3 constraintChecks .........................................................................................................................495 9.2.13.2.4 negatedConstraintChecks ............................................................................................................495 9.2.14 Requirements.......................................................................................................................................................496 9.2.14.1 Requirements Overview ..........................................................................................................................496 9.2.14.2 Elements ..................................................................................................................................................496 9.2.14.2.1 ConcernCheck .............................................................................................................................496 9.2.14.2.2 concernChecks.............................................................................................................................496 9.2.14.2.3 DesignConstraintCheck...............................................................................................................497 9.2.14.2.4 FunctionalRequirementCheck .....................................................................................................497 9.2.14.2.5 InterfaceRequirementCheck........................................................................................................497 9.2.14.2.6 PerformanceRequirementCheck..................................................................................................498 9.2.14.2.7 PhysicalRequirementCheck.........................................................................................................498 9.2.14.2.8 RequirementCheck ......................................................................................................................499 9.2.14.2.9 requirementChecks ......................................................................................................................499 9.2.15 Cases ...................................................................................................................................................................500 9.2.15.1 Cases Overview.......................................................................................................................................500 9.2.15.2 Elements ..................................................................................................................................................500 9.2.15.2.1 Case .............................................................................................................................................500 9.2.15.2.2 cases.............................................................................................................................................501 9.2.16 Analysis Cases ....................................................................................................................................................501 9.2.16.1 Analysis Cases Overview........................................................................................................................501 9.2.16.2 Elements ..................................................................................................................................................501 9.2.16.2.1 AnalysisCase ...............................................................................................................................501 9.2.16.2.2 analysisCases...............................................................................................................................502 9.2.17 Verification Cases ...............................................................................................................................................502 9.2.17.1 Verification Cases Overview ..................................................................................................................502 9.2.17.2 Elements ..................................................................................................................................................502 9.2.17.2.1 PassIf ...........................................................................................................................................502 9.2.17.2.2 VerdictKind .................................................................................................................................503 9.2.17.2.3 VerificationCase ..........................................................................................................................503 9.2.17.2.4 verificationCases .........................................................................................................................504 9.2.17.2.5 VerificationCheck .......................................................................................................................504 9.2.17.2.6 VerificationMethod .....................................................................................................................505 9.2.17.2.7 VerificationMethodKind .............................................................................................................505 9.2.18 Use Cases ............................................................................................................................................................506 9.2.18.1 Use Cases Overview................................................................................................................................506 9.2.18.2 Elements ..................................................................................................................................................506 9.2.18.2.1 UseCase .......................................................................................................................................506 9.2.18.2.2 useCases ......................................................................................................................................506 9.2.19 Views...................................................................................................................................................................507 9.2.19.1 Views Overview ......................................................................................................................................507 9.2.19.2 Elements ..................................................................................................................................................507 9.2.19.2.1 asElementTable ...........................................................................................................................507 9.2.19.2.2 asInterconnectionDiagram...........................................................................................................507 Systems Modeling Language v2.0, Part 1 xi -9.2.19.2.3 asTextualNotation .......................................................................................................................508 9.2.19.2.4 asTreeDiagram ............................................................................................................................508 9.2.19.2.5 GraphicalRendering.....................................................................................................................509 9.2.19.2.6 Rendering ....................................................................................................................................509 9.2.19.2.7 renderings ....................................................................................................................................509 9.2.19.2.8 TabularRendering........................................................................................................................510 9.2.19.2.9 TextualRendering ........................................................................................................................510 9.2.19.2.10 View ..........................................................................................................................................511 9.2.19.2.11 ViewpointCheck........................................................................................................................511 9.2.19.2.12 viewpointChecks .......................................................................................................................512 9.2.19.2.13 viewpointConformance .............................................................................................................512 9.2.19.2.14 views..........................................................................................................................................513 9.2.20 Standard View Definitions ..................................................................................................................................513 9.2.20.1 Standard View Definitions Overview .....................................................................................................513 9.2.20.2 Elements ..................................................................................................................................................514 9.2.20.2.1 ActionFlowView .........................................................................................................................514 9.2.20.2.2 BrowserView...............................................................................................................................515 9.2.20.2.3 GeneralView................................................................................................................................515 9.2.20.2.4 GeometryView ............................................................................................................................516 9.2.20.2.5 GridView .....................................................................................................................................516 9.2.20.2.6 InterconnectionView ...................................................................................................................517 9.2.20.2.7 SequenceView .............................................................................................................................517 9.2.20.2.8 StateTransitionView ....................................................................................................................518 9.2.21 Metadata ..............................................................................................................................................................519 9.2.21.1 Metadata Overview .................................................................................................................................519 9.2.21.2 Elements ..................................................................................................................................................519 9.2.21.2.1 MetadataItem...............................................................................................................................519 9.2.21.2.2 metadataItems..............................................................................................................................519 9.2.22 SysML .................................................................................................................................................................520 9.3 Metadata Domain Library.................................................................................................................................................520 9.3.1 Metadata Domain Library Overview ....................................................................................................................520 9.3.2 Modeling Metadata ...............................................................................................................................................521 9.3.2.1 Modeling Metadata Overview...................................................................................................................521 9.3.2.2 Elements ....................................................................................................................................................521 9.3.2.2.1 Issue...............................................................................................................................................521 9.3.2.2.2 Rationale........................................................................................................................................521 9.3.2.2.3 Refinement ....................................................................................................................................522 9.3.2.2.4 StatusInfo.......................................................................................................................................522 9.3.2.2.5 StatusKind .....................................................................................................................................523 9.3.3 Risk Metadata........................................................................................................................................................523 9.3.3.1 Risk Metadata Overview ...........................................................................................................................523 9.3.3.2 Elements ....................................................................................................................................................524 9.3.3.2.1 Level..............................................................................................................................................524 9.3.3.2.2 LevelEnum ....................................................................................................................................524 9.3.3.2.3 Risk................................................................................................................................................525 9.3.3.2.4 RiskLevel.......................................................................................................................................525 9.3.3.2.5 RiskLevelEnum .............................................................................................................................526 9.3.4 Parameters of Interest Metadata ............................................................................................................................526 9.3.4.1 Parameters of Interest Metadata Overview ...............................................................................................526 9.3.4.2 Elements ....................................................................................................................................................526 9.3.4.2.1 MeasureOfEffectiveness ...............................................................................................................526 9.3.4.2.2 MeasureOfPerformance.................................................................................................................527 9.3.4.2.3 measuresOfEffectiveness ..............................................................................................................527 9.3.4.2.4 measuresOfPerformance ...............................................................................................................528 9.3.5 Image Metadata .....................................................................................................................................................528 9.3.5.1 Image Metadata Overview ........................................................................................................................528 xii Systems Modeling Language v2.0, Part 1 -9.3.5.2 Elements ....................................................................................................................................................528 9.3.5.2.1 Icon ................................................................................................................................................528 9.3.5.2.2 Image .............................................................................................................................................529 9.4 Analysis Domain Library..................................................................................................................................................530 9.4.1 Analysis Domain Library Overview .....................................................................................................................530 9.4.2 Analysis Tooling ...................................................................................................................................................530 9.4.2.1 Analysis Tooling Overview ......................................................................................................................530 9.4.2.2 Elements ....................................................................................................................................................530 9.4.2.2.1 ToolExecution ...............................................................................................................................530 9.4.2.2.2 ToolVariable..................................................................................................................................530 9.4.3 Sampled Functions ................................................................................................................................................531 9.4.3.1 Sampled Functions Overview ...................................................................................................................531 9.4.3.2 Elements ....................................................................................................................................................531 9.4.3.2.1 Domain ..........................................................................................................................................531 9.4.3.2.2 Interpolate......................................................................................................................................532 9.4.3.2.3 interpolateLinear ...........................................................................................................................532 9.4.3.2.4 Range.............................................................................................................................................533 9.4.3.2.5 Sample ...........................................................................................................................................533 9.4.3.2.6 SampledFunction...........................................................................................................................534 9.4.3.2.7 SamplePair.....................................................................................................................................534 9.4.4 State Space Representation ...................................................................................................................................535 9.4.4.1 State Space Representation Overview.......................................................................................................535 9.4.4.2 Elements ....................................................................................................................................................535 9.4.5 Trade Studies.........................................................................................................................................................536 9.4.5.1 Trade Studies Overview ............................................................................................................................536 9.4.5.2 Elements ....................................................................................................................................................536 9.4.5.2.1 EvaluationFunction .......................................................................................................................536 9.4.5.2.2 MaximizeObjective .......................................................................................................................537 9.4.5.2.3 MinimizeObjective ........................................................................................................................537 9.4.5.2.4 TradeStudy ....................................................................................................................................538 9.4.5.2.5 TradeStudyObjective.....................................................................................................................539 9.5 Cause and Effect Domain Library ....................................................................................................................................540 9.5.1 Cause and Effect Domain Library Overview........................................................................................................540 9.5.2 Causation Connections..........................................................................................................................................540 9.5.2.1 Causation Connections Overview .............................................................................................................540 9.5.2.2 Elements ....................................................................................................................................................540 9.5.2.2.1 Causation .......................................................................................................................................540 9.5.2.2.2 causations ......................................................................................................................................541 9.5.2.2.3 causes.............................................................................................................................................541 9.5.2.2.4 effects ............................................................................................................................................541 9.5.2.2.5 Multicausation ...............................................................................................................................542 9.5.2.2.6 multicausations ..............................................................................................................................543 9.5.3 Cause and Effect ...................................................................................................................................................543 9.5.3.1 Cause and Effect Overview.......................................................................................................................543 9.5.3.2 Elements ....................................................................................................................................................543 9.5.3.2.1 CausationMetadata ........................................................................................................................543 9.5.3.2.2 CausationSemanticMetadata .........................................................................................................544 9.5.3.2.3 CauseMetadata ..............................................................................................................................544 9.5.3.2.4 EffectMetadata ..............................................................................................................................545 9.5.3.2.5 MulticausationSemanticMetadata .................................................................................................545 9.6 Requirement Derivation Domain Library .........................................................................................................................546 9.6.1 Requirement Derivation Domain Library Overview ............................................................................................546 9.6.2 Derivation Connections.........................................................................................................................................546 9.6.2.1 Derivation Connections Overview ............................................................................................................546 9.6.2.2 Elements ....................................................................................................................................................546 9.6.2.2.1 Derivation ......................................................................................................................................546 Systems Modeling Language v2.0, Part 1 xiii -9.6.2.2.2 derivations .....................................................................................................................................547 9.6.2.2.3 derivedRequirements.....................................................................................................................547 9.6.2.2.4 originalRequirements ....................................................................................................................548 9.6.3 Requirement Derivation ........................................................................................................................................548 9.6.3.1 Requirement Derivation Overview ...........................................................................................................548 9.6.3.2 Elements ....................................................................................................................................................548 9.6.3.2.1 DerivationMetadata .......................................................................................................................548 9.6.3.2.2 DerivedRequirementMetadata.......................................................................................................549 9.6.3.2.3 OriginalRequirementMetadata ......................................................................................................549 9.7 Geometry Domain Library................................................................................................................................................550 9.7.1 Geometry Domain Library Overview ...................................................................................................................550 9.7.2 Spatial Items..........................................................................................................................................................550 9.7.2.1 Spatial Items Overview .............................................................................................................................550 9.7.2.2 Elements ....................................................................................................................................................550 9.7.2.2.1 CurrentDisplacementOf.................................................................................................................550 9.7.2.2.2 CurrentPositionOf .........................................................................................................................551 9.7.2.2.3 DisplacementOf.............................................................................................................................551 9.7.2.2.4 PositionOf......................................................................................................................................552 9.7.2.2.5 SpatialItem.....................................................................................................................................553 9.7.3 Shape Items ...........................................................................................................................................................554 9.7.3.1 Shape Items Overview ..............................................................................................................................554 9.7.3.2 Elements ....................................................................................................................................................554 9.7.3.2.1 Circle .............................................................................................................................................554 9.7.3.2.2 CircularCone .................................................................................................................................554 9.7.3.2.3 CircularCylinder ............................................................................................................................555 9.7.3.2.4 CircularDisc...................................................................................................................................555 9.7.3.2.5 Cone...............................................................................................................................................556 9.7.3.2.6 ConeOrCylinder ............................................................................................................................556 9.7.3.2.7 ConicSection .................................................................................................................................557 9.7.3.2.8 ConicSurface .................................................................................................................................558 9.7.3.2.9 Cuboid ...........................................................................................................................................558 9.7.3.2.10 CuboidOrTriangularPrism...........................................................................................................559 9.7.3.2.11 Cylinder .......................................................................................................................................560 9.7.3.2.12 Disc..............................................................................................................................................560 9.7.3.2.13 EccentricCone .............................................................................................................................561 9.7.3.2.14 EccentricCylinder ........................................................................................................................561 9.7.3.2.15 Ellipse ..........................................................................................................................................562 9.7.3.2.16 Ellipsoid ......................................................................................................................................562 9.7.3.2.17 Hyperbola ....................................................................................................................................563 9.7.3.2.18 Hyperboloid.................................................................................................................................563 9.7.3.2.19 Line..............................................................................................................................................564 9.7.3.2.20 Parabola .......................................................................................................................................564 9.7.3.2.21 Paraboloid....................................................................................................................................564 9.7.3.2.22 Path..............................................................................................................................................565 9.7.3.2.23 PlanarCurve .................................................................................................................................565 9.7.3.2.24 PlanarSurface...............................................................................................................................566 9.7.3.2.25 Polygon........................................................................................................................................566 9.7.3.2.26 Polyhedron...................................................................................................................................567 9.7.3.2.27 Pyramid .......................................................................................................................................567 9.7.3.2.28 Quadrilateral................................................................................................................................568 9.7.3.2.29 Rectangle .....................................................................................................................................569 9.7.3.2.30 RectangularCuboid......................................................................................................................569 9.7.3.2.31 RectangularPyramid ....................................................................................................................570 9.7.3.2.32 RectangularToroid.......................................................................................................................570 9.7.3.2.33 RightCircularCone.......................................................................................................................571 9.7.3.2.34 RightCircularCylinder .................................................................................................................571 xiv Systems Modeling Language v2.0, Part 1 -9.7.3.2.35 RightTriangle...............................................................................................................................571 9.7.3.2.36 RightTriangularPrism ..................................................................................................................572 9.7.3.2.37 Shell.............................................................................................................................................573 9.7.3.2.38 Sphere ..........................................................................................................................................573 9.7.3.2.39 Tetrahedron .................................................................................................................................573 9.7.3.2.40 Toriod ..........................................................................................................................................574 9.7.3.2.41 Torus............................................................................................................................................574 9.7.3.2.42 Triangle .......................................................................................................................................575 9.7.3.2.43 TriangularPrism...........................................................................................................................576 9.8 Quantities and Units Domain Library...............................................................................................................................576 9.8.1 Quantities and Units Domain Library Overview ..................................................................................................576 9.8.2 Quantities ..............................................................................................................................................................577 9.8.2.1 Quantities Overview..................................................................................................................................577 9.8.2.2 Elements ....................................................................................................................................................578 9.8.2.2.1 3dVectorQuantityValue.................................................................................................................578 9.8.2.2.2 QuantityDimension .......................................................................................................................578 9.8.2.2.3 QuantityPowerFactor.....................................................................................................................579 9.8.2.2.4 scalarQuantities .............................................................................................................................579 9.8.2.2.5 ScalarQuantityValue .....................................................................................................................580 9.8.2.2.6 SystemOfQuantities.......................................................................................................................580 9.8.2.2.7 tensorQuantities.............................................................................................................................581 9.8.2.2.8 TensorQuantityValue ....................................................................................................................581 9.8.2.2.9 vectorQuantities.............................................................................................................................583 9.8.2.2.10 VectorQuantityValue...................................................................................................................583 9.8.3 Measurement References ......................................................................................................................................584 9.8.3.1 Measurement References Overview..........................................................................................................584 9.8.3.2 Elements ....................................................................................................................................................584 9.8.3.2.1 3dCoordinateFrame .......................................................................................................................584 9.8.3.2.2 AffineTransformationMatrix3d.....................................................................................................584 9.8.3.2.3 ConversionByConvention .............................................................................................................585 9.8.3.2.4 ConversionByPrefix ......................................................................................................................586 9.8.3.2.5 CoordinateFrame ...........................................................................................................................587 9.8.3.2.6 CoordinateFramePlacement ..........................................................................................................587 9.8.3.2.7 CoordinateTransformation ............................................................................................................588 9.8.3.2.8 countQuantities..............................................................................................................................588 9.8.3.2.9 CountValue....................................................................................................................................589 9.8.3.2.10 CyclicRatioScale .........................................................................................................................589 9.8.3.2.11 DefinitionalQuantityValue ..........................................................................................................590 9.8.3.2.12 DerivedUnit .................................................................................................................................590 9.8.3.2.13 dimensionOneQuantities .............................................................................................................591 9.8.3.2.14 DimensionOneUnit......................................................................................................................591 9.8.3.2.15 DimensionOneValue ...................................................................................................................591 9.8.3.2.16 IntervalScale ................................................................................................................................592 9.8.3.2.17 LogarithmicScale.........................................................................................................................592 9.8.3.2.18 MeasurementScale.......................................................................................................................593 9.8.3.2.19 MeasurementUnit ........................................................................................................................594 9.8.3.2.20 NullTransformation .....................................................................................................................594 9.8.3.2.21 nullTransformation ......................................................................................................................595 9.8.3.2.22 one ...............................................................................................................................................595 9.8.3.2.23 OrdinalScale ................................................................................................................................596 9.8.3.2.24 QuantityValueMapping ...............................................................................................................596 9.8.3.2.25 Rotation .......................................................................................................................................597 9.8.3.2.26 ScalarMeasurementReference .....................................................................................................597 9.8.3.2.27 SimpleUnit ..................................................................................................................................598 9.8.3.2.28 SystemOfUnits ............................................................................................................................599 9.8.3.2.29 TensorMeasurementReference ....................................................................................................599 Systems Modeling Language v2.0, Part 1 xv -9.8.3.2.30 Translation...................................................................................................................................600 9.8.3.2.31 TranslationOrRotation.................................................................................................................601 9.8.3.2.32 TranslationRotationSequence......................................................................................................601 9.8.3.2.33 UnitConversion ...........................................................................................................................602 9.8.3.2.34 UnitPowerFactor .........................................................................................................................602 9.8.3.2.35 UnitPrefix ....................................................................................................................................603 9.8.3.2.36 VectorMeasurementReference ....................................................................................................603 9.8.4 ISQ ........................................................................................................................................................................604 9.8.4.1 ISQ Overview............................................................................................................................................604 9.8.4.2 Elements ....................................................................................................................................................605 9.8.4.2.1 amountOfSubstance.......................................................................................................................605 9.8.4.2.2 AmountOfSubstanceUnit ..............................................................................................................605 9.8.4.2.3 AmountOfSubstanceValue ............................................................................................................605 9.8.4.2.4 AngularMeasureValue...................................................................................................................606 9.8.4.2.5 Cartesian3dSpatialCoordinateFrame .............................................................................................606 9.8.4.2.6 Displacement3dVector ..................................................................................................................607 9.8.4.2.7 duration..........................................................................................................................................607 9.8.4.2.8 DurationUnit..................................................................................................................................607 9.8.4.2.9 DurationValue ...............................................................................................................................608 9.8.4.2.10 electricCurrent .............................................................................................................................608 9.8.4.2.11 ElectricCurrentUnit .....................................................................................................................608 9.8.4.2.12 ElectricCurrentValue...................................................................................................................609 9.8.4.2.13 length ...........................................................................................................................................609 9.8.4.2.14 LengthUnit...................................................................................................................................610 9.8.4.2.15 LengthValue ................................................................................................................................610 9.8.4.2.16 luminousIntensity ........................................................................................................................610 9.8.4.2.17 LuminousIntensityUnit................................................................................................................611 9.8.4.2.18 LuminousIntensityValue .............................................................................................................611 9.8.4.2.19 mass .............................................................................................................................................611 9.8.4.2.20 MassUnit .....................................................................................................................................612 9.8.4.2.21 MassValue ...................................................................................................................................612 9.8.4.2.22 Position3dVector .........................................................................................................................612 9.8.4.2.23 Spatial3dCoordinateFrame ..........................................................................................................613 9.8.4.2.24 thermodynamicTemperature .......................................................................................................613 9.8.4.2.25 ThermodynamicTemperatureUnit ...............................................................................................614 9.8.4.2.26 ThermodynamicTemperatureValue.............................................................................................614 9.8.4.2.27 universalCartesianSpatial3dCoordinateFrame ............................................................................614 9.8.5 SI Prefixes .............................................................................................................................................................615 9.8.5.1 SI Prefixes Overview ................................................................................................................................615 9.8.5.2 Elements ....................................................................................................................................................616 9.8.6 SI ...........................................................................................................................................................................616 9.8.6.1 SI Overview...............................................................................................................................................616 9.8.6.2 Elements ....................................................................................................................................................616 9.8.7 US Customary Units .............................................................................................................................................616 9.8.7.1 US Customary Units Overview.................................................................................................................616 9.8.7.2 Elements ....................................................................................................................................................617 9.8.8 Time ......................................................................................................................................................................617 9.8.8.1 Time Overview..........................................................................................................................................617 9.8.8.2 Elements ....................................................................................................................................................617 9.8.8.2.1 Clock .............................................................................................................................................617 9.8.8.2.2 Date ...............................................................................................................................................617 9.8.8.2.3 DateTime .......................................................................................................................................618 9.8.8.2.4 DurationOf.....................................................................................................................................618 9.8.8.2.5 Iso8601DateTime ..........................................................................................................................618 9.8.8.2.6 Iso8601DateTimeEncoding...........................................................................................................619 9.8.8.2.7 Iso8601DateTimeStructure ...........................................................................................................619 xvi Systems Modeling Language v2.0, Part 1 -9.8.8.2.8 timeInstant .....................................................................................................................................620 9.8.8.2.9 TimeInstantValue ..........................................................................................................................620 9.8.8.2.10 TimeOf ........................................................................................................................................621 9.8.8.2.11 TimeOfDay..................................................................................................................................622 9.8.8.2.12 TimeScale ....................................................................................................................................622 9.8.8.2.13 universalClock.............................................................................................................................622 9.8.8.2.14 UTC .............................................................................................................................................623 9.8.8.2.15 utcTimeInstant.............................................................................................................................623 9.8.8.2.16 UtcTimeInstantValue ..................................................................................................................624 9.8.9 Quantity Calculations............................................................................................................................................624 9.8.9.1 Quantity Calculations Overview ...............................................................................................................624 9.8.9.2 Elements ....................................................................................................................................................628 9.8.10 Vector Calculations .............................................................................................................................................628 9.8.10.1 Vector Calculations Overview ................................................................................................................628 9.8.10.2 Elements ..................................................................................................................................................631 9.8.11 Tensor Calculations.............................................................................................................................................631 9.8.11.1 Tensor Calculations Overview ................................................................................................................631 9.8.11.2 Elements ..................................................................................................................................................633 9.8.12 Measurement Ref Calculations ...........................................................................................................................633 9.8.12.1 Measurement Ref Calculations Overview...............................................................................................633 9.8.12.2 Elements ..................................................................................................................................................634 A Annex: Example Model ...............................................................................................................................................................635 A.1 Introduction ......................................................................................................................................................................635 A.2 Model Organization .........................................................................................................................................................635 A.3 Definitions........................................................................................................................................................................636 A.4 Parts..................................................................................................................................................................................640 A.5 Parts Interconnection........................................................................................................................................................642 A.6 Actions .............................................................................................................................................................................645 A.7 States ................................................................................................................................................................................647 A.8 Requirements....................................................................................................................................................................650 A.9 Analysis............................................................................................................................................................................652 A.10 Verification ....................................................................................................................................................................653 A.11 View and Viewpoint ......................................................................................................................................................655 A.12 Variability ......................................................................................................................................................................656 A.13 Individuals......................................................................................................................................................................657 Systems Modeling Language v2.0, Part 1 xvii -List of Tables 1. Dependencies – Representative Notation ......................................................................................................................................19 2. Annotations – Representative Notation .........................................................................................................................................20 3. Packages – Representative Notation ..............................................................................................................................................24 4. Definition and Usage – Representative Notation...........................................................................................................................34 5. Attributes – Representative Notation.............................................................................................................................................45 6. Enumerations – Representative Notation.......................................................................................................................................47 7. Occurrences – Representative Notation.........................................................................................................................................51 8. Items – Representative Notation ....................................................................................................................................................56 9. Parts – Representative Notation.....................................................................................................................................................58 10. Ports – Representative Notation...................................................................................................................................................61 11. Connections – Representative Notation.......................................................................................................................................65 12. Interfaces – Representative Notation ...........................................................................................................................................74 13. Allocations – Representative Notation ........................................................................................................................................79 14. Flows and Messages – Representative Notation..........................................................................................................................81 15. Actions – Representative Notation ..............................................................................................................................................87 16. Control Node Definitions...........................................................................................................................................................101 17. States – Representative Notation ...............................................................................................................................................114 18. Calculations – Representative Notation.....................................................................................................................................123 19. Constraints – Representative Notation.......................................................................................................................................126 20. Requirements – Representative Notation...................................................................................................................................130 21. Analysis Cases – Representative Notation ................................................................................................................................138 22. Verification Cases – Representative Notations..........................................................................................................................142 23. Use Cases – Representative Notation ........................................................................................................................................145 24. Views and Viewpoints – Representative Notation ....................................................................................................................149 25. Diagrams – Representative Examples .......................................................................................................................................155 26. Metadata – Representative Notation ..........................................................................................................................................157 27. EBNF Notation Conventions .....................................................................................................................................................164 28. Abstract Syntax Synthesis Notation...........................................................................................................................................164 29. Grammar Production Definitions...............................................................................................................................................164 30. Graphical BNF Conventions......................................................................................................................................................193 31. Implied Definition Subclassification Relationships...................................................................................................................396 32. Implied Usage Subsetting Relationships ...................................................................................................................................397 33. Other Implied Relationships ......................................................................................................................................................400 34. Standard View Definitions.........................................................................................................................................................513 xviii Systems Modeling Language v2.0, Part 1 -List of Figures 1. SysML Language Architecture ......................................................................................................................................................12 2. Elements.......................................................................................................................................................................................257 3. Dependencies ...............................................................................................................................................................................258 4. Annotation....................................................................................................................................................................................258 5. Namespaces..................................................................................................................................................................................259 6. Imports .........................................................................................................................................................................................260 7. Packages.......................................................................................................................................................................................260 8. Definition and Usage ...................................................................................................................................................................261 9. Variant Membership ....................................................................................................................................................................261 10. Attribute Definition and Usage ..................................................................................................................................................278 11. Enumeration Definition and Usage............................................................................................................................................280 12. Occurrence Definition and Usage ..............................................................................................................................................281 13. Event Occurrences .....................................................................................................................................................................282 14. Item Definition and Usage .........................................................................................................................................................287 15. Part Definition and Usage ..........................................................................................................................................................289 16. Port Definition and Usage..........................................................................................................................................................291 17. Port Conjugation ........................................................................................................................................................................291 18. Connectors as Usages ................................................................................................................................................................296 19. Connection Definition and Usage ..............................................................................................................................................297 20. Interface Definition and Usage ..................................................................................................................................................300 21. Allocation Definition and Usage ...............................................................................................................................................302 22. Flows..........................................................................................................................................................................................304 23. Action Definition and Usage .....................................................................................................................................................306 24. Control Nodes ............................................................................................................................................................................307 25. Performed Actions .....................................................................................................................................................................307 26. Send and Accept Actions ...........................................................................................................................................................308 27. Assignment Actions ...................................................................................................................................................................308 28. Terminate Actions......................................................................................................................................................................309 29. Structured Control Actions ........................................................................................................................................................309 30. State Definition and Usage ........................................................................................................................................................331 31. State Membership ......................................................................................................................................................................331 32. Exhibited States .........................................................................................................................................................................332 33. Transition Usage ........................................................................................................................................................................332 34. Calculation Definition and Usage ..............................................................................................................................................345 35. Constraint Definition and Usage................................................................................................................................................347 36. Asserted Constraints ..................................................................................................................................................................347 37. Requirement Definition and Usage............................................................................................................................................351 38. Satisfied Requirements ..............................................................................................................................................................351 39. Concern Definition and Usage...................................................................................................................................................352 40. Requirement Constraint Membership ........................................................................................................................................352 41. Requirement Parameter Memberships .......................................................................................................................................353 42. Case Definition and Usage.........................................................................................................................................................366 43. Case Membership.......................................................................................................................................................................366 44. Analysis Case Definition and Usage..........................................................................................................................................371 45. Verification Case Definition and Usage ....................................................................................................................................374 46. Verification Membership ...........................................................................................................................................................374 47. Use Case Definition and Usage .................................................................................................................................................378 48. Included Use Case......................................................................................................................................................................378 49. View Definition and Usage........................................................................................................................................................381 50. Viewpoint Definition and Usage ...............................................................................................................................................382 51. Rendering Definition and Usage................................................................................................................................................382 52. Expose Relationship...................................................................................................................................................................383 53. View Rendering Membership ....................................................................................................................................................383 54. Metadata Definition and Usage .................................................................................................................................................393 Systems Modeling Language v2.0, Part 1 xix -55. State Space Representation action and calculation definitions ..................................................................................................536 56. Model Organization for SimpleVehicleModel ..........................................................................................................................635 57. Part Definition for Vehicle.........................................................................................................................................................636 58. Part Definition for FuelTank Referencing Fuel it Stores...........................................................................................................638 59. Axle and its Subclass FrontA.....................................................................................................................................................639 60. Example Definition Elements ....................................................................................................................................................639 61. Part Usage for vehicle_b............................................................................................................................................................640 62. Parts Tree for vehicle_b .............................................................................................................................................................641 63. Variant engine4Cyl ....................................................................................................................................................................642 64. Parts Interconnection for vehicle_b ...........................................................................................................................................643 65. Action providePower .................................................................................................................................................................645 66. Action flow for providePower ...................................................................................................................................................645 67. Action flow for transportPassenger ...........................................................................................................................................646 68. Vehicle States.............................................................................................................................................................................648 69. Requirement Definition MassRequirement ...............................................................................................................................650 70. Requirements Group vehicleSpecification ................................................................................................................................651 71. Analysis Case fuelEconomyAnalysis ........................................................................................................................................653 72. Vehicle Mass Verification Test .................................................................................................................................................654 73. Vehicle Safety View ..................................................................................................................................................................655 74. Rendering of view vehiclePartsTree_Safety..............................................................................................................................656 75. Variability Model for vehicleFamily .........................................................................................................................................656 76. Vehicle Individuals and Snapshots ............................................................................................................................................658 xx Systems Modeling Language v2.0, Part 1 -Systems Modeling Language v2.0, Part 1 xxi -xxii Systems Modeling Language v2.0, Part 1 -1Scope The purpose of this standard is to specify the Systems Modeling Language™ (SysML), to guide the implementation of conformant modeling tools, and to provide the basis for the development of material and other resources to train users in the application of SysML. SysML is a general-purpose modeling language for modeling systems that is intended to facilitate a model-based systems engineering (MBSE) approach to engineer systems. It provides the capability to create and visualize models that represent many different aspects of a system. This includes representing the requirements, structure, and behavior of the system, and the specification of analysis cases and verification cases used to analyze and verify the system. The language is intended to support multiple systems engineering methods and practices. The specific methods and practices may impose additional constraints on how the language is used. SysML is defined as an extension of the Kernel Modeling Language (KerML), which provides a common, domain- independent language for building semantically rich and interoperable modeling languages. SysML also provides a capability to provide further language extensions. It is anticipated that SysML will be customized using this language extension mechanism to model more specialized domain-specific applications, such as automotive, aerospace, healthcare, and information systems, as well as discipline specific extensions such as safety and reliability. Note. Definitions of system and systems engineering can be found in ISO/IEC 15288 Systems and Software Engineering – System Life Cycle Process. Systems Modeling Language v2.0, Part 1 i -ii Systems Modeling Language v2.0, Part 1 -2Conformance This specification defines the Systems Modeling Language (SysML), a language used to construct models of systems (whether they are real, planned or imagined). The specification comprises this document together with the content of the machine-readable files listed on the cover page. If there are any conflicts between this document and the machine-readable files, the machine-readable files take precedence. A SysML model shall conform to this specification only if it can be represented according to the syntactic requirements specified in Clause 8 . The model may be represented in a form consistent with the requirements for the SysML concrete syntax (which includes both textual and graphical notation), in which case it can be parsed (as specified in 8.2 ) into an abstract syntax form, or it may be represented directly in an abstract syntax form. A SysML modeling tool is a software application that creates, manages, analyzes, visualizes, executes or performs other services on SysML models. A tool can conform to this specification in one or more of the following ways. 1. Abstract Syntax Conformance. A tool demonstrating Abstract Syntax Conformance provides a user interface and/or API that enables instances of SysML abstract syntax metaclasses to be created, read, updated, and deleted. The tool must also provide a way to validate the well-formedness of models that corresponds to the constraints defined in the SysML metamodel. A well-formed model represented according to the abstract syntax is syntactically conformant to SysML as defined above. (See 8.3 .) 2. Concrete Syntax Conformance. A tool demonstrating Concrete Syntax Conformance provides a user interface and/or API that enables instances of SysML concrete syntax notation to be created, read, updated, and deleted. Note that a conforming tool may also provide the ability to create, read, update and delete additional notational elements that are not defined in SysML. Concrete Syntax Conformance implies Abstract Syntax Conformance, in that creating models in the concrete syntax acts as a user interface for the abstract syntax. However, a tool demonstrating Concrete Syntax Conformance need not represent a model internally in exactly the form modeled for the abstract syntax in this specification. (See 8.2 .) There are two variants of Concrete Syntax Conformance: a. Textual Notation Conformance. A tool demonstrating Textual Notation Conformance provides Concrete Syntax Conformance for the SysML textual notation. (See 8.2.2 ) b. Graphical Notation Conformance. A tool demonstrating Graphical Notation Conformance provides Concrete Syntax Conformance for the SysML graphical notation. As part of this, the tool shall also support the textual notation at least to the extent necessary to properly render text in the graphical notation, and may also fully support the textual notation in conjunction with the graphical notation. (See 8.2.3 .) 3. Semantic Conformance. A tool demonstrating Semantic Conformance provides a demonstrable way to interpret a syntactically conformant model (as defined above) according to the SysML semantics, e.g., via semantic model analysis or model execution. Semantic Conformance implies Abstract Syntax Conformance, in that the semantics for SysML are only defined on well-formed models represented in the abstract syntax. (See 8.4 and 9.2 .) 4. Model Interchange Conformance. A tool demonstrating model interchange conformance can import and/ or export syntactically conformant SysML models (as defined above) as a project interchange file as specified in [KerML, Clause 10], with the following further conditions: ◦ The project interchange file shall use the standard .kpar (KerML Project Archive) extension. ◦ All model interchange files in the project interchange file shall be SysML models. Textual notation files shall use the extension .sysml . Systems Modeling Language v2.0, Part 1 3 -◦ The metadata for the project interchange file shall identify the metamodel using the normative SysML metamodel URI as given for this specification (i.e., https://www.omg.org/spec/ SysML/yymmnn , where yymmnn is the current date-based version identifier). 5. Domain Library Support. In addition to the Systems Model Library, a conformant tool may provide one or more of the domain model libraries specified in Clause 9 . Every conformant SysML modeling tool shall demonstrate at least Abstract Syntax Conformance and Model Interchange Conformance. In addition, such a tool may demonstrate Concrete Syntax Conformance and/or Semantic Conformance, both of which are dependent on Abstract Syntax Conformance. The tool may also provide Domain Library Support. 4 Systems Modeling Language v2.0, Part 1 -3Normative References The following normative documents contain provisions which, through reference in this text, constitute provisions of this specification. [ISO15897] ISO/IEC 15897:2011 Information technology – User interfaces – Procedures for the registration of cultural elements https://www.iso.org/standard/50707.html [KerML] Kernel Modeling Language (KerML), Version 1.0 https://www.omg.org/spec/KerML/1.0 [MOF] Meta Object Facility, Version 2.5.1 https://www.omg.org/spec/MOF/2.5.1 [OCL] Object Constraint Language, Version 2.4 https://www.omg.org/spec/OCL/2.4 [SMOF] MOF Support for Semantic Structures, Version 1.0 https://www.omg.org/spec/SMOF/1.0 [SysML v1] OMG Systems Modeling Language (SysML), Version 1.7 https://www.omg.org/spec/SysML/1.7 [SysML v1 to v2] OMG Systems Modeling Language (SysML), Version 2.0 Part 2: SysML v1 to SysML v2 Transformation https://www.omg.org/spec/SYSML/2.0/Transformation [UML] Unified Modeling Language (UML), Version 2.5.1 https://www.omg.org/spec/UML/2.5.1 The following references were used in the definition of the Quantities and Units model library (see 9.8 ): [GUM] JCGM 100:2008 and ISO/IEC Guide 98-3, Evaluation of measurement data - Guide to the expression of uncertainty in measurement https://www.bipm.org/en/publications/guides/#gum [ISO 80000-1] ISO 80000-1:2009, Quantities and units - Part 1: General https://www.iso.org/obp/ui/#iso:std:iso:80000:-1:ed-1:v1:en [ISO 80000-2] ISO 80000-2:2019, Quantities and units - Part 2: Mathematical signs and symbols to be used in the natural sciences and technology https://www.iso.org/obp/ui/#iso:std:iso:80000:-2:ed-2:v1:en [ISO 80000-3] ISO 80000-3:2019, Quantities and units - Part 3: Space and Time https://www.iso.org/obp/ui/#iso:std:iso:80000:-3:ed-2:v1:en [ISO 80000-4] ISO 80000-4:2019, Quantities and units - Part 4: Mechanics https://www.iso.org/obp/ui/#iso:std:iso:80000:-4:ed-2:v1:en [ISO 80000-5] ISO 80000-5:2019, Quantities and units - Part 5: Thermodynamics https://www.iso.org/obp/ui/#iso:std:iso:80000:-5:ed-2:v1:en [IEC 80000-6] IEC 80000-6:2008, Quantities and units - Part 6: Electromagnetism https://www.iso.org/obp/ui/#iso:std:iec:80000:-6:ed-1:v1:en,fr Systems Modeling Language v2.0, Part 1 5 -[ISO 80000-7] ISO 80000-7:2019, Quantities and units - Part 7: Light https://www.iso.org/obp/ui/#iso:std:iso:80000:-7:ed-2:v1:en [ISO 80000-8] ISO 80000-8:2020, Quantities and units - Part 8: Acoustics https://www.iso.org/obp/ui/#iso:std:iso:80000:-8:ed-2:v1:en [ISO 80000-9] ISO 80000-9:2019, Quantities and units - Part 9: Physical chemistry and molecular physics https://www.iso.org/obp/ui/#iso:std:iso:80000:-9:ed-2:v1:en [ISO 80000-10] ISO 80000-10:2019, Quantities and units - Part 10: Atomic and nuclear physics https://www.iso.org/obp/ui/#iso:std:iso:80000:-10:ed-2:v1:en [ISO 80000-11] ISO 80000-11:2019, Quantities and units - Part 11: Characteristic numbers https://www.iso.org/obp/ui/#iso:std:iso:80000:-11:ed-2:v1:en [ISO 80000-12] ISO 80000-12:2019, Quantities and units - Part 12: Solid state physics https://www.iso.org/obp/ui/#iso:std:iso:80000:-12:ed-2:v1:en [IEC 80000-13] IEC 80000-13:2008, Quantities and units - Part 13: Information science and technology https://www.iso.org/obp/ui/#iso:std:iec:80000:-13:ed-1:v1:en [IEC 80000-14] IEC 80000-14:2008, Quantities and units - Part 14: Telebiometrics related to human physiology https://www.iso.org/obp/ui/#iso:std:iec:80000:-14:ed-1:v1:en [NIST SP-811] NIST Special Publication 811, The NIST Guide for the use of the International System of Units (In particular its Appendix B "Conversion Factors") https://www.nist.gov/pml/special-publication-811 [VIM] JCGM 200:2012 and ISO/IEC Guide 99, International vocabulary of metrology - Basic and general concepts and associated terms (VIM) https://www.bipm.org/en/publications/guides/#vim [ISO 8601-1] ISO 8601-1:2019 (First edition) Date and time — Representations for information interchange — Part 1: Basic rules https://www.iso.org/standard/70907.html 6 Systems Modeling Language v2.0, Part 1 -4Terms and Definitions Various terms and definitions are specified throughout the body of this specification. Systems Modeling Language v2.0, Part 1 7 -8 Systems Modeling Language v2.0, Part 1 -5Symbols A concrete syntax for SysML is specified in subclause 8.2 of this specification. Systems Modeling Language v2.0, Part 1 9 -10 Systems Modeling Language v2.0, Part 1 -6Introduction 6.1 Document Overview The Systems Modeling Language (SysML) is a general-purpose modeling language for modeling systems that is intended to facilitate a model-based systems engineering (MBSE) approach to engineer systems. This document provides the standard specification for SysML Version 2 (SysML v2). SysML v2 is intended to enhance the precision, expressiveness, interoperability, and the consistency and integration of the language relative to SysML Versions 1.0 to 1.7 [SysML v1]. SysML v1 was specified as a profile of the Unified Modeling Language v2 [UML]. SysML v2, on the other hand, is specified as a metamodel extending the Kernel metamodel from the Kernel Modeling Language [KerML]. In order to facilitate the transition from SysML v1 to SysML v2, this standard also specifies a formal transformation from models using the SysML v1.7 profile of UML to models using the SysML v2 metamodel [SysML v1 to v2]. This document specifies the textual and graphical concrete syntax, abstract syntax, and semantics for SysML v2. The SysML v2 textual notation (see 8.2.2 ) and the SysML v2 graphical notation (see 8.2.3 ) provide the concrete syntax representation of the SysML v2 abstract syntax (see 8.3 ). The SysML v2 abstract syntax extends the Kernel abstract syntax, providing specialized constructs for modeling systems (as shown in Fig. 1 ). Further, the Systems Library (see 9.2 ) is a model library that extends the Kernel Library to provide the semantic specification for SysML v2 (see 8.4 ; see also [KerML] on the use of model libraries for semantic specification). Finally, SysML v2 provides an additional set of Domain Libraries (see 9.4 and following) to provide a set of reference models in various domains important to systems modeling (such as Analysis and Quantities and Units). Systems Modeling Language v2.0, Part 1 11 -Systems DefinitionAndUsage Attributes Enumerations Occurrences Items Parts Ports Connections Interfaces Allocations Flows metamodel Domain Actions Libraries States Calculations Constraints Requirements «import» Cases AnalysisCases VerificationCases metamodel UseCases Systems Model Views Library semantic library Metadata «import» «import» metamodel Kernel Kernel Semantic semantic library Library Figure 1. SysML Language Architecture 6.2 Document Organization The rest of this document is organized into three major clauses. • Clause 7 describes SysML from a user point of view. Its subclauses describe the modeling constructs in SysML, including for each a general overview, related abstract syntax diagrams and a description of the textual and graphical notation. The overviews in this clause should be considered informative. The abstract syntax and notation subclauses, however, are normative, including descriptions of the processing of the textual notation and its relationship to the graphical notation and the abstract syntax. • Clause 8 provides the normative specification of the metamodel that defines the SysML language. This includes the concrete syntax (textual and graphical notations), the abstract syntax and the semantics for the language. The SysML abstract syntax and semantics are formally extensions of the Kernel abstract syntax and semantics provided by KerML (as discussed in 6.1 ). However, this clause does not cover details of the Kernel metamodel, which are included by normative reference to the KerML specification [KerML]. • Clause 9 specifies a set of model libraries defined in SysML itself. The Systems Library extends the Kernel Library from [KerML] in order to provide systems-modeling-specific semantics to SysML language constructs. The Domain Libraries provide domain-specific models on which users can draw 12 Systems Modeling Language v2.0, Part 1 -when creating their own models. Each model library is described with a set of subclauses that covers each of the top-level packages in the model library, referred to as its library models. These clauses are followed by informative Annex A , which presents an example model using the SysML language as defined in this specification to illustrate how the language features can be used to model a system. In addition, Clause 10 of [KerML] on Model Interchange is included by reference as a normative part of this specification in order to define allowable methods for interchanging SysML models. 6.3 Acknowledgements The primary authors of this specification document and the syntactic and semantic models defined in it are: • Sanford Friedenthal, SAF Consulting • Ed Seidewitz, Model Driven Solutions • Roger Burkhart, Thematix Partners • Eran Gery, IBM • Hisashi Miyashita, Mgnite • Hans Peter de Koning, DEKonsult Other contributors include: • Oystein Haugen, Østfold University College • Tomas Juknevicius, Dassault Systèmes • Charles Krueger, BigLever Software The specification was formally submitted for standardization by the following organizations: • 88Solutions Corporation • Dassault Systèmes • GfSE e.V. • IBM • INCOSE • Intercax LLC • Lockheed Martin Corporation • MITRE • Model Driven Solutions, Inc. • PTC • Simula Research Laboratory AS • Thematix Partners LLC However, work on the specification was also supported by over 200 people in over 80 organizations that participated in the SysML v2 Submission Team (SST), by contributing use cases, providing critical review and comment, and validating the language design. The following individuals had leadership roles in the SST: • Manas Bajaj, Intercax LLC (API and services development lead) • Yves Bernard, Airbus (v1 to v2 transformation co-lead) • Bjorn Cole, Lockheed Martin Corporation (metamodel development co-lead) • Sanford Friedenthal, SAF Consulting (SST co-lead, requirements V&V lead) • Charles Galey, Lockheed Martin Corporation (metamodel development co-lead) • Karen Ryan, Siemens (metamodel development co-lead) • Ed Seidewitz, Model Driven Solutions (SST co-lead, pilot implementation lead) • Tim Weilkiens, oose (v1 to v2 transformation co-lead) Systems Modeling Language v2.0, Part 1 13 -The specification was prepared using CATIA Magic/No Magic modeling tools and the OpenMBEE system for model publication (http://www.openmbee.org), supported by the 3DEXPERIENCE platform, with the invaluable support of the following individuals: • Tyler Anderson, Dassault Systèmes • Christopher Delp, Jet Propulsion Laboratory • Jackson Galloway, Dassault Systèmes • Ivan Gomes, Twingineer • Doris Lam, Jet Propulsion Laboratory • Robert Karban, Jet Propulsion Laboratory • Christopher Klotz, Dassault Systèmes • John Watson, Lightstreet Consulting The following individuals made significant contributions to the SysML v2 pilot implementation developed by the SST in conjunction with the development of this specification: • Ivan Gomes, Twingineer • Hisashi Miyashita, Mgnite • Miyako Wilson, Georgia Institute of Technology • Santiago Leon, Tom Sawyer • William Piers, Obeo • Tilo Schreiber, Siemens • Zoltán Ujhelyi, IncQuery Labs 14 Systems Modeling Language v2.0, Part 1 -7 Language Description (Informative) 7.1 Language Overview The System Modeling Language (SysML) contains concepts that are used to model systems, their components, and the external environment in a context. It extends the Kernel Modeling Language (KerML) as specified in the KerML specification [KerML]. SysML directly uses some elements of KerML, but most SysML elements are specializations of KerML elements. This clause provides an informative description of all these language concepts in their context of use in SysML. Clause 8 gives the full definition of the SysML metamodel, which is the normative specification for implementing the language. In contrast, the description in this clause focuses on how the various constructs of the language are used, along with the Systems Model Library (see 9.2 ), to construct models. While non-normative, it is intended to be precise and consistent with the normative specification of the language. SysML directly uses the following concepts from KerML: • Elements and relationships that define the basic graph structure of a model (see 7.2 ). • Dependencies between modeling elements (see 7.3 ). • Annotations for attaching metadata to a model, including comments and textual representations (see 7.4 ). • Namespaces that contain and name elements, and, particularly, packages used to organize the elements in a model (see 7.5 ). • Specialization of elements that specify types, including subclassification, subsetting, redefinition and feature typing (see 7.6 ). • Expressions can be used to specify calculations, case results, constraints and formal requirements. The full KerML expression sub-language is available in SysML, as described in the KerML specification. The description of this sub-language is not repeated in the SysML specification document. The modeling constructs specific to SysML, as specified in subclauses 7.6 through 7.27 , are built on the KerML foundation, and cover the following areas: • Fundamental aspects of constructing a model, including: ◦ The general pattern of definition and usage, which is applied to many of the SysML language constructs (see 7.6 ). The pattern of definition and usage elements facilitates model reuse, such that a concept can be defined once and then used in many different contexts. A usage element can be further specialized for its specific context. ◦ The modeling of variability, which includes the definition of variation points within a model where choices can be made to select a specific variant, and the selection of a particular variant may constrain the allowable choices at other variation points. A system can be configured by making appropriate choices at each of the variation points of a variability model, consistent with specified constraints. Variation points can be defined in any of the specific modeling areas listed below, so the ability to model variability is built into the base syntax of definitions and usages (see 7.6 ). • The modeling of attributive information about things, including: ◦ Attributes that specify characteristics of something that can be defined by simple or compound data types, and dimensional quantities such as mass, length, etc. (see 7.7 ). ◦ Enumerations that are attributes restricted to a specified set of enumerated values (see 7.8 ). • The modeling of occurrences with temporal and spatial extent. Temporal extent enables an occurrence to be represented at specific points in time, over a duration in time, or over an entire lifetime. Spatial extent enables an occurrence to be represented at a position and orientation with respect to a coordinate frame, and to have a shape and size (see 7.9 ). • The modeling of individuals with specific identities (see 7.9 ). Systems Modeling Language v2.0, Part 1 15 -• The modeling of structure to represent how parts are decomposed, interconnected and classified, and includes: ◦ Items that may flow through a process or system or be stored by a system (see 7.10 ). ◦ Parts that are the foundational units of structure, which can be composed and interconnected, to form composite parts and entire systems (see 7.11 ). ◦ Ports that define connection points on parts that enable interactions between parts (see 7.12 ). ◦ Connections (see 7.13 ) and interfaces (see 7.14 ) that define how parts and ports are interconnected. ◦ Allocations that assign responsibility for realizing the features of one element by another element (see 7.15 ). • The modeling of behavior, which specifies how parts interact and includes: ◦ Flows of values and items between parts and actions (see 7.16 ). ◦ Actions performed by a part, including their temporal ordering (see 7.17 ). ◦ States exhibited by a part, the allowable transitions between those states, and the actions enabled in a state or during a transition (see 7.18 ). • The modeling of calculations that are parameterized expressions that can be evaluated to produce specific results (see 7.19 ). • The modeling of constraints, which specify conditions that can be evaluated as true or false, or asserted to be true or false (see 7.20 ). • The modeling of requirements, which is a special kind of constraint that a subject must satisfy to be a valid solution (see 7.21 ). • The modeling of cases, which define the steps required to produce a desired result relative to a subject, possibly also involving external actors, to achieve a specific objective (see 7.22 ), including: ◦ Analysis cases, whose steps are the actions necessary to analyze a subject (see 7.23 ). ◦ Verification cases, whose objective is to verify how a requirement is satisfied by the subject (see 7.24 ). ◦ Use cases, that specify required behavior of the subject with the objective of providing a measurable benefit to one or more external actors (see 7.25 ). • The modeling of viewpoints that specify information of interest by a set of stakeholders, and views that specify a query of the model, and a rendering of the query results, that is intended to satisfy a particular viewpoint (see 7.26 ). • The modeling of user-defined metadata that allows for both simple tagging of elements with additional model-level information and more sophisticated semantic extension of the SysML language. In a similar way that SysML extends KerML, modelers can use this metadata capability to build domain and user- specific extensions of SysML, both syntactically and semantically. This allows SysML to be highly adaptable for specific application domains and user needs, while maintaining a high level of underlying standardization and tool interoperability. (See 7.27 .) It should be noted that SysML does not contain specific language constructs called system, subsystem, assembly, component, and many other commonly used terms. An entity with structure and behavior in SysML is represented simply as a part (see 7.11 ). The language provides straightforward extension mechanisms to specify terminology that is appropriate for the domain of interest. 7.2 Elements and Relationships 7.2.1 Elements and Relationships Overview Metamodel references: • Textual notation, 8.2.2.2 • Graphical notation, 8.2.3.2 • Abstract syntax, 8.3.2 • Semantics, none Elements are the constituents of a model. Some elements represent relationships between other elements, known as the related elements of the relationship. One of the related elements of a relationship may be the owning related 16 Systems Modeling Language v2.0, Part 1 -element of the relationship. If the owning related element of a relationship is deleted from a model, then the relationship is also deleted. Some of the related elements of a relationship (distinct from the owning related element, if any) may be owned related elements. If a relationship has owned related elements, then, if the relationship is deleted from a model, all its owned related elements are also deleted. The owned relationships of an element are all those relationships for which the element is the owning related element. The owned elements of an element are all those elements that are owned related elements of the owned relationships of the element (notice the extra level of indirection through the owned relationships). The owning relationship of an element (if any) is the relationship for which the element is an owned related element (of which the element can have at most one). The owner of an element (if any) is the owning related element of the owning relationship of the element (again, notice the extra level of indirection through the owning relationship). The deletion rules for relationships imply that, if an element is deleted from a model, then all its owned relationships are also deleted and, therefore, all its owned elements. This may result in a further cascade of deletions until all deletion rules are satisfied. An element that has no owner acts as the root element of an ownership tree structure, such that all elements and relationships in the structure are deleted if the root element is deleted. Deleting any element other than the root element results in the deletion of the entire subtree rooted in that element. Graphically, non-relationship elements are generally represented using a box-like shape or other icon, while relationships are shown using lines connecting the symbols for the related elements. However, in some cases, additional shapes may be attached to relationship lines in order to present additional information. The specific conventions for such graphical notations are covered in subsequent subclauses. 7.2.2 Elements Various specific kinds of model elements in SysML are described in subsequent subclauses. However, there are certain concepts that apply to all model elements. Every element has a unique identifier known as its element ID. The properties of an element can change over its lifetime, but its element ID does not change after the element is created. An element may also have additional identifiers, its alias IDs, which may be assigned for tool-specific purposes. The SysML notation, however, does not have any provision for specifying element or alias IDs, since these are expected to be managed by the underlying modeling tooling. Instead, an element can be given a name and/or a short name, and it can also have any number of alias names relative to one or more namespaces (see 7.5 ). In most cases, an element is declared using a keyword indicating the kind of element it is (e.g., part def or attribute ). The declaration of an element may also specify a short name and/or name for it, in that order. The short name is distinguished by being surrounded by the delimiting characters < and > . part <'1.2.4'> myName; While the language makes no formal distinction between names and short names, the intent is that the name of an element should be fully descriptive, particularly in the context of the definition of the element, while the short name, if given, should be an abbreviated name useful for referring to the element. Note also that it is not required to specify either a name or a short name for an element. However, unless at least one of these is given, it is not possible to reference the element using the textual notation (though it is still possible to show it in relationships on graphical diagrams). Names and short names can contain essentially any printable characters (and certain control characters). However, when written in the textual notation, they must be represented with a specific lexical structure, which has two variants. 1. A basic name is one that can be lexically distinguished in itself from other parts of the textual notation. The initial character of a basic name must be a lowercase letter, an uppercase letter or an underscore. The remaining characters of a basic name can be any character allowed as an initial character or any digit. Systems Modeling Language v2.0, Part 1 17 -However, a reserved word may not be used as a name, even though it has the form of a basic name (see 8.2.2.1.2 for the list of the reserved words in SysML). Vehicle power_line 2. An unrestricted name provides a way to represent a name that contains any character. It is represented as a non-empty sequence of characters surrounded by single quotes. The name consists of the characters within the single quotes – the single quotes are not included as part of the represented name. The characters within the single quotes may not include non-printable characters (including backspace, tab and newline). However, these characters may be included as part of the name itself through use of an escape sequence. In addition, the single quote character or the backslash character may only be included within the name by using an escape sequence. '+' 'circuits in line' 'On/Off Switch' 'Ångström' An escape sequence is a sequence of two text characters starting with a backslash as an escape character, which actually denotes only a single character (except for the newline escape sequence, which represents however many characters is necessary to represent an end of line in a specific implementation). See [KerML, 8.2.2.3] for a complete description of unrestricted names and escape sequences. In addition to its declaration, the representation for an element may also list other elements owned by the containing element. In the textual notation, such owned elements are shown represented as a body delimited by curly braces { ... } , particularly when the owning element is a namespace (see 7.5 ). In the graphical notation, owned elements may be shown in compartments within the symbol representing the owning element, particularly when the owning element is a package, definition or usage (see 7.5 and 7.6.1 ). 7.2.3 Relationships A relationship is a kind of element that relates two or more other elements. Some relationships are constrained to have exactly two related elements (i.e., binary relationships) while others may have more. The related elements of relationships are ordered. A relationship may designate certain of its related elements as sources with the rest being targets. In this case, the relationship is said to be directed from the sources to the targets. An undirected relationship simply designates all its related elements to be targets, with no source elements. A relationship may also be the source or target of other relationships. In particular, a relationship may be annotated by being the target of an annotation relationship (see 7.4 ). In some cases, the annotating element may be owned by the annotated relationship via the annotation relationship, particularly in the case of a documentation comment (see 8.2.2.4.2 ). 7.3 Dependencies 7.3.1 Dependencies Overview Metamodel references: • Textual notation, 8.2.2.3 • Graphical notation, 8.2.3.3 • Abstract syntax, 8.3.3 • Semantics, none A dependency is a kind of relationship between any number of client (source) and supplier (target) elements. This implies that a change to a supplier element may result in a change to a client element. Dependencies can be useful for representing relationships between elements in an abstract way. For example, a dependency can be used to 18 Systems Modeling Language v2.0, Part 1 -represent that an upper layer of an architecture stack may depend on a lower layer of the stack. A dependency can also be extended to reflect more specialized relationships, such as refinement (e.g., by using user-defined keywords, see 7.27 ). Table 1. Dependencies – Representative Notation Element Graphical Notation Textual Notation dependency Package2 to Package1; Dependency Package2 Package1 Package1 Package3 dependency Package1, Package2 Dependency - nary to Package3, Package4; Package2 Package4 7.3.2 Dependency Declaration A dependency is declared textually using the keyword dependency . The client elements of the dependency are then given as a comma-separated list of qualified names following the keyword from , followed by a similar list of the supplier elements after the keyword to . If no short name or name is given for the dependency, then the keyword from may be omitted. dependency Use from 'Application Layer' to 'Service Layer'; // 'Service Layer' is the client of this dependency, not its name. dependency 'Service Layer' to 'Data Layer', 'External Interface Layer'; A dependency declaration may also optionally have a body containing any annotating elements owned by the dependency via annotation relationships (see 7.4 ). dependency 'Service Layer' to 'Data Layer', 'External Interface Layer' { /* 'Service Layer' is the client of this dependency, * not its name. */ } 7.4 Annotations 7.4.1 Annotations Overview Metamodel references: • Textual notation, 8.2.2.4 • Graphical notation, 8.2.3.4 • Abstract syntax, 8.3.4 Systems Modeling Language v2.0, Part 1 19 -• Semantics, none An annotating element is an element that is used to provide additional information about other elements. An annotation is a relationship between an annotating element and an annotated element that is being described. An annotating element can annotate multiple annotated elements, and each element can have multiple annotations. A comment is one kind of annotating element that is used to provide textual descriptions about other elements. Comments can be members of namespaces and, therefore, can be named. Such member comments may be about the namspace that owns them, or they may be about different elements. Documentation is a distinguished kind of comment used to document the annotated element. Documentation comments always annotate a single element, which is their owning element. A textual representation is an annotating element whose textual body provides a representation of the annotated element in a specifically named language. This representation may be in the SysML textual notation or it may be in another language. If the named language is machine-parsable, then the body text should be legal input text as defined for that language. In particular, annotating a SysML model element with a textual annotation in a language other than SysML can be used as a semantically "opaque" element specified in the other language. It is also possible to annotate elements with user-defined metadata, allowing both syntactic and semantic extension of SysML. This capability is described in 7.27 . Table 2. Annotations – Representative Notation Element Graphical Notation Textual Notation This is a comment. /*This is a comment.*/ Comment «comment» Comment1 comment Comment1 Comment /*This is a comment.*/ This is a comment. «doc» doc /*This is Documentation This is documentation. documentation.*/ «doc» doc Document1 Document1 /*This is Documentation This is documentation. documentation.*/ «doc» Documentation with doc locale "fr_BE" locale "fr_BE" /* Ceci n'est pas une locale (in French, Ceci n'est pas une pipe. pipe. */ region Belgium) 20 Systems Modeling Language v2.0, Part 1 -Element Graphical Notation Textual Notation rep language "language1" /* body1 */ «rep» Textual language="language1" or Representation body1 language "language1" /* body1 */ «part» «comment» comment about part1 : Part1 part1::attribute1 The annotated element attributes Annotation /* The annotated element is attribute1. attribute1 : Attribute1 * is attribute1. */ attribute2 : Attribute2 part part1 : Part1 { «doc» p1 : P1 doc /* «part» documentation-text */ Annotation- documentation-text port p1 : P1; part1 : Part1 Documentation port p2 : P2; p2 : P2 } calc def square { in attribute x : ScalarValues::Real; return x:Real :ScalarValues::Real; «rep» rep square language «calc def» Annotation-Textual language="Python" "Python" def square(x:float) -> float: CalcDef1 Representation /* return x**2 * def :Real square(x:float) -> float: * return x**2 */ doc doc /*This is a Documentation This is a documentation compartment. documentation Compartment *compartment.*/ 7.4.2 Comments and Documentation The full declaration of a comment begins with the keyword comment , optionally followed by a short name and/or name (see 7.2 ). One or more qualified names of annotated elements for the comment, separated by commas, are then given after the keyword about , indicating that the comment has annotation relationships to each of the identified elements. The body of the comment is written lexically as text between /* and */ delimiters. Systems Modeling Language v2.0, Part 1 21 -item A; part B; comment Comment1 about A, B /* This is the comment body text. */ If the comment is an owned member of a namespace (see 7.5 ), then the explicit identification of annotated elements can be omitted, in which case the annotated element is implicitly the containing namespace. Further, in this case, if no short name or name is given for the comment, then the comment keyword can also be omitted. package P { comment C /* This is a comment about P. */ /* This is also a comment about P. */ } A locale can also be specified for a comment, using the keyword locale followed by the locale string, placed immediately before the comment body (whether or not the comment keyword is used). The locale identifies the language of the body text and, optionally, the region and/or encoding. The format is language[_territory][.codeset][@modifier] (conformant to [ISO15897]). comment C_US_English locale "en_US" /* This is US English comment text */ A documentation comment is notated similarly to a regular comment, but using the keyword doc rather than comment . The documenting element of documentation is always the owning element of the documentation. part X { doc X_Comment /* This is a documentation comment about X. */ doc /* This is more documentation about X. */ } When a comment is written in the textual notation, the actual body text of the comment is extracted from the lexical comment body according to the rules given in the KerML specification [KerML, 8.2.3.3.2]. The body text of a comment can include markup information (such as HTML), and a tool may graphically display such text as rendered according to the markup. However, marked up "rich text" for a comment is stored in the comment body in plain text including all mark up text, with all line terminators and white space included as entered, other than what is removed according to the rules referenced above. 7.4.3 Textual Representation A textual representation is notated similarly to a regular comment, but with the keyword rep used instead of comment . As for documentation, a textual representation is always owned by its represented element. In particular, if the textual representation is an owned member of a namespace (see 7.5 ), then the represented element is the containing namespace. A textual representation declaration must also specify the language as a literal string following the keyword language . If the textual representation has no short name or name, then the rep keyword can also be omitted. part def C { attribute x: Real; assert x_constraint { rep inOCL language "ocl" /* self.x > 0.0 */ } } action def setX(c : C, newX : Real) { language "alf" /* c.x = newX; * WriteLine("Set new x"); 22 Systems Modeling Language v2.0, Part 1 -*/ } The lexical comment text given for a textual representation is processed as for regular comment text, and it is the result after such processing that is the textual representation body expected to conform to the named language. Note. Since the lexical form of a comment is used to specify the textual representation body , it is not possible to include comments of a similar form in the body text. The language name in a textual representation is case insensitive. The name can be of a natural language, but will often be for a machine-parsable language. In particular, there are recognized standard language names. If the language is "sysml" , then the body of the textual representation must be a legal representation of the represented element in the SysML textual notation. A tool can use such a textual representation to record the original SysML notation text from which an element is parsed. Other standard language names that can be used in a textual representation include "kerml" , "ocl" , and "alf" , in which case the body of the textual representation must be written in the Kernel Modeling Language [KerML], Object Constraint Language [OCL] or the Action Language for fUML [Alf], respectively. (This is the same set of standard language names as in [KerML, 7.2.4.3, 8.3.2.3], with the addition of "sysml" .) However, for any other language than "sysml" , the SysML specification does not define how the body text is to be semantically interpreted as part of the model being represented. An element with no other definition than a textual representation in a language other than SysML is essentially a semantically "opaque" element specified in the other language. Nevertheless, a conforming SysML tool may (but is not required to) interpret such an element consistently with the specification of the named language. 7.5 Namespaces and Packages 7.5.1 Namespaces Overview Metamodel references: • Textual notation, 8.2.2.5 • Graphical notation, 8.2.3.5 • Abstract syntax, 8.3.5 • Semantics, none A namespace is a kind of element that can contain other elements and provide names for them. The elements contained in a namespace are referred to as its member elements. Membership is a kind of relationship that relates a namespace to its members. A membership relationship can specify the name by which its member element is known relative to the containing namespace and whether the element membership is visible outside the namespace or not (see 7.5.2 ). An element may be owned via its membership in a namespace. When a namespace is deleted, all such owned members will also be deleted. An element may also have a membership in a namespace without being owned by the namespace. In this case, the membership may introduce an alias name for the element relative to the namespace. Note that it is possible for an element to have both owning and non-owning memberships with the same namespace, but it can have at most one owning membership across all namespaces. An import relationship allows one namespace to import memberships from another namespace (see 7.5.3 ). The member elements from imported memberships become (unowned) members of the importing namespace in addition to being members of the imported namespace. In particular, this allows members of the imported namespace to be referenced in textual notations within the scope of the importing namespace without having to qualify the member names with the name of the imported namespace. An import can also be recursive, which means that, in addition to importing members of the referenced namespace itself, all namespaces that are owned members of the imported package are also recursively imported. Systems Modeling Language v2.0, Part 1 23 -A package is a kind of namespace that is used solely as a container for other elements to organize the model. In addition, a package has the capability to filter imported elements based on certain conditions (see 7.5.4 ), usually defined in terms of the metadata provided by annotations of those elements (see 7.4 and 7.27 ). Only elements that meet all filter conditions actually become imported members of the package. Together, recursive import and filtering provide a general capability for specifying that a package automatically contain a set of elements identified from across a model by their metadata. In addition to packages, all kinds of SysML definitions and usages are also namespaces (see 7.6 and following subclauses). All rules discussed generically for namespaces in this subclause 7.5 apply generically to packages, definitions and usages (even though the examples in this subclause are given using packages). In general, an element may have different names in different namespaces, and the same name may identify different elements relative to different namespaces. Therefore, to unambiguously identify an element by name, the element name must be qualified by the namespace relative to which the element name is to be resolved. Such a qualified name is notated by specifying a name to identify the namespace, followed by the symbol :: , followed by the element name. Since the namespace name may also be qualified, a qualified name is most generally a sequence of segment names separated by :: punctuation, of which all but the last must identify namespaces. An unqualified name can be considered the degenerate case of a qualified name with just one element name in its sequence, for which the namespace to be used is implicit. Note that qualified names do not appear in the abstract syntax. Instead, the abstract syntax representation contains actual references to the identified elements. Name resolution is the process of determining the element that is identified by a qualified name. An unqualified name used within the body of a namespace is resolved in the context of that namespace and, potentially, other namespaces in which the first namespace is lexically nested, taking into account imported (see 7.5.3 ) and inherited (see 7.6 ) memberships. A qualified name with more than one segment is resolved by recursively resolving the name of the qualifying namespace and then resolving the element name in that context. The full name resolution process is specified in [KerML, 8.2.3.5]. Table 3. Packages – Representative Notation Element Graphical Notation Textual Notation Package (name in package Package1; body) Package1 Package1 Package (name in package Package1; tab) Package1 package Package1 { package Package2 Package with owned package Package2; package } 24 Systems Modeling Language v2.0, Part 1 -Element Graphical Notation Textual Notation Package1 Package2 package Package1 { package Package 2; Package with owned part def Part2; members «part def» part part2 : Part2; } Part2 «part» part2 : Part2 Package1 package Package1 { alias Package2Alias Package with alias for Package2; «alias» member (unowned) } Package2Alias package Package2; for Package2 Package1 package Package1 { alias Package2Alias Package with alias for Package2; member (unowned) «alias» } package Package2; Package2Alias Package1 package Package1 { Package2 public import Package with Package2::*; imported package private import (nested notation) Package3::*; } «private» Package3 Systems Modeling Language v2.0, Part 1 25 -Element Graphical Notation Textual Notation package Package0 { Membership (owned package Package1; member) Package0 Package1 } package Package0 { Membership alias Package1Alias Package1Alias for Package1; (unowned member Package0 Package1 } with alias name) package Package1; Import (recursive) Note: - no star is element import package Package2 { private import - single star is «private import» ** Package0::Package1::**; Package2 Package1 package import } (content of package) - double star is recursive including outer package Package1 package Package1 { Package with /* members */ compartment stack compartment } ... Package1 package Package1 { members part def PartDef1; part def PartDef2; part def PartDef1 Package with part part1 : members PartDef1; part def PartDef2 compartment part part2 : PartDef2; part part1 : PartDef1 } part part2 : PartDef2 7.5.2 Owned Members and Aliases A package is declared using the keyword package , with the owned members of the package listed in its body. package Configurations { attribute def ConfigEntry { attribute key: String; attribute value: String; } 26 Systems Modeling Language v2.0, Part 1 -item ConfigData { attribute entries[*]: ConfigEntry; } } In general, declaring an element within the body of a namespace denotes that the element is an owned member of the namespace—that is, that there is an owning membership relationship between the namespace and the member element. The visibility of the membership can be specified by placing one of the keywords public , protected or private before the public element declaration. If the membership is public (the default), then it is visible outside of the namespace. If it is private , then it is not visible. For namespaces other than definitions and usages, protected visibility is equivalent to private . For definitions and usages, protected visibility has a special meaning relating to member inheritance (see 7.6 ). package P { public part def A; private attribute def B; part a : A; // public by default } An alias for an element is a non-owning membership of the element in a namespace, which may or may not be the same namespace that owns the element. An alias name or short name is determined only relative to its membership in the namespace, and can therefore be different than the name or short name defined on the element itself. Note that the same element may be related to a namespace by multiple alias memberships, allowing the element to have multiple, different names relative to that namespace. An alias is declared using the keyword alias followed by the alias short name and/or name, with a qualified name identifying the element given after the keyword for . An alias declaration may also optionally have a body containing annotating elements for the alias (see 8.2.2.4.1 ). The visibility of the alias membership can be specified as for an owned member. package P1 { item A; item B; alias CCC for B { doc /* Documentation of the alias. */ } private alias D for B; } A comment (see 7.4 ), including documentation, declared within a namespace body also becomes an owned member of the namespace. If no annotated elements are specified for the comment (with an about clause), then, by default, the comment is considered to be about the containing namespace. package P9 { item A; comment Comment1 about A /* This is a comment about item A. */ comment Comment2 /* This is a comment about package P9. */ /* This is also a comment about package P9. */ doc P9_Doc /* This is documentation about package P9. */ } 7.5.3 Imports Systems Modeling Language v2.0, Part 1 27 -An owned import of a Namespace is denoted using the keyword import followed by a qualified name, optionally suffixed by " ::* " and/or " ::** ". If the qualified name in an import does not have any suffix, then this specifies a membership import whose imported membership is identified by the qualified name. Such an import results in the identified membership becoming an imported membership of the namespace owning the import. That is, the member element of this membership becomes an imported member of the importing namespace. Note that the imported membership may be an alias membership (see 7.5.2 ), in which case the element is imported with that alias name. package P2 { private import P1::A; private import P1::C; // Imported with name "C". package Q { import C; // "C" is re-imported from P2 into Q. } } If the qualified name in an import is further suffixed by "::* ", then then this specifies a namespace import in which the qualified name identifies the imported namespace. In this case, all visible memberships of the imported namespace of the import become imported memberships of the importing namespace. package P3 { // Memberships A, B and C are all imported from P1. private import P1::*; } If the declaration of either a membership or namespace import is further suffixed by " ::** ", then the import is recursive. Such an import is equivalent to importing memberships as described above for either an imported membership or namespace, followed by further recursively importing from each imported member that is itself a namespace, with the following limitations: 1. Recursive import only continues with a namespace that is either the imported element of an original recursive membership import or an owned member of an imported namespace. 2. Memberships inherited via implicit specializations (of any kind) are not imported by recursive imports (see also 7.6.8 on Implicit Specialization). package P4 { item A; item B; package Q { item C; } } package P5 { private import P4::**; // The above recursive import is equivalent to all // of the following taken together: // private import P4; // private import P4::*; // private import P4::Q::*; } package P6 { private import P4::*::**; // The above recursive import is equivalent to all // of the following taken together: // private import P4::*; // private import P4::Q::*; // (Note that P4 itself is not imported.) } 28 Systems Modeling Language v2.0, Part 1 -The visibility of an import is always shown explicitly by placing the keyword private , protected , or public before the import declaration. If the import is private (which is the default in the abstract syntax), then the imported memberships become private relative to the importing namespace. A visibility of protected is the same as private , unless the importing namespace is a definition or usage, in which case the imported memberships are also visible in all specializations of the definition or usage (see also 7.6 on inheritance). If the import is public , then all the imported memberships become public for the importing namespace. An import declaration may also optionally have a body containing annotating elements owned by the import (see 8.2.2.4.1 ). package P7 { public import P1::A { /* The imported membership is visible outside P7. */ } private import P4::* { doc /* None of the imported memberships are visible * outside of P7. */ } 7.5.4 Import Filtering A package may also contain filter conditions that filter the imports for the package. A filter condition is a Boolean- valued, model-level evaluable expression (see [KerML. 7.4.9]) declared using the keyword filter followed by a Boolean-valued, model-level evaluable expression (see [KerML. 7.4.9]). The filter conditions of a package are evaluated on the member elements of all memberships that are potentially to be imported into the package (see 7.5.3 ). Only those memberships that for which all the filter conditions evaluate to true are actually imported. Filter conditions can, for example, be used to select which elements to import into a package based on metadata applied to those elements (see also 7.27 on metadata). package ApprovalMetadata { metadata def Approval { attribute approved : Boolean; attribute approver : String; attribute level : Natural; } ... } package DesignModel { public import ApprovalMetadata::*; part System { @Approval { approved = true; approver = "John Smith"; level = 2; } } ... } package UpperLevelApprovals { // This package imports all direct or indirect members // of the DesignModel package that have been approved // at a level greater than 1. public import DesignModel::**; filter @ApprovalMetadata::Approval and ApprovalMetadata::Approval::approved and ApprovalMetadata::Approval::level > 1; } Systems Modeling Language v2.0, Part 1 29 -Note that a filter condition in a package will filter all imports of that package. That is why full qualification is used for ApprovalMetadata::Approval in the example above, since an imported element of the ApprovalMetadata package would be filtered out by the very filter condition in which the elements are intended to be used. This may be avoided by combining one or more filter conditions with a specific import in a filter import declaration. A filter import includes one or more filter conditions in the import declaration, listed after the imported membership or namespace specification, each surrounded by square brackets [ ... ] . For such a filtered import, memberships are imported, from that specific import, if and only if they satisfy all the given filter conditions. package UpperLevelApprovals { // Recursively import all annotation data types and all // features of those types. private import ApprovalMetadata::**; // The filter condition for this import applies only to // elements imported from the DesignModel package. public import DesignModel::**[@Approval and approved and level > 1]; } The SysML package from the Systems Model Library (see 9.2.22 ) contains a complete model of the SysML abstract syntax represented in SysML itself, and it publicly imports the KerML package from the Kernel Library containing the Kernel abstract syntax model (see [KerML, 9.2.17]). When a filter condition is evaluated on an element, abstract syntax metadata for the element can be tested as if the element had an implicit metadata usage (see 7.27 ) defined by the definition from the SysML package corresponding to the abstract syntax metaclass of the element. package PackageApprovals { private import ApprovalMetadata::*; private import SysML::*; // This imports all part definitions from the DesignModel that have // at least one owned part usage and have been marked as approved. public import DesignModel::**[@PartDefinition and @PartDefinition::ownedPart != null and @Approval and Approval::approved]; } Note. Namespaces other than packages cannot have filter conditions (except for their special use in view definitions and usages – see 7.26 ). However, any kind of namespaces may have filtered imports. 7.5.5 Root Namespaces A root namespace is a namespace that has no owner. The owned members of a root namespace are known as top- level elements. Any element that is not a root namespace has an owner and, therefore, must be in the ownership tree of a top-level element of some root namespace. The declaration of a root namespace is implicit and no identification of it is provided in the SysML notation. Instead, the content of a root namespace is given simply by the list of its top-level elements. For the purposes of model interchange (see [KerML, Clause 10]), a single project may contain one or more root namespace, though there is no syntax for defining a project in the SysML syntax. doc /* This is a model notated in SysML textual notation. */ item def I; attribute def A; item i: I; package P; 30 Systems Modeling Language v2.0, Part 1 -While a root namespace has no explicit owner, it is considered to be within the scope of a single global namespace. This global namespace may contain several root namespaces (such as those being managed as a project), and always contains at least all of the KerML and SysML model libraries (see [KerML, Clause 9] and Clause 9 ). Any root namespace within the global namespace may refer to the name of a top-level element of any other root namespace using an unqualified name (since root namespaces are themselves never named). If an import is owned by a root namespace, then the memberships imported by it are visible to and within all the top- level elements of the root namespace. However, an import owned by a root namespace is required to be private , so none of the imported memberships become globally visible outside of the root namespace. (This rule disallows the "re-export" of the same element from multiple different root namespaces, which would cause ambiguity that could complicate the resolution of unqualified, globally-visible names.) 7.6 Definition and Usage 7.6.1 Definition and Usage Overview Metamodel references: • Textual notation, 8.2.2.6 • Graphical notation, 8.2.3.6 • Abstract syntax, 8.3.6 • Semantics, 8.4.2 Definitions and Usages The modeling capabilities of SysML facilitate reuse in different contexts. Definition and usage elements provide a consistent foundation for many SysML language constructs to provide this capability, including attributes, occurrences, items, parts, ports, connections, interfaces, allocations, actions, states, calculations, constraints, requirements, concerns, cases, analysis cases, verification cases, use cases, views, viewpoints and renderings. In general, a definition element classifies a certain kind of element (e.g., a classification of attributes, parts, actions, etc.). A usage element is a usage of a definition element in a certain context. A usage must always be defined by at least one definition element that corresponds to its usage kind. For example, a part usage is defined by a part definition, and an action usage is defined by an action definition. If no definition is specified explicitly, then the usage is defined implicitly by the most general definition of the appropriate kind from the Systems Library (see 9.2 ). For example, a part usage is implicitly defined by the most general part definition Part from the model library package Parts . Features A definition may have owned usage elements nested in it, referred to as its features. A usage may also have nested usage elements as features. In this case, the context for the nested usages is the containing usage. A simple example is illustrated by a parts tree that is defined by a hierarchy of part usages. A vehicle usage defined by Vehicle could contain part usages for engine , transmission , frontAxle , and rearAxle . Each part usage has its own (implicit or explicit) part definition. A feature relates instances of its featuring definition or usage to instances of its definition. For example, a mass feature with definition MassValue , featured by the definition Vehicle , relates each specific instance of Vehicle to the specific MassValue for that vehicle, known as the value of the mass feature of the vehicle. A usage can also be contained directly in an owning package. In this case, the usage element is considered to be an implicit feature of the most general kernel type Anything . That is, a package-level usage is essentially a generic feature that can be applied in any context, or further specialized in specific contexts (as described under Specialization below). Systems Modeling Language v2.0, Part 1 31 -A usage may have a multiplicity that constrains its cardinality, that is, the allowed number of values it may have for any instance of its featuring definition or usage. The multiplicity is specified as a range, giving the lower and upper bound expressions that are evaluated to determine the lower and upper bounds of the specified range. The bounds must be natural numbers. The lower bound must be finite, but the upper bound may also have the infinite value * . An upper bound value of * indicates that the range is unbounded, that is, it includes all numbers greater than or equal to the lower bound value. If a lower bound is not given, then the lower bound is taken to be the same as the upper bound, unless the upper bound is * , in which case the lower bound is taken to be 0 . For example, a Vehicle definition could include a usage element called wheels with multiplicity 4 , meaning each Vehicle has exactly four wheels . A less restrictive constraint, such as a multiplicity of 4..8 , means each Vehicle can have 4 to 8 wheels. A usage may be referential or composite. A referential usage represents a simple reference between a featuring instance and one or more values. A composite usage, on the other hand, indicates that the related instance is integral to the structure of the containing instance. As such, if the containing instance is destroyed, then any instances related to it by composite usages are also destroyed. For example, a Vehicle would have a composite usage of its wheels , but only a referential usage of the road on which it is driving. Note. The concept of composition only applies to occurrences that exist over time and can be created and destroyed (see 7.9 ). Attribute usages are always referential and any nested features of attributes definitions and usages are also always referential (see 7.7 ). Specialization Definition and usage elements can be specialized using several different kinds of specialization relationships. A definition is specialized using the subclassification relationship. The specialized definition inherits the features of the more general definition element and can add other features. For example, if Vehicle has a feature called fuel , that is defined by Fuel , and Truck is a specialized kind of Vehicle , then Truck inherits the feature fuel . An inherited feature can be subsetted or redefined as described below. The Truck definition can also add its own features such as cargoSize . A definition can specialize more than one other definition, in which case the definition inherits the features from each of the definitions it specializes. All inherited features must have names that are distinct from each other and any owned features of the specializing definition. Name conflicts can be resolved by redefining one or more of the otherwise conflicting inherited features (see below). A usage inherits the features from its definition in the same way that a specialized definition inherits from a more general definition element. For example, if a part usage vehicle is defined by a part definition Vehicle , and Vehicle has a mass defined by MassValue , then vehicle inherits the feature mass . In some cases, a usage may have more than one definition element, in which case the usage inherits the features from each of its definition elements, with the same rules for conflicting names as described above for subclassification. A usage can also add its own features, and subset or redefine its inherited features. This enables each usage to be modified for its context. A usage can be specialized using the subsetting relationship. A subsetting usage has a subset of the values of the subsetted usage. The subsetting usage may further constrain its definition and multiplicity. For the example above, Truck inherits the feature wheels with multiplicity 4..8 from Vehicle . The part usage truck further inherits wheels with multiplicity 4..8 from Truck . The part usage truck can subset wheels by defining frontLeftWheel , frontRightWheel , rearLeftwheel1 , and rearRightWheel1 , each with multiplicity 1..1, together giving the minimum total multiplicity of 4. The truck usage can then define additional subsets of wheels , such as rearLeftwheel2 , and rearRightwheel2 , with multiplicity 0..1, indicating they are optional. Redefinition is a kind of subsetting. While, in general, a subsetting usage is an additional feature to the subsetted usage, a redefining usage replaces the redefined usage in the context of redefining usage. For the example above, Vehicle contains a feature called fuel that is defined by Fuel . Truck inherits fuel from Vehicle . The part usage truck would then normally inherit fuel as defined by Fuel from Truck . However, truck can instead redefine fuel to restrict its definition to DieselFuel , a subclassification of Fuel . In this case, the new redefining 32 Systems Modeling Language v2.0, Part 1 -feature replaces the fuel feature that would otherwise be inherited, meaning that the fuel of the truck part must be defined by DieselFuel . A usage, particularly one with nested usages, can be reused by subsetting it. For example, subsetting the part usage vehicle is analogous to specializing the part definition Vehicle . Suppose vehicle1 is a part usage that subsets vehicle , with the parts-tree decomposition described above. This enables vehicle1 to inherit the features and structure of vehicle . The part usage vehicle1 can be further specialized by adding other part usages to it, such as a body and chassis , and it can redefine parts from vehicle as needed. For example, vehicle1 may redefine engine to be a 4-cylinder engine . The original part vehicle remains unchanged, but vehicle1 is a unique design configuration that specializes vehicle . Other part usages, such as vehicle2 , could be created in a similar way to represent other design configurations. Note. If the part definition Vehicle is modified, the modification will propagate down through the specializations described above. However, it is expected that if Vehicle is baselined in a configuration management tool, then a change to Vehicle is a new revision, and it is up to the modelers to determine whether to retain the previous version of Vehicle or move to the next revision. Variability Variation and variant are used to model variability typically associated with a family of design configurations. A variation (sometimes referred to as a variation point) identifies an element in a model that can vary from one design configuration to another. One example of a variation is an engine in a vehicle. For each variation, there are design choices called variants. For this example, where the engine feature is designated as a point of variation, the design choices are a 4-cylinder engine variant or a 6-cylinder engine variant. Variation can apply to any kind of definition or usage in the model (except for enumeration, see 7.8 ). The variation element then specifies all possible variants (i.e., choices) for that variation point. For example, the specified variants for the engine variation are the 4-cylinder engine and the 6-cylinder engine . Variants are usage elements. If the containing variation is a definition, then each of its variants is implicitly defined by the variation definition. If the containing variation is a usage, then each of its variants implicitly subsets the variation usage. For example, the 4-cylinder engine and the 6-cylinder engine are subsets of all possible engines . Variations can be nested within other variations, to any level of nesting. For example, the 6-cylinder engine variant may in turn contain cylinders with a variation for bore diameter that includes variants for small-bore diameter and large-bore diameter . Alternatively, the bore diameter variation could be applied more generally to the cylinder of engine , enabling both the 4-cylinder engine and the 6-cylinder engine to have this variation point. A model with variability can be quite complex since the variation can extend to many other aspects of the model including its structure, behavior, requirements, analysis, and verification. Also, the selection of a particular variant often impacts many other design choices that include other parts, connections, actions, states, and attributes. Constraints can be used to constrain the available choices for a given variant. For example, the choice of a 6-cylinder engine may constrain the choice of transmission to be an automatic transmission , whereas the choice of a 4-cylinder engine may allow for both an automatic transmission or a manual transmission . Variations and variants are used to construct a model that is sometimes referred to as a superset model, which includes the variants to configure all possible design configurations. A particular configuration is selected by selecting a variant for each variation. SysML provides validation rules that can evaluate whether a particular configuration is a valid configuration based on the choices and constraints provided in the superset model. Variability modeling in SysML can augment other external variability modeling applications, which provide robust capabilities for managing variability across multiple kinds of models such as CAD, CAE, and analysis models, and auto-generating the variant design configurations based on the selections. Systems Modeling Language v2.0, Part 1 33 -Note. The approach to variability modeling in SysML is intended to align with industry standards such as ISO/IEC 26580:2021 Software and systems engineering — Methods and tools for the feature-based approach to software and systems product line engineering. Graphical Compartments The graphical notation for a definition or usage may include one or more compartments, which show member elements (if any) using textual or graphical notation. In the graphical symbols in all Representative Notation tables in Clause 7 , the term compartment stack is a placeholder for any valid compartment for the model element. Table 4. Definition and Usage – Representative Notation Element Graphical Notation Textual Notation «part def» PartDef1 Name Compartment part def PartDef1; - Definition (without part def PartDef2; and with short name) «part def» PartDef2 abstract part def PartDef1 :> PartDef0; package P { «part def» alias PartDefAlias1 PartDef1 :> PartDef0 Name Compartment for PartDef1; «alias» - Definition } P::PartDefAlias1, Q::PartDefAlias2 package Q { alias PartDefAlias2 for PartDef1; } package Package1 { Name Compartment package Package2 { «part def» part def PartDef3; - Definition Package1::Package2::PartDef3 } (qualified name) } Name Compartment «abstract part def» abstract part def - Definition PartDef1 PartDef1; (abstract) Name Compartment «variation part def» variation part def - Definition PartDef1; PartDef1 (variation) 34 Systems Modeling Language v2.0, Part 1 -Element Graphical Notation Textual Notation «part» part1 : PartDef1 part part1 : PartDef1; Name Compartment - Usage (without and part <'p#2'> part2 : with short name) PartDef2; «part» <'p#2'> part2 : PartDef2 part part1 { part part2 { «part» part part3 : Name Compartment part1::part2::part3 : PartDef3 PartDef3; - Usage } } abstract part part1 : PartDef1; package P { alias partAlias1 «abstract part» for part1; part1 : PartDef1 Name Compartment } «alias» - Usage (abstract) package Q { P::partAlias1, Q::partAlias2 alias partAlias2 for part1; } «variation part» variation part part1 : Name Compartment part1 : PartDef1 PartDef1; - Usage (variation) «variant part» variant part part1 : Name Compartment part1:PartDef1 PartDef1; - Usage (variant) «part» Name Compartment No textual notation. ^part1 : PartDef1 - Inherited Usage «part» part part1S : PartDef1S Name Compartment part1S : PartDef1S [m] [m] - Subsetted Usage subsets part1; subsets part1 part part1R : PartDef1R «part» Name Compartment [m] part1R : PartDef1R[m] - Redefined Usage redefines part1 = redefines part1 = part2 (with binding) part2; Systems Modeling Language v2.0, Part 1 35 -Element Graphical Notation Textual Notation «part def» part def Part2 { Part2 attribute attribute1 attributes : Attribute1; perform action attribute1 : Attribute1 action1 : Action1; perform actions } action1 : Action1 part def Part2S :> Part2 { attribute attribute2 : Attribute2; Subclassification «part def» item item1 : Item1 Part2S [0..*]; attributes } ^attribute1 : Attribute1 or attribute2 : Attribute2 part def Part2S perform actions specializes Part2 { ^action1 : Action1 ... } items item1 : Item1 [0..*] part def Part1 { attribute attribute1 : Attribute1; perform action action1 : Action1; } «part» «part def» part1 Part1 part part1 : Part1 { attributes attributes attribute attribute2 ^attribute1 : Attribute1 attribute1 : Attribute1 : Attribute2; Part defined by Part attribute2 : Attribute2 perform actions part part2 : Part2 Definition perform actions action1 : Action1 [0..*]; ^action1 : Action1 } parts or part2 : Part2 [0..*] part part1 defined by Part1 { ... } 36 Systems Modeling Language v2.0, Part 1 -Element Graphical Notation Textual Notation «part» part1 : Part1 attributes ^attribute1 : Attribute1 attribute2 : Attribute2 part part1 : Part1 { attribute attribute2 perform actions : Attribute2; ^action1 : Action1 part part2 : Part2 [0..*]; parts } part2 : Part2 [0..*] part part1S :> part1 { attribute attribute3 : Attribute3; Subsetting part part3 : Part3 [0..*]; «part» } part1S or attributes ^attribute1 : Attribute1 part part1S ^attribute2 : Attribute2 subsets part1 { ... attribute3 : Attribute3 } perform actions ^action1 : Action1 parts ^part2 : Part2 [0..*] part3 : Part3 [0..*] part part1 : Part1 [0..*] { part part2 : Part2 [0..*]; } «part» «part» part part1S : Part1S [1] part1 : Part1 [0..*] part1S : Part1S [1] :> part1 { part part2R : Part2R :>> part2; Redefinition } «part» «part» or part2 : Part2 [0..*] part2R : Part2R part part1S : Part1S [1] subsets part1 { part part2R : Part2R redefines part2; } Systems Modeling Language v2.0, Part 1 37 -Element Graphical Notation Textual Notation «part def» PartDef1 part def PartDef1 { part part2 : Part2 Feature Membership [0..*]; (isComposite=true) } «part» part2 : Part2 [0..*] «part» part1 : Part1 [0..1] part part1 : Part1 [0..1] { Feature Membership part part2 : Part2 (isComposite=true) [0..*]; } «part» part2 : Part2 [0..*] «part» part1 : Part1 [0..1] part part1 : Part1 [0..1] { Feature Membership ref part part2 : Part2 (isComposite=false) [0..*]; } «part» part2 : Part2 [0..*] «variation part» variation part part1 : part1 : Part1 Part1 { variant part part1a : Part1a; Variant Membership variant part part1b : «variant part» «variant part» Part1b; part1a : Part1a part1b : Part1b } 38 Systems Modeling Language v2.0, Part 1 -Element Graphical Notation Textual Notation variation item itemChoice : ItemDef { variants variant part1; variant item1; part1 } item1 ... or variation item or itemChoice : ItemDef { variants variant part references part1; part references part1 Variants variant item item references item1 Compartment references item1; ... } or or variants variation item itemChoice : ItemDef { part part1 : Part1 variant part part1 : item item1 : Item1 Part1; ... variant item item1 : Item1; } variation part variant parts partChoice : PartDef { variant part part1 : part1 : PartDef1 Variant Parts PartDef1; part2 : PartDef2 Compartment variant part part2 : ... PartDef2; } relationships defines part2 specializes PartDef1 part def PartDef1; ... part def PartDef2 :> PartDef1; part part1 : PartDef1; Relationships part part2 : PartDef2 :> Compartment relationships part1; defined by PartDef2 connect part2 to part3; part part3; subsets part1 connect to part3 ... 7.6.2 Definitions There is a basic common notation for all kinds of definitions, as described here in subclause 7.6 , with additional special notations for certain kinds of definitions described in the later subclauses specifically related to those kinds Systems Modeling Language v2.0, Part 1 39 -of definitions. As a kind of Namespace (see 7.5 ), the representation of a definition includes a declaration and a body. A definition is declared using a keyword specific to the kind of definition (e.g., item , part , action , etc.) followed by the keyword def . One or more owned subclassifications may also optionally be included in the declaration of a definition by giving a comma-separated list of qualified names of the general definitions after the keyword specializes (or the symbol :> ). A definition is specified as abstract by placing the keyword abstract before its kind keyword. abstract part def Vehicle; part def Automobile specializes Vehicle; part def Truck :> Vehicle; A definition that is not abstract is called a concrete definition. Declaring a definition to be abstract means that all instances of the definition must also be instances of at least one concrete definition or usage that directly or indirectly specializes the abstract definition. The body of a definition is specified generically as for any namespace. In the textual notation, this is done by listing the members and imports between curly braces { ... } (see 7.5 ), or alternatively by a semicolon ; if the definition has no members or imports. Usages declared within the body of a definition are owned usages that specify features of the Definition. item def Super { private package N { item def Sub specializes Super; } item f : N::Sub; } 7.6.3 Usages There is a basic common notation for all kinds of usages, as described here in subclause 7.6 , with additional special notations for certain kinds of usage described in the later subclauses specifically related to those kinds of usages. As a kind of namespace (see 7.5 ), the representation of a usage includes a declaration and a body. A usage is declared using a keyword specific to the kind of usage (e.g., item , part , action , etc.). One or more owned specializations may also optionally be included in the declaration of a usage. There are three kinds of specializations relevant to usages: 1. Feature typings specify the definitions of a usage (also known as its types). Textually, they are declared by giving a comma-separated list of the qualified names of the definition elements after the keyword defined by (or the symbol : ). The definitions given must be consistent with the kind of usage being defined. 2. Subsettings specify other usages subsetted by the owning usage. Textually, they are declared by giving a comma-separated list of the qualified names of the subsetted usages after the keyword subsets (or the symbol :> ). 3. Redefinitions specify other usages redefined by the owning usage. Textually, they are declared by giving a comma-separated list of the qualified names of the redefined usages after the keyword redefines (or the symbol :>> ). (Note that redefinition is a kind of subsetting, so the owned redefinitions of a usage will be a subset of the owned subsettings in the abstract syntax.) item x : A, B :> f :>> g; // Equivalent declaration: item x defined by A defined by B subsets f redefines g; 40 Systems Modeling Language v2.0, Part 1 -The multiplicity of a usage can be given in square brackets [ ... ] after the name part of the declaration of a usage (if it is named) or after one of the owned specialization clauses in the declaration (but, in all cases, only one multiplicity may be specified). (This allows for a notation style consistent with previous modeling languages, in which the multiplicity is always placed after the declared type.) A multiplicity range is written in the form [lowerBound..upperBound], where each of lowerBound and upperBound is either a literal or the identification of a usage. Literals can be used to specify a multiplicity range with fixed lower and/or upper bounds. The values of the bounds of a multiplicity range must be natural numbers. If only a single bound is given, then the value of that bound is used as both the lower and upper bound of the range, unless the result is the infinite value * , in which case the lower bound is taken to be 0. If two bounds are given, and the value of the first bound is * , then the meaning of the multiplicity range is not defined. item def Person { ref item parent[2] : Person; ref item mother : Person[1..1] subsets parent; attribute numberOfChildren : Natural; ref item children[0..numberOfChildren] : Person; } item def ChildlessPerson specializes Person { ref item redefines children[0]; } A multiplicity may be optionally followed by one or both of the following keywords (in either order), or they can be used without giving an explicit muiltiplicity, at any place in the declaration a multiplicity would be allowed. • nonunique – If a usage is non-unique, then the same value may appear more than once as a value of the usage. The default is that the usage is unique, meaning that no two values of the usage may be the same. • ordered – If a usage is ordered, then the values of the usage can be placed in order, indexed from 1 to the number of values. The default is that the feature is unordered. If a multiplicity is not declared for a usage, then the usage inherits the multiplicity constraints of any other usages it subsets or redefines. If no tighter constraint is inherited, the effective default is the most general multiplicity [0..*] . However, a tighter default of [1..1] is implicitly declared for the usage if all of the following conditions hold: 1. The usage is an attribute usage, an item usage (including a part usage, except if it is a connection usage), or a port usage. 2. The usage is owned by a definition or another usage (not a package). 3. The usage does not have any explicit owned subsettings or owned redefinitions. There are a number of additional properties of a usage that can be flagged by adding specific keywords to its declaration. If present these are always specified in the following order, before the kind keyword in the usage declaration. 1. in , out , inout – Specifies a directed usage with the indicated direction, which determines what things are allowed to change its values relative to its featuring instance. ◦ in – Things "outside" the featuring instance. These usages identify things input to an instance. ◦ out – The featuring instance itself or things "inside" it. These usages identify things output by an instance. ◦ inout – Both things "outside" and "inside" the featuring instance. These usages identify things that are both input to and output by an instance. 2. derived – Specifies that the usage is derived. Such a feature is typically expected to have a bound value expression that completely determines its value at all times (see also 7.13.3 on binding a usage to a value). 3. abstract – Specifies that the usage is abstract. A usage that is not abstract is called a concrete usage. Similarly to an abstract definition (see 7.6.2 ), declaring a usage to be abstract means that any value of the Systems Modeling Language v2.0, Part 1 41 -usage must also be a value of some concrete usage that directly or indirectly specializes (subsets or redefines) the abstract usage. 4. constant – Specifies that the usage is constant. Values of a constant usage are the same during the entire existence of the featuring instance. Note that this only applies if the featuring instance is an occurrence and the usage is such that its values would otherwise be allowed to vary over time if it was not constrained to be constant (see also 7.9.2 on occurrences and usages with time-varying values). 5. ref – Specifies that the usage is referential. A usage that is not referential is composite. Values of a composite usage, for each featuring instance, cannot exist after the featuring instance ceases to exist. A composite usage must be featured by an occurrence (such as an item, part or action; see 7.9 and following). This only applies to values at the time the instance goes out of existence, not to other things that may have been values of the usage before that, but are not any longer. Values of a composite usage cannot be values of another composite usage unless it is on the same featuring instance. (Note also that a directed usage is always referential, whether or not the keyword ref is also given explicitly in its declaration.) abstract part def Container { abstract ref item content; } part def Tank :> Container { in item fuelFlow : Fuel; ref item fuel : Fuel :>> content; } (See also the discussion of end features in 7.13.2 .) The body of a usage is specified generically as for any namespace. In the textual notation, this is done by listing the members and imports between curly braces { ... } (see 7.5 ), or alternatively by a semicolon ; if it has no members or imports. Usages declared within the body of another Usage are owned (nested) usages that specify features of the owning usage. part vehicle : Vehicle { part wheelAssembly[2] { part axle : Axle; part wheel : Wheel; } } 7.6.4 Reference Usages A reference usage is a usage that is declared without any kind keyword. Unlike other kinds of usages, the definitions (types) of a reference usage are not restricted to be of a particular kind. The declaration of a reference usage may, but is not required, to include the ref keyword. However, a reference usage is always, by definition, referential. A reference usage is otherwise declared like any other usage, as given above. abstract part def Container { abstract ref content : Base::Anything; } part def OrderedContainer { // By default, the following is a reference usage. orderedContent ordered :>> content; } 7.6.5 Effective Names If a name and/or short name are declared for an element, these are used in the name resolution process to identify the element (as discussed in 7.6.1 ). However, if neither a name or a short name are given in the declaration of a usage with an owned redefinition, then its effective name and short name are implicitly determined by the name and short name of the redefining usage of its first owned redefinition (which may itself be an implicit name, if the redefined 42 Systems Modeling Language v2.0, Part 1 -usage is itself a redefining usage). This is useful when redefining a usage in order to constrain it, while maintaining the same naming as for the original usage. part def Engine { part cylinders : Cylinder[2..*]; } part def FourCylinderEngine :> Engine { // This redefines Engine::cylinders with a // new usage, restricting the multiplicity // to 4. It's declared name is empty, // but its effective name is "cylinders". part redefines cylinders[4]; } part def SixCylinderEngine :> Engine { part redefines cylinders[6]; } Certain other kinds of usages (such as perform action usages) specify an alternate effective name rule, as described in the subclauses relevant to those usages (e.g., 7.17.6 describes the rule for perform action usages). 7.6.6 Feature Chains A feature chain is a textual notation specified as a sequence of two or more qualified names separated by dot ( . ) symbols. Each qualified name in a feature chain must resolve to a Usage (or, more generally, a KerML Feature). The first qualified name in a feature chain is resolved in the local namespace as usual (see 7.6.1 ). Subsequent qualified names are then be resolved using the previously resolved usage (feature) as the context namespace, but considering only public memberships. A feature chain is similar to a qualified name but, unlike a qualified name, the path of usages (features) in the chain is recorded in the abstract syntax, not just the reference to the final usages. This means that different paths to the same usage can be distinguished in the abstract syntax representation of a model. Feature chains can be used to specify the target for most kinds of relationships involving usages, including subsetting and redefinition. However, their use is particularly important when specifying the related features of a connection usage that are more deeply nested than the connection usage itself (see 7.13 ). (See also [KerML, 7.3.4.6].) item uncles subsets parents.siblings; item cousins redefines parents.siblings.children; connect vehicle.wheelAssembly.wheels to vehicle.road; In general, when a textual notation is described as including the identification of a usage, this can be done by using either a qualified name or a feature chain. 7.6.7 Variations and Variants A definition or usage is specified as a variation by placing the keyword variation before its kind keyword. A variation is always abstract, so the abstract keyword is not used on a variation. All usages declared within the body of a variation definition or usage are declared as variant usages by placing the keyword variant at the beginning of their declarations. Variant usages may only be declared within a variation. The kind of a variant usage must be consistent with the kind of its owning variation. variation part def TransmissionChoices :> Transmission { variant part manual : ManualTransmission; variant part automatic : AutomaticTransmission; } A non-variant usage can also be declared to act as a variant of a variation by not including a kind keyword in the variant declaration and, instead, following the variant keyword with the identification of a separately declared Systems Modeling Language v2.0, Part 1 43 -usage. Such a variant declaration may also optionally further constrain the variant usage by including a multiplicity and/or further specializations. // These are non-variant usages. part smallEngine : FourCylinderEngine; part bigEngine : SixCylinderEngine; part def Vehicle { variation part engine : Engine { // These are variant usages within the variation part "engine", // based on the referenced non-variant usages. variant smallEngine; variant bigEngine; } } 7.6.8 Implicit Specialization The meaning or semantics of a definition is given by what things it classifies relative to the system being modeled. Specific kinds of definitions are already restricted to classifying specific kinds of things. E.g., an attribute definition classifies attributive values, a part definition classifies systems and parts of systems, etc. The Systems Model Library (see 9.2 ), which is based on the KerML Kernel Semantic Library (see [KerML, 9.2]) is a set of ontological SysML models that define the basic kinds of things relevant for systems modeling. The semantics of definition elements in SysML is given by requiring that each such element (directly or indirectly) specialize the corresponding base definition from the Systems Model Library (or base classifier from the Kernel Semantic Library) corresponding to its kind. At the highest level, every definition element must directly or indirectly specialize the most general classifier Anything from the Base model in the Kernel Semantic Library (see [KerML, 9.2.2]). Specific kinds of definition then have more specific requirements for what more specific base definition they must specialize. For example, an attribute definition must specialize the base attribute definition AttributeValue from the Attributes model in the Systems Model Library, while a part definition must specialize the base part definition Part from the Parts model. The Systems Model Library also includes a parallel hierarchy of base usages (or base features in the Kernel Semantic Library). So, every usage element must directly or indirectly specialize (subset) the most general feature things from the from the Base model in the Kernel Semantic Library. And specific kinds of usage then also have more specific requirements for what more specific base usage they must specialize. For example, an attribute usage must subset the base attribute usage attributeValues from the Attributes model in the Systems Model Library, while a part usage must subset the base part usage parts from the Parts model. In general, each base usage is defined by the corresponding base definition. E.g., the base usage parts is defined by the base definition Part , so that every part usage is ultimately a direct or indirect usage of Part . These and other semantic constraints are fully described in 8.4 . However, it is not generally necessary for a modeler to explicitly satisfy these constraints when constructing a model. Rather, the violation of a semantic constraint implies the need for a specific relationship, which may then be added to the model automatically by tooling (see also [KerML, 8.4.2]). In particular, if a definition or usage, as explicitly declared, does not directly or indirectly specialize the required base definition or usage, then the declaration is considered to include an implicit subclassification or subsetting of the appropriate base definition or usage. attribute def A; // Implicitly subclassifies Attributes::AttributeValue. part def P { // Implicitly subclassifies Parts::Part. ref x; // Implicitly subsets Base::things. attribute a : A; // Implicitly subsets Attributes::attributeValues. part p; // Implicitly subsets Parts::parts. part q :> p; // No implicit specialization. 44 Systems Modeling Language v2.0, Part 1 -} part def Q :> P; // No implicit specialization. 7.7 Attributes 7.7.1 Attributes Overview Metamodel references: • Textual notation, 8.2.2.7 • Graphical notation, 8.2.3.7 • Abstract syntax, 8.3.7 • Semantics, 8.4.3 An attribute definition defines a set of data values, such as numbers, quantitative values with units, qualitative values such as text strings, or data structures of such values. An attribute usage is a usage of an attribute definition. An attribute usage is always referential and any nested features of an attribute definition or usage must also be referential (see also 7.6 on referential and composite usages). The data values of an attribute usage are constrained to be in the range specified by its definition. The range of data values for an attribute definition can be further restricted using constraints (see 7.20 ). An enumeration definition is a specialized kind of attribute definition that further restricts the values of the data type to a discrete set of data values (see 7.8 ). Attribute usages can be defined by KerML data types as well as SysML attribute definitions. This allows them to be typed by primitive data types from the Kernel Data Type Library (see [KerML, 9.3]), such as String , Boolean , and numeric types including Integer , Rational , Real and Complex . The Kernel Data Type Library also includes basic structured data types for collections. Attribute usages representing quantities with units are defined using the SysML Quantities and Units Domain Library or extensions of the elements in this library (see 9.8 ). The library provides base attribute definitions for scalar, vector and tensor quantity values, along with other models that specify the full set of international standard quantity kinds and units. Fundamental to this approach is the principle that only the kind of unit (e.g., MassUnit , LengthUnit , TimeUnit , etc.) is associated with an attribute definition, while a specific unit (e.g., kg , m , s , etc.) is only given with an actual quantity value. This means that an attribute usage for a quantity value is independent of the specific units used, allowing for automatic conversion and interoperability between different units of the same kind (e.g., kilograms and pounds mass, meters and feet, etc.). The values of an attribute usage are data values, whether primitive values like integers or structured values with nested attributes, that do not themselves change over time. However, the owner of an attribute usage may be an occurrence definition or usage (or a specialized kind of occurrence, such as an item, part or action). In this case, the value of the attribute usage may vary over the lifetime of its owning occurrence, in the sense that it can have different values at different points in time, reflecting the changing condition of the occurrence over time. (See also the discussion in 7.9 .) Systems Modeling Language v2.0, Part 1 45 -Table 5. Attributes – Representative Notation Element Graphical Notation Textual Notation «attribute def» AttributeDef1 attribute def AttributeDef1; «attribute def» attribute def Attribute Definition AttributeDef1 { AttributeDef1 /* members */ compartment stack } ••• «attribute» attribute attribute1 : attribute1 : AttributeDef1 AttributeDef1; attribute attribute1 : «attribute» Attribute AttributeDef1 { attribute1 : AttributeDef1 /* members */ } compartment stack ••• attributes ^attribute2 : AttributeDef2 attribute1 : AttributeDef1 [1..*] ordered nonunique attribute3R : AttributeDef3R redefines attribute3 { attribute4R : AttributeDef4R :>> attribute5 attribute attribute1 : :>> attribute5 AttributeDef1 attribute6S : AttributeDef6S [m] subsets attribute6 [1..*] Attributes ordered nonunique; attribute7S : AttributeDef7S [m] :> attribute7 Compartment /* ... */ attribute8 : AttributeDef8 = expression1 } attribute10 : AttributeDef10 := expression2 /attribute12 readonly attribute13 abstract attribute14 ... 7.7.2 Attribute Definitions and Usages An attribute definition is declared as described in 7.6.2 , using the kind keyword attribute . An attribute definition may only specialize other attribute definitions (including enumeration definitions) or KerML data types (see [KerML, 7.4.2]). An attribute usage may be declared as described in 7.6.3 , using the kind keyword attribute . An attribute usage may only be defined by attribute definitions or KerML data types. (See also 7.8 on enumeration definitions and enumeration usages. An attribute usage is always referential, whether or not the ref keyword (see 7.6.3 ) is used explicitly in its declaration. The default multiplicity of an attribute usage is [1..1] , under the conditions described in 7.6.3 . In general, any kind of usage may be declared in the body of an attribute definition or attribute usage, but all such usages shall be referential. (There are further restrictions on what can be nested in an enumeration definition – see 7.8 .) 46 Systems Modeling Language v2.0, Part 1 -attribute def SensorRecord { ref part sensor : Sensor; attribute reading : Real; } The base attribute definition is AttributeValue from the Attributes library model (see 9.2.2 ), which is simply an alias for the data type DataValue from the KerML Base library model (see [KerML, 9.2.2]). The base attribute usage is attributeValues from the Attributes library model, which is simply an alias for the feature dataValues from the KerML Base library model. 7.8 Enumerations 7.8.1 Enumerations Overview Metamodel references: • Textual notation, 8.2.2.8 • Graphical notation, 8.2.3.8 • Abstract syntax, 8.3.8 • Semantics, 8.4.4 An enumeration definition is a kind of attribute definition (see 7.7 ) whose instances are limited to specific set of enumerated values. An enumeration usage is an attribute usage that is required to have a single definition that is an enumeration definition. An enumeration usage is restricted to only the set of enumerated values specified in its definition. Since an enumeration definition is a kind of attribute definition, it can also be used to define a regular attribute usage. Even if the attribute usage is not syntactically an enumeration usage, it is still semantically restricted to take on only the values allowed by its enumeration definition. An enumeration definition can specialize an attribute definition that is not itself an enumeration definition. In this case, the enumerated values of the enumeration definition will be a subset of the attribute values of the specialized attribute definition. Which enumerated values correspond to which attribute values may be specified by binding the enumerated values to expressions that evaluate to the desired values of the specialized attributed definition (see also 7.13 on binding usages to values). In this case, the results of all the expressions must be distinct (typically they will just be literals). For example, an enumeration definition DiameterChoices may specialize the attribute definition LengthValue . DiameterChoices may include literals that are equal to 60 mm, 80 mm, and 100 mm. An attribute usage called cylinderDiameter can be defined by DiameterChoices , and its value can equal one of the three enumerated values. An enumeration definition may not contain anything other than the declaration of its enumerated values. However, if the enumeration definition specializes an attribute definition with nested usages, then those nested usages will be inherited by the enumeration definition, and they may be bound to specific values within each enumerated value of the enumeration definition. An enumeration definition may not specialize another enumeration definition. This is because the semantics of specialization require that the set of instances classified by a definition be a subset of the instances of classified by any definition it specializes. The enumerated values defined in an enumeration definition, however, would add to the set of enumerated values allowed by any enumeration definition it specialized, which is inconsistent with the semantics of specialization. Systems Modeling Language v2.0, Part 1 47 -Table 6. Enumerations – Representative Notation Element Graphical Notation Textual Notation «enumeration def» EnumerationDef1 enum def EnumerationDef1; Enumeration «enumeration def» enum def EnumerationDef1 Definition { EnumerationDef1 /* members */ compartment stack } ••• enum def EnumerationDef1 { enum enum1; enum enum2; enums } enum1 Enums Compartment enum2 or ... enum def EnumerationDef1 { enum1; enum2; } enum def EnumerationDef1 { enum = value1 [unit1]; enum = value2 enums [unit2]; = value1 [unit1] } Enums Compartment = value2 [unit2] ... or enum def EnumerationDef1 { = value1 [unit1]; = value2 [unit2]; } 7.8.2 Enumeration Definitions and Usages An enumeration definition is declared as described in 7.6.2 , using the kind keyword enum , with the additional restrictions described below. As a kind of attribute definition, an enumeration definition may generally subclassify other attribute definitions or KerML data types. However, an enumeration definition must not subclassify another enumeration definition. An enumeration usage is declared as described in 7.6.3 , using the kind keyword enum . Any owned members declared in the body of an enumeration definition must be enumeration usages, which are the enumerated values of the enumeration definition. An enumeration definition is always considered to be a variation and its enumerated values are its variants. The keywords abstract and variation may not be used with an enumeration definition. The declaration of an enumeration usage as an enumerated value of an enumeration definition may not include the keyword variant nor any of the other property keywords given in 7.6.3 (i.e, any direction keywords, abstract , derived , etc.). 48 Systems Modeling Language v2.0, Part 1 -Since the body of an enumeration definition may only declare enumeration usages, the declaration of an enumerated value may omit the enum keyword. An enumerated usage declared as an enumerated value is considered to be implicitly defined by its owning enumeration definition and, therefore, may not have any explicitly declared definition other than that enumeration definition (and need not have any explicitly declared definition at all). enum def ConditionColor { red; green; yellow; } attribute def ConditionLevel { attribute color : ConditionColor; } enum def RiskLevel :> ConditionLevel { enum low { :>> color = ConditionColor::green; } enum medium { :>> color = ConditionColor::yellow; } enum high { :>> color = ConditionColor::red; } } There are no special restrictions on the declaration of an enumeration usage outside the body of an enumeration definition, other than as for an attribute usage in general (see 9.2.2 ), except that such an enumeration usage must be explicitly defined by a single enumeration definition. As a kind of attribute usage, an enumeration usage is always referential, whether or not ref is included in its declaration, and all the nested usages of an enumeration usage must also be referential. enum assessedRisk : RiskLevel { // The following feature is added for this usage. // It is legal, since all attribute usages are // referential. attribute assessment : String; } 7.9 Occurrences 7.9.1 Occurrences Overview Metamodel references: • Textual notation, 8.2.2.9 • Graphical notation, 8.2.3.9 • Abstract syntax, 8.3.9 • Semantics, 8.4.5 Occurrences An occurrence definition is a definition of a class of occurrences that have an extent in time and may have spatial extent. An occurrence usage is a usage of an occurrence definition. The extent of an occurrence in time is known as its lifetime, which covers the period in time from the occurrence's creation to its destruction. An occurrence maintains its identity over its lifetime, while the values of its features may change over time. The lifetime of an occurrence begins when the identity of the occurrence is established, and the the lifetime ends when the occurrence loses its identity. For example, the lifetime of a car could begin when it leaves the production-line, or when a vehicle identification number is assigned to the car. Similarly, the lifetime of a car could end when the car is disassembled or demolished. The performance of a behavior is also an occurrence that takes place over time. The lifetime of a behavior performance begins at the start of the performance and ends when the performance is completed. Structural and behavioral occurrences are often related. For example, a machine on an automobile assembly line, during its lifetime, will repeatedly perform a behavioral task, each performance of which has its own respective lifetime, which then affects the construction of some car being assembled on the line. Systems Modeling Language v2.0, Part 1 49 -If an occurrence definition or usage has nested composite features, then those features must also be usages of occurrence definitions (including the various specialized kinds of occurrences, such as parts, items and actions). If an occurrence has values for any composite features at the end of its lifetime, then the lifetime of those composite values must also end. However, if a composite suboccurrence is removed from its containing occurrence before the end of the lifetime of the containing occurrence, then the former suboccurrence can continue to exist. For example, if a wheel is attached to a car when the car is destroyed, then the wheel is also destroyed. However, if the wheel is removed before the car is destroyed, then the wheel can continue to exist even after the car is destroyed. Values of a composite feature cannot be values of another composite feature except on the same containing occurrence. (See also 7.6 on referential and composite usages.) Time Slices and Snapshots The lifetime of an occurrence can be partitioned into time slices which correspond to some duration of time. These time slices represent periods or phases of a lifetime, such as the deployment or operational phase. Time slices can be further partitioned into other time slices. For example, the lifetime of a car might be divided into time slices corresponding to its assembly, being in inventory before being sold, and then sequential periods of ownership with different owners. A time slice with zero duration is a snapshot. Start, end and intermediate snapshots can be defined for any time slice to represent particular instants of time in an occurrence's lifetime. For example, the start snapshot of each ownership time slice of a car corresponds to the sale of the car to a new owner, which happens at the same time as the end snapshot of the previous ownership (or inventory) time slice. Individuals Any kind of occurrence definition can be restricted to define a class that represents an individual, that is, a single real or perceived object with a unique identity. For example, consider the part definition Car modeling the class of all cars (parts are kinds of items which are kinds of occurrences, see 7.11 ). An individual car called Car1 with a unique vehicle identification number can then be modeled as an individual part definition that is a subclassification of the general part definition Car . As such, Car1 inherits all the features of Car (such as its parts engine , transmission , chassis , wheels , etc.), but has individual values for each of those features (individual engine , individual transmission , individual chassis , four individual wheels , etc.), each of which is itself a uniquely identifiable subclassification of a more general part definition ( Engine , Transmission , Chassis , Wheel , etc.). An occurrence usage can also be restricted to be the usage of a single individual. In this case, exactly one of the definitions of the occurrence usage must be an occurrence definition for that individual. Such an individual usage can be used to model a role that an individual plays for some period of time. For example, the individual part definition Car1 can be used in different contexts, such as the usage of Car1 when it is in for service and the usage of Car1 when it is used for normal operations. Let car1InService be the usage of Car1 when it is in for service to have its tires rotated. For this usage, car1InService has four wheels that play different roles, including front- left, front-right, rear-left, and rear-right. The four wheels of Car1 are individual Wheel usages defined by the individual definitions Wheel1 , Wheel2 , Wheel3 , and Wheel4 . Each of these individual definitions is a subclassification of Wheel . When car1InService enters the shop, the front-left wheel individual usage is initially defined by the individual definition Wheel1 , but after the tires are rotated, the front-left wheel is defined by the individual definition Wheel2 . The lifetime of an individual and any of its time slices can be actual or projected. For example, the individual car Car1 may be purchased as a used car. Car1 has had an actual lifetime up to that time. A mechanic may perform diagnostics and obtain some measurements, and may estimate the remaining life of the car or its parts based on the measurements. For example, the mechanic may estimate the remaining lifetime of the tires, based on the tread measurements and the estimated tire wear rate. At a given point in time, the condition of an individual (sometimes called its "state", which should not be confused with a behavioral state usage, as described in 7.18 ) can be specified by the values of its attributes. As an example, the condition of car1inOperation at different points in time can be specified in terms of its acceleration , velocity , and position . In addition, its finite (i.e., discrete) state (in the sense that can be modeled with state 50 Systems Modeling Language v2.0, Part 1 -definitions and usages, see 7.18 ) can be specified at different points in time as off or on , and any nested state such as forward or reverse . The condition of the car can continue to change over its lifetime, and can be specified as a function of discrete and/or continuous time. Events An event is a reference from one occurrence to another occurrence that represents some relevant happening during the lifetime of the first occurrence. Such an event model makes no commitment as to how the event actually happens. Different specializations of the containing occurrence may realize the modeled event in different ways. In particular, occurrences may collaborate by transferring information between each other via messages (see 7.16 ). The sending of such a message is an event in the lifetime of the sending occurrence, while the receipt of such a message is an event in the lifetime of the receiving occurrence. These events can possibly be realized as the performance of a send action and corresponding accept action, respectively, with the message being the resulting transfer between them (see 7.17 ). However, it could also be realized as the start and end of an explicitly modeled flow (see 7.16 on flows and messages). Table 7. Occurrences – Representative Notation Element Graphical Notation Textual Notation «occurrence def» OccurrenceDef1 occurrence def OccurrenceDef1; Occurrence «occurrence def» occurrence def Definition OccurrenceDef1 { OccurrenceDef1 /* members */ compartment stack } ••• «occurrence» occurrence occurrence1 : occurrence1 : OccurrenceDef1 OccurrenceDef1; «occurrence» occurrence occurrence1 : Occurrence OccurrenceDef1 { occurrence1 : OccurrenceDef1 /* members */ compartment stack } ••• «occurrence def» OccurrenceDef1 Individual individual def 'OccurrenceDef1-1' Occurrence :> OccurrenceDef1; Definition «individual occurrence def» 'OccurrenceDef1-1' Systems Modeling Language v2.0, Part 1 51 -Element Graphical Notation Textual Notation «occurrence» individual occurrence1 : OccurrenceDef1; occurrence1 : OccurrenceDef1 individual def 'OccurrenceDef1-1' :> Individual OccurrenceDef1; Occurrence individual 'occurrence1-1' : «individual occurrence» 'OccurrenceDef1-1' :> 'occurrence1-1' : 'OccurrenceDef1-1' occurrence1; individual part «individual part» individual1 : individual1 : Individual1 Individual1 { timeslice timeslice1 { Time Slices, snapshot «timeslice» «timeslice» Snapshots and snapshot1; timeslice1 timeslice2 Portion Membership snapshot snapshot2; } «snapshot» «snapshot» timeslice timeslice2; snapshot1 snapshot2 } «part» part1 event occurrence event1; Event Occurrence part part1 { «event» Usage (shorthand event event1; notation) } «event occurrence» event1 52 Systems Modeling Language v2.0, Part 1 -Element Graphical Notation Textual Notation occurrences ^occur2 : OccurDef2 occur1 : OccurDef1 [1..*] ordered nonunique occur3R : OccurDef3R redefines occur3 occur4R : OccurDef4R :>> occur4 :>> occur5 { occur6S : OccurDef6S [m] subsets occur6 occurrence occur1 : occur7S : OccurDef7S [m] :> occur7 OccurDef [1..*] ordered nonunique; Occurrences occur8R = occur8 /* ... */ Compartment ref occur9 : OccurDef9 occur 10 } /occur11 readonly occur12 abstract occur13 ... individual parts ^part2 : PartDef2_1 part1 : PartDef1_1 [1..*] ordered nonunique part3R : PartDef3R_1 redefines part3 { individual part part1 part4R : PartDef4R_1 :>> part4 : :>> part5 PartDef1_1 [1..*] part6S : PartDef6S_1 [m] subsets part6 Individuals ordered nonunique; part7S : PartDef7S_1 [m] :> part7 Compartment (parts) /* ... */ part8R_1 = part8 } ref part9 : PartDef9_1 part10 ... timeslices part part1 { phase1 timeslice phase1; Timeslices phase2 timeslice phase2; Compartment /* ... */ ... } snapshots part part1 { snapshot1; snapshot snapshot1; snapshot2; snapshot snapshot2; Snapshots snapshot snapshot3; snapshot3; Compartment /* ... */ ... } Systems Modeling Language v2.0, Part 1 53 -7.9.2 Occurrence Definitions and Usages An occurrence definition or usage (that is not of a more specialized kind) can be declared as described in 7.6.2 and 7.6.3 , using the kind keyword occurrence . An occurrence usage may only be defined by occurrence definitions (of any kind) or KerML classes (see [KerML, 7.4.3]). occurrence def Flight { ref part aircraft : Aircraft; } Unlike the features of attribute definitions and usages (see 7.7 ), the features of an occurrence definition or usage may have values that vary over the lifetime of a featuring occurrence. Such variability may be, for example, the result of the binding of a feature to another feature with a varying value (see 7.13.3 ), a flow of values into or out of a feature (see 7.16 ), or an explicit assignment of values to a feature (see 8.2.2.17.5 ). However, the following kinds of features do not vary over time in this way, and, instead, have values relative to the entire duration of the featuring occurrence: 1. Time slices and snapshots, because they represent specific portions of the duration of their featuring occurrences (see 7.9.3 ). 2. Bindings, because they reflect relationships that can hold across time (see 7.13.3 and 7.13.4 ). 3. Successions, because they determine ordering of occurrences across time (see 7.13.5 ). 4. Composite subactions, because their values and ordering across time are determined by succession relationships and other control constructs (see 7.17 on actions and 7.18 on states). action def ChangeAircraft { in flight : Flight; in newAircraft : Aircraft; // This assignment changes the aircraft for the given flight. assign flight.aircraft := newAircraft; } A feature that would otherwise be allowed to vary in time may be declared to nevertheless have a constant value using the constant keyword (see 7.6.3 ). Such a feature must have the same value over the entire duration of a featuring occurrence. occurrence def ApprovedFlight :> Flight { // This redefines the aircraft feature so it is constant for // an entire ApprovedFlight. constant ref part approvedAircraft redefines aircraft; } The base definition for occurence definitions is the class Occurrence from the Occurrences model in the Kernel Semantic Library (see [KerML, 9.2.4]). The base usage for occurrence usages is the feature occurrences from the Occurrences model. 7.9.3 Time Slices and Snapshots An occurrence usage (of any kind) can be declared as a time slice or a snapshot using the keyword timeslice or snapshot , respectively, placed immediately before the kind keyword of the declaration (after any of the other usage property keywords described in 7.6.3 ). Alternatively, timeslice or snapshot may be used in place of the kind keyword, in which case the declaration is equivalent to timeslice occurrence or snapshot occurrence (that is, an occurrence usage not of a more specialized kind, but declared as a time slice or snapshot, respectively). A time slice or snapshot usage must be declared in the body of an occurrence definition or usage (of any kind). If it is declared in the body of an occurrence definition, then it represents a portion of the instances of the containing occurrence definition. If it is declared in the body of another occurrence usage, then it represents a portion of the instances of the definition(s) of that containing usage. Note that it is allowable to declare a time slice or snapshot 54 Systems Modeling Language v2.0, Part 1 -usage within a time slice usage. However, it is not generally useful to declare a time slice or snapshot usage within a snapshot usage, since a snapshot is, by definition, without duration. occurrence def Flight { ref part aircraft : Aircraft; // The following are time slices of Flight. timeslice preflight; timeslice inflight; timeslice postflight; } part aircraft : Aircraft { // The following are snapshots of the part aircraft. snapshot part aircraftTakeOff; snapshot part aircraftLanding; } 7.9.4 Individual Definitions and Usages An occurrence definition (of any kind) can be declared as an individual definition using the keyword individual , placed immediately before the kind keyword of the declaration. Alternatively, individual may be used in place of the kind keyword, in which case the declaration is equivalent to individual occurrence (that is, an occurrence usage not of a more specialized kind, but representing an individual). individual def Flight_248 :> Flight; individual part def TestPlane_1 :> Aircraft; An occurrence usage (of any kind) is considered to be an individual usage if it has a definition that is an individual definition. An occurrence usage must not have more than one definition that is an individual definition. An occurrence usage may also be explicitly declared to be an individual usage using the keyword individual , placed after any of the other usage property keywords described in 7.6.3 , but before a timeslice or snapshot keyword (if any). In this case, the occurrence usage must have exactly one definition that is an individual definition. If the declaration of an occurrence usage includes the the keyword individual (and, possibly, timeslice or snapshot ), but no kind keyword, then this is equivalent to having included the occurrence keyword (that is, an occurrence isage not of a more specialized kind, but representing an individual, and, possibly, a time slice or snapshot). individual flightRecord : Flight_248 { individual part redefines aircraft : TestPlane_1; individual timeslice redefines preflight; individual timeslice redefines inflight; individual timeslice redefines postflight; } 7.9.5 Event Occurrence Usages An event occurrence usage is declared like an occurrence usage, as described in 7.9.2 , 7.9.3 , and 7.9.4 , but using the kind keyword event occurrence instead of just occurrence . It is related to another occurrence usage, representing the occurring event, by a reference subsetting relationship, which is a special kind of subsetting relationship specified using the keyword references or the symbol ::> . Or, if the event occurrence usage has no such reference subsetting, then the referenced event occurrence is the event occurrence usage itself. part client { event occurrence request[1] references subscriptionMessage.source; event occurrence delivery[*] ::> publicationMessage.target; } Systems Modeling Language v2.0, Part 1 55 -An event occurrence usage may also be declared using just the keyword event instead of event occurrence . In this case, the declaration does not include either a name or a short name. Instead, the referenced event occurrence of the event occurrence usage is identified by giving a qualified name or feature chain immediately after the event keyword. part client { event subscriptionMessage.source[1]; event publicationMessage.target[*]; } The ref keyword may be used in the declaration of an event occurrence usage, but an event occurrence usage is always referential, whether or not ref is included in its declaration. 7.10 Items 7.10.1 Items Overview Metamodel references: • Textual notation, 8.2.2.10 • Graphical notation, 8.2.3.10 • Abstract syntax, 8.3.10 • Semantics, 8.4.6 An item definition is a kind of occurrence definition (see 7.9 ) that defines a class of identifiable objects that may be acted on over time, but which do not necessarily perform actions themselves. An item usage is a usage of one or more item definitions. Item usages can be used to represent inputs and outputs to actions such as water, fuel, electrical signals and data. Item usages, such as fuel, may flow through a system and be stored by a system. An item may have attributes (see 7.7 ), states (see 7.18 ), and nested item usages. An item that performs actions is normally modeled as a part (see 7.11 ). All parts are items, but not all items are necessarily parts. An item may also be considered to be a part during some time slices of its lifetime but not others. For instance, an engine being assembled can be modeled as an item moving along an assembly line. However, once the engine assembly is completed, the engine can be considered to be a part that may be installed into a car, where it is expected to perform the action providing power to propel the car. But later it may be removed from the car and again be considered only an inactive item in a junkyard. Items may also have an extent in space as well as time. The shape of an item is its boundary in three-dimensional space. Items without shapes are closed enabling them to be boundaries of other items (for example, a two- dimensional sphere has no boundary, but it is the shape of a three-dimensional ball). The Geometry Domain Library (see 9.7 ) includes a model of basic kinds of geometric shapes that can be composed to construct compound spatial items. An item can also identify other items as enveloping shapes, which are closed items that are the boundary of a hypothetical item occupying the same or larger space as the enveloped item. Some of these can be bounding shapes, which overlap the bounded item on all sides. The spatial boundaries of items can break into separate closed items, such as the inside and outside of an egg shell. These inner boundaries can be the boundary of a hypothetical item, the interior of which is a void of the item. Items with no voids are solid. 56 Systems Modeling Language v2.0, Part 1 -Table 8. Items – Representative Notation Element Graphical Notation Textual Notation «item def» ItemDef1 item def ItemDef1; «item def» item def ItemDef1 { Item Definition /* members */ ItemDef1 } compartment stack ••• «item» item1 : ItemDef1 item item1 : ItemDef1; «item» item item1 : ItemDef1 { Item /* members */ item1 : ItemDef1 } compartment stack ••• items ^item2 : ItemDef2 item1 : ItemDef1 [1..*] ordered nonunique item3R : ItemDef3R redefines item3 item4R : ItemDef4R :>> item4 { item item1 : :>> item5 ItemDef1 [1..*] item6S : ItemDef6S [m] subsets item6 ordered nonunique; Items Compartment item7S : ItemDef7S [m] :> item7 /* ... */ item8R = item8 ref item9 : itemDef9 } item10 ... 7.10.2 Item Definitions and Usages An item definition or usage (that is not of a more specialized kind) is declared as a kind of occurrence definition or usage (see 7.9.2 ), using the kind keyword item . An item usage must only be defined by item definitions (of any kind) or KerML structures (see [KerML, 7.4.4]). The default multiplicity of an item usage is [1..1] , under the conditions described in 7.6.3 . item def Fuel { attribute pressure : PressureValue; ref item impurities[0..*] : Material; } Systems Modeling Language v2.0, Part 1 57 -The base item definition and usage are Item and items from the Items library model (see 9.2.3 ). (For other semantic constraints on item usages, see 8.4.6 ). 7.11 Parts 7.11.1 Parts Overview Metamodel references: • Textual notation, 8.2.2.11 • Graphical notation, 8.2.3.11 • Abstract syntax, 8.3.11 • Semantics, 8.4.7 A part definition represents a modular unit of structure such as a system, system component, or external entity that may directly or indirectly interact with the system. A part definition is a kind of item definition (see 7.10 ) and, as such, defines a class of part objects that are occurrences with temporal (and possibly spatial) extent. A part usage is a kind of item usage that is a usage of one or more part definitions, but may also be a usage of item definitions that are not part definitions. This allows a part to be treated like an item in some cases (e.g., when an engine under assembly flows through an assembly line) and as a part in other cases (e.g., when an assembled engine is installed in a vehicle). A system is modeled as a composite part, and its part usages may themselves have further composite structure. The parts of a system may have attributes (see 7.7 ) that represent different performance, physical and other quality characteristics. The parts may have ports (see 7.12 ) that define the points at which those parts may be interconnected (see 7.13 and 7.14 ). Parts may also perform actions (see 7.17 ) resulting in items flowing across the connections between them, and exhibit states (see 7.18 ) that enable different actions. A part can represent any level of abstraction, such as a purely logical component without implementation constraints, or a physical component with a part number, or some intermediate abstraction. Parts can also be used to represent different kinds of system components such as hardware components, software components, facilities, organizations, or users of a system. Table 9. Parts – Representative Notation Element Graphical Notation Textual Notation «part def» PartDef1 part def PartDef1; «part def» part def PartDef1 { Part Definition /* members */ PartDef1 } compartment stack ••• 58 Systems Modeling Language v2.0, Part 1 -Element Graphical Notation Textual Notation «part» part1 : PartDef1 part part1 : PartDef1; «part» part part1 : PartDef1 { Part /* members */ part1 : PartDef1 } compartment stack ••• part part1 { port p0 : PortDef0 { p4 : PortDef4 p1 : PortDef1 port p1 : PortDef1; 0 f port p2 : e D p2 : PortDef2 t PortDef2; «part» r Part with Ports o port p3 : P part1 : PortDef3; 0 p3 : PortDef3 } p p5 : PortDef5 port p4 : PortDef4; port p5 : PortDef5; } part part1 : Part1{ port p1 : P1Def; port p6 : P6Def; «part» Part with Graphical part1 : Part1 part part2:Part2; Compartment part part3:Part3; showing a standard «part» «part» part2 : Part2 part3 : Part3 interconnection view p1 : P1Def p6 : P6Def bind p1 = part2.p2; p2 : P2Def p3 : P3Def p4 : P4Def p5 : P5Def of part1. connect part2.p3 to part3.p4; bind part2.p5 = p6; } «part» Part performs an part part0 { part0 action (action1) that perform action action1; it owns as well as a «perform» perform action2; reference-subsetted } action (action2) that «perform action» «action» action action2; is declared elsewhere action1 action2 Systems Modeling Language v2.0, Part 1 59 -Element Graphical Notation Textual Notation action action3 : «part» Part performs an Action3; part0 action (action1) that part part0 { explicitly reference- perform action subsets another, action1 references differently-named «perform action» «action» action3; action (action3) action1 action3 : Action3 } «part» part2 : PartDef2 action flow Part with Graphical part part2 : PartDef2 { Compartment with perform action perform actions and «perform action» action2; flows between them. then perform action action2 This is informally action3; referred to as a swim } lane. «perform action» action3 parts ^part2 : PartDef2 part1 : PartDef1 [1..*] ordered nonunique part3R : PartDef3R redefines part3 { part4R : PartDef4R :>> part4 part part1 : :>> part5 PartDef1 [1..*] part6S : PartDef6S [m] subsets part6 ordered nonunique; Parts Compartment part7S : PartDef7S [m] :> part7 /* ... */ part8R = part8 } ref part9 : PartDef9 part10 ... 7.11.2 Part Definitions and Usages A part definition or usage (that is not of a more specialized kind) is declared as a kind of occurrence definition or usage (see 7.9.2 ), using the kind keyword part . As a kind of item usage (see 7.10 ), a part usage must only be defined by item definitions (including part definitions) or KerML structures (see [KerML, 7.4.4]). The default multiplicity of a part usage is [1..1] , under the conditions described in 7.6.3 . item def Person; part def Vehicle { 60 Systems Modeling Language v2.0, Part 1 -ref part driver[0..1] : Person; part engine : Engine; part wheels[4] : Wheel; } The base part definition and usage are Part and parts from the Parts library model (see 9.2.4 ). (For other semantic constraints on part usages, see 8.4.7 ). Note. Because the base usage of a part usage is the part usage parts defined by the base part definition Part , every part usage is always directly or indirectly defined by at least one part definition, implicitly if not explicitly, in addition to any other item definitions. 7.12 Ports 7.12.1 Ports Overview Metamodel references: • Textual notation, 8.2.2.12 • Graphical notation, 8.2.3.12 • Abstract syntax, 8.3.12 • Semantics, 8.4.8 A port definition is a kind of occurrence definition (see 7.9 ) that defines a connection point to enable interactions between occurrences (most commonly parts). A port usage is a kind of occurrence usage definition that is a usage of a port definition. A port usage may be connected to one or more other port usages (see 7.14 ). Such connections enable interactions between the occurrences that own the ports. The features of the port usages (whether inherited from its definition or declared locally for the usage) specify what can be exchanged in such interactions. Since ports are themselves kinds of occurrences, port definitions and usages can contain nested port usages. A feature of a port may be directed, with one of the directions in , out , or inout (see also 7.6.3 ). Flows nested in a connection between ports may be used to model transfers between matching directed features of the ports (see 7.16 ). Two features match if they have conforming definitions and either both have no direction or they have conjugate directions. The conjugate of direction in is out and vice versa, while direction inout is its own conjugate. A transfer can occur from the out features of one port usage to the matching in features of connected port usages. Transfers can occur in both directions between matching inout features. Two ports are said to conform if each feature of one port has a matching feature on the other port. In this case, if the two ports are connected, it is possible to have a flow between every directed feature of one port and the matching feature on the other port. Bindings can also be used to relate features of connected ports (see 7.13.3 ). Each port definition has a conjugated port definition whose directed features are conjugate to those of the original port definition. A conjugated port usage is a usage of a conjugated port definition. A conjugated port usage automatically conforms to a usage of the corresponding original port definition. Systems Modeling Language v2.0, Part 1 61 -Table 10. Ports – Representative Notation Element Graphical Notation Textual Notation «port def» PortDef1 port def PortDef1; «port def» port def PortDef1 { Port Definition /* members */ PortDef1 } compartment stack ••• «port» port1 : PortDef1 port port1 : PortDef1; «port» port port1 : PortDef1 { Port /* members */ port1 : PortDef1 } compartment stack ••• ports ^port2 : PortDef2 port1 : PortDef1 [1..*] ordered nonunique port3R : PortDef3R redefines port3 port4R : PortDef4R :>> port4 { :>> port5 port port1 : PortDef1 [1..*] port6S : PortDef6S [m] subsets port6 ordered nonunique; port7S : PortDef7S [m] :> port7 Ports Compartment /* ... */ port8R = port8 ref port9 : PortDef9 } port10 port11 : ~PortDef11 ... { directed features in attribute1 : in attribute1 : AttributeDef1 AttributeDef1; out attribute2 : out attribute2 : AttributeDef2 AttributeDef2; inout attribute3 : AttrributeDef3 inout attribute3 : Directed Features in item1 : ItemDef1 AttributeDef3; Compartment in item1 : ItemDef1; out item2 : ItemDef2 out item2 : ItemDef2; inout item3 : ItemDef3 inout item3 : ItemDef3; ... } 62 Systems Modeling Language v2.0, Part 1 -7.12.2 Port Definitions and Usages A port definition or usage is declared as a kind of occurrence definition or usage (see 7.9.2 ), using the kind keyword port . A port usage must only be defined by port definitions. The default multiplicity of a port usage is [1..1] , under the conditions described in 7.6.3 . All the features of a port definition or port usage, other than any nested port usages, must be referential (non-composite). port def FuelingPort { attribute flowRate : Real; out fuelOut : Fuel; in fuelReturn : Fuel; } part def FuelTank { port fuelOutPort : FuelingPort; } The base port definition and usage are Port and ports from the Ports library model (see 9.2.5 ). (For other semantic constraints on port usages, see 8.4.8 .) 7.12.3 Conjugated Port Definitions and Usages Every port definition also implicitly declares a single, nested conjugated port definition, which has the same features as its original port definition, except that any directed features have conjugated directions (i.e., in and out are reversed, with inout unchanged). The name of the conjugated port definition is always given by the name of the original port definition with the character ~ prepended, in the namespace of the original port definition. For example, if a port definition has the name P , then its conjugated port definition has the name P::'~P' . A conugated port usage is a shorthand for declaring a port usage defined by a conjugated port definition. With this shorthand, rather than using the actual name of the conjugated port definition, the name of the original port definition can be used, preceded by the symbol ~ . For example, port p : ~P; is equivalent to port p : P::'~P'; Since the symbol ~ is not considered part of a name when used in a conjugated port usage, it does not have to be placed within quotes, while quotes do have to be used to represent the actual name of the conjugated port definition as a lexical unrestricted name (see 7.2.2 ). Note that, if the original port definition itself has a name that is itself lexically represented as an unrestricted name, such as 'P-1' , then its conjugated port definition has the (qualified) name 'P-1'::'~P-1' , but the corresponding conjugated port usage is port p1 : ~'P-1' where the ~ is not placed inside the quotes. 7.13 Connections 7.13.1 Connections Overview Metamodel references: • Textual notation, 8.2.2.13 • Graphical notation, 8.2.3.13 • Abstract syntax, 8.3.13 • Semantics, 8.4.9 Systems Modeling Language v2.0, Part 1 63 -Connection Definition and Usage A connection definition is both a relationship and a kind of part definition (see 7.11 ) that classifies connections between related things, such as items and parts. Unless it is abstract, at least two of the owned features of a connection definition must be connection ends, which specify the things that are related by the connection definition. Connection definitions with exactly two connection ends are called binary connection definitions, and they classify binary connections. The features of a connection definition that are not connection ends characterize connections separately from the connected things. Since a connection is a part, values of these non-end features can potentially change over the lifetime of the connection. However, the values of connection ends (i.e., the things that are actually connected) do not change over time (though they can potentially be occurrences that themselves have features whose values change over time). A connection usage is a part usage (see 7.11 ) that is a usage of a connection definition, connecting usage elements such as item and part usages. A connection usage redefines the connection ends from its definition, associating those ends with the specific usage elements that are to be connected. For example, a connection definition could have connection ends that are part usages defined by part definitions Pump and Tank . A usage of this connection definition would then associate corresponding connection ends with specific pump and tank part usages. Supposing that the pump and tank part usages have multiplicity 1 , then this means that the single value of the pump usage is to be connected to the single value of the tank usage. A connection usage that connects parts is often a logical connection that abstracts away details of how the parts are connected. For example, plumbing that includes pipes and fittings may be used to connect a pump and a tank. It is sometimes desired to model the connection of the pump to the tank at a more abstract level without including the plumbing. This is viewed as a logical connection between the pump and the tank. Alternatively, the plumbing can be modeled as a part (informally referred to as an interface medium) where the pump connects to the plumbing, and the plumbing connects to the tank. As a part itself, a connection can contain the plumbing either as a composite feature, or as a reference to the plumbing that is owned by a higher level pump-tank system context. In this way, the logical connection without structure can be transformed into a physical connection. Bindings and Successions Bindings and successions are special kinds of connections. They are usages, but, unlike regular connection usages, they are not part usages. The connections specified by bindings and successions are not occurrences and are not created and destroyed. Rather, they assert specific relationships between the features that they connect, which must be true at all times. A binding is a binary connection that requires its two related usages to have the same values. A binding can also be used to bind a referential feature in one context to a composite feature in another context to assert they are the same thing. For example, the steering wheel in a car may be considered part of the interior of the car, while at the same time it is considered part of the steering subsystem. The steering wheel can be a composite part usage of the interior, and a reference part usage of the steering subsystem, and these two usages can be bound together to assert that they are the same part. A feature value is a shorthand for initializing or binding a usage to the result of an expression (see 7.19 ) as part of the declaration of the usage. There are two types of feature value binding. • A fixed feature value establishes the binding of the usage to the result of evaluating the given expression at the point of declaration of the usage. Such a binding cannot be overridden in a redefinition of the usage because, once asserted, a binding must be true for all instances of the usage. • A default feature value also includes an expression, but it does not immediately establish the binding of the usage. Instead, the evaluation of the expression and the binding of the usage is delayed until the instantiation of a definition or usage that features the original usage. Unlike a fixed feature value, a default feature value can be overridden in a redefinition of its original feature with a new feature value (fixed or 64 Systems Modeling Language v2.0, Part 1 -default). In this case, the new overriding feature value is used instead of the original feature value for binding the redefining usage. A succession is a binary connection that requires its two related usages to have values that are occurrences that happen completely separated in time, with the first occurrence happening before the second. Successions can be used to assert the ordering of any kind of occurrences in time, but are particularly useful for event occurrences (see 7.9 ) and performances of actions (see 7.17 ). Table 11. Connections – Representative Notation Element Graphical Notation Textual Notation «connection def» ConnectionDef1 connection def ConnectionDef1 { ends end end1 : Part1; end1 : Part1 end end2 : Part2; } Connection end2 : Part2 Definition connection def ConnectionDef1 { «connection def» /* members */ ConnectionDef1 } compartment stack ••• «part def» Part1 connection def end1 0..1 ConnectionDef1 { end [0..1] part end1 ConnectionDef1 Connection : Part1; Definition end [1..*] part end2 end2 1..* : Part2; } «part def» Part2 «part def» Part1 connection def sourceEnd 1..1 ConnectionDef2 { Connection end [1..1] part ConnectionDef2 sourceEnd : Part1; Definition (with end [1..*] part direction indication) 1..* targetEnd targetEnd : Part2; } «part def» Part2 Systems Modeling Language v2.0, Part 1 65 -Element Graphical Notation Textual Notation «part def» connection def ConnectionDef1 { Part1 end [0..1] part end1 end1 0..1 Connection : Part1; end3 «part def» ConnectionDef1 end part end2 : Definition (n-ary Part3 Part2; with 3 ends) end2 end part end3 : «part def» Part3; } Part2 «connection» connection1 : ConnectionDef1 connection connection1 : ConnectionDef1 { ends end end1 ::> part1; end1 ::> part1 end end2 ::> part2; } end2 ::> part2 Connection connection connection1 : ConnectionDef1 { «connection» /* members */ connection1 : ConnectionDef1 } compartment stack ••• «connection» «part» «part» connection1 : connection connection1 : part1 : Part1 part2 : Part2 ConnectionDef1 ConnectionDef1 Connection connect part1 to part2; «part» «part» connection2 : connection connection2 : part1 : Part1 part2 : Part2 ConnectionDef2 ConnectionDef2 Connection (with connect part1 to direction indication) part2; «part» part1 : Part1 connection connection1 : «part» connection1 : ConnectionDef1 Connection (n-ary ConnectionDef1 connect (part1, with 3 ends) part3 : Part3 part2, part3); «part» part2 : Part2 66 Systems Modeling Language v2.0, Part 1 -Element Graphical Notation Textual Notation part def Part1 { part part2 : Part2 { part part4 : Part4; Part1 } part part3 : Part3 { part2 : Part2 part3 : Part3 part part5 : Part5; Nested Connection part4 : Part4 part5 : Part5 } connection connection1 : ConnectionDef1 connect part2.part4 to part3.part5; } part def Part1 { part part2 : Part2 { part part4 : Part4; } Part1 part part3 : Part3 { part2 : Part2 part3 : Part3 part part5 : Part5; Proxy Connection } .part4 .part5 connection connection1 : ConnectionDef1 connect part2.part4 to part3.part5; } Connections Compartment part part1 : Part1 { «part» part part2 : Part2 { part1 : Part1 ref part part4R : Part4; } «part» «part» part part3 : Part3 { part2 : Part2 part3 : Part3 part part4 : Binding Connection Part4; } bind part2.part4R = part3.part4; = «part» «part» } part4R : Part4 part4 : Part4 Systems Modeling Language v2.0, Part 1 67 -Element Graphical Notation Textual Notation part def Part1 { part part2:part2 { «part def» ref part Part1 part4R:Part4; «part» «part» } part2 : Part2 part3 : Part3 part part3:part3 { Binding Connection «ref part» «part» part part4:Part4; = part4R : Part4 part4 : Part4 } bind part2.part4R = part3.part4; } 7.13.2 Connection Definitions and Usages A connection definition or usage (that is not of a more specialized kind) is declared as a kind of occurrence definition or usage (see 7.9.2 ), using the kind keyword connection . A connection usage must only be defined by connection definitions (of any kind) or KerML association structures (see [KerML, 7.4.5]). Unless it is abstract, a connection definition or usage must have at least two end features (which may be owned or inherited). A binary connection definition or usage is one that has exactly two end features. End features are declared as usages (see 7.6.3 ), prefixed by the keyword end . End features are always considered referential (non-composite), whether or not their declaration explicitly includes the ref keyword. The end features of a connection definition or usage identify the participants in the connections that are instances of the connection definition or usage and must have multiplicity 1..1 . If a multiplicity is not explicitly declared for an end feature, then a default of 1..1 is implicitly declared for it (regardless of the usual conditions for default multiplicity given in 7.6.3 ). Connection definitions and usages are also relationships. For a connection definition, its related elements are given by the definitions of its end features. For a connection usage, its related elements are the features associated to each of its end features via reference subsetting relationships, whose textual notation is the keyword references or the equivalent symbol ::>. (See also 7.2 on Relationships.) // The related elements of this connection definition // are the part definitions Hub and Device. connection def DeviceConnection { end part hub : Hub; end part device : Device; // This is a non-end feature of the connection definition. attribute bandwidth : Real; } // The related elements of this connection usage // are the part usages mainSwitch and sensorFeed. connection connection1 : DeviceConnection { end part hub ::> mainSwitch[1]; end part device ::> sensorFeed[1]; } The kind keyword (e.g., part in the example above) may be omitted from an end declaration unless it has an owned cross feature, as described later). In this case, the end feature is a reference usage by default (i.e., as if ref was used as the kind keyword). For a binary connection definition or usage, one or both end features can be explicitly declared to subset a cross feature owned by the other related type. This is done with cross subsetting, which is a special kind of subsetting 68 Systems Modeling Language v2.0, Part 1 -relationship specified using the keyword crossing or the symbol => . Only end features may have cross subsetting relationships, and an end feature can have at most one owned cross subsetting. part def Hub { ref part connectedDevices [1..*] ordered : Device; } part def Device { ref part connectingHub [0..1] : Hub; } connection def DeviceConnection { end part hub : Hub crosses device.connectingHub; end part device : Device => hub.connectedDevices; attribute bandwidth : Real; } This specifies that each instance of the DeviceConnection connection definition must link a value of the connectingHub feature of the device with a value of the connectedDevices feature of the hub . That is, creating a DeviceConnection between a Hub and a Device means that the Device must be one of the connectedDevices of the Hub and that the Hub must the connectingHub of the Device . As shown above, the target of a cross subsetting relationship must be a feature chain (see 7.6.6 ) in which the first feature is the other connection end and the second feature is the cross feature for that end. Cross feature multiplicity effectively constrains the number of instances of a connection definition. It applies to each set of instances (connections) of the connection definition that have the same (single) values for each of the other ends. For a binary connection definition, this is the same as the number of values resulting from "navigating" across the association from an instance of one related type to instances of the other related type. Cross feature uniqueness and ordering apply to the instances navigated to, preventing duplication among them and ordering them to form a sequence. For example, given a specific Device , navigating across all DeviceConnections with that Device as the device to the corresponding hub gives a collection of Hubs that must be the same as the connectingHub of the Device . The connectingHub feature has a multiplicity of 0..1 , requiring that there must be at most one DeviceConnection for any Device . Similarly, given a specific Hub , navigating across all DeviceConnections with that Hub as the hub to the corresponding device gives a collection of Devices that must be the same as the connectedDevices of the Hub . The connectedDevices feature has a multiplicity lower bound of 1 , requiring that there must be at least one DeviceConnection for every Hub . The declaration of connectedDevices as ordered means that this collection is ordered in the same order as the connectedDevices of the Hub . Similarly, if connectedDevices were non-unique, the collection could contain duplicate Devices . Note that these semantics depend on the values of cross features being exclusively due to the existence of corresponding connections. In particular, cross features can only meet their minimum multiplicity constraints if such connections exist. For example, a Hub having a Device as one of its connectedDevices is sufficient to require that a DeviceConnection exists between that Hub and that Device , and, therefore, that the Hub is also the connectingHub of the Device . In addition, since connectedDevices has a multiplicity lower bound of 1 , there must be at least one DeviceConnection for every Hub (as stated above), to provide the required value for connectedDevices . It is also possible to declare cross features directly in the declaration of the ends of a connection definition, rather than nested in the related types of the connection definition. Such owned cross features are declared between the end and kind keywords of the association end declarations (and, in this case, the kind keyword is required). These may be full usage declarations, including declared name and or short name, owned subsettings and redefinitions, etc., but without bodies and nested elements (see 7.6.3 on usage declaration). connection def HubDeviceConnection { end connectingHub [0..1] ordered part hub : Hub; end connectedDevices [1..*] part device : Device; Systems Modeling Language v2.0, Part 1 69 -attribute bandwidth : Real; } Note. Owned cross features are in the namespace of the owning end features, so their names are qualified by the name of the end features, e,g., HubDeviceConnection::hub::connectedDevices . For a binary connection definition, an owned cross feature is implied to be featured by the type of the other association end, rather than its owning connection end. Further, a connection end with a cross feature has an implied cross subsetting relationship to the cross feature through the other end feature. This ensures owned cross features have the same semantics as cross features that are nested directly in the related types of the connection end. (For further details, see 8.4.9.1 on connection definition semantics.) Note. If an end feature has an owned cross feature, then it may not have an explicit cross subsetting relationship declared to an unowned cross feature. While owned cross features can have full feature declarations, it is often sufficient to just include the cross multiplicity, ordering, and/or uniqueness on one or more connection ends. connection def HubDeviceConnection { end [0..1] part hub : Hub; end [1..*] ordered part device : Device; attribute bandwidth : Real; } This specifies that every Device must have at most one Hub as its hub , and that every Hub may have one or more Devices as connectedDevices , which are ordered. Note that the connection ends themselves, as participants of the connection, still always have multiplicity 1..1 , whether or not this is included in the declaration. Cross features can also be used in connection definitions with more than two ends, but they must all be owned by the connection ends. In general, the cross multiplicity, ordering, and uniqueness of a connection end apply to the the collection of its values from each set of instances of the connection definition that have the same (single) values for each of the other ends. connection def ProtocolDeviceConnection { end [*] part hub : Hub; end [*] ordered part device : Device; end [0..1] item protocol : Protocol; } The cross multiplicity 0..1 for protocol requires that, for every pair of a Hub and a Device , at most one ProtocolDeviceConnection instance may connect that Hub as its hub and Device as its device to a Protocol as its protocol . Similarly, every pair of a Hub as hub and a Protocol as protocol may be connected to any number of Devices as device , including none at all, as declared by the cross multiplicity of device . This collection of connected Devices is ordered, as declared by the cross ordering of device . The same applies to the cross multiplicity of hub . (For further details, see 8.4.9.1 on connection definition semantics.) Connection usages may also have end features with cross features, either specified using cross subsetting or as owned cross features. The cross feature for the end feature further constrains any inherited cross feature(s). part def NetworkConfiguration { part networkHubs[*] : Axle; part networkDevices[*] : Device; // Connects each one of the networkHubs to at most four of the networkDevices. connection networkConnections : DeviceConnection { end [1] part hub references networkHubs; end [0..4] part device references networkDevices; } } 70 Systems Modeling Language v2.0, Part 1 -There are two shorthand textual notations for connection usages. Rather than using explicit end feature declarations in the body of a connection usage, the related features of the connection usage may be identified in a comma-separated list, between parentheses ( ... ) , preceded by the keyword connect , placed after the connection usage declaration and before its body. The identification of a related feature may optionally be preceded by a cross multiplicity and/or an end feature name followed by the keyword references or the symbol ::> . If the declaration part of the connection usage is empty when using this notation, then the keyword connection may be omitted. connection connection1 : DeviceConnection connect ( [1] hub ::> mainSwitch[1], [1] device ::> sensorFeed ); // This is a ternary connection. // It is equivalent to "connection connect (axle, wheel1, wheel2);" connect (axle, wheel1, wheel2); If the connection usage is binary, then a further special notation may be used in which the source related feature is identified directly after the keyword connect and the target related feature is identified after the keyword to . As above, if the declaration part of the connection usage is empty, then the keyword connection may be omitted. connection connection1 : DeviceConnection connect [1] hub ::> mainSwitch to [1] device ::> sensorFeed; connect leftWheel to leftHalfAxle; The base connection definition and usage are Connection and connections from the Connections library (see 9.2.6 ). For a binary connection definition or usage, the base definition and usage are further restricted to BinaryConnection and binaryConnections , which enforce that the connection has exactly two ends. If a connection definition has a single owned superclassification relationship with another connection definition, it may inherit end features from this general connection definition. However, if it declares any owned end features, then each of these must redefine an end feature of the general connection definition, in order, up to the number of end features of the general connection definition. If no redefinition is given explicitly for an owned end feature, then it is considered to implicitly redefine the end feature at the same position, in order, of the general connection definition, if any. An implicitly or explicitly redefining connection end may also further constrain the cross multiplicity (if any) of the superclassifier connection ends that it redefines. // Implicitly specializes Connections::BinaryConnection by default. connection def AssetOwnership { attribute valuationOnPurchase : MonetaryValue; end [1..*] item owner : LegalEntity; // Implicitly redefines BinaryConnection::source. end [*] item ownedAsset : Asset; // Implicitly redefines BinaryConnection::target. } connection def SoleOwnership specializes AssetOwnership { end [1] item owner; // Implicitly redefines Ownership::owner. // ownedAsset is inherited. } Any specialization of a binary connection definition must also be binary. That is, it can inherit or redefine the two end features from the general connection definition, but it cannot add more end features. If a connection definition has more than one owned superclassification with other connection definitions, then it must declare a number of owned end features at least equal to the maximum number of end features of any of the general connection definitions. Each of these owned end features must then redefine the corresponding end feature (if any) at the same position, in order, of each of the general connections, either explicitly or implicitly. Systems Modeling Language v2.0, Part 1 71 -Similar rules hold for the end features of a connection usage that is defined by one or more connection definitions and/or subsets or redefines one or more connection usages. connection connection1 : DeviceConnection { end [1] part hub ::> mainSwitch; // Implicitly redefines DeviceConnection::hub. end [1] part device ::> sensorFeed; // Implicitly redefines DeviceConnection::device. } 7.13.3 Bindings as Usages A binding can be declared as a usage as described in 7.6.3 , using the kind keyword binding . Note that a binding is not a kind of occurrence usage (unlike a regular connection usage), so the notations for time slices, snapshots and individuals (described in 7.9 ) do not apply to it. Further, the two related features of a binding are specified using a special notation. The two related features of a binding are identified after its declaration part and before its body, following the keyword bind and separated by the symbol = . If the declaration part is empty, then the keyword binding may be omitted. part def Vehicle { part fuelTank { out fuelFlowOut : Fuel; } part engine { in fuelFlowIn : Fuel; } binding fuelFlowBinding bind fuelTank.fuelFlowOut = engine.fuelFlowIn; // The following is equivalent to the above, but // without the name. bind fuelTank.fuelFlowOut = engine.fuelFlowIn; } The base usage for a binding is the the KerML feature selfLinks from the Links model in the Kernel Semantic Library (see [KerML, 9.2.3]). 7.13.4 Feature Values A feature value is a relationship between an owning usage and a value expression, whose result provides values for the feature. The feature value relationship is specified as either bound or initial, and as either fixed or default. A usage can have at most one feature value relationship. A fixed, bound feature value relationship is declared using the symbol = followed by a representation of the value expression (using the expression notation from [KerML, 7.4.9]). This notation is appended to the declaration of the usage being bound by the feature value. Usages that have a feature value relationship of this form implicitly have a nested binding between the feature and the result of the value expression. attribute monthsInYear : Natural = 12; item def TestRecord { attribute scores[1..*] : Integer; derived attribute averageScore[1] : Rational = sum(scores)/size(scores); attribute cutoff : Integer default = 0.75 * averageScore; } Note. The semantics of binding mean that such a feature value asserts that a feature is equivalent to the result of the value expression. To highlight this, a feature with such a feature value can be flagged as derived (though this is not required, nor is it required that the value of a derived feature be computed using a feature value – see also 7.6.3 ). 72 Systems Modeling Language v2.0, Part 1 -A fixed, initial feature value relationship is declared as above but using the symbol := instead of = . In this case, the usage also has an implicit nested binding, but the binding only applies to the starting snapshot of the owning definition or usage of the bound usage (which means that that the owner must be a kind of occurrence definition or usage, see 7.9 ). That is, the result of the value expression gives the initial values of the declared feature but, unlike in the case of a bound value, these initial values may subsequently change. part def Counter { attribute count[1] : Natural := 0; } A default feature value relationship is declared similarly to the above, but with the keyword default preceding the symbol = or := , depending on whether it is bound or initial. However, for a default, bound feature value, the symbol = may be elided. part def Vehicle { attribute mass : Real default 1500.0; feature engine[1] : Engine default := standardEngine; } item def TestWithCutoff :> TestRecord { attribute cutoff : Rational default = 0.75 * averageScore; } For a default feature value relationship, no implicit binding is added to the usage declaration, but the default will apply when an instance of the owning definition or usage is constructed, if no other explicit values are given for the defaulted usage. 7.13.5 Successions as Usages A succession can be declared as a usage as described in 7.6.3 , using the kind keyword succession . Note that a succession is not a kind of occurrence usage (unlike a regular connection usage), so the notations for time slices, snapshots and individuals (described in 7.9 ) do not apply to it. Further, the two related features of a succession are specified using a special notation. The two related features of a succession are identified after its declaration part and before its body, following the keyword succession and separated by the keyword then . If the declaration part is empty, then the keyword succession may be omitted. The related features of a succession must be occurrence usages. As for regular connection usages, constraining multiplicities can also be defined on the end features of a succession. part def Camera { action focus[*] : Focus; action shoot[*] : Shoot; // Each focus may be preceded by a previous focus. succession multiFocusing first [0..1] focus then [0..1] focus; // Each shoot must follow a focus. first [1] focus then [0..1] shoot; // The Camera can be focused after shooting. first [0..1] shoot then focus; } If a succession is placed lexically directly between the two occurrence usages that are its related elements, then the declaration of the succession can be shortened to just the keyword then , prepended to the declaration of the second occurrence usage. A multiplicity for the source end of the succession can optionally be placed directly after the then keyword. occurrence def Flight { timeslice preflight[1]; Systems Modeling Language v2.0, Part 1 73 -then timeslice inflight[1]; then timeslice postflight[1]; } // The above is equivalent to the following. occurrence def Flight { timeslice preflight[1]; first preflight then inflight; timeslice inflight[1]; first inflight then postflight; timeslice postflight[1]; } Note. There are additional shorthands for the use of successions within the bodies of action definitions and usages (see 7.17.4 ). The base usage for a succession is the KerML feature happensBeforeLinks from the Occurrences model in the Kernel Semantic Library (see [KerML, 9.2.4]). 7.14 Interfaces 7.14.1 Interfaces Overview Metamodel references: • Textual notation, 8.2.2.14 • Graphical notation, 8.2.3.14 • Abstract syntax, 8.3.14 • Semantics, 8.4.10 An interface definition is a kind of connection definition (see 7.13 ) whose ends are restricted to be port definitions (see 7.12 ). An interface usage is a kind of connection that is usage of an interface definition. The ends of an interface usage are restricted to be port usages. An interface is simply a connection all of whose ends are ports. As such, an interface facilitates the specification and reuse of compatible connections between parts. For example, consider a Power interface definition between an Appliance and Wall Power . The power port on one end of the interface represents the Appliance connection point, and the outlet port on the other end represents the Wall Power connection point. This interface can then be used for connecting many different appliances to wall power. When modeling physical interactions, an interface definition or usage can contain constraints (see 7.20 ) to constrain the values of the features of the ports on its ends. For example, such features may be across and through variables, which are constrained by conservation laws across the interface (e.g., Kirchhoff’s Laws). When specifying an interface between electrical components, the across and through variables are port features defined as Voltage and Current quantities, respectively. The feature values on either port are constrained such that the voltages must be equal, and the sum of the currents must equal zero. 74 Systems Modeling Language v2.0, Part 1 -Table 12. Interfaces – Representative Notation Element Graphical Notation Textual Notation «interface def» InterfaceDef1 interface def InterfaceDef1 { ends end port1:Port1; port1 : Port1 end port2:Port2; port2 : Port2 } Interface Definition interface def InterfaceDef1 { «interface def» /* members */ InterfaceDef1 } compartment stack ••• «interface» interface interface1 : interface1 : InterfaceDef1 InterfaceDef1 { ends end port1 :> pa; end port2 :> pb; port1 :>pa } port2 :>pb Interface interface interface1 : «interface» InterfaceDef1 { /* members */ interface1 : InterfaceDef1 } compartment stack ••• { interfaces interface interface1 interface1 : InterfaceDef1 [1..*] : InterfaceDef1 [1..*]; Interfaces interface2 : InterfaceDef2 interface interface2 Compartment ... : InterfaceDef2; /* ... */ } part part1:Part1 { port p4:P4; } part part2:Part2 { part1 : Part1 part2 : Part2 interface1: port p2:P2; InterfaceDef1 p2 : P2 p4 : P4 } Interface interface interface1 : InterfaceDef1 connect part1.p4 to part2.p2; Systems Modeling Language v2.0, Part 1 75 -Element Graphical Notation Textual Notation port def Pa { port p1 : P1; port p2 : P2; port p3 : P3; } part def Part1 { port pa : Pa; «part» part0 } part def Part2 { «part» «part» port pb : ~Pa; part1 : Part1 part2 : Part2 interface2 : InterfaceDef2 } pa : Pa pb : ~Pa interface def InterfaceDef2 { end :>> source : Pa; end :>> target : ~Pa; «interface» interface2 : InterfaceDef2 } part part0 { Interface as Node «ref port» «ref port» part part1 : Part1; source ::> part1.pa target ::> part2.pb part part2 : Part2; p1 : P1 p1 : ~P1 interface interface2 : InterfaceDef2 p2 : P2 p2 : ~P2 connect source ::> part1.pa to target ::> part2.pb { p3 : P3 p3 : ~P3 interface source.p1 to target.p1; interface source.p2 to target.p2; interface source.p3 to target.p3; } } 76 Systems Modeling Language v2.0, Part 1 -Element Graphical Notation Textual Notation port def Pa { out item i1Out : Item1; in item i2In : Item2; } «part» interface def Interface2 part0 { «part» «part» end supplierP : Pa; part1 : Part1 part2 : Part2 if2 : Interface2 end consumerP : ~Pa; pa : Pa pb : ~Pa «flow» of «flow» of flow supplierP.i1Out :Item2 :Item1 to consumerP.i1Out; flow consumerP.i2In Interface as Node to supplierP.i2In; «interface» (with flow) } if2 : Interface2 part part0 { i1Out : Item1 «ref port» «ref port» supplierP ::> part1.pa consumerP ::> part2.pb part part1 : Part1 { i1Out : Item1 port pa : Pa; i2In : Item2 } part part2 : Part2 { i2In : Item2 port pb : ~Pa; } interface if2 : Interface2 connect part1.pa to part2.pb; } 7.14.2 Interface Definitions and Usages An interface definition or usage is declared like a connection definition or usage (see 7.13.2 ), but using the kind keyword interface . An interface usage must only be defined by interface definitions. All the end features of an interface definition or usage must be port usages, so the use of the port keyword is optional on such end features if no owned cross feature is declared on the end. The shorthand notations for connection usages described in (see 7.13.2 ) may also be used for interface usages. However, if the declaration part of an interface usage is empty, then the interface keyword is still included, but the connect keyword may be omitted. port def FuelingPort { out fuel : Fuel; } interface def FuelingInterface { end fuelOutPort : FuelingPort; end fuelInPort : ~FuelingPort; } interface fuelLine : FuelingInterface connect fuelTank.fuelingPort to engine.fuelingPort; // The following is equivalent to the above, except // for not using a specialized interface definition. interface fuelTank.fuelingPort to engine.fuelingPort; If a send action (see 7.17.7 ) is used to send a transfer via a port that is at one end of a binary interface, then the port at the other end of the interface automatically becomes the target of the transfer. Such automatic targeting happens in either direction between the ports related by the interface. If a port is connected by multiple interfaces, then each transfer outgoing from the port will target exactly one of the ports at the other ends of these interfaces, but which one is not determined by the interface semantics. Systems Modeling Language v2.0, Part 1 77 -part def DistributedSystem { item def Request; item def Response; part client { port clientPort; action clientBehavior { send new Request() via clientPort; then accept Response via clientPort; } } part server { port serverPort; action serverBehavior { accept Request via serverPort; then send new Response() via serverPort; } } // Transfers from the clientPort automatically target the serverPort // and vice versa. interface client.clientPort to server.serverPort; } Targeting of transfers outgoing from a port at one end of an interface with three or more ends is similar to the case of a port connected by multiple binary interfaces. In all cases, an outgoing transfer is targeted to a port at one of the other ends of any of the interfaces connecting the port, but which one is is not determined by the interface semantics. Note. Transfers via ports must be targeted across interfaces. It does not happen across other kinds of connections. The base interface definition and usage are Interface and interfacess from the Interfacess library (see 9.2.7 ). For a binary interface definition or usage, the base definition and usage are further restricted to BinaryInterface and binaryInterfaces , which enforce that the interface has exactly two ends. 7.15 Allocations 7.15.1 Allocations Overview Metamodel references: • Textual notation, 8.2.2.15 • Graphical notation, 8.2.3.15 • Abstract syntax, 8.3.15 • Semantics, 8.4.11 An allocation definition is a connection definition (see 7.13 ) that specifies that a target element is responsible for realizing some or all of the intent of the source element. An allocation usage is a usage of one or more allocation definitions. An allocation definition or usage can be further refined using nested allocation usages that provide a finer-grained decomposition of the containing allocation. As used by systems engineers, an allocation denotes a "mapping" across the various structures and hierarchies of a system model. This concept of "allocation" requires flexibility suitable for abstract system specification, rather than a particular constrained method of system or software design. System modelers often associate various elements in a user model in abstract, preliminary, and sometimes tentative ways. Allocations can be used early in the design as a precursor to more detailed rigorous specifications and implementations. Allocations can provide an effective means for navigating a model by establishing cross relationships and ensuring that various parts of the model are properly integrated. Since these relationships are instantiable connections, they can also be semantically related to other such relationships, including satisfying requirements (see 7.21 ), 78 Systems Modeling Language v2.0, Part 1 -performing actions (see 7.17 ) and exhibiting states (see 7.18 ). Modelers can also create specialized allocation definitions to reflect conventions for allocation on specific projects or within certain system models. Table 13. Allocations – Representative Notation Element Graphical Notation Textual Notation «allocation def» allocation def AllocationDef1 AllocationDef1; «allocation def» allocation def Allocation Definition AllocationDef1 { AllocationDef1 /* members */ compartment stack } ••• «allocation» allocation allocation1 : allocation1 : AllocationDef1 AllocationDef1; allocation allocation1 : Allocation «allocation» AllocationDef1 { /* members */ allocation1 : AllocationDef1 } ••• part part3 { allocate part1 to allocated part3; Allocated from part1.part1a allocate part3 to Compartment to part2.part2a part2; } part part1 : Part1; «allocate» «part» «part» part part2 : Part2; Allocation part1 : Part1 part2 : Part2 allocate part1 to part2; part part1 : Part1 { perform action1; } «allocate» «part» «part» part part2 : Part2 { part1 : Part1 part2 : Part2 perform action2; «perform» «perform» } Allocation (with sub «allocate» allocate part1 to part2 allocation) { «action» «action» allocate acton1 action2 part1.action1 to part2.action2; } Systems Modeling Language v2.0, Part 1 79 -7.15.2 Allocation Definitions and Usages An allocation definition or usage is declared like a connection definition or usage (see 7.13.2 ), but using the kind keyword allocation . An allocation usage must only be defined by allocation definitions. Allocation definitions and usages are always binary, having exactly two end features, even if abstract. Shorthand notations similar to those for connection usages, as described in see 7.13.2 , may also be used for allocation usages, but using the keyword allocate instead of connect . If the declaration part of the allocation usage is empty when using this notation, then the keyword allocation may be omitted. part def LogicalSystem { part component : LogicalComponent; } part def PhysicalDevice { part assembly : PhysicalAssembly; } allocation def LogicalToPhysicalAllocation { end part logical : LogicalSystem; end part physical : PhysicalDevice; // This is a nested sub-allocation. allocate logical.component to physical.assembly; } part system : LogicalSystem; part device : PhysicalDevice; allocation systemToDevice : LogicalToPhysicalAllocation allocate logical ::> system to physical ::> device; The base allocation definition and usage are Allocation and allocations from the Allocations library model (see 9.2.8 ). 7.16 Flows and Messages 7.16.1 Flows and Messages Overview Metamodel references: • Textual notation, 8.2.2.16 • Graphical Notation, 8.2.3.16 • Abstract Syntax, 8.3.16 • Semantics, 8.4.12 A flow definition is both a relationship and a kind of action definition (see 7.17 ) that classifies transfers of some payload between interacting occurrences, such as parts and actions. A flow definition is a binary relationship between two ends, the first of which is the source, from which the payload comes, and the second of which is the target, to which the payload is delivered. The transferred payload can be anything (attribute value, item, part, etc.). A flow definition may also have features other than its source and target that characterize the classified transfers separately from the interacting occurrences. A flow usage is an action usage (see 7.17 ) that is a usage of a flow definition, connecting usage elements such as part and action usages. It represents the performance of a transfer, as classified by its flow definition, between the values of the interacting usages, which must be occurrences. The transfer is directed from the first end (the source) to the second end (the target). There are three kinds of flows. 80 Systems Modeling Language v2.0, Part 1 -1. A message is modeled as a flow usage that specifies that some transfer happens between the source and target ends, and can define the payload that is to be transferred. However, a message does not specify how the payload is to be obtained from the source or delivered to the target. 2. A streaming flow is modeled as a flow usage that not only specifies the source and target of a transfer (and, optionally, the payload), but also identifies the source output feature of the source usage from which the payload is obtained and the target input feature of the target usage to which the payload is to be delivered. 3. A succession flow is modeled as a succession flow usage, which is both a flow usage and a succession. A succession flow is specified in the same way as a streaming flow, but it adds the further constraint that the transfer source must complete before the transfer starts, and the transfer must complete before the target can start. Messages are typically used to model abstract logical interaction between part usages in a certain context, which may be realized in a more detailed model using streaming or succession flows (or transfers from send actions to accept actions, see 7.17 ). Table 14. Flows and Messages – Representative Notation Element Graphical Notation Textual Notation action action1:Action1 { out item1:Item1; } action1 : Action1 action2 : Action2 action action2:Action2 { item1 : Item1 in item1:Item1; Flow item1 : Item1 } flow action1.item1 to action2.item1; Systems Modeling Language v2.0, Part 1 81 -Element Graphical Notation Textual Notation item def Item1 { item subItem1; item subItem2; item subItem3; } «action» «action» action action1 : Action1 action2 : Action2 item1 : Item1 item2 : Item1 action1 : Action1 { out item1 : Item1; } action action2 : Action2 { «flow» in item2 : Item1; flow1_2 : FlowConnection } flow flow1_2 from «end» source «end» target action1.item1 to Flow as Node «in ref item» «out ref item» action2.item2 { ^item1 : Item1 ^item2 : Item1 flow «item» «item» source.item1.subItem1 subItem1 subItem1 to «item» «item» target.item2.subItem1; subItem2 subItem2 flow «item» «item» source.item1.subItem2 subItem3 subItem3 to target.item2.subItem2; flow source.item1.subItem3 to target.item2.subItem3; } { flow flow1 of ItemDef from part1.port1 to flows part2.port2; flow1 of ItemDef from part1.port1 to part2.port2 flow flow2 from action1.output to flow2 from action1.output to action2.input action2.input; action1.output to action2.input flow action1.output Flows Compartment succession action1.output to action2.input to action2.input; message msg from part1 to part2 succession flow action1.output to action2.input; message msg from part1 to part2; } part part1 : Part1 { event occurrence ev1; } «message» part1 : Part1 part2 : Part2 Message (in of item1 : Item1 part part2 : Part2 { event occurrence ev2; Interconnection } View) message of item1 : Item1 from part1.ev1 to part2.ev2; 82 Systems Modeling Language v2.0, Part 1 -Element Graphical Notation Textual Notation occurrence { part part1 : Part1 { «part» «part» event occurrence ev1; part1 : Part1 part2 : Part2 } part part2 : Part2 { Message (in msg1 event occurrence Sequence View) ev2; } message msg1 from part1.ev1 to part2.ev2; } 7.16.2 Flow Definitions and Usages A flow definition is declared like a regular connection definition (see 7.13.2 ), but using the kind keyword flow . A flow usage is declared like a regular connection usage (see 7.13.2 ), but using one of the kind keywords message , flow , or succession flow (as discussed further below). A flow usage must only be defined by flow definitions or KerML interactions (see [KerML, 7.4.10]). A non-abstract flow definition is always binary, having exactly two end features. An abstract flow definition may have less than two end features. The payload of a flow definition can be constrained by redefining the payload feature of the flow. flow def FuelFlow { ref item :>> payload : Fuel; end tank : FuelTank; end eng : Engine; } A flow usage may be declared as either a message, a streaming flow, or a succession flow. A flow usage is declared as a message using the kind keyword message rather than flow . In addition, the declaration of a message may also optionally include an explicit specification of the name, type (definition) and/or multiplicity of the payload of the message, after the keyword of . The payload name is followed by the keyword defined by (or the symbol : ), but this keyword (or the symbol) is omitted if the name is omitted. In the absence of a payload specification, the message declaration does not constrain what kinds of values may be transferred between the source and target of the message. A message is always abstract (whether or not the abstract keyword is included explicitly in its declaration). If a message declaration explicitly specifies defining flow usages for the message, then these should always be abstract and have no end features. A message does not explicitly identify the interacting source and target occurrences at the ends of the transfers it specifies. Instead, a message declaration may identify the source and target events at which a transfer may be initiated and received, respectively (see also 7.9.5 on event occurrence usages). If they are included, then they follow the payload specification (if any), with the source event identified after the keyword from , followed by the target event after the keyword to . Alternative, if the source and target event identification is not included, then the message declaration may include a feature value (see 7.13.4 ) to provide a value for the message. part def Vehicle { attribute def ControlSignal; part controller { event occurrence sendControl; } part engine { Systems Modeling Language v2.0, Part 1 83 -event occurrence receiveControl; } message of ControlSignal from controller.sendControl to engine.receiveControl; } A flow usage is declared as a streaming flow using the kind keyword flow . It may include a specification of the flow payload, as for a message declaration. A flow declaration then includes a specification of not only the source and target related features of the flow, but, more specifically, the output feature of the source from which the flow receives its payload (after the keyword from ) and the input feature of the target to which the flow delivers the payload (given using dot notation after they keyword to ). This is done by giving a feature chain with at least two features, the last of which identifies the output or input feature, with the preceding part of the chain identifying the source or target of the flow. If no declaration part or payload specification is included in the flow declaration, then the from keyword may also be omitted. part def Vehicle { part fuelTank : FuelTank { out fuelOut : Fuel; } part engine : Engine { in fuelIn : Fuel; } // This flow usage actually connects the fuelTank to the // engine. The transfer moves Fuel from fuelOut to fuelIn. flow fuelFlow : FuelFlow of flowingFuel : Fuel from fuelTank.fuelOut to engine.fuelIn; // The following is equivalent to the above, except without the name // and leaving the flow definition and payload implicit. flow fuelTank.fuelOut to engine.fuelIn; } A flow usage is declared as a succession flow like a streaming flow above, but using the keyword succession flow . action def TakePicture { action focus : Focus { out image : Image; } action shoot : Shoot { in image : Image; } // The use of a succession flow usage means that focus must // complete before the image is transferred, after which shoot can begin. succession flow focus.image to shoot.image; } Similar rules for specialization and inheritance apply to flow definitions and usages as to regular connection definitions and usages (see 7.13.2 ). The base flow definition is MessageAction from the Flows library model (see 9.2.9 ). The base flow usages are also from the Flows library model: ▪ messages for a message. ▪ flows for a streaming flow. ▪ successionFlows for a succession flow. 84 Systems Modeling Language v2.0, Part 1 -7.17 Actions 7.17.1 Actions Overview Metamodel references: • Textual notation, 8.2.2.17 • Graphical notation, 8.2.3.17 • Abstract syntax, 8.3.17 • Semantics, 8.4.13 Action Definition and Usage An action definition is a kind of occurrence definition (see 7.9 ) that classifies action performances. An action usage is a kind of occurrence usage that is a usage of one or more action definitions. An action definition may have features with directions in , out or inout that act as the parameters of the action. Features with direction in or inout are input parameters, and features with direction out or inout are output parameters. An action usage inherits the parameters of its definitions, if any, and it can also define its own parameters to augment or redefine those of its definitions. Actions are occurrences over time that can coordinate the performance of other actions and generate effects on items and parts involved in the performance (including those items' existence and relation to other things). The features of an action definition or usage that are themselves action usages specify the performance of the action in terms of the performances of each of the subactions. If an action has parameters, then it may also transform the values of its input parameters into values of its output parameters. Action definitions and usages follow the same patterns that apply to structural elements (see 7.6 ). Action definitions and action usages can be decomposed into lower-level action usages to create an action tree, and action usages can be referenced by other actions. In addition, an action definition can be subclassified, and an action usage can be subsetted or redefined. This provides enhanced flexibility to modify a hierarchy of action usages to adapt to its context. Performed Actions A perform action usage is an action usage that specifies that an action is performed by the owner of the performed action usage. A perform action usage is referential, which allows the performed action behavior to be defined in a different context than that of the performer (perhaps by an action usage in a functionally decomposed action tree). However, if the owner of the perform action usage is an occurrence, then the referenced action performance must be carried out entirely within the lifetime of the performing occurrence. In particular, a perform action usage can be a feature of a part definition or usage, specifying that the referenced action is performed by the containing part during its lifetime. A perform action usage can also be a feature of an action definition or usage. In this case, the perform action usage represents a "call" from the containing action to the performed action. Sequencing of Actions Since action usages are kinds of occurrence usages, their ordering can be specified using successions (see 7.13 ). However, a succession between action usages may, additionally, have a guard condition, represented as a Boolean expression (see 7.19 ). If the succession has a guard, then the time ordering of the source and target of the succession is only asserted when the guard condition evaluates to true . The sequencing of action usages may be further controlled using control nodes, which are special kinds of action usages that impose additional constraints on action sequencing. Control nodes are always connected to other actions Systems Modeling Language v2.0, Part 1 85 -usages by incoming and outgoing successions (with or without guards). The kinds of control nodes include the following. • A fork node has one incoming succession and one or more outgoing successions. The actions connected to the outgoing successions cannot start until the action connected to the incoming succession has completed. • A join node has one or more incoming successions and one outgoing succession. The action connected to the outgoing succession cannot start until all the actions connected to the incoming successions have completed. • A decision node has one incoming succession and one or more outgoing successions. Exactly one of the actions connected to an outgoing succession can start after the action connected to the incoming succession has completed. Which of the downstream actions is performed can be controlled by placing guards on the outgoing successions. • A merge node has one or more incoming successions and one outgoing succession. The action connected to the outgoing succession cannot start until any one of the actions connected to an incoming succession has completed. Bindings and Flows Between Actions An output parameter of one action usage may be bound to the input parameter of another action usage (see 7.13 on binding). Such a binding indicates that the values of the target input parameter will always be the same as the values of the source output parameter. If the two actions are performed concurrently, then this equivalence will be maintained over time throughout their performances. An input parameter of an action definition or usage can also be bound to the input parameter of a nested action usage, passing the values of the input parameter into the nested action, and an output parameter of a nested action usage can be bound an output parameter of a containing action definition or usage, passing the values of the output parameter out. The binding of action parameters, however, does not model the case when there is an actual transfer of items between the actions that may itself take time or have other modeled properties. Such a transfer can be more properly modeled using a flow between the two action usages (see 7.16 ), in which the transfer source output is an output parameter of the source action usage and the transfer target input is the input parameter of the target action usage. A streaming flow represents a flow in which the transfer can be ongoing while both the source and target action are being performed. A succession flow represents a flow that imposes the additional succession constraint that the transfer cannot begin until the source action completes and the target action cannot start until the transfer has completed. Transfers can also be performed using send and accept action usages. In this case, the source and target of the transfer do not have to be explicitly connected with a flow. Instead, the source of the transfer is specified using a send action usage contained in some some source part or action, while the target is given by an accept action usage in some destination part or action (which may be the same as or different than the source). A send action usage includes an expression that is evaluated to provide the values to be transferred, and it specifies the destination to which those values are to be sent (possibly delegated through a port and across one or more interfaces – see also 7.12 and 7.14 on interfaces between ports). An accept action usage specifies the type of values that can be received by the action. When a send action performed in the source is matched with a compatible accept action performed in the destination, then the transfer of values from the origin to the destination can be completed. Assignment Actions An assignment action usage is used to change the value of a referent feature of a target occurrence. The target is specified as the result of an expression and the referent is specified as a feature chain relative to that target. The new value for the feature is determined as the result of a different expression. When the assignment action usage completes, the referent feature has the new assigned value for the target occurrence. Note that the target must be an occurrence, because the values of the features of attributes do not change over time (see also 7.7 on attributes and 7.9 on occurrences). If the referent feature has a multiplicity upper bound other than 1, then an assignment action can assign multiple values to it, consistent with the multiplicity of the feature. The values are all assigned atomically, at the same time. 86 Systems Modeling Language v2.0, Part 1 -A initializing feature value can be used as a shorthand for assigning an initial value to a usage as part of the declaration of the usage that is a feature of an occurrence definition or usage. Unlike when feature is a bound using a feature value (as described in 7.13 ), the initial value of a feature can be later assigned a different value. As for a binding feature value, there are two types of initializing feature value. • A fixed feature value assigns the result of evaluating the given expression to a usage at the point of declaration of the usage. Such an assignment cannot be overridden in a redefinition of the usage because, once asserted, it would be indeterminate which initialization is to be used. • A default feature value also includes an initial-value expression, but it does not immediately assign an initial value to the usage. Instead, the evaluation of the expression and the assignment of its result to the usage is delayed until the instantiation of a definition or usage that features the original usage. Unlike a fixed feature value, a default feature value can be overridden in a redefinition of its original feature with a new feature value (fixed or default). In this case, the new overriding feature value is used instead of the original feature value for initializing the redefining usage. Terminate Actions A terminate action usage is used to terminate the performance of some other action. The terminated action ends its performance by the completion of the terminate action usage. The terminated action may be given as an argument to the terminate action usage. If not given explicitly, by default, a terminate action usage terminates its own immediately containing action. A terminate action usage may also be used to terminate a non-action occurrence. In this case, the lifetime of the terminated occurrence must end by the completion of the terminate action usage (see also 7.9.1 on occurrence lifetimes). That is, the terminate action usage effectively "destroys" the terminated occurrence. Structured Control Actions Structured control action usages are used to control the performance of nested action usages in a structured way. There are three kinds of structured control action usages: 1. An if action usage evaluates a condition expression and then performs a then clause action usage if the expression evaluates to true, or, optionally, an else clause action usage if the expression evaluates to false. 2. A while loop action usage performs a body clause action usage iteratively, as long as its while expression continues to evaluate to true and its until expression continues to evaluate to false. 3. A for loop action usage performs a body clause action usage iteratively, assigning a loop variable successively for each iteration to the values resulting from the evaluation of a sequence expression. Table 15. Actions – Representative Notation Element Graphical Notation Textual Notation «action def» ActionDef1 action def ActionDef1; «action def» action def ActionDef1 { Action Definition /* members */ ActionDef1 } compartment stack ••• Systems Modeling Language v2.0, Part 1 87 -Element Graphical Notation Textual Notation «action» action action1 : action1 : ActionDef1 ActionDef1; «action» action action1 : Action ActionDef1 { action1 : ActionDef1 /* members */ compartment stack } ••• item def ItemDef1 { in item 'item1.1'; item1_1 1 f out item 'item1.2'; e param2 : ItemDef2 D in item 'item1.3'; m item1_2 } e t «action» Action with I action action1 { : Parameters 1 action1 inout param1 m item1_3 a :ItemDef1; r a out param2 : p ItemDef2; } action action1 : Action1 { in input1; bind input1 = action2.input2; action action2 : Action2 { in input2; out output2; Action with «action» } action1 : Action1 Graphical flow action2.output2 «action» «action» Compartment = = to action2 : Action2 action3 : Action3 showing standard action3.input3; action flow view action action3 : Action3 { in input3; out output3; } bind action3.output3 = output1; out output1; } 88 Systems Modeling Language v2.0, Part 1 -Element Graphical Notation Textual Notation actions ^action2 : ActionDef2 { action1 : ActionDef1 [1..*] ordered nonunique action action1 : action3R : ActionDef3R redefines action3 ActionDef1 [1..*] action4R : ActionDef4R :>> action4 ordered nonunique; :>> action5 /* ... */ perform action action6S : ActionDef6S [m] subsets action6 action10; Actions action7S : ActionDef7S [m] :> action7 action action11 { Compartment action8R = action8 action ref action9 : ActionDef9 'action11.1'; action perform action10 'action11.2'; action11 } ... } perform actions ^action2 : ActionDef2 action1 : ActionDef1 [1..*] ordered nonunique action3R : ActionDef3R redefines action3 { action4R : ActionDef4R :>> action4 perform action :>> action5 action1 : ActionDef1 Perform Actions action6S : ActionDef6S [m] subsets action6 [1..*] ordered Compartment action7S : ActionDef7S [m] :> action7 nonunique; /* ... */ action8R = action8 } action11 ... Systems Modeling Language v2.0, Part 1 89 -Element Graphical Notation Textual Notation «view» part0ActionFlowView1 : ActionFlowView «part» part0 : PartDef0 package SwimLanes { parts part def Part0; part1 : PartDef1 part def Part1; part2 : PartDef2 part def Part2; part part0 : PartDef0 perform actions { «action» perform action0; part0::action0 part part1 : PartDef1 { «performer» «performer» perform part0::part1 part0::part2 action0.action1; perform perform actions perform actions action0.action4; «action» «action» } part part2 : action1 action2 PartDef2 { perform «action» «action» action0.action2; action4 action3 perform action0.action3; Perform Actions } Swimlanes } action action0 { action action1; «view» part0ActionFlowView1 : ActionFlowView action action2; action action3; «part» action action4; part0 : PartDef0 parts part1 : PartDef1 first start then part2 : PartDef2 action1; perform actions first action1 «action» then action2; part0::action0 first action2 «performer» «performer» then action3; part0::part1 part0::part2 first action3 perform actions perform actions then action4; «action» «action» first action4 action1 action2 then done; } «action» «action» } action4 action3 Note. In View2, part0 has been elided. 90 Systems Modeling Language v2.0, Part 1 -Element Graphical Notation Textual Notation parameters ^in param5 : ParamDef5 in param1 : ParamDef1 [1..*] ordered nonunique out param2 : ParamDef2 inout param3 : ParamDef3 { return param4 : ParamDef4 in param1 : ParamDef in param6R : ParamDef6R redefines param6 [1..*] ordered Parameters nonunique; in param7R : ParamDef7R :>>param7 Compartment /* ... */ in :>> param8 } in param9S : ParamDef9S [m] subsets param9 in param10S : ParamDef10S [m] :> param10 in param11 : ParamDef11 = expression1 ... «action» action1 : Action1 action action1 : Action1; [guard1] action action2 : Action2; succession action1 «action» if guard1 then action2 : Action2 action2; Actions with and without Conditional or Succession «action» action1 : Action1 action action1 : Action1; if guard1 then action2; [guard1] action action2 : Action2; «action» action2 : Action2 Systems Modeling Language v2.0, Part 1 91 -Element Graphical Notation Textual Notation first start; then fork fork1; fork1 then action1; then action2; «action» «action» action action1; action1 action2 then join1; action action2; join1 then join1; join join1; [guard2] [guard1] then decide decision1; Actions with Control if guard2 then Nodes action3; decision1 if guard1 then action4; «action» «action» action3 action4 action action3; then merge1; merge1 action action4; then merge1; merge merge1; then terminate; Performed By No textual notation Compartment 92 Systems Modeling Language v2.0, Part 1 -Element Graphical Notation Textual Notation «action» actionWithLoop1 attributes x : Integer increment : Integer = 1 y : Integer action actionWithLoop1 { action flow attribute x:Integer; attribute increment:Integer = 1; attribute y:Integer; «assign» first start; Action with Until x := 1 then assign x := 1; Loop (body in then action loop1 textual notation) loop { assign y := 2*x; «loop» then assign x := x loop1 +increment; } until x >= 10; loop body then done; assign y := 2*x } then assign x := x+increment until condition x >= 10 Systems Modeling Language v2.0, Part 1 93 -Element Graphical Notation Textual Notation «action» actionWithLoop1 attributes x : Integer increment : Integer = 1 y : Integer action flow «assign» action actionWithLoop1 { x := 1 attribute x:Integer; attribute increment:Integer = 1; «loop» attribute y:Integer; loop1 first start; Action with Until loop body then assign x := 1; Loop (body in then action loop1 graphical notation) loop { assign y := 2*x; then assign x := x «assign» +increment; } until x >= 10; y := 2*x then done; } «assign» x := x+increment until condition x >= 10 94 Systems Modeling Language v2.0, Part 1 -Element Graphical Notation Textual Notation x:Integer «action» actionWithLoop2 attributes increment : Integer = 1 action actionWithLoop2 { action flow in attribute x:Integer; out attribute y:Integer; «assign» attribute increment:Integer = 1; y := 0 Action with While first start; Loop (body in then assign y := 0; «loop» textual notation) then action loop2 while x < 10 { loop2 assign y := 2*x; while condition then assign x := x < 10 x+increment; } loop body then done; assign y := 2*x } then assign x := x+increment y:Integer Systems Modeling Language v2.0, Part 1 95 -Element Graphical Notation Textual Notation n:Integer «action» actionWithLoop3 action flow action actionWithLoop3 { in attribute «assign» n:Integer; y := 0 out attribute y:Integer; first start; «loop» Action with For then assign y := 0; Loop forLoop1 then action forLoop1 for i : Integer in 1..n for iterator { i : Integer in 1..n assign y := y + i; } loop body then done; assign y := y + i } y:Integer a:Integer action { «if» inout attribute a : Integer; ifThenAction action ifThenAction If-Then Structured if condition if a < 0 { Control Action assign a := -a; a < 0 } then body } assign a := -a 96 Systems Modeling Language v2.0, Part 1 -Element Graphical Notation Textual Notation a:Integer action { «if» in attribute a : Integer; ifThenElseAction out attribute b : if condition Integer; If-Then-Else action a >= 20 ifThenElseAction if a >= Structured Control 20 { then body Action assign b := 100; assign b := 100 } else { assign b := 0; else body } assign b := 0 } b:Integer port viewPort; «accept action» item def Scene; trigger1 Accept Action action trigger1 accept scene : Scene via viewPort scene : Scene via viewPort; port viewPort; «accept action» item def Scene; trigger1 scene : Scene via viewPort action trigger1 accept scene : Scene via scene : Scene viewPort; Accept Action (with succession flow from succession flow to trigger1.scene to next action) action2.scene; scene : Scene action action2 { «action» in item scene : action2 Scene; } item def Picture; port displayPort; «send action» send1 Send Action action send1 send new new Picture() via displayPort Picture() via displayPort; Systems Modeling Language v2.0, Part 1 97 -Element Graphical Notation Textual Notation «action» item def Picture; shoot port displayPort; action shoot { picture : Picture out item picture : Send Action (with Picture; succession flow from } other action) action send1 send via payload displayPort; succession flow from «send action» shoot.picture to send1 send1.payload; shoot.picture via displayPort 98 Systems Modeling Language v2.0, Part 1 -Element Graphical Notation Textual Notation «part» camera item def Scene; = viewPort part camera { receiver port viewPort; port displayPort; «accept action» trigger perform action scene : Scene takePicture { action trigger scene : Scene accept scene : Scene { = in :>> receiver = viewPort; scene } then action focus «action» { focus in item scene = trigger.scene; image out item image; } «succession flow» succession flow Accept and Send image from focus.image to Action Flow shoot.image; «action» action shoot { shoot in item image; out item picture picture; = } then action picture sendPicture send { «send action» in picture :>> payload = shoot.picture; sendPicture in :>> sender = camera.displayPort; } sender } = } part screen { displayPort port displayPort; displayPort } «part» screen 7.17.2 Action Definitions and Usages An action definition or usage (that is not of a more specialized kind) can be declared as a kind of occurrence definition or usage (see 7.9.2 ), using the kind keyword action . An action usage must only be defined by action definitions (of any kind) or KerML behaviors (see [KerML, 7.4.7]). Any directed features declared in the body of an action definition or usage are considered to be owned parameters of the action. Features with direction in are input parameters, those with direction out are output parameters, and those with direction inout are both input and output parameters. Systems Modeling Language v2.0, Part 1 99 -action def TakePicture { // The following two features are considered parameters. in scene : Scene; out picture : Picture; bind focus.scene = scene; action focus : Focus { in scene; out image; } first focus then shoot; flow focus.image to shoot.image; action shoot : Shoot { in image; out picture; } bind picture = focus.picture; } If an action definition has superclassification relationships (implicit or explicit) with other action definitions (or KerML behaviors), then each of the owned parameters of the specialized action definition must redefine, in order, the parameter at the position of each of the general action definitions. The redefining parameters must have the same direction as the redefined parameters. action def A { in a1; out a2; } action def B { in b1; out b2; } action def C specializes A, B { in c1 redefines a1 redefines b1; out c2 redefines a2 redefines b2; } If an action definition has a single superclassification, then the specialized action definition may declare fewer owned parameters than the general action definition, inheriting any additional parameters from the general definition (which are considered to be ordered after any owned parameters). If there is more than one superclassification, then every parameter from every general action definition must be redefined by an owned parameter of the specialized action definition. If the required redefinitions are not explicitly declared for a parameter, then the parameter is considered to implicitly have redefinitions sufficient to meet the stated requirements. action def A1 :> A { in aa; } // aa redefines A::a1, A::a2 is inherited. action def B1 :> B { in b1; out b2; inout b3; } // Redefinitions are implicit. action def C1 :> A1, B1 { in c1; out c2; inout c3; } If an action usage has any type of specialization relationship (i.e., feature typing, subsetting or redefinition, implicit or explicit) with an action definition or usage (or KerML behavior or step), the rules for the redefinition of the parameters of the general definitions and usages are the same as given for the redefinition of parameters of an action definition above. action focus : Focus { // Parameters redefine parameters of Focus. in scene; out image; } action refocus subsets focus; // Parameters are inherited. Binding connection usages (see 7.13.3 ) and flow usages (see 7.16 ) can be used to connect subactions in the body of an action definition or usage. In addition, the feature value shorthand for binding (see 7.13.4 ) is often useful for action parameters. action providePower : ProvidePower { in fuelCmd : FuelCmd; action generatePower : GeneratePower { in fuelCmd : FuelCmd = providePower::fuelCmd; out generatedTorque : Torque; } 100 Systems Modeling Language v2.0, Part 1 -flow generatePower.generatedTorque to transmitPower.generatedTorque; action transmitPower : TransmitPower { in generatedTorque : Torque; out transmittedTorque; // ... } The base action definition and usage are Action and actions from the Actions library model (see 9.2.10 ). (For other semantic constraints on action usages, see 8.4.13 .) 7.17.3 Control Nodes A control node is a special syntactic notation for an action usage whose definition is a concrete specialization of the abstract action usage ControlAction from the Actions library model (see 9.2.10 ). A control node is declared like a normal action usage (see 7.17.2 ), but using one of the keywords shown in Table 16 instead of the keyword action . A control node can only be declared in the body of an action definition or usage and implicitly subsets the action usage shown in the table corresponding to its keyword, thereby inheriting the corresponding definition. A control node is always composite, so the ref keyword is never used in a control node declaration. A control node declaration can have a body, but only containing annotating elements related to it via annotation relationships (see 8.2.2.4.1 ). Table 16. Control Node Definitions Keyword Subsetting Definition merge Actions::Action::merges Actions::MergeAction decide Actions::Action::decisions Actions::DecisionAction join Actions::Action::joins Actions::JoinAction fork Actions::Action::forks Actions::ForkAction Control nodes are used to control the sequencing of other action usages connected to them via sucessions. The following rules apply to these connections. 1. Incoming successions to a merge node must have source multiplicity 0..1 and subset the incomingHBLink feature inherited by MergeAction from the Kernel Semantic Library Behavior ControlPerformances::MergePerformance (see [KerML, 9.2.9]). 2. Outgoing successions from a decide node must have target multiplicity 0..1 and subset the outgoingHBLink feature inherited from the Kernel Library Behavior ControlPerformances::DecisionPerformance (see [KerML, 9.2.9]). 3. Incoming successions to a join node must have source multiplicity 1..1. 4. Outgoing successions from a fork node must have target multiplicity 1..1. These rules shall be enforced in the abstract syntax, even if not shown explicitly in the concrete syntax notation for a model. (See also 8.4.13.4 on the semantic constraints related to control nodes.) // Both action1 and action2 will proceed concurrently // after fork1. fork fork1; first fork1 then action1; first fork1 then action2; action action1; Systems Modeling Language v2.0, Part 1 101 -action action2; // join1 will be performed after both action1 // and action2 have completed. first action1 then join1; first action2 then join1; join join1; first join1 then decision1; // One of action3 or action4 will be chosen // (non-deterministically) to be performed after decision1. decide decision1; first decision1 then action3; first decision1 then action4; action action3; action action4; // merge1 will be performed after either action3 // or action4 have completed. first action3 then merge1; first action4 then merge1; merge merge1; 7.17.4 Succession Shorthands The basic notation for successions (see 7.13.5 ) may be used to specify the sequencing of action usages within the body of an action definition or usage. There are also additional textual notation shorthands that may be used only within the body of an action definition or usage, as described below. Further, every action inherits the features start and done from the base action definition Actions::Action , which represent the start and end snapshots of the action. The source of a succession may be specified separately from the target by using the keyword first followed by a qualified name or feature chain for the source action usage. Similarly, the target of a succession may be specified separately from the source by using the keyword then followed by a qualified name or feature chain for the target action usage. first action1; then action2; // The above two declarations are together // equivalent to the following single succession. first action1 then action2; The then keyword may also be followed by a complete action usage declaration, rather than just the name. first action1; then action action2; // The above two declarations are together // equivalent to the following. first action1 then action2; action action2; The then shorthand can be used lexically following any action usage, not just following a first declaration, with the preceding action usage becoming the source of the succession. This is particularly useful when a sequence of actions is to be performed successively or in a loop. 102 Systems Modeling Language v2.0, Part 1 -first start; then merge 'loop'; then action initialize; then action monitor; then action finalize; then 'loop'; The source of a succession must be an occurrence usage. Therefore, the source of a succession represented using the then shorthand is actually determined as the nearest occurrence lexically previous to the then , skipping over any intervening non-occurrence usages (and conditional successions, see 7.17.5 ). Since a succession is not an occurrence usage, this allows several then successions to be placed in a sequence after a common source action usage. This is particularly useful for specifying multiple successions outgoing from fork and decide nodes. // The two successions following fork1 both have // fork1 as their source. fork fork1; then action1; then action2; action action1; then join1; action action2; then join1; join join1; // The two successions following decision1 both have // decision1 as their source. then decide decision1; then action3; then action4; action action3; then merge1; action action4; then merge1; merge merge1; 7.17.5 Conditional Successions A succession within the body of an action definition or usage may be given a guard condition. A guard is given as a Boolean-valued expression preceded by the keyword if . It is placed in the declaration of the succession (see 7.13.5 ) after the specification of the source of the succession and before the specification of the target. succession conditionalOnActive first initialize if isActive then monitor; Such a conditional succession actually declares a special transition usage (see also 7.18.3 on transition usages in state models), which is a kind of action usage defined by the action definition DecisionTransitionAction from the Actions model library (see 9.2.10 ). The transition usage performs the evaluation of the guard expression and, if true, asserts the existence of the succession. (See 8.4.13.3 on the semantic constraints related to decision transition usages used for conditional successions.) As usual, if the declaration part is empty, the keyword succession may be omitted. The source for the succession may then be further omitted, in which case the source is identified from a lexically previous action usage, as for the then shorthand described in 7.17.4 . Further, the keyword else may be used in place of a guard expression to indicate a succession to be taken if the guards evaluate to false on all of an immediately preceding set of conditional Systems Modeling Language v2.0, Part 1 103 -successions. However, the target of a conditional succession must be specified as a qualified name or feature chain and cannot be a full action usage declaration, even when the shorthand notation is used. The conditional succession shorthand notation is particularly useful for notating several conditional successions outgoing from a decide node. merge 'loop'; action checkLevel { out level; } decide; if level <= refillLevel then refill; if level >= maxLevel then drain; else continue; action refill; then 'loop'; action drain; then 'loop'; action continue; 7.17.6 Perform Action Usages A perform action usage is declared as an action usage (see 7.17.2 ) but using the kind keyword perform action instead of just action . A perform action usage is a kind of event occurrence usage (see 7.9.5 ) for which the event occurrence is an action usage, known as the performed action. As for an event occurrence usage, the performed action is related to the perform action usage by a reference subsetting relationship, specified textually using the keyword references or the symbol ::> . Or, if the perform action usage has no such reference subsetting, then the performed action is the perform action usage itself. part def Vehicle { perform action powerVehicle references VehicleActions::providePower; abstract perform action moveVehicle; // Performed action is itself. } A perform action usage may also be declared using just the keyword perform instead of perform action . In this case, the declaration does not include either a name or short name. Instead, the performed action of the perform action usage is identified by giving a qualified name or feature chain immediately after the perform keyword. part vehicle : Vehicle { // The performed action is VehicleActions::move. perform VehicleActions::move :> Vehicle::moveVehicle; } If a perform action usage is used in the body of a part definition or usage, then the part is considered to be the performer of the performed action (see also 8.4.13.11 on the semantics of perform action usages). A perform action usage may also be used in the body of another action definition or usage, in which case it acts like a referential "call" of the performed action by the containing action. action initialization { in item device; perform Utility::startUpCheck { in component = device; out status; } ... } 104 Systems Modeling Language v2.0, Part 1 -The ref keyword may be used in the declaration of a performed action usage, but a perform action usage is always referential, whether or not ref is included in its declaration. 7.17.7 Send Action Usages A send action usage is declared as an action usage (see 7.17.2 ) implicitly defined by the action definition SendAction from the Actions library model (see 9.2.10 ). A SendAction has three input parameters: 1. a set of payload values 2. a sender occurrence 3. a receiver occurrence The behavior of a SendAction is to transfer the payload from the sender to the receiver. In the textual notation for a send action usage, values for the three SendAction parameters are given after the action declaration part, identified by the keywords send (payload), via (sender) and to (receiver). If the declaration part is empty, then the action keyword may be omitted. part monitor { action sendReadingTo { in part destination; perform getReading { out reading : SensorReading; } // Send a reading from the monitor to the destination. action sendReading send getReading.reading via monitor to destination; // The following send action is equivalent to the // one above, but without a name. send getReading.reading via monitor to destination; } } Alternatively, values can be provided for send-action parameters using flows or bindings, as in a regular action usage (see 7.17.2 ). part monitor { action sendReadingTo { in part destination; perform getReading { out reading : SensorReading; } flow getReading.reading to sendReading.payload; action sendReading send { in payload; in sender = monitor; in receiver = destination; } send getReading.reading { // payload parameter is already bound in the "send" declaration. in sender = monitor; in receiver = destination; } } } A send action usage can specify both a sender ( via ) and receiver ( to ), but it will generally give only one or the other. When a send action usage is directly or indirectly a composite feature of a part definition or usage, then the Systems Modeling Language v2.0, Part 1 105 -default for the sender ( via ) of the send action usage is the containing part, not the send action itself. This is known as the default sending context. part monitor { action sendReadingTo { in part destination; perform getReading { out reading : SensorReading; } // The sender for the following send action is, by default, // the sending context, which is the part "monitor". send getReading.reading to destination; } } If a send action usage is not in the composition hierarchy of a part definition or usage (or any item definition or usage), then the sending context is the highest-level containing action usage. Note that a perform action usage is always referential, so that the sending context for subactions of a perform action usage is the perform action usage itself, not the containing performing part. part monitor { ref part destination; perform action sending { perform getReading { out reading : SensorReading; } // The sender for the following send action is, by default, // the sending context, which is the action "sending", // not the part "monitor". send getReading.reading to destination; } } When sending through a port (see 7.12 on ports), the port usage will usually be the sender ( via ), with the actual receiver determined by interface connections having the port usage as their source (see 7.14 ). When sending via a port, the send action is allowed to also include an explicit receiver ( to ), but this must still be another port connected to the sending port by an interface. part def MonitorDevice { port readingPort; action monitoring { perform getReading { out reading : SensorReading; } send getReading.reading via readingPort; } } A send action usage must be one of the following: 1. An owned feature of an action definition or usage. 2. The owned entry , do or exit action of a state definition or usage (see 7.18 ). 3. The owned effect action of a transition usage (see 7.18 ). The base send action usage is sendActions from the Actions library model (see 9.2.10 ), which is defined by SendAction . (See 8.4.13.5 for additional semantic constraints on send action usages.) 7.17.8 Accept Action Usages An accept action usage is declared as an action usage (see 7.17.2 ) implicitly defined by the action definition AcceptAction from the Actions library model (see 9.2.10 ). An AcceptAction has two parameters: 106 Systems Modeling Language v2.0, Part 1 -1. an output parameter for a set of payload values 2. an input parameter giving a receiver occurrence The behavior of an AcceptAction is to accept the transfer of a payload received by the given receiver, and then output that payload. The textual notation for an accept action usage includes special notation for declaring a usage-specific payload parameter and giving a value for the receiver parameter. The payload parameter declaration is identified by the keyword accept , and the expression giving the transfer receiver is identified by the keyword via . If the action declaration part is empty, then the action keyword may be omitted. The payload parameter declaration for an accept action usage identifies the type of values accepted by the accept action. It is declared as a reference usage (see 7.6 ), but without the ref keyword or any body. If the payload parameter declaration has the form of a single qualified name (and, optionally, a multiplicity), then the qualified name is interpreted as the definition (type) of the payload parameter (not its name). part controller { action accepting { // ... action acceptReading accept reading : SensorReading via controller; // The following accept action is equivalent to the // one above, but it does not name the accept action or // the payload parameter. accept SensorReading via controller; // ... } } Alternatively, a value can be provided for the receiver parameter (but not the payload parameter) using a flow or binding, as for a parameter of a regular action usage (see 7.17.2 ). part controller { action accepting { //... accept SensorReading { in receiver = controller; } } A payload parameter declaration can also include a feature value (see 7.13.4 ). In this case, the accept action usage will only accept exactly the value that is the result of the feature value expression. The following special notations can also be used for the feature value of a payload parameter: • Change trigger. A change trigger is notated using the keyword when followed by an expression whose result must be a Boolean value. A change trigger evaluates to a ChangeSignal (as defined in the Observation model from the Kernel Semantic Library Library [KerML, 9.2.13]) that is sent when the result of the given expression changes from false to true (or sent immediately if the expression is true when first evaluated). • Absolute time trigger. An absolute time trigger is notated using the keyword at followed by an expression whose result must be a TimeInstantValue (see 9.8.8 ). An absolute time trigger evaluates to a TimeSignal (as defined in the Trigger model from the Kernel Semantic Library Library [KerML, 9.2.14]) that is sent when the current time (relative to the localClock , which defaults to the defaultClock , see 9.8.8 ) reaches the TimeInstantValue that is the result of the given expression. • Relative time trigger. A relative time trigger is notated using the keyword after followed by an Expression whose result must be a DurationValue (see 9.8.8 ). A relative time trigger evaluates to a Systems Modeling Language v2.0, Part 1 107 -TimeSignal (as defined in the Trigger model from the Kernel Semantic Library Library [KerML, 9.2.14]) that is sent when the current time (relative to the localClock , which defaults to the defaultClock , see 9.8.8 ) reaches the TimeInstantValue that is computed as the result of the given expression added to the time at which the time trigger is evaluated. part controller { in level : Real; attribute threshold : Real; action { // Both of the following accept actions trigger (once) when the // given expression becomes true. accept : ChangeSignal = Triggers::triggerWhen({ level > threshold }); accept when level > threshold; // The following accept action triggers at the given date and time. accept at Iso8601DateTime("2024-02-01T00:00:00Z"); // The following accept action triggers 30 seconds after the evaluation // of its time trigger. accept after 30 [s]; } } When an accept action usage is directly or indirectly a composite feature of a part definition or usage, then the default for the receiver ( via ) of the accept action usage is the containing part, not the accept action itself. This is known as the default accepting context. part controller { action accepting { // The receiver for the following accept action is, by default, // the accepting context, which is the part "controller". accept SensorReading; // ... } } If an accept action usage is not in the composition hierarchy of a part definition or usage (or any item definition or usage), then the accepting context is the highest-level containing action usage. Note that a perform action usage is always referential, so that the accepting context for subactions of a perform action usage is the perform action usage itself, not the containing performing part. part controller { perform action accepting { // The receiver for the following accept action is, by default, // the accepting context, which is the "accepting" action, // not the part "controller". accept reading : SensorReading; // ... } } When accepting through a port (see 7.12 on ports), the port usage is the receiver ( via ). part def ControllerDevice { port sensorPort; action control { accept reading : SensorReading via sensorPort; 108 Systems Modeling Language v2.0, Part 1 -} } An accept action usage must be one of the following: 1. An owned feature of an action definition or usage. 2. The owned entry , do or exit action of a state definition or usage (see 7.18 ). 3. The owned effect action or accept action of a transition usage (see 7.18 ). The base accept action usage is acceptActions from the Actions library model (see 9.2.10 ), which is defined by AcceptAction . (See 8.4.13.6 for additional semantic constraints on accept action usages.) 7.17.9 Assignment Action Usages An assignment action usage is declared as an action usage (see 7.17.2 ) that is implicitly defined by the action definition AssignmentAction from the Actions model (see 9.2.10 ). An AssignmentAction sets a referent feature of a target occurrence to a new assigned value. In the textual notation for an assignment action usage, these three things are specified in an assignment part between the usual action declaration part and the action body (if any). An assignment part consists of the keyword assign followed by an expression that evaluates to the target and a feature chain identifying the referent, separated by a dot ( . ), followed by the symbol := and an expression whose result is the assigned value. If the declaration part is empty, then the action keyword may be omitted. action def UpdateVehiclePosition { in part sim : Simulation; in attribute deltaT : TimeDurationValue; // The target of the assignment below is "sim". // The referent feature chain is "vehicle.position". assign sim.vehicle.position := sim.vehicle.position + sim.vehicle.velocity * deltaT; // After the above assignment "sim.vehicle.position" has the // value of the result of the assigned value expression, // evaluated at the time of the assignment. } action def RecordNames { in item record : Record; in item entries : Entry[1..*]; // "entries.name" evaluates to the names of all entries. // These values are assigned to the "names" feature of "record". assign record.names := entries.name; } To be assignable, the target expression of an assignment action usage must evaluate to an occurrence, and the last feature in the referent feature chain must be allowed to have values that vary over time (see 7.9.2 ). If the target expression of an assignment action usage is omitted, then the target is implicitly the occurrence owning the assignment action usage. action counter { // This attribute is initialized using a feature value. attribute count : Natural := 0; // The target of the following assign action usage is // implicitly the action "counter". assign count := count + 1; // ... } Systems Modeling Language v2.0, Part 1 109 -Every assignment action usage must be one of the following: 1. An owned feature of an action definition or usage. 2. The owned entry , do or exit action of a state definition or usage (see 7.18 ). 3. The owned effect of a transition usage (see 7.18 ). The base assignment action usage is assignmentActions from the Actions library model (see 9.2.10 ). (See 8.4.13.7 for other semantic constraints on assignment action usages.) 7.17.10 Terminate Action Usages A terminate action usage is declared as an action usage (see 7.17.2 ) implicitly defined by the action definition TerminateAction from the Actions library model (see 9.2.10 ). A TerminateAction has a single parameter that identifies a terminated occurrence. The behavior of a TerminateAction is to force the lifetime of the terminated occurrence to end by the completion of the TerminateAction (see also 7.9.1 on the occurrence lifetimes). If the terminated occurrence is an action, this is equivalent to terminating the performance of the action. part processor { private ref action process : ProcessWorkflow; action startProcessing { assign process := new ProcessWorkFlow(); } action terminateProcessing { // The following terminate action has the name "terminate1". action terminate1 terminate process; // Terminates "process" action. // The following terminate action is unnamed. terminate this; // Terminates "processor" part. } } In the textual notation for a terminate action usage, the value for the terminated occurrence parameter is given after the action declaration part, after the keyword terminate . If the declaration part is empty, then the action keyword may be omitted. action def MonitoredActivity { merge continue; then action performCriticalActivity { perform action monitorCriticalActivity; perform action criticalActivity; then terminate; // Terminates "performCriticalActivity" even if // "monitorCriticalActivity" is still ongoing. } then decide; if continueActivity() then continue; else stop; action stop terminate; // Terminates performance of "MonitoredActivity". } If a value is not given for the terminated occurrence parameter, then the default is to terminate the immediately containing action of the terminate action usage. Note that this means that, if the terminate action usage is in a nested action, it is that nested action that is terminated, not any containing actions of the nested action. Alternatively, a value can be provided for the terminated occurrence parameter using a flow. action def TerminateProcessByID { in attribute id : ProcessID; perform action getProcessByID { in processID = id; 110 Systems Modeling Language v2.0, Part 1 -out process; } flow getProcessByID.process to terminateProcess.terminatedProcess; action terminateProccess terminate { in terminatedProcess; } } The base terminate action usage is terminateActions from the Actions library model (see 9.2.9), which is defined by TerminateAction . (See 8.4.13.8 for additional semantic constraints on terminate action usages.) 7.17.11 If Action Usages An if action usage is an action usage that is implicitly defined by one of the action definitions IfThenAction or IfThenElseAction from the Actions model (see 9.2.10 ). In the textual notation, an if action usage can have a typical action declaration (see 7.17.2 ), but without the usual action body. Instead, the action declaration part is followed by the keyword if , which introduces a Boolean-valued condition expression, followed by a then clause and, for an IfThenElseAction , the keyword else and an else clause. The behavior of an if action usage is to first evaluate the condition expression. If the result is true, then the then-clause is performed, otherwise the else-clause is performed, if there is one. Each of the then-clause and the else-clause is itself notated as an action usage, but with the body required to be given using curly braces { … } , with a semicolon not allowed for an empty body. action test if speed < lowerLimit action increase : IncreaseSpeed { } else action main : MaintainSpeed { } If the if action usage does not include a declaration part, the leading action keyword can be omitted. If either or both of the clauses have no declaration part, then the action keyword can be omitted for them, too, leaving only their bodies surrounded by curly braces. if selectedSensor != null { assign reading := selectedSensor.reading; } else { assign reading := undefinedValue; } With one except, only the basic form of action declaration can be used for the clauses of an if action usage, not the special notations for perform action usages, send action usages, etc. The except is that, if the else-clause is itself an if action usage, then the special if action usage notation can be used. This allows for a typical "else if" structure for expressing the performance of a sequence of multiple tests. if threat.level == high then { perform soundAlarm {in cause = threat;} } else if threat.level == medium then { action sendNotification {in msg = threat;} } else { action beginMonitoring {in target = threat;} } 7.17.12 Loop Action Usages A loop action usage is an action usage that is implicitly defined by one of the concrete specializations of the abstract action definition LoopAction from the Actions model (see 9.2.10 ). There are two forms of loop action usages, the while loop action usage and the for loop action usage. In the textual notation, both kinds of loop action can have Systems Modeling Language v2.0, Part 1 111 -a typical action declaration (see 7.17.2 ), but without the usual action body. Instead, the body is replaced with special notations specific to each kind of LoopAction . While Loops A while loop action usage is implicitly defined by the WhileLoopAction specialization of LoopAction . For a while loop action usage, the action declaration part is followed by the keyword while , which introduces a Boolean- valued while expression, followed by a body clause, and then, optionally, the keyword until , which introduces a Boolean-valued until expression terminated with a semicolon. The behavior of the while loop action usage is to repeatedly perform the body clause as long as the while expression evaluates to true and the until expression (if there is one) evaluates to false. The while expression is evaluated before the first iteration of the body clause, but the until expression is not evaluated for the first time until after the first iteration of the body clause (if the while expression evaluates to true). Similarly to the then and else clauses of an if action usage (see 7.17.11 ), the body clause is itself notated as an action usage, but with its body required to be given using curly braces { … } , with a semicolon not allowed for an empty body. action advance while t < endTime action step { perform advanceState { :>> stateVector = systemState; :>> deltaT = dt; } then assign t := t + dt; } until stateVector.position >= endPosition; The action keyword can be omitted for the while loop action usage itself and/or for the body clause, if they have no action declaration part. while not ready { assign ready := poll(device); } The keyword loop may be used as a shorthand for while true . This is useful for a while loop that is designed to be non-terminating or will be terminated with just an until expression. loop { assign charge := MonitorBattery(); then if charge < 100 { action AddCharge; } } until charge >= 100; For Loops A for loop action usage is implicitly defined by the ForLoopAction specialization of LoopAction . For a for loop action usage, the action declaration part is followed by the keyword for , which introduces a loop variable declaration followed by the keyword in and a sequence expression, and, after that, a body clause. The behavior of the for loop action usage is to first evaluate the sequence expression, which should result in a sequence of values. The body clause is then performed iteratively, with the loop variable assigned to each value sequentially for each iteration. As for a while loop action usage, the body clause is itself notated as an action usage, but with its body required to be given using curly braces { … } , with a semicolon not allowed for an empty body. action dynamicScenario for power : PowerValue in powerProfile 112 Systems Modeling Language v2.0, Part 1 -action dynamicsStep { assign position := ComputeDynamics(position, power); } The action keyword can be omitted for the for loop action usage itself and/or for the body clause, if they have no action declaration part. for power : PowerValue in powerProfile { assign position := ComputeDynamics(position, power); } The .. operator can be used to construct a sequence of Integer values between two bounds (inclusive), which can be useful as the sequence expression of a for loop (especially for indexing). for i in 1..scenario->size() { assign positionList := positionList->including(scenario.postion#(i)); assign velocityList := velocityList->including(scenario.velocity#(i)); } 7.18 States 7.18.1 States Overview Metamodel references: • Textual notation, 8.2.2.18 • Graphical notation, 8.2.3.18 • Abstract syntax, 8.3.18 • Semantics, 8.4.14 States A state definition is a kind of action definition (see 7.17 ) that defines the conditions under which other actions can execute. A state usage is a usage of a state definition. State definitions and usages are used to describe state-based behavior, where the execution of any particular state is triggered by events. A state definition or usage can contain specially identified action usages that are only performed while the state is activated. • An entry action starts when the state is activated. • A do action starts after the entry action completes and continues while the state is active. • An exit action starts when the state is exited, and the state becomes inactive once the exit action is completed. State definitions and usages follow the same patterns that apply to structural elements (see 7.6 ). States can be decomposed into lower-level states to create a hierarchy of state usages, and states can be referenced by other states. In addition, a state definition can be specialized, and a state usage can be subsetted and redefined. This provides enhanced flexibility to modify a state hierarchy to adapt to its context. Exhibited States A state usage can be a feature of a part definition or a part usage, which can exhibit a state by referencing the state usage or by containing an owned state usage. Whether owned or referenced, the state usage that the part exhibits can represent a top state in a hierarchy of state usages. Systems Modeling Language v2.0, Part 1 113 -An exhibit state usage is a state usage that specifies that a state is exhibited by the owner of the exhibit state usage. An exhibit state usage is referential, which allows the exhibited state behavior to be defined in a different context than that of the exhibitor (perhaps by a state usage in a state decomposition hierarchy). However, if the owner of the exhibit state usage is an occurrence, then the referenced state performance must be carried out entirely within the lifetime of the performing occurrence. In particular, an exhibit state usage can be a feature of a part definition or usage, specifying that the referenced state is exhibited by the containing part. Typically, the exhibited state and its substates will reflect conditions of the exhibiting part, such as the operating states of a vehicle. The values of the exhibit state usage are then references to occurrences of the state when the exhibiting part is "in" that state. Transitions State usages can be connected by transition usages, which can activate and deactivate the state usages. The triggering of a transition usage from its source state usage to its target state usage deactivates the source state and activates the target state. The trigger of a transition usage is an accept action usage (see 7.17 ), which accepts an incoming transfer. The transition usage can contain a guard condition, which is a Boolean expression (see 7.19 ) that must evaluate to true for the transition to occur. In addition, a transition usage may specify an effect action usage that starts if the transition is triggered, after the source state is deactivated, and must complete before the target state is activated. If the triggering transfer of a transition has a payload, then this payload is available for use in the guard condition and effect action of the transition, and after the transition completes. Parallel States A parallel state is one whose substates are performed concurrently. As such, no transitions are allowed between the substates of a parallel state. In contrast, if a non-parallel state has substates then, exactly one of the substates shall be active at any point in time in the lifetime of the containing state after completion of the entry action (if any). Table 17. States – Representative Notation Element Graphical Notation Textual Notation «state def» StateDef1 state def StateDef1; «state def» state def StateDef1 { State Definition /* members */ StateDef1 } compartment stack ••• «state» state state1 : state1 : StateDef1 StateDef1; «state» state state1 : StateDef1 State { state1 : StateDef1 /* members */ compartment stack } ••• 114 Systems Modeling Language v2.0, Part 1 -Element Graphical Notation Textual Notation «state» state state1 : StateDef1 state1 : StateDef1 { state actions entry action1; State with entry, do do action2; and exit actions. entry action1 exit action3; do action2 } exit action3 state compositeState1 { «state» entry; then state1; compositeState1 state state1; transition State with Graphical first state1 state1 Compartment with accept trigger1 standard state if guard1 transition view do action1 trigger1[guard1] / action1 (sequential states) then state2; state state2; state2 then done; } «state» compositeState2 state compositeState2 «parallel» parallel { state state1 { entry; then «state» state1 State with Graphical 'state1.1'; Compartment with state 'state1.1'; «state» state1.1 } standard state state state2 { transition view entry; then (parallel states) 'state2.1'; «state» state2 state 'state2.1'; } «state» state2.1 } Systems Modeling Language v2.0, Part 1 115 -Element Graphical Notation Textual Notation state state1 : State1; state state2 : State2; transition first state1 «state» accept trigger1 if guard1 state1 : State1 do action1 then state2; trigger1[guard1] / action1 Transition or «state» state state1 : State1; accept trigger1 state2 : State2 if guard1 do action1 then state2; state state2 : State2; «part» part1 state def State1; state state1 : State1; «exhibit» Exhibit (shorthand part part1 { notation) exhibit state1; } «state» state1 : State1 «part» part1 state def State1; part part1 : Part1 { exhibit state state1 Exhibit State : State1; } «exhibit state» state1 : State1 116 Systems Modeling Language v2.0, Part 1 -Element Graphical Notation Textual Notation states ^state2 : StateDef2 state1 : StateDef1 [1..*] ordered nonunique { state state1 : state3R : StateDef3R redefines state3 StateDef [1..*] state4R : StateDef4R :>> state4 ordered nonunique; :>> state5 /* ... */ state6S : StateDef6S [m] subsets state6 exhibit state States Compartment state10; state7S : StateDef7S [m] :> state7 state state11 { state8R = state8 state 'state11.1'; ref state9 : StateDef9 state 'state11.2'; exhibit state10 } state11 } ... exhibit states ^state2 : StateDef2 state1 : StateDef1 [1..*] ordered nonunique state3R : StateDef3R redefines state3 state4R : StateDef4R :>> state4 :>> state5 { state6S : StateDef6S [m] subsets state6 exhibit state state1 state7S : StateDef7S [m] :> state7 : state8R = state8 StateDef [1..*] Exhibit States state11 ordered nonunique; Compartment /* ... */ ... } exhibits ^state2 state1 ... exhibited by Exhibited By item1 : ItemDef1 No textual notation Compartment 7.18.2 State Definitions and Usages A state definition or usage is declared as an action definition or usage (see 7.17.2 ), but using the keyword state instead of action . In addition, entry, do and exit actions can be declared (at most one of each) in the body of a state definition or usage, using the keywords entry action , do action , and exit action , followed by an action declaration and body, in the usual form. Systems Modeling Language v2.0, Part 1 117 -state def Exercising { entry action warmup : WarmUp; do action exercise : Exercise { action strengthTraining; then action cardioTraining; } exit action cooldown : Cooldown; } In addition to the generic action notation as above, the special notations for send action usages (see 7.17.7 ), accept action usages (see 7.17.8 ), and assignment action usages (see 7.17.9 ) can be used for entry, do, and exit actions. state def Operating { entry assign stateCode := StateCodes::Operating; do send new ReadySignal() to Controller; } The entry , do , and exit keywords can also be used without any action keyword. If the keyword is immediately followed by a semicolon ; , then they are empty actions. If they are followed by a qualified name or feature chain for an action usage, then this is a shorthand for relating the entry, do, or exit action to the identified action usage via reference subsetting (see also 7.13.2 ). action monitorTemperature; state def TurnedOn { // This is an empty entry action. entry; // The following is equivalent to // do action references monitorTemperature; do monitorTemperature; } A state definition or usage may hierarchically contain state usages in its body. By default, these substate usages are considered to be exclusive, that is, their performances do not overlap in time. The initial state usage to be performed is indicated by a succession (see 7.13.5 ) from the entry action to that state usage, representing that this is the state that is entered on completion of the entry action. If the containing state has no substantive entry action, then an empty entry action may be used as the source of the succession. A shorthand may also be used for a succession whose source is the entry action, consisting of the keyword then followed by a qualified name or feature chain for the target state usage, placed immediately after the entry action declaration (see also 7.17.4 ). state def OperationalStates { entry action initial; then off; // The above shorthand is equivalent to // first initial then off; state off; state starting; state on; } Conditional successions (see 7.17.5 ) may be used when the initial state to be entered depends on some condition. state def OperationalStates { entry action initial { out attribute isStarting : Boolean; } if not initial.isStarting then off; if initial.isStarting then starting; state off; 118 Systems Modeling Language v2.0, Part 1 -state starting; state on; } If the keyword parallel is added to a state definition or usage, just before the body part, then that state definition or usage becomes a parallel state, and its contained state usages can be performed concurrently (that is, "in parallel"). state def VehicleStates parallel { // These substates are performed concurrently. state OperationalStates; state HealthStates; } Transitions between the nested states of a state definition or state usage are indicated using transition usages (see 7.18.3 ). However, no transitions are allowed between the concurrent states nested in a parallel state. The base state definition and usage are StateAction and stateActions from the States library model (see 7.18 ). (For other semantic constraints on state usages, see 8.4.14 .) 7.18.3 Transition Usages A transition usage is also a kind of action usage (see 7.17.2 ) that can be used within non-parallel states. (A parallel state with concurrent substates is not allowed to have transitions to or from its substates.) A transition usage is implicitly defined by the action definition StateTransitionAction from the States library model (see 7.18 ). A transition usage also relates a source state usage to a target state usage, declaring that it is possible to transition from a performance of the source state to a new performance of the target state. A transition usage is identified with the keyword transition . The source and target states are identified using the same keywords as for a succession (see 7.13.5 ), first and then . state def OnOff1 { entry; then off; state off; state on; transition off_on first off then on; transition on_off first on then off; } A transition usage can also have an accepter, which is an accept action usage use to trigger the transition. The accepter action for a transition usage is placed between the source and target parts and notated using the accept keyword, with its payload and receiver parameters specified exactly as discussed in 7.17.8 . item def TurnOn; state def OnOff2 { port commPort; entry; then off; state off; state on; transition off_on first off accept TurnOn via commPort Systems Modeling Language v2.0, Part 1 119 -then on; transition on_off first on accept after 5[min] then off; } A transition usage can also have a Boolean-valued guard expression. The guard expression is evaluated during the performance of the source, and the transition usage is only enabled to possibly cause a transition out of the source state when the guard evaluates to true. The guard expression is given after the keyword if , placed between the source and target parts, after the accepter (if any). state def OnOff3 { in attribute isInitOff : Boolean; in attribute isEnabled : Boolean; port commPort; entry action init; transition first init if isInitOff then off; transition first init if not isInitOff then on; state off; state on; transition off_on first off accept TurnOn via commPort if isEnabled then on; transition on_off first on accept after 5[min] if isEnabled then off; } Note. An entry action can have outgoing transitions, but they will have the same semantics as conditional successions. A transition usage with a source that is not a state usage is not allowed to have an accepter. Finally, a transition usage can have an effect action, which is an action usage that is performed if the transition usage is triggered. An effect action is notated using the keyword do in the same way as a do action on a state definition or usage (see 7.18.2 ). In the textual notation for a transition usage, it is also placed between the source and target parts, after the guard and accepter (if the transition usage has those). action def PowerUp; item def TimeoutSignal; state def OnOff4 { in attribute isInitOff; in attribute isEnabled; port commPort; entry action init; transition first init if isInitOff then off; transition first init if not isInitOff then on; state off; state on; transition off_on 120 Systems Modeling Language v2.0, Part 1 -first off if isEnabled accept TurnOn via commPort do action powerUp : PowerUp; then on; transition on_off first on if isEnabled accept after 5[min] do send new TimeoutSignal() via commPort then off; } In the textual notation, there is also a shorthand for a transition usage without a declaration part, in which both the transition keyword and the source part can be omitted. In this case, the source is taken to be the closest lexically previous state usage, which means the transition usages out of a certain state usage need to be placed essentially immediately after their source states. This notation can also be used when the transition source is the entry action, which is particularly useful, because it means the entry action does not need to be named. state def OnOff5 { in attribute isInitOff; in attribute isEnabled; port commPort; entry; if isInitOff then off; if not isInitOff then on; state off; accept TurnOn via commPort if isEnabled do action powerUp : PowerUp; then on; state on; accept after 5[min] if isEnabled do send new TimeoutSignal() via commPort; then off; } In summary, the guard and accepter of a transition action usage determine whether a transition usage is triggered: 1. A transition usage can only be triggered during a performance of its source. 2. If a transition usage has a guard expression, it can only be triggered if the guard expression evaluates to true. 3. If a transition has an accepter, and it meets the above conditions, then it is triggered if the accepter can accept in incoming transfer via its receiver parameter, in which case the accepter is performed as described in 7.17.8 (see also 8.4.13.6 ). If a transition usage is triggered, then it establishes a succession relationship between the source performance and a new performance of the target, and a transition is performed as follows: 1. If the source state has a do action that is still being performed, that is interrupted. 2. Then, if the source state has an exit action, that is performed. 3. Once that completes, if the transition usage has an effect action, that is performed. 4. Once that completes, if the target state has an entry action, that is performed. 5. Once that completes, if the target state has a do action, that is performed. Systems Modeling Language v2.0, Part 1 121 -The source of a transition usage must be a state usage, but its target may be an action usage other than a state usage. In particular, a transition to done indicates that the source state is the final state of the containing state performance, though the containing state does not necessarily terminate immediately. Alternatively, a transition to a terminate action (see 7.17.10 ) may be used to immediately terminate the containing state performance if that transition is triggered. item def Abort; state def OnOff6 { port commPort; entry; then off; state off; accept TurnOn via commPort then on; accept Abort via commPort then stop; state on; accept after 5[min] then done; action stop terminate; } 7.18.4 Exhibit State Usages An exhibit state usage is declared as a state usage (see 7.18.2 ) but using the kind keyword exhibit state instead of just state . An exhibit state usage is a kind of perform action usage (see 7.17.6 ) for which the action usage is a state usage, known as the exhibited state. As for a perform action usage, the exhibited state is related to the exhibit state usage by a reference subsetting relationship, specified textually using the keyword references or the symbol ::> . Or, if the exhibit state usage has no such reference subsetting, then the exhibited state is the exhibit state usage itself. part def Vehicle { exhibit state operatingState references VehicleStates::operating; abstract exhibit state monitoringState; // Exhibited state is itself. } An exhibit state usage may also be declared using just the keyword exhibit instead of exhibit state . In this case, the declaration does not include either a name or short name. Instead, the exhibited state of the exhibit state usage is identified by giving a qualified name or feature chain immediately after the exhibit keyword. part vehicle : Vehicle { // The exhibited state is VehicleActions::monitoring. exhibit VehicleStates::monitoring :> Vehicle::monitoringState; } If an exhibit state usage is used in the body of a part definition or usage, then the part is considered to be the performer of the exhibit state usage (see also 8.4.14.4 on the semantics of exhibit state usages). The ref keyword may be used in the declaration of a exhibit state usage, but a exhibit state usage is always referential, whether or not ref is included in its declaration. 7.19 Calculations 7.19.1 Calculations Overview Metamodel references: • Textual notation, 8.2.2.19 • Graphical notation, 8.2.3.19 122 Systems Modeling Language v2.0, Part 1 -• Abstract syntax, 8.3.19 • Semantics, 8.4.15 A calculation definition is a kind of action definition (see 7.17 ) that has a distinguished parameter with direction out called the result parameter (which is usually the only out parameter). A calculation definition specifies a reusable computation that returns a result in the result parameter. A calculation usage is an action usage that is a usage of a calculation definition. In addition to its parameters, a calculation definition or usage may have features that are calculation or action usages that carry out steps in the computation of the result of the calculation. The calculation may also have other features that are used to record intermediate results in the computation. The final result is specified as an expression written in terms of the input parameters of the calculation and any intermediate results. KerML includes extensive syntax for constructing expressions, including traditional operator notations for functions in the Kernel Function Library, which is adopted in its entirety into SysML. In addition, a calculation definition is also a KerML function, and a calculation usage is itself a KerML expression. This allows a calculation definition or usage to also be invoked using the notation of a KerML invocation expression. (See the KerML Specification [KerML, 7.4.9] for a complete description of the KerML expression sublanguage.) Calculation definitions are often used to define mathematical functions, in which case the defined computation should be pure. A pure calculation has the following properties: 1. Two invocations of the calculation definition with the same values for the input parameters always produce the same values for the result parameter. 2. The performance of the calculation does not produce any side effects (that is, it does not effect any occurrence that is not a composite part of its performance or that of a subaction or subcalculation). Any subcalculations or subactions of a pure calculation must also be pure, including the final expression computing the result. Further, the inputs of a pure calculation should either be attributes or the calculation should not rely on features of input occurrences that may change from one invocation of the calculation definition to another. Table 18. Calculations – Representative Notation Element Graphical Notation Textual Notation «calc def» CalcDef1 calc def CalcDef1 { result expression1 expression1 } Calc Definition calc def CalcDef1 { «calc def» /* members */ } CalcDef1 compartment stack ••• Systems Modeling Language v2.0, Part 1 123 -Element Graphical Notation Textual Notation «calc» calc1 : CalcDef1 calc calc1 : CalcDef1 { result expression1 expression1 } Calc calc calc1 : CalcDef1 { «calc» /* members */ } calc1 : CalcDef1 compartment stack ••• 7.19.2 Calculation Definitions and Usages A calculation definition or usage is declared as an action definition or usage (see 7.17.2 ), but using the keyword calc instead of action . As for an action definition or usage, directed usages declared in the body of a calculation definition or usage are consider to be parameters. In addition, the result parameter for a calculation definition or usage can be declared as an out parameter using the keyword return instead of out . Note that a calculation definition or usage always has a result parameter, inherited if not owned. calc def Velocity { in v_i : VelocityValue; in a : AccelerationValue; in dt : TimeValue; return v_f : VelocityValue; } If a calculation definition has superclassification relationships (implicit or explicit) with action definitions (or KerML behaviors), then the rules for the redefinition of the non-result parameters of the calculation definition are the same as for an action definition (see 7.17.2 ). In addition, if a calculation definition specializes other calculation definitions (or KerML functions), then its result parameter redefines the results parameters of the calculation definitions it specializes, regardless of the positions of those parameters. calc def Dynamics { in initialState : DynamicState; in time : TimeValue; return : DynamicState; } calc def VehicleDynamics specializes Dynamics { // Each parameter redefines the corresponding parameter of Dynamics in initialState : VehicleState; in time : TimeValue; return : VehicleState; } If a calculation usage has any type of specialization relationship (i.e., feature typing, subsetting or redefinition, implicit or explicit) with an action definition or usage (or KerML behavior or step), the rules for the redefinition of the parameters of the general definitions and usages are the same as given for the redefinition of parameters of a calculation definition above. calc computation : Dynamics { // Parameters redefine parameters of Dynamics. in initialState; in time; 124 Systems Modeling Language v2.0, Part 1 -return result; } calc vehicleComputation subsets computation { // Input parameters are inherited, result is redefined. return : VehicleState; } The body of a calculation definition or usage is like the body of an action definition or usage (see 7.17.2 ), with the optional addition of the declaration of a result expression at the end, using the expression sublanguage from [KerML, 7.4.9]. The result of the result expression is implicitly bound to the result parameter of the containing calculation definition or usage.. calc def Average { in scores[1..*] : Rational; return : Rational; sum(scores) / size(scores) } Note. A result expression is written without a final semicolon. The result of a calculation definition or usage can also be explicitly bound, particularly using a feature value on the result parameter declaration (see 7.13.4 ). In this case, the body of the calculation definition or usage should not include a result expression. calc def Average { in scores[1..*] : Rational; return : Rational = sum(scores) / size(scores); } The base calculation definition and usage are Calculation and calculations from the Calculations library model (see 7.19 ). 7.20 Constraints 7.20.1 Constraints Overview Metamodel references: • Textual notation, 8.2.2.20 • Graphical notation, 8.2.3.20 • Abstract syntax, 8.3.20 • Semantics, 8.4.16 Constraint Definition and Usage A constraint definition is a kind of occurrence definition (see 7.9 ) that defines a logical predicate. Similar to a calculation definition (see 7.19 ), a constraint definition may have parameters with direction in . A constraint always has an implicit Boolean-value result parameter with direction out . A constraint usage is an occurrence usage that is the usage of a constraint definition. Also similarly to a calculation, a constraint definition or usage may have features that are calculation or action usages that carry out steps in the computation of the result of the calculation. The constraint may also have other features that are used to record intermediate results in the computation. The final result is specified as an expression written in terms of the input parameters of the calculation and any intermediate results. In addition, a constraint definition is also a KerML predicate and a constraint usage is a KerML Boolean expression, which allows a constraint definition or usage to also be invoked using the notation of a KerML invocation expression. Systems Modeling Language v2.0, Part 1 125 -For a given set of input parameter values, a constraint usage is satisfied if its expression evaluates to true and is violated otherwise. The parameters of a constraint usage may be bound to specific features whose values can be constrained by the constraint expression. For the constraint expression {x < y} , the constraint usage may bind x to the diameter of a bolt and bind y to the diameter of a hole that the bolt must fit into. This constraint can then be evaluated to be true or false . E.g., if x is 3 and y is 5 , then the expression x < y evaluates to true, and the constraint is satisfied. In the general case, the expression used to define a constraint can be arbitrarily complicated, as long as the overall expression returns a Boolean value. A constraint usage that is a feature of another definition or usage may also directly reference features of its containing context, in which case it may be used to effectively constrain the values of those features. In a context with the features bolt diameter and hole diameter , a constraint usage may be defined directly without parameters using the expression {'bolt diameter' < 'hole diameter'} . Asserted Constraints In general, a constraint may be satisfied sometimes and violated other times. However, an assert constraint usage asserts that the result of a given constraint must be always true at all times. If, at some point in time, it can be determined that an assert constraint usage evaluates to other than its asserted value, this would be a logical inconsistency in the model. Constraints associated with the laws of physics, for example, should be asserted to be true , because they cannot be violated in any valid model of the real world. However, a constraint can also be asserted simply if its satisfaction is expected to be implied within a model. That way, if the constraint is violated, this can be flagged by tooling as needing resolution. An assert constraint usage can also be negated, which means that the given constraint is asserted to be false rather than true . A negated assert constraint usage can be used to assert that some condition must never happen if the model is logically consistent. Table 19. Constraints – Representative Notation Element Graphical Notation Textual Notation «constraint def» constraint def ConstraintDef1 ConstraintDef1; «constraint def» constraint def Constraint Definition ConstraintDef1 { ConstraintDef1 /* members */ compartment stack } ••• «constraint» constraint constraint1 : constraint1 : ConstraintDef1 ConstraintDef1; «constraint» constraint constraint1 : Constraint ConstraintDef1 { constraint1 : ConstraintDef1 /* members */ compartment stack } ••• 126 Systems Modeling Language v2.0, Part 1 -Element Graphical Notation Textual Notation constraints ^constraint2 : ConstraintDef2 constraint1 : ConstraintDef1 [1..*] ordered nonunique constraint3R : ConstraintDef3R redefines constraint3 { constraint constraint4R : ConstraintDef4R :>> constraint4 constraint1 : :>> constraint5 ConstraintDef1 constraint6S : ConstraintDef6S [m] subsets constraint6 [1..*] constraint7S : ConstraintDef7S [m] :> constraint7 ordered nonunique; Constraints constraint8R = constraint8 /* ... */ Compartment ref constraint9 : ConstraintDef9 assert constraint assert constraint10 constraint10; assert {boolean_expression1} constraint {boolean_expression1} {boolean_expression1} } constraint11 require constraint12 assume constraint13 ... { assert constraint constraint1 : ConstraintDef1 assert constraints [1..*] constraint10 ordered nonunique; Assert Constraints {boolean_expression1} /* ... */ Compartment assert ... constraint {boolean_expression1} } «part» part1 constraint constraint1; part part1 { Assert Constraint «assert» assert constraint1; (shorthand notation) } «constraint» constraint1 7.20.2 Constraint Definitions and Usages A constraint definition or usage can be declared as a kind of occurrence definition or usage (see 7.9.2 ), using the kind keyword constraint . A constraint usage must be defined by a single constraint definition or a KerML predicate (see [KerML, 7.4.8]). Constraint definitions and usages are not calculation definitions and usages, but, like calculation definitions and usages, they are kinds of KerML functions and expressions (a predicate is a kind of function). As such, any directed usages declared in the body of a constraint definition or usage are considered to be owned parameters of the Systems Modeling Language v2.0, Part 1 127 -constraint. Furthermore, every constraint definition and usage has a result parameter, but, since this must have a Boolean type, it is generally not necessary to redeclare it for a constraint definition or usage. The body of a constraint definition or usage is also like the body of a calculation definition or usage (see 7.19.2 ), including the addition of the declaration of a result expression at the end, using the expression sublanguage from [KerML, 7.4.9]. For a constraint definition or usage, the result expression must be Boolean valued. constraint def IsFull { in tank : FuelTank; tank.fuelLevel == tank.maxFuelLevel // Result expression } part def Vehicle { part fuelTank : FuelTank; constraint isFull : IsFull { in tank = fuelTank; } } The base constraint definition and usage are Constraint and constraints from the Constraints model library (see 7.20 ) 7.20.3 Assert Constraint Usages An assert constraint usage is declared like a regular constraint usage (see 8.4.16.2 ), except using the kind keyword assert constraint instead of just constraint . By default, an assert constraint usage asserts that it must evaluate to true at all times. However, an assert constraint usage may be negated by inserting the keyword not between assert and constraint , in which case the assertion is that the assert constraint usage evaluates to false at all times. part testObject { attribute computedMass : MassValue; assert constraint { computedMass >= 0[kg] } // Alternatively, the following is equivalent. assert not constraint { computedMass < 0[kg] } } An assert constraint usage may also be declared using just the keyword assert instead of assert constraint . In this case, the declaration does not include either a name or short name for the assert constraint usage. Instead, the constraint to be asserted is identified by giving a qualified name or feature chain immediately after the assert keyword, and it is then related to the assert constraint usage by a reference subsetting relationship (see also 8.4.5.3 ). A negated assert constraint usage of this form can be constructed using assert not . constraint negativeMass { attribute mass : MassValue; mass < 0[kg] } part testObject { attribute computedMass : MassValue; // The following is equivalent to // assert not constraint references negativeMass { ... } assert not negativeMass { :>> mass = computedMass; } } part alienObject { attribute antiMass : MassValue; // The following is equivalent to // assert constraint references negativeMass { ... } 128 Systems Modeling Language v2.0, Part 1 -assert negativeMass { :>> mass = antiMass; } } 7.21 Requirements 7.21.1 Requirements Overview Metamodel references: • Textual notation, 8.2.2.21 • Graphical notation, 8.2.3.21 • Abstract syntax, 8.3.21 • Semantics, 8.4.17 Requirements A requirement definition is a kind of constraint definition (see 7.20 ) that specifies stakeholder-imposed constraints that a design solution must satisfy to be a valid solution. A requirement definition contains one or more features that are constraint usages designated as the required constraints. These may be specified informally using text statements (commonly known as "shall" statements) or more formally using constraint expressions. A requirement definition may also optionally include assumed constraints. The required constraints of a requirement only apply if all the assumed constraints are satisfied. A requirement usage is a kind of constraint usage (see 7.20 ) that is a usage of a requirement definition in some context. The context for multiple requirements can be provided by a package (see 7.5 ), a part (see 7.11 ) or another requirement. A design solution must satisfy the requirement and all of its member requirements and constraints to be a valid solution. A requirement definition or usage may be decomposed into nested requirement usages, which may themselves be further decomposed. Since a requirement usage is a kind of constraint usage, any nested composite requirement usage is automatically considered to be a required constraint of the containing requirement definition or usage. A requirement definition or usage may also reference another requirement usage as a required constraint. For the overall requirement to then be satisfied, all such composite or referenced requirements must be satisfied. Like any usage element, the features of a requirement usage can redefine the features of its requirement definition. For example, a requirement definition MaximumMass may include the require constraint {massActual <= massRequired} , written in terms of the attribute usages massActual and massRequired . A requirement usage maximumVehicleMass defined by MaximumMass could restrict the subject of the requirement to be a Vehicle , redefine the massActual attribute to be the mass of the subject Vehicle , and redefine the massRequired attribute and bind it to 2000 kilograms. In this way, the requirement definition serves as a requirement template that can be reused and tailored to each context of use. Subjects A requirement definition or usage always has a subject, which is a distinguished parameter that identifies the entity on which the requirement is being specified. A requirement usage can only be satisfied by an entity that conforms to the definition of its subject. For example, if the subject of a requirement is defined to be a Vehicle , then a standard vehicle model or sports vehicle model can satisfy the requirement, as long as these usages are defined by Vehicle or a specialization of it. The subject can also be restricted to be a certain kind of definition element, if it is desired to constrain what kind of entity can satisfy the requirement. For example, the subject can be restricted to be an action, if it is desired to constrain the requirement to be satisfied only by action usages. Constraining the subject of a requirement definition or usage is also useful to allow features of the subject definition to be used in formal expressions for the assumed and required constraints of the requirement. However, this may not Systems Modeling Language v2.0, Part 1 129 -be necessary if the requirement is specified more informally, or in terms of parameters or other features to be bound later. In this case, it is not necessary to explicitly specify the subject of a requirement, in which case it the subject is implicitly assumed to be defined as Anything . Note. Cases also have subjects (see 7.22 ). Actors, Stakeholders and Concerns Actors and stakeholders are additional distinguished parameters that may be specified for a requirement definition or usage. Actor and stakeholder parameters are part usages representing entities that play special roles relative to the requirement definition or usage. A requirement may have multiple actors and stakeholders, some of which may have the same definition, representing the same kind of entity playing different roles relative to the requirement. An actor parameter represents a role played by an entity external to the subject of the requirement but necessary for the satisfaction of the requirement. For example, a requirement whose subject is a Vehicle may also specify an actor that is the Driving Environment . Features of this actor may be used in, for example, the assumed constraints of the requirement, to constrain the environment in which the required constraints apply. The satisfaction of the requirement by a specific subject entity is then relative to the specific environment entity filling the actor role. Note. Actor parameters may also be specified for cases (see 7.22 ) and, in particular, use cases (see 7.25 ). A stakeholder parameter represents a role played by an entity (usually a person, organization or other group) having concerns related to the containing requirement. Stakeholder concerns may also be explicitly modeled as special kinds of requirements. A concern definition is a kind of requirement definition that represents a stakeholder concern. A concern usage is a kind of requirement usage that is a usage of a concern definition. The stakeholder parameters of a concern definition or usage then delineate the stakeholders that have a certain concern. Rather than explicitly referencing specific stakeholders, a requirement definition or usage can be specified as framing the modeled concerns of relevant stakeholders. All the framed concerns of a requirement must then be addressed for the requirement to be satisfied. Note. Stakeholder and concern modeling is frequently used in the context of view and viewpoint modeling (see 7.26 ). A viewpoint is a kind of requirement that frames certain stakeholder concerns to be addressed by one more more views satisfying the viewpoint. Requirement Satisfaction Since a requirement is a kind of constraint, a requirement can be evaluated to be true or false . A requirement is satisfied when it evaluates to true . A satisfy requirement usage is a kind of assert constraint usage (see 7.20 ) that asserts that a requirement is satisfied when a given feature is bound to the subject parameter of the requirement. Other parameters or features of the requirement may also be bound in the body of the satisfy requirement usage. For example, the maximumVehicleMass requirement above could be asserted to be satisfied by a specific vehicle c1 usage, which means that the required constraint {massActual <= massRequired} must be true when massActual is bound to the mass of vehicle c1 . Similarly to an assert constraint usage, a satisfy requirement usage can also be negated. A negated satisfy requirement usage asserts that some entity does not satisfy the given requirement. 130 Systems Modeling Language v2.0, Part 1 -Table 20. Requirements – Representative Notation Element Graphical Notation Textual Notation requirement def «requirement def» RequirementDef1 { RequirementDef1 subject s1 : Subject1; } Requirement Definition «requirement def» requirement def RequirementDef1 RequirementDef1 { /* members */ compartment stack } ••• «requirement» requirement1 : RequirementDef1 «requirement» requirement1 : RequirementDef1 requirement compartment stack requirement1 : RequirementDef1 { ••• subject redefines s1 = mySubject; «requirement» } requirement1 : RequirementDef1 requirement requirement1 Requirement documentation : RequirementDef1 { ••• doc /* ... */ subject redefines s1 subject = mySubject; redefines s1 = mySubject require require2; assume constraint1; require constraints } require2 ••• assume constraints constraint1 ••• «requirement» constraint assumption1 { requirement1 /*...*/ } constraint constraint1 { «assume» «require» /*...*/ } Requirement with requirement requirement1 «constraint» «constraint» { Assume and Require assume assumption1; Constraints assumption1 constraint1 assume constraint assumption2 { /*...*/ } «assume constraint» require constraint1; } assumption2 Systems Modeling Language v2.0, Part 1 131 -Element Graphical Notation Textual Notation concern concern1 { «requirement» subject system1; requirement1 stakeholder operator; } «assume» «frame» constraint assumption1 { Requirement with /*...*/ } Assume, Require «constraint» «concern» requirement requirement1 Constraints and { assumption1 concern1 Frame Concern frame concern1; assume assumption1; «require constraint» require constraint req1Formalization; req1Formalization } requirements ^requirement2 : RequirementDef2 requirement1 : RequirementDef1 [1..*] ordered nonunique { requirement3R : RequirementDef3R redefines requirement3 requirement requirement4R : RequirementDef4R :>> requirement4 requirement1 : :>> requirement5 RequirementDef1 Requirements requirement6S : RequirementDef6S [m] subsets requirement6 [1..*] Compartment requirement7S : ReqiuirementDef7S [m] :> requirement7 ordered nonunique; /* ... */ requirement8R = requirement8 ref requirement9 : RequirementDef9 } requirement11 ... part part1 { satisfy requirement11 by part1 { satisfy requirements bind requirement11 'requirement11-1'.x1 = Satisfy Requirements requirement12 a; Compartment bind ... 'requirement11-2'.x2 = b; } } requirement requirement1; part part1 : Part1 { «part» satisfy requirement1; part1 : Part1 } Satisfy Requirement «satisfy» or (shorthand notation) «requirement» requirement requirement1; requirement1 part part1 : Part1; satisfy requirement1 by part1; 132 Systems Modeling Language v2.0, Part 1 -Element Graphical Notation Textual Notation requirement «part» requirement1; part1 part part1 { Satisfy Requirement satisfy requirement requirement2 references (longhand notation requirement1 { with explicit // parameter reference-subsetting) «satisfy requirement» «requirement» bindings, etc. } requirement2 requirement1 } 7.21.2 Requirement Definition and Usage A requirement definition or usage is declared as a kind of constraint definition or usage (see 7.20.2 ), using the kind keyword requirement . A requirement usage must be defined by a single requirement definition. The informal text of a requirement is given by any documentation comments written in the body of a requirement definition or usage. If a requirement definition or usage is declared with a short name (see 7.2 ), then this is also considered to be its requirement ID. Formally, a requirement is a kind of constraint. However, rather than specifying its constraint expression directly, a requirement constraint is built from two sets of other constraints: the assumed and required constraints of the requirement. The effective constraint for the requirement is them a logical implication: if all the assumption constraints are true, all the required constraints must be true. Required and assumed constraints are declared as composite constraint usages in the body of a requirement definition or usage, by prefixing a regular constraint usage declaration (see 7.20.2 ) with the keyword assume or require . requirement def <'1.1'> MaximumMass { doc /* * Assuming the required mass is greater than 0, * the actual mass shall be less than or equal to * the required mass. */ attribute massActual : MassValue; attribute massRequired : MassValue; assume constraint { massRequired > 0[kg] } require constraint { massActual <= massRequired } } An assumed or required constraint may also be declared using just the keyword assume or require instead of assume constraint or require constraint . In this case, the declaration does not include either a name or short name for the constraint usage. Instead, the constraint to be assumed or required is identified by giving a qualified name or feature chain immediately after the assume or require keyword, and it is then related to the assumed or required constraint usage by a reference subsetting relationship (see also 8.4.5.3 ). constraint massIsPositive { attribute mass : MassValue; mass > 0[kg]; } constraint massLimit { attribute mass : MassValue; attribute massLimit : MassValue; massActual <= massRequired Systems Modeling Language v2.0, Part 1 133 -} requirement def <'1.1'> MaximumMass { attribute massActual : MassValue; attribute massRequired : MassValue; assume massIsPositive { :>> mass = massRequired; } require massLimit { :>> mass = massActual; :>> massLimit = massRequired; } } The subject of a requirement definition or usage is modeled as its first parameter. Following the general rule for parameters (see 7.17.2 ), the subject parameter of a requirement definition or usage will redefine the subject parameter of any requirement definitions or usages that it specializes. The base requirement definition in the Requirements library model specifies the most general possible subject, with the default name subj and the most general type Anything , and this can then be further specialized in specific requirement definitions and usages. A subject parameter is always an in parameter, so it is not necessary to declare it with an explicit direction. Instead, the keyword subject is used to identify the declaration of a subject parameter, which must come before the declaration of any other parameters in a requirement definition or usage. requirement <'v1.1'> vehicleMaximumMass : MaximumMass { doc /* The total mass of a Vehicle shall be no greater than * its required mass. */ subject vehicle : Vehicle; attribute :>> massActual = vehicle.totalMass; attribute :>> massRequired = 2000[kg]; // Required and assumed constraints are inherited. } A requirement definition or usage may also have one or more actor or stakeholder parameters. Similarly to the declaration of a subject parameter, these distinguished parameters are declared using the keywords actor and stakeholder rather than explicitly declaring their direction. Actor and stakeholder parameters are part usages, so they must be (explicitly or implicitly) defined by part definitions (see 7.11.2 ). requirement def BrakingRequirement { subject vehicle : Vehicle; actor environment : 'Driving Environment'; stakeholder driver : Person; attribute speedLimit : SpeedValue; attribute maxBrakingDistance : DistanceValue; assume constraint { doc /* The environment conditions are poor. */ } assume constraint { doc /* The driver is an occupant of the vehicle. */ } assume constraint { doc /* The vehicle speed is less than the speed limit. */ } require constraint { doc /* The vehicle shall brake from its initial speed to zero * speed in a distance less than the maxBrakingDistance. */ 134 Systems Modeling Language v2.0, Part 1 -} } A composite requirement usage nested in a requirement definition or usage is a subrequirement of the containing requirement definition or usage. Subrequirements are considered to automatically be required constraints of the containing requirement definition or usage. This is useful for modeling groups of requirements that are intended to be satisfied together on the same subject. To simplify doing this, if a subject parameter is not explicitly declared for a subrequirement, it is assumed to have the same subject as its containing requirement definition or usage, with its subject bound to that of the container. requirement def VehicleRequirementsGroup { subject vehicle : Vehicle; // The subject of the following subrequirements // are implicitly bound to the subject "vehicle" // of the containing requirement definition. requirement driving : DrivingRequirement; requirement braking : BrakingRequirement; // The subject of the following subrequirement // is declared explicitly. requirement engineRqts : EngineRequirementsGroup { subject engine = vehicle.engine; } } The base requirement definition and usage are RequirementCheck and requirementChecks from the Requirements model library (see 9.2.14 ). 7.21.3 Concern Definitions and Usages A concern definition or usage is declared as a requirement definition or usage (see 7.21.2 ) using the kind keyword concern instead of requirement . Otherwise, a concern definition or usage is specified exactly like a regular requirement definition or usage. The intent, however, is that the concerns of one or more stakeholders can be modeled as the required constraints of a concern definition or usage with appropriate stakeholder parameters. concern def BrakingConcern { subject vehicle : Vehicle; stakeholder driver : Person; attribute maxBrakingDistance : DistanceValue; assume constraint { doc /* The driver is an occupant of the vehicle. */ } require constraint { doc /* The vehicle shall brake from its initial speed to zero * speed in a distance less than the maxBrakingDistance. */ } } One or more concerns can then be framed in other requirement definitions and usages. A framed concern usage is a subrequirement usage (see 7.21.2 ) indicated by prefixing a concern usage declaration with the keyword frame . As for an assumed or required constraint, the keyword frame can be used rather than frame concern to declare a framed concern using reference subsetting. In any case, since the framed concern usage itself is a subrequirement, it will automatically be considered a required constraint of its containing requirement definition or usage. requirement def BrakingRequirement { subject vehicle : Vehicle; Systems Modeling Language v2.0, Part 1 135 -actor environment : 'Driving Environment'; attribute speedLimit : SpeedValue; attribute maxBrakingDistance : DistanceValue; assume constraint { doc /* The environment conditions are poor. */ } frame concern brakingConcern : BrakingConcern { // Subject is automatically bound to "vehicle". :>> maxBrakingDistance = BrakingRequirement::maxBrakingDistance; } } The base concern definition and usage are ConcernCheck and concernChecks from the Requirements model library (see 9.2.14 ). 7.21.4 Satisfy Requirement Usages A satisfy requirement usage is declared as a requirement usage (see 7.21.2 ), using the kind keyword satisfy requirement . However, a satisfy requirement usage differs from a regular requirement usage in two ways: 1. The subject parameter of a satisfy requirement usage must be bound to a satisfying feature. 2. A satisfy requirement usage is a kind of assert constraint usage (see 7.20.3 ). Together, these mean that a satisfy requirement usage asserts that it is satisfied as a requirement (that is, it always evaluates to true) when the role of its subject is bound to the satisfying feature. The satisfying feature for a satisfy requirement usage can be specified in its declaration, immediately before its body, after keyword by . part vehicle1 : Vehicle; satisfy requirement braking : BrakingRequirement by vehicle1 { :>> speedLimit = 100[km/h]; :>> maxBrakingDistance = 10[m]; } A satisfy requirement usage may also be declared using just the keyword satisfy instead of satisfy requirement . In this case, the declaration does not include either a name or short name for the satisfy requirement usage. Instead, the requirement to be satisfied is identified by giving a qualified name or feature chain immediately after the satisfy keyword, and it is then related to the satisfy requirement usage by a reference subsetting relationship (see also 8.4.5.3 ). satisfy vehicleMaximumMass by vehicle1; A satisfy requirement usage can be negated by placing the keyword not before satisfy . A negated satisfy requirement usage asserts that the modeled requirement is not satisfied by the value of the given satisfying feature. part vehicle2 : ExperimentalVehicle; not satisfy vehicleMaximumMass by vehicle2; A satisfy requirement usage can be declared without an explicit satisfying feature if it is nested in definition or usage. In this case, the satisfying feature is considered to be given by the containing definition or usage (in the case of a definition this is essentially the self feature of the definition; see [KerML, 9.2.2]). part vehicle3 : Vehicle { part engine : Engine; // ... // "vehicle3" is implicitly the satisfying feature. 136 Systems Modeling Language v2.0, Part 1 -satisfy rqts : VehicleRequirementsGroup; } 7.22 Cases 7.22.1 Cases Overview Metamodel references: • Textual notation, 8.2.2.22 • Graphical notation, 8.2.3.22 • Abstract syntax, 8.3.22 • Semantics, 8.4.18 A case definition is a kind of calculation definition (see 7.19 ) that produces a result intended to achieve a specific objective regarding a given subject. A case usage is a kind of calculation usage that is a usage of a case definition. A case is a general concept that may be used in its own right, but also provides the basis for more specific kinds of cases, including analysis cases (see 7.23 ), verification cases (see 7.24 ), and use cases (see 7.25 ). The subject of a case is modeled as a distinguished parameter, similarly to the subject of a requirement (see 7.21 ). The objective of a case is modeled as a requirement usage to be satisfied by the performance of the case. Depending on the kind of case, the subject of the objective may be the same as the subject of the case (such as for a verification case or a use case) or it may be the result of the case (such as for an analysis case). A case definition or usage may also have one or more actor parameters that represent roles played by an entity external to the subject of the case but necessary to the specification of the case. An actor parameter is a part usage representing an entity that plays a designated actor role for the case. A case may have multiple actors representing the same kind of entity playing different roles relative to the case. Note. Actor parameters may also be specified for any kind of case, but they are used, in particular, in the specification of use cases (see 7.25 ). Requirements may also have actor parameters (see 7.21 ). The body of a case can be specified using subactions and subcalculations needed to achieve the case objective. This generally includes some combination of collecting information about the subject, evaluating it, and then producing a result. 7.22.2 Case Definitions and Usages A case definition or usage is declared as a kind of calculation definition or usage (see 7.19.2 ), using the kind keyword case . A case usage must be defined by a single case definition. The subject of a case definition or usage is modeled as its first parameter. Following the general rule for parameters (see 7.17.2 ), the subject parameter of a case definition or usage will redefine the subject parameter of any case definitions or usages that it specializes. The base case definition in the Cases library model specifies the most general possible subject, with the default name subj and the most general type Anything , and this can then be further specialized in specific case definitions and usages. A subject parameter is always an in parameter, so it is not necessary to declare it with an explicit direction. Instead, the keyword subject is used to identify the declaration of a subject parameter, which must come before the declaration of any other parameters in a case definition or usage. A case definition or usage may also have one or more actor parameters. Similarly to the declaration of a subject parameter, these distinguished parameters are declared using the keyword actor rather than explicitly declaring their direction. Actor parameters are part usages, so they must be (explicitly or implicitly) defined by part definitions (see 7.11.2 ). Systems Modeling Language v2.0, Part 1 137 -The objective of a case definition or usage is declared as a requirement usage (see 7.21.2 ), but using the keyword objective instead of requirement . The subject of an objective requirement is bound by default to the result of the case definition or usage, meaning that the objective of the case concerns its result. However, this can be overridden in specific case definitions or usages (but see 7.23.2 and 7.24.2 on the required bindings for analysis cases and verification cases). case def FaultRecovery { subject system : AutomationSystem; actor engineer : Person; objective { doc /* The engineer determines the cause of the system * fault and resolves it returning the system to * nominal operation. */ } } The base case definition and usage for are Case and cases from the Cases model library (see 9.2.15 ). 7.23 Analysis Cases 7.23.1 Analysis Cases Overview Metamodel references: • Textual notation, 8.2.2.23 • Graphical notation, 8.2.3.23 • Abstract syntax, 8.3.23 • Semantics, 8.4.19 An analysis case definition is a kind of case definition (see 7.22 ) whose objective is to carry out an analysis on the subject of the case. An analysis case usage is a kind of case usage that is a usage of an analysis case definition. The subject of an analysis case identifies what is being analyzed. The subject can often be kept quite general in an analysis case definition and then made more specific in usages of that definition. Performing an analysis case returns a result about the subject. For example, a fuel economy analysis of a vehicle subject returns the estimated fuel economy of the vehicle, given a set of analysis inputs and assumed conditions. The analysis result can be evaluated to determine whether it satisfies the analysis objective. The performance of an analysis case can be specified in a number of different ways. • The analysis case can include a set of analysis actions, each of which can specify calculations that return results. For example, the fuel economy analysis referred to above may require both a dynamics analysis and a fuel consumption analysis. The dynamics analysis determines the vehicle trajectory and the required engine power versus time. The fuel consumption analysis determines the fuel consumed to achieve the required engine power. Both the dynamics analysis and the fuel consumption analysis may require multiple calculations. • An analysis can be specified in SysML and solved by external solvers. In this case, the analysis case specifies the analysis to be performed, but does not define how the analysis is actually executed. For example, the analysis case could specify that the analysis result is obtained by integrating a differential equation, without detailing what integration algorithm is to be used to do this. • An analysis case can also specify a set of simultaneous equations to be solved. This can be done defining one or more constraint usages (see 7.20 ) that logically and each of the equations, and asserting that the constraint must be true. A solver would be expected to solve the equations such that it returns values that satisfy each equation. 138 Systems Modeling Language v2.0, Part 1 -Table 21. Analysis Cases – Representative Notation Element Graphical Notation Textual Notation «analysis def» analysis def AnalysisDef1 AnalysisDef1 { subject s1 : subject Subject1; s1 : Subject objective { doc /* '...' */; objective assume Analysis Case assumption1; doc '•••' Definition } assume assumption1 } «analysis def» analysis def AnalysisDef1 { AnalysisDef1 /* members */ compartment stack } ••• «analysis» analysis analysis1 : analysis1 : AnalysisDef1 AnalysisDef1 { subject redefines s1 subject = mySubject; redefines s1 = mySubject objective { doc /* '...' */ objective assume assumption1; Analysis Case doc '•••' } assume assumption1 } «analysis» analysis analysis1 : AnalysisDef1 { analysis1 : AnalysisDef1 /* members */ compartment stack } ••• «analysis» analysis1 : AnalysisDef1 subject analysis analysis1 : redefines s1 = mySubject AnalysisDef1 { ... objective Analyses analysis analysis4 : Compartment doc '•••' AnalysisDef4; assume assumption1 } analyses ^analysis3 : AnalysisDef3 analysis4 : AnalysisDef4 Systems Modeling Language v2.0, Part 1 139 -7.23.2 Analysis Case Definitions and Usages An analysis case definition or usage is declared as a case definition or usage (see 7.22.2 ), using the kind keyword analysis . An analysis case usage must be defined by a single analysis case definition. For an analysis case, the subject of the objective is always bound to the result of the analysis case definition or usage. That is, the objective is always about the result that is produced by the analysis. analysis def FuelEconomyAnalysis { subject vehicle : Vehicle; return fuelEconomyResult : DistancePerVolumeValue; objective fuelEconomyAnalysisObjective { doc /* * The objective of this analysis is to determine whether the * subject vehicle can satisfy the fuel economy requirement. */ requirement : FuelEconomyRequirement; } // ... } The base analysis case definition and usage are AnalysisCase and analysisCases in the AnalsysisCases model library (see 9.2.16 ). 7.23.3 Trade-Off Analyses A trade-off analysis is a special kind of analysis used to evaluate and compare alternatives. Such an analysis can be modeled by a usage of the TradeStudy analysis case definition from the TradeStudies library model found in the Analysis Domain Library (see 9.4.5 ). The subject of a TradeStudy analysis case is the collection of alternatives to be analyzed. An evaluation function is then provided that is used to evaluate each alternative, in order to find the alternative that meets the objective of the analysis case. Common TradeStudy objectives are to maximize or minimize the value of the objective function. An example of a trade-off analysis is an analysis that evaluates and compares alternatives for a vehicle engine in terms of various criteria, such as power, mass, efficiency and cost. The evaluation function establishes a relative weighting of each criterion based on its importance to the stakeholder. The evaluation result is computed for each alternative based on a weighted sum of the normalized value for each of the criteria. The evaluation results for each alternative are then compared with each other, based on the TradeStudy objective, to determine a preferred solution. analysis engineTradeStudy : TradeStudy { // The subject is bound to the two alternatives to be studied. subject : Engine = (engine4cyl, engine6cyl); // The objective is to find the alternative that has the // maximum value for the evaluationFunction. objective : MaximizeObjective; // For each one of the alternatives, the evaluationFunction // produces a numerical evaluation result. calc :>> evaluationFunction { in part anEngine : Engine :>> alternative; calc powerRollup: PowerRollup { in engine = anEngine; 140 Systems Modeling Language v2.0, Part 1 -return power; } calc massRollup: MassRollup { in engine = anEngine; return mass; } calc efficiencyRollup: EfficiencyRollup { in engine = anEngine; return efficiency; } calc costRollup: CostRollup { in engine = anEngine; return cost; } return :>> result : Real = EngineEvaluation( power = powerRollup.power, mass = massRollup.mass, efficiency = efficiencyRollup.efficiency, cost = costRollup.cost ); } // The selected alternative will be the one that has the // maximum value for the evaluationFunction. return part :>> selectedAlternative : Engine; } 7.24 Verification Cases 7.24.1 Verification Cases Overview Metamodel references: • Textual notation, 8.2.2.24 • Graphical notation, 8.2.3.24 • Abstract syntax, 8.3.24 • Semantics, 8.3.24 A verification case definition is a kind of case definition (see 7.22 ) whose result is a verdict on whether the subject of the case satisfies certain requirements. A verification case usage is a case usage that is a usage of a verification case definition. The subject of a verification case is an input parameter that identifies the system or other entity that is being evaluated as to whether it satisfies certain requirements (often referred to as the "unit under test" or "unit under verification"). The subject may be kept general in a verification case definition and then made more specific in usages of that definition. The objective of a verification case is to verify that the verification subject satisfies one or more specific requirements, which are specified as a special kind of required constraint in the objective. The result of the validation case is a verdict, which is one of the following: • Pass indicates that the subject has been determined to satisfy the requirements to be verified. • Fail indicates that the subject has been determined not to satisfy the requirements to be verified. • Inconclusive indicates that a determination could not be made as to whether the subject satisfies the requirements to be verified. • Error indicates that an error occurred during the performance of the verification. A typical verification case includes a set of verification actions that perform the following steps. Systems Modeling Language v2.0, Part 1 141 -1. Collect data about the subject as needed to support the verification objective, which is typically done using verification methods such as analysis, inspection, demonstration, and test. 2. Analyze collected data. For example, the data may include multiple measurements that span a range of conditions for a particular individual, or measurements of different individuals. This analysis step may need to determine the probability distribution, mean, and standard deviation associated with the measurements. 3. Evaluate the results of the analysis based on the objective to produce a verdict. Each of the verification actions in the verification case requires a set of resources to perform the actions. This may include verification personnel, equipment, facilities, and other resources. These resources may be represented in the model as parts that perform actions, or more specifically, using actor parameters on the verification case. Table 22. Verification Cases – Representative Notations Element Graphical Notation Textual Notation «verification def» VerificationDef1 verification def VerificationDef1 { subject subject s1 : s1 : Subject1 Subject1; objective { objective doc /* '...' */ verify doc objective statement Verification Case requirement1; verify requirement1 Definition } ••• } verification def «verification def» VerificationDef1 { /* members */ VerificationDef1 } compartment stack ••• «verification» verification verification1 : VerificationDef1 verification1 : VerificationDef1 { subject subject redefines s1 redefines s1 = mySubject = mySubject; objective { objective doc /* '...' */ verify doc objective statement requirement1; Verification Case verify requirement2 } ••• } verification «verification» verification1 : VerificationDef1 { verification1 : VerificationDef1 /* members */ compartment stack } ••• 142 Systems Modeling Language v2.0, Part 1 -Element Graphical Notation Textual Notation Verified Requirements Compartment { verifications verification ^verification2 : VerificationDef2 (in : ParamDef1, out : verification1 : ParamDef2) VerificationDef1 verification1 : VerificationDef1 [1..*] ordered nonunique [1..*] verifcation3R : VerficationDef3R redefines verification3 ordered nonunique; verification4R : VerificationDef4R :>> verification4 /* ... */ :>> verification5 perform verification Verifications verification6S : VerificationDef6S [m] subsets verification6 verification10; Compartment verification7S : VerificationDef7S [m] :> verification7 verification verification8R = verification8 verification11 { verification ref verification9 : VerificationDef9 'verification11.1'; perform verification10 verification verification11 'verification11.2'; ... } } metadata VerificationMethod { kind = ( verification methods inspect VerificationMethodKind::inspect, demo Verification Methods VerificationMethodKind::demo analyze Compartment test VerificationMethodKind::analyze, VerificationMethodKind::test); } verifies objective { requirement1 verify requirement1; Verifies requirement2 verify requirement2; Compartment ... } requirement requirement1: «verification» Requirement1; verificationCase1 : VerificationCase1 verification verificationCase1 : «verify» VerificationCase1 { Verify objective { verify «requirement» requirement1; requirement1 : Requirement1 } } Systems Modeling Language v2.0, Part 1 143 -7.24.2 Verification Case Definitions and Usages A verification case definition or usage is declared as a case definition or usage (see 7.22.2 ), using the kind keyword verification . A verification case usage must be defined by a single verification case definition. For a verification case, the subject of the objective is always bound to the subject of the verification case definition or usage. That is, the objective is always about the verification of requirements relative to the subject of the case. In addition to assumed and required constraint usages allowed in any requirement usage (see 7.21.2 ), the objective of a verification case may also have requirement verification usages, which indicate the requirements to be verified by the verification case. A requirement verification usage is a subrequirement of the objective that is indicated by prefixing a requirement usage declaration with the keyword verify . As for an assumed or required constraint, the keyword verify can be used rather than verify requirement to declare a verified requirement using reference subsetting. In any case, since the requirement verification usage itself is a subrequirement, it is automatically considered a required constraint of its containing objective. In addition, its subject is bound by default to the subject of the objective, which is itself bound to the subject of the verification case. The result of a verification case is a verdict that can have the values pass , fail , inconclusive , or error . In simple cases, the PassIf calculation definition from the VerificationCases library model (see 9.2.17 ) can be used to obtain a pass or fail verdict based on a Boolean value. In addition, the VerificationMethod metadata definition can be used to annotate a verification case with the method used to carry out the verification, one of inspect , analyze , demo , or test (see also 7.27 ). verification def VehicleMassTest { import VerificationCases::*; subject testVehicle : Vehicle; objective vehicleMassVerificationObjective { // The subject of the verify is automatically bound to "testVehicle". verify vehicleMassRequirement; } metadata VerificationMethod { kind = VerificationMthodKind::test; } action collectData { in part testVehicle : Vehicle = VehicleMassTest::testVehicle; out massMeasured :> ISQ::mass; } action processData { in massMeasured :> ISQ::mass = collectData.massMeasured; out massProcessed :> ISQ::mass; } action evaluateData { in massProcessed :> ISQ::mass = processData.massProcessed; out verdict : VerdictKind = // Check that "testVehicle" statisfies "vehicleMassRequirement" // if its mass equals 'massProcessed'. PassIf(vehicleMassRequirement( vehicle = testVehicle, massActual = massProcessed) ); } return verdict : VerdictKind = evaluateData.verdict; } 144 Systems Modeling Language v2.0, Part 1 -7.25 Use Cases 7.25.1 Use Cases Overview Metamodel references: • Textual notation, 8.2.2.25 • Graphical notation, 8.2.3.25 • Abstract syntax, 8.3.25 • Semantics, 8.4.21 A use case definition is a kind of case definition (see 7.22 ) that specifies the required behavior of its subject relative to one or more external actors. The objective of the use case is to provide an observable result of value to one or more of its actors. A use case usage is a case usage that is a usage of a use case. A use case is typically specified as a sequence of interactions between the subject and the various actors, which are all modeled as part usages. Each interaction can be modeled as a message (see 7.13 ) that delivers some payload or signal from an actor to the system or vice versa. The sources and target ends of these messages can either be modeled simply as abstract events within the lifetime of the subject and actor occurrences (see 7.9 ), or more concretely as actions performed to carry out the interaction (see 7.17 ). An include use case usage is a use case usage that is also a kind of perform action usage (see 7.17 ). A use case definition or usage may contain an include use case usage to specify that the behavior of the containing use case includes the behavior of the included use case. The subject of the included use case is the same as the subject of the containing use case, so the subject parameter of the included use case must have a definition that is compatible with the definition of the containing use case. Actor parameters of the included use case may be bound to corresponding actor parameters of the containing use case as necessary (see also 7.17 on parameter binding and 7.13 on binding in general). As a behavior, a use case can be performed with specific values for its subject and actor parameters. If a given subject also has a design model that decomposes its internal structure, then it should be possible to construct an interaction of the internal parts of the subject, consistent with the design model, that can be shown to be a specialization of the behavior specified by the performance of the use case for that subject. This is known as a realization of the use case relative to the design model. A system is properly designed to provide the behavior required by a set of use cases if there is a legal realization of each use case relative to the design of the system. Systems Modeling Language v2.0, Part 1 145 -Table 23. Use Cases – Representative Notation Element Graphical Notation Textual Notation «use case def» use case def UseCaseDef1 UseCaseDef1 { subject subject s1:Subject1; objective { s1 : Subject1 doc /* This is the objective description. objective */ doc This is the objective description. require Use Case Definition requirement1; require requirement1 } ••• } use case def UseCaseDef1 «use case def» { /* members */ UseCaseDef1 } compartment stack ••• «use case» useCase1 : UseCaseDef1 use case useCase1 : UseCaseDef1 { subject subject redefines s1 = redefines s1 = mySubject mySubject; objective { objective doc /* '...' */ require doc This is the objective description. requirement1; Use Case require requirement1 } ••• } use case useCase1 : «use case» UseCaseDef1 { /* members */ useCase1 : UseCaseDef1 } compartment stack ••• 146 Systems Modeling Language v2.0, Part 1 -Element Graphical Notation Textual Notation include use cases ^useCase2 : UseCaseDef2 (in : ParamDef1, out : ParamDef2) { useCase1 : UseCase1 [1..*] ordered nonunique include use case useCase3R : UseCaseDef3R redefines useCase3 useCase1 : useCase4R : UseCaseDef4R :>> useCase4 UseCase1 [1..*] Include Use Cases :>> useCase5 ordered nonunique; Compartment useCase6S : UseCaseDef6S [m] subsets useCase6 /* ... */ useCase7S : UseCaseDef7S [m] :> useCase7 } useCase8R = useCase8 useCase11 ... subject system=system1 use case useCase1 { subject system = system1; actor actor1 : Actor1; «use case» actor1 : Actor1 actor actor2 : Use Case with useCase1 Actor2; actor3 : Actor3 Include Use Cases actor actor3 : (shorthand notation) Actor3; actor2 : Actor2 include useCase2; include useCase3; «include» «include» } use case useCase2; use case useCase3; «use case» «use case» useCase2 useCase3 7.25.2 Use Case Definitions and Usages A use case definition or usage is declared as a case definition or usage (see 7.22.2 ), using the kind keyword use case . A use case usage must be defined by a single use case definition. A use case definition will typically have an explicit declaration of its subject and one or more external actors (see see 7.22.2 on the declaration of subject and actor parameters in case definitions). The objective of the use case is for the subject to provide some result of value to one or more of the actors. The subject and the actors interact in order to achieve this objective, and the use case definition may specify this interaction as, for example, messages passing between them (see 7.16.2 on message declarations). use case def 'Provide Transportation' { subject vehicle : Vehicle { event occurrence driverEnters [1]; then event occurrence passengerEnters [0..*]; then event occurrence startsDrive [1]; then event occurrence endsDrive [1]; then event occurrence passengerExits [0..*]; then event occurrence driverExits [1]; } actor driver : Person { Systems Modeling Language v2.0, Part 1 147 -event occurrence entersVehicle [1]; then event occurrence exitsVehicle [1]; } actor passengers : Person[0..4] { event occurrence entersVehicle [1]; then event occurrence exitsVehicle [1]; } actor environment : Environment { event occurrence vehicleDrives [1]; } objective { doc /* Transport driver and passengers from starting location * to ending location. */ } message of Enter from driver.entersVehicle to vehicle.driverEnters; then message of Enter from passengers.entersVehicle to vehicle.passengerEnters; then message of Drive from vehicle.drives to environment.vehicleDrives; then message of Exit from passengers.exitsVehicle to vehicle.passengerExits; then message of Exit from driver.exitsVehicle to vehicle.driverExits; } The base use case definition and usage are UseCase and useCases from the UseCases library model (see 9.2.18 ) 7.25.3 Include Use Case Usages An include use case usage is declared as a use case usage (see 7.25.2 ) using the kind keyword include use case instead of just use case . An include use case usage is a kind of perform action usage (see 7.17.6 ) for which the action usage is a use case usage, known as the included use case. As for a perform action usage, the included use case is related to the include use usage by a reference subsetting relationship, specified textually using the keyword references or the symbol ::> . Or, if the include use case usage has no such reference subsetting, then the included use case is the include use case usage itself. An include use case usage may also be declared using just the keyword include instead of include use case . In this case, the declaration does not include either a name or short name. Instead, the included use case of the include use case usage is identified by giving a qualified name or feature chain immediately after the include keyword. The subject of an included use case usage is bound by default to the subject of its containing use case definition or usage. However, the actor parameters of the included use case usages should be explicitly bound to appropriate actors of the containing use case, as necessary. use case 'provide transportation' : 'Provide Transportation' { first start; then include 'enter vehicle' { actor :>> driver = 'provide transportation'::driver; actor :>> passengers = 'provide transportation'::passengers; } then include 'drive vehicle' { actor :>> driver = 'provide transportation'::driver; actor :>> environment = 'provide transportation'::environment; } then include 'exit vehicle' { actor :>> driver = 'provide transportation'::driver; actor :>> passengers = 'provide transportation'::passengers; } 148 Systems Modeling Language v2.0, Part 1 -then done; } 7.26 Views and Viewpoints 7.26.1 Views and Viewpoints Overview Metamodel references: • Textual notation, 8.2.2.26 • Graphical notation, 8.2.3.26 • Abstract syntax, 8.3.26 • Semantics, 8.4.22 A viewpoint definition is a kind of requirement definition (see 7.21 ) that frames the concerns of one or more stakeholders regarding information about a modeled system or domain of interest. A viewpoint usage is a requirement usage that is a usage of a viewpoint definition. The subject of a viewpoint is a view that is required to address the stakeholder concerns. A view definition is a kind of part definition (see 7.11 ) that specifies how to create a view artifact to satisfy one or more viewpoints. A view artifact is a rendering of information that addresses some aspect of a system or domain of interest of concern to one or more stakeholders. A view definition can include view conditions to extract the relevant model content, and a rendering that specifies how the model content should be rendered in a view artifact. A view condition is specified using metadata, in the same way as for a filter condition on a package (see 7.5 ). A view definition and its rendering can preserve a correspondence between elements of the model and of the graphical and/or textual elements of the view artifact. The implementation of a rendering can follow this correspondence to propagate changes to a view artifact back to the model from which the view artifact was extracted and rendered. A view usage is a kind of part usage (see 7.11 ) that is a usage of a view definition. A view usage exposes a portion of a model, which is a kind of import (see 7.5 ) without regard to visibility that provides the scope of application of the view conditions. The view rendering can then be applied to those exposed elements that meet all the view conditions to produce the view artifact. A view usage can add further view conditions to those inherited from its view definition, and it can specify a view rendering if one is not provided by its definition. View usages can be nested and ordered within a composite view to generate composite view artifacts. The view usage also can contain further rendering specifications on the symbolic representation, style, and layout for a particular view. For example, a complex view definition with deeply nested structures can be rendered as a document, where each nested view usage corresponds to a section of a document, and the ordering represents the order of the sections within the document. Within each section of the document, the nested view usages can then specify the information that is rendered as a combination of text, graphical, and tabular information. A rendering definition is a kind of part definition (see 7.11 ) that specifies how a view artifact is to be rendered. A rendering usage is a kind of part usage that is a usage of a rendering definition. A rendering usage is used in a view definition or usage to specify the view rendering. Systems Modeling Language v2.0, Part 1 149 -Table 24. Views and Viewpoints – Representative Notation Element Graphical Notation Textual Notation «view def» ViewDef1 viewpoints view def ViewDef1 { satisfy viewpoint1; ••• /* ... */ filter filters filterExpression1; ••• /* ... */ View Definition render rendering1; rendering } rendering1 view def ViewDef1 { /* members */ «view def» } ViewDef1 compartment stack ••• «view» view1 : ViewDef1 viewpoints ••• exposes view view1 : ViewDef1 { part1::** satisfy viewpoint1; ••• expose part1::**; filter @PartUsage; filters render asTable; View @PartUsage } ••• view view1 : ViewDef1 { rendering /* members */ } asTable «view» view1 : ViewDef1 compartment stack ••• 150 Systems Modeling Language v2.0, Part 1 -Element Graphical Notation Textual Notation «viewpoint def» viewpoint def ViewpointDef1 ViewPointDef1; «viewpoint def» viewpoint def Viewpoint Definition ViewPointDef1 { ViewpointDef1 /* members */ compartment stack } ••• «viewpoint» viewpoint viewpoint1 : viewpoint1 : ViewpointDef1 ViewPointDef1; «viewpoint» viewpoint viewpoint1 : Viewpoint ViewPointDef1 { viewpoint1 : ViewpointDef1 /* members */ compartment stack } ••• «view» view1 : View1 part part1 : Part1; view view1 : View1 { «expose» expose part1; Expose } «part» part1 : Part1 «viewpoint» concern concern1 : viewpoint1 : Viewpoint1 Concern1; viewpoint viewpoint1 : «frame» Viewpoint1 { Frame frame concern1; } «concern» concern1 : Concern1 { frame concern frame concerns concern1 : Concern1 concern1 : Concern1 [1..*] ordered nonunique [1..*] Frames ordered nonunique; ... Compartment /* ... */ } Systems Modeling Language v2.0, Part 1 151 -7.26.2 View Definitions and Usages A view definition or usage is declared as a kind of part definition or usage (see 7.11.2 ), using the kind keyword view . A view usage must be defined by a single view definition. A view definition includes filter conditions on what kinds of elements can be included in a view and identifies a view rendering that determines how the included elements are to be rendered. The filter conditions are specified in the same way as for packages (see 7.5.4 ), by using the keyword filter followed by a Boolean-valued, model-level evaluable expression (see [KerML. 7.4.9]). The view rendering is specified using the keyword render followed by a composite rendering usage declaration (see 7.26.4 ). Alternatively, the keyword render may be followed by just a qualified name or feature chain identifying a rendering usage, which establishes a reference subsetting relationship between the view rendering usage and the identified rendering usage. The Views model in the Systems Model Library provides a limited number of basic standard renderings (see 9.2.19 ). view def 'Part Structure View' { import Views::*; filter @SysML::PartUsage; render asTreeDiagram; } A view usage inherits any filter conditions from its view definition and can declare addition conditions of its own. If a view usage does not declare a view rendering, then this will be inherited from the view definition, if it has one. If a view usage does declare a view rendering, then this will redefine the view rendering from its view definition (if any). Note that this means that the view rendering for a view usage must be consistent with the rendering specified in the view definition, though it can be more specialized. In addition, a view usage can specify which elements are actually to be exposed by the view. This is done using expose relationships, which are a special kind of import relationships. Expose relationships are declared like import relationships (see 7.5.3 ), but using the keyword expose instead of import and with no specification of visibility. A view artifact is generated from a view usage by first importing the exposed elements based on the expose relationships of the view usage, filtering those based on the filter conditions that are owned and inherited by the view usage, and then generating a rendered view artifact using the view rendering specified for the view usage. An expose relationship always has protected visibility, which means that the elements exposed by a view usage are not publicly visible outside the view usage, but they are visible within specializations of the view usage. view 'vehicle parts view' : 'Part Structure View' { // Recursive import is useful for exposing elements // from hierarchical models. expose VehicleDesignModel::**; // This is an additional filter condition. filter not @SysML::ConnectionUsage; // This implicitly redefines the view rendering from // the view definition. render asMyTreeDiagram; } Since an expose relationship is a kind of import relationship, the filtered import notation can also be used with it (see 7.5.4 ). This provides an alternate way to filter the elements exposed by a view usage. view 'vehicle parts view' : 'Part Structure View' { // This applies the filter directly on the imported // elements from the expose relationships. (The filter // conditions from the view definition also still apply.) 152 Systems Modeling Language v2.0, Part 1 -expose VehicleDesignModel::**[not @SysML::ConnectionUsage]; render asMyTreeDiagram; } The base view definition and usage are View and views from the Views model library (see 9.2.19 ). 7.26.3 Viewpoint Definitions and Usages A viewpoint definition or usage is declared as a kind of requirement definition or usage (see 7.21.2 ). A viewpoint usage must be defined by a single viewpoint definition. The subject of a viewpoint definition or usage must be a view. Otherwise, a viewpoint is specified with assumed and required constraints, just like any requirement definition or usage. However, it is typical for a viewpoint definition to be structured as framing a set of stakeholder concerns (see 7.21.3 ) regarding information about a modeled system or domain of interest. The viewpoint then models the requirement for view needed in order to address the framed concerns. concern 'system breakdown' { stakeholder se : 'Systems Engineer'; stakeholder ivv : 'IV&V'; } concern 'modularity' { stakeholder se : 'Systems Engineer'; } viewpoint def 'System Structure Perspective' { frame 'system breakdown'; frame 'modularity'; require constraint { doc /* A system structure view shall show the hierarchical * part decomposition of a system, starting with a * specified root part. */ } } Since a viewpoint usage is a kind of requirement usage, a view usage can be declared to satisfy a viewpoint usage using a satisfy requirement usage (see 7.21.4 ). However, as a short cut, any composite viewpoint usage nested in a view definition or usage is asserted to be satisfied by that view. view def 'Part Structure View' { // This viewpoint is asserted to be satisfied by any // instance of the view definition. viewpoint vp : 'System Structure Perspective'; //... } Alternatively, a satisfy requirement usage can be used explicitly between a viewpoint and a view. In particular, a satisfy requirement usage for a viewpoint that is nested in a view definition or usage will, by default, have the containing view as its satisfying feature (as described in general for nested satisfy requirement usages in 7.21.4 ). viewpoint 'vehicle structure perspective' : 'System Structure Perspective' { subject : Vehicle; } view 'vehicle parts view' : 'Part Structure View' { Systems Modeling Language v2.0, Part 1 153 -// This asserts that the give viewpoint is satisfied by the // 'vehicle parts view'. satisfy 'vehicle structure perspective'; // ... } The base viewpoint definition and usage are Viewpoint and viewpoints from the Views library model (see 9.2.19 ). 7.26.4 Rendering Definitions and Usages A rendering definition or usage is declared as a kind of part definition or usage (see 7.11.2 ), using the kind keyword rendering . A rendering usage must be defined by a single rendering definition. While a rendering is intended to specify how a view is rendered as a view artifact, there are no specific constructs provided in SysML for specifying that. A rendering definition or usage can be defined similarly to any other part definition or usage, perhaps with nested subrenderings and references to related view usages. Nevetheless, conforming tools can provide libraries of rendering usages that reflect the capabilities they provide for rendering various kinds of views, which can then be identified in user models specifying those kinds of views. A small number of basic standard rendering usages are provided in the Views library model (see 9.2.19 ). The base rendering definition and usage are Rendering and renderings from the Views library model (see 9.2.19 ). 7.26.5 Compartments and Diagrams as View Usages A compartment is a view usage (see 7.26.2 ). For example, a part definition or part usage may contain an attributes compartment that lists its attributes (see, for example, Table 9 in 7.11.2 ). The compartment label is the view name. This view implicitly exposes the owning part and applies a filter expression to select the attributes of the part. The filtered contents are then rendered as a list of attributes in accordance with the textual rendering specified in the graphical notation (see 7.7.1 and 8.2.3.7 ). A graphical node symbol, such as for a part definition or usage, can have any number of compartments. Each compartment can be rendered using graphical notation in a graphical compartment or using textual notation in a textual compartment. For example, an interconnection view of a part can be rendered in a graphical compartment of the part symbol showing nested parts as nodes and connections as edges. The parts can also be rendered in a textual compartment labeled as parts and rendered as a list of parts. A diagram is also a view usage. The diagram header is the name compartment of the view usage. As with any other view usage, the filtered contents of a diagram are rendered in a compartment. These contents are typically rendered as a graphical compartment that contains nodes and edges, but it may be a textual compartment as well. A graphical node within the graphical compartment of a diagram can also have compartments that are view usages as described above. This provides a mechanism to nest views within other views. Definition and usage nodes can include symbols on the boundary of the node to represent ports and parameters. An edge in a graphical view can be attached via a dashed line to a node that elaborates the features of the edge. The attached node can also have graphical or textual compartments to show the internal structure of a connection, such as its decomposition into nested connections. A view usage may contain other view usages that each contain a name compartment and rendered contents in their respective compartment. This enables nesting of diagrams within other diagrams. The StandardViewDefinitions package in the Systems Model Library (see 9.2.20 ) provides a set of standard view definitions for typical kinds of diagrams, including the valid contents for the view. The standard views are then rendered as specified for the graphical notation, such as the General View in 8.2.3.5 , the Interconnection View in 154 Systems Modeling Language v2.0, Part 1 -8.2.3.11 , etc. (see Table 34 in 9.2.20 for the complete list). However, visualization of SysML models is not limited to these standard views. User-defined view definitions and usages can be used to provide a wide range of views beyond the standard set. Table 25. Diagrams – Representative Examples Standard View Diagram General View Tree View Systems Modeling Language v2.0, Part 1 155 -Standard View Diagram Nested View Note. The info compartment at the bottom-right corner is an example of rendering data structured by a metadata definition similar to: metadata def ProjectInfo { attribute projectName : String; attribute modifiedAt : Time::Iso8601DateTime; attribute author : String; attribute status : StatusKind; } Table View Matrix View Matrix View 156 Systems Modeling Language v2.0, Part 1 -7.27 Metadata 7.27.1 Metadata Overview Metamodel references: • Textual notation, 8.2.2.27 • Graphical notation, 8.2.3.27 • Abstract syntax, 8.3.27 • Semantics, 8.4.23 A metadata usage is a kind of annotating element (see 7.4 ) that allows for the definition of structured metadata with modeler-specified attributes. This may be used, for example, to add tool-specific information to a model that can be relevant to the function of various kinds of tooling that may use or process a model, or domain-specific information relevant to a certain project or organization. A metadata usage is defined by a single metadata definition. If the definition has no nested features itself, then the metadata usage simply acts as a user-defined syntactic tag on the annotated element. If the definition does have features, then the metadata usage must provide value bindings for all of them, specifying metadata for the annotated element. Table 26. Metadata – Representative Notation Element Graphical Notation Textual Notation metadata MetadataDef1 { attribute1=value1; attribute2="value2"; attribute3="http://...." «metadata» } MetadataDef1 attribute1=value1 Metadata or attribute2="value2" attribute3="http : //....." @MetadataDef1 { attribute1=value1; attribute2="value2"; attribute3="http://...." } Systems Modeling Language v2.0, Part 1 157 -Element Graphical Notation Textual Notation analysis vehicleAnalysis : VehicleAnalysis; metadata ToolMetadata about vehicleAnalysis { toolName="ToolX"; toolURL="http://....."; behaviorName= "ComputeVehicleState"; «metadata» } «analysis» ToolMetadata toolName="ToolX" vehicleAnalysis : Annotation-Metadata or toolURL="http : //....." VehicleAnalysis behaviorName="ComputeVehicleState" analysis vehicleAnalysis : VehicleAnalysis { metadata ToolMetadata { toolName="ToolX"; toolURL="http://....."; behaviorName= "ComputeVehicleState"; } } metadata metadata MetadataDef1 { MetadataDef1 attribute1=value1; attribute1=value1 attribute2="value2"; Metadata attribute2="value2" attribute3= Compartment attribute3="http : //....." "http://....."; } ... metadata def «metadata def» ToolMetadata { ToolMetadata attribute toolName : String; Metadata Definition attributes attribute uri : toolName : String String; } uri : String 158 Systems Modeling Language v2.0, Part 1 -Element Graphical Notation Textual Notation state 'failure modes' «state» [*]; 'failure modes' [*] metadata def 'failure mode' :> SemanticMetadata { «metadata def» :>> baseType = SemanticMetadata 'failure mode' :> SemanticMetadata 'failure modes' meta Definition features SysML::StateUsage; :> annotatedElement : :>> baseType = 'failure modes' meta SysML::StateUsage SysML::StateDefinition; :> annotatedElement : SysML::StateDefinition :> annotatedElement : SysML::StateUsage; :> annotatedElement : SysML::StateUsage } 7.27.2 Metadata Definitions and Usages A metadata definition is declared like an item definition (see 7.10 ), but using the keyword metadata def . metadata def SecurityRelated; metadata def ApprovalAnnotation { attribute approved : Boolean; attribute approver : String; } A metadata usage is declared like an item usage (see 7.10 ) using the keyword metadata (or the symbol @ ) followed by the keyword defined by (or the symbol : ) and the qualified name of exactly one metadata definition or KerML Metaclass (see [KerML], 7.4.13). If there is no declared name or short name, then the keyword defined by (or the symbol : ) may also be omitted. In addition, one or more annotated elements can be identified for the metadata usage after the keyword about , indicating that the metadata usage has annotation relationships to each of the identified elements (see also 7.4 on annotation relationships). metadata securityDesignAnnotation : SecurityRelated about SecurityRequirements, SecurityDesign; If the specified metadata definition (or KerML metaclass) has features, then a body must be given for the metadata usage that declares reference usages (see 7.6 ) that redefine each of the features of the definition and binds them to the result of model-level evaluable expressions (see [KerML, 7.4.9]). These nested reference usages of a metadata usage must always have the same names as the names of the features of its metadata definition, so the shorthand prefix redefines notation (see 7.6 ) is always used metadata ApprovalAnnotation about Design { ref :>> approved = true; ref :>> approver = "John Smith"; } The keyword ref and/or redefines (or the equivalent symbol :>> ) may be omitted in the declaration of a feature of a metadata usage. metadata ApprovalAnnotation about Design { approved = true; approver = "John Smith"; } Systems Modeling Language v2.0, Part 1 159 -If the metadata usage is an owned member of a namespace (see 7.5 ), then the explicit identification of annotated elements can be omitted, in which case the annotated element shall be implicitly the containing namespace. part def Design { // This metadata usage is implicitly about the part def Design. @ApprovalAnnotation { approved = true; approver = "John Smith"; } } The base metadata definition and usage are MetadataItem and metadataItems from the Metadata library (see 9.2.21 ). The base metadata definition MetadataItem specializes the KerML metaclass Metaobject , and it inherits the feature annotatedElement from Metaobject , which is typed by the reflected KerML metaclass KerML::Element (see [KerML, 9.2.17]). When a metadata usage is declared, its inherited annotatedElement feature is implicitly bound to reflective instances representing its annotated elements. metadata securityDesignAnnotation : SecurityRelated about SecurityRequirements, SecurityDesign { // The feature "annotatedElement" is implicitly bound to the list // of SecurityRequirements meta KerML::Element and // SecurityDesign meta KerML::Element. } A metadata definition can restrict the kind of elements that it can be applied to by subsetting Metaobject::annotatedElement and restricting its type. If a metadata usage then inherits one or more concrete features that directly or indirectly subset annotatedElement , any annotated element of the metadata usage must conform to the type of at least one of these features. The restricted type should be one of the reflective metaclasses from the KerML (see [KerML, 9.2.17]) or SysML (see 9.2.22 ) abstract syntax models. metadata def CommandMetadata { // A metadata usage of this definition may annotate // an ActionDefinition or an ActionUsage. :> annotatedElement : SysML::ActionDefinition; :> annotatedElement : SysML::ActionUsage; } action def Save specializes UserAction { @CommandMetadata; // This is valid. redefine action doAction { @CommandMetadata; // This is valid. } } item def Options { @CommandMetadata; // This is INVALID. } 7.27.3 Semantic Metadata If the metadata definition of a metadata usage is a direct or indirect specialization of KerML metaclass SemanticMetadata from the Metaobjects model in the Kernel Semantic Library (see [KerML, 9.2.16]), then the annotated elements of the metadata usage must all be types (e.g., definitions or usages), and the inherited feature SemanticMetadata::baseType must be bound to a value of type KerML::Type (which is a generalization of SysML::Definition and SysML::Usage ). Each annotated element is then considered to implicitly specialize a definition or usage determined from the baseType value as follows: • If the annotated type is a definition and the baseType is a definition (or KerML classifier), then the annotated definition implicitly subclassifies the baseType . 160 Systems Modeling Language v2.0, Part 1 -• If the annotated type is a definition and the baseType is a usage (or KerML feature), then the annotated definition implicitly subclassifies each definition (or type ) of the baseType . • If the annotated type is a usage and the baseType is a usage (or KerML feature), then the annotated usage implicitly subsets the baseType . • Otherwise no implicit specialization is added. When evaluated in a model-level evaluable expression, the meta-cast operator meta (see [KerML, 7.4.9.2]) may be used to cast a type element referenced as its first operand to the actual reflective metadata definition (or KerML metaclass) value for the type, which may then be bound to the baseType feature of SemanticMetadata . action def UserAction; action userActions : UserAction[*] nonunique; metadata def CommandMetadata :> SemanticMetadata { // The meta-cast operation "userAction meta SysML::Usage" has // type Usage, which conforms to the type KermL::Type of baseType. // Since userActions is an ActionUsage, the expression evaluates // at model level to a value of type SysML::ActionUsage. :>> baseType = userActions meta SysML::Usage; } // Save implicitly subclassifies UserAction // (which is the definition of userActions). action def Save { @CommandMetadata; } // previousAction implicitly subsets userActions. action previousAction[1] { @CommandMetadata; } 7.27.4 User-Defined Keywords A user-defined keyword is the (possibly qualified) name (or short name) of a metadata definition (or KerML metaclass) preceded by the symbol # . Such a keyword can be used in package, dependency, definition and usage declarations. The user-defined keyword is placed immediately before the language-defined (reserved) keyword for the declaration and specifies a metadata annotation of the declared element. If the named metadata definition is a kind of SemanticMetadata , then the implicit specialization rules given in 7.27.3 for semantic metadata also apply. occurrence def Situation; occurrence situations : Situation[0..*] nonunique; // It is often convenient to use a lower-case initial name or // short name for semantic metadata intended to be used as a keyword. metadata def SituationMetadata :> SemanticMetadata { :>> baseType = situations meta SysML::Usage; } // Failure is an OccurrenceDefinition that implicitly subclassifies Situation. #situation occurrence def Failure; // batteryLow is an OccurrenceUsage that implicitly subsets situations. #situation occurrence batteryLow; In addition, a user-defined keyword for semantic metadata may also be used to declare a definition or usage without using any language-defined keyword. Systems Modeling Language v2.0, Part 1 161 -// Failure is a definition that implicitly subclassifies Situation. #situation def Failure; // batteryLow is a usage implicitly subsets situations. #situation batteryLow; It is also possible to include more than one user defined-keyword in a declaration. #SecurityRelated #situation def Vulnerability; 162 Systems Modeling Language v2.0, Part 1 -8Metamodel 8.1 Metamodel Overview The SysML metamodel extends the KerML metamodel as specified in the KerML specification [KerML]. • The SysML concrete syntax includes a textual notation (see 8.2.2 ), which is generally distinct from that of KerML, though consistent on common elements (such as packages and expressions), and a complete graphical notation (see 8.2.3 ). • The SysML abstract syntax (see 8.3 ) imports the KerML abstract syntax, reusing some KerML metaclasses directly, and further specializing most other KerML metaclasses. • The SysML semantics (see 8.4 ) are defined by relating the SysML abstract syntax to the semantic models in the Systems Model Library (see Clause 9 ), which is based on the Kernel Model Library from KerML, and providing syntactic transformations from SysML models to syntactically equivalent KerML models (including elements that are otherwise implicit in the SysML abstract syntax). Throughout this clause, the names of elements from the SysML (and KerML) abstract syntax models appear in a " code " font. Further: 1. Names of metaclasses appear exactly as in the abstract syntax, including capitalization, except possibly with added pluralization. When used as English common nouns, e.g., "a Usage ", "multiple Subsettings ", they refer to instances of the metaclass. E.g., " Usages can be nested in other Usages " refers to instances of the metaclass Usage that reside in models. This can be modified with the term "metaclass" as necessary to refer to the metaclass itself instead of its instances, e.g., "The Usage metaclass is contained in the DefinitionAndUsage package." 2. Names of properties of metaclasses, when used as English common nouns, e.g., “an ownedUsage ”, “multiple nestedActions ”, refer to values of the properties. This can be modified using the term "metaproperty" as necessary to refer to the metaproperty itself instead of its values, e.g., "The ownedUsage metaproperty is contained in the DefinitionAndUsage package." Similar stylistic conventions apply to text about SysML (and KerML) models, except that an " italic code " front is used. 1. Convention 1 above applies to SysML Definitions (e.g., Action ), using "definition" (or a more specialized term) instead of "metaclass" (e.g., "the action definition Action "). 2. Convention 2 above applies to SysML Usages (e.g, actions ), using "usage" (or a more specialized term) instead of "metaproperty" (e.g., "the action usage actions "). 8.2 Concrete Syntax 8.2.1 Concrete Syntax Overview Concrete syntax specifies the how the language appears to modelers. They construct and review models shown according to the concrete syntax. The SysML concrete syntax includes both a textual notation, described in 8.2.2 , and a graphical notation, described in 8.2.3 . Various views of a SysML model may be rendered entirely using the textual notation, entirely using the graphical notation, or using a combination of the two. 8.2.2 Textual Notation 8.2.2.1 Textual Notation Overview 8.2.2.1.1 EBNF Conventions The grammar definition for the SysML textual concrete syntax defines how lexical tokens for an input text are grouped in order to construct an abstract syntax representation of a model (see 8.3 ). The concrete syntax grammar Systems Modeling Language v2.0, Part 1 163 -definition uses an Extended Backus Naur Form (EBNF) notation (see Table 27 ) that includes further notations to describe how the concrete syntax maps to the abstract syntax (see Table 28 ). Productions in the grammar formally result in the synthesis of classes in the abstract syntax and the population of their properties (see Table 29 ). Productions may also be parameterized, with the parameters typed by abstract syntax classes. Information passed in parameters during parsing allows a production to update the properties of the provided abstract syntax elements as a side-effect of the parsing it specifies. Some productions only update the properties of parameters, without synthesizing any new abstract syntax element. Table 27. EBNF Notation Conventions LEXICAL Lexical element 'terminal' Terminal element NonterminalElement Non-terminal element Element1 Element2 Sequential elements Element1 | Element2 Alternative elements Element ? Optional elements (zero or one) Element * Repeated elements (zero or more) Element + Repeated elements (one or more) ( Elements ... ) Grouping Table 28. Abstract Syntax Synthesis Notation Assign the result of parsing the concrete syntax Element to abstract p = Element Property assignment syntax property p . Add the result of parsing the concrete syntax Element to the p += Element List property construction abstract syntax list property p . If the concrete syntax Element is p ?= Element Boolean property assignment parsed, then set the abstract Boolean property p to true. Assign (or add) the given value to the abstract syntax property p , without parsing any input. The { p = value } Non-parsing assignment value may be a literal or a reference { p += value } to another abstract syntax property. The symbol " this " refers to the element being synthesized. Parse a QualifiedName , then resolve that name to an Element [QualifiedName] Name resolution reference for use as a value in an assignment as above. 164 Systems Modeling Language v2.0, Part 1 -Table 29. Grammar Production Definitions Define a production for the NonterminalElement that synthesizes the AbstractSyntaxElement . If the NonterminalElement : NonterminalElement has the Production definition AbstractSyntaxElement = ... same name as the AbstractSyntaxElement , then " : AbstractSyntaxElement " may be omitted. Define a production for the NonterminalElement that NonterminalElement (p : synthesizes the Parameterized production Type) : AbstractSyntaxElement , with a definition AbstractSyntaxElement = ... parameter named p , whose type is an abstract syntax class. 8.2.2.1.2 Lexical Structure The lexical structure of the SysML textual notation is identical to that of the KerML textual notation [KerML], except for the following two points. 1. The reserved keywords of SysML are the following. about abstract accept action actor after alias all allocate allocation analysis and as assert assign assume at attribute bind binding by calc case comment concern connect connection constant constraint crosses decide def default defined dependency derived do doc else end entry enum event exhibit exit expose false filter first flow for fork frame from hastype if implies import in include individual inout interface istype item join language library locale loop merge message meta metadata nonunique not null objective occurrence of or ordered out package parallel part perform port private protected public redefines ref references render rendering rep require requirement return satisfy send snapshot specializes stakeholder standard state subject subsets succession terminate then timeslice to transition true until use variant variation verification verify via view viewpoint when while xor 2. The set of special lexical terminals matching either certain keywords or their symbolic equivalents are the following in SysML. DEFINED_BY = ':' | 'defined' 'by' SPECIALIZES = ':>' | 'specializes' SUBSETS = ':>' | 'subsets' REFERENCES = '::>' | 'references' CROSSES = '=>' | 'crosses' REDEFINES = ':>>' | 'redefines' Tooling for the SysML textual notation should generally highlight keywords relative to other text, for example by using boldface and/or distinctive coloring. However, while keywords are shown in boldface in this specification, the specification does not require any specific highlighting (or any highlighting at all). SysML textual notation documents are expected to be interchanged as plain text (see also [KerML, Clause 10] on Model Interchange). This recommendation also applies to snippets of textual notation used as part of the graphical notation, i.e., textual elements residing inside graphical elements. Systems Modeling Language v2.0, Part 1 165 -8.2.2.2 Elements and Relationships Textual Notation Identification : Element = ( '<' declaredShortName = NAME '>' )? ( declaredName = NAME )? RelationshipBody : Relationship = ';' | '{' ( ownedRelationship += OwnedAnnotation )* '}' 8.2.2.3 Dependencies Textual Notation Dependency = ( ownedRelationship += PrefixMetadataAnnotation )* 'dependency' DependencyDeclaration RelationshipBody DependencyDeclaration = ( Identification 'from' )? client += [QualifiedName] ( ',' client += [QualifiedName] )* 'to' supplier += [QualifiedName] ( ',' supplier += [QualifiedName] )* 8.2.2.4 Annotations Textual Notation 8.2.2.4.1 Annotations Annotation = annotatedElement = [QualifiedName] OwnedAnnotation : Annotation = ownedRelatedElement += AnnotatingElement AnnotatingMember : OwningMembership = ownedRelatedElement += AnnotatingElement AnnotatingElement = Comment | Documentation | TextualRepresentation | MetadataFeature 8.2.2.4.2 Comments and Documentation Comment = ( 'comment' Identification ( 'about' ownedRelationship += Annotation ( ',' ownedRelationship += Annotation )* )? )? ( 'locale' locale = STRING_VALUE )? body = REGULAR_COMMENT Documentation = 'doc' Identification ( 'locale' locale = STRING_VALUE )? body = REGULAR_COMMENT 8.2.2.4.3 Textual Representation TextualRepresentation = ( 'rep' Identification )? 'language' language = STRING_VALUE body = REGULAR_COMMENT 166 Systems Modeling Language v2.0, Part 1 -8.2.2.5 Namespaces and Packages Textual Notation 8.2.2.5.1 Packages RootNamespace : Namespace = PackageBodyElement* Package = ( ownedRelationship += PrefixMetadataMember )* PackageDeclaration PackageBody LibraryPackage = ( isStandard ?= 'standard' ) 'library' ( ownedRelationship += PrefixMetadataMember )* PackageDeclaration PackageBody PackageDeclaration : Package = 'package' Identification PackageBody : Package = ';' | '{' PackageBodyElement* '}' PackageBodyElement : Package = ownedRelationship += PackageMember | ownedRelationship += ElementFilterMember | ownedRelationship += AliasMember | ownedRelationship += Import MemberPrefix : Membership = ( visibility = VisibilityIndicator )? PackageMember : OwningMembership MemberPrefix ( ownedRelatedElement += DefinitionElement | ownedRelatedElement = UsageElement ) ElementFilterMember : ElementFilterMembership = MemberPrefix 'filter' ownedRelatedElement += OwnedExpression ';' AliasMember : Membership = MemberPrefix 'alias' ( '<' memberShortName = NAME '>' )? ( memberName = NAME )? 'for' memberElement = [QualifiedName] RelationshipBody Import = visibility = VisibilityIndicator 'import' ( isImportAll ?= 'all' )? ImportDeclaration RelationshipBody ImportDeclaration : Import = MembershipImport | NamespaceImport MembershipImport = importedMembership = [QualifiedName] ( '::' isRecursive ?= '**' )? NamespaceImport = importedNamespace = [QualifiedName] '::' '*' ( '::' isRecursive ?= '**' )? Systems Modeling Language v2.0, Part 1 167 -| importedNamspace = FilterPackage { ownedRelatedElement += importedNamespace } FilterPackage : Package = ownedRelationship += FilterPackageImport ( ownedRelationship += FilterPackageMember )+ FilterPackageMember : ElementFilterMembership = '[' ownedRelatedElement += OwnedExpression ']' VisibilityIndicator : VisibilityKind = 'public' | 'private' | 'protected' 8.2.2.5.2 Package Elements DefinitionElement : Element = Package | LibraryPackage | AnnotatingElement | Dependency | AttributeDefinition | EnumerationDefinition | OccurrenceDefinition | IndividualDefinition | ItemDefinition | PartDefinition | ConnectionDefinition | FlowDefinition | InterfaceDefinition | PortDefinition | ActionDefinition | CalculationDefinition | StateDefinition | ConstraintDefinition | RequirementDefinition | ConcernDefinition | CaseDefinition | AnalysisCaseDefinition | VerificationCaseDefinition | UseCaseDefinition | ViewDefinition | ViewpointDefinition | RenderingDefinition | MetadataDefinition | ExtendedDefinition UsageElement : Usage = NonOccurrenceUsageElement | OccurrenceUsageElement 8.2.2.6 Definition and Usage Textual Notation 8.2.2.6.1 Definitions BasicDefinitionPrefix = isAbstract ?= 'abstract' | isVariation ?= 'variation' DefinitionExtensionKeyword : Definition = ownedRelationship += PrefixMetadataMember DefinitionPrefix : Definition = BasicDefinitionPrefix? DefinitionExtensionKeyword* 168 Systems Modeling Language v2.0, Part 1 -Definition = DefinitionDeclaration DefinitionBody DefinitionDeclaration : Definition Identification SubclassificationPart? DefinitionBody : Type = ';' | '{' DefinitionBodyItem* '}' DefinitionBodyItem : Type = ownedRelationship += DefinitionMember | ownedRelationship += VariantUsageMember | ownedRelationship += NonOccurrenceUsageMember | ( ownedRelationship += SourceSuccessionMember )? ownedRelationship += OccurrenceUsageMember | ownedRelationship += AliasMember | ownedRelationship += Import DefinitionMember : OwningMembership = MemberPrefix ownedRelatedElement += DefinitionElement VariantUsageMember : VariantMembership = MemberPrefix 'variant' ownedVariantUsage = VariantUsageElement NonOccurrenceUsageMember : FeatureMembership = MemberPrefix ownedRelatedElement += NonOccurrenceUsageElement OccurrenceUsageMember : FeatureMembership = MemberPrefix ownedRelatedElement += OccurrenceUsageElement StructureUsageMember : FeatureMembership = MemberPrefix ownedRelatedElement += StructureUsageElement BehaviorUsageMember : FeatureMembership = MemberPrefix ownedRelatedElement += BehaviorUsageElement 8.2.2.6.2 Usages FeatureDirection : FeatureDirectionKind = 'in' | 'out' | 'inout' RefPrefix : Usage = ( direction = FeatureDirection )? ( isDerived ?= 'derived' )? ( isAbstract ?= 'abstract' | isVariation ?= 'variation' )? ( isConstant ?= 'constant' )? BasicUsagePrefix : Usage = RefPrefix ( isReference ?= 'ref' )? EndUsagePrefix : Usage = isEnd ?= 'end' ( ownedRelationship += OwnedCrossFeatureMember )? (see Note 1) OwnedCrossFeatureMember : OwningMembership = ownedRelatedElement += OwnedCrossFeature Systems Modeling Language v2.0, Part 1 169 -OwnedCrossFeature : ReferenceUsage = BasicUsagePrefix UsageDeclaration UsageExtensionKeyword : Usage = ownedRelationship += PrefixMetadataMember UnextendedUsagePrefix : Usage = EndUsagePrefix | BasicUsagePrefix UsagePrefix : Usage UnextendedUsagePrefix UsageExtensionKeyword* Usage = UsageDeclaration UsageCompletion UsageDeclaration : Usage = Identification FeatureSpecializationPart? UsageCompletion : Usage = ValuePart? UsageBody UsageBody : Usage = DefinitionBody ValuePart : Feature = ownedRelationship += FeatureValue FeatureValue = ( '=' | isInitial ?= ':=' | isDefault ?= 'default' ( '=' | isInitial ?= ':=' )? ) ownedRelatedElement += OwnedExpression Notes 1. A Usage parsed with isEnd = true for which mayTimeVary = true must also have isConstant set to true, even though this is not explicitly notated in the textual notation, in order to satisfy the KerML constraint checkFeatureEndIsConstant . 8.2.2.6.3 Reference Usages DefaultReferenceUsage : ReferenceUsage = RefPrefix Usage ReferenceUsage = ( EndUsagePrefix | RefPrefix ) 'ref' Usage VariantReference : ReferenceUsage = ownedRelationship += OwnedReferenceSubsetting FeatureSpecialization* UsageBody 8.2.2.6.4 Body Elements NonOccurrenceUsageElement : Usage = DefaultReferenceUsage | ReferenceUsage | AttributeUsage | EnumerationUsage | BindingConnectorAsUsage 170 Systems Modeling Language v2.0, Part 1 -| SuccessionAsUsage | ExtendedUsage OccurrenceUsageElement : Usage = StructureUsageElement | BehaviorUsageElement StructureUsageElement : Usage = OccurrenceUsage | IndividualUsage | PortionUsage | EventOccurrenceUsage | ItemUsage | PartUsage | ViewUsage | RenderingUsage | PortUsage | ConnectionUsage | InterfaceUsage | AllocationUsage | Message | FlowUsage | SuccessionFlowUsage BehaviorUsageElement : Usage = ActionUsage | CalculationUsage | StateUsage | ConstraintUsage | RequirementUsage | ConcernUsage | CaseUsage | AnalysisCaseUsage | VerificationCaseUsage | UseCaseUsage | ViewpointUsage | PerformActionUsage | ExhibitStateUsage | IncludeUseCaseUsage | AssertConstraintUsage | SatisfyRequirementUsage VariantUsageElement : Usage = VariantReference | ReferenceUsage | AttributeUsage | BindingConnectorAsUsage | SuccessionAsUsage | OccurrenceUsage | IndividualUsage | PortionUsage | EventOccurrenceUsage | ItemUsage | PartUsage | ViewUsage | RenderingUsage | PortUsage | ConnectionUsage | InterfaceUsage | AllocationUsage | Message | FlowUsage | SuccessionFlowUsage | BehaviorUsageElement Systems Modeling Language v2.0, Part 1 171 -8.2.2.6.5 Specialization SubclassificationPart : Classifier = SPECIALIZES ownedRelationship += OwnedSubclassification ( ',' ownedRelationship += OwnedSubclassification )* OwnedSubclassification : Subclassification = superClassifier = [QualifiedName] FeatureSpecializationPart : Feature = FeatureSpecialization+ MultiplicityPart? FeatureSpecialization* | MultiplicityPart FeatureSpecialization* FeatureSpecialization : Feature = Typings | Subsettings | References | Crosses | Redefinitions Typings : Feature = TypedBy ( ',' ownedRelationship += FeatureTyping )* TypedBy : Feature = DEFINED_BY ownedRelationship += FeatureTyping FeatureTyping = OwnedFeatureTyping | ConjugatedPortTyping OwnedFeatureTyping : FeatureTyping = type = [QualifiedName] | type = OwnedFeatureChain { ownedRelatedElement += type } Subsettings : Feature = Subsets ( ',' ownedRelationship += OwnedSubsetting )* Subsets : Feature = SUBSETS ownedRelationship += OwnedSubsetting OwnedSubsetting : Subsetting = subsettedFeature = [QualifiedName] | subsettedFeature = OwnedFeatureChain { ownedRelatedElement += subsettedFeature } References : Feature = REFERENCES ownedRelationship += OwnedReferenceSubsetting OwnedReferenceSubsetting : ReferenceSubsetting = referencedFeature = [QualifiedName] | referencedFeature = OwnedFeatureChain { ownedRelatedElement += referenceFeature } Crosses : Feature = CROSSES ownedRelationship += OwnedCrossSubsetting OwnedCrossSubsetting : CrossSubsetting = crossedFeature = [QualifiedName] | crossedFeature = OwnedFeatureChain { ownedRelatedElement += crossedFeature } Redefinitions : Feature = Redefines ( ',' ownedRelationship += OwnedRedefinition )* Redefines : Feature = REDEFINES ownedRelationship += OwnedRedefinition 172 Systems Modeling Language v2.0, Part 1 -OwnedRedefinition : Redefinition = redefinedFeature = [QualifiedName] | redefinedFeature = OwnedFeatureChain { ownedRelatedElement += redefinedFeature } OwnedFeatureChain : Feature = ownedRelationship += OwnedFeatureChaining ( '.' ownedRelationship += OwnedFeatureChaining )+ OwnedFeatureChaining : FeatureChaining = chainingFeature = [QualifiedName] 8.2.2.6.6 Multiplicity MultiplicityPart : Feature = ownedRelationship += OwnedMultiplicity | ( ownedRelationship += OwnedMultiplicity )? ( isOrdered ?= 'ordered' ( { isUnique = false } 'nonunique' )? | { isUnique = false } 'nonunique' ( isOrdered ?= 'ordered' )? ) OwnedMultiplicity : OwningMembership = ownedRelatedElement += MultiplicityRange MultiplicityRange = '[' ( ownedRelationship += MultiplicityExpressionMember '..' )? ownedRelationship += MultiplicityExpressionMember ']' MultiplicityExpressionMember : OwningMembership = ownedRelatedElement += ( LiteralExpression | FeatureReferenceExpression ) 8.2.2.7 Attributes Textual Notation AttributeDefinition : AttributeDefinition = DefinitionPrefix 'attribute' 'def' Definition AttributeUsage : AttributeUsage = UsagePrefix 'attribute' Usage 8.2.2.8 Enumerations Textual Notation EnumerationDefinition = DefinitionExtensionKeyword* 'enum' 'def' DefinitionDeclaration EnumerationBody EnumerationBody : EnumerationDefinition = ';' | '{' ( ownedRelationship += AnnotatingMember | ownedRelationship += EnumerationUsageMember )* '}' EnumerationUsageMember : VariantMembership = MemberPrefix ownedRelatedElement += EnumeratedValue EnumeratedValue : EnumerationUsage = 'enum'? Usage EnumerationUsage : EnumerationUsage = UsagePrefix 'enum' Usage Systems Modeling Language v2.0, Part 1 173 -8.2.2.9 Occurrences Textual Notation 8.2.2.9.1 Occurrence Definitions OccurrenceDefinitionPrefix : OccurrenceDefinition = BasicDefinitionPrefix? ( isIndividual ?= 'individual' ownedRelationship += EmptyMultiplicityMember )? DefinitionExtensionKeyword* OccurrenceDefinition = OccurrenceDefinitionPrefix 'occurrence' 'def' Definition IndividualDefinition : OccurrenceDefinition = BasicDefinitionPrefix? isIndividual ?= 'individual' DefinitionExtensionKeyword* 'def' Definition ownedRelationship += EmptyMultiplicityMember EmptyMultiplicityMember : OwningMembership = ownedRelatedElement += EmptyMultiplicity EmptyMultiplicity : Multiplicity = { } 8.2.2.9.2 Occurrence Usages OccurrenceUsagePrefix : OccurrenceUsage = BasicUsagePrefix ( isIndividual ?= 'individual' )? ( portionKind = PortionKind { isPortion = true } )? UsageExtensionKeyword* OccurrenceUsage = OccurrenceUsagePrefix 'occurrence' Usage IndividualUsage : OccurrenceUsage = BasicUsagePrefix isIndividual ?= 'individual' UsageExtensionKeyword* Usage PortionUsage : OccurrenceUsage = BasicUsagePrefix ( isIndividual ?= 'individual' )? portionKind = PortionKind UsageExtensionKeyword* Usage { isPortion = true } PortionKind = 'snapshot' | 'timeslice' EventOccurrenceUsage = OccurrenceUsagePrefix 'event' ( ownedRelationship += OwnedReferenceSubsetting FeatureSpecializationPart? | 'occurrence' UsageDeclaration? ) UsageCompletion 8.2.2.9.3 Occurrence Successions SourceSuccessionMember : FeatureMembership = 'then' ownedRelatedElement += SourceSuccession 174 Systems Modeling Language v2.0, Part 1 -SourceSuccession : SuccessionAsUsage = ownedRelationship += SourceEndMember SourceEndMember : EndFeatureMembership = ownedRelatedElement += SourceEnd SourceEnd : ReferenceUsage = ( ownedRelationship += OwnedMultiplicity )? 8.2.2.10 Items Textual Notation ItemDefinition = OccurrenceDefinitionPrefix 'item' 'def' Definition ItemUsage = OccurrenceUsagePrefix 'item' Usage 8.2.2.11 Parts Textual Notation PartDefinition = OccurrenceDefinitionPrefix 'part' 'def' Definition PartUsage = OccurrenceUsagePrefix 'part' Usage 8.2.2.12 Ports Textual Notation PortDefinition = DefinitionPrefix 'port' 'def' Definition ownedRelationship += ConjugatedPortDefinitionMember { conjugatedPortDefinition.ownedPortConjugator. originalPortDefinition = this } (See Note 1) ConjugatedPortDefinitionMember : OwningMembership = ownedRelatedElement += ConjugatedPortDefinition ConjugatedPortDefinition = ownedRelationship += PortConjugation PortConjugation = {} PortUsage = OccurrenceUsagePrefix 'port' Usage ConjugatedPortTyping : ConjugatedPortTyping = '~' originalPortDefinition = ~[QualifiedName] (See Note 2) Notes 1. Even though it is not explicitly represented in the text, a PortDefinition is always parsed as containing a nested ConjugatedPortDefinition with a PortDefinition Relationship pointing back to the containing PortDefinition . The abstract syntax for ConjugatedPortDefinition sets its effectiveName to the name of its originalPortDefinition with the symbol ~ prepended to it (see 8.3.12.2 ). (See also 8.4.8.1 .) 2. The notation ~[QualifiedName] indicates that a QualifiedName shall be parsed from the input text, but that it shall be resolved as if it was the qualified name constructed as follows: Systems Modeling Language v2.0, Part 1 175 -◦ Extract the last segment name of the given QualifiedName and prepend the symbol ~ to it. ◦ Append the name so constructed to the end of the entire original QualifiedName . For example, if the ConjugatedPortTyping is ~A::B::C , then the given QualifiedName is A::B::C , and ~[QualifiedName] is resolved as A::B::C::'~C' . Alternatively, a conforming tool may first resolve the given QualifiedName as usual to a PortDefinition and then use the conjugatedPortDefinition of this PortDefinition as the resolution of ~[QualifiedName ]. 8.2.2.13 Connections Textual Notation 8.2.2.13.1 Connection Definition and Usage ConnectionDefinition = OccurrenceDefinitionPrefix 'connection' 'def' Definition ConnectionUsage = OccurrenceUsagePrefix ( 'connection' UsageDeclaration ValuePart? ( 'connect' ConnectorPart )? | 'connect' ConnectorPart ) UsageBody ConnectorPart : ConnectionUsage = BinaryConnectorPart | NaryConnectorPart BinaryConnectorPart : ConnectionUsage = ownedRelationship += ConnectorEndMember 'to' ownedRelationship += ConnectorEndMember NaryConnectorPart : ConnectionUsage = '(' ownedRelationship += ConnectorEndMember ',' ownedRelationship += ConnectorEndMember ( ',' ownedRelationship += ConnectorEndMember )* ')' ConnectorEndMember : EndFeatureMembership : ownedRelatedElement += ConnectorEnd ConnectorEnd : ReferenceUsage = ( ownedRelationship += OwnedCrossMultiplicityMember )? ( declaredName = NAME REFERENCES )? ownedRelationship += OwnedReferenceSubsetting OwnedCrossMultiplicityMember : OwningMembership = ownedRelatedElement += OwnedCrossMultiplicity OwnedCrossMultiplicity : Feature = ownedRelationship += OwnedMultiplicity 8.2.2.13.2 Binding Connectors BindingConnectorAsUsage = UsagePrefix ( 'binding' UsageDeclaration )? 'bind' ownedRelationship += ConnectorEndMember '=' ownedRelationship += ConnectorEndMember UsageBody 8.2.2.13.3 Successions SuccessionAsUsage = UsagePrefix ( 'succession' UsageDeclaration )? 'first' s.ownedRelationship += ConnectorEndMember 176 Systems Modeling Language v2.0, Part 1 -'then' s.ownedRelationship += ConnectorEndMember UsageBody 8.2.2.14 Interfaces Textual Notation 8.2.2.14.1 Interface Definitions InterfaceDefinition = OccurrenceDefinitionPrefix 'interface' 'def' DefinitionDeclaration InterfaceBody InterfaceBody : Type = ';' | '{' InterfaceBodyItem* '}' InterfaceBodyItem : Type = ownedRelationship += DefinitionMember | ownedRelationship += VariantUsageMember | ownedRelationship += InterfaceNonOccurrenceUsageMember | ( ownedRelationship += SourceSuccessionMember )? ownedRelationship += InterfaceOccurrenceUsageMember | ownedRelationship += AliasMember | ownedRelationship += Import InterfaceNonOccurrenceUsageMember : FeatureMembership = MemberPrefix ownedRelatedElement += InterfaceNonOccurrenceUsageElement InterfaceNonOccurrenceUsageElement : Usage = ReferenceUsage | AttributeUsage | EnumerationUsage | BindingConnectorAsUsage | SuccessionAsUsage InterfaceOccurrenceUsageMember : FeatureMembership = MemberPrefix ownedRelatedElement += InterfaceOccurrenceUsageElement InterfaceOccurrenceUsageElement : Usage = DefaultInterfaceEnd | StructureUsageElement | BehaviorUsageElement DefaultInterfaceEnd : PortUsage = isEnd ?= 'end' Usage 8.2.2.14.2 Interface Usages InterfaceUsage = OccurrenceUsagePrefix 'interface' InterfaceUsageDeclaration InterfaceBody InterfaceUsageDeclaration : InterfaceUsage = UsageDeclaration ValuePart? ( 'connect' InterfacePart )? | InterfacePart InterfacePart : InterfaceUsage = BinaryInterfacePart | NaryInterfacePart BinaryInterfacePart : InterfaceUsage = ownedRelationship += InterfaceEndMember 'to' ownedRelationship += InterfaceEndMember NaryInterfacePart : InterfaceUsage = '(' ownedRelationship += InterfaceEndMember ',' ownedRelationship += InterfaceEndMember Systems Modeling Language v2.0, Part 1 177 -( ',' ownedRelationship += InterfaceEndMember )* ')' InterfaceEndMember : EndFeatureMembership = ownedRelatedElement += InterfaceEnd InterfaceEnd : PortUsage : ( ownedRelationship += OwnedCrossMultiplicityMember )? ( declaredName = NAME REFERENCES )? ownedRelationship += OwnedReferenceSubsetting 8.2.2.15 Allocations Textual Notation AllocationDefinition = OccurrenceDefinitionPrefix 'allocation' 'def' Definition AllocationUsage = OccurrenceUsagePrefix AllocationUsageDeclaration UsageBody AllocationUsageDeclaration : AllocationUsage = 'allocation' UsageDeclaration ( 'allocate' ConnectorPart )? | 'allocate' ConnectorPart 8.2.2.16 Flows Textual Notation FlowDefinition : OccurrenceDefinitionPrefix 'flow' 'def' Definition Message : FlowUsage = OccurrenceUsagePrefix 'message' MessageDeclaration DefinitionBody { isAbstract = true } MessageDeclaration : FlowUsage = UsageDeclaration ValuePart? ( 'of' ownedRelationship += FlowPayloadFeatureMember )? ( 'from' ownedRelationship += MessageEventMember 'to' ownedRelationship += MessageEventMember )? | ownedRelationship += MessageEventMember 'to' ownedRelationship += MessageEventMember MessageEventMember : ParameterMembership = ownedRelatedElement += MessageEvent MessageEvent : EventOccurrenceUsage = ownedRelationship += OwnedReferenceSubsetting FlowUsage = OccurrenceUsagePrefix 'flow' FlowDeclaration DefinitionBody SuccessionFlowUsage = OccurrenceUsagePrefix 'succession' 'flow' FlowDeclaration DefinitionBody FlowDeclaration : FlowUsage = UsageDeclaration ValuePart? ( 'of' ownedRelationship += FlowPayloadFeatureMember )? ( 'from' ownedRelationship += FlowEndMember 'to' ownedRelationship += FlowEndMember )? 178 Systems Modeling Language v2.0, Part 1 -| ownedRelationship += FlowEndMember 'to' ownedRelationship += FlowEndMember FlowPayloadFeatureMember : FeatureMembership = ownedRelatedElement += FlowPayloadFeature FlowPayloadFeature : PayloadFeature = PayloadFeature PayloadFeature : Feature = Identification? PayloadFeatureSpecializationPart ValuePart? | ownedRelationship += OwnedFeatureTyping ( ownedRelationship += OwnedMultiplicity )? | ownedRelationship += OwnedMultiplicity ownedRelationship += OwnedFeatureTyping PayloadFeatureSpecializationPart : Feature = ( -> FeatureSpecialization )+ MultiplicityPart? FeatureSpecialization* | MultiplicityPart FeatureSpecialization+ FlowEndMember : EndFeatureMembership = ownedRelatedElement += FlowEnd FlowEnd = ( ownedRelationship += FlowEndSubsetting )? ownedRelationship += FlowFeatureMember FlowEndSubsetting : ReferenceSubsetting = referencedFeature = [QualifiedName] | referencedFeature = FeatureChainPrefix { ownedRelatedElement += referencedFeature } FeatureChainPrefix : Feature = ( ownedRelationship += OwnedFeatureChaining '.' )+ ownedRelationship += OwnedFeatureChaining '.' FlowFeatureMember : FeatureMembership = ownedRelatedElement += FlowFeature FlowFeature : ReferenceUsage = ownedRelationship += FlowFeatureRedefinition (See Note 1) FlowFeatureRefefinition : Redefinition = redefinedFeature = [QualifiedName] Notes 1. To ensure that a FlowFeature passes the validateRedefinitionDirectionConformance constraint (see [KerML, 8.3.3.3.8]), its direction must be set to the direction of its redefinedFeature , relative to its owning FlowEnd , that is, the result of the following OCL expression: owningType.directionOf(ownedRedefinition->at(1).redefinedFeature) 8.2.2.17 Actions Textual Notation 8.2.2.17.1 Action Definitions ActionDefinition = OccurrenceDefinitionPrefix 'action' 'def' Systems Modeling Language v2.0, Part 1 179 -DefinitionDeclaration ActionBody ActionBody : Type = ';' | '{' ActionBodyItem* '}' ActionBodyItem : Type = NonBehaviorBodyItem | ownedRelationship += InitialNodeMember ( ownedRelationship += ActionTargetSuccessionMember )* | ( ownedRelationship += SourceSuccessionMember )? ownedRelationsuip += ActionBehaviorMember ( ownedRelationship += ActionTargetSuccessionMember )* | ownedRelationship += GuardedSuccessionMember NonBehaviorBodyItem = ownedRelationship += Import | ownedRelationship += AliasMember | ownedRelationship += DefinitionMember | ownedRelationship += VariantUsageMember | ownedRelationship += NonOccurrenceUsageMember | ( ownedRelationship += SourceSuccessionMember )? ownedRelationship += StructureUsageMember ActionBehaviorMember : FeatureMembership = BehaviorUsageMember | ActionNodeMember InitialNodeMember : FeatureMembership = MemberPrefix 'first' memberFeature = [QualifiedName] RelationshipBody ActionNodeMember : FeatureMembership = MemberPrefix ownedRelatedElement += ActionNode ActionTargetSuccessionMember : FeatureMembership = MemberPrefix ownedRelatedElement += ActionTargetSuccession GuardedSuccessionMember : FeatureMembership = MemberPrefix ownedRelatedElement += GuardedSuccession 8.2.2.17.2 Action Usages ActionUsage = OccurrenceUsagePrefix 'action' ActionUsageDeclaration ActionBody ActionUsageDeclaration : ActionUsage = UsageDeclaration ValuePart? PerformActionUsage = OccurrenceUsagePrefix 'perform' PerformActionUsageDeclaration ActionBody PerformActionUsageDeclaration : PerformActionUsage = ( ownedRelationship += OwnedReferenceSubsetting FeatureSpecializationPart? | 'action' UsageDeclaration ) ValuePart? ActionNode : ActionUsage = ControlNode | SendNode | AcceptNode | AssignmentNode | TerminateNode 180 Systems Modeling Language v2.0, Part 1 -| IfNode | WhileLoopNode | ForLoopNode ActionNodeUsageDeclaration : ActionUsage = 'action' UsageDeclaration? ActionNodePrefix : ActionUsage = OccurrenceUsagePrefix ActionNodeUsageDeclaration? 8.2.2.17.3 Control Nodes ControlNode = MergeNode | DecisionNode | JoinNode| ForkNode ControlNodePrefix : OccurrenceUsage = RefPrefix ( isIndividual ?= 'individual )? ( portionKind = PortionKind { isPortion = true } )? UsageExtensionKeyword* MergeNode = ControlNodePrefix isComposite ?= 'merge' UsageDeclaration ActionBody DecisionNode = ControlNodePrefix isComposite ?= 'decide' UsageDeclaration ActionBody JoinNode = ControlNodePrefix isComposite ?= 'join' UsageDeclaration ActionBody ForkNode = ControlNodePrefix isComposite ?= 'fork' UsageDeclaration ActionBody 8.2.2.17.4 Send and Accept Action Usages AcceptNode : AcceptActionUsage = OccurrenceUsagePrefix AcceptNodeDeclaration ActionBody AcceptNodeDeclaration : AcceptActionUsage = ActionNodeUsageDeclaration? 'accept' AcceptParameterPart AcceptParameterPart : AcceptActionUsage = ownedRelationship += PayloadParameterMember ( 'via' ownedRelationship += NodeParameterMember )? PayloadParameterMember : ParameterMembership = ownedRelatedElement += PayloadParameter PayloadParameter : ReferenceUsage = PayloadFeature | Identification PayloadFeatureSpecializationPart? TriggerValuePart Systems Modeling Language v2.0, Part 1 181 -TriggerValuePart : Feature = ownedRelationship += TriggerFeatureValue TriggerFeatureValue : FeatureValue = ownedRelatedElement += TriggerExpression TriggerExpression : TriggerInvocationExpression = kind = ( 'at | 'after' ) ownedRelationship += ArgumentMember | kind = 'when' ownedRelationship += ArgumentExpressionMember ArgumentMember : ParameterMembership = ownedMemberParameter = Argument Argument : Feature = ownedRelationship += ArgumentValue ArgumentValue : FeatureValue = value = OwnedExpression ArgumentExpressionMember : ParameterMembership = ownedRelatedElement += ArgumentExpression ArgumentExpression : Feature = ownedRelationship += ArgumentExpressionValue ArgumentExpressionValue : FeatureValue = ownedRelatedElement += OwnedExpressionReference SendNode : SendActionUsage = OccurrenceUsagePrefix ActionUsageDeclaration? 'send' ( ownedRelationship += NodeParameterMember SenderReceiverPart? | ownedRelationship += EmptyParameterMember SendReceiverPart )? ActionBody SendNodeDeclaration : SendActionUsage = ActionNodeUsageDeclaration? 'send' ownedRelationship += NodeParameterMember SenderReceiverPart? SenderReceiverPart : SendActionUsage = 'via' ownedRelationship += NodeParameterMember ( 'to' ownedRelationship += NodeParameterMember )? | ownedRelationship += EmptyParameterMember 'to' ownedRelationship += NodeParameterMember NodeParameterMember : ParameterMembership = ownedRelatedElement += NodeParameter NodeParameter : ReferenceUsage = ownedRelationship += FeatureBinding FeatureBinding : FeatureValue = ownedRelatedElement += OwnedExpression EmptyParameterMember : ParameterMembership = ownedRelatedElement += EmptyUsage EmptyUsage : ReferenceUsage = {} Notes 182 Systems Modeling Language v2.0, Part 1 -1. The productions for ArgumentMember , Argument , ArgumentValue , ArgumentExpressionMember , ArgumentExpression and ArgumentExpressionValue are the same as given in [KerML, 8.2.5.8.1]. 8.2.2.17.5 Assignment Action Usages AssignmentNode : AssignmentActionUsage = OccurrenceUsagePrefix AssignmentNodeDeclaration ActionBody AssignmentNodeDeclaration: ActionUsage = ( ActionNodeUsageDeclaration )? 'assign' ownedRelationship += AssignmentTargetMember ownedRelationship += FeatureChainMember ':=' ownedRelationship += NodeParameterMember AssignmentTargetMember : ParameterMembership = ownedRelatedElement += AssignmentTargetParameter AssignmentTargetParameter : ReferenceUsage = ( ownedRelationship += AssignmentTargetBinding '.' )? AssignmentTargetBinding : FeatureValue = ownedRelatedElement += NonFeatureChainPrimaryExpression FeatureChainMember : Membership = memberElement = [QualifiedName] | OwnedFeatureChainMember OwnedFeatureChainMember : OwningMembership = ownedRelatedElement += OwnedFeatureChain 8.2.2.17.6 Terminate Action Usages TerminateNode : TerminateActionUsage = OccurrenceUsagePrefix ActionNodeUsageDeclaration? 'terminate' ( ownedRelationship += NodeParameterMember )? ActionBody 8.2.2.17.7 Structured Control Action Usages IfNode : IfActionUsage = ActionNodePrefix 'if' ownedRelationship += ExpressionParameterMember ownedRelationship += ActionBodyParameterMember ( 'else' ownedRelationship += ( ActionBodyParameterMember | IfNodeParameterMember ) )? ExpressionParameterMember : ParameterMembership = ownedRelatedElement += OwnedExpression ActionBodyParameterMember : ParameterMembership = ownedRelatedElement += ActionBodyParameter ActionBodyParameter : ActionUsage = ( 'action' UsageDeclaration? )? '{' ActionBodyItem* '}' IfNodeParameterMember : ParameterMembership = ownedRelatedElement += IfNode WhileLoopNode : WhileLoopActionUsage = Systems Modeling Language v2.0, Part 1 183 -ActionNodePrefix ( 'while' ownedRelationship += ExpressionParameterMember | 'loop' ownedRelationship += EmptyParameterMember ) ownedRelationship += ActionBodyParameterMember ( 'until' ownedRelationship += ExpressionParameterMember ';' )? ForLoopNode : ForLoopActionUsage = ActionNodePrefix 'for' ownedRelationship += ForVariableDeclarationMember 'in' ownedRelationship += NodeParameterMember ownedRelationship += ActionBodyParameterMember ForVariableDeclarationMember : FeatureMembership = ownedRelatedElement += UsageDeclaration ForVariableDeclaration : ReferenceUsage = UsageDeclaration 8.2.2.17.8 Action Successions ActionTargetSuccession : Usage = ( TargetSuccession | GuardedTargetSuccession | DefaultTargetSuccession ) UsageBody TargetSuccession : SuccessionAsUsage = ownedRelationship += SourceEndMember 'then' ownedRelationship += ConnectorEndMember GuardedTargetSuccession : TransitionUsage = ownedRelationship += GuardExpressionMember 'then' ownedRelationship += TransitionSuccessionMember DefaultTargetSuccession : TransitionUsage = 'else' ownedRelationship += TransitionSuccessionMember GuardedSuccession : TransitionUsage = ( 'succession' UsageDeclaration )? 'first' ownedRelationship += FeatureChainMember ownedRelationship += GuardExpressionMember 'then' ownedRelationship += TransitionSuccessionMember UsageBody 8.2.2.18 States Textual Notation 8.2.2.18.1 State Definitions StateDefinition = OccurrenceDefinitionPrefix 'state' 'def' DefinitionDeclaration StateDefBody StateDefBody : StateDefinition = ';' | ( isParallel ?= 'parallel' )? '{' StateBodyItem* '}' StateBodyItem : Type = NonBehaviorBodyItem | ( ownedRelationsup += SourceSuccessionMember )? ownedRelationship += BehaviorUsageMember ( ownedRelationship += TargetTransitionUsageMember )* | ownedRelationship += TransitionUsageMember | ownedRelationship += EntryActionMember 184 Systems Modeling Language v2.0, Part 1 -( ownedRelationship += EntryTransitionMember )* | ownedRelationship += DoActionMember | ownedRelationship += ExitActionMember EntryActionMember : StateSubactionMembership = MemberPrefix kind = 'entry' ownedRelatedElement += StateActionUsage DoActionMember : StateSubactionMembership = MemberPrefix kind = 'do' ownedRelatedElement += StateActionUsage ExitActionMember : StateSubactionMembership = MemberPrefix kind = 'exit' ownedRelatedElement += StateActionUsage EntryTransitionMember : FeatureMembership : MemberPrefix ( ownedRelatedElement += GuardedTargetSuccession | 'then' ownedRelatedElement += TargetSuccession ) ';' StateActionUsage : ActionUsage = EmptyActionUsage ';' | StatePerformActionUsage | StateAcceptActionUsage | StateSendActionUsage | StateAssignmentActionUsage EmptyActionUsage : ActionUsage = {} StatePerformActionUsage : PerformActionUsage = PerformActionUsageDeclaration ActionBody StateAcceptActionUsage : AcceptActionUsage = AcceptNodeDeclaration ActionBody StateSendActionUsage : SendActionUsage SendNodeDeclaration ActionBody StateAssignmentActionUsage : AssignmentActionUsage = AssignmentNodeDeclaration ActionBody TransitionUsageMember : FeatureMembership = MemberPrefix ownedRelatedElement += TransitionUsage TargetTransitionUsageMember : FeatureMembership = MemberPrefix ownedRelatedElement += TargetTransitionUsage 8.2.2.18.2 State Usages StateUsage = OccurrenceUsagePrefix 'state' ActionUsageDeclaration StateUsageBody StateUsageBody : StateUsage = ';' | ( isParallel ?= 'parallel' )? '{' StateBodyItem* '}' ExhibitStateUsage = OccurrenceUsagePrefix 'exhibit' Systems Modeling Language v2.0, Part 1 185 -( ownedRelationship += OwnedReferenceSubsetting FeatureSpecializationPart? | 'state' UsageDeclaration ) ValuePart? StateUsageBody 8.2.2.18.3 Transition Usages TransitionUsage = 'transition' ( UsageDeclaration 'first' )? ownedRelationship += FeatureChainMember ownedRelationship += EmptyParameterMember ( ownedRelationship += EmptyParameterMember ownedRelationship += TriggerActionMember )? ( ownedRelationship += GuardExpressionMember )? ( ownedRelationship += EffectBehaviorMember )? 'then' ownedRelationship += TransitionSuccessionMember ActionBody TargetTransitionUsage : TransitionUsage = ownedRelationship += EmptyParameterMember ( 'transition' ( ownedRelationship += EmptyParameterMember ownedRelationship += TriggerActionMember )? ( ownedRelationship += GuardExpressionMember )? ( ownedRelationship += EffectBehaviorMember )? | ownedRelationship += EmptyParameterMember ownedRelationship += TriggerActionMember ( ownedRelationship += GuardExpressionMember )? ( ownedRelationship += EffectBehaviorMember )? | ownedRelationship += GuardExpressionMember ( ownedRelationship += EffectBehaviorMember )? )? 'then' ownedRelationship += TransitionSuccessionMember ActionBody TriggerActionMember : TransitionFeatureMembership = 'accept' { kind = 'trigger' } ownedRelatedElement += TriggerAction TriggerAction : AcceptActionUsage = AcceptParameterPart GuardExpressionMember : TransitionFeatureMembership = 'if' { kind = 'guard' } ownedRelatedElement += OwnedExpression EffectBehaviorMember : TransitionFeatureMembership = 'do' { kind = 'effect' } ownedRelatedElement += EffectBehaviorUsage EffectBehaviorUsage : ActionUsage = EmptyActionUsage | TransitionPerformActionUsage | TransitionAcceptActionUsage | TransitionSendActionUsage | TransitionAssignmentActionUsage TransitionPerformActionUsage : PerformActionUsage = PerformActionUsageDeclaration ( '{' ActionBodyItem* '}' )? TransitionAcceptActionUsage : AcceptActionUsage = AcceptNodeDeclaration ( '{' ActionBodyItem* '}' )? TransitionSendActionUsage : SendActionUsage = SendNodeDeclaration ( '{' ActionBodyItem* '}' )? 186 Systems Modeling Language v2.0, Part 1 -TransitionAssignmentActionUsage : AssignmentActionUsage = AssignmentNodeDeclaration ( '{' ActionBodyItem* '}' )? TransitionSuccessionMember : OwningMembership = ownedRelatedElement += TransitionSuccession TransitionSuccession : Succession = ownedRelationship += EmptyEndMember ownedRelationship += ConnectorEndMember EmptyEndMember : EndFeatureMembership = ownedRelatedElement += EmptyFeature EmptyFeature : ReferenceUsage = {} 8.2.2.19 Calculations Textual Notation CalculationDefinition = OccurrenceDefinitionPrefix 'calc' 'def' DefinitionDeclaration CalculationBody CalculationUsage : CalculationUsage = OccurrenceUsagePrefix 'calc' ActionUsageDeclaration CalculationBody CalculationBody : Type = ';' | '{' CalculationBodyPart '}' CalculationBodyPart : Type = CalculationBodyItem* ( ownedRelationship += ResultExpressionMember )? CalculationBodyItem : Type = ActionBodyItem | ownedRelationship += ReturnParameterMember ReturnParameterMember : ReturnParameterMembership = MemberPrefix? 'return' ownedRelatedElement += UsageElement ResultExpressionMember : ResultExpressionMembership = MemberPrefix? ownedRelatedElement += OwnedExpression 8.2.2.20 Constraints Textual Notation ConstraintDefinition = OccurrenceDefinitionPrefix 'constraint' 'def' DefinitionDeclaration CalculationBody ConstraintUsage = OccurrenceUsagePrefix 'constraint' ConstraintUsageDeclaration CalculationBody AssertConstraintUsage = OccurrenceUsagePrefix 'assert' ( isNegated ?= 'not' )? ( ownedRelationship += OwnedReferenceSubsetting FeatureSpecializationPart? | 'constraint' ConstraintUsageDeclaration ) CalculationBody ConstraintUsageDeclaration : ConstraintUsage = UsageDeclaration ValuePart? Systems Modeling Language v2.0, Part 1 187 -8.2.2.21 Requirements Textual Notation 8.2.2.21.1 Requirement Definitions RequirementDefinition = OccurrenceDefinitionPrefix 'requirement' 'def' DefinitionDeclaration RequirementBody RequirementBody : Type = ';' | '{' RequirementBodyItem* '}' RequirementBodyItem : Type = DefinitionBodyItem | ownedRelationship += SubjectMember | ownedRelationship += RequirementConstraintMember | ownedRelationship += FramedConcernMember | ownedRelationship += RequirementVerificationMember | ownedRelationship += ActorMember | ownedRelationship += StakeholderMember SubjectMember : SubjectMembership = MemberPrefix ownedRelatedElement += SubjectUsage SubjectUsage : ReferenceUsage = 'subject' UsageExtensionKeyword* Usage RequirementConstraintMember : RequirementConstraintMembership = MemberPrefix? RequirementKind ownedRelatedElement += RequirementConstraintUsage RequirementKind : RequirementConstraintMembership = 'assume' { kind = 'assumption' } | 'require' { kind = 'requirement' } RequirementConstraintUsage : ConstraintUsage = ownedRelationship += OwnedReferenceSubsetting FeatureSpecializationPart? RequirementBody | ( UsageExtensionKeyword* 'constraint' | UsageExtensionKeyword+ ) ConstraintUsageDeclaration CalculationBody FramedConcernMember : FramedConcernMembership = MemberPrefix? 'frame' ownedRelatedElement += FramedConcernUsage FramedConcernUsage : ConcernUsage = ownedRelationship += OwnedReferenceSubsetting FeatureSpecializationPart? CalculationBody | ( UsageExtensionKeyword* 'concern' | UsageExtensionKeyword+ ) CalculationUsageDeclaration CalculationBody ActorMember : ActorMembership = MemberPrefix ownedRelatedElement += ActorUsage ActorUsage : PartUsage = 'actor' UsageExtensionKeyword* Usage StakeholderMember : StakeholderMembership = MemberPrefix ownedRelatedElement += StakeholderUsage StakeholderUsage : PartUsage = 'stakeholder' UsageExtensionKeyword* Usage 188 Systems Modeling Language v2.0, Part 1 -8.2.2.21.2 Requirement Usages RequirementUsage = OccurrenceUsagePrefix 'requirement' ConstraintUsageDeclaration RequirementBody SatisfyRequirementUsage = OccurrenceUsagePrefix 'assert' ( isNegated ?= 'not' ) 'satisfy' ( ownedRelationship += OwnedReferenceSubsetting FeatureSpecializationPart? | 'requirement' UsageDeclaration ) ValuePart? ( 'by' ownedRelationship += SatisfactionSubjectMember )? RequirementBody SatisfactionSubjectMember : SubjectMembership = ownedRelatedElement += SatisfactionParameter SatisfactionParameter : ReferenceUsage = ownedRelationship += SatisfactionFeatureValue SatisfactionFeatureValue : FeatureValue = ownedRelatedElement += SatisfactionReferenceExpression SatisfactionReferenceExpression : FeatureReferenceExpression = ownedRelationship += FeatureChainMember 8.2.2.21.3 Concerns ConcernDefinition = OccurrenceDefinitionPrefix 'concern' 'def' DefinitionDeclaration RequirementBody ConcernUsage = OccurrenceUsagePrefix 'concern' ConstraintUsageDeclaration RequirementBody 8.2.2.22 Cases Textual Notation CaseDefinition = OccurrenceDefinitionPrefix 'case' 'def' DefinitionDeclaration CaseBody CaseUsage = OccurrenceUsagePrefix 'case' ConstraintUsageDeclaration CaseBody CaseBody : Type = ';' | '{' CaseBodyItem* ( ownedRelationship += ResultExpressionMember )? '}' CaseBodyItem : Type = ActionBodyItem | ownedRelationship += SubjectMember | ownedRelationship += ActorMember | ownedRelationship += ObjectiveMember ObjectiveMember : ObjectiveMembership = MemberPrefix 'objective' ownedRelatedElement += ObjectiveRequirementUsage Systems Modeling Language v2.0, Part 1 189 -ObjectiveRequirementUsage : RequirementUsage = UsageExtensionKeyword* ConstraintUsageDeclaration RequirementBody 8.2.2.23 Analysis Cases Textual Notation AnalysisCaseDefinition = OccurrenceDefinitionPrefix 'analysis' 'def' DefinitionDeclaration CaseBody AnalysisCaseUsage = OccurrenceUsagePrefix 'analysis' ConstraintUsageDeclaration CaseBody 8.2.2.24 Verification Cases Textual Notation VerificationCaseDefinition = OccurrenceDefinitionPrefix 'verification' 'def' DefinitionDeclaration CaseBody VerificationCaseUsage = OccurrenceUsagePrefix 'verification' ConstraintUsageDeclaration CaseBody RequirementVerificationMember : RequirementVerificationMembership = MemberPrefix 'verify' { kind = 'requirement' } ownedRelatedElement += RequirementVerificationUsage RequirementVerificationUsage : RequirementUsage = ownedRelationship += OwnedReferenceSubsetting FeatureSpecialization* RequirementBody | ( UsageExtensionKeyword* 'requirement' | UsageExtensionKeyword+ ) ConstraintUsageDeclaration RequirementBody 8.2.2.25 Use Cases Textual Notation UseCaseDefinition = OccurrenceDefinitionPrefix 'use' 'case' 'def' DefinitionDeclaration CaseBody UseCaseUsage = OccurrenceUsagePrefix 'use' 'case' ConstraintUsageDeclaration CaseBody IncludeUseCaseUsage : OccurrenceUsagePrefix 'include' ( ownedRelationship += OwnedReferenceSubsetting FeatureSpecializationPart? | 'use' 'case' UsageDeclaration ) ValuePart? CaseBody 8.2.2.26 Views and Viewpoints Textual Notation 8.2.2.26.1 View Definitions ViewDefinition = OccurrenceDefinitionPrefix 'view' 'def' DefinitionDeclaration ViewDefinitionBody 190 Systems Modeling Language v2.0, Part 1 -ViewDefinitionBody : ViewDefinition = ';' | '{' ViewDefinitionBodyItem* '}' ViewDefinitionBodyItem : ViewDefinition = DefinitionBodyItem | ownedRelationship += ElementFilterMember | ownedRelationship += ViewRenderingMember ViewRenderingMember : ViewRenderingMembership = MemberPrefix 'render' ownedRelatedElement += ViewRenderingUsage ViewRenderingUsage : RenderingUsage = ownedRelationship += OwnedReferenceSubsetting FeatureSpecializationPart? UsageBody | ( UsageExtensionKeyword* 'rendering' | UsageExtensionKeyword+ ) Usage 8.2.2.26.2 View Usages ViewUsage = OccurrenceUsagePrefix 'view' UsageDeclaration? ValuePart? ViewBody ViewBody : ViewUsage = ';' | '{' ViewBodyItem* '}' ViewBodyItem : ViewUsage = DefinitionBodyItem | ownedRelationship += ElementFilterMember | ownedRelationship += ViewRenderingMember | ownedRelationship += Expose Expose = 'expose' ( MembershipExpose | NamespaceExpose ) RelationshipBody MembershipExpose = MembershipImport NamespaceExpose = NamespaceImport 8.2.2.26.3 Viewpoints ViewpointDefinition = OccurrenceDefinitionPrefix 'viewpoint' 'def' DefinitionDeclaration RequirementBody ViewpointUsage = OccurrenceUsagePrefix 'viewpoint' ConstraintUsageDeclaration RequirementBody 8.2.2.26.4 Renderings RenderingDefinition = OccurrenceDefinitionPrefix 'rendering' 'def' Definition Systems Modeling Language v2.0, Part 1 191 -RenderingUsage = OccurrenceUsagePrefix 'rendering' Usage 8.2.2.27 Metadata Textual Notation MetadataDefinition = ( isAbstract ?= 'abstract')? DefinitionExtensionKeyWord* 'metadata' 'def' Definition PrefixMetadataAnnotation : Annotation = '#' annotatingElement = PrefixMetadataUsage { ownedRelatedElement += annotatingElement } PrefixMetadataMember : OwningMembership = '#' ownedRelatedEleemnt = PrefixMetadataUsage PrefixMetadataUsage : MetadataUsage = ownedRelationship += OwnedFeatureTyping MetadataUsage = UsageExtensionKeyword* ( '@' | 'metadata' ) MetadataUsageDeclaration ( 'about' ownedRelationship += Annotation ( ',' ownedRelationship += Annotation )* )? MetadataBody MetadataUsageDeclaration : MetadataUsage = ( Identification ( ':' | 'typed' 'by' ) )? ownedRelationship += OwnedFeatureTyping MetadataBody : Type = ';' | '{' ( ownedRelationship += DefinitionMember | ownedRelationship += MetadataBodyUsageMember | ownedRelationship += AliasMember | ownedRelationship += Import )* '}' MetadataBodyUsageMember : FeatureMembership = ownedMemberFeature = MetadataBodyUsage MetadataBodyUsage : ReferenceUsage : 'ref'? ( ':>>' | 'redefines' )? ownedRelationship += OwnedRedefinition FeatureSpecializationPart? ValuePart? MetadataBody ExtendedDefinition : Definition = BasicDefinitionPrefix? DefinitionExtensionKeyword+ 'def' Definition ExtendedUsage : Usage = UnextendedUsagePrefix UsageExtensionKeyword+ Usage 192 Systems Modeling Language v2.0, Part 1 -8.2.3 Graphical Notation 8.2.3.1 Graphical Notation Overview A graphical view is rendered as a graph with nodes connected by edges. The nodes and edges may be rendered with specialized syntax in different views. Nodes that depict definition and usage elements may also contain connection points, such as those corresponding to ports and parameters. Each node in a graphical view can have any number of compartments. Each compartment is also a view that contains selected members of the node (which may be modeled as a view usage having a filter condition selecting the contents). The compartment shall either be a textual compartment, whose contents are rendered using textual syntax, or a graphical compartment, whose contents are rendered using graphical syntax. In either case, the rendering shall be as specified in the graphical notation grammar (see below and 8.2.3.2 ). A diagram is a view where the diagram header is the name compartment of the view (see view-frame in 8.2.3.26 ). The view exposes some portion of the model and applies filter conditions to select the contents to be rendered in a compartment of the view. The compartment shall either be a textual compartment or a graphical compartment. The StandardViewDefinitions package in the Systems Model Library (see 9.2.20 ) provides a set of standard view definitions for typical kinds of diagrams, including the valid contents for the view. The standard views are then rendered as specified in the graphical notation grammar (as given in Table 34 in 9.2.20.1 ). User-defined view definitions and usages (see 8.2.2.26 and 8.2.3.26 ) can also be used to provide views beyond the standard set. User- defined views may use or extend the graphical notation specification, but this is not required. The SysML graphical notation is expressed using a simplified form of the EBNF notation used to define the SysML textual notation (see 8.2.2.1.1 ). This graphical BNF has been extended to include productions with a mixture of graphical and textual elements. Table 30 summarizes the conventions used. Table 30. Graphical BNF Conventions non-terminal-element Non-terminal element non-terminal-element = elements Non-terminal element production (complete) non-terminal-element =| elements Non-terminal element production (partial) ( elements ) Grouping elements | elements Alternative elements element * Repeated elements (zero or more) element + Repeated elements (one or more) element ? Optional elements (zero or one) Elements 2-D layout of graphical and textual elements Graphical element graphical shape or graphical line Graphical shape 2-D shape with optional nested elements Graphical line 1-D shape with optional nested elements &element graphical-line &element Graphical line that connects other elements element1 element2 Sequential text elements 'terminal' Terminal text element as literal string Terminal text element as lexical symbol LEXICAL Systems Modeling Language v2.0, Part 1 193 -graphical production <=> textual Graphical Notation to Textual Notation mapping production These conventions make a distinction between a complete production, which must include all alternatives within the production itself, and partial productions, which allow alternatives to be distributed across multiple productions located anywhere within a specification. This distinction allows greater reuse of production symbols across sections of a specification that build on partial productions given by earlier sections, while still making clear productions that are already complete within a given section. A graphical production contains a two-dimensional layout of graphical and textual elements including graphical shapes and lines. Shapes may contain other elements nested within these shapes. Generally speaking, graphical elements specify only containment and connectivity of graphical and textual elements out of which they are built. Shapes within the graphical notation may generally be relocated anywhere within a given graphical layout. They may also have any of their graphical elements stretched as necessary to hold their contents. Lines that connect other graphical elements may be composed of one or more straight or curved line segments. Any of these line segments may contain a semicircular jump symbol where the segment overlaps a line segment of another connecting line. A textual production contains only other textual productions. All production symbols within the graphical BNF follow a convention of all-lowercase names with optional internal hyphens. Elements of the textual notation defined in subclause 8.2.2 of this specification may also be referenced by textual productions within the graphical BNF. These imported textual notation elements can be distinguished from those of the graphical BNF by their use of one or more uppercase letters within the name. 8.2.3.2 Elements and Relationships Graphical Notation element = dependencies-and-annotations-element | general-element | element-inside-textual-compartment compartment =| general-compartment general-compartment = 'general' general-view general-view = (general-element)* (dependencies-and-annotations-element)* (ellipsis-at-lower-left-corner)? ellipsis-at-lower-left-corner = '...' general-element = general-node | general-relationship element-node = usage-node | definition-node | annotation-node | namespace-node element-inside-textual-compartment = rel-name = 194 Systems Modeling Language v2.0, Part 1 -Identification | QualifiedName Note. An element inside a textual compartment is selected by graying out a substring containing the element. The grayed-out section must cover a single element within the textual syntax inside the compartment. 8.2.3.3 Dependencies Graphical Notation dependencies-and-annotations-element =| dependencies-element dependencies-element =| binary-dependency | n-ary-dependency binary-dependency = (rel-name)? &element-node &element-node n-ary-dependency = &n-ary-association-dot (n-ary-dependency-client-or-supplier-link &element-node)+ n-ary-dependency-client-or-supplier-link = n-ary-dependency-client-link | n-ary-dependency-supplier-link n-ary-association-dot = (rel-name)? n-ary-dependency-client-link = &element-node &n-ary-association-dot n-ary-dependency-supplier-link = &n-ary-association-dot &element-node element-node = usage-node | definition-node | annotation-node | namespace-node Note. An n-ary dependency must have two or more client elements or two or more supplier elements. 8.2.3.4 Annotations Graphical Notation dependencies-and-annotations-element =| annotation-node | annotation-link annotation-node = comment-node | documentation-node | textual-representation-node text-block = (LINE_TEXT)* comment-node = Systems Modeling Language v2.0, Part 1 195 -comment-without-keyword | comment-with-keyword comment-without-keyword = text-block comment-with-keyword = '«comment»' 22 Identification ( 'locale' STRING_VALUE )? text-block documentation-node = '«doc»' Identification ( 'locale' STRING_VALUE )? text-block documentation-compartment = 'doc' Identification text-block textual-representation-node = '«rep»' Identification language-string text-block language-string = 'language' '=' STRING_VALUE annotation-link = (rel-name)? &annotation-node &element annotated-element = element | element-inside-textual-compartment Note. A comment node may be attached to zero, one, or more than one annotated elements. All other annotation nodes must be attached to one and only one annotated element. 196 Systems Modeling Language v2.0, Part 1 -8.2.3.5 Namespaces and Packages Graphical Notation general-node =| namespace-node namespace-node =| package-node package-node = package-with-name-inside | package-with-name-in-tab | imported-package-with-name-inside | imported-package-with-name-in-tab package-with-name-inside = Identification package-with-name-in-tab = Identification general-view (package-compartment)* imported-package-with-name-inside = Identification imported-package-with-name-in-tab = Systems Modeling Language v2.0, Part 1 197 -Identification general-view (package-compartment)* package-compartment = general-compartment | documentation-compartment | packages-compartment | members-compartment | relationships-compartment compartment =| package-compartment packages-compartment = 'packages' packages-compartment-contents packages-compartment-contents = packages-compartment-element* '…'? packages-compartment-element = el-prefix? Identification members-compartment = 'members' members-compartment-contents members-compartment-contents = members-compartment-element* '…'? members-compartment-element = el-prefix? (DefinitionElement | UsageElement) relationships-compartment = 'relationships' relationships-compartment-contents relationships-compartment-contents = (relationships-compartment-element)* '…'? relationships-compartment-element = el-prefix? relationship-name QualifiedName relationship-name = 'defines', 'defined by', 'specializes', 'specialized by', 'connect to', 'subsets', 'subsetted by', 'performs', 'performed by', 'allocated', 'allocated to', 'satisfy', 'satisfied by' general-relationship =| import | top-level-import | recursive-import | owned-membership | unowned-membership import = 198 Systems Modeling Language v2.0, Part 1 -'«' VisibilityIndicator? 'import' '»' &namespace-node &namespace-node top-level-import = '«' VisibilityIndicator? 'import' '»*' &namespace-node &namespace-node recursive-import = '«' VisibilityIndicator? 'import' '»**' &namespace-node &namespace-node owned-membership = &namespace-node &element-node unowned-membership = &namespace-node &element-node 8.2.3.6 Definition and Usage Graphical Notation general-node =| type-node type-node = definition-node | usage-node general-node |= usage-node definition-node< namespace-node =| type-node definition-name-with-alias = DefinitionDeclaration ( '«alias»' ( QualifiedName (',' QualifiedName)* ) )? usage-name-with-alias = '^'? UsageDeclaration ( '«alias»' ( QualifiedName (',' QualifiedName)* ) )? compartment-stack = (compartment)* compartment =| | features-compartment | variants-compartment | variant-elementusages-compartment features-compartment = 'features' features-compartment-contents features-compartment-contents = (features-compartment-element)* '…'? features-compartment-element = el-prefix? UsagePrefix usage-cp Systems Modeling Language v2.0, Part 1 199 -variants-compartment = 'variants' variants-compartment-contents variants-compartment-contents = members-compartment-contents variant-elementusages-compartment = 'variant elementusages' variants-compartment-contents general-relationship =| type-relationship type-relationship = subclassification | subsetting | definition | redefinition | composite-feature-membership | noncomposite-feature-membership subclassification = &definition-node &definition-node definition = &definition-node &usage-node subsetting = &usage-node &usage-node reference-subsetting = &usage-node &usage-node redefinition = &usage-node &usage-node composite-feature-membership = &type-node &usage-node noncomposite-feature-membership = 200 Systems Modeling Language v2.0, Part 1 -&type-node &usage-node el-prefix = '^' | '/' usage-cp = usageDeclaration ValuePart? extended-def = extended-def-name-compartment compartment-stack extended-def-name-compartment = '«' BasicDefinitionPrefix? DefinitionExtensionKeyword+ 'def' '»' definition-name-with-alias Note. This production is only valid for cases where one or more DefinitionExtensionKeyword names a MetadataDefinition that is a direct or indirect specialization of KerML metaclass SemanticMetadata. definition-node |= extended-def extended-usage = extended-usage-name-compartment compartment-stack extended-usage-name-compartment = '«' BasicUsagePrefix? UsageExtensionKeyword+ '»' usage-name-with-alias Note. This production is only valid for cases where one or more UsageExtensionKeyword names a MetadataDefinition that is a direct or indirect specialization of KerML metaclass SemanticMetadata. usage-node |= extended-usage 8.2.3.7 Attributes Graphical Notation definition-node =| attribute-def attribute-def = attribute-def-name-compartment compartment-stack Systems Modeling Language v2.0, Part 1 201 -attribute-def-name-compartment = '«' DefinitionPrefix 'attribute' 'def' '»' definition-name-with-alias usage-node =| attribute attribute = attribute-name-compartment compartment-stack attribute-name-compartment = '«' UsagePrefix 'attribute' '»' usage-name-with-alias compartment =| attributes-compartment attributes-compartment = 'attributes' attributes-compartment-contents attributes-compartment-contents = (attributes-compartment-element)* '…'? attributes-compartment-element = el-prefix? UsagePrefix usage-cp 8.2.3.8 Enumerations Graphical Notation definition-node =| enumeration-def enumeration-def = enumeration-def-name-compartment compartment-stack enumeration-def-name-compartment = '«' DefinitionPrefix 'enum' 'def' '»' definition-name-with-alias usage-node =| enumeration enumeration = enumeration-name-compartment compartment-stack 202 Systems Modeling Language v2.0, Part 1 -enumeration-name-compartment = '«' UsagePrefix 'enum' '»' usage-name-with-alias compartment =| enums-compartment enums-compartment = 'enums' enums-compartment-contents enums-compartment_contents = (enums-compartment-element)* '…'? enums-compartment-element = el-prefix? UsagePrefix usage-cp 8.2.3.9 Occurrences Graphical Notation definition-node =| occurrence-def general-relationship =| portion-relationship occurrence-def = occurrence-def-name-compartment sequence-view compartment-stack occurrence-def-name-compartment = '«' DefinitionPrefix 'occurrence' 'def' '»' definition-name-with-alias usage-node =| occurrence | occurrence-refxfx | timeslice-or-snapshot-node occurrence = occurrence-name-compartment sequence-view compartment-stack occurrence-ref = Systems Modeling Language v2.0, Part 1 203 -occurrence-name-compartment sequence-view compartment-stack occurrence-name-compartment = '«' OccurrenceUsagePrefix 'occurrence' '»' usage-name-with-alias timeslice-or-snapshot-node = timeslice | snapshot timeslice = rd timeslice-name-compartment compartment-stack timeslice-name-compartment = '«timeslice»' usage-name-with-alias snapshot = snapshot-name-compartment compartment-stack snapshots-name-compartment '«snapshot»' usage-name-with-alias event-occurrence-def = event-occurrence-def-name-compartment compartment-stack event-occurrence-def-name-compartment = '«' DefinitionPrefix 'event' 'occurrence' 'def' '»' definition-name-with-alias definition-node |= event-occurrence-def event-occurrence = 204 Systems Modeling Language v2.0, Part 1 -event-occurrence-name-compartment compartment-stack event-occurrence-name-compartment = '«' OccurrenceUsagePrefix 'event' 'occurrence' '»' usage-name-with-alias usage-node |= event-occurrence event-edge = '«event»' &eventer &event-occurence eventer = usage-node | definition-node< portion-relationship = &occurrence-node ×lice-or-snapshot-node compartment =| occurrences-compartment | individuals-compartment | timeslices-compartment | snapshots-compartment | sequence-compartment occurrences-compartment = 'occurrences' occurrences-compartment-contents occurrences-compartment-contents = (occurrences-compartment-element)* '…'? occurrences-compartment-element = el-prefix? OccurrenceUsagePrefix usage-cp individuals-compartment = 'individuals' individuals-compartment-contents individuals-compartment-contents = (individuals-compartment-element)* '…'? individuals-compartment-element = occurrences-compartment-element timeslices-compartment = 'timeslices' timeslices-compartment-contents timeslices-compartment-contents = (timeslices-compartment-element)* '…'? timeslices-compartment-element = occurrences-compartment-element Systems Modeling Language v2.0, Part 1 205 -snapshots-compartment = 'snapshots' snapshots-compartment-contents snapshots-compartment-contents = (snapshots-compartment-element)* '…'? snapshots-compartment-element = occurrences-compartment-element sequence-compartment = 'sequence' sequence-view sequence-view = (sq-graphical-element)* sq-graphical-element = sq-graphical-node | sq-graphical-relationship | dependencies-and-annotations-element sq-graphical-node = sq-head-node | lifeline sq-head-node = sq-part | sq-port sq-part = part-name-compartment sq-port* sq-port = sq-port-label sq-port-label = UsageDeclaration sq-l-node = lifeline | sq-proxy lifeline = 206 Systems Modeling Language v2.0, Part 1 -&sq-head-node sq-proxy* sq-proxy = proxy-label | proxy-label proxy-label = '.'? FeatureChainMember sq-graphical-relationship = message | sq-succession succession-label = UsageDeclaration? sq-succession = '«succession»'? succession-label &sq-l-node &sq-l-node succession-label = Identification Note: the proxy nodes attached to a succession must refer to an event 8.2.3.10 Items Graphical Notation definition-node =| item-def interconnection-element = | item| item-ref item-def = item-def-name-compartment compartment-stack item-def-name-compartment = Systems Modeling Language v2.0, Part 1 207 -'«' DefinitionPrefix 'item' 'def' '»' definition-name-with-alias usage-node =| item item = item-name-compartment compartment-stack item-name-compartment = '«' OccurrenceUsagePrefix 'item' '»' usage-name-with-alias item-ref = item-name-compartment compartment-stack compartment =| items-compartment items-compartment = 'items' items-compartment-contents items-compartment-contents = (items-compartment-element)* '…' items-compartment-element = el-prefix? OccurrenceUsagePrefix usage-cp 8.2.3.11 Parts Graphical Notation definition-node =| part-def interconnection-element = | part | part-ref part-def = 208 Systems Modeling Language v2.0, Part 1 -port-t* part-def-name-compartment port-l* port-r* interconnection-view compartment-stack port-b* part-def-name-compartment = '«' DefinitionPrefix 'part' 'def' '»' definition-name-with-alias usage-node =| part part = port-t* part-name-compartment port-l* port-r* interconnection-view compartment-stack port-b* part-name-compartment = '«' OccurrenceUsagePrefix 'part' '»' usage-name-with-alias part-ref = port-t* part-name-compartment port-l* port-r* interconnection-view compartment-stack port-b* compartment =| parts-compartment | directed-features-compartment | interconnection-compartment Systems Modeling Language v2.0, Part 1 209 -parts-compartment = 'parts' parts-compartment-contents parts-compartment-contents = (parts-compartment-element)* '…'? parts-compartment-element = el-prefix? OccurrenceUsagePrefix usage-cp directed-features-compartment = 'directed features' directed-features-compartment-contents directed-features-compartment-contents = (directed-features-compartment-element)* '…'? directed-features-compartment-element = el-prefix FeatureDirection Definition-Body-Item* interconnection-compartment = 'interconnection' interconnection-view interconnection-view =| (interconnection-element)* (dependencies-and-annotations-element)* (ellipsis-at-lower-left-corner)? general-view =| interconnection-view 8.2.3.12 Ports Graphical Notation definition-node =| port-def port-def = port-t* port-def-name-compartment port-l* port-r* compartment-stack port-b* port-def-name-compartment = '«' DefinitionPrefix 'port' 'def' '»' definition-name-with-alias usage-node =| port-usage port-usage = 210 Systems Modeling Language v2.0, Part 1 -port-t* port-name-compartment port-l* port-r* compartment-stack port-b* port-name-compartment = '«' OccurrenceUsagePrefix 'port' '»' usage-name-with-alias compartment =| ports-compartment ports-compartment = 'ports' ports-compartment-contents ports-compartment-contents = (ports-compartment-element)* '…'? ports-compartment-element = el-prefix? OccurrenceUsagePrefix usage-cp interconnection-element =| port-def | port pdh = | | pdv = | | port-l = Systems Modeling Language v2.0, Part 1 211 -port-label pdh | port-label pdh | pdh l e b a l port-l* - t r o p | proxy-v port-r = port-label pdh | port-label pdh | 212 Systems Modeling Language v2.0, Part 1 -pdh l e b a port-r* l - t r o p | proxy-v port-t = port-label pdv | port-label pdv | port-t* v port-label d p | proxy-h port-b = pdv port-label | pdv port-label | v port-label d p port-b* | proxy-h Systems Modeling Language v2.0, Part 1 213 -port-label = QualifiedName (':' QualifiedName)? proxy-v = proxy-label | proxy-label proxy-h = proxy-label | proxy-label Note. Dotted line port productions (references) are only possible for nested ports Note. The proxy option of a port production is valid only on a part usage contained within an interconnection view. 8.2.3.13 Connections Graphical Notation definition-node =| connection-def connection-def = connection-def-name-compartment compartment-stack connection-def-name-compartment = '«' DefinitionPrefix 'connection' 'def' '»' definition-name-with-alias usage-node =| connection connection = 214 Systems Modeling Language v2.0, Part 1 -connection-name-compartment compartment-stack connection-name-compartment = '«' OccurrenceUsagePrefix 'connection' '»' usage-name-with-alias compartment =| connections-compartment connections-compartment = 'connections' connections-compartment-contents connections-compartment-contents = (connections-compartment-element)* '…'? connections-compartment-element = el-prefix? OccurrenceUsagePrefix UsageDeclaration interconnection-element =| connection-def | connection | connection-relationship | attribute connection-relationship = binding-connection | connection-graphical | n-ary-connection | n-ary-connection-def | connection-definition-elaboration | connection-usage-elaboration | connection-def-graphical connection-graphical = rolename rolename connection-label? &connection-end &connection-end multiplicity multiplicity c-adornment c-adornment | connection-label? rolename rolename &connection-end &connection-end multiplicity multiplicity c-adornment c-adornment c-adornment = (a-property | a-direction | a-subsetting |a-redefinition)* a-property = 'ordered' | 'nonunique' | 'abstract' | 'derived' | 'readonly' a-direction = 'in' | 'out' | 'inout' a-subsetting = 'subsets' OwnedSubsetting (',' OwnedSubsetting)* a-redefinition = Systems Modeling Language v2.0, Part 1 215 -'redefines' OwnedRedefinition (',' OwnedRedefinition)* connection-end = usage-node | usage-edge usage-edge =| connection-graphical | binding-connection connection-label = UsageDeclaration connection-def-graphical = connection-label? rolename rolename &type-node &type-node multiplicity multiplicity c-adornment c-adornment | connection-label? rolename rolename &type-node &type-node multiplicity multiplicity c-adornment c-adornment general-relationship |= connection-def-graphical cdef-label = Identification n-ary-connection-def = n-ary-def-connection-dot n-ary-def-segment+ n-ary-def-connection-dot = cdot-def-label n-ary-def-segment = rolename &type-node &n-ary-def- connection-dot multiplicity c-adornment definition-node |= n-ary-def-connection-dot general-relationship |= n-ary-def-segment n-ary-connection = n-ary-connection-dot n-ary-segment+ n-ary-connection-dot = cdot-label usage-node |= n-ary-connection-dot cdot-label = UsageDeclaration n-ary-segment = rolename &n-ary-connection-dot &usage-node multiplicity 216 Systems Modeling Language v2.0, Part 1 -binding-connection = '=' &usage-node &usage-node rolename = Identification? multiplicity = MultiplicityRange? connection-definition-elaboration = &connection-relationship &definition-node connection-usage-elaboration = &connection-relationship &usage-node Note. The usage-nodes at the ends of a binding-connection must be of compatible types. 8.2.3.14 Interfaces Graphical Notation definition-node =| interface-def interconnection-element =| interface interface-def = interface-def-name-compartment compartment-stack interface-def-name-compartment = Systems Modeling Language v2.0, Part 1 217 -'«' DefinitionPrefix 'interface' 'def' '»' definition-name-with-alias< usage-node =| interface interface = interface-name-compartment compartment-stack interface-name-compartment = '«' OccurrenceUsagePrefix 'interface' '»' usage-name-with-alias compartment =| interfaces-compartment | ends-compartment interfaces-compartment = 'interfaces' interfaces-compartment-contents interfaces-compartment-contents = (interfaces-compartment-element)* '…'? interfaces-compartment-element = el-prefix? OccurenceUsagePrefix InterfaceUsageDeclaration ends-compartment = 'ends' ends-compartment-contents ends-compartment-contents = (ends-compartment-element)* '…'? ends-compartment-element = QualifedName (':' QualifiedName)? connection-relationship = | interface-connection interface-connection = '«interface»'? interface-label rolename rolename &port-node &port-node flow-node* multiplicity multiplicity interface-label = UsageDeclaration? 8.2.3.15 Allocations Graphical Notation definition-node =| allocation-def 218 Systems Modeling Language v2.0, Part 1 -allocation-def = allocation-def-name-compartment compartment-stack allocation-def-name-compartment = '«' DefinitionPrefix 'allocation' 'def' '»' definition-name-with-alias usage-node =| allocation allocation = allocation-name-compartment compartment-stack allocation-name-compartment = '«' OccurrenceUsagePrefix 'allocation' '»' usage-name-with-alias compartment =| allocations-compartment allocations-compartment = 'allocations' allocations-compartment-contents allocations-compartment-contents = (allocations-compartment-element)* '…'? allocations-compartment-element = el-prefix? OccurrenceUsagePrefix AllocationUsageDeclaration UsageBody* general-relationship =| allocate-relationship allocate-relationship = ''«allocate»'' &allocation-node &allocation-node allocation-node = general-node | element-in-textual-compartment usage-edge = |allocate-relationship 8.2.3.16 Flows Graphical Notation definition-node =| flow-def flow-def = Systems Modeling Language v2.0, Part 1 219 -flow-def-name-compartment compartment-stack flow-def-name-compartment = '«' DefinitionPrefix 'succession'? 'flow' 'def' '»' definition-name-with-alias usage-node =| flow-node flow-node = flow-name-compartment compartment-stack flow-name-compartment = '«' OccurrenceUsagePrefix ( 'message' | 'succession'? 'flow' ) '»' usage-name-with-alias compartment =| flows-compartment flows-compartment = 'flows' flows-compartment-contents flows-compartment-contents = (flows-compartment-element)* '...'? flows-compartment-element = el-prefix? OccurrenceUsagePrefix ( 'message' MessageDeclaration | 'succession'? FlowDeclaration ) interconnection-element =| flow-def | flow connection-relationship =| message-connection | flow | succession-flow | flow-on-connection usage-edge =| message | flow | succession-flow msg-end-node = occurrence| sq-l-node| item | part | port | action | state | use-case | verification-case | analysis-case | proxy message = 220 Systems Modeling Language v2.0, Part 1 -'«message»'? message-label &msg-end-node &msg-end-node Note: proxy nodes and ends of messages must refer to occurrences message-label = UsageDeclaration? ('of' FlowPayloadFeatureMember)? | FlowPayloadFeatureMember flow = '«flow»'? flow-label &flow-end-node &flow-end-node flow-label = UsageDeclaration? ('of' FlowPayloadFeatureMember)? | FlowPayloadFeatureMember flow-end-node = parameter | proxy Note: proxy nodes at ends of flows must refer to directed features succession-flow = '«succession flow»'? succession-flow-label &flow-end-node &flow-end-node succession-flow-label = flow-label flow-on-connection = &port-node flow-node* &port-node flow-node = flow-node-r | flow-node-l | sflow-node-r | sflow-node-l | message-node-r | message-node-l flow-node-r = '«flow»'? flow-label flow-node-l = Systems Modeling Language v2.0, Part 1 221 -'«flow»'? flow-label sflow-node-r = '«succession flow»'? flow-label sflow-node-l = '«succession flow»'? flow-label message-node-r = '«message»'? message-label message-node-l = '«message»'? message-label flow-label = Identification | FlowPayloadFeatureMember 8.2.3.17 Actions Graphical Notation definition-node =| action-def action-def = 222 Systems Modeling Language v2.0, Part 1 -param-t* action-def-name-compartment param-l* param-r* action-flow-view compartment-stack param-b* action-def-name-compartment = '«' DefinitionPrefix 'action' 'def' '»' definition-name-with-alias< usage-node =| action | perform-action-usage action = param-t* action-name-compartment param-l* param-r* action-flow-view compartment-stack param-b* action-name-compartment = '«' OccurrenceUsagePrefix 'action' '»' usage-name-with-alias< perform-action-usage = perform-action-name-compartment compartment-stack action-ref = Systems Modeling Language v2.0, Part 1 223 -param-t* action-name-compartment param-l* param-r* action-flow-view compartment-stack param-b* perform-action-name-compartment = '«' OccurrenceUsagePrefix 'perform' 'action' '»' usage-name-with-alias compartment =| actions-compartment | perform-actions-compartment | parameters-compartment | action-flow-compartment actions-compartment = 'actions' actions-compartment-contents actions-compartment-contents = (actions-compartment-element)* '…'? actions-compartment-element = el-prefix? OccurrenceUsagePrefix ActionUsageDeclaration perform-actions-compartment = 'perform actions' perform-actions-compartment-contents perform-actions-compartment-contents = (perform-actions-compartment-element)* '…'? perform-actions-compartment-element = el-prefix? OccurrenceUsagePrefix PerformActionUsageDeclaration parameters-compartment = 'parameters' parameters-compartment-contents parameters-compartment-contents = (parameters-compartment-element)* '…'? parameters-compartment-element = el-prefix? FeatureDirection UsageDeclaration ValueOrFlowPart? DefinitionBodyItem* performed-by-compartment = 'performed by' performed-by-compartment-contents performed-by-compartment-contents = QualifiedName* '…'? 224 Systems Modeling Language v2.0, Part 1 -action-flow-compartment = 'action flow' action-flow-view action-flow-view = (dependencies-and-annotations-element)* (action-flow-element)* (perform-action-swimlanes)? action-flow-element =| action-ref | action | action-flow-node | action-flow-relationship action-flow-node = start-node | done-node | terminate-node | fork-node | join-node | decision-node | merge-node | send-action-node | accept-action-node | while-loop-action-node | for-loop-action-node | if-else-action-node | assign-action-node action-flow-relationship = flow | aflow-succession | binding-connection | else-branch param-l = param-label pdh | Systems Modeling Language v2.0, Part 1 225 -pdh l e b a l - param-l* m a r a p | proxy-v param-r = param-label pdh | pdh p a r a m param-r* - l a b e l | proxy-v param-t = param-label pdv | 226 Systems Modeling Language v2.0, Part 1 -v d param-label p | proxy-h param-b = pdv param-label | v param-label d p param-b* | proxy-h param-label = QualifiedName (‘:’ QualifiedName)* start-node = done-node = terminate-node = fork-node = join-node = decision-node = Systems Modeling Language v2.0, Part 1 227 -merge-node = send-action-node = param-t* send-action-name-compartment param-l* param-r* send-action-expression param-b* send-action-name-compartment = '«' OccurrenceUsagePrefix 'send' 'action' '»' usage-name-with-alias send-action-expression = NodeParameterMember 'to' NodeParameterMember accept-action-node = param-t* accept-action-name-compartment param-l* param-r* accept-action-expression param-b* accept-action-name-compartment = '«' OccurrenceUsagePrefix 'accept' 'action' '»' usage-name-with-alias accept-action-expression = AcceptParameterPart while-loop-action-node = 228 Systems Modeling Language v2.0, Part 1 -param-t* while- loop-action-name- compartment while-condition? param-l* param-r* loop-body until-condition? compartment-stack param-b* while-condition = 'while condition' condition-expression until-condition = 'until condition' condition-expression while-loop-action-name-compartment = '«' OccurrenceUsagePrefix 'loop' '»' usage-name-with-alias for-loop-action-node = param-t* for-loop-action-name-compartment iteration param-r* param-l* loop-body compartment-stack param-b* iteration = 'for iterator' iteration-expression Systems Modeling Language v2.0, Part 1 229 -loop-body = 'loop body' action-body for-loop-action-name-compartment = '«' OccurrenceUsagePrefix 'loop' '»' usage-name-with-alias if-else-action-node = param-t* ifelse-action-name-compartment if-condition then-body param-r* param-l* else-body? compartment-stack param-b* if-condition = 'if condition' condition-expression then-body = 'then body' action-body else-body = 'else body' action-body ifelse-action-name-compartment = '«' OccurrenceUsagePrefix 'if' '»' usage-name-with-alias action-body = action-body-textual | action-flow-view condition-expression = ExpressionParameterMember iteration-expression = ForVariableDeclarationMember 'in' NodeParameterMember 230 Systems Modeling Language v2.0, Part 1 -action-body-textual = ActionBodyParameterMember assign-action-node = param-t* assign-action-name-compartment param-l* param-r* assign-action-expression param-b* assign-action-name-compartment = '«' OccurrenceUsagePrefix 'assign' '»' usage-name-with-alias perform-actions-swimlanes = (swimlane)* swimlane = usage-name- compartment &action-flow-node* parameter = param-l | param-r | param-t | param-b aflow-succession = Systems Modeling Language v2.0, Part 1 231 -guard-expression? &action-flow-node &action-flow-node else-branch = 'else' &decision-node &action-flow-node perform-edge = '«perform»' &action &performer-node performer-node = part | action | part-def | action-def | distinguished-parameter usage-edge = |succession perform-edge guard-expression = '[' OwnedExpression ']' Note. All swimlanes are attached to each other on vertical edges and aligned along the top and bottom horizontal edges. Note. The proxy option of a parameter production is valid only on an action usage contained within an action flow view. 8.2.3.18 States Graphical Notation definition-node =| state-def state-def = state-def-name-compartment state-entry-action state-do-action state-transition-view state-exit-action compartment-stack state-def-name-compartment = '«' DefinitionPrefix 'state' 'def' '»' definition-name-with-alias ('«' 'parallel' '»')? usage-node =| state-node | exhibit-state-usage state = 232 Systems Modeling Language v2.0, Part 1 -state-name-compartment state-entry-action state-do-action state-transition-view state-exit-action compartment-stack state-ref = state-name-compartment state-transition-view compartment-stack state-name-compartment = '«' OccurrenceUsagePrefix 'state' '»' usage-name-with-alias ('«' 'parallel' '»')? exhibit-state-usage = exhibit-state-name-compartment compartment-stack state-subaction-body = state-subaction-body-textual | action-flow-view state-subaction-body-textual = state-subaction-declaration? ( '{' ActionBodyItem* '}' )? state-subaction-declaration = PerformActionUsageDeclaration | AcceptNodeDeclaration | SendNodeDeclaration | AssignmentNodeDeclaration state-do-action = 'do' state-subaction-body state-entry-action = Systems Modeling Language v2.0, Part 1 233 -'entry' state-subaction-body state-exit-action = 'exit' state-subaction-body entry-action = | param-t* entry-action-name-comp param-l* param-r* state-subaction-body param-b* entry-action-name-comp = '«' 'entry' OccurrenceUsagePrefix 'action' '»' usage-name-with-alias exit-action = param-t* exit-action-name-comp param-l* param-r* state-subaction-body param-b* exit-action-name-comp = '«' 'exit' OccurrenceUsagePrefix 'action' '»' usage-name-with-alias do-action = param-t* do-action-name-comp param-l* param-r* state-subaction-body param-b* do-action-name-comp = '«' 'do' OccurrenceUsagePrefix 'action' '»' usage-name-with-alias 234 Systems Modeling Language v2.0, Part 1 -exhibit-state-name-compartment = '«exhibit-state»' state-name-compartment compartment =| states-compartment | states-actions-compartment | exhibit-states-compartment | successions-compartment | state-transition-compartment states-compartment = 'states' states-compartment-contents states-compartment-contents = (states-compartment-element)* '…'? states-compartment-element = el-prefix? OccurrencePrefix ActionUsageDeclaration state-actions-compartment = 'state actions' state-actions-compartment-contents state-actions-compartment-contents = (state-actions-compartment-element)* '…'? state-actions-compartment-element = el-prefix? EntryActionMember | DoActionMember | ExitActionMember exhibit-states-compartment = 'exhibit states' exhibit-states-compartment-contents exhibit-states-compartment-contents = exhibit-state-scompartment-element* '…'? exhibit-states-compartment-element-compartment = UsageDeclaration successions-compartment = 'successions' successions-compartment-contents successions-compartment-contents = QualifiedName* '…'? state-transition-compartment = 'state transition' state-transition-view state-transition-view = (state-transition-element)* (dependencies-and-annotations-element)* state-transition-element = state-transition-node | transition Systems Modeling Language v2.0, Part 1 235 -| st-succession state-transition-node = state-node | state-ref-node | start-node | entry-action | do-action | exit-action | done-node | fork-node | join-node | decision-node | merge-node | terminate-node | action | perform-action-usage | action-ref transition = transition-label &state-source &state-transition-node | guard-expression &decision-node &state-transition-node state-source = state-node | state-ref-node transition-label = trigger-expression '/' ActionUsage trigger-expression = AcceptParameterPart (guard-expression)? st-succession = &state-transition-node &state-transition-node | &state-transition-node &state-transition-node exhibit-edge = '«exhibit»' &exhibitor &state exhibitor = part | part-def general-relationship |= exhibit-edge usage-edge = |transition | st-succession | exhibit-edge 8.2.3.19 Calculations Graphical Notation definition-node =| calc-def calc-def = 236 Systems Modeling Language v2.0, Part 1 -param-t* calc-def-name-compartment param-l* param-r* action-flow-view compartment-stack param-b* calc-def-name-compartment = '«' DefinitionPrefix 'calc' 'def' '»' definition-name-with-alias usage-node =| calc calc = param-t* calc-name-compartment param-l* param-r* action-flow-view compartment-stack param-b* calc-name-compartment = occurrence-name-prefix '«' 'ref'? keyword* 'calc' '»' definition-name-with-alias calc-name-compartment = '«' OccurrenceUsagePrefix 'calc' '»' usage-name-with-alias action-flow-element =| calc-def | calc compartment =| calcs-compartment | result-compartment calcs-compartment = 'calcs' calcs-compartment-contents calcs-compartment-contents = calcs-compartment-element* '…'? calcs-compartment-element = el-prefix? OccurrenceUsagePrefix ActionUsageDeclaration Systems Modeling Language v2.0, Part 1 237 -result-compartment = 'result' result-compartment-contents result-compartment-contents = OwnedExpression 8.2.3.20 Constraints Graphical Notation definition-node =| constraint-def constraint-def = param-t* constraint-def-name-compartment param-l* param-r* general-view compartment-stack param-b* constraint-def-name-compartment = '«' DefinitionPrefix 'constraint' 'def' '»' definition-name-with-alias usage-node = constraint | assert-constraint-usage constraint = param-t* constraint-name-compartment param-l* param-r* general-view compartment-stack param-b* constraint-ref = 238 Systems Modeling Language v2.0, Part 1 -param-t* constraint-name-compartment param-l* param-r* general-view compartment-stack param-b* constraint-name-compartment = '«' OccurrenceUsagePrefix 'constraint' '»' usage-name-with-alias assert-constraint-node = assert-constraint-name-compartment compartment-stack assert-constraint-name-compartment = '«assert constraint»' constraint-name-compartment assume-constraint-node = assume-constraint-name-compartment compartment-stack assume-constraint-name-compartment = '«' OccurrenceUsagePrefix 'assume' 'constraint' '»' usage-name-with-alias usage-node =| assume-constraint-node assert-constraint-node< assume-edge = '«assume»' &assumer &constraint assumer = requirement | requirement-def general-relationship |= assume-edge Systems Modeling Language v2.0, Part 1 239 -assert-edge = '«assert»' &assertor &constraint assertor = usage-node | definition-node general-relationship |= assert-edge compartment =| constraints-compartment | assert-constraints-compartment constraints-compartment = 'constraints' constraints-compartment-contents constraints-compartment-contents = (constraints-usage-compartment-element)* '…'? constraints-usage-compartment-element = el-prefix? OccurrenceUsagePrefix ConstraintUsageDeclaration CalculationBody* assert-constraints-compartment = 'assert constraints' assert-constraints-compartment-contents assert-constraints-compartment-contents = (assert-constraints-compartment-element)* '…'? assert-constraints-compartment-element = el-prefix? OccurrenceUsagePrefix ( 'not' )? ( OwnedSubsetting FeatureSpecializationPart? | UsageDeclaration ) CalculationUsageParameterPart CalculationBody interconnection-element =| constraint-ref | constraint 8.2.3.21 Requirements Graphical Notation definition-node =| requirement-def | concern-def requirement-def = param-t* requirement-def-name-compartment param-l* param-r* general-view compartment-stack param-b* 240 Systems Modeling Language v2.0, Part 1 -requirement-def-name-compartment = '«' DefinitionPrefix 'requirement' 'def' '»' definition-name-with-alias usage-node = requirement | satisfy-requirement-usage | concern requirement = param-t* requirement-name-compartment param-l* param-r* general-view compartment-stack param-b* requirement-ref = param-t* requirement-name-compartment param-l* param-r* general-view compartment-stack param-b* requirement-name-compartment = '«' OccurrenceUsagePrefix 'requirement' '»' usage-name-with-alias satisfy-requirement-usage = satisfy-requirement-name-compartment compartment-stack satisfy-requirement-name-compartment = '«satisfy requirement»' requirement-name-compartment Systems Modeling Language v2.0, Part 1 241 -concern-def = concern-def-name-compartment compartment-stack concern-def-name-compartment = '«' DefinitionPrefix 'concern' 'def' '»' definition-name-with-alias concern = concern-name-compartment compartment-stack concern-name-compartment = '«' OccurrenceUsagePrefix 'concern' '»' usage-name-with-alias compartment =| constraints-compartment | assert-constraints-compartment compartment =| requirements-compartment | require-constraints-compartment | assume-constraints-compartment | satisfy-requirements-compartment | satisfies-compartment | actors-compartment | subject-compartment | stakeholders-compartment | frames-compartment requirements-compartment = 'requirements' requirements-compartment-contents requirements-compartment-contents = (requirements-compartment-element)* '…'? requirements-compartment-element = OccurrenceUsagePrefix ConstraintUsageDeclaration require-constraints-compartment = 'require constraints' require-constraints-compartment-contents require-constraints-compartment-contents = require-constraint-element* '…'? require-constraint-element = 242 Systems Modeling Language v2.0, Part 1 -el-prefix? requireMemberPrefix? RequirementConstraintUsage assume-constraints-compartment = 'assume constraints' assume-constraints-compartment-contents assume-constraints-compartment-contents = require-constraint-element* '…'? satisfy-requirements-compartment = 'satify requirements' satisfy-requirements-compartment-contents satisfy-requirements-compartment-contents = text-block satisfies-compartment = 'satisfies' satisfies-compartment-contents satisfies-compartment-contents = UsageDeclaration* '…'? actors-compartment = 'actors' actors-compartment-contents actors-compartment-contents = (actors-compartment-element)* '…'? actors-compartment-element = el-prefix? MemberPrefix usage-cp subject-compartment = 'subject' subject-compartment-contents subject-compartment-contents = (subject-compartment-element)* '…'? subject-compartment-element = el-prefix? MemberPrefix usage-cp stakeholders-compartment = 'stakeholders' stakeholders-compartment-contents stakeholders-compartment-contents = (stakeholders-compartment-element)* '…'? stakeholders-compartment-element = el-prefix? MemberPrefix usage-cp frames-compartment = 'frames' frames-compartment-contents frames-compartment-contents = (frames-compartment-element)* '…'? frames-compartment-element = el-prefix* MemberPrefix? FramedConcernUsage Systems Modeling Language v2.0, Part 1 243 -concerns-compartment = 'concerns' concerns-compartment-contents interconnection-element =| requirement-ref | requirement | concern | distinguished-parameter | distinguished-parameter-link | concern-stakeholder-link general-relationship =| frame-relationship subject-actors-stakeholders-node =| requirement distinguished-parameter = subject | actor | stakeholder subject = «subject» subject-name actor = actor-name | «actor» actor-name stakeholder = 244 Systems Modeling Language v2.0, Part 1 -«stakeholder» stakeholder-name subject-name = UsageDeclaration actor-name = UsageDeclaration stakeholder-name = UsageDeclaration distinguished-parameter-link = &subject-actors-stakeholders-node &distinguished-parameter frame-relationship = '«frame»' &framer &concern concern-stakeholder-link = &concern &stakeholder-node satisfy-edge = '«satisfy»' &satisfier &requirement satisfier = usage-node | definition-node general-relationship |= satisfy-edge require-edge = '«require»' &requirer &requirement requirer = usage-node | definition-node general-relationship |= require-edge require-constraint-node = require-constraint-name-compartment compartment-stack Systems Modeling Language v2.0, Part 1 245 -require-constraint-name-compartment = '«' OccurrenceUsagePrefix 'require' 'constraint' '»' usage-name-with-alias usage-node |= require-constraint-node frame-concern-node = frame-concern-name-compartment compartment-stack frame-concern-name-compartment = '«' OccurrenceUsagePrefix 'frame' 'concern' '»' usage-name-with-alias usage-node |= frame-concern-node frame-edge = '«frame»' &framer &concern framer = requirement | requirement-def | viewpoint | viewpoint-def general-relationship |= frame-edge 8.2.3.22 Cases Graphical Notation compartment =| objective-compartment objective-compartment = 'objective' objective-compartment-contents objective-compartment-contents = (objective-compartment-element)* '…'? objective-compartment-element = comp-prefix? MemberPrefix ConstraintUsageDeclaration RequirementBody 8.2.3.23 Analysis Cases Graphical Notation definition-node =| analysis-def analysis-def = 246 Systems Modeling Language v2.0, Part 1 -param-t* analysis-def-name-compartment param-l* param-r* action-flow-view compartment-stack param-b* analysis-def-name-compartment = '«' DefinitionPrefix 'analysis' 'def' '»' definition-name-with-alias usage-node =| analysis analysis = param-t* analysis-name-compartment param-l* param-r* action-flow-view compartment-stack param-b* analysis-name-compartment = '«' OccurrenceUsagePrefix 'analysis' '»' usage-name-with-alias compartment =| analyses-compartment analyses-compartment = 'analyses' analyses-compartment-contents analyses-compartment-contents = analyses-compartment-element* '…'? analyses-compartment-element = el-prefix? OccurrenceUsagePrefix ConstraintUsageDeclaration CaseBody action-flow-element =| analysis-def | analysis subject-actors-stakeholders-node =| analysis | analysis-def Systems Modeling Language v2.0, Part 1 247 -8.2.3.24 Verification Cases Graphical Notation definition-node =| verification-def verification-def = param-t* verification-def-name-compartment param-l* param-r* action-flow-view compartment-stack param-b* verification-def-name-compartment = '«' DefinitionPrefix 'verification' 'def' '»' definition-name-with-alias usage-node =| verification verification = param-t* verification-name-compartment param-l* param-r* action-flow-view compartment-stack param-b* verification-name-compartment = '«' OccurrenceUsagePrefix 'verification' '»' usage-name-with-alias verify-requirement-node = verify-requirement-name-compartment compartment-stack 248 Systems Modeling Language v2.0, Part 1 -verify-requirement-name-compartment = '«' OccurrenceUsagePrefix 'verify' 'requirement' '»' usage-name-with-alias usage-node |= verify-requirement-node compartment =| verifications-compartment | verifies-compartment | verification-methods-compartment verifications-compartment = 'verifications' verifications-compartment-contents verifications-compartment-contents = (verifications-compartment-element)* '…'? verifications-compartment-element = el-prefix? OccurrenceUsagePrefix ConstraintUsageDeclaration CaseBody '…' verifies-compartment = 'verifies' verifies-compartment-contents verifies-compartment-contents = (verifies-compartment-element)* '…'? verifies-compartment-element = el-prefix? MemberPrefix RequirementVerificationUsage '…' verification-methods-compartment = 'verification methods' verification-methods-compartment-contents verification-methods-compartment-contents = (verification-methods-compartment-element)* '…'? verification-methods-compartment-element = MetadataBody action-flow-element =| verification-def | verification general-relationship =| verify-relationship verify-relationship = '«verify»' &verification-case &requirement subject-actors-stakeholders-node =| verification | verification-def 8.2.3.25 Use Cases Graphical Notation definition-node =| use-case-def use-case-def = Systems Modeling Language v2.0, Part 1 249 -param-t* use-case-def-name-compartment param-l* param-r* action-flow-view compartment-stack param-b* use-case-def-name-compartment = '«' DefinitionPrefix 'use' 'case' 'def' '»' definition-name-with-alias usage-node =| use-case | include-use-case-usage use-case = param-t* use-case-name-compartment param-l* param-r* action-flow-view compartment-stack param-b* use-case-name-compartment = '«' OccurrenceUsagePrefix 'use' 'case' '»' usage-name-with-alias include-use-case-usage = include-use-case-name-compartment compartment-stack include-use-case-name-compartment = '«include use case»' requirement-name-compartment 250 Systems Modeling Language v2.0, Part 1 -compartment =| use-cases-compartment | include-actions-compartment | includes-compartment use-cases-compartment = 'use cases' use-cases-compartment-contents use-cases-compartment-contents = use-cases-compartment-element* '…'? use-cases-compartment-element = el-prefix? OccurrenceUsagePrefix ConstraintUsageDeclaration include-use-cases-compartment = 'include use cases' include-use-cases-compartment-contents include-use-cases-compartment-contents = (include-use-cases-compartment-element* '…'? include-use-cases-compartment-element = el-prefix? OccurrenceUsagePrefix ( OwnedSubsetting FeatureSpecializationPart? | UsageDeclaration ) ( ValuePart | ActionUsageParameterList )? CaseBody includes-compartment = 'includes' includes-compartment-contents includes-compartment-contents = (includes-compartment-element)* '…'? includes-compartment-element = el-prefix? OccurrenceUsagePrefix ( OwnedSubsetting FeatureSpecializationPart? | UsageDeclaration ) action-flow-element =| use-case-def | use-case general-relationship =| include-use-case-relationship include-use-case-relationship = '«include»' &use-case &use-case subject-actors-stakeholders-node =| use-case | use-case-def 8.2.3.26 Views and Viewpoints Graphical Notation root-view = framed-view< definition-node =| viewpoint-def | view-def viewpoint-def = Systems Modeling Language v2.0, Part 1 251 -viewpoint-def-name-compartment compartment-stack viewpoint-def-name-compartment = '«' DefinitionPrefix 'viewpoint' 'def' '»' definition-name-with-alias view-def = view-def-name-compartment compartment-stack view-def-name-compartment = '«' DefinitionPrefix 'view' 'def' '»' definition-name-with-alias usage-node |= viewpoint | view | framed-view viewpoint = viewpoint-name-compartment compartment-stack viewpoint-name-compartment = '«' OccurrenceUsagePrefix 'viewpoint' '»' usage-name-with-alias view = view-name-compartment compartment-stack view-name-compartment = '«' OccurrenceUsagePrefix 'view' '»' usage-name-with-alias compartment =| | views-compartment | viewpoints-compartment | exposes-compartment 252 Systems Modeling Language v2.0, Part 1 -| filters-compartment | rendering-compartment views-compartment = 'views' views-compartment-contents views-compartment-contents = (views-compartment-element)* '…' views-compartment-element = el-prefix? OccurrenceUsagePrefix UsageDeclaration? ValueOrFlowPart? ViewBody viewpoints-compartment = 'viewpoints' viewpoints-compartment-contents viewpoints-compartment-contents = (viewpoints-compartment-element)* '…'? viewpoints-compartment-element = el-prefix? OccurrenceUsagePrefix ConstraintUsageDeclaration RequirementBody exposes-compartment = 'exposes' exposes-compartment-contents exposes-compartment-contents = exposes-compartment-element* '…'? exposes-compartment-element = MembershipExpose | NamespaceExpose filters-compartment = 'filters' filters-compartment-contents filters-compartment-contents = (filters-compartment-element)* '…'? filters-compartment-element = el-prefix? MemberPrefix OwnedExpression rendering-compartment = 'rendering' rendering-compartment-contents rendering-compartment-contents = usage-cp* '…'? interconnection-element =| viewpoint-def | viewpoint | view-def | view framed-view = Systems Modeling Language v2.0, Part 1 253 -view-frame-info-compartment-tr? view-frame-name-compartment frameless-view view-frame-info-compartment-bl? view-frame-info-compartment-br? frameless-view = general-view | interconnection-view | action-flow-view | state-transition-view | sequence-view view-frame-name-compartment = '«view»' QualifiedName (':' QualifiedName)? view-frame-info-contents = Expose? ElementFilterMember? AnnotatingElement* view-frame-info-compartment-tr = view-frame-info-contents view-frame-info-compartment-bl = view-frame-info-contents view-frame-info-compartment-br = view-frame-info-contents general-relationship =| expose-relationship expose-relationship = expose-r | toplevel-expose-r | recursive-expose-r expose-r = '«' 'expose' '»' &view &element 254 Systems Modeling Language v2.0, Part 1 -toplevel-expose-r = '«' 'expose' '»*' &view &element recursive-expose-r = '«' 'expose' '»**' &view &element Note. The view frame info compartments are optional elements. The AnnotatingElement* enables adding any relevant supporting information related to a view, possibly using a configurable rendering. Note. A model library in Section 9.2.18 defines standard graphical view definitions for SysML. These may be supplemented by further, customized view definitions specific to a model. 8.2.3.27 Metadata Graphical Notation annotation-node =| metadata-feature-annotation-node metadata-feature-annotation-node = '«metadata»' metadata-feature-decl metadata-feature-name-value-list metadata-feature-decl = Identifier metadata-feature-name-value-list = ( metadata-feature-name '=' expression-text )* metadata-feature-name = Identifier expression-text = text-block metadata-def = metadata-def-name-compartment compartment-stack metadata-def-name-compartment = basic-name-prefix '«' keyword* 'metadata' 'def' '»' definition-name-with-alias 8.3 Abstract Syntax 8.3.1 Abstract Syntax Overview The abstract syntax is the common underlying syntactic representation for SysML models. The SysML textual or graphical notations (see 8.2 ) provide for concrete presentation of models in the abstract syntax presentation. This Systems Modeling Language v2.0, Part 1 255 -concrete syntax notation may also be parsed to create or update the abstract syntax representation of models. The semantics for SysML models are then formally defined on the abstract syntax representation (see 8.4 ). The SysML abstract syntax is specified as a MOF model [MOF] that is an extension of the KerML abstract syntax model [KerML]. Each of the subsequent abstract subclauses describes one package in the abstract syntax model, including one or more overview diagrams and descriptions of each of the elements in the package. In the diagrams, metaclasses and relationships from the KerML abstract syntax are shown in gray. See [KerML] for the description of these elements. The MOF-compliant class model for the abstract syntax defines the basic structural representation for any SysML model. In addition to this basic structure, the abstract syntax also includes constraints defined on various metaclasses. A conformant tool shall be able to accept any KerML model that conforms to the structural abstract syntax class model, and it may then additionally report on and/or enforce the constraints on a model so represented (as further described below). The SysML abstract syntax model follows the conventions from [KerML, 8.3.1] on three kinds of constraints: 1. Derivation constraints. These constraints specify how the values of the derived properties of a metaclass are computed from the values of other properties in the abstract syntax model. A tool conformant to the SysML abstract syntax shall always enforce derivation constraints. However, the computed values of derived properties may depend on whether implied relationships are included in the model or not (see below). A derivation constraint has a name starting with the word derive , followed by the name of the metaclass it constrains, followed by the name of the derived property it is for. The OCL specification of such a constraint always has the form of an equality, with the derived property on the left-hand side and the derivation expression on the right-hand side. For example, the derivation constraint for the derived propertyUsage::isReference is called deriveUsageIsReference and has the OCL specification isReference = not isComposite . Note. Derivation constraints are not included for derived properties in the following cases: ◦ The derived property subsets a property with multiplicity upper bound 1. In this case, if the derived property has a value, it must be the same as that of the subsetted property. ◦ The derived property redefines another derived property. In this case, the derivation of the redefined property also applies to the redefining property, though the redefining property will generally place additional constraints on type and/or multiplicity. 2. Semantic constraints. These constraints specify relationships that are semantically required in a SysML model (see 8.4.1 ), particularly relationships with elements in the Kernel Semantic Library (see [KerML, 9.2]) and Systems Model Library (see 9.2 ). These constraints may be violated by a model as entered by a user or as interchanged. In this case, a tool may satisfy the constraints by introducing implied relationships into the model, it may simply report their violation, or it may ignore the violations. Semantic constraints have names that start with the word check , followed by the name of the constrained metaclass, followed by a descriptive word or phrase. For example, checkPartDefinitionSpecialization . 3. Validation constraints. These constraints specify additional syntactic conditions that must be satisfied in order to give a model a proper semantic interpretation. They are written presuming that all semantic constraints are satisfied. A valid model is a model that satisfies all validation constraints. A tool conformant to the SysML abstract syntax should report violations of validation constraints. A tool conformant to the SysML semantics is only required to operate on valid models. Validation constraints have names that start with the word validate , followed by the name of the metaclass, followed by a descriptive word or phrase. For example, validateUsageOwningType . 256 Systems Modeling Language v2.0, Part 1 -8.3.2 Elements and Relationships Abstract Syntax {ordered} +/ownedElement 0..* +/owner 0..1 Element +target +elementId : String{id} +ownedRelatedElement 0..* +aliasIds : String [0..*]{ordered} {subsets relatedElement, 0..* +declaredShortName : String [0..1] ordered} {subsets relatedElement, +declaredName : String [0..1] +source ordered} +/shortName : String [0..1] 0..* +/name : String [0..1] {subsets relatedElement, +/qualifiedName : String [0..1] +owningRelatedElement ordered} +isImpliedIncluded : Boolean = false 0..1 +/isLibraryElement : Boolean +/relatedElement {subsets +escapedName() : String [0..1] 0..* relatedElement} +effectiveShortName() : String [0..1] {ordered, nonunique} +effectiveName() : String [0..1] +libraryNamespace() : Namespace [0..1] +path() : String +/relationship Relationship 0..* +ownedRelationship +isImplied : Boolean = false {union, nonunique} 0..* +libraryNamespace() : Namespace [0..1]{redefines libraryNamespace} {subsets relationship, +sourceRelationship +path() : String{redefines path} ordered} 0..* +owningRelationship {subsets relationship} 0..1 +targetRelationship {subsets relationship} 0..* {subsets relationship} Figure 2. Elements It is a general design principle of the KerML abstract syntax that non- Relationship Elements are related only by reified instances of Relationships . All other meta-associations between Elements are derived from these reified Relationships . For example, the owningRelatedElement / ownedRelationship meta-association between an Element and a Relationship is fundamental to establishing the structure of a model. However, the owner / ownedElement meta-association between two Elements is derived, based on the Relationship structure between them. Systems Modeling Language v2.0, Part 1 257 -8.3.3 Dependencies Abstract Syntax +client +supplier Element 1..* 1..* {redefines source, {redefines ordered} target, ordered} Relationship +clientDependency +supplierDependency Dependency 0..* 0..* {subsets sourceRelationship} {subsets targetRelationship} Figure 3. Dependencies 8.3.4 Annotations Abstract Syntax +/representedElement Element +/documentedElement 1 {subsets owner, redefines annotatedElement} 1 +/owningAnnotatedElement {subsets owner, redefines annotatedElement} 0..1 +/annotatedElement {subsets annotatedElement, subsets owningRelatedElement} 1..* +annotatedElement {subsets annotation, {ordered} subsets 1 ownedRelationship, {subsets targetRelationship, {redefines target} ordered} ordered} +annotation 0..* 0..* +/ownedAnnotation +/annotatingElement +/annotation AnnotatingElement Annotation 1 0..* +/annotatingElement {redefines source} {subsets sourceRelationship, 0..* ordered} {ordered} +/ownedAnnotatingElement +/owningAnnotatingRelationship 0..1 0..1 {subsets annotatingElement, {subsets annotation, subsets ownedRelatedElement} subsets owningRelationship} +/owningAnnotatingElement +/ownedAnnotatingRelationship 0..1 0..* {subsets annotatingElement, {subsets annotation, subsets owningRelatedElement} subsets ownedRelationship, ordered} Relationship Comment TextualRepresentation +/textualRepresentation +locale : String [0..1] +language : String [1] 0..* +body : String [1] +body : String [1] {subsets annotatingElement, subsets ownedElement, ordered} +/documentation Documentation 0..* {subsets annotatingElement, subsets ownedElement, ordered} Figure 4. Annotation 258 Systems Modeling Language v2.0, Part 1 -8.3.5 Namespaces and Packages Abstract Syntax +/ownedMemberElement Element 1 {subsets ownedRelatedElement, redefines memberElement} +memberElement 1 {redefines target} +/ownedMember 0..* 0..* +/member {subsets member, ordered} {ordered} {subsets namespace} 0..1 0..* +/owningNamespace +/namespace Namespace +namesOf( element : Element ) : String [0..*] +visibilityOf( mem : Membership ) : VisibilityKind +visibleMemberships( excluded : Namespace [0..*], isRecursive : Boolean, includeAll : Boolean ) : Membership [0..*] +importedMemberships( excluded : Namespace [0..*] ) : Membership [0..*] +membershipsOfVisibility( visibility : VisibilityKind [0..1], excluded : Namespace [0..*] ) : Membership [0..*] +resolve( qualifiedName : String ) : Membership [0..1] +resolveGlobal( qualifiedName : String ) : Membership [0..1] +resolveLocal( name : String ) : Membership [0..1] +resolveVisible( name : String ) : Membership [0..1] +qualificationOf( qualifiedName : String ) : String [0..1] +unqualifiedNameOf( qualifiedName : String ) : String 1..* +/membershipNamespace +/membershipOwningNamespace +/importingNamespace 0..* 1 {union} {subsets membershipNamespace, {subsets subsets owningRelatedElement, membershipNamespace} «enumeration» redefines source} VisibilityKind {subsets membership, subsets private {subsets membership, ownedRelationship, subsets protected ordered} sourceRelationship, ordered} public {union, ordered} +/importedMembership 0..* 0..* 0..* +/ownedMembership +/membership Membership +/memberElementId : String +memberShortName : String [0..1] +membership Relationship +memberName : String [0..1] 0..* +visibility : VisibilityKind = public {subsets targetRelationship} +isDistinguishableFrom( other : Membership ) : Boolean OwningMembership +/ownedMemberElementId : String{redefines memberElementId} +/owningMembership +/ownedMemberShortName : String [0..1]{redefines memberShortName} 0..1 +/ownedMemberName : String [0..1]{redefines memberName} {subsets membership, +path() : String{redefines path} subsets owningRelationship} Figure 5. Namespaces Systems Modeling Language v2.0, Part 1 259 -Relationship Import +visibility : VisibilityKind = private +/ownedImport +/importOwningNamespace +/importedElement +/membershipImport +isRecursive : Boolean = false Namespace Element 0..* 1 +isImportAll : Boolean = false 1 0..* {subsets ownedRelationship, {subsets owningRelatedElement, +importedMemberships( excluded : Namespace [0..*] ) : Membership [0..*] +memberElement 1 1 +importedNamespace subsets sourceRelationship, redefines source} {redefines target} {redefines target} ordered} +import MembershipImport NamespaceImport 0..* +importedMemberships( excluded : Namespace [0..*] ) : Membership [0..*]{redefines importedMemberships} +importedMemberships( excluded : Namespace [0..*] ) : Membership [0..*]{redefines importedMemberships} {subsets targetRelationship} +import 0..* {redefines targetRelationship} {redefines target} +importedMembership 1 +membership Membership 0..* {subsets targetRelationship} Figure 6. Imports Namespace OwningMembership Package +importedMemberships( excluded : Namespace [0..*] ) : Membership [0..*]{redefines importedMemberships} ElementFilterMembership +includeAsMember( element : Element ) : Boolean +/conditionedPackage 0..1 +/owningFilter 0..1 {subsets owningNamespace} {subsets owningMembership} {redefines ownedMemberElement} +/condition 1 LibraryPackage +/filterCondition +isStandard : Boolean = false Expression 0..* +libraryNamespace() : Namespace [0..1]{redefines libraryNamespace} {subsets ownedMember, ordered} Figure 7. Packages 260 Systems Modeling Language v2.0, Part 1 -8.3.6 Definition and Usage Abstract Syntax 8.3.6.1 Overview +/definition Classifier Feature 0..* {redefines type, ordered} +/owningUsage +/definedUsage Definition Usage 0..1 0..* +isVariation : Boolean +/mayTimeVary : Boolean{redefines isVariable} {subsets owningType} {subsets typedFeature} +/isReference : Boolean +isVariation : Boolean +/owningDefinition +/ownedUsage +/nestedUsage +namingFeature() : Feature [0..1]{redefines namingFeature} 0..* 0..* 0..1 +referencedFeatureTarget() : Feature {subsets ownedFeature, {subsets ownedFeature, {subsets featuringDefinition, subsets usage, ordered} subsets usage, ordered} subsets owningType} /featuringUsage 0..* {subsets typeWithFeature} +/featuringDefinition +/usage 0..* 0..* +/usage {subsets typeWithFeature} {subsets feature, 0..* ordered} {subsets feature, ordered} /usageWithDirectedUsage 0..* +/directedUsage +/definitionWithDirectedUsage {subsets featuringUsage, subsets 0..* 0..* typeWithDirectedFeature} {subsets featuringDefinition, {subsets directedFeature, subsets typeWithDirectedFeature} subsets usage, ordered} +/directedUsage 0..* +/referenceOwningUsage 0..1 {subsets directedFeature, +/referenceOwningDefinition 0..1 {subsets owningUsage} subsets usage, ordered} {subsets owningDefinition} {subsets nestedUsage, ordered} +/nestedReference 0..* +/ownedReference ReferenceUsage 0..* +/isReference : Boolean = true{redefines isReference} {subsets ownedUsage, +namingFeature() : Feature [0..1]{redefines namingFeature} ordered} Figure 8. Definition and Usage +/owningVariationDefinition +/owningVariationDefinition OwningMembership Definition 0..1 0..1 {subsets {subsets membershipOwningNamespace} owningNamespace} +/variantMembership {subsets ownedMembership} {subsets ownedMember} 0..* +/variant 0..* +/variantMembership +/owningVariationUsage +/variant VariantMembership Usage 0..* 0..1 0..* {subsets ownedMembership} {subsets {subsets ownedMember} membershipOwningNamespace} +/ownedVariantUsage +/owningVariationUsage +/owningVariantMembership 0..1 1 0..1 {subsets owningMembership} {redefines ownedMemberElement} {subsets owningNamespace} Figure 9. Variant Membership 8.3.6.2 Definition Description A Definition is a Classifier of Usages . The actual kinds of Definition that may appear in a model are given by the subclasses of Definition (possibly as extended with user-defined SemanticMetadata ). Systems Modeling Language v2.0, Part 1 261 -Normally, a Definition has owned Usages that model features of the thing being defined. A Definition may also have other Definitions nested in it, but this has no semantic significance, other than the nested scoping resulting from the Definition being considered as a Namespace for any nested Definitions . However, if a Definition has isVariation = true , then it represents a variation point Definition . In this case, all of its members must be variant Usages , related to the Definition by VariantMembership Relationships . Rather than being features of the Definition , variant Usages model different concrete alternatives that can be chosen to fill in for an abstract Usage of the variation point Definition . General Classes Classifier Attributes /directedUsage : Usage [0..*] {subsets directedFeature, usage, ordered} The usages of this Definition that are directedFeatures . isVariation : Boolean Whether this Definition is for a variation point or not. If true, then all the memberships of the Definition must be VariantMemberships . /ownedAction : ActionUsage [0..*] {subsets ownedOccurrence, ordered} The ActionUsages that are ownedUsages of this Definition . /ownedAllocation : AllocationUsage [0..*] {subsets ownedConnection, ordered} The AllocationUsages that are ownedUsages of this Definition . /ownedAnalysisCase : AnalysisCaseUsage [0..*] {subsets ownedCase, ordered} The AnalysisCaseUsages that are ownedUsages of this Definition . /ownedAttribute : AttributeUsage [0..*] {subsets ownedUsage, ordered} The AttributeUsages that are ownedUsages of this Definition . /ownedCalculation : CalculationUsage [0..*] {subsets ownedAction, ordered} The CalculationUsages that are ownedUsages of this Definition . /ownedCase : CaseUsage [0..*] {subsets ownedCalculation, ordered} The code>CaseUsages that are ownedUsages of this Definition . /ownedConcern : ConcernUsage [0..*] {subsets ownedRequirement} The ConcernUsages that are ownedUsages of this Definition . /ownedConnection : ConnectorAsUsage [0..*] {subsets ownedUsage, ordered} 262 Systems Modeling Language v2.0, Part 1 -The ConnectorAsUsages that are ownedUsages of this Definition . Note that this list includes BindingConnectorAsUsages , SuccessionAsUsages , and FlowUsages because these are ConnectorAsUsages even though they are not ConnectionUsages . /ownedConstraint : ConstraintUsage [0..*] {subsets ownedOccurrence, ordered} The ConstraintUsages that are ownedUsages of this Definition . /ownedEnumeration : EnumerationUsage [0..*] {subsets ownedAttribute, ordered} The EnumerationUsages that are ownedUsages of this Definition . /ownedFlow : FlowUsage [0..*] {subsets ownedConnection} The FlowUsages that are ownedUsages of this Definition . /ownedInterface : InterfaceUsage [0..*] {subsets ownedConnection, ordered} The InterfaceUsages that are ownedUsages of this Definition . /ownedItem : ItemUsage [0..*] {subsets ownedOccurrence, ordered} The ItemUsages that are ownedUsages of this Definition . /ownedMetadata : MetadataUsage [0..*] {subsets ownedItem, ordered} The MetadataUsages that are ownedUsages of this Definition . /ownedOccurrence : OccurrenceUsage [0..*] {subsets ownedUsage, ordered} The OccurrenceUsages that are ownedUsages of this Definition . /ownedPart : PartUsage [0..*] {subsets ownedItem, ordered} The PartUsages that are ownedUsages of this Definition . /ownedPort : PortUsage [0..*] {subsets ownedUsage, ordered} The PortUsages that are ownedUsages of this Definition . /ownedReference : ReferenceUsage [0..*] {subsets ownedUsage, ordered} The ReferenceUsages that are ownedUsages of this Definition . /ownedRendering : RenderingUsage [0..*] {subsets ownedPart, ordered} The RenderingUsages that are ownedUsages of this Definition . /ownedRequirement : RequirementUsage [0..*] {subsets ownedConstraint, ordered} The RequirementUsages that are ownedUsages of this Definition . /ownedState : StateUsage [0..*] {subsets ownedAction, ordered} The StateUsages that are ownedUsages of this Definition . Systems Modeling Language v2.0, Part 1 263 -/ownedTransition : TransitionUsage [0..*] {subsets ownedUsage} The TransitionUsages that are ownedUsages of this Definition . /ownedUsage : Usage [0..*] {subsets ownedFeature, usage, ordered} The Usages that are ownedFeatures of this Definition . /ownedUseCase : UseCaseUsage [0..*] {subsets ownedCase, ordered} The UseCaseUsages that are ownedUsages of this Definition . /ownedVerificationCase : VerificationCaseUsage [0..*] {subsets ownedCase, ordered} The VerificationCaseUsages that are ownedUsages of this Definition . /ownedView : ViewUsage [0..*] {subsets ownedPart, ordered} The ViewUsages that are ownedUsages of this Definition . /ownedViewpoint : ViewpointUsage [0..*] {subsets ownedRequirement, ordered} The ViewpointUsages that are ownedUsages of this Definition . /usage : Usage [0..*] {subsets feature, ordered} The Usages that are features of this Definition (not necessarily owned). /variant : Usage [0..*] {subsets ownedMember} The Usages which represent the variants of this Definition as a variation point Definition , if isVariation = true. If isVariation = false , the there must be no variants . /variantMembership : VariantMembership [0..*] {subsets ownedMembership} The ownedMemberships of this Definition that are VariantMemberships . If isVariation = true, then this must be all ownedMemberships of the Definition . If isVariation = false, then variantMembership must be empty. Operations None. Constraints deriveDefinitionDirectedUsage The directedUsages of a Definition are all its directedFeatures that are Usages . directedUsage = directedFeature->selectByKind(Usage) deriveDefinitionOwnedAction The ownedActions of a Definition are all its ownedUsages that are ActionUsages . ownedAction = ownedUsage->selectByKind(ActionUsage) 264 Systems Modeling Language v2.0, Part 1 -deriveDefinitionOwnedAllocation The ownedAllocations of a Definition are all its ownedUsages that are AllocationUsages . ownedAllocation = ownedUsage->selectByKind(AllocationUsage) deriveDefinitionOwnedAnalysisCase The ownedAnalysisCases of a Definition are all its ownedUsages that are AnalysisCaseUsages . ownedAnalysisCase = ownedUsage->selectByKind(AnalysisCaseUsage) deriveDefinitionOwnedAttribute The ownedAttributes of a Definition are all its ownedUsages that are AttributeUsages . ownedAttribute = ownedUsage->selectByKind(AttributeUsage) deriveDefinitionOwnedCalculation The ownedCalculations of a Definition are all its ownedUsages that are CalculationUsages . ownedCalculation = ownedUsage->selectByKind(CalculationUsage) deriveDefinitionOwnedCase The ownedCases of a Definition are all its ownedUsages that are CaseUsages . ownedCase = ownedUsage->selectByKind(CaseUsage) deriveDefinitionOwnedConcern The ownedConcerns of a Definition are all its ownedUsages that are ConcernUsages . ownedConcern = ownedUsage->selectByKind(ConcernUsage) deriveDefinitionOwnedConnection The ownedConnections of a Definition are all its ownedUsages that are ConnectorAsUsages . ownedConnection = ownedUsage->selectByKind(ConnectorAsUsage) deriveDefinitionOwnedConstraint The ownedConstraints of a Definition are all its ownedUsages that are ConstraintUsages . ownedConstraint = ownedUsage->selectByKind(ConstraintUsage) deriveDefinitionOwnedEnumeration The ownedEnumerations of a Definition are all its ownedUsages that are EnumerationUsages . ownedEnumeration = ownedUsage->selectByKind(EnumerationUsage) deriveDefinitionOwnedFlow The ownedFlows of a Definition are all its ownedUsages that are FlowUsages . Systems Modeling Language v2.0, Part 1 265 -ownedFlow = ownedUsage->selectByKind(FlowConnectionUsage) deriveDefinitionOwnedInterface The ownedInterfaces of a Definition are all its ownedUsages that are InterfaceUsages . ownedInterface = ownedUsage->selectByKind(ReferenceUsage) deriveDefinitionOwnedItem The ownedItems of a Definition are all its ownedUsages that are ItemUsages . ownedItem = ownedUsage->selectByKind(ItemUsage) deriveDefinitionOwnedMetadata The ownedMetadata of a Definition are all its ownedUsages that are MetadataUsages . ownedMetadata = ownedUsage->selectByKind(MetadataUsage) deriveDefinitionOwnedOccurrence The ownedOccurrences of a Definition are all its ownedUsages that are OccurrenceUsages . ownedOccurrence = ownedUsage->selectByKind(OccurrenceUsage) deriveDefinitionOwnedPart The ownedParts of a Definition are all its ownedUsages that are PartUsages . ownedPart = ownedUsage->selectByKind(PartUsage) deriveDefinitionOwnedPort The ownedPorts of a Definition are all its ownedUsages that are PortUsages . ownedPort = ownedUsage->selectByKind(PortUsage) deriveDefinitionOwnedReference The ownedReferences of a Definition are all its ownedUsages that are ReferenceUsages . ownedReference = ownedUsage->selectByKind(ReferenceUsage) deriveDefinitionOwnedRendering The ownedRenderings of a Definition are all its ownedUsages that are RenderingUsages . ownedRendering = ownedUsage->selectByKind(RenderingUsage) deriveDefinitionOwnedRequirement The ownedRequirements of a Definition are all its ownedUsages that are RequirementUsages . ownedRequirement = ownedUsage->selectByKind(RequirementUsage) deriveDefinitionOwnedState 266 Systems Modeling Language v2.0, Part 1 -The ownedStates of a Definition are all its ownedUsages that are StateUsages . ownedState = ownedUsage->selectByKind(StateUsage) deriveDefinitionOwnedTransition The ownedTransitions of a Definition are all its ownedUsages that are TransitionUsages . ownedTransition = ownedUsage->selectByKind(TransitionUsage) deriveDefinitionOwnedUsage The ownedUsages of a Definition are all its ownedFeatures that are Usages . ownedUsage = ownedFeature->selectByKind(Usage) deriveDefinitionOwnedUseCase The ownedUseCases of a Definition are all its ownedUsages that are UseCaseUsages . ownedUseCase = ownedUsage->selectByKind(UseCaseUsage) deriveDefinitionOwnedVerificationCase The ownedValidationCases of a Definition are all its ownedUsages that are ValidationCaseUsages . ownedVerificationCase = ownedUsage->selectByKind(VerificationCaseUsage) deriveDefinitionOwnedView The ownedViews of a Definition are all its ownedUsages that are ViewUsages . ownedView = ownedUsage->selectByKind(ViewUsage) deriveDefinitionOwnedViewpoint The ownedViewpoints of a Definition are all its ownedUsages that are ViewpointUsages . ownedViewpoint = ownedUsage->selectByKind(ViewpointUsage) deriveDefinitionUsage The usages of a Definition are all its features that are Usages . usage = feature->selectByKind(Usage) deriveDefinitionVariant The variants of a Definition are the ownedVariantUsages of its variantMemberships . variant = variantMembership.ownedVariantUsage deriveDefinitionVariantMembership The variantMemberships of a Definition are those ownedMemberships that are VariantMemberships . variantMembership = ownedMembership->selectByKind(VariantMembership) Systems Modeling Language v2.0, Part 1 267 -validateDefinitionVariationIsAbstract If a Definition is a variation, then it must be abstract. isVariation implies isAbstract validateDefinitionVariationOwnedFeatureMembership If a Definition is a variation, then all it must not have any ownedFeatureMemberships . isVariation implies ownedFeatureMembership->isEmpty() validateDefinitionVariationSpecialization A variation Definition may not specialize any other variation Definition . isVariation implies not ownedSpecialization.specific->exists( oclIsKindOf(Definition) and oclAsType(Definition).isVariation) 8.3.6.3 ReferenceUsage Description A ReferenceUsage is a Usage that specifies a non-compositional ( isComposite = false ) reference to something. The definition of a ReferenceUsage can be any kind of Classifier , with the default being the top-level Classifier Base::Anything from the Kernel Semantic Library. This allows the specification of a generic reference without distinguishing if the thing referenced is an attribute value, item, action, etc. General Classes Usage Attributes /isReference : Boolean {redefines isReference} Always true for a ReferenceUsage . Operations namingFeature() : Feature [0..1] {redefines namingFeature} If this ReferenceUsage is the payload parameter of a TransitionUsage , then its naming Feature is the payloadParameter of the triggerAction of that TransitionUsage (if any). body: if owningType <> null and owningType.oclIsKindOf(TransitionUsage) and owningType.oclAsType(TransitionUsage).inputParameter(2) = self then owningType.oclAsType(TransitionUsage).triggerPayloadParameter() else self.oclAsType(Usage).namingFeature() endif Constraints validateReferenceUsageIsReference A ReferenceUsage is always referential. 268 Systems Modeling Language v2.0, Part 1 -isReference 8.3.6.4 Usage Description A Usage is a usage of a Definition . A Usage may have nestedUsages that model features that apply in the context of the owningUsage . A Usage may also have Definitions nested in it, but this has no semantic significance, other than the nested scoping resulting from the Usage being considered as a Namespace for any nested Definitions . However, if a Usage has isVariation = true , then it represents a variation point Usage . In this case, all of its members must be variant Usages , related to the Usage by VariantMembership Relationships . Rather than being features of the Usage , variant Usages model different concrete alternatives that can be chosen to fill in for the variation point Usage . General Classes Feature Attributes /definition : Classifier [0..*] {redefines type, ordered} The Classifiers that are the types of this Usage . Nominally, these are Definitions , but other kinds of Kernel Classifiers are also allowed, to permit use of Classifiers from the Kernel Model Libraries. /directedUsage : Usage [0..*] {subsets directedFeature, usage, ordered} The usages of this Usage that are directedFeatures . /isReference : Boolean Whether this Usage is a referential Usage , that is, it has isComposite = false . isVariation : Boolean Whether this Usage is for a variation point or not. If true, then all the memberships of the Usage must be VariantMemberships . /mayTimeVary : Boolean {redefines isVariable} Whether this Usage may be time varying (that is, whether it is featured by the snapshots of its owningType , rather than being featured by the owningType itself). However, if isConstant is also true, then the value of the Usage is nevertheless constant over the entire duration of an instance of its owningType (that is, it has the same value on all snapshots). The property mayTimeVary redefines the KerML property Feature::isVariable , making it derived. The property isConstant is inherited from Feature . /nestedAction : ActionUsage [0..*] {subsets nestedOccurrence, ordered} The ActionUsages that are nestedUsages of this Usage . /nestedAllocation : AllocationUsage [0..*] {subsets nestedConnection, ordered} Systems Modeling Language v2.0, Part 1 269 -The AllocationUsages that are nestedUsages of this Usage . /nestedAnalysisCase : AnalysisCaseUsage [0..*] {subsets nestedCase, ordered} The AnalysisCaseUsages that are nestedUsages of this Usage . /nestedAttribute : AttributeUsage [0..*] {subsets nestedUsage, ordered} The code>AttributeUsages that are nestedUsages of this Usage . /nestedCalculation : CalculationUsage [0..*] {subsets nestedAction, ordered} The CalculationUsage that are nestedUsages of this Usage . /nestedCase : CaseUsage [0..*] {subsets nestedCalculation, ordered} The CaseUsages that are nestedUsages of this Usage . /nestedConcern : ConcernUsage [0..*] {subsets nestedRequirement} The ConcernUsages that are nestedUsages of this Usage . /nestedConnection : ConnectorAsUsage [0..*] {subsets nestedUsage, ordered} The ConnectorAsUsages that are nestedUsages of this Usage . Note that this list includes BindingConnectorAsUsages , SuccessionAsUsages , and FlowConnectionUsages because these are ConnectorAsUsages even though they are not ConnectionUsages . /nestedConstraint : ConstraintUsage [0..*] {subsets nestedOccurrence, ordered} The ConstraintUsages that are nestedUsages of this Usage . /nestedEnumeration : EnumerationUsage [0..*] {subsets nestedAttribute, ordered} The code>EnumerationUsages that are nestedUsages of this Usage . /nestedFlow : FlowUsage [0..*] {subsets nestedConnection} The code>FlowUsages that are nestedUsages of this Usage . /nestedInterface : InterfaceUsage [0..*] {subsets nestedConnection, ordered} The InterfaceUsages that are nestedUsages of this Usage . /nestedItem : ItemUsage [0..*] {subsets nestedOccurrence, ordered} The ItemUsages that are nestedUsages of this Usage . /nestedMetadata : MetadataUsage [0..*] {subsets nestedItem, ordered} The MetadataUsages that are nestedUsages of this of this Usage . /nestedOccurrence : OccurrenceUsage [0..*] {subsets nestedUsage, ordered} The OccurrenceUsages that are nestedUsages of this Usage . 270 Systems Modeling Language v2.0, Part 1 -/nestedPart : PartUsage [0..*] {subsets nestedItem, ordered} The PartUsages that are nestedUsages of this Usage . /nestedPort : PortUsage [0..*] {subsets nestedUsage, ordered} The PortUsages that are nestedUsages of this Usage . /nestedReference : ReferenceUsage [0..*] {subsets nestedUsage, ordered} The ReferenceUsages that are nestedUsages of this Usage . /nestedRendering : RenderingUsage [0..*] {subsets nestedPart, ordered} The RenderingUsages that are nestedUsages of this Usage . /nestedRequirement : RequirementUsage [0..*] {subsets nestedConstraint, ordered} The RequirementUsages that are nestedUsages of this Usage . /nestedState : StateUsage [0..*] {subsets nestedAction, ordered} The StateUsages that are nestedUsages of this Usage . /nestedTransition : TransitionUsage [0..*] {subsets nestedUsage} The TransitionUsages that are nestedUsages of this Usage . /nestedUsage : Usage [0..*] {subsets ownedFeature, usage, ordered} The Usages that are ownedFeatures of this Usage . /nestedUseCase : UseCaseUsage [0..*] {subsets nestedCase, ordered} The UseCaseUsages that are nestedUsages of this Usage . /nestedVerificationCase : VerificationCaseUsage [0..*] {subsets nestedCase, ordered} The VerificationCaseUsages that are nestedUsages of this Usage . /nestedView : ViewUsage [0..*] {subsets nestedPart, ordered} The ViewUsages that are nestedUsages of this Usage . /nestedViewpoint : ViewpointUsage [0..*] {subsets nestedRequirement, ordered} The ViewpointUsages that are nestedUsages of this Usage . /owningDefinition : Definition [0..1] {subsets owningType, featuringDefinition} The Definition that owns this Usage (if any). /owningUsage : Usage [0..1] {subsets owningType} The Usage in which this Usage is nested (if any). Systems Modeling Language v2.0, Part 1 271 -/usage : Usage [0..*] {subsets feature, ordered} The Usages that are features of this Usage (not necessarily owned). /variant : Usage [0..*] {subsets ownedMember} The Usages which represent the variants of this Usage as a variation point Usage , if isVariation = true . If isVariation = false , then there must be no variants . /variantMembership : VariantMembership [0..*] {subsets ownedMembership} The ownedMemberships of this Usage that are VariantMemberships . If isVariation = true , then this must be all memberships of the Usage . If isVariation = false , then variantMembership must be empty. Operations namingFeature() : Feature [0..1] {redefines namingFeature} If this Usage is a variant, then its naming Feature is the referencedFeature of its ownedReferenceSubsetting . body: if not owningMembership.oclIsKindOf(VariantMembership) then self.oclAsType(Feature).namingFeature() else if ownedReferenceSubsetting = null then null else ownedReferenceSubsetting.referencedFeature endif endif referencedFeatureTarget() : Feature If ownedReferenceSubsetting is not null, return the featureTarget of the referencedFeature of the ownedReferenceSubsetting . body: if ownedReferenceSubsetting = null then null else ownedReferenceSubsetting.referencedFeature.featureTarget endif Constraints checkUsageVariationDefinitionSpecialization If a Usage has an owningVariationDefinition , then it must directly or indirectly specialize that Definition . owningVariationDefinition <> null implies specializes(owningVariationDefinition) checkUsageVariationUsageSpecialization If a Usage has an owningVariationUsage , then it must directly or indirectly specialize that Usage . owningVariationUsage <> null implies specializes(owningVariationUsage) checkUsageVariationUsageTypeFeaturing If a Usage has an owningVariationUsage , then it must have the same featuringTypes as that Usage . owningVariationUsage <> null implies featuringType->asSet() = owningVariationUsage.featuringType->asSet() 272 Systems Modeling Language v2.0, Part 1 -deriveUsageDirectedUsage The directedUsages of a Usage are all its directedFeatures that are Usages . directedUsage = directedFeature->selectByKind(Usage) deriveUsageIsReference A Usage is referential if it is not composite. isReference = not isComposite deriveUsageMayTimeVary A Usage mayTimeVary if and only if all of the following are true • It has an owningType that specializes Occurrences::Occurrence (from the Kernel Semantic Library). • It is not a portion. • It does not specialize Links::SelfLink or Occurrences::HappensLink (from the Kernel Semantic Library). • If isComposite = true , it does not specialize Actions::Action (from the Systems Model Library). mayTimeVary = owningType <> null and owningType.specializesFromLibrary('Occurrences::Occurrence') and not ( isPortion or specializesFromLibrary('Links::SelfLink') or specializesFromLibrary('Occurrences::HappensLink') or isComposite and specializesFromLibrary('Actions::Action') ) deriveUsageNestedAction The ownedActions of a Usage are all its ownedUsages that are ActionUsages . nestedAction = nestedUsage->selectByKind(ActionUsage) deriveUsageNestedAllocation The ownedAllocations of a Usage are all its ownedUsages that are AllocationUsages . nestedAllocation = nestedUsage->selectByKind(AllocationUsage) deriveUsageNestedAnalysisCase The ownedAnalysisCases of a Usage are all its ownedUsages that are AnalysisCaseUsages . nestedAnalysisCase = nestedUsage->selectByKind(AnalysisCaseUsage) deriveUsageNestedAttribute The ownedAttributes of a Usage are all its ownedUsages that are AttributeUsages . nestedAttribute = nestedUsage->selectByKind(AttributeUsage) deriveUsageNestedCalculation Systems Modeling Language v2.0, Part 1 273 -The ownedCalculations of a Usage are all its ownedUsages that are CalculationUsages . nestedCalculation = nestedUsage->selectByKind(CalculationUsage) deriveUsageNestedCase The ownedCases of a Usage are all its ownedUsages that are CaseUsages . nestedCase = nestedUsage->selectByKind(CaseUsage) deriveUsageNestedConcern The ownedConcerns of a Usage are all its ownedUsages that are ConcernUsages . nestedConcern = nestedUsage->selectByKind(ConcernUsage) deriveUsageNestedConnection The ownedConnections of a Usage are all its ownedUsages that are ConnectorAsUsages . nestedConnection = nestedUsage->selectByKind(ConnectorAsUsage) deriveUsageNestedConstraint The ownedConstraints of a Usage are all its ownedUsages that are ConstraintUsages . nestedConstraint = nestedUsage->selectByKind(ConstraintUsage) deriveUsageNestedEnumeration The ownedEnumerations of a Usage are all its ownedUsages that are EnumerationUsages . ownedNested = nestedUsage->selectByKind(EnumerationUsage) deriveUsageNestedFlow The ownedFlows of a Usage are all its ownedUsages that are FlowConnectionUsages . nestedFlow = nestedUsage->selectByKind(FlowConnectionUsage) deriveUsageNestedInterface The ownedInterfaces of a Usage are all its ownedUsages that are InterfaceUsages . nestedInterface = nestedUsage->selectByKind(ReferenceUsage) deriveUsageNestedItem The ownedItems of a Usage are all its ownedUsages that are ItemUsages . nestedItem = nestedUsage->selectByKind(ItemUsage) deriveUsageNestedMetadata The ownedMetadata of a Usage are all its ownedUsages that are MetadataUsages . nestedMetadata = nestedUsage->selectByKind(MetadataUsage) 274 Systems Modeling Language v2.0, Part 1 -deriveUsageNestedOccurrence The ownedOccurrences of a Usage are all its ownedUsages that are OccurrenceUsages . nestedOccurrence = nestedUsage->selectByKind(OccurrenceUsage) deriveUsageNestedPart The ownedParts of a Usage are all its ownedUsages that are PartUsages . nestedPart = nestedUsage->selectByKind(PartUsage) deriveUsageNestedPort The ownedPorts of a Usage are all its ownedUsages that are PortUsages . nestedPort = nestedUsage->selectByKind(PortUsage) deriveUsageNestedReference The ownedReferences of a Usage are all its ownedUsages that are ReferenceUsages . nestedReference = nestedUsage->selectByKind(ReferenceUsage) deriveUsageNestedRendering The ownedRenderings of a Usage are all its ownedUsages that are RenderingUsages . nestedRendering = nestedUsage->selectByKind(RenderingUsage) deriveUsageNestedRequirement The ownedRequirements of a Usage are all its ownedUsages that are RequirementUsages . nestedRequirement = nestedUsage->selectByKind(RequirementUsage) deriveUsageNestedState The ownedStates of a Usage are all its ownedUsages that are StateUsages . nestedState = nestedUsage->selectByKind(StateUsage) deriveUsageNestedTransition The ownedTransitions of a Usage are all its ownedUsages that are TransitionUsages . nestedTransition = nestedUsage->selectByKind(TransitionUsage) deriveUsageNestedUsage The ownedUsages of a Usage are all its ownedFeatures that are Usages . nestedUsage = ownedFeature->selectByKind(Usage) deriveUsageNestedUseCase The ownedUseCases of a Usage are all its ownedUsages that are UseCaseUsages . Systems Modeling Language v2.0, Part 1 275 -nestedUseCase = nestedUsage->selectByKind(UseCaseUsage) deriveUsageNestedVerificationCase The ownedValidationCases of a Usage are all its ownedUsages that are ValidationCaseUsages . nestedVerificationCase = nestedUsage->selectByKind(VerificationCaseUsage) deriveUsageNestedView The ownedViews of a Usage are all its ownedUsages that are ViewUsages . nestedView = nestedUsage->selectByKind(ViewUsage) deriveUsageNestedViewpoint The ownedViewpoints of a Usage are all its ownedUsages that are ViewpointUsages . nestedViewpoint = nestedUsage->selectByKind(ViewpointUsage) deriveUsageUsage The usages of a Usage are all its features that are Usages . usage = feature->selectByKind(Usage) deriveUsageVariant The variants of a Usage are the ownedVariantUsages of its variantMemberships . variant = variantMembership.ownedVariantUsage deriveUsageVariantMembership The variantMemberships of a Usage are those ownedMemberships that are VariantMemberships . variantMembership = ownedMembership->selectByKind(VariantMembership) validateUsageIsReferential A Usage that is directed, an end feature or has no featuringTypes must be referential. direction <> null or isEnd or featuringType->isEmpty() implies isReference validateUsageVariationIsAbstract If a Usage is a variation, then it must be abstract. isVariation implies isAbstract validateUsageVariationOwnedFeatureMembership If a Usage is a variation, then it must not have any ownedFeatureMemberships . isVariation implies ownedFeatureMembership->isEmpty() validateUsageVariationSpecialization 276 Systems Modeling Language v2.0, Part 1 -A variation Usage may not specialize any variation Definition or Usage . isVariation implies not ownedSpecialization.specific->exists( oclIsKindOf(Definition) and oclAsType(Definition).isVariation or oclIsKindOf(Usage) and oclAsType(Usage).isVariation) 8.3.6.5 VariantMembership Description A VariantMembership is a Membership between a variation point Definition or Usage and a Usage that represents a variant in the context of that variation. The membershipOwningNamespace for the VariantMembership must be either a Definition or a Usage with isVariation = true . General Classes OwningMembership Attributes /ownedVariantUsage : Usage {redefines ownedMemberElement} The Usage that represents a variant in the context of the owningVariationDefinition or owningVariationUsage . Operations None. Constraints validateVariantMembershipOwningNamespace The membershipOwningNamespace of a VariantMembership must be a variation-point Definition or Usage . membershipOwningNamespace.oclIsKindOf(Definition) and membershipOwningNamespace.oclAsType(Definition).isVariation or membershipOwningNamespace.oclIsKindOf(Usage) and membershipOwningNamespace.oclAsType(Usage).isVariation Systems Modeling Language v2.0, Part 1 277 -8.3.7 Attributes Abstract Syntax 8.3.7.1 Overview +/attributeOwningDefinition Definition Usage 0..1 +/attributeOwningUsage 0..1 {subsets owningDefinition} {subsets owningUsage} {subsets nestedUsage, ordered} +/nestedAttribute 0..* +/ownedAttribute AttributeDefinition AttributeUsage 0..* +/isReference : Boolean = true{redefines isReference} {subsets ownedUsage, +/definedAttribute 0..* ordered} {subsets definedUsage} +/attributeDefinition DataType 0..* {redefines definition, ordered} Figure 10. Attribute Definition and Usage 8.3.7.2 AttributeDefinition Description An AttributeDefinition is a Definition and a DataType of information about a quality or characteristic of a system or part of a system that has no independent identity other than its value. All features of an AttributeDefinition must be referential (non-composite). As a DataType , an AttributeDefinition must specialize, directly or indirectly, the base DataType Base::DataValue from the Kernel Semantic Library. General Classes Definition DataType Attributes None. Operations None. Constraints validateAttributeDefinitionFeatures All features of an AttributeDefinition must be non-composite. feature->forAll(not isComposite) 278 Systems Modeling Language v2.0, Part 1 -8.3.7.3 AttributeUsage Description An AttributeUsage is a Usage whose type is a DataType . Nominally, if the type is an AttributeDefinition , an AttributeUsage is a usage of a AttributeDefinition to represent the value of some system quality or characteristic. However, other kinds of kernel DataTypes are also allowed, to permit use of DataTypes from the Kernel Model Libraries. An AttributeUsage itself as well as all its nested features must be referential (non- composite). An AttributeUsage must specialize, directly or indirectly, the base Feature Base::dataValues from the Kernel Semantic Library. General Classes Usage Attributes /attributeDefinition : DataType [0..*] {redefines definition, ordered} The DataTypes that are the types of this AttributeUsage . Nominally, these are AttributeDefinitions , but other kinds of kernel DataTypes are also allowed, to permit use of DataTypes from the Kernel Model Libraries. /isReference : Boolean {redefines isReference} Always true for an AttributeUsage . Operations None. Constraints checkAttributeUsageSpecialization An AttributeUsage must directly or indirectly specialize Base::dataValues from the Kernel Semantic Library. specializesFromLibrary('Base::dataValues') validateAttributeUsageFeatures All features of an AttributeUsage must be non-composite. feature->forAll(not isComposite) validateAttributeUsageIsReference An AttributeUsage is always referential. isReference Systems Modeling Language v2.0, Part 1 279 -8.3.8 Enumerations Abstract Syntax 8.3.8.1 Overview +/enumerationOwningDefinition +/enumerationOwningUsage Definition Usage 0..1 0..1 {subsets {subsets attributeOwningDefinition} attributeOwningUsage} AttributeDefinition AttributeUsage +/ownedEnumeration EnumerationDefinition EnumerationUsage 0..* +isVariation : Boolean = true{redefines isVariation} {subsets ownedAttribute, ordered} +/owningEnumerationDefinition +/enumeratedValue +/nestedEnumeration 0..1 0..* 0..* {subsets owningVariationDefinition} {redefines variant, ordered} {subsets nestedAttribute, ordered} +/enumerationDefinition +/definedEnumeration 1 0..* {redefines attributeDefinition} {subsets definedAttribute} Figure 11. Enumeration Definition and Usage 8.3.8.2 EnumerationDefinition Description An EnumerationDefinition is an AttributeDefinition all of whose instances are given by an explicit list of enumeratedValues . This is realized by requiring that the EnumerationDefinition have isVariation = true , with the enumeratedValues being its variants . General Classes AttributeDefinition Attributes /enumeratedValue : EnumerationUsage [0..*] {redefines variant, ordered} EnumerationUsages of this EnumerationDefinition that have distinct, fixed values. Each enumeratedValue specifies one of the allowed instances of the EnumerationDefinition . isVariation : Boolean {redefines isVariation} An EnumerationDefinition is considered semantically to be a variation whose allowed variants are its enumerationValues . Operations None. Constraints validateEnumerationDefinitionIsVariation 280 Systems Modeling Language v2.0, Part 1 -An EnumerationDefinition must be a variation. isVariation 8.3.8.3 EnumerationUsage Description An EnumerationUsage is an AttributeUsage whose attributeDefinition is an EnumerationDefinition . General Classes AttributeUsage Attributes /enumerationDefinition : EnumerationDefinition {redefines attributeDefinition} The single EnumerationDefinition that is the type of this EnumerationUsage. Operations None. Constraints None. 8.3.9 Occurrences Abstract Syntax 8.3.9.1 Overview +/occurrenceOwningDefinition Definition Usage 0..1 +/occurrenceOwningUsage 0..1 {subsets owningDefinition} {subsets owningUsage} {subsets nestedUsage, ordered} +/nestedOccurrence 0..* +/ownedOccurrence OccurrenceUsage «enumeration» 0..* PortionKind +isIndividual : Boolean = false {subsets ownedUsage, ordered} +portionKind : PortionKind [0..1] timeslice snapshot OccurrenceDefinition +/individualDefinition +/individualUsage +isIndividual : Boolean = false 0..1 0..* {subsets occurrenceDefinition} +/occurrenceDefinition +/definedOccurrence Class 0..* 0..* {redefines {subsets definedUsage} definition, ordered} Figure 12. Occurrence Definition and Usage Systems Modeling Language v2.0, Part 1 281 -+/eventOccurrence OccurrenceUsage 1 +/referencingOccurrence EventOccurrenceUsage 0..* +/isReference : Boolean = true{redefines isReference} Figure 13. Event Occurrences 8.3.9.2 EventOccurrenceUsage Description An EventOccurrenceUsage is an OccurrenceUsage that represents another OccurrenceUsage occurring as a suboccurrence of the containing occurrence of the EventOccurrenceUsage . Unless it is the EventOccurrenceUsage itself, the referenced OccurrenceUsage is related to the EventOccurrenceUsage by a ReferenceSubsetting Relationship . If the EventOccurrenceUsage is owned by an OccurrenceDefinition or OccurrenceUsage , then it also subsets the timeEnclosedOccurrences property of the Class Occurrence from the Kernel Semantic Library model Occurrences . General Classes OccurrenceUsage Attributes /eventOccurrence : OccurrenceUsage The OccurrenceUsage referenced as an event by this EventOccurrenceUsage . It is the referenceFeature of the ownedReferenceSubsetting for the EventOccurrenceUsage , if there is one, and, otherwise, the EventOccurrenceUsage itself. /isReference : Boolean {redefines isReference} Always true for an EventOccurrenceUsage . Operations None. Constraints checkEventOccurrenceUsageSpecialization If an EventOccurrenceUsage has an owningType that is an OccurrenceDefinition or OccurrenceUsage , then it must directly or indirectly specialize the Feature Occurrences::Occurrence::timeEnclosedOccurrences . owningType <> null and (owningType.oclIsKindOf(OccurrenceDefinition) or 282 Systems Modeling Language v2.0, Part 1 -owningType.oclIsKindOf(OccurrenceUsage)) implies specializesFromLibrary('Occurrences::Occurrence::timeEnclosedOccurrences') deriveEventOccurrenceUsageEventOccurrence If an EventOccurrenceUsage has no ownedReferenceSubsetting , then its eventOccurrence is the EventOccurrenceUsage itself. Otherwise, the eventOccurrence is the featureTarget of the referencedFeature of the ownedReferenceSubsetting (which must be an OccurrenceUsage ). eventOccurrence = if referencedFeatureTarget() = null then self else if referencedFeatureTarget().oclIsKindOf(OccurrenceUsage) then referencedFeatureTarget().oclAsType(OccurrenceUsage) else null endif endif validateEventOccurrenceUsageIsReference An EventOccurrenceUsage must be referential. isReference validateEventOccurrenceUsageReference If an EventOccurrenceUsage has an ownedReferenceSubsetting , then the featureTarget of the referencedFeature must be an OccurrenceUsage . referencedFeatureTarget() <> null implies referencedFeatureTarget().oclIsKindOf(OccurrenceUsage) 8.3.9.3 OccurrenceDefinition Description An OccurrenceDefinition is a Definition of a Class of individuals that have an independent life over time and potentially an extent over space. This includes both structural things and behaviors that act on such structures. If isIndividual is true, then the OccurrenceDefinition is constrained to have (at most) a single instance that is the entire life of a single individual. General Classes Definition Class Attributes isIndividual : Boolean Whether this OccurrenceDefinition is constrained to represent at most one thing. Operations None. Constraints checkOccurrenceDefinitionIndividualSpecialization Systems Modeling Language v2.0, Part 1 283 -An OccurrenceDefinition with isIndividual = true must directly or indirectly specialize Occurrences::Life from the Kernel Semantic Library. isIndividual implies specializesFromLibrary('Occurrences::Life') checkOccurrenceDefinitionMultiplicitySpecialization An OccurrenceDefinition with isIndividual = true must have a multiplicity that specializes Base::zeroOrOne from the Kernel Semantic Library. isIndividual implies multiplicity <> null and multiplicity.specializesFromLibrary('Base::zeroOrOne') 8.3.9.4 OccurrenceUsage Description An OccurrenceUsage is a Usage whose types are all Classes . Nominally, if a type is an OccurrenceDefinition , an OccurrenceUsage is a Usage of that OccurrenceDefinition within a system. However, other types of Kernel Classes are also allowed, to permit use of Classes from the Kernel Model Libraries. General Classes Usage Attributes /individualDefinition : OccurrenceDefinition [0..1] {subsets occurrenceDefinition} The at most one occurrenceDefinition that has isIndividual = true . isIndividual : Boolean Whether this OccurrenceUsage represents the usage of the specific individual represented by its individualDefinition . /occurrenceDefinition : Class [0..*] {redefines definition, ordered} The Classes that are the types of this OccurrenceUsage . Nominally, these are OccurrenceDefinitions , but other kinds of kernel Classes are also allowed, to permit use of Classes from the Kernel Model Libraries. portionKind : PortionKind [0..1] The kind of temporal portion (time slice or snapshot) is represented by this OccurrenceUsage . If portionKind is not null, then the owningType of the OccurrenceUsage must be non-null, and the OccurrenceUsage represents portions of the featuring instance of the owningType . Operations None. Constraints checkOccurrenceUsageSnapshotSpecialization 284 Systems Modeling Language v2.0, Part 1 -If an OccurrenceUsage has portionKind = snapshot , then it must directly or indirectly specialize Occurrences::Occurrence::snapshots from the Kernel Semantic Library. portionKind = PortionKind::snapshot implies specializesFromLibrary('Occurrences::Occurrence::snapshots') checkOccurrenceUsageSpecialization An OccurrenceUsage must directly or indirectly specialize Occurrences::occurrences from the Kernel Semantic Library. specializesFromLibrary('Occurrences::occurrences') checkOccurrenceUsageSuboccurrenceSpecialization A composite OccurrenceUsage , whose ownedType is a Class , another OccurrenceUsage , or any kind of Feature typed by a Class , must directly or indirectly specialize Occurrences::Occurrence::suboccurrences isComposite and owningType <> null and (owningType.oclIsKindOf(Class) or owningType.oclIsKindOf(OccurrenceUsage) or owningType.oclIsKindOf(Feature) and owningType.oclAsType(Feature).type-> exists(oclIsKind(Class))) implies specializesFromLibrary('Occurrences::Occurrence::suboccurrences') checkOccurrenceUsageTimeSliceSpecialization If an OccurrenceUsage has portionKind = timeslice , then it must directly or indirectly specialize Occurrences::Occurrence::timeSlices from the Kernel Semantic Library. portionKind = PortionKind::timeslice implies specializesFromLibrary('Occurrences::Occurrence::timeSlices') deriveOccurrenceUsageIndividualDefinition The individualDefinition of an OccurrenceUsage is the occurrenceDefinition that is an OccurrenceDefinition with isIndividual = true , if any. individualDefinition = let individualDefinitions : OrderedSet(OccurrenceDefinition) = occurrenceDefinition-> selectByKind(OccurrenceDefinition)-> select(isIndividual) in if individualDefinitions->isEmpty() then null else individualDefinitions->first() endif validateOccurrenceUsageIndividualDefinition An OccurrenceUsage must have at most one occurrenceDefinition with isIndividual = true . occurrenceDefinition-> selectByKind(OccurrenceDefinition)-> select(isIndividual).size() <= 1 validateOccurrenceUsageIndividualUsage Systems Modeling Language v2.0, Part 1 285 -If an OccurrenceUsage has isIndividual = true , then it must have an individualDefinition . isIndividual implies individualDefinition <> null validateOccurrenceUsageIsPortion If an OccurrenceUsage has a non-null portionKind , then it must have isPortion = true . portionKind <> null implies isPortion validateOccurrenceUsagePortionKind If an OccurrenceUsage has a non-null portionKind , then its owningType must be an OccurrenceDefinition or an OccurrenceUsage . portionKind <> null implies owningType <> null and (owningType.oclIsKindOf(OccurrenceDefinition) or owningType.oclIsKindOf(OccurrenceUsage)) 8.3.9.5 PortionKind Description PortionKind is an enumeration of the specific kinds of Occurrence portions that can be represented by an OccurrenceUsage . General Classes None. Literal Values snapshot A snapshot of an Occurrence (a time slice with zero duration). timeslice A time slice of an Occurrence (a portion over time). 286 Systems Modeling Language v2.0, Part 1 -8.3.10 Items Abstract Syntax 8.3.10.1 Overview +/itemOwningDefinition +/itemOwningUsage Definition Usage 0..1 0..1 {subsets {subsets occurrenceOwningDefinition} occurrenceOwningUsage} OccurrenceDefinition OccurrenceUsage +/nestedItem +/ownedItem ItemDefinition ItemUsage 0..* 0..* {subsets ownedOccurrence, +/definedItem 0..* {subsets nestedOccurrence, ordered} ordered} {subsets definedOccurrence} +/itemDefinition Structure 0..* {subsets occurrenceDefinition, ordered} Figure 14. Item Definition and Usage 8.3.10.2 ItemDefinition Description An ItemDefinition is an OccurrenceDefinition of the Structure of things that may themselves be systems or parts of systems, but may also be things that are acted on by a system or parts of a system, but which do not necessarily perform actions themselves. This includes items that can be exchanged between parts of a system, such as water or electrical signals. General Classes Structure OccurrenceDefinition Attributes None. Operations None. Constraints checkItemDefinitionSpecialization An ItemDefinition must directly or indirectly specialize the Systems Library Model ItemDefinition Items::Item . specializesFromLibrary('Items::Item') Systems Modeling Language v2.0, Part 1 287 -8.3.10.3 ItemUsage Description An ItemUsage is a ItemUsage whose definition is a Structure . Nominally, if the definition is an ItemDefinition , an ItemUsage is a ItemUsage of that ItemDefinition within a system. However, other kinds of Kernel Structures are also allowed, to permit use of Structures from the Kernel Model Libraries. General Classes OccurrenceUsage Attributes /itemDefinition : Structure [0..*] {subsets occurrenceDefinition, ordered} The Structures that are the definitions of this ItemUsage. Nominally, these are ItemDefinitions, but other kinds of Kernel Structures are also allowed, to permit use of Structures from the Kernel Library. Operations None. Constraints checkItemUsageSpecialization An ItemUsage must directly or indirectly specialize the Systems Model Library ItemUsage items . specializesFromLibrary('Items::items') checkItemUsageSubitemSpecialization isComposite and owningType <> null and (owningType.oclIsKindOf(ItemDefinition) or owningType.oclIsKindOf(ItemUsage)) implies specializesFromLibrary('Items::Item::subitem') deriveItemUsageItemDefinition The itemDefinitions of an ItemUsage are those occurrenceDefinitions that are Structures . itemDefinition = occurrenceDefinition->selectByKind(Structure) 288 Systems Modeling Language v2.0, Part 1 -8.3.11 Parts Abstract Syntax 8.3.11.1 Overview +/partOwningUsage +/partOwningDefinition Definition Usage 0..1 0..1 {subsets itemOwningUsage} {subsets itemOwningDefinition} OccurrenceDefinition OccurrenceUsage ItemDefinition ItemUsage +/ownedPart PartUsage 0..* +/nestedPart {subsets ownedItem, ordered} 0..* +/definedPart +/partDefinition PartDefinition {subsets nestedItem, 0..* 0..* ordered} {subsets definedItem} {subsets itemDefinition, ordered} Figure 15. Part Definition and Usage 8.3.11.2 PartDefinition Description A PartDefinition is an ItemDefinition of a Class of systems or parts of systems. Note that all parts may be considered items for certain purposes, but not all items are parts that can perform actions within a system. General Classes ItemDefinition Attributes None. Operations None. Constraints checkPartDefinitionSpecialization A PartDefinition must directly or indirectly specialize the base PartDefinition Parts::Part from the Systems Model Library. specializesFromLibrary('Parts::Part') 8.3.11.3 PartUsage Description Systems Modeling Language v2.0, Part 1 289 -A PartUsage is a usage of a PartDefinition to represent a system or a part of a system. At least one of the itemDefinitions of the PartUsage must be a PartDefinition . A PartUsage must subset, directly or indirectly, the base PartUsage parts from the Systems Model Library. General Classes ItemUsage Attributes /partDefinition : PartDefinition [0..*] {subsets itemDefinition, ordered} The itemDefinitions of this PartUsage that are PartDefinitions. Operations None. Constraints checkPartUsageActorSpecialization If a PartUsage is owned via an ActorMembership , then it must directly or indirectly specialize either Requirements::RequirementCheck::actors (if its owningType is a RequirementDefinition or RequirementUsage or Cases::Case::actors (otherwise). owningFeatureMembership <> null and owningFeatureMembership.oclIsKindOf(ActorMembership) implies if owningType.oclIsKindOf(RequirementDefinition) or owningType.oclIsKindOf(RequirementUsage) then specializesFromLibrary('Requirements::RequirementCheck::actors') else specializesFromLibrary('Cases::Case::actors') checkPartUsageSpecialization A PartUsage must directly or indirectly specialize the PartUsage Parts::parts from the Systems Model Library. specializesFromLibrary('Parts::parts') checkPartUsageStakeholderSpecialization If a PartUsage is owned via a StakeholderMembership , then it must directly or indirectly specialize either Requirements::RequirementCheck::stakeholders . owningFeatureMembership <> null and owningFeatureMembership.oclIsKindOf(StakeholderMembership) implies specializesFromLibrary('Requirements::RequirementCheck::stakeholders') checkPartUsageSubpartSpecialization A composite PartUsage whose owningType is a ItemDefinition or ItemUsage must directly or indirectly specialize the PartUsage Items::Item::subparts from the Systems Model Library. isComposite and owningType <> null and (owningType.oclIsKindOf(ItemDefinition) or 290 Systems Modeling Language v2.0, Part 1 -owningType.oclIsKindOf(ItemUsage)) implies specializesFromLibrary('Items::Item::subparts') derivePartUsagePartDefinition The partDefinitions of an PartUsage are those itemDefinitions that are PartDefinitions . itemDefinition->selectByKind(PartDefinition) validatePartUsagePartDefinition At least one of the itemDefinitions of a PartUsage must be a PartDefinition . partDefinition->notEmpty() 8.3.12 Ports Abstract Syntax 8.3.12.1 Overview +/portOwningUsage +/portOwningDefinition Definition Usage 0..1 0..1 {subsets owningDefinition} {redefines owningUsage} OccurrenceDefinition OccurrenceUsage +/ownedPort PortDefinition PortUsage 0..* +/nestedPort {subsets ownedUsage, ordered} 0..* +/portDefinition +/definedPort {subsets nestedUsage, 0..* 0..* ordered} {redefines occurrenceDefinition, {subsets definedOccurrence} ordered} Structure Figure 16. Port Definition and Usage FeatureTyping Conjugation {redefines originalType} +/portDefinition +originalPortDefinition PortDefinition 1 1 1 +/originalPortDefinition {redefines owningNamespace} {subsets targetRelationship} {subsets conjugation} +portConjugation 0..1 0..* +/conjugatedPortTyping ConjugatedPortTyping PortConjugation +typingByConjugatedPort 0..* +/ownedPortConjugator 1 {subsets typingByType} {subsets ownedMember} {redefines ownedConjugator} 0..1 +/conjugatedPortDefinition +/conjugatedPortDefinition ConjugatedPortDefinition +conjugatedPortDefinition 1 +effectiveName() : String [0..1]{redefines effectiveName} 1 {redefines owningType} {redefines type} Figure 17. Port Conjugation Systems Modeling Language v2.0, Part 1 291 -8.3.12.2 ConjugatedPortDefinition Description A ConjugatedPortDefinition is a PortDefinition that is a PortDefinition of its original PortDefinition . That is, a ConjugatedPortDefinition inherits all the features of the original PortDefinition , but input flows of the original PortDefinition become outputs on the ConjugatedPortDefinition and output flows of the original PortDefinition become inputs on the ConjugatedPortDefinition . Every PortDefinition (that is not itself a ConjugatedPortDefinition ) has exactly one corresponding ConjugatedPortDefinition , whose effective name is the name of the originalPortDefinition , with the character ~ prepended. General Classes PortDefinition Attributes /originalPortDefinition : PortDefinition {redefines owningNamespace} The original PortDefinition for this ConjugatedPortDefinition , which is the owningNamespace of the ConjugatedPortDefinition . /ownedPortConjugator : PortConjugation {redefines ownedConjugator} The PortConjugation that is the ownedConjugator of this ConjugatedPortDefinition , linking it to its originalPortDefinition . Operations effectiveName() : String [0..1] {redefines effectiveName} If the name of the originalPortDefinition is non-empty, then return that with the character ~ prepended. body: let originalName : String = originalPortDefinition.name in if originalName = null then null else '~' + originalName endif Constraints validateConjugatedPortDefinitionConjugatedPortDefinitionIsEmpty A ConjugatedPortDefinition must not itself have a conjugatedPortDefinition conjugatedPortDefinition = null validateConjugatedPortDefinitionOriginalPortDefinition The originalPortDefinition of the ownedPortConjugator of a ConjugatedPortDefinition must be the originalPortDefinition of the ConjugatedPortDefinition . ownedPortConjugator.originalPortDefinition = originalPortDefinition 8.3.12.3 ConjugatedPortTyping Description 292 Systems Modeling Language v2.0, Part 1 -A ConjugatedPortTyping is a FeatureTyping whose type is a ConjugatedPortDefinition . (This relationship is intended to be an abstract-syntax marker for a special surface notation for conjugated typing of ports.) General Classes FeatureTyping Attributes conjugatedPortDefinition : ConjugatedPortDefinition {redefines type} The type of this ConjugatedPortTyping considered as a FeatureTyping , which must be a ConjugatedPortDefinition . /portDefinition : PortDefinition The originalPortDefinition of the conjugatedPortDefinition of this ConjugatedPortTyping . Operations None. Constraints deriveConjugatedPortTypingPortDefinition The portDefinition of a ConjugatedPortTyping is the originalPortDefinition of the conjugatedPortDefinition of the ConjugatedPortTyping . portDefinition = conjugatedPortDefinition.originalPortDefinition 8.3.12.4 PortConjugation Description A PortConjugation is a Conjugation Relationship between a PortDefinition and its corresponding ConjugatedPortDefinition . As a result of this Relationship , the ConjugatedPortDefinition inherits all the features of the original PortDefinition , but input flows of the original PortDefinition become outputs on the ConjugatedPortDefinition and output flows of the original PortDefinition become inputs on the ConjugatedPortDefinition . General Classes Conjugation Attributes /conjugatedPortDefinition : ConjugatedPortDefinition {redefines owningType} The ConjugatedPortDefinition that is conjugate to the originalPortDefinition . originalPortDefinition : PortDefinition {redefines originalType} The PortDefinition being conjugated. Operations Systems Modeling Language v2.0, Part 1 293 -None. Constraints None. 8.3.12.5 PortDefinition Description A PortDefinition defines a point at which external entities can connect to and interact with a system or part of a system. Any ownedUsages of a PortDefinition , other than PortUsages , must not be composite. General Classes Structure OccurrenceDefinition Attributes /conjugatedPortDefinition : ConjugatedPortDefinition [0..1] {subsets ownedMember} The that is conjugate to this PortDefinition . Operations None. Constraints checkPortDefinitionSpecialization A PortDefinition must directly or indirectly specialize the PortDefinition Ports::Port from the Systems Model Library. specializesFromLibrary('Ports::Port') derivePortDefinitionConjugatedPortDefinition The conjugatedPortDefinition of a PortDefinition is the ownedMember that is a ConjugatedPortDefinition . conjugatedPortDefinition = let conjugatedPortDefinitions : OrderedSet(ConjugatedPortDefinition) = ownedMember->selectByKind(ConjugatedPortDefinition) in if conjugatedPortDefinitions->isEmpty() then null else conjugatedPortDefinitions->first() endif validatePortDefinitionConjugatedPortDefinition Unless it is a ConjugatedPortDefinition , a PortDefinition must have exactly one ownedMember that is a ConjugatedPortDefinition . not oclIsKindOf(ConjugatedPortDefinition) implies ownedMember-> 294 Systems Modeling Language v2.0, Part 1 -selectByKind(ConjugatedPortDefinition)-> size() = 1 validatePortDefinitionOwnedUsagesNotComposite The ownedUsages of a PortDefinition that are not PortUsages must not be composite. ownedUsage-> reject(oclIsKindOf(PortUsage))-> forAll(not isComposite) 8.3.12.6 PortUsage Description A PortUsage is a usage of a PortDefinition . A PortUsage itself as well as all its nestedUsages must be referential (non-composite). General Classes OccurrenceUsage Attributes /portDefinition : PortDefinition [0..*] {redefines occurrenceDefinition, ordered} The occurrenceDefinitions of this PortUsage , which must all be PortDefinitions. Operations None. Constraints checkPortUsageOwnedPortSpecialization A PortUsage whose owningType is a PartDefinition or PartUsage must directly or indirectly specialize the PortUsage Parts::Part::ownedPorts from the Systems Model Library. owningType <> null and (owningType.oclIsKindOf(PartDefinition) or owningType.oclIsKindOf(PartUsage)) implies specializesFromLibrary('Parts::Part::ownedPorts') checkPortUsageSpecialization A PortUsage must directly or indirectly specialize the PortUsage Ports::ports from the Systems Model Library. specializesFromLibrary('Ports::ports') checkPortUsageSubportSpecialization A composite PortUsage with an owningType that is a PortDefinition or PortUsage must directly or indirectly specialize the PortUsage Ports::Port::subports from the Systems Model Library. isComposite and owningType <> null and (owningType.oclIsKindOf(PortDefinition) or Systems Modeling Language v2.0, Part 1 295 -owningType.oclIsKindOf(PortUsage)) implies specializesFromLibrary('Ports::Port::subports') validatePortUsageIsReference Unless a PortUsage has an owningType that is a PortDefinition or a PortUsage , it must be referential (non- composite). owningType = null or not owningType.oclIsKindOf(PortDefinition) and not owningType.oclIsKindOf(PortUsage) implies isReference validatePortUsageNestedUsagesNotComposite The nestedUsages of a PortUsage that are not themselves PortUsages must not be composite. nestedUsage-> reject(oclIsKindOf(PortUsage))-> forAll(not isComposite) 8.3.13 Connections Abstract Syntax 8.3.13.1 Overview Usage Connector ConnectorAsUsage BindingConnectorAsUsage SuccessionAsUsage BindingConnector Succession Figure 18. Connectors as Usages 296 Systems Modeling Language v2.0, Part 1 -+/connectionOwningDefinition +/connectionEnd +/connectionOwningUsage Definition Usage 0..1 0..* 0..1 {subsets {redefines associationEnd, {subsets partOwningUsage} partOwningDefinition} ordered} OccurrenceDefinition OccurrenceUsage ItemDefinition ItemUsage PartDefinition PartUsage ConnectionDefinition ConnectionUsage +/connectionDefinitionWithEnd +isSufficient : Boolean = true{redefines isSufficient} 0..* +/definedConnection {redefines associationWithEnd} 0..* {subsets typedConnector, ordered} +/connectionDefinition AssociationStructure 0..* {subsets itemDefinition, redefines association, ordered} +/ownedConnection +/nestedConnection ConnectorAsUsage 0..* 0..* {subsets ownedUsage, {subsets nestedUsage, ordered} ordered} Figure 19. Connection Definition and Usage 8.3.13.2 BindingConnectorAsUsage Description A BindingConnectorAsUsage is both a BindingConnector and a ConnectorAsUsage . General Classes ConnectorAsUsage BindingConnector Attributes None. Operations None. Constraints None. 8.3.13.3 ConnectionDefinition Description A ConnectionDefinition is a PartDefinition that is also an AssociationStructure . The end Features of a ConnectionDefinition must be Usages . General Classes Systems Modeling Language v2.0, Part 1 297 -PartDefinition AssociationStructure Attributes /connectionEnd : Usage [0..*] {redefines associationEnd, ordered} The Usages that define the things related by the ConnectionDefinition . isSufficient : Boolean {redefines isSufficient} A ConnectionDefinition always has isSufficient = true . Operations None. Constraints checkConnectionDefinitionBinarySpecialization A binary ConnectionDefinition must directly or indirectly specialize the ConnectionDefinition Connections::BinaryConnection from the Systems Model Library. ownedEndFeature->size() = 2 implies specializesFromLibrary('Connections::BinaryConnections') checkConnectionDefinitionSpecializations A ConnectionDefinition must directly or indirectly specialize the ConnectionDefinition Connections::Connection from the Systems Model Library. specializesFromLibrary('Connections::Connection') validateConnectionDefinitionIsSufficient A ConnectionDefinition must have isSufficient = true . isSufficient 8.3.13.4 ConnectionUsage Description A ConnectionUsage is a ConnectorAsUsage that is also a PartUsage . Nominally, if its type is a ConnectionDefinition , then a ConnectionUsage is a Usage of that ConnectionDefinition , representing a connection between parts of a system. However, other kinds of kernel AssociationStructures are also allowed, to permit use of AssociationStructures from the Kernel Model Libraries. General Classes PartUsage ConnectorAsUsage Attributes /connectionDefinition : AssociationStructure [0..*] {subsets itemDefinition, redefines association, ordered} 298 Systems Modeling Language v2.0, Part 1 -The AssociationStructures that are the types of this ConnectionUsage . Nominally, these are , but other kinds of Kernel AssociationStructures are also allowed, to permit use of AssociationStructures from the Kernel Model Libraries Operations None. Constraints checkConnectionUsageBinarySpecialization A binary ConnectionUsage must directly or indirectly specialize the ConnectionUsage Connections::binaryConnections from the Systems Model Library. ownedEndFeature->size() = 2 implies specializesFromLibrary('Connections::binaryConnections') checkConnectionUsageSpecialization A ConnectionUsage must directly or indirectly specialize the ConnectionUsage Connections::connections from the Systems Model Library. specializesFromLibrary('Connections::connections') 8.3.13.5 ConnectorAsUsage Description A ConnectorAsUsage is both a Connector and a Usage . ConnectorAsUsage cannot itself be instantiated in a SysML model, but it is a base class for the concrete classes BindingConnectorAsUsage , SuccessionAsUsage , ConnectionUsage and FlowConnectionUsage . General Classes Connector Usage Attributes None. Operations None. Constraints None. 8.3.13.6 SuccessionAsUsage Description A SuccessionAsUsage is both a ConnectorAsUsage and a Succession . General Classes Systems Modeling Language v2.0, Part 1 299 -Succession ConnectorAsUsage Attributes None. Operations None. Constraints None. 8.3.14 Interfaces Abstract Syntax 8.3.14.1 Overview +/interfaceOwningDefinition Definition Usage 0..1 +/interfaceOwningUsage 0..1 {subsets {subsets connectionOwningDefinition} connectionOwningUsage} OccurrenceDefinition OccurrenceUsage ItemDefinition ItemUsage PartDefinition PartUsage ConnectionDefinition ConnectionUsage {subsets nestedConnection, ordered} +/nestedInterface 0..* +/ownedInterface InterfaceUsage 0..* {subsets ownedConnection, ordered} +/interfaceDefinition +/definedInterface InterfaceDefinition 0..* 0..* {redefines connectionDefinition} {subsets definedConnection} +/interfaceDefinitionWithEnd +/interfaceEnd PortUsage 0..* 0..* {subsets connectionDefinitionWithEnd} {redefines connectionEnd, ordered} Figure 20. Interface Definition and Usage 8.3.14.2 InterfaceDefinition Description An InterfaceDefinition is a ConnectionDefinition all of whose ends are PortUsages , defining an interface between elements that interact through such ports. 300 Systems Modeling Language v2.0, Part 1 -General Classes ConnectionDefinition Attributes /interfaceEnd : PortUsage [0..*] {redefines connectionEnd, ordered} The PortUsages that are the connectionEnds of this InterfaceDefinition Operations None. Constraints checkInterfaceDefinitionBinarySpecialization A binary InterfaceDefinition must directly or indirectly specialize the InterfaceDefinition Interfaces::BinaryInterface from the Systems Model Library. ownedEndFeature->size() = 2 implies specializesFromLibrary('Interfaces::BinaryInterface') checkInterfaceDefinitionSpecialization An InterfaceDefinition must directly or indirectly specialize the InterfaceDefinition Interfaces::Interface from the Systems Model Library. specializesFromLibrary('Interfaces::Interface') 8.3.14.3 InterfaceUsage Description An InterfaceUsage is a Usage of an InterfaceDefinition to represent an interface connecting parts of a system through specific ports. General Classes ConnectionUsage Attributes /interfaceDefinition : InterfaceDefinition [0..*] {redefines connectionDefinition} The InterfaceDefinitions that type this InterfaceUsage . Operations None. Constraints checkInterfaceUsageBinarySpecialization Systems Modeling Language v2.0, Part 1 301 -A binary InterfaceUsage must directly or indirectly specialize the InterfaceUsage Interfaces::binaryInterfaces from the Systems Model Library. ownedEndFeature->size() = 2 implies specializesFromLibrary('Interfaces::binaryInterfaces') checkInterfaceUsageSpecialization An InterfaceUsage must directly or indirectly specialize the InterfaceUsage Interfaces::interfaces from the Systems Model Library. specializesFromLibrary('Interfaces::interfaces') 8.3.15 Allocations Abstract Syntax 8.3.15.1 Overview +/allocationOwningUsage +allocationOwningDefinition Definition Usage 0..1 0..1 {subsets {subsets connectionOwningUsage} connectionOwningDefinition} OccurrenceDefinition OccurrenceUsage ItemDefinition ItemUsage PartDefinition PartUsage ConnectionDefinition ConnectionUsage +/ownedAllocation AllocationDefinition AllocationUsage 0..* {subsets ownedConnection, ordered} +/featuringAllocationDefinition +/allocation +/nestedAllocation 0..* 0..* 0..* {subsets featuringDefinition} {subsets usage, ordered} {subsets nestedConnection, ordered} +/allocationDefinition +/definedAllocation 0..* 0..* {redefines connectionDefinition, {subsets definedConnection} ordered} Figure 21. Allocation Definition and Usage 8.3.15.2 AllocationDefinition Description An AllocationDefinition is a ConnectionDefinition that specifies that some or all of the responsibility to realize the intent of the source is allocated to the target instances. Such allocations define mappings across the various structures and hierarchies of a system model, perhaps as a precursor to more rigorous specifications and 302 Systems Modeling Language v2.0, Part 1 -implementations. An AllocationDefinition can itself be refined using nested allocations that give a finer- grained decomposition of the containing allocation mapping. General Classes ConnectionDefinition Attributes /allocation : AllocationUsage [0..*] {subsets usage, ordered} The AllocationUsages that refine the allocation mapping defined by this AllocationDefinition . Operations None. Constraints checkAllocationDefinitionSpecialization An AllocationDefinition must directly or indirectly specialize the AllocationDefinition Allocations::Allocation from the Systems Model Library. specializesFromLibrary('Allocations::Allocation') deriveAllocationDefinitionAllocation The allocations of an AllocationDefinition are all its usages that are AllocationUsages . allocation = usage->selectAsKind(AllocationUsage) 8.3.15.3 AllocationUsage Description An AllocationUsage is a usage of an AllocationDefinition asserting the allocation of the source feature to the target feature. General Classes ConnectionUsage Attributes /allocationDefinition : AllocationDefinition [0..*] {redefines connectionDefinition, ordered} The AllocationDefinitions that are the types of this AllocationUsage . Operations None. Constraints checkAllocationUsageSpecialization Systems Modeling Language v2.0, Part 1 303 -An AllocationUsage must directly or indirectly specialize the AllocationUsage Allocations::allocations from the Systems Model Library. specializesFromLibrary('Allocations::allocations') 8.3.16 Flow Abstract Syntax 8.3.16.1 Overview +/flowEnd Usage 0..* {redefines associationEnd} +/flowOwningDefinition +/flowOwningUsage Definition 0..1 0..1 {subsets connectionOwningDefinition} {subsets connectionOwningUsage} OccurrenceDefinition OccurrenceUsage ActionDefinition ActionUsage ConnectorAsUsage Connector +/flowDefinitionWithEnd +/nestedFlow FlowDefinition FlowUsage 0..* 0..* {redefines associationWithEnd} {subsets nestedConnection} Flow +/flowDefinition +/definedFlow Interaction 0..* 0..* {redefines ownedAction} {redefines actionDefinition, redefines interaction, ordered} +/ownedFlow 0..* {subsets ownedConnection} SuccessionFlowUsage SuccessionFlow Figure 22. Flows 8.3.16.2 FlowDefinition Description A FlowDefinition is an ActionDefinition that is also an Interaction (which is both a KerML Behavior and Association ), representing flows between Usages . General Classes ActionDefinition Interaction Attributes /flowEnd : Usage [0..*] {redefines associationEnd} The Usages that define the things related by the FlowDefinition . Operations None. Constraints checkFlowDefinitionBinarySpecialization 304 Systems Modeling Language v2.0, Part 1 -A binary FlowDefinition must directly or indirectly specialize the base FlowDefinition Flows::Message from the Systems Model Library. flowEnd->size() = 2 implies specializesFromLibrary('Flows::Message') checkFlowDefinitionSpecialization A FlowDefinition must directly or indirectly specialize the base FlowDefinition Flows::MessageAction from the Systems Model Library. specializesFromLibrary('Flows::MessageAction') validateFlowDefinitionFlowEnds A FlowDefinition may not have more than two flowEnds . flowEnd->size() <= 2 8.3.16.3 FlowUsage Description A FlowUsage is an ActionUsage that is also a ConnectorAsUsage and a KerML Flow . General Classes Flow ActionUsage ConnectorAsUsage Attributes /flowDefinition : Interaction [0..*] {redefines actionDefinition, interaction, ordered} The Interactions that are the types of this FlowUsage . Nominally, these are FlowDefinitions , but other kinds of Kernel Interactions are also allowed, to permit use of Interactions from the Kernel Model Libraries. Operations None. Constraints checkFlowUsageFlowSpecialization If a FlowUsage has ownedEndFeatures , it must directly or indirectly specialize the FlowUsage Flows::flows from the Systems Model Library. ownedEndFeatures->notEmpty() implies specializesFromLibrary('Flows::flows') checkFlowUsageSpecialization A FlowUsage must directly or indirectly specialize the base FlowUsage Flows::messages from the Systems Library model. Systems Modeling Language v2.0, Part 1 305 -specializesFromLibrary('Flows::messages') 8.3.16.4 SuccessionFlowUsage Description A SuccessionFlowUsage is a FlowUsage that is also a KerML SuccessionFlow . General Classes FlowUsage SuccessionFlow Attributes None. Operations None. Constraints checkSuccessionFlowUsageSpecialization A SuccessionFlowUsage must directly or indirectly specialize the base FlowUsage Flows::successionFlows from the Systems Library model. specializesFromLibrary('Flows::successionFlows') 8.3.17 Actions Abstract Syntax 8.3.17.1 Overview +/actionOwningDefinition +/actionOwningUsage Definition Usage 0..1 0..1 {subsets {subsets occurrenceOwningDefinition} occurrenceOwningUsage} OccurrenceDefinition OccurrenceUsage +/ownedAction ActionUsage 0..* +inputParameters() : Feature [0..*] {subsets ownedOccurrence, +inputParameter( i : Integer ) : Feature [0..1] ordered} +/nestedAction +/action +/featuringActionDefinition +argument( i : Integer ) : Expression [0..1] ActionDefinition 0..* +isSubactionUsage() : Boolean 0..* 0..* {subsets nestedOccurrence, {subsets featuringBehavior, {subsets step, subsets usage, ordered} subsets featuringDefinition} ordered} +/definedAction 0..* {subsets definedOccurrence, subsets typedStep} +/actionDefinition Behavior Step 0..* {redefines behavior, redefines occurrenceDefinition, ordered} Figure 23. Action Definition and Usage 306 Systems Modeling Language v2.0, Part 1 -ActionUsage ControlNode MergeNode DecisionNode JoinNode ForkNode Figure 24. Control Nodes +/performedAction EventOccurrenceUsage ActionUsage 1 {redefines eventOccurrence} PerformActionUsage +/performingAction +namingFeature() : Feature [0..1]{redefines namingFeature} 0..* {subsets referencingOccurrence} Figure 25. Performed Actions Systems Modeling Language v2.0, Part 1 307 -ActionUsage +/sendingActionUsage +/owningAcceptActionUsage SendActionUsage AcceptActionUsage 0..1 0..1 +isTriggerAction() : Boolean +/senderActionUsage 0..1 0..1 +/sendActionUsage {subsets +/acceptActionUsage 0..1+/acceptingActionUsage 0..1 referenceOwningUsage} {subsets nestedReference, subsets parameter} +/senderArgument 0..1 0..1 +/receiverArgument +/payloadParameter 1 +/receiverArgument Expression ReferenceUsage +/payloadArgument 0..1 1 +/payloadArgument 0..1 InstantiationExpression InvocationExpression TriggerInvocationExpression «enumeration» TriggerKind +kind : TriggerKind when +instantiatedType() : Type{redefines instantiatedType} at after Figure 26. Send and Accept Actions ActionUsage +/assignment +/referent +/assignmentAction AssignmentActionUsage Feature 0..* 1 0..1 +/assigningAction 0..1 {subsets namespace} {subsets member} A_valueExpression_assigningAction 0..1 +/valueExpression +/targetArgument Expression 0..1 Figure 27. Assignment Actions 308 Systems Modeling Language v2.0, Part 1 -ActionUsage TerminateActionUsage +/terminateActionUsage 0..1 +/terminatedOccurrenceArgument 0..1 Expression Figure 28. Terminate Actions +/thenAction ActionUsage 1 +/bodyAction +/elseAction 1 0..1 +/ifElseAction 0..1 +/ifThenAction +/loopAction IfActionUsage LoopActionUsage 0..1 0..1 +/ifAction 0..1 +/forLoopAction WhileLoopActionUsage ForLoopActionUsage 0..1 +/forLoopAction 0..1 +/whileLoopAction 0..1 0..1 +/untilLoopAction +/ifArgument 1 +/whileArgument +/loopVariable 1 Expression 1 ReferenceUsage +/untilArgument 0..1 +/seqArgument 1 Figure 29. Structured Control Actions 8.3.17.2 AcceptActionUsage Description An AcceptActionUsage is an ActionUsage that specifies the acceptance of an incomingTransfer from the Occurrence given by the result of its receiverArgument Expression. (If no receiverArgument is provided, the default is the this context of the AcceptActionUsage.) The payload of the accepted Transfer is output on its payloadParameter . Which Transfers may be accepted is determined by conformance to the typing and (potentially) binding of the payloadParameter . General Classes Systems Modeling Language v2.0, Part 1 309 -ActionUsage Attributes /payloadArgument : Expression [0..1] An Expression whose result is bound to the payload parameter of this AcceptActionUsage . If provided, the AcceptActionUsage will only accept a Transfer with exactly this payload . /payloadParameter : ReferenceUsage {subsets nestedReference, parameter} The nestedReference of this AcceptActionUsage that redefines the payload output parameter of the base AcceptActionUsage AcceptAction from the Systems Model Library. /receiverArgument : Expression [0..1] An Expression whose result is bound to the receiver input parameter of this AcceptActionUsage . Operations isTriggerAction() : Boolean Check if this AcceptActionUsage is the triggerAction of a TransitionUsage . body: owningType <> null and owningType.oclIsKindOf(TransitionUsage) and owningType.oclAsType(TransitionUsage).triggerAction->includes(self) Constraints checkAcceptActionUsageReceiverBindingConnector If the payloadArgument of an AcceptActionUsage is a TriggerInvocationExpression , then the AcceptActionusage must have an ownedFeature that is a BindingConnector between its receiver parameter and the receiver parameter of the TriggerInvocationExpression . payloadArgument <> null and payloadArgument.oclIsKindOf(TriggerInvocationExpression) implies let invocation : Expression = payloadArgument.oclAsType(Expression) in parameter->size() >= 2 and invocation.parameter->size() >= 2 and ownedFeature->selectByKind(BindingConnector)->exists(b | b.relatedFeatures->includes(parameter->at(2)) and b.relatedFeatures->includes(invocation.parameter->at(2))) checkAcceptActionUsageSpecialization An AcceptActionUsage that is not the triggerAction of a TransitionUsage must directly or indirectly specialize the ActionUsage Actions::acceptActions from the Systems Model Library. not isTriggerAction() implies specializesFromLibrary('Actions::acceptActions') checkAcceptActionUsageSubactionSpecialization 310 Systems Modeling Language v2.0, Part 1 -A composite AcceptActionUsage that is a subaction usage, but is not the triggerAction of a TransitionUsage , must directly or indirectly specialize the ActionUsage Actions::Action::acceptSubactions from the Systems Model Library. isSubactionUsage() and not isTriggerAction() implies specializesFromLibrary('Actions::Action::acceptSubactions') checkAcceptActionUsageTriggerActionSpecialization An AcceptActionUsage that is the triggerAction of TransitionUsage must directly or indirectly specialize the ActionUsage Actions::TransitionAction::accepter from the Systems Model Library. isTriggerAction() implies specializesFromLibrary('Actions::TransitionAction::accepter') deriveAcceptActionUsagePayloadArgument The payloadArgument of an AcceptUsageAction is its first argument Expression . payloadArgument = argument(1) deriveAcceptActionUsagePayloadParameter The payloadParameter of an AcceptActionUsage is its first parameter. payloadParameter = if parameter->isEmpty() then null else parameter->first() endif deriveAcceptActionUsageReceiverArgument The receiverArgument of an AcceptUsageAction is its second argument Expression . receiverArgument = argument(2) validateAcceptActionUsageParameters An AcceptUsageAction must have at least two input parameters , corresponding to its payload and receiver , respectively (even if they have no FeatureValue ). (Note that the payloadParameter is an input as well as an output.) inputParameters()->size() >= 2 8.3.17.3 ActionDefinition Description An ActionDefinition is a Definition that is also a Behavior that defines an Action performed by a system or part of a system. General Classes Behavior OccurrenceDefinition Attributes Systems Modeling Language v2.0, Part 1 311 -/action : ActionUsage [0..*] {subsets step, usage, ordered} The ActionUsages that are steps in this ActionDefinition , which define the actions that specify the behavior of the ActionDefinition . Operations None. Constraints checkActionDefinitionSpecialization An ActionDefinition must directly or indirectly specialize the ActionDefinition Actions::Action from the Systems Model Library. specializesFromLibrary('Actions::Action') deriveActionDefinitionAction The actions of a ActionDefinition are those of its usages that are ActionUsages . action = usage->selectByKind(ActionUsage) 8.3.17.4 ActionUsage Description An ActionUsage is a Usage that is also a Step , and, so, is typed by a Behavior . Nominally, if the type is an ActionDefinition , an ActionUsage is a Usage of that ActionDefinition within a system. However, other kinds of kernel Behaviors are also allowed, to permit use of Behaviors from the Kernel Model Libraries. General Classes Step OccurrenceUsage Attributes /actionDefinition : Behavior [0..*] {redefines behavior, occurrenceDefinition, ordered} The Behaviors that are the types of this ActionUsage . Nominally, these would be ActionDefinitions , but other kinds of Kernel Behaviors are also allowed, to permit use of Behaviors from the Kernel Model Libraries. Operations argument(i : Integer) : Expression [0..1] Return the i -th argument Expression of an ActionUsage , defined as the value Expression of the FeatureValue of the i -th owned input parameter of the ActionUsage . Return null if the ActionUsage has less than i owned input parameters or the i -th owned input parameter has no FeatureValue . body: if inputParameter(i) = null then null else let featureValue : Sequence(FeatureValue) = inputParameter(i). ownedMembership->select(oclIsKindOf(FeatureValue)) in if featureValue->isEmpty() then null 312 Systems Modeling Language v2.0, Part 1 -else featureValue->at(1).value endif endif inputParameter(i : Integer) : Feature [0..1] Return the i -th owned input parameter of the ActionUsage . Return null if the ActionUsage has less than i owned input parameters . body: if inputParameters()->size() < i then null else inputParameters()->at(i) endif inputParameters() : Feature [0..*] Return the owned input parameters of this ActionUsage . body: input->select(f | f.owner = self) isSubactionUsage() : Boolean Check if this ActionUsage is composite and has an owningType that is an ActionDefinition or ActionUsage but is not the entryAction or exitAction of a StateDefinition or StateUsage . If so, then it represents an Action that is a subaction of another Action . body: isComposite and owningType <> null and (owningType.oclIsKindOf(ActionDefinition) or owningType.oclIsKindOf(ActionUsage)) and (owningFeatureMembership.oclIsKindOf(StateSubactionMembership) implies owningFeatureMembership.oclAsType(StateSubactionMembership).kind = StateSubactionKind::do) Constraints checkActionUsageOwnedActionSpecialization A composite ActionUsage whose owningType is PartDefinition or PartUsage must directly or indirectly specialize the ActionUsage Parts::Part::ownedActions from the Systems Model Library. isComposite and owningType <> null and (owningType.oclIsKindOf(PartDefinition) or owningType.oclIsKindOf(PartUsage)) implies specializesFromLibrary('Parts::Part::ownedActions') checkActionUsageSpecialization An ActionUsage must directly or indirectly specialize the ActionUsage Actions::actions from the Systems Model Library. specializesFromLibrary('Actions::actions') checkActionUsageStateActionRedefinition An ActionUsage that is the entry , do , or exit Action of a StateDefinition or StateUsage must redefine the entryAction , doAction , or exitAction feature , respectively, of the StateDefinition States::StateAction from the Systems Model Library. Systems Modeling Language v2.0, Part 1 313 -owningFeatureMembership <> null and owningFeatureMembership.oclIsKindOf(StateSubactionMembership) implies let kind : StateSubactionKind = owningFeatureMembership.oclAsType(StateSubactionMembership).kind in if kind = StateSubactionKind::entry then redefinesFromLibrary('States::StateAction::entryAction') else if kind = StateSubactionKind::do then redefinesFromLibrary('States::StateAction::doAction') else redefinesFromLibrary('States::StateAction::exitAction') endif endif checkActionUsageSubactionSpecialization A composite ActionUsage that is a subaction usage must directly or indirectly specialize the ActionUsage Actions::Action::subactions from the Systems Model Library. isSubactionUsage() implies specializesFromLibrary('Actions::Action::subactions') 8.3.17.5 AssignmentActionUsage Description An AssignmentActionUsage is an ActionUsage that is defined, directly or indirectly, by the ActionDefinition AssignmentAction from the Systems Model Library. It specifies that the value of the referent Feature , relative to the target given by the result of the targetArgument Expression , should be set to the result of the valueExpression . General Classes ActionUsage Attributes /referent : Feature {subsets member} The Feature whose value is to be set. /targetArgument : Expression [0..1] The Expression whose value is an occurrence in the domain of the referent Feature , for which the value of the referent will be set to the result of the valueExpression by this AssignmentActionUsage . /valueExpression : Expression [0..1] The Expression whose result is to be assigned to the referent Feature . Operations None. Constraints checkAssignmentActionUsageAccessedFeatureRedefinition The first ownedFeature of the first ownedFeature of the first parameter of an AssignmentActionUsage must redefine AssignmentAction::target::startingAt::accessedFeature . 314 Systems Modeling Language v2.0, Part 1 -let targetParameter : Feature = inputParameter(1) in targetParameter <> null and targetParameter.ownedFeature->notEmpty() and targetParameter->first().ownedFeature->notEmpty() and targetParameter->first().ownedFeature->first(). redefines('AssigmentAction::target::startingAt::accessedFeature') checkAssignmentActionUsageReferentRedefinition The first ownedFeature of the first ownedFeature of the first parameter of an AssignmentActionUsage must redefine the referent of the AssignmentActionUsage . let targetParameter : Feature = inputParameter(1) in targetParameter <> null and targetParameter.ownedFeature->notEmpty() and targetParameter->first().ownedFeature->notEmpty() and targetParameter->first().ownedFeature->first().redefines(referent) checkAssignmentActionUsageSpecialization An AssignmentActionUsage must directly or indirectly specialize the ActionUsage Actions::assignmentActions from the Systems Model Library. specializesFromLibrary('Actions::assignmentActions') checkAssignmentActionUsageStartingAtRedefinition The first ownedFeature of the first parameter of an AssignmentActionUsage must redefine AssignmentAction::target::startingAt . let targetParameter : Feature = inputParameter(1) in targetParameter <> null and targetParameter.ownedFeature->notEmpty() and targetParameter.ownedFeature->first(). redefines('AssignmentAction::target::startingAt') checkAssignmentActionUsageSubactionSpecialization A composite AssignmentActionUsage that is a subaction usage must directly or indirectly specialize the ActionUsage Actions::Action::assignments from the Systems Model Library. isSubactionUsage() implies specializesFromLibrary('Actions::Action::assignments') deriveAssignmentActionUsageReferent The referent of an AssignmentActionUsage is the first Feature that is the memberElement of a ownedMembership that is not a FeatureMembership . referent = let unownedFeatures : Sequence(Feature) = ownedMembership-> reject(oclIsKindOf(FeatureMembership)).memberElement-> selectByKind(Feature) in if unownedFeatures->isEmpty() then null else unownedFeatures->first().oclAsType(Feature) endif deriveAssignmentActionUsageValueExpression Systems Modeling Language v2.0, Part 1 315 -The valueExpression of a AssignmentActionUsage is its second argument Expression . valueExpression = argument(2) deriveAssignmentUsageTargetArgument The targetArgument of a AssignmentActionUsage is its first argument Expression . targetArgument = argument(1) validateAssignmentActionUsage The featureTarget of the referent of an AssignmentActionUsage must be able to have time-varying values. referent <> null implies referent.featureTarget.mayTimeVary validateAssignmentActionUsageReferent An AssignmentActionUsage must have an ownedMembership that is not an OwningMembership and whose memberElement is a Feature . ownedMembership->exists( not oclIsKindOf(OwningMembership) and memberElement.oclIsKindOf(Feature)) 8.3.17.6 ControlNode Description A ControlNode is an ActionUsage that does not have any inherent behavior but provides constraints on incoming and outgoing Successions that are used to control other Actions . A ControlNode must be a composite owned usage of an ActionDefinition or ActionUsage . General Classes ActionUsage Attributes None. Operations multiplicityHasBounds(mult : Multiplicity, lower : Integer, upper : UnlimitedNatural) : Boolean Check that the given Multiplicity has lowerBound and upperBound expressions that are model-level evaluable to the given lower and upper values. body: mult <> null and if mult.oclIsKindOf(MultiplicityRange) then mult.oclAsType(MultiplicityRange).hasBounds(lower, upper) else mult.allSuperTypes()->exists( oclisKindOf(MultiplicityRange) and oclAsType(MultiplicityRange).hasBounds(lower, upper) endif Constraints 316 Systems Modeling Language v2.0, Part 1 -checkControlNodeSpecialization A ControlNode must directly or indirectly specialize the ActionUsage Actions::Action::control from the Systems Model Library. specializesFromLibrary('Action::Action::controls') validateControlNodeIncomingSuccessions All incoming Successions to a ControlNode must have a target multiplicity of 1..1 . targetConnector->selectByKind(Succession)-> collect(connectorEnd->at(2).multiplicity)-> forAll(targetMult | multiplicityHasBounds(targetMult, 1, 1)) validateControlNodeIsComposite A ControlNode must be composite. isComposite validateControlNodeOutgoingSuccessions All outgoing Successions from a ControlNode must have a source multiplicity of 1..1 . sourceConnector->selectByKind(Succession)-> collect(connectorEnd->at(1).multiplicity)-> forAll(sourceMult | multiplicityHasBounds(sourceMult, 1, 1)) validateControlNodeOwningType The owningType of a ControlNode must be an ActionDefinition or ActionUsage . owningType <> null and (owningType.oclIsKindOf(ActionDefinition) or owningType.oclIsKindOf(ActionUsage)) 8.3.17.7 DecisionNode Description A DecisionNode is a ControlNode that makes a selection from its outgoing Successions . General Classes ControlNode Attributes None. Operations None. Constraints Systems Modeling Language v2.0, Part 1 317 -checkDecisionNodeOutgoingSuccessionSpecialization All outgoing Successions from a DecisionNode must subset the inherited outgoingHBLink feature of the DecisionNode . sourceConnector->selectByKind(Succession)-> forAll(subsetsChain(self, resolveGlobal('ControlPerformances::MergePerformance::outgoingHBLink'))) checkDecisionNodeSpecialization A DecisionNode must directly or indirectly specialize the ActionUsage Actions::Action::decisions from the Systems Model Library. specializesFromLibrary('Actions::Action::decisions') validateDecisionNodeIncomingSuccessions A DecisionNode may have at most one incoming Succession . targetConnector->selectByKind(Succession)->size() <= 1 validateDecisionNodeOutgoingSuccessions All outgoing Successions from a DecisionNode must have a target multiplicity of 0..1 . sourceConnector->selectAsKind(Succession)-> collect(connectorEnd->at(2))-> forAll(targetMult | multiplicityHasBounds(targetMult, 0, 1)) 8.3.17.8 ForkNode Description A ForkNode is a ControlNode that must be followed by successor Actions as given by all its outgoing Successions . General Classes ControlNode Attributes None. Operations None. Constraints checkForkNodeSpecialization A ForkNode must directly or indirectly specialize the ActionUsage Actions::Action::forks from the Systems Model Library. 318 Systems Modeling Language v2.0, Part 1 -specializesFromLibrary('Actions::Action::forks') validateForkNodeIncomingSuccessions A ForkNode may have at most one incoming Succession . targetConnector->selectByKind(Succession)->size() <= 1 8.3.17.9 ForLoopActionUsage Description A ForLoopActionUsage is a LoopActionUsage that specifies that its bodyAction ActionUsage should be performed once for each value, in order, from the sequence of values obtained as the result of the seqArgument Expression , with the loopVariable set to the value for each iteration. General Classes LoopActionUsage Attributes /loopVariable : ReferenceUsage The ownedFeature of this ForLoopActionUsage that acts as the loop variable, which is assigned the successive values of the input sequence on each iteration. It is the ownedFeature that redefines ForLoopAction::var . /seqArgument : Expression The Expression whose result provides the sequence of values to which the loopVariable is set for each iterative performance of the bodyAction . It is the Expression whose result is bound to the seq input parameter of this ForLoopActionUsage . Operations None. Constraints checkForLoopActionUsageSpecialization A ForLoopActionUsage must directly or indirectly specialize the ActionUsage Actions::forLoopActions from the Systems Model Library. specializesFromLibrary('Actions::forLoopActions') checkForLoopActionUsageSubactionSpecialization A composite ForLoopActionUsage that is a subaction usage must directly or indirectly specialize the ActionUsage Actions::Action::forLoops from the Systems Model Library. isSubactionUsage() implies specializesFromLibrary('Actions::Action::forLoops') checkForLoopActionUsageVarRedefinition Systems Modeling Language v2.0, Part 1 319 -The loopVariable of a ForLoopActionUsage must redefine the ActionUsage Actions::ForLoopAction::var . loopVariable <> null and loopVariable.redefinesFromLibrary('Actions::ForLoopAction::var') deriveForLoopActionUsageLoopVariable The loopVariable of a ForLoopActionUsage is its first ownedFeature , which must be a ReferenceUsage . loopVariable = if ownedFeature->isEmpty() or not ownedFeature->first().oclIsKindOf(ReferenceUsage) then null else ownedFeature->first().oclAsType(ReferenceUsage) endif deriveForLoopActionUsageSeqArgument The seqArgument of a ForLoopActionUsage is its first argument Expression . seqArgument = argument(1) validateForLoopActionUsageLoopVariable The first ownedFeature of a ForLoopActionUsage must be a ReferenceUsage . ownedFeature->notEmpty() and ownedFeature->at(1).oclIsKindOf(ReferenceUsage) validateForLoopActionUsageParameters A ForLoopActionUsage must have two owned input parameters . inputParameters()->size() = 2 8.3.17.10 IfActionUsage Description An IfActionUsage is an ActionUsage that specifies that the thenAction ActionUsage should be performed if the result of the ifArgument Expression is true. It may also optionally specify an elseAction ActionUsage that is performed if the result of the ifArgument is false. General Classes ActionUsage Attributes /elseAction : ActionUsage [0..1] The ActionUsage that is to be performed if the result of the ifArgument is false. It is the (optional) third parameter of the IfActionUsage . /ifArgument : Expression 320 Systems Modeling Language v2.0, Part 1 -The Expression whose result determines whether the thenAction or (optionally) the elseAction is performed. It is the first parameter of the IfActionUsage. /thenAction : ActionUsage The ActionUsage that is to be performed if the result of the ifArgument is true. It is the second parameter of the IfActionUsage. Operations None. Constraints checkIfActionUsageSpecialization A IfActionUsage must directly or indirectly specialize the ActionUsage Actions::ifThenActions from the Systems Model Library. If it has an elseAction , then it must directly or indirectly specialize Actions::ifThenElseActions if elseAction = null then specializesFromLibrary('Actions::ifThenActions') else specializesFromLibrary('Actions::ifThenElseActions') endif checkIfActionUsageSubactionSpecialization A composite IfActionUsage that is a subaction usage must directly or indirectly specialize the ActionUsage Actions::Action::ifSubactions from the Systems Model Library. isSubactionUsage() implies specializesFromLibrary('Actions::Action::ifSubactions') deriveIfActionUsageElseAction The elseAction of an ifActionUsage is its third parameter , if there is one, which must then be an ActionUsage . elseAction = let parameter : Feature = inputParameter(3) in if parameter <> null and parameter.oclIsKindOf(ActionUsage) then parameter.oclAsType(ActionUsage) else null endif deriveIfActionUsageIfArgument The ifArgument of an ifActionUsage is its first parameter , which must be an Expression . ifArgument = let parameter : Feature = inputParameter(1) in if parameter <> null and parameter.oclIsKindOf(Expression) then parameter.oclAsType(Expression) else null endif Systems Modeling Language v2.0, Part 1 321 -deriveIfActionUsageThenAction The thenAction of an ifActionUsage is its second parameter , which must be an ActionUsage . thenAction = let parameter : Feature = inputParameter(2) in if parameter <> null and parameter.oclIsKindOf(ActionUsage) then parameter.oclAsType(ActionUsage) else null endif validateIfActionUsageParameters An IfActionUsage must have at least two owned input parameters . inputParameters()->size() >= 2 8.3.17.11 JoinNode Description A JoinNode is a ControlNode that waits for the completion of all the predecessor Actions given by incoming Successions . General Classes ControlNode Attributes None. Operations None. Constraints checkJoinNodeSpecialization A JoinNode must directly or indirectly specialize the ActionUsage Actions::Action::joins from the Systems Model Library. specializesFromLibrary('Actions::Action::join') validateJoinNodeOutgoingSuccessions A JoinNode may have at most one outgoing Succession . sourceConnector->selectByKind(Succession)->size() <= 1 8.3.17.12 LoopActionUsage Description 322 Systems Modeling Language v2.0, Part 1 -A LoopActionUsage is an ActionUsage that specifies that its bodyAction should be performed repeatedly. Its subclasses WhileLoopActionUsage and ForLoopActionUsage provide different ways to determine how many times the bodyAction should be performed. General Classes ActionUsage Attributes /bodyAction : ActionUsage The ActionUsage to be performed repeatedly by the LoopActionUsage . It is the second parameter of the LoopActionUsage . Operations None. Constraints deriveLoopActionUsageBodyAction The bodyAction of a LoopActionUsage is its second input parameter , which must be an Action . bodyAction = let parameter : Feature = inputParameter(2) in if parameter <> null and parameter.oclIsKindOf(Action) then parameter.oclAsType(Action) else null endif 8.3.17.13 MergeNode Description A MergeNode is a ControlNode that asserts the merging of its incoming Successions . A MergeNode may have at most one outgoing Successions . General Classes ControlNode Attributes None. Operations None. Constraints checkMergeNodeIncomingSuccessionSpecialization Systems Modeling Language v2.0, Part 1 323 -All incoming Successions to a MergeNode must subset the inherited incomingHBLink feature of the MergeNode . targetConnector->selectByKind(Succession)-> forAll(subsetsChain(self, resolveGlobal('ControlPerformances::MergePerformance::incomingHBLink'))) checkMergeNodeSpecialization A MergeNode must directly or indirectly specialize the ActionUsage Actions::Action::merges from the Systems Model Library. specializesFromLibrary('Actions::Action::merges') validateMergeNodeIncomingSuccessions All incoming Successions to a MergeNode must have a source multiplicity of 0..1 . targetConnector->selectByKind(Succession)-> collect(connectorEnd->at(1))-> forAll(sourceMult | multiplicityHasBounds(sourceMult, 0, 1)) validateMergeNodeOutgoingSuccessions A MergeNode may have at most one outgoing Succession . sourceConnector->selectAsKind(Succession)->size() <= 1 8.3.17.14 PerformActionUsage Description A PerformActionUsage is an ActionUsage that represents the performance of an ActionUsage . Unless it is the PerformActionUsage itself, the ActionUsage to be performed is related to the PerformActionUsage by a ReferenceSubsetting relationship. A PerformActionUsage is also an EventOccurrenceUsage , with its performedAction as the eventOccurrence . General Classes ActionUsage EventOccurrenceUsage Attributes /performedAction : ActionUsage {redefines eventOccurrence} The ActionUsage to be performed by this PerformedActionUsage . It is the eventOccurrence of the PerformActionUsage considered as an EventOccurrenceUsage , which must be an ActionUsage . Operations namingFeature() : Feature [0..1] {redefines namingFeature} The naming Feature of a PerformActionUsage is its performedAction , if this is different than the PerformActionUsage . If the PerformActionUsage is its own performedAction , then the naming Feature is the same as the usual default for a Usage . 324 Systems Modeling Language v2.0, Part 1 -body: if performedAction <> self then performedAction else self.oclAsType(Usage).namingFeature() endif Constraints checkPerformActionUsageSpecialization If a PerformActionUsage has an owningType that is a PartDefinition or PartUsage , then it must directly or indirectly specialize the ActionUsage Parts::Part::performedActions . owningType <> null and (owningType.oclIsKindOf(PartDefinition) or owningType.oclIsKindOf(PartUsage)) implies specializesFromLibrary('Parts::Part::performedActions') validatePerformActionUsageReference If a PerformActionUsage has an ownedReferenceSubsetting , then the featureTarget of the referencedFeature must be an ActionUsage . referencedFeatureTarget() <> null implies referencedFeatureTarget().oclIsKindOf(ActionUsage) 8.3.17.15 SendActionUsage Description A SendActionUsage is an ActionUsage that specifies the sending of a payload given by the result of its payloadArgument Expression via a MessageTransfer whose source is given by the result of the senderArgument Expression and whose target is given by the result of the receiverArgument Expression . If no senderArgument is provided, the default is the this context for the action. If no receiverArgument is given, then the receiver is to be determined by, e.g., outgoing Connections from the sender. General Classes ActionUsage Attributes /payloadArgument : Expression An Expression whose result is bound to the payload input parameter of this SendActionUsage . /receiverArgument : Expression [0..1] An Expression whose result is bound to the receiver input parameter of this SendActionUsage . /senderArgument : Expression [0..1] An Expression whose result is bound to the sender input parameter of this SendActionUsage . Operations None. Systems Modeling Language v2.0, Part 1 325 -Constraints checkSendActionUsageSpecialization A SendActionUsage must directly or indirectly specialize the ActionUsage Actions::sendActions from the Systems Model Library. specializesFromLibrary('Actions::sendActions') checkSendActionUsageSubactionSpecialization A composite SendActionUsage that is a subaction must directly or indirectly specialize the ActionUsage Actions::Action::sendSubactions from the Systems Model Library. isSubactionUsage() implies specializesFromLibrary('Actions::Action::acceptSubactions') deriveSendActionUsagePayloadArgument The payloadArgument of a SendActionUsage is its first argument Expression . payloadArgument = argument(1) deriveSendActionUsageReceiverArgument The receiverArgument of a SendActionUsage is its third argument Expression . receiverArgument = argument(3) deriveSendActionUsageSenderArgument The senderArgument of a SendActionUsage is its second argument Expression . senderArgument = argument(2) validateSendActionParameters A SendActionUsage must have at least three owned input parameters , corresponding to its payload , sender and receiver , respectively (whether or not they have FeatureValues ). inputParameters()->size() >= 3 8.3.17.16 TerminateActionUsage Description A TerminateActionUsage is an ActionUsage that directly or indirectly specializes the ActionDefinition TerminateAction from the Systems Model Library, which causes a given terminatedOccurrence to end during its performance. By default, the terminatedOccurrence is the featuring instance ( that ) of the performance of the TerminateActionUsage , generally the performance of its immediately containing ActionDefinition or ActionUsage . General Classes ActionUsage Attributes 326 Systems Modeling Language v2.0, Part 1 -/terminatedOccurrenceArgument : Expression [0..1] The Expression that is the featureValue of the terminateOccurrence parameter of this TerminateActionUsage Operations None. Constraints checkTerminateActionUsageSpecialization A TerminateActionUsage must directly or indirectly specialize the ActionUsage Actions::terminateActions from the Systems Modeling Library. specializesFromLibrary('Actions::terminateActions') checkTerminateActionUsageSubactionSpecialization A composite TerminateActionUsage that is a subaction must must directly or indirectly specialize the ActionUsage Actions::Action::terminateSubactions from the Systems Modeling Library. isSubactionUsage() implies specializesFromLibrary('Actions::Action::terminateSubactions') deriveTerminateActionUsageTerminatedOccurrenceArgument The terminatedOccurrenceArgument of a TerminateActionUsage is its first argument. terminatedOccurrenceArgument = argument(1) 8.3.17.17 TriggerInvocationExpression Description A TriggerInvocationExpression is an InvocationExpression that invokes one of the trigger Functions from the Kernel Semantic Library Triggers package, as indicated by its kind . General Classes InvocationExpression Attributes kind : TriggerKind Indicates which of the Functions from the Triggers model in the Kernel Semantic Library is to be invoked by this TriggerInvocationExpression . Operations instantiatedType() : Type {redefines instantiatedType} Return one of the Functions TriggerWhen , TriggerAt or TriggerAfter , from the Kernel Semantic Library Triggers package, depending on whether the kind of this TriggerInvocationExpression is when , at or after , respectively. Systems Modeling Language v2.0, Part 1 327 -body: resolveGlobal( if kind = TriggerKind::when then 'Triggers::TriggerWhen' else if kind = TriggerKind::at then 'Triggers::TriggerAt' else 'Triggers::TriggerAfter' endif endif ).memberElement.oclAsType(Type) Constraints validateTriggerInvocationExpressionAfterArgument If a TriggerInvocationExpression has kind = after , then it must have an argument Expression with a result that conforms to the type Quantities::ScalarQuantityValue and a feature that directly or indirectly redefines Quantities::TensorQuantityValue::mRef and directly or indirectly specializes ISQBase::DurationUnit . kind = TriggerKind::after implies argument->notEmpty() and argument->at(1).result.specializesFromLibrary('Quantities::ScalarQuantityValue') and let mRef : Element = resolveGlobal('Quantities::TensorQuantityValue::mRef').ownedMemberElement in argument->at(1).result.feature-> select(ownedRedefinition.redefinedFeature-> closure(ownedRedefinition.redefinedFeature)-> includes(mRef))-> exists(specializesFromLibrary('ISQBase::DurationUnit')) validateTriggerInvocationExpressionAtArgument If a TriggerInvocationExpression has kind = at , then it must have an argument Expression with a result that conforms to the type Time::TimeInstantValue . kind = TriggerKind::at implies argument->notEmpty() and argument->at(1).result.specializesFromLibrary('Time::TimeInstantValue') validateTriggerInvocationExpressionWhenArgument If a TriggerInvocationExpression has kind = when , then it must have an argument that is a FeatureReferenceExpression whose referent is an Expression with a result that conforms to the type ScalarValues::Boolean . kind = TriggerKind::when implies argument->notEmpty() and argument->at(1).oclIsKindOf(FeatureReferenceExpression) and let referent : Feature = argument->at(1).oclAsType(FeatureReferenceExpression).referent in referent.oclIsKindOf(Expression) and referent.oclAsType(Expression).result.specializesFromLibrary('ScalarValues::Boolean') 8.3.17.18 TriggerKind Description TriggerKind enumerates the kinds of triggers that can be represented by a TriggerInvocationExpression . 328 Systems Modeling Language v2.0, Part 1 -General Classes None. Literal Values after Indicates a relative time trigger, corresponding to the TriggerAfter Function from the Triggers model in the Kernel Semantic Library. at Indicates an absolute time trigger, corresponding to the TriggerAt Function from the Triggers model in the Kernel Semantic Library. when Indicates a change trigger, corresponding to the TriggerWhen Function from the Triggers model in the Kernel Semantic Library. 8.3.17.19 WhileLoopActionUsage Description A WhileLoopActionUsage is a LoopActionUsage that specifies that the bodyAction ActionUsage should be performed repeatedly while the result of the whileArgument Expression is true or until the result of the untilArgument Expression (if provided) is true. The whileArgument Expression is evaluated before each (possible) performance of the bodyAction , and the untilArgument Expression is evaluated after each performance of the bodyAction . General Classes LoopActionUsage Attributes /untilArgument : Expression [0..1] The Expression whose result, if false, determines that the bodyAction should continue to be performed. It is the (optional) third owned parameter of the WhileLoopActionUsage . /whileArgument : Expression The Expression whose result, if true, determines that the bodyAction should continue to be performed. It is the first owned parameter of the WhileLoopActionUsage . Operations None. Constraints checkWhileLoopActionUsageSpecialization Systems Modeling Language v2.0, Part 1 329 -A WhileLoopActionUsage must directly or indirectly specialize the ActionUsage Actions::whileLoopActions from the Systems Model Library. specializesFromLibrary('Actions::whileLoopActions') checkWhileLoopActionUsageSubactionSpecialization A composite WhileLoopActionUsage that is a subaction usage must directly or indirectly specialize the ActionUsage Actions::Action::whileLoops from the Systems Model Library. isSubactionUsage() implies specializesFromLibrary('Actions::Action::whileLoops') deriveWhileLoopActionUsageUntilArgument The whileArgument of a WhileLoopActionUsage is its third input parameter , which, if it exists, must be an Expression . untilArgument = let parameter : Feature = inputParameter(3) in if parameter <> null and parameter.oclIsKindOf(Expression) then parameter.oclAsType(Expression) else null endif deriveWhileLoopActionUsageWhileArgument The whileArgument of a WhileLoopActionUsage is its first input parameter , which must be an Expression . whileArgument = let parameter : Feature = inputParameter(1) in if parameter <> null and parameter.oclIsKindOf(Expression) then parameter.oclAsType(Expression) else null endif validateWhileLoopActionUsage A WhileLoopActionUsage must have at least two owned input parameters . inputParameters()->size() >= 2 330 Systems Modeling Language v2.0, Part 1 -8.3.18 States Abstract Syntax 8.3.18.1 Overview {subsets actionOwningDefinition} +/stateOwningDefinition 0..1 +/stateOwningUsage Usage Definition 0..1 {redefines actionOwningUsage} OccurrenceDefinition OccurrenceUsage +/entryAction +/entryAction Behavior ActionDefinition ActionUsage 0..1 0..1 +/doAction +/doAction +/stateDefinition 0..* 0..1 0..1 {redefines actionDefinition, +/exitAction +/exitAction ordered} 0..1 0..1 StateDefinition StateUsage +/enteredStateDefinition +/exitedState +isParallel : Boolean = false +isParallel : Boolean = false 0..* 0..* +/activeState +/activeStateDefintion 0..* 0..* +/enteredState +/exitedStateDefinition 0..* 0..* +/nestedState +/featuringStateDefinition +/state 0..* 0..* 0..* {subsets nestedAction, {subsets featuringBehavior} {subsets action, ordered} ordered} +/definedState +/ownedState 0..* 0..* {subsets definedAction} {subsets ownedAction, ordered} Figure 30. State Definition and Usage FeatureMembership «enumeration» «enumeration» StateSubactionKind TransitionFeatureKind entry trigger StateSubactionMembership TransitionFeatureMembership do guard +kind : StateSubactionKind +kind : TransitionFeatureKind exit effect +/stateSubactionMembership 0..1 +/transitionFeatureMembership 0..1 {subsets owningFeatureMembership} {subsets owningFeatureMembership} {redefines ownedMemberFeature} {redefines ownedMemberFeature} +/action 1 +/transitionFeature 1 ActionUsage Step Figure 31. State Membership Systems Modeling Language v2.0, Part 1 331 -+/exhibitedState PerformActionUsage StateUsage 1 {redefines performedAction} +/exhibitingState ExhibitStateUsage 0..* {subsets performingAction} Figure 32. Exhibited States +/transitionOwningUsage Definition Usage 0..1 0..1 +/transitionOwningDefinition {subsets owningUsage} {subsets owningDefinition} OccurrenceUsage +/source ActionUsage 1 +/target 1 +/effectAction 0..* {subsets feature} +/activeTransition +/ownedTransition TransitionUsage 0..1 0..* {subsets owningType} {subsets ownedUsage} +/incomingTransition +/triggerAction +/triggeredTransition AcceptActionUsage 0..* 0..* 0..1 {subsets ownedFeature} {subsets owningType} +/outgoingTransition +/guardExpression +/guardedTransition Expression 0..* 0..1 0..* {subsets owningType} {subsets ownedFeature} +/nestedTransition +/succession +/linkedTransition Succession 0..* 1 0..1 {subsets nestedUsage} {subsets ownedMember} {subsets owningNamespace} Figure 33. Transition Usage 8.3.18.2 ExhibitStateUsage Description An ExhibitStateUsage is a StateUsage that represents the exhibiting of a StateUsage . Unless it is the StateUsage itself, the StateUsage to be exhibited is related to the ExhibitStateUsage by a ReferenceSubsetting Relationship . An ExhibitStateUsage is also a PerformActionUsage , with its exhibitedState as the performedAction . 332 Systems Modeling Language v2.0, Part 1 -General Classes PerformActionUsage StateUsage Attributes /exhibitedState : StateUsage {redefines performedAction} The StateUsage to be exhibited by the ExhibitStateUsage . It is the performedAction of the ExhibitStateUsage considered as a PerformActionUsage , which must be a StateUsage . Operations None. Constraints checkExhibitStateUsageSpecialization If an ExhibitStateUsage has an owningType that is a PartDefinition or PartUsage , then it must directly or indirectly specialize the StateUsage Parts::Part::exhibitedStates . owningType <> null and (owningType.oclIsKindOf(PartDefinition) or owningType.oclIsKindOf(PartUsage)) implies specializesFromLibrary('Parts::Part::exhibitedStates') validateExhibitStateUsageReference If an ExhibitStateUsage has an ownedReferenceSubsetting , then the featureTarget of the referencedFeature must be a StateUsage . referencedFeatureTarget() <> null implies referencedFeatureTarget().oclIsKindOf(StateUsage) 8.3.18.3 StateSubactionKind Description A StateSubactionKind indicates whether the action of a StateSubactionMembership is an entry, do or exit action. General Classes None. Literal Values do Indicates that the action of a StateSubactionMembership is a doAction . entry Indicates that the action of a StateSubactionMembership is an entryAction . Systems Modeling Language v2.0, Part 1 333 -exit Indicates that the action of a StateSubactionMembership is an exitAction . 8.3.18.4 StateSubactionMembership Description A StateSubactionMembership is a FeatureMembership for an entry, do or exit ActionUsage of a StateDefinition or StateUsage. General Classes FeatureMembership Attributes /action : ActionUsage {redefines ownedMemberFeature} The ActionUsage that is the ownedMemberFeature of this StateSubactionMembership . kind : StateSubactionKind Whether this StateSubactionMembership is for an entry, do or exit ActionUsage. Operations None. Constraints validateStateSubactionMembershipOwningType The owningType of a StateSubactionMembership must be a StateDefinition or a StateUsage . owningType.oclIsKindOf(StateDefinition) or owningType.oclIsKindOf(StateUsage) 8.3.18.5 StateDefinition Description A StateDefinition is the Definition of the Behavior of a system or part of a system in a certain state condition. A StateDefinition may be related to up to three of its ownedFeatures by StateBehaviorMembership Relationships , all of different kinds , corresponding to the entry, do and exit actions of the StateDefinition . General Classes ActionDefinition Attributes /doAction : ActionUsage [0..1] 334 Systems Modeling Language v2.0, Part 1 -The ActionUsage of this StateDefinition to be performed while in the state defined by the StateDefinition . It is the owned ActionUsage related to the StateDefinition by a StateSubactionMembership with kind = do . /entryAction : ActionUsage [0..1] The ActionUsage of this StateDefinition to be performed on entry to the state defined by the StateDefinition . It is the owned ActionUsage related to the StateDefinition by a StateSubactionMembership with kind = entry . /exitAction : ActionUsage [0..1] The ActionUsage of this StateDefinition to be performed on exit to the state defined by the StateDefinition . It is the owned ActionUsage related to the StateDefinition by a StateSubactionMembership with kind = exit . isParallel : Boolean Whether the ownedStates of this StateDefinition are to all be performed in parallel. If true, none of the ownedActions (which includes ownedStates ) may have any incoming or outgoing Transitions . If false, only one ownedState may be performed at a time. /state : StateUsage [0..*] {subsets action, ordered} The StateUsages , which are actions in the StateDefinition , that specify the discrete states in the behavior defined by the StateDefinition . Operations None. Constraints checkStateDefinitionSpecialization A StateDefinition must directly or indirectly specialize the StateDefinition States::StateAction from the Systems Model Library. specializesFromLibrary('States::StateAction') deriveStateDefinitionDoAction The doAction of a StateDefinition is the action of the owned StateSubactionMembership with kind = do . doAction = let doMemberships : Sequence(StateSubactionMembership) = ownedMembership-> selectByKind(StateSubactionMembership)-> select(kind = StateSubactionKind::do) in if doMemberships->isEmpty() then null else doMemberships->at(1) endif deriveStateDefinitionEntryAction Systems Modeling Language v2.0, Part 1 335 -The entryAction of a StateDefinition is the action of the owned StateSubactionMembership with kind = entry . entryAction = let entryMemberships : Sequence(StateSubactionMembership) = ownedMembership-> selectByKind(StateSubactionMembership)-> select(kind = StateSubactionKind::entry) in if entryMemberships->isEmpty() then null else entryMemberships->at(1) endif deriveStateDefinitionExitAction The exitAction of a StateDefinition is the action of the owned StateSubactionMembership with kind = exit . exitAction = let exitMemberships : Sequence(StateSubactionMembership) = ownedMembership-> selectByKind(StateSubactionMembership)-> select(kind = StateSubactionKind::exit) in if exitMemberships->isEmpty() then null else exitMemberships->at(1) endif deriveStateDefinitionState The states of a StateDefinition are those of its actions that are StateUsages . state = action->selectByKind(StateUsage) validateStateDefinitionParallelSubactions If a StateDefinition is parallel, then its ownedActions (which includes its ownedStates ) must not have any incomingTransitions or outgoingTransitions . isParallel implies ownedAction.incomingTransition->isEmpty() and ownedAction.outgoingTransition->isEmpty() validateStateDefinitionStateSubactionKind A StateDefinition must not have more than one owned StateSubactionMembership of each kind . ownedMembership-> selectByKind(StateSubactionMembership)-> isUnique(kind) 8.3.18.6 StateUsage Description A StateUsage is an ActionUsage that is nominally the Usage of a StateDefinition . However, other kinds of kernel Behaviors are also allowed as types , to permit use of Behaviors A StateUsage may be related to up to three of its ownedFeatures by StateSubactionMembership Relationships , all of different kinds , corresponding to the entry, do and exit actions of the StateUsage . 336 Systems Modeling Language v2.0, Part 1 -General Classes ActionUsage Attributes /doAction : ActionUsage [0..1] The ActionUsage of this StateUsage to be performed while in the state defined by the StateDefinition . It is the owned ActionUsage related to the StateUsage by a StateSubactionMembership with kind = do . /entryAction : ActionUsage [0..1] The ActionUsage of this StateUsage to be performed on entry to the state defined by the StateDefinition . It is the owned ActionUsage related to the StateUsage by a StateSubactionMembership with kind = entry . /exitAction : ActionUsage [0..1] The ActionUsage of this StateUsage to be performed on exit to the state defined by the StateDefinition . It is the owned ActionUsage related to the StateUsage by a StateSubactionMembership with kind = exit . isParallel : Boolean Whether the nestedStates of this StateUsage are to all be performed in parallel. If true, none of the nestedActions (which include nestedStates ) may have any incoming or outgoing Transitions . If false, only one nestedState may be performed at a time. /stateDefinition : Behavior [0..*] {redefines actionDefinition, ordered} The Behaviors that are the types of this StateUsage . Nominally, these would be StateDefinitions , but kernel Behaviors are also allowed, to permit use of Behaviors from the Kernel Model Libraries. Operations isSubstateUsage(isParallel : Boolean) : Boolean Check if this StateUsage is composite and has an owningType that is a StateDefinition or StateUsage with the given value of isParallel , but is not an entryAction , doAction , or exitAction . If so, then it represents a StateAction that is a substate or exclusiveState (for isParallel = false ) of another StateAction . body: isComposite and owningType <> null and (owningType.oclIsKindOf(StateDefinition) and owningType.oclAsType(StateDefinition).isParallel = isParallel or owningType.oclIsKindOf(StateUsage) and owningType.oclAsType(StateUsage).isParallel = isParallel) and not owningFeatureMembership.oclIsKindOf(StateSubactionMembership) Constraints checkStateUsageExclusiveStateSpecialization A StateUsage that is a substate usage with a non-parallel owning StateDefinition or StateUsage must directly or indirectly specialize the StateUsage States::StateAction::exclusiveStates from the Systems Model Library. isSubstateUsage(false) implies specializesFromLibrary('States::StateAction::exclusiveStates') Systems Modeling Language v2.0, Part 1 337 -checkStateUsageOwnedStateSpecialization A composite StateUsage whose owningType is a PartDefinition or PartUsage must directly or indirectly specialize the StateUsage Parts::Part::ownedStates from the Systems Model Library. isComposite and owningType <> null and (owningType.oclIsKindOf(PartDefinition) or owningType.oclIsKindOf(PartUsage)) implies specializesFromLibrary('Parts::Part::ownedStates') checkStateUsageSpecialization A StateUsage must directly or indirectly specialize the StateUsage States::stateActions from the Systems Model Library. specializesFromLibrary('States::stateActions') checkStateUsageSubstateSpecialization A StateUsage that is a substate usage with a owning StateDefinition or StateUsage that is parallel must directly or indirectly specialize the StateUsage States::StateAction::substates from the Systems Model Library. isSubstateUsage(true) implies specializesFromLibrary('States::StateAction::substates') deriveStateUsageDoAction The doAction of a StateUsage is the action of the owned StateSubactionMembership with kind = do . doAction = let doMemberships : Sequence(StateSubactionMembership) = ownedMembership-> selectByKind(StateSubactionMembership)-> select(kind = StateSubactionKind::do) in if doMemberships->isEmpty() then null else doMemberships->at(1) endif deriveStateUsageEntryAction The entryAction of a StateUsage is the action of the owned StateSubactionMembership with kind = entry . entryAction = let entryMemberships : Sequence(StateSubactionMembership) = ownedMembership-> selectByKind(StateSubactionMembership)-> select(kind = StateSubactionKind::entry) in if entryMemberships->isEmpty() then null else entryMemberships->at(1) endif deriveStateUsageExitAction The exitAction of a StateUsage is the action of the owned StateSubactionMembership with kind = exit . 338 Systems Modeling Language v2.0, Part 1 -exitAction = let exitMemberships : Sequence(StateSubactionMembership) = ownedMembership-> selectByKind(StateSubactionMembership)-> select(kind = StateSubactionKind::exit) in if exitMemberships->isEmpty() then null else exitMemberships->at(1) endif validateStateUsageParallelSubactions If a StateUsage is parallel, then its nestedActions (which includes nestedStates ) must not have any incomingTransitions or outgoingTransitions . isParallel implies nestedAction.incomingTransition->isEmpty() and nestedAction.outgoingTransition->isEmpty() validateStateUsageStateSubactionKind A StateUsage must not have more than one owned StateSubactionMembership of each kind . ownedMembership-> selectByKind(StateSubactionMembership)-> isUnique(kind) 8.3.18.7 TransitionFeatureKind Description A TransitionActionKind indicates whether the transitionFeature of a TransitionFeatureMembership is a trigger, guard or effect. General Classes None. Literal Values effect Indicates that the transitionFeature of a TransitionFeatureMembership is an effectAction . guard Indicates that the transitionFeature of a TransitionFeatureMembership is a guardExpression . trigger Indicates that the transitionFeature of a TransitionFeatureMembership is a triggerAction . 8.3.18.8 TransitionFeatureMembership Description A TransitionFeatureMembership is a FeatureMembership for a trigger, guard or effect of a TransitionUsage , whose transitionFeature is a AcceptActionUsage , Boolean -valued Expression or ActionUsage , depending on its kind . Systems Modeling Language v2.0, Part 1 339 -General Classes FeatureMembership Attributes kind : TransitionFeatureKind Whether this TransitionFeatureMembership is for a trigger , guard or effect . /transitionFeature : Step {redefines ownedMemberFeature} The Step that is the ownedMemberFeature of this TransitionFeatureMembership . Operations None. Constraints validateTransitionFeatureMembershipEffectAction If the kind of a TransitionUsage is effect , then its transitionFeature must be a kind of ActionUsage . kind = TransitionFeatureKind::effect implies transitionFeature.oclIsKindOf(ActionUsage) validateTransitionFeatureMembershipGuardExpression If the kind of a TransitionUsage is guard , then its transitionFeature must be a kind of Expression whose result is a Boolean value. kind = TransitionFeatureKind::guard implies transitionFeature.oclIsKindOf(Expression) and let guard : Expression = transitionFeature.oclIsKindOf(Expression) in guard.result.specializesFromLibrary('ScalarValues::Boolean') and guard.result.multiplicity <> null and guard.result.multiplicity.hasBounds(1,1) validateTransitionFeatureMembershipOwningType The owningType of a TransitionFeatureMembership must be a TransitionUsage . owningType.oclIsKindOf(TransitionUsage) validateTransitionFeatureMembershipTriggerAction If the kind of a TransitionUsage is trigger , then its transitionFeature must be a kind of AcceptActionUsage . kind = TransitionFeatureKind::trigger implies transitionFeature.oclIsKindOf(AcceptActionUsage) 8.3.18.9 TransitionUsage Description 340 Systems Modeling Language v2.0, Part 1 -A TransitionUsage is an ActionUsage representing a triggered transition between ActionUsages or StateUsages . When triggered by a triggerAction , when its guardExpression is true, the TransitionUsage asserts that its source is exited, then its effectAction (if any) is performed, and then its target is entered. A TransitionUsage can be related to some of its ownedFeatures using TransitionFeatureMembership Relationships , corresponding to the triggerAction , guardExpression and effectAction of the TransitionUsage . General Classes ActionUsage Attributes /effectAction : ActionUsage [0..*] {subsets feature} The ActionUsages that define the effects of this TransitionUsage , which are the ownedFeatures of the TransitionUsage related to it by TransitionFeatureMemberships with kind = effect , which must all be ActionUsages . /guardExpression : Expression [0..*] {subsets ownedFeature} The Expressions that define the guards of this TransitionUsage , which are the ownedFeatures of the TransitionUsage related to it by TransitionFeatureMemberships with kind = guard , which must all be Expressions . /source : ActionUsage The source ActionUsage of this TransitionUsage , which becomes the source of the succession for the TransitionUsage . /succession : Succession {subsets ownedMember} The Succession that is the ownedFeature of this TransitionUsage , which, if the TransitionUsage is triggered, asserts the temporal ordering of the source and target . /target : ActionUsage The target ActionUsage of this TransitionUsage, which is the targetFeature of the succession for the TransitionUsage. /triggerAction : AcceptActionUsage [0..*] {subsets ownedFeature} The AcceptActionUsages that define the triggers of this TransitionUsage , which are the ownedFeatures of the TransitionUsage related to it by TransitionFeatureMemberships with kind = trigger , which must all be AcceptActionUsages . Operations sourceFeature() : Feature [0..1] Return the Feature to be used as the source of the succession of this TransitionUsage , which is the first member of the TransitionUsage that is a Feature , that is owned by the TransitionUsage via a Membership that is not a FeatureMembership , and whose featureTarget is an ActionUsage . Systems Modeling Language v2.0, Part 1 341 -body: let features : Sequence(Feature) = ownedMembership-> reject(oclIsKindOf(FeatureMembership)).memberElement-> selectByKind(Feature)-> select(featureTarget.oclIsKindOf(ActionUsage)) in if features->isEmpty() then null else features->first() endif triggerPayloadParameter() : ReferenceUsage [0..1] Return the payloadParameter of the triggerAction of this TransitionUsage , if it has one. body: if triggerAction->isEmpty() then null else triggerAction->first().payloadParameter endif Constraints checkTransitionUsageActionSpecialization A composite TransitionUsage whose owningType is an ActionDefinition or ActionUsage and whose source is not a StateUsage must directly or indirectly specialize the ActionUsage Actions::Action::decisionTransitions from the Systems Model Library. isComposite and owningType <> null and (owningType.oclIsKindOf(ActionDefinition) or owningType.oclIsKindOf(ActionUsage)) and source <> null and not source.oclIsKindOf(StateUsage) implies specializesFromLibrary('Actions::Action::decisionTransitions') checkTransitionUsagePayloadSpecialization If a TransitionUsage has a triggerAction , then the payload parameter of the TransitionUsage subsets the Feature chain of the triggerAction and its payloadParameter . triggerAction->notEmpty() implies let payloadParameter : Feature = inputParameter(2) in payloadParameter <> null and payloadParameter.subsetsChain(triggerAction->at(1), triggerPayloadParameter()) checkTransitionUsageSourceBindingConnector A TransitionUsage must have an ownedMember that is a BindingConnector between its source and its first input parameter (which redefines Actions::TransitionAction::transitionLinkSource ). ownedMember->selectByKind(BindingConnector)->exists(b | b.relatedFeatures->includes(source) and b.relatedFeatures->includes(inputParameter(1))) checkTransitionUsageSpecialization A TransitionUsage must directly or indirectly specialize the ActionUsage Actions::transitionActions from the Systems Model Library. specializesFromLibrary('Actions::transitionActions') checkTransitionUsageStateSpecialization 342 Systems Modeling Language v2.0, Part 1 -A composite TransitionUsage whose owningType is a StateDefinition or StateUsage and whose source is a StateUsage must directly or indirectly specialize the ActionUsage States::StateAction::stateTransitions from the Systems Model Library isComposite and owningType <> null and (owningType.oclIsKindOf(StateDefinition) or owningType.oclIsKindOf(StateUsage)) and source <> null and source.oclIsKindOf(StateUsage) implies specializesFromLibrary('States::StateAction::stateTransitions') checkTransitionUsageSuccessionBindingConnector A TransitionUsage must have an ownedMember that is a BindingConnector between its succession and the inherited Feature TransitionPerformances::TransitionPerformance::transitionLink . ownedMember->selectByKind(BindingConnector)->exists(b | b.relatedFeatures->includes(succession) and b.relatedFeatures->includes(resolveGlobal( 'TransitionPerformances::TransitionPerformance::transitionLink'))) checkTransitionUsageSuccessionSourceSpecialization The sourceFeature of the succession of a TransitionUsage must be the source of the TransitionUsage (i.e., the first connectorEnd of the succession must have a ReferenceSubsetting Relationship with the source ). succession.sourceFeature = source checkTransitionUsageTransitionFeatureSpecialization The triggerActions , guardExpressions , and effectActions of a TransitionUsage must specialize, respectively, the accepter , guard , and effect features of the ActionUsage Actions::TransitionActions from the Systems Model Library. triggerAction->forAll(specializesFromLibrary('Actions::TransitionAction::accepter') and guardExpression->forAll(specializesFromLibrary('Actions::TransitionAction::guard') and effectAction->forAll(specializesFromLibrary('Actions::TransitionAction::effect')) deriveTransitionUsageEffectAction The effectActions of a TransitionUsage are the transitionFeatures of the ownedFeatureMemberships of the TransitionUsage with kind = effect , which must all be ActionUsages . triggerAction = ownedFeatureMembership-> selectByKind(TransitionFeatureMembership)-> select(kind = TransitionFeatureKind::trigger).transitionFeatures-> selectByKind(AcceptActionUsage) deriveTransitionUsageGuardExpression The triggerActions of a TransitionUsage are the transitionFeatures of the ownedFeatureMemberships of the TransitionUsage with kind = trigger , which must all be Expressions . guardExpression = ownedFeatureMembership-> selectByKind(TransitionFeatureMembership)-> Systems Modeling Language v2.0, Part 1 343 -select(kind = TransitionFeatureKind::trigger).transitionFeature-> selectByKind(Expression) deriveTransitionUsageSource The source of a TransitionUsage is featureTarget of the result of sourceFeature() , which must be an ActionUsage . source = let sourceFeature : Feature = sourceFeature() in if sourceFeature = null then null else sourceFeature.featureTarget.oclAsType(ActionUsage) deriveTransitionUsageSuccession The succession of a TransitionUsage is its first ownedMember that is a Succession . succession = ownedMember->selectByKind(Succession)->at(1) deriveTransitionUsageTarget The target of a TransitionUsage is given by the featureTarget of the targetFeature of its succession , which must be an ActionUsage . target = if succession.targetFeature->isEmpty() then null else let targetFeature : Feature = succession.targetFeature->first().featureTarget in if not targetFeature.oclIsKindOf(ActionUsage) then null else targetFeature.oclAsType(ActionUsage) endif endif deriveTransitionUsageTriggerAction The triggerActions of a TransitionUsage are the transitionFeatures of the ownedFeatureMemberships of the TransitionUsage with kind = trigger , which must all be AcceptActionUsages . triggerAction = ownedFeatureMembership-> selectByKind(TransitionFeatureMembership)-> select(kind = TransitionFeatureKind::trigger).transitionFeature-> selectByKind(AcceptActionUsage) validateTransitionUsageParameters A TransitionUsage must have at least one owned input parameter and, if it has a triggerAction , it must have at least two. if triggerAction->isEmpty() then inputParameters()->size() >= 1 else inputParameters()->size() >= 2 endif validateTransitionUsageSuccession 344 Systems Modeling Language v2.0, Part 1 -A TransitionUsage must have an ownedMember that is a Succession with an ActionUsage as the featureTarget of its targetFeature . let successions : Sequence(Successions) = ownedMember->selectByKind(Succession) in successions->notEmpty() and successions->at(1).targetFeature.featureTarget-> forAll(oclIsKindOf(ActionUsage)) validateTransitionUsageTriggerActions If the source of a TransitionUsage is not a StateUsage , then the TransitionUsage must not have any triggerActions . source <> null and not source.oclIsKindOf(StateUsage) implies triggerAction->isEmpty() 8.3.19 Calculations Abstract Syntax 8.3.19.1 Overview +/calculationOwningDefinition +/calculationOwningUsage Definition Usage 0..1 0..1 {subsets actionOwningDefinition} {subsets actionOwningUsage} OccurrenceDefinition OccurrenceUsage ActionDefinition ActionUsage +/ownedCalculation CalculationUsage 0..* +modelLevelEvaluable( visited : Feature [0..*] ) : Boolean{redefines modelLevelEvaluable} {subsets ownedAction, ordered} +/calculation +/nestedCalculation +/featuringCalculationDefinition CalculationDefinition 0..* 0..* 0..* {subsets computedFunction, {subsets action, subsets expression, {subsets nestedAction, subsets featuringActionDefinition} ordered} ordered} +/definedCalculation 0..* {subsets definedAction, subsets typedExpression} +/calculationDefinition Function Expression 0..1 {redefines actionDefinition, redefines function, ordered} Figure 34. Calculation Definition and Usage 8.3.19.2 CalculationDefinition Description A CalculationDefinition is an ActionDefinition that also defines a Function producing a result . General Classes ActionDefinition Function Attributes /calculation : CalculationUsage [0..*] {subsets action, expression, ordered} The actions of this CalculationDefinition that are CalculationUsages . Systems Modeling Language v2.0, Part 1 345 -Operations None. Constraints checkCalculationDefinitionSpecialization A CalculationDefinition must directly or indirectly specialize the CalculationDefinition Calculations::Calculation from the Systems Model Library. specializesFromLibrary('Calculations::Calculation') deriveCalculationUsageCalculation The calculations of a CalculationDefinition are those of its actions that are CalculationUsages . calculation = action->selectByKind(CalculationUsage) 8.3.19.3 CalculationUsage Description A CalculationUsage is an ActionUsage that is also an Expression , and, so, is typed by a Function . Nominally, if the type is a CalculationDefinition , a CalculationUsage is a Usage of that CalculationDefinition within a system. However, other kinds of kernel Functions are also allowed, to permit use of Functions from the Kernel Model Libraries. General Classes ActionUsage Expression Attributes /calculationDefinition : Function [0..1] {redefines function, actionDefinition, ordered} The Function that is the type of this CalculationUsage . Nominally, this would be a CalculationDefinition , but a kernel Function is also allowed, to permit use of Functions from the Kernel Model Libraries. Operations modelLevelEvaluable(visited : Feature [0..*]) : Boolean {redefines modelLevelEvaluable} A CalculationUsage is not model-level evaluable. body: false Constraints checkCalculationUsageSpecialization A CalculationUsage must specialize directly or indirectly the CalculationUsage Calculations::calculations from the Systems Model Library. specializesFromLibrary('Calculations::calculations') 346 Systems Modeling Language v2.0, Part 1 -checkCalculationUsageSubcalculationSpecialization owningType <> null and (owningType.oclIsKindOf(CalculationDefinition) or owningType.oclIsKindOf(CalculationUsage)) implies specializesFromLibrary('Calculations::Calculation::subcalculations') 8.3.20 Constraints Abstract Syntax 8.3.20.1 Overview +/constraintOwningUsage +/constraintOwningDefinition Definition Usage 0..1 0..1 {subsets {subsets occurrenceOwningUsage} occurrenceOwningDefinition} OccurrenceDefinition OccurrenceUsage ConstraintDefinition ConstraintUsage +/ownedConstraint +/nestedConstraint +namingFeature() : Feature [0..1]{redefines namingFeature} 0..* 0..* +modelLevelEvaluable( visited : Feature [0..*] ) : Boolean{redefines modelLevelEvaluable} {subsets ownedOccurrence, {subsets nestedOccurrence, ordered} ordered} +/definedConstraint 0..* +/constraintDefinition Predicate BooleanExpression {subsets 0..1 typedBooleanExpression} {redefines predicate} Figure 35. Constraint Definition and Usage +/assertedConstraint ConstraintUsage 1 0..* AssertConstraintUsage +/constraintAssertion Invariant Figure 36. Asserted Constraints 8.3.20.2 AssertConstraintUsage Description An AssertConstraintUsage is a ConstraintUsage that is also an Invariant and, so, is asserted to be true (by default). Unless it is the AssertConstraintUsage itself, the asserted ConstraintUsage is related to the AssertConstraintUsage by a ReferenceSubsetting Relationship . General Classes Invariant ConstraintUsage Attributes /assertedConstraint : ConstraintUsage Systems Modeling Language v2.0, Part 1 347 -The ConstraintUsage to be performed by the AssertConstraintUsage . It is the referenceFeature of the ownedReferenceSubsetting for the AssertConstraintUsage , if there is one, and, otherwise, the AssertConstraintUsage itself. Operations None. Constraints checkAssertConstraintUsageSpecialization If a AssertConstraintUsage is negated, then it must directly or indirectly specialize the ConstraintUsage Constraints::negatedConstraintChecks . Otherwise, it must directly or indirectly specialize the ConstraintUsage Constraints::assertedConstraintChecks . if isNegated then specializesFromLibrary('Constraints::negatedConstraintChecks') else specializesFromLibrary('Constraints::assertedConstraintChecks') endif deriveAssertConstraintUsageAssertedConstraint If an AssertConstraintUsage has no ownedReferenceSubsetting , then its assertedConstraint is the AssertConstraintUsage itself. Otherwise, the assertedConstraint is the featureTarget of the referencedFeature of the ownedReferenceSubsetting , which must be a ConstraintUsage . assertedConstraint = if referencedFeatureTarget() = null then self else if referencedFeatureTarget().oclIsKindOf(ConstraintUsage) then referencedFeatureTarget().oclAsType(ConstraintUsage) else null endif endif validateAssertConstraintUsageReference If an AssertConstraintUsage has an ownedReferenceSubsetting , then the featureTarget of its referencedFeature must be a ConstraintUsage. referencedFeaureTarget() <> null implies referencedFeatureTarget().oclIsKindOf(ConstraintUsage) 8.3.20.3 ConstraintDefinition Description A ConstraintDefinition is an OccurrenceDefinition that is also a Predicate that defines a constraint that may be asserted to hold on a system or part of a system. General Classes Predicate OccurrenceDefinition Attributes None. 348 Systems Modeling Language v2.0, Part 1 -Operations None. Constraints checkConstraintDefinitionSpecialization A ConstraintDefinition must directly or indirectly specialize the base ConstraintDefinition Constraints::ConstraintCheck from the Systems Model Library. specializesFromLibrary('Constraints::ConstraintCheck') 8.3.20.4 ConstraintUsage Description A ConstraintUsage is an OccurrenceUsage that is also a BooleanExpression , and, so, is typed by a Predicate . Nominally, if the type is a ConstraintDefinition , a ConstraintUsage is a Usage of that ConstraintDefinition . However, other kinds of kernel Predicates are also allowed, to permit use of Predicates from the Kernel Model Libraries. General Classes BooleanExpression OccurrenceUsage Attributes /constraintDefinition : Predicate [0..1] {redefines predicate} The (single) Predicate that is the type of this ConstraintUsage . Nominally, this will be a ConstraintDefinition , but other kinds of Predicates are also allowed, to permit use of Predicates from the Kernel Model Libraries. Operations modelLevelEvaluable(visited : Feature [0..*]) : Boolean {redefines modelLevelEvaluable} A ConstraintUsage is not model-level evaluable. body: false namingFeature() : Feature [0..1] {redefines namingFeature} The naming Feature of a ConstraintUsage that is owned by a RequirementConstraintMembership and has an ownedReferenceSubsetting is the featureTarget of the referencedFeature of that ownedReferenceSubsetting . body: if owningFeatureMembership <> null and owningFeatureMembership.oclIsKindOf(RequirementConstraintMembership) and ownedReferenceSubsetting <> null then ownedReferenceSubsetting.referencedFeature.featureTarget else self.oclAsType(OccurrenceUsage).namingFeature() endif Systems Modeling Language v2.0, Part 1 349 -Constraints checkConstraintUsageCheckedConstraintSpecialization A ConstraintUsage whose owningType is an ItemDefinition or ItemUsage must directly or indirectly specialize the ConstraintUsage Items::Item::checkedConstraints . owningType <> null and (owningType.oclIsKindOf(ItemDefinition) or owningType.oclIsKindOf(ItemUsage)) implies specializesFromLibrary('Items::Item::checkedConstraints') checkConstraintUsageRequirementConstraintSpecialization A ConstraintUsage whose owningFeatureMembership is a RequirementConstraintMembership must directly or indirectly specialize on the ConstraintUsages assumptions or constraints from the ConstraintDefinition Requirements::RequirementCheck in the Systems Model Library, depending on whether the kind of the RequirementConstraintMembership is assumption or requirement , respectively. owningFeatureMembership <> null and owningFeatureMembership.oclIsKindOf(RequirementConstraintMembership) implies if owningFeatureMembership.oclAsType(RequirementConstraintMembership).kind = RequirementConstraintKind::assumption then specializesFromLibrary('Requirements::RequirementCheck::assumptions') else specializesFromLibrary('Requirements::RequirementCheck::constraints') endif checkConstraintUsageSpecialization A ConstraintUsage must directly or indirectly specialize the base ConstraintUsage Constraints::constraintChecks from the Systems Model Library. specializesFromLibrary('Constraints::constraintChecks') 350 Systems Modeling Language v2.0, Part 1 -8.3.21 Requirements Abstract Syntax 8.3.21.1 Overview {subsets constraintOwningDefinition} 0..1 +/requirementOwningDefinition +/requirementOwningUsage Definition Usage 0..1 {subsets constraintOwningUsage} OccurrenceUsage OccurrenceDefinition {subsets ownedFeature, ordered} +/requiredConstraint ConstraintDefinition ConstraintUsage +/assumedConstraint 0..* 0..* {subsets ownedFeature, ordered} {subsets ownedFeature, ordered} +/requiredConstraint +/assumedConstraint 0..* 0..* {subsets ownedFeature, ordered} +/requiringRequirementDefinition +/requiringRequirement RequirementDefinition RequirementUsage 0..1 {subsets owningType} 0..1 +reqId : String [0..1]{redefines declaredShortName} +reqId : String [0..1]{redefines declaredShortName} {subsets owningType} +/assumingRequirement +/text : String [0..*] +/text : String [0..*] 0..1 {subsets owningType} +/assumingRequirementDefinition 0..1 +/nestedRequirement {subsets nestedConstraint, ordered} 0..* {subsets owningType} +/requirementDefinition +/definedRequirement +/ownedRequirement +/framingRequirementDefinition 0..1 0..* 0..* {subsets ownedConstraint, ordered} 0..1 {redefines {subsets definedConstraint} +/framingRequirement constraintDefinition} {subsets assumingRequirementDefinition} 0..1 {subsets requiringRequirement} +/stakholderOwiningRequirementDefinition +/stakholderOwningRequirement 0..1 0..1 {subsets parameteredStep, {subsets parameteredStep, subsets partOwningUsage} subsets partOwningUsage} +/actorOwningRequirementDefinition 0..1 0..1 +/subjectOwningRequirementDefinition +/subjectOwningRequirement 0..1 0..1 +actorOwningRequirement {subsets parameteredBehavior, {subsets owningDefinition, {subsets owningUsage, {subsets parameteredStep, subsets partOwningDefinition} subsets parameteredBehavior} subsets parameteredStep} subsets partOwningUsage} +/subjectParameter +/subjectParameter Usage 1 1 {subsets parameter, {subsets parameter, subsets usage} subsets usage} +/actorParameter +/actorParameter PartUsage 0..* 0..* {subsets parameter, {subsets parameter, subsets subsets usage, ordered} usage, ordered} +/stakeholderParameter +/stakeholderParameter 0..* 0..* {subsets parameter, {subsets parameter, subsets subsets usage, ordered} usage, ordered} +/framedConcern +/framedConcern ConcernUsage 0..* 0..* {subsets requiredConstraint, ordered} {subsets requiredConstraint, ordered} Figure 37. Requirement Definition and Usage {redefines assertedConstraint} +/satisfiedRequirement RequirementUsage AssertConstraintUsage 1 0..* SatisfyRequirementUsage +/requirementSatisfaction {subsets constraintAssertion} +/satisfiedRequirement 0..* +/satisfyingFeature 1 Feature Figure 38. Satisfied Requirements Systems Modeling Language v2.0, Part 1 351 -+/concernOwningDefinition +/concernOwningUsage Definition Usage 0..1 0..1 {subsets requirementOwningDefinition} {subsets requirementOwningUsage} OccurrenceDefinition OccurrenceUsage ConstraintDefinition ConstraintUsage RequirementDefinition RequirementUsage +/ownedConcern ConcernUsage 0..* {subsets ownedRequirement} +/nestedConcern 0..* +/concernDefinition +/definedConcern ConcernDefinition {subsets nestedRequirement} 0..1 0..1 {redefines requirementDefinition} {subsets definedRequirement} Figure 39. Concern Definition and Usage FeatureMembership +/requirementConstraintMembership +/ownedConstraint «enumeration» RequirementConstraintMembership ConstraintUsage 0..1 1 RequirementConstraintKind +kind : RequirementConstraintKind {subsets {redefines owningFeatureMembership} ownedMemberFeature} assumption requirement +/referencingConstraintMembership +/referencedConstraint 0..* 1 RequirementUsage +/framedConstraintMembership +/ownedConcern FramedConcernMembership ConcernUsage 0..1 1 +kind : RequirementConstraintKind = requirement{redefines kind} {subsets {redefines requirementConstraintMembership} ownedConstraint} +/referencingConcernMembership +/referencedConcern 0..* 1 {subsets {redefines referencingConstraintMembership} referencedConstraint} Figure 40. Requirement Constraint Membership 352 Systems Modeling Language v2.0, Part 1 -ParameterMembership SubjectMembership ActorMembership StakeholderMembership +/owningSubjectMembership 0..1 +/owningActorMembership 0..1 +/owningStakeholderMembership 0..1 {subsets {subsets {subsets owningParameterMembership} owningParameterMembership} owningParameterMembership} {redefines {redefines ownedMemberParameter} ownedMemberParameter} +/ownedSubjectParameter 1 +/ownedActorParameter 1 +/ownedStakeholderParameter Usage PartUsage 1 {redefines ownedMemberParameter} Figure 41. Requirement Parameter Memberships 8.3.21.2 ActorMembership Description An ActorMembership is a ParameterMembership that identifies a PartUsage as an actor parameter , which specifies a role played by an external entity in interaction with the owningType of the ActorMembership . General Classes ParameterMembership Attributes /ownedActorParameter : PartUsage {redefines ownedMemberParameter} The PartUsage specifying the actor. Operations None. Constraints validateActorMembershipOwningType The owningType of an ActorMembership must be a RequirementDefinition , RequirementUsage , CaseDefinition , or CaseUsage . owningType.oclIsKindOf(RequirementUsage) or owningType.oclIsKindOf(RequirementDefinition) or owningType.oclIsKindOf(CaseDefinition) or owningType.oclIsKindOf(CaseUsage) 8.3.21.3 ConcernDefinition Description Systems Modeling Language v2.0, Part 1 353 -A ConcernDefinition is a RequirementDefinition that one or more stakeholders may be interested in having addressed. These stakeholders are identified by the ownedStakeholders of the ConcernDefinition . General Classes RequirementDefinition Attributes None. Operations None. Constraints checkConcernDefinitionSpecialization A ConcernDefinition must directly or indirectly specialize the base ConcernDefinition Requirements::ConcernCheck from the Systems Model Library. specializesFromLibrary('Requirements::ConcernCheck') 8.3.21.4 ConcernUsage Description A ConcernUsage is a Usage of a ConcernDefinition . The ownedStakeholder features of the ConcernUsage shall all subset the ConcernCheck::concernedStakeholders feature. If the ConcernUsage is an ownedFeature of a StakeholderDefinition or StakeholderUsage, then the ConcernUsage shall have an ownedStakeholder feature that is bound to the self feature of its owner. General Classes RequirementUsage Attributes /concernDefinition : ConcernDefinition [0..1] {redefines requirementDefinition} The ConcernDefinition that is the single type of this ConcernUsage. Operations None. Constraints checkConcernUsageFramedConcernSpecialization If a ConcernUsage is owned via a FramedConcernMembership , then it must directly or indirectly specialize the ConcernUsage Requirements::RequirementCheck::concerns from the Systems Model Library. 354 Systems Modeling Language v2.0, Part 1 -owningFeatureMembership <> null and owningFeatureMembership.oclIsKindOf(FramedConcernMembership) implies specializesFromLibrary('Requirements::RequirementCheck::concerns') checkConcernUsageSpecialization A ConcernUsage must directly or indirectly specialize the base ConcernUsage Requirements::concernChecks from the Systems Model Library. specializesFromLibrary('Requirements::concernChecks') 8.3.21.5 FramedConcernMembership Description A FramedConcernMembership is a RequirementConstraintMembership for a framed ConcernUsage of a RequirementDefinition or RequirementUsage . General Classes RequirementConstraintMembership Attributes kind : RequirementConstraintKind {redefines kind} The kind of an FramedConcernMembership must be requirement . /ownedConcern : ConcernUsage {redefines ownedConstraint} The ConcernUsage that is the ownedConstraint of this FramedConcernMembership . /referencedConcern : ConcernUsage {redefines referencedConstraint} The ConcernUsage that is referenced through this FramedConcernMembership . It is the referencedConstraint of the FramedConcernMembership considered as a RequirementConstraintMembership , which must be a ConcernUsage . Operations None. Constraints validateFramedConcernMembershipConstraintKind A FramedConcernMembership must have kind = requirement . kind = RequirementConstraintKind::requirement 8.3.21.6 RequirementConstraintKind Description A RequirementConstraintKind indicates whether a ConstraintUsage is an assumption or a requirement in a RequirementDefinition or RequirementUsage . Systems Modeling Language v2.0, Part 1 355 -General Classes None. Literal Values assumption Indicates that a member ConstraintUsage of a RequirementDefinition or RequirementUsage represents an assumption. requirement Indicates that a member ConstraintUsage of a RequirementDefinition or RequirementUsage represents an requirement. 8.3.21.7 RequirementConstraintMembership Description A RequirementConstraintMembership is a FeatureMembership for an assumed or required ConstraintUsage of a RequirementDefinition or RequirementUsage. General Classes FeatureMembership Attributes kind : RequirementConstraintKind Whether the RequirementConstraintMembership is for an assumed or required ConstraintUsage . /ownedConstraint : ConstraintUsage {redefines ownedMemberFeature} The ConstraintUsage that is the ownedMemberFeature of this RequirementConstraintMembership . /referencedConstraint : ConstraintUsage The ConstraintUsage that is referenced through this RequirementConstraintMembership . It is the referencedFeature of the ownedReferenceSubsetting of the ownedConstraint , if there is one, and, otherwise, the ownedConstraint itself. Operations None. Constraints deriveRequirementConstraintMembershipReferencedConstraint The referencedConstraint of a RequirementConstraintMembership is the featureTarget of the referencedFeature of the ownedReferenceSubsetting of the ownedConstraint , if there is one, and, otherwise, the ownedConstraint itself. 356 Systems Modeling Language v2.0, Part 1 -referencedConstraint = let referencedFeature : Feature = ownedConstraint.referencedFeatureTarget() in if referencedFeature = null then ownedConstraint else if referencedFeature.oclIsKindOf(ConstraintUsage) then refrencedFeature.oclAsType(ConstraintUsage) else null endif endif validateRequirementConstraintMembershipIsComposite The ownedConstraint of a RequirementConstraintMembership must be composite. ownedConstraint.isComposite validateRequirementConstraintMembershipOwningType The owningType of a RequirementConstraintMembership must be a RequirementDefinition or a RequirementUsage . owningType.oclIsKindOf(RequirementDefinition) or owningType.oclIsKindOf(RequirementUsage) 8.3.21.8 RequirementDefinition Description A RequirementDefinition is a ConstraintDefinition that defines a requirement used in the context of a specification as a constraint that a valid solution must satisfy. The specification is relative to a specified subject, possibly in collaboration with one or more external actors. General Classes ConstraintDefinition Attributes /actorParameter : PartUsage [0..*] {subsets parameter, usage, ordered} The parameters of this RequirementDefinition that represent actors involved in the requirement. /assumedConstraint : ConstraintUsage [0..*] {subsets ownedFeature, ordered} The owned ConstraintUsages that represent assumptions of this RequirementDefinition , which are the ownedConstraints of the RequirementConstraintMemberships of the RequirementDefinition with kind = assumption . /framedConcern : ConcernUsage [0..*] {subsets requiredConstraint, ordered} The ConcernUsages framed by this RequirementDefinition , which are the ownedConcerns of all FramedConcernMemberships of the RequirementDefinition . reqId : String [0..1] {redefines declaredShortName} An optional modeler-specified identifier for this RequirementDefinition (used, e.g., to link it to an original requirement text in some source document), which is the declaredShortName for the RequirementDefinition . Systems Modeling Language v2.0, Part 1 357 -/requiredConstraint : ConstraintUsage [0..*] {subsets ownedFeature, ordered} The owned ConstraintUsages that represent requirements of this RequirementDefinition , derived as the ownedConstraints of the RequirementConstraintMemberships of the RequirementDefinition with kind = requirement . /stakeholderParameter : PartUsage [0..*] {subsets parameter, usage, ordered} The parameters of this RequirementDefinition that represent stakeholders for th requirement. /subjectParameter : Usage {subsets parameter, usage} The parameter of this RequirementDefinition that represents its subject. /text : String [0..*] An optional textual statement of the requirement represented by this RequirementDefinition , derived from the bodies of the documentation of the RequirementDefinition . Operations None. Constraints checkRequirementDefinitionSpecialization A RequirementDefinition must directly or indirectly specialize the base RequirementDefinition Requirements::RequirementCheck from the Systems Model Library. specializesFromLibrary('Requirements::RequirementCheck') deriveRequirementDefinitionActorParameter The actorParameters of a RequirementDefinition are the ownedActorParameters of the ActorMemberships of the RequirementDefinition . actorParameter = featureMembership-> selectByKind(ActorMembership). ownedActorParameter deriveRequirementDefinitionAssumedConstraint The assumedConstraints of a RequirementDefinition are the ownedConstraints of the RequirementConstraintMemberships of the RequirementDefinition with kind = assumption . assumedConstraint = ownedFeatureMembership-> selectByKind(RequirementConstraintMembership)-> select(kind = RequirementConstraintKind::assumption). ownedConstraint deriveRequirementDefinitionFramedConcern The framedConcerns of a RequirementDefinition are the ownedConcerns of the FramedConcernMemberships of the RequirementDefinition . 358 Systems Modeling Language v2.0, Part 1 -framedConcern = featureMembership-> selectByKind(FramedConcernMembership). ownedConcern deriveRequirementDefinitionRequiredConstraint The requiredConstraints of a RequirementDefinition are the ownedConstraints of the RequirementConstraintMemberships of the RequirementDefinition with kind = requirement . requiredConstraint = ownedFeatureMembership-> selectByKind(RequirementConstraintMembership)-> select(kind = RequirementConstraintKind::requirement). ownedConstraint deriveRequirementDefinitionStakeholderParameter The stakeHolderParameters of a RequirementDefinition are the ownedStakeholderParameters of the StakeholderMemberships of the RequirementDefinition . stakeholderParameter = featureMembership-> selectByKind(StakholderMembership). ownedStakeholderParameter deriveRequirementDefinitionSubjectParameter The subjectParameter of a RequirementDefinition is the ownedSubjectParameter of its SubjectMembership (if any). subjectParameter = let subjects : OrderedSet(SubjectMembership) = featureMembership->selectByKind(SubjectMembership) in if subjects->isEmpty() then null else subjects->first().ownedSubjectParameter endif deriveRequirementDefinitionText The texts of a RequirementDefinition are the bodies of the documentation of the RequirementDefinition . text = documentation.body validateRequirementDefinitionOnlyOneSubject A RequirementDefinition must have at most one featureMembership that is a SubjectMembership . featureMembership-> selectByKind(SubjectMembership)-> size() <= 1 validateRequirementDefinitionSubjectParameterPosition The subjectParameter of a RequirementDefinition must be its first input . input->notEmpty() and input->first() = subjectParameter 8.3.21.9 RequirementUsage Description Systems Modeling Language v2.0, Part 1 359 -A RequirementUsage is a Usage of a RequirementDefinition . General Classes ConstraintUsage Attributes /actorParameter : PartUsage [0..*] {subsets parameter, usage, ordered} The parameters of this RequirementUsage that represent actors involved in the requirement. /assumedConstraint : ConstraintUsage [0..*] {subsets ownedFeature, ordered} The owned ConstraintUsages that represent assumptions of this RequirementUsage , derived as the ownedConstraints of the RequirementConstraintMemberships of the RequirementUsage with kind = assumption . /framedConcern : ConcernUsage [0..*] {subsets requiredConstraint, ordered} The ConcernUsages framed by this RequirementUsage , which are the ownedConcerns of all FramedConcernMemberships of the RequirementUsage . reqId : String [0..1] {redefines declaredShortName} An optional modeler-specified identifier for this RequirementUsage (used, e.g., to link it to an original requirement text in some source document), which is the declaredShortName for the RequirementUsage . /requiredConstraint : ConstraintUsage [0..*] {subsets ownedFeature, ordered} The owned ConstraintUsages that represent requirements of this RequirementUsage , which are the ownedConstraints of the RequirementConstraintMemberships of the RequirementUsage with kind = requirement . /requirementDefinition : RequirementDefinition [0..1] {redefines constraintDefinition} The RequirementDefinition that is the single definition of this RequirementUsage . /stakeholderParameter : PartUsage [0..*] {subsets parameter, usage, ordered} The parameters of this RequirementUsage that represent stakeholders for the requirement. /subjectParameter : Usage {subsets parameter, usage} The parameter of this RequirementUsage that represents its subject. /text : String [0..*] An optional textual statement of the requirement represented by this RequirementUsage , derived from the bodies of the documentation of the RequirementUsage. Operations None. Constraints 360 Systems Modeling Language v2.0, Part 1 -checkRequirementUsageObjectiveRedefinition A RequirementUsage whose owningFeatureMembership is a ObjectiveMembership must redefine the objectiveRequirement of each CaseDefinition or CaseUsage that is specialized by the owningType of the RequirementUsage . owningfeatureMembership <> null and owningfeatureMembership.oclIsKindOf(ObjectiveMembership) implies owningType.ownedSpecialization.general->forAll(gen | (gen.oclIsKindOf(CaseDefinition) implies redefines(gen.oclAsType(CaseDefinition).objectiveRequirement)) and (gen.oclIsKindOf(CaseUsage) implies redefines(gen.oclAsType(CaseUsage).objectiveRequirement)) checkRequirementUsageRequirementVerificationSpecialization A RequirementUsage whose owningFeatureMembership is a RequirementVerificationMembership must directly or indirectly specialize the RequirementUsage VerificationCases::VerificationCase::obj::requirementVerifications . owningFeatureMembership <> null and owningFeatureMembership.oclIsKindOf(RequirementVerificationMembership) implies specializesFromLibrary('VerificationCases::VerificationCase::obj::requirementVerifications') checkRequirementUsageSpecialization A RequirementUsage must directly or indirectly specialize the base RequirementUsage Requirements::requirementChecks from the Systems Model Library. specializesFromLibrary('Requirements::requirementChecks') checkRequirementUsageSubrequirementSpecialization A composite RequirementUsage whose owningType is a RequirementDefinition or RequirementUsage must directly or indirectly specialize the RequirementUsage Requirements::RequirementCheck::subrequirements from the Systems Model Library. isComposite and owningType <> null and (owningType.oclIsKindOf(RequirementDefinition) or owningType.oclIsKindOf(RequirementUsage)) implies specializesFromLibrary('Requirements::RequirementCheck::subrequirements') deriveRequirementUsageActorParameter The actorParameters of a RequirementUsage are the ownedActorParameters of the ActorMemberships of the RequirementUsage . actorParameter = featureMembership-> selectByKind(ActorMembership). ownedActorParameter deriveRequirementUsageAssumedConstraint The assumedConstraints of a RequirementUsage are the ownedConstraints of the RequirementConstraintMemberships of the RequirementDefinition with kind = assumption . assumedConstraint = ownedFeatureMembership-> selectByKind(RequirementConstraintMembership)-> Systems Modeling Language v2.0, Part 1 361 -select(kind = RequirementConstraintKind::assumption). ownedConstraint deriveRequirementUsageFramedConcern The framedConcerns of a RequirementUsage are the ownedConcerns of the FramedConcernMemberships of the RequirementUsage . framedConcern = featureMembership-> selectByKind(FramedConcernMembership). ownedConcern deriveRequirementUsageRequiredConstraint The requiredConstraints of a RequirementUsage are the ownedConstraints of the RequirementConstraintMemberships of the RequirementUsage with kind = requirement . requiredConstraint = ownedFeatureMembership-> selectByKind(RequirementConstraintMembership)-> select(kind = RequirementConstraintKind::requirement). ownedConstraint deriveRequirementUsageStakeholderParameter The stakeHolderParameters of a RequirementUsage are the ownedStakeholderParameters of the StakeholderMemberships of the RequirementUsage . stakeholderParameter = featureMembership-> selectByKind(AStakholderMembership). ownedStakeholderParameter deriveRequirementUsageSubjectParameter The subjectParameter of a RequirementUsage is the ownedSubjectParameter of its SubjectMembership (if any). subjectParameter = let subjects : OrderedSet(SubjectMembership) = featureMembership->selectByKind(SubjectMembership) in if subjects->isEmpty() then null else subjects->first().ownedSubjectParameter endif deriveRequirementUsageText The texts of a RequirementUsage are the bodies of the documentation of the RequirementUsage . text = documentation.body validateRequirementUsageOnlyOneSubject A RequirementDefinition must have at most one featureMembership that is a SubjectMembership . featureMembership-> selectByKind(SubjectMembership)-> size() <= 1 validateRequirementUsageSubjectParameterPosition 362 Systems Modeling Language v2.0, Part 1 -The subjectParameter of a RequirementUsage must be its first input . input->notEmpty() and input->first() = subjectParameter 8.3.21.10 SatisfyRequirementUsage Description A SatisfyRequirementUsage is an AssertConstraintUsage that asserts, by default, that a satisfied RequirementUsage is true for a specific satisfyingFeature , or, if isNegated = true , that the RequirementUsage is false. The satisfied RequirementUsage is related to the SatisfyRequirementUsage by a ReferenceSubsetting Relationship . General Classes AssertConstraintUsage RequirementUsage Attributes /satisfiedRequirement : RequirementUsage {redefines assertedConstraint} The RequirementUsage that is satisfied by the satisfyingSubject of this SatisfyRequirementUsage . It is the assertedConstraint of the SatisfyRequirementUsage considered as an AssertConstraintUsage , which must be a RequirementUsage . /satisfyingFeature : Feature The Feature that represents the actual subject that is asserted to satisfy the satisfiedRequirement . The satisfyingFeature is bound to the subjectParameter of the SatisfyRequirementUsage . Operations None. Constraints checkSatisfyRequirementUsageBindingConnector A SatisfyRequirementUsage must have exactly one ownedMember that is a BindingConnector between its subjectParameter and some Feature other than the subjectParameter . ownedMember->selectByKind(BindingConnector)-> select(b | b.relatedElement->includes(subjectParameter) and b.relatedElement->exists(r | r <> subjectParameter))-> size() = 1 checkSatisfyRequirementUsageSpecialization If a SatisfyRequirementUsage is negated, then it must directly or indirectly specialize the RequirementUsage Requirements::notSatisfiedRequirementChecks . Otherwise, it must directly or indirectly specialize the RequirementUsage Requirements::satisfiedRequirementChecks . if isNegated then specializesFromLibrary('Requirements::notSatisfiedRequirementChecks') else Systems Modeling Language v2.0, Part 1 363 -specializesFromLibrary('Requirements::satisfiedRequirementChecks') endif deriveSatisfyRequirementUsageSatisfyingFeature The satisfyingFeature of a SatisfyRequirementUsage is the Feature to which the subjectParameter is bound. satisfyingFeature = let bindings: BindingConnector = ownedMember-> selectByKind(BindingConnector)-> select(b | b.relatedElement->includes(subjectParameter)) in if bindings->isEmpty() or bindings->first().relatedElement->exits(r | r <> subjectParameter) then null else bindings->first().relatedElement->any(r | r <> subjectParameter) endif validateSatisfyRequirementUsageReference If a SatisfyRequirementUsage has an ownedReferenceSubsetting , then the featureTarget of its referencedFeature must be a RequirementUsage . referencedFeatureTarget() <> null implies referencedFeatureTarget().oclIsKindOf(RequirementUsage) 8.3.21.11 SubjectMembership Description A SubjectMembership is a ParameterMembership that indicates that its ownedSubjectParameter is the subject of its owningType . The owningType of a SubjectMembership must be a RequirementDefinition , RequirementUsage , CaseDefinition , or CaseUsage . General Classes ParameterMembership Attributes /ownedSubjectParameter : Usage {redefines ownedMemberParameter} The UsageownedMemberParameter of this SubjectMembership . Operations None. Constraints validateSubjectMembershipOwningType The owningType of a SubjectMembership must be a RequirementDefinition , RequirementUsage , CaseDefinition , or CaseUsage . owningType.oclIsType(RequirementDefinition) or owningType.oclIsType(RequiremenCaseRequirementDefinition) or 364 Systems Modeling Language v2.0, Part 1 -owningType.oclIsType(CaseDefinition) or owningType.oclIsType(CaseUsage) 8.3.21.12 StakeholderMembership Description A StakeholderMembership is a ParameterMembership that identifies a PartUsage as a stakeholderParameter of a RequirementDefinition or RequirementUsage , which specifies a role played by an entity with concerns framed by the owningType . General Classes ParameterMembership Attributes /ownedStakeholderParameter : PartUsage {redefines ownedMemberParameter} The PartUsage specifying the stakeholder. Operations None. Constraints validateStakeholderMembershipOwningType The owningType of a StakeholderMembership must be a RequirementDefinition or RequirementUsage . owningType.oclIsKindOf(RequirementUsage) or owningType.oclIsKindOf(RequirementDefinition) Systems Modeling Language v2.0, Part 1 365 -8.3.22 Cases Abstract Syntax 8.3.22.1 Overview +/caseOwningDefinition +/caseOwningUsage Definition Usage 0..1 0..1 {subsets {subsets calculationOwningDefinition} calculationOwningUsage} OccurrenceDefinition OccurrenceUsage ActionDefinition ActionUsage CalculationDefinition CalculationUsage +/ownedCase +/nestedCase CaseDefinition CaseUsage 0..* 0..* +/objectiveOwningCaseDefinition {subsets ownedCalculation, ordered} {subsets nestedCalculation, ordered} 0..1 +/caseDefinition +/definedCase +/objectiveOwningCase {subsets owningType} 0..1 0..* 0..1 {redefines calculationDefinition} {subsets definedCalculation} {subsets requirementOwningUsage} +actorOwningCaseDefinition 0..1 0..1 +/subjectOwningCaseDefinition +subjectOwningCase 0..1 0..1 +/actorOwningCase {subsets parameteredBehavior, {subsets owningDefinition, {subsets owningUsage, {subsets parameteredStep, subsets partOwningDefinition} subsets parameteredBehavior} subsets parameteredStep} subsets partOwningUsage} +/subjectParameter +/subjectParameter Usage 1 1 {subsets parameter, {subsets parameter, subsets usage} subsets usage} +/actorParameter +/actorParameter PartUsage 0..* 0..* {subsets parameter, {subsets parameter, subsets usage, ordered} subsets usage, ordered} +/objectiveRequirement +/objectiveRequirement RequirementUsage 0..1 0..1 {subsets usage, {subsets usage, ordered} ordered} Figure 42. Case Definition and Usage FeatureMembership ObjectiveMembership +/owningObjectiveMembership 0..1 {subsets owningParameterMembership} {redefines ownedMemberFeature} +/ownedObjectiveRequirement 1 RequirementUsage Figure 43. Case Membership 366 Systems Modeling Language v2.0, Part 1 -8.3.22.2 CaseDefinition Description A CaseDefinition is a CalculationDefinition for a process, often involving collecting evidence or data, relative to a subject, possibly involving the collaboration of one or more other actors, producing a result that meets an objective. General Classes CalculationDefinition Attributes /actorParameter : PartUsage [0..*] {subsets parameter, usage, ordered} The parameters of this CaseDefinition that represent actors involved in the case. /objectiveRequirement : RequirementUsage [0..1] {subsets usage, ordered} The RequirementUsage representing the objective of this CaseDefinition . /subjectParameter : Usage {subsets parameter, usage} The parameter of this CaseDefinition that represents its subject. Operations None. Constraints checkCaseDefinitionSpecialization A CaseDefinition must directly or indirectly specialize the base CaseDefinition Cases::Case> from the Systems Model Library. specializesFromLibrary('Cases::Case') deriveCaseDefinitionActorParameter The actorParameters of a CaseDefinition are the ownedActorParameters of the ActorMemberships of the CaseDefinition . actorParameter = featureMembership-> selectByKind(ActorMembership). ownedActorParameter deriveCaseDefinitionObjectiveRequirement The objectiveRequirement of a CaseDefinition is the ownedObjectiveRequirement of its ObjectiveMembership, if any. objectiveRequirement = let objectives: OrderedSet(RequirementUsage) = featureMembership-> selectByKind(ObjectiveMembership). Systems Modeling Language v2.0, Part 1 367 -ownedRequirement in if objectives->isEmpty() then null else objectives->first().ownedObjectiveRequirement endif deriveCaseDefinitionSubjectParameter The subjectParameter of a CaseDefinition is the ownedSubjectParameter of its SubjectMembership (if any). subjectParameter = let subjectMems : OrderedSet(SubjectMembership) = featureMembership->selectByKind(SubjectMembership) in if subjectMems->isEmpty() then null else subjectMems->first().ownedSubjectParameter endif validateCaseDefinitionOnlyOneObjective A CaseDefinition must have at most one featureMembership that is a ObjectiveMembership . featureMembership-> selectByKind(ObjectiveMembership)-> size() <= 1 validateCaseDefinitionOnlyOneSubject A CaseDefinition must have at most one featureMembership that is a SubjectMembership . featureMembership->selectByKind(SubjectMembership)->size() <= 1 validateCaseDefinitionSubjectParameterPosition The subjectParameter of a CaaseDefinition must be its first input . input->notEmpty() and input->first() = subjectParameter 8.3.22.3 CaseUsage Description A CaseUsage is a Usage of a CaseDefinition . General Classes CalculationUsage Attributes /actorParameter : PartUsage [0..*] {subsets parameter, usage, ordered} The parameters of this CaseUsage that represent actors involved in the case. /caseDefinition : CaseDefinition [0..1] {redefines calculationDefinition} The CaseDefinition that is the type of this CaseUsage. /objectiveRequirement : RequirementUsage [0..1] {subsets usage, ordered} 368 Systems Modeling Language v2.0, Part 1 -The RequirementUsage representing the objective of this CaseUsage . /subjectParameter : Usage {subsets parameter, usage} The parameter of this CaseUsage that represents its subject. Operations None. Constraints checkCaseUsageSpecialization A CaseUsage must directly or indirectly specialize the base CaseUsage Cases::cases from the Systems Model Library. specializesFromLibrary('Cases::cases') checkCaseUsageSubcaseSpecialization A composite CaseUsage whose owningType is a CaseDefinition or CaseUsage must directly or indirectly specialize the CaseUsage Cases::Case::subcases . isComposite and owningType <> null and (owningType.oclIsKindOf(CaseDefinition) or owningType.oclIsKindOf(CaseUsage)) implies specializesFromLibrary('Cases::Case::subcases') deriveCaseUsageActorParameter The actorParameters of a CaseUsage are the ownedActorParameters of the ActorMemberships of the CaseUsage . actorParameter = featureMembership-> selectByKind(ActorMembership). ownedActorParameter deriveCaseUsageObjectiveRequirement The objectiveRequirement of a CaseUsage is the RequirementUsage it owns via an ObjectiveMembership, if any. objectiveRequirement = let objectives: OrderedSet(RequirementUsage) = featureMembership-> selectByKind(ObjectiveMembership). ownedRequirement in if objectives->isEmpty() then null else objectives->first().ownedObjectiveRequirement endif deriveCaseUsageSubjectParameter The subjectParameter of a CaseUsage is the ownedSubjectParameter of its SubjectMembership (if any). subjectParameter = let subjects : OrderedSet(SubjectMembership) = Systems Modeling Language v2.0, Part 1 369 -featureMembership->selectByKind(SubjectMembership) in if subjects->isEmpty() then null else subjects->first().ownedSubjectParameter endif validateCaseUsageOnlyOneObjective A CaseUsage must have at most one featureMembership that is a ObjectiveMembership . featureMembership-> selectByKind(ObjectiveMembership)-> size() <= 1 validateCaseUsageOnlyOneSubject A CaseUsage must have at most one featureMembership that is a SubjectMembership . featureMembership-> selectByKind(SubjectMembership)-> size() <= 1 validateCaseUsageSubjectParameterPosition The subjectParameter of a CaseUsage must be its first input . input->notEmpty() and input->first() = subjectParameter 8.3.22.4 ObjectiveMembership Description An ObjectiveMembership is a FeatureMembership that indicates that its ownedObjectiveRequirement is the objective RequirementUsage for its owningType , which must be a CaseDefinition or CaseUsage . General Classes FeatureMembership Attributes /ownedObjectiveRequirement : RequirementUsage {redefines ownedMemberFeature} The RequirementUsage that is the ownedMemberFeature of this RequirementUsage. Operations None. Constraints validateObjectiveMembershipIsComposite The ownedObjectiveRequirement of an ObjectiveMembership must be composite. ownedObjectiveRequirement.isComposite validateObjectiveMembershipOwningType 370 Systems Modeling Language v2.0, Part 1 -The owningType of an ObjectiveMembership must be a CaseDefinition or CaseUsage . owningType.oclIsType(CaseDefinition) or owningType.oclIsType(CaseUsage) 8.3.23 Analysis Cases Abstract Syntax 8.3.23.1 Overview +/analysisCaseOwningDefinition +/analysisCaseOwningUsage Definition Usage 0..1 0..1 {subsets {subsets caseOwningDefinition} analysisCaseOwningUsage} OccurrenceDefinition OccurrenceUsage ActionDefinition ActionUsage CalculationDefinition CalculationUsage CaseDefinition CaseUsage +/ownedAnalysisCase AnalysisCaseDefinition AnalysisCaseUsage 0..* {subsets ownedCase, ordered} +/nestedAnalysisCase 0..* +/analysisCaseDefinition +/definedAnalysisCase {subsets nestedCase, 0..1 0..* ordered} {redefines definedCase, {redefines caseDefinition} ordered} +/analysisCaseDefintion 0..1 +/analysisCase 0..1 {subsets computedFunction, {subsets owningType} subsets owningType} +/resultExpression +/resultExpression Expression 0..1 0..1 {subsets expression, {subsets ownedFeature} subsets ownedFeature} Figure 44. Analysis Case Definition and Usage 8.3.23.2 AnalysisCaseDefinition Description An AnalysisCaseDefinition is a CaseDefinition for the case of carrying out an analysis. General Classes CaseDefinition Attributes /resultExpression : Expression [0..1] {subsets expression, ownedFeature} An Expression used to compute the result of the AnalysisCaseDefinition , owned via a ResultExpressionMembership . Systems Modeling Language v2.0, Part 1 371 -Operations None. Constraints checkAnalysisCaseDefinitionSpecialization An AnalysisCaseDefinition must directly or indirectly specialize the base AnalysisCaseDefinition AnalysisCases::AnalysisCase from the Systems Model Library. specializesFromLibrary('AnalysisCases::AnalysisCase') deriveAnalysisCaseDefinitionResultExpression The resultExpression of a AnalysisCaseDefinition is the ownedResultExpression of its ResultExpressionMembership , if any. resultExpression = let results : OrderedSet(ResultExpressionMembership) = featureMembersip-> selectByKind(ResultExpressionMembership) in if results->isEmpty() then null else results->first().ownedResultExpression endif 8.3.23.3 AnalysisCaseUsage Description An AnalysisCaseUsage is a Usage of an AnalysisCaseDefinition . General Classes CaseUsage Attributes /analysisCaseDefinition : AnalysisCaseDefinition [0..1] {redefines caseDefinition} The AnalysisCaseDefinition that is the definition of this AnalysisCaseUsage . /resultExpression : Expression [0..1] {subsets ownedFeature} An Expression used to compute the result of the AnalysisCaseUsage , owned via a ResultExpressionMembership . Operations None. Constraints checkAnalysisCaseUsageSpecialization An AnalysisCaseUsage must directly or indirectly specialize the base AnalysisCaseUsage AnalysisCases::analysisCases from the Systems Model Library. 372 Systems Modeling Language v2.0, Part 1 -specializesFromLibrary('AnalysisCases::analysisCases') checkAnalysisCaseUsageSubAnalysisCaseSpecialization A composite AnalysisCaseUsage whose owningType is an AnalysisCaseDefinition or AnalysisCaseUsage must specialize the AnalysisCaseUsage AnalysisCases::AnalysisCase::subAnalysisCases from the Systems Model Library. isComposite and owningType <> null and (owningType.oclIsKindOf(AnalysisCaseDefinition) or owningType.oclIsKindOf(AnalysisCaseUsage)) implies specializesFromLibrary('AnalysisCases::AnalysisCase::subAnalysisCases') deriveAnalysisCaseUsageResultExpression The resultExpression of a AnalysisCaseUsage is the ownedResultExpression of its ResultExpressionMembership , if any. resultExpression = let results : OrderedSet(ResultExpressionMembership) = featureMembersip-> selectByKind(ResultExpressionMembership) in if results->isEmpty() then null else results->first().ownedResultExpression endif Systems Modeling Language v2.0, Part 1 373 -8.3.24 Verification Cases Abstract Syntax 8.3.24.1 Overview +/verificationCaseOwningUsage +/verificationCaseOwningDefinition Usage Definition 0..1 0..1 {subsets caseOwningUsage} {subsets caseOwningDefinition} OccurrenceDefinition OccurrenceUsage ActionDefinition ActionUsage CalculationDefinition CalculationUsage CaseDefinition CaseUsage VerificationCaseUsage +/ownedVerificationCase 0..* +/nestedVerificationCase {subsets ownedCase, ordered} 0..* {subsets nestedCase, ordered} +/verificationCaseDefinition +/definedVerificationCase VerificationCaseDefinition 0..1 0..* +verifyingCaseDefinition 0..* {subsets caseDefinition} {subsets definedCase} 0..* +/verifyingCase +/verifiedRequirement +/verifiedRequirement RequirementUsage 0..* 0..* {ordered} {ordered} Figure 45. Verification Case Definition and Usage RequirementConstraintMembership RequirementVerificationMembership +/requirementVerification +kind : RequirementConstraintKind = requirement{redefines kind} 0..* {subsets referencingConstraintMembership} +/requirementVerificationMembership 0..1 {subsets requirementConstraintMembership} {redefines ownedConstraint} +/ownedRequirement 1 +/verifiedRequirement RequirementUsage 1 {redefines referencedConstraint} Figure 46. Verification Membership 374 Systems Modeling Language v2.0, Part 1 -8.3.24.2 RequirementVerificationMembership Description A RequirementVerificationMembership is a RequirementConstraintMembership used in the objective of a VerificationCase to identify a RequirementUsage that is verified by the VerificationCase . General Classes RequirementConstraintMembership Attributes kind : RequirementConstraintKind {redefines kind} The kind of a RequirementVerificationMembership must be requirement . /ownedRequirement : RequirementUsage {redefines ownedConstraint} The owned RequirementUsage that acts as the ownedConstraint for this RequirementVerificationMembership . This will either be the verifiedRequirement , or it will subset the verifiedRequirement . /verifiedRequirement : RequirementUsage {redefines referencedConstraint} The RequirementUsage that is identified as being verified. It is the referencedConstraint of the RequirementVerificationMembership considered as a RequirementConstraintMembership , which must be a RequirementUsage . Operations None. Constraints validateRequirementVerificationMembershipKind A RequirementVerificationMembership must have kind = requirement . kind = RequirementConstraintKind::requirement validateRequirementVerificationMembershipOwningType The owningType of a RequirementVerificationMembership must a RequirementUsage that is owned by an ObjectiveMembership . owningType.oclIsKindOf(RequirementUsage) and owningType.owningFeatureMembership <> null and owningType.owningFeatureMembership.oclIsKindOf(ObjectiveMembership) 8.3.24.3 VerificationCaseDefinition Description A VerificationCaseDefinition is a CaseDefinition for the purpose of verification of the subject of the case against its requirements. Systems Modeling Language v2.0, Part 1 375 -General Classes CaseDefinition Attributes /verifiedRequirement : RequirementUsage [0..*] {ordered} The RequirementUsages verified by this VerificationCaseDefinition , which are the verifiedRequirements of all RequirementVerificationMemberships of the objectiveRequirement . Operations None. Constraints checkVerificationCaseSpecialization A VerificationCaseDefinition must directly or indirectly specialize the base VerificationCaseDefinition VerificationCases::VerificationCase from the Systems Model Library. specializesFromLibrary('VerificationCases::VerificationCase') deriveVerificationCaseDefinitionVerifiedRequirement The verifiedRequirements of a VerificationCaseDefinition are the verifiedRequirements of its RequirementVerificationMemberships . verifiedRequirement = if objectiveRequirement = null then OrderedSet{} else objectiveRequirement.featureMembership-> selectByKind(RequirementVerificationMembership). verifiedRequirement->asOrderedSet() endif 8.3.24.4 VerificationCaseUsage Description A VerificationCaseUsage is a Usage of a VerificationCaseDefinition . General Classes CaseUsage Attributes /verificationCaseDefinition : VerificationCaseDefinition [0..1] {subsets caseDefinition} The VerificationCase that is the definition of this VerificationCaseUsage . /verifiedRequirement : RequirementUsage [0..*] {ordered} 376 Systems Modeling Language v2.0, Part 1 -The RequirementUsages verified by this VerificationCaseUsage , which are the verifiedRequirements of all RequirementVerificationMemberships of the objectiveRequirement . Operations None. Constraints checkVerificationCaseUsageSpecialization A VerificationCaseUsage must subset, directly or indirectly, the base VerificationCaseUsage VerificationCases::verificationCases from the Systems Model Library. specializesFromLibrary('VerificationCases::verificationCases') checkVerificationCaseUsageSubVerificationCaseSpecialization If it is composite and owned by a VerificationCaseDefinition or VerificationCaseUsage , then it must specialize VerificationCaseUsage VerificationCases::VerificationCase::subVerificationCases . isComposite and owningType <> null and (owningType.oclIsKindOf(VerificationCaseDefinition) or owningType.oclIsKindOf(VerificationCaseUsage)) implies specializesFromLibrary('VerificationCases::VerificationCase::subVerificationCases') deriveVerificationCaseUsageVerifiedRequirement The verifiedRequirements of a VerificationCaseUsage are the verifiedRequirements of its RequirementVerificationMemberships . verifiedRequirement = if objectiveRequirement = null then OrderedSet{} else objectiveRequirement.featureMembership-> selectByKind(RequirementVerificationMembership). verifiedRequirement->asOrderedSet() endif Systems Modeling Language v2.0, Part 1 377 -8.3.25 Use Cases Abstract Syntax 8.3.25.1 Overview +/useCaseOwningDefinition +/useCaseOwningUsage Definition Usage 0..1 0..1 {subsets {subsets caseOwningDefinition} caseOwningUsage} OccurrenceDefinition OccurrenceUsage ActionDefinition ActionUsage CalculationDefinition CalculationUsage CaseDefinition CaseUsage +/nestedUseCase +/ownedUseCase UseCaseDefinition UseCaseUsage 0..* 0..* {subsets ownedCase, ordered} {subsets nestedCase, ordered} +/includingUseCaseDefinition +/includedUseCase +/includedUseCase 0..* 0..* 0..* {ordered} {ordered} +/includingUseCase +/useCaseDefinition +/definedUseCase 0..1 0..* 0..* {redefines caseDefinition} {subsets definedCase} Figure 47. Use Case Definition and Usage +/useCaseIncluded PerformActionUsage UseCaseUsage 1 {redefines performedAction} +/useCaseInclusion IncludeUseCaseUsage 0..* {subsets performingAction} Figure 48. Included Use Case 8.3.25.2 IncludeUseCaseUsage Description An IncludeUseCaseUsage is a UseCaseUsage that represents the inclusion of a UseCaseUsage by a UseCaseDefinition or UseCaseUsage . Unless it is the IncludeUseCaseUsage itself, the UseCaseUsage to be included is related to the includedUseCase by a ReferenceSubsetting Relationship . An IncludeUseCaseUsage is also a PerformActionUsage, with its useCaseIncluded as the performedAction . General Classes 378 Systems Modeling Language v2.0, Part 1 -PerformActionUsage UseCaseUsage Attributes /useCaseIncluded : UseCaseUsage {redefines performedAction} The UseCaseUsage to be included by this IncludeUseCaseUsage . It is the performedAction of the IncludeUseCaseUsage considered as a PerformActionUsage , which must be a UseCaseUsage . Operations None. Constraints checkIncludeUseCaseSpecialization A IncludeUseCaseUsage whose owningType is a UseCaseDefinition or UseCaseUsage must directly or indirectly specialize the UseCaseUsage UseCases::UseCase::includedUseCases from the Systems Model Library. owningType <> null and (owningType.oclIsKindOf(UseCaseDefinition) or owningType.oclIsKindOf(UseCaseUsage) implies specializesFromLibrary('UseCases::UseCase::includedUseCases') validateIncludeUseCaseUsageReference If an IncludeUseCaseUsage has an ownedReferenceSubsetting , then the featureTarget of the referencedFeature must be a UseCaseUsage . referencedFeatureTarget() <> null implies referencedFeatureTarget().oclIsKindOf(UseCaseUsage) 8.3.25.3 UseCaseDefinition Description A UseCaseDefinition is a CaseDefinition that specifies a set of actions performed by its subject, in interaction with one or more actors external to the subject. The objective is to yield an observable result that is of value to one or more of the actors. General Classes CaseDefinition Attributes /includedUseCase : UseCaseUsage [0..*] {ordered} The UseCaseUsages that are included by this UseCaseDefinition , which are the useCaseIncludeds of the IncludeUseCaseUsages owned by this UseCaseDefinition. Operations None. Systems Modeling Language v2.0, Part 1 379 -Constraints checkUseCaseDefinitionSpecialization A UseCaseDefinition must directly or indirectly specializes the base UseCaseDefinition UseCases::UseCase from the Systems Model Library. specializesFromLibrary('UseCases::UseCase') deriveUseCaseDefinitionIncludedUseCase The includedUseCases of a UseCaseDefinition are the useCaseIncludeds of the IncludeUseCaseUsages owned by the UseCaseDefinition. includedUseCase = ownedUseCase-> selectByKind(IncludeUseCaseUsage). useCaseIncluded 8.3.25.4 UseCaseUsage Description A UseCaseUsage is a Usage of a UseCaseDefinition . General Classes CaseUsage Attributes /includedUseCase : UseCaseUsage [0..*] {ordered} The UseCaseUsages that are included by this UseCaseUse , which are the useCaseIncludeds of the IncludeUseCaseUsages owned by this UseCaseUsage. /useCaseDefinition : UseCaseDefinition [0..1] {redefines caseDefinition} The UseCaseDefinition that is the definition of this UseCaseUsage . Operations None. Constraints checkUseCaseUsageSpecialization A UseCaseUsage must directly or indirectly specializes the base UseCaseUsage UseCases::useCases from the Systems Model Library. specializesFromLibrary('UseCases::useCases') checkUseCaseUsageSubUseCaseSpecialization A composite UseCaseUsage whose owningType is a UseCaseDefinition or UseCaseUsage must specialize the UseCaseUsage UseCases::UseCase::subUseCases from the Systems Model Library. 380 Systems Modeling Language v2.0, Part 1 -isComposite and owningType <> null and (owningType.oclIsKindOf(UseCaseDefinition) or owningType.oclIsKindOf(UseCaseUsage)) implies specializesFromLibrary('UseCases::UseCase::subUseCases') deriveUseCaseUsageIncludedUseCase The includedUseCases of a UseCaseUsage are the useCaseIncludeds of the IncludeUseCaseUsages owned by the UseCaseUsage. includedUseCase = ownedUseCase-> selectByKind(IncludeUseCaseUsage). useCaseIncluded 8.3.26 Views and Viewpoints Abstract Syntax 8.3.26.1 Overview +/viewOwningDefinition +/viewOwningUsage Definition Usage 0..1 0..1 {subsets partOwningDefinition} {subsets partOwningUsage} OccurrenceDefinition OccurrenceUsage ItemDefinition ItemUsage PartDefinition PartUsage {subsets nestedPart, ordered} +/nestedView 0..* +/ownedView ViewDefinition ViewUsage 0..* +includeAsExposed( element : Element ) : Boolean {subsets ownedPart, ordered} +/viewDefinition +/definedView 0..1 0..* {redefines partDefinition} {subsets definedPart} +/featuringView +/view +/exposingView +/exposedElement Element 0..* 0..* 0..* 0..* {subsets featuringDefinition} {subsets usage, {subsets namespace} {subsets member, ordered} ordered} +/owningViewDefinition +/viewCondition +/viewCondition +/owningView Expression 0..1 0..* 0..* 0..1 {subsets {subsets ownedMember, {subsets ownedMember, {subsets owningType} ordered} ordered} owningType} +/renderingOwningViewDefinition 0..1 0..1 +viewpointSatisfyingViewDefinition +/viewpointSatisfyingView 0..1 0..1 +/renderingOwningView {subsets owningDefinition} {subsets owningDefinition} {subsets featuringUsage} {subsets owningUsage} +/satisfiedViewpoint +/satisfiedViewpoint ViewpointUsage 0..* 0..* {subsets {subsets nestedRequirement, ownedRequirement, ordered} ordered} +/viewRendering +/viewRendering RenderingUsage 0..1 0..1 Figure 49. View Definition and Usage Systems Modeling Language v2.0, Part 1 381 -+/viewpointOwningUsage +/viewpointOwningDefinition Definition Usage 0..1 0..1 {subsets requirementOwningDefinition} {subsets requirementOwningUsage} OccurrenceDefinition OccurrenceUsage ConstraintDefinition ConstraintUsage RequirementDefinition RequirementUsage +/ownedViewpoint ViewpointUsage 0..* {subsets ownedRequirement, ordered} +/nestedViewpoint +/viewpointDefinition +/definedViewpoint ViewpointDefinition 0..* 0..1 0..* {subsets nestedRequirement, ordered} {redefines requirementDefinition} {subsets definedRequirement} +/viewpointDefinitionForStakeholder 0..1 +/viewpointForStakeholder 0..1 +/viewpointStakeholder +/viewpointStakeholder PartUsage 0..* 0..* {ordered} {ordered} Figure 50. Viewpoint Definition and Usage +/redenderingOwningDefinition +/renderingOwningUsage Definition Usage 0..1 0..1 {subsets partOwningDefinition} {subsets partOwningUsage} OccurrenceDefinition OccurrenceUsage ItemDefinition ItemUsage PartDefinition PartUsage +/ownedRendering RenderingUsage 0..* {subsets ownedPart, ordered} +/renderingDefinition +/definedRendering +/nestedRendering RenderingDefinition 0..1 0..* 0..* {redefines partDefinition} {subsets definedPart} {subsets nestedPart, ordered} +/featuringRenderingDefinition +/rendering 0..* 0..* {subsets featuringDefinition} {subsets usage, ordered} Figure 51. Rendering Definition and Usage 382 Systems Modeling Language v2.0, Part 1 -+/ownedImport +/importOwningNamespace Import Namespace 0..* 1 +importedNamespace 1 Expose +visibility : VisibilityKind = protected{redefines visibility} +isImportAll : Boolean = true{redefines isImportAll} MembershipExpose NamespaceExpose +import MembershipImport NamespaceImport 0..* +import 0..* +importedMembership 1 Membership Figure 52. Expose Relationship FeatureMembership +/referencingRenderingMembership ViewRenderingMembership 0..* +/viewRenderingMembership 0..1 {redefines ownedMemberFeature} +/ownedRendering 1 +/referencedRendering RenderingUsage 1 Figure 53. View Rendering Membership 8.3.26.2 Expose Description An Expose is an Import of Memberships into a ViewUsage that provide the Elements to be included in a view. Visibility is always ignored for an Expose (i.e., isImportAll = true ). General Classes Systems Modeling Language v2.0, Part 1 383 -Import Attributes isImportAll : Boolean {redefines isImportAll} An Expose always imports all Elements , regardless of visibility ( isImportAll = true ). visibility : VisibilityKind {redefines visibility} An Expose always has protected visibility. Operations None. Constraints validateExposeIsImportAll An Expose always imports all Elements , regardless of visibility. isImportAll validateExposeOwningNamespace The importOwningNamespace of an Expose must be a ViewUsage . importOwningNamespace.oclIsType(ViewUsage) validateExposeVisibility An Expose always has protected visibility. visibility = VisibilityKind::protected 8.3.26.3 MembershipExpose Description A MembershipExpose is an Expose that exposes a specific importedMembership and, if isRecursive = true , additional Memberships recursively. General Classes MembershipImport Expose Attributes None. Operations None. Constraints 384 Systems Modeling Language v2.0, Part 1 -None. 8.3.26.4 NamespaceExpose Description A NamespaceExpose is an Expose Relationship that exposes the Memberships of a specific importedNamespace and, if isRecursive = true , additional Memberships recursively. General Classes NamespaceImport Expose Attributes None. Operations None. Constraints None. 8.3.26.5 RenderingDefinition Description A RenderingDefinition is a PartDefinition that defines a specific rendering of the content of a model view (e.g., symbols, style, layout, etc.). General Classes PartDefinition Attributes /rendering : RenderingUsage [0..*] {subsets usage, ordered} The usages of a RenderingDefinition that are RenderingUsages . Operations None. Constraints checkRenderingDefinitionSpecialization A RenderingDefinition must directly or indirectly specialize the base RenderingDefinition Views::Rendering from the Systems Model Library. specializesFromLibrary('Views::Rendering') Systems Modeling Language v2.0, Part 1 385 -deriveRenderingDefinitionRendering The renderings of a RenderingDefinition are all its usages that are RenderingUsages . rendering = usages->selectByKind(RenderingUsage) 8.3.26.6 RenderingUsage Description A RenderingUsage is the usage of a RenderingDefinition to specify the rendering of a specific model view to produce a physical view artifact. General Classes PartUsage Attributes /renderingDefinition : RenderingDefinition [0..1] {redefines partDefinition} The RenderingDefinition that is the definition of this RenderingUsage . Operations None. Constraints checkRenderingUsageRedefinition A RenderingUsage whose owningFeatureMembership is a ViewRenderingMembership must redefine the RenderingUsage Views::View::viewRendering . owningFeatureMembership <> null and owningFeatureMembership.oclIsKindOf(ViewRenderingMembership) implies redefinesFromLibrary('Views::View::viewRendering') checkRenderingUsageSpecialization A RenderingUsage must directly or indirectly specialize the base RenderingUsage Views::renderings from the Systems Model Library. specializesFromLibrary('Views::renderings') checkRenderingUsageSubrenderingSpecialization A RenderingUsage whose owningType is a RenderingDefinition or RenderingUsage must directly or indirectly specialize the RenderingUsage Views::Rendering::subrenderings from the Systems Model Library. owningType <> null and (owningType.oclIsKindOf(RenderingDefinition) or owningType.oclIsKindOf(RenderingUsage)) implies specializesFromLibrary('Views::Rendering::subrenderings') 386 Systems Modeling Language v2.0, Part 1 -8.3.26.7 ViewDefinition Description A ViewDefinition is a PartDefinition that specifies how a view artifact is constructed to satisfy a viewpoint . It specifies a viewConditions to define the model content to be presented and a viewRendering to define how the model content is presented. General Classes PartDefinition Attributes /satisfiedViewpoint : ViewpointUsage [0..*] {subsets ownedRequirement, ordered} The composite ownedRequirements of this ViewDefinition that are ViewpointUsages for viewpoints satisfied by the ViewDefinition . /view : ViewUsage [0..*] {subsets usage, ordered} The usages of this ViewDefinition that are ViewUsages . /viewCondition : Expression [0..*] {subsets ownedMember, ordered} The Expressions related to this ViewDefinition by ElementFilterMemberships , which specify conditions on Elements to be rendered in a view. /viewRendering : RenderingUsage [0..1] The RenderingUsage to be used to render views defined by this ViewDefinition , which is the referencedRendering of the ViewRenderingMembership of the ViewDefinition . Operations None. Constraints checkViewDefinitionSpecialization A ViewDefinition must directly or indirectly specialize the base ViewDefinition Views::View from the Systems Model Library. specializesFromLibrary('Views::View') deriveViewDefinitionSatisfiedViewpoint The satisfiedViewpoints of a ViewDefinition are its ownedRequirements that are composite ViewpointUsages satisfiedViewpoint = ownedRequirement-> selectByKind(ViewpointUsage)-> select(isComposite) deriveViewDefinitionView Systems Modeling Language v2.0, Part 1 387 -The views of a ViewDefinition are all its usages that are ViewUsages . view = usage->selectByKind(ViewUsage) deriveViewDefinitionViewCondition The viewConditions of a ViewDefinition are the conditions of its owned ElementFilterMemberships . viewCondition = ownedMembership-> selectByKind(ElementFilterMembership). condition deriveViewDefinitionViewRendering The viewRendering of a ViewDefinition is the referencedRendering of its owned ViewRenderingMembership, if any. viewRendering = let renderings: OrderedSet(ViewRenderingMembership) = featureMembership->selectByKind(ViewRenderingMembership) in if renderings->isEmpty() then null else renderings->first().referencedRendering endif validateViewDefinitionOnlyOneViewRendering A ViewDefinition must have at most one ViewRenderingMembership . featureMembership-> selectByKind(ViewRenderingMembership)-> size() <= 1 8.3.26.8 ViewpointDefinition Description A ViewpointDefinition is a RequirementDefinition that specifies one or more stakeholder concerns that are to be satisfied by creating a view of a model. General Classes RequirementDefinition Attributes /viewpointStakeholder : PartUsage [0..*] {ordered} The PartUsages that identify the stakeholders with concerns framed by this ViewpointDefinition , which are the owned and inherited stakeholderParameters of the framedConcerns of this ViewpointDefinition . Operations None. Constraints checkViewpointDefinitionSpecialization 388 Systems Modeling Language v2.0, Part 1 -A ViewpointDefinition must directly or indirectly specialize the base ViewpointDefinition Views::Viewpoint from the Systems Model Library. specializesFromLibrary('Views::Viewpoint') deriveViewpointDefinitionViewpointStakeholder The viewpointStakeholders of a ViewpointDefinition are the ownedStakeholderParameters of all featureMemberships that are StakeholderMemberships . viewpointStakeholder = framedConcern.featureMemberhsip-> selectByKind(StakeholderMembership). ownedStakeholderParameter 8.3.26.9 ViewpointUsage Description A ViewpointUsage is a Usage of a ViewpointDefinition . General Classes RequirementUsage Attributes /viewpointDefinition : ViewpointDefinition [0..1] {redefines requirementDefinition} The ViewpointDefinition that is the definition of this ViewpointUsage. /viewpointStakeholder : PartUsage [0..*] {ordered} The PartUsages that identify the stakeholders with concerns framed by this ViewpointUsage , which are the owned and inherited stakeholderParameters of the framedConcerns of this ViewpointUsage . Operations None. Constraints checkViewpointUsageSpecialization A ViewpointUsage must directly or indirectly specialize the base ViewpointUsage Views::viewpoints from the Systems Model Library. specializesFromLibrary('Views::viewpoints') checkViewpointUsageViewpointSatisfactionSpecialization A composite ViewpointUsage whose owningType is a ViewDefinition or ViewUsage must directly or indirectly specialize the ViewpointUsage Views::View::viewpointSatisfactions from the Systems Model Library. isComposite and owningType <> null and (owningType.oclIsKindOf(ViewDefinition) or Systems Modeling Language v2.0, Part 1 389 -owningType.oclIsKindOf(ViewUsage)) implies specializesFromLibrary('Views::View::viewpointSatisfactions') deriveViewpointUsageViewpointStakeholder The viewpointStakeholders of a ViewpointUsage are the ownedStakeholderParameters of all featureMemberships that are StakeholderMemberships . viewpointStakeholder = framedConcern.featureMemberhsip-> selectByKind(StakeholderMembership). ownedStakeholderParameter 8.3.26.10 ViewRenderingMembership Description A ViewRenderingMembership is a FeatureMembership that identifies the viewRendering of a ViewDefinition or ViewUsage . General Classes FeatureMembership Attributes /ownedRendering : RenderingUsage {redefines ownedMemberFeature} The owned RenderingUsage that is either itself the referencedRendering or subsets the referencedRendering /referencedRendering : RenderingUsage The RenderingUsage that is referenced through this ViewRenderingMembership . It is the referencedFeature of the ownedReferenceSubsetting for the ownedRendering , if there is one, and, otherwise, the ownedRendering itself. Operations None. Constraints deriveVewRenderingMembershipReferencedRendering The referencedRendering of a ViewRenderingMembership is the the featureTarget of the referencedFeature of the ownedReferenceSubsetting (which must be a RenderingUsage ) of the ownedRendering , if there is one, and, otherwise, the ownedRendering itself. referencedRendering = let referencedFeature : Feature = ownedRendering.referencedFeatureTarget() in if referencedFeature = null then ownedRendering else if referencedFeature.oclIsKindOf(RenderingUsage) then refrencedFeature.oclAsType(RenderingUsage) else null endif endif validateViewRenderingMembershipOwningType 390 Systems Modeling Language v2.0, Part 1 -The owningType of a ViewRenderingMembership must be a ViewDefinition or a ViewUsage . owningType.oclIsKindOf(ViewDefinition) or owningType.oclIsKindOf(ViewUsage) 8.3.26.11 ViewUsage Description A ViewUsage is a usage of a ViewDefinition to specify the generation of a view of the members of a collection of exposedNamespaces . The ViewUsage can satisfy more viewpoints than its definition, and it can specialize the viewRendering specified by its definition. General Classes PartUsage Attributes /exposedElement : Element [0..*] {subsets member, ordered} The Elements that are exposed by this ViewUsage , which are those memberElements of the imported Memberships from all the Expose Relationships that meet all the owned and inherited viewConditions . /satisfiedViewpoint : ViewpointUsage [0..*] {subsets nestedRequirement, ordered} The nestedRequirements of this ViewUsage that are ViewpointUsages for (additional) viewpoints satisfied by the ViewUsage . /viewCondition : Expression [0..*] {subsets ownedMember, ordered} The Expressions related to this ViewUsage by ElementFilterMemberships , which specify conditions on Elements to be rendered in a view. /viewDefinition : ViewDefinition [0..1] {redefines partDefinition} The ViewDefinition that is the definition of this ViewUsage . /viewRendering : RenderingUsage [0..1] The RenderingUsage to be used to render views defined by this ViewUsage , which is the referencedRendering of the ViewRenderingMembership of the ViewUsage . Operations includeAsExposed(element : Element) : Boolean Determine whether the given element meets all the owned and inherited viewConditions . body: let metadataFeatures: Sequence(AnnotatingElement) = element.ownedAnnotation.annotatingElement-> select(oclIsKindOf(MetadataFeature)) in self.membership->selectByKind(ElementFilterMembership). condition->forAll(cond | metadataFeatures->exists(elem | cond.checkCondition(elem))) Systems Modeling Language v2.0, Part 1 391 -Constraints checkViewUsageSpecialization A ViewUsage must directly or indirectly specialize the base ViewUsage Views::views from the Systems Model Library. specializesFromLibrary('Views::views') checkViewUsageSubviewSpecialization A ViewUsage whose owningType is a ViewDefinition or ViewUsage must specialize the ViewUsage Views::View::subviews from the Systems Library Model. owningType <> null and (owningType.oclIsKindOf(ViewDefinition) or owningType.oclIsKindOf(ViewUsage)) implies specializesFromLibrary('Views::View::subviews') deriveViewUsageExposedElement The exposedElements of a ViewUsage are those memberElements of the imported Memberships from all the Expose Relationships for which the includeAsExposed operation returns true. exposedElement = ownedImport->selectByKind(Expose). importedMemberships(Set{}).memberElement-> select(elm | includeAsExposed(elm))-> asOrderedSet() deriveViewUsageSatisfiedViewpoint The satisfiedViewpoints of a ViewUsage are its ownedRequirements that are composite ViewpointUsages satisfiedViewpoint = ownedRequirement-> selectByKind(ViewpointUsage)-> select(isComposite) deriveViewUsageViewCondition The viewConditions of a ViewUsage are the conditions of its owned ElementFilterMemberships . viewCondition = ownedMembership-> selectByKind(ElementFilterMembership). condition deriveViewUsageViewRendering The viewRendering of a ViewUsage is the referencedRendering of its owned ViewRenderingMembership, if any. viewRendering = let renderings: OrderedSet(ViewRenderingMembership) = featureMembership->selectByKind(ViewRenderingMembership) in if renderings->isEmpty() then null else renderings->first().referencedRendering endif 392 Systems Modeling Language v2.0, Part 1 -validateViewUsageOnlyOneViewRendering A ViewUsage must have at most one ViewRenderingMembership . featureMembership-> selectByKind(ViewRenderingMembership)-> size() <= 1 8.3.27 Metadata Abstract Syntax 8.3.27.1 Overview +/metadataOwningDefinition +/metadataOwningUsage Definition Usage 0..1 0..1 {subsets {subsets itemOwningDefinition} itemOwningUsage} OccurrenceDefinition OccurrenceUsage ItemDefinition ItemUsage +/ownedMetadata MetadataDefinition MetadataUsage 0..* {subsets ownedItem, +/nestedMetadata ordered} 0..* {subsets nestedItem, +/definedMetadata +/metadataDefinition Metaclass ordered} 0..1 0..* {redefines itemDefinition, {subsets definedItem, redefines metaclass} subsets typedMetadata} MetadataFeature Figure 54. Metadata Definition and Usage 8.3.27.2 MetadataDefinition Description A MetadataDefinition is an ItemDefinition that is also a Metaclass . General Classes ItemDefinition Metaclass Attributes None. Operations None. Systems Modeling Language v2.0, Part 1 393 -Constraints checkMetadataDefinitionSpecialization A MetadataDefinition must directly or indirectly specialize the base MetadataDefinition Metadata::MetadataItem from the Systems Model Library. specializesFromLibrary('Metadata::MetadataItem') 8.3.27.3 MetadataUsage Description A MetadataUsage is a Usage and a MetadataFeature , used to annotate other Elements in a system model with metadata. As a MetadataFeature , its type must be a Metaclass , which will nominally be a MetadataDefinition . However, any kernel Metaclass is also allowed, to permit use of Metaclasses from the Kernel Model Libraries. General Classes MetadataFeature ItemUsage Attributes /metadataDefinition : Metaclass [0..1] {redefines itemDefinition, metaclass} The MetadataDefinition that is the definition of this MetadataUsage . Operations None. Constraints checkMetadataUsageSpecialization A MetadataUsage must directly or indirectly specialize the base MetadataUsage Metadata::metadataItems from the Systems Model Library. specializesFromLibrary('Metadata::metadataItems') 8.4 Semantics 8.4.1 Semantics Overview The semantics of constructs in SysML are specified in terms of the constructs defined in KerML supported by reuse of model elements from the Kernel Semantic Model Library (see [KerML, 9.2]) and the Systems Model Library (see 9.2 ). This is similar to how the KerML Kernel Layer semantics are build on the KerML Core Layer (see [KerML, 8.4.4.1]). The semantic requirements are formalized by semantic constraints included in the SysML abstract syntax (see also 8.3.1 on the various kinds of constraints in the abstract syntax). Additionally, other semantic constraints require relationships between elements within a user model necessary for the model to be semantically well formed. Specifically, there are four categories of semantic constraints used to specify SysML semantics, each dealing with a different kind of relationship. 394 Systems Modeling Language v2.0, Part 1 -1. Specialization constraints. These constraints require that Definition or Usage elements of a certain kind directly or indirectly specialize some specific base Definition or Usage from the Kernel Semantic Library or the Systems Model Library. They are the fundamental means for providing semantics to abstract syntax elements in SysML. Specialization constraints always have the word Specialization in their name. For example, checkPartDefinitionSpecialization requires that a PartDefinition directly or indirectly specialize the PartDefinition Parts::Part from the Systems Model Library. 2. Redefinition constraints. These constraints require that certain Usages in a model have Redefinition relationships with certain other Usages (or KerML Features ) in the model. While Redefinitions are kinds of Specializations , redefinition constraints differ from the specialization constraints described above because of the specific semantics of redefinition. Redefinition constraints always have the word Redefinition in their name. For example, checkRenderingUsageRedefinition requires a Redefinition on a RenderingUsage used to specify a viewRendering . 3. Type-featuring constraints. These constraints require that certain Usages in a model have TypeFeaturing relationships with certain other Definitions or Usages in the model. The SysML specification includes only one constraint in this category, checkVariationUsageTypeFeaturing , which applies to a variant Usage in a variation model. However, various type-featuring constraints from KerML also apply to corresponding SysML constructs. For instance, the KerML checkConnectorTypeFeaturing also applies to SysML ConnectionUsages . 4. Binding-connector constraints. These constraints require that BindingConnectors exist between certain Features in a model. For example, checkSatisfyRequirementUsageBindingConnector requires that the satisfyingFeature of a SatisfyRequirementUsage be bound to the subject of the SatisfyRequirementUsage . (In a SysML model, it is allowable for binding-connector constraints to be satisfied by SysML BindingConnectorAsUsages , rather than plain KerML BindingConnectors .) A SysML model parsed from the textual or graphical concrete syntax (see 8.2 ) or obtained through model interchange (see [KerML, Clause 10]) will not necessarily meet the semantic constraints specified for the abstract syntax. In this case, a tool may insert certain implied Relationships into the model in order to meet the semantic constraints. In all cases, the semantics of a model are only defined if it meets all semantic and validation constraints (see 8.3.1 ). For specialization constraints applying to Definitions , the implied Relationship is a Subclassification , as given in Table 31 . For specialization constraints applying to Usages , the implied Relationship is a Subsetting , as given in Table 32 . For redefinition, type-featuring and binding-connector constraints, the implied Relationship is a Redefinition , TypeFeaturing , or BindingConnector , as given in Table 33 . Note that an implied Relationship should only be added if the constraint would actually be violated otherwise. For the detailed conditions on when a constraint applies, see its specification in the abstract syntax model ( 8.3 ). When including implied Relationships for specialization constraints, it is possible that multiple such constraints may apply to a single Element . For example, a PartDefinition is a kind of ItemDefinition , which is a kind of OccurrenceDefinition , and there are specialization constraints for all three of these metaclasses, with corresponding implied Subclassification Relationships . However, simply including all three implied Subclassification would be redundant, because the Subclassification implied by the checkPartDefinitionSpecialization constraint will also automatically satisfy the checkItemDefinitionSpecialization and checkOccurrenceDefinitionSpecialization constraints. Therefore, in order to avoid redundant Relationships , a tool should observe the following rules when selecting which Specializations to actually include for a certain constrained Element , out of the set of those implied by all specialization constraints applicable to the Element : 1. If there is any ownedSpecialization or other implied Specialization whose general Type is a direct or indirect subtype of (but not the same as) the general Type of an implied Specialization , or if there is an ownedSpecialization with the same general Type , then that implied Specialization should not be included. 2. If there are two implied Specializations with the same general Type , then only one should be included. Systems Modeling Language v2.0, Part 1 395 -Note that the above rules do not apply to Redefinitions implied by redefinition constraints, because Redefinition relationships have semantics beyond just basic Specialization . The following subclauses specify the semantics for each syntactic area of SysML in terms of the semantic constraints that must be satisfied for various Elements , the pattern of Relationships these imply, and the model library Elements that are reused to support this. For compactness, the textual notation is used in these subclauses to present model snippets to illustrate the semantic patterns being discussed. However, it should be understood that, like the semantic constraints themselves, these semantic patterns are actually defined on the abstract syntax representation of a model, independent of its textual or graphical concrete syntax representation. Table 31. Implied Definition Subclassification Relationships Subclassification Target Semantic Constraint (see Note 1) checkOccurrenceDefinitionIndividual Occurrences::Life Specialization checkItemDefinitionSpecialization Items::Item checkPartDefinitionSpecialization Parts::Part checkPortDefinitionSpecialization Ports::Port checkConnectionDefinitionSpecialization Connections::Connection checkConnectionDefinitionBinarySpecialization Connections::BinaryConnection checkInterfaceDefinitionSpecialization Interfaces::Interface checkInterfaceDefinitionBinarySpecialization Interface::BinaryInterface checkAllocationDefinitionSpecialization Allocations::Allocation checkFlowDefinitionSpecialization Flows::MessageAction checkFlowDefinitionBinarySpecialization Flows::Message checkActionDefinitionSpecialization Actions::Action checkStateDefinitionSpecialization States::StateAction checkCalculationDefinitionSpecialization Calculations::Calculation checkConstraintDefinitionSpecialization Constraints::ConstraintCheck checkRequirementDefinitionSpecialization Requirements::RequirementCheck checkConcernDefinitionSpecialization Concerns::ConcernCheck checkCaseDefinitionSpecialization Cases::Case checkAnalysisCaseDefinitionSpecialization AnalysisCases::AnalysisCase checkVerificationCaseDefinitionSpecialization VerificationCases::VerificationCase checkUseCaseDefinitionSpecialization UseCases::UseCase checkViewDefinitionSpecialization Views::View checkViewpointDefinitionSpecialization Views::ViewpointCheck checkRenderingDefinitionSpecialization Views::Rendering checkMetadataDefinitionSpecialization Views::MetadataItem 396 Systems Modeling Language v2.0, Part 1 -Notes 1. In all cases, the source of the Subclassification is the Definition to which the constraint applies. Table 32. Implied Usage Subsetting Relationships Subsetting Target Semantic Constraint (see Note 1) checkUsageVariationUsageSpecialization owningVariationUsage of the Usage checkAttributeUsageSpecialization Attributes::attributes Occurrences::Occurrence:: checkEventOccurrenceSpecialization timeEnclosedOccurrences checkOccurrenceDefinitionMultiplicity Base::exactlyOne (source is the multiplicity of Specialization the OccurrenceDefinition ) checkOccurrenceUsageSpecialization Occurrences::occurrences checkOccurrenceUsageSuboccurrence Occurrences::Occurrence:: Specialization suboccurrences checkOccurrenceUsageSnapshot Occurrences::Occurrence:: Specialization snapshots checkOccurrenceUsageTimeSlice Occurrences::Occurrence:: Specialization timeSlices checkItemUsageSpecialization Items::items checkItemUsageSubitemSpecialization Items::Item::subitems checkPartUsageSpecialization Parts::parts checkPartUsageSubpartSpecialization Items::Item::subparts Requirements::Requirement::actors or checkPartUsageActorSpecialization Cases::Case::actors (depending on the owningType of the PartUsage ) Requirements::Requirement:: checkPartUsageStakeholderSpecialization stakeholders checkPortUsageSpecialization Ports::ports checkPortUsageSubportSpecialization Ports::Port::subports checkPortUsageOwnedPortSpecialization Parts::Part::ownedPorts checkConnectionUsageSpecialization Connections::connections checkConnectionUsageBinarySpecialization Connections::binaryConnections checkInterfaceUsageSpecialization Interfaces::interfaces checkInterfaceUsageBinarySpecialization Interfaces::binaryInterfaces checkAllocationUsageSpecialization Allocations::allocations checkFlowUsageSpecialization Flows::messages checkFlowUsageFlowSpecialization Flows::Flows Systems Modeling Language v2.0, Part 1 397 -Subsetting Target Semantic Constraint (see Note 1) checkSuccessionFlowUsage Flow::successionFlowss Specialization checkActionUsageSpecialization Actions::actions checkActionUsageSubactionSpecialization Actions::Action::subactions checkActionUsageOwnedActionSpecialization Parts::Part::ownedActions checkActionUsageAnalysisAction AnalysisCases::AnalysisCase:: Specialization analysisActions checkControlNodeSpecialization Actions::Action::controls checkJoinNodeSpecialization Actions::Action::joins checkForkNodeSpecialization Actions::Action::forks checkMergeNodeSpecialization Actions::Action::merges checkMergeNodeIncomingSuccession incomingHBLink of the MergeNode (source is the Specialization incoming Succession ) checkDecisionNodeSpecialization Actions::Action::decisions checkDecisionNodeOutgoingSuccession outgoingHBLink of the DecisionNode (source is the Specialization outgoing Succession ) checkSendActionUsageSpecialization Actions::sendActions checkSendActionUsageSubaction Actions::Action::sendSubactions Specialization checkAcceptActionUsageSpecialization Actions::acceptActions checkAcceptActionUsageSubaction Actions::Action::acceptSubctions Specialization checkAcceptActionUsageTriggerAction Actions::TransitionAction::accepter Specialization checkAssignmentActionUsageSpecialization Actions::assignmentActions checkAssignmentActionUsageSubaction Actions::Action::assignments Specialization checkTerminateActionUsageSpecialization Actions::terminateActions checkTerminateActionUsageSubaction Actions::Action::terminateSubactions Specialization Actions::ifThenActions or checkIfActionUsageSpecialization Actions::ifThenElseActions (depending on whether the IfActionUsage has an elseClause ) checkIfActionUsageSubactionSpecialization Actions::Action::ifSubactions checkWhileLoopActionUsageSpecialization Actions::whileLoopActions checkWhileLoopActionUsageSubaction Actions::Action::whileLoops Specialization 398 Systems Modeling Language v2.0, Part 1 -Subsetting Target Semantic Constraint (see Note 1) checkForLoopActionUsageSpecialization Actions::forLoopActions checkForLoopActionUsageSubaction Actions::Action::forLoops Specialization checkPerformActionUsageSpecialization Parts::Part::performedActions checkStateUsageSpecialization States::stateActions checkStateUsageOwnedStateSpecialization Parts::Part::ownedStates checkStateUsageSubstateSpecialization States::State::substates checkStateUsageExclusiveState States::State::exclusiveStates Specialization checkTransitionUsageSpecialization Actions::transitions checkTransitionUsageActionSpecialization Actions::Action::decisionTransitions checkTransitionUsageStateSpecialization States::StateAction::stateTransitions TransitionAction::triggerAction. checkTransitionUsagePayloadSpecialization payloadParameter (source is TransitionAction::payload ) source of the TransitionUsage (source is the checkTransitionUsageSuccessionSource sourceFeature of the succession of the Specialization TransitionUsage ; Relationship is a ReferenceSubsetting ) accepter , guard , or effect of Actions::TranstionActions (for the checkTransitionUsageTransitionFeature triggerActions , guardExpressions , and Specialization effectActions of the TransitionUsage , respectively) checkExhibitStateUsageSpecialization Parts::Part::exhibitedStates checkCalculationUsageSpecialization Calculations::calculations checkCalculationUsageSubcalculation Calculations::Calculation::subcalculations Specialization checkConstraintUsageSpecialization Constraints::constraintChecks checkConstraintUsageCheckedConstraint Items::Item::checkConstraints Specialization Requirements::RequirementCheck::assumptions or checkConstraintUsageRequirementConstraint Requirements::RequirementCheck::constraints Specialization (depending on whether the kind of the owning RequirementConstraintMembership is assumption or requirement ) Either Constraints::assertedConstraints (if isNegated = false ) or checkAssertConstraintUsageSpecialization Constraints::negatedConstraints (if isNegated = true ) Systems Modeling Language v2.0, Part 1 399 -Subsetting Target Semantic Constraint (see Note 1) checkRequirementUsageSpecialization Requirements::requirementChecks checkRequirementUsageSubrequirement Requirements::RequirementCheck:: Specialization subrequirement checkRequirementUsageRequirement VerificationCases::VerificationCase::obj:: VerificationSpecialization requirementVerifications checkConcernUsageSpecialization Requirements::concernChecks checkConcernUsageFramedConcern Requirements::RequirementCheck::concerns Specialization checkCaseUsageSpecialization Cases::Cases checkCaseUsageSubcaseSpecialization Cases::Case::subcases checkAnalysisCaseUsageSpecialization AnalysisCases::analysisCases checkAnalysisCaseUsageSubAnalysisCase AnalysisCases::AnalysisCase:: Specialization subAnalysisCases checkVerificationCaseUsageSpecialization VerificationCases::verificationCases checkVerificationCaseUsageSubVerification VerificationCases::VerificationCase:: CaseSpecialization subVerificationCases checkUseCaseUsageSpecialization UseCases::useCases checkUseCaseUsageSubUseCaseSpecialization UseCases::UseCase::subUseCases checkIncludeUseCaseUsageSpecialization UseCases::UseCase::includedUseCases checkViewUsageSpecialization Views::views checkViewUsageSubviewSpecialization Views::View::subviews checkViewpointUsageSpecialization Views::viewpoints checkViewpointUsageViewpointSatisfaction Views::View::viewpointSatisfactions Specialization checkRenderingUsageSpecialization Views::renderings checkRenderingUsageSubrendering Views::Rendering::subrenderings Specialization checkMetadataUsageSpecialization Metadata::metadataItems Notes 1. Unless otherwise indicated, the source of the Subsetting is the Usage to which the constraint applies. Table 33. Other Implied Relationships Semantic Constraint Source Target Redefinition 400 Systems Modeling Language v2.0, Part 1 -Semantic Constraint Source Target entryAction , doAction , or exitAction of checkActionUsageStateAction States::StateAction (depending The ActionUsage Redefinition on whether the kind of the owning StateSubactionMembership is entry , do , or exit , respectively) The first ownedFeature of the first checkAssignmentActionUsage ownedFeature of the first AssignmentAction::target:: AccessedFeatureRedefinition parameter of the startingAt::accessedFeature AssignmentActionUsage The first ownedFeature of the first checkAssignmentActionUsage ownedFeature of the first referent of the ReferentRedefinition parameter of the AssignmentActionUsage AssignmentActionUsage The first ownedFeature of the first checkAssignmentActionUsage AssignmentAction::target:: parameter of the StartingAtRedefinition startingAt AssignmentActionUsage The objectiveRequirement of each CaseDefinition or checkRequirementUsage The RequirementUsage CaseUsage specialized by the ObjectiveSpecialization owningType of the RequirementUsage . checkRenderingUsage The RenderingUsage Views::View::viewRendering Redefinition TypeFeaturing featuringTypes of the checkUsageVariationUsage The Usage owningVariationUsage of the TypeFeaturing Usage BindingConnector (see Note 1) The receiver parameter (second The receiver parameter (second checkAcceptActionUsage parameter ) of the parameter ) of the ReceiverBindingConnector AcceptActionUsage TriggerInvocationExpression The transitionLinkSource checkTransitionUsageSource The source of the parameter (first input parameter ) BindingConnector TransitionUsage of the TransitionUsage TransitionPerformances:: checkTransitionUsage The succession of the TransitionPerformance:: SuccessionBindingConnector TransitionUsage transitionLink checkSatisfyRequirement subjectParameter of the Base::things::that UsageBindingConnector SatisfyRequirementUsage Systems Modeling Language v2.0, Part 1 401 -Notes 1. It is acceptable to use either KerML BindingConnectors or SysML BindingConnectorAsUsages as the implied Relationships for binding-connector constraints. However, a conforming tool should consistently use one or the other. 8.4.2 Definition and Usage Semantics Abstract syntax reference: 8.3.6 8.4.2.1 Definitions A SysML Definition has the semantics of a KerML Classifier (see [KerML, 8.4.3.3]). However, a Definition element is always either instantiated as one of its more specific subclasses (e.g., AttributeDefinition , ItemDefinition , etc.), or with at least one semantic metadata annotation. In the former case, the Definition has the semantics of the more specialize kind. In the latter case it has semantics as given by the base Type (s) from the annotation(s) (see 8.4.23 ). 8.4.2.2 Usages A SysML Usage has the semantics of a KerML Feature (see [KerML, 8.4.3.4]). However, a Usage element is always either instantiated as one of its more specific subclasses (e.g., AttributeUsage , ItemUsage , etc.), or with at least one semantic metadata annotation. In the former case, the Usage has the semantics of the more specialized kind, except that a ReferenceUsage has no additional semantics. In the latter case it has semantics as given by the base Type(s) from the annotation(s) (see 8.4.23 ). In KerML, any Type that directly or indirectly specializes Occurrence may have Features with isVariable = true . The checkFeatureFeatureMembershipTypeFeaturing constraint requires that such variable Features are featured by the snapshots of their owningType . A snapshot covers the entire three-dimensional extent of an Occurrence at a specific point in time. Therefore, variable Features being featured by those snapshots means that an Occurrence that is an instance of the owningType can potentially have a different value for the variable Feature at each point in time during its Life . (See [KerML, 8.4.4.3] for more on the semantics of variable features.) In SysML, the property Usage::mayTimeVary redefines Feature::isVariable and makes it derived. The deriveUsageMayTimeVary constraint specifies that mayTimeVary is true if and only if all the following are true about a Usage : 1. It has an owningType that directly or indirectly specializes Occurrences::Occurrence . 2. It has isPortion = false . 3. It does not specialize Links::SelfLink (from the Kernel Semantic Library). 4. It does not specialize Occurrences::HappensLink (from the Kernel Semantics Library). 5. If isComposite = true , it does not specialize Actions::Action (from the Systems Model Library). The first two conditions above are required to avoid violating KerML validation constraints on isVariable . The last condition means that BindingAsUsages , SuccssionAsUsages and composite ActionUsages are not variable. This allows, in particular, for the temporal ordering of actions to be determined by successions, transitions and other control constructs (see 8.4.13 and 8.4.14 on the semantics of actions and states). Usage also inherits the property isConstant from Feature . If a Usage has both mayTimeVary = true and isConstant = true , then the Usage is asserted to be constant over the entire duration of any instance of its owningType . That is, it must have the same values on every snapshot of any instance of the owningType . If a Usage has isEnd = true and mayTimeVary = true then it must also have isConstant = true in order to satisfy the KerML constraint checkFeatureEndIsConstaint . This is, in particular, the case for end features of 402 Systems Modeling Language v2.0, Part 1 -ConnectionDefinitions , ConnectionUsages , FlowDefinitions and FlowUsages , even though the keyword constant is not explicitly notated in the declaration of the end feature. 8.4.2.3 Variation Definitions and Usages A Definition or Usage with isVariation = true has additional semantic restrictions. In this case, the validateDefinitionVariationMembership and validateUsageVariationMembership constraints require that all the ownedMembers of the Definition or Usage be variant Usages . The checkUsageVariationDefinitionSpecialization and checkUsageVariationUsageSpecialization constraints then require that each variant Usage directly or indirectly specialize its owning variation Definition or Usage . Thus, a variation Definition of the form variation part def P { variant part p1; variant part p2; ... } has, with implied Relationships included, the equivalent kernel semantics of // KerML class P specializes Parts::Part { member feature p1 : P subsets Parts::parts; member feature p2 : P subsets Parts::parts; ... } Note that VariantMemberships are OwningMemberships but not FeatureMemberships , so variant Usages are ownedMembers but not ownedFeatures of the variation Definition . Similarly, a Usage of the form variation part p { variant part p1; variant part p2; ... } has, with implied Relationships included, the equivalent kernel semantics of // KerML feature p subsets Parts::parts { member feature p1 subsets p; member feature p2 subsets p; ... } ( PartDefinition and PartUsage are used in the examples above for concreteness, but the variation semantics are similar for any kind of Definition or Usage other than EnumerationDefinition or EnumerationUsage .) In addition, the allowable instances of a variation Definition or Usage shall be restricted to values of its corresponding owned variant Usages . This is the fundamental intent of enumerating the variants in the variation declaration. Since a variation enumerates in this way a fixed set of allowed variants, it is not valid for a variation to specialize another variation, since this would imply an inconsistent subsetting of the allowed instances in the specialized Definition or Usage . Systems Modeling Language v2.0, Part 1 403 -Note. The semantic restriction on the instances of a variation is not currently formally captured in the Systems semantic model. However, it is required to be enforced by any semantically conformant tool for variability modeling. 8.4.3 Attributes Semantics Abstract syntax reference: 8.3.7 8.4.3.1 Attribute Definitions An AttributeDefinition is a kind of Definition and a kind of KerML DataType . The base AttributeDefinition Attributes::AttributeValue (see 9.2.2.2.1 ) is just an alias for the KerML DataType Base::DataValue (see [KerML, 9.2.2]). Therefore, SysML AttributeDefinitions have the same semantics as KerML DataTypes (see [KerML, 8.4.4.2]), and the KerML checkDataTypeSpecialization constraint requires that an AttributeDefinition specialize Base::DataValue . An AttributeDefinition is also syntactically restricted by the validateAttributeDefinitionFeatures constraint to have no composite features . attribute def D1 specializes Base::DataValue { ref a subsets Base::things; } As specified in the Kernel Semantic Library, DataValue is disjoint from Occurrence , which is the base Type of SysML OccurrenceDefinitions (see 8.4.5 ). This means that an AttributeDefinition cannot specialize an OccurrenceDefinition (or any of its more specialized kinds, such as ItemDefinition , ActionDefinition and ConstraintDefinition ). 8.4.3.2 Attribute Usages An AttributeUsage is a kind of Usage that is syntactically required to be defined only by DataTypes (including AttributeDefinitions ). The base AttributeUsage Attributes::attributeValues (see 9.2.2.2.2 ) is an alias for the KerML Feature Base::dataValues (see [KerML, 9.2.2]). The checkAttributeUsageDataTypeSpecialization constraint requires that an AttributeUsage specialize Base::dataValues , which is typed by Base::DataValue . AttributeUsages are also syntactically restricted by the validateAttributeUsageIsReference to be referential (non-composite) and, by the validateAttributeUsageFeatures constraint to have no composite features . attribute def D2 specializes Base::DataValue { ref attribute a : ScalarValue::String subsets Base::dataValues; } ref attribute d : D2 subsets Base::dataValues { ref attribute b subsets a; } 8.4.4 Enumerations Semantics Abstract syntax reference: 8.3.8 An EnumerationDefinition is a kind of AttributeDefinition , so the semantic constraints for KerML DataTypes apply to it, as for an AttributeDefinition (see 8.4.3 ). However, an EnumerationDefinition is also required to have isVariation = true , and its enumeratedValues are then just its variants (see 8.4.2.3 on the semantics of variation Definitions ). Therefore, an EnumerationDefinition of the form enum def E { enum e1; enum e2; 404 Systems Modeling Language v2.0, Part 1 -... } is essentially equivalent to variation attribute def E specializes Base::DataValue { variant attribute e1 : E subsets Base::dataValues; variant attribute e2 : E subsets Base::dataValues; ... } Note, in particular, that this means that the enumeratedValues are not features of the containing EnumeratedDefinition but, rather, members owned via VariantMemberships . However, other than when nested in an EnumerationDefinition , an EnumerationUsage is semantically just an AttributeUsage that is required to be typed by exactly one EnumerationDefinition (syntactically enforced by the 1..1 multiplicity of EnumerationUsage::enumerationDefinition , see 8.3.8 ). Since an EnumerationDefinition is already a variation, there is no further concept of a "variation enumeration". Also, since, in general, a variation cannot specialize another variation (as discussed in 8.4.2.3 ), an EnumerationDefinition cannot specialize another EnumerationDefinition . 8.4.5 Occurrences Semantics Abstract syntax reference: 8.3.9 8.4.5.1 Occurrence Definitions An OccurrenceDefinition is a kind of Definition and a kind of KerML Class . The kernel checkClassSpecialization constraint requires that it specialize the base Class Occurrences::Occurrence from the Kernel Semantic Library (see [KerML, 9.2.4]). Therefore, SysML OccurrenceDefinitions have the same basic semantics as KerML Classes (see [KerML, 8.4.4.3]). However, there are additional semantic constraints on an OccurrenceDefinition if it has isIndividual = true (see below). The Class Occurrences::Occurrence is disjoint with Base::DataValues , the base Type for AttributeDefinitions (see 8.4.3 ), so an OccurrenceDefinition cannot specialize an AttributeDefinition . If an OccurrenceDefinition has isIndividual = true , the following additional constraints apply: • checkOccurrenceDefinitionIndividualSpecialization requires that it specialize the Class Life from the Kernel Semantic Library model Occurrences (see [KerML, 9.2.4]). • checkOccurrenceDefinitionMultiplicitySpecialization requires that it have a multiplicity that specializes the MultiplicityRange zeroOrOne from the Kernel Semantic Library model Base (see [KerML, 9.2.2]). An OccurrenceDefinition declaration of the form individual occurrence def Ind; is parsed with a nested Multiplicity to act as the source of the required implied Subsetting to zeroOrOne . The declaration thus has the equivalent kernel semantics of // KerML class Ind specializes Occurrences::Life { multiplicity subsets Base::zeroOrOne; } The Kernel Semantic Library Class Life classifies all Occurrences that are maximal portions, that is, those Occurrences that are not a portion of any other Occurrence . Every Occurrence is a portion of some Life Systems Modeling Language v2.0, Part 1 405 -(possibly itself), as given by the value of its portionOfLife feature (see [KerML, 9.2.4]). In this way, a single Life instance also identifies all possible portions that have that Life as their portionOfLife value. Colloquially, a Life represents the "identity" of an individual and the totality of its existence in space and time. A individual OccurrenceDefinition is a subclass of Life with a zeroOrOne multiplicity , meaning that it has at most a single instance. If this instance exists, then the OccurrenceDefinition models exactly a single individual, as described above. If the instance does not exist, it means there is no such individual. The optional multiplicity thus provides for the ability to model counterfactual situations in which a certain individual is asserted not to exist. 8.4.5.2 Occurrence Usages An OccurrenceUsage is a kind of Usage that is syntactically required to be defined only by Classes (including OccurrenceDefinitions ). The following specialization constraints apply to an OccurrenceUsage : • checkOccurrenceUsageSpecialization requires that it specialize the Feature Occurrences::occurrences from the Kernel Model Library (see [KerML, 9.2.4]), which is typed by Occurrences::Occurrence . • checkOccurrenceUsageSuboccurrenceSpecialization requires that, if the OccurrenceUsage is composite (non-referential) and owned by an OccurrenceDefinition or OccurrenceUsage , it specialize the Feature Occurrences::Occurrence::suboccurrences (see [KerML, 9.2.4]), which subsets Occurrences::occurrences . occurrence def Occ specializes Occurrences::Occurrence { ref occurrence a subsets Occurrences::occurrences; occurrence b subsets Occurrences::Occurrence::suboccurrences; } An OccurrenceUsage that has an occurrenceDefinition with isIndividual = true represents a usage of the individual modeled by that OccurrenceDefinition (or possibly a time slice or snapshot of it, see below). This is constrained as follows: • validateOccurranceUsageIndividualDefinition requires that an OccurrenceUsage have at most one such occurrenceDefinition that has isIndividual = true . • validateOccurrenceUsageIsIndividual requires that, if the OccurrenceUsage has isIndividual = true , it have exactly one such occurrenceDefinition (which will then be the value of its individualDefinition property). If an OccurrenceUsage has a non-null portionKind , then the following additional constraints apply: • validateOccurrenceUsageIsPortion requires that the OccurrenceUsage is a portion feature (see [KerML, 9.2.4] on the semantic model for portions). • validateOccurrenceUsagePortionKind requires that the OccurrenceUsage have an owningType that is an OccurrenceDefinition or OccurrenceUsage . • If portionKind = timeslice , then checkOccurrenceUsageTimeSliceSpecialization requires that the OccurrenceUsage specialize the Feature Occurrences::Occurrence::timeSlices from the Kernel Semantic Library Model Occurrences (see [KerML, 9.2.4]). • If portionKind = snapshot , then checkOccurrenceUsageSnapshotSpecialization requires that the OccurrenceUsage specialize the Feature Occurrences::Occurrence::snapshots from the Kernel Semantic Library Model Occurrences (see [KerML, 9.2.4]). Thus, the time slice and snapshot declarations in the following: occurrence def Occ { timeslice occurrence t; 406 Systems Modeling Language v2.0, Part 1 -snapshot occurrence s; } have, with implied Relationships included, the equivalent kernel semantics of //KerML class Occ specializes Occurrences::Occurrence { portion feature t subsets Occurrences::Occurrence::timeslices; portion feature s subsets Occurrences::Occurrence::snapshots; } 8.4.5.3 Event Occurrence Usages An EventOccurrenceUsage is a kind of OccurrenceUsage that is required to always be referential by the validateEventOccurrenceUsageIsReference . All general semantic constraints on an OccurrenceUsage (see 8.4.5.2 ) also apply to an EventOccurrenceUsage . In addition, if an EventOccurrenceUsage is an ownedFeature of an OccurrenceDefinition or OccurrenceUsage , then the checkEventOccurrenceUsageSpecialization constraint requires that it specialize the kernel Feature Occurrences::Occurrence::timeEnclosedOccurrences (see [KerML, 9.2.4]). In this case, any Occurrence referenced by the EventOccurrenceUsage must happen within the lifetime of the featuring Occurrence of the EventOccurrenceUsage . For example, the following model: occurrence occ1; occurrence occ2 { event occurrence evt references occ1; // Other than having a name, the above is equivalent to // event occ1; } is, with implied Relationships included, semantically equivalent to occurrence occ1 subsets Occurrences::occurrences; occurrence occ2 subsets Occurrences::occurrences { ref occurrence evt references occ1 subsets Occurrences::Occurrence::timeEnclosedOccurrences; } Thus, the values of occ2.evt will be some subset of the Occurrences represented by occ1 that happen within the lifetime of occ2 . An EventOccurrenceUsage that is not an ownedFeature of an OccurrenceDefinition or OccurrenceUsage has the same semantics as a referential OccurrenceUsage (see 8.4.5.2 ). 8.4.6 Items Semantics Abstract syntax reference: 8.3.10 8.4.6.1 Item Definitions An ItemDefinition is a kind of OccurrenceDefinition and a kind of KerML Structure . As such, all the general semantic constraints for an OccurrenceDefinition (see 8.4.5 ) and a Structure (see [KerML, 8.4.4.4]) also apply to an ItemDefinition . In addition, the checkItemDefinitionSpecialization constraint requires that an ItemDefinition specialize the base ItemDefinition Items::Item (see 9.2.3.2.1 ), which subclassifies the kernel Class Objects::Object (see [KerML, 9.2.5]). The Item semantic model also includes additional features whose semantics is covered in other subclauses: Systems Modeling Language v2.0, Part 1 407 -• subparts – A subset of subitems and Parts::parts that collects the values of all composite PartUsages featured by an Item . Covered under Parts Semantics (see 8.4.7 ). • checkedConstraints – A subset of Constraints::constraintChecks and Object::ownedPerformances that collects all checks of composite ConstraintUsages featured by an Item . Covered under Constraints Semantics (see 8.4.16 ). 8.4.6.2 Item Usages An ItemUsage is a kind of OccurrenceUsage . As such, all the general semantic constraints for an OccurrenceUsage (see 8.4.5 ) also apply to an ItemUsage . The following additional specialization constraints also apply to an ItemUsage : • checkItemUsageSpecialization requires that an ItemUsage specialize the base ItemUsage Items::items (see 9.2.3.2.2 ), which subsets the Kernel Feature Objects::objects (see [KerML, 9.2.5]). • checkItemUsageSubitemSpecialization requires that an ItemUsage that is composite and has an owningType that is an ItemDefinition or ItemUsage specialize the ItemUsage Items::Item::subitems (see 9.2.3.2.1 ), which subsets Objects::Objects::subobjects (see [KerML, 9.2.5]) and Items::items . item def I specializes Items::Item { ref item a subsets Items::items; item b subsets Items::Item::subitems; } As a kind of Object , an Item may have a physical extent in three-dimensional space as well as existing over time. The semantic model for an Item contains a number of specializations of the kernel spatial model (see [KerML, 9.2.4 and 9.2.5]), including the features shape, envelopingShapes , boundingShapes , voids , and isSolid (see 9.2.3.2.1 for details). This provides the basis for the geometric shape model defined in the Geometry Domain Library (see 9.7 ). 8.4.7 Parts Semantics Abstract syntax reference: 8.3.11 8.4.7.1 Part Definitions A PartDefinition is a kind of ItemDefinition . As such, all the general semantic constraints for an ItemDefinition (see 8.4.6 ) also apply to a PartDefinition . In addition, the checkPartDefinitionSpecialization constraint requires that a PartDefinition specialize the base PartDefinition Parts::Part (see 9.2.4.2.1 ), which subclassifies Items::Item (see 9.2.3.2.1 ). The Part semantic model also includes additional features whose semantics is covered in other subclauses: • ownedPorts – A subset of Ports::ports and Occurrences::timeEnclosedOccurrences that collects the values of the PortUsages featured by a Part . Covered under Ports Semantics (see 8.4.8 ). • performedActions – A subset of Actions::actions and Objects::enactedPerformances that collects the values of the PerformedActionUsages featured by a Part . Covered under Actions Semantics (see 8.4.13 ). • ownedActions – A subset of Actions::actions and Objects::ownedPerformances that collects the values of the composite ActionUsages featured by a Part . Covered under Actions Semantics (see 8.4.13 ). • exhibitedStates – A subset of States::stateActions and performedActions that collects the values of the ExhibitStateUsages featured by a Part . Covered under States Semantics (see 8.4.14 ). 408 Systems Modeling Language v2.0, Part 1 -• ownedStates – A subset of States::stateActions and ownedActions that collects the values of the composite StateUsages featured by a Part . Covered under States Semantics (see 8.4.14 ). 8.4.7.2 Part Usages A PartUsage is a kind of ItemUsage . As such, all the general semantic constraints for an ItemUsage (see 8.4.6 ) also apply to a PartUsage , as well as the following additional specialization constraints: • checkPartUsageSpecialization requires that a PartUsage specialize the base PartUsage Parts::parts (see 9.2.4.2.2 ). • checkPartUsageSubpartSpecialization requires that a PartUsage that is composite and has an owningType that is an ItemDefinition or ItemUsage specialize the PartUsage Items::Item::subparts (see 9.2.3.2.1 ), which subsets Items::Item::subitems (see 9.2.3.2.1 ) and Parts::parts . part def P specializes Parts::Part { ref part a subsets Parts::parts; part b subsets Items::Item::subparts; item c subsets Items::Item::subitems { part p : P subsets Items::Item::subparts; } } • checkPartUsageActorSpecialization requires that a PartUsage that is owned by a ActorMembership specialize either the PartUsage Requirements::RequirementCheck::actors (see 9.2.14.2.8 ) or Cases::Case::actors (see 9.2.15.2.1 ). See also Requirements Semantics ( 8.4.17 ) and Case Semantics (see 8.4.18 ). • checkPartUsageStakeholderSpecialization requires that a PartUsage that is owned by a StakeholderMembership specialize the PartUsage Requirements::RequirementCheck::stakeholders (see 9.2.14.2.8 ). See also Requirements Semantics ( 8.4.17 ). 8.4.8 Ports Semantics Abstract syntax reference: 8.3.12 8.4.8.1 Port Definitions A PortDefinition is a kind of OccurrenceDefinition and a kind of KerML Structure . As such, all the general semantic constraints for an OccurrenceDefinition (see 8.4.5 ) and a Structure (see [KerML, 8.4.4.4]) also apply to a PortDefinition . The following additional constraints apply to a PortDefinition : • checkPortDefinitionSpecialization requires that a PortDefinition specialize the base PortDefinition Ports::Port (see 9.2.5.2.1 ), which subclassifies the kernel Class Objects::Object (see [KerML, 9.2.5]). • validatePortDefinitionNestedUsagesNotComposite requires that all nestedUsages of the PortDefinition that are not PortUsages are referential (non-composite). A PortDefinition is parsed as containing a ConjugatedPortDefinition with a ConjugatedPortDefinition Relationship pointing back to the containing PortDefinition . A PortConjugation is a kind of KerML Conjugation and, except for being syntactically restricted to be between a ConjugatedPortDefinition and a (non-conjugated) PortDefinition , it has the same effect as Conjugation . That is, the ConjugatedPortDefinition is considered to inherit the features of its PortDefinition , but in and out directions are reversed (see [KerML, 8.3.3.1]). Thus, a PortDefinition declaration of the form Systems Modeling Language v2.0, Part 1 409 -port def Pd { // Directed features are always referential // (ref keyword is optional). in ref a; out ref b; inout ref c; ref item d; } has, with implied Specializations included, the equivalent kernel semantics of // KerML struct Pd specializes Ports::Port { in feature a subsets Base::things; out feature b subsets Base::things; inout feature c subsets Base::things; feature d subsets Items::Item; struct '~Pd' conjugates Pd { //* Effective conjugated features: out feature a subsets Base::things; in feature b subsets Base::things; inout feature c subsets Base::things; feature d subsets Items::Item; *// } } Note that the KerML validateSpecificationSpecificNotConjugated constraint disallows a Type that is conjugated from having an ownedSpecialization (see [KerML, 8.3.3.1]) . Nevertheless, ~Pd still satisfies the checkPortDefinitionSpecialization constraint because its original PortDefinition does. The base PortDefinition Port declares the PortUsage interfacingPorts (see 9.2.5.2.1 ). If a Port is a participant in an Interface , then the other participants in the Interface must be a subset of the interfacingPorts of the first Port . The interfacingPorts of a Port are thus all the Ports connected to it via Interfaces . Port also redefines the feature Occurrences::Occurrence::outgoingTransfersFromSelf (see [KerML, 9.2.4.13]), constraining it to be a subset of the incomingTransfersToSelf of the interfacingPorts . Since the incomingTransfersToSelf of an Occurrence have that Occurrence as their target (see [KerML, 9.2.4.13]), this means that any outgoingTransferFromSelf of a Port must have one of the interfacingPorts of the Port as its target . If the Port has more than one interfacingPort , then this specification does not determine which of those is used as the target for any particular outgoingTransfer . 8.4.8.2 Port Usages A PortUsage is a kind of OccurrenceUsage that is syntactically restricted to be defined only by PortDefinitions . As such, all the general semantic constraints for an OccurrenceUsage (see 8.4.5 ) also apply to a PortUsage , as well as the following additional constraints: • checkPortUsageSpecialization requires that a PortUsage specialize the base PortUsage Ports::ports (see 9.2.5.2.2 ), which subsets the kernel Feature Objects::objects (see [KerML, 9.2.5]). • checkPortUsageSubportSpecialization constraint requires that a PortUsage that is composite and has an owningType that is an PortDefinition or PortUsage specialize the PortUsage Ports::Port::subports (see 9.2.5.2.1 ), which subsets Occurrences::Occurrence::timeEnclosedOccurrences (see [KerML, 9.2.4]) and Ports::ports . • validatePortUsageNestedUsagesNotComposite requires that all nestedUsages of the PortUsage that are not PortUsages are referential (non-composite). 410 Systems Modeling Language v2.0, Part 1 -port p : Pd specializes Ports::ports { port p1 subsets Ports::Port::subports; ref port p2 subsets Ports::ports; } The following constraints apply to a PortUsage that is not nested in a PortDefinition or PortUsage : • validatePortUsageIsReference requires that it is referential (non-composite). • checkPortUsageOwnedPortSpecialization requires that a PortUsage has an owningType that is a PartDefinition or PartUsage specialize the PortUsage Parts::Part::ownedPorts (see 9.2.4.2.1 ). part def P specializes Parts::Part { // PortUsages not nested in PortDefinitions or PortUsages // are always referential (ref keyword is optional). ref port p : Pd subsets Parts::Part::ownedPorts; } A PortUsage may have an ownedFeatureTyping that is a ConjugatedPortTyping , in which case the type is the ConjugatedPortDefinition for the named PortDefinition (see 8.2.2.12 ). Thus, the declaration port p : ~Pd; is equivalent to port p : Pd::'~Pd'; 8.4.9 Connections Semantics Abstract Syntax Reference: 8.3.13 8.4.9.1 Connection Definitions A ConnectionDefinition is a kind of PartDefinition and a kind of KerML AssociationStructure . As such, all the general semantic constraints for a PartDefinition (see 8.4.7 ) and an AssociationStructure (see [KerML, 8.4.4.5.2]) also apply to a ConnectionDefinition . In addition, the checkConnectionDefinitionSpecialization constraint requires that a ConnectionDefinition specialize the base ConnectionDefinition Connections::Connection (see 9.2.6.2.3 ), which subclassifies the PartDefinition Parts::Part (see 9.2.4.2.1 ) and the kernel AssociationStructure Objects::LinkObject (see [KerML, 9.2.5]). A ConnectionDefinition must have at last two connectionEnd Features (unless it is abstract), and it may also have ownedFeatures that are not ends. The checkFeatureEndSpecialization and checkFeatureEndRedefinitionSpecialization constraints apply to the connectionEnds of a ConnectionDefinition . As a result, all connectionEnd s must directly or indirectly specialize the kernel Feature Link::participant and they must redefine the end Features of any Associations specialized by their owning ConnectionDefinition (see [KerML, 8.4.4.5]). (Note also that the constraint validateUsageIsReferential requires that all end Usages are referential.) connection def C specializes Connections::Connection { end ref e1 subsets Links::Link::participant; end ref e2 subsets Links::Link::participant; end ref e3 subsets Links::Link::participant; } connection def D specializes C { end ref f1 redefines C::e1; end ref f2 redefines C::e2; Systems Modeling Language v2.0, Part 1 411 -end ref f3 redefines C::e3; } The checkConnectionDefinitionBinarySpecialization constraint requires that a binary ConnectionDefinition specialize the ConnectionDefinition Connections::BinaryConnection , which subclassifies Connection and Objects::BinaryLinkObject (see [KerML, 9.2.5]), which is a subclassification of Objects::LinkObject and Links::BinaryLink (see [KerML, 9.2.3] that restricts a BinaryConnection two have exactly two participants corresponding to two ends called source and target . As required by the checkFeatureEndRedefinition constraint, the first connectionEnd of a binary Association will redefine Connections::BinaryConnection::source and its second connectionEnd will redefine Connections::BinaryConnection::target . connection def B specializes Connections::BinaryConnections { end ref e1 redefines Connections::BinaryConnection::source; end ref e2 redefines Connections::BinaryConnection::target; } A binary ConnectionDefinition can also specify cross features for one or both of its connectionEnds using CrossSubsetting . Such a cross feature must be a feature of the type of the other connectionEnd than the one for the cross feature. The validateCrossSubsettingCrossedFeature constraint requires that the target of a CrossSubsetting be a feature chain consisting of the other connectionEnd and the cross feature. CrossSubsetting is a kind of Subsetting , so it semantically requires that the value of a connectionEnd be one of the values of the cross feature for the other connectionEnd . Further, the validateConnectionDefinitionIsSufficient constraint requires that a ConnectionDefinition has isSufficient = true , so instances of the ConnectionDefinition must exist for all values of its cross features. This also means that cross-feature multiplicity applies to each set of instances (connections) of the ConnectionDefinition that have the same (singleton) value for the connectionEnd . Cross feature uniqueness and ordering apply to the collection of values of the other connectionEnd in each of those connection sets, preventing duplication in each collection and ordering them to form a sequence. For example, the binary ConnectionDefinition B1 below specifies cross features for both its ends (without implied relationships included): item def T1 { ref item e2_cross[0..1] : T2; } item def T2 { ref item e1_cross[1..4] nonunique ordered : T1; } connection def B1 { end ref e1 : T1 crosses e2.e1_cross; end ref e2 : T2 crosses e1.e2_cross; } In this case, an instance t1 of T1 having a value t2 for e2_cross is sufficient to require that an instance of B1 exist linking t1 to t2 and, therefore, that t1 is a value of e1_cross for t2. Conversely, an instance of B1 linking t1 to t2 is sufficient to require that t1 has a value t2 for e2_cross and t2 has a value t1 for e1_cross . The instances of B1 are then constrained by the multiplicity requirements that there be at most one value of e2_cross connected to any value of e1_cross and one to four values of e1_cross connected to any value of e2_cross . Cross features may also be directly owned by the corresponding connectionEnd . Such an owned cross feature may be declared with the declaration of the corresponding connectionEnd . The TypeFeaturing and Specialization of an owned cross feature are implied by the checkFeatureOwnedCrossFeatureTypeFeaturing and checkFeatureCrossingSpecialization 412 Systems Modeling Language v2.0, Part 1 -constraints. For example, the following binary Association declaration (the cross feature names are optional, but they are included here for convenience of reference): connection def B2 end e1_cross [1..4] nonunique ordered ref e1 : T1; end e2_cross [0..1] ref e2 : T2; } is essentially semantically equivalent to the previous example B1 , in that e1_cross is implied to be featured by T2 , e2_cross is implied to be featured by T1 , and the two end features have implied CrossSubsettings with each other. As a result, the instances of B2 and the values of e1_cross and e2_cross are coordinated in the same way as B1 and its cross features. A ConnectionDefinition with three or more connectionEnds may also have ends with cross features, but, in this case, the cross features must be owned by their corresponding connectionEnds . For example: connection def Ternary { end a_cross[1] ref a[1] : A; end b_cross[0..2] ref b[1] : B; end c_cross[*] nonunique ordered ref c[1] : C; } Owned cross feature multiplicity has the following general semantics: For a ConnectionDefinition with N connectionEnds , with N of 2 or greater, consider the i-th connectionEnd e . The multiplicity of the owned cross i feature of e applies to each set of instances of the ConnectionDefinition that have the same (singleton) values i for each of the N-1 associationEnds other than e . Uniqueness and ordering of the owned cross feature apply to i the collection of values of e in each of those link sets, preventing duplication in each collection and ordering them i to form a sequence. For full details on the semantics of cross features and corresponding implied relationships, see [KerML, 8.4.4.5.1]. 8.4.9.2 Connection Usages A ConnectionUsage is a PartUsage and a ConnectorAsUsage , which is a kind of KerML Connector . As such, all the general semantic constraints for a PartUsage (see 8.4.7 ) and a Connector (see [KerML, 8.4.4.6.1]) also apply to a ConnectionUsage . In addition, the checkConnectionUsageSpecialization constraint requires that a ConnectionUsage specialize the base ConnectionUsage Connections::connections (see 9.2.6.2.4 ), which is defined by Connections::Connection and subsets the PartUsage Parts::parts (see 9.2.4.2.2 ) and the kernel Feature Objects::linkObjects (see [KerML, 9.2.5]). A ConnectionUsage is syntactically restricted to be defined only by AssociationStructures (including ConnectionDefinitions ). Further, the checkFeatureEndRedefinition constraint requires that the end Features of a ConnectionUsage redefine of corresponding end Features of its connectionDefinitions (see [KerML, 8.4.4.5]). connection c : C subsets Connections::connections { end ref e1 references f1 redefines C::e1; end ref e2 references f2 redefines C::e2; end ref e3 references f3 redefines C::e1; } Note that the relatedFeatures of a ConnectionUsage are determined by the referencedFeatures of its ends. Therefore, unless the ConnectionUsage is abstract, every end must have an ownedReferenceSubsetting . The checkConnectionUsageBinarySpecialization constraint requires that a binary ConnectionUsage specialize the ConnectionUsage Connections::binaryConnections (see 9.2.6.2.2 ), which is defined by Connections::BinaryConnection and subsets he Connections::connections and the kernel Feature Objects::binaryLinkObjects (see [KerML, 9.2.5]) Systems Modeling Language v2.0, Part 1 413 -connection b : B subsets Connections::binaryConnections { end ref source references f1 redefines B::source; end ref target references f2 redefines B::target; } Since a ConnectionUsage is a kind of PartUsage , the checkPartUsageSupartSpecialization constraint requires that a composite ConnectionUsage nested in an ItemDefinition or ItemUsage of any kind specialize the PartUsage Items::Item::subparts (see 9.2.3.2.1 ) as well as Connections::connections or Connections::binaryConnections (see also 8.4.7.2 ). part def P specializes Parts::Part { part f1 subsets Items::Item::subparts; part f2 subsets Items::Item::subparts; connector b : B subsets Connections::binaryConnections, Items::Items::subparts connects f1 to f2; } An end feature of a ConnectionUsage may also have an owned cross feature, with the same syntax and semantics as for an owned cross feature of a connectionEnd of a ConnectionDefinition (see 8.4.9.1 , [KerML, 8.4.4.5.1]; see also [KerML, 8.4.4.6.1]) 8.4.9.3 Binding Connectors As Usages A BindingConnectorAsUsage is a kind of ConnectorAsUsage and a kind of KerML BindingConnector . As such, all the general semantic constraints for a Usage (see 8.4.2 ) and a BindingConnector (see [KerML, 8.4.4.6.2]) also apply to a BindingConnectorAsUsage . In particular, the checkBindingConnectorSpecialization constraint requires that BindingConnectorAsUsages specialize the kernel Feature Links:selfLink , which is typed by the Association SelfLink (see [KerML, 9.2.3]). A BindingConnectorAsUsage therefore has the same basic semantics as a KerML BindingConnector , asserting that the (single) values of its two ends must be the same things (see [KerML, 8.4.4.6.2]). Thus, a BindingConnectorAsUsage declaration of the form bind f1 = f2; has, with implied Specializations included, the equivalent kernel semantics of // KerML connector subsets Links::selfLinks { end feature thisThing redefines Links::SelfLink::thisThing references f1; end feature thatThing redefines Links::SelfLink::thatThing references f2; } Note that a BindingConnectorAsUsage does not have the semantics of a SysML ConnectionUsage , because a ConnectionUsage must be defined by AssociationStructures (see 8.4.9.2 ), and Links::selfLink is an Association but not an AssociationStructure . The KerML checkFeatureValueBindingConnector constraint requires that a FeatureValue with isDefault = false have a BindingConnector to enforce its semantics (see [KerML, 8.4.4.11]). For a SysML model, it is allowable to use a BindingConnectorAsUsage , rather than a plain KerML BindingConnector , as the implied Relationship to satisfy this constraint. 8.4.9.4 Successions As Usages A SuccessionAsUsage is a kind of ConnectorAsUsage and a kind of KerML Succession . As such, all the general semantic constraints for an Usage (see 8.4.2 ) and a Succession (see [KerML, 8.4.4.6.3]) also apply to a 414 Systems Modeling Language v2.0, Part 1 -SuccessionAsUsage . In particular, the checkSuccessionSpecialization constraint requires that a SuccessionAsUsage specialize the KerML Feature Occurrences::happensBeforeLinks (see [KerML, 9.2.4]), which is typed by the Association HappensBefore . A SuccessionAsUsage therefore has the same basic semantics as a KerML Succession , asserting that the Occurrence identified by its first end happens temporally before the one identified by its second end. Thus, a SuccessionAsUsage declaration of the form succession first f1 then f2; has, with implied Specifications included, the equivalent kernel semantics of // KerML connector subsets Occurrences::happensBeforeLinks { end feature earlierOccurrence references f1 redefines Occurrences::HappensBefore::earlierOccurrence; end feature laterOccurrence references f2 redefines Occurrences::HappensBefore::laterOccurrence; } Note that a SuccessionAsUsage does not have the semantics of a SysML ConnectionUsage , because a ConnectionUsage must be defined by AssociationStructures (see 8.4.9.2 ), and Occurrences::HappensBefore is an Association but not an AssociationStructure . 8.4.10 Interfaces Semantics Abstract syntax reference: 8.3.14 8.4.10.1 Interface Definitions An InterfaceDefinition is a kind of ConnectionDefinition whose connectionEnds are syntactically restricted to to be PortUsages . As such, all the general semantic constraints that apply to a ConnectionDefinition (see 8.4.9.1 ) also apply to an InterfaceDefinition , as well as the following additional specialization constraints: • checkInterfaceDefinitionSpecialization requires that an InterfaceDefinition specialize the base InterfaceDefinition Interfaces::Interface (see 9.2.7.2.3 ), which subclassifies the ConnectionDefinition Connection::Connection (see 9.2.6.2.3 ). • checkInterfaceDefinitionBinarySpecialization requires that an InterfaceDefinition that is binary specialize the InterfaceDefinition Interfaces::BinaryInterface (see 9.2.7.2.1 ), which subclassifies Interfaces::Interface and the ConnectionDefinition Connections::BinaryConnection (see 9.2.6.2.1 ), redefining the source and target ends so that they are PortUsages . interface def I1 specializes Interfaces::Interface { end port p1 subsets Links::Link::participant; end port p2 subsets Links::Link::participant; end port p3 subsets Links::Link::participant; } interface def I2 specializes Interfaces::BinaryInterface { end port p1 redefines Interfaces::BinaryInterface::source; end port p2 redefines Interfaces::BinaryInterface::target; } In the base InterfaceDefinition Interface , the participant Ports are constrained such that the interfacingPorts of each participant includes all the other participants (see 9.2.7.2.3 ). The semantics of Ports requires that the outgoingTransfersFromSelf of a Port target one of its interfacingPorts (see Systems Modeling Language v2.0, Part 1 415 -8.4.8.1). The term "other participants " as used here means " Ports that are values of other ends of the Interface ". It is possible that some of these other values are actually the same as the original Port . This allows, for example, a Port to be connected to itself by an Interface , in which case outgoingTransfersFromSelf of the Port will target the same Port . 8.4.10.2 Interface Usages An InterfaceUsage is a kind of ConnectionUsage whose connectionDefinitions are syntactically restricted to to be only InterfaceDefinitions . Since InterfaceDefinitions have ends that are PortUsages , the ends of an InterfaceUsage must also be ports. The general semantic constraints of a ConnectionUsage (see 8.4.9.2 ) also apply to an InterfaceUsage , as well as the following additional specialization constraints: • checkInterfaceUsageSpecialization requires that an InterfaceUsage specialize the base InterfaceUsage Interfaces::interfaces (see 9.2.7.2.4 ), which is defined by the InterfaceDefinition Interfaces::Interface (see 9.2.7.2.3 ) and subsets the ConnectionUsage Connection::connections (see 9.2.6.2.4 ). • checkInterfaceUsageBinarySpecialization requires that a binary InterfaceUsage specialize the InterfaceUsage Interfaces::binaryInterfaces (see 9.2.7.2.2 ), which is defined by the InterfaceDefinition Interfaces::BinaryInterface (see 9.2.7.2.1 ) and subsets the ConnectionUsage Connections::binaryConnections (see 9.2.6.2.2 ). interface i1 : I1 subsets Interfaces::interfaces { end port p1 references q1 redefines I1::e1; end port p2 references q2 redefines I1::e2; end port p3 references q3 redefines I1::e3; } interface i2 : I2 subsets Interfaces::binaryInterfaces { end port p1 references q1 redefines I2::p1; end port p2 references q2 redefines I2::p2; } part def P specializes Parts::Part { part f1 : F1 subsets Items::Item::subparts; part f2 : F2 subsets Items::Item::subparts; // A nested InterfaceUsage also subsets subparts. interface b : B subsets Interface::binaryInterfaces, Items::Items::subparts connects f1.p1 to f2.p2; } 8.4.11 Allocations Semantics Abstract syntax reference: 8.3.15 8.4.11.1 Allocation Definitions An AllocationDefinition is a kind of binary ConnectionDefinition . The checkAllocationDefinitionSpecialization constraint requires that an AllocationDefinition specialize the base AllocationDefinition Allocations::Allocation (see 9.2.8.2.1 ), which subclassifies the ConnectionDefinition Connection::BinaryConnection (see 9.2.6.2.1 ). Otherwise, the semantics of an AllocationDefinition are the same as for a binary ConnectionDefinition (see 8.4.9.1 ). allocation def A specializes Allocations::Allocation { end e1 redefines Allocations::Allocation::source; end e2 redefines Allocations::Allocation::target; } 416 Systems Modeling Language v2.0, Part 1 -8.4.11.2 Allocation Usages An AllocationUsage is a kind of binary ConnectionUsage whose connectionDefinitions are syntactically restricted to to be only AllocationDefinitions . The checkAllocationUsageSpecialization constraint requires that an AllocationUsage specialize the base AllocationUsage Allocations::allocations (see 9.2.8.2.2 ), which is defined by the AllocationDefinition Allocations::Allocation (see 9.2.8.2.1 ) and subsets the ConnectionUsage Connection::binaryConnections (see 9.2.6.2.4 ) (see 9.2.6.2.2 ). Otherwise, the semantics of an AllocationUsage are the same as for a ConnectionUsage (see 8.4.9.2 ) allocation a : A subsets Allocations::allocations { end ref e1 references f1 redefines A::e1; end ref e2 references f2 redefines A::e2; // A nested AllocationUsage is a subpart. allocation subsets Allocations::allocations, Items::Item::subparts allocate e1.x to e2.y; } 8.4.12 Flows Semantics 8.4.12.1 Flow Definitions A FlowDefinition is a kind of ActionDefinition , and a kind of KerML Interaction . As such, all the general semantic constraints for ActionDefinitions (see 8.4.13.1 ) and Interactions (see [KerML, 8.4.4.10.1]) also apply to FlowDefinitions . In addition, the checkFlowDefinitionSpecialization constraint requires that a FlowDefinition specialize the base FlowDefinition Flows::MessageAction (see 9.2.9.2.4 ), which subclassifies the ActionDefinition Actions::Action (see 9.2.10.2.4 ), as well as the kernel Association Links::Link (see [KerML, 9.2.3]). If the FlowDefinition is binary, then the checkFlowBinarySpecialization constraint further requires that it specialize the FlowConnectionFlows::Message (see 9.2.9.2.3 ), which subclassifies MessageAction and the kernel Interaction Transfers::Transfer (see [KerML, 9.2.7]). An abstract FlowDefinition may have less than two flowEnds . In particular, an abstract FlowDefinition with no ownedEndFeatures may be used to type a FlowUsage declared as a message (see 8.4.12.2 ). It also inherits MessageAction::payload , which represents the payload of the flow. This feature can be redefined the restrict the allowed type of the payload. abstract flow def M specializes Flows::MessageAction { item i : I redefines Flows::MessageAction::payload; } A non-abstract FlowDefinition is always binary, with source and target ends corresponding to the corresponding ends of Transfer . It also inherits Message::payload , which is a redefinition of MessageAction::payload and Transfer::payload , representing the payload being transferred by the flow. These features can be redefined to restrict the allowed type of the ends connected by a flow and the type of the payload transferred across the flow, as desired. Note that the source and target ends must be kinds of Occurrences , but that the payload can be anything, flow def F1 specializes Flows::Message { item i : I redefines Flows::Message::payload; end p : P redefines Flows::Message::source; end q : Q redefines Flows::Message::target; } The ends of a Message identify the Occurrences between which payload values are flowing, but they do not identify how these values are obtained from the source (the sourceOutput Feature ) or to where they are delivered at the target (the targetInput Feature ). In order to restrict the sourceOutput and targetInput in a Systems Modeling Language v2.0, Part 1 417 -FlowDefinition , the FlowDefinition can specialize Flows::Flow (see 9.2.9.2.1 ), which is a Message that also subclassifies the kernel Interaction FlowTransfer (see [KerML, 9.2.7]). part def P specializes Parts::Part { port p1 : Pd subsets Parts::Part::ownedPorts; } part def Q specializes Parts::Part { port p2 : ~Pd subsets Parts::Part::ownedPorts; } flow def F2 specializes Flows::Flow { item i : I redefines Flows::Flow::payload; end p : P redefines Flows::Flow::source { port p1 redefines P::p1, Flows::Flow::source::sourceInput; } end q : Q redefines Flows::Flow::target { port p2 redefines Q::p2, Flows::Flow::source::targetOuput; } } A FlowDefinition may also (explicitly) specialize Flow::SuccessionFlow (see 9.2.9.2.6 ), which is a Flow that also subclassifies the kernel Interaction FlowTransferBefore (see [KerML, 9.2.7]). A SuccessionFlow not only represents a flow from the source to the target , but it also asserts that the flow happens after the completion of the lifetime of the source and before the start of the lifetime of the target (e.g., if the source and target are Actions , then the source Action must complete before the flow can start, and the flow must complete before the target Action can start). 8.4.12.2 Flow Usages A FlowUsage is a kind of ActionUsage and a kind of KerML Flow that is syntactically restricted to be defined by only KerML Interactions (including FlowDefinitions ). As such, all the general semantic constraints that apply to an ActionUsage (see 8.4.13.2 ), and an Flow (see [KerML, 8.4.4.10.2]) also apply to a FlowUsage . In addition, the checkFlowUsageSpecification constraint requires that a FlowUsage specialize the base FlowUsage Flows::messages (see 9.2.9.2.5 ), which is typed by the FlowDefinition Flows::Message (see 9.2.9.2.3 ) and subsets the ActionUsage Actions::actions (see 9.2.10.2.5 ), and the kernel Step Transfers::transfers (see [KerML, 9.2.7]). Further, if the FlowUsage has ownedEndFeatures , then it must specialize the FlowUsage Flows::flows (see 9.2.9.2.2 ), which is defined by the FlowDefinition Flows::Flow (see 9.2.9.2.1 ) and subsets Flows::messages and the kernel Step Transfers::flowTransfers (see [KerML, 9.2.7]). A message declaration of the form message m : M of i : I from evt1 to evt2; is parsed as an abstract FlowUsage , but without any flowEnds (see 8.2.2.16 ), so it is required by checkFlowUsageSpecification to just specialize Flows::messages . Rather than being parsed as flowEnds , evt1 and evt2 are parsed as in parameters , which are then, by the KerML checkFeatureParameterRedefinition constraint (see [KerML, 8.4.4.7]), required to redefine the parameters sourceEvent and targetEvent from Message . The payload declaration i : I is parsed as a KerML PayloadFeature (see [KerML, 8.4.4.10]) that is required by the checkPayloadFeatureRedefinition constraint to redefine the Feature Transfers::Transfer::payload (see [KerML, 9.2.7]; this is equivalent to redefining Flows::Message::payload ). abstract flow m : M subsets Flows::messages { // PayloadFeature ref i : I redefines Transfers::Transfer::payload; // parameters in redefines Flows::Message::sourceEvent 418 Systems Modeling Language v2.0, Part 1 -references evt1; in redefines Flows::Message::targetEvent references evt2; } Such a FlowUsage asserts that there is some sourceEvent that occurs to initiate a flow and provide the payload and some targetEvent that occurs to accept the flow payload, but it does not constrain what the actually connected source and target Features are. This allows for, e.g., the case in which the sourceEvent is a SendAction and the targetEvent is an AcceptAction , but the connected source and target Features are Ports (see also 8.4.13 ). For a FlowUsage to be considered a message, it must not have any owned flowEnds . Therefore, such a FlowUsage should only be defined by FlowDefinitions that are abstract and have no flowEnds . Otherwise, flownEnds will be inhertied from both the Flow\Definitions and messages , with no way to redefine them, resulting in the FlowUsage having more than two end Features , violating the KerML validateConnectorBinarySpecialization constraint. A flow declaration of the form flow f : F of i : I from src.src_out to tgt.tgt_in; is parsed with two FlowEnds (see [KerML, 8.3.4.9]) referencing src and tgt , with nested redefinitions of src_out and tgt_in (as for a KerML Flow [KerML, 8.4.4.10]), respectively. Since it has FlowEnds , the checkFlowUsageFlowSpecification constraint requires it to specialize Flows::flows . The KerML checkFeatureEndRedefinition and checkFeatureFlowFeatureRedefinition constraints then require both the redefinition of the end Features (as for a regular ConnectionUsage , see 8.4.9.2 ) and the redefinition of the sourceOutput and targetInput Features . flow f : F subsets Flows::flows { // PayloadFeature ref i : I redefines Transfers::Transfer::payload; // First FlowEnd end redefines Flows::flows::source references src { redefines Transfers::Transfer::source::sourceOutput, src_out; } // Second FlowEnd end redefines Flows::flows::target references tgt { redefines Transfers::Transfer::target::targetInput, tgt_in; } } In this case, the sourceEvent and targetEvent parameters default to the starting and ending snapshots of the Flow , which are required to occur during the lifetime of the source and target Occurrences , respectively. Since a FlowUsage is a kind of ActionUsage , the checkActionUsageSubactionSpecialization constraint requires that a FlowUsage nested in an ActionDefinition or ActionUsage specialize Actions::Action::subactions (see 9.2.10.2.4 ) as well as Flows::Flows (see also 8.4.13.2 ). action def A specializes Actions::Action { action a1 : A1 subsets Actions::Action::subactions; action a2 : A2 subsets Actions::Action::subactions; flow subsets Flows::flows, Actions::Action::subactions from a1.a1_out to a2.a2_in; } Systems Modeling Language v2.0, Part 1 419 -8.4.12.3 Succession Flow Usages A SuccessionFlowUsage is a kind of FlowUsage and a kind of KerML SuccessionFlow . As such, all the general semantic constraints of a FlowUsage (see 8.4.12.2 ) and a SuccessionFlow (see [KerML, 8.4.4.10]) also apply to a SuccessionFlowUsage . A SuccessionFlowUsage is semantically the same as a FlowUsage , except that the checkSuccessionFlowUsageSpecialization constraint requires that it specialize the FlowUsage Flows::successionFlows (see 9.2.9.2.7 ), which is defined by the FlowConnectionDefinition SuccessionFlowConnection (see 9.2.9.2.6 ; see also 8.4.12.1 ) and subsets the FlowUsage Flows::flows (see 9.2.9.2.2 ) and the kernel Step flowTransfersBefore (see [KerML, 9.2.7]). As a result, a SuccessionFlowUsage has the semantics of both a temporal succession from its source to itself to its target and a flow from the source to the target . Thus, a succession flow declaration of the form succession flow of i : I from src.src_out to tgt.tgt_in; is semantically equivalent, with implied Specializations included, to: succession flow subsets Flows::successionFlows { // PayloadFeature ref i : I redefines Transfers::Transfer::payload; // First FlowEnd end redefines Flows::flows::source references src { redefines Transfers::Transfer::source::sourceOutput, src_out; } // Second FlowEnd end redefines Flows::flows::target references tgt { redefines Transfers::Transfer::target::targetInput, tgt_in; } } Abstract syntax reference: 8.3.16 8.4.13 Actions Semantics Abstract syntax reference: 8.3.17 8.4.13.1 Action Definitions An ActionDefinition is a kind of OccurrenceDefinition and a kind of KerML Behavior . As such, all the general semantic constraints for an OccurrenceDefinition (see 8.4.5 ) and a Behavior (see [KerML, 8.4.4.7.1]) also apply to an ActionDefinition . In addition, the checkActionDefinitionSpecialization constraint requires that an ActionDefinition specialize the base ActionDefinition Actions::Action (see 9.2.10.2.4 ), which subclassifies the kernel Behavior Performances::Performance (see [KerML, 9.2.6]). Further, the KerML checkFeatureParameterRedefinition constraint (see [KerML, 8.4.4.7.1]) requires that any owned parameters (i.e., directed ownedFeatures ) of an ActionDefinition redefine corresponding parameters of any Behaviors it specializes (including other ActionDefinitions ). action def A specializes Actions::Action { in ref x[0..*] subsets Base::things; out ref y[0..1] subsets Base::things; inout ref z subsets Base::things; } action def A1 specializes A { in ref x1[1] redefines x; out ref y1[1] redefines y; 420 Systems Modeling Language v2.0, Part 1 -// z is inherited without redefinition } The Action semantic model also includes additional features that collect various composite subactions of an Action : • subactions – All subperformances of an Action that are Actions (see 8.4.13.2 ). • transitions – The subactions that are TransitionActions (see 8.4.13.3 and 8.4.14.3 ). ◦ decisionTransitions – The transitions that are DecisionTransitionActions . • controls – The subactions that are ControlActions (see 8.4.13.4 ). ◦ merges – The controls that are MergeActions . ◦ decisions – The controls that are DecisionActions . ◦ joins – The controls that are JoinActions . ◦ forks – The controls that are ForkActions . • sendSubactions – The subactions that are SendActions (see 8.4.13.5 ). • acceptSubactions – The subactions that are AcceptActions (see 8.4.13.6 ). • • assignments – The subactions that are AssignmentActions (see 8.4.13.7 ). • ifSubactions – The subactions that are IfThenActions (see 8.4.13.9 ). • loops – The subactions that are LoopActions (see 8.4.13.10 ). ◦ whileLoops – The loops that are WhileLoopActions . ◦ forLoops – The loops that are ForLoopActions . 8.4.13.2 Action Usages An ActionUsage is a kind of OccurrenceUsage and a kind of KerML Step . As such, all the general semantic constraints for an OccurrenceUsage (see 8.4.5 ) and a Step (see [KerML, 8.4.4.7.2]) also apply to an ActionUsage , as well as the following additional specialization constraints: • checkActionUsageSpecialization requires that an ActionUsage specialize the base ActionUsage Actions::actions (see 9.2.10.2.5 ), which is defined by the ActionDefinition Actions::Action (see 9.2.10.2.4 ) and subsets the kernel Step Performances::performances (see [KerML, 9.2.6]). Further, the KerML checkFeatureParameterRedefinition constraint requires that any owned parameters (i.e., directed ownedFeatures ) of a ActionUsage redefine corresponding parameters of any Behaviors or Steps it specializes (including ActionDefinitions and ActionUsages ). action a : A subsets Actions::actions { in ref x redefines A::x = x1; out ref y redefines A::y; inout ref z redefines A::z := z1 ; } action a1 : A1 subsets a { in ref x redefines A1::x, a::x; out ref y redefines A2::y, a::y; } • checkActionUsageSubactionSpecialization requires that an ActionUsage that is composite, has an owningType that is an ActionDefinition or ActionUsage , and is not the entryAction or exitAction of a StateDefinition or StateUsage (see 8.4.14 ) specialize the ActionUsage Actions::Action::subactions (see 9.2.10.2.4 ), which subsets the kernel Step Performances::Performance::subperformances (see [KerML, 9.2.6]). Note also that, in other cases, the general KerML checkStepEnclosedPerformanceSpecialization and checkStepSubperformanceSpecialization constraints will still apply (see [KerML, 8.4.4.7]). action def Act subsets Actions::Action { action act1 subsets Actions::Action::subactions; ref action act2 subsets Actions::actions, Systems Modeling Language v2.0, Part 1 421 -Performances::Performance::enclosedPerformances; } • checkActionUsageOwnedActionSpecialization requires that a composite ActionUsage whose owningType is a PartDefinition or a PartUsage specialize the ActionUsage Parts::Part::ownedActions (see 9.2.4.2.1 ), which subsets the ActionUsage Action::actions and the kernel Feature Objects::Object::ownedPerformances (see [KerML, 9.2.5]). Note also that, in other cases, the general KerML checkStepOwnedPerformanceSpecialization constraint will still apply (see [KerML, 8.4.4.7]). part def PA specializes Parts::Part { action a : A subsets Parts::Part::ownedActions; } item def IA specializes Items::Item { action a : A subsets Objects::Object::ownedPerformances; } • checkActionUsageStateActionRedefinition requires that an ActionUsage that is an entryAction , exitAction or doAction of a StateDefinition or StateUsage specialize, respectively, the entryAction , exitAction , or doAction feature of the StateDefinition States::StateAction (see 9.2.11.2.1 ), which redefine the entry , exit , and do features of the kernel Behavior StatePerformances::StatePerformance (see [KerML, 9.2.6]), restricting them to be Actions (see 9.2.10.2.4 ). (See also 8.4.14 on State Semantics.) • checkActionUsageAnalysisActionSpecialization requires that an ActionUsage that is an analysisAction of an AnalysisCaseDefinition or AnalysisCaseUsage specialize the ActionUsage Actions::Action::analysisSteps (see 9.2.10.2.4 ). (See also 8.4.19 on Analysis Case Semantics.) Semantics of this Action inherits the kernel Feature Occurrences::Occurrence::this (see [KerML, 9.2.4]). The value for this Feature is determined in by the semantic model for Object::Object (see [KerML, 9.2.5]) and Performances::Performance (see [KerML, 9.2.6]), as further specialized for Parts::Part::ownedActions (see 9.2.4.2.1 ) and Actions::Action::subactions (see 9.2.10.2.4 ). For an Action in a hierarchy of subactions , the value of this is the top-level Action in the hierarchy (that is, one that is not one of the subactions of any other Action ), unless that top-level Action is itself one of the ownedActions of a Part (or on of the ownedPerformances of an Item ), in which case the value is that Part (or Item ). For example, consider the model package Pkg { action def A specializes Actions::Action { action b subsets Actions::Action::subactions; } action a1 : A[1] subsets Action::actions { // a1.this == a1 // b.x == a1 } part p subsets Parts::parts { action a2: A[1] subsets Parts::Part::ownedActions { // a2.this == p // b.this == p } } } 422 Systems Modeling Language v2.0, Part 1 -As indicated, the value of this for both the Action a1 and its subaction a1.b will be (the value of) a1 , since the ActionUsage a1 is at "package level", while the value of this for both p.a2 and p.a2.b will be (the value of) p , since a2 is an ownedAction of p . The semantics of this are particularly important in the specification of default semantics for SendActionUsages (see 8.4.13.5 ) and AcceptActionUsages (see 8.4.13.6 ). 8.4.13.3 Decision Transition Usages A Succession in the body of an ActionDefinition or ActionUsage may be syntactically declared with a guard Expression . In this case, it is actually parsed as a TransitionUsage , with the guard Expression and the declared Succession nested in the TransitionUsage (see 8.2.2.17.8 ). The checkTransitionUsageActionSpecialization constraint requires that a composite TransitionUsage whose ownedType is an ActionDefinition or ActionUsage , but not a StateDefinition or StateUsage , specialize the ActionUsage Actions::Action::decisionTransitions (see 9.2.10.2.4 ), which is typed by the ActionDefinition Actions::DecisionTransitionAction (see 9.2.10.2.10 ). DecisionTransitionAction subclassifies the ActionDefinition Actions::TransitionAction (see 9.2.10.2.26 ) and the kernel Behavior TransitionPerformances::NonStateTransitionPerformance (see [KerML, 9.2.10]). It represents a TransitionAction that has a guard , but no accepter or effects . For example, consider the following model of a conditional Succession between to ActionUsages : action def AC { action a1 { out ref test : ScalarValues::Boolean; } succession sc first a1 if a1.test then a2; action a2; } With implied Relationships included (see 8.2.2.18.3 on the semantic constraints related to a TransitionUsage ), this has the equivalent kernel semantics of: // KerML behavior AC specializes Actions::Action { step a1 subsets Actions::Action::subactions { out feature test : ScalarValues::Boolean; } step sc subsets Actions::Action::decisionTransitions { in feature redefines Actions::TransitionAction::transitionLinkSource; bool redefines Actions::TransitionAction::guard { a1.test } member succession sc_link subsets Occurrences::happensBeforeLinks featured by AC first a1 then a2; member binding featured by AC of sc_link = TransitionPerformances::TransitionPerformance::transitionLink; member binding featured by AC of s1 = transitionLinkSource; } step a2 subsets Actions::Action::subactions; } Systems Modeling Language v2.0, Part 1 423 -As specified for a NonStateTransitionPerformance , the guard of a DecisionTransitionAction is evaluated after the completion of the Performance of the transitionLinkSource , which is the source of the nested transitionLink Succession . If the guard evaluates to true, then the transitionLink may have a value, meaning that there must be a Performance of the targetFeature of the Succession temporally following the Performance of the sourceFeature . If the guard evaluates to false, the transitionLink does not have a value, so no such temporal ordering is asserted. 8.4.13.4 Control Nodes A ControlNode is a kind of ActionUsage that has no inherent behavior but is used to control other Actions within a containing Action . All the general semantic constraints of an ActionUsage (see 8.4.13.2 ) also apply to a ControlNode , as well as the following additional constraints: • checkControlNodeSpecialization requires that a ControlNode specialize the ActionUsage Actions::Action::controls (see 9.2.10.2.4 ), which is defined by the ActionDefinition Actions::ControlAction (see 9.2.10.2.8 ) and subsets the composite ActionUsage Actions::Action::subactions (further implying that a ControlNode must be composite). ControlAction includes a constraint that it's performance is instantaneous. • validateControlNodeOwningType requires that the owningType of a ControlNode be an ActionDefinition or ActionUsage . • validateControlNodeIncomingSuccessions requires that all incoming Successions to a ControlNode have target multiplicity 1..1 . • validateControlNodeOutgoingSuccessions requires that all outgoing Successions from a ControlNode have source multiplicity 1..1 . Note. Multiplicities are given in a model as MultiplicityRanges which have Expressions for lowerBound and upperBound . When checking validation constraints such as the above on MultiplicityRanges , the lowerBound and upperBound Expressions shall be model-level evaluable to the required values for the bounds (see [KerML, 8.4.4.9]). If the lowerBound is empty, then an upperBound value of 1 is equivalent to multiplicity 1..1 . The constraints can also be equivalently satisfied by multiplicities that subset the MultiplicityRanges ExactlyOne or ZeroOrOne from the Kernel Semantic Library model Base (see [KerML, 9.2.2]). The ControlNode metaclass is itself abstract, but it has four concrete subclasses representing various specific ControlNode elements. Each of these places additional constraints on incoming and outgoing Successions , as appropriate to achieve the specific control constraints required for each kind of element. Join Nodes A JoinNode is a kind of ControlNode that represents the joining of control. The following additional constraints apply to a JoinNode : • checkJoinNodeSpecialization requires that a JoinNode specialize the ActionUsage Actions::Action::joins (see 9.2.10.2.4 ), which is defined by the ActionDefinition Actions::JoinAction (see 9.2.10.2.21 ) and subsets Actions::Action::controls . JoinAction subclassifies ControlAction . • validateJoinNodeOutgoingSuccessions requires that a JoinNode have at most one outgoing Succession . • validateJoinNodeIncomingSuccessions constraint requires that all incoming Successions to a JoinNode have source multiplicity 1..1 . The semantics of a JoinNode are entirely a result of the above constraints. Because of the required multiplicities , for each performance of a JoinNode , every incoming Succession must have a value, temporally ordering the JoinNode as happening after all the source Occurrences (typically Actions ) of the incoming Successions . 424 Systems Modeling Language v2.0, Part 1 -For example, consider the following model of a JoinNode with two incoming Successions and one outgoing Succession , explicitly showing the required Succession multiplicities : action def A1 { action a1; action a2; succession s1 first a1[1..1] then j[1..1]; succession s2 first a2[1..1] then j[1..1]; join j; succession s3 first j[1..1] then a3; action a3; } With implied Specializations included, this is semantically equivalent to: action def A1 specializes Actions::Action { action a1 subsets Actions::Action::subactions; action a2 subsets Actions::Action::subactions; succession s1 subsets Occurrences::happensBeforeLinks first a1[1..1] then m[1..1]; succession s2 subsets Occurrences::happensBeforeLinks first a2[1..1] then m[1..1]; join j subsets Actions::Action::joins; succession s3 subsets Occurrences::happensBeforeLinks first j[1..1] then a3; action a3 subsets Actions::Action::subactions; } Fork Nodes A ForkNode is a kind of ControlNode that represents a forking of control.The following additional constraints apply to a ForkNode : • checkForkNodeSpecialization requires that a ForkNode specialize the ActionUsage Actions::Action::forks (see 9.2.10.2.4 ), which is defined by the ActionDefinition Actions::ForkAction (see 9.2.10.2.21 ) and subsets Actions::Action::controls . ForkAction subclassifies ControlAction . • validateForkNodeIncomingSuccessions requires that a ForkNode have at most one incoming Succession . • validateForkNodeOutgoingSuccessions requires that all outgoing Successions from a ForkNode have target multiplicity 1..1 . The semantics of a ForkNode are entirely a result of the above constraints. Because of the required multiplicities, for each performance of a ForkNode , every outgoing Succession must have a value, temporally ordering the ForkNode as happening before all the target Occurrences (typically Actions ) of the outcoming Successions . For example, consider the following model of a ForkNode with two incoming Successions and one outgoing Succession , explicitly showing the required Succession multiplicities: action def A2 { action a1; succession s1 first a1 then f[1..1]; fork f; succession s2 first f[1..1] then a2[1..1]; Systems Modeling Language v2.0, Part 1 425 -succession s3 first f[1..1] then a3[1..1]; action a2; action a3; } With implied Specializations included, this is semantically equivalent to: action def A2 specializes Actions::Action { action a1 subsets Actions::Action::subactions; succession s1 subsets Occurrences::happensBeforeLinks first a1 then f[1..1]; fork f subsets Actions::Action::forks; succession s2 subsets Occurrences::happensBeforeLinks first f[1..1] then a2[1..1]; succession s3 subsets Occurrences::happensBeforeLinks first f[1..1] then a3[0..1]; action a2 subsets Actions::Action::subactions; action a3 subsets Actions::Action::subactions; } Merge Nodes A MergeNode is a kind of ControlNode that represents the merging of control. The following additional constraints apply to a MergeNode . • checkMergeNodeSpecialization constraint requires that a MergeNode specialize the ActionUsage Actions::Action::merges (see 9.2.10.2.4 ), which is defined by the ActionDefinition Actions::MergeAction (see 9.2.10.2.21 ) and subsets Actions::Action::controls . MergeAction subclassifies ControlAction and the kernel Behavior ControlPerformances::MergePerformance (see [KerML, 9.2.9]). • checkMergeNodeIncomingSuccessionSpecialization requires that any incoming Succession to a MergeNode specialize the Feature MergePerformance::incomingHBLink (which is inherited by MergeAction ). • validateMergeNodeOutgoingSuccessions requires that a MergeNode have at most one outgoing Succession . • validateMergeNodeIncomingSuccessions requires that all incoming Successions to a MergeNode have source multiplicity 0..1 . Since MergePerformance::incomingHBLink has a multiplicity of 1 , the result of the above constraints is that, for any performance of a MergeAction , there must be exactly one incoming Succession that has a value, representing the incoming "control" that triggers this specific performance of the MergeAction . For example, consider the following model of a MergeNode with two incoming Successions and one outgoing Succession , explicitly showing the required Succession multiplicities: action def A3 { action a1; action a2; succession s1 first a1[0..1] then m[1..1]; succession s2 first a2[0..1] then m[1..1]; merge m; succession s3 first m[1..1] then a3; action a3; } 426 Systems Modeling Language v2.0, Part 1 -With implied Specializations included, this is semantically equivalent to: action def A3 specializes Actions::Action { action a1 subsets Actions::Action::subactions; action a2 subsets Actions::Action::subactions; succession s1 subsets Occurrences::happensBeforeLinks subsets m.incomingHBLink first a1[0..1] then m[1..1]; succession s2 subsets Occurrences::happensBeforeLinks subsets m.incomingHBLink first a2[0..1] then m[1..1]; merge m subsets Actions::Action::merges{ // m inherits the following feature from MergePerformance: // incomingHBLink : HappensBefore[1]; } succession s3 subsets Occurrences::happensBeforeLinks first m[1..1] then a3; action a3 subsets Actions::Action::subactions; } Decision Nodes A DecisionNode is a kind of ControlNode that represents a control decision. The following additional constraints apply to a DecisionNode : • checkDecisionNodeSpecialization requires that a DecisionNode specialize the ActionUsage Actions::Action::decisions (see 9.2.10.2.4 ), which is defined by the ActionDefinition Actions::DecisionAction (see 9.2.10.2.21 ) and subsets Actions::Action::controls . DecisionAction subclassifies ControlAction and the kernel Behavior ControlPerformances::DecisionPerformance (see [KerML, 9.2.9]). • checkDecisionNodeOutgoingSuccessionSpecialization requires that any incoming Succession to a MergeNode specialize the Feature DecisionPerformance::outgoingHBLink (which is inherited by DecisionAction ). • validateDecisionNodeIncomingSuccessions requires that a DecisionNode have at most one incoming Succession . • validateDecisionNodeOutcomingSuccessions constraint requires that all outgoing Successions from a DecisionNode have target multiplicity 0..1 . Since DecisionPerformance::outgoingHBLink has a multiplicity of 1 , the result of these constraints is that, for any performance of a DecisionAction , there must be exactly one outgoing Succession that has a value, representing the outgoing "control" decided on by this specific performance of the DecisionAction . For example, consider the following model of a DecisionNode with one incoming Successions and two outgoing Succession s, explicitly showing the required Succession multiplicities: action def A4 { action a1; succession s1 first a1 then d[1..1]; decide d; succession s2 first d[1..1] then a2[0..1]; succession s3 first d[1..1] then a3[0..1]; action a2; action a3; } Systems Modeling Language v2.0, Part 1 427 -With implied Specializations included, this is semantically equivalent to: action def A4 specializes Actions::Action { action a1 subsets Actions::Action::subactions; succession s1 subsets Occurrences::happensBeforeLinks first a1[0..1] then d[1..1]; decide d subsets Actions::Action::decisions { // d inherits the following feature from DecisionPerformance: // outgoingHBLink : HappensBefore[1]; } succession s2 subsets Occurrences::happensBeforeLinks subsets d.outgoingHBLink first d[1..1] then a2[0..1]; succession s3 subsets Occurrences::happensBeforeLinks subsets d.outgoingHBLink first d[1..1] then a3[0..1]; action a2 subsets Actions::Action::subactions; action a3 subsets Actions::Action::subactions; } The semantics of a DecisionNode do not determine which of the outgoing Successions will have a value for any specific performance of the DecisionNode . However, the outgoing Successions of a DecisionNode will typically have guard conditions, in which case only the Succession(s) for which the guard is true may have values. action def A5 { action a1 { out ref x : ScalarValues::Integer; } succession s1 first a1 then d[1..1]; decide d; succession s2 first d[1..1] if x < 0 then a2[0..1]; succession s3 first d[1..1] if x >= 0 then a3[0..1]; action a2; action a3; } Such conditional Successions are actually parsed as TransitionUsages defined by the ActionDefinition DecisionTransitionAction (see 8.2.2.17.8 ), with a nested Succession . It is this nested Succession that actually has the DecisionNode as its source, and, therefore, to which the validateDecisionNodeOutcomingSuccessions constraint applies. See 8.4.13.3 on the semantics of decision TransitionUsages . 8.4.13.5 Send Action Usages A SendActionUsage is a kind of ActionUsage , so all general semantic constraints for an ActionUsage (see 8.4.13.2 ) also apply to a SendActionUsage , as well as the following additional specialization constraints: • checkSendActionUsageSpecialization requires that a SendActionUsage specialize the ActionUsage Actions::sendActions (see 9.2.10.2.23 ), which is defined by the ActionDefinition Actions::SendAction (see 9.2.10.2.22 ) and subsets the ActionUsage Actions::actions (see 9.2.10.2.5 ) and the kernel Feature Transfers::sendPerformances (see [KerML, 9.2.7]). • checkSendActionUsageSubactionSpecialization constraint requires that a SendActionUsage that is composite, has an owningType that is an ActionDefinition or ActionUsage , and is not the entryAction or exitAction of a StateDefinition or StateUsage (see 8.4.14 ) specialize the 428 Systems Modeling Language v2.0, Part 1 -ActionUsage Actions::Action::sendSubactions (see 9.2.10.2.4 ), which subsets Actions::sendActions and Actions::Action::subactions . A SendActionUsage provides arguments for the parameters of a SendAction . A SendActionUsage declaration of the form action snd send p via src to tgt; (where all of p , src and tgt are Expressions ) is parsed (including implied Specializations ) as (see 8.2.2.17.4 ): action s subsets Actions::sendActions { in ref redefines Actions::SendAction::payload = p; in ref redefines Actions::SendAction::sender = src; in ref redefines Actions::SendAction::receiver = tgt; } SendAction subclassifies the ActionDefinition Actions::Action (see 9.2.10.2.4 ) and the kernel Behavior Transfers::SendPerformance (see [KerML, 9.2.7]). The semantics of SendPerformance is to initiate a sentMessage , which is a MessageTransfer (for a SendAction , this will also be a MessageConnection , see ) from a given sender . The SendAction::payload parameter (which redefines SendPerformance::sentItems ) provides the values that are transferred. If given, the receiver parameter specifies the target of the sentMessage . This parameter is optional. If no receiver is given, then the target of the sentMessage is unspecified by the SendAction , and must be determined from other constraints in the model. (For example, if the SendAction has a PortUsage as its sender , then the target of the sentMessage may be determined by an InterfaceUsage outgoing from that PortUsage ; see 8.4.8.1 and 8.4.10.1 .) The sender parameter is mandatory. However, if no explicit value is given for this parameter , it defaults to the value of this for the SendAction (see 8.4.13.2 on the semantics of this for Actions in general). This is particularly important when the SendAction is nested in other containing Actions or Parts . For example, consider a SendActionUsage with no declared sender nested in an ActionDefinition : action def AS { action snd send p to tgt; } This is equivalent to action def AS specializes Actions::Action { action snd subsets Actions::Action::sendSubactions { in ref redefines payload = p; in ref redefines sender = this; in ref redefines receiver = tgt; } } Therefore, in the model package Sending { action as1 : AS[1] subsets Action::actions { // snd.sender == as1 } part p subsets Parts::parts { action as2: AS[1] subsets Parts::Part::ownedActions { // snd.sender == p Systems Modeling Language v2.0, Part 1 429 -} } } the default sender for as1.snd is as1 , but the default sender for p.as2.snd is p . 8.4.13.6 Accept Action Usages An AcceptActionUsage is a kind of ActionUsage , so all general semantic constraints for an ActionUsage (see 8.4.13.2 ) also apply to an AcceptActionUsage , as well as the following additional specialization constraints: • checkAcceptActionUsageSpecialization requires that (unless it is the triggerAction of a TransitionUsage , see 8.4.14.3 ) an AcceptActionUsage specialize the ActionUsage Actions::acceptActions (see 9.2.10.2.2 ), which is defined by the ActionDefinition Actions::AcceptAction (see 9.2.10.2.1 ) and subsets Actions::Action::actions (see 9.2.10.2.5 ) and the kernel Feature Transfers::acceptPerformances (see [KerML, 9.2.7]). • checkAcceptActionUsageSubactionSpecialization requires that an AcceptActionUsage that is composite, has an owningType that is an ActionDefinition or ActionUsage , and is not the triggerAction of a TransitionUsage or the entryAction or exitAction of a StateDefinition or StateUsage (see 8.4.14 ) specialize the ActionUsage Actions::Action::acceptSubactions (see 9.2.10.2.4 ), which subsets Actions::acceptActions and Actions::Action::subactions . An AcceptActionUsage provides an argument for the input parameter receiver of an AcceptAction and declares what can be accepted in the output parameter payload . An AcceptActionUsage declaration of the form action acpt accept x : T via tgt; (where src and tgt are Expressions ) is parsed (including implied Specializations ) as (see 8.2.2.17.4 ): action acpt subsets Actions::acceptActions { inout ref x : T redefines Actions::AcceptAction::payload; in ref redefines Actions::AcceptAction::receiver = tgt; } AcceptAction subclassifies the ActionDefinition Actions::AcceptMessageAction (see 9.2.10.2.3 ), which itself subclassifies Actions::Action (see 9.2.10.2.4 ) and the kernel Behavior Transfers::AcceptPerformance (see [KerML, 9.2.7]). The semantics of AcceptPerformance is to select an incomingTransfer of the given receiver Occurrence that is a MessageTransfer and whose transferred values conform to its acceptedItem parameter , as redefined in the AcceptActionUsage ( AcceptAction::payload itself redefines AcceptPerformance::acceptedItem ). AcceptAction has a nested StateActionUsage , such that, when the AcceptAction is performed, it waits for the acceptance of a conforming MessageTransfer , and then completes if and when such a MessageTransfer is eventually accepted. If so, then the transferred values of the acceptedMessage are placed on the payload output parameter . The receiver parameter is mandatory. However, if no explicit value is given for this parameter , it defaults to the value of this for the AcceptAction (see 8.4.13.2 on the semantics of this for Actions in general). This is particularly important when the AcceptAction is nested in other containing Actions or Parts . For example, consider an AcceptActionUsage with no declared receiver nested in an ActionDefinition : action def AA { action acpt accept x : T; } This is equivalent to 430 Systems Modeling Language v2.0, Part 1 -action def AA specializes Actions::Action { action acpt subsets Actions::Action::acceptSubactions { inout ref x : T redefines Actions::AcceptAction::payload; in ref redefines Actions::AcceptAction::receiver = this; } } Therefore, in the model package Accepting { action aa1 : AA[1] subsets Action::actions { // acpt.receiver == aa1 } part p subsets Parts::parts { action aa2: AA[1] subsets Parts::Part::ownedActions { // acpt.receiver == p } } } the default receiver for aa1.acpt is aa1 , but the default receiver for p.aa2.accept is p . Note also that the AcceptAction::payload parameter actually has direction inout , which means that an input value may be optionally provided for it. If a the payload parameter has a FeatureValue Relationship to a value Expression , then any acceptedMessage must have values that match the result of the value Expression bound to the payload parameter . This is used, in particular, to provide the semantics for TriggerInvocationExpressions as used in AcceptActionUsages . A TriggerInvocationExpression (see 8.3.17.17 ) is a kind of KerML InvocationExpression (see [KerML, 8.3.4.8]), with the corresponding semantics (see [KerML, 8.4.4.9]). The checkTriggerInvocationExpressionSpecialization constraint requires that a TriggerInvocationExpression specialize (invoke) one of the Functions TriggerWhen , TriggerAt or TriggerAfter , from the Kernel Semantic Library Triggers package (see [KerML, 9.2.14]), depending on whether its kind is when , at or after (see TriggerKind , 8.3.17.18 ), respectively. An AcceptActionUsage with a change ( when ), absolute time ( at ) or relative time ( after ) trigger is parsed as having its payload parameter bound to a TriggerInvocationExpression of the corresponding kind . So, the following: action def AT { action acpt_when accept when boolean_expr; action acpt_at accept at time_expr; action acpt_after accept after duration_expr; } is equivalent to: action def AT specializes Actions::Action { action acpt_when subsets Actions::Action:acceptSubactions { in ref redefines Actions::AcceptAction::payload = Triggers::TriggerWhen({ boolean_expr }, receiver); in ref redefines Actions::AcceptAction::receiver = this; } action acpt_at subsets Actions::Action:acceptSubactions { in ref redefines Actions::AcceptAction::payload = Triggers::TriggerAt(time_expr, receiver); in ref redefines Actions::AcceptAction::receiver = this; } action acpt_after subsets Actions::Action:acceptSubactions { in ref redefines Actions::AcceptAction::payload = Systems Modeling Language v2.0, Part 1 431 -Triggers::TriggerAfter(duration_expr, receiver); in ref redefines Actions::AcceptAction::receiver = this; } } Note that the checkAcceptActionUsageReceiverBindingConnector constraint requires that the second parameter of a TriggerInvocationExpression be bound to the receiver parameter of the containing AcceptActionUsage , indicating that it is the AcceptActionUsage receiver that is to be signaled by the trigger. Each of the Triggers Functions also has two additional parameters , which all get their default values. 1. clock , typed by Clocks::Clock (see [KerML, 9.2.12]), defaults to Occurrences::Occurrence::localClock (see [KerML, 9.2.4]). 2. monitor , typed by Observation::ChangeMonitor (see [KerML, 9.2.13]), defaults to Observation::defaultMonitor . In particular, the Occurrences::Occurrence::localClock itself defaults to the singleton universalClock (see 9.8.8.2.13 and [KerML, 9.2.12]). However, for a suboccurrence , this default is overridden to instead be the localClock of the containing Occurrence . This means that binding the localClock feature to a new Clock instance in an OccurrenceDefinition or OccurrenceUsage (particularly a PartDefinition or PartUsage ) means that this Clock instance will be used as the default for all contained suboccurrences (particularly ownedActions and subactions ) at any level of nesting in the composition hierarchy (unless it is further overridden at some lower level). part def TimeContext specializes Parts::Part { ref redefines localClock = new Time::Clock(); action behavior subsets Parts::Part::ownedActions { // Uses the value bound to TimeContext::localClock, // not the default universalClock. action subsets Actions::Action::acceptSubactions accept after 30 [SI::s]; } } 8.4.13.7 Assignment Action Usages An AssignmentActionUsage is a kind of ActionUsage , so all general semantic constraints for an ActionUsage (see 8.4.13.2 ) also apply to an AssignmentActionUsage , as well as the following additional specialization constraints: • checkAssignmentActionUsageSpecialization requires that an AssignmentActionUsage specialize the ActionUsage Actions::assignmentActions (see 9.2.10.2.7 ), which is defined by the ActionDefinition Actions::AssignmentAction (see 9.2.10.2.6 ) and subsets Actions::Action::actions (see 9.2.10.2.5 ). • checkAssignmentActionUsageSubactionSpecialization constraint requires that an AssignmentActionUsage that is composite, has an owningType that is an ActionDefinition or ActionUsage , and is not the entryAction or exitAction of a StateDefinition or StateUsage (see 8.4.14 ) specialize the ActionUsage Actions::Action::assignments (see 9.2.10.2.4 ), which subsets Actions::assignmentActions and Actions::Action::subactions . An AssignmentActionUsage has two input parameters for the target Occurrence and the replacementValues to be assigned. The target has a time slice called startingAt with a nested feature called accessedFeature . The referent Feature to be assigned by the AssignmentActionUsage is actually parsed as an alias member of the AssignmentActionUsage (see 8.2.2.17.4 ). The following constraints then apply: • checkAssignmentActionUsageStartingAtRedefinition requires that the first ownedFeature of the first parameter of an AssignmentActionUsage (the target parameter ) redefines Actions::AssignmentAction::target::startingAt . 432 Systems Modeling Language v2.0, Part 1 -• checkAssignmentActionUsageAccessedFeatureRedefinition requires that the first ownedFeature of the above redefinition of startingAt redefines Actions::AssignmentAction::target::startingAt::accessedFeature . • checkAssignmentActionReferentRedefinition requires that target.startingAt.accessedFeature of the AssignmentActionUsage redefine the referent Feature . An AssignmentActionUsage declaration of the form action asgn assign tgt.rfnt := val; (where tgt and val are Expressions and rfnt is a qualified name or feature chain) is parsed (including implied Specializations ) as action asgn subsets Actions::assignmentActions { in ref redefines Actions::AssignmentAction::target = tgt { redefines Actions::AssignmentAction::target::startingAt { redefines Actions::AssignmentAction::target::startingAt::accessedFeature, rfnt; } } inout ref redefines Actions::AssignmentAction::replacementValues = val; } AssignmentAction subclassifies the Actions::Action (see 9.2.10.2.4 ) and the kernel Behavior ControlPerformances::FeatureWritePerformance (see [KerML, 9.2.9]). The semantics of FeatureWritePerformance is that, at the time it ends, the accessedFeature of the target Occurrence will have the given replacementValues . 8.4.13.8 Terminate Action Usages A TerminateActionUsage is a kind of ActionUsage , so all general semantic constraints for an ActionUsage (see 8.4.13.2 ) also apply to a TerminateActionUsage , as well as the following additional specialization constraints: • checkTerminateActionUsageSpecialization requires that a TerminateActionUsage specialize the ActionUsage Actions::terminateActions (see 9.2.10.2.25 ), which is defined by the ActionDefinition Actions::TerminateAction (see 9.2.10.2.24 ) and subsets Actions::Action::actions (see 9.2.10.2.5 ). • checkTerminateActionUsageSubactionSpecialization constraint requires that a TerminateActionUsage that is composite, has an owningType that is an ActionDefinition or ActionUsage , and is not the entryAction or exitAction of a StateDefinition or StateUsage (see 8.4.14 ) specialize the ActionUsage Actions::Action::terminateSubactions (see 9.2.10.2.4 ), which subsets Actions::terminateActions and Actions::Action::subactions . A TerminateActionUsage optionally provides an argument for the terminatedOccurrence parameter of a TerminateAction . A TerminateActionUsage declaration of the form action trm terminate occ; (where occ is an Expression ) is parsed (including implied Specializations , presuming the TerminateActionUsage is a subaction ) as (see 8.4.13.8 ): action trm subsets Actions::Action::terminateSubactions { in ref redefines Actions::terminateActions::terminatedOccurrence = occ; } Systems Modeling Language v2.0, Part 1 433 -When a TerminateAction is performed, it has a nested composite ActionUsage of the KerML Function Library Function OccurrenceFunctions::destroy , with the terminatedOccurrence as its argument. The semantics of destroy then require that the lifetime of the terminateOccurrence end during the performance of destroy and, hence, during the performance of the TerminateAction . The TerminateAction::terminatedOccurrence parameter is mandatory, but the ActionUsage terminateActions provides a default of that for this parameter. As specified in [KerML], this means that, by default, the terminatedOccurrence will be the featuring instance of a terminateAction , which will generally be the immediately containing Action within which the terminateAction is being performed. 8.4.13.9 If Action Usages An IfActionUsage is a kind of ActionUsage , so all general semantic constraints for an ActionUsage (see 8.4.13.2 ) also apply to an IfActionUsage , as well as the following additional specialization constraints: • checkIfActionUsageSpecialization requires that ◦ If an IfActionUsage does not have an elseAction , it specialize the ActionUsage Actions::ifThenActions (see 9.2.10.2.15 ), which is defined by the ActionDefinition Actions::IfThenAction (see 9.2.10.2.14 ) and subsets Actions::Action::actions (see 9.2.10.2.5 ). ◦ If the IfActionUsage has an elseAction , it specialize the ActionUsage Actions::ifThenElseActions (see 9.2.10.2.17 ), which is defined by the ActionDefinition Actions::IfThenElseAction (see 9.2.10.2.14 ) and subsets Actions::Action::actions (see 9.2.10.2.5 ). • checkIfActionUsageSubactionSpecialization constraint requires that an IfActionUsage that is composite, has an owningType that is an ActionDefinition or ActionUsage , and is not the entryAction or exitAction of a StateDefinition or StateUsage (see 8.4.14 ) specialize the ActionUsage Actions::Action::ifSubactions (see 9.2.10.2.4 ), which subsets Actions::ifThenActions and Actions::Action::subactions . The ActionDefinition IfThenAction has two input parameters : ifTest , which is a BooleanEvaluation , and thenClause , which is an Action . IfThenElseAction specializes IfThenAction , adding a third input parameter : elseClause , which is also an Action . The ifArgument , thenAction and (optionally) elseAction of an IfActionUsage are then parsed as parameters of the IfActionUsage that redefine the corresponding parameters of the IfThenAction or IfThenElseAction . Thus, IfActionUsages such as the following: action def AC { action if1 if test1 then action then1 { // ... } action if2 if test2 then action then2 { // ... } else action else2 { // ... } } (where test1 and test2 can be arbitrary Boolean -valued Expressions ) are parsed, with implied Specializations included, as (see 8.2.2.17.7 ): 434 Systems Modeling Language v2.0, Part 1 -action def AC specializes Actions::Action { action if1 subsets Actions::Action::ifSubactions { in calc redefines Actions::IfThenAction::ifTest { test1 } in action then1 redefines Actions::IfThenAction::thenClause { // ... } } action if2 subsets Actions::Action::ifSubactions, Actions::ifThenElseActions { in calc redefines Actions::IfThenAction::ifTest { test1 } in action then1 redefines Actions::IfThenAction::thenClause { // ... } in action else2 redefines Actions::IfThenElseAction::elseClause { // ... } } IfThenAction specializes the KerML Behavior IfThenPerformance , whose behavior is to first evaluate the ifTest and then, if the result of that evaluation is true, perform the thenClause . IfThenElseAction specializes the KerML Behavior IfThenElsePerformance , which specializes IfThenPerformance , adding the additional behavior such that, if the result of the evaluation of the ifTest is false, it performs the elseClause . 8.4.13.10 Loop Action Usages A LoopActionUsage is a kind of ActionUsage , so all general semantic constraints for an ActionUsage (see 8.4.13.2 ) also apply to a LoopActionUsage . LoopActionUsage is abstract. There are two concrete subclasses of LoopActionUsage , WhileLoopActionUsage and ForLoopActionUsage , and further semantic constraints are specific to those subclasses. While Loops A WhileLoopActionUsage is a kind of LoopActionUsage . The following additional specialization constraints apply to a WhileLoopActionUsage : • checkWhileLoopActionUsageSpecialization requires that a WhileLoopActionUsage specialize the ActionUsage Actions::whileLoopActions (see 9.2.10.2.29 ), which is defined by the ActionDefinition Actions::WhileLoopAction (see 9.2.10.2.28 ) and (indirectly) subsets Actions::Action::actions (see 9.2.10.2.5 ). • checkWhileLoopActionUsageSubactionSpecialization requires that a WhileLoopActionUsage that is composite, has an owningType that is an ActionDefinition or ActionUsage , and is not the entryAction or exitAction of a StateDefinition or StateUsage (see 8.4.14 ) specialize the ActionUsage Actions::Action::whileLoops (see 9.2.10.2.4 ), which subsets Actions::whileLoopActions and (indirectly) Actions::Action::subactions . A WhileLoopAction has three input parameters : 1. whileTest , which is a BooleanExpression that defaults to true 2. body , which is an Action 3. untilTest , which is a BooleanExpression that defaults to false Systems Modeling Language v2.0, Part 1 435 -The whileArgument , bodyAction , and untilArgument of the WhileLoopActionUsage are then parsed as owned parameters (see 8.2.2.17.7 ), which must redefine the corresponding parameters of WhileLoopAction , as required by the KerML checkFeatureParameterRedefinition constraint (see [KerML, 8.4.4.7.1]). Thus, a WhileLoopActionUsage such as the following action def AW { action loop1 while test1 action body1 { // ... } until test2; } (where test1 and test2 can be arbitrary Boolean -valued Expressions ) is parsed, with implied Specializations included, as: action def AW specializes Actions::Action { action loop1 subsets Actions::Action::whileLoops { in calc redefines Actions::WhileLoopAction::whileTest { test1 } in action body1 redefines Actions::WhileLoopAction::body { // ... } in calc redefines Actions::WhileLoopAction::untilTest { test2 } } } WhileLoopAction specializes the KerML Behavior LoopPerformance , whose behavior is to perform the body while the whileTest evaluates to true and the untilTest evaluates to false. The whileTest is evaluated before each (possible) performance of the body , and the untilTest is evaluated after each performance of the body . For Loops A ForLoopActionUsage is a kind of LoopActionUsage . The following additional specialization constraints apply to a ForLoopActionUsage : • checkForLoopActionUsageSpecialization requires that a ForLoopActionUsage specialize the ActionUsage Actions::forLoopActions (see 9.2.10.2.13 ), which is defined by the ActionDefinition Actions::ForLoopAction (see 9.2.10.2.12 ) and (indirectly) subsets Actions::Action::actions (see 9.2.10.2.5 ). • checkForLoopActionUsageSubactionSpecialization constraint requires that a ForLoopActionUsage that is composite, has an owningType that is an ActionDefinition or ActionUsage , and is not the entryAction or exitAction of a StateDefinition or StateUsage (see 8.4.14 ) specialize the ActionUsage Actions::Action::forLoops (see 9.2.10.2.4 ), which subsets Actions::forLoopActions and (indirectly) Actions::Action::subactions . ForLoopAction has two input parameters : 1. seq , which is a sequence of Anything 2. body, which is an Action It also has a protected ownedFeature var that is a subset of seq with multiplicity 0..1 . The loopVariable , seqArgument , and bodyAction of a ForLoopActionUsage are parsed as follows (see 8.2.2.17.7 ): 436 Systems Modeling Language v2.0, Part 1 -1. loopVariable is an ownedFeature 2. seqArgument is related by a FeatureValue to an owned parameter 3. bodyAction is an owned parameter The checkForLoopActionUsageVarRedefinition constraint then requires that the loopVariable redefine ForLoopAction::var . The KerML checkFeatureParameterRedefinition constraint (see [KerML, 8.4.4.7.1]) requires that the two parameters redefine the corresponding parameters seq and body of ForLoopAction . Thus, a ForLoopActionUsage such as the following action def AF { action loop2 for v : T in vals action body2 { // ... } } (where vals is an Expression ) is parsed, with implied Specializations included, as: action def AF specializes Actions::Action { action loop2 subsets Actions::Action::forLoops { protected v : T redefines Actions::ForLoopAction::var; in ref redefines Actions::ForLoopAction::seq = vals; in action body2 redefines Actions::ForLoopAction::body { // ... } } } ForLoopAction uses a nested WhileLoopActionUsage to iteratively perform its body Action , with its var assigned to each successive value from seq in turn. 8.4.13.11 Perform Action Usages A PerformActionUsage is a kind of ActionUsage and a kind of EventOccurrenceUsage . As such, all general semantic constraints on an ActionUsage (see 8.4.13.2 ) and an EventOccurrenceUsage (see 8.4.5.3 ) also apply to a PerformActionUsage . In particular, validateEventOccurrenceUsageIsReference requires a PerformActionUsage to be referential. In addition, if a PerformActionUsage is an ownedFeature of a PartDefinition or PartUsage , then the checkPerformActionUsageSpecialization constraint requires that it specialize the ActionUsage Parts::Part::performedActions (see 9.2.4.2.1 ), which subsets Actions::actions (see 9.2.10.2.5 ) and the kernel Feature Occurrences::Occurrence::enactedPerformances (see [KerML, 9.2.4]). In this case, any Action referenced by the PerformActionUsage is considered to have been performed by the containing Part within its lifetime. For example, the following model: action act; part p { perform action perf references act; // Other than having a name, the above is equivalent to // perform act; } is, with implied Specializations included, semantically equivalent to Systems Modeling Language v2.0, Part 1 437 -action act1 subsets Actions::actions; part p subsets Parts::parts { ref action perf references act subsets Parts::Part::performedActions; } Thus, the values of p.perf will be some subset of the Actions represented by act that are performed by p . As a referential ActionUsage , a PerformActionUsage that is an ownedFeature of an ActionDefinition or ActionUsage is required by the KerML checkStepEnclosedPerformanceSpecialization constraint (see [KerML, 8.4.4.7.2]) to specialize Performances::Performance::enclosedPerformance (see [KerML, 9.2.6]). If the PerformActionUsage has a ReferenceSubsetting , then this will suffice to satisfy the checkActionUsageSpecialization constraint, if the referenced ActionUsage does. However, if it does not have a ReferenceSubsetting (or other relevant explicit ownedSpecialization ), it requires an implied Subsetting of Actions::actions . action def APA specializes Actions::Action { perform action pa1 references act subsets Performances::Performance::enclosedPerformances; perform action pa2 subsets Actions::actions subsets Performances::Performance::enclosedPerformances; } A PerformActionUsage that is an ownedFeature of an OccurrenceDefinition or OccurrenceUsage but not a PartDefinition , PartUsage , ActionDefinition or ActionUsage has the same semantics as an EventOccurrenceUsage in that context, with an ActionUsage as its referenced OccurrenceUsage (see 8.4.5.3 ). Otherwise, a PerformActionUsage has the same semantics as a referential ActionUsage (see 8.4.13.2 ). 8.4.14 States Semantics Abstract syntax reference: 8.3.18 8.4.14.1 State Definitions A StateDefinition is a kind of ActionDefinition . As such, all the general semantic constraints for an ActionDefinition (see 8.4.13.1 ) also apply to a StateDefinition . In addition, the checkStateDefinitionSpecialization constraint requires that a StateDefinition specialize the base StateDefinition States::StateAction (see 9.2.11.2.1 ), which specializes the ActionDefinition Actions::Action (see 9.2.10.2.4 ) and the kernel Behavior StatePerformances::StatePerformance (see [KerML, 9.2.6]). state def S specializes States::StateAction; state def S1 specializes S; Further, the checkActionUsageStateActionRedefinition constraint (see 8.4.13.2 ) requires that an ActionUsage that is an entryAction , exitAction or doAction of a StateDefinition (i.e., is owned via a StateSubactionMembership ) redefine, respectively, the entryAction , exitAction , or doAction feature of StateAction (see 9.2.11.2.1 ), which redefine the entry , exit , and do features of StatePerformances::StatePerformance (see [KerML, 9.2.6]), restricting them to be Actions (see 9.2.10.2.4 ). state def SA specializes States::StateAction { entry action entAct redefines States::StateAction::entryAction; do action doAct redefines States::StateAction::doAction; exit action extAct redefines States::StateAction::exitAction; } 438 Systems Modeling Language v2.0, Part 1 -A StateAction is a kind of StatePerformance , which specifies the basic semantics of entry into a state, the performance of behaviors while in a state, and the acceptance of an incomingTransfer , causing an exit from the state (see [KerML, 9.2.6]). See also the descriptions of the semantics of StateUsages (see 8.4.14.2 ) and TransitionUsages (see 8.4.14.3 ). The StateAction semantic model also includes various additional features related to various kinds of subactions of StateActions : • subactions – Redefines Action::subactions to subset StatePeformances::middle , thus excluding entryActions and exitActions from the collection of subactions for a StateAction (see 8.4.14.2 ). • substates – The subactions that are StateActions (see 8.4.14.2 ). • exclusiveStates – The substates that are mutually exclusive, that is whose performances do not overlap in time. If a StateDefinition or StateUsage is not parallel (i.e., isParallel = false ), than all the substates of its StateActions will be exclusiveStates (see 8.4.14.2 ). • stateTransitions – The subset of transitions (inherited from Action ; see 8.4.13.1 ) that are StateTransitionActions (see 8.4.14.3 ). 8.4.14.2 State Usages A StateUsage is a kind of ActionUsage . As such, all the general semantic constraints for an ActionUsage (see 8.4.13.2 ) also apply to a StateUsage , as well as the following additional specialization constraints: • checkStateUsageSpecialization requires that a StateUsage specialize the base StateUsage States::stateActions (see 9.2.11.2.2 ), which is defined by the StateDefinition States::StateAction (see 9.2.11.2.1 ) and subsets the ActionUsage Actions::actions (see 9.2.10.2.5 ). state s : S subsets States::StateActions; state s1 : S1 subsets s; • checkStateUsageSubstateSpecialization requires that a composite StateUsage whose whose owningType is a StateDefinition or StateUsage , but is not the entryAction or exitAction , specialize the StateUsage States::StateAction::substates (see 9.2.11.2.1 ), which subsets State::StateAction::subactions . • checkStateUsageExclusiveStateSpecialization requires that a composite StateUsage whose whose owningType is a StateDefinition or StateUsage for which isParallel = false , but is not the entryAction or exitAction , specialize the StateUsage States::StateAction::exclusiveStates (see 9.2.11.2.1 ), which subsets State::StateAction::substates . This constraint enforces the semantic requirement that a non- parallel StateAction perform only one substate at a time. state def SE specializes States::StateAction { state se1 subsets States::StateAction::exclusiveStates; state se2 subsets States::StateAction::exclusiveStates; } state def SP specializes States::StateAction parallel { state sp1 subsets States::StateAction::substates; state sp2 subsets States::StateAction::substates; } • checkStateUsageOwnedStateSpecialization requires that a composite StateUsage whose owningType is a PartDefinition or a PartUsage specialize the StateUsage Parts::Part::ownedStates (see 9.2.4.2.1 ), which subsets the ActionUsage Parts::Part::ownedActions . Note also that, in other cases, the general KerML checkStepEnclosedPerformanceSpecialization , checkStepSubperformanceSpecialization and Systems Modeling Language v2.0, Part 1 439 -checkStepOwnedPerformanceSpecialization constraints will still apply (see [KerML, 8.4.4.7]), as well as checkActionUsageSubactionSpecialization (see 8.4.13.2 ). action def AS subsets Action::Action { ref state st1 subsets Performances::Performance::enclosedPerformance; state st2 subsets Actions::Action::ownedActions; } part def PS specializes Parts::Part { state s : S subsets Parts::Part::ownedStates; } item def IS specializes Items::Item { state s : S subsets Objects::Object::ownedPerformances; } In addition, the checkActionUsageStateActionRedefinition constraint (see 8.4.13.2 ) requires that an ActionUsage that is an entry Action, exitAction or doAction of a StateUsage (i.e., is owned via a StateSubactionMembership ) redefine, respectively, the entryAction , exitAction , or doAction feature of the StateDefinition StateAction (see 9.2.11.2.1 ), which redefine the entry , exit , and do features of the kernel Behavior StatePerformances::StatePerformance (see [KerML, 9.2.6]), restricting them to be Actions (see 9.2.10.2.4 ). state sa subsets States::stateActions { entry action entAct redefines States::StateAction::entryAction; do action doAct redefines States::StateAction::doAction; exit action extAct redefines States::StateAction::exitAction; } 8.4.14.3 Transition Usages A TransitionUsage is a kind of ActionUsage . As such, all the general semantic constraints for an ActionUsage (see 8.4.13.2 ) also apply to a TransitionUsage , as well as the following additional specialization constraints: • checkTransitionUsageSpecialization requires that a TransitionUsage specialize the ActionUsage Actions::transitionActions (see 9.2.10.2.27 ), which is defined by the ActionDefinition Actions::TransitionAction (see 9.2.10.2.26 ) and subsets the ActionUsage Actions::actions (see 9.2.10.2.5 ). • checkTransitionUsageActionSpecialization requires that a composite TransitionUsage whose ownedType is an ActionDefinition or ActionUsage , but not a StateDefinition or StateUsage , specialize the ActionUsage Actions::Action::decisionTransitions (see 9.2.10.2.4 ), which is typed by the ActionDefinition Actions::DecisionTransitionAction (see 9.2.10.2.10 ) and subsets the ActionUsage Actions::Action::transitions (see 9.2.10.2.4 ). (For the semantics of TransitionUsages of DecisionTransitionActions , see 8.4.13.3 .) • checkTransitionUsageStateSpecialization requires that a composite TransitionUsage whose ownedType is a StateDefinition or StateUsage specialize the ActionUsage States::StateAction::stateTransitions (see 9.2.11.2.1 ), which is typed by the ActionDefinition States::StateTransitionAction (see 9.2.11.2.3 ) and subsets the ActionUsage Actions::Action::transitions (see 9.2.10.2.4 ). StateTransitionAction subclassifies Actions::TransitionAction (see 9.2.10.2.26 ) and the kernel Behavior StatePerformances::StateTransitionPerformance (see [KerML, 9.2.11]). The transitionLinkSource of a StateTransitionAction must be a StateAction . The StateTransitionAction then represents a possible transition from the source StateAction to a target Action . A TransitionUsage is parsed as having the following ownedMemberships (see 8.2.2.18.3 ): 440 Systems Modeling Language v2.0, Part 1 -• An alias (non-owning) Membership to its source StateUsage ( or a Feature chain identifying the source ). • A ParameterMembership for the transitionLinkSource parameter . • A ParameterMembership for the payload parameter (if the TransitionUsage has a triggerAction ). • Zero to three TransitionFeatureMemberships for up to one each of a triggerAction , guardExpression , and effectAction . Note also that a triggerAction is parsed as an AcceptActionUsage , with payload and, optionally, receiver parameters (see 8.4.13.6 ). • An OwningMembership for the succession of the TransitionUsage , which is a Succession whose targetFeature is the target of the TransitionUsage (or a Feature chain identifying the target ). The following semantic constraints then apply: • checkFeatureParameterRedefinition (see [KerML, 8.4.4.7]) requires that the transitionLinkSource and payload parameters of a TransitionUsage redefinition the corresponding parameters of StateTransitionAction (see 9.2.11.2.3 ), as inherited from Transition • checkTransitionUsagePayloadSpecialization requires that the payload parameter of a TransitionUsage also subset the payloadParameter of the triggerAction . Note also that the effective name of a ReferenceUsage used as the payload parameter of a TransitionUsage is defined to be the name of the payloadParameter it subsets, rather than the name of the StateTransitionAction::payload feature it redefines. • checkTransitionUsageTransitionFeatureSpecialization requires that the triggerAction , guardExpression , and effectAction of a TransitionUsage (if they exist) specialize, respectively, the accepter , guard , and effect features of TransitionAction ( 9.2.10.2.26 ; see also [KerML, 9.2.10, 9.2.11] for inherited features). • checkTransitionUsageSuccessionSourceSpecialization requires that the sourceFeature of the succession of a TransitionUsage be the aliased source for the TransitionUsage . • checkTransitionUsageSuccessionBindingConnector requires that a TransitionUsage have an ownedMember that is a BindingConnector between its succession and the inherited TransitionPerformances::TransitionPerformance::transitionLink feature . • checkTransitionUsageSourceBindingConnector requires that a TransitionUsage have an ownedMember that is a BindingConnector between its source and its transitionLinkSource parameter . • checkConnectorTypeFeaturing (see [KerML, 8.4.4.6.1]) then determines the featuringType of the Succession and two BindingConnectors owned by a TransitionUsage (typically the owningType of the TransitionUsage ). As a result of all the above semantic constraints, a TransitionUsage such as in the following model state def ST { state s1; transition trns first s1 accept x : T via tgt if test effect action efct { // ... } then s2; state s2; } (where test is a Boolean-valued Expression) has, with implied Relationships included, the equivalent kernel semantics of: // KerML behavior ST specializes States::StateAction { Systems Modeling Language v2.0, Part 1 441 -step s1 subsets States::StateAction::exclusiveStates; step trns subsets States::State::stateTransitions { alias s1 of SC::s1; in feature redefines States::StateTransitionAction::transitionLinkSource; in feature x redefines States::StateTransitionAction::payload subsets accepter.x; step redefines Actions::TransitionAction::accepter { inout ref x : T redefines Actions::AcceptAction::payload; in ref redefines Actions::AcceptAction::receiver = tgt; } bool redefines Actions::TransitionAction::guard { test } step efct redefines Actions::TransitionAction::effect { // ... } member succession trns_link subsets Occurrences::happensBeforeLinks featured by ST first s1 then s2; member binding featured by ST of trns_link = TransitionPerformances::TransitionPerformance::transitionLink; member binding featured by ST of s1 = transitionLinkSource; } step s2 subsets States::StateAction::exclusiveStates; } A StateTransitionAction is a kind of StateTransitionPerformance , which specifies the fundamental semantics of transition out of a state. The guard of a StateTransitionAction is evaluated during the performance of its source StateAction , and, if the guard evaluates to true and the transition accepts a Transfer , then its accepter is also performed during the source StateAction , after which the exitAction of the StateAction is performed (if it has one), and then the effect of the StateTransitionAction is performed (if it has one). Finally, the transitionLink of the StateTransitionAction is asserted to have a value, meaning that there must be a target Action temporally following the source StateAction . (For a complete description of the semantics of StateTransitionPerformance , see [KerML, 9.2.10].) 8.4.14.4 Exhibit State Usages An ExhibitStateUsage is a kind of StateUsage and a kind of PerformActionUsage . As such, all general semantic constraints on a StateUsage (see 8.4.14.2 ) and a PerformActionUsage (see 8.4.13.11 ) also apply to a ExhibitStateUsage . In particular, validateEventOccurrenceUsageIsReference requires an ExhibitStateUsage to be referential. In addition, if an ExhibitStateUsage is an ownedFeature of a PartDefinition or PartUsage , then the checkExhibitStateUsageSpecialization constraint requires that it specialize the StateUsage Parts::Part::exhibitStates (see 9.2.4.2.1 ), which subsets State::states (see 7.18 ) and Parts::Part::performedActions . In this case, any State referenced by the ExhibitStateUsage is considered to have been exhibited by the containing Part within its lifetime. For example, the following model: 442 Systems Modeling Language v2.0, Part 1 -state st; part p { exhibit state exhb references st; } is, with implied Specializations included, semantically equivalent to state st subsets State::states; part p subsets Parts::parts { ref state exhb references st subsets Parts::Part::exhibitedStates; } Thus, the values of p.exhb will be the subset of the States represented by st that are performed by p . As a referential StateUsage , an ExhibitStateUsage that is an ownedFeature of an ActionDefinition or ActionUsage (including a StateDefinition or StateUsage ) is required by the KerML checkStepEnclosedPerformanceSpecialization constraint (see [KerML, 8.4.4.7.2]) to specialize Performances::Performance::enclosedPerformance (see [KerML, 9.2.6]). If the ExhibitStateUsage has a ReferenceSubsetting , then this will suffice to satisfy the checkStateUsageSpecialization constraint, if the referenced StateUsage does. However, if it does not have a ReferenceSubsetting (or other relevant explicit ownedSpecialization ), it requires an implied Subsetting of State::states . state def SES specializes States::State { exhibit state es1 references st subsets Performances::Performance::enclosedPerformances; exhibit state es2 subsets State::states subsets Performances::Performance::enclosedPerformances; } An ExhibitStateUsage that is an ownedFeature of an OccurrenceDefinition or OccurrenceUsage but not a PartDefinition , PartUsage , ActionDefinition or ActionUsage has the same semantics as an EventOccurrenceUsage in that context, with a StateUsage as its referenced OccurrenceUsage (see 8.4.5.3 ). Otherwise, an ExhibitStateUsage has the same semantics as a referential StateUsage (see 8.4.14.2 ). 8.4.15 Calculations Semantics Abstract syntax reference: 8.3.19 8.4.15.1 Calculation Definitions A CalculationDefinition is a kind of ActionDefinition and a kind of KerML Function . As such, all the general semantic constraints for an ActionDefinition (see 8.4.13.1 ) and a Function (see [KerML, 8.4.4.8.1]) apply to a CalculationDefinition . In addition, the checkCalculationDefinitionSpecialization constraint requires that a CalculationDefinition specialize the base CalculationDefinition Calculations::Calculation (see 9.2.12.2.1 ), which subclassifies the ActionDefinition Actions::Action (see 9.2.10.2.4 ) and the kernel Behavior Performances::Evaluation (see [KerML, 9.2.6]). Further, in addition to the KerML checkFeatureParameterRedefinition constraint, that applies to all kinds of ActionDefinitions (see 8.4.13.1 ), the KerML checkFeatureResultRedefinition constraint (see [KerML, 8.4.4.8.1]) constraint also requires that the result parameter of a CalculationDefinition redefine the result parameters of any Functions it specializes (including other CalculationDefinitions ), which means that it ultimately directly or indirectly specializes Performances::Evaluation::result . calc def C specializes Calculations::Calculation { in ref a redefines Base::things; in ref b redefines Base::things; Systems Modeling Language v2.0, Part 1 443 -return ref result redefines Calculations::Calculation::result; } calc def C1 specializes C { in ref a redefines C::a; // The result parameter can be in any position. return ref result redefines C::result; in ref b redefines C::b; } Further, if a CalculationDefinition owns an Expression via a ResultExpressionMembership , then the KerML checkFunctionResultBindingConnector constraint (see [KerML, 8.4.4.8.1]) requires that the CalculationDefinition have, as an ownedFeature , a BindingConnector between the result parameter of the Expression and the result parameter of the CalculationDefinition . calc def C2 specializes Calculations::Calculation { return redefines Calculations::Calculation::result; binding result = resultExpr.result; // Implied resultExpr } where resultExpr is an arbitrary Expression and resultExpr.result represents a Feature chain to the Expression result . 8.4.15.2 Calculation Usages A CalculationUsage is a kind of ActionUsage and a kind of KerML Expression . As such, all the general semantic constraints for an ActionUsage (see 8.4.13.2 ) and an Expression (see [KerML, 8.4.4.8.2]) apply to a CalculationUsage , as well as the following additional specialization constraints: • checkCalculationUsageSpecialization requires that a CalculationUsage specialize the base CalculationUsage Calculations::calculations (see 9.2.12.2.2 ), which is defined by the CalculationDefinition Calculations::Calculation (see 9.2.12.2.1 ) and subsets the ActionUsage Actions::actions (see 9.2.10.2.4 ) and the kernel Step Performances::evaluations (see [KerML, 9.2.6]). Further, in addition to the KerML checkFeatureParameterRedefinition constraint, that applies to all kinds of ActionUsages (see 8.4.13.2 ), the KerML checkFeatureResultRedefinition constraint (see [KerML, 8.4.4.8.1]) also requires that the result parameter of a CalculationUsage redefine the result parameters of any Functions or Expressions it specializes (including CalculationDefinitions and CalculationUsages ). calc c : C subsets Calculations::calculations { in ref a redefines C::a; in ref b redefines C::b; return result redefines C::result, Calculation::calculations::result; } calc c1 : C1 subsets c { return ref result redefines C1::result, c::result; } • checkCalculationUsageSubcalculationSpecialization requires that a CalculationUsage that is composite and has an owningType that is a CalculationDefinition or CalculationUsage specialize the CalculationUsage Calculations::Calculation::subcalculations (see 9.2.12.2.1 ), which subsets Calculations::calculations and the ActionUsage Actions::Action::subactions (see 9.2.10.2.4 ). Note also that, in other cases, the general checkActionUsageSubactionSpecialization constraint (see 8.4.13.2 ) and the KerML checkStepEnclosedPerformanceSpecialization and checkStepSubperformanceSpecialization constraints (see [KerML, 8.4.4.7]) will still apply. 444 Systems Modeling Language v2.0, Part 1 -calc def Clc subsets Calculations::Calculation { calc clc1 subsets Calculations::Calculation::subcalculations; ref calc clc2 subsets Calculations::calculations, Performances::Performance::enclosedPerformances; } action def AClc subsets Actions::Action { calc clc3 subsets Calculations::calculations, Actions::Action::subactions; } Further, if a CalculationUsage owns an Expression via a ResultExpressionMembership , then the KerML checkExpressionResultBindingConnector constraint (see [KerML, 8.4.4.8.1]) requires that the CalculationUsage have, as an ownedFeature , a BindingConnector between the result parameter of the Expression and the result parameter of the CalculationUsage . calc c2 subsets Calculations::calculations { binding result = resultExpr.result; // Implied resultExpr } where resultExpr is an arbitrary Expression and resultExpr.result represents a Feature chain to the Expression result . 8.4.16 Constraints Semantics Abstract syntax reference: 8.3.20 8.4.16.1 Constraint Definitions A ConstraintDefinition is a kind of OccurrenceDefinition and a kind of KerML Predicate . As such, all the general semantic constraints for an OccurrenceDefinition (see 8.4.5 ) and a Predicate (see [KerML, 8.4.4.8.1]) also apply to a ConstraintDefinition . In addition, the checkConstraintDefinitionSpecialization constraint requires that a ConstraintDefinition specialize the base ConstraintDefinition Constraints::ConstraintCheck (see 9.2.10.2.4 ), which subclassifies the kernel Predicate Performances::BooleanEvaluation (see [KerML, 9.2.6]). A ConstraintDefinition is not a CalculationDefinition , but, since a Predicate is a kind of KerML Function , the KerML checkFeatureParameterRedefinition constraint (see [KerML, 8.4.4.7.1]) and checkFeatureResultRedefinition (see [KerML, 8.4.4.8.1]) constraints also apply to the parameters of a ConstraintDefinition , as for a CalculationDefinition (see 8.4.15.1 ). However, the result parameter of BooleanEvaluation has type ScalarValues::Boolean , so the result of a ConstraintDefinition must also have type Boolean (or a specialization of it), and, therefore, it is often just inherited into the ConstraintDefinition . Also as for a CalculationDefinition , if a ConstraintDefinition owns an Expression via a ResultExpressionMembership , then the KerML checkFunctionResultBindingConnector constraint (see [KerML, 8.4.4.8.1]) requires that the ConstraintDefinition have, as an ownedFeature , a BindingConnector between the result parameter of the Expression and the result parameter of the ConstraintDefinition . The result Expression must therefore be Boolean -valued. constraint def Cst specializes Constraints::ConstraintCheck { in attribute x : ScalarValues::Real subsets Base::dataValues; // Implied binding between the inherited result parameter // and the result of the Expression x > 0. x > 0 } Systems Modeling Language v2.0, Part 1 445 -8.4.16.2 Constraint Usages A ConstraintUsage is a kind of OccurrenceUsage and a kind of KerML Expression . As such, all the general semantic constraints for an OccurrenceUsage (see 8.4.5 ) and an Expression (see [KerML, 8.4.4.8.2]) also apply to a ConstraintUsage , as well as the following additional specialization constraints: • checkConstraintUsageSpecialization requires that a ConstraintUsage specialize the base ConstraintUsage Constraints::constraintChecks (see 9.2.13.2.3 ), which is defined by the ConstraintDefinition Constraints::ConstraintCheck (see 9.2.13.2.2 ) and subsets the kernel Step Performances::booleanEvaluations (see [KerML, 9.2.6]). Further, the KerML checkFeatureParameterRedefinition constraint (see [KerML, 8.4.4.7.1]) and checkFeatureResultRedefinition (see [KerML, 8.4.4.8.1]) constraints also apply to the parameters of a ConstraintUsage , as for a ConstraintDefinition (see 8.4.16.1 ). constraint cst : Cst subsets Constraints::constraintChecks { in ref x redefines Cst::x = 2; // Inherits result parameter and result Expression from Cst. } • checkConstraintUsageCheckedConstraintSpecialization requires that a composite ConstraintUsage whose owningType is an ItemDefinition or an ItemUsage (including a PartDefinition or PartUsage ) specialize the ConstraintUsage Items::Item::checkedConstraints (see 9.2.4.2.1 ), which subsets the ConstraintUsage Constraints::constraintChecks and the kernel Feature Objects::Object::ownedPerformances (see [KerML, 9.2.5]). Note also that, in other cases, the general KerML checkStepOwnedPerformanceSpecialization constraint will still apply (see [KerML, 8.4.4.7]). item def ICst specializes Items::Item { constraint c : Cst subsets Items::Item::checkedConstraints; } action def ACst specializes Actions::Action { constraint c : Cst subsets Objects::Object::ownedPerformances; } • checkConstraintUsageRequirementConstraintSpecialization requires that a ConstraintUsage whose owningFeatureMembership is a RequirementConstraintMembership specialize either the assumptions (if it is an assumedConstraint ) or constraints (if it is a requiredConstraint ) feature of the RequirementDefinition Requirements::RequirementCheck (see 9.2.14.2.8 ). (See also 8.4.17 on requirements semantics.) 8.4.16.3 Assert Constraint Usages An AssertConstraintUsage is a kind of ConstraintUsage and a kind of KerML Invariant . As such, all the general semantic constraints for a ConstraintUsage (see 8.4.16.2 ) and an Invariant (see [KerML, 8.4.4.8.2]). In addition, the checkAssertConstraintUsageSpecialization constraint requires that an AssertConstraintUsage specialize one of the following: • If the AssertConstraintUsage is not negated, ConstraintUsage Constraints::assertedConstraintChecks (see 9.2.13.2.1 ), which subsets the ConstraintUsage Constraints::constraintChecks (see 9.2.13.2.3 ) and the kernel Expression Performances::trueEvaluations (see [KerML, 9.2.6]). • If the AssertConstraintUsage is negated, the ConstraintUsage Constraints::negatedConstraintChecks (see 9.2.13.2.4 ), which subsets the ConstraintUsage Constraints::constraintChecks (see 9.2.13.2.3 ) and the kernel Expression Performances::falseEvaluations (see [KerML, 9.2.6]). 446 Systems Modeling Language v2.0, Part 1 -assert constraint ast references cst subsets Constraints::assertedConstraints; assert constraint ast1 : Cst subsets Constraints::assertedConstraints { redefines x = 3; } assert not constraint ast2 : Cst subsets Constraints::negatedConstraints { redefines x = -3; } In general, a ConstraintCheck of a ConstraintUsage at a certain point in time produces a Boolean result indicating whether the modeled constraint holds or not at that point in time. This may be true at some times and false at other times. However, assertedConstraintChecks subsets trueEvaluations , which only includes BooleanEvaluations that have true results . Therefore, a ConstraintCheck of a non-negated AssertConstraintUsage must have a true result —that is, the constraint modeled by the AssertConstraintUsage is asserted to always hold. Similarlty, negatedConstraintChecks subsets falseEvaluations , which only includes BooleanEvaluations that have false results . Therefore, a ConstraintCheck of a negated AssertConstraintUsage must have a false result —that is, the constraint modeled by the AssertConstraintUsage is asserted to never hold. 8.4.17 Requirements Semantics Abstract syntax reference: 8.3.21 8.4.17.1 Requirement Definitions A RequirementDefinition is a kind of ConstraintDefinition . As such, all the general semantic constraints for a ConstraintDefinition (see 8.4.16.1 ) also apply to a RequirementDefinition . In addition, the checkRequirementDefinitionSpecialization constraint requires that a RequirementDefinition specialize the base RequirementDefinition Requirements::RequirementCheck (see 9.2.14.2.8 ), which specializes the ConstraintDefinition Constraints::ConstraintCheck (see 9.2.13.2.2 ). requirement def R specializes Requirements::RequirementCheck; requirement def R1 specializes R; A RequirementDefinitions differs from a plain ConstraintDefinition in that it represents a condition on a subject in terms of assumed and required constraints. • validateRequirementDefinitionSubjectParameterPosition requires that the subjectParameter of a RequirementDefinition be its first parameter. Thus, as a result of the KerML checkFeatureParameterRedefinition constraint (see [KerML, 8.4.4.7.1]), the subjectParameter of a RequirementDefinition will always redefine the subjectParameter of any RequirementDefinitions it specializes, and so will directly or indirectly redefine the base subject parameter Requirements::RequirementCheck::subj (see 9.2.14.2.8 ). • checkConstraintUsageRequirementConstraintSpecialization (see 8.4.16.2 ) requires that a ConstraintUsage that is an assumedConstraint or requiredConstraint of a RequirementDefinition specialize, respectively, the assumptions or constraints feature of RequirementCheck , both of which subset Constraints::constraintChecks (see 9.2.13.2.3 ). requirement def R2 specializes Requirements::RequirementCheck { subject subj redefines Requirements::RequirementCheck::subj; assume constraint ca subsets Requirements::RequirementCheck::assumptions; require constraint cr subsets Requirements::RequirementCheck::constraints; } The result of a RequirementCheck is defined to be the following logical test: if all the assumptions have a true result , then all the constraints must have a true result. In addition to the assumedConstraints and requiredConstraints declared as above, RequirementCheck includes two other features that contribute to the requiredConstraints that are checked: Systems Modeling Language v2.0, Part 1 447 -• subrequirements – Collects the values of the composite RequirementUsages featured by a RequirementCheck , subsetting constraints . (See 8.4.17.2 on the semantics of RequirementUsages .) • concernChecks – Collects the values of the composite ConcernUsages featured by a RequirementCheck , subsetting subrequirements (since ConcernUsages are kinds of RequirementUsages ). (See 8.4.17.5 on the semantics of ConcernUsages .) Finally, RequirementCheck includes two features that collect the values of PartUsages representing entities playing actor and stakeholder roles relative to a RequirementDefinition (or RequirementUsage ): • actors – Collects the values of PartUsages that are owned via ActorMemberships . (See also 8.4.7.2 on the semantics of PartUsages .) • stakeholders – Collects the values of PartUsages that are owned via StakeholderMemberships . (See also 8.4.7.2 on the semantics of PartUsages .) requirement def R3 specializes Requirements::RequirementCheck { actor a subsets Requirements::RequirementCheck::actors; stakeholder s subsets Requirements::RequirementCheck::stakeholders; } 8.4.17.2 Requirement Usages A RequirementUsage is a kind of ConstraintUsage . As such, all the general semantic constraints for a ConstraintUsage (see 8.4.16.2 ) also apply to a RequirementUsage , as well as the following additional specialization constraints: • checkRequirementUsageSpecialization requires that a RequirementUsage specialize the base RequirementUsage Requirements::requirementChecks (see 9.2.14.2.9 ), which subsets Constraints::constraintChecks (see 9.2.13.2.3 ). requirement r : R subsets Requirements::requirementChecks; • checkRequirementUsageSubrequirementSpecialization requires that a composite RequirementUsage whose owningType is a RequirementDefinition or RequirementUsage specialize the RequirementUsage Requirements::RequirementCheck::subrequirements (see 9.2.14.2.8 ), which subsets Requirements::RequirementCheck::constraints (see also 8.4.17.1 ). requirement def Rqt specializes Requirements::RequirementCheck { requirement rqt1 subsets Requirements::RequirementCheck::subrequirements; ref requirement rqt2 subsets Requirements::requirements, Performances::enclosedPerformances; } • checkRequirementUsageObjectiveRedefinition requires that a RequirementUsage owned by a CaseDefinition or CaseUsage via an ObjectiveMembership redefine the objectiveRequirement of each CaseDefinition or CaseUsage specialized by its owningType. (See also 8.4.18 on Case Semantics.) • checkRequirementUsageRequirementVerificationSpecialization requires that a RequirementUsage that is owned by the objective of a CaseDefinition or CaseUsage via a RequirementVerificationMembership specializes the RequirementUsage VerificationCases::VerificationCase::obj::requirementVerifications (see VerificationCase). Similarly to RequirementDefinitions , a RequirementUsage also has a subject and assumed and required constraints (see also 8.4.17.1 ). 448 Systems Modeling Language v2.0, Part 1 -• validateRequirementUsageSubjectParameterPosition requires that the subjectParameter of a RequirementUsage be its first parameter. Thus, as a result of the KerML checkFeatureParameterRedefinition constraint (see [KerML, 8.4.4.7.1]), the subjectParameter of a RequirementUsage will always redefine the subjectParameter of any RequirementDefinitions and RequirementUsages it specializes, and so will directly or indirectly redefine the base subject parameter Requirements::RequirementCheck::subj (see 9.2.14.2.8 ). • checkConstraintUsageRequirementConstraintSpecialization (see 8.4.16.2 ) requires that a ConstraintUsage that is an assumedConstraint or requiredConstraint of a RequirementUsage specialize, respectively, the assumptions or constraints feature of RequirementCheck , both of which subset Constraints::constraintChecks (see 9.2.13.2.3 ). requirement r1 : R1 subsets Requirements::requirementChecks { subject subj redefines R1::subj; assume constraint ca subsets Requirements::RequirementCheck::assumptions; require constraint cr subsets Requirements::RequirementCheck::constraints; } 8.4.17.3 Satisfy Requirement Usages A SatisfyRequirementUsage is a kind of RequirementUsage and a kind of AssertConstraintUsage . As such, all the general semantic constraints for a RequirementUsage (see 8.4.17.2 ) and an AssertConstraintUsage (see 8.4.16.3 ) also apply to a SatisfyRequirementUsage . In addition, the checkSatisfyRequirementUsageBindingConnector constraint requires that a SatisfyRequirementUsage have a BindingConnector between its subjectParameter and some other Feature , which is then considered to be the satisfyingFeature of the SatisfyRequirementUsage . Further, the checkAssertConstraintUsageSpecialization applies to a SatisfyRequirementUsage , so it must either specialize Constraints::assertedConstraintChecks (see 9.2.13.2.1 ), or Constraints::negatedConstraintChecks (see 9.2.13.2.4 ), if negated. Together, these constraints mean that a SatisfyRequirementUsage asserts the satisfaction (or not, if negated) of a requirement when the satisfyingFeature is bound as the subject of the requirement A SatisfyRequirementUsage of the form satisfy requirement sr : R by f; is parsed with f bound to the subjectParameter of the SatisfyRequirementUsage using a FeatureValue Relationship (see 8.2.2.21.2 ). The KerML checkFeatureValueBindingConnector constraint (see [KerML, 8.4.4.11]) then requires that the SatisfyRequirementUsage have a BindingConnector that effectively also meets the checkSatisfyRequirementUsageBindingConnector constraint. satisfy requirement sr : R subsets Requirements::requirementChecks, Constraints::assertedConstraintChecks { subject subj redefines R::subj = f; // Implicit BindingConnector for the FeatureValue also meets // the checkSatisfyRequirementUsageBindingConnector constraint. bind subj = subj::f_expr.result; } where f_expr is the FeatureReferenceExpression that references f as the value Expression of the FeatureValue . If a SatisfyRequirementUsage is declared without an explicit satisfyingFeature : then the implicit BindingConnector for the checkSatisfyRequirementUsageBindingConnector constraint targets the Feature Base::things::that (see [KerML, 9.2.2]). This means that a SatisfyRequirementUsage nested in a Definition or Usage , such as Systems Modeling Language v2.0, Part 1 449 -part p { satisfy requirement sr1 : R1; } is asserted to satisfy the featuring instance of that containing Definition or Usage . part p subsets Parts::parts { satisfy requirement sr1 : R1 subsets Requirements::requirementCheck, Constraints::assertedConstraintChecks { subject subj redefines R1::subj; // The implied BindingConnector means that sr1 is effectively // satisfied by the containing Part p. bind subj = Base::things::that; } } 8.4.17.4 Concern Definitions A ConcernDefinition is a kind of RequirementDefinition . As such, all the general semantic constraints for a RequirementDefinition (see 8.4.17.1 ) also apply to a ConcernDefinition . In addition, the checkConcernDefinitionSpecialization constraint requires that a ConcernDefinition specialize the base ConcernDefinition Requirements::ConcernCheck (see 9.2.14.2.1 ), which specializes the RequirementDefinition Requirements::RequirementCheck (see 9.2.14.2.8 ). concern def Crn specializes Requirements::ConcernCheck; concern def Crn1 specializes Crn; 8.4.17.5 Concern Usages A ConcernUsage is a kind of RequirementUsage . As such, all the general semantic constraints for a RequirementUsage (see 8.4.17.2 ) also apply to a ConcernUsage , as well as the following additional specialization constraints: • checkConcernUsageSpecialization requires that a ConcernUsage specialize the base ConcernUsage Requirements::concernChecks (see 9.2.14.2.2 ), which subsets Requirements::requirementChecks (see 9.2.14.2.9 ). concern crn : Crn subsets Requirements::concernChecks; • checkConcernUsageFramedConcernSpecialization requires that a ConcernUsage that is owned by a RequirementDefinition or RequirementUsage via a FramedConcernMembership specialize the ConcernUsage Requirements::RequirementCheck::concerns (see 9.2.14.2.8 ), which subsets Requirements::concernChecks and Requirements::RequirementCheck::subrequirements . requirement def Rcrn subsets Requirements::RequirementCheck { concern crn1 : Crn1 subsets Requirements::RequirementCheck::concerns; } 8.4.18 Cases Semantics Abstract syntax reference: 8.3.22 8.4.18.1 Case Definitions A CaseDefinition is a kind of CalculationDefinition . As such, all the general semantic constraints for a CalculationDefinition (see 8.4.15.1 ) apply to a CaseDefinition . In addition, the checkCaseDefinitionSpecialization constraint requires that a CaseDefinition specialize the base CaseDefinition Cases::Case (see 9.2.15.2.1 ), which subclassifies the CalculationDefinition 450 Systems Modeling Language v2.0, Part 1 -Calculations::Calculation (see 9.2.12.2.1 ). Further, the KerML checkFeatureParameterRedefinition and checkFeatureResultRedefinition constraints (see [KerML, 8.4.4.8.1]) also apply to a CaseDefinition , as for any CalculationDefinition (see 8.4.15.1 ). case def Cs specializes Cases::Case { return ref result redefines Cases::Case::result; } case def cs1 : Cs1 specializes cs { return ref result redefines Cs1:result, cs::result; } A CaseDefinition differs from a plain CalculationDefinition in that it has a subject and an objective, and it may also have one or more actor features . • validateCaseDefinitionSubjectParameterPosition requires that the subjectParameter of a CaseDefinition be its first parameter. Thus, as a result of the KerML checkFeatureParameterRedefinition constraint (see [KerML, 8.4.4.7.1]), the subjectParameter of a CaseDefinition will always redefine the subjectParameter of any CaseDefinitions it specializes, and so will directly or indirectly redefine the base subject parameter Case::Case::subj (see 9.2.15.2.1 ). • checkRequirementUsageObjectiveRedefinition (see 8.2.2.21.2 ) effectively requires that the objectiveRequirement of a CaseDefinition redefine the objectiveRequirements of any CaseDefinitions specialized by the first CaseDefinition , which means that it will directly or indirectly redefined the RequirementUsage Cases::Case::obj . The obj feature has a default binding to the result of the Case , so, unless the default is overridden, the subjectParameter of the objectiveRequirement of a CaseDefinition should conform to the result of the CaseDefinition . • checkPartUsageActorSpecialization requires that a PartUsage that is owned by a CaseDefinition via an ActorMembership specialize the PartUsage Cases::Case::actors (see 8.4.7.2 ). case def Cs2 specializes Cases::Case { subject subj redefines Cases::Case::subj; objective obj redefines Cases::Case::obj; actor a subsets Cases::Case::actors; return result : T redefines Cases::Case::result; } Additional semantics are defined for each of the more specialized kinds of CaseDefinition (see 8.4.19.1 on AnalysisCaseDefinitions , 8.4.20.1 on VerificationCaseDefinitions , and 8.4.21.1 on UseCaseDefinitions ). 8.4.18.2 Case Usages A CaseUsage is a kind of CalculationUsage . As such, all the general semantic constraints for an CalculationUsage (see 8.4.15.2 ) apply to a CaseUsage , as well as the following additional specialization constraints: • checkCaseUsageSpecialization requires that a CaseUsage specialize the base CaseUsage Cases::cases (see 9.2.12.2.2 ), which is defined by the CaseDefinition Cases::Case (see 9.2.12.2.1 ) and subsets the CalculationUsage Calculations::calculations (see 9.2.10.2.4 ). Further, the KerML checkFeatureParameterRedefinition and checkFeatureResultRedefinition constraints (see [KerML, 8.4.4.8.1]) also apply to a CaseUsage , as for any CalculationUsage (see 8.4.15.2 ). case cs : Cs subsets Cases::cases { return result redefines Cs::result; Systems Modeling Language v2.0, Part 1 451 -} case cs1 : Cs1 subsets cs { return ref result redefines Cs1::result, cs::result; } • checkCaseUsageSubcaseSpecialization requires that a CaseUsage that is composite and has an owningType that is a CaseDefinition or CaseUsage specialize the CaseUsage Cases::Case::subcases (see 9.2.12.2.1 ), which subsets Cases::cases and the CalculationUsage Calculations::Calculation::subcalculations (see 9.2.10.2.4 ). case def Csc subsets Cases::Case { case csc1 subsets Cases::Case::subcases; ref case csc2 subsets Cases::cases, Performances::Performance::enclosedPerformances; } Similarly to a CaseDefinition , a CaseUsage also has a subject and an objective, and may have one or more actor features (see also 8.4.18.1 ). • validateCaseUsageSubjectParameterPosition requires that the subjectParameter of a CaseUsage be its first parameter. Thus, as a result of the KerML checkFeatureParameterRedefinition constraint (see [KerML, 8.4.4.7.1]), the subjectParameter of a CaseUsage will always redefine the subjectParameter of any CaseDefinition or CaseUsage it specializes, and so will directly or indirectly redefine the base subject parameter Case::Case::subj (see 9.2.15.2.1 ). • checkRequirementUsageObjectiveRedefinition (see 8.2.2.21.2 ) effectively requires that the objectiveRequirement of a CaseUsage redefine the objectiveRequirements of any CaseDefinitions or CaseUsages specialized by the first CaseUsage , which means that it will directly or indirectly redefined the RequirementUsage Cases::Case::obj . The obj feature has a default binding to the result of the Case , so, unless the default is overridden, the subjectParameter of the objectiveRequirement of a CaseUsage should conform to the result of the CaseUsage . • checkPartUsageActorSpecialization requires that a PartUsage that is owned by a CaseUsage via an ActorMembership specialize the PartUsage Cases::Case::actors (see 8.4.7.2 ). case cs2 specializes Cases::cases { subject subj redefines Cases::Case::subj; objective obj redefines Cases::Case::obj; actor a subsets Cases::Case::actors; return result redefines Cases::Case::result; } Additional semantics are defined for each of the more specialized kinds of CaseUsage (see 8.4.19.2 on AnalysisCaseUsages , 8.4.20.2 on VerificationCaseUsages , and 8.4.21.2 on UseCaseUsages ). 8.4.19 Analysis Cases Semantics Abstract syntax reference: 8.3.23 8.4.19.1 Analysis Case Definitions An AnalysisCaseDefinition is a kind of CaseDefinition . As such, all the general semantic constraints for a CaseDefinition (see 8.3.22.2 ) apply to an AnalysisCaseDefinition . In addition, the checkAnalysisCaseDefinitionSpecialization constraint requires that an AnalysisCaseDefinition specialize the base AnalysisCaseDefinition AnalysisCases::AnalysisCase (see 9.2.16.2.1 ), which subclassifies the CaseDefinition Cases::Case (see 9.2.15.2.1 ). 452 Systems Modeling Language v2.0, Part 1 -As discussed in 8.4.18.1 , the checkRequirementUsageObjectiveRedefinition constraint implies that the objectiveRequirement of any CaseDefinition directly or indirectly redefines the RequirementUsage Cases::Case::obj . The obj feature is then redefined in AnalysisCases , with its subjectParameter bound to the result of the AnalysisCase , so that the objective is about the result . This means that the objectiveRequirement for an AnalysisCaseDefinition must have a subjectParameter that is consistent with the result of the AnalysisCaseDefinition . The analysisAction property of an AnalysisCaseDefinition (see 8.3.23.2 ) collects all the composite actions of the AnalysisCaseDefinition that are directly or indirectly defined by the ActionDefinition ActivityCases::AnalysisAction . The AnalysisCaseDefinition AnalysisCases::AnalysisCase then has an analysisSteps feature that subsets Actions::Action::subaction (see 9.2.10.2.4 ) and collects the values of the analysisActions . The checkActionUsageAnalysisActionSpecialization constraint requires that any ActionUsage that is an analysisAction of an AnalysisCaseDefinition specialize AnalysisCases::AnalysisCase::analysisSteps (see 8.4.13.2 ). analysis case def AC specializes AnalysisCases::AnalysisCase { subject subj redefines AnalysisCases::AnalysisCase::subj; objective obj redefines AnalysisCases::AnalysisCase::obj { // AnalysisCases::AnalysisCase::obj::subj is bound to // AnalysisCases::AnalysisCase::result. subject subj : T redefines AnalysisCases::AnalysisCase::obj::subj; } action aa : Actions::AnalysisAction subsets AnalysisCases::AnalysisCase::analysisSteps; return result : T redefines AnalysisCases::AnalysisCase::result; } 8.4.19.2 Analysis Case Usages An AnalysisCaseUsage is a kind of CaseUsage . As such, all the general semantic constraints for a CaseUsage (see 8.4.18.2 ) apply to an AnalysisCaseUsage , as well as the following additional specialization constraints: • checkAnalysisCaseUsageSpecialization constraint requires that an AnalysisCaseUsage specialize the base AnalysisCaseUsage AnalysisCases::analysisCases (see 9.2.16.2.2 ), which is defined by the AnalysisCaseDefinition AnalysisCases::AnalysisCase (see 9.2.16.2.1 ) and subsets the CaseUsage Cases::cases (see 9.2.15.2.2 ). • checkAnalysisCaseUsageSubAnalysisCaseSpecialization requires that an AnalysisCaseUsage that is composite and has an owningType that is an AnalysisCaseDefinition or AnalysisCaseUsage specialize the AnalysisCaseUsage AnalysisCases::AnalysisCase::subAnalysisCases (see 9.2.16.2.1 ), which subsets AnalysisCases::analysisCases and the CaseUsage Cases::Case::subcases (see 9.2.15.2.1 ). As for an AnalysisCaseDefinition (see 8.4.19.1 ), the checkRequirementUsageObjectiveRedefinition constraint and the binding of AnalysisCases::AnalysisCase::obj::subj imply that the objectiveRequirement for an AnalysisCaseUsage must have a subjectParameter that is consistent with the result of the AnalysisCaseUsage . Also similarly to an AnalysisCaseDefinition , the analysisAction property of an AnalysisCaseUsage (see 8.3.23.3 ) collects all the composite actions of the AnalysisCaseUsage that are directly or indirectly defined by the ActionDefinition ActivityCases::AnalysisAction , and the checkActionUsageAnalysisActionSpecialization constraint also requires that any ActionUsage that is an analysisAction of an AnalysisCaseUsage specialize AnalysisCases::AnalysisCase::analysisSteps (see 8.4.13.2 ). analysis case ac specializes AnalysisCases::analysisCases { subject subj redefines AnalysisCases::AnalysisCase::subj; objective obj redefines AnalysisCases::AnalysisCase::obj { // AnalysisCases::AnalysisCase::obj::subj is bound to // AnalysisCases::AnalysisCase::result. Systems Modeling Language v2.0, Part 1 453 -subject subj : T redefines AnalysisCases::AnalysisCase::obj::subj; } action aa : Actions::AnalysisAction subsets AnalysisCases::AnalysisCase::analysisSteps; analysis case anl1 subsets AnalysisCases::subAnalysisCases; return result : T redefines AnalysisCases::AnalysisCase::result; } 8.4.20 Verification Cases Semantics Abstract syntax reference: 8.3.24 8.4.20.1 Verification Case Definitions A VerificationCaseDefinition is a kind of CaseDefinition . As such, all the general semantic constraints for a CaseDefinition (see 8.3.22.2 ) apply to a VerificationCaseDefinition . In addition, the checkVerificationCaseDefinitionSpecialization constraint requires that a VerificationCaseDefinition specialize the base VerificationCaseDefinition VerificationCases::VerificationCase (see 9.2.17.2.3 ), which subclassifies the CaseDefinition Cases::Case (see 9.2.15.2.1 ). As discussed in 8.4.18.1 , the checkRequirementUsageObjectiveRedefinition constraint implies that the objectiveRequirement of any CaseDefinition directly or indirectly redefines the RequirementUsage Cases::Case::obj . The obj feature is then redefined in VerificationCase , with its subj parameter bound to the subj parameter of the VerificationCase , so that the objective is about the subject of the VerificationCase . This means that the objectiveRequirement for a VerificationCaseDefinition must have a subjectParameter that is consistent with the subjectParameter of the VerificationCaseDefinition . The intent is that the objective of a VerificationCaseDefinition is to verify the satisfaction of requirements on the subject of the VerificationCaseDefinition . In addition to regular RequirementConstraintMemberships (see 8.4.17.2 ), the objectiveRequirement of a VerificationCaseDefinition can have RequirementVerificationMemberships whose ownedRequirements reference the verifiedRequirements of the VerificationCaseDefinition . The checkRequirementUsageRequirementVerificationSpecialization constraint (see 8.4.17.2 ) then requires that a RequirementUsage owned by the objective of a VerificationCaseDefinition via a RequirementVerificationMembership specialize the RequirementUsage VerificationCases::VerificationCase::obj::requirementVerifications , which subsets Requirements::RequirementCheck::subrequirements . The requirementVerifications feature thus collects checks, in the context of the objective of the VerificationCase , of the requirements to be verified, which are then required constraints on the objective of the VerificationCase (since subrequirement subsets constraints ). verification case V specializes VerificationCases::VerificationCase { subject subj : S redefines VerificationCases::VerificationCase::subj; objective obj redefines VerificationCases::VerificationCase::obj { // VerificationCases::VerificationCase::obj::subj is bound to // VerificationCases::VerificationCase::subj. subject subj : S redefines VerificationCases::VerificationCase::obj::subj; verify requirement vr subsets VerificationCases::VerificationCase::obj::requirementVerifications; } return verdict redefines VerificationCases::VerificationCase::verdict; } 454 Systems Modeling Language v2.0, Part 1 -The result of a VerificationCaseDefinition is a verdict that indicates whether a performance of a VerificationCase was pass , fail , inconclusive , or error . Commonly, the verdict will only be pass if the objective of the VerificationCase was satisfied, meaning all the necessary requirements were verified. However, this may not always be the desired condition for passing, so the criteria for passing must be modeled explicitly. 8.4.20.2 Verification Case Usages A VerificationCaseUsage is a kind of CaseUsage . As such, all the general semantic constraints for a CaseUsage (see 8.4.18.2 ) apply to a VerificationCaseUsage , as well as the following additional specialization constraints: • checkVerificationCaseUsageSpecialization constraint requires that a VerificationCaseUsage specialize the base VerificationCaseUsage VerificationCases::verificationCases (see 9.2.17.2.4 ), which is defined by the VerificationCaseDefinition VerificationCases::VerificationCase (see 9.2.17.2.3 ) and subsets the CaseUsage Cases::cases (see 9.2.15.2.2 ). • checkVerificationCaseUsageSubAnalysisCaseSpecialization requires that a VerificationCaseUsage that is composite and has an owningType that is a VerificationCaseDefinition or VerificationCaseUsage specialize the VerificationCaseUsage VerificationCases::VerificationCase::subVerificationCases (see 9.2.17.2.3 ), which subsets VerificationCases::verificationCases and the CaseUsage Cases::Case::subcases (see 9.2.15.2.1 ). As for a VerificationCaseDefinition (see 8.4.20.1 ), the checkRequirementUsageObjectiveRedefinition constraint and the binding of VerificationCases::VerificationCase::obj::subj imply that the objectiveRequirement for a VerificationCaseUsage must have a subjectParameter that is consistent with the subjectParameter of the VerificationCaseUsage . Also similarly to a VerificationCaseDefinition , the objectiveRequirement of a VerificationCaseUsage may own RequirementUsages via RequirementVerificationMemberships , to which the checkRequirementUsageRequirementVerificationSpecialization constraint applies (see 8.4.17.2 ). verification v specializes VerificationCases::VerificationCase { subject subj : S redefines VerificationCases::VerificationCase::subj; objective obj redefines VerificationCases::VerificationCase::obj { // VerificationCases::VerificationCase::obj::subj is bound to // VerificationCases::VerificationCase::subj. subject subj : S redefines VerificationCases::VerificationCase::obj::subj; verify requirement vr subsets VerificationCases::VerificationCase::obj::requirementVerifications; } verification v1 subsets VerificationCases::VerificationCase::subVerificationCases; return verdict redefines VerificationCases::VerificationCase::verdict; } As discussed for a VerificationCaseDefinition (see 8.4.20.1 ), the result of a VerificationCaseUsage is a verdict on whether a VerificationCase passes. 8.4.21 Use Cases Semantics Abstract syntax reference: 8.3.25 Systems Modeling Language v2.0, Part 1 455 -8.4.21.1 Use Case Definitions A UseCaseDefinition is a kind of CaseDefinition . As such, all the general semantic constraints for a CaseDefinition (see 8.3.22.2 ) apply to a UseCaseDefinition . In addition, the checkUseCaseDefinitionSpecialization constraint requires that a UseCaseDefinition specialize the base UseCaseDefinition UseCases::UseCase (see 9.2.18.2.1 ), which subclassifies the CaseDefinition Cases::Case (see 9.2.15.2.1 ). use case def UC specializes UseCases::UseCase { subject subj redefines Cases::Case::subj; objective obj redefines Cases::Case::obj; actor a subsets Cases::Case::actors; return result redefines Cases::Case::result; } 8.4.21.2 Use Case Usages A UseCaseUsage is a kind of CaseUsage . As such, all the general semantic constraints for a CaseUsage (see 8.4.18.2 ) apply to a UseCaseUsage , as well as the following additional specialization constraints: • checkUseCaseUsageSpecialization constraint requires that a UseCaseUsage specialize the base UseCaseUsage UseCases::useCases (see 9.2.18.2.2 ), which is defined by the UseCaseDefinition UseCases::UseCase (see 9.2.18.2.1 ) and subsets the CaseUsage Cases::cases (see 9.2.15.2.2 ). • checkUseCaseUsageSubAnalysisCaseSpecialization requires that a UseCaseUsage that is composite and has an owningType that is a UseCaseDefinition or UseCaseUsage specialize the UseCaseUsage UseCases::UseCase::subUseCases (see 9.2.18.2.1 ), which subsets UseCases::useCases and the CaseUsage Cases::Case::subcases (see 9.2.15.2.1 ). use case uc specializes UseCases::useCases { subject subj redefines UseCases::Case::subj; objective obj redefines UseCases::Case::obj; actor a subsets Cases::Case::actors; use case uc1 subsets UseCases::UseCase::subUseCases; return result redefines UseCases::UseCase::result; } 8.4.21.3 Include Use Case Usages An IncludeUseCaseUsage is a kind of UseCaseUsage and a kind of PerformActionUsage . As such, all general semantic constraints on a UseCaseUsage (see 8.4.21.2 ) and a PerformActionUsage (see 8.4.13.11 ) also apply to a IncludeUseCaseUsage . In particular, validateEventOccurrenceUsageIsReference requires an IncludeUseCaseUsage to be referential. In addition, if an IncludeUseCaseUsage has an owningType that is a UseCaseDefinition or UseCaseUsage , then the checkUseCaseUsageSpecialization constraint requires that it specialize the UseCaseUsage UseCases::UseCase::includedUseCases (see 9.2.18.2.1 ), which subsets UseCases::useCases (see 9.2.18.2.2 ) and the kernel Feature Performances::Performance::enclosedPerformances (see [KerML, 9.2.6]). For example, the following model: use case uc1; use case uc2 { include use case incl references uc1; } is, with implied Specializations included, semantically equivalent to use case uc1 subsets UseCases::useCases; use case uc2 subsets UseCases::useCases { 456 Systems Modeling Language v2.0, Part 1 -ref use case incl references uc1 subsets UseCases::UseCase::includedUseCases; } Thus, the values of uc2.incl will be the subset of the UseCases represented by uc1 that are performed within uc2 . If the IncludeUseCaseUsage has a ReferenceSubsetting , then this will suffice to satisfy the checkUseCaseUsageSpecialization constraint, if the referenced UseCaseUsage does. However, if it does not have a ReferenceSubsetting (or other relevant explicit ownedSpecialization ), it requires an implied Subsetting of UseCases::useCases . use case def UIU specializes UseCases::UseCases { include use case iu1 references uc1 subsets UseCases::UseCase::includedUseCases; include use case iu2 subsets UseCases::useCases subsets UseCases::UseCase::includedUseCases; } An ExhibitStateUsage that is an ownedFeature of an ActionDefinition or ActionUsage other than a UseCaseDefinition or UseCaseUsage has the same semantics as a PerformActionUsage in that context (see 7.17.6 , with a UseCaseUsage as its performedAction . If it is an ownedFeature of an OccurrenceDefinition or OccurrenceUsage that is not an ActionDefinition or ActionUsage , it has the same semantics as an EventOccurrenceUsage in that context (see 8.4.5.3 ). Otherwise, it has the same semantics as a referential UseCaseUsage (see 8.4.14.2 ). 8.4.22 Views and Viewpoints Semantics Abstract syntax reference: 8.3.26 8.4.22.1 View Definitions A ViewDefinition is a kind of PartDefinition . As such, all the general semantic constraints for an PartDefinition (see 8.4.7.1 ) also apply to a ViewDefinition . In addition, the checkViewDefinitionSpecialization constraint requires that a ViewDefinition specialize the base ViewDefinition Views::View (see 9.2.19.2.10 ), which subclassifies Parts::Part (see 9.2.4.2.1 ). 8.4.22.2 View Usages A ViewUsage is a kind of PartUsage . As such, all the general semantic constraints for an PartUsage (see 8.4.7.2 ) also apply to a ViewUsage , as well as the following additional specialization constraints: • checkViewUsageSpecialization requires that a ViewUsage specialize the base ViewUsage Views::views (see 9.2.19.2.14 ). • checkViewUsageSubviewSpecialization requires that a ViewUsage that is composite and has an owningType that is a ViewDefinition or ViewUsage specialize the ViewUsage Views::View::subviews (see 9.2.19.2.10 ), which subsets Views::views . view def V specializes Views::View { ref view v1 subsets Views::views; view v2 subsets Views::View::subviews; } 8.4.22.3 Viewpoint Definitions A ViewpointDefinition is a kind of RequirementDefinition . As such, all the general semantic constraints for a RequirementDefinition (see 8.4.17.1 ) also apply to a ViewpointDefinition . In addition, the Systems Modeling Language v2.0, Part 1 457 -checkViewpointDefinitionSpecialization constraint requires that a ViewpointDefinition specialize the base ViewpointDefinition Views::ViewpointCheck (see 9.2.19.2.11 ), which specializes the RequirementDefinition Requirements::RequirementCheck (see 9.2.14.2.8 ). viewpoint def Vp specializes Viewpoints::ViewpointCheck; viewpoint def Vp1 specializes Vp; 8.4.22.4 Viewpoint Usages A ViewpointUsage is a kind of RequirementUsage . As such, all the general semantic constraints for a RequirementUsage (see 8.4.17.2 ) also apply to a ViewpointUsage , as well as the following additional specialization constraints: • checkViewpointUsageSpecialization requires that a ViewpointUsage specialize the base ViewpointUsage Views::viewpointChecks (see 9.2.19.2.12 ), which subsets Requirements::requirementChecks (see 9.2.14.2.9 ). viewpoint vp : Vp subsets Views::viewpointChecks; • checkViewpointUsageViewpointSatisfactionSpecialization requires that a composite ViewpointUsage whose owningType is a ViewDefinition or ViewUsage specialize the ViewpointUsage Views::View::viewpointSatisfactions (see 9.2.19.2.10 ), which subsets Views::viewpointChecks . Since the Views::View model asserts the satisfaction of the viewpointSatisfactions , this means that any composite ViewpointUsage that is an ownedFeature of a ViewDefinition or ViewpointUsage is implicitly asserted to be satisfied by the specified View . view def Vw subsets Views::View { // The following ViewpointUsage is implicitly asserted to be // satisfied by the Views defined by Vw. viewpoint vp1 : Vp1 subsets Views::View::viewpointSatisfactions; } 8.4.22.5 Rendering Definitions A RenderingDefinition is a kind of PartDefinition . As such, all the general semantic constraints for a PartDefinition (see 8.4.7.1 ) also apply to a RenderingDefinition . In addition, the checkRenderingDefinitionSpecialization constraint requires that a RenderingDefinition specialize the base RenderingDefinition Views::Rendering (see 9.2.19.2.6 ), which subclassifies Parts::Part (see 9.2.4.2.1 ). 8.4.22.6 Rendering Usages A RenderingUsage is a kind of PartUsage . As such, all the general semantic constraints for an PartUsage (see 8.4.7.2 ) also apply to a RenderingUsage , as well as the following additional specialization constraints: • checkRenderingUsageSpecialization requires that a RenderingUsage specialize the base RenderingUsage Views::rendering (see 9.2.19.2.7 ). • checkRenderingUsageSubrenderingSpecialization requires that a RenderingUsage that is composite and has an owningType that is a RenderingDefinition or RenderingUsage specialize the RenderingUsage Views::Rendering::subrenderings (see 9.2.19.2.6 ), which subsets Renderings::renderings . rendering def Rnd specializes Renderings::Rendering { ref rendering rnd1 subsets Renderings::renderings; view rnd2 subsets Renderings::Rendering::subrenderings; } 458 Systems Modeling Language v2.0, Part 1 -• checkRenderingUsageRedefinition requires that a RenderingUsage that is owned by a ViewDefinition or ViewUsage via a ViewRenderingMembership redefines the viewRendering of each ViewDefinition or ViewUsage that is specialized by the owning ViewDefinition or ViewUsage . This means that the viewRendering of a ViewDefinition or ViewUsage will always directly or indirectly redefined the RenderingUsage Views::View::viewRendering (see 9.2.19.2.10 ). rendering r1; rendering r2; view def VR specializes Views::View { render r1 redefines Views::View::viewRendering; } view def vr : VR { render r2 redefines VR::r1; } 8.4.23 Metadata Semantics Abstract syntax reference: 8.3.27 8.4.23.1 Metadata Definitions A MetadataDefinition is a kind of ItemDefinition and a kind of KerML Metaclass . As such, the general semantic constraints for an ItemDefinition (see 8.4.6.1 ) and a Metaclass (see [KerML, 8.4.4.13]) also apply to a MetadataDefinition . In addition, the checkMetadataDefinitionSpecialization constraint requires that a MetadataDefinition specialize the base MetadataDefinition Metadata::MetadataItem (see 9.2.21.2.1 ), which subclassifies Items::Item (see 9.2.3.2.1 ) and the kernel Metaclass Metaobjects::Metaobject (see [KerML, 9.2.16]). The instances of a MetadataDefinition are MetadataItems that are part of the structure of a model itself, rather than being an instance in the system represented by the model. The SysML library model is a reflective model of the MOF abstract syntax for SysML, containing one SysML MetadataDefinition corresponding to each MOF metaclass in the abstract syntax model (see 9.2.22 for more details on the relationship between the SysML model and the abstract syntax). 8.4.23.2 Metadata Usages A MetadataUsage is a kind of ItemUsage and a kind of KerML MetadataFeature . As such, the general semantic constraints for an ItemUsage (see 8.4.6.2 ) and a MetadataFeature (see [KerML, 8.4.4.13]) also apply to a MetadataUsage . In addition, the checkMetadataUsageSpecialization constraint requires that a MetadataUsage specialize the base MetadataUsage Metadata::metadataItems (see 9.2.21.2.2 ), which is defined by Metadata::MetadataItem (see 9.2.21.2.1 ) and subsets Items::items (see 9.2.3.2.2 ) and the kernel Feature Metaobjects::metaobjects (see [KerML, 9.2.16]). See [KerML, 8.4.4.13.2] for further description of the model-level semantics of MetadataUsages as MetadataFeatures that can be used to annotate Elements of a model. See also [KerML, 8.4.4.13.3] for a discussion of semantic metadata that is also usable in SysML. Systems Modeling Language v2.0, Part 1 459 -460 Systems Modeling Language v2.0, Part 1 -9Model Libraries 9.1 Model Libraries Overview The SysML model libraries are an integral part of the language. The Systems Model Library (see 9.2 ) is used any time a Definition or Usage element is instantiated in a user model, providing a bridge to the semantic models in the Kernel Model Library [KerML, Clause 8]. For example, any ItemDefinition or ItemUsage must directly or indirectly specialize the base ItemDefinition Item from the Items library model, where Item specializes the Kernel Class Object , giving Items the semantics of structural Objects. SysML also includes a set of domain libraries, which provide models of fundamental concepts from domains of particular importance in systems engineering. These models are normative and available for use in all SysML user models. The following domain libraries are included. • The Metadata Domain Library contains models of attribute definitions for a useful set of standard metadata annotations (see 9.3 ; see also 7.4 on Annotations). • The Analysis Domain Library contains models of concepts useful in carrying out analyses of systems. In particular, it includes frameworks for state space representation of systems and for performing trade-off studies (see 9.4 ). • The Cause and Effect Domain Library contains a language extension for modeling cause and effect relationships (see 9.5 ). • The Requirement Derivation Domain Library contains a language extension for modeling requirement derivation relationships (see 9.6 ). • The Geometry Domain Library contains a model for physical items with spacial extent, including an extensive set of basic geometric shapes that can be used to construct such items (see 9.7 ). • The Quantities and Units Domain Library contains a comprehensive set of models for scalar, vector and tensor quantities, including quantity value and unit definitions covering the ISO/IEC 80000 and ISO 8601-1 standards (see 9.8 ). The normative machine-readable representation for each of these model libraries is a project interchange file, formatted consistent with the standard for model interchange given in [KerML, 10.3], as specified for SysML in Clause 2 under Model Interchange Conformance. The documentation on these models provided here in Clause 9 is either derived from the model files themselves or gives additional overview information on the use of the models, and is therefore also considered normative. Each library model is packaged as a model interchange file in the project interchange file for its corresponding model library (see [KerML, 10.2]). Regardless of whether such a library model is interchanged in textual notation, XMI or JSON format, the elementId for any Element in the library model shall be a name-based (version 5) UUID (see [UUID, 14.2]), constructed as specified in [KerML, 9.1], except using the prefix https://www.omg.org/spec/SysML/ when constructing the URL for a standard library package. The elementIds constructed in this way shall be normative across all forms of interchange of the library models. For Elements with non-null qualifiedNames , in particular, the elementIds shall remain stable for future versions of the library models, though future revisions of this specification may deprecate certain existing Elements and their names, or introduce new Elements with new names and hence UUIDS that are distinct (with a high probability). 9.2 Systems Model Library 9.2.1 Systems Model Library Overview The Systems Model Library includes models for the base types of all kinds of Definition and Usage elements in SysML. Each of the following subclauses describes a library model package corresponding to the elements in the similarly named abstract syntax package (see 8.3 ). For example, the Attributes library model package (see Systems Modeling Language v2.0, Part 1 461 -9.2.2 ) includes the Attribute and attributes types that are the base types for all AttributeDefinitions and AttributeUsages (respectively) as specified in the Attributes abstract syntax package (see 8.3.7 ). It also includes a package of StandardViewDefinitions (see 9.2.20 ) and a reflective SysML model of the SysML abstract syntax (see 9.2.22 ). 9.2.2 Attributes 9.2.2.1 Attributes Overview This package defines the base types for attributes and related structural elements in the SysML language. 9.2.2.2 Elements 9.2.2.2.1 AttributeValue Element AttributeDefinition Description AttributeValue is the most general type of data values that represent qualities or characteristics of a system or part of a system. AttributeValue is the base type of all AttributeDefinitions . General Types DataValue Features None. Constraints None. 9.2.2.2.2 attributeValues Element AttributeUsage Description attributeValues is the base feature for all AttributeUsages . General Types dataValues AttributeValue Features None. 462 Systems Modeling Language v2.0, Part 1 -Constraints None. 9.2.3 Items 9.2.3.1 Items Overview This package defines the base types for items and related structural elements in the SysML language. 9.2.3.2 Elements 9.2.3.2.1 Item Element ItemDefinition Description Item is the most general class of objects that are part of, exist in or flow through a system. Item is the base type of all ItemDefinitions . General Types Object Features boundingShapes : Item [0..*] {subsets envelopingShapes} envelopingShapes that are StructuredSpaceObjects with every face or every edge intersecting this Item . checkedConstraints : ConstraintCheck [0..*] {subsets ownedPerformances} Constraints that have been checked by this Item . envelopingShapes : Item [0..*] Shapes that are the shape of an Item that includes this Item in space and time. isSolid : Boolean An Item is solid if it has no voids . shape : Item {redefines spaceBoundary} Spatial boundary of this Item . subitems : Item [0..*] {subsets suboccurrences} The Items that are composite subitems of this Item . subparts : Part [0..*] {subsets subitems} The subitems of this item that are parts . Systems Modeling Language v2.0, Part 1 463 -voids : Item [0..*] {redefines innerSpaceOccurrences} voids are the innerSpaceOccurrences of Item Item. Constraints None. 9.2.3.2.2 items Element ItemUsage Description items is the base feature of all ItemUsages . General Types Item objects Features None. Constraints None. 9.2.3.2.3 Touches Element ConnectionDefinition Description Touching Occurrences are JustOutsideOf each other and happen at the same time ( HappensWhile ). General Types JustOutsideOf HappensWhile Features touchedItem : Item {redefines separateSpace, thatOccurrence} touchedItemToo : Item {redefines thisOccurrence, separateSpaceToo} touches : Item [0..*] {subsets justOutsideOfOccurrences, happensWhile} 464 Systems Modeling Language v2.0, Part 1 -touchesToo : Item [0..*] {subsets timeCoincidentOccurrences, justOutsideOfOccurrences} Owned cross feature of touchedItemToo . Constraints None. 9.2.4 Parts 9.2.4.1 Parts Overview This package defines the base types for parts and related structural elements in the SysML language. 9.2.4.2 Elements 9.2.4.2.1 Part Element PartDefinition Description Part is the most general class of objects that represent all or a part of a system. Part is the base type of all PartDefinitions . General Types Item Features exhibitedStates : StateAction [0..*] {subsets performedActions} StateActions that are exhibited by this Part . ownedActions : Action [0..*] {subsets ownedPerformances} Actions that are owned by this Part . The this reference of a ownedAction is always its owning Part . ownedPorts : Port [0..*] {subsets timeEnclosedOccurrences} Ports that are owned by this Part . ownedStates : StateAction [0..*] {subsets ownedActions} StateActions that are owned by this Part . performedActions : Action [0..*] {subsets enactedPerformances} Actions that are performed by this Part . Constraints None. Systems Modeling Language v2.0, Part 1 465 -9.2.4.2.2 parts Element PartUsage Description parts is the base feature of all PartUsages . General Types Part items Features None. Constraints None. 9.2.5 Ports 9.2.5.1 Ports Overview This package defines the base types for ports and related structural elements in the SysML language. 9.2.5.2 Elements 9.2.5.2.1 Port Element PortDefinition Description Port is the most general class of objects that represent connection points for interacting with a Part . Port is the base type of all PortDefinitions . General Types Object Features subports : Port [0..*] {subsets timeEnclosedOccurrences} Constraints None. 466 Systems Modeling Language v2.0, Part 1 -9.2.5.2.2 ports Element PortUsage Description ports is the base feature of all PortUsages . General Types objects Port Features None. Constraints None. 9.2.6 Connections 9.2.6.1 Connections Overview This package defines the base types for connections and related structural elements in the SysML language. 9.2.6.2 Elements 9.2.6.2.1 BinaryConnection Element ConnectionDefinition Description BinaryConnection is the most general class of binary links between two things within some containing structure. BinaryConnection is the base type of all ConnectionDefinitions with exactly two ends. General Types Connection BinaryLinkObject Features source : Anything {redefines source} target : Anything {redefines target} Constraints Systems Modeling Language v2.0, Part 1 467 -None. 9.2.6.2.2 binaryConnections Element ConnectionUsage Description binaryConnections is the base feature of all binary ConnectionUsages. General Types BinaryConnection binaryLinkObjects connections Features None. Constraints None. 9.2.6.2.3 Connection Element ConnectionDefinition Description Connection is the most general class of links between things within some containing structure. Connection is the base type of all ConnectionDefinitions . General Types Part LinkObject Features None. Constraints None. 9.2.6.2.4 connections Element 468 Systems Modeling Language v2.0, Part 1 -ConnectionUsage Description connections is the base feature of all ConnectionUsages . General Types linkObjects parts Features None. Constraints None. 9.2.7 Interfaces 9.2.7.1 Interfaces Overview This package defines the base types for interfaces and related structural elements in the SysML language. 9.2.7.2 Elements 9.2.7.2.1 BinaryInterface Element InterfaceDefinition Description BinaryInterface is the most general class of links between two PortUsages within some containing structure. BinaryInterface is the base Type of all InterfaceDefinitions with exactly two ends. General Types BinaryConnection Interface Features source : Port [0..*] {redefines source} target : Port {redefines target} Constraints None. Systems Modeling Language v2.0, Part 1 469 -9.2.7.2.2 binaryInterfaces Element InterfaceUsage Description binaryInterfaces is the base feature of all binary InterfaceUsages . General Types interfaces BinaryInterface binaryConnections Features None. Constraints None. 9.2.7.2.3 Interface Element InterfaceDefinition Description Interface is the most general class of links between PortUsages within some containing structure. Interface is the base type of all InterfaceDefinitions . General Types Connection Features None. Constraints None. 9.2.7.2.4 interfaces Element InterfaceUsage Description 470 Systems Modeling Language v2.0, Part 1 -interfaces is the base feature of all InterfaceUsages . General Types Interface connections Features None. Constraints None. 9.2.8 Allocations 9.2.8.1 Allocations Overview This package defines the base types for allocations and related structural elements in the SysML language. 9.2.8.2 Elements 9.2.8.2.1 Allocation Element AllocationDefinition Description Allocation is the most general class of allocations, represented as a connection between the source of the allocation and the target. Allocation is the base type of all AllocationDefinitions . General Types BinaryConnection Features source : Anything {redefines source} target : Anything {redefines target} Constraints None. 9.2.8.2.2 allocations Element AllocationUsage Description Systems Modeling Language v2.0, Part 1 471 -allocations is the base feature of all ConnectionUsages . General Types Allocation binaryConnections Features None. Constraints None. 9.2.9 Flows 9.2.9.1 Flows Overview This package defines the base types for flows and related behavioral elements in the SysML language. 9.2.9.2 Elements 9.2.9.2.1 Flow Element FlowDefinition Description Flow is a subclass of messages that are also flow transfers. It is the base type for FlowUsages that identify their source output and target input. General Types FlowTransfer Message Features source : Occurrence {redefines source, source} target : Occurrence {redefines target, target} Constraints None. 9.2.9.2.2 flows Element FlowUsage 472 Systems Modeling Language v2.0, Part 1 -Description flows is the base feature of all FlowUsages that identify their source output and target input. General Types messages flowTransfers Flow Features source : Occurrence {redefines source, source, source} target : Occurrence {redefines target, target, target} Constraints None. 9.2.9.2.3 Message Element FlowUsage Description Message is the subclass of message actions that represent a transfer of objects or values between two occurrences. It is the base type of FlowUsages . General Types MessageAction Transfer Features payload : Anything [1..*] {redefines payload, payload} A payload that may be transferred during the interaction. source : Occurrence {redefines source} sourceEvent : Occurrence An occurrence happening during the source of this flow message that is either the start of the message or happens before it. (in parameter) target : Occurrence {redefines target} targetEvent : Occurrence Systems Modeling Language v2.0, Part 1 473 -An occurrence happening during the target of this message that is either the end of the message or happens after it. (in parameter) Constraints None. 9.2.9.2.4 MessageAction Element FlowDefinition Description MessageAction is the most general class of actions that represent interactions between linked things. It is the base type of all FlowDefinitions . General Types Action Link Features payload : Anything [0..*] A payload that may be transferred during the interaction. Constraints None. 9.2.9.2.5 messages Element FlowUsage Description messages is the base feature of all FlowUsages . General Types Message transfers actions Features source : Occurrence {redefines source, source} 474 Systems Modeling Language v2.0, Part 1 -target : Occurrence {redefines target, target} Constraints None. 9.2.9.2.6 SuccessionFlow Element FlowDefinition Description p> SuccessionFlow is a subclass of flows that happen after their source and before their target . It is the base type for all SuccessionFlowUsages . General Types FlowTransferBefore Flow Features source : Occurrence {redefines source, source} target : Occurrence {redefines target, target} Constraints None. 9.2.9.2.7 successionFlows Element FlowUsage Description successionFlows is the base feature of all SuccessionFlowUsages . General Types flows SuccessionFlow transfersBefore Features source : Occurrence {redefines source, source, source} target : Occurrence {redefines target, target, target} Systems Modeling Language v2.0, Part 1 475 -Constraints None. 9.2.10 Actions 9.2.10.1 Actions Overview This package defines the base types for actions and related behavioral elements in the SysML language. 9.2.10.2 Elements 9.2.10.2.1 AcceptAction Element ActionDefinition Description An AcceptAction is a AcceptMessageAction that waits for a payload or acceptedMessage of the specified kind to be accepted by a state transition nested in it. General Types AcceptMessageAction Features None. Constraints None. 9.2.10.2.2 acceptActions Element ActionUsage Description acceptActions is the base feature for all SendActionUsages . General Types AcceptAction actions Features None. Constraints 476 Systems Modeling Language v2.0, Part 1 -None. 9.2.10.2.3 AcceptMessageAction Element ActionDefinition Description An AcceptMessageAction is an Action and AcceptPerformance that identifies an incomingTransferToSelf of a designated receiver Occurrence , providing its payload as output. General Types Action AcceptPerformance Features acceptedMessage : MessageTransfer, MessageAction {redefines acceptedTransfer} payload : Anything [1..*] {redefines payload} The payload received from the incoming Transfer . If an input value is provided for this parameter, then the Transfer payload must match that value. Constraints None. 9.2.10.2.4 Action Element ActionDefinition Description Action is the most general class of performances of ActionDefinitions in a system or part of a system. Action is the base class of all ActionDefinitions . General Types Performance Features acceptSubactions : AcceptAction [0..*] {subsets subactions, acceptActions} The subactions of this Action that are AcceptActions . assignments : AssignmentAction [0..*] {subsets subactions} The subactions of this Action that are AssignmentActions . Systems Modeling Language v2.0, Part 1 477 -controls : ControlAction [0..*] {subsets subactions} The subactions of this Action that are ControlActions . decisions : DecisionAction [0..*] {subsets controls} The controls of this Action that are DecisionActions . decisionTransitions : DecisionTransitionAction [0..*] {subsets transitions} The subactions of this Action that are DecisionTransitionActions done : Action {redefines endShot} The ending snapshot of this Action . forks : ForkAction [0..*] {subsets controls} The controls of this Action that are ForkActions . forLoops : ForLoopAction [0..*] {subsets loops} The loops of this Action that are ForLoopActions . ifSubactions : IfThenAction [0..*] {subsets subactions} The subactions of this Action that are IfThenActions (including IfThenElseActions ). joins : JoinAction [0..*] {subsets controls} The controls of this Action that are JoinActions . loops : LoopAction [0..*] {subsets subactions} The subactions of this Action that are LoopActions . merges : MergeAction [0..*] {subsets controls} The controls of this Action that are MergeActions . sendSubactions : SendAction [0..*] {subsets subactions, sendActions} The subactions of this Action that are SendActions . start : Action {redefines startShot} The starting snapshot of this Action . subactions : Action [0..*] {subsets enclosedPerformances} The subperformances of this Action that are Actions . The this reference of a subaction is always the same as that of its owning Action . terminateSubactions : TerminateAction [0..*] {subsets subactions, terminateActions} The subactions of this Action that are TerminateActions . 478 Systems Modeling Language v2.0, Part 1 -transitions : TransitionAction [0..*] {subsets subactions} The subactions of this Action that are TransitionActions. whileLoops : WhileLoopAction [0..*] {subsets loops} The loops of this Action that are WhileLoopActions . Constraints None. 9.2.10.2.5 actions Element ActionUsage Description actions is the base feature for all ActionUsages . General Types Action performances Features None. Constraints None. 9.2.10.2.6 AssignmentAction Element ActionDefinition Description An AssignmentAction is an Action used to type an AssignmentActionUsage . It is also a FeatureWritePerformance that updates the accessedFeature of its target Occurrence with the given replacementValues . General Types FeatureWritePerformance Action Features Systems Modeling Language v2.0, Part 1 479 -replacementValues : Anything [0..*] {redefines replacementValues} The values to be assigned to the accessedFeature of the target . target : Occurrence {redefines onOccurrence} The target Occurrence whose accessedFeature is being assigned. Constraints None. 9.2.10.2.7 assignmentActions Element ActionUsage Description assignmentActions is the base feature for all AssignmentActionUsages . General Types AssignmentAction actions Features target : Occurrence {redefines target} The default target for assignmentActions is the featuring instance (if that is an Occurrence Constraints None. 9.2.10.2.8 ControlAction Element ActionDefinition Description A ControlAction is the Action of a ControlNode , which has no inherent behavior. General Types Action Features None. 480 Systems Modeling Language v2.0, Part 1 -Constraints None. 9.2.10.2.9 DecisionAction Element ActionDefinition Description A DecisionAction is the ControlAction for a DecisionNode . It is a DecisionPerformance that selects one outgoing HappensBeforeLink . General Types DecisionPerformance ControlAction Features None. Constraints None. 9.2.10.2.10 DecisionTransitionAction Element ActionDefinition Description A DecisionTransitionAction is a TransitionAction and NonStateTransitionPerformance that has a single guard , but no trigger or effects . It is the base type of TransitionUsages used as conditional successions in action models. General Types NonStateTransitionPerformance TransitionAction Features accepter : AcceptMessageAction [0] {redefines accepter} effect : Action [0] {redefines effect} Constraints None. Systems Modeling Language v2.0, Part 1 481 -9.2.10.2.11 ForkAction Element ActionDefinition Description A ForkAction is the ControlAction for a ForkNode . Note: Fork behavior results from requiring that the target multiplicity of all outgoing succession connectors be 1..1. General Types ControlAction Features None. Constraints None. 9.2.10.2.12 ForLoopAction Element ActionDefinition Description A ForLoopAction is a LoopAction that iterates over an ordered sequence of values. It is the base type for all ForLoopActionUsages . General Types LoopAction Features body : Action [0..*] {redefines body} The Action that is performed on each iteration of the loop. index : Positive The index of the element of seq assigned to var on the current iteration of the loop. initialization : AssignmentAction Initializes index to 1. seq : Anything [0..*] {ordered, nonunique} The sequence of values over which the loop iterates. 482 Systems Modeling Language v2.0, Part 1 -var : Anything The loop variable that is assigned successive elements of seq on each iteration of the loop. whileLoop : WhileLoopAction While index is less than or equal to the size of seq , assigns var to the index element of seq , then performs body and increments index . Constraints None. 9.2.10.2.13 forLoopActions Element ActionUsage Description forLoopActions is the base feature for all ForLoopActionUsages . General Types loopActions ForLoopAction Features None. Constraints None. 9.2.10.2.14 IfThenAction Element ActionDefinition Description An IfThenAction is a Kernel IfThenPerformance that is also an Action . It is the base type for all IfActionUsages . General Types Action IfThenPerformance Features Systems Modeling Language v2.0, Part 1 483 -ifTest : BooleanEvaluation {redefines ifTest} An evaluation of a Boolean -valued Expression whose result determines whether or not the thenClause is performed. thenClause : Performance [0..1] {redefines thenClause} An optional Performance that occurs if and only if the result of the ifTest is true. Constraints None. 9.2.10.2.15 ifThenActions Element ActionUsage Description ifThenActions is the base feature for all IfActionUsages . General Types IfThenAction actions Features None. Constraints None. 9.2.10.2.16 IfThenElseAction Element ActionDefinition Description An IfThenElseAction is a Kernel IfThenElsePeformance that is also an IfThenAction . It is the base type for all IfActionUsages that have an elseAction . General Types IfThenAction IfThenElsePerformance Features 484 Systems Modeling Language v2.0, Part 1 -elseClause : Performance [0..1] {redefines elseClause} An optional Performance that occurs if and only if the result of the ifTest is false. Constraints None. 9.2.10.2.17 ifThenElseActions Element ActionUsage Description ifThenElseActions is the base feature for all IfActionUsages that have an elseAction . General Types IfThenElseAction ifThenActions Features None. Constraints None. 9.2.10.2.18 JoinAction Element ActionDefinition Description A JoinAction is the ControlAction for a JoinNode . Note: Join behavior results from requiring that the source multiplicity of all incoming succession connectors be 1..1. General Types ControlAction Features None. Constraints None. Systems Modeling Language v2.0, Part 1 485 -9.2.10.2.19 LoopAction Element ActionDefinition Description A LoopAction is the base type for all LoopActionUsages . General Types Action Features body : Action [0..*] The Action that is performed repeatedly in the loop. Constraints None. 9.2.10.2.20 loopActions Element ActionUsage Description loopActions is the base feature for all LoopActionUsages . General Types LoopAction actions Features None. Constraints None. 9.2.10.2.21 MergeAction Element ActionDefinition Description 486 Systems Modeling Language v2.0, Part 1 -A MergeAction is the ControlAction for a MergeNode . It is a MergePerformance that selects exactly one incoming HappensBefore link. General Types MergePerformance ControlAction Features None. Constraints None. 9.2.10.2.22 SendAction Element ActionDefinition Description A SendAction is an Action and SendPerformance used to type a SendActionUsages . It initiates an outgoingTransferFromSelf from a designated sender Occurrence with a given payload , optionally to a designated receiver Occurrence . General Types Action SendPerformance Features payload : Anything [1..*] {redefines payload} The payload to be sent in the outgoing Transfer . sentMessage : MessageTransfer, MessageAction {redefines sentTransfer} Constraints None. 9.2.10.2.23 sendActions Element ActionUsage Description sendActions is the base feature for all SendActionUsages . Systems Modeling Language v2.0, Part 1 487 -General Types SendAction actions Features None. Constraints None. 9.2.10.2.24 TerminateAction Element ActionDefinition Description A TerminateAction is an Action that terminates a given Occurrence , meaning that the Occurrence ends during the performance of this Action . TerminateAction is the base type for all TerminateActionUsages . General Types Action Features terminatedOccurrence : Occurrence The Occurrence to be terminated. ( in parameter) Constraints None. 9.2.10.2.25 terminateActions Element ActionUsage Description terminateActions is the base feature for all TerminateActionUsages . General Types TerminateAction actions Features 488 Systems Modeling Language v2.0, Part 1 -terminatedOccurrence : Occurrence {redefines terminatedOccurrence} The default terminatedOccurrence for a terminateAction is its featuring occurrence (which will generally be a containing Action ). Constraints None. 9.2.10.2.26 TransitionAction Element ActionDefinition Description A TransitionAction is a TransitionPerformance with an Action as transitionLinkSource . It is the base type of all TransitionUsages . General Types Action TransitionPerformance Features acceptedMessage : MessageTransfer, MessageAction {redefines trigger} accepter : AcceptMessageAction [0..1] {subsets subactions, redefines accept} effect : Action [0..*] {subsets subactions, redefines effect} receiver : Occurrence {redefines triggerTarget} transitionLinkSource : Action {redefines transitionLinkSource} Constraints None. 9.2.10.2.27 transitionActions Element TransitionUsage Description transitionActions is the base feature for all TransitionUsages . General Types Action Systems Modeling Language v2.0, Part 1 489 -TransitionAction actions Features None. Constraints None. 9.2.10.2.28 WhileLoopAction Element ActionDefinition Description A WhileLoopAction is a Kernel LoopPerformance that is also a LoopAction . It is the base type for all WhileLoopActionUsages . General Types LoopAction LoopPerformance Features body : Action [0..*] {redefines body, body} The Action that is performed while the whileTest is true and the untilTest is false. untilTest : BooleanEvaluation [0..*] {redefines untilTest} Successive evaluations of a Boolean -valued Expression that must be false for the loop to continue. The Expression is evaluated after the body is performed. whileTest : BooleanEvaluation [1..*] {redefines whileTest} Successive evaluations of a Boolean -valued Expression that must be true for the loop to continue. the Expression is evaluated before the body is performed and is always evaluated at least once. Constraints None. 9.2.10.2.29 whileLoopActions Element ActionUsage Description 490 Systems Modeling Language v2.0, Part 1 -whileLoopActions is the base feature for all WhileLoopActionUsages . General Types WhileLoopAction loopActions Features None. Constraints None. 9.2.11 States 9.2.11.1 States Overview This package defines the base types for states and related behavioral elements in the SysML language. 9.2.11.2 Elements 9.2.11.2.1 StateAction Element StateDefinition Description A StateAction is a kind of Action that is also a StatePerformance . It is the base type for all StateDefinitions . General Types Action StatePerformance Features doAction : Action {redefines do} entryAction : Action {redefines entry} exclusiveStates : StateAction [0..*] {subsets substates} The substates of this StateAction that are mutually exclusive, that is, whose performances do not overlap in time. exitAction : Action {redefines exit} stateTransitions : StateTransitionAction [0..*] {subsets transitions} subactions : Action [0..*] {subsets middle, redefines subactions} Systems Modeling Language v2.0, Part 1 491 -The subperformances of this StateAction that are Actions , other than the entry and exit Actions . These subactions all take place in the "middle" of the StatePerformance , that is, after the entry Action and before the exit Action . substates : StateAction [0..*] {subsets subactions} The subactions of this StateAction that are StateActions . NOTE: This feature is declared as an ActionUsage , not a StateUsage , so that the constraint checkStateUsageExclusiveStateSpecialization does not apply to it, since this constraint would otherwise incorrectly require that substates subset exclusiveStates . Constraints None. 9.2.11.2.2 stateActions Element StateUsage Description stateActions is the base feature for all StateUsages . General Types StateAction actions Features None. Constraints None. 9.2.11.2.3 StateTransitionAction Element ActionDefinition Description A StateTransitionAction is a TransitionAction and a StateTransitionPerformance whose transitionLinkSource is a StateAction . It is the base type of TransitionUsages used as transitions in state models. General Types TransitionAction 492 Systems Modeling Language v2.0, Part 1 -StateTransitionPerformance Features payload : Anything [0..*] receiver : Occurrence {redefines receiver} transitionLinkSource : StateAction {redefines transitionLinkSource, transitionLinkSource} Constraints None. 9.2.12 Calculations 9.2.12.1 Calculations Overview This package defines the base types for calculations and related behavioral elements in the SysML language. 9.2.12.2 Elements 9.2.12.2.1 Calculation Element CalculationDefinition Description Calculation is the most general class of evaluations of CalculationDefinitions in a system or part of a system. Calculation is the base class of all CalculationDefinitions . General Types Evaluation Action Features subcalculations : Calculation [0..*] {subsets subactions} The subcalculations of this Calculations that are Calculations Constraints None. 9.2.12.2.2 calculations Element CalculationUsage Description Systems Modeling Language v2.0, Part 1 493 -calculations is the base Feature for all CalculationUsages . General Types evaluations Calculation actions Features None. Constraints None. 9.2.13 Constraints 9.2.13.1 Constraints Overview This package defines the base types for constraints and related behavioral elements in the SysML language. 9.2.13.2 Elements 9.2.13.2.1 assertedConstraintChecks Element ConstraintUsage Description assertedConstraintChecks is the subset of constraintChecks for ConstraintChecks asserted to be true. General Types constraintChecks trueEvaluations Features None. Constraints None. 9.2.13.2.2 ConstraintCheck Element ConstraintDefinition Description 494 Systems Modeling Language v2.0, Part 1 -ConstraintCheck is the most general class for constraint checking. ConstraintCheck is the base type of all ConstraintDefinitions . General Types BooleanEvaluation Features None. Constraints None. 9.2.13.2.3 constraintChecks Element ConstraintUsage Description constraintChecks is the base feature of all ConstraintUsages . General Types booleanEvaluations ConstraintCheck Features None. Constraints None. 9.2.13.2.4 negatedConstraintChecks Element ConstraintUsage Description negatedConstraintChecks is the subset of constraintChecks for ConstraintChecks asserted to be false. General Types falseEvaluations constraintChecks Features Systems Modeling Language v2.0, Part 1 495 -None. Constraints None. 9.2.14 Requirements 9.2.14.1 Requirements Overview This package defines the base types for requirements and related behavioral elements in the SysML language. 9.2.14.2 Elements 9.2.14.2.1 ConcernCheck Element ConcernDefinition Description ConcernCheck is the most general class for concern checking. ConcernCheck is the base type of all ConcernDefinitions . General Types RequirementCheck Features None. Constraints None. 9.2.14.2.2 concernChecks Element ConcernUsage Description concernChecks is the base feature of all ConcernUsages . General Types ConcernCheck requirementChecks Features None. 496 Systems Modeling Language v2.0, Part 1 -Constraints None. 9.2.14.2.3 DesignConstraintCheck Element ConstraintDefinition Description A DesignConstraintCheck specifies a constraint on the implementation of the system or system part, such as the system must use a commercial-off-the-shelf component. General Types RequirementCheck Features part : Part {redefines subj} Constraints None. 9.2.14.2.4 FunctionalRequirementCheck Element ConstraintDefinition Description A FunctionalRequirementCheck specifies an action that a system, or part of a system, must perform. General Types RequirementCheck Features subject : Action {redefines subj} Constraints None. 9.2.14.2.5 InterfaceRequirementCheck Element ConstraintDefinition Description Systems Modeling Language v2.0, Part 1 497 -An InterfaceRequirementCheck specifies an Interface for connecting systems and system parts, which optionally may include item flows across the Interface and/or Interface constraints. General Types RequirementCheck Features subject : BinaryInterface {redefines subj} Constraints None. 9.2.14.2.6 PerformanceRequirementCheck Element ConstraintDefinition Description A PerformanceRequirementCheck quantitatively measures the extent to which a system, or a system part, satisfies a required capability or condition. General Types RequirementCheck Features subject : AttributeValue {redefines subj} Constraints None. 9.2.14.2.7 PhysicalRequirementCheck Element ConstraintDefinition Description A PhysicalRequirementCheck specifies physical characteristics and/or physical constraints of the system, or a system part. General Types RequirementCheck Features subject : Part {redefines subj} 498 Systems Modeling Language v2.0, Part 1 -Constraints None. 9.2.14.2.8 RequirementCheck Element RequirementDefinition Description RequirementCheck is the most general class for requirements checking. RequirementCheck is the base type of all RequirementDefinitions . General Types ConstraintCheck Features actors : Part [0..*] The Parts that fill the role of actors for this RequirementCheck . assumptions : ConstraintCheck [0..*] {ordered} The checks of assumptions that must hold for the required constraints to apply. concerns : ConcernCheck [0..*] {subsets constraints} The checks of any concerns being addressed (as required constraints). constraints : ConstraintCheck [0..*] {ordered} The checks of required constraints. stakeholders : Part [0..*] The Parts that represent stakeholders interested in the requirement being checked. subj : Anything The entity that is being check for satisfaction of the required constraints. Constraints [no name] allTrue(assumptions) implies allTrue(constraints) 9.2.14.2.9 requirementChecks Element RequirementUsage Systems Modeling Language v2.0, Part 1 499 -Description requirementChecks is the base feature of all RequirementUsages . General Types constraintChecks RequirementCheck Features None. Constraints None. 9.2.15 Cases 9.2.15.1 Cases Overview This package defines the base types for cases and related behavioral elements in the SysML language. 9.2.15.2 Elements 9.2.15.2.1 Case Element CaseDefinition Description Case is the most general class of performances of CaseDefinitions . Case is the base class of all CaseDefinitions . General Types Calculation Features actors : Part [0..*] The Parts that fill the role of actors for this Case . obj : RequirementCheck A check of whether the objective RequirementUsage was satisfied for this Case . By default, the subj for the objective is the result of the Case . subcases : Case [0..*] {subsets subcalculations} Other Cases carried out as part of the performance of this Case . subj : Anything 500 Systems Modeling Language v2.0, Part 1 -The subject that was investigated by this Case . Constraints None. 9.2.15.2.2 cases Element CaseUsage Description cases is the base feature of all CaseUsages . General Types calculations Case Features None. Constraints None. 9.2.16 Analysis Cases 9.2.16.1 Analysis Cases Overview This package defines the base types for analysis cases and related behavioral elements in the SysML language. 9.2.16.2 Elements 9.2.16.2.1 AnalysisCase Element AnalysisCaseDefinition Description AnalysisCase is the most general class of performances of AnalysisCaseDefinitions . AnalysisCase is the base class of all AnalysisCaseDefinitions . General Types Case Features subAnalysisCases : AnalysisCase [0..*] {subsets subcases} Systems Modeling Language v2.0, Part 1 501 -The subcases of this AnalysisCase that are AnalysisCaseUsages . Constraints None. 9.2.16.2.2 analysisCases Element AnalysisCaseUsage Description analysisCases is the base feature of all AnalysisCaseUsages . General Types AnalysisCase cases Features None. Constraints None. 9.2.17 Verification Cases 9.2.17.1 Verification Cases Overview This package defines the base types for verification cases and related behavioral elements in the SysML language. 9.2.17.2 Elements 9.2.17.2.1 PassIf Element CalculationDefinition Description PassIf returns a pass or fail VerdictKind depending on whether its argument is true or false. General Types None. Features isPassing : Boolean in Whether or not a verification has passed. 502 Systems Modeling Language v2.0, Part 1 -verdict : VerdictKind return pass if isPassing is true and fail Constraints None. 9.2.17.2.2 VerdictKind Element EnumerationDefinition Description VerdictKind is an enumeration of the possible results of a VerificationCase General Types AttributeValue Features error fail inconclusive pass Constraints None. 9.2.17.2.3 VerificationCase Element VerificationCaseDefinition Description VerificationCase is the most general class of performances of VerificationCaseDefinitions . VerificationCase is the base class of all VerificationCaseDefinitions . General Types Case Features obj : VerificationCheck {redefines obj} Systems Modeling Language v2.0, Part 1 503 -The objective of this VerificationCase , whose subject is bound to the subject of the VerificationCase and whose requirementVerifications are bound to the requirementVerifications of the VerificationCase . requirementVerifications : RequirementCheck [0..*] Checks on whether the verifiedRequirements of the VerificationCaseDefinition have been satisfied. subj : Anything {redefines subj} The subject of this VerificationCase , representing the system under test, which is bound to the subject of the objective of the VerificationCase . subVerificationCases : VerificationCase [0..*] {subsets subcases} The subcases of this VerificationCase that are VerificationCases . verdict : VerdictKind {redefines result} The result of a VerificationCase must be a VerdictKind . Constraints None. 9.2.17.2.4 verificationCases Element VerificationCaseUsage Description verificationCases is the base feature of all VerificationCaseUsages . General Types VerificationCase cases Features None. Constraints None. 9.2.17.2.5 VerificationCheck Element RequirementDefinition Description 504 Systems Modeling Language v2.0, Part 1 -VerificationCheck is a specialization of RequirementCheck used for the objective of a VerificationCase in order to record the evaluations of the RequirementChecks of requirements being verified. General Types RequirementCheck Features requirementVerifications : RequirementCheck [0..*] {subsets constraints} A record of the evaluations of the RequirementChecks of requirements being verified. Constraints None. 9.2.17.2.6 VerificationMethod Element AttributeDefinition Description VerificationMethod can be used as metadata annotating a verification case or action. General Types None. Features kind : VerificationMethodKind [1..*] The methods by which the annotated verification was carried out. Constraints None. 9.2.17.2.7 VerificationMethodKind Element EnumerationDefinition Description VerificationMethodKind is an enumeration of the standard methods by which verification can be carried out. General Types AttributeValue Features Systems Modeling Language v2.0, Part 1 505 -analyze demo inspect test Constraints None. 9.2.18 Use Cases 9.2.18.1 Use Cases Overview This package defines the base types for use cases and related behavioral elements in the SysML language. 9.2.18.2 Elements 9.2.18.2.1 UseCase Element UseCaseDefinition Description UseCase is the most general class of performances of UseCaseDefinitions . UseCase is the base class of all UseCaseDefinitions . General Types Case Features includedUseCases : UseCase [0..*] {subsets subUseCases} Other UseCase included by this UseCase (i.e., as modeled by an IncludeUseCaseUsage ). subUseCases : UseCase [0..*] {subsets subcases} Other UseCase carried out as part of the performance of this UseCase . Constraints None. 9.2.18.2.2 useCases Element UseCaseUsage Description 506 Systems Modeling Language v2.0, Part 1 -useCases is the base feature of all UseCaseUsages . General Types cases UseCase Features None. Constraints None. 9.2.19 Views 9.2.19.1 Views Overview This package defines the base types for views, viewpoints, renderings and related elements in the SysML language. 9.2.19.2 Elements 9.2.19.2.1 asElementTable Element RenderingUsage Description asElementTable renders a View as a table, with one row for each exposed Element and columns rendered by applying the columnViews in order to the Element in each row. General Types TabularRendering Features columnView : View [0..*] {ordered} The Views to be rendered in the column cells, in order, of each rows of the table. Constraints None. 9.2.19.2.2 asInterconnectionDiagram Element RenderingUsage Description Systems Modeling Language v2.0, Part 1 507 -asInterconnectionDiagram renders a View as an interconnection diagram, using the graphical notation defined in the SysML specification. General Types GraphicalRendering Features None. Constraints None. 9.2.19.2.3 asTextualNotation Element RenderingUsage Description asTextualNotation renders a View into textual notation as defined in the KerML and SysML specifications. General Types TextualRendering Features None. Constraints None. 9.2.19.2.4 asTreeDiagram Element RenderingUsage Description asTreeDiagram renders a View as a tree diagram, using the graphical notation defined in the SysML specification. General Types GraphicalRendering Features None. Constraints 508 Systems Modeling Language v2.0, Part 1 -None. 9.2.19.2.5 GraphicalRendering Element RenderingDefinition Description A GraphicalRendering is a Rendering of a View into a graphical format. General Types Rendering Features None. Constraints None. 9.2.19.2.6 Rendering Element RenderingDefinition Description Rendering is the base type of all RenderingDefinitions . General Types Part Features subrenderings : Rendering [0..*] Other Rendering used to carry out this Rendering . Constraints None. 9.2.19.2.7 renderings Element RenderingUsage Description Systems Modeling Language v2.0, Part 1 509 -renderings is the base feature of all RenderingUsages . General Types Rendering parts Features None. Constraints None. 9.2.19.2.8 TabularRendering Element RenderingDefinition Description A TabularRendering is a Rendering of a View into a tabular format. General Types Rendering Features None. Constraints None. 9.2.19.2.9 TextualRendering Element RenderingDefinition Description A TextualRendering is a Rendering of a View into a textual format. General Types Rendering Features None. 510 Systems Modeling Language v2.0, Part 1 -Constraints None. 9.2.19.2.10 View Element ViewDefinition Description View is the base type of all ViewDefinitions . General Types Part Features self : View {redefines self} subviews : View [0..*] Other Views that are used in the rendering of this View . viewpointConformance : viewpointConformance An assertion that all viewpointSatisfactions are true. viewpointSatisfactions : ViewpointCheck [0..*] Checks that the View satisfies all required ViewpointUsages . viewRendering : Rendering [0..1] The Rendering of this View . Constraints None. 9.2.19.2.11 ViewpointCheck Element ViewpointDefinition Description ViewpointCheck is a RequirementCheck for checking if a View meets the concerns of concernedStakeholders . It is the base type of all ViewpointDefinitions . General Types RequirementCheck Systems Modeling Language v2.0, Part 1 511 -Features subject : View {redefines subj} The subject of this ViewpointCheck , which must be a View . Constraints None. 9.2.19.2.12 viewpointChecks Element ViewpointUsage Description viewpointChecks is the base feature of all ViewpointUsages. General Types ViewpointCheck requirementChecks Features None. Constraints None. 9.2.19.2.13 viewpointConformance Element SatisfyRequirementUsage Description A RequirementCheck that all viewpointSatisfactions are true. General Types RequirementCheck Features viewpointSatisfactions : ViewpointCheck [0..*] {subsets constraints} The required ViewpointChecks . Constraints 512 Systems Modeling Language v2.0, Part 1 -None. 9.2.19.2.14 views Element ViewUsage Description views is the base feature of all ViewUsages . General Types parts View Features None. Constraints None. 9.2.20 Standard View Definitions 9.2.20.1 Standard View Definitions Overview This package defines normative standard view definitions that shall be supported by any tool conforming to the SysML graphical notation. The standard view definitions include filter conditions to specify valid contents for the view, which shall then be rendered as specified in the graphical notation grammar (see 8.2.3 ). Table 34 lists all the standard view definitions contained in the package, along with the corresponding graphical notation subclause that specifies the rendering of each view. Note. Visualization of SysML models is not limited to these standard views. User-defined view definitions and usages can be used to provide a wide range of views beyond the standard set (see 8.2.2.26 , 8.2.3.26 , and 8.3.26 ). Table 34. Standard View Definitions Standard View Definition Default Compartment General View (gv) Default compartment for a package, see 8.2.3.5 . Interconnection View (iv) Default compartment for a part, see 8.2.3.11 . Action Flow View (afv) Default compartment for an action, see 8.2.3.17 . State Transition View (stv) Default compartment for a state, see 8.2.3.18 . Systems Modeling Language v2.0, Part 1 513 -Standard View Definition Default Compartment Sequence View (sv) Default compartment for an occurrence, see 8.2.3.9 . Geometry View (gev) Grid View (grv) Browser View (bv) 9.2.20.2 Elements 9.2.20.2.1 ActionFlowView Element ViewDefinition Description ViewDefinition to present connections between actions. Valid nodes and edges in an ActionFlowView are: • Actions with nested actions • Parameters with direction • Flow connection usages (e.g., kinds of transfers from output to input) • Binding connections between parameters (e.g., delegate a parameter from one level of nesting to another) • Proxy connection points • Swim lanes • Conditional succession • Control nodes (fork, join, decision, merge) • Control structures, e.g., if-then-else, until-while-loop, for-loop • Send and accept actions • Change and time triggers • Compartments on actions and parameters Short name: afv General Types InterconnectionView Features None. Constraints None. 514 Systems Modeling Language v2.0, Part 1 -9.2.20.2.2 BrowserView Element ViewDefinition Description ViewDefinition to present the hierarchical membership structure of model elements starting from an exposed root element. The typical rendering in graphical notation is as an indented list of rows, consisting of dynamically collapsible-expandable nodes that represent branches and leaves of the tree. Short name: bv General Types None. Features None. Constraints None. 9.2.20.2.3 GeneralView Element ViewDefinition Description ViewDefinition to present any members of exposed model element(s). This is the most general view, enabling presentation of any model element. The typical rendering in graphical notation is as a graph of nodes and edges. Specializations of GeneralView can be specified through appropriate selection of filters, e.g.: • package view, filtering on Package , Package containment, package Import • definition and usage view, filtering on Definition , Usage , Specialization , FeatureTyping (covering defined by) • requirement view, filtering on RequirementDefinition , RequirementUsage , Specialization , FeatureTyping , SatisfyRequirementUsage , AllocationDefinition , AllocationUsage , ... • view and viewpoint view, filtering on ViewDefinition , ViewUsage , ViewpointDefinition , ViewpointUsage , RenderingDefinition , RenderingUsage , ConcernDefinition , ConcernUsage , StakeholderMembership , ... • language extension view, filtering on Metaclass , MetadataFeature , MetadataAccessExpression , ... Note: filters are specified by referencing concepts from the KerML and SysML standard library packages. Short name: gv General Types Systems Modeling Language v2.0, Part 1 515 -None. Features None. Constraints None. 9.2.20.2.4 GeometryView Element ViewDefinition Description ViewDefinition to present a visualization of exposed spatial items in two or three dimensions Valid nodes and edges in a GeometryView are: • Spatial item, including shape • Coordinate frame • Feature related to spatial item, such as a quantity (e.g. temperature) of which values are to be rendered on a color scale The typical rendering in graphical notation would include a number of visualization parameters, such as: • 2D or 3D view • viewing direction • zoom level • light sources • object projection mode, e.g., isometric, perspective, orthographic • object rendering mode, e.g., shaded, wireframe, hidden line • object pan (placement) and rotate (orientation) settings • color maps Short name: gev General Types None. Features None. Constraints None. 9.2.20.2.5 GridView Element ViewDefinition 516 Systems Modeling Language v2.0, Part 1 -Description ViewDefinition to present exposed model elements and their relationships, arranged in a rectangular grid. GeometryView is the generalization of the following more specialized views: • Tabular view • Data value tabular view • Relationship matrix view Short name: grv General Types None. Features None. Constraints None. 9.2.20.2.6 InterconnectionView Element ViewDefinition Description ViewDefinition to present exposed features as nodes, nested features as nested nodes, and connections between features as edges between (nested) nodes. Nested nodes may present boundary features (e.g., ports, parameters). Short name: iv General Types None. Features None. Constraints None. 9.2.20.2.7 SequenceView Element ViewDefinition Description Systems Modeling Language v2.0, Part 1 517 -ViewDefinition to present time ordering of event occurrences on lifelines of exposed features. Valid nodes and edges in a SequenceView are: • Features such as parts with their lifelines • Event occurrences on the lifelines • Messages sent from one part to another with and without a type of flow • Succession between event occurrences • Nested sequence view (e.g., a reference to a view) • Compartments The typical rendering in graphical notation depicts the exposed features horizontally along the top, with vertical lifelines. The time axis is vertical, with time increasing from top to bottom. Short name: sv General Types None. Features None. Constraints None. 9.2.20.2.8 StateTransitionView Element ViewDefinition Description ViewDefinition to present states and their transitions. Valid nodes and edges in a StateTransitionView are: • States with nested states • Entry, do, and exit actions • Transition usages with triggers, guards, and actions • Compartments on states Short name: stv General Types InterconnectionView Features None. Constraints None. 518 Systems Modeling Language v2.0, Part 1 -9.2.21 Metadata 9.2.21.1 Metadata Overview This package defines the base types for metadata definitions and related metadata annotations in the SysML language. 9.2.21.2 Elements 9.2.21.2.1 MetadataItem Element MetadataDefinition Description MetadataItem is the most general class of Items that represent Metaobjects . MetadataItem is the base type of all MetadataDefinitions . General Types Item Metaobject Features None. Constraints None. 9.2.21.2.2 metadataItems Element ItemUsage Description metadataItems is the base feature of all MetadataUsages . Note: It is not itself a MetadataUsage , because it is not being used as an AnnotatingElement here. General Types items metaobjects MetadataItem Features None. Systems Modeling Language v2.0, Part 1 519 -Constraints None. 9.2.22 SysML This package contains a reflective SysML model of the SysML abstract syntax. It is generated from the normative MOF abstract syntax model (see 8.3 ) as follows. 1. The SysML model imports all elements from the reflective KerML package (see [KerML, 9.2.17]) and directly contains all metaclasses mapped from the SysML abstract syntax, without any subpackaging. 2. A metaclass from the MOF model is mapped into a MetadataDefinition in the KerML package. ◦ The MOF metaclass name is mapped unchanged. ◦ Generalizations of the MOF metaclass are mapped to ownedSpecializations . ◦ All properties from the MOF metaclass are mapped to usages of the corresponding MetadataDefinition (see below). All non-association-end properties are grouped before association-end properties. 3. A property from the MOF model is mapped into an AttributeUsage or ItemUsage , depending on whether the MOF property type is a data type or a class. ◦ The following feature properties are set as appropriate: ▪ isAbstract = true if the MOF property is a derived union ▪ isReadonly = true if the MOF property is read-only. ▪ isDerived = true if the MOF property is derived. ▪ isReferential = true if the MOF property is not composite. ▪ isOrdered = true if the MOF property is ordered ▪ isUnique = false if the MOF property is non-unique ◦ The MOF property name is mapped unchanged. ◦ The MOF property type is mapped to an ownedTyping relationship. ▪ If the MOF property type is a primitive type, the relationship is to the corresponding type from the ScalarValues package (see [KerML, 9.3.2]). ▪ If the MOF property type is a metaclass, the relationship is to the corresponding reflective MetadataDefinition . ◦ The MOF property multiplicity is mapped to an owned MultiplicityRange with bounds given by LiteralExpressions . ◦ Subsetted properties from the MOF property are mapped to ownedSubsettings of the corresponding reflective Features or Usages . ◦ Redefined properties from the MOF property are mapped to ownedRedefinitions of the corresponding reflective Features or Usages . ◦ If the MOF property is annotatedElement , then Metaobject::annotatedElement is added to the list of redefined properties for the mapping. 4. An enumeration from the MOF model is mapped into an EnumerationDefinition . ◦ The MOF enumeration name is mapped unchanged. ◦ Each enumeration literal from the MOF enumeration is mapped into an enumeratedValue of the EnumerationDefinition , with the same name as the MOF enumeration literal. Note that associations are not mapped from the MOF model and, hence, non-navigable association-owned end properties are not included in the reflective model. 9.3 Metadata Domain Library 9.3.1 Metadata Domain Library Overview The Metadata Domain Library contains library models of generally useful metadata that can be used to annotate model elements (see 7.4 ). 520 Systems Modeling Language v2.0, Part 1 -9.3.2 Modeling Metadata 9.3.2.1 Modeling Metadata Overview This package contains definitions of metadata generally useful for annotating models. 9.3.2.2 Elements 9.3.2.2.1 Issue Element MetadataDefinition Description Issue is used to record some issue concerning the annotated element. General Types MetadataItem Features text : String A textual description of the issue. Constraints None. 9.3.2.2.2 Rationale Element MetadataDefinition Description Rationale is used to explain a choice or other decision made related to the annotated element. General Types MetadataItem Features explanation : Anything [0..1] A reference to a Feature that provides a formal explanation of the rationale. (For example, a trade study whose result explains the choice of a certain alternative). text : String A textual description of the rationale (required). Systems Modeling Language v2.0, Part 1 521 -Constraints None. 9.3.2.2.3 Refinement Element MetadataDefinition Description Refinement is used to identify a Dependency as modeling a refinement relationship. In such a relationship, the source elements of the relationship provide a more precise and/or accurate representation than the target elements. General Types MetadataItem Features annotatedElement : Dependency {redefines annotatedElement} Constraints None. 9.3.2.2.4 StatusInfo Element MetadataDefinition Description StatusInfo is used to annotate a model element with status information. General Types MetadataItem Features originator : String [0..1] The originator of the annotatedElement . owner : String [0..1] The current owner of the annotatedElement . risk : Risk [0..1] An assessment of risk for the annotatedElement . status : StatusKind 522 Systems Modeling Language v2.0, Part 1 -The current status of work on the annotatedElement (required). Constraints None. 9.3.2.2.5 StatusKind Element EnumerationDefinition Description StatusKind enumerates the possible statuses of work on a model element. General Types AttributeValue Features closed Status is closed. done Status is done. open Status is open. tbc Status is to be confirmed. tbd Status is to be determined. tbr Status is to be resolved. Constraints None. 9.3.3 Risk Metadata 9.3.3.1 Risk Metadata Overview This package defines metadata for annotating model elements with assessments of risk. Systems Modeling Language v2.0, Part 1 523 -9.3.3.2 Elements 9.3.3.2.1 Level Element AttributeDefinition Description A Level is a Real number in the interval 0.0 to 1.0, inclusive. General Types AttributeValue Real Features level : Level {redefines self} Constraints levelRange level >= 0.0 and level <= 1.0 9.3.3.2.2 LevelEnum Element EnumerationDefinition Description LevelEnum provides standard probability Levels for low, medium and high risks. General Types Level Features high High level, taken to be 75%. low Low level, taken to be 25%. medium Medium level taken to be 50%. Constraints 524 Systems Modeling Language v2.0, Part 1 -None. 9.3.3.2.3 Risk Element MetadataDefinition Description Risk is used to annotate a model element with an assessment of the risk related to it in some typical risk areas. General Types MetadataItem Features costRisk : RiskLevel [0..1] The risk that work on the annotatedElement will exceed its planned cost. scheduleRisk : RiskLevel [0..1] The risk that work on the annotatedElement will not be completed on schedule. technicalRisk : RiskLevel [0..1] The risk of unresolved technical issues regarding the annotatedElement . totalRisk : RiskLevel [0..1] The total risk associated with the annotatedElement . Constraints None. 9.3.3.2.4 RiskLevel Element AttributeDefinition Description RiskLevel gives the probability of a risk occurring and, optionally, the impact if the risk occurs. General Types AttributeValue Features impact : Level [0..1] Systems Modeling Language v2.0, Part 1 525 -The impact of the risk if it occurs (with 0.0 being no impact and 1.0 being the most severe impact). probability : Level The probability that a risk will occur. Constraints None. 9.3.3.2.5 RiskLevelEnum Element EnumerationDefinition Description RiskLevelEnum enumerates standard RiskLevels for low, medium and high risks (without including impact). General Types RiskLevel Features high Risk level with high probability. low Risk level with low probability. medium Risk level with medium probability. Constraints None. 9.3.4 Parameters of Interest Metadata 9.3.4.1 Parameters of Interest Metadata Overview This package contains definitions of metadata to identify key parameters of interest, including measures of effectiveness (MOE) and other key measures of performance (MOP). 9.3.4.2 Elements 9.3.4.2.1 MeasureOfEffectiveness Element MetadataDefinition 526 Systems Modeling Language v2.0, Part 1 -Description MeasureOfEffectiveness (short name moe ) is semantic metadata for identifying an attribute as a measure of effectiveness. General Types SemanticMetadata MetadataItem Features annotatedElement : Usage {redefines annotatedElement} baseType : Type {redefines baseType} Base type is measuresOfEffectiveness . Constraints None. 9.3.4.2.2 MeasureOfPerformance Element MetadataDefinition Description MeasureOfPerformance (short name mop ) is semantic metadata for identifying an attribute as a measure of performance. General Types SemanticMetadata MetadataItem Features annotatedElement : Usage {redefines annotatedElement} baseType : Type {redefines baseType} Base type is measuresOfPeformance . Constraints None. 9.3.4.2.3 measuresOfEffectiveness Element Systems Modeling Language v2.0, Part 1 527 -AttributeUsage Description Base feature for attributes that are measures of effectiveness. General Types attributeValues Features None. Constraints None. 9.3.4.2.4 measuresOfPerformance Element AttributeUsage Description Base feature for attributes that are measures of performance. General Types attributeValues Features None. Constraints None. 9.3.5 Image Metadata 9.3.5.1 Image Metadata Overview This package provides attributive data and metadata to allow a model element to be annotated with an image to be used in its graphical rendering or as a marker to adorn graphical or textual renderings. 9.3.5.2 Elements 9.3.5.2.1 Icon Element MetadataDefinition Description 528 Systems Modeling Language v2.0, Part 1 -Icon metadata can be used to annotate a model element with an image to be used to show render the element on a diagram and/or a small image to be used as an adornment on a graphical or textual rendering. Alternatively, another metadata definition can be annotated with an Icon to indicate that any model element annotated by the containing metadata can be rendered according to the Icon . General Types MetadataItem Features fullImage : Image [0..1] A full-sized image that can be used to render the annotated element on a graphical view, potentially as an alternative to its standard rendering. smallImage : Image [0..1] A smaller image that can be used as an adornment on the graphical rendering of the annotated element or as a marker in a textual rendering. Constraints None. 9.3.5.2.2 Image Element AttributeDefinition Description Image provides the data necessary for the physical definition of a graphical image. General Types AttributeValue Features content : String [0..1] Binary data for the image according to the given MIME type, encoded as given by the encoding. encoding : String [0..1] Describes how characters in the content are to be decoded into binary data. At least "base64", "hex", "identify", and "JSONescape" shall be supported. location : String [0..1] A URI for the location of a resource containing the image content, as an alternative for embedding it in the content attribute. type : String [0..1] Systems Modeling Language v2.0, Part 1 529 -The MIME type according to which the content should be interpreted. Constraints None. 9.4 Analysis Domain Library 9.4.1 Analysis Domain Library Overview The Analysis Domain Library provides library models supporting the modeling of analysis cases (see 7.23 ) and related analysis tasks. 9.4.2 Analysis Tooling 9.4.2.1 Analysis Tooling Overview This package contains definitions for metadata annotations related to analysis tool integration. 9.4.2.2 Elements 9.4.2.2.1 ToolExecution Element MetadataDefinition Description ToolExecution metadata identifies an external analysis tool to be used to implement the annotated action. General Types MetadataItem Features toolName : String uri : String Constraints None. 9.4.2.2.2 ToolVariable Element MetadataDefinition Description ToolVariable metadata is used in the context of an action that has been annotated with ToolExecution metadata. It is used to annotate a parameter or other feature of the action with the name of the variable in the tool that is to correspond to the annotated feature. 530 Systems Modeling Language v2.0, Part 1 -General Types MetadataItem Features name : String Constraints None. 9.4.3 Sampled Functions 9.4.3.1 Sampled Functions Overview This package provides a library model of discretely sampled mathematical functions. A SampledFunction can be used for many engineering purposes. For example, it can represent a time series observation, where the domain consists of time instants expressed on a given timescale and the range consists of observed quantity values. It can also capture a physical property of a substance that depends on temperature or pressure or both. A SampledFunction with numerical domain and range types can be used as input to an interpolation algorithm in order to obtain range values for domain values that fall in-between the discretely sampled domain values. 9.4.3.2 Elements 9.4.3.2.1 Domain Element CalculationDefinition Description Domain returns the sequence of the domainValues of all samples in a SampledFunction . General Types Calculation Features fn : SampledFunction input result : Anything [0..*] output Constraints None. Systems Modeling Language v2.0, Part 1 531 -9.4.3.2.2 Interpolate Element CalculationDefinition Description An Interpolate calculation returns an interpolated range value from a given SampledFunction for a given domain value . If the input domain value is outside the bounds of the domainValues of the SampleFunction , null is returned. General Types Calculation Features fn : SampledFunction input result : Anything [0..1] output value : Anything input Constraints None. 9.4.3.2.3 interpolateLinear Element CalculationUsage Description interpolateLinear is an Interpolate calculation assuming a linear functional form between SamplePairs . General Types Interpolate calculations Features fn : SampledFunction input 532 Systems Modeling Language v2.0, Part 1 -result : Anything [0..1] {redefines result} output value : Anything {redefines value} input Constraints None. 9.4.3.2.4 Range Element CalculationDefinition Description Range returns the sequence of the rangeValues of all samples in a SampledFunction . General Types Calculation Features fn : SampledFunction input result : Anything [0..*] output Constraints None. 9.4.3.2.5 Sample Element CalculationDefinition Description Sample returns a SampledFunction that samples a given calculation over a sequence of domainValues . General Types Calculation Features calculation : Calculation [0..*] Systems Modeling Language v2.0, Part 1 533 -input domainValues : Anything [0..*] input sampling : SampledFunction output Constraints None. 9.4.3.2.6 SampledFunction Element AttributeDefinition Description SampledFunction is a variable-size, ordered collection of SamplePair elements that represents a generic, discretely sampled, uni-variate or multi-variate mathematical function. The function must be montonic, either strictly increasing or strictly decreasing. It maps discrete domain values to discrete range values. The domain of the function is represented by the sequence of domainValues of each SamplePair in samples , and the range of the function is represented by the sequence of rangeValues of each SamplePair in samples . General Types OrderedMap Features samples : SamplePair [0..*] {redefines elements, ordered} Constraints [no name] Note: Assumes the functions '<' and '>' are defined for the domain type. (1..size(samples)-1)->forAll { in i; (samples.domainValue[i] < samples.domainValue[i+1]) } or // Strictly increasing (1..size(samples)-1)->forAll { in i; (samples.domainValue[i] > samples.domainValue[i+1]) } // Strictly decreasing 9.4.3.2.7 SamplePair Element AttributeDefinition Description 534 Systems Modeling Language v2.0, Part 1 -SamplePair is a key-value pair of a domainValue and a rangeValue , used as a sample element in SampledFunction . General Types KeyValuePair Features domainValue : Anything {redefines key} rangeValue : Anything {redefines val} Constraints None. 9.4.4 State Space Representation 9.4.4.1 State Space Representation Overview State Space Representation (SSR) is a foundational dynamical systems representation, commonly used in control systems. In this representation, a system is described by a set of state variables whose evolution by a state equation (note that this is a different conception of "state" than used in the behavioral state modeling constructs described in 7.18 ). The system outputs are then given by an output equation. This representation provides a description of the quantitative stateful behavior of the target system in an explicit manner so that external solvers can compute the behavior by properly integrating input and state variables. Mathematically, let x be a vector of state variables and x' be its time derivative, u be a vector of inputs, and y be a vector of outputs. Then the state equation has the form x' = f(x, u) , for some system-specific function f, and the output equation has the form y = g(x, u) , for some system-specific function g. The StateSpaceRepresentation library model is a model of this representation in terms of SysML actions and calculations. These can be used in combination with end-user action models to describe system functional behaviors. 9.4.4.2 Elements Fig. 55 shows the action definitions in the State Space Representation library. This library defines StateSpaceDynamics as the base abstract action definition, which provides the basic structure of input, output, and state space. This definition has getNextState and getOuput calculations as well to calculate the next state and the current output, which corresponds to the math functions of f() and g(), respectively. ContinuousStateSpaceDynamics gives the continuous extension of StateSpaceDynamics by redefininig getNextState and adding getDerivative that calculates the derivative of the state space, corresponding to x'. Likewise, DiscreteStateSpaceDinamics gives the discrete extension by adding getDifference that calculates ∆x, that is the difference between the current state and the next state, and getNextState adds it to stateSpace . Systems Modeling Language v2.0, Part 1 535 -Figure 55. State Space Representation action and calculation definitions zeroCrossingEvents defined in ContinuousStateSpaceDynamics give event occurrences when the derivative cross the zero. Some solvers, especially variable-step ones, need to identify such points for precise integration and thus implementations of ContinuousStateSpaceDynamics may notify zero-crossings with these event occurrences. 9.4.5 Trade Studies 9.4.5.1 Trade Studies Overview This package provides a simple framework for defining trade-off study analysis cases. 9.4.5.2 Elements 9.4.5.2.1 EvaluationFunction Element CalculationDefinition Description 536 Systems Modeling Language v2.0, Part 1 -An EvaluationFunction is a calculation that evaluates a TradeStudy alternative, producing a ScalarValue that can be compared with the evaluation of other alternatives. General Types Calculation Features alternative : Anything The alternative to be evaluated result : ScalarValue {redefines result} A ScalarValue representing the evaluation of the given alternative. Constraints None. 9.4.5.2.2 MaximizeObjective Element RequirementDefinition Description A MaximizeObjective is a TradeStudyObjective that requires that the selectedAlternative have the maximum EvaluationFunction value of all the given alternatives. General Types TradeStudyObjective Features alternatives : Anything [1..*] {redefines alternatives} best : ScalarValue {redefines best} For a MaximizeObjective , the best value is the maximum one. eval : EvaluationFunction {redefines eval} selectedAlternative : Anything {redefines selectedAlternative} Constraints None. 9.4.5.2.3 MinimizeObjective Element Systems Modeling Language v2.0, Part 1 537 -RequirementDefinition Description A MinimizeObjective is a TradeStudyObjective that requires that the selectedAlternative have the minimum EvaluationFunction value of all the given alternatives. General Types TradeStudyObjective Features alternatives : Anything [1..*] {redefines alternatives} best : ScalarValue {redefines best} For a MinimizeObjective , the best value is the minimum one. eval : EvaluationFunction {redefines eval} selectedAlternative : Anything {redefines selectedAlternative} Constraints None. 9.4.5.2.4 TradeStudy Element AnalysisCaseDefinition Description A TradeStudy is an analysis case whose subject is a set of alternatives (at least one) and whose result is a selection of one of those alternatives. The alternatives are evaluated based on a given ObjectiveFunction and the selection is made such that it satisfies the objective of the TradeStudy (which must be a TradeStudyObjective ). General Types AnalysisCase Features evaluationFunction : EvaluationFunction [0..*] The EvaluationFunction to be used to evaluate the alternatives. In a TradeStudy usage, redefine this feature to provide the desired calculation (or bind it to a calculation usage that does so). selectedAlternative : Anything The alternative selected by this TradeStudy , which is the one that meets the requirement of the tradeStudyObjective . 538 Systems Modeling Language v2.0, Part 1 -studyAlternatives : Anything [1..*] {redefines subj} The set of alternatives being considered in this TradeStudy . In a TradeStudy usage, bind this feature to the actual collection of alternatives to be considered. tradeStudyObjective : TradeStudyObjective The objective of this TradeStudy . Redefine this feature to give it a definition that is a concrete specialization of TradeStudyObjective . That can either be one of the specializations provided in this package, or a more specific user-defined one. Constraints None. 9.4.5.2.5 TradeStudyObjective Element RequirementDefinition Description A TradeStudyObjective is the base definition for the objective of a TradeStudy . The requirement is to choose from a given set of alternatives the selectedAlternative for that has the best evaluation according to a given EvaluationFunction . What value is considered "best" is not defined in the abstract base definition but must be computed in any concrete specialization. General Types RequirementCheck Features alternatives : Anything [1..*] The alternatives being considered in the TradeStudy for which this TradeStudyObjective is the objective. best : ScalarValue Out of the evaluation results of all the given alternatives, the one that is considered "best", in the sense that it is the value the selectedAlternative should have. This value must be computed in any concrete specialization of TradeStudyObjective/em> . eval : EvaluationFunction The EvaluationFunction to be used in evaluating the given alternatives. selectedAlternative : Anything {redefines subj} The alternative that should be selected, as evaluated using the given EvaluationFunction . Constraints Systems Modeling Language v2.0, Part 1 539 -[no name] eval(selectedAlternative) == best 9.5 Cause and Effect Domain Library 9.5.1 Cause and Effect Domain Library Overview The Cause and Effect Domain Library contains a library model of cause and effect relationships and metadata supporting its use. 9.5.2 Causation Connections 9.5.2.1 Causation Connections Overview This package provides a library model modeling causes, effects, and causation connections between them. 9.5.2.2 Elements 9.5.2.2.1 Causation Element ConnectionDefinition Description A Causation is a binary Multicausation in which a single cause occurrence causes a single effect occurrence. (However, a single cause can separately have multiple effects, and a single effect can have separate Causation connections with multiple causes.) General Types Multicausation BinaryConnection Features theCause : Occurrence {subsets causes, redefines source} The single causing occurrence. theCauses : Occurrence [0..*] Owned cross feature for theCause . theEffect : Occurrence {subsets effects, redefines target} The single effect occurrence resulting from the cause. theEffects : Occurrence [0..*] Owned cross feature for theEffect . Constraints 540 Systems Modeling Language v2.0, Part 1 -None. 9.5.2.2.2 causations Element ConnectionUsage Description causations is the base feature for Causation ConnectionUsages . General Types multicausations Causation Features None. Constraints None. 9.5.2.2.3 causes Element OccurrenceUsage Description Occurrences that are causes. General Types occurrences Features None. Constraints None. 9.5.2.2.4 effects Element OccurrenceUsage Description Systems Modeling Language v2.0, Part 1 541 -Occurrences that are effects. General Types occurrences Features None. Constraints None. 9.5.2.2.5 Multicausation Element ConnectionDefinition Description A Multicausation connection models the situation in which one set of occurrences causes another. All causes must at least exist before all effects. To create a Multicausation connection, specialize this connection definition adding specific end features of the relavent types. Ends representing causes should subset causes , while ends representing effects should subset effects . There must be at least one cause and at least one effect. General Types Connection Features causes : Occurrence [1..*] {subsets participant} The causing Occurrences . (Constant for each Multicausation instance.) Redefines CausationConnections::causes in the context of Multicausation . effects : Occurrence [1..*] {subsets participant} The effect Occurrences caused by the causing Occurrences . (Constant for each Multicausation instance.) Redefines CausationConnections::effects in the context of Multicausation . Constraints disjointCauseEffect causes must be disjoint from effects . isEmpty(intersection(causes, effects)) 542 Systems Modeling Language v2.0, Part 1 -9.5.2.2.6 multicausations Element ConnectionUsage Description multicausations is the base feature for Multicausation ConnectionUsages . General Types Multicausation connections Features None. Constraints None. 9.5.3 Cause and Effect 9.5.3.1 Cause and Effect Overview This package provides language-extension metadata for cause-effect modeling. 9.5.3.2 Elements 9.5.3.2.1 CausationMetadata Element MetadataDefinition Description CausationMetadata allows for the specification of additional metadata about a cause-effect ConnectionDefinition or ConnectionUsage. . General Types MetadataItem Features annotatedElement1 : ConnectionDefinition {subsets annotatedElement} annotatedElement2 : ConnectionUsage {subsets annotatedElement} isNecessary : Boolean Whether all the causes are necessary for all the effects to occur. If this is false (the default), then some or all of the effects may still have occurred even if some of the causes did not. Systems Modeling Language v2.0, Part 1 543 -isSufficient : Boolean Whether the causes were sufficient for all the effects to occur. If this is false (the default), then it may be the case that some other occurrences were also necessary for some or all of the effects to have occurred. probability : Real [0..1] The probability that the causes will actually result in effects occurring. Constraints None. 9.5.3.2.2 CausationSemanticMetadata Element MetadataDefinition Description CausationMetadata (short name causation ) is SemanticMetadata for a Causation connection. General Types SemanticMetadata CausationMetadata Features baseType : Type {redefines baseType} Base type is CausationConnections::causations . Constraints None. 9.5.3.2.3 CauseMetadata Element MetadataDefinition Description CauseMetadata (short name cause ) identifies a Usage as being a cause occurrence. It is intended to be used to tag the cause ends of a Multicausation . General Types SemanticMetadata MetadataItem 544 Systems Modeling Language v2.0, Part 1 -Features annotatedElement : Usage {redefines annotatedElement} baseType : Type {redefines baseType} Base type is CausationConnections::causes . Constraints None. 9.5.3.2.4 EffectMetadata Element MetadataDefinition Description EffectMetadata (short name effect ) identifies a Usage as being a effect occurrence. It is intended to be used to tag the effect ends of a Multicausation . General Types SemanticMetadata MetadataItem Features annotatedElement : Usage {redefines annotatedElement} baseType : Type {redefines baseType} Base type is CausationConnections::effects . Constraints None. 9.5.3.2.5 MulticausationSemanticMetadata Element MetadataDefinition Description MulticausationMetadata (short name multicausation ) is SemanticMetadata for a Multicausation connection. General Types SemanticMetadata Systems Modeling Language v2.0, Part 1 545 -CausationMetadata Features baseType : Type {redefines baseType} Base type is CausationConnections::multicausations . Constraints None. 9.6 Requirement Derivation Domain Library 9.6.1 Requirement Derivation Domain Library Overview The Requirement Derivation Domain Library contains a library model of requirement derivation relationships and metadata supporting its use. 9.6.2 Derivation Connections 9.6.2.1 Derivation Connections Overview This package provides a library model for derivation connections between requirements. 9.6.2.2 Elements 9.6.2.2.1 Derivation Element ConnectionDefinition Description A Derivation connection asserts that one or more derivedRequirements are derived from a single originalRequirement . This means that any subject that satisfies the originalRequirement should, in itself or though other things related to it, satisfy each of the derivedRequirements . A ConnectionUsage typed by Derivation must have RequirementUsages for all its ends. The single end for the original requirement should subset originalRequirement , while the rest of the ends should subset derivedRequirements . General Types Connection Features derivedRequirements : RequirementCheck [1..*] {subsets participant} The one or more requirements that are derived from the original requirement. Redefines DerivationConnections::derivedRequirements in the context of Derivation . originalRequirement : RequirementCheck {subsets participant} 546 Systems Modeling Language v2.0, Part 1 -The single original requirement. Redefines DerivationConnections::originalRequirement in the context of Derivation . participant : RequirementCheck [2..*] {redefines participant} All the participants in a Derivation must be requirements. Constraints originalImpliesDerived Whenever the originalRequirement is satisfied, all of the derivedRequirements must also be satisfied. originalRequirement.result implies allTrue(derivedRequirements.result) originalNotDerived The original requirement must not be a derived requirement. derivedRequirements->excludes(originalRequirement) 9.6.2.2.2 derivations Element ConnectionUsage Description derivations is the base feature for Derivation ConnectionUsages . General Types Derivation connections Features None. Constraints None. 9.6.2.2.3 derivedRequirements Element RequirementUsage Description derivedRequirements are the derived requirements in Derivation connections. General Types Systems Modeling Language v2.0, Part 1 547 -occurrences Features None. Constraints None. 9.6.2.2.4 originalRequirements Element RequirementUsage Description originalRequirements are the original requirements in Derivation connections. General Types occurrences Features None. Constraints None. 9.6.3 Requirement Derivation 9.6.3.1 Requirement Derivation Overview This package provides language-extension metadata for modeling requirement derivation. 9.6.3.2 Elements 9.6.3.2.1 DerivationMetadata Element MetadataDefinition Description DerivationMetadata (short name derivation ) is SemanticMetadata for a Derivation connection. General Types SemanticMetadata MetadataItem Features 548 Systems Modeling Language v2.0, Part 1 -annotatedElement1 : ConnectionDefinition {subsets annotatedElement} annotatedElement2 : ConnectionUsage {subsets annotatedElement} baseType : Type Base type is DerivationConnections::derivations . Constraints None. 9.6.3.2.2 DerivedRequirementMetadata Element MetadataDefinition Description DerivedlRequirementMetadata (short name derive ) identifies a Usage as a derived requirement. It is intended to be used to tag the derived requirement ends of a Derivation . General Types SemanticMetadata MetadataItem Features annotatedElement : Usage baseType : Type Base type is DerivationConnections::derivedRequirements . Constraints None. 9.6.3.2.3 OriginalRequirementMetadata Element MetadataDefinition Description OriginalRequirementMetadata (short name original ) identifies a Usage as an original requirement. It is intended to be used to tag the original requirement end of a Derivation . General Types SemanticMetadata Systems Modeling Language v2.0, Part 1 549 -MetadataItem Features annotatedElement : Usage baseType : Type Base type is DerivationConnections::originalRequirements . Constraints None. 9.7 Geometry Domain Library 9.7.1 Geometry Domain Library Overview The Geometry Domain Library contains a general library model of physical items with spatial extent and a library model of specific spatial items that represent basic geometric shapes. 9.7.2 Spatial Items 9.7.2.1 Spatial Items Overview This package models physical items that have a spatial extent and act as a spatial frame of reference for obtaining position and displacement vectors of points within them. 9.7.2.2 Elements 9.7.2.2.1 CurrentDisplacementOf Element CalculationDefinition Description The CurrentDisplacementOf two Points relative to a SpatialItem and a Clock is the DisplacementOf the Points relative to the SpacialItem , at the currentTime of the Clock . General Types CurrentDisplacementOf Features clock : Clock {redefines clock} displacementVector : Displacement3dVector {redefines displacementVector} frame : SpatialItem {redefines frame} point1 : Point {redefines point1} point2 : Point {redefines point2} 550 Systems Modeling Language v2.0, Part 1 -Constraints None. 9.7.2.2.2 CurrentPositionOf Element CalculationDefinition Description The CurrentPositionOf a Point relative to a SpatialItem and a Clock is the PositionOf the Point relative to the SpatialItem at the currentTime of the Clock . General Types CurrentPositionOf Features clock : Clock {redefines clock} point : Point {redefines point} positionVector : Position3dVector {redefines positionVector} spatialItem : SpatialItem {redefines frame} Constraints None. 9.7.2.2.3 DisplacementOf Element CalculationDefinition Description The DisplacementOf two Points relative to a SpatialItem , at a specific TimeInstantValue relative to a given Clock , is the displacementVector computed as the difference between the PositionOf the first Point and PositionOf the second Point , relative to that SpatialItem , at that timeInstant General Types DisplacementOf Features clock : Clock {redefines clock} displacementVector : Displacement3dVector {redefines displacementVector} frame : SpatialItem {redefines frame} Systems Modeling Language v2.0, Part 1 551 -point1 : Point {redefines point1} point2 : Point {redefines point2} time : TimeInstantValue {redefines time} Constraints zeroDisplacementConstraint If either point1 or point2 occurs within the other, then the displacementVector is the zero vector. (point1.spaceTimeEnclosedOccurrences->includes(point2) or point2.spaceTimeEnclosedOccurrences->includes(point1)) implies isZeroVector(displacementVector) 9.7.2.2.4 PositionOf Element CalculationDefinition Description The PositionOf a Point relative to a SpatialItem , at a specific TimeInstantValue relative to a given Clock , is a positionVector that is a VectorQuantityValue in the coordinateFrame of the SpatialItem . The default Clock is the localClock of the SpatialItem . General Types PositionOf Features clock : Clock {redefines clock} point : Point {redefines point} positionVector : Position3dVector {redefines positionVector} spatialItem : SpatialItem {redefines frame} time : TimeInstantValue {redefines time} Constraints positionTimePrecondition The given point must exist at the given time . TimeOf(point.startShot) <= time and time <= TimeOf(point.endShot) spacePositionConstraint The result positionVector is equal to the PositionOf the Point spaceShot of the frame that encloses the given point , at the given time . 552 Systems Modeling Language v2.0, Part 1 -(frame.spaceShots as Point)->forAll{in p : Point; p.spaceTimeEnclosedOccurrences->includes(point) implies positionVector == PositionOf(p, time, frame) } 9.7.2.2.5 SpatialItem Element ItemDefinition Description A SpatialItem is an Item with a three-dimensional spatial extent that also acts as a SpatialFrame of reference. General Types Item SpatialFrame Features componentItems : SpatialItem [0..*] {subsets subitems} A SpatialItem with componentItems is entirely made up of those items (the SpatialItem occurs only as a collection of its componentItems ). By default they have the same localClock and equivalent coordinateFrame as the SpatialItem they make up. A SpatialItem without componentItems occurs on its own, separately from its subitems . coordinateFrame : VectorMeasurementReference The three-dimensional VectorMeasurementReference to be used as the measurement reference for position and displacement vector values relative to this SpatialItem . localClock : Clock {redefines localClock} A local Clock to be used as the corresponding time reference within this SpatialItem . By default this is the singleton Time::universalClock . originPoint : Point The Point at the origin of the coordinateFrame of this SpatialItem . Constraints originPointConstraint The CurrentPositionOf the originPoint must always be a zero vector. isZeroVector(CurrentPositionOf(originPoint, SpatialItem::self)) Systems Modeling Language v2.0, Part 1 553 -9.7.3 Shape Items 9.7.3.1 Shape Items Overview This package defines basic geometric Items , most of which can be used as shapes of other Items (see 7.10 ). Their innerSpaceDimensions are either 1 ( Curves ) or 2 ( Surfaces ), which is the number of variables needed to identify any space point occupied by an Item, without regard to higher dimensional spaces in which it might be embedded (see Occurrences and Objects in [KerML]). All are StructuredSpaceObjects ( Paths and Shells for Curves and Surfaces , respectively), except for Lines . This enables them to divide their spaceSlices into faces , edges , and vertices , identifying Surfaces , Curve , and Points , respectively. Paths have no faces , but Shells do. All the Paths and Shells are closed ( isClosed =true, they have no shape ), except for Discs , enabling them to be shapes of other Items . 9.7.3.2 Elements 9.7.3.2.1 Circle Element ItemDefinition Description A Circle is an Ellipse with semiaxes equal to its radius . General Types Ellipse Features radius : LengthValue semiMajorAxis : LengthValue {redefines semiMajorAxis} semiMinorAxis : LengthValue {redefines semiMinorAxis} Constraints None. 9.7.3.2.2 CircularCone Element ItemDefinition Description A CircularCone is a Cone with a circular base. General Types Cone Features 554 Systems Modeling Language v2.0, Part 1 -base : CircularDisc {redefines base} radius : LengthValue semiMajorAxis {redefines semiMajorAxis} semiMinorAxis {redefines semiMinorAxis} Constraints None. 9.7.3.2.3 CircularCylinder Element ItemDefinition Description A CircularCylinder is a Cylinder with two circular sides. General Types Cylinder Features af : CircularDisc {redefines af} base : CircularDisc {redefines base} radius : LengthValue semiMajorAxis {redefines semiMajorAxis} semiMinorAxis {redefines semiMinorAxis} Constraints None. 9.7.3.2.4 CircularDisc Element Description A CircularDisc is a Disc bound by a Circle . General Types Disc Features edges : Circle {redefines edges} Systems Modeling Language v2.0, Part 1 555 -radius : LengthValue semiMajorAxis {redefines semiMajorAxis} semiMinorAxis {redefines semiMinorAxis} shape : Circle {redefines shape} Constraints None. 9.7.3.2.5 Cone Element ItemDefinition Description A Cone has one elliptical sides joined to a point by a curved side. General Types ConeOrCylinder Features af [0] {redefines af} apex {subsets vertices} edges [2] {redefines edges} faces [2] {redefines faces} Constraints None. 9.7.3.2.6 ConeOrCylinder Element ItemDefinition Description A ConeOrCylinder is a Cone or a Cylinder with a given elliptical base, height, width (perpendicular distance from the base to the center of the top side or vertex), and offsets of this perpendicular at the base from the center of the base. General Types Shell 556 Systems Modeling Language v2.0, Part 1 -Features ae [0..2] {subsets edges} af : Disc [0..1] {subsets faces} base : Disc {subsets faces} be [2] {subsets edges} cf {subsets faces} edges [2..4] {redefines edges} faces : Surface [2..3] {redefines faces} height : LengthValue semiMajorAxis : LengthValue semiMinorAxis : LengthValue vertices [0..1] {redefines vertices} xoffset : LengthValue yoffset : LengthValue Constraints None. 9.7.3.2.7 ConicSection Element ItemDefinition Description A ConicSection is a closed PlanarCurve , possibly disconnected, see Hyperbola . General Types Path PlanarCurve Features edges [1..2] {redefines edges} isClosed {redefines isClosed} vertices [0] {redefines vertices} Constraints Systems Modeling Language v2.0, Part 1 557 -None. 9.7.3.2.8 ConicSurface Element ItemDefinition Description A ConicSurface is a Surface that has ConicSection cross-sections. General Types Shell Features edges [0] {redefines edges} faces [1..2] {redefines faces} genus {redefines genus} vertices [0] {redefines vertices} Constraints None. 9.7.3.2.9 Cuboid Element ItemDefinition Description A Cuboid is a Polyhedron with six sides, all quadrilateral. General Types CuboidOrTriangularPrism Features edges [24] {redefines edges} faces [6] {redefines faces} ff : Quadrilateral {redefines ff} rf : Quadrilateral {redefines rf} Constraints None. 558 Systems Modeling Language v2.0, Part 1 -9.7.3.2.10 CuboidOrTriangularPrism Element ItemDefinition Description A CuboidOrTriangularPrism is a Polyhedron that is either a Cuboid or TriangularPrism . General Types Polyhedron Features bf : Quadrilateral {subsets faces} bfe [2] {subsets edges} bflv [3] {subsets vertices} bfrv [3] {subsets vertices} bre [2] {subsets edges} brlv [3] {subsets vertices} brrv [3] {subsets vertices} bsle [2] {subsets edges} bsre [2] {subsets edges} edges [0..*] {redefines edges} faces [5..6] {redefines faces} ff : Polygon {subsets faces} rf : Polygon {subsets faces} slf : Quadrilateral {subsets faces} srf : Quadrilateral [0..1] {subsets faces} tf : Quadrilateral {subsets faces} tfe [2] {subsets edges} tflv [3] {subsets vertices} tfrv [0..3] {subsets vertices} tre [2] {subsets edges} trlv [3] {subsets vertices} Systems Modeling Language v2.0, Part 1 559 -trrv [0..3] {subsets vertices} tsle [2] {subsets edges} tsre [0..2] {subsets edges} ufle [2] {subsets edges} ufre [0..2] {subsets edges} urle [2] {subsets edges} urre [0..2] {subsets edges} vertices [24] {redefines vertices} Constraints None. 9.7.3.2.11 Cylinder Element ItemDefinition Description A Cylinder has two elliptical sides joined by a curved side. General Types ConeOrCylinder Features ae [2] {redefines ae} af {redefines af} edges [4] {redefines edges} faces [3] {redefines faces} vertices [0] {redefines vertices} Constraints None. 9.7.3.2.12 Disc Element ItemDefinition Description 560 Systems Modeling Language v2.0, Part 1 -A Disc is a Shell bound by an Ellipse . General Types Shell PlanarSurface Features edges : Ellipse {redefines edges} faces : PlanarSurface {redefines faces} semiMajorAxis : LengthValue semiMinorAxis : LengthValue shape : Ellipse {redefines shape} vertices [0] {redefines vertices} Constraints None. 9.7.3.2.13 EccentricCone Element ItemDefinition Description An EccentricCone is a Cone with least one positive offset. General Types Cone Features None. Constraints None. 9.7.3.2.14 EccentricCylinder Element ItemDefinition Description Systems Modeling Language v2.0, Part 1 561 -An EccentricCylinder is a Cylinder General Types Cylinder Features None. Constraints None. 9.7.3.2.15 Ellipse Element ItemDefinition Description An Ellipse is a ConicSection in the shape of an ellipse of given semiaxes. General Types ConicSection Features edges {redefines edges} semiMajorAxis : LengthValue semiMinorAxis : LengthValue Constraints None. 9.7.3.2.16 Ellipsoid Element ItemDefinition Description An Ellipsoid is a ConicSurface with only elliptical cross-sections. General Types ConicSurface Features 562 Systems Modeling Language v2.0, Part 1 -faces {redefines faces} semiAxis1 : LengthValue semiAxis2 : LengthValue semiAxis3 : LengthValue Constraints None. 9.7.3.2.17 Hyperbola Element ItemDefinition Description A Hyperbola is a planar Path in the shape of a hyperbola with given axes. General Types ConicSection Features conjugateAxis : LengthValue tranverseAxis : LengthValue Constraints None. 9.7.3.2.18 Hyperboloid Element ItemDefinition Description A Hyperboloid is a ConicSurface with only hyperbolic cross-sections. General Types ConicSurface Features conjugateAxis : LengthValue transverseAxis : LengthValue Constraints Systems Modeling Language v2.0, Part 1 563 -None. 9.7.3.2.19 Line Element ItemDefinition Description A Line is a PlanarCurve that is straight. General Types PlanarCurve Features outerSpaceDimension [0..1] {redefines outerSpaceDimension} Constraints None. 9.7.3.2.20 Parabola Element ItemDefinition Description A Parabola is a planar Path in the shape of a parabola of a given focal length. General Types ConicSection Features edges {redefines edges} focalDistance : LengthValue Constraints None. 9.7.3.2.21 Paraboloid Element ItemDefinition Description 564 Systems Modeling Language v2.0, Part 1 -A Paraboloid is a ConicSurface with only parabolic cross-sections. General Types ConicSurface Features faces {redefines faces} focalDistance : LengthValue Constraints None. 9.7.3.2.22 Path Element ItemDefinition Description Path is the most general structured Curve . General Types Item Curve StructuredSpaceObject Features edges [1..*] {redefines edges} faces [0] {redefines faces} vertices {redefines vertices} Constraints None. 9.7.3.2.23 PlanarCurve Element ItemDefinition Description A PlanarCurve is a Curve with a given length embeddable in a plane. Systems Modeling Language v2.0, Part 1 565 -General Types Item Curve Features length : LengthValue outerSpaceDimension [0..1] {redefines outerSpaceDimension} Constraints None. 9.7.3.2.24 PlanarSurface Element ItemDefinition Description A PlanarSurface is a Surface with given area that is flat. General Types Item Surface Features area : LengthValue outerSpaceDimension {redefines outerSpaceDimension} shape : PlanarCurve {redefines shape} Constraints None. 9.7.3.2.25 Polygon Element ItemDefinition Description A Polygon is a closed planar Path with straight edges. General Types Path 566 Systems Modeling Language v2.0, Part 1 -PlanarCurve Features edges : Line {redefines edges} isClosed {redefines isClosed} Constraints None. 9.7.3.2.26 Polyhedron Element ItemDefinition Description A Polyhedron is a closed Shell with polygonal sides. General Types Shell Features edges {redefines edges} faces : Polygon [2..*] {redefines faces} genus {redefines genus} isClosed outerSpaceDimension {redefines outerSpaceDimension} vertices [0..*] {redefines vertices} Constraints None. 9.7.3.2.27 Pyramid Element ItemDefinition Description p>A Pyramid is a Polyhedron with the sides of a polygon (base) forming the bases of triangles that join at an apex point. Its height is the perpindicular distance from the base to the apex, and its offsets are between this perpindicular at the base and the center of the base. Systems Modeling Language v2.0, Part 1 567 -General Types Polyhedron Features apex [0..*] {redefines vertices} base {subsets faces} edges [0..*] {redefines edges} faces [0..*] height : LengthValue wall : Triangle [0..*] {subsets faces} wallNumber : Positive xoffset : LengthValue yoffset : LengthValue Constraints None. 9.7.3.2.28 Quadrilateral Element ItemDefinition Description A Quadrilateral is a four-sided Polygon . General Types Polygon Features e1 e2 e3 edges [4] {redefines edges} v12 [2] {subsets vertices, ordered} v23 [2] {subsets vertices, ordered} v34 [2] {subsets vertices, ordered} 568 Systems Modeling Language v2.0, Part 1 -v41 [2] {subsets vertices, ordered} vertices [8] {redefines vertices} Constraints None. 9.7.3.2.29 Rectangle Element ItemDefinition Description A Rectangle is a Quadrilateral with four right angles and given length and width . General Types Quadrilateral Features length : LengthValue width : LengthValue Constraints None. 9.7.3.2.30 RectangularCuboid Element ItemDefinition Description A RectangularCuboid is a Cuboid with all Rectangular sides. General Types Cuboid Features bf : Rectangle {redefines bf} ff : Rectangle {redefines ff} height : LengthValue length : LengthValue rf : Rectangle {redefines rf} Systems Modeling Language v2.0, Part 1 569 -slf : Rectangle {redefines slf} srf : Rectangle {redefines srf} tf : Rectangle {redefines tf} width : LengthValue Constraints None. 9.7.3.2.31 RectangularPyramid Element ItemDefinition Description A RectangularPyramid is a Pyramid with a rectangular base. General Types Pyramid Features base : Rectangle {redefines base} baseLength : LengthValue baseWidth : LengthValue Constraints None. 9.7.3.2.32 RectangularToroid Element ItemDefinition Description A RectangularToroid is a revolution of a Rectangle . General Types Toriod Features rectangleLength : LengthValue rectangleWidth : LengthValue 570 Systems Modeling Language v2.0, Part 1 -revolvedCurve : Rectangle {redefines revolvedCurve} Constraints None. 9.7.3.2.33 RightCircularCone Element ItemDefinition Description A RightCircularCone is a CircularCone with zero offsets. General Types CircularCone Features xoffset {redefines xoffset} yoffset {redefines yoffset} Constraints None. 9.7.3.2.34 RightCircularCylinder Element ItemDefinition Description A RightCircularCylinder is a CircularCylinder with zero offsets. General Types CircularCylinder Features xoffset {redefines xoffset} yoffset {redefines yoffset} Constraints None. 9.7.3.2.35 RightTriangle Element Systems Modeling Language v2.0, Part 1 571 -ItemDefinition Description A RightTriangle is a Triangle with edges opposite the hypotenuse at right angles. General Types Triangle Features hypotenuse {redefines e3} xoffset {redefines xoffset} Constraints None. 9.7.3.2.36 RightTriangularPrism Element ItemDefinition Description A RightTriangularPrism is a TriangularPrism with two right triangular sides, with given length , width , and height . General Types TriangularPrism Features bf : Rectangle {redefines bf} ff : RightTriangle {redefines ff} height : LengthValue length : LengthValue rf : RightTriangle {redefines rf} slf : Rectangle {redefines slf} tf : Rectangle {redefines tf} width : LengthValue Constraints None. 572 Systems Modeling Language v2.0, Part 1 -9.7.3.2.37 Shell Element ItemDefinition Description Shell is the most general structured Surface . General Types Item StructuredSpaceObject Surface Features None. Constraints None. 9.7.3.2.38 Sphere Element ItemDefinition Description A Sphere is an Ellipsoid with all the same semiaxes. General Types Ellipsoid Features radius : LengthValue semiAxis1 {redefines semiAxis1} semiAxis2 {redefines semiAxis2} semiAxis3 {redefines semiAxis3} Constraints None. 9.7.3.2.39 Tetrahedron Element Systems Modeling Language v2.0, Part 1 573 -ItemDefinition Description A Tetrahedron is Pyramid with a triangular base. General Types Pyramid Features base : Triangle {redefines base} baseLength : LengthValue baseWidth : LengthValue Constraints None. 9.7.3.2.40 Toriod Element ItemDefinition Description A Toroid is a surface generated from revolving a planar closed curve about an line coplanar with the curve. It is single sided with one hole. General Types Shell Features edges [0] {redefines edges} faces {redefines faces} genus {redefines genus} revolutionRadius : LengthValue revolvedCurve : PlanarCurve vertices [0] {redefines vertices} Constraints None. 9.7.3.2.41 Torus 574 Systems Modeling Language v2.0, Part 1 -Element ItemDefinition Description A Torus is a revolution of a Circle . General Types Toriod Features majorRadius {redefines revolutionRadius} minorRadius : LengthValue revolvedCurve : Circle {redefines revolvedCurve} Constraints None. 9.7.3.2.42 Triangle Element ItemDefinition Description A Triangle is three-sided Polygon with given length (base), width (perpindicular distance from base to apex), and offset of this perpindicular at the base from the center of the base. General Types Polygon Features apex [2] {subsets vertices, ordered} base {subsets edges} e2 {subsets edges} e3 {subsets edges} edges [3] {redefines edges} length : LengthValue v12 [2] {subsets vertices, ordered} v31 [2] {subsets vertices, ordered} Systems Modeling Language v2.0, Part 1 575 -vertices [6] {redefines vertices} width : LengthValue xoffset : LengthValue Constraints None. 9.7.3.2.43 TriangularPrism Element ItemDefinition Description A TriangularPrism is a Polyhedron with five sides, two triangular and the others quadrilateral. General Types CuboidOrTriangularPrism Features edges [18] {redefines edges} faces [5] {redefines faces} ff : Triangle {redefines ff} rf : Triangle {redefines rf} Constraints None. 9.8 Quantities and Units Domain Library 9.8.1 Quantities and Units Domain Library Overview For any system model, a solid foundation for the representation of physical quantities, their units, scales, and quantity dimensions, as well as coordinate frames is essential. Quantity attributes are needed to specify many characteristics of a system of interest and its elements. The foundation should be a shareable resource that can be reused in models within and across projects as well as organizations in order to facilitate collaboration and model interoperability. The Quantities and Units Domain Library defines reusable and extensible model elements for physical quantities, including vector and tensor quantities, quantity dimensions, measurement units, measurement scales, coordinate frames, coordinate transformations and vector spaces. The library also enables the specification of coherent systems of quantities and systems of units, as well as the operators and functions needed to support quantity arithmetic in expressions. The most widely accepted, scrutinized, and globally used specification of quantities and units is captured and maintained in: 576 Systems Modeling Language v2.0, Part 1 -• the International System of Quantities (ISQ) • the International System of Units (SI) The ISQ and SI are formally standardized through the ISO/IEC 80000 series of standards. The top level concepts and semantics defined in this domain library are derived from and mapped to the concepts and semantics specified in [ISO 80000-1] and [VIM], as directly as possible, but staying at a generic level. This enables the representation of the ISQ and the SI, but also of any other system of quantities or system of units. The data model specifies a precise representation of the relationships between quantities, units, scales, quantity dimensions, coordinate frames, coordinate transformations and vectors spaces. As a result, both robust automated conversion between quantity values expressed in compatible measurement units or scales is enabled, as well as static type and quantity dimension analysis of expressions and constraints. This library further contains lower level packages that specify the actual quantities, units and scales as standardized in parts 3 to 13 of the ISO/IEC 80000 series as SysML AttributeDefinitions and AttributeUsages , that represent the complete ISQ and SI. These packages provide a broad common basis, that can be extended and tailored for use by particular communities of practice and industry sectors. Apart from SI, the system of US Customary Units is still in wide industrial use, in particular in North America. The library therefore also contains a package of US Customary Units, as specified in [NIST SP-811], and including their relationships with ISQ quantities as well as the conversion factors to corresponding SI units. 9.8.2 Quantities 9.8.2.1 Quantities Overview Taxonomy The Quantities package defines the root elements to represent quantities and their values. TensorQuantityValue (an AttributeDefinition ) and tensorQuantities (an AttributeUsage ) are th defined to represent quantities at the most general level, and can represent any n order tensor quantity. Then, VectorQuantityValue and vectorQuantities are defined as order 1 specializations of the tensor quantity concepts, and finally, ScalarQuantityValue and scalarQuantities as order 0 specializations of the vector quantity concepts. Quantity Values A quantity value is defined as a tuple of: • a sequence of one or more mathematical numbers (as AttributeUsage num ), • a measurement reference (as AttributeUsage mRef ). For a ScalarQuantityValue , the sequence of numbers collapses to one single number, and the measurement reference is typically a measurement unit or scale. For a VectorQuantityValue , there must be as many numbers as needed to define the magnitude and direction of the vector quantity, and a measurement reference that typically specifies a coordinate frame, e.g., a sequence of 3 numbers for the vector components in a standard orthonormal Cartesian 3D vector space with the same measurement unit on each of the axes. For a TensorQuantityValue , the measurement reference must establish a reference frame compliant with the full dimensionality of the tensor quantity involved. Note. The specification of a quantity value as a tuple of its numerical value and a measurement reference has the big advantage that the type of a quantity value becomes independent from the choice of measurement reference. For example: a power expressed as 1.5 watt has the same type ( AttributeDefinition PowerValue ) as a power expressed as 1500 milliwatt. This is an improvement over SysML v1, where the choice of measurement unit or scale was embedded in the value property type. Systems Modeling Language v2.0, Part 1 577 -Free versus Bound Quantities and Vector Spaces A TensorQuantityValue can be defined with respect to a free vector space product or a bound vector space product. Similarly, a VectorQuantityValue can be defined with respect to a free or a bound vector space, and a ScalarQuantityValue with respect to a free or bound number line, which can be regarded as a one-dimensional vector space. In a free vector space, vectors can be added and vectors can be multiplied by a scalar number, where both operations yield a new free vector. Free vectors have only magnitude and direction. A bound vector space includes a particular choice of origin, and vectors in such a space can not be added nor multiplied by scalars. AttributeUsage isBound is used to capture this: false specifies a free vector space (product), and true specifies a bound vector space (product). Examples that (informally) illustrate the distinction between free and bound vector quantities are given by pairs of quantities of the same quantity dimension: 1. Displacement vector (free) and position vector (bound), both of quantity dimension length. Two displacement vectors can be added and yield a resulting displacement vector. A displacement vector can also be multiplied with a scalar factor, which changes only its magnitude. Two position vectors can not be added, nor can a position vector be multiplied by a scalar number. A position vector is always bound to the origin of its bound vector space. One can however subtract one position vector from another, and the result is a displacement vector. It is the displacement to get from the position defined by the first vector to that defined by the second vector. 2. Duration (free scalar) and time instant (bound scalar), both of quantity dimension time. Durations can be added and multiplied, time instants cannot. Time instant values can only be specified with respect to a measurement reference that is a time scale with some particular choice of zero. Such a time scale is the same as a (time) coordinate axis in a one-dimensional bound vector space. 9.8.2.2 Elements 9.8.2.2.1 3dVectorQuantityValue Element AttributeDefinition Description Most general representation of real 3-vector quantities. Alias: ThreeDVectorQuantityValue General Types VectorQuantityValue Features num : Real [3] {redefines num} Constraints None. 9.8.2.2.2 QuantityDimension Element AttributeDefinition 578 Systems Modeling Language v2.0, Part 1 -Description A QuantityDimension is the product of powers of the set of base quantities defined for a particular system of quantities, units and scales. General Types None. Features quantityPowerFactors : QuantityPowerFactor [0..*] {ordered} Constraints None. 9.8.2.2.3 QuantityPowerFactor Element AttributeDefinition Description A QuantityPowerFactor is a representation of a quantity power factor, being the combination of a quantity and an exponent. A sequence of QuantityPowerFactors for the baseQuantities of a SystemOfQuantities define the QuantityDimension of a scalar quantity. General Types None. Features exponent : Real quantity : ScalarQuantityValue Constraints None. 9.8.2.2.4 scalarQuantities Element AttributeUsage Description AttributeUsage scalarQuantities : ScalarQuantityValue[*] nonunique is the subset of vectorQuantities that defines a top-level general self-standing attribute that can be used to consistently specify scalar quantities of Occurrences . Systems Modeling Language v2.0, Part 1 579 -Any particular scalar quantity attribute is specified by subsetting scalarQuantities . In other words, the co- domain of a scalar quantity attribute is a suitable specialization of ScalarQuantityValue . General Types ScalarQuantityValue vectorQuantities Features None. Constraints None. 9.8.2.2.5 ScalarQuantityValue Element AttributeDefinition Description A ScalarQuantityValue is an abstract AttributeDefinition that specializes VectorQuantityValue . It represents a scalar quantity value as a tuple of a Number num and a ScalarMeasurementReference mRef . By definition it has order zero. The ScalarMeasurementReference is typically a MeasurementUnit or a MeasurementScale MeasurementUnitMeasurementScale . General Types NumericalValue VectorQuantityValue Features mRef : ScalarMeasurementReference {redefines mRef} Specification of the ScalarMeasurementReference for the value of the scalar quantity. Constraints oneElement dimensions[1] == 1 9.8.2.2.6 SystemOfQuantities Element AttributeDefinition Description 580 Systems Modeling Language v2.0, Part 1 -A SystemOfQuantities represents the essentials of [VIM] concept "system of quantities" (https://jcgm.bipm.org/ vim/en/1.3.html), defined as a "set of quantities together with a set of noncontradictory equations relating those quantities". In order to establish such a set of noncontradictory equations a set of baseQuantities is selected. Subsequently the system of quantities is completed by adding derived quantities which are products of powers of the base quantities. General Types None. Features baseQuantities : ScalarQuantityValue [0..*] {ordered} Constraints None. 9.8.2.2.7 tensorQuantities Element AttributeUsage Description AttributeUsage tensorQuantities : TensorQuantityValue[*] nonunique defines a top-level general self-standing attribute that can be used to consistently specify quantities of Occurrences . Any particular tensor quantity attribute is specified by subsetting tensorQuantities . In other words, the co- domain of a tensor quantity attribute is a suitable specialization of TensorQuantityValue . General Types dataValues TensorQuantityValue Features None. Constraints None. 9.8.2.2.8 TensorQuantityValue Element AttributeDefinition Description A TensorQuantityValue is an abstract AttributeDefinition and a specialization of Collections::Array that represents a tensor quantity value as a sequence of Numbers and a TensorMeasurementReference . Systems Modeling Language v2.0, Part 1 581 -The dimensionality of the tensor quantity is specified in dimensions , from which the order of the tensor is derived. In engineering the name 'tensor' is typically used if its order is 2 or greater, but mathematically a tensor can have order 0 or 1. A TensorQuantityValue must have the same dimensions and order as the TensorMeasurementReference that it references via AttributeUsage mRef . It is possible to specify the contravariant and covariant order of a tensor quantity through the AttributeUsages contravariantOrder and covariantOrder , the sum of which must be equal to order . In applications where it is not important to distinguish between contravariant and covariant tensors (or vectors), the convention is to use contravariant by default and therefore set contravariantOrder equal to order , and covariantOrder equal to zero. General Types Array Features contravariantOrder : Positive The number of contravariant indices of the tensor quantity. covariantOrder : Positive The number of covariant indices of the tensor quantity. dimensions : Positive [0..*] {redefines dimensions, ordered, nonunique} A sequence of positive integer numbers that define the dimensionality of the tensor quantity. Examples: for a second order 3D tensor dimensions = (3, 3); for fourth order 2D tensor dimensions = (2, 2, 2, 2); The dimensions must be the same as the dimensions of the associated mRef . isBound : Boolean Assertion whether this tensor quantity is defined in a free ( isBound == false ) or bound ( isBound == true ) vector space product. mRef : TensorMeasurementReference Specification of the TensorMeasurementReference for the value of the tensor quantity. num : Number [1..*] {redefines elements, ordered, nonunique} Sequence of numbers that specify the numerical value of the tensor quantity. order : Natural {redefines rank} Order of the tensor quantity. The order is equal to the order of the associated TensorMeasurementReference mRef . Constraints 582 Systems Modeling Language v2.0, Part 1 -boundMatch (isBound == mRef.isBound) or (not isBound and mRef.isBound) orderSum contravariantOrder + covariantOrder == order 9.8.2.2.9 vectorQuantities Element AttributeUsage Description AttributeUsage vectorQuantities : VectorQuantityValue[*] nonunique is the subset of tensorQuantities that defines a top-level general self-standing attribute that can be used to consistently specify vector quantities of Occurrences . Any particular vector quantity attribute is specified by subsetting vectorQuantities . In other words, the co- domain of a vector quantity attribute is a suitable specialization of VectorQuantityValue . General Types tensorQuantities VectorQuantityValue Features None. Constraints None. 9.8.2.2.10 VectorQuantityValue Element AttributeDefinition Description A VectorQuantityValue is an AttributeDefinition that represents the value of a vector quantity by a tuple of Numbers and a VectorMeasurementReference . It is a specialization of TensorQuantityValue and has order one. A VectorQuantityValue can be free ( isBound == false ) or bound ( isBound == true ). A value of a free vector quantity is expressed using a free VectorMeasurementReference , in which there is no particular choice of zero or origin. A value of a bound vector quantity is expressed using a bound VectorMeasurementReference that includes a specified choice of origin. In both cases the VectorMeasurementReference typically defines a coordinate system. General Types Systems Modeling Language v2.0, Part 1 583 -NumericalVectorValue TensorQuantityValue Features mRef : VectorMeasurementReference {redefines mRef} Specification of the VectorMeasurementReference for the value of the vector quantity. Constraints [no name] order == 1 9.8.3 Measurement References 9.8.3.1 Measurement References Overview This package defines the general AttributeDefinitions and AttributeUsages to construct measurement references. This includes: • measurement units, • ordinal, logarithmic and cyclic measurement scales, • unit conversions, • coordinate frames and coordinate transformations, • measurement unit prefixes to denote multiples (such as mega ) and sub-multiples (such as nano ). It also defines concepts to represent quantity dimensions, which form the basis for dimensional analysis of quantity expressions. 9.8.3.2 Elements 9.8.3.2.1 3dCoordinateFrame Element AttributeDefinition Description General Types CoordinateFrame Features dimensions : Positive {redefines dimensions} Constraints None. 9.8.3.2.2 AffineTransformationMatrix3d Element 584 Systems Modeling Language v2.0, Part 1 -AttributeDefinition Description AffineTransformationMatrix3d is a three dimensional CoordinateTransformation specified via an affine 4x4 transformation matrix The interpretation of the matrix is as follows: • The upper left 3x3 matrix represents the rotation matrix. • The upper right 3x1 column vector represents the translation vector. • The bottom row must be the row vector (0, 0, 0, 1). I.e. the matrix has the following form: ( R, R, R, T, R, R, R, T, R, R, R, T, 0, 0, 0, 1 ) where the cells marked R form the rotation matrix and the cells marked T form the translation vector. Note: See https://en.wikipedia.org/wiki/Transformation_matrix, under affine transformations for a general explanation. General Types Array CoordinateTransformation Features dimensions : Positive [0..*] {redefines dimensions, ordered, nonunique} The dimensions of an AffineTransformationMatric3d are (4,4) . elements : Real [16] {redefines elements, ordered, nonunique} Constraints validSourceDimensions source.dimensions == 3 9.8.3.2.3 ConversionByConvention Element AttributeDefinition Description ConversionByConvention is a UnitConversion that is defined according to some convention. Systems Modeling Language v2.0, Part 1 585 -An example is the conversion relationship between "foot" (the owning MeasurementUnit ) and "metre" (the referenceUnit MeasurementUnit ), with conversionFactor 3048/10000, since 1 foot = 0.3048 metre, as defined in [NIST SP-811]. General Types UnitConversion Features None. Constraints None. 9.8.3.2.4 ConversionByPrefix Element AttributeDefinition Description ConversionByPrefix is a UnitConversion that is defined through reference to a named [ISO/IEC 80000-1] UnitPrefix , which represents a conversion factor that is a decimal or binary multiple or sub-multiple. Example 1: "kilometre" ( symbol "km") with the 'kilo' UnitPrefix denoting conversion factor 1000 and referenceUnit "metre". Example 2: "nanofarad" ( symbol "nF") with the 'nano' UnitPrefix denoting conversion factor 1E-9 and referenceUnit "farad". Example 3: "mebibyte" ( symbol "MiB" or alias "MiByte") with the 'mebi' UnitPrefix denoting conversion factor 1024^2 (a binary multiple) and referenceUnit "byte". See also SIPrefixes . General Types UnitConversion Features conversionFactor : Real {redefines conversionFactor} The Number value of the ratio between the quantity expressed in the owning MeasurementUnit over the quantity expressed in the referenceUnit . prefix : UnitPrefix A UnitPrefix that represents one of the named unit prefixes defined in [ISO/IEC 80000-1] as a decimal or binary multiple or sub-multiple. Constraints 586 Systems Modeling Language v2.0, Part 1 -None. 9.8.3.2.5 CoordinateFrame Element AttributeDefinition Description A CoordinateFrame is a VectorMeasurementReference with the specific purpose to quantify (i.e., coordinatize) a vector space, and optionally locate and orient it with respect to another CoordinateFrame . The optional attribute transformation enables specification of the location and orientation of this CoordinateFrame as with respect to another (reference) CoordinateFrame . If the target of the transformation is this CoordinateFrame , the transformation specifies a CoordinateFrame that is nested inside the CoordinateFrame that is the source of the transformation . The primary use of this is to specify a chain of nested coordinate frames follows the composite structure of a physical architecture. Typically the source CoordinateFrame of the transformation is the frame is the frame of the next higher containing Item or Part in a composite structure. General Types VectorMeasurementReference Features transformation : CoordinateTransformation [0..1] Constraints None. 9.8.3.2.6 CoordinateFramePlacement Element AttributeDefinition Description CoordinateFramePlacement is a CoordinateTransformation by placement of the target frame in the source frame. Attribute origin specifies the location of the origin of the target frame through a vector in the source frame. Attribute basisDirections specifies the orientation of the target frame by specifying the directions of the respective basis vectors of the target frame via direction vectors in the source frame. An empty sequence of basisDirections signifies no change of orientation of the target frame with respect to the source frame. General Types CoordinateTransformation Features basisDirections : VectorQuantityValue [0..*] {ordered, nonunique} origin : VectorQuantityValue Systems Modeling Language v2.0, Part 1 587 -Constraints validBasisDirectionsDimensions basisDirections->forAll { in basisDirection : VectorQuantityValue; basisDirection.dimensions->equals(source.dimensions) validBasisDirectionsSize size(basisDirections) == 0 or size(basisDirections) == source.dimensions#(1) validOriginDimensions origin.dimensions == source.dimensions 9.8.3.2.7 CoordinateTransformation Element AttributeDefinition Description A CoordinateTransformation is an AttributeDefinition that defines the transformation relationship between two coordinate systems, that are represented by VectorMeasurementReferences , typically CoordinateFrames . General Types None. Features source : VectorMeasurementReference target : VectorMeasurementReference Constraints [no name] forall(bd: basisDirections | bd.mRef == source) [no name] size(basisDirections) == source.dimensions[1] [no name] origin.mRef == source validSourceTargetDimensions source.dimensions == target.dimensions 9.8.3.2.8 countQuantities Element 588 Systems Modeling Language v2.0, Part 1 -AttributeUsage Description General Types dimensionOneQuantities CountValue Features None. Constraints None. 9.8.3.2.9 CountValue Element AttributeDefinition Description CountValue is an explicit definition of a generic "count" quantity as a DimensionOneValue . General Types DimensionOneValue Features None. Constraints None. 9.8.3.2.10 CyclicRatioScale Element AttributeDefinition Description CyclicRationScale is a MeasurementScale that represents a ratio scale with a periodic cycle. Example 1: "cyclic degree" (to express planar angular measures) with modulus 360 and unit 'degree'. Example 2: "hour of day" with modulus 24 and unit 'hour'. General Types Systems Modeling Language v2.0, Part 1 589 -MeasurementScale Features modulus : Number Attribute modulus is a Number that defines the modulus, i.e. periodic cycle, of this CyclicRatioScale. Constraints None. 9.8.3.2.11 DefinitionalQuantityValue Element AttributeDefinition Description A DefinitionalQuantityValue is a representation of a particular quantity value that is used in the definition of a MeasurementReference . Typically such a particular value is defined by convention. It can be used to define a selected reference value, such as the meaning of zero on a measurement scale or the origin of a top-level coordinate system. General Types None. Features definition : String num : Number [1..*] Constraints None. 9.8.3.2.12 DerivedUnit Element AttributeDefinition Description DerivedUnit is a MeasurementUnit that represents a measurement unit that depends on one or more powers of other measurement units. General Types MeasurementUnit Features 590 Systems Modeling Language v2.0, Part 1 -None. Constraints None. 9.8.3.2.13 dimensionOneQuantities Element AttributeUsage Description General Types DimensionOneValue scalarQuantities Features None. Constraints None. 9.8.3.2.14 DimensionOneUnit Element AttributeDefinition Description DimensionOneUnit is an explicit definition of "unit of dimension one", also known as "dimensionless unit". General Types DerivedUnit Features unitPowerFactors : UnitPowerFactor [0] Constraints None. 9.8.3.2.15 DimensionOneValue Element AttributeDefinition Description Systems Modeling Language v2.0, Part 1 591 -A DimensionOneValue is a ScalarQuantityValue with a DimensionOneUnit . General Types ScalarQuantityValue Features mRef : DimensionOneUnit {redefines mRef} Constraints None. 9.8.3.2.16 IntervalScale Element AttributeDefinition Description IntervalScale is a MeasurementScale that represents a linear interval measurement scale, i.e. a scale on which only intervals between two values are meaningful and not their ratios. Implementation note: In order to enable quantity value conversion between an IntervalScale and another MeasurementScale , the offset (sometimes also called zero shift) between the source and target scales must be known. This offset can be indirectly defined through a QuantityValueMapping , see quanityValueMapping of MeasurementScale . This will be aligned with, and possibly replaced by, a 1D coordinate transformation, so that scalar and vector transformations are handled in the same way. General Types MeasurementScale Features isBound : Boolean {redefines isBound} For an IntervalScale isBound is always true , since the scale must include a definition of what zero means. Constraints None. 9.8.3.2.17 LogarithmicScale Element AttributeDefinition Description LogarithmicScale is a MeasurementScale that represents a logarithmic measurement scale that is defined as follows. The numeric value v of a ratio quantity expressed on a logarithmic scale equivalent with a value x of the same quantity expressed on a ratio scale (i.e. only using a MeasurementUnit ) is computed as follows: 592 Systems Modeling Language v2.0, Part 1 -\(v = f \cdot \log_b (x/x_{ref})^a \) where: \(f\) is a multiplication factor, \(\log_b\) is the log function for the given logarithm base \(b\), \(x\) is the actual quantity, \(x_{ref}\) is a reference quantity, \(a\) is an exponent. General Types MeasurementScale Features exponent : Number The exponent \(a\) in the logarithmic value expression. factor : Number The multiplication factor \(f\) in the logarithmic value expression. logarithmBase : Number A Number that specifies the logarithmic base. The logarithmicBase is typically 10, 2 or e (for the natural logarithm). referenceQuantity : ScalarQuantityValue [0..1] The reference quantity value (denominator) \(x_{ref}\) in the logarithmic value expression. Constraints None. 9.8.3.2.18 MeasurementScale Element AttributeDefinition Description MeasurementScale is a MeasurementReference that represents a measurement scale. Note: the majority of scalar quantities can be expressed by just using a MeasurementUnit directly as its MeasurementReference . This implies expression of a ScalarQuantityValue on a ratio scale. However, for full coverage of all quantity value expressions, additional explicit measurement scales with additional semantics are needed, such as ordinal scale, interval scale, ratio scale with additional limit values, cyclic ratio scale and logarithmic scale. General Types ScalarMeasurementReference Features quantityValueMapping : QuantityValueMapping [0..1] Systems Modeling Language v2.0, Part 1 593 -An optional QuantityValueMapping that specifies the relationship between this MeasurementScale and another MeasurementReference in terms of equivalent QuantityValues . unit : MeasurementUnit The MeasurementUnit that defines an interval of one on this MeasurementScale . Constraints None. 9.8.3.2.19 MeasurementUnit Element AttributeDefinition Description A MeasurementUnit is a ScalarMeasurementReference that represents a measurement unit. As defined in [VIM] a measurement unit is a "real scalar quantity, defined and adopted by convention, with which any other quantity of the same kind can be compared to express the ratio of the two quantities as a number". Direct use of a MeasurementUnit as the mRef attribute of a ScalarQuantitiyValue , establishes expressing the ScalarQuantitiyValue on a ratio scale. General Types ScalarMeasurementReference Features isBound : Boolean {redefines isBound} isBound is always false for a MeasurementUnit . unitConversion : UnitConversion [0..1] Optional UnitConversion that specifies a linear conversion relationship with respect to another MeasurementUnit . This can be used to support automated quantity value conversion. unitPowerFactors : UnitPowerFactor [1..*] {ordered} A product of powers of base units, that define the quantity dimension of this measurement unit. Constraints None. 9.8.3.2.20 NullTransformation Element AttributeDefinition Description 594 Systems Modeling Language v2.0, Part 1 -NullTransformation is an AffineTransformationMatrix3d that places the target CoordinateFrame at the same position and orientation as the source CoordinateFrame . The interpretation of the matrix is as follows: • The rotation matrix is diagonal, with 1 as values. • The translation vector is all zeros. I.e. the matrix has the following form: ( 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1 ) General Types AffineTransformationMatrix3d Features None. Constraints None. 9.8.3.2.21 nullTransformation Element AttributeUsage Description General Types NullTransformation Features None. Constraints None. 9.8.3.2.22 one Element AttributeUsage Description General Types Systems Modeling Language v2.0, Part 1 595 -DimensionOneUnit Features None. Constraints None. 9.8.3.2.23 OrdinalScale Element AttributeDefinition Description An OrdinalScale is a MeasurementScale that represents an ordinal measurement scale, i.e. a scale on which only the ordering of quantity values is meaningful, not the intervals between any pair of values and neither their ratio. Note: In order to keep the library simple the associated unit of an OrdinalScale shall be set to the unit of dimension one, although a unit is meaningless for an OrdinalScale . Implementation note: The unit attribute of MeasurementScale should be made optional, and its multiplicity be redefined in the specialization of MeasurementScale . General Types MeasurementScale Features None. Constraints None. 9.8.3.2.24 QuantityValueMapping Element AttributeDefinition Description QuantityValueMapping is an AttributeDefinition that represents the mapping of equivalent quantity values expressed on two different measurement scales. Example: The mapping between the temperature value of 0.01 degree Celsius on the celsius temperature scale to the equivalent temperature value of 273.16 K on the kelvin temperature scale, would specify a mappedQuantityValue referencing the DefinitionalQuantityValue (0.01, "absolute thermodynamic temperature of the triple point of water") of the celsius interval scale, and a referenceQuantityValue referencing the 596 Systems Modeling Language v2.0, Part 1 -DefinitionalQuantityValue (273.16, "absolute thermodynamic temperature of the triple point of water") of the kelvin ratio scale. General Types None. Features mappedQuantityValue : DefinitionalQuantityValue referenceQuantityValue : DefinitionalQuantityValue Constraints None. 9.8.3.2.25 Rotation Element AttributeDefinition Description Representation of a rotation about an axis over an angle. Attribute axisDirection specifies the direction of the rotation axis. Attribute angle specifies the angle of rotation, where a positive value implies right-handed rotation. Attribute isIntrinsic asserts whether the intermediate coordinate frame moves with the rotation or not, i.e. whether an instrinsic or extrinsic rotation is specified. See https://en.wikipedia.org/wiki/Davenport_chained_rotations for details. General Types TranslationOrRotation Features angle : AngularMeasureValue axisDirection : VectorQuantityValue isIntrinsic : Boolean Default is true . Constraints None. 9.8.3.2.26 ScalarMeasurementReference Element Systems Modeling Language v2.0, Part 1 597 -AttributeDefinition Description A ScalarMeasurementReference is a specialization of VectorMeasurementReference . It represents a single measurement reference for a ScalarQuantityValue or for a component of a tensor or vector quantity. Its order is zero. ScalarMeasurementReference is also a generalization of MeasurementUnit and MeasurementScale , which in turn can be regarded as the basis vector for respectively a free or bound scalar quantity. It establishes how to interpret the num numerical value of a ScalarQuantityValue or a component of a tensor or vector quantity value, and establishes its actual quantity dimension. General Types VectorMeasurementReference Features dimensions : Positive [0..1] {redefines dimensions, ordered, nonunique} isOrthogonal : Boolean {redefines isOrthogonal} A ScalarMeasurementReference always has isOrthogonal = true . mRefs : ScalarMeasurementReference [1..*] {redefines mRefs, ordered} negativeValueConnotation : String [0..1] Optionally specifies the connotation of negative quantity values for this ScalarMeasurementReference . An example is "east" for positive values on the MeasurementReference ( CyclicRatioScale ) for "longitude" and "west" for negative values. positiveValueConnotation : String [0..1] Optionally specifies the connotation of positive quantity values for this ScalarMeasurementReference . An example is "east" for positive values on the MeasurementReference ( CyclicRatioScale ) for "longitude" and "west" for negative values. quantityDimension : QuantityDimension Constraints None. 9.8.3.2.27 SimpleUnit Element AttributeDefinition Description SimpleUnit is a MeasurementUnit that does not depend on any other measurement unit. Note: As a consequence the unitPowerFactor of a SimpleUnit references itself with an exponent of one. 598 Systems Modeling Language v2.0, Part 1 -General Types MeasurementUnit Features unitPowerFactors : UnitPowerFactor {redefines unitPowerFactors} Constraints exponentIsOne this.unitPowerFactor1.exponent == 1 ExponentIsOne self.unitPowerFactor.exponent = 1 9.8.3.2.28 SystemOfUnits Element AttributeDefinition Description A SystemOfUnits represents the essentials of [VIM] concept "system of units" (https://jcgm.bipm.org/vim/en/ 1.13.html), defined as a "set of base units and derived units, together with their multiples and submultiples, defined in accordance with given rules, for a given system of quantities". The baseUnits are a particular selection of measurement units for each of the base quantities of a SystemOfQuantities , that form the basis on top of which all other (derived) units are defined. General Types None. Features baseUnits : SimpleUnit [1..*] {ordered} longName : String systemOfQuantities : SystemOfQuantities Constraints None. 9.8.3.2.29 TensorMeasurementReference Element AttributeDefinition Description Systems Modeling Language v2.0, Part 1 599 -A TensorMeasurementReference is an abstract AttributeDefinition and a specialization of Collections::Array , that represents the [VIM] concept measurement reference, but generalized for tensor, vector and scalar quantities. [VIM] defines measurement reference as a measurement unit, a measurement procedure, a reference material, or a combination of such. In this generalized definition, the measurement references for all components in all dimensions of the QuantityValue are specified through the mRefs attribute, which are all ScalarMeasurementReferences . As an example a Cartesian 3-dimensional 3x3 moment of inertia tensor would have the following attributes: attribute def Cartesian3dMomentOfInertiaMeasurementReference :> TensorMeasurementReference { attribute :>> dimensions = (3, 3); attribute :>> isBound = false; attribute :>> mRefs: MomentOfInertiaUnit[9]; } The shortName of a TensorMeasurementReference is the unique symbol by which the measurement reference is known. The name of a TensorMeasurementReference is spelled-out human readable name of the measurement reference. General Types Array Features definitionalQuantityValues : DefinitionalQuantityValue [0..*] isBound : Boolean Default is false . mRefs : ScalarMeasurementReference [1..*] {redefines elements, ordered, nonunique} order : Natural {redefines rank} Constraints None. 9.8.3.2.30 Translation Element AttributeDefinition Description Representation of a translation with respect to a coordinate frame. Attribute translationVector specifies the displacement vector that constitutes the translation. General Types TranslationOrRotation 600 Systems Modeling Language v2.0, Part 1 -Features translationVector : VectorQuantityValue Constraints None. 9.8.3.2.31 TranslationOrRotation Element AttributeDefinition Description TranslationOrRotation is an abstract union of Translation and Rotation General Types None. Features None. Constraints None. 9.8.3.2.32 TranslationRotationSequence Element AttributeDefinition Description A TranslationRotationSequence is a coordinate frame transformation specified by a sequence of translations and/or rotations. Note: This is a CoordinateTransformation that is convenient for interpretation by humans. In particular a sequence of rotations about the principal axes of a coordinate frame is much more easy understandable than a rotation about an arbitrary axis. Any sequence can be reduced to a single combination of a translation and a rotation about a particular axis, but in general the original sequence cannot be retrieved as there are infinitely many sequences representing the reduced transformation. General Types List CoordinateTransformation Features elements : TranslationOrRotation [1..*] {redefines elements, ordered, nonunique} Systems Modeling Language v2.0, Part 1 601 -Constraints None. 9.8.3.2.33 UnitConversion Element AttributeDefinition Description UnitConversion is an AttributeDefinition that represents a linear conversion relationship between one measurement unit and another measurement unit, that acts as a reference. General Types None. Features conversionFactor : Real The Real value of the ratio between the quantity expressed in the owning MeasurementUnit over the quantity expressed in the referenceUnit . isExact : Boolean Default is true . referenceUnit : MeasurementUnit Establishes the reference MeasurementUnit with respect to which this UnitConversion is defined. Constraints None. 9.8.3.2.34 UnitPowerFactor Element AttributeDefinition Description UnitPowerFactor is an AttributeDefinition that represents a power factor of a MeasurementUnit and an exponent. Note: A collection of UnitPowerFactors defines a unit power product. General Types None. Features 602 Systems Modeling Language v2.0, Part 1 -exponent : Real A Real that specifies the exponent of this UnitPowerFactor . unit : MeasurementUnit The MeasurementUnit of this UnitPowerFactor . Constraints None. 9.8.3.2.35 UnitPrefix Element AttributeDefinition Description UnitPrefix is an AttributeDefinition that represents a named multiple or sub-multiple measurement unit prefix as defined in ISO/IEC 80000-1. General Types None. Features conversionFactor : Real A Real that specifies the value of multiple or sub-multiple of this UnitPrefix . longName : String symbol : String The short symbolic name of this UnitPrefix . Examples are: "k" for "kilo", "m" for "milli", "MeBi" for "mega binary". Constraints None. 9.8.3.2.36 VectorMeasurementReference Element AttributeDefinition Description A VectorMeasurementReference is a specialization of TensorMeasurementReference for vector quantities that are typed by a VectorQuantityValue . Its order is typically one, but can be zero in case of a specialization to ScalarMeasurementReference . It implicitly defines a vector space of dimension N equal to Systems Modeling Language v2.0, Part 1 603 -dimensions[1] . The N basis unit vectors that span the vector space are defined by the mRefs which each are a ScalarMeasurementReference , typically a MeasurementUnit or an IntervalScale . It is possible to specify purely symbolic vector spaces, without committing to particular measurement units or scales by setting the measurement references for all dimensions to unit one and quantity of dimension one, thereby basically reverting to the representation of a purely mathematical vector space. A VectorMeasurementReference can be used to represent a coordinate frame for a vector space. See the CoordinateFrame specialization. The attribute isOrthogonal indicates whether the inner products of the basis vectors of the vector space specified by are orthogonal or not. General Types TensorMeasurementReference Features dimensions : Positive [0..1] {redefines dimensions} isOrthogonal : Boolean Constraints placementCheck size(placement) == 0 | placement.target == self 9.8.4 ISQ 9.8.4.1 ISQ Overview The ISQ package specifies a complete set of predefined quantity types for the International System of Quantities (ISQ). The ISQ itself is specified as a SystemOfQuantities . The quantity types are specified as specializations of TensorQuantityValue , VectorQuantityValue , ScalarQuantityValue , that capture all quantities defined in ISO/IEC 80000 parts 3 to 13. It also defines all TensorMeasurementReference , VectorMeasurementReference and ScalarMeasurementReference specializations needed to define concrete MeasurementReference AttributeDefinitions needed to specify the actual measurement units and scales, coordinate frames and vector space products in other library packages. The ISQ package comprises the following sub-packages via import: • ISQBase for ISO/IEC 80000 base quantities and general concepts • ISQSpaceTime for [ISO 80000-3] "Space and Time" • ISQMechanics for [ISO 80000-4] "Mechanics" • ISQThermodynamics for [ISO 80000-5] "Thermodynamics" • ISQElectromagnetism for [IEC 80000-6] "Electromagnetism" • ISQLight for [ISO 80000-7] "Light" • ISQAcoustics for [ISO 80000-8] "Acoustics" • ISQChemistryMolecular for [ISO 80000-9] "Physical chemistry and molecular physics" • ISQAtomicNuclear for [ISO 80000-10] "Atomic and nuclear physics" • ISQCharacteristicNumbers for [ISO 80000-11] "Characteristic numbers" • ISQCondensedMatter for [ISO 80000-12] "Condensed matter physics" • ISQInformation for [IEC 80000-13] "Information science and technology" 604 Systems Modeling Language v2.0, Part 1 -Since package ISQ imports all other sub-packages, the statement import ISQ::*; suffices to make the whole ISQ available in a user model. 9.8.4.2 Elements 9.8.4.2.1 amountOfSubstance Element AttributeUsage Description General Types AmountOfSubstanceValue scalarQuantities Features None. Constraints None. 9.8.4.2.2 AmountOfSubstanceUnit Element AttributeDefinition Description General Types SimpleUnit Features None. Constraints None. 9.8.4.2.3 AmountOfSubstanceValue Element AttributeDefinition Description General Types Systems Modeling Language v2.0, Part 1 605 -ScalarQuantityValue Features mRef : AmountOfSubstanceUnit {redefines mRef} num : Real {redefines num} Constraints None. 9.8.4.2.4 AngularMeasureValue Element Description General Types None. Features None. Constraints None. 9.8.4.2.5 Cartesian3dSpatialCoordinateFrame Element AttributeDefinition Description General Types Spatial3dCoordinateFrame Features isOrthogonal : Boolean {redefines isOrthogonal} mRefs : LengthValue [3] {redefines mRefs} xUnit : LengthUnit yUnit : LengthUnit zUnit : LengthUnit Constraints None. 606 Systems Modeling Language v2.0, Part 1 -9.8.4.2.6 Displacement3dVector Element AttributeDefinition Description General Types 3dVectorQuantityValue Features isBound : Boolean {redefines isBound} mRef : Spatial3dCoordinateFrame {redefines mRef} Constraints None. 9.8.4.2.7 duration Element AttributeUsage Description General Types DurationValue scalarQuantities Features None. Constraints None. 9.8.4.2.8 DurationUnit Element AttributeDefinition Description General Types SimpleUnit Features Systems Modeling Language v2.0, Part 1 607 -None. Constraints None. 9.8.4.2.9 DurationValue Element AttributeDefinition Description General Types ScalarQuantityValue Features mRef : DurationUnit {redefines mRef} num : Real {redefines num} Constraints None. 9.8.4.2.10 electricCurrent Element AttributeUsage Description General Types ElectricCurrentValue scalarQuantities Features None. Constraints None. 9.8.4.2.11 ElectricCurrentUnit Element AttributeDefinition Description 608 Systems Modeling Language v2.0, Part 1 -General Types SimpleUnit Features None. Constraints None. 9.8.4.2.12 ElectricCurrentValue Element AttributeDefinition Description General Types ScalarQuantityValue Features mRef : ElectricCurrentUnit {redefines mRef} num : Real {redefines num} Constraints None. 9.8.4.2.13 length Element AttributeUsage Description General Types LengthValue scalarQuantities Features None. Constraints None. Systems Modeling Language v2.0, Part 1 609 -9.8.4.2.14 LengthUnit Element AttributeDefinition Description General Types SimpleUnit Features None. Constraints None. 9.8.4.2.15 LengthValue Element AttributeDefinition Description General Types ScalarQuantityValue Features mRef : LengthUnit {redefines mRef} num : Real {redefines num} Constraints None. 9.8.4.2.16 luminousIntensity Element AttributeUsage Description General Types LuminousIntensityValue scalarQuantities Features 610 Systems Modeling Language v2.0, Part 1 -None. Constraints None. 9.8.4.2.17 LuminousIntensityUnit Element AttributeDefinition Description General Types SimpleUnit Features None. Constraints None. 9.8.4.2.18 LuminousIntensityValue Element AttributeDefinition Description General Types ScalarQuantityValue Features mRef : LuminousIntensityUnit {redefines mRef} num : Real {redefines num} Constraints None. 9.8.4.2.19 mass Element AttributeUsage Description General Types Systems Modeling Language v2.0, Part 1 611 -MassValue scalarQuantities Features None. Constraints None. 9.8.4.2.20 MassUnit Element AttributeDefinition Description General Types SimpleUnit Features None. Constraints None. 9.8.4.2.21 MassValue Element AttributeDefinition Description General Types ScalarQuantityValue Features mRef : MassUnit {redefines mRef} num : Real {redefines num} Constraints None. 9.8.4.2.22 Position3dVector Element 612 Systems Modeling Language v2.0, Part 1 -AttributeDefinition Description General Types 3dVectorQuantityValue Features isBound : Boolean {redefines isBound} mRef : Spatial3dCoordinateFrame {redefines mRef} Constraints None. 9.8.4.2.23 Spatial3dCoordinateFrame Element AttributeDefinition Description General Types 3dCoordinateFrame Features isBound : Boolean {redefines isBound} Constraints None. 9.8.4.2.24 thermodynamicTemperature Element AttributeUsage Description General Types ThermodynamicTemperatureValue scalarQuantities Features None. Constraints Systems Modeling Language v2.0, Part 1 613 -None. 9.8.4.2.25 ThermodynamicTemperatureUnit Element AttributeDefinition Description General Types SimpleUnit Features None. Constraints None. 9.8.4.2.26 ThermodynamicTemperatureValue Element AttributeDefinition Description General Types ScalarQuantityValue Features mRef : ThermodynamicTemperatureUnit {redefines mRef} num : Real {redefines num} Constraints None. 9.8.4.2.27 universalCartesianSpatial3dCoordinateFrame Element AttributeUsage Description A singleton CartesianSpatial3dCoordinateFrame that can be used as a default universal Cartesian 3D coordinate frame. General Types 614 Systems Modeling Language v2.0, Part 1 -attributeValues Cartesian3dSpatialCoordinateFrame Features mRefs : LengthValue [3] {redefines mRefs} By default, the universalCartesianSpatial3dCoordinateFrame uses meters as the units on all three axes. transformation : CoordinateTransformation [0] {redefines transformation} The universalCartesianSpatial3dCoordinateFrame Constraints None. 9.8.5 SI Prefixes 9.8.5.1 SI Prefixes Overview This package specifies the SI unit prefixes as defined in [ISO 80000-1], so that they can be used in automated quantity value conversion. ISO/IEC 80000-1 unit prefixes for decimal multiples and sub-multiples. See also https://en.wikipedia.org/wiki/ Unit_prefix. Name Symbol Value -24 yocto y 10 -21 zepto z 10 -18 atto a 10 -15 femto f 10 -12 pico p 10 -9 nano n 10 -6 micro μ 10 -3 milli m 10 -2 centi c 10 -1 deci d 10 1 deca da 10 2 hecto h 10 3 kilo k 10 6 mega M 10 Systems Modeling Language v2.0, Part 1 615 -Name Symbol Value 9 giga G 10 12 tera T 10 15 peta P 10 18 exa E 10 21 zetta Z 10 24 yotta Y 10 10 ISO/IEC 80000-1 prefixes for binary multiples, i.e. multiples of 1024 (= 2 ). See also https://en.wikipedia.org/wiki/ Binary_prefix. Name Symbol Value kibi Ki 1024 2 mebi Mi 1024 3 gibi Gi 1024 4 tebi Ti 1024 5 pebi Pi 1024 6 exbi Ei 1024 7 zebi Zi 1024 8 yobi Yi 1024 9.8.5.2 Elements 9.8.6 SI 9.8.6.1 SI Overview This package specifies the measurement units as defined in ISO/IEC 80000 parts 3 to 13, the International System of (Measurement) Units -- Système International d'Unités (SI). The statement import SI::*; suffices to make all SI units available in a user model. 9.8.6.2 Elements 9.8.7 US Customary Units 9.8.7.1 US Customary Units Overview This package specifies all US Customary measurement units, with conversion factors to compatible SI units, as defined in Appendix B "Conversion Factors" of [NIST SP-811]. The statement import USCustomaryUnits::*; suffices to make all US Customary measurement units available in a user model. 616 Systems Modeling Language v2.0, Part 1 -9.8.7.2 Elements 9.8.8 Time 9.8.8.1 Time Overview This package specifies concepts to support time-related quantities and metrology, beyond the quantities duration and time as defined in [ISO 80000-3]. Representations of the Gregorian calendar date and time of day as specified by the [ISO 8601-1] standard are included. Also the Coordinated Universal Time (UTC) time scale is captured. 9.8.8.2 Elements 9.8.8.2.1 Clock Element PartDefinition Description A Clock provides a currentTime as a TimeInstantValue that advances montonically over its lifetime. General Types Clock Features currentTime : TimeInstantValue {redefines currentTime} Constraints None. 9.8.8.2.2 Date Element AttributeDefinition Description Generic representation of a time instant as a calendar date. General Types TimeInstantValue Features None. Constraints None. Systems Modeling Language v2.0, Part 1 617 -9.8.8.2.3 DateTime Element AttributeDefinition Description Generic representation of a time instant as a calendar date and time of day. General Types TimeInstantValue Features None. Constraints None. 9.8.8.2.4 DurationOf Element CalculationDefinition Description DurationOf returns the duration of a given Occurrence relative to a given Clock , which is equal to the TimeOf the end snapshot of the Occurrence minus the TimeOf General Types DurationOf Features clock : Clock {redefines clock} Default is inherited Occurrence::localClock . duration : DurationValue {redefines duration} o : Occurrence {redefines o} Constraints None. 9.8.8.2.5 Iso8601DateTime Element AttributeDefinition 618 Systems Modeling Language v2.0, Part 1 -Description Representation of an ISO 8601-1 date and time in extended string format. General Types UtcTimeInstantValue Features num : Real {redefines num} val : Iso8601DateTimeEncoding Constraints None. 9.8.8.2.6 Iso8601DateTimeEncoding Element AttributeDefinition Description Extended string encoding of an ISO 8601-1 date and time. General Types String Features None. Constraints None. 9.8.8.2.7 Iso8601DateTimeStructure Element AttributeDefinition Description Representation of an ISO 8601 date and time with explicit date and time component attributes. General Types UtcTimeInstantValue Features day : Natural Systems Modeling Language v2.0, Part 1 619 -hour : Natural hourOffset : Integer microsecond : Natural minute : Natural minuteOffset : Integer month : Natural num : Real {redefines num} second : Natural year : Integer Constraints None. 9.8.8.2.8 timeInstant Element AttributeUsage Description General Types TimeInstantValue scalarQuantities Features None. Constraints None. 9.8.8.2.9 TimeInstantValue Element AttributeDefinition Description Representation of a time instant quantity. Also known as instant (of time) or point in time. General Types ScalarQuantityValue 620 Systems Modeling Language v2.0, Part 1 -Features mRef : TimeScale {redefines mRef} num : Real {redefines num} Constraints None. 9.8.8.2.10 TimeOf Element CalculationDefinition Description TimeOf returns a TimeInstantValue for a given Occurrence relative to a given Clock . This TimeInstantValue is the time of the start of the Occurrence , which is considered to be synchronized with the snapshot of the Clock with a currentTime equal to the returned timeInstant General Types Evaluation TimeOf Features clock : Clock {redefines clock} Default is inherited Occurrence::localClock . o : Occurrence {redefines o} timeInstant : TimeInstantValue {redefines timeInstant} Constraints startTimeConstraint The TimeOf an Occurrence timeContinuityConstraint If one Occurrence happens immediately before another, then the TimeOf the end snapshot of the first Occurrence equals the TimeOf the second Occurrence . timeOrderingConstraint If one Occurrence happens before another, then the TimeOf the end snapshot of the first Occurrence is no greater than the TimeOf the second Occurrence . Systems Modeling Language v2.0, Part 1 621 -9.8.8.2.11 TimeOfDay Element AttributeDefinition Description Generic representation of a time instant as a time of day. General Types TimeInstantValue Features None. Constraints None. 9.8.8.2.12 TimeScale Element AttributeDefinition Description Generic time scale to express a time instant, including a textual definition of the meaning of zero time instant value. Attribute definitionalEpoch captures the specification of the time instant with value zero, also known as the (reference) epoch. General Types IntervalScale Features definitionalEpoch : DefinitionalQuantityValue definitionalQuantityValues : DefinitionalQuantityValue {redefines definitionalQuantityValues} unit : DurationUnit Constraints None. 9.8.8.2.13 universalClock Element PartUsage Description 622 Systems Modeling Language v2.0, Part 1 -universalClock is a single Clock that can be used as a default universal time reference. General Types universalClock parts Clock Features None. Constraints None. 9.8.8.2.14 UTC Element AttributeDefinition Description Representation of the Coordinated Universal Time (UTC) time scale. UTC is the primary time standard by which the world regulates clocks and time. It is within about 1 second of mean solar time at 0° longitude and is not adjusted for daylight saving time. UTC is obtained from International Atomic Time (TAI) by the insertion of leap seconds according to the advice of the International Earth Rotation and Reference Systems Service (IERS) to ensure approximate agreement with the time derived from the rotation of the Earth. General Types TimeScale Features definitionalEpoch : DefinitionalQuantityValue {redefines definitionalEpoch} unit : DurationUnit {redefines unit} Constraints None. 9.8.8.2.15 utcTimeInstant Element AttributeUsage Description General Types Systems Modeling Language v2.0, Part 1 623 -UtcTimeInstantValue timeInstant Features None. Constraints None. 9.8.8.2.16 UtcTimeInstantValue Element AttributeDefinition Description Representation of a time instant expressed on the Coordinated Universal Time (UTC) time scale. General Types DateTime Features mRef : UTC {redefines mRef} Constraints None. 9.8.9 Quantity Calculations 9.8.9.1 Quantity Calculations Overview Basics In order to enable the use of quantities in expressions this library package specifies the mathematical operators and functions to support quantity arithmetic, and some convenience functions. Any scalar quantity has a quantity dimension (see 9.8.2.2.2 ) that specifies the product of powers of base quantities of the applicable system of quantities. Rules for valid quantity dimensions of the variables in quantity expressions are given below, after definition of the possible quantity expression operations. Such rules specify a necessary but not a sufficient condition for valid quantity expressions. For example, EnergyValue and TorqueValue have the 2 -2 same quantity dimension (L ·M·T in ISQ), but it is not valid to add an energy quantity to a torque quantity. Also each ScalarMeasurementReference has a quantity dimension, that can be used to check the validity of using constructed quantity values in quantity expressions. To enable enforcement of model-evaluable type checking on quantity expressions, all direct specializations of (abstract) ScalarQuantityValue , VectorQuantityValue and TensorQuantityValue must be disjoint. AttributeDefinitions for quantity types at this first level of specialization are referred to as top level quantity types. Furthermore all lower level specializations of quantity AttributeDefinitions and AttributeUsages must be disjoint at each sibling level. For example, a kineticEnergy quantity cannot also be a 624 Systems Modeling Language v2.0, Part 1 -potentialEnergy quantity. Both however, are subsettings of generic energy (defined by EnergyValue ), that is a top level quantity type, so they may be added, subtracted, equated or compared. ScalarQuantityValue Construction Construction of a literal or variable ScalarQuantityValue is done through the [ operator, matched by a closing ] . The signature of the corresponding CalculationDefinition is: calc def '[' specializes BaseFunctions::'[' { in num: Number[1]; in mRef: ScalarMeasurementReference[1]; return quantity : ScalarQuantityValue[1]; } Examples are: attribute mass : MassValue[1] = 24.5 [kg]; attribute x : Real[1] := 58.0; attribute speed : SpeedValue[1] := 3*x [m/s]; attribute :>> ISQ::width default 250.0 [mm]; The provided ScalarMeasurementReference must have a quantity dimension that is the same as the quantity dimension of the scalar quantity attribute being bound, assigned, defaulted or compared. Basics In order to enable the use of quantities in expressions this library package specifies the mathematical operators and functions to support quantity arithmetic, and some convenience functions. Any scalar quantity has a quantity dimension (see 9.8.2.2.2 ) that specifies the product of powers of base quantities of the applicable system of quantities. Rules for valid quantity dimensions of the variables in quantity expressions are given below, after definition of the possible quantity expression operations. Such rules specify a necessary but not a sufficient condition for valid quantity expressions. For example, EnergyValue and TorqueValue have the 2 -2 same quantity dimension (L ·M·T in ISQ), but it is not valid to add an energy quantity to a torque quantity. Also each ScalarMeasurementReference has a quantity dimension, that can be used to check the validity of using constructed quantity values in quantity expressions. To enable enforcement of model-evaluable type checking on quantity expressions, all direct specializations of (abstract) ScalarQuantityValue , VectorQuantityValue and TensorQuantityValue must be disjoint. AttributeDefinitions for quantity types at this first level of specialization are referred to as top level quantity types. Furthermore all lower level specializations of quantity AttributeDefinitions and AttributeUsages must be disjoint at each sibling level. For example, a kineticEnergy quantity cannot also be a potentialEnergy quantity. Both however, are subsettings of generic energy (defined by EnergyValue ), that is a top level quantity type, so they may be added, subtracted, equated or compared. ScalarQuantityValue Construction Construction of a literal or variable ScalarQuantityValue is done through the [ operator, matched by a closing ] . The signature of the corresponding CalculationDefinition is: calc def '[' specializes BaseFunctions::'[' { in num: Number[1]; in mRef: ScalarMeasurementReference[1]; return quantity : ScalarQuantityValue[1]; } Examples are: Systems Modeling Language v2.0, Part 1 625 -attribute mass : MassValue[1] = 24.5 [kg]; attribute x : Real[1] := 58.0; attribute speed : SpeedValue[1] := 3*x [m/s]; attribute :>> ISQ::width default 250.0 [mm]; The provided ScalarMeasurementReference must have a quantity dimension that is the same as the quantity dimension of the scalar quantity attribute being bound, assigned, defaulted or compared. ScalarQuantityValue Operations The following table enumerates the scalar quantity operations. In order to enable concise formulations the following symbols for quantity AttributeUsages are defined: • x is defined by ScalarValues::Real , i.e. x is a real number • b is defined by ScalarValues::Boolean , i.e. b is a boolean • mr is defined by ScalarMeasurementReference , i.e. mr is a scalar measurement reference, typically a measurement unit • s1 , s2 , s3 are defined by ScalarQuantityValue , i.e. they are free or bound scalar quantities • fs1 , fs2 , fs3 are defined by ScalarQuantityValue {:>> isBound = false} , i.e. they are free scalar quantities • bs1 , bs2 , bs3 are defined by ScalarQuantityValue {:>> isBound = true} , i.e. they are bound scalar quantities Note. For completeness also invalid operations are listed, for which the result is empty, and an implementation should raise a warning or error. Note. A mathematical number or a quantity defined by DimensionOneValue has by definition quantity dimension 1, i.e. all exponents in the product of powers of the base quantities are zero. Operator or Result Description function expression fs1+fs2 fs3 Addition of two free scalar quantities returns a free scalar quantity. fs1+bs2 bs3 Addition of a free and a bound scalar quantity returns a bound scalar quantity. fs1+fs2 bs3 Addition of a bound and a free scalar quantity returns a bound scalar quantity. bs1+bs2 ERROR. Two bound scalar quantities cannot be added. Subtraction of a free scalar quantity from a free scalar quantity returns a free fs1-fs2 fs3 scalar quantity. Subtraction of a bound scalar quantity from a free scalar quantity returns a fs1-bs2 bs3 bound scalar quantity. Subtraction of a free scalar quantity from a bound scalar quantity returns a bs1-fs2 bs3 bound scalar quantity. Subtraction of a bound scalar quantity from a bound scalar quantity returns a bs1-bs2 fs3 free scalar quantity. fs1*x or x*fs1 fs3 Multiplication of a free scalar quantity with a real returns a free scalar quantity. bs1*x or x*bs1 ERROR. A bound scalar quantity cannot be an operand in a multiplication. fs1*fs2 fs3 Multiplication of two free scalar quantities returns a free scalar quantity. 626 Systems Modeling Language v2.0, Part 1 -Operator or Result Description function expression fs1*bs2 or bs1*fs2 or ERROR. A bound scalar quantity cannot be an operand in a multiplication. bs1*fs2 fs1/fs2 fs3 Division of two free scalar quantities returns a free scalar quantity. fs1/bs2 or bs1/ ERROR. A bound scalar quantity cannot be an operand in a division. fs2 or bs1/fs2 fs1^x fs3 Exponentiation of a free scalar quantity returns a free scalar quantity. bs1^x ERROR. A bound scalar quantity cannot be an operand in an exponentiation. Function that asserts whether given scalar quantity is zero or not by returning a isZero(s1) b boolean. Function that asserts whether given scalar quantity is 1 or not by returning a isUnit(s1) b boolean. abs(s1) s3 Return scalar quantity of same type with absolute numerical value. Return maximum value scalar quantity of same type and mRef of maximum max(s1, s2) s3 value operand. See note 1. Return minimum value scalar quantity of same type and mRef of minimum min(s1, s2) s3 value operand. See note 1. Return square root value of given scalar quantity. Its quantity dimension sqrt(s1) s3 exponents are halved. floor(s1) s3 Return floor value scalar quantity of same type and mRef as operand. Return scalar quantity of same type and mRef as operand, with numerical value round(s1) s3 rounded to nearest integer. Return scalar quantity of same type and mRef as operand, with numerical value sum(s1[0..*]) s3 equal to cumulative sum of the elements in the operand. Return scalar quantity of same type and mRef as operand, with numerical value product(s1[0..*]) s3 equal to cumulative product of the elements in the operand. ConvertQuantity(s1, Return scalar quantity of same type but with numerical value converted to s3 mr) given target scalar measurement reference. Return true if scalar quantity operands have equal (effective) value, else false. s1 == s2 b See Note 1. Return true if scalar quantity operands do not have equal (effective) value, else s1 != s2 b false. See Note 1. Return true if (effective) value of first scalar quantity operand is less than value s1 < s2 b of second operand, else false. See Note 1. Return true if (effective) value of first scalar quantity operand is less than or s1 <= s2 b equal to value of second operand, else false. See Note 1. Return true if (effective) value of first scalar quantity operand is greater than s1 > s2 b value of second operand, else false. See Note 1. Return true if (effective) value of first scalar quantity operand is greater than of s1 >= s2 b equal to value of second operand, else false. See Note 1. Systems Modeling Language v2.0, Part 1 627 -Note 1. Operands of min , max functions, and relational operators must have the same top level quantity type and be both either free or bound, but may have different mRefs . The rules for valid quantity dimensions for the above operations are: 1. The operands and result of addition ( + ) and subtraction ( - ) operations must all have the same quantity dimension, and be of the same top level quantity type. 2. The operands of multiplication ( * ) operations may differ. The result must have a quantity dimension, in which the exponent for each base quantity is the sum of the exponents of the corresponding base quantity of each of the operands. 3. The operands of division ( / ) operations may differ. The result must have a quantity dimension, in which the exponent for each base quantity is the difference of the exponent of the corresponding base quantity of the first operand minus the exponent of the second operand. 4. The first operand of the exponentiation operator ( ^ ) may have any quantity dimension. The result must have a quantity dimension, in which the exponent for each base quantity is the sum of the exponent of the corresponding base quantity of the first operand plus the value of the second operand (the exponent of the exponentiation operation). 9.8.9.2 Elements 9.8.10 Vector Calculations 9.8.10.1 Vector Calculations Overview Basics In order to enable the use of quantities in expressions this library package specifies the mathematical operators and functions to support vector quantity arithmetic, and some convenience functions. See 9.8.9.1 for a general introduction. VectorQuantityValue Construction Construction of a literal or variable VectorQuantityValue is done through the [ operator, matched by a closing ] . The signature of the corresponding CalculationDefinition is: calc def '[' specializes BaseFunctions::'[' { in num : Number[1..n]; // a sequence of numbers that are the numerical values of the vector components in mRef : VectorMeasurementReference[1]; return quantity : VectorQuantityValue[1]; private attribute n = mRef.flattenedSize; } Typically the measurement reference for a vector quantity is a CoordinateFrame , which is a specialization of VectorMeasurementReference . Examples are: attribute datum : ISQ::CartesianSpatial3dCoordinateFrame { doc /* The datum is the top level coordinate frame of the system-of-interest */ :>> mRefs = (mm, mm, mm); // the units on all 3 Cartesian axes are milllimetre } attribute posVec :>> cartesianPosition3dVector = (200.0, 350.0, 80.0) [datum]; The quantity dimensions of the components of a VectorQuantityValue are specified through the mRefs (defined by ScalarMeasurementReference[1..*] ) of the mRef : VectorMeasurementReference[1] AttributeUsage of the vector quantity. This allows to enforce the rules of scalar quantity arithmetic to the components of vector quantities, when they are bound, assigned, defaulted, compared or the result of a vector quantity expression evaluation. 628 Systems Modeling Language v2.0, Part 1 -Basics In order to enable the use of quantities in expressions this library package specifies the mathematical operators and functions to support vector quantity arithmetic, and some convenience functions. See 9.8.9.1 for a general introduction. VectorQuantityValue Construction Construction of a literal or variable VectorQuantityValue is done through the [ operator, matched by a closing ] . The signature of the corresponding CalculationDefinition is: calc def '[' specializes BaseFunctions::'[' { in num : Number[1..n]; // a sequence of numbers that are the numerical values of the vector components in mRef : VectorMeasurementReference[1]; return quantity : VectorQuantityValue[1]; private attribute n = mRef.flattenedSize; } Typically the measurement reference for a vector quantity is a CoordinateFrame , which is a specialization of VectorMeasurementReference . Examples are: attribute datum : ISQ::CartesianSpatial3dCoordinateFrame { doc /* The datum is the top level coordinate frame of the system-of-interest */ :>> mRefs = (mm, mm, mm); // the units on all 3 Cartesian axes are milllimetre } attribute posVec :>> cartesianPosition3dVector = (200.0, 350.0, 80.0) [datum]; The quantity dimensions of the components of a VectorQuantityValue are specified through the mRefs (defined by ScalarMeasurementReference[1..*] ) of the mRef : VectorMeasurementReference[1] AttributeUsage of the vector quantity. This allows to enforce the rules of scalar quantity arithmetic to the components of vector quantities, when they are bound, assigned, defaulted, compared or the result of a vector quantity expression evaluation. VectorQuantityValue Operations The following table enumerates the vector quantity operations. In order to enable concise formulations the following symbols for quantity AttributeUsages are defined: • x is defined by ScalarValues::Real , i.e. x is a real number • b is defined by ScalarValues::Boolean , i.e. b is a boolean • fs is defined by ScalarQuantityValue {:>> isBound = false} , i.e. it is a free scalar quantity • bs is defined by ScalarQuantityValue {:>> isBound = true} , i.e. it is a bound scalar quantity • v1 , v2 , v3 are defined by VectorQuantityValue , i.e. they are free or bound vector quantities • fv1 , fv2 , fv3 are defined by VectorQuantityValue {:>> isBound = false} , i.e. they are free vector quantities • bv1 , bv2 , bv3 are defined by VectorQuantityValue {:>> isBound = true} , i.e. they are bound vector quantities • ct is defined by CoordinateTransformation , i.e. it is a coordinate transformation Note. For completeness also invalid operations are listed, for which the result is empty, and an implementation should raise a warning or error. Systems Modeling Language v2.0, Part 1 629 -Operator or Result Description function expression fv1+fv2 fv3 Addition of two free vector quantities returns a free vector quantity. fv1+bv2 bv3 Addition of a free and a bound vector quantity returns a bound vector quantity. fv1+fv2 bv3 Addition of a bound and a free vector quantity returns a bound vector quantity. bv1+bv2 ERROR. Two bound vector quantities cannot be added. Subtraction of a free vector quantity from a free vector quantity returns a free fv1-fv2 fv3 vector quantity. Subtraction of a bound vector quantity from a free vector quantity returns a fv1-bv2 bv3 bound vector quantity. Subtraction of a free vector quantity from a bound vector quantity returns a bv1-fv2 bv3 bound vector quantity. Subtraction of a bound vector quantity from a bound vector quantity returns a bv1-bv2 fv3 free vector quantity. fv1*x or x*fv1 fv3 Multiplication of a free vector quantity and a real returns a free vector quantity. bv1*x or x*bv1 ERROR. A bound vector quantity cannot be an operand in a multiplication. fv1/x fv3 Division of a free vector quantity by a real returns a free vector quantity. bv1/x ERROR. A bound vector quantity cannot be an operand in a division. Multiplication of a free scalar quantity and a free vector quantity returns a free fs*fv1 or fv1*fs fv3 vector quantity. fs*bv1 or bv1*fs ERROR. A bound vector quantity cannot be an operand in a multiplication. Division of a free vector quantity by a free scalar quantity returns a free vector fv1/fs fv3 quantity. ERROR. A bound vector quantity or a bound scalar quantity cannot be an bv1/bs operand in a division. inner(v1, v2) x Inner product (aka dot product) of two vector quantities returns a real number. Outer product (aka cross product) of two vector quantities returns a free vector outer(v1, v2) v3 quantity if both operands are free vectors, else a bound vector quantity. Norm of a vector quantity returns a free scalar quantity representing the norm(v1) fs magnitude of the vector. Angle of two vector quantities returns a scalar quantity representing the angle angle(v1, v2) fs (in radian) between the two vectors. Function that asserts whether given vector quantity is a zero vector or not by isZeroVectorQuantity(bv1) returning a boolean. Function that asserts whether given vector quantity is a unit vector or not by isUnitVectorQuantity(bv1) returning a boolean. Transform a vector quantity according to a coordinate transformation, which transform(ct, v3 returns a vector quantity transformed into the target coordinate frame of the v1) given coordinate transformation. The rules for valid quantity dimensions for the above operations are: 630 Systems Modeling Language v2.0, Part 1 -1. The vector quantities for all operands and results must have compatible mRef : VectorMeasurementReference[1] . Here compatible means that the mRef of each vector quantity must have the same dimensions, and their mRef.mRefs must have the same quantity dimension for each vector component. 2. The operands and result of addition ( + ) and subtraction ( - ) operations must all have the same mRef : VectorMeasurementReference[1] , and be of the same top level quantity type. 3. The operands of a multiplication ( * ) operation can be any free vector quantity and free scalar quantity. The result of a must have an mRef , in which for each vector component the exponent for each base quantity is the sum of the exponent of the corresponding base quantity of the component of the vector operand plus the exponent of the scalar operand. 4. The operands of a division ( / ) operation can be any free vector quantity and free scalar quantity. The result of a must have an mRef , in which for each vector component the exponent for each base quantity is the difference of the exponent of the corresponding base quantity of the component of the vector operand minus the exponent of the scalar operand. 5. The operands of the inner product must all have the same mRef , i.e. coordinate frame, and therefore component-wise the same quantity dimensions. 6. The operands and the result of the outer product must all have the same mRef , i.e. coordinate frame, and therefore component-wise the same quantity dimensions. 7. The operand of the norm , isZeroVectorQuantity , isUnitVectorQuantity can be any vector quantity. The result of the norm function is a free scalar quantity that has an mRef compatible with the magnitude of the vector quantity operand. 8. For the transform function, the mRef of the vector quantity operand must be the source coordinate frame of the coordinate transformation operand. The result vector quantity must have an mRef that is equal to the target coordinate frame of the coordinate transformation operand. This specifies all involved quantity dimensions. 9.8.10.2 Elements 9.8.11 Tensor Calculations 9.8.11.1 Tensor Calculations Overview Basics In order to enable the use of quantities in expressions this library package specifies the mathematical operators and functions to support tensor quantity arithmetic, and some convenience functions. See 9.8.9.1 for a general introduction. TensorQuantityValue Construction Construction of a literal or variable TensorQuantityValue is done through the [ operator, matched by a closing ] . The signature of the corresponding CalculationDefinition is: calc def '[' specializes BaseFunctions::'[' { in num : Number[1..n] ordered; // a sequence of numbers that are the numerical values of the tensor components in mRef : TensorMeasurementReference[1]; return quantity : TensorQuantityValue[1]; private attribute n = mRef.flattenedSize; } The quantity dimensions of the components of a TensorQuantityValue are specified through the mRefs (defined by ScalarMeasurementReference[1..*] ) of the mRef : TensorMeasurementReference[1] AttributeUsage of the tensor quantity. This allows to enforce the rules of scalar quantity arithmetic to the components of tensor quantities, when they are bound, assigned, defaulted, compared or the result of a tensor quantity expression evaluation. Systems Modeling Language v2.0, Part 1 631 -Basics In order to enable the use of quantities in expressions this library package specifies the mathematical operators and functions to support tensor quantity arithmetic, and some convenience functions. See 9.8.9.1 for a general introduction. TensorQuantityValue Construction Construction of a literal or variable TensorQuantityValue is done through the [ operator, matched by a closing ] . The signature of the corresponding CalculationDefinition is: calc def '[' specializes BaseFunctions::'[' { in num : Number[1..n] ordered; // a sequence of numbers that are the numerical values of the tensor components in mRef : TensorMeasurementReference[1]; return quantity : TensorQuantityValue[1]; private attribute n = mRef.flattenedSize; } The quantity dimensions of the components of a TensorQuantityValue are specified through the mRefs (defined by ScalarMeasurementReference[1..*] ) of the mRef : TensorMeasurementReference[1] AttributeUsage of the tensor quantity. This allows to enforce the rules of scalar quantity arithmetic to the components of tensor quantities, when they are bound, assigned, defaulted, compared or the result of a tensor quantity expression evaluation. TensorQuantityValue Operations The following table enumerates the tensor quantity operations. In order to enable concise formulations the following symbols for AttributeUsages are defined: • x is defined by ScalarValues::Real , i.e. x is a real number • b is defined by ScalarValues::Boolean , i.e. b is a boolean • v1 , v2 , v3 are defined by VectorQuantityValue , i.e. they are vector quantities • T1 , T2 , T3 are defined by TensorQuantityValue , i.e. they are tensor quantities • ct is defined by CoordinateTransformation , i.e. it is a coordinate transformation Operator or Result Description function expression Addition of two tensor quantities returns a tensor quantity, with all T1+T2 T3 corresponding component values added. Subtraction of a tensor quantity from another tensor quantity returns a tensor T1-T2 T3 quantity, with all corresponding component values of the second operand subtracted from those of the first operand. Multiplication of a tensor quantity and a real number returns a tensor quantity, T1*x or x*T1 T3 with all component values multiplied by x . Division of a tensor quantity with a real number returns a tensor quantity, with T1/x T3 all component values divided by x . Multiplication of a tensor quantity and a vector quantity returns a vector T1*v1 or v1*T1 v3 quantity. The tensor and vector must have compatible (covariant and contravariant) dimensions. Function that asserts whether given tensor quantity is a zero tensor or not by isZeroTensorQuantity(bT1) returning a boolean. 632 Systems Modeling Language v2.0, Part 1 -Operator or Result Description function expression Function that asserts whether given tensor quantity is a unit tensor or not by isUnitTensorQuantity(bT1) returning a boolean. Transform a tensor quantity according to a coordinate transformation, which transform(ct, T3 returns a tensor quantity transformed into the target coordinate frame of the T1) given coordinate transformation. 9.8.11.2 Elements 9.8.12 Measurement Ref Calculations 9.8.12.1 Measurement Ref Calculations Overview Similar to computations with ScalarQuantityValues and VectorQuantityValues in quantity expressions, it is also possible to create measurement reference expressions to compute with MeasurementUnits and CoordinateFrames . MeasurementUnit and CoordinateFrame Operations The following table enumerates the measurement unit and coordinate frame operations. In order to enable concise formulations the following symbols for AttributeUsages are defined: • x is defined by ScalarValues::Real , i.e. x is a real number • u1 , u2 , u3 are defined by MeasurementUnit , i.e. they are measurement units • fcf1 , f cf2 are defined by CoordinateFrame{:>> isBound = false;} , i.e. they are free coordinate frames • bcf1 , b cf2 are defined by CoordinateFrame{:>> isBound = true;} , i.e. they are bound coordinate frames Operator or Result Description function expression Multiplication of two measurement units returns a (derived) measurement unit, with quantity dimension exponents changed such that the exponent of the first u1*u2 u3 operand is added to that of the second, for each base quantity. Equal terms in nominator and denominator cancel out. Division of two measurement units returns a (derived) measurement unit, with quantity dimension exponents changed such that the exponent of the second u1/u2 u3 operand is subtracted from that of the second, for each base quantity. Equal terms in nominator and denominator cancel out. u1^x u3 Exponentiation of a measurement unit returns a (derived) measurement unit. Return a coordinate frame (with isBound default false), that has its quantity cf1*u1 cf2 dimension exponents for all component mRefs changed by adding the corresponding base quantity exponent of the measurement unit. Return a coordinate frame (with isBound default true ), that has its bf1*u1 cf2 quantity dimension exponents for all component mRefs changed by adding the corresponding base quantity exponent of the measurement unit. Return a coordinate frame (with isBound default false ), that has its cf1/u1 cf2 quantity dimension exponents for all component mRefs changed by subtracting the corresponding base quantity exponent of the measurement unit. Systems Modeling Language v2.0, Part 1 633 -Operator or Result Description function expression Return a coordinate frame (with isBound default true ), that has its bf1/u1 cf2 quantity dimension exponents for all component mRefs changed by subtracting the corresponding base quantity exponent of the measurement unit. Examples of measurement unit expressions are: attribute <'m/s'> 'metre per second' : SpeedUnit = m/s; attribute <'N⋅m'> 'newton metre' : EnergyUnit = N*m; Examples of coordinate frame and measurement unit expressions are: attribute spatialCF: CartesianSpatial3dCoordinateFrame[1] { :>> mRefs = (m, m, m); } attribute velocityCF: CartesianVelocity3dCoordinateFrame[1] = spatialCF/s { :>> isBound = false; } ; attribute accelarationCF: CartesianAcceleration3dCoordinateFrame[1] = velocityCF/s; 9.8.12.2 Elements 634 Systems Modeling Language v2.0, Part 1 -AAnnex: Example Model (Informative) A.1 Introduction The example presented in this Annex is intended to illustrate how SysML can be used to model a system. The example is a simple vehicle model that highlights selected language features. Both the graphical and corresponding textual notation are presented. A.2 Model Organization The SimpleVehicleModel is organized into a hierarchy of packages, where some packages contain nested packages. The Definitions package contains nested packages for part definitions, attribute definitions, port definitions, item definitions, action definitions, requirements definitions, and other kinds of definition elements. The VehicleConfigurations package contains two design configurations that are modeled as usages of the definition elements from the Definitions package. Each vehicle configuration contains packages that contain its parts, actions, and requirements. This model includes separate packages for VehicleAnalysis, VehicleVerification, Individuals, and View_Viewpoints. The VehicleAnalysis package contains analysis cases to analyze the system, and the VehicleVerification package contains verification cases and the verification system to verify the system. The Views_Viewpoints package specifies user-defined views. Additional packages that are not shown include a MissionContext package that contains use cases for how the vehicle is used in a particular context, and a VehicleFamily package that contains a model with variation points from which specific vehicle configurations can be derived. The package for the International System of Quantities ( ISQ ) is imported into this model from the SysML model library so its content can be used to specify standard quantities and units. Imported packages can be shown with a dashed outline package symbol as shown in the figure or with an import relationship between the importing package and the imported package. SimpleVehicleModel_ Definitions VehicleConfigurations Individuals PartDefinitions AttributeDefinitions VehicleConfiguration_a VehicleAnalyiss VehicleConfiguration_b PortDefinitions InterfaceDefinitions PartsTree ActionTree VehicleVerification ItemDefinitions RequirementDefinitions Requirements View_Viewpoints ActionDefinitions ISQ Figure 56. Model Organization for SimpleVehicleModel package SimpleVehicleModel{ private import ISQ::*; package Definitions { ... } package VehicleConfigurations{ package VehicleConfiguration_a{ ... } Systems Modeling Language v2.0, Part 1 635 -package VehicleConfiguration_b{ package PartsTree{ ... } package ActionTree{ ... } package Requirements{ ... } } } package VehicleAnalysis{ ... } package VehicleVerification{ ... } package Individuals{ ... } package Views_Viewpoints{ ... } ... } The packages of a system model are often organized and managed to enable team members to work collaboratively on different aspects of the model, where each package contains cohesive content that can be worked on independently. The VehicleConfigurations package would typically import packages for each major system element (e.g., subsystem) to aid in collaborative development, although this was not done for this simple example. A.3 Definitions The Definitions package contains a nested PartDefinitions package that contains definitions for the parts that are used to represent the vehicle configurations. This includes the part definition for a Vehicle , whose features include attributes, ports, actions, and states. «part def» Vehicle attributes Tmax:> temperature acceleration:> acceleration brakePedalDepressed: Boolean cargoMass:> mass dryMass:> mass electricalPower:> power maintenanceTime: DateTime mass:> mass position:> length velocity:> speed ports ignitionCmdPort: IgnitionCmdPort pwrCmdPort: PwrCmdPort statusPort: StatusPort vehicleToRoadPort: VehicleToRoadPort actions perform applyParkingBrake perform controlDirection perform performSelfTest perform provideBraking perform providePower perform senseTemperature states exhibit vehicleStates Figure 57. Part Definition for Vehicle 636 Systems Modeling Language v2.0, Part 1 -part def Vehicle { attribute mass:>ISQ::mass; attribute dryMass:>ISQ::mass; attribute cargoMass:>ISQ::mass; attribute position:>ISQ::length; attribute velocity:>ISQ::speed; attribute acceleration:>ISQ::acceleration; attribute electricalPower:>ISQ::power; attribute Tmax:>ISQ::temperature; attribute maintenanceTime: Time::DateTime; attribute brakePedalDepressed: Boolean; port ignitionCmdPort: IgnitionCmdPort; port pwrCmdPort: PwrCmdPort; port vehicleToRoadPort: VehicleToRoadPort; perform action providePower; perform action provideBraking; perform action controlDirection; perform action performSelfTest; perform action applyParkingBrake; perform action senseTemperature; exhibit state vehicleStates; } The attributes called mass , dryMass , and cargoMass are each a kind of the base mass attribute imported from the standard SysML ISQ library model (see 9.8.4 ). Values of the attribute quantities contained in this library can then be assigned standard units from the SI (see 9.8.6 ) or USCustomaryUnits (see 9.8.7 ) library models. For example, the value of the mass of the Vehicle can be assigned the unit of kilogram ( SI::kg ). The Vehicle also contains other quantity attributes such as its position and velocity . The Vehicle contains three ports called ignitionCmdPort , pwrCmdPort and vehicleToRoadPort , which are interaction points that provide ignition and fuel commands to the vehicle, and transfer vehicle torque to the road. The Vehicle performs the action providePower to accelerate the vehicle, and other actions that include performSelfTest and applyParkingBrake . In addition, the Vehicle exhibits its vehicleStates . The Vehicle represents a class of individual vehicles which is defined by its attributes, ports, actions, and states. Other part definitions can be specified in a similar way to build a reusable library of part definitions. The part definition for FuelTank contains an attribute called mass and an attribute called fuelKind . The attribute fuelKind is defined by the enumeration FuelKind that contains literal values for different kinds of fuel such as gas and diesel. The FuelTank also contains an item called fuel. An item is often used to represent something that flows through a system or is stored by a system. The fuel is not considered to be part of the FuelTank , so fuel is modeled as a referential feature (shown graphically using the white diamond symbol instead of the black diamond). Systems Modeling Language v2.0, Part 1 637 -«part def» FuelTank attributes fuelKind: FuelKind fuelMassMax:> ISQBase::mass mass:> ISQBase::mass ports fuelInPort: ~FuelPort fuelOutPort: FuelPort 1 * «item» «assert constraint» fuel: Fuel fuelConstraint attributes operator expressions fuelMass { fuel.fuelMass<=fuelMassMax } :>>Fuel::fuelMass Figure 58. Part Definition for FuelTank Referencing Fuel it Stores part def FuelTank{ attribute mass :> ISQ::mass; attribute fuelKind:FuelKind; ref item fuel:Fuel{ attribute redefines fuelMass; } attribute fuelMassMax:>ISQ::mass; assert constraint fuelConstraint {fuel.fuelMass<=fuelMassMax} port fuelOutPort:FuelPort; port fuelInPort:~FuelPort; } The fuel contains an attribute called fuelMass . The FuelTank contains an attribute called fuelMassMax , which represents the maximum amount of fuel that a FuelTank can store. A constraint is imposed that the fuelMass must be less than or equal to the fuelMassMax . The constraint is asserted to be true because, if the fuelMass exceeds the fuelMassMax , the model would be inconsistent and the model validation should generate an error. If assert is not used with the constraint, the model could evaluate the constraint to be false, and the model validation should not generate an error. The FuelTank also contains a fuelInPort and a fuelOutPort . The fuelOutPort is defined by FuelPort that contains a directed feature to represent the fuel flowing out of this port. The fuelInPort is defined by a port definition that is the conjugate of the FuelPort . The conjugate is notated with a tilda ( ~ ) in front of the port definition name. The conjugate reverses the direction of each directed feature of the port that it conjugates, which in this case reverses the direction of the fuel to flow in to the port instead of out from the port. Note that the directed features are not shown in the figure but are specified as part of the definition of FuelPort . The part definition for Axle contains the attribute mass . FrontAxle is a specialization of Axle that inherits its mass attribute and contains an additional attribute called steeringAngle . 638 Systems Modeling Language v2.0, Part 1 -«part def» «part def» FrontAxle Axle attributes attributes steeringAngle:> mass:> ISQBase::mass ISQSpaceTime::angularMeasure Figure 59. Axle and its Subclass FrontA part def Axle{ attribute mass:>ISQ::mass; } part def FrontAxle:>Axle{ attribute steeringAngle:>ISQ::angularMeasure; } The Definitions package also contains several other kinds of definition elements. The port definition FuelPort contains an item called fuel that can flow out of the port. The fuel is defined by the item definition Fuel that contains a mass attribute. The interface definition FuelInterface is used to connect a fuelOutPort to a fuelInPort . The definition also specifies that Fuel flows across this interface. The item definition FuelCmd contains an attribute called throttleLevel that is defined by a Real . The action definition ProvidePower contains an input item fuelCmd that is defined by FuelCmd . It also contains an output attribute called wheelToRoadTorque that has multiplicity of 2, and is defined by the attribute definition TorqueValue . «interface def» FuelInterface «enum def» «action def» «item def» «port def» «item def» flows FuelKind ProvidePower Fuel FuelPort FuelCmd of : Fuel from fuelOutPort.fuel to enums parameters fuelInPort.fuel attributes parameters attributes gas in fuelCmd: FuelCmd fuelMass:> ISQBase::mass out fuel: Fuel throttleLevel: Real ports diesel out wheelToRoadTorque: TorqueValue fuelInPort: ~FuelPort fuelOutPort: FuelPort Figure 60. Example Definition Elements action def ProvidePower { in item fuelCmd:FuelCmd; out wheelToRoadTorque:TorqueValue[2]; } item def FuelCmd{ attribute throttleLevel:Real; } port def FuelPort{ out item fuel:Fuel; } item def Fuel{ attribute fuelMass:>ISQ::mass; } interface def FuelInterface{ end fuelOutPort:FuelPort; end fuelInPort:~FuelPort; flow of Fuel from fuelOutPort.fuel to fuelInPort.fuel; } enum def FuelKind {gas; diesel;} Systems Modeling Language v2.0, Part 1 639 -A.4 Parts The VehicleConfigurations package contains two usages of the Vehicle part definition called vehicle_a and vehicle_b . The vehicle_b configuration is shown below. The part vehicle_b inherits features from its part definition Vehicle . It can then redefine or subset its inherited features and add new features. As an example, vehicle_b redefines the mass attribute it inherited from Vehicle and further constrains it's mass to be the sum of its dryMass , cargoMass , and fuelMass . It redefines other features including other attributes, ports, actions, and states in a similar manner. Its actions are redefined to perform actions that are contained in the ActionTree . For example, the inherited action from Vehicle to providePower is redefined by ActionTree::providePower . As described in A.6 , the providePower contained in ActionTree is decomposed into other actions. «part» vehicle_b: Vehicle attributes cargoMass default 0 [kg] :>>Vehicle::cargoMass avgFuelEconomy:> AttributeDefinitions::distancePerVolume dryMass=sum(partMasses) :>>Vehicle::dryMass mass=dryMass+cargoMass+fuelTank.fuel.fuelMass :>>Vehicle::mass partMasses exhibit states vehicleStates :>>Vehicle::vehicleStates parts fuelTank: FuelTank perform actions providePower:> ActionTree::providePower :>>Vehicle::providePower performSelfTest:> ActionTree::performSelfTest :>>Vehicle::performSelfTest applyParkingBrake:> ActionTree::applyParkingBrake :>>Vehicle::applyParkingBrake senseTemperature:> ActionTree::senseTemperature :>>Vehicle::senseTemperature ports fuelCmdPort: FuelCmdPort :>>Vehicle::pwrCmdPort setSpeedPort: ~SetSpeedPort vehicleToRoadPort :>>Vehicle::vehicleToRoadPort Figure 61. Part Usage for vehicle_b part vehicle_b:Vehicle{ attribute mass redefines mass= dryMass+cargoMass+fuelTank.fuel.fuelMass; attribute dryMass redefines dryMass=sum(partMasses); attribute redefines cargoMass default 0 [kg]; attribute partMasses=(...); // collection of part.mass attribute fuelEconomy :> distancePerVolume; port fuelCmdPort:FuelCmdPort redefines pwrCmdPort{ in item fuelCmd redefines pwrCmd; port setSpeedPort:~SetSpeedPort; 640 Systems Modeling Language v2.0, Part 1 -port vehicleToRoadPort redefines vehicleToRoadPort{ port wheelToRoadPort1;WheelToRoadPort; port wheelToRoadPort2:WheelOtRoadPort; } perform ActionTree::providePower redefines providePower; perform ActionTree::performSelfTest redefines performSelfTest; perform ActionTree::applyParkingBrake redefines applyParkingBrake; perform ActionTree::senseTemperature redefines senseTemperature; exhibit States::vehicleStates redefines vehicleStates; } part fuelTank:FuelTank{ ... } ... } A parts tree is a representation of the decomposition of a part into its constituent parts. Different part usages with the same definition, such as vehicle_a and vehicle_b , can have different decompositions. As shown below, vehicle_b is composed of several parts, including an engine , starterMotor , transmission , driveshaft , frontAxleAssembly , rearAxleAssembly , fuelTank , and vehicleSoftware . The frontAxleAssembly contains a frontAxle and two frontWheels as designated by the multiplicity [2] . The rearAxleAssembly contains a rearAxle , differential , rearWheel1 , and rearWheel2 . Note that some of the definition elements are elided from the figure but are visible in the textual notation. As always, views of the model only show selected aspects of the model. «part» vehicle_b: Vehicle «part» «part» «part» «part» «part» «part» «part» «part» fuelTank: FuelTank starterMotor: StarterMotor engine: Engine transmission: Transmission driveshaft: Driveshaft rearAxleAssembly frontAxleAssembly vehicleSoftware: VehicleSoftware 2 «part» «part» «part» «part» «part» «part» differential: Differential rearAxle: Axle rearWheel1: Wheel rearWheel2: Wheel frontAxle: FrontAxle frontWheels: Wheel Figure 62. Parts Tree for vehicle_b part vehicle_b:Vehicle { ... part starterMotor:StarterMotor; part fuelTank:FuelTank; part engine:Engine; part transmission:Transmission; part driveshaft:Driveshaft; part rearAxleAssembly{ part differential:Differential; part rearAxle:Axle; part rearWheel1:Wheel; part rearWheel2:Wheel; } part frontAxleAssembly{ part frontAxle:FrontAxle; part frontWheels:Wheel[2]; } part vehicleSoftware:VehicleSoftware; } The VehicleConfigurations package also contains the engine4Cyl variant that subsets engine . In general, an engine can contain 4 to 8 cylinders . The engine4Cyl variant redefines the set of 4..8 cylinders to be exactly 4 cylinders , and then subsets the set of 4 cylinders to create cylinder1 , cylinder2 , cylinder3 , and cylinder4 . (See also the example of variability modeling in A.12 .) Systems Modeling Language v2.0, Part 1 641 -«part» engine4Cyl :> Engine4Cyl_Variant::engine 1 1 1 1 «part» «part» «part» «part» cylinder1 :> engine4Cyl::cylinders cylinder2 :> engine4Cyl::cylinders cylinder3 :> engine4Cyl::cylinders cylinder4 :> engine4Cyl::cylinders «part» «part» 4 cylinders engine: Engine 4. .8 «part» cylinders: Cylinder Figure 63. Variant engine4Cyl part engine:Engine{ part cylinders:Cylinder [4..8] ordered; } part engine4Cyl:>engine{ part redefines cylinders[4]; part cylinder1[1] subsets cylinders; part cylinder2[1] subsets cylinders; part cylinder3[1] subsets cylinders; part cylinder4[1] subsets cylinders; } A.5 Parts Interconnection The various constituent parts of vehicle_b are interconnected via their ports. The fuelCmdPort on vehicle_b is delegated to the fuelCmdPort on the engine using a binding connection. The controlPort on the vehicleController is connected to the engineControlPort on the engine. The controlPort is defined by ControlPort and the engineControlPort is defined by a port definition that is the conjugate of the ControlPort (that is, the directions of all its directed features are reversed relative to those of the original port definition). The drivePwrPort on the engine is connected to the clutchPort on the transmission by an interface. The interface is defined by an interface definition whose port at one end of the interface is defined as DrivePwrPort and whose port at the other end of the interface is defined as the conjugate of the DrivePwrPort . The DrivePwrPort contains the directed feature out engineTorque:Torque . The conjugate of the DrivePwrPort contains the directed feature in engineTorque:Torque . The fuelOutPort on the fuelTank is connected to the fuelInPort on the Engine by an interface. This interface is defined by the interface definition FuelInterface which contains a flow of Fuel . This flow can be shown as a solid arrowhead on the connection between the ports but is not shown in this particular view. Connections can be made directly between nested parts without having to establish a connection between the corresponding composite parts. For example, the port on the driveShaft can connect directly to a port on the differential without having to connect first to the rearAxleAssembly that composes the differential . Ports can also be nested within a composite port as shown by the vehicleToRoadPort , which contains a nested port for each rear wheel. 642 Systems Modeling Language v2.0, Part 1 -«part» vehicle_b : Vehicle «part» ignitionCmdPort = ignitionCmdPort starterMotor «part» vehicleSoftware gearPort «part» flyWheelPort fuelTank attributes fuelInPort fuelOutPort controlPort controlPort «part» «part» mass vehicleController engine ... attributes wheelToRoadPort1 fuelCmdPort = = mass fuelCmdPort ... vehicleToRoadPort «part» wheelToRoadPort2 rearAxleAssembly drivePwrPort attributes driveTrainEfficiency : Real mass «part» «part» = wheelToRoadPort wheelToRoadPort rearWheel2 : Wheel rearWheel1 : Wheel attributes attributes diameter diameter clutchPort «part» wheelToAxlePort wheelToAxlePort transmission attributes «part» mass rearAxle shaftPort_a «part» rightAxleToWheelPort rightHalfAxle : HalfAxle rightAxleToDiffPort «part» leftAxleToWheelPort leftHalfAxle : HalfAxle leftAxleToDiffPort shaftPort_b rightDiffPort leftDiffPort «part» driveshaft shaftPort_d = shaftPort_d shaftPort_c «part» attributes differential mass Figure 64. Parts Interconnection for vehicle_b part vehicle_b : Vehicle{ port fuelCmdPort redefines pwrCmdPort; port vehicleToRoadPort redefines vehicleToRoadPort{ port wheelToRoadPort1; port wheelToRoadPort2; } part fuelTank:FuelTank{ port fuelOutPort; } part rearAxleAssembly{ port shaftPort_d; part rearWheel1:Wheel{ port :>>wheelToRoadPort; port :>>wheelToAxlePort; } part rearWheel2:Wheel{ port :>>wheelToRoadPort; port :>>wheelToAxlePort; } part differential:Differential{ port shaftPort_d; port leftDiffPort; port rightDiffPort; } part rearAxle{ part leftHalfAxle:HalfAxle{ port leftAxleToDiffPort; port leftAxleToWheelPort; } part rightHalfAxle:HalfAxle{ port rightAxleToDiffPort; Systems Modeling Language v2.0, Part 1 643 -port rightAxleToWheelPort; } } bind shaftPort_d = differential.shaftPort_d; connect differential.leftDiffPort to rearAxle.leftHalfAxle.leftAxleToDiffPort; connect differential.rightDiffPort to rearAxle.rightHalfAxle.rightAxleToDiffPort; connect rearAxle.leftHalfAxle.leftAxleToWheelPort to rearWheel1.wheelToAxlePort; connect rearAxle.rightHalfAxle.rightAxleToWheelPort to rearWheel2.wheelToAxlePort; } part starterMotor:StarterMotor{ port ignitionCmdPort; port gearPort; } part engine:Engine{ port fuelCmdPort; port drivePwrPort:DrivePwrPort; port fuelInPort; port flyWheelPort; port controlPort; } part transmission:Transmission{ port clutchPort:~DrivePwrPort; port shaftPort_a; } part driveshaft:Driveshaft{ port shaftPort_b; port shaftPort_c; } part vehicleSoftware:VehicleSoftware{ part vehicleController { port controlPort; } } //connections bind engine.fuelCmdPort = fuelCmdPort; bind starterMotor.ignitionCmdPort = ignitionCmdPort; interface engineToTransmissionInterface:EngineToTransmissionInterface connect engine.drivePwrPort to transmission.clutchPort; interface fuelInterface:FuelInterface connect fuelTank.fuelOutPort to engine.fuelInPort; connect vehicleSoftware.vehicleController.controlPort to engine.controlPort; connect starterMotor.gearPort to engine.flyWheelPort; connect transmission.shaftPort_a to driveshaft.shaftPort_b; connect driveshaft.shaftPort_c to rearAxleAssembly.shaftPort_d; bind rearAxleAssembly.rearWheel1.wheelToRoadPort = vehicleToRoadPort.wheelToRoadPort1; bind rearAxleAssembly.rearWheel2.wheelToRoadPort = vehicleToRoadPort.wheelToRoadPort2; } 644 Systems Modeling Language v2.0, Part 1 -A.6 Actions The definition and usage pattern applies not only to parts and part definitions, but to most constructs in SysML. As shown below, the action providePower is defined by the action definition ProvidePower . The action providePower contains actions to generateTorque , amplifyTorque , transferTorque , and distributeTorque , each of which have their own definitions. The actions inherit their input and output parameters from their definition and redefine them as necessary (Note: the inherited parameters are not shown.) «action» providePower: ProvidePower «action» «action» «action» «action» generateTorque: GenerateTorque amplifyTorque: AmplifyTorque transferTorque: TransferTorque distributeTorque: DistributeTorque Figure 65. Action providePower action providePower:ProvidePower{ action generateTorque:GenerateTorque; action amplifyTorque:AmplifyTorque; action transferTorque:TransferTorque; action distributeTorque:DistributeTorque; ... } As shown in Fig. 61 , the part vehicle_b performs the action providePower . The subparts of vehicle_b then perform the appropriate subactions of providePower . For example, the part engine performs the action providePower.generateTorque , which redefines the generateTorque action inherited from its definition. The output of each subaction of providePower is connected by a flow connection to the input of another subaction, except for distributeTorque , whose outputs are bound to the outputs of providePower . The input and output parameters are streaming unless designated as succession flows, meaning that the inputs continue to be consumed and the outputs continue to be produced as the action executes. Figure 66. Action flow for providePower action providePower:ProvidePower{ ... bind fuelCmd = generateTorque.fuelCmd; flow generateTorque.engineTorque to amplifyTorque.engineTorque; flow amplifyTorque.transmissionTorque to transferTorque.transmissionTorque; flow transferTorque.driveshaftTorque to distributeTorque.driveshaftTorque; bind distributeTorque.wheelToRoadTorque = wheelToRoadTorque; } Systems Modeling Language v2.0, Part 1 645 -The transportPassenger_1 use case contains a sequence of actions for a Vehicle to transport passengers. The use case is defined by a use case definition called TransportPassenger . The actions passenger1GetInVehicle and driverGetInvehicle are performed concurrently after the start of the use case. After both these actions complete, an accept action is triggered upon receipt of an IgnitionCmd . After this, the actions driveVehicleToDestination and providePower can proceed concurrently. Once these are both completed, then the actions passenger1GetOutOfVehicle and driverGetOutOfvehicle are preformed concurrently, after which the transportPassenger use case is done. The fork and join control nodes and the successions (i.e., first and then) are used to control the action sequence. vehicle «use case» transportPassenger_1 «use case» start «action» «action» driverGetInVehicle passenger1GetInVehicle «accept action» ignitionCmd:IgnitionCmd «action» «action» driveVehicleToDestination providePower «action» «action» driverGetOutOfVehicle passenger1GetOutOfVehicle @ «use case» ^done result Figure 67. Action flow for transportPassenger use case transportPassenger_1:TransportPassenger{ //action declarations ... first start; then fork fork1; then driverGetInVehicle; then passenger1GetInVehicle; first driverGetInVehicle then join1; first passenger1GetInVehicle then join1; 646 Systems Modeling Language v2.0, Part 1 -first join1 then trigger; first trigger then fork2; fork fork2; then driveVehicleToDestination; then providePower; first driveVehicleToDestination then join2; first providePower then join2; first join2 then fork3; fork fork3; then driverGetOutOfVehicle; then passenger1GetOutOfVehicle; first driverGetOutOfVehicle then join3; first passenger1GetOutOfVehicle then join3; first join3 then done; } A.7 States The states of a Vehicle enable selected actions to be performed. The Vehicle exhibits its state vehicleStates . This state is a parallel state, so its substates operatingStates and healthStates are concurrent. The states operatingStates and healthStates are not parallel, so only one of each of their substates can be active at any given time. Systems Modeling Language v2.0, Part 1 647 -Figure 68. Vehicle States exhibit state vehicleStates parallel { ref controller; state operatingStates { ... } state healthStates { ... } } Note that the state vehicleStates has a referential feature controller :VehicleController . This allows the substates of vehicleStates to send a signal to the controlller or one of its ports, or to access any other feature of controller. 648 Systems Modeling Language v2.0, Part 1 -The operatingStates are further decomposed into off , starting , and on states, with an entry transition to the off substate. Upon receipt of an ignitionCmd , the off-starting transition fires if the ignitionCmd is in the on position and the brakePedalDepressed is true. A StartSignal is sent to the controller as part of this transition, after which operatingStates enters its starting substate. The state operatingStates also includes transitions from the substates starting to on and on to off . The ignitionCmd is defined by the item definition IgnitionCmd , which contains an attribute defined by an enumeration with values on and off . This pattern is used to represent a variety of signals that may be sent by send actions and accepted by accept actions. The on state has an entry action to performSelfTest , which is performed upon entry to the state. When the entry action completes, the do action to providePower starts, and it continues to be performed until the state is exited. Prior to exiting the state, the exit action to applyParkingBrake is performed. The state also has a constraint that the electricalPower must not exceed 500 watts. state operatingStates { entry action initial; state off; state starting; state on { entry performSelfTest; do providePower; exit applyParkingBrake; constraint {electricalPower<=500[W]} } transition initial then off; transition 'off-starting' first off accept ignitionCmd:IgnitionCmd via ignitionCmdPort if ignitionCmd.ignitionOnOff==IgnitionOnOff::on and brakePedalDepressed do send new StartSignal() to controller then starting; transition 'starting-on' first starting accept VehicleOnSignal then on; transition 'on-off' first on accept VehicleOffSignal do send new OffSignal() to controller then off; } The healthStates are decomposed into normal , maintenance and degraded states. Starting in the normal state, healthStates continually monitors the vehicle temperature and, when the temperature exceeds the allowed maximum, it transitions to the degraded state and notifies the controller . It also transitions from normal to maintenance when it is time for vehicle maintenance. In either case, it transitions back to the normal state on receipt of a ReturnToNormal signal. state healthStates { entry action initial; do senseTemperature{ out temp; } Systems Modeling Language v2.0, Part 1 649 -state normal; state maintenance; state degraded; transition initial then normal; transition 'normal-maintenance' first normal accept at maintenanceTime then maintenance; transition 'normal-degraded' first normal accept when senseTemperature.temp > Tmax do send new OverTemp() to controller then degraded; transition 'maintenance-normal' first maintenance accept ReturnToNormal then normal; transition 'degraded-normal' first degraded accept ReturnToNormal then normal; } A.8 Requirements The requirement definition MassRequirement has a shall statement that "The actual mass shall be less than the required mass". This statement is formalized using attributes for massRequired and massActual and the constraint expression {massActual<=massRequired} . «requirement def» MassRequirement doc The actual mass shall be less than the required mass attributes massActual:> ISQBase::mass massRequired:> ISQBase::mass constraints require {massActual<=massRequired} Figure 69. Requirement Definition MassRequirement requirement def MassRequirement{ doc /*The actual mass shall be less than the required mass*/ attribute massRequired:>ISQ::mass; attribute massActual:>ISQ::mass; require constraint {massActual<=massRequired} } The vehicleSpecification is a requirement that contains other requirements. It has a dependency to marketSurvey (not shown) that indicates its requirements are dependent on the market survey. The subject of the vehicleSpecification is vehicle:Vehicle , which enables the requirements contained in the specification to 650 Systems Modeling Language v2.0, Part 1 -reference the features of vehicle . One of the requirements contained in the specification is the vehicleMassRequirement , which is defined by MassRequirement . The massRequired attribute is redefined to have a specific value of 2000 kg in the context of this vehicleSpecification . The attribute massActual is redefined to be the sum of the dryMass and fuelMassActual of the vehicle , where the fuelMassActual is assumed to be a full tank of gas that weighs 60 kg. The vehicleSpecficiation also contains vehicleFuelEconomyRequirements for both city and highway. Although not shown, the mass requirement is allocated to the mass of the vehicle using the allocate relationship, and the engine mass requirement is derived from the vehicle mass requirement using the derivation relationship. «requirement» vehicleSpecification * «requirement» <1> vehicleMassRequirement: MassRequirement doc * The total mass of the vehicle shall be less than or equal to the required mass. «requirement» * Assume total mass includes a full tank of <2> vehicleFuelEconomyRequirements gas of 60 kg «subject» doc attributes vehicle fuel economy requirements group massRequired =2000 [kg] attributes attributes :>>MassRequirement::massRequired dryMass:> ISQBase::mass assumedCargoMass:> ISQBase::mass massActual = vehicle.dryMass + subject fuelMassActual :>>MassRequirement::massActual fuelMassActual:> ISQBase::mass fuelMassMax:> ISQBase::mass = 60 [kg] constraints assume {fuelMassActual==fuelMassMax} * * «requirement» «requirement» <2_1> cityFuelEconomyRequirement: FuelEconomyRequirement <2_2> highwayFuelEconomyRequirement: FuelEconomyRequirement references references requiredFuelEconomy = 10 [km / L] requiredFuelEconomy = 12.75 [km / L] :>>FuelEconomyRequirement::requiredFuelEconomy :>>FuelEconomyRequirement::requiredFuelEconomy constraints constraints assume {assumedCargoMass<=500 [kg]} assume {assumedCargoMass<=500 [kg]} Figure 70. Requirements Group vehicleSpecification item marketSurvey; dependency from vehicleSpecification to marketSurvey; requirement vehicleSpecification{ subject vehicle:Vehicle; requirement <'1'> vehicleMassRequirement : MassRequirement { doc /* The total mass of a vehicle shall be less than or equal to the required mass. Assume total mass includes a full tank of gas of 60 kg*/ attribute redefines massRequired=2000 [kg]; attribute redefines massActual = vehicle.dryMass + fuelMassActual; attribute fuelMassActual:>ISQ::mass; attribute fuelMassMax:>ISQ::mass = 60 [kg]; assume constraint {fuelMassActual==fuelMassMax} } allocate vehicleMassRequirement to PartsTree::vehicle_b.mass; requirement <'2'> vehicleFuelEconomyRequirements { doc /* fuel economy requirements group */ attribute assumedCargoMass:>ISQ::mass; requirement <'2_1'> cityFuelEconomyRequirement : FuelEconomyRequirement { redefines requiredFuelEconomy= 10 [km / L]; assume constraint {assumedCargoMass>=500 [kg]} } requirement <'2_2'> highwayFuelEconomyRequirement : FuelEconomyRequirement { redefines requiredFuelEconomy= 12.75 [km / L]; assume constraint {assumedCargoMass>=500 [kg]} } Systems Modeling Language v2.0, Part 1 651 -} } requirement engineSpecification{ subject engine1:Engine; requirement <'1'> enegineMassRequirement : MassRequirement { ... } #derivation connection{ end #original ::> vehicleSpecification.vehicleMassRequirement; end #derive ::> engineSpecification.engineMassRequirement; } } In order to evaluate whether vehicle_b satisfies the vehicleMassRequirement , the massActual must be bound to the mass of vehicle_b . This is accomplished by asserting that vehicle_b satisfies the vehicleSpecification and binding the actualMass of the requirement to the mass of vehicle_b . Asserting vehicle_b satisfies the requirement is equivalent to imposing the mass constraint contained in the requirement on vehicle_b . satisfy vehicleSpecification by vehicle_b { requirement vehicleMassRequirement :>> vehicleMassRequirement { attribute redefines massActual = vehicle_b.mass; attribute redefines fuelMassActual = vehicle_b.fuelTank.fuel.fuelMass; } } A.9 Analysis The FuelEconomyAnalyisModel package contains an analysis case called fuelEconomyAnalysis . The objective for this analysis case is to estimate the fuel economy of the vehicle. Its subject is the part vehicle_b . The analysis case accepts a nominal driving scenario as an input, and returns a calculatedFuelEconomy in KilometersPerLitre as an output. The analysis includes the following calculations to determine the result: • TraveledDistance (scenario) • AverageTravelTimePerDistance (scenario) • ComputeBSFC (vehicle_b.engine) • BestFuelConsumptionPerDistance (vehicle_b.mass, bsfc, tpd_avg, distance) • IdlingFuelConsumptionPerTime (vehicle_b.engine) • FuelConsumption (f_a, f_b, tpd_avg) 652 Systems Modeling Language v2.0, Part 1 -«analysis» fuelEconomyAnalysis parameters in scenario: Scenario out calculatedFuelEconomy:>AttributeDefinitions::distancePerVolume =FuelConsumption(f_a, f_b, tpd_avg) attributes bsfc = ComputeBSFC(vehicle_b.engine) distance = TraveledDistance(scenario) f_a = BestFuelConsumptionPerDistance(vehicle_b.mass, bsfc, tpd_avg, distance) f_b = IdlingFuelConsumptionPerTime(vehicle_b.engine) tpd_avg = AverageTravelTimePerDistance(scenario) objectives fuelEconomyAnalysisObjective subject subj = vehicle_b Figure 71. Analysis Case fuelEconomyAnalysis analysis fuelEconomyAnalysis { in attribute scenario: Scenario; subject = vehicle_b; objective fuelEconomyAnalysisObjective { doc /* estimate the vehicle fuel economy */ } attribute distance = TraveledDistance(scenario); attribute tpd_avg = AverageTravelTimePerDistance(scenario); attribute bsfc = ComputeBSFC(vehicle_b.engine); attribute f_a = BestFuelConsumptionPerDistance(vehicle_b.mass, bsfc, tpd_avg, distance); attribute f_b = IdlingFuelConsumptionPerTime(vehicle_b.engine); return attribute calculatedFuelEconomy:>distancePerVolume = FuelConsumption(f_a, f_b, tpd_avg); } A.10 Verification The simple verification case massTests is a usage of the verification case definition MassTest . The verification objective is to verify the vehicleMassRequirement . The subject of the verification case is vehicle_b . The verification case includes actions to weighVehicle and evaluatePassFail . The massVerificationSystem performs the massTests . It is composed of an operator and a scale . The scale performs the action to weighVehicle , and the operator performs the action to evaluatePassFail . The verification case returns a verdict of pass or fail based on whether the measured mass satisfies the mass requirement. Systems Modeling Language v2.0, Part 1 653 -VerificationSystem «part» «perform action» operator evaluatePassFail «part» «part» «perform action» massVerificationSystem scale weighVehicle «perform» VerificationCases1 «action» evaluatePassFail «verification» massTests: MassTest «action» metadata weighVehicle VerificationMethod kind = VerificationMethodKind::test, «objective» VerificationMethodKind::analyze «requirement» «require» «requirement» vehicleMassRequirement obj VerificationCaseDefinitions «verification def» MassTest «verification def» AccelerationTest «verification def» ReliabilityTest Figure 72. Vehicle Mass Verification Test package VerificationCaseDefinitions{ verification def MassTest; verification def AccelerationTest; verification def ReliabilityTest; } package VerificationCases1{ verification massTests:MassTest { subject = vehicle_b; objective { verify vehicleSpecification.vehicleMassRequirement{ redefines massActual=weighVehicle.massMeasured; } } metadata VerificationMethod{ kind = VerificationMethodKind::test; } action weighVehicle { out massMeasured:>ISQ::mass; } then action evaluatePassFail { in massMeasured:>ISQ::mass; out verdict = PassIf( vehicleSpecification.vehicleMassRequirement(vehicle_b) ); } flow from weighVehicle.massMeasured to evaluatePassFail.massMeasured; return :>> verdict = evaluatePassFail.verdict; } } package VerificationSystem{ part massVerificationSystem{ perform massTests; part scale{ 654 Systems Modeling Language v2.0, Part 1 -perform massTests.weighVehicle; } part operator{ perform massTests.evaluatePassFail; } } } A.11 View and Viewpoint The SafetyEngineer is a stakeholder with a concern for VehicleSafety . The safetyViewpoint frames this concern. The view vehiclePartsTree_Safety is a PartsTreeView that satisfies the SafetyViewpoint , and, therefore, addresses the VehicleSafety concern. The view definition TreeView defines views that are rendered as tree diagrams. The view definition PartsTreeView specializes TreeView with a filter condition that only PartUsages should be included in the view. The view usage vehiclePartsTree_Safety adds the further condition to only include parts that have the metadata annotation for Safety . This view then exposes all the nested parts of vehicle_b , such that those parts meeting all the filter criteria are rendered in a tree diagram. « VehicleSafetyView i m p o r t » * «view» * «expose»** «import»* vehiclePartsTree_Safety: PartsTreeView «import»** «import»** «satisfy» «import»* ViewpointDefinitions ViewDefinitions «concern def» VehicleSafety «viewpoint def» PartsTree «part def» «view def» SafetyViewpoint doc SafetyEngineer PartsTreeView identify system safety features concerns require vs: VehicleSafety stakeholders se: SafetyEngineer «view def» TreeView renderings asTreeDiagram:> Views::asTreeDiagram Figure 73. Vehicle Safety View package Viewpoints{ part def SafetyEngineer; concern def VehicleSafety { doc /* Vehicle must have necessary safety features. */ stakeholder se:SafetyEngineer; } viewpoint safetyViewpoint{ frame concern vs:VehicleSafety; } } package ViewDefinitions{ view def TreeView { render asTreeDiagram; } view def PartsTreeView:>TreeView { filter @SysML::PartUsage; } } Systems Modeling Language v2.0, Part 1 655 -package VehicleViews{ view vehiclePartsTree_Safety:PartsTreeView{ satisfy safetyViewpoint; filter @Safety; expose vehicle_b::**; } } «#Safety» «#Safety» «#Safety» bumper seatBelt driverAirBag Figure 74. Rendering of view vehiclePartsTree_Safety A.12 Variability The part vehicleFamily models a family of Vehicles that allows variations in the subparts engine , transmission and sunroof . In particular, the part engine has two variants, engine4Cyl and engine6Cyl , which constrain engine.cylinders to have multiplicity 4 and 6, respectively. The part cylinders of engine6Cyl has an attribute diameter that is also a variation point, with two variants for smallDiameter and largeDiameter . There are also two choices for the transmission and a sunroof is optional. The choice of a selected variant at one variation point can constrain the available choices at another variation point. For this example, the choices are constrained to be a 4 cylinder engine with a manual transmission or a 6 cylinder engine with an automatic transmission. «part» vehicleFamily * «assert constraint» selectionConstraint 1 1 1 1 1 1 operator expressions «variation» «variation» «variation» { (engine==engine::engine4Cyl and «part» «part» «part» «part» «part» «part» transmissionChoices==TransmissionChoices::transmissionManual) driveshaft frontAxleAssembly rearAxleAssembly engine: Engine transmissionChoices: TransmissionChoices sunroof: Sunroof xor (engine==engine::engine6Cyl and transmissionChoices==TransmissionChoices::transmissionAutomatic) } «part def» TransmissionChoices 1 1 «variant» «variant» «part» «part» engine4Cyl: Engine4Cyl engine6Cyl: Engine6Cyl 6 * * «part» «variant» «variant» cylinder: Cylinder «part» «part» transmissionAutomatic: TransmissionAutomatic transmissionManual: TransmissionManual attributes diameter: LengthValue Figure 75. Variability Model for vehicleFamily variation part def TransmissionChoices:>Transmission { variant part transmissionAutomatic:TransmissionAutomatic; variant part transmissionManual:TransmissionManual; } abstract part vehicleFamily:>vehicle_a{ variation part engine:Engine{ variant part engine4Cyl:Engine4Cyl; variant part engine6Cyl:Engine6Cyl{ part cylinder:Cylinder [6]{ variation attribute diameter:LengthValue{ variant attribute smallDiameter:LengthValue; variant attribute largeDiagmeter:LengthValue; } } } 656 Systems Modeling Language v2.0, Part 1 -} variation part transmission:TransmissionChoices; variation part sunroof:Sunroof; assert constraint selectionConstraint { (engine==engine::engine4Cyl and transmission==TransmissionChoices::transmissionManual) xor (engine==engine::engine6Cyl and transmission==TransmissionChoices::transmissionAutomatic) } } A.13 Individuals The part definition Vehicle represents a class of individual vehicles with common characteristics. The parts vehicle_a and vehicle_b are usages of Vehicle with different part decompositions. There can be many individual vehicles that conform to vehicle_a or vehicle_b . The individual part definition Vehicle_1 is a specialization of Vehicle that restricts the part definition to a single individual. A usage vehicle_1 of this definition represents that individual within a specific context. This usage can also subset vehicle_b and inherit the parts hierarchy and other features of vehicle_b . Additional individual definitions FrontAxleAssembly_1 , FrontAxle_1 , Wheel_1 , Wheel_2 , etc., are similarly specializations of their respective part definitions. The vehicle_1.frontAxleAssembly is a usage of FrontAxleAssembly_1 , whose frontAxle is a usage of FrontAxle_1 , whose wheels are Wheel_1 and Wheel_2 . In this way, vehicle_1 can decompose into a hierarchy of individual parts. An individual definition and usage can be created for any definition and usage element. An individual action for example, represents a particular performance of an action with individual inputs and outputs. The part definition VehicleRoadContext defines a context containing vehicle:Vehicle and road:Road subparts. The individual definition VehicleRoadContext_1 is a specialization of VehicleRoadContext whose subparts are constrained to be usages of the individual definitions Vehicle_1 and Road_1 . As shown below, there is a time slice of VehicleRoadContext_1 from t0 to t2 called t0_t2_a with three snapshots t0_a , t1_a and t2_a , at the times t0 , t1 and t2 , respectively. Each context snapshot contains snapshots of Vehicle_1 and Road_1 at the respective times. Each of the vehicle and road snapshots are characterized by specific values for their attributes. In addition, the vehicle snapshot contains snapshots of its individual parts consistent with the decomposition of vehicle_1 . An analysis may be used to compute the values of the attributes for each snapshot. The analysis results reflect the time history of the individuals, which may be visualized using typical time-based plots and data representations. Systems Modeling Language v2.0, Part 1 657 -«individual occurrence» a: VehicleRoadContext_1 «timeslice occurrence» t0_t2_a «snapshot occurrence» «snapshot occurrence» «snapshot occurrence» t0_a t1_a t2_a attributes attributes attributes t0 =0 [s] t1 =1 [s] t2 =2 [s] :>>Context::time :>>Context::time :>>Context::time «snapshot occurrence» «snapshot occurrence» «snapshot occurrence» «snapshot occurrence» «snapshot occurrence» «snapshot occurrence» t0_r: Road_1 t0_v: Vehicle_1 t1_r: Road_1 t1_v: Vehicle_1 t2_r: Road_1 t2_v: Vehicle_1 «snapshot occurrence» «snapshot occurrence» «snapshot occurrence» t0_fa: FrontAxleAssembly_1 t1_fa: FrontAxleAssembly_1 t2_fa: FrontAxleAssembly_1 «snapshot occurrence» «snapshot occurrence» «snapshot occurrence» «snapshot occurrence» «snapshot occurrence» «snapshot occurrence» t0_leftFront: Wheel_1 t0_rightFront: Wheel_2 t1_leftFront: Wheel_1 t1_rightFront: Wheel_2 t2_leftFront: Wheel_1 t2_rightFront: Wheel_2 Figure 76. Vehicle Individuals and Snapshots individual a:VehicleRoadContext_1{ timeslice t0_t2_a{ snapshot t0_a { attribute t0 redefines time=0 [s]; snapshot t0_r:Road_1{ :>>incline=0; :>>friction=.1; } snapshot t0_v:Vehicle_1{ :>>position=0 [m]; :>>velocity=0 [m]; :>>acceleration=1.96 [m/s**2]; snapshot t0_fa:FrontAxleAssembly_1{ snapshot t0_leftFront:Wheel_1; snapshot t0_rightFront:Wheel_2; } } } snapshot t1_a{ attribute t1 redefines time=1 [s]; snapshot t1_r:Road_1{ :>>incline=0; :>>friction=.1; } snapshot t1_v:Vehicle_1{ :>>position=.98 [m]; :>>velocity=1.96 [m/s]; :>>acceleration=1.96 [m/s**2]; snapshot t1_fa:FrontAxleAssembly_1{ snapshot t1_leftFront:Wheel_1; snapshot t1_rightFront:Wheel_2; } } } snapshot t2_a{ attribute t2 redefines time=2 [s]; snapshot t2_r:Road_1{ 658 Systems Modeling Language v2.0, Part 1 -:>>incline =0; :>>friction=.1; } snapshot t2_v:Vehicle_1{ :>>position=3.92 [m]; :>>velocity=3.92 [m/s]; :>>acceleration=1.96 [m/s**2]; snapshot t2_fa:FrontAxleAssembly_1{ snapshot t2_leftFront:Wheel_1; snapshot t2_rightFront:Wheel_2; } } } } } Systems Modeling Language v2.0, Part 1 659 diff --git a/Resources/specification/3-Systems_Modeling_API_and_Services.pdf.txt b/Resources/specification/3-Systems_Modeling_API_and_Services.pdf.txt deleted file mode 100644 index 54df395e..00000000 --- a/Resources/specification/3-Systems_Modeling_API_and_Services.pdf.txt +++ /dev/null @@ -1,107 +0,0 @@ -® An OMG Systems Modeling Publication Systems Modeling Application Programming Interface (API) and Services Version 1.0 _______________________________________________________________________________ OMG Document Number: formal/2026-03-04 Date: March 2026 Standard document URL: https://www.omg.org/spec/SystemsModelingAPI/1.0/ _______________________________________________________________________________ - -Copyright © 2019-2025, 88solutions Corporation Copyright © 2023-2025, Adaptive Analytics, Inc. Copyright © 2023-2025, Aerospace Corporation Copyright © 2019-2025, Airbus Copyright © 2023-2025, Ansys Government Initiatives Copyright © 2019-2025, Aras Corporation Copyright © 2019-2025, Association of Universities for Research in Astronomy (AURA) Copyright © 2019-2025, BigLever Software Copyright © 2019-2025, Boeing Copyright © 2022-2025, Budapest University of Technology and Economics Copyright © 2021-2025, Commissariat à l'énergie atomique et aux énergies alternatives (CEA) Copyright © 2019-2025, Contact Software GmbH Copyright © 2019-2025, Dassault Systèmes (No Magic) Copyright © 2019-2025, DSC Corporation Copyright © 2020-2025, DEKonsult Copyright © 2020-2025, Delligatti Associates LLC Copyright © 2019-2025, The Charles Stark Draper Laboratory, Inc. Copyright © 2020-2025, ESTACA Copyright © 2023-2025, Galois, Inc. Copyright © 2019-2025, GfSE e.V. Copyright © 2019-2025, George Mason University Copyright © 2023-2025, Georgia Institute of Technology Copyright © 2024-2025, Integration Innovation, Inc. (i3) Copyright © 2019-2025, IBM Copyright © 2019-2025, Idaho National Laboratory Copyright © 2019-2025, INCOSE Copyright © 2023-2025, IncQuery Labs cPlc Copyright © 2019-2025, Intercax LLC Copyright © 2019-2025, Jet Propulsion Laboratory (California Institute of Technology) Copyright © 2019-2025, Kenntnis LLC Copyright © 2020-2025, Kungliga Tekniska högskolon (KTH) Copyright © 2019-2025, LightStreet Consulting LLC Copyright © 2019-2025, Lockheed Martin Corporation Copyright © 2024-2025, Mantech International Corporation Copyright © 2019-2025, Maplesoft Copyright © 2021-2025, MID GmbH Copyright © 2020-2025, MITRE Copyright © 2019-2025, Model Alchemy Consulting Copyright © 2019-2025, Model Driven Solutions, Inc. Copyright © 2019-2025, Model Foundry Pty. Ltd. Copyright © 2023-2024, OAR Corporation Copyright © 2023-2025, Object Management Group, Inc. Copyright © 2019-2025, On-Line Application Research Corporation (OAC) Copyright © 2024-2025, OntoAge Copyright © 2019-2025, oose eG Copyright © 2023-2024, OpenText Inc. Copyright © 2019-2025, Østfold University College Copyright © 2019-2025, PTC Copyright © 2020-2025, Qualtech Systems, Inc. Copyright © 2024-2025, Rocket Software Copyright © 2023-2025, RTX Copyright © 2019-2025, SAF Consulting Copyright © 2024-2025, Sensmetry Copyright © 2023-2025, Siemens Copyright © 2023-2025, Sierra Nevada -Copyright © 2019-2025, Simula Research Laboratory AS Copyright © 2023-2025, Sparx Systems Copyright © 2019-2025, System Strategy, Inc. Copyright © 2024-2025, The MathWorks Copyright © 2019-2025, Thematix Partners, LLC Copyright © 2019-2025, Tom Sawyer Copyright © 2023-2025, Tucson Embedded Systems, Inc. Copyright © 2019-2025, Universidad de Cantabria Copyright © 2019-2025, University of Alabama in Huntsville Copyright © 2023-2025, University of Arizona Copyright © 2019-2025, University of Detroit Mercy Copyright © 2019-2025, University of Kaiserslauten Copyright © 2020-2025, Willert Software Tools GmbH (SodiusWillert) Copyright © 2023-2025, Zuken Vitech Inc. -USE OF SPECIFICATION - TERMS, CONDITIONS & NOTICES The material in this document details an Object Management Group specification in accordance with the terms, conditions and notices set forth below. This document does not represent a commitment to implement any portion of this specification in any companys products. The information contained in this document is subject to change without notice. LICENSES The companies listed above have granted to the Object Management Group, Inc. (OMG) a nonexclusive, royalty-free, paid up, worldwide license to copy and distribute this document and to modify this document and distribute copies of the modified version. Each of the copyright holders listed above has agreed that no person shall be deemed to have infringed the copyright in the included material of any such copyright holder by reason of having used the specification set forth herein or having conformed any computer software to the specification. Subject to all of the terms and conditions below, the owners of the copyright in this specification hereby grant you a fully-paid up, non-exclusive, nontransferable, perpetual, worldwide license (without the right to sublicense), to use this specification to create and distribute software and special purpose specifications that are based upon this specification, and to use, copy, and distribute this specification as provided under the Copyright Act; provided that: (1) both the copyright notice identified above and this permission notice appear on any copies of this specification; (2) the use of the specifications is for informational purposes and will not be copied or posted on any network computer or broadcast in any media and will not be otherwise resold or transferred for commercial purposes; and (3) no modifications are made to this specification. This limited permission automatically terminates without notice if you breach any of these terms or conditions. Upon termination, you will destroy immediately any copies of the specifications in your possession or control. PATENTS The attention of adopters is directed to the possibility that compliance with or adoption of OMG specifications may require use of an invention covered by patent rights. OMG shall not be responsible for identifying patents for which a license may be required by any OMG specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. OMG specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. GENERAL USE RESTRICTIONS Any unauthorized use of this specification may violate copyright laws, trademark laws, and communications regulations and statutes. This document contains information which is protected by copyright. All Rights Reserved. No part of this work covered by copyright herein may be reproduced or used in any form or by any means--graphic, electronic, or mechanical, including photocopying, recording, taping, or information storage and retrieval systems--without permission of the copyright owner. DISCLAIMER OF WARRANTY WHILE THIS PUBLICATION IS BELIEVED TO BE ACCURATE, IT IS PROVIDED "AS IS" AND MAY CONTAIN ERRORS OR MISPRINTS. THE OBJECT MANAGEMENT GROUP AND THE COMPANIES LISTED ABOVE MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS PUBLICATION, INCLUDING BUT NOT LIMITED TO ANY WARRANTY OF TITLE OR -OWNERSHIP, IMPLIED WARRANTY OF MERCHANTABILITY OR WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE OR USE. IN NO EVENT SHALL THE OBJECT MANAGEMENT GROUP OR ANY OF THE COMPANIES LISTED ABOVE BE LIABLE FOR ERRORS CONTAINED HEREIN OR FOR DIRECT, INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, RELIANCE OR COVER DAMAGES, INCLUDING LOSS OF PROFITS, REVENUE, DATA OR USE, INCURRED BY ANY USER OR ANY THIRD PARTY IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS MATERIAL, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. The entire risk as to the quality and performance of software developed using this specification is borne by you. This disclaimer of warranty constitutes an essential part of the license granted to you to use this specification. RESTRICTED RIGHTS LEGEND Use, duplication or disclosure by the U.S. Government is subject to the restrictions set forth in subparagraph (c) (1) (ii) of The Rights in Technical Data and Computer Software Clause at DFARS 252.227-7013 or in subparagraph (c)(1) and (2) of the Commercial Computer Software - Restricted Rights clauses at 48 C.F.R. 52.227-19 or as specified in 48 C.F.R. 227-7202-2 of the DoD F.A.R. Supplement and its successors, or as specified in 48 C.F.R. 12.212 of the Federal Acquisition Regulations and its successors, as applicable. The specification copyright owners are as indicated above and may be contacted through the Object Management Group, 9C Medway Road, PMB 274, Milford, MA 01757, U.S.A. TRADEMARKS ® ® ® ® CORBA , CORBA logos , FIBO , Financial Industry Business Ontology , Financial Instrument Global ® ® ® ® ® ® ® Identifier , IIOP , IMM , Model Driven Architecture , MDA , Object Management Group , OMG , OMG ® ® ® ® ® ® ® Logo , SoaML , SOAML , SysML , UAF , Unified Modeling Language™, UML , UML Cube Logo , ® ® VSIPL , and XMI are registered trademarks of the Object Management Group, Inc. For a complete list of trademarks, see: https://www.omg.org/legal/tm_list.htm. All other products or company names mentioned are used for identification purposes only, and may be trademarks of their respective owners. COMPLIANCE The copyright holders listed above acknowledge that the Object Management Group (acting itself or through its designees) is and shall at all times be the sole entity that may authorize developers, suppliers and sellers of computer software to use certification marks, trademarks or other special designations to indicate compliance with these materials. Software developed under the terms of this license may claim compliance or conformance with this specification if and only if the software compliance is of a nature fully matching the applicable compliance points as stated in the specification. Software developed only partially matching the applicable compliance points may claim only that the software was based on this specification, but may not claim compliance or conformance with this specification. In the event that testing suites are implemented or approved by Object Management Group, Inc., software developed using this specification may claim compliance or conformance with the specification only if the software satisfactorily completes the testing suites. -OMG’S ISSUE REPORTING PROCEDURE All OMG specifications are subject to continuous review and improvement. As part of this process we encourage readers to report any ambiguities, inconsistencies, or inaccuracies they may find by completing the Issue Reporting Form listed on the main web page https://www.omg.org, under Documents, Report a Bug/Issue. - -Preface OMG Founded in 1989, the Object Management Group, Inc. (OMG) is an open membership, not-for-profit computer industry standards consortium that produces and maintains computer industry specifications for interoperable, portable, and reusable enterprise applications in distributed, heterogeneous environments. Membership includes Information Technology vendors, end users, government agencies, and academia. OMG member companies write, adopt, and maintain its specifications following a mature, open process. ® ® OMG’s specifications implement the Model Driven Architecture (MDA ), maximizing ROI through a full- lifecycle approach to enterprise integration that covers multiple operating systems, programming languages, middleware and networking infrastructures, and software development environments. OMG’s ® ® specifications include: UML (Unified Modeling Language™); CORBA (Common Object Request Broker Architecture); CWM™ (Common Warehouse Metamodel); and industry-specific standards for dozens of vertical markets. More information on the OMG is available at https://www.omg.org/. OMG Specifications As noted, OMG specifications address middleware, modeling, and vertical domain frameworks. All OMG Specifications are available from the OMG website at: https://www.omg.org/spec All of OMG’s formal specifications may be downloaded without charge from our website. (Products implementing OMG specifications are available from individual suppliers.) Copies of specifications, available in PostScript and PDF format, may be obtained from the Specifications Catalog cited above or by contacting the Object Management Group, Inc. at: OMG Headquarters 9C Medway Road, PMB 274 Milford, MA 01757 USA Tel: +1-781-444-0404 Fax: +1-781-444-0320 Email: pubs@omg.org Certain OMG specifications are also available as ISO standards. Please consult https://www.iso.org Issues All OMG specifications are subject to continuous review and improvement. As part of this process we encourage readers to report any ambiguities, inconsistencies, or inaccuracies they may find by completing the Issue Reporting Form listed on the main web page https://www.omg.org, under Specifications, Report an Issue. - -Table of Contents 1 Scope.................................................................................................................................................................................................1 2 Conformance.....................................................................................................................................................................................3 3 Normative References.......................................................................................................................................................................7 4 Terms and Definitions.......................................................................................................................................................................9 5 Symbols ..........................................................................................................................................................................................11 6 Introduction.....................................................................................................................................................................................13 6.1 API and Services Architecture ............................................................................................................................................13 6.2 Document Conventions.......................................................................................................................................................14 6.3 Document Organization ......................................................................................................................................................15 6.4 Acknowledgements .............................................................................................................................................................15 7 Platform Independent Model (PIM)................................................................................................................................................17 7.1 API Model...........................................................................................................................................................................17 7.1.1 Record .....................................................................................................................................................................17 7.1.2 Project Data Versioning ..........................................................................................................................................18 7.1.3 ExternalData and ExternalRelationship ..................................................................................................................22 7.1.4 Query ......................................................................................................................................................................24 7.2 API Services........................................................................................................................................................................25 7.2.1 ProjectService .........................................................................................................................................................25 7.2.2 ElementNavigationService......................................................................................................................................27 7.2.3 ProjectDataVersioningService ................................................................................................................................28 7.2.4 QueryService...........................................................................................................................................................32 7.2.5 ExternalRelationshipService ...................................................................................................................................32 7.2.6 ProjectUsageService ...............................................................................................................................................33 8 Platform Specific Models (PSMs) ..................................................................................................................................................35 8.1 REST/HTTP PSM...............................................................................................................................................................35 8.1.1 Overview .................................................................................................................................................................35 8.1.2 PIM API Model - REST/HTTP PSM Model Mapping...........................................................................................35 8.1.3 PIM API Services - REST/HTTP PSM Endpoints Mapping..................................................................................36 8.2 OSLC 3.0 PSM ...................................................................................................................................................................42 8.2.1 Overview .................................................................................................................................................................42 8.2.2 OSLC Nomenclature ...............................................................................................................................................43 8.2.3 PIM API Model – OSLC PSM Resource Mapping ................................................................................................44 8.2.4 PIM API Services – OSLC PSM Service Mapping ................................................................................................45 A Annex: Conformance Test Suite ....................................................................................................................................................55 A.1 ProjectService Conformance Test Cases ...........................................................................................................................55 A.2 ElementNavigationService Conformance Test Cases........................................................................................................57 A.3 ProjectDataVersioningService Conformance Test Cases ..................................................................................................61 A.4 QueryService Conformance Test Cases.............................................................................................................................72 A.5 ExternalRelationshipService Conformance Test Cases .....................................................................................................74 A.6 ProjectUsageService Conformance Test Cases .................................................................................................................76 A.7 Cross-Cutting Conformance Test Cases ............................................................................................................................77 B Annex: API and Services Examples and Cookbook ......................................................................................................................83 B.1 Examples ............................................................................................................................................................................83 B.2 Cookbook ...........................................................................................................................................................................93 Systems Modeling API and Services v1.0 i -List of Tables 1. Operations ......................................................................................................................................................................................25 2. Operations ......................................................................................................................................................................................27 3. Operations ......................................................................................................................................................................................28 4. Operations ......................................................................................................................................................................................28 5. Operations ......................................................................................................................................................................................31 6. Operations ......................................................................................................................................................................................32 7. Operations ......................................................................................................................................................................................33 8. Operations ......................................................................................................................................................................................33 9. PIM API Model - REST/HTTP PSM Model Mapping Table .......................................................................................................35 10. PIM to REST / HTTP PSM Mapping ..........................................................................................................................................36 11. PIM Concept to OSLC Resource type Mapping..........................................................................................................................44 12. PIM API Services - OSLC Services Mapping.............................................................................................................................45 ii Systems Modeling API and Services v1.0 -List of Figures 1. API and Services Provider and Consumer.......................................................................................................................................3 2. API and Services Architecture.......................................................................................................................................................13 3. Use of PIM and PSMs by Providers and Consumers ....................................................................................................................14 4. Types of Records ...........................................................................................................................................................................17 5. Project Data Versioning API Model ..............................................................................................................................................18 6. External Relationship API Model..................................................................................................................................................22 7. Query API Model...........................................................................................................................................................................24 8. ProjectService Operations..............................................................................................................................................................25 9. ElementNavigationService Operations ..........................................................................................................................................27 10. ProjectDataVersioningService Operations ..................................................................................................................................28 11. QueryService Operations .............................................................................................................................................................32 12. ExternalRelationshipService Operations .....................................................................................................................................32 13. ProjectUsageService Operations..................................................................................................................................................33 Systems Modeling API and Services v1.0 iii -iv Systems Modeling API and Services v1.0 -1Scope The purpose of this standard is to specify the Systems Modeling Application Programming Interface (API) and Services that provide standard services to access, navigate, and operate on KerML-based models [KerML], and, in particular, SysML models [SysML]. The standard services facilitate interoperability both across SysML modeling environments and between SysML modeling environments and other engineering tools and enterprise services. The Systems Modeling API and Services specifies the types and details of the requests that can be made and responses that can be received by software applications that are consuming the services to software applications that are providing the services. The Systems Modeling API and Services specification includes the Platform Independent Model (PIM) - see Clause 7 - and two Platform Specific Models (PSMs) - see Clause 8 : REST/HTTP PSM and OSLC PSM. Systems Modeling API and Services v1.0 i -ii Systems Modeling API and Services v1.0 -2Conformance This specification defines the Systems Modeling API and Services that provide standard services to access, navigate, and operate on KerML-based models [KerML] and, in particular, SysML models [SysML]. The specification comprises this document together with the content of the machine-readable files listed on the cover page. If there are any conflicts between this document and the machine-readable files, the machine-readable files take precedence. A Systems Modeling API and Services Provider is a software application that provides the services defined in this specification. A Systems Modeling API and Services Consumer is a software application that consumes the services defined in this specification and provided by the Service Provider. Consumers send requests to Providers and receive responses with results, as illustrated in Fig. 1 below. For brevity, this specification uses the phrase Service Provider for Systems Modeling API and Services Provider, and the term Service Consumer for Systems Modeling API and Services Consumer. interaction API_Services_Provider_Consumers [ API_Services_Provider_Consumers ] API and Services Consumer API and Services Provider 1: Request Uses the API Implements the API 2: Response Figure 1. API and Services Provider and Consumer A Service Provider can conform to this specification at the PSM or PIM level. 1. PSM-level Conformance - A Service Provider demonstrating PSM-level Conformance implements one or more of the Systems Modeling API and Services PSMs defined in this specification. For example, a Provider can implement the REST/HTTP PSM, the OSLC PSM, or both. PSM-level conformance of Service Providers ensures interoperability of Service Consumers using the PSM across the different Service Providers. See Clause 8 . 2. PIM-level Conformance - A Service Provider demonstrating PIM-level Conformance implements a PSM that is not defined in this specification but is based on Systems Modeling API and Services PIM defined in this specification. The Service Provider shall define the PSM and the mapping from PIM to PSM with the goal that the new PSM may become part of future versions of this specification. See Clause 7 . A Service Provider tool must demonstrate conformance to one or more services, as described below. Systems Modeling API and Services v1.0 3 -1. ProjectService Conformance - A Service Provider must implement all the operations in the ProjectService, and demonstrate that the implementation successfully passes all the ProjectService Conformance Test Cases (see A.1 ) and Cross-Cutting Conformance Test Cases (see A.7 ). 2. ProjectService Read Conformance - A Service Provider must implement the following operations in the ProjectService, and demonstrate that the implementation successfully passes all the ProjectService Conformance Test Cases (see A.1 ) and Cross-Cutting Conformance Test Cases (see A.7 ) related to these operations. The UML attribute isQuery is set to true (isQuery=true) for these operations. 1. getProjectById 2. getProjects 3. ElementNavigationService Conformance - A Service Provider must implement all the operations in the ElementNavigationService, and demonstrate that the implementation successfully passes all the ElementNavigationService Conformance Test Cases (see A.2 ) and Cross-Cutting Conformance Test Cases (see A.7 ). ElementNavigationService includes operations that get data and not create/modify any data. As such, the ElementNavigationService Conformance does not have a corresponding ElementNavigationService Read Conformance. 4. ProjectDataVersioningService Conformance - A Service Provider must implement all the operations in the ProjectDataVersioningService, and demonstrate that the implementation successfully passes all the ProjectDataVersioningService Conformance Test Cases (see A.3 ) and Cross-Cutting Conformance Test Cases (see A.7 ). 5. ProjectDataVersioningService Read Conformance - A Service Provider must implement the following operations in the ProjectDataVersioningService, and demonstrate that the implementation successfully passes all the ProjectDataVersioningService Conformance Test Cases (see A.3 ) anCross-Cutting Conformance Test Cases (see A.7 ) related to these operations. The UML attribute isQuery is set to true (isQuery=true) for these operations. 1. getCommits 2. getHeadCommit 3. getCommitById 4. getCommitChange 5. getCommitChangeById 6. getBranches 7. getBranchById 8. getDefaultBranch 9. getTags 10. getTagById 11. getTaggedCommit 12. diffCommits 6. QueryService Conformance - A Service Provider must implement all the operations in the Query Service, and demonstrate that the implementation successfully passes all the QueryService Conformance Test Cases (see A.4 ) and Cross-Cutting Conformance Test Cases (see A.7 ). 7. QueryService Read Conformance - A Service Provider must implement the following operation in the QueryService, and demonstrate that the implementation successfully passes all the QueryService Conformance Test Cases (see A.4 ) and Cross-Cutting Conformance Test Cases (see A.7 ) related to this operation. The UML attribute isQuery is set to true (isQuery=true) for this operation. 1. executeQuery 8. ExternalRelationshipService Conformance - A Service Provider must implement all the operations in the ExternalRelationshipService, and demonstrate that the implementation successfully passes all the ExternalRelationshipService Conformance Test Cases (see A.5 ) and Cross-Cutting Conformance Test Cases (see A.7 ). ExternalRelationshipService includes operations that get data and not create/modify any data. As such, the ExternalRelationshipService Conformance does not have a corresponding ExternalRelationshipService Read Conformance. 9. ProjectUsageService Conformance - A Service Provider must implement all the operations in the ProjectUsageService, and demonstrate that the implementation successfully passes all the ProjectUsageService Conformance Test Cases (see A.6 ) and Cross-Cutting Conformance Test Cases (see A.7 ). 10. ProjectUsageService Read Conformance - A Service Provider must implement the following operation in the ProjectUsageService, and demonstrate that the implementation successfully passes all 4 Systems Modeling API and Services v1.0 -the ProjectUsageService Conformance Test Cases (see A.6 ) and Cross-Cutting Conformance Test Cases (see A.7 ) related to this operation. The UML attribute isQuery is set to true (isQuery=true) for this operation. 1. getProjectUsages Derived Property Conformance Various Element (KerML) data may have derived properties defined for them. However, not all Service Providers are required to perform the computations that evaluate these properties and obtain their values. There are two specific Derived Property Conformance levels, as described below. A Service Provider demonstrating Derived Property Conformance must demonstrate one of two conformance levels presented below. As with other Service Conformances, it is also permitted for a Service Provider to claim no Derived Property conformance. Each of the two Derived Property Conformance levels described below has different guarantees on derived property values as inputs and derived property values as outputs of operations covered by this specification. These guarantees need to be met across all the services and operations supported by the Service Provider, such as in the case of operations that return Element data in the response, e.g. ElementNavigationService.getElementById or QueryService.executeQuery. Furthermore, the guarantees are to be met for all Elements, whether the Element was originally supplied by a Service Consumer in Service operations that write Element data (primarily ProjectDataVersioningService.createCommit), or however else the Service Provider obtains Project contents to store and output, such as import operations not covered by this specification. The two Derived Property Conformance levels are the following: 1. Derived Property Passthrough Conformance: A Service Provider declaring this conformance level must take at face value any derived property values obtained, and store these values along with all the other non-derived property values of the Element, in order to be faithfully reproduced in any operation of any Service where the Service Provider returns the properties of this Element to the Service Consumer. In addition, if the Service Provider conforms with the QueryService, these stored derived property values must be usable in Query structures as PrimitiveConstraint properties. The Service Provider is not required to ever perform the derived property computations or verify that derived property values presented by a Service Consumer are correct. Any derived property values obtained as an input to an operation defined in this specification are accepted as-is. 2. Derived Property Full Conformance: A Service Provider declaring this conformance level must, for operations in any Service where Element (KerML) data is returned, guarantee that the derived properties for the Element are included in the response with their correctly computed, up-to-date value. Furthermore, if the Service Provider conforms with the QueryService, it also ensures that derived properties can be used in Query structures as PrimitiveConstraint properties, and that the query execution will consider the correctly computed and up-to-date values of such derived properties. In operations where Elements are given as input, the Service Consumer is free to omit derived properties, since their value will be computed by the Service Provider. Note that the actual time when the computation of derived feature values is to be performed, such as just in time when producing a response, or ahead of time upon the reception of the latest commit that affected the derived feature value, is an implementation detail of the Service Provider and not prescribed for Conformance. However, appropriate caution should be taken as the values of derived properties of a given Element may be affected by commits that do not directly change that Element. Systems Modeling API and Services v1.0 5 -6 Systems Modeling API and Services v1.0 -3Normative References [GraphQL] GraphQL https://graphql.org/ [Gremlin] Gremlin Graph Traversal Machine and Language https://tinkerpop.apache.org/gremlin.html [IRI] Internationalized Resource Identifiers (IRI) https://www.w3.org/International/articles/idn-and-iri/ [KerML] Kernel Modeling Language (KerML), Version 1.0 https://www.omg.org/spec/KERML/1.0 TM [MOFVD] MOF2 Versioning and Development Lifecycle (MOFVD ), Version 2.0 https://www.omg.org/spec/MOFVD/2.0 [OpenAPI] OpenAPI Specification https://www.openapis.org/ [OSLC] Open Services for Lifecycle Collaboration (OSLC) http://open-services.net/ TM [QVT] MOF Query/View/Transformation (QVT ), Version 1.3 https://www.omg.org/spec/QVT/1.3 [SEBoK] Systems Engineering Body of Knowledge (SEBoK) www.sebokwiki.org [SE Handbook] INCOSE Systems Engineering Handbook https://www.incose.org/products-and-publications/se-handbook TM [SMOF] MOF Support for Semantic Structures (SMOF ), Version 1.0 https://www.omg.org/spec/SMOF/1.0 [SPARQL] SPARQL Query Language for RDF https://www.w3.org/TR/rdf-sparql-query/ [SQL] ISO/IEC 9075:2016, Information technology — Database languages — SQL https://www.iso.org/standard/63555.html [STEP] ISO 10303-233:2012 (STEP) https://www.iso.org/standard/55257.html ® [SysML] OMG Systems Modeling Language (SysML ), Version 2.0 https://www.omg.org/spec/SYSML/2.0 [UML] Unified Modeling Language (UML), Version 2.5.1 https://www.omg.org/spec/UML/2.5.1 [UUID] Universally Unique IDentifier (UUID) URN Namespace https://tools.ietf.org/html/rfc4122 Systems Modeling API and Services v1.0 7 -® [XMI] XML Metadata Interchange (XMI ), Version 2.5.1 https://www.omg.org/spec/XMI/2.5.1 8 Systems Modeling API and Services v1.0 -4Terms and Definitions Various terms and definitions are specified throughout the body of this specification. Systems Modeling API and Services v1.0 9 -10 Systems Modeling API and Services v1.0 -5Symbols There are no special symbols defined in this specification. Systems Modeling API and Services v1.0 11 -12 Systems Modeling API and Services v1.0 -6Introduction 6.1 API and Services Architecture The Systems Modeling API and Services includes the following. (1) Platform-Independent Model (PIM) provides a service specification independent of any platform or technology. This specification defines each of the services and their operations with inputs and outputs. The PIM serves as the logical API model. (2) Platform-Specific Models (PSMs) are bindings of the PIM using a particular technology, such as REST/HTTP, SOAP, Java, and .NET. Multiple platform-specific models can exist for a given PIM. Two PSMs are provided in this specification: • REST/HTTP PSM - a binding of the PIM as a REST/HTTP API using OpenAPI specification. • OSLC PSM - a binding of the PIM as services based on the OSLC standard. For each PSM, a mapping is defined. This mapping is used to generate the PSM from the PIM. Fig. 2 illustrates the PIM, PSMs, Service Providers that implement API PSMs, and Service Consumers that consume the API PSMs from multiple Providers. API and Service Definitions and Operations Platform Independent Model (PIM) «Conforms to» «Conforms to» «Conforms to» «Conforms to» «Conforms to» REST/HTTP API OSLC API Python API Java API ... Others Platform-specific Models (PSMs) «Implements» «Implements» «Implements» «Implements» Service Provider 1 Service Provider 2 Service Provider 3 Systems Modeling API and Services Providers and Consumers «Consumes from» «Consumes from» «Consumes from» Service Consumer 1 Service Consumer 2 (REST/HTTP API) (Python API) Figure 2. API and Services Architecture Service specifications in the PIM do not prescribe or constrain the architecture of the Service Providers. For example, Service Providers with file-based, 3-tier application-based, or federated microservices-based architectures can all implement one or more PSMs derived from the same service specifications (PIM). Service Consumers that use a specific PSM should be interoperable across multiple Service Providers that implement that PSM without requiring any modification in the consumer. Systems Modeling API and Services v1.0 13 -Programmatic Authoring Graphical Authoring Textual Authoring Environment Environment Environment Active validation (Service Consumer) (Service Consumer) (Service Consumer) based on Request API Definition (PIM) Response Conforms to Data OSLC 3.0 API REST/HTTP (PSM 2) (PSM 1) Realizes KerML-based Systems Modeling API Model CRUD Services Metamodel and Services Provider (Pilot Implementation) Schema influenced by NoSQL GraphDB RDBMS Figure 3. Use of PIM and PSMs by Providers and Consumers Fig. 3 illustrates the role of PIM and PSMs in the context of Systems Modeling API and Services providers and consumers. The Systems Modeling API and Services, version 1.0, includes two PSMs, specifically the REST/HTTP PSM and OSLC 3.0 PSM. A System Modeling API and Services provider implements either or both the PSMs using its native technology stack, such as databases and web-service frameworks. Service consumers, such as those used for programmatic, graphical, or textual authoring, navigation, and querying data use the PSMs (e.g. REST/HTTP API), agnostic of the native technology stack of the providers. The choice of REST/HTTP PSM is key. Most modern programming languages provide libraries for consuming REST/HTTP APIs. Enterprise applications, written in any modern programming language, can consume the standard Systems Modeling API and Services, and interoperate with multiple providers. 6.2 Document Conventions The following stylistic conventions are applied in the presentation of the Platform Independent Model (PIM) of the Systems Modeling API and Services. Service definitions 1. Names of classes representing services start with an uppercase letter and use the camel case notation, such as ElementNavigationService. 2. Names of operations representing the API calls available for each service start with a lowercase letter and are italicized, such as getElementById Input and output data 1. Names of classes representing data that is the input or output of services start with an uppercase letter, such as Project and Data 2. Names of attributes representing the details of the data that is the input or output of services start with a lowercase letter and are italicized, such as identifier 14 Systems Modeling API and Services v1.0 -The services and operations in the PIM are presented using class diagrams and tables with descriptions of each operation. The input and output data for services in the PIM are presented using class diagrams followed by detailed descriptions. 6.3 Document Organization The rest of this document is organized into two major clauses. • Clause 7 - Platform Independent Model (PIM) of the Systems Modeling API and Services • Clause 8 - Platform Specific Models (PSMs) of the Systems Modeling API and Services ◦ 8.1 - REST/HTTP PSM ◦ 8.2 - OSLC PSM These clauses are followed by two annexes. • Annex A defines the suite of conformance tests that must be used to demonstrate the conformance of Service Providers to this specification - see Clause 2 . • Annex B includes the following. ◦ Examples of requests and responses for the REST/HTTP API endpoints, and ◦ Cookbook with a collection of recipes, as Jupyter notebooks, demonstrating patterns and examples for using the Systems Modeling API and Services 6.4 Acknowledgements The primary authors of this specification document, the PIM, and the REST/HTTP PSM are: • Manas Bajaj, Intercax LLC • Ivan Gomes, Twingineer LLC The primary authors of the OSLC PSM are: • David Honey, IBM • Jad El-Khoury, KTH Royal Institute of Technology • Jim Amsden, IBM Other contributors include: • Tomas Vileiniskis, Dassault Systèmes The specification was formally submitted for standardization by the following organizations: • 88Solutions Corporation • Dassault Systèmes • GfSE e.V. • IBM • INCOSE • Intercax LLC • Lockheed Martin Corporation • Model Driven Solutions, Inc. • PTC • Simula Research Laboratory AS Systems Modeling API and Services v1.0 15 -However, work on the specification was also supported by over 200 people in 80 organizations that participated in the SysML v2 Submission Team (SST). The following individuals had leadership roles in the SST: • Manas Bajaj, Intercax LLC (API and services development lead) • Yves Bernard, Airbus (v1 to v2 transformation co-lead) • Bjorn Cole, Lockheed Martin Corporation (metamodel development co-lead) • Sanford Friedenthal, SAF Consulting (SST co-lead, requirements V&V lead) • Charles Galey, Lockheed Martin Corporation (metamodel development co-lead) • Karen Ryan, Siemens (metamodel development co-lead) • Ed Seidewitz, Model Driven Solutions (SST co-lead, pilot implementation lead) • Tim Weilkiens, oose (v1 to v2 transformation co-lead) The specification was prepared using CATIA Magic/No Magic modeling tools and the OpenMBEE system for model publication (http://www.openmbee.org), supported by the 3DEXPERIENCE platform, with the invaluable support of the following individuals: • Tyler Anderson, Dassault Systèmes • Christopher Delp, Jet Propulsion Laboratory • Jackson Galloway, Dassault Systèmes • Ivan Gomes, Jet Propulsion Laboratory • Robert Karban, Jet Propulsion Laboratory • Christopher Klotz, Dassault Systèmes • John Watson, Lightstreet consulting The following individuals made significant contributions to the API and Services pilot implementation developed by the SST in conjunction with the development of this specification: • Manas Bajaj, Intercax LLC • Ivan Gomes, Twingineer LLC • Brian Miller, Intercax LLC 16 Systems Modeling API and Services v1.0 -7Platform Independent Model (PIM) 7.1 API Model 7.1.1 Record Record attributes +id : UUID{readOnly} +resourceIdentifier : IRI [0..1] +alias : String [0..*] +name : String [0..1]{subsets alias} +description : String Project Commit CommitReference DataVersion DataIdentity Query Tag Branch Figure 4. Types of Records Record - A Record represents any data that is consumed (input) or produced (output) by the Systems Modeling API and Services. A Record is an abstract concept from which other concrete concepts inherit. A Record has the following attributes: • id is the UUID assigned to the record • resourceIdentifier is an IRI for the record • alias is a collection of other identifiers for this record, especially if the record was created or represented in other software applications and systems. Note that for DataIdentity and DataVersion records, this does not conflict with Element.aliasIds in KerML. Instead, it enables service providers to add other aliases on any record • name is an optional human-friendly identifier for a record. The value assigned to the name for a given record must be in the set of values assigned to alias for that record • description is a statement that provides details about the record. Systems Modeling API and Services v1.0 17 -7.1.2 Project Data Versioning Record attributes +id : UUID{readOnly} +resourceIdentifier : IRI [0..1] +alias : String [0..*] +name : String [0..1]{subsets alias} +description : String DataVersion DataIdentity Data version payload operations identity version +getId() : UUID 1 0..1 1 1..* 0..1 +/versionedData 0..* change 1..* ProjectUsage Element ExternalData ExternalRelationship {usedProject = usedProjectCommit.o wningProject} Relationship 0..* Project Commit +usedProjectCommit attributes attributes 1 +queries : Query [0..*] +created : ISO8601DateTime 0..* /project commit +name : String{redefines name} +created : ISO8601DateTime 1 1 previous Commits +owningProject +commits 0..* 1 0..* referencedCommit 1 head 1 +taggedCommit 1 {redefines {redefines CommitReference referencedCommit} referencedCommit} {referencedCommit.owningProject = owningProject} 0..1 +owningProject 1 +owningProject 1 +owningProject 1 +commitReferences {redefines {redefines 0..* owningProject} owningProject} attributes 0..* +created : ISO8601DateTime +name : String{redefines name} +deleted : ISO8601DateTime +branches Branch 1..* 0..* {subsets commitReferences} +defaultBranch Tag 1 {subsets branches} 0..* +tags 0..* {subsets commitReferences} Figure 5. Project Data Versioning API Model The class diagram above presents concepts related to Project and Data Versioning Service. Data - Data represents any entity that can be created, updated, deleted, and queried by the Systems Modeling API and Services. In the PIM, Data is represented as an Interface that is realized by the following concepts in the scope of Systems Modeling API and Services. • Element, root metaclass in the SysML v2 language metamodel • External Data • External Relationship • Project Usage Each realization of Data must implement the getId() operation that provides a valid UUID. Data Identity - Data Identity is a subclass of Record that represents a unique, version-independent representation of Data through its lifecycle. A Data Identity is associated with 1 or more Data Version records that represent different versions of the same Data. A Data Identity record has the following additional attributes: • createdAt is a derived attribute that references the Commit in a project in which the given Data was created • deletedAt is a derived attribute that references the Commit in a project in which the given Data was deleted Data Version - Data Version is a subclass of Record that represents Data at a specific version in its lifecycle. A Data Version record is associated with exactly one Data Identity record. Data Version serves as a wrapper for Data (payload) in the context of a Commit in a Project; associating the data identity with the state of the Data (payload) in the specific (range of) Commits, or no payload if no Data element with the given identifier is present at that 18 Systems Modeling API and Services v1.0 -Commit. Different versions of the same Data, identified by the same UUID values returned by Data.getId(), are represented in the following manner: • One (1) Data Identity record is created for all versions of the same Data, where Data Identity.id returns the same UUID value as Data.getId() • A Data Version record is created for each version of Data (and, if needed, also for a Commit where no Data exists for the given identity), where: ◦ Data Version.payload is set to Data if exists in the commit, null otherwise. ◦ Data Version.identity is set to the Data Identity common to all versions of the same Data. ◦ Data Version.id is set to a new, randomly generated UUID for the specific Data Version record. Data Version record has the following additional attributes: • commit is the project commit at which the wrapped data (payload) was created, modified, or deleted • /project is a derived attribute referencing the owning project Project - Project is a subclass of Record that represents a container for other Records and an entry point for version management and data navigation. The Project record has the following attributes: • identifiedData is a derived attribute that is the set of Data Identity records corresponding to the Data contained in the project • commit is the set of all commits in the Project • commitReference is the set of all commit references in the Project • branch is the set of all the branches in the Project and a subset of commitReference • defaultBranch is the default branch in the Project and a subset of branch • tag is the set of all the tags in the Project and a subset of commitReference • usage is the set of Project Usage records representing all other Projects being used by the given Project (Project Usage.usedProject) • queries is the set of Query records owned by the project. Each Query record represents a saved query for the given project. See 7.1.4 Query for details. • name is a human-friendly identifier for a Project • created is the creation timestamp for the project, in ISO8601DateTIme format A project also represents a permission target at which access and authorization controls may be applied to teams associated with a project. ProjectUsage - ProjectUsage is a subclass of Record that represents the use of a Project in the context of another Project. ProjectUsage is represented as a realization of Data, and has the following attributes: • usedProject references the Project being used • usedProjectCommit references the Commit of the Project being used Commit - Commit is a subclass of Record that represents the changes made to a Project at a specific point in time in its lifecycle, such as the creation, update, or deletion of data in a Project. A Project has 0 or more Commits. A Commit has the following additional attributes: • created is the timestamp at which the Commit was created, in ISO8601DateTime format • owningProject is the Project that owns the Commit • previousCommit is the set of immediately preceding Commits • change is the set of Data Version records representing Data that is created, updated, or deleted in the Commit • versionedData is the set of cumulative Data Version records in a Project at the Commit Clarifications and Invariants: Systems Modeling API and Services v1.0 19 -• Commit.versionedData must indicate only the Data records that actually exist at the given Commit; all listed DataVersion records must have their payload attribute set to a non-null Data record. • Commit.change indicates deletions by listing DataVersion records with their payload attribute set to null. This is only valid if at least one Commit in previousCommits contains a DataVersion with the same identity in its versionedData (i.e. only existing Data records may be deleted). • DataVersion.identity is unique among records listed in Commit.versionedData and in Commit.change. • A Commit must resolve all conflicts in its parent Commits: if the Commit C has two parent Commits C a and C in C.previousCommits, where C .versionedData lists a DataVersion D but C.versionedData does b a a not contain D (either the Data associated with D .identity is different, or not present at all), then C.change a a must list a DataVersion with D .identity. a • Version histories must monotonically increase in time: for Commit C, the value of C.created must be strictly newer than the value of D.created for any commit D in C.previousCommit. An implementation should ensure that the selected timestamp resolution (which corresponds to a required number of decimals in the ISO 8601 second field) is sufficient to ensure the strict monotonicity of the timestamps for the supported number of Commits per second per branch. The versionedData for a Commit is computed as follows: 1. Let updatedNotDeleted be all DataVersions in the change set of the Commit, excluding deletions. 2. Let updatedIdentities be all DataIdentities in the change set of the Commit, including deletions. 3. Let retainedWithDuplicates be the union of the versionedData of all the previousCommits of this Commit, excluding DataVersions whose identities are in the updatedIdentities of this commit. 4. Let retained be the set of DataVersions obtained from retainedWithDuplicates by choosing from each subset of duplicate DataVersions with the same identity a single one of them to include. See the Note below for additional clarification. 5. The versionedData of this Commit is the union of the updatedNotDeleted set and the retained set. Note. If there are multiple previousCommits, retainedWithDuplicates may include DataVersions from different previousCommits with the same identity. If any of the previousCommits have DataVersions with the same identity but different payloads, then this Commit is required to have resolved this merge conflict by including merged DataVersions for the conflicting identities in its change set, so the conflicting DataVersions will not be included in retainedWithDuplicates. Therefore, any DataVersions in retainedWithDuplicates with the same identity must also have the same payload, and any one of them can be chosen for inclusion in the versionedData of this commit. This is formalized in the following OCL: let updatedNotDeleted : Set(DataVersion) = change->select(payload <> null) in let updatedIdentities : Set(DataIdentity) = change.identity in let retainedWithDuplicates : Bag(DataVersion) = previousCommits.versionedData->select(oldData | updatedIdentities->excludes(oldData.identity) ) in let retained : Set(DataVersion) = retainedWithDuplicates.identity->asSet()->collect(retainedID | retainedWithDuplicates->any(identity == retainedID) )->asSet() in versionedData = updatedNotDeleted->union(retained) Commits are immutable. For a given Commit record, the value of Commit.change cannot be modified after a Commit has been created. If a modification is required, a new Commit record can be created with a different value of Commit.change. 1 Commits are not destructible . A Commit record cannot be deleted during normal end-user operation. Commits represent the history and evolution of a Project. Deleting and mutating Commit records must be disabled for the normal end-user operations to preserve Project history. 20 Systems Modeling API and Services v1.0 -1 Note. A provider tool may provide administrative functions to repair the Commit graph of a Project but this is not considered a normal end-user operation. CommitReference - CommitReference is an abstract subclass of Record that references a specific Commit (CommitReference.referencedCommit). Project.commit is the set of all the Commit records for a given Project. Project.commitReferences identifies specific Commit records in a Project that provide the context for navigating the Data in a Project. A CommitReference has the following additional attributes: • created is the timestamp at which the CommitReference was created, in ISO8601DateTime format • deleted is the timestamp at which the CommitReference was deleted, in ISO8601DateTime format • name is a human-friendly identifier for a CommitReference, inherited from Record Two special types of CommitReference are Branch and Tag, as described below. Branch - Branch is an indirect subclass of Record (via CommitReference) that represents an independent line of development in a project. A Project can have 1 or more branches. When a Project is created, a default branch is also created. The default branch of a project can be changed, and a project can have only 1 default branch. A Branch is a type of CommitReference. A Branch is a pointer to a commit (Branch.head). The commit history of a Project on a given branch can be computed by recursively navigating Commit.previousCommit, starting from the head commit of the branch (Branch.head). A Branch has the following additional attributes: • created is the timestamp at which the Branch was created, in ISO8601DateTime format. This attribute is inherited from Commit Reference. • deleted is the timestamp at which the Branch was deleted, in ISO8601DateTime format. This attribute is inherited from Commit Reference. • head is the commit to which the branch is currently pointing. It represents the latest state of the project on the given branch • owningProject is the project that owns the given branch Branches are mutable. Since a Branch is a pointer to a Commit, it can be updated to point to a different Commit. If a new Commit is created on a Project Branch, the value of Branch.head refers to that new Commit. Branches are destructible under normal end-user operation. Branches can be deleted and merged with other branches. Tag - Tag is an indirect subclass of Record (via CommitReference) used for annotating specific commits-of-interest during Project development, such as for representing Project milestones, releases, baselines, or snapshots. A Project can have 0 or more tags. A Tag has the following additional attributes: • created is the timestamp at which the Tag was created, in ISO8601DateTime format. This attribute is inherited from Commit Reference. • deleted is the timestamp at which the Tag was deleted, in ISO8601DateTime format. This attribute is inherited from Commit Reference. • taggedCommit is a pointer to a commit • owningProject is the project that owns the given tag Tags are immutable. Tag.taggedCommit cannot be modified after a Tag record has been created. If Tag.taggedCommit needs to be modified to refer to a different Commit record, then the existing Tag can be deleted and a new Tag can be created with the same name and description. Tags are destructible under normal end-user operation. The table below summarizes the Mutability and Destruction semantics for Commit, Branch, and Tag. Systems Modeling API and Services v1.0 21 -Type of Record Mutable Destructible Commit No No Branch Yes Yes Tag No Yes Timestamps - The following requirements and recommendations apply to timestamps: • All attributes typed by ISO8601DateTime must be communicated over the API as either a time instant expressed directly on the UTC (Coordinated Universal Time) time scale, or on a local time scale with an explicit time shift with respect to UTC, as specified in [ISO8601-1]. The reason is to avoid any implicit dependency on timezone-specific representation of time instants. ◦ Examples of valid UTC timestamps in [ISO8601-1] extended format are: 2024-12-18T16:45:34.635726Z and 2024-12-18T16:45:34.635726+00:00. ◦ Examples of valid local timestamps in [ISO8601-1] extended format are: 2024-12-18T11:45:34.635726-05:00 and 2024-12-18T17:45:34.635726+01:00. These example values represent the same time instant as the previous UTC timestamp examples. ◦ Note. Be aware that the explicit time shift for a selected timezone may change throughout a calendar year due to switching between standard and daylight saving time, typically by one hour. • Service implementations should ensure that all timestamps for a given Project are expressed in UTC or apply a time shift for one selected timezone. • For reasons of simplicity it is recommended that service implementations consistently apply UTC timestamps, if there is no requirement to support a local time scale. • Computation of time intervals between two timestamps should make use of an appropriate software library that supports UTC-based arithmetic including handling of possible leap seconds. 7.1.3 ExternalData and ExternalRelationship Data operations +getId() : UUID elementEnd ExternalRelationship Element attributes ExternalData specification : String [0..1] language : String [0..1] attributes externalDataEnd resourceIdentifier : IRI Figure 6. External Relationship API Model The class diagram above presents concepts related to ExternalRelationship Service. ExternalRelationship - ExternalRelationship is a realization of Data, and represents the relationship between a KerML Element [KerML] available from a service provider to ExternalData available over the web using an IRI. The ExternalData may be a KerML Element available from another service provider using an IRI. A hyperlink 22 Systems Modeling API and Services v1.0 -between a KerML Element to a web resource is the most primitive example of an ExternalRelationship. An ExternalRelationship has the following attributes: • specification is the formal representation of the semantics of the ExternalRelationship. The specification can be a collection of mathematical expressions. For example, an ExternalRelationship can be defined to map the attributes of a KerML Element to the attributes of an ExternalData. In this case, the specification would contain mathematical expressions, such as equations, representing the mapping. This is an optional attribute. • language is the name of the expression language used for the specification. This is an optional attribute. ExternalData - ExternalData is a realization of Data, and represents a resource available over the web using an IRI. ExternalData is defined only for the purpose of defining an ExternalRelationship. An ExternalData has the following additional attributes. • resourceIdentifier is the IRI of the resource represented by the ExternalData Systems Modeling API and Services v1.0 23 -7.1.4 Query Record attributes +id : UUID{readOnly} +resourceIdentifier : IRI [0..1] +alias : String [0..*] +name : String [0..1]{subsets alias} +description : String Query Project attributes +project +queries +name : String{redefines name} 1 0..* select : String [0..*] scope : Data [0..*] orderBy : String [0..*] where 1 +constraint Constraint 2..* PrimitiveConstraint CompositeConstraint attributes inverse : Boolean 0..1 property : String value [1..*] operator 1 operator 1 JoinOperator Operator and instanceOf or = < <= > >= in Figure 7. Query API Model The class diagram above presents concepts related to the Query service. Query- Query is a subclass of Record that represents a precise and language-independent request for information retrieval using the Systems Modeling API and Services. Query can be mapped to commonly used query languages, such as SQL, Gremlin, GraphQL, and SPARQL. A Query record has the following attributes: • name is a human-friendly identifier for a Query 24 Systems Modeling API and Services v1.0 -• select is a list of properties of Data (or its realizations) that will be included for each Data object in the query response. If no properties are specified, then all the properties will be included for each Data object in the query response. • scope is a list of Data objects that define the scope context for query execution. The default scope of a Query is the owning Project. • where is a Constraint that represents the conditions that Data objects in the query response must satisfy • orderBy is a list of properties of Data (or its realizations) that are used for sorting the Data objects in the query response. The order of properties in the list governs the sorting order. Constraint - Constraint is an abstract concept that represents conditions that must be satisfied by Data objects in the query response. PrimitiveConstraint is a concrete subtype of Constraint that represents simple conditions that can be modeled using the property-operator-value tuple, e.g. mass <= 4 kg., or type instanceOf Generalization. A PrimitiveConstraint has the following attributes: • property is a property of Data (or its realizations) that is being constrained • operator is of type Enumeration whose literals are mathematical operators, as shown in the figure above • value is either a list of primitive objects, such as String, Boolean, Integer, Double, UUID, or null. An explicit type is not assigned to this property since it can be any of the specified types above. • inverse is of type Boolean. If true, a logical NOT operator is applied to the PrimitiveConstraint. CompositeConstraint is a concrete subtype of Constraint that represents complex conditions composed of two or more Constraints using logical AND or OR operator. CompositeConstraint has the following attributes: • constraint is the set of Constraints being composed • operator is the logical operator for composing the Constraints 7.2 API Services 7.2.1 ProjectService ProjectService operations getProjects() : Project [0..*]{query} getProjectById( projectId : UUID ) : Project [0..1]{query} createProject( name : String, description : String [0..1] ) : Project updateProject( projectId : UUID, name : String [0..1], description : String [0..1], defaultBranch : Branch [0..1] ) : Project deleteProject( projectId : UUID ) : Project Figure 8. ProjectService Operations Table 1. Operations Name Documentation Create a new project with the given name and createProject description (optional). Get all projects. getProjects Update the project with the given id (projectId). updateProject Systems Modeling API and Services v1.0 25 -Name Documentation Delete the project with the given id (projectId). The following pre-condition must be satisfied for a project to be deleted. 1. Project with given projectId exists. The following post-condition must be satisfied for a project to be deleted. 1. All operations of all services where projectId (Id of the deleted project) is an input argument will return null. Note that when a project is being deleted, elements owned by the project may be used in other projects via project usages. The detection of this condition and subsequent behavior is left to the API and Service providers. As a general recommendation, API and Service providers may implement different behaviors, such as, but not limited to, the following. 1. Allow projects to be deleted irrespective of deleteProject any of the elements from its latest tag (commit), default or pre-specified branches, being used in other projects, via project usages. The Service provider guarantees that future operations involving the using projects will continue to work in the absence of referenced elements owned by the deleted project. It is up to the Service Provider to find a way to implement this guarantee, such as by suppressing such nonexistent element references or reporting only unique identifiers of nonexistent element references in operation results. 2. Allow projects to be deleted only if none of the elements in a list of pre-specified commits (e.g. latest tag and main branch) are being used in the list of pre-specified commits (e.g. latest tag or main branch) of another project, via project usage. 3. Allow projects to be deleted only if none of their commits are referenced by project usages in any of the commits of any other project. Get project with the given id (projectId). getProjectById 26 Systems Modeling API and Services v1.0 -7.2.2 ElementNavigationService ElementNavigationService operations getElements( project : Project, commit : Commit ) : Element [0..*]{query} getElementById( project : Project, commit : Commit, elementId : UUID ) : Element [0..1]{query} getRelationshipsByRelatedElement( project : Project, commit : Commit, elementId : UUID, direction : Direction ) : Relationship [0..*]{query} getRootElements( project : Project, commit : Commit ) : Element [0..*]{query} «enumeration» Direction in out both Figure 9. ElementNavigationService Operations Element is the root metaclass in the KerML abstract syntax [KerML]. Relationship is a subtype of Element. Both Element and Relationship realize the Data interface defined in the API Model (refer to 7.1.2 - Project Data Versioning). Table 2. Operations Name Documentation Get relationships that are incoming, outgoing, or both getRelationshipsByRelatedElement relative to the given related element. Get all the elements in a given project at the given getElements commit. Get element with the given id (elementId) in the given getElementById project at the given commit. Get all the root elements in the given project at the getRootElements given commit. Systems Modeling API and Services v1.0 27 -7.2.3 ProjectDataVersioningService ProjectDataVersioningService operations getCommits( project : Project ) : Commit [0..*]{query} getHeadCommit( project : Project, branch : Branch [0..1] ) : Commit{query} getCommitById( project : Project, commitId : UUID ) : Commit [0..1]{query} createCommit( change : DataVersion [1..*], branch : Branch [0..1], previousCommits : Commit [0..*], project : Project ) : Commit getCommitChange( project : Project, commit : Commit, changeTypes : ChangeType [0..*] ) : DataVersion [1..*]{query} getCommitChangeById( project : Project, commit : Commit, changeId : UUID ) : DataVersion{query} getBranches( project : Project ) : Branch [1..*]{query} getBranchById( project : Project, branchId : UUID ) : Branch [0..1]{query} getDefaultBranch( project : Project ) : Branch [1]{query} setDefaultBranch( project : Project, branchId : UUID ) : Project [1] createBranch( project : Project, branchName : String, head : Commit ) : Branch [1] deleteBranch( project : Project, branchId : UUID ) : Branch [0..1] getTags( project : Project ) : Tag [1..*]{query} getTagById( project : Project, tagId : UUID ) : Tag{query} getTaggedCommit( project : Project, tag : Tag ) : Commit{query} createTag( project : Project, tagName : String, taggedCommit : Commit ) : Tag [1] deleteTag( project : Project, tagId : UUID ) : Tag [0..1] mergeIntoBranch( baseBranch : Branch, commitsToMerge : Commit [1..*], resolution : Data [0..*], description : String [0..1] ) : MergeResult diffCommits( baseCommit : Commit, compareCommit : Commit, changeTypes : ChangeType [0..*] ) : DataDifference [0..*]{query} DataDifference MergeResult «enumeration» ChangeType attributes attributes baseData : DataVersion [0..1] mergeCommit : Commit [0..1] CREATED compareData : DataVersion [0..1] conflict : DataIdentity [0..*] UPDATED DELETED Figure 10. ProjectDataVersioningService Operations Table 4. Operations Name Documentation Delete the branch with the given id (branchId) in the deleteBranch given project. Create a new tag with the given name (tagName) in the given project, and set the taggedCommit of the new tag createTag as the given commit (taggedCommit). Get the tag with the given id (tagId) in the given project. getTagById Get the tagged commit of the given tag in the given getTaggedCommit project. 28 Systems Modeling API and Services v1.0 -Name Documentation Get the difference between two commits - compareCommit and baseCommit. The set of all DataVersion records in a project at a given commit is accessible as Commit.versionedData. From a set theoretic perspective, this operation gets compareCommit.versionedData - baseCommit.versionedData and returns a DataDifference object with baseData and compareData for each difference. If any data is present in the compareCommit but absent in the baseCommit, DataDifference.compareData will include the corresponding DataVersion and DataDifference.baseData will be empty. If any data is absent in the compareCommit but present in the baseCommit, DataDifference.compareData will be empty and DataDifference.baseData will include the corresponding DataVersion. If any data is present in both but different in the compareCommit and baseCommit, DataDifference.compareData and DataDifference.baseData will include the corresponding DataVersion records. diffCommits The operation diffCommits in ProjectDataVersioningService has an optional argument changeTypes that is a collection typed by the enumeration ChangeType with three literals (CREATED, UPDATED, DELETED). If the argument changeTypes is passed, then only the changes of the given type will be returned by the operation as DataDifference objects. Some examples to elaborate this behavior are included below. If changeTypes = [], i.e. the argument is not specified, then the DataDifference objects for all the data that was created, updated, or deleted in the compareCommit versus the baseCommit will be returned. If changeTypes = ['DELETED'], then the DataDifference objects for all the data that was deleted in the compareCommit versus the baseCommit will be returned. If changeTypes = ['CREATED', 'UPDATED'], then the DataDifference objects for all the data that was created or updated in the compareCommit versus the baseCommit will be returned. Get all the commits in the given project. getCommits Get the head commit of the given branch in the given project. If the branch is not specified, the default branch getHeadCommit of the project is used. Set the branch with the given branchId as the default setDefaultBranch branch of the given project. Systems Modeling API and Services v1.0 29 -Name Documentation Get the change with the given id (changeId) in the given commit of the given project. The changeId is the id of getCommitChangeById the DataVersion that changed in the commit. Get all the branches in the given project. getBranches Create a new branch with the given name (branchName) in the given project, and set the head of the new branch createBranch as the given commit (head). Create a new commit with the given change (collection of DataVersion records) in the given branch of the project. If the branch is not specified, the default branch of the project is used. Commit.change should include the following for each Data object that needs to be created, updated, or deleted in the new commit. (1) Creating Data - Commit.change should include a DataVersion record with DataVersion.payload populated with the Data being created. DataVersion.identity is either left empty, in which case a new DataIdentity needs to be created by the Service and assigned to DataVersion.identity in the new commit; or provided a brand new value (one that does not already exist in any of the previousCommits) by the client and accepted by the Service as is. (2) Updating Data - Commit.change should include a DataVersion record with DataVersion.payload populated with the updated Data. DataVersion.identity should be populated createCommit with the DataIdentity for which a new DataVersion record will be created in the new commit. (3) Deleting Data - Commit.change should include a DataVersion record with DataVersion.payload not provided, thereby indicating deletion of DataIdentity in the new commit. DataVersion.identity should be populated with the DataIdentity that will be deleted in the new commit. When a DataIdentity is deleted in a commit, all its versions (DataVersion) are also deleted, and any references from other DataIdentity are also removed to maintain data integrity. In addition, for Element Data (KerML), deletion of an Element must also result in deletion of incoming Relationships. When Element Data (KerML) is created or updated, derived properties must be computed or verified if the API provider claims Derived Property Conformance. The deleted element - DataIdentity and its DataVersion records - will be accessible in previous commits. 30 Systems Modeling API and Services v1.0 -Name Documentation Get the change in the given commit of the given project. The operation getCommitChange in ProjectDataVersioningService has an optional argument changeTypes that is a collection typed by the enumeration ChangeType with three literals (CREATED, UPDATED, DELETED). If the argument changeTypes is passed, then only the changes of the given type will be returned by the operation as DataVersion records. Some examples to elaborate this behavior are included below. getCommitChange If changeTypes = [], i.e. the argument is not specified, then the DataVersion records for all the data that was created, updated, or deleted in the given commit will be returned. If changeTypes = ['DELETED'], then the DataVersion records for all the data that was deleted in the given commit will be returned. If changeTypes = ['CREATED', 'UPDATED'], then the DataVersion records for all the data that was created or updated in the given commit will be returned. Get the branch with the given id (branchId) in the given getBranchById project. Delete the tag with the given id (tadId) in the given deleteTag project. Merge the given commits (commitsToMerge) in the given branch (baseBranch). The commits included in commitsToMerge may be commits referenced by a CommitReference, such as Branch.head or Tag.taggedCommit, or any other commit in the owning project (Project.commits). This operation returns a MergeResult which will include either of the following: mergeIntoBranch (1) commit after the merge operation if successful, or (2) a set of DataIdentity records representing the merge conflicts if the merge operation is unsuccessful. Two optional inputs may be provided: (1) resolution as a set of Data that will resolve the merge conflicts, and (2) description of the merged commit if this operation is successful. Get the default branch of the given project. getDefaultBranch Get the commit with the given id (commitId) in the getCommitById given project. Get all the tags in the given project. getTags Systems Modeling API and Services v1.0 31 -7.2.4 QueryService QueryService operations getQueries( project : Project ) : Query [0..*] getQueryById( project : Project ) : Query [0..1] createQuery( name : String, project : Project, select : String [0..*], scope : Data [0..*], where : Constraint, orderBy : String [0..*] ) : Query updateQuery( project : Project, updateQuery : Query ) : Query deleteQuery( project : Project, queryId : UUID ) : Query executeQueryById( queryId : UUID, commit : Commit [0..1] ) : Data [0..*] executeQuery( query : Query, commit : Commit [0..1] ) : Data [0..*]{query} Figure 11. QueryService Operations Table 6. Operations Name Documentation Get all the queries in the given project. getQueries Get the query with the given id (queryId) in the given getQueryById project. Update the given query (updateQuery) in the given updateQuery project. Create a query in the given project with the given createQuery inputs. Execute the given query in the owning project (Query.project) at the given commit. If the commit is executeQuery not specified, then the head commit of the default branch of the project will be used. Delete the query with the given id (queryId) in the given deleteQuery project. Execute the query with the given id in the owning project (Query.project) at the given commit. If the executeQueryById commit is not specified, then the head commit of the default branch of the project will be used. 7.2.5 ExternalRelationshipService ExternalRelationshipService operations getExternalRelationships( project : Project, commit : Commit ) : ExternalRelationship [0..*]{query} getExternalRelationshipsByElement( project : Project, commit : Commit, elementId : UUID ) : ExternalRelationship [0..*]{query} getExternalRelationshipById( project : Project, commit : Commit, externalRelationshipId : UUID ) : ExternalRelationship [0..1]{query} createExternalRelationship( project : Project, branch : Branch [0..1], externalRelationship : ExternalRelationship ) deleteExternalRelationship( project : Project, branch : Branch [0..1], externalRelationshipId : UUID ) Figure 12. ExternalRelationshipService Operations 32 Systems Modeling API and Services v1.0 -Table 7. Operations Name Documentation Get the external relationship with the given id getExternalRelationshipById (externalRelationshipId). Get all the external relationships in a given project at a getExternalRelationships given commit. Delete the external relationship with the given id deleteExternalRelationship (externalRelationshipId). Create an external relationship in a given project on a createExternalRelationship given branch. Get all the external relationships in the given project at the given commit, where the id of elementEnd of the getExternalRelationshipsByElement external relationship is the given elementId. 7.2.6 ProjectUsageService ProjectUsageService operations getProjectUsages( project : Project, commit : Commit ) : ProjectUsage [0..*]{query} createProjectUsage( project : Project, branch : Branch [0..1], projectUsage : ProjectUsage ) : Commit deleteProjectUsage( project : Project, branch : Branch [0..1], projectUsageId : UUID ) : Commit Figure 13. ProjectUsageService Operations Table 8. Operations Name Documentation Get all the project usages in the given project at the getProjectUsages given commit. Deletes the project usage with the given id (projectUsageId) from the given project at the head commit of the given branch. This operation returns a new commit where the given project usage does not deleteProjectUsage exist, and sets the head of the given branch to the new commit. If a project branch is not given, then the default branch of the project will be used. Create a new project usage in the given project at the head commit of the given branch. This operation returns a new commit that includes the new project usage, and createProjectUsage sets the head of the given branch to the new commit. If a project branch is not given, then the default branch of the project will be used. Systems Modeling API and Services v1.0 33 -34 Systems Modeling API and Services v1.0 -8Platform Specific Models (PSMs) 8.1 REST/HTTP PSM 8.1.1 Overview The REST/HTTP Platform-Specific Model (PSM) for the Systems Modeling API and Services is described using OpenAPI Specification (OAS) 3.1 and is included with this specification. The REST/HTTP PSM is described in the following sections. • PIM API Model - REST/HTTP PSM Model Mapping: This section presents the mapping from the PIM API Model concepts to the JSON Models in the REST/HTTP PSM (OpenAPI specification). • PIM API Services - REST/HTTP PSM Endpoints Mapping: This section presents the mapping from the PIM API Service definitions and operations to the API endpoints in the REST/HTTP PSM (OpenAPI specification). 8.1.2 PIM API Model - REST/HTTP PSM Model Mapping The table below presents the mapping from the PIM API Model concepts to the JSON Models in the REST/HTTP PSM (OpenAPI specification). Table 9. PIM API Model - REST/HTTP PSM Model Mapping Table PIM Concept REST/HTTP PSM Model (JSON) Project Project Commit Commit Tag Tag Branch Branch Data Data DataIdentity DataIdentity DataVersion DataVersion Element Element Relationship Relationship ExternalData ExternalData ExternalRelationship ExternalRelationship ProjectUsage ProjectUsage Query Query PrimitiveConstraint PrimitiveConstraint CompositeConstraint CompositeConstraint DataDifference DataDifference MergeResult.mergeCommit Commit MergeResult.conflict DataIdentity [0..*] Systems Modeling API and Services v1.0 35 -8.1.3 PIM API Services - REST/HTTP PSM Endpoints Mapping The table below presents the mapping between the PIM Services to the REST/HTTP PSM Endpoints. This is followed by a detailed description of the pagination strategy used by the REST/HTTP PSM. Table 10. PIM to REST / HTTP PSM Mapping PIM Service REST / HTTP PSM Endpoint ProjectService createProject POST /projects getProjects GET /projects getProjectById GET /projects/{projectId} updateProject PUT /projects/{projectId} deleteProject DELETE /projects/{projectId} ElementNavigationService getElements GET/projects/{projectId}/commits/{commitId}/elements getElementById GET /projects/{projectId}/commits/{commitId}/elements/{elementId} GET /projects/{projectId}/commits/{commitId}/elements/{relatedElementId}/ relationships getRelationshipsByRelatedElement • direction query parameter with allowable values {in, out, both} getRootElements GET /projects/{projectId}/commits/{commitId}/roots ProjectDataVersioningService getCommits GET /projects/{projectId}/commits • GET /projects/{projectId}/branches/{branchId} returns the branch with the given branch ID. If the branch ID is not provided, then the ID of the default branch of the project is used. Use the following steps to get the ID of the default branch. ◦ GET /projects/{projectId} return the project with the getHeadCommit given project ID ◦ Project.defaultBranch provides the ID of the default branch of the project • Branch.head provides the ID of the head commit of the branch • GET /projects/{projectId}/commits/{commitId} returns the head commit with the the given commit ID getCommitById GET /projects/{projectId}/commits/{commitId} 36 Systems Modeling API and Services v1.0 -PIM Service REST / HTTP PSM Endpoint POST /projects/{projectId}/commit • The body of the POST request is a CommitRequest. • The content of CommitRequest.change for creating, updating, and deleting Data maps directly to the corresponding PIM operation (createCommit), and is described below. ◦ For creating new Data, CommitRequest.change should include a DataVersion where DataVersion.payload includes the Data being created and DataVersion.identity is either not specified or set to a new DataIdentity that does not already exist in any of createCommit the previousCommits. ◦ For updating existing Data, CommitRequest.change should include a DataVersion where DataVersion.payload includes the updated Data, and DataVersion.identity is the DataIdentity for which a new DataVersion will be created in the commit. ◦ For deleting existing Data, CommitRequest.change should include a DataVersion where DataVerision.payload is not specified, and DataVersion.identity is the DataIdentity that will be deleted in the commit. getCommitChange GET /projects/{projectId}/commits/{commitId}/changes getCommitChangeById GET /projects/{projectId}/commits/{commitId}/changes/{changeId} getBranches GET /projects/{projectId}/branches getBranchById GET /projects/{projectId}/branches/{branchId} • GET /projects/{projectId} returns a Project with the given ID (projectId) getDefaultBranch • Project.defaultBranch provides the ID of the default branch of the project • PUT /projects/{projectId} • The body of the PUT request is a ProjectRequest. Set the ID of setDefaultBranch the new default branch as ProjectRequest.defaultBranch in the body. createBranch POST /projects/{projectId}/branches deleteBranch DELETE /projects/{projectId}/branches/{branchId} getTags GET /projects/{projectId}/tags getTagById GET /projects/{projectId}/tags/{tagId} Systems Modeling API and Services v1.0 37 -PIM Service REST / HTTP PSM Endpoint • GET /projects/{projectId}/tags/{tagId} returns the tag with the given ID (tagId) getTaggedCommit • Tag.taggedCommit provides the ID of the tagged commit • GET /projects/{projectId}/commits/{commitId} returns the tagged commit given its ID (see the previous step) createTag POST /projects/{projectId}/tags deleteTag DELETE /projects/{projectId}/tags/{tagId} mergeIntoBranch POST /projects/{projectId}/branches/{targetBranchId}/merge diffCommits GET /projects/{projectId}/commits/{compareCommitId}/diff QueryService getQueries GET /projects/{projectId}/queries getQueryById GET /projects/{projectId}/queries/{queryId} createQuery POST /projects/{projectId}/queries updateQuery PUT /projects/{projectId}/queries/{queryId} deleteQuery DELETE /projects/{projectId}/queries/{queryId} executeQueryById GET /projects/{projectId}/queries/{queryId}/results GET /projects/{projectId}/query-results POST /projects/{projectId}/query-results executeQuery Either the GET or the POST endpoint may be used. The POST endpoint is provided for compatibility with clients that don't support GET requests with a body ExternalRelationshipService 38 Systems Modeling API and Services v1.0 -PIM Service REST / HTTP PSM Endpoint • POST /projects/{projectId}/queries with QueryRequest JSON model ◦ Query.where is set to a PrimitiveConstraint ◦ PrimitiveConstraint.property = @type ◦ PrimitiveConstraint.value = 'ExternalRelationship' getExternalRelationships ◦ PrimitiveConstraint.operator = '=' • Execute the query with the following request ◦ GET /projects/{projectId}/queries/{queryId}/results? commitId={commitId}, where {projectId} and {commitId} are the ids of the given Project and Commit • POST /projects/{projectId}/queries with QueryRequest JSON model ◦ Query.where is set to a CompositeConstraint ◦ CompositeConstraint.constraints includes the following 2 instances of PrimitiveConstraint with the and operator ▪ PrimitiveConstraint 1 ▪ PrimitiveConstraint.property = @type ▪ PrimitiveConstraint.value = 'ExternalRelationship' ▪ PrimitiveConstraint.operator = '=' getExternalRelationshipsByElement ▪ PrimitiveConstraint 2 ▪ PrimitiveConstraint.property = elementEnd ▪ PrimitiveConstraint.value = {elementId} ▪ PrimitiveConstraint.operator = '=' • Execute the query with the following request ◦ GET /projects/{projectId}/queries/{queryId}/results? commitId={commitId}, where {projectId} and {commitId} are the ids of the given Project and Commit Systems Modeling API and Services v1.0 39 -PIM Service REST / HTTP PSM Endpoint • POST /projects/{projectId}/queries with Query JSON model ◦ Query.where is set to a CompositeConstraint ◦ CompositeConstraint.constraints includes the following 2 instances of PrimitiveConstraint with the and operator ▪ PrimitiveConstraint 1 ▪ PrimitiveConstraint.property = @type ▪ PrimitiveConstraint.value = 'ExternalRelationship' ▪ PrimitiveConstraint.operator = '=' getExternalRelationshipsById ▪ PrimitiveConstraint 2 ▪ PrimitiveConstraint.property = @id ▪ PrimitiveConstraint.value = {externalRelationshipId} ▪ PrimitiveConstraint.operator = '=' • Execute the query with the following request ◦ GET /projects/{projectId}/queries/{queryId}/results? commitId={commitId}, where {projectId} and {commitId} are the ids of the given Project and Commit • POST /projects/{projectId}/commits?branchId={branchId} with CommitRequest JSON model, such that: createExternalRelationship ◦ CommitRequest.change = DataVersion object with specifics below ◦ DataVersion.payload = ExternalRelationship object • POST /projects/{projectId}/commits?branchId={branchId} with CommitRequest JSON model, such that: ◦ CommitRequest.change = DataVersion object with specifics below deleteExternalRelationship ◦ DataVersion.payload = null ◦ DataVersion.identity = DataIdentity object with the specifics below ▪ DataIdentity.id = {externalRelationshipId} Project Usage Service 40 Systems Modeling API and Services v1.0 -PIM Service REST / HTTP PSM Endpoint • POST /projects/{projectId}/queries with QueryRequest JSON model ◦ Query.where is set to a PrimitiveConstraint ◦ PrimitiveConstraint.property = @type ◦ PrimitiveConstraint.value = 'ProjectUsage' getProjectUsages ◦ PrimitiveConstraint.operator = '=' • Execute the query with the following request ◦ GET /projects/{projectId}/queries/{queryId}/results? commitId={commitId}, where {projectId} and {commitId} are the ids of the given Project and Commit • POST /projects/{projectId}/commits?branchId={branchId} with CommitRequest JSON model, such that: ◦ CommitRequest.change = DataVersion with the following inputs createProjectUsage ▪ DataVersion.payload = ProjectUsage with the following inputs ▪ ProjectUsage.usedProjectCommit = {commitId} of the Project and Commit being used. • POST /projects/{projectId}/commits?branchId={branchId} with CommitRequest JSON model, such that: ◦ CommitRequest.change = DataVersion with the following inputs deleteProjectUsage ▪ DataVersion.identity = DataIdentity with the following inputs ▪ DataIdentity.id = {projectUsageId} ▪ DataVersion.payload = null Pagination The REST/HTTP PSM uses a Cursor-based pagination strategy for the responses received from the GET requests. The following 3 query parameters can be specified in any GET request that returns a collection of records. 1. page[size] specifies the maximum number of records that will be returned per page in the response 2. page[before] specifies the URL of the page succeeding the page being requested 3. and page[after] specifies the URL of a page preceding the page being requested If neither page[before] nor page[after] is specified, the first page is returned with the same number of records as specified in the page[size] query parameter. If the page[size] parameter is not specified, then a default page size is used, which can be set by the API provider. The Link header in the response includes links (URLs) to the previous page and the next page, if any, for the given page in the response. The specification of these links is conformant to the IETF Web Linking standard. As an example, the value of the Link response header is shown below. The rel value associated with each page link specifies the type of relationship the linked page has with the page returned in the response. Page link specified with Systems Modeling API and Services v1.0 41 -rel value as next is the link for the next (or succeeding) page to the page returned in the response, and the page link specified with rel value as prev is the link for the previous (or preceding) page to the page returned in the response. ; rel="next", ; rel="prev" Example An example demonstrating the Cursor-based paginated responses received from GET requests to the /projects endpoint is presented here. The term "User" in the example scenario presented below refers to an API user that could be a human user or a software program. Step 1 - User makes a GET request to the /projects endpoint with page[size] query parameter set to 3. If successful, this request will return the first page with a maximum of 3 project records. The URL for this GET request is shown below. http://sysml2-api-host:9000/projects?page[size]=3 Step 2 - If there are more than 3 projects in the provider repository, the Link header in the response will provide the URL for the next page with rel value equal to next. The User gathers the link to the next page. ; rel="next" Step 3 - User makes a GET request to the URL for the next page gathered from Step 2. The Link header in the response will provide the URL for the next page with rel value equal to next. Additionally, the Link header will include the URL for the previous page with rel value equal to prev. ; rel="next", ; rel="prev" Step 4 - User continues Step 3 until the Link header in the response does not include the URL for the next page (rel value as next). 8.2 OSLC 3.0 PSM 8.2.1 Overview The OSLC Platform-Specific Model (PSM) for the Systems Modeling API and Services is described using OpenAPI Specification (OAS) 2.0 and is included with this specification. Note that the URLs listed in the OpenAPI Specification are provided as examples only. With OSLC, all URLs are implementation-specific. A OSLC client typically relies on the OSLC discovery mechanism (https://docs.oasis- open-projects.org/oslc-op/core/v3.0/ps01/discovery.html), to determine what services are provided by an OSLC server, as well as the necessary information (such as a service URL) to be able to consume any such service. At the least, an OSLC client requires a discovery URL to bootstrap this discovery for any particular server. The various approaches for bootstrapping and discovery are further detailed in the OSLC standard. • 8.2.2 presents a brief introduction to OSLC and its nomenclature. 42 Systems Modeling API and Services v1.0 -• 8.2.3 presents the mapping of PIM concepts to OSLC resource types • 8.2.4 presents the mapping of PIM services and operations to OSLC services An OSLC implementation may typically need to realize a broader set of services than those defined by the PIM for full integration with other OSLC-compliant systems. Services such as Delegated UI for Selection and Creation, resource UI Preview, authentication, and support for arbitrary queries (beyond those defined in the PIM). 8.2.2 OSLC Nomenclature What is OSLC? Open Services for Lifecycle Collaboration (OSLC) is an open community creating specifications for integrating tools. OSLC specifications allow conforming independent software and product lifecycle tools to integrate their data and workflows in support of end-to-end lifecycle processes. OSLC is based on the W3C Linked Data and the use of RDF to represent artifacts using common vocabularies, and HTTP to discover, create, read, update, and delete such artifacts. For a more comprehensive introduction, see the OSLC Primer and the OSLC specifications at https://open- services.net/specifications/. OSLC servers may support any or all of the following: 1. Creation factories for creating a resource of some RDF type associated with the factory. For example, a client might create a new change request by an HTTP POST including the RDF representation of the change request to be created to the URI of a change request creation factory. 2. REST services to read, update, and/or delete resources at the resource's URI. 3. Query capabilities that allow OSLC clients to query for resources of an RDF type associated with the query capability. For example, a client might query for change requests by an HTTP GET or POST to the query base URI of a query capability for change requests. See OSLC Query Version 3.0 for further details. 4. Creation dialog that allows some other application to embed it in an iFrame of an application dialog that allows a user to fill in information and create a resource of some type associated with the creation dialog. 5. Selection dialog that allows an application to display it to select a resource of some type associated with the dialog in order to create and persist a link to that resource in the application. 6. Resource preview, such as a pop-up display, that is shown as a rich hover when a user hovers over a link to a resource managed by the OSLC server. OSLC Discovery OSLC clients and other servers discover the OSLC capabilities offered by a server through OSLC discovery. This allows clients to discover the URIs of creation factories, query capabilities, creation dialogs, and selection dialogs without the need for hard coding or constructing URIs for them. Discovery starts with a known URI for an OSLC Service Provider Catalog. That service provider catalog may reference zero, one, or many service providers. Servers that support the concept of project as a container of resources, often for access control, often define a service provider for each such container. A service provider may declare one or many services, each of which may define the creation factories, query capabilities, creation dialogs, and selection dialogs supported by that service. For more details, see OSLC Core Version 3.0. Part 2: Discovery. A creation factory for a specific RDF type is discovered by: 1. Start with a known OSLC service provider catalog URI, perform HTTP GET. 2. Get the URIs of service providers from the response. 3. For each service provider, perform HTTP GET. 4. From the response, look for services described in the response data, that declare a creation factory for the RDF type. 5. Get the URI of the creation factory. A query capability for a specific RDF type is discovered by: Systems Modeling API and Services v1.0 43 -1. Start with a known OSLC service provider catalog URI, perform HTTP GET. 2. Get the URIs of service providers from the response. 3. For each service provider, perform HTTP GET. 4. From the response, look for services described in the response data, that declare a query capability for the RDF type. 5. Get the query base URI of the query capability. OSLC Resource Shapes Resource shapes specify a standard way (using RDF) of describing resources of specific RDF types and their properties. For more details, see OSLC Core Version 3.0. Part 6: Resource Shape. Resource shapes may be discovered in a number of ways: 1. The definition of a creation factory may reference a resource shape that describes the properties that might be included in the RDF content POSTed to that creation factory. 2. The definition of a query capability may reference a resource shape that describes the properties of the query results and references a shape that describes the properties that might be queried as a condition, or selected to be included in the results. 3. A resource may reference an instance shape that describes the properties of that resource. Linked Data Platform Containers Linked Data Platform Containers (LDPC) are a way of representing containers as an RDF resource. OSLC specifications specify LPDCs as a container representation. See W3C Linked Data Platform 1.0 for further information. OSLC Service Providers A "global" service provider will contain one or more services that cross all systems modeling projects. A service provider will be declared for each systems modeling project that provides capabilities specific to that project. RDF Media Types OSLC recommends that servers support RDF/XML (application/rdf+xml), Turtle (text/turtle, application/x-turtle), and JSON-LD ( application/ld+json). 8.2.3 PIM API Model – OSLC PSM Resource Mapping The mapping from the PIM API Model to the OSLC PSM resource types includes the following. 1. Mapping from the KerML and SysML abstract syntax (Element and subtypes) to OSLC resource shapes and vocabulary. The package containing the resulting OSLC resource shapes and vocabulary is included with this specification - see OSLC_Systems_Modeling_Resource_Shapes_and_Vocabulary.zip. 2. Mapping from the API Model concepts to resource types in other OSLC specifications, such as OSLC Configuration Management specification and OSLC Query specification. This mapping is shown in the table below. References to the OSLC specifications mentioned in the table below are as follows. 1. OSLC Configuration Management refers to OSLC Configuration Management Version 1.0 available at https://oslc-op.github.io/oslc-specs/specs/config/oslc-config-mgt.html. 2. OSLC Query refers to OSLC Query Version 3.0 available at https://docs.oasis-open- projects.org/oslc-op/query/v3.0/os/oslc-query.html 44 Systems Modeling API and Services v1.0 -Table 11. PIM Concept to OSLC Resource type Mapping dcterms:identifier PIM Concept OSLC Resource Type (OSLC Specification) Component (oslc_config:Component) Project PIM project id (OSLC Configuration Management) Stream (oslc_config:Stream) Branch PIM branch id (OSLC Configuration Management) Baseline (oslc_config:Baseline) Tag PIM tag id (OSLC Configuration Management) Commit Not supported by OSLC Configuration Management. PIM commit id Concept resource DataIdentity PIM Data Identity id (OSLC Configuration Management) Version resource (oslc_config:VersionResource) DataVersion PIM Data Version id (OSLC Configuration Management) OSLC Query Query (OSLC Query) oslc.where in OSLC Query PrimitiveConstraint (OSLC Query) oslc.where in OSLC Query CompositeConstraint (OSLC Query) Not Available. ProjectUsage PIM Project concept is mapped to OSLC Component but OSLC does not define Component Usage. DataDifference Not Available MergeResult Not Available ExternalData Not Available ExternalRelationship Not Available 8.2.4 PIM API Services – OSLC PSM Service Mapping The table below presents the mapping between the PIM Services to the OSLC 3.0 PSM. Table 12. PIM API Services - OSLC Services Mapping PIM Services OSLC PSM ProjectService Systems Modeling API and Services v1.0 45 -PIM Services OSLC PSM In OSLC, a Project is identified by its URL. So simply perform a GET on the Project URL. To search for a project with a given dcterms:identifier (or any other property that is deemed to return a single query result): 1. Discover a query capability for components (oslc_config:Component). See OSLC Discovery section. 2. Perform a GET on the query base, specifying a query for the dcterms:identifier in a oslc.where query parameter, and specifying which getProjectById properties, if any, of the component should be returned in the query result using an oslc.select query parameter. Example: Query for components with identifier 123, returning all properties. GET queryBaseUri? oslc.where=dcterms%3Aidentifier%3D%22123%22& oslc.select=* 1. Discover a creation factory for components (oslc_config:Component). See OSLC Discovery section. 2. POST the RDF content describing the component (with a Content-Type header set to an RDF media type supported by the server) to the creation factory. The RDF content should be compliant with the resource shape specified for the creation factory, and that resource shape must be createProject compatible with the resource shape for Component as described in the OSLC specification (see https://docs.oasis-open-projects.org/oslc-op/ config/v1.0/ps01/config-resources.html#ComponentShape). Example: POST creationFactoryUri 1. Discover a query capability for components (oslc_config:Component). See OSLC Discovery section. 2. Perform a GET on the query base, specifying which properties, if any, of the component should be returned in the query result using an oslc.select query parameter. getProjects Example: Query for components returning their name (dcterms:title) and id (dcterms:identifier) GET queryBaseUri? oslc.select=dcterms%3Atitle%2Cdcterms%3Aidentifier Execute an HTTP PUT with the revised content of the component. The RDF content should be compliant with the instance resource shape of the Component, and this updateProject should be compatible with the resource shape for Component as described in the OSLC specification (see https://docs.oasis-open-projects.org/oslc-op/config/v1.0/ ps01/config-resources.html#ComponentShape) 46 Systems Modeling API and Services v1.0 -PIM Services OSLC PSM Not supported directly. Deletion operation is not supported for Components in the OSLC Configuration Management specification. See https://oslc-op.github.io/oslc- deleteProject specs/specs/config/config-resources.html#componentoperations. However, providers may implement deletion operation for Components. ElementNavigation Service 1. Discover a query capability for elements (an API-specific RDF type) for the specified project. See OSLC Discovery section. 2. Perform a GET on the query base, specifying which properties, if any, of the commit should be returned in the query result using an oslc.select query parameter. getElements Example: Query for elements returning name (dcterms:title) and identifier (dcterms:identifier). GET queryBaseUri? oslc.select=dcterms%3Atitle%2Cdcterms%3Aidentifier In OSLC, an Element is identified by its URL. So simply perform a GET on the Element URL. To search for an Element with a given dcterms:identifier (or any other property that is deemed to return a single query result): 1. Discover a query capability for elements (an API-specific RDF type) for the specified project. See OSLC Discovery section. 2. Perform a GET on the query base, specifying a query for the dcterms:identifier in a oslc.where query parameter, and specifying which getElementById properties, if any, of the commit should be returned in the query result using an oslc.select query parameter. Example: Query for elements with identifier 123, returning all properties. GET queryBaseUri? oslc.where=dcterms%3Aidentifier%3D%22123%22& oslc.select=* Systems Modeling API and Services v1.0 47 -PIM Services OSLC PSM 1. Discover the query capability for Elements for the particular project (and its specific commit). See OSLC Discovery section. 2. Perform a GET on the query base, setting the oslc.where query parameter to: 1. sysml:out = URI of the subject element to get all the outgoing Relationships from that element 2. sysml:in = URI of the subject element to get all the incoming Relationships to the element Example 1: Query for Relationships outgoing from an element : GET queryBaseUri? getRelationshipsByRelated oslc.where=sysml:out= and Element rdf:type= &oslc.prefix=sysml= Example 2: Query for Relationships incoming to an element : GET queryBaseUri? oslc.where=sysml:in= and rdf:type= &oslc.prefix=sysml= For Direction equal to both: perform and merge the separate queries on in and out values. Not Available. getRootElements OSLC Query does not currently support the ability to search for resources, where certain properties (owner in this case) are not set. ProjectDataVersioning Service 1. Discover a query capability for streams (oslc_config:Stream) for the specified project. See OSLC Discovery section. 2. Perform a GET on the query base, specifying a query for the dcterms:identifier in a oslc.where query parameter, and specifying which properties, if any, of the component should be returned in the query result using an oslc.select query parameter. getBranchById Example: Query for streams with identifier 123, returning all properties. GET queryBaseUri? oslc.where=dcterms%3Aidentifier%3D%22123%22& oslc.select=* 48 Systems Modeling API and Services v1.0 -PIM Services OSLC PSM 1. Discover a query capability for baselines (oslc_config:Baseline) for the specified project. See OSLC Discovery section. 2. Perform a GET on the query base, specifying a query for the dcterms:identifier in a oslc.where query parameter, and specifying which properties, if any, of the component should be returned in the query result using an oslc.select query parameter. getTagById Example: Query for baselines with identifier 123, returning all properties. GET queryBaseUri? oslc.where=dcterms%3Aidentifier%3D%22123%22& oslc.select=* Not available. The OSLC Configuration Management specification does not define getCommits any notion of a commit. Versions of specific resources may be fetched. 1. Discover a query capability for streams (oslc_config:Stream) for the specified project. See OSLC Discovery section. 2. Perform a GET on the query base, specifying which properties, if any, of the stream should be returned in the query result using an oslc.select query parameter. getBranches Example: Query for branches returning their name (dcterms:title) and id (dcterms:identifier) GET queryBaseUri? oslc.select=dcterms%3Atitle%2Cdcterms%3Aidentifier Systems Modeling API and Services v1.0 49 -PIM Services OSLC PSM Not available. The OSLC Configuration Management specification does not define any notion of a commit. New versions may be created in the context of a stream or change set. However, the OSLC Configuration Management specification does not define any means to commit a change set or deliver the changes in a stream or change set to another stream. For creating new versions of a resource in the context of a stream or a change set, see below. 1. Execute a PUT on version resource concept URI with configuration context parameter/header set to the URI of a stream (branch). Body contains the updated RDF representation of the element version. Note that this only supports a new commit along a branch with the previous latest commit being its previous commit. If a client wants to commit from an earlier createCommit version, they must first create a stream (branch) from that earlier baseline (commit) and then use a PUT with that new stream. The OSLC Configuration Management specification does not currently define any mechanisms for creating new versions of multiple versioned resources in a single REST operation. Example 1: PUT conceptResourceUri? oslc_config.context=urlEncodedStreamUri Example 2: Headers: Configuration-Context=streamUri PUT conceptResourceUri 1. Discover a query capability for commits (a API-specific RDF type) for the specified project. See OSLC Discovery section. 2. Perform a GET on the query base, specifying a query for the dcterms:identifier in a oslc.where query parameter, and specifying which properties, if any, of the commit should be returned in the query result using an oslc.select query parameter. getCommitById Example: Query for commits with identifier 123, returning all properties. GET queryBaseUri? oslc.where=dcterms%3Aidentifier%3D%22123%22& oslc.select=* Not available. The OSLC Configuration Management specification does not define any notion of a commit. New versions may be created in the context of a stream or getCommitChange change set. However, the OSLC Configuration Management specification does not define any means to commit a change set or deliver the changes in a stream or change set to another stream. Not available. The OSLC Configuration Management specification does not define any notion of a commit. New versions may be created in the context of a stream or getCommitChangeById change set. However, the OSLC Configuration Management specification does not define any means to commit a change set or deliver the changes in a stream or change set to another stream. 50 Systems Modeling API and Services v1.0 -PIM Services OSLC PSM Execute an HTTP DELETE on the URI of the stream. Note that servers may reject the delete request if the stream is used or referenced by other configurations. deleteBranch A server may also support archiving (soft delete) a stream using a HTTP PUT with content that includes a oslc:archived "true"^^xsd:boolean property. Not available. The OSLC Configuration Management specification does not define getDefaultBranch any notion of a default stream. Execute an HTTP DELETE on the URI of the baseline. Note that a server might reject a request to delete a baseline if it is used or referenced by other configurations. deleteTag A server may also support archiving (soft delete) a baseline using a HTTP PUT with content that includes a oslc:archived "true"^^xsd:boolean property. Not available. The OSLC Configuration Management specification does not define setDefaultBranch any notion of a default stream. Not available. The OSLC Configuration Management specification does not define any notion of a commit. New versions may be created in the context of a stream or getHeadCommit change set. However, OSLC Configuration Management does not define any means to commit a change set or deliver the changes in a stream or change set to another stream. Not available. The OSLC Configuration Management specification does not define any notion of a commit. New versions may be created in the context of a stream or getTaggedCommit change set. However, OSLC Configuration Management does not define any means to commit a change set or deliver the changes in a stream or change set to another stream. A baseline can provide a set of versioned resources but it is not a commit. 1. Discover a query capability for baselines (oslc_config:Baseline) for the specified project. See OSLC Discovery section. 2. Perform a GET on the query base, specifying which properties, if any, of the baseline should be returned in the query result using an oslc.select query parameter. getTags Example: Query for tags returning their name (dcterms:title) and id (dcterms:identifier) GET queryBaseUri? oslc.select=dcterms%3Atitle%2Cdcterms%3Aidentifier 1. Get the baselines LDPC URI from the RDF of a stream. 2. POST the RDF representation of the baseline to the LDPC URI (with a Content-Type header set to an RDF media type supported by the server). The RDF content should be compatible with the resource shape for Baseline as described in the specification (see https://docs.oasis-open- createTag projects.org/oslc-op/config/v1.0/ps01/config- resources.html#BaselineShape) Example: Create a baseline from a stream POST baselinesLdpcUri Systems Modeling API and Services v1.0 51 -PIM Services OSLC PSM A server might support either or both of the following: A) Use a creation factory: 1. Discover a creation factory for streams (oslc_config:Stream) for the specified project. See OSLC Discovery section. 2. POST the RDF content describing the stream (with a Content-Type header set to an RDF media type supported by the server) to the creation factory. The RDF content should be compliant with the resource shape specified for the creation factory, and that resource shape must be compatible with the resource shape for Stream as described in the specification (see https://docs.oasis-open-projects.org/oslc-op/config/v1.0/ ps01/config-resources.html#StreamShape) Example: createBranch POST creationFactoryUri or B) Use the streams LDPC of a component 1. Get the URI of the streams LDPC from the RDF of a component. 2. POST the RDF content describing the stream (with a Content-Type header set to an RDF media type supported by the server) to the LDPC. The RDF content should be compatible with the resource shape for Stream as described in the specification (see https://docs.oasis-open-projects.org/oslc- op/config/v1.0/ps01/config-resources.html#StreamShape) Example: POST streamsLdpcUri mergeIntoBranch Not Available diffCommits Not Available QueryService Not Available getQueryById OSLC does not provide any RDF representation or persistence mechanisms of OSLC queries. Not Available getQueries OSLC does not provide any RDF representation or persistence mechanisms of OSLC queries. Not Available executeQueryById OSLC does not provide any RDF representation or persistence mechanisms of OSLC queries. Not Available createQuery OSLC does not provide any RDF representation or persistence mechanisms of OSLC queries. 52 Systems Modeling API and Services v1.0 -PIM Services OSLC PSM Not Available updateQuery OSLC does not provide any RDF representation or persistence mechanisms of OSLC queries. Not Available deleteQuery OSLC does not provide any RDF representation or persistence mechanisms of OSLC queries. 1. Discover a query capability for the specified project. See OSLC Discovery section. 2. Perform a GET on the query base, specifying the following. See OSLC executeQuery Query Capability in OSLC Nomenclature 1. The oslc.where query parameter to filter for the desired elements 2. The oslc.select query parameter, to define the element properties that should be returned in the query result. OSLC does/can not differentiate between properties/relationships/elements that are ExternalRelationship external or otherwise. Service The services below are just specific examples of the getElements and getElementById service operation mappings above. getExternalRelationships See getElementById under ElementNavigationService ById getExternalRelationships See getRelationshipsByRelatedElement under ElementNavigationService ByElementEnd getExternalRelationships See getElements under Element Navigation Service createExternalRelationship Not available. deleteExternalRelationship Not available. ProjectUsageService Not available. The OSLC Configuration Management specification does not define createProjectUsage any notion of component usage. Not available. The OSLC Configuration Management specification does not define deleteProjectUsage any notion of component usage. Not available. The OSLC Configuration Management specification does not define getProjectUsages any notion of component usage. Systems Modeling API and Services v1.0 53 -54 Systems Modeling API and Services v1.0 -AAnnex: Conformance Test Suite (Normative) A.1 ProjectService Conformance Test Cases Operation create_project PIM-PS-001 Description Create Project - success 1. _description : String[0..1] Input 2. _name : String[1] Scenario Precondition let _record : Record = Record.allInstances() (OCL) Execute operation create_project(name = _name, description = _description) : Steps Project[1] 1. Result, defined as project : Project[1] , is a created Project 2. The id attribute value of the created Project is randomly generated and universally unique, including (but not limited to) not being used as the id attribute value for any previously existing Record 3. A Branch is created and specified as the defaultBranch attribute value for the created Project 4. The id attribute value of the created Branch ( defaultBranch ) is randomly generated Result and universally unique, including (but not limited to) not being used as the id attribute value for any previously existing Record. 5. The name attribute value of the created Branch ( defaultBranch ) is specified as 'main' 6. The description attribute value is specified as inputted 7. The name attribute value is specified as inputted let project : Project = create_project(_name, _description) project->size() = 1 Project.allInstances()->includes(project) _record.id->excludes(project.id) Postcondition project.defaultBranch->notEmpty() (OCL) _record.id->excludes(project.defaultBranch.id) project.defaultBranch.name = 'main' project.description = _description project.name = _name Systems Modeling API and Services v1.0 55 -Operation get_projects PIM-PS-002 Description Get Projects - success Input None Scenario Precondition (OCL) Execute operation get_projects() : Project[0..*] Steps Result, defined as project : Project[0..*] , is all of the existing Projects Result let project : Project = get_projects() Postcondition project = Project.allInstances() (OCL) Operation get_project_by_id PIM-PS-003 Description Get Project by ID - exists 1. _projectId : UUID[1] Input A Project with an id attribute value equal to _projectId exists Scenario let _project : Project = Project.allInstances()->select(id = _projectId) Precondition _project->size() = 1 (OCL) Execute operation get_project_by_id(projectId = _projectId) : Project[0..1] Steps Result, defined as project : Project[1] , is the Project with an id attribute value equal to Result _projectId let project : Project = get_project_by_id(_projectId) Postcondition project = _project (OCL) PIM-PS-004 Description Get Project by ID - does not exist 56 Systems Modeling API and Services v1.0 -1. _projectId : UUID[1] Input A Project with an id attribute value equal to _projectId does not exist Scenario Precondition Project.allInstances()->select(projectId = _projectId)->isEmpty() (OCL) Execute operation get_project_by_id(projectId = _projectId) : Project[0..1] Steps 1. Result, defined as project : Project[0] , does not include any Projects Result 2. Result communicates that a Project with the provided ID does not exist let project : Project = get_project_by_id(_projectId) Postcondition project->isEmpty() (OCL) A.2 ElementNavigationService Conformance Test Cases Operation get_elements PIM-EN-001 Description Get Elements - success 1. _project : Project[1] Input 2. _commit : Commit[1] 1. The inputted Project exists Scenario 2. The inputted Commit exists 3. The inputted Commit belongs to the inputted Project Project.allInstances()->includes(_project) Precondition Commit.allInstance()->includes(_commit) (OCL) _commit.owningProject = _project Execute operation get_elements(project = _project, commit = _commit) : Steps Element[0..*] Result, defined as element : Element[0..*] , is all Elements at the inputted Commit Result let element : Element = get_elements(_project, _commit) Postcondition element = _commit.version.data->select(oclIsKindOf(Element)) (OCL) Systems Modeling API and Services v1.0 57 -Operation get_element_by_id PIM-EN-002 Description Get Element by ID - success 1. _project : Project[1] 2. _commit : Commit[1] Input 3. _elementId : UUID[1] 1. The inputted Project exists 2. The inputted Commit exists 3. The inputted Commit belongs to the inputted Project Scenario 4. An Element with an id attribute value equal to _elementId exists at the inputted Commit Project.allInstances()->includes(_project) Commit.allInstance()->includes(_commit) _commit.owningProject = _project Precondition let _element : Element = _commit.version->select(identity.id = (OCL) _elementId and data.oclIsKindOf(Element)).data _element.size() = 1 Execute operation get_element_by_id(project = _project, commit = _commit, Steps elementId = _elementId) : Element[0..1] Result, defined as element : Element[1] , is the Element with an id attribute value equal to Result _elementId at the inputted Commit let element : Element = get_element_by_id(_project, _commit, _elementId) Postcondition element = _element (OCL) PIM-EN-003 Description Get Element by ID - does not exist at Commit 58 Systems Modeling API and Services v1.0 -1. _project : Project[1] 2. _commit : Commit[1] Input 3. _elementId : UUID[1] 1. The inputted Project exists 2. The inputted Commit exists 3. The inputted Commit belongs to the inputted Project Scenario 4. An Element with an id attribute value equal to _elementId does not exist at the inputted Commit Project.allInstances()->includes(_project) Commit.allInstance()->includes(_commit) Precondition _commit.owningProject = _project (OCL) _commit.version->select(identity.id = _elementId and data.oclIsKindOf(Element)).data->isEmpty() Execute operation get_element_by_id(project = _project, commit = _commit, Steps elementId = _elementId) : Element[0..1] 1. Result, defined as element : Element[0] , does not include any Elements Result 2. Result communicates that an Element with the provided ID at the inputted Commit does not exist let element : Element = get_element_by_id(_project, _commit, _id) Postcondition element->isEmpty() (OCL) Operation get_relationships_by_source PIM-EN-004 Description Get Relationships by source (Element) - success Systems Modeling API and Services v1.0 59 -1. _project : Project[1] 2. _commit : Commit[1] Input 3. _elementId : UUID[1] 1. The inputted Project exists 2. The inputted Commit exists 3. The inputted Commit belongs to the inputted Project Scenario 4. An Element with an id attribute value equal to _elementId exists at the inputted Commit Project.allInstances()->includes(_project) Commit.allInstance()->includes(_commit) _commit.owningProject = _project Precondition let _element : Element = _commit.version->select(identity.id = _id and (OCL) data.oclIsKindOf(Element)).data _element.size() = 1 Execute operation get_relationships_by_source(project = _project, commit = Steps _commit, elementId = _elementId) : Relationship[0..*] Result, defined as relationship : Relationship[0..*] , is all the Relationships whose Result source attribute value includes the Element with id attribute value equal to _elementId let relationship : Relationship = get_relationship_by_source(_project, _commit, _elementId) Postcondition relationship = _commit.version->select(data.oclIsKindOf(Relationship) (OCL) and data.source->includes(_element)) Operation get_relationships_by_target PIM-EN-005 Description Get Relationships by target (Element) - success 60 Systems Modeling API and Services v1.0 -1. _project : Project[1] 2. _commit : Commit[1] Input 3. _elementId : UUID[1] 1. The inputted Project exists 2. The inputted Commit exists 3. The inputted Commit belongs to the inputted Project Scenario 4. An Element with an id attribute value equal to _elementId exists at the inputted Commit Project.allInstances()->includes(_project) Commit.allInstance()->includes(_commit) _commit.owningProject = _project Precondition let _element : Element = _commit.version->select(identity.id = _id and (OCL) data.oclIsKindOf(Element)).data _element.size() = 1 Execute operation get_relationships_by_target(project = _project, commit = Steps _commit, elementId = _elementId) : Relationship[0..*] Result, defined as relationship : Relationship[0..*] , is all the Relationships whose Result target attribute value includes the Element with id attribute value equal to _elementId let relationship : Relationship = get_relationship_by_target(_project, _commit, _elementId) Postcondition relationship = _commit.version->select(data.oclIsKindOf(Relationship) (OCL) and data.target->includes(_element)) A.3 ProjectDataVersioningService Conformance Test Cases Operation create_branch PIM-PCB-001 Description Create Branch - success Systems Modeling API and Services v1.0 61 -1. _project : Project[1] 2. _head : Commit[1] Input 3. _name : String[1] 1. The inputted Project exists 2. The inputted Commit ( _head ) exists Scenario 3. The inputted Commit ( _head ) belongs to the inputted Project Project.allInstances()->includes(_project) Commit.allInstance()->includes(_head) Precondition _head.owningProject = _project (OCL) let _record : Record = Record.allInstances() Execute operation create_branch(project = _project, head = _head, name = Steps _name) : Branch[1] 1. Result, defined as branch : Branch[1] , is a created Branch in the inputted Project 2. The id attribute value of the created Branch is randomly generated and universally unique, including (but not limited to) not being used as the id attribute value for any previously existing Record. Result 3. The owningProject attribute value of the created Branch is specified as inputted, i.e. equal to _project 4. The head attribute value of the created Branch is specified as inputted 5. The name attribute value of the created Branch is specified as inputted let branch : Branch = create_branch(_project, _head, _name) branch->size() = 1 Branch.allInstances()->includes(branch) _project.branch->includes(branch) Postcondition _record.id->excludes(branch.id) (OCL) branch.owningProject = _project branch.head = _head branch.name = _name Operation get_branches PIM-PCB-002 Description Get Branches - success 1. _project : Project[1] Input Scenario The inputted Project exists 62 Systems Modeling API and Services v1.0 -Precondition Project.allInstances()->includes(_project) (OCL) Execute operation get_branches(project = _project) : Branch[0..*] Steps Result, defined as branch : Branch[0..*] , is all Branches in the inputted Project Result let branch : Branch = get_branches(_project) Postcondition branch = _project.branch (OCL) Operation get_branch_by_id PIM-PCB-003 Description Get Branch by ID - success 1. _project : Project[1] Input 2. _branchId : UUID[1] 1. The inputted Project exists Scenario 2. A Branch with an id attribute value equal to _branchId exists in the inputted Project Project.allInstances()->includes(_project) Precondition let _branch : Branch = _project.branch->select(id = _branchId) (OCL) _branch.size() = 1 Execute operation get_branch_by_id(project = _project, branchId = _branchId) Steps : Branch[0..1] Result, defined as branch : Branch[1] , is the Branch with an id attribute value equal to Result _branchId in the inputted Project let branch : Branch = get_branch_by_id(_project, _branchId) Postcondition branch = _branch (OCL) PIM-PCB-004 Description Get Branch by ID - does not exist in Project Systems Modeling API and Services v1.0 63 -1. _project : Project[1] Input 2. _branchId : UUID[1] 1. The inputted Project exists 2. A Branch with an id attribute value equal to _branchId does not exist in the inputted Scenario Project Project.allInstances()->includes(_project) Precondition _project.branch->select(id = _branchId)->isEmpty() (OCL) Execute operation get_branch_by_id(project = _project, branchId = _branchId) Steps : Branch[0..1] 1. Result, defined as branch : Branch[0] , does not include any Branches Result 2. Result communicates that a Branch with the provided ID in the inputted Project does not exist let branch : Branch = get_branch_by_id(_project, _branchId) Postcondition branch->isEmpty() (OCL) Operation delete_branch PIM-PCB-005 Description Delete Branch - success 1. _project : Project[1] Input 2. _branchId : UUID[1] 1. The inputted Project exists Scenario 2. A Branch with an id attribute value equal to _branchId exists in the inputted Project Project.allInstances()->includes(_project) Precondition let _branch : Branch = _project.branch->select(id = _branchId) (OCL) _branch.size() = 1 Execute operation delete_branch(project = _project, branchId = _branchId) : Steps Branch[0..1] 64 Systems Modeling API and Services v1.0 -1. Result, defined as branch : Branch[1] , is the Branch with an id attribute value equal to _branchId in the inputted Project Result 2. Branch with an id attribute value equal to _branchId does not exist let branch : Branch = delete_branch(_project, _branchId) _project.branch->excludes(branch) Postcondition Branch.allInstances()->excludes(branch) (OCL) _project.branch->select(id = _branchId)->isEmpty() Branch.allInstances()->select(id = _branchId)->isEmpty() PIM-PCB-006 Description Delete Branch - does not exist in Project 1. _project : Project[1] Input 2. _branchId : UUID[1] 1. The inputted Project exists 2. A Branch with an id attribute value equal to _branchId does not exist in the inputted Scenario Project Project.allInstances()->includes(_project) Precondition _project.branch->select(id = _branchId)->isEmpty() (OCL) Execute operation delete_branch(project = _project, branchId = _branchId) : Steps Branch[0..1] 1. Result, defined as branch : Branch[0] , does not include any Branches Result 2. Result communicates that a Branch with the provided ID in the inputted Project does not exist let branch : Branch = delete_branch(_project, _branchId) Postcondition branch->isEmpty() (OCL) Operation get_default_branch PIM-PCB-007 Description Get default Branch - success Systems Modeling API and Services v1.0 65 -1. _project : Project[1] Input Scenario The inputted Project exists Precondition Project.allInstances()->includes(_project) (OCL) Execute operation get_default_branch(project = _project) : Branch[1] Steps 1. Result, defined as branch : Branch[1] , is the defaultBranch attribute value of Result the inputted Project let branch = get_default_branch(_project) Postcondition branch = _project.defaultBranch (OCL) Operation set_default_branch PIM-PCB-008 Description Set default Branch - success 1. _project : Project[1] Input 2. _branchId : UUID[1] 1. The inputted Project exists Scenario 2. A Branch with an id attribute value equal to _branchId exists in the inputted Project Project.allInstances()->includes(_project) Precondition let _branch : Branch = _project.branch->select(id = _branchId) (OCL) _branch.size() = 1 Execute operation set_default_branch(project = _project, branchId = Steps _branchId) : Project[1] 1. Result, defined as project : Project[1] , is the inputted Project 2. The defaultBranch attribute value of the inputted Project is specified as the Branch Result with an id attribute value equal to _branchId let project : Project = set_default_branch(_project, _branchId) Postcondition project.defaultBranch = _branch (OCL) 66 Systems Modeling API and Services v1.0 -PIM-PCB-009 Description Set default Branch - does not exist in Project 1. _project : Project[1] Input 2. _branchId : UUID[1] 1. The inputted Project exists 2. A Branch with an id attribute value equal to _branchId does not exist in the inputted Scenario Project Project.allInstances()->includes(_project) Precondition _project.branch->select(id = _branchId)->isEmpty() (OCL) let _defaultBranch : Branch = _project.defaultBranch Execute operation set_default_branch(project = _project, branchId = Steps _branchId) : Project[1] 1. Result, defined as project : Project[1] , is the inputted Project 2. The defaultBranch attribute value of the inputted Project is unchanged Result 3. Result communicates that a Branch with the provided ID in the inputted Project does not exist let project : Project = set_default_branch(_project, _branchId) Postcondition project.defaultBranch = _defaultBranch (OCL) Operation create_commit PIM-PCB-010 Description Create Commit - success Systems Modeling API and Services v1.0 67 -1. _project : Project[1] 2. _change : DataVersion[1..*] Input 3. _branch : Branch[0..1] 4. _previousCommit : Commit[0..*] 1. The inputted Project exists 2. The inputted Branch, optional and if provided, exists in the inputted Project Scenario 3. The inputted Commits ( _previousCommit ), optional and if provided, exists in the inputted Commit Project.allInstances()->includes(_project) _branch->isEmpty() or _project.branch->includes(_branch) _previousCommit->isEmpty() or _previousCommit->forAll(owningProject = Precondition _project) (OCL) let _record : Record = Record.allInstances() let _head : Commit = _branch.head Execute operation create_commit(project = _project, change = _change, branch Steps = _branch, previousCommit = _previousCommit) : Commit[1] 1. Result, defined as commit : Commit[1] , is a created Commit 2. The id attribute value of the created Commit is randomly generated and universally unique, including (but not limited to) not being used as the id attribute value for any previously existing Record. 3. The owningProject attribute value of the created Commit is specified as inputted ( _project ) Result 4. The change attribute value of the created Commit is specified as inputted 5. The previousCommit attribute value of the created Commit is specified as the union of the head attribute value of the inputted Branch, if provided, and the inputted Commits ( _previousCommit ) 6. The version attribute value of the created Commit includes the new changes 7. The head attribute value of the inputted Branch, if provided, is updated to the created Commit let commit : Commit = create_commit(_project, _change, _branch, _previousCommit) commit->size() = 1 _record.id->excludes(commit.id) Postcondition commit.owningProject = _project (OCL) commit.change = _change commit.previousCommit = _head->union(_previousCommit) commit.version->includes(_change) _branch->isEmpty() or _branch.head = commit 68 Systems Modeling API and Services v1.0 -Operation get_commit_by_id PIM-PCB-011 Description Get commit by ID - success 1. _project : Project[1] Input 2. _commitId : UUID[1] 1. The inputted Project exists Scenario 2. A Commit with an id attribute value equal to _commitId exists in the inputted Project Project.allInstances()->includes(_project) Precondition let _commit : Commit = _project.commit->select(id = _commitId) (OCL) _commit.size() = 1 Execute operation get_commit_by_id(project = _project, commitId = _commitId) Steps : Commit[0..1] Result, defined as commit : Commit[1] , is the Commit with an id attribute value equal to Result _commitId in the inputted Project let commit : Commit = get_commit_by_id(_project, _commitId) Postcondition commit = _commit (OCL) PIM-PCB-012 Description Get commit by ID - does not exist in Project 1. _project : Project[1] Input 2. _commitId : UUID[1] 1. The inputted Project exists 2. A Commit with an id attribute value equal to _commitId does not exist in the Scenario inputted Project Project.allInstances()->includes(_project) Precondition _project.commit->select(id = _commitId)->isEmpty() (OCL) Execute operation get_commit_by_id(project = _project, commitId = _commitId) Steps : Commit[0..1] Result, defined as commit : Commit[0] , does not include any Commits Result Systems Modeling API and Services v1.0 69 -let commit : Commit = get_commit_by_id(_project, _commitId) Postcondition commit->isEmpty() (OCL) Operation get_head PIM-PCB-013 Description Get head Commit of Branch - success 1. _project : Project[1] Input 2. _branch : Branch[1] 1. The inputted Project exists Scenario 2. The inputted Branch exists 3. The inputted Branch belongs to the inputted Project Project.allInstances()->includes(_project) Precondition Branch.allInstance()->includes(_branch) (OCL) _branch.owningProject = _project Execute operation get_head(project = _project, branch = _branch) : Steps Commit[0..1] Result, defined as head : Commit[0..1] , is the Commit that is the head attribute value of the Result inputted Branch let head : Commit = get_head(_project, _branch) Postcondition Bag{0, 1}->includes(head->size()) (OCL) head = _project.head PIM-PCB-014 Description Get head Commit of Branch - Branch does not exist 70 Systems Modeling API and Services v1.0 -1. _project : Project[1] Input 2. _branch : Branch[1] 1. The inputted Project exists Scenario 2. The inputted Branch does not exist Project.allInstances()->includes(_project) Precondition Branch.allInstance()->excludes(_branch) (OCL) Execute operation get_head(project = _project, branch = _branch) : Steps Commit[0..1] 1. Result, defined as head : Commit[0] , does not include any Commits Result 2. Result communicates that the inputted Branch does not exist let head : Commit = get_head(_project, _branch) Postcondition head->isEmpty() (OCL) PIM-PCB-015 Description Get head Commit of Branch - Branch not in Project 1. _project : Project[1] Input 2. _branch : Branch[1] 1. The inputted Project exists Scenario 2. The inputted Branch exists 3. The inputted Branch does not belong to the inputted Project Project.allInstances()->includes(_project) Precondition Branch.allInstance()->includes(_branch) (OCL) _branch.owningProject <> _project Execute operation get_head(project = _project, branch = _branch) : Steps Commit[0..1] Systems Modeling API and Services v1.0 71 -1. Result, defined as head : Commit[0] , does not include any Commits Result 2. Result communicates that the provided input is invalid let head : Commit = get_head(_project, _branch) Postcondition head->isEmpty() (OCL) A.4 QueryService Conformance Test Cases Operation create_query PIM-QS-001 Description Create Query - success 1. _project : Project[1] 2. _select : String[0..*] 3. _scope : DataIdentity[0..*] Input 4. _where : Constraint[0..1] 5. _orderBy : String[0..*] Scenario 1. The inputted Project exists Project.allInstances()->includes(_project) Precondition let _record : Record = Record.allInstances() (OCL) Execute operation create_query(project = _project, select = _select, scope = Steps _scope, where = _where, orderBy = _orderBy) : Query[1] 72 Systems Modeling API and Services v1.0 -1. Result, defined as query : Query[1] , is a created Query in the inputted Project 2. The id attribute value of the created Query is randomly generated and universally unique, including (but not limited to) not being used as the id attribute value for any previously existing Record. 3. The owningProject attribute value of the created Query is specified as inputted, i.e. Result equal to _project 4. The select attribute value of the created Query is specified as inputted 5. The scope attribute value of the created Query is specified as inputted 6. The where attribute value of the created Query is specified as inputted 7. The orderBy attribute value of the created Query is specified as inputted let query : Query = create_query(_project, _select, _scope, _where, _orderBy) query->size() = 1 Query.allInstances()->includes(query) _project.query->includes(query) Postcondition _record.id->excludes(query.id) (OCL) query.owningProject = _project query.select = _select query.scope = _scope query.where = _where query.orderBy = orderBy PIM-QS-002 Description Execute Query - success 1. _query : Query[1] Input 2. _commit : Commit[1] 1. The inputted Query exists Scenario 2. The inputted Commit exists 3. The inputted Query and Commit both belong to the same Project Query.allInstances()->includes(_query) Precondition Commit.allInstances()->includes(_commit) (OCL) _query.owningProject = _commit.owningProject Execute operation execute_query(query = _query, commit = _commit) : Steps Data[0..*] Systems Modeling API and Services v1.0 73 -1. Result, defined as data : Data[0..*] , is all of the Datas at the inputted Commit that satisfy the conditions of the inputted Query Result 2. If inputted Query has a non-empty scope attribute value, result only includes Data within the Query's scope let data : Data = execute_query(_query, _commit) Postcondition _commit.versionedData->includesAll(data) (OCL) _query.scope->isEmpty() or _query.scope->includesAll(data) A.5 ExternalRelationshipService Conformance Test Cases Operation get_external_relationships PIM-ER-001 Description Get ExternalRelationships - success 1. _project : Project[1] Input 2. _commit : Commit[1] 1. The inputted Project exists Scenario 2. The inputted Commit exists 3. The inputted Commit belongs to the inputted Project Project.allInstances()->includes(_project) Precondition Commit.allInstance()->includes(_commit) (OCL) _commit.owningProject = _project Execute operation get_external_relationships(project = _project, commit = Steps _commit) : ExternalRelationship[0..*] 1. Result, defined as externalRelationship : ExternalRelationship[0..*] , is Result all of the existing ExternalRelationships at the inputted Commit let externalRelationship : ExternalRelationship = get_external_relationships(_project, _commit) Postcondition externalRelationship = (OCL) _commit.version.data->select(oclIsKindOf(ExternalRelationship)) 74 Systems Modeling API and Services v1.0 -Operation get_external_relationship_by_id PIM-ER-002 Description Get ExternalRelationships by ID - success 1. _project : Project[1] 2. _commit : Commit[1] Input 3. _externalRelationshipId : UUID[1] 1. The inputted Project exists 2. The inputted Commit exists 3. The inputted Commit belongs to the inputted Project Scenario 4. An ExternalRelationship with an id attribute value equal to _externalRelationshipId exists at the inputted Commit Project.allInstances()->includes(_project) Commit.allInstance()->includes(_commit) _commit.owningProject = _project Precondition let _externalRelationship : ExternalRelationship = (OCL) _commit.version->select(identity.id = _externalRelationshipId and data.oclIsTypeOf(ExternalRelationship)).data _externalRelationship.size() = 1 Execute operation get_external_relationship_by_id(project = _project, commit = _commit, Steps externalRelationshipId = _externalRelationshipId) : ExternalRelationship[0..1] 1. Result, defined as externalRelationship : ExternalRelationship[1] , is the Result Element with an id attribute value equal to _externalRelationshipId at the inputted Commit let externalRelationship : ExternalRelationship = get_external_relationship_by_id(_project, _commit, Postcondition _externalRelationshipId) (OCL) externalRelationship = _externalRelationship PIM-ER-003 Description Get ExternalRelationships by ID - does not exist at Commit Systems Modeling API and Services v1.0 75 -1. _project : Project[1] 2. _commit : Commit[1] Input 3. _externalRelationshipId : UUID[1] 1. The inputted Project exists 2. The inputted Commit exists 3. The inputted Commit belongs to the inputted Project Scenario 4. An ExternalRelationship with an id attribute value equal to _externalRelationshipId does not exist at the inputted Commit Project.allInstances()->includes(_project) Commit.allInstance()->includes(_commit) Precondition _commit.owningProject = _project (OCL) _commit.version->select(identity.id = _externalRelationshipId and data.oclIsTypeOf(ExternalRelationship)).data->isEmpty() Execute operation get_external_relationship_by_id(project = _project, commit =_commit, externalRelationshipId = _externalRelationshipId) : Steps ExternalRelationship[0..1] 1. Result, defined as externalRelationship : ExternalRelationship[0] , does not include any ExternalRelationships Result 2. Result communicates that an ExternalRelationship with the provided ID at the inputted Commit does not exist let externalRelationship : ExternalRelationship = get_external_relationship_by_id(_project, _commit, Postcondition _externalRelationshipId) (OCL) externalRelationship->isEmpty() A.6 ProjectUsageService Conformance Test Cases Operation get_project_usages PIM-PU-001 Description Get ProjectUsages - success 76 Systems Modeling API and Services v1.0 -1. _project : Project[1] Input 2. _commit : Commit[1] 1. The inputted Project exists Scenario 2. The inputted Commit exists 3. The inputted Commit belongs to the inputted Project Project.allInstances()->includes(_project) Precondition Commit.allInstance()->includes(_commit) (OCL) _commit.owningProject = _project Execute operation get_project_usages(project = _project, commit = _commit) : Steps ProjectUsage[0..*] 1. Result, defined as projectUsage : ProjectUsage[0..*] , is all of the existing Result ProjectUsages at the inputted Commit let projectUsage : ProjectUsage = get_project_usages(_project, _commit) Postcondition projectUsage = (OCL) _commit.version.data->select(oclIsKindOf(ProjectUsage)) A.7 Cross-Cutting Conformance Test Cases Operations with Invalid Input PIM-CC-001 Description Execute operation - missing Project input 1. _project : Project[0] Input Scenario Precondition (OCL) Systems Modeling API and Services v1.0 77 -Execute any of the following operations, defined as x(project : Project[1], …) : • get_elements(project = _project, …) • get_element_by_id(project = _project, …) • get_relationships_by_source(project = _project, …) • get_relationships_by_target(project = _project, …) • create_branch(project = _project, …) • get_branches(project = _project) • get_branch_by_id(project = _project, …) Steps • delete_branch(project = _project, …) • get_default_branch(project = _project) • set_default_branch(project = _project, …) • create_commit(project = _project, …) • get_commit_by_id(project = _project, …) • get_head(project = _project, …) • create_query(project = _project, …) 1. Result, defined as result : OclAny[0] , does not include any OclAny Result 2. Result communicates that project is a required input let result : OclAny = x(_project, …) Postcondition result->isEmpty() (OCL) PIM-CC-002 Description Execute operation - missing Commit input 1. _commit : Commit[0] Input Scenario Precondition (OCL) Execute any of the following operations, defined as x(commit : Commit[1], …) : • get_elements(…, commit = _commit) • get_element_by_id(…, commit = _commit, …) Steps • get_relationships_by_source(…, commit = _commit, …) • get_relationships_by_target(…, commit = _commit, …) • create_branch(…, head = _commit, …) 78 Systems Modeling API and Services v1.0 -1. Result, defined as result : OclAny[0] , does not include any OclAny Result 2. Result communicates that commit is a required input let result : OclAny = x(_commit, …) Postcondition result->isEmpty() (OCL) PIM-CC-003 Description Execute operation - Project input does not exist 1. _project : Project[1] Input Scenario The inputted Project does not exist Precondition Project.allInstances()->excludes(_project) (OCL) Execute any of the following operations, defined as x(project : Project[1], …) : • get_elements(project = _project, …) • get_element_by_id(project = _project, …) • get_relationships_by_source(project = _project, …) • get_relationships_by_target(project = _project, …) • create_branch(project = _project, …) • get_branches(project = _project) • get_branch_by_id(project = _project, …) Steps • delete_branch(project = _project, …) • get_default_branch(project = _project) • set_default_branch(project = _project, …) • create_commit(project = _project, …) • get_commit_by_id(project = _project, …) • get_head(project = _project, …) • create_query(project = _project, …) 1. Result, defined as result : OclAny[0] , does not include any OclAny Result 2. Result communicates that the inputted Project does not exist let result : OclAny = x(_project, …) Postcondition result->isEmpty() (OCL) Systems Modeling API and Services v1.0 79 -PIM-CC-004 Description Execute operation - Commit input does not exist 1. _commit : Commit[1] Input Scenario The inputted Commit does not exist Precondition Commit.allInstances()->excludes(_commit) (OCL) Execute any of the following operations, defined as x(commit : Commit[1], …) : • get_elements(…, commit = _commit) • get_element_by_id(…, commit = _commit, …) Steps • get_relationships_by_source(…, commit = _commit, …) • get_relationships_by_target(…, commit = _commit, …) • create_branch(…, head = _commit, …) 1. Result, defined as result : OclAny[0] , does not include any OclAny Result 2. Result communicates that the inputted Commit does not exist let result : OclAny = x(_commit, …) Postcondition result->isEmpty() (OCL) PIM-CC-005 Description Execute operation - Commit input is not owned by Project input 1. _project : Project[1] Input 2. _commit : Commit[1] 1. The inputted Project exists Scenario 2. The inputted Commit does not exist 3. The inputted Commit does not belong to the inputted Project Project.allInstances()->includes(_project) Precondition Commit.allInstances()->includes(_commit) (OCL) _commit.owningProject <> _project 80 Systems Modeling API and Services v1.0 -Execute any of the following operations, defined as x(project : Project[1], commit : Commit[1], …) : • get_elements(project = _project, commit = _commit) • get_element_by_id(project = _project, commit = _commit, …) • get_relationships_by_source(project = _project, commit = Steps _commit, …) • get_relationships_by_target(project = _project, commit = _commit, …) • create_branch(project = _project, head = _commit, …) 1. Result, defined as result : OclAny[0] , does not include any OclAny Result 2. Result communicates that the provided input is invalid let result : OclAny = x(_project, _commit, …) Postcondition result->isEmpty() (OCL) PIM-CC-006 Description Execute operation - missing name input 1. _name : String[0] Input Scenario Precondition (OCL) Execute any of the following operations, defined as x(name : String[1], …) : OclAny : • create_project(name = _name, …) Steps • create_branch(…, name = _name, …) 1. Result, defined as result : OclAny[0] , does not include any OclAny Result 2. Result communicates that name is a required input let result : OclAny = x(_name, …) Postcondition result->isEmpty() (OCL) PIM-CC-007 Description Execute operation - missing UUID input Systems Modeling API and Services v1.0 81 -1. _id : UUID[0] Input Scenario Precondition (OCL) Execute any of the following operations, defined as x(id : UUID[1], …) : OclAny : • get_project_by_id(projectId = _id) • get_element_by_id(…, elementId = _id) • get_relationships_by_source(…, elementId = _id) • get_relationships_by_target(…, elementId = _id) Steps • get_branch_by_id(…, branchId = _id) • delete_branch(…, branchId = _id) • set_default_branch(…, branchId = _id) • get_commit_by_id(…, commitId = _id) 1. Result, defined as result : OclAny[0] , does not include any OclAny Result 2. Result communicates that the input for which _id is used is a required input let result : OclAny = x(_id, …) Postcondition result->isEmpty() (OCL) 82 Systems Modeling API and Services v1.0 -BAnnex: API and Services Examples and Cookbook (Informative) B.1 Examples In this section, examples of REST/HTTP PSM (API) requests and responses are presented. The examples are organized per the tags in the OpenAPI specification that group individual endpoints, such as Project, Branch, Commit, and Element. The tags defined in the OpenAPI specification of the REST/HTTP PSM are generally organized by PIM Services. For each request, the curl notation and the resulting response with JSON data are presented. The term Protocol://FQDN in the request URLs indicates the protocol (e.g. http/https) and the Fully Qualified Domain Name (FQDN) of the System Modeling API and Services Provider, e.g. https://sysml2-test.omg.org. Project GET /projects Gets all the projects. Request: curl -X GET "Protocol://FQDN/projects" -H "accept: application/json" Response: [ { "@id": "09257c67-2dce-4177-a95a-f2ede95b3ef3", "@type": "Project", "defaultBranch": { "@id": "71904fd1-2d86-4bb3-a626-ca94097f746c" }, "description": null, "name": "1c-Parts Tree Redefinition Mon Oct 18 21:43:35 CDT 2021" }, { "@id": "0d885964-c176-4006-9809-4c74621da0f0", "@type": "Project", "defaultBranch": { "@id": "0a021fc1-b70c-4256-9342-41ed383d3933" }, "description": null, "name": "Hello SysML v2" }, { "@id": "11507ece-f27b-4b01-bc7e-1fe8cb4b665c", "@type": "Project", "defaultBranch": { "@id": "3e01a5f9-95bc-40de-8332-3d0d2c111d55" }, "description": null, "name": "8-Requirements Wed Oct 20 14:24:05 CDT 2021" } ] Systems Modeling API and Services v1.0 83 -GET /projects/{projectId} Gets the project with id {projectId}. Request: curl -X GET "protocol://FQDN/projects/0d885964-c176-4006-9809-4c74621da0f0" -H "accept: application/json" Response: { "@id": "0d885964-c176-4006-9809-4c74621da0f0", "@type": "Project", "defaultBranch": { "@id": "0a021fc1-b70c-4256-9342-41ed383d3933" }, "description": null, "name": "Hello SysML v2" } POST /projects Creates a new project using the project data specified in the body of the request. Request: curl -X POST "Protocol://FQDN/projects" -H "accept: application/json" -H "Content- Type: application/json" -d "{ \"@type\": \"Project\", \"description\": \"Getting started with SysML v2 REST/HTTP API\", \"name\": \"SysML v2 API Start\"}" Response (body): { "@id": "6b5e80d1-7291-4eef-880c-c462ca5a3288", "@type": "Project", "defaultBranch": { "@id": "e9e33b09-ad9b-45ea-a85b-107dc862c1ff" }, "description": "Getting started with SysML v2 REST/HTTP API", "name": "SysML v2 API Start" } Branch GET /projects/{projectId}/branches Gets all the branches in the project with id {projectId}. Request: curl -X GET "Protocol://FQDN/projects/6b5e80d1-7291-4eef-880c-c462ca5a3288/branches" -H "accept: application/json" Response (body): [ { "@id": "e9e33b09-ad9b-45ea-a85b-107dc862c1ff", 84 Systems Modeling API and Services v1.0 -"@type": "Branch", "head": { "@id": "068440fd-9294-4acf-bc61-00b9156c9dde" }, "name": "main", "owningProject": { "@id": "6b5e80d1-7291-4eef-880c-c462ca5a3288" }, "referencedCommit": { "@id": "068440fd-9294-4acf-bc61-00b9156c9dde" }, "timestamp": "2021-11-06T15:45:34.967737-04:00" }, { "@id": "feefb263-f330-49da-b679-1d65602bf611", "@type": "Branch", "head": { "@id": "068440fd-9294-4acf-bc61-00b9156c9dde" }, "name": null, "owningProject": { "@id": "6b5e80d1-7291-4eef-880c-c462ca5a3288" }, "referencedCommit": { "@id": "068440fd-9294-4acf-bc61-00b9156c9dde" }, "timestamp": "2021-11-06T15:55:57.332349-04:00" } ] GET /projects/{projectId}/branches/{branchId} Gets the branch with id {branchId} in the project with id {projectId}. Request: curl -X GET "Protocol://FQDN/projects/6b5e80d1-7291-4eef-880c-c462ca5a3288/branches/ e9e33b09-ad9b-45ea-a85b-107dc862c1ff" -H "accept: application/json" Response (body): { "@id": "e9e33b09-ad9b-45ea-a85b-107dc862c1ff", "@type": "Branch", "head": { "@id": "068440fd-9294-4acf-bc61-00b9156c9dde" }, "name": "main", "owningProject": { "@id": "6b5e80d1-7291-4eef-880c-c462ca5a3288" }, "referencedCommit": { "@id": "068440fd-9294-4acf-bc61-00b9156c9dde" }, "timestamp": "2021-11-06T15:45:34.967737-04:00" } POST /projects/{projectId}/branches Creates a new branch in the project with id {projectId} using the branch data specified in the body of the request. Systems Modeling API and Services v1.0 85 -Request: curl -X POST "Protocol://FQDN/projects/6b5e80d1-7291-4eef-880c-c462ca5a3288/branches" -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"@type\": \"Branch\", \"head\": { \"@id\": \"068440fd-9294-4acf-bc61-00b9156c9dde\" }, \"name\": \"SysML v2 API Explore Branch\", \"owningProject\": { \"@id\": \"6b5e80d1-7291-4eef-880c-c462ca5a3288\" }}" Response (body): { "@id": "feefb263-f330-49da-b679-1d65602bf611", "@type": "Branch", "head": { "@id": "068440fd-9294-4acf-bc61-00b9156c9dde" }, "name": null, "owningProject": { "@id": "6b5e80d1-7291-4eef-880c-c462ca5a3288" }, "referencedCommit": { "@id": "068440fd-9294-4acf-bc61-00b9156c9dde" }, "timestamp": "2021-11-06T15:55:57.332349-04:00" } Tag GET /projects/{projectId}/tags Gets all the tags in the project with id {projectId}. Request: curl -X GET "Protocol://FQDN/projects/6b5e80d1-7291-4eef-880c-c462ca5a3288/tags" -H "accept: application/json" Response: [ { "@id": "d4657183-c4c1-45e9-90ac-dc984fc7c488", "@type": "Tag", "name": "Release 1", "owningProject": { "@id": "6b5e80d1-7291-4eef-880c-c462ca5a3288" }, "referencedCommit": { "@id": "068440fd-9294-4acf-bc61-00b9156c9dde" }, "taggedCommit": { "@id": "068440fd-9294-4acf-bc61-00b9156c9dde" }, "timestamp": "2021-11-06T16:18:42.992149-04:00" } ] POST /projects/{projectId}/tags Creates a new tag in the project with id {projectId} using the tag data specified in the body of the request. 86 Systems Modeling API and Services v1.0 -Request: curl -X POST "Protocol://FQDN/projects/6b5e80d1-7291-4eef-880c-c462ca5a3288/tags" -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"name\": \"Release 1\", \"taggedCommit\": { \"@id\": \"068440fd-9294-4acf- bc61-00b9156c9dde\" }}" Response (body): { "@id": "d4657183-c4c1-45e9-90ac-dc984fc7c488", "@type": "Tag", "name": "Release 1", "owningProject": { "@id": "6b5e80d1-7291-4eef-880c-c462ca5a3288" }, "referencedCommit": { "@id": "068440fd-9294-4acf-bc61-00b9156c9dde" }, "taggedCommit": { "@id": "068440fd-9294-4acf-bc61-00b9156c9dde" }, "timestamp": "2021-11-06T16:18:42.992149-04:00" } GET /projects/{projectId}/tags/{tagId} Gets the tag with id {tagId} in the project with id {projectId}. Request: curl -X GET "Protocol://FQDN/projects/6b5e80d1-7291-4eef-880c-c462ca5a3288/tags/ d4657183-c4c1-45e9-90ac-dc984fc7c488" -H "accept: application/json" Response (body): { "@id": "d4657183-c4c1-45e9-90ac-dc984fc7c488", "@type": "Tag", "name": "Release 1", "owningProject": { "@id": "6b5e80d1-7291-4eef-880c-c462ca5a3288" }, "referencedCommit": { "@id": "068440fd-9294-4acf-bc61-00b9156c9dde" }, "taggedCommit": { "@id": "068440fd-9294-4acf-bc61-00b9156c9dde" }, "timestamp": "2021-11-06T16:18:42.992149-04:00" } Commit GET /projects/{projectId}/commits Gets all the commits in a project with id {projectId}. Request: Systems Modeling API and Services v1.0 87 -curl -X GET "Protocol://FQDN/projects/6b5e80d1-7291-4eef-880c-c462ca5a3288/commits" -H "accept: application/json" Response: [ { "@id": "068440fd-9294-4acf-bc61-00b9156c9dde", "@type": "Commit", "owningProject": { "@id": "6b5e80d1-7291-4eef-880c-c462ca5a3288" }, "previousCommit": null, "timestamp": "2021-11-06T15:54:11.867499-04:00" }, { "@id": "cd4e9929-a51f-4f68-b87e-42b63083d9e6", "@type": "Commit", "owningProject": { "@id": "6b5e80d1-7291-4eef-880c-c462ca5a3288" }, "previousCommit": { "@id": "068440fd-9294-4acf-bc61-00b9156c9dde" }, "timestamp": "2021-11-06T16:39:46.579269-04:00" } ] GET /projects/{projectId}/commits/{commitId} Gets the commit with id {commitId} in the project with id {projectId}. Request: curl -X GET "Protocol://FQDN/projects/6b5e80d1-7291-4eef-880c-c462ca5a3288/commits/ cd4e9929-a51f-4f68-b87e-42b63083d9e6" -H "accept: application/json" Response (body): { "@id": "cd4e9929-a51f-4f68-b87e-42b63083d9e6", "@type": "Commit", "change": [ { "@id": "635e54a6-f091-4925-b784-96c5243ca99d", "identity": { "@id": "7787bf4a-48fb-4176-a495-d23b38c2f3ec", "@type": "DataIdentity" }, "payload": null } ], "owningProject": { "@id": "6b5e80d1-7291-4eef-880c-c462ca5a3288" }, "previousCommit": { "@id": "068440fd-9294-4acf-bc61-00b9156c9dde" }, "timestamp": "2021-11-06T16:39:46.579269-04:00" } 88 Systems Modeling API and Services v1.0 -POST /projects/{projectId}/commits Creates a new commit in the given project with id {projectId} using the commit data specified in the body of the request. If the branch is not specified ({branchId} query parameter is absent), the default branch of the project will reference the new commit. Request: curl -X POST "Protocol://FQDN/projects/6b5e80d1-7291-4eef-880c-c462ca5a3288/commits" -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"@type\": \"Commit\", \"change\": [ { \"@type\": \"DataVersion\", \"payload\": { \"@type\": \"PartDefinition\", \"name\":\"Vehicle_B\" }, \"identity\":{ \"@type\":\"DataIdentity\" } } ], \"containingProject\": { \"id\": \"6b5e80d1-7291-4eef-880c-c462ca5a3288\" }, \"previousCommit\": { \"id\": \"d3b258d4-c2e3-4385-b044-e32f535ae673\" }}" Response: { "@id": "42122503-70f1-42e9-ac6d-9b1ea2790138", "@type": "Commit", "owningProject": { "@id": "6b5e80d1-7291-4eef-880c-c462ca5a3288" }, "previousCommit": { "@id": "d3b258d4-c2e3-4385-b044-e32f535ae673" }, "timestamp": "2021-11-06T17:01:11.031488-04:00" } Element GET /projects/{projectId}/commits/{commitId}/elements Gets all the elements at the commit with id {commitId} in the project with id {projectId}. Request: curl -X GET "Protocol://FQDN/projects/6b5e80d1-7291-4eef-880c-c462ca5a3288/commits/ 42122503-70f1-42e9-ac6d-9b1ea2790138/elements" -H "accept: application/json" Response: [ { "@type": "PartDefinition", "@id": "4ace3d89-fd5d-4a03-a303-376eea6fbf29", "identifier": "4ace3d89-fd5d-4a03-a303-376eea6fbf29", "name": "Vehicle_B", ... }, { "@type": "PartDefinition", "@id": "72f90039-064b-4e91-a21d-7c58813aa4c1", "identifier": "72f90039-064b-4e91-a21d-7c58813aa4c1", "name": "Vehicle_A", ... } ] Systems Modeling API and Services v1.0 89 -GET /projects/{projectId}/commits/{commitId}/elements/{elementId} Gets the element with id {elementId} at the commit with id {commitId} in the project with id {projectId}. Request: curl -X GET "Protocol://FQDN/projects/6b5e80d1-7291-4eef-880c-c462ca5a3288/commits/ 42122503-70f1-42e9-ac6d-9b1ea2790138/elements/72f90039-064b-4e91-a21d-7c58813aa4c1" -H "accept: application/json" Response: { "@type": "PartDefinition", "@id": "72f90039-064b-4e91-a21d-7c58813aa4c1", "name": "Vehicle_A", ... } Query GET /projects/{projectId}/queries Gets all the queries defined in the project with id {projectId}. Request: curl -X GET "Protocol://FQDN/projects/6b5e80d1-7291-4eef-880c-c462ca5a3288/queries" -H "accept: application/json" Response (body): [ { "@id": "1e368830-eee5-404a-be93-490a2b84d28f", "@type": "Query", "owningProject": { "@id": "6b5e80d1-7291-4eef-880c-c462ca5a3288" }, "scope": [], "select": [ "owner", "@type", "name", "@id" ], "where": { "@type": "PrimitiveConstraint", "inverse": false, "operator": "=", "property": "@type", "value": "PartDefinition" } }, { "@id": "2cfc2123-90c3-48a9-a165-b50d21ab067d", "@type": "Query", "owningProject": { "@id": "6b5e80d1-7291-4eef-880c-c462ca5a3288" }, 90 Systems Modeling API and Services v1.0 -"scope": [], "select": [ "owner", "@type", "name", "@id" ], "where": { "@type": "PrimitiveConstraint", "inverse": false, "operator": "=", "property": "@type", "value": "PartDefinition" } }, { "@id": "930167d5-0d5e-4f2e-8544-8f66f200e56a", "@type": "Query", "owningProject": { "@id": "6b5e80d1-7291-4eef-880c-c462ca5a3288" }, "scope": [], "select": [ "owner", "@type", "name", "@id" ], "where": { "@type": "PrimitiveConstraint", "inverse": false, "operator": "=", "property": "name", "value": "Vehicle_A" } }, { "@id": "ab894e8b-d6be-4af0-b029-b52058f20b93", "@type": "Query", "owningProject": { "@id": "6b5e80d1-7291-4eef-880c-c462ca5a3288" }, "scope": [], "select": [ "owner", "@type", "name", "@id" ], "where": { "@type": "PrimitiveConstraint", "inverse": false, "operator": "=", "property": "name", "value": "Vehicle_A" } } ] POST /projects/{projectId}/queries Creates a new query in project with id {projectId} using the query data specified in the body of the request. Systems Modeling API and Services v1.0 91 -Request: curl -X POST "Protocol://FQDN/projects/6b5e80d1-7291-4eef-880c-c462ca5a3288/queries" -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"@type\": \"Query\", \"select\": [ \"name\",\"@id\",\"@type\",\"owner\" ], \"where\": { \"@type\": \"PrimitiveConstraint\", \"inverse\": false, \"operator\": \"=\", \"property\": \"@type\", \"value\": \"PartDefinition\" }}" Response (body): { "@id": "2cfc2123-90c3-48a9-a165-b50d21ab067d", "@type": "Query", "owningProject": { "@id": "6b5e80d1-7291-4eef-880c-c462ca5a3288" }, "scope": [], "select": [ "owner", "@type", "name", "@id" ], "where": { "@type": "PrimitiveConstraint", "inverse": false, "operator": "=", "property": "@type", "value": "PartDefinition" } } GET /projects/{projectId}/queries/{queryId} Gets the query with id {queryId} in project with id {projectId}. Request: curl -X GET "Protocol://FQDN/projects/6b5e80d1-7291-4eef-880c-c462ca5a3288/queries/ 2cfc2123-90c3-48a9-a165-b50d21ab067d" -H "accept: application/json" Response (body): { "@id": "2cfc2123-90c3-48a9-a165-b50d21ab067d", "@type": "Query", "owningProject": { "@id": "6b5e80d1-7291-4eef-880c-c462ca5a3288" }, "scope": [], "select": [ "owner", "@type", "name", "@id" ], "where": { "@type": "PrimitiveConstraint", "inverse": false, "operator": "=", "property": "@type", 92 Systems Modeling API and Services v1.0 -"value": "PartDefinition" } } GET /projects/{projectId}/queries/{queryId}/results Executes the query with id {queryId} in project with id {projectId}. If the commit is not specified ({commitId} query parameter is absent), the query is executed at the head commit in the default branch of the project. Request: curl -X GET "Protocol://FQDN/projects/6b5e80d1-7291-4eef-880c-c462ca5a3288/queries/ 2cfc2123-90c3-48a9-a165-b50d21ab067d/ results?commitId=42122503-70f1-42e9-ac6d-9b1ea2790138" -H "accept: application/json" Response (body): [ { "@type": "PartDefinition", "@id": "4ace3d89-fd5d-4a03-a303-376eea6fbf29", "name": "Vehicle_B", "owner": null }, { "@type": "PartDefinition", "@id": "72f90039-064b-4e91-a21d-7c58813aa4c1", "name": "Vehicle_A", "owner": null } ] B.2 Cookbook The Systems Modeling API Cookbook is a collection of recipes demonstrating patterns and examples for using the Systems Modeling API and Services. Each recipe is a Jupyter (IPython) notebook (see https://jupyter.org) with a series of API calls using the REST/HTTP PSM of the API. The Systems Modeling API Cookbook is available as a zip file containing the Jupyter (IPython) notebooks with this specification. Systems Modeling API and Services v1.0 93 diff --git a/Resources/specification/Intro to the SysML v2 Language-Graphical Notation.pdf.txt b/Resources/specification/Intro to the SysML v2 Language-Graphical Notation.pdf.txt deleted file mode 100644 index b9a5d998..00000000 --- a/Resources/specification/Intro to the SysML v2 Language-Graphical Notation.pdf.txt +++ /dev/null @@ -1,123 +0,0 @@ -SST Introduction to the SysML v2 Language Graphical Notation (2023-03-07) This presentation uses the graphical notation to complement the textual syntax (i.e., notation) to represent a SysML model. The graphical notation is generated manually with Microsoft Visio. Copyright © 2021, 2022, 2023 by Sanford Friedenthal Licensed under the Creative Commons Attribution 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by/4.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA. -SST Agenda  Language Background and Overview  SysML v2 Functional Areas  Contrasting SysML v2 with SysML v1  Summary Refer to date in lower right on each slide to see when it was last modified 16 January 2023 2 -SST General Caveats  The graphical and textual notation (i.e., syntax) are different renderings of the same model  The textual syntax is formally specified using BNF  The graphical syntax is formally specified using graphical BNF  The graphical visualization in this presentation is captured in Visio  Two visualization prototypes are under development (Tom Sawyer and PlantUML)  SysML v2 Marker  Some of the more significant SysML v2 changes in functionality and terminology relative to SysML v1 are designated with the SysML v2 marker 07 March 2023 3 -Language Background & Overview 11 November 2022 4 -Systems Modeling Language™ SST ® (SysML ) Supports the specification, analysis, design, and verification and validation of complex systems that may include hardware, software, information, processes, personnel, and facilities  SysML has evolved to address user and vendor needs  v1.0, adopted in 2006; v1.6, current version; v1.7  SysML has facilitated awareness and adoption of MBSE  Much has been learned from using SysML for MBSE 07 March 2023 5 -SST SysML v2 Objectives Increase adoption and effectiveness of MBSE by enhancing…  Precision and expressiveness of the language  Consistency and integration among language concepts  Interoperability with other engineering models and tools  Usability by model developers and consumers  Extensibility to support domain specific applications  Migration path for SysML v1 users and implementors 11 November 2022 6 -SST Key Elements of SysML v2  New Metamodel that is not constrained by UML  Preserves most of UML modeling capabilities with a focus on systems modeling  Grounded in formal semantics  Robust visualizations based on flexible view & viewpoint specification  Graphical, Tabular, Textual  Standardized API to access the model 11 November 2022 7 -SST SysML v2 Language Architecture Declarative semantic base elements and Systems Modeling Language domain-specific libraries (SysML) modeled using SysML metamodel Systems and Systems Domain Model Syntax semantic library Libraries Declarative semantic Kernel Modeling Language base elements modeled (KerML) using KerML metamodel Kernel Kernel Model Syntax Library semantic library Direct semantic mapping to formal logic semantic specification Core Core Syntax Semantics Root syntactic elements without model-level semantics (e.g., packaging) Root Syntax 07 March 2023 8 -SST SysML v2 API & Services  Enables other tools and applications to access SysML models in a standard way  Provides services to:  Create, update, and delete elements  Query and navigate model  Other services including support for model management, analysis, transformation, and file export generation  Supports common patterns called recipes (GitHub - Systems-Modeling/SysML- v2-API-Cookbook: Recipes for using the SysML v2 API)  Navigating a decomposition tree  Creating a branch  Query with multiple constraints  Facilitates use of different implementation technologies such as REST/HTTP, Java, or OSLC 11 November 2022 9 -Pilot Implementation SST Using Standard API Meta-Model based on KerML 10 11 November 2022 -SysML v2 Language SST Capabilities Requirements Behavior Analysis - function-based - analysis cases - state-based - expression language - sequence-based SysML v2 - use cases Language Structure Verification - decomposition - verification cases - interconnection - classification View & Viewpoint 11 November 2022 11 -Definition and Usage SST Reuse Pattern  A definition element defines an element such as a part, action, or requirement  A usage element is a usage of a definition element in a particular context  There can be different usages of the same definition element in either different contexts or the same context  Pattern is applied consistently throughout the language «usage» «usage» «usage» context1 context2 context2 «usage» «usage» «usage» notation usage1 usage2 usage2 defined by : : «definition» «definition» «definition» DefinitionA DefinitionA DefinitionA 11 November 2022 12 -SysML v2 Notation (1 of 2) SST Textual and Graphical package 'Vehicle Parts Tree' { part vehicle { attribute mass; perform providePower; part engine { attribute mass; perform providePower.generateTorque; part cylinders [6]; } part transmission { attribute mass; perform providePower.amplifyTorque; } }} action providePower { action generateTorque; action amplifyTorque; } } 11 November 2022 13 -SysML v2 Notation (2 of 2) SST Textual and Graphical interface def Drive { end enginePort : DrivePort; end transmissionPort : ~DrivePort; } part vehicle : Vehicle { part engine : Engine { port drivePort : DrivePort; } part transmission : Transmission { port drivePort : ~DrivePort; } interface : Drive connect engine.drivePort to transmission.drivePort; } «part» vehicle : Vehicle «part» : Drive «part» transmission : engine: Engine Transmission drivePort : drivePort : DrivePort ~DrivePort Tom Sawyer Visualization Prototype 11 November 2022 14 -SysML v2 Spec (Clause 7) SST SysML v2 Language Description 7.14 Interfaces 7.1 Language Overview 7.15 Allocations 7.2 Elements and Relationships 7.16 Actions 7.3 Dependencies 7.17 States 7.4 Annotations 7.18 Calculations 7.5 Namespaces and Packages 7.19 Constraints 7.6 Definition and Usage 7.20 Requirements 7.7 Attributes 7.21 Cases 7.8 Enumerations 7.22 Analysis Cases 7.9 Occurrences 7.23 Verification Cases 7.10 Items 7.24 Use Cases 7.11 Parts 7.25 Views and Viewpoints 7.12 Ports 7.26 Metadata (incl. User Defined Keywords) 7.13 Connections 07 March 2023 15 -Module 1 Packages & Element Names 11 November 2022 16 -SST Model Organization  A hierarchy of packages, where packages can contain other packages and elements  Packages are namespaces that contain member elements that may be owned or unowned  A package can import members of another package as unowned members, where deletion semantics do not apply, and they can be referred to by their local name  Nested import notation enables flexible organization SimSpimlepVleehViechleicMleoMdeoldel SysML Standard SysML Standard Libraries Libraries VVeehhiicclleeCCoonnffiigguurraattiioonnss VVeehhiicclleeCCoonnffiigguurraattiioonn__aa «import»* SI SysML SI SI Standard KerML DDeeffiinniittiioonnss Libraries Libraries «import»* ISQ ISQ VVeehhiicclleeCCoonnffiigguurraattiioonn__bb ISQ SI ScalarValues VVeehhiicclleeAAnnaallyyssiiss «import»* KerML KerML Libraries Libraries ScalarValues RReeqquuiirreemmeennttss PPaarrttssTTrreeee ISQ ScalarFunctions «import»* VVeehhiicclleeVVeerriiffiiccaattiioonn ScalarValues ScalarValues ScalarFunctions AAccttiioonnTTrreeee SSttaatteess «import»* ScalarFunctions ScalarFunctions 11 November 2022 17 -SST Import Notation «import»  no star is element import «import» *  single star is package import (content of package) «import» **  double star is recursive including outer package  Imports can apply to any namespace, but packages are most commonly used  A package import can include filter criteria to select elements based on their metadata 11 November 2022 18 -SST Definitions Package  Example: Definitions package contains packages to define different kinds of elements  Ellipsis indicates there is more content Definitions PartDefinitions ItemDefinitions ActionDefinitions AttributeDefinitions SignalDefinitions StateDefinitions PortDefinitions InterfaceDefinitions RequirementDefinitions … 11 November 2022 19 -SST Package Compartments  Packages can include textual compartments  Filter can be applied to select element kinds Part Definitions members part def Vehicle part def Engine ... 16 January 2023 20 -SST Qualified Names  A qualified name of a model element is prepended by the name of its owner followed by a double colon (::)  A fully qualified name is prepended by the concatenated names of its owners in its containment hierarchy separated by double colons (::) A B B «part def» «part def» A::B::Vehicle B::Vehicle Vehicle Vehicle «part def» A::B::Vehicle 11 November 2022 21 -SST Element Names  Each element includes a universally unique identifier (UUID) that is not visible  Managed by the tool  Does not change over the life of the element  Each element can include a name  Required for an element to be referenced in the textual notation  Each element can optionally include a short name in angle brackets  Can be a user or tool selected id  An element can have one or more aliases in the context of a namespace «part def» Sports Utility Vehicle «part def» <1.1> Sports Utility Vehicle «part def» «alias» SUV «part def» Note: reserved words can be Sports Utility Vehicle shown in «guillemet» or bold «alias» PartDefinitions::SUV «part def» alias SUV 11 November 2022 22 -Module 2 Definition Elements 23 11 November 2022 -SST Part Definition  A Part Definition can contain features such «part def» Vehicle as attributes, ports, actions, and states attributes  A modular unit of structure mass:>ISQ::mass dryMass cargoMass electricalPower position velocity acceleration ... ports pwrCmdPort vehicleToRoadPort ... perform actions providePower provideBraking controlDirection ... exhibit states vehicleStates 11 November 2022 24 -SST Other Kinds of Definition Elements Terminology  Each kind of definition element can contain specific kinds of features  Attribute definition ▪ Data type that defines a set of data values «attribute def» Real ▪ Primitive attribute definitions include integer, Real, Complex, Boolean, String, …. «attribute def» ▪ Can include quantity kinds such as Torque with units Torque ▪ Can include complex data types such as vectors «port def» FuelCmdPort ~  Port definition ~ directed features ▪ Defines a connection point on parts that enable interactions in item fuelCmd:FuelCmd attributes ▪ Contain kinds of features including directed features with in, out, and in/out x:Real ▪ Ports can be conjugated (i.e., reverse direction of directed features) «item def» FuelCmd  Item definition «item def» ▪ Defines kind of entity that is acted on, such as an input, output or a stored item Fuel «action def»  Action definition ProvidePower ▪ Defines kind of behavior that transforms inputs and outputs parameters in pwrCmd:PwrCmd out torqueToWheels:Torque [*]  State definition «state def» VehicleStates ▪ Defines kind of behavior that responds to events actions ▪ Enables entry, exit, and do actions do providePower 11 November 2022 25 -SST Specialization  Definition elements can be specialized  Subclass inherits features from its superclass that can be redefined or subsetted  Subclass can add new features  Subclass can be a specialization of more than one superclass (i.e., multiple inheritance) «part def» Axle attributes mass «part def» FrontAxle attributes inherited ^mass added steeringAngle 11 November 2022 26 -SST Redefinition and Subsetting «port def»  An inherited feature can be redefined by a PwrCmdPort directed features feature whose definition is more specialized in item pwrCmd:PwrCmd  The more specialized feature overrides the inherited feature «port def» FuelCmdPort directed features  Symbol for redefines (:>>) in item fuelCmd:FuelCmd redefines pwrCmd «part def»  An inherited feature can be subsetted by one Engine or more features with a more constrained parts cylinders:Cylinder [4..8] multiplicity  The Engine4Cyl contains a subset of the «part def» cylinders contained by Engine Engine4Cyl  First redefine multiplicity to 4 parts cylinders [4] redefines cylinders cylinder1 [1] subsets cylinders  Then identify the subsetting features cylinder2 [1] subsets cylinders cylinder3 [1] subsets cylinders  Symbol for subsets (:>) cylinder4 [1] subsets cylinders 11 November 2022 27 -Module 3 Usage Elements 11 November 2022 28 -SST Part  A part is a usage of a part definition  Part inherits its features from its definition  Inherited features can be redefined or subsetted, and new features can be added «part» vehicle_b:Vehicle attributes mass :>> mass = dryMass+cargoMass+fuelTank.fuel.fuelMass dryMass :>> dryMass=sum(partMasses) redefined cargoMass :>> cargoMass default 0 [kg] partMasses = ( . . . ) added ^electricalPower ^position inherited ^velocity ^acceleration ports fuelCmdPort:FuelCmdPort :>> pwrCmdPort vehicleToRoadPort :>> vehicleToRoadPort wheelToRoadPort1:WheelToRoadPort wheelToRoadPort2:WheelToRoadPort perform actions ^providePower ^provideBraking ^controlDirection exhibit states ^vehicleStates parts fuelTank:FuelTank 11 November 2022 29 -SST Other Usage Elements Terminology  Other kinds of usage elements are defined by specific kinds of definition elements  Attributes defined by attribute definition  Ports defined by port definition  Items defined by item definition  Actions defined by action definition  States defined by state definition  … 11 November 2022 30 -SST Enumeration  A data type whose range is restricted to a set of discrete values  Without units «enum def» Colors ▪ Definition: enum def Colors {red; blue; green;} enums ▪ Usage: attribute color1: Colors = Colors::blue; red blue green  With units: ▪ Definition: enum def DiameterChoices :> ISQ::LengthValue { «enum def» enum = 60 [mm]; DiameterChoices enum = 70 [mm]; enums =60 [mm] =70 [mm] enum = 80 [mm]; =80 [mm] } ▪ Usage: attribute cylinderDiameter: DiameterChoices = 80 [mm]; 11 November 2022 31 -Usage Elements Defined By SST Default Definition Elements  A definition element is a subclass of the most general definition element in the SysML v2 library (e.g., Part)  A usage element is defined by a definition element  defined by is a kind of specialization  A usage element that is not provided a definition by the modeler is a subset of the most general usage element in the library (e.g., parts) Default part Default Part Definition «part» «part def» SysML v2 : parts [0..*] Part Library part without «part» vehicle_b definition defined by part with «part def» «part» «part def» : : Vehicle vehicle_b:Vehicle Vehicle definition 11 November 2022 32 -Module 4 Part Decomposition 11 November 2022 33 -SST SysML v1 Decomposition in SysML v2  defined by relationship is used to create next level of decomposition of a part def «part def» Vehicle «part» «part» «part» «part» «part» engine:Engine transmission:Transmission driveshaft:Driveshaft rearAxleAssembly fuelTank:FuelTank : defined by «part def» RearAxleAssembly «part» «part» «part» «part» differential:Differential rearAxle:Axle rearWheel1:Wheel rearWheel2:Wheel 11 November 2022 34 -SST Parts Decomposition  A parts tree is a composition of a part from other parts  SysML v1 only supports block decomposition  Definition element can serve as black-box specification without committing to an internal structure (e.g., part decomposition)  Can provide significant advantages (more intuitive, less ambiguous, easier to modify a design configuration) «part» vehicle_b:Vehicle «part» «part» «part» «part» «part» engine:Engine transmission:Transmission driveshaft:Driveshaft rearAxleAssembly:AxleAssembly fuelTank:FuelTank There is no part-to-part decomposition «part» «part» «part» «part» In SysML v1 differential:Differential rearAxle:Axle rearWheel1:Wheel rearWheel2:Wheel 11 November 2022 35 -Parts Tree Reuse & Modification SST Subsetting a Part  A part can be a subset of another part  Equivalent to specializing a part  Inherits the part decomposition and other features  Can modify inherited parts and features through redefinition and subsetting  Can add new parts subsets «part» «part» ««ppaarrtt»» «part» vehicle_b:Vehicle vehicle_c:Vehicle vveehhiiccllee__bb::VVeehhiiccllee vehicle_c:Vehicle «part» «part» «part» «part» «part» «part» ««ppaarrtt»» ««ppaarrtt»» ««ppaarrtt»» ««ppaarrtt»» ««ppaarrtt»» engine:Engine transmission:Transmission driveshaft:Driveshaft rearAxleAssembly:AxleAssembly fuelTank:FuelTank bodyAssy:BodyAssy eennggiinnee::EEnnggiinnee ttrraannssmmiissssiioonn::TTrraannssmmiissssiioonn ddrriivveesshhaafftt::DDrriivveesshhaafftt rreeaarrAAxxlleeAAsssseemmbbllyy::AAxxlleeAAsssseemmbbllyy ffuueellTTaannkk::FFuueellTTaannkk «part» «part» «part» «part» ««ppaarrtt»» ««ppaarrtt»» ««ppaarrtt»» ««ppaarrtt»» differential:Differential rearAxle:Axle rearWheel1:Wheel rearWheel2:Wheel ddiiffffeerreennttiiaall::DDiiffffeerreennttiiaall rreeaarrAAxxllee::AAxxllee rreeaarrWWhheeeell11::WWhheeeell rreeaarrWWhheeeell22::WWhheeeell 11 November 2022 36 -SST References  A part can refer to other parts that are part of another decomposition  Not composite (i.e., lifetime semantics do not apply) «part»  Bind the reference usage vehicle-trailer-system «part» «part» «part» vehicle trailerHitch trailer reference reference bind bind = = «part» «part» «part» «part» hitchBall trailerCoupler hitchBall trailerCoupler  A part can refer to an item that it stores «part» fuelTank «item» fuel 16 January 2023 37 -SST Multiplicity  Defines the number of features (e.g., parts) in a particular context  Defines a range with a lower bound and upper bound  Lower and upper bounds are integers ▪ Can be parameterized [x..y] where x and y are expressions  Default multiplicity is [1..1]  Optional multiplicity [0..1] «part» bodyAssy:BodyAssy «part» «part» «part» doors:Door [2..4] body sunroof:Sunroof [0..1] 11 November 2022 38 -Module 5 Part Interconnection 11 November 2022 39 -SST Connecting Parts  Parts can be connected via their ports or without ports  Parts can be connected directly without connecting to the composite part  Ports can contain nested ports  Flows can be shown on connections  References are dashed  Conjugate port  Binding connection «view» vehicle interconnection «part» vehicle_b:Vehicle «part» fuelTank:FuelTank «item» fuel:Fuel «part» rearAxleAssembly:AxleAssembly p1 : FuelOutPort fuel = «part» p2 : ~FuelOutPort rearWheel1:Wheel = «part» «part» «part» «part» «part» engine:Engine transmission:Transmission driveshaft:Driveshaft differential:Differential rearAxle:Axle = «part» rearWheel2:Wheel «part» vehicleSoftware engineStatus «part» vehicleController 11 November 2022 40 -SST Interfaces  A connection definition connects two usage elements (e.g., two parts)  An interface definition is a connection definition whose ends are compatible ports  Can contain flows  Can contain other kinds of features  An interface defined by an interface definition is used to connect ports  Ports on parts must be compatible with the interface definition «part» fuelTank:FuelTank «item» «interface def» fuel:Fuel FuelTankToEngine_IF p1 : FuelOutPort ports : FuelOutPort fuel:Fuel :FuelTankToEngine_IF : ~ FuelOutPort p2 : ~FuelOutPort item flows :Fuel «part» engine:Engine 11 November 2022 41 -Interface SST Connecting a Wheel to a Hub  Usage of WheelToHub interface definition specifies a compatible connection between a wheel and a hub  Connects composite ports on wheel and hub  Decomposes into 5 Wheel Fastener interfaces  Wheel Fastener interface species a compatible connection between a lugnut and shank  Contains features needed for a compatible connection wheelHub_IF : WheeltoHub_IF «part» «part» wheel:Wheel hub:Hub lugNutCompositePort: shankCompositePort: LugNutCompositePort ShankCompositePort «interface def» «port def» «port def» WheeltoHub_IF ShankCompositePort LugNutCompositePort ports ports lugNutCompositePort:LugNutCompositePort [1] ports shankCompositePort::ShankCompositePort [1] shankPort:ShankPort [*] lugNutPort:LugNutPort [*] interfaces wheelFastener_IF : WheelFastener_IF [5] connect lugNutCompositePort.lugNutPort to shankCompositePort.shankPort «port def» «port def» «interface def» ShankPort LugNutPort WheelFastener_IF attributes attributes ports threadDia = 14 [mm] threadDia = 14 [mm] lugNutPort:LugNutPort threadPitch = 1.5 [mm] threadPitch = 1.5 [mm] shankport:ShankPort shaftLength = 70 [mm] attributes maxTorque = 90 [ft-lbs] constraints {lugNutPort.threadDia == shankPort.threadDia} 11 November 2022 42 -SST Wheel Hub Interface  Usage of WheelHubInterface to specify interface between rear axle and wheels «interface def» WheeltoHub_IF ports lugNutCompositePort:LugNutCompositePort [1] shankCompositePort::ShankCompositePort [1] interfaces wheelFastener_IF : WheelFastener_IF [5] connect lugNutCompositePort.lugNutPort to shankCompositePort.shankPort «interface def» WheelFastener_IF ports lugNutPort:LugNutPort shankport:ShankPort attributes maxTorque = 90 [ft-lbs] constraints {lugNutPort.threadDia == shankPort.threadDia} 11 November 2022 43 -SST Nested Wheel Hub Interface 11 November 2022 44 -Module 6 Variability 11 November 2022 45 -SST Variability  Vehicle family is the superset model (150%)  Variation points represent elements that can vary  Can be applied to all definition and usage elements  A variant represents a particular choice at a variation point  A choice at one variation point can constrain choices at other variation points  A system can be configured by making choices at each variation point «part» «part» «part» vehicleFamily vehicleFamily vehicleFamily «variation» «variation» «variation» «variation» «variation» «variation» «part» «part» «part» «part» «part» «part» transmission transmission transmission engine engine engine «variant» «variant» «variant» «variant» «variant» «variant» «variant» «variant» «part» «part» «part» «part» «part» «part» «part» «part» transmissionAuto transmissionAuto engine4cyl engine6cyl transmissionManual engine4cyl engine6cyl transmissionManual constraints engine==engine::engine4cyl xor (engine==engine::engine6cyl and transmission==transmissionAuto) 11 November 2022 46 -SST Selected Vehicle Configuration  Vehicle_a subsets vehicleFamily to represent a particular design configuration  Selected parts must satisfy variability constraints  Model is inconsistent if constraints are not satisfied  Variability modeling applications can automate the selection of valid configurations «part» vehicleFamily «part» vehicle_a «part» «part» engine=engine6cyl transmission=transmissionAuto 11 November 2022 47 -Behavior 11 November 2022 48 -Module 7 Actions 11 November 2022 49 -SST Actions  Actions are defined by action definitions  Inherit features (e.g., input and output parameters)  Can redefine or subset inherited features or add new features «action» «action def» : : providePower ProvidePower parameters parameters in fuelCmd:FuelCmd :>> pwrCmd in pwrCmd:PwrCmd ^out torque [*] out torque:Torque [*] 11 November 2022 50 -SST Action Decomposition  Actions can be decomposed in a similar way as parts «action» providePower «action» «action» «action» «action» generateTorque amplifyTorque distributeTorque transferTorque 11 November 2022 51 -SST Part Performs Actions  A part that performs an action can reference an action in an action tree  This is done through reference subsetting «part» vehicle_b:Vehicle perform «action» providePower providePower :: providePower provideBraking controlDirection «action» «action» «action» «action» «part» amplifyTorque distributeTorque transferTorque generateTorque engine:Engine perform providePower.generateTorque providePower.generateTorque 07 March 2023 52 -SST Perform Action  Show two kinds  perform action1  perform action action1  The difference between these two is as follows  Line with arrow part part1 {perform action1} (example from previous slide) this creates an anonymous reference feature that subsets action1 which is often in a separate action tree. Name is properly qualified such as package1::action1). This is like a call action.  Line with white diamond part part1 {perform action action1} This creates an explicit reference feature called action1 that can either subset or bind to another action  This pattern is repeated for many different kinds of features. 11 November 2022 53 -Perform Action SST Simple Example package PerformActions{ «part» part0 part part0{ perform action action1; perform action2; } «perform action» «perform» action1 action2 action action2; } Alternatives «part» «part» part0 part0 «perform action» «perform action» «perform action» «perform action» action1 references action2 action1 ::> action2 07 March 2023 54 -Module 8 Action Flow 11 November 2022 55 -SST Action Flow  Actions can include successions and input/output flows  Control nodes include decision, merge, fork, and join nodes  Actions can include send and accept actions  Swimlanes represent performers of actions «perform action» providePower = «perform» «perform» «perform» «perform» = generateTorque transferTorque amplifyTorque distributeTorque = «perform» trigger1 «accept» es:EngineStarted Note: Parameter notation subject to change 16 January 2023 56 -SST Input/Output Flows  A flow is a kind of connection that transfers items from a source output to a target input  A flow is a transfer that continues while the source and target actions execute (this is the default)  A succession flow is a transfer that only occurs after the source action ends and before the target action starts «perform action» providePower = «perform» «perform» «perform» «perform» = generateTorque transferTorque amplifyTorque distributeTorque = «perform» trigger1 «accept» es:EngineStarted 16 January 2023 57 -SST Controlling Actions [1]  A start action and done action represent the start and end of an action sequence  A succession asserts that the target action can start execution only after the source action ends execution  A conditional succession asserts that the target action can start only if the guard condition is true (if…then). If the guard is false, the target action cannot start «action» transportPassenger [vehicleStarted] «action» «action» «action» «action» «action» unlockDoor openDoor enterVehicle closeDoor startVehicle start join1 fork1 «action» driveVehicle merge1 decision1 «action» «action» «action» «action» openDoor exitVehicle closeDoor lockDoor [else] done «action» [anotherDestination] providePower 11 November 2022 58 -SST Controlling Actions [2]  Control nodes are kinds of actions (with names) that control outgoing successions in response to incoming successions  Decision node ▪ 1 incoming succession and 1.. many outgoing successions ▪ One outgoing succession is selected based on the guard condition that is satisfied (“else” condition is the complement of all other guard conditions)  Merge node ▪ 1.. many incoming successions and 1 outgoing succession [vehicleStarted] ▪ The outgoing succession occurs when any of its incoming successions occur join1 fork1 «action» driveVehicle merge1 decision1 «action» «action» «action» «action» openDoor exitVehicle closeDoor lockDoor [else] done «action» [anotherDestination] providePower 59 11 November 2022 -SST Controlling Actions [3]  Fork node ▪ 1 incoming succession and 1.. many outgoing successions ▪ All outgoing successions occur when its incoming succession occurs  Join node ▪ 1.. many incoming successions and 1 outgoing succession ▪ Outgoing succession occurs when all its incoming successions occur Note: Control nodes cannot currently be applied to input/output flows join1 fork1 «action» driveVehicle merge1 decision1 «action» «action» «action» «action» openDoor exitVehicle closeDoor lockDoor [else] done «action» [anotherDestination] providePower 11 November 2022 60 -SST Controlling Actions [4]  startVehicle subsets startVehicle1 behavior which is independent of structure «perform action» ` startVehicle :> startVehicle1  Event occurrences driver:Driver vehicle:Vehicle  Accept actions and send actions «event» «event»  When a send action executes, it driverReady doorClosed transfers an item to a target part  When a triggering input item is «perform» «perform» turnVehicleOn trigger1 received, an accept action executes ` «send» vs «accept» vs:VehicleStart and can transfer the input item to vs vs:VehicleStart vs:VehicleStart another action «perform»  driver and vehicle are in a shared startEngine es.EngineStatus context (not shown) es:EngineStatus «perform» «perform» trigger2 sendStatus «accept» es:EngineStatus «send» es 61 16 January 2023 -Scenario_1o SST Textual Notation package Scenario_1o{ part def Driver{ item def VehicleStart; port p1; item def EngineStatus; port p2; } action startVehicle1{ part def Vehicle{ event occurrence doorClosed; port p1; event occurrence driverReady; } first doorClosed then driverReady; first driverReady then turnVehicleOn; part part0{ perform action startVehicle:>startVehicle1{ action turnVehicleOn send vs via source{ action :>> turnVehicleOn send vs via source{ in vs:VehicleStart; in :>> source = driver.p1; in source default self; } } action :>> trigger1 accept vs:VehicleStart via vehicle.p1; action trigger1 accept vs:VehicleStart; action :>> sendStatus send es via source{ flow of VehicleStart from trigger1.vs to startEngine.vs; in es:EngineStatus; action startEngine{ in :>> source = vehicle.p1; in item vs:VehicleStart; } out item es:EngineStatus; action :>> trigger2 accept es:EngineStatus via vehicle.p1; } flow of EngineStatus from startEngine.es to sendStatus.es; } part driver : Driver { action sendStatus send es via source{ perform startVehicle.turnVehicleOn; in es:EngineStatus; perform startVehicle.trigger2; in source default self; event startVehicle.driverReady; } } action trigger2 accept es:EngineStatus; part vehicle : Vehicle { perform startVehicle.trigger1; message of VehicleStart from turnVehicleOn to trigger1; perform startVehicle.startEngine; message of es:EngineStatus from sendStatus to trigger2; perform startVehicle.sendStatus; } event startVehicle.doorClosed; } interface driver.p1 to vehicle.p1; interface driver.p2 to vehicle.p1; } } 16 January 2023 62 -Module 9 States 11 November 2022 63 -SST States  States can be defined by state definitions  Inherit features (e.g., actions, nested states, transitions) from its state definition  Can redefine or subset inherited features or add new features «state» «state def» : : vehicleStates VehicleStates state actions state actions entry ^action1 entry action1 do action2' :>> action2 do action2 exit action3 07 March 2023 64 -SST State-based Behavior [1]  States decompose into nested states (without regions, which were in SysML v1)  A parallel state decomposes into concurrent states  A non-parallel state (default) decomposes into sequential/exclusive states  Transitions between sequential states  Triggered by events  Can include guard and action «state» vehicleStates «parallel» «state» «state» healthStates operatingStates vehicelOff «state» «state» «state» «state» normal maintenance on off vehicleStart [brakePedalDepressed] / send engineHealthStatus to driver «state» «state» degraded starting [vehicleStarted] 07 March 2023 65 -SST State-based Behavior [2]  States can have entry, exit, and do actions that can refer to actions in action trees or be defined locally  States can include constraints «state» operatingStates «state» on vehicleOff «state» state actions off entry performSelfTest do providePower exit applyParkingBrake vehicleStart [brakePedalDepressed] assert constraints / send engineHealthStatus to driver {electricalPower <= 500 [W]} «state» starting state actions [vehicleStarted] do startEngine exit send engineStartStatus to driver 07 March 2023 66 -SST Part Exhibits States  A part exhibits states  Owns its state-based behavior «state» «part» vehicleStates «parallel» vehicle_b:Vehicle «state» «state» actions healthStates operatingStates perform providePower vehicelOff «state» «state» «state» «state» normal maintenance on off perform actions vehicleStart applyParkingBrake [brakePedalDepressed] performSelfTest / send engineHealthStatus to driver «state» «state» exhibit states degraded starting [vehicleStarted] vehicleStates 07 March 2023 67 -Module 10 Interactions 11 November 2022 68 -SST Sequence View  Represents an event sequence and messages (refer to action flow on slide 62)  Event sequence  Message  Driver and vehicle are in a shared context (not shown) «part» «part» driver:Driver vehicle_b:Vehicle . . .driverReady .doorClosed vs:VehicleStart «perfrom» startEngine es:EngineStatus 16 January 2023 69 -Module 11 Individuals 11 November 2022 70 -SST Individuals  An individual definition is a unique member of a class with identity  A specialization of a class, having only one member  Has a unique lifetime  An individual is a usage that is defined by an individual definition  Can subset a part to represent a particular configuration  Can have different configurations across Vehicle-1 lifetime «part» «part def» «part» : vehicle_b:Vehicle Vehicle engine:Engine attributes vin:Integer mass «Individual def» «individual» Vehicle-1 : vehicle_b-1:Vehicle-1 attributes vin :>> vin = 1 ^mass 11 November 2022 71 -Module 12 Timeslices & Snaphots 11 November 2022 73 -SST 4D Model & Occurrences  Each entity called an occurrence has a lifetime  Distinct from attributes which do not have a lifetime  Includes a reference clock that can quantify time (defaults to universal clock)  Can specify time slices and snapshots  Spatial items are kinds of occurrences that have spatial extent that can change over their lifetime  Specified by shapes with position and orientation within coordinate frames  Individuals  Unique occurrence with a lifetime 11 November 2022 74 -Lifetime with SST Snapshots and Time Slices «Individual def»  Each individual definition has a unique lifetime Vehicle-1 attributes  Begins when it is created vin :>> vin = 1 ^mass  Ends when it is destroyed «individual»  Individual usage exists over some portion of vehicle_b-1:Vehicle-1 Vehicle-1 lifetime  Individual lifetime can be segmented into time «timeslice» slices (i.e., durations of time) vehicle_b-t0->t1:Vehicle-1 attributes ^vin = 1  A time slice whose duration is zero is a snapshot  Beginning and ending snapshot of a time slice is designated as start and done snapshot  The condition of an individual for a time slice or «snapshot» «snapshot» vehicle_b-t1:Vehicle-1 vehicle_b-t0:Vehicle-1 snapshot can be specified in terms of the values of attributes attributes tdone =1 [min] tstart = 0 [min] its features ^vin = 1 ^vin = 1 mass = 1549.9 [kg] mass = 1550 [kg] position = 1 [km] position = 0 [m] velocity = 60 [km/hr] velocity = 60 [km/hr] acceleration = 0 acceleration = 0 11 November 2022 75 -SST Individuals Playing Different Roles  An individual can play different roles and have different configurations in different time slices ▪ Individual wheel (Wheel-1) is left front wheel during vehicle_b_t1-t2 time slice ▪ Individual wheel (Wheel-1) is right front wheel during vehicle_b_t2-t3 time slice «part» vehicle_b:Vehicle «part» «part» part leftFront:Wheel rightFront:Wheel redefine «indvidual» vehicle_b-1:Vehicle-1 temporal «timelice» «timeslice» decomposition vehicle_b_t1->t2 vehicle_b_t2->t3 Individual time slice «individual» «individual» individual individual rightFront:Wheel-1 leftFront:Wheel-1 «individual» rightFront:Wheel-2 «individual» leftFront:Wheel-2 11 November 2022 76 -Module 13 Expressions and Calculations 11 November 2022 77 -SST Expressions  Used to compute a result  Library of mathematical functions (e.g., sum, max, …)  Includes arithmetic operators that also apply to vectors and tensors  Default value means value can be over-ridden using redefinition «part» vehicle_b:Vehicle attributes mass ::>> mass=dryMass+cargoMass+fuelTank.fuel.fuelMass dryMass :>> dryMass=sum(partMasses) cargoMass :>> cargoMass default 0 [kg] partMasses=(fuelTank.mass,frontAxleAssembly.mass,rearAxleAssembly.mass,engine.mass,transmission.mass,driveshaft.mass) 11 November 2022 78 -SST Calculations  A kind of behavior generally used to represent reusable mathematical functions «calc def»  Inputs Force  Expression parameters in m :> ISQ::mass  Returns a single result in a :> ISQ::acceleration return f :> ISQ::force = m*a ▪ Can have multiplicity  Represent a calculation definition using the textual notation calc def Force { in attribute m:>ISQ::mass; in attribute a:>ISQ::acceleration; return f :>ISQ::force = m * a; } 11 November 2022 79 -SST Calculations  Evaluate usage  Bind values to input parameters. Then evaluate expression and return a result  calc force : Force { in m=1500 [kg]; in a=9.806 [m/s^2]; }  Can bind a calc return value to an attribute  attribute f1 = Force (m=1500 [kg] , a = 9.806 [m/s ^2]); «calc def» «calc» Force force:Force parameters parameters in m :> ISQ::mass in m=1500 [kg] in a :> ISQ::acceleration in a=9.806 [m/s^2] return f :> ISQ::force = m*a ^return :> ISQ::force = m*a 16 January 2023 80 -SST Binding Connection  A binding is a kind of connection where both sides of the connection are asserted to be equal at all times  Symbol is «bind» or =  If both sides are not equal, the model is inconsistent (e.g., 3=4) is inconsistent  A tool could make both sides equal if the values are not the same ▪ In the above example, the values can be set to (3=3) or (4=4) ▪ For y = x+3, when x is 1, then y can be set to 4 so that both sides are equal  Different from the Boolean operator ‘==’, which evaluates whether both sides of the ‘==’ have the same value or not, and returns a value of true or false (e.g., {3==4} returns a value of false)  Binding can be used to establish equality of any kind of feature  A part can be bound (e.g., engine = engine4cyl)  A port on a composite part can be bound to a port on a nested part to constrain them to have equal values 16 January 2023 81 -Module 14 Quantities & Units 11 November 2022 82 -SST Quantities and Units  Quantity is an attribute (e.g., mass)  Quantity is defined by an attribute def of a quantity kind (e.g., MassValue)  Units conform to the quantity kind (e.g., kilograms conform to MassValue)  The values are associated with the units  A change in a unit can apply the unit conversion factor if a tool supports this  attribute m:MassValue = 25 [kg] (an equivalent value to 55.1 [lbs])  In SysML v1, a change in unit requires a change in the value type  Complex quantities and units can be derived from primitive quantities and units  distancePerVolume :> scalarQuantities = distance / volume  Libraries  International System of Quantities (ISQ)  International System of Units (SI)  US Customary Units (USCustomaryUnits) 11 November 2022 83 -Module 15 Constraints 11 November 2022 84 -SST Constraint Expression [1]  A Boolean expression that evaluates to true or false, which includes  Constraint operators (==), (>), (>=), (<), (<=), (!=) ▪ Used to compare expressions (e.g., {a < b})  Boolean operators include and, or, xor, not ▪ Used to logically combine expressions (e.g., {A and B or C})  Asserting a constraint to be true means the evaluation must be true for the model to be consistent «part def» part def FuelTank { FuelTank attribute mass :> ISQ::mass; attributes ref item fuel:Fuel{ fuelMassMax attribute redefines fuelMass; assert constraints } {fuel.fuelMass <= fuelMassMax} attribute fuelMassMax:>ISQ::mass; assert constraint {fuel.fuelMass<=fuelMassMax} «item» } fuel:Fuel 11 November 2022 85 -SST Constraint Expression [2]  Usage inherits constraint expression and redefines constraint parameters «part def» «part» FuelTank fuelTank:FuelTank attributes fuelMassMax attributes :>>fuelMassMax = 60 [kg] assert constraints {fuel.fuelMass <= fuelMassMax} assert constraints ^{fuel.fuelMass<=fuelMassMax} «item» «item» fuel:Fuel fuel1:>>fuel 11 November 2022 86 -SST Constraint Definition  Enables reuse of a constraint expression  Default parameter direction is ‘in’  Can assert a constraint on the usage  Bind parameters on the usage  Can mark dependent parameters as derived with slash «constraint def» «assert constraint» StraightLineDynamics sld:StraightLineDynamics parameters power :> ISQ::power parameters m :> ISQ::mass power = vehicle_b.engine.peakHorsePwr delta_t :> ISQ::time x_in :> ISQ:: length m=vehicle_b.mass v_in:>ISQ:: speed delta_t = 0.1 [s] x_out :> ISQ::length x_in = vehicle_b.position v_out :> ISQ::speed v_in = vehicle_b.speed a_out :> ISQ::acceleration /x_out = position_delta_t expression /v_out = speed_delta_t a_out == power/(mass*v_avg) and /a_out = acceleration v_out == v_in +a_out*delta_t and x_out == x_in+v_avg*delta_t 16 January 2023 87 -SST Binding Constraints  Equivalent to SysML v1 parametric diagram 11 November 2022 88 -Module 16 Requirements 11 November 2022 89 -SST Requirement Definition  A constraint definition that a valid design solution must satisfy that can include:  Identifier  Shall statement  Constraint expression that can be evaluated to true or false ▪ can apply to performance, functional, interface and other kinds of requirements if desired  Assumed constraint expression that is asserted to be true for the requirement to be valid  Attributes of the constraint expressions «requirement def» <1_1> MassRequirement doc The actual mass shall be less than the required mass. 16 January 2023 90 -SST Requirement Specification  A tree of requirements that contains nested requirement usages  Composite requirement can own or reference other requirements  Subject of nested requirements is the kind of entity being specified  Requirement features can redefine features of the requirement definition «requirement» composite requirement vehicleSpecification subject v:Vehicle subject «requirement» «requirement» <2> fuelEconomyRequirements <1> massReqt:MassRequirement reqt id doc The actual vehicle mass shall be less than the required vehicle mass. «requirement» «requirement» <2_1> city:FuelEconomyRequirementl <2_2> highway:FuelEconomyRequirement assumption 16 January 2023 91 -SST Satisfying a Requirement  The vehicleSpecification imposes constraints on the vehicle  The modeler can assert the vehicle mass satisfies the massRequired ▪ Bind the vehicle mass to massActual of the requirement «requirement» vehicleSpecification subject v:Vehicle «requirement» «part» <1> massReqt:MassRequirement vehicle_b:Vehicle doc The actual vehicle mass shall be less attributes than the required vehicle mass. :>>mass = dryMass + fluidMass :>>dryMass=sum(partMasses) :>>fluidMass = 36 [kg] … requirements satisfy vehicleSpecification constraints massReqt.massActual = mass ^require {massActual<=massRequired} massReqt.massFluid = fluidMass assume {massFluid<=40 [kg]} 16 January 2023 92 -Satisfying a Requirement SST Alternative Notation  Alternative notation «requirement» «part» vehicleSpecification vehicle_b:Vehicle subject v:Vehicle attributes :>>mass = dryMass + fluidMass ... «requirement» <1> massReqt:MassRequirement doc The actual vehicle mass shall be less than the required vehicle mass. «satisfy» vehicleSpecification.massReqt constraints ^require {massActual<=massRequired} assume {massFluid<=40 [kg]} 07 March 2023 93 -Requirement Allocation vs. SST Requirement Satisfaction  Allocating a requirement assigns responsibility for realizing a requirement  Less formal than requirement satisfaction (no explicit constraint assertion) «part»  Can be decomposed specificationContext «requirement» «allocate» «part» vehicleSpecification vehicle_b:Vehicle subject v:Vehicle attributes :>>mass = dryMass+fluidMass :>>dryMass=sum(partMasses) «requirement» :>>fluidMass = 36 [kg] <1> massReqt:MassRequirement … doc requirements The actual vehicle mass shall be less «allocate» satisfy vehicleSpecification than the required vehicle mass. massReqt.massActual = mass massReqt.massFluid = fluidMass constraints ^require {massActual<=massRequired} assume {massFluid<=40 [kg]} 16 January 2023 94 -SST Derived Requirement  Single original requirement with one or more «requirement» derived requirements engineSpecification  If the original requirement is satisfied, then all the derived requirements must be satisfied #derive «requirement» <2> massReqt:MassRequirement «requirement» doc vehicleSpecification The actual engine mass shall be less than the required engine mass. #original «requirement» «#derivation» <1> massReqt:MassRequirement «requirement» doc transmissionSpecification The actual vehicle mass shall be less than the required vehicle mass. «requirement» <3> massReqt:MassRequirement #derive doc The actual transmission mass shall be less than the required transmission mass. 16 January 2023 95 -Module 17 Use Cases 11 November 2022 96 -SST Use Case  A kind of case  Subject of the use case (often the system of interest)  Objective is to provide value to one or more actor ▪ Stakeholders are typically external to the system of interest referred to as actors  Required actions/steps performed by actors and subject to achieve the objective  Include use cases are always performed as part of the base use case  Constraints can specify pre and post conditions «subject» «use case def» ^vehicle TransportPassenger objective doc Deiver passenger to destination safely, comfortably, and within accecptable time «use case» «actor» ^driver:Driver transporttPassenger:TransportPassenger road:Road «include» «include» ^passengers:Passenger [0..4] «use case» «use case» ^getInVehicle:GetInVehicle ^getOutOfVehicle:GetOutOfVehicle 16 January 2023 97 -Module 18 Analysis Cases 11 November 2022 98 -SST Analysis Case  A set of steps with an objective to evaluate a «analysis» fuelEconomyAnalysis result about a subject of the analysis  A kind of behavior  Each step can be an action, calc, or an analysis case that can contain ▪ subject ▪ objective ▪ input and output parameters ▪ single return parameter (i.e., the result) ▪ attributes bound to calculations and/or constraints to be solved by a solver ▪ bind parameters to the subject convert to liters / 100 km «analysis» vehicleAnalysis «analysis» «analysis» straightLineDynamics fuelEconomyAnalysis 16 January 2023 99 -SST Trade-off Analysis  A kind of analysis case  Trade study objective is to select preferred solution that maximizes or minimizes some evaluation function «analysis»  Subject of the trade study are the vehicle alternatives engineTradeOffAnalysis:TradeStudy with different engines subject vehicleAlternatives [2] :> vehicle_b ▪ Alternatives can be modeled as variants objective :MaximizeObjective  Evaluate evaluation function for each alternative doc Select vehicle alternative with the engine whose evaluation function returns the max value ▪ Criteria are parameters of evaluation function alternatives ▪ Each criteria may require separate analysis vehicle_b_engine4cyl:>vehicleAlternatives vehicle_b_engine6cyl:>vehicleAlternatives  Rationale is a kind of annotation calcs :>> evaluationFunction { in part vehicle:>vehicle_b; return attribute eval:Real=EngineEvaluation (vehicle.engine.mass, vehicle.engine.peakHorsePower, vehicle.engine.fuelEfficiency, vehicle.engine.cost)} 11 November 2022 100 -Module 19 Verification Cases 11 November 2022 101 -SST Verification Case  A set of steps with an objective to «part» verificationContext evaluate whether the subject of the verification satisfies one or more «part» requirements vehicle_b:Vehicle attributes  A kind of behavior :>>mass = dryMass + fluidMass «part» :>>dryMass=sum(partMasses) verificationSystem :>>fluidMass = 36 [kg]  Steps typically include collect data, «perform» requirements process/reduce data, evaluate result satisfy vehicleSpecification «verification» massVerificationTest massReqt.massActual = mass  Subject is an input to the verification «verify» objective doc Verify massRequirement is  Returns a result called a verdict satisfied subject whose value is pass, fail, inconclusive, v:Vehicle:>vehicle_b or error actions collectData processData  Verify relationship relates evaluateResult : Verdict verification case to requirement  Verification system interacts with «verification» massVerificationTest subject to perform the verification = «action» «action» «action» = collectData processData evaluateResult verdict case v:Vehicle 11 November 2022 102 -Module 20 Dependency, Allocation, and Cause-Effect Relationships 11 November 2022 103 -SST Dependency  A directed relationship where the element on the client end may be impacted when the element on the supplier end changes  Example: Use of dependency to represent traceability between specification and source document  Can have 1.. many clients and 1.. many suppliers «item» supplier marketSurvey dependency «requirementGroup» client vehicleSpecification 11 November 2022 104 -SST Allocation  A statement of intent that assigns responsibility from one set of elements to another set of elements «allocate»  A kind of mapping (1 to n) «part» «part» torqueGenerator powerTrain  Includes definition and usage perform actions generateTorque generateTorque  Can include suballocations  Examples «part» «allocate» engine:Engine  Actions to components perform actions generateTorque generateTorque  Logical components to physical components  Logical connections to physical connections The torque generator  Budget allocation (e.g. weight budget) Is allocated to the powertrain, and realized by the engine  Software to hardware  Requirements to design elements  … 11 November 2022 105 -SST Cause-Effect Relationship  Single relationship can have multiple causes of multiple effects  Can logically combine different cause-effect relationships «state» vehicleStates «parallel» «state» «state» engineStates healthStates «parallel» «state» «state» «state» «state» operatingStates nominal maintenance healthStates «state» operatingStates «state» «state» «#causation» «state» nominal overheating degraded «#causation» «state» thermostat «parallel» «state» Vehicle Thermostat Stuck Closed failureStates Causes engine to overheat «state» stuckClosed «state» Causes vehicle to enter degraded state operatingStates «state» healthy «state» stuckOpen 16 January 2023 106 -Module 21 Annotations 11 November 2022 107 -SST Annotations «part» vehicle_b:Vehicle  An Annotating Element is an Element that is used to provide additional information about other elements «comment» Refer to document xyz  Can be named for full description  Can apply to 0.. many elements «action»  An annotation is a kind of relationship that relates the generateTorque annotating element to the element being annotated «rep»  Kinds of annotating elements language MATLAB body { x=  Comment y= }. ▪ Documentation is an owned comment  Textual representation (e.g., opaque expression) «analysis» straightLineDynamics ▪ Includes name of language and body  Metadata feature «metadata» ToolMetadata ▪ Used to add structured metadata toolName = Tool_X toolURL = behaviorName = Compute vehicle state 11 November 2022 108 -SST Metadata  Use metadata to mark elements  Identify parts that are Security or Safety parts (e.g., members of Security of Safety group)  Can add additional security and safety information «part» vehicle_b:Vehicle «part» «part» «part» engine:Engine transmission:Transmission driveshaft:Driveshaft «part» «part» interior:Interior bodyAssy:BodyAssy «part» «part» «part» «part» «part» «part» «part» «part» «part» driverAirBag sunroof:Sunroof [0..1] doors:Door [2..4] body bumper [2] alarm keylessEntry frontSeat [2] seatBelt [2] attributes metadata metadata metadata metadata metadata color:Colors Security Security Safety Safety Safety isMandatory=true isMandatory=false isMandatory=true Marked as a security part Marked a safety part Additional info: isMandatory 11 November 2022 109 -Module 22 Element Filters 11 November 2022 110 -SST Element Filters  Used to select elements from a group of elements  Create a package  Import the part of the model that contains the elements of interest ▪ Use a recursive import to include all nested elements  Define the filter expression to select the imported elements based on the selection criteria Security Parts Safety & Security Parts Safety Parts Safety Parts filter @Security filter @Safety and @Security filter @Safety Parts Tree Parts Tree Parts Tree Parts Tree Filter selects parts marked with Safety metadata 16 January 2023 111 -Module 23 View & Viewpoint 11 November 2022 112 -SST View and Viewpoint  A Viewpoint reflects the concerns of one more stakeholders in terms of what they care about relative to a domain of interest  A View specifies an artifact to present to a stakeholder to satisfy their viewpoint  Exposes the scope of the model to be viewed  Filters the model to select a particular subset based on a scope and filter criteria  Renders the filtered results using a particular presentation form and style  Intended to support document generation (e.g., OpenMBEE) VehicleConfiguration_b «view» «viewpoint» vehiclePartsTree structure viewpoint stakeholders structure «expose» structure architect Requirements PartsTree concerns system breakdown ActionTree States Include rendering in view compartment 113 11 November 2022 -SST SysML v2 Views and Diagrams  A view is a rendering of a selected model elements based on filter expression and exposed elements  Frame is the view element with view name  View is defined by a view definition (e.g., diagram kind)  View content «view» Vehicle Requirements : TreeView «view» Vehicle Requirements : «view» Vehicle Requirements : GeneralView «requirement» vehicleSpecification subject v:Vehicle «requirement» «requirement» <2> fuelEconomyRequirements <1> massReqt:MassRequirement doc The actual vehicle mass shall be less than the required vehicle mass. «requirement» «requirement» <2_1> city:FuelEconomyRequirementl <2_2> highway:FuelEconomyRequirement 16 January 2023 114 -Standard View Definitions SST (SysML v2 vs SysML v1) Baseline as of January 04, 2023 Standard views are normative, but user defined views are valid if they are consistent with the abstract syntax and graphical bnf . 16 January 2023 -SST SysML v2 Compartments  Compartments are views of the element represented by the node «part def» Vehicle  Compartment names represent view definitions attributes mass:>ISQ::mass dryMass  Standard compartments / view definitions cargoMass electricalPower position  Textual view of contained elements of a particular kind (e.g., velocity acceleration attributes, actions, ports) ... ports  Textual view of elements at the other end of relationships (e.g., pwrCmdPort vehicleToRoadPort ... allocation, specialization, …) perform actions providePower  A compartment can also be rendered using graphical notation provideBraking controlDirection ...  Ports and parameters are connectable nested nodes on the exhibit states boundary of a structure or behavior vehicleStates 116 16 January 2023 -Module 24 Language Extension 11 November 2022 117 -SST Language Extension SysML Model  Provides ability to extend concepts in Library SysML v2 to address domain-specific «stateUsage» concepts and terminology states  Define concept by subclassing an element in the SysML Model Library «stateUsage» define the  Define the keyword using metadata failure modes concept state 'failure modes'[*] nonunique; metadata def ’failure mode’ :> SemanticMetadata { :>> baseType = ‘failure modes’ meta SysML::StateUsage; } «#failure mode» flatTire  Apply the concept to an element by annotating it with the metadata apply the concept #'failure mode' flatTire; «#fm» flatTire #fm flatTire; 16 January 2023 118 -Contrasting SysML v2 with SysML v1 119 11 November 2022 -SysML v2 to v1 SST Terminology Mapping (partial) SysML v2 SysML v1 part / part def part property / block attribute / attribute def value property / value type port / port def proxy port / interface block action / action def action / activity state / state def state / state machine constraint / constraint def constraint property / constraint block requirement / requirement def requirement connection / connection def connector / association block view / view def view 11 November 2022 120 -SST Contrasting SysML v1 with SysML v2  Simpler to learn and use  More expressive  Systems engineering concepts designed  Variant modeling into metamodel versus added-on  Analysis case  Consistent definition and usage pattern  Trade-off analysis  More consistent terminology  Individuals, snapshots, time slices  Ability to decompose parts, actions, …  More robust quantitative properties  More flexible model organization (e.g., vectors, ..) (unowned members, package filters)…  Simple geometry  More precise  Query/filter expressions  Textual syntax and expression language  Metadata  Formal semantic grounding  More extensible  Requirements as constraints  Simpler language extension capability  Reified relationships (e.g., membership, ▪ Based on model libraries annotation)  More interoperable  Standardized API 11 November 2022 121 -Summary 122 11 November 2022 -SST Summary  SysML v2 is addressing SysML v1limitations to improve MBSE adoption and effectiveness  Precision, expressiveness  Regularity, usability  Interoperability with other engineering models and tools  Approach  Simplified SysML v2 metamodel with formal semantics overcomes fundamental UML limitations  Flexible graphical notations and textual notation  Standardized API for interoperability  Specification submitted to OMG on February 20, 2023  Will request vote to adopt at March 2023 OMG meeting  Becomes a beta specification if approved 07 March 2023 123 -SST References  Monthly Release Repository (release 2023-02)  https://github.com/Systems-Modeling/SysML-v2-Release  SysML v2 Specification (revised submission)  Note: refer to Annex B for Example Vehicle Model  Introduction to the SysML v2 Language Textual Notation (release 2021-08)  Friedenthal S., Seidewitz E., A Preview of the Next Generation System Modeling Language (SysML v2), Project Performance International (PPI), Systems Engineering Newsletter, PPI SyEN 95 27 November, 2020 07 March 2023 124 diff --git a/Resources/specification/Intro to the SysML v2 Language-Textual Notation.pdf.txt b/Resources/specification/Intro to the SysML v2 Language-Textual Notation.pdf.txt deleted file mode 100644 index 4594a3e8..00000000 --- a/Resources/specification/Intro to the SysML v2 Language-Textual Notation.pdf.txt +++ /dev/null @@ -1,185 +0,0 @@ -Introduction to the SysML v2 Language Textual Notation This is a training presentation on the SysML v2 language. It is updated as appropriate for each release of the SysML v2 Pilot Implementation maintained by the OMG® Systems Modeling Community (SMC) Release: 2026-03 Copyright © 2019-2026 Model Driven Solutions, Inc. Licensed under the Creative Commons Attribution 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by/4.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA. -Changes in this Release  In State Definition and subsequent slides on states, changed “entry; then … ;” to “first start then … ;”.  Revised use of feature references for Element Import Filtering. To find slides that have changed recently, search for Last changed: 2026-03 (and similarly for earlier releases). Release 2026-03 2 -SysML v2 Language Architecture Declarative semantic base elements and domain- Systems Modeling Language specific libraries modeled (SysML) using SysML metamodel Systems and Systems Syntax Domain Model semantic library Libraries Declarative semantic base Kernel Modeling Language elements modeled using (KerML) KerML metamodel Kernel Model Kernel Syntax Libraries semantic library Direct semantic mapping to formal logic semantic specification Core Core Semantics Syntax Root syntactic elements without model-level semantics (e.g., packaging) Root Syntax Last changed: 2020-09 Release 2026-03 3 -Four-Layer Language Architecture  Root – Root syntactic elements  Element, Comment, Documentation, Textual Representation, Namespace  Relationship, Annotation, Membership, Import, Dependency  Core – Fundamental semantic concepts – Formal declarative semantics  Type, Classifier, Feature, Multiplicity  Feature Membership, Specialization, Conjugation, Type Featuring, Feature Chaining, Feature Inverting, Unioning, Intersecting, Differencing  Kernel – Foundation for building modeling languages – Kernel semantic library  Class, Data Type, Behavior, Function, Metaclass, Step, Expression, Metadata Feature, Package  Association, Interaction, Connector, Binding Connector, Succession, Item Flow, Succession Item Flow  Systems – Modeling language for systems engineering – Domain libraries  Definition and Usage of: ▪ Attributes, Enumerations, Occurrences, Items, Parts, Ports, Actions, States, Constraints, Requirements, Concerns, Calculations, Cases, Analysis Cases, Verification Cases, Use Cases, Views, Viewpoints, Renderings, Metadata ▪ Connections, Interfaces, Allocations, Flows, Succession Flows Last changed: 2025-02 (“flow connection” renamed ”flow”) Release 2026-03 4 -Packages – Members  A name with spaces or other A package acts as a namespace An import adds either a single special characters is for its members and a container surrounded in single quotes. imported member or all the for its owned members . members of an imported package to the importing package. package 'Package Example’ { public import ISQ::TorqueValue; private import ScalarValues::*; A package can introduce aliases for its owned part def Automobile; The owned members of members or for individual a package are elements members of other packages. alias Car for Automobile; directly contained in alias Torque for ISQ::TorqueValue; the package. }  A qualified name is a package name (which may itself be qualified) followed by the name of one of its members, separated by :: . Last changed: 2024-07 (import visibility) Release 2026-03 5 -Packages – Visibility ! All members from a public import Visibility must be shown are visible (re-exported) from the explicitly on import declarations. importing package. Members Use private visibility unless re- from a private import are not. export is required. A private member is package 'Package Example' { not visible outside the public import ISQ::TorqueValue; package (but it is visible private import ScalarValues::*; to subpackages). private part def Automobile; public alias Car for Automobile; alias Torque for ISQ::TorqueValue; Members are public by } default but can also be marked public explicitly. Last changed: 2024-07 (import visibility) Release 2026-03 6 -Comments package 'Comment Example’ { A comment begins with /* and /* This is comment, part of the model, ends with */ . * annotating (by default) it's owning package. */ comment Comment1 /* This is a named comment. */ A comment can optionally be comment about Automobile named. /* This is an unnamed comment, annotating an * explicitly specified element. */ What the comment annotates can be explicitly specified (it is the part def Automobile; Import and alias declarations owning namespace by default). can also be commented. alias Car for Automobile { /* This is a comment annotating its owning * element. A note begins with // and */ extends to the end of the line. } (A multiline note begins with //* and ends with */.) // This is a note. It is in the text, but not part // of the model. alias Torque for ISQ::TorqueValue; } Last changed: 2023-10 (removed "documentary") Release 2026-03 7 -Documentation Documentation is a special kind of comment that is directly owned by the package 'Documentation Example' { element it documents. doc /* This is documentation of the owning * package. */ A documentation comment part def Automobile { can be optionally named doc Document1 like a regular comment. /* This is documentation of Automobile. */ } alias Car for Automobile { doc /* This is documentation of the alias. */ } alias Torque for ISQ::TorqueValue; } Last changed: 2023-07 (corrected "ISO" to "ISQ") Release 2026-03 8 -Part and Attribute Definitions A part definition is a definition of a class of systems or parts of An attribute usage usage of an systems, which are mutable and attribute definition, used here as exist in space and time. a feature of the part definition. part def Vehicle { attribute mass : ScalarValues::Real; A part usage is a composite part eng : Engine; feature that is the usage of a An attribute definition is a definition part definition . ref part driver : Person; of attributive data that can be used } to describe systems or parts. A reference part usage is a referential feature that is the attribute def VehicleStatus {  Definitions and usages are also usage of a part definition . private import ScalarValues::*; namespaces that allow import. attribute gearSetting : Integer; attribute acceleratorPosition : Real; } An attribute definition may not have composite part def Engine; features. Attribute usages part def Person; are always referential. Last changed: 2023-10 (corrected callout on attribute features) Release 2026-03 9 -Generalization/Specialization A specialized definition defines a subset of the classification of its generalization. abstract part def Vehicle; part def HumanDrivenVehicle specializes Vehicle { An abstract definition ref part driver : Person; The :> symbol is equivalent is one whose instances } to the specializes keyword. must be members of some specialization. part def PoweredVehicle :> Vehicle { part eng : Engine; A specialization can define } additional features. part def HumanDrivenPoweredVehicle :> HumanDrivenVehicle, PoweredVehicle; part def Engine; A definition can have multiple part def Person; generalizations, inheriting the features of all general definitions. Last changed: 2020-06 Release 2026-03 10 -Subsetting Subsetting asserts that, in any common context, the values of one feature are a subset of the values of part def Vehicle { another feature. part parts : VehiclePart[*]; part eng : Engine subsets parts; part trans : Transmission subsets parts; part wheels : Wheel[4] :> parts; } Subsetting is a kind of generalization between features. abstract part def VehiclePart; part def Engine :> VehiclePart; part def Transmission :> VehiclePart; part def Wheel :> VehiclePart; Last changed: 2020-06 Release 2026-03 11 -Redefinition A specialized definition can redefine a feature that would otherwise be inherited, to change part def Vehicle { its name and/or specialize its type. part eng : Engine; } part def SmallVehicle :> Vehicle { part smallEng : SmallEngine redefines eng; } The :>> symbol is equivalent part def BigVehicle :> Vehicle { to the redefines keyword. part bigEng : BigEngine :>> eng; } A feature can also specify multiplicity. There is shorthand notation part def Engine { for redefining a feature with part cyl : Cylinder[4..6]; the same name. }  The default multiplicity for part def SmallEngine :> Engine { parts is 1..1. part redefines cyl[4]; } part def BigEngine :> Engine { part redefines cyl[6]; } Redefinition can be used to constrain the multiplicity of a feature. part def Cylinder; Last changed: 2021-08 (multiplicity defaults) Release 2026-03 12 -Enumeration Definitions (1) An enumeration definition is a kind of attribute definition that defines a set of enumerated values. enum def TrafficLightColor { enum green; The values of an attribute usage defined enum yellow; by an enumeration definition are limited enum red; to the defined set of enumerated values. } part def TrafficLight { attribute currentColor : TrafficLightColor; } part def TrafficLightGo specializes TrafficLight { attribute redefines currentColor = TrafficLightColor::green; } This shows an attribute being bound to a specific value (more on binding later). Release 2026-03 Last changed: 2020-12 (new) 13 -Enumeration Definitions (2) An enumeration definition can contain nothing but declarations of its attribute def ClassificationLevel { enumerated values. However, it can attribute code : String; specialize a regular attribute attribute color : TrafficLightColor; definition and inherit nested features. } enum def ClassificationKind specializes ClassificationLevel { unclassified { :>> code = "uncl"; :>> color = TrafficLightColor::green; ! An enumeration definition } cannot specialize another The enum keyword is confidential { enumeration definition. :>> code = "conf"; optional when declaring :>> color = TrafficLightColor::yellow; enumerated values. } secret { :>> code = "secr"; The nested features can then be :>> color = TrafficLightColor::red; bound to specific values in each of } } the enumerated values. enum def GradePoints :> Real { A = 4.0; B = 3.0; Enumerated values can also be bound C = 2.0; directly to specific values of a specialized D = 1.0; attribute definition or data type. F = 0.0; } Release 2026-03 Last changed: 2020-12 (new) 14 -Parts (1) // Definitions part def Vehicle { part eng : Engine; } part def Engine { Parts can be specified part cyl : Cylinder[4..6]; outside the context of a } The defined by relationship is a specific part definition. part def Cylinder; kind of generalization. // Usages part smallVehicle : Vehicle { part redefines eng { part redefines cyl[4]; } Parts inherit properties from } their definitions and can part bigVehicle : Vehicle { redefine them, to any level of part redefines eng { nesting. part redefines cyl[6]; } } Last changed: 2020-12 (editorial) Release 2026-03 15 -Parts (2) // Definitions part def Vehicle; part def Engine; Composite structure can be part def Cylinder; specified entirely on parts. // Usages part vehicle : Vehicle { part eng : Engine { A part can specialize part cyl : Cylinder[4..6]; another part. } } part smallVehicle :> vehicle { part redefines eng { part redefines cyl[4]; } } part bigVehicle :> vehicle { part redefines eng { part redefines cyl[6]; } } Last changed: 2020-06 Release 2026-03 16 -Items An item definition defines a class of  All parts can be treated as items, but things that exist in space and time but not all items are parts. The design of a are not necessarily considered "parts" system determines what should be of a system being modeled. modeled as its "parts". item def Fuel; A system model may reference discrete item def Person; items that interact with or pass through the system. part def Vehicle { attribute mass : Real; ref item driver : Person;  The default multiplicity for attributes and items part fuelTank { is also 1..1. item fuel: Fuel; } Items may also model continuous } materials that are stored in and/or flow between parts of a system.  An item is continuous if any portion of it in space is the same kind of thing. A portion of fuel is still fuel. A portion of a person is generally no longer a person. Last changed: 2021-08 (multiplicity defaults) Release 2026-03 17 -Connections (1) A connection definition is connection def PressureSeat { a part definition whose end [1] part bead : TireBead; end [1] part mountingRim: TireMountingRim; usages are connections } Cross multiplicities constrain between its ends. the number of connections, part wheelHubAssembly : WheelHubAssembly { rather than end values. E.g. , for every TireBead there part wheel : WheelAssembly[1] { must be a PressureSeat part t : Tire[1] { part bead : TireBead[2]; connection to exactly one } TireMountingRim. part w: Wheel[1] { part rim : TireMountingRim[2]; part mountingHoles : LugBoltMountingHole[5]; } A connection is a usage of a connection : PressureSeat connection definition, connect bead references t.bead which connects two other Reference subsetting to mountingRim references w.rim; features. } (references or ::>) relates feature to a connector ends. part lugBoltJoints : LugBoltJoint[0..5]; “Dot” notation specifies part hub : Hub[1] { paths to nested features. If a connection definition is part h : LugBoltThreadableHole[5]; not specified, a generic } connect [0..1] lugBoltJoints to [1] wheel.w.mountingHoles; connection definition connect [0..1] lugBoltJoints to [1] hub.h; (called Connection) is used. } Last changed: 2024-12 (cross multiplicity) Release 2026-03 18 -Connections (2) These are owned features of the part wheel, not the part definition WheelAssembly. Feature chains (“dot notation”) like wheel.w.mountingHoles can be used to refer to the value of a specific feature in context (similarly to property paths in SysML v1). Last changed: 2024-12 (feature chain callout) Release 2026-03 19 -Ports Ports may have attribute and reference features. A feature with a direction (in, out or inout) is a directed feature. port def FuelOutPort { A port definition defines attribute temperature : Temp; features that can be out item fuelSupply : Fuel; made available via ports. in item fuelReturn : Fuel; (Replaces interface } blocks in SysML v1). port def FuelInPort { attribute temperature : Temp;  Directed features are in item fuelSupply : Fuel; always referential, so it is Two ports are compatible for out item fuelReturn : Fuel; not necessary to explicitly connection if they have } use the ref keyword. directed features that match with inverse directions. part def FuelTankAssembly { port fuelTankPort : FuelOutPort; A port is a connection point } through which a part definition makes some of part def Engine { its features available in a port engineFuelPort : FuelInPort; limited way. (Like a proxy } port in SysML v1.) Last changed: 2021-05 (editorial) Release 2026-03 20 -Port Conjugation port def FuelPort { attribute temperature : Temp; out item fuelSupply : Fuel; in item fuelReturn : Fuel; Every port definition has an implicit } conjugate port definition that reverses input and output features. It has the part def FuelTankAssembly { name of the original definition with ~ port fuelTankPort : FuelPort; prepended (e.g., '~FuelPort'). } part def Engine { port engineFuelPort : ~FuelPort; } Using a ~ symbol on the port type is a shorthand for using the conjugate port definition (e.g., FuelPort::'~FuelPort'). Last changed: 2021-05 (editorial) Release 2026-03 21 -Interfaces An interface definition is a connection definition whose ends are ports. interface def FuelInterface { end port supplierPort : FuelOutPort;  The default cross end port consumerPort : FuelInPort; multiplicity is 0..*. } part vehicle : Vehicle { part tankAssy : FuelTankAssembly; part eng : Engine; An interface usage is a interface : FuelInterface connect connection usage supplierPort ::> tankAssy.fuelTankPort to defined by an interface consumerPort ::> eng.engineFuelPort; definition, connecting } two compatible ports. Last changed: 2024-12 (cross multiplicity) Release 2026-03 22 -Interface Decomposition «interface def» WaterDelivery [1] [1..*] suppliedBy : deliveredTo : hot hot SpigotBank Faucet  Every suppliedBy cold cold SpigotBank must have Connection ends specify the one or more connections participants in the to deliveredTo Faucets. connection. They always have multiplicity 1. .1 relative to the connection definition. interface def WaterDelivery { end [1] port suppliedBy : SpigotBank { port hot : Spigot; Cross multiplicities port cold : Spigot; correspond to navigating } across connections. end [1..*] port deliveredTo : Faucet { Connection usages interconnect port hot : FaucetInlet; port cold : FaucetInlet; specific participants. } connect suppliedBy.hot to deliveredTo.hot; connect suppliedBy.cold to deliveredTo.cold; } Last changed: 2024-12 (cross multiplicity) Release 2026-03 23 -Binding Connections part tank : FuelTankAssembly { A binding connection is a connection port redefines fuelTankPort { that asserts the equivalence of the out item redefines fuelSupply; connected features (i.e., they have in item redefines fuelReturn; equal values in the same context). } bind fuelTankPort.fuelSupply = pump.pumpOut; bind fuelTankPort.fuelReturn = tank.fuelIn; part pump : FuelPump { Usages on parts can also have out item pumpOut : Fuel; direction (and are automatically in item pumpIn : Fuel; referential). } part tank : FuelTank { out item fuelOut : Fuel; in item fuelIn : Fuel; } } Last changed: 2021-04 (dot notation) Release 2026-03 24 -Binding Connections – Feature Values part tank : FuelTankAssembly { port redefines fuelTankPort { out item redefines fuelSupply = pump.pumpOut; in item redefines fuelReturn; } The feature value notation part pump : FuelPump { combines the definition of a out item pumpOut : Fuel; feature with a binding connection. in item pumpIn : Fuel; } part tank : FuelTank { out item fuelOut : Fuel; in item fuelIn : Fuel = fuelTankPort.fuelReturn; } } ! This is a binding, not an initial or default value. Last changed: 2023-10 (moved fuelSupply feature value, revised callouts) Release 2026-03 25 -Flows «part» A flow transfers a payload vehicle : Vehicle from the source output to the target input. fuelTankPort engineFuelPort Fuel «part» «part» tankAssy : eng : fuelSupply fuelSupply FuelTank Engine Assembly But it is actually a connection between the source and target ports.  A flow is streaming if the transfer is ongoing between the source and target, as opposed to happening once after the source generates its output and before the target consumes its input. Last changed: 2025-02 (“flow connection” renamed ”flow”) Release 2026-03 26 -Flow Usage part vehicle : Vehicle { A flow usage is a transfer of part tankAssy : FuelTankAssembly; some payload from an output part eng : Engine; of a source port to an input of a target port. flow of Fuel from tankAssy.fuelTankPort.fuelSupply to eng.engineFuelPort.fuelSupply; flow of Fuel  Specifying the payload type from eng.engineFuelPort.fuelReturn (e.g., “of Fuel”) is optional. to tankAssy.fuelTankPort.fuelReturn; } Last changed: 2025-02 (“flow connection” renamed ”flow”) Release 2026-03 27 -Flows in Interfaces interface def FuelInterface { Flows can be defined within end supplierPort : FuelOutPort; an interface definition. end consumerPort : FuelInPort; flow supplierPort.fuelSupply to consumerPort.fuelSupply; flow consumerPort.fuelReturn to supplierPort.fuelReturn; } part vehicle : Vehicle { The flows are established part tankAssy : FuelTankAssembly; when the interface is used. part eng : Engine; interface : FuelInterface connect supplierPort ::> tankAssy.fuelTankPort to consumerPort ::> eng.engineFuelPort; } Last changed: 2025-02 (“flow connection” renamed ”flow”) Release 2026-03 28 -Flow Definitions A flow definition is used to assert The definition can (optionally) that a flow must exist between constrain the payload the instances of part definitions. transferred by usages. flow def FuelFlow { ref :>> payload : Fuel; end port fuelOut : FuelOutPort; Note that the default end port fuelIn : FuelInPort; end multiplicities on this } connection are 1 to 1. This usage realizes the part vehicle : Vehicle { The payload should be required flow between the part tankAssy : FuelTankAssembly; consistent with what is tankAssy.fuelTankPort and part eng : Engine; declared in the flow the eng.engineFuelPort. definition (if any). flow : FuelFlow of Fuel from tankAssy.fuelTankPort.fuelSupply to eng.engineFuelPort.fuelSupply; } The connection is defined to be between the ports, but the transfer is still from an output to an input. Last changed: 2025-07 (payload in flow usage) Release 2026-03 29 -Action Definition DDiirreecctteedd ffeeaattuurreess ooff aann aaccttiioonn ddeeffiinniittiioonn AAnn aaccttiioonn ddeeffiinniittiioonn iiss aa ddeeffiinniittiioonn aarree ccoonnssiiddeerreedd ttoo bbee aaccttiioonn ppaarraammeetteerrss.. ooff ssoommee aaccttiioonn ttoo bbee ppeerrffoorrmmeedd.. aaccttiioonn ddeeff FFooccuuss{{ iinn sscceennee :: SScceennee;; oouutt iimmaaggee :: IImmaaggee;; }} aaccttiioonn ddeeff SShhoooott{{ iinn iimmaaggee :: IImmaaggee;; oouutt ppiiccttuurree :: PPiiccttuurree;; }} scene «action def» aaccttiioonn ddeeff TTaakkeePPiiccttuurree {{ TakePicture iinn sscceennee :: SScceennee;; AAnn aaccttiioonn iiss aa uussaaggee ooff aann aaccttiioonn ddeeffiinniittiioonn = oouutt ppiiccttuurree :: PPiiccttuurree;; ppeerrffoorrmmeedd iinn aa ssppeecciiffiicc ccoonntteexxtt.. scene «action» bbiinndd ffooccuuss..sscceennee == sscceennee;; focus image aaccttiioonn ffooccuuss :: FFooccuuss {{ iinn sscceennee;; oouutt iimmaaggee;; }};; AA ffllooww ccoann nbeec utisoend c taon image btrea nussfeedr titoe tmrasn bsefetwr een «action» ffllooww ffooccuuss..iimmaaggee ttoo sshhoooott..iimmaaggee;; iatcetmiosn bs.etween actions. shoot picture aaccttiioonn sshhoooott :: SShhoooott {{ iinn iimmaaggee;; oouutt ppiiccttuurree;; }} = picture bbiinndd sshhoooott..ppiiccttuurree == ppiiccttuurree;; AAnn aaccttiioonn hhaass ppaarraammeetteerrss }} ccoorrrreessppoonnddiinngg ttoo iittss aaccttiioonn ddeeffiinniittiioonn.. Last changed: 2025-02 (“flow connection” renamed ”flow”) Release 2026-03 30 -Action Succession (1) action def Focus{ in scene : Scene; out image : Image; } action def Shoot{ in image : Image; out picture : Picture; } action def TakePicture { scene in scene : Scene; «action def» out picture : Picture; TakePicture = bind focus.scene = scene; scene «action» action focus : Focus { in scene; out image; } focus image flow focus.image to shoot.image; A succession asserts that the image first action must complete «action» first focus then shoot; before the second can begin. shoot picture action shoot : Shoot { in image; out picture; } = picture bind shoot.picture = picture; } Last changed: 2024-09 (succession graphic) Release 2026-03 31 -Action Succession (2) action def Focus{ in scene : Scene; out image : Image; } action def Shoot{ in image : Image; out picture : Picture; } scene «action def» action def TakePicture { TakePicture in scene : Scene; A succession flow requires the = out picture : Picture; first action to finish producing scene its output before the second «action» bind focus.scene = scene; can begin consuming it. focus image «succession action focus : Focus { in scene; out image; } flow» image «action» succession flow focus.image to shoot.image; shoot picture action shoot : Shoot { in image; out picture; } = picture bind shoot.picture = picture; } Last changed: 2024-09 (succession flow graphic) Release 2026-03 32 -Action Notation Shorthands action def Focus{ in scene : Scene; out image : Image; } action def Shoot{ in image : Image; out picture : Picture; } scene «action def» This qualified name refers to the action def TakePicture { TakePicture scene parameter of TakePicture, in scene : Scene; = rather than the parameter of scene focus with the same name. action focus : Focus { «action» focus in scene = TakePicture::scene; image out image; This is the same shorthand } image for binding used previously. «action» flow focus.image to shoot.image; shoot picture = then action shoot : Shoot { picture in image; out picture; } This is a shorthand for a succession between out picture : Picture = shoot.picture; the lexically previous } action (focus) and this action (shoot). Last changed: 2024-09 (succession graphic) Release 2026-03 33 -Action Decomposition action def Focus{ in scene : Scene; out image : Image; } action def Shoot{ in image : Image; out picture : Picture; } action def TakePicture{in scene : Scene; out picture : Picture;} An action usage can also action takePicture : TakePicture { scene be directly decomposed in scene; «action» into other actions. takePicture : TakePicture action focus : Focus { = scene in scene = takePicture::scene; «action» out image; focus } takePicture is a usage, so dot image notation could be used here, but flow focus.image to shoot.image; image it is unnecessary because scene is in an outer scope, not nested. «action» then action shoot : Shoot { shoot in image; picture = out picture; picture } out picture = shoot.picture; } Last changed: 2024-09 (succession graphic) Release 2026-03 34 -Conditional Succession (1) action takePicture : TakePicture { in scene; action focus : Focus { scene A conditional succession asserts that the in scene = takePicture::scene; «action» second action must follow the first only out image; takePicture : TakePicture if a guard condition is true. If the guard } = is false, succession is not possible. scene first focus «action» if focus.image.isFocused then shoot; focus ! Note that, currently, image [image. the target action must flow focus.image to shoot.image; isFocused] image be explicitly named (no «action» shorthand). action shoot : Shoot { shoot in image; picture = out picture; } out picture = shoot.picture; } Last changed: 2024-09 (succession graphic) Release 2026-03 35 -Conditional Succession (2) action takePicture : TakePicture { in scene; out picture; scene «action» action focus : Focus { takePicture : TakePicture in scene = takePicture::scene; = scene out image; This is a shorthand for a conditional succession «action» } following the lexically previous action. focus image [image. if focus.image.isFocused then shoot; isFocused] image flow focus.image to shoot.image; «action» shoot action shoot : Shoot { picture = in image; picture out picture; } out picture = shoot.picture; } Last changed: 2024-09 (succession graphic) Release 2026-03 36 -Merge Nodes References the start of the action as the source of the initial succession. action takePicture : TakePicture { first start; A merge node waits for exactly then merge continue; one predecessor to happen continue before continuing. then action trigger { out item scene; } flow trigger.scene to focus.scene; then action focus : Focus { trigger in scene; scene out image; } scene flow focus.image to shoot.image; focus then action shoot : Shoot { image in image; out picture; image } shoot flow shoot.picture to display.picture; picture then action display { in picture; picture } display then continue; References the merge node named } “continue” as the target of the succession. Last changed: 2024-09 (succession graphics) Release 2026-03 37 -Decision Nodes action def ChargeBattery { first start; then merge continueCharging; continueCharging then action monitor : MonitorBattery { out batteryCharge : Real; } A decision node (decide keyword) chooses monitor exactly one successor to happen after it. then decide; if monitor.batteryCharge < 100 then addCharge; if monitor.batteryCharge >= 100 then endCharging; [batteryCharge >= 100] action addCharge : AddCharge { [batteryCharge < 100] in charge = monitor.batteryCharge; } A decision node is typically followed addCharge then continueCharging; by one or more conditional successions (the last “if…then” can action endCharging : EndCharging; be replaced by “else”). endCharging then done; References the end of the action as the target of a succession. } Last changed: 2024-09 (succession graphics) Release 2026-03 38 -Control Structures  Control-structure actions provide a structured alternative to control nodes for conditionals and looping. A loop action repeatedly performs a body action. This is the body action, which action def ChargeBattery { is given the name charging. (The default name is body.) loop action charging { action monitor : MonitorBattery { An if action performs its body if a out charge; Boolean condition is true. (It can } also have an else part, which is performed if the condition is false.) then if monitor.charge < 100 { if used in this way ! action addCharge : AddCharge { represents an action, until introduces a Boolean in charge = monitor.charge; not a succession. } condition that terminates the } loop when it is true. } until charging.monitor.charge >= 100;  A loop action can also begin with while (instead of loop), then action endCharging : EndCharging; introducing a Boolean then done; condition that terminates } the loop when it is false. Last changed: 2021-12 (new) Release 2026-03 39 -Fork and Join Nodes A fork node enables all its successors to happen after it. action def Brake { turnOn action turnOn; then fork; The source for all these then monitorBrakePedal; successions is the fork node. then monitorTraction; then braking; action monitorBrakePedal : MonitorBrakePedal { monitor out brakePressure; } BrakePedal then joinNode; action monitorTraction : MonitorTraction { out modulationFrequency; } then joinNode; monitor Traction flow monitorBrakePedal.brakePressure to braking.breakPressure; flow monitorTraction.modulationFrequency to braking.modulationFrequency; braking action braking : Braking { in brakePressure; in modulationFrequency; } then joinNode; A join node waits for all its predecessors join joinNode; to happen before continuing. then done; } Last changed: 2024-09 (succession graphics) Release 2026-03 40 -Performed Actions takePhoto is the local name of the performing action. perform identifies the part camera : Camera { owner as the performer of an action. perform action takePhoto[*] ordered references takePicture; The performing action part f : AutoFocus { references the performed perform takePhoto.focus; This shorthand simply action takePicture. } identifies the performed action owned elsewhere part i : Imager { without renaming it locally. perform takePhoto.shoot; } } Last changed: 2022-08 (reference subsetting) Release 2026-03 41 -Terminate Actions (1) action def MonitoredActivity { first start; monitorCriticalActivity then fork; and criticalActivity are then performCriticalActivity; preformed concurrently. then waitForTimeOut; performCriticalActivity action performCriticalActivity { «perform» perform monitorCriticalActivity; monitorCritical Activity perform criticalActivity; then terminate; A terminate action ends its «perform» criticalActivity } immediately containing action. In then stop; this case, performCriticalActivity terminates even if monitorCritical action waitForTimeOut; Activity is still ongoing. then stop; waitForTime stop action stop terminate; Out This terminates MonitoredActivity } when either performCriticalActivity or waitForTimeOut completes. Last changed: 2024-11 (new) 42 Release 2026-03 -Terminate Actions (2) part def Processor { ref action workflowProcess : WorkflowProcess; action internalProcess { // ... } A terminate action can have an } argument that identifies the action to be terminated (instead of the action terminateProcessing { default to the containing action). in processor : Processor; terminate processor.workflowProcess; terminate processor; A terminate action can also be used } to terminate (”destroy”) a part. ! A composite action is automatically terminated when its containing part is terminated, but a referential action is not. That is why workflowProcess was terminated explicitly in this example, but not internalProcess. 43 Release 2026-03 -Assignment Actions Using := instead of = action def ComputeMotion { here indicates an in attribute powerProfile :> ISQ::power[*]; initial value, instead in attribute vehicleMass :> ISQ::mass; in attribute initialPosition :> ISQ::length; of a binding. A for loop action repeatedly in attribute initialSpeed :> ISQ::speed; performs its body, setting a in attribute deltaT :> ISQ::time; loop variable to successive out attribute positions :> ISQ::length[*] := ( ); values from the result of a sequence expression. private attribute position := initialPosition; private attribute speed := initialSpeed; for vehiclePower in powerProfile { perform action dynamics : StraightLineDynamics { An action may also be in power = vehiclePower; performed by another in mass = vehicleMass; action (similar to a "call"). in delta_t = deltaT; in x_in = position; in v_in = speed; out x_out; out v_out; An assignment action sets } the value of a feature to the then assign position := dynamics.x_out; result of an expression at then assign speed := dynamics.v_out; the time of performance of  The functions including then assign positions := the assignment. comes from the positions->including(position); SequenceFunctions } library package. } Last changed: 2025-02 (changed for loop variable) Release 2026-03 44 -Asynchronous Messaging This is the name An accept action receives This is a declaration of what is being of the action. an incoming asynchronous received, which can be anything. transfer any kind of values. action takePicture : TakePicture { trigger action trigger accept scene : Scene; accept scene : Scene scene = then action focus : Focus { scene in scene = trigger.scene; out image; focus } image flow from focus.image to shoot.image; image then action shoot : Shoot { in image; shoot out picture; This is an expression that picture } = constructs the value to be sent. picture then send new Show(shoot.picture) to screen; send Show(picture) to screen }  The notation “Show(…)” means to create an instance of the This is also an expression, A send action is an definition Show with the given evaluating to the target (in this outgoing transfer of values value for its nested attribute. case just a feature reference). to a specific target. Last changed: 2025-02 (constructor notation) Release 2026-03 45 -Asynchronous Messaging through Ports An accept action can be via a specific viewPort part camera : Camera { port, meaning that the transfer is «part» port viewPort; expected to be received by that port. camera port displayPort; trigger accept scene : Scene action takePicture : TakePicture { via viewPort action trigger accept scene : Scene via viewPort; scene = scene then action focus : Focus { in scene = trigger.scene; focus out image; image } image flow from focus.image to shoot.image; then action shoot : Shoot { shoot in image; picture out picture; = picture } send Show(picture) via displayPort then send new Show(shoot.picture) via displayPort; } displayPort }An asynchronous transfer sent via a «interface» A send action can also be sent via port has that port as its source. The displayPort a port, meaning that the transfer target of the transfer is determined «part» is sent out from that port. by what the port is connected to. screen Last changed: 2025-02 (constructor notation) Release 2026-03 46 -Opaque Actions action def UpdateSensors { in sensors : Sensor[*]; language "Alf" /* An "opaque" action definition or * for (sensor in sensors) { usage can be specified using a * if (sensor.ready) { textual representation annotation * Update(sensor); in a language other than SysML. * } * } */ } The textual representation body is written using comment syntax. The /*, */ and leading * symbols are not included in the body text. Note that support for referencing SysML elements from the body text is tool-specific.  A textual representation annotation can actually be used with any kind of element, not just actions. OMG-standard languages a tool may support include "OCL" (Object Constraint Language) and "Alf" (Action Language for fUML). A tool can also provide support for other languages (e.g., "JavaScript" or "Modelica"). Last changed: 2022-07 (parameter declaration) Release 2026-03 47 -State Definitions (1) A state definition is like a state machine in UML and SysML v1. It defines a behavioral state that can be exhibited by a system. state def VehicleStates { first start then off; «state def» This indicates the the initial VehicleStates state off; state after entry is ”off”. transition off_to_starting first off accept VehicleStartSignal then starting; «state» A state definition can specify a off state starting; set of discrete nested states. VehicleStartSignal transition starting_to_on first starting accept VehicleOnSignal «state» then on; starting States are connected by transitions that fire on state on; VehicleOnSignal acceptance of item transfers transition on_to_off (like accept actions). first on «state» accept VehicleOffSignal on then off; VehicleOffSignal } Last changed: 2026-03 (changed “entry” to ”first start”) Release 2026-03 48 -State Definitions (2) «state def» VehicleStates This is a shorthand for a state def VehicleStates { transition whose source is first start then off; the lexically previous state. state off; «state» accept VehicleStartSignal off then starting; VehicleStartSignal state starting; accept VehicleOnSignal then on; «state» starting state on; accept VehicleOffSignal then off; VehicleOnSignal } «state» on VehicleOffSignal Last changed: 2026-03 (changed “entry” to ”first start”) Release 2026-03 49 -State Decomposition «state» A state can be explicitly vehicleStates : VehicleStates declared to be a usage of a state definition. state def VehicleStates; state vehicleStates : VehicleStates { first start then off; «state» off state off; accept VehicleStartSignal then starting; VehicleStartSignal A state can also be state starting; directly decomposed accept VehicleOnSignal «state» into other states. then on; starting state on; VehicleOnSignal accept VehicleOffSignal then off; } «state» on VehicleOffSignal Last changed: 2026-03 (changed “entry” to ”first start”) Release 2026-03 50 -Concurrent States «state» A parallel state is one whose vehicleStates : VehicleStates «parallel» nested states are concurrent. state def VehicleStates; «state» operationalStates state vehicleStates : VehicleStates parallel { state operationalStates { first start then off; «state» state off; off accept VehicleStartSignal then starting; VehicleStartSignal state starting; accept VehicleOnSignal then on; «state» starting state on; accept VehicleOffSignal VehicleOnSignal then off; ! } Transitions are not allowed between concurrent states. «state» state healthStates { on VehicleOffSignal … } «state» } healthStates Last changed: 2026-03 (changed “entry” to ”first start”) Release 2026-03 51 -State Entry, Do and Exit Actions States, like actions, can have parameters. «state» vehicleStates : VehicleStates action performSelfTest{in vehicle : Vehicle;} parameters state def VehicleStates{in operatingVehicle : Vehicle;} ^in operatingVehicle : Vehicle state vehicleStates : VehicleStates { in operatingVehicle : Vehicle; first start then off;  An entry action is performed VehicleOffSignal «state» on entry to a state, a do state off; off action while in it, and an exit accept VehicleStartSignal action on exit from it. then starting; VehicleStartSignal state starting; A state entry, do or exit accept VehicleOnSignal «state» then on; can reference an action starting defined elsewhere… state on { VehicleOnSignal entry performSelfTest { in vehicle = operatingVehicle; } do action providePower { … } «state» exit action applyParkingBrake { … } on } entry performSelfTest accept VehicleOffSignal do action providePower then off; … or the action can be exit action applyParkingBrake } defined within the state. Last changed: 2026-03 (changed “entry” to ”first start”) Release 2026-03 52 -Transition Guards and Effect Actions action performSelfTest{in vehicle : Vehicle;} «state» vehicleStates : VehicleStates state def VehicleStates { parameters in operatingVehicle : Vehicle; ^in operatingVehicle : Vehicle in controller : VehicleController; } ^in controller: VehicleController state vehicleStates : VehicleStates { in operatingVehicle : Vehicle; in controller : VehicleController; A guard is a condition that must be true for a «state» first start then off; transition to fire. off state off; VehicleStartSignal accept VehicleStartSignal [brakePedalDepressed]/ if operatingVehicle.brakePedalDepressed send ControllerStartSignal() do send new ControllerStartSignal() to controller then starting; «state» starting state starting; An effect action is performed accept VehicleOnSignal VehicleOnSignal when a transition fires, before then on; entry to the target state. state on { … } «state» accept VehicleOffSignal on VehicleOffSignal then off; } Last changed: 2026-03 (changed “entry” to ”first start”) Release 2026-03 53 -Change and Time Triggers action senseTemperature { out temp : TemperatureValue; } «state» healthStates state healthStates { An absolute time parameters in vehicle : Vehicle; trigger fires at a ^in operatingVehicle : Vehicle in controller : VehicleController; given instant of time. ^in controller: VehicleController do senseTemperature; actions A change trigger fires first start then normal; do senseTemperature(out temp) when a given Boolean state normal; expression becomes true. when accept at vehicle.maintenanceTime senseTemperature.temp > then maintenance; vehicle.maxTemperature accept when senseTemperature.temp > vehicle.maxTemperature normal do send new OverTemp() to controller then degraded; ! Time instant quantities are defined in the Time package, not the ISQ package. at vehicle. after 48[h] state maintenance { maintenanceTime entry assign vehicle.maintenanceTime := vehicle.maintenanceTime + vehicle.maintenanceInterval; } maintenance A relative time trigger accept after 48 [h] fires after a given then normal; when time duration. senseTemperature.temp <= state degraded; vehicle.maxTemperature accept when senseTemperature.temp <= vehicle.maxTemperature then normal; degraded  Change and time triggers can } also be used in accept actions. Last changed: 2026-03 (changed “entry” to ”first start”) Release 2026-03 54 -Local Clocks part def Server { Redefining the localClock feature of a part provides a part :>> localClock = new Time::Clock(); local time reference for composite items, parts and attribute today : String; actions nested within it. Each Server instance port requestPort; will have its own independent Clock. state ServerBehavior {  A localClock can also be first start then off; declared for an item or an  If no localClock is declared, action (or any kind of state off; the default is a universalClock occurrence that happens accept Start via requestPort that provides a common time then waiting; over time). universal reference. state waiting; accept request : Request via requestPort then responding; All absolute and relative accept at new Time::Iso8601DateTime(today + "11:59:00") time references are then off; relative to the localClock. state responding; accept after 5 [SI::min] then waiting; } } Last changed: 2025-02 (constructor notation) Release 2026-03 55 -Exhibited States part vehicle : Vehicle { part vehicleController : VehicleController; exhibit identifies the part exhibit vehicleStates { that is exhibiting states that in operatingVehicle = vehicle; are defined elsewhere. in controller = vehicleController; } } Parameters for a state usage can be bound in the same way as parameters of an action usage. ! Like performed actions, exhibited states are not composite features, therefore, a localClock on a part will not apply to performed actions or exhibited states of the part. Last changed: 2022-07 (localClock warning) Release 2026-03 56 -Occurrences, Time Slices and Snapshots (1)  An occurrence is something that happens over time. Items and parts are structural occurrences. Actions are behavioral occurrences. Attributes are not occurrences. attribute def Date; A time slice represents a portion of the lifetime of item def Person; an occurrence over some A succession asserts that the period of time. part def Vehicle { first occurrence ends before timeslice assembly; the second can begin. first assembly then delivery; snapshot delivery; A snapshot represents an first delivery then ownership; occurrence at a specific point in time (a time slice timeslice ownership[0..*] ordered; with zero duration). done is the name of the snapshot junked = done; end-of-life snapshot of }  Timeslices and snapshots any occurrence. are suboccurrences. Last changed: 2021-10 (successions) Release 2026-03 57 -Occurrences, Time Slices and Snapshots (2) part def Vehicle { … This is a shorthand snapshot delivery { for a succession after attribute deliveryDate : Date; the lexically previous } occurrence. then timeslice ownership[0..*] ordered { snapshot sale = start; start is the name of the start-of-life snapshot of ref item owner : Person[1]; any occurrence. Time slices and snapshots can have nested time timeslice driven[0..*] { slices, snapshots and ref item driver : Person[1]; other features applicable } during their occurrence. } One occurrence references snapshot junked = done; another during the same time period in the other } reference’s lifetime. Last changed: 2021-05 (new) Release 2026-03 58 -Event Occurrences An event occurrence is a reference to something that part driver : Driver { happens during the lifetime event occurrence setSpeedSent; of another occurrence. } part vehicle : Vehicle { part cruiseController : CruiseController { event occurrence setSpeedReceived; then event occurrence sensedSpeedReceived; then event occurrence fuelCommandSent; Event occurrences can } be sequenced as usual using succession. part speedometer : Speedometer { event occurrence sensedSpeedSent; } part engine : Engine { event occurrence fuelCommandReceived; } } Last changed: 2021-05 (new) Release 2026-03 59 -Messages (1) An occurrence definition defines a class of occurrences, without committing to whether they are structural or behavioral. occurrence def CruiseControlInteraction { ref part :>> driver; A message asserts that there is ref part :>> vehicle; a transfer of some payload of a certain type from one message setSpeedMessage of SetSpeed occurrence to another from driver.setSpeedSent (specifying the payload type is to vehicle.cruiseController.setSpeedReceived; optional). message sensedSpeedMessage of SensedSpeed from vehicle.speedometer.sensedSpeedSent to vehicle.cruiseController.sensedSpeedReceived; Messages can be explicitly ordered. Otherwise, they are message fuelCommandMessage of FuelCommand only partially ordered by the from vehicle.cruiseController.fuelCommandSent time-ordering of their respective to vehicle.engine.fuelCommandReceived; source and target events. first setSpeedMessage then sensedSpeedMessage; } Last changed: 2022-09 (source and target events) Release 2026-03 60 -Messages (2) occurrence def CruiseControlInteraction { ref part driver : Driver { event setSpeedMessage.sourceEvent; An event can also be specified } by reference to an identified occurrence (such as the source ref part vehicle : Vehicle { or target of a message). part cruiseController : CruiseController { event setSpeedMessage.targetEvent; then event sensedSpeedMessage.targetEvent; then event fuelCommandMessage.sourceEvent; } part speedometer : Speedometer { event sensedSpeedMessage.sourceEvent; } part engine : Engine { Each message has a event fuelCommandMessage.targetEvent; sourceEvent and } targetEvent, even if it is } not explicitly identified in the message declaration. message setSpeedMessage of SetSpeed; then message sensedSpeedMessage of SensedSpeed; message fuelCommandMessage of FuelCommand; } Last changed: 2022-09 (sourceEvent and targetEvent) Release 2026-03 61 -Interactions  Event occurrences and messages can be used together to specify an interaction between parts without committing to how the interaction happens. «occurrence def» CruiseControlInteraction ! Sequence diagram graphical notation is «part» purely illustrative. vehicle «part» «part» «part» «part» speedometer engine driver cruiseController Succession must be message setSpeedMessage event occurrence event occurrence specified explicitly for of SetSpeed setSpeedSent setSpeedReceived events in different lifelines. then Succession is implicit between events on a single lifeline. message sensedSpeedMessage of SensedSpeed event occurrence event occurrence sensedSpeedReceived sensedSpeedSent event occurrence message fuelCommandMessage fuelCommandReceived of FuelCommand event occurrence fuelCommandSent Last changed: 2023-10 (names not bold) Release 2026-03 62 -Interaction Realization by Actions (1)  An interaction can be realized by many different models. A valid realization part driver_a : Driver { must have suboccurrences that can be perform action driverBehavior { identified with all the events and send SetSpeed() to vehicle_a; } messages in the interaction. } In this model, event occurrences are part vehicle_a : Vehicle { realized by nested send part cruiseController_a : CruiseController { and accept actions. perform action controllerBehavior { accept SetSpeed via vehicle_a; then accept SensedSpeed via cruiseController_a; then send new FuelCommand() to engine_a; } } part speedometer_a : Speedometer { perform action speedometerBehavior { Messages are realized send new SensedSpeed() to cruiseController_a; by the implicit transfers } between send actions } and corresponding  In more realistic cases, a part engine_a : Engine { accept actions. realizing model will have more perform action engineBehavior { extensive behavior, only a accept FuelCommand via engine_a; subset of which will conform } to any one interaction model. } } Last changed: 2021-10 (accept via) Release 2026-03 63 -Interaction Realization by Actions (2) «occurrence» cruiseControlInteraction_a : CruiseControlInteraction «part» vehicle_a «part» «part» «part» «part» :>> speedometer :>> engine :>> driver :>> cruiseController :>> speedometer_a :>> engine_a :>> driver_a :>> cruiseController_a perform perform perform perform driverBehavior cruiseControllerBehavior speedometerBehavior engineBehavior SetSpeed accept setSpeed send setSpeed() This succession from the then interaction may not actually be satisfied by the realization. SensedSpeed accept SensedSpeed send SensedSpeed() FuelCommand accept send FuelCommand() FuelCommand Last changed: 2023-10 (names not bold) Release 2026-03 64 -Interaction Realization by Flows (1) part driver_b : Driver {  Ports are also suboccurrences port setSpeedPort { out setSpeed : SetSpeed; of the parts that contain them. } In this model, event } occurrences are realized interface driver_b.setSpeedPort to vehicle_b.setSpeedPort { flow of SetSpeed from driver_b.setSpeedPort.setSpeed by values leaving from to vehicle_b.setSpeedPort.setSpeed; and arriving at ports. } part vehicle_b : Vehicle { port setSpeedPort { in setSpeed : SetSpeed; } part cruiseController_b : CruiseController { port setSpeedPort { in setSpeed : SetSpeed = vehicle_b.setSpeedPort.setSpeed; } Messages are realized by port sensedSpeedPort { explicit flows between in sensedSpeed : SetSpeed; } features of ports. … } flow of SensedSpeed from speedometer_b.sensedSpeedPort.sensedSpeed to cruiseController_b.sensedSpeedPort.sensedSpeed; part speedometer_b : Speedometer { port sensedSpeedPort { out sensedSpeed : SensedSpeed; } } … Last changed: 2025-02 (constructor notation) Release 2026-03 65 -Interaction Realization by Flows (2) «occurrence» cruiseControlInteraction_b : CruiseControlInteraction «part» vehicle_b «part» «part» «part» «part» :>> speedometer :>> engine :>> driver :>> cruiseController :>> speedometer_b :>> engine_b :>> driver_b :>> cruiseController_b port port port port port port setSpeedPort setSpeedPort sensedSpeedPort fuelCommandPort fuelCommandPort sensedSpeedPort This is a snapshot of when the setSpeed is flow of SetSpeed received into the port. in setSpeed out setSpeed then flow of SensedSpeed in SensedSpeed out SensedSpeed This is a snapshot of when the setSpeed is sent out of the port. flow of FuelCommand in out FuelCommand FuelCommand Last changed: 2023-10 (names not bold) Release 2026-03 66 -Message Payloads  The default name for a message payload is payload. message setSpeedMessage of SetSpeed from driver.setSpeedSent to vehicle.cruiseController.setSpeedReceived; The payload of a message can be declared with a then message sensedSpeedMessage of SensedSpeed name for reference. from vehicle.speedometer.sensedSpeedSent to vehicle.cruiseController.sensedSpeedReceived; then message fuelCommandMessage of fuelCommand : FuelCommand from vehicle.cruiseController.fuelCommandSent to vehicle.engineController.fuelCommandReceived; then message fuelCommandForwardingMessage of fuelCommand : FuelCommand = fuelCommandMessage.fuelCommand from vehicle.engineController.fuelCommandForwarded to vehicle.engine.fuelCommandReceived; The payload of a message can also be bound to ! Note that a payload declaration a specific value. In this case, the without a colon names the type of fuelCommandMessage payload is forwarded by the payload, not the payload itself. the engineController to the engine. Last changed: 2022-10 (new) Release 2026-03 67 -Individuals and Snapshots (1) An individual definition is an An individual definition will occurrence definition (of any kind) often specialize a definition of restricted to model a single individual the general class of things the and how it changes over its lifetime. individual is one of. As occurrences, individuals can have snapshots that individual part def Vehicle_1 :> Vehicle { describe them at a single instant of time. snapshot part vehicle_1_t0 : Vehicle_1 { :>> mass = 2000.0; :>> status { :>> gearSetting = 0; This is a compact :>> acceleratorPosition = 0.0; notation for showing } redefinition of an } An attribute does not have attribute usage. snapshots, but it can be } asserted to have a specific value in a certain snapshot. Last changed: 2024-02 (removed PhysicalContext) Release 2026-03 68 -Individuals and Snapshots (2) individual part def Vehicle_1 :> Vehicle { snapshot part vehicle_1_t0 : Vehicle_1 { :>> mass = 2000.0; :>> status { :>> gearSetting = 0; :>> acceleratorPosition = 0.0; } } snapshot part vehicle_1_t1 : Vehicle_1 { :>> mass = 1500.0; The values of the attributes As usual, succession asserts :>> status { of an individual can change that the first snapshot :>> gearSetting = 2; over time. occurs before the second in :>> acceleratorPosition = 0.5; time, in some context. } } first vehicle_1_t0 then vehicle_1_t1; } Last changed: 2021-05 (occurrence modeling) Release 2026-03 69 -Individuals and Roles individual part def Vehicle_1 :> Vehicle { part leftFrontWheel : Wheel; part rightFrontWheel : Wheel; } During the first snapshot of individual part def Wheel_1 :> Wheel; vehicle_1, Wheel_1 has the role of the leftFrontWheel. individual part vehicle_1 : Vehicle_1 { snapshot part vehicle_1_t0 { An individual usage snapshot leftFrontWheel_t0 : Wheel_1 :>> leftFrontWheel; represents an } individual during some portion of its lifetime. then snapshot part vehicle_1_t1 { snapshot rightFrontWheel_t1 : Wheel_1 :>> rightFrontWheel; } } During a later snapshot, the same Wheel_1 has the role of the rightFrontWheel. Last changed: 2024-02 (revised call-outs) Release 2026-03 70 -Individuals and Time Slices A time slice represents individual item def Alice :> Person; an individual over individual item def Bob :> Person; some period of time During this time slice of (that this is a time slice Vehicle_1, the Alice has individual part : Vehicle_1 { of a part is implicit). the role of the driver. timeslice aliceDriving { ref individual item :>> driver : Alice; start and done are snapshot :>> start { snapshots at the :>> mass = 2000.0; beginning and end of } the time slice. snapshot :>> done { :>> mass = 1500.0; Succession asserts that During a later time slice } the first time slice must of Vehicle_1, Bob has the } complete before the role of the driver. second can begin. then timeslice bobDriving { ref individual item :>> driver : Bob; } } Last changed: 2021-05 (occurrence modeling) Release 2026-03 71 -Expressions and Feature Values ISQ::mass is a standard quantity package MassRollup1 { kind from the International System private import ScalarFunctions::*; of Quantities library model. part def MassedThing { attribute simpleMass :> ISQ::mass; attribute totalMass :> ISQ::mass; A feature value is a shorthand for binding } a feature to the result of an expression (here simply the value of another part simpleThing : MassedThing { feature). attribute :>> totalMass = simpleMass; } part compositeThing : MassedThing { part subcomponents: MassedThing[*]; attribute :>> totalMass = simpleMass + sum(subcomponents.totalMass); } } An expression in general is a The dot notation can be used as an expression to read computation expressed using a typical the values of a feature. Here, the totalMass is mathematical operator notation. collected for each of the subcomponents. Last changed: 2024-07 (import visibility) Release 2026-03 72 -Car Mass Rollup Example (1) private import ScalarValues::*; private import MassRollup1::*; part def CarPart :> MassedThing { attribute serialNumber : String; } part car: CarPart :> compositeThing { attribute vin :>> serialNumber; part carParts : CarPart[*] :>> subcomponents; part engine :> simpleThing, carParts { … } part transmission :> simpleThing, carParts { … } } This is an expression for a quantity with a specific numeric value and // Example usage unit. Note that units are identified private import SI::kg; on the quantity value, not the type. part c :> car { attribute :>> simpleMass = 1000[kg]; part :>> engine { attribute :>> simpleMass = 100[kg]; } part attribute transmission { attribute :>> simpleMass = 50[kg]; } The totalMass of c can be computed } using the feature value expressions from simpleThing and compositeThing. // c.totalMass --> 1150.0[kg] Last changed: 2024-11 (import visibility) Release 2026-03 73 -Default Values package MassRollup2 { A default value is feature value that private import ScalarFunctions::*; applies unless explicitly overridden. part def MassedThing { attribute simpleMass :> ISQ::mass; attribute totalMass :> ISQ::mass default simpleMass; } A default value can be overridden when the feature is redefined, part compositeThing : MassedThing { with a default or bound value. part subcomponents: MassedThing[*]; attribute :>> totalMass default mass + sum(subcomponents.totalMass); } Once bound, the value of the feature is fixed as the result of the part filteredMassThing :> compositeThing { value expression. attribute minMass : ISQ::mass attribute :>> totalMass = sum(subcomponents.totalMass.?{in p:>ISQ::mass; p >= minMass)}); } A dot can be followed by a } select expression in order to filter a collection of values. Last changed: 2024-07 (import visibility) Release 2026-03 74 -Car Mass Rollup Example (2) The default of totalMass to private alarValues::*; simpleMass is inherited. private import MassRollup2::*; part def CarPart :> MassedThing { The default for totalMass is overridden attribute serialNumber : String; as specified in compositeThing. } part car: CarPart :> compositeThing { attribute vin :>> serialNumber; part carParts : CarPart[*] :>> subcomponents; part engine :> carParts { … } part transmission :> carParts { … } } The totalMass default is not // Example usage overridden for the nested carParts. private import SI::kg; part c :> car { attribute :>> simpleMass = 1000[kg]; part :>> engine { attribute :>> simpleMass = 100[kg]; } part attribute transmission { attribute :>> simpleMass = 50[kg]; } When computing the totalMass } of c, c.engine and c.transmission, the relevant defaults are used. // c.totalMass --> 1150.0[kg] Last changed: 2024-11 (import visibility) Release 2026-03 75 -Calculation Definitions A calculation definition is a reusable, parameterized expression. Similarly to actions, the directed features calc def Power { in whlpwr : PowerValue; of a calculation are its parameters. in Cd : Real; in Cf : Real; A calculation has a in tm : MassValue; single return result. in v : SpeedValue; return : PowerValue; The calculation can include the attribute drag = Cd * v; computation of intermediate values. attribute friction = Cf * tm * v; ! There is no semicolon whlpwr - drag - friction at the end of a result The calculation result expression must } expression. conform to the return type. calc def Acceleration { in tp: PowerValue; in tm : MassValue; in v: SpeedValue; return : AccelerationValue = tp / (tm * v); The result expression can also be bound } directly to the return parameter. calc def Velocity { in dt : TimeValue; in v0 : SpeedValue; in a : AccelValue; return : SpeedValue = v0 + a * dt; } calc def Position (dt : TimeValue; x0 : LengthValue; v : SpeedValue; return : LengthValue = x0 + v * dt; } Last changed: 2022-07 (parameter declaration) Release 2026-03 76 -Calculation Usages (1) part def VehicleDynamics { attribute C_d : Real; attribute C_f : Real; attribute wheelPower : PowerValue; attribute mass : MassValue; action straightLineDynamics { in delta_t : TimeValue; Values are bound to the in v_in : SpeedValue; in x_in : LengthValue; parameters of calculation usages (similar to action parameters). calc acc : Acceleration { in tp = Power(wheelPower, C_d, C_f, mass, v_in); in tm = mass; in v = v_in; A calculation definition can also be return a; invoked as an expression, with input } values given as arguments, evaluating calc vel : Velocity { in dt = delta_t; to the result of the calculation. in v0 = v_in; in a = acc.a; return v; } calc pos : Position { Calculation results can be in dt = delta_t; referenced by name (they are in x0 = x_in; output parameters). in v = vel.v; return x; } out v_out : SpeedValue = vel.v; out x_out : LengthValue = pos.x; } } Last changed: 2023-10 (output binding) Release 2026-03 77 -Calculation Usages (2) attribute def DynamicState { attribute v: SpeedValue; attribute x: LengthValue; } part def VehicleDynamics { attribute C_d : Real; attribute C_f : Real; attribute wheelPower : PowerValue; attribute mass : MassValue; A calculation can be specified without an explicit Calculations can also calculation definition. handle structured values. calc updateState { in delta_t : TimeValue; in currState : DynamicState; This is a declaration of the result attribute totalPower : PowerValue = parameter of the calculation, with Power(wheelPower, C_d, C_f, mass, currState.v); bound subattributes. return attribute newState : DynamicState { :>> v = Velocity(delta_t, currState.v, Acceleration(totalPower, mass, currState.v)); :>> x = Position(delta_t, currState.x, currState.v); } } } Last changed: 2022-07 (parameter declaration) Release 2026-03 78 -Constraint Definitions (1) A constraint definition is a reusable, private import ISQ::*; parameterized Boolean expression. private import SI::*; private import ScalarFunctions::*; Constraint parameters are always constraint def MassConstraint { in parameters. in partMasses : MassValue[0..*]; in massLimit : MassValue; ! There is no semicolon at the end of a The constraint expression can be sum(partMasses) <= massLimit constraint expression. any Boolean expression using } the constraint parameters. part def Vehicle { constraint massConstraint : MassConstraint { in partMasses = (chassisMass, engine.mass, transmission.mass); in massLimit = 2500[kg]; } A constraint is the usage Values are bound to of a constraint definition, attribute chassisMass : MassValue; constraint parameters which may be true or (similarly to actions). false in a given context. part engine : Engine { attribute mass : MassValue; }  A constraint may be violated (false) without part transmission : Transmission { attribute mass : MassValue; making the model } inconsistent. } Last changed: 2024-07 (import visibility) Release 2026-03 79 -Constraint Definitions (2) private import ISQ::*; private import SI::*; private import ScalarFunctions::*; Alternatively, constraint constraint def MassConstraint { parameters may be modeled as attribute partMasses : MassValue[0..*]; attribute or reference features. attribute massLimit : MassValue; sum(partMasses) <= massLimit } part def Vehicle { constraint massConstraint : MassConstraint { redefines partMasses = (chassisMass, engine.mass, transmission.mass); redefines massLimit = 2500[kg]; } The constraint parameter attribute chassisMass : MassValue; properties are then redefined in order to be bound. part engine : Engine { attribute mass : MassValue; } part transmission : Engine { attribute mass : MassValue; } } Last changed: 2024-07 (import visibility) Release 2026-03 80 -Constraint Assertions (1) private import ISQ::*; private import SI::*; private import ScalarFunctions::*; constraint def MassConstraint { in partMasses : MassValue[0..*]; in massLimit : MassValue; sum(partMasses) <= massLimit } part def Vehicle { assert constraint massConstraint : MassConstraint { in partMasses = (chassisMass, engine.mass, transmission.mass); in massLimit = 2500[kg]; } A constraint assertion asserts that a constraint attribute chassisMass : MassValue; must be true. part engine : Engine { attribute mass : MassValue; }  If an assertion is violated, then the part transmission : Engine { attribute mass : MassValue; model is inconsistent. } } Last changed: 2024-07 (import visibility) Release 2026-03 81 -Constraint Assertions (2) The constraint expression constraint def MassConstraint { in partMasses : MassValue[0..*]; can also be defined on a in massLimit : MassValue; usage of a constraint def. } constraint massConstraint : MassConstraint { sum(partMasses) <= massLimit A named constraint } can be asserted in part def Vehicle { multiple contexts. assert massConstraint { in partMasses = (chassisMass, engine.mass, transmission.mass); in massLimit = 2500[kg]; } attribute chassisMass : MassValue; attribute engine : Engine { value mass : MassValue; } attribute transmission : Engine { value mass : MassValue; } } Last changed: 2023-12 (updated constraint def and usage) Release 2026-03 82 -Derivation Constraints In UML and SysML v1, constraints are often used to define derived values. part vehicle1 : Vehicle { attribute totalMass : MassValue; assert constraint {totalMass == chassisMass + engine.mass + transmission.mass} } part vehicle2 : Vehicle { attribute totalMass : MassValue = chassisMass + engine.mass + transmission.mass; } In SysML v2 this can usually be constraint def AveragedDynamics { done more directly using a binding. in mass: MassValue; in initialSpeed : SpeedValue; in finalSpeed : SpeedValue; ! Be careful about the in deltaT : TimeValue; in force : ForceValue; difference between ==, which is the Boolean-valued equality operator, and =, force * deltaT == mass * (finalSpeed - initialSpeed) and which denotes binding. mass > 0[kg] } However, constraints allow for more general equalities and inequalities than direct derivation. Last changed: 2022-07 (parameter declaration) Release 2026-03 83 -Analytical Constraints This constraint definition provides a reusable constraint def StraightLineDynamicsEquations { specification of a system in p : PowerValue, in m : MassValue, in dt : TimeValue; in x_i : LengthValue; in v_i : SpeedValue; of (coupled) equations. in x_f : LengthValue; in v_f : SpeedValue, in a : AccelerationValue; attribute v_avg : SpeedValue = (v_i + v_f)/2;  Note the use of the An action definition is inherently a == Acceleration(p, m, v_avg) and v_f == Velocity(dt, v_i, a) and calculation definitions "causal" in the sense that outputs x_f == Position(dt, x_i, v_avg) defined earlier. are determined in terms of inputs. } action def StraightLineDynamics { in power : PowerValue; in mass : MassValue; in delta_t : TimeValue; in x_in : LengthValue; in v_in : SpeedValue; A constraint is inherently out x_out : LengthValue; out v_out : SpeedValue; "acausal" – it is simply true out a_out : AccelerationValue; or false for given values of assert constraint dynamics : StraightLineDynamicsEquations { its parameters. in p = power; in m = mass; in dt = delta_t; in x_i = x_in; in v_i = v_in;  This specifies that the action outputs in x_f = x_out; in v_f = v_out; in a = a_out; must be solved for analytically given } the action inputs, consistent with } the asserted constraint. Last changed: 2022-07 (parameter declaration) Release 2026-03 84 -Time Constraints  TimeOf and DurationOf are from the Time package in the Quantities state healthStates { and Units Domain Library. in vehicle : Vehicle; entry; then normal; TimeOf returns the time of the state normal; start of an occurrence (in this accept at vehicle.maintenanceTime example, a state performance). then maintenance; state maintenance { assert constraint { TimeOf(maintenance) > vehicle.maintenanceTime } assert constraint { TimeOf(maintenance) - TimeOf(normal.done) < 2 [s] } entry assign vehicle.maintenanceTime := vehicle.maintenanceTime + vehicle.maintenanceInterval; } accept MaintenanceDone then normal; constraint { DurationOf(maintenance) <= 48 [h] } } DurationOf returns the time duration of an occurrence (the different between its start and done times). Last changed: 2022-01 (new) Release 2026-03 85 -Requirement Definitions (1) A textual statement of the requirement can be given as a documentation comment in A requirement definition is a special the requirement definition body. kind of constraint definition. requirement def MassLimitationRequirement { doc /* The actual mass shall be less than or equal * to the required mass. */ attribute massActual : MassValue; attribute massReqd : MassValue; Like a constraint definition, a requirement definition require constraint { massActual <= massReqd } can be parameterized } using features. The requirement can be formalized by giving one or more component required constraints. Last changed: 2020-08 Release 2026-03 86 -Requirement Definitions (2) part def Vehicle { attribute dryMass: MassValue; attribute fuelMass: MassValue; A requirement definition may have  Actually, any identifiable attribute fuelFullMass: MassValue; a modeler specified short name, element can have a short … which is an alternate name for it. name, not just requirements. } requirement def <'1’> VehicleMassLimitationRequirement :> MassLimitationRequirement { doc /* The total mass of a vehicle shall be less than or equal to the required mass. */ A requirement definition is always about some subject vehicle : Vehicle; subject, which may be implicit or specified explicitly. attribute redefines massActual = vehicle.dryMass + vehicle.fuelMass; assume constraint { vehicle.fuelMass > 0[kg] } } Features of the subject can be used in the A requirement definition may also requirement definition. specify one or more assumptions. Last changed: 2023-10 ("human id" to "short name") Release 2026-03 87 -Requirement Definitions (3) The subject of a requirement definition can have any kind of definition. port def ClutchPort; action def GenerateTorque; requirement def <'2’> DrivePowerInterfaceRequirement { doc /* The engine shall transfer its generated torque to the transmission * via the clutch interface. */ subject clutchPort: ClutchPort; } requirement def <'3’> TorqueGenerationRequirement { doc /* The engine shall generate torque as a function of RPM as shown in Table 1. */ subject generateTorque: GenerateTorque; } Last changed: 2021-10 (requirement id) Release 2026-03 88 -Requirement Usages A requirement may optionally A requirement is the usage of a have its own short name. requirement definition. requirement <'1.1’> fullVehicleMassLimit : VehicleMassLimitationRequirement { subject vehicle : Vehicle; A requirement will often bind attribute :>> massReqd = 2000[kg]; requirement definition assume constraint { parameters to specific values. doc /* Fuel tank is full. */ vehicle.fuelMass == vehicle.fuelFullMass } } requirement <'1.2’> emptyVehicleMassLimit : VehicleMassLimitationRequirement { subject vehicle : Vehicle; attribute :>> massReqd = 1500[kg]; assume constraint { doc /* Fuel tank is empty. */ vehicle.fuelMass == 0[kg] } } Last changed: 2023-10 ("human id" to "short name") Release 2026-03 89 -Requirement Groups A requirement may also be used  Grouped requirements are treated as to group other requirements. required constraints of the group. requirement vehicleSpecification { doc /* Overall vehicle requirements group */ subject vehicle : Vehicle; By default, the subject of grouped require fullVehicleMassLimit; requirements is assumed to be the require emptyVehicleMassLimit; same as that of the group. } Requirements can be part def Engine { grouped by reference… port clutchPort: ClutchPort; perform action generateTorque: GenerateTorque; } The subject of a grouped requirement can also be requirement engineSpecification { bound explicitly. doc /* Engine power requirements group */ …or by composition. subject engine : Engine; requirement drivePowerInterface : DrivePowerInterfaceRequirement { subject clutchPort = engine.clutchPort; } requirement torqueGeneration : TorqueGenerationRequirement { subject generateTorque = engine.generateTorque; } } Last changed: 2021-04 (dot notation) Release 2026-03 90 -Requirement Satisfaction part vehicle_c1 : Vehicle { part engine_v1: Engine { … } A requirement satisfaction asserts … that a given requirement is satisfied } when its subject parameter is part 'Vehicle c1 Design Context' { bound to a specific thing. ref vehicle_design :> vehicle_c1; satisfy vehicleSpecification by vehicle_design; satisfy engineSpecification by vehicle_design.engine_v1; }  Formally, a requirement is satisfied for a subject if, when all its assumed constraints are true, then all its required constraints are true. Last changed: 2021-04 (dot notation) Release 2026-03 91 -Analysis Case Definitions (1) An analysis case definition defines the computation of the result of analyzing some subject, meeting an objective. The subject may be specified similarly to the subject of a requirement definition. analysis def FuelEconomyAnalysis { subject vehicle : Vehicle; The objective is a requirement on objective fuelEconomyAnalysisObjective { the result of the analysis case. doc /* * The objective of this analysis is to determine whether the * subject vehicle can satisfy the fuel economy requirement. */ assume constraint { vehicle.wheelDiameter == 33['in’] and The analysis objective is specified as a vehicle.driveTrainEfficiency == 0.4 requirement, allowing both assumed } and required constraints. require constraint { fuelEconomyResult > 30[mi / gallon] } The analysis result is declared as a return } result (as for a calculation definition). … return fuelEconomyResult : DistancePerVolumeValue = …; } Last changed: 2024-12 (return result) Release 2026-03 92 -Analysis Case Definitions (2) attribute def WayPoint { time : TimeValue; position : LengthValue; speed : SpeedValue; The steps of an analysis case } are actions that, together, analysis def FuelEconomyAnalysis { compute the analysis result. subject vehicle : Vehicle; objective fuelEconomyAnalysisObjective { … } in attribute scenario : WayPoint[*]; Additional parameters action solveForPower { can be specified in the out power: PowerValue[*]; out acceleration: AccelerationValue[*]; case body. The first step solves for the assert constraint { (1. .size(scenario)-1)->forAll {in i : Positive; engine power needed for a StraightLineDynamicsEquations ( given position/velocity scenario. power#(i), vehicle.mass, scenario.time#(i+1) – scenario.time#(i), scenario.position#(i), scenario.speed#(i), The second step computes the fuel scenario.position#(i+1), scenario.speed#(i+1), economy result, given the power acceleration#(i+1))) profile determined in the first step. } } then action solveForFuelEconomy { in power : PowerValue[*] = solveForPower.power; out fuelEconomy : DistancePerVolumeValue; … } return fuelEconomyResult : DistancePerVolumeValue; = solveForFuelEconomy.fuelEconomy; … } Last changed: 2024-12 (return result) Release 2026-03 93 -Analysis Case Usages part vehicleFuelEconomyAnalysisContext { requirement vehicleFuelEconomyRequirements{subject vehicle : Vehicle; … } attribute cityScenario : WayPoint[*] = { … }; attribute highwayScenario : WayPoint[*] = { … }; analysis cityAnalysis : FuelEconomyAnalysis { subject vehicle = vehicle_c1; The previously defined analysis is carried in scenario = cityScenario; out for a specific vehicle configuration } for two different scenarios. analysis highwayAnalysis : FuelEconomyAnalysis { subject vehicle = vehicle_c1; in scenario = highwayScenario; The subject and parameters are } automatically redefined, so redefinition does not need to be specified explicitly. part vehicle_c1 : Vehicle { … attribute :>> fuelEconomy_city = cityAnalysis.fuelEconomyResult; attribute :>> fuelEconomy_highway = highwayAnalysis.fuelEconomyResult; If the vehicle fuel economy is set to } the results of the analysis, then this satisfy vehicleFuelEconomyRequirements by vehicle_c1; configuration is asserted to satisfy the } desired fuel economy requirements. Last changed: 2022-05 (use of WayPoint) Release 2026-03 94 -Trade-off Study Analysis  A trade-off study is an analysis with the The TradeStudy analysis definition from the objective of selecting the optimum TradeStudies domain library model provides a general alternative from a given set based on framework for defining basic trade study analyses. an evaluation of each alternative. analysis engineTradeStudy : TradeStudies::TradeStudy { Bind the analysis subject to the set of subject : Engine = (engine4cyl, engine6cyl); objective : MaximizeObjective; study alternatives. Select either MaximizeObjective or MinimizeObjective. calc :>> evaluationFunction { in part anEngine :>> alternative : Engine; Redefine the evaluationFunction calc powerRollup: PowerRollup {in engine = anEngine; return power : ISQ::PowerValue; } calculation to provide an evaluation calc massRollup: MassRollup {in engine = anEngine; of each one of the alternatives. return mass : ISQ::MassValue; } calc efficiencyRollup: EfficiencyRollup {in engine = anEngine; return efficiency : Real; } calc costRollup: CostRollup {in engine = anEngine; return cost : Real; } return :>> result : Real = EngineEvaluation( powerRollup.power, massRollup.mass, efficiencyRollup.efficiency, costRollup.cost The result of the analysis will be the ); alternative with either the maximum } or minimum evaluated value. return part :>> selectedAlternative : Engine; } Last changed: 2022-07 (parameter declaration) Release 2026-03 95 -Verification Case Definitions (1) Parameterizing the requirement allows it to be checked against a measured requirement vehicleMassRequirement { subject vehicle : Vehicle; massActual, while asserting (below) that in massActual :> ISQ::mass; this must be equal to the vehicle.mass. doc /* The vehicle mass shall be less * than or equal to 2500 kg. */ require constraint { A verification case definition defines a massActual == vehicle.mass and process for verifying whether a subject massActual <= 2500[SI::kg] } satisfies one or more requirements. } verification def VehicleMassTest { private import VerificationCases::*; The subject may be specified similarly to the subject of a requirement or analysis case. subject testVehicle : Vehicle; objective vehicleMassVerificationObjective { verify vehicleMassRequirement; The requirements to be verified are declared in } the verification case objective. The subject of the verification case is automatically bound to return verdict : VerdictKind; the subject of the verified requirements. } A verification case always returns a  VerdictKind is an verdict of type VerdictKind. (The enumeration with Last changed: 2020-11 default name is verdict, but a different allowed values pass, fail, name can be used if desired.) inconclusive and error. Last changed: 2024-12 (massActual binding) Release 2026-03 96 -Verification Case Definitions (2) verification def VehicleMassTest { private import VerificationCases::*; The steps of a verification case subject testVehicle : Vehicle; objective vehicleMassVerificationObjective { are actions that, together, verify vehicleMassRequirement; determine the verdict. } action collectData { in part testVehicle : Vehicle = VehicleMassTest::testVehicle; out massMeasured :> ISQ::mass; } action processData { in massMeasured :> ISQ::mass = collectData.massMeasured; PassIf is a utility function that out massProcessed :> ISQ::mass; returns a pass or fail verdict } depending on whether its action evaluateData { in massProcessed :> ISQ::mass = processData.massProcessed; argument is true or false. out verdict : VerdictKind = PassIf(vehicleMassRequirement( vehicle = testVehicle,  The use of named This is a check of whether the massActual = massProcessed)); argument notation requirement is satisfied for } here is optional. the given parameter values. return verdict : VerdictKind = evaluateData.verdict; } Last changed: 2024-12 (import visibility) Release 2026-03 97 -Verification Case Usages (1) This is a verification case usage in which the subject has been restricted to a specific test configuration. part vehicleTestConfig : Vehicle { … } verification vehicleMassTest : VehicleMassTest { subject testVehicle :> vehicleTestConfig; A verification case can be } performed as an action by part massVerificationSystem : MassVerificationSystem { a verification system. perform vehicleMassTest; part scale : Scale { perform vehicleMassTest.collectData { Parts of the verification in part :>> testVehicle; system can perform steps in the overall verification bind measurement = testVehicle.mass; process. out :>> massMeasured = measurement; } In reality, this would be } some more involved } process to determine the measured mass. Last changed: 2022-05 (dot notation on perform) Release 2026-03 98 -Verification Case Usages (2) Individuals can be used to individual def TestSystem :> MassVerificationSystem; model the carrying out of individual def TestVehicle1 :> Vehicle; actual tests. individual def TestVehicle2 :> Vehicle; individual testSystem : TestSystem :> massVerificationSystem { timeslice test1 { perform action :>> vehicleMassTest { ! The keyword action is individual :>> testVehicle : TestVehicle1 { required here to permit :>> mass = 2500[SI::kg]; the local redefinition. } } The test on the individual } TestVehicle1 should pass. then timeslice test2 { perform action :>> vehicleMassTest { individual :>> testVehicle : TestVehicle2 { :>> mass = 3000[SI::kg]; } } The test on the individual } TestVehicle2 should fail. } Last changed: 2021-03 (units notation) Release 2026-03 99 -Use Case Definition A use case definition defines a required interaction between its subject and certain external actors . An actor is a parameter of the use case representing a role played use case def 'Provide Transportation’ { by entity external to the subject. subject vehicle : Vehicle; ! Actors are (referential) actor driver : Person; actor passengers : Person[0..4]; part usages and so must actor environment : Environment; The objective of the use case is have part definitions. objective { for the subject to provide a doc /* Transport driver and passengers from result of value to one or more * starting location to ending location. of the actors. */ } } use case def 'Enter Vehicle’ {  Actors may also be specified for subject vehicle : Vehicle; other kinds of cases and for actor driver : Person; requirements. actor passengers : Person[0..4]; } use case def 'Exit Vehicle’ { subject vehicle : Vehicle; actor driver : Person; actor passengers : Person[0..4]; } Last changed: 2021-08 (new) Release 2026-03 100 -Use Case Usage use case 'provide transportation' : 'Provide Transportation’ { subject vehicle; first start; The required behavior of then include use case 'enter vehicle' : 'Enter Vehicle’ { a use case can be subject vehicle; specified as for an action. actor :>> driver = 'provide transportation'::driver; actor :>> passengers = 'provide transportation'::passengers; } A use case can define then use case 'drive vehicle’ { sub-use cases within its subject vehicle; behavior. actor driver = 'provide transportation'::driver; actor environment = 'provide transportation'::environment; include 'add fuel'[0..*] { A subject must be declared ! subject vehicle; A use case can include the first, before any actors. It can actor :>> fueler = driver; performance of a use case only be omitted if there are no } defined elsewhere (similar actors or other parameters. } to performing an action). then include use case 'exit vehicle' : 'Exit Vehicle’ { subject vehicle; actor :>> driver = 'provide transportation'::driver; ! The traditional use case actor :>> passengers = 'provide transportation'::passengers; } “extend” relationship is The subject of a nested use case is implicitly then done; not supported yet. } bound to that of its containing use case, but use case 'add fuel’ { actors need to be explicitly bound. subject vehicle : Vehicle; A use case can also be actor fueler : Person; specified without an actor 'fuel station' : 'Fuel Station’; explicit use case definition. } Last changed: 2025-07 (added subjects) Release 2026-03 101 -Variation Definitions attribute def Diameter :> Real; part def Cylinder { attribute diameter : Diameter[1]; } part def Engine { part cylinder : Cylinder[2..*]; } part '4cylEngine' : Engine { A variation definition will typically part redefines cylinder[4]; Any kind of definition can be specialize a definition from a design } marked as a variation, model, representing the type of thing part '6cylEngine' : Engine { expressing variability within a being varied. The variants must then part redefines cylinder[6]; product line model. } be valid usages of this type. // Variability model variation attribute def DiameterChoices :> Diameter { variant attribute diameterSmall = 70[mm]; variant attribute diameterLarge = 100[mm]; } A variation defines one or variation part def EngineChoices :> Engine { more variant usages, which variant '4cylEngine'; represent the allowed variant '6cylEngine'; Variants can also be declared by choices for that variation. } reference to usages defined elsewhere. Last changed: 2021-03 (units notation) Release 2026-03 102 -Variation Usages A variation definition can be used like any other definition, but valid values of the usage are restricted to the allowed variants of the variation. Any kind of usage can also be a variation, defining abstract part vehicleFamily : Vehicle { allowable variants without a part engine : EngineChoices[1]; separate variation definition. variation part transmission : Transmission[1] { variant manualTransmission; variant automaticTransmission; } assert constraint { (engine == engine::'4cylEngine’ and transmission == transmission::manualTransmission) xor A constraint can be used to (engine == engine::'6cylEngine’ and model restrictions across the transmission == transmission::automaticTransmission) } choices that can be made.  The operator xor means "exclusive or". So, this constraint } means "choose either a 4cylEngine and a manualTransmission, or a 6cylEngine and an automaticTransmission". Last changed: 2021-05 (logical operators) Release 2026-03 103 -Variation Configuration An element from a variability model with variation usages can be configured A selection is made for a variation by specializing it and making selections by binding one of the allowed for each of the variations. variants to the variation usage. part vehicle4Cyl :> vehicleFamily { part redefines engine = engine::'4cylEngine'; part redefines transmission = transmission::manualTransmission; } part vehicle6Cyl :> vehicleFamily { part redefines engine = engine::'6cylEngine'; part redefines transmission = transmission::manualTransmission; } Choosing a manualTransmission with a 6cylEngine is not allowed by the constraint asserted on vehicleFamily, so this model of vehicle6Cyl is invalid. Last changed: 2020-06 Release 2026-03 104 -Dependencies package 'Dependency Example' { part 'System Assembly' {  A dependency is a relationship that indicates that part 'Computer Subsystem' { one or more client elements require one more … supplier elements for their complete specification. } A dependency is entirely a model-level part 'Storage Subsystem' { relationship, without instance-level semantics. … } } package 'Software Design' { item def MessageSchema { … A dependency can be between any kinds of elements, } generally meaning that a change to a supplier may item def DataSchema { necessitate a change to the client element. … } } dependency from 'System Assembly'::'Computer Subsystem' to 'Software Design'; dependency Schemata from 'System Assembly'::'Storage Subsystem' to 'Software Design'::MessageSchema, 'Software Design'::DataSchema; } A dependency can have multiple clients and/or suppliers. Last changed: 2020-08 Release 2026-03 105 -Allocation package LogicalModel { … part torqueGenerator : TorqueGenerator { perform generateTorque; } } package PhysicalModel {  Allocations define traceable links private import LogicalModel::*; across the various structures and … An allocation specifies that hierarchies of a system model, part powerTrain : PowerTrain { some or all of the responsibility perhaps as a precursor to more part engine : Engine { for realizing the intent of the perform generateTorque; rigorous specifications and source is allocated to the target. } implementations. } allocate torqueGenerator to powerTrain { allocate torqueGenerator.generateTorque to powerTrain.engine.generateTorque; } } An allocation can be refined using nested allocations that give a finer- grained decomposition of the containing allocation mapping. Last changed: 2024-07 (import visibility) Release 2026-03 106 -Allocation Definition package LogicalModel { … part def LogicalElement; ! Unlike SysML v1, an part def TorqueGenerator :> LogicalElement; allocation in SysML v2 is not a dependency but, rather, an part torqueGenerator : TorqueGenerator { … } instantiable connection } across model features. package PhysicalModel { private import LogicalModel::*; … part def PhysicalElement; part def PowerTrain :> PhysicalElement; An allocation definition defines a class of allocations between part powerTrain : PowerTrain { … } features of specific types. } allocation def LogicalToPhysical { end logical : LogicalElement; end physical : PhysicalElement; An allocation usage must } allocate features that conform allocation torqueGenAlloc : LogicalToPhysical to the types of the ends of its allocate torqueGenerator to powerTrain { … } allocation definition. } Last changed: 2024-07 (import visibility) Release 2026-03 107 -Metadata (1) part vehicle { part interior {  The KerML and SysML library  Metadata is additional data part alarm; models include all the that can be used to annotate part seatBelt[2]; metaclasses from the KerML part frontSeat[2]; the elements of a model. and SysML abstract syntax. part driverAirBag; } part bodyAssy { part body; To restrict what kind of element part bumper; can be annotated, subset the part keylessEntry; Metadata is defined using a annotatedElement feature with } metadata definition . the desired element type(s). } metadata def SafetyFeature; metadata def SecurityFeature { :> annotatedElement : SysML::PartDefinition; :> annotatedElement : SysML::PartUsage; } metadata SafetyFeature about vehicle::interior::seatBelt,  At its simplest, a metadata vehicle::interior::driverAirBag, annotation can be used to vehicle::bodyAssy::bumper; simply "tag" certain A specific type of metadata can elements, so that they can, then be applied as an annotation metadata SecurityFeature about vehicle::interior::alarm, e.g., be grouped by tooling. to one or more model elements. vehicle::bodyAssy::keylessEntry; Last changed: 2022-03 (metadata definition, annotatedElement) Release 2026-03 108 -Metadata (2) standard library package AnalysisTooling { private import ScalarValues::*; metadata def ToolExecution {  The AnalysisTooling attribute toolName : String; package is part of the attribute uri : String; } Analysis domain library. metadata def ToolVariable { attribute name : String; } } If the metadata definition has nested features, these must be bound to action computeDynamics { values in the metadata annotation. private import AnalysisTooling::*; metadata ToolExecution { toolName = "ModelCenter"; The @ symbol is equivalent uri = "aserv://localhost/Vehicle/Equation1"; to the metadata keyword. } A metadata annotation contained in the body of in dt : ISQ::TimeValue {@ToolVariable {name = "deltaT";}} in a : ISQ:: AccelerationValue {@ToolVariable {name = "mass";}} a namespace (package, in v_in : ISQ:: VelocityValue {@ToolVariable {name = "v0";}} definition or usage) is, in x_in : ISQ:: LengthValue {@ToolVariable {name = "x0";}} by default, about that namespace. out v_out : ISQ:: VelocityValue {@ToolVariable {name = "v";}} out x_out : ISQ:: LengthValue {@ToolVariable {name = "x";}} } Last changed: 2024-07 (import visibility) Release 2026-03 109 -Element Import Filtering (1) metadata def Safety { A recursive import (using **) attribute isMandatory : Boolean; imports members of a namespace } and, recursively, members of any ! Currently, a metadata annotation must nested namespaces. part vehicle { be owned by the annotated element to part interior { be accessed in a filter condition. part alarm; part seatBelt[2] { package 'Safety Features' { @Safety{isMandatory = true;}} public import vehicle::**; part frontSeat[2]; filter @Safety; part driverAirBag { } @Safety{isMandatory = false;}} } package 'Mandatory Safety Features' { part bodyAssy { public import vehicle::**; part body; filter @Safety and (as Safety).isMandatory; part bumper { } @Safety{isMandatory = true;}} part keylessEntry; } part wheelAssy { A filter is a Boolean @ checks life an element part wheel[2]; condition that must be true has the given metadata part antilockBrakes[2] { @Safety{isMandatory = false;}} for an element to actually and as ”casts” to that } be imported into a package. metadata type. } Last changed: 2026-03 (filter expression) Release 2026-03 110 -Element Import Filtering (2)  The filter keyword is only allowed in a package (or view), but a filtered import can metadata def Safety { be used anyplace an import is allowed. attribute isMandatory : Boolean; } Filter conditions can also be part vehicle { combined with the import itself. part interior { part alarm; part seatBelt[2] { package 'Safety Features' { @Safety{isMandatory = true;}} public import vehicle::**[@Safety]; part frontSeat[2]; } part driverAirBag { @Safety{isMandatory = false;}} package 'Mandatory Safety Features' { } public import vehicle::** part bodyAssy { [@Safety and (as Safety).isMandatory]; part body; } part bumper { @Safety{isMandatory = true;}} part keylessEntry; } ! A filter condition expression must be model- part wheelAssy { level evaluable. It can reference only literals part wheel[2]; part antilockBrakes[2] { and metadata annotations and attributes, @Safety{isMandatory = false;}} connected using basic arithmetic, } comparison and Boolean operators. } Last changed: 2026-03 (filter expression) Release 2026-03 111 -Language Extension (1) For a domain-specific extension to SysML, first create a library model of domain-specific concepts. library package FailureModeling { This can be explicitly identified as a library package. abstract occurrence def Situation; abstract occurrence situations : Situation[*] nonunique; abstract occurrence def Cause { attribute probability : Real; } abstract occurrence causes : Cause[*] nonunique :> situations; For each concept, provide a base abstract occurrence def Failure { definition and a base usage attribute severity : Level; modeling the concept semantics. } abstract occurrence failures : Failure[*] nonunique :> situations; abstract connection def Causation :> Occurrences::HappensBefore { end cause : Situation[*]; end effect : Situation[*]; } abstract connection causations : Causation[*] nonunique; HappensBefore is the base type for successions, from the Kernel item def Scenario { Library Occurrences package. occurrence :>> situations; occurrence :>> causes :> situations; occurrence :>> failures :> situations; } item scenarios : Scenario[*] nonunique; } Last changed: 2022-09 (library package) Release 2026-03 112 -Language Extension (2) library package FailureModelingMetadata { private import FailureModeling::*; Declare semantic metadata for private import Metaobjects::SemanticMetadata; each concept to be included in the language extension. metadata def situation :> SemanticMetadata { :>> baseType = situations meta SysML::Usage; } metadata def cause :> SemanticMetadata { Bind baseType to the base usage :>> baseType = causes meta SysML::Usage; for the relevant concept. } metadata def failure :> SemanticMetadata { :>> baseType = failures meta SysML::Usage; } The meta-cast "meta SysML::Usage" allows failures to metadata def causation :> SemanticMetadata { be referenced as a usage, rather :>> baseType = causations meta SysML::Usage; than evaluated as an expression. } metadata def scenario :> SemanticMetadata { :>> baseType = scenarios meta SysML::Usage; } } Last changed: 2024-07 (import visibility) Release 2026-03 113 -Language Extension (3) private import FailureModelingMetadata::*; #scenario def DeviceFailure { ref device : Device; Implicitly specializes the attribute minPower : Real; library definition Scenario A user-defined keyword, starting (the definition of the #cause 'battery old' { with # and referencing a semantic scenarios base type). :>> probability = 0.01; metadata definition, can be used } to declare a definition or usage. #causation connect 'battery old’ to 'power low'; #situation 'power low' { Implicitly specializes the constraint { device.battery.power < minPower } library usage situations } (as given in the semantic metadata situation). #causation connect 'power low’ to 'device shutoff'; #failure 'device shutoff' { Inheritance and :>> severity = LevelEnum::high; redefinition work as for } explicit specialization. } Last changed: 2025-07 (changed successions to connections) Release 2026-03 114 -Stakeholders and Concerns part def 'Systems Engineer'; A concern is a specific topic that one or more part def 'IV&V’; stakeholders desire to be addressed. concern 'system breakdown' { doc /* * To ensure that a system covers all its required capabilities, * it is necessary to understand how it is broken down into * subsystems and components that provide those capabilities. */ A subject must be declared first, before any ! subject system; stakeholders. It can only be omitted if there stakeholder se: 'systems engineer'; are no stakeholders or other parameters. stakeholder ivv: 'IV&V'; } A stakeholder is a person, organization or concern modularity { other entity with concerns to be addressed. doc /* * There should be well defined interfaces between the parts of * a system that allow each part to be understood individually, * as well as being part of the whole system. */ subject system;  Stakeholders may be specified for any stakeholder 'systems engineer'; kind of requirement, not just concerns. } Last changed: 2025-07 (added subjects) Release 2026-03 115 -Viewpoints A viewpoint is a requirement to present information from a model in a view that addresses certain stakeholder concerns. viewpoint 'system structure perspective' { frame 'system breakdown'; frame modularity; A viewpoint frames the concerns that will be addressed by a view that satisfies the viewpoint. require constraint { doc /* * A system structure view shall show the hierarchical * part decomposition of a system, starting with a * specified root part. */ } }  Any requirement may be modeled as framing relevant stakeholder concerns, not just viewpoints. Last changed: 2021-05 (new) Release 2026-03 116 -Views (1) A view definition specifies how information can be extracted from a model in order to satisfy one or more viewpoints. A view definition can view def 'Part Structure View' { filter the elements to satisfy 'system structure perspective’; be included in the views it specifies. filter @SysML::PartUsage; The SysML library package models } the SysML abstract syntax, which can be used to filter on specific view 'vehicle structure view' : kinds of model elements. 'Part Structure View' { A view usage specifies a A view usage exposes the model elements expose vehicle::**; certain view conforming to be included in the view, which are to a view definition. filtered as specified in the view definition. render asTreeDiagram; } A view usage specifies how the view is  The view rendering can also be given to be rendered as a physical artifact. in the view definition, in which case it will be the same for all usages of that definition. But only view usages can expose elements to be viewed. Last changed: 2021-05 (new) Release 2026-03 117 -Views (2)  The Views library package includes four basic kinds of rendering: asTreeDiagram, Specialized kinds of renderings asInterconnectionDiagram, can be defined in a user model. asTextualNotation and asElementTable. rendering asTextualNotationTable :> asElementTable { view :>> columnView[1] { render asTextualNotation; ! A more comprehensive } rendering library model is } planned for future release. view 'vehicle tabular views’ { view 'safety features view' : 'Part Structure View’ { expose vehicle::**[@Safety]; Views can have render asElementTable; subviews. } view 'non-safety features view' : 'Part Structure View’ { expose vehicle::**[not (@Safety)]; render asElementTable; } Views can specify additional filtering } conditions on an expose, using the same notation as for an import. Last changed: 2021-09 (editorial correction) Release 2026-03 118 -Example View Rendering view ‘vehicle structure view’ { expose vehicle::**[@SysML::PartUsage]; render asTreeDiagram; } Last changed: 2021-05 (new) Release 2026-03 119 -Kernel Data Type Library 120 Release 2026-03 -Scalar Values standard library package ScalarValues { private import Base::*; abstract datatype ScalarValue specializes Value; datatype Boolean specializes ScalarValue; datatype String specializes ScalarValue; abstract datatype NumericalValue specializes ScalarValue; abstract datatype Number specializes NumericalValue; datatype Complex specializes Number; datatype Real specializes Complex; datatype Rational specializes Real; datatype Integer specializes Rational; datatype Natural specializes Integer; datatype Positive specializes Natural; } Last changed: 2022-09 (standard library package) Release 2026-03 121 -Collections (1) standard library package Collections { … abstract datatype Collection { feature elements[0..*] nonunique; } abstract datatype OrderedCollection :> Collection { feature :>> elements[0..*] ordered nonunique; } abstract datatype UniqueCollection :> Collection { feature :>> elements[0..*]; } datatype Array :> OrderedCollection { feature dimensions: Positive[0..*] ordered nonunique; feature rank: Natural[1] = size(dimensions); feature flattenedSize: Positive[1] = dimensions->reduce '*' ?? 1; inv { flattenedSize == size(elements) } } datatype Bag :> Collection; datatype Set :> UniqueCollection; datatype OrderedSet :> OrderedCollection, UniqueCollection { feature :>> elements[0..*] ordered; } datatype List :> OrderedCollection; … } Last changed: 2022-09 (standard library package) Release 2026-03 122 -Collections (2) standard library package Collections { … datatype KeyValuePair { feature key: Anything[0..*] ordered nonunique; feature val: Anything[0..*] ordered nonunique; } datatype Map :> Collection { feature :>> elements: KeyValuePair[0..*]; } datatype OrderedMap :> Map { feature :>> elements: KeyValuePair[0..*] ordered; } } Last changed: 2022-09 (standard library package) Release 2026-03 123 -Vector Values standard library package VectorValues { private import ScalarValues::NumericalValue; private import ScalarValues::Real; private import Collections::Array; abstract datatype VectorValue; datatype NumericalVectorValue :> VectorValue, Array { feature dimension[0..1] :>> dimensions; feature :>> elements : NumericalValue; } datatype CartesianVectorValue :> NumericalVectorValue { feature :>> elements : Real; } datatype ThreeVectorValue :> NumericalVectorValue { feature :>> dimension = 3; } datatype CartesianThreeVectorValue :> CartesianVectorValue, ThreeVectorValue; } Last changed: 2022-09 (standard library package) Release 2026-03 124 -Kernel Function Library (selected models) 125 Release 2026-03 -Base Functions standard library package BaseFunctions { private import Base::Anything; private import ScalarValues::*; abstract function '==' { in x: Anything[0..1]; in y: Anything[0..1]; return : Boolean[1]; } function '!=' { in x: Anything[0..1]; in y: Anything[0..1]; return : Boolean[1] = not (x == y) } abstract function '===' { in x: Anything[0..1]; in y: Anything[0..1]; return : Boolean[1]; } function '!==' { in x: Anything[0..1]; in y: Anything[0..1]; return : Boolean[1] = not (x === y) } function ToString { in Anything[0..1]; return : String[1]; } abstract function '['{ in x: Anything[0..*] nonunique; in y: Anything[0..*] nonunique; return : Anything[0..*] nonunique; } abstract function '#'{ in seq: Anything[0..*] ordered nonunique; in index: Positive[1..*] ordered nonunique; return : Anything[0..1]; } abstract function ','{ in seq1: Anything[0..*] ordered nonunique; seq2: Anything[0..*] ordered nonunique; return : Anything[0..*] ordered nonunique; } … } Last changed: 2023-02 (added '[', '#', ',') Release 2026-03 126 -Data Functions  ScalarFunctions package is similar standard library package DataFunctions { but specialized for ScalarValue. … abstract function '=='specializes BaseFunctions::'==' {in x: DataValue[0..1]; in y: DataValue[0..1]; return : Boolean[1];} function '==='specializes BaseFunctions::'===' {in x: DataValue[0..1]; in y: DataValue[0..1]; return : Boolean[1];} abstract function '+'{in x: DataValue[1]; in y: DataValue[0..1]; return : DataValue[1];} abstract function '-'{in x: DataValue[1]; in y: DataValue[0..1]; return : DataValue[1];} abstract function '*'{in x: DataValue[1]; in y: DataValue[1]; return : DataValue[1];} abstract function '/'{in x: DataValue[1]; in y: DataValue[1]; return : DataValue[1];} abstract function '**'{in x: DataValue[1]; in y: DataValue[1]; return : DataValue[1];} abstract function '^'{in x: DataValue[1]; in y: DataValue[1]; return : DataValue[1];} abstract function '%'{in x: DataValue[1]; in y: DataValue[1]; return : DataValue[1];} abstract function 'not'{in x: DataValue[1]; return : DataValue[1];} abstract function 'xor'{in x: DataValue[1]; in y: DataValue[1]; return : DataValue[1];} abstract function '~'{in x: DataValue[1]; return : DataValue[1];} abstract function '|'{in x: DataValue[1]; in y: DataValue[1]; return : DataValue[1];} abstract function '&'{in x: DataValue[1]; in y: DataValue[1]; return : DataValue[1];} abstract function '<'{in x: DataValue[1]; in y: DataValue[1]; return : Boolean[1];} abstract function '>'{in x: DataValue[1]; in y: DataValue[1]; return : Boolean[1];} abstract function '<='{in x: DataValue[1]; in y: DataValue[1]; return : Boolean[1];} abstract function '>='{in x: DataValue[1]; in y: DataValue[1]; return : Boolean[1];} abstract function max{in x: DataValue[1]; return : DataValue[1];} abstract function min{in x: DataValue[1]; return : DataValue[1];} abstract function '..' {in lower:DataValue[1]; in upper:DataValue[1]; return : DataValue[0..*] ordered; } } Last changed: 2022-09 (standard library package, "===") Release 2026-03 127 -Boolean Functions standard library package BooleanFunctions { public import ScalarValues::*; function 'not' specializes ScalarFunctions::'not’ {in x: Boolean; return : Boolean;} function 'xor' specializes ScalarFunctions::’xor’ {in x: Boolean; in y: Boolean; return : Boolean;} function '|' specializes ScalarFunctions::'|’ {in x: Boolean; in y: Boolean; return : Boolean;} function '&' specializes ScalarFunctions::'&’ {in x: Boolean; in y: Boolean; return : Boolean;} function '==' specializes BaseFunctions::'==‘ {in x: Boolean; in y: Boolean; return : Boolean;} function ToString specializes BaseFunctions::ToString {in x: Boolean; return : String;} function ToBoolean(x: String): Boolean; {in x: String; return : Boolean;} } Last changed: 2024-07 (import visibility) Release 2026-03 128 -String Functions standard library package StringFunctions { public import ScalarValues::*; function '+' specializes ScalarFunctions::’+’ {in x: String; in y: String; return : String;} function Size {in x: String; return : Natural;} function Substring {in x: String; in lower: Integer; in upper: Integer; return : String;} function '<' specializes ScalarFunctions::'<‘ {in x: String; in y: String; return : Boolean;} function '>' specializes ScalarFunctions::’>’ {in x: String; in y: String; return : Boolean;} function '<=' specializes ScalarFunctions::'<=' {in x: String; in y: String; return : Boolean;} function '>=' specializes ScalarFunctions::'>=' {in x: String; in y: String; return : Boolean;} function '=' specializes BaseFunctions::'==' {in x: String; in y: String; return : Boolean;} function ToString specializes BaseFunctions::ToString {in x: String; return : String; } Last changed: 2024-07 (import visibility) Release 2026-03 129 -Numerical Functions standard library package NumericalFunctions { public import ScalarValues::*; function abs {in x: NumericalValue[1]; return : NumericalValue[1];} abstract function ‘+’ specializes ScalarFunctions::‘+’ {in x: NumericalValue[1]; in y: NumericalValue[0..1]; return : NumericalValue[1];} abstract function '-' specializes ScalarFunctions::‘-’ {in x: NumericalValue[1]; in y: NumericalValue[0..1]; return : NumericalValue[1];} abstract function '*' specializes ScalarFunctions::‘*’ {in x: NumericalValue[1]; in y: NumericalValue[1]; return : NumericalValue[1];} abstract function '/' specializes ScalarFunctions::‘/’ {in x: NumericalValue[1]; in y: NumericalValue[0..1]; return : NumericalValue[1];} abstract function '**' specializes ScalarFunctions::‘**’ {in x: NumericalValue[1]; in y: NumericalValue[0..1]; return : NumericalValue[1];} abstract function '^' specializes ScalarFunctions::‘^’ {in x: NumericalValue[1]; in y: NumericalValue[0..1]; return : NumericalValue[1];} abstract function '%' specializes ScalarFunctions::‘%’ {in x: NumericalValue[1]; in y: NumericalValue[0..1]; return : NumericalValue[1];} abstract function '<‘specializes ScalarFunctions::‘<’ {in x: NumericalValue[1]; in y: NumericalValue[0..1]; return : Boolean[1];} abstract function ‘>’ specializes ScalarFunctions::‘>’ {in x: NumericalValue[1]; in y: NumericalValue[0..1]; return : Boolean[1];} abstract function '<=' specializes ScalarFunctions::‘<=’ {in x: NumericalValue[1]; in y: NumericalValue[0..1]; return : Boolean[1];} abstract function '>=' specializes ScalarFunctions::‘>=’ {in x: NumericalValue[1]; in y: NumericalValue[0..1]; return : Boolean[1];} abstract function max specializes ScalarFunctions::max {in x: NumericalValue[1]; in y: NumericalValue[0..1]; return : NumericalValue[1];} abstract function min specializes ScalarFunctions::min {in x: NumericalValue[1]; in y: NumericalValue[0..1]; return : NumericalValue[1];} abstract function sum {in collection: NumericalValue[0..*] ordered; return : NumericalValue[1];} abstract function product {in collection: NumericalValue[0..*] ordered; return : NumericalValue[1];} } Last changed: 2024-07 (import visibility) Release 2026-03 130 -Complex Functions standard library package ComplexFunctions { public import ScalarValues::*; feature i: Complex[1] = rect(0.0, 1.0); function rect{in re: Real[1]; in im: Real[1]; return : Complex[1];} function polar{in abs: Real[1]; in arg: Real[1]; return : Complex[1];} function re{in x: Complex[1]; return : Real[1];} function im {in x: Complex[1]; return : Real[1];} function abs specializes NumericalFunctions::abs {in x: Complex[1]; return : Real[1];} function {in x: Complex[1]; return : Real[1];} function '+' specializes NumericalFunctions::'+’ {in x: Complex[1]; in y: Complex[0..1]; return : Complex[1]; function '-' specializes NumericalFunctions::'-' {in x: Complex[1]; in y: Complex[0..1]; return : Complex[1]; function '*' specializes NumericalFunctions::'*' {in x: Complex[1]; in y: Complex[1]; return : Complex[1]; function '/' specializes NumericalFunctions::'/' {in x: Complex[1]; in y: Complex[1]; return : Complex[1]; function '**' specializes NumericalFunctions::'**' {in x: Complex[1]; in y: Complex[1]; return : Complex[1]; function '^' specializes NumericalFunctions::'^' {in x: Complex[1]; in y: Complex[1]; return : Complex[1]; function '==' specializes DataFunctions::'==' {in x: Complex[1]; in y: Complex[1]; return : Complex[1]; function ToString specializes BaseFunctions::ToString {in x: Complex[1]; return : String[1];} function ToComplex {in x: String[1]; return : Complex[1];} function sum specializes NumericalFunctions::sum {in collection: Complex[0..*]; return : Complex[1];} function product specializes NumericalFunctions::product {in collection: Complex[0..*]; return : Complex[1];} } Last changed: 2024-07 (import visibility) Release 2026-03 131 -Real Functions standard library package RealFunctions { public import ScalarValues::*; function abs specializes ComplexFunctions::abs {in x: Real[1]; return : Real[1];} function '+' specializes ComplexFunctions::'+’ {in x: Real[1]; in y: Real[0..1]; return: Real[1];} function '-' specializes ComplexFunctions::'-' {in x: Real[1]; in y: Real[0..1]; return: Real[1];} function '*' specializes ComplexFunctions::'*' {in x: Real[1]; in y: Real[1]; return: Real[1];} function '/' specializes ComplexFunctions::'/' {in x: Real[1]; in y: Real[0..1]; return: Real[1];} function '**' specializes ComplexFunctions::'**' {in x: Real[1]; in y: Real[0..1]; return: Real[1];} function '^' specializes ComplexFunctions::'^' {in x: Real[1]; in y: Real[0..1]; return: Real[1];} function '<' specializes ComplexFunctions::'<' {in x: Real[1]; in y: Real[0..1]; return: Boolean[1];} function '>' specializes ComplexFunctions::'>' {in x: Real[1]; in y: Real[0..1]; return: Boolean[1];} function '<=' specializes ComplexFunctions::'<=' {in x: Real[1]; in y: Real[0..1]; return: Boolean[1];} function '>=' specializes ComplexFunctions::'>=' {in x: Real[1]; in y: Real[0..1]; return: Boolean[1];} function max specializes ComplexFunctions::max {in x: Real[1]; in y: Real[0..1]; return: Real[1];} function min specializes ComplexFunctions::min {in x: Real[1]; in y: Real[0..1]; return: Real[1];} function '==' specializes ComplexFunctions::'==‘ {in x: Real[1]; in y: Real[0..1]; return: Boolean[1];} function sqrt {in x: Real[1]; return : Real[1];} function floor {in x: Real[1]; return : Integer[1];} function round {in x: Real[1]; return : Integer[1];} function ToString specializes ComplexFunctions::ToString {in x: Real[1]; return : String[1];} function ToInteger {in x: Real[1]; return : Integer[1];} function ToRational {in x: Real[1]; return : Rational[1];} function ToReal {in x: String[1]; return : Real[1];} function ToComplex(x: Real[1]): Complex; function sum specializes ComplexFunctions::sum {in collection: Real[0..*]; return : Real[1];} function product specializes ComplexFunctions::product {in collection: Real[0..*]; return : Real[1];} } Last changed: 2024-07 (import visibility) Release 2026-03 132 -Rational Functions standard library package RationalFunctions { public import ScalarValues::*; function rat {in numer: Integer[1]; in denum: Integer[1]; return : Rational[1];} function numer{in rat: Rational[1]; return : Integer[1];} function denom {in rat: Rational[1]; return : Integer[1];} function abs specializes RealFunctions::abs {in x: Rational[1]; return : Rational[1];} function '+' specializes RealFunctions::’+’ {in x: Rational[1]; in y: Rational[0..1]; return : Rational[1];} function '-' specializes RealFunctions::'-' {in x: Rational[1]; in y: Rational[0..1]; return : Rational[1];} function '*' specializes RealFunctions::'*' {in x: Rational[1]; in y: Rational[1]; return : Rational[1];} function '/' specializes RealFunctions::'/' {in x: Rational[1]; in y: Rational[1]; return : Rational[1];} function '**' specializes RealFunctions::'**' {in x: Rational[1]; in y: Rational[1]; return : Rational[1];} function '^' specializes RealFunctions::'^' {in x: Rational[1]; in y: Rational[1]; return : Rational[1];} function '<' specializes RealFunctions::'<‘ {in x: Rational[1]; in y: Rational[1]; return : Boolean[1]; function '>' specializes RealFunctions::'>' {in x: Rational[1]; in y: Rational[1]; return : Boolean[1]; function '<=' specializes RealFunctions::'<=' {in x: Rational[1]; in y: Rational[1]; return : Boolean[1]; function '>=' specializes RealFunctions::'>=' {in x: Rational[1]; in y: Rational[1]; return : Boolean[1]; function max specializes RealFunctions::max {in x: Rational[1]; in y: Rational[1]; return : Boolean[1]; function min specializes RealFunctions::min {in x: Rational[1]; in y: Rational[1]; return : Boolean[1]; function '==' specializes RealFunctions::'==' {in x: Rational[1]; in y: Rational[1]; return : Boolean[1]; function gcd {in x: Rational[1]; in y: Rational[0..1]; return : Integer[1];} function floor {in x: Rational[1]; return : Integer[1];} function round {in x: Rational[1]; return : Integer[1];} function ToString specializes RealFunctions::ToString {in x: Rational[1]; return : String[1];} function ToInteger {in x: Rational[1]; return : Integer[1];} function ToRational {in x: String[1]; return : Rational[1];} function sum specializes RealFunctions::sum {in collection: Rational[0..*]; return : Rational[1];} function product specializes RealFunctions::product {in collection: Rational[0..*]; return : Rational[1];} } Last changed: 2024-07 (import visibility) Release 2026-03 133 -Integer Functions standard library package IntegerFunctions { public import ScalarValues::*; function abs specializes RationalFunctions::abs {in x: Integer[1]; return : Natural[1];} function '+' specializes RationalFunctions::'+' {in x: Integer[1]; in y: Integer[0..1]; return : Integer[1];} function '-' specializes RationalFunctions::'-' {in x: Integer[1]; in y: Integer[0..1]; return : Integer[1];} function '*' specializes RationalFunctions::'*' {in x: Integer[1]; in y: Integer[1]; return : Integer[1];} function '/' specializes RationalFunctions::'/' {in x: Integer[1]; in y: Integer[1]; return : Rational[1];} function '**' specializes RationalFunctions::'**' {in x: Integer[1]; in y: Natural[1]; return : Integer[1];} function '^' specializes RationalFunctions::'^' {in x: Integer[1]; in y: Natural[1]; return : Integer[1];} function '%' specializes NumericalFunctions::'%' {in x: Integer[1]; in y: Integer[1]; return : Integer[1];} function '<' specializes RationalFunctions::'<' {in x: Integer[1]; in y: Integer[1]; return : Boolean[1];} function '>' specializes RationalFunctions::'>' {in x: Integer[1]; in y: Integer[1]; return : Boolean[1];} function '<=' specializes RationalFunctions::'<=' {in x: Integer[1]; in y: Integer[1]; return : Boolean[1];} function '>=' specializes RationalFunctions::'>=' {in x: Integer[1]; in y: Integer[1]; return : Boolean[1];} function max specializes RationalFunctions::max {in x: Integer[1]; in y: Integer[1]; return : Integer[1];} function min specializes RationalFunctions::min {in x: Integer[1]; in y: Integer[1]; return : Integer[1];} function '==' specializes DataFunctions::'==' {in x: Integer[0..1]; in y: Integer[0..1]; return : Boolean[1];} function '..' specializes ScalarFunctions::'..’ {in lower: Integer[1]; in upper: Integer[1]; return : Integer[0..*];} function ToString specializes RationalFunctions::ToString {in x: Integer[1]; return : String[1];} function ToNatural {in x: Integer[1]; return : Natural[1];} function ToInteger {in x: String[1]; return : Integer[1];} function sum specializes RationalFunctions::sum {in collection: Integer[0..*]; return : Integer[1];} function product specializes RationalFunctions::product {in collection: Integer[0..*]; return : Integer[1];} } Last changed: 2024-07 (import visibility) Release 2026-03 134 -Natural Functions standard library package NaturalFunctions { public import ScalarValues::*; function '+' specializes IntegerFunctions::'+' {in x: Natural[1]; in y: Natural[0..1]; return : Natural[1];} function '*' specializes IntegerFunctions::'*' {in x: Natural[1]; in y: Natural[1]; return : Natural[1];} function '/' specializes IntegerFunctions::'/' {in x: Natural[1]; in y: Natural[1]; return : Natural[1];} function '%' specializes IntegerFunctions::'%' {in x: Natural[1]; in y: Natural[1]; return : Natural[1];} function '<' specializes IntegerFunctions::'<' {in x: Natural[1]; in y: Natural[1]; return : Boolean[1];} function '>' specializes IntegerFunctions::'>' {in x: Natural[1]; in y: Natural[1]; return : Boolean[1];} function '<=' specializes IntegerFunctions::'<=' {in x: Natural[1]; in y: Natural[1]; return : Boolean[1];} function '>=' specializes IntegerFunctions::'>=' {in x: Natural[1]; in y: Natural[1]; return : Boolean[1];} function max specializes IntegerFunctions::max {in x: Natural[1]; in y: Natural[1]; return : Natural[1];} function min specializes IntegerFunctions::min { n x: Natural[1]; in y: Natural[1]; return : Natural[1];} function '==' specializes IntegerFunctions::'==‘ {in x: Natural[0..1]; in y: Natural[0..1]; return : Boolean[1];} function ToString specializes IntegerFunctions::ToString {in x: Natural[1]; return : String[1];} function ToNatural{in x: String[1]; return : Natural[1];} } Last changed: 2024-07 (import visibility) Release 2026-03 135 -Trigonometric Functions standard library package TrigFunctions { public import ScalarValues::Real; feature pi : Real; inv piPrecision { RealFunctions::round(pi * 1E20) == 314159265358979323846.0 } function deg {in theta_rad : Real[1];return : Real[1];} function rad {in theta_deg : Real; return : Real[1];} datatype UnitBoundedReal :> Real { inv unitBound { -1.0 <= that & that <= 1.0 } } function sin {in theta : Real[1]; return : UnitBoundedReal[1];} function cos {in theta : Real[1]; return : UnitBoundedReal[1];} function tan {in theta : Real[1]; return : Real;} function cot {in theta : Real; return : Real;} function arcsin {in x : UnitBoundedReal[1]; return : Real[1];} function arccos {in x : UnitBoundedReal[1]; return : Real[1];} function arctan {in x : Real[1]; return : Real[1];} } Last changed: 2024-07 (import visibility) Release 2026-03 136 -Sequence Functions (1) standard library package SequenceFunctions { … function equals {in x: Anything[0..*] ordered nonunique; in y: Anything[0..*] ordered nonunique; return : Boolean[1]; } function same {in x: Anything[0..*] ordered nonunique; in y: Anything[0..*] ordered nonunique; return : Boolean[1]; } function size {in seq: Anything[0..*] ordered nonunique; return : Natural[1];} function isEmpty {in seq: Anything[0..*] ordered nonunique; return : Boolean[1];} function notEmpty {in seq: Anything[0..*] ordered nonunique; return : Boolean[1];} function includes {in seq1: Anything[0..*] ordered nonunique; in seq2: Anything[0..*] nonunique; return : Boolean[1]; } function excludes {in seq1: Anything[0..*] ordered nonunique; in seq2: Anything[0..*] nonunique; return : Boolean[1]; } function including {in seq: Anything[0..*] ordered nonunique; in values: Anything[0..*] ordered nonunique; return : Anything[0..*] ordered nonunique; } function includingAt{in seq: Anything[0..*] ordered nonunique; in values: Anything[0..*] ordered nonunique; in index: Positive[1]; return : Anything[0..*] ordered nonunique; } function excluding {in seq: Anything[0..*] ordered nonunique; in values: Anything[0..*] ordered nonunique; return : Anything[0..*] ordered nonunique; } function excludingAt{in seq: Anything[0..*] ordered nonunique; in values: Anything[0..*] ordered nonunique; in index: Positive[1]; return : Anything[0..*] ordered nonunique; } … Last changed: 2022-09 (standard library package, additional functions) Release 2026-03 137 -Sequence Functions (2) standard library package SequenceFunctions { … function head {in seq: Anything[0..*] ordered nonunique; return : Anything[0..1]; } function tail {in seq: Anything[0..*] ordered nonunique ; return : Anything[0..*] ordered nonunique; } function last {in seq: Anything[0..*] ; return : Anything[0..1]; } function '#' specializes BaseFunctions::'#' { in seq: Anything[0..*] ordered nonunique; in index: Natural[1]; return : Anything[0..1]; } behavior add { inout seq: Anything[0..*] ordered nonunique; in values: Anything[0..*] ordered nonunique; } behavior addAt { inout seq: Anything[0..*] ordered nonunique; in values: Anything[0..*] ordered nonunique; in index: Positive[1]; } behavior remove{ inout seq: Anything[0..*] ordered nonunique; in values: Anything[0..*]; } behavior removeAt{ inout seq: Anything[0..*] ordered nonunique; in startIndex: Positive[1]; in endIndex: Positive[1] default startIndex; } } Last changed: 2023-02 (changed '[' to '#') Release 2026-03 138 -Collection Functions standard library package CollectionFunctions { … public import Collections::*; function '==' specializes BaseFunctions::'==‘ {in col1: Collection[0..1]; in col2: Collection[0..1]; return : Boolean[1];} function size {in col: Collection[1]; return : Natural[1];} function isEmpty {in col: Collection[1]; return : Boolean[1];} function notEmpty {in col: Collection[1]; return : Boolean[1];} function contains {in col: Collection[1]; in values: Anything[*]; return : Boolean[1];} function containsAll {in col1: Collection[1]; in col2: Collection[2]; return : Boolean[1];} function head {in col: OrderedCollection[1]; return : Anything[0..1];} function tail {in col: OrderedCollection[1]; return : Anything[0..*] ordered nonunique;} function last {in col: OrderedCollection[1]; return : Anything[0..1];} function '#' specializes BaseFunctions::'#‘ {in col: OrderedCollection[1]; in index: Positive[1]; return : Anything[0..1];} function 'array#' specializes BaseFunctions::'#‘ {in arr: Array[1]; in indexes: Positive[n] ordered nonunique; return : Anything[0..1];} } Last changed: 2024-07 (import visibility) Release 2026-03 139 -Vector Functions (1) standard library package VectorFunctions { … public import VectorValues::*; abstract function isZeroVector {in v: VectorValue[1]; return : Boolean[1];} abstract function '+' specializes DataFunctions::'+' {in v: VectorValue[1]; in w: VectorValue[0. .1]; return u: VectorValue[1];} abstract function '-' specializes DataFunctions::'-' {in v: VectorValue[1]; in w: VectorValue[0. .1]; return u: VectorValue[1];} function VectorOf {in components: NumericalValue[1. .*] ordered nonunique; return : NumericalVectorValue[1];} abstract function scalarVectorMult specializes DataFunctions::' *’ {in x: NumericalValue[1]; in v: NumericalVectorValue[1]; return w: NumericalVectorValue[1]; alias '*' for scalarVectorMult; abstract function vectorScalarMult specializes DataFunctions::' *’ {in v: NumericalVectorValue[1]; in x: NumericalValue[1]; return : NumericalVectorValue[1];} abstract function vectorScalarDiv specializes DataFunctions::'/’ {in v: NumericalVectorValue[1]; in x: NumericalValue[1]; return : NumericalVectorValue[1];} abstract function inner specializes DataFunctions::'*’ {in v: NumericalVectorValue[1]; in w: NumericalVectorValue[1]; return x: NumericalValue[1];} abstract function norm {in v: NumericalVectorValue[1]; return l : NumericalValue[1];} abstract function angle {in v: NumericalVectorValue[1]; in w: NumericalVectorValue[1]; return theta: NumericalValue[1];} … } Last changed: 2024-07 (import visibility) Release 2026-03 140 -Vector Functions (2) standard library package VectorFunctions { … function CartesianVectorOf {in components: NumericalValue[1. .*] ordered nonunique; return : CartesianVectorValue[1];} function CartesianThreeVectorOf specializes CartesianVectorOf {in components: Real[3] ordered nonunique; return : CartesianVectorValue[1];} function isCartesianZeroVector specializes isZeroVector {in v: CartesianVectorValue[1]; return : Boolean[1];} function 'cartesian+' specializes '+' {in v: CartesianVectorValue[1]; in w: CartesianVectorValue[0. .1]; return: CartesianVectorValue[1]; function 'cartesian-' specializes '-' {in v: CartesianVectorValue[1]; in w: CartesianVectorValue[0. .1]; return: CartesianVectorValue[1]; function cartesianScalarVectorMult specializes scalarVectorMult {in x: Real[1]; in v: CartesianVectorValue[1]; return : CartesianVectorValue[1];} function cartesianVectorScalarMult specializes vectorScalarMult {in v: CartesianVectorValue[1]; in x: Real[1]; return : CartesianVectorValue[1];} function cartesianInner specializes inner {in v: CartesianVectorValue[1]; in w: CartesianVectorValue[0. .1]; return : Real[1];} function cartesianNorm specializes norm {in v: CartesianVectorValue[1]; return : NumericalValue[1];} function cartesianAngle specializes angle {in v: CartesianVectorValue[1]; in w: CartesianVectorValue[0. .1]; return : Real[1];} function sum {in coll: CartesianThreeVectorValue[*]; return : CartesianThreeVectorValue[0. .1];} } Last changed: 2022-09 (standard library package) Release 2026-03 141 -Control Functions standard library package ControlFunctions { private import Base::Anything; private import ScalarValues::ScalarValue; abstract function 'if’ {in test: Boolean[1]; in expr thenValue[0..1] {return : Anything[0..*] ordered nonunique;} in expr elseValue[0..1] {return : Anything[0..*] ordered nonunique;} return : Anything[0..*] ordered nonunique;} abstract function ‘??’ {in firstValue: Anything[0..*]; in expr secondValue[0..1] {return : Anything[0..*] ordered nonunique;} return : Anything[0..*] ordered nonunique;} function 'and’ {in firstValue: Anything[0..*]; in expr secondValue[0..1] {return : Boolean[1];} return : Boolean[1];} function 'or’ {in firstValue: Anything[0..*]; in expr secondValue[0..1] {return : Boolean[1];} return : Boolean[1];} function 'implies’ {in firstValue: Anything[0..*]; in expr secondValue[0..1] {return : Boolean[1];} return : Boolean[1];} abstract function collect {in collection: Anything[0..*] ordered nonunique; in expr mapper[0..*] (argument: Anything[1]): Anything[0..*] ordered nonunique; return : Anything[0..*] ordered nonunique { } abstract function select { in collection: Anything[0..*] ordered nonunique; in expr selector[0..*] (argument: Anything[1]): Boolean[1]; return : Anything[0..*] ordered nonunique { } abstract function reject { in collection: Anything[0..*] ordered nonunique; in expr rejector[0..*] (argument: Anything[1]): Boolean[1]; return : Anything[0..*] ordered nonunique { } … } Last changed: 2025-02 (corrected 'and', 'or', 'implies' parameters) Release 2026-03 142 -Occurrence Functions Test whether two occurrences represent different portions of the same entity (i.e., standard library package OccurrenceFunctions { whether they have the same "identity"). … function '===' specializes BaseFunctions::'===' { Can be invoked using the === operator. in x: Occurrence[0..1]; in y: Occurrence[0..1]; return : Boolean[1]; } function isDuring { Test whether a performance in occ: Occurrence[1]; of this function happens return : Boolean[1]; } during the input occurrence. function create { inout occ: Occurrence[1]; return : Occurrence[1]; } Create or destroy an function destroy { occurrence. inout occ: Occurrence[0..1]; return : Occurrence[0..1]; Add a newly created instance } to a group of occurrences. function addNew { inout group: Occurrence[0..*] nonunique; inout occ: Occurrence[1]; return : Occurrence[1]; } function addNewAt { inout group: Occurrence[0..*] ordered nonunique; inout occ: Occurrence[1]; in index: Positive[1]; return : Occurrence[1]; } Remove an instance from behavior removeOld { a group of occurrences inout group: Occurrence[0..*] nonunique; inout occ: Occurrence[0..1]; } and destroy it. behavior removeOldAt { inout group: Occurrence[0..*] ordered nonunique; in index: Positive[1]; } } Last changed: 2022-09 (new) Release 2026-03 143 -Systems Library (selected models) 144 Release 2026-03 -Standard View Definitions standard library package StandardViewDefinitions { view def GeneralView; view def InterconnectionView; view def ActionFlowView specializes InterconnectionView; view def StateTransitionView specializes InterconnectionView; view def SequenceView; view def GeometryView; view def GridView; view def BrowserView; } Last changed: 2024-07 (updated to latest version) Release 2026-03 145 -Metadata Domain Library 146 Release 2026-03 -Risk Metadata standard library package RiskMetadata { private import ScalarValues::Real; attribute def Level :> Real { assert constraint { that >= 0.0 and that <= 1.0 } } enum def LevelEnum :> Level { low = 0.25; medium = 0.50; high = 0.75; } General risk level in terms of attribute def RiskLevel { attribute probability : Level; probability and impact. attribute impact : Level [0..1]; } enum def RiskLevelEnum :> RiskLevel { Standard low, medium and low = RiskLevel(probability = LevelEnum::L); high risk levels. medium = RiskLevel(probability = LevelEnum::M); high = RiskLevel(probability = LevelEnum::H); } To be used to annotate metadata def Risk { model elements as to their attribute totalRisk : RiskLevel [0..1]; attribute technicalRisk : RiskLevel [0..1]; risk level in typical risk areas. attribute scheduleRisk : RiskLevel [0..1]; attribute costRisk : RiskLevel [0..1]; } } Last changed: 2024-07 (import visibility) Release 2026-03 147 -Modeling Metadata standard library package ModelingMetadata { … enum def StatusKind { open; tbd; // To be determined tbr; // To be resolved tbc; // To be confirmed To be used to annotate done; model elements with closed; status information. } metadata def StatusInfo { attribute originator : String [0..1]; To be used to give a attribute owner : String [0..1]; This is an optional reference attribute status : StatusKind; rationale for a model attribute risk : Risk [0..1]; to a feature that further element. } explains this rationale (e.g., metadata def Rationale { a trade study analysis). attribute text : String; ref explanation : Anything [0..1]; Generic issue annotation. } metadata def Issue { attribute text : String; } To be used to model a metadata def Refinement { dependency in which :>> annotatedElement : SysML::Dependency; source elements refine } target elements. } Last changed: 2022-09 (standard library package) Release 2026-03 148 -Parameters of Interest Metadata standard library package ParametersOfInterestMetadata { Semantic metadata for private import Metaobjects::SemanticMetadata; identifying an attribute attribute measuresOfEffectiveness[*] nonunique; as a measure of attribute measuresOfPerformance[*] nonunique; effectiveness. metadata def MeasureOfEffectiveness :> SemanticMetadata { :>> annotatedElement : SysML::Usage; :>> baseType = measuresOfEffectiveness meta SysML::Usage; } metadata def MeasureOfPerformance :> SemanticMetadata { Semantic metadata for :>> annotatedElement : SysML::Usage; identifying an attribute :>> baseType = measuresOfPerformance meta SysML::Usage; as a measure of } performance. } Last changed: 2022-09 (replaced "as" with "meta") Release 2026-03 149 -Image Metadata Provides data standard library package ImageMetadata { private import ScalarValues::String; necessary for the physical definition of a Binary data for the image. attribute def Image { graphical image. attribute content : String[0..1]; Binary data character attribute encoding : String[0..1]; encoding (e.g., "base64"). attribute type : String[0..1]; MIME type of the content. To be used to annotate attribute location : String[0..1]; } URI for image content, a model element with an image. alternative to embedding metadata def Icon { it in the content attribute. attribute fullImage : Image[0..1]; Full-sized image for attribute smallImage : Image[0..1]; rendering the } annotated element. } Smaller image for use as an adornment or marker. Last changed: 2022-11 (private import) Release 2026-03 150 -Analysis Domain Library 151 Release 2026-03 -Trade Studies An EvaluationFunction is a standard library package TradeStudies { calculation that evaluates a private import Base::Anything; TradeStudy alternative. private import ScalarValues::*; private import ScalarFunctions::*; abstract calc def EvaluationFunction(alternative) result : ScalarValue[1]; abstract requirement def TradeStudyObjective { A TradeStudyObjective is the subject selectedAlternative : Anything; in ref alternatives : Anything[1..*]; base definition for the objective in calc eval : EvaluationFunction; of a TradeStudy, requiring the out attribute best : ScalarValue; selectedAlternative to have best require constraint { eval(selectedAlternative) = = best } evaluation according to a given } requirement def MinimizeObjective :> TradeStudyObjective { EvaluationFunction. … attribute :>> best = alternatives->minimize {in x; eval(x)}; } requirement def MaximizeObjective :> TradeStudyObjective { … attribute :>> best = alternatives->maximize {in x; eval(x)}; } A TradeStudy is an analysis case whose abstract analysis def TradeStudy { subject studyAlternatives : Anything[1. .*]; subject is a set of alternatives and abstract calc evaluationFunction : EvaluationFunction; whose result is a selection of one of objective tradeStudyObjective : TradeStudyObjective { those alternatives, based on a given subject :>> selectedAlternative; EvaluationFunction such that it satisfies in ref :>> alternatives = studyAlternatives; in calc :>> eval = evaluationFunction; the objective of the TradeStudy. } return selectedAlternative : Anything = studyAlternatives->selectOne {in ref a; tradeStudyObjective(selectedAlternative = a)}; } Last changed: 2025-07 (“fn” changed to “eval”) Release 2026-03 152 -Analysis Tooling Annotations standard library package AnalysisTooling { private import ScalarValues::*; ToolExecution metadata metadata def ToolExecution { identifies an external analysis attribute toolName : String; tool to be used to implement attribute uri : String; the annotated action. } metadata def ToolVariable { attribute name : String; } ToolVariable metadata is used in the } context of an action that has been annotated with ToolExecution metadata. It is used to annotate a parameter or other feature of the action with the name of the variable in the tool that is to correspond to the annotated feature. Last changed: 2022-09 (standard library package) Release 2026-03 153 -State Space Representation (1) standard library package StateSpaceRepresentation { private import ISQ::DurationValue; private import Quantities::VectorQuantityValue; private import VectorCalculations::*; abstract attribute def StateSpace :> VectorQuantityValue; abstract attribute def Input :> VectorQuantityValue; abstract attribute def Output :> VectorQuantityValue; abstract calc def GetNextState {in input: Input; in stateSpace: StateSpace; in timeStep: DurationValue; return : StateSpace;} abstract calc def GetOutput {in input: Input; in stateSpace: StateSpace; return : Output;} abstract action def StateSpaceEventDef; action def ZeroCrossingEventDef :> StateSpaceEventDef; item def StateSpaceItem; StateSpaceDynamics is the simplest abstract action def StateSpaceDynamics { in attribute input: Input; form of state space representation, abstract calc getNextState: GetNextState; and getNextState directly computes abstract calc getOutput: GetOutput; the stateSpace of the next timestep. attribute stateSpace: StateSpace; out attribute output: Output = getOutput(input, stateSpace); } abstract attribute def StateDerivative :> VectorQuantityValue { … } abstract calc def GetDerivative {in input: Input; in stateSpace: StateSpace; return : StateDerivative;} abstract calc def Integrate {in getDerivative: GetDerivative; in input: Input; in initialState: StateSpace; in timeInterval: DurationValue; return result: StateSpace;} … Last changed: 2022-11 (private import) Release 2026-03 154 -State Space Representation (2) ContinuousStateSpaceDynamics represents continuous behavior. The derivative needs to return a time … derivative of stateSpace, i.e. dx/dt. abstract action def ContinuousStateSpaceDynamics :> StateSpaceDynamics { abstract calc getDerivative: GetDerivative; calc :>> getNextState: GetNextState { calc integrate: Integrate { in derivative = ContinuousStateSpaceDynamics::getDerivative; in input = GetNextState::input; in initialState = GetNextState::stateSpace; in timeInterval = GetNextState::timeStep; return resultState = result; } } event occurrence zeroCrossingEvents[0. .*] : ZeroCrossingEventDef; } DiscreteStateSpaceDynamics abstract calc def GetDifference { represents discrete behavior. in input: Input; in stateSpace: StateSpace; getDifference returns the difference return : StateSpace;} of the stateSpace for each timestep. abstract action def DiscreteStateSpaceDynamics :> StateSpaceDynamics { abstract calc getifference: GetDifference; calc :>> getNextState: GetNextState { attribute diff: StateSpace = getDifference(input, stateSpace); stateSpace + diff } } } Last changed: 2022-09 (standard library package) 155 Release 2026-03 -Sampled Functions SamplePair is a key-value pair of a domain-value and a standard library package SampledFunctions { range-value, used as a sample … element in SampledFunction. SampleFunction is a variable-size, ordered collection of SamplePair attribute def SamplePair :> KeyValuePair { elements representing a discretely attribute domainValue :>> key; attribute rangeValue :>> val; sampled mathematical function. } attribute def SampledFunction :> OrderedMap { attribute samples: SamplePair[0..*] ordered :>> elements; Domain and Range return all assert constraint { … } The function is constrained the domain values and range } to be strictly increasing or values of a sampled function. strictly decreasing. calc def Domain{in fn : SampledFunction; return : Anything[0..*] = fn.samples.domainValue;} calc def Range{in fn : SampledFunction; Sample a calculation on return : Anything[0..*] = fn.samples.rangeValue;} given domain values to create a SampledFunction. calc def Sample {in calc calculation {in x;} in attribute domainValues [0..*]; return sampling; Interpolate a calc def Interpolate {in attribute fn : SampledFunction; SampledFunction to in attribute value; compute a result for a return attribute result;} given domain value. calc interpolateLinear : Interpolate { … } } Last changed: 2022-09 (standard library package) Release 2026-03 156 -Cause and Effect Domain Library 157 Release 2026-03 -Causation Connections A connection between one or more cause occurrences standard library package CausationConnections { and one or more effect abstract occurrence causes[*]; occurrences. Specializations abstract occurrence effects[*]; add ends for specific causes abstract connection def Multicausation { and effects. abstract constant ref occurrence causes[1..*] :>> causes :> participant; abstract constant ref occurrence effects[1..*] :>> effects :> participant; … } abstract connection multicausations : Multicausation[*] { connection def Causation :> Multicausation { A binary connection end theCauses[*] occurrence theCause between a single cause and :>> causes :>> source; a single effect. (But a single end theEffects[*] occurrence theEffect cause can separately have :>> effects :>> target; } multiple effects, and a abstract connection causations : Causation[*] single effect can separately :> multicausations; have multiple causes.) } Last changed: 2025-07 (connection feature declarations) Release 2026-03 158 -Cause and Effect Metadata standard library package CauseAndEffect { public import CausationConnections::*; Used to tag the “cause” private import ScalarValues::*; ends of a multicausation. private import Metaobjects::SemanticMetadata; metadata def CauseMetadata :> SemanticMetadata { ref :>> annotatedElement : SysML::Usage; Used to tag the “effect” ref :>> baseType = causes meta SysML::Usage; ends of a multicausation. } metadata def EffectMetadata :> SemanticMetadata { ref :>> annotatedElement : SysML::Usage; Additional metadata about ref :>> baseType = effects meta SysML::Usage; } a causation connection. metadata def CausationMetadata { ref :> annotatedElement : SysML::ConnectionDefinition; ref :> annotatedElement : SysML::ConnectionUsage; attribute isNecessary : Boolean default false; attribute isSufficient : Boolean default false; Semantic metadata for attribute probability : Real[0..1]; multicausation. } metadata def MulticausationSemanticMetadata :> CausationMetadata, SemanticMetadata { Semantic metadata for ref :>> baseType = multicausations meta SysML::Usage; binary cauasation. } metadata def CausationSemanticMetadadata :> CausationMetadata, SemanticMetadata { ref :>> baseType = causations meta SysML::Usage; } } Last changed: 2024-07 (import visibility) Release 2026-03 159 -Requirements Derivation Domain Library 160 Release 2026-03 -Derivation Connections A connection between one original requirement and one standard library package DerivationConnections { or more derived requirements. requirement originalRequirements[*]; Specializations add ends for requirement derivedRequirements[*]; specific original and derived requirements. abstract connection def Derivation { ref requirement originalRequirement[1] :>> originalRequirements :> participant; ref requirement :>> derivedRequirements[1..*] Original requirement must not :> participant; be a derived requirement. private assert constraint originalNotDerived { … } private assert constraint originalImpliesDerived { … } } Whenever the original requirement is satisfied, all abstract connection derivations : Derivation[*]; the derived requirements } must also be satisfied. Last changed: 2025-07 (removed participant redefinition) Release 2026-03 161 -Requirement Derivation Metadata standard library package RequirementDerivation { public import DerivationConnections::*; Used to tag the “original” private import Metaobjects::SemanticMetadata; ends of a derivation. metadata def OriginalRequirementMetadata :> SemanticMetadata { :> annotatedElement : SysML::Usage; :>> baseType = originalRequirements meta SysML::Usage; Used to tag the “derived” } ends of a derivation. metadata def DerivedRequirementMetadata :> SemanticMetadata { :> annotatedElement : SysML::Usage; :>> baseType = derivedRequirements meta SysML::Usage; Semantic metadata for } requirement derivation. metadata def DerivationMetadata :> SemanticMetadata { :> annotatedElement : SysML::ConnectionDefinition; :> annotatedElement : SysML::ConnectionUsage; :>> baseType = derivations meta SysML::Usage; } } Release 2026-03 Last changed: 2024-07 (import visibility) 162 -Quantities and Units Domain Library (selected models) 163 Release 2026-03 -Quantities A tensor quantity value The numeric value of represents the value of the most the tensor is given as general kind of quantity, a tensor. standard library package Quantities { an array of numbers . abstract attribute def TensorQuantityValue :> Collections::Array { attribute num : ScalarValues::Number[1..*] ordered nonunique :>> elements; attribute mRef : UnitsAndScales::TensorMeasurementReference; attribute :>> dimensions = mRef::dimensions; The value of a tensor … quantity is relative to a } multi-dimensional tensor abstract attribute def VectorQuantityValue :> TensorQuantityValue { measurement reference. attribute :>> mRef : UnitsAndScales::VectorMeasurementReference; } A vector is a tensor with abstract attribute def ScalarQuantityValue :> ScalarQuantityValue { a single dimension. attribute :>> mRef : UnitsAndScales::ScalarMeasurementReference; } A scalar is a vector with a single abstract attribute tensorQuantities: TensorQuantityValue[*] nonunique; element. Its measurement abstract attribute vectorQuantities: VectorQuantityValue[*] nonunique :> tensorQuantities; reference may be a measurement abstract attribute scalarQuantities: ScalarQuantityValue[*] nonunique :> vectorQuantities; unit if the scale is a ratio scale. alias TensorQuantityValue as QuantityValue; A quantity is a usage of a alias tensorQuantities as quantity; … quantity value to represent } a feature of something. Last changed: 2022-09 (standard library package) Release 2026-03 164 -Measurement References standard library package MeasurementReferences { attribute def TensorMeasurementReference :> Array { attribute mRefs : ScalarMeasurementReference[1..*] :>> elements; … } A tensor measurement reference attribute def VectorMeasurementReference is defined as an array of scalar :> TensorMeasurementReference { measurement references , one attribute :>> dimensions: Positive[0..1]; for each element of the tensor. … } attribute def ScalarMeasurementReference :> VectorMeasurementReference { attribute :>> dimensions = (); … } attribute def CoordinateFrame :> VectorMeasurementReference { attribute transformation: CoordinateTransformation[0..1]; } … } A coordinate frame is a kind of vector measurement reference that can be located and oriented relative to another frame using a coordinate transformation. Last changed: 2022-09 (standard library package) Release 2026-03 165 -Units A measurement unit is a measurement scale defined as a standard library package Measurement { sequence of unit power factors. … abstract attribute def MeasurementUnit :> ScalarMeasurementReference { A simple unit is a measurement attribute unitPowerFactor : UnitPowerFactor[1..*] ordered; unit with no power factor attribute unitConversion : UnitConversion[0..1]; dependencies on other units. } abstract attribute def SimpleUnit :> MeasurementUnit { attribute redefines unitPowerFactor[1] { attribute redefines unit = SimpleUnit::self; attribute redefines exponent = 1; A derived unit is any unit that is } not simple. } abstract attribute def DerivedUnit :> MeasurementUnit; attribute def UnitPowerFactor { attribute unit : MeasurementUnit; attribute exponent : ScalarValues::Real; A unit power factor is a } representation of a reference … unit raised to an exponent. } Last changed: 2022-09 (standard library package) Release 2026-03 166 -International System of Quantities (ISQ) The International System of Quantities defines seven abstract units (length, mass, time, electric current, standard library package ISQ { temperature, amount of substance, import ISQBase::*; import ISQSpaceTime::*; luminous intensity) and many other units derived from those. … } standard library package ISQBase { A length unit is a simple unit. attribute def LengthUnit :> SimpleUnit {…} A length value is a quantity attribute def LengthValue :> ScalarQuantityValue { attribute redefines num : ScalarValues::Real; value with a real magnitude and a length-unit scale. attribute redefines mRef : LengthUnit; } attribute length: LengthValue :> quantity; A length is a quantity with a … length value. } The ISQ standard (ISO 80000) package ISQSpaceTime { is divided into several parts. For import ISQBase::*; example, Part 3 defines units … related to space and time. } Last changed: 2022-09 (standard library package) Release 2026-03 167 -International System of Units / Système International (SI) The International standard library package SI { public import ISQ::*; System of Units defines public import SIPrefixes::*; base units for the seven A unit can be defined using abstract ISQ unit types. prefix-based conversion attribute gram : MassUnit; from a reference unit. attribute metre : LengthUnit; attribute kilogram : MassUnit { Each unit declaration attribute redefines unitConversion : ConversionByPrefix { includes the full unit attribute redefines prefix = kilo; name and its attribute redefines referenceUnit = g abbreviation as an } identifier. } attribute second : TimeUnit; attribute ampere : ElectricCurrentUnit; attribute kelvin : ThermodynamicTemperatureUnit; A derived unit can be attribute mole : AmountOfSubstanceUnit; defined from an attribute candela : LuminousIntensityUnit; arithmetic expression … of other units. attribute newton : ForceUnit = kg * m / s ^ 2; Last changed: 2024-07 (import visibility) Release 2026-03 168 -US Customary Units standard library package USCustomaryUnits { public import ISQ::*; private import SI::*; attribute foot : LengthUnit { attribute redefines unitConversion : ConversionByConvention { attribute redefines referenceUnit = m, attribute redefines conversionFactor = 3048/10000; } US customary units are defined } by conversion from SI units. … attribute mile : LengthUnit { attribute redefines unitConversion : ConversionByConvention { attribute redefines referenceUnit = ft, attribute redefines conversionFactor = 5280; } } attribute <'mi/hr'> 'mile per hour' : SpeedUnit = mi / hr; alias mph for 'mi/hr’; … } An alias for mile per hour. Last changed: 2024-07 (import visibility) Release 2026-03 169 -Quantity Calculations (1) standard library package QuantityCalculations { private import ScalarValues::*; private import Quantities::ScalarQuantityValue; private import MeasurementReferences::ScalarMeasurementReference; private import MeasurementReferences::DimensionOneValue; calc def '[' specializes BaseFunctions::'[' { in num: Number[1]; in mRef: ScalarMeasurementReference[1]; return quantity : ScalarQuantityValue[1]; } … calc def abs specializes NumericalFunctions::abs { in x: ScalarQuantityValue[1]; return : ScalarQuantityValue[1]; } calc def '+' specializes NumericalFunctions::'+' { in x: ScalarQuantityValue[1]; in y: ScalarQuantityValue[0..1]; return : ScalarQuantityValue; } calc def '-' specializes NumericalFunctions::'-' { in x: ScalarQuantityValue; in y: ScalarQuantityValue[0..1]; return : ScalarQuantityValue[1]; } calc def '*' specializes NumericalFunctions::'*' { in x: ScalarQuantityValue[1]; in y: ScalarQuantityValue[1]; return : ScalarQuantityValue[1]; } calc def '/' specializes NumericalFunctions::'/' { in x: ScalarQuantityValue[1]; in y: ScalarQuantityValue[1]; return : ScalarQuantityValue[1]; } calc def '**' specializes NumericalFunctions::'**' { in x: ScalarQuantityValue[1]; in y: Real[1]; return : ScalarQuantityValue[1]; } calc def '^' specializes NumericalFunctions::'^' { in x: ScalarQuantityValue[1]; in y: Real[1]; return : ScalarQuantityValue[1]; } calc def '<' specializes NumericalFunctions::'<' { in x: ScalarQuantityValue[1]; in y: ScalarQuantityValue[1]; return : Boolean[1]; } calc def '>' specializes NumericalFunctions::'>' { in x: ScalarQuantityValue[1]; in y: ScalarQuantityValue[1]; return : Boolean[1]; } calc def '<=' specializes NumericalFunctions::'<=' { in x: ScalarQuantityValue[1]; in y: ScalarQuantityValue[1]; return : Boolean[1]; } calc def '>=' specializes NumericalFunctions::'>=' { in x: ScalarQuantityValue[1]; in y: ScalarQuantityValue[1]; return : Boolean[1]; } … } Last changed: 2023-02 (new) Release 2026-03 170 -Quantity Calculations (2) standard library package QuantityCalculations { … calc def max specializes NumericalFunctions::max { in x: ScalarQuantityValue[1]; in y: ScalarQuantityValue[1]; return : ScalarQuantityValue[1]; } calc def min specializes NumericalFunctions::min { in x: ScalarQuantityValue[1]; in y: ScalarQuantityValue[1]; return : ScalarQuantityValue[1]; } calc def '==' specializes DataFunctions::'==' { in x: ScalarQuantityValue[1]; in y: ScalarQuantityValue[1]; return : Boolean[1]; } calc def sqrt{ in x: ScalarQuantityValue[1]; return : ScalarQuantityValue[1]; } calc def floor { in x: ScalarQuantityValue[1]; return : ScalarQuantityValue[1]; } calc def round { in x: ScalarQuantityValue[1]; return : ScalarQuantityValue[1]; } calc def ToString specializes BaseFunctions::ToString { in x: ScalarQuantityValue[1]; return : String; } calc def ToInteger { in x: ScalarQuantityValue[1]; return : Integer[1]; } calc def ToRational { in x: ScalarQuantityValue[1]; return : Rational[1]; } calc def ToReal { in x: ScalarQuantityValue[1]; return : Real[1]; } calc def ToDimensionOneValue { in x: Real[1]; return : DimensionOneValue[1]; } calc def sum specializes NumericalFunctions::sum { in collection: ScalarQuantityValue[0..*]; return : ScalarQuantityValue; } calc def product specializes NumericalFunctions::product { in collection: ScalarQuantityValue[0..*]; return : ScalarQuantityValue; } calc def ConvertQuantity { in x: ScalarQuantityValue[1]; in targetMRef: ScalarMeasurementReference[1]; return : ScalarQuantityValue[1]; } } Last changed: 2023-02 (new) Release 2026-03 171 -Measurement Reference Calculations standard library package MeasurementRefCalculations { private import ScalarValues::String; private import ScalarValues::Real; private import MeasurementReferences::MeasurementUnit; private import MeasurementReferences::ScalarMeasurementReference; private import MeasurementReferences::CoordinateFrame; calc def '*' specializes DataFunctions::'*' { in x: MeasurementUnit[1]; in y: MeasurementUnit[1]; return : MeasurementUnit[1]; } calc def '/' specializes DataFunctions::'/' { in x: MeasurementUnit[1]; in y: MeasurementUnit[1]; return : MeasurementUnit[1]; } calc def '**' specializes DataFunctions::'**' { in x: MeasurementUnit[1]; in y: Real[1]; return : MeasurementUnit[1]; } calc def '^' specializes DataFunctions::'^' { in x: MeasurementUnit[1]; in y: Real[1]; return : MeasurementUnit[1]; } calc def 'CoordinateFrame*' specializes DataFunctions::'*' { in x: CoordinateFrame[1]; in y: MeasurementUnit[1]; return : CoordinateFrame[1]; } calc def 'CoordinateFrame/' specializes DataFunctions::'/' { in x: CoordinateFrame[1]; in y: MeasurementUnit[1]; return : CoordinateFrame[1]; } calc def ToString specializes BaseFunctions::ToString { in x: ScalarMeasurementReference[1]; return : String[1]; } } Last changed: 2023-02 (new) Release 2026-03 172 -Vector Calculations standard library package VectorCalculations { private import ScalarValues::Boolean; private import ScalarValues::Number; private import Quantities::VectorQuantityValue; calc def '+' specializes VectorFunctions::'+’ {in : VectorQuantityValue; in : VectorQuantityValue; return : VectorQuantityValue;} calc def '-' specializes VectorFunctions::'-’ {in : VectorQuantityValue; in : VectorQuantityValue; return : VectorQuantityValue;} calc def scalarVectorMult specializes VectorFunctions:: scalarVectorMult {in : Number; in : VectorQuantityValue; return : VectorQuantityValue;} calc def vectorScalarMult specializes VectorFunctions:: vectorScalarMult {in : VectorQuantityValue; in : Number; return : VectorQuantityValue;} calc def vectorScalarDiv specializes RealFunctions::'*’ {in : VectorQuantityValue; in : Number; return : VectorQuantityValue;} calc def inner specializes VectorFunctions::inner {in : VectorQuantityValue; in : VectorQuantityValue; return : Number;} alias scalarVectorMult as '*'; calc def norm specializes VectorFunctions::norm {in : VectorQuantityValue; return : Number;} calc def angle specializes VectorFunctions::angle {in : VectorQuantityValue; in : VectorQuantityValue; return : Number;} } Last changed: 2022-09 (standard library package) Release 2026-03 173 -Tensor Calculations standard library package TensorCalculations { private import ScalarValues::Boolean; private import ScalarValues::Number; private import Quantities::ScalarQuantityValue; private import Quantities::VectorQuantityValue; private import Quantities::TensorQuantityValue; private import MeasurementReferences::TensorMeasurementReference; private import MeasurementReferences::CoordinateTransformation; calc def '[' specializes BaseFunctions::'[' { in elements: Number[1..n] ordered; in mRef: TensorMeasurementReference[1]; return quantity: TensorQuantityValue[1]; private attribute n = mRef.flattenedSize; } … calc def '+' :> DataFunctions::'+' ]{ in : TensorQuantityValue[1]; in : TensorQuantityValue[1]; return : TensorQuantityValue[1]; } calc def '-' :> DataFunctions::'-' { in : TensorQuantityValue[1]; in : TensorQuantityValue[1]; return : TensorQuantityValue[1]; } calc def scalarTensorMult { in : Number[1]; in : TensorQuantityValue[1]; return : TensorQuantityValue[1]; } calc def TensorScalarMult { in : TensorQuantityValue[1]; in : Number[1]; return : TensorQuantityValue[1]; } calc def scalarQuantityTensorMult { in : ScalarQuantityValue[1]; in : TensorQuantityValue[1]; return : TensorQuantityValue[1]; } calc def TensorScalarQuantityMult { in : TensorQuantityValue[1]; in : ScalarQuantityValue[1]; return : TensorQuantityValue[1]; } calc def tensorVectorMult { in : TensorQuantityValue[1]; in : VectorQuantityValue[1]; return : VectorQuantityValue[1]; } calc def vectorTensorMult { in : VectorQuantityValue[1]; in : TensorQuantityValue[1]; return : VectorQuantityValue[1]; } calc def tensorTensorMult { in : TensorQuantityValue[1]; in : TensorQuantityValue[1]; return : TensorQuantityValue[1]; } calc def transform { in transformation : CoordinateTransformation; in sourceTensor : TensorQuantityValue; return targetTensor : TensorQuantityValue; } } Last changed: 2023-02 (new) Release 2026-03 174 -Time (1) A singleton universal time reference. standard library package Time { Clocks is a Kernel Library model part universalClock : Clock[1] :> of the semantics of clocks. Clocks::universalClock; part def Clock :> Clocks::Clock { A clock provides the current attribute :>> currentTime : TimeInstantValue; time as a quantity that } advances monotonically over the lifetime of the clock. calc def TimeOf :> Clocks::TimeOf { in o : Occurrence[1]; TimeOf returns the time instant in clock : Clock[1] default localClock; of the start of an occurrence return timeInstant : TimeInstantValue[1]; relative to a given clock. } calc def DurationOf :> Clocks::DurationOf { DurationOf returns the in o : Occurrence[1]; duration of a given occurrence in clock : Clock[1] default localClock; relative to a given clock (the return duration : DurationValue; time of its end snapshot minus } the time of its start snapshot). Last changed: 2025-02 (removed “readonly”) Release 2026-03 175 -Time (2) Captures the specification Generic time scale to of the time instant with express a time instant. value zero, also known as the (reference) epoch. attribute def TimeScale :> IntervalScale { attribute :>> unit: DurationUnit[1]; attribute definitionalEpoch: DefinitionalQuantityValue[1]; attribute :>> definitionalQuantityValues = definitionalEpoch; } Representation of a time instant quantity. attribute def TimeInstantValue :> ScalarQuantityValue { attribute :>> num: Real[1]; attribute :>> mRef: TimeScale[1]; } Generic representation of a attribute timeInstant: TimeInstantValue :> scalarQuantities; time instant as a calendar date and time of day. abstract attribute def DateTime :> TimeInstantValue; abstract attribute def Date :> TimeInstantValue; abstract attribute def TimeOfDay :> TimeInstantValue; Representation of the attribute UTC: TimeScale { Coordinated Universal Time attribute :>> longName = "Coordinated Universal Time"; (UTC) time scale. attribute :>> unit = SI::s; attribute :>> definitionalEpoch: DefinitionalQuantityValue { :>> num = 0; :>> definition = "UTC epoch at 1 January 1958 at 0 hour 0 minute 0 second"; } } attribute def UtcTimeInstantValue :> DateTime { :>> mRef = UTC; } attribute utcTimeInstant: UtcTimeInstantValue; Last changed: 2022-09 (standard library package) Release 2026-03 176 -Time (3) Representation of an ISO 8601-1 date and time in extended attribute def Iso8601DateTimeEncoding :> String; string format. attribute def Iso8601DateTime :> UtcTimeInstantValue { attribute :>> num = getElapsedUtcTime(val); Representation of an ISO 8601 attribute val: Iso8601DateTimeEncoding; date and time with explicit date private calc getElapsedUtcTime and time component attributes. {in iso8601DateTime: Iso8601DateTimeEncoding; return : Real;} } attribute def Iso8601DateTimeStructure :> UtcTimeInstantValue { attribute :>> num = getElapsedUtcTime(year, month, day, hour, minute, second, microsecond, hourOffset, minuteOffest); attribute :>> mRef = UTC; attribute year: Integer; attribute month: Natural; attribute day: Natural; attribute hour: Natural; attribute minute: Natural; attribute second: Natural; attribute microsecond: Natural; attribute hourOffset: Integer; attribute minuteOffest: Integer; private calc getElapsedUtcTime(year: Integer, month: Natural, day: Natural, hour: Natural, minute: Natural, second: Natural, microsecond: Natural, hourOffset: Integer, minuteOffest: Integer) : Real; } … } Last changed: 2022-09 (standard library package) Release 2026-03 177 -Geometry Library 178 Release 2026-03 -Spatial Items (1) A spatial item is an Item with a three- standard library package SpatialItems { dimensional spatial extent that also … acts as a spatial frame of reference. item def SpatialItem :> SpatialFrame { item :>> self : SpatialItem; item :>> localClock : Clock[1] default Time::universalClock; attribute coordinateFrame : ThreeDCoordinateFrame[1] default universalCartesianSpatial3dCoordinateFrame; A spatial item has local time and space references item originPoint : Point[1] :> spaceShots; used within it. item subSpatialItems : SpatialItem[1..*] :> subitems { ref item :>> SpatialItem::localClock, subitems::localClock; } item componentItems : SpatialItem[0..*] ordered :> subSpatialItems { ref item :>> SpatialItem::localClock, subSpatialItems::localClock; attribute :>> coordinateFrame { attribute :>> transformation[1] default nullTransformation { … } } } private attribute cunionNum: Natural [1] = if isEmpty(componentItems) ? 0 else 1; private attribute componentUnion[cunionNum] :> unionsOf { item :>> elements : SpatialItem[1..*] = componentItems; } … } A compound spatial item is a spatial … item that is a (spatial) union of a } collection of component spatial items. Last changed: 2025-07 (added subSpatialItem) Release 2026-03 179 -Spatial Items (2) standard library package SpatialItems { … The position of points in space can be calc def PositionOf :> SpatialFrames::PositionOf { in point : Point[1]; determined relative to the space and in timeInstant : TimeInstantValue[1]; time references of a spatial item. in enclosingItem :>> 'frame' : SpatialItem[1]; in clock : Clock[1] default enclosingItem.localClock; return positionVector : VectorQuantityValue[1]; } calc def CurrentPositionOf :> SpatialFrames::CurrentPositionOf { in point : Point[1]; in enclosingItem :>> 'frame' : SpatialItem[1]; The position of a point can move in clock : Clock[1] default enclosingItem.localClock; over time, with its "current" return positionVector : VectorQuantityValue[1]; position being relative to the clock } calc def DisplacementOf :> SpatialFrames::DisplacementOf { reference of the spatial item. in point1 : Point[1]; in point2 : Point[1]; in timeInstant : TimeInstantValue[1]; in spacialItem :>> 'frame' : SpatialItem[1]; in clock : Clock[1] default spacialItem.localClock; return displacementVector : VectorQuantityValue[1]; } calc def CurrentDisplacementOf :> SpatialFrames::CurrentDisplacementOf { in point1 : Point[1]; in point2 : Point[1]; in spacialItem :>> 'frame' : SpatialItem[1]; in clock : Clock[1] default spacialItem.localClock; return displacementVector : VectorQuantityValue[1]; } } Last changed: 2022-09 (standard library package) Release 2026-03 180 -Shape Items (1) The ShapeItems package provides a model of items that represent standard library package ShapeItems { … basic geometric shapes. item def PlanarCurve :> Curve { attribute :>> length [1]; … } item def Line :> PlanarCurve { attribute :>> length; attribute :>> outerSpaceDimension = 1; } item def PlanarSurface :> Surface { attribute :>> area; attribute :>> outerSpaceDimension = 2; item :>> shape : PlanarCurve; } abstract item def Path :> StructuredCurve; abstract item def Shell :> StructuredSurface; … } Last changed: 2025-07 (StructuredCurve and StructuredSurface) Release 2026-03 181 -Shape Items (2) standard library package ShapeItems { … item def ConicSection :> Path, PlanarCurve { … } item def Ellipse :> ConicSection { attribute :>> semiMajorAxis; attribute :>> semiMinorAxis; … } item def Circle :> Ellipse { attribute :>> radius; attribute :>> semiMajorAxis = radius; attribute :>> semiMinorAxis = radius; … } … item def Polygon :> Path, PlanarCurve { item :>> edges : Line { item :>> vertices [2]; } attribute :>> isClosed = true; … } … } Last changed: 2023-11 (Updated Circle) Release 2026-03 182 -Shape Items (3) standard library package ShapeItems { … item def Disc :> Shell, PlanarSurface { attribute :>> semiMajorAxis; attribute :>> semiMinorAxis; item :>> shape : Ellipse [1] { attribute :>> semiMajorAxis = Disc::semiMajorAxis; attribute :>> semiMinorAxis = Disc::semiMinorAxis; } … } item def CircularDisc :> Disc { attribute :>> radius [1]; attribute :>> semiMajorAxis [1] = radius; attribute :>> semiMinorAxis [1] = radius; item :>> shape : Circle { … } … } item def ConicSurface :> Shell { … } … } Last changed: 2025-07 (CircularDisc attributes) Release 2026-03 183 -Shape Items (4) standard library package ShapeItems { … item def Ellipsoid :> ConicSurface { attribute semiAxis1 : LengthValue [1] :> scalarQuantities; attribute semiAxis2 : LengthValue [1] :> scalarQuantities; attribute semiAxis3 : LengthValue [1] :> scalarQuantities; … } item def Sphere :> Ellipsoid { attribute :>> radius [1]; attribute :>> semiAxis1 [1] = radius; attribute :>> semiAxis2 [1] = radius; attribute :>> semiAxis3 [1] = radius; } item def Paraboloid :> ConicSurface { attribute focalDistance : LengthValue [1] :> scalarQuantities; … } … } Last changed: 2025-07 (Sphere attributes) Release 2026-03 184 -Shape Items (5) standard library package ShapeItems { … item def ConeOrCylinder :> Shell { attribute :>> semiMajorAxis [1]; attribute :>> semiMinorAxis [1]; attribute :>> height [1]; … } item def Cone :> ConeOrCylinder { … } item def Cylinder :> ConeOrCylinder { … } … item def Polyhedron :>> Shell { … } item def CuboidOrTriangularPrism :> Polyhedron { … } item def Cuboid :> CuboidOrTriangularPrism { … } item def RectangularCuboid :> Cuboid { attribute :>> length [1]; attribute :>> width [1]; attribute :>> height [1]; … } alias Box for RectangularCuboid; … } Last changed: 2022-09 (standard library package) Release 2026-03 185