银行系统建模.docx
《银行系统建模.docx》由会员分享，可在线阅读，更多相关《银行系统建模.docx（27页珍藏版）》请在冰豆网上搜索。
银行系统建模
第六章纺织业实时监测系统分析与建模
前一章介绍了如何使用RationalRose2003对一个网上选课系统进行建模，本章将以一个简单的银行系统为例，介绍面向对象的分析和设计过程。
进一步来学习如何通过UML统一建模语言对软件系统进行建模。
本章仍是从需求分析开始，一直到对系统完成建模。
15.1需求分析
我们在现实生活中不可能不与银行打交道，银行与人们的生活息息相关。
它为每一个人提供了一系列的金融服务，比如存款、取款和转账等服务。
实际生活中银行的业务功能极其复杂，比如，客户可以使用信用卡进行存取款和支付等功能，由于本章篇幅有限，这里所介绍的银行系统只涉及银行中最基本的功能。
本章所讲的银行系统的功能性需求包括以下内容。
客户可以在银行开立一个或多个账户。
客户能够将钱款存入已经开立的账号中。
客户可从自己的账号中提款。
客户能够将账户中的存款转账至另一个账户。
客户可以随时查询自己账户的情况，包括以前进行的存款、取款等的交易记录。
客户也有权利要求取消账户。
由于分析设计过程是个迭代的软件开发过程，所以需求也会在分析设计的过程中不断被细化。
15.2 系统建模
下面通过使用用例驱动创建系统的用例模型，获取系统的需求，并使用系统的静态模型创建系统的内容，然后通过动态模型对系统的内容进行完善，最后通过部署模型完成系统的部署情况。
在系统建模以前，首先需要在RationalRose2003中创建一个模型，并命名为"银行系统"，该名称将会在RationalRose2003的顶端出现。
如图15-1所示。
（点击查看大图）图15-1 创建项目系统模型
15.2.1 创建系统的用例模型
进行系统分析和设计的第一步是创建系统的用例模型。
作为描述系统的用户或参与者所能操作的模型，它在需求分析阶段有着重要的作用，整个开发过程都围绕系统的需求用例表述的问题和问题模型进行。
创建系统用例的第一步是确定系统的参与者。
银行系统的参与者包含以下三种。
银行职员（Clerk）。
银行职员是银行的工作人员，他们为银行的客户提供开立账户、删除账户和修改账户信息等金融服务。
客户（Customer）。
客户是银行系统中数量最多，也是最重要的参与者。
客户不一定只指个人，它包括任何在银行中开有账户的个人和组织。
客户可以存钱、取钱，并在不同的账户之间进行转账。
银行（Bank）。
银行是为客户提供金融服务的主体。
客户可以在银行开立账户或取消账户。
由上可以得出，系统的参与者包含三种，分别是Clerk（银行职员）、Customer（客户）和Bank（银行），如图15-2所示。
图15-2 系统参与者
然后根据参与者的不同分别画出各个参与者的用例图。
1.银行职员用例图
图15-3 银行职员用例图
如图15-2所示，银行职员能够通过该系统进行如下活动。
登录银行系统。
银行职员在登录系统时，必须通过系统的身份验证才能进入银行系统主界面进行下一步的操作。
对客户的账户进行管理，包括为客户创建新的账户、修改账户信息和删除账户。
2.客户用例图
（点击查看大图）图15-4 客户用例图
如图15-3所示，客户与银行职员之间是依赖关系，客户必须依赖于职员才能完成各种用例。
银行职员作为客户的代理完成与用例的交互。
具体用例如下。
存款。
用户通过银行职员将钱款存入自己的账户中。
取款。
用户通过银行职员从自己的账户中将钱款取出。
转账。
用户通过银行职员将一个账户中的钱款转至其他账户中。
由于转账既可以在同一银行进行，也可以在不同的银行之间进行，因此这里用了两个用例，用本行转账和跨行转账来描述。
本行转账和跨行转账是转账的子用例，它们之间是继承的关系。
3.银行用例图
请参看图15-4客户用例图。
这里的银行参与者描述的是与转账用例中的跨行转账交互的另外一家银行对象。
如果是同一家银行的转账，就不需要用到这个银行参与者。
15.2.2 创建系统的静态模型
在获得系统的基本需求用例模型以后，通过识别和分析系统中的类和对象来创建系统的静态模型。
根据系统需求可以识别系统中存在的对象。
系统对象的识别是通过寻找系统域描述和需求描述中的名词来进行的，从前面的需求分析中可以找到的名词有银行、账户、客户和资金，这些都是对象图中的候选对象。
判断是否应该为这些候选对象创建类的方法是：
是否有与该对象相关的身份和行为？
如果有的话，候选对象应该是一个存在于模型中对象，并应该为它创建类。
根据这些原则，我们至少创建三个类：
银行（Bank）、账户（Account）和客户（Customer）。
在管理账户的用例中职员需要对账户进行存款、取款和转账的操作，所以在系统中还要有表示这些业务记录的对象存在，可以为这些对象建立三个类：
存款（Deposit）、取款（Withdraw）和转账（Transfer），这三个类又可以抽象出父类（Transaction）。
系统和用户交互离不开直观的图形化界面，所以也需要定义系统的用户界面类。
我们将创建六个界面类，分别是主界面类（MainForm）、登录界面类（LoginFrame）、查询界面类（QueryForm）、取款界面类（WithdrawForm）、账户界面类（AccountForm）和转账界面类（TransferForm）。
接着，需要确定系统参与者的属性。
Bank类具用编号、名称、地址、电话和传真的私有属性。
Account类拥有编号、开户时间的私有属性。
Customer类具有姓名、编号、地址和账户的私有属性。
Transaction类具有账户、转账时间和金额的私有属性。
Transfer类具有转至的账号和转至的银行两个私有属性。
Deposit类和Withdraw类不需要设置属性。
所有界面类都不需要设置类属性。
确定了系统中的类后，还需要确定类之间的关系，然后才能建立类图。
我们来分析：
Account账户类和Customer客户类之间是"多对多"的关系，一个客户至少拥有一个账户，一个账户至少被一个客户所拥有（集体账户可以为多个客户共同拥有）。
Account账户类和Bank银行类之间是"一对多"的组合关系，账户是银行类的一部分，一个银行对象至少拥有一个账户对象。
一个账户对象只属于一个银行。
Account账户类和Transaction存在"一对多"的关联关系，一个账户对象可以有多个交易记录，一个Transaction对象只属于一个账户。
Deposit存款类、Withdraw取款类和Transfer转账类继承Transaction类，所以它们和Transaction之间是类属关系。
MainForm主界面类与登录界面类之间是关联关系，而AccountForm账户界面类、QueryForm查询界面类、TransferForm转账界面类和WithdrawForm取款界面类都是主界面类的一部分，所以它们和主界面类之间是组合关系。
AccountForm、QueryForm、TransferForm和WithdrawForm与Account账户类是依赖关系。
根据上述类的关系，完整的类图如图15-5所示。
（点击查看大图）图15-5 系统类图
15.2.3 创建系统的动态模型
（1）
系统的动态模型可以使用交互作用图、状态图和活动图来描述。
交互作用图包括序列图和协作图。
序列图描绘了系统中的一组对象在时间上交互的整体行为，协作图描绘的是系统中一组对象的交互行为。
1.创建序列图和协作图
在银行系统中，通过系统用例的描述，可以获得以下交互行为。
银行职员登录本系统。
客户通过银行职员将钱款存入自己的账户。
客户通过银行职员从自己的账户中将钱款取出。
客户通过银行职员在本银行进行转账。
客户通过银行职员进行跨行转账。
客户通过银行职员开立新账户。
客户通过银行职员删除账户。
客户通过银行职员修改账户信息。
1）银行职员登录银行系统用例的工作流程
（1）银行职员想通过系统进行某一项操作。
（2）银行职员启动系统，在登录页面LoginForm输入自己的用户名和密码并提交。
（3）系统验证银行职员的用户名和密码是否正确，如正确，创建系统主界面。
（4）如果身份验证未通过，返回错误提示信息。
根据基本流程，银行职员登录银行系统的序列图如图15-6所示。
与序列图等价的协作图如图15-7所示。
图15-6 银行职员登录系统序列图
图15-7 银行职员登录系统协作图
2）客户存款用例的工作流程
（1）客户向银行职员提出存款要求。
（2）银行职员在系统主界面请求存款操作，系统创建存款界面。
（3）银行职员添加存款信息后，提交至账户类。
（4）账户类确认数据库是否存在该账户，如存在，创建一个存款交易记录，再将记录保存到数据库中。
计算账户的余额，最后更新数据库中该账户的信息。
根据基本流程，客户存款序列图如图15-8所示。
（点击查看大图）图15-8 客户存款序列图
与序列图等价的协作图如图15-9所示。
图15-9 客户存款协作图
15.2.3 创建系统的动态模型
（2）
3）客户取款用例的工作流程
（1）客户向银行职员提出取款要求。
（2）银行职员在系统主界面请求取款操作，系统创建取款界面。
（3）银行职员添加取款信息后，提交至账户类。
（4）账户类确认数据库是否存在该账户，并确认账户中的金额是否足够支付所取款项，如可足够支付，则创建一个取款交易记录，再将记录保存到数据库中。
计算账户的余额，最后更新数据库中该账户的信息。
根据基本流程，客户取款的序列图如图15-10所示。
（点击查看大图）图15-10 客户取款序列图
与序列图等价的协作图如图15-11所示。
图15-11 客户取款协作图
4）客户进行本行转账的工作流程
（1）客户向银行职员提出本行转账的要求。
（2）银行职员在系统主界面请求转账操作，系统创建转账界面。
（3）银行职员添加转账款信息后，提交至账户类（转出）。
（4）账户类确认是否存在该账户，并确认账户中的金额是否足够支付转账款项，如可足够支付则计算新的账户余额，更新数据库中该账户的信息，发送消息给转账类，创建转账交易记录，并保存转账交易记录。
（5）转账界面将转账信息传递给账户（转入），查询该账户是否存在。
如存在，计算账户余额，然后更新数据库的数据。
发送消息给转账类，创建转账交易记录，并保存转账交易记录。
根据基本流程，客户本行转账的序列图如图15-12所示。
（点击查看大图）图15-12 客户本行转账序列图
与序列图等价的协作图如图15-13所示。
（点击查看大图）图15-13 客户本行转账协作图
15.2.3 创建系统的动态模型（3）
5）客户进行跨行转账的工作流程
（1）客户向银行职员提出跨行转账的要求。
（2）银行职员在系统主界面请求转账操作，系统创建转账界面。
（3）银行职员添加转账款信息后，提交至账户类。
（4）账户类确认是否存在该账户，并确认账户中的金额是否足够支付转账款项。
如可足够支付则计算新的账户余额，更新数据库中该账户的信息。
（5）发送消息给转账类，创建转账交易记录，并保存转账交易记录。
（6）最后，发送转账通知到另一家银行。
根据基本流程，客户跨行转账的序列图如图15-14所示。
（点击查看大图）图15-14 客户跨行转账序列图
与序列图等价的协作图如图15-15所示。
（点击查看大图）图15-15 客户跨行转账协作图
6）客户开立新账户的工作流程
（1）客户向银行职员提出开立账户的要求。
（2）银行职员在系统主界面请求创建账户操作，系统创建账户界面。
（3）银行职员添加账户信息后，提交至账户类。
（4）账户类确认数据库是否已存在该客户的账户。
如不存在，则创建新客户对象。
（5）然后将客户信息保存到数据库中。
根据基本流程，客户开立新账户的序列图如图15-16所示。
与序列图等价的协作图如图15-17所示。
图15-16 客户开立新账户序列图
图15-17 客户开立新账户协作图
7）客户删除账户的工作流程
（1）客户向银行职员提出删除账户的要求。
（2）银行职员在系统主界面请求查询账户操作，系统创建查询界面。
（3）银行职员在查询界面提交账号，从账户类中获得指定账户的信息，同时系统创建账户界面。
（4）银行职员在账户界面确认删除，并将删除命令提交给账户类。
（5）账户类结算账户金额，关闭账户，从数据库中删除账户，并更新数据库中客户的相关信息。
（6）判断是否还有和客户相关的账户存在。
如果没有，最后删除数据库中客户的信息。
根据基本流程，客户删除账户的序列图如图15-18所示。
（点击查看大图）图15-18 客户删除账户的序列图
15.2.3 创建系统的动态模型（4）
与序列图等价的协作图如图15-19所示。
（点击查看大图）图15-19 客户删除账户协作图
8）客户修改账户信息的工作流程
（1）客户向银行职员提出修改账户信息的要求。
（2）银行职员在系统主界面请求查询账户操作，系统创建查询界面。
（3）银行职员在查询界面提交账号，从账户类中获得指定账户的信息，同时系统创建账户界面。
（4）银行职员修改账户信息后，提交给账户界面。
（5）账户界面发送消息更新数据库中客户的信息，同时更新账户信息。
根据基本流程，客户修改账户信息序列图如图15-20所示。
（点击查看大图）图15-20 客户修改账户信息序列图
与序列图等价的协作图如图15-21所示。
图15-21 客户修改账户信息协作图
2.创建状态图
上面描述了用例的活动状态，它们都是通过一组对象的交互活动来表达用例的行为。
接着，需要对有明确状态转换的类进行建模。
在银行系统中，有明确状态转换的类是账户。
下面使用状态图进行描述。
账户包含三种状态：
被创建的新账户、被修改后的账户、睡眠账户和被删除的账户。
它们之间的转化规则如下。
客户开立账户时，新的账户被创建。
客户要求变更原有账户信息时，账户内容被改变。
账户长期未使用，银行将其定义为睡眠账户的状态。
客户注销账户，账户被删除。
根据账户的各种状态以及转换规则，创建账户的状态图如图15-22所示。
（点击查看大图）图15-22 账户状态图
3.创建活动图
还可以利用系统的活动图来描述系统的参与者是如何协同工作的。
在银行系统中，可以创建银行职员的活动图。
1）银行职员登录系统活动图
在银行职员登录系统的活动图中，创建了两个泳道，分别是银行职员对象和系统对象，具体的活动过程描述如下。
（1）系统提示用户输入用户名和密码。
（2）银行职员输入用户名和密码后提交系统，验证其是否正确。
（3）如正确，进入主界面，否则显示错误信息，并提示用户重新输入。
根据上述过程，创建的活动图如图15-23所示。
15.2.3 创建系统的动态模型（5）
2）客户存款活动图
在客户存款的活动图中，创建了两个泳道，分别是银行职员对象和系统对象，具体的活动过程描述如下。
（1）系统提示输入用户的相关信息和存款金额。
（2）银行职员将相关信息输入后提交，系统判断账户是否存在且有效。
（3）如果账户有效并存在，建立交易记录，同时修改账户金额，保存交易记录。
根据上述过程，创建的活动图如图15-24所示。
图15-23 银行职员登录系统活动图
图15-24 客户存款活动图
3）客户取款活动图
在客户取款活动图中创建了二个泳道，分别是银行职员对象和系统对象，具体的活动过程描述如下。
（1）系统提示输入用户的相关信息和取款金额。
（2）银行职员将相关信息输入后提交，系统判断账户是否存在且有效，账户中的余额是否大于取款金额。
（3）如果账户有效并存在，同时金额足够，则建立交易记录，同时修改账户金额，保存交易记录。
根据上述过程，创建的活动图如图15-25所示。
图15-25 客户取款活动图
4）客户转账活动图
对于客户转账的活动图，创建了两个泳道，分别是银行职员对象和系统对象，具体的活动过程描述如下。
（1）系统提示输入用户的相关信息和转账金额。
（2）银行职员将相关信息输入后，提交系统，判断账户是否存在且有效，账户中的金额是否大于转账金额。
（3）如果账户有效并存在，同时金额足够，则建立交易记录，同时修改账户金额，保存交易记录。
（4）判断转入账户是否属于同一银行。
如果是同一银行，系统先确认转入账户是否存在并有效。
如有效则更新账户相关信息，建立转账记录，并保存转账记录。
（5）如果转入和转出账户不是同一银行，则发送转账通知给另一个银行。
根据上述过程，创建的活动图如图15-26所示。
图15-26 客户转账活动图
15.2.3 创建系统的动态模型（6）
5）创建账户活动图
在创建账户的活动图中，需要创建两个泳道，分别是银行职员对象和系统对象，具体的活动过程描述如下。
（1）系统提示输入用户的相关信息和存款金额。
（2）银行职员输入相关信息后提交。
（3）系统为客户创建账户，并将账户信息保存到数据库中。
根据上述过程，创建的活动图如图15-27所示。
6）客户修改账户活动图
对于客户修改账户的活动图，我们创建了两个泳道，分别是银行职员对象和系统对象，具体的活动过程描述如下。
（1）系统提示输入用户的账号。
（2）银行职员输入账号后提交。
系统查询该账户信息并显示。
（3）银行职员修改账户信息后提交，系统更改账户信息。
根据上述过程，创建的活动图如图15-28所示。
图15-27 创建账户的活动图
图15-28 客户修改账户活动图
在对系统的行为描述完成以后，我们基本上可以根据上述的行为或操作建立各个类的操作，从而完善各个类的静态模型。
15.2.4 创建系统的部署模型
前面的静态模型和动态模型都是按照逻辑的观点对系统进行的概念建模，另外还需要对系统的实现结构进行建模。
对系统的实现结构进行建模的方式包括两种，即构件图和部署图。
在银行系统中，可以对系统的主要参与者和主要的业务实体类分别创建对应的构件并进行映射。
根据类图创建系统构件图，包括银行构件（Bank）、客户构件（Customer）、银行职员构件（Clerk）、界面构件（Form）、账户构件（Account）和账户管理构件（Transaction）。
除此之外，还必须有一个主程序构件。
根据这些构件及其关系创建的构件图如图15-29所示。
图15-29 基本业务构件图
系统的部署图描绘的是对系统节点上运行资源的安排。
在银行系统中，系统包括四种节点，分别是：
数据库服务器（DatabaseServer）节点，负责数据的存储；系统服务器（BankServer）节点，用于处理系统的业务逻辑；内部客户端节点（InClient）和外部客户端节点（OutClient），使用者通过客户端登录系统进行操作。
银行系统的部署图如图15-30所示。
图15-30 系统部署图
本章介绍了一个简单的银行系统，通过对该系统的面向对象分析和设计，进一步讲解了UML在项目开发中的综合运用。
我们使用用例图来描述系统的需求，使用类图和对象图进行系统静态模型的创建，使用活动图、状态图对系统的动态模型进行建模，最后通过构件图和部署图完成了系统结构的实现。
学习该案例能够加深大家对UML（统一建模语言）的理解，从而能在实际项目中灵活地使用所学到的知识。
升级会员 