The Blog for Rhapsody (Power) Users.

Month: July 2017

Who needs documentation anyway?

Yes who?

Everybody of course. Don’t be daft. I know software developers hate writing documentation. Why do i know that? I am a software developer myself… takes one to know one.

But when using Model Driven Software development, documentation is not that hard anymore. In fact, you are writing documentation while you are developing, almost without noticing it.

Oh, don’t get me wrong here, it is not done fully automatically, you have to do the right things, like putting effort in the way you build up your model. When you don’t, the same happens when you write source code without documentation.

It is fully possible to create a working (meaning: the code you generate will do what is expected) UML model from Rhapsody without a chance to understand what is happening by reading the model. Or as we used to say: you can mess up things pretty bad but to really screw things up requires a computer…

So. Let’s assume we modelled the right way. Now what? The boss wants to see what we did and I have to present the model for him/her on paper. How do we do that?

Well: Rhapsody offers multiple ways to document your models and make the information available to others.

  1. Use Rhapsody. Sounds a bit awkward but the best way to look at Rhapsody models is with…. Rhapsody. Don’t start with: But that is too expensive… there is an Architect Version that suffices for viewing the model for about € 600,- But a tiny bit of knowledge about models is required so that might not be the 100% solution.
  2. Use Reporter. It’s free. And it does documentation! So where’s the drawback? Well… it does documentation but that;s about it. There’s no formatting, you can only decide on a high level what will be in and what not, it’s just in RTF, no other formats and you can edit the documents but they will be overwritten when you regenerate them. So…. only limited use.
  3. Reporter Plus, is the version that costs. I’m not sure what the price is but since you ony need one, normally, that should not be a problem. This can write Word, PowerPoint, RTF and even HTML (with javaScript). The last format is pretty cool, it can build a web version of the model where you can click your way through as if you are using Rhapsody. The creating of the documentation template is a lot of work but not really complicated. Can document what and how you want.
  4. Publishing Engine is the successor to the Reporter Plus. Can document data from multiple tools, that can be quite handy when you also use Doors or other IBM Tools. Must also be purchased , but again, mostly only one license is needed. Is also not too complicated but a lot of work to make perfect documentation.
  5. Another method is often overlooked. But is sometimes the best way to do stuff. The Rhapsody Java API! It can access the model, it is built-in, (for free!) and is not too complicated. You are free to create any doc you like.

So. I hope this helps you in deciding how to document! If you have any questions, don’t hesitate to ask!

Happy Modeling with Rhapsody

Walter van der Heiden (wvdheiden@willert.de)

 

AUTOSAR meeting Juli 2017 Paderborn

The planning was to have a more quit week with less travelling. As usual, this did not work out well. As my good friend Bruce always says: The difference between theory and praxis is a lot larger in praxis than it is in theory. No problem, I’m used to that.

On Tuesday, at least that is what Clemens thought, we had a common AUTOSAR Meeting. We are AUTOSAR Premium Member (by proxy of Sodius) so we visit the meetings and we try to influence the process of the AUTOSAR specification.

So on Tuesday morning very early we drove from the apartment in Bückeburg to dSpace in Paderborn where the meeting was held.

There it turned out that Clemens made a tiny mistake. He assumed that all meetings had the same footprint during the week which was wrong. (As _I_ always say: Assumption is the mother of all f***-ups) So after a Tuesday full of very very in-depth AUTOSAR workgroup meetings (and a nice lunch, thanks dSpace!) we drove back to the appartement just to go up very early again on Wednesday to visit the meeting we wanted to visit….

Anyway… shit happens. This way Clemens and I had time to discuss the Willert AUTOSAR solutions. Basically there are 2 AUTOSAR solutions, Classic and Adaptive.

Classic is for targeted at smaller controllers and very static environments. Base is that many system information and software (SW-C, Software Component) information is captured in an XML structure (ARXML) Tools can read that structure and use the information in there to configure themselves and to export their own added information to other tools.

Adaptive is targeted at larger systems that have dynamic components. Base is a Linux environment with many specs for security. It will (amongst others) be used by ADAS (Advanced Driver Assistent Systems)

What does that has to do with us? Well, Rhapsody is a tool as well and it is, out of the box, capable of reading and writing these ARXML files. You can then add information and work with the provided information. We think, however, that this solution is not applicable and scalable enough for a lot of customers. So we visit the meetings and have access to the AUTOSAR information to be able to create our own simplified AUTOSAR profile. (Apple Style, or better: Jobs Style, keep it as simple as possible, hide the complex stuff, make it usable for everybody but also make the complex stuff still accessible for Guru’s)

What we basically do with Classic is that we import ARXML and convert it to UML Elements right away. In that way we can use “normal” UML to develop AUTOSAR SWC’s.

Adaptive is very new and in early stages of definition. So there is a lot to do for us in that area, not only in profiles and frameworks but we can do a lot there in Rhapsody modeling, at least that is what we think.

So in the next weeks we have a lot to do. Clemens and I will be cooperating in creating / improving the Willert AUTOSAR Solution!

Happy modeling with Rhapsody

Walter van der Heiden (wvdheiden@willert.de)

 

Rhapsody Getting Started – part 1.

San José

The second part of this USA trip brings me to San José in California. I am joining the 10th AUTOSAR Conference there. The meeting is held in the Computer Museum in San Jose.
I think that’s pretty cool. Also in the neighborhood are Apple, Google, Tesla, the famous garage of Jobs&the Woz and the HP garage. When there’s time I will take pictures. But we will fly to Detroit very early on Thursday.. so there is only limited time.

San José is nice but very, very expensive. Hotels cost a fortune, the hotels that are affordable are really low-class. The weather is nice, about 20ºC .

 

Introduction

People ask me a lot of times: “Why don’t you write something for “beginners”?”
OK, good point. Let’s do something for beginners.

First: what are we going to do, what are we going to use.

  • Board: Infineon XMC2Go Board
    ARM Cortex M0 – XMC1100, 64k ROM, 16k RAM
  • Keil µVision IDE
    When installed without a license, this acts like an eval version with a 32k size limit: we can live with that! The Willert Frameworks are really small, a Blinky is only a few KiloBytes without optimisation. If optimising it’s just over 1 KiloByte.
  • Keil CMSIS2 RTOS
    Embedded RTOS that implements the CMSIS standard
  • Rhapsody 8.2.1, the latest version
    We use the ‘C’ or the ‘C++’ version. We will cover both languages.
  • Willert RXF for C or C++
    The “general” version of the award-winning Rhapsody Framework.
    includes the UML Target Debugger
  • CygWin/Visual Studio/Eclipse
    Some C/C++ compiler running on a PC, preferably a free one.

Second: The sequence of installing:

  • C/C++-Compiler
  • Keil
  • Rhapsody
  • Willert RXF

See Installing Rhapsody for more info.

Third: What are we going to make?

That’s easy, there is a Hello World equivalent in the embedded world. It’s called Blinky. We let an LED blink on the board, that is about the smallest complete program you can make that still has user interaction.

Getting Started

Now we have installed it all, we can start using the environment to create a project.

First we start Rhapsody. I always like to make a shortcut on the Desktop to have Rhapsody accessible always. In Windows 10 you can pin it to they taskbar. As you can read a in the Installing Rhapsody part, you can influence the version of Rhapsody that is started by adding command line options.

So the version we need to start is Rhapsody Developer in C++. You can start Rhapsody Developer in C if you like, i will describe the differences between these versions.

People that just start with Rhapsody often ask: Why do I have to choose a language when I start a new model? Why can’t I do that later. Well that is because Rhapsody not only generates code, it also accepts your own code that you type in. You can do that in operations that are in classes but also in state-charts and activity diagram actions.

So changing the language after a while would implicate that you would have to change your own code as well. Can be done, but is much work. Also there are differences in the language versions. Rhapsody in C cannot generate code for inheritance (only from Interfaces) and there are mode differences.

Luckily you never switch the programming language that often, where I worked we always decided which one we’d use upfront and stayed with it…

Now that looks pretty empty

Yes, it does. That’s why it’s now time to create a new model. Rhapsody works with models. Models as in representations of the real world not the models from the middle pages of certain magazines… We can open an existing model but for now we will create a complete new one. Can be done in multiple ways;

I don’t use the mouse often so I usually press CTRL-N. Yes, I like the keyboard…. I’m old enough. And now we are outing ourselves anyway: Yes I like VI…. But feel free to use the mouse if you like. You’ll become a small window that asks you to enter 4 things.

  • Name, the name of the model. You’ll notice that Rhapsody adds the name of the model to the path. So it will create a new directory for every model you create.
  • Path, where the model is stored. Non-existing parts of the path will be created (after asking…. after all this is Windows!) only if you create a new directory in the root directory, this cannot be created. It’s not Rhapsody, it’s a Windows relict from the past. Have I already mentioned that I hate Windows?
  • Project type, here you can select a profile to be loaded with the new model. The profiles have to be stored in a Rhapsody directory (and preferably have an accompanying text file with the same name that contains a description)
  • Project settings, almost the same as project type but adds a settings file

You should create a directory that you can find easy, preferably c:\work or something similar. This is the directory to filled in after “Path”. As Project Name you take “Blinky”, as project Type you click on select, then scroll down to the directory “WST_RXF_V7”, in there choose “RXF_CPP_V7”. In the Settings Tab, go to the same directory and choose WSTProfile

If you have filled in everything a new model is created.

OK… Now what?

You see an empty model [picture of Rhapsody GUI]

There are a few area’s on the screen.

  • Menu
  • Browser
  • Diagram area
  • Output Area
  • Drawing Menu

The menu is a partly straightforward, the stuff that visual studio gives you for free, but parts are Rhapsody specific. You can create and open diagrams and do a lot more.

What is the Browser? It is the view to your model. It contains all element of your UML or SysML model. You can select what you see in the browser by using queries, you can from the browser, create and delete model elements. Your Browser View will not be empty, it will contain some default elements and the profiles you have selected when creating the model.

The Diagram Area is logically the view on your diagram. Per default Rhapsody will create and open a diagram for you: An object Model Diagram named “Model1”.

The Output Area is empty until you start doing things like generating, compiling or executing code. Then the output is shown here, beware, it has multiple tabs.

The drawing menu is on the right and contains the elements that can be used on the currently open diagram type. Rhapsody has possibilities to add items to it or to limit the items on the drawing menu.

Repository

Or, as we call it, the browser. When a new model is just created, it contains a few folders.

  • Components, contain what you are actually creating with Rhapsody. Per default it contains a single component: “DefaultComponent”. If you double-click that’s window will open, the Features Window. All Elements in Rhapsody have a feature window, a double-click will open it. Even diagrams have features, only they are not opened with a double click but with a right-click and selecting “Features”. A double click on a diagram will of course open that diagram. The first tab contains the name and type (library, executable or other”.The second has a “Scope” that lets you select what other UML elements are part of this component.
    Under a component there is at least one “Configuration” (Default: DefaultConfiguration” . This contains the information about the target environment.
  • Object Model Diagrams, normally all diagrams are located under a package, like all other UML elements. But to make a model better accessible for others we need diagrams on the top-level to assure an entry in the model. You can (Actually you should…) add navigation info to allow for traversing the model from there.
  • Packages, the base of your UML Model. Packages are nothing more than folders, however they have influence on the generated code, some elements will be generated inside .c (or .cpp) and .h. You can organize your work by dividing it in packages and sub-packages. And sub-sub-packages, and sub-sub-sub-packages, and… you get it I guess.
  • Profiles, these are the profiles that were loaded when we selected our project type. It is, of course possible to load more profiles after you have created the model. Just use “File”, “Add Profile to Model”. Profiles are used to transfer a lot of properties in one go but also to include certain information in the model.
  • Settings, about the same as profiles, technically there is no difference. Then why? Beats me….

C or C++?

What is the difference between Rhapsody in C and in C++? There are a few differences which I will explain but there is also a lot that is the same. You can draw exactly the same elements, the generated code will differ. Also the code that you enter must be equal to the chosen language otherwise nothing will work.

‘C++’ is of course closer to the UML. It already has classes, OO, inheritance and a lot more. But Rhapsody in ‘C’ also offers OO. Here you see the same class code, in ‘C’ and in ‘C++’.

The Object orientation in C is done by using a struct to mimic a class. (Private members are not really private there, unfortunately.But in Rhapsody, the get and set methods are used to implement private, public and (only in ‘C++) protected.
Functions have the name of the class as prefix to prevent linking problems when 2 classes have the same functions. Private functions have only the name of the function and are “static” which makes them really private.
All functions have a “class * me” as first parameter to have access to the objects attributes.
Calling a function in C++: object->function();
Calling the same in C: class_function(object);

So. That was the start. Happy modeling with Rhapsody and see you in part 2!

Walter van der Heiden (wvdheiden@willert.de)

Code-centric vs Model-centric Development with Rhapsody.

Keep on dreaming…..

On the phone with a customer I noticed that the customer was disappointed in Rhapsody and in its ability to handle C source code that was externally written.
I always find it very difficult to deal with people who are not happy with the tools we sold them. But yes, it does happen sometimes and unfortunately, this was no different.

This particular customer wanted to use Rhapsody to more or less monitor his coding in C and in the meantime draw diagrams that represent his documentation. And also when it fitted better he wanted to draw in Rhapsody and then generate the C code according to his coding standard.
I never promised that such a scenario would work, I’m very sure, but this is what the customer understood from my words in earlier visits before buying.
I think that is OK, I am not offended, nor angry, nor do I take it personally. Customers are just as human as I am. I also hear what I want to hear and interpret until it’s right for me.
So, I do hear the ice cream man say: “I will be in your street today” and I do not hear him add: “but I wont be stopping…..” No problem.

The problem is that it I hate it when my customers are unhappy and I would like to change that but it I find it very difficult to transfer the correct information to a future customer during the sales process. Let’s give it a try here…

The truth, the whole truth and nothing but the truth.

NO! It is NOT possible! You cannot use Rhapsody and just continue coding C or C++ (or even Java).
Well… not entirely…. You can do some of that.
Is it any good? No, it’s not. Well.. it is OK but not more than that. If you just want to understand your fuzzy written code and expect Rhapsody to generate perfect UML diagrams so that you can understand some spaghetti code that you found on your hard disk: Keep on Dreaming. Never gonna happen.

As I always say: Reverse Engineering is a GiGo Process: Garbage in, Garbage out. There is no way that you can automatically make the incomprehensible understandable.
That is perfectly OK, badly written code should be re-designed and re-made….
(Yes, I know there are programmers that think otherwise…
– It was hard to write, it should be hard to read….
– Better write software with “built-in understandability protection” to ensure your pension plan.
…but I do not agree there…)

Now in C++ or Java the conversion to UML works reasonably well since these languages already support OO like UML does. But even in these languages you have to comply with Rhapsody coding, it is not a simple process. Reverse Engineering for C, however, is a totally different matter.
There are some YouTube movies in the internet describing RE in Rhapsody (see links at the bottom) but for these demo’s they all used Rhapsody in C++.
And there is a reason for that…

But before I tell you what is possible and what not in Rhapsody in C, may I gently remind you that Rhapsody is a UML Tool? Yes!, that is what it was built for. From the beginning in 1996 it was designed from the bottom up to be the worlds greatest UML Tool. And it is!
(It is possible that I am a bit prejudiced here)

For Rhapsody the same applies as for all tools: the best way to become happy with a tool is by using it as closely to the way the creators have intended it. The more you bend the tool to do things your way, the unhappily you will become.

I always tell that to my customers and to my future customers. Always. But funny enough nobody hears it. That is just not what they want to hear. They all want the holy grail of software developers: the tool that does exactly what you want without errors. And there is no such thing, sorry. But, enough ranting, let’s go through what you _can_ do.

(Re-) Using your code in Rhapsody

Basically there are 3 variants: Code-centric, Model-centric and Code-aware.

Model-centric:

This is the way to use Rhapsody. Your Model is the base of all. Code generation will generate your application. It can be compiled and linked to the framework (RXF) and you have a working application.
Code will be generated from Class and Object Diagrams, Structure Diagrams and from State-machine Diagrams and Activity Diagrams.
Rhapsody also supports flowcharts (Although these are NOT UML!) for the behavioral code of operations.

Code-centric:

Here you use Rhapsody only to visualize your code. You can change the code and Rhapsody can process it to reflect the code in your model and in (some) diagrams.

How does that work?

  1. Switch your Rhapsody to Code-centric. How?
    – When you are working in the Rhapsody Architect for Software your project will be code-centric by default.
    – In Developer (or EUSIII) you can add the CodeCentric profile via the menu “Add Profile to Model”. In the next file selection screen go up one directory and then go to “Settings”. There you will find “CodeCentric” (Or if you have a Willert Install, “CodeCentric_Original) and load the newest file with the correct language)
  2. You can now use “Tools”, “Reverse Engineering” (RE) from the menu to read-in the files that you want to use. Beware!: Starting RE makes changes to Rhapsody that might not be easy to revert.
  3. Things you can (or should) do before using RE:
    • Create a new Component
  4. Your reversed engineered code is now in Rhapsody. How does it look?
    • You will see Packages, Files with variables and functions.
    • These artefacts are NOT UML artefacts, they are introduced by Rhapsody to allow working with code.
  5. Rhapsody will generate OMD’s (Object Model Diagrams) with the structure of your files. If you have a lot of include files this does not really help.
  6. Rhapsody will NOT automatically generate Flow Diagrams (Activity Diagrams for functions). You can ask Rhapsody to do so (Right-click, “Populate FlowChart”).
    remember: there is always just one “leading” source. Either your code or your Diagram. Check your settings.
  7. The best way to use the reversed engineered stuff is to convert it to “decent” Rhapsody elements like classes and objects. It is a bit of work but the result is very helpful.

 

Code-Aware:

The “hybrid” form. Not really supported.

Problems and possible solutions

  • All the code-centric stuff is (current version is 8.2) only useable on 32-bit Rhapsody. 64-bit is improving but not there yet.
  • Don’t expect miracles. If your code sucks, it will suck in Rhapsody as well. No way around it.
  • Be prepared to experiment with re-reading in a new model. Sometimes that clears things.
  • It’s 5 am…. do you know where your properties are? You better…. Check out what is set. Remember: Reverse Engineering sets properties by itself!

More information on YouTube

Gavin Arthurs speaks about Rhapsody mode/code centric:
Gavin on Rhapsody

Fraser Chadburn speaks about Code-centric development in C++:
Fraser on Code-centric

Chris Carson speaks about Code Reuse:
Chris about Code Reuse

Thomas Hall speaks about Reverse Engineering:
Thomas on Reverse Engineering

Stuttgart 2 (The Sequel)

OK… Stuttgart again. I’m there so often that people think I live there… “Neigeschmeckt” they call it … (Something like “Tastes new” but ask a Schwabe if you want to be sure…..) To make it halfway bearable I’m with a different customer again. And I’m not alone, Joachim is joins me for the training part and on Wednesday for support with our AUTOMOTIVE Rhapsody Model and later Andreas will join us on Wednesday for the MDSE part.

Yes correct, I’m with an Automotive customer again (what are the odds…) so a lot of extra constraints that are less important at non-automotive sites. They always use AUTOSAR, they never buy chips that have enough memory or enough power to do the job, often they have a very cheap CPU but there is only a CPU manufactured compiler (horrible, sometimes these don’t even fulfill ANSI-‘C’….) And they have time constraints that make all other projects look relaxed.

But this customer might use a bit different approach. At least a decent (although very expensive) compiler: Tasking and a decent (although complicated) CPU: Infineon TriCore. But they are determined to use MDSE and willing to put in the necessary effort.

It was a very nice week with very productive sessions. So I’m sure I will see a lot more of Stuttgart in the next months….

Back to Rhapsody. We had a new case, a customer from…. Stuttgart…., with a question I heard before. But that was a long time ago so i decided not to do a copy/paste solution but to dive into it and see if there were better solutions now. And there was…

The problem, or actually the question, was “How do I use Doxygen within Rhapsody”. Simple question. For those who do not know Doxygen: this is a system (Open source) to document C or C++ (amongst many others but these are the interesting for us)  source code. ( www.doxygen.org ) Of course it is Dutch, what else, and many developers use it.

You can document your source code with certain special comments, Doxygen will look for that and generate either an HTML or a LaTeX file. It can do stuff like generate call trees, looks pretty neat.

My first reaction, years ago, to this question was: why do you need to document your source code? It is generated, who cares? But that is too black and white. A lot of source code inside Rhapsody models can be documented and a Rhapsody model is, of course, way better as documentation but not everybody has Rhapsody! (We are working on that one…) So there is an actual use case for generating documentation from your partly generated source code. We even use Doxygen to document our RXF Framework!

But how do you do that? Simple way is to just use the “Description” field in Rhapsody, it will appear in the generated source code. But there are ways to make this more comfortable.

The “old” solution was to add some properties to your site.prp (sitec, sitecpp) But in modern time we can use profiles for that. So i decided to put the stuff into 2 profiles, one for C and one for C++.

A very nice feature of Rhapsody is that it has profiles. In these profiles you can do a lot of stuff that, once the profile is loaded in a model, has great influence on that model. You can set properties, define stereotypes and define tags. You can also define model elements that will be copied (and adapted!!) to your model and much more, I will write about that in a later Blog entry.

When you define tags in a profile and you assign these tags to a specific model element then (It’s magic!) the tags appear in all that elements in your complete model.

Another nice feature is that Rhapsody has a “Description Template” property for many model elements. In that property you can define what comment you want with that model element. You can use tags there ($TagName), the content of that tag will appear in the description. Quite cool eh?

So if you predefine some tags with Doxygen Standard Comments and you make a clever description template you can generate your source with the correct Doxygen Comments. The nice thing? I already did that for you, just download the model (8.1.5, if you need an older one: just ask, I’ll generate it for you, but you will owe me a beer…)

Download at: DoxyGen815

Happy Modeling with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)

Stuttgart

I do a lot of traveling. A whole lot of traveling. Mostly Germany but sometimes outside or way outside. But the city I travel to most is Stuttgart. Not because my car was made there but because we have lots and lots of customers here.

Stuttgart and the surrounding cities are not bad, just the traffic is really murdering. They even beat Munich in traffic jams. Part of it is caused by the geography, Stuttgart is a whole between some hills, there is no way you can build decent roads, what is there must be used, no room for more roads.

The other cause is the so-called “Stuttgart 21” plan. This involves railway only but it will take the complete main station and move it underground. If you look where the station used to be it looks like a nuclear bomb just went of…. Big hole with lots of machines. This has its influences on railway traffic but also on everything that goes through the city.

This week is Rhapsody Training at a customer. 5 days! A long time ago a 5 day Rhapsody Training was normal, unfortunately this is no longer the case. It went to 3 days, often only 2 days and there are companions that estimate their employers to be able to learn UML and Rhapsody in 1 day.

This is, of course, total rubbish. Learning UML and Rhapsody takes just as long as learning ‘C’ and compiler/debugger. If by now you think: “Learning ‘C’ goes quick” then please dig your memory for the truth…,. Before you are an experienced ‘C’ programmer, years go by!

The UML is not more difficult or easy to learn, it is just different. And… you have to know ‘C’’ (or ‘C++’) before. This is what Rhapsody generates.

What is difficult about UML/Modeling? Well.. the way you do it is very different from traditional source code programming. I think that is the most difficult part for most “converted programmers”. Modeling is an art, you learn it by doing a real good training (like ours… 😉 ) and by doing it! You need to practice, read a lot, try a lot.

I see many people using Rhapsody The way they use their IDE, try until the code generator produces the desired output. This is wrong! Follow the paths that people like Bruce Powel Douglas and others have described in books, modeling is a lot of work. In the end you will save because the number of errors and changes will be way lower than with traditional programming.

It pays of to invest in a good process (which diagram should I use when?, what information is where?)  and in making your model so that it is actually your documentation. Modeling takes time but it is time you have to take anyway to give your brain the time to understand what you are doing.

I always say: a model behaves just like your car. If you car is dirty, it does not drive “good”. As soon as you wash and vacuum it, you will sense that it drives “better”. Subconsciously, admitted but true. A model behaves the same. If you make it nicer, with straight lines and with elements that have the same size and are outlined you will notice that it makes more fun to use the model. Some think that the drawing part is wasted time: trust me, it’s not!

So beautify your mode, insert navigation information so that other can also find their way in your model, use enough diagrams, (every diagram should answer a question) use requirements that you connect to model elements to show traceability. Use stereotypes, profiles and tags to store information in your model. After a while you will do that automatically and the quality of your modeling will increase dramatically. Also re-use will be much easier then it was.

Happy modeling with Rhapsody

Walter van der Heiden (wvdheiden@willert.de)

RUGS & DUGS

On Tuesday June 27 we had our yearly RUGS&DUGS. That is the Doors and Rhapsody User Group Summit. Actually the correct abbreviation would be DRUGS. Is fine with me (i’m Dutch) but my German colleagues were against that name. Well OK… but acronyms ending in UGS are all problematic… well except Hugs I guess 😉 Check out RUGS/DUGS in google…

But the conference was successful despite the name, a lot of users were there. This year we were in München, not exactly my favourite city. Or to be precise: i hate Munich. Traffic is hell, public transportation sucks, hotel cost a fortune unless there is a fair then hotels cost more than a house in north Germany, the local soccer team are a bunch of tax criminals.

Enough about bad stuff, onto the good stuff. On our User Group Meetings (and also the MESConf we held the day before) we use something called “Open Space”. This is something that was invented by Harrison Owen and David Belisle. These guys organised conferences and in their evaluations they found out that most people liked the conversations they had during the breaks best. So they figured out a way to extend the conversations during breaks: cut the presentations and formalize the breaks.

There is a time/place plan that allows for multiple conversations to take place, participants determine the topics themselves, put them on a board on a specific time and place and others can, with a look on the board, determine what is interesting to go to.

Works like a charm, i’ve witnessed an Open Space conference a dozen times now and all were great. You can learn a lot in a short time.

More Info

This is one of the methods we use to spread our knowledge about MDSE/Rhapsody/Doors/etc. Other methods are:

this BLOG!

FaceBook

Twitter

IBM DeveloperWorks (Recommended!!!)

Rhapsody4You (please use Developerworks from now on!)

UMLforum (use Developerworks please!)

Andy’s Page

Training & Coaching

Download Portal

Support

You see, enough possibilities to extend your knowledge and become an MDSE Pro real fast! About the forums: In close cooperation with IBM (Thanks Johan Adelgaard!!) we decided to concentrate all Rhapsody knowledge on the IBM site. You will need an IBM ID to login but that is totally free and takes 1 minute to set up.

The next UML Trainings are:

  • 19. – 21.09.2017 in Stuttgart
  • 14. – 16.11.2017 in Bückeburg

 

 

Happy Modeling with Rhapsody!

Walter van der Heiden, wvdheiden@willert.de

© 2025 Rhapsody Tech Blog

Theme by Anders NorenUp ↑