Webel Parsing Analysis: Formally, if «pa:implied» has been applied to indicate an implied elicited Element, the 'snippet' tagged value should bet set using at least one Snippet that implies it. (Note, the Snippet should have identical 'name' and 'body'.)
Webel Parsing Analysis: A "focus" Parsing Analysis Diagram (PAD) for one or more Snippets SHOULD always show the /member tagged value of every Snippet.
Using Model-Based Systems Engineering with ANY version of Systems Modeling Language (SysML) is better than just doing drawings in a graphics tool or presentation tool
You DO NOT have to wait for SysMLv2 to do excellent Model-Based Systems Engineering with SysML! You can do MOST of what you need to do with SysMLv1.6/1.7 and you WILL be able to migrate models to SysMLv2 (once it matures). Start your SysML models NOW!
SysML: The placement of usages of Blocks, their Ports, and Connectors in an Internal Block Diagrams DOES NOT necessarily represent physical geometry!
In a control loop, the 'got' (sensed) value is not in necessarily exactly the same as the actual, physical value being controlled! Typically it will be limited to a certain performance accuracy (and an intrinsic accuracy limit due to the number of bits).
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!
Webel vs SysPhS-1.1: Annex A.5: Humidifier: It is assumed that "vapor" is a volume rate corresponding to the rate of consumption OF HEATED LIQUID WATER (from a tank) used to create the vapor.
UML/SysML: Navigation: Try to offer a way out of a diagram (usually up a hierarchy, but possibly across) using a navigable symbol (linked to a diagram) and/or a diagram symbol. Avoid "cul-de-sacs"!
SysPhS-1.1: Annex A.5: Humidifier: Use of UML-style direct Port conjugation not permitted since SysML-1.6, prefer ~InterfaceBlock type-based conjugation (example requires migration)
Webel vs SysPhS-1.1: Diagramming style: DO NOT recommend overlapping Connectors with "phantom" fork (or junction) as shown in in 'Figure 48: Internal structure of the signal processor'
GOTCHA: A SysML/SysPhS Connector (or Modelica connection) in an electronics model is NOT a wire! It's a contract between connected Ports.
Webel vs SysPhS-1.1: Diagramming style: DO NOT recommend overlapping Connectors as shown in 'Figure 38: Internal structure of the circuit example'
Webel Best Practice: SysML/SysPhS: DO NOT use overlapping Connector lines from/to one Port (can be misunderstood as "summed" flow and/or physical node/fork/junction).
Webel Twin Pattern: The information and data in AssetSpecification leveraged for creation of a new ActualPhysicalAsset need not necessarily only be «digital».
Webel Twin Pattern: An AssetSpecification may contain ANY information or data of ANY kind in ANY format about how to acquire, manifest, build, or create a physical asset. This information may be distributed across an @Entity and a PotentialPhysicalAsset.
Webel: SysML: Electronics: DO NOT represent a jack/socket as a dumb proxy. Imagine it can introduce some signal noise or other effect (such as buzz) to test it is a physical model.
Webel Parsing Analysis: SysMLv1.x: Q: "Instead of using a Snippet extension of an ElementGroup, can't I just use a Requirement and Trace to achieve the same thing?" A: No! The ElementGroup extended as the Snippet is far more powerful and fit for purpose.
MagicDraw/Cameo: AVOID the "default" SysML Item Flow Creation Mode 'Between Part Types' completely. Use 'Direct' mode, change it as soon as you start any SysML project under Options → Project → General → SysML.
MagicDraw/Cameo: On EVERY project of ANY kind set the Environment Perspective to Full-Featured and check the Expert box, even if you are a "novice".
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.
Always consider including an abstract (sometimes intermediate) base Block in your domain modelling Generalization hierarchy.
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.
When domain modelling with SysML, Generalization, inheritance, and even multiple inheritance are not "evil" and can be used relatively freely. We are not doing code-oriented Decorator patterns - an implementation choice - we are doing domain modelling!
A common interpretation of composite Aggregation of a part property in SysML domain modelling is that if the owner Block is "destroyed" so is the child part property. Webel adopts these semantics always.
If an abstract Block or Class in a domain model has Associations to Blocks or Classes that are not also abstract, it's often a hint that you have not identified a correct abstraction layer.
In SysML, unless you MUST use a DataType or PrimitiveType from an existing ModelLibrary or Profile, you SHOULD probably be using a ValueType, Enumeration ValueType, or SysML PrimitiveValueType instead so that it integrates with the value system of SysML.
Webel Parsing Analysis: typically the quoted extract text (body) of a «snippet» is a short phrase, a sentence, or a couple of short sentences (but not dozens of sentences).
By all means use ActivityAllocatePartition swimlanes for CallBehaviorAction allocation in usage allocation mode, but use BDDs for your definition-level allocations with directly drawn «allocate» relationships between Activity and Block symbols.
Dr Darren of Webel has always opposed the exclusion of the obviously useful UML Artifact from SysML (but in MagicDraw and Cameo you can sneak it in anyway). After all, systems engineers do use documents quite a bit.
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.
Avoid mixing flow properties on the Type of a Port with directed features (operations and values); One distinguishes between "ports with flows" and "contract ports".
In general, the SysML DirectedFeature approach is more powerful and the notation is cleaner than UML provided/required Interfaces. Prefer SysML DirectedFeatures unless you have a really good reason to use Interfaces!
Webel: SysMLv1.x: AVOID (where possible) ValueType names that are the same as the name of units or unit symbols
Prefer the Name Display Mode 'both' on CallBehaviorAction symbols (rather than 'Show Action Name', 'Show Behavior Name', or 'Show Both or Behavior Name')
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)
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.
"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!
In the Webel recipe for SysML, DO use a "standard" Port until you have a truly compelling reason to commit to a FullPort or ProxyPort
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!
Consider creating a "focus" Block Definition Diagram (or Class Diagram) for each main Block (or Class) with expanded feature details and relationships to at least nearest neighbours
Colours: Strongly recommend (insist) use black symbol borders and no symbol fill (or white symbol fill) EXCEPT for special highlighting. DO NOT use the default VENDOR-SPECIFIC line and fill colours for symbols!
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)
