ArgonDigital - enterprise automation experts

Share This Post

Diagrams 2008 Day 1 Highlights: From Models to Code (and Back)

Today’s Keynote address, given by Wilhelm Schäfer, discussed something called Mechatronic UML: A subset of UML 2.0 with applications in industries which intersect EE and ME, and actually in use on the Railcab project.

This subset of UML is used to generate code for systems in which there is heavy interaction among several different components—especially designed for safety-critical applications (such as public transportation). Although such a language is definitely beyond the scope of most requirements engineers, it made me reflect on the “Requirements/Design/Implementation” distinction, in that even though the distinction between requirements and design will never be resolved, the distinction between design and implementation always seemed more concrete. I think that Schäfer’s project has sort of blown a hole in this belief for me, as the design work done in UML is used to generate code directly and successfully in very complex systems. Now, if there were a requirements modeling language which could be translated into Mechatronic UML (or even a fragment of it), it would not only blur the line between requirements and design even more, but also the line between requirements and implementation. Scary.

Also, today during the welcome and introduction, it was revealed that the authors for the best paper in the conference would be awarded two Nokia N810s tablets! Cool! One of the great things about a conference such as this, is that despite the diverse interests of many of the participants, all of them almost universally believe in leveraging technology to solve complex representational problems. As a result, I would say that around 50% of the people here are using a tablet PC or convertible.

At the poster session, I encountered some interesting studies about diagram placement and comprehension of supporting text. It turns out that placement of diagrams in relation to the supporting text may not be as important as our intuitions might reveal. Additionally, diagrams with which one must interact in order to view (e.g., a clickable thumbnail) are more likely to be ignored. The sample for this study was college students, however, and not requirements engineers or their audiences. It would be interesting to run a similar study with an RE orientation. By the way, there was plenty of German snack food at the reception and poster session—pretzels, dark bread, wurst, mustard. And of course, beer. It was a long and cold—but happy—walk back to my hotel.

Diagrams 2008 Day 1 Highlights: From Models to Code (and Back)

More To Explore

AI to Write Requirements

How We Use AI to Write Requirements

At ArgonDigital, we’ve been writing requirements for 22 years. I’ve watched our teams waste hours translating notes into requirements. Now, we’ve cut the nonsense with AI. Our teams can spend

ArgonDigital | Making Technology a Strategic Advantage