实践中的软件架构：第三版详解

3星 · 超过75%的资源需积分: 15 48 浏览量更新于2024-07-20 收藏 39.87MB PDF 举报

"《软件架构实践》第三版是Len Bass、Paul Clements和Rick Kazman合著的一本权威指南，深入探讨了软件架构的设计与实施。该书针对实际项目中的软件架构问题，提供了实用的策略和方法论，旨在帮助软件开发者、架构师和团队在复杂的技术环境中构建可维护、可扩展和高性能的软件系统。在本书中，作者强调了软件架构的重要性，它不仅影响系统的整体性能，还对团队协作、成本控制和长期演进有着深远影响。书中涵盖了软件架构的各个层面，包括但不限于架构设计原则、模式识别、架构决策过程、领域驱动设计（DDD）、微服务架构、云计算和DevOps等现代技术的应用。然而，由于版权保护的严格性，未经出版商事先书面许可，任何章节或书籍内容都不能以任何形式进行复制或传播，这符合美国版权法第17章第107节关于合理使用的条款，同时也遵守了在线服务的使用条款。任何违反这些规定的行为将受到美国联邦和马萨诸塞州法律的严厉追究。《软件架构实践》第三版对于那些希望提升软件工程实践的专业人士来说，是一本不可或缺的参考书，它提供了丰富的案例研究和实战经验分享，帮助读者理解和应用软件架构的最佳实践。无论是新手还是经验丰富的从业者，都可以通过阅读这本书来深化对软件架构的理解，从而提高项目的成功率和软件质量。" 该书适合在课堂教育、研讨会、技术团队培训以及个人自我学习中使用，但务必确保尊重并遵循版权法规。如果你在学术或教学活动中需要引用其中的内容，务必获得官方授权，以确保合规性和尊重知识产权。

Username:

Carleton University Library

Book:

Software Architecture in Practice, Third Edition.

No part of any chapter or book may be reproduced or

transmitted in any form by any means without the prior written permission for reprints and excerpts from the publisher of the book or chapter.

Redistribution or other use that violates the fair use privilege under U.S. copyright laws (see 17 USC107) or that otherwise violates these Terms of

Service is strictly prohibited. Violators will be prosecuted to the full extent of U.S. Federal and Massachusetts laws.

Acknowledgments

We had a fantastic collection of reviewers for this edition, and their assistance helped make this a better book. Our reviewers were

Muhammad Ali Babar, Felix Bachmann, Joe Batman, Phil Bianco, Jeromy Carriere, Roger Champagne, Steve Chenoweth, Viktor Clerc,

Andres Diaz Pace, George Fairbanks, Rik Farenhorst, Ian Gorton, Greg Hartman, Rich Hilliard, James Ivers, John Klein, Philippe Kruchten,

Phil Laplante, George Leih, Grace Lewis, John McGregor, Tommi Mikkonen, Linda Northrop, Ipek Ozkaya, Eltjo Poort, Eelco Rommes, Nick

Rozanski, Jungwoo Ryoo, James Scott, Antony Tang, Arjen Uittenbogaard, Hans van Vliet, Hiroshi Wada, Rob Wojcik, Eoin Woods, and

Liming Zhu.

In addition, we had significant contributions from Liming Zhu, Hong-Mei Chen, Jungwoo Ryoo, Phil Laplante, James Scott, Grace

Lewis, and Nick Rozanski that helped give the book a richer flavor than one written by just the three of us.

The issue of build efficiency in

Chapter 12

came from Rolf Siegers and John McDonald of Raytheon. John Klein and Eltjo Poort

contributed the “abstract system clock” and “sandbox mode” tactics, respectively, for testability. The list of stakeholders in

Chapter 3

is from

Documenting Software Architectures: Views and Beyond, Second Edition.

Some of the material in

Chapter 28

was inspired by a talk given

by Anthony Lattanze called “Organizational Design Thinking” in 2011.

Joe Batman was instrumental in the creation of the seven categories of design decisions we describe in

Chapter 4

. In addition, the

descriptions of the security view, communications view, and exception view in

Chapter 18

are based on material that Joe wrote while

planning the documentation for a real system’s architecture. Much of the new material on modifiability tactics was based on the work of Felix

Bachmann and Rod Nord. James Ivers helped us with the security tactics.

Both Paul Clements and Len Bass have taken new positions since the last edition was published, and we thank their new respective

managements (BigLever Software for Paul and NICTA for Len) for their willingness to support our work on this edition. We would also like to

thank our (former) colleagues at the Software Engineering Institute for multiple contributions to the evolution of the ideas expressed in this

edition.

Finally, as always, we thank our editor at Addison-Wesley, Peter Gordon, for providing guidance and support during the writing and

production processes.

http://proquest.safaribooksonline.com.proxy.librar...

1 of 1 2017-03-04 04:33 PM

Username:

Carleton University Library

Book:

Software Architecture in Practice, Third Edition.

No part of any chapter or book may be reproduced or

transmitted in any form by any means without the prior written permission for reprints and excerpts from the publisher of the book or chapter.

Redistribution or other use that violates the fair use privilege under U.S. copyright laws (see 17 USC107) or that otherwise violates these Terms of

Service is strictly prohibited. Violators will be prosecuted to the full extent of U.S. Federal and Massachusetts laws.

1. What Is Software Architecture?

Good judgment is usually the result of experience. And

experience is frequently the result of bad judgment. But

to learn from the experience of others requires those

who have the experience to share the knowledge with

those who follow.

—Barry LePatner

Writing (on our part) and reading (on your part) a book about software architecture, which distills the experience of many people,

presupposes that

having a software architecture is important to the successful development of a software system and

there is a sufficient, and sufficiently generalizable, body of knowledge about software architecture to fill up a book.

One purpose of this book is to convince you that both of these assumptions are true, and once you are convinced, give you a basic

knowledge so that you can apply it yourself.

Software systems are constructed to satisfy organizations’ business goals. The architecture is a bridge between those (often abstract)

business goals and the final (concrete) resulting system. While the path from abstract goals to concrete systems can be complex, the good

news is that software architectures can be designed, analyzed, documented, and implemented using known techniques that will support the

achievement of these business and mission goals. The complexity can be tamed, made tractable.

These, then, are the topics for this book: the design, analysis, documentation, and implementation of architectures. We will also

examine the influences, principally in the form of business goals and quality attributes, which inform these activities.

In this chapter we will focus on architecture strictly from a software engineering point of view. That is, we will explore the value that a

software architecture brings to a development project. (Later chapters will take a business and organizational perspective.)

http://proquest.safaribooksonline.com.proxy.librar...

1 of 1 2017-03-04 04:33 PM

Username:

Carleton University Library

Book:

Software Architecture in Practice, Third Edition.

No part of any chapter or book may be reproduced or

transmitted in any form by any means without the prior written permission for reprints and excerpts from the publisher of the book or chapter.

Redistribution or other use that violates the fair use privilege under U.S. copyright laws (see 17 USC107) or that otherwise violates these Terms of

Service is strictly prohibited. Violators will be prosecuted to the full extent of U.S. Federal and Massachusetts laws.

1.1. What Software Architecture Is and What It Isn’t

There are many definitions of software architecture, easily discoverable with a web search, but the one we like is this one:

The software architecture of a system is the set of structures needed to reason about the system, which comprise

software elements, relations among them, and properties of both.

This definition stands in contrast to other definitions that talk about the system’s “early” or “major” design decisions. While it is true that

many architectural decisions are made early, not all are—especially in Agile or spiral-development projects. It’s also true that very many

decisions are made early that are not architectural. Also, it’s hard to look at a decision and tell whether or not it’s “major.” Sometimes only

time will tell. And since writing down an architecture is one of the architect’s most important obligations, we need to know now which

decisions an architecture comprises.

Structures, on the other hand, are fairly easy to identify in software, and they form a powerful tool for system design.

Let us look at some of the implications of our definition.

Architecture Is a Set of Software Structures

This is the first and most obvious implication of our definition. A structure is simply a set of elements held together by a relation. Software

systems are composed of many structures, and no single structure holds claim to being

the

architecture. There are three categories of

architectural structures, which will play an important role in the design, documentation, and analysis of architectures:

First, some structures partition systems into implementation units, which in this book we call

modules

. Modules are assigned

specific computational responsibilities, and are the basis of work assignments for programming teams (Team A works on the

database, Team B works on the business rules, Team C works on the user interface, etc.). In large projects, these elements

(modules) are subdivided for assignment to subteams. For example, the database for a large enterprise resource planning

(ERP) implementation might be so complex that its implementation is split into many parts. The structure that captures that

decomposition is a kind of module structure, the

module

decomposition structure

in fact. Another kind of module structure

emerges as an output of object-oriented analysis and design—class diagrams. If you aggregate your modules into layers,

you’ve created another (and very useful) module structure. Module structures are static structures, in that they focus on the

way the system’s functionality is divided up and assigned to implementation teams.

Other structures are dynamic, meaning that they focus on the way the elements interact with each other at runtime to carry

out the system’s functions. Suppose the system is to be built as a set of services. The services, the infrastructure they

interact with, and the synchronization and interaction relations among them form another kind of structure often used to

describe a system. These services are made up of (compiled from) the programs in the various implementation units that we

just described. In this book we will call runtime structures

component-and-connector

(C&C) structures. The term

component

is overloaded in software engineering. In our use, a component is always a runtime entity.

A third kind of structure describes the mapping from software structures to the system’s organizational, developmental,

installation, and execution environments. For example, modules are assigned to teams to develop, and assigned to places

in a file structure for implementation, integration, and testing. Components are deployed onto hardware in order to execute.

These mappings are called

allocation

structures.

Although software comprises an endless supply of structures, not all of them are architectural. For example, the set of lines of source

code that contain the letter “z,” ordered by increasing length from shortest to longest, is a software structure. But it’s not a very interesting

one, nor is it architectural. A structure is architectural if it supports reasoning about the system and the system’s properties. The reasoning

should be about an attribute of the system that is important to some stakeholder. These include functionality achieved by the system, the

availability of the system in the face of faults, the difficulty of making specific changes to the system, the responsiveness of the system to

user requests, and many others. We will spend a great deal of time in this book on the relationship between architecture and quality

attributes like these.

Thus, the set of architectural structures is not fixed or limited. What is architectural is what is useful in your context for your system.

Architecture Is an Abstraction

Because architecture consists of structures and structures consist of elements

and relations, it follows that an architecture comprises

software elements and

how the elements relate to each other. This means that architecture specifically omits certain information about

elements that is not useful for reasoning about the system—in particular, it omits information that has no ramifications outside of a single

element. Thus, an architecture is foremost an

abstraction

of a system that selects certain details and suppresses others. In all modern

systems, elements interact with each other by means of interfaces that partition details about an element into public and private parts.

Architecture is concerned with the public side of this division; private details of elements—details having to do solely with internal

implementation—are not architectural. Beyond just interfaces, though, the architectural abstraction lets us look at the system in terms of its

elements, how they are arranged, how they interact, how they are composed, what their properties are that support our system reasoning,

and so forth. This abstraction is essential to taming the complexity of a system—we simply cannot, and do not want to, deal with all of the

complexity all of the time.

. In this book we use the term “element” when we mean either a module or a component, and don’t want to distinguish.

http://proquest.safaribooksonline.com.proxy.librar...

1 of 3 2017-03-04 04:33 PM

Every Software System Has a Software Architecture

Every system can be shown to comprise elements and relations among them to support some type of reasoning. In the most trivial case, a

system is itself a single element—an uninteresting and probably non-useful architecture, but an architecture nevertheless.

Even though every system has an architecture, it does not necessarily follow that the architecture is known to anyone. Perhaps all of

the people who designed the system are long gone, the documentation has vanished (or was never produced), the source code has been

lost (or was never delivered), and all we have is the executing binary code. This reveals the difference between the architecture of a system

and the

representation

of that architecture. Because an architecture can exist independently of its description or specification, this raises the

importance of

architecture documentation

, which is described in

Chapter 18

, and

architecture reconstruction

, discussed in

Chapter 20

Architecture Includes Behavior

The behavior of each element is part of the architecture insofar as that behavior can be used to reason about the system. This behavior

embodies how elements interact with each other, which is clearly part of our definition of architecture.

This tells us that box-and-line drawings that are passed off as architectures are in fact not architectures at all. When looking at the

names of the boxes (database, graphical user interface, executive, etc.), a reader may well imagine the functionality and behavior of the

corresponding elements. This mental image approaches an architecture, but it springs from the imagination of the observer’s mind and relies

on information that is not present. This does not mean that the exact behavior and performance of every element must be documented in all

circumstances—some aspects of behavior are fine-grained and below the

architect’s level of concern. But to the extent that an element’s

behavior influences another element or influences the acceptability of the system as a whole, this behavior must be considered, and should

be documented, as part of the software architecture.

Not All Architectures Are Good Architectures

The definition is indifferent as to whether the architecture for a system is a good one or a bad one. An architecture may permit or preclude a

system’s achievement of its behavioral, quality attribute, and life-cycle requirements. Assuming that we do not accept trial and error as the

best way to choose an architecture for a system—that is, picking an architecture at random, building the system from it, and then hacking

away and hoping for the best—this raises the importance of

architecture design

, which is treated in

Chapter 17

, and

architecture evaluation

which we deal with in

Chapter 21

System and Enterprise Architectures

Two disciplines related to software architecture are system architecture and enterprise architecture. Both of these

disciplines have broader concerns than software and affect software architecture through the establishment of

constraints within which a software system must live. In both cases, the software architect for a system should be

on the team that provides input into the decisions made about the system or the enterprise.

System architecture

A system’s architecture is a representation of a system in which there is a mapping of functionality onto hardware

and software components, a mapping of the software architecture onto the hardware architecture, and a concern

for the human interaction with these components. That is, system architecture is concerned with a total system,

including hardware, software, and humans.

A system architecture will determine, for example, the functionality that is assigned to different processors and

the type of network that connects those processors. The software architecture on each of those processors will

determine how this functionality is implemented and how the various processors interact through the exchange of

messages on the network.

A description of the software architecture, as it is mapped to hardware and networking components, allows

reasoning about qualities such as performance and reliability. A description of the system architecture will allow

reasoning about additional qualities such as power consumption, weight, and physical footprint.

When a particular system is designed, there is frequently negotiation between the system architect and the

software architect as to the distribution

of functionality and, consequently, the constraints placed on the software

architecture.

Enterprise architecture

Enterprise architecture is a description of the structure and behavior of an organization’s processes, information

flow, personnel, and organizational subunits, aligned with the organization’s core goals and strategic direction. An

enterprise architecture need not include information systems—clearly organizations had architectures that fit the

preceding definition prior to the advent of computers—but these days, enterprise architectures for all but the

smallest businesses are unthinkable without information system support. Thus, a modern enterprise architecture is

concerned with how an enterprise’s software systems support the business processes and goals of the enterprise.

Typically included in this set of concerns is a process for deciding which systems with which functionality should be

supported by an enterprise.

An enterprise architecture will specify the data model that various systems use to interact, for example. It will

specify rules for how the enterprise’s systems interact with external systems.

Software is only one concern of enterprise architecture. Two other common concerns addressed by enterprise

architecture are how the software is used by humans to perform business processes, and the standards that

determine the computational environment.

http://proquest.safaribooksonline.com.proxy.librar...

2 of 3 2017-03-04 04:33 PM

剩余464页未读，继续阅读

scutgui

粉丝: 1
资源: 8

实践中的软件架构：第三版详解

Software Architecture in Practice(软件架构实践)英文第二版(pdf完整文字版)

Software Architecture in Practice,2nd Edition--软件构架实践(第2版)

浙江大学王灿软件体系结构PPT

software architecture in practice three下载

你知道《Software Architecture in Practice, 4th Edition》这本书吗

software architecture in practice

software architecture in practice 中文版

引用的写出体系结构相关文献

软件设计师教程电子书

explain software architecture of android

最新资源