Webel: SysML4Mathematica: A custom stereotype «M:Paclet» applied to a SysML Package denotes a Wolfram Package Paclet. An «M:Package» is a specialisation of SysMLv1 Block and denotes a Wolfram Language Package.
Webel: SysML4Mathematica: A SysML/UML Usage (keyword «uses») is used to indicate a Wolfram Package Needs import, where an «M:Package» is a specialisation of Block (not a SysML/UML Package) and denotes a Wolfram Language Package.
Webel: SysML4Mathematica: Activity Diagrams used purely for analysis and as development aids are not required to show every ControlFlow, may omit InitialNode and ActivityFinalNode, and are not required to fully validate in SysML tools or execute.
Webel: SysML4Mathematica: An OptionsPattern[] may be represented by an «M:OptionsPattern» SysMLv1 Block with «M:Opt» properties. An «M:Opt» property represents an Options[] Rule IMPLICITLY (an «M:Opt» does not use the Rule block modelling recipe).
Mathematica: CONVENTION: A prefix 'eq$' indicates a symbolic equation (typically using 'sym$' human-friendly markup "symbols")
Cameo Simulation Toolkit: HOWTO test an EnumerationLiteral value in a (Groovy) script in an OpaqueAction/Behavior. Use kind.name == "value"
Webel: SysML/MBSE: Suggest don't fuss about ownership (containment) too much early on. Focus on "logical" modelling, values, flows, relationships between elements. Suggest perform regular separate modelling "housekeeping" sweeps to deal with ownership.
SysMLv1: Webel often uses Model packages for most modelling and reserves Package for code-like elements, OpaqueBehavior sub-libraries, instances, and elements reverse-engineered from code. But there are no hard and fast rules about Package vs Model.
Webel: SysML: If you are working within a self-contained model you may freely include diagrams icons for navigation and model elements from other Packages in a Package Diagram or "focus" BDD but beware of breaking Shared Package and library dependencies!
SysMLv1: MagicDraw/Cameo: GOTCHA: If you DRAG a Signal onto a Block symbol it will create a Reception. One way to create a Property typed by a Signal is to use a composite Association. Or just create an untyped Property then type it by the Signal.
SysMLv1: CAUTION: Only a Signal can be used for a SendSignalAction or MessageEvent trigger of an AcceptEventAction, not a Block or ValueType, even if they are valid types for a SysML FlowProperty! But you can "wrap" a Block or ValueType in a Signal.
ISSUE: Cameo Simulation Toolkit: v2024x: Although does not respect inheritance of attributes of Signals on SendSignalAction or un-marshalling AcceptEventAction DOES require them on 'effect' Behaviors.
SysMLv1: Cameo Simulation Toolkit: GOTCHA: Do not use Associations with Signal attributes, they will become null when fed as argument values for Parameters of 'effect' Behaviors of Transitions
SysMLv1/UML2: Whilst fUML does not support InterruptibleActivityRegion, there are still ways to interrupt a StructuredActivityNode in Cameo Simulation Toolkit
SysMLv1.7/fUMLv1.4: Cameo Simulation Toolkit v2024x: Using an extending Enumeration literal as a parameter argument value runs but a WARN is issued.
SysMLv1: Cameo Simulation Toolkit: 2024x: GOTCHA: SendSignalAction: Nested Ports won't appear in the selection dialog for 'onPort' (or work for Drag n' Drop) unless «InvocationOnNestedPortAction» has been applied (they are filtered out).
ISSUE: Cameo Simulation Toolkit: v2024x: Does not show argument Pins corresponding to inherited attributes of Signal on SendSignalAction or an un-marshalling AcceptEventAction. No known UML2.5.1 or fUML-1.4 constraint; no obvious tool display option.
Cameo Simulation Toolkit includes a (basic) TimeEvent, but fUML-1.3/1.4 does not. There are many different supported time units for duration constraints, and you can also use property values in durations.
TIP: SysMLv1/UML: Cameo Simulation Toolkit: HOWTO convert an fUML ReadLine CLI String to a Boolean for cleaner DecisionNode tests against a LiteralBoolean [true] guard.
TIP/GOTCHA: SysMLv1/fUML: Cameo Simulation Toolkit: If you have a ControlFlow loop with a DecisionNode test you MUST have a MergeNode for the continuation path ControlFlow (typically entered also from an InitialNode or other loop starting point).
TIP/GOTCHA: SysMLv1/UML: Cameo Simulation Toolkit: If you use a «decisionInputFlow» to a DecisionNode you MUST also have a ControlFlow to the DecisionNode; if you don't use an explicit «decisionInputFlow» you don't need the "extra" ControlFlow
SysML: HOWTO Represent a person as an external block-based SysML «actor» in one lower context and as an internal participating «person» in another higher context, with traceability. For modelling systems of systems in a team with many modellers.
Dr Darren says: 'You can't obtain the optimum benefit of graphical engineering with SysML without becoming mindful of the cognitive and artistic aspects of graphical modelling. The "Zen of SysML" matters!' Just like an elegant electronics device design.
GOTCHA: MagicDraw/Cameo: SysMLv1/UML: The argument context required to see results in Evaluation Mode for custom OpaqueBehavior scripts might not be the same as required for use in an Operation From Model for a Derived Property on a table column
GOTCHA: MagicDraw/Cameo: SysMLv1/UML: If you can extract model info using an OpaqueBehavior and you can see that in the Evaluation Mode in the Expression Editor it might not appear in a column in the Generic Table Diagram because the final Type is not set
GOTCHA: MagicDraw/Cameo: SysMLv1/UML: The 'name' of a Derived Property is parsed and sometimes displayed quite differently in column names. Be careful when mixing lower case and UPPER CASE in the middle of Derived Property names.
ANNOUNCEMENT: Webel IT Australia is developing an Online Subscription Video Tutorial Series version of our hands-on course for MBSE with SysML(v1) with Cameo Systems Modeler tool videos and OMG SysML-language only videos. Register your interest now!
Webel: SysMLv1: MagicDraw/Cameo: CON: Using anonymous property and/or action names is not ideal for Element Compartment and Note callout displays when Usage level allocation is used. But allocation table and matrix views are better anyway.
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: 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.)
SysML tools can ALSO be used for many graphical Model-Based Engineering tasks that benefit from Single Source Of Truth - and even without any formal System Engineering methodology (which is NOT to say that formal System Engineering is not also useful).
Webel: Dr Darren says: "Many aspects of older Document-Intensive Systems Engineering methodologies and the reporting obligations they impose on their users were intended to address problems that simply DO NOT EXIST ANYMORE with modern MBSE with SysML!"
Webel: SysML: "Really long human friendly element names with spaces make my diagrams easier to read". Dr Darren says "No they don't! Prefer code-like naming (or anonymous for typed elements) wherever possible. Use custom tagged values for other names!"
Webel: SysMLv1: TIP: Use semantically meaningful Association names and/or custom Stereotypes where applicable. They can also often be used as pseudo OWL/RDF semantic triples. But don't use Association names where an ItemFlow can capture an exchange item!
Webel: SysML: SE: Terminology: '«logical» handler' is used for a specific kind of «logical» subsystem (aka 'conceptual subsystem') that is a SPECIFIC collaboration of parts that handle one Activity usage in a higher level «whitebox» Activity.
HOWTO "cheat" with two-level white-boxing and tracking stereotypes because you just don't want that darn "extra" logical subsystem (conceptual subsystem) Block the systems engineers reckon you are supposed to use (and why it's easier to actually use one)
Webel: SysML: Heard of "follow the money"? In MBSE we "follow the flows"! Identify requests, data packets, messages, signals early on and use ItemFlow as often as you can wherever you can! Adopt a signal processing mindset throughout (systems thinking).
SysMLv1: MagicDraw/Cameo: Oh no, I lost my part or reference property? Where did it go? The Symbol Properties option for 'Show Association ends as Attributes' may help you find it!
SysMLv1: A part Property or reference Property is not necessarily a 'memberEnd' or 'ownedEnd' of an Association ('association' or 'owningAssociation'). But an Association always as at least 2 'memberEnd' Properties. (With some MagicDraw/Cameo tool tips.)
Webel: SysMLv1: Overview of annotated Diagram Slides and Note pages related to general high level SysML modelling principles (some specific to MagicDraw/Cameo). Recommended reading for all Webel SysML/MBSE course attendees.
Webel: SysMLv1: Overview of annotated Diagram Slides and Note pages related to UseCases and their combination with a System (of interest), SystemContext, and drill-down to scenario Sequence Diagrams (Interactions) and Activity Diagrams.
SysMLv1: A common misunderstanding: Just because a UseCase symbol appears inside the rectangle of a subject Classifier does NOT mean that it is owned by that Classifier and can only have that one Classifier as 'subject', and it does not imply ownership!
Webel: SysML1.7: Port contract matching is Feature-based, not Type-based. There's nothing particularly magical or special about use of an ~InterfaceBlock on a "conjugating" SysML Port, it's just a convenient way of managing one-to-one Feature matching!
SysMLv1: "Should" the 'subject' of a top-level UseCase be a System or (a particular) SystemContext? Answer: Which one would you like to be correct!? [WITH EXTERNAL LINKS]
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: MagicDraw/Cameo: Synchronising ItemFlows on Connectors with ObjectFlows in Activities using the Item Flow Manager. Nice!
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).
SysMLv1: MagicDraw/Cameo: INTRINSIC GOTCHA: Care must be taken with ownership of Activities used as UseCase scenarios vs the ‘subject’ of the UseCase. Make sure you don’t get an Activity ‘context’ mismatch! It's up to you to manage it as intended.
SysMLv1: MagicDraw/Cameo: Automated creation of usage-level allocation swimlanes in SysML Activity Diagrams for part properties of a Block. EXAMPLE: A UseCase scenario within a SystemContext as UseCase ‘subject’.
SysML/MBSE: Many videos, tutorial slides, and guides to MBSE with SysML present particular modelling recipes as though they are THE way to do something in SysML, not just ONE way of doing it in SysML. They are not necessarily enforced by the SysML spec.
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: 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.
Webel: SysML/MBSE: Dr Darren's Open Letter on why you may initially need the Model-Based (MB) and Single Source Of Truth aspects of MBSE more than the formal Systems Engineering (SE) aspect (or even initially no formal SE process at all) to benefit most!
Webel: SysMLv1: Dr Darren for LinkedIn: On "Trusting The Type" and avoiding unnecessary verbose repetitive Property names ... unless you really, really need them and really do have reasons to use them, and then only use concise role indicators anyway!
TIP: Mathematica: Webel's ultimate guide to using Abstract Data Types to create "pseudo classes" (strong types) with inheritance for the Wolfram Language, all modelled in SysML!
TIP: SysMLv1: MagicDraw/Cameo: Activity Diagrams: Consider using the Pin display mode 'Name And Type Labels Inside' for 'Position of Labels'. Dr Darren swears by it!
TIP: UML/SysML: MagicDraw/Cameo: Activity Diagrams: Pins: You can display the 'multiplicity' of the underlying Parameter on Pins symbols using Edit Compartments. (The 'multiplicity' shows anyway if the :Type is shown.)
TIP: UML/SysML: MagicDraw/Cameo: Activity Diagrams: ActivityParameterNodes: Displaying the underlying 'parameter::multiplicity' using Edit Compartments is extremely useful!
UML/SysML: MagicDraw/Cameo: Edit Compartments: ActivityParameterNode: Can't select the 'parameter::multiplicity'? Run the synchronisation between the Activity in the direction Synchronize Activity Parameter Nodes by Activity Parameter then try again!
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: Mathematica: CONVENTION: A prefix '$doc' indicates a documentation String for each primary variable/quantity (argument or output)
Webel: Mathematica: 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 Mathematica Symbol - to avoid namespace clashes!
Webel: SysML4Mathematica: Does every bit of the Mathematica code need to be modelled in SysML? No. Typically just the main function parameters and their interdependencies, data structures, and main code logic. Except for special or educational purposes.
Webel: SysML/UML: Some example diagrams show extremely fine-grained and trivial examples purely for educational and capability demonstration purposes (not as practical recommendations for real-world projects). You can sometimes just use code in SysML.
Webel: SysML4Mathematica: POLICY: Handle flow sign changes via a single negative (not duplicated and "adjusted" algebra). This strategy may come at a very slight performance cost (for benefit of more robustness).
Cameo Simulation Toolkit: You can use Mathematica as an external maths engine to share maths between an OpaqueBehavior and a ConstraintBlock using custom auto-loaded Mathematica functions (keeps a project nice and DRY and respects Single Source of Truth)
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: SysML4Mathematica: TIP: Representing Mathematica Paclets and their inter-dependencies as SysML Packages modelled in SysML Package Diagrams can really help you organise your Wolfram Language code on complex projects!
Webel: SysML4Mathematica: TIP: Representing Mathematica functions as SysML ConstraintBlocks modelled in Block Definition Diagram (BDD) overviews can really help you organise and document your Wolfram Language code on complex projects!
Webel: SysML4Mathematica: TIP: Representing Mathematica functions as SysML ConstraintBlocks modelled in SysML Parametric Diagrams and as Activities in SysML Activity Diagrams is super for analysing the dependencies between functions and their arguments!
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 '_'
SysML1.x: MagicDraw/Cameo: The nested property path concept is implemented using a vendor-specific stereotype extension NestedPropertyPath
SysML1.x: MagicDraw/Cameo: The value property concept is implemented using a vendor-specific stereotype extension ValueProperty
SysML1.x: MagicDraw/Cameo: The shared property concept is implemented using a vendor-specific stereotype extension SharedProperty
SysML1.x: MagicDraw/Cameo: The reference property concept is implemented using a vendor-specific stereotype extension ReferenceProperty
SysML1.x: MagicDraw/Cameo: The part property concept is implemented using a vendor-specific stereotype extension PartProperty
SysML1.x: MagicDraw/Cameo: The block property concept is implemented using a vendor-specific stereotype extension BlockProperty
SysML1.x: MagicDraw/Cameo: The constraint parameter concept is implemented using a vendor-specific stereotype extension ConstraintParameter
SysML1.x: MagicDraw/Cameo: The constraint property concept is (was) implemented using a vendor-specific stereotype extension ConstraintProperty [VENDOR-DEPRECATED]
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 '{}'. (Extending types may adapt the notation.)
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 main logic flow of Mathematica code with Activity Diagrams it isn't necessary to model every Mathematica construct. Placeholder Actions, OpaqueActions , and OpaqueBehaviors (as CallBehaviorActions) may be used.
Webel: SysML4Mathematica: Cameo Systems Modeler: Can perform calculations with a custom Quantity ValueType (for Mathematica) directly, but DOES NOT perform units-aware algebra (no automatic conversions)
SysML/UML: MagicDraw/Cameo: To display the body of an OpaqueBehavior on a usage (CallBehaviorAction) in an Activity Diagram use an element property callout of 'Body' into a Note with a handle to the CallBehaviorAction
Webel: SysML4Mathematica: An '@' prefix in the name of a Block indicates a data structure (such as an Association or List) that does not have a corresponding MTools class or a Webel Abstract Data Type (ADT) "pseudo class" in the Wolfram Language code.
Webel: SysML4Mathematica: An '@' prefix in the name of a ConstraintBlock, Activity, or OpaqueBehavior indicates that it is a "@pseudo" function not represented directly in the Wolfram Language or Webel code libraries (typically for minor maths or logic)
ISSUE: MagicDraw/Cameo: v2022x Golden, v2022xRefresh1: Comment can't connect anchor to another Comment as annotatedElement
[FIXED in v2022Refresh1]: BUG: MagicDraw/Cameo: 19SP3/v2022xGolden: Activity Diagrams: Pin display mode 'Position of Labels' does not stick, label positions in Diagrams have sometimes moved after re-opening a project [and "FIX"] ARCHIVAL (2022): This content is now considered historical only!
Webel: SysML: MagicDraw/Cameo: Strongly recommend that you set the Perspective to 'Full Featured' and 'Expert' at the very beginning at the start of every new project
On the Webel Best Practice modelling tips for SysML (and UML). If you want to model the Webel way, use them, if you don't, ignore them. They are ONLY offered as options and graphical modelling paradigms and idioms for you to consider.
Webel: On going beyond SysML (and UML) with additional modelling practices, policies, and additional semantics
Webel: SysML: TIP: CONVENTION (default policy suggestion): Use reverse time ordering for Dependency, reserve Usage, PackageImport, ElementImport for software dependencies
MagicDraw/Cameo: UML/SysML: TIP: Activity Diagrams: Learn how to use the Refactor > Extract feature to divide-and-conquer and identify cleaner flow and logic. Get control of those crossed wires!
Webel: MagicDraw/Cameo: UML/SysML: TIP: Activity Diagrams, StateMachine Diagrams, and port-based IBDs: Keep it loose initially with oblique (no break) paths, then square it up with rectangular paths at the very end
UML/SysML: TIP: Using Cameo Simulation Toolkit will strengthen your use of Activity Diagrams even when they are "just" analysis diagrams
MagicDraw/Cameo: 2022xGolden: TIP/GOTCHA: Mac: HOWTO Load the available plugins in the Resource/Plugin Manager
Cameo Simulation Toolkit: v19SP3: GOTCHA/BUG: When a Property is typed by an abstract Block an instance of a concrete specialising Block (where available) will automatically be created and assigned even when the lower multiplicity is 0
MagicDraw/Cameo 19SP3/v2022xGolden: [FIXED in v2022xRefresh1]: Activity Diagrams: Pin display mode 'Position of Labels' does not work correctly for 'Name And Type Labels Inside', only shows the Name inside (not the Label) [and WORKAROUND] ARCHIVAL (2022): This content is now considered historical only!
Cameo Simulation Toolkit: You can assign the results of simulations calculations on instances to the default values of properties of the Classes/Blocks that type the instance.
UML/SysML: MagicDraw/Cameo: 19SP3: Instance Table Diagram sometimes does not display the values for nested value properties
UML/SysML: MagicDraw/Cameo: Instance Table Diagrams are one of the most powerful features of MagicDraw/Cameo! Learn to use them to progressively test, debug, and evolve your models as you work!
UML/SysML: MagicDraw/Cameo 19SP3: GOTCHA/TIP: An Instance Table will not display a row for instances typed by an abstract Class/Block (although one can show such instances as InstanceSpecification symbols on a Class Diagram or Block Definition Diagram)
UML/SysML: Cameo Simulation Toolkit 19SP3: GOTCHA/TIP: ConstraintBlock constraints: Not every available constraint language can handle Enumeration literals (if in doubt choose 'English')
UML: Cameo Simulation Toolkit 19SP3: GOTCHA: CreateObjectAction ignores an Artifact as 'classifier' even though Artifact is a Classifier
GOTCHA: UML/SysML: Cameo Simulation Toolkit 19SP3: A [true] or [false] guard on an ActivityEdge MUST be a LiteralBoolean, not just characters typed in, or the evaluation may give unexpected or ill-defined results
UML/SysML: Cameo Simulation Toolkit 19SP3: A parent Activity with a DecisionNode that uses a Activity as a decisionInput Behavior terminates immediately after the decisionInput terminates (but OpaqueBehavior works)
UML/SysML: Cameo Simulation Toolkit 19SP3: GOTCHA: Will not evaluate a guard using a token from a decisionInputFlow UNLESS a decisionInput Behaviour is explicitly defined (but Alf does)
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: MagicDraw/Cameo: SysML1.6+: ElementGroup-based Snippets do not list in the compartment of Package/Model symbols because ElementGroup is based on the UML Comment, which does not list in Package/Model symbols.
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.
UML/SysML: MagicDraw/Cameo: WARNING: If you assign a value to a Slot for an untyped Property then assign a ValueType later it will DELETE your assigned value! Assign a type first .
The SysML1.6 derived /tracedTo is only available on AbstractRequirement (but in MagicDraw/Cameo you can use derived relationships to achieve the same thing on other kinds of NamedElement).
The SysML Trace relationship can be used as a quick way to traceably elicit model elements from an identified diagram or table from a domain source document. You may visually remove the Trace symbols as each element is elicited to reduce clutter.
The UML «Trace» and SysML Trace can't be applied to a Slot as target (because Slot is just an Element, not a NamedElement).
Webel Parsing Analysis for SysML: Track and display alternative names, human friendly names, organisation-specific names, and identifiers using tagged values for a custom stereotype «pa:term» (adapt or extend as required).
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: 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 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
You DO NOT have to wait for SysMLv2 to do Model-Based Systems Engineering with SysML! You can do MOST of what you need to do with SysMLv1.6/1.7 and you WILL be able to migrate models to SysMLv2 once tool support matures. Start your SysML models NOW!
MagicDraw/Cameo v19SP3: UML/SysML: HOWTO Set an OpaqueExpression on a Slot that seems to be stuck on a numerical value.
MagicDraw/Cameo v19SP3: vs SysPhS-1.1: OpaqueExpression for Slot value exports to Modelica as 'null' if only uses a single variable. WORKAROUND/HACK prefix the variable with '1 *' [FIXED in v2021x]
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
SysMLv2: On the v2 Comment extension of the v2 AnnotatingElement as a candidate Parsing Analysis Container
SysMLv1.x: Q: Why can't a Package with PackageImports be used as a Parsing Analysis text container? Why is the SysML1.6 ElementGroup (extended and customised as the Webel «snippet») far better suited for text-driven model element elicitation?
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!
MagicDraw/Cameo v19SP3: vs SysPhS-1.1: Modelica export: Direct binding from a PhSVariable value property within a FlowProperty of a Port to an inner value property does not flatten. WORKAROUND: Use an intermediate constraint property.
MagicDraw/Cameo v19SP3: Does not support display of context-specific values on a FlowProperty symbol within a Port in an IBD
SysML vs Modelica: GOTCHA: Terminology: A 'connector' in Modelica is equivalent to the Type of a Port in SysML. A Connector in SysML-1.x is equivalent to a 'connect(source,target)' in Modelica.
MagicDraw/Cameo: Modelica export: Need environment option to disable generation of layout annotations (not just on individual export dialog)
MagicDraw/Cameo v19SP3+SysPhS-1.1: Does not cleanly export INLINE Modelica 'if/then/else' statements (a.k.a. "switching" form)
SysPhS: MagicDraw/Cameo v19SP3: Export to Modelica does not interpret as 'start' the default on a PhSVariable assigned via ElementValue to a PhSConstant
MagicDraw/Cameo: GOTCHA: When applying a numerical default to a value property make sure the value property has already been typed by Real or Integer (or a ValueType that extends one of them) otherwise it will assign a LiteralString as default.
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 use a Signal to type the itemProperty of an ItemFlow on a Connector, care must be take in how you create the Property or you might get an unwanted signal Reception 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!
In the Webel terminology for a basic control loop there is an 'aim' value (controlled via an actuator) and a 'got' value (a value read from a sensor). The 'got' value is NOT necessarily exactly the same as the actual physical value.
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).
MagicDraw/Cameo: SysML Parametrics: To colour instance table cells to indicate broken constraints you need to create at least one Simulation Configuration Diagram, which loads a validation profile with colour coding rules.
MagicDraw/Cameo v19SP3 vs SysML&SysPhS: Export to Modelica: The exported layout annotations appear to be completely broken (at least vs Wolfram SystemModeler) just de-select generation of them on export.
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: 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.
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.
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!
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 v19SP3 vs SysML&SysPhS: GOTCHA: Will NOT correctly export a SysML-1.6 «~interfaceBlock» to Modelica (but does cope with a tilde ~ prefix in the name of a plain InterfaceBlock)
MagicDraw/Cameo vs SysML&SysPhS: GOTCHA: Will NOT export a non-normative System «system» block to Modelica, it only recognises a plain Block «block»!
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
Webel: UML/SysML: Navigation: ALWAYS 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"! [But beware of shared package cross-dependencies]
MagicDraw SysML/Cameo: You can customise the generic query table diagram kind to check that the context Blocks of your Parametric Diagrams only contain BindingConnectors (not Connectors)
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)
MagicDraw/Cameo: v19SP3: Property created by dragging onto a Class or Block a symbol of a Classifier named with a single letter capital name 'N' has a poor name 'N:N'
MagicDraw/Cameo: You can drag a Class symbol onto a Class symbol (in a Class Diagram) or a Block symbol or ValueType symbol onto or Block symbol (in a Block Definition Diagram) to create a new part property or value property
MagicDraw/Cameo: You can drag out a Property (or Port) from a Class or Block symbol to create an Association with the Property (or Port) as one end
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.)
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'
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
SysML: HOWTO Safely incorporate ConstraintBlock equations from a library into a project with local ValueType variants: CASE: SysPhS vs ISO-80000 ModelLibrary
SysPhS-1.1: When RealSignalInElement or RealSignalOutElement are used to type a SysML Port, assignments to the FlowProperty 'rSig' map to the Port name (only) when mapped to Modelica.
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'!
SysML: Although not encouraged, you can still use a DataType to type a Property of a Block, it just won't be listed in the 'values' compartment. Prefer the SysML ValueType versions of primitives!
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!
SysML-16: Taken literally the text and OCL of constraint 'Block::6_valueproperties_composite' imply that every FlowProperty typed by a ValueType should have AggregationKind 'composite'
MDSysML19SP3: Validation engine does not report value properties with AggregationKind other than composite
MagicDraw SysML/Cameo: 19SP3: Does not seem to support export to Modelica from a Package [use a SysML Block as root instead]
MagicDraw SysML/Cameo: SysPhS: Export to Modelica: It does not seem to matter whether you give the language of Constraints as 'Modelica' or 'sysphs' (although SysPhS specifies a restricted SysPhS expression grammar)
MagicDraw SysML/Cameo: GOTCHA: Export to Modelica only includes owned Constraints (not just applied Constraints) under the 'equation' export
MagicDraw SysML/Cameo: GOTCHA: A Constraint created and applied to a ConstraintBlock via the sidebar menu is NOT owned by the ConstraintBlock!
MagicDraw SysML/Cameo: 19SP3: Export to Modelica from TestBed (for SignalProcessor) sample does not validate in Wolfram SystemModeler
MagicDraw SysML/Cameo: 19SP3: Export to Modelica from SysPhS sample for HumidifierSystem does not execute in Wolfram SystemModeler Simulation Centre
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).
UML/SysML: During modelling it can really help to create little instance (object) diagrams as you go! This can also help communicate with non-SysML stakeholders.
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).
UML/SysML: When you use an AddStructuralFeatureValueAction to set one end of a bi-directional Association it also sets the other end.
Cameo Simulation Toolkit matches the Parameters of an effect Behavior and a trigger Operation on a Transition under the hood.
Webel Twin Pattern: Once a PotentialPhysicalAsset has been integrated with a real, existing (has mass) ActualPhysicalAsset under twinning control, its job is done forever (although it may be kept as an historical tracking record).
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 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)!
WARNING: In natural language casual conversation one often hears people speaking of a digital twin "replicating" or "twinning" a physical entity. If you do it that way literally, you will NOT have anything to manage the control system loop!
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 «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!
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.
Optionally suffix the "focus" BDD for a Block with '.bdd' so that it won't clash with a corresponding IBD on diagram export. This is not a SysMLv1 concern, it is purely a workflow concern. It has the slight disadvantage that BDD may "indicated" twice.
Webel: SysMLv1: MagicDraw/Cameo: AVOID the "default" SysML Item Flow Creation Mode 'Between Part Types' completely. Use 'Direct' mode, change it as soon as you start any SysML project under Options → Project → General → SysML [Helps prevent a clash/issue]
Cameo/MagicDraw: The Classifier specification setting 'isAbstract' is (for reasons that beggar belief or engineering reason) not by default visible in the Element specification dialog. Enable expertise level 'All' (and for always everwhere).
Webel: MagicDraw/Cameo: Set EVERY element properties & symbol properties filter to 'All' (yes, not just 'Expert', to 'All', even if you are a "novice" on your first project) in EVERY dialog and every project option setting. Use the search filters!
ALL Model-Based Engineering: Just because you can't see a Feature or some other aspect of a SysML (or UML) Element in a tool on a symbol does NOT mean it does not exist in the underlying model (repository)! The model is not just what is DISPLAYED!
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.
MagicDraw/Cameo v19SP3: uses the Block compartment name 'signal receptions' instead of just 'receptions'. [CLAIMED FIXED in v2021x]
Webel: If you must name your Ports or Pins, name them simply 'i', 'o', or 'io' (or 'oi') 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.
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.
MagicDraw/Cameo: You can easily find all elements a Stereotype has been applied to using Edit > Find OR via a Generic Table Diagram with the Stereotype as the 'Element type' (with or without sub-types).
[HISTORICAL] MagicDraw/Cameo 19SP3: Does NOT yet support ~InterfaceBlock [NOW SUPPORTED in 2024x Golden] ARCHIVAL (2023): This content is now considered historical only!
Webel: SysMLv1/UML: Prefer the Name Display Mode 'both' on CallBehaviorAction symbols (rather than 'Show Action Name', 'Show Behavior Name', or 'Show Both or Behavior Name')
SysMLv1: Prefer not show Port symbols on the boundary of Block symbols in BDDs, just list them in compartments. One can't connect them in a BDD anyway. Recommend only show Port symbols in IBDs.
Nobody (informed) said that SysML (or even UML) modelling and MBSE is only about graphical modelling, notations, and diagrams! Information can be extracted in many different ways and presented in many different formats from the underlying model!
Webel: SysMLv1/UML: MagicDraw/Cameo: AVOID the the vendor-specific «useCaseModel» stereotype for Model packages, it leads to confusion with the rectangular 'subject' notation
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.
SysML: MagicDraw/Cameo: Diagram Style: Recommend DO NOT use shadows or gradient fill adornments on diagrams! [TIP OFTEN IGNORED]
Webel: SysML symbol colour styles: Recommend use black symbol borders and no symbol fill (or white symbol fill) EXCEPT for special highlighting. Recommend DO NOT use the default VENDOR-SPECIFIC line and fill colours for symbols! [TIP IS MOSTLY IGNORED]
Webel: For SysML Blocks and InterfaceBlocks used to type Ports with physical flows use 'F_UpperCamelCase' [may be combined with acronymn conventions]. The trailing part (after the underscore '_') may indicate the type that flows.
The vendor-specific Action Language Helper (ALH) API can be accessed from all of the various action scripting languages available in MagicDraw, Cameo Systems Modeler, and Cameo Simulation Toolkit
Cameo Simulation Toolkit DOES NOT leverage a Reception on a Class/Block at all! Use an AcceptEventAction with a SignalEvent trigger or an 'effect' on a Transition instead. There is a formal fUML restriction that a Reception should not have a method.
