Snippets (text quotes and extracts from authoritative sources)

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

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

Kind Snippet quote/extract Source UML keywords SysML keywords Keywords
INFO UseCases may have associated Actors, which describe how an instance of the Classifier realizing the UseCase and a user playing one of the roles of the Actor interact. Unified Modeling Language 2.5.1 UseCase, UseCase::subject, Behavior, BehavioredClassifier, Actor, Association
INFO It may also be described indirectly through a Collaboration that uses the UseCase and its Actors as the Classifiers that type its parts. Unified Modeling Language 2.5.1 UseCase, UseCase::subject, Behavior, BehavioredClassifier, Collaboration, Actor, part, Classifier
INFO The behaviors of a UseCase can be described by a set of Behaviors (through its ownedBehavior relationship), such as Interactions, Activities, and StateMachines, as well as by pre-conditions, post-conditions and natural language text where appropriate. Unified Modeling Language 2.5.1 UseCase, UseCase::subject, Behavior, BehavioredClassifier, BehavioredClassifier::ownedBehavior, Interaction, StateMachine, Behavior::precondition, Behavior::postcondition
INFO Moreover, the UseCases may also state the requirements the specified subject poses on its environment by defining how the Actors should interact with the subject so that it will be able to perform its services. Unified Modeling Language 2.5.1 UseCase, UseCase::subject external requirement
INFO UseCases can be used both for specification of the (external) requirements on a subject and for the specification of the functionality offered by a subject. Unified Modeling Language 2.5.1 UseCase, UseCase::subject functional requirement, external requirement
INFO It is deemed complete if, after its execution, the subject will be in a state in which no further inputs or actions are expected and the UseCase can be initiated again, or in an error state. Unified Modeling Language 2.5.1 UseCase, Behavior, BehavioredClassifier, UseCase::subject error handling
INFO Each UseCase specifies a unit of useful functionality that the subject provides to its users (i.e., a specific way of interacting with the subject). This functionality must always be completed for the UseCase to complete. Unified Modeling Language 2.5.1 UseCase, Behavior, BehavioredClassifier, UseCase::subject
INFO A subject of a UseCase could be a system or any other element that may have behavior, such as a Component or Class. Unified Modeling Language 2.5.1 UseCase, Behavior, BehavioredClassifier, Class, Component, UseCase::subject
INFO A UseCase can include possible variations of its basic behavior, including exceptional behavior and error handling. Unified Modeling Language 2.5.1 UseCase, Behavior, BehavioredClassifier error handling
INFO UseCases define the offered Behaviors of the subject without reference to its internal structure. These Behaviors, involving interactions between the Actors and the subject, may result in changes to the state of the subject and communications with its... Unified Modeling Language 2.5.1 UseCase, UseCase::subject, Classifier, Behavior, Actor, BehavioredClassifier black box
INFO A UseCase is a kind of BehavioredClassifier that represents a declaration of a set of offered Behaviors. Each UseCase specifies some behavior that a subject can perform in collaboration with one or more Actors. Unified Modeling Language 2.5.1 UseCase, UseCase::subject, Classifier, Behavior, Actor, BehavioredClassifier
INFO A UseCase may apply to any number of subjects. When a UseCase applies to a subject, it specifies a set of behaviors performed by that subject, which yields an observable result that is of value for Actors or other stakeholders of the subject. Unified Modeling Language 2.5.1 UseCase, UseCase::subject, Classifier, Behavior, Actor
NOTATION In particular, there is scope for confusion between a UseCase appearing visually contained in a boundary rectangle representing a Classifier that is its subject, and appearing visually contained in a compartment of a Classifier that is its owner... Unified Modeling Language 2.5.1 UseCase, UseCase::subject, Classifier
NOTATION Note also that the subject rectangle does not imply that the subject classifier owns the contained UseCases, but merely that the UseCases apply to that classifier. Unified Modeling Language 2.5.1 UseCase, UseCase::subject
NOTATION Note that this notation for the subject classifier differs from the normal Classifier notation – it has no header or compartments. Unified Modeling Language 2.5.1 UseCase, UseCase::subject
CONSTRAINT «physicalRequirement»: satisfied by a structural element. OMG Systems Modeling Language (SysML) 1.6 ExtendedRequirement, AbstractRequirement, «performanceRequirement», Block, part property, MD:PartProperty requirements engineering
CONSTRAINT «designConstraint»: satisfied by a block or part. OMG Systems Modeling Language (SysML) 1.6 ExtendedRequirement, AbstractRequirement, «performanceRequirement», Block, part property, MD:PartProperty requirements engineering
CONSTRAINT «performanceRequirement»: satisfied by a value property. OMG Systems Modeling Language (SysML) 1.6 ExtendedRequirement, AbstractRequirement, «performanceRequirement», value property, MD:ValueProperty requirements engineering
CONSTRAINT «interfaceRequirement»: satisfied by a port, conector, item flow, and/or constraint property. OMG Systems Modeling Language (SysML) 1.6 Operation, Connector ExtendedRequirement, AbstractRequirement, «interfaceRequirement», ItemFlow, constraint property requirements engineering
CONSTRAINT «functionalRequirement»: satisfied by an operation or behavior OMG Systems Modeling Language (SysML) 1.6 Operation, Behavior «functionalRequirement», ExtendedRequirement, AbstractRequirement requirements engineering
INFO 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 ... OMG Systems Modeling Language (SysML) 1.6 Dependency::supplier, Dependency::client AbstractRequirement, Requirement, Copy, AbstractRequirement::/master, AbstractRequirement::text requirements engineering
INFO The master/slave relationship is indicated by the use of the copy relationship. OMG Systems Modeling Language (SysML) 1.6 Dependency::supplier, Dependency::client AbstractRequirement, Requirement, Copy, AbstractRequirement::/master, AbstractRequirement::text requirements engineering
INFO 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. OMG Systems Modeling Language (SysML) 1.6 Dependency::supplier, Dependency::client AbstractRequirement, Requirement, Copy, AbstractRequirement::/master, AbstractRequirement::text requirements engineering
INFO Since the concept of requirements reuse is very important in many applications, SysML introduces the concept of a slave requirement. OMG Systems Modeling Language (SysML) 1.6 AbstractRequirement, Requirement, Copy, AbstractRequirement::/master requirements engineering, primary/replica
INFO 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. OMG Systems Modeling Language (SysML) 1.6 AbstractRequirement, Requirement, composite (compound) requirement
INFO 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. OMG Systems Modeling Language (SysML) 1.6 DirectedRelationship, DirectedRelationship::/source, DirectedRelationship::/target DirectedRelationshipPropertyPath, DirectedRelationshipPropertyPath::sourceContext, DirectedRelationshipPropertyPath::sourcePropertyPath, DirectedRelationshipPropertyPath::targetContext, DirectedRelationshipPropertyPath::targetPropertyPath
INFO 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. OMG Systems Modeling Language (SysML) 1.6 DirectedRelationship, DirectedRelationship::/source, DirectedRelationship::/target DirectedRelationshipPropertyPath, DirectedRelationshipPropertyPath::sourceContext, DirectedRelationshipPropertyPath::sourcePropertyPath, DirectedRelationshipPropertyPath::targetContext, DirectedRelationshipPropertyPath::targetPropertyPath
INFO 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 ... OMG Systems Modeling Language (SysML) 1.6 «trace», NamedElement Trace, Trace::getTracedFrom(in ref), AbstractRequirement
INFO 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] OMG Systems Modeling Language (SysML) 1.6 «trace» Trace, AbstractRequirement::/tracedTo
INFO 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 ... OMG Systems Modeling Language (SysML) 1.6 query Refine, Refine::getRefines(in ref : NamedElement)
NOTATION SysML has added some notational extensions to represent stereotype properties in compartments as well as notes. OMG Systems Modeling Language (SysML) 1.6 compartment, Stereotype, Note SysML
INFO A Class has four mandatory compartments: attributes, operations, receptions ... and internal structure ... A Class may also have optional compartments as described for Classifiers in general Unified Modeling Language 2.5.1 Class, Classifier, symbol, compartment, attribute, attributes compartment, Operation, operations compartment, Reception, receptions compartment, internal structure compartment, optional compartment
INFO A Class is shown using the Classifier symbol. As Class is the most widely used Classifier, no keyword is needed to indicate that the metaclass is Class. Unified Modeling Language 2.5.1 Class, Classifier, symbol
INFO 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. OMG Systems Modeling Language (SysML) 1.6 DirectedRelationship::/source, DirectedRelationship::/target, Trace DirectedRelationshipPropertyPath, Trace, AbstractRequirement::/tracedTo
INFO 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 OMG Systems Modeling Language (SysML) 1.6 Dependency, Dependency::client, Dependency::supplier Verify, Requirement
INFO Examples of additional non-normative stereotypes based on AbstractRequirement are included in E.8. OMG Systems Modeling Language (SysML) 1.6 AbstractRequirement, Requirement
INFO The only normative stereotype based on AbstractRequirement is the Requirement stereotype, ... OMG Systems Modeling Language (SysML) 1.6 AbstractRequirement, Requirement
INFO An AbstractRequirement establishes the attributes and relationships essential to any potential kind of requirement. Any intended requirement kind should subclass AbstractRequirement. OMG Systems Modeling Language (SysML) 1.6 AbstractRequirement, Requirement
INFO An entire specification can be decomposed into children requirements, which can be further decomposed into their children to define the requirements hierarchy. OMG Systems Modeling Language (SysML) 1.6 Namespace, Element::owner, containment Requirement, SysML Requirements Diagram, composite (compound) requirement requirements engineering
INFO 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 OMG Systems Modeling Language (SysML) 1.6 Namespace, Element::owner, containment Requirement, SysML Requirements Diagram, composite (compound) requirement requirements engineering
INFO 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. OMG Systems Modeling Language (SysML) 1.6 Namespace, Element::owner Requirement, SysML Requirements Diagram, composite (compound) requirement requirements engineering
INFO These include relationships for defining a requirements hierarchy, deriving requirements, satisfying requirements, verifying requirements, and refining requirements. OMG Systems Modeling Language (SysML) 1.6 Requirement, SysML Requirements Diagram, Satisfy, DeriveReqt, Copy, Verify requirements engineering
INFO Several requirements relationships are specified that enable the modeler to relate requirements to other requirements as well as to other model elements. OMG Systems Modeling Language (SysML) 1.6 Requirement, SysML Requirements Diagram, Satisfy, DeriveReqt, Copy, Verify requirements engineering
INFO 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. OMG Systems Modeling Language (SysML) 1.6 Requirement, SysML Requirements Diagram, AbstractRequirement::text, AbstractRequirement::id requirements engineering
INFO A requirement is defined as a stereotype of UML Class subject to a set of constraints. OMG Systems Modeling Language (SysML) 1.6 Class, Stereotype Requirement, SysML Requirements Diagram requirements engineering
INFO The requirements modeling constructs are intended to provide a bridge between traditional requirements management tools and the other SysML models. OMG Systems Modeling Language (SysML) 1.6 Requirement, AbstractRequirement::text, Satisfy, Verify, DeriveReqt, Copy, SysML Requirements Diagram requirements engineering
INFO 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. OMG Systems Modeling Language (SysML) 1.6 Requirement, AbstractRequirement::text, Satisfy, Verify, DeriveReqt, Copy, SysML Requirements Diagram requirements engineering
INFO SysML provides modeling constructs to represent text-based requirements and relate them to other modeling elements. OMG Systems Modeling Language (SysML) 1.6 Requirement, AbstractRequirement::text, Satisfy, Verify, DeriveReqt, Copy requirements engineering
INFO 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. OMG Systems Modeling Language (SysML) 1.6 Requirement requirements engineering
CONSTRAINT FullPort::3_not_behavioral Full ports shall not be behavioral (isBehavior=false). OMG Systems Modeling Language (SysML) 1.6 Port::isBehavior FullPort
CONSTRAINT 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 OMG Systems Modeling Language (SysML) 1.6 Port, internal part, AggregationKind::composite, Generalization FullPort, Block, part property, owning Block, value property, block property, BindingConnector
CONSTRAINT 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. OMG Systems Modeling Language (SysML) 1.6 Port FullPort, ProxyPort
INFO 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. OMG Systems Modeling Language (SysML) 1.6 Port::isBehavior, Port FullPort, BindingConnector
INFO 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. OMG Systems Modeling Language (SysML) 1.6 Port::isBehavior, Port, Element::owner, internal part FullPort, Block, part property, MD:PartProperty, BindingConnector, owning Block
INFO 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. OMG Systems Modeling Language (SysML) 1.6 Port, internal part, Behavior FullPort, Block, part property, MD:PartProperty
INFO The rest of the connectors linked to a port are external. OMG Systems Modeling Language (SysML) 1.6 Port, ConnectorEnd::partwithPort, internal Connector NestedConnectorEnd
INFO 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 OMG Systems Modeling Language (SysML) 1.6 Port, ConnectorEnd::partwithPort, internal Connector NestedConnectorEnd
INFO 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. OMG Systems Modeling Language (SysML) 1.6 Port::isBehavior ProxyPort
INFO 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. OMG Systems Modeling Language (SysML) 1.6 Port::isBehavior ProxyPort
INFO A completely specified proxy port shall describe how any interaction through the port is handled or initiated. OMG Systems Modeling Language (SysML) 1.6 ProxyPort
INFO 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. OMG Systems Modeling Language (SysML) 1.6 Port, Behavior, part ProxyPort, InterfaceBlock, nested Port, part property
CONSTRAINT, INFO Internal connectors to proxy ports can be typed by association blocks, including when the connector is binding. Association OMG Systems Modeling Language (SysML) 1.6 Port, Feature, Connector, internal Connector ProxyPort, BindingConnector, AssociationBlock
CONSTRAINT, INFO This aggregate is not a separate element of the system, and only groups the internal parts for purposes of binding to the proxy port. OMG Systems Modeling Language (SysML) 1.6 Port, part, Feature ProxyPort, part property, MD:PartProperty, BindingConnector
CONSTRAINT, INFO 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... OMG Systems Modeling Language (SysML) 1.6 Port, part, Feature ProxyPort, part property, MD:PartProperty, BindingConnector
CONSTRAINT, INFO (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) OMG Systems Modeling Language (SysML) 1.6 Port, part, Association ProxyPort, part property, MD:PartProperty, BindingConnector
CONSTRAINT 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. OMG Systems Modeling Language (SysML) 1.6 Connector, ConnectorEnd BindingConnector
CONSTRAINT, INFO 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 ... OMG Systems Modeling Language (SysML) 1.6 Port, part ProxyPort, part property, MD:PartProperty, BindingConnector
INFO 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. OMG Systems Modeling Language (SysML) 1.6 Port, part, Feature ProxyPort, part property, MD:PartProperty
CONSTRAINT ProxyPort::3_subports_are_proxyports Ports owned by the type of a proxy port shall be proxy ports. OMG Systems Modeling Language (SysML) 1.6 ProxyPort, nested Port
CONSTRAINT ProxyPort::2_interfaceblock Proxy ports shall only be typed by interface blocks. OMG Systems Modeling Language (SysML) 1.6 ProxyPort, InterfaceBlock
INFO 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. OMG Systems Modeling Language (SysML) 1.6 internal part, external Connector, Feature, Connector Connector, external Connector, ProxyPort
CONSTRAINT 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. OMG Systems Modeling Language (SysML) 1.6 Property::redefinedProperty, Property::subsettedProperty ProxyPort
CONSTRAINT InterfaceBlock::2_no_part Interface blocks composite properties are either ports, value properties or flow properties. OMG Systems Modeling Language (SysML) 1.6 Port, AggregationKind::composite InterfaceBlock, ~InterfaceBlock, value property, FlowProperty
CONSTRAINT InterfaceBlock::isconjugated_not_used Any port typed by an InterfaceBlock shall have its isConjugated property set to false. OMG Systems Modeling Language (SysML) 1.7beta1 Port::isConjugated InterfaceBlock, ~InterfaceBlock
CONSTRAINT InterfaceBlock::3_interfaceblock_typed_ports Ports owned by interface blocks shall only be typed by interface blocks. OMG Systems Modeling Language (SysML) 1.6 InterfaceBlock, ~InterfaceBlock
CONSTRAINT InterfaceBlock::1_no_behavior Interface blocks shall not own or inherit behaviors, have classifier behaviors, or methods for their behavioral features. OMG Systems Modeling Language (SysML) 1.6 InterfaceBlock, ~InterfaceBlock
CONSTRAINT Interface blocks cannot have behaviors, including classifier behaviors or methods, or internal parts. OMG Systems Modeling Language (SysML) 1.6 InterfaceBlock, ~InterfaceBlock
INFO If the general ports had both behaviors and internal binding connectors, then both specializations would be invalid. OMG Systems Modeling Language (SysML) 1.6 Port FullPort, "standard" Port, ProxyPort
INFO 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. OMG Systems Modeling Language (SysML) 1.6 Port FullPort, "standard" Port, ProxyPort
INFO 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. OMG Systems Modeling Language (SysML) 1.6 Port FullPort, "standard" Port, ProxyPort
INFO 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. OMG Systems Modeling Language (SysML) 1.6 Port FullPort, "standard" Port, ProxyPort
INFO 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 ... OMG Systems Modeling Language (SysML) 1.6 Port FullPort, "standard" Port, ProxyPort
INFO 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. OMG Systems Modeling Language (SysML) 1.6 Port FullPort, "standard" Port, ProxyPort
INFO The stereotypes of proxy and full ports might be elided in these cases to simplify diagrams. OMG Systems Modeling Language (SysML) 1.6 Port FullPort, "standard" Port, ProxyPort
INFO 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. OMG Systems Modeling Language (SysML) 1.6 Port FullPort, "standard" Port, ProxyPort
INFO 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 ... OMG Systems Modeling Language (SysML) 1.6 Port FullPort, "standard" Port, ProxyPort
INFO Modelers can choose between proxy or full ports at any time in the development lifecycle, or not at all, depending on their methodology. OMG Systems Modeling Language (SysML) 1.6 Port FullPort, "standard" Port, ProxyPort
INFO 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. OMG Systems Modeling Language (SysML) 1.6 Port FullPort, "standard" Port, ProxyPort
INFO 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. OMG Systems Modeling Language (SysML) 1.6 Port FullPort, "standard" Port, ProxyPort
INFO Ports that are not specified as proxy or full are simply called “ports.” OMG Systems Modeling Language (SysML) 1.6 Port
INFO 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. OMG Systems Modeling Language (SysML) 1.6 Port, Port::isBehavior FullPort
INFO Proxy ports are always typed by interface blocks, a specialized kind of block that has no behaviors or internal parts. OMG Systems Modeling Language (SysML) 1.6 Port ProxyPort, InterfaceBlock, ~InterfaceBlock
INFO 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. OMG Systems Modeling Language (SysML) 1.6 Port ProxyPort, FullPort
INFO Both are ways of defining the boundary of the owning block as features available through external connectors to ports. OMG Systems Modeling Language (SysML) 1.6 Port ProxyPort, FullPort
INFO 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). OMG Systems Modeling Language (SysML) 1.6 Port ProxyPort, FullPort
INFO, NOTATION 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 ... OMG Systems Modeling Language (SysML) 1.6 Port, compartment, Property, Feature nested Port, block compartment, ProxyPort, FullPort, Block, InterfaceBlock
INFO, NOTATION 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 ... OMG Systems Modeling Language (SysML) 1.6 Port, compartment, Property, Association, Association::memberEnd, Association::ownedEnd nested Port, block compartment
INFO, NOTATION Ports that are not proxy or full can appear in block compartments labeled ports. OMG Systems Modeling Language (SysML) 1.6 Port, compartment, ports compartment nested Port, block compartment
INFO, NOTATION Port rectangles can have port rectangles overlapping their boundaries, to notate a port type that has ports (nested ports). OMG Systems Modeling Language (SysML) 1.6 Port nested Port
INFO, NOTATION 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. OMG Systems Modeling Language (SysML) 1.6 Port nested Port