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
NOTATION An ItemFlow describes the flow of items across a connector or an association. The notation of an item flow is a black arrowhead on the connector or association. The arrowhead is towards the target element. OMG Systems Modeling Language (SysML) 1.6 Connector, Association ItemFlow
CONSTRAINT FlowProperty::1_restricted_types A FlowProperty shall be typed by a ValueType, Block, or Signal. OMG Systems Modeling Language (SysML) 1.6 Signal FlowProperty, ValueType, Block
INFO The itemProperty attribute has no values if the item flow is realized by an Association. OMG Systems Modeling Language (SysML) 1.6 InformationFlow ItemFlow, ItemFlow::itemProperty
INFO ItemFlow::itemProperty : Property [0..1] An optional property that relates the flowing item to the instances of the connectors enclosing block. This property is applicable only for item flows realized by connectors. The itemProperty attribute has no ... OMG Systems Modeling Language (SysML) 1.6 InformationFlow ItemFlow, ItemFlow::itemProperty
INFO The target flow property type shall be the same as, or a generalization of, a classifier of the item flow or the source flow property type, whichever is more specialized. OMG Systems Modeling Language (SysML) 1.6 InformationFlow ItemFlow
INFO Each classifier of conveyed items on an item flow shall be the same as, a specialization of, or a generalization of at least one flow property type on each end of the connected block usages (or their accessible nested block usages recursively, ... OMG Systems Modeling Language (SysML) 1.6 InformationFlow ItemFlow
INFO, NOTATION Item flows on connectors shall be compatible with flow properties of the blocks usages at each end of the connector, if any. The direction of the item flow shall be compatible with the direction of flow specified by the flow properties. OMG Systems Modeling Language (SysML) 1.6 InformationFlow ItemFlow
INFO, NOTATION Item properties are owned by the common (possibly indirect) owner of the source and target of the item flow, rather than by the source and target types, as flow properties are. OMG Systems Modeling Language (SysML) 1.6 InformationFlow ItemFlow
INFO, NOTATION For example, a label of "liquid: Water" means Water items might flow and these items are the values of the property "liquid," i.e., the values of the "liquid" item property are the instances of Water flowing at any given time. OMG Systems Modeling Language (SysML) 1.6 InformationFlow ItemFlow
INFO, NOTATION In addition, if the item flow identifies an item property, then one can label the item flow with the item property. OMG Systems Modeling Language (SysML) 1.6 InformationFlow ItemFlow
INFO, NOTATION One can label an ItemFlow with the classifiers of the items that may be conveyed. For example: a label Water would imply that instances of Water might be transmitted over this ItemFlow. OMG Systems Modeling Language (SysML) 1.6 InformationFlow ItemFlow
INFO To signify that only water flows between the pump and the tank, we can specify an ItemFlow of type Water on the connector. OMG Systems Modeling Language (SysML) 1.6 InformationFlow ItemFlow, FlowProperty, FlowDirectionKind::in, FlowDirectionKind::out, FlowDirectionKind
INFO For example, a pump connected to a tank: the pump has an "out" flow property of type Liquid and the tank has an "in" FlowProperty of type Liquid. OMG Systems Modeling Language (SysML) 1.6 InformationFlow ItemFlow, FlowProperty, FlowDirectionKind::in, FlowDirectionKind::out, FlowDirectionKind
INFO An ItemFlow describes the flow of items across a connector or an association. It may constrain the item exchange between blocks, block usages, or ports as specified by their flow properties. OMG Systems Modeling Language (SysML) 1.6 InformationFlow ItemFlow
NOTATION The label of any compartment shown on the property box that displays contents belonging to the type of the property is shown with a colon character (“:”) preceding the compartment label. The compartment name is otherwise the same as it would appear on ... OMG Systems Modeling Language (SysML) 1.6 compartment property compartment, SysML Internal Block Diagram, IBD :features compartments, :values compartment, :parts compartment, :properties compartment, :references compartment, :flow properties compartment, :operations compartment
NOTATION All features shown within these compartments shall match those of the block or value type that types the property. OMG Systems Modeling Language (SysML) 1.6 compartment property compartment, SysML Internal Block Diagram, IBD :features compartments, :values compartment, :parts compartment, :properties compartment, :references compartment, :flow properties compartment, :operations compartment
NOTATION SysML permits any property shown on an internal block diagram to also show compartments within the property box. These compartments may be given standard or user-customized labels just as on block definitions. OMG Systems Modeling Language (SysML) 1.6 compartment property compartment, SysML Internal Block Diagram, IBD :features compartments, :values compartment, :parts compartment, :properties compartment, :references compartment, :flow properties compartment, :operations compartment
INFO For example, the ports supporting torque flows in the transmission example might have nested ports for physical links to the engine or the driveshaft. OMG Systems Modeling Language (SysML) 1.6 Port nested Port
INFO Ports nest other ports in the same way that blocks nest other blocks. The type of the port is a block (or one of its specializations) that also has ports. OMG Systems Modeling Language (SysML) 1.6 Port nested Port
INFO For example, a block might provide particular services to other blocks as operations, or have a particular geometry accessible to other block, or it might require services and geometries of other blocks. OMG Systems Modeling Language (SysML) 1.6 Feature, Operation, Reception, Property DirectedFeature, FeatureDirectionKind, FeatureDirectionKind::provided, FeatureDirectionKind::required, FeatureDirectionKind::providedrequired, value property
INFO Required and provided features are operations, receptions, and non-flow properties that a block supports for other blocks to use, or requires other blocks to support for its own use, or both. OMG Systems Modeling Language (SysML) 1.6 Feature, Operation, Reception, Property DirectedFeature, FeatureDirectionKind, FeatureDirectionKind::provided, FeatureDirectionKind::required, FeatureDirectionKind::providedrequired, value property
INFO For example, a block specifying a car’s automatic transmission could have a flow property for Torque as an input, and another flow property for Torque as an output. OMG Systems Modeling Language (SysML) 1.6 FlowProperty
NOTATION 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 FlowProperty, FlowProperty::direction, FlowDirectionKind, FlowDirectionKind::in, FlowDirectionKind::inout, FlowDirectionKind::out
NOTATION Directed features can appear in compartments for the various kinds of properties and behavioral features. OMG Systems Modeling Language (SysML) 1.6 compartment, Property, BehavioralFeature DirectedFeature, DirectedFeature::featureDirection, FeatureDirectionKind, FeatureDirectionKind::provided, FeatureDirectionKind::providedrequired, FeatureDirectionKind::required
NOTATION A DirectedFeature has the same notation as other non-flow properties and behavioral features with a feature direction prefix (prov | reqd | provreqd), which corresponds to one the FeatureDirectionKind literals “provided,” “required,” and “providedrequired OMG Systems Modeling Language (SysML) 1.7beta1 DirectedFeature, DirectedFeature::featureDirection, FeatureDirectionKind, FeatureDirectionKind::provided, FeatureDirectionKind::providedrequired, FeatureDirectionKind::required
INFO Provided behavioral features are invoked with the owning block as target, while required behavioral features are invoked with an external block as target (required). OMG Systems Modeling Language (SysML) 1.6 Feature, BehavioralFeature, Operation, Reception DirectedFeature, FeatureDirectionKind::provided, FeatureDirectionKind::required, block property, value property, MD:ValueProperty, Block
INFO Provided non-flow properties are read and written on the owning block, while required non-flow properties are read or written on an external block OMG Systems Modeling Language (SysML) 1.6 Property, Feature DirectedFeature, FeatureDirectionKind::provided, FeatureDirectionKind::required, block property, value property, MD:ValueProperty
INFO Using non-flow properties means to read or write them, and using behavioral features means to invoke them. OMG Systems Modeling Language (SysML) 1.6 Property, BehavioralFeature, Operation, Reception DirectedFeature, FeatureDirectionKind::required, value property, block property
INFO (the owning block for features on types of proxy ports is the type of the block usage the proxy port is standing in for, which might be an internal part). OMG Systems Modeling Language (SysML) 1.6 DirectedFeature, ProxyPort
INFO [SysML1.6: PREFER SysML1.7] A DirectedFeature indicates whether the feature is supported by the owning block (provided), or is to be supported by other blocks for the owning block to use (required), or both ... OMG Systems Modeling Language (SysML) 1.6 DirectedFeature, FeatureDirectionKind::provided, FeatureDirectionKind::required, FeatureDirectionKind::providedrequired, FeatureDirectionKind
INFO ~InterfaceBlock::original : InterfaceBlock [1] The InterfaceBlock that this is a conjugation of. OMG Systems Modeling Language (SysML) 1.6 InterfaceBlock, ~InterfaceBlock::original, ~InterfaceBlock
INFO Conjugation is specified by a constraint giving the features of ~InterfaceBlocks according to those of their original InterfaceBlocks ... It is expected that tools conforming to this specification automatically create features of ~InterfaceBlocks. OMG Systems Modeling Language (SysML) 1.6 InterfaceBlock, ~InterfaceBlock, conjugation, ~InterfaceBlock::original, DirectedFeature, FlowProperty, FlowProperty::direction, FlowDirectionKind, DirectedFeature::featureDirection, FeatureDirectionKind, FlowDirectionKind::in, FlowDirectionKind::out, FeatureDirectionKind::provided, FeatureDirectionKind::providedrequired
INFO InterfaceBlock ... for example, in flow properties are conjugated as out flow properties and provided features are conjugated as required features. OMG Systems Modeling Language (SysML) 1.6 InterfaceBlock, ~InterfaceBlock, conjugation, ~InterfaceBlock::original, DirectedFeature, FlowProperty, FlowProperty::direction, FlowDirectionKind, DirectedFeature::featureDirection, FeatureDirectionKind, FlowDirectionKind::in, FlowDirectionKind::out, FeatureDirectionKind::provided, FeatureDirectionKind::providedrequired
INFO The ~InterfaceBlock stereotype (shall be pronounced: "conjugated interface block") is a specialization of InterfaceBlock that has the same features as its original InterfaceBlock except that its DirectedFeatures and FlowProperties are reversed (conjugated OMG Systems Modeling Language (SysML) 1.6 InterfaceBlock, ~InterfaceBlock, conjugation, ~InterfaceBlock::original, DirectedFeature, FlowProperty, FlowProperty::direction, FlowDirectionKind, DirectedFeature::featureDirection, FeatureDirectionKind
INFO Then it is delivered to a factory, reclassified from a warehouse item to a factory resource (while still being a machine), and records the percentage of time it is operating. OMG Systems Modeling Language (SysML) 1.6 Classifier, Stereotype, Property PropertySpecificType
INFO At first it is not an item or resource and is classified only as a machine. Before delivery to the factory, a new machine is stored in a warehouse, classified additionally as a warehouse item, and is assigned a storage location. OMG Systems Modeling Language (SysML) 1.6 Classifier, Stereotype, Property PropertySpecificType
INFO Figure 8-23 shows the classification of a particular machine over time, identified by its serial number. OMG Systems Modeling Language (SysML) 1.6 Classifier, Stereotype, Property PropertySpecificType
INFO The properties disappear once an item leaves a warehouse or a resource is no longer used in a factory, because they are declassified as WarehouseItems and FactoryResources at that time, respectively. OMG Systems Modeling Language (SysML) 1.6 Classifier, Stereotype, Property PropertySpecificType
INFO The properties appear when an item arrives in a warehouse or a resource is used in a factory, because they are classified as WarehouseItems and FactoryResources at that time, respectively OMG Systems Modeling Language (SysML) 1.6 Classifier, Stereotype, Property PropertySpecificType
INFO Items in warehouses are assigned a location, while resources in factories indicate own much they are being used as a percentage of time. Only objects that are items in warehouses or resources in factories have these location and utilization properties. OMG Systems Modeling Language (SysML) 1.6 Classifier, Stereotype, Property PropertySpecificType
INFO Figure 8-22 shows property-specific types in a model of facilities that includes factories and warehouses. Items flow through facilities, while resources operate on items. OMG Systems Modeling Language (SysML) 1.6 Classifier, Stereotype, Property PropertySpecificType
INFO The PropertySpecificType stereotype can be applied to classifiers that type exactly one property and that are owned by the owner of that property. Classifiers with this stereotype applied shall be generalized by at most one other classifier. OMG Systems Modeling Language (SysML) 1.6 Classifier, Stereotype, Property PropertySpecificType
EXAMPLE, INFO The Verify relationship is shown on Figure 16-7 using callout notation anchored to the diagram frame, which indicates that the BurnishTest test case verifies the Burnish requirement. OMG Systems Modeling Language (SysML) 1.6 callout, StateMachine HSUV sample problem, SysML specification figure, Requirement, TestCase, Verify requirements engineering, test engineering
EXAMPLE, INFO Figure 17-1 [Figure 16-7] is a state machine diagram of the BurnishTest test case, which expresses the textual sequence and criteria of the Burnish requirement in state machine form. OMG Systems Modeling Language (SysML) 1.6 callout, StateMachine HSUV sample problem, SysML specification figure, Requirement, TestCase requirements engineering, test engineering
EXAMPLE, INFO The Burnish requirement is shown as having a Verify relationship to the BurnishTest test case using callout notation on the diagram, indicating that the Burnish requirement is verified by the BurnishTest test case. OMG Systems Modeling Language (SysML) 1.6 callout HSUV sample problem, SysML specification figure, Requirement, Verify, AbstractRequirement::/verifiedBy, TestCase requirements engineering, test engineering
EXAMPLE, INFO The example in Figure 16-6 is taken from the automotive safety domain, and shows a Burnish requirement contained in the NHTSASafetyRequirements requirement. Note that the text of the Burnish requirement indicates a specific sequence of steps and transitio OMG Systems Modeling Language (SysML) 1.6 HSUV sample problem, SysML specification figure, Requirement, AbstractRequirement::text requirements engineering
CONSTRAINT TestCase::1_return_verdictkind The type of return parameter of the stereotyped model element shall be VerdictKind. (note this is consistent with the UML Testing Profile). OMG Systems Modeling Language (SysML) 1.6 UML Testing Profile TestCase, Requirement, VerdictKind, VerdictKind::pass, VerdictKind::fail, VerdictKind::inconclusive, VerdictKind::error requirements engineering, test engineering
INFO A test case is a method for verifying a requirement is satisfied. OMG Systems Modeling Language (SysML) 1.6 TestCase, Requirement, Verify, Satisfy, VerdictKind::pass, VerdictKind::fail, VerdictKind::inconclusive, VerdictKind::error requirements engineering, test engineering
EXAMPLE, INFO Figure 16-5 illustrates the use of the Copy dependency to allow a single requirement to be reused in several requirements hierarchies. The master tag provides a textual reference to the reused requirement. OMG Systems Modeling Language (SysML) 1.6 Dependency, Dependency::client, Dependency::supplier Copy, Requirement
CONSTRAINT Copy::2_same_text The text property of the client requirement is constrained to be a read-only copy of the text property of the supplier requirement and this applies recursively to all subrequirements OMG Systems Modeling Language (SysML) 1.6 Dependency, Dependency::client, Dependency::supplier Requirement, Copy, AbstractRequirement::text, AbstractRequirement::id
CONSTRAINT Copy::1_source_and_taget_are_requirements A Copy dependency may only be created between two NamedElements that have a subtype of the abstractRequirement stereotype applied OMG Systems Modeling Language (SysML) 1.6 Dependency, Dependency::client, Dependency::supplier Requirement, Copy, AbstractRequirement::text, AbstractRequirement::id
CONSTRAINT When a Copy dependency exists between two requirements, the requirement text of the client requirement is a read-only copy of the requirement text of the requirement at the supplier end of the dependency. OMG Systems Modeling Language (SysML) 1.6 Dependency, Dependency::client, Dependency::supplier Requirement, Copy, AbstractRequirement::text, AbstractRequirement::id
INFO A Copy dependency created between two requirements maintains a master/slave relationship between the two elements for the purpose of requirements re-use in different contexts OMG Systems Modeling Language (SysML) 1.6 Dependency, Dependency::client, Dependency::supplier Requirement, Copy, AbstractRequirement::text, AbstractRequirement::id
INFO A Copy relationship is a dependency between a supplier requirement and a client requirement that specifies that the text of the client requirement is a read-only copy of the text of the supplier requirement. OMG Systems Modeling Language (SysML) 1.6 Dependency, Dependency::client, Dependency::supplier Requirement, Copy, AbstractRequirement::text, AbstractRequirement::id
INFO Satisfy::getSatisfies (in ref : NamedElement) : AbstractRequirement [0..*] OMG Systems Modeling Language (SysML) 1.6 Dependency, Dependency::supplier Requirement, Satisfy, AbstractRequirement, Satisfy::getSatisfies(in ref) requirements engineering, requirements analysis
CONSTRAINT Satisfy::1_supplier_is_requirement The supplier shall be an element stereotyped by any subtype of «AbstractRequirement». OMG Systems Modeling Language (SysML) 1.6 Dependency, Dependency::supplier Requirement, Satisfy, AbstractRequirement::/satisfiedBy, AbstractRequirement requirements engineering, requirements analysis
INFO As with other dependencies, the arrow direction points from the satisfying (client) model element to the (supplier) requirement that is satisfied. OMG Systems Modeling Language (SysML) 1.6 Dependency, Dependency::client, Dependency::supplier Requirement, Satisfy, AbstractRequirement::/satisfiedBy requirements engineering, requirements analysis
INFO A Satisfy relationship is a dependency between a requirement and a model element that fulfills the requirement. OMG Systems Modeling Language (SysML) 1.6 Dependency Requirement, Satisfy, AbstractRequirement::/satisfiedBy requirements engineering, requirements analysis
EXAMPLE, INFO The diagram in Figure 16-3 shows derived requirements and refers to the design elements that satisfy them. The rationale is also shown as a basis for the design solution. OMG Systems Modeling Language (SysML) 1.6 Requirement, DeriveReqt, Rationale, SysML specification figure
CONSTRAINT DeriveReqt::2_client_is_requirement The client shall be an element stereotyped by a subtype of AbstractRequirement. OMG Systems Modeling Language (SysML) 1.6 Dependency, Dependency::client DeriveReqt, Requirement
CONSTRAINT DeriveReqt::1_supplier_is_requirement The supplier shall be an element stereotyped by a subtype of AbstractRequirement. OMG Systems Modeling Language (SysML) 1.6 Dependency, Dependency::supplier DeriveReqt, Requirement
INFO, NOTATION As with other dependencies, the arrow direction points from the derived (client) requirement to the (supplier) requirement from which it is derived. OMG Systems Modeling Language (SysML) 1.6 Dependency, Dependency::client, Dependency::supplier DeriveReqt, Requirement
INFO For example, a system requirement may be derived from a business need, or lower-level requirements may be derived from a system requirement. OMG Systems Modeling Language (SysML) 1.6 DeriveReqt, Requirement system requirement, business requirement
INFO A DeriveReqt relationship is a dependency between two requirements in which a client requirement can be derived from the supplier requirement. OMG Systems Modeling Language (SysML) 1.6 Dependency, Dependency::client, Dependency::supplier DeriveReqt, Requirement
EXAMPLE, INFO The diagram in Figure 16-2 shows an example of a compound requirement decomposed into multiple subrequirements. OMG Systems Modeling Language (SysML) 1.6 SysML specification figure, Requirement, composite (compound) requirement
EXAMPLE, INFO The allocation table can also be shown using a sparse matrix style as in the following example shown in Figure 15-9. OMG Systems Modeling Language (SysML) 1.6 HSUV sample problem, «allocate», Allocate
EXAMPLE, INFO The table shown in Figure D.40 is provided as a specific example of how the «allocate» dependency may be depicted in tabular form, consistent with the automotive example above. OMG Systems Modeling Language (SysML) 1.6 HSUV sample problem, «allocate», Allocate
EXAMPLE, INFO The need also arises, when adding detail to a structural model, to allocate a connector (at a more abstract level) to a part (at a more concrete level). OMG Systems Modeling Language (SysML) 1.6 Connector, part Allocate, «allocate», structural allocation, Block, part property
EXAMPLE, INFO For example, if a particular user model includes an abstract logical structure, it may be important to show how these model elements are allocated to a more concrete physical structure. OMG Systems Modeling Language (SysML) 1.6 Connector, part Allocate, «allocate», structural allocation, Block, part property
EXAMPLE, INFO Systems engineers have frequent need to allocate structural model elements (e.g., blocks, parts, or connectors) to other structural elements. OMG Systems Modeling Language (SysML) 1.6 Connector, part Allocate, «allocate», structural allocation, Block, part property systems engineering, Model-Based Systems Engineering
EXAMPLE, INFO Allocation of ControlFlow is not shown as an example, but it is not prohibited in SysML. OMG Systems Modeling Language (SysML) 1.6 ControlFlow SysML specification figure, Allocate
EXAMPLE, INFO Figure 15-5 shows flow allocation of [an] ObjectFlow to a Connector, or alternatively to an ItemFlow. OMG Systems Modeling Language (SysML) 1.6 ObjectFlow, Connector SysML specification figure, Allocate, ItemFlow
EXAMPLE, INFO The allocation to Activity6 comes from a nested part, and uses the attributes of DirectedRelationshipPropertyPath to specify the path of properties to reach that part. The sourceContext of the allocation is Block4 and the sourcePropertyPath is (Part5). OMG Systems Modeling Language (SysML) 1.6 Behavior, Action, part behavior allocation, SysML specification figure, Allocate, part property, MD:PartProperty, AllocateActivityPartition functional allocation
EXAMPLE, INFO Note that the AllocateActivityPartition, if used in this manner, is unambiguously associated with behavior allocation. OMG Systems Modeling Language (SysML) 1.6 Behavior, Action, part behavior allocation, SysML specification figure, Allocate, part property, MD:PartProperty, AllocateActivityPartition functional allocation
EXAMPLE, INFO Specific behavior allocation of Actions to Parts are depicted in Figure 15-4. OMG Systems Modeling Language (SysML) 1.6 Behavior, Action, part behavior allocation, SysML specification figure, Allocate, part property, MD:PartProperty functional allocation
INFO AllocateActivityPartition is used to depict an «allocate» relationship on an Activity diagram. The AllocateActivityPartition is a standard UML::ActivityPartition, with modified constraints... OMG Systems Modeling Language (SysML) 1.6 ActivityPartition AllocateActivityPartition
INFO State machines in block definition diagrams can also appear with the same notation as submachine states. OMG Systems Modeling Language (SysML) 1.6 StateMachine, submachine, State::/isSubmachineState SysML Block Definition Diagram
INFO Properties with AdjunctProperty applied, where the principal of the AdjunctProperty is a parameter of the state machine, can be used as the end of the associations towards the parameter type. OMG Systems Modeling Language (SysML) 1.6 StateMachine, Association, Parameter SysML Block Definition Diagram, AdjunctProperty, AdjunctProperty::principal
INFO Properties with AdjunctProperty applied, where the principal of the AdjunctProperty is a submachine state, can be used as the end of the associations towards the sub state machine. OMG Systems Modeling Language (SysML) 1.6 StateMachine, Association, submachine SysML Block Definition Diagram, AdjunctProperty, AdjunctProperty::principal
INFO State machines in block definition diagrams appear as regular blocks, except the «stateMachine» keyword may be used to indicate the Block stereotype is applied to a state machine, as shown in Figure 13-1. OMG Systems Modeling Language (SysML) 1.6 StateMachine, «keyword» SysML Block Definition Diagram, «stateMachine»
EXAMPLE, INFO Figure D.10 shows the sequence of communication that occurs inside the HybridSUV when the vehicle is started successfully. OMG Systems Modeling Language (SysML) 1.6 Interaction SysML Sequence Diagram, HSUV sample problem
EXAMPLE, INFO The “hybridSUV” lifeline represents another interaction which further elaborates what happens inside the “hybridSUV” when the vehicle is started. OMG Systems Modeling Language (SysML) 1.6 Interaction, Event, Message, Lifeline SysML Sequence Diagram
EXAMPLE, INFO Figure D.9 shows an interaction that includes events and messages communicated between the driver and vehicle during the starting of the vehicle. OMG Systems Modeling Language (SysML) 1.6 Interaction, Event, Message SysML Sequence Diagram
EXAMPLE, INFO CombinedFragments are used to illustrate that steering can take place at the same time as controlling the speed and that controlling speed can be either idling, accelerating/cruising, or braking. OMG Systems Modeling Language (SysML) 1.6 interactionOperator ref, Interaction, CombinedFragment SysML Sequence Diagram
EXAMPLE, INFO To manage the complexity, a hierarchical sequence diagram is used which refers to other interactions that further elaborate the system behavior (“ref StartVehicleBlackBox”). OMG Systems Modeling Language (SysML) 1.6 interactionOperator ref SysML Sequence Diagram
EXAMPLE, INFO Figure D.7 illustrates the overall system behavior for operating the vehicle in Sequence diagram format. OMG Systems Modeling Language (SysML) 1.6 SysML Sequence Diagram, HSUV sample problem
EXAMPLE Interactions in block definition diagrams can also appear with the same notation as InteractionUses. OMG Systems Modeling Language (SysML) 1.6 Interaction, Association, Parameter, InteractionUse SysML Block Definition Diagram
EXAMPLE Properties with AdjunctProperty applied, where the principal of the AdjunctProperty is a parameter of the interaction, can be used as the end of the associations towards the parameter type. OMG Systems Modeling Language (SysML) 1.6 Interaction, Association, Parameter «interaction», SysML Block Definition Diagram, AdjunctProperty
EXAMPLE Properties with AdjunctProperty applied, where the principal of the AdjunctProperty is an interaction use, can be used as the end of the associations towards the interaction being used. OMG Systems Modeling Language (SysML) 1.6 Interaction, Property, Association, Association::memberEnd «interaction», SysML Block Definition Diagram, AdjunctProperty
EXAMPLE Interactions in block definition diagrams appear as regular blocks, except the «interaction» keyword may be used to indicate the Block stereotype is applied to an interaction, as shown in Figure 12-1 OMG Systems Modeling Language (SysML) 1.6 Interaction «interaction», SysML Block Definition Diagram
EXAMPLE, INFO In an instance of Operating Car, which is one execution of it, instances of Brake Pressure and Modulation Frequency are linked to the execution instance when they are in the object nodes of the activity. OMG Systems Modeling Language (SysML) 1.6 AggregationKind::composite, Association, Activity, ObjectNode «activity», SysML specification figure, AdjunctProperty
EXAMPLE, INFO Figure 11-14 shows a block definition diagram with composition associations between the activity in Figure 11-10 and the types the object nodes in that activity, with AdjunctProperty applied to the object node type end. OMG Systems Modeling Language (SysML) 1.6 AggregationKind::composite, Association, Activity, ObjectNode «activity», SysML specification figure, AdjunctProperty
CONSTRAINT 2_same_name Properties to which AdjunctProperty [is] applied shall have the same name as the principal, if the principal is a NamedElement. OMG Systems Modeling Language (SysML) 1.6 NamedElement::name AdjunctProperty, AdjunctProperty::principal
EXAMPLE, INFO Like all composition, if an instance of Operating Car is destroyed, terminating the execution, the executions it owns are also terminated. OMG Systems Modeling Language (SysML) 1.6 AggregationKind::composite, Association AdjunctProperty, SysML Block Definition Diagram
EXAMPLE, INFO Each instance of Operating Car is an execution of that behavior. It owns the executions of the behaviors it invokes synchronously, such as Driving. OMG Systems Modeling Language (SysML) 1.6 AggregationKind::composite, Association AdjunctProperty, SysML Block Definition Diagram
EXAMPLE, INFO Figure 11-13 shows a block definition diagram with composition associations between the activities and AdjunctProperty applied to the part ends in Figures 11.10, 11.11, and 11.12, as an alternative way to show the activity decomposition of Figures ... OMG Systems Modeling Language (SysML) 1.6 AggregationKind::composite, Association AdjunctProperty, SysML Block Definition Diagram
EXAMPLE, INFO The edges coming out of the decision node indicate the probability of each branch being taken. OMG Systems Modeling Language (SysML) 1.6 Activity, DecisionNode, ActivityEdge::guard, ObjectFlow, ValueSpecificationAction Probability, Probability::probability
EXAMPLE, INFO The decision node and guards determine if the brake pressure is greater than zero, and flow is directed to value specification actions that output an enabling or disabling control value from the activity. OMG Systems Modeling Language (SysML) 1.6 Activity, DecisionNode, ActivityEdge::guard, ObjectFlow, ValueSpecificationAction ControlOperator, ControlValueKind::enable, ControlValueKind::disable
EXAMPLE, INFO The activity diagram for the control operator Enable on Brake Pressure > 0 is shown in Figure 11-12. OMG Systems Modeling Language (SysML) 1.6 Activity ControlOperator
EXAMPLE, INFO The result of Calculate Traction is filtered by a decision node for a threshold value and Calculate Modulation Frequency determines the output of the activity. OMG Systems Modeling Language (SysML) 1.6 DecisionNode, Activity, ActivityParameterNode SysML specification figure