sysml-roadmap:secm_concept_definitions_snapshot_1_28_2016
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
sysml-roadmap:secm_concept_definitions_snapshot_1_28_2016 [2016-01-28 20:08] roncwilliamson |
sysml-roadmap:secm_concept_definitions_snapshot_1_28_2016 [2016-01-28 20:15] (current) roncwilliamson |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| Back to [[http://www.omgwiki.org/OMGSysML/doku.php?id=sysml-roadmap:sysml_assessment_and_roadmap_working_group| SysML Assessment and Roadmap Working Group]] | Back to [[http://www.omgwiki.org/OMGSysML/doku.php?id=sysml-roadmap:sysml_assessment_and_roadmap_working_group| SysML Assessment and Roadmap Working Group]] | ||
| + | |||
| + | Back to [[http://www.omgwiki.org/OMGSysML/doku.php?id=sysml-roadmap:Systems_Engineering_Model_Construction_Focus_Area|Systems Engineering Model Construction Focus Area]] | ||
| Line 50: | Line 52: | ||
| |Event|A noteworthy occurrence that occurs at the instant of time when a specified expression evaluates true.| | |Event|A noteworthy occurrence that occurs at the instant of time when a specified expression evaluates true.| | ||
| |Execution|The state of the system or model when it is running. For a model, this implies that model computation is occuring.| | |Execution|The state of the system or model when it is running. For a model, this implies that model computation is occuring.| | ||
| - | |Expression|Refer to UML specification | + | |Expression|Refer to UML specification| |
| |Facility|A physical infrastructure that supports use of equipment and other resources.| | |Facility|A physical infrastructure that supports use of equipment and other resources.| | ||
| |Failure|An inability to satsify a requirement.| | |Failure|An inability to satsify a requirement.| | ||
| Line 116: | Line 118: | ||
| |Scalable|A measure of the extent to which the modeling langauge (or methodology, etc), can be adapted to an increase in scope and/or complexity.| | |Scalable|A measure of the extent to which the modeling langauge (or methodology, etc), can be adapted to an increase in scope and/or complexity.| | ||
| |Selection|A control operator which represents a test that enables an output based on the values/conditions of the input.| | |Selection|A control operator which represents a test that enables an output based on the values/conditions of the input.| | ||
| - | |Semantics|The meaning of a model element.| Note: a precise meaning should be able to be expressed mathematically.| | + | |Semantics|The meaning of a model element. Note: a precise meaning should be able to be expressed mathematically.| |
| |Sequential state|A state which can only be active when the other sequential states are not active.| | |Sequential state|A state which can only be active when the other sequential states are not active.| | ||
| |Simple state|A state that does not have nested states.| | |Simple state|A state that does not have nested states.| | ||
| Line 127: | Line 129: | ||
| |Specification|One or more requirements for a system, component or element.| | |Specification|One or more requirements for a system, component or element.| | ||
| |Stakeholder|Individuals, groups, and/or institutions which may be impacted by the system throughout its life cycle, including acquisition, development, production, deployment, operations, support, and disposal.| | |Stakeholder|Individuals, groups, and/or institutions which may be impacted by the system throughout its life cycle, including acquisition, development, production, deployment, operations, support, and disposal.| | ||
| - | |State (finite)|A condition of a system or element, as defined by some of its properties, which can enable system behaviors and/or structure to occur. Note: The enabled behavior may include no actions, such as associated with a wait state.| Also, the condition that defines the state may be dependent on one or more previous states.| | + | |State (finite)|A condition of a system or element, as defined by some of its properties, which can enable system behaviors and/or structure to occur. Note: The enabled behavior may include no actions, such as associated with a wait state. Also, the condition that defines the state may be dependent on one or more previous states.| |
| |State based behavior|Behavior which is described by states and transitions between states.| | |State based behavior|Behavior which is described by states and transitions between states.| | ||
| - | |Storage device|A component of a system that is used to store a system store.| Note: this may include memory device, a battery, or a tank.| | + | |Storage device|A component of a system that is used to store a system store. Note: this may include memory device, a battery, or a tank.| |
| |Store requirement|An element a system must store.| | |Store requirement|An element a system must store.| | ||
| |String|A value represented by alphanumeric characters.| | |String|A value represented by alphanumeric characters.| | ||
| Line 139: | Line 141: | ||
| |System hierarchy|A decomposition of a system and its components.| | |System hierarchy|A decomposition of a system and its components.| | ||
| |System interconnection|The connection between systems and between components.| | |System interconnection|The connection between systems and between components.| | ||
| - | |System role|A subset of its behaviors, properties, and structure.| Note: The subset may be associated with specific interactions.| | + | |System role|A subset of its behaviors, properties, and structure. Note: The subset may be associated with specific interactions.| |
| - | |System store|An input/output element that persists over time, which may be depletable or non-depletable. Note: Non-depletable stores may include data store in computer memory, and depletable stores may include energy in a battery, or fluid in a tank. Physical stores obey the conservation laws (only take out what is put in). A non-depletable store, such as a data store, is not constrained by the conservation laws.| The system store should be differentiated from the storage device, which stores the element.| | + | |System store|An input/output element that persists over time, which may be depletable or non-depletable. Note: Non-depletable stores may include data store in computer memory, and depletable stores may include energy in a battery, or fluid in a tank. Physical stores obey the conservation laws (only take out what is put in). A non-depletable store, such as a data store, is not constrained by the conservation laws. The system store should be differentiated from the storage device, which stores the element.| |
| |Test case|The input stimulus, expected output, and associated test criteria which verify that the system satisfies its requirements or needs.| | |Test case|The input stimulus, expected output, and associated test criteria which verify that the system satisfies its requirements or needs.| | ||
| |Test scenario|A scenario which replicates the behavior of the environment that interacts with the system under test.| | |Test scenario|A scenario which replicates the behavior of the environment that interacts with the system under test.| | ||
| |Text based requirement|One or more requirements specified in text.| | |Text based requirement|One or more requirements specified in text.| | ||
| |Thread|A process with no concurrent functions, and represents a single path of execution.| | |Thread|A process with no concurrent functions, and represents a single path of execution.| | ||
| - | |Time property|A property of the model that represents a local or global time, which other properties may depend on. Note: The property can support continuous or discrete-time models.| This variable should not be confused with the measured or computed time that an actual system uses, which depends on a number of implementation specific factors related to clocks, synchronization, etc.| | + | |Time property|A property of the model that represents a local or global time, which other properties may depend on. Note: The property can support continuous or discrete-time models. This variable should not be confused with the measured or computed time that an actual system uses, which depends on a number of implementation specific factors related to clocks, synchronization, etc.| |
| |Topology|A graph of nodes and arcs.| | |Topology|A graph of nodes and arcs.| | ||
| |Trade-off study|An evaluation of alternatives based on a set of evaluation criteria.| | |Trade-off study|An evaluation of alternatives based on a set of evaluation criteria.| | ||
| Line 156: | Line 158: | ||
| |Vector|A data type, which specifies a magnitude and direction.| | |Vector|A data type, which specifies a magnitude and direction.| | ||
| |Verification|The process for demonstrating a system satisfies its requirements.| | |Verification|The process for demonstrating a system satisfies its requirements.| | ||
| - | |Verification procedure|The functions needed to support execution of a test case. Note. This may include generating an input stimulus and monitoring an output | + | |Verification procedure|The functions needed to support execution of a test case. Note. This may include generating an input stimulus and monitoring an output| |
| - | + | ||
| - | + | ||
sysml-roadmap/secm_concept_definitions_snapshot_1_28_2016.1454029701.txt.gz · Last modified: 2016-01-28 20:08 by roncwilliamson
Page Tools
