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)

Experienced professional Systems Engineers who use fully-fledged formal systems engineering frameworks may safely ignore this page or read it for fun and just say "Of course!"

Dr Darren says:

I know, I know, you are a practical hands-on engineer using SysML for MBSE, not a high fallutin' systems engineer, and you just want to get into your design and you don't want to deal with all that formal functional analysis drill-down stuff the systems engineers keep banging on about and those darn "extra" logical subsystem Blocks they always show, which look like extra work (but really isn't).

This shows you how to "cheat" whilst still tracking it with custom stereotypes, and exactly why you might as well indeed do that "extra" SE stuff with an intermediate logical subsystem (aka logical subsystem or conceptual subsystem) Block (which also has lots of different names).

You are drilling down from an Activity usage from a scenario Activity (that serves a UseCase, details of which are deliberately not shown). So you are entering the «whitebox» zone (by definition here for this example). The scenario is complex enough that you can't cleanly jump to your design blocks yet, you need to flesh it out a bit still with some logical analysis.

You know that the Activity Process is not so simple, and it will involve an Unpack and some other stuff, and you know that Unpack will involve some Blocks from the actual design level.

But (for some reason) you just don't want that darn "extra" SE advocated logical Block, and you don't drink beers with high fallutin' systems engineers or care what they think, you hang out with your really hands-on engineering buddies who just make stuff (and are good at it). Design is your everything.

So you CHEAT: At least mark your drill-down level Activity Unpack with a custom stereotype «whitebox:logical». That way you know it "stands for" that logical Block you missed, and you at least have some tracking. And your Activity Diagram for the Process (that uses Unpack) does not have any swimlanes, because you have nothing to allocate to at this level.

Now you jump down from your «whitebox:logical» Activity (the placeholder "tracker" for that darn "extra" logical SE Block you reckon you don't want) into an Activity Diagram.

But now you don't have any parts corresponding to the Blocks from your actual design to allocate to!

No problem you say:

"I can at least allocate to my familiar design level Blocks at Classifier level. And from thereafter I'll have parts anyway."

Just one problem:

Now you can't show Connectors in an IBD between parts corresponding to the design level Blocks and you can't show ItemFlows on them because you don't have any parts or a context for them.

No problem you say:

"Well at least I can have ItemFlows on Associations between those design level blocks."

Even if you do that (which is not a bad idea to do anyway) you might as well indeed use an IBD with a that "extra" logical subsystem Block (aka conceptual subsystem) you reckon you don't want.

And another problem:

In MagicDraw/Cameo you now can't use the nice Item Flow Manager to sync your ItemFlows with ObjectFlows.

You might as indeed well use that darn extra "SE" logical subsystem Block!

And if you really, really just don't want to, at least track it as shown. At least then you can "upgrade" to the the more formal SE approach with that "extra" Block later.