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.
Mathematica: Webel OpenXML: The XL$Cell value accessor XL$Cell⊙valReal has no units-awareness; prefer the US$Cell value accessor US$Cell⊙val, which can return a Quantity.
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: Mathematica: Packages that import the Webel HelpF` package (but not MTools and the Webel HelpM` package) should use the 'usageF' function for ::usage String generation (rather than the 'docF' and 'docV' functions) and an AOR Map.
Dr Darren says: 'You can't obtain the optimum benefit of graphical engineering with SysML without becoming mindful of the cognitive and artistic aspects of graphical modelling. The "Zen of SysML" matters!' Just like an elegant electronics device design.
SysML tools can ALSO be used for many graphical Model-Based Engineering tasks that benefit from Single Source Of Truth - and even without any formal System Engineering methodology (which is NOT to say that formal System Engineering is not also useful).
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!"
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: SysML: Heard of "follow the money"? In MBSE we "follow the flows"! Identify requests, data packets, messages, signals early on and use ItemFlow as often as you can wherever you can! Adopt a signal processing mindset throughout (systems thinking).
Webel: SysML/MBSE: Dr Darren's Open Letter on why you may initially need the Model-Based (MB) and Single Source Of Truth aspects of MBSE more than the formal Systems Engineering (SE) aspect (or even initially no formal SE process at all) to benefit most!
Mathematica: Webel ADT pseudo classes: TIP: Prefer the Decorator Pattern over multiple inheritance of ADT-Method UpValues! (But not because "inheritance is evil" per se, it isn't.) The base ADT libraries make heavy (and very useful) use in inheritance.
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: 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: SysML Parametric Diagrams are not well suited to modelling calculations with Blocks for MTools classes, or for modelling complex logic flow of Mathematica functions. Prefer SysML Activity Diagrams for those modelling cases.
Webel: SysML: MagicDraw/Cameo: Strongly recommend that you set the Perspective to 'Full Featured' and 'Expert' at the very beginning at the start of every new project
TIP: Mathematica: Use of For is often a hint that Map, Table, Scan, or something else more functional could be used. But don't stress over it!
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 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 tool support 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.
Webel: UML/SysML: Navigation: ALWAYS 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"! [But beware of shared package cross-dependencies]
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.
Webel: SysMLv1: 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 [Helps prevent a clash/issue]
Webel: MagicDraw/Cameo: STRONGLY RECOMMEND: On EVERY project of ANY kind set the Environment Perspective to 'Full Featured' and check the Expert box, even if you are a "novice". For SysML use 'Full-Featured' not just 'System Engineer'!
Cameo/MagicDraw: The Classifier specification setting 'isAbstract' is (for reasons that beggar belief or engineering reason) not by default visible in the Element specification dialog. Enable expertise level 'All' (and for always everwhere).
Webel: MagicDraw/Cameo: Set EVERY element properties & symbol properties filter to 'All' (yes, not just 'Expert', to 'All', even if you are a "novice" on your first project) in EVERY dialog and every project option setting. Use the search filters!
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.
Webel: SysML: 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' (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.
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
Webel: SysMLv1/UML: 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' (or 'oi') for inout. "Trust the Type". For conjugation ~InterfaceBlock use 'o' for in, 'i' for out, and 'io' (or 'oi') for inout.
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!
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
SysML: MagicDraw/Cameo: DO NOT use the FlowPort or FlowSpecification menu items or smart manipulator items they are completely OBSOLETE (they create fully DEPRECATED SysML model element types)! Use FlowProperty on Block features instead.
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: SysMLv1: Highly recommend creating a "focus" Block Definition Diagram (BDD) for each main Block with expanded feature details and relationships to at least nearest neighbours
Webel: SysML symbol colour styles: Recommend use black symbol borders and no symbol fill (or white symbol fill) EXCEPT for special highlighting. Recommend DO NOT use the default VENDOR-SPECIFIC line and fill colours for symbols! [TIP IS MOSTLY IGNORED]
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.
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)
