Webel: SysMLv1.x: TIP: The name and documentation of a ValueType can indicate and specify more than just the unit and quantity kind. Example: A ClockFrequency may document how the frequency is measured. Example: WeightOnEarth.
Mathematica: TIP: Maintain a Package library of variables for convenient units using a naming convention unit$[unitSymbol]
Mathematica: Webel: You CAN/MAY use $ in variable names and function names - just not as the first character before a Capital - and it's extremely useful. You won't get sent to Azkaban prison if do you use a $ character!
Webel: SysML: Electronics modelling: TIP: Use a custom Connector stereotype '<>' with the keyword '<>' to carry a 'net' property. (Use of punctuation in Stereotype names is not usually recommended and the keyword is not usually displayed.)
Webel Parsing Analysis: Pseudo Semantic Triple: When «pa:triple» is applied to a named uni-directional Association the name and a consistent direction arrow should be displayed on the Association symbol in diagrams.
Webel Parsing Analysis: Pseudo Semantic Triple: For «pa:triple» applied to a named one-to-one Dependency, the source is the subject, the name of the Dependency is the predicate, the target is the object.
Webel Parsing Analysis: Pseudo Semantic Triple: For «pa:triple» applied to a named one-to-one or one-to-many uni-directional Association, the non-navigable end Property is the subject, the name is the predicate, the navigable end Property is the object.
Webel Parsing Analysis: The name of a Parsing Analysis Diagram (PAD) may be drawn from a focus Snippet OR may simply indicate a topic of interest to the analysis
Webel Parsing Analysis: Where too many dashed line "anchors" from Snippets to elicited members lead to clutter they may be selectively omitted from a Parsing Analysis Diagram (PAD) once each member has been collected.
Webel Parsing Analysis: While Associations may be collected as elicited members of a Snippet this can quickly lead to clutter in the /member list display. Often just collecting an end Property as member is sufficient.
Webel Parsing Analysis: While Generalizations may be collected as elicited members of a Snippet this can quickly lead to clutter in the /member list display.
Webel Parsing Analysis: An anonymous Element may be collected as a /member of a Snippet (it is not important whether collected elements list with a clear name under /member, only that they are traceably elicited).
Webel Parsing Analysis: Acronym: PAD = Parsing Analysis Diagram (may be nearly any diagram type, except those types that must be owned by an elicited model element)
Naming: If SISO is 'Single Input Single Output' then 'Double Input Single Output (DISO)' is more consistent than 'Two Input Single Output (TISO)', otherwise you'd have to have a 'One Input Single Input (OISO)' for consistency. But who ever says OISO?
SysML vs Modelica: GOTCHA: Terminology: A 'connector' in Modelica is equivalent to the Type of a Port in SysML. A Connector in SysML-1.x is equivalent to a 'connect(source,target)' in Modelica.
SysML: Naming: You may include Block, ValueType, and Signal names in the names of Behaviors (such as Activities) as long as this does not undermine the principles of functional analysis and allocation.
SysML: Naming: Including Block, ValueType, and Signal names in the names of Behaviors (such as Activities) can sometimes undermine purist functional allocation (because it may presuppose the element of the physical solution that carries out the function).
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.
In the Webel terminology for a basic control loop there is an 'aim' value (controlled via an actuator) and a 'got' value (a value read from a sensor). The 'got' value is NOT necessarily exactly the same as the actual physical value.
Webel vs SysPhS-1.1: Annex A.5: Humidifier: Where ValueTypes involving litre are defined, the Unit symbol "L" is used rather than the Modelica-preferred "l" (in combination with an explicit additional unit converter).
Webel vs SysPhS-1.1: Annex A.5: Humidifier: Where custom ValueTypes are defined, Modelica-friendly Unit symbols are used. Examples: "m3" not "m^3"; "degC" not "°C"; "J/(K.L)" (full stop as multiplier) not "J/(K⋅L)"; (EXCEPT "L" for litre not "l").
Webel: SysML: DO NOT sacrifice modelling naming conventions for the mere sake of carrying organisation-specific names! Instead use tagged values of custom stereotypes as metadata to carry alternative names in parallel with systematic model element names.
SysML/SysPhS-1.1: Anonymous Property or Action names may not be an option if: You are exporting to Modelica or Simulink; You absolutely need names for generated query reports (such as generated Interface Control Documents).
Webel: In some SysML trails ValueType names with Unit indicator suffixes have been used for dimensional analysis and illustrative purposes. This practice is NOT otherwise recommended here. Instead just use consistent custom ValueTypes across your system!
Block naming: If you find you've got similar blocks named 'Thing' and 'Thing2' then 'Thing' is probably better renamed 'Thing1'
MagicDraw/Cameo: v19SP3: Property created by dragging onto a Class or Block a symbol of a Classifier named with a single letter capital name 'N' has a poor name 'N:N'
Concerning definitions: "a connector end" vs "a connector between 2 ends" vs "connection" vs "connect" in various technologies
Modelica: Naming convention: Why does the OnePort family of electrical components have 2 Pins? Where is the "one port"?
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
Suffix the "focus" BDD for a Block with .bdd so that it won't clash with a corresponding IBD on diagram export.
Webel: SysMLv1.x: AVOID (where possible) SysML Unit names that are the same as unit symbols. Unit names SHOULD start with a lower case Latin alpha letter. Custom Unit names should be a single lower case word or lowerCamelCase.
MagicDraw/Cameo v19SP3: The SysML 'properties' compartment of a ValueType is called 'attributes' like in UML2.5.1 for DataTypes [CLAIMED FIXED in v2021x]
If using "French style" post-adjective naming in English use a trailing underscore after the noun and before the adjective or qualifier: Vin_rouge, Cable_digital. Can be combined with TLA acronyms: Player_DVD.
MagicDraw/Cameo v19SP3: uses the Block compartment name 'signal receptions' instead of just 'receptions'. [CLAIMED FIXED in v2021x]
The name of a «testCase» Behavior may be verbose and may use natural language, but should always start with a Capital letter.
Webel has a proposal for clearly revealing anonymous typed elements in SysML callouts and on derived Properties from operation queries.
Verbose block property names and port names can help tracing participation of properties and ports in requirements relationships and play nicely with current SysML callout style.
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 names like 'input', 'output', etc.
"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.
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.
The UML InformationFlow notation and the SysML ItemFlow notation can sometimes clash with the notation of named Associations and named and typed Connectors
MagicDraw/Cameo: By implementation the name of some Stereotype attributes and operations is UpperCase instead of lowerCase like in the UML and SysML specs
Use of 'this-that' with a hyphen in Connector names is admissable (where 'this' and 'that' indicate Connector ends or their types)
DO NOT use Property names that are identical to the names of the Classifier (Class, DataType, Block, ValueType) that type them!
MagicDraw/Cameo: SysMLv1.x: ValueType naming: The ISO-80000 libraries use 'lower case' (sometimes with spaces for compound units and/or with [scaling] indicated in square brackets).
Webel: SysMLv1.x: AVOID (where possible) ValueType names that are the same as the name of units or unit symbols
The SysML block compartment name 'initialValues' for what are really "context-specific values" is confusing - even completely misleading; please just think of them as 'contextValues' (and initial values as a special context case)
The Webel trail versions of the Activity Diagrams D.36 and D.38 use the name 'transMode' for the output Parameter and corresponding ActivityParameterNode (consistent with the spec figure D.38) NOT 'transMode_imported' (as in spec figure D.36)
Avoid punctuation in Property names (except when used to "quote text"). You can usually avoid underscores in Property names (even if they are used in the Type name) if you can "Trust the Type"!
Webel: "Trust the Metaclass or Stereotype" of an Element to indicate what type of element it is (you don't have to repeat it in the name)
Webel: DO NOT name the Type (Block or InterfaceBlock) of a Port with a flow the same as the name of the 'Stuff' that flows through it; use the Webel 'F_Stuff' convention!
SysML-1.6: Naming inconsistencies 'Figure D.24 is a parametric diagram showing how fuel flowrate is related to FuelDemand and FuelPressure value properties.'
DO NOT use spaces in Property names or Class/Block names! If you want to communicate familiar names of elements within an organisation use a custom stereotype and tagged values (such as 'aka')!
FlowProperty naming. Use anonymous or just 'i' for in, 'o' for out, and 'io' for inout. "Trust the Type". For conjugation ~InterfaceBlock use 'o' for in, 'i' for out, and 'oi' for inout.
DO NOT name ports with first letter capital (like 'Port'), DO NOT name ports 'port' (except for educational illustration), and DO NOT use port names that do not indicate a role.
Webel suggests using a verbose 'name' for leaf (child) Requirements but NO 'text' to prevent Single Source of Truth issues and for improved callout vs relationships (but this might not always work when syncing with external requirements management tools)
"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!
"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!
The Webel modelling style, naming conventions, and Best Practices for SysML are more consistent than most SysML specification diagrams. When following Webel courses please DO NOT use the spec sample diagrams as visual references!
Webel: For SysML Blocks and InterfaceBlocks used to type Ports with physical flows use 'F_UpperCamelCase' [may be combined with acronymn conventions
For SysML Blocks and InterfaceBlocks used to type Ports with contracts use the naming convention 'I_UpperCamelCase' [may be combined with acronymn conventions]
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
When using acronyms in names of Classifiers either treat them as a word 'TlaLikeThis' or suffix with an underscore 'TLA_LikeThis', except at the end of the name 'LikeThisTLA' is admissable.
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]
Prefer anonymous Actions, or if they must be named, prefer 'lowerCamelCase' or completely 'lower case' (if you do absolutely insist on having spaces in action names, but please no other punctuation).
Prefer 'UpperCamelCase' (a.k.a. PascalCase) names for Behaviors such as Activities intended for use in CallBehaviorActions, or at least use a 'Capital first letter'; avoid 'all lower case' (as it leads to confusion with lower case Action names)
