Is UML appropriate for embedded systems ?

It is a tool and like any other it is only as good as the hands you put it in.

Ian

I don't think much has changed since the last time it was discussed:

Vadim

conviced

Its a good idea, but the implementation is expensive. Training in UML design methods and tools is expensive and many companies choose the "half-assed UML" approach by doing use-case diagrams in Visio only. In my experience, lots of scenarios are overlooked in the development of use-cases for any but the simplest of systems.

Usually the UML experts are not very familiar with the hardware and this causes other oversights to occur. But according to 99% of the literature that I've seen, UML is a superior design methodology for designing automated coffee machines.

- UML may not be suitable for embedded development. As some pointed out, too many diagrams and in the end someone should convert all this to code anyway.

- xtUML may be suitable for embedded development. The company I work for use this. So far it works well. We use it to model embedded control systems that are safety critical aswell as the cores of desktop style applications. From the models we auto generate code in C++ and Ada. In a year I will be able to tell if it still works since in that time we are to complete a simulator project that will contain a few hundred classes and run distributed over a network. We would not have choosen this technology if we were not pretty convinced it would be possible.

/Leif

I agree with you in the sense that good workers always have good tools ...

But, the point is that UML is not a tool but a method or more exactly a language. As such it should help system specification and design and not hinder it, or why should not we not stick to well proven structured methods.

I think that all diagrams in UML have some usefulness but that they seem to be ad hoc add-ons from different origins that don't form a consistant whole.

IMO:

- Use Cases don't allow easy hierarchical representations of requirements

- Sequence diagrams are good for representing typical scenarios but cannot be used for a complete specification of a protocol.

- There is no hierachical representation of data flow or of control flow

- Class diagrams are useful for the design of object oriented architecture but not for the specification of many embedded systems, at least not naturally

- StateCharts are very useful but they are not new and don't integrate easily with other diagrams.

Hi,

In my opinion, UML is very wel suited for embedded systems specification, design AND implementation. Sequence diagrams are a good help in specifying specific behaviour, although you need more diagrams (structure and behaviour) to completely specify the system. IMO the big advantage only starts if your systems's model is used to generate the actual code, otherwise you end up with a documentation tool.

We have been using Rose Realtime C++ and C with complete codegeneration for several years sucessfully to implement complex embedded applications. C++ with active classes and an underlying RTOS for the 32 bit platforms, C with passive classes only and NoRTOS for the 16 bit platforms.

Cheers,

-- ############################################################ # Oce Technologies B.V. name: Ton Janssen (3A05) # # P.O. Box 101 email: snipped-for-privacy@oce.nl # # 5900 MA Venlo Private: snipped-for-privacy@home.nl # # Tel: +31 (0)77-359 40 97 # # The Netherlands Fax: +31 (0)77-359 54 50 # ############################################################ This note does not necessarily represent the position of Oce Technoligies B.V. Therefore no liability or responsibility for whatever will be accepted.

conviced

Just as a matter if interest:-

Is it possible to understand, at every level and in minute detail, every aspect of the software source and eventual code that is produced by your tool in order that you may know how correct it is, how much memory resource it will require and whether or not you have any dead code in the final result.

Are you joking, or do you really use VB and VBA for embedded system work?

Firstly, any toolchain can "tolerate" dead code and variables. The problem is that dead code/variables are using up memory better spent on "live" stuff.

Secondly, if you're using Visual Basic for embedded stuff, you've got _way_ bigger problems that dead code.

It's been a number of years, but I have worked on a system where I would have been unhappy if "dead code" were not included in the ROM. Because the code wasn't actually "dead," it just wasn't used by that application. Another application (burned in the same ROM) required it. Sort of, but not exactly, like a BIOS.

Though I suppose I could have worked around it in assembly if it had come to that...

Regards,

-=Dave

No problem. With gnu ld you just tell the linker to keep those functions or files even if they aren't used.

No assembly required, just an extra command in the linker script file.

Are you very sure about that? And that it won't break the program completely, in the presence of function pointer usage? Of function pointer arithmetic (--> jump tables)?

Yes, I'm sure. I've been using it for years. It works even with function pointers and jump tables. Why wouldn't it? A reference to a fucntion is a reference to a function: it doesn't make any difference whether it's part of JSR instruction, a LDI instruction, or a .LONG directive.

If you put a pointer to a function into a jump table, that function will be included in the final image. The linker has no way to know if your program will actually _use_ that slot at runtime, so it will be included even if your program never actually uses that slot in the table. The linker will "garbage collect" unused objects (variables, arrays, functions) but there's now way it can "garbage collect" individual elements _within_ an array (e.g. un-needed entries in a jump-table).

You've got to rely on the programmer a little bit...

I haven't used a gnu toolchain for an embedded project yet, but I would expect that there are still going to be dead code possibilities that the machine is going to have a hard time eliminating. E.g:

int foo() { int dummy = 0; return bar(dummy); }

int bar(int limit) { int i; for (i==0; i "garbage collect" unused objects (variables, arrays, functions) but there's

With most of the tools I use (and have used) an unreferenced variable is caught and flagged by the compiler. I seem to recall a study that was published in the Communications of the ACM some years ago that found that unreferenced variables had a very high correlation with defective code, so whenever I get such a warning from my compiler, I look *very* carefully at the offending routine.

Ed

I don't know if it's that sophisticated or not.

I don't see how that's even theoretically possible in the C language. The compiler can only see 1 file at time. If you declare a global variable and don't use it within that file, the C compiler can't know it's an error because it might be used by another file. That's bad style, I'll admit, but perfectly legal C.

For local and static variables, I agree. For global variables, I don't really see how such a warning can be generated by a C compiler.

On my Linux box, I can't make it eliminate that code, but that could just mean I don't know all of the optimization command line options sufficiently. I just used -O3. However, it did promptly notice that it should be "for (i=0..." Oops!

Ah, I should have been specific that I meant local and static v'bles only and not globals. I tend to use very very few globals so checking them by hand is usually fairly simple. There, tools like splint and Doxygen can help.

It would have to be generated by a linker or a global source code analyzer. Many years ago, I wrote one in Perl which checked for various things like that in a very large assembly language projects. One of the more interesting things it discovered was something that had lived in the code for a very long time, overlooked by many programmers. It was a piece of code which had conditional assembly. The conditional part was test code which was never put into the actual product, but it wasn't put in quite the right location. The result was something like this:

test TestModeFlag jz BeyondTest #ifdef INCLUDE_TEST_CODE TestMode: ; many lines of code... #endif BeyondTest: ; blah, blah, blah...

Obviously, if the #ifdef code is not included, both the test and the jump are useless, but because they were separated by a couple hundred lines of test code, nobody spotted it!

Our computers can definitely help us spot silly errors, if we use the right tools.

Ed

Ah. I use -Werror, so files with unreferenced local/static variables don't even compile.

I really do need to get lint going again...

That would be a useful addition to the Gnu ld. You can tell it to discard unreferenced objects, but I don't think you can generate a report on what got discarded.

And we pay attention to what they tell us. :)

That's what lint (well Gimpel's version at least, maybe lc-lint too?) is for ;)

Lint again ;)

And using another tool like that means you get a second POV on the code and you don't have to rely of the quality of diagnostics from the compiler (which range from excellent to pointless depending on the compiler).

Robert