Slashdot Mirror

I'm on a project that is using Executable and Translatable UML (xtUML) for developing embedded firmware. The target is an 8-bit microcontroller.

Our software process involves doing an extensive requirements analysis phase. Next, we break the problem down into domains, which are further anaylyzed. Finally, we begin work on the class models and state models.

The xtUML methodology includes precise semantics, which allow it to be directly translated into C using off-the-shelf compilers. Or, you can be brave and write your own model compiler to directly translate your models into the target assembly.

There is some high-level action specification language code which is written for the state actions and instance based operations, but besides that, no coding is required.

Check out this site for some xtUML information: http://www.projtech.com/

For those who are saying that the term "Code Generator" isn't applicable - it is. Consider a C++ compiler. It may generate asm code, which then gets converted into machine code.

(generic) C++ -> (specific) asm -> executable bits

(obviuosly, the C/C++ compiler doesn't need to generate asm, but it's still code generation if it does)

Code generators just take this a level higher, so the code "life cycle" looks like this:

(generic) Diagram / CG description -> (specific implementation) C++ -> (specific machine) asm -> machine code.

Code generators have a great potential for easing coding and documentation. Just like GCC has many backends to generate code for different processor architectures, the code compilers can have different backends to make source code in different languages (C, C++, Fortran, whatever). Even better, you can run a different translator and get documentation out of the "source" - in HTML, DocBook, XML, or any other format you want.

There are tools to let you make UML diagrams (Google for "Executable UML" for great goodness), and generate real-time C code for an application, a C++ app simulator that runs on a PC, and documentation for the system, all from the same diagram. The tools are expensive (like $15k-$30k), but for large projects, they can be a great savings.

I saw a program called BridgePoint (from Project Technologies), which was able to generate embedded, real-time code that was as efficient (more in some areas, less in others, but it averaged out the same) as hand-optimized code done by expert programmers. It all depends on how goo dyour translator is (and this program lets you write your own).

Some books on the subject:
"Executable UML: A Foundation for Model-Driven Architecture", by Stephen J. Mellor and Marc J. Balcer
"Executable UML: The Models are the Code", by Leon Starr
"Real-Time UML: Developing Efficient Objects for Embedded Systems, Second Edition", by Bruce Powel Douglass

Its interesting that Booch talks about an 'executable, testable UML 2.0', given the history of his own methodology. Prior to UML, the Booch, Rumbaugh, and Jacobsen advocated design by elaboration. This meant you continually add artifacts to your design and code until you get to a running system. The 'tools' did nothing but book-keeping for you. They unified their approaches into the UML.

Standing on the other side was the Shlaer-Mellor method, which advocated design by translation (also called recursive design). In this methodology, you diagram different 'domains' and write code generators to eventually produce executable code directly from the model. CASE tools provide assistance in actually producing software (now there's a novel idea).

UML put a lot more emphasis in 'round tripping' in CASE tools, because you edited artifacts that were derived 'in your head' and often failed to match the original model (would you consider editing java bytecode, or asm files?), culminating in the excellent TogetherJ. In Shlaer-Mellor round-tripping didn't matter - you worked on the model and the translators, never on the end code directly (you modify the translator to alter generated code).

I remember back in the day, all the Booch advocates denigrating Shlaer-Mellor, saying it would never work, but here we are, with Booch telling us he's doing executable UML...ah well, at least the methodology wars are over - looks like the tool & book vendors won ;)

- Baz

Its interesting that Booch talks about an 'executable, testable UML 2.0', given the history of his own methodology. Prior to UML, the Booch, Rumbaugh, and Jacobsen advocated design by elaboration. This meant you continually add artifacts to your design and code until you get to a running system. The 'tools' did nothing but book-keeping for you. They unified their approaches into the UML.

Standing on the other side was the Shlaer-Mellor method, which advocated design by translation (also called recursive design). In this methodology, you diagram different 'domains' and write code generators to eventually produce executable code directly from the model. CASE tools provide assistance in actually producing software (now there's a novel idea).

UML put a lot more emphasis in 'round tripping' in CASE tools, because you edited artifacts that were derived 'in your head' and often failed to match the original model (would you consider editing java bytecode, or asm files?), culminating in the excellent TogetherJ. In Shlaer-Mellor round-tripping didn't matter - you worked on the model and the translators, never on the end code directly (you modify the translator to alter generated code).

I remember back in the day, all the Booch advocates denigrating Shlaer-Mellor, saying it would never work, but here we are, with Booch telling us he's doing executable UML...ah well, at least the methodology wars are over - looks like the tool & book vendors won ;)

- Baz

I have built UML models and translated them into ANSI C, compiled with gcc (using rcx-tools) on Linux and run them on the Lego brick. [The UML modeling tool suite is BridgePoint/MC-3020 from Project Technology.]

Actually, the H8 micro (inside the brick) is a pretty hot little micro. $200 is pretty cheap for an engineering prototyping system.

Ok gang. We went through a similar thingie a 'few' years back when most of you were not even a twinkle in your daddy's eyes yet.

It was the 'real programmers' versus pinko compilers. (Search your favorite search engine for real programmers don't eat quiche to catch up on your hacking history.) 'Real programmers' only used assembler language and did not trust compilers. They did not believe. They are, of course, mostly extict now. Nothing, except for some drivers and low level code, gets implemented in assy any more.

What do we do these days? We do not even look at the compiler-genrated assembly code any more.

What's next you ask? Complete model-driven, implementation independent code generation, of course!

How? What? When? Where?

At this site and this site.

How about being able to generate C++, Java, C?

Poor performance? No problem! Just swap the software architecture. Single process/single processor -> multi process/single processor -> multiprocessor/fully distributed. Whatever does the job...

Why commit to platforms? Switch from CORBA -> DCOM, Sybase -> Oracle, C++ -> Java and so on.. (and back again). If XOOF++ comes along, all you have to do is modify the affected part the software architecture and generate the new code. No changes to source models required to generate a code based on a different implementation!

Oh - did I mention that the resulting code is practically bug free? It does what you want, as fast as you want. No memory leaks, core dumps, etc.

It would behoove the open source community not to get stuck in the implementation layer and not become the 'real programmers' of the future. Once these models really catch on, it will be great to have a set of open source tools and models ready for the ultimate blow to proprietary code.

-- l2b
#include "std.disclaimer"

very a propos - funny and true to boot.

for more info on real system engineering click here

The person using the CASE tool having no clue does not mean that methodologies and CASE tools are not effective.

Like anything, one must know what one is doing. Would you say that Linux performs badly because some utility may be poorly written by a newbie? I hope not!

Some methodologies and CASE tools are pure garbage even though they sell well. Popular does not mean right. The disasters do and will continue to speak for themselves.

Until effective methods and tools become widely accepted and used on large and complex systems, we will continue seeing these expensive disasters.