Webel Twin Pattern: A «digital» DigitalEntity (a.k.a. @Entity) encapsulates strictly geometrical, spatial, and material aspects of a «physical» PhysicalEntity only. BY DEFINITION of this pattern it DOES NOT encapsulate processes!
Webel: Convention: [MIGHT CHANGE]: An '@' prefix in a DigitalTwin model indicates a «digital» Block that maps a non-digital «mappable» Block.
SysML: Some users employed the ~ tilde prefix for a conjugated Port type long before it was introduced for ~InterfaceBlock and you MAY use it to name a regular Block that is not an ~InterfaceBlock
Webel: SysML-1.7/SysMLv2: WISHLIST: Constraint: A BindingConnector used for pure proxying MUST NOT be typed by an AssociationBlock by definition, because the associated information can be mis-appropriated to undermine the proxy equality!
You can use custom stereotypes keywords «i» and «o» to indicate value properties that are intended to be used as (i)nputs and (o)utput when bound to constraint parameters for SysML Parametrics
Computed category membership test values are sometimes adequate and can prevent Class/Block explosion. However, a dedicated Class/Block encapsulating a clear domain concept offers a clear documentation point and can carry other characterising features.
In professional applications of the Webel Parsing Analysis recipe for SysML, a robust reusable profile for «part»/«assembly»/«leaf» components is used, along with stereotypes keywords like «assembles» for indicating physical composition hierarchies.
In the Webel recipe for UML/SysML, the pattern of progressive redefinition of end Properties of Associations between progressively more specialised pairs of Blocks at the same level of abstraction is informally called a "redefinition ladder"
Do export your UML/SysML presentation diagrams (only, not every diagram) regularly as static images; it will help you develop diagrams that are better balanced and communicate well with stakeholders.
Webel Parsing Analysis diagrams do their job once - namely traceable elicitation of model elements - and are then only kept as a reference! The elicited model elements are then used elsewhere in the final model.
