实战指南：软件架构师成长手册

需积分: 9 75 浏览量更新于2024-07-23 收藏 3.5MB PDF 举报

《软件架构师速成营》(Software Architect Bootcamp)是由Raphael Malveau和Thomas J. Mowbray两位经验丰富的软件架构大师合作编撰的。该书由Prentice Hall PTR出版社于2000年10月首次发行，ISBN号为0-13-027407-0，共352页，旨在为软件开发人员提供成为优秀软件架构师所需的实战指南。本书是一本“实战手册”，旨在帮助开发者在软件架构设计领域迅速上手并实现成长。它涵盖了广泛的实用知识，包括设计模式、原型制作、业务场景开发、领导力培养等关键主题。两位作者分享了他们在利用面向对象、组件化和分布式互联网计算进行架构设计时的深刻洞察和实用解决方案，指导读者如何避免常见的耗时陷阱和昂贵的错误。书中深入探讨了如何针对不同的项目选择最合适的架构模型，区分轻量级和重量级的软件架构方法，并关注如何处理可扩展性和长期商业灵活性的问题。此外，读者将学习如何充分利用抽象、重构和架构原型化来优化设计过程，以及如何有效地运用这些技术来提升项目的整体效能。《软件架构师速成营》不仅教授理论知识，更注重实践操作，通过实例和案例研究帮助读者在实际工作中应用所学，确保他们在软件架构的职业道路上稳步前行。这本书对于正在寻求转型或希望提升现有技能的软件工程师来说，是一本不可或缺的参考书籍。无论是初入领域的新人还是资深的专业人士，都能从中收获宝贵的经验和指导。

IT-SC 13

Of course, we do not want to lose the inherent benefit of bad is better, i.e., rapid delivery.

Architecture-centered approaches utilize several techniques, including pragmatism,

architecture planning, and architecture reuse, which jointly support increased productivity,

reduced risk, and minimum time-to-market.

The Software Crisis

Many of us have serious misconceptions about the capabilities of current software

approaches. Based upon surveys of corporate software projects in the United States, the

realities of software development are as follows [Brown 98]. About one-third of all

software projects are cancelled. Average projects expend twice as much budget and

schedule as initially planned. After delivery, the majority of systems are considered

unsuccessful because they have far fewer capabilities than expected. Modification and

extension of systems are the most expensive cost drivers and very likely to create new

defects. Overall, virtually all application software projects produce stovepipe

systems, brittle software architectures that underperform on requirements.

The software crisis in corporate development became apparent decades ago, when

procedural software technologies were popular. Subsequent, object-oriented approaches

(such as the Object Modeling Technique) have been equally unsuccessful for corporate

developers. These outcomes have been repeatedly confirmed by research [Brown 98].

Three key factors are exacerbating the software crisis:

requirements change

commercial innovation

distributed computing

A significant part of the problem is rising user expectations. User requirements for

systems have increased much faster than corporate developers' capability to deliver.

Requirements changes are more frequent, as businesses maneuver for competitive

advantage with strategic corporate software.

Another confounding factor is the destabilizing force of accelerating technology

innovation, in both commercial software and hardware platforms. Corporate developers

have difficulty finding compatible configurations of software products and are forced to

upgrade configurations frequently as new products are released. Software maintenance

due to technology upgrades is a significant corporate cost driver.

Owing to predominance of the Internet and geographically diverse enterprises, distributed

computing is an essential feature of many new applications. Traditionally, software

designers assumed homogeneous configurations, centralized systems, local

communications, and infrequent failures. Today's highly distributed enterprises require

heterogeneous hardware/software, decentralized legacy configurations, and complex

communications infrastructure. The resulting computing environments have frequent

partial system failures. Distributed computing reverses many key assumptions that are the

basis for procedural and object-oriented software development.

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

剩余293页未读，继续阅读

点点吃得太多了

粉丝: 180
资源: 680

实战指南：软件架构师成长手册

IBM_Rational_Software_Architect

Software Architect Bootcamp

Prentice Hall - Software Architect.pdf

036GraphTheory(图论) matlab代码.rar

026SVM用于分类时的参数优化，粒子群优化算法，用于优化核函数的c,g两个参数(SVM PSO)Matlab代码.rar

药店管理-JAVA-基于springBoot的药店管理系统的设计与实现（毕业论文+开题）

【网络】基于matlab高动态网络拓扑中OSPF网络计算【含Matlab源码 10964期】.zip

今天吴老师上课的时候说我.txt

检测骨架图像的交点Matlab代码.rar

MMC simulink 模块化多电平变流器 载波移相 双闭环仿真 输出谐波分析，线性自抗扰控制LADRC 有仿真文件

最新资源

MMC simulink 模块化多电平变流器载波移相双闭环仿真输出谐波分析，线性自抗扰控制LADRC 有仿真文件