PLE: A STREAMLINED REUSE MODEL

16.1 PLE: A STREAMLINED REUSE MODEL

Given that software is very labor-intensive (hence hard to automate), that software labor is very expensive (as it requires a great deal of specialized expertise), and that software products are very hard to produce (due to their size and complexity), one would expect software reuse to be an indispensable component of software engineer- ing. Indeed, for an industry that is under as much stress as the software industry, reuse offers a number of significant advantages, including the following:

• Enhanced productivity, which stems from using the same product in a wide variety of applications at little or no extra cost. • Enhanced quality, which stems from investing an adequate amount of effort in the quality assurance of the product, with the knowledge that this effort will be

amortized through the multiple uses of the product. • Shorter time to market, which can be achieved by saving, not only the develop- ment effort but also the development schedule required for a custom product development.

Software Testing: Concepts and Operations, First Edition. Ali Mili and Fairouz Tchier. © 2015 John Wiley & Sons, Inc. Published 2015 by John Wiley & Sons, Inc.

348 TESTING PRODUCT LINES

• Reduced risk, which stems from trading the risk inherent in any software project development for the safety and predictability of using an existing component that has survived extensive field testing and field usage.

Despite all these advantages, software reuse has not caught on as a general routine practice in software engineering, for a number of reasons, chief among them is the absence of a reference architecture in software products. Indeed, in order for reuse to happen, the party that produces reusable assets and the party that consumes them need to have a shared product architecture in mind. In the automobile industry, for example, component reuse has been a routine practice for over a century because the basic architecture of automobiles has not changed since the late nineteenth cen- tury: All cars are made up of a chassis, four wheels, a cab, an engine, a transmission,

a steering mechanism, a braking mechanism, a battery, an electric circuitry, a fuel tank, an exhaust pipe, an air-conditioning system, and so on. As a result of this stand- ard architecture, many industries emerge around the production of specific parts of this architecture, such as tire manufacturers, battery manufacturers, transmission man- ufacturers, exhaust manufacturers, and air-conditioning manufacturers, as well as other more specialized (and less visible to the average user) auto parts manufacturers. This standard architecture supports reuse on a large scale: when they design a new automobile, car manufacturers do not reinvent what is a car every time; rather, they may make some design decision pertaining to look, styling, engine performance char- acteristics, standard features, and optional features, then pick up their phone and order all the auto parts that they envision for their new car. Unfortunately, such an efficient/ flexible process is not possible for software products, for lack of a standard architec- ture for such products.

But while software products have no common architecture across the broad range of applications where software is prevalent, they may have a common architecture within specific application domains—whence PLE. PLE is a software development and evolution process that represents a streamlined form of software reuse. It is geared toward the production of a family of related software products within a particular application domain and includes two major phases, which are as follows:

• Domain Engineering, which consists in developing the necessary infrastructure to build and evolve applications within the selected application domain. This

phase includes the following steps/activities: ○ Domain Analysis, which is the PLE equivalent of the requirements engineering

phase in traditional waterfall lifecycles and consists of analyzing the applica- tion domain to understand its domain-specific knowledge (abstractions, assumptions, axioms, rules, etc.).

○ Domain Scoping, which consists of determining the boundaries of the domain by specifying which applications fall within and which fall outside the selected

domain. ○ Economic Rationale, which consists of making a case for the product line

based on an estimation of the return on investment achieved by this product

16.1 PLE: A STREAMLINED REUSE MODEL 349

line; the calculation of the return on investment depends on the domain engi- neering costs, the application engineering costs, the number of applications we envision to sell every year, and the number of years we envision the product line to be active.

○ Variability/Commonality Analysis, which consists of deciding what features domain applications have in common (to maximize reuse potential) and how they

differ from each other (to broaden the market that can be served by the domain). Variabilities are defined by specifying what features vary from one application to another and what values each feature may take. For example, if we are talking about database applications, then one variability could be the back-end database, and the values on offer could include Oracle, SQL, and Access.

○ Reference Architecture, which consists in deriving a common architecture for all the applications in the domain. ○ Asset Development, which consists in developing adaptable components that fit in the proposed architecture and support the variabilities that have been

selected in the aforementioned analysis. ○ Application Modeling Language (AML): For well-designed, well-modeled product lines, it is possible to define a language in which one can specify or uniquely characterize individual products within the application domain. In some simple cases, it is possible to design translators that map a specifica- tion written in this AML onto a finished application.

○ Application Engineering Process: In addition to producing the necessary assets that the application engineer needs to compose an application, the

domain engineering team must deliver a systematic application engineering process that explains how applications are produced from domain engineering assets according to application requirements.

• Application Engineering, which consists in using the assets produced in the domain engineering phase to build an application according to the steps detailed in the application engineering process.

As a simple illustration, consider a product line developed to cater to the IT needs of banks in some jurisdiction (e.g., the state of New Jersey in the United States).

• Domain analysis consists of getting acquainted with the banking domain and with the relevant requirements of an IT application in the selected jurisdiction. This may require that we read relevant documentation and legislation in the jurisdiction of the bank and that we talk to bank managers, bank employees, bank tellers, bank customers, fiscal authorities, state and federal regulators of the banking sector, and so on. At the end of this phase, we ought to become fluent in the banking domain; we also need to record our expertise and domain knowledge in the form of domain models, including relevant abstractions, rules, terminology, and so on.

• Domain scoping consists of deciding what applications are or are not part of our domain. For example, we consider all the types of banks, such as retail banks,

350 TESTING PRODUCT LINES

investment banks, credit unions, online banks, savings and loans banks, local banks, statewide banks, nationwide banks, offshore banks, and international banks.

• To build an economic rationale for our product line, we must consider the scope that we have defined earlier and evaluate the cost of developing a product line to cater for banks within our scope, then balance this cost against the benefits reaped from selling applications to banks; this, in turn, requires that we estimate the length of our investment cycle, the discount rate that we want to apply from one year to the next, the number of applications that we envision to sell to banks, the price at which we envision to sell the applications, and so on.

• Variability/Commonality Analysis: Once we have defined the scope of our domain, we can analyze the common attributes that the applications of our domain have: for example, if we decide to cater to nationwide retail banks, commonalities include that they are all subject to federal banking laws, federal tax laws, and federal employment laws; other commonalities include that they all maintain bank accounts, customer databases, loan departments, and so on. As for variabilities,

Domain engineering

Domain architecture

Domain models Reusable assets

Domain

Asset analysis

Application A Application B

Application C Application requirements

Requirements specs

Application C

Application design

Final application

Requirements

Product analysis

Figure 16.1 Domain engineering and application engineering lifecycles.

16.2 TESTING ISSUES 351

banks may be subject to different state laws depending on where they are headquartered, they may have significantly distinct banking policies, they may differ by the range of services that they offer their clients, and so on.

• Reference Architecture: Once we know what kinds of banks we are catering to and what kinds of commonalities and variabilities exist among the needs of these banks, we can draw an architecture that may be shared by all applications of the domain. Such an architecture may include a database of accounts, a database of customers, and a database of loans, along with a customer interface (for online customer transactions), a teller interface (for teller in-branch operations), an automatic teller interface (for ATMs), and so on.

• Once the common architecture is drawn, we can proceed with developing adaptable software components, which can be adjusted to fulfill specific customer

needs within the scope of the product line and integrated into the architectural framework to produce a complete application.

Figure 16.1 illustrates the lifecycles of domain engineering and application engineering and how they relate to each other.