AdaIC News Fall 1996

Product-Line Software Reuse
from an Automotive Perspective

| Engineering paradigms |
| Reusable components and component brokerage |
| Looking ahead |

by Fred Maymir-Ducharme, PhD

My son understood the value of reuse at quite the early age. His friend Bobby next door had a new 4-wheel drive truck to play with, and he didn't. His allowance wasn't enough that week to go out and buy one like his friend, so he decided to make his own from the array of cars and trucks in his toy box. He took the axle and wheels from a big plastic car to replace the little wheels on one of his average-looking play trucks. He then ripped out the shiny engine from a model-kit car and glued it on the hood of this project. He ended up with a pretty mean-looking 4-wheel drive truck, similar to Bobby's and yet unlike anyone else's in the neighborhood!

Reuse is basic to every engineering discipline; and it's taking software engineering quite some time to realize this is the fundamental key to becoming a "disciplined" engineering practice. Electrical engineers understand the value of having standardized computer chips -- where their functionality and interfaces are well defined and understood (taught in schools, readily available and documented in numerous manuals). Chips may include merely simple "and," "or," "nand," and "nor" operations (component reuse in the small) or go all the way up to Very Large Scale Integration (VLSI) (component reuse in the large).

Electrical engineers also have breadboards and schematics (analogous to software architectures) to help them combine and/or interchange chips and develop (or reengineer) new electronic devices. Granted, electrical engineers are only dealing with binary bits (0's and 1's), while software engineers can have an unlimited range of data and messaging types; but the size and complexity of an oscilloscope, a mainframe, or a massively parallel computer give credence to the size and complexity of their problems and solutions. When asked to develop a new computer, an electric engineer will not go back to the drawing board, capture the requirements, design the computer from scratch and then move into wire-wrapping and-gates, or-gates, etc. (analogous to the way we develop most software these days). To put together a new computer, the electrical engineer will (re)use existing schematics, breadboards, VLSI chips -- even bigger components like disk drives, monitors, and printers. Likewise, a civil engineer builds a house from a variety of architectural blueprints and standardized components: nails, screws, hinges, 2x4's, 2x8's, doors -- or sometimes, on an even larger reuse scale, prefabricated home components for roof and wall structures. These exemplify the publicly-held, formally transmitted, experience-based technology base of engineering models essential to a mature engineering discipline.

But the intent of this paper is not to discuss reuse in other engineering disciplines. We will look at how simple reuse looks to the automobile business. It's easy to explain terms like domain-specific, process-driven, architecture-centric, and technology-assisted engineering to someone who understands cars. Reuse is a major element of any mature, disciplined engineering practice, even aspects of "automotive engineering" that aren't commonly called "engineering". Ø

Engineering paradigms

The automobile industry has many desirable attributes, analogous to those sought by a disciplined software-engineering practice; for example, successful software factories mirror automobile factories in a number of ways.

Domain-specific -- Auto shops and dealers specialize in different ways and from many perspectives. Some distinguish between cars and trucks, while others specialize in performance vehicles.

Analogously, software domains distinguish families of related systems from different perspectives. Within the context of software, a domain (as used in terms such as domain engineering and domain analysis) refers to a group of common or related systems. These systems may share a common design and components (e.g., relational databases), common capabilities/services (e.g., software-engineering environments include the capability to compile, edit and debug software) or common technology (e.g., compilers are all built on lexes and parsers.)

Process-driven -- Assembly lines revolutionized the automotive industry. Factories put cars together, and dealerships sell and repair them -- all using well defined steps and rules. The software analog, the application-engineering process, is pretty simple to see.

Architecture-centric -- Automotive architectures include: the chassis, standardized parts/components (e.g., engines, transmissions, wheels, etc.), and connections (e.g., 1/2" nuts and bolts, 14" rims and P195R14 tires, etc.).

Likewise, a software architecture is made up of components -- e.g., a command center includes a database management system (DBMS), message handler, geographic information system, etc. The connections might be varying application program interfaces and middleware such as the database language SQL. The architecture would also include constraints (e.g., realtime system constraints and application-specific component constraints) and the associated decision rationales.

Technology-based -- Technology can include concepts, methods, processes, and tools. The automotive industry has leveraged numerous concepts such as automation, assembly lines, and repair shops. To ensure the safety of automobiles, there are Total Quality Management methods, such using crash test dummies. Automotive factories have very well defined and continuously improving processes. And there is certainly no shortage in the automotive field of power tools and robotics to support auto engineering and manufacturing.

Software technology includes concepts such as domains, assets, software architectures, and reuse libraries; methods such as Rumbaugh's Object Modeling Technique for object-oriented analysis and design; processes such as application engineering, domain engineering, and information/enterprise engineering; and tools for compiling code, modeling analyses, specifying architectures, etc.

Auto repair and maintenance share considerable similarities with software maintenance:

And an auto customization shop is very much like a reengineering shop.

Software can be reverse engineered from code to design and if necessary, from design to requirements. There are tools and techniques to reverse engineer applications to discover their software architecture.

Product lines are primarily an economic decision -- based on supply and demand

Automobile dealers really understand the product-line approach. The product-line approach extends and constrains systematic, domain engineering to meet the business-specific needs of an organization, based on business analyses and product-specific market lifecycles.

They may not be familiar with the term "domain," but maybe the old "line-of-business" analogy will bring them back into the discussion. The automotive market (in software terms, the "problem space") can be described from different perspectives. Some dealers (and manufacturers) deal only with the automobile domain (e.g., Saturn), while others broaden the scope to include trucks and recreational vehicles (e.g., Ford and General Motors).

Obviously, there's considerably more commonality across a small, well-bounded domain like passenger cars -- they all have a chassis, a steering wheel, an engine, four wheels, and a body. There's still a considerable amount of commonality across a broader-scoped domain that includes trucks and recreational vehicles -- they include steering wheels, engines, wheels, etc.; yet they may have six wheels instead of four, more ruggedized chasses, suspensions, and engines, etc.

So also, a small software domain (e.g., compilers or DBMSs) has more commonality to exploit than broader and larger domains (e.g., a family of related systems such as the Army's Sustaining Base Information Services (SBIS) or the Air Force's Global Combat Support System (GCSS) where common data/objects and functions are shared, but considerable variance across the systems reduces the "density" of commonality. But it is in these large systems that a disciplined engineering approach is most needed. Domain engineering not only exploits the commonality across these systems, but engineers the variance to ensure interoperability and avoid "stovepipe" (non-interoperable) applications.

In either case, all of these offer various product lines (in software terms, "a solution space"). Most auto makers (e.g., Chevrolet, Ford, Chrysler, Honda, Toyota, etc.) offer a variety of product lines. They offer a variety of styles: e.g., small, medium, and large cars, coupes, convertibles, two-door, four-door, hatchbacks, etc. And they offer a variety of options: e.g., AM/FM radios, AM/FM/cassette stereos, stereos with CD players, leather or vinyl seats, air-conditioning, etc.

The key to product lines is market demand -- there are unlimited options in the automotive market, but not all are available from any single automotive manufacturer or dealer. The automotive domain is continuously analyzed to identify the most economically advantageous subset of automotive styles and options that meets the majority of the market demands. An automotive company can meet 80-90% of the market needs (domain requirements) with only 40-50% of the market-defined solutions.

Likewise, the equivalent software (product line) approach is to support the capabilities/requirements within the selected domain that makes the most economic sense. This approach has been very effective for several software companies in very specialized domains. AT&T Bell Labs, for example, has a well defined 5ESS (System 5 -- Electronic Switching Systems) product line, where the features and capabilities of each product release are predetermined and the list of available features and capabilities are the same for all of their customers.

It is important to consider the business model behind product lines. A product line optimizes production to meet a majority of the market with the minimal set of components -- maximizing the potential for profit. A product line includes a well defined (and limited) set of options and has made the decision not to support additional options or specializations because of economic analyses.

It's important to differentiate here between market products and market product lines. DeLorean, for example, developed and sold a single product, as did Ferrari, Yugo, and others. These products obviously leveraged off existing auto industry-standardized auto architectures and auto components, but they customized their products to meet specialized market needs not met by the major auto manufactures like Honda, GM, and Ford. It should be noted that in these cases, either the custom-made product is very expensive and for a small portion of the market (e.g., Ferrari) or the company was unable to remain in business (e.g., the Yugo and DeLorean).

A software development organization that hasn't optimized to a product-line, software-engineering discipline likewise runs the chance of failure and cannot compete efficiently against a product-line-oriented organization. Ø

Reusable components and component brokerage

The automobile industry has matured to the point where de facto standards govern most of the automobile architecture -- components, connections, and controls.

Auto shops can be viewed as equivalent to centralized software repositories. If they are properly organized, and if the specs for your model are available in the shop, you can generally find what you are looking for. Otherwise, you can take a chance. Ø

Looking ahead

In software, the state of the practice is somewhere between the horse and buggy days and Henry Ford's manufacturing line. The production of software is evolving into an engineering discipline -- which leverages a stable technology base (domain models, software architectures, product-line components, etc.), applies routine engineering, and develops reliable products using validated components and processes.

Class libraries are a modest example of this process, akin to the stock room an ordinary worker can access. Software factories will evolve as a larger demonstration of the process.

Automobile manufacturers have learned to separate factory costs (e.g., facility, tools/equipment, training and research) from product costs (e.g., raw materials, labor and utilities. They have learned that the additional capital investment in the factory yields increased productivity and reliability, resulting in lower costs per product. A software factory must likewise separate the factory costs (e.g., domain engineering, domain management, process engineering, integrated software-engineering environments, software architectures, training and metrics) from the product costs (e.g., application engineering, integration, testing, COTS licensing and configuration management). A disciplined, software-engineering product-line paradigm can then realize the same benefits: faster, better and cheaper.

What will the impact be? What will things look like? We don't know -- any more than Henry Ford could have predicted the social consequences of the Interstate Highway System. We can suspect, though, as the automobile industry found in the 1970s and 80s, that if we don't meet the needs of the market, others will! Ø

        Back                    Contents                    Next