网上购物系统uml建模

第一篇：网上购物系统uml建模

UML(ATM系统)动态建模

实验3 动态建模

一、 实验目的与要求

1 掌握分析ATM系统用例中用例的流程，分析对象之间的交互关系

2 掌握用UML设计参与对象之间的交互，用状态图、时序图、协作图和活动图来描述系统的行为。

二、实验设备、环境

PC(一台)，Windows 2000或以上版本，安装Microsoft Visio 2003

三、实验内容及步骤

1 交互图：实现ATM系统的序列关系图和通信(协作)关系图; 2 分析设计软件系统的状态图。((1)和(2)选做一个状态图);

(1) ATM系统

(2) 具体题目如下：某销售POS机，它的工作流程是：当客户到收银台后，收银员逐一输入用户购买的商品，输入完之后，计算出总金额，然后等待用户付款，确定支付成功之后，完成收银，等待下一个客户。请为其绘制出相应的状态机图。

3分析设计ATM系统的活动图(选做1个活动图)。

建立动态模型：

建立序列关系图、状态图、活动图

步骤：



编写脚本



确定各个对象之间的事件



构造事件追踪图(交互图) 

构造状态图



添加活动和动作

一、 时序关系图

1)ATM系统的正常情况脚本

 ATM请储户插卡;储户插入一张现金兑换卡。  ATM接受该卡并读它上面的卡号。

 ATM要求储户输入密码;储户输入自己的密码“1234”等数字。

 ATM请求系统验证卡号和密码;核对储户密码，然后通知显示器显示说这张卡有效。

 ATM要求储户选择事务类型(取款、转账、查询等);储户选择“取款”。  ATM要求储户输入取款额;储户输入“880”。

 ATM确认取款额在预先规定的限额内，然后要求处理这个事务;成功处理完这项事务并返回该账户的新余额。

 ATM吐出现金并请储户拿走这些现金;储户拿走现金。  ATM问储户是否继续这项事务;储户回答“不”。

 ATM打印账单，退出现金兑换卡，请储户拿走它们;储户取走账单和卡。  ATM请储户插卡。

2)ATM系统的异常情况脚本

 ATM请储户插卡;储户插入一张现金兑换卡。  ATM接受该卡并顺序读它上面的数字。

 ATM要求密码;储户误输入“8888”等数字。

 ATM请求总行验证卡号和密码;经验证发现密码错误，拒绝这张卡。  ATM显示“密码错”，并请储户输入密码;储户输入“1234”等数字;ATM请求总行验证后知道输入密码正确。

 ATM要求储户选择事务类型;储户选择“取款”。

 ATM询问取款额;储户改变主意不想取款了，按“取消”。  ATM退出现金兑换卡，请储户拿走它们;储户取走卡。  ATM请储户插卡。

ATM 脚本的事件时序图如下图所示：(正常情况)

用户读卡器显示器ATM卡用户账户事务提款机插卡读卡初始化提示输入密码输入密码验证密码获取密码获取账户初始化提示选择业务选择业务执行事务初始化提示输入金额输入金额获取余额验证取款金额计算余额计算利息更新账户配给现金打印收据退卡

二、 状态图

主屏]do：显示主屏幕插卡[可读]Do：要求密码输入密码Do:验证账户继续密码错拿走卡退卡do：退卡请拿走卡插卡[不可读]不可读的卡do：显示信息取消取消do:显示取消信息无效账户账户有效Do:要求类型取消输入类型Do:要求金额取消结束do：打印账单Do:显示无效账户信息输入金额等待5秒Do:处理事务中止取消Do:请求继续拿走现金do：吐出现金请拿走现金事务成功取消事务失败Do:失败信息网络响应等待网络响应中断do：显示取消信息ATM类的状态图

处理事务验证账户请求处理事务请求验卡事务成功事务失败无效账户账户有效密码错

事务处理状态图

账户验证状态图

三、 活动图

插卡<没有接收动作>输入密码<没有接收动作>输入账户类型输入金额取卡取钱<没有发送动作>

四、 实验体会

顺序图的重点是完成某个行为的对象类之间所传递的消息的时间顺序。一个顺序图事务对象角色，生命线，激活期和消息构成。协作图用于描述系统的行为是如何有系统的成分合作实现的。协作时一种静态结构，是一个系统对实现某些服务所涉及的对象及其交互的投影。一个协同定义了一组对某些服务有意义的参加者和它们的联系，这些参加者定义了交互中的对象所扮演的角色。

第二篇：UML建模--银行管理系统（范文）

银行管理系统的UML

建模

课程设计报告

专业：

学号：

姓名：

任课教师：

一、系统概述

银行是与人们生活密切相关的一个机构，银行可以提供存款、取款、转账等业务。 在银行设立账户的人或机构被称为银行的客户(customer)。一个客户可以在银行开设多个账户(account)，客户可以存钱到账户中，也可以从自己的账户中取钱，还可以将存款从一个账户转到另一个账户。另外，客户可以随时查询自己的账户情况，以及查询以前所进行的存款、取款等交易记录。客户还有权利要求关闭自己的账户。

实际生活中的银行功能其实还要复杂得多，但为了简化系统，本次设计只考虑银行的基本功能。简化版的银行信息系统至少应具有如下功能：

1. 一个银行可以有多个账户; 2. 一个银行可以有多个客户; 3. 一个客户可以持有多个账户; 4. 一个账户可以有多个持有者; 5. 银行可以为客户开设账户; 6. 银行可以为客户注销账户; 7. 客户可以从自己账户中取钱; 8. 客户可以向自己账户中存钱;

9. 客户可以在同一银行的不同账户之间转账; 10. 客户可以在不同银行的不同账户之间转账; 请完成登录、存款、取款、转账和查询几个模块的设计。

二、需求分析

银行系统是与生活紧密相关的一个机构，银行提供了存款、取款、转账等业务。在银行设立账户的人或机构通常被称为银行的储户。一个储户可以在银行开多个账户，储户可以存钱到账户中，也可以从自己的账户中取现，还可以将存款从一个账户转到另一个账户。储户还可以随时查询自己账户的情况，并查询以前所进行的存款、取款等交易记录。后台管理员可以对客户的账户进行注销、删除、查询等管理，还有就是银行利息、汇率、手续费之类参数的设置，以及财务管理以及财务分析。

软件分别有开户，查询存取款，转账等功能。各个模块各有不同的功能，但都能完成查询和存取功能。各模块的数据都存放在数据库中。数据的调用和连接都有程序来完成。

此软件所要完成的主要功能有三方面：如果是存款，用户填写存款单，然后交给收银员键入系统，同时系统还要记录存款人姓名，住址，身份证号码，存款类型，存款日期，利率及密码(可选)等信息，完成后由系统反馈成功存款信息给用户。如果是取款，用户填写取款的相关信息(取款金额、取款币种)进行提交，系统要求用户输入密码以确认身份，核对密码正确无误后系统计算利息并印出利息单给用户。如果是转账，用户填写转账的相关信息进行提交，系统要求用户输入密码以确认身份，核对密码正确无误后系统计算利息并反馈信息给用户。系统及时更新数据库。

外部功能：实现化窗口，开户/销户、存款/取款、查询/转账。

内部功能：同步，过滤，定位，识别，更新，连接。

三、系统的UML基本模型

(1)、用例图

通过分析对银行管理系统的需求分析，确定参与者有银行客户、收银员。 收银员具有维护系统信息、维护客户信息、查询客户情况和处理处理客户需求的作用。 用例包括：

1)开户、 2)存款、 3)取款、 4)转账、 5)查询、

6)销户等

(2)、用例描述：

用例名称：银行信息系统

描述：银行客户对需要办理业务的需求以及收银员对事件的处理。

(3)、银行信息系统的事件流

1.用例存款的事件流

1.1 前置条件

在存款之前，客户已经办理银行账号并且带来现金若干，并到达银行网点。 1.2 后置条件

如果这个用例成功，这个存款事件是成功的，否则，系统没有变化。 1.3 扩充点

无 1.4 事件流

1.4.1 基流 (1)客户将银行卡交给收银员。

(2)收银员要求客户输入卡密码。

(3)客户输入卡密码，并确认密码。

(4)收银员提示，请客户选择服务类型。

(5)客户选择存款服务。

(6)收银员提示：存款数目。

(7)客户说出数目，并把钱交给收银员。

(8)收银员完成服务。

(9)收银员退还卡。 1.4.2 替代流

如果输入的密码无效，用户可以重新输入密码或者终止用例。

2. 用例转账的事件流

2.1 前置条件

在转账之前，客户已经办理银行账号，被转账人的账号已经存在并且已经知道了对方的账号。

2.2 后置条件

如果这个用例成功，这个转账事件是成功的，否则，系统没有变化。 2.3 扩充点

无 2.4 事件流

2.4.1 基流

(1)客户填写转账单。

(2)客户把转账单和银行卡交给收银员。

(3)收银员要求客户输入卡密码。

(4)客户输入卡密码，并确认密码。

(5)收银员转账成功。

(6)收银员退还卡。 2.4.2 替代流

如果输入的密码无效，用户可以重新输入密码或者终止用例。

3.用例查询的事件流

3.1 前置条件

在查询之前，客户已经办理银行账号并且携带银行卡，并到达银行网点。 3.2 后置条件

如果这个用例成功，这个查询事件是成功的，否则，系统没有变化。 3.3 扩充点

无 3.4 事件流

3.4.1 基流

(1)客户将银行卡交给收银员。

(2)收银员要求客户输入卡密码。

(3)客户输入卡密码，并确认密码。

(4)收银员提示，请客户选择服务类型。 (5)客户选择查询服务。

(6)客户说出查询内容，收银员将内容反馈给客户。

(7)收银员完成服务。

(8)收银员退还卡。 3.4.2 替代流

如果输入的密码无效，用户可以重新输入密码或者终止用例。

(4)、活动图

活动图是基于对象的状态变迁所绘制的视图。

收银员首先凭着自己的系统用户名和密码登录系统，收银员可以通过银行客户提供的有效证件号开户，提供客户账号开户、存款、取款、转账、查询、销户等功能，最后退出系统。

1.存款活动图

2.转账活动图

3.查询活动图

(5)、时序图

时序图(Sequence Diagram)主要用于按照交互发生的一系列顺序，显示对象之间的这些交互。收银员通过用户账号和密码登录系统，在系统的操作窗口对需要存款、取款、转账、查询、销户的用户进行操作，最后退出操作窗口。

我们所开发的银行管理系统时序图如图所示：

(6)、类图

类图是对象结构建模的一部分，类图描述系统中类的静态结构。类图是代码生成(将模型转化为代码)的来源，也是逆向工程(将代码转化为模型)的目标设生成物。

类图设计如下图：

系统中主要的类 (1)用户类： 它的属性有用户名(Name)、密码(Password)、银行卡号(Cardnumber)、用户身份证号码(ID)。

操作包括修改密码(Changpassword)、存款(deposit)、取款(cash)、转账(transfer)、 查询(Chaxun)、、用户开户(Registered)。

(2)系统类：

它的属性有电脑号(Computernumber)、机器地址(Mac)。 本身的操作没有，但有被管理员使用的操作。 (3)收银员类：

它的属性有用户名(name)、密码(password)。

操作包括用户开户(Registeredusers)、注销用户(Deleteusers)、查询用户信息(Chaxun)、系统维护(Weihu)。

(7)状态图

状态图用来表示建模对象是如何改变其状态的，状态定义为对象行为在某一时刻的快照或转折点。

四、结论

系统主要的实现目标是实现客户开户、存款、取款、转账、查询、销户和后台服务器端系统的设计，提供完善的功能设计。

五、总结及心得体会

UML工具很好的帮助我们实现了对银行信息系统的设计，通过UML建模，把事物从抽象到实例化的过程，对每个对象进行细化分析，从而得到简单而方便，容易理解的模型结构。通过此次试验收获很大，使我们认识到了通过UML模型可以高效完成软件设计，收获颇丰。

一、开发背景与目标

1.1开发背景

本系统选题为银行存储系统，是模拟银行存储开发的。随着计算机的飞速发展及应用领域的扩大，特别是计算机网络和电子商务的发展，极大的改变了商业银行传统的经营模式。能够为客户提供方便、快捷、安全的服务，也能够有效的降低银行的营运成本，这是银行存储系统追求的目标。目前，对于现代化银行运营的要求是客户可以实现方便安全的业务交易，银行职员可以进行高效合理的工作管理，实现银行业务电子化

在银行管理系统中，系统包括4个节点，分别是：银行管理员业务处理节点、

ATM自动取款机节点、系统维护节点、数据库节点。

银行管理员业务处理节点，银行管理员通过该节点办理相应业务; ATM自动取款节点，用户通过该节点进行自动取款服务;

系统维护节点，系统管理员通过该节点进行后台维护，执行银行管理员允许的所有操作;数据库节点，负责数据的存储与处理。

谁使用系统的主要功能?谁改变系统的数据? 谁从系统获取信息? 谁需要系统的支持才能完成日常的工作任务?谁负责维护,管理并保持系统的正常运行?系统需要应付,处理那些硬件设备?系统需要和那些外部系统交互?谁(或是什么)对系统运行产生的结果感兴趣?

用例图主要用来描述“用户、需求、系统功能单元”之间的关系。它展示了一个外部用户能够观察到的系统功能模型图。

【用途】：帮助开发团队以一种可视化的方式理解系统的功能需求

第三篇：uml建模报告ATM自动柜员机系统

UML建模报告

( 2010 / 2011 学年 第 2学期)

题 目：

基于UML的ATM自动

柜员机系统

专

业：

成

员：

指

导

教

师：

基于UML的ATM自动柜员机系统建模报告

一、需求分析

(1)功能需求：

1.登陆：客户通过输入正确的登陆密码即可登陆ATM。

2.取款：允许客户取出自己账户中的现金。 3.客户存款：允许客户把现金存入自己账户。 4客户查询余额：允许客户查询自己的账户余额。

5客户转账：允许客户将自己账户中的金额转移至另一账户。 6客户更改密码：允许客户修改自己的登录密码。

(2)系统操作要求：

1.要求用户每次取款数额为50的整数倍;

2.要求用户一次取款数额不得大于1000元; 3.要求用户一天取款数额不得超过5000元; 4.要求用户每次取款数额不得大于账户余额; 5.要求用户设置的登录密码为6位。

(3) 系统性能要求：

1.要求反应时间不得大于10秒钟; 2. 系统设计目标：

ATM自动取款机可以提供24小时不间断服务，操作简单，可以很方便为用户提供取款、转账/汇款、查询账户余额等服务。

(4)实现手段：

使用ASP.NET进行界面设计，建立一个数据库保存客户的账户信息，使用C#语言功能函数并对数据库中的账户信息进行操作。

二、总体设计

本系统总共分为登陆、查询、存款、取款、转账、修改密码等6个功能模块。

1. 登录模块：登陆模块使用字符匹配算法，要求用户在输入账号之后输入登陆密码，只有输入正确的密码才能登陆自己的账户。否则提示密码错误。

2. 查询模块：用户输入正确的密码后就可登陆自己的账户并接受服务。查询功能允许用户查得自己账户上的余额信息。

3. 存款模块：允许客户向自己的账户中存入现金。

4. 取款模块：允许客户从账户中取走现金，要求取出的金额不能大于所剩余款，否则提示余额不足。

5. 转账模块：允许客户将自己账户中的金额转移至另一账户。要求所转的金额不能多于所剩余款，否则提示余额不足。

6. 修改密码模块：允许用户修改自己的登陆密码，密码仍然是6位数的，修改之后，下次登陆就应该用新密码。

三、详细设计 用例图：

类图：

客户取钱的协作图：

其他功能的协作图与此类似。

账目类的状态图：

ATM系统的部署图：

四、测试报告 我们在客户数据库中建立四个账户，如下：

其中四个属性分别是客户名、账号、密码、账户余额。 打开网页，进入初始页面：

若选择取回磁卡，显示如下：

1.登录功能测试

我们选择继续以进行测试，单击测试进入如下页面：

若输入不存在的账号，则出现提示：

现在我们输入正确的账号，这里以08060112为例：

单击确认，系统将提示客户输入密码，正确的密码是“123456”，我们输入“333333”以进行测试，系统提示密码错误：

我们输入正确的密码“123456”，单击确认，则进入交易界面：

2.查询功能测试

单击查询，显示如下

与数据库表中的number值比较可得，结果正确。 3.取款功能测试

选择返回，回到主菜单，单击取款，系统提示客户输入取款金额：

我们输入300单击确认，显示如下

单击确定回到主菜单，单击查询，显示如下：

余额为700，说明取款成功，取款功能顺利实现。 4.转账功能测试

单击返回，回到主菜单，单击转账，系统提示用户输入转入账号，我们以转入08060119为例：

单击确认，系统提示转账金额，我们输入300：

单击确认，提示转账成功：

单击确定回到主菜单，这时我们单击查询08060112的余额：

结果正确，我们再通过数据库查询08060119的余额，打开表格，右击，执行，显示如下：

结果也正确，说明转账功能也已顺利实现。 5.存款功能测试

单击返回回到主菜单，单击“存款”，我们通过输入数值来模拟放入现金：

单击确认，系统提示操作成功：

单击“确定”回到主菜单，单击查询，显示如下：

结果正确。

6.修改密码功能测试

单击返回回到主菜单，单击“修改密码”，系统提示如下：

我们将密码修改为“555555”，输入“555555”后，提示操作成功：

单击确定就回到主菜单。这时我们取回磁卡重新登录以测试密码是否已经修改。依旧输入卡号08060112，

单击确认，输入旧密码“123456”，提示密码错误：

单击确定，重新输入新密码“555555”，单击确认，则可顺利登录到主菜单

可见，密码已经修改成功，另一方面，我们查看数据库中的数据，右击，执行，显示如下：

可以看到账户08060112的password属性已经变为“555555”，因此，修改密码功能也能顺利实现。至此，ATM系统的六大功能都已通过测试并正确无误。

五、总结

通过这次UML建模的学习，我们学会了很多知识。之前我对UML建模一无所知，但现在我已学会了一些UML建模的基本知识，并学会了建立一些简单的模型。

虽然只有短短的几个礼拜，但收获却是很大的。首先是分析问题的能力，刚拿到这个题，总觉得无从下手，不知道题目到底要我们做什么，心里只是干着急，不知道该干嘛。经过一周的迷茫，我们开始静下心来，分析题目，找参考书，尝试性地进行编程。到第三周，我们终于做出了一个成果并且编译没有错误。之后就是尝试运行，运行的过程中出现很多问题。比如转账，修改密码等，但经过我们细心的测试、排查，还是找到了错误的原因并进行了纠正。因此，我们的查错改错的能力也得到了提高。最重要的是，我们通过这次实习学会了互相合作，俗话说“三个臭皮匠顶个诸葛亮”，也许我们单独做很难完成这个程序。但是只要我们团结一致就没有克服不了的困难。这次实习在我们的大学生活乃至整个人生中都有着非常重要的意义，是一笔不小的财富，难忘的经历。我们会以此为基础走好人生的每一步。

以上是我们对UML建模的学习的一点总结，同时也是为自己的未来整理好思路，为以后的学习做好准备。UML建模，教会了我很多，而我要做的，就是在以后的学习与生活中更加努力的学习来迎接它带来的知识与挑战。

第四篇：UML网上售楼系统设计论文

[摘要] 本文设计和实现了一个B/S架构的网上售楼系统。本系统采用UML建模，Web服务器软件是IIS5.5，开发工具是ASp，后台数据库系统是SQL Server 2000，网页设计软件是Macromedia Dreamweaver。

[关键词] 网上售楼 UML ASp

网上售楼系统是一个B2C的电子商务流程，售楼本身业务繁多，涉及金额数量大，根据售楼的实际特点，网上售楼系统在售楼业务完成以后，可以为用户提供支付信息，将会员所要支付的款项收录在支付信息中，为后续服务提供依据。

一、系统分析与设计

1.系统用例分析与设计。用例是获取系统功能需求的一种技术，是从参与者的角度来描述系统行为。一个用例就是参与者与系统的一次交互，它表达了系统的功能和所提供的服务。因此，在识别出参与者的基础上，可确定在网上售楼系统中，有访客、会员、管理员三个参与者，访客可以浏览楼盘信息、注册成为会员。会员可以登录系统、管理个人信息、订购房屋、退订房屋、查询订单、查询退单、查询支付信息、在留言板上留言。管理员可以管理管理员专栏、管理楼盘房屋信息、管理公告信息、管理会员信息、处理订单、处理退单、管理支付信息、管理留言板。

在分析阶段我们分析了访客用例、会员用例和管理员用例，而在设计阶段，所描述的会员和管理员的用例图是编写程序代码、实现系统功能的依据。下面仅以角色权限最大的管理员为例说明(如图1)。

图1 管理员用例图

说明：管理员登录系统后台，主要实现几个大的功能模块，包括管理会员信息、管理管理员信息、管理留言板、管理公告、管理订、退、支付单等 。在每个大模块中，又包含具体的基本功能，主要是增、删、改、查的操作。

2.系统类图分析设计与数据库逻辑设计。类图描述系统所包含的类、类的内部结构及类之间的关系，表示的是系统中各个对象及其间各种静态关系。这种静态关系主要有两种：关联和子类型。

类图分为分析阶段的类图和设计阶段的类图，本系统需要九个类：“会员”、“管理员”、“订单”、“退单”、“留言”、“公告”、“支付清单”、“楼盘信息”、“房屋信息”(如图2)。

说明：在对象模型向关系模型的转化中需将业务逻辑类进行转化,即将每个业务逻辑类映射为一个数据实体,在数据库中用一个或多个数据表表示;类属性映射为数据表的字段。本系统涉及的数据库表有:“会员表”、“管理员表”、“订单表”、“退单表”、“留言表”、“公告表”、“支付清单表”、“楼盘信息表”、“房屋信息表”。　3.系统顺序图分析与设计。顺序图显示了对象之间的动态合作关系，强调对象之间消息发送的时间顺序，同时显示对象之间的交互，顺序图分为分析阶段的顺序图和设计阶段的顺序图。

设计阶段的顺序图是对分析阶段在内容上的补充和完善，在系统分析和设计中描述了管理员基本信息管理顺序图、留言顺序图、访客注册成为会员顺序图、管理员处理退单顺序图、会员提交订单顺序图。无法一一描述，仅以访客注册会员为例。访客注册会员顺序图描述为：两个参与者，即访客和管理员。访客进入售楼系统后可以注册成为会员。访客要先填写并提交注册信息，当还有必填内容没有填时，则会出现注册失败，系统会自动提示所要填的信息，此时，访客修改补充并提交，系统将显示注册成功。之后，管理员将审核会员信息，如果符合标准，则改变会员状态，由“未审核”转变为“已审核”，只有在已审核状态下的会员才能登录系统(如图3)。

二、系统实现

1.系统体系结构。本系统采用B/S架构，B /S模式把处理功能全部移植到了服务器端,用户的请求通过浏览器发出,无论是使用和数据库维护上都比传统模式更加经济方便. 而且使维护任务层次化:管理员负责服务器硬件日常管理和维护,系统维护人员负责后台数据库数据更新维护。

2.系统开发工具。本系统采用采用ASp开发WEB应用程序。ASp (Active server pages动态服务器主页的简称) 内含于Internet Information Server(IIS)中,是一套微软开发的服务器端脚本环境。通过ASp ,可以结合HTML网页、ASp 指令和ActiveX 元件,建立动态、交互且高效的WEB 服务器应用程序，所有的程序都将在服务器端执行，包括所有嵌在普通HTML中的脚本程序。当程序执行完毕后,服务器仅将执行的结果返回给客户浏览器,这样也就减轻了客户端浏览器的负担,大大提高了交互的速度。后台数据库系统是SQL Server 2000，网页设计软件是Macromedia Dreamweaver。

3.主要界面的实现。本系统分为前台和后台两个部分。前台主要的界面有：前台首页、楼盘信息页、房屋信息明细页、公告首页、公告内容页、注册页、留言页、会员修改个人信息页、提交订单页、查看订单页、提交退单页、查看退单页、支付信息明细页等;后台主要的界面有：审核会员页、发布公告页、公告保存页、管理留言板页、查看会员信息页、删除会员信息页、修改会员信息页、查看订单并受理页、订单生成支付信息页、订单生成支付信息明细页、管理员查看支付信息明细页等(如图4)。

三、总结

本文结合使用了UML 和ASp, 设计并实现了网上售楼系统。采用UML 建模语言进行分析,具有灵活、高效的特点,为进行可视化系统的开发提供了极大的方便。

参考文献:

[1]邝孔武王晓敏:信息系统分析与设计[M].清华大学出版社.2006

[2]陈刚李建义:数据库系统原理及应用[M].中国水利水电出版社. 2003

第五篇：基于UML的网络购物系统的分析

姓名：牛慧敏

学号;102055208 摘要：论文简单的描述了UML的基本概念和发展历史，并且分析了目前运用UML存在的一些问题，通过在实际的设计开发中运用UML对网络购物系统的开发例子来阐述UML的一些实现原理。

关键词：对象管理组织 统一建模语言 面向对象设计

[Abstract]:This paper describes the history and development of basic concepts and analysis of the current use of UML problems through the practical application of UML to the design and development of network shopping system development to achieve some examples to explain the principles of UML

[key words]：OMG, UML, OOA. 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是一个比较大的升级工作，其发布时间也一再的

1 推迟。经过对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还存在以下几个方面的不足: 第一，目前UML很多地方运用难以解释的字符来描述系统的功能、系统的行为和计算,不易于理解。并且没有对数据操作进行定义,很多对象之间的行为过程没有加以说明，如：对象之间关系的操作(relationship manipulation)，这些都迫切需要一个标准化的行为描述语言(Action Specification Language)来对系统的行为进行精确的描述。

第二，UML虽然是一种面向对象的软件系统设计的标准描述语言，但是在其状态图中用状态和迁移表示对象行为关联时用到了大量的

2 不易于理解的注释字符，因此，系统的UML模型既不是可以执行的也是不和用编程语言开发的可执行程序相协调。

第三，在不同的技术实现平台上(如：实现语言，软件环境)对同样需求的系统建模时细节差别很大，系统构建模型的重用性就很低。这样在计算机技术正在向各个方向快速发展的今天，老的遗留系统必须和新技术的实施平台，开发技术相协调，使得新旧系统之间的集成或系统的演化面临不同的实现技术，老的遗留系统在运用新技术进行重构时，必然要浪费很多财力，人力进行系统模型的更新甚至完全重建系统

3.网络购物系统的分析：

(1)用例图的分析：分析阶段的一个主要工作是对用户的需求进行分析，找出系统的用例，如下图是网络购物系统的用例图：当然这并不是唯一的用例图，每个设计者对用例的划分粒度，参与者的选择，用例优先级的分配等有不同的方案。在用例的分析中，对于用例还有一个很重要的工作就是要有用例的描述，这样会让用户能更加明白你的系统的用途。在网络购物系统中，购物者进入网站是浏览或购买自己喜爱的东西，对于用例的描述有不同的格式，但是基本的内容应该都是差不多的。都是能尽量的把系统的所有功能描述清楚，让用户最大化的理解和能使用系统的功能。

管理员登陆系统管理员管理信息会员信息处理定单people购物者登陆系统将定单发送给销售者查看顾客定单商品信息购物者浏览和查询商品决定购物销售者也有自己的登陆界面填写定单将定单发给管理员销售者销售者登陆系统定单信息查看信息货物信息发货

(2) 类图的分析：画类图和理解类图时都应采用三个层次的观点。这些观点也适用于其它模型。三个层次的观点不是UML的组成部分，但对建造模型或评价模型都非常有用，且都可应用于UML.(1)概念层描述应用域中的概念，是对现实世界的直接描述，与实现它们的类有关

4 但与实现方案和实现语言无关。(2)说明层描述软件的接口，而不是软件的实现。一个类型描述一个接口，但可能有多种实现。(3)实现层从实现的角度定义类及其实现，揭示了软件实现体的构成情况。下面是系统的类图

：

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

6 Desktop ...InternetDesktop ...RegistrationServer LANWebBrowserbuyingSystemsaleSystemMaintainSystemLANDesktop PC(saler)

4.结束语： UML在软件工程中的运用是与OMG组织提出的MDA是相一致的，随着它的不断发展和完善，并且随着OMG使UML实现的标准化﹑统一化，最终基于UML的MDA软件开发过程将变为一个更加重用，更加快速，更加有效的软件开发方法，使软件开发方法向更高抽象层，更加可重用发展

5.参考文献：

[1] Alan Zeichick , Modeling Usage Low; Developers Confused About UML 2.0, MDA,2004 [2] ITU Recommendation Z.100, Specification and Description Language(SDL);2003 [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,科学出版社