5 lessons on embedded software modeling

-July 22, 2015

Software models can help developers understand, clarify, and communicate ideas about their code and the user requirements it must support. But I’ve learned through experience, surveying, and networking that embedded developers are --unfortunately -- notoriously bad at developing software models. At ESC Silicon Valley this week, I had the opportunity to sit in on Bruce Douglass' “Bruce's Top 10 Modeling Hints” session to learn more about developing effective models. Here are some of the lessons I took away that every developer should consider when designing their next embedded system.

Lesson #1 – Specify the purpose of the model

Targeted properly, models let embedded software developers better understand a system before ever having to write a single line of code. They act as an abstraction and serve the purpose of answering a specific question about the system. Before developers start randomly filling in a model, then, they should stop for a moment to define the purpose of the model and the specific question to answer.

To help in specifying the purpose, Bruce's recommendation is that developers add a mission statement to the model that states its purpose. A brief mission statement will not only serve as a reminder to guide the model's developer but will also inform future maintainers as to the model's purpose.

Lesson #2 – 80% of modeling is covered by three (+1) UML diagrams

The majority of an embedded system can be modeled using just three diagram types. The diagrams that are most commonly used are class, state, and sequence diagrams.

  • Class diagrams provide a developer with a way to define software blocks or classes and their interactions within the software system. These diagrams then help developers understand the bigger picture and see how different blocks of code will interact with one another.
  • State diagrams, a type I personally use religiously, help developers to depict the system's different software states and how the system moves from one state to the next.
  • Sequence diagrams can be used to depict a series of events and behaviors between inputs, outputs, and system components.

An extra diagram that may occasionally be needed (the +1) is the flowchart, which is probably the diagram that nearly every developer is familiar with.

Lesson #3 – Requirements can be modeled

Usually developers get or develop a software requirements document that is then used to develop the software's design. That document is important. In Bruce’s talk, he pointed out that the cost to fix a defect at the requirements stage is roughly $30, whereas catching that defect once a device is deployed could cost millions to detect and resolve. Developers can take advantage of the UML Use Case diagram to model and define the software's requirements in a visual and precise manner.

Lesson #4 – Reuse design patterns of proven solutions

Why reinvent the wheel if there is a known solution to a problem? Computer science offers developers a number of proven solutions to common problems encountered in nearly every embedded system. Design patterns offer a way for developers to leverage the experience of others and develop a system faster and more robustly than if they start from scratch. Bruce Douglass has written a number of books on the topic, including “Design Patterns for Embedded Systems in C,” which is quite insightful.

Lesson #5 – Continuously verify and test

Embedded software developers will generally spot check their work as they write code, but the bulk of testing really comes at the end. Usually, large amounts of code are written and then handed off to the QA team to beat up and prove that there are no defects.

But remember earlier it was mentioned that the sooner a defect is detected the lower the cost? For this reason, testing and verification of an embedded system should occur at every stage and iteration of the system. Breaking the system up into small pieces that are modeled and tested, then implemented and tested, is a great way to start proving that the system works. With each iteration, more pieces can be added that once again are tested and verified before adding yet more to the system.

Conclusions

Embedded software developers need to get better at modeling their software and system before ever writing a single line of code. These five lessons from Bruce’s ESC talk are a great first step for developers to start building better models that will yield more reliable and cost-effective systems.

Jacob Beningo is a Certified Software Development Professional (CSDP) whose expertise is in embedded software. He works with companies to decrease costs and time to market while maintaining a quality and robust product. Feel free to contact him at jacob@beningo.com, at his website www.beningo.com, and sign-up for his monthly Embedded Bytes Newsletter here.




Join over 2,000 technical professionals and embedded systems hardware, software, and firmware developers at ESC Minneapolis Nov 4-5, 2015 and learn about the latest techniques and tips for reducing time, cost, and complexity in the embedded development process.

The Embedded Systems Conference and EDN are owned by UBM Canon.


Loading comments...

Write a Comment

To comment please Log In

FEATURED RESOURCES