网购物系统uml的分析与设计(定稿)—-毕业论文设计.doc

网络购物系统的UML分析与设计
摘要：论文简单的描述了UML的基本概念和发展历史，并且分析了目前运用UML存在的一些问题，通过在实际的设计开发中，运用UML对网络购物系统的开发例子来阐述UML的一些实现原理。
关键词：UML 系统分析 面向对象设计
1.UML简介和背景：
UML是有世界著名的面向对象技术专家G.BOOCH，J.RUMBAUGH，和I.JACOBSON发起，在BOOCH方法，OMT方法和OOSE方法的基础上，汲取其他面向对象方法的优点，广泛征求意见，几经修改而完成的。目前UML得到了诸多大公司的支持，已经成为面向对象技术领域内占主导地位的标准建模语言。
目前最新的UML规范说明是2003年3月发布的1.5版本。OMG在同时进行两个UML版本的工作，一个是对1.X版本的改进工作，一个是有较大改动的版本2.0的工作。OMG从2001年开始UML2.0的工作，由于UML2.0是一个比较大的升级工作，其发布时间也一再的推迟。经过对2.0版本草案的多次征求意见和修改，2003年8月，OMG发布了最后的征求意见版本。正式的版本将很快发布。在UML建模语言成为标准之前，有很多的OO方法，每种方法都说自己是最好的，出现了所谓的方法学大战。随着UML被OMG采纳为标准，面向对象领域的方法学大战也随之结束。UML在学术界和工业界越来越受到重视。
2. 目前运用UML存在的一些问题：
自从OMG提出UML以来,随着它的不断完善发展, UML逐渐被很多企业接受认可, 在很短的时间内，UML已经成为软件工业中占支配地位的建模语言。但目前在国内外UML的运用情况却不是很好。2002年6月底,BZ公司对226个个体进行了调查,结果是有34%的开发人员运用UML进行系统开发的建模,62%的开发人员不用UML进行开发,4%的开发人员不太确定[1].究其原因是UML1.4还存在以下几个方面的不足:
1目前UML很多地方运用难以解释的字符来描述系统的功能、系统的行为和计算,不易于理解。并且没有对数据操作进行定义,很多对象之间的行为过程没有加以说明，如：对象之间关系的操作（relationship manipulation），这些都迫切需要一个标准化的行为描述语言(Action Specification Language)来对系统的行为进行精确的描述。
2 UML虽然是一种面向对象的软件系统设计的标准描述语言，但是在其状态图中用状态和迁移表示对象行为关联时用到了大量的不易于理解的注释字符，因此，系统的UML模型既不是可以执行的也是不和用编程语言开发的可执行程序相协调。
3在不同的技术实现平台上（如：实现语言，软件环境）对同样需求的系统建模时细节差别很大，系统构建模型的重用性就很低。这样在计算机技术正在向各个方向快速发展的今天，老的遗留系统必须和新技术的实施平台，开发技术相协调，使得新旧系统之间的集成或系统的演化面临不同的实现技术，老的遗留系统在运用新技术进行重构时，必然要浪费很多财力，人力进行系统模型的更新甚至完全重建系统。
3.网络购物系统的分析：
3.1网络购物系统的需求分析：
1：普通用户可以登陆系统，成为登陆后用户。
2：普通用户只具有搜索产品、查看产品分类、查看产品项目、查看产品等几个基本权限。
3：除提供一般权限外，本系统还可为登陆后用户提供编辑帐号、购物车、定单、结算的功能和服务。
4：登陆后用户可修改购物数量。
3.2 用例分析：
确定参与者：
1谁使用系统的主要功能？
2谁需要从系统获得对日常工作的支持和服务？
3需要谁维护管理系统的日常运行？
4公司的哪个部门使用系统？
5系统需要与其它哪些系统交互？
6谁需要使用系统产生的结果？
针对网上购物系统的前台系统，通过回答以上问题，可以得到执行者有三类，顾客，管理员和一般员工。
确定用例:
1系统需要哪些输入/输出？这些输入/输出从何而来？到哪里去？
2执行者是否需要对系统中的信息进行读、创建、修改、删除或存储？
创建用例
（1）订单处理
（2）订单维护
（3）订单状态查询
（4）个人信息维护
（5）订购
（6）接收发货
（7）库存查询
（8）缺货拒绝
（9）商品查询
（10）商品信息维护
（11）销售查询
（12）员工信息维护
（13）报表维护
（14）订单增加
（15）订单删除
创建用例图
系统管理的用例图如下图1

图1 系统管理用例图
系统用户的用例图如下图2所示

图2 系统用户的用例图
3.3类图分析：
画类图和理解类图时都应采用三个层次的观点。这些观点也适用于其它模型。三个层次的观点不是UML的组成部分，但对建造模型或评价模型都非常有用，且都可应用于UML.（1）概念层描述应用域中的概念，是对现实世界的直接描述，与实现它们的类有关但与实现方案和实现语言无关。（2）说明层描述软件的接口，而不是软件的实现。一个类型描述一个接口，但可能有多种实现。（3）实现层从实现的角度定义类及其实现，揭示了软件实现体的构成情况。
针对当前系统1产品类（Product）的主要操作：设置和获取每个属性值的方法。
2产品类别类（Category）的主要操作：设置和获取每个属性值的方法。
3产品项目类（Item）的主要操作：设置和获取每个属性值的方法
4订单类（Order）的主要操作：设置和获取每个属性值的方法、初始化订单（initOrder）、增加产品项目（addLineItem）等。
5购物车类（Cart）的主要操作：设置和获取每个属性值的方法、增加产品项目（addItem）、删除产品项目（removeItemById）等。
6购物车项目类(CartItem) 的主要操作：设置和获取每个属性值的方法、统计金额（calculateTotal）等。
下面是系统的类图，见图3

图3 网上购物系统的类图

3.4系统的时序图分析：
顺序图可描述几个对象间的动态协作关系，它非常直观的展示了对象之间传递消息的时间顺序。反映了系统执行过程中某个特定时刻所发生的事情。在系统分析时，可对主要对象类绘制顺序图，以便分析系统的行为，验证和修改系统的静态结构，满足用户的需求，达到系统的目标。
顾客订购的时序图如下图4所示：
顾客首先使用自己的帐号和密码进行登陆系统，登陆模块会将客户的ID保存在系统缓存中，并提交给商品查询模块。商品查询模块提示客户输入查询条件，客户输入适当的查询条件后，查询模块将显示商品列表。客户得到商品列表后，提交自己想要购买的商品ID，订购模块得到商品ID。生成订单并提交给数据库模块进行保存，保存成功后，提示用户订购商品成功。

图4 顾客订购时序图
客户删除订单的时序图如图5所示
客户在提交订单后可以对订单进行维护（添加，删除，修改）。客户首先输入自己的帐号和密码登陆系统，登陆模块会将客户的ID保存在系统缓存中，并提交给订单查询模块。订单查询模块会显示当前所有的订单，顾客得到该列表后，选择要删除商品的ID，订单处理模块把删除信息提交给数据模块，数据模块保存信息。订单处理提示用户删除成功。

图5客户删除订单的时序图
管理员处理订单的时序图如图6所示
管理员使用其帐号和密码登陆后，登陆模块会将管理员的ID保存在系统缓存中并提交给订单处理模块。订单处理模块提交给管理员未处理的列表，管理员提交某商品的ID得到该商品的库存情况，如果库存充足则接收订单，并把接收信息提交给数据模块，数据模块更新改客户的订单信息并返回成功信息给订单处理模块，订单处理模块提示改操作成功。

图6 管理员处理订单的时序图

3.5系统的协作图分析：
顾客订购协作图如图7所示

图7顾客订购协作图
顾客删除订单的协作图如图8所示

图8 顾客删除订单的协作图
管理员处理订单协作图如图9所示

图9 管理员处理订单协作图
3.6系统的活动图分析：
购买商品的活动图如图10所示

图10 购买商品的活动图
3.7系统的配置图分析：
配置图可以显示节点以及它们之间的必要连接，也可以显示这些连接的类型，还可以显示组件和组件之间的依赖关系，但是每个组件必须存在于某些节点上。配置图用于对系统的实现视图建模。绘制这些视图主要是为了描述系统中各个物理组成部分的分布、提交和安装过程。在实际应用中，并不是每一个软件开发项目都必须绘制配置图的。如果项目开发组所开发的软件系统只需要运行于一台计算机并且只需使用此计算机上已经由操作系统管理的标准设备，这种情况下就没有必要绘制配置图了。另一方面，如果项目开发组所开发的软件系统需要使用操作系统管理以外的设备（例如数码相机、路由器等）、或者系统中的设备分布在多个处理器上，这时就有必要绘制配置图，用其来帮助开发人员理解系统中软件和硬件的映射关系。下面的本系统的配置图，见图11。

图11 网络购物系统的配置图

4.系统采取的设计模式分析
4.1系统中的类，如下图12所示：

图12 系统的类图
关于图11有几点说明如下：
1.Person类是所有类的父类，它的属性包括用于标示不同身份人的ID，姓名和地址。它的方法包括根据ID搜索，根据姓名搜索，设置某人的姓名，地址等。
2.Customer继承了父类的方法和属性，并添加了自己的方法和属性。Reg_date表示改用户注册的日子，password表示登陆密码，Search_goods()用于搜索商品，maintain_order()用于维护客户订单。
3.employee继承了person，它的属性dateHired表示雇佣日期，right表示使用权限，salary表示该员工的薪水，password表示登陆密码。Handle_Order()用于搜处理订单，这是所有员工共有的操作。系统管理员中还增加了查询分析和报表打印的方法。
4.2系统中的其他类，如下图13所示：

图13系统中的其他类
4.3 模式的使用
1简单工厂模式：
简单工厂模式又称静态工厂方法模式，它就是由一个工厂对象决定创建出哪一产品类的实例。简单工厂模式的策略图如下14所示：

图14 简单工厂的策略模式图
简单工厂模式是由一个工厂类根据传入的参量决定创建哪一类产品的实例。由上图可以看出它有三个角色：
工厂类：担任这个角色的是工厂方法模式的核心，含有与应用紧密相关的商业逻辑。工厂类在客户端的直接调用下创建产品的对象，它往往由一个具体的java类实现。
抽象产品角色：担任这个角色的类是由工厂方法模式所创建的类的父类，或者他们有共同的接口。抽象产品可以是一个java接口或者抽象类的实现。
具体产品角色：工厂方法模式所创建的任何对象都是这个类的实例，由一个具体的java类来实现。
在系统中，我们抽象出一个员工的类，它有连个子类：一般员工和系统管理员。有个一个工厂类factory负责具体实例的创建。具体的类图如下图15所示：

图15系统中使用的简单工厂模式
2策略模式：
策略模式的用意：
策略模式的用意是针对一组算法，将每一个算法封装到具有共同接口的独立的类里面去，从而使得它们可以相互替换。它是对算法的包装，是把使用算法的责任和算法本身分割开，委派给不同的对象管理。
策略模式的结构：
策略模式的结构图如下图16所示：

图16 策略模式的结构图
在这个模式里面设计到三个角色：
环境角色：它持有一个抽象策略的引用
抽象策略角色：这是一个抽象角色，通常由一个接口或者抽象类实现。此角色给出所有的具体策略类所需要的接口。
具体策略角色：包装了相关的算法和行为
在系统中设计到多种查询，它们大都类似，我们可以采用策略模式提高程序的灵活性和适应性。具体的策略模式的使用见下图17所示：

图17 策略模式在系统中的使用
3享元模式：
由于只使用到单享元模式，故在这里只给单享元模式给与介绍。
在单纯享元模式中，所有的享元对象都是可以共享的，如下图17所示。它涉及到如下的四种角色：
客户端：它需要一个对所有享元对象的一个引用，同时它需要自行存储所有享元的外蕴状态
享元工厂：本角色负责创建和管理享元角色。它必须保证享元对象可以被系统适当的共享。当一个客户端对象调用一个享元对象的时候，享元工厂会检查系统中是否已近有一个已符合要求的享元对象，如果有的话，享元工厂就提供这个已有的享元对象；如果没有的话，享元工厂就创建一个合适的享元对象。
抽象享元角色：它是所有具体享元类的超类，为它们提供一个公共接口，当需要外蕴状态的操作，可以提供参数传入。
具体享元：它实现了抽象享元所规定的接口。如果有内蕴状态的话，它必须为内蕴状态提供空间，使得享元对象在系统内可以共享。

图18 单纯享元的模式结构图
在系统中所有的用户拥有同样的用户类型，因此对他们我们只需保存一个，这样可以很大程度上节省系统运行的开销以及提高运行的效率。享元模式在系统中的使用如下图19所示：

图19 享元模式在系统中的使用
5.结束语：UML在软件工程中的运用是与ＯＭＧ组织提出的ＭＤＡ是相一致的，随着它的不断发展和完善，并且随着OMG使UML实现的标准化﹑统一化，最终基于UML的MDA软件开发过程将变为一个更加重用，更加快速，更加有效的软件开发方法，使软件开发方法向更高抽象层，更加可重用发展。
6.参考文献：
[1] 面向对象程序设计高级教程，陈奇，高等教育出版社，2001
[2] 标准建模语言UML极其支持环境，周伯生，张莉等，北京：计算机世界，1998
[3] UML和模式应用——面向对象分析和设计导论，Craig Larman等，姚淑珍，李虎译，机械工业出版社，2002
[4] UML ASL Reference Guide ASL Language Level 2.5；Ian Wilkie, Adrian King, Mike Clarke, Chas Weaver and Chris Rastrick；
[5] Stephen J. Mellor, Marc J. Balcer,Executable UML :A Foundation for Model-Driven Architecture, ,2003,科学出版社
21