UML-银行系统分析与设计.doc-资料库

df3646cd-0c5c-4769-9c4e-56f37bfea709.doc.pdf-第1页.png

第1页 / 共28页

df3646cd-0c5c-4769-9c4e-56f37bfea709.doc.pdf-第2页.png

第2页 / 共28页

df3646cd-0c5c-4769-9c4e-56f37bfea709.doc.pdf-第3页.png

第3页 / 共28页

df3646cd-0c5c-4769-9c4e-56f37bfea709.doc.pdf-第4页.png

第4页 / 共28页

df3646cd-0c5c-4769-9c4e-56f37bfea709.doc.pdf-第5页.png

第5页 / 共28页

df3646cd-0c5c-4769-9c4e-56f37bfea709.doc.pdf-第6页.png

第6页 / 共28页

df3646cd-0c5c-4769-9c4e-56f37bfea709.doc.pdf-第7页.png

第7页 / 共28页

df3646cd-0c5c-4769-9c4e-56f37bfea709.doc.pdf-第8页.png

第8页 / 共28页

银行系统的分析与设计 1 系统需求分析银行是与生活紧密相关的一个机构，银行提供了存款、取款、转账等业务。在银行设立账户的人或机构通常被称为银行的客户。一个客户可以在银行开多个帐户，客户可以存钱到账户中，也可以从自己的账户中取钱，还可以将存款从一个账户转到另一个账户。客户还可以随时查询自己账户的情况，并查询以前所进行的存款、取款等交易记录。客户也有权利要求关闭账户。上面所描述的是银行的最基本功能，实际生活中的银行要具有复杂很多的功能，譬如客户可以持有信用卡，可以使用信用卡来进行存取、支付等活动。为了简化系统，本章的例子只考虑上述的基本功能。简化的银行系统至少应该具有如下功能：（1）一个银行可以有多个账户（2）一个银行可以有多个客户（3）一个客户可以持有多个账户（4）一个账户可以有多个持有者（5）可以开户（6）可以注销账户（7）可以取钱（8）可以存钱（9）可以在银行内的账户之间转账（10）可以在不同银行的账户之间转账 2 分析问题领域采用用命驱动的分析方法分析需求的主要任务是识别出系统中的参与者和用例，并建立用例模型。参与者和用例是通过分析功能需求确定的。 2.1 识别参与者通过分析银行系统的功能需求，可以识别出 3 个参与者，描述如下：

（1）Clerk（银行职员）描述：Clerk 可以创建、删除账户，并可以修改账户信息。示例：银行的工作人员。（2）CustomerActor（客户）描述：CustomerActor 可以存钱、取钱，并在不同的账户之间转账。示例：任何在银行中开有账户的个人或组织。（3）BankActor（银行）描述：客户可以在 BankActor 中设立或关闭账户。示例：任意一个提供存款、取款、转账等业务的银行。 2.2 识别用例通过对需求的进一步分析，可以确定系统中有如下用例存在：（1）Login（登录）本用例提供了验证用户身份的功能。（2）Deposit fund（存款）本用例提供了存钱到账户的功能。（3）Withdraw fund（取钱）本用例提供了从账户中取钱的功能。（4）Maintain Account（管理账户）本用例提供了创建、删除账户，以及修改账户信息的功能。由于“转账”既可以在属于同一银行的账户之间发生，也可以在属于不同银行的账户之间发生，而发生于不同银行的账户之间的转账需要与参与者“BankActor”交互，因此需要用两个不同的用例来描述银行内的转账和银行之间的转账：（5）Transfer fund within a bank（在银行内转账）本用例提供了在属于同一银行的账户之间转发的功能。（6）Transfer fund between banks（在不同的银行之间转账）本用例提供了在属于不同银行的账户之间转账的功能。由于用例（5）和（6）具有公共行为，因此可以抽象出一个父用例“Transfer fund”。（7）Transfer fund（转账）本用例描述了转账的通用行为，是用例（5）和（6）的父用例。系统的用例图如图 1 所示，参与者“Clerk”与用例“Login”、“Maintain Account”交互，参与者“Clerk”作为参与者“CustomerActor”的代理与用例“Deposit fund”、“Withdraw fund”、 “Transfer fund”交互，也即参与者“CustomerActor”依赖参与者“Clerk”完成存款、取钱、转账的动作。用例“Transfer fund”具有两个子用例“Transfer fund within a bank”和“Transfer

fund between banks”，因此它们之间存在类属关系。另外，用例“Transfer fund between banks” 要与代表另一个银行的参与者“BankActor”交互。图 1 系统用例图 2.3 用例的事件流描述用例的事件流是对完成用例行为所需的事件的描述。下面对前面识别出的用例逐个进行描述。 A “Login”（登录） A.1 简单描述本用例描述了用户如何登录到系统中。 A.2 前置条件（Pre-Conditions）无 A.3 后置条件（Post-Conditions）如果用例成功，则用户登录到系统中。否则，系统状态不变。

A.4 扩充点（Extension Points）无 A.5 事件流 A.5.1 基流（Basic Flow）当用户想登录到银行信息系统中时，用例启动。（1）系统提示用户输入用户名和密码。（2）用户输入自己的用户名和密码，提交。（3）系统验证输入的名字和密码，用户登录系统成功。 A.5.2 替代流（Alternative Flow）如果输入用户名和/或密码无效，系统提示错误信息，用户可以重新输入或终止该用例。该用例可以用如图 2 所示的活动图描述，首先系统提示用户输入用户名和密码，然后 Clerk 输入上述信息后提交，系统验证用户名和密码是否正确，如若正确，则启动系统，否则，显示错误提示信息，并提示用户重新输入用户名和密码。图 2 “登录”活动图

B “Deposit fund”（存款） B.1 简单描述本用例允许客户借助 Clerk 存款到账户中。 B.2 前置条件在本用例开始前，Clerk 必须登录到系统中。 B.3 后置条件如果用例成功，则客户 CustomerActor 账户中存款的金额发生变化。否则，系统状态不变。 B.4 扩充点无 B.5 事件流 B.5.1 基流当 CustomerActor 想存钱到自己的账户时，要向 Clerk 提交存款单和现金，用例启动。（1）系统提示 Clerk 输入用户姓名、用户 ID 号、账号和所存款项的金额。（2）Clerk 输入相关信息后提交，系统确认账户是否存在并有效（当用户名、用户 ID 与账户的户主信息一致，且账户处于非冻结状态时，账户有效）（E-1）。（3）系统建立存款事件记录，并更新账户的相关信息。 B.5.2 替代流 E-1：账户不存在或无效，显示提示信息，用户可以重新输入或终止该用例。该用例的活动图如图 3 所示。首先，系统提示 Clerk 输入用户姓名、用户 ID 号、账号和所存款项的金额。然后，Clerk 输入相关信息后提交，系统确认账户是否存在并有效。如若正确，系统建立存款事件记录，并更新账户的相关信息，否则，显示错误信息，提示用户可以重新输入或终止该用例。

图 3 “存款”的活动图 C “Withdraw fund”（取款） C.1 简单描述本用例允许 Clerk 按照客户的要求从客户的账户中取款。 C.2 前置条件在本用例开始前，用户必须登录到系统中。 C.3 后置条件如果用例成功，则客户 CustomerActor 账户中存款的金额发生变化。否则，系统状态不变。 C.4 扩充点

无 C.5 事件流 C.5.1 基流当 Customer 想从自己的账户中取钱时，要向 Clerk 提交取款单，用例启动。（1）系统提示 Clerk 输入用户姓名、用户 ID 号、账号和取款金额。（2）Clerk 输入相关信息后提交，系统确认账户是否存在并有效（当用户名、用户 ID 与账户的户主信息一致，且账户处于非冻结状态时，账户有效）（E-1），账户中的存款金额是否足够支付所取款项（E-2）。（3）系统建立取款事件记录，并更新账户的相关信息。 C.5.2 替代流 E-1：账户不存在或无效，显示提示信息，用户可以重新输入或终止该用例。 E-2：账户中的存款金额不足，显示提示信息，用户可以重新输入金额或终止该用例。该用例的活动图如图 4 所示。首先，系统提示 Clerk 输入用户姓名、用户 ID 号、账号和取款金额。然后，Clerk 输入相关信息后提交，系统确认账户是否存在并有效。如果不存在或无效，显示错误信息，提示用户可以重新输入或终止该用例，如果存在，再确认账户中的存款是否足够，如果足够，系统建立取款事件记录，并更新账户的相关信息，否则，显示提示信息，用户可以重新输入金额或终止该用例。

图 4 “取款”的活动图 D “Transfer fund”（转账） D.1 简单描述本用例允许 Clerk 按照客户的要求将资金从一个账户转到另一个账户。 D.2 前置条件在本用例开始前，用户必须登录到系统中。 D.3 后置条件如果用例成功，则客户 CustomerActor 账户中存款的金额发生变化。否则，系统状态不变。 D.4 扩充点无

资料库

UML-银行系统分析与设计.doc

相关推荐

课程资源

热门标签

最新资料