Month: February 2018

On the road again….

Last week I was on tour in Germany by car. Not by myself but together with Andreas. That makes traveling a lot more fun, alone is OK but with someone to talk to (or to listen to Jazz on my Burmester…) is a lot cooler.

S-class Burmester speaker

First evening stage was from home to Bückeburg. Sunday evening is perfect for driving, it is quit on the road and trucks are only allowed on the street after 22:00u. Then the next morning early to Stuttgart but via Karlsruhe. We had a visit to a partner company, show them our AUTOSAR solution. then to Stuttgart for the hotel.

Next two days was at an automotive customer to help them using Rhapsody to create the architecture for some very cool stuff. Sorry,…can’t tell you any more… sometimes stuff must be kept secret….

During that 2 days I came across an old friend, the Publisher-Subscriber Design Pattern and I decided to write something about it.

Design Pattern

Publisher Subscriber is a design pattern. A design pattern is not just a library function, it is a standard way to solve a problem, you can not give standard code for it but you can give example code that you must adapt to implement in your own realm. (Not always, due to clever inheritance it is possible to give some standard stuff for OO languages.)

What is PS (Publisher – Subscriber) ? It is just what it says. Somebody publishes something and somebody else can subscribe to it.
Suppos you have a button in your system and you want an event when the button is pressed. Easy, just do a CGEN (me->receiver, evOfInterest() )….
If it only were that easy… Of course this is not a solution, you probably want to re-use the button in other applications. If you have solved it like this, you have to change the button each time you want to re-use it. Better is to let the button be unaware of anything from the application and:

Reverse the Relation

Yes. The application should have a relation with the hardware and not the other way around. The hardware should have a “subscribe()” function that allows an interested user to be notified when the event of interst comes by.

*^@#$&*( “C”…

Yes… the old “C” fan starts to see the advantages of “C++”… “C” definitely has its uses but design patterns just work so much easier when you have encapsulation, inheritance templates and overloading.

A very cool example of ‘C’…

The publisher subscriber pattern works as follows, you have a publisher that “publishes” a certain service, let’s say a button can be pressed, you can “subscribe” to that press. This is done by a subscribe function where a function pointer and (We’re using Rhapsody in”C”!) a “me”-pointer are passed. The function stores them in attributes and can call the function via the pointer. Sounds easy but there are some caveats. You have to know the signature of the function to “type” the attribute and the subscribe functions’ arguments. This is a bit awkward since you can not “just” take any function, your compiler will protest. Also the “me”-pointer has to be of type “void *”, you can never predict which object it will be. Depending on the compiler you need some casts… not really elegant.PublSubsc

Elegant C++

Compare that to “C++” where you just create a Publisher Class that has a relation with a subscriber class. The publisher Class has the “subscribe” function that has a pointer to the class as argument. This will be stored in the “Subscriber”, that has an abstract Notify function that needs to be implement in the inheriting class (Since it is abstract) 
You can use the subscriber type as a template and you have a ready made function that works for most cases. You only have to adapt the subscriber function but you can even make multiple functions with different parameters, the compiler will help you.

To make life easier I have put this in a Rhapsody 8.2.1 model, download here: PublSubsc.
As always: If you need an older Version: please respond.

That was it for today! Happy modeling with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)

Muenchen

This week I was in München again. We have lots of customers there so traveling to Munich once and a while is unavoidable.

This time I went there by plane. There are more possible ways to go to Munich, plane, train and car. I let it depend on the starting point (from Home, which is 150km further then from the Office) The weather forecast (not very good, snow and ice) and my own personal feeling at the time (don’t wanted to drive far) So… KLM, do your job…

This time they did, no snow or wind to cancel the flights. And then flying is pretty easy for me. Just hop on the train in the city I live, check in (Yes… the Netherlands have a “public Transport Chipcard”. Just hold it against the check-in pole and it beeps. Check out again 1,5 hours later at Schiphol and you’re done. Eat your heart out, Germany…..

Flying went fast and comfortable. I like flying with KLM. In Munich I took the S-Bahn to the hotel. Always a challenge to find out where to go and which train you need. Giving the right directions in the right dose is an art, Munich does not have that.
But OK, München is OK. I don’t like their football team (at least not “that one”) but the city is cool. So I arrived at the hotel and checked in. # days of AUTOSAR modeling before me, later more about that!

Rhapsody 8.3

Almost in Nikolaus day (December 6) IBM released Rhapsody 8.3. As I already mentioned before: If it ain’t broke, don’t fix it….
If you really want to update: please wait until we have tested the release and determined the parts that require special attention.
In a complex world, development environments are becoming more and more complex. Even small changes can have large consequences. Here I will give you a heads-up on the changes and some caveats we (and a helpfull customer!) have already established.

File Format and extensions

To allow a better integration in the Jazz platform, IBM needed to change the format that Rhapsody uses to store its models. until now that format was propriety (but working quite well) IBm changed that to an XML format. To indicate the change they changed the file extension (Like Microsoft did in Word and Excel, the went from .doc and .xls to .docx and .xlsx) Rhapsody files now also have an x behind it (.rpyx, .sbsx, etc)
This seems like a minor issue but is deadly when you want to keep your historical information in your config management files.
Some CM systems allow you to change the name of files but you have to do that by hand. Not a small job if you have large models….

Not new

In fact, the new database format was already there, it was just optional in version 8.2.1. It was there in the release notes but it was not really noticed. To be clear: I like this change. But it is a complex one, it takes time to solve all the pieces of the puzzle.

DiffMerge

OK, a new file format. Does that work with DiffMerge? The good new: Yes it does. The bad news: it only saves as .<file>x. converting old into new.

Save As?

The question that comes up immediately is: Can I still save in the old format. Yes you can! Like all (since 7.4) Rhapsody versions you can do “File”, “Save As” and then go back 2 Database versions. I don’t have an official statement from IBM yet but to me this looks like this option will be gone after 2 more releases.

When to update?

So this does not bother you? And you want to update to 8.3 anyway. Well… don’t do that yet. Certainly not if you use Eclipse (Plugin and Workflow), there have been some issues there.
There has been an iFix already but that did not solve all problems. IBM is working on this with high priority but it takes some time. I’ll keep you posted.
If you also use the RXF you also have to be a little patient, we have to test it first. Check our download portal, we keep you informed.

Happy modelling with Rhapsody (8.2.1)

Walter van der Heiden (wvdheiden@willert.de)

Introduction

The coolest thing about traveling: you always learn new stuff. Not necessarily about modeling but also about the cities and countries that you visit. I had to do work in the nice city of Nantes in France for 3 days. Nantes is about 1000km through the air and a lot more in a car or by train so we took the plane.
When flying, you have the choice when you’re on location, hire a car or use public transportation.
I’ve been to Nantes before and I remembered that they had Uber there and that the traffic is not really “my style” so I decided to do that. The Uber driver told us a lot about Nantes and one of its famous inhabitants: Jules Verne. There is even a museum there. Also there is a warship museum in the harbor where the film “??” was recorded. Not that we had time for that… but nice to know for the next visit.

What Diagram shall I use?

As long as you use UML to document your software, it does not really matter which Diagram you use for what. It does not even matter if you use the UML correctly. Or even worse, you don’t know while you cannot check if you use the UML correctly. At least in Rhapsody you can generate code to check if your model does what you specified. But there is enough left to do wrong… you can only generate code from Class-, Object-, Package-, State-machine- and activity Diagrams.

Admitted, the UML is not clear on when to use what diagram. The argument for not having that is that it is a programming language. “C does not tell you when to you which statement either”. Correct but if someone else does something in a certain way, that does not force me to do the same….

So the UML lacks a “process” that divides your development in stages with deliverables and rules on what to use when and how.

V-Model

The V-model is still used widely in software development. As it should be because it is a proven way to develop software. The exact way it is used changed over the last decades. From a waterfall model where each stage was finished completely before starting the next to the agile process we use now that makes the V-model more a system where you store your development artifacts.

Process

There are numerous processes that describe how to develop software. Some of them are more common and some of them specify UML or even Rhapsody specific, like IBM’s Harmony. Older processes are still used like RUP from rational, Ropes from Bruce and many more like Automotive Spice (a-spice)
You don’t need to try and follow these processes, you can use them to describe your own process. How thorough you do that is mostly depending on the safety level of your software. Railway systems or cars or planes have huge processes that require really thoroughly described steps.

Requirements

When you don’t know what to do, you cannot do it. So you first have to be clear on what it is that you are building. This is a difficult part for experienced software developers… We (Yes I am a software developer…) are very solution oriented. If somebody describes a problem to us we immediately start to think solution. Write down the real requirements of your product. Concentrate on “What do I need” not on “How do I do that”. You can use a Requirements Management Tool like DOORS (Next) of Polarion or even Word or Excel (Not good for linking and traceability but will work)

May be you are lucky and you will receive the requirements from your stakeholder, like in the Automotive industry.

Then import the requirements in your UML model. In Rhapsody you can use either the Gateway of the Willert RequirementXChanger. These tools will create a package with your requirements. They can even synchronize them if the requirements change and mark the changed requirements accordingly so you can do impact analysis on changes.

What diagram should you use for requirements? That is a good question since the UML does not know a requirement diagram. There are a couple of possibilities in Rhapsody, you can stereotype an OMD (Object Model Diagram) as a new term “Requirement Diagram”. Very elegant way, Rhapsody creates a category for new Terms so that you see them as a folder in the browser. Another possibility is to not show the requirements on diagrams but to create a table where you have the requirements on one axis and your linked model elements on the other. Have a dependency with “trace” stereotype as cell item and you can link requirements very easily. Also possible is to drag your requirements in the diagrams where you have the model elements that you want to link. This will make your diagrams messy but there is a solution for that too! You can apply filters (actually queries) to your diagrams and blend out certain elements.

Analysis

The next step is to analyze your requirements and create diagrams where you extract behavior.
The Diagram of choice here is a Sequence Diagram (At least that is my opinion) The nice thing about Sequence Diagrams is:

• Even non-techies understand SD’s
• They are easy to draw
• They can be used for tests!

You just start drawing the first diagram by treating your system as a black-box, defining what output you expect for certain input. You then create new SD’s by refining the first one  in horizontal way (splitting up the system in sub-systems, then sub-sub-systems until you are at Class level) and vertical way (split the functions ins sub-functions and so on…)
You can use Class Diagrams (Or Object Model Diagrams) to already start drawing your system architecture that you find out when drawing the SD’s.
Some use Activity Diagrams or even State-charts for this part. There is nothing against that, I just don’t like it. Activity Diagrams are more or less OK but I think State-charts are just too complicated and distract your mind too much during analysing your system. Also if you need to speak with non-technical people about the exact requirements of the system, State-charts are much less “natural” to use.

Design/Implementation

Here you use the same diagrams as in the Analysis and now it is time for state-machines. Together with the state-machines you start creating tests for all your sequence diagrams, in that way you can immediately test if what you have created is correct. And even better: you can do so whenever you have made changes.
This allows you to do Analysis/Design/Implementation in a sort of spiral model. Just keep adding small pieces of functionality, keep starting automated tests (using Test Conductor) and you always have a working system.

Some pictures from Nantes

That’s it for today, happy modeling with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)