Webel: Mathematica: CONVENTION: A 'type$' indicator for an '$opt$' or '$arg$' is for documentation only. It may use a "pattern helper", a human-friendly String, or a SysML-similar short-hand type representation. It need not correspond to a valid Pattern.
Webel: SysML4Mathematica: A custom stereotype «M:Paclet» applied to a SysML Package denotes a Wolfram Package Paclet. An «M:Package» is a specialisation of SysMLv1 Block and denotes a Wolfram Language Package.
Webel: SysML4Mathematica: A SysML/UML Usage (keyword «uses») is used to indicate a Wolfram Package Needs import, where an «M:Package» is a specialisation of Block (not a SysML/UML Package) and denotes a Wolfram Language Package.
Webel: SysML4Mathematica: Activity Diagrams used purely for analysis and as development aids are not required to show every ControlFlow, may omit InitialNode and ActivityFinalNode, and are not required to fully validate in SysML tools or execute.
Webel: Mathematica: CONVENTION: A '$Q$' in a function variant name indicates that it is a variant where every argument is strictly either a Quantity or dimensionless Real. Compare with '$SI$' functions.
Webel: Mathematica: CONVENTION: An '$E$' or '$EQ$' in a function name indicates that it is symbolic (takes Blank expression arguments), but the absence of '$E$' or '$EQ$' does not necessarily imply that it does not take Blank arguments.
Webel: SysML4Mathematica: An OptionsPattern[] may be represented by an «M:OptionsPattern» SysMLv1 Block with «M:Opt» properties. An «M:Opt» property represents an Options[] Rule IMPLICITLY (an «M:Opt» does not use the Rule block modelling recipe).
Mathematica: Webel ADT pseudo classes: The SysMLv1 models are supported by custom stereotypes with icons. Some of these indicate OO-similar use of ADT-Methods and departures from formal Abstract Data Type (ADT) definitions.
Webel: Mathematica: CONVENTION: MTools classes: A 'z' prefix indicates a "private" method; A 'my' prefix indicates a "protected" method (typically a protected hook). There is no actual visibility enforcement other than by name convention.
Webel: SysML4Mathematica: An '@*~' prefix in a @pseudo function (OpaqueBehavior or Activity) represents a cast from any expression to a Type. Example: '@*~OpenerView' casts from any expression to an OpenerView. '@Type~' casts from a specific Type.
Webel: Mathematica: CONVENTION: An '$SI$' in a function variant name indicates that all arguments are SI Real convention (no Quantity arguments with units). An '$SI$' function can also be used to generate '$C$' compiled function variants.
Mathematica: CONVENTION: A prefix 'eq$' indicates a symbolic equation (typically using 'sym$' human-friendly markup "symbols")
Webel: Mathematica: CONVENTION: A '$C$' in a function name indicates that it is a compiled variant. Typically it is compiled from an '$E$' symbolic function or an '$SI$' Real convention function.
Webel: Mathematica: CONVENTION: An '$E$' in a function name indicates that it is symbolic (takes Blank expression arguments). An '$E$' function can also be used with Quantity inputs and can be used to generate '$C$' compiled function variants.
Webel: Mathematica: CONVENTION: A '$EQ$' in a function name indicates that it is a symbolic equation (with LHS == RHS). An '$EQ$ function can be used in combination with 'sym$' markup to create human-friendly formatted equations.
Webel: Mathematica: CONVENTION: Entity "field definers" are prefixed with '$e$[pac]' (where '[pac]' is a nickname for a package or logical grouping) and carry String field names. EntityStore functions are prefixed with 'e$[pac]'.
Webel: Mathematica: CONVENTION: A '$sig$f$' prefix indicates a String signature helper for a function (or for a "method" of an MTools class or a Webel Abstract Data Type (ADT) pseudo class).
Webel: Mathematica: CONVENTION: A '$doc$' prefix indicates a formatted documentation String helper. A '$doc$arg$' is for an argument, a '$doc$opt$' is for an option. A '$doc$ String may be used to create ::usage documentation via docF.
Webel: Mathematica: CONVENTION: A ‘$pac$’ String helper variable is used to capture the fully qualified String name of every package. Useful for quick '$pac' argument provision for search functions and for DEVEL package load echoes.
Webel: Mathematica: CONVENTION: A 'z$' prefix may be used to indicate a Private` function or expression within a package or a "private" method of an MTools class or Webel Abstract Data Type (ADT) stateless pseudo class.
Webel: Mathematica: CONVENTION: The Stereotype keyword «functional» indicates a "pseudo functional" representation of functional in SysML. There are limits to representation of functional programming in SysML, but it can be informative and is worth doing.
Webel: Mathematica: CONVENTION: A '$t$' prefix indicates a String help holder with a "pseudo type" indicator (for human friendly documentation only). Used by the Doc`, HelpF`, and HelpO` packages.
Webel: Mathematica: CONVENTION: A function's description (but not its signature, arguments, or options) may be captured as an '$info$f$' Stringhelp holder for use by the Doc` package for ::usage generation and the HelpF`& HelpO` help registry packages.
Webel: Mathematica: A help Rule 'rule$opt$' for an '$opt$' (option) accepts keys: '$k$help' (required), '$k$def' (required), and optional '$k$warn', '$k$tip', '$k$lab' (a label), '$k$type' (indicator only), '$k$mult' (SysML multiplicity), and '$k$pat'.
Webel: Mathematica: A help Rule 'rule$arg' for an '$arg$' (argument) accepts keys: '$k$help' (required), '$k$def' (required if $k$req = True not given), '$k$req' (True if $k$def not given), '$k$warn', '$k$tip', '$k$lab', '$k$type', '$k$mult' and '$k$pat'
Webel: Mathematica: CONVENTION: An '$opt$' (option) or '$arg$ (argument) help holder may be have an associated (typically short) '$lab$opt$' or '$lab$arg$' label help holder for use in GUIs and views.
Webel: Mathematica: CONVENTION: Where keys of Associations are Strings they are encapsulated as variables prefixed with '$k$' (promotes DRY and has many advantages, such as IDE prompting). Direct use of "Strings" as keys is WET and strongly discouraged!
Webel: Mathematica: CONVENTION: "pattern helpers" (which are not themselves Patterns) use the prefix '$pat$. Encapsulated Patterns use a 'pat$' prefix, and may use a '$pat$' pattern helper (such as an Alternatives).
Webel: Mathematica: CONVENTION: Argument help holders use a String variable with the prefix '$arg$', a related '$info$arg$' String, a 'def$arg$' default value expression and/or 'req$arg$', and optional '$warn$arg$', '$tip$arg$, '$lab$arg$', 'type$arg$'..
Webel: SysML: SE: A functional analysis «whitebox» Activity may have swimlanes that Allocate to logical subsystems (logical handlers) within the 'problem' zone or to design/implementation level blocks.
Webel: SysML: SE: The custom Stereotype keyword «whitebox» applied to an Activity indicates that it is part of the functional analysis breakdown serving a «whitebox» «scenario» Activity (directly or indirectly) for a UseCase.
Webel: SysML: SE: «blackbox»: The custom Stereotype keyword «scenario» indicates a Behavior (Interaction as Sequence Diagram or Activity) that Refines a top-level UseCase within the 'problem' zone.
The Webel recipe for pragramatic SE with SysML omits many of the concerns addressed by fully-fledged systems engineering frameworks. Many of these can be partially addressed by using custom Stereotypes for extraction using query view tables.
Webel: SysML: SE: The custom stereotype keyword «design» covers elements involved with BOTH design and/or implementation aspects in the 'solution' zone. (In more comprehensive SE methodologies design and implementation are often treated separately.)
Webel: SysML: SE: Stereotype keyword convention: BY DEFINITION HERE «blackbox» and «whitebox» refer specifically to the 'problem' zone and NEVER the 'solution' zone (as opposed to more general uses of the terms 'black-box' and 'white-box').
Webel: SysML: SE: Naming convention: «whitebox»: A '$' prefix indicates a «logical» system, «logical» subsystem (aka conceptual subsystem) or «logical» handler Block (which is a more specific form of «logical» subsystems Block).
Webel: SysML: SE: Naming convention: '0' used for a Package/Model name indicates a zone dedicated to a formal systems engineering breakdown (functional analysis, blackbox, whitebox, logical vs design or implementation etc.)
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!
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!"
Webel: SysMLv1: Functional analysis (isolation of white-box Activities identified via «blackbox» scenario Activities of UseCases). Recommend custom stereotype them. Candidate: «whitebox» (or a recommended SE methodology stereotype).
Webel: SysMLv1: Overview of annotated Diagram Slides and Note pages related to general high level SysML modelling principles (some specific to MagicDraw/Cameo). Recommended reading for all Webel SysML/MBSE course attendees.
SysMLv1: An ItemFlow without an assigned 'itemProperty' is sometimes informally/casually referred to as an "information flow", especially when applied to an Association (because it is much like a UML InformationFlow), but formally it is a SysML ItemFlow.
Webel: SysML/UML: Dr Darren explains HOWTO use concise 'i'/'o' (input/output) Pin and Parameter naming conventions to promote a signal processing mindset in Activity Diagrams. And HOWTO get them compact.
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!
Mathematica: Webel ADT pseudo classes: POLICY: The ADT-Methods of an ADT-Class are created as TagSetDelayed UpValues using the 'signature' of the ADT-Class and its defining 'pattern' as 1st argument
Mathematica: Webel ADT pseudo classes: CONVENTION: PROVISIONAL: The infix operator for calling ADT-Methods on ADT "objects" is the CircleDot (⊙ in Notebooks). ISSUE: \[CircleDot] is NOT GOOD FOR USE IN IDEs!
Mathematica: Webel ADT pseudo classes: POLICY/DEFINITION: Every "hard coded" definer or defining client of a definer has a corresponding ADT ArchetypeClass. Example ("hard coded"): The definer 'my$def$MY$SmartList' has ArchetypeClass 'MY$SmartList'.
Mathematica: Webel ADT pseudo classes: NAMING CONVENTION: An UpValue that can be invoked on an ADT accepting its unique 'signature' pattern as (at least) 1st argument is called an 'ADT-Method'. They are NOT methods in the general object-oriented sense!
Mathematica: Webel ADT pseudo classes: DEFINITION/CONVENTION: Functions that populate ADTs with reusable ADT-method UpValues are called 'definers' and include '$def' in the name after a Package scope indicator: Example: adt$def$ADT, my$def$MY$CleverList
Webel: Psy/MPsy: Psychrometrics for Mathematica: '$HC' in a function name indicates pure sensible heating or cooling (with no change in water vapour content). Such functions may also be used in the pure sensible portion of a 2-step treatment.
Webel: Mathematica: CONVENTION: A prefix '$doc' indicates a documentation String for each primary variable/quantity (argument or output)
Webel: Mathematica: CONVENTION: A prefix 'sym$' indicates a markup variable "symbol" for a documented variable. It need not be a String, but each referenced part MUST be a String - not a Mathematica Symbol - to avoid namespace clashes!
Webel: Psy/MPsy: Psychrometrics for Mathematica: A suffix '$wat$i' indicates water (liquid or vapour) flow TO (into) the humid air mixture. A suffix '$wat$o' indicates water (liquid or vapour) flow FROM (out of) the humid air mixture.
Webel: Psy/MPsy: Psychrometrics for Mathematica: A suffix '$sat' indicates a humid air mixture quantity at saturation (relative humidity = 1 or degree of saturation = 1).
Webel: Psy/MPsy: Psychrometrics for Mathematica: A suffix '$ha' indicates a HUMID air mixture variable, quantity, or function or a PER humid air mass quantity.
Webel: Psy/MPsy: Psychrometrics for Mathematica: A suffix '$a' indicates a DRY air component variable, quantity, or function. A suffix '$da' indicates a HUMID air mixture quantity PER dry air.
Webel: Psy/MPsy: Psychrometrics for Mathematica: A suffix '$wat' indicates a water-related variable, quantity, or function (note that 'w' is reserved for the humidity ratio).
Webel: Psy/MPsy: Psychrometrics for Mathematica: Variable/quantity registry and naming conventions, with symbol markup.
Webel: Psy/MPsy: Psychrometrics for Mathematica: The term 'steam' (indicated in variable names with a suffix '$s') is reserved for water vapour created through boiling.
Webel: Psy/MPsy: Psychrometrics for Mathematica: A suffix '$g' in a water-related variable name refers to water vapour (a special case of gas) or steam. A suffix '$f' refers to liquid (fluid) water. [Although a gas is a fluid.]
Webel: SysML4Mathematica: Does every bit of the Mathematica code need to be modelled in SysML? No. Typically just the main function parameters and their interdependencies, data structures, and main code logic. Except for special or educational purposes.
Webel: SysML4Mathematica: Convention: A Mathematica Blank '_' (which pattern-matches any Expression) is represented by a custom SysML ValueType '_'
Webel: Psy/MPsy: Psychrometrics for Mathematica: Convention: Option variable names are prefixed with '$opt$psy'
Webel: Mathematica: CONVENTION: Option help holders use a String variable with the prefix '$opt$', a related '$info$opt$' String, a 'def$opt$' default value expression, and optional '$warn$opt$', '$tip$opt$', '$lab$opt$', and 'type$opt$' indicator ...
Webel: SysML4Mathematica: An Association used as the Type of an argument or return is represented by a Block '<||>'. A List used as as the Type of an argument or return is represented by a Block '{}'. (Extending types may adapt the notation.)
ISSUE/GOTCHA: MagicDraw/Cameo v2022x: UML/SysML: If you "rename" an ActivityParameterNode symbol on the frame of an Activity Diagram it actually renames the underlying Parameter (only) NOT the name of the ActivityParameterNode element!
SysML/UML: MagicDraw/Cameo: The name of an ActivityParameterNode does not always stay in synch with its Parameter (and it is not always desirable that it does).
SysML/UML: MagicDraw/Cameo: GOTCHA: Connecting a typed OutputPin to an untyped (UNSPECIFIED) InputPin with an ObjectFlow changes the type of the InputPin
Webel: SysML4Mathematica: Convention: A '$E' in a function name indicates that all parameters (arguments and return) are Mathematica '_' expressions. However, when representing such functions as Activities they may end up getting strongly typed in tools!
Webel: SysML4Mathematica: When modelling the main logic flow of Mathematica code with Activity Diagrams it isn't necessary to model every Mathematica construct. Placeholder Actions, OpaqueActions , and OpaqueBehaviors (as CallBehaviorActions) may be used.
Webel: SysML4Mathematica: An '@' prefix in the name of a Block indicates a data structure (such as an Association or List) that does not have a corresponding MTools class or a Webel Abstract Data Type (ADT) "pseudo class" in the Wolfram Language code.
Webel: SysML4Mathematica: An '@' prefix in the name of a ConstraintBlock, Activity, or OpaqueBehavior indicates that it is a "@pseudo" function not represented directly in the Wolfram Language or Webel code libraries (typically for minor maths or logic)
SysML Parametrics: You can use custom stereotypes keywords «i» and «o» on constraint parameters to indicate their intended use (causality) as (i)nputs and (o)utputs on ConstraintBlocks
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: The Webel Units` package has Quantity variables for frequently used units using a naming convention 'unit$[Symbol]' or 'unit[DescriptiveName]' or unit[Acronym], each with a corresponding '$unit...' for the units identifier String(s).
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"?
[HISTORICAL] 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 ARCHIVAL (2022): This content is now considered historical only!
SysML Parametrics: You can use custom stereotypes keywords «i» and «o» to indicate value properties that are intended to be used as (i)nputs and (o)utputs when bound to constraint parameters for SysML Parametrics
Optionally suffix the "focus" BDD for a Block with '.bdd' so that it won't clash with a corresponding IBD on diagram export. This is not a SysMLv1 concern, it is purely a workflow concern. It has the slight disadvantage that BDD may "indicated" twice.
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.
SysML: Non-anonymous (concise please) block property names and port names may help a little in tracing participation of properties and ports in requirements relationships and play nicely with current SysML callout style. Short role indicators are best!
Webel: If you must name your Ports or Pins, name them simply 'i', 'o', or 'io' (or 'oi') to indicate direction UNLESS you have to indicate a special role like 'iRole', 'oAuxiliary'. DO NOT use Port or Pin 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' (or 'oi') for inout. "Trust the Type". For conjugation ~InterfaceBlock use 'o' for in, 'i' for out, and 'io' (or '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)
SysML: Webel: "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 within the same owner context!
"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 spec diagrams. When following Webel courses please DO NOT use the spec sample diagrams (which serve a different purpose) 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]. The trailing part (after the underscore '_') may indicate the type that flows.
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 code-like '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)
