经济管理学院软件工程课程设计.docx
《经济管理学院软件工程课程设计.docx》由会员分享，可在线阅读，更多相关《经济管理学院软件工程课程设计.docx（47页珍藏版）》请在冰豆网上搜索。
经济管理学院软件工程课程设计
经济管理学院
本科软件工程课程设计
XX管理信息系统
组长：
组员：
2009年6月10日
第1章绪论1
1.1系统开发的背景和意义1
1.2国内外研究发展现状1
1.2.1面向对象技术的发展与现状1
1.2.2UML的建模语言2
1.2.3UML的应用领域3
1.2.4银行系统的发展与现状4
1.3主要工作5
第2章业务建模6
2.1RUP软件开发过程6
2.2业务术语表7
2.3组织机构图8
2.4主业务用例图9
第3章分析与设计10
3.1业务流程调查10
3.1.1银行管理系统业务流程调查10
3.1.2岗位职责10
3.2业务用例分析11
3.2.1银行系统用例图11
3.2.2登陆活动图16
3.2.3银行系统存款活动图17
3.2.4银行系统取款活动图18
3.2.5银行系统转账活动图-19
3.2.6银行系统创建账户活动图
3.3业务类图17
3.3.1高压用电检查管理系统业务类图17
3.3.2高压用电检查管理系统业务类描述18
3.3.3数据库详细设计19
第4章系统实现22
4.1顺序图22
4.1.1高压用电周期性检查顺序图22
4.1.2高压用电检查统计顺序图23
4.2协作图24
4.2.1高压用电周期性检查协作图25
4.2.2高压用电检查统计协作图25
4.3活动图26
4.4系统构件图27
4.5部署图28
4.5.1网络结构图29
4.5.2系统部署图29
4.6界面设计30
4.6.1本系统用户界面程序设计遵循的原则30
4.6.2输入输出设计31
第1章绪论
1.1系统开发的背景和意义
供电公司管理系统的意义是以现代计算机网络技术和通信技术为基础，对用电管理业务实现信息采集、处理、储存、传递和分析汇总，并向客户提供迅速快捷的服务，系统设计依据各业务流程,贯穿了各相关业务部门，真正实现了供用电数据共享，为供电营销决策提供科学、可靠的依据。
经济建设高速发展、用电量与日俱增，这一切对供电企业的管理水平和服务质量提出了更高的要求。
以往人工低效率的管理方式，已经不能很好地适应目前管理工作中所要求的时间性强、数据量大、正确无误、业务繁杂的特点。
以往对高压用电用户的用电检查工作需要用电检查员到变电所现场检查，耗掉了用电检查员的许多时间和精力，且工作效率低，管理很难到位。
因此我们考虑建立基于负荷管理系统已有资源的高压用电检查微机网络化管理系统，变“人工走检”为先进的“智能自动检”，实现对用户的安全合理用电等情况的自动检测，并可同时降低系统投资成本和软件开发成本。
1.2国内外研究发展现状
1.2.1面向对象技术的发展与现状
目前，我国的信息化水平不仅远远落后于起步较早的西方发达国家，而且大大逊色于与我们起点相同的邻国印度。
采用传统面向过程的方法开发应用系统，程序元素（数据、语句）相互之间的关系复杂，系统功能隐含在程序代码中，造成开发困难、维护不易，且稳定性、可重用性较差。
在系统开发方面，利用传统程序设计语言的软件开发方法出现于20世纪70年代，在80年代被广泛采用，其中最重要的是结构化分析和结构化设计方法（Yourdon-79）和它的变体，如实时结构化设计方法等。
这些方法最初由Constantine、Mellor、Ward、Yourdon和其他一些人发明和推广，在一些大型系统，特别是和政府签约的航空和国防领域的系统中取得了一定突破，在这些系统中，主持项目的政府官员强调开发过程的有组织性和开发设计文档的完备和充分。
结果不是像预料的那么好——许多计算机辅助软件工程系统（CASE）只是摘录一些已实现的系统设计的报表生成器，尽管如此，这些方法中仍包含一些好的思想，有时在一些大系统中是很有效的。
随着应用系统规模的日益庞大，面向过程的程序设计方法，越来越难以胜任软件系统的开发。
20世纪80年代在软件开发各种概念和方法积累的基础上，对于如何超越程序复杂性障碍、如何在计算机系统中自然地表示客观世界，人们拿起了思维科学中的面向对象技术作为武器。
面向对象思想的运用，被认为是程序设计方法学方面的一场实质性革命。
MauriceWilkes在图灵奖颁奖仪式上说：
“对象是软件界80年代以来最激动人心的革新之一。
”90年代，面向对象技术四面开花、蓬勃发展，面向对象方法的应用从编程阶段延伸至软件开发的上游、下游阶段，出现了面向对象分析、面向对象设计、面向对象测试等技术。
如今，面向对象技术成为计算机领域中的一种主流技术，在学术界，面向对象的方法与技术已经成为最受关注的研究热点之一；在产业界，越来越多的公司从传统的软件开发技术转向面向对象技术，特别是在一些发达国家，几乎所有的新软件开发都全面或部分地采用面向对象技术。
1.2.2UML的建模语言
1997年11月，UML被OMG全体成员一致通过，并被采纳为标准。
OMG承担了进一步完善UML标准的工作。
在UML标准通过前，就已经有许多概括UML精华的书出版发行。
许多软件开发工具供应商声称他们的产品支持或计划支持UML，若干软件工程方法学家宣布他们将使用UML的表示法进行以后的研究工作。
UML的出现似乎深受计算机界欢迎，因为它是由官方出面集中了许多专家的经验形成的，减少了各种软件开发工具之间无谓的分歧。
我们希望建模语言的标准化既能促进软件开发人员广泛使用面向对象建模技术，同时也能带来UML支持工具和培训市场的繁荣，因为不论是用户还是供应商都不用再考虑到底应该采用哪一种开发方法。
UML的最终目标是在尽可能简单的同时能够对实际需要建立的系统的各个方面建模。
UML需要有足够的表达能力以便可以处理现代软件系统中出现的所有概念，例如并发和分布，以及软件工程中使用的技巧，如封装和组件。
它必须是一个通用语言，像任何一种通用程序设计语言一样。
然而，这样就意味着UML必将十分庞大，不可能像描述一个近乎于玩具一样的软件系统那样简单。
现代语言和操作系统比起40年前要复杂多，因为我们对它们的要求越来越多。
UML提供了多种模型，不是在一天之内就能够掌握的。
它比先前的建模语言更复杂，因为它更全面。
计算机技术的飞速发展创造了人类历史上新的奇迹，但是，随着现代软件工程的复杂程度不断提高，项目失败的可能性也相应的增加了。
信息系统的专家们发现当他们面对越来越多的源代码的时候，脑海中系统模型及其内部的联系也越发混沌和模糊了。
面对现代社会庞大而繁杂的信息事务，专家们渴望使信息变得简单易懂。
无论何种复杂程度的工程项目，设计者都是从建模开始的，设计者通过创建模型和设计蓝图来描述系统的结构。
比如说，电子工程设计人员使用惯用标记和示意图进行复杂的系统的最初设计，会计总是在表格上规划公司的财务蓝图，而行政管理人员则常使用组织结构图这种可视化的方式来描述所管理的部门。
正是因为感到无法对整个复杂的系统全面地把握，所以我需要建模。
建模的意义重大，“分而治之”，这是一个古老而有效的概念。
可以想象，当我们把特别复杂而困难的问题细化分解之后，一次只是设法解决其中一个的时候，事情就容易解决多了。
模型的作用就是使复杂的信息关联变的简单易懂，它使我们容易洞察复杂堆砌而成的原始数据背后的规律，并能有效地使我们将系统需求映射到软件结构上去。
Rose支持三层结构方案。
浏览器/服务器体系结构的广泛使用预示了系统复杂化的发展趋势，为了解决这一问题，与之相应的三层结构方案越来越得到了广泛的应用。
传统的两层结构不是“胖客户机”就是“胖服务器”，胖客户机结构将事务处理原则放在用户端处理，胖服务器则将之集成在数据库中，大量的数据流动为维护和编程带来了极大的困难，而且，其中包含的事务处理原则不能与其它应用共享。
三层结构方案是指由用户接口层、事务处理原则层和数据层的应用模型。
与传统的两层结构相比，它有着更多的优点：
对应用结构任意一层做出修改时，只对其它层产生极小的影响。
固有的可塑性，三层既可共存于单机之中，也可根据需要相互分开。
公用代码数据库使事务处理规则在系统中共享。
1.2.3UML的应用领域
UML的目标是以面向对象图的方式来描述任何类型的系统，具有很宽的应用领域。
其中最常用的是建立软件系统的模型，但它同样可以用于非软件领域的系统，如机械系统、企业机构或业务过程，以及处理复杂数据的信息系统、具有实时要求的工业系统或工业过程等。
总之,UML是一个通用的标准建模语言，可以对任何具有静态结构和动态行为的系统进行建模。
此外,UML适用于系统开发过程中从需求规格描述到系统完成后测试的不同阶段。
在需求分析阶段,可以用用例来捕获用户需求。
通过用例建模,描述对系统感兴趣的外部角色及其对系统（用例）的功能要求。
分析阶段主要关心问题域中的主要概念（如抽象、类和对象等）和机制,需要识别这些类以及它们相互间的关系,并用UML类图来描述。
为实现用例,类之间需要协作,这可以用UML动态模型来描述。
在分析阶段,只对问题域的对象（现实世界的概念）建模,而不考虑定义软件系统中技术细节的类（如处理用户接口、数据库、通讯和并行性等问题的类）。
这些技术细节将在设计阶段引入,因此设计阶段为构造阶段提供更详细的规格说明。
编程（构造）是一个独立的阶段,其任务是用面向对象编程语言将来自设计阶段的类转换成实际的代码。
在用UML建立分析和设计模型时,应尽量避免考虑把模型转换成某种特定的编程语言。
因为在早期阶段,模型仅仅是理解和分析系统结构的工具,过早考虑编码问题十分不利于建立简单正确的模型。
UML模型还可作为测试阶段的依据。
系统通常需要经过单元测试、集成测试、系统测试和验收测试。
不同的测试小组使用不同的UML图作为测试依据:
单元测试使用类图和类规格说明；集成测试使用部件图和合作图；系统测试使用用例图来验证系统的行为，验收测试由用户进行，以验证系统测试的结果是否满足在分析阶段确定的需求。
总之，标准建模语言UML适用于以面向对象技术来描述任何类型的系统，而且适用于系统开发的不同阶段，从需求规格描述直至系统完成后的测试和维护。
1.2.4用电检查的发展与现状
目前国内主要运用用电管理软件的供电公司有上海电力公司、沪西供电分公司和沈阳供电公司及鞍山供电公司。
就上海供电公司来说，上海市电力公司下属l3个供电分公司，高压用电检查是每个分公司均有的业务岗位，其主要工作内容是指导新装客户的业务流程、对已投运客户进行日常管理、采集错避峰相关信息等，每个检查员管辖的客户相对固定。
在沪西分公司试运行时，首先将客户的档案信息输入PDA系统中，再由检查员进行核对，核对完毕后，PDA系统正式试运行，检查员的随手档案管理工作都在PDA系统中完成。
在PDA系统使用之前，检查员的下厂检查都是带上客户的随手档案、下厂检查单、笔记本等到现场的，物件较多，携带不便且容易遗失，现在一个PDA的体积就小多了。
以前，如遇两次下厂之间的时段内调换过表计，必须抄下新表的表号等参数，回公司再进入CIS进行核对，较为麻烦，且不能及时发现问题，如表号有误、倍率有误等。
而现在在现场就能通过PDA查询到表计信息，各类参数一目了然，调表时间、最近一次抄见数也都记录在案，当场就能进行核对。
以前，下厂检查回来后，要马上将检查信息手工整理归档，现在只需将PDA与个人台式电脑连接，进行信息上传，CIS中的相关信息就得到了更新，无须在个人台式电脑上进行二次操作，下厂检查记录也能打印出来，方便省时，大大提高了工作效率和工作质量。
在电力真正走向市场的今天，电力企业在不断寻求管理水平的提高和科技的进步，PDA在高压用电检查业务上的应用完善了电力营销系统的数据采集手段，提升了高压用电检查现场工作管理的信息化水平，并为移动平台在电力营销业务上的应用提供了切实可行的案例
1.3主要工作
本文采用面向对象的分析与设计方法，具体使用IBM公司的RationalRose工具，采用统一建模语言（UML）按照统一开发过程（RUP）实现系统的分析与设计，并用JAVAEE实现。
主要有几个阶段的任务，如下：
1．绪论（系统开发背景、国内外技术现、开发计划）
2．业务建模
3．系统开发的过程文档（需求、分析、设计）
4．系统实现
5．结论
本文对系统进行了详细地UML业务建模，并利用Rose工具将整个过程用一系列的图表形式表现出来，形成一个完整的体系，使开发人员和系统用户都能相对容易的了解系统。
在UML建模阶段，介绍了统一建模的过程，介绍了主要的业务术语，描述了公司的组织机构图和高压用电检查系统的主业务用例图。
在分析与设计一章对供电公司业务流程调查作了描述，并且作了详细地分析；利用用例图描述了供电公司高压用电管理系统的主要业务；并用活动图描述了系统中的各个过程；最后进行了供电公司高压用电管理系统的数据库的设计。
在系统实现阶段，以顺序图的形式描述了各个活动状态的执行顺序，完成了用例的实现部分，设计了网络结构和系统程序界面。
程序的实现采用JAVA语言作为开发工具，SQLSever2000作为数据库管理系统。
第2章业务建模
统一建模语言（UML）是一个通用的可视化建模语言，用于对软件进行描述、可视化处理、构造和建立软件系统制品的文档。
它记录了对必须构造的系统的决定和理解，可用于对系统的理解、设计、浏览、配置、维护和信息控制。
UML适用于各种软件开发方法、软件生命周期的各个阶段、各种应用领域以及各种开发工具，是一种总结了以往建模技术的经验并吸收当今优秀成果的标准建模方法。
UML包括概念的语义、表示法和说明，提供了静态、动态、系统环境及组织结构的模型。
它可被交互的可视化建模工具所支持，这些工具提供了代码生成器和报表生成器。
UML标准并没有定义一种标准的开发过程，但它适用于迭代式的开发过程。
它是为支持大部分现存的面向对象开发过程而设计的。
UML不是一门程序设计语言。
但可以使用代码生成器工具将UML模型转换为多种程序设计语言代码，或使用反向生成器工具将程序源代码转换为UML。
UML不是一种可用于定理证明的高度形式化的语言，这样的语言有很多种，但它们通用性较差，不易理解和使用。
UML是一种通用建模语言。
对于一些专门领域，例如用户图形界面（GUI）设计、超大规模集成电路（VLSI）设计、基于规则的人工智能领域，使用专门的语言和工具可能会更适合些。
UML是一种离散的建模语言，不适合对诸如工程和物理学领域中的连续系统建模。
它是一个综合的通用建模语言，适合对诸如由计算机软件、固件或数字逻辑构成的离散系统建模。
UML描述了一个系统的静态结构和动态行为。
UML将系统描述为一些离散的相互作用的对象并最终为外部用户提供一定功能的模型结构。
静态结构定义了系统中重要对象的属性和操作以及这些对象之间的相互关系。
动态行为定义了对象的时间特性和对象为完成目标而相互进行通信的机制。
从不同但相互联系的角度对系统建立的模型可用于不同的目的。
UML还包括可将模型分解成包的结构组件，以便于软件小组将大的系统分解成易于处理的块结构，并理解和控制各个包间的依赖关系，在复杂的开发环境中管理模型单元。
它还包括用于显示系统实现和组织运行的组件。
2.1RUP软件开发过程
RationalUnifiedProcess（RUP，统一开发过程）是一套面向对象的软件工程过程。
RUP说明了如何有效地使用成熟技术开发软件。
传统软件项目失败的原因有：
1．混乱的需求管理。
2．开发者之间以及开发者和用户不清晰的交流
3．架构不够坚固。
4．没有发现需求、设计和实现中的不一致。
5．缺少有效的测试。
6．对项目状态的主观估计。
7．没有正确地处理项目开发过程中的风险。
8．没有对项目变更进行控制。
如瀑布模型将软件生存周期划分为6个阶段：
需求分析、设计、实现、测试、运行和维护。
瀑布模型最为突出的缺点是缺乏灵活性。
传统的瀑布开发模型是一个一维的模型，开发过程被划分为多个连续的阶段。
在RUP中，软件开发生命周期根据时间和RUP的核心工作流划分为二维空间。
横轴表示项目的时间维，纵轴以内容来组织为自然的逻辑活动。
图2-1RUP软件开发过程
RUP中有9个核心工作流，分为6个核心过程工作流（CoreProcessWorkflows）和3个核心支持工作流（CoreSupportingWorkflows）。
9个核心工作流在项目中轮流被使用，在每一次迭代中以不同的重点和强度重复。
业务建模（BusinessModeling）理解系统的组织结构及其商业运作，确保所有参与人员对开发系统有共同的认识。
2.2业务术语表
软件构架：
在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。
结构问题包括总体组织结构和全局控制结构，通信、同步和数据访问的协议，设计元素的功能分配，物理分布，设计元素的组成，定标与性能，备选设计的选择。
逻辑视图：
包括最重要的设计类、从这些设计类到包和子系统的组织形式，以及从这些包和子系统到层的组织形式。
它还包括一些用例实现。
它是设计模型的子集。
实施视图：
包括实施模型及其从模块到包和层的组织形式的概览。
同时还描述了将逻辑视图中的包和类向实施视图中的包和模块分配的情况。
它是实施模型的子集。
进程视图：
包括所涉及任务（进程和线程）的描述，它们的交互和配置，以及将设计对象和类向任务的分配情况。
只有在系统具有很高程度的并行时，才需要该视图。
在RationalUnifiedProcess中，它是设计模型的子集。
配置视图：
包括对最典型的平台配置的各种物理节点的描述以及将任务（来自进程视图）向物理节点分配的情况。
只有在分布式系统中才需要该视图。
它是部署模型的一个子集。
用例图：
用例图是包括参与者、由系统边界（一个矩形）封闭的一组用例、参与者和用例之间的关联、用例间的关系以及参与者的泛化的图。
用例图表示了来自用例模型（用例，参与者）的元素。
活动图：
活动图是状态机的一个特殊例子，在该状态机中所有的或大部分的状态都是活动状态或动作状态，所有或大部分的转换由源状态中活动的完成所触发。
活动图表示一个程序或工作流。
活动图是模型中的完整单元。
类图：
类图是静态视图的图形表达方式，表示声明的（静态的）模型元素，如类、类型及其内容及相互关系。
类图可以表示包的视图，包含嵌套包的符号。
协作图：
协作图是表示角色间交互的视图，即，协作中的实例及其链接。
与顺序图不同，协作图表示了角色之间的关系。
另一方面，协作图也不将时间作为单独的维来表示，所以必须使用顺序号来判断消息的顺序以及并行线程。
2.3组织机构图
银行组织机构图如图2-2所示。
银行管理机构组织机构图描述了银行内部组织结构，工作人员之间的上下级关系。
图2-2银行组织机构图
2.4主业务用例图
银行系统主业务用例图如图2-3所示。
以下是银行系统主业务用例图，在下一章将银行系统的主业务用例进行细化，有关本用例图的描述在此略。
图2-3银行系统主业务用例图
第3章分析与设计
系统分析与设计过程首先根据业务用例和业务活动图进行聚类，聚类活动在系统分析时开始。
聚类活动是个连续的过程，需要不断地进行丰富和完善，需要按照面向对象设计的思想，划分出子系统类，并为类添加应该具有的方法或属性，以及这些方法或属性的可见性，这些可以通过设计类图来描述。
系统设计的任务就是要依据系统分析文档资料，采用正确的方法，确定系统功能模块在计算机内应该用那些程序组成，它们之间用什么方式连接在一起，以构成一个最好的系统结构。
3.1业务流程调查
3.1.1银行管理系统业务流程调查
信息系统分析与设计的第一步是要了解和理解业务。
在这个过程中需要通过问卷调查、现场调研、业务实习等手段了解业务开展的组织机构、掌握业务活动的规律、理解用户的实际需求，通过简洁直观的方式展示给用户，并以此作为业务讨论的依据和摸板，最终形成用户和开发者双方都能理解的标准文档。
通过调研了解以下内容:
银行管理系统工作流程可分为3个主要阶段:
1．计划阶段，根据银行的业务规模做出下一季度的用业务计划，在审核后交到上级部门。
2．银行业务阶段，根据检查对各个部门基本情况进行检查，并将检查结果储存到资料中。
3．银行统计与分析，将季度的检查结果进行统计分析，并将统计报表上交到相关部门。
3.1.2岗位职责
1．银行业务计划员：
本岗位的主要职责是对银行业务做计划，银行业务检查计划的编制等相关的工作。
2．银行业务科长：
本岗位的主要职责是负责对银行业务检查计划做出整体构想并进行监督，并负责整个银行业务的控制等。
3．银行业务总经理：
本岗位的主要职责是控制整个银行的运作，并对各个部门进行监督与管理，有效控制整个公司的工作，从而提高竞争力。
4．检查人员：
本岗位的主要职责是对银行系统进行检查工作。
5.客户资料管理员：
本岗位的主要职责是对大客户资料进行管理，包括各种信息的查询修改等。
6．系统检查统计管理员：
本岗位的主要职责是对银行业务检查的结果进行统计分析并生成统计报表。
7．财务人员：
本岗位的主要职责是进行检查人员检查期间的各种开销和财务结算工作。
3.2业务用例分析
用例视图是被称为参与者的外部用户所能观察到的系统功能的模型图。
用例是系统中的一个功能单元，可以被描述为参与者与系统之间的一次交互作用。
用例模型的用途是列出系统中的用例和参与者，并显示哪个参与者参与了哪个用例的执行。
用例建模的主要目标是：
1.将需求模型变为可视化模型，并最终得到用户确认；
2.给出清晰、一致的关于系统做什么的描述，确定系统的功能要求；
3.提供从功能需求到系统分析、设计、实现各阶段的度量标准；
4.为最终系统测试提供基准，据此验证系统是否达到功能要求。
3.2.1银行系统用例图
通过整理上诉调研内容，根据岗位职责，划分出参与业务活动的各种角色（不完全等同于岗位职责）。
这些角色主要有：
银行职员，客户，银行。
根据银行主要的业务过程，对照岗位职责确定系统中的业务用例。
使用业务用例刻画了业务活动中的各个角色以及它们在业务活动中的关系。
用例图如图2-3所示。
用例一览
表1Actor一览表
Actor
中文名称
可选操作
Clerk
银行职员
创建、删除帐户，并可以修改帐户信息
CustomerActor
客户
存钱、取钱，并在不同的帐户之间转账
BankActor
银行
客户可以在BankActor中设立或关闭帐户
表2用例一览表
用例识别符
优先级
UseCase
中文名称
简单用例描述
ZY01
1
Login
登录
提供验证用户身份的功能
ZY02
1
Depositfund
存款
提供存钱到帐户的功能
ZY03
1
Withdrawfund
取款
提供从帐户中取钱的功能
ZY04
1
MaintainAccount
管理帐户
提供创建、删除帐户，以及修改帐户信息的功能
ZY05
1
Transferfundwithinabank
在银行内转帐
提供了在属于同一银行的帐户之间转帐的功能
ZY06
1
Transferfundbetweenbanks
在不同的银行之间转帐
提供了在属于不同银行的账户之间转帐的功能
表3优先级说明
优先级
优先级名称
优先级描述
1
基本的
必须实现的功能
用例详细描述
登录（Login）
用例名称
登录
表示符
ZY01
用例描述
描述了用户如何登录到系统中
参与者
用户
优先级
1
状态
审查通过
前置条件
无
升级会员 