软件架构基础：David Garlan与Mary Shaw的见解

需积分: 3 20 浏览量更新于2024-08-02 收藏 149KB PDF 举报

"An Introduction to Software Architecture - David Garlan and Mary Shaw" 本文档是David Garlan和Mary Shaw在1994年撰写的一篇关于软件架构的重要文献，主要探讨了软件架构的基础概念和重要性。该文被收录于《软件工程与知识工程》第一卷，并作为CMU软件工程研究所的技术报告发布。研究得到了美国国防高级研究计划署、国家科学基金会以及西门子企业研究等多个机构的资助。软件架构是软件开发过程中的核心部分，它定义了系统的高级结构，包括组件、接口、交互模式和组织原则。在"An Introduction to Software Architecture"中，作者可能会详细解释以下几个关键知识点： 1. **架构定义**：软件架构是一系列重要的决策，这些决策定义了软件系统的组织结构和关键组件，以及它们之间的相互关系。它关注系统的主要功能、性能、可扩展性和可维护性等关键属性。 2. **组件与接口**：组件是软件架构的基本构建块，它们执行特定的功能。接口是组件间通信的桥梁，规定了它们如何协同工作。理解组件及其接口对于理解和设计复杂系统至关重要。 3. **架构模式与风格**：文档可能讨论了常见的架构模式和风格，如微服务架构、三层架构（表示层、业务逻辑层、数据访问层）或事件驱动架构。这些模式提供了设计和实现系统的通用框架。 4. **质量属性**：软件架构需要考虑多个非功能性需求，如性能、安全、可用性、可伸缩性和可测试性。作者可能会阐述如何通过架构设计来满足这些质量属性。 5. **决策与权衡**：设计软件架构涉及一系列决策，每个决策都可能带来不同的权衡。例如，提高性能可能牺牲可维护性，或者增加复杂性以提高安全性。作者可能详细介绍了如何评估和管理这些权衡。 6. **演化与适应性**：随着需求变化和技术发展，软件架构需要具有适应性和可演进性。作者可能会讨论如何设计可适应未来变化的架构，以及如何处理遗留系统的现代化问题。 7. **评估与验证**：文档可能会涵盖架构评估的方法，如架构评审、模拟和原型验证，以确保架构符合预期的需求和目标。 8. **案例研究**：为了更好地解释理论，作者可能会引用实际的软件项目作为案例，展示如何应用架构原则和模式来解决具体问题。 9. **最佳实践**：作者可能会分享一些在软件架构设计中广泛接受的最佳实践，以帮助读者在实际工作中应用这些理念。 "An Introduction to Software Architecture"提供了对软件设计基础的深入理解，是软件工程师、架构师和项目经理的重要参考资料。通过学习这篇论文，读者可以提升在构建大规模、高质量软件系统方面的知识和技能。

Garlan & Shaw: An Introduction to Software Architecture 5

One of these is based on the theory of abstract data types. But this is not the

only way to organize a software system.

Many other organizations have developed informally over time, and are

now part of the vocabulary of software system designers. For example, typical

descriptions of software architectures include synopses such as (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.”[8]

•“Abstraction layering and system decomposition provide the appearance

of system uniformity to clients, yet allow Helix to accommodate a

diversity of autonomous devices. The architecture encourages a client-

server model for the structuring of applications.”[9]

•“We have chosen a distributed, object-oriented approach to managing

information.” [10]

•“The easiest way to make the canonical sequential compiler into a

concurrent compiler is to pipeline the execution of the compiler phases

over a number of processors. . . . A more effective way [is to] split the

source code into many segments, which are concurrently processed

through the various phases of compilation [by multiple compiler

processes] before a final, merging pass recombines the object code into a

single program.”[11]

Other software architectures are carefully documented and often widely

disseminated. Examples include the International Standard Organization's

Open Systems Interconnection Reference Model (a layered network

architecture) [12], the NIST/ECMA Reference Model (a generic software

engineering environment architecture based on layered communication

substrates) [13, 14], and the X Window System (a distributed windowed user

interface architecture based on event triggering and callbacks) [15].

We are still far from having a well-accepted taxonomy of such architectural

paradigms, let alone a fully-developed theory of software architecture. But we

can now clearly identify a number of architectural patterns, or styles, that

currently form the basic repertoire of a software architect.

3. Common Architectural Styles

We now examine some of these representative, broadly-used architectural

styles. Our purpose is to illustrate the rich space of architectural choices, and

indicate what are some of the tradeoffs in choosing one style over another.

To make sense of the differences between styles, it helps to have a common

framework from which to view them. The framework we will adopt is to treat

an architecture of a specific system as a collection of computational

Garlan & Shaw: An Introduction to Software Architecture 6

components—or simply components-—together with a description of the

interactions between these components—the connectors. Graphically speaking,

this leads to a view of an abstract architectural description as a graph in which

the nodes represent the components and the arcs represent the connectors. As

we will see, connectors can represent interactions as varied as procedure call,

event broadcast, database queries, and pipes.

An architectural style, then, defines a family of such systems in terms of a

pattern of structural organization. More specifically, an architectural style

determines the vocabulary of components and connectors that can be used in

instances of that style, together with a set of constraints on how they can be

combined. These can include topological constraints on architectural

descriptions (e.g., no cycles). Other constraints—say, having to do with

execution semantics—might also be part of the style definition.

Given this framework, we can understand what a style is by answering the

following questions: What is the structural pattern—the components,

connectors, and constraints? What is the underlying computational model?

What are the essential invariants of the style? What are some common

examples of its use? What are the advantages and disadvantages of using that

style? What are some of the common specializations?

3.1. Pipes and Filters

In a pipe and filter style each component has a set of inputs and a set of

outputs. A component reads streams of data on its inputs and produces

streams of data on its outputs, delivering a complete instance of the result in a

standard order. This is usually accomplished by applying a local

transformation to the input streams and computing incrementally so output

begins before input is consumed. Hence components are termed “filters”. The

connectors of this style serve as conduits for the streams, transmitting outputs

of one filter to inputs of another. Hence the connectors are termed “pipes”.

Among the important invariants of the style, filters must be independent

entities: in particular, they should not share state with other filters. Another

important invariant is that filters do not know the identity of their upstream

and downstream filters. Their specifications might restrict what appears on the

input pipes or make guarantees about what appears on the output pipes, but

they may not identify the components at the ends of those pipes. Furthermore,

the correctness of the output of a pipe and filter network should not depend on

the order in which the filters perform their incremental processing—although

fair scheduling can be assumed. (See [5] for an in-depth discussion of this style

and its formal properties.) Figure 1 illustrates this style.

Common specializations of this style include pipelines, which restrict the

topologies to linear sequences of filters; bounded pipes, which restrict the

amount of data that can reside on a pipe; and typed pipes, which require that

the data passed between two filters have a well-defined type.

剩余41页未读，继续阅读

asdf_2009

粉丝: 2
资源: 15

软件架构基础：David Garlan与Mary Shaw的见解

Pattern-Oriented Software Architecture 全集（vol1到vol5）

Pattern-Oriented Software Architecture Vol 4 Server Component Patterns

software architecture

Software Architecture

SoftwareArchitecture：SoftwareArchitecture

Software Architecture 2010

AgileSoftwareArchitecture

embedded Software Architecture

Software Architecture Document

software architecture introduction

最新资源