Webel: SysMLv1: Dr Darren for LinkedIn: On "Trusting The Type" and avoiding unnecessary verbose repetitive Property names ... unless you really, really need them and really do have reasons to use them, and then only use concise role indicators anyway!

Icon class
far fa-sticky-note
far fa-sticky-note
Note kind
Policy level
Specification keywords
UML keywords
SysMLv1.x keywords
If you are a true SysML expert and you know exactly why you are using verbose, repetitive, Property names that read exactly like Type names (such as for annoying very old fashioned pre-MBSE formal report generation requirements), by all means just ignore the following (although it's still a very, very good TIP).

Otherwise, and especially if you are completely new to SysML modelling, Dr Darren of Webel IT Australia says:

This page is adapted from some of my comments on LinkedIn MBSE and SysML Group discussions, and elaborates on the above Webel Best Practice for SysML. If anyone tells you this TIP is nonsense, have a look through the SysML models and diagrams on the Webel site, be encouraged by their robust effectiveness, then try this TIP out yourself. You'll find that mostly - unless you actually really do have very special reasons to use them (some of which are listed below) - verbose Property names that just "mimic" the Type do absolutely nothing for your model, your modelling, your diagrams, your time, your enjoyment, or your sanity.

Maintaining verbose, repetitive Property names has been a turn off for some modellers (their instinct that it feels like needless repetition is mostly right). You can often just "Trust the type" and use anonymous Properties (yep, no name at all). The following Property names add little if there is only one of each kind in the owner context:


Such names add clutter and they break if you change the Type name. Better, anonymous, no name at all, let the Type do all the talking:

beadLock:BeadLock -> :BeadLock 
rim:Rim -> :Rim
tire:Tire -> :Tire
pressure:Pressure -> :Pressure

The owner context tells you everything you need to know about those properties, as long as there is only one of each Type!

A case for indeed using (short) names is when there are specific roles:

lfw: FrontWheel

Each name indicates a unique role. Another example:

pDynamic: Pressure
pStatic: Pressure

And that can be handled better with more specific ValueTypes, where each specific ValueType could carry documentation about how that specific Quantity is measured and its meaning:


Per-Property documentation (if needed at all) is then about the particular role only!

Another case for using indeed using Property names is when you really need them for report generation (ICDs), but even then, the Type and owner context are often enough.

Often showing the Element ID in query view reports is handy!

Are you suffering under pre-MBSE Document Intensive System Engineering with organisation-imposed requirements to generate massively verbose and largely repetitive reports? Dr Darren says:

Some older formal Systems Engineering methodologies and process were designed to address challenges that simply do not exist under modern MBSE with Single Source of Truth (SSOT)!

When modelling software code in SysML (which I do a lot), names for Typed variables are often necessary, but even then, concise role indicators are often best (rather than repeating the WholeTypeName as wholeTypeName everywhere).

Some of the examples you see in, say, the SysMLv1 spec and many educational slides have quite verbose naming for pedagogical reasons; those modelling practices shown aren't always intended to be used on real world projects for rapid robust modelling.

The MagicDraw/Cameo tool often generates Property names automatically (such as lowerCase from PascalCase); I mostly delete them immediately, or at least given them a concise role indicator. Nearly every single time.

You might ask what about when you are referencing a Property elsewhere, say using AdjunctProperty? It actually usually does not matter whether it has a name at all! As long as the assignment is made OK in the model, that's what counts.

Callouts? Where possible, just show the Type.

MagicDraw/Cameo have a few limitations concerning display of Types where my "Trust the type" motto is not entirely optimal for display in a few places, e.g. if you show the ownedParameters in the Element Compartments on an Activity symbol in a BDD it does not show the Type (AFAIK, I could be wrong, but I know most of the display settings pretty well).
"Aha! ... "
... I hear you say, thinking you've found the great flaw in my "anonymous Properties" strategy ...
" What about when you need to search for the anonymous Property to select it to assign it to a specification dialog field, eh, what then, Dr Darren, what then?"

Use Select In Containment Tree then Drag n' Drop, it's faster. If you aren't "near" the target property in your Diagram or model browser, search for the owner's Type! The Webel way works.

Relates to
Related notes
Related notes (backlinks)
Related snippets (extracts)
Visit also
Visit also (backlinks)