sysml-roadmap:secm_concept_definitions_snapshot_1_28_2016
This is an old revision of the document!
Back to SysML Assessment and Roadmap Working Group
SECM Concept Model Definitions Snapshot (1/28/2016)
| Name | Documentation | |||
|---|---|---|---|---|
| Action | A non-interruptible function. Note: An action represents an atomic unit of processing or work. Actions may be continuous or discrete. Discrete actions may or may not be assumed to execute in zero time. | |||
| Activation/deactivation event | An event that occurs when a function is activated or deactivated. | |||
| Activation/deactivation requirement | The activation or deactivation that one or more functions must satsify when specified events and conditions occur. | |||
| Activation/deactivation rules | The logic which determines when one or more functions are activated and deactivated. | |||
| Activation time | The interval of time that a function or state is active. | |||
| Activity | One or more related actions. | |||
| Analysis | The process of evaluating elements, properties and associated relationships. | |||
| Analysis model | A model used to analyze the structure, behavior, and/or properties of systems and environments. | |||
| AP-233 | ISO STEP Application Protocol for Systems Engineering Data Interchange Standard | |||
| Arc | An association between two or more nodes. | |||
| Association | Refer to UML specification | |||
| Behavior | The activation/deactivation of one or more functions. Note: This describes how a system interacts with its environment. Reactive behavior includes the stimulus and response. | |||
| Behavior allocation | The allocation of functions and/or states to systems, and the allocation of inputs and outputs to system ports. | |||
| Boolean | Refer to UML specification | |||
| Category | A partitioning of elements based on a classification. | |||
| Complex number | A number which can includes a real and imaginary part. | |||
| Component | A constituent part of an element or system that contributes to the properties and behaviors of the whole (emergent). Note: A leaf component does not have constituent parts. | |||
| Composite function | A function which is decomposed into lower level functions. | |||
| Composite state | A state which includes nested states. | |||
| Concurrent state | A state which is active at the same time as another state that is part of the same composite state. | |||
| Condition | An expression with a discrete output, which is true as long as the expression evaluates true, and is false otherwise. | |||
| Connecting component | A specialized component or system, whose primary function is to connect the outputs from one system to the inputs of another system via its ports. Note: This may be a wire, network, or mechanical coupler that has properties and behaviors, which may transform the inputs and outputs. | |||
| Connection | Identification of which ports connect to one another. | |||
| Connection path | Multiple connections that may represent a single logical connection. | |||
| Continuous time model | A model which is based on properities that vary continuously with time. | |||
| Control input | An input that activates or deactivates a function. | |||
| Control operator | A specialized function that provides logic to transform input events and conditions to discrete values that are supplied as control inputs to functions. | |||
| Data | A component of information. | |||
| Data type | Refer to UML specification | |||
| Decomposition | A description of a whole in terms of its component parts. | |||
| Dependency | A relationship where a change to one entity results in a change to the other. | |||
| Deployment | A allocation of one component to another that is often associated with the utilization of resources across the distributed nodes of a system. | |||
| Design | The process of transforming requirements to an implementation. | |||
| Design constraint | A requirement that one or more components of a system must satisfy. Note: This term is sometimes used to refer to a constraint on the design process versus the system. | |||
| Diagram interchange | The ability to exchange notational information on a diagram, including the layout of the diagram. | |||
| Discrete time model | A model which is based on properities that vary discretely with time. | |||
| Domain | A scope that encompasses a set of entities and relationships that may be addressed by the model. | |||
| Effectiveness measure | A criterion for system optimization that is critcial to the success of the mission. | Note: The criterion are often used to support trade studies to select among alternatives, as well as to optimize a given design. | ||
| EIA 632 | A process standard for Engineering a System. | |||
| Element | Anything of interest to the modeler, which is uniquely identifiable and can be characterized by a set of properties. | |||
| Enabling system | Any system which may be needed to support another system throughout its life cycle, and typically includes the development, production, deployment, support, and disposal systems. | |||
| Enumerated value | Refer to UML specification | |||
| Environment | A collection of systems and elements that interact either directly or indirectly with the system of interest. | |||
| 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. | |||
| Expression | ||||
| Facility | A physical infrastructure that supports use of equipment and other resources. | |||
| Failure | An inability to satsify a requirement. | |||
| Fork | A control operator which enables all of its outputs, when the input is evaluated true. | |||
| Function | A transformation of inputs to outputs that may include the creation, monitoring, modification or destruction of elements, or a null transformation. | |||
| Function port | A binding of an input to the arguments of a function. | |||
| Function time-line | A representation of the interval of time that one or more functions and/or states are active and inactive. | |||
| Functional requirement | A function a system must perform. | |||
| Generalization | The factoring of common features to characterize a more general concept. | |||
| Geometric model | A model of the geometric relationships associated with one or more elements. | |||
| Hardware | A component of a system that has geometric contstraints. | |||
| IDEF0 | Air Force Standard for process modeling. | |||
| Input/Output | An element that is subject to a transformation by a function. | |||
| Instance | A unique model element in a set that iis defined by the general features of its classifier. | |||
| Integer | ||||
| Interaction | Emergent behavior that results from two or more dependent behaviors Note: A system or component interacts with other components its environment, to yield an emergent system behavior from the individual component behaviors . | |||
| Interface | The inputs, outputs, ports, connections, connecting components (i.e. harness), and associated information that support one or more interactions between systems. Note: The UML definition of interface also includes the operations that must be performed in response to the inputs or invocations. | |||
| Interface requirement | An interface a system must support. | |||
| ISO 15288 | A process standard for system life cycle processes. | |||
| Issue (technical) | A potential problem, that requires resolution. | |||
| Iteration loop | A specialized loop where the loop repeats a specified number of times. | |||
| Join | A control operator which enables its control output, when all of its inputs are evaluated true. | |||
| Leaf function | A function which is not further decomposed. | |||
| Loop | A control operator which initiates one or more loop functions when the input is evaluated true, and is repeated as long as the loop conditions are evaluated true. | |||
| Manual procedure | A set of operations that provide instructions for a user to perform. | |||
| Mean | The expected value associated with a probability distirbution. | |||
| Merge | A control operator which enables its output, when any of its inputs are evaluated true. | |||
| Mission | The operational context and purpose that the system is intended to support. | |||
| Model (graphical, visual) | A representation of something of interest that includes notation and semantics. | |||
| Model element | A construct that is used to build a model. | |||
| Model interchange | The ability to exchange model information. | |||
| Model view | A subset of model elements and associated relationships, that are of use to the modeler for a particular purpose and context. | |||
| Natural object | An element that is not engineered, and may be part of a system or environment. | |||
| Need | A desired requirement of a stakeholder. | |||
| Nested state | A state which is enabled by its composite state. | |||
| Node | A component of a system that provides resources to support execution. | |||
| Notation | The graphical depiction of a model construct. | |||
| Operational requirement | A requirement which is associated with the operation of a system, and typically includes a combination of functional, interface, and performance requirements. | |||
| Parametric model | An analysis model which defines a set of dependent or logically grouped parametric relationships. | |||
| Parametric relationship | A dependency between properties, such that a change to the value of one property impacts the value of the other property. | |||
| Performance property | A measure of the transformation or response of a function or behavior (i.e response time, etc | ). | ||
| Performance requirement | A performance property a system must satsify. | |||
| Physical property | A physical characteristic of a system or element (i.e. weight, color). | |||
| Physical requirement | A physical property a system must satsify. | |||
| Port | The part of a system or component that provides access between a system’s behaviors and properties, and its environment. Note: this is sometimes referred to as an interaction point. | |||
| Probability distribution | A mathematical function which defines the likelihood of a paritcular set of outcomes. | |||
| Probe | A component that monitors the values associated with one or more parameters (i.e. properties). | |||
| Problem | A deficiency, limitation, or failure to satisfy a requirement or need, or other undesired outcome. Note: A problem may be associated with the behavior, structure, and/or properties of a system or element at any level of the hierarchy (i. | e. | system of system level, down to a component/part level). | |
| Problem cause | The relationship between a problem and its source problems (i.e. cause). Note: This cause affect relationship is often represented in fishbone diagrams, fault trees, etc. | . | ||
| Process | A set of inter-related functions and their corresponding inputs and outputs, which are activated and deactivated by their control inputs. | |||
| Property | A quantifiable characteristic. | |||
| Property association | The assignment of a property to a model element or set of model elements. | |||
| Property attribute | ||||
| Property value | Unique state of a property. | |||
| Real number | A number which can have any value from negative infinity to infinity. | |||
| Replicate function | A function which represents the same transformation, but is implemented by separate resources. | |||
| Requirement | The capability, behavior, structure, and/or properties that a system, component, or element must satisfy. Note: This is used to establish a contract between the customer (or stakeholder) and implementer. | |||
| Requirement allocation | The assignment of a requirement to an element, component, or system. | |||
| Requirement attribute | An attrirbue fo a requirement, which may include its criticality or weighting, level of uncertainty, verification status, etc. | |||
| Requirement traceability | The relationship between a source requirement and the derived requirements needed to satisfy the source requirement. | |||
| Requirement type | A category of requirement. | Note: This includes functional, interface, performance, etc. | ||
| Requirement verification | A comparison between a requirement and the verification results that is intended to satisfy the requirement. | |||
| Resource | Any element that is needed for the execution of a function. | |||
| Role | ||||
| 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. | |||
| 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. | |||
| Simple state | A state that does not have nested states. | |||
| Software | A component of a system that specifies instructions which are executed by a computer. | |||
| Source requirement | The requirement which is the basis for deriving one or more other requirements. | |||
| Spatial representation | A geometrical relationship among elements. | |||
| Specialization | A classification of an entity (e. | g. | , element, system, function, requirement, …), which specifies the common features of the more general element, and unique features of the specific element. | |
| Specialized requirement | A requirement that is not explicitly addressed by the default requirement types. Note: This may include safety, reliabillity, maittianability, producibility, usability, security, etc. | |||
| Specialty engineering | A general term for engineering disciplines associated with some specific aspects of a system, suchas reliability or safety engineering. | |||
| 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. | |||
| 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. | |||
| 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. | |||
| String | A value represented by alphanumeric characters. | |||
| Structure | The relationships between the components that contribute to the properties of the whole, and enable them to interact (inter-relate). | |||
| Subsystem | A logical or physical partitioning of a system. | |||
| System | An element, with structure, that exhibits observable properties and behaviors. | |||
| System (component) boundary | The set of all ports, which connect the system (component) to its environment. | |||
| System context | A depiction of the inputs and outputs between a system and its environment. | |||
| System hierarchy | A decomposition of a system and its 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 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 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. | |||
| 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. | ||
| Topology | A graph of nodes and arcs. | |||
| Trade-off study | An evaluation of alternatives based on a set of evaluation criteria. | |||
| Transition | Response to events/conditions, which triggers a behavior. | |||
| Triggering input | An input which is required for a function to be activated. | |||
| UML | ||||
| User | An individual or group of individuals that use a system. | |||
| Validation | The process for demonstrating that a system or its requirements satisfy the stakeholder needs. | |||
| Variance | A measure of the distribution about the mean of a probability distribution. Refer to the mathematical definition associated with a probability distribution. | |||
| Vector | A data type, which specifies a magnitude and direction. | |||
| Verification | The process for demonstrating a system satisfies its requirements. | |||
| Verification procedure |
sysml-roadmap/secm_concept_definitions_snapshot_1_28_2016.1454029460.txt.gz · Last modified: 2016-01-28 20:04 by roncwilliamson
