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 Viewpoint::presentation : String [0..*] The specifications prescribed for formatting and styling the view. OMG Systems Modeling Language (SysML) 1.6 String Viewpoint, Viewpoint::presentation, View
INFO Viewpoint::/method : Behavior [0..*] The behavior is derived from the method of the operation with the Create stereotype. (derived) OMG Systems Modeling Language (SysML) 1.6 Behavior, «Create», constructor, Operation, BehavioralFeature::method Viewpoint, Viewpoint::/method URI, URL
INFO 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. OMG Systems Modeling Language (SysML) 1.6 Viewpoint, Viewpoint::language URI, URL
INFO Viewpoint::concernList : Comment [0..*] The interests of the stakeholders addressed by this viewpoint. OMG Systems Modeling Language (SysML) 1.6 Comment::body Viewpoint, Stakeholder, Stakeholder::/concern, Viewpoint::/concern, Stakeholder::concernList, Viewpoint::concernList
INFO Viewpoint::/concern : String [0..*] The interest of the stakeholders displayed as the body of the comments from concernList. (derived) OMG Systems Modeling Language (SysML) 1.6 Comment::body Viewpoint, Stakeholder, Stakeholder::/concern, Viewpoint::/concern, Stakeholder::concernList, Viewpoint::concernList
INFO For example, the security viewpoint may require the security requirements, security functional and physical architecture, and security test cases. OMG Systems Modeling Language (SysML) 1.6 Viewpoint, Stakeholder, Stakeholder::/concern, Viewpoint::/concern, View
INFO 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... OMG Systems Modeling Language (SysML) 1.6 Viewpoint, Stakeholder, Stakeholder::/concern, Viewpoint::/concern, View
INFO Just like a Class, a Stereotype may have Properties, which have traditionally been referred to as Tag Definitions. When a Stereotype is applied to a model element, the values of the Properties have traditionally been referred to as tagged values. Unified Modeling Language 2.5.1 Stereotype, stereotype Property, tagged value, tag definition
CONSTRAINT A stereotype must be contained, directly or indirectly, in a profile. Unified Modeling Language 2.5.1 Stereotype, Profile
INFO A Comment is shown as a rectangle with the upper right corner bent (this is also known as a “note symbol”). The rectangle contains the body of the Comment. The connection to each annotatedElement is shown by a separate dashed line. Unified Modeling Language 2.5.1 Comment, Comment::annotatedElement, Comment::body, MD:anchor
INFO ElementGroup::/size : Integer [1] Number of members in the group. Derived. (derived) OMG Systems Modeling Language (SysML) 1.6 Comment ElementGroup, ElementGroup::/size, ElementGroup::/member
INFO ElementGroup::orderedMember : Element [0..*] Organize member according to an arbitrary order. Optional. (subsets: ElementGroup::member) OMG Systems Modeling Language (SysML) 1.6 Comment ElementGroup, ElementGroup::orderedMember
INFO ElementGroup::name : String [1] Name of the element group OMG Systems Modeling Language (SysML) 1.6 Comment ElementGroup, ElementGroup::name
INFO ElementGroup::/member : Element [0..*] Set specifying the members of the group. Derived from Comment::annotatedElement. (derived) OMG Systems Modeling Language (SysML) 1.6 Comment, Comment::annotatedElement ElementGroup, ElementGroup::/member
INFO 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) OMG Systems Modeling Language (SysML) 1.6 Comment, Comment::body ElementGroup, ElementGroup::/criterion, ElementGroup::/member
INFO Element groups can be members of other element groups, but this does not imply that members of the first are members of the second. OMG Systems Modeling Language (SysML) 1.6 Comment, Comment::annotatedElement ElementGroup, ElementGroup::/member
INFO The elements in a group are identified by the modeler, as opposed to being the result of a query, as in views. OMG Systems Modeling Language (SysML) 1.6 Comment, Comment::annotatedElement ElementGroup, ElementGroup::/member
INFO Element groups do not own their elements and thus an element can participate in an unlimited number of groups. OMG Systems Modeling Language (SysML) 1.6 Comment, Comment::annotatedElement ElementGroup, ElementGroup::/member
INFO Grouped elements are the annotated elements of the comment to which the stereotype is applied. This has several implications: OMG Systems Modeling Language (SysML) 1.6 Comment, Comment::annotatedElement ElementGroup, ElementGroup::/member
INFO ElementGroups appear in diagrams as comments, and properties of the stereotype appear in the notation for stereotype properties. OMG Systems Modeling Language (SysML) 1.6 Comment, Stereotype, stereotype Property ElementGroup
INFO Optionally, members of an element group can be ordered using its orderedMember property. OMG Systems Modeling Language (SysML) 1.6 Comment ElementGroup, ElementGroup::/member, ElementGroup::orderedMember
INFO 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. OMG Systems Modeling Language (SysML) 1.6 Comment, Comment::body ElementGroup, ElementGroup::/member, ElementGroup::/criterion
INFO Element groups are named using the name property. OMG Systems Modeling Language (SysML) 1.6 Comment ElementGroup, ElementGroup::name
INFO 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. OMG Systems Modeling Language (SysML) 1.6 Comment ElementGroup
INFO 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. OMG Systems Modeling Language (SysML) 1.6 Comment ElementGroup
INFO 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. OMG Systems Modeling Language (SysML) 1.6 Comment ElementGroup
INFO 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. ... OMG Systems Modeling Language (SysML) 1.6 ActivityPartition AllocateActivityPartition, behavior allocation functional allocation
INFO AllocateActivityPartition::2_not_uml_semantics The «AllocateActivityPartition» shall maintain the constraints, but not the semantics, of the UML::ActivityPartition. OMG Systems Modeling Language (SysML) 1.6 ActivityPartition AllocateActivityPartition, behavior allocation functional allocation
CONSTRAINT 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 ... OMG Systems Modeling Language (SysML) 1.6 Dependency::client, Dependency::supplier AllocateActivityPartition, Allocate
INFO A typical example is the allocation of activities to blocks (e.g., functions to components) OMG Systems Modeling Language (SysML) 1.6 Allocate, behavior allocation functional allocation
INFO ... 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. OMG Systems Modeling Language (SysML) 1.6 Allocate, behavior allocation functional allocation, structural allocation, flow allocation
INFO 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. OMG Systems Modeling Language (SysML) 1.6 Allocate
INFO 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. OMG Systems Modeling Language (SysML) 1.6 Allocate
INFO The concept of “allocation” requires flexibility suitable for abstract system specification, rather than a particular constrained method of system or software design. OMG Systems Modeling Language (SysML) 1.6 Allocate
INFO 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. OMG Systems Modeling Language (SysML) 1.6 Allocate
INFO UseCases need not be owned by their subject. Unified Modeling Language 2.5.1 UseCase, UseCase::subject
INFO A UseCase may be owned either by a Package or by a Classifier. Although the owning Classifier typically represents a subject to which the owned UseCases apply, this is not necessarily the case ... Unified Modeling Language 2.5.1 UseCase, UseCase::subject, Behavior, BehavioredClassifier, Package, Classifier
CONSTRAINT, INFO Two UseCases specifying the same subject cannot be associated as each of them individually describes a complete usage of the subject. Unified Modeling Language 2.5.1 UseCase, UseCase::subject, Behavior, BehavioredClassifier, Association
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