Click here to view the complete list of archived articles

This article was originally published in the Fall 2006 issue of Methods & Tools

---

Introduction to the Emerging Practice of Software Product Line Development - Part 2

Charles W. Krueger, http://www.biglever.com/

Production

The production operation creates partially or fully instantiated product outputs from software asset inputs, using product decisionsto determine how to bind variations in the assets. Production is a keydiscriminator between different software product line approaches and those differences are described in this section.

Automation. Production in software product lines can be fully automated, completely manual, or somewhere in between. An example of afully automated production approach is application generators and productconfigurators, where product decisions provide sufficient information toautomatically generate the product outputs. An example of a completely manualapproach is a textual production plan, where software engineers interpretand follow directions in the plan and the product decisions to tailor,integrate, and provide "glue code" around the software assets in order to create products.

Periodicity. As with conventional software engineering, production of a product is typically not a one-shot activity. Products may needto be periodically reproduced to reflect enhancements to the software assets ordecisions. The frequency of periodic production may be measured in terms ofhours in an agile approach that utilizes automation or in terms of years in a waterfall and manual production approach.

Roles. Some production approaches define a separate human role for the production activity called application engineering, distinctfrom the domain engineering role responsible for engineering the softwareasset inputs. Other approaches do not distinguish between these two roles.Separate roles are common in approaches with manual production while a single role is more common in approaches with fully automated production.

Production Artifacts

Product Decisions

Representation. The different formats used to represent product decisions range from informal textual descriptions to formalmachine-interpreted languages.

Guidance. Some software product line approaches provide guidance when making decisions for a product, ranging from written heuristics,to constraint checking, to expert system guidance. Guidance helps to reduce thetime, complexity, and errors in the decision-making process, particularly for large numbers of interdependent decisions.

Role. The decision-making role for product creation may be an engineering role such as an application engineer or a domain engineer, orit may be a non-engineering role such as a product marketer, a sales person, orthe customer. The role should be given to the person who can make the bestdecisions at the best time. This will in turn influence the binding time (or times) for production.

Replayable. For periodic production of products, previously-made decisions for products can be automatically "replayed" rather than manually recreated. This requires stored decision representations and automated replay mechanisms.

Software Asset Inputs

Representation. The software asset inputs for software product lines can come in many different formats, ranging from immutable binary executables to mutable source code that is manually modified, tailored, or extended during production. Assets are not limited to source code and can include test cases, documentation, requirements, use cases, architecture and design descriptions, and so forth.

Variation points. There are many approaches for representing points of variation in the software assets as well as mechanisms to instantiate them. The best choice is influenced by the desired binding time and the degree of production automation desired. For example, a variation point for development-time binding without automation could be an empty block of source code that an application developer fills in. Variation points for runtime binding with full automation might be a programming language if-then-else statement whose behavior is determined by user preferences settings made by the customer.

Product Outputs

Representation. The product outputs can take on many different formats, such as binary versus source and mutable versus immutable.

Partial instantiation. If the product outputs are partially instantiated in one stage of variation binding, the unbound variations become the variation points in software asset inputs for the next stage.

Evolution and Configuration Management

As with conventional software engineering, the software artifacts in a software product line (the assets, decisions, and products) are subject to maintenance and evolution. That variation over time, due to evolution, is distinct from the variation found in the variation points in the software assets, due to the variation among products in the product line space. This distinction is characterized as variation in time versus variation in space.

Conventional configuration management can manage some of the issues of variation in time for a software product line. However, theproblem is complicated by dependencies among the different software artifacts inthe production process. As illustrated below, evolutionary changes to anartifact may require that those changes be propagated to interdependent downstream or upstream artifacts in the production workflow.

Update paths. A change made to an upstream artifact may need to be reflected in all existing downstream artifacts previously producedfrom the original artifact.

Feedback paths. If downstream artifacts are mutable, then a change made to a downstream artifact may need to be fed back to the originalartifact or artifacts from which the original downstream artifact was produced.Automated production and replay can eliminate the need for manual updates and all feedback paths.

Product Line Scope

The scope of a single software product is defined by the bounds of the capabilities provided in that product. Similarly, the scope ofa software product line is determined by the bounds of the capabilities providedby the collection of products in the product line. The scope of the products inany product line can be characterized in terms of six dimensions in productusage scenarios: who, what, when, where, how,and why. Multiplicity along these dimensions leads to multiple products in a product line.

There are two primary approaches to managing scope software product lines, proactive and reactive. In the case of a pureproactive approach, all of the products needed on the foreseeable horizon aresupported by the product line. In the case of a pure reactive approach, only theproducts needed in the immediate term are supported by the product line and newproducts are incrementally added as the needs change. There is, of course, a continuum between the two.

The reactive approach requires less up-front effort than the proactive approach since the initial scope coverage is smaller. To implement thesame scope coverage, the reactive approach incrementally defers the cost andeffort over longer period of time compared to the proactive approach. With theproactive approach, the up-front investment for implementing a broader scope isamortized over time when new products within the scope are deployed with littleor no effort. It is possible for early stage artifacts in a software productline, such as the architecture, to have a more proactive scope than later stageartifacts, such as the source code. However, the overall scope of the productline is defined by the scope of the product collection that can be produced, tested, and deployed.

Page 1    Page 3    Back to the archive list