Service Oriented Design v Embedded Implementation

I've found myself writing a lot of UML recently. Now being in a position to spend time on designing something rather than just being made to dive right in is something of a novelty but at-least it's a good kind of novelty.

Now the slightly strange part about this design work: I'm using a service oriented technique to design an embedded system that will be implemented using a non OO language (namely C).

What you tend to see in embedded circles in terms of design are state diagrams and sequence diagrams, defining how systems are physically going to work but not defining the overall structure of the code. We're going a step further and using UML class and component diagrams to define the structure of the code in terms of classes.

Now does this make sense given that we're using a non OO language and have to optimise the code to run as an embedded system?

We'll yes if we make a few assumptions.

Firstly the problem of language: this is a bit of a myth that you can't use C to produce OO code. It's perfectly possible to structure C to emulate most, if not all, the features available in a more OO oriented language like C++. In the past I've even managed to do generic programming using macro preprocessing (but that's a whole different article). But this isn't what we want to do here.

Why? Well we're targeting this design at an embedded system, a hard real-time embedded system at that, so code size and runtime optimisation is king.

One of the main optimisations at this level is eliminating function calls since each time a function call is made a stack frame is constructed which takes time and stack memory, so this is to be avoided in operations that are executed frequently. Conversely to save code space you may want to use functions to reduce code space used. Of course you also want to make your code maintainable. It's all a bit of a balancing act which comes with experience.

So what chance does an OO design stand at this level of coding?

So this is where my partial rant begins.

One of the big misconceptions about OO design is that it has to boil down to a service-oriented implementation and that all the services/classes have to be the separate entities described in the design. Once you've defined a service pipeline you're at liberty to optimise it for efficiency. One of the main optimisations you can make is combining loosely coupled services into a tightly coupled single service. Now the design conceptually stays the same but the implementation may have a number of composite services instead of loosely coupled ones.

So for our implementation we have to take this to the extreme. Instead of combining service we may have to combine functions so a set of function calls down a chain of classes may be optimised into a single function body. There are of course things you can do to make the code more understandable, such as defining functions as macros etc but you must always keep an eye on code size verses efficiency. As I mentioned earlier it's a balancing act.

The one thing that doesn't increase code size are comments. I'm a great fan of commenting code especially when it's complicated.

So what we end up with is a uber tightly coupled implementation of our original design, but it's still an implementation of the original design.

Mini rant over.

- Posted from my phone (please excuse grammar and spelling. Well more than usual anyway)

No longer an academic

Hum! I'm no longer an academic as of friday. Suppose I'm going to have to rework all my website blurb as well as my CV. Oh well, these things are sent to try us.