About architecture centric resuse and product line tactics
Answers
Answered by
2
In the context of software, the term architecture has different meanings depending on whom you ask. The definition in UML Explained is as follows:
The fundamental organization of the system as a whole. Aspects of an architecture include static elements, dynamic elements, how those elements work together, and the overall architectural style that guides the organization of the system. Architecture also addresses issues such as performance, scalability, reuse, and economic and technological constraints.
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 buil
The fundamental organization of the system as a whole. Aspects of an architecture include static elements, dynamic elements, how those elements work together, and the overall architectural style that guides the organization of the system. Architecture also addresses issues such as performance, scalability, reuse, and economic and technological constraints.
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 buil
Similar questions