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 IT Australia recommends that course attendees keep this page open in a browser as a convenient reference and as a "navigation dashboard" for some main SysML modelling tips.

Policy Note pages and Webel Best Practice pages cross-linked to many examples

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!

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.

There is separate overview page for everything related to UseCases, scenarios, drill-down, and functional analysis (some of which include some more advanced topics):

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.

The Webel recipe for SysML modelling advocates adopting a signal-processing mindset throughout all modelling, as part of the higher principle of using systems thinking and idioms that go beyond just SysML as a language.

The following page has a BIG REFERENCE CARD on ItemFlows showing how to use them to capture communication views in various SysML diagrams:

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

Incorporate ItemFlows for exchange items as soon as possible in your modelling; use them in many diagram types, and sync them between Associations and Connectors (and in MagicDraw/Cameo also to ObjectFlows in Activity Diagrams):

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

Use Associations names to help tell a story:

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!

Query view tables, dependency maps, and matrix views are not only your very good friend, they are the very good friend of those colleagues who don't yet "speak" SysML:

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

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!

Prefer a "logical" modelling approach over ownership-centric!

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.

The Webel "focus" BDD approach is a powerful modelling strategy

This is a main topic during the Webel SysML/MBSE course and there are hundreds (or maybe thousands) of examples of "focus" BDDs throughout this site and in the Webel training slide materials and example models.

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

Style: use line width 2 or 3 on the border of the "focus" element in "focus" diagrams (such as the main Block or Class of a dedicated Block Definition Diagram or Class Diagram)

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!

If you are an attendee at the Webel SysML/MBSE course you will asked to please follow this next recommendation every single time you create a new diagram until it becomes an automatic habit:

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]

Abstract blocks are good and inheritance in SysMLv1 (which is a NOT concerned with software engineering code implementation) is NOT "evil":

Webel Best Practice: Webel: SysML: Always consider including an abstract (sometimes intermediate) base Block in your domain modelling Generalization hierarchy.

When domain modelling with SysML, Generalization, inheritance, and even multiple inheritance are not "evil" and can be used relatively freely. We are not doing code-oriented Decorator patterns - an implementation choice - we are doing domain modelling!

If you are keen to introduce and advocate for SysML for MBSE at your organisation this following recommendation can really help. Use IBDs as your primary presentation diagrams for a wider audience:

Webel Best Practice: 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!

Concise (or no) Element names are the way to go!

Dr Darren says:

Every heard me banging on over and over about "Trusting The Type" instead of using those mostly completely redundant automatically generated verbose and repetitive cluttering property names that most tools create (which can be deleted immediately)? That's because it's indeed a really very good idea to instead just "Trust The Type"!

SysML: Webel: "Trust the Type!" - Often the name of the Type of an anonymous Property or instance-level element is completely sufficient to indicate its role - unless multiple Properties of the same Type have different roles within the same owner context!

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!

Webel Best Practice: "Trust the Port or Pin Type!" - Often the name of the Type of an anonymous Port or Pin is completely sufficient to indicate its role, unless a clear indication of its direction or unique role is required.

Webel Best Practice: Prefer anonymous Actions, or if they must be named, prefer code-like 'lowerCamelCase' or completely 'lower case' (if you do absolutely insist on having spaces in action names, but please no other punctuation).

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

SysMLv1: When using model queries (such as tables) for compliance with some older systems engineering docs you may not always be able to use anonymous Property names and anonymous instance level element names. Or try the owner context or the ID!

Those 'Really long Block & Property & Package names with spaces' be gone!

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 Best Practice: 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 Best Practice: DO NOT use spaces in Property names or Class/Block names! If you want to communicate familiar names of elements within an organisation use a custom stereotype and tagged values (such as 'aka')!

Webel Best Practice: 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!

Some concise 'i/o/io' naming conventions and modelling strategies that promote a "signal processing mindset":

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 Best Practice: FlowProperty naming. Use anonymous or just 'i' for in, 'o' for out, and 'io' (or 'oi') for inout. "Trust the Type". For conjugation ~InterfaceBlock use 'o' for in, 'i' for out, and 'io' (or 'oi') for inout.

Webel Best Practice: 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

Webel Best Practice: 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

Some finer details about the SysMLv1 metamodel and its supporting subset of UML2

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

REFERENCE CARD: Property cheat-sheet for Block

REFERENCE CARD: Types of Block Properties and Block compartments

SysML Reference Property representations

uml101 - StateMachines - NOTATION REFERENCE CARD

uml101 - Activity Diagram - notation - REFERENCE CARD

REFERENCE CARD: QUDV - basic metamodel

Confused about different types of block properties?

REFERENCE CARD: Property cheat-sheet for Block

REFERENCE CARD: Types of Block Properties and Block compartments

SysML: Syntax ain't Semantics: FUN CHALLENGE: SysMLv1 block property aggregation: 'The tornado chaser plane "has" a chaser car "with" a chaser team.'

SysML "shared" Property example: two Triangles share one LineSegment edge.

SysML "shared" Property challenge as objects: two Triangles share one LineSegment edge.

So you want to know what 'shared' AggregationKind means for reference properties (which in SysMLv1 includes both AggregationKind 'shared' and 'none'). Dr Darren says:

What would you like shared aggregation to mean? Here's a "famous" example of a possible use for 'shared' (it was already well "famous" long before I saw it)

SysML "shared" Property example: two Triangles share one LineSegment edge.

SysML "shared" Property challenge as objects: two Triangles share one LineSegment edge.

Still confused about 'aggregation' kinds for block properties? Don't worry, everyone is. Custom stereotypes to the rescue!

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»

Signal, ValueType, or Block?

When dealing with flows and message-oriented systems there are many different options for representing "packets", with various pros and cons:

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.

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.

And please remember always

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.

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!"

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

Specific to the MagicDraw/Cameo/CATIA Magic tools

Webel SysML/MBSE course attendees: Please make sure you have the symbol options display level set to 'All' (not even 'Expert' is enough) then please leave it that way forever!

Dr Darren of Webel IT Australia says:

I strongly recommend that you remove/disable ALL expertise mode filters in MagicDraw/Cameo! Yes, even for complete SysML tool newbies, or you will (as night follows day and as day follows night) get unnecessarily lost and frustrated. Don't be overwhelmed by all the metamodel and spec dialog fields and symbol options, just use search, it's massively faster, easier, better.

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!

Webel: MagicDraw/Cameo: STRONGLY RECOMMEND: On EVERY project of ANY kind set the Environment Perspective to 'Full Featured' and check the Expert box, even if you are a "novice". For SysML use 'Full-Featured' not just 'System Engineer'!

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

If you are new to SysML with MagicDraw/Cameo please do visit these next two and learn how to use some tricky display options for part and reference properties on Block symbols:

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!

MagicDraw/Cameo: If you want to show a Property or Port listed both in its corresponding compartment on a Class or Block symbol and as the end of an Association in the same diagram, set the display option Show Association Ends As Attributes/Ports to 'all'

On MagicDraw/Cameo SysML style colours and minimal adornments

Dr Darren of Webel IT Australia says:

A nice clean simple style can really help your modelling and will help you to stay in your engineering modelling zone without distractions. It will also help you communicate with other stakeholders not fluent in SysML.

Webel Best Practice: Webel: MagicDraw/Cameo: First recommended display style settings and project option steps for every SysML (and UML) project. [Includes TIP: DO NOT show the Diagram Name in the optional Diagram Info adornment, show it on the Diagram frame only]

In case you've somehow fallen in love with the default MagicDraw/Cameo SysML symbol colours (which are in fact completely arbitrary and are just the left-over ones that were not already taken for the old MagicDraw UML symbols colours):

In the Webel SysML/MBSE course a typical b/w .stl starting point style file is provided, or you can adapt the OMG b/w style. And yes, since nearly everyone ignores this advice anyway, you can very easily switch between Webel's style set and the familiar (but completely arbitrary) MagicDraw/Cameo default coloured styles.

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 Best Practice: Webel: Recommend maintain a basic black-and-white style file for starting new projects. Webel course attendees have access to a basic Webel.stl file (or clone and tune the 'OMG SysML style').

TIP: SysML can be used to create clear black and white figures compliant with patent specifications.

In the Webel modelling approach for SysML a lot of the available adornments are hidden:

Webel Best Practice: In SysML diagrams, showing the context name and type in the diagram frame can lead to clutter and is not always clear to non-SysML stakeholders (although that is the style used in the specification samples)

Webel Best Practice: MagicDraw/Cameo: HOWTO turn off verbose context information in SysML-style diagram frames

Webel Best Practice: SysML: MagicDraw/Cameo: Diagram Style: Recommend DO NOT use shadows or gradient fill adornments on diagrams! [TIP OFTEN IGNORED]

Some additional recommended MagicDraw/SysML project settings

Webel Best Practice: Webel: SysMLv1/UML: MagicDraw/Cameo: AVOID the the vendor-specific «useCaseModel» stereotype for Model packages, it leads to confusion with the rectangular 'subject' notation

Webel Best Practice: 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]

Ever "lost" your ItemFlows but you know they are there somewhere?

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.

SysMLv1: MagicDraw/Cameo: If redisplay of an Association with an InformationFlow or ItemFlow creates a strange extra dashed line with «ItemFlow» keywords (separate from the Association) just remove (only) that extra dashed line from the diagram.

There are some minor display issues when using anonymous actions and part properties under usage level allocation mode (but prefer tables and matrices anyway):

Prefer anonymous Actions, or if they must be named, prefer code-like 'lowerCamelCase' or completely 'lower case' (if you do absolutely insist on having spaces in action names, but please no other punctuation).

For once you are off and running with SysML for MBSE

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

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!

Dr Darren offers some encouragement for those learning Systems Modeling Language (SysML) for Model-Based Systems Engineering (MBSE)

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.

Last but not least: Webel Parsing Analysis for SysML

The Webel Parsing Analysis recipe for SysML^® is a powerful recipe for traceable elicitation of SysML model elements from text "snippet" extracts from domain source documents. In the full 5-day workshop version of the Webel course for SysML/MBSE a very simplified form of the recipe is used in a final day workshop by attendees to kickstart some SysML modelling of a real world project. Attendees are encouraged to learn at least a bit about the Webel Parsing Analysis recipe for SysML^® prior to the course:

The Webel Parsing Analysis recipe for SysML

TRAIL: Theory and best practices for the Webel Parsing Analysis recipe for SysMLv1.6+

White Paper: The Webel Parsing Analysis recipe for SysMLv1.6 (PDF)

DEMO: Webel SysML Parsing Analysis: The Mars Society University Rover Challenge 2020 (PDF slides and simulation video)

Learn SysML for MBSE with the Webel IT Australia Live Online web seminar or On-Site course!

Please email or phone Webel IT Australia on +61 405 029 008 to arrange On-Site, Off-Site, or Live Online remote web training seminars and workshops.

Course: Model-Based Systems Engineering with the OMG's Systems Modeling Language® (v1) and the MagicDraw/Cameo (CATIA Magic™) tools for SysML

Webel IT Australia is an OMG-Accredited Training Provider for SysML!