IBM Engineering Rhapsody Tip #102 - Executable MBSE Profile's Functional Analysis package structure

This live recorded video (with sound) gives an overview of the SysML package structure that my Executable MBSE Profile automatically creates for doing the functional analysis part of a method based on Executable MBSE. Key aspects are that simulations are built with actor test benches, and it's the actors that are used to drive the simulation, so that all the test stimulus is visible on an auto-generated sequence diagram. Related to this is to ensure that the structure separates elements related to the system under design/test from model elements used to test it, and having a package that contains the interfaces and events separate from the blocks that use them.

Here's the transcript in case that helps:

In this video I thought you where I'm at with the executable MBSE profile. The link of which is available at www.executablembse.com. The profile itself is on GitHub. 

You put that profile into your installation and then that gives you this ExecutableMBSEProfile available in the list. So, let's just show you this. I'll just use a simple mouse trap system. 

OK, let's take a quick look at the structure created for this functional analysis scenarios package. The intent here is to have a package that can work on the functional analysis of a use case that's captured with textual actions and textual requirements. 

So, the currency here is going to be the requirements, and the way that they are created is through an activity diagram. What's going to happen is I'm going to consume that activity diagram in my functional analysis package, so the intent is that this package is owned by a different user than the user who owns the activity diagram, and it may be added by reference, so the first thing you'll notice in this scenario package is a ‘Working Copy’ package and there's a little helper here which based on dependencies that were created, is going to pull the activity diagram as a copy. 

and on that copy it make a marker here in red, just so we know that this is a copy and that means I can mess around with it. I can delete stuff, and importantly, there's a little helper here which will color the actions or the accept event actions based on me performing the processing of them. For example, converting this action into an event, “Mouse enters trap”, coming from the mouse. 

This helper will effectively color this working copy. So the original is kind of pristine and interestingly enough, by the time in which I finish processing this, I'll just throw away the diagram and I'll have traceability to these requirements, that's a fundamental part of the process here, capturing that traceability. 

Let's do this operation as well, the “trap springs capturing the mouse”. 

What you'll notice here, is that when I create events they get created on a block, so I've got this Blocks_<Name>Pkg mouse trap package. 

There's a unique name given to all these packages, so there's a root package, this is the Mouse Trap package. This may represent a system, or it may represent a feature, or it could represent in a use case. I leave that quite flexible. 

But it's got a unique name and that unique name is used to create a file on the file system which is going to be unique. 

The Blocks_<Name>Pkg package is where the blocks that I'm essentially adding operations to that represent components of the system, so it's the system of interest, the “things I am testing”, and in this case there's a single block, so it's a black box model. 

What you'll also see is this test package. 

The Test_<Name>Pkg package here was got actors and these have been stereotyped, just to make them clear, and also the helper will use this stereotype, but essentially the idea is that there's a system called the mouse trap assembly system, that is assembling my Block, which is the mouse trap with these actors, and they are connected through ports and interfaces. 

This is a bit messy this (IBD) diagram, because it's auto drawn. 

This is my system block and it's connected to these actors. This is the fundamental thing about the simulation structure. We build a system that includes the system and the other parts of that system are actors and I've also got time as an actor. 

The helper also created a sequence diagram with lifelines representing those actors and the blocks that represent the subject. The system under test, in essence, because that's what we're doing: We're trying to build test scenarios. 

So that means having created this structure, I can build this system assembly. 

Hence, you'll see that there's a component here called the Mouse Trap EXE, and it's been set up with a configuration to enable it to build an instance of that assembly with animation and, in this case, it's got webify enabled. 

And when that runs, that executable runs, it's going to talk back to the Rhapsody client, and I've got full simulation capabilities here. 

Within my test harness, i.e. the design, I've got this time generator actor called elapsed time and that enables me to control time without using timers. 

In my simulations I don't use the Rhapsody standard system timer, rather I simulate time and that enables you to freeze a simulation, or you can move it at different speeds. 

This time actor can be configured to drive a simulation, either in a continuous way or a discrete event driven way. 

The structure is fairly important and OK, so it looks a bit complex, but essentially everything that will stimulate the system is shown on the sequence diagram, including the stimulus, so the sequence is a full definition of the test cases. 

I'm not going to change anything in a simulation directly on the system blocks, rather that the stimulus always comes from an actor, and that that's important. That was important in Harmony/SE classic. It's important in this structure as well. 

And I can hook it into technologies such as test conductor to automatically run tests, build up a test suite that can repeat the injection of the stimulus as defined on a sequence diagram. 

Let’s look at the other elements of the structure. 

The working package is basically where I can copy things and hack around with them. 

The blocks package is where the blocks that represent the system of interest, or if it's a white box, where the components would go. These are where the functions which are represented by operations and the triggers, which are represented by events, are captured on, and value properties. 

I've got a separate Interfaces_<Name>Pkg package. Again, that separation of the usage from the interface is important for multi modeling, where you've got multiple models that reference other packages in other models, and then you can bring and import packages into other models, either by reference or by copy. 

So that's going to become important and important also here, is that these interfaces are captured with explicit interfaces on the ports. Again, that's to do with test conductor. 

So that's what the interfaces package is storing if you like. 

I've got my test package, I’ve got my interfaces packets, I've got my blocks package and I've got this block called system assembly. The block called <Name>_SystemAssembly is higher in the hierarchy than the design package. That is partly a usability thing. 

In my test package, for example, I've got a panel diagram here, and if you if you start to use panels when you when you go to bind things, I want to find the system assembly first, so I want it to be the first thing it finds. 

I don't bind directly to the blocks. I bind to an instance of the block running in the system assembly, so by putting that system assembly block higher, it helps with the usability here to stop you binding to the wrong elements. 

So, that's more or less the structure. 

The sequence diagrams again, I put a higher level at the scenario package level, because they're the outcome, the handoff that comes from executing and creating this functional model. 

The intent is to take the events and operations that I had and put them into a state machine. 

So I’ver got mouse enters trap and trap springs, capturing the mouse. 

Essentially, I'm integrating the behavior of the use case steps into Statechart, which captures the same behavior at the same level, but it's fully constructed and this enables me to execute this behavior in a way which is integrated with the other scenarios that may be captured on other use cases, or different scenarios in the same use case, until I've got kind of a fully constructed definition of system behavior. 

And importantly, in this behavior, I've got things like operations and events. 

Oh, I've got that error here. I need to add a default transition to say the system starts with no mouse. 

Let's build and run. 

In this definition I've got these elements, events and operations, which capture the functions of the system from its concept of operations as defined by the formal requirements handoff. 

Let me just stop and rerun that see what happened. 

Right there we are. The handoff is going to be test scenarios defined that use these operations and events and also trace to the requirements. 

So this could be test case 1, trap a mouse. This sequence diagram is in the scenario package, so I may have 20 or 30 of these, in a handoff from black box or white box. 

The functions and operations are defined on the blocks and these are all tracing to the requirements, and they’re the same requirements that were handed to me in the use case package. 

This functional model is a separate definition of the same behavior. I've done a model transformation from an activity model into a sequence diagram and statechart model, and this executes. 

So, so that’s the structure. Hopefully I'll do a few more videos in future when I get some time.