UML/SysML: In Internal Block Diagrams: If you have a Port with a name that indicates a unique role AND and if there is an ItemFlow on a Connector that implies or suggests the Type of the Port, consider hiding the Type on the Port symbol.

Icon class
icon_class
far fa-sticky-note
icon_class_computed
far fa-sticky-note
Note kind
DISPLAY
MODELLING
NAMING
STYLE
Policy level
OPTION
Specification keywords
SysML-1.6
SysML-1.7
UML-2.5.1
UML keywords
NamedElement::name
Property
Port
InformationFlow::conveyed
Connector
SysMLv1.x keywords
"standard" Port
ProxyPort
FullPort
ItemFlow
Keywords
This is in slight contrast to the following modelling options:
Webel Best Practice: UML/SysML: In Internal Block Diagrams: Consider hiding the name of a named Port or Property in a Diagram if its Type is sufficient to indicate its role.
Webel Best Practice: "Trust the Port or Pin Type!" - Often the name of the Type of an anonymous Port or Pin is completely sufficient to indicate its role, unless a clear indication of its direction or unique role is required.

In both cases, the aim is to reduce clutter by removing redundant information (in context).

Note that not showing the Type is ONLY recommended here when there is a clear suggestion of the Type of flowing stuff on a Connector to/from the Port. Showing only the Port name works together with:
Webel Best Practice: Webel: If you must name your Ports or Pins, name them simply 'i', 'o', or 'io' to indicate direction UNLESS you have to indicate a special role like 'iRole', 'oAuxiliary'. DO NOT use Port or Pin names like 'input', 'output', etc.
Relates to
IBD: Context for SimpleDomesticInverterAirCon - detailed
Related notes
[NAMING, POLICY]{STRONG} "Trust the Namespace" - DO NOT repeat information in names of owned elements that can be gleaned from the owner or ancestor (and is usually easily shown using display options). It is WET, it breaks the DRY principle!
[NAMING, POLICY, STYLE] "Trust the Port or Pin Type!" - Often the name of the Type of an anonymous Port or Pin is completely sufficient to indicate its role, unless a clear indication of its direction or unique role is required.
[NAMING, POLICY]{STRONG} Prefer anonymous Actions, or if they must be named, prefer code-like 'lowerCamelCase' or completely 'lower case' (if you do absolutely insist on having spaces in action names, but please no other punctuation).
[NAMING, POLICY]{STRICT} SysML: Naming: Always use either anonymous or first letter lower case for Property, ObjectNode and InstanceSpecification names; no exceptions (unless using names to "quote text")! Valid: 'lowerCamelCase' OR 'tla' vs TLA acronym OR 'uCC' vs UpperCamelCase
[NAMING, POLICY, STYLE]{STRONG} SysML: Webel: "Trust the Type!" - Often the name of the Type of an anonymous Property or instance-level element is completely sufficient to indicate its role - unless multiple Properties of the same Type have different roles within the same owner context!
[CAVEAT]{OPTION} SysMLv1: When using model queries (such as tables) for compliance with some older systems engineering docs you may not always be able to use anonymous Property names and anonymous instance level element names. Or try the owner context or the ID!
[DISPLAY, MODELLING, NAMING, STYLE]{TIP} UML/SysML: In Internal Block Diagrams: Consider hiding the name of a named Port or Property in a Diagram if its Type is sufficient to indicate its role.
[NAMING, POLICY]{STRONG} Use 'UpperCamelCase' (a.k.a. PascalCase) names for Classifiers such as UML Classes and SysML Blocks) to avoid confusion with 'lowerCase' Property names [see however special naming conventions for acronyms and SysML contract and flow Blocks]
Related notes (backlinks)
Related snippets (extracts)
Visit also
Visit also (backlinks)