This chapter is from the book
This chapter is from the book
This chapter is from the book
Architecture-Centric
In the context of software, the term architecture has different meanings depending on whom you ask. The definition in UML Explained is as follows:
Several books offer other useful definitions; see, for example, Software Architecture in Practice (Len Bass, Paul Clements, and Rick Kazman; Addison- Wesley, 1998).
The Unified Process specifies that the architecture of the system being built, as the fundamental foundation on which that system will rest, must sit at the heart of the project team's efforts to shape the system, and also that architecture, in conjunction with the use cases, must drive the exploration of all aspects of the system. You might think of the architecture as expressing the common vision that all members of the team must share in order for the resulting system to be suitably robust, flexible, expandable, and cost-effective.
In the context of the process, architecture is primarily specified in terms of views of six models. (See "The Five Workflows" later in this chapter for brief descriptions of these models.) These views reflect the "architecturally significant" elements of those models; taken together, the views form the architecture description. The project team initializes the architecture description early, then expands and refines it during virtually all the activities of the project.
The following subsections discuss the key reasons why architecture is so important to the Unified Process.
Understanding the Big Picture
The tools and techniques available to developers for building software are growing increasingly powerful. For better or worse, though, software itself, especially with its new focus on distributed computing, is getting considerably more complex as well, and there aren't any indications that the tools and techniques will "catch up" any time soon. Also, customers' attention spans are becoming shorter and shorter as their demands on development teams grow more sophisticated. The result is that it's very difficult for all but a few especially gifted people to understand—really understand—most software systems to any meaningful extent. The architecture description is meant, first and foremost, to facilitate an understanding of the architecture of the system being built. Rigorous modeling, and careful attention to the readability of the associated UML diagrams and supporting text, will go a long way toward turning the architecture description into the fulcrum for increased understanding of the "big picture" of the new system.
Organizing the Development Effort
A sound architecture explicitly defines discrete chunks of the system, as well as the interfaces among the various parts of the system. It also makes effective use of one or more architectural patterns, which help shape the development effort on various levels. (Client/server, three-tier, and N-tier are all examples of well-known architectural patterns. Other patterns focus on things like object request brokers [ORBs], which sit at the center of systems that use distributed components, and virtual machines, such as the one on top of which Java runs.) By using this aspect of architecture effectively, the project team can increase the chances that communication across subteams will add value to the effort.
Facilitating the Possibilities for Reuse
One of the key tenets of component-based development (CBD) is the idea that components should be usable, with a relative minimum of customization, in a variety of contexts. A well-constructed software architecture offers solid "scaffolding" on which components can reside and work gracefully with each other, while making it easy for teams building other systems to identify opportunities for possible reuse of any or all of those components. The bottom line is that the less time a team has to spend focusing on building new components, the more time it can spend on understanding the customers' problems and modeling the solutions.
Evolving the System
Maintaining and enhancing a system tends to occupy more time over the life of that system than it took to build it in the first place. When development projects find themselves operating in mythical "Internet time," with technologies evolving faster and business models changing more frequently than ever before, there's no question that a system of any size and complexity will be subject to evolutionary changes of a healthy magnitude. Having a solid architecture in place offers a set of essential reference points on which future development work can rely. An architecture that's been built such that changes in one part of the system almost never have adverse effects on other parts of the system also greatly enhances team members' ability to evolve the system effectively and efficiently.
Guiding the Use Cases
In one sense, use cases drive the architecture of a software system, since the use cases do drive all of the development effort. In another sense, however, the architecture guides the selection and exploration of use cases. Decisions that architects must make about things like middleware, system software, legacy systems, and so forth, have a strong influence on the choice of which use cases the team focuses on at what point in the project. The basic idea, then, is to focus on those use cases that will add value to the architecture, which in turn helps shape the content of those use cases and the nature of the work involved in developing the system from them.