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: May 1, 2007
Version 5.0 of the SEI’s Framework for Software Product Line Practice, a conceptual framework that describes the essential activities and 29 practice areas necessary for successful software product lines, was released this summer. In the five years since the release of the previous version, the community using the Framework has grown, and the number of organizations achieving business benefits from a product line approach has grown. At the same time, a number of other emerging technologies have influenced approaches to software product lines. This gave us the opportunity to answer more questions about software product lines and expand this component of the Framework. Following are some of the common questions from Version 5.0.
"Can I use open source software packages in my product line?"
You can if all of the following conditions exist:
Also be aware that some open source licenses are crafted in such a way that would require you to make your products, when based on open source packages, also open source. Read the license agreements very carefully.
"Does the software product line approach work in a globalization environment?"
Globalization has two meanings. The first, also called internationalization or localization, refers to making a software product or software-intensive system work correctly around the world. You can easily see that the software product line approach applies straightforwardly in this case. Different locale requirements correspond directly to product line variation points, and, in fact, a scoping exercise and a product line perspective on requirements can greatly help in identifying those variations. Identifying variations can result in each member of the family being as lean as possible and perhaps letting developers concentrate more on global features as well as locale-specific features.
The second meaning of globalization involves separate development groups located around the world cooperating productively and correctly to build software. In this context, the question is whether product lines can be developed globally. They can. It is necessary to lay some groundwork before effective distributed development can occur, and product lines are not immune from this need. For example, it is very useful to first establish such things as a common development environment, a common configuration management system, and a minimum set of common processes (or at least crisp process interface points), so the exchange of information and artifacts can flow smoothly across site boundaries. Just as in global development for single systems, architecture plays a central role. It crisply defines the work assignments and responsibility boundaries in the system but also among the development parties. In a product line situation, the responsibilities will include the design and development of variation mechanisms for core assets.
"Can a product line approach be compatible with agile development methods?"
The short answer is yes, as demonstrated by the successful use of eXtreme Programming (XP) in Salion’s product line effort [Clements 02]. However, the larger point is that the applicability of agile methods is more strongly determined by whether a project’s characteristics align with a method’s home ground.
Boehm and Turner advocate a pragmatic, risk-driven approach to choosing appropriate aspects from both plan-driven and agile methods [Boehm 04]. For projects whose characteristics stray from agility’s home ground, it may still be possible to partition off portions where agile methods can flourish.
One challenge to agile methods’ applicability is the principle of simple design, de-emphasizing the importance of software architecture. Within XP, this concept is known as “You Aren’t Going to Need It” (YAGNI). As Boehm says, YAGNI works fine when future requirements are largely unpredictable but can be highly inefficient where there is a reasonable understanding of future needs. Because a product line approach inherently means you set out to understand future needs, and indeed base your business strategy on that understanding, you are going to need a sufficiently defined product line architecture. However, once it’s developed, the software architecture contributes very well to a team’s tacit knowledge and can serve as a basis for other agile practices (e.g., for development activities within a partitioned area of the architecture).
"Is a model-driven development (MDD) approach compatible with the software product line strategy?"
Yes. The software product line strategy is compatible with a variety of technical approaches loosely grouped under the model-driven category including MDD, model-driven architecture, and model-driven engineering. The software engineering practice areas in the framework include the activities of a traditional development process but do not constrain how those activities are implemented. The model-driven techniques emphasize the disciplined use of a variety of models, whose currency is maintained throughout the product life cycle. A model-driven approach to software products lines would emphasize automatic product derivation [McGregor 05]. Models would be constructed that are capable of expressing the commonality and variations inherent in the product line's scope. A new product's requirements would be translated into product-specific configurations of the product independent models that are maintained as core assets. Tool-supported translation, laid out in a production plan, would be used to derive products. In fact, model-driven development could be thought of as a production strategy, as described in Section 2.1 of the framework.
"Does a system-of-systems (SoS) context rule out the use of software product lines?"
No. On the contrary, software product lines can help reduce the complexity of an SoS context. An SoS comprises independent, self-contained systems that, when taken as a whole, satisfy a specified need. Many software-intensive contexts today are systems of systems. The complexity involved can be daunting. However, in many cases, there is considerable commonality among some of the self-contained systems. Suppose, for example, that the SoS involves 200 separate systems that all must interoperate. But suppose further (as is often the case) that there are some clusters within those 200 that have considerable commonality and whose variations could be handled economically. By making those clusters into software product lines, you can tame the interoperability issue into a smaller, more manageable set of interfaces and thereby reduce the complexity of the SoS. Moreover, the economic advantages and predictability associated with software product lines will be highly beneficial to the SoS in question.
"Is there any connection between service-oriented architectures (SOAs) and software product lines?"
SOAs and software product line approaches to software development share a common goal. They both encourage an organization to reuse existing assets and capabilities rather than repeatedly redeveloping them for new systems to achieve desired benefits such as productivity gains, decreased development costs, improved time to market, higher reliability, and competitive advantage.
"How are SOA and software product line approaches alike?"
Both approaches promote reuse by developing applications or products based on a set of reusable components. Those components are developed with well-defined interfaces and processes that specify how the components are to be used, which enables applications or products to be produced in less time.
Adopting either approach requires implementing similar organizational policies and practices necessary to adopt a new technology or a new way of doing business. SOA and software product lines share many of the same organizational issues, such as planning, funding, tool support, training, and the need to change the organizational mindset toward reuse. When starting to use either approach, it is imperative for both SOA and software product line efforts to have organizational commitment and a champion.
Both approaches focus on identifying the application building blocks or reusable components associated with the application(s). In SOA, services represent the reusable building blocks. Core assets are the basis for production of products in a software product line. Separate teams may be employed to develop the reusable components and the applications. Small or pilot studies help develop skills to evolve the organization toward an SOA or software product line capability.
In both cases, the initial building blocks may come from legacy systems. Identifying and retrieving product line assets or services from existing systems in order to obtain the benefits of reuse are equally difficult. Documentation and tool support aid this effort.
Application or product development for both approaches is orchestrated in a similar manner. Inputs include the requirements for a particular application or product, reusable components, and the details of how these components are to be used to build the application or product.
"How are SOA and software product line approaches different?"
While the goals and the use of reusable components in the SOA and software product line approaches are similar, the processes by which the two compose systems are very different.
A software product line is, fundamentally, a set of related products. Each product is formed by taking applicable components from the base of common assets, tailoring them as necessary through preplanned variation mechanisms such as parameterization or inheritance, adding any new components that may be necessary, and assembling the collection according to the rules of a common, product-line-wide architecture under the auspices of a production plan. New or updated core assets are rolled back into the core asset base for future systems.
In SOA, it is not necessary for the reusable component(s) to come from a centralized, organization-controlled service base. Multiple organizations may provide the services leading to the possibility that services may change or disappear without notification. While multiple organizations can have responsibility for the core asset base in the software product line paradigm, that is not the usual case.
SOA addresses the issue of variation through orchestration (coordinating the participating services), service versioning, or extensible XML data types (a process of evolving from one format to another without requiring central control of the format).
The product line architecture is a software architecture that satisfies the needs of the products within the product line’s scope. It is a key core asset. SOA is not the software architecture of the system; it is a design philosophy and an approach to software development where
The product line architecture establishes the quality goals for a system—its performance, reliability, modifiability, and so forth. Since SOA implementations may span enterprise boundaries, the quality attributes are dependent on the Quality of Service (QoS) of each of the included services. Desired end-to-end qualities may be achieved in specifically engineered applications. However, if the services are used in a different context, they may not meet the expected QoS. Service developers need to understand the functional and QoS requirements of potential service users.
In a software product line, an established process for updates to the core asset base is followed as the product line evolves, as more resources become available, as fielded products are maintained, and as technological changes or market shifts affect the product line’s scope. Unlike SOA, the core assets in a software product line approach include non-software assets as well as software components. Product line requirements, domain models, test cases, and other assets provide significant strategic advantage. Also included in the core asset base is a production plan prescribing how the products are produced from the core assets. SOA employs an SOA governance to facilitate planned reuse of services. SOA governance means the creation, deployment, enforcement, and verification of policies throughout the entire life cycle of SOA artifacts. SOA governance platforms may provide easy service discovery through a centralized service registry and management tools for planned reuse (on the service level), such as tracking subscribers to services, negotiating service level agreements (SLAs), communicating change requests and actual changes in service interfaces and data types.
"Can SOA and software product lines be used together?"
It is possible to build a stand-alone (i.e., non-product-line) application using SOA and to build a software product line without using SOA. In that sense, the two approaches are independent. However, it is also possible to combine the two approaches. In particular, it is possible and feasible for an organization to use services as reusable core assets with which to build products in a software product line. That is a focus of the Using Externally Available Software practice area. Also, service providers and SOA application developers could take a product line approach to the development of services."
Can the framework provide guidance for a move to SOA"
Organizations moving to an SOA approach can benefit from software product line information captured in other practice areas as well. The practice areas related to organizational management could help organizations understand important issues in adopting a new reuse-based technology. And those related to technical management and software engineering could help organizations analyze legacy systems, determine make/buy/mine/commission decisions, use existing available software, and understand risk. Documents similar to the product line adoption plan (describing the desired state of the organization and a strategy for achieving that state) and the product line production plan (which prescribes how the products are produced from the reusable components) provide excellent templates for organizations moving to planned, reuse-oriented environments.
Planned and systematic reuse, exploiting economies of scope, and other important software product line issues could feed into the SOA design philosophy to help manage the growth of services and application developments, understand the dependencies between services, and determine the impact of service changes to the applications. The software product line approach would help control complexities created by the combinatorics of services and applications that occur over the entire life cycle of a system.
Boehm, B. & Turner, R. Balancing Agility and Discipline: A Guide for the Perplexed. Reading, MA: Addison-Wesley, 2004.
Clements, P. & Northrop, L. Salion, Inc: A Software Product Line Case Study (CMU/SEI-2002-TR-038, ADA412311). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2002.
McGregor, J. Preparing for Automated Derivation of Products in a Software Product Line (CMU/SEI-2005-TR-017, ADA448223). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2005.
Paul Clements is a senior member of the technical staff at the SEI, where he has worked for 10 years leading or co-leading projects in software product line engineering and software architecture design, documentation, and analysis. Clements is the co-author of three practitioner-oriented books about software architecture: Software Architecture in Practice (1998; second edition, 2003), 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 written dozens of papers in software engineering reflecting his long-standing interest in the design and specification of challenging software systems. He received a BS in mathematical sciences in 1977 and an MS in computer science in 1980, both from the University of North Carolina at Chapel Hill. He received a PhD 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.