软件项目实训及课程设计指导——统一建模语言UML在项目开发中的应用

在90年代初，面向对象的方法领域在经过几年的发展后，已经进入成熟期。软件工程领域在1995年至1997年间取得了前所未有的进展，其成果超过软件工程领域过去十几年来的成就总和。而其中最重要的、具有划时代重大意义的成果之一就是统一建模语言（UML，Unified Modeling Language）的出现。

本文通过对银行账户信息管理系统项目示例中的需求描述、系统设计和系统部署等开发环节的具体实现作为示例，为读者提纲要领式地领略UML中的各种视图在软件系统开发中所起的作用，以期望读者在课程设计中能够正确地应用UML中有关知识和体验UML在课程设计项目开发中的具体应用。

1.1 软件系统功能性和非功能性需求的正确描述

1.1.1 利用需求清单描述系统中的功能性和非功能性需求的项目示例

1、银行账户信息管理系统主要的功能描述

银行账户是开展各项金融业务的基础，不论什么样的金融交易，只要通过银行，都表现为资金从一个账户到另一个账户的转移。因此，必须加强银行账户信息管理系统的信息化建设，加大对账户资金流动的监控力度、提高账户信息管理的效率和保障账户数据的安全性。

储户（个人或者企业客户）到银行办理账户有关的各种业务主要有开户、存款、取款、查询、转账、修改密码、销户等多项工作。因此，银行账户信息管理系统前台服务的基本功能要求应该要包括开户、存款、取款、查询、转账、修改密码、销户等多项业务功能。

通过对该银行账户信息管理系统的开发实现，使银行账户管理工作系统化、规范化和自动化，从而达到提高账户管理的工作效率和降低工作人员的劳动强度等目的。

2、银行账户信息管理系统基本需求描述

银行是与人们生活密切相关的金融机构、同时也是IT技术应用比较密集性的企业。在银行设立账户的个人或企业机构通常称为银行的储户（客户）。银行可以为储户开展存款、取款、转账等方面的业务。下面为银行账户信息管理系统的基本功能要求及具体的描述。

（1）开户功能描述

储户向银行前台工作人员出示身份证，填写姓名、家庭住址、身份证号码，并且决定要存入的初始金额；银行工作人员给储户新建出账号并给出初始密码和开户日期等方面的信息。因此，基于Web方式的账户信息管理系统中的储户完成开户功能所需要输入的各个方面的信息请见下图所示的开户功能需求原型表单中的各个数据项目。

（2）存款功能描述

储户向银行前台工作人员提供账号，并且决定要存入的金额和存期；银行工作人员给出储户账号的余额和存款日期。因此，基于Web方式的账户信息管理系统中储户完成存款功能所需要输入的各个方面的信息请见下图所示的存款功能需求原型表单中的各个数据项目。

（3）取款功能描述

储户向银行前台工作人员提供账号和密码，并且决定要取出的金额（如果账户的余额小于取款金额，则本次取款行为将被禁止）；银行工作人员给出储户账号的余额和取款日期。因此，基于Web方式的账户信息管理系统中储户完成取款功能所需要输入的各个方面的信息请见下图所示的取款功能需求原型表单中的各个数据项目。

（4）查询功能描述

储户向银行前台工作人员提供账号和密码等方面的信息；银行工作人员给出储户账号的余额和查询日期。因此，基于Web方式的账户信息管理系统中储户完成查询账户的结果信息请见下图所示的查询功能需求原型表单中的各个数据项目。

（5）转账功能描述

储户向银行前台工作人员提供要转出的账号和密码、以及要转入的账号，并且决定要转账的金额；银行工作人员给予储户转出账号的余额和转账日期。因此，基于Web方式的账户信息管理系统中储户完成转账功能所需要输入的各个方面的信息请见下图所示的转账功能需求原型表单中的各个数据项目。

（6）修改密码功能描述

储户向银行前台工作人员提供账号和账号的原密码，然后决定新密码。银行即用新密码代替储户账号原来的密码。因此，基于Web方式的账户信息管理系统中储户完成修改密码功能所需要输入的各个方面的信息请见下图所示的修改密码功能需求原型表单中的各个数据项目。

（7）销毁账户功能描述

储户向银行前台工作人员提供账号和密码，并且把账号的余额全部取出，银行撤销这个账号。因此，基于Web方式的账户信息管理系统中储户完成销毁账户功能所需要输入的各个方面的信息请见下图所示的销户功能需求原型表单中的各个数据项目。

（8）注册和登陆等其他方面的功能

本账户信息管理系统除了需要提供上面所罗列出的各个业务功能以外，也还需要提供对储户的个人信息进行管理的功能，如注册、登陆、修改个人信息和在线注销等方面的功能，下图所示显示储户登陆系统的需求原型表单中的各个数据项目。

一个储户可以持有多个不同的账户，如果账户不存在或是无效的账户，账户信息管理系统都应该显示出对应的错误提示信息。因此，本账户信息管理系统不仅要提供上面的各个基本功能要求，也还要满足下面的各个非功能方面的要求。具体表现为：

1）系统应符合银行账户管理的规定，满足银行相关人员日常使用的需要，并达到操作过程中的直观、方便、实用安全等要求；

2）系统采用模块化程序设计方法，即便于系统功能的各种组合和修改，又便于系统以后的扩展和功能完善；

3） 系统应具备数据库表中的数据维护功能，能够及时根据应用的需求进行数据的添加、删除、修改等方面的功能操作。

另外，对系统的稳定性也提出了具体的要求——系统在正常的业务活动中，不能宕机；并在数据存储的安全性方面同样也提出了下面的要求：各个账户信息的数据不能丢失、并对交易过程进行日志记录。而系统的运行环境和设计约束方面的要求如下：

1）环境约束：系统在局域网环境内使用；

2）设计约束：必须采用Java平台实现、并且应用B/S架构开发和实现。

3、银行账户信息管理系统中的用户角色划分及身份定义

（1）游客用户

普通用户以游客身份登录本系统，只具有浏览系统的功能，不能进行具体的业务活动。

（2）注册用户

具备普通用户所有的能力。并且是已经注册和成功登陆系统的用户，可以登录、修改个人信息，并且可以进行各种与账户有关的业务活动。

（3）VIP注册用户

具备注册用户所有的能力，并且是系统中的重要的用户（账户内的存款大于20万元），可以享受系统中的各种优惠服务。

（4）账户管理员

是本系统中的后台管理中的一种角色的用户，其主要的职责是对系统中的各种账户进行管理和维护。

（5）储户管理员

是本系统中的后台管理的一种角色的用户，其主要的职责是对系统中的各种储户信息进行管理和维护。

（6）系统管理员

系统管理员登录本系统以后，可以对本系统进行各种系统级别的管理和维护。

1.1.2 利用UML用例图描述系统中的功能性需求

1、采用语言文字描述软件系统的需求所存在的主要缺陷

很长时间以来，无论是传统的软件开发方法还是面向对象的开发方法，都采用自然语言（如中文）描述软件系统的需求。这样的描述方法通常存在有以下各种缺陷：

1）缺乏描述的统一形式，随意性较大——常常会产生理解上的含混及不确定性，因为自然语言的描述容易产生歧义。读者通过对前面的小节"利用需求清单描述系统中的功能性和非功能性需求"中的有关内容的学习，应该对此有所感悟。

2） 其次是没有统一的标准格式，导致不能由软件工具程序帮助开发人员管理需求。

3）另外，也不能保证需求描述的文档与程序代码之间的同步性和一致性。

在系统开发时，开发人员必须要了解并准确地描述用户对应用系统的各个方面的需求，这包括功能、非功能以及环境的约束等方面要求。开发人员应该怎样描述系统中的这些需求？这包括应该采用什么形式和内容？所采用的描述方法能否避免采用语言文字的常规描述方法所带来的问题？

统一建模语言UML能够以图形的方式展示软件系统中的各个方面的特性，为此可以采用UML中的用例模型（用例图）方法描述软件系统中的功能性需求。因为在UML表示法中的每一个图形符号都是有明确的语义、并且可以无歧义地理解的。

2、采用UML中的用例模型方法描述功能性需求

（1）在项目开发中为什么要进行建模和应用模型

模型可以帮助开发人员更好地理解和描述应用系统的结构和功能行为，能够更好地进行沟通和交流；模型也为开发人员提供了如何创建应用系统程序的指导和模板。

（2）UML用例模型和传统的功能分解方法是不同的

用例最初是由Ivar Jackboson博士提出，后被综合到UML的标准规范之中，成为目前软件系统中需求描述的标准。UML用例模型和传统的功能分解方法是不同的，因为将整个软件系统分解成各个用例是面向对象的过程而不是面向实现的过程，并且用例关注软件系统的用户对软件系统本身的各个功能需求。而功能分解的方法主要关注如何将整个软件系统分解成若干个能够被处理的小功能模块。

（3）UML用例模型的主要作用

另外，UML用例模型中的用例图是一种图形化的工具，它用简单的图形元素表示出软件系统的参与者、用例以及它们之间的各种关系。通过用例图能够较好地避免软件系统在功能表达方面的歧义性和不一致性，便于软件系统的最终用户和软件系统的开发人员共同理解软件系统的需求，并取得一定的共识。

3、前台功能服务中面向游客的用例图

游客用户是未进行系统登陆的用户，因此该角色的用户只能完成系统中的最基本的功能。下图所示为前台功能服务中面向游客的用例图，其中的参与者和用例之间的使用关系，在用例图中表示为一个带箭头的直线。

4、前台功能服务中面向注册用户的用例图

一旦注册用户成功地登陆账户信息管理系统后，将可以完成下图所示的各个方面的功能。用例图能够帮助软件系统的开发团队中的各个成员理解用户对软件系统中的各种功能需求——因为它是从用户的角度来描述软件系统所应该具有的功能，也还能够指出各个功能的参与者。但建立用例模型的关键在于如何确定软件系统中的用例：

1） 首先从需求清单中找出动词，每个动词初步可以看成为一个"用例"；

2）然后再分析这些动词（同时还要过滤掉无关的动词）以找出这些动词之间的关系——也就是"用例和用例"之间的关系；

3）其次再找出每个用例所对应的参与者——这可以在需求清单中找出各个代词；

4）最后在某个UML的工具（如Rose）中画出这些用例以产生出最终的用例图。

5、用例图只是对系统中的各个功能的静态图示化表示

在用例图中只能描述出软件系统中应该要提供哪些用例（每个用例代表特定的功能）和各个用例之间的"静态的关系"，而不能够描述系统中的"各个参与者"、"各个用例"的动态行为——各个用例之间的逻辑关系（比如触发的条件及具体的执行流程、活动状态等方面的信息）和先后次序等方面的信息。

此时开发人员应该再辅助采用UML活动图进一步完善对用例的描述。因为UML活动图是从系统的"内部实现"的角度出发来编写和描述的，使用活动图可以表示由系统内部所生成的各个动作；当然，设计人员也可以利用活动图来为参与者对系统的操作行为进行建模、并且可以图示不同功能之间的前后的关系——从这个角度来看，可以认为UML活动图是"动态"的用例图，因为在活动图中不仅可以描述出软件系统中的参与者的各个活动，也能够描述出各个活动之间的条件和分支等逻辑关系方面的内容。

6、采用UML活动图进一步完善对用例的描述