Snippets (text quotes and extracts from authoritative sources)

A Snippet is a short quote or extract (typically a phrase, a sentence, or at most a few sentences) from an authoritative source document such as a specification, technical manual, or design manual. Throughout this site, content is often related to supporting Snippets and each Snippet page links back to the content pages that reference it! The Snippet and Note concepts are very closely related and they support each other.

The Snippet concept is also at the heart of the Parsing Analysis recipe for UML® and SysML®

Kind Snippet quote/extract Source UML keywords SysML keywords Keywords
INFO Such constraints can also be used to identify critical performance parameters and their relationships to other parameters, which can be tracked throughout the system life cycle. OMG Systems Modeling Language (SysML) 1.6 Constraint ConstraintBlock mathematics, equation
INFO Constraint blocks can be used to specify a network of constraints that represent mathematical expressions such as {F=m*a} and {a=dv/dt}, which constrain the physical properties of a system. OMG Systems Modeling Language (SysML) 1.6 Constraint ConstraintBlock mathematics, equation
INFO Constraint blocks provide a mechanism for integrating engineering analysis such as performance and reliability models with other SysML models. OMG Systems Modeling Language (SysML) 1.6 ConstraintBlock
NOTATION A constraint property may be shown on a parametric diagram using a rectangle with rounded corners. This graphical shape distinguishes a constraint property from all other properties and avoids the need to show an explicit «constraint» keyword. Otherwise.. OMG Systems Modeling Language (SysML) 1.6 Property, «keyword» SysML Parametric Diagram, constraint parameter, constraint property, MD:ConstraintParameter, BindingConnector, «constraint» notation
INFO All properties that appear, other than the constraints themselves, shall either be bound directly to a constraint parameter, or contain a property that is bound to one (through any number of levels of containment). OMG Systems Modeling Language (SysML) 1.6 Property SysML Parametric Diagram, constraint parameter, constraint property, MD:ConstraintParameter, BindingConnector
INFO A parametric diagram is defined as a restricted form of internal block diagram. A parametric diagram may contain constraint properties and their parameters, along with other properties from within the internal block context. OMG Systems Modeling Language (SysML) 1.6 Property SysML Parametric Diagram, constraint parameter, constraint property, MD:ConstraintParameter
INFO A constraint property is a property of any block that is typed by a constraint block. It holds a localized usage of the constraint block. Binding connectors may be used to bind the parameters of this constraint block to other properties of the block ... OMG Systems Modeling Language (SysML) 1.6 ConstraintBlock, constraint parameter, MD:ConstraintParameter, BindingConnector, constraint property
INFO All properties of a constraint block are constraint parameters, with the exception of constraint properties that hold internally nested usages of constraint blocks. OMG Systems Modeling Language (SysML) 1.6 ConstraintBlock, constraint parameter, MD:ConstraintParameter, BindingConnector, constraint property
INFO Binding connectors, as defined in Clause 8 are used to bind each parameter of the constraint block to a property in the surrounding context. OMG Systems Modeling Language (SysML) 1.6 ConstraintBlock, constraint parameter, MD:ConstraintParameter, BindingConnector
INFO A constraint block typically defines one or more constraint parameters, which are bound to properties of other blocks in a surrounding context where the constraint is used. OMG Systems Modeling Language (SysML) 1.6 Constraint, Port ConstraintBlock, constraint parameter, MD:ConstraintParameter
INFO A constraint block is a block that packages the statement of a constraint so it may be applied in a reusable way to constrain properties of other blocks. OMG Systems Modeling Language (SysML) 1.6 Constraint ConstraintBlock
INFO As with any connector owned by a SysML Block, the ends of a binding connector may be nested within a multi-level path of properties accessible from the owning block. The NestedConnectorEnd stereotype is used to represent such nested ends just as for ... OMG Systems Modeling Language (SysML) 1.6 Connector, Property BindingConnector, Block, NestedConnectorEnd, multi-level property path
INFO If the properties at the ends of a binding connector are typed by a Block, the connector specifies that the instances of the properties shall refer to the same block instance. OMG Systems Modeling Language (SysML) 1.6 Connector, Property, instance BindingConnector, Block, block property
INFO If the properties at the ends of a binding connector are typed by a ValueType, the connector specifies that the instances of the properties shall hold equal values, recursively through any nested properties within the connected properties. OMG Systems Modeling Language (SysML) 1.6 Connector, Property BindingConnector, ValueType, value property
INFO A Binding Connector is a connector which specifies that the properties at both ends of the connector have equal values. OMG Systems Modeling Language (SysML) 1.6 Connector BindingConnector
EXAMPLE, INFO Figure D.24 is a parametric diagram showing how fuel flowrate is related to FuelDemand and FuelPressure value properties. OMG Systems Modeling Language (SysML) 1.6
INFO A FlowProperty signifies a single flow element to/from a block. A flow property has the same notation as a Property only with a direction prefix (in | out | inout). Flow properties are listed in a compartment labeled flow properties. OMG Systems Modeling Language (SysML) 1.6 Property FlowProperty, FlowProperty::direction, FlowDirectionKind::in, FlowDirectionKind::out, FlowDirectionKind::inout, FlowDirectionKind
INFO Flow properties specify the kinds of items that might flow between a block and its environment, whether it is data, material, or energy. The kind of items that flow is specified by typing flow properties. OMG Systems Modeling Language (SysML) 1.6 FlowProperty
INFO Blocks with ports can type other ports (nested ports). OMG Systems Modeling Language (SysML) 1.6 Port nested Port
INFO SysML extends blocks to support flow properties and provided and required features. OMG Systems Modeling Language (SysML) 1.6 provided Feature, required Feature, Block, FlowProperty
EXAMPLE, INFO The ports on the FuelTankAssembly and InternalCombustionEngine (as shown in Figure D.19) are defined in Figure D.23. OMG Systems Modeling Language (SysML) 1.6 Port HSUV sample problem
EXAMPLE, INFO Inversely, the InternalCombustionEngine can read the isControlOn property of the PowerControlUnit across the connector to determine if the unit is still operating, and possibly shut down if it is not. OMG Systems Modeling Language (SysML) 1.6 Connector HSUV sample problem, provided Feature, required Feature, part property, Block
EXAMPLE, INFO By invoking these operations, the PowerControlUnit can set the throttle and mixture of the InternalCombustionEngine. The PowerControlUnit can also read properties of the InternalCombustionEngine across the connector to find out the rpm, temperature, ... OMG Systems Modeling Language (SysML) 1.6 Connector HSUV sample problem, provided Feature, required Feature, part property, Block
EXAMPLE, INFO Since the ecu:PowerControlUnit part and ice:InternalCombustionEngine part are connected via these ports, the ecu:PowerControlUnit part may invoke setThrottle and setMixture on the ice:InternalCombustionEngine part via its ice port, across the connector... OMG Systems Modeling Language (SysML) 1.6 Port HSUV sample problem, provided Feature, required Feature, part property, Block
EXAMPLE, INFO This means the provided features of ICE are provided by the ctrl port of InternalCombustionEngine, and required by the ice port of PowerControlUnit, while the required features of ICE are required by the ctrl port of InternalCombustionEngine, and provided OMG Systems Modeling Language (SysML) 1.6 Port HSUV sample problem, provided Feature, required Feature, part property, Block
EXAMPLE, INFO For example, the ICE block specifies the provided operations setMixture and setThrottle, the provided properties RPM, temperature, and isKnocking, and required property isControlOn, as shown in Figure D.20. This block types the ctrl port of ... OMG Systems Modeling Language (SysML) 1.6 Property, Operation HSUV sample problem, provided Feature, required Feature, part property, Block
EXAMPLE, INFO The ecu:PowerControlUnit part has three ports with required and provided features, each connected to a port of another part. Each of the ports in this example is typed by a block specifying provided and required features available via connectors ... OMG Systems Modeling Language (SysML) 1.6 Port, part, Connector HSUV sample problem, provided Feature, required Feature, part property
EXAMPLE, INFO Figure 9-6 is a fragment of the ibd:PwrSys diagram used in the HybridSUV Sample Problem in Annex D. (The complete diagram is in Figure D.19.) OMG Systems Modeling Language (SysML) 1.6 HSUV sample problem
INFO Figure D.20 provides definition of the block that types the ports linked by connector c1 in Figure D.19 OMG Systems Modeling Language (SysML) 1.6 Connector, Port HSUV sample problem, Block
INFO FlowProperty::direction : FlowDirectionKind [1] Specifies if the property value is received from an external block (direction="in"), transmitted to an external Block (direction="out") or both (direction="inout"). OMG Systems Modeling Language (SysML) 1.6 FlowProperty, FlowProperty::direction, FlowDirectionKind, FlowDirectionKind::in, FlowDirectionKind::out, FlowDirectionKind::inout
EXAMPLE, INFO These multiplicities may be assumed if not shown on a diagram. To avoid confusion, any multiplicity other than the default should always be shown on a diagram. OMG Systems Modeling Language (SysML) 1.7beta1 Association, AggregationKind, multiplicity, AggregationKind::composite, AggregationKind::shared, MultiplicityElement::upperValue, MultiplicityElement::lowerValue, MultiplicityElement, MultiplicityElement::/lower, MultiplicityElement::/upper, Property::isNavigable(), DirectedRelationship::/target
EXAMPLE, INFO A part or shared association has a default multiplicity of [0..1] on the black or white diamond end. A unidirectional association has a default multiplicity of 1 on its target end. OMG Systems Modeling Language (SysML) 1.7beta1 Association, AggregationKind, multiplicity, AggregationKind::composite, AggregationKind::shared, MultiplicityElement::upperValue, MultiplicityElement::lowerValue, MultiplicityElement, MultiplicityElement::/lower, MultiplicityElement::/upper, Property::isNavigable(), DirectedRelationship::/target
EXAMPLE, INFO SysML defines defaults for multiplicities on the ends of specific types of associations. OMG Systems Modeling Language (SysML) 1.7beta1 Association, AggregationKind, multiplicity HSUV sample problem
EXAMPLE, INFO The dashed borders on Fuel denote a store, which keeps track of the amount and mass of fuel in the FuelTankAssy. This is also depicted in Figure D.18. OMG Systems Modeling Language (SysML) 1.6 AggregationKind, AggregationKind::shared HSUV sample problem
EXAMPLE, INFO The dashed borders on FrontWheel and BrakePedal denote the “use-not-composition” relationship depicted elsewhere in Figure D.16 and Figure D.18. OMG Systems Modeling Language (SysML) 1.6 AggregationKind, AggregationKind::shared HSUV sample problem
EXAMPLE, INFO Figure D.19 shows how the parts of the PowerSubsystem block, as defined in the diagram above, are used. It shows connectors between parts, ports, and connectors with item flows. OMG Systems Modeling Language (SysML) 1.6 HSUV sample problem
EXAMPLE, INFO Figure D.17 shows how the top level model elements in the above diagram are connected together in the HybridSUV block. OMG Systems Modeling Language (SysML) 1.6 Connector HSUV sample problem, Block
INFO Like UML, SysML defines no specific semantics or constraints for properties with shared aggregation, but particular models or tools may interpret them in specific ways. OMG Systems Modeling Language (SysML) 1.6 AggregationKind::shared, AggregationKind, Association, Property
INFO SysML also supports properties with shared aggregation, as shown by a white diamond symbol on an association. OMG Systems Modeling Language (SysML) 1.6 AggregationKind::shared, AggregationKind, Association, Property
EXAMPLE, INFO Figure D.16 defines components of the HybridSUV block. Note that the BrakePedal and WheelHubAssembly are used by, but not contained in, the PowerSubsystem block. OMG Systems Modeling Language (SysML) 1.6 AggregationKind::shared, AggregationKind::none HSUV sample problem, Block, shared property, reference property
EXAMPLE, INFO Note that the interactions DriveBlackBox and Stac4rtVehicleBlackBox (described in D.4.3 Elaborating Behavior (Sequence and State Machine Diagrams), are depicted as owned by the AutomotiveDomain block. OMG Systems Modeling Language (SysML) 1.6 HSUV sample problem
EXAMPLE, INFO Figure D.15 provides definition for the concepts previously shown in the context diagram. OMG Systems Modeling Language (SysML) 1.6 HSUV sample problem
EXAMPLE, INFO Figure D.14 contains two diagrams that show requirement containment (decomposition), and requirements derivation in tabular form. This is a more compact representation than the requirements diagrams shown previously. OMG Systems Modeling Language (SysML) 1.6 Requirement table, query table, report table
EXAMPLE, INFO The Power requirement is satisfied by the PowerSubsystem, and a Max Acceleration test case verifies the Acceleration requirement. OMG Systems Modeling Language (SysML) 1.6 UseCase HSUV sample problem, Requirement, TestCase, Verify, Block, «subsystem»
EXAMPLE, INFO The “refine” relation, introduced in Figure D.12, shows how the Acceleration requirement is refined by a similarly named use case. OMG Systems Modeling Language (SysML) 1.6 UseCase HSUV sample problem, Requirement, Refine
EXAMPLE, INFO Figure D.13 focuses on the Acceleration requirement, and relates it to other requirements and model elements. OMG Systems Modeling Language (SysML) 1.6 HSUV sample problem, Requirement
EXAMPLE, INFO Note also that rationale can be attached to the «deriveReqt» relationship. In this case, rationale is provided by a referenced document “Hybrid Design Guidance.” OMG Systems Modeling Language (SysML) 1.6 Refine HSUV sample problem, Requirement, DeriveReqt, Rationale requirements engineering
EXAMPLE, INFO Note how PowerSourceManagement is “RefinedBy” the HSUVOperationalStates model (Figure D.8). OMG Systems Modeling Language (SysML) 1.6 Refine HSUV sample problem, Requirement, Refine requirements engineering
INFO The Refine stereotype specializes UML4SysML Refine and DirectedRelationshipPropertyPath to enable refinements to identify their sources and targets by a multi-level path of accessible properties from context blocks for the sources and targets. OMG Systems Modeling Language (SysML) 1.6 Refine, DirectedRelationship::/source, DirectedRelationship::/target Refine, DirectedRelationshipPropertyPath
EXAMPLE, INFO Various other model elements may be necessary to help develop a derived requirement, and these model element may be related by a «refinedBy» relationship. OMG Systems Modeling Language (SysML) 1.6 Refine HSUV sample problem, Requirement, DeriveReqt, Refine requirements engineering
EXAMPLE, INFO Derived requirements, for the purpose of this example, express the concepts of requirements in the HSUVSpecification in a manner that specifically relates them to the HSUV system. OMG Systems Modeling Language (SysML) 1.6 HSUV sample problem, Requirement, DeriveReqt requirements engineering
EXAMPLE, INFO Figure D.12 shows a set of requirements derived from the lowest tier requirements in the HSUV specification. OMG Systems Modeling Language (SysML) 1.6 HSUV sample problem, Requirement, DeriveReqt requirements engineering
INFO When a requirement has nested requirements, all the nested requirements apply as part of the container requirement. Deleting the container requirement deleted [deletes] the nested requirements, a functionality inherited from UML. OMG Systems Modeling Language (SysML) 1.6 Requirement, composite (compound) requirement, subrequirement requirements engineering
INFO Subrequirements shall be accessed through the "nestedClassifier" property of a class. OMG Systems Modeling Language (SysML) 1.6 Class, Class::nestedClassifier, Classifier Requirement, «system», AbstractRequirement, composite (compound) requirement, subrequirement requirements engineering
INFO The default interpretation of a compound requirement, unless stated differently by the compound requirement itself, is that all its subrequirements shall be satisfied for the compound requirement to be satisfied. OMG Systems Modeling Language (SysML) 1.6 Class Requirement, «system», AbstractRequirement, composite (compound) requirement, Satisfy, subrequirement requirements engineering
INFO Compound requirements can be created by using the nesting capability of the class definition mechanism. OMG Systems Modeling Language (SysML) 1.6 Class Requirement, «system», AbstractRequirement, composite (compound) requirement requirements engineering
INFO A requirement is a stereotype of both Class and Abstract Requirement. OMG Systems Modeling Language (SysML) 1.6 Class Requirement, «system», AbstractRequirement requirements engineering
INFO Requirements are used to establish a contract between the customer (or other stakeholder) and those responsible for designing and implementing the system. OMG Systems Modeling Language (SysML) 1.6 Requirement, «system» requirements engineering, contract, customer, stakeholder, designer
INFO A requirement may specify a function that a system must perform or a performance condition that a system must satisfy. OMG Systems Modeling Language (SysML) 1.6 Requirement, Satisfy, «system» requirements engineering, function, system, performance condition
INFO A requirement specifies a capability or condition that must (or should) be satisfied. OMG Systems Modeling Language (SysML) 1.6 Requirement, Satisfy requirements engineering
EXAMPLE, INFO The containment (cross hair) relationship, for purposes of this example, refers to the practice of decomposing a complex requirement into simpler, single requirements. OMG Systems Modeling Language (SysML) 1.6 containment Requirement, HSUV sample problem
EXAMPLE, INFO The vehicle system specification contains many text based requirements. A few requirements are highlighted in Figure D.11, including the requirement for the vehicle to pass emissions standards, which is expanded for illustration purposes. OMG Systems Modeling Language (SysML) 1.6 Requirement, HSUV sample problem
EXAMPLE, INFO The lifelines on Figure D.10 (“whitebox” sequence diagram) need to come from the Power System decomposition. This now begins to consider parts contained in the HybridSUV block. OMG Systems Modeling Language (SysML) 1.6 Lifeline, Sequence Diagram, part HSUV sample problem, Block, part property
INFO If the reply Message has a signature, then wildcard arguments are provided for all return, out and inout ownedParameters of the signature Operation. Unified Modeling Language 2.5.1 reply-message-label, Message, Message::messageSort, MessageSort, MessageSort::reply, ExecutionOccurence, Operation, Behavior::ownedParameter
INFO If the identity of a reply Message is obvious (e.g., when its sendEvent is the only reply within the extent of an ExecutionOccurence where there is only one receipt of an Operation call message), the label may be omitted to simplify the diagram. Unified Modeling Language 2.5.1 reply-message-label, Message, Message::messageSort, MessageSort, MessageSort::reply, ExecutionOccurence, Operation
INFO If an output-argument does not have an explicit assignment-target specified, it is considered to have an unknown assignment target. In this case, it is required to include a value-specification, which denotes the returned value for the argument. Unified Modeling Language 2.5.1 reply-message-label, Message, Message::messageSort, MessageSort, MessageSort::reply, ValueSpecification
INFO An output-argument with an explicit assignment-target given may also optionally include a value-specification. If a value-specification is given, then this denotes the returned value for the argument. Otherwise the argument has no modeled returned value Unified Modeling Language 2.5.1 reply-message-label, Message, Message::messageSort, MessageSort, MessageSort::reply, ValueSpecification
INFO Note that the parentheses are not considered part of the output-argument list, so a reply-message-label without an output-argument-list may still optionally include an empty set of parentheses (“()”) after the message-name. Unified Modeling Language 2.5.1 reply-message-label, Message, Message::messageSort, MessageSort, MessageSort::reply, ValueSpecification, Operation, Parameter, Behavior::ownedParameter
INFO If a reply-message-label does not include an output-argument-list and the Message has a signature, then this denotes that the Message has wildcard arguments corresponding to all out and inout ownedParameters of the signature Operation (if any). Unified Modeling Language 2.5.1 reply-message-label, Message, Message::messageSort, MessageSort, MessageSort::reply, ValueSpecification, Operation, Parameter, Behavior::ownedParameter
INFO An output-argument always explicitly names the parameter to which it is to be matched. Any parameters that are not named are considered to have implicit wildcard arguments. (There is thus no need for an explicit wildcard notation for output-arguments.) Unified Modeling Language 2.5.1 reply-message-label, Message, Message::messageSort, MessageSort, MessageSort::reply, ValueSpecification, Operation, ParameterDirectionKind::return, Parameter
INFO If a reply Message does not have a signature, then the only argument that may be specified for it is a return argument as specified above. However, if the Message has a signature that is an Operation with out or inout ownedParameters, then ... Unified Modeling Language 2.5.1 reply-message-label, Message, Message::messageSort, MessageSort, MessageSort::reply, ValueSpecification, Operation, ParameterDirectionKind::return, Parameter
INFO If a reply Message does not have a signature, then the only argument that may be specified for it is a return argument as specified above. Unified Modeling Language 2.5.1 reply-message-label, Message, Message::messageSort, MessageSort, MessageSort::reply, ValueSpecification, Operation, ParameterDirectionKind::return, Parameter
INFO If the Message has a signature without a return parameter, then no assignment-target or value-specification may be given for the reply-message-label as a whole. Unified Modeling Language 2.5.1 reply-message-label, Message, Message::messageSort, MessageSort, MessageSort::reply, ValueSpecification, Operation, ParameterDirectionKind::return, Parameter
INFO If the Message has a signature that is an Operation with a return parameter, then this assignment-target and/or value-specification corresponds to the argument for that parameter (if no assignment-target is given, it is considered to be unknown). Unified Modeling Language 2.5.1 reply-message-label, Message, Message::messageSort, MessageSort, MessageSort::reply, ValueSpecification, Operation, ParameterDirectionKind::return, Parameter
INFO A reply-message-label may optionally have an assignment-target given to the left of the message-name, with a corresponding returned value denoted by the optional value-specification given after a colon at the end of the reply-message-label. Unified Modeling Language 2.5.1 reply-message-label, Message, Message::messageSort, MessageSort, MessageSort::reply, ValueSpecification
INFO If the Message has a signature, this will be the name of the Operation referenced by the signature (which should be the Operation for whose call this is a reply). Otherwise the name is unconstrained. Unified Modeling Language 2.5.1 reply-message-label, Message, Message::messageSort, MessageSort, MessageSort::reply, Message::signature, Operation
INFO The message-name appearing in a reply-message-label is the name property of the Message. Unified Modeling Language 2.5.1 reply-message-label, Message, Message::messageSort, MessageSort, MessageSort::reply
INFO A reply-message-label is used for reply Messages. It has the following form ... Unified Modeling Language 2.5.1 reply-message-label, Message, Message::messageSort, MessageSort, MessageSort::reply
INFO Note that the parentheses are not considered part of the input-argument list, so a request-message-label without an input-argument-list may still optionally include an empty set of parentheses (“()”) after the message-name. Unified Modeling Language 2.5.1 request-message-label, Message, Message::messageSort, MessageSort, Operation, Signal, Parameter, BehavioralFeature::ownedParameterSet, message-name
INFO If a request-message-label does not include an input-argument-list and the Message has a signature, then this denotes that the Message has wildcard arguments corresponding to all in and inout ownedParameters of an Operation or attributes of a Signal ... Unified Modeling Language 2.5.1 request-message-label, Message, Message::messageSort, MessageSort, Operation, Signal, Parameter, BehavioralFeature::ownedParameterSet
INFO Message::signature : NamedElement [0..1] ... The signature of the Message is the specification of its content. It refers either an Operation or a Signal. Unified Modeling Language 2.5.1 Message, Message::signature, NamedElement, NamedElement::name, Operation, Signal
NOTATION On Communication Diagrams, the Messages are decorated by a small arrow in the direction of the Message close to the Message name and sequence number along the line between the lifelines ... OMG Systems Modeling Language (SysML) 1.6 Message, MessageEnd, Communication Diagram, Lifeline
NOTATION A found Message is denoted with a small black circle at the starting end of the Message. OMG Systems Modeling Language (SysML) 1.6 Message, MessageEnd, found Message
NOTATION A lost Message is denoted with a small black circle at the arrow end of the Message. OMG Systems Modeling Language (SysML) 1.6 Message, MessageEnd, lost Message
NOTATION An object deletion Message (messageSort equals deleteMessage) must end in a DestructionOccurrenceSpecification. OMG Systems Modeling Language (SysML) 1.6 Message, MessageEnd, Message::messageSort, MessageSort, MessageSort::deleteMessage, DestructionOccurrenceSpecification
NOTATION An object creation Message (messageSort equals createMessage) has a dashed line with an open arrow head. OMG Systems Modeling Language (SysML) 1.6 Message, MessageEnd, Message::messageSort, MessageSort, MessageSort::createMessage
NOTATION A reply Message (messageSort equals reply) has a dashed line with either an open or filled arrow head. OMG Systems Modeling Language (SysML) 1.6 Message, MessageEnd, Message::messageSort, MessageSort, MessageSort::reply
NOTATION A synchronous Message (messageSort equals synchCall) has a filled arrow head. OMG Systems Modeling Language (SysML) 1.6 Message, MessageEnd, Message::messageSort, MessageSort, MessageSort::synchCall
NOTATION An asynchronous Message (messageSort equals asynchCall or asynchSignal) has an open arrow head. OMG Systems Modeling Language (SysML) 1.6 Message, MessageEnd, Message::messageSort, MessageSort, MessageSort::asynchCall, MessageSort::asynchSignal
NOTATION The form of the line or arrowhead reflects properties of the message OMG Systems Modeling Language (SysML) 1.6 Message, MessageEnd
NOTATION The send and receive events may both be on the same lifeline. OMG Systems Modeling Language (SysML) 1.6 Message, MessageEnd
NOTATION 17.4.4.1 Message - A message is shown as a line from the sender MessageEnd to the receiver MessageEnd. The line must be such that every line fragment is either horizontal or downwards when traversed from send event to receive event. OMG Systems Modeling Language (SysML) 1.6 Message, MessageEnd
EXAMPLE, INFO Figure D.9 shows a “black box” interaction, but references “StartVehicleWhiteBox” (Figure D.10), which will decompose the lifelines within the context of the HybridSUV block. OMG Systems Modeling Language (SysML) 1.6 Interaction, Sequence Diagram, Lifeline, interactionOperator ref HSUV sample problem, Block
INFO «Refine» Abstraction Specifies a refinement relationship between model elements at different semantic levels, such as analysis and design. The mapping specifies the relationship between the two elements or sets of elements. The mapping ... Unified Modeling Language 2.5.1 Refine, Stereotype, UML StandardProfile
EXAMPLE, INFO This diagram expresses only the nominal states. Exception states, like “acceleratorFailure,” are not expressed on this diagram. OMG Systems Modeling Language (SysML) 1.6 State, StateMachine, StateMachine Diagram HSUV sample problem black box, Object Constraint Language
EXAMPLE, INFO Also note that this state machine refines the requirement “PowerSourceManagment,” which will be elaborated in the requirements sub clause of this sample problem. OMG Systems Modeling Language (SysML) 1.6 State, StateMachine, StateMachine Diagram, Requirement HSUV sample problem black box, Object Constraint Language
EXAMPLE, INFO Note that this state machine was developed in conjunction with the DriveBlackBox interaction in Figure D.7. OMG Systems Modeling Language (SysML) 1.6 State, StateMachine, StateMachine Diagram, Interaction HSUV sample problem black box, Object Constraint Language
EXAMPLE, INFO Figure D.8 depicts the operational states of the HSUV block, via a State Machine named “HSUVOperationalStates.” OMG Systems Modeling Language (SysML) 1.6 State, StateMachine, StateMachine Diagram HSUV sample problem black box, Object Constraint Language
INFO The operation oclIsInState(s) results in true if the object is in the state s. Possible states for the operation oclIsInState(s) are all states of the statemachine that defines the classifier's behavior. For nested states the statenames can be combined... Object Constraint Language Version 2.4 State, Classifier, StateMachine Object Constraint Language
EXAMPLE, INFO The conditions for each alternative in the alt controlSpeed sub clause are expressed in OCL, and relate to the states of the HybridSUV block, as shown in Figure D.8. OMG Systems Modeling Language (SysML) 1.6 State HSUV sample problem black box, Object Constraint Language