Sunday 31 December 2017

Mastering MBSE with OMG SysML and IBM Rational Rhapsody updated to Rhapsody 8.3

Phew. Just finished updating my 3-4 days of my IBM Rational Rhapsody MBSE/SysML hands-on training material (that's 560+ slides of tool training) to Release 8.3 to make a Version 6.

Rational Rhapsody 8.3 was released 04 December 2017. Update was relatively straight forward. Main impacts were:
- 8.3 offers a new xml-based file format, hence unit file extensions are appended with an x (e.g. .sbsx, .rpyx). You get a choice to upgrade when you open a project which results in files with the new unit extensions being saved (the old ones remain hence I had to manually clear these out which is easy but worth knowing)
- I did need to explicitly make rhapsody.exe the default application for new .rpyx file extensions.
- I'm following up on a few things with queries that are no longer working.
- The Format and Display Options dialog have been fused for Classifiers. I felt this leads to improved usability, e.g., much easier to enable the Quick Navigation icons (although multi-select doesn't fully work for things like compartments).

In summary, I think 8.3 is an improvement over 8.2.1. Actually some fixes to 8.2.1 proved useful (mainly word-wrap issues that were fixed). The fix list for 8.3 is here. I expect that an iFix will cover a few of the above (like the file extensions one). I'll post when I know one is out.

Friday 22 December 2017

Rhapsody Tip #28 - Using explicit vs derived configs to define what to build (Intermediate)

Here's a another video for you.

I sometimes get asked to explain how to define what to build for a Rhapsody model simulation. You can do this either using global parts (which exist in the browser) or using a composite structure, i.e. a Block that has parts which are then connected together. The latter is actually the more powerful as you can tell Rhapsody to derive the bits of the model to build using the "assembly block". Using the property called HighlightElementsInActiveScope you can see in the browser which elements are in active scope, i.e. will be built. This video hopefully explains.

I tried to make the model festive! Happy Xmas!

Thursday 21 December 2017

2 day tool-neutral SysML training

Based on a couple of private deliveries I have decided to begin advertising a 2 day Understanding SysML notation for productive MBSE course. This is really focused on people new to MBSE who want to get an understanding before they look at a tool. They can actually be quite fun. There is a lot of team-working using white boards and I teach all theory from the tool training (e.g. understanding the difference between include vs extend on use cases, aggregation vs composition vs association, associations vs connectors, ports/parts etc).


Wednesday 20 December 2017

8.3 What's New: Display options dialog improvements

On the subject of Rational Rhapsody 8.3 changes I thought I'd post stuff as I find it (for your awareness more than anything).

Other than the obvious (it now saves model files in an xml format) it's worth noting that the Display Options dialog is now vastly different.

Rhapsody 8.3 is released (6.0.5)

For those that don't know Rhapsody 8.3 was released on 4th December 2017:

I have big hopes for this release. Most significantly it aligns with the Jazz 6.0.5 release that heralds the introduction of a new Jazz application called Jazz/am that is licensed for users that have Design Manager licenses. Although the abbreviation is /am to align with the OSLC "Architecture Management". Essentially this is modified version of RTC for model management called Rhapsody Model Manager (or RMM for short). There is some summary information on here. For those that don't know what OSLC is there is a summary video here. It's about publishing lifecycle data as URLs and linked them without moving data and making this standards, non-proprietary based.

Bare in mind that the IBM Announcement Letter for 8.1 stated that "Design Manager is now part of Rhapsody Developer and Rhapsody Designer products" so if you have Developer or Designer products under maintenance then you have the ability to generate DM licenses and thus use RMM without additional cost of RTC licenses.

In essence this means that it's possible to use the powerful SCM capabilities of RTC for modelling, such as component-based SCM, repository-based private sandboxes for review, stream-based SCM, without needing to pay for RTC Professional licenses. It also means that some of the deployment aspects such as getting Rhapsody models to publish OSLC resources will be simplified, as it will be built-in with the RMM application model saving.

The IBM Help pages for 8.3 are here. Remember that if you want to google for Help or Topics on Rhapsody that if you pre-fix with "Rational Rhapsody" then chances are that you'll get a good return on your search. You don't pre-fix your google search then think Freddie Mercury. On that subject check out these 20 versions of Bohemian Rhapsody. I like the Muppet version the best.

Friday 8 December 2017

The Why, What, How, and Who of requirements writing...

... it's interesting when I talk to many engineers how they struggle with the concept of raising their thinking to a systems, rather than implementation level. Of course, this is a well known struggle within the world of good requirements writing. The ability to define hierarchies and separate customer/stakeholder need, for the how the implementation will full-it, gives the solution architect the freedom to choose and explore alternatives. Of course, the same thing happens with model-based systems engineering...

Here's one way to think about it.

In Scott and Long's MBSE Primer I quite like the way that they talk about 3 systems:
1. The system as it's perceived by the user (the Context System)
2. The design of components that realise the emergent behaviour (the system under design)
3. The designing system (i.e. the system being used to do the MBSE).

We often talk about 1 as being the Black-box system, 2 = the white box, and 3 = the process/method/people.

Of course, the way we model the context system is at a level of abstraction above that of white box modelling. This abstraction enables us to manage complexity. If we don't know how the user will use the system, then the chances of us being able to define the internal communication in the system is slim (at least if the system is new this is the case).

Another way of thinking of this abstraction is the why, what, how and who.

Take unlocking a vehicle use case, for example.

The first level to consider is the Why?

We can state the why, i.e. the goal, regardless of the what, how and who: The Driver needs to be able to secure their vehicle from theft. There may be many ways of doing this, of course. Conventionally, one uses a lock, but that doesn't mean that a water cannon that automatically fires when anybody else gets need, would not meet the same objective.

At the user interaction level we might define what a system does. For example, when I unlock the car, I expect the lights to flash.  This behaviour is emergent behaviour realised by multiple components, hence we can consider this to be a functional requirements of a system. The system includes a vehicle and a key. This is essentially a statement of what the system does. System level behaviours are black box requirements. They are realised by multiple components that are not realised by any individual component.

Below this level, is the white box. Perhaps we can think of this as the how (and maybe the who). Which components do what, and how do they communicate to achieve the black-box system level requirements. At the how level we can start to model the internal interactions of the system and allocate behaviour and logical interfaces to individual components.

Another way we could use the Who, of course, is to think of the 3rd system that Scott and Long consider which is the system used to create the system. Perhaps the Who is really the identification of the requirements and behaviours in the components of the system as these components are ultimately defined around people, i.e. as system engineers we write requirements at component level so that we can allocate work to people with some confidence that the work they complete will be valuable in realising the system requirements.

Each of these layers, is a lesson in abstraction. Without abstraction we cannot manage complexity. Abstraction is our friend.

Presentation on adapting Harmony/SE process for automotive

This was the presentation I did at INCOSE ASEC 2017 for any who might be interested.