第一章 程序架构基础

目标

        程序架构基础

        标准关键程序建构术语和原则

        促使现代架构形成的关键因素

 

概要

定义程序架构就是定义结构化的解决方案的过程，这个解决方案可以满足所有的技术和操作的需求，以及最佳化的一般质量特性，如性能，安全和可管理性。

这包括广泛因素的一系列的决策，每个决策都考虑到了对质量，性能，可维护性和程序的成功。下面我们就展开对这一过程的描述，并使用其中包含的信息，你可以构建一个包含所有要点的架构。并可以使这个架构部署在你选择的基础之上，并且符合所有的原始的目标和需求。本章是实践性的程序架构的基础。首先从高层介绍架构和设计，之后详细介绍具体的架构和设计。提示符和以上采用同样方式。最后，本章会给出关键术语和原则。理解这些会帮助你从本指南中获得最大的收益，并成为一个更好的架构师。通过学习本章，你会从整体角度理解结束和架构及设计，主要的你必须考虑的因素和你在设计架构是可以使用的主要方法。

这会帮助你理解一些架构和程序风格，质量特性和交叉相关的概念以及分析和展示架构。

 

什么是软件架构？

软件架构一般被定义为一个系统的机构和各种结构的集合。

一些我们熟知的工业专家在架构相关决策的基础上扩展了这个定义。

Kruchten, Booch, Bittner, 和 Reitman对架构的定义

根据工作的经验Philippe Kruchten, Grady Booch, Kurt Bittner和Rich Reitman继承并提炼了架构的定义。他们的定义是：“软件架构包括了一些列的显著的软件系统组织的决策，包括：

ü  选择结构元素和他们组成系统的接口。

ü  明确这些元素之间的协同行为

ü  把这些结构的和行为的元素组成一个更大的子系统

ü  指导这种组织的架构风格

软件架构同时包括功能性、可用性、可靠性、性能、复用性、广泛性以及经济和技术约束、权衡和美观等相关问题。”

Fowler 给出的架构定义

在《企业应用架构模式》一书中Martin Fowler在解释架构的时候，指出了一些重复发生的主题：

•          从最高层分解系统。

•          决策很难修改。

•          一个系统中存在多个架构。

•          架构会影响一个系统的生命期。

•          最后，架构按照系统的各个总要部分分解。

Bass, Clements, Kazman对架构的定义

在《软件架构实践（第二版）》中Bass, Clements, 和 Kazman这样定义软件架构：

 “一个软件或者是一个计算系统的架构就是这个系统的结构或者结构的集合，包括软件的各种元素，这些元素的外部可见的属性和他们之间的关系。架构主要是关于公共接口的，这些元素的内部细节—需要在内部实现的细节与架构无关。”

 

我们为什么需要架构设计？

想其他的复杂结构一样，软件必须建立在一个稳定的基础之上。没有考虑到关键的用例，没有处理好常见的问题，或者没有对长期的关键决策做好评估，会导致一个应用的失败。先待工具和平台会帮助你简化创建应用的难度，但是他们不会在需求之上建立你的应用程序。不好的架构导致的风险包括不稳定，不支持业务需求，甚至软件部署到工作环境时无法工作。考虑软件架构时，从高层考虑一下问题：

•            软件如何部署到生产环境？

•            用户会如何使用软件？

•            质量需求有哪些，比如安全，性能，并发，国际化以及配置？

 

架构和设计

当前或者在你部署了你的软件后，会影响到你的架构的趋势是什么？Martin Fowler说道：“专家一级的开发人员对于项目有个共同的理解。这个共同的理解叫做‘架构’。这个理解包括如何把系统分块以及这些不同的模块如何通过接口相互作用。这些模块通常又由更小的模块组成，但是架构只包括这些可以呗所有开发人员理解的模块以及他们之间的接口。”。所以结构主要集中在如何分解出模块和他们之间的接口。选择数据机构和算法实现已经不是架构了。不要用硬性快速的法则去区分架构和设计的区别，把他们两者结合起来才更有意义。在某些场合下，决策本质上来说更接近与架构。在其他情况下，决策又更接近于设计，并帮助你实现架构。

 

用户，业务和系统目标

系统架构的建立需要考虑到用户，系统和业务目标。每个领域都需要列出关键场景，重要的质量属性（比如，可维护性），关键客户要求实现的功能。如果可以，开发时，考虑每个领域中的成功的度量标准。

 

图1

在每个领域中都会有权衡，并且平衡点也必须找到。比如，反应时间可能是一个用户体验方面的要求但是系统管理者却不愿意投资到硬件上。而平衡点可能只是满足用户80%反应时间要求。

架构的目标

通过理解用例，软件架构可以建立业务需求和技术需求之间的桥梁，并在软件中实现用例。架构的目的就是为了辨别出对软件的结构有重大影响的需求。好的架构可以有效的降低业务的变化对解决方案的影响。一个好的设计可以非常灵活的适应由于时间引起的硬件和软件技术的变化，以及用户场景和需求的变化。一个架构师必须考虑设计决策，质量属性（比如：性能和安全）固有平衡，用户、系统和业务需求等对整体的影响。

架构应该包括的一下的内容：

•            找出系统的结构但是隐藏实现的细节。

•            实现全部的场景用例。

•            列出所有的利益相关者关注的问题。

•             

实现架构的方法

功能和质量需求全都处理。任意的架构，实现架构的方式，都必须列出全部的关键决策。至少你必须确定你要建立的架构的类型，建立架构的风格并且处理这些问题的交叉部分。通过这个指南，我们会通过基本的架构来列出在你的架构中需要考虑的各个方面。基本架构在下图中。

 

图2

 

此外，对于基本架构来说，你可以用下列的方式来帮助你定义你自己的架构。第一步是你的要建立的应用的类型。接着，你必须理解你的软件如何部署。一旦你明白了你应用的类型以及该软件如何部署，你就可以开始用你认为合适的风格和技术来建立你的软件。最终，你需要把考虑质量属性和交叉点容纳到你的设计中。

 

应用类型

作为设计和组织软件架构过程的一部分，选择正确的应用类型极为关键。这取决于需求和基础结构的限制。本指南包括了一下的应用类型：

l  移动设备的移动应用

l  主要运行在客户机上的富客户端应用

l  部署在Internet上的支持丰富的UI和媒体的RIA应用

 

部署策略

当你设计架构时，你必须考虑到共同的方针和处理过程，以及你要部署你软件的基础。目标环境是灵活的还是不变的，你的软件必须考虑到在目标环境中存在的限制。你的应用程序必须同时考虑到质量属性比如安全和性能以及可维护性。有时你必须因为网络技术和协议做出必要的权衡。尽早在设计阶段分辨出需求和基础结构的限制和需求。这会帮助你选择一个正确的部署技术，帮助你尽早解决软件和基础架构之间的冲突。

 

架构风格

一种架构风格就是一些列的组成该风格的原则。每种风格都定义了一系列的规则，这些规则指明了你可以用于组成系统的组件，在软件组件之间关系，各个组件组织到一起的约束，以及他们组织到一起的方式。架构风格的例子是客户机/服务器，基于组件的，分层架构，消息总线，MVC，三层/N层，面向对象，以及面向服务的架构（SOA）。很多的因素会影响你对架构风格的选择。这些因素包括你所在开发单位的设计和实现的能力，开发人员的经验和能力，以及可以获得的架构约束和部署场景。

 

合适的技术

当为您的软件选择技术的时候，要考虑的关键因素是你所要开发的软件的类型，和软件部署技术以及架构风格。技术的选择也会受到代发单位策略，基础架构限制，技术资源等的影响。你必须比较在你的需求的基础上考虑你选择的技术，并且在做出任何的决定之前考虑其他的因素。

 

质量属性

质量属性可以把你的思考集中在几个设计中必须解决的关键的问题上。在你的需求的基础之上，你可能要考虑在本指南中列出的全部的质量属性，或者这些质量属性的一个子集。比如，每个软件都必须考虑安全和性能，但不是每个设计都需要考虑互操作性或者可升级性。首先理解你的需求和部署场景，这样哪些质量属性对你的设计很重要。记住质量属性会出现冲突。比如，安全性需要对性能和可用性做出权衡。在做安全性方面的设计时，分析并理解关键的权衡，就会避免边缘作用对软件产生显著的影响。在质量属性设计中可以考虑一下的指导：

l  质量是系统级属性，是和功能分离的。

l  从技术的角度讲，质量属性的实现与否或实现如何可以区分一个软件的好坏。

l  有两种质量属性：一种是在运行是度量的，一种只能通过审查来度量。

l  分析质量属性之间的权衡。

当你考虑质量属性时，有几个问题你需要考虑：

什么是你软件要求的关键的质量属性？在设计的过程中找出他们。

什么是你软件要求的关键的质量属性？在设计的过程中找出他们。

客户的接手标准是什么，这表明了你是否符合需求。

 

关注交叉点

交叉点代表了软设计中与某一层无关的关键域。比如，你可能想在展示层和数据访问层缓存数据。你也需要设计一个在每一层都工作的异常处理框架。另外，你还设计每一层都可以使用的日志系统以及设计一个在不同层之间通讯的功能。权限管理也存在于不同的层次之间，所以你必须决定如何在系统中传递一个认证并使持有这个认证的用户可以访问特定的系统资源。一下列表描述了架构中必须考虑的交叉点：

 

身份认证：决定如何验证用户并在不同层之间传递认证的身份。

权限：在每一层和信任授权之间的授权正确。

缓存：确定什么是需要缓存的，缓存位置以改善软件的性能和响应时间。设计缓

存时一定要考虑到网页和网络应用的问题。

通讯：选择和是网络技术，减少网络调用并防止敏感数据在网络中传输。

异常管理：在边界捕获异常。不再终端用户钱显示敏感信息。

规范应用程序和日志：规范全部的业务和系统关键事件，并详细记录日志以便重建事件。不要记录敏感信息。

 

敏捷架构

敏捷架构假设软件的设计会随着时间的改变儿改变，并且你不知道为整个系统设计架构需要知道的所有信息。你的设计，总的来说，会在实施阶段获得了更多的信息后，或是在实际环境中测试过后加以改进。由于在设计的开始阶段无法全面的了解需求，而不断在头脑中改进架构。用敏捷的方法设计架构时，需要考虑一下问题：

在架构中，如果你出错了给整个系统带来最大风险的基本模块有那些。

架构中的那些部分是最容易改变的，或者说那部分的设计退后之后对系统的影响最小？

你的关键假设是什么，如何测试他们？

何种情况会使你重新考虑你的设计？

不要过分设计，不要做无法验证的假设。相反的，保持对未来的变化开放的想法，而不是把自己逼到墙角。有些方面，如果重新设计会给你带来很高成本的话，是你在设计的初期就必须确定好的，尽快确认这些域，并认真分析他们。

敏捷架构设计的关键原则

 

敏捷架构包括一些关键的原则：

建模适应改变：任何地点只要可能，设计你的软件，以使之可以适应新的需求和

挑战。

建模分析、减低风险：给风险建模以理解风险和易出问题的地方。

建模和试图只是沟通和协调的工具：设计原则行业设计变更的沟通是敏捷设计的

关键所在。用户建模和其他的可视化手段可以使得沟通更加有效并可以使得

团队针对设计的变更做出迅速的应对。

 

确认关键建模决策：用本指导的框架来理解工程决策，区分出经常容易出错的地方。最后可以第一时间找出这些关键决策，以使设计更加灵活和更容易适应变化。

 

增量和迭代架构方式

敏捷架构通过增量和迭代的方式达到改进的目的。就是不要在第一次就把搜有的事情都作对。尽可能的设计，之后在需求和假设的基础上验证你的设计。迭代的在你的设计中添加细节，以使你在第一次就在重要问题上做出正确的决策，之后关注细节。一个常犯的错误就是过早的进入到了细节问题，并在错误的假设上做出错误的决策，或者无法评价架构是否有效。保证架构的基本方面是正确的，并测试这个架构，同时考虑一下问题：

•            在这个架构中我做了什么样的假设？

•            这个架构能满足什么样的显式或隐性的需求？

•            这样架构设计方式会有什么样的风险？

•            通过何种方法应对关键的危机？

•            以何种方式改进架构的基本设计或最近一个版本的架构？

基本架构和待测架构

一个基本架构就是对现存系统的描述—也就是你系统当前的结构。如果是一个全新的架构，那么你的基本架构就是这个架构设计的最高层描述，待测架构也将从这里产生。一个待测架构包括应用类型，部署架构，架构风格，技术选择，质量属性和交叉点。

Architectural Spikes

An architectural spike是一个软件的每个小块的端到端的测试。目的就是减低风险并测试潜在路径。只要你评价你的架构，你就会用这些spike来发现不同的场景，但这不会对软件现有的设计产生任何影响。An architectural spike可以得出一个待测架构，这个待测架构可以在基础架构的基础上进行测试。如果一个待测架构是一个改进，那么它就可以作为下一个待测架构的基础架构。这样的迭代和增量方式使你可以在第一时间摆脱较大的风险。用迭代的方式得出架构，并用架构测试证明每个基本架构都是一个改进。考虑下面的问题，以帮助你测试一个新的待测架构：

•            这个架构会导致新的风险吗？

•            这个架构会降低已知的风险吗？

•            这个架构满足其他的新增的需求吗？

•            这个架构支持架构级的用例吗？

•            这个架构列出了质量属性了吗？

•            这个架构列出了增加的交叉点了吗？

 

架构级的用例

架构级用例的符合以下标准：

•            他们对成功和客户对软件部署的接受至关重要。

•            他们可以从多方面考验设计，这对架构的评估至关重要。

当你确定好架构的架构级用例之后，你可以用他们来评估待测框架的成功与否。如果待测框架需要更多的用例，或者更加有效的评估架构，那么这个待测架构是上个基本架构的改进版本了。

分析和评估架构

用架构评价来确定你的基本架构和待测架构的灵活性。架构评价是成功的架构迭代中的关键部分。在架构评价中考虑以下几个技术：

•            架构级用例:用用例来测试设计对你软件的成功非常重要。这也是你设计中的重要一环。

•            基于场景的评估：用场景来分析你的设计。并且要考虑到质量属性。基于场景的评估有：

 

ü  架构权衡分析方法。

ü  软件架构分析方法。

ü  和中间设计审查。

 

展示和沟通架构

把你的架构拿出来沟通在架构审查中非常重要，在架构的实施过程中尤其如此。最后，只要你的沟通质量好，那架构的质量就有了保障。你必须和不同的角色讨论你的架构，包括系统设计者、开发人员、系统管理员等。一个可以清晰展现架构图景的方法是决策图。决策图不是某个专业的东西而是一个可以帮助你和其他人沟通的抽象。

 

架构图景

理解当前让我们做出架构决策，和将来让我们做出改变的关键因素。这些关键因素受客户要求的影响，同时也受到业务要求的影响，比如更快的得到结果，更好的支持工作风格和工作流程的改变，以及更容易修改的设计。考虑一下关键趋势：

•            用户授权：一个支持用户授权的设计是比较灵活的，这样的设计是可配置的，并考虑到了用户使用体验。设计时考虑到用户的个性和可能的选择。允许用户选择软件如何对操作做出回应，而不是培训他们。理解关键的使用场景，并使软件尽量的简单易用，容易找到信息和使用。

•            市场成熟：在现有平台和技术选择的基础上烤炉事成成熟度。在高层建立应用框架才有意义，这样唯一的确定什么在你的软件中是有价值的，而不是建立一些已经存在并可以复用的。评价模式可以提供很多的已经证明了的普遍问题的解决方案。

•            灵活性和适应性：一个灵活的，适应性强的设计重点在与松耦合以支持复用。考虑插件式开发以支持扩展。考虑服务优先的技术比如SOA以支持互操作。

•            未来趋势：当你构建你的软件的时候，理解未来可能在部署后对你的设计产生影响的趋势。比如，考虑富客户端和媒体，符合模块比如混搭应用，增加的网络贷款和可用性，移动终端的增加，硬件性能的持续改进，社区和个人出版的增加，云计算的和远程操作的增加等。

本文转自张昺华-sky博客园博客，原文链接：http://www.cnblogs.com/sunshine-anycall/archive/2009/01/17/1377377.html，如需转载请自行联系原作者