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: 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: 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: A Parsing Analysis Container MAY collect any other Element type as a member EXCEPT for another Parsing Analysis Container
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: On export to Modelica sometimes repeats parts of an equation into an extending model.
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.
MagicDraw/Cameo v19SP3: SysPhS: If you have a custom ValueType it MUST extend Real either directly or indirectly or it will not be seen on export to Modelica.
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-1.6: p.43: 8.3.1.2.1 Property types 'Four general categories of properties of blocks are recognized in SysML ...' does not cover FlowProperty
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).
MagicDraw SysML/Cameo: For export of more complex physical interaction and flow cases to Modelica or Simulink/Simscape/Stateflow load the SysPhS ModelLibrary using SysPhSLibrary.mdzip as a shared project.
MagicDraw SysML/Cameo: You do not always need to load the entire SysPhS ModelLibrary for simpler black box exports to Modelica or Simulink/Simscape/Stateflow (sometimes the sysphs_profile within the MD Customization for SysML is enough)
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!
Cameo Simulation Toolkit: GOTCHA: In the Variable pane reference properties are hidden by default (show them using the Options pulldown menu)
SysML-1.6: Figure 8-17: Redefined properties in Vehicle Model 1 and Vehicle Model 2 break constraint: 'BoundReferences shall not be applied to properties that are related by redefinition to other properties with BoundReference applied'
[HISTORICAL] 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 ARCHIVAL (2022): This content is now considered historical only!
UML/SysML: When sending a Signal (message) via a Port the 'target' is the owner of the Port through which the message will be sent, it is NOT the final recipient! So the 'target' is essentially the "sender"!
One of the most important reasons to use a Port to send a Signal is that only the connection context, not the sender, knows the ultimate recipient (at the end of a specific Connector).
MagicDraw/Cameo: A structured ValueType can have value properties (each typed by a ValueType), but they list in an 'attributes' compartment (not a 'values' compartment)
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.
One limit of the SysML-1.6 ElementGroup for use as a Snippet in the v1.x version of Webel Parsing Analysis for SysML is that an ElementGroup is not directly relatable.
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!
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).
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.
SysML-1.6: The provided/required Interfaces indicated in the spec version of D.19 for 'connector c1 in Figure D.19.' are not defined on the corresponding Block in Figure D.20 (known issue)
In a SysML Activity Diagram a control flow may be notated with a dashed line and stick arrowhead; this helps distinguish a ControlFlow from an ObjectFlow symbol.
Webel: A plain Dependency that is not stereotyped is always strictly timed-ordered; the supplier (target) must exist before the client (source).
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: In a BDD the diagram sidebar menu item for Enumeration is a UML Enumeration with ValueType applied (so properties typed by it will list as value properties in the 'values' compartment on a Block).
The SysML Complex "primitive" ValueType does in fact have substructure: realPart:Real and imaginaryPart:Real
QUDV in SysML refers to: Quantity, Unit, Dimension, Value. It is strongly influenced by the International Vocabulary of Metrology (VIM).
MagicDraw/Cameo v19SP3: uses the Block compartment name 'signal receptions' instead of just 'receptions'. [CLAIMED FIXED in v2021x]
MagicDraw/Cameo 19SP3: Stakeholder: Has 'concern' NOT derived and /concernList derived; SysML-1.6 has /concern derived and concernList NOT derived.
SysML-1.6: The constraint that ''An Action appearing in an “AllocateActivityPartition” shall be the /client (from) end of an “allocate” dependency.' is not compatible with all Activity Diagram swimlane configurations.
The SysML non-normative extended requirements are NOT offered as the ultimate set of requirements categories or requirements fields, but they are highly usable and can be easily adapted.
Webel has suggested primary/replica as an alternative to master/slave terminology for the SysML Copy relationship in future SysML versions
Webel has suggested that SysMLv2 should support verification of each individual claim of more than one Element helping to Satisfy a Requirement.
In SysML more than one NamedElement can help Satisfy a single Requirement (which presents challenges for verifying satisfaction of Requirements). This is a conceptual challenge for requirements engineering in general, not just SysML!
In UML and SysML a '/' forward slash prefix before a Property name indicates that it is derived from other elements in the model.
SysML-1.6: Refers to both 'composite requirements' and 'compound requirements' (clearly as identical concepts)
A FlowProperty need not have 'composite' AggregationKind, it can be 'shared' or 'none'. (The MagicDraw/Cameo default is 'none').
MagicDraw/Cameo 19SP3: Validation of required and provided Interfaces proxied between a ProxyPort and a part with a compatible contract fails
SysML directional FlowProperty contracts for ProxyPorts SHOULD be satisfiable Property-wise (including as subsets of Properties) not necessarily just at the level of entire Blocks!
SysML-1.6: InterfaceBlock: OCL in constraint 2_no_part is missing FlowProperty check (for FlowProperty of a valid type other than ValueType).
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.
A SysML Enumeration is a UML Enumeration with ValueType applied (so properties typed by it will list as value properties in the 'values' compartment on a Block)
In SysML the NOW DEPRECATED (since SysML-1.6) direct UML Port conjugation does not work consistently with SysML DirectedFeature and SysML FlowProperty on nested ports!
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).
Until tool support for ~InterfaceBlock comes you have to make a decision: (1) Bake your own «~InterfaceBlock» then deal with clashes when tool support comes; (2) stick with the DEPRECATED UML conjugation (not nested-port friendly) and await migration.
Although the older SysML FlowPort is strictly deprecated, the term "ports with flows" is often used for a Port typed by a block with a FlowProperty. The expression "flow port" is best avoided to prevent confusion.
In general, the SysML DirectedFeature approach is more powerful and the notation is cleaner than UML provided/required Interfaces. Prefer SysML DirectedFeatures unless you have a really good reason to use Interfaces!
[HISTORICAL] MagicDraw/Cameo 19SP3: Does NOT yet support ~InterfaceBlock [NOW SUPPORTED in 2024x Golden] ARCHIVAL (2023): This content is now considered historical only!
The mechanism for conjugated Ports has been changed in SysML 1.6, it now conjugates the Type! If you are using an InterfaceBlock to type a Port you can conjugate that 'original' on another Port by typing it with an ~InterfaceBlock.
SysML-1.6: Needs a constraint on ~InterfaceBlock making the implied inversion of provided/required Interfaces explicit
MagicDraw/Cameo: To callout the element properties of Diagram's context Element into a Note in that Diagram use the context menu item Represent Diagram Context on the Note!
SysML-1.6: double-callout into one Note from 2 part Property symbols in 'Figure 16.4: Requirement satisfaction in an internal block diagram' is not tool friendly
SysML-1.6: in 'Figure 16-3: Links between requirements and design' on block BrakeSystem the part 'r:BrakeLine' should probably be 'r:RearBrake'
SysML-1.6: 'Figure 16-2: Requirements Derivation' indeed shows DeriveReqt but spec text refers to it only as 'an example of a compound requirement'
SysML-1.6: text on Requirement 'Test and procedure conditions' is mangled in 'Figure 16-2: Requirements Derivation' (was OK in SysML-1.5) [and also on Figure 16-6]
SysML-1.6: Consistency: either show the [metaclass] on all Stereotype symbols in profile diagrams or on none
SysML-1.6: In 'Figure 15-7: Example of flow allocation from ObjectNode to FlowProperty' there are allocations from an Actions (usage level) to Blocks (definition level)
SysML-1.6: In 'Figure 15-7: Example of flow allocation from ObjectNode to FlowProperty' it does not make sense naming the BDD 'Block0' if that Block is not shown in the diagram
SysML-1.6: The 'Figure 15-7: Example of flow allocation from ObjectNode to FlowProperty' does not show the allocatedFrom for 'action2' on Block7
SysML-1.6: The 'Figure 15-7: Example of flow allocation from ObjectNode to FlowProperty' does not allocate to any FlowProperty
SysML-1.6: Figure 15-5 does not show 'flow allocation of ObjectFlow .. alternatively to an ItemFlow', Figure 15-6 does.
SysML-1.6: text concerning Figure 15-4 says 'allocation of Actions to Parts are depicted in Figure 15-4' then has an allocation from a part to Activity6.
SysML-1.6: text concerning Figure 15-4 'The allocation to Activity6'; the allocation is FROM Activity6.
SysML-1.6 Typo: There is no "hybridSUV" Lifeline in Figure D.9 - there is 'vehicleInContext:HybridSUV'
SysML-1.6: An additional ControlFlow is required into the DecisionNode of 'Figure 11-12: Continuous system example 3' and the existing ObjectFlow with Brake Pressure must become a decisionInputFlow
SysML-1.6: Edge for [else] in 'Figure 11-11: Continuous system example 2' should be an ObjectFlow not a ControlFlow
MagicDraw/Cameo: Uses the lowerCase keyword «valueType», the SysML spec has «ValueType» in some sample figures
SysML-1.6: reference to 'association between Spigot and Faucet Inlet in Figure 9-11' should say 'Figure 9-8'
Webel vs SysML-1.6: There is no «port» stereotype keyword for Port or Property in UML-2.5.1 or SysML-1.6, it is introduced as a custom (user-defined) stereotype keyword here only to mimic the spec Figure 9-8.
SysML-1.6: does not leverage redefinition of 'sp:Surface' on 'Figure 9-7: Usage example of proxy and full ports' (earlier versions of the spec did). And does not show direction of flows.
SysML-1.6: 'Figure 9-6: Usage example of ports with provided and required features' does not expose any directed features. It would be more instructive if the ports on the diagram used the capability to show the underlying directed features of the blocks
SysML-1.6: Figure 8-17: EndPathMultiplicity is applied to 'rollBarBR' instead of 'lugBoltBR' of 'Vehicle Model 2'
SysML-1.6: Figure 8-17: Multiplicity of 'rollBarBR' in 'Vehicle Model 1' should be [1] not [*] and it has no redefined type for the 'light roll bar'
SysML-1.6: Use of ValueTypes named like units in Figure 8-12 and Figure 8-14 is inconsistent w.r.t. some other specification diagrams and examples (but not necessarily wrong)
UML4SysML is a specification abstraction (concept) only, it does not find direct expression (such as via a namespace) in tools like MagicDraw/Cameo
SysML-1.6: Spec Figure D.41 refers to 'em:ElectricalMotor' inconsistent w.r.t. 'emg:ElectricalMotorGenerator' in D.18 and allocation tables.
SysML-1.6: Spec Figure D.41 refers to 't:Transmission' not 'trsm:Transmission', inconsistent w.r.t. D.18 and allocation tables (with impact on some connector names).
Some Connectors 'b-l' and 'i-l' shown in Figure D.17 are missing in spec Figure D.41, and some 'c-p' and 'bk-p' are named inconsistently w.r.t 'p-c' and 'p-bk' in D.17
SysML-1.6: Spec Figure D.41 refers to 'i:Interior' not 'i:InteriorSubsystem', inconsistent w.r.t. Figure D.16.
The SysML block compartment name 'initialValues' for what are really "context-specific values" is confusing - even completely misleading; please just think of them as 'contextValues' (and initial values as a special context case)
SysML-1.6: The allocation from ObjectNode 'driveCurrent' in Figure D.38 to itemFlow 'i1' on the Connector in Figure D.39 does not appear in the allocation table Figure D.40; Instead there is an allocation from an ObjectFlow 'o6' to the Connector 'epc-emg'
In the Webel trail versions of the SysML-1.6 spec sample Figure D.38, the alignment of ObjectNode symbols over the ActivityParameterNode boundaries is completely contrived, please DO NOT mimic it; please use explicit Pins instead!
SysML-1.6: Each «continuous» Parameter (of each corresponding ActivityParameterNode) in Figure D.36 and Figure D.38 should be set to be streaming, because the Continuous Stereotype has a Generalization to Rate
SysML-1.6: The spec version of Figure D.37 does not show the breakdown from the top-level Accelerate activity
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')
SysML-1.6: Figure D.31 has constraint parameter 'vc' on ':CapacityEquation', which is inconsistent w.r.t. parameters 'V1', 'V2', 'V3' and constraint {pcap=Sum(Vi)) shown in Figure D.26.
SysML-1.6: The spec sample diagrams D.27 has Expose relationships to ValueType, they should be to value properties.
SysML-1.6: The View and Viewpoint spec sample diagrams D.27, D.28, D.29 and D.30 have multiple known issues; the trail versions here on this site are only placeholders until new spec versions are available once SysML-1.7 is released.
SysML-1.6: Figure D.25 has the type Fuel for both an in Port and an out Port on FuelTankAssembly (and it is not ideal to have same name as the Classifier that flows)
SysML-1.6: Need a Connector from fuel:Fuel to :FuelPump in 'Figure D.25 Detailed Internal Structure of Fuel Delivery Subsystem (Internal Block Diagram)'
SysML-1.6: Naming inconsistencies 'Figure D.24 is a parametric diagram showing how fuel flowrate is related to FuelDemand and FuelPressure value properties.'
SysML-1.6: Figure D.24 does not explicitly show «equal» keyword or '=' on BindingConnectors [suggest this might be good to show this notation on at least one HSUV sample diagram]
SysML-1.6: The provided features are in fact not indicated on the spec version of Figure D.20 (this was addressed by OMG JIRA SYSML17-224 'Features that are not denoted as a DirectedFeature are implicitly provided features'')
SysML-1.6: Figure D.19: It's not clear why 'Port:~FuelTankFitting' (an ~InterfaceBlock conjugation port) does not match 'Port:ICEFuelFitting'
SysMLv1.6 Provided/required DirectedFeature contracts for ProxyPorts SHOULD be satisfiable Feature-wise (including as subsets of Features) not necessarily just at the level of entire Blocks (types)! [See also the SysMLv1.7 spec changes.] ARCHIVAL (2022): This content is now considered historical only!
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.
SysML directed features displayed on Port symbols are often far clearer than UML-style provided/required Interface "ball (lollipop) and socket" notation
SysML: Typing a Port by an InterfaceBlock or ~InterfaceBlock does NOT imply that the Port is a ProxyPort (but ProxyPort must be typed by an InterfaceBlock or ~InterfaceBlock)
SysML-1.6: Figure D.19 Internal Structure of the Power Subsystem (Internal Block Diagram): Connector 'acl-ecu' and 'bkp-ecu' should be 'acl-pcu' and 'bkp-pcu'
SysML-1.6: For the Connectors in Figure D.4 to be typed by the implied anonymous Associations need define them in Figure D.15 (or elsewhere) between 'HybridSUV' and: 'Driver', 'Maintainer', 'Passenger', 'Baggage', 'Environment'.
SysML-1.6: Figure D.3: Would 'HSUV Interfaces' be better higher up directly under 'HSUV Model' (instead of under 'HSUV Structure')?
ERROR: SysML-1.6: The name 'Operational Viewpoint' in Figure D.3 contradicts the name ''Functional Viewpoint' in Figure D.30 (suggest amend D.30 not D.3)
ERROR: SysML-1.6: Figure D.2: the original spec figure appears to show Real owned by the ModelLibrary 'Automotive Value Types' without an explicit element import.
ERROR: SysML-1.6: Figure D.3 Automotive Value Types model library does not belong under the HSUV Model, showing it on this diagram without showing the owner suggests it is. Compare with Figure D.2.
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!
SysML: The «system», «subsystem», «external», «domain» and «system context» keywords are for "user defined" block Stereotypes (they are not part of core SysML); they are supported in MagicDraw/Cameo as Non-Normative Extensions.
The SysML specification refers to 'part property' as a concept (as a type of block property) but there is no stereotype PartProperty; MagicDraw/Cameo as an additional stereotype PartProperty to encapsulate the concept
SysML-1.6: In Figure D.9 is a synchronous Message from Lifeline for :Driver for an Operation StartVehicle() intended? Does it make sense for the human Driver to have to wait for such a synchronous call?
Webel: SysMLv1/UML: MagicDraw/Cameo: AVOID the the vendor-specific «useCaseModel» stereotype for Model packages, it leads to confusion with the rectangular 'subject' notation
The Webel versions of the SysML HSUV sample problems and specification sample figures use "standard" Ports EXCEPT where ProxyPorts or FullPorts are explicitly indicated in the specification
SysML: MagicDraw/Cameo: DO NOT use the FlowPort or FlowSpecification menu items or smart manipulator items they are completely OBSOLETE (they create fully DEPRECATED SysML model element types)! Use FlowProperty on Block features instead.
HOWTO get at and display "standard" Ports that have been unnecessarily hidden and suppressed in MD SysML 19SP3 and Cameo 19SP3
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.
Since SysML-1.6 use of direct UML conjugation of Ports is NOT supported; If you are using InterfaceBlocks use instead a conjugated ~InterfaceBlock type!
[HISTORICAL] HOWTO easily "hack" the SysML-1.6 ~InterfaceBlock conjugation and «~interfaceBlock» keywords in MagicDraw/Cameo. [NOW SUPPORTED 2024x Golden] ARCHIVAL (2022): This content is now considered historical only!
SysML-1.6: HSUV sample problem and spec sample diagrams naming issue, 'ecu:PowerControlUnit' should be 'pcu:PowerControlUnit'
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.
