Webel: SysML: "Really long human friendly element names with spaces make my diagrams easier to read". Dr Darren says "No they don't! Prefer code-like naming (or anonymous for typed elements) wherever possible. Use custom tagged values for other names!"

Icon class
icon_class
far fa-sticky-note
icon_class_computed
far fa-sticky-note
Note kind
MODELLING
NAMING
TIP
Policy level
STRONG
Specification keywords
SysML-1.6
SysML-1.7
SysMLv2
UML keywords
NamedElement::name
Type
custom Stereotype
tagged value
Keywords
Dr Darren of Webel IT Australia hears you say:
"But really long human friendly element names with spaces make my Diagrams easier to read".
Dr Darren says:
"No they don't! Prefer code-like naming conventions and adopt anonymous for typed elements wherever possible. Use tagged values METADATA for carrying "human friendly" names to optionally display on symbols on Diagrams! Pull that "human-friendlier" METADATA out in table view queries!"
By using long so-called human-friendly names in Blocks and Package names (in particular) you are completely undermining a heap of really powerful modelling strategies that leverage short names (no spaces) to provide semantic context and ownership context efficiently. Anyone who tries to convince you otherwise is proving one thing to me:
They haven't yet discovered some of the most powerful SysML/MBSE modelling strategies used in the Webel modelling recipe for SysML!

Such as this:

Webel: SysML: Use concise Package and Model naming to provide "context aware" owner paths that reflect a systems engineering strategy. Extremely so-called "human friendly" verbose Package/Model names with spaces DO NOT make the model easier to understand!

Do the advocates of so-called "human friendly" extremely long SysML element names have a set of tried-and-tested well recording policies like the Webel Best Practices for SysML policy note pages in this site (cross linked to many examples)? No. Are their SysML diagrams as nice and compact and presentable and legible as the Webel ones? No. Can they model as quickly and as efficiently in SysML as I do with the Webel approach? No. Tried it out on heaps of real world SysML for MBSE projects for decades? Mostly, no. Do they make examples of their SysML modelling of truly substantial real world problems and domain realistic models available in public like the Webel IT Australia site? Mostly, no.

Do the advocates of such cluttering long verbose so-called "human friendly" naming have an actual recipe for traceable elicitation of SysML model elements such as the  Webel Parsing Analysis recipe for SysML®? Very likely no.

Really long element names with spaces also run the risk of becoming too WET not DRY

As for the argument that such verbose naming is required for alignment with older pre-MBSE systems engineering methodologies:

Webel: Dr Darren says: "Many aspects of older Document-Intensive Systems Engineering methodologies and the reporting obligations they impose on their users were intended to address problems that simply DO NOT EXIST ANYMORE with modern MBSE with SysML!"

You can progressively introduce Webel-style concise naming!

In any case, the naming conventions of the Webel Best Practices for SysML can be adopted incrementally, and thanks to the wonders of Single Source Of Truth modelling with SysML (with propagation of changes throughout all Diagrams), they can be introduced selectively if and as and when you wish with incremental benefit:

On the Webel Best Practice modelling tips for SysML (and UML). If you want to model the Webel way, use them, if you don't, ignore them. They are ONLY offered as options and graphical modelling paradigms and idioms for you to consider.

Please be aware also that the SysML spec figures and sample problems are NOT intended to act as "templates" for modelling in SysML! And the authors have special pedagogical reasons for including some quite verbose naming and adornments in those figures:

The Webel modelling style, naming conventions, and Best Practices for SysML are more consistent than most SysML spec diagrams. When following Webel courses please DO NOT use the spec sample diagrams (which serve a different purpose) as visual references!
The Webel Best Practice items for SysML (and for supporting UML) - tuned for the MagicDraw/Cameo tools - represent the world's most comprehensive guide to robust, fluent, enjoyable, consistent modelling for Model-Based Systems Engineering (MBSE), developed over two decades, and proven to work on extremely demanding real-world projects! Learn more by attending the Webel IT Australia course for MBSE with SysML.
Visit also:
Webel Best Practice: 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')!
Webel Best Practice: 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.
Webel Parsing Analysis for SysML: Track and display alternative names, human friendly names, organisation-specific names, and identifiers using tagged values for a custom stereotype «pa:term» (adapt or extend as required).
Webel: SysML: Use concise Package and Model naming to provide "context aware" owner paths that reflect a systems engineering strategy. Extremely so-called "human friendly" verbose Package/Model names with spaces DO NOT make the model easier to understand!
Relates to
[STUB] TRAIL: Webel's ultimate guide to simplified yet adequate pragmatic systems engineering with functional analysis in SysMLv1 for smaller scale MBSE projects in the MagicDraw/Cameo/CATIA Magic tools
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!
[POLICY]{STRONG} About the Single Source of Truth (SSOT) and Don't Repeat Yourself (DRY) principles
[NAMING, POLICY] 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.
[CONVENTION, NAMING, STYLE]{STRONG} 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.
[DISPLAY, STYLE, TOOL]{RECOMMENDED} In Package Diagrams and Block Definition Diagrams use the owner indicator display option for Classifier symbol headers to indicate the owner (except where a containment operator suffices). The mode 'Below Element Name' is preferred.
[DISPLAY, STYLE]{OPTION} In SysML diagrams, showing the context name and type in the diagram frame can lead to clutter and is not always clear to non-SysML stakeholders (although that is the style used in the specification samples)
[EXPLANATION, MODELLING, TIP] On the Webel Best Practice modelling tips for SysML (and UML). If you want to model the Webel way, use them, if you don't, ignore them. They are ONLY offered as options and graphical modelling paradigms and idioms for you to consider.
[NAMING, POLICY]{STRONG} 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)
[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]{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).
[] Prefer owner path indicators over Package containment operators (which are fragile).
[DISPLAY, TIP]{STRONG} Prefer the Name Display Mode 'both' on CallBehaviorAction symbols (rather than 'Show Action Name', 'Show Behavior Name', or 'Show Both or Behavior Name')
[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]{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
[MODELLING, STYLE]{RECOMMENDED} SysMLv1: Prefer not show Port symbols on the boundary of Block symbols in BDDs, just list them in compartments. One can't connect them in a BDD anyway. Recommend only show Port symbols in IBDs.
[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!
[NAMING, POLICY, STYLE]{STRONG} The Webel modelling style, naming conventions, and Best Practices for SysML are more consistent than most SysML spec diagrams. When following Webel courses please DO NOT use the spec sample diagrams (which serve a different purpose) as visual references!
[NAMING, POLICY]{STRICT} 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.
Related notes (backlinks)
Related snippets (extracts)
Visit also
Visit also (backlinks)