Tuesday, 12 January 2021

Fix list for IBM Engineering Systems Design Rhapsody 8 onwards

One thing about IBM is that it puts a lot of its support information online. This link may be interesting for some, it lists the defects fixed and enhancements added in the various releases of IBM Engineering Systems Design Rhapsody (formerly IBM Rational Rhapsody), beginning with release 8.0: https://www.ibm.com/support/pages/fix-list-ibm-engineering-systems-design-rhapsody

Friday, 8 January 2021

IBM Engineering Rhapsody Tip #91 - Recap on the OMROOT variable and Share folder (Intermediate)

Welcome to 2021! In this short tips and tricks video I cover a topic that relates to how to set-up Rhapsody in a team environment. Typical use cases for this are where you might have customized the OxF (framework) libraries and model to remove or add code, or where you have user-defined profiles that you want all users to get updates for (because they're opening the same projects). Essentially this can be done by copying the Share folder from a local installation location to a shared network drive location, and then changing the rhapsody.ini file to point to it for all users that need it.  Of course, the caveat is that all users will need access to the folder. The drive path can be different, of course, because the OMROOT variable that points to it is in the rhapsody.ini file. This .ini file is part of the read/write component of the Rhapsody installation and the default OMROOT would've been set-up during the install. Enjoy. Hope it helps.


Here's the transcript (for those that need it):

This short caption-only tips and tricks video is quick reminder of what Rhapsody's $OMROOT variable is.

Let's start by creating a project with a pre-defined project type of SysML.

The SysML profile's unit is added by reference (REF). The path for the file starts with $OMROOT, a Rhapsody environment variable that is set up during installation.

The OMPATH path is setup in the rhapsody.ini file created in the read/write part of the installation. This file is editable, but always backup the .ini file before editing, and never edit when Rhapsody is open, as it’s a file that Rhapsody both reads and writes to.

If we wanted to move the OMROOT then we could. It points to something called the Share folder. The Share folder contains many important aspects of the Rhapsody installation including profiles, properties and settings, as well as framework code libraries used for model execution. E.g., here is the unit (file) for the SysML profile referenced by our project. 

Importantly, we may want to customise aspects of Rhapsody, such as the Framework code (OxF), or adding new settings or plugins. One way to enable all users to access these changes is to copy the Share folder to a network folder location that all users can access. 

We can then change the OMROOT in the .ini file for all the users to point to the network Share folder location. Remember, don't edit the .ini file while Rhapsody is open otherwise there's a risk of corruption.

The benefit of the shared location is that updating user-defined profiles, recompiling and linking framework code can be done centrally. To illustrate, I'll add this helper profile that I downloaded from my Github project. It's got a range of different profiles and plugins for different SysML project types. By adding it to the Share > Profiles subfolder, users with their OMROOT changed will be able to open projects that use the profile. The list of project types is now much wider than the factory set.

The project has referenced my project profile and plugin, including adding new right-click menu commands. The user-defined profile is being referenced from the Share folder that can be on a shared drive. Of course, if you can't access the drive then Rhapsody will complain when you try to open it.

If you're moving your machine to different locations then make sure the drive will still be accessible!

In summary, the OMROOT variable points to the Share folder. If you want to customize Share folder contents for all users then one way is to move it to a cental location and change their rhapsody.ini files to point to it.

Hope that helps. If you do have any questions about Rhapsody or want consultancy or training on how to customize and set-up to get high level value quickly, then feel free to email me.

Tuesday, 1 December 2020

Jazz.net articles on known limitations for Rhapsody Model Manager (RMM)

In case you're interested, e.g., planning RMM upgrades/installs upgrades, Jazz.net provides a source of wider information, e.g., known issues and limitations articles:

Workarounds and Limitations: Known issues in Rhapsody Model Manager 6.0.5 (Rhapsody 8.3)

Workarounds and Limitations: Known issues in Rhapsody Model Manager 6.0.6 (Rhapsody 8.3.1)

Workarounds and Limitations: Known issues in Rhapsody Model Manager 6.0.6.1 (Rhapsody 8.4)

Workarounds and Limitations: Known issues in IBM Engineering Systems Design Rhapsody – Model Manager 7.0 (Rhapsody 9.0)

Workarounds and Limitations: Known issues in IBM Engineering Systems Design Rhapsody – Model Manager 7.0.1 (Rhapsody 9.0.1)

One to be aware of is the Windows file path limitation. This is one reason why I set my sandbox areas to be C:\workspaces (or something short like this).

Friday, 27 November 2020

IBM Engineering Rhapsody Tip #90 - Switching requirements from Rhapsody to DOORS Next (Intermediate)

I'm a big fan of not just tracing model elements to requirements but using use case analysis to define requirements for a system. I like the analogy of how modeling provides a powerful and visual workshop in which requirements can be forged and the requirements management is the "gallery" where the resulting works will be exhibited moving forwards. This isn't just about creating requirements to manage but rather finding way to get a better and more complete set of requirements to manage, and also the use of diagrams to communicate in ways which textual requirements cannot. This is video I cover some of the provisional work I've done in adapting my methods, like ROCKETS (R=Requirements), to work with Rhapsody and Jazz/rm (aka DOORS Next). In this work I use existing technology in the form of the csv importer to first get the requirements into a DOORS Next module. I then add the requirements to the model and use a profile helper in Rhapsody to perform the switch. The good thing about this technique is that it means that my helpers work for wide variety of different Rhapsody and Jazz versions and is not tied to an API or the need to do authentication to achieve the sync, i.e. it's not ROCKET science but it helps load the payload into the ROCKET using a 10 minute method.


Here's the transcript:

This silent video covers some development work I'm doing on my profiles.

Some who've followed me may have picked up that I see value from dovetailing use case steps with textual requirements.

Creating requirements from textual activity diagrams for use cases is stage 1 in most of my MBSE methods, including my executable MBSE method called ROCKETS.

To help achieve quick success from MBSE quickly and systematically I've written profiles like this ExecutableMBSEProfile to set up the tool to provide a "10 minute" method.

Diagrams like this are highly accessible because most people can understand flow-chart like semantics with limited training.

For use case modeling, we can use decision nodes to show alternate paths (e.g. sunny and rainy day) on the same canvas.

Diagrams are richer than text, e.g., you can also show things happening in parallel.

Interruptible regions like this can also be powerful, e.g., to show things being interrupted by events.

Importantly people can read a flow-chart like syntax without needing much training, including users.

The Requirements Analysis stage of ROCKETS, focused on the production of formal requirements using use case steps as a stepping stone.

Requirements are the formal hand-off but they are fortified by the understanding conveyed in the diagrams.

In this particular method, all use case steps and guards must be traced to reviewed requirement(s) before hand off to the next stage.

The profile provides automation to make this  easy to do, once the use case steps have been reviewed with stakeholders.

As well as being fun this can lead to a surprisingly complete set of functional requirements when followed through to fruition.

Use case steps are not requirements and requirements are not use case steps. However, they are both enhanced by dovetailing them together.

To accelerate usage, my helper profile has automatically moved the Rhapsody requirements into their own package.

The end of the Requirements Analysis stage involves getting Rhapsody requirements into a formal requirements management tool.

Previously, my methods worked well with the Gateway Add-in and DOORS 9. Moving forward there is a need to be able to switch requirements to DOORS NG (Jazz/rm) without the Gateway.

I want to show you some early work, I've done to achieve this.

Firstly, I'll create a module in DOORS Next where I want the requirements to go.

To get them into DOORS NG I've written a helper to first export them into a CSV file.

This isn't rocket science. However, using the csv import works for all the versions of Jazz, i.e. makes things less coupled to specific versions.

I'll now choose the CSV file import in DOORS Next and select the module I want to import them into.

I'm treating the model as the 'workshop' where requirements are forged, and the requirements management tool as the 'gallery' where they are exhibited.

Next we need to create a view with just the requirements we want to sync back to the model.

Creating shared views are how we aggregate the requirement artifacts we want to trace to the model (include the name of the module here).

We can now tell Rhapsody to load the view we just created into its remote artifacts package for the RM Project.

Remote artifacts are visible in the Rhapsody browser but stored on the server.

To get my automation to switch the Rhapsody requirements to their Jazz/rm counterparts, I first add them as OSLC links to the requirements package.

Finally, I run a "switch requirements to DOORS NG" command that I added to my profile's right-click menu.

This does the switch on all the diagrams and removes the old requirements

All the requirements are now actually in DOORS Next (Jazz/rm).

Before delivery, I'll also run my profile helper to rename action/event names on activity diagram(s).

I'll now deliver the changes so that OSLC links can be seen in DOORS NG (Jazz/rm).

I can now add a column to DOORS Next to show traceability to model element(s).

My renamed actions are nicer to see here.

To finish off, I'll just publish the diagram to Jazz also. Here's the diagram in the web client.

People can review the requirements and use cases using a web browser. Using my profile, we've created formal requirements that tests and design elements can trace to, in less than 10 minutes ;-)

Interested in Rhapsody customization, MBSE methods or Rhapsody training, then feel free to email me.

Reflections on last weeks training - picking a user's own example

Last week I did another 3-day remote Rhapsody training for customers of an IBM business partner again. It still amazes me how much there is in SysML and Rhapsody to teach and it's not easy in 3 days. What seemed to work well this time was to actually model the use cases of their system with them. I think this brought into perspective how it might add value in their context. I doubt that 3 days is enough to learn Rhapsody but I think that it provides a solid foundation level of knowledge to then use, to make decisions about how to apply, and also the importance of adapting the training to the participants to make it relevant and fun. 

Friday, 20 November 2020

IBM Engineering Rhapsody Tip #89 - Exploring how RMM has changed, 6.0.6 to 7.0.1 - Part 2 of 2 (Intermediate)

This is the second of two videos that explores how Jazz-based Rhapsody Model Manager workings have changed in the 3 releases from 6.0.6 to  7.0.1. It follows on from tip #88. The main change is that the /am functionality is now provided as an extension to the /ccm application. This means that work items and model management are stored in the same repository. There is also a new license that enables the /ccm server to be used for either just Rhapsody models, or Rhapsody models and source code. In this caption-based video I look at a few aspects of using 7.0.1, including associating changes to work items, and being able to do more functions like accepting change sets directly from the Rhapsody browser. I also recap how to establish links to requirements in the IBM Engineering Requirements Management DOORS Next application (/rm) - although this is not new.



Here's the transcript in case it helps:

In this silent video, I look at enhancements added between 6.0.6 and 7.0.1 in Rhapsody Model Manager (RMM) - the server-side technology for managing Rhapsody projects in IBM's Jazz platform.

Remember, in 7.0.x Jazz, RMM is now part of the /ccm application, not a separate /am application.

This makes integrated work item planning easier, as it's now managed by the same /ccm Jazz application as the change sets.

In 7.0.1, a new RMM license called "Model Manager - Systems and Software Engineer" is used rather than the "Design Manager" license.

Let's make changes to our model under RMM 7.0.1 control.

As in 6.0.6, I can also add OSLC links to requirements stored in the Jazz-based DOORS Next.

From Rhapsody menus, we can exploit Jazz governance and change tracking, e.g., associating changes with work items in /ccm.

Here we can see that the change set has been attached to the work item.

The Engineering Workflow Manager (EWM) Eclipse client still provide more advanced configuration management features such as work item editing.

Tight integration between model management and change management means that linked data and history is automatically captured.

You can also manage things like approvals and reviews using work items linked to elements under review.

Another key theme  in the 3 releases since 6.0.6 has been additional menus enabling more EWM commands in the  Rhapsody browser. Let's switch user.

Having got Bob to deliver his changes, I've switched user to Deb now.

She's notified of Bob's changes.

She can see there are changes directly in the Rhapsody browser from the descandant overlay icons.

She doesn't need to leave the Rhapsody client to know that changes have been made.

This is new! In 9.0.1 Rhapsody, she can accept incoming change sets directly from the Rhapsody menus.

Her Rhapsody model has been updated with the changes made by Bob.

To finish off, let's have a look at the RhapsodyModelManager > Requirements Coverage Table.

Here we can see the traceability that the elements in this package have with requirements, including those in DOORS Next.

Interested in RMM or Rhapsody training/customisations? Email me.

Thursday, 12 November 2020

IBM Engineering Rhapsody Tip #88 - Exploring how RMM has changed, 6.0.6 to 7.0.1 - Part 1 of 2 (Intermediate)

One of the areas where the IBM Engineering Rhapsody development invested a lot of effort in the last 3-4 releases is in its integration into the IBM Jazz platform with the Rhapsody Model Manager (RMM) server-side technology. This is crucial, of course, for its integration with DOORS Next generation, IBM's web-based Requirements Management (RM) technology built on top of Jazz. RMM also enables web views of the model and linking with work items and planning and shared configured access to models. In version 7 of Jazz there was a significant change, in that the functionality provided by the /am application became an extension to the /ccm application, rather than a separate entity. Over the releases they've also done work to make more functionality available directly in the Rhapsody browser. In this first of two videos, I wanted to give some examples of things that have changed (especially to those who are user older versions and thinking of migrating).



Here's the transcript of Part 1:

Rhapsody Model Manager (RMM) is the server-side technology for managing Rhapsody projects in the IBM Jazz platform.

To enable me to create/update my training for different Jazz releases, I've installed a local 7.0.1 Jazz server using a Hyper-V virtual machine (in Windows 10 Pro).

In this silent video, I look at some of the key differences I've noticed in the 3 releases from RMM 6.0.6 to 7.0.1.

An obvious change is the renaming. Engineering Workflow Management is the new name for Rational Team Concert.

Not too many changes in the Eclipse client. It still performs the role of allowing access to  deeper workflow management features.

There's still lots of stuff available here like baselining, data feeds, diff/merge, work item editing, creating components and workspaces.

Let's launch Rhapsody 9.0.1 for the 7.0.1 server. This too has been renamed for 9.x (dropping the 'Rational' branding).

This project has been disconnected from the server, so l need to re-attach it to the server.

As before, status icons show use the status of units under configuration management.

There's some new functionality related to seeing the descendant unit's status though.

The smaller overlay icon in the top-right, tells me that a child unit has changed enabling me to know where changes are in the tree.

Also, the older Team Concert menus are now split across the Unit and Unit with descendants menus.

The Unit with descendants menus makes it easier to do SCM functions further up in the browser tree, e.g., deliver or accept changes.

The status icons are updated and the output window includes slightly more information than in 6.0.6.

Let's try making a diagram change.

As usual with Rhapsody, there are some properties that will control behavior, e.g. diagrams will be updated on deliver according to this policy.

The default Save policy will be to check in the changes and Deliver will deliver the changes and update the web views.

You may notice a bit more information in the web client (compared with 6.0.6) and the diagram was updated (actually this was in 6.0.6.1/Rhapsody 8.4 also).

So, here's the biggest change in 7.0.x. No, not the black bar, but rather  the /ccm application has taken on the role of RMM as well.

Let's review of the Jazz applications.

Engineering Insights is what used to be called RELM.

"DOORS Next" name makes an appearance in the menus (/rm).

Quality Manager is Test Management (/qm).

Team Concert is Workflow Management (/ccm).

/am is no longer a separate Jazz application. It's combined into the /ccm application (when installed correctly, the /ccm project area can be configured to enable model management)

This makes it easier to install/deploy but is something to consider when upgrading from pre-V7.0 servers. It also means that a same /ccm project area can provide access to both model information and work items.

I'll cover this in Part 2 and also the ability to accept changes from the Rhapsody menus (stay tuned ;-)

Interested in RMM or Rhapsody training/customizations? Email me.