sysmledgraph 0.7.0

package/lsp/node_modules/sysml-v2-lsp/sysml.library/Systems Library/Ports.sysml

@@ -0,0 +1,54 @@
+standard library package Ports {
+    doc
+    /*
+     * This package defines the base types for ports and related structural elements 
+     * in the SysML language.
+     */
+
+    private import Objects::Object;
+    private import Objects::objects;
+    
+    abstract port def Port :> Object {
+        doc
+        /*
+         * 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.
+         * 
+         * Transfers outgoing from a Port are always targeted to a Port connected to
+         * the original Port by an Interface.
+         */
+    
+        ref self: Port :>> Object::self;
+        
+        port subports: Port [0..*] :> ports, timeEnclosedOccurrences {
+            doc
+            /*
+             * The Ports that are subports of this Port.
+             */
+        }
+        
+        abstract ref port interfacingPorts : Port[0..*] nonunique :> ports {
+            doc
+            /*
+             * Ports that are connected to this Port by an Interface.
+             */
+        }
+        
+        ref :>> outgoingTransfersFromSelf :> interfacingPorts.incomingTransfersToSelf {
+            doc
+            /* 
+             * The target of each of the outgoingTransfersFromSelf of a Port must be an interfacingPort.
+             */
+             
+             end ref source;
+             end ref target;
+        }
+    }
+    
+    abstract port ports : Port[0..*] nonunique :> objects {
+        doc
+        /*
+         * ports is the base feature of all PortUsages.
+         */
+    }
+}

package/lsp/node_modules/sysml-v2-lsp/sysml.library/Systems Library/Requirements.sysml

@@ -0,0 +1,194 @@
+standard library package Requirements {
+	doc
+	/*
+	 * This package defines the base types for requirements and related elements in the SysML language.
+	 */
+
+	private import Base::Anything;
+	private import ScalarValues::String;
+	private import ControlFunctions::allTrue;
+	private import Constraints::constraintChecks;
+	private import Constraints::assertedConstraintChecks;
+	private import Constraints::negatedConstraintChecks;
+	private import Parts::Part;
+	private import Parts::parts;
+	private import Actions::Action;
+	private import Interfaces::Interface;
+	private import Attributes::AttributeValue;
+	
+	private abstract constraint def RequirementConstraintCheck {
+		doc
+		/*
+		 * RequirementConstraintCheck is the base ConstraintCheck for RequirementCheck, defining the
+		 * separate assumptions and required constraints such that, if all the assumptions are true,
+		 * then all the required constraints must be true.
+		 */
+	
+		constraint assumptions[0..*] :> constraintChecks, subperformances {
+			doc
+			/*
+			 * Assumptions that must hold for the required constraints to apply.
+			 */
+		}
+		
+		constraint constraints[0..*] :> constraintChecks, subperformances {
+			doc
+			/*
+			 * The required constraints that are to be checked.
+			 */
+		}
+		
+		return result = allTrue(assumptions()) implies allTrue(constraints()) {
+			doc
+			/*
+			 * If all the assumptions are true, then all the required constraints must hold.
+			 */
+		}
+	}
+	
+	abstract requirement def RequirementCheck :> RequirementConstraintCheck {
+		doc
+		/*
+		 * RequirementCheck is the most general class for requirements checking. RequirementsCheck is the base
+		 * type of all requirement definitions.
+		 */
+	
+		ref requirement :>> self: RequirementCheck;
+		
+		subject subj : Anything[1] {
+			doc
+			/*
+			 * The entity that is being checked for satisfaction of the required constraints.
+			 */
+		}
+		
+		ref part actors : Part[0..*] {
+			doc
+			/*
+			 * The Parts that fill the role of actors for this RequirementCheck.
+			 * (Note: This is not itself an actor parameter, because specific actor
+			 * parameters will be added for specific RequirementChecks.)
+			 */
+		}
+		
+		ref part stakeholders : Part[0..*] {
+			doc
+			/*
+			 * The Parts that represent stakeholders interested in the concern being checked.
+			 * (Note: This is not itself a stakeholder parameter, because specific stakeholder
+			 * parameters will be added for specific RequirementChecks.)
+			 */
+		}
+
+		/* 
+		 * Note: assumptions and constraints are redefined here solely to simplify the
+		 * resolution of their qualified names as library elements.
+		 */
+		constraint assumptions :>> RequirementConstraintCheck::assumptions;
+		constraint constraints :>> RequirementConstraintCheck::constraints;
+		
+		abstract requirement subrequirements[0..*] :> requirementChecks, constraints {
+			doc
+			/*
+			 * Nested requirements, which are also required constraints.
+			 */
+		}
+		
+		abstract concern concerns[0..*] :> concernChecks, subrequirements {
+			doc
+			/*
+			 * The checks of any concerns being addressed (as required constraints).
+			 */
+		}
+		
+	}
+	
+	requirement def FunctionalRequirementCheck :> RequirementCheck {
+		doc
+		/*
+		 * A functional requirement specifies an action that a system, or part of a system, must perform.
+		 */
+	
+		subject: Action;
+	}
+	
+	requirement def InterfaceRequirementCheck :> RequirementCheck {
+		doc
+		/*
+		 * An interface requirement specifies an interface for connecting systems and system parts, which
+		 * optionally may include item flows across the interface and/or interface constraints.
+		 */
+	
+		subject: Interface;
+	}
+	
+	requirement def PerformanceRequirementCheck :> RequirementCheck {
+		doc
+		/*
+		 * A performance requirement quantitavely measures the extent to which a system, or a system part, 
+		 * satisfies a required capability or condition.
+		 */
+	
+		subject: AttributeValue;
+	}
+	
+	requirement def PhysicalRequirementCheck :> RequirementCheck {
+		doc
+		/*
+		 * A physical requirement specifies physical characteristics and/or physical constraints of the 
+		 * system, or a system part.
+		 */
+	
+		subject: Part;
+	}
+	
+	requirement def DesignConstraintCheck :> RequirementCheck {
+		doc
+		/*
+		 * A design constraint specifies a constraint on the implementation of the system or system part, 
+		 * such as the system must use a commercial off the shelf component.
+		 */
+	
+		subject: Part;
+	}
+	
+	concern def ConcernCheck :> RequirementCheck {
+		doc
+		/*
+		 * ConcernCheck is the most general class for concern checking. ConcernCheck is the base type of 
+		 * all ConcernDefinitions.
+		 */
+	
+		ref concern :>> self: ConcernCheck;
+		
+	}
+	
+	abstract requirement requirementChecks: RequirementCheck[0..*] nonunique :> constraintChecks {
+		doc
+		/*
+		 * requirementChecks is the base feature of all requirement usages.
+		 */
+	}
+	
+	abstract requirement satisfiedRequirementChecks :> requirementChecks, assertedConstraintChecks {
+		doc
+		/*
+		 * satisfiedRequirementChecks is the subset of requirementChecks for Requirements asserted to be satisfied.
+		 */
+	}
+
+	abstract requirement notSatisfiedRequirementChecks: RequirementCheck[0..*] :> requirementChecks, negatedConstraintChecks {
+		doc
+		/*
+		 * notSatisfiedRequirementChecks is the subset of requirementChecks for Requirements asserted to be not satisfied.
+		 */
+	}
+	
+	abstract concern concernChecks: ConcernCheck[0..*] nonunique :> requirementChecks {
+		doc
+		/*
+		 * concernChecks is the base feature of all ConcernUsages.
+		 */
+	}
+	
+}

package/lsp/node_modules/sysml-v2-lsp/sysml.library/Systems Library/StandardViewDefinitions.sysml

@@ -0,0 +1,123 @@
+standard library package StandardViewDefinitions {
+    doc /*
+         * This package defines the standard view definitions for the SysML language.
+         */
+    public import SysML::*;
+
+    view def <gv> GeneralView {
+        doc /*
+             * View definition 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.kerml and SysML.sysml standard library packages.
+             */
+    }
+
+    view def <iv> InterconnectionView {
+        doc /*
+             * View definition 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).
+             */
+    }
+
+    view def <afv> ActionFlowView specializes InterconnectionView {
+        doc /*
+             * View definition 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
+             */
+    }
+
+    view def <stv> StateTransitionView specializes InterconnectionView {
+        doc /*
+             * View definition 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
+             */
+    }
+
+    view def <sv> SequenceView {
+        doc /*
+             * View definition 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.
+             */
+    }
+
+    view def <gev> GeometryView {
+        doc /*
+             * View definition 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
+             */
+    }
+
+    view def <grv> GridView {
+        doc /*
+             * View definition to present exposed model elements and their relationships,
+             * arranged in a rectangular grid.
+             * GridView is the generalization of the following more specialized views:
+             * - Tabular view
+             * - Data value tabular view
+             * - Relationship matrix view, e.g. presenting allocation or dependency relationships
+             */
+    }
+
+    view def <bv> BrowserView {
+        doc /*
+             * View definition to present the hierarchical membership structure of model
+             * elements starting from one or more exposed root elements.
+             * 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, as in graphical user interface widgets.
+             */
+    }
+}

package/lsp/node_modules/sysml-v2-lsp/sysml.library/Systems Library/States.sysml

@@ -0,0 +1,103 @@
+standard library package States {
+	doc
+	/*
+	 * This package defines the base types for states and related behavioral elements in the
+	 * SysML language.
+	 */
+
+	private import Occurrences::Occurrence;
+	private import StatePerformances::StatePerformance;
+	private import StatePerformances::StateTransitionPerformance;
+	private import Actions::Action;
+	private import Actions::TransitionAction;
+	private import Actions::transitionActions;
+	private import Actions::AcceptAction;
+	private import Actions::actions;
+	private import SequenceFunctions::notEmpty;
+	private import SequenceFunctions::size;
+	
+	abstract state def StateAction :> Action, StatePerformance {
+		doc
+		/*
+		 * A StateAction is a kind of Action that is also a StatePerformance. It is the base type for all
+		 * StateDefinitions.
+		 */
+	
+		entry action entryAction :>> 'entry';
+		do action doAction: Action :>> 'do';
+		exit action exitAction: Action :>> 'exit';
+		
+		attribute :>> isTriggerDuring;
+		
+		ref state self: StateAction :>> Action::self, StatePerformance::self;
+		ref state start: StateAction :>> Action::start, StatePerformance::startShot;
+		ref state done: StateAction :>> Action::done, StatePerformance::endShot;
+		
+		action :>> subactions :> middle {
+			doc
+			/*
+			 * 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. 
+			 */
+		}
+		
+		action substates: StateAction[0..*] :> stateActions, subactions {
+			doc
+			/*
+			 * The subactions of this state that are states.
+			 * 
+			 * 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".
+			 */
+		}
+		
+		abstract state exclusiveStates: StateAction[0..*] :> substates {
+			doc
+			/*
+			 * The substates of this state that are mutually exclusive, that is, whose performances do not
+			 * overlap in time.
+			 */
+		}
+		
+		abstract action stateTransitions: StateTransitionAction[0..*] :> transitions {
+			doc
+			/*
+			 * The transitions of this state that are state transitions.
+			 */
+		}
+		
+		succession stateSequencing first [0..1] exclusiveStates then [0..1] exclusiveStates {
+			doc
+			/*
+			 * Exclusive states cannot overlap, so it must be possible to strictly sequence them in time.
+			 */
+		}
+		assert constraint {notEmpty(exclusiveStates) implies size(stateSequencing) == size(exclusiveStates) - 1}
+	}
+	
+	action def StateTransitionAction :> TransitionAction, StateTransitionPerformance {
+		doc
+		/*
+		 * A StateTransitionAction is a TransitionAction and a StateTransitionPerformance whose transitionLinkSource 
+		 * is a State. It is the base type of TransitionUsages used transitions in state models.
+		 */
+	
+		in transitionLinkSource[1]: StateAction :>> 
+			TransitionAction::transitionLinkSource, StateTransitionPerformance::transitionLinkSource;
+			
+		inout payload[0..*];
+		in :>> receiver;
+		
+		bind payload = accepter.payload;
+		bind receiver = accepter.receiver;
+	}
+	
+	abstract state stateActions: StateAction[0..*] nonunique :> actions {
+		doc
+		/*
+		 * stateActions is the base feature for all StateUsages.
+		 */
+	}
+}