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.
SysMLv1: TIP: You can strengthen the ill-defined semantics of Property 'aggregation' (an AggregationKind) by applying custom Stereotypes to a Property, documented with its intended use. Not perfect, but better than not. EXAMPLE: «assembled»
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: TIP: Consider using high level "communication" Associations between Blocks in BDDs and corresponding object diagram BDDs WITHOUT any Ports, with Links typed by the Associations. Object diagrams are great for exploring Slot values, too.
Webel: SysMLv1: TIP: Consider using high level "communication" Associations between Blocks in BDDs with ItemFlows and corresponding context IBDs WITHOUT any Ports, with Connectors typed by the Associations (as well, in parallel with your port-based IBDs).
Webel: SysML4Mathematica: SysML Activities and SysML Activity Diagrams CAN represent some functional programming paradigms (sort of). You can type Parameters by encapsulations of functions and pass them to/from InputPins/OutputPins of Actions.
Webel: WISHLIST: MagicDraw/Cameo: UML/SysML: Ability to freeze the Feature lines shown on symbols under Edit Compartments so that the diagram does not "break" when new Features are added elsewhere (reduce graphical coupling)
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: A stereotype with keyword «pa:from» may be applied to a Dependency from a Package to another Package within the Source Input Zone to indicate that all of its Elements were directly or indirectly elicited from source Documents.
Webel: SysMLv2: PROPOSAL: New Causality Graph Diagram for coordinating MetaEvents across an entire model
MagicDraw/Cameo: Modelica export: Need environment option to disable generation of layout annotations (not just on individual export dialog)
SysML-1.6/1.7: You can introduce a custom (user-defined) stereotype keyword «item» to indicate Properties that are to be used as "packets" for ItemFlows on Connectors. (SysMLv2 will have a formal way of treating such items/packets.)
Webel vs SysPhS-1.1: Annex A.5: Assume the conversion value property name 'SaturationVaporPressure::hPa2Pa' stands for 'hectopascal to pascal'.
Webel vs SysPhS-1.1: Annex A.5: Assume the conversion value property names 'WaterTank::litpSec2mLitpHr' and 'EvaporationCalculation2::litPSec2mLitPHour' stand for 'litres per second to millilitres per hour'
Sample problems and example diagrams in graphical language specifications are NOT necessarily indications of how one should model on a real-world project! They often just serve to demonstrate a particular aspect of the specified language.
SysPhS-1.1: Annex A.5: Humidifier: Naming not very consistent across parts, input/output Port name, value properties, or constraint parameters
UML/SysML: A Boolean "state flag" attribute corresponding to a State can be useful for indicating states in some diagram types (but must be synchronised with Transitions to States carefully).
Webel: SysMLv2: WISHLIST: Manage "cascading" Satisfy claim vs Block inheritance hierarchy with redefined properties
Webel: SysMLv2: WISHLIST: Suggest declare an custom Stereotype as 'cascading' then behave likes constraint rules for Block
Computed category membership test values are sometimes adequate and can prevent Class/Block explosion. However, a dedicated Class/Block encapsulating a clear domain concept offers a clear documentation point and can carry other characterising features.
WISHLIST: Webel has suggested that future SysML should support the display of Classifier-level :features in compartments on a rectangular itemProperty symbol on an ItemFlow on a Connector in an IBD.
Webel Parsing Analysis: You do not need to map every word of every snippet to the UML/SysML model! Extract only the information required for your domain modelling task to add incremental benefit.
Webel Parsing Analysis: You may create custom stereotypes applicable to a Dependency or a uni-directional Association to represent a «predicate» much like a semantic triple (subject-predicate-object) in OWL/RDF.
Webel Parsing Analysis: If the dashed-line "anchors" from your «snippet» ElementGroup symbols to elicited elements make a «pa» Parsing Analysis Diagram (PAD) too hard to read, try making them light grey using symbol properties.
You can use a ValueType to document how a value of a certain quantity kind should be measured (in a particular system, in a particular organisation, or according to an industry standard).
MagicDraw/Cameo: When you create an InstanceSpecification in a diagram it will a Select Classifier dialog. It is often faster to Cancel that and then just drag a Classifier onto the instance symbol from the diagram or model tree.
MagicDraw/Cameo: If you can't find Usage on a particular diagram just use a Dependency then the refactor context menu item.
SysML Blocks have lots of possible features and compartments, lots of capabilities, and are very powerful! But you don't have to use every aspect of a Block (or show every aspect in every diagram) at once on every project.
Webel has suggested that SysMLv2 should support verification of each individual claim of more than one Element helping to Satisfy a Requirement.
SysML: Webel recommends use of an additional custom «requirementGroup» stereotype for compound Requirements that serve as owning Namespaces and are subject to the satisfaction policy that all child requirements must be satisfied.
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)
Style: use line width 2 or 3 on the border of the "focus" element in "focus" diagrams (such as the main Block or Class of a dedicated Block Definition Diagram or Class Diagram)
