《软件架构师实战指南》深度解析：从设计模式到领导力提升

需积分: 31 133 浏览量更新于2024-07-23 收藏 3.16MB PDF 举报

《软件架构师教程：实战手册》是由Raphael Malveau和Thomas J. Mowbray共同编著的一本专业书籍，由Prentice Hall PTR出版社于2000年10月首次出版。该书的ISBN为0-13-027407-0，共352页，旨在为软件开发人员提供成为优秀软件架构师所需的实战指南。作为一本"现场操作手册"，它深入探讨了软件架构设计的各个方面，包括设计模式、原型制作、业务案例开发以及领导力培养。本书的核心内容涵盖了软件架构的关键挑战，特别是在面向对象、组件和分布式互联网计算的环境中。作者分享了深刻的洞察和实用的解决方案，帮助读者避免耗费时间和金钱的陷阱和错误。以下是一些关键章节的主要知识点： 1. **最佳架构模型选择**：学习如何根据不同项目的特性，识别并选择最合适的架构模式，确保项目的高效性和可持续性。 2. **软件架构方法论**：区分并实践重型（ heavyweight）和轻型（ lightweight）架构方法，以适应不同复杂度和需求变化的情况。 3. **应对可扩展性和灵活性**：探讨如何设计能够支持长期增长和商业环境变化的架构，以确保系统的弹性。 4. **抽象与重构的重要性**：理解抽象原则在软件设计中的作用，掌握如何通过重构优化代码结构，提高代码质量和维护性。 5. **架构原型设计**：学会使用架构原型作为探索和决策工具，快速验证和优化设计方案。 6. **领导力与团队协作**：作为软件架构师，如何引领团队进行有效的沟通，协调跨职能团队，推动项目成功。 7. **分布式系统与互联网技术**：熟悉分布式计算架构、网络通信协议及云计算技术的应用，以构建分布式系统和云服务架构。通过阅读这本书，软件开发者不仅可以提升自身的专业技能，还能获得在实际项目中运用软件架构的最佳实践，从而成长为一名成功的软件架构师。书中丰富的实例和实用建议，对于正在寻求转型或者希望进一步提升的工程师来说，具有很高的参考价值。

IT-SC 14

The software industry has established object orientation (OO) as the mainstream

technology. OO is the technology adopted by new corporate development projects

because it is universally supported by software tool vendors. Masses of legacy

programmers are training for object-oriented development (e.g., C++ and the Java

programming language) as corporations create new strategic systems. Unfortunately,

these developers and corporations are likely to become the next generation of

disillusioned participants in the software crisis. However, the organizations that survive

and thrive with this technology, must use it in sophisticated new ways, represented by

componentware.

1.2 Software Architecture as a Discipline

As a professional discipline, software architecture has at least a dozen schools of thought.

Some of the major schools of thought include:

Zachman Framework [Zachman 97]

Open Distributed Processing (ODP) [ISO 96]

Domain Analysis [Rogers 97]

Rational's 4+1 View Model [Booch 98]

Academic Software Architecture [Bass 98]

Alternative architecture approaches share concepts and principles, but their terminologies

differ greatly. Each architecture school is relatively isolated from the others. In the

literature of any given school, perhaps one or two other schools are acknowledged,

however briefly. None of the schools appear to make any significant use of the results of

the others. Since the terminology between these groups varies significantly,

communication is difficult, especially between practitioners using different architecture

approaches. Upon further study, we find that the goals of each school are quite similar,

and each school has some unique value to offer.

In addition to these schools, there are many vendor-driven approaches that are tied to

specific product lines, such as Netscape ONE, Sun Enterprise JavaBeans, and Microsoft

BackOffice. In fact, every vendor appears to have a unique architectural vision for the

future founded upon its own product lines.

Many vendors actually have minimal understanding of application architecture. Thus, I

focus here on those approaches which consider key application drivers with appropriate

product support for underlying capabilities.

Architecture Approaches

Here is a brief tour of the major schools of software architecture thought.

Zachman Framework

IT-SC 15

Derived from IBM research and practice, the Zachman Framework is a traditional

architecture approach; i.e., it is decidedly non-OO. The Zachman Framework is a

reference model comprising 30 architecture viewpoints. The reference model is a matrix,

which intersects two paradigms: journalism (who, what, when, why, where, and how) and

construction (planner, owner, builder, designer, subcontractor). Architects choose from

among these viewpoints to specify a system architecture.

Open Distributed Processing

A formal standard from ISO and ITU (telecommunications), Open Distributed Processing

(ODP) defines a five-viewpoint reference model (enterprise, information, computational,

engineering, and technology). ODP defines a comprehensive set of terminology, a

conformance approach, and viewpoint correspondence rules for traceability. The product

of seven years of standards work, ODP is a recent adoption that fully supports OO and

component-based architecture. In fairness, I should note that ODP is my primary

approach to software architecture.

Domain Analysis

A process for the systematic management of software reuse, domain analysis transforms

project-specific requirements into more general domain requirements for families of

systems. The requirements then enable the identification of common capabilities, which

are used as the basis for horizontal frameworks and reusable software architectures. An

important capability of this approach is the definition of robust software designs, which

are relatively resistant to requirements and context changes.

4+1 View Model

A four-viewpoint approach is under development by Rational Software. The viewpoints

include: logical, implementation (formerly "component"), process (i.e., runtime), and

deployment. The "+1" denotes use case specifications supporting requirements capture.

This approach is closely aligned with the Unified Modeling Language and the Unified

Process.

Academic Software Architecture

Academic software architecture comprises a community of computer science researchers

and educators constituting an academic field. Their educational efforts are focused on

basics and fundamentals. In their research contributions, this community avoids proven

architectural standards and practices in order to achieve originality, theoretical formality,

and other academic goals.

Common Principles

It is often said that the principles of software are simple. For example, let's consider (1)

simplicity and (2) consistency. Architects agree that managing complexity (i.e., achieving

simplicity) is a key goal, because it leads to many architectural benefits, such as system

IT-SC 16

adaptability and reduced system cost. For example, a simpler system is easier to test,

document, integrate, extend, and so forth.

" Explore the situation from more than one point of view. A seemingly impossible

situation might become transparently simple " [Rechtin 97].

Simplicity is most necessary in the specification of the architecture itself. Most

architectural approaches utilize multiple viewpoints to specify architecture. Viewpoints

separate concerns into a limited set of design forces, which can be resolved in a

straightforward and locally optimal manner.

Consistency enhances system understanding and transfer of design knowledge between

parts of the system and between developers. An emphasis on consistency contributes to

the discovery of commonality and opportunities for reuse. Architects agree that

unnecessary diversity in design and implementation leads to decidedly negative

consequences, such as brittle system structure.

Architecture Controversies

The principal disagreements among architecture schools include: (1) terminology, (2)

completeness, and (3) a priori viewpoints.

Architects disagree on terminology due to their backgrounds or schools of thought. For

example, when discussing software interfaces, the consistency principle is variously

called: standard interfaces, common interfaces, horizontal interfaces, plug-and-play

interfaces, and interface generalization. We can also argue that variation-centered

design (from design patterns) and component substitution are largely based upon

consistent interface structure.

Unnecessary diversity of terminology leads to confusion, and sometimes to proprietary

advantage. Some vendors and gurus change terminology so frequently that keeping up

with their latest expressions becomes a time-consuming career.

Differences in terminology lead to miscommunication. In contrast, some distinct areas of

disagreement among architecture schools can't be resolved through improved

communications alone.

The notion of complete models is promoted by legacy OO approaches (e.g., OMT), the

Zachman Framework school, and various others. These groups have promoted a vision

that complete models (describing multiple phases of development) are a worthwhile goal

of software development projects. Other schools would argue that multiple models are

not maintainable, that unnecessarily detailed models are counterproductive, and that

architectural significance should be considered when selecting system features for

modeling.

These contrary notions can be summarized in terms of the principle of pragmatism. We

side with the pragmatists for the above reasons and because most software systems are

too complex to model completely (e.g., multithreaded distributed computing systems).

IT-SC 17

Pragmatism is a key principle to apply in the transition from document-driven to

architecture-centered software process.

The selection of architecture viewpoints is a key point of contention among architecture

schools. Some schools have preselected a priori viewpoints. Some schools leave that

decision to individual projects. The Zachman Framework is an interesting case, because it

proposes 30 viewpoints, from among which most projects select groups of viewpoints to

specify.

Variable viewpoints have the advantage that they can be tailored to address the concerns

of particular system stakeholders. Predefined viewpoints have the advantage that they can

accompany a stable conceptual framework and a well-defined terminology, as well as

predefined approaches for resolving viewpoint consistency and architecture conformance.

Innovative Software Architecture

There are many active and successful schools of software architecture thought. Software

architecture is a discipline unified by principles, but divided by terminology. The various

architecture schools can be viewed as different branches of an evolutionary progression.

The Zachman Framework has evolved from the traditional non-OO approaches. ODP is

an outgrowth from object-oriented and distributed-computing paradigms that has

achieved stability, multiindustry acceptance, and formal standardization. Both Zachman

and ODP approaches have enjoyed significant success in production-quality software

development. Domain analysis has demonstrated its worth in defining robust, domain-

specific software architectures for reuse. The 4+1 View Model is an approach undergoing

development, in parallel with the Unified Process.

All of the above can be described as innovative software architecture approaches. They

are being applied in practice, based upon various levels of proven experience. Academic

research in software architecture is defining a baseline for architecture knowledge that

resembles a lowest common denominator of the above approaches. Fortunately, the

academic community has legitimized the role of the software architect, regardless of

whether their guidance is useful to innovative architects.

In our opinion, software architects should have a working knowledge of the innovative

approaches described above. In addition, they should utilize one of the product-quality

architecture frameworks in daily practice. Component architecture development is a

challenging area, requiring the best of stable conceptual frameworks supporting sound

architectural judgment.

The Architecture Paradigm Shift

The nature of information systems is changing from localized departmental application to

large-scale global and dynamic systems. This trend is following the change in business

environments toward globalization. The migration from relatively static and local

剩余292页未读，继续阅读

irunt

粉丝: 0
资源: 2

《软件架构师实战指南》深度解析：从设计模式到领导力提升

软件架构师教程,系统架构师讲义

软件架构师教程 软件架构

软件架构师应该知道的97件事.pdf

软件架构师培训资料,软件架构师培训资料,软件架构师培训资料

软件架构师论文

软件架构师教程

软件架构师速成手册：实战成为优秀架构师

结合软件架构师招聘需求，谈谈软件架构师需要哪些技能？

有软件架构师相对于没有软件架构师的人工资会多多少

1. 什么是软件架构师?软件架构师应具有怎样的知识体系?

最新资源

软件架构师教程软件架构