架构实战-软件架构设计的过程_PDF下载[84MB-百度云]伊乐斯(PeterEeles)

节选

[

《架构实战:软件架构设计的过程》从基本原理入手，介绍软件架构设计过程中涉及的一些概念、流程、方法、用到的工作产品及可重用的资源，从第6章开始，通过介绍一个具体的案例来阐述如何定义需求、创建逻辑架构、创建物理架构。在第10章“进阶”中，作者补充说明了架构师和软件开发项目其他方面的关系，后面又说明了各种软件开发项目可能存在的困难及相应的处理方法。《架构实战:软件架构设计的过程》理论结合实践，介绍了一些可以应用到整个或部分的架构设计流程中的*佳方法。不管你是一位资深的架构师还是一位有志于成为架构师的初级使用者，通过阅读《架构实战:软件架构设计的过程》都能从中获益。

]

相关资料

[

插图：2.4 架构设计的优点总的来说，架构设计是降低成本、改进质量、支持按计划及时交付、支持按需求交付及降低风险的-个关键因素。在这一部分，我们集中讲述架构设计有助于达成这些目标的更明确的优点。另外，因为架构师有时候必须证明架构设计的存在是合理的，这一部分将提供一些有用的资料来证明架构设计是软件开发流程中的一个重要组成部分。2.4.1 架构设计解决系统的质量问题系统的功能性是通过组成架构的各种元素之间发生的交互来支持的。不管怎样，架构设计的关键特征之一是系统质量是通过架构这个工具达到的。在缺少统一的架构设想的情况下，像性能、安全及可维护性这样的质量是不可能保证的，这些质量不仅限于单个架构元素，而是遍布于整个架构。例如，为了处理性能的需求，必须考虑架构的每个组件执行的时间以及组件之间通信所花的时间。同样，为了处理安全的需求，必须考虑组件之间的通信类型，而且在必要的地方引入专门的具有安全意识的组件。所有这些考虑都是关于架构的，而且，在这些例子中，涉及这些组件本身以及它们之间的联系。架构设计的一个相关优点是使得在项目生命周期的早期评估这类质量成为可能。通常特意创建架构的概念模型以确保处理这类质量。通过一个真实的实现（在这种情况下采用架构概念模型）来证明达到这类质量要求，这很重要，因为一个架构无论在纸上看起来多么优秀，只有可执行软件才是这种架构已经处理这类质量的唯一真实标准。2.4.2 架构设计促进达成共识架构设计流程促进不同的利益相关者达成共识，因为它提供了一个工具使大家能够对系统解决方案进行辩论。为了支持这样的辩论，架构设计流程必须确保架构被清楚地交流和证实。一个可以被有效交流的架构使得大家对决策和折中进行辩论，使检查变得容易，还使得大家达成一致。相反，一个缺乏交流的架构不会使这样的辩论发生。没有这样的输入，最终的架构可能是低质量的。很明显，对一个架构进行有效交流的一个重要方面是为它适当地编写文档。这是架构师的主要关注点，也是第4章“编写软件架构文档”的主题。需要注意的是，架构可以作为培训的一部分，促进架构师（及他们的设想）和新的或现有的团队成员之间达成共识。为了取得这个好处，架构还必须进行有效地交流。清楚知道他们正在实现的内容的开发团队会更有可能按期望实现产品。通过验证

]

本书特色

[

ibm高级it架构师倾力打造关于软件架构流程的全面、权威参考书
　　从实战出发，涵盖软件架构设计全过程

]

内容简介

[

本书从基本原理入手，介绍软件架构设计过程中涉及的一些概念、流程、方法、用到的工作产品及可重用的资源，从第6章开始，通过介绍一个具体的案例来阐述如何定义需求、创建逻辑架构、创建物理架构。在第10章“进阶”中，作者补充说明了架构师和软件开发项目其他方面的关系，后面又说明了各种软件开发项目可能存在的困难及相应的处理方法。
　　本书理论结合实践，介绍了一些可以应用到整个或部分的架构设计流程中的*佳方法。不管你是一位资深的架构师还是一位有志于成为架构师的初级使用者，通过阅读本书都能从中获益。

]

作者简介

[

Peter Eeles 是IBM的高级IT架构师，他就职于IBM的Rational品牌软件组。在这个职位上，他帮助组织提高软件开发能力，尤其关注和致力于改进架构流程。Peter从1985年开始从事软件行业，其主要工作是进行架构设计和实现大规模、分布式的系统。Peter是《Building J2EE Applications with the Rational Unified Process》（Addison�瞁esley，2002）和《Building business Objects》（John Wiley & Sons，1998）的合著者。

]

译者序序前言致谢作者简介第1章　导言　1.1　流程应用　1.2　流程概述　1.3　范围　1.4　总结第2章　架构、架构师和架构设计　2.1　架构　　2.1.1　架构定义结构　　2.1.2　架构定义行为　　2.1.3　架构关注重要的元素　　2.1.4　架构平衡利益相关者的需要　　2.1.5　架构基于合理证据使决策具体化　　2.1.6　架构会遵循一种架构风格　　2.1.7　架构受它的环境影响　　2.1.8　架构影响开发团队的结构　　2.1.9　所有系统都存在架构　　2.1.10　架构有特定的范围　2.2　架构师　　2.2.1　架构师是技术领导　　2.2.2　架构师的角色可能由一个团队来履行　　2.2.3　架构师理解软件开发流程　　2.2.4　架构师掌握业务领域的知识　　2.2.5　架构师掌握技术知识　　2.2.6　架构师掌握设计技能　　2.2.7　架构师具备编程技能　　2.2.8　架构师是优秀的沟通人员　　2.2.9　架构师进行决策　　2.2.10　架构师知道组织政策　　2.2.11　架构师是谈判专家　2.3　架构设计　　2.3.1　架构设计是一门科学　　2.3.2　架构设计是一门艺术　　2.3.3　架构设计跨越很多方面　　2.3.4　架构设计是一个渐进的活动　　2.3.5　架构设计受许多利益相关者驱动　　2.3.6　架构设计经常包括折中　　2.3.7　架构设计承认经验　　2.3.8　架构设计既由上而下也由下而上　2.4　架构设计的优点　　2.4.1　架构设计解决系统的质量问题　　2.4.2　架构设计促进达成共识　　2.4.3　架构设计支持计划编制流程　　2.4.4　架构设计促进架构的完整性　　2.4.5　架构设计有助于管理复杂性　　2.4.6　架构设计为重用提供基础　　2.4.7　架构设计降低维护成本　　2.4.8　架构设计支持影响分析　2.5　总结第3章　方法基本原理　3.1　关键概念　3.2　方法内容　　3.2.1　角色　　3.2.2　工作产品　　3.2.3　活动　　3.2.4　任务　3.3　流程　　3.3.1　瀑布流程　　3.3.2　迭代流程　　3.3.3　敏捷流程　3.4　总结第4章　编写软件架构文档第5章　可重用架构资源第6章　案例介绍第7章　定义需求第8章　创建逻辑架构第9章　创建物理架构第10章　进阶附录a　软件架构元模型附录b　视点目录附录c　方法概述附录d　架构需求检查列表术语表参考文献