Rhapsody Tip #6 - Using a guard-based STM pattern (Advanced)

Occasionally, I want to share some advanced tips and ideas. Sometimes in real-time systems development it can help to capture more continuous behavior in an STM, particularly in automotive. This 2 minute advanced video contrasts two executable MBSE state machines drawn in Rhapsody.

The first State Machine uses a conventional Harel Statechart where the transitions are triggered by asynchronous events. The second shows a different pattern that only uses [guard] conditions to trigger transitions. It shows how a parallel region in Rhapsody can be used to trigger the null-triggered transitions in other parallel regions.

Thinking outside the box

Let's consider this thinking inside and outside the box thing again... 'I'll tell you what I want it to do and you work out how it's going to meet my needs'. The reason we write requirements, after all, isn't because we like writing. It's because we want someone else to do something. Specs are a way we can try and conduct the work of multiple teams working in parallel. The intent being that when they all do their job well, we'll end up with a sum of parts that actually mean something. The same patterns apply to good MBSE with SysML.

The trouble, of course, is that systems engineers are engineers. They love the Chocolate of actually designing the system. Sometimes they can end up thinking inside the box, whereas perhaps they shouldn't. In some cases it's their role, but in other's it's not. Solid division of responsibility on the other hand allows us to get multiple teams working together in parallel. The simplest way by far to separate concerns between teams, whether internal or external, is for one team to work on what happens outside, while another team works out what happens internally, i.e the inside/outside the box division. This is very easy with diagrams in SysML such as Sequence Diagrams and Internal Block Diagrams, and arguably one of the key differences between how SysML techniques are applied in systems engineering vs how UML has been historically applied in software design.

Rhapsody Tip #5 - The General::Model::BackUps property (Simple)

Just one of a thousand useful properties, did you know that this property can be set on a model to get it to save a copy of the previous version, every time you save? This can be handy to give you Backups when using Rhapsody "solo", i.e. without an SCM tool configured.

Rational Rhapsody JAVA API – Code Snippets & Helper Apps

Now, always remember if you're actually looking for Rhapsody tips and tricks on the web, then the tip is to prefix Rhapsody as 'Rational Rhapsody', and you may get lucky.

Forum's and google doesn't tell you everything, for sure. But here's a useful link for those writing Java helpers for IBM Rational Rhapsody that's on the IBM website.

Forget the Rational and, yep, it's 1975 again, probably ;-).

Systems Thinking

What is systems modelling? At what level of thinking is MBSE done? Let’s take the analogy of the Game of Chess.

As a Pawn, I may think that I understand the game. I can see all the other players on the board (well most of them but sometimes I have to stretch). I know the moves each can make. But, as the Pawn, do I understand everything that is in the Chess players head? Well, I’m not sure. There’s the whole bigger picture about the current game-plan, the strategies like Fool’s Mate and the Fortress Endgame, the tactics for countering the opposition, and fooling the opposition.

As the Chess Master in a game I see the bigger picture, the tactics and the plan, I’m at a different level of abstraction. Both levels of viewpoints are abstraction, of course, and both valid. However, I can do things and see things at the system level that are not possible at subsystem level. Then there’s the question about why the Chess board is like it is? Does every Chess Master understand why Chess is like it is? Well, probably, but imagine they don’t. Imagine Chess was not invented and were trying to come up with a game. What characteristics do we want the game to have? Perhaps we want a game between two players, a game that mimics the tactics of battlefield, a game of cunning, a game that has evolved from other games...

All these levels of abstraction are valid. They are all about the same system. However, they are at different levels of abstraction. This is one view of what successful modelling can provide, if you embrace systems thinking. Of course, there are other views of MBSE but for me the trick is to have multiple views that are all valid and all useful with no duplication. That's an art not a given.

Rhapsody Tip #4 - Applying format using a stereotype (Simple)

This basic-level technique I use all the time. I've seen many engineers make great use of it. The most recent example was a requirements engineers who wanted to differentiate 'User Interface' requirements from other requirements on the same diagram so that the guy from the HMI team could pick them out with ease. Another example is for «abstract»  use cases. By making the text Italic and shading them I can place more focus on the concrete use cases.

Interesting Automotive MBSE paper related to Ford

I really like hearing about real-world usage and lessons learnt. Christopher Davey's paper from an INCOSE 2013 (USA) MBSE Workshop on Jan 26-28th is interesting. It talks about Automotive MBSE at Ford (EE Systems). The PDF is on the OMG Wiki.

"These forcing functions lead to the need to support a HYBRID MBSE environment that consists of a set of modelling tools with associated style guides, maturity levels, completeness levels" (p33) is what I took away; particularly when it comes to reconciling the different worlds of PLM BOM-centric vs SysML/UML/Software is-the-future ;-)

Rhapsody Tip #3 - Deleting Events and usages in one step (Advanced)

This super short video shows how it's possible to use a custom Helper written in Java to automate the deletion of Events and related EventReceptions and diagram references. Helpers like this can simplify usage in increase a team's productivity by removing repetitive tasks.

This helper is part of the toolkit delivered with the training we offer.

How soon do I need tool-specific vs non-tool training/consulting?

The adage that “tool-training is not necessary” is sometimes aligned to the propensity to believe that "the production of diagrams is more important than the engineering content behind them". The reality is that the sooner you get you engineers focused on the latter, the better. It's my experience that this naturally happens if you remove questions about how to use the language and the tools by delivering tool-specific SysML training.

It’s not uncommon to go into companies who have been trying to use Rhapsody and SysML for 1-2 years without training. They think they don’t need it. They believe they are doing OK but you see immediately that they are exploiting only a fraction of the tool and languages’ capability.

Contrast this with those who do the training at the start of their journey. If you do training at the start, you start with relative expertise and understanding of what can be achieved. Empowered with knowledge you make better choices sooner. By unlocking the potential from the start this helps to show to everybody what can be achieved with a few clever choices. People will bow to your superior knowledge. Everybody will want to be part of it. Because you’ve done the training, you now understand that training is valuable. You ensure that training is included in tool deployment. People naturally end up focusing on the engineering issues and problems, not on how to use the tool or exploit the language, and the circle is complete. Well, at least, that's the hope ;-)

Rhapsody Tip #2 - Allowing spaces in names (Intermediate)

This quick tip video shows how you can use the NamesRegExp property in IBM® Rational® Rhapsody® to relax or change the naming rules. For example, to allow spaces or special characters in element names of things that it would not normally allow.

This can also be useful for action names; particularly when we sync them into Rational DOORS® using the Rhapsody Gateway add-on.

Rhapsody Tip #1 - Using the Alt key when resizing (Simple)

Here's a simple Rhapsody usage tip for you: If you want to re-size a container without re-sizing the elements inside it, then just hold down the Alt key first.