Software Architecture Perspectives on an Emerging Discipline

【实例简介】
Mary Shaw和David Garlan老师的软件体系结构作品
CONTENTS 4.3.3R tory, 85 4.3. 4 Hierarchical layers, 86 4.3.5 Evolution of Shared Information Systems in Software Development Environments, 88 4.4 Integration in the Design of Buildings 4.4.I Repository, 82 4.4.2 Intelligent Control, 90 4.4.3 Evolution of Shared Information Systems in Building Design, 9i Architectural Structures for Shared Information Systems 93 4.5.1 Variants on Dataflow Systems, 93 4.5.2 Variants on Repositories, 94 46 Some conclusions 95 CHAPTER 5 Architectural Design Guidance 5.1 Guidance for Liser-Interface Architectures 97 by Thomas G. lane 5.1.1 Design Spaces and Rules, 97 5.1.2 A Design Space for User-Interface Architectures, 100 5.1.3 Design Rules for User-Interface Architecture, 110 5.1. 4 Applying the Design Space: An Example,111 5.1.5 A Validation Experiment, 113 5.1.6 How the Design Space Was Prepared, 1 14 5.1.7 Summary, 115 5.2 The Quantified Design Space 116 by Toru Asada, Roy F. Swonger, Nadine Bounds, and Paul Duerig 5.21 Overview,116 5.2.2 Background, 116 5.2.3 Quantified Design Space, 1 20 5.2.4 Conclusion, 127 CHAPTER 6 Formal Models and specifications 129 6.1 The Value of Architectural Formalism 129 6.2 Formalizing the Architecture of a Specific System 130 6.3 Furinalizing an Arcinitecturai Style 13 63.1 Filters. 1 34 6.3.2 Pipes, 135 6.3.3 Pipe-and-Filter System, 136 6. 4 Formalizing an Architectural Design Space 139 6.5 Toward a Theory of Software Architecture 142 6.6 What next? 42 6.7 Z Notation Used in This Chapter 143 CONTENTS CHAPTER 7 Linguistic Issues 147 7. 1 Requirements for Architecture-Dcscription Languages 147 7.1.1 The Linguistic Character of Architectural Description, 148 7.1.2 Desiderata for Architecture-Description Languages, 15 7. 1. 3 Problems with Existing Languages, 155 72 First-Class Connectors 160 7.2.lC t Practice. l 6i 7.2.2 Problems with Current Practice, 161 7.2.3 A Fresh View of Software System Composition, 16 7.2.4 An Architectural Language with First-Class Connectors, 166 7.2.5 The Promise of Explicit Architectural Notations, 171 7.3 Adding Implicit Invocation to Traditional Programming Languages 7.31 Inti ction,、172 7.3.2 Adding Implicit Invocation to Ada, 174 7.33 Evaluation, 181 CHAPTER 8 Tools for Architectural design 33 8. 1 UniCon: A Universal Connector Language 183 8. 1. 1 Components and Connectors, 185 8.1.2 Abstraction and Encapsulation, 186 8.1.3 Types and Type Checking, 187 8. 1.4 Accommodating Analysis Tools, 188 8.2 Exploiting Style in Architectural Design Environments I 8.2.1 What Is Architectural Style?, 190 8.2.2 Automated Support for Architectural Design, 192 8.2.3 Observations about Environments for Architectural Design, 202 8.3 Beyond Definition/Use: Architectural Interconnection 204 8.3.1 Implementation versus Interaction, 205 8.3.2 Example, 206 8.3.3 The WRIGHT Model of Architectural Description, 208 8.3.4 Reasoning about Architectural Descriptions, 210 8.3.5 A Brief Explanation of Our Use of CSP, 211 ChAPTER 9 Education of Software Architects 213 9.1 Philosophy and Course Overview 9.1.1 Objectives, 213 9.1,2A approach, 214 9.2 Course Description 215 9.3 Assignments 218 9.3.1Pu 9.3.2 Readings, 219 9.3.3 Architectural Development Tasks, 220 9.3.4 Formal Modeling, 222 CONTeNTs ⅹX 9.3.5 Analysis and Interpretation of a System, 222 9.4 Evaluati 9.4.1 Lessons from the Initial Offering, 223 9.4.2 Conclusions About Teaching Software Architecture, 225 Bibliography 227 inde 39 c INTRODUCTION SoFTWARE ARCHITECTURE IS EMERGING as an important discipline for engineers of soft- ware. But it did not simply appear, well-formed and clearly articulated, as a new concern for software systems. Rather, it has emerged over time as a natural evolution of design abstractions, as engineers have searched for better ways to understand their software and new ways to build larger, more complex software systems In this chapter we trace this evolution. We begin by identifying the engineering issues of architectural design and how those issues relate to other software design levels Next we consider the nature of software engineering and its evolution over the past few decades. With this background we outline the current status of software architecture and its relationship to other aspects of software engineering. 1.1 WHAT IS SOFTWARE ARCHITECTURE? As the size and complexity of software systems increase, the design and specification of overall system structure become more significant issues than the choice of algorithms and data structures of computation. Structural issues include the organization of a system as a composition of components global control structures; the protocols for communication, synchronization, and data access; the assignment of functionality to design elements; the composition of design elements; physical distribution; scaling and performance: dimen sions of evolution, and selection among design alternatives. This is the software architecture level of design. Abstractly, software architecture involves the description of elements from which systems are built, interactions among those elements, patterns that guide their composi- ion, and constraints on these patterns. In general, a particular system is defined in terms of a collection of components and interactions among those components. Such a system may in turn be used as a(composite)element in a larger system design 设牙 INTRODUCTION CHAPTERI While it has long been recognized that finding an appropriate architectural design for a system is a' key element of its long-term success, current practice for describing archi- lectures is typically informal and idiosyncratic. Architectural structures are often described in terms of idiomatic patterns that have emerged informally over time. Usually, architec- tures are represented abstractly as box-and-line diagrams, together with accompanying prose that explains the meanings behind the symbols and provides some rationale for the specific choice of components and interactions. For example, typical descriptions of soft ware architectures include statements such as these(italics ours) Camelot is based on the client-server model and uses remote procedure calls both locally and remotely to provide communication among applications and servers S+87] Abstraction layering and system decomposition provide the appearance of system iformity to ciients, yet allow Helix to accommodate a diversity of autonomous devices. The architecture encourages a client-server model for the structuring of applications”(FO85] We have chosen a distributed, object-oriented approach to managing information [Iin87]. The easiest way to make the canonical sequential compiler into a concurrent com piler is to pipeline the execution of the compiler phases over a number of processors A more effective way lis to split the source code into many segments, which are oncurrently processed through the various phases of compilation [by multipie compiler processes] before a final, merging pass recombines the object code into a S】 agle program Such descriptions are common. It is striking that they communicate so effectively despite being almost completely informal. Labeling of individual components is idiosyncratic to he system being described, and even the generalizations such as architectural patterns are defined casually--and differently by different authors The relative informality and high level of abstraction of current practice in describ ing architectures might at first glance suggest that archiectural descriptions have little sub stantive value for software engineers. But there are two reasons why this is not the case. First, engineers have evolved over time a collection of idioms, patterns, and styles of soft ware system organization that serves as a shared, semantically rich vocabulary. For exam ple, by identifying a system as an instance uf a pipe-filter architectural style an engineer communicates the facts that the system is primarily involved in stream transformation that the functional behavior of the system can be derived compositionally from the behav- iors of the constituent filters, and that issues of systen latency and throughput can be addressed in relatively straightforward ways. Thus, although this shared vocabulary is largely informal, it conveys considerable semantic content among software engineers The second reason is that although architectural structures are abstract in relation to details of the actual computations of the elements, those structures provide a natural framework for understanding broader, system-level concerns, such as global rates of flow, patterns of communication, execution control structure, scalability, and intended paths of system evolution. Thus, architectural descriptions serve as a skeleton around which system SECTION 1.1 What Is SOFTWARE ARCHITECTURES properties can be fleshed out, and thereby serve a vital role in exposing the ability of a sys tem to meet its gross system requirements. This is, of course, not to say that more formal notations for architectural descrir tion and rigorous techniques of analysis are unnecessary. Indeed, much could be gained i the current practice of architectural design could be supported with better notations, thecries and analytical techniques. In later chapters we explore specification issues in software architecture, with particular attention to the way improvements in the formulation of architectural issues set the stage for better formalization. There is a considerable ( and growing) body of work on this topic, including module interconnection languages, templates and frameworks for systems that serve the needs of specific domains, and formal models of component integration mechanisms. However, there is not currently a consistent terminology with which to characterize the common ele- ments of these fields We are stil far from having a well-accepted taxonomy of such architectural pard digms, let alone a fully developed theory of software architecture. But we can now cl e arly identify a number of the basic ingredients of architectural description. Moreover, we can also identify a set of architectural patterns, or styles, that currently form the basic reper- toire of a software architect. (This basic repertoire is illustrated in the quotations above and is the subiect matter of Chapter 3. The architecture of a software system defines that system in terms of computational components and interactions among those components Components are such thing s as clients and servers, databases, filters, and layers in a hierarchical system. Interact: on mong component s at ign can be simple and familiar, proce(fure call and shared variable access but they can also be complex and semantically rich, such as client-server protocols, database-accessing protocols, asynchronous event multicast, and Piped streams. In addition to specifying the structure and topology of the system, the architec ure shows the correspondence between the system requirements and elements of the onl tructed system thereby providing some rationale for the design decisions. At the archite tural level,relevant system-lcvel issues typically include properties such as Capas: ity, through ut,consistency,and component compatibility More generally, architectural models clarify structural and semantic differences among components and interactions. These architectural models can often be composed to define larger systems. Ideally, individual elements of the architectural descriptions are defined independently, so that they can be reused in diferent contexts. The architecture establishes specifications for these individual elements, which may themselves be refined as architectural subsystems, or implemented in a conventional programming language The informal documentation of architectures currently produced by software designers suggests that their applied body of architectural knowledge is not well-servec b existing tools and notations. To establish the reasons for treating it explicitly, we riow examine the significance of design levels in computer systems. Following that, we will assess the development of an engineering discipline for software and the way improved architectural techniques will serve the maturation of software engineering INTRODUCTION CHAPTER 1 1.1.1 SOFTWARE DESIGN LEVELS System design takes place at many levels. It is useful to make precise distinctions among those levels, for each level appropriately deals with different design concerns. At each level we find components, both primitive and composite; rules of composition that allow the con struction of nonprimitive components, or systems; and rules of behavior that provide semantics for the system(BN71, New82, New90 ). Since these differ from one level to another, we also find different notations, design problems, and analysis techniques at each level. As a result, design at each level can proceed substantially autonomously. But levels are also related, in that elements at the base of each level correspond to-are implemented y-constructs ol f the level below The hierarchy of levels for computer hardware systems is familiar and appears in Fig ure 1.(BN71,P 3). Note first that each level deals with different content. Different kinds of structures guide design with different sets of components. Different notations, analysis techniques, and design issues accompany the differences of content matter. Note also that each level admits of substructure: abstraction and composition take place within each level, in terms of the components and structures of that level. In addition there is an estab lished transformation from the primitive components at the bottom of each level to(prob ably nonprimitive) components of the level below. are, too has its design levels we can identify at least three 1. Architecture, where the design issues involve overall association of system capability with components; components are modules, and interconnections among modules are handled in a variety of ways, operators guide the composition of systems from b 2, Code, where the design issues involve algorithms and data structures; the compo- nents are programming language primitives such as numbers, characters, painters, nd threads of control; primitive operators the arithmetic and d manipulation primitives of the language; composition mechanisms include records, arrays, and procedures 3. Executable, where the design issues involve memory maps, data layouts, call stacks and register allocations; the components are bit patterns supported by hardware, and the operations and compositions are described in machine code. These roughly track the higher levels of hardware design. From the 1960s through the 1980s software developers concentrated on the programming level. The executable and code levels for software are now well understood. However, the architecture level is cur- rentiy understood mostly at the level of intuition, anecdote and folklore. It is common for a description of a software system to include a few paragraphs of text and a box-and-line diagram but there are neither uniform svntax nor uniform semantics for interpreting the prose and the diagrams. Our concern here is to improve understanding and precision at the software architecture level. At this level the components are programs, modules, or sys tems; a rich collection of interchange representations and protocols connects the compo nents; and system patterns often guide the compositions. SECTION 12 AN ENGINEERING DISCIFLINE FOR SOFTWARE Structures: Network/ N, computer omponents: Processors/P, memories switches/S, controls K transducers. data operators/D links 2 Structures: Programs, subprograms s Components: State(memory cels 83 instructions, operatars, controls interpreter Circuits: Arithmetic unit 2 Components: Registers, transfers, controls, data operators(+,-, etc.) Circuits: Counters, controls, sequential M State 5冒 egister arrays level Components: Flip-Hiaps, reset-sey RS,K, delay/D, toggle T, latch delay. one shot Circuits En =s arays, data ops selectors, 套|君 distrbutors. erative newworks ∧ cmponent states, inputs 8 Components: AND, OR,NOT NAND,NOR cutputs Circuits: Amplifiers, delays, attenuators. o multivibrators, cocks, gates, differentiator I Active components: Relays, vacuum tubes transistor Passive components: Resistor/R, capacitor/C inductor, diode, delay lines FIGURE 1.1 Computer Hardware Design Levels (Reproduced with permission of the McGraw-Hill Companies from Computer Sr uctures by g. Bell and A Newell, McGraw-Hill 1971.) 1.2 AN ENGINEERING DISCIPLINE POR SOFTWARD Explicit recognition of the architectural issues in software design is part of the maturation of the field. It contributes to establishing an engineering basis for software. It will prowide useful context to examine the emergence of software engineering as an engineering discipline The phrase software engineering was coined in 1968 as a statement of aspiration--d sort of rallying cry. That year NATO convened a workshop by that name to assess the state 【实例截图】
【核心代码】