下面基于我实际经历的一个项目，结合对《软件架构设计》一书的理解，谈一下质量属性的设计。

首先介绍一下项目背景，某大型电信解决方案提供商向全球电信运营商提供某软件系统，因不同的运营商需求有差别，需要投入大量的人力物力对某个特定的运营商进行客户化定制，成本较高，为了降低定制成本，该提供商将交付组织切分为负责通用版本的组织A和负责针对特定局点定制的交付组织B，且成立了一个项目专门提升该软件系统的可定制性，以实现这种分级交付，降低定制成本。

项目启动后，负责该项目的架构师凭借丰富的经验马上启动了架构设计，他从业界同类产品了解到，业界为了提升定制能力采用了元数据驱动的架构风格，于是马上开始了元数据驱动框架的设计，设计好之后召集开发人员和管理人员开了个沟通会，会中，该架构师被两个问题难住了：

1）有个定制开发人员问，如果基线版本升级了，能否保证定制版本做的修改能够被直接继承？在这个问题上，大家发生了激烈的争论，架构设计团队认为有些场景可以，有些场景不可以，而定制开发人员的理解跟架构设计团队的理解不一样，最终该问题被搁置下来，后续再论。

2）管理人员问，对定制能力目标，我们怎么测试和验证目标是否达成。这个问题比较毒，一下子把架构设计团队问傻了，没人答得上来，于是被骂了一顿。

问题在哪里？？看了《软件架构设计》的第9章“概念性架构设计”就能找到答案。我认为的问题有：

1）没有从系统各Actor的角度，分析定制用例，导致重要定制场景遗漏，被问起的时候自然就捉襟见肘；

2）没有将定制能力目标分解到定制场景，导致对设计缺乏度量，不知道设计到底能不能满足定制能力目标要求，自然也回答不了“通用版本与定制版本的边界”这类的问题。

要怎么做呢？？看了《软件架构设计》的第9章“概念性架构设计”就能找到答案。我认为，应该遵从下面的步骤，才能确保定制目标的达成：

1）分析定制的Actor，比如定制开发人员，定制运维人员等；

2）针对各Actor，分析其定制用例，如开发人员增加一个业务、修改一个业务流程、增加一个业务实体字段等等；

3）针对每个用例，结合定制能力目标，分析该Actor的工作流程，通过这一步的分析，通用版本的边界（系统用例）能够大致识别出来。

4）再针对关键系统用例，进一步使用分析对象进行鲁棒分析；通过这一步，对元数据驱动框架的能力要求能明确下来；

5）然后在进一步对元数据驱动框架进行细化设计；

通过这样一个系统的方法和流程，我们才能保证做出符合业务目标的可定制性设计。其它类型的质量属性的设计方法和流程也是类似的。

其实那个负责可定制性设计的架构设计团队不管是业务经验还是技术能力，都是比较扎实的，关键是没有掌握一个比较科学的设计方法和流程。因此，广大程序员兄弟们在实践的同时，一定不能忘了提升理论素养，这样才有利于更早的打破天花板，获得更大的成功。

很多人对SOA的理解就是分层、模块化、面向对象。。。这种理解对不对后面再说。先看一些问题：

我今天看了一个开发团队的开发工程包结构，部分类的命名及组织产生了如下印象：

• 每个usecase是一根根烟囱
• 烟囱与烟囱之间连模型都没有共享。其实业务模型是有设计的，主要是实现模型没有保持业务模型的结构特征，全部成了“值对象”，开发人员天天把这些值对象叫做领域对象。
• 有三层，是Struts帮忙定义的，三层分别根据usecase分包

这也是我们宣称的SOA系统！！！！连最基本的模型设计、模块设计、分层设计都没做好，难怪年年重构、年年完成不可能完成的任务！！！我确信这种重构、这种不可能完成的任务还会年年持续下去！！！

究竟什么是符合SOA风格的系统？先看看SOA宗师IBM的一篇文章：

http://www.ibm.com/developerworks/cn/architecture/ar-soastyle/

我来总结一下。

SOA能达到什么目的：

1.实现业务与IT的一致性；

2. 创建更灵活的反应更敏捷的IT基础设施；

3. 简化集成实现；

SOA要怎么做？

1. 从应用程序到流程和服务。消除应用程序，将软件系统创建为一组由业务流程进行协调的交互服务。每个服务实现企业上下文中定义的特定业务目标或功能，业务流程表示必须实现的业务解决方案。这个讲的比较抽象，我的解读就是服务表示一个最细粒度的业务目标或功能，由业务流程来编排这些服务，实现更大粒度的业务目标或功能，业务流程也是服务。注意，这里隐式的定义了服务的概念，服务是自治的，可替换的，可被多个流程编排的，不耦合流程上下文的，是直接面向业务目标或功能的，不是一个公共函数库，服务不是封装了数据和方法的类。
2. SOA的服务基于业务资源（对象）定义，不支持操作者的执行上下文，而是支持业务资源（对象）。这里的业务资源是指业务实体。业务实体也是来自业务的。所以，SOA能保证IT与业务的一致性。

别再说你的应用程序或烟囱遵循SOA的架构风格！

确定系统需求即确定系统用例。方法以根据业务用例实现场景分析为输入，分析每个系统Actor的系统用例。每个系统用例一定是一个完整的事件流，注意业务用例和系统用例的区别，业务用例是一个完整的业务目标，而系统用例是一个完整的事件流，是业务目标中的一个环节，如客户代表申请开户是一个完整的系统用例，但不是一个完整的业务目标，其包括多个页面操作。

3.11 用例实现分析

对每个系统用例，识别其可能的实现路径，每个实现路径就是一个用例实现，然后针对每个用例实现，分析人机交互，使用活动图绘制用例实现场景。

3.12 分析模型

使用分析对象，实现所有的用例实现场景，识别出三种分析对象。在这个过程中，也可以建立界面原型，和客户进一步达成需求的一致理解。分析模型是需求到设计的桥梁，分析类的层次高于设计实现，需求通过分析类转成计算机语言。后续做系统设计的时候，可直接将分析模型转换成设计模型。

在考虑分析模型的过程中，有可能识别出一些公共模块，比如开户、销户过程中都会有一些业务规则校验，需要引入规则引擎的支持，那么类似规则引擎这样的公共模块需要添加到逻辑架构中去。

3.13 非功能性需求设计

以性能为例讲一下对非功能性需求设计的过程。

1、确定性能目标：要支持多少用户、多少在线用户、多少并发操作、操作响应时间要求等；

2、以一个简单的三层架构为起点，根据性能目标，识别瓶颈。比如，如果数据库撑不住，那么需要考虑最佳的分库设计，如果是逻辑层撑不住，则要考虑负荷分担，状态同步的逻辑层方案设计，如果操作响应时间要求很高，则可根据不同场景，分析其操作的数据的读写特点，采用合适的缓存方案。如要支撑高并发低时延的大数据量查询，Twitter就采用了垂直缓存，raw缓存的设计方案。

3、验证性能设计。抽取典型场景，实现一个prototype来验证性能设计是否满足性能目标。

在质量属性设计中，如果需要新增模块，则需要修改逻辑架构。

有一些约束类需求也是非常重要的，不能遗漏分析。

经过这一个阶段，我们能够得到一个比较完整的逻辑架构，运行架构、开发架构、物理架构、数据架构的输入了。剩下的工作就是编档的工作了。

3.14 架构编档

有了上面的工作作为铺垫，编档就非常容易了，这个就不细讲了。

分别针对上节中业务用例视图中的每一个用例，分析该业务用例在实际工作中是如何做的，一般使用业务活动图来表述业务场景。在这个阶段，有几点需要特别注意的地方：

1、关注参与业务用例的各个参与者是如何协同的，如一个简化的用户开户的流程就是填写营业员提交开户订单-》主管审批订单-》施工人员履行订单；

2、对一个业务用例，如果有不同的实现路径，需要做不同的场景分析。例如，用户订购产品，分网上订购和营业厅订购这两种场景，两个场景大不相同；

3、场景的步骤粒度：用户的一个完整操作目的，如用户开户，则用户填写订单是一个步骤，而不用细化到用户取单、拿笔填单等；

3.5 产生业务对象模型

针对每个业务用例，根据业务用例场景，分析该用例中涉及的业务实体，并绘制业务对象模型图。

3.6 产生业务用例实现视图

业务用例实现指业务用例的一种实现路径，一个业务用例实现对应着一个业务用例场景。业务用例实现视图是表述业务用例实现的视图。

3.7 分析业务用例实现场景

业务用例实现场景着重描述如何通过人机交互来完成业务，是业务用例场景的具体化。一般用活动图来表述人机交互流程。这里每个步骤的粒度是人与系统或系统与人的一次交互。

3.8 领域建模

领域模型是描述特定问题域的对象及其相互关系。领域模型对业务对象做了进一步的精化。领域建模的步骤如下：

1、确定问题域：如CRM中的客户模型比较关键，我们决定对其进行领域建模，则需要将设计客户业务实体的用例全部识别出来；

2、领域建模：逐一分析涉及到操作客户模型的业务用例场景，识别领域对象以及对象之间的关系；

3、验证领域模型：使用序列图作为工具，基于领域模型来编排实现各业务场景，如果能实现，证明领域模型ok。

领域对象跟业务对象有区别，我认为，业务对象不是领域对象。业务对象来自于业务用例，是业务中客观存在的，而领域对象是对业务对象做进一步抽象、精化后的结果，是人对业务的主观认识，这就是为什么不同厂商的产品模型会不一样的原因，而且并不是所有的领域对象都是根据业务对象分析而来的。比如，某CRM产品面向全球市场，可定制能力是关键，为提升可定制性，需要构建一个快速开发框架，这个快速开发框架也是软件系统的一部分，也是有领域模型的，但是它的领域模型跟业务对象没半点关系。

3.9 产生逻辑架构草稿

通过上述步骤，我们已经有了部分领域模型，针对每一个可直接映射到业务对象一级的领域对象，可规划相应的业务模块，如有开户订单，那么可以有订单管理，有客户管理等。业务模块的划分粒度可依据大概的工作量而定，保证最低级别的业务模块的工作量是大致均匀的。这仅仅是一个建议，可以根据项目的实际情况决定。

基于上述的成果，我们还只能产出一个逻辑架构的草稿，因为我们还没有分析质量属性，后续对质量属性做设计的时候，还有可能会引入新的模块。比如要让业务流程可快速编排、定制，我们希望引入工作流，那么逻辑架构中也要引入一个工作流模块。

待续。。。

本人经历过不少项目，一些项目的架构设计负责人能力很强，接到活之后，马上一头扎进设计，抽象出一堆玄玄乎乎的概念，讲得人晕头转向的，让人觉得高深莫测，但是，在会议上却被涉众提的一些简单的问题问得很仓促，究其根本，还是漏考虑了涉众的需求，被人提问而又缺乏准备，是不是很多人有类似的经验？：）

我们还经常遇到的场景是设计人员通常为一些模型、概念争论不休，公说公的英俊，婆说婆的漂亮，其实模型概念这东西就像人的人生观和世界观，是人对世界和人生的主观认识，可能随着年龄阶段的变化而变化，而且有时候没有绝对的对与错，就像有些人喜欢金戈铁马，有些人喜欢与世无争，我们很难说谁一定是对的一定是错的！遇到这种清醒时，我建议停下争论，争论方各自拿出实际的业务场景来检验模型，哪个模型对场景的满足度更好，实现成本更低则更好，如果两个都挑不出刺儿，随便选一个即可。

还有一些架构设计人员喜欢创造一些与众不同的概念，让人看上去显得高深莫测。我觉得如果一个架构师能够用最少的语言、文字把问题和方案讲清楚，那才是真正的有水平！你让人晕头转向的时间既是项目的成本，因此，我们创造概念词汇的时候，需要从涉众的角度出发，我这里的意思不是盲从涉众语言词汇，而是说出发点从涉众角度出发，如果涉众原本使用的语言不够准确，我们可以跟他们一起探讨，定义更合适的概念词汇。

还有一个就是对软件竞争力的认识。有人通过包装一堆玄玄乎乎的概念来显得很高深莫测，试图通过这种方式让人觉得有竞争力，我认为，竞争力首先是要跟对手比，其次一定是涉众能感知的，能够涉众带来正向价值的，比如省多少成本，端到端业务流程节约多少时间。

我认为遵循一个科学的架构设计过程跟上篇提到的软件架构4+1视图法是架构设计的两个法宝，一个指导思维、定义输出，另一个指导如何来做，相辅相成，确保架构设计人员全面而正确的理解需求，做好需求平衡、设计平衡，设计出实用的、能落地的架构。

下面我会按顺序讲解架构设计的过程，以及每个步骤具体要做的事情。

3.1 确定涉众

      一般来讲，涉众包括客户（资方）、承接方（劳方）、用户。我们通常找到代表某一类型的涉众群体的代表人：客户代表、劳方代表、用户代表等。访谈的时候直接找代表进行。

3.2 确定系统边界

      对于要明确实现某种标准的软件系统，通常确定边界非常容易，直接按标准圈定的scope分析即可，比如像SIPServlet容器，是要求遵从JSR168规范的，那么软件系统的Scope就是JSR168规定的Scope，但是也有例外，比如客户或者劳方明确指定要复用一个现有的实现了部分功能的系统或组件，那么Scope就不同了。对于没有标准的软件系统，就需要分别访谈客户代表、承接方代表确定系统边界。为什么要访谈承接方代表呢？因为承接方代表往往是劳方领导，领导肩负企业战略达成的使命，很有可能对系统提出比客户更多的要求。举个例子，某客户需要一个SIP通信协议栈，以实现三方通话的业务，但是劳方领导认为，后续ICT融合是趋势，我们构建的系统要支持ICT融合应用部署和运行，支持业务标准JSR168规范。

3.3 软件需求收集

      软件需求可分为二类：

      功能需求（即业务用例）：描述Actor（用户或系统）可基于软件系统做什么事，要符合什么业务规则；

      非功能性需求又可分为两类：

      质量属性：质量属性指软件系统的品质，可分为运行期质量属性与开发期质量属性。

        运行期质量属性包括

      （1）性能：性能是指软件系统及时提供相应服务的能力。具体而言，性能包括速度、吞吐量和持续高速性这三方面的要求。
　　（2）安全性：指软件系统同时兼顾向合法用户提供服务，又阻止非授权使用功能的能力。
　　（3）易用性：指软件系统易于使用的程度。
　　（4）可用性：可用性与易用性不相同。可用性指系统长时间无故障运行的能力。
　　（5）可伸缩性：指当用户增加时，软件系统维持高服务质量的能力。
　　（6）互操作性：指本软件系统与其他系统交换数据和相互调用服务的难易程度。
　　（7）可靠性：软件系统在一定时间内无故障运行的能力。
　　（8）健壮性：也称容错性。是指软件系统在异常情况仍能够正常运行的能力。

       开发期质量属性包括：

   （1）易理解性：是指系统设计能被开发人员理解的难易程度。
　　（2）可扩展性：为适应新需求或者需求变化，为软件增加功能的能力。有些时候，称之为灵活性。
　　（3）可重用性：重用软件系统或其中一部分的能力的难易程度。
　　（4）可测试性：对软件测试以证明其满足需求规约的难易程度。在实际的项目中，主要指进行单元测试等难易程度。
　　（5）可维护性：修改Bug，增加功能，提高质量属性。
　　（6）可移植性：将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。

      约束：规定开发软件系统时必须遵循的限制条件，如要基于什么操作系统，要基于什么开发语言等等。

      对于功能需求，可找系统的直接使用用户代表，对其进行访谈，收集其要基于系统做的事情，可按照标准的用例模板，在访谈的过程中引导用户代表。之后，绘制业务用例视图，并针对每个业务用例，使用标准的用例模板将功能需求编档，通常叫用例规约。

      对于非功能性需求，可找软件系统的涉众，依据下面的模板，引导涉众，收集其对相应质量属性的要求：

总结：本阶段需要输出业务用例视图，业务用例规约，非功能性需求。

待续。。。

软件架构设计的主题狠深狠难，本文打算从架构的概念，架构的表述方法，架构设计的过程三个方面来讲一下我的理解。

一、什么是软件架构？

      温昱在《软件架构设计》一书中，给了下面的定义：

      组合派：软件系统的架构将系统描述为计算组件及组件之间的交互。
      决策派：架构是一系列重要决策的集合，这些决策与以下内容有关：软件的组织，构成系统的结构元素及其接口的选择，这些元素在相互协作中明确表现出的行为，这些结构元素和行为元素进一步组合所构成的更大规模的子系统，以及指导这一组织--包括这些元素及其接口、它们的协作和它们的组合--架构风格。

      在我看来，决策派的定义更为具体和准确，注意决策派用了元素这一词而没有用组件，组件是有具体含义的，指一个可独立替换的物理单元，而架构需要能够指导涉众，如开发人员、用户、部署人员等等，对开发人员来讲，开发过程中如何分包、如何将包打包为组件，架构师需不需要提供指导呢，答案是肯定的。因此，如果将架构限定在组件和组件的交互上，是不完整的。

二、架构的表述方法

     这个现在都有共识，就是4+1视图表述法：逻辑视图，实现视图，进程视图，部署视图，用例视图。 参见下图RUP 4+1视图：

      用例视图关注系统的人、事、物、规则，人是指系统的Actor，包括业务主角和业务工人，事是指系统用例，物是指业务实体，规则指做事情的前置条件、后置条件，做事情过程中的规则。下面这个图很精辟：

      用例视图是4+1视图中的+1，它定义需求标准，跟其它视图描述系统某一方面的结构有很大的不同。

      逻辑视图关注系统的逻辑功能模块和领域模型，不仅包括用户可见的功能模块，还包括实现用户功能而必须提供的“辅助功能模块”；它们可能是逻辑层、功能模块、类等。

      实现视图关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件。开发架构和逻辑架构之间可能存在一定的映射关系：比如逻辑架构中的逻辑层一般会映射到实现架构中的多个程序包；再比如实现架构中的源码文件可以包含逻辑架构中的一到多个类（在C++里一个源码文件可以包含多个类，即使在Java里一个源码文件也可以同时包含一个类和几个内部类）。

      进程视图关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。

      进程视图和实现视图的关系：实现视图一般偏重程序包在编译时期的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程，进程视图比较关注的是这些运行时单元的交互问题。

      物理视图关注“目标程序及其依赖的运行库和系统软件”最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。物理架构和运行架构的关系：运行架构特别关注目标程序的动态执行情况，而物理架构重视目标程序的静态位置问题；物理架构还要考虑软件系统和包括硬件在内的整个IT系统之间是如何相互影响的。

      上面几个视图是最典型的视图，不管你是通信中间件，还是依赖于数据库的企业应用都需要的。对于依赖数据库的企业应用，通常还需要数据视图，数据视图关注对象如何存储，如数据库表等。

       4+1视图不仅仅是软件架构的表述方法，它们各自从不同的视角去展现架构，因此，还是一种比较好的思维方式，引导我们从不同的视角去思考，从而做出比较系统的架构设计。

究竟什么是订单?

订单作为一个业务Actor皆可感知的重要业务实体，其是脱离IT系统而存在的，IT系统所做的仅是将其在软件系统中以对象的形式表现出来，不能依据系统实现，改变订单的定义。要正确的给订单下定义，须忘掉IT系统，从业务的角度给出定义。

企业一般会有售前，售后，销售，服务等部门，而订单是产生在销售活动中的，表示客户对企业产品或服务的一次订购。依此理解，退换货是服务，不是订单，而充值是订单。走不走流程，仅仅是订单实施的方式。

这个案例告诉我们，系统的业务模型，要从业务的视角来建，IT系统是将业务模型用软件概念来表述，不能改变业务概念。