SysML: Syntax ain't Semantics: FUN CHALLENGE: SysMLv1 block property aggregation: 'The tornado chaser plane "has" a chaser car "with" a chaser team.'
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!
Mathematica: MTools: Argument Pattern strong type matching does not intrinsically respect inheritance (makes implementing design-by-contract and some Design Patterns less convenient). But you can use PatternTests with Webel MAll extensions.
Webel: The single biggest disease in the world of IT is the idea that somehow mathematics is bad, or not useful, or not efficient, and that getting people who don't like maths to make stuff up (badly) in coding languages (rather than using maths) is ok.
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).
SysML: Having a Behavior owned by a Block it is allocated to may undermine purist functional allocation (because it presupposes the element of the physical solution that carries out the function)
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!
The use of an additional «port» keyword on a Port is usually redundant and causes clutter. The use of an additional «port» keyword on a basic Property is an obsolete trick. Please don't imitate it even if you see it in some specification sample diagrams!
There is no «port» stereotype keyword for Port or Property in UML-2.5.1 or SysML-1.6. It is assumed to be introduced in some SysML and SysPhS specification diagrams as a custom or user-defined stereotype for special illustration purposes.
SysPhS-1.1: In the specification model for Figure 59 the handling of the initial values for some value properties (such as for 'gravity') in Tank usages within context block ConnectedTanks is WET not DRY (breaks Single Source of Truth).
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: 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.
