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.
Tuesday, 20 July 2021
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.
Saturday, 3 July 2021
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.
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.
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.