Friday, 17 September 2021

IBM Engineering Rhapsody Tip #100 - An example of a general belly tickle problem

This is another one of my short, and silent, IBM Rhapsody tips and tricks videos. It actually came up in my tool training this week, as creating generalizations between the use cases and finding them in the browser, is part of one of my labs. The problem is sort of a user error, in that new users often press Delete on a diagram, and forget that a relation still exists in the model. When you do this because you've drawn an OO generalization relation the wrong way around, and then attempt to draw the generalization in the correct direction, then you get an error message from Rhapsody saying that you can't add a relation as it will create a cyclical relation in the inheritance structure. To fix the issue you can complete relations to populate the relation on the diagram and then properly delete it from the model, before redrawing.


Here's the transcript:

This is one of my "quickie" quick tips for IBM Rhapsody. The issue came up in my tool training delivery again this week, hence I've turned it into my video tip #100!

It's silent so you have to reeead tttthhhhe teeeext!

This "user error" basically relates to Rhapsody cleverly detecting that you're trying to add a cyclical generalization relation.

To demonstrate, I'll first add a couple of use cases and a generalization relation between them.

What I want to say is that "Give a belly tickle" is a specialization of a more general "Give a tickle" use case. 

Oops, I've drawn it the wrong way around! I'll press Delete so that I can draw it again.

Rhapsody stops me from doing this as it detects that this would create a cycle in the inheritance structure (which is illegal and would cause nasty issues).

Well, we all know why, of course? 

On a diagram, pressing Delete removes from view, it doesn't delete from model (so the relation still exists).

Tip: If we want to know if there are relations in the model not populated on a diagram then you can use the Layout > Complete Relations menu.

This will populate relations that exist but not shown. It's a good way to check for unexpected relations.

To really delete then we should choose Delete from Model from the right-click menu and we can then draw the relationship the correct way around, i.e., Give belly tickle "is a" Give a tickle use case ;-)

Tip #2: If you hold down Ctrl key and press Delete on the diagram, then it will Delete from model. When you Delete from model then you get a confirmation dialog. This is good way of knowing that you really are deleting.

Thursday, 5 August 2021

Aggregated feedback from most recent Rhapsody training

The following is the feedback from my last IBM Engineering Rhapsody training using V12 of my material (mainly to software engineers + some systems/research), where 5 = Strongly agree, 4 = Agree, 3 = Neutral, 2 = Disagree, and 1 = Strongly disagree.









What did you like most about the training/other feedback?

  • Drilling the concepts through "labs"
  • Technically involving course. Fraser is very knowledgeable on the topics and is happy/ready to answer and help with any questions.
  • Really good & detailed resources, instructor very knowledgeable, easy to follow exercises
  • Practical labs and engagement were good.
  • Lab work
  • Hands on experimenting on Skytap virtual machine very useful. Having a cleanly setup environment with all the notes and lessons ready is great.
  • Doing the labs
  • Thank you.  As a last minute addition to the course, with no prior knowledge or expectation, it was clear and all very interesting.
  • It was a great course

Aligning IBM Engineering Rhapsody client with your Jazz server for Rhapsody Model Manager usage

Generally, it's important to align your IBM Engineering Rhapsody client with your Jazz server for Rhapsody Model Manager usage. This is a useful link to an IBM page that says which Rhapsody version aligns with which Jazz product:

Rhapsody and Rhapsody Model Manager integration (ibm.com)

Tuesday, 20 July 2021

IBM Engineering Rhapsody Tip #99 - Making life easier with some proxy port automation

In this short silent video, I wanted to showcase a couple of helpers I wrote for a client. Basically, if you expect people to follow steps that are repeatable, then why not get the computer to do it? (Steve Jobs: I'd rather than a lazy engineer than a good one). I want my Rhapsody modeling to be like my iPhone, in that it just does stuff I expect without me having to think about it. In this video I show a couple of helpers that I did to speed up modeling for a client who wanted to use Proxy Ports. Essentially, I just roll the things that I would do manually into a profile plugin, and Bob's your uncle. The interesting thing about automation is that the more you do, the more ideas to speed things up pop out. Also, the market for SysML has matured a bit hence there are a few more new users, with less training and patience. I want to make it as easy as pie to model, so that they stick to the fun and creative stuff, and are able to demonstrate business value first time, rather than flop around like busy bee's unable to find a flower. 


Here's the transcript for those that need it:

In this silent video I thought I'd share a snippet of some automation I've been writing to make it easier for a client to model with Proxy Ports in Rhapsody.

The first bit here, is to speed up creation. Since, I know modeler is expected to use proxy ports, I detect the add new for part->part connector, and create proxy ports automatically. My plugin also creates the interface block that will define the contract. The 'opposite port' has the fiddly stuff done, e.g., the conjugated flag is set.

Now we can define what is exchanged via the InterfaceBlock. This is usually done by creating an interaction model, i.e., using sequence diagrams. This is an event (asynchronous signal) from the Operator to the system. I'm using a condition mark here to imply the state of the Block, i.e. I'm inferring states for the subsystems and, importantly, the signals sent between the subsystems via the proxy ports.

In "Analysis" mode, operations/events in sequence diagrams are not created automatically in the browser, meaning that it's easy to change event names. This is standard behavior in Rhapsody. There is a separate "Realization" step that you perform once the sequence is finalized. The final piece of "speed up" automation I wanted to show, is a helper that no-only realizes the events/operations, but also updates the ports and interfaces.

This is similar to a really useful helper provided by the Harmony/SE toolkit, but I've added a user interface. Still some work to do but the aim is to always explain what you're going to do, before doing it, as this helps with training people in what is going to happen.

As well as realizing the operations and adding events and event receptions to the Blocks, it has updated the Interface Block. As the rest of this video shows, I can go on to create statecharts and build an animating model of them.

Ultimately, with "speed up" helpers like the ones I've shown, we can accelerate your modeling process and engineers can focus on the creative and fun stuff.

In lieu of TrustPilot, some recent training feedback

I don't really have the volume of deliveries or business to live in the world of trust pilot. However, I do appreciate that it's good to have real feedback from real people.

As such, I thought I'd share some feedback from recent 3 day Rhapsody trainings in the last 2 months. In the following survey, 5 = strongly agree and 1 = strongly disagree.

What did you like most about the training?

  • The labs really helped enforce the theory and brought the material full circle.
  • It's a new tool for me that can capture big picture ideas and decompose to manageable chunks.
  • Labs are great. Good examples.
  • Instructor & the labs
  • Flexibility to demonstrate tasks on demand, make it easy in this environment.
  • Lots of tips and short cuts for action users 
  • I had no prior knowledge regarding Rhapsody however leaving the training I feel like I'm able to perform task via Rhapsody. The trainer was also very knowledgeable and kept the participants engaged. 
This week, I'm moving on to Version 12 of my material. I've added a simplified DOORS NG with Rhapsody half-day workshop which can be optionally used to finish things off with a fun "from scratch" example. I've also added even more differentiation to the labs to give me more options based on whether participants are experts who use Rhapsody a lot, or new to SysML/Rhapsody, so that I don't scare people with too much information, if I can help it.

Saturday, 3 July 2021

IBM Engineering Rhapsody Tip #98 - Debugging user Java plugins running in Rhapsody

When you write a lot of add-ons for IBM Rhapsody, it becomes very helpful to be able to debug them. This can be a little more difficult when they're running inside the Rhapsody processes, rather than as an external Java application. There are lots of reasons for running in process though, not least because they run an order of magnitude faster, and you can tie them to a profile that adds things like menu commands and properties to control it. In this video I show how it's possible to debug them as remote java applications enabling you to set breakpoints and step through the code in Eclipse, even though the code is running in Rhapsody. You first need to add some changes to your Rhapsody ini file though. The video illustrates. Hopefully, it helps someone out there. p.s. This is a real life example.


Here's the transcript for those that need it:

This video demonstrates how it's possible to debug user-written Java plugins running in the Rhapsody process using Eclipse. 

Java add-ons for Rhapsody can be written to run as applications outside of Rhapsody, or as plugins running in the Rhapsody process (as here). Plugins can be loaded by a profile. 

A certain amount of debugging can be done using instrumentation. It doesn't always work though. In this case, I'm expecting my plugin listener to detect the event and automatically move it into an 'interfaces' package.

To determine what is happening, I want to use the Eclipse debugger to set breakpoints and step through the plugin as it runs inside of Rhapsody.

It's possible to do this by first adding some JVM settings to the rhapsody.ini file. As Rhapsody reads/writes the .ini file, always create a backup and make sure Rhapsody is closed before editing.

The JVM section is where the Java Virtual Machine that Rhapsody will use is specified.

I've added the Debug1, Debug2 and Debug3 options to my .ini file before, hence I just need to include them in Options list for the JVM.

[JVM]
Options=ClassPath,LibPath,Debug1,Debug2,Debug3
Debug1=-Xnoagent
Debug2=-Xdebug
Debug3=-Xrunjdwp:transport=dt_socket,address=6743,server=y,suspend=y

Now when I run Rhapsody and an attempt is made to load a plugin into the Rhapsody JVM, it will wait for a remote debug connection.

To get the Eclipse debugger to connect we need to run a Remote Java Application configuration and change the port number for the Remote Java Application to 6743.

Voilà, the debugger connects with the waiting plugin running in the Rhapsody JVM.

It's now possible to run the application as normal, but set breakpoints in the plugin code. E.g., I'll set a breakpoint in the Java plugin.

That's strange...

To reload the plugin code, I need to exit Rhapsody not just close the project.

Doh!! (an unnecessary space, but I can fix it)

Hope that helps. Interested in MBSE/UML or Rhapsody training or customizations then email me.

Friday, 16 April 2021

IBM Engineering Rhapsody Tip #97 - I can't get no Satisfactions (creating a browser view)

I'm keeping towards the magic 100! This IBM Rational/Engineering Rhapsody tips and tricks video shows the simple steps how to create a new browser filter that shows whether requirements have certain coverage in a model. I show that it works with both requirements in the model and remote requirements in IBM Engineering DOORS Next Jazz application. It's silent though hence if you fancy strutting your stuff then feel free.


The following is the transcript for those that need it:

The theme for this Rhapsody tips and tricks video is the Stones' "I can't get no Satisfaction". It's silent though, hence you have to sing it yourself. 

Rhapsody has a bunch of standard browser filters, e.g., filter browser to Requirements View. But look, there are some non-standard views listed here! E.g., which requirements are covered, and which requirements can't get no satisfaction?

If we add a Satisfaction to the model and save, then the requirements are removed to show they're now covered. Adding such views can speed up requirement tracing.

These custom views were added by one of my profiles. 

Let's have a go at creating the "no satisfaction" one from scratch ;-) First off, I'll do it in a profile, a special type of UML package for customizations. 

I'll create a Query element. Queries are like persisted model searches. We can define a search criteria, such as Element type = Requirement. If we double-click a Query then it runs a search in the model.

We can build a compound filter, e.g. Reference. Find elements that have exactly zero incoming relations of type Satisfaction. The compound filter is now looking for requirements that don't have satisfaction relations. Double-click enables us to test it.

What's more, the Model::Query::ShowInBrowserFilterList property is set. This means that our new Query - AintGotNoSatisfaction is listed as a browser.

Worth noting that these queries also work with remote requirements. These requirements are in IBM Engineering DOORS Next. With DOORS Next requirements, adding a standard dependency allows us to create an OSLC Satisfaction and the requirements has been removed from the filtered view of unsatisfied requirements, i.e., I can't get no satisfaction! ;-)

Interested in MBSE/UML or Rhapsody training/customizations? Email me.