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.

Release of V2.2

This version is functionally-equivalent, to 2.1 (Release) and is considered a Release version and contains a fix to a threading issue that was causing creation of the functional block hierarchy to not work in Rhapsody 8.3.

The following changes were made for v2.2 on GitHub (released 08-APR-2018 - Release build):

#247 08-APR-2018: Fix threading issue crashing functional block hierarchy creation in 8.3 (F.J.Chadburn)
#248 08-APR-2018: Update copyright notice year to 2018 (F.J.Chadburn)

It is recommended for all users of the profile to move to this version to avoid this issue. The issues relate to limitations in the Rhapsody API when trying to get GUIs to work in separate threads. The solution took a little while, but came with the help of Andy Lapping. He's put a bit of background here:

http://www.merlinscave.info/Merlins_Cave/Tutorials/Entries/2018/4/3_Building_GUI_Based_Helpers_for_Rhapsody_-_Dealing_with_Multi-Threading.html

Changes log for v2.1 (Release) profile

The following changes were made for v2.1 on GitHub (released 05-NOV-2017 - Release build):

This version is functionally, i.e. profile and code-equivalent, to 2.1.r and is considered a Release version. The only functional difference between this and the 2.1.r version is the version of the plug-in version in the Config.properties has been changed to say 2.1.Rhp82 (Release).

#246 05-NOV-2017: Changed the plugin version to 2.1.Rhp82 (Release)

Full change history since 2.0 (Release) is in the CHANGE_HISTORY.txt

This release can be downloaded from GitHub link above:

Changes log for v2.1.r (UnderDev) profile

The following changes were made for v2.1.r on GitHub (released 11-OCT-2017 - UnderDev build):

These only relate to use of Call Operation actions, i.e. when the activity diagram is used for functional decomposition using operations. Issues found during robustness testing:

#244 11-OCT-2017: Default ADs to Analysis mode to better support call operation parameter sync (F.J.Chadburn). ..

When you choose MBSE Method: Functional Analysis > Copy activity diagrams to package under development .

... the plugin will now make sure that the Analysis Only check-box is ticked on the copied diagrams.

This ensures that Rhapsody's menus appear (so that the workflow is improved if you did want to go on and use action pins with activity parameters where the master for the inputs/output pins is the are the parameters on the operation)

#245 11-OCT-2017: Fixed exception on CallOperation action drop when using detailed ADs with Ops (F.J.Chadburn). This may relate to changes to Rhapsody behaviour between versions, i.e. it was working for some but not all versions, hence I changed the hook used to get the element to be more robust.

Essentially, when the FunctionalAnalysisPkg package structure is added you can right-click a AD to create a more detailed one.

When you drop a CallOperation on the diagram, the plugin will pop up a dialog that allows you to create the Operation for a Block that is part of the system assembly.

The Operation is added to the Block and hooked to the Call Operation automatically, thus speeding up the process of building a list of re-usable functions.

Note: This also works when you're doing white-box modelling. If your _SystemAssembly block has more than one part which is not an actor or test driver, then a dialog will be popped up by the plugin to ask you which Block to add the operation to.

Changes log for v2.1.q (UnderDev) profile

The following changes were made for v2.1.q on GitHub (released 04-OCT-2017 - UnderDev build):

The main thing here are robustness improvements to reduce issues when user opens multiple Rhapsody clients, namely to give a warning. Also some users keep asking how to add pre and post conditions to AD, so I added to toolbar to remove them having to ask. Plus a couple of little tweaks discovered during testing.

#238 04-OCT-2017: Improve ability to add new UC pre or post conditions to the AD (F.J.Chadburn). Added these to the AD toolbar propagated to packages that have the RequirementsAnalysisProfile applied. It just makes it easier for users who are new to Rhapsody who are using simplified activity diagrams to model use cases. Had to add stereotypes to profile as built in Precondition/Postcondition stereotypes used before were constrained by properties prevent their use in toolbar.

#239 04-OCT-2017: Improve warning/behaviour if multiple Rhapsodys are open or user switches app (F.J.Chadburn). Occasionally users will accidentally open multiple Rhapsody's and accidentally modify the wrong model. This enhancement reduces that risk leading to better overall robustness in wider deployments.

#240 04-OCT-2017: Prevent commands running in the SysMLHelper model to avoid accidental damage (F.J.Chadburn). This enhancement reduces that risk leading to better overall robustness in wider deployments.

#241 04-OCT-2017: Fixed TableL - Use case refinement relations so that it works as expected post 8.2 (F.J.Chadburn). Oddity, but for some reason Use Cases were not selected in the shipped profile (probably dates back to the 8.2 upgrade). All fixed now though.

#242 04-OCT-2017: Get re-layout dependencies on diagrams(s) menu to centre on graph edges properly (F.J.Chadburn). Improvement to v2.1.o enhancement.

#243 04-OCT-2017: Added ability to do smart link from a testcase to create a Verification (F.J.Chadburn). Again, a small thing I noticed as being useful.

Changes log for v2.1.p (UnderDev) profile

The following changes were made for v2.1.p on GitHub (released 27-SEP-2017 - UnderDev build):

There's nothing urgent in this one, just a bit of polish that helps me with white box simulation building.

#231 27-SEP-2017: Enhanced tooltip now shows the req't text when hovering over traceability relations (F.J.Chadburn). I did this because I found I was often navigating to the end of dependency to be able to read the requirement text, hence this enhancement saves a lot of time when working in concert with textual requirements as the formal hand-off.

#232 27-SEP-2017: Improve move unclaimed req'ts needs so that it handles read-only packages better (F.J.Chadburn). Essentially, the helper won't provided referenced packages as an option to move into. Note: The method allows for the RequirementsAnalysisPkg to be added by reference, e.g., it can be developed by a different modeller in parallel! (the so called "Wing-person" approach to modelling where the Wing person is building and testing the requirements into a simulation that can then generate the test cases).

#234 27-SEP-2017: DesignSynthesisProfile no longer sets property to hide part/Object name on IBD (F.J.Chadburn). This is a better default. Of course, the user can override if they wish.

#235 27-SEP-2017: FunctionalAnalysisProfile now sets ObjectModelGe::flowPort::ShowName to Name only (F.J.Chadburn). This is a slightly better default when doing flow-based modelling and coarse-grain sim work as type is considered detail. Of course, the user can override if they wish.

#236 27-SEP-2017: Improved Add new Block/Part... dialog to allow naming of part (F.J.Chadburn). Of course, this menu is a available in a bunch of places and is used when building white-box simulations. It means you can create a part/block and stereotype it in one action (next thing will be to ask using to populate part on the IBD if there happens to be an IBD open). This is all about making it simpler for modellers to handle the part/Block model in SysML. The Helper also asks if you want to update the simulation SD template automatically to include the part.

#237 27-SEP-2017: Resolved Java path problems with Entry in certain versions of Eclipse (F.J.Chadburn). This is really just an SCM issue, if you want to configure the code using RTC, rather than GitHub.

Changes log for v2.1.o (UnderDev) profile

The following changes were made for v2.1.o on GitHub (released 20-SEP-2017 - UnderDev build):

No bug fixes here, just a couple of helpers that I think will speed things up for people:

#229 20-SEP-2017: Add re-layout dependencies on diagram(s) menu to ease beautifying when req't tracing (F.J.Chadburn). This is in lieu of the General::Graphics::KeepEndPoints property not working quite as expected, an 8.2+ property (which if unchecked might have preventing need for menu).

#230 20-SEP-2017: Initial alpha trial for create test case script from a sequence diagram (F.J.Chadburn). Right-click a simulated sequence diagram to populate a test script on to the test driver. Limitation is that I haven't yet got arguments to be transcribed over. It does make creating test cases from running a sim much quicker though ;-) Make sure you save the sequence diagram first though, so that script can read the events on it.