目录
1 需求分析模型重构 (3)
1.1业务需求分析 (3)
1.2非功能性需求分析 (5)
2 业务分析模型 (6)
2.1业务主角 (6)
2.2业务用例分析 (7)
2.3业务用例场景分析 (9)
2.4业务用例实现 (11)
2.5业务用例完整的包图 (11)
3概念分析模型 (12)
3.1核心业务活动图 (12)
3.2关键业务概念用例图 (12)
3.3概念用例分析 (13)
3.4概念用例实现分析 (14)
3.5概念用例完整的包图 ........................................................ 错误!未定义书签。

4 系统分析模型 (16)
4.1系统用户分析 (16)
4.2系统用例分析 (16)
4.3系统用例实现分析 (17)
4.4分析类 (18)
4.5组件模型分析 (21)
4.6系统分析完整的包图 ........................................................ 错误!未定义书签。

5系统设计模型.. (21)
5.1软件架构/框架选择 (21)
5.2基于架构的设计类 (22)
6设计类优化 (23)
6.1设计类优化结果 (23)
6.2采用的设计模式说明 (23)
7面向对象数据库分析设计 (25)
7.1概念数据模型 (25)
7.2概念数据模型优化/调整................................................... 错误!未定义书签。

7.3物理数据模型 (25)
总结................................................................................................ 错误!未定义书签。

附录A 部分生成的SQL语句. (26)
附录B 部分生成的程序结构性代码 (27)
1 需求分析模型重构
1.1 业务需求分析
1.1.1.背景、业务概况
随着国家的发展、综合国力的不断增加，居民的理财意识、理财意愿日益增长，国家进入了全民理财的时代，与此同时国家理财市场发生很大的变化，资产质量和数量都有了很大的变化，市场有待进一步完善，创新发展动力逐步增强。

商业银行理财系统是银行为了便于管理，引导投资者树立健康、正确的投资理念、进一步推动银行理财市场的长远发展而开发的系统，包括对业务的办理和管理。

1.1.2业务目标
通过对业务概况的了解和整理得出该系统的业务目标如下：
BO-1：为客户提供优质的业务办理服务，提高办事效率，方便客户，为客户提供更好的服务。

BO-2：规范商店的内部管理，提高工作效率和管理效能。

1.1.3涉众分析
1.1.3.1 涉众
涉众（stakehoder）是指与要建设系统相关的一切人和事情。

通过需求陈述分析，得出商业银行理财系统利益相关者（涉众）如图1.1以及涉众的信息如表1-1：
图1.1涉众分析
表1-1涉众概要信息
编号名称说明期望
SH001 客户排号，预约办理业务。

1. 可以方便地申请办理理财业务。

2. 可以方便快速查找相关产品信息。

SH002 大堂经理给予客户帮助，接受客户的
咨询，给客户解释信息。

1.能够正确的解答客户疑问。

2.可以满足客户的需求。

SH003 业务人员介绍业务信息，办理业务。

1.快速准确的办理业务。

2.帮助客户查询业务信息。

SH004 管理人员跟踪监督整个业务的运作。

1.可以查看业务相关信息。

2.管理相关人员信息。

SH005 系统维护人员维护系统正常运行和安全。

1.系统可以正常运行。

2.系统处于安全状态。

1.1.3.2边界
分析业务目标，得到系统边界。

业务目标一：通过本系统为客户办理理财业务提高了自动化服务，提高办事效率。

系统边界的划分如图1.2所示，业务一的边界定义如图1.3所示。

图1.2 边界定义
业务目标二：根据客户所制定的理财项目和业务统计情况，为客户提供优质的个人理财业务。

业务二的边界定义如图1.4所示。

图1.4 业务办理边界定义
业务目标三：对业务跟踪监控，保证整个业务合法有制度的进行。

业务三的边界定义如图1.5所示。

图1.5 业务管理边界定义
业务目标四：维护整个系统的正常运转，确保客户的信息安全。

业务四的边界定义如图1.6所示。

图1.6 系统维护边界定义
1.2 非功能性需求分析
1.2.1性能(PEformance)需求
PE-1:系统需要保证在工作期间的工作效率。

PE-2:系统需要保证长时间的正常运行。

1.2.2 安全性（SEcurity）需求
SE-1:每条充值记录都需要有日志文件能够查询。

SE-2:保证充值或扣款事务的完整进行，不受特殊情况（如断电，误操作等）而影响数据的完整性、一致性。

2 业务分析模型
2.1 业务主角
2.1.1 服务业务主角
通过分析服务业务主角如图2.1所示。

图2.1 服务业务主角
2.1.2 业务办理业务主角
业务办理是由业务人员直接负责，所以业务办理主角如图2.2所示。

图2.2业务办理主角
2.1.3 业务管理业务主角
业务管理主角如图2.3所示。

图2.3 业务管理主角
2.1.4 系统维护业务主角
系统维护业务主角如图2.4所示。

图2.4 系统维护主角
2.2 业务用例分析
2.2.1 服务部门用例
根据对服务部门业务分析，得到其用例如图2.5所示。

图2.5 服务部门业务用例
2.2.2 业务办理业务用例
根据对业务办理部门分析，得到其用例图如图2.6所示。

图2.6 业务办理用例图
2.2.3 管理部门业务用例
根据对管理部门的业务分析，得到其用例图如图2.7所示。

图2.7 管理部门业务用例
2.2.4 系统维护部门业务用例
通过对系统维护部门的业务分析，得到其用例如图2.8所示。

图2.8 系统维护部门业务用例图
2.3 业务用例场景分析
2.3.1 理财业务开通用例场景分析
通过对理财业务开通用例图的分析，获得其场景分析时序图和协作图，如图2.9和2.10所示。

图2.9 理财业务办理时序图
图2.10理财业务办理协作图
2.3.2 理财业务管理用例场景分析
通过对理财业务管理用例的过程分析，得出了业务管理的时序图和协作图，如图2.11和2.12所示。

图2.11业务管理时序图
图2.11业务管理协作图
2.4业务用例实现
2.4.1 理财业务开通用例实现
图2.12 理财业务办理用例实现图2.5 业务用例完整的包图
业务用例包图如图2.13所示。

图2.13 边界定义
3概念分析模型
3.1核心业务活动图
在这个系统中，最核心的业务是开通理财业务，绘制该核心业务活动图如图3.1所示。

图3.1核心业务活动图
3.2关键业务概念用例图
确定了业务主线以后，挑选出与该业务主线有关并且具有代表性的典型业务用例如图3.2所示。

图3.2 关键用例概念用例图
3.3概念用例分析（活动图）
3.3.1 业务办理概念用例分析
3.3.1.1 业务办理概念用例
业务办理概念用例图如图3.3所示。

图3.3业务办理概念用例图
3.3.1.2 业务办理信息录入概念用例场景分析
对业务办理分析，信息录入概念用例场景如图3.4所示。

3.4信息录入用例活动图
3.3.1.3 业务办理信息审核概念用例场景分析
对业务办理分析，信息审核概念用例场景如图3.5所示。

3.4概念用例实现分析 3.
4.1办理理财业务概念用例实现分析
3.4.1.1 办理理财业务概念用例实现
办理理财业务的时序图如图3.6所示。

3.4.1.2 办理理财业务概念用例场景分析对象
办理业务信息审核和信息录入对象图如图3.7和3.8所示所示。

图 3.5 信息审核用例活
图3.6办理理财业务时序图
图3.7 信息审核对象图
4 系统分析模型
4.1 系统用户分析
系统用户是直接使用系统的人，所以得到系统用户是业务员和管理员，如图4.1所示。

4.2 系统用例分析
4.2.1 系统用例图 对系统用户分析得到相应的系统用例图，如图4.2所示。

4.2.2 系统用例图场景分析
建立活动图来描述系统用例，如图4.3所示。

图4.1 系统用户
图4.2 系统用例图
图4.3 业务办理及管理操作活动图4.3 系统用例实现分析
4.3.1 系统用例实现用例图
实现系统需求，如图4.4所示。

图4.4 系统用例实现用例图
4.3.2 用例实现场景分析
办理业务用例实现场景如图4.4所示。