Embedded software design methodologies have been developed by the dozen if not by the hundreds. Methodologies are meant to help guide engineers toward developing software that is more robust, has fewer bugs, and is more maintainable, to name a few coveted characteristics. Methodologies vary in focus from being heavily reliant upon documentation all the way through being focused on cleverly crafting code to act as documentation. One methodology that can be useful for developing embedded software interfaces is Design by Contract.
The term Design by Contract was first used, and later trademarked, by Bertrand Meyer in connection with the object-oriented programming language, Eiffel. The idea behind Design by Contract is that developers should be designing precise and verifiable software interfaces for components in their applications; in essence, they create a contract between the interface and the application code that will use the interface. For example, when creating a hardware abstraction layer interface for a GPIO component, each component interface would contain some method for defining the components pre-conditions, post-conditions, and invariants. In many circumstances, developers using an interface are often left in the dark about these conditions which can be quite dangerous.
|Figure 1 – Example Interface Header using Pre-conditions and Post-Conditions.|
Mastering Modern Debug Techniques. Attendees of this session will walk away with an understanding of the modern debug techniques available to engineers in todays development cycle. Attendees will learn how to quickly setup SWV and how it can benefit their development effort. Finally, a look at ETM and code coverage analysis will be examined. Don't miss "Mastering Modern Debug Techniques" at ESC Silicon Valley, Dec. 6-8, 2016 in San Jose, Calif. Register here for the event, hosted by Design News ’ parent company, UBM.
For a designer to share and identify the pre-conditions and the post-conditions for a component makes sense, yet, very rarely do developers explicitly provide this information. An application developer would be happy to know that they need to enable a clock and initialize the interrupt vector controller before calling the Gpio_Init function rather than spending 30 minutes or more debugging the system only to discover that the initialization function doesn’t do it for them. Design by Contract provides application developers a contract for using the component. If the preconditions are met, then the interface is contractually guaranteed to provide the specified post-condition from calling the interface. An example Doxygen interface function header can be seen in Figure 1 that demonstrates how easily a developer can specify the contract by simply adding comments for the PRE-CONDITIONS and the POST-CONDITIONS.
Since the pre-conditions and post-conditions are fully specified up front, the component developer can use C assertions to validate that the contract is being met by the component user. For example, the component implementer would create an assertion to verify all pre-conditions including function input values. If any precondition is not met or an input value is out of range, this is a bug in the application software and the assertion will stop the application from executing and provide a message stating which file and line number the