Tuesday 25 August 2020

IBM Rational Rhapsody Tip #82 - Modelling Domain Specific Language (DSL) & Profiles (Advanced)

This is one of my more involved and narrated videos. It covers the topic of domain specific profiling with IBM Rational Rhapsody. In it, I give a glimpse of an example profile for automotive model-based systems engineering, showing how it's possible to add new term element types and diagrams to make SysML/UML more easily consumable when following a chosen method. Domain specific profiling in Rhapsody is controlled via properties on stereotypes. At the end I also show one of the more advanced techniques I've moved to is to build and maintain such a profile using model-based techniques, i.e., drawing a class model of the domain specific meta-model that represents the element types (also known as meta-modeling! ;-).

Here's the transcipt:

In this video I thought I’d give a short insight into what a domain specific profile is. Some of the benefits… and how I go about this in Rhapsody now, based on my experience.

Firstly, a profile is type of package that extends the UML language. Profiles contain stereotypes to represent new concepts and meanings. Profiles can also add tags and, in the case of Rhapsody can convey properties that change the user interface.

SysML, for example, is a profile that extends UML, and it contains a stereotype called a Block. Whilst a block in SysML is a general-purpose element for architectural specification, within any given model there likely to be different types of blocks. We could further classify or replace the idea of a Block using stereotypes of our own. 

For example, here I have the prototype for a profile I’m dubbing as my 'Autobahn Profile' as it’s designed to speed up the journey into productive model-based systems engineering, and builds on my automotive sector experience. In this profile some Blocks may represent systems while others may represent subsystems or functionality performed by subsystems.

Having created these stereotypes I can use them in the browser. Let’s create a logical system package with a logical system element inside it. Here the browser is representing these new term stereotyped elements as part of the tools’ modeling language, including given them their own categories and icons in the browser.

Stereotypes are a bit like fancy dress. We can stereotype base UML elements to give them new meaning.

With Rhapsody, unlike some of its competitors such as Cameo, the extension mechanism for writing a domain specific profile does not require you to write any code. It is based instead on static values set in profile and stereotype properties. The use of New terms like this Logical System stereotype I’ve added here, can be conveyed by the profile in such a way that they change the Rhapsody menus.

New term stereotypes can also be applied to diagrams. Here’s a stereotype I’ve used to create my own Architecture Definition Diagram type. The drawing toolbar for the diagram has be customised using properties on the stereotype. This enables me to add new classifications of element types to the drawing toolbar, but also subset default element types so that users are not burdened with unnecessary choices. 

Let me quickly change this diagram back to the standard Object Model Diagram type. Here you can see if has options such as Objects, Classes, Associations, and Links. By applying the new term stereotype, I can specialise and simplify the available palette of tools. I’ve essentially created my own domain specific Block Definition Diagram type, albeit that I’ve further classifiers such as logical systems, logical subsystems and subsystem functions.

This makes it clearer and simpler for a non-SysML expert to draw a necessary structure, as they can work closely with more familiar terms.

A system comprises of subsystems, and subsystems own subsystem functions. By using this domain specific profile, I’ve made a choice about how to adapt the generic SysML language up front rather than leaving it to end users. This reduces the burden placed on end users to choose how to represent their concepts.

Using properties on the elements, I have also applied some more direct constraints. For example, subsystem functions can be used by subsystems and by not systems.

This makes it possible to achieve a more consistent outcome with less training. Such customisation's become valuable at scale when you start to deploy MBSE in a mass- user environment where black belt SysML experts are not 10 to a penny, rather everyone has a job to do and a limited time to do it.

In building a number of these profiles for different clients, one of techniques I’ve centred on is the use of different package types to simplify menus to role-based work. Here, for example,  you can see that there are a number of different package types I’ve made available on the right-click menu for the project.

For example, I quite like the idea of a use case package, where the right-click menus are simplified for just elements needed for use case analysis. As I want use case analysis to be  by a domain specialist, I’ve removed SysML types they don’t need like Blocks, Parts, and Ports. In this instance I haven’t actually added any new concepts. I’ve just simplified the menu so that the users working on these packages can focus on the job at hand.

I quite like this idea of sub-setting packages in this way. I also like the flatter, ordered structure that new term package types can give, so users do not have to drill too deep to find the area of the model they’re working on.

That’s just a very short introduction into what domain specific profiling is and some of the benefits such as easing adoption by domain specialists, improving the consistency of models, and simplifying training by removing the need for all end users to learn the full breadth of the UML and SysML languages.

I wanted to finish off by just giving you a glimpse of how I now approach building profiles like these for customers. As you can see here, the profile is specified using properties which formulate how the menu should be structured and what the context menu of an element should allow.

For small profiles these can be doctored by hand. What I found through experience is that manually keeping all these properties in synch becomes exponentially harder as you progressively add new terms, especially as names of things often change during the forging of a profile.

To solve this issue, I’ve created a meta-modeling profile and plugin to apply a model-based approach to building up the profile properties. This enables me to draw the relationships I want between meta-types and get the code to automatically update the corresponding property values. This makes it much more fun. For example adding a composition relation will allow a nesting in the browser and using an aggregation relation will add the element type to the drawing toolbar.

To illustrate this, let’s look at an example. Firstly, I’m going to add some new icons to the profile’s Rhapsody project. These will be used to represent a new type of package called an Actor Package. Actor Packages will perform the role of housing Actors shared by other packages, and will have their own icons to distinguish them in the browser.

I’ll now add a stereotype to represent the Actor Package type. I’ll make this a New Term stereotype applicable to the base UML Package type. Checking the New Term box tells Rhapsody that it needs add Actor Packages as a category in the browser, and also means that some properties applied to the stereotype will come into play.

Let’s use these properties to specify a new icon for Actor Package elements in the browser. I’ll also set this separate property that specifies which icon to use when displaying a category grouping elements of this type.

In general it’s better for stereotypes to not have spaces in their name as it makes managing the properties for them easier, so I’ve not used spaces in the browser, and will give the Actor Package a human readable name via its property instead. 

I’ll also give it a category name for use in the Rhapsody browser. Using a number here is a trick that I use particular for new term packages, as it acts to order to the package types in the root of the Rhapsody browser, making them easy to find. This will become more obvious in a minute.

I’m now going to switch to the metamodel that I’m using to maintain the menu related properties. This is declared separate from the profile, using a class model, hence doesn’t need to be deployed to end users. As I mentioned, this metamodeling-based approach enables me to build the menu structures graphically. As I can’t draw class relationships between stereotypes I will use a stereotyped class in the model to represent the stereotype instead.

To begin with I need to add a class to represent the Actor Package. I’m using a stereotype in my metamodel profile to represent that this is a new term. I’ve draw a dependency to bind this class to the stereotype I want the properties to be updated for.

A number of classes are already specified in the metamodel for this profile. I want Actor Packages to be available on the right-click menu for the project, so I’m going to use a Composition relation to specify this. I’ll drag on the class representing the AutoMBSEProfile and draw the composition. I also want actor packages to be in the right-click menu for elements typed as use cases packages, so I’ll drag that concept in from the browser and draw another composition relationship.

Finally, I’m going to use a stereotype to say Actor Packages it should be placed in the AutoMBSE Element submenu. At this point I can run the plugin code that sets or updates the properties based on the metamodel I’ve specified here.

This can take a minute or so but is a lot quicker than trying to find all the necessary properties and update them by hand, especially when the number of terms becomes large, or you want to tweak or change their names. As you can see here, the meta-model plugin displays the aggregates properties for the new term element types in a simple table.

This allows me to spot mistakes. For example, my new actor package is missing some element types. I forgot to say that I want Actor Packages to contain actors, for example. To do this, I’ll drag in the UML Actor type from the base metamodel package. I can then draw a composition relationship to say that Actor packages can contain them.

There are also a number of types that I want all Packages to have such as Comments, Tags, Dependencies and Hyperlinks. Rather than draw these individually I’m going to specify these base relationships using a Generalisation relationship to a base Package type. My plugin code will look at the relations of the inherited metatype when forming the property values.

If things start to get complicated I can get Rhapsody to re-lay out this metamodel diagram with a hierarchical style.

Once I’m happy the desired relations are in place, I can then rerun the plugin to set the necessary properties on the stereotypes. This will include the property that determines the right-click menu structure. Again, this can take a while but is a lot easier to do with the profile doing the work for me.

Now we can see Actor Packages are on the right-click menu. By controlling the menus in this way, it’s easier to direct a team to produce more consistent output.  Consistency about how projects or parts of projects are developed can also be valuable when chaining methods together, for example, taking the outcome of use case analysis and consuming them in further downstream analysis such as building an interaction model with executable state machines.

We can think of the team developing the model as a system, where different parts of the system work on different packages and hand off or consume artefacts of others.

Packages are also the default granularity for configuration management of Rhapsody models, and can be shared by reference between different projects.

This concludes the demo for now. The profile I’ve shown here is a prototype of my Autobaun profile, so if you’re interested to know more then let me know and I can maybe show you a few more details.

That’s it for now. 

My name is Fraser Chadburn and I’m a specialist in model-based engineering with Rhapsody. As well as developing and delivering tool-based training for Rhapsody and IBM products, I specialise in providing consulting for clients to achieve higher value by extracting the best from their tools. If you do have any questions then feel free to drop us an email.

Monday 3 August 2020

IBM Rational Rhapsody Tip #81 - Understanding actor test benches (intermediate)

I did this tips and tricks video in response to a few questions that people have asked as to whether they should tick the box to generate code for use case and generate code for actors? To answer this you need, of course, to understand better what you're doing when it comes to system simulation. 

In this video I look at the concept of actor test benches. An actor test bench is part of a simulation that plays the role of an actor. By including the actor in a higher level system, you can show the interactions that is has with named external entities, rather than with the system border. In Rhapsody, this is possible because actors have full classifier status, i.e. they can have ports, operations, event receptions (signals), and state machines, in the same way as blocks do.  This is one of my silent videos (it takes longer to create videos with sound, hence I need to balance my time with paid work).


Note: This is not the case for all UML/SysML tools. 

This is the transcript:

Rhapsody’s code generator is used for both software (embedded C++/C) and systems engineering simulation.
 
Occasionally I get asked what the checkbox means to generate code for actors and generate code for use cases. In this short video I will attempt to explain it by creating a simple simulation model.

The first thing to note is that Actor and Use Case are types Classifier in Rhapsody. This means that they can have operations, attributes/value properties and state behavior just like Blocks.
 
Use Cases can therefore be placed sequence diagrams and used in the same way as if they were a Blocks, e.g., receiving signals or sending events or invoking operations. They could also own state or activity-based behaviors.
 
This should answer the first question, which is why one would tick the box to generate code for use cases?
 
Of course, if you do this then you need to treat the Use case as if it were a Block being used for simulation, i.e., set the name as legal as I’m doing here by changing its name to Camel case. 

Now I can simulate the behavior of the use case by injecting events and see the changes in state on the animated sequence diagrams. The Government actor here. However, is not sown as injecting the event but I could drag a System Border on to show that the event is coming from outside the use case classifier.
 
Suppose, that I want to show the event as coming from the actor?
 
Well, this is where the concept of what is conventionally called an Actor test bench comes in.
Let’s create a build that includes the actor and the use case.
 
I’ll connect them for now, using rapid ports. Rapid ports are ports that have no interfaces. They can be used for building simulations quickly. 

An actor test bench is one that has its own behavior, typically described using a state machine. We’ll get this statechart to send a antibody test event to the port, whenever it receives it as a trigger. We’ll do the same for the test invalidated event.
 
These are both reactions in state as no state change is needed.
 
Now, instead of building a simulation of the use case, I’m going to build a simulation of the test bench and it’s owned elements.
 
In this instance, I need to make sure that generate code for actors is checked. 

The Government actor is now bold in the browser. This means that it is in the scope of the build, so I’ll regenerate and build the application.
 
In this simulation, the Actor test bench is now in scope and has it’s won state-based behavior. I can stimulate the simulation by getting the actor to generate the event on the use case.
 
Of course, it’s possible for the actor to have more than simple forwarding behavior. However, the approach shown here is the basis for how testbenches were designed to work with the Hamrony/SE toolkit.

This answers the question as to why one might check the boxes to generate code for actors and use cases?

Hopefully, that helps. If you need any more help, or want to discuss hands-on tool-based training options tailored to your company then let me know.