Ever since I matched Test Driven Development (TDD) with embedded systems programming, I’ve wondered how TDD fits in with software design. In the past, I have expressed embedded systems with a small subset of UML including: sequence diagrams, flowcharts, and state charts. There seems to be a dichotomy between TDD and design, because as soon as I say the word “design” I think of the waterfall approach: Requirements → Design → Implementation. Are software design and TDD mutually exclusive?
Using QP taught me to see this question in a whole new light. Maybe the problem isn’t our tools. Maybe it’s our process itself.
The Problem with Code Generation Tools
A key requirement of TDD is that you can sustain a quick cycle of design → code → test. It’s been my experience that code generation tools actually impede this quick cycle. Because the model files cannot be merged, all model files have to be locked in revision control before an edit can be made. Not being able to merge the model is the key impediment to collaborative development and continuous integration on a large embedded project with many developers.
What Makes QP Different?
QP is a different kind of model-building product. It’s focused specifically on statecharts for embedded systems, with an accompanying framework compiled into your embedded code. Don’t worry, it’s lightweight enough for all but the very smallest embedded applications.
QP’s framework gives you a major head start when putting together an embedded product: its event queue system seeks to ensure that you never miss an important input event. Events can also be prioritized. Without this event queue, you’d have to hand roll a custom queueing mechanism for every input to your system.
QP also differs in what it’s not. It’s not a system for capturing and modeling all of the code in your system. It only describes the state-based parts of your code, and only as much of it as you want. Things like input processing and response are totally outside the domain of QP.
Seeing Things Differently with QP
Working with QP made me realize something. Perhaps the problem with the old modeling tools is a policy problem and not a tool problem. Our previous policy was to model everything, even code that was written outside of the model. This lead to a bottleneck in version control and continuous integration. QP can’t read code and incorporate it into its model, so such a thing wouldn’t have been an option.
QP uses a single configuration file that appears to be xml. This type of setup means that it would usually be able to merge, thus having an advantage against other tools. It seems to be a great asset for all but the simplest applications.
Fortunately, it’s also open source. It uses GPL so that any derived application will also have to be open source. This is not acceptable with certain OEMs, but in that situation there’s a license you can purchase.