Components As Products

NEWS AT SEI

Authors

John McGregor

Linda M. Northrop

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: March 1, 2003

Products in a software product line are software for sale. Common components for the software product line are part of the core asset base. But what if you are in the software component business? Then each product you build is a software component. If you have a family of components with many common features but that vary in some distinct and predictable ways, could you have a product line of components? And is this a silly idea? Not at all silly, just confusing. In fact, today a product line of components makes a lot of sense (and for many, a lot of money).

But before we explain, let’s first define what we mean by component. Szyperski gives this definition [Szyperski 98]:

A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties.

A component is therefore opaque, and it is this opaqueness that allows one company to use proprietary information and algorithms from another company without detailed access that would compromise the intellectual property rights of the providing company. The using company must be able to easily compose the component with other components without special environments or tools. Standards for specific purposes, such as the Enterprise Java Beans and CORBA models, provide market strata and architectural constraints that guide and facilitate the component selection process.

Providing individual software components as products is a rapidly growing business, but not a new business. Software libraries for domains such as numerical analysis or graphics have been available for over thirty years. But a number of changes have occurred in the last few years that have reshaped the component marketplace.

An increased focus on defining interfaces and component models that are defined via interfaces has made it simpler to identify candidates for a particular use. These candidate components “almost” fit and the amount of rework required to use them has dramatically decreased. When you couple this opportunity to eliminate some of the in-house development work with the ever-growing demand for software—more complex and more challenging software—using some prefabricated components makes sense. And many have reached that conclusion; the market demand for components is strong. Moreover, the granularity of commercial components has grown from small, low-payoff components such as stacks and queues to components that provide more comprehensive functionality, such as a complete voice recognition engine. These new larger, more sophisticated components command a healthy price that results in an attractive return on development investment—an incentive for the component developer. In response, electronic marketplaces such as flashline.com have made it possible to offer small individual components for sale at affordable but profitable prices.

Consider a hypothetical (but close to real) example from the domain of telecommunication protocols. Our hypothetical company, Protocols-R-Us, is a company founded by a small group of managers and developers who all worked for the same multinational telecommunications corporation. The company has begun production of “protocol stack” software components, which are used to parse signals coming into a communications device, to do error detection and retry, and to deliver the signal to the platform software.

As a small company, Protocols-R-Us moved carefully to define their market. Their original business plan was narrowly scoped to address only their first product. The company began by supplying an implementation of a communications protocol to both their former employer and one other company. As the first product was nearing release, the managers began to consider other products. Given the depth of technical knowledge of the company founders, they explored products that could be leveraged from the work done so far. The team determined that their market consisted of companies that are developing the broad array of communication devices and add-ons that are being introduced into the consumer market. Each of these devices is capable of receiving a variety of signals, including voice conversations and data transmissions. Each device would actually need to “understand” numerous protocols. Which protocols are useful is information that is changing rapidly, as is the specification of many of the newer protocols.

The company team saw the rapid increase in the creation and release of new protocol standards as a business opportunity. They could capitalize on this business opportunity only if they could design and produce implementations of several protocols that could coexist in a single device and could do so in a way that kept pace with the release of standards updates as protocols were revised and expanded. The company would also have to be able to keep costs low because the “shelf life” of a given implementation is extremely short. Client companies would want each new version of their device to have the latest implementation in order to provide the widest array of services to their clients. Protocols-R-Us set a goal to meet the protocol processing needs of customers by providing high-quality implementations of telecommunications protocols and to do so as quickly and efficiently as possible.

The company’s small staff would need to be enlarged, but given current job market conditions, the new hires would not have a depth of experience in either software development or telecommunications. There would have to be a significant increase in productivity among the experienced personnel or the company would miss most of the benefits of the current telecommunications explosion.

How could they succeed? They could take a software product line approach. And their products would be? A product line of components.

As the team began planning for the product line, they had to identify the products that would constitute the product line (the product line scope). The initial product was an implementation of the HyperText Transfer Protocol (HTTP) and a HyperText Markup Language (HTML) translator. If they were to build on their existing client base, it made sense to include protocols that are related either to the Transfer Control Protocol/Internet Protocol (TCP/IP) or HTTP. However, these are well-known protocols for which many implementations exist. A new, but somewhat related, area was the Wireless Application Protocol (WAP) used to provide Internet access from a mobile phone. This is an emerging area in which it should be possible to establish a presence. As an initial scope the team identified the following pieces that would be needed for a complete protocol stack from signal reception to screen presentation:

  • Wireless Application Environment (WAE)
  • Wireless Session Layer (WSP)
  • Wireless Transaction Protocol (WTP)
  • Wireless Transport Layer Security (WTLS)
  • Wireless Datagram Protocol (WDP)

To offer a “complete solution” the company would also have to provide an implementation of the Wireless Markup Language (WML). The protocol stack accompanied by the language would provide support for accessing HTML-based content on the mobile phone.

The team recognized that their most important asset would be the basic architecture from which all of the products are derived. Since the products will be components, they actually had to consider two architectures: the architecture of the systems into which the components are intended to fit, and the architecture for the protocol components—their product line architecture. They knew that the product line architecture for the components must provide a link between the standard organization for communication protocols and the individual components to permit clients, who are familiar with the network model, to easily understand how the Protocols-R-Us components will fit into their architecture.

The architecture would have to be updated to anticipate the evolution of those components with which it must interoperate. The company formed strategic alliances with a number of companies that produced related products. Through these partnerships, Protocols-R-Us hopes to keep up with the latest design changes and receive advance releases. It will test its products with these new releases to identify any unintended interactions. The architecture must also be maintained to remain current with the latest versions of the applicable standards.

And how will the final products be packaged? Each component will be packaged with a test component that contains the test cases used to test the protocol component. The component will also contain technical documentation that includes specification of both the provides and requires interfaces for the component. Finally, the shrink-wrapped package will also contain sample designs for integrating sets of the components into different configurations that provide support for different types of products.

Protocols-R-Us shows that the basic principles of product line development apply regardless of the nature of the products—even if the products are components. In the case of our component product line, the main changes in practices are the result of the size of the products and the need to manage the requirements with limited effort. The major impact on the architecture development is the need to pay more attention to the architecture of the environment into which the components will be integrated. There is always some integration between an application and its operating environment; however, the interface between an individual component and an application architecture is not as standardized as the OS interface. On the positive side, the interfaces implemented by a single component are smaller and can be more completely specified than the interface of an entire application.

And so you can have a software product line where the components are products. In fact, a product line approach is a promising development paradigm for the component industry for the same reasons it made sense for Protocols-R-Us.

References

[Szyperski 98]
Szyperski, C. Component Software: Beyond Object-Oriented Programming. Harlow, England; Reading, MA: Addison-Wesley, 1998.

About the Authors

Linda Northrop has over 30 years of experience in the software development field as practitioner, manager, consultant, and educator. She is currently director of the Product Line Systems Program at the Software Engineering Institute (SEI). Her current publications are in the areas of software product lines, software architecture, and object technology. She is co-author of the book, Software Product Lines: Practices and Patterns.

Northrop chaired the first Software Product Line Conference in 2000 and SPLC2 in 2002. Linda is the OOPSLA Steering Committee Chair and was the OOPSLA 2001 Conference Chair. She is also on the Executive Committee of ACM SIGPLAN, and is a member of ACM, the IEEE Computer Society, the Computer Sciences Accreditation Commission, and the ACM/IEEE Joint Committee on Software Engineering.

Dr. John D. McGregor is an associate professor of computer science at Clemson University, a Visiting Scientist in the Product Line Systems program at the SEI, and a partner in Luminary Software, a software development consulting firm. Dr. McGregor has conducted research for organizations such as the National Science Foundation, DARPA, IBM and AT&T. Dr. McGregor is co-author of Object-oriented Software Development: Engineering Software for Reus,  published by Van Nostrand Reinhold. Dr. McGregor is also co-author of A Practical Guide to Testing Object-Oriented Software, published by Addison-Wesley. He has published numerous articles on software development focusing on design and quality issues. Dr. McGregor's research interests include software engineering, specifically in the areas of product development, design quality, testing and measurement.

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.

Find Us Here

Find us on Youtube  Find us on LinkedIn  Find us on twitter  Find us on Facebook

Share This Page

Share on Facebook  Send to your Twitter page  Save to del.ico.us  Save to LinkedIn  Digg this  Stumble this page.  Add to Technorati favorites  Save this page on your Google Home Page 

For more information

Contact Us

info@sei.cmu.edu

412-268-5800

Help us improve

Visitor feedback helps us continually improve our site.

Please tell us what you
think with this short
(< 5 minute) survey.