@memoarchitect/ontology 0.6.5 → 0.8.22

package/src/architecture/functional/constraints/memo_constraints.sysml

@@ -1,13 +1,14 @@
 package memo_architecture_functional_constraints {
     private import ScalarValues::*;
+    private import memo_core_common::*;
 
     doc /* Reusable quantitative constraint definitions. */
 
-    constraint def MaxResponseTimeConstraint {
+    constraint def MaxResponseTimeConstraint :> MemoConstraint {
         attribute responseTimeMs : Real;
         attribute maxAllowedMs : Real;
     }
-    constraint def LockoutIntervalConstraint {
+    constraint def LockoutIntervalConstraint :> MemoConstraint {
         attribute elapsedMs : Real;
         attribute lockoutMs : Real;
     }

package/src/architecture/functional/functions/memo_functions.sysml

@@ -1,10 +1,56 @@
-// Functional architecture (§9). A SystemFunction is a technology-independent
-// responsibility of the system; a SystemAction is executable behavior realizing
-// a function; a FunctionalExchange is a typed transfer between functions. A
-// function may be realized by human action, mechanical design, electrical
-// hardware, software, or a combination — allocation is optional and never
-// assumes software.
+// Functional architecture (§9). A function is a responsibility: what the
+// system, or one of its components, is answerable for. A FunctionalExchange is
+// a typed transfer between functions. A function may be realized by human
+// action, mechanical design, electrical hardware, software, or a combination —
+// allocation to the system's own parts is what ComponentFunction records, and
+// it never assumes software.
+//
+// ─── A function is a behaviour ───────────────────────────────────────────
+//
+// `MemoFunction` and both its specializations are `action def`s. They were
+// `part def SystemFunction specializes ArchitectureElement` until Track A0
+// removed the reason: relation ends were typed on MemoPart/ArchitectureElement,
+// KerML forbids a behaviour from specializing a part-based type, and a function
+// has to be satisfiable, verifiable, and allocatable. So a function was declared
+// a part, and a separate `action def SystemAction` carried the behaviour with a
+// `ref performedFunction` stapling the two back together — a reference used in
+// ZERO example files. The ends are metaclass-neutral now (CR-ONT-060..073), so
+// the split has no cause and is gone: SystemAction is merged into the function
+// family, and its `actionKind` moved onto MemoFunction where it was always
+// describing the function anyway.
+//
+// `functionCategory` and `actionKind` are NOT two spellings of one axis, and
+// merging them would lose information. `actionKind` is the verb — sense,
+// compute, actuate, route. `functionCategory` is the domain grouping the
+// project argues in — therapy, alarm, platform, protection. A function can be
+// `sense` in the `protection` category, and a safety case reasons about both.
+//
+// ─── System function vs. component function ──────────────────────────────
+//
+// ARCADIA's functional chain does not stop at the system boundary: system
+// functions decompose until each piece is the responsibility of exactly one
+// component. MEMO names the two ends of that chain because they obey different
+// rules, not because they carry different attributes:
+//
+//   SystemFunction    — a responsibility of the system as a whole.
+//                       Technology-independent. Allocation is OPTIONAL, and a
+//                       system function may be realized by several components,
+//                       by a human, or by mechanism.
+//   ComponentFunction — a responsibility of ONE component: a flowmeter's
+//                       "measure flow rate", a subsystem's "arbitrate alarms".
+//                       Allocation is MANDATORY and single-valued (CR-ONT-074).
+//
+// That difference is structural, which is why these are two definitions rather
+// than one definition carrying a `functionLevel` enum. An enum member cannot
+// change a multiplicity, and "is answerable to exactly one component" is the
+// whole content of the concept.
+//
+// Decomposition and allocation reuse the existing relations and need no new
+// ones — `Composes` for the function tree, `AllocatedTo` for the component.
+// Both had part-typed ends until A0; both are metaclass-neutral now, which is
+// precisely what makes an action-def function usable at all.
 package memo_architecture_functional_functions {
+    private import Metaobjects::SemanticMetadata;
     private import ScalarValues::*;
 
     private import memo_core_common::*;
@@ -13,31 +59,53 @@ package memo_architecture_functional_functions {
     private import memo_architecture_operational_activities::*;
     private import memo_architecture_operational_scenarios::*;
 
-    part def SystemFunction specializes ArchitectureElement {
+    abstract action def MemoFunction specializes MemoAction {
         attribute functionCategory : String;
+        attribute actionKind : ActionKind;
         attribute trigger : String;
         attribute outputSummary : String;
         attribute concernKind : ConcernKind;
         attribute criticality : CriticalityKind;
     }
 
-    // Executable behavior realizing a system function.
-    action def SystemAction specializes MemoAction {
-        attribute actionKind : ActionKind;
-        attribute executionSummary : String;
-        ref performedFunction : SystemFunction[0..1];
-    }
+    // A responsibility of the system as a whole. Allocation is optional: a
+    // system function that no single component owns is a normal intermediate
+    // state of the functional chain, not a defect.
+    action def SystemFunction specializes MemoFunction;
+
+    // A responsibility of exactly one component. `AllocatedTo` names that
+    // component; CR-ONT-074 requires it. A component function that reaches no
+    // component is a responsibility nobody has accepted.
+    action def ComponentFunction specializes MemoFunction;
 
-    // Typed transfer of information/command/status/etc. between functions
-    // (renamed from LogicalFlow — it belongs to the functional perspective).
+    // Named traceable route between functions. Native `flow of` usages carry
+    // the transported item; this element exists for the budgets and assurance
+    // attributes below.
+    //
+    // The reason is MEMO's grammar, NOT the language — the earlier wording here
+    // said "attributes that a flow usage cannot own", and that was a false
+    // claim about SysML v2. The standard's `FlowUsage` is
+    // `OccurrenceUsagePrefix 'flow' FlowDeclaration DefinitionBody`
+    // (SysML-textual-bnf.kebnf:829), so a conforming flow usage takes a name
+    // from its `UsageDeclaration` and owns attributes in its body like any
+    // other usage. MEMO's own production is
+    // `'flow' 'of' itemType 'from' … 'to' … ';'` — no name, no body — so a
+    // MEMO flow can carry neither an `id` nor a latency budget, and nothing
+    // can refer to it. Every MEMO element rests on the identification core in
+    // memo_core_common, and an anonymous attribute-less edge cannot join it.
+    //
+    // So this part def is a workaround for a MEMO gap, not a design MEMO is
+    // entitled to. Restoring the two dropped clauses is what would let it
+    // collapse into the flow it stands in for.
     part def FunctionalExchange specializes ArchitectureElement {
         attribute flowKind : FlowKind;
-        attribute direction : DirectionKind;
         attribute latencyBudgetMs : Real;
         attribute staleAfterMs : Real;
         attribute integrityLevel : String;
-        ref sourceFunction : SystemFunction[0..1];
-        ref targetFunction : SystemFunction[0..1];
+        // MemoFunction, not SystemFunction: an exchange between two component
+        // functions is the ordinary case once the chain is decomposed.
+        ref sourceFunction : MemoFunction[0..1];
+        ref targetFunction : MemoFunction[0..1];
     }
 
     // A system function enables operational work; it does not perform it.
@@ -46,36 +114,18 @@ package memo_architecture_functional_functions {
     // flows are part of functional architecture, never logical structure.
     part def FunctionalFlow specializes ArchitectureElement {
         attribute flowCategory : FunctionalFlowKind;
-        ref startFunction : SystemFunction[0..1];
-        ref endFunction : SystemFunction[0..1];
         attribute endToEndLatencyBudgetMs : String;
         attribute safetyRelevant : Boolean;
         attribute securityRelevant : Boolean;
-        ref includedFunctions : SystemFunction[0..*];
     }
-    part def FunctionalFlowStep specializes MemoPart {
-        attribute stepOrder : String;
-        ref function : SystemFunction[0..1];
+    action def FunctionalFlowStep specializes MemoAction {
+        ref function : MemoFunction[0..1];
         ref exchange : FunctionalExchange[0..1];
-        ref item exchangedItem : MemoExchangeItem[0..1];
+        ref item exchangedItem : MemoItem[0..1];
     }
 
-    // The functional-layer scenario selects one functional route and realizes
-    // an operative scenario. It is the "what the system does" path, not a
-    // logical component interaction.
-    part def FunctionalScenario specializes MemoScenario {
-        ref functionSequence : SystemFunction[0..*];
-        ref functionalFlows : FunctionalExchange[0..*];
-        attribute sequenceDiagramRef : String;
-        ref selectedFlow : FunctionalFlow[0..1];
-    }
-    connection def IncludesStep :> MemoRelationship {
-        end functionalFlow : FunctionalFlow;
-        end step : FunctionalFlowStep;
-    }
-    connection def InvolvesFunction :> MemoRelationship {
-        end functionalFlow : FunctionalFlow;
-        end function : SystemFunction;
-    }
-    // Compatibility spelling used by existing models.
+    // `InvolvesFunction` is native `perform` (R10-S6): a `FunctionalFlow`
+    // already names its functions via its step chain
+    // (`perform <step>;` + the step's own `ref function`), and a flow with no
+    // step chain performs its functions directly.
 }

package/src/architecture/implementation/software/runtime/memo_software_runtime.sysml

@@ -1,10 +1,17 @@
-// Software runtime (component-and-connector) view (§11). Runtime structure
-// with concurrency, scheduling, health monitoring, fault containment, and
-// update/rollback semantics. Module structure lives in
+// Software runtime (component-and-connector) view (§11), matching the SEI
+// Views and Beyond distinction between runtime components and implementation
+// modules. Runtime structure carries concurrency, scheduling, health
+// monitoring, fault containment, and update/rollback semantics. Module structure lives in
 // memo_architecture_implementation_software_structure; allocation in
-// memo_architecture_realization_deployment. Detailed AADL categories stay in the AADL
-// correspondence profile (examples/aadl-mapping).
+// memo_architecture_realization_deployment.
+//
+// Detailed AADL categories live in the AADL correspondence profile, which is
+// an extension package: `extensions/aadl` (plan §C5). It carries the process /
+// thread / virtual-processor families and a correspondence rule per mapped
+// name and property. This comment pointed at `examples/aadl-mapping` for a
+// long time and that directory never existed; the pointer above resolves.
 package memo_architecture_implementation_software_runtime {
+    private import Metaobjects::SemanticMetadata;
     private import ScalarValues::*;
 
     private import memo_core_common::*;
@@ -25,11 +32,9 @@ package memo_architecture_implementation_software_runtime {
         enum messageBroker;
     }
 
-    part def SoftwareComponent specializes ArchitectureElement {
+    part def SoftwareComponent specializes SoftwareElement {
         attribute runtimeKind : RuntimeKind;
         attribute responsibility : String;
-        attribute safetyClass : SafetyClassKind;
-        attribute complexity : ComplexityKind;
         attribute periodMs : Real;
         attribute deadlineMs : Real;
         attribute wcetMs : Real;
@@ -38,7 +43,10 @@ package memo_architecture_implementation_software_runtime {
         attribute activation : String;
         attribute synchronizationMechanism : String;
         attribute sharedResources : String;
-        attribute memoryBudget : String;
+        // Maximum resident memory allocation in megabytes.  The public name
+        // predates MEMO's unit-suffixed scalar convention, so document the
+        // unit here rather than silently changing the published feature name.
+        attribute memoryBudget : Real;
         attribute healthMonitoring : String;
         attribute restartPolicy : String;
         attribute faultContainment : String;
@@ -47,24 +55,38 @@ package memo_architecture_implementation_software_runtime {
         attribute auditable : Boolean;
         attribute updatePolicy : String;
         attribute rollbackPolicy : String;
-        // runtime-kind-specific detail (set only for the relevant runtimeKind)
-        attribute addressSpaceIsolated : Boolean[0..1];
-        attribute owningProcessName : String[0..1];
-        attribute serviceContract : String[0..1];
-        attribute discoveryMechanism : String[0..1];
-        attribute imageReference : String[0..1];
-        attribute orchestrationPlatform : String[0..1];
-        attribute partitionBudget : String[0..1];
-        attribute isolationMechanism : String[0..1];
-        attribute storageKind : String[0..1];
-        attribute retentionPolicy : String[0..1];
-        attribute deliverySemantics : String[0..1];
-        attribute topicStructure : String[0..1];
+        // Twelve runtime-kind-conditional attributes used to follow, each
+        // documented "set only for the relevant runtimeKind" — which is a
+        // subtype family in disguise, and a technology the base ontology had
+        // no business asserting. They are gone; every one of them now lives on
+        // a type in an extension, where it is unconditional and therefore
+        // checkable (plan §10.3 D3, extensions/README.md):
+        //
+        //   addressSpaceIsolated, owningProcessName,
+        //   partitionBudget, isolationMechanism          -> extensions/aadl
+        //   serviceContract, discoveryMechanism,
+        //   storageKind, retentionPolicy                 -> extensions/cloud
+        //   imageReference, orchestrationPlatform        -> extensions/container
+        //   deliverySemantics, topicStructure            -> extensions/messaging
+        //
+        // The last two were also on the wrong metaclass: a component does not
+        // have a topic, a publication does.
+        //
+        // What stays is what is true of EVERY runtime component in every
+        // regulated project — the AADL thread properties above and the
+        // assurance ones — plus `runtimeKind` itself, which says which family
+        // a component belongs to without claiming to describe it.
     }
 
     connection def ComponentConnects :> MemoRelationship {
         attribute protocolSummary : String;
-        end sourceComponent : SoftwareComponent;
-        end targetComponent : SoftwareComponent;
+        end sourceComponent : SoftwareComponent :>> source;
+        end targetComponent : SoftwareComponent :>> target;
+    }
+    abstract connection componentConnectsLinks : ComponentConnects[*];
+    metadata def <componentConnects> ComponentConnectsMetadata :> SemanticMetadata {
+        :> annotatedElement : SysML::ConnectionDefinition;
+        :> annotatedElement : SysML::ConnectionUsage;
+        :>> baseType = componentConnectsLinks meta SysML::Usage;
     }
 }

package/src/architecture/implementation/software/structure/memo_software_structure.sysml

@@ -1,7 +1,10 @@
-// Software module view (§11; IEC 62304 5.3-5.4). Code/module structure only:
-// runtime structure lives in memo_architecture_implementation_software_runtime and
-// allocation in memo_architecture_realization_deployment.
+// Software module view (§11; IEC 62304 5.3-5.4). Following the SEI Views and
+// Beyond viewtypes, modules are implementation/code units; interacting runtime
+// elements are SoftwareComponents in
+// memo_architecture_implementation_software_runtime, and allocation lives in
+// memo_architecture_realization_deployment.
 package memo_architecture_implementation_software_structure {
+    private import Metaobjects::SemanticMetadata;
     private import ScalarValues::*;
 
     private import memo_core_common::*;
@@ -9,10 +12,29 @@ package memo_architecture_implementation_software_structure {
     private import memo_core_relationships::*;
     private import memo_architecture_logical_structure::*;
 
-    part def SoftwareSystem specializes ArchitectureElement {
-        attribute version : String;
+    // IEC 62304 §3.25: a SOFTWARE ITEM is "any identifiable part of a computer
+    // program". It is the general, recursive term — a SOFTWARE SYSTEM (§3.24)
+    // is the top item and a SOFTWARE UNIT (§3.26) is one not subdivided
+    // further; both are software items. So this is a base, not a fourth
+    // sibling of system/module/component.
+    //
+    // It exists because §4.3 classifies, and §5.3–5.4 decompose, SOFTWARE
+    // ITEMS — not "modules" or "components" specifically. Anything the
+    // standard obliges at item level therefore belongs here, and every
+    // software view inherits it rather than re-declaring it: the code view
+    // (SoftwareModule), the runtime view (SoftwareComponent), the system, and
+    // the user interface (memo_architecture_implementation_ui::UIElement).
+    // Structural software decomposition is part-native. IEC 62304 also uses
+    // the term "software item" for this concept, but reserving SoftwareItem
+    // for the native SysML item family keeps structural parts and exchanged
+    // values unambiguous in the model.
+    abstract part def SoftwareElement specializes ArchitectureElement {
         attribute safetyClass : SafetyClassKind;
         attribute complexity : ComplexityKind;
+    }
+
+    part def SoftwareSystem specializes SoftwareElement {
+        attribute version : String;
         attribute operatingSystem : String;
     }
 
@@ -29,11 +51,9 @@ package memo_architecture_implementation_software_structure {
         enum soup;
     }
 
-    part def SoftwareModule specializes ArchitectureElement {
+    part def SoftwareModule specializes SoftwareElement {
         attribute moduleKind : ModuleKind;
         attribute responsibility : String;
-        attribute safetyClass : SafetyClassKind;
-        attribute complexity : ComplexityKind;
         // module-kind-specific detail (set only for the relevant moduleKind)
         attribute iec62304Role : String[0..1];
         attribute implementationLanguage : String[0..1];
@@ -65,7 +85,15 @@ package memo_architecture_implementation_software_structure {
         attribute version : String;
     }
 
-    item def SBOMEntry specializes MemoExchangeItem {
+    // Software data/content that may be stored or exchanged through ports.
+    abstract item def SoftwareItem specializes MemoItem {
+        attribute schemaIdentifier : String;
+        attribute schemaVersion : String;
+        attribute encoding : String;
+        attribute timestampRequired : Boolean;
+    }
+
+    item def SBOMEntry specializes SoftwareItem {
         attribute componentName : String;
         attribute version : String;
         attribute supplier : String;
@@ -73,8 +101,20 @@ package memo_architecture_implementation_software_structure {
         attribute hash : String;
     }
 
-    connection def ModuleUses :> MemoRelationship {
-        end usingModule : SoftwareModule;
-        end usedModule : SoftwareModule;
+    // `ModuleUses` is native `dependency` (R10-S6): write
+    // `dependency <usingModule> to <usedModule>;` instead of a connection.
+
+    // ── Relations owned by this package ─────────────────────────────
+    // Moved out of memo_core_relationships: their ends are typed against
+    // types declared here, and core must not depend on a domain package.
+    connection def DependsOnSoup :> MemoRelationship {
+        end component : ArchitectureElement :>> source;
+        end soupItem : SoftwareElement :>> target;
+    }
+    abstract connection dependsOnSoupLinks : DependsOnSoup[*];
+    metadata def <dependsOnSoup> DependsOnSoupMetadata :> SemanticMetadata {
+        :> annotatedElement : SysML::ConnectionDefinition;
+        :> annotatedElement : SysML::ConnectionUsage;
+        :>> baseType = dependsOnSoupLinks meta SysML::Usage;
     }
 }