Saturday 23 February 2019

Rational Rhapsody Tip #54 - Linking models to remote requirements in DOORS NG 6.0.6 (Intermediate)

This second short min video follows on from the previous one (#53) and shows what you can do once you've associated a Rhapsody /am project area with a DOORS NG /rm project area. This is really the core of what OSLC linking is all about. You can connect data to other lifecycle artefacts without leaving the tool that you're in. In my opinion the Rhapsody development team have actually done a good job here with the 6.0.6 implementation of Rhapsody Model Manager (RMM) - its server-side back-end. The good thing for me is that it fully supports the well established mechanisms of an OMG SysML approach with requirements in the model and traceability captured both graphically and in diagrams. It allows you to dovetail requirements in DOORS NG with modeling artifacts in Rhapsody despite them being separate applications. Other good things in the 6.0.6 (Rhapsody 8.3.1) implementation are the ability to navigate from the web-client to the Rhapsody rich client, and the quickness of the linking. It's almost like the requirements are part of the model, despite the fact that they're being provided and linked to by an separate application.


1. In this video I look at how the IBM Jazz platform (6.0.6) allows you to link Rhapsody model elements to requirements in DOORS NG (DNG).

In the first video I created a Jazz lifecycle project which associated my Rhapsody architechure management (/am) project area with Jazz project areas for work items (/ccm), tests (/qm), and requirements (/rm).

2. When I open a Rhapsody project, it will automatically populate the Remote Artifact Packages category with these associated project areas.

3. I can then login if I want to access these 'live' resources from the Rhapsody browser.

4. For linking, rather than show all the artefacts, I can choose to populate a collection.

5. OSLC uses a delegated user interface approach allowing me to select a collection in DOORS NG without leaving Rhapsody.

6. With DNG we can have view of modules. For example, a view filtered to show just the approved stakeholder requirements.

7. What is great about the Rhapsody dev teams approach is that although these requirements are remote resources, I can use them if they were part of the model.

8. For example, we can drag them on to diagrams...

9. ... and add dependency-based traceability (ala SysML).

10. The traceability that is created as actually OSLC-based, hence will be navigable also from DNG.

11. With the new /am application the links are stored in the Rhapsody project. This makes it quick to add and correct them before they are delivered.

12. We could establish review gates also, prior to delivery, as they're stored in the change set.

13. When the change set is delivered, the links will be visible in DOORS NG.

14. DNG is an entirely web-based client built from scratch using the Jazz-platform.

15. Module views allow me to choose which attributes or links to show. For example, a Stakeholder Approved view in which we can see the linked Rhapsody model elements.

16. Hovering over the link, a rich preview is provided by the Rhapsody Jazz/am web application.

17. 6.0.6 has a handy Show in Rhapsody button.

18. This overlay icon is showing that the requirement is linked...

19. ... and we can add relations here also.

20. Again, remember that we have to deliver before these are published to others.

21. In this instance we added a different type of relation.

22. Jazz /rm allows you to show these SysML-based link types, out-of-the-box (there is very little configuration you have to do).

23. The other thing about Jazz /am is that you can also view the Rhapsody model and links without needing Rhapsody installed.

24. For example, in the /am (RMM) application in Jazz, we can see all the DOORS NG (Jazz /rm) requirements linked to the use case.

25. The same traceability is viewable across applications, making it truly collaborative with a highly integrated feel.

Friday 15 February 2019

Rational Rhapsody Tip #53 - Linking Rhapsody to DOORS NG using a Lifecycle Project (Intermediate)

This 7 min video is the first of two looking at OSLC linking between Rhapsody projects and Rational DOORS Next Generation (DNG). It shows a trick I often use to set up a simple evaluation environment. The trick is to create the Rhapsody Model Manager (/am) and DOORS NG Requirements Management (/rm) project areas first (using the AMR system sample) and then use the Jazz Lifecycle Project Area wizard to create the associations. Another thing shown in the video is the use of a Module View in DNG to define requirements to link. A DNG project area can have many thousand artifacts of many different types. A View allows you to limit what's shown in the Rhapsody browser. With an association created to an /rm project area, the Remote Artifacts Package category can then be populated to show the requirements in DNG directly in the Rhapsody browser. They're not imported, of course, rather Rhapsody is able to use the OSLC interface to expose requirements that are stored in the /rm database, for modeling purposes (which will be the topic of the next video).




Note: In visiting a few of my customers I noticed that you're not all able to view YouTube videos, hence I'll try and put a bit more detail on the blog.

1. One of the quickest ways to create a Rhapsody project area linked to Requirements for evaluation is using a Jazz built in lifecycle project template. The wizard includes an initial template for Rhapsody Model Management with CLM (Requirements, Change, and Quality Management).

2. When a project is stored in Rhapsody Model Manager (Jazz /am) but not associated with other project areas then it will have an empty Remote Artifact Package category in the browser.



3. DOORS NG has a customizable information model and hence your Jazz /rm project will look different based on the template you choose.

4. To show DNG for complex systems engineering there is a “systems sample” for an Automated Meter Reader project so I’ve created a project using that (OK, I’ve called the project something else).



5. As a module in DNG could contain artifacts of many different types, we might want to create view that just shows requirements. I created this shared ‘Stakeholder Approved’ view, for example, to show all the Approved requirements with the Artifact Type Stakeholder Requirements.

6. One of the quickest ways to create associations between multiple project areas is to choose Create Lifecycle Project.


7. There is lifecycle project template called Quality Professional, Analyst, Developer – with Architecture or Design Management.  You can Link to Existing … for the project areas you already have created.



8. The lifecycle project creation establishes the missing project areas and also sets up associations between them that will bring OSLC linking to life.
9. We need to ensure that the necessary users members of the new project areas and that they all have appropriate roles.


10. Now in the Jazz /am project area, there are Associations to the other project areas listed (to requirements, change, and quality management).

11. If we close and reopen the Rhapsody project we can see that Remote Artifact Packages are now listed in the browser, and we can login to the server and choose to populate a collection.

12. The requirements in DOORS NG (Jazz /am) now become visible in the Rhapsody browser.

Friday 1 February 2019

Rational Rhapsody Tip #52 - Making user-defined types appear in selection dialogs (Simple)

In a recent IBM Rational Rhapsody training, a user asked me how they could get data types they’ve added (or reverse engineered) to appear in the pull-down list when a user selects the type for an attribute or operation argument. Sounds like another topic for a short Rhapsody tips and tricks video, I thought, so here you are, tip number 52 in a 3 min format! Of course, like many things in Rhapsody there’s a property to help, it’s called General::Model::CommonTypes, and can be set at either the model level or in a profile. The property specifies which types are listed as alternatives for attributes, variables, and arguments. It makes commonly used types easily accessible and you can specify a list of packages.















On a related topic, if you want to remove the predefined types from the browser, there’s also Browser property you can use to do that. It’s called Browser::Settings::ShowPredefinedPackage. The video also shows this, in case it's useful (I sometimes use it to simplify the browser for people).