OOPSLA 98 Object Technology and Product Lines Workshop Position Paper
The Role of Object-Oriented Techniques in a Product Line Approach
The theme for this workshop is "How do current object-oriented technical practices support or hinder a product line approach?". My position is that object-oriented technical practices used now in developing custom products are on balance neutral with regard to a product line approach. This position suggests that object-oriented practices are beneficial in a product line approach but that non-object-oriented practices are no less effective in this respect. Stated another way, a product line approach is adaptive to and not dependent on technical practices in current use by software developers. This position is based on three factors.
The first factor is that there is only one fundamental difference between custom product development and a product line approach. That difference is variability, the idea that there is a set of similar problems and associated solutions that we could treat uniformly if we conceive of them as a family. When developing a custom product, the goal is to eliminate variability, by resolving away all uncertainty and alternative solutions, to solve one problem. In contrast, the goal in product line development is to discover and illuminate all uncertainty and alternatives, eliminating only undesirable or unimportant differences, so that all viable solutions to a set of similar problems should remain possible. The goal in a product line approach is to formalize variability and enable all useful solutions to any interesting problems (that is, all problems of a particular sort that an organization might ever wish to solve) and to reduce the non-mechanical aspects of producing a solution product to simply the explicit resolution of variability associated with the product line.
The second factor behind my position relates to certain object-oriented technical practices that seem to support expressing variability. The basic object-oriented concept of a class embodies the idea of a set of similar objects and could be viewed as representing a family (but only extensionally in set-theoretic terms whereas the ideal is to do so intentionally). In principle, the concept of specialization (that is, subclasses with strict inheritance) provides a way to represent that some of the objects in a class are "more alike" than others and thus implicitly identify one degree of variability in the family (having trait A versus not having trait A). However, as a development-time capability, this has marginal value: this means of expressing variability is both incomplete and cumbersome, requiring creation of one or more new subclasses for every difference in the product line. Another more useful mechanism is generics, represented in Ada with generic packages and in C++ with templates. Generics permit parameterization of class definitions with types and constants, permitting compile-time instantiation of tailored classes without hand coding. Again, however, this mechanism is incomplete as a means of expressing variability.
The third, and most fundamental factor, is that representing differences among a set of products is properly orthogonal to representing the substance and form of products. Techniques for custom product development are, and should be, optimized to eliminating variability. Extending or overloading these techniques to express variability introduces unnecessary confusion and complexity. The idea of a product line approach is that it is possible to leverage the common aspects of a set of similar products by discovering and formalizing their essential differences. If the differences among a set of products are known, any one of those products is distinguishable with respect to the set as a whole purely in terms of those differences. By expressing the causes and form of variability in an orthogonal notation, there is an effective separation between expressing a product and expressing a product line as a family of products.
To elaborate on the view that object-oriented notations are incomplete for expressing variability, the ability to represent variability fully requires five types of construct:
- Abstraction: a means to define a family concretely as a parameterized constructor of instances, by composition of fragments relative to simple, aggregate, optional, and multivalued parameters and expressed using the other 4 types of construct recursively
- Substitution: a means to express that part of the content of instances either is common and thus fixed or comes from parameters and differs accordingly
- Selection: a means to express that part of the content of instances differs based on predicates over parameter values
- Repetition: a means to express that part of the content of instances is repeated in accordance with the number and ordinality of a multivalued parameter's value
- Instantiation: a means to express that part of the content of instances is an instance of a family defined by an abstraction and to express the parameters that indicate which instance is needed
Classes and subclasses support only the substitution construct and only at the granularity of methods (that is, subclasses give the ability to add or replace methods defined in a class). Representing a family in the form of a class hierarchy provides only implicit expression of variability and requires undesirable redundancy (in that common fragments of a variant method are repeated in all its versions in different subclasses). Generics add support for the abstraction and instantiation constructs and support substitution at the level of type and name tokens. Use of an associated preprocessor can add explicitness in the expressiveness of selections but the usual restriction of parameters to simple text values limits its utility.
Full variability can best be expressed using a meta-level notation and associated tool for translating product families defined with this notation into instance products. With such a notation, it is feasible to create a definition of families of components, work products, or entire products that are the equivalent of tens, hundreds, or thousands of what would otherwise have to be separately crafted instances. This approach is applicable to plans, user documentation, requirements or design specifications, test scenarios, code, or any other recurring development work product.
Regardless of the efficacy of object-oriented mechanisms for expressing variability, the value of using those mechanisms is questionable if there is no encompassing discipline for establishing what variability is actually needed. Specifically, this means an analysis beyond the scope of a single product development to establish the diversity and change expected in what customers need in such products. The usual effect of omitting this analysis is an emphasis on implementation-level variability without rationalization in terms of needs-level variability. This leads to generic implementations that reduce potential leverage by transferring effort from domain engineering's product line implementers to application engineering's individual product implementers.
In substantiation of my position that a product line approach is adaptive to different technical practices, the Reuse-driven Software Processes (RSP - aka Synthesis) methodology has been used repeatedly, achieving the objectives of a product line effort, without ever displacing the existing technical practices of an adopting organization. Instead, new practices are introduced and existing practices adapted at the level of Domain Engineering to address the need to identify and express variability. This then permits the streamlining of Application Engineering activities to derive products entirely in terms of variability elimination. RSP has been used formally by multiple programs in each of Rockwell, Boeing (including the DARPA STARS program), Lockheed-Martin, Lucent (using the FAST derivative of Synthesis), and Thomson-CSF. Domains have included software for communications, training simulators, satellite avionics, air traffic control, train control, and global positioning receivers. As a refinement of RSP, our Domain-specific Engineering (DsE) methodology defines a product line vision of disciplined engineering and streamlined manufacturing of software and system products. Adoption of the DsE methodology is guided by explicitly identified factors for the systematic derivation of a tailored approach suited to an organization's capabilities and objectives. This derivation specifically accommodates the preferred technical practices of the adopting organization.
This experience has shown that an effective product line approach is not dependent on the choice of product development methods to be used. Those methods should be chosen because they are effective in creating solutions to relevant problems. Any set of methods can be extended to accommodate addressing variability to represent a family of such products. Current object-oriented technical practices are valuable in developing a product, while also addressing opportunities for standardization (in architecture and implementation) across similar products but they fail to address the essential concern of product line development for variability across those products. Addressing variability requires enhanced techniques and a broader scope than single schedule- and resource-sensitive projects can provide. An effective product line approach also requires efforts, not considered in current object-oriented technical practices, to establish a foundation of standardization and variability at higher levels of market needs, customer requirements, and application engineering process.