软件体系结构英文版aaaa文档格式.docx

1、?- City Gent #1 （Michael Palin）, The Architects Sketch 111As predicted by Perry and Wolf 105, software architecture has been a focal point for software engineering research in the 1990s. The complexity of modern software systems have necessitated a greater emphasis on componentized systems, where th

2、e implementation is partitioned into independent components that communicate to perform a desired task. Software architecture research investigates methods for determining how best to partition a system, how components identify and communicate with each other, how information is communicated, how el

3、ements of a system can evolve independently, and how all of the above can be described using formal and informal notations.A good architecture is not created in a vacuum. All design decisions at the architectural level should be made within the context of the functional, behavioral, and social requi

4、rements of the system being designed, which is a principle that applies equally to both software architecture and the traditional field of building architecture. The guideline that form follows function comes from hundreds of years of experience with failed building projects, but is often ignored by

5、 software practitioners. The funny bit within the Monty Python sketch, cited above, is the absurd notion that an architect, when faced with the goal of designing an urban block of flats （apartments）, would present a building design with all the components of a modern slaughterhouse. It might very we

6、ll be the best slaughterhouse design ever conceived, but that would be of little comfort to the prospective tenants as they are whisked along hallways containing rotating knives.The hyperbole of The Architects Sketch may seem ridiculous, but consider how often we see software projects begin with ado

7、ption of the latest fad in architectural design, and only later discover whether or not the system requirements call for such an architecture. Design-by-buzzword is a common occurrence. At least some of this behavior within the software industry is due to a lack of understanding of why a given set o

8、f architectural constraints is useful. In other words, the reasoning behind good software architectures is not apparent to designers when those architectures are selected for reuse.This dissertation explores a junction on the frontiers of two research disciplines in computer science: software and ne

9、tworking. Software research has long been concerned with the categorization of software designs and the development of design methodologies, but has rarely been able to objectively evaluate the impact of various design choices on system behavior. Networking research, in contrast, is focused on the d

10、etails of generic communication behavior between systems and improving the performance of particular communication techniques, often ignoring the fact that changing the interaction style of an application can have more impact on performance than the communication protocols used for that interaction.

11、 My work is motivated by the desire to understand and evaluate the architectural design of network-based application software through principled use of architectural constraints, thereby obtaining the functional, performance, and social properties desired of an architecture. When given a name, a coo

12、rdinated set of architectural constraints becomes an architectural style.The first three chapters of this dissertation define a framework for understanding software architecture via architectural styles, revealing how styles can be used to guide the architectural design of network-based application

13、software. Common architectural styles are surveyed and classified according to the architectural properties they induce when applied to an architecture for network-based hypermedia. This classification is used to identify a set of architectural constraints that could be used to improve the architect

14、ure of the early World Wide Web.Architecting the Web requires an understanding of its requirements, as we shall discuss in Chapter 4. The Web is intended to be an Internet-scale distributed hypermedia system, which means considerably more than just geographical dispersion. The Internet is about inte

15、rconnecting information networks across organizational boundaries. Suppliers of information services must be able to cope with the demands of anarchic scalability and the independent deployment of software components. Distributed hypermedia provides a uniform means of accessing services through the

16、embedding of action controls within the presentation of information retrieved from remote sites. An architecture for the Web must therefore be designed with the context of communicating large-grain data objects across high-latency networks and multiple trust boundaries.Chapter 5 introduces and elabo

17、rates the Representational State Transfer （REST） architectural style for distributed hypermedia systems. REST provides a set of architectural constraints that, when applied as a whole, emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, a

18、nd intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems. I describe the software engineering principles guiding REST and the interaction constraints chosen to retain those principles, contrasting them to the constraints of other architectural styles

19、.Over the past six years, the REST architectural style has been used to guide the design and development of the architecture for the modern Web, as presented in Chapter 6. This work was done in conjunction with my authoring of the Internet standards for the Hypertext Transfer Protocol （HTTP） and Uni

20、form Resource Identifiers （URI）, the two specifications that define the generic interface used by all component interactions on the Web.Like most real-world systems, not all components of the deployed Web architecture obey every constraint present in its architectural design. REST has been used both

21、 as a means to define architectural improvements and to identify architectural mismatches. Mismatches occur when, due to ignorance or oversight, a software implementation is deployed that violates the architectural constraints. While mismatches cannot be avoided in general, it is possible to identif

22、y them before they become standardized. Several mismatches within the modern Web architecture are summarized in Chapter 6, along with analyses of why they arose and how they deviate from REST.In summary, this dissertation makes the following contributions to software research within the field of Inf

23、ormation and Computer Science: a framework for understanding software architecture through architectural styles, including a consistent set of terminology for describing software architecture; a classification of architectural styles for network-based application software by the architectural proper

24、ties they would induce when applied to the architecture for a distributed hypermedia system; REST, a novel architectural style for distributed hypermedia systems; and, application and evaluation of the REST architectural style in the design and deployment of the architecture for the modern World Wid

25、e Web.CHAPTER 1Software ArchitectureIn spite of the interest in software architecture as a field of research, there is little agreement among researchers as to what exactly should be included in the definition of architecture. In many cases, this has led to important aspects of architectural design

26、being overlooked by past research. This chapter defines a self-consistent terminology for software architecture based on an examination of existing definitions within the literature and my own insight with respect to network-based application architectures. Each definition, highlighted within a box

27、for ease of reference, is followed by a discussion of how it is derived from, or compares to, related research.1.1 Run-time AbstractionAsoftware architectureis an abstraction of the run-time elements of a software system during some phase of its operation. A system may be composed of many levels of

28、abstraction and many phases of operation, each with its own software architecture.At the heart of software architecture is the principle of abstraction: hiding some of the details of a system through encapsulation in order to better identify and sustain its properties 117. A complex system will cont

29、ain many levels of abstraction, each with its own architecture. An architecture represents an abstraction of system behavior at that level, such that architectural elements are delineated by the abstract interfaces they provide to other elements at that level 9. Within each element may be found anot

30、her architecture, defining the system of sub-elements that implement the behavior represented by the parent elements abstract interface. This recursion of architectures continues down to the most basic system elements: those that cannot be decomposed into less abstract elements.In addition to levels

31、 of architecture, a software system will often have multiple operational phases, such as start-up, initialization, normal processing, re-initialization, and shutdown. Each operational phase has its own architecture. For example, a configuration file will be treated as a data element during the start

32、-up phase, but wont be considered an architectural element during normal processing, since at that point the information it contained will have already been distributed throughout the system. It may, in fact, have defined the normal processing architecture. An overall description of a system architecture must be capable of describing not only the operational behavior of the systems architecture during each phase, but also the architecture of transitions between phases.Perry and Wolf 105 define processing elements as transformers of data, while Shaw et al. 11