本书对于如何设计和实现高效的信息系统架构提供了指导，包括如何设计反映各利益相关方不同需求的架构，如何着眼于设计架构方面的因素，如何使用案例和模式驱动架构的创造力和有效性，如果将架构文档化为一系列相关的视图等等。本书对软件架构师具有积极的指导作用，是建立最佳实践的必备参考手册。

本书核心内容围绕利益相关者、视点和视角这三个概念展开。利益相关者是我们为之创建系统的人。架构师的重要工作就是要知道如何与利益相关者协作，从而满足他们复杂、多变甚至经常冲突的需求。视点（和视图）是确定架构定义过程和架构描述结构的方法，它基于分离关注点的原则。视点包含已经过验证的架构知识，以引导架构的创建过程，本书以一系列特定视图的形式来描述它（每种视图都是在特定的视点下应用指引的结果）。视角是本书中引入的一种概念，它是视点的有效补充。视角包含已经过验证的架构知识，会分离关注点，关注跨结构的质量属性而不是架构结构，从而帮助架构师确定架构定义过程的结构。

本书主要内容：
详细阐释利益相关者、架构描述、视点、视图和视角等基本概念，并描述软件架构师的角色。
深入分析架构师所要从事的重要活动，如商量确定项目的范围、识别并管理利益相关者、使用场景和模式、创建模型以及为架构创建文档并对其加以验证等。
详细解释了在创建架构描述时最重要的七种视点：情境、功能、信息、并发、开发、部署和运维视点。
综合介绍了对信息系统最重要的视角，包括安全性、性能和可伸缩性、可用性和适应性、演进、位置、开发资源、国际化等。
如何应对用户和其他利益相关者在功能、容量、推向市场的时间以及灵活性方面提出的苛刻要求。
漫长的系统开发时间导致范围持续改变，如何应对系统架构和设计的经常变更。

作者简介

Nick Rozanski 资深软件架构师，拥有30余年软件行业工作经验。他在企业应用程序集成、程序包实现、关系型数据库、数据复制和面向对象的软件开发等领域有自己独到的见解，积累颇丰。他在包括金融、零售、制造和行政等多个领域担任重要的角色，曾任职于多家大型系统集成公司，包括Logica、Capgemini和Sybase，以及玛莎百货和Barclays全球投资公司，目前是英国一家大型银行前端IT部门的主要负责人。他曾在剑桥大学和曼彻斯特大学求学，是英国计算机学会的注册工程师和注册会员。他还是一位经验丰富的技术讲师和通过认证的内部项目审计员。
Eoin Woods 资深软件架构师，拥有近20年软件行业工作经验。他对软件架构、分布式系统、计算机安全和数据管理等技术都有深入研究。曾在多家技术公司、顾问公司和金融服务公司任职，目前是欧洲一家大型投资银行的首席软件架构师，负责该公司大量关键系统的架构和设计。他拥有布鲁塞尔大学软件工程学士学位和曼彻斯特大学软件工程硕士学位。他还是工程技术协会的注册会员，并且是英国计算机学会的注册工程师和注册会员。

译者简介

侯伯薇 资深软件开发工程师、系统工程师和系统分析师，拥有10余年软件行业从业经验。现就职于中荷人寿保险有限公司，担任高级系统分析师。致力于技术与业务的融合，让开发的程序能够真正提高业务人员的工作效率。InfoQ中文站翻译团队主编，热衷于通过翻译和演讲的方式与广大程序员分享和交流，曾翻译过多本技术书籍和几百篇技术短文，并多次在Scrumgathering、QClub、敏捷之旅等活动上发表技术演讲。

和十年前我们开始撰写本书第1 版时相比，当前IT 业界的状况已经发生了天翻地覆的变化。计算机和互联网已经成为很多人日常工作和生活的重要组成部分，这使得整个世界更紧密地连接在一起。同时，这也让用户和其他利益相关者对系统寄予更大的期望，他们希望系统功能完备、易于使用、健壮稳定、方便扩展且安全可靠。我们认为，在实现这些目标的过程中，架构师扮演了非常重要的角色，而且广大专业的软件开发者以及高级业务和技术经理也深以为然。
　　我们非常高兴地看到，本书第1 版得到了软件从业者、有抱负的软件架构师以及学术界的认可。读者认为它有用、可理解且内容丰富。然而，架构是一种不断变化的规则，因此本书第2 版会反映出从第1 版的出版到现在我们在实践中所学到和已经做出的改善。它还包括了读者发来的大量非常有用的评论和改进建议，对此我们深表感谢。
　　然而，本书的基础内容保持不变。本书的首要关注点依然在于：架构是为利益相关者提供的服务，并且是确保信息系统能够满足他们需求的一种方式。本书还是会强调视图（view）的极端重要性，它会以利益相关者可以理解的方式来显示架构的复杂性。我们还坚持认为，架构必须定义系统能如何提供利益相关者所要求达到的质量属性—如可扩展性、弹性和安全性—还要定义静态和动态结构，以及能够提供有效方式达到这些目的的透视图。
　　本书的主要受众是架构师或者期望成为架构师的人，但是，我们希望其他可能会和架构师一起工作的IT 专业人士、某天可能会成为架构师的学生，都认为这本书值得一读。
　　第2 版中做出的最重要改变如下。
　　本书引入了一种叫做情境的新视角（Context viewpoint），它会描述系统及其所处环境（人、系统以及与之交互的外部实体）之间的关系、依赖和交互。这部分内容还会将第1 版第8 章中对范围和情境相对简要的讨论进行扩展、格式化和标准化。
　　第二部分进一步讨论了架构角色的不同方面。
　　修订了大多视角和透视图的定义，特别是功能（Functional）和并发（Concurrency）视图以及性能（Performance）和可扩展性（Scalability）透视图。
　　修订和扩展了大多数章节的参考文献和延伸阅读部分。
　　更新了第1 版中的部分内容，使其可以与新的国际架构标准ISO 42010（它继承自IEEE 标准1471）中的概念和术语保持一致。
　　更新了UML 建模的建议和示例，从而适应UML 在第2 版中所引入的变更。
　　我们希望你能够发现，本书第2 版对第1 版做出了很有用的提升和扩展，我们也邀请你访问本书的网站：www.viewpoints-and-perspectives.info，在那里你可以获得更多软件架构的资源，或者可以与我们联系，提供对本书的反馈。
致谢
　　除了在第1 版中感谢的人，我们还要感谢审阅了本书第2 版的各位朋友：Paul Clements 、Tim Cull 、Rich Hilliard 、Philippe Kruchten 和Tommi Mikkonen，还有勤勉负责的文字编辑Barbara Wood 。特别要感谢Paul 彻底、具有洞察力和挑战性的意见与改进建议，这些对我们帮助很大。

第1版前言
　　本书的两位作者都是实践经验丰富的软件架构师，在信息系统开发项目中担当这个角色多年，在有些项目中是共同担任架构师，在有些项目中是分别担任的。在那期间内，我们看到软件架构师的数量得到了显著增加，而且该角色的重要性也得到同事、管理层和客户的认可。现在，所有大型的软件开发项目都需要架构师的参与，甚至在先进的开发团队中，会存在架构师小组。
　　尽管人们已经达成共识，认为软件架构师的角色非常重要，但是关于这一角色所包含的工作并没有一致的意见。谁是我们的客户？我们应该对谁负责？他们期望我们交付什么？一旦架构设计完成，我们又该做些什么？以及可能最重要的是，需求、架构和设计之间的边界是什么？
　　因为当前软件项目（特别是项目的架构师）中有很多亟待解决的问题，所以缺少对架构师角色的清晰定义，这导致了更多问题。
　　用户和其他利益相关者在功能、容量、推向市场的时间以及灵活性方面提出了更多苛求。
　　漫长的系统开发时间导致范围持续改变，进而导致系统架构和设计经常变更。
　　现在的系统要比以往功能更加丰富，结构更加复杂，经常会混用直接可用的和自定义构建的组件。
　　很少有系统能够独立存在，大多数都需要和很多其他系统交互操作并交换信息。
　　让系统的功能结构（即设计）正确只是问题的一部分。系统如何表现（例如，它的质量属性）与其对有效性同样重要。
　　技术持续改变的步伐让架构师的技术专业知识无法保持最新。
　　当第一次担任软件架构师的时候，我们试图寻找某种软件架构手册，希望它能够指导我们完成创建架构设计的过程。毕竟，其他架构方面的准则，在理论上和确立的最佳实践上都要领先软件架构几个世纪。
　　例如，在公元1 世纪，罗马人Marcus Vitruvius Pollio 就写出了第一本架构手册《建筑十书》（Ten Books on Architecture），这本书描述了建筑架构师的职责和所需要的技能，为标准的架构结构提供了丰富的资料。1670 年，日记作家Samuel Pepys 的朋友Anthony Deane，曾是英国Harwich 镇的镇长，后来又成为一位议员，出版了一本开创性的书《船舶工程学》（A Doctrine of Naval Architecture），其中详细描述了当时大型船舶设计方面的先进方法。Deane 的观点和原则在很多年间帮助人们将船舶工程的实践系统化。1901 年，英国化学工业的顾问工程师George E. Davis 发表了《化学工程学手册》（A Handbook of Chemical Engineering），从而创建了一种新领域的工程学。这是第一本定义很多实践性原则的书籍，这些原则支持了工业化化学过程，并在之后的很多年引领了该领域的发展。
　　这些最佳实践存在的重要结果就是统一了方法。如果你想要给几位架构师和工程师一项设计楼房、旅游船或者化工厂的任务，他们创建出来的设计可能会彼此不同。然而，他们使用的过程、
　　在纸上（或者计算机屏幕上）展现设计的方式以及用来确保设计合理的技术非常类似。遗憾的是，我们的行业还没有创建出可流传下去的主流业界的最佳实践。当我们查看的时候，发现很少会有介绍性的书籍，可以为信息系统架构师的工作提供详细指导。
　　我们承认，在特定的技术上已有很多书籍，不管是J2EE 、CORBA 还是.NET，还有一些更广泛的话题像Web 服务或者面向对象（尽管由于软件技术变化的速度，很多像这些书籍在几年内就过时了）。也有大量优秀的软件架构方面的书籍，我们会在部分章节中对其加以引用。但是因为这些书很多旨在创建在各种系统中都可以应用的原则，所以使用很通用的方式进行编写，大多数特定文字的目标都是针对实时和嵌入式系统社区的朋友。
　　我们觉得，如果你是一位新的信息系统软件架构师，很少有书会告诉你如何完成自己的工作，学到你所需要知道的最重要的知识，并成功地做出架构设计。我们不想取代已经存在的软件架构方面的书籍，也不敢与Vitruvius 、Deane 和Davis 比肩，让我们决定撰写这本书的驱动力就是要解决上述需求。
　　具体来说，本书将会向你展示：
　　软件架构的相关内容有哪些，你的角色对于成功交付项目为什么极度重要。
　　如何决定谁对你的架构感兴趣（你的利益相关者），理解什么对他们重要（他们的关注点），并设计反映和平衡他们不同需求的架构。
　　如何以可理解的方式与利益相关者沟通你的架构，从而说明你已经满足了他们的关注点（架构描述）。
　　如何关注对架构重要的内容，安全地把其他方面的设计工作交给设计师，而不会遗漏如性能、弹性和位置等问题。
　　作为架构师，哪些重要的活动是你最需要执行的，例如识别并引入利益相关者、使用场景、创建模型以及编写架构文档并加以验证。
　　贯穿全书，我们首先关注的是大规模信息系统（即用来自动化大型组织的业务操作的计算机系统）的开发。然而，我们也试图以一种特别的方式来展现内容，这种方式不依赖你正在设计的信息系统的类型、开发者将要使用的技术以及项目所遵循的软件开发生命周期。我们标准化了一些事情，例如在大多数图表中使用了统一建模语言（Unified Modeling Language, UML），但是我们只做了这么多，因为UML 是最广为理解的建模语言。想要理解这本书，你不需要是一位UML 专家。
　　我们并不打算让本书成为创建你的信息系统架构的确切指导—这样一本书可能永远都不可能完成，并且需要大量跨广泛技术领域专家的合作。我们也不想编写一本规范方法的书。尽管我们展示了说明如何产出可交付物的一些活动图，但是设计这些活动图是为了与当前使用中的多种软件开发方法相兼容。
　　我们期望达到的目的是，创建一种可实践的、面向实践者的指导，说明如何为信息系统设计出成功的架构，以及如何保证它们可以成功实现。这是我们在开始从事软件架构师工作时想要看到的那种书，也是我们现在期望参考的书。
　　你可以访问我们的网站：www.viewpoints-and-perspectives.info，找到更多有用的软件架构资源，并和我们联系，提供对本书内容的反馈。我们非常期待能够听到你的声音。
致谢
　　本书的出版得到了很多人的建议、帮助和支持，否则这本书永远都不会问世。
　　我们非常感谢多位审校者，他们在我们创作本书的不同阶段对文字给出了意见，包括Gary Birch 、Chris Britton 、Kelley Butler 、Sholom Cohen 、Dan Haywood 、Sallie Henry 、Andy Longshaw 、Robert Nord 、Dan Paulish 、Martyn Thomas 和Hans van Vliet 。
　　我们还要感谢Addison-Wesley 的团队成员，正是他们的工作让这本书成为现实，包括Kim Boedigheimer 、John Fuller 、Peter Gordon 、Chrysta Meadowbrooke 、Simon Plumtree 和Elizabeth Ryan 。
　　还有很多人为我们提供了建议、鼓励和启发，包括Felix Bachmann 、Dave Borthwick 、David Emery 、Wolfgang Emmerich 、Rich Hilliard 、Philippe Kruchten 、Roland Leibundgut 、Mike Mackay 、Dave Maher 、Mark Maier 、Lucia Rapanotti 和Gaynor Redvers-Mutton 。
　　我们还要感谢我们的家人，他们始终为我们提供持续的爱、鼓励和支持。

计算机\软件工程

本书的核心内容是围绕利益相关者、视点和视角这三个概念展开。利益相关者是我们为之创建系统的人。架构师的重要工作就是要知道如何与利益相关者协作，从而能满足他们复杂、多变甚至经常冲突的需求。视点（和视图）是确定架构定义过程和架构描述结构的方法，它基于分离关注点的原则。视点包含了已经过验证的架构知识，以引导架构的创建过程，本书以一系列特定视图的形式来描述它（每种视图都是在特定的视点下应用指引的结果）。视角是本书中引入的一种概念，它是视点的有效补充。视角包含已经经过验证的架构知识，会分离关注点，关注跨结构的质量属性而不是架构结构，从而帮助架构师确定架构定义过程的结构。
本书主要内容：
 详细阐释利益相关者、架构描述、视点、视图和视角等基本概念，并描述软件架构师的角色。
 深入分析架构师所要从事的重要活动，如商量确定项目的范围、识别并管理利益相关者、使用场景和模式、创建模型以及为架构创建文档并对其加以验证等。
 详细解释了在创建架构描述时最重要的七种视点：情境、功能、信息、并发、开发、部署和运维视点。
 综合介绍了对信息系统最重要的视角，包括安全性、性能和可伸缩性、可用性和适应性、演进、位置、开发资源、国际化等。
 如何应对用户和其他利益相关者在功能、容量、推向市场的时间以及灵活性方面提出了苛求要求。
 漫长的系统开发时间导致范围持续改变，如何应对系统架构和设计的经常变更。

（英）Nick Rozanski　 Eoin Woods 著：暂无简介

侯伯薇　译：暂无简介

作为一名程序员，对未来的职业规划会有很多种。有人想要走管理路线，基本目标是成为项目主管或者项目经理；有人对数据库感兴趣，期望成为DBA；有人对测试感兴趣，期望成为测试方面的专家或者质量保证方面的高手；还有很多人希望做架构师，能够从总体上把握一个系统或者一个组织中的所有系统。
　　和其他角色相比，在一个系统的设计和开发过程中，架构师的地位显得尤为重要，颇有“运筹帷幄之中，决胜于千里之外”的架势。但是，很多时候，在很多组织中，架构师只不过是一个职位的概念，很多人即便在拥有这个头衔之后，还是会有很多的疑问亟待解答，比如：
　　架构师需要哪些能力？
　　架构师需要从事哪些工作？
　　想要设计出良好的架构，需要考虑哪些问题？
　　如何与系统的各种利益相关者相互协调？他们的关注点一般又会有哪些？
　　如何编写出能够让相关人员都很好了解的架构文档？
　　如何评估设计出的架构？
　　在解决某些特定系统问题时，应该采用何种合适的方法？
　　……
　　很少有一本书能够系统地回答这么多问题，能够为迷茫的架构师做出有效的指导。我自己也是一样，作为一名程序员，对架构方面还是如履薄冰，了解了一些皮毛，绝不敢以架构师来自居。
　　直到偶然与这样的一本书相遇，我才发现，其实想要成为架构师，或者在成为架构师之后，想要更好地完成相应的工作，这本书都能够提供很好的指导和帮助。其中提出的各种视图、视点和视角，可以帮助我们更好地了解架构的诸多方面，从而在设计架构的时候，能够根据最重要的利益相关者的关注点，更好地进行平衡。
　　也正因为如此，我才争取到这样的机会，把这么好的一本书翻译成中文，呈献给国内的程序员朋友们，希望他们能够通过阅读这本书，更好地了解架构设计和架构师这种职业，也更好地为他们解决架构方面的问题。
　　不得不说，翻译这样一本大部头的确是很辛苦的事情，这也是我所翻译的最厚的一本书，所以首先要感谢我的家人对我的理解和支持，让我抽出晚上和周末的时间来从事该书的翻译工作。还要感谢关敏老师，容忍我一再延期交稿。还要感谢张勇等人的参与，正是大家的帮助，才让我最终完成了这本书的翻译。
　　愿这本书能够帮助更多有志成为架构师或者已经是架构师的朋友们！

译者序
前言
第1版前言
第1章　简介1
1.1　利益相关者、视点和视角1
1.2　本书结构4
1.3　谁应该阅读本书5
1.4　本书约定5
第一部分　架构的基本原则
第2章　软件架构概念8
2.1　软件架构8
2.1.1　系统元素和关系8
2.1.2　基本系统属性9
2.1.3　设计和发展的原则10
2.1.4　系统属性和内部组织形式10
2.1.5　软件架构的重要性13
2.2　架构元素13
2.3　利益相关者14
2.3.1　个人、团队或组织14
2.3.2　兴趣和关注点15
2.3.3　利益相关者的重要性16
2.4　架构描述16
2.5　核心概念之间的关系17
2.6　小结18
2.7　延伸阅读19
第3章　视点和视图20
3.1　架构视图22
3.2　视点23
3.3　核心概念之间的关系24
3.4　使用视点和视图的好处24
3.5　视点缺陷25
3.6　视点目录25
3.7　小结27
3.8　延伸阅读28
第4章　架构视角29
4.1　质量属性29
4.2　架构视角30
4.3　向视图应用视角33
4.4　应用视角的结果34
4.4.1　深入的观点34
4.4.2　提升35
4.4.3　精品内容35
4.5　核心概念之间的关系35
4.6　使用视角的好处36
4.7　视角的缺陷37
4.8　视角与视点对比37
4.9　视角种类38
4.10　小结39
4.11　延伸阅读39
第5章　软件架构师的角色41
5.1　架构定义过程41
5.1.1　架构定义不仅是设计42
5.1.2　需求分析和架构定义之间的区别43
5.1.3　架构定义和设计之间的区别43
5.2　架构师的角色44
5.3　核心概念之间的相互关系46
5.4　架构专门化47
5.5　组织情境47
5.5.1　业务分析师47
5.5.2　项目经理47
5.5.3　设计主管48
5.5.4　技术专家49
5.5.5　开发者49
5.6　架构师的技能49
5.7　架构师的责任50
5.8　小结51
5.9　延伸阅读51
第二部分　软件架构过程
第6章　软件架构过程简介54
第7章　架构定义过程55
7.1　指导原则55
7.2　过程产出物56
7.3　过程情境56
7.4　支持活动57
7.5　架构定义活动60
7.6　过程完成标准62
7.7　软件开发生命周期中的架构定义64
7.7.1　瀑布式方法64
7.7.2　迭代方法65
7.7.3　敏捷方法65
7.8　小结66
7.9　延伸阅读67
第8章　关注点、原则和决定68
8.1　专注于问题的关注点70
8.1.1　业务策略70
8.1.2　业务目标和驱动力70
8.1.3　系统范围和需求71
8.1.4　业务标准和政策72
8.2　专注于解决方案的关注点72
8.2.1　IT策略72
8.2.2　技术目标和驱动力72
8.2.3　技术标准和政策73
8.3　其他现实世界中的约束73
8.4　什么决定了好的关注点75
8.5　架构原则75
8.5.1　什么造就了好的原则78
8.5.2　定义自己的原则78
8.6　架构决定79
8.7　使用原则关联关注点和决定81
8.8　检查列表82
8.9　小结83
8.10　延伸阅读83
第9章　确定并引入利益相关者84
9.1　利益相关者的选择84
9.2　利益相关者的类别85
9.2.1　出资方86
9.2.2　评估者86
9.2.3　沟通者86
9.2.4　开发人员87
9.2.5　维护人员87
9.2.6　生产工程师87
9.2.7　供应商87
9.2.8　支持人员87
9.2.9　系统管理员88
9.2.10　测试人员88
9.2.11　用户88
9.3　示例88
9.3.1　非专门设计的部署项目88
9.3.2　软件产品开发项目89
9.3.3　合作开发89
9.4　代理利益相关者90
9.5　利益相关者组90
9.6　利益相关者的责任90
9.7　检查列表91
9.8　小结91
9.9　延伸阅读92
第10章　识别并使用场景93
10.1　场景类型93
10.2　使用场景94
10.3　识别场景并排定优先级95
10.4　捕获场景96
10.5　什么造就了好场景98
10.6　应用场景98
10.6.1　纸质模型98
10.6.2　走查99
10.6.3　模拟100
10.6.4　原型实现的测试100
10.6.5　完整规模真实测试100
10.7　有效使用场景100
10.7.1　识别一系列重点场景101
10.7.2　使用清晰的场景101
10.7.3　尽早使用场景101
10.7.4　包含对系统质量场景的使用101
10.7.5　包含对故障场景的使用101
10.7.6　让利益相关者紧密参与101
10.8　检查列表102
10.9　小结102
10.10　延伸阅读103
第11章　使用样式和模式104
11.1　设计模式介绍104
11.2　样式、模式和惯用法105
11.2.1　架构样式106
11.2.2　软件设计模式106
11.2.3　语言惯用法106
11.2.4　使用样式、模式和惯用法107
11.3　模式和架构策略107
11.4　架构样式的例子108
11.5　使用架构样式的好处110
11.6　样式和架构描述111
11.7　应用设计模式和语言惯用法111
11.8　检查列表113
11.9　小结113
11.10　延伸阅读113
第12章　创建架构模型115
12.1　模型为什么重要115
12.2　模型的类型117
12.2.1　定性模型117
12.2.2　定量模型118
12.2.3　示意图119
12.3　建模语言119
12.3.1　架构描述语言119
12.3.2　统一建模语言120
12.3.3　可执行的领域专用语言121
12.3.4　其他建模语言121
12.4　创建有效模型的准则121
12.4.1　有目的地建模121
12.4.2　应对受众122
12.4.3　仔细、准确地抽象122
12.4.4　根据风险确定工作重点123
12.4.5　选择描述性的名称123
12.4.6　定义你的术语123
12.4.7　以简单为目标124
12.4.8　使用已定义的标记法124
12.4.9　了解暗示的语义124
12.4.10　验证模型125
12.4.11　保持模型的活力125
12.5　和敏捷团队一起建模125
12.6　检查列表126
12.7　小结127
12.8　延伸阅读127
第13章　创建架构描述128
13.1　有效架构描述的属性129
13.1.1　正确129
13.1.2　充分129
13.1.3　及时130
13.1.4　简洁131
13.1.5　清晰131
13.1.6　最新132
13.1.7　精确133
13.2　词汇表134
13.3　ISO标准134
13.4　架构描述的内容135
13.4.1　文档控制135
13.4.2　内容表135
13.4.3　介绍和管理纲要135
13.4.4　利益相关者136
13.4.5　通用架构原则136
13.4.6　架构设计决定136
13.4.7　视点136
13.4.8　视图136
13.4.9　质量属性摘要137
13.4.10　重要的方案137
13.4.11　亟待解决的问题137
13.4.12　附录138
13.5　展现架构描述138
13.6　检查列表139
13.7　小结140
13.8　延伸阅读140
第14章　评估架构141
14.1　为什么要评估架构141
14.2　评估技术142
14.2.1　演讲142
14.2.2　正式评审和结构化的走查143
14.2.3　通过使用场景来评估144
14.2.4　原型和概念验证系统145
14.2.5　骨架系统146
14.3　基于场景的评估方法146
14.3.1　以架构为中心的活动147
14.3.2　以利益相关者为中心的活动149
14.4　在软件生命周期内评估150
14.5　验证现存系统的架构151
14.6　记录评估结果153
14.7　选择评估方法154
14.8　检查列表154
14.9　小结155
14.10　延伸阅读155
第三部分　视点类型
第15章　视点类型简介158
第16章　情境视点160
16.1 关注点161
16.1.1 系统范围和责任161
16.1.2 外部实体和服务以及所用数据的标识161
16.1.3 外部实体的本质和特征162
16.1.4 外部接口的标识和职责162
16.1.5 外部接口的本质和特征163
16.1.6 其他外部依赖关系163
16.1.7 对系统环境的影响164
16.1.8 总体完成度、一致性和连贯性164
16.1.9 利益相关者的关注点165
16.2 模型165
16.2.1 情境模型165
16.2.2 交互场景169
16.3 问题和缺陷169
16.3.1 遗漏或者错误的外部实体169
16.3.2 遗漏隐藏的依赖关系169
16.3.3 松散或不精确的接口描述170
16.3.4 详细程度不合适170
16.3.5 范围蔓延170
16.3.6 隐藏或假设的情境和范围171
16.3.7 过于复杂的交互171
16.3.8 过度使用术语171
16.4 检查列表172
16.5 延伸阅读172
第17章　功能视点173
17.1 关注点173
17.1.1 功能能力173
17.1.2 外部接口174
17.1.3 内部结构174
17.1.4 功能设计哲学174
17.1.5 利益相关者的关注点175
17.2 模型176
17.3 问题和缺陷184
17.3.1 设计很差的接口184
17.3.2 难以理解的职责184
17.3.3 基础架构作为功能性元素184
17.3.4 过载的视图185
17.3.5 没有元素定义的图186
17.3.6 难以调节多位利益相关者的需求186
17.3.7 错误的详细程度187
17.3.8 “神元素”187
17.3.9 过多依赖关系188
17.4 检查列表188
17.5 延伸阅读188
第18章　信息视点190
18.1 关注点191
18.1.1 信息结构和内容191
18.1.2 信息目的和用途191
18.1.3 信息所有权192
18.1.4 企业拥有的信息193
18.1.5 标识符和映射关系194
18.1.6 信息语义的易变性195
18.1.7 信息存储模型196
18.1.8 信息流197
18.1.9 信息一致性198
18.1.10 信息质量199
18.1.11 及时性、延迟和寿命200
18.1.12 归档和保留信息201
18.1.13 利益相关者的关注点201
18.2 模型202
18.2.1 静态信息结构模型202
18.2.2 信息流模型204
18.2.3 信息生命周期模型206
18.2.4 其他类型的信息模型207
18.3 问题和陷阱209
18.3.1 数据展现不兼容209
18.3.2 不可避免的多个更新器210
18.3.3 键值匹配缺陷211
18.3.4 接口复杂211
18.3.5 过载的中心数据库212
18.3.6 不一致的分布式数据库213
18.3.7 信息质量很差213
18.3.8 信息延迟过大213
18.3.9 容量不足214
18.4 检查列表214
18.5 延伸阅读215
第19章　并发视点216
19.1 关注点217
19.1.1 任务结构217
19.1.2 功能元素与任务的映射关系218
19.1.3 进程间通信218
19.1.4 状态管理218
19.1.5 同步和整合218
19.1.6 支持可伸缩性219
19.1.7 启动和关闭219
19.1.8 任务故障219
19.1.9 重入219
19.1.10 利益相关者的关注点220
19.2 模型220
19.2.1 系统级别的并发模型220
19.2.2 状态模型225
19.3 问题和缺陷228
19.3.1 对错误的并发建模228
19.3.2 错误地对并发建模228
19.3.3 过度复杂229
19.3.4 资源竞争229
19.3.5 死锁230
19.3.6 竞争条件230
19.4 检查列表230
19.5 延伸阅读231