VPUMLEE设计指南.docx
- 文档编号:5761118
- 上传时间:2023-01-01
- 格式:DOCX
- 页数:41
- 大小:714.72KB
VPUMLEE设计指南.docx
《VPUMLEE设计指南.docx》由会员分享,可在线阅读,更多相关《VPUMLEE设计指南.docx(41页珍藏版)》请在冰豆网上搜索。
VPUMLEE设计指南
分类号:
单位代码:
学号:
硕士学位论文
论文题目:
用VP-UMLEE设计高效的办公自动化系统
作者姓名:
专业:
软件工程
指导教师姓名
专业技术职务:
2009年3月12日
原创性声明
本人郑重声明:
所呈交的学位论文,是本人在导师的指导下,独立进行研究所取得的成果。
除文中已经注明引用的内容外,本论文不包含任何其他个人或集体己经发表或撰写过的科研成果。
对本文的研究作出重要贡献的个人和集体,均已在文中以明确方式标明。
本声明的法律责任由本人承担。
论文作者签名:
日期:
关于学位论文使用授权的声明
本人完全了解大学有关保留、使用学位论文的规定,同意学校保留或向国家有关部门或机构送交论文的复印件和电子版,允许论文被查阅和借阅;本人授权大学可以将本学位论文的全部或部分内容编入有关数据库进行检索,可以采用影印、缩印或其他复制手段保存论文和汇编本学位论文。
(保密论文在解密后应遵守此规定)
论文作者签名:
导师签名:
日期:
摘要
ABSTRACT
第一章绪论
第二章设计用户系统需求的相关基础
第三章利用VP-UMLEE进行系统分析
第四章利用VP-UMLEE实现系统设计
第五章系统程序实现与测试
第六章总结与展望
摘要
Abstraet
第一章绪论
1.1利用VP-UMLEE设计科技项目管理软件的背景
UML(UnifiedModelingLanguage)伙伴组织于1996年由Rational公司创立。
对象管理组织(OMG)于1997年11月采纳了它。
此后,UML继续改进,目前最新的版本是UML2.2。
UML是多种方法相互借鉴、相互融合、趋于一致、走向标准化的产物。
这样的统一建模语言将为软件开发商及其用户带来诸多便利。
美国等计算机技术发达国家已有大量的软件开发组织开始用UML进行系统建模,学习和使用UML已经成为一种潮流。
我国软件界对UML也相当关注,许多研究人员和技术人员已在几年前就开始了对UML的学习和研究。
在研究大型软件过程中,通常会遇到几个大的项目在同时进行。
传统的项目管理模式主要是基于手工处理,对于经费核算等以人工辅以计算器为工具进行计算,效率太低。
且信息容量大,容易出错。
如何建立一个高效的项目管理系统,即对操作人员予以解放,又能及时迅速全面的管好项目,是我们特别关切的问题。
使用VisualParadigmforUMLEnterpriseEdition建模软件,完全满足以上要求。
利用VisualParadigmforUMLEnterpriseEdition(简称VP-UMLEE)建模软件可以方便地对软件项目进行设计与信息管理,为客户提供充足的信息和快捷的查询手段。
项目管理是以项目为中心,对项目信息做全程跟踪,规范报销流程,对项目分门别类的进行记录,对项目涉及单位主要负责人情况有详细登记,提供便捷的综合查询等,对于市场人员和管理人员来说是至关重要的。
这样庞杂的信息收集与处理,使用计算机远比使用传统人工的方式管理有了许多优点,能够为用户提供充足的、准确的信息和快捷的查询手段。
使用VP-UMLEE软件能直接设计对项目的相关信息进行管理,检索迅速、可靠性高、存储量大、保密性好、寿命长、成本低等,这些优点能够极大地提高效率与管理水平。
1.2利用VP-UMLEE设计项目管理软件开发原则
众所周知,凡是工业产品都有其生命周期,即要经过分析要求、设计、制造、测试、运行(此时需要不断地维护)等几个阶段。
软件也是一种产品,同样存在生命周期。
那什么是软件生命期呢?
一个软件从被提出开始研制至软件最终被废弃不再使用为止的全过程,称为软件生命期。
我们通常把软件生命期划分为可行性研究与计划、需求分析、设计、编程、测试、运行与维护等六个阶段,每个阶段都有明确的任务,并需产生一定规格的文档资料交付给下一阶段,下一阶段在上阶段交付的文档的基础上继续开展工作。
与传统的手工艺开发方式相比,上述生命期模型有两个明显的长处,第一,由于强调要将每个阶段的工作结果用书画形式描述出来,这就便原来“不可见”的软件变成了“可见”的文档资料;第二,开发过程分阶段按步骤进行,以交付某种特定规格的文档作为标志某个阶段完成的里程碑,这就使原来“难以管理的思考过程”变为“可以管更换生产过程”了。
显然,这两点长处为提高软件生产率和改进软件质量创靠了极为有利的条件。
建模语言UML的重要内容可以由下列五类图9种图形来完成项目软件的设计:
首先利用例图,从用户角度描述系统功能,并指出各功能的操作者。
从应用的角度看,当采用面向对象技术设计系统时,首先是描述需求。
用例图等静态图等即很方便的解决这个问题。
其次根据需求建立系统的静态模型,以构造系统的结构。
第二类是静态图(Staticdiagram),包括类图、对象图和包图。
其中类图描述系统中类的静态结构。
不仅定义系统中的类,表示类之间的联系如关联、依赖、聚合等,也包括类的内部结构(类的属性和操作)。
类图描述的是一种静态关系,在系统的整个生命周期都是有效的。
对象图是类图的实例,几乎使用与类图完全相同的标识。
他们的不同点在于对象图显示类的多个对象实例,而不是实际的类。
一个对象图是类图的一个实例。
由于对象存在生命周期,因此对象图只能在系统某一时间段存在。
包由包或类组成,表示包与包之间的关系。
包图用于描述系统的分层结构。
其中在第一步与第二步中所建立的模型都是静态的,包括用例图、类图(包含包)、对象图、组件图和配置图等五个图形,是标准建模语言UML的静态建模机制。
第三步是描述系统的行为。
其中第三步中所建立的模型或者可以执行,或者表示执行时的时序状态或交互关系。
它包括状态图、活动图、顺序图和合作图等四个图形,是标准建模语言UML的动态建模机制。
行为图(Behaviordiagram),描述系统的动态模型和组成对象间的交互关系。
其中状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件。
通常,状态图是对类图的补充。
在实用上并不需要为所有的类画状态图,仅为那些有多个状态其行为受外界环境的影响并且发生改变的类画状态图。
而活动图描述满足用例要求所要进行的活动以及活动间的约束关系,有利于识别并行活动。
交互图(Interactivediagram),描述对象间的交互关系。
其中顺序图显示对象之间的动态合作关系,它强调对象之间消息发送的顺序,同时显示对象之间的交互;合作图描述对象间的协作关系,合作图跟顺序图相似,显示对象间的动态合作关系。
除显示信息交换外,合作图还显示对象以及它们之间的关系。
如果强调时间和顺序,则使用顺序图;如果强调上下级关系,则选择合作图。
这两种图合称为交互图。
实现图(Implementationdiagram)。
其中构件图描述代码部件的物理结构及各部件之间的依赖关系。
一个部件可能是一个资源代码部件、一个二进制部件或一个可执行部件。
它包含逻辑类或实现类的有关信息。
部件图有助于分析和理解部件之间的相互影响程度。
配置图定义系统中软硬件的物理体系结构。
它可以显示实际的计算机和设备(用节点表示)以及它们之间的连接关系,也可显示连接的类型及部件之间的依赖性。
在节点内部,放置可执行部件和对象以显示节点跟可执行软件单元的对应关系。
大型软件系统的程序内部必须带有说明性材料,即“内部文档”,内部文档可用注释语句书写,程序中适当地加上注释后,可以使程序成为一篇“自我解释”的文章,读程序时就不必再翻阅其他说明材料了,因而使用注释是提高程序可读性的有力手段。
我们还认识到提高程序效率的根本途径在于设计阶段选择良好的数据结构和算法,而不是靠编程时对程序语句作调整,编程中的这类手段对提高程序效率所起的作用是微乎其微的。
我们考虑程序的效率的时候,保证了提高程序运行速度时要保持程序的正确性和清晰性。
我们采用了工程化方法作为我们的开发依据,不仅提高了程序系统的效率,更从可读性和可靠性方面得到了改善,给以后的维护工作带来了方便,从整体上增加了系统的性能。
1.3本文使用的开发工具及所采用的关键技术
我们使用的开发工具:
VisualParadigmforUMLEnterpriseEdition(VP-UMLEE)软件作为建模工具。
我们的设计理念:
首先我们采用了面向对象的思想。
面向对象的思想已经涉及到软件开发的各个方面。
如面向对象的分析(OOA,OBJECTORIENTEDANALYSIS)、面向对象的设计(OOD,OBJECTORIENTEDDESIGN)、以及我们经常说的面向对象的编程实现(OOP,OBJECTORIENTEDPROGARMMING)。
面向对象带来了很大的好处,如继承机制,信息隐藏等,然而带来的最大的好处却是对象的思想。
对象不是实体,它可以脱离实体而存在,它描述了自然的语义,最好的软件就是能同构于现实世界的实际,这也就是对象思想最大的优势。
面向对象也使得软件重用变得自然,最大程度的软件重用也使得开发简单而软件的可靠性高。
我们的系统是在原有的类库基础之上开发的,大多是继承已有超类,并且子类沿承超类风格,这也使得软件程序的可读性和可维护性提高。
其次,系统的扩展性大大增强。
最后,模块化使得系统很容易在纵向和水平两个方向拓展:
一方面可以将系统升级为更大、更有力的平台,同时也可以适当增加规模来增强系统的网络应用。
由于摆脱了系统同构性的限制,使得分布数据处理成为可能。
VP-UMLEE这个软件帮助我们实现了这个愿望。
1.4本文要点及组织结构
1.4.1本文要点
本文的主要精华:
一是在软件工程化思想指导之下完成了软件项目管理系统的开发并投入了使用。
该系统是针对一般公司实际业务需要进行的研发,以项目信息为中心,对项目信息做全程跟踪,规范报销流程,项目分门别类的进行记录,对项目涉及单位主要负责人情况有详细登记,提供便捷的综合查询等,对于企业的市场人员和管理人员来说是至关重要的。
本系统的研发工作,满足用户需求,并最终投入了使用,为用户项目管理的规范化发挥了重要的基石作用。
二是利用VP-UMLEE建模工具软件,使本系统可以快速、可靠地开发成功,主要得益于该系统的整个开发过程都遵循了工程化方法:
明确的工作步骤,确定的文档格式,具体的评价标准。
最终的系统非常的规范和标准,并且从需求分析、到概要设计和详细设计再到编程和测试,其中每一步都附有相应的文档来描述,而这些文档也有确定的格式。
文档对软件的可维护性起了决定性的作用,它使得最终投入使用的系统有了较高的可读性、可维护性和可靠性。
该系统实际投入运行后,显示出了运行的稳定性和可靠性,而且有良好的可扩充性和易修改性,这些也都得益于开发过程中工程化方法的运用。
在工程化之外,先进的系统框架结构也为系统高质量研发成功奠定了坚实的基础。
优秀的VP-UMLEE设计软件使得我们的整个业务流程的安全性得到了保障,并使得各个部门之间的相互查询变得更为方便、快捷。
1.4.2本文的组织结构
本文第一章分析了利用VP-UMLEE设计软件研制项目管理系统的背景和必要性,阐述了本文所采取的开发原则,并对所采用的关键技术进行了简要介绍,最后指明了本文工作的主要精华之处。
第二章阐述了相关基础。
利用VP-UMLEE设计软件设计用例图,描述系统需求分析,对公司业务具体描述,并进行了详细的需求说明,主要包括项目登记维护、项目费用登记维护、项目相关单位管理、综合查询、人员管理等几个部分。
第三章深入进行系统分析。
利用VP-UMLEE设计软件所建立的模型或者可以执行,或者表示执行时的时序状态或交互关系。
它包括状态图、活动图、顺序图和合作图等四个图形,也是标准建模语言UML的动态建模机制。
用来确定系统的总体目标、开发环境、系统的设计原则和开发模式,在此基础上对系统的各部进行详细设计,然后给出了相应的状态图、活动图、顺序图和合作图。
第四章严格进行系统设计。
并对系统编码部分,对系统开发环境和编程方法进行了介绍。
第五章系统实现与测试。
对系统提出测试原则,给出测试方法、测试过程和测试结果。
第六章总结与展望。
对本文所作的工作和下一步要解决的问题进行了总结。
第二章设计用户系统需求的相关基础
正如前面曾提到过的,UML的本意是要成为一种标准的统一语言,使得IT专业人员能够进行计算机应用程序的建模。
UML的主要创始人是JimRumbaugh、IvarJacobson和GradyBooch,他们最初都有自己的建模方法(OMT、OOSE和Booch),彼此之间存在着竞争。
最终,他们联合起来创造了一种开放的标准。
(听起来是不是很熟悉?
这个现象类似J2EE、SOAP和Linux的诞生)。
UML成为"标准"建模语言的原因之一在于,它与程序设计语言无关。
(IBMRational的UML建模工具被广泛应用于J2EE和.NET开发。
)而且,UML符号集只是一种语言而不是一种方法学。
这点很重要,因为语言与方法学不同,它可以在不做任何更改的情况下很容易地适应任何公司的业务运作方式。
既然UML不是一种方法学,它就不需要任何正式的工作产品(即IBMRationalUnifiedProcess?
术语中所定义的"工件")。
而且它还提供了多种类型的模型描述图(diagram),当在某种给定的方法学中使用这些图时,它使得开发中的应用程序的更易理解。
UML的内涵远不只是这些模型描述图,但是对于入门来说,这些图对这门语言及其用法背后的基本原理提供了很好的介绍。
通过把标准的UML图放进您的工作产品中,精通UML的人员就更加容易加入您的项目并迅速进入角色。
最常用的UML图包括:
用例图、类图、序列图、状态图、活动图、组件图和部署图。
2.1根据需求设计系统需求用例图
多年来,我们总是利用情节或经历来描述用户和软件系统的交互方式,从而获取需求(McGrawandHarbison1997)。
IvarJacobson(1992)把这种看法系统地阐述成用例(用例)的方法进行需求获取和建模。
虽然用例来源于面向对象的开发环境,但是它也能应用在具有许多开发方法的项目中,因为用户并不关心你是怎样开发你的软件。
而最重要的,用例的观点和思维过程带给需求开发的改变比起是否画正式的用例图显得更为重要。
注意用户要利用系统做什么远远强于询问用户希望系统为他们做什么这一传统方法。
用户的需求说明如下:
我们将从项目执行流程、查询要求、权限问题、表结构的建议设置、项目信息、项目费用信息、项目进展情况、项目相关单位、工作人员管理、备份和数据的导入导出以及人员操作部分等方面详细介绍。
用户系统总体要求:
项目执行流程
市场部业务员将项目信息整理好交市场部秘书处,并协助市场部秘书完成新增项目的信息录入工作,新增项目的阶段默认为“运作中”。
若此业务员还没有系统登陆权限,市场部秘书将其添加进系统。
业务员随时关注项目进展情况,对项目产生的相关信息及时登陆系统作登记,市场部秘书对业务员登记的信息进行核对,对有疑问的内容及时与相应业务员联系核实,确实有误进行修改,并填写备注信息加以说明。
查询要求
公司领导可以查询每个项目的所有详细信息,可以按项目类型、项目阶段进行分类查询,统计项目金额的情况,可以分类统计项目的相关信息。
项目基本信息为公共信息,其他信息,如项目费用查询等根据具体操作人员的权限而定。
权限问题
基本原则就是市场部业务人员只有登记项目费用、项目进展情况、项目相关单位信息,及查询项目基本信息和自己所负责的项目的详细信息的权限。
市场部秘书作为超级管理员具有数据库管理、数据备份和所有项目内容修改的权限。
领导可以看到所有信息,但出于对数据安全性和一致性的考虑,暂不具有修改数据的权限,具体修改的录入工作有市场部秘书负责。
另外,如果市场部务人员登记信息中出现了误操作或者漏操作则由市场部秘书负责将操作补齐或者更改回正确的,但是在备注中应该有更改说明。
建议设置的几个表结构
项目情况表:
项目编号、项目所在区域编号,项目所在区域名称、项目类别、项目名称、项目建档人、项目状态、项目启动时间、项目金额、备注信息。
项目费用表:
项目阶段、姓名、日期、差旅费、住宿费、市内交通费、招待费、餐饮费、礼品费、其他费用、费用合计、备注信息。
项目相关单位情况表:
项目阶段、当前进展描述、近期目标、工作计划、填写人、填写时间。
项目进展情况表:
单位名称、联系人、职位、办公电话、手机号、E一。
li、单位
地址、邮政编码和备注。
工作人员表:
人员编号、姓名、人员口令、姓名拼音
代码表:
代码编号、代码、代码内容
根据用户需求,我们从工程化角度对对用户的需求进行分析,然后设计为用户更多服务的项目管理系统。
首先,根据用户提供的需求说明以及与用户的交流和讨论,我们获取了用户的基本需求。
所以在需求分析阶段我们要做的主要工作是对用户需求进行分析。
分析用户需求主要是通过建立模型的方式来描述用户的需求,为客户、用户、开发方等不同参与方提供一个交流的渠道。
这些模型是对需求的抽象,以可视化的方式提供一个易于沟通的桥梁。
用户需求的分析与获取用户需求有着相似的步骤,区别在于分析用户需求时使用模型来描述,以获取用户更明确的需求。
用于需求建模的方法有很多种,最常用的包括数据流图(DDF)、实体关系图(ERD)和用例图(UseCase)三种方式。
DDF作为结构化系统分析与设计的主要方法,已经得到了广泛的应用,DFD尤其适用于MIS系统的表述。
DDF使用四种基本元素来描述系统的行为,过程、实体、数据流和数据存储。
DFD方法直观易懂,使用者可以方便地得到系统的逻辑模型和物理模型。
我们使用VP-UMLEE软件,按照以下设计步骤,生成用户需求用例图(UseCase)如图1。
用例图Usecasediagrams描述了作为一个外部的观察者的视角对系统的印象。
强调这个系统是什么而不是这个系统怎么工作。
用例图与情节紧紧相关的。
情节是指当某个人与系统进行互动时发生的情况。
图1系统需求用例图
实施前期准备工作,首先对用户的问题进行调研,有非常深刻完善的理解;确保系统能够解决用户的所有问题;其次,把用户的需求真正地反应到系统模型,并对以后的设计和开发过程提供说明和框架,再根据需求生成UI界面。
用例图的建立步骤:
1〉找出系统外部的活动者和外部系统,确定系统的边界和范围。
此系统外部主要是工作人员,这些工作人员中,主要是市场部秘书,他是超级管理员和市场部秘书双重身份;另外是市场部业务员、市场部部长、公司领导。
2〉确定每一个活动者所希望的系统行为。
这些行为是用户所提出的,在图中加以说明和显示。
3〉把这些系统行为命名为用例。
4〉把一些公共的系统行为分解为一批新的用例,供其它的用例引用。
把一些变更的行为分解为扩展用例。
比如:
项目、项目费用等。
5〉编制每一个用例的剧本。
6〉绘制用例图,如图1所示。
7〉区分主业务流和例外情况的事件流。
可以把表达例外的情况的事件流的用例图画成一个单独的子用例图,如图2所示。
8〉精化用例图,解决用例图的重复与冲入问题,简化用例中的对话序列,用例图可以有不同的层次,高层次系统的用例可以分解为若干个下属子系统中的子用例。
通过图1说明:
用户通过我们设计的系统,可以实现高效、准确的项目管理。
2.2用户需求用例图中的建模类图设计
在用户需求分析阶段,我们对具体项目的需求出发,设计该系统共有以下几个实体:
项目、项目费用、项目进展情况、项目相关单位情况、工作人员。
并且每个实体集,即记录规定了具体字段。
实体集<工作人员>工作人员编号、姓名、口令,实体集<项目>项目编号、项目所在区域编号,项目所在区域名称、项目类别、项目名称、项目建档人、项目状态、项目启动时间、项目金额、备注。
实体集<项目费用>项目阶段、姓名、日期、差旅费、住宿费、市内交通费、招待费、餐饮费、礼品费、其他费用、费用合计、备注。
实体集<项目进展情况>项目阶段、当前进展描述、近期目标、工作计划、填写人、填写时间。
实体集<项目相关单位情况>单位名称、联系人、职位、办公电话、手机号、E一mail、单位地址、邮政编码和备注。
实体之间的关系:
操作:
实体集[工作人员」与[项目〕之间的N:
N联系,即一个工作人员可以操作多个项目,一个项目可以被多个工作人员操作。
属于,实体集[项目〕与[项目进展情况]之间的1:
N联系,即一个项目开张过程中可记录很多条情况记录,而一条情况记录只可属于一个项目,同理〔项目〕与〔项目进展情况]之间,[项目〕与[项目相关单位情况]之间也是1:
N联系。
记录:
实体集[工作人员〕与[项目费用〕之间的N:
N联系,即一个工作人员可以记录多个项目的费用信息,一个项目的费用也可以由多个工作人员来记录。
同理〔工作人员与[项目进展情况]之间,[项目〕与〔项目相关单位情况]之间也是N:
N联系。
为了细化用户需求用例图,表达系统的类以及这些类之间的关系,进一步设计建模类图。
类是对象的集合,展示了对象的结构以及与系统的交互行为。
类主要有属性(Attribute)和方法(Method)构成,属性代表对象的状态,如果属性被保存到数据库,此称之为“持久化”;方法代表对象的操作行为,类具有继承关系,可以继承于父类,也可以与其他的Class进行交互。
类图展示了系统的逻辑结构,类和接口的关系。
类图是静态的,但它能显示出什么可以产生影响,为下面分析什么时候产生影响打好基础。
下面以系统管理模块中的数据查询模块为例,使用VP-UMLEE设计其类图。
对象类图的建立步骤:
1〉研究分析问题领域,确定系统的需求。
根据用户要求,有四方面数据需要查询:
工作人员对项目情况、项目费用、项目进展、项目相关单位情况的查询。
2〉分析查询对象和对象类,明确他们的含义和责任,确定属性和操作。
3〉发现类之间的静态联系。
着重分析找出对象类之间的一般和特殊关系,部分与整体关系,研究类的继承性和多态性,把类之间的静态联系用关联、泛化、聚合、组合、依赖等联系表达出来,虽然对象类图表达的是系统的静态结构特征,但是应当把对系统的静态分析与动态分析结合起来,更能准确地了解系统的静态结构特征。
4〉设计类与联系。
调整和精化已得到的对象类和类之间的联系,解决诸如命名冲突、功能重复等问题。
5〉绘制对象类图并编制相应的说明。
上述做法是直接从领域分析抽取对象和对象类开始的,这是常规的面向对象的系统分析与设计的做法。
Rational统一过程主张采用用例驱动的系统分析与设计方法。
从业务领域的分析中先抽取活动者和用例,建立业务模型。
业务模型包括业务用例模型、设计模型、实现模型和测试模型。
系统管理的数据查询类图如图2所示。
图2系统管理的数据查询类图
2.3系统建模时序图的设计
顺序图的建立步骤:
1〉确定交互的上下文。
2〉找出参与交互的对象类角色,把他们横向排列在顺序图的顶部,最重要的对象安置在最左边,交互密切的对象尽可能相邻。
在交互中创建的对象在垂直方向应安置在其被创建的时间点处。
3〉对每一个对象设置一条垂直的向下的生命线。
4〉从初始化交互的信息开始,自顶向下在对象的生命线之间安置信息。
注意用箭头的形式区别同步消息和异步消息。
根据顺序图是属于说明层还是属于实例层,给出消息标签的内容,以及必要的构造型与约束。
5〉在生命线上绘出对象的激活期,以及对象创建或销毁的构造型和标记。
6〉更具消息之间的关系,确定循环结构及循环参数和出口条件。
以查询时序图为例,使用VP-UMLEE建立查询顺序图如图3所示。
图3查询顺序图
从查询顺序图可以看出,市场部秘书查询级别最高,其他人直接向他提出要求,即可得到查询报表;领导与市场部部长均可直接对系统项目中的各类信息进行查询(图中省略);只允许市场部业务员随时关注项目的进展情况,随时进行与用户的协调工作。
2.
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- VPUMLEE 设计 指南