课程设计UML支持校园卡的食堂消费管理信息系统.docx
《课程设计UML支持校园卡的食堂消费管理信息系统.docx》由会员分享，可在线阅读，更多相关《课程设计UML支持校园卡的食堂消费管理信息系统.docx（10页珍藏版）》请在冰豆网上搜索。
课程设计UML支持校园卡的食堂消费管理信息系统
统一建模语言
UML课程设计报告
——支持校园卡的食堂消费管理信息系统
第1章系统需求分析
系统功能分析
功能需求
对于支持校园卡的食堂消费信息管理系统来说，应该至少包括如下几部分功能：
（1）信息查询
系统在验证用户身份之后，允许用户根据需要进行查询。
查询搜索的分类只要有三种：
对账号的基本信息查询时，主要通过连接数据库查询用户的账号、姓名、性别、卡类、单位、专业、备注信息。
对消费明细的查询时，可以查询最近30天内制定时期内消费明细，包括消费日期、具体时间、消费地点、消费金额、余额。
对充值明细的查询时，可以查询4年内制定时期内的充值明细，包括充值时间、交易金额、交易类型（柜台充值、网银充值、充值地点等）、操作员或交易号等。
（2）校园卡管理
挂失和解挂；
通知学生事务中心补办新卡，学生事务中心通知客户取新卡；
使用网上银行为校园卡充值，必须与网上银行连接，实现充值功能。
非功能需求
（1）操作需求
系统可以在任何主流web浏览器上运行；
系统可以进行后台数据库管理。
（2）性能需求
系统可以满足每天24小时全年365天持续工作；
系统每天会在晚10点以后进行更新；
在8：
00—22：
00时段支持300位并发用户使用，其余时间支持150位。
（3）安全需求
由于系统涉及到个人财产安全问题，所以系统要求有很高的安全性；
系统包含对病毒、蠕虫和木马等病毒的防卫；
系统系统对登录用户进行身份验证，管理员对网站和后台数据库进行管理。
功能需求分析以后，可知满足上述需求的系统需要包括以下几个模块：
（1）数据库管理模块。
数据库管理模块提供了使用者录入、修改并维护数据的途径。
比如学生和老师都可以修改自己的基本信息，然后保存到数据库中；也提供了系统管理员进行用户信息维护的功能。
（2）基本业务模块。
可以用校园卡消费、充值、也可以挂失和解挂，并在遗失以后旧卡的所有信息保留到新卡。
（3）信息查询模块。
主要是对校园卡用户的基本信息查询，也可以对消费和充值的相关记录进行查询、浏览。
图1-1系统功能需求
数据库管理模块
数据库模块包括如下图所示的几个方面：
图1-2数据库管理模块功能
（1）用户注册的信息管理，包括教师和学生在系统上进行注册信息的更新操作，操作者可以是用户，也可以是系统管理员。
（2）消费明细信息管理，系统管理员在教师离职，或者学生学籍不存在时可以进行删除或者清空消费信息。
（3）充值明细信息管理，系统管理员在教师离职，或者学生学籍不存在时可以进行删除或者清空充值信息。
基本业务模块
基本业务模块包括如下图所示的几个方面：
图1-3基本业务模块功能
（1）在校园卡丢失之后可以登录系统补办新卡。
（2）到指定的地方可以为校园卡充值，也可以进行网上转账。
（3）校园卡丢失以后可以挂失，防止别人用自己的卡消费。
（4）校园卡找到之后可以解挂，卡的状态从停用变为正常。
信息查询模块
信息查询模块主要用于网页上的信息浏览和查询，包括如下图所示几个方面：
图1-4信息查询模块功能
（1）用户注册信息，通过网页登陆浏览、查询。
（2）用户消费信息，通过给定日期进行查询。
（3）用户充值信息，同样通过给定提起进行查询。
（4）用户账户信息，在查询消费信息和充值信息的时候在网页上都同时显示账户余额。
第2章系统的UML基本模型
UML初始模型
选择菜单【File->New】可以打开如下图所示的“CreateNewModel”对话框，选择J2SE模式，点击【ok】按钮，表示此系统将用Java语言来开发。
接下来开始设计自己的模型，在此之前先保存，将模型命名为“基于校园卡的食堂消费信息管理系统”，如下图所示：
图2-1UML建模初始模型
系统的用例图
根据系统的需求可以确定四类参与者，分别是学生和教师、营业员、数据库、银行，参与者的详细信息如下：
学生和教师：
是持有校园卡的任何个人，由于学生和教师登录系统之后只是浏览到的自己信息不同，所以可以将两者统称为用户，可以通过本系统查询个人的基本信息、某时间段的消费明细或者充值明细；可以办理校园卡挂失和解挂；可以通知注册中心补办新卡；可以到指定的地点为一卡通充值。
管理员:
是校园卡的管理者，通过校园卡的服务器端进行管理工作。
在客户端方面，接收用户充值的请求，并且接收系统的为用户办理新卡的通知。
数据库：
是服务器端的数据库存储器，负责接收用户输入的信息，并将相应的信息显示给用户。
银行：
是任何在网上开通网上银行的银行网上系统，可以接收用户输入的信息，并执行相应的数据处理服务，之后将处理结果传递给服务器端的数据库。
根据以上描述，可以确定系统用例图包括三部分登录系统、充值业务、其他业务。
其中，用户登录的是客户端系统，所登陆的是服务器系统。
识别用例：
校园卡客户端系统的功能简单，只需要一层用例即可表示。
根据系统的需求可以确定用例包括6个：
查询信息（包括查询用户信息、查询消费信息、查询充值信息、查询余额四类信息）、挂失和解挂、补办新卡、银行转账充值、维护用户信息。
图2-2系统参与者总的用例图
【用例说明】：
（1）查询信息：
在用户登陆系统之后，查询注册信息、消费信息还有卡上余额信息用例，而且此用例的执行时依赖于后台数据库的。
（2）银行转账充值：
可以根据卡号为校园卡直接进行网上银行转账充值。
（3）挂失和解挂：
在用户登陆系统之后，可以办理挂失和解挂，在系统中提交办理挂失和解挂。
（4）补办新卡：
在用户登录系统之后，提交补办新卡的请求，而在系统管理员进入系统之后可以受理用户补办新卡的请求将旧卡的信息完整复制到新卡上面去。
（5）维护用户信息：
在系统管理员进入系统之后，对数据库中的用户信息进行更新操作，对离职的教师、毕业的学生信息做删除或者清空操作。
系统的时序图
本系统的时序图包括以下几个：
（1）查询信息时序图：
查询功能在用户打开查询界面后，对于基本信息查询，系统接收到学号后执行查询，并直接将数据库的信息显示给学生，相对的收到工号后执行查询，并将数据库中的信息显示给老师；对于消费明细查询和充值明细查询，用户输入开始和结束时间并确定查询后，数据库接收学号或工号、查询的开始时间和结束时间，执行查询，并将信息显示给用户。
图2-3用户查询信息时序图
（2）网银转账时序图：
用户打开转账界面后，输入转账金额，然后确定转账，系统接收学号和金额跳到网银界面，当用户在网上银行转账成功后，网银将成功信息传给数据库，数据库保存数据成功后，将信息回显给用户。
图2-4网银转账时序图
（3）补办新卡、挂失解挂顺序图：
用户打开挂失和解挂界面并确定该业务后，系统根据学号修改数据库信息，并将信息回显该用户。
图2-5补办新卡、挂失解挂时序图
系统的协作图
（1）用户登陆以后查找消费充值信息的协作图：
图2-6查找信息的协作图
（2）用户登陆以后挂失、解挂校园卡的协作图：
图2-7办理挂失解挂的协作图
（3）用户登陆后进行网银转账的协作图
图2-8进行网银转账充值的协作图
系统的状态图
（1）数据库的状态图：
数据库的状态比较复杂，刚开始处于空闲状态，接收到查询请求的时候进入查询状态，接收到更新数据请求的时候进入到更新数据的状态，这些操作都是在数据库中存储的表上进行操作的，当对表的操作结束，查询的信息提交给系统，数据库又恢复到空闲的状态。
图2-9数据库状态图
（2）校园卡的状态图：
校园卡从正常使用到已被删除，总共经历了如下几个状态。
图2-10校园卡状态图
系统的活动图
在本系统中，用到的活动图有以下5个，所有的活动图均分为用户和系统两个泳道：
（1）登陆系统活动图：
用户申请登录系统，接着系统要求输入密码，然后用户输入密码，最后系统判断用户名和密码的正确性，并由此响应是进入系统还是保留申请登陆状态。
图2-11登陆系统的活动图
（2）转帐充值活动图：
在成功登陆之后，首先用户申请转帐，然后系统要求用户输入转帐金额并选择银行，然后进入网银系统进行转帐操作，之后后，若转帐成功，系统修改数据库，最后将转帐成功信息提示给用户，否则提示用户失败信息。
图2-12转账充值的活动图
（3）查询消费信息的活动图：
在成功登陆系统之后，先进入到查询消费信息的页面，输入指定的日期，系统开始查找数据库中的信息，显示给用户。
图2-13查询消费信息的活动图
第3章系统中的类
类图的生成
本系统所需要的类的确定只要考虑一下几点：
主要功能中，查询功能只需要通过学号访问数据库，转账业务、补办新卡和挂失解挂业务只需要通过学号修改数据库。
查询界面的功能只需要取学生卡号和查询信息的时间段（包括开始时间和结束时间）；补办新卡和挂失解挂界面只需要取学号即可；转账界面需要用到学号和金额信息；办理定期转账界面需要用到卡号和银行卡号、每次转账的金额。
因此这些界面的功能都非常简单，所有的功能只要写在一个控制类里面即可。
对于用户的数据取得，需要用到数据库，由于数据库的查询修改删除工作所要编写的类本身就有一定量，故本系统的关于数据库的类都另外定义在实体类里面。
（1）定义系统控制类
控制类是主要负责其它类工作的类。
如：
主程序类、主窗体类。
本系统中的实体类有：
用户登陆类（Login）和主程序类（Main）。
（2）定义系统边界类
边界类位于系统与外界的交界处。
如：
窗体类、报表类、描述通信协议的类、直接与外设交互的类、直接与外部系统交互的类。
本系统较简单，各个界面要实现的功能均由主程序实现，不需要专门的边界类。
（3）定义系统实体类
实体类描述要保存到持久存储体中的信息。
如：
数据库、各种形式的数据文件中的信息。
实体类有以下几个：
DataBase-负责连接数据库：
UserInfo、CostInfo、SaveInfo-查询基本信息、消费明细以及充值明细的数据库处理类
GetNewCard-补办新卡的数据库处理类
LostAndBack-挂失和解挂的数据库处理类
BankTransfer-银行转账的数据库处理类
Login-用户登录的类
各类之间的关系
各个类的操作都是依赖于数据库类的，所以在绘制类图的时候，把数据库类BataBase放置在中间，其他类围绕在其周围，与它都是依赖关系。
图3-1系统类之间的关系图
【类图说明】：
上述的所有类中都包含有共同的参数，那就是String类型的传递给数据库的参数sql，里面存放的是传递给数据库的信息。
UserInfo是查询基本信息的类，可以查询数据库中的用户基本信息，属性包括用户的账户号等，操作包括查找用户信息的方法userInfoSearch（）；
CostInfo是查询消费信息的类，里面新增了两个属性那就是开始日期和结束日期，用来确定所要查询的信息所在的时段，而操作函数costInfoSearch（）的调用可以显示出消费信息和账户余额；
SavaInfo是查询充值信息的类，其构造和CostInfo类类似，也需要加入开始日期和结束日期，用来确定所要查询信息的时段，而操作函数costInfoSearch（）的调用，可以显示出消费信息和账户余额；
Login是用户登陆类，必须包括的属性有用户名和密码，操作方法check（）里面需要有连接到数据库的操作，验证登陆的用户是否存在于数据库中，验证用户输入的密码是否与数据库中的密码匹配；
LostAndBack是为用户办理挂失和解挂校园卡的类，必须包括的属性有State类型的参数，代表校园卡当前的状态，类里面还有两个操作方法get（）、lost（）分别调用，用来办理挂失和解挂；
GetNewCard是补办新卡的类，里面有的操作方法newCard（）是用来将原来挂失的卡上的信息复制到新卡上的方法；
BankTransfer是办理网上银行转账的类，其中的属性bankName、bankID、Date是用来记录交易信息的，如交易银行的名字、交易号、交易时间，里面的操作方法bankTransfer（）的调用可以为校园卡充值，并将余额信息存入到数据库当中；
DataBase是系统用来连接到数据库的类，里面有四个操作方法，openConnection（）和closeConnection（）者两个操作方法的设计是为了防止多个的用户并发访问数据库的时候出错，而Query（）和Update（）两个方法则是对数据库表中数据的操作，分别是查询和更新数据。
第4章系统的配置与实现
系统的组件图
基于校园卡的食堂消费管理信息系统主要有两种组件图，业务对象组件和用户界面组件。
（1）业务对象组件：
图4-1业务包Business中所有的组件
【业务对象组件图说明】：
是查询基本信息的类，可以查询数据库中的用户基本信息；
是查询消费信息的类，同时可以显示出账户余额；
是查询充值信息的类，同时可以显示出账户余额；
是用户登陆类，里面需要有连接到数据库的操作，验证登陆的用户是否存在于数据库中，验证用户输入的密码是否与数据库中的密码匹配；
是为用户办理挂失和解挂校园卡的类；
是补办新卡的类；
是办理网上银行转账的类；
是系统用来连接到数据库的类。
将各种用户不同的业务操作封装成不同的类，也就是一个个的工作产品组件，再把这些类组合成一个包Business，充分体现面向对象的思想。
（2）用户界面组件图
图4-2用户界面包Swing中所有的组件
【用户界面组件图说明】：
是用户登陆系统后，系统呈现给用户的主界面。
是用户在提交查询信息请求之后，系统呈现给用户的界面。
是用户在提交网银转账的请求之后，系统呈献给用户的界面。
是用户有补办新卡的需要是进入的界面。
上述业务对象组件和用户界面组件都是添加了包规范的组件。
系统的整体组件图如下图所示，包括系统服务、用户（教师和学生）、数据库服务3个组件，从组件的分类上来看，三者都属于配置组件，是运行系统必须要配置的组件，是形成可执行文件的基础。
图4-3系统的组件图
系统的配置图
配置图主要是用来说明如何配置系统的软件和硬件。
系统配置由以下几个节点构成。
图4-4系统配置图
【配置图说明】：
应用服务器用来协调整个系统的总体协调工作；
数据库负责数据管理和所有信息的存储；
客户机通过互联网与应用服务器相连，这样，系统管理员可以通过互联网管理应用程序服务器，用户则可以通过互联网访问基于校园卡和食堂消费信息管理系统。
第5章小结
本次UML的课程设计是对基于校园卡的食堂消费信息管理系统进行建模，首先我们做了系统需求分析，知道了系统需要的一些功能需求和非功能需求，然后将系统的整体架构分为3个模块进行设计，分别是数据库管理模块、基本业务模块、信息查询模块。
然后分别用UML通用建模语言对本系统从不同的角度进行建模描述，换句话说，UML提供了从不同的角度去观察和展示系统的各个特征的标准和方法。
在UML中，从任何一个角度对系统所做的抽象都可以用几种模型图来描述，而这些来自不同角度的模型图最终组成了系统的完整的模型。
用例图是需求分析到系统实现的第一步，是非常关键的，它描述了人们希望如何使用一个系统。
时序图描述了对象之间传送消息的时间顺序。
协作图描述了对象之间相互交互的关系。
活动图着重表现一个活动到另一个活动的控制流，是内部处理驱动的流程，而状态图则着重描述从一个状态到另外一个状态的流程，主要有外部事件的参与。
组件图描述了软件的各组件和她们之间的依赖关系。
配置图描述了运行软件的系统中硬件和软件的物理结构，即系统执行处理中系统系统资源元素的配置情况以及软件到这些资源元素的映射。
只要能够绘出这些关键的图，就可以从各个方面非常好的理解系统。
要想设计出好的软件，建模都很重要，软件的开发问题不仅仅是写代码，而是怎么样正确的写代码和怎么样少些代码，这就使得高质量的软件开发变成了一个结构、过程和工具箱结合的问题，所以说，如果没有对结构、过程和工具加以考虑，所造成的失败是惨重的。
每个失败的软件项目都有其特殊的原因，但是成功的项目在许多方面是相似的。
软件组织获得成功的因素有很多，但是一个基本的因素是对建模工具的使用。
模型提供系统的蓝图，包含细节设计，也包含对系统的总体设计。
一个好的模型包括重要的因素，而忽略不相关的细节。
每一个系统可以从不同的方面使用不同的模型进行描述，因此每个模型都是对系统从语义上的抽象。
模型可以是结构的、侧重于系统的组织，也可以是行为的、侧重于系统的动作。
现代的软件开发采用面向对象的方法。
主要的模块是类或者对象，比如在考虑包含界面、中间层和数据库的简单的系统。
在用户界面层上，有一些具体的对象，例如按钮、菜单以及对话框。
在数据库中，也有一些具体的对象，例如包含系统所需信息的表、视图。
面向对象之所以是现在软件开发的主流，原因非常简单，因为它已经被证实在任何情况下，都能够很好的建模，而且，大多数现代的编程语言、操作系统和编程工具都是不同形式的面向对象的体现。
在建模过程中，我从不了解到熟悉UML建模，虽然在过程中遇到许多问题，诸如某些操时序图的顺序、组件图的组建构造等，通过询问查看书本和上网查找资料，渐渐解决了一个又有一个问题，对统一建模的概念也越来越清晰。
通过本次可设我对RationalRose的UML功能运用更加系统、更加熟练地了解了，在一个软件工程中起着一个非常重要的作用。
这让我明白，要开发好一款软件首先要做的就是对软件的分析建模，完整的建模可以有利于开发人员的软件设计展示开发系统做到与客户良好的沟通协调。
UML的知识是十分丰富的，我将会在以后的学习中，不断提高自己的UML知识。
在以后的其他课程设计上,设计系统时考虑系统的UML模型，这样不仅能够提高我的UML建模水平，还能更加高效地统一规划设计的程序软件系统。
在对于基于校园卡的食堂消费信息管理系统的需求分析数据模块等的划分后，开始定义UML的建模。
建模的目的是便于开发人员展现系统；允许开发人员指定系统的结构或行为；提供指导开发人员构造系统模板；记录开发人员的决策。
在目的明确的情况下还要遵循认真选择模型；每个模型可以有多种表达方式；最好的模型总是能够切合实际；孤立的模型是不完整的这四个原则把现实的食堂消费信息管理系统进行模型构建的简化呈现。
明确所有需要的UML建模概念后开始选择选择模型，本次课程设计我运用了用例图、时序图、写作图、状态图、类图和组建图从外部参与者用户的角度看到需求系统的系统功能到开发人员如何实现系统的功能、组织结构，并且考虑到系统在运用过程中的消息并发性和同步问题，还有一个系统需要的软件与硬件的基本要求。
先通过视图的核心用例视图构画出用例图，分析出用例中的参与者和用例关系，对于谁向系统输入或请求系统输入某些事件来触发系统的执行，搞清担当者在用例中起到的角色。
系统功能是系统单元所提供的，通过认真分析与网上调查，把基本的参与者之间交换消息的过程与关系了解清楚。
总之，我就在课程设计的过程，发现了很多自己的不足之处，我总结了一下，主要有以下几点：
第一，理论的知识不能在实际当中很好运用。
我一直都觉得书本上的知识自己都会了，但是在实际的运用当中，我还是出现了各种各样的问题，只有通过问老师、问同学、上网查找资料才得以解决。
第二，Rose这个建模工具运用的不熟练。
我在建模的时候发现自己对一些不常用的图标不认识，而且在画状态图和类图等需要在内部添加很多内容的图的时候，出现了不知道如何操作的问题。
第三，英文的词汇量有待增加。
很多优秀的软件都是英文编写的，要想熟练运用各种工具软件，知道上面的英文单词的意思是前提。
第四，耐心不够。
所以，我会在今后不断学习，弥补不足，然后尽可能的在实际当中运用。
附录参考资料
[1]AlanZeichick,ModelingUsageLow;DevelopersConfusedAboutUML,MDA,2004
[2]ITURecommendation,SpecificationandDescriptionLanguage（SDL）；2003
[3]UML和模式应用——面向对象分析和设计导论，CraigLarman等，姚淑珍，李虎译，机械工业出版社，2002
[4]UMLASLReferenceGuideASLLanguageLevel；IanWilkie,AdrianKing,MikeClarke,ChasWeaverandChrisRastrick；
[5]StephenJ.Mellor,MarcJ.Balcer,ExecutableUML:
AFoundationforModel-DrivenArchitecture,,2003,科学出版社
[6]UML基础与Rose建模教程，蔡敏、徐慧慧、黄炳强，人民邮电出版社
升级会员 