银行信用评级系统

3. 3系统功能分析

3.3.1定义系统边界

系统的边界是系统区别于环境或另一系统的界限，它把系统从所处的环境中分离出来，由定义和描述一个系统的某些特征来形成。当构造系统时，首先需要确定系统的边界在哪里，在对信用评级系统进行分析时，具体需要考虑的内容主要有:什么是系统的组成部分、什么是系统的外部、谁(参与者)使用系统系统

为哪些角色提供哪些特定功能(即用例）等内容。

按以上内容分析信用评级系统的定义主要包括:

1)系统功能主要有:数据导入功能、客户经理申请进行信用评级CPD评级

和打分卡评级)功能、评级信息查询功能、评级审批人员进行评级审批、统计分析、参数管理和系统管理等功能。

2)公司客户管理系统是外部系统，数据导入功能与公司管户管理系统有数据接口。

3、客户经理和评级审批人员参与的功能属于系统的边界范围之内。

3.3.2识别参与者

参与者是用户作用于系统的一个角色，存在于系统的外部，表示一个用例的使用者在与这个用例进行交互时所扮演的角色，每个系统之外的任何实体都可以用一个或者多个参与者来代表。通常代表与系统交互的人、硬件设各或另一系统。同时，参与者有自己的目标，通常通过与系统的交互而实现。

通过对信用评级系统的需求分析，可以确定系统的参与者主要有两类:公司客户管理系统(外部系统)和系统使用的用户。系统使用的用户包括客户经理、审批人和系统管理员三类，其中客户经理是客户信用评级流程的发起人;审批人是评级流程的各级审批参与者，分为:初评复核人、评级审批人和有权认定人: 系统管理员是用户和评级参数的系统管理人。

参与者的用例关系如图3-6所示:

3.3.3识别用例

在UMI,中，用例被定义成参与者与系统在交互中执行的一系列动作，而用例模型描述外部参与者（Acior )所理解的系统功能，用来获取需求，并对系统的开发进行规划和控制。大部分用例将在项目的需求分析阶段产生，用来准确获取用户需求。此外，用例还将驱动系统分析、系统设计、系统实现等其它软件。

通过对软件企业信用评级管理系统的需求分析，初步确定系统中有如下用例存在:

1) 信用数据报送：软件企业用户将评级信息上报信用报送，进入评审;

2)自动评级:根据软件企业用户填报的一些信息计算客户的信用级别。

3)信息查询：查询正在审批的软件企业用户相关信息;

4)历史修改查询:查询客户在审批过程中的历史修改信息:

5)各级流程审批:初评信息经过复评的审核，修改，最终形成软件企业用户的评级信息;

6)统计分析:根据选择的查询条件，生成客户的报表信息，报表信息可以

下载成Excel格式的文件。其中报表类型分为:信用等级客户数统计表、地区分

类客户数统计表、行业分类客户数统计表、客户性质分类客户数统计表:

7)手工调级:审批流程结束后，由相关权限人员对评级结果直接进行等级

调整:

8)用户管理:进行用户的新增、修改和删除;

9) 评级模型维护;计算参数;

10)机构参数管理:用户输入机构编号、机构名称，查询、添加、删除、编辑机构信息，以及进行机构归属维护。

3.3.4用例建模

在确定了参与者和用例的基础上，通过绘制用例图来可视化参与者和用例之

间的联系，可以更清楚直观的了解系统的行为。

系统总体用例图如图3-7所示。

信用评级系统是由软件企业用户进行流程发起的，即数据报送工作是由软件企业用户执行的，发起评级申报时包含数据模板下载后导入用例和手工上报用例。审批是将评级信息上报自动评级，进入审批流转，也是评审员所执行的。软件企业用户可以查询评级流程用例。评审员均能执行评级流程查询用例和历史修改查询用例。评审员还能执行各级审批流程用例和统计分析用例。而手工调级用例只能由复评评审员执行。

依照业务管理的需要，系统需要将业务功能和系统管理功能分开。软件企业用户管理用例、评级模型维护用例、机构参数维护用例是由系统管理员来完成的，软件企业用户和各类评审员〔业务参与者)不能参与执行这些用例。系统管理用例如图3-8所示:

图3-8系统管理用例图

Figure 3-8 Use case diagram system management

3.3.5用例事件流分析

信用评级系统主要包括10个用例，针对各个用例，采用活动图的方式进行分析，可以简化为统一的事件流的描述。

活动图( Activity Diagram)是UML规

范定义的一种图，由状态图变化而来，是一种特殊的状态图，它的应用非常广泛，

既可以用来描述用例的工作流程，也可以用来描述类中某个方法的操作的行为。

活动图展现了在系统内从一个活动到另一个活动的流程，用来表示系统中各种活

动的次序，活动图专注于系统的动态视图，并强调对象间的控制流程。活动图包

括基本活动图和泳道活动图。

我们采用泳道活动图对业务需求进行分析，获得活动图模型。主要是考虑到

用基本活动图虽然能描述系统发生了什么，但无法说明完成这个活动的对象，意

味着活动图没有描述出各个活动由哪个类来完成。而泳道将活动图的逻辑描述与

顺序图、协作图的责任描述结合来，在活动图中，对象可以作为活动的输入或输

出，对象与活动间的输入/输出关系由虚线箭头来表示，在活动图中可以通过信

号的发送和接收标记来表示信号的发送和接收，发送和接收标志也可以与对象相

连，用于表示消息的发送者和接收者。限于篇幅限制，在此只对系统的核心用例

就进行事件流分析，其他模块的建模依此设计:

1. PD类初始评级用例

公司客户的评级采用PD模型评级的方式进行。初评人员接受评级请求，对

要评级的客户进行查询，系统进行自动评级后，初评人员根据该客户的客户信息、

财务数据、定性指标和债务承受额匡算表等，对系统自动评级的结果进行相应的

级别调整，并将调整后的评级结果上报请求评级审批。

n查询待评级客户流程如图3-9所示。

图3一查询待评级客户流程

Figure 3-9G}stomer Inquiries flow rating

初评人员输入客户关键信息项，对要评级的客户进行查询。系统判断用户权

限，对于有权限的用户允许进入客户初评查询界面:系统通过用户输入的关键信

息项对待评级客户进行查询，查询完成后在界面显示符合查询条件的待评级客户

JIJ表。

2)系统自动初评评级流程如图3-10所示。

初评审人员在查询待评级软件企业客户列表中，选择待评级的软件企业客户，对该客户进行评级。系统对初评人员选择的客户进行自动计算，自动计算完成后，系统将评级人信息和初评结果保存到系统数据库，并将初评结果显示在界面。

图3-ZO系统自动初评流程

Figure 3-10 Evaluation flow automatically

3)人工级别调整流程如图3-11所示。

初复评人员申请察看该软件企业客户的定性指标信息，参考该软件企业客户相关信息后，对需要的客户初始评级结果进行调整，输入调整后的客户信用级别信息。界面显示用户需要查看的定性指标信息如财务数据等内容，接受客户的评级级别调整申请，将客户调整后的客户信用级别信息保存到数据库，对评审人用户的申请操作进行记录。

图3-11人工级别调整流程

Figure 3-11 Artificial adjust level slow

4)初评结果上报流程如图3-12所示。

初评人员确认初始评级或评级调整后，选择复评审批人员进行上报申请，申请对初始评级结果进行审批。系统接受初始评级上报申请，将上报的用户申请记录到系统数据库，将申