SysMLv1

SysMLv1: Cameo Simulation Toolkit: Cases for StateMachine Transitions with 'effect' Behaviors and/or States with 'entry' Behaviors triggered by a Signal with an attribute [with mini video]

Gallery

Tutorial

TRAIL: SysMLv1/UML: Cameo Simulation Toolkit® (Magic Model Analyst®): Some basics for beginners and some more advanced cases [with mini videos]

Section

Slide kind

SysML Activity Diagram

SysML Block Definition Diagram (BDD)

SysML StateMachine Diagram

SysMLv1: Cameo Simulation Toolkit: Cases for Transitions triggered by Signals sent direct to a remote target vs via Ports [with mini video]

This content has been marked as discussing an ADVANCED topic!

Gallery

Tutorial

TRAIL: SysMLv1/UML: Cameo Simulation Toolkit® (Magic Model Analyst®): Some basics for beginners and some more advanced cases [with mini videos]

Section

Slide kind

SysML Activity Diagram

SysML Block Definition Diagram (BDD)

SysML StateMachine Diagram

SysMLv1: Cameo Simulation Toolkit: HOWTO handle sending and receiving families of related Signal types with reuse of send/receive and processing logic [with mini video]

This content has been marked as discussing an ADVANCED topic!

Gallery

Tutorial

TRAIL: SysMLv1/UML: Cameo Simulation Toolkit® (Magic Model Analyst®): Some basics for beginners and some more advanced cases [with mini videos]

Section

Slide kind

SysML Activity Diagram

SysML Block Definition Diagram (BDD)

SysMLv1: Cameo Simulation Toolkit: HOWTO send a Signal via a Port to an intended recipient via a mediating secure RoutingHub [with mini video]

Gallery

Tutorial

TRAIL: SysMLv1/UML: Cameo Simulation Toolkit® (Magic Model Analyst®): Some basics for beginners and some more advanced cases [with mini videos]

Section

Slide kind

SysML Activity Diagram

SysML Block Definition Diagram (BDD)

SysML Internal Block Diagram (IBD)

SysMLv1: Cameo Simulation Toolkit: HOW send to an intended recipient via a shared Port? ATTEMPT: Using multiple Connectors to every candidate recipient without a mediating hub [with mini video]

Gallery

Tutorial

TRAIL: SysMLv1/UML: Cameo Simulation Toolkit® (Magic Model Analyst®): Some basics for beginners and some more advanced cases [with mini videos]

Section

Slide kind

SysML Activity Diagram

SysML Block Definition Diagram (BDD)

SysML Internal Block Diagram (IBD)

SysMLv1: Cameo Simulation Toolkit: HOWTO: Send a Signal via a nested Port using InvocationOnNestedPortAction and 'onNestedPort' together with 'onPort' [with mini video]

Gallery

Tutorial

TRAIL: SysMLv1/UML: Cameo Simulation Toolkit® (Magic Model Analyst®): Some basics for beginners and some more advanced cases [with mini videos]

Section

Slide kind

SysML Activity Diagram

SysML Block Definition Diagram (BDD)

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

TIP: SysMLv1: Cameo Simulation Toolkit®: HOWTO handle receiving multiple Signal events in parallel within a repeated loop [with mini video]

Gallery

Tutorial

TRAIL: SysMLv1/UML: Cameo Simulation Toolkit® (Magic Model Analyst®): Some basics for beginners and some more advanced cases [with mini videos]

Section

Slide kind

SysML Activity Diagram

SysML Block Definition Diagram (BDD)

SysML StateMachine Diagram

ISSUE: Cameo Simulation Toolkit: v2024x: Does not show argument Pins corresponding to inherited attributes of Signal on SendSignalAction or un-marshalling AcceptEventAction. No known UML2.5.1 or fUML-1.4 constraint; no obvious tool display option.

[EXTERNAL LINKS] Cameo Simulation Toolkit (aka Magic Model Analyst) videos and guides

Keywords

Keywords

A collection of EXTERNAL links (scroll down) to videos, slides, and other guides on Magic Model Analyst^® (Cameo Simulation Toolkit^®). These links are included here as additional resources and do not replace the Webel IT Australia online SysML/MBSE educational resources or the Webel training course materials:

SysMLv1: A basic ControlFlow, ObjectFlow, and DecisionNode loop driven by fUML ReadLine CLI String input with conversion to Boolean for LiteralBoolean guard [with mini video]

Gallery

Tutorial

TRAIL: SysMLv1/UML: Cameo Simulation Toolkit® (Magic Model Analyst®): Some basics for beginners and some more advanced cases [with mini videos]

Section

Slide kind

SysML Activity Diagram

UML Activity Diagram

SysMLv1: A basic ControlFlow, ObjectFlow, and DecisionNode loop driven by fUML ReadLine CLI String input [with mini video]

Gallery

Tutorial

TRAIL: SysMLv1/UML: Cameo Simulation Toolkit® (Magic Model Analyst®): Some basics for beginners and some more advanced cases [with mini videos]

Section

Slide kind

SysML Activity Diagram

UML Activity Diagram

SysMLv1: A basic ControlFlow and DecisionNode loop with implied variable popup dialog [with mini video]

Gallery

Tutorial

TRAIL: SysMLv1/UML: Cameo Simulation Toolkit® (Magic Model Analyst®): Some basics for beginners and some more advanced cases [with mini videos]

Section

Slide kind

SysML Activity Diagram

UML Activity Diagram

TRAIL: SysMLv1/UML: Cameo Simulation Toolkit® (Magic Model Analyst®): Some basics for beginners and some more advanced cases [with mini videos]

Jump to first slide

SysMLv1: A basic ControlFlow and DecisionNode loop with implied variable popup dialog [with mini video]

Sections

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.

[STUB] SysMLv1: MagicDraw/Cameo: SPECIFIC CASES of Structured Expressions, Derived Properties, Custom Scripts, and Metachain Navigation for table columns

Sections

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.

An Open Letter to LinkedIn SysML/MBSE groups from Dr Darren: "But, but, but, that SysML Diagrams doesn't show [insert pet systems engineering principle here]". It doesn't have to! It just has to show (or teach) something useful with SysML in a SysML tool!

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: 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: 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, message, 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]

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

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.

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.

Using SysML ItemFlow on an Association to show compatibility with a physical flow

Gallery

Tutorial

TRAIL: Webel's ultimate guide to Systems Modeling Language (v1) with MagicDraw/Cameo

Section

09:01: Indicating flow on Associations and Connectors

Slide kind

SysML Block Definition Diagram (BDD)

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.

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

Subscribe to SysMLv1