STRICT

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: A 'source' Document must have one (only) of a URL or a URN (includes ISBN or other unique identifier) for use as a URI

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: 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: 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.

Webel Parsing Analysis: A Parsing Analysis Container MAY collect any other Element type as a member EXCEPT for another Parsing Analysis Container

Webel Parsing Analysis: A Parsing Analysis Container MAY own other child Parsing Analysis Containers

Webel Parsing Analysis: The symbol for a Parsing Analysis Container MUST be able to indicate the unique domain source document from which its analysed text extract was quoted.

Webel Parsing Analysis: The symbol for a Parsing Analysis Container MUST be able to OPTIONALLY display a list of names of elicited model elements (a.k.a. members)

Webel Parsing Analysis: It SHOULD be possible to relate one Parsing Analysis Container to another and stereotype that relationship as an RDF/OWL-like semantic triple

Webel Parsing Analysis: It MUST be possible to collect elicited members of a Parsing Analysis Container graphically in diagrams using relationship-like path drawing (not just via a specification dialog or other indirect modelling means)

Webel Parsing Analysis: The symbol for the relationship between a Parsing Analysis Container and elicited model elements SHOULD be a dashed line (like the anchor/handle line used with a UML Comment)

Webel Parsing Analysis: The symbol for a Parsing Analysis Container MUST be text-friendly and evocative of quoting a domain source text extract

Webel Parsing Analysis: The symbol of a Parsing Analysis Container MUST be usable on every possible diagram type

Webel Parsing Analysis: A Parsing Analysis Container MUST NOT be able to own the Elements it elicits

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.

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: The water temperature from TemperatureIncreaseConstraint and HeatingCalculationConstraint starts at 0 °C (should probably be the environment temperature 20 °C). Needs an additional parameter and initial value.

This page identifies a possible issue, inconsistency, concern, error, or bug!

One of the ways Webel IT Australia helps promote tools, technologies, and languages is by donating a lot of time identifying, tracking, and reporting potential issues, in order to help vendors and developers improve the tools and technologies. In some cases, we also offer workarounds and advice for users. All issues tracked on our public site are offered most constructively and with sincerest gratitude to the tool vendors and technology developers.

DISCLAIMER: Vendors do not officially endorse issue analysis by Webel IT Australia.

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.

GOTCHA: MD SysML/Cameo 19SP3 vs SysPhS-1.1: Export to Modelica does not see a 'doActivity' on a State (does not write it to a Modelica algorithm), you MUST use an 'entry'!

Webel Twin Pattern: DigitalTwin: The multiplicity of 'digitalEntity:@Entity' and 'physicalEntity:PhysicalEntity' MUST be [1] when the DigitalTwin is in the state Attached, the @Entity is in the state Bound, and the PhysicalEntity is in the state Exists.

UML/SysML: If you have a Boolean "state flag" attribute corresponding to a State you MUST set it on an 'entry' of the State, not on the 'effect' of a Transition into the State (otherwise with multiple incoming Transitions it could be WET and breaks SSoT).

Webel Twin Pattern: An ActualPhysicalAsset is an asset that is also a «physical» PhysicalEntity.

Webel Twin Pattern: A DigitalTwin and PhysicalEntity must both be 'attached' to Sensors and/or Actuators under management of the DigitalTwin before the twinning control loop is fully entered.

Webel Twin Pattern: The sensor/actuator twinning control loop can involve automated devices (SensorDevice and/or ActuatorDevice) and or humans (SensorHuman and/or ActuatorHuman).

Webel Twin Pattern: A DigitalTwin (even a "process twin" or "finance twin"), always, without exception, BY DEFINITION HERE either directly or indirectly involves at least one existing or anticipated PhysicalEntity (even if only via another DigitalTwin)!

Webel Twin Pattern: A DigitalEntity (a.k.a. «digital» @Entity) used as a digital variant must not be directly bound to a «physical» PhysicalEntity (may not directly actuate/sense/affect)

Webel Twin Pattern: A LogicalProcess may only act on a PhysicalEntity via a PhysicalProcess

Webel Twin Pattern: Communication between the ControlSystem of a DigitalTwin and its digitalEntity:@Entity is via a dedicated protocol (ReadTwin, WriteTwin) distinct from the sensor reading or actuator driving signals.

Webel Twin Pattern: A DigitalTwin may use one or more variantEntity:@Entity[0..*] to explore the impact of changes (optimisation studies, trade off studies) and then use them to drive the PhysicalEntity into a desired state (via its ControlSystem).

Webel Twin Pattern: The primary aim of the digitalEntity:@Entity of a DigitalTwin is to replicate its physical:PhysicalEntity as closely as possible (not to explore variants).

Webel Twin Pattern: A «digital» DigitalEntity (a.k.a. @Entity) is NOT a representation! It is a digital encapsulation (it can only be perceived at the level of "bits and bytes"). It HAS many representations (such as views)!

Webel Twin Pattern: A PotentialPhysicalAsset is «digital», not «physical». It is used to acquire (an existing) or create (build, manifest, make) an «physical» ActualPhysicalAsset, which is a special case of «physical» PhysicalEntity.

Webel Twin Pattern: A DigitalTwin manages a control loop including a PhysicalEntity and a DigitalEntity (a.k.a. @Entity) that «replicates» it. It typically includes at least one Sensor and at least one Actuator.

Webel Twin Pattern: It is a DigitalEntity (a.k.a. @Entity) - not the DigitalTwin that owns it - that directly «replicates» geometrical, spatial, and material aspects (only) of a single PhysicalEntity.

Webel Twin Pattern: A DigitalTwin must model processes and the entities they act on separately.

Webel Twin Pattern: A «digital» DigitalEntity (a.k.a. @Entity) encapsulates strictly geometrical, spatial, and material aspects of a «physical» PhysicalEntity only. BY DEFINITION of this pattern it DOES NOT encapsulate processes!

Webel: SysML-1.7/SysMLv2: WISHLIST: Constraint: A BindingConnector used for pure proxying MUST NOT be typed by an AssociationBlock by definition, because the associated information can be mis-appropriated to undermine the proxy equality!

Webel Parsing Analysis diagrams do their job once - namely traceable elicitation of model elements - and are then only kept as a reference! The elicited model elements are then used elsewhere in the final model.

In Webel Parsing Analysis elicited model elements MUST eventually be moved out of the 'source' (or '0-source') Package/Model zone and under a main project Package/Model area. (Use the owner display option to check.)

Just because you can't see a Feature or some other aspect of a UML or SysML Element in a tool on a symbol does NOT mean it does not exist in the underlying model (repository)!

Rule #1: A UML or SysML Element in a tool is NOT just an Element symbol in a diagram! A Note is not an Element (compare with a Comment).

GOTCHA: Just because an InitialNode MAY have more than one outgoing ControlFlow and offers tokens on every outgoing ControlFlow does NOT mean that every outgoing edge takes a control token; InitialNode does NOT act like an implicit fork!

Webel: A plain Dependency that is not stereotyped is always strictly timed-ordered; the supplier (target) must exist before the client (source).

Visual nesting of InstanceSpecification symbols has no meaning in the underlying model, only assignment to a Slot does!

When dealing with required Interfaces you must use Usage (not Dependency) and it has dedicated "socket" notation.

Use singular Property names, let the multiplicity indicate plurality.

MagicDraw/Cameo: If you make a copy of the SYMBOL of an Element in a Diagram you have only copied the SYMBOL, it represents the same Element! If you make a copy of an Element in the model browser you have indeed made a unique new (distinct) Element!

Webel Parsing Analysis: A Snippet (keyword «snippet») MUST always have exactly one domain 'source' Document (keyword «document»).

Webel Parsing Analysis: A custom Document stereotype (keyword «document») extends the UML standard profile Document that extends Artifact (which is NOT in the UML4SysML intersection). Such a Document may act as the 'source' of a «snippet».

Webel Parsing Analysis: Create a top-level 'source' or '0-source' Package/Model SEPARATE from your project model. All source «document» elements and «snippet» extracts and «pa» diagrams MUST be ultimately owned by that top-level Package/Model as ancestor!

Webel «pa» Parsing Analysis Diagrams (PADs) are "scratchpads" used to elicit model elements traceably from text Snippets (extracts from source Documents). While BDDs are a good initial choice, most types of SysML diagram can be used as a «pa» diagram.

Webel Parsing Analysis: If you wish to show a «snippet» comment symbol (with its body text) in a presentation diagram (that is NOT a «pa» diagram) remove the '/member' tagged value from display so the only visible tagged value is 'source'.

Webel Parsing Analysis «pa» diagrams are NOT intended as final presentation diagrams! They serve merely to traceably elicit model elements, which may then be shown in other (typically much tidier) presentation diagrams elsewhere.

AVOID "mixed" functional (behavioral) allocation levels! DO NOT Allocate from Usage level (Action) to Definition level (Block) or from Definition level (Activity) to usage level (part Property) - even if formally permitted in SysML.

DO NOT use Connector names that are identical to the names of the Associations that type them!

DO NOT use Property names that are identical to the names of the Classifier (Class, DataType, Block, ValueType) that type them!

ValueType naming: The Webel convention is 'UpperCamelCase' (a.k.a. PascalCase).

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!

DO NOT use spaces in Property names or Class/Block names! If you want to communicate familiar names of elements within an organisation use a custom stereotype and tagged values (such as 'aka')!

Colours: Very strongly recommend (insist) DO NOT use shadows or gradient fill adornments on diagrams!

For SysML Blocks and InterfaceBlocks used to type Ports with physical flows use 'F_UpperCamelCase' [may be combined with acronymn conventions]

For SysML Blocks and InterfaceBlocks used to type Ports with contracts use the naming convention 'I_UpperCamelCase' [may be combined with acronymn conventions]

SysML: Naming: Always use either anonymous or first letter lower case for Property, ObjectNode and InstanceSpecification names; no exceptions (unless using names to "quote text")! Valid: 'lowerCamelCase' OR 'tla' vs TLA acronym OR 'uCC' vs UpperCamelCase

When using acronyms in names of Classifiers either treat them as a word 'TlaLikeThis' or suffix with an underscore 'TLA_LikeThis', except at the end of the name 'LikeThisTLA' is admissable.

Subscribe to STRICT