基于UML的电子商务系统建模研究与应用.docx
- 文档编号:9810923
- 上传时间:2023-05-21
- 格式:DOCX
- 页数:69
- 大小:66.57KB
基于UML的电子商务系统建模研究与应用.docx
《基于UML的电子商务系统建模研究与应用.docx》由会员分享,可在线阅读,更多相关《基于UML的电子商务系统建模研究与应用.docx(69页珍藏版)》请在冰点文库上搜索。
基于UML的电子商务系统建模研究与应用
研究生课程(论文类)试卷
2012/2013学年第一学期
课程名称:
系统建模与仿真
课程代码:
12000025
论文题目:
基于UML的电子商务系统建模研究与应用
学生姓名:
专业﹑学号:
信号与信息处理122460335
学院:
光电信息与计算机工程学院
课程(论文)成绩:
课程(论文)评分依据(必填):
任课教师签字:
日期:
年月日
课程(论文)题目:
基于UML的电子商务系统建模研究与应用
摘要
电子商务系统是商务和技术结合的产物,对于大型复杂的电子商务系统,
其开发周期已不再是从需求定义、软件设计、实现和交付的一次性过程,而是
一个连续的、递增的、不断迭代的过程,要高效快速地开发一个安全、健壮、
性能良好的电子商务系统,需要重视和强调系统的建模。
UML是面向对象软件开发中的一种通用、统一的图形模型语言,是用于软
件系统规约化、可视化构造和建模的有效工具。
其提供的各类图形在面向对象
开发的软件系统的建模过程中得到了广泛使用,设计人员借助于这些标准图形,
直观、形象、准确地刻画系统模型,使软件开发易于实施。
本文在深入分析研究软件工程领域新思想、新方法和新技术的基础上,以
UML为建模语言,以RUP统一开发过程为方法论指导,对电子商务系统的建
模进行了研究,并针对电子商务系统的体系结构及其特点,分析了基于UML
的电子商务系统建模的关键技术,提出了基于UML的电子商务系统的建模过
程。
从系统的业务建模开始,分别对系统进行了需求建模、对象建模、数据库
建模和物理建模,为系统建立了各种模型,以模型为驱动来实现电子商务系统
的开发。
最后,本文以网上购物系统为实例,分析并研究了基于UML的电子商务系
统的建模过程,建立了系统的用例模型、静态结构模型、动态行为模型、数据
库模型和物理模型等,并通过这些模型实现并测试了网上购物系统。
第一章绪论
本章概括介绍了课题的研究背景,阐明了本文的研究内容和主要工作,介
绍了本文的组织结构。
20世纪90年代以来,计算机网络技术得到了飞速发展,信息的处理和传递
突破了时间和地域的限制,信息技术的运用和推广给用户带来了无比的方便和
快捷,信息化、网络化和以人为本成为信息时代的基本特征。
由于网络的实时
性、方便性、快捷性和低成本性,互联网已进入社会生活的各个领域和环节,
人们日常生活中的许多活动都将逐步转移到网络上来,能够足不出户办到需要
办的事情,已不再是梦想。
根据中国互联网络信息中心(CNNIC)2008年1月发布的《第21次中国互
联网络发展状况统计报告》显示,中国网民总数己经达到2.1亿,网民平均每
周上网时间为16.1小时,Internet成为人们获取信息的重要手段,电子商务也
成为网民使用Internet的一种重要原因,其中19%的网民经常使用Internet购物,
而其中又有57.9%的网民选择网上支付,这说明电子商务在中国不断发展。
赛
迪顾问发布《2006-2007年中国电子商务市场研究年度报告》显示,截至2006
年年底,中国电子商务市场共实现交易额1.1万亿元人民币,同比2005年增长
了48.6%。
电子商务给中国许多企业带来了无限商机,越来越多的企业正在或
即将加入到电子商务中,这就要求相应的电子商务系统来满足企业电子商务的
发展需要。
但是企业规模的不同对电子商务系统的要求也不同,而且系统的费用也差
别很大。
目前各大电子商务软件厂商不断地开发电子商务类的软件并将相关软
件升级换代,使企业的负担越来越重,同时企业对电子商务解决方案的依赖程
度也越来越高。
因此,如何开发满足企业要求的电子商务系统已成为电子商务
系统开发人员必须面对的问题。
电子商务系统是企业内部网与Internet的集成,与传统的管理信息系统有
相同点,也有不同点。
电子商务系统具有互连网的特性,由于部分环节技术还
不够成熟,如果不加选择随意使用传统的软件开发方法进行开发,容易产生一
些问题。
目前适合电子商务系统特点和要求并在实际工作中富有成效的设计方
法有瀑布式开发模型、快速原型法、基于组件的电子商务系统设计方法、MVC
设计模式等。
这些方法着重于过程的描述,在电子商务系统开发过程中还存在
不足。
UML(UnifiedModelingLanguage,统一建模语言)是用来说明面向对象开
发系统的产品,是为系统建模、描述系统架构的标准建模语言,在全世界得到
了广泛的支持和普及应用。
UML的目标是以面向对象的方式来描述系统,具
有很宽的应用领域,主要用于建立软件系统的模型,也可以用于描述不带任何
软件的机械系统、企业机构、企业过程、复杂的数据信息系统、具有实时要求
的工业系统或工业过程、嵌入式实时系统、分布式系统、系统软件、商业系统
等。
总之,UML是一个通用的标准建模语言,可以对任何具有静态结构和动
态结构的系统进行建模。
运用UML对电子商务系统进行建模,在分析和设计
阶段建立良好的系统模型,根据建立起的模型进行编码,这样能降低开发成本,
缩短开发周期,减少开发风险,从而保证系统的正确实施。
第二章UML与RUP概述
UML概述
2.1.1UML的产生与发展
面向对象建模语言在20世纪70年代中期开始出现,其后众多的面向对象
方法学家都在尝试用不同的方法进行面向对象分析与设计。
从1989年到1994
年,面向对象建模语言的数量从不到10种增加到50多种。
虽然每种建模语言
的创造者都在努力推广自己的方法,并在实践中不断完善,但是,面向对象方
法的用户并不了解不同建模语言的优缺点及它们之间的差异,很难在实际工作
中根据应用的特点选择合适的建模语言,甚至爆发了一场“方法大战”。
到了
90年代中期,出现了第二代面向对象方法,其中最著名的是Booch'93,OMT-2
和OOSE等方法。
GradyBooch是面向对象方法最早的倡导者之一,提出了面向对象软件工程
的概念。
1991年他把以前面向Ada的工作扩展到整个面向对象设计领域。
他提
出的Booch'93方法比较适合于系统的设计和构造。
JamesRumbaugh等人提出的对象建模技术(ObjectModeling
Technique,OMT)方法,采用了面向对象的概念,并引入了各种独立于语言的
表示符号。
这种方法用对象模型、动态模型和功能模型,共同完成对整个系统
的建模,所定义的概念和符号适用于软件开发的分析、设计和实现的全过程,
软件开发人员无需在开发过程的不同阶段进行概念和符号的转换。
OMT-2方法
特别适用于描述和分析以数据为中心的信息系统。
IvarJacobson于1994年提出了OOSECObject-OrientedSoftwareEngineering,
面向对象的软件工程)方法,其最大特点是面向用例(UseCase),并在用例的描
述中引入了外部角色的概念。
用例的概念是精确描述需求的重要工具,用例贯
穿于整个开发过程,包括对系统的测试和验证过程。
DOSE比较适合支持商业
工程和需求分析。
面对众多的建模语言,用户很难找到一种最适合其应用特点的语言,而且
不同建模语言之间存在的细微差别极大地妨碍了用户之间的交流。
面向对象方
法发展的客观现实要求在精心比较不同建模语言的优缺点及总结面向对象技术
应用经验的基础上,组织联合设计小组,根据应用的需要,集中各种面向对象
方法的优点,克服缺点,统一建模语言,UML由此而生。
2.1.2UML的发展
1994年10月,Booch和Rumbaugh开始致力于统一建模语言的工作,他们
首先把Booch'93和OMT-2统一起来,并于1995年10月发布了第一个公开版
本,称为“统一方法(UnifiedMethod)"UM0.801995年秋,OOSE方法的创始
人Jacobson也加入到这项工作中,并贡献了他的用例思想。
经过三个人的共同
努力,于1996年6月和10月分别发布了两个新的版本,即UML0.9和UML0.91
并把UM改名为“统一建模语言(UnifiedModelingLanguage)"UMLo
1997年1月,UML1.0被提交给对象管理组织OMG,作为标准化软件建模
语言的候选者。
在其后的半年多时间里,许多重要的软件开发商和系统集成商,
如Microsoft,IBM,HP,Oracle,RationalSoftware等,都成为“UML伙伴”,
它们积极地使用UML并提出反馈意见,以完善、加强和促进UML的定义工作,
对UML1.1(1997年9月)的定义和发布起了重要的促进作用。
1997年9月,UML
1.1再次被提交给OMG组织,并于1997年11月17日正式被OMG采纳作为
基于面向对象技术的标准建模语言。
此后,UML一直没有停止前进的步伐,1998
年、1999年和2001年分别发布了UML1.2,UML1.3和UML1.4,其中UML1.3
是较为重要的修订版。
经过对UML的重大修订,于2003年6月正式通过了
UML2.0。
UML2.0的推出是为了帮助简化模型驱动的开发,其中增强了语义部分,
可帮助模型更好地支持元数据交换,这一切的目的在于使UML成为一种胜过
大多数文本语言的高层次语言,能直接生成代码和进行逆向工程,甚至直接生
成某些可执行的UML模型。
现在,OMG已经把UML作为公共可得到的规格
说明(PubliclyAvailableSpecification)提交给国际标准化组织(ISO),进行国际标
准化。
UML2.0通过提供稳定的技术基础结构(这种结构考虑到了软件开发过程
的更多的自动化功能)支持人们开始对模型驱动架构的应用。
下面是出自该需
求规范的四个目标,它们是促使UML发展进化的突出驱动者。
(1)使得该语言对软件实体进行建模变得更加可行。
(2)对流程和动作建模提供更健壮的机制。
(3)为不同工具之间的通信创建一个标准。
(4)在一个标准的建模框架内协调UMLo
UML2.0标准对UML1.4进行了扩充,添加了一部分自己特有的图,这些
图能更好地描述建模的过程。
在UML2.0中用更为受限的通信图代替了协作图,
还增加了几种新的图,如交互综述图、定时图、协议状态图、组成结构图等。
2.1.2UML的结构
UML是一种标准的图形化(即可视化)建模语言,它由图和元模型组成。
图
是UML的语法,而元模型给出图的含义,是UML的语义。
(1)UML的语义
UML的语义是定义在一个四层(四个抽象级别)建模概念框架中的,这四层
分别是:
①元元模型(meta_metamodel)层
由UML最基本的元素“事物(thing)”组成,代表要定义的所有事物。
②元模型(metamodel)层
由UML基本元素组成,包括面向对象和面向构件的概念。
这一层的每个概
念都是元元模型中“事物”概念的实例(通过版类化)。
③模型(model)层
由UML模型组成,这一层的每个概念都是元模型层中概念的实例(通过版
类化)。
这一层的模型通常称为类模型或类型模型。
④用户模型(usermodel)层
由UML模型的例子组成,这一层中的每个概念都是模型层的一个实例(通
过分类),也是元模型层概念的一个实例(通过版类化)。
这一层的模型通常称为
对象模型或实例模型。
(2)UML的表示法
UML由视图(view)、图(diagram)、模型元素(modelelement)和通用机制
(generalmechanism)等几个部分组成。
①视图
为了完整地描述一个系统,往往需要描述该系统的许多方面。
用视图可以
表示被建模系统的各个方面,也就是说,从不同目的出发可以为系统建立多个
模型,这些模型都描述同一个系统,只是描述的角度不同,它们之间具有一致
性。
②图
图是用来表达一个视图的内容的,通常,一个视图由多张图组成。
UML语
言共定义了9种不同的图,把它们有机地结合起来就可以描述系统的所有视图。
③模型元素
可以在图中使用的概念(例如:
用例、类、对象、消息和关系),统称为模型
元素。
模型元素在图中用相应的视图元素(图形符号)表示。
一个模型元素可以
用在多个不同的图中,不管怎样使用,它总是具有相同的含义和相同的符号表
示。
④通用机制
UML语言利用通用机制为图附加一些额外的信息,比如,可以在“笔记”
中书写注释,或用“标签值”说明模型元素的性质等。
此外,它还提供扩展机
制(例如,版类、标签值、约束),使UML能够适应一种特殊方法或满足某些特
殊用户的需要。
2.1.3UML的建模机制
UML可以对任何具有静态结构和动态行为的系统进行建模,其建模机制可
以分为静态建模机制和动态建模机制两大类。
(1)静态建模机制
静态建模机制是UML的基础,它包括以下内容。
①用例图
用例是对系统提供的功能(即系统的具体用法)的描述。
用例图从用户的角度
描述系统功能,并指出各个功能的操作者。
用例图定义了系统的功能需求。
②类图
类图不仅定义系统中的类,表示类与类之间的关系(例如,关联、依赖、泛
化和细化等关系),也表示类的内部结构(类的属性和操作)。
类图描述的是一种
静态关系,在系统的整个生命期内都是有效的。
③对象图
对象图是类图的实例,它使用几乎与类图完全相同的图示符号。
两者之间
的差别在于,对象图表示的是类的多个对象实例,而不是实际的类。
由于对象
有生命周期,因此对象图只能在系统的某个时间段内存在。
一般说来,对象图
没有类图重要,它主要用来帮助对类图的理解,也可用在协作图中,表示一组
对象之间的动态协作关系。
④包
包是一个用来将模型元素分组的通用机制。
可以将一个系统看作一个单一
的、高级的包。
包可以有包名,以与其它包相区分。
包可以含有类、接口、组
件、节点、协作或其它的包。
包所含有的元素要在包中声明,如果包被破坏,
包中的元素也被破坏,每个元素只能被一个包所拥有。
一个包形成了一个命名
空间,这意味着在一个包中,同种元素必须有不同的名字。
⑤组件图
组件图描述代码组件的物理结构及各个组件之间的依赖关系。
组件可能是
源代码、二进制文件或可执行文件。
使用组件图有助于分析和理解构件之间的
相互影响。
⑥配置图
配置图用来定义系统中软件和硬件的物理体系结构。
通常,配置图中显示
实际的计算机和设备(用节点表示),以及各个节点之间的连接关系,也可以显
示连接的类型及构件之间的依赖关系。
在节点内部显示可执行的构件和对象,
以清晰地表示出哪个软件单元运行在哪个节点上。
(2)动态建模机制
动态建模机制描述了执行系统功能的各个角色之间相互传递消息的动态关
系。
动态建模机制包括以下内容。
①消息
在面向对象的编程中,两个对象之间的交互是通过一个对象向另一个对象
发送消息来完成的。
在UML图形上,一个消息被绘制为一条位于该消息的发
送者和接收者之间的带有箭头的直线,箭头类型指示了消息的类型。
②状态图
状态图描述类的对象可能具有的所有状态,以及引起状态变化的事件,状
态变化称作状态转换。
通常,状态图是对类图的补充。
实际使用时,并不需要
为每个类都画状态图,仅需要为那些有多个状态,且其行为在不同状态有所不
同的类画状态图。
③时序图
时序图显示若干个对象间的动态协作关系,它强调对象之间发送消息的先
后次序,描述对象之间的交互过程。
④协作图
协作图与时序图类似,也描述对象间的动态协作关系。
除了显示对象间发
送的消息之外,协作图还显示对象及它们之间的关系(称为上下文相关)。
由于
时序图和协作图都描述对象间的交互关系,所以建模者可以选择其中一种表示
对象间的协作关系:
如果需要强调时间和顺序,最好选用时序图;如果需要强
调上下文相关,最好选择协作图。
⑤活动图
活动图主要是一个流图,描述了从活动到活动的流。
活动是在状态机中进
行的一个非原子的执行,它由一系列的动作组成。
动作是由可执行的不可分的
计算组成,这些计算可以引起系统的状态发生变化或者返回一个值。
2.1.4UML的应用领域
UML的目标是以面向对象图的方式来描述系统,具有很宽的应用领域。
其
中最常用的是建立软件系统的模型,但它同样适用于描述非软件领域的系统,
如机械系统、企业机构或业务过程,以及处理复杂数据的信息系统,具有实时
要求的工业系统或工业过程等。
此外,UML适用于系统开发过程中从需求分析
描述到系统完成后测试的不同阶段。
(1)需求分析阶段
UML的用例视图可以表示客户的需求,通过用例建模可以对外部角色以及
它们所需要的系统功能建模,角色和用例是用它们之间的关系通信建模的,每
个用例都指定了客户的需求,他需要系统干什么,不仅要对软件系统进行需求
分析,而且对商业过程也要进行需求分析。
(2)分析阶段
本阶段主要考虑所要解决的问题,可用UML的逻辑视图和动态视图来描
述,类图描述系统的静态结构,协作图、状态图、序列图、活动图和状态图描
述系统的动态特征,在分析阶段只为问题领域的类建模,不定义软件系统解决
方案的细节,如用户接口的类、数据库等。
(3)设计阶段
在设计阶段,把分析阶段的结果扩展成技术解决方案,并提出技术框架,
例如,用户界面、面向对象数据库的永久性对象和系统接口等。
该阶段最后为
系统实施阶段产生详细说明文档。
(4)构造阶段
把设计阶段的类转换成某种面向对象程序设计语言的代码,在对UML表示
的分析和设计模型进行转换时,最好不要直接把模型转化成代码,因为在早期
阶段模型是理解系统并对系统进行结构化的手段。
(5)测试阶段
对系统的测试通常分为单元测试、集成测试和系统测试等几个不同级别测
试,单元测试使用类图和类的定义文档,集成测试使用协作图,系统测试使用
用例图,用例图可以用于证实客户所期望的系统行为。
总之,标准建模语言UML不仅适用于以面向对象技术来描述任何类型的系
统,而且适用于系统开发的不同阶段,从需求规格描述直至系统完成后的测试
和维护。
2.2RUP概述
2.2.1RUP的特点
(1)RUP简介
UML作为一种广泛应用的建模语言,不是一种方法,它独立于开发过程。
建模语言是设计的表示符号,而过程则是描述进行开发所需的步骤。
UML的应
用必然以系统的开发过程为背景,但不同的组织和不同的应用领域,需要采用
不同的开发过程。
成功的应用UML还是需要科学的过程,以有效规范控制工
作进程,改进和提高工作效率。
RUP(RationalUnifiedProcess}Rational统一过程)是由UML的创始人
Booch,Rumbaugh和Jacobson在创建UML的同时提出来的,它是由Rational
公司开发、维护并销售的软件工程化过程,它提供了在开发机构中分派任务和
责任的纪律化方法。
它的目标是在可预见的日程和预算前提下确保满足最终用
户需求的高质量产品。
RUP对开发过程中的关键开发活动都提供了准则、模板和工具作为理解的
知识基础。
通过对相同知识基础的理解,在需求分析、设计、实现、测试、项
目管理或变更的过程中就能使得开发人员得到一致的认识和视图模型。
RUP比
一般的软件开发过程具有以下的优势:
①RUP提高了团队生产力。
②RUP的活动创建并维护模型。
③RUP是一个可配置的过程。
④基于组件的体系结构。
⑤验证软件质量。
⑥控制软件的变化。
C2)RUP的特点
以用例为驱动、以架构为中心、迭代和增量式的开发过程,是使用RUP进
行软件开发的基本特点,也是RUP的核心内容。
①用例驱动
用例驱动强调了软件开发的过程中以用户对系统的需求为根本的出发点和
基础。
用例代表了用户的系统化的需求,用例驱动可以保证在系统开发的过程
中,特别是早期的分析与设计不偏离用户需求,保证后续的工作都是为了满足
用户功能需求。
②以架构为中心
以架构为中心指软件是由不同的用例决定的若干个子系统构成的,各个子
系统之间的相互结合的方式就是软件系统的架构,软件开发要以软件的架构作
为最基本的标准,在统一的架构的指导下来进行。
软件的架构要在软件分析与
设计的阶段确定下来,保证整个软件开发的可行性。
这是保证软件开发过程顺
利进行的基础。
③迭代和增量
RUP中最重要的思想在于迭代和增量的过程,这是它的核心所在。
迭代和
增量的开发过程是指软件开发中的每一个阶段可以根据自身的特点划分成不同
的小的项目,每一个小的项目内部要经历需求、分析、设计、实现到测试这五
个软件开发的核心步骤。
每次的迭代都产生软件产品的一个新的版本,意味着
功能的增加和完善。
计划一小步,实现一小步,测试一小步,成功一小步,尽
最大可能确保每一个阶段的工作都是有效的、成功的。
这种“计划一实现一测
试”的开发过程,在每一次迭代过程中都进行测试,保证了移交到下一个阶段
的成果不会发生重大的错误。
2.2.2RUP的四大阶段
RUP中的软件生命周期在时间上被分解为四个顺序的阶段:
初始阶段
(Interception)、细化阶段(Elaboration)、构造阶段(Construction)和交付阶段
(Transition),每个阶段的结果都是一个里程碑。
在每个阶段的结尾执行一次评
估以确定这个阶段的目标是否己经满足,如果评估结果令人满意的话,才可以
进入下一个阶段。
在每个阶段都可以继续细分成迭代,后一次迭代是在前一次
基础上增加了更多的内容,整个开发过程增量向前发展。
(1)初始阶段
初始阶段的主要目标是获得项目的基础。
这一阶段主要围绕特定的产品,
描述工程所管辖的范围、整体需求、涉及到的费用和主要风险。
这一阶段,通
常要建立一个用做概念验证的可执行原型。
开始阶段的成果包括:
前景文档(对
核心项目需求、关键性质的一个一般性前景说明)、一个最初的用例模型(大约
是系统用例的10%-20%左右)、一个最初的项目词汇表、一个最初的商业用例(包
括商业环境及成功的准则)、一个最初的风险评估、一个项目规划、一个或多个
原型。
初始阶段的里程碑是生命周期的目标。
在初始阶段最后,检查项目的生命
周期目标,决定是否继续进行全范围的开发。
(2)细化阶段
细化阶段的主要目标是分析问题域,建立一个健全的、合理的体系结构基
础,制定开发项目计划,并为项目的最高风险提出解决方案。
为了达到这个目
标,必须对系统有一个广泛的认识,对整个系统的构架有一定的理解。
本阶段
的成果包括:
用例模型(至少完成了80%,识别出了所有的用例和角色,以及大
多数的用例描述)、一些增加的需求(包括非功能性需求,以及任何与特定用例
无关的需求)、软件构架描述、一个可执行的构架原型、一个修正后的风险表,
并获得了利益相关人的认可和一份足够详细的项目计划。
细化阶段的里程碑是创建了可执行的构架基线。
该构架不是原型而是一个
可真正执行的系统。
该系统将在后续阶段演化为最终可提交系统。
这一阶段是
最关键的。
在细化阶段最后,检查已经细化的目标和范围、产品的前景是否稳
定、构架是否稳定等因素,决定是否进入构造阶段。
(3)构造阶段
构造阶段的主要目标是把细化阶
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 基于 UML 电子商务 系统 建模 研究 应用