业务建模之一：业务分析

“业务要求”似乎是IT程序员永远无法越过的一道坎，轻飘飘一句“不满足业务要求”，足以让你从云端自由落体；“业务逻辑”是IT程序员心中无法言及的痛，它总是那么“蛮横得不讲道理”。如果让程序员评选“最不合逻辑的逻辑”，结果一定会是业务逻辑。当“不满足业务要求”，或者“不符合业务逻辑” 时，年轻的程序员总会弱弱地问“能不能就这样”，大抵是让业务迁就程序，结果自然不断碰壁。业务员乐此不疲，程序员伤心不已。

业务是什么？业是指工作岗位，务是指事情，合在一起是工作岗位上的事情。我觉得业务的含义就是完成一项具体的工作，会涉及人员分工、工作步骤、时限要求、工作成果、验收标准等潜在的属性。比如上市公司研究业务，就是股票研究员按一定的上市公司估值方法，在规定的时间内给出研究报告及投资建议，并接受公司的考核。业务分析的过程其实就是找全业务的属性并赋值的过程，每个业务点都可以套用5W1H、脑图等方法进行析构，复杂业务可以采用分类等方法进行简化。这项工作做得越细致，分析就越透彻。

业务分析

业务分析是业务建模的基础，它的首要成果应该是分析出业务中涉及的主体，有抽象的，也有具体的。这些主体的概念一经明确，就具有了活力，有特征、有行为、有生命，所以需要反复推敲。我一般套用数据库中的概念，称之为概念模型。业务建模领域有些成熟的方法论：用例图可以帮助固化场景、界定范围，类图可以明确主体的特征、行为及关系，时序图可以明晰不同主体间的协作等。主体的属性、关系一旦确定，就会体现在库表结构设计和程序逻辑中，在项目的中后期改变起来非常困难，所以要慎重。我们经常能够听到程序员抱怨说这个问题当时没考虑到，现在不太好改。比如两个主体原先是一对一的映射关系，在某种极其例外的情况下，需要变成一对多的关系，估计就会伤筋动骨。

业务分析的第二项成果是梳理出哪些是变化的，哪些是不变的。对变化进行封装，让变化所带来的不确定性只影响局部范围，是程序员进阶需要掌握的一项基本技能。程序在很多时候就是为了管理变化。比如一个文件备份业务，不变的是需要将文件从一个目录拷贝到另外一个目录，变化的是到底需要拷贝哪些文件。通过配置、解析来管理这个变化，程序也就有了足够的通用性。

业务分析的第三项成果是需要分析出哪些工作应该机器完成，哪些需要人工完成。这个“度”很难把握，需要综合权衡风险、便利、技术成熟度等。在考虑风险因素时，需要认清到底是消除了风险，还是转移了风险。我们不能做风险的搬运工。随着计算机应用技术的发展，机器能做的事情越来越多，本着“事务型工作自动化、管理型工作流程化、决策型工作智能化”的原则，一点点地提高业务运作效率。

在你认为已经将业务分析得很透彻之后，加入时间变量，借用有限状态机的概念，让业务模型在纸面上运转起来。你可能会发现很多新的问题：这时候可能你还没有考虑清楚每个概念主体到底有多少种状态，状态之间到底如何变化，当不同状态重叠的时候又该如何处理。千万不要轻易给主体新增状态属性。比如一个主体已经有三个状态字段，每个字段有两个值，则这个主体就会有八种状态。如果你再随手增加一个状态字段，则至少新增了八种状态，会使问题大大的复杂化，但你的初衷可能只是为了解决一个小问题。事实上很多状态并没有实际的物理意义。两个原则：原则一是宁愿扩充解释，也不要新增属性；原则二是没有物理意义的分支一定要剪枝。

以上是我在业务建模过程中总结的一些理念、工具和方法，其中滋味不足道也。不见得通用，也不能一招鲜吃遍天，需要在实践中不断琢磨、提高。

举例

以信息披露业务为例。

第一步：分类

第一步：分类。由于业务繁多，所以我首先对它进行分类，比如：公募基金招募说明书更新、公募基金定期报告、公募基金公告、年金定期报告、专户定期报告等。分类是否合理，需要根据实际业务判定。我在实际操作中，将人员分工和管理流程一致的业务分为同一类业务，因此现在的信息披露系统中已经有十几类业务了。

第二步：主体抽象

第二步：主体抽象。和大多数人一样，我一开始觉得信息披露业务比较简单，无非牵扯到的业务部门多一点，后来的事实证明我错得离谱。闲话不说，看结果：

1、人，要赋予不同的角色：报告创建人、数据维护人、数据审核人、部门负责人、审计人员、业务负责人等等。

2、模板：这是对报告结构的抽象。

3、元素：构成报告模板的基本要素，对应报告中的一个内容，可以是一个词汇、换行符，也可以是一个表格、图，甚至可以是一个Word文档。

4、数据：给元素赋予具体的值。

5、报告：最终要交付的文档。

6、产品：公司运作的产品。

7、报告期：信息披露的报告期限，不同业务需要的数据不同。

8、业务：人员分工和管理流程一致的信息披露子业务。

9、部门：公司组织架构的一部分。

……

梳理出所有主体之后，进一步梳理出主体的属性，篇幅所限，略过。

第三步：梳理关系

第三步：主体间的关系，反复推敲，从而形成类图。略过。

第四步：用例分析

第四步：用例分析。我以批量创建定期报告这个场景简要说明一下。批量创建定期报告是指年金（养老金业务部）、专户（机构业务部）或一对多专户（客户服务部）在每个月初、季初或年初的时候，需要批量创建上一个报告期的定期报告。除了创建报告外，其余隐含的业务逻辑包括：

1、哪些产品需要披露定期报告？新成立的产品怎么办？产品如果不需要披露报告的怎么办？

2、每个产品使用什么报告模板来披露报告？忘了维护产品和模板对应关系怎么办？模板还没有怎么办？

3、模板是不是都已经正确设置？有没有被人修改过？

4、通用的数据是不是已经维护好？

看似简单重复地调用“创建报告接口”即可完成的批量创建报告，其实需要考虑的问题点很多。

第五步：形成功能

第五步：定义动作，形成功能，比较复杂时可以借助时序图。以批量创建报告功能为例，需要处理：

１、产品检查：返回报告期内新增的、未在信息披露系统中维护的相关产品。

２、模板检查：返回报告期内相关模板变更记录。

３、产品模板对应关系检查：返回报告期内新增的、尚未指定定期报告模板的相关产品。

４、通用数据维护检查：返回模板中涉及的通用元素的最新信息。

５、创建报告。

第六步：纸面推演

第六步：纸面推演。比如报告生命周期管理：创建报告、发起流程、任务分发、数据维护、数据审核、稽核审核、报告下载、报告归档。

纸面推演时，在确保业务正常运作的前提下，重点考虑例外情况处理。举例来讲，在任务分发环节，部门负责人可能按子业务将分发权限授权给不同的人员负责；在元素维护部门对应关系上，同一元素可能因发起部门不同，数据维护的职责归属不同等等。找到例外并修改之前的设定，如此反复。

最后

以上就是要减肥含羞草为你收集整理的业务建模之一：业务分析的全部内容，希望文章能够帮你解决业务建模之一：业务分析所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。