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!

Icon class
icon_class
far fa-sticky-note
icon_class_computed
far fa-sticky-note
Note kind
Keywords
Click on the image to view it full size
But, but that SysML Diagrams doesn't show [insert pet form systems engineering principle here].

It doesn't have to! It just has to show (or teach) something useful with SysML in a SysML tool! Apart from being just plain silly, such statements overlook one of the the major principles of model-based engineering tools that distinguish between the model from and diagrams (presentation views) of that underlying model:

Consider this [expressed with outrage]:
That SysML Diagram doesn't show all the constraints! The model is ill-formed!

Or, maybe the Constraints compartment on a Symbol is just closed, because the Constraints aspect is not relevant for the audience of that Diagram!

Besides, it's not always good to show everything in a diagram, especially in educational diagrams that wish to explain one aspect, because showing "everything" can lead to visual clutter that distracts from the pedagogical purpose of that diagram.

The bigger picture is a train of thought criticising SysML Diagrams for not being things that they are not trying to be, which is about as muddy and illogical as a false syllogism and a chain of non sequiturs. The following is clearly silly:

  1. 'All fish live in the water.'
  2. 'All dolphins live in the water.'
  3. 'A dolphin is a fish.'
But, but, but that dolphin doesn't have gills! It "should" have gills!!!

Now consider this:

  1. 'I'm an experienced systems engineer.'
  2. 'I've heard it claimed that SysML can be used for Model-Based Systems Engineering (MBSE).'
  3. 'That is a SysML Diagram.'
  4. 'That SysML Diagram is Model-Based (MB) but it doesn't show any of my pet formal Systems Engineering (SE) techniques!!!'
"Therefore":
People claiming that SysML is well suited to systems engineering are clearly wrong, that SysML Diagram is missing stuff that's needed for real systems engineering! Whoever made that SysML Diagram is clearly not a real engineer.

Silly, isn't it. So is this:

Asimov's short story ". . . That Thou Art Mindful of Him" doesn't cover all of the comprehensive topics of Tolstoy's great literary novel 'War and Peace'. Asimov's short story is clearly missing stuff, he's clearly not a great writer!"

SysML is a set of building blocks and can be used for many things. For those of you who are interested in using the Model-Based and Single Source of Truth aspects of SysML initially more than its systems engineering capabilities - and if you aren't designing a nuclear submarine from scratch - may I suggest that you politely ignore those who might criticise your SysML Diagrams (or your model) for what it is supposedly "missing" as far as formal systems engineering purists are concerned, and simply focus on what you can do of value with your SysML tool.

Now did I say that formal systems engineering has no value? No.

And is every SysML Diagram is there with the higher purpose of advocating for the suitability of SysML for MBSE? No.

I can gold guarantee you that unless you already have some real experience with formal systems engineering, if you try to incorporate it all straight up before you've mastered the SysML language as a set of building blocks and your SysML tool features you'll likely stumble, and if you instead focus on mastering the SysML language and your SysML tool and its features first, you'll actually be able to progressively incorporate formal systems engineering aspects faster once you are ready for it. 'The Tortoise and the Hare'!

Above all, don't let someone else try to make you feel like an inferior engineer (or even bully you) just because you don't include every aspect of their pet formal systems engineering framework in your SysML work. Maybe you are really good at electrical design; maybe you like requirements engineering; maybe you have a knack at network design or with signals. Then by all means do use your SysML tool to get incremental benefit tackling those aspects first, perhaps initially in isolation, and perhaps first only with selected Model-Based aspects that benefit from Single Source Of Truth.

And if anyone tells you that's wrong, tell them Dr Darren said it's ok. I'll take the heat for you. Because I'm here to help people get benefit from the SysML language and SysML tools, however it may be used to benefit their engineering projects.

And I'm flame 🔥 proof

Dr Darren, Webel IT Australia
Relates to
Related notes
Related notes (backlinks)
Related snippets (extracts)
Visit also
Visit also (backlinks)