银行管理系统设计.doc

Four short words sum up what has lifted most successful individuals above the crowd: a little bit more.-author-date银行管理系统设计_x0001_x0001_x0001_x0001_x0001_x0001_x0001_课 程 设 计 报 告学生姓名:学 号：学 院:班 级:题 目:银行管理系统设计银行储蓄管理系统指导教师： 职称: 2011年 7 月 15 日-目 录1. 选题背景12. 银行业务管理系统需求分析22.1 银行管理系统的需求陈述22.2 需求分析22.2.1 功能需求22.2.2 性能需求32.3 系统需求建模42.3.1 确定参与者42.3.2确定用例42.3.3系统用例建模52.3.4 用例描述53. 银行管理系统系统分析103.1 系统用例建模103.2 静态结构模型113.2.1类的识别113.2.2类的关联分析113.2.3类的属性描述123.3 系统动态模型133.3.1 系统执行顺序分析133.3.2 系统的协作分析183.3.3 系统状态分析233.3.4 系统活动分析264. 银行管理系统系统设计与实现324.1 UML体系结构设计324.1.1 硬件体系结构设计324.1.2 软件体系结构设计323.2 对象模型设计334.3 系统实现334.3.1 组件分析334.3.2 配置分析345. 课程设计心得体会35参考文献361、选题背景银行储蓄管理软件的主要作用是针对于各类银行中的储蓄业务进行有效管理。银行储蓄是我们现实生活中的常见活动。就储蓄业务而言，无论国外还是国内，也无论是那家银行，虽然所开展的业务种类稍有不同，利息的计算也存在差异，但储蓄的本质是完全相同的。在我国加入WTO以后，各银行的业务逐渐和国际接轨。银行与企业是市场经济中两个重要的经济主体，两者间的关系是现代市场经济中最重的经济关系之一1。世界经济发展史表明，商业银行从其诞生之日起，便与企业结下了不解之缘，企业的存在是银行产生的前提，企业的发展是银行发展的基础；而银行是企业资金的主要提供者之一，对企业的生产经营具有相当大的影响作用。商业银行为了保证贷款的安全性、盈利性和流动性，必然会对企业的经营情况和信用程度进行详尽的事前调查分析以及事后的跟踪总结。现在的银行储蓄系统工作效率低，越来越不能满足广大人民群众的需要，人们希望能更方便、省时就可以办理储蓄业务；随着拥有银行卡的人群不断增加，人们急切希望能有一种通用的银行卡以便方便在哪家银行都可以存款取款；现在计算机网络的高速发展使越来越多的人更喜欢在网上购物、在家存款取款。本次开发以一个虚拟银行为背景，在深入了解通用的银行储蓄业务管理要求的基础上，力争开发出一个实用性强的通用储蓄系统软件，基本上可满足正常银行业的工作需要。本项目对系统的安全保密性要求也较高。另外，还要实现多币种的储蓄业务。设计者必须了解并掌握银行储蓄业务的一般要求及银行核算的规则（如利息计算的规则、节假日规则、币种兑换规则等）。同时，应该能模拟出消费者的外部消费与银行的结算业务。项目工作量和专业跨度较大。2、银行业务管理系统需求分析2.1 银行管理系统的需求陈述现在的银行储蓄系统工作效率低，越来越不能满足广大人民群众的需要，人们希望能更方便、省时就可以办理储蓄业务；随着拥有银行卡的人群不断增加，人们急切希望能有一种通用的银行卡以便方便在哪家银行都可以存款取款；现在计算机网络的高速发展使越来越多的人更喜欢在网上购物、在家存款取款。在这样的背景下，现在的银行储蓄系统已经不能满足人们日益增长的需求，急切需要建立一个新的、高效的、方便的、互联的银行储蓄系统。在使用此时，需要用户的登录，由系统判断该帐户是否有效（帐户密码是否正确），若密码输入不正确，则再次显示让用户输入密码，若3次输入的密码均不正确，系统自动退出服务，若密码输入正确，则系统进入选择服务类型界面：1.存款，2.取款，3.查询余额，然后系统根据服务类型进行相应操作，若选择取款操作，系统确认取款请求以后，会询问取款数额，系统界面显示输入数额请求，用户输入取款数额，系统接到信息后发出确认取款请求，用户选择确认，系统选择确认后会向点钞机发出钞请求，然后点钞机出钞，系统向用户发出去钞请求，用户取钞以后，系统记录此次取款并自动计算余额，更新帐户信息，然后系统界面进入是否选择继续服务界面，用户点击否，然后系统退出，至此，取款业务完成。若选择存款业务，系统确认存款请求以后，系统界面进入请放入存款界面，然后用户将存款放入存款口，系统提示点钞机进行点钞，点钞完毕后，系统记录存款操作并更新余额，系统界面显示存款完毕，然后系统界面进入是否选择继续服务界面，用户点击否，则系统退出，存款业务完成。若用户选择查询业务，若查询余额，系统确认请求以后根据其账号信息查取余额，并在界面显示余额为多少。2.2 需求分析2.2.1 功能需求（1）功能划分软件分别有创建、删除帐户，修改帐户信息，存钱、取钱，及在不同的帐户之间转账（可以是同一银行，也可以跨行）等功能。各个模块各有不同的功能，但都能完成查询和存储功能。各模块的数据存放在数据库中。数据的调用和连结都由程序来完成。此软件所要完成的主要功能有两方面：如果是存款，储户填写存款单，然后交给键入系统，同时系统还要记录用户姓名、用户id号、帐号和所存款项的金额等信息，完成后由系统打印存款单给储户。如果是取款，储户填写取款单交给业务员，业务员把取款金额输入系统要求储户输入密码以确认身份，核对密码正确无误后系统计算利息并印出利息清单给储户。（2）功能描述外部功能：实现化窗口，查询及储蓄。内部功能：更新，同步，过滤，定位，识别。存款功能：以储户的存款为主要活动，相关记录根据存款结果进行调整，以使信息保持一致。系统需要在原帐户信息中增加一条记录，包括存款人姓名、住址、存款类型、存款日期、利率等信息。若为新储户须建立一个帐户，并记录此次的记录。打印存款单给储户。取款功能：系统计算利息，在原帐户信息中将取款减去。若为清户，记录注销该帐户，将帐户余额一并交与储户。打印利息清单给储户。余额查询功能：为储户提供查询余额服务，将储户的相关记录输出。需要储户的帐户信息及密码。打印储户的帐户余额。更新功能：根据用户的存储数量，系统能够自动更新，并且应储户的需求修改密码并保存。 需要储户输入帐户及密码，若想修改密码按下一个键，输入密码按确定，并且要求储户再次确认密码。系统保存储户信息，并且系统实现自动更新。2.2.2 性能需求（1）数据精确度在进行向数据库文件提取数据时，需求数据记录定位精确，在往数据库文件数组中添加数据时，要求输入数精确金额、身份证、卡号等按消息设定字符数。（2）时间特性程序响应时间：在人的感觉和视觉事物范围内；信息交换时间：要求在程序调用前后都与数据库保持同步更新，网络信息交换时间应该小于程序调用时间。（3）适应性要求数据库局用很好的更新能力，由于本产品是试验性软件，故对磁盘和内存容量没有很高的要求，但是数据库应该能够对并发事件，脏数据具有较强的识别处理能力。（4）磁盘容量由于要存储大量的数据和信息，所以要求要有足够的磁盘容量。（5）主存容量为了满足储户的要求，系统必须要有高的运作速度，储户填写的表单输入到系统，系统必须能快速作出响应，迅速处理各项数据、信息，显示出所有必需信息并打印出各项清单，所以要求很高的信息量速度和大的主存容量；由于要存贮大量的数据和信息，也还要有足够大的磁盘容量。除此之外，安全性也是系统最重要的性能需求之一，银行计算机储蓄系统必须有可靠的安全措施，以保证储户的存储安全。2.3 系统需求建模2.3.1 确定参与者系统中参与者（Actor）信息如表1所示。表2-1ctor一览表Actor中文名称可选操作Clerk银行职员创建、删除帐户，并可以修改帐户信息CustomerActor客户存钱、取钱，并在不同的帐户之间转账BankActor银行客户可以在BankActor中设立或关闭帐户2.3.2确定用例系统中各用例信息如表2所示。表2-2例一览表用例识别符优先级UseCase中文名称简单用例描述ZY011Login登录提供验证用户身份的功能ZY021Deposit fund存款提供存钱到帐户的功能ZY031Withdraw fund取款提供从帐户中取钱的功能ZY041Maintain Account管理帐户提供创建、删除帐户，以及修改帐户信息的功能ZY051Transfer fund within a bank在银行内转帐提供了在属于同一银行的帐户之间转帐的功能ZY061Transfer fund between banks在不同的银行之间转帐提供了在属于不同银行的账户之间转帐的功能系统中执行优先级情况如表3所示。表2-3优先级说明优先级优先级名称优先级描述1基本的必须实现的功能2.3.3系统用例建模 根据银行的业务流程、系统参与者确定了系统的主业务用例模型，银行系统主业务用例图如图2-1所示。图2-1 银行系统主业务用例图2.3.4 用例描述登录（Login）用例 登录用例如表2-4所示表2-4登录用例用例名称登录表示符ZY01用例描述描述了用户如何登录到系统中参与者用户优先级1状态审查通过前置条件无后置条件如果用例成功，则用户登录到系统之。否则，系统状态不变。基本操作流程当用户想登录到银行信息系统中时，用例启动。（1） 系统提示用户输入用户名和密码。（2） 用户输入自己的用户名和密码，提交。（3） 系统验证输入的名字和密码（E-1）,用户登录系统成功。可选操作流程E-1：如果输入用户名和（或）密码无效，系统提示错误信息，用户可以重新输入或中止该用例。存款（Deposit fund）用例 存款用例如表2-5所示表2-5存款用例用例名称存款表示符ZY02用例描述本用例允许客户借助Clerk存款到帐户中参与者客户优先级1状态审查通过前置条件在本用例开始前，Clerk必须登陆到系统中后置条件如果用例成功，则客户账户中存款的金额发生变化。否则，系统状态不变。基本操作流程当客户向存钱到自己的账户时，要向Clerk提供存款单和先进，用例启动。（1） 系统提示Clerk输入用户姓名、用户id号、帐号和所存款项的金额。（2） Clerk输入相关信息后提交，系统确认帐户是否存在并有效（E-1）（3） 系统建立存款实践记录，并更新账户的相关信息。可选操作流程E-1：账户不存在或者无效，显示提示信息，用户可以重新输入或终止该用例。取款（Withdraw fund）用例 取款用例如表2-6所示表2-6取款用例用例名称取款表示符ZY03用例描述本用例允许Clerk按照客户的要求从客户的帐户中取款参与者客户优先级1状态 前置条件本用例开始前，用户必须登录到系统中后置条件如果用例成功，则客户账户中存款的金额发生变化。否则，系统状态不变。基本操作流程当客户向存钱到自己的账户时，要向Clerk提供存款单和先进，用例启动。（1） 系统提示Clerk输入用户姓名、用户id号、帐号和所取款项的金额。（2） Clerk输入相关信息后提交，系统确认帐户是否存在并有效（E-1），账户中的存款金额是否足够支付所取款项（E-2）。（3） 系统建立存款实践记录，并更新账户的相关信息。可选操作流程E-1：账户不存在或者无效，显示提示信息，用户可以重新输入或终止该用例。E-2：账户中的存款金额不足，显示提示信息，用户可以重新输入金额或终止该用例。管理帐户（Maintain Account）用例 管理账户用例如表2-7所示表2-7管理账户用例用例名称管理帐户表示符ZY04用例描述提供创建、删除帐户，以及修改帐户信息的功能参与者客户优先级1状态审查通过前置条件在本用例开始前，Clerk必须登陆到系统中后置条件如果用例成功，则客户账户中存款的金额发生变化。否则，系统状态不变。基本操作流程当Clerk想添加修改或删除账户信息时,用例启动.系统要求Clerk选择所要执行的活动(添加账户、修改账户信息、或删除帐户) 。如果所选的活动是“添加帐户”，则执行 分之流S-1：添加帐户。如果所选的活动是“删除帐户”，则执行 分之流S-2：删除帐户。如果所选的活动是“修改帐户”，则执行 分之流S-3：修改帐户信息。S-1：添加帐户（1）系统要求Clerk输入客户信息：姓名、用户id号、帐号、地址、存储金额。（2）Clerk输入帐号后提交。（3）系统为客户建立帐户。（4）将帐户信息存储到数据库中。S-2：删除用户(1) 系统提示Clerk输入帐号（E-1）。（2）Clerk输入帐号后提交。（3）系统检索帐户信息（E-2）。（4）显示帐户信息。（5）Clerk确认删除（E-3）。(6) 关闭帐户。（7）从系统中删除帐户。S-3：修改帐户信息（1）系统提示Clerk输入帐号（E-1）。（2）Clerk输入帐号后提交。（3）系统检索帐户信息（E-2）。（4）显示帐户信息。（5）Clerk修改帐户信息。（6）Clerk修改完毕后提交。（7）系统更新帐户信息。可选操作流程E-1：账户不存在或者无效，显示提示信息，用户可以重新输入或终止该用例。E-2：帐户不存在，系统显示错误信息，Clerk重新输入帐号或取消操作（用例终止）。E-3：取消删除，删除帐户操作被取消，用例终止。转账：转账在银行内转帐（Transfer fund within a bank）用例 在不同的银行之间转帐（Transfer fund between banks）用例 转账用例如表2-8所示表2-8转账用例用例名称转账表示符ZY05用例描述本用例允许Clerk按照用户的要求将资金从一个账户转到另一个账户。参与者客户优先级1状态审查通过前置条件本用例开始前，用户必须登陆到系统中。后置条件如果用例成功，则客户账户中存款的金额发生变化。否则，系统状态不变。基本操作流程当客户要求转帐时，用例启动（1） 系统提示Clerk输入用户姓名、用户id号、帐号和所损款项的金额。（2） Clerk输入相关信息后提交.（3） 系统确认帐户是否存在并有效（E-1），账户中的存款金额是否足够支付所取款项（E-2）。（4） 系统建立存款实践记录，并更新账户的相关信息。（5） 为资金转出账户建立转帐记录。（6） 存储转帐记录。（7） 判断资金转入帐户是否属于同一银行。如果资金转入账户与资金转出账户适于同一银行，则执行分支流S-1：在同一银行的账户间转帐。如果资金转入账户与资金转出账户适于不同银行，则执行分支流S-2：在不同银行的账户间转帐。S-1：在同一银行的账户间转帐（1）系统确认资金转入帐户是否存在并有效（E-1）。（2）更新资金转入账户的相关信息。（3）为资金转入账户建立转帐记录。(4) 存储转帐记录.S-2：在不同银行的账户间转帐.(1) 发送转帐通知给另一个银行.可选操作流程E-1：账户不存在或者无效，显示提示信息，用户可以重新输入或终止该用例。E-2：账户中的存款金额不足，显示提示信息，用户可以重新输入金额或终止该用例。3、 银行管理系统系统分析3.1 系统用例建模用例视图是被称为参与者的外部用户所能观察到的系统功能的模型图。用例是系统中的一个功能单元，可以被描述为参与者与系统之间的一次交互作用。用例模型的用途是列出系统中的用例和参与者，并显示哪个参与者参与了哪个用例的执行。用例建模的主要目标是： 1、将需求模型变为可视化模型，并最终得到用户确认； 2、给出清晰、一致的关于系统做什么的描述，确定系统的功能要求； 3、提供从功能需求到系统分析、设计、实现各阶段的度量标准； 4、为最终系统测试提供基准，据此验证系统是否达到功能要求。通过整理调研内容，根据岗位职责，划分出参与业务活动的各种角色（不完全等同于岗位职责）。这些角色主要有：银行职员，客户，银行。根据银行主要的业务过程，对照岗位职责确定系统中的业务用例。使用业务用例刻画了业务活动中的各个角色以及它们在业务活动中的关系。 系统主业务用例图如图3-1所示。图3-1 银行系统主业务用例图3.2 静态结构模型3.2.1类的识别起初，按“名词找类法”分析得到系统中的类有：储户、银行、银行业务员、存款、取款、查询、转账、销户、本金、利息等。后来经过多次去重和删掉无用的类及属性，得到最终的系统设计到的类是：银行、账户、用户、交易、存款、取款、转账。在这一过程中，例如银行业务员等候选类，被列入到最终类的属性中。1. 根据给出的需求陈述，从陈述中找出下列名词，可以把它们作为类与对象的初步的候选者：银行，账户，客户，资金，计算机，储蓄管理系统，存储卡，工作人员，存/取款单。通常，在需求陈述中不会一个不漏地写出问题域中的所有有关的类与对象，因此，分析员应该根据领域知识或常识进一步把隐含的类与对象提取出来。 2. 筛选出正确的类与对象通过一个简单、机械的过程不可能正确地完成分析工作。非正式分析仅仅帮助人们找到一些候选的类与对象，接下来应该严格考察每个候选对象，从中去掉那些不必要的，仅仅保留确实应该记录其信息或需要其提供服务的那些对象。筛选时主要依据下列标准，删除不正确或不必要的类与对象。3.2.2类的关联分析 类是应用领域或应用解决方案中概念的描述。类图是以类为中心来组织的，类图中的其他元素或属于某个类或与类相关联。静态视图用类图来实现，正因为它以类为中心，所以称其为类图。在类图中类用矩形框来表示，它的属性和操作分别列在分格中。如不需要表达详细信息时，分格可以省略。一个类可能出现在好几个图中。同一个类的属性和操作可只在一种图中列出，在其他图中可省略。关系用类框之间的连线来表示，不同的关系用连线上和连线端头处的修饰符来区别。银行管理系统的类图如图3-2所示。图3-2银行业务类图3.2.3类的属性描述类名：Bank基本信息功能：记录物理存在银行的基本信息属性：银行代码、银行名称、银行地址、联系电话和传真类名：Account基本信息功能：记录用户账户的基本信息属性：银行名、账户号、持有者姓名、持有者ID、创建日期类名：Customer基本信息功能：记录客户的基本信息属性：客户姓名、客户地址、客户的ID、客户的账号类名：Transaction信息功能：对交易结果进行统计属性：账号、交易日期、交易的金额类名：Deposit信息功能：对用户的存款信息进行记录属性：账号、存款日期、存款金额类名：Withdraw信息功能：对用户的取款信息进行记录属性：账号、取款日期、取款金额类名：Transfer信息功能：对用户的转账信息进行记录属性：账号、转账账号、转账日期、转账银行、转账金额3.3 系统动态模型3.3.1 系统执行顺序分析顺序图表示了对象之间传送消息的时间顺序。每一个类元角色用一条生命线来表示，即用垂直线代表整个交互过程中对象的生命期。生命线之间的箭头连线代表消息。顺序图可以用来进行一个场景说明即一个事务的历史过程。顺序图的一个用途是用来表示用例中的行为顺序。当执行一个用例行为时，顺序图中的每条消息对应了一个类操作或状态机中引起转换的触发事件。顺序图将交互关系表示为一个二维图。纵向是时间轴，时间沿竖线向下延伸。横向轴代表在协作中各独立对象的类元角色。类元角色用生命线表示。当对象存在时，角色用一条虚线表示；当对象的过程处于激活状态时，生命线是一个双道线。消息用从一个对象的生命线到另一个对象生命线的箭头表示。箭头以时间顺序在图中从上到下排列。顺序图的图形元素组成成分：对象、生存线、消息和激活期。1. 对象：顺序图中所包含的每个对象用一个对象框表示，对象名需要带下划线。2. 生存线：对象框下画垂直的虚线，称为该对象的生存线，表示对象的生存时间。3. 激活期：对象生存线上的一个长方形框，表示该对象的激活时间段，即活动期。4. 消息：在顺序图中，对象之间的消息发送和接收用两个对象生存线之间的消息箭头线表示，用来指出该对象执行期间的顺序。银行系统登录顺序图 对象之间传送消息的时间顺序如图3-3所示，它的先后顺序如图所列。图3-3 银行系统登录顺序图银行存款顺序图 对象之间传送消息的时间顺序如图3-4所示，它的先后顺序如图所列。图3-4 银行存款顺序图银行取款顺序图 对象之间传送消息的时间顺序如图3-5所示，它的先后顺序如图所列。图3-5 银行取款顺序图银行内转账顺序图 对象之间传送消息的时间顺序如图3-6所示，它的先后顺序如图所列。图3-6 银行内转账顺序图银行间转账顺序图 对象之间传送消息的时间顺序如图3-7所示，它的先后顺序如图所列。图3-7 银行间转账顺序图银行创建账户顺序图 对象之间传送消息的时间顺序如图3-8所示，它的先后顺序如图所列。图3-8银行创建账户顺序图银行删除账户顺序图 对象之间传送消息的时间顺序如图3-9所示，它的先后顺序如图所列。图3-9银行删除账户顺序图银行修改账户顺序图 对象之间传送消息的时间顺序如图3-10所示，它的先后顺序如图所列。图3-10银行修改账户顺序图3.3.2 系统的协作分析协作图和顺序图都可以表示各对象间的交互关系，但它们的侧重点不同。顺序图用消息的几何排列关系来表达消息的时间顺序，各角色之间的相关关系是隐含的。协作图用各个角色的几何排列图形来表示角色之间的关系，并用消息来说明这些关系。在实际中可以根据需要选用这两种图。一个协作图描述了系统中为实现某些服务所涉及的对象扮演的角色及其相互之间的交互。协作图着重于有协作关系的对象之间的交互和链接（指对象实例之间的物理或概念上的链接，一个链接是某关联的一个实例）。它可用于图示系统中的操作执行、用例执行或一个简单的交互场景。协作图描述了对象及其之间的链接，还描述了链接的对象之间如何发送消息。银行系统登录协作图 对象之间协作关系如图3-11所示。图3-11 银行系统登录协作图银行存款协作图 对象之间协作关系如图3-12所示。图3-12 银行存款协作图银行取款协作图 对象之间协作关系如图3-13所示。图3-13 银行取款协作图银行内转账协作图 对象之间协作关系如图3-14所示。图3-14 银行内转账协作图银行间转账协作图 对象之间协作关系如图3-15所示。图3-15 银行间转账协作图银行创建账户协作图 对象之间协作关系如图3-16所示。图3-16银行创建账户协作图银行删除账户协作图 对象之间协作关系如图3-17所示。图3-17 银行删除账户协作图银行修改账户协作图 对象之间协作关系如图3-18所示。图3-18 银行修改账户协作图3.3.3 系统状态分析状态图描述了事件和对象状态的关系。状态图描绘事件与对象状态的关系。由事件引起的状态改变称为“转换”。用一张状态图描绘一类对象的行为，它确定了由事件序列引出的状态序列不是任何一个类都需要有一张状态图描绘它的行为。系统分析员应该集中精力仅考虑具有重要交互行为的那些类。状态图(State Diagram)用来描述一个特定对象的所有可能的状态及其引起状态转移的事件。一个状态图包括一系列的状态以及状态之间的转移。状态所有对象都具有状态,状态是对象执行了一系列活动的结果。当某个事件发生后,对象的状态将发生变化。状态图中定义的状态有: 1、 初态状态图的起始点,一个状态图只能有一个初态。2、 终态是状态图的终点。而终态则可以有多个。3、 中间状态可包括三个区域:名字域、状态变量与活动域。4、 复合状态可以进一步细化的状态称作复合状态。 一个对象的状态的变迁称为状态迁移。通常是由事件触发的,此时应标出触发转移的事件表达式。如果转移上未标明事件,则表示在源状态的内部活动执行完毕后自动触发转移。下面用状态图来对银行系统的主要活动进行描述。登陆状态图图3-19描述了银行系统登录状态图。图3-19 银行系统登录活动图银行系统存款状态图图3-20描述了银行系统存款状态图。图3-20 银行系统存款活动图银行系统取款状态图图3-21描述了银行系统取款状态图。图3-21 银行系统取款活动图银行系统转账状态图图3-22描述了银行系统的转账状态图。图3-22 银行系统转账状态图银系统创建账户状态图图3-23描述了银行系统的创建账户状态图。图3-23 银行系统创建账户状态图银行系统删除账户状态图图3-24描述了银行系统的删除账户状态图。图3-24 银行系统删除账户状态图银行系统修改账户状态图图3-25描述了银行系统的修改账户状态图。图3-25 银行系统修改账户状态图3.3.4 系统活动分析在UML中，活动图是系统动态行为建模的图形工具之一，用来表示完成一个操作所需要的活动，或者是一个用例实例（场景）的活动。活动图实际上也是一种流程图，它描述活动的序列，即系统从一个活动到另一个活动的控制流。活动图特别适合描述动作流和并发处理行为。活动图是描述对象间互动关系的另一种方法。1. 动作状态动作状态表达不可中断的动作或操作的执行，用于对实例中原子性（不可分割）动作或算法的执行步骤建立模型。2. 活动状态活动状态拥有一组不可中断的动作或操作，表达一个非原字的运行。也可以说，一个活动状态是由一系列动作状态组成。活动状态的图标中可以只标明活动名称。也可以详细描述其入口动作和出口动作等。3. 动作流是一个实例的不同动作状态之间的联系，说明状态之间的控制流。4. 泳道泳道代表对象对活动的责任。一张活动图可划分成若干个矩形区，每个矩形区为一个泳道，泳道名放在矩形区的顶端。把这些泳道指定给对象，这些对象必须履行该泳道包括的活动。泳道是把指定对象和活动相联系的办法之一，它明确表明对象进行了哪些活动。通常根据责任把活动组织到不同的泳道中，它能清楚地表明动作在哪执行（在那个对象中），或者表明一个组织的哪部分工作（一个动作）被执行。5. 活动图中的对象活动图中的对象用对象符号（矩形框）表示，它可作为活动的输入或输出（用虚线箭线连接），也可展示一个对象受一个特定动作的影响（用动作和对象之间的虚箭线表示）。在活动图中，虚箭线也称为对象流，对象流表示动作状态或活动状态与对象之间的关联。通过活动图中的对象流，可以清楚地描述各项动作状态与不同对象之间的关系，方便系统的分析与设计。根据聚类分析结果和业务流程中的活动图可以设计和完成用例。用例的实现可以用顺序图和活动图来表示。这里用顺序图做了详细分析，因此不在用活动图表示.登陆活动图在用例的基础上，需要对每一个业务活动进行详细描述。UML中的活动图用于描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别并行活动和工作流程情况。活动图实际上就是用来为用例的事件流建模的工具。下面用活动图来对银行系统的主要活动进行描述。图3-26描述了银行系统登录活动图活动图。图3-26 银行系统登录活动图银行系统存款活动图 图3-27描述了银行系统的存款活动图。图3-27 银行存款活动图银行系统取款活动图 图3-28描述了银行系统的取款活动图。图3-28 银行系统取款活动图银行系统转账活动图 图3-29描述了银行系统的转账活动图。图3-29 银行系统转账活动图银系统创建账户活动图 图3-30描述了银行系统的创建账户活动图。图3-30 银行系统创建账户活动图银行系统删除账户活动图 图3-31描述了银行系统的删除账户活动图。图3-31 银行系统删除账户活动图银行系统修改账户活动图 图3-32描述了银行系统的修改账户活动图。图3-32银行系统修改账户活动图4、 银行管理系统系统设计与实现4.1 UML体系结构设计4.1.1 硬件体系结构设计系统硬件体系结构设计如图4-1所示。图4-1 银行系统硬件体系结构图4.1.2 软件体系结构设计系统软件体系结构设计如图4-2所示。图4-2 银行系统软件体系结构图3.2 对象模型设计根据银行日常主要经营业务及管理操作，确定系统的对象模型如图4-3所示。图4-3 银行系统对象模型图4.3 系统实现4.3.1 组件分析组件图描述构件及其之间的相互依赖，组件是逻辑体系结构（类、对象、它们间的关系和协作）中定义的概念和功能在物理体系结构中的视线，它通常是开发环境中的实现性文件。组件图主要用于建立系统的静态实现视图模型，通过组件之间的依赖（虚箭线）关系描述系统软件的组织结构，展示系统中的不同物理构件及其之间的联系。在UML中对一个系统的组件和组件图建模就是在物理结构上建模。每一个组件图只是系统静态视图的某一个图形表示，描述系统的某一个侧面。也就是说，任何一个组件图都不必面面俱到，试图全面地描述系统的整个面貌，系统中所有的组件图合起来才能描述系统的完整静态视图。银行管理系统的组件图如图4-4所示。通过系统组件图可以清楚地看出各个组件间的相互依赖关系。图4-4 银行系统组件图4.3.2 配置分析银行管理系统配置图如图4-5所示。图4-5 银行系统配置图5、课程设计心得体会从7月1日到7月13日，我进行了为期两周的软件工程课程设计，同归这次课程设计，我拓宽了知识面，锻炼了能力，综合素质得到提高。安排课程设计的目的，在于通过理论与实际的结合、人与人的沟通，进一步提高思想觉悟。尤其是观察、分析和解决问题的实际工作能力，以便培养成为能够主动适应社会主义现代化建设需要的高素质的复合型人才。通过课程设计检验学习成果，看看课堂学习与实际工作到底有多大的距离，并通过综合分析，找出学习中存在的不足，以便为完善学习计划，改变学习内容与方法提供实践依据。对于我们信息管理与信息系统的本科生来说，实际能力的培养至关重要，而这种实际能力的培养靠课堂教学是远远不够的，必须从课堂走向实践。通过课程设计，为求职与正式工作做好充分的知识、能力准备，从而缩短从校园走向社会的心里转型期。课程设计促进了我系人才培养计划的完善和课程设置的调整。在为期两周的课程设计之后，我们普遍感到不仅实际都收能力有所提高，更重要的是通过软件开发流程的了解，进一步激发了我们对专业知识的兴趣，并能够结合实际存在的问题在专业领域内进行更深入的学习。参考文献1软件工程原理，方法与应用 吴钦藩 编著 人民交通出版社出版2软件工程导论（第5版） 张海藩 编著 清华大学出版社出版3软件工程 任胜兵 邢琳 编著 北京邮电大学出版社4张海龙. HIS中住院管理系统的研发与应用硕士学位论文.长春. 吉林大学.20055李莹.基于三层结构的医院住院管理系统的设计与实现硕士学位论文.济南.山东大学.2006.6彭叔湘. 中小型医院管理信息系统的设计与实现硕士学位论文.成都.电子科技大学.2007.7李骁. 医院管理信息系统的分析与设计硕士学位论文. 长春. 吉林大学.20048张宏. 医院信息化建设硕士学位论文.大连.大连海事大学.2004.9刘天时.软件案例分析.北京.清华大学出版社.200810张海藩.软件工程.北京.清华大学出版社.2009