OMG Systems Modeling Language (SysML) 1.6

Icon class
icon_class
far fa-file-alt
icon_class_computed
far fa-file-alt
Keywords
Specification keywords
SysML-1.6
Copyright information
About Object Management Group copyright in text extracts quoted from OMG specifications for educational purposes
Snippets (quotes/extracts)
A control operator is a behavior that is intended to represent an arbitrarily complex logical operator that can be used to enable and disable other actions. ... The «controlOperator» stereotype also applies to operations with the same semantics.
When the «controlOperator» stereotype is applied to behaviors, the behavior takes control values as inputs or provides them as outputs, that is, it treats control as data
When the «controlOperator» stereotype is not applied, the behavior may not have a parameter typed by ControlValue.
The control value inputs do not enable or disable the control operator execution based on their value, they only enable based on their presence as data.
Pins for control parameters are regular pins, not UML control pins. This is so the control value can be passed into or out of the action and the invoked behavior, rather than control the starting of the action, or indicating the ending of it.
This single signal carries the temperature, rpm, and knockSensor information of the engine.
For purposes of example, the ports, flows, and related point-to-point connectors in Figure D.19 are being refined into a common bus architecture. For this example, ports with flow properties have been used to model the bus architecture.
Figure D.21 is an incomplete first step in the refinement of this bus architecture, as it begins to specify the flow properties for InternalCombustionEngine, the Transmission, and the ElectricalPowerController.
Figure D.22 continues the refinement of this Controller Area Network (CAN) bus architecture using ports.
The explicit structural allocation between the original connectors of Figure D.19 and this new bus architecture is shown in Figure D.39.
A ValueType defines types of values that may be used to express information about a system, but cannot be identified as the target of any reference.
Since a value cannot be identified except by means of the value itself, each such value within a model is independent of any other, unless other forms of constraints are imposed.
Value types may be used to type properties, operation parameters, or potentially other elements within SysML.
SysML defines ValueType as a stereotype of UML DataType to establish a more neutral term for system values that may never be given a concrete data representation.
For example, the SysML "Real" ValueType expresses the mathematical concept of a real number, but does not impose any restrictions on the precision or scale of a fixed or floating-point representation that expresses this concept.
More specific value types can define the concrete data representations that a digital computer can process, such as conventional Float, Integer, or String types.
SysML ValueType adds an ability to carry a unit of measure and quantity kind associated with the value.
A quantity kind is a kind of quantity that may be stated in terms of defined units, but does not restrict the selection of a unit to state the value. A unit is a particular value in terms of which a quantity of the same quantity kind may be expressed.
A SysML ValueType may define its own properties and/or operations, just as for a UML DataType.
quantityKind : InstanceSpecification [0..1] A kind of quantity, represented by an InstanceSpecification classified by a kind of SysML QuantityKind, that may be stated by means of units. A value type may optionally specify a quantity kind without any unit.
unit : InstanceSpecification [0..1] A unit, represented by an InstanceSpecification classified by a kind of SysML Unit, in terms of which the magnitudes of other quantities that have the same quantity kind can be stated.
The package diagram (Figure D.3) shows the structure of the model used to evaluate the sample problem.
Model elements are contained in packages, and relationships between packages (or specific model elements) are shown on this diagram.
The relationship between the views (OperationalView and PerformanceView) and the rest of the user model are explicitly expressed using the «import» relationship.
Note that the «view» models contain no model elements of their own, and that changes to the model in other packages are automatically updated in the Operational and Performance Views.
The term “context diagram,” in Figure D.4, refers to a user-defined usage of an internal block diagram, which depicts some of the top level entities in the overall enterprise and their relationships.
The diagram usage enables the modeler or methodologist to specify a unique usage of a SysML diagram type using the extension mechanism described in Annex A, “Diagrams.”
The entities are conceptual in nature during the initial phase of development, but will be refined as part of the development process.
The «system» and «external» stereotypes are user defined, not specified in SysML, but help the modeler to identify the system of interest relative to its environment.
Each model element depicted may include a graphical icon to help convey its intended meaning.
The spatial relationship of the entities on the diagram sometimes conveys understanding as well, although this is not specifically captured in the semantics.
Also, a background such as a map can be included to provide additional context.
The associations among the classes may represent abstract conceptual relationships among the entities, which would be refined in subsequent diagrams.
Note how the relationships in this diagram are also reflected in the Automotive Domain Model Block Definition Diagram, Figure D.15.
The use case diagram for “Drive Vehicle” in Figure D.5 depicts the drive vehicle usage of the vehicle system. The subject (HybridSUV) and the actors (Driver, Registered Owner, Maintainer, Insurance Company, DMV) interact to realize the use case.
Goal-level Use Cases associated with “Operate the Vehicle” are depicted in the following diagram. These use cases help flesh out the specific kind of goals associated with driving and parking the vehicle.
Maintenance, registration, and insurance of the vehicle would be covered under a separate set of goal-oriented use cases.
Figure D.7 shows the interactions between driver and vehicle that are necessary for the “Drive the Vehicle” Use Case. This diagram represents the “DriveBlackBox” interaction, with [which] is owned by the AutomotiveDomain block.
“BlackBox” for the purpose of this example, refers to how the subject system (HybridSUV block) interacts only with outside elements, without revealing any interior detail.
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.
Figure D.8 depicts the operational states of the HSUV block, via a State Machine named “HSUVOperationalStates.”
Note that this state machine was developed in conjunction with the DriveBlackBox interaction in Figure D.7.
Also note that this state machine refines the requirement “PowerSourceManagment,” which will be elaborated in the requirements sub clause of this sample problem.
This diagram expresses only the nominal states. Exception states, like “acceleratorFailure,” are not expressed on this diagram.
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.
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.
The send and receive events may both be on the same lifeline.
The form of the line or arrowhead reflects properties of the message
An asynchronous Message (messageSort equals asynchCall or asynchSignal) has an open arrow head.
A synchronous Message (messageSort equals synchCall) has a filled arrow head.
A reply Message (messageSort equals reply) has a dashed line with either an open or filled arrow head.
An object creation Message (messageSort equals createMessage) has a dashed line with an open arrow head.
An object deletion Message (messageSort equals deleteMessage) must end in a DestructionOccurrenceSpecification.
A lost Message is denoted with a small black circle at the arrow end of the Message.
A found Message is denoted with a small black circle at the starting end of the Message.
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 ...
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.
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.
The containment (cross hair) relationship, for purposes of this example, refers to the practice of decomposing a complex requirement into simpler, single requirements.
A requirement specifies a capability or condition that must (or should) be satisfied.
A requirement may specify a function that a system must perform or a performance condition that a system must satisfy.
Requirements are used to establish a contract between the customer (or other stakeholder) and those responsible for designing and implementing the system.
A requirement is a stereotype of both Class and Abstract Requirement.
Compound requirements can be created by using the nesting capability of the class definition mechanism.
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.
Subrequirements shall be accessed through the "nestedClassifier" property of a class.
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.
Figure D.12 shows a set of requirements derived from the lowest tier requirements in the HSUV specification.
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.
Various other model elements may be necessary to help develop a derived requirement, and these model element may be related by a «refinedBy» relationship.
Note how PowerSourceManagement is “RefinedBy” the HSUVOperationalStates model (Figure D.8).
Note also that rationale can be attached to the «deriveReqt» relationship. In this case, rationale is provided by a referenced document “Hybrid Design Guidance.”
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.
Figure D.13 focuses on the Acceleration requirement, and relates it to other requirements and model elements.
The “refine” relation, introduced in Figure D.12, shows how the Acceleration requirement is refined by a similarly named use case.
The Power requirement is satisfied by the PowerSubsystem, and a Max Acceleration test case verifies the Acceleration requirement.
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.
Figure D.15 provides definition for the concepts previously shown in the context diagram.
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.
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.
SysML also supports properties with shared aggregation, as shown by a white diamond symbol on an association.
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.
Figure D.17 shows how the top level model elements in the above diagram are connected together in the HybridSUV block.
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.
The dashed borders on FrontWheel and BrakePedal denote the “use-not-composition” relationship depicted elsewhere in Figure D.16 and Figure D.18.
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.
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").
Figure D.20 provides definition of the block that types the ports linked by connector c1 in Figure D.19
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.)
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 ...
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 ...
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
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...
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, ...
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.
The ports on the FuelTankAssembly and InternalCombustionEngine (as shown in Figure D.19) are defined in Figure D.23.
SysML extends blocks to support flow properties and provided and required features.
Blocks with ports can type other ports (nested ports).
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.
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.
Figure D.24 is a parametric diagram showing how fuel flowrate is related to FuelDemand and FuelPressure value properties.
A Binding Connector is a connector which specifies that the properties at both ends of the connector have equal values.
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.
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.
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 ...
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.
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.
Binding connectors, as defined in Clause 8 are used to bind each parameter of the constraint block to a property in the surrounding context.
All properties of a constraint block are constraint parameters, with the exception of constraint properties that hold internally nested usages of constraint blocks.
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 ...
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.
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).
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..
Constraint blocks provide a mechanism for integrating engineering analysis such as performance and reliability models with other SysML models.
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.
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.
A constraint block includes the constraint, such as {F=m*a}, and the parameters of the constraint such as F, m, and a.
Constraint blocks define generic forms of constraints that can be used in multiple contexts. For example, a definition for Newton’s Laws may be used to specify these constraints in many different contexts.
Reusable constraint definitions may be specified on block definition diagrams and packaged into general-purpose or domain-specific model libraries. Such constraints can be arbitrarily complex mathematical or logical expressions.
The constraints can be nested to enable a constraint to be defined in terms of more basic constraints such as primitive mathematical operators.
Parametric diagrams include usages of constraint blocks to constrain the properties of another block.
The usage of a constraint binds the parameters of the constraint, such as F, m, and a, to specific properties of a block, such as a mass, that provide values for the parameters.
The constrained properties, such as mass or response time, typically have simple value types that may also carry units, quantity kinds, or probability distributions.
A pathname dot notation can be used to refer to nested properties within a block hierarchy.
This allows a value property (such as an engine displacement) that may be deeply nested within a containing hierarchy (such as vehicle, power system, engine) to be referenced at the outer containing level (such as vehicle-level equations).
The context for the usages of constraint blocks shall also be specified in a parametric diagram to maintain the proper namespace for the nested properties.
A property name shown inside or outside the property box may take the form of a multi-level name. This form of name references a nested property accessible through a sequence of intermediate properties from a referencing context.
The name of the referenced property is built by a string of names separated by “.”, resulting in a form of path name that identifies the property in its local context.
A colon and the type name for the property may optionally be shown following the dotted name string.
If any of the properties named in the path name string identifies a reference property, the property box is shown with a dashed-outline box, just as for any reference property on an internal block diagram.
This notation is purely a notational shorthand for a property that could otherwise be shown within a structure of nested property boxes, with the names in the dotted string taken from the name that would appear at each level of nesting
In other words, the internal property shown with a path name in the left-hand side of Figure 8-1 is equivalent to the innermost nested box shown at the right.
If the property has no name, the property’s type name can be used instead. e.g., car:Engine:Cylinder:Piston.length car.e.c.p.length
A constraint block is defined by a keyword of «constraint» applied to a block definition. Properties of this block define parameters of the constraint, with the exception of properties that hold internally nested usages of constraint blocks.
The usage of a constraint block is distinguished from other parts by a box having rounded corners rather than the square corners of an ordinary part.
A parametric diagram is a restricted form of internal block diagram that shows only the use of constraint blocks along with the properties they constrain within a context.
Figure D.25 shows how the connectors fuelDelivery and fdist on Figure D.19 have been expanded to include design detail. The fuelDelivery connector is actually two connectors, one carrying fuelSupply and the other carrying fuelReturn.
The fdist connector inside the InternalCombustionEngine block has been expanded into the fuel regulator and fuel rail parts. These more detailed design elements are related to the original connectors using the allocation relationship.
The Fuel store represents a quantity of fuel in the FuelTankAssy, which is drawn by the FuelPump for use in the engine, and is refreshed, to some degree, by fuel returning to the FuelTankAssy via the FuelReturnLine.
Allocate is a dependency based on UML::Abstraction. It is a mechanism for associating elements of different types, or in different hierarchies, at an abstract level. Allocate is used for assessing user model consistency and directing future design ...
It is expected that an «allocate» relationship between model elements is a precursor to a more concrete relationship between the elements, their properties, operations, attributes, or sub-classes.
Allocate is a stereotype of a UML4SysML::Abstraction that is permissible between any two NamedElements. It is depicted as a dependency with the "allocate" keyword attached to it.
Allocate is directional in that one NamedElement is the "from" end (no arrow), and one NamedElement is the "to" end (the end with the arrow).
The Allocate stereotype specializes DirectedRelationshipPropertyPath to enable allocations to identify their sources and targets by a multi-level path of accessible properties from context blocks for the sources and targets.
The following paragraphs describe types of allocation that are typical in systems engineering.
Behavior allocation relates to the systems engineering concept segregating form from function. This concept requires independent models of "function" (behavior) and "form" (structure), and a separate, deliberate mapping between elements in each of these..
It is acknowledged that this concept does not support a standard object-oriented paradigm, not[r] is this always even desirable. Experience on large scale, complex systems engineering problems have proven, however, that segregation of form and function...
In addition, behavior allocation may also include the allocation of Behaviors to BehavioralFeatures of Blocks (e.g., Operations).
Figure D.26 defines the various model elements that will be used to conduct analysis in this example. It depicts each of the constraint blocks/equations that will be used for the analysis, and key relationships between them.
Figure D.27 shows the user-defined Performance Viewpoint, and the elements that populate the HSUV specific PerformanceView. The PerformanceView itself may contain a number of diagrams depicting the elements it contains.
A stakeholder represents a role, group, or individual who has concerns that will be addressed by the View of the model.
A Stakeholder stereotype can only be applied to UML::Actor or UML::Class which are not a UML::Association.
The expose relationship relates a view to one or more model elements. Each model element is an access point to initiate the query.
The view and the model elements related to the view are passed to the constructor when it is invoked. The method describes how the exposed elements are navigated to extract the desired information.
Figure D.28 shows the Requirements and VnV viewpoint definitions with relationships to stakeholders, concerns and views.
The stakeholder and viewpoint share the same concern via comments that are shown textually as values of the concern property. The comments could be shown graphically with annotation relationships to stakeholders and viewpoints, if needed.
Note that the value of the stakeholder property is an instance of the stereotype not the class to which the stereotype is applied.
Figure D.29 shows the Requirements and VnV views and the model elements they expose. Note that the expose relationship relies on the viewpoint method to identify the entire set of elements that appear in the view.
View::/stakeholder : Stakeholder [0..*] The list of stakeholders is derived from the viewpoint the view conforms to. (derived)
View::/viewpoint : Viewpoint [1] The viewpoint for this View is derived from the conform relationship. (derived)
It is sometimes desirable to construct views from other views, and to establish an order for presenting the views. Views may include one or more views as properties, each of which conforms to their viewpoint. The order of the referenced views is ...
Figure D.30 shows the Requirements and VnV views and the supporting views that complete the description of Requirements and VnV respectively for the Hybrid SUV.
Measure of Effectiveness is a user defined stereotype.
Figure D.31 shows how the overall cost effectiveness of the HSUV will be evaluated. It shows the particular measures of effectiveness for one particular alternative for the HSUV design, and can be reused to evaluate other alternatives.
A measure of effectiveness (moe) represents a parameter whose value is critical for achieving the desired mission cost effectiveness.
It will also be assumed that the overall mission cost effectiveness can be determined by applying an objective function to a set of criteria, each of which is represented by a measure of effectiveness.
This non-normative extension includes stereotypes for an objective function and a measure of effectiveness. The objective function is a stereotype of a ConstraintBlock and the measure of effectiveness is a stereotype of a block property.
«objectiveFunction» An objective function (aka optimization or cost function) is used to determine the overall value of an alternative in terms of weighted criteria and/or moe's.
«moe» A measure of effectiveness (moe) represents a parameter whose value is critical for achieving the desired mission cost effectiveness.
Since overall fuel economy is a key requirement on the HSUV design, this example applies significant detail in assessing it. Figure D.32 shows the constraint blocks and properties necessary to evaluate fuel economy.
The StraightLineVehicleDynamics constraint block from Figure D.32 has been expanded in Figure D.33. ConstraintNotes are used, which identify each constraint using curly brackets {}. In addition, Rationale has been used to explain the meaning ...
Ports are notated by rectangles overlapping the boundary of their owning blocks or properties (parts or ports) typed by the owning block.
Port labels appear in the same format as properties on the end of an association. Port labels can appear inside port rectangles.
The constraints and parameters in Figure D.33 are detailed in Figure D.34 in Block Definition Diagram format. Note the use of valueTypes [ValueTypes] originally defined in Figure D.2.
Timing diagrams, while included in UML 2, are not directly supported by SysML.
For illustration purposes, however, the interaction shown in Figure D.35 was generated based on the constraints and parameters of the StraightLineVehicleDynamics constraintBlock, as described in the Figure D.33.
It assumes a constant 100hp at the drive wheels, 4000lb gross vehicle weight, and constant values for Cd and Cf.
Figure D.36 shows the top level behavior of an activity representing acceleration of the HSUV.
It is the intent of the systems engineer in this example to allocate this behavior to parts of the PowerSubsystem. It is quickly found, however, that the behavior as depicted cannot be allocated, and must be further decomposed.
The stereotypes on the object nodes between actions in the figure apply to parameters of the behaviors or operations called by the actions (see the notation for object nodes described in 11.3.1.4, ObjectNode, Variables, and Parameters).
SysML provides extensions that might be very loosely grouped under the term “continuous,” but are generally applicable to any sort of distributed flow of information and physical items through a system.
Restrictions on the rate at which entities flow along edges in an activity, or in and out of parameters of a behavior (see Rate in Figure 11-8). This includes both discrete and continuous flows, either of material, energy, or information.
Discrete and continuous flows are unified under rate of flow, as is traditionally done in mathematical models of continuous change, where the discrete increment of time approaches zero.
Extension of object nodes, including pins, with the option for newly arriving values to replace values that are already in the object nodes (see Overwrite in Figure 11-8).
SysML also extends object nodes with the option to discard values if they do not immediately flow downstream (see NoBuffer in Figure 11-8).
These two extensions are useful for ensuring that the most recent information is available to actions by indicating when old values should not be kept in object nodes, and for preventing fast or continuously flowing values from collecting ...
Continuous rate is a special case of rate of flow (see Rate) where the increment of time between items approaches zero. It is intended to represent continuous flows that may correspond to water flowing through a pipe, a time continuous signal, or ...
Continuous ... It is independent from UML streaming, see clause 11.3.2.8. A streaming parameter may or may not apply to continuous flow, and a continuous flow may or may not apply to streaming parameters.
Figure D.37 defines a decomposition of the activities and objectFlows from the activity diagram in Figure D.36.
Activities as blocks can have associations between each other, including composition associations. Composition means that destroying an instance at the whole end destroys instances at the part end.
When composition is used with activity blocks, the termination of execution of an activity on the whole end will terminate executions of activities on the part end of the links.
Associations can be used between activities and classifiers (blocks or value types) that are the type of object nodes, variables, or parameters in the activity, as shown in Figure 11-5.
When the «rate» stereotype is applied to an activity edge, it specifies the expected value of the number of objects and values that traverse the edge per time interval, that is, the expected value rate at which they leave the source node and arrive at ...
Rate ... It does not refer to the rate at which a value changes over time.
Rate ... When the stereotype is applied to a parameter, the parameter shall be streaming, and the stereotype gives the number of objects or values that flow in or out of the parameter per time interval while the behavior or operation is executing.
Streaming is a characteristic of UML behavior parameters that supports the input and output of items while a behavior is executing, rather than only when the behavior starts and stops. The flow may be continuous or discrete ...
The «rate» stereotype has a rate property of type InstanceSpecification. The values of this property shall be instances of classifiers stereotyped by «valueType» or «distributionDefinition» ...
Rate::rate - In particular, the denominator for units used in the rate property shall be time units.
1_streaming When the «rate» stereotype is applied to a parameter, the parameter shall be streaming.
Figure D.38 shows the ProvidePower activity, which includes Actions invoking the decomposed Activities and ObjectNodes from Figure D.37.
Figure D.38 ... It also uses AllocateActivityPartitions and an allocation callout to explicitly allocate activities and an object flow to parts in the PowerSubsystem block.
Note that the incoming and outgoing object flows for the ProvidePower activity have been decomposed. This was done to distinguish the flow of electrically generated mechanical power and gas generated mechanical power, and to provide further insight ...
Figure D.39 depicts a subset of the PowerSubsystem, specifically showing the allocation relationships generated in Figure D.38.
Figure D.40 shows the same allocation relationships shown in Figure D.38, but in a more compact tabular representation.
Figure D.41[ ]shows a particular Hybrid SUV (VIN number) satisfying the EPA fuel economy test. Serial numbers of specific relevant parts are indicated.
A compartment with a label of “initialValues” may be used to show values of properties belonging to a containing block. These values override any default values that may have been previously specified on these properties on their originally defining block
Initial value compartments may be specified within nested properties, which then apply only in the particular usage context defined by the outermost containing block.
Values are specified in an initialValues compartment by lines in the form <property-name> = <value-specification> or <property-name> : <type> = <value-specification>, each line of which specifies the initial value for one property owned either by ...
This portion of concrete syntax is the same as may be shown for values within the UML instance specification notation, but this is the only element of UML InstanceSpecification notation that may be shown in an initial values compartment.
The BoundReference stereotype can be applied to properties that have binding connectors, to highlight their usage as constraining other properties. The bound end of the stereotype is a connector end of one of the binding connectors, opposite the ..
The bound end of the stereotype is a connector end of one of the binding connectors, opposite the stereotyped property.
The binding path includes the property at the bound end, and before that, the property path of the bound end, if it is a nested connector end.
Figure 8-15 shows an example decomposition for vehicles in a block definition diagram.
Figure 8-16 shows the same decomposition in an internal block diagram that includes bound references. The binding connectors have nested connector ends, because they link inside the parts of the vehicle.
Figure 8-17 shows specializations for vehicles that restrict aspects of nested parts by redefining bound references. Paths for bound references are based on the property paths of the corresponding binding connectors.
The general block on the top does not restrict the bound properties, except the total number of lug bolts is required to be between 24 and 32, rather than 24 and 40 as the associations in Figure 8-15 allow.
The specialization on the lower left restricts the number of cylinders to four, requires a light roll bar, and a total of 24 lug bolts over all the wheels.
The specialization on the lower right restricts the number of cylinders to between six and eight, rules out any roll bar, and limits lug bolts per wheel to between 6 and 7, by giving the end path upper and lower values.
The EndPathMultiplicity stereotype can be applied to properties that are related by redefinition to properties that have BoundReference applied.
The lower and upper properties of the stereotype give the minimum and maximum number of values, respectively, of the property at the bound end of the related bound reference, for each object reached by navigation along its binding path.
Ports with types that have flow properties all in the same direction, either all in or all out, can have an arrow inside them indicating the direction of the properties with respect to the owning block.
This includes the direction of flow properties on nested ports, and if the port is full and its type is unencapsulated, ports on parts of the port, recursively. The arrows are perpendicular to the boundary lines they overlap.
Ports with types that have flow properties in different directions or flow properties that are all in both directions, including have two open arrow heads inside them facing away from each other (<>). This includes the directions of nested and...
Ports appearing in block compartments can have their direction appear textually before the port name as “in,” “out,” or “inout” determined in the same way as the arrow direction.
Figure 9-8 shows an association block Water Delivery between a bank of spigots and a faucet. The «port» keyword indicates which association ends are ports (associations use properties as ends, which can be ports).
Figure 9-9 shows the internal structure of Water Delivery defining connectors between the spigots in the bank and inlets on the faucet.
The participant properties identify the spigot bank and faucet being connected. The end property on the stereotype refers to the corresponding association end in Figure 9-8.
The type of participant properties is shown for clarity, but is always the same as the association end type and can be elided. They are shown with dashed rectangles because they are reference properties.
The aggregation of a property stereotyped by ParticipantProperty shall be none
The internal structure connects hot and cold ports of the participants.
Figure 9-10 shows two views of a block House with a connector of type Water Delivery.
The connector in the top view “decomposes” into the subconnectors in the lower view according to the internal structure of Water Delivery. The subconnectors relate the nested ports of :WaterSupply to the nested ports of :WaterClient.
The top portion of Figure 9-11 shows specializations of the block WaterClient into Bath, Sink, and Shower. These are used as part types in the internal structure of the block House 2 shown in the lower portion of the figure
The composite connector for Water Delivery is reused three times to establish connections between spigots on the water supply and the inlets of faucets on the bath, sink, and shower.
Figure 9-12 adds a Plumbing association block for the association between Spigot and Faucet Inlet in Figure 9-11.
Figure 9-13 shows the internal structure for the Plumbing association block, which includes a pipe and two fittings (the additional part and connector definitions are omitted for brevity).
Figure 9-14 modifies Figure 9-9 to use Plumbing as a connector type within the Water Delivery association block.
The lower connector shows its connector property explicitly, enabling the pipe it contains to be connected to a mounting bracket (the additional part and connector definitions are omitted for brevity).
Connectors can be typed by association classes that are stereotyped by Block (association blocks, see ParticipantProperty ...
These connectors specify instances of the association block created within the instances of the block that owns the connector.
The values of a connector property are instances of the association block created due to the connector referred to by the connector property.
A connector property can optionally be shown in an internal block diagram with a dotted line from the connector line to a rectangle notating the connector property.
The keyword «connector» before a property name indicates the property is stereotyped by ConnectorProperty.
Item flows in internal block diagrams specify flows local to a block.
For example, in Figure 9-15 the connector to the output of the water heater has an item flow indicating distilled water is flowing, even though the out flow property of the water heater indicates it produces water.
The water heater is fed from a water distiller in this particular usage, so the modeler knows the output will always be distilled water, rather than other kinds of water.
The radiator on the left requires distilled water, and its connection to the water heater is compatible because the item flow narrows the items to distilled water.
Item flows can also be more general than the actual flow, as shown by the connector on the right. The water distiller produces distilled water, but the item flow is for any kind of fluid.
The connection to the water heater is compatible because it accepts any kind of water, including distilled.
The item flow does not require the heater to accept any kind of fluid, because the source of flow is still producing water, regardless of the generality of the item flow.
Connectors with item flows can be decomposed by association blocks that have additional item flows. The relationship between an item flow and those in the association block is determined by the modeler.
Figures 9.16 and 9.17 are examples of item flow decomposition that modelers might choose, but they are not the only possible decompositions and are not required.
In Figure 9-16, the item flow classifier (EnginePart) is a supertype of the classifiers of the item flows in the decomposition.
The flow properties are all in the types of the nested ports, while the composing item flow summarizes the kinds of items flowing by generalization.
In Figure 9-17, the item flow classifier (Engine) composes the classifiers of the items flows in the decomposition from Figure 9-17.
The port types have an additional flow property that is not in the nested ports. These are for the flow of the engine, as opposed to its parts.
Constraints can be added between the flow properties for the engine and those for the parts, to indicate the flowing parts are inside the flowing engine, or are separate, for example as spare parts.
Figure D.32 shows the use of constraint properties on a parametric diagram. This diagram shows the use of nested property references to the properties of the parts;
parametric diagrams can make use of the nested property name notation to refer to multiple levels of nested property containment, as shown in this example.
A parametric diagram is similar to an internal block diagram with the exception that the only connectors that may be shown are binding connectors.
The Sample Problem in Annex D provides definitions of the containing EconomyContext block for which this parametric diagram is shown.
Activities in block definition diagrams appear as regular blocks, except the «activity» keyword may be used to indicate the Block stereotype is applied to an activity, as shown in Figure 11-1. See example in 11.4, Usage Examples.
This provides a means for representing activity decomposition in a way that is similar to classical functional decomposition hierarchies.
Properties with AdjunctProperty applied, where the principal of the AdjunctProperties are call actions, including call behavior actions, can be used as the part end of the associations. See 8.3.2.2 for constraints when AdjunctProperty is used ...
Activities in block definition diagrams can also appear with the same notation as CallBehaviorAction, except the rake notation can be omitted, if desired. Also see use of activities in block definition diagrams that include ObjectNodes.
Stereotypes applied to behaviors may appear on the notation for CallBehaviorAction when invoking those behaviors, as shown in Figure 11-2.
CallBehaviorActions in activity diagrams may optionally show the action name with the name of the invoked behavior using the colon notation shown in Figure 11-3.
Control flow may be notated with a dashed line and stick arrowhead, as shown in Figure 11-4.
Associations can be used between activities and classifiers (blocks or value types) that are the type of object nodes, variables, or parameters in the activity, as shown in Figure 11-5.
This supports linking the execution of the activity with items that are flowing through the activity or assigned to variables or parameters, and happen to be contained by an object node or assigned to a variable or parameter at the time the link exists.
Properties with AdjunctProperty applied, where the principal of the AdjunctProperty is an object node, variable, or parameter, can be used as the end of the associations toward the object node, variable, or parameter type.
Like any association end or property these can be the subject of parametric constraints, design values, units, and quantity kinds.
The associations may be composition if the intention is to delete instances of the classifier flowing the activity when the activity is terminated. See example in 11.4, Usage Examples.
Figure 11-10 shows a simplified model of driving and braking in a car that has an automatic braking system.
Turning the key on has a duration constraint specifying that this action lasts no more than 0.1 seconds.
Turning the key on starts two behaviors, Driving and Braking. These behaviors execute until the key is turned off, using streaming parameters to communicate with other behaviors.
The Driving behavior outputs a brake pressure continuously to the Braking behavior while both are executing, as indicated by the «continuous» rate and streaming properties (streaming is a characteristic of UML behavior parameters that supports ...
Brake pressure information also flows to a control operator that outputs a control value to enable or disable the Monitor Traction behavior.
No pins are used on Monitor Traction, so once it is enabled, the continuously arriving enable control values from the control operator have no effect, per UML semantics.
When the brake pressure goes to zero, disable control values are emitted from the control operator. The first one disables the monitor, and the rest have no effect.
While the monitor is enabled, it outputs a modulation frequency for applying the brakes as determined by the ABS system.
The rake notations on the control operator and Monitor Traction indicate they are further defined by activities, as shown in Figure 11-11 and Figure 11-12. An alternative notation for this activity decomposition is shown in Figure 11-13.
The activity diagram for Monitor Traction is shown in Figure 11-11.
When Monitor Traction is enabled, it begins listening for signals coming in from the wheel and accelerometer, as indicated by the signal receipt symbols on the left, which begin listening automatically when the activity is enabled.
A traction index is calculated every 10 ms, which is the slower of the two signal rates. The accelerometer signals come in continuously, which means the input to Calculate Traction does not buffer values.
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.
The activity diagram for the control operator Enable on Brake Pressure > 0 is shown in Figure 11-12.
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.
The edges coming out of the decision node indicate the probability of each branch being taken.
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 ...
Each instance of Operating Car is an execution of that behavior. It owns the executions of the behaviors it invokes synchronously, such as Driving.
Like all composition, if an instance of Operating Car is destroyed, terminating the execution, the executions it owns are also terminated.
2_same_name Properties to which AdjunctProperty [is] applied shall have the same name as the principal, if the principal is a NamedElement.
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.
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.
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
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.
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.
Interactions in block definition diagrams can also appear with the same notation as InteractionUses.
Figure D.7 illustrates the overall system behavior for operating the vehicle in Sequence diagram format.
To manage the complexity, a hierarchical sequence diagram is used which refers to other interactions that further elaborate the system behavior (“ref StartVehicleBlackBox”).
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.
Figure D.9 shows an interaction that includes events and messages communicated between the driver and vehicle during the starting of the vehicle.
The “hybridSUV” lifeline represents another interaction which further elaborates what happens inside the “hybridSUV” when the vehicle is started.
Figure D.10 shows the sequence of communication that occurs inside the HybridSUV when the vehicle is started successfully.
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.
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.
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.
State machines in block definition diagrams can also appear with the same notation as submachine states.
AllocateActivityPartition is used to depict an «allocate» relationship on an Activity diagram. The AllocateActivityPartition is a standard UML::ActivityPartition, with modified constraints...
Specific behavior allocation of Actions to Parts are depicted in Figure 15-4.
Note that the AllocateActivityPartition, if used in this manner, is unambiguously associated with behavior allocation.
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).
Figure 15-5 shows flow allocation of [an] ObjectFlow to a Connector, or alternatively to an ItemFlow.
Allocation of ControlFlow is not shown as an example, but it is not prohibited in SysML.
Systems engineers have frequent need to allocate structural model elements (e.g., blocks, parts, or connectors) to other structural elements.
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.
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).
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.
The allocation table can also be shown using a sparse matrix style as in the following example shown in Figure 15-9.
The diagram in Figure 16-2 shows an example of a compound requirement decomposed into multiple subrequirements.
A DeriveReqt relationship is a dependency between two requirements in which a client requirement can be derived from the supplier requirement.
For example, a system requirement may be derived from a business need, or lower-level requirements may be derived from a system requirement.
As with other dependencies, the arrow direction points from the derived (client) requirement to the (supplier) requirement from which it is derived.
DeriveReqt::1_supplier_is_requirement The supplier shall be an element stereotyped by a subtype of AbstractRequirement.
DeriveReqt::2_client_is_requirement The client shall be an element stereotyped by a subtype of AbstractRequirement.
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.
A Satisfy relationship is a dependency between a requirement and a model element that fulfills the requirement.
As with other dependencies, the arrow direction points from the satisfying (client) model element to the (supplier) requirement that is satisfied.
Satisfy::1_supplier_is_requirement The supplier shall be an element stereotyped by any subtype of «AbstractRequirement».
Satisfy::getSatisfies (in ref : NamedElement) : AbstractRequirement [0..*]
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.
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
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.
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
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
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.
A test case is a method for verifying a requirement is satisfied.
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).
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
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.
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.
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.
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.
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.
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.
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
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.
Figure 8-23 shows the classification of a particular machine over time, identified by its serial number.
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.
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.
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
InterfaceBlock ... for example, in flow properties are conjugated as out flow properties and provided features are conjugated as required features.
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.
~InterfaceBlock::original : InterfaceBlock [1] The InterfaceBlock that this is a conjugation of.
[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 ...
(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).
Using non-flow properties means to read or write them, and using behavioral features means to invoke them.
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
Provided behavioral features are invoked with the owning block as target, while required behavioral features are invoked with an external block as target (required).
Directed features can appear in compartments for the various kinds of properties and behavioral features.
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.
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.
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.
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.
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.
For example, the ports supporting torque flows in the transmission example might have nested ports for physical links to the engine or the driveshaft.
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.
All features shown within these compartments shall match those of the block or value type that types the property.
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 ...
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.
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.
To signify that only water flows between the pump and the tank, we can specify an ItemFlow of type Water on the connector.
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.
In addition, if the item flow identifies an item property, then one can label the item flow with the item property.
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.
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.
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.
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, ...
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.
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 ...
The itemProperty attribute has no values if the item flow is realized by an Association.
FlowProperty::1_restricted_types A FlowProperty shall be typed by a ValueType, Block, or Signal.
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.
For an item flow with an item property, the label shows the name and type of the item property (in name: type format). Otherwise the item flow is labeled with the name of the classifier of the conveyed items.
When several item flows having the same direction are represented, only one triangle is shown, and the list of item flows, separated by a comma is presented.
ItemFlow::2_type_restricted An ItemFlow itemProperty shall be typed by a ValueType, Block, or Signal.
Item flows specify the things that flow between blocks and/or parts and across associations or connectors.
Whereas flow properties specify what “can” flow in or out of a block, item flows specify what “does” flow between blocks and/or parts in a particular usage context.
This important distinction enables blocks to be interconnected in different ways depending on its usage context.
For example, tanks might include a flow property that can accept fluid as an input. In a particular use of tanks, “gasoline” flows across a connector into a tank, and in another use of tanks, “water” flows across a connector into a tank.
The item flow in each case specifies what “does” flow on the connector in the particular usage (e.g., gas, water) and the flow property specifies what can flow (e.g., fluid). This enables type matching between the item flows and between flow properties...
Nested ports that are not on proxy ports can appear anywhere on the boundary of the owning port rectangle that does not overlap the boundary of the rectangle the owning port overlaps.
Port rectangles can have port rectangles overlapping their boundaries, to notate a port type that has ports (nested ports).
Ports that are not proxy or full can appear in block compartments labeled ports.
Ports are specialized kinds of properties, and can be shown in same way as other properties. They can appear in block compartments in the same format as other properties of their owning blocks, or as the ends of associations, with the port appearing ...
All ports and nested ports (i.e., proxy, full, and ports with no stereotype applied), and their type definitions (e.g., interface blocks, blocks) can include compartments with textual and graphical representations to display their features ...
SysML identifies two [EDIT:ADDITIONAL] usage patterns for ports, one where ports act as proxies for their owning blocks or its internal parts (proxy ports), and another where ports specify separate elements of the system (full ports).
Both are ways of defining the boundary of the owning block as features available through external connectors to ports.
Proxy ports define the boundary by specifying which features of the owning block or internal parts are visible through external connectors, while full ports define the boundary with their own features.
Proxy ports are always typed by interface blocks, a specialized kind of block that has no behaviors or internal parts.
Full ports cannot be behavioral in the UML sense of standing in for the owning object, because they handle features themselves, rather than exposing features of their owners, or internal parts of their owners.
Ports that are not specified as proxy or full are simply called “ports.”
In either case, users of a block are only concerned with the features of its ports, regardless of whether the features are surfaced by proxy ports, or handled by full ports directly.
Proxy and full ports support the capabilities of ports in general, but these capabilities are also available on ports that are not declared as proxy or full.
Modelers can choose between proxy or full ports at any time in the development lifecycle, or not at all, depending on their methodology.
Modelers have the option of applying stereotypes for proxy and full ports to indicate whether ports are specifying features of their owners and internal parts (proxy), or for themselves separately (full). This is a concern when defining ports, rather ...
Using existing blocks with ports only requires knowing the port types, because they define the features available for linking or communication with those ports via connectors.
The stereotypes of proxy and full ports might be elided in these cases to simplify diagrams.
Modelers can apply stereotypes for proxy and full ports at any stage of model development, or not all if the stereotype constraints are not needed.
Figure 9-7 happens to use unstereotyped ports on a general block distributed to users, and stereotyped ports on its specializations for implementation, but the modelers might have not used stereotypes at all, if they did not care whether the model met ...
Unstereotyped ports do not commit to whether they are proxy or full, and do not prevent or dictate future application of the stereotypes, except for ports that violate constraints of the stereotypes.
For example, if the port types on the general block in Figure 9-7 had behaviors defined, then the proxy specialization would be invalid. If the general ports had binding connectors to internal parts, then the full specialization would be invalid.
Unstereotyped ports have the basic functionality of stereotyped ones, including flow properties and nested ports, so they can be used as long as the modeler is not concerned with the distinction between proxy and full, and the constraints they impose.
If the general ports had both behaviors and internal binding connectors, then both specializations would be invalid.
Interface blocks cannot have behaviors, including classifier behaviors or methods, or internal parts.
InterfaceBlock::1_no_behavior Interface blocks shall not own or inherit behaviors, have classifier behaviors, or methods for their behavioral features.
InterfaceBlock::3_interfaceblock_typed_ports Ports owned by interface blocks shall only be typed by interface blocks.
InterfaceBlock::2_no_part Interface blocks composite properties are either ports, value properties or flow properties.
Proxy ports identify features of the owning block or its internal parts that are available to external blocks through external connectors to the ports. They do not specify a separate element of the system from the owning block or internal parts.
ProxyPort::1_not_fullport Proxy ports shall not also be full ports. This applies even if some of the stereotypes are on subsetted or redefined ports.
ProxyPort::2_interfaceblock Proxy ports shall only be typed by interface blocks.
ProxyPort::3_subports_are_proxyports Ports owned by the type of a proxy port shall be proxy ports.
Proxy ports can be connected to internal parts or ports on internal parts, identifying features on those parts or ports that are available to external blocks.
When a proxy port is connected to a single internal part [or port or internal part], the connector shall be a binding connector, or have the same semantics as a binding connector ...
BindingConnector::1_compatible_types The two ends of a binding connector shall have either the same type or types that are compatible so that equality of their values can be defined.
(the value of the proxy port and the connected internal part are the same; links of associations typing the connector are between all objects and themselves, and no others)
When a proxy port is connected to multiple internal parts, the connectors have the same semantics as a single binding connector to an aggregate of those parts, supporting all their features, and treating flows and invocations from outside the aggregate...
This aggregate is not a separate element of the system, and only groups the internal parts for purposes of binding to the proxy port.
Internal connectors to proxy ports can be typed by association blocks, including when the connector is binding. Association
Proxy ports do not specify their own behaviors or internal parts, and shall be typed by interface blocks. Their nested ports shall also be proxy ports.
A completely specified proxy port shall describe how any interaction through the port is handled or initiated.
This can be achieved in several ways. For instance by making it behavioral, by binding it to a fully specified internal part or by having all its properties individually bound to internal parts.
However, blocks can be defined with non-behavioral proxy ports that do not have internal connectors, with the expectation that these will be added in specialized blocks.
Internal connectors to ports are the ones inside the ports owner (specifically, they are the ones that do not have a UML partwithPort on the connector end linked to the port, assuming NestedConnectorEnd is not applied to that end, or if NestedConnectorEnd
The rest of the connectors linked to a port are external.
Full ports specify a separate element of the system from the owning block or its internal parts. They might have their own internal parts and behaviors to support interaction with the owning block, its internal parts, or external blocks.
They cannot be behavioral ports, or [be] linked to internal parts by binding connectors, because these constructs imply identity with the owning block or internal parts.
However, full ports can be linked to non-full ports by binding connectors, because this does not necessarily imply identity with other parts of the system.
FullPort::1_not_proxy Full ports shall not also be proxy ports. This applies even if some of the stereotypes are on subsetted or redefined ports.
FullPort::2_not_bound_to_fullport Binding connectors shall not link full ports (either directly or indirectly through other binding connectors) to other composite properties of the block owning the full port (or that blocks generalizations or specializati
FullPort::3_not_behavioral Full ports shall not be behavioral (isBehavior=false).
A requirement specifies a capability or condition that must (or should) be satisfied. A requirement may specify a function that a system must perform or a performance condition a system must achieve.
SysML provides modeling constructs to represent text-based requirements and relate them to other modeling elements.
The requirements diagram described in this clause can depict the requirements in graphical, tabular, or tree structure format. A requirement can also appear on other diagrams to show its relationship to other modeling elements.
The requirements modeling constructs are intended to provide a bridge between traditional requirements management tools and the other SysML models.
A requirement is defined as a stereotype of UML Class subject to a set of constraints.
A standard requirement includes properties to specify its unique identifier and text requirement. Additional properties such as verification status, can be specified by the user.
Several requirements relationships are specified that enable the modeler to relate requirements to other requirements as well as to other model elements.
These include relationships for defining a requirements hierarchy, deriving requirements, satisfying requirements, verifying requirements, and refining requirements.
A composite requirement can contain subrequirements in terms of a requirements hierarchy, specified using the UML namespace containment mechanism. This relationship enables a complex requirement to be decomposed into its containing child requirements.
A composite requirement may state that the system shall do A and B and C, which can be decomposed into the child requirements that the system shall do A, the system shall do B, and the system shall do C
An entire specification can be decomposed into children requirements, which can be further decomposed into their children to define the requirements hierarchy.
An AbstractRequirement establishes the attributes and relationships essential to any potential kind of requirement. Any intended requirement kind should subclass AbstractRequirement.
The only normative stereotype based on AbstractRequirement is the Requirement stereotype, ...
Examples of additional non-normative stereotypes based on AbstractRequirement are included in E.8.
A Verify relationship is a dependency between a requirement and a test case or other model element that can determine whether a system fulfills the requirement. As with other dependencies, the arrow direction points from the (client) element to the (suppl
The Trace stereotype specializes UML4SysML Trace and DirectedRelationshipPropertyPath to enable traces to identify their sources and targets by a multi-level path of accessible properties from context blocks for the sources and targets.
SysML has added some notational extensions to represent stereotype properties in compartments as well as notes.
Refine::getRefines (in ref : NamedElement) : AbstractRequirement [0..*] The query getRefines() gives all the requirements that are suppliers ("to"end of the concrete syntax) of a «Refine» relationships whose client is the element in parameter ...
AbstractRequirement::/tracedTo : NamedElement [0..*] Derived from all elements that are the client of a «trace» relationship for which this requirement is a supplier. (derived) [ERROR]
Trace::getTracedFrom (in ref : NamedElement) : AbstractRequirement [0..*] The query getTracedFrom() gives all the requirements that are clients ("from" end of the concrete syntax) of a «Trace» relationship whose supplier is the element in parameter ...
The DirectedRelationshipPropertyPath stereotype based on UML DirectedRelationship enables directed relationships to identify their sources and targets by a multi-level path of properties accessible from context blocks for the sources and targets.
Context blocks are typically the owner of the first property in the path of properties, but can be specializations of the owner to limit the scope of the relationship.
The use of namespace containment to specify requirements hierarchies precludes reusing requirements in different contexts since a given model element can only exist in one namespace.
Since the concept of requirements reuse is very important in many applications, SysML introduces the concept of a slave requirement.
A slave requirement is a requirement whose text property is a read-only copy of the text property of a master requirement. The text property of the slave requirement is constrained to be the same as the text property of the related master requirement.
The master/slave relationship is indicated by the use of the copy relationship.
AbstractRequirement::/master : AbstractRequirement [0..*] This is a derived property that lists the master requirement for this slave requirement. The master attribute is derived from the supplier of the Copy dependency ...
«functionalRequirement»: satisfied by an operation or behavior
«interfaceRequirement»: satisfied by a port, conector, item flow, and/or constraint property.
«performanceRequirement»: satisfied by a value property.
«designConstraint»: satisfied by a block or part.
«physicalRequirement»: satisfied by a structural element.
Allocation is the term used by systems engineers to denote the organized cross-association (mapping) of elements within the various structures or hierarchies of a user model.
The concept of “allocation” requires flexibility suitable for abstract system specification, rather than a particular constrained method of system or software design.
System modelers often associate various elements in a user model in abstract, preliminary, and sometimes tentative ways. Allocations can be used early in the design as a precursor to more detailed rigorous specifications and implementations.
The allocation relationship can provide an effective means for navigating the model by establishing cross relationships, and ensuring the various parts of the model are properly integrated.
... does not try to limit the use of the term “allocation,” but provides a basic capability to support allocation in the broadest sense. It does include some specific subclasses of allocation for allocating behavior, structure, and flows.
A typical example is the allocation of activities to blocks (e.g., functions to components)
AllocateActivityPartition::1_actions_on_client_ends An Action appearing in an "AllocateActivityPartition" shall be the /client (from) end of an "allocate" dependency. The element that represents the "AllocateActivityPartition" shall be the /supplier ...
AllocateActivityPartition::2_not_uml_semantics The «AllocateActivityPartition» shall maintain the constraints, but not the semantics, of the UML::ActivityPartition.
AllocateActivityPartition::2_not_uml_semantics ... Classifiers or Properties represented by an «AllocateActivityPartition» do not have any direct responsibility for invoking behavior depicted within the partition boundaries. ...
The ElementGroup stereotype provides a lightweight mechanism for grouping various and possibly heterogeneous model elements by extending the capability of comments to refer to multiple annotated elements.
For example, it can group elements that are associated with a particular release of the model, have a certain risk level, or are associated with a legacy design.
The semantics of ElementGroup is modeler-defined. In particular, the body text is not restricted. It can describe the grouped elements as well as elements or values related to the grouped elements.
Element groups are named using the name property.
The criterion for membership in an element group is specified by the body of the comment the stereotype is applied to. By grouping elements, the modeler asserts that the criterion of the group applies to the member.
Optionally, members of an element group can be ordered using its orderedMember property.
ElementGroups appear in diagrams as comments, and properties of the stereotype appear in the notation for stereotype properties.
Grouped elements are the annotated elements of the comment to which the stereotype is applied. This has several implications:
Element groups do not own their elements and thus an element can participate in an unlimited number of groups.
The elements in a group are identified by the modeler, as opposed to being the result of a query, as in views.
Element groups can be members of other element groups, but this does not imply that members of the first are members of the second.
ElementGroup::/criterion : String [0..1] Specifies the rationale for being member of the group. Adding an element to the group asserts that the criterion applies to this element. Derived from Comment::body. (derived)
ElementGroup::/member : Element [0..*] Set specifying the members of the group. Derived from Comment::annotatedElement. (derived)
ElementGroup::name : String [1] Name of the element group
ElementGroup::orderedMember : Element [0..*] Organize member according to an arbitrary order. Optional. (subsets: ElementGroup::member)
ElementGroup::/size : Integer [1] Number of members in the group. Derived. (derived)
A Viewpoint is a specification of the conventions and rules for constructing and using a view for the purpose of addressing a set of stakeholder concerns. They specify the elements expected to be represented in the view...
For example, the security viewpoint may require the security requirements, security functional and physical architecture, and security test cases.
Viewpoint::/concern : String [0..*] The interest of the stakeholders displayed as the body of the comments from concernList. (derived)
Viewpoint::concernList : Comment [0..*] The interests of the stakeholders addressed by this viewpoint.
Viewpoint::language : String [0..*] The languages used to express the models that represent content which is represented by the view. The language specification such as its metamodel, profile, or other language specification is referred to by its URI.
Viewpoint::/method : Behavior [0..*] The behavior is derived from the method of the operation with the Create stereotype. (derived)
Viewpoint::presentation : String [0..*] The specifications prescribed for formatting and styling the view.
Viewpoint::purpose : String [1] The purpose addresses the stakeholder concerns.
Viewpoint::stakeholder : Stakeholder [0..*] Set of stakeholders whose concerns are to be addressed by the viewpoint.
Viewpoint::1_method_derived_from_create_operations The derived values of the method attribute shall be the names of the methods of the operations stereotyped by the UML Create stereotype on the classifier stereotyped by Viewpoint.
Viewpoint::2_create_view_operation The property ownedOperation shall include at least one operation named "View" with the UML Create stereotype applied.
A Conform relationship is a generalization between a view and a viewpoint. The view conforms to the specified rules and conventions detailed in the viewpoint. When this is done, the view is said to conform to the viewpoint.
Stakeholder::/concern : String [0..*] (derived)
Stakeholder::concernList : Comment [0..*]
Although SysML indirectly imports the UML 2 PrimitiveTypes library ... due to the transitivity of package import, SysML provides a PrimitiveValueTypes model library that systems engineers can extend via SysML’s ValueType stereotype.
A compartment with the label “receptions” may appear as part of a block definition to show signal receptions. The “«signal»” keyword is optional in this compartment.
Blocks are modular units of system description.
Each block defines a collection of features to describe a system or other element of interest. These may include both structural and behavioral features, such as properties and operations, to represent the state of the system and behavior ...
Blocks provide a general-purpose capability to model systems as trees of modular components.
The specific kinds of components, the kinds of connections between them, and the way these elements combine to define the total system can all be selected according to the goals of a particular system model.
These include modeling either the logical or physical decomposition of a system, and the specification of software, hardware, or human elements.
Parts in these systems may interact by many different means, such as software operations, discrete state transitions, flows of inputs and outputs, or continuous interactions.
The Block Definition Diagram in SysML defines features of blocks and relationships between blocks such as associations, generalizations, and dependencies.
It captures the definition of blocks in terms of properties and operations, and relationships such as a system hierarchy or a system classification tree
The Internal Block Diagram in SysML captures the internal structure of a block in terms of properties and connectors between properties.
A block can include properties to specify its values, parts, and references to other blocks.
Ports are a special class of property used to specify allowable types of interactions between blocks ...
Constraint Properties are a special class of property used to constrain other properties of blocks...
Various notations for properties are available to distinguish these specialized kinds of properties on an internal block diagram.
A property can represent a role or usage in the context of its enclosing block. A property has a type that supplies its definition.
A part belonging to a block, for example, may be typed by another block. The part defines a local usage of its defining block within the specific context to which the part belongs.
For example, a block that represents the definition of a wheel can be used in different ways. The front wheel and rear wheel can represent different usages of the same wheel definition.
SysML also allows each usage to define context-specific values and constraints associated with the individual usage, such as 25 psi for the front tires and 30 psi for the rear tires.
Blocks may also specify operations or other features that describe the behavior of a system
SysML blocks are based on UML classes as extended by UML composite structures. Some capabilities available for UML classes, such as more specialized forms of associations, have been excluded from SysML blocks to simplify the language.
SysML blocks always include an ability to define internal connectors, regardless of whether this capability is needed for a particular block.
SysML Blocks also extend the capabilities of UML classes and connectors with reusable forms of constraints, multi-level nesting of connector ends, participant properties for composite association classes, and connector properties.
SysML blocks can be used throughout all phases of system specification and design, and can be applied to many different kinds of systems.
SysML establishes four basic classifications of properties belonging to a SysML Block or ValueType.
Constraint properties are further defined in Clause 10. A port is another category of property, as further defined in Section 9.
A property typed by a SysML Block that has composite aggregation is classified as a part property, except for the special case of a constraint property ...
A property typed by a SysML ValueType is classified as a value property, and always has composite aggregation.
Part, reference, value, and constraint properties may be shown in block definition compartments with the labels "parts," "references," "values," and "constraints" respectively.
Properties of any type may be shown in a "properties" compartment or in additional compartments with user-defined labels.
A compartment with the label “structure” may appear as part of a block definition to show connectors and other internal structure elements for the block being defined. This compartment may contain any of the graphical elements of an internal block diagram
Four general categories of properties of blocks are recognized in SysML: parts, references, value properties, and constraint properties.
A part or value property is always shown on an internal block diagram with a solid-outline box.
A reference property is shown by a dashed-outline box, consistent with UML.
Ports are special cases of properties, and have a variety of notations ...
Constraint properties and their parameters also have their own notations ...
Connectors may be drawn that cross the boundaries of nested properties to connect to properties within them. The connector is owned by the most immediate block that owns both ends of the connector.
Block::isEncapsulated : Boolean [0..1] If true, then the block is treated as a black box; a part typed by this black box can only be connected via its ports or directly to its outer boundary.
Block::isEncapsulated : Boolean [0..1] ... If false, or if a value is not present, then connections can be established to elements of its internal structure via deep-nested connector ends.
A Complex value type represents the mathematical concept of a complex number. A complex number consists of a real part defined by a real number, and an imaginary part defined by a real number multiplied by the square root of -1 ...
A Slot designates that an entity modeled by an InstanceSpecification has a value or values for a specific StructuralFeature.
A QuantityKind is a kind of quantity that may be stated by means of defined units. For example, the quantity kind of length may be measured by units of meters, kilometers, or feet.
QuantityKind is defined as a non-abstract SysML Block defined in the SysML UnitAndQuantityKind model library.
QuantityKind, or a specialization of it, classifies an InstanceSpecification to define a particular "kind-of-quantity" in the sense of an "aspect common to mutually comparable quantities" [VIM3-1.2], ...
... a SysML value property is understood to correspond to the VIM concept of "quantity" defined as a "property of a phenomenon, body or substance, where the property has a magnitude that can be expressed as a number and a reference" [VIM3-1.1].
Modelers specialize QuantityKind as done in SysMLs QUDV model library or in a similar manner in other model libraries.
The definitionURI of an InstanceSpecification classified by a kind of QuantityKind identifies the particular "kind-of-quantity" [VIM3-1.2] that the InstanceSpecification represents.
Two such InstanceSpecifications represent the same "kind-of-quantity" if and only if their definitionURIs have values and their values are equal.
The only valid use of a QuantityKind instance is to be referenced by the quantityKind property of a ValueType or Unit.
A Unit is a quantity in terms of which the magnitudes of other quantities that have the same quantity kind can be stated.
A unit often relies on precise and reproducible ways to measure the unit. For example, a unit of length such as meter may be specified as a multiple of a particular wavelength of light.
A unit may also specify less stable or precise ways to express some value, such as a cost expressed in some currency, or a severity rating measured by a numerical scale.
Unit is defined as a non-abstract SysML Block defined in the SysML UnitAndQuantityKind model library.
Unit, or a specialization of it, classifies an InstanceSpecification to define a particular "measurement unit" in the sense of a "real scalar quantity, defined and adopted by convention, with which any other quantity of the same kind can be compared ...
Modelers specialize Unit as done in SysMLs QUDV model library or in a similar manner in other model libraries.
The definitionURI of an InstanceSpecification classified by a kind of Unit identifies the particular "measurement unit" [VIM3-1.9] that the InstanceSpecification represents.
Two such InstanceSpecifications represent the same "measurement unit" if and only if their definitionURIs have values and their values are equal.
The only valid use of a Unit instance is to be referenced by the unit property of a ValueType stereotype.
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.
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.
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.
A DerivedQuantityKind may also be used to define a synonym kind of quantity for another kind of quantity.
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.
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.
In the case of the profile diagram, profile definitions can be captured on a package diagram and the parametric diagram.
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 ...
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 ...
Activity diagrams have also been modified via the activity extensions.
Tabular representations, such as the allocation table, are used in SysML but are not considered part of the diagram taxonomy.
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.
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, ...
When the «optional» stereotype is applied to parameters, the lower multiplicity shall be equal to zero. This means the parameter is not required to have a value for the activity or any behavior to begin or end execution ...
1_lower_is_0 A parameter with the «optional» stereotypes applied shall have multiplicity.lower equal to zero, otherwise multiplicity.lower shall be greater than zero
When the «probability» stereotype is applied to edges coming out of decision nodes and object nodes, it provides an expression for the probability that the edge will be traversed. These shall be between zero and one inclusive, and add up to one ...
When the «probability» stereotype is applied to output parameter sets, it gives the probability the parameter set will be given values at runtime. These shall be between zero and one inclusive, and add up to one for output parameter sets of the same ...
Discrete rate is a special case of rate of flow ... where the increment of time between items is a non-zero. Examples include the production of assemblies in a factory and signals set at periodic time intervals.
When the «nobuffer» stereotype is applied to object nodes, tokens arriving at the node are discarded if they are refused by outgoing edges, or refused by actions for object nodes that are input pins.
This is typically used with fast or continuously flowing data values, to prevent buffer overrun, or to model transient values, such as electrical signals.
For object nodes that are the target of continuous flows, «nobuffer» and «overwrite» have the same effect.
The stereotype does not override UML token offering semantics; it just indicates what happens to the token when it is accepted. When the stereotype is not applied, the semantics are as in UML, specifically, tokens arriving at an object node ...
NoBuffer::1_not_overwrite The «nobuffer» and «overwrite» stereotypes cannot be applied to the same element at the same time
When the «overwrite» stereotype is applied to object nodes, a token arriving at a full object node removes one that is already there before being added (a full object node has as many tokens as allowed by its upper bound).
This is typically used on an input pin with an upper bound of 1 to ensure that stale data is overridden at an input pin.
For upper bounds greater than one, the token removed is the one that has been in the object node the longest. For FIFO ordering, this is the token that is next to be selected, for LIFO it is the token that would be last to be selected.
Tokens arriving at a full object node with the Overwrite stereotype applied take up their positions in the ordering as normal, if any. The arriving tokens do not take the positions of the removed tokens.
A null token removes all the tokens already there.
The number of tokens replaced is equal to the weight of the incoming edge, which defaults to 1.
For object nodes that are the target of continuous flows, «overwrite» and «nobuffer» have the same effect.
The stereotype does not override UML token offering semantics, just indicates what happens to the token when it is accepted. When the stereotype is not applied, the semantics is as in UML, specifically, tokens arriving at object nodes do not replace ...
«streaming» Used for activities that can accept inputs or provide outputs after they start and before they finish. The activity has at least one streaming parameter.
«nonStreaming» Used for activities that accept inputs only when they start, and provide outputs only when they finish. The activity has no streaming parameters.
«effbd» Specifies that the activity conforms to the constraints necessary for EFFBD.
Block:8_specializations_are_blocks: Any classifier that specializes a Block shall also have the Block stereotype or one of its specializations applied.
BoundReference::7_cannot_redefine_boundreference BoundReferences shall not be applied to properties that are related by redefinition to other properties with BoundReference applied.
Block::6_valueproperties_composite: If a property owned by a SysML Block or SysML ValueType is typed by a SysML ValueType, then the aggregation attribute of the property shall be "composite."
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 the type on a block definition diagram.
Stereotypes applying to parameters can appear on object nodes in activity diagrams, as shown in Figure 11-7, when the object node notation is used as a shorthand for pins.
The stereotype applies to all parameters corresponding to the pins notated by the object node.
Stereotypes applied to behaviors may appear on the notation for CallBehaviorAction when invoking those behaviors, as shown in Figure 11-2.
External links
https://www.omg.org/spec/SysML/1.6/PDF
Visit also
Object Management Group™ (OMG™)
SysML zone
Unified Modeling Language 2.5.1
Visit also (backlinks)
OMG Systems Modeling Language (SysML) 1.7beta1
OMG Systems Modeling Language TM (SysML®) Version 2.0 Release 2021-02
There is no «port» stereotype keyword for Port or Property in UML-2.5.1 or SysML-1.6. It is assumed to be introduced in some SysML and SysPhS specification diagrams as a custom or user-defined stereotype for special illustration purposes.
Webel vs SysML-1.6: There is no «port» stereotype keyword for Port or Property in UML-2.5.1 or SysML-1.6, it is introduced as a custom (user-defined) stereotype keyword here only to mimic the spec Figure 9-8.
On OMG copyright in text extracts and figures reproduced for educational purposes