Thursday, 13 July 2017

Executable MBSE webinar planned for IBM on Wed, Jul 19, 2017 4:00 PM BST

https://register.gotowebinar.com/register/4742377653032506369

Wed, Jul 19, 2017 4:00 PM - 5:00 PM BST
Show in My Time Zone
Presenter: Fraser Chadburn, Trainer/consultant in Rational Rhapsody (currently working in automotive)

Fraser will demonstrate creating an executable “concept of operations” OMG SysML model from scratch with requirements traced in DOORS. He will use an open-source alternative to the Harmony-SE toolkit and explain how it has evolved slightly differently in order to fit with the experiences he's  seen in the automotive market. Advanced and exploratory techniques will be touched on such as using Object-Orientated inheritance of black-box behaviours, coping with iterative and evolving use case models, as well as use of tool automation to reduce training needs during deployment. Aligning SysML/UML usage to the graphical notations familiar to automotive control engineers expectations, using state-based behaviours with continuous conditions, flowing data between controllers, and automatically building test plans/cases from executing the system specification will be touched on based on aspirations to use standards-based SysML modelling in automotive feature development.

Friday, 30 June 2017

Rhapsody Tip #23 - Enhanced usability with Quick Navigation icons in 8.2.1 (Intermediate)

Being able to navigate between diagrams, including drilling back and forth through hierarchies of diagrams is increasingly important for systems engineers and SysML in general (and is also important in UML 2.x which introduced structured classes). In this video I show a new feature added to Rhapsody 8.2.1 (June 2017) called "Quick Navigation" shortcuts.

As illustrated in this short video, this new feature is enabled by setting the General::Graphics::EnableQuickNavigation property. The categories of displayed types can then be tailored for individual diagram or element types using QuickNavigationCategories properties for different meta-classes/diagrams. Further refinement is also possible using the Compartment tab of individual graphical elements, resulting in quite a cool new usability feature that is easily enabled (with a certain amount of power behind it for advanced users to play with). A very welcome addition to Rhapsody for both UML and SysML users ...


Sunday, 25 June 2017

Rhapsody Tip #22 - Why you can't draw connectors between Blocks in SysML (Intermediate)

Another Rhapsody SysML/MBSE tips and tricks video!

Understanding the difference between Blocks and Parts (and thus the difference between BDDs and IBDs) is a massively important topic for a SysML practitioner and something that very few Rhapsody users with no training will guess their way into (I'm forever finding users who try to draw connectors between Blocks, give up, and choose to use Flows instead!).

The whole Block, Part, Port/Connector capability of SysML (and to some extent UML) is really powerful though. This video tries to shed some light on the typical question: Why can't I draw a connector between ports on two Blocks? The video is using IBM Rational Rhapsody 8.2.1 (released June 2017)

















p.s. The topic of which ports to use is a whole different ballgame ;-)

Tuesday, 20 June 2017

Rhapsody 8.2.1 was released on 12th June 2017

Just so you know, v8.2.1 of IBM Rational Rhapsody was released on June 12th. The IBM page for release notes etc is here and includes a Whats New overview. There's quite few usability things that look good, e.g., Diagram: back and forward navigation button improvements, Diagrams: hover Drawing toolbar and Diagrams: new layouts for Populate Diagram and Rearrange. Some videos will follow. Rhapsody has significant releases roughly twice a year, hence there are 6 months of development time in 8.2.1 compared with 8.2. (my understanding is that development team has also invested more effort - with a particular focus on usability).

I've updated my download and setup Rhapsody Designer for MBSE setup instructions to align, see below. Note fully tested all the training against it but initial tests didn't indicate any show stoppers so I will start update soon (so that all my Rhapsody training is on the latest!).


Sunday, 4 June 2017

Executable MBSE and SysMLHelper updates

As an update the SysMLHelper has recently had a couple of updates (latest is v2.1.g). Aim is to finish testing in next 2 weeks, hence it's possible I'll do a couple more updates. These mainly relate to speeding up workflow on the "straight to white-box" modelling workflow. I'm posting details to http://www.executablembse.com/ and preparing a tutorial for this.

Monday, 1 May 2017

How important is the tool choice?

I heard an interesting analogy recently from someone who was describing how your needs from a tool change over time. For example, when you first go to University you need a fork, knife and tin opener (and a glass). The things you cook may be limited but you learn about cooking over time. When you get your first house you may invest in a set of cooking utensils. If you really like cooking and you have the money you might splash out on some great knives.

It's a nice analogy but there are a few things to consider. Usually when one makes a modelling tool choice it's something you learn to live with because changing tools is difficult and people begin to invest their time, i.e. it's not simply the case of buying a new set of tools as there are people to consider (for example, the manager who stuck their head out to get the money approved).

While you might consider the modelling tool to be a set of knives there is also the bigger picture about the kitchen. For example, IBM doesn't sell knives, it sells kitchens hence a lot of people using a tool like Rhapsody are in big companies where the kitchen is in play, including wider issues such as interfacing with change management and requirements management tools.

I prefer to think of the analogy of a boat that you intend to tend you down river. You could choose a canoe or an inflatable raft. The chances however is that when you hit the rapids you won't have the luxury to change tools. You'll just have to hang on. That's not to say that your tool won't carry you there. You'll just need to take the rough with the smooth.

Something to remember though is that modeling tools are very different in their architectures. Some are repository-based, some file-based, some use Relational databases, some - like Jazz/Design Manager - use an ontological database. Some even have a file-based and repository-based option (Rhapsody, for example).

Chances are though that you won't find out the real differences until later. That's not to say that one tool is better than another. For example, when I was product manager for Artisan Studio one of the great things was how easy it was to collaborate on the same model as it had a Object-based database with very fine granular locking. This of course has benefits and disadvantages (e.g. what happens over a wide-area network?). Rhapsody has some really sharp aspects. Simulation is one. Configure-ability is another, or working with SCM.

The thing is whichever tool you choose, you're provably stuck with it for a while. I'd recommend therefore that you learn it very well (or get someone that does). Play to your tools strengths but don't be surprised if at some point you see others shooting down the river on different boats, at different times, or occasionally you find you need to portage a waterfall in a few years.

Tuesday, 18 April 2017

4 Different Representations for Use Cases in OMG SysML/UML

This 6 minute video uses one of the example models from my 3 day Mastering MBSE with OMG SysML and IBM Rational Rhapsody training. I actually speak!

It shows 4 different forms for how use cases might be represented in SysML or UML: namely structured text, an activity diagram, an interaction model with sequence diagrams, and as an executable state machine model. The cool thing is that we’re free to use whatever you like. Neither SysML nor the UML specify how a use case shall look. The main thing to consider is that use cases take on a journey from analysis to design! Through-out this journey we will meet different people with different needs and levels of knowledge. We need to consider their needs, recognizing that different stakeholders will have different needs, and that needs will change over time. After all there is little value in building an executable state machine of a system, if a simple review of the use case description can determine that it is not what the customer wants after all.