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: SysMLv1: Recommend using Block Definition Diagrams as associative, graphical engineering "scratchpads" FOR YOU; Use Internal Block Diagrams as the main presentation diagrams for your engineering colleagues and other stakeholders!
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).
SysMLv1: MagicDraw/Cameo: Having a SystemContext as the 'subject' of each main UseCase plays nicely with the feature for automated creation of usage-level allocation swimlanes in SysML Activity Diagrams for part properties. But it's not the only way.
SysMLv1: UseCase scenario representations: On use of Activity Diagrams with swimlanes and/or Sequence Diagrams (Interactions): Actor or block-based custom «actor» on 1st (typically left) Lifeline/Swimlane, System/Subsystem on 2nd Lifeline/Swimlane
Webel: MBSE: SysMLv1: Prefer a custom «actor» extension of a Block (such as the non-normative External) over UML-style Actor for use as parts in IBDs and on allocation swimlanes. You can also have a Trace from a block-based «actor» to a UML-style Actor.
Webel: SysML for MBSE: The frequent recommendation that each UseCase have at least one "primary" scenario is a very useful and highly recommended CONVENTION (only). But it is not actually enforced by the SysML1.7 or UML2.5.1 metamodels or specifications.
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.
Mathematica: Webel: A concise i:/o: notation is often used for indicating input/output cells in Mathematica notebooks in Webel's online help pages and tutorials, instead of 'In[n]:=' and 'Out[n]='. (Also learn how to hide them completely in notebooks.)
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: A tricky POLICY & CONVENTION: Client packages MUST access the special "wrapped" primary named ADT-parameter '$$' via $ContextAliases! The recommended alias is "A`" (which stands of course for ADT).
Mathematica: NAMING CONVENTION: Webel: ADT pseudo classes: 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
Mathematica: Webel: ADT pseudo classes: POLICY: Every named concrete Abstract Data Type (ADT) class has a ONE unique "signature" (which is the pattern passed to the "definer" functions). To vary a signature, define another unique ADT class name.
Mathematica: Webel: ADT pseudo classes: POLICY: The Abstract Data Types (ADTs) are stateless functional (although inheritance and overrides are supported), with no caching by default (although there is nice optional caching using CreateUUID[] and Once[]).
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: SysML4Mathematica: Convention: A prefix '$doc' indicates a documentation String for each primary variable/quantity (argument or output)
Webel: SysML4Mathematica: 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 raw 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: Convention: A custom SysML ValueType 'Quantity' extends a custom ValueType '_' (representing a Mathematica '_' Blank). It DOES NOT also extend the SysML Real!
Webel: SysML4Mathematica: Convention: A Mathematica Blank '_' (which pattern-matches any Expression) is represented by a custom SysML ValueType '_'
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 '{}'.
Webel: Psy/MPsy: Psychrometrics for Mathematica: The CoolProp "wrappers" of the Psy library in fact wrap lower-level wrappers (bindings) for CoolProp for Mathematica
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 logic flow of Mathematica code with Activity diagrams it is not necessary to model every single Mathematica construct. Placeholder OpaqueBehaviors (used via CallBehaviorActions) and OpaqueActions may be used.
Webel: SysML4Mathematica: An '@' prefix in the name of a Block indicates a Mathematica data structure (such as an Association or List) that is not represented by an MTools class in the Mathematica code
Webel: SysML4Mathematica: An '@' prefix in the name of a ConstraintBlock, Activity, or OpaqueBehavior indicates that it is not represented by a dedicated function in a Mathematica code library (typically for minor maths or logic)
Webel: Psy/MPsy: Psychrometrics for Mathematica: Most CoolProp wrappers can be invoked with the dry bulb temperature 'tdb', the pressure 'p', and one (only) of the relative humidity 'r', the humidity ratio 'w', or the wet bulb temperature 'twb'
Webel: Psy/MPsy: Psychrometrics for Mathematica: Due to Mathematica's units-aware Quantity algebra system it is irrelevant what units are used for the input Quantities for creation of the MPsy objects, as long as they are dimensionally consistent!
Webel: Psy/MPsy: Psychrometrics for Mathematica: Transferred heat (energy "Q") has field names with lower case 'qTot', 'qSen', 'qLat'. Heat rates (energy per time) have field names 'qDotTot', 'qDotSen', 'qDotLat' (to avoid clashes with Mathematica core)
Webel: Psy/MPsy: Psychrometrics for Mathematica: Relative humidity is indicated by a lower case 'r' and measured as a Real fraction (rather than as a Percentage). [Some tables and plots do SHOW the relative humidity as a Percentage.]
Webel: Psy/MPsy: Psychrometrics for Mathematica: For Imperial Units (IP), International British Thermal Units (Btu) are assumed
Webel: Psy/MPsy: Psychrometrics for Mathematica: Convention: 'Q' indicates the energy GAINED BY the system as heat energy transfer; 'W' indicates the work DONE BY the system on its external surroundings.
Webel: Psy/MPsy: Psychrometrics for Mathematica: Humidity ratio (absolute humidity) is indicated by a lower case 'w' and measured in mass (water) / mass (dry air) units, so the SI and IP representations are equal Real (without an explicit unit system)
Webel: SysML: TIP: CONVENTION (default policy suggestion): Use reverse time ordering for Dependency, reserve Usage, PackageImport, ElementImport for software dependencies
Mathematica: TIP: Protecting against computations breaking verbosely because of Null, None, Undefined. And about using Undefined as a return policy.
Webel: Mathematica: TIP: Maintain a Package library of Quantity variables for frequently used units using a naming convention unit$[unitSymbol] and unit[DescriptiveName] or unit[Acronym]
Webel Parsing Analysis: It does not matter whether you use a Package or a Model package. (The informal Webel convention is that Models are used for systems engineering analysis with SysML and Packages are reserved for code-related software engineering.)
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?
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").
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).
Block naming: If you find you've got similar blocks named 'Thing' and 'Thing2' then 'Thing' is probably better renamed 'Thing1'
Modelica: Naming convention: Why does the OnePort family of electrical components have 2 Pins? Where is the "one port"?
Webel Twin Pattern: Convention: [MIGHT CHANGE]: A '*' prefix in a Property name of a «digital» @Block in a DigitalTwin model indicates a mapped block property, which must be typed by a non-digital «mappable» Block, and must have the «@» keyword applied.
Webel: Convention: [MIGHT CHANGE]: An '@' prefix in a DigitalTwin model indicates a «digital» Block that maps a non-digital «mappable» Block.
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.
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.
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).
Webel use editorial Sterotypes prefixed with ! and ? in and in CAPS in keywords such as: «!». «?», «!ERROR», «!ISSUE», «!CAUTION», «!WARNING», «!CAVEAT», etc.
MagicDraw/Cameo: The default 'Implied Satisfy' relation will claim a Requirement is satisfied by any direct composite aggregation parent Block or composite aggregation ancestor Block of a part property
The name of a «testCase» Behavior may be verbose and may use natural language, but should always start with a Capital letter.
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 or Pin names like 'input', 'output', etc.
In most Webel examples, the default is chosen to be 'out' if there is a single FlowProperty, so a Port with the type applied will act as a source. If an InterfaceBlock is used, then a Port typed by the conjugating ~InterfaceBlock will act as a sink.
Webel: SysMLv1.x: AVOID (where possible) ValueType names that are the same as the name of units or unit symbols
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: 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!
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.
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