Rhapsody TechBlog

BLOG about IBM Rhapsody. Contains technical information as well as more private travel stories.

Tag: Systems Engineering

DCUG Day 2026: The Dutch IBM Champions Are Gathering — and They Want You On Stage

August 4, 2026 / / 0 Comments

If you follow this blog, you know I spend most of my time deep inside IBM Rhapsody and Model-Based Systems Engineering. But there is a whole world of IBM technology and community around that — and this autumn a big part of it is coming together in Amsterdam.

On Friday, 2 October 2026, the very first DCUG Day takes place at the IBM Innovation Center in Amsterdam. DCUG stands for the Dutch Champions User Group — the Netherlands-based community of IBM Champions who share knowledge and enthusiasm across the whole IBM portfolio.

What to expect

A full day of content-driven, non-commercial sessions by and for the community, spread across four tracks:

  • Data & AI
  • Automation
  • Hardware & Storage
  • Cloud

Covering IBM priority areas from watsonx and hybrid cloud to IBM Z, IBM i, Storage and Power. It is the kind of day where you learn something new in every slot and bump into exactly the people you needed to talk to.

📣 Call for Papers — extended to 14 August 2026

Here is where you come in. The Call for Papers has been extended to Friday, 14 August 2026. If you are an IBM Champion with something to share — a real-world story, a technical deep-dive, a lesson learned — consider this your invitation to the stage.

Sessions are short and punchy: 25 minutes plus 5 minutes of Q&A, preferably in English. Send your title, a short abstract, your preferred track, session language and speaker information to the organisers (all the details are on the DCUG site below).

And yes — if your world is systems engineering and modeling, there is absolutely a place for that conversation here. The IBM ecosystem is broad, and cross-pollination is exactly what these days are for.

Join us in Amsterdam

Whether you want to speak or simply come along and connect, mark 2 October in your calendar. All the details, the full Call for Papers and submission instructions are on the DCUG website:

👉 DCUG Day 2026 & Call for Papers on dcug.nl

See you there!

Mercury Rising

September 10, 2025 / / 0 Comments

AI Meets Rhapsody (and I Meet Welsh Hedgerows)

Mercury Rising: AI Meets Rhapsody (and I Meet Welsh Hedgerows)

Flying into Bristol, picking up a rental car, and immediately remembering why left-hand driving on narrow Welsh roads is… an experience. Destination: Usk, Wales. Purpose: work stuff that I can’t talk about in detail, but let’s just say it involved some interesting conversations about the future of systems engineering.

The drive from Bristol to Usk was like being dropped into an episode of “Escape to the Country” (which, yes, Jannie and I watch religiously). Rolling green hills, stone cottages, roads that seem designed for horses and carts rather than rental cars driven by confused Dutch guys trying to remember which side of the road they’re supposed to be on.

Welsh countryside aerial view

Every turn felt like I was about to meet a tractor head-on, or worse, scrape the rental car against one of those ancient stone walls. But somehow I made it to Usk in one piece, which is more than I can say for my nerves.

Mercury: When AI Meets Model-Based Engineering

Which brings me to why I’m really writing this post. While I was navigating those Welsh country lanes, my colleagues back home were putting the finishing touches on something we’ve been working on for a while: Mercury, our latest extension to Rhapsody.

Now, before you roll your eyes and think “Oh great, another AI thing,” hear me out. Mercury isn’t just AI for the sake of having AI. It’s AI that actually does something useful for us systems engineers.

Mercury AI in IBM Rhapsody

What Does Mercury Actually Do?

Simple version? You can write your requirements in natural language, and Mercury will generate a model for you. Not a perfect model—let’s not get carried away—but a decent starting point that you can refine.

Think about it: instead of spending hours creating class diagrams from scratch, you describe what you want in plain English (or Dutch, or German, or whatever), and Mercury gives you something to work with.

“I need a system that manages user authentication with role-based permissions and audit logging.”

Boom. Mercury creates the basic structure. Classes, relationships, interfaces. You still need to refine it, add the details, make it actually work—but the tedious initial setup? Done.

Rental car in Wales

Reverse Engineering That Actually Works

But here’s where it gets interesting (and where I stopped thinking about Welsh hedgerows for a moment). Mercury can also work backwards. Give it existing code, and it’ll create models and documentation.

You know that legacy system everyone’s afraid to touch? The one where the original developer left three years ago and took all the knowledge with them? Mercury can help make sense of it. It’ll read through the code, identify patterns, create UML diagrams, even suggest what the requirements might have been.

Is it perfect? No. Is it better than trying to reverse-engineer a 50,000-line codebase by hand? Absolutely.

Rhapsody reverse engineering

Requirements and Traceability

And then there’s the requirements side. Mercury can read your existing requirements documents (yes, even those Word documents everyone pretends don’t exist) and create proper traceability matrices. It can spot inconsistencies, identify gaps, even suggest test cases based on the requirements.

Remember those three-hour meetings where you try to figure out which requirements are actually implemented and which ones are just wishful thinking? Mercury can do a lot of that legwork for you.

The Welsh Connection

Sitting in a pub in Usk that evening (after successfully navigating more narrow roads without major incident), I was thinking about how both AI and Welsh country roads require a certain amount of trust. You have to trust that the AI understands what you’re asking for. You have to trust that the road actually goes somewhere and isn’t just going to end in someone’s back garden.

Pub in Usk, Wales

With Mercury, we’re not trying to replace systems engineers. We’re trying to give them better tools. The same way GPS doesn’t replace the need for a driver, but it sure makes navigation easier (even on Welsh country roads).

First Impressions

I’ve been playing with Mercury for some time now, and honestly? It’s promising. Not revolutionary—let’s not oversell this—but definitely useful. It’s like having a junior engineer who never gets tired, never complains about documentation, and doesn’t mind doing the boring setup work.

The model generation is surprisingly good for simple systems. Complex stuff still needs human intervention, but for getting started? It beats staring at a blank Rhapsody workspace.

The reverse engineering is where it really shines. I fed it some automotive code we’ve been working with, and it produced documentation that was actually readable. Not perfect, but readable.

StopwatchModel in Rhapsody

The Reality Check

Will Mercury solve all our systems engineering problems? No. (I feel like I say this a lot, but it’s always true.) Will it make some tasks less tedious? Yes, and that’s enough for now.

The AI hype cycle is exhausting, I know. Everyone’s promising that AI will revolutionize everything, cure diseases, solve world hunger, and probably make better coffee. Mercury has more modest goals: help systems engineers do their jobs with less tedious busy work.

And sometimes, that’s exactly what you need.

Pics or it didn’t happen

Well i have a movie? Does that count?

Create a model from almost nothing.

Back home

My flight left on saturday morning. Who needs weekend when he does amazing things… It was early but really cool. Great visit to Wales. “I’ll be back”!

Welsh countryside from the road
View from airplane window

Final Thoughts

Driving back to Bristol the next day (slightly more confident about the left-hand driving thing), I realized that both Mercury and Welsh country roads teach you the same lesson: trust the process, but stay alert.

Mercury will generate models and documentation that are mostly right. Your job is to spot where “mostly right” isn’t good enough and fix it. Just like driving those narrow roads—the GPS will get you close, but you still need to pay attention to avoid the stone walls.

If you’re curious about Mercury, drop me a line. We’re still in beta, still figuring out what works and what doesn’t. But so far, it’s looking promising.

P.S. – “Escape to the Country” makes Welsh property hunting look much more relaxing than Welsh driving. Trust me on this one.

Usktoberfest poster
Indian food
Airplane window
Train station
Restaurant dinner
Breakfast
Allo Allo dinner invitation
Fawlty Towers poster
Clifton Suspension Bridge in rain
Rental car interior

Have you tried any AI-powered engineering tools? What worked, what didn’t? Let me know in the comments below.

From the Depths to the Heights: Rhapsody SE and the Grand Canyon

August 30, 2025 / / 0 Comments

Every year in January I go to Phoenix (Scottsdale actually), for the yearly 321-Gang kick-off. Like last year, I took Jannie with me (i have a truckload of KLM miles to spend), and although I had to work, we had some free time to see some things. So we decided to go to the Grand Canyon. Yes, that’s quite a drive, but I like driving, certainly in the USA. Very relaxed there.

I’ve been at the Grand Canyon before—many years ago on a road trip from Minneapolis to Las Vegas. But that’s a story for another time.

The drive from Phoenix was nice enough—20°C and sunny (and no, I don’t use FreeDumb Units). But once we got up to the South Rim? Different story entirely. Way, way colder. Like, “why didn’t I pack better clothes for this” cold.

[Photo: Grand Canyon winter view - those layered rock formations]

Jannie was smart enough to bring proper winter gear. Me? Not so much. But hey, the views were worth the frozen fingers.

A Canyon of Perspective
(and Frozen Fingers)

Standing there at the rim, trying to take decent photos while my fingers slowly turned into ice cubes, watching the layers of geological history unfold in the winter light, I couldn’t help but think about layers of a different kind—the architectural layers we’ve been building in the new IBM Rhapsody Systems Engineering (Rhapsody SE).

The Grand Canyon has this way of putting things into perspective, doesn’t it? There I was, looking down at rock formations that took millions of years to create, thinking about how we systems engineers are always trying to manage complexity and time in our own projects. The Vishnu Schist at the bottom? That’s like our foundational architecture. The Kaibab Limestone at the top? Well, that’s probably the user interface everyone actually sees and judges us by.

But here’s where it gets interesting (and where my mind inevitably wandered back to work, because apparently I can’t help myself even at one of the world’s natural wonders)—the Grand Canyon makes all those layers visible. You can see the relationships, the dependencies, the way each layer built upon the previous one. And that’s exactly what we’ve been trying to achieve with systems engineering for… well, forever.

Enter Rhapsody SE
(From the Outside Looking In)

Which brings me to the real reason I’m writing this post. Now, full disclosure—I’m still an “old fashioned” Rhapsody Classic guy. Haven’t made the jump to Rhapsody SE yet. But I’ve been reading about it, talking to people who have tried it, and honestly? It sounds like someone finally listened to what we systems engineers actually needed.

[Screenshot placeholder: Rhapsody SE web interface - if someone can send me one!]

What’s Different This Time?

First off, it’s web-based. No more “Can you install this on my machine?” or “The license server is down again” conversations. You just… open a browser. Revolutionary, right? Well, for our industry, it kind of is.

But here’s the thing that really caught my attention: SysML V2 support. Finally! I mean, we’ve all been waiting for this for what feels like forever. It’s supposed to be like moving from a horse-drawn carriage to a Tesla. Sure, both get you there, but one makes the journey significantly more pleasant and efficient.

[Photo: Me looking cold but happy at the Grand Canyon - because why not?]

Of course, I’m still stuck in Classic Rhapsody land for now. But a guy can dream, right?

The Collaboration Game-Changer

Standing at Hopi Point (thankfully they had a heated visitor center), watching tourists from around the world gather to see the same incredible view despite the cold, it struck me how good collaboration really needs that shared perspective—that common view of what you’re all working on. That’s what Rhapsody SE is supposed to be all about.

In Classic Rhapsody, collaboration often feels like playing telephone. You work on your part of the model, export it, someone else imports it, merge conflicts happen, and suddenly you’re in a three-hour meeting trying to figure out why the state machine doesn’t match the interface definition anymore.

Sound familiar? Yeah, thought so.

From what I’m hearing, Rhapsody SE is supposed to change this. Everyone’s looking at the same “canyon”—the same live model, the same data, the same current state of the architecture. No more version conflicts, no more “Well, in my version…” discussions.

At least, that’s the promise. I’ll believe it when I see it, but I’m cautiously optimistic.

[Screenshot placeholder: Rhapsody SE collaborative interface showing real-time updates - anyone?]

Real-Time Everything

The Grand Canyon was carved by the Colorado River over millions of years, but today’s business environment doesn’t give us millions of years to get our systems right. We need real-time everything: real-time collaboration, real-time updates, real-time validation.

SysML V2 and other data and workflow APIs enable model-based integrations with downstream domains as cross-domain digital threads, boosting productivity and accelerating system engineering processes. This is the kind of integration we’ve been promising stakeholders for years. Finally, we can actually deliver on it.

The View from Here

As I walked the Rim Trail that day, moving from viewpoint to viewpoint, each offering a slightly different perspective on the same magnificent canyon, I realized that’s what good systems engineering is about—providing multiple perspectives on the same system, helping stakeholders understand the relationships and dependencies that aren’t immediately obvious.

Rhapsody SE feels like it’s finally giving us the tools to create those multiple perspectives without having to maintain separate models or worry about consistency. The solution supports systems of all sizes, from small projects to large enterprises, by providing layers of abstraction to manage different levels of detail and keep models clear and manageable.

The Verdict (From Someone Who Hasn’t Used It Yet)

Will Rhapsody SE solve all our systems engineering problems? Probably not. (Nothing ever does, really.) Will it make some of our daily frustrations disappear? Maybe. And after using Classic Rhapsody for over a decade, I’m willing to be hopeful.

The Grand Canyon took millions of years to become what it is today, and it’s still changing. Our systems engineering practices are evolving too, just a bit faster. Rhapsody SE sounds like it might be a significant step in the right direction—a tool that finally acknowledges that systems engineering is inherently collaborative and that maybe, just maybe, we should make that collaboration as seamless as possible.

Plus, it’s web-based. Did I mention it’s web-based? Because after years of Classic Rhapsody license server issues, that alone makes me want to try it.

Now I just need to convince management to let me play with it…

[Photo: Final Grand Canyon shot - the vastness that puts everything in perspective]

P.S. – If you’re ever at the Grand Canyon in winter, pack warm clothes. Trust me on this one. And yes, Hermit’s Rest still has the best coffee and least crowded viewpoint, even in January.

What are your thoughts on the evolution of systems engineering tools? Have you tried Rhapsody SE yet? Let me know in the comments below.

Development of Safety-critical Software

April 5, 2018 / / 0 Comments

Content

This is also published TechLetter 6, written by Eike Römer. Translated by me and published on the Rhapsody BLOG to allow more people to read it.

The development of safety-critical software is often associated with a certification process. Experiences from the certification environment are presented together with possible work steps.

The procedure is based on the V-model. This Tech-letter covers requirements management, implementation, testing, and end-to-end traceability.

The presented experiences can be adapted to own projects.

Grph - Entwicklung sicherheitskritischer Software-290.png

Practical experience and possible work steps

Creating software for embedded systems in safety-critical areas often requires certification as well. Standards such as IEC 61508 or industry-specific standards are intended to ensure functional safety for safety-critical application areas. In this Techletter practical experiences of the Willert Software Tools GmbH in the range of the software certification are presented.

Example RXF-Cert

Willert develops a so-called semi-finished product, that, being only a part of the software, is being built together with the application software of customers later to create a unit. This unit then must be certified as a whole.

In the specific case, it is the “RXF-Cert” [1], a framework on which the code generator can be based on the UML tool IBM Rational Rhapsody [2] (see Figure 1). In addition to the framework source code and UML model, a “Certification package” is delivered consisting of documents and test suites that facilitate certification in the overall context.

Screen Shot 2018-04-03 at 16.43.06

Figure 1 – RXF-Cert as semi-product in the context of the customers application

Management of Requirements

Probably the most important part of the accompanying documents are the requirements. In order to manage their relationships, versions and status changes, many tools have become established in the market. Such tools are, for example, IBM Rational DOORS® [3] and Polarion [4]. Willert has chosen Polarion for his own use as part of the RXF-Cert project.

Screen Shot 2018-04-03 at 16.44.55

Figure 2 – Specifications and their links in the V-Model

The organization of the requirements has been made in the following levels (see Figure 2)::

  • Customer Requirements (Role of the Customer)
  • System-specification (Role of the SW-Architect)
  • (Software-)Module- and Operation-specification (Role of the developer).

The linking should be defined fixed from the lower level to the next highest level, as a “Satisfies” relationship.

A specification should always have one or more relationships with overlying specifications or requirements. Also links from the resulting software or the source code to the specifications are required here. This makes it clear which code section is used to implement which request (s).

The RXF-Cert comes with a Rhapsody UML model. In addition to the module specification and implementation with the associated code generation, this also contains visualizations of the architecture and of scenarios for more complex processes. In case of a certification diagrams bring the advantage that an auditor can more quickly grasp the construction and implementation of the software. Model elements should also have links to the specifications here.

To create representations for requests in UML tools, there are, for example, the IBM Rational Rhapsody Gateway tools [5] and the Willert ReqXChanger [6] tools. For the RXF-Cert the ReqXChanger, developed by Willert Software Tools, is used that connects e.g. Polarion via the standardized Requirements Interchange Format (ReqIF) and directly supports Rhapsody. Thus, representations for UML elements are also created in the requirements management tool and related to the associated requirements. The associated workflow is visualized later in the document in Figure 5

 

Ensuring functionality through Testing

Certification also requires proof that the functionality is being verified by testing. In a first RXF-Cert project, unit tests and code coverage analyzes were conducted on the basis of manually written C test cases and the gcov tool (from the gcc package) [7] in a test environment. Currently, the effort has been greatly reduced by using the model-based Test-tool BTC TestConductor [8]. In addition, these tests are also performed on the hardware of the target system instead of a PC environment. The results are returned to the test model from the target environment (see Figures 3 and 4).

The test case specification for the unit tests has been linked in the UML model with the implementations of the modules, so that also the test specifications from the model are mirrored in the requirements management tool and in conjunction with the specifications, herewith also a cover and Impact analysis up to the unit tests possible (see Figure 1).

Test Conductor

Figure 3 – Test execution on the target with feedback of the test results into the test model.

Coverage

Figure 4 – Results of the Code Coverage Analysis on the target environment

Cross-phase coverage and impact analysis

Coverage analyzes are important in order to determine, for example, whether all requirements have a test or whether all requirements are linked with software elements. In the approach presented above, coverage analyzes of the UML model can also be performed. From this documents can be generated that can be presented to an auditor.

Impact analyzes are necessary if, for example, requirements are changed during development. One goal is to be able to determine through all levels what needs to be adjusted as a requirement changes. The ReqXChanger can mark changed requests with stereotypes when retransferring requests to the UML tool (see Figure 6). For the certification process, it can be ensured that the software always takes into account the current state of the requirements.

Preparation of documents for certification

Traceability

Figure 5 – Exchange between UML Model und requirement Management

Impact Analysis

Figure 6 – Changed Requirement / Specification obtains Stereotype “Changed” in the model

Creating Certification Documents

From the standard it can be extracted which documentation components are expected. However, combining these into suitable documents and maintaining them involves some work. It therefore makes sense to create an overview document of all delivered goods. Here are source texts, documents and other artifacts of the delivery described and clearly identified including the consistent version numbers. The basics also include adding structure elements to each document, such as a table of contents with page references, a version history, and a cover page with the unique identifier and version. Likewise, a page number indicating the total number of pages on each page in order to be able to verify the completeness.

When recording the requirements, it should be noted from the outset that the corresponding documents must be created for certification. Printing the documents from our internal requirements management with Polarion in an appropriate form requires a lot of effort. The documents managed in Polarion itself can not be used to print the specifications if the links and thus the traceability should also be printed. It is not possible to filter only for specific link types or links to desired targets in the view. One of the consequences of this is that requirements list a relation to the IDs of their chapter headings (these have a hierarchical relationship in the document to each other). A certifier will now stumble upon references that he can not find because headings in the references show the Polarion internal ID, but the header itself does not display an ID. It is therefore strongly recommended that when selecting a tool it is taken into account that it can generate the documents accordingly or how to configure it accordingly. Also with Polarion it is possible via wiki or info pages to prepare the documents for printing accordingly.

Conducting (internal) Reviews

The review of the specification and elements of the software should be done in the requirements management tool. It is helpful to specify that for a “review attribute” (here: “status”) of work items (eg requirements) certain values ​​can only be set one after the other (see Figure 7).

Req Review.png

For the “Specify action”, Polarion has been configured to invite specified users to “approve” the work items. Here are two responsible persons. Only when these persons have both given their “Approval”, a status transition to “Reviewed” is possible. This fact is explained in the supplied validation plan and thus ensures the four-eyes principle in the review process.

Also reviews of models can be managed with this mechanism. In addition, the module specifications specify which SVN revision number (of a checked-in model unit) a review was carried out for. For new revisions, new reviews must be made accordingly.

At the code level, we have had good experience with the Crucible tool [9] and have created a PDF export plugin there that can be used to create code review reports suitable for certification.

Evaluation by a certification consultant

In order to assess the described status independently, we have obtained an evaluation of our procedure by an external certification consultant. This has brought many valuable experience. Among other things, we understood better what content and documents are required by the standard. For example, A security officer must be named in the company, who of course also lives up to his task, and there must be a corporate policy statement on the handling of software security in a “Safety Policy” document.

We have received a lot of positive feedback on the approach and process in development, as well as the approach to meeting the standard. For us in the consultation also the large difference in the standard, whether something is certified as software or as a tool (tool), clear. When you certify a tool, you only have to deal with about one-tenth of the IEC 61508 requirements than with a complete software certification. Nevertheless, we strive to classify our RXF-Cert as software in general. This must also be clearly documented and the user should be made aware of the field of application. If our RXF-Cert were e.g. Not only supporting the development of software, but also the systems engineering, would be added to several other requirements.

In conclusion, we still see the effort associated with certifying software as considerable – but it also shows for us that the requirements of the standard are absolutely meaningful. The development process becomes more sophisticated, the software quality can improve significantly and almost as a by-product the software becomes certifiable.

Passed certifications

The RXF-Cert has now been deployed in several functional safety software projects along with the customer applications. The areas Railway, Automotive and Space are represented. Some of these projects have already successfully passed the certification with the RXF-Cert package, others are currently or will only be in the project status in which the certification will be carried out in the near future. Thus, it has already been shown that the general procedure, meaningful use of tools and careful work steps described in this Techletter make it possible to plan and implement certification according to a standard based on IEC 61508.

Referenced Tools

[1] Willert RXF-Cert, Framework for modeling and code-generation of safety-critical Software:
https://www.willert.de/uml-rxf-cert

[2] IBM Rational Rhapsody, UML-Tool:
https://www.willert.de/rhapsody

[3] IBM Rational DOORS®, Requirements Management:
     https://www.willert.de/doors

[4] Siemens Polarion, Application Lifecycle Management:
https://www.willert.de/polarion/

[5] IBM Rational Rhapsody Gateway, Tool for the exchange and trace of Requirements:
https://www.willert.de/gateway

[6] Willert ReqXChanger, Tool for the exchange and trace of Requirements:
https://www.willert.de/reqxchanger

[7] gcov (from the gcc package), Open Source Tool for Code Coverage Analysis:
https://gcc.gnu.org/onlinedocs/gcc/Gcov.html

[8] IBM Rational TestConductor, Model-based Testing:
http://www.willert.de/testconductor/

[9] Atlassian Crucible, Code Review Tool:
https://de.atlassian.com/software/crucible

 

Happy Modeling with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)
Eike Römer (eroemer@willert.de)

 

 

Nantes – Jules Verne

February 5, 2018 / / 0 Comments

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) or 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 in 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)

Engineering@Scale Tech Day

October 4, 2017 / / 0 Comments

Join us for Engineering@Scale Tech Day. Learn how new solutions and technologies are helping to lead the innovation agenda while addressing the complexity challenge in the automotive industry.

This event will focus on engineering systems and software development.  We will feature sessions around industry best practices and the core processes of requirements management, architecture design, collaboration, change and configuration management, test and quality management, product line engineering and variant management. Improve your skills, network and collaborate with industry experts.

What to expect:

  •  Keynote session by the American Center for Mobility
  •  Technical sessions for novices to experts, with topics ranging from:
    •  Scaling Agile to the Automotive Enterprise
    •  Convergence of MBSE and the Product Innovation Platform in Automotive
    •  Connected Product initiatives with Digital Twin and Digital Thread
    •  Improving your processes with Automotive SPICE
    •  Feature-based Product Line Engineering and Operations for the Automotive Enterprise
    •  Certifiable framework for AUTOSAR
    •  And more
  •  Networking Lunch (no charge)
  •  Plus, tour the spectacular automotive collection at the GM Heritage Center.

 Register today and share with a colleague!

General Motors Heritage Center
6400 Center Drive
Sterling Heights, MI 48312

Thursday, October 12, 2017 from 8:00 AM to 4:00 PM (EDT)

Don’t let the bedbugs bite…..

September 5, 2017 / / 2 Comments

Introduction

Using UML and Rhapsody to develop software is a very good way to cope with increasing complexity. The ultimate usage of Rhapsody is using the code generator to generate production code.

Although using UML makes it much easier to maintain an overview over the software, it is still no guarantee for error-free software.

So even in Model Driven Development there is point where there is need for a debugger.

Rhapsody offers a few ways to debug the generated software.

  1. Using Rhapsody Developer and Animation, basically generate code with instrumentation
  2. Using a source code debugger provided by the compiler
  3. Using the Willert Embedded UML Target Debugger

The first solution is directly connected to the use of the Rhapsody Developer, a license that is not generally available. It is also available in the Rhapsody Architect for System Engineers (Designer) which is often used by System Designers. In fact, the Designer can ONLY generate instrumented code.

This is a very comfortable way to debug UML Models, Animation can show „Live“ State-charts, trace Sequence Diagrams and much more. There is, however, a price to be paid for this comfort.

Animation uses a TCP/IP connection and does a lot of communication, also the Code Instrumentation uses an incredible amount of RAM and ROM. This makes it unsuitable for small targets.

Of course it is possible to create models that will be runnable on both PC and embedded target, this is not always easy and allows you to only debug the logic of your software.

When doing Systems Engineering this is mostly exactly what is needed and Animation is very suitable for that.

Using a source code debugger is possible but it requires deep knowledge of the generated source code and the used Framework. Also, the use of object orientation is making debugging in a classic way more difficult. (When using multiple objects, a breakpoint tells you where you are in the code but not in which object.)

A great way to debug is using the WST Embedded UML Target Debugger., short: TD.

What is the TD

The TD, the Willert Software Tools Embedded UML Target Debugger is a tool for debugging UML Models on a model level. It consists of 2 parts:

– The Monitor

The WST RXF has a small monitor built-in that will transport information about what is happening inside the framework to your PC.

– The Target Debugger GUI

TDWorkingTakes the information from the monitor and presents that in the form of UML Diagrams using symbolic information from an XML file that is generated during code generation.

In the process of creating the new version of the framework we also redesigned the TD from the bottom up. The Code is made with Rhapsody (Quote George Clooney: what else…) and the Qt Framework from Willert.

What can the TD do?

It can draw 2 types of UML diagrams: Timing Diagrams and Sequence Diagrams. These diagrams are drawn from the information that the target provides. They provide you with enough information to see what your system is doing.

  • Breakpoints
    Intelligent breakpoints can be used to allow stopping when you need it. The diagrams will then provide you with the correct information.
  • Filters (Host/Target)
    You can filter what information you want to see, dynamically on the host (The diagrams will be re-drawn with the requested information) but also on the target (Only the requested information will be sent, saving valuable resources)
  • Event injection
    Use the TD for your own testing by sending events to your target. You can also predefine sequences of events to be sent to easy do test sequences.
  • Test Conductor integration
    Use the Test Conductor together with the TD to automatically run tests e.g. for nightly testing.
  • Multiple targets
    It is possible to use multiple targets to debug larger systems consisting of multiple components. Synchronize the time between the targets with one button.

The Target debugger is included in the RXF, it must be adapted to your environment and your communication interface. But it can save you loads of time debugging and testing.

Happy Modeling (and Debugging) with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)

© 2026 Rhapsody TechBlog

Theme by Anders Noren — Up ↑