建模：是将现实世界中的某种事物用某种形式(数学公式、图形、表格... ... )抽象的表示的过程（自己定义的，不一定准确）。
【http://wiki.mbalib.com/wiki/业务建模， 业务建模】。 （1） 什么是业务建模 业务（Business）--是指商业（或非商业）组织及其运作的活动流程。 建模（Modeling）--是指人类对事物进行的一种可视化抽象活动，目的是为了揭示事物的本质和规律。 有了上述两个词的概念，就不难理解"业务建模"的定义了。 业务建模是指对商业（或非商业）组织及其运作的流程进行的建模过程。 最常见的商业组织就是企业，所以，针对商业组织的业务建模一般就指对企业的组织及其业务过程进行建模。 很多人一听到或说到，就理解成用户需求分析的一部分，其实这是对业务建模错误认识。需求分析有自己独立的流程。 业务建模的结果并不是需求（它只是需求的输入），它是反映了业务组织的静态的和动态的本质抽象特征。 业务建模因而是对业务组织的静态特征和动态特征进行抽象化的过程。 静态特征包括：业务目标、业务组织结构、业务角色、业务成果等。 动态特征主要指：业务流程。 业务建模并不一定需要与信息化或计算机技术硬扯上关系，除非想把流程的某些环节或所有整个流程进行自动化运作，但这也只是业务模型中的一种手段或优化，不应喧宾夺主。 所以严格来说，业务建模与计算机建模无关，它只是业务领域的一个模型，通过业务模型可以得到业务范围，帮助需求人员理解客户业务，并在工务层面上和客户达到共识【大象--Thinking in UML，P61】。 （2）业务建模的分类 【http://wiki.mbalib.com/wiki/业务建模， 业务建模】。 大概可分为两类：
以企业整体业务为对象，面向业务过程的建模。 以问题域为对象，面向KPI的建模。（3）业务建模的思路与步骤 【http://wiki.mbalib.com/wiki/业务建模， 业务建模】。 以企业业务为例：
明确业务领域所在的业务体系，业务领域在体系中的作用，与其他业务领域的关系。 明确业务领域内的主要内容、业务目标、服务对象，构建领域内的业务层次。 明确各业务的背景、目标、内容。 明确各业务的流转顺序。 明确各业务节点的5W1H。 明确各业务中业务规则的算法。 明确各业务输入、输出的数据以及参考的资料。 明确各业务的业务主角与业务角色。
需求获取阶段。 需求是技术无关的。在需求阶段讨论技术是没有任何意义的。那只会让你的注意力分散。技术的实现细节是在后面的分析、设计阶段才需要考虑的事情。而在业务建模阶段，不但要保证需求的技术无关性，还要保证你的需求不要深入细节，因为在业务建模阶段，最重要的事情就是为了了解业务的全貌，深入细节会浪费时间和精力【http://blog.csdn.net/11t/archive/2004/10/26/152621.aspx， 软件和需求的实践，P17】。
领域模型：领域模型是一组图，这些图有助于定义出现在用例中的术语。这些图显示了问题中的关键对象以及他们之间的联系。认识到领域模型是一种描述工具，用来帮助人们记录他们的决策以及相互之间的交流是非常重要的【敏捷软件开发：原则、模式与实践，P443】。 领域模型中使用一种称为<<type>>或<<stereotype>>的实体。<<type>>或<<stereotype>>代表了对象可以充当的角色，可以具有方法和属性，也可以具有和其它<<type>>实体的关联。但是<<type>>或<<stereotype>>不代表设计意义上的类或者对象，不代表软件元素，也不直接映射到代码。仅表示一个用于问题描述的概念实体【敏捷软件开发：原则、模式与实践，P443】。
用例是一种描述系统需同需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。
需求分析阶段。 用例模型是系统既定功能及系统环境的模型，它可以作为客户和开发人员之间的默契。用例是贯穿整个系统开发的一条主线。同一个用例模型即为需求工作流程的结果，可当作分析设计工作流程及测试工作的输入使用。 系统建模有很多种方法，每种建模方法可以满足不同的目的。用例模型最主要的作用是将系统行为传达给客户或最终用户。因此，模型必须易于理解。 需求分析仍然多采用自然语言，如果采用形式化语言，和用户沟通将成为一个大问题，这意味着客户在开发软件前必须先进行形式化语言培训，这是不现实的。自然语言对需求分析最大的弊病就是它的二义性，所以不得不对需求分析中采用的语言进行某些限制【http://blog.csdn.net/11t/archive/2004/10/26/152621.aspx， 软件和需求的实践，P5】。 除了语言的二义性外，注意不能使用计算机术语。需求分析最重要的是和用户沟通，可是多半用户不是计算机的专业人士，如果在需求分析中使用计算机术语，就会造成用户理解上的困难【http://blog.csdn.net/11t/archive/2004/10/26/152621.aspx，软件和需求的实践，P5】。
系统分析阶段。
分析模型是采用分析类，在系统架构和框架的约束下，来实现用例场景的产物。在OO之路的第一部里，我们说用例和用例场景规定了业务范围和要求，如果分析类完全实现了这些用例和场景，我们就能肯定的说分析类已经满足了需求。分析类有：
边界类(boundary) 实体类(entity) 控制类(control)再加上实现用例场景需要的actor类，共四种。 分析模型是高层次的系统视图，在语义上，分析类不代表最终的实现。它是计算机系统元素的高层抽象。上述的四个分析类可以完全模拟计算机的执行过程。分析类具体化以后产生真正的实现类，即所谓的设计类，也就是大多数设计师所说的类图。 分析模型正是OO设计的核心，设计类只是OO的实现手段。 分析模型是MVC模式的经典应用。从分析类的名称就可以看出来。"商业系统无论多复杂，无论什么行业，其本质无非是人，事，物， 规则。人是一切的中心，人做事，做事产生物，规则限制人事物。人驱动系统，事体现过程，物记录结果，规则代表控制。无论OO也好，UML也好，复杂的表面 下其实只是一个简单的规则，系统分析员弄明白有什么人，什么人做什么事，什么事产生什么物，中间有什么规则，再把人，事，物之间的关系定义出来，商业建模 也就基本完成了。" 根据这一段话，再对比分析类的名称，想想MVC模式，读者应该能够发现分析类在OO和商业目标中精妙的对应关系：人，事，物，规则 ，actor、boundary、entity、control。这就是为什么笔者说分析模型是OO设计的核心。
【OO系统设计师之路--分析模型， coffeewoo】。 为什么要用分析模型？现在绝大多数系统的产生过程并没有用分析模型，也照样运行，而且在RUP里，分析模型也只是一个Optional的过程，并非强制过程。 的确如此，这可能也是为什么大多数设计师并不用分析模型的原因。有读者要问，分析模型完全实现用例场景因此可以证明设计满足需求，那么我用设计类来实现用例场景，也可以同样证明，分析模型又有何用呢？
这正是分析模型要存在的原因。
分析类不代表实现，它具化成设计类以后才是实现。分析类是系统元素的高层抽象。 有经验的设计师，特别是那些擅长于使用设计模式的设计师们都知道，OO系统要保持扩展能力，复用性要好，要把变更影响控制在小范围内，就要应用高层次的抽象，用高层次的抽象接口来 表达系统行为，而把具体实现delay到子类，配置文档，甚至运行期去。所有的设计模式，不论采取了怎样的技巧，均是为了这些目的。 分析模型对系统设计来说也同样延续了这样的思想，用四个高度抽象的分析类来表达系统行为，而把实现delay到设计类中去。这些抽象透明于实现方式，也透明于实现语言，它表达的核心观点是系统架构，业务实现模式和规范，需求可回溯的验证。 比如，我们用一个实体分析类表达了某个业务实体，在分析模型中我们定义了所有针对该实体的交互和存取操作，对分析模型这个层次的抽象来说已经完整表达了计算机系统对业务需求的模拟实现。但其实这时并未真正的实现这个业务需求，一直到具化成设计类后，根据开发语言特性、框架、规范等等要求，这个实体分析类可被具化成一个或多个SDO，POJO，EntityBean，可以用Hibernate，可以用 Webshpere BO，也可以用Weblogic XMLbean...等等。完全可以根据实际需要来确定实现方式和语言，因此实现得以delay，这就带来了OO扩展和复用的潜在能力。并且这时设计师已经不用担心具化出的设计类是否会脱离需求，它们已经在分析模型层次被验证，而能专心考虑系统实现所要求的那些特性。
为什么要用分析类而不是设计类去验证需求呢？这是由于抽象层次更高，分析类比设计类验证需求的工作量以及可能的变化都要少很多。 比如针对登录要求，如果用分析类来表达，我们只需要向登录control类发一条登录请求就OK了。而设计类由于与实现方式相关，并且已经具化到了实现，所以根据安全验证方式不 同，LDAP，CA，SSL，或应用服务器不同，登录方式和方法都不同，并且可能是很多个步骤，例如 getUser()、getRole()、getGroup()、register()...，你愿意用这么多说明才能表示已经验证了一个简单的登录要求 吗？如果更换了安全模式呢？更换了应用服务器呢？这在现实情况中也很常见，对分析类来说，由于抽象层次高于实现方式，因此继续有效，而设计类却必须更改。这就是为什么要用分析模型来验证需求的原因之一。 较真的读者或许会说，安全模式变了，就算不为了验证需求，设计类本身也不得不改，这看起来没什么必然因果关系啊？考虑一下，在一个项目组里，当一份设计文档被share到负责各个摸块的开发小组时，各小组对该文档都形成了一个共同的认识。如果这个认识是基于分析模型而不是设计模型的，当安全模式改变，对负 责安全模块的开发小组来说，他可以改变他负责的设计类而无需通知其它小组。因为从分析模型的层次来看，一切都没有改变。 这与大家熟悉的设计类中更换了类实现而保持接口不变的道理是一样的，只要接口不变就无须通知任何人。 而如果这个共识是基于设计模型的，一点小的改变都需要通知到各个小组，因为各小组的认识是基于类名，方法名的，改动了，能不通知他人么？从OO角度来说， 这就是松藕合和紧藕合的差别。 从上面的例子可以看出分析模型比设计模型要稳定得多，因此用它来验证和表达系统到需求的映射是很好的。这有助于在开发过程中当实现类变来变去，一个类改为两个，突然又加了一个设计模式（这种情形非常的常见吧？）时，保持系统到需求映射的稳定，同时也就保持了一个稳定的系统视图和业务架构。对开发小组来说，不会因为这些变动影响到他们对系统整体的认识。
分析模型较高的抽象层次有助于让人们更容易理解系统行为。由于与实现无关，因此可以用大白话来表达系统交互过程，比如对于登录要求，我们可以直接用"登录 ()"来表示这个系统请求，相比于设计类中的getUser()、getRole()、getGroup()之类的方法名，分析模型明显要直白得多。而开发人员对系统行为良好的理解显然会对开发有着很大的帮助。 在一个项目比较复杂，而且是多个Team横向合作的情况下，分析模型显得更加有效。因为它的简洁和稳定，会让各个开发组减少细节沟通的成本。 最后，如果你所做的项目并非一次性项目，而是基于一个行业，不断的有相似或相同的单子，更打算长期立足于这个行业，做精做深，形成完整的行业解决方案的话，分析模型更是必须要考虑的。在你的组织面对同行业不同客户时，可能无法保证所有客户都选择同样的语言，同样的软件平台，有着同样的业务要求。在设计模型的层次上，这必然导致很多个不同的实现版本。面对这么多不同的版本，如何去维护一个"统一的行业解决方案"呢？正如上面所述，由于分析模型抽象层次高于实现方式和实现语言，你可以用分析模型来维护这一个方案。还是登录的例子，虽然客户们可能有的用LDAP，有的用CA，将来可能还有新的模式，但对于分析 模型来说，安全模块始终可以保持一致。这将非常有利于随着各个项目的进行，对分析模型的逐步维护，而形成一个统一的，稳定的架构和行业解决方案，而针对不 同的客户要求，又可以提供不同的实现包。
【OO系统设计师之路--分析模型， coffeewoo】。 分析模型是系统的高层抽象，是高于实现语言和实现方式的。因此在做分析模型过程中，要跳出固有的Java思维，C++思维，同时也暂时不要考虑设计模式的应用，而专心的，用OO思维把四个分析类的职责和交互，以及它们之间的关系定义清楚。 如果说用例分析大部分情况下是程式化的（笔者正希望它是程式化的）， 那么你会发现，分析模型大部分工作也是程式化的。
系统设计阶段。
【http://blog.3snews.net/?6633， 区分用例模型、分析模型和设计模型】
用例模型使用客户的语言进行描述；分析模型使用开发人员的语言进行描述
用例模型是系统的外部视图；分析模型是系统的内部视图；
用例模型通过用例来构造，提供外部视图的结构；分析模型通过构造型的类或包来构造，提供内部视图的结构；
用例模型用于客户和开发人员签合同时，明确系统应该和不应该做什么；分析模型为开发人员所用以理解如何构造系统，即怎样设计和实现系统
用例模型中需求可能存在冗余和不一致等问题；分析模型中需求不可能存在冗余和不一致等问题
用例模型捕获系统的功能包括对架构重要的功能；分析模型概述如何实现系统功能，包括对架构层重要的功能，是设计阶段的切入点
用例模型定义早分析模型中进一步进行分析的用例；分析模型定义用例实现，每个用例实现代表对用例模型中一个用例的分析。
【http://blog.3snews.net/?6633， 区分用例模型、分析模型和设计模型】
分析模型是概念模型，因为是系统的一个抽象并回避了实现问题；设计模型是物理模型，因为它是实现的蓝图。
分析模型对设计是通用的，即适用于多种设计；设计模型对设计不是通用的，针对特定的实现
分析模型不太形式化；设计模型比较形式化
分析模型开发费用比较低；设计模型开发费用比较高，是5倍的分析模型
分析模型层数少；设计模型层数多
分析模型勾画系统的设计轮廓，包括系统架构；设计模型是进行系统的设计，包括系统架构；
分析模型不需要在整个软件生命周期内做维护；设计模型需要在整个软件生命周期内做维护；
分析模型定义作为构造系统基本输入的架构，包括创建设计模型；设计模型在尽可能保持需求模型所定义结构的前提下构造系统。
