基于 UML 的银行贷款系统业务建模
0 引言
一套完善的银行贷款系统，不仅可以大大提高贷款业务的办理效率，而且可以根据客户的需求快速完成新业务的开发和重组，改善银行的服务品质。然而对于像银行贷款系统这种大中型系统的开发，很难直接对其进行分析设计，需要借助建立业务模型来分析系统。
UML（Unified Modeling Language，统一建模语言）不仅提供了描述软件系统模型的概 念和图形表示法，而且能准确地表达面向对象的概念，体现面向对象的分析和设计风格。 RUP（Rational Unified Process，统一建模过程）是 Rational 公司为用户提供的基于 UML 的
软件开发过程，它是一种基于用例驱动的，以系统架构为中心的迭代与增量开发软件的过程。
本文是从银行贷款的实际业务出发，在遵循 RUP 迭代开发思想的指导下，利用 UML 开发工具（如 Rational Rose）建立了银行贷款系统的 UML 用例模型。在用例模型的基础上，详细介绍了从用例描述中提取和筛选系统类的语法分析过程，通过分析类之间的关系，建立了银行贷款系统的类图模型，实现了从业务需求分析到系统设计和编码的无缝连接。
1 业务建模
业务建模在软件开发过程中起了非常重要的作用，通过业务建模可以帮助开发人员了解现状，启发愿景和需求，为后续的分析和设计提供精确有效的参考。实施业务建模可以按下文提及的步骤进行。
1.1 选定业务领域
对业务领域的划分应该有一个明确的界限，这一步是基本前提，如果范围不明确，会导致以后的分析缺乏依据，或者产生矛盾。本文引用的实例是银行贷款系统，通过对银行贷款业务的需求调研，选定银行贷款系统的业务领域如图 1 所示。
图 1 银行贷款系统的业务领域
1.2 识别业务执行者
业务执行者（business actor）是在系统之外与业务交互的人或组织；业务工人（business worker）是在系统内帮助完成业务处理的服务人员或系统。一般来说，真正的顾客才是业务系
统的执行者，如银行贷款系统的业务执行者为来银行办理贷款业务的客户。
1.3 识别业务用例
业务用例是业务单元为业务执行者提供的完整价值，需要从业务执行者的角度对每一个业务单元进行分析提取业务用例。UML 用例图主要由业务用例和业务执行者构成，通过“业务执行者——业务用例”的模式来反映业务执行者驱动业务用例的状况。基于以上对业务执行者和业务用例的识别和分析，建立的贷款业务处理单元的用例图，如图 2 所示。
申请贷款发放归还
贷款
查询贷款信息
维护贷款信息
客户
延长贷款期限
...
图 2 贷款业务处理单元用例模型
1.4 描述业务用例
对业务用例的描述是为了说明各业务用例的实现过程。业务用例的描述有两种方式：
用例文档和 UML 动态图：如序列图或活动图。如图 3 所示为申请贷款发放的活动图。
采用用例文档来描述业务用例需要遵循一个用例模板，该模板中一般应包括以下信息：用例名称、用例编号、用例的简短描述、用例的业务执行者、业务工人、前置条件、后置条
件、用例的输入、输出、用例的执行过程等。
图 3 申请贷款发放活动图
2 建立类图模型
2.1 候选类
本文采用简单的语法分析方法提取类：依据用例描述文档找出其中所有的名词，将名词作为类和对象的候选者。从申请贷款发放的用例描述文档中找出的名词有：客户、贷款业务办理申请书、信贷文件建立人员、客户号、客户信息、客户姓名、地址、证件类型、贷款编号、担保品编号、担保品价值、授信客度、合同编号、合同信息、存款账户、贷款
账户、借款凭证等。
2.2 类的筛选
接下来严格考察每个候选类，从中去掉不必要的，仅仅保留确实应该记录其信息或需要其提供服务的类。筛选类的分析方法和依据有：
（1）要寻找隐含在字里行间的名词，合并含义或性质相同的名词，例如把客户和客户信息合并为客户；
（2）有些名词仅作为类的属性，将其去掉。如果一个名词有另外的名词作为附属，或有一个动词受此名词的支配，那么通常该名词就是类。候选类中有很大一部分都是类的属
性，如姓名、贷款编号、担保品价值等，将这些词从候选类中删除；
（3）一般来讲，参与业务活动的人、组织机构、系统管理的设备、需要长期保存的事件、业务运转的表单、票据等都是类；另外还有一些为了业务运转而附加的类，如贷款业
务办理申请书、收费凭证、借款凭证等。
通过以上方法对候选类进行分析，经过筛选最后剩下以下 8 个实体类：客户、账户、贷款产品、合同、业务凭证、信贷文件、担保品、贷款办理人员。
在类的提取过程中，可能会因为分析不全面导致漏过某个真正的类或者把一个不该作为类的词加进来了，这并不重要，根据 RUP 的迭代特性会使开发人员在每一个阶段都进行以上分析，用尽量小的代价来修正所暴露出的错误，最终使筛选出的类能够合理和完整。
2.3 定义类的属性和行为
属性是类的一个描述特征，类的行为描述了这个类在系统中所提供的服务。和类的来源一样，类的属性和行为也有一部分来源于用例描述文档。文档中的形容词作为确定类的属性的线索，动词作为类行为（操作）的候选者。
2.4 建立类之间的关系
找出实体类，确定了类的属性和行为以后，还需要分析任意两个类之间的关系。类之间的关系主要有四种：泛化、关联、聚合、依赖。在 UML 类图中这四种关系分别用不同的线区分出来。关联关系，用来表明两个类之间的点对点关系，每个类都会调用另一个类提供的操作，如贷款办理人员可以调用账户类中开立账户这一操作，来为客户开立账户。聚合关系，或者说是一种拥有的关系，是较强的关联关系，如客户拥有账户。泛化关系，表示类与类之间的继承关系，或类对接口的实现关系，如个贷产品、企贷产品与贷款产品之间就是一种继承关系。依赖关系，类 A 要完成某个功能必须引用类 B，则 A 与 B 存在依赖关
系，依赖关系是弱的关联关系，如贷款账户的开立需要先借助于建立信贷文件。
通过分析申请贷款发放中实体类之间的关系，建立申请贷款发放的 UML 部分类图模型，如图 4 所示。
图 4 申请贷款发放的类图
3 设计和测试
建立类图后，开发人员可以利用 UML 工具（如 Rational rose）自动生成程序代码框架，并对代码框架进行修改和补充，形成完整代码。进一步可根据代码逆向生成 UML 模型，通过这种双向工程可较好地保证模型与代码的一致性。测试必须在整个项目周期中进行，对每个阶段都要用所建立的模型进行测试，才能保证开发的质量，降低开发的风险。
4 结论
本文采用了 UML 对银行贷款系统建立了用例模型，在用例模型的基础上进行类的提取和筛选，建立了银行贷款系统的类图模型，将复杂的银行贷款系统用简单明了的可视化图形表示出来。这在一定程度上实现了软件开发的自动化，实现了设计和编码的无缝连接。对整个银行贷款系统的开发设计提供了必要的参考模型，提高了软件开发的效率和质量。
业务建模
