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
SEMANTIC There are two kinds of ActivityEdges: Unified Modeling Language 2.5.1 Activity, ActivityEdge, ControlEdge, ObjectFlow
SEMANTIC InitialNodes are an exception to the rule that ControlNodes cannot “hold” tokens, but only manage their flow. Unified Modeling Language 2.5.1 Activity, InitialNode, ControlNode, control token, InitialNode
SEMANTIC The outgoing ActivityEdges of an InitialNode must all be ControlFlows. The control token placed on an InitialNode is offered concurrently on all outgoing ControlFlows. Unified Modeling Language 2.5.1 Activity, InitialNode, ControlNode, control token, ActivityEdge, ActivityNode::outgoing, ActivityNode::incoming
SEMANTIC An InitialNode shall not have any incoming ActivityEdges, which means the InitialNodes owned by an Activity will always be enabled when the Activity begins execution and a single control token is placed on each such InitialNode when Activity execution sta Unified Modeling Language 2.5.1 Activity, InitialNode, ControlNode, control token, ActivityEdge
INFO When an ExecutableNode completes an execution, the control token representing that execution is removed from the ExecutableNode and control tokens are offered on all outgoing ControlFlows of the ExecutableNode. That is, there is an implicit fork ... Unified Modeling Language 2.5.1 Behavior, Activity, Activity Diagram, ExecutableNode, implicit join, ControlFlow, ActivityNode::outgoing, token, control token, implicit fork
INFO In some cases, multiple concurrent executions of an ExecutableNode may be ongoing at one time (see the semantics of isLocallyReentrant=true for Actions ... ). In this case, the ExecutableNode holds one control token for each concurrent execution. Unified Modeling Language 2.5.1 Behavior, Activity, Activity Diagram, ExecutableNode, implicit join, ControlFlow, ActivityNode::incoming, token, control token
INFO While the ExecutableNode is executing, it is considered to hold a single control [token] indicating it is execution [executing]. Unified Modeling Language 2.5.1 Behavior, Activity, Activity Diagram, ExecutableNode, implicit join, ControlFlow, ActivityNode::incoming, token, control token
INFO The effect of object tokens accepted from ControlFlows is not specified (see isControlType for ObjectNodes ...), but the semantics above applies if the effect is to execute the ExecutableNode. Unified Modeling Language 2.5.1 Behavior, Activity, Activity Diagram, ExecutableNode, implicit join, ControlFlow, ActivityNode::incoming, token, object token, ObjectNode
INFO Before an ExecutableNode begins executing, it accepts all tokens offered on incoming ControlFlows. If multiple tokens are being offered on a ControlFlow, they are all consumed. Unified Modeling Language 2.5.1 Behavior, Activity, Activity Diagram, ExecutableNode, implicit join, ControlFlow, ActivityNode::incoming, token, control token, object token
INFO An ExecutableNode shall not execute until all incoming ControlFlows (if any) are offering tokens. That is, there is an implicit join on the incoming Control Flows. Specific kinds of ExecutableNodes may have additional prerequisites ... Unified Modeling Language 2.5.1 Behavior, Activity, Activity Diagram, ExecutableNode, implicit join, ControlFlow, ActivityNode::incoming, token
INFO An ExecutableNode may also consume and produce data, but it must do so through related ObjectNodes (Actions use Pins for this purpose ... Unified Modeling Language 2.5.1 Behavior, Activity, Activity Diagram, ExecutableNode, ActivityNode, ObjectNode, Action, Pin, InputPin, OutputPin
INFO An ExecutableNode is an ActivityNode that carries out a substantive behavioral step of the Activity that contains it. Unified Modeling Language 2.5.1 Behavior, Activity, Activity Diagram, ExecutableNode, ActivityNode, execution
INFO All concrete kinds of ExecutableNodes are Actions ... Unified Modeling Language 2.5.1 Behavior, Activity, Activity Diagram, ExecutableNode, ActivityNode, execution, Action
INFO Generally, the ControlNodes and ObjectNodes in an Activity are largely there to control the sequencing and to manage the flow of data between the ExecutableNodes of the Activity. Unified Modeling Language 2.5.1 Behavior, Activity, Activity Diagram, ExecutableNode, ActivityNode, execution, ControlNode, ObjectNode
INFO An ExecutableNode is a kind of ActivityNode that may be executed as a step in the overall desired behavior of the containing Activity. Unified Modeling Language 2.5.1 Behavior, Activity, Activity Diagram, ExecutableNode, ActivityNode, execution
NOTATION Transitions of the kind internal are not shown explicitly in diagrams. Unified Modeling Language 2.5.1 State, StateMachine, Transition, Vertex, TransitionKind, Transition::kind, TransitionKind::internal, Internal Transition compartment
INFO kind = internal ... This kind of Transition can only be defined if the source Vertex is a State. Unified Modeling Language 2.5.1 State, StateMachine, Transition, Transition::source, Vertex, TransitionKind, Transition::kind, TransitionKind::internal, Internal Transition compartment
INFO kind = internal is a special case of a local Transition that is a self-transition (i.e., with the same source and target States), such that the State is never exited (and, thus, not re-entered), which means that no exit or entry Behaviors are executed ... Unified Modeling Language 2.5.1 State, StateMachine, Transition, Transition::source, Vertex, TransitionKind, Transition::kind, TransitionKind::internal, Internal Transition compartment
INFO kind = local ... However, for local Transitions the target Vertex must be different from its source Vertex. A local Transition can only exist within a composite State. Unified Modeling Language 2.5.1 State, StateMachine, Transition, Transition::source, Vertex, TransitionKind, Transition::kind, TransitionKind::local, composite State, State::/isComposite
INFO kind = local is the opposite of external, meaning that the Transition does not exit its containing State (and, hence, the exit Behavior of the containing State will not be executed). ... Unified Modeling Language 2.5.1 State, StateMachine, Transition, Transition::source, Vertex, TransitionKind, Transition::kind, TransitionKind::local
INFO kind = external means that the Transition exits its source Vertex. If the Vertex is a State, then executing this Transition will result in the execution of any associated exit Behavior of that State. Unified Modeling Language 2.5.1 State, StateMachine, Transition, Transition::source, Vertex, TransitionKind, Transition::kind, TransitionKind::external
INFO The semantics of a Transition depend on its relationship to its source Vertex. Three different possibilities are defined, depending on the value of the Transition’s kind attribute ... Unified Modeling Language 2.5.1 State, StateMachine, Transition, Transition::source, Vertex, TransitionKind, Transition::kind, TransitionKind::external, TransitionKind::internal, TransitionKind::local
INFO When multiple triggers are defined for a Transition, they are logically disjunctive, that is, if any of them are enabled, the Transition will be triggered. Unified Modeling Language 2.5.1 State, StateMachine, Transition, Trigger, Transition::trigger, Event, Event occurrence, Trigger::event
INFO A Transition may own a set of Triggers, each of which specifies an Event whose occurrence, when dispatched, may trigger traversal of the Transition. A Transition trigger is said to be enabled if the dispatched Event occurrence matches its Event type. Unified Modeling Language 2.5.1 State, StateMachine, Transition, Trigger, Transition::trigger, Event, Event occurrence, Trigger::event
INFO Transitions are executed as part of a more complex compound transition that takes a StateMachine execution from one stable state configuration to another. Unified Modeling Language 2.5.1 State, StateMachine, Transition, compound transition
INFO NOTE. The duration of a Transition traversal is undefined, allowing for different semantic interpretations, including both “zero” and non-“zero” time. Unified Modeling Language 2.5.1 State, StateMachine, Transition
INFO It may have an associated effect Behavior, which is executed when the Transition is traversed (executed). Unified Modeling Language 2.5.1 State, StateMachine, Transition, Transition::effect
INFO A Transition is a single directed arc originating from a single source Vertex and terminating on a single target Vertex (the source and target may be the same Vertex), which specifies a valid fragment of a StateMachine Behavior. Unified Modeling Language 2.5.1 State, StateMachine, Transition
INFO Otherwise, the appropriate history entry into the Region is executed (see above). If no default history Transition is defined, then standard default entry of the Region is performed .... Unified Modeling Language 2.5.1 State, StateMachine, Vertex, Pseudostate, history, PseudostateKind::deepHistory, PseudostateKind::shallowHistory, default history mechanism
INFO This is a Transition that originates in the history Pseudostate and terminates on a specific Vertex (the default history state) of the Region containing the history Pseudostate. This Transition is only taken if execution leads to the history Pseudostate a Unified Modeling Language 2.5.1 State, StateMachine, Vertex, Transition, Pseudostate, history, PseudostateKind::deepHistory, PseudostateKind::shallowHistory, default history mechanism
INFO In cases where a Transition terminates on a history Pseudostate when the State has not been entered before (i.e., no prior history) or it had reached its FinalState, there is an option to force a transition to a specific substate, using the default ... Unified Modeling Language 2.5.1 State, StateMachine, Vertex, Pseudostate, history, PseudostateKind::deepHistory, PseudostateKind::shallowHistory, default history mechanism
INFO Shallow history (shallowHistory) represents a return to only the topmost substate of the most recent state configuration, which is entered using the default entry rule. Unified Modeling Language 2.5.1 State, StateMachine, Vertex, Pseudostate, history, PseudostateKind::shallowHistory, substate, default entry rule, state configuration
INFO The effect is the same as if the Transition terminating on the deepHistory Pseudostate had, instead, terminated on the innermost State of the preserved state configuration, including execution of all entry Behaviors encountered along the way. Unified Modeling Language 2.5.1 State, StateMachine, Vertex, Pseudostate, history, PseudostateKind::deepHistory, Region, enclosing Region
INFO Deep history (deepHistory) represents the full state configuration of the most recent visit to the containing Region. Unified Modeling Language 2.5.1 State, StateMachine, Vertex, Pseudostate, history, PseudostateKind::deepHistory, Region, enclosing Region
INFO Two types of history Pseudostates are provided. Unified Modeling Language 2.5.1 State, StateMachine, Vertex, Pseudostate, history, PseudostateKind::deepHistory, PseudostateKind::shallowHistory
INFO If there is no outgoing Transition inside the composite State, then the incoming Transition simply performs a default State entry. Unified Modeling Language 2.5.1 State, StateMachine, Transition, PseudostateKind, PseudostateKind::entryPoint, default entry rule, default State entry
INFO In effect, the latter is a continuation of the external incoming Transition, with the proviso that the execution of the entry Behavior of the composite State (if defined) occurs between the effect Behavior of the incoming Transition and the effect ... Unified Modeling Language 2.5.1 State, StateMachine, Transition, PseudostateKind, PseudostateKind::entryPoint, Vertex, Transition::source, Transition::effect, Behavior
INFO Entry points represent termination points (sources) for incoming Transitions and origination points (targets) for Transitions that terminate on some internal Vertex of the composite State. Unified Modeling Language 2.5.1 State, StateMachine, Transition, PseudostateKind, PseudostateKind::entryPoint, Vertex, Transition::source, Transition::target
INFO If the composite State has an exit Behavior defined, it is executed after any effect Behavior of the incoming inside Transition and before any effect Behavior of the outgoing external Transition. Unified Modeling Language 2.5.1 State, StateMachine, Transition, PseudostateKind, PseudostateKind::exitPoint, Vertex, TransitionKind::external
INFO In a well-formed model, such a Transition should have a corresponding external Transition outgoing from the same exit point, representing a continuation of the terminating Transition. Unified Modeling Language 2.5.1 State, StateMachine, Transition, PseudostateKind, PseudostateKind::exitPoint, Vertex, TransitionKind::external
INFO Exit points are the inverse of entry points. That is, Transitions originating from a Vertex within the composite State can terminate on the exit point. Unified Modeling Language 2.5.1 State, StateMachine, Transition, PseudostateKind, PseudostateKind::exitPoint, Vertex
INFO Regardless of how a State is entered, the StateMachine is deemed to be “in” that State even before any entry Behavior or effect Behavior (if defined) of that State start executing. Unified Modeling Language 2.5.1 State, StateMachine, Transition, State::entry, State::exit, active state configuration, state configuration
INFO If the Transition explicitly enters one or more Regions (in case of a fork), these Regions are entered explicitly and the others by default. Unified Modeling Language 2.5.1 State, StateMachine, Transition, composite State, orthogonal Region, State::/isOrthogonal, Region, default entry rule, PseudostateKind::fork
INFO If the Transition terminates on the edge of the composite State (i.e., without entering the State), then all the Regions are entered using the default entry rule above. Unified Modeling Language 2.5.1 State, StateMachine, Transition, composite State, orthogonal Region, State::/isOrthogonal, Region, default entry rule
INFO If the composite State is also an orthogonal State with multiple Regions, each of its Regions is also entered, either by default or explicitly. Unified Modeling Language 2.5.1 State, StateMachine, Transition, composite State, orthogonal Region, State::/isOrthogonal, Region
INFO Transition::trigger : Trigger [0..*] ... Specifies the Triggers that may fire the transition Unified Modeling Language 2.5.1 State, StateMachine, Transition, Transition::trigger, Trigger
INFO Transition::target : Vertex [1..1] ... Designates the target Vertex that is reached when the Transition is taken. Unified Modeling Language 2.5.1 State, StateMachine, Transition, Vertex, Transition::target
INFO Transition::source : Vertex [1..1] ... Designates the originating Vertex (State or Pseudostate) of the Transition. Unified Modeling Language 2.5.1 State, StateMachine, Transition, Transition::source, Vertex
INFO Transition::/redefinitionContext : Classifier [1..1] ... References the Classifier in which context this element may be redefined. Unified Modeling Language 2.5.1 State, StateMachine, Transition, Transition::/redefinitionContext
INFO Transition::redefinedTransition : Transition [0..1] ... The Transition that is redefined by this Transition. Unified Modeling Language 2.5.1 State, StateMachine, Transition, Transition::redefinedTransition
INFO Transition::guard : Constraint [0..1] ... If the guard is true at that time, the Transition may be enabled, otherwise, it is disabled. Guards should be pure expressions without side effects. Guard expressions with side effects are ill formed. Unified Modeling Language 2.5.1 State, StateMachine, Transition, Transition::guard, Constraint, Event, Event occurrence
INFO Transition::guard : Constraint [0..1] ... A guard is a Constraint that provides a fine-grained control over the firing of the Transition. The guard is evaluated when an Event occurrence is dispatched by the StateMachine. ... Unified Modeling Language 2.5.1 State, StateMachine, Transition, Transition::guard, Constraint, Event, Event occurrence
INFO Transition::effect : Behavior [0..1] ... Specifies an optional behavior to be performed when the Transition fires. Unified Modeling Language 2.5.1 State, StateMachine, Transition, Transition::effect, Behavior
INFO Transition::container : Region [1..1] ... Designates the Region that owns this Transition. Unified Modeling Language 2.5.1 State, StateMachine, Transition, Transition::container, Region
INFO Transition::kind : TransitionKind [1..1] = external Indicates the precise type of the Transition. Unified Modeling Language 2.5.1 State, StateMachine, Transition, Vertex, compound transition, Transition::kind, kind : TransitionKind [1..1] = external
INFO A Transition represents an arc between exactly one source Vertex and exactly one Target vertex (the source and targets may be the same Vertex). It may form part of a compound transition, which takes the StateMachine from one steady State configuration... Unified Modeling Language 2.5.1 State, StateMachine, Transition, Vertex, compound transition, Transition::source, Transition::target
INFO Regardless of how a State is exited, the StateMachine is deemed to have “left” that State only after the exit Behavior (if defined) of that State has completed execution. Unified Modeling Language 2.5.1 State, StateMachine, Behavior, State::exit
INFO When exiting from an orthogonal State, each of its Regions is exited. After that, the exit Behavior of the State is executed. Unified Modeling Language 2.5.1 State, StateMachine, Behavior, State::exit, State::/isOrthogonal, orthogonal Region, Region
INFO If the exit occurs through an exitPoint Pseudostate, then the exit Behavior of the State is executed after the effect Behavior of the Transition terminating on the exit point. Unified Modeling Language 2.5.1 State, StateMachine, Behavior, State::exit, composite State, State::/isComposite, PseudostateKind::exitPoint, Transition, Transition::effect
INFO When exiting from a composite State, exit commences with the innermost State in the active state configuration. This means that exit Behaviors are executed in sequence starting with the innermost active State. Unified Modeling Language 2.5.1 State, StateMachine, Behavior, State::exit, composite State, State::/isComposite, substate, active state configuration
INFO If the State has a doActivity Behavior that is still executing when the State is exited, that Behavior is aborted before the exit Behavior commences execution. Unified Modeling Language 2.5.1 State, StateMachine, Behavior, State::exit, State::doActivity
INFO When exiting a State, regardless of whether it is simple or composite, the final step involved in the exit, after all other Behaviors associated with the exit are completed, is the execution of the exit Behavior of that State. Unified Modeling Language 2.5.1 State, StateMachine, Behavior, State::exit
INFO ... if a doActivity Behavior is defined for the State, this Behavior commences execution immediately after the entry Behavior is executed. It executes concurrently with any subsequent Behaviors associated with entering the State, such as the entry ... Unified Modeling Language 2.5.1 State, StateMachine, Behavior, State::entry, State::doActivity
INFO ... the entry Behavior of the State is executed (if defined) upon entry, but only after any effect Behavior associated with the incoming Transition is completed. Unified Modeling Language 2.5.1 State, StateMachine, Behavior, State::entry, Transition, Transition::effect
INFO A State may also have an associated doActivity Behavior. This Behavior commences execution when the State is entered (but only after the State entry Behavior has completed) and executes concurrently with any other Behaviors that may be associated ... Unified Modeling Language 2.5.1 State, StateMachine, Behavior, State::doActivity
INFO In addition, a State may also have an associated exit Behavior, which, if defined, is executed whenever the State is exited. Unified Modeling Language 2.5.1 State, StateMachine, Behavior, State::exit
INFO A State may have an associated entry Behavior. This Behavior, if defined, is executed whenever the State is entered through an external Transition. Unified Modeling Language 2.5.1 State, StateMachine, Behavior, State::entry, Transition, external Transition
INFO A State is said to be active if it is part of the active state configuration. Unified Modeling Language 2.5.1 State, StateMachine, Region, composite State, State::/isComposite, State::/isSimple, state configuration, valid state configuration, active state configuration
INFO StateMachine execution is represented by transitions from one active state configuration to another in response to Event occurrences that match the Triggers of the StateMachine. Unified Modeling Language 2.5.1 State, StateMachine, Region, composite State, State::/isComposite, State::/isSimple, state configuration, valid state configuration, active state configuration, Event, Trigger, Transition::trigger, Transition
INFO An executing StateMachine instance can only be in exactly one state configuration at a time, which is referred to as its active state configuration. Unified Modeling Language 2.5.1 State, StateMachine, Region, composite State, State::/isComposite, State::/isSimple, state configuration, valid state configuration, active state configuration
INFO For example, one valid state configuration for an execution of the StateMachine depicted in Figure 14.9 is: <CourseAttempt - Studying – (Studying::Lab2, Studying::TermProject, Studying::FinalTest)>. Unified Modeling Language 2.5.1 State, StateMachine, Region, composite State, State::/isComposite, State::/isSimple, state configuration, valid state configuration
INFO Similarly, we can talk about such a hierarchy of substates within a composite State. This complex hierarchy of States is referred to as a state configuration (of a State or a StateMachine). Unified Modeling Language 2.5.1 State, StateMachine, Region, composite State, State::/isComposite, State::/isSimple, state configuration
INFO Consequently, a particular “state” of an executing StateMachine instance is represented by one or more hierarchies of States, starting with the topmost Regions of the StateMachine and down through the composition hierarchy to the simple, or leaf, States. Unified Modeling Language 2.5.1 State, StateMachine, Region, composite State, State::/isComposite, State::/isSimple
INFO In general, a StateMachine can have multiple Regions, each of which may contain States of its own, some of which may be composites with their own multiple Regions, etc. Unified Modeling Language 2.5.1 State, StateMachine, Region, composite State, State::/isComposite
INFO A SignalEvent represents the receipt of an asynchronous Signal instance. Unified Modeling Language 2.5.1 Event, MessageEvent, SignalEvent, Trigger, Trigger::event, Message, Operation, object, Signal, SignalEvent::signal
INFO A CallEvent models the receipt by an object of a message invoking a call of an Operation. Unified Modeling Language 2.5.1 Event, MessageEvent, CallEvent, Trigger, Trigger::event, Message, Operation, object, CallEvent::operation
INFO A trigger for an AnyReceiveEvent is triggered by the receipt of any message that is not explicitly handled by any related trigger. Unified Modeling Language 2.5.1 Event, MessageEvent, AnyReceiveEvent, Trigger, Trigger::event, Message
INFO A TimeEvent is an Event that occurs at a specific point in time. Unified Modeling Language 2.5.1 Event, TimeEvent, TimeEvent::isRelative, TimeEvent::when time
INFO A ChangeEvent models a change in the system configuration that makes a condition true. Unified Modeling Language 2.5.1 Event, ChangeEvent, ChangeEvent::changeExpression, ValueSpecification, Boolean
INFO An Event is the specification of some occurrence that may potentially trigger effects by an object. Unified Modeling Language 2.5.1 Event, object, Event occurrence, Trigger, Trigger::event, Transition::trigger, ChangeEvent, MessageEvent, TimeEvent
INFO A MessageEvent specifies the receipt by an object of either an Operation call or a Signal instance. Unified Modeling Language 2.5.1 Event, MessageEvent, object, Operation, Signal, CallEvent, SignalEvent, AnyReceiveEvent
INFO A given BehavioredClassifier may implement more than one Interface and that an Interface may be implemented by a number of different BehavioredClassifiers. Unified Modeling Language 2.5.1 BehavioredClassifier, Interface, BehavioredClassifier::interfaceRealization, InterfaceRealization, provided Interface, required Interface
INFO Required Interfaces specify services that a BehavioredClassifier needs in order to perform its function and fulfill its own obligations to its clients. Unified Modeling Language 2.5.1 BehavioredClassifier, Interface, Usage, required Interface
INFO Interfaces may also be used to specify required Interfaces, which are specified by a Usage dependency between the BehavioredClassifier and the corresponding Interfaces. Unified Modeling Language 2.5.1 BehavioredClassifier, Interface, Usage, required Interface
INFO The set of Interfaces realized by a BehavioredClassifier are its provided Interfaces, which represent the services and obligations that instances of that BehavioredClassifier offer to their clients. Unified Modeling Language 2.5.1 BehavioredClassifier, Interface, BehavioredClassifier::interfaceRealization, InterfaceRealization, provided Interface
INFO The receptions compartment contains ownedReceptions ... Unified Modeling Language 2.5.1 Class, symbol, compartment, Reception, receptions compartment, Signal
INFO The operations compartment of a Class contains notation for its ownedOperations ... Unified Modeling Language 2.5.1 Class, symbol, compartment, Operation, Class::ownedOperation, operations compartment
INFO The parametric diagram is a new SysML diagram type that describes the constraints among the properties associated with blocks. This diagram is used to integrate behavior and structure models with engineering analysis models such as performance, ... OMG Systems Modeling Language (SysML) 1.6 Diagram, Constraint SysML Parametric Diagram, constraint parameter, ConstraintBlock Systems Modeling Language, SysML, mathematics, equation, engineering analysis
INFO The requirement diagram is a new SysML diagram type. A requirement diagram provides a modeling construct for text- based requirements, and the relationship between requirements and other model elements that satisfy or verify them. OMG Systems Modeling Language (SysML) 1.6 Diagram SysML Requirement Diagram, Requirement, Satisfy, Verify, TestCase, DeriveReqt, Copy, AbstractRequirement::text Systems Modeling Language, SysML, requirements engineering
INFO Tabular representations, such as the allocation table, are used in SysML but are not considered part of the diagram taxonomy. OMG Systems Modeling Language (SysML) 1.6 Diagram, Activity Diagram SysML Activity Diagram
INFO Activity diagrams have also been modified via the activity extensions. OMG Systems Modeling Language (SysML) 1.6 Diagram, Activity Diagram SysML Activity Diagram
INFO For example, the block definition diagram and internal block diagram are similar to the UML class diagram and composite structure diagram respectively, but include extensions ... OMG Systems Modeling Language (SysML) 1.6 Diagram, Class Diagram, Composite Structure Diagram SysML Block Definition Diagram, SysML Internal Block Diagram
INFO SysML reuses many of the major diagram types of UML. In some cases, the UML diagrams are strictly reused, such as use case, sequence, state machine, and package diagrams, whereas in other cases they are modified so that they are consistent with SysML ... OMG Systems Modeling Language (SysML) 1.6 Diagram, UseCase Diagram, Sequence Diagram, StateMachine Diagram, Package Diagram
INFO In the case of the profile diagram, profile definitions can be captured on a package diagram and the parametric diagram. OMG Systems Modeling Language (SysML) 1.6 Diagram, Object Diagram, Communication Diagram, Interaction Overview Diagram, Timing Diagram, Deployment Diagram, Profile Diagram SysML Package Diagram, SysML Parametric Diagram
INFO SysML does not use all of the UML diagram types such as the object diagram, communication diagram, interaction overview diagram, timing diagram, deployment diagram, and profile diagram. OMG Systems Modeling Language (SysML) 1.6 Diagram, Object Diagram, Communication Diagram, Interaction Overview Diagram, Timing Diagram, Deployment Diagram, Profile Diagram
INFO For example “velocity” can be specified as the product of “length” to the power one times “time” to the power minus one, and subsequently “speed” can be specified as “velocity” to the power one. OMG Systems Modeling Language (SysML) 1.6 DerivedQuantityKind, QuantityKind
INFO A DerivedQuantityKind may also be used to define a synonym kind of quantity for another kind of quantity. OMG Systems Modeling Language (SysML) 1.6 DerivedQuantityKind, QuantityKind
INFO A DerivedQuantityKind is a QuantityKind that represents a kind of quantity that is defined as a product of powers of one or more other kinds of quantity. OMG Systems Modeling Language (SysML) 1.6 DerivedQuantityKind, QuantityKind
INFO For example the measurement unit “metre per second” for “velocity” is specified as the product of “metre” to the power one times “second” to the power minus one. OMG Systems Modeling Language (SysML) 1.6 Unit, DerivedUnit
INFO A DerivedUnit is a Unit that represents a measurement unit that is defined as a product of powers of one or more other measurement units. OMG Systems Modeling Language (SysML) 1.6 Unit, DerivedUnit