Webel: SysMLv1.x: TIP: The name and documentation of a ValueType can indicate and specify more than just the unit and quantity kind. Example: A ClockFrequency may document how the frequency is measured. Example: WeightOnEarth.
Mathematica: GOTCHA: EntityFunction can only return a scalar (although its the 3rd decade of the 21st century)
Mathematica: The slightly less painful ultimate list of links on Object-Orientation (or the lack thereof) and a public plea to Wolfram Research
Webel: Domain Modelling in graphical SysML (and the best SysML tools) is massively, hugely, compellingly, better than in any other language (or tool). [OWL does something very useful but different.]
Webel electronics modelling recipe for SysML: Diagrams can be made less verbose by using stereotype icon shape display mode, by not showing names and types on obvious Ports, by hiding context-specific values, and by omitting {net} tagged values.
MagicDraw/Cameo: Rule: Internal Block Diagram and Block structure compartment: only one symbol for a given Property may be shown.
MagicDraw/Cameo: Display option: You can choose whether to show Domain Specific Language (DSL) stereotypes: 'None', 'All', 'Only Last'
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: An "index" Parsing Analysis Diagram (PAD) showing a collection of Snippets may optionally (but need not always) show the /member tagged value of each Snippet.
Webel Parsing Analysis: SysML: Pseudo Semantic Triple: A «pa:triple» may be applied to a uni-directional Association between SysML Blocks and/or Actors.
Webel Parsing Analysis: SysML: Pseudo Semantic Triple: A «pa:triple» may be applied to a Dependency between SysML Blocks and/or Actors or Properties typed by them.
Webel Parsing Analysis: Pseudo Semantic Triple: When «pa:triple» is applied to a named uni-directional Association the name and a consistent direction arrow should be displayed on the Association symbol in diagrams.
Webel Parsing Analysis: Pseudo Semantic Triple: For «pa:triple» applied to a named one-to-one Dependency, the source is the subject, the name of the Dependency is the predicate, the target is the object.
Webel Parsing Analysis: Pseudo Semantic Triple: For «pa:triple» applied to a named one-to-one or one-to-many uni-directional Association, the non-navigable end Property is the subject, the name is the predicate, the navigable end Property is the object.
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.)
Webel Parsing Analysis: The name of a Parsing Analysis Diagram (PAD) may be drawn from a focus Snippet OR may simply indicate a topic of interest to the analysis
Webel Parsing Analysis: Where too many dashed line "anchors" from Snippets to elicited members lead to clutter they may be selectively omitted from a Parsing Analysis Diagram (PAD) once each member has been collected.
Webel Parsing Analysis: While Associations may be collected as elicited members of a Snippet this can quickly lead to clutter in the /member list display. Often just collecting an end Property as member is sufficient.
Webel Parsing Analysis: While Generalizations may be collected as elicited members of a Snippet this can quickly lead to clutter in the /member list display.
Webel Parsing Analysis: An anonymous Element may be collected as a /member of a Snippet (it is not important whether collected elements list with a clear name under /member, only that they are traceably elicited).
Webel Parsing Analysis: A "focus" Parsing Analysis Diagram (PAD) for one or more Snippets SHOULD always show the /member tagged value of every Snippet.
Webel Parsing Analysis: Acronym: PAD = Parsing Analysis Diagram (may be nearly any diagram type, except those types that must be owned by an elicited model element)
Webel Parsing Analysis: As StateMachine Diagrams are always owned by an element that is not eventually under the Source Input Zone they should not be used as «pa» diagrams. Elicit States instead via the /member section of the specification dialog.
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
MagicDraw/Cameo v19SP3: UML/SysML: HOWTO Set an OpaqueExpression on a Slot that seems to be stuck on a numerical value.
Webel Parsing Analysis: The symbol of a Parsing Analysis Container MUST be usable on every possible diagram type
SysMLv2: On the v2 Comment extension of the v2 AnnotatingElement as a candidate Parsing Analysis Container
The targeting of the Modelica and Simulink simulation language families by the SysML Extension for Physical Interaction and Signal Flow Simulation (SysPhS) encourages development of SysML models aligned with known practices for a wide class of problems!
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).
MagicDraw SysML/Cameo: If you have a SINGLE Allocate from an Activity to a Block it will set that Block to be the Behavior::/context for that Activity.
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)
UML/SysML: In Internal Block Diagrams: If you have a Port with a name that indicates a unique role AND and if there is an ItemFlow on a Connector that implies or suggests the Type of the Port, consider hiding the Type on the Port symbol.
SysML+SysPhS: Flows: If you intend to use a Classifier to type the itemProperty of an ItemFlow on a Connector for a physical interaction you MUST use a Block (not a ValueType or Signal) so your can extend ConservedQuantityKind.
SysML: Flows: If you intend to use a Classifier to type the itemProperty of an ItemFlow on a Connector use a ValueType or Block rather than a Signal, otherwise you'll get probably-unwanted signal receptions on the owning context Block.
SysML: Whether you use a Block, ValueType, or Signal to represent something that flows (and can be applied to an ItemFlow) depends on what you want to achieve. If you want to indicate something structured with value properties with Units use a Block.
SysML: The placement of usages of Blocks, their Ports, and Connectors in an Internal Block Diagrams DOES NOT necessarily represent physical geometry!
MagicDraw SysML/Cameo has a nice feature 'Tools > Delegate Port(s)' accessible from the context menu for splitting Connectors that cross block boundaries into multiple Connectors with "exporting" Ports.
Progressively "exporting" internal Ports of usages of Blocks to the boundary of their using Block may seem like a bit of extra work, but it means you can progressively develop with clean black box views without the Connectors crossing Block boundaries.
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.)
Additional Dependency relationships between ValueTypes and their Units on some SysML diagrams on this site are for educational illustration only (you don't need them in your own SysML models).
GOTCHA: MagicDraw SysML/Cameo 19SP3: Export to Modelica: The name of a redefining Property must be exactly the same as the Property it redefines or it will not export properly!
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").
Webel: SysML: DO NOT sacrifice modelling naming conventions for the mere sake of carrying organisation-specific names! Instead use tagged values of custom stereotypes as metadata to carry alternative names in parallel with systematic model element names.
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).
MagicDraw/Cameo: If you drag a Behavior from the model browser onto the SYMBOL of a State (that does not already own the Behavior) and set it as an 'entry', 'doActivity', or 'exit' Behavior a "wrapper" Behavior owned by the State will be created.
MagicDraw SysML/Cameo 19SP3: GOTCHA: If you drag a Behavior from the model browser onto the 'entry', 'doActivity', or 'exit' field in a specification dialog of a State it WILL BECOME OWNED by the State (which "steals ownership")!
MagicDraw/Cameo: Display options: On an 'entry', 'doActivity', or 'exit' Behavior of a State you may choose to display the specification code of an OpaqueBehavior or just its name.
MagicDraw/Cameo: On dragging a Property onto another Property set it as redefining, the multiplicity of the redefining Property is set to [0..*] if the redefined (dragged) Property only has <UNSPECIFED> Multiplicity
WISHLIST: MagicDraw/Cameo: Ability to set project-wide option to NOT set the multiplicity of a redefining Property to [0..*] on using drag-n-drop when the redefined (dragged) Property has <UNSPECIFED> Multiplicity
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.
SysML: When using Property::defaultValue and Property::redefinedValue to carry a "shadow hierarchy" of redefinitions across an entire system hierarchy, considering using a user-defined keyword such as «configuration» or «scenario» on each redefining Block
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"!
Block naming: If you find you've got similar blocks named 'Thing' and 'Thing2' then 'Thing' is probably better renamed 'Thing1'
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)
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!
SysPhS-1.1: Apparent use of part Property with «port» keyword (instead of standard SysML Port) leads to property path symbols appearing inside the boundary of context blocks (instead of within a Port symbol on the boundary) in IBDs and Parametric Diagrams
Webel vs SysPhS-1.1: Recommend use standard SysML Ports instead of block part property with «port» keyword
MagicDraw/SysML vs SysPhS-1.1: Can't reproduce the "shortcut" property path representation of some properties nested within Ports as shortcut symbols fully inside the diagram frame. (Might be a specification diagram style issue.)
Concerning definitions: "a connector end" vs "a connector between 2 ends" vs "connection" vs "connect" in various technologies
Modelica: Naming convention: Why does the OnePort family of electrical components have 2 Pins? Where is the "one port"?
SysPhS: MagicDraw/Cameo: In the sysphs_profile the properties for PhSVariable have multiplicity [1], so the defaults always appear explicitly (but may be overridden): isContinuous: Boolean = true, isConserved: Boolean = false, changeCycle: Real = 0
GOTCHA: MagicDraw SysML/Cameo 19SP3: Export to Modelica: 'entry', 'doActivity', or 'exit' Behaviors of a State must be directly owned (not just "wrapped") or they won't be seen on export!
MagicDraw SysML/Cameo: GOTCHA: A Constraint created and applied to a ConstraintBlock via the sidebar menu is NOT owned by the ConstraintBlock!
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).
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).
SysML: Some users employed the ~ tilde prefix for a conjugated Port type long before it was introduced for ~InterfaceBlock and you MAY use it to name a regular Block that is not an ~InterfaceBlock
SysML: Electronics: When modelling electronics systems you should to decide and make clear (with ItemFlow and/or Stereotypes) whether you are modelling signals (information, does not care about GND) or a physical design with voltage (needs GND)
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.
UML/SysML: In Internal Block Diagrams: Consider hiding the name of a named Port or Property in a Diagram if its Type is sufficient to indicate its role.
Dependency/Usage relationships in some referenced UML/SysML diagrams on this site are for educational illustration only, they are NOT part of the actual model.
