I'm currently working on a project where I'm writing the firmware for an electronic system in C, and have been asked to produce documentation on the development/evolution of the software for the embedded devices. Having developed software in the object oriented paradigm I know to use UML to document the software such as class diagrams with objects, however this does not work for documenting the development of my embedded system. So what should I produce to document the development of my firmware?
Even for a system that is not designed according to the OO paradigm, you can still use UML notation to document the system, possibly extended with some Data Flow Diagrams (as I can't immediately find a corresponding diagram in UML). Diagrams worth looking into, even for non-OO systems are:
- State (Transition) Diagrams
- Use Case Diagrams
- Sequence Diagrams
When modeling a non-OO system, you may have to be a bit flexible as to what you model as a 'class'.
For example, if you have a header file stack.h like this
struct stack; struct stack* stack_create(void); void stack_destroy(struct stack*); void stack_push(struct stack*, void*); void stack_pop(struct stack*); void* stack_top(struct stack*);
with corresponding implementation, there is nothing to stop you from presenting that as a 'class' stack in your models.
You can make an object-oriented design and implement it in C, even though C does not directly support object-oriented concepts.
See for example Rumbaugh et al., "Object-Oriented Modeling and Design", Chapter 16, Prentice-Hall 1991, ISBN 0-13-629841-9.
You do the same design only with conceptual modules (like you really should've done in OO design) rather than explicit classes. In C, those modules tend to be functions, structures, or some bundle of functions, structures or both.