NEWS AT SEI
This library item is related to the following area(s) of work:Software Product Lines
This article was originally published in News at SEI on: September 1, 2002
Editor’s note: A software product line is a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. As Paul Clements previously wrote in news@sei:
Product lines promise to become the dominating production-software paradigm of the new century. Product flexibility is the new anthem of the marketplace, and product lines fulfill the promise of tailor-made systems built specifically for the needs of particular customers or customer groups. What makes product lines succeed from the vendor’s (and developer’s) point of view is that the commonalities shared by the products can be exploited to achieve economies of production.…But software product lines based on interproduct commonality are a relatively new concept, and the community is discovering that this path to success contains more than its share of pitfalls.
In this new column, Clements, Linda Northrop, and other software product line experts at the Software Engineering Institute will contribute insights into how the software engineering community can reap the advantages of the product-line approach, while avoiding some of the pitfalls.
In his bestseller Chaos: Making a New Science, James Gleick related how some of the pioneers of chaos theory would, while relaxing in their favorite coffeehouse, compete to find the nearest example of a certain kind of chaotic system . A flag whipping in the breeze, a dripping faucet, a rattling car fender—they seemed to be everywhere.
I can relate. Lately it seems that no matter where I turn I see a product line. At airports I see product lines of airliners (such as the Airbus A-318 A-319, A-320, and A-321, a family that ranges from 100 to 220 seats but clearly share production commonalities) powered by product lines of jet engines and equipped with product lines of navigation and communication equipment. When I arrive at my destination, I rent an American mid-size car that is always pretty much the same except for cosmetic factors and features, even though it could have one of four nameplates on it. I wonder how much more expensive the cars would be if they had nothing in common? The hotel leaves a copy of the local newspaper at my door: the morning edition of the city-wide version. Someone else will get the afternoon edition of the upstate version, but it will have most of the same stories, all of the same comics, and come off the same presses. On my way to work I pass residential subdivisions where the houses are all variants on a few basic designs. Even the street signs are the same except for the names of the streets on them. While the actual street name is fundamental to a street sign’s function, it is inconsequential to its fabrication and is just a variation point.
We know that product lines have been around in manufacturing almost since there was manufacturing. Remember Eli Whitney’s idea of interchangeable parts for rifles in the early 1800s? They enabled a product line of firearms to be built that shared components. Remember the IBM System/360 family of computers? From the Principles of Operation:
Models of System/360 differ in storage speed, storage width (the amount of data obtained in each storage access), register width, and capabilities for processing data concurrently with the operation of multiple input/output devices. Several CPUs permit a wide choice in internal performance. Yet none of these differences affect the logical appearance of these models to the programmer. An individual System/360 is obtained by selecting the system components most suited to the applications from a wide variety of alternatives in internal performance, functional ability, and input/output (I/O).
This was clearly a product line, and the operating system that powered it was a software product line. And town plans where the buildings look like each other pre-date post-War suburbia by at least eight centuries. During the Pei Sung dynasty of northern China (960-1127 AD) a book called the “Ying-tsao fa-shih” was written by Li Chieh, the state architect of the emperor Hui-tsung, in 1100 AD and published in 1103 AD. This was a set of building codes for official buildings. It described in encyclopedic detail the layout, materials, and practices for designing and building official buildings. It listed standard parts and standard ways of connecting the parts as well as recognizing and parameterizing variations of the parts such as allowable lengths, load capacities, bracketing, decorations, allowed components based on the building’s purpose, and the options available for various component choices. The book also included design construction details that provided a process for building design and implementation of the design. While it was influential in spreading the most advanced techniques of the time of its first publication in 1103, by codifying practice it may also have inhibited further development and contributed to the conservatism of later techniques. Some scholars even claim that because of it, Chinese architecture remained largely unchanged until the beginning of the 20th century. (In a product line, you’ve got to know when your architecture has outlived its usefulness.)
But, like Gleick’s scientists, I find some of the best examples of product lines in places where I go to eat. Here’s something I saw on the menu at a little Mexican restaurant recently:
#16. Enchiladas verdes: Corn tortillas baked with a zesty filling, covered
with a green tomatillo sauce. Your choice of chicken, beef, pork,
#17. Enchiladas rojas: Corn tortillas baked with a zesty filling, covered with a red ancho chile sauce. Your choice of chicken, beef, or pork.
See what I mean? This restaurant clearly produces an “enchilada” product line. (Well, all right, “clearly” only applies to those of us who have been thinking about this for too long.) While admittedly a cheesy example—sorry—it actually provides a pretty good analogy with software product lines and the central concepts they embody.
The enchilada product line consists of seven separate products, differentiated by filling and sauce. This defines their variabilities. The corn tortillas are core assets because they’re used in every product. The red and green sauces are also core assets because they’re used in four and three products, respectively. And the meat fillings are also core assets, used in two products each. But the cheese is a product-specific asset, only used in the enchiladas verdes.
Some of the core assets have attached processes that indicate how they are to be instantiated for use in products. Here, the beef, pork, and chicken have attached processes that dictate how they’re chopped, seasoned, and cooked. The processes call for different spices to be added depending on the sauce.
All of the products share an “architecture”—tortillas wrapped around a filling, covered with sauce. And they also share a “production plan”—prepare filling, wrap filling in tortilla, cover with sauce, bake at 350 degrees for 15 minutes, garnish, serve.
This little product line provides economies of scope; the common ingredients let the restaurant stock a small number of food items delivered from a small number of suppliers. They provide personnel flexibility: the same person who makes the pork enchiladas rojas is, I would bet my house, the same person who makes the cheese enchiladas verdes. And by limiting the choices, many of the ingredients can be pre-prepared, allowing for rapid time-to-market, which in this case means time-to-table.
As a family, the products define a clear scope that leaves little doubt what’s in and what’s out. Chicken enchiladas are in. Beef enchiladas are in. And if you wanted cheese enchiladas with the red sauce instead of the green? Well, that’s probably open for discussion—a scope definition with a pronounced gray area is a healthy thing—but duck enchiladas with a white sauce are definitely out.
Finally, by making the commonalities and variabilities exquisitely clear, it’s easy to see how this product line’s scope could be expanded—offer new fillings and new sauces and perhaps new combinations. You could even see how this efficient production capability could be used to launch an entirely new product line to capture a new market segment: Replace corn tortillas with flour tortillas, lose the sauce, add lettuce and tomato and other condiments, and open a new restaurant chain that sells “wraps.”
If you already had a strong grasp of the concepts underlying software product lines, then this little culinary diversion probably had no effect, except possibly to make you hungry. If you didn’t, then perhaps the concepts are now a bit more palpable. In either case, the next time you’re at a coffeehouse or restaurant, try looking around to see how many product lines you can spot.
 Clements/Northrop, Software Product Lines (pages 6-8, 38-40, 41-44, 46-48, 180-183, 195-197, 226-229, 264-272, 295-299, and 427-430). 2001 Pearson Education, Inc. Reproduced by permission of Pearson Education, Inc. All rights reserved.
Dr. Paul Clements is a senior member of the technical staff at Carnegie Mellon University's Software Engineering Institute, where he has worked for 8 years leading or co-leading projects in software product line engineering and software architecture documentation and analysis.
Clements is the co-author of three practitioner-oriented books about software architecture: Software Architecture in Practice (1998, second edition due in late 2002), Evaluating Software Architectures: Methods and Case Studies (2001), and Documenting Software Architectures: View and Beyond (2002). He also co-wrote Software Product Lines: Practices and Patterns (2001), and was co-author and editor of Constructing Superior Software (1999). In addition, Clements has also authored dozens of papers in software engineering reflecting his long-standing interest in the design and specification of challenging software systems.
He received a B.S. in mathematical sciences in 1977 and an M.S. in computer science in 1980, both from the University of North Carolina at Chapel Hill. He received a Ph.D. in computer sciences from the University of Texas at Austin in 1994.
The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.
For more information
Please tell us what you
think with this short
(< 5 minute) survey.