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).
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.
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.
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's strategies for effectively introducing SysML for MBSE on your projects and the importance of extracting incremental benefit from the powerful SysML language and MBSE tools
SysMLv1: TIP: You can strengthen the ill-defined semantics of Property 'aggregation' (an AggregationKind) by applying custom Stereotypes to a Property, documented with its intended use. Not perfect, but better than not. EXAMPLE: «assembled»
SysML: Syntax ain't Semantics: FUN CHALLENGE: SysMLv1 block property aggregation: 'The tornado chaser plane "has" a chaser car "with" a chaser team.'
Webel Parsing Analysis for SysML: "Snippet trumps Requirement": A SysML Requirement element is just another model element that is elicited IN PARALLEL WITH other elements that a text description mentions in any way as being involved with or related to it.
Webel: SysML: SE: A functional analysis «whitebox» Activity may have swimlanes that Allocate to logical subsystems (logical handlers) within the 'problem' zone or to design/implementation level blocks.
Webel: SysML: SE: The custom Stereotype keyword «whitebox» applied to an Activity indicates that it is part of the functional analysis breakdown serving a «whitebox» «scenario» Activity (directly or indirectly) for a UseCase.
Webel: SysML: SE: «blackbox»: The custom Stereotype keyword «scenario» indicates a Behavior (Interaction as Sequence Diagram or Activity) that Refines a top-level UseCase within the 'problem' zone.
The Webel recipe for pragramatic SE with SysML adopts the MagicDraw/Cameo tool friendly approach of using a SystemContext as 'subject' of top-level UseCases (although using a System as 'subject' can also be used).
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: Stereotype keyword convention: BY DEFINITION HERE «blackbox» and «whitebox» refer specifically to the 'problem' zone and NEVER the 'solution' zone (as opposed to more general uses of the terms 'black-box' and 'white-box').
Webel: SysML: SE: Naming convention: «whitebox»: A '$' prefix indicates a «logical» system, «logical» subsystem (aka conceptual subsystem) or «logical» handler Block (which is a more specific form of «logical» subsystems Block).
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.)
Webel: SysML: Use concise Package and Model naming to provide "context aware" owner paths that reflect a systems engineering strategy. Extremely so-called "human friendly" verbose Package/Model names with spaces DO NOT make the model easier to understand!
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: Recommend using Block Definition Diagrams as associative, graphical engineering "scratchpads" FOR YOU; Use Internal Block Diagrams as the main presentation diagrams for your engineering colleagues and other stakeholders!
SysML: MagicDraw/Cameo: Use query view tables, matrices, and maps, use them a lot! They help communicate well with other stakeholders. Learn how to use the Generic Table diagram type, custom relations, Simple Navigation & Metachain Navigation (expert)!
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!
SysMLv1: MagicDraw/Cameo: HOWTO show "missing" ItemFlows after using Display Related Elements to re-draw Associations and Connectors. Use the 'Show Realised Item Flows' and 'Realize All Item Flows' smart manipulators.
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).
Webel: SysMLv1: Functional analysis (isolation of white-box Activities identified via «blackbox» scenario Activities of UseCases). Recommend custom stereotype them. Candidate: «whitebox» (or a recommended SE methodology stereotype).
Webel IT's summaries of MagicGrid® for SysML/MBSE with Cameo are offered for the interest of MagicGrid users for informative and educational purposes only. They are not recommendations to use (or not use) MagicGrid, and are not officially endorsed.
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]
SysML: Cameo/MagicDraw: ItemFlow notation/indication on ObjectFlow edges in SysML Activity Diagrams is a tool-specific feature, although it was proposed and discussed (but DEFERRED) as part of the OMG SysMLv1 Revision Task Force (RTF).
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: An ItemFlow without an assigned 'itemProperty' is sometimes informally/casually referred to as an "information flow", especially when applied to an Association (because it is much like a UML InformationFlow), but formally it is a SysML ItemFlow.
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: MBSE: SysMLv1: Prefer a custom «actor» extension of a Block (such as the non-normative External) over UML-style Actor for use as parts in IBDs and on allocation swimlanes. You can also have a Trace from a block-based «actor» to a UML-style Actor.
Webel: SysML for MBSE: The frequent recommendation that each UseCase have at least one "primary" scenario is a very useful and highly recommended CONVENTION (only). But it is not actually enforced by the SysML1.7 or UML2.5.1 metamodels or specifications.
SysMLv1 (or v2): CHALLENGE EXERCISE: Simplified Parsing Analysis breakdown of 'Build an Airport' with variations
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: TIP: Try "reverse" time ordered effect-from-cause Dependencies. Because it's harder to depend on something that does not already exist!
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: 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!
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: 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!
SysML: Cameo Systems Modeler: A ValueType that does not extend Real might not always simulate correctly when used to type a constraint parameter of a ConstraintBlock (in a SysML Parametric Diagram) or to type a parameter (in a SysML Activity Diagram)!
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.)
ISSUE/GOTCHA: MagicDraw/Cameo v2022x: UML/SysML: If you "rename" an ActivityParameterNode symbol on the frame of an Activity Diagram it actually renames the underlying Parameter (only) NOT the name of the ActivityParameterNode element!
SysML/UML: MagicDraw/Cameo: The name of an ActivityParameterNode does not always stay in synch with its Parameter (and it is not always desirable that it does).
SysML/UML: MagicDraw/Cameo: Activity Diagrams: All Pins of CallBehaviorActions and CallOperationActions MUST be displayed (synchronised). All ActivityParameterNodes MUST be shown on the frame of an Activity Diagram.
Webel: SysML4Mathematica: SysML Parametric Diagrams are not well suited to modelling calculations with Blocks for MTools classes, or for modelling complex logic flow of Mathematica functions. Prefer SysML Activity Diagrams for those modelling cases.
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!
TIP: Webel: SysML/UML: On the boundary of symbols for ConstraintParameters on a ConstraintProperty (ConstraintBlock usage) symbol in Parametric Diagrams use any placement or "ordering" of ConstraintParameter symbols that works for the diagram!
TIP: Webel: SysML/UML: On the boundary of Action symbols in Activity Diagrams use any placement or "ordering" of Parameter symbols that works for the diagram. Ignore the Parameter ordering of Operation and Behavior signatures completely!
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)
SysML Parametrics: You can use custom stereotypes keywords «i» and «o» on constraint parameters to indicate their intended use (causality) as (i)nputs and (o)utputs on ConstraintBlocks
[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!
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
Webel: WISHLIST: MagicDraw/Cameo: UML/SysML: Ability to freeze the Feature lines shown on symbols under Edit Compartments so that the diagram does not "break" when new Features are added elsewhere (reduce graphical coupling)
MagicDraw SysML: [v2022xGolden,v2022xRefresh1]: ISSUE: Automatic assignment of the Type of the 'result' of a ReadStructuralFeatureAction not working with drag & drop.
The integration between Wolfram Workbench and Mathematica is partly gammy (as of latest versions 2022-08-23)
Webel: SysMLv1.x: TIP: The name and documentation of a ValueType can indicate and specify more than just the unit and quantity kind. Example: A ClockFrequency may document how the frequency is measured. Example: WeightOnEarth.
Webel: Domain Modelling in graphical SysML (and the best SysML tools) is massively, hugely, compellingly, better than in any other language (or tool). [OWL does something very useful but different.]
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!
Webel electronics modelling recipe for SysML: Diagrams can be made less verbose by using stereotype icon shape display mode, by not showing names and types on obvious Ports, by hiding context-specific values, and by omitting {net} tagged values.
MagicDraw/Cameo: Rule: Internal Block Diagram and Block structure compartment: only one symbol for a given Property may be shown.
MagicDraw/Cameo: Display option: You can choose whether to show Domain Specific Language (DSL) stereotypes: 'None', 'All', 'Only Last'
Webel: SysML: Electronics modelling: TIP: Use a custom Connector stereotype '<>' with the keyword '<>' to carry a 'net' property. (Use of punctuation in Stereotype names is not usually recommended and the keyword is not usually displayed.)
Webel Parsing Analysis: An "index" Parsing Analysis Diagram (PAD) showing a collection of Snippets may optionally (but need not always) show the /member tagged value of each Snippet.
Webel Parsing Analysis: SysML: Pseudo Semantic Triple: A «pa:triple» may be applied to a uni-directional Association between SysML Blocks and/or Actors.
Webel Parsing Analysis: SysML: Pseudo Semantic Triple: A «pa:triple» may be applied to a Dependency between SysML Blocks and/or Actors or Properties typed by them.
Webel Parsing Analysis: Pseudo Semantic Triple: When «pa:triple» is applied to a named uni-directional Association the name and a consistent direction arrow should be displayed on the Association symbol in diagrams.
Webel Parsing Analysis: Pseudo Semantic Triple: For «pa:triple» applied to a named one-to-one Dependency, the source is the subject, the name of the Dependency is the predicate, the target is the object.
Webel Parsing Analysis: Pseudo Semantic Triple: For «pa:triple» applied to a named one-to-one or one-to-many uni-directional Association, the non-navigable end Property is the subject, the name is the predicate, the navigable end Property is the object.
Webel Parsing Analysis: It does not matter whether you use a Package or a Model package. (The informal Webel convention is that Models are used for systems engineering analysis with SysML and Packages are reserved for code-related software engineering.)
Webel Parsing Analysis: The name of a Parsing Analysis Diagram (PAD) may be drawn from a focus Snippet OR may simply indicate a topic of interest to the analysis
Webel Parsing Analysis: Where too many dashed line "anchors" from Snippets to elicited members lead to clutter they may be selectively omitted from a Parsing Analysis Diagram (PAD) once each member has been collected.
Webel Parsing Analysis: While Associations may be collected as elicited members of a Snippet this can quickly lead to clutter in the /member list display. Often just collecting an end Property as member is sufficient.
Webel Parsing Analysis: While Generalizations may be collected as elicited members of a Snippet this can quickly lead to clutter in the /member list display.
Webel Parsing Analysis: An anonymous Element may be collected as a /member of a Snippet (it is not important whether collected elements list with a clear name under /member, only that they are traceably elicited).
Webel Parsing Analysis: A "focus" Parsing Analysis Diagram (PAD) for one or more Snippets SHOULD always show the /member tagged value of every Snippet.
Webel Parsing Analysis: Acronym: PAD = Parsing Analysis Diagram (may be nearly any diagram type, except those types that must be owned by an elicited model element)
Webel Parsing Analysis: As StateMachine Diagrams are always owned by an element that is not eventually under the Source Input Zone they should not be used as «pa» diagrams. Elicit States instead via the /member section of the specification dialog.
Using Model-Based Systems Engineering with ANY version of Systems Modeling Language (SysML) is better than just doing drawings in a graphics tool or presentation tool
MagicDraw/Cameo v19SP3: UML/SysML: HOWTO Set an OpaqueExpression on a Slot that seems to be stuck on a numerical value.
Webel Parsing Analysis: The symbol of a Parsing Analysis Container MUST be usable on every possible diagram type
SysMLv2: On the v2 Comment extension of the v2 AnnotatingElement as a candidate Parsing Analysis Container
The targeting of the Modelica and Simulink simulation language families by the SysML Extension for Physical Interaction and Signal Flow Simulation (SysPhS) encourages development of SysML models aligned with known practices for a wide class of problems!
SysML: Naming: You may include Block, ValueType, and Signal names in the names of Behaviors (such as Activities) as long as this does not undermine the principles of functional analysis and allocation.
SysML: Naming: Including Block, ValueType, and Signal names in the names of Behaviors (such as Activities) can sometimes undermine purist functional allocation (because it may presuppose the element of the physical solution that carries out the function).
MagicDraw SysML/Cameo: If you have a SINGLE Allocate from an Activity to a Block it will set that Block to be the Behavior::/context for that Activity.
SysML: Having a Behavior owned by a Block it is allocated to may undermine purist functional allocation (because it presupposes the element of the physical solution that carries out the function)
UML/SysML: In Internal Block Diagrams: If you have a Port with a name that indicates a unique role AND and if there is an ItemFlow on a Connector that implies or suggests the Type of the Port, consider hiding the Type on the Port symbol.
SysML+SysPhS: Flows: If you intend to use a Classifier to type the itemProperty of an ItemFlow on a Connector for a physical interaction you MUST use a Block (not a ValueType or Signal) so your can extend ConservedQuantityKind.
SysML: Flows: If you 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!
MagicDraw SysML/Cameo has a nice feature 'Tools > Delegate Port(s)' accessible from the context menu for splitting Connectors that cross block boundaries into multiple Connectors with "exporting" Ports.
Progressively "exporting" internal Ports of usages of Blocks to the boundary of their using Block may seem like a bit of extra work, but it means you can progressively develop with clean black box views without the Connectors crossing Block boundaries.
SysML-1.6/1.7: You can introduce a custom (user-defined) stereotype keyword «item» to indicate Properties that are to be used as "packets" for ItemFlows on Connectors. (SysMLv2 will have a formal way of treating such items/packets.)
Additional Dependency relationships between ValueTypes and their Units on some SysML diagrams on this site are for educational illustration only (you don't need them in your own SysML models).
GOTCHA: MagicDraw SysML/Cameo 19SP3: Export to Modelica: The name of a redefining Property must be exactly the same as the Property it redefines or it will not export properly!
Webel vs SysPhS-1.1: Annex A.5: Humidifier: Where ValueTypes involving litre are defined, the Unit symbol "L" is used rather than the Modelica-preferred "l" (in combination with an explicit additional unit converter).
Webel vs SysPhS-1.1: Annex A.5: Humidifier: Where custom ValueTypes are defined, Modelica-friendly Unit symbols are used. Examples: "m3" not "m^3"; "degC" not "°C"; "J/(K.L)" (full stop as multiplier) not "J/(K⋅L)"; (EXCEPT "L" for litre not "l").
Webel: SysML: DO NOT sacrifice modelling naming conventions for the mere sake of carrying organisation-specific names! Instead use tagged values of custom stereotypes as metadata to carry alternative names in parallel with systematic model element names.
SysML/SysPhS-1.1: Anonymous Property or Action names may not be an option if: You are exporting to Modelica or Simulink; You absolutely need names for generated query reports (such as generated Interface Control Documents).
MagicDraw/Cameo: If you drag a Behavior from the model browser onto the SYMBOL of a State (that does not already own the Behavior) and set it as an 'entry', 'doActivity', or 'exit' Behavior a "wrapper" Behavior owned by the State will be created.
MagicDraw SysML/Cameo 19SP3: GOTCHA: If you drag a Behavior from the model browser onto the 'entry', 'doActivity', or 'exit' field in a specification dialog of a State it WILL BECOME OWNED by the State (which "steals ownership")!
MagicDraw/Cameo: Display options: On an 'entry', 'doActivity', or 'exit' Behavior of a State you may choose to display the specification code of an OpaqueBehavior or just its name.
MagicDraw/Cameo: On dragging a Property onto another Property set it as redefining, the multiplicity of the redefining Property is set to [0..*] if the redefined (dragged) Property only has <UNSPECIFED> Multiplicity
WISHLIST: MagicDraw/Cameo: Ability to set project-wide option to NOT set the multiplicity of a redefining Property to [0..*] on using drag-n-drop when the redefined (dragged) Property has <UNSPECIFED> Multiplicity
Sample problems and example diagrams in graphical language specifications are NOT necessarily indications of how one should model on a real-world project! They often just serve to demonstrate a particular aspect of the specified language.
SysML: When using Property::defaultValue and Property::redefinedValue to carry a "shadow hierarchy" of redefinitions across an entire system hierarchy, considering using a user-defined keyword such as «configuration» or «scenario» on each redefining Block
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]
Block naming: If you find you've got similar blocks named 'Thing' and 'Thing2' then 'Thing' is probably better renamed 'Thing1'
SysPhS-1.1: Annex A.5: Humidifier: Use of UML-style direct Port conjugation not permitted since SysML-1.6, prefer ~InterfaceBlock type-based conjugation (example requires migration)
The use of an additional «port» keyword on a Port is usually redundant and causes clutter. The use of an additional «port» keyword on a basic Property is an obsolete trick. Please don't imitate it even if you see it in some specification sample diagrams!
SysPhS-1.1: Apparent use of part Property with «port» keyword (instead of standard SysML Port) leads to property path symbols appearing inside the boundary of context blocks (instead of within a Port symbol on the boundary) in IBDs and Parametric Diagrams
Webel vs SysPhS-1.1: Recommend use standard SysML Ports instead of block part property with «port» keyword
MagicDraw/SysML vs SysPhS-1.1: Can't reproduce the "shortcut" property path representation of some properties nested within Ports as shortcut symbols fully inside the diagram frame. (Might be a specification diagram style issue.)
Concerning definitions: "a connector end" vs "a connector between 2 ends" vs "connection" vs "connect" in various technologies
Modelica: Naming convention: Why does the OnePort family of electrical components have 2 Pins? Where is the "one port"?
SysPhS: MagicDraw/Cameo: In the sysphs_profile the properties for PhSVariable have multiplicity [1], so the defaults always appear explicitly (but may be overridden): isContinuous: Boolean = true, isConserved: Boolean = false, changeCycle: Real = 0
GOTCHA: MagicDraw SysML/Cameo 19SP3: Export to Modelica: 'entry', 'doActivity', or 'exit' Behaviors of a State must be directly owned (not just "wrapped") or they won't be seen on export!
MagicDraw SysML/Cameo: GOTCHA: A Constraint created and applied to a ConstraintBlock via the sidebar menu is NOT owned by the ConstraintBlock!
Webel Best Practice: SysML/SysPhS: DO NOT use overlapping Connector lines from/to one Port (can be misunderstood as "summed" flow and/or physical node/fork/junction).
UML/SysML: A Boolean "state flag" attribute corresponding to a State can be useful for indicating states in some diagram types (but must be synchronised with Transitions to States carefully).
[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!
SysML: Electronics: When modelling electronics systems you should to decide and make clear (with ItemFlow and/or Stereotypes) whether you are modelling signals (information, does not care about GND) or a physical design with voltage (needs GND)
Webel: SysML: Electronics: DO NOT represent a jack/socket as a dumb proxy. Imagine it can introduce some signal noise or other effect (such as buzz) to test it is a physical model.
SysML Parametrics: You can use custom stereotypes keywords «i» and «o» to indicate value properties that are intended to be used as (i)nputs and (o)utputs when bound to constraint parameters for SysML Parametrics
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!
SysMLv1: Associative BDDs are best used as staging diagrams for you the modeller (and SysML-fluent readers). IBDs usually make better presentations diagrams for a wider audience of general engineers and other stakeholders.
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.
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.
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.
Webel: SysMLv1: Highly recommend creating a "focus" Block Definition Diagram (BDD) for each main Block with expanded feature details and relationships to at least nearest neighbours
