Software Architecture for Product Families: Principles and Practice

Although many embedded projects are one-offs, many aren’t, but are part of a product family developed simultaneously or sequentially. Take a look at many of the embedded devices in popular use today. For example, cell phones are designed in versions for specific telecommunications standards and diverse markets and feature sets.

Although new products and high-end products might appear dissimilar to older, lower-end devices, many of those functional changes are enabled mainly through software. Planning and designing the software architecture of embedded systems with the explicit goal of having the device be part of a product family would, therefore, seem to be an obvious and intuitive task. Yet it’s not common practice. Instead, code is written to implement today’s requirements, and not as part of a general solution. When the next version of the embedded device is needed, the code is largely rewritten.

Software Architecture for Product Families is an attempt to solve the problem that devices are designed, architected and coded largely as individual systems. Not a textbook, this dry and humorless book is actually a report on a project called ARES (Architectural Reasoning for Embedded Systems) carried out in Europe and funded by the European Commission. The project’s goal was to understand the challenges faced in product-family embedded development in industrial settings, and then to offer some rough solutions.

Let’s see if any of the challenges identified by the ARES team sound familiar: difficulty in developing variations of software for similar products; managing the explosion of different product versions; low degree of code reuse, despite functional similarity and use of object-oriented design tools; inability to predict or control performance of large distributed real-time systems; lack of conformance between original design documents and final implementation; and inability to recover an existing system’s software architecture by examining its source code.

Start Software Architecture with the case studies at the back of the book. The best is in Chapter 5, where van der Linden relates the experiences that Philips Research Laboratories had in attempting to develop a general software architecture for mass-market television sets. The problem Philips faced was that many of the architectural decisions existed only in the minds of the architects—making it impossible for the software designers and programmers to strictly adhere to the architecture. Worse, there were no tools available to help. It was also very hard to train new software engineers to develop the TV’s code. It’s a broadly applicable problem and fascinating to read about.

Once Chapter 5 has given a good idea of the practical implications of the architectural difficulties, go back to the beginning. Chapters 1 to 4 discuss the broad challenges and key concepts.

The ARES project developed a four-part metamodel of software architecture, explained in the first chapter: architecturally significant requirements for construction, use and evolution; key concepts for understanding the system; structure of the components and how they are integrated into a complete system; and the texture that makes the components consistent and manageable.

Building on that framework, the authors explore architecture description languages, or ADLs, which provide a formal level of abstraction for dealing with complex systems. The book doesn’t recommend any particular ADL—and, in fact, claims that no existing ADL does a good job of accommodating product families, as opposed to individual products. Plus, many ADLs are internally developed and domain specific. The authors do emphasize the need for formal ADLs, and the requirement to find or build software tools that can work with the ADLs, and then present two ADLs: Darwin and Koala.

The third chapter goes into the key concept of software architecture assessment, or ensuring that an architecture meets the metamodel requirements introduced in Chapter 1. It’s a tough issue, and one that has had little research up to now. Any good assessment technique needs to take into account both functional and quality requirements, often ascertained via metrics, prototype experiments or other means. The book does an excellent job reviewing this important area.

Finally, Chapter 4 delves into the challenge of software architecture recovery, or the techniques and processes required to uncover an existing system’s architecture based on available information, including reverse-engineering and exploration of a system’s major properties. Why is that important? Documentation of an existing system is one reason, as well as assessing if an existing system truly meets current requirements. Other reasons include maintenance, preparation of modification or evolution of the system, or building a replacement system or new members of the product family.

Of course, examining a system can tell you how it was built and can help unveil some of its requirements, such as for redundant data paths, or for real-time performance of certain tasks, but that examination can’t tell you why it was built that way. Still, the ARES project has performed valuable work, including the development of an architecture recovery framework for product families, which begins with the examination of individual systems, and then a process of identifying family vs. individual system architectural properties.

Now it’s back to Chapter 5, the first of the three case-study chapters. The Philips case was about the development of an architecture description language. The Nokia Research Center focused on family architectural problems in the telecommunications giant’s switching systems and handheld cellular telephone families. Asea Brown Boveri presented the company’s challenge and success in recovering the architecture of a family of embedded real-time locomotive control systems.

If your organization produces families of embedded products and would like to formalize the architecture of those product families to improve quality, reduce costs, ensure that the systems better meet broad requirements, and simplify the maintenance and evolution of these product families, this is an important book to read, particularly for readers with a clear understanding of the fundamentals of software architecture. The authors are to be commended for producing such a clear treatment of a complex topic.

Reprinted with permission from SDTimes. Originally appeared in Issue 13, September 1, 2000.