Thursday 24 May 2018

Video (8 mins) on Making MBSE with Rhapsody simple (SysMLHelper 3rd generation enhancements)

This video takes you through some of the enhancements I’ve been working on for the 3rd generation of the SysMLHelperProfile; a profile I originally developed to support my Rhapsody training, but which has evolved with my work with different companies rolling out Rhapsody for the first time.
The goal of the SysMLHelper profile is to make MBSE with Rhapsody simple.


















In this 3rd generation of the profile I’m looking to make it even smoother. Creating the initial Requirements Analysis package structure requires only a couple of clicks.












In the box here, it’s asking me to name the package. I’m going to call this FeatureA. Let’s imagine it represents a set of use cases that relate to a new feature for an existing system that we want to work on.



A use case diagram has been created programmatically based on a list of actors in a property in the profile, and hence is customizable.









It we look in the browser we can see that the helper profile created 3 different types of packages.

The main package is the use cases package where we can create use case diagrams with use cases for a feature, but there’s also an actors package, for shared actors, and a requirements package where we want the requirements to go. The new profile has no dependency on a fixed root structure, so this opens-up it up to be used more flexibly in existing projects.


The profile tailors Rhapsody so that the type of package is clear from its icon and category name, and ordering puts things where they’re wanted. Each of these package plays a clear role, and the right-click menus have been simplified accordingly.

We’re not going to use IBDs and BDDs in the use case model, so I’ve removed and simplified the right-click menus.

If all the packages are built with consistent and appropriate modelling constructs for their role, then a measure of uniformity will permeate through our models; making them easier to build, navigate and review. This leads to more consistent simplified usage.

The use case diagram is also customized and includes a process note giving advice.

As with the Generation 2 profile - the double-click will create a nested activity diagram pre-populated with a template to conveys consistency and gets people working straight away.

This Activity Diagram is tailored to focus on textual use case steps, with a simplified drawing toolbar that means that users can easily access the tools needed for the job, and are not left pondering some of the more eclectic activity diagram tools.



The Gen 3 profile includes a new auto-flow feature for requirements. If I create requirements they will flow automatically into the requirements package based on the dependencies between them.








Obviously, a system will be able to perform multiple use cases and multiple features. Imagine that the project is for a single system. We might have one user working on new use cases for a new feature in version 1 while another user works on use cases for a different feature for version 2.

We can create any number of use case packages. We’re using the use case package here to group use cases into features or functions that might constitute marketable commodities. We can run this command multiple times in the same project, giving a unique name to get package.
When I create a use cases package, the profile is intelligent enough to know that I already have an actors package, hence it will prompt me to make use of the actors in it.

We could choose also whether to create a separate requirements package, or not.

We now have two use case packages representing different features. However, they are in the same model and can share the same actors. Importantly, over time you need the flexibility to re-factor your use case model to include multiple features or requirement sets, but where different use case models might be initially built by different users.








As I’m probably going to deploy this with Rhapsody Model Manager the helper is experienced enough to know that by selecting Store in separate directory on the root packages we will make units easier to find on the file system later.









With the Generation 3 of the profile I’ve switch to using properties. The use of Rhapsody properties replaces the previous profiles use of tags under root packages with fixed names. This makes it simpler to configure and maintain, and more consistent with other profiles such as the SE toolkit.


You’ll notice I’ve also added a Perspective to the Properties pane so that you can view the properties for the profile. The defaults here are drawn from a property file in the profile folder, so can easily be changed.











If I tick Enable Gateway types for example, then I can create a stereotyped requirements package when I create the structure.

The goal here is to get the best balance between integration and isolation. One of the benefits of bringing users into the same project is to improve collaboration, especially as Rhapsody Model Manager brings the capability to view Rhapsody projects via the web client.













Requirement stereotypes work really well if we apply a Format to the stereotype. We can do this by right-clicking on the stereotype to access its Format… menu.


We can then say that when this stereotype is applied to a requirement, we want Rhapsody to colour it a specific colour like green.

We can now see that requirements with the stereotype applied are different from other requirements in the project. This gives us a visual cue that the requirement is related to a different specification or collection than other requirements in same project.
















The helper includes a Start link and End link helper that is intelligent to know which type of relation we want to create based on the elements we selected. Again, this is based on property settings in the profile. It can even populate them as it knows they’re on the diagram.



The final thing to note is that as well as automatically creating the structure, the helper is automatically maintaining a package diagram for the project. Here we can see that all the feature packages are sharing the same actors package.


With my automation help this could be one of several automatically maintained diagrams in the project.






This concludes the demo for now. It’s just a glimpse really of the stuff I’ve been working on to make the process of using and deploying Rhapsody to a large team, that little-bit simpler. I’ve just shown the requirements analysis method helpers, one of three stepping stones to achieving a working white box architecture traced to system requirements.

In today’s world many things are automated. Like Rhapsody’s built in Harmony/SE toolkit, the SysMLHelper brings the idea of automation to SysML modeling tasks. You want your team to be doing fun and creative tasks, in a consistent way, as part of a big team in a shared model without stepping on each other’s toes.

This requires more than installing a tool. You need a combination of a modelling language, tools, people, and process to come together. You essentially need a system. The more automation you can get into that system the faster it run, the better it will scale, and the more consistent and predictable its output will be. Consistency also shows that you are meeting your process which may be important for certification and quality assurance reasons.

Some of the methods are based heavily on IBMs Harmony process but use an open-source Rhapsody profile, meaning we have the option to tailor it to fit your organisation and business goals.
I can offer both consulting and training to take these ideas and make them work for your organisation, meaning less time spent trying to re-invent the wheel, and increasing your chance of achieving success earlier in your adoption lifecycle.

If you want to explore any of these ideas, then feel free to look at my www.mbsetraining.com website, or fire me an email.