六、业务建模中的用例

　　在上一篇中我们讨论了很多用例的知识，可是落实到企业中的时候，我们往往会感觉难以把握企业的用例，这一点我们在用例的误区中也有提到。在实际的情况中，你可能会对角色的归类，用例的划分，粒度的把握等很细节的方面都没有底，偏偏这些实际的东西对你的项目有非常大的影响。

　　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.

　　业务实体代表业务角色处理或使用的"事物"。

业务实体

　　在很早以前，我们讨论过需求易变性。相对于需求的不断变化，可是业务实体对象在一段相当长的时间内都存在。航空公司今天打折，明天又不打，还有明折、暗折。可是机票从来没见有什么大的变化，从来也只有那几样属性：价格、航班、出发地、目的地。所以业务实体是比较稳定的。这对于我们是有很大的意义的：

　　"一个业务实体经常代表某个对多个业务用例或用例实例有价值的事物，因此，业务实体对象的生存期相当长。一般而言，一个好的业务实体不包含关于其使用主体和使用方法的信息。"（RUP）

　　由业务实体组成的业务用例会稳定很多。在以前，开发方式采用模块为基础的方法，需求变化的时候，只好改写模块。如果采用稳定的业务实体来实现业务用例的话，业务用例的改变只需要对业务实体进行重新的组合。当然，这里还需要很多的技术来实现，并没有那么简单。要知道，四个现代化可不是一天就能够实现的。

　　还有一个使用业务实体的重要原因：业务实体的特性决定它具有天生的重用性。就像麦当劳的销售系统中有汉堡实体，生产系统中也有，供应链系统中也有。天哪，这世界真是美好！

　　使用业务实体一个很大的困惑是应该把它做为类还是属性。这个取决于业务环境对这个实体的重视程度。一个客户在银行信贷部门是一个很重要的类，而在押汇部门就只是信用证实例的一个属性。这个问题非常的重要。设计时的失误可能会导致今后系统改进的极大痛苦。例如本该设计为类的业务实体设计成了属性，在今后增加属性的时候不得不面对着数据库的调整和系统的修改。

　　6. 建立业务用例模型

　　业务用例模型（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中业务用例模型的图示。

业务用例模型

　　从图中我们也可以很清楚的看出业务用例模型包括一组的业务用例。这是因为企业中的业务通常都会由多个的业务用例的多个实例构成。这些业务用例形成的企业工作流程可能会由业务主角所引发，也可能会由业务规则②所引发。

　　②业务规则（Business Rules）：业务规则是必须遵守的政策或条件的声明。（Business Rules are declarations of policy or conditions that must be satisfied.）

　　业务用例模型实际上就是企业经营业务的一种描述，为了建立完整、准确的企业用例模型，应该将注意力专注于企业的业务做了些什么事情，而不应该集中于如何做。虽然这样可能会产生一些业务用例相冲突，相重复的情况，但是RUP的思想在于迭代，这项工作完全可以在接下去的迭代周期内完善。

　　业务用例模型是和企业业务最贴近的计算机模型。它的很多思想和企业日常经营如出一辙。在企业的日常活动中，业务的种类可能有很多种。在一些讲述ERP思想的文章中，通常会强调三类：

　　一种是和主营业务密切相关的工作，例如银行的营业部、信贷部、押汇部等。这种工作通过人的劳动，将一种资源转变为另一种资源，产生价值。

　　一种是管理型的工作，例如公司的管理层，财务部门等。这种工作本身并不产生价值，但是它通过指导、管理、检测第一种工作，加大第一种工作的产出价值。

　　还有一种称为支持工作，例如系统管理、安全等。它并不是很重要，具有支持其他工作的性质。

　　业务模型同样可以使用这种分类。通过这种分类，可以更好的把握核心业务用例，为下一步的工作打好基础。

　　有很多业务用例是由业务主角触发的，RUP中也把和业务主角有关联关系的业务用例称为核心业务用例（Core Business Use Case）。这强调了构建业务模型的目的是为了提供以用户为中心的服务。这也是我们建立业务用例的时候应该注意的。

　　当然，有时候业务用例的触发是为了产生用户需要的结果。例如企业的市场调查行为就不是由业务主角触发，而是企业积累了大量用户请求的结果。而对于管理型、支持型的，不直接和业务主角的客户类发生联系，但是也有其特定的业务主角，如管理型的业务用例需要和董事会为发生联系，支持型的业务用例可能和供应商发生联系。

　　在建立了基本的业务用例模型之后，对此模型进行精化是非常有必要的，这时候，在上一章中我们介绍的用例的扩展关系和使用关系就有了用武之地。除了这两种关系，还有一种新的关系。

　　7. 在业务建模中使用关系

　　泛化关系（Generalization）：根据我的理解，可以把它看作我们比较熟悉的继承关系很相似的一种关系。Generalization一词含有一般化、概括的意思。它是一个相对抽象的词。虽然它和继承关系非常相似，但是它们在使用环境和产生目的方面都有相异之处。下图描述了四个业务实体之间的泛化关系：

　　当你去麦当劳的时候（不要误会，我并不是很经常去的），会选择麦香鸡汉堡、麦香鱼汉堡或是吉士汉堡。但是分别对这三种汉堡建立业务实体就非常没有意义。所以可以将它们概括为汉堡这个业务实体。同样的道理，企业的业务流程中也可以概括出一些共有的属性和行为。为了避免多次说明同一个工作流程，您可以将共有的行为放在一个单独的业务用例中。称为父用例，执行子用例的用例实例将遵循父用例的事件流，同时插入附加行为或修改在子用例事件流中定义的行为。

　　8. 方法的选择

　　以上的原理我采用了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）。也就是说，客户应该随时和开发人员在一起，随时提供资料和做出决策。而这个客户，也必须领域专家，而且能够有权做出决策。

　　这种现场客户相信国内的软件组织多半还做不到。但是一定要往这方面努力。我认为，这种现场客户有两种人：一种是项目涉众，还有一种是行业专家。其实很多软件公司都会配备一些管理咨询人员，这些人就是行业专家。有数据统计说，目前广东省软件公司中的咨询人员和开发人员的比例达到了3：1。我觉得这是好事。项目涉众往往对自己的工作中的事务性部分有很深的认识，但是很难将之提升到一个理论的水平。这时候就需要一些行业专家来帮助了。让行业专家和项目涉众共同探讨，还能够激发项目涉众的灵感，想到原来他想不到的方面。这就是"潜在需求"的开发。

　　另一方面，参与还意味着需要项目涉众全身心的投入到业务建模的过程中来，要能够调动他们的积极性。因此呢，太复杂的流程会阻碍涉众的参与。所以，使用一些简单的、能够为客户所接受的工件（Artifact）来进行业务建模是很有必要的。我说过前面讨论的那些"主角"啊，"用例"啊，那是理论，是给开发人员看的，让开发人员心里有个底。你给涉众看这些，他们能懂吗？等他们了解了这套机制，恐怕黄花菜都凉了吧。

　　素材（User Story）、特性（Feature）、CRC卡片这些都是很不错的工件，既简单，又能够满足需要。

　　知识点：素材和特性都表述了用户的一个简单的要求，它能够在较短的时间内完成。素材是XP方法中的工件，特性是FDD方法中的工件。CRC是class、 responsibility、collaborator的缩写，它是一张分为三个部分的卡片，分别标记了类名，类的责任，以及类之间的合作关系。非常的贴近客户，甚至可以在做游戏的过程中完成卡片的填写，能带来很强的客户参与度。

　　4. 拥抱变化

　　我想这一点会遭到开发人员点一致指责。毕竟，需求变化是开发人员最讨厌的一件事了。不错，我也讨厌。可是，就像我们常说"哭不能解决问题"一样，讨厌能解决问题吗？拒绝客户的变更要求，要求客户在需求规格说明书上签字。这些做法只能是适得其反。没有任何正面的、积极的意义。

　　必要的需求变更管理是重要的。因为无休止、无控制的变化必然会造成资源的极大浪费。但从另一方面说，需求变更被接受的评判标准应该是"是否合理"，而不是"是否易于实现"。

　　需求变更要求我们的开发工作要迭代式进行，包括需求、设计、实现等阶段。这样才能将变更风险减到最小。这一点我们在讨论具体需求建模的时候会进一步讨论。

　　拥抱变化的更高一个层次是提前预估变化。制定一个可能的变化清单来记录可能出现的变化。最简单的例子就是一个企业在开发了进销存系统之后又希望能够开发财会系统与之相连。如果你能够预先留下伏笔，相信能够省不少力气。预估变化的另一种做法是通过使用模式。但是切记，模式的使用也不能过头。这些是题外话，如果有机会我会在其他的文章中集中讨论这方面的问题。

七、业务建模的实践（Practice）

　　5. 建模会议

　　会议是业务建模最重要的手段。尽管会议在中国总是背负着一些骂名，但是只要组织得好，它是一种相当有效的沟通（Communication）手段。建模会议是一种大范围的会议，换句话说，所有的相关人员都应该参加会议。因为在业务建模时期，主要的目的就是建立对系统的高阶需求，这就要求众多项目涉众的共同参与，以保证需求的广泛性。所以呢，建模会议的规模是相当大的。出资方、高级经理、经理、直接用户、开发人员，各方各面的人都应该参加或是派代表参加建模会议。

　　如果大家有过参加大型会议的经验都知道，越是大型的会议，它的决策效率就越低。这是正常的。因为一个人的时候，不需要沟通，决策效率最高。等到两个人的时候，他们需要沟通的时间来进行决策。等到三个人的时候，这个沟通并达成一致的时间就更长。如果人数到了四个人、五个人甚至一二十个人，那么大部分的时间都会花在沟通上。更何况，人和人之间还有观念不同、利益之争。所以呢，为了保证会议的效率和效果，应该遵循一定的规则：

　　·做好准备：如果你要开会，与会者连内容都不清楚，那你会怎么办。你必须首先花很多的时间来说明你开会的目的，是不是。要事先将会议的主题、议程连同会议通知发送给与会者，让他们先有个准备，会议开始时就能够迅速进入正题。

　　·尽量邀请最多的人：我已经说过，如果建模会议不能够听取最广泛的意见，它就不是一个成功的会议。可是在现实中，这点往往难以做到。因为目标组织做为客户，往往都很"拽"，在没有充分认识会议的重要性之前，要做到全部到场简直就是不可能。而客观上也会有出差、休假、有要事等原因做不到这一点。这里，一方面你需要向目标组织的决策者阐明利害，让他们重视。另一方面，你也需要积极主动的邀请项目涉众参与。因为邀请所有的人是不可能的，所以就尽可能的多吧。

　　·分出与会者的级别：我很喜欢那种有一个内圈、一个外圈的会议室。因为我邀请所有人是件无法做到的事情，所以我首先要保证核心人员能够全部到场，坐在内圈，然后才是次要的人员，坐在外圈。核心人员是和你的项目息息相关的那种人。比如，财务系统，财务主管就是核心人员。要保证核心人员全员到场，至于次要人员，越全越好。

　　·从底层开始：中国人有个比较不好的习惯，就是老板说一的时候，他决不会说二。所以要先让底层先说话，然后才轮到中层，再到上层。开发人员是不说话的，他们要么听，要么引导大家说话。如果我们一开始就先让领导来训话一番，那底层的人也就不用再说什么了。

　　·列举所有涉众的所有观点：首先要让大家能够对新的系统畅所欲言，然后把所有的观点都罗列在白板上。这里头可能会有一些观点会是非常荒唐的，但没有关系，尽管写上去。这是一个脑力激荡的过程，很容易产生出新的idea。主持的开发人员的主要工作就是引导和鼓励大家说出更多的想法，并记录下来。这里我们稍微离题一下，有人说中国人在会议上大都不愿意发表意见，我看在这种建模会议上不必过于担心此事。为什么呢，因为项目涉众不需要为他们的发言担任何的责任，说了，白说，白说谁不说。

　　·将观点分类：想必你的项目涉众已经有些累了，创意也差不多了，你的白板估计也满了。但是你看看白板上的观点，有很多是重复的，有很多是类似的。所以你需要用逻辑的观念将这些观点归类整理。这个工作也可以由你引导大家去做。

　　·确定优先级：对观点排出优先级也是非常重要的，它能够帮助你识别出重大的风险，并为你在制定迭代计划时提供指导。同样，这项工作也应该由项目涉众来确定。

　　·调查主要业务逻辑：什么叫主要业务逻辑？包括了企业的主要业务流程、主要的业务规则、重大的算法。这些都是需要在一开始就十分明确的资料，需要在建模会议上了解清楚。当然，你不能对你的项目涉众说，"这个，接下来，大家谈一谈主要的业务逻辑吧。"下面的涉众一定摸不着头脑。你还是应该引导涉众，从涉众的话语中捕捉你需要的信息。

　　·注意会议时间：人不是机器，是会累的。所以控制好会议的长度很关键。一般，这种会议会有四五个小时，根据统计，两个小时内的会议不会让人产生疲劳感。所以应该把会议分成几小段。另外，你还可以根据会议的进展来决定每小段会议参与的人数。因为，会议越往后，一些与会者就不太重要了。

　　·避免细节：建模会议主要的目标是建立高阶需求。如果把过多的时间花在讨论鸡毛蒜皮的小事，那就会浪费大家的时间。而在此时调查需求细节是没有很大的意义的。因为你对很多的事情都还不了解，需要进一步的深入。这时候的细节对你并没有太多的帮助。

　　·回避技术：我在一次建模会议的时候，遇到一位负责技术的涉众，他总是不停的询问系统的技术架构，推销他的设计理念。使得我不得不好几次重申，"技术问题我们会单独找时间谈。"我想，那位技术人员应该是有比较好的理念，也很希望能够表现一把，这点无可厚非。但是这个时候还不是讨论技术的时候，需求尚未明确，讨论技术实现不是本末倒置么？

　　·做好记录：俗话说，好记性不如烂笔头。所以在会议上做好记录是非常关键的。因为这种会议的代价相当高昂，你的项目涉众不可能每天不干活，陪你开会的，就算他们肯，他们的老板也不肯。所以要充分利用好会议的成果，所以一个优秀的速记员绝对是必要的。另外，根据研究显示，如果使用录音机的话，会使得与会者心存芥蒂而不愿开口，所以，不要使用录音机。

　　6. 测试

　　在需求的初始阶段提到测试可能会觉得有些奇怪。凡是项目，总会有一个标准来考核是否成功。这里的测试指的是考核软件项目是否成功的一个"执行性目标"。

　　这个目标将会是软件开发最终要满足的条件，软件成功与否的判定标准。很多企业在信息化建设的时候没有一个比较明确的目标。所以在被问道这方面的问题时，他的答案往往是我的目标是建成企业的ERP系统，建设企业的信息化平台等空洞的话。这样的软件怎么开发？连结束的标准都没有。是费用用完结束呢，还是决策者说停就停了呢。目标应该有一个可以量化的标准。例如，开发物流系统的目的是为了缩短产品周转周期，降低库存；开发供应链系统是为了加强和供应商的联系，降低库存。这些和具体业务有关的指标都是可以通过细化，用多种分指标来度量的，所以是可以做到的。

　　我们把这种目标称为测试就是要提醒开发人员，要把满足这种目标当作最终的测试。你的软件做得再好，不是涉众想要的，又有什么用？这是很浅显的道理，可是在实际中，涉众方和开发方往往因为一些具体的因素看不到这一点。其实，这个目标在上一篇中我们也讲过，那时我们是把它叫做愿景、范围。在本质上是一样的。

　　这种"可执行性目标"可以使用一些因素来衡量：

　　7. 业务实体

　　业务实体（business entity）是企业中的一些起到关键作用的类别。客户、供应商、员工、订单、凭证，这种业务实体的例子可以举出很多很多。业务实体往往会成为一个很关键的因素，因为在系统中，角色操作业务实体的行为往往会分配给业务实体，例如"根据订单计算价格"会成为订单的一个行为。这样，工作流程的实现往往是多个业务实体相互合作完成的。所以业务实体设计的好坏会对系统有很大的影响作用。

　　业务实体设计的主要工作包括找出业务实体，确定业务实体的属性和行为。

　　要确定业务实体，首先必须确定角色，并从角色的行为找出业务实体。角色需要我们对目标组织进行讨论。以我个人的经验，寻找业务角色一般比较简单，但是要记住，一个人可能担任好几个的业务角色，这是经常发生的情况。从业务角色的行为，我们可以找出业务角色所处理的事物，这些就是我们所需要的业务实体。业务实体是一个单独的业务实体还是业务实体的一个属性是值得研究的。一个本该是属性的事物被判断成业务实体只是会带来一些开销，可是一个本该单独列出的业务实体却只是被判定为其它业务实体的一个属性就有可能会带来灾难性的后果，最大的可能是系统难以扩展。

　　在一个人力资源管理系统中，员工类可能是非常重要的一个业务实体，它可能有非常多的属性。而在其它的系统中，例如进销存，员工类只是起到一个记录、权限管理的作用罢了。再比如，在一些企业内部的自动化处理系统中，客户可能只是其它一些实体的属性，而以客户为中心的设计大行其道的现在，这种设计就有它的致命缺陷。

　　要确定业务实体的属性和行为，主要是要确定每个类（业务实体）要做的事情，属性则是为了能够更好的描述类和类要做的事情。利用CRC卡片是一个不错的办法。

　　CRC是"类"（class），"责任"（responsibility）及"辅助者"（collaborator）三者的简称，这些资料常呈现在一张卡片上。

　　　　类名称

　　　　责任1 责任1的辅助者1

　　　　责任2 责任2的辅助者2

　　　　　… 　　…

　　通过制作这样的CRC卡片，可以比较容易的找出每个业务实体的行为（责任）和属性（辅助者）。您可能会问，为什么不直接找出属性和行为，而要多此一举呢。这个问题是我们一直在强调的。在建模阶段，我们面对的是可能对计算机技术完全不懂的涉众，所以，采用大家易于接受的方法，可以够保证需求的完整和正确。

　　8. 准备计划

　　目前在软件开发中，关于计划有两个极端的误解。

　　在有些软件组织中，一般不做计划，或是做一些笼统的、没什么用处的计划。一些开发人员认为，"做计划是虚的，还不如做些实际的事。"对于项目经理，或是对这种情况没有办法，或是发布的计划开发人员阳奉阴违，让计划成为一纸空文。项目执行中随意性极大，偏离方向的事情时有发生。

　　而在另外一些组织中，计划被视为重中之重，需要花费大量的时间、人力，做出来的计划可谓事无巨细，算无遗策。而写的出这种计划的项目经理也被视为高级人才。开发人员叹口气说，"写程序的不如写文档的。"可是在执行的时候，原来精密的计划往往漏洞百出，项目的进度一拖再拖。

　　我们所有人都知道那句明言：在软件开发中，要花90%的时间完成90%的项目，然后再用90%的时间完成剩下的10%的项目。为什么呢？计划不科学。

　　在管理学中，计划，也有叫规划的，定义是"为组织确定目标、实现目标的战略与手段、步骤、程序的过程。"打个比方说，我想要把一个箱子推倒一个地方，这个地方就是我的目的，我为了到达那里，我是不是要估计一下按什么路线推，要推多快。然后我就开始推，还要不时的和原先的计划比较比较，需不需要调整路线和速度。这个估计就是计划。

　　计划的目标不是消除错误，而是让所有错误变成一堆经过细心规划后的小错误。研究四种设计方式后，最终放弃三种，最多不过是三个小错误而已，但因没有做好设计而将程序重写三遍，却可能造成三个大错误。

　　然而为什么会出现上面提到的两个极端呢？第一种情况其实是软件行业最早期的一种形态，没有计划，资源分配混乱，软件的开发过程处于混沌、无序、自发的状态。项目的成功全凭运气和项目成员的个人能力。而第二种情况其实一个前进了的形态，最典型的代表就是我们之前提到过的瀑布模型。那这种考虑周密的计划为什么也容易失败呢？很简单，你认为你考虑周密，可是实际上却不一定。我就见过标榜自己考虑周详的计划中排出的时间表是一周7天的。看来他一开始就没打算让开发人员休息了。计划是对未来的一种估计，哪一个人能够准确的说出6个月后的情况，恐怕没人能行吧。9月11号之前，有几个人能料到那天会发生这么大的事情？那你凭什么推算出半年，甚至一年后的事情呢？另外，你是不是真的非常了解你的开发人员，以至于有信心代替他们制定计划呢？

　　有人说，计划没有变化快。这句话说得很对，它提醒我们，没有计划是不行的，不具备可执行性的计划也是不行的。计划不是拿来炫耀的，是要用来执行的。我们定计划的时候，可以没有华丽的词藻，美好的构想。但是我们不能没有一些要素：

　　·什么(WHAT)：按顺序列出达到目标所需完成的工作；

　　·何时(WHEN)：完成工作所需要的时间；

　　·做到的程度(HOW-WELL)：要完成的工作以何标准来度量；

　　·资源(RESOURCES)：完成工作需要的人员/资金等；

　　·谁(WHO)：由谁负责完成任务。

　　但是我们仍然逃不开现实和计划的背离的问题。我们虽然对预计一年后的事情把握不大，对把握开发人员在想什么把握也不大。但是如果你自己想想自己两个星期后的事情应该还是能够猜的八九不离十吧。这就引出了迭代的概念。一个项目由几个甚至几十个的迭代周期组成，每个迭代周期都是比较容易估算并制定计划的。这就是迭代的思想，也是软件工程技术的一个大飞跃。说到这里，我又要吊大家的胃口了。关于具体制定迭代计划的讨论，我们会留到下一章节讨论细节需求建模的时候再谈。

　　9. 培训

　　我很难想象一个项目没有培训该如何进行。兵书有云，"三军未动，粮草先行。"我们可以理解为事先做好充分的准备。项目也是一样，在一开始就要指定好培训的计划，留出培训的时间。我想，除非是一个非常完美的团队，否则他的成员一定也还是有不懂的东西吧，如果没有培训计划，把学习的任务推倒个人头上，项目的风险就会变得难以控制。

　　说起培训，大家可能就会认为是大家正儿八经的坐在那里，听一位老师上课。并不是这样的，这里说的培训是一个广义范围的培训，达到一组课程、一次会议，小到一次讨论、一次交流，都可以是培训。而其目的，就是为了让团队成员拥有足够的知识和技能，来完成项目。