微软新技术

一、架构分析架构分析是在功能性需求过程中，有关识别非功能性需求的活动，事实上非功能需求就是质量需求，这些信息对于架构设计来说，是最值得关注的。1，架构分析需要解决的问题下面说明在架构级别上，需要解决的诸多问题的一些示例：可靠性和容错性需求是如何影响设计的？购买的子组件的许可成本将如何影响收益？分布式服务如何影响有关软件质量需求和功能需求的？适应性和可配置性是如何影响设计的？2．架构分析的一般步骤架

1、意图软件复用的关键是寻找相似性，在很多情况下，相似性表现为业务流程相似，但是业务单元具有特殊性。如果是这种情况，可以定义一个操作中的业务流程骨架，而将一些业务单元的实现延伸到子类中去，使得子类可以不改变一个业务流程的的结构，即可重新定义该业务流程的某些特定业务单元。这里需要复用的是业务流程的结构，也就是操作步骤，而步骤的实现（或者是业务单元的实现）可以在子类中完成。2、使用场合1）一次性实现一

一、组织产品线的需求许多产业构造了一系列在功能上相近的产品集，但每种产品又包含了某些独特的特性，被称之为产品线。假定，正在构建一套软件系统，每个产品都有共享的功能，在使用过程中需要共享数据，或者与其它部分进行通讯。在这种情况下，可以用如下方法组织需求：开发产品系列的前景文档，描述产品共同的工作方式以及共享的特性。为了更好的理解共享用法的模型，也应该设计一套用例，先是用户如何与共同运行的不同应用自建

在系统设计进行模块切分的时候，需要关注以下几个问题。1，系统的骨架化对于一个庞大的系统，如果设计规格不加以控制，则会给将来的集成和维护带来极大的困难。但在这个例子中，仅仅使用了 6 个模块类型（构件、子系统控制器、时间同步器、周期时序器、事件处理器以及代理），就可以对这么大的系统进行完整的描述。这就使得架构很容易创建、理解、集成、发展和修改。更重要的是，如果采用一组标准模式，我们就可以创建一个骨架

后期绑定和允许非开发人员进行修改，可以使系统的可维护性大大提升，推迟绑定时间还能够使最终用户或者系统管理员进行设置，或者提供影响行为的输入。后期绑定需要系统的设计上做好准备，解决方案包括：运行时注册：即支持即插即用操作。配置文件：目的是启动时设置参数。多态：允许方法调用的后期绑定。构件更换：允许载入时绑定。遵守已定义的协议：允许独立进程的运行时绑定。

高可靠性的系统往往伴随着系统冗余，必然带来了造价提高和系统复杂性提高，但在航空设备、航空管制或者战场指挥这样要求高的但数据相对比较简单的系统，使用恰当的系统冗余是合适的，但对于大量的长时间数据处理这样的问题，就需要作一些限制。1，表决对于复杂的数据处理计算，例如快速傅里叶变换或者卷积、相关函数的计算、航路计算、及威胁计算以及应对策略计算等等，如果处理上出现了问题（错误），往往会带来灾难性的后果，在

事实上无论代码写的多么优秀，各种问题考虑得多么全面，但系统发生故障的可能性还是存在的，作为模块或者设备的冗余配置，恰当的健康监测是判断模块是否工作正常的基础架构。1，命令/响应（ping/echo）：一个构件发出一个命令，并希望预定时间内收到一个审查构件的响应。和心跳方式相比，它的特点是发出检测命令是由专门的构件完成的。这个解决方案一般用在处理共同完成某项任务的一组构件内。一般情况下，“探测器”可

在上一章我们已经构建了软件架构设计总体过程，为了强调针对质量属性的架构设计策略，我们还应该在每个节点加入如下子过程。一、以核心功能为主进行架构设计对于任何一个基础架构，我们都需要回答如下一些问题：这个系统有哪些核心功能？这些核心功能分布在哪些系统级的框架之内？是什么样的质量要求才使我们这样分配功能分布？这些系统功能互相交互的时候考虑了哪些质量要求？事实上，我们总是倾向于使用一些我们熟悉的架构，但是

综上所述，我们就可以比较条理化的建立软件架构设计的流程了。典型软件架构设计的流程如下图所示。一、业务架构概念在构建软件架构之前，架构师需要仔细研究如下几个问题：系统是为什么目的而构建的？系统投运后服务于哪些利益相关者的利益？什么角色在什么时候操作或者维护系统？业务系统实现方法是怎样的？整个业务系统是如何依靠系统而运转的？为了回答这些问题，需要仔细阅读需求分析文档中的业务模型建立、问题域及其解决构思

1、意图简单工厂的作用是实例化对象，而不需要客户了解这个对象属于哪个具体的子类。在 GoF 的设计模式中并没有简单工厂，而是把它作为工厂方法的一个特例加以解释，可以这样来理解，简单工厂是参数化的工厂方法，由于它可以处理粒度比较大的问题，所以还是单独列出来比较有利。2、使用场合和效果简单工厂实例化的类具有相同的接口，类的个数有限而且基本上不需要扩展的时候，可以使用简单工厂。使用简单工厂的优点是用户可

在系统之间集成的时候，最常见的问题是接口不一致，很多能满足功能的软件模块，由于接口不同，而导致无法使用。在这种情况下可以使用适配器模式。1，意图适配器模式的含义在于，把一个类的接口转换为另一个接口，使原本不兼容而不能一起工作的类能够一起工作。2，结构适配器有类适配器和对象适配器两种类型，二者的意图相同，只是实现的方法和适用的情况不同。类适配器采用继承的方法来实现，而对象适配器采用组合的方法来实现。

模板方法是利用继承来完成切割，当对耦合性要求比较高，无法使用继承的时候，可以横向切割，也就是使用桥接模式。我们还是通过上面的关于支付的简单例子可以说明它的原理。显然，它具备和模版方法相类似的能力，但是不采用继承。public class Payment{private double amount;public double getAmount(){return amount;}public voi

在软件组织中，架构师的作用是举足轻重的，当企业把一个方向的生命线托付给你的时候，责任也是重大的，因此架构师必须十分谨慎和细致，最后我给你提如下一些建议：1，架构师的知识结构1）首先必须是一个好的程序员，技术上要强2）知识结构：对象的观点，UML，RUP，设计模式关键不是懂得了原理，而是灵活融合的应用3）系统的观念：分析能力，把握抽象的能力4）沟通能力：与客户沟通能力，与项目其它成员的沟通能力5）知

1，防止编写成智力拼图许多文档写成了类似智力拼图的玩具，很多不同的相关定义与内容散落在文档的不同地方。读者不会预料到在文档的其它地方会不会还有相关说明。为了阅读这样的文档，人们需要把一切都记在脑子里，智力拼图是把散落在各处的小块拼在一起，但人的大脑很难做到这一点。要记住，任何大的文档都不同程度的具有智力拼图性质，但我们的任务是减少智力拼图块的数量。不要让阅读者在一个地方看到的信息块做出了推论，而在

1，进程视图事实上，在分布式计算平台上，是把系统构建成一组通信进程，这个问题的研究需要使用进程视图。进程视图的关注点是性能，我们还需要关注诸如：死锁、通信协议、容错性（防止通信线路出现问题）、网络管理及防阻塞的考虑等，我们必须制定一些约定，这些约定不但是分布式系统而且对于构件的开发都是必要的。比如我们提出的约定如下：构件之间的通信是通过强类型消息传递的。抽象数据类型和实施操纵的程序是由传递消息的构

当算法牵涉到一种链型运算，而且不希望处理过程中有过多的循环和条件选择语句，并且希望比较容易的扩充文法，可以采用职责链模式。1、意图使多个对象都有机会处理请求，避免请求的发送者和接收者之间的耦合关系，可以把这些对象链成一个链，并且沿着这个链来传递请求，直到处理完为止。当处理方式需要动态宽展的时候，职责链是一个很好的方式。2、使用场合以下情况可以使用职责链模式：1）有多个对象处理请求，到底怎么处理在运

组合可以说是非常常见的一种结构，我们经常会遇到一些装配关系，从数据结构上来说，这些关系往往表达为一种树状结构，这就用到了组合模式。它的意图是，把对象组合成树形结构来来表示“部分-整体”关系，使得用户对单个对象和组合对象的使用具有一致性。1、结构组合模式的结构可以有多种形式，一个最典型的结构如下。2、效果使用组合模式有以下优点：1）组合对象可以由基本对象和其它组合对象构成，这样，采用有限的基本对象就

一、应用策略模式提升层的通用性1、意图将算法封装，使系统可以更换或扩展算法，策略模式的关键是所有子类的目标一致。2、结构策略模式的结构如下。利用反射实现通用框架目标：构造一个 Bean 容器框架，可以动态装入和构造对象，装入类可以使用配置文件，这里利用了反射技术。问题：如何动态构造对象，集中管理对象。解决方案：策略模式，XML 文档读入，反射的应用。我们现在要处理的架构如下：Bean.xml 文档

当需要上层对底层的操作的时候，可以使用观察者模式实现向上协作。也就是上层响应底层的事件，但这个事件的执行代码由上层提供。1、意图：定义对象一对多的依赖关系，当一个对象发生变化的时候，所有依赖它的对象都得到通知并且被自动更新。2、结构传统的观察者模式结构如下。3，举例：// PaymentEvent.java 传入数据的类import java.util.*;public class Payment

有的时候，希望实现一个基本的核心代码快，由外围代码实现专用性能的包装，最简单的方法，是使用超类，但是超类使用了继承而提升了耦合性。在这样的情况下，也可以使用装饰器模式，这是用组合取代继承的一个很好的方式。1、意图事实上，上面所要解决的意图可以归结为“在不改变对象的前提下，动态增加它的功能”，也就是说，我们不希望改变原有的类，或者采用创建子类的方式来增加功能，在这种情况下，可以采用装饰模式。2、结构

事实上，经过从上面三个方面审视架构，我们已经建立了一个完整的而且比较良好的架构。但我们还需要从第四个方面在更高的层次审视我们的架构，需要考虑的又一个问题就是软件的复用。复用可以大大降低后期成本，提高整个软件系统的可升级性与可维护性。我们可以考虑哪些结构可以使用已经存在的可复用结构和产品，某些结构可以利用 GoF 的设计模式设计可复用的构件已备后期使用。还需要根据需求分析得出的易变点仔细设计产品结构

下面我们再从第三个方面审视架构设计，关注点在模块的缠绕和分散。所谓缠绕，指的是一个模块是不是包含了多个模块不同的实现。所谓分散，一个模块的实现分散在多个不同的模块中。解决这些缠绕和分散问题，需要使用分层结构来解决。1，层模式的问题与机会在模块分割以后，就会发现有些功能块或者某些功能是共享的或者缠绕的，我们需要把这些模块或者功能提取出来，分成若干层次，这就是层模式。层模式是构造弹性架构的基础，好的架

很常见的情况是，开发人员对于书写文档有种种非议，但是一个正规的软件项目，即使带来了表面上的工作效率降低，也必须花费精力书写文档，为什么呢？任何时候，只要是两个人以上参与项目，都离不开口头交流，但是每个人在传递这个口头交流的内容的时候，都会把原来的意思歪曲一点点，人类的记忆能力就是这样的。一个软件项目永远离不开口头交流，我们不必要去停止这种交流方式，但是当开发人员比较多的时候，就可能带来很多麻烦，某

1，识别概念类我们的目标是在相关分析中创建有意义的概念类，比如说创建“处理销售”用例中的相关概念类。一个方法是通过建立一个候选的概念类的列表，来开始建立模型。但是，更多的是使用名词短语分析找出概念类的方法，然后把它们作为候选的概念类或者属性。使用这种方法必须十分小心，从名词机械的映射肯定是不行的，而且自然语言中的单词本来就是模棱两可的。不过，这仍然是灵感的另一种来源。一般来说，用大量细粒度的概念类

1，意图外观模式定义了一个把子系统的一组接口集成在一起的高层接口，以提供一个一致的处理方式，其它系统可以方便的调用子系统中的功能，而忽略子系统内部发生的变化。2，使用场合1）为一个比较复杂的子系统，提供一个简单的接口。2）把客户程序和子系统的实现部分分离，提高子系统的独立性和可移植性。3）简化子系统的依赖关系3，结构下图是外观模式的结构，由于该模式的引入，所以外界访问通过这个统一的接口进行，系统的

虽然经过了系统架构和设计的重构，系统的结构已经得到了很大程度的改善。但是，最终我们还需要进行一个更低层面但绝对重要的重构工作，这就是系统代码重构。我们在浏览一个系统代码后，通过经验及直觉就能发现的一些“坏味”，例如：代码的方法过大。系统中重复的代码过多。类的子类中存在大量相同方法。代码中过多的注释。参数列表太长。那么一般我们应该选择怎样的时机去解决这些问题呢？通常，有如下四种时刻最合适进行代码重构

当架构设计基本完成而且已经编制了文档以后，需要做的一件最重要的工作就是架构决策，我们必须知道我们构建的架构对系统重要的质量属性产生的影响，以及对架构方案的取舍做出定。评估大型系统的架构是一项复杂任务，它的困难在于：1，大型系统由于结构庞大，要在有限的时间里理解这个构架非常困难。2，计算机系统的目的是支持商业目标，评估的时候需要把这些目标和技术支持联系起来。3，大型系统通常都有多个涉众，需要在有限的

下面，我们针对系统架构和设计中的“坏味”（注：“坏味”是 Martin Fowler 的一个著名概念），分别总结出的一些“重构模式”，看看这些模式是如何把这些设计“坏味”去掉的。1，实体重新命名问题：进行架构和设计时所界定出来的系统组成元素（子系统、构件、模块等）名称使用混乱，不能很好地表达该系统元素的用途或语义，使系统结构难以理解。事实上，一个架构发展的历程中，命名的逐渐混乱，是促使架构老化的重

假定某一个大型系统的设计提出了极高的可靠性要求，因此在架构设计的时候，就需要针对可靠性问题讨论具体的解决方案。一、进程间提升可靠性的方法大型系统一般是按照多处理器环境设计的，逻辑上组成处理器组，处理器组的目的是运行一个或者多个应用程序的副本，这一思想对于支持容错性和可靠性是非常重要的。在多个运行副本中，一个为主，称为主地址空间（PAS），其它的为辅，称为备用地址空间（SAS）。一个主地址空间，和相

软件的质量由一系列质量要素组成，每一个质量要素又由一些衡量标准组成，每个衡量标准又由一些量度标准加以定量刻画。质量度量贯穿于软件工程的全过程以及软件交付之后，在软件交付之前的度量（内部属性）主要包括程序复杂性、模块的有效性和总的程序规模。在软件交付之后的度量（外部属性）则主要包括残存的缺陷数和系统的可维护性方面。ISO 9126 称为“软件产品评价：质量特性及使用指南”。在这个标准中，把软件质量定

软件架构（software archiecture）也称之为软件体系结构，它是一组有关如下要素的重要决策：软件系统的组织，构成系统的结构化元素，接口和它们相互协作的行为的选择，结构化元素和行为元素组合成粒度更大的子系统的方式的选择，以及指导这一组织（元素及其接口、协作和组合方式）的架构风格的选择。软件架构是对系统整体结构设计的刻划，一直以来，对于架构的理解有两个基本概念，一个称之为组成，另一个称之

经过 20 年的应用，人们发现经典项目过程存在很多问题，这迫使人们研究它存在的问题，以期找到解决方案。经典项目管理最困难的问题是项目难以规划，做出来的计划往往会出错。于是开发小组往往走向两个极端：要么是不做规划，这样的小组根本无法回答“你们什么时候能完成？”这样的问题。要么是在计划中投入大量的精力，直到自己确信计划是正确的，但这种“正确”往往是自欺其人的，这种计划可能更全面，但不意味着更准确或更有

1，介绍提供整个前景文档的概述。1.1 前景文档的目的文档的目的是收集、分析、定义高层用户需要和产品特性。1.2 产品综述阐述该应用系统的目的、版本以及要交付的新特性。1.3 参考这一部分应该列出在前景文档中引用的其它文档的全部清单。2，用户描述简要描述系统用户的观点。2.1 用户/市场统计总结决定产品动机的主要市场统计。2.2 用户剖析简要描述系统预期用户。2.3 用户环境描述在使用中包括应用程

对初步的架构轮廓作第二个方面的审视，是考虑模块化的设计问题。也就是从架构的组成单元来说，定义清楚子系统以后，下一步就是定义模块。1，模块化设计的概念如何合理的进行模块设计呢？这里的关键是要保证模块的独立性。模块：模块是数据说明、可执行语句等程序对象的集合，是单独命名的并且可以通过名字来访问，例如过程、函数、子程序、宏等。模块化：软件被划分成独立命名和可独立访问的被称作模块的构件，每个模块完成一个子

通过从系统工程的角度分析与组织需求信息，我们已经由需求分析得到了一个框架性的架构雏形，但那只是架构的一个大概形状，在具体进行架构设计之前，架构师必须进行架构的进一步分析和设计，从不同的角度审视架构设计，多角度、多层次的修改架构设计方案，从而得到一个合理的架构基线产品。对初步的架构轮廓作第一个方面的审视，是从需求分析中仔细思考质量需求对架构的要求，换句话说就是获取架构因素。架构分析的本质，是识别可能

对于基础架构，我还有几个观点要说明。在单一团队工作结束的时候，将建立系统早期的、关键性的第一个版本，这是一个可执行的版本，我们称之为架构基线版本。在建立好架构基线之前可能要花费几个迭代周期，但完成以后，将会证实你的假设、以及系统开发方法，也就可以降低风险，基于这个架构，其它部分的开发速度将会大大加快。一个好的架构要确保不同类型的关注点互相独立，当其中一个发生改变的时候，不至于影响系统的其它部分。架

策略对实践提供总体上的指导，对于有难度的工程（比如软件工程），或者有竞争性目标（软件中时间、质量、范围、成本之间存在竞争）而言，策略往往是制胜的关键。一定要注意，策略来自于问题，没有问题的策略是无目之本。下面，我们针对成功架构设计的四个要素，以此衍生出四个问题，作为讨论相应的策略的基础。这样的思考过程也可以成为我们研究其它架构问题的思考范例。我们先把关键点归纳成下面的表。编号 关键点 问题 危害

软件架构设计是以“需求规格说明书”为最主要的设计依据，首先勾勒出概念性的架构，再结合具体的技术平台制定实际架构方案的。在考虑架构设计的时候，必须注意如下关键要素。1）是否遗漏了至关重要的非功能性需求非功能需求是最重要的架构决定因素之一，所谓非功能需求主要包含两个部分：质量属性和约束条件。质量属性是软件系统整体的质量品质，所谓整体品质，就是它往往和大多数功能都有关系。比如易用性、可扩展、安全性、可靠

成功的软件架构设计是高质量的，并且所花费的时间、技术决策等方面都能满足具体开发方法的要求，具体应该有如下品质：良好的模块化：每个模块职责明确，模块之间松耦合，模块内布高内聚，并且合理的实现了信息隐蔽。适应功能需求变化，适应技术变化：典型情况是，应该保持具体应用的相关模块和领域通用模块的分离，技术平台相关模块与具体技术的应用模块相分离，从而达到“隔离变化”的效果。对系统动态运行有良好

为了能够实现架构设计，概要层次的用例可以帮助我们建立业务架构概念，利用概要层次的用例集中精力考虑了系统大的关系，专注于子系统和功能块“黑盒”层面的状态与行为，而有意的忽视了本身细节层面的内容，这在很多情况下是架构设计所需要的。但从另一方面来讲，作为架构层面的需求分析，很多内容又需要从细节层面考虑，特别是各个子系统和功能块之间交互行为的描述应该细致翔实，从这个范围来说，很多架构层面的需求分析又属于用