级别： 初级 张 蕴 (yunzhang710@gmail.com), 博士, 西北工业大学计算机学院智能决策教研室
陈 洋 (yangchen129@gmail.com), 软件工程师, SPSS西安研究院
2008 年 11 月 03 日 利用管理学模式提高 WebSphere Business Modeler 建模质量，着重描述了如何使用管理学中不同的模型来提高在建模中的效率并使得建模更加准确。本部分着重描述了业务建模的领域、目的、主要任务，并详细的介绍了如何确立业务建模的过程中的建模，业务实体及准备计划。本部分对于利用管理学模式提高建模质量系列以后章节部分的理解有重要的作用。
为什么要业务建模
Brooks 大师说，三十多年来各式各样的应用系统（Application Programs AP）历经多次的修修改改，已经变得面目全非，如同一群怪兽，难以驯服。
Rogerson大师也说，The application is a rock in the river of change.（应用（系统）成为改变之潮流中的顽石）。
对很多企业而言，有一个整合企业各部门的信息系统的心愿似乎已经成了一种奢望。企业中或多或少都会有一些应用系统在辅助企业的自动化运作，当企业信息主管希望能够对目前的信息系统进行整合以配合企业发展的时，他们失望了。因为大多数的应用缺乏一个统一的接口，难以进行整合。
以前，应用程序的开发都是基于部门的功能而建的，只是为了单纯的解决目的而建立应用系统。所以这种方式建立的应用系统是针对特定的功能区域（Function Area）。至于如何使企业内的多个应用系统共同运作，就不在设计者的考虑之列了。然而随着企业的发展，企业需要灵活地变化以适应市场快速地变化。当业务发展的时候，原有的一系列应用系统却成了企业发展的拦路虎，这使得企业不得不回到手工的时代（由于系统不能满足市场变化后的需求，所以需要利用传统的笔和纸等方式来进行信息的记录，和信息的表达）。
针对这种情况，有没有相应的解决之道呢？解决的方法就是从业务建模入手。通过用例分析技术，建立企业的业务模型，进行适当的切割，选取稳定的软件架构，分析出企业的业务实体（Business Entity 企业中微小不可分的事物，抽象或具体的，如账户，契约等，又被称为Business Object），以此为基础，组装出组件（Component），落实到相应的三层结构，建立针对特定功能区域的应用系统。
以这样的流程做出来的企业应用系统，不论规模是部门级的，还是企业级的，都有扩展的余地。以组件为基础的软件三层构架，也能够较好的配合企业的业务变化而变化（相应变化的代价较小）。而整个流程的第一步，就是业务建模。
业务建模的目的
了解目标组织（将要在其中部署系统的组织）的结构及机制。
了解目标组织中当前存在的问题并确定改进的可能性。
确保客户、最终用户和开发人员就目标组织达成共识。
导出支持目标组织所需的系统需求。
为实现这些目标，业务建模工作流程说明了如何拟定新目标组织的前景，并基于该前景来确定该组织在业务用例模型和业务对象模型中的流程、角色以及职责。
业务建模的规模
根据环境和需求的不同，业务建模工作可能有不同的规模。以下列出了六种这样的场景。
场景 #1 - 组织图
您可能需要构建组织及其流程的简图，以便更好地了解对正在构建的应用程序的需求。在这种情况下，业务建模就成了软件工程项目中的一部分，它主要是在先启阶段执行的。通常，这些工作在开始时仅仅是画出组织图，其目的并不是对组织进行变更。但实际上，构建和部署新的应用程序时往往会进行一定程度的业务改进。
场景 #2 - 领域建模
如果您构建应用程序时的主要目的是管理和提供信息（例如，订单管理系统或银行系统），那么您可能选择在业务级别上构建该信息的模型，而不考虑该业务的工作流程。这就称为领域建模。
场景 #3 - 单业务多系统
如果您正在构建一个大的系统（即一系列的应用程序），那么一个业务建模工作可能成为数个软件工程项目的输入。业务模型帮助您找出功能性需求，并且也作为构建应用程序系列构架的输入。详情请参见概念：从业务模型到系统。在这种情况下，通常将业务建模工作本身当做一个项目。
场景 #4 - 通用业务模型
如果您正在构建一个供多个组织使用的应用程序（例如，销售支持应用程序或结账应用程序）。一种有效的做法是：从头到尾进行一次业务建模工作，从而按这些组织的经营方式对它们进行调整，避免一些对于系统来说过于复杂的需求（业务改进）。但如果无法对组织进行调整，那么业务建模工作能够帮助您了解并管理这些组织使用该应用程序时存在的差别，并使您更容易确定应用程序功能的优先级。
场景 #5 - 新业务
如果某个组织决定要启动一项全新的业务（业务创建），并将构建信息系统来支持该业务，那么就需要进行业务建模工作。在这种情况下，业务建模的目的就不仅仅是要找出对系统的需求，而且还要确定新业务是否可行。在这种情况下，通常将业务建模工作本身当做一个项目。
场景 #6 - 修改
如果某个组织决定要对其经营方式进行彻底修改（业务重建），那么业务建模本身就是一个或多个项目。通常，业务重建分数个阶段完成：新业务展望、对现有业务实施逆向工程、对新业务实施正向工程以及启动新业务。
业务建模时期的主要任务
项目涉众的共同愿景：项目的成功离不开项目涉众的支持，但共同愿景的树立可没有想象中的那么简单，因为每位涉众都关心自己的利益，都有自己的评判标准。你可以把大家的意见都列在白板上，然后逐项集中讨论，做出修正，直到大家的意见一致时为止。在共同远景的树立过程中，其实有两件事情也已经同时做了，项目范围（scope）和高阶（high-level）需求。
项目范围：项目该做什么，不该做什么，需要在一开始就有明确的定义。对于项目范围内的需求，一个也不要放过，而项目之外的，一个也不要去关心。虽然有的时候，范围的变化会有利于项目本身，例如客户的合理要求或是市场目标客户的变化，但是这种变化应该要在"资源能够支持"和"得到审批"的前提下进行。
项目范围的描述可以通过陈述和图示来进行。我建议大家使用图示。因为陈述语句比较含糊不清。例如常常听到有客户说，"我要建立我公司的电子商务系统。"这句话就是含糊不清的，你的电子商务系统是销售什么产品？面向什么客户？是否要支持在线支付？根据这些疑问，这个陈述句可以做进一步的修改，"建立在线订货系统，针对当前的目标客户销售公司的目前产品。"这样就清楚许多了。不过图示的方法会更好一些，在图的选择上，你可以使用数据流图（DFD图）或是用例图。根据经验，DFD图比较容易为客户所接受。
以固定资产管理系统为例，如图 1，图 2 所示：
图1 系统基本业务流程图:
通过对固定资产管理过程中涉及到的业务和要求的调查，得到新系统的业务流程图。固定资产卡片是保存固定资产信息的一种数据结构名称。
图2 根据系统流程图得到的DFD：
数据流程图是系统逻辑模型的主要组成部分，在逻辑上精确地描述了新系统的功能、输入、输出和数据存储。通过录入数据，处理数据，录入维修数据等操作来对固定资产卡片进行操作，将数据修改后存储到固定资产一览表中。在整个的DFD中实现了清楚描述项目范围。
高阶需求：这个部分我们在下面会详细讨论。既然是高阶需求，就不能讨论过多的细节。在讨论高阶需求的时候，尽量保证快速的讨论出系统的概貌，建立需求模型，得到项目涉众的一致通过。
取得支持：为了保证需求计划的顺利进行，取得项目涉众的支持至关重要。你可以选择在这个时候告诉项目涉众他们的权利和义务，以及开发人员的权利和义务。主要的就是"涉众有改变需求的权利，同时要承担向开发人员讲解需求的义务。"开发人员的权利和义务正好和涉众相反。
业务建模会议：所有的这一切都通过业务建模会议进行，和其它会议不同的是，这个会议需要所有的项目涉众参加，如果不能获取所有项目涉众的意见，那就不是完美的。会议中最重要的工具就是白板，一位出色的速记员也是必须的。
需求和业务建模
业务建模是需求工程中最初始的阶段，也是整个项目的初始阶段。需要指出的是，业务建模时间的跨度在不同的项目中有很大的差别的。在有些项目中，例如大型ERP系统，可能需要几个月的时间。而对于普通的项目，业务建模的时间可能仅仅需要几天的时间。
需求是技术无关（technology independent）的。在需求阶段讨论技术是没有任何意义的。那只会让你的注意力分散。技术的实现细节是在后面的分析、设计阶段才需要考虑的事情。而在业务建模阶段，不但要保证需求的技术无关性，还要保证你的需求不要深入细节。因为在业务建模阶段，最重要的事情就是要了解业务的全貌，深入细节会浪费时间和精力。要知道，讨论一个企业里的业务细节，就算给你一个月的时间也没必能够结束。
在实际中，这两点都是很难做到的。例如企业原先有一个系统，这就不得不由你讨论和新旧系统的兼容问题。这时候就要注意，如果你是讨论旧有系统的架构的话，那还是属于技术无关的范畴，如果你一旦进而讨论各具体模块/组件的细节，那就非但不是技术无关，而且也深入技术细节了。在不深入细节的问题上，往往你很难禁止项目涉众（Stakeholder）不去讨论一些相关的业务细节。这个时候你可以将这些细节记录下来，然后再回到业务建模上。
业务建模中的用例
在RUP中，有多种的概念来支持用例的实现：业务主角（Business Actor）、业务实体（Business Entity）、业务用例（Business Use Case）、业务角色（Business Worker）、业务用例实例（Business Use-Case Instance）。为了能够比较清楚的展示出业务建模，我们采用了UP方法的代表――RUP。但在实际中，要视大家具体的情况而定，这里所讲到的概念，都是为了帮助大家理解建模过程，并不是让大家生搬硬套。
在对系统还丝毫不了解的时候，我们会把系统看成一个很大的黑盒，称之为业务域（Business Domain），把它的外部看成一个业务环境（business environment）。而那些在业务环境中和业务域有关系的人（也可能是物）就被称为业务主角（Business Actor）。在实际的例子中，我们可能会把信贷业务（注意不是信贷业务系统，这里是业务建模，系统还不存在）称为业务域。经过调查，我们发现平时和信贷业务打交道的有客户，实施项目的银行，外汇管理局，其他银行，信贷部门使用的其他系统，银行内部的其他部门，所以这些人（物）就是业务主角。业务主角的实例一般包括了客户、供应商、合作伙伴、潜在客户（"市场"）、当地政府、在业务中未建模部分工作的同事等。必须注意的是，业务主角表示特定类型的用户，而不是某一个具体的用户。一个角色可能会有很多实际用户担任，一个实际的用户也可能会担任很多的角色。
业务用例以及业务用例实例在RUP中的定义如下：
A business use-case instance is a sequence of actions performed in a business that produces a result of observable value to an individual actor of the business. A business use case defines a set of business use-case instances. A business use case has a name.
业务用例实例是在业务中执行的一系列动作，这些动作为业务的个体主角产生具有可见价值的结果。业务用例定义了一组业务用例实例。业务用例具有名称。
刚开始大家可能会对业务用例以及业务用例实例有所疑问。其实可以把他们看成基类和子类的关系。在一个企业中，具体的工作流程可能有很多，比如你去麦当劳，点汉堡和点薯条的工作流程就不同。众多的流程给需求的调查工作造成了一定的难度。即使是最古老的哲学也告诉我们，表面现象是复杂的，本质是简单的。为了简化需求工作，我们就把点汉堡和点薯条归纳为点餐。这样，点餐就是一个业务用例，而点汉堡、点薯条就是相对应的业务用例实例。
业务用例
业务角色和业务主角的概念也很容易让人摸不着头脑。其实看它们的英文会更容易理解它们的区别：Business Worker，Business Actor。Worker有工人的意思，而Actor有参与者的意思。所以它们的区别就是一个在内部，一个在外部。业务角色是实现业务用例的人，业务主角是和业务有关的人。例如，对银行的押汇业务而言，客户就是业务主角，他和业务有关。而押汇人员就是业务角色，因为他们是实现业务用例的人。在RUP中，二者定义如下：
A business worker represents a role or set of roles in the business. A business worker interacts with other workers and manipulates business entities while participating in business use-case realizations.
业务角色代表业务中的一个或一组角色。参与业务用例实现时，一个业务角色和其他角色进行交互，并操纵业务实体
A business actor represents a role played in relation to the business by someone or something in the business environment.
业务主角代表了与业务有关的角色，此角色由业务环境中的某个人或物来担任。
业务角色
业务主角
分辨业务角色和业务主角要看环境而定。当你开发企业的ERP系统时，部门的员工都属于业务角色，而你开发一个部门级的应用时，其他部门的员工可能属于业务主角。
业务实体，在一些文章中被称为商业对象（Business Object）。不论怎么叫，所表示的意义都是一样的。例如在银行信贷这个例子中，我们就涉及到很多业务实体：契约、单笔贷款、客户等。所以业务实体就是企业中那些很基本的要素。如果觉得银行押汇的例子不好理解。可以想象餐厅中的菜单、汉堡等都是业务实体。在RUP中，业务实体被定义为：
A business entity represents a "thing" handled or used by business workers.
业务实体代表业务角色处理或使用的"事物"。
业务实体
建立业务用例模型
业务用例模型（business use-case model），在RUP中定义为：
The business use-case model is a model of the business intended functions. The business use-case model is used as an essential input to identify roles and deliverables in the organization.
业务用例模型是说明业务预期功能的模型。作为一个核心输入模型，业务用例模型用于确定组织的各个角色和可交付工件。
从业务用例模型的定义可以看出，它是企业最核心，最概括的业务说明。它主要是由业务用例和业务主角构成的，其主要目的是说明客户和合作伙伴是如何开展业务的，它主要通过业务用例的方式描述业务。下图为RUP中业务用例模型的图示。
图3 业务用例模型
业务用例模型
从图中我们也可以很清楚的看出业务用例模型包括一组的业务用例
 。这是因为企业中的业务通常都会由多个的业务用例的多个实例构成。这些业务用例形成的企业工作流程可能会由业务主角
 所引发，也可能会由业务主角直接操作的业务用例
所引发。
业务规则（Business Rules）：业务规则是必须遵守的政策或条件的声明。（Business Rules are declarations of policy or conditions that must be satisfied.）
业务用例模型实际上就是企业经营业务的一种描述，为了建立完整、准确的企业用例模型，应该将注意力专注于企业的业务做了些什么事情，而不应该集中于如何做。虽然这样可能会导致一些业务用例相冲突、重复的情况，但是RUP的思想在于迭代，这项工作完全可以在接下去的迭代周期内完善。
业务用例模型是和企业业务最贴近的计算机模型。它的很多思想和企业日常经营如出一辙。在企业的日常活动中，业务的种类可能有很多种。在一些讲述ERP思想的文章中，通常会强调三类： 一种是和主营业务密切相关的工作，例如银行的营业部。一种是管理型的工作，例如公司的管理层，财务部门等。一种称为支持工作，例如系统管理、安全等。
业务模型同样可以使用这种分类。通过这种分类，可以更好的把握核心业务用例，为下一步的工作打好基础。
很多业务用例是由业务主角触发的，RUP中也把和业务主角有关联关系的业务用例称为核心业务用例（Core Business Use Case）。这强调了构建业务模型的目的是提供以用户为中心的服务。这也是我们建立业务用例的时候应该注意的。
在建立了基本的业务用例模型之后，对此模型进行精化是非常有必要的，这时候，在上一章中我们介绍的用例的扩展关系和使用关系就有了用武之地。除了这两种关系，还有一种新的关系。
在业务建模中使用关系
泛化关系（Generalization）：根据我的理解，可以把它看作我们比较熟悉的继承关系很相似的一种关系。Generalization一词含有一般化、概括的意思。它是一个相对抽象的词。虽然它和继承关系非常相似，但是它们在使用环境和产生目的方面都有相异之处。图 4 描述了四个业务实体之间的泛化关系：
在快餐店的业务中，可以将香鸡汉堡、麦香鱼汉堡或是吉士汉堡的业务实体抽象为汉堡这个较高层次的业务实体。这样在业务建模和分析的过程中可以通过汉堡这个业务实体来同意管理。
图 4 泛化关系实例
当你去麦当劳的时候，会选择麦香鸡汉堡、麦香鱼汉堡或是吉士汉堡。但是分别对这三种汉堡建立业务实体就非常没有意义。所以可以将它们概括为汉堡这个业务实体。同样的道理，企业的业务流程中也可以概括出一些共有的属性和行为。为了避免多次说明同一个工作流程，您可以将共有的行为放在一个单独的业务用例中。称为父用例，执行子用例的用例实例将遵循父用例的事件流，同时插入附加行为或修改在子用例事件流中定义的行为。
方法的选择
以上的原理我采用了UP的方法。但是除了UP方法，还有XP、FDD等方法。所以在做业务建模的时候，也要根据不同的方法选择适当的工件。例如素材和功能。方法的好坏并不是我们这片文章讨论的重点。再一次需要强调的是，上面讨论的RUP的工件只是为了学习，所以才定义了比较复杂的工件，区分了它们之间的区别。但是在实际中，并不需要这么多的工件，那只会使你的项目涉众和开发人员糊涂。这些工件的区别只要在你心中就可以了。
业务建模的原则（Principle）
1. 谁才是"上帝"
我们说客户是上帝，是因为客户的重要性，客户占有决定性的地位。可是在软件开发中，到底是谁有决定权呢？是出资方，项目经理，还是程序员？
职责不清，是业务建模失败的主要原因之一。我们可以很容易的看见客户把自己的要求用几句话高度浓缩之后扔给开发人员，或是开发人员按照自己的意思开发程序。难道说，客户和开发人员之间真的是"心有灵犀"，完全不用沟通的吗。
在前文中已经提到过项目涉众和开发人员的权利和义务，我想这里还有必要再次强调。Scott W. Ambler说：
it is the role of project stakeholders to provide requirements, it is the role of developers to understand and implement them.
2. 耐心是首要的
明白了谁是"上帝"，那就要耐心的对待上帝。学理工科的人，一般在逻辑思维上会比较好，可是对于涉众来说，可不一定是这样。我就遇到过一位做档案工作的涉众，在了解需求的时候，扯东扯西，含糊不清。明明一分钟前才否定的方法，下一分钟又提出来了。我觉得我的脾气应该是不错的，可到最后也几乎发飚。所幸，最后我终于撑了下来。我想，在经历过这件事情之后，我的耐心指数又会有一个很大的提高了吧。
3. 参与是重要的
XP方法的一个重要实践，就是提倡"现场客户"（on-site customer）。也就是说，客户应该随时和开发人员在一起，随时提供资料和做出决策。而这个客户，也必须是领域专家，而且能够有权做出决策。
4. 拥抱变化
必要的需求变更管理是重要的。因为无休止、无控制的变化必然会造成资源的极大浪费。但从另一方面说，需求变更被接受的评判标准应该是"是否合理"，而不是"是否易于实现"。
需求变更要求我们的开发工作要迭代式进行，包括需求、设计、实现等阶段。这样才能将变更风险减到最小。这一点我们在讨论具体需求建模的时候会进一步讨论。
拥抱变化的更高一个层次是提前预估变化。制定一个可能的变化清单来记录可能出现的变化。最简单的例子就是一个企业在开发了进销存系统之后又希望能够开发财会系统与之相连。
业务建模的实践（Practice）
建模会议
会议是一种相当有效的沟通（Communication）手段。建模会议是一种大范围的会议，换句话说，所有的相关人员都应该参加会议。因为在业务建模时期，主要的目的就是建立对系统的高阶需求，这就要求众多项目涉众的共同参与，以保证需求的广泛性。出资方、高级经理、经理、直接用户、开发人员，各方各面的人都应该参加或是派代表参加建模会议。下面给出建模的主要因素：
业务实体
业务实体（business entity）是企业中的一些起到关键作用的类别。客户、供应商、员工、订单、凭证，这种业务实体的例子可以举出很多很多。业务实体往往会成为一个很关键的因素，因为在系统中，角色操作业务实体的行为往往会分配给业务实体，例如"根据订单计算价格"会成为订单的一个行为。这样，工作流程的实现往往是多个业务实体相互合作完成的。所以业务实体设计的好坏会对系统有很大的影响作用。
业务实体设计的主要工作包括找出业务实体，确定业务实体的属性和行为。
在一个人力资源管理系统中，员工类可能是非常重要的一个业务实体，它可能有非常多的属性。而在其它的系统中，例如进销存，员工类只是起到一个记录、权限管理的作用罢了。再比如，在一些企业内部的自动化处理系统中，客户可能只是其它一些实体的属性，而以客户为中心的设计大行其道的现在，这种设计就有它的致命缺陷。
要确定业务实体的属性和行为，主要是要确定每个类（业务实体）要做的事情，属性则是为了能够更好的描述类和类要做的事情。利用CRC卡片是一个不错的办法。
CRC是"类"（class），"责任"（responsibility）及"辅助者"（collaborator）三者的简称，这些资料常呈现在一张卡片上。
类名称
责任1 责任1的辅助者1
责任2 责任2的辅助者2
图 5 CRC卡片结构：
分别是类名称，责任，辅助者。
图 6 学生类的CRC卡片：
类名称：Student
每个业务实体的行为（责任）：Address地址，Phone number电话号码 等信息。
属性（辅助者）：Seminar 研讨小组。
通过制作这样的CRC卡片，可以比较容易的找出每个业务实体的行为（责任）和属性（辅助者）。您可能会问，为什么不直接找出属性和行为，而要多此一举呢。这个问题是我们一直在强调的。在建模阶段，我们面对的是可能对计算机技术完全不懂的涉众，所以，采用大家易于接受的方法，可以够保证需求的完整和正确。
准备计划
目前在软件开发中，关于计划有两个极端的误解。
在有些软件组织中，一般不做计划，或是做一些笼统的、没什么用处的计划。一些开发人员认为，"做计划是虚的，还不如做些实际的事"。而在另外一些组织中，计划被视为重中之重，需要花费大量的时间、人力，做出来的计划可谓事无巨细，算无遗策。而写的出这种计划的项目经理也被视为高级人才。开发人员叹口气说，"写程序的不如写文档的"，可是在执行的时候，原来精密的计划往往漏洞百出，项目的进度一拖再拖。我们所有人都知道那句名言：在软件开发中，要花90%的时间完成90%的项目，然后再用90%的时间完成剩下的10%的项目。为什么呢？计划不科学。
有人说，计划没有变化快。这句话说得很对，它提醒我们，没有计划是不行的，不具备可执行性的计划也是不行的。计划不是拿来炫耀的，是要用来执行的。我们定计划的时候，可以没有华丽的词藻，美好的构想。但是我们不能没有一些要素：
-
什么(WHAT)：按顺序列出达到目标所需完成的工作；
-
何时(WHEN)：完成工作所需要的时间；
-
做到的程度(HOW-WELL)：要完成的工作以何标准来度量；
-
资源(RESOURCES)：完成工作需要的人员/资金等；
-
谁(WHO)：由谁负责完成任务。
但是我们仍然逃不开现实和计划相背离的问题。我们虽然对预计一年后的事情把握不大，对开发人员在想什么把握也不大。但是如果想想自己两个星期后的事情应该还是能够猜的八九不离十吧。这就引出了迭代的概念。一个项目由几个甚至几十个迭代周期组成，每个迭代周期都是比较容易估算并制定计划的。
结束语
本文详细的描述了业务建模的领域，业务建模的目的，业务建模的主要任务，并且详细的介绍了如何确立业务建模的过程中的建模，业务实体，准备计划的确立。本文对于利用管理学模式提高建模质量以后部分的理解有重要的作用。
参考资料
作者简介  | | | 张蕴是西北工业大学计算机学院在读博士，研究方向为智能决策支持系统，曾于西北工业大学计算机学院攻读硕士学位，所研究方向为软件工程与网络软件，现于西北工业大学计算机学院智能决策教研室工作和学习，对网格计算有关技术有着浓厚兴趣，深入研究互联网分布式计算的过程。 |
| | | 陈洋毕业于中国科学与技术大学，软件系统设计专业硕士。目前在SPSS西安研究院PES(Predictive Enterprise Management )Team 从事PES platform的开发与实现。从事过供应链过程建模的分析和实现以及网格计算中多个CLUSTER中数据的收集，分析，处理，存储过程的研究和开发过程。Chen Yang 对领先思想和创建新产品及服务有着浓厚的兴趣，对IBM 电子商务模式中 Electric Business Model 有所学习，并且有很高的兴趣。 |
对本文的评价
| 
