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:
beadLock:BeadLock
rim:Rim
tire:Tire
pressure:Pressure
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:
rfw:FrontWheel
lfw: FrontWheel
rbw:BackWheel
lbw:BackWheel
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:
:DynamicPressure
:StaticPressure
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.
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).
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.
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.
