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

首先介绍一下项目背景，某大型电信解决方案提供商向全球电信运营商提供某软件系统，因不同的运营商需求有差别，需要投入大量的人力物力对某个特定的运营商进行客户化定制，成本较高，为了降低定制成本，该提供商将交付组织切分为负责通用版本的组织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系统是将业务模型用软件概念来表述，不能改变业务概念。

Read part 1: Driving Design with Use Cases 
Read part 2: Driving Design: The Problem Domain

Welcome to the third in a series of five articles that provides a prepublication look at the annotated example from the forthcoming book, Applied Use Case Driven Object Modeling(Addison-Wesley, 2001; tentatively scheduled for April). We're following the process detailed in our first book, Use Case Driven Object Modeling with UML (Addison-Wesley, 1999), as we dissect the design of an Internet bookstore. In this article, we show common mistakes, and then explain how to correct them.

Within the ICONIX process, one of the early steps involves building a use case model. This model is used to capture the user requirements of a new system (whether it's being developed from scratch or based on an existing system) by detailing all the scenarios that users will perform. Use cases drive the dynamic model and, by extension, the entire development effort.

Figure 1. The "Big Picture" for Use Case Driven Object Modeling The diagram portrays the essence of a streamlined approach to software development that includes a minimal set of UML diagrams and some valuable techniques that take you from use cases to code quickly and efficiently.

Figure 1 shows where use case modeling resides within the "big picture" of the ICONIX process.

The Key Elements
The task of building use cases for your new system is based on immediately identifying as many as you can, and then establishing a continuous loop of writing and refining the text that describes them. Along the way, you will discover new use cases, and also factor out commonality in usage.

You should keep one overriding principle in mind during your effort to identify use cases: They should have strong correlations with material found in the system's user manual. The connection between each use case and a distinct section of your user guide should be obvious. It reinforces the fundamental notion that you are designing a system that will conform to the viewpoints of the users. It also provides a convenient summary of what "use case driven" means: Write the user manual, then write the code. If you're reengineering a legacy system, you can simply work backward from the user manual.

Once you have some text in place for a use case, it's time to refine it by making sure the sentences are clear and discrete, the basic format of your text is noun-verb-noun, and the actors and potential domain objects are easy to identify. You should also update your domain model—the subject of our previous article, "Driving Design: The Problem Domain" (Jan. 2001)—as you discover new objects and expand your understanding of the objects you'd previously found. And, it's important to determine all possible alternate courses of action for each use case wherever possible, an activity which should take up the majority of the time.

You can use several mechanisms to factor out common usage, such as error handling, from sets of use cases. This is usually effective, because breaking usage down to atomic levels will ease the analysis effort and save you lots of time when drawing sequence diagrams. Whether you use UML's generalization and includes and extends relationships, or OML's invokes andprecedes relationships, which we recommend in our book, your goal should be a set of small, precise, reusable use cases.

You should feel comfortable proceeding to the next phases of the development process when you've achieved the following goals:

• You've built use cases that together account for all of the desired functionality of the system.
• You've produced clear and concise written descriptions of the basic course of action, along with appropriate alternative courses of action, for each use case.
• You've factored out scenarios common to more than one use case, using whichever constructs you're most comfortable with.

The Top 10 Use Case Modeling Errors
Contrary to the principles we just discussed are a number of common errors that we have seen students make when they're doing use case modeling on their projects for the first time. Our "top 10" list follows.

10. Don't write functional requirements instead of usage scenario text. Requirements are generally stated in terms of what the system shall do, while usage scenarios describe actions that the users take and the responses that the system generates. Eventually, our use case text will be used as a run-time behavioral specification for the scenario we'll describe, and this text will sit on the left margin of a sequence diagram. We want to be able to easily see howthe system (shown with objects and messages) implements the desired behavior, as described in the use case text. So, we need to clearly distinguish between usage descriptions (behavior) and system requirements.

9. Don't describe attributes and methods rather than usage. Your use case text shouldn't include too many presentation details, but it should also be relatively free of details about the fields on your screens. Field names often match the names of attributes on your domain classes, which we discussed in January's article. Methods shouldn't be named or described in use case text because they represent how the system will do things, as opposed to what the system will do.

8. Don't write the use cases too tersely. When it comes to writing text for use cases, expansive is preferable. You need to address all of the details of user actions and system responses as you move into robustness analysis and interaction modeling, so you might as well put some of those details in your use cases. Remember also that your use cases will serve as the foundation for your user manual. It's better to err on the side of too much detail when it comes to user documentation.

7. Don't divorce yourself completely from the user interface. One of the fundamental notions of "use case driven" is that the development team conforms the design of the system to the viewpoints of the users. You can't do this without being specific as to what actions the users will perform on your screens. As we mentioned for item number nine, you don't need to talk about fields in your use case text, and you don't want to discuss the cosmetic appearance of your screens; however, you can let your prototypes, in whatever form they take, do that work for you. You do need to discuss those features of the user interface that allow the user to tell the system to do something.

6. Don't avoid explicit names for your boundary objects. Boundary objects are the objects with which actors will interact. These frequently include windows, screens, dialogs and menus. In keeping with our theme of including ample detail and being explicit about user navigation, we submit that it's necessary to name your boundary objects explicitly in your use case text. It's also important to do this because you will explore the behavior of these objects during robustness analysis (the subject of the next article in this series), and it can only reduce ambiguity and confusion to name them early.

5. Don't write in the passive voice, using a perspective other than the user's. A use case is most effectively written from the user's perspective as a set of present-tense verb phrases in active voice. The tendency of engineers to use passive voice is well-established, but use cases should state the actions that the user performs, and the system's responses to those actions. This kind of text is only effective when it's expressed in the active voice.

4. Don't describe only user interactions; ignore system responses. The narrative of a use case should be event- response oriented, as in, "The system does this when the user does that." The use case should capture a good deal of what happens "under the covers" in response to what the actor is doing, whether the system creates new objects, validates user input, generates error messages or whatever. Remember that your use case text describes both sides of the dialog between the user and the system.

3. Don't omit text for alternative courses of action. Basic courses of action are generally easier to identify and write text for. That doesn't mean, however, that you should put off dealing with alternative courses until, say, detailed design. Far from it. In fact, it's been our experience that when important alternative courses of action are not uncovered until coding and debugging, the programmer responsible for writing or fixing the code tends to treat them in ways that are most convenient for him. Needless to say, this isn't healthy for a project.

2. Don't focus on something other than what is "inside" a use case, such as how you get there or what happens afterward. Several prominent authors, such as Alistair Cockburn and Larry Constantine, advocate the use of long, complicated use case templates. Spaces for preconditions and post-conditions are generally present on these templates. We like to think of this as the 1040 "long form" approach to use case modeling, in comparison to the 1040EZ-like template that we advocate (two headings: Basic Course and Alternate Course). You shouldn't insist on using long and complex use case templates just because they appeared in a book or article. 

1. Don't spend a month deciding whether to use includes or extends. In our years of teaching use case driven development, we've yet to find a situation where we've needed more than one mechanism for factoring out commonality. Whether you use UML's include construct, or OML's invoke and precede mechanisms, or something else that you're comfortable with, doesn't matter; simply pick one way of doing things and stick with it. Having two similar constructs is worse than having only one. It's just too easy to get confused—and bogged down—when you try to use both. Don't spin your wheels. 

Figure 2 shows use case text that contains violations of five of the top 10 rules.

Did you spot the violations?

• Use case one is too terse. There is no reference to what kind of information the customer enters, nor to the page he or she is looking at. The text doesn't explain what is involved in validating the data that the customer entered. And the use case doesn't describe how the customer needs to respond to an error condition.
• Use case two doesn't have explicit names for the relevant boundary objects.
• Use case three reveals how useless it can be to obsess about using a complicated use case template. The name of the use case expresses the goal clearly enough; the content of the basic course will make the stated precondition and postcondition redundant.
• Use case four lacks alternate courses, even though it should be fairly clear from the context that some validation needs to occur, and that there are several possible error conditions (for instance, the system can't find the e-mail address, or the password that the customer entered doesn't match the one that is stored).
• Use case five doesn't specify how the system responds when the customer presses the update button.

Figure 3 shows the use case text with the mistakes corrected.

Our next article will demonstrate how to do robustness analysis in order to tighten up use cases and make it easier to head into detailed design. See you next month.

Figure 2. The 1040 "Long Form" Approach to Use Cases Use case text that contains violations of five of the top 10 rules.

[back to text]

Figure 3. The 1040EZ Approach to Use Cases The use case text with the mistakes corrected.

Read Part 1: Driving Design with Use Cases 

Welcome to the second in a series of five articles that provide a pre-publication look at the annotated example from our forthcoming book Applied Use Case Driven Object Modeling(Addison-Wesley, 2001; tentatively scheduled for April). We're following the process detailed in our first book, Use Case Driven Object Modeling with UML (Addison-Wesley, 1999), as we dissect the design of an Internet bookstore.

The focus of this article is domain modeling. The term "problem domain" refers to the area that encompasses real-world things and concepts related to the problem that the system is being designed to solve. Domain modeling is the task of discovering "objects" (classes, actually) that represent those things and concepts.

You may wonder why we're starting a series on use case driven object modeling by writing about the seemingly unrelated subject of domain modeling. The reason is that we write our use cases in the context of the object model (which we'll discuss in next month's article), instead of from an abstract, pure user viewpoint. This process allows us to connect the static and dynamic portions of the model, which is essential if we're going to drive our application design forward from the use cases. The domain model serves as a glossary that the writers of use cases can use in the early stages of that effort.

Within the ICONIX process, domain modeling involves working outward from the data requirements to build a static model of the problem domain relevant to the proposed system. This inside-out approach contrasts with the outside-in approach we take toward user requirements, which we'll describe in the third article in this series. (The fourth article, about robustness analysis, will describe how the domain modeling and use case development paths merge.)

Figure 1. The "Big Picture" for Use Case Driven Object Modeling The diagram portrays the essence of a streamlined approach to software development that includes a minimal set of UML diagrams and some valuable techniques that take you from use cases to code quickly and efficiently.

Figure 1 illustrates where domain modeling resides within the "big picture" for the ICONIX process.

Key Elements of Domain Modeling
The first thing you must do when building a static model of your system is find appropriate classes that accurately represent the real abstractions that the problem domain presents. If you execute this activity well, you will not only have a solid foundation on which to build the system, but also excellent prospects for reuse by systems that will be designed and built over time.

The best sources of classes are likely to be the high-level problem statement, lower-level requirements and expert knowledge of the problem space. To get started, lay out as many relevant statements from these areas (and even others, such as marketing literature) as you can find, and then circle, or highlight, all the nouns and noun phrases. As you work, refine the lists; gradually, nouns and noun phrases will become objects and attributes, while verbs and verb phrases will become operations and associations. Possessives ("its," "ours" and "theirs") tend to indicate that nouns should be attributes, rather than objects.

Next, sift through your list of candidate classes and eliminate unnecessary items. Look for classes that are redundant, irrelevant, incorrect or vague. Unessential classes may also represent concepts outside the scope of the model, or represent actions even though they're phrased as nouns: For example, Order Processor represents the nounification of the verb pharse, "process order."

You should also make some initial decisions about generalization ("kind of" or "is a" relationships among classes) while building your class diagram(s). If you need to, and you're comfortable doing so at this stage, generalize to more than one level of a subclass. Remember to look for kind-of statements that are true in the real world. Domain modeling is also the appropriate area for decisions about aggregations ("part of" or "has" relationships among classes).

Finally, much like an entity-relationship diagram (ERD), your domain model, updated to show associations—the static relationships between pairs of classes—should be a true statement about the problem space, independent of time (that is, static). This model serves as the foundation of your static class model.

The Top 10 Domain Modeling Errors
The flip side of the principles that we just discussed are a number of common errors that our students make when they're doing domain modeling for their projects. Our "top 10" list follows:

10. Don't immediately assign multiplicities to associations. Make sure that every association has an explicit multiplicity. Some associations on a class diagram represent one-to-one relationships, while others represent one-to-many relationships. These are both called multiplicities. However, you can avoid dealing with multiplicity altogether during domain modeling—it chews up time and can be a major cause of analysis paralysis, which we'll signal with this symbol. 

9. Don't do such an exhaustive noun and verb analysis that you pass out along the way. Kurt Derr's Applying OMT (SIGS Books, 1995) is a good source of information about "grammatical inspection." If you follow Derr's advice to the letter, however, you'll likely reach such an extreme level of detail, at such a low level of abstraction, with regard to your objects, that you can't breathe. Use this technique to get your object discovery started, but take care not to get carried away.

8. Don't assign operations to classes without exploring use cases and sequence diagrams.Take a minimalist approach to defining operations during domain modeling. In fact, don't assign any operations to classes during domain modeling, because there isn't enough information available with which to make good design decisions about operations at that stage. Wait until you begin interaction modeling, before you assign operations to classes.

7. Don't optimize your code for reusability before making sure you've satisfied the user's requirements. The more general your objects and classes, the higher the probability that you'll be able to reuse those objects and classes for other projects. A complete class is one that is theoretically reusable in any number of contexts. However, in order to achieve reusability and completeness, you must consider both attributes and operations, and we just told you why you shouldn't be assigning operations to classes during domain modeling. So don't worry too much about making classes reusable when you're doing high-level class diagrams.

6. Don't debate whether to use aggregation or composition for each of your part-of associations. Grady Booch's original descriptions of "has by reference" relationships morphed into aggregation within UML. Similarly, "has by value" became a "strong" form of aggregation called "composition" within which a "piece" class is "owned by" one larger class. Trying to differentiate between these two during a domain modeling effort is a definite way to do some serious tail-chasing. We much prefer to focus on simple aggregation during domain modeling. Aggregation versus composition is a detailed design issue. 

5. Don't presume a specific implementation strategy without modeling the problem space. As part of the ongoing refinement of your domain model, you should remove anything that clearly states an action rather than a dependency or that is specifically related to implementation. Don't introduce things on your high-level class diagrams that represent commitments to specific technologies, whether it's a relational database or a particular kind of server. Leave implementation issues to implementation.

4. Don't use hard-to-understand names for your classes, like cPortMgrIntf, instead of intuitively obvious ones, like PortfolioManager. Doing domain modeling up front helps everyone on the project team agree on what classes should be called. The more obvious the class names, the easier that task will be. Save acronyms and other kinds of abbreviations (if you insist on having them) for implementation.

3. Don't jump directly to implementation constructs such as friend relationships and parameterized classes. UML offers lots of opportunities to add what we call "Booch stuff" to class diagrams. This includes constructs that come more or less directly from C++, such as abstract and parameterized classes and friend relationships. These are more relevant to the solution space than to the problem space, though, and the focus of domain modeling should definitely be the problem space.

2. Don't create a one-for-one mapping between domain classes and relational database tables. If you're reengineering a legacy system that uses a relational database, the tables within that database are likely to be an excellent source of domain classes. However, be careful not to just bring them over to your static model wholesale. Relational tables can have lots of attributes that might not belong together in the context of an object model. You should use aggregation to factor groups of attributes into "helper" classes, which contain attributes and operations that are relevant to more significant classes.

1. Don't perform "premature patternization," which involves building cool solutions, from patterns, that have little or no connection to user problems. Patterns often become visible during robustness analysis. As we'll explore in the fourth article of this series, there are two strategies, "control in the screen" and "use case controller," that lend themselves to discovering patterns connected to use cases. Looking ahead to interaction modeling, design patterns can be highly useful in the context of sequence diagrams and design-level class diagrams. However, domain modeling is not the time to start thinking in terms of patterns.

Figure 2. A Flawed Class Diagram This class diagram violates the third, fifth, sixth, eighth and ninth rule from our top 10 list of domain modeling mistakes.

Figure 2 shows a class diagram that violates five of the top 10 rules.

Did you spot the violations?

• The cBinaryTree class is a parameterized class (also known as a template class within UML). This violates rule number three. There is no good reason to define an implementation construct such as a binary tree at this stage of modeling.
• The name of the cSessionBeanShpngCrt class indicates that the modeler has decided to represent the concept of a shopping cart using a session Enterprise Java Bean (EJB). This violates rule number five. Robustness analysis, which we'll discuss in the fourth article in this series, is the appropriate stage to explore how to map classes to Java Beans and so on.
• This class also has a composition relationship with the Order class. This violates rule number six. The modeler has committed to the idea that an order disappears when the shopping cart object to which it belongs is destroyed. This may or not make sense in the long run, but it's certainly too soon to be thinking along those lines.
• The cLoginMgr class has an operation named verifyPassword. This violates rule number eight. It's too early to make decisions about which operations go on which classes, and besides, chances are good that the operation belongs on the Login Info class anyway.
• The names of the two classes we just discussed should be Shopping Cart and Login Manager. The current names both violate rule number four.

Figure 3. A Corrected Class Diagram The rule violations found in Figure 2 are corrected here.

See the diagram in Figure 3 to see how the mistakes are corrected.

Our next article will discuss how to write small and concise use cases that capture functional requirements in terms of user actions and system responses in a way that's easy for readers to understand at a glance. See you then.

We need to see more use case and Unified Modeling Language examples" is a demand we hear fairly often these days. Although we present a fairly extensive example in our first book, Use Case Driven Object Modeling with UML (Addison-Wesley, 1999), we recently convinced Addison-Wesley to let us produce a companion workbook, in which we will dissect the design of an Internet bookstore, step-by-step, in great detail. This will involve showing many common mistakes, and then showing the model with its mistakes corrected.

This article is the first in a series of five that will provide a prepublication look at the annotated example from the workbook (to be called Applied Use Case Driven Object Modeling, conveniently enough) as it evolves. We'll be following the process detailed in our book (also known as the ICONIX process), which sits somewhere between the very large Rational Unified Process (RUP) and the very small Extreme Programming (XP) approach.

The ICONIX process is use case driven, like RUP, but lacks a lot of the overhead that RUP brings to the table. It's also relatively small and tight, like XP, but it doesn't discard analysis and design like XP does. This process also makes streamlined use of UML while keeping a sharp focus on the traceability of requirements. And, the process stays true to Jacobson's original vision of what "use case driven" means, in that it results in concrete, specific, readily understandable use cases that a project team can actually use to drive the development effort.

Each of the articles that follow this one will address an essential aspect of the process by focusing on one of the four critical diagrams used in the Iconix process. These four articles will have the same basic look and feel, with these shared elements:

• A "top 10" list that describes modeling errors to avoid.
• A diagram that shows two or three violations of these top 10 rules, as committed by students in classes that we've taught.
• Another diagram that shows corrections of the erroneous material.

Best of Breed
Figure 1 shows the "big picture" for the process. The diagram portrays the essence of a streamlined approach to software development that includes a minimal set of UML diagrams and some valuable techniques that take you from use cases to code quickly and efficiently. The approach is flexible and open; you can always select from the other aspects of UML to supplement the basic materials.

The second article will discuss domain modeling. This is the task of discovering classes that represent the things and concepts related to the problem that a system is being designed to solve. We'll describe how the domain model serves as a glossary of terms that people can use in writing use cases.

Domain modeling involves working outward from the data requirements to build a static model of the problem domain relevant to the proposed system. We'll point out how the approach emphasizes domain modeling more than RUP, and certainly more than XP.

The third article will discuss how to write use cases that detail the scenarios that the users will be performing. We'll describe how to write complete and unambiguous use cases that describe individual aspects of system usage without presuming any specific design or implementation.

Use case modeling involves working inward from the user requirements to start building adynamic model of the solution space for the proposed system. We'll talk about how use cases, by extension, drive the entire development effort.

The Forgotten Diagram
The fourth article in the series will discuss robustness analysis, a practice that originated with Ivar Jacobson but was dropped from the Rational implementation of UML. This involves analyzing the narrative text of use cases, identifying a first-guess set of objects that will participate in those use cases, and classifying these objects based on the roles they play.

• Boundary objects are what actors use in communicating with the system.
• Entity objects are usually objects from the domain model.
• Controllers serve as the "glue" between boundary objects and entity objects.

We'll show how robustness analysis, which serves as preliminary design within the process, provides the missing link between analysis and detailed design.

The fifth and last article will discuss interaction modeling, the phase in which people build the threads that weave their objects together and enable them to start seeing how the new system will perform useful behavior. We'll demonstrate how to build sequence diagrams, which enable designers to perform three key tasks:

1. Allocate behavior among boundary objects, entity objects, and controllers that will become full objects in the model.
2. Show the detailed interactions that occur over time among the objects associated with each use case.
3. Finalize the distribution of operations among classes.

We'll explain how the detailed, design-level class diagrams that result from interaction modeling represent a suitable foundation for moving into the coding phase of a project.

We'd like to point out three significant features of this approach.

First, it's iterative and incremental. Multiple iterations occur between developing the domain model and identifying and analyzing the use cases. Other iterations exist, as well, as the team proceeds through the life cycle. The static model gets refined incrementally during the successive iterations through the dynamic model (composed of use cases, robustness analysis and sequence diagrams). Please note, though, that the approach doesn't require formal milestones and lots of bookkeeping; rather, the refinement efforts result in natural milestones as the project team gains knowledge and experience.

Second, the approach offers a high degree of traceability. At every step along the way, you refer back to the requirements in some way. There is never a point at which the process allows you to stray too far from the user's needs. Traceability also refers to the fact that you can track objects from step to step as analysis melds into design.

Third, the approach offers streamlined usage of UML. The steps that we'll describe in the upcoming articles represent a "minimalist" approach-they comprise the minimal set of steps that we've found to be necessary and sufficient on the road to a successful OO development project. By focusing on a subset of the large and often unwieldy UML, a project team can also head off "analysis paralysis" at the pass.

E-Commerce Example
We'll demonstrate these aspects of the ICONIX process in the context of an on-line bookstore. The focus will be on the customer's view of the system.

Article two will describe how to build a domain model that has loosely coupled classes, each of which does one thing well.

Article three will discuss how to write small, concise use cases that capture functional requirements in terms of user actions and system responses in a way that's easy for readers to understand at a glance.

Article four will demonstrate how to do robustness analysis in order to tighten up use cases and make it easier to head into detailed design.

Article five will explore sequence diagrams, which we'll use to allocate the behavior specified by use cases to the objects mentioned in those use cases.

See you next month.
http://drdobbs.com/184414677 

这里的难点在于如何抽象出一套稳定的元模型，能描述各种各样的变化，以达到通过配置即可搞定需求变更的目的。

这里着重讲一下金蝶BOS的元模型，所谓元模型，是模型的模型。

在数据层，有Table，Table对应到数据库表，直接三种Table之间的关系，什么交叉表、扩展表之类的，基本与平常大家设计表的范式对应，不多说；

在业务逻辑层，有实体，实体表示系统的领域实体对象，一个实体对应到一个Table，实体的属性对应到Table的field或其扩展表的Field，实体与实体之间有关系，关系分为One2One，One2Many，Many2One，Many2Many。还可以对实体的属性定义计算公式，约束。但缺乏实体级别的约束。我认为金蝶可以增加这一个小特性：）。实体可继承另一个实体，以获得另一个实体的定义。

可以为实体定义方法，方法映射到一个规则。也就是说调用这个方法的时候实际执行的是这个规则；

可以为实体定义查询方案、过滤方案、排序方案，主要是以OO的方式做实体查询，对外暴露OO化的用户接口，对内生成SQL用；

可以为实体定义事件，Function和Facade可监听事件，事件由Function触发。

金蝶对Function的解释是“业务功能是对运行系统的Entity对象、UI对象及其方法的一定封装，供其它模块或二次开发使用”，比如上文提到的事件，即是由Function触发的，但不知为什么还要指定事件的方法，Function是事件的生产者，事件的方法表示事件的消费者（监听者），这样做不是导致生产者与消费者耦合了吗？？那还要事件干什么，不知道有没有朋友能解答这个问题？？Function还可以绑定到一个UI的Action，意味着当该UI对象的Action触发时，会执行这个Function。对UI Action的绑定是可选的。

Facade表示领域Service对象，相比实体，其仅仅有方法，没有属性。

UI对象表示一个界面对象，比如订单创建对象，可以对其指定Layout，UI对象支持绑定实体、Query对象。UI对象也有事件、Action和状态，事件和Action应该可以绑定到Function和Facade，State表示界面对象的状态，比如界面通常有编辑状态、查看状态等等。UI对象还有个父对象，还没怎么弄清楚UI对象与UI对象之间的关系，没有看到描述，需要进一步研究；感觉BOS对UI层的抽象略显简单，通常UI层是最复杂的，有字段联动，子页面联动等等，没见到BOS怎么来搞定这种联动场景。

查询表示对对象的查询，需要绑定一个对象树，可定义查询方案、过滤方案、排序方案，生成SQL用；

还有其它的一些非主要元模型。

通过UI Object、Entity/Function/Facade、和Table，可支持描述界面、领域对象/服务、数据库表以及它们之间的绑定关系，如果对象模型有变更、或者业务逻辑有变更，会导致这三层的对象的变化，而变化可基于这三层的元模型描述，实现配置即可用。

Spring现在已经覆盖系统各个层次，在web层，有Spring Web、Spring Webflow，在业务逻辑层，有Spring Core，在数据持久层，Spring整合了Ibatis（SQL Mapping）、Hibernate（ORM）、NOSQL，在集成层，Spring有Spring Integration，还有针对特定场景的解决方案，如Spring batch、Spring Message、Spring Security、Spring Social等等。

Spring Core是一个IOC容器，负责对象的生命周期管理，正因为其负责了对象的生命周期管理，Spring可以通过Proxy和AOP等技术在对象创建和调用的时候玩一把魔术，如：动态为对象的调用植入一些代码，使得开发人员可以把业务逻辑无关的调用系统服务的逻辑切面化，实现声明式配置。另外，Spring还负责了对象的组装，使得面向接口的编程更为简单，省去很多Factory逻辑。

其它方案都可以说是基于Spring Core的，面向特定应用场景的解决方案，不多说。

如何解决上文提到的鉴定标准中的问题呢？我认为答案就是MDD。

用一个实际的例子来表述一下思路：

在CRM系统有个订单处理模块，其提供了订单管理、订单流程执行、工单管理等功能，营业员通过界面提交一个订单请求，如果订单请求通过业务规则的校验，则会创建一个订单对象，订单对象的创建会触发订单流程的创建，订单流程流转的过程中，会在各个节点创建工单，也会调用其它子系统开通服务，比如调用物流发货。订单流程完成后，订单对象的状态也完成。实际的系统比这个要复杂，这里仅仅为了阐述思路，做适当的简化。

从上面的例子，我们可以识别出几个模型:订单、工单、订单流程，订单、工单、订单流程都是stateful的、其state的变更会导致其它对象的状态变更或者服务的执行。

在展现层，展现各个模型是有章法的，比如创建订单的界面总是一样的，处理工单的界面也总是一样的，展现订单的界面也总是一样的。因此，我们可针对指定的对象的某种需要展现的状态，提供合适的展示构件（WEB TAG）来展示它。

在持久层，因为对象总是持久化到一张表当中的，因此，可用一些ORM的框架来持久化对象，而不是开发人员针对每个场景去写SQL，复杂的关联查询可以使用类HQL。

各对象之间的关联操作通过事件驱动。

举一个订单创建的例子：

1、开发做的工作：

    1）使用元数据定义订单的数据结构，包含持久化元数据、基本属性元数据、字典元数据；

    2）定义订单状态机，以及状态变迁的规则；

    3）建模订单处理流程；

    4）定义订单请求处理规则流，并发布为一个受理订单请求的服务；

    5）开发订单创建界面，使用订单WEB构件来展示订单对象；

    6）定义事件，以及事件的监听服务；

2、系统执行流程：

    1）营业员打开订单创建界面，系统获取订单对象的元数据，生成订单创建页面；

    2）营业员点击订单创建界面的提交按钮，调用受理订单请求的服务；规则流执行，如果规则校验错误，则返回错误，如果成功，则创建订单，返回成功；

    3）因创建订单，导致订单的状态变为创建状态，触发订单创建事件；

    4）订单创建的监听服务流程服务接收到事件，触发订单处理流程的创建；

    5）流程执行的过程中编排第三方系统服务；流程执行结束后，触发订单流程结束事件，流程结束事件的监听服务订单管理接收到事件，触发状态机变迁，订单状态变为完成。

上述开发做的工作全部可通过配置完成。后续如果增删字段，修改元数据即可，要增删改业务规则，调整业务规则即可，要调整实体状态，修改实体状态机即可。

业务平台要致力于对状态机、业务流程、SEP、元数据、领域化的WEB构件的实现，并将其有机整合。

写的比较乱，过几天再整理一下。。。

就如同变化多端的八卦卦象是由乾、兑、离等8个基本卦象组成，万事万物是由数种原子构成，形态各异的高楼大厦是由砖头和砂浆砌成，应用也有构成其的“元”，即构件。

业务应用是分层的，典型的分层是展现层、流程层、服务层、数据持久层，每一层次的关注点都不同，构件也不相同，比如一个业务逻辑层的构件输出的数据，会通过展现层的构件来展现在界面上。且各层之间的贯通黏合（如MVC中的Controller层就是黏合逻辑），通常要耗费比较多的开发精力，一个好的业务平台，除了在各层次分别提供可复用的构件，需要能够减少各层黏合的工作量。

面向特定领域的业务平台的易用度与其适用面是鱼和熊掌的关系，针对特定领域，要越易用，则平台能力就要越面向特定领域，则越不通用，导致适用面越窄。因此，一个好的平台，要注意分层，比如分成通用的构件和领域化的构件。业务用户可按需使用。同时，还需要在各层次开放定制能力，供业务用户在各层提供领域构件。

现在的产品交付都是解决方案级的交付，解决方案由多个系统或子系统构成，一个部门，一个项目组通常只是提供解决方案中的一个部件，负责端到端的业务功能中的一个环境，因此，需要支持构件的组装，以形成更大粒度的构件，支撑软件复用与集成。

开发一个子系统粒度的构件通常是一件很复杂的事情，如CRM，需求琐碎、变化频繁、不同客户要求不尽相同，如果缺乏一个好的支撑平台，人力成本会很高，TTM也会很长，因此，一个好的业务平台，也需要能够支撑快速的构件开发、定制。

解决构件的组装和集成，已经有比较成熟的技术了，如ESB、SCA等，IBM、Oracle等大厂商都有提供集成化的开发环境和执行环境。但如何支撑构件的开发这块，各大厂商也有支撑，比如在展现层，Oracle有ADF，在流程层，IBM和Oracle都提供了BPM，在service层，IBM和Oracle提供了规则引擎，VMWare的Spring，在持久层，Oracle提供了Toplink，还有就JBOSS大名鼎鼎的Hibernate。所有前面提到的这些都是业务无关的技术部件，且各层之间的靠业务开发人员自己来黏合，还是不够领域化。因此，一个业务平台，仅仅去重复制造IBM、Oracle造过的轮子，是完全没有竞争力的（这里不算成本）。面向特定领域，评判一个业务平台是否优秀的标准是：

1、是否提供了丰富的领域构件？

2、是否能够节省业务开发人员黏合各层的工作量？

3、提供了什么样的机制来应对需求变化？比如有的客户要求多加个字段、加个校验，有的客户要求少个字段、少个校验等等。

待续。。。

做事情需要有方法，方法可以参考业界一些好的实践。本文主要是想总结一些好的设计IDE的实践供朋友们借鉴。

我们借IBM的BPM Suite来分析IDE的设计方法。

IBM BPM Suite主要用于业务流程的管理。IBM把业务流程的生命周期划分为流程建模、流程开发、流程部署、流程监控4个环节，针对这4个环境，定义了相应的角色执行相应环节的工作。然后再针对指定的角色，提供了专门的workspace来支撑其工作，实现了对其不关心的数据和配置的封装和隐藏。

这种方法论其实是通用的，对CRM应用来讲，其开发生命周期也可分为几个阶段，每个阶段的参与Actor需要使用的信息、不需要了解的信息都不同。同时，一个现代SOA应用在技术上通常会分层，典型的分层是UI、流程、Services、Entities。需要根据Actor，仔细分析在每个分层上的开发用例，从而构建出最适合各种Actor的IDE。

本人最近在研究BPEL和BPMN，希望能和对此有研究的朋友探讨一些技术问题，联系QQ：38425726，盼指教。

接下来的推导分为两个阶段，第一阶段先推导支撑技术，第二阶段再推导以什么样的开发方式将这些支撑技术串起来，达到快速开发的目的。

下表中列出了对上面的核心组成要素（数据+服务）的一些支撑技术：

下面在列一些辅助支撑技术，这些技术是为了让企业应用这些大厦能够构建的更快，毕竟盖房子，有了水泥和砖是不够的，还要有扁担，簸箕等等。