业务建模时期(上)

业务建模时期（上）

　　有非常重要的意义。不同的人、不同的方法对这项工作有不同的描述，在我们的文章中，根据UP的思想，称之为"业务建模".所有的项目都有业务建模时期1. 业务建模是什么业务建模（BusinessModeling），业务建模是一个复杂的过程，对其下一个准确的定义是困难的事情。在RUP的词汇表中将其解释为："包含您可用来对业务进行可视化建模的所有建模方法。这些是您可用于执行业务工程的方法的子集。"从定义中可以看出，它是一种建模方法的集合，目的是对业务进行建模。这方面的工作可能包括了对业务流程建模，对业务组织建模，改进业务流程，领域建模等方面。
　
　　2. 为什么要业务建模Brooks 大师说，三十多年来各式各样的应用系统（Application Programs AP）历经多次的修修改改，已经变得面目全非，如同一群的怪兽，难以驯服。
　
　　Rogerson大师也说，The application is a rock in the river of change.（应用（系统）成为改变之潮流中的顽石）。
　
　　对很多企业而言，有一个统合企业各部门的信息系统的心愿似乎已经成了一种奢望。企业中或多或少都会有一些应用系统在辅助企业的自动化运作，当企业信息主管希望能够对目前的信息系统进行整合，能够配合企业的发展的时候，他们失望了。大多数的应用缺乏一个统一的接口，难以进行整合。
　
　　在我们进行项目开发的银行中，我们也同样发现了这个问题，不同部门的系统之间无法进行互联，跨部门的业务流程必须经过手工的处理。
　
　　以前，应用程序的开发都是基于部门的功能的而建的。单纯只是为了解决目的而建立应用系统。所以这种方式建立的应用系统是针对特定的功能区域（FunctionArea）而建立的。至于如何使企业内的多个应用系统共同运作，就不在设计者的考虑之列了。随着企业的发展，就会发现企业需要变化以适应市场变化，业务发展的时候，原有的一系列应用系统却成了企业发展的拦路虎，这使得企业不得不回到手工的时代。
　
　　针对这种情况，有没有相应的解决之道呢？解决的方法就是从业务建模入手，而不是从较低层次（部门级或以下）入手。通过用例分析技术，建立企业的业务模型，进行适当的切割，选取稳定的软件架构，分析出企业的业务实体（Business Entity企业中微小不可分的事物，抽象或具体的，如帐户，契约等，又被称为BusinessObject），以此为基础，组装出组件（Component），落实到相应的三层结构，建立针对特定功能区域的应用系统。
　
　　以这样的流程做出来的企业应用系统，不论规模是部门级的，还是企业级的，都有扩展的余地。以组件为基础的软件三层构架，也能够较好的配合企业的业务变化而变化（相应变化的代价较小）。而整个流程的第一步，就是业务建模。
　
　　在前一段时间，中国很流行企业流程再造BPR（Business ProcessRe-engineering）这个名词。BPR这一名词中的R（Re-engineering）一词是由Dr.Hammer提出，说明企业必须推动四个层面的重新设计：Re-position、Re-organization、Re-system、Re-vitalizing之再造工程；名称中的P（Process），更是管理上由销售、采购到财务、生产各层次，力求降低成本、提高产出，所必须精密设计的企业管理流程或程序。这个词目前都是和ERP串联在一起，成了ERP的前置工程，更成为保证ERP能建立企业完美管理体系，以支持高绩效的最重要因素。实际上呢，这个BPR就是我们所谈到的业务建模。
　
　　可以看出，业务建模在ERP工程中被着重强调，而且ERP中的BPR已经成为一门独立的学科。不仅如此，即便是在普通的信息系统中，业务建模也是非常重要的，所不同的，仅仅是它们的规模而已。这一点上，可能大家会不理解，如果你只是为企业的业务自动化建立应用，直接照搬企业模式不就行了吗。这里有两点原因，一是企业原有的业务模式在以人为主的环境中可能运行的很好，可是把这套模式原本不动的搬到计算机上就未必会适合了。人的能力和计算机的能力有很大的出入，所以流程必须经过调整以适应计算机；第二个原因是上面已经提到过的避免产生部门级的，部分功能区域的应用系统。
　
　　在RUP中，业务建模被作为下游流程的输入重点强调：业务模型是需求工作流程的一种重要输入，用来了解对系统的需求。业务实体是分析设计工作流程的一种输入，用来确定设计模型中的实体类。（RUP）
　
　　3. 需求和业务建模业务建模是需求工程中最初始的阶段，也是整个项目的初始阶段。需要指出的是，业务建模时间的跨度在不同的项目中有很大的差别的。在有些项目中，例如大型ERP系统，可能需要几个月的时间。而对于普通的项目，业务建模的时间可能仅仅需要几天的时间。
　
　　需求是技术无关（technology independent）的。在需求阶段讨论技术是没有任何意义的。那只会让你的注意力分散。技术的实现细节是在后面的分析、设计阶段才需要考虑的事情。而在业务建模阶段，不但要保证需求的技术无关性，还要保证你的需求不要深入细节。因为在业务建模阶段，最重要的事情就是要了解业务的全貌，深入细节会浪费时间和精力。要知道，讨论一个企业里的业务细节，就算给你一个月的时间也没必能够结束。
　
　　在实际中，这两点都是很难做到的。例如企业原先有一个系统，这就不得不由你讨论和新旧系统的兼容问题。这时候就要注意，如果你是讨论就有系统的架构的话，那还是属于技术无关的范畴，如果你一旦进而讨论各具体模块/组件的细节，那就非但不是技术无关，而且也深入细节了。在不深入细节的问题上，往往你很难禁止项目涉众（Stakeholder）①不去讨论一些相关的业务细节。这个时候你可以将这些细节记录下来，然后再回到业务建模上。
　
　　①A stakeholder is defined as anyone who is materially affected by the outcome of the project.涉众是所有会受到项目结果重大影响的人。
　
　　4.业务建模时期的主要任务项目涉众的共同愿景：要想项目成功，可离不开项目涉众的支持。在项目一开始，不论是项目涉众还是开发人员，对项目的任务、范围都是模糊不清的。但随着项目的深入，原来模糊的景象会慢慢清晰、立体起来。但是为了不浪费时间，我们有必要在项目射入之前，现在项目涉众中竖立一个共同的愿景。
　
　　共同愿景的竖立可没有想象中的那么简单，因为每位涉众都关心自己的利益，都有自己的评判标准。你可以把大家的意见都列在白板上，然后逐项集中讨论，做出修正，直到大家的意见一致的时候为止。在共同远景的竖立过程中，其实有两件事情也已经同时做了，项目范围（scope）和高阶（high-level）需求。
　
　　项目范围：项目该做什么，不该做什么，需要在一开始就有明确的定义。对于项目范围内的需求，一个也不要放过，而项目之外的，一个也不要去关心。虽然有的时候，范围的变化会有利于项目本身，例如客户的合理要求或是市场目标客户的变化，但是这种变化应该要在"资源能够支持"和"得到审批"的前提下进行。
　
　　项目范围的描述可以通过陈述和图示来进行。我建议大家使用图示。因为陈述语句比较含糊不清。例如常常听到有客户说。"我要建立我公司的电子商务系统。"这句话就是含糊不清的，你的电子商务系统是销售什么产品？面向什么客户？是否要支持在线支付？根据这些疑问，这个陈述句可以做进一步的修改，"建立在线订货系统，针对当前的目标客户销售公司的目前产品。"这样就清楚许多了。不过图示的方法会更好一些，在图的选择上，你可以使用DFD图或是用例图。根据经验，DFD图比较容易为客户所接受。
　
　　高阶需求：这个部分我们在下面会详细讨论。既然是高阶需求，就不能讨论过多的细节。在讨论高阶需求的时候，尽量保证快速的讨论出系统的概貌，建立需求模型，得到项目涉众的一致通过。
　
　　取得支持：为了保证需求计划的顺利进行，取得项目涉众的支持至关重要。你可以选择在这个时候告诉项目涉众他们的权利和义务，以及开发人员的权利和义务。在这个方面，具体的我不想多说，大家可以参考「软件需求」的第二章。主要的就是"涉众有改变需求的权利，同时要承担向开发人员讲解需求的义务。"开发人员的权利和义务正好和涉众相反。
　
　　业务建模会议：所有的这一切都通过业务建模会议进行，和其它会议不同的是，这个会议需要所有的项目涉众参加，如果不能获取所有项目涉众的意见，那就不是完美的。会议中最重要的工具就是白板，一位出色的速记员也是必须的。
　
　　建模原理5.业务建模中的用例在上一篇中我们讨论了很多用例的知识，可是落实到企业中的时候，我们往往会感觉难以把握企业的用例，这一点我们在用例的误区中也有提到。在实际的情况中，你可能会对角色的归类，用例的划分，粒度的把握等很细节的方面都没有底，偏偏这些实际的东西对你的项目有非常大的影响。
　
　　RUP中，有多种的概念来支持用例的实现：业务主角（Business Actor）、业务实体（BusinessEntity）、业务用例（Business Use Case）、业务角色（Business Worker）、业务用例实例（BusinessUse-CaseInstance）。为了能够比较清楚的展示出业务建模，我们采用了UP方法的代表――RUP.但在实际中，要视大家具体的情况而定，这里所讲到的概念，都是为了帮助大家理解建模过程，并不是让大家生搬硬套。
　
　　在我们对系统还丝毫不了解的时候，我们就会把系统看成一个很大很大的黑盒，这个大黑盒子我们会叫他业务域（Business Domain），把它的外部看成一个业务环境（businessenvironment）。而那些在业务环境中和业务域有关系的人（也可能是物）就被称为业务主角（BusinessActor）。在实际的例子中，我们可能会把信贷业务（注意不是信贷业务系统，这里是业务建模，系统还不存在。）称为业务域，我们经过调查，发现平时和信贷业务打交道的有客户，人民银行，外汇管理局，其他银行，信贷部门使用的其他系统，银行内部的其他部门。所以这些人（物）就是业务主角。业务主角的实例一般包括了客户、供应商、合作伙伴、潜在客户（"市场"）、当地政府、在业务中未建模部分工作的同事等。必须注意的是，业务主角表示的特定类型的用户，而不是某一个具体的用户。一个角色可能会有很多实际用户担任，一个实际的用户也可能会担任很多的角色。
　
　　业务用例以及业务用例实例在RUP中的定义如下：A businessuse-case instance is a sequence of actions performed in a business thatproduces a result of observable value to an individual actor of thebusiness. A business use case defines a set of business use-caseinstances. A business use case has aname.业务用例实例是在业务中执行的一系列动作，这些动作为业务的个体主角产生具有可见价值的结果。业务用例定义了一组业务用例实例。业务用例具有名称。
　
　　刚开始大家可能会对业务用例以及业务用例实例有所疑问。其实可以把他们看成基类和子类的关系。在一个企业中，具体的工作流程可能有很多很多，比如你去麦当劳的时候，点汉堡和点薯条的工作流程就不一样。众多的流程给需求的调查工作造成了一定的难度。即使是最古老的哲学也告诉我们，表面现象是复杂的，本质是简单的。为了简化需求工作，我们就把点汉堡和点薯条归纳为点餐。这样，点餐就是一个业务用例，而点汉堡、点薯条就是相对应的业务用例实例。
　在大规模的需求调研展开之前，有一个重要的工作要做。这项工作在项目中所占的时间跨度非常的小，但是却

业务用例

业务角色