One of the most powerful applications of software architecture is its use as the foundation of a software product line. This chapter presents the basics of software product line production, highlighting architecture as the keystone for achieving large improvements in productivity, time-to-market, quality, and cost. The chapter explores in detail a few of the software engineering development and management activities that take on a special dimension in a product line context.
CelsiusTech is an organization that successfully implemented a product line based on an architecture. This chapter describes the architecture of the product line and shows why this architecture was crucial to CelsiusTech's success. Without this approach, it would not have been able to build these systems?it simply did not have adequate personnel. The product line approach brought consequent changes to the organizational structure and the manner in which it both solicits and contracts for business.
This chapter presents an overview of Sun Microsystems's Java 2 Enterprise Edition (J2EE) architecture specification, as well as an important portion of that specification, the Enterprise JavaBeans (EJBs) architecture specification. The J2EE specification provides a standard description of how distributed object-oriented programs written in Java should be designed and developed. The chapter examines the business drivers that led to the creation of such an industry standard architecture for building distributed systems, and shows how the J2EE/EJB architecture addresses such needs.
The Luther architecture was designed to provide a general framework to provide customized solutions in the domain of maintenance or operation of large vehicles or industrial infrastructure. It is based on J2EE, and so this chapter becomes an application of the general J2EE/EJB framework discussed in Chapter 16. This case deals with an environment where the end user is connected over a wireless network and has a device with limited input/output capabilities, limited computational capabilities, or both.
Systems are being constructed with more and more off-the-shelf components. The use of such components changes the design process because the components can constrain the architecture. Typically, components are chosen to achieve some set of functionality, but they also embody architectural (and hence quality) assumptions. This chapter describes a lightweight process to guide an architect in choosing components that will work well in concert. The chapter includes a demonstration of the process applied to a recently fielded system.
We look at the Architecture Business Cycle again and identify some of the yet to be solved problems associated with software architecture and discuss why more research is needed.