uml管理系统课程设计

第一篇：uml管理系统课程设计

仓库管理系统课程设计 UML

无锡职业技术学院实践环节材料撰写用纸

二、仓库信息管理系统分析与设计

(一)《仓库信息管理系统》的需求建模

1、需求分析

仓库信息管理系统要能完成以下功能：

仓库存放的货物品种繁多，堆存方式以及处理方式也非常复杂，随着业务量的增加，仓库管理者需要处理的信息量会大幅上升，因此往往很难及时准确的掌握整个仓库的运作状态。针对这一情况，为了减轻仓库管理员和操作员的工作负担，此系统在满足仓库的基本管理功能基础上发挥信息系统的智能化。

根据要求可将系统分为四个模块 (1)用户登录模块

普通操作员和管理人员登录此系统，执行仓库管理的一些操作，但是普通操作员和管理人员所能执行的功能不一样。 (2)仓库管理模块

管理员工作需要登陆系统，才能够进行操作，系统中的各项数据都不允许外人随便查看和更改，所以设置登陆模块是必须的。可以执行仓库进货，退货，领料，退料;商品调拨，仓库盘点等功能。 (3)业务查询模块

在用户登录系统后，可以执行库存查询，销售查询，仓库历史记录查询。

(4)系统设置模块

显示当前仓库系统中的信息,在系统中可以执行供应商设置，仓库设置。

2、功能模块分析 (1)登录模块

普通操作员：显示当天仓库中的所有库存的信息。 管理员：修改仓库中的库存信息。

用户注销：在用户执行完仓库功能时，注销。 用户退出。 (2)管理模块

仓库库存的进货与退货;

仓库中的库存需要领料和退料功能;

仓库也可以完成不同地区的商品在此仓库的商品调拨任务; 用户人员也可以在当天之后对仓库中的库存进行盘点。 (3)查询模块

显示当前仓库商品信息，并执行库存查询; 显示仓库信息，对商品的销售量进行查询; 此系统还可以对仓库历史记录进行查询。 (4)设置模块

供应商设置 仓库设置

3、工作内容及要求

进一步细化需求分析的内容，识别出系统的参与者，并完成用例图;

3 无锡职业技术学院实践环节材料撰写用纸

将用例图中的每个用例都写成相应的事件流文档;

进一步使用活动图来描述每个用例，为后续的系统设计做好准备;

按照系统的功能分析，从用例的描述中提取出系统的对象类和界面类，建立类图;

分析类图中的实体类和实体类之间的关系，画出数据库的逻辑模型图(只包含实体类，且注明角色和阶元)。

对数据库的逻辑模型进行优化，取消多对多的联系，完成最终的逻辑模型设计; 使用交互作用图或状态机图完成系统动态行为的建模。(建议使用顺序图按功能分别描述)

4、创建SRS文档：

 引言

仓库管理系统将24小时为用户服务。  用途

SRS文档将作为SDLC设计和编码阶段的输入。  作用域

管理员直接对系统进行管理。  功能性需求

操作员需要取得管理员的认可才可以登录此系统。 操作员可以查询库存的信息。

系统管理员可以管理登录系统以后对仓库进行管理

因为不是每个人都可以随便修改系统的，所以系统管理员可以登录进系统以后对用户的权限信息进行管理。

 界面需求

界面应该清晰易懂。  运行环境

此系统可以在网络上进行运行。

4 无锡职业技术学院实践环节材料撰写用纸

用例图如下：

分析：操作员在进行验证后登陆系统，可以执行商品的进退货的记录信息的查询与管理等操作。

用户登录**仓库领料仓库进货**退出系统****商品调拨**操作员****用户注销*仓库退料*仓库退货c

图1 操作员用例图

分析：此用户是管理员，可以对仓库信息进行维护，仓库商品进行盘点，业务分析，历史记录查询，供应商信息维护和仓库查询操作。

5 无锡职业技术学院实践环节材料撰写用纸

仓库信息维护用户登录****用户注销******管理员***退出系统仓库盘点*仓库查询**供应商信息维护*业务分析历史记录查询*

图2 管理员用例图

分析：该用户为供应商，可以对执行仓库进货和退货的查询与管理操作。

仓库进货***商品供应商*仓库退货

图3 供应商用例图

(二)《仓库管理系统》的静态建模

静态建模用于描述软件的静态成分，又叫结构建模。它包含类关系图和对象关系图。用于描述软件系统的成分之间的关系和依赖性。 1)类的分析与设计

 确定初始类图  提取类的属性  提取类的操作

6 无锡职业技术学院实践环节材料撰写用纸

 类之间的关系

去除不必要的类和不正确的类：

1. 冗余类：若两个类表述同一信息，保留最具有描述能力的类; 2. 不相干的类：去掉与问题没有多少关系和根本不相关的类;

3. 模糊类：类必须是确定的，有些临时类边界定义不对，或范围太广，应排除; 4. 属性：如果有些名词是用来描述某个类的，那么它一定是这个类的属性。 5. 操作：如果所描述的操作并不适用于对象并且被自身所操作，那么这一定不是类。 这样可以得到相关的三种类关系：  人员信息包类图  接口信息包类图  系统事务信息包类图 2)确定类之间的关系

两个类之间的相互依赖就是关联，关联常用描述性动词或动词组来表示，其中有物理位置的表示、传导的动作、通信、所有者关系及条件的满足等等。 通过以上方法可以确定类图：

① 人员信息包类图里包含：操作员类、管理员类、供应商类、商品进货模块类、商品退换模块类、商品打印模块类、库存查询模块类、商品盘点模块类、历史信息查询模块类和商品调拨模块类。

7 无锡职业技术学院实践环节材料撰写用纸

**操作员-姓名-id号-权限+仓库进货()*+仓库退货()+仓库领料()+仓库退料()+商品调拨()*+用户登录()+用户注销()+退出系统()+盘点信息打印报表()+进货商品打印报表()*+退换商品打印报表()+商品库存信息()**商品进货模块+商品清单()+退货清单()+查询信息()库存查询模块**商品打印模块*

图4 人员信息包类图

供应商-供应商姓名-供应商id号-联系方法+进货()+退货()*1管理员-姓名-id号-权限+供应商信息维护()+仓库信息维护()+盘点信息()+仓库查询()+业务分析()+用户注销()+退出系统()+历史记录查询()+用户登录()+查询结果()*历史信息查询模块*+查询条件()+进货记录()+商品调拨记录()+商品盘点信息()*********商品退换模块*商品盘点模块*+审核后盘点信息()+查询信息()**商品调拨模块+查询信息()+查询条件()*+盘点信息列表() 8 无锡职业技术学院实践环节材料撰写用纸

② 接口信息包类图里包含：用户登录类、仓库管理类、系统管理类和业务查询类。

仓库管理+仓库进货()+仓库退货()+仓库领料()+仓库退料()+仓库调拨()+仓库盘点()用户登录+用户登录()+用户注销()+退出系统()系统设置-供应商设置-仓库信息维护业务查询+库存查询()+业务分析()+历史记录查询()

图5 接口信息包类图

③系统事务信息包类图包含：用户登录类、供应商管理类、业务分析类、查询历史信息类、仓库信息维护类、领料类、退料类、退换类、盘点类、调拨类和仓库查询类。

9 无锡职业技术学院实践环节材料撰写用纸

调拨供应商管理-该操作id号-日期-管理员id号+增加供应商()仓库信息维护-该操作id号-日期退料用户登录-该操作id号-登录日期-登录人id-name+用户登录()+用户注销()+退出系统()退货-交易id-日期-操作员-交易id-日期-退料人-操作员仓库查询-该操作id-日期领料-交易id-日期-领料员-操作员查询历史信息-该操作id-日期业务分析-操作id号-日期-管理员id+opname()盘点-交易id-日期-管理员id-仓库id

图6 系统事务信息包类图

(三)《仓库管理系统》的动态建模

在完成静态建模后，需要对系统实现动态建模。需要创建

 活动关系图：表示系统的静态成分为了完成过程需要执行的活动的顺序;

 交互关系图：表示软件系统静态成分之间的交互，常用序列关系图和通信关系图。 (1)活动关系图

活动关系图是用来对特定过程的控制流进行建模。

分析：管理员在登录系统后，查看销售记录和查看商品库存情况，如果缺货就通知操作员缺货商品清单，操作员即可联系供应商按缺货清单提供货物，然后管理员更新数据库结束，如果不缺货直接结束。

10 无锡职业技术学院实践环节材料撰写用纸

通知操作员缺货商品清单查看销售记录联系供应商按缺货清单提供货物查看商品库存情况[ 缺货] 接受货物更新库存数据库[ 不缺货 ]

图7 仓库系统的活动图

(2)交互关系图：通信关系图、序列关系图

①通信关系图以消息的形式表示对象之间的交互。通信图集中在活动着的对象上，表现的是相互通信的对象之间的消息传递，不参照时间。通信图通过在消息上加序号表示消息传递的次序。序列号放在消息之前作为消息的前缀。

注：通信关系图不描绘对象的生命线。 A.管理员盘点过程协助图

分析：操作员把盘点信息发送给管理员，管理员审查后盘点信息，在仓库商品盘点模块中盘点信息列表，然后交由信息打印模块打印盘点信息列表，给操作员。

11 无锡职业技术学院实践环节材料撰写用纸

操作员盘点信息管理员盘点信息打印列表审查后盘点信息商品信息打印模块盘点信息列表商品盘点模块

图8 管理员盘点过程协作图

B.商品管理协作图

分析：操作员通知供应商进货，供应商打印出进货清单，操作员也可以对进货退货进行管理，供应商打印出退货清单。

商品进货进货商印品打报表进货清单操作员退货商品供应商表库存查询商品退换退货清单库存信息进货商品打印报

图9 商品管理协作图

12 无锡职业技术学院实践环节材料撰写用纸

C.仓库历史记录查询协作图

分析：管理员应该先登录系统。当管理员登录系统以后，可以查询历史信息，看到商品进货、商品盘点、商品调拨的历史记录。

商品进货管理员查询条件历史信息查询进货、退货记录查询条件商品调拨商品盘点图10 仓库历史记录查询协作图

②序列关系图

序列关系图以按时间排序的消息形式来表示对象之间的交互。序列关系图和通信关系图的区别在于通信关系图情调对象的组织结构，而序列关系图则按时间顺序显示对象之间交互的消息。在序列关系图中，可以沿x轴方向排列对象。将启动交互的对象放在最左边。消息序列中后来的对象则放在交互启动对象的右边。在交互中，对象发送和接收的消息按时间升序沿y轴防止。

注：和通信关系图不同，序列关系图描述对象生命线。

A.仓库盘点过程序列图 分析：操作员将盘点信息发送给管理员，管理员审查盘点信息，然后盘点信息列表交给商品打印模块打印后发给操作员执行相关商品操作。

商品盘点信息

13 无锡职业技术学院实践环节材料撰写用纸

操作员管理员商品盘点模块商品打印模块盘点信息盘点信息列表()审核后盘点信息盘点信息打印报表()

图11 仓库盘点过程序列图

B.商品管理序列图

分析：操作通知商品供应商进货、退货，商品供应商将商品清单和退货商品清单发送给商品进货模块，商品进货模块将进货商品打印报表给操作员，商品退货模块将商品退换报表打印发给操作员，操作员也可以查询库存，库存库存模块将库存查询信息发送给操作员。

14 无锡职业技术学院实践环节材料撰写用纸

操作员商品供应商商品进货模块商品退换模块进货()商品清单()进货商品打印报表()退货清单()退货()退换商品打印报表()查询条件()商品库存信息

图12 商品管理序列图

C.仓库历史记录序列图

分析：管理员登录系统查询历史信息模块，历史信息则查询商品进货退货模块、商品调拨模块、商品盘点模块，之后各模块将查询得到的信息发送给历史信息模块，最后由历史信息模块统一将信息发给管理员。

15 无锡职业技术学院实践环节材料撰写用纸

管理员历史信息查询模块商品进货退货模块商品调拨模块商品盘点模块查询信息()查询条件()进货记录()查询信息()商品调拨记录()查询信息()商品盘点信息()查询结果()

图13 仓库历史记录序列图

16 无锡职业技术学院实践环节材料撰写用纸

(四)《仓库管理系统》的架构建模

架构建模使您能够了解组件在组织网络中的物理分布。您需要对软件系统的架构进行建模以确定组件的设计是否符合软件系统的需要。软件架构描述软件按系统的所有组件以及这些组件之间的关系。要对系统软件的架构进行建模，您需要创建以下关系图：

 包关系图：描述根据特定条件分组在一起的软件系统构成。  组件关系图：描述软件系统的可执行构成。

 部署关系图：描述软件系统组件的各种处理设备。

a)组件关系图：组件可实现一组接口并构成软件系统的可执行部分。

分析：该图是系统的各个组件图，由系统登录、仓库管理管理、信息查询、系统设置。

仓库管理信息查询系统登录系统设置

图14 组件关系图

b)部署关系图：显示需要在其中部署软件组件的硬件。

分析：下图表明系统采用数据库系统作为后台数据提供者，然后客户登录使用系统，也可以对系统中的信息进行打印操作。

17 无锡职业技术学院实践环节材料撰写用纸

数据服务器客户机1客户机n打印机

图15 部署关系图

第二篇：UML课程设计报告+网络教学系统的分析和设

统一建模语言UML 课程设计报告

指导老师: 姓名: 学号: 班级:

【设计名称】 网络教学系统-使用UML进行系统的分析和设计 【设计目的】1.掌握UML建模的基础知识和其应用;

2.熟悉Rational Rose环境及功能,能够设计出完整系统。

【设计要求】1.对系统功能进行必要的描述;

2.绘制系统的主要模型图;

3.模型图要有说明性文字解释。 【设计内容】1.网络教学系统的需求分析;

2.网络教学系统UML建模。

【设计步骤】

一: 网络教学系统的需求分析

1、系统功能需求

(1)学生可以登陆网站浏览和查找各种信息以及下载文件。

(2)教师可以登陆网站给出课程见解、发布、修改和更新消息以及上传课件。 (3)系统管理员可以对页面进行维护和批准用户的注册申请。 满足上述需求的系统主要包括下面几个模块

(1)数据库管理模块：提供使用者录入、修改并维护数据的途径。

(2)基本业务模块：教师可以上传文件、发布消息、修改和更新消息;学生可以下载文件;管理员可以维护页面，批准注册等。

(3)信息浏览、查询模块：主要用于对网站的信息进行浏览、搜索查询。

图 1.1系统功能需求

2、数据库管理模块

图 1.2数据库管理模块

(1)教师信息管理：负责教师信息的管理。

(2)课程简介信息管理：负责课程简介信息的管理。 (3)文件上传信息管理：负责文件上传信息的管理。

3、基本业务模块

图 1.3基本业务模块

(1)文件上传：教师可以使用此模块将课程的数据上传到网站服务器。 (2)文件下载：学生可以使用此模块从网站上下载课件及其他资料。

(3)消息发布：教师可以通过此模块发布学习方法、课程重点等和教学相关的文章，以及和课程相关的通知等。

(4)消息修改和更新：教师可以通过此模块对自己发布的信息进行修改和更新。 (5)页面维护：网站管理员可以使用此模块对网站的页面进行维护。 (6)用户注册批准：网站管理员可以使用此模块批准用户注册。

4、信息浏览、查询模块

图 1.4信息查询模块功能

(1)网页信息浏览：用户浏览网站信息。

(2)文章信息搜索：用户根据关键字搜索文章。

二: 系统的UML建模

1、系统的用例图

创建用例图之前首先需要确定参与者。 ① 在网络教学系统中，需要学生和教师的参与。学生可以浏览课程简介，教学计划，学习方法等教师发布的文章，并可以根据关键字查询文章。此外，学生可以从网站上下载课件。教师作为教学的主导者，使用此网站可以发布学习方法，课程重点等和教学相关的文章，以及和课程相关的通知等，还可以将某一门课程的课件上传。 ② 网站需要一个专门的管理者进行日常维护与管理，所以需要有系统管理员的参与。 (1)系统用户参与的总的用例图

教师和学生都可以从“网站用户”这个参与者泛化而来，网站用户是指网站的注册用户，注册用户可以登录系统完成相应的操作。

系统用户参与的总的用例图如图所示。从图中可以清楚地看到泛化关系与各个参与者所参与的用例。

图 2.1系统用户参与的总的用例图

抽象参与者注册用户的用例只有登录系统(System Login)一个，学生和老师用户除了包含这个用例以外，还各自有相对应的用例。 (2)学生参与者的用例图

学生参与者的用例图如下图所示。

图 2.2学生参与的用例图

① 文章浏览用例:学生可以浏览诸如课程简介，教学计划，学习方法等教师发布的文章。 ② 文章搜索用例:学生可以使用搜索功能根据关键字查询相应的文章。

③ 文章下载用例:学生可以使用下载功能将网站上的课件以及资料信息下载到本地机器上。〖用例图说明〗

① Download:文件下载用例。 ② Look through info:文章浏览用例。 ③ Article search:文章搜索用例。

④ Identify:权限认证用例。此用例用来认证文件下载是否具有下载文件的权限。

(3)教师参与者的用例图

教师参与者的用例图如下所示。

图 2.3教师参与的用例图

3 ① 添加课程简介用例：教师可以为自己所教授的课程添加课程简介。 ② 上传课件用例：教师可以将课程的课件上传到网站上供学生下载。 ③ 文章或消息发布用例：教师可以发布介绍学习方法，课程重点等和教学相关的文章，以及和课程相关的通知等。 ④ 文章或消息修改用例：教师可以修改自己发布的文章和通知。 〖用例图说明〗

① Course Intro:添加课程简介用例。 ② Upload CAI:上传课件用例。 ③ Message Issue:文章或消息发布用例。 ④ Message Update:文章或消息修改用例。

(4)系统管理员参与者的用例图

系统管理员的用例图如下所示。

图 2.4系统管理员参与的用例图

① 页面维护。系统管理员可以对网站进行日常维护与管理。 ② 处理注册申请。系统管理员可以处理学生或教师用户的注册申请。 〖用例图说明〗

① Page Maintenance:页面维护。

② CAI Process:教师上传的课件经过系统管理员的审批和处理。

③ Information Update:页面更新。系统管理员负责网站的页面更新，除了文章，消息，图片等的更新，还包括页面的美化和板块的调整。

④ Process Registration:处理注册申请。

2、系统的时序图

网络教学系统中的用例很多，所能画出的时序图也很多，在此不一一介绍。 (1)系统管理人员管理网站的时序图

图 3.1 系统管理人员管理网站的时序图

4 〖时序图说明〗

① Login:登录系统的函数。

② Add_or_delete_Article:添加或删除的文章。 ③ UpdateCAI():更新CAI课件的函数。 ④ Add_or_delete_User:添加或删除用户。 ⑤ Show():刷新页面的函数。 ⑥ Notify():通知用户的函数。

系统管理人员通过与管理窗口的交互可以添加或删除文章，更新CAI课件，添加或删除用户。具体的操作由管理窗口与数据库交互完成，管理员操作后的结果会在页面上显示。 (2)用户登录系统的时序图

图 3.2 用户登录系统的时序图

〖时序图说明〗

① Input(String,String):输入用户名和密码的函数。

② Send(String,String):将用户名和密码发送给服务器的函数。

③ Query_and_Validate():查询数据库并验证用户名和密码正确性的函数。

④ feedBack():发送反馈消息的函数，如果验证通过，发送OK;如果验证出错，发送Error. ⑤ ShowInformation():将反馈信息显示给用户的函数。

用户要登录系统，首先要和登录窗口交互，输入用户名和密码。登录窗口负责和服务器交互，将用户输入的用户名和密码发送到服务器，服务器再与数据库交互，以验证用户名和密码的有效性，如果验证成功，则返回OK，验证失败返回Error。服务器将通过登录窗口将信息显示给用户。

(3)学生下载文件时序图

图 3.3 学生下载文件的时序图

〖时序图说明〗

5 ①Request:学生发送下载请求。

②Send(String,String):传递下载参数的函数。 ③Identity():验证用户权限的函。 ④authorize:返回认证信息的函数。

学生要下载文件，首先要向下载窗口发送请求，然后下载窗口的参数传递个服务器，服务器与数据库交互以获得用户的权限认证，认证信息再通过服务器及下载窗口传递给学生。

3、系统的协作图：

1 、用户登录系统的协作图

图 4.1 用户登录系统的协作图

〖协作图说明〗

①Input(String,String):输入用户名和密码的函数。

②Send(String,String):将用户名和密码发送给服务器的函数。

③Query_and_Validate():查询数据库并验证用户名和密码正确性的函数。

④feedback():发送反馈消息的函数，如果验证通过，发送OK，否则，发送Error。 ⑤ShowInformation():将反馈信息显示给用户的函数。

2、学生下载文件的协作图

图 4.2 学生下载文件的协作图

〖协作图说明〗

①Request:学生发送下载请求。

②Request(String,String):传递下载参数的函数。 ③Identity():验证用户权限的函数。

④showStatus():返回下载状态的函数。如果认证成功，开始下载，不成功则报错。

4、系统的状态图：

图 5.1 系统的状态图

〖状态图说明〗

① HomePage:处于网站主页。 ② Certify:登录验证状态。 ③ SuccessPage:登录成功页面。 ④ UploadApplyPage:文件上传页面。 ⑤ Storing File:文件存储状态。 ⑥ OldPage: 页面未更新状态。 ⑦ NewPage:页面更新状态。

教师要上传文件，首先要登录网站，通过网站认证后转入文件上传页面，上传文件后处于文件存储状态。文件存储后，要经过管理员的认证才可以在页面上显示，如果通过认证，则刷新页面，如果未通过，页面维持不变。

5、系统的活动图：

(1)用户登录系统的活动图

图 6.1 用户登录系统的活动图

〖活动图说明〗

7 ①InputURL:输入网站的URL。 ②Show HomePage:显示网站主页。 ③Input Login Information:输入登录信息。 ④Press ”OK” Button:单击 “OK”按钮。

⑤Certify UserInfo:用户信息认证。 ⑥Show Success Page:显示登录成功界面。

用户登录系统时，首先要输入登录网站的URL，然后从首页的登录窗口中输入信息登录信息，如用户名和密码，点击页面上的登录按钮。用户输入的信息会与数据库中的信息对比验证，如果验证成功返回登录成功页面，如果失败，返回登录失败页面。 (2)教师上传课件的活动图

图 6.2 教师上传课件的活动图

〖活动图说明〗

①Apply File Upload:申请文件上传。

②Certify Size And Other Aspact:验证文件的大小和其他信息。 ③Store:文件存储。

④Administrator Authorize:系统管理员认证。 ⑤Update Page:更新页面。 ⑥Delete File:删除文件。

教师要上传文件，先要进入文件上传页面，然后验证上传文件的大小和其他信息是否符合要求。验证成功后将文件存储，当系统管理员认证通过，更新页面;认证不通过删除文件。 (3)系统管理员维护网站的活动图

图 6.3 系统管理员维护网站的活动图

〖活动图说明〗

①Login:登录系统。

②Process CAI:处理上传的课件。 ③Update Information:更新页面信息。 ④Modify Page:修改页面。

6、系统中的类

(1)参与者相关的类

系统中和参与者相关的类的类图如下：

图 7.1 参与者相关的类

〖类图说明〗

9 ①User类是所有类的父类，包括属性有Account(登录名)、Password(密码)、email(用户邮箱)等。方法有getEmail(获取邮箱)、getAccount(获取登录账户名)以及changePass(修改密码)。

②Student类是学生类， 除了继承父类的属性和方法，还包括number(学号)、name(姓名)、sex(性别)、age(年龄)、class(班级)、和grade(年级)等属性。

③Teacher类是教师类，除了继承父类的属性和方法，还包括name(姓名)、sex(性别)、Identity Card(身份证号)、course(教授的课程)、以及TelephoneNum(电话号码)。

④Adminstrator是管理类，管理员有自己的属性，TelephoneNum(电话号码)。还有自己的方法：CertifyUpload(文件的上传认证)、UpdatePageInformation(更新页面信息)、AddUser(添加用户)和DeleteUser(删除用户)等。

(2)各类之间的关系

类不是单独一个模块，各个类之间是存在联系。网络教学系统各个类之间的联系如下图：

图 7.2 各类之间的关系

〖类图说明〗

①CourseIntro类表示课程介绍类。此类的属性有：courseName(课程名)、college(开课院校)、teacher(授课教师)、scorePoint(课程学分)、time(开课时间)、Place(上课地点)和teachingPlan(教学计划)等，它有一个修改课程信息的方法Modify()。

②Article类表示发表的文章类，包括articleNum(文章序号)、articleTitle(文章标题)、teacherToIssue(发布教师)、create Time(创建时间)以及文章内容。方法有Issue(文章发布)、Delete(文章删除)和Modify(修改)。 ③FileUploadOrDownload类表示上传的文件信息类，属性包括fileName(文件名)、fileType(文件类型)、fileSize(文件大小)、shortIntro(文件的简短介绍)、fileURL(文件地址)、create(文件的创建者)以及createTime(文件的创建时间)等。操作包括checkSize(检查文件大小)、Modify(修改文件信息)、Store(文件存储)以及Cancle(取消上传)等。

教师可以教授几门课程，所以有几门课程的课程简介;教师可以发布多条信息，也可以不发布;教师可以不上传文件，也可以上传多个文件。一个学生可以下载一个文件，也可以不下载文件。

7、系统的组件图

网络教学系统的组件图如下图，组成Web应用程序的页面包括：维护页面(Maintenance Page)、文件下载页面(File Download Page)、文件上传页面(FileUpload Page)、信息发布页面(Message Issue

10 Page)和登录页面(Login Page)。

图 8.1 系统的组件图

8、系统的配置图

配置图主要是用来说明如何配置系统的软件和硬件。网络教学系统的应用服务器负责保存整个Web应用程序，数据库是负责数据库管理。此外还有很多终端可以作为系统的客户端。由于客户端很多，在此只画出3个客户端，系统配置图如下图：

图 9.1 系统的配置图

【小结】

在建模过程中，遇到一些问题，诸如某些操作界面无法看到，一些修改影响了其他模图的建立，通过询问辅导老师和上网查找资料，得到了比较满意的解决;在这次实验中，关于UML的概念以前比较模糊的地方，我在实际操作中，变得更加清楚了，对Rational Rose的UML功能运用的更加系统，更加熟练;但是更让我明白，UML的知识是十分丰富的，我现在的认识还不够，我将会在以后的学习中，不断提高自己的UML知识。

第三篇：软件工程课程设计——基于UML医院患者监护系统的分析与设计

软件工程

课程设计报告

基于UML医院患者监护系统的分析与设计

姓名： 班级： 学号： 指导教师：

实验题目

基于UML医院患者监护系统的分析与设计

实验目的

软件工程课程设计是软件工程专业一个综合性的实践教学环节，其目的在于促进学生复习和巩固计算机软件设计知识，加深对软件设计方法、软件设计技术和设计思想的理解，并能运用所学软件设计知识和面向对象技术进行综合软件设计，提高学生的综合应用能力。通过这次课程设计，要掌握UML(统一建模语言)，并能运用UML在Rational Rose中建模。

实验要求

1. 一人一组。

2. 熟悉Rose开发环境。

3. 掌握UML的基本模型元素(如角色、用例、类等)。 4. 熟悉UML，主要了解UML中的9大图：Use case diagram(用例图)、Class diagram(类图)、Sequence diagram(序列图)、Collaboration diagram(协作图)、Statechart diagram(状态图)、Activity diagram(活动图)、Component diagram(组件图)、Deployment diagram(配置图)、datamodel diagram(数据模型图)。

5. 进行系统需求分析与系统功能模块设计，绘出系统详细的业务流程图和数据流程图，建立完整的系统数据库的逻辑模型。 6. 完成对系统的建模实现。 7. 进行检查，并提交设计报告。

实验内容

一、 问题描述

在医院的病房里，将病症监视器安置在每个病床，对病人进行监护。监视器将病人的病症信号(组合)实时地传送到中央监护系统进行分析处理。在中心值班室里，值班护士使用中央监护系统对病员的情况进行监控，监护系统实时地将病人的病症信号与标准的病诊信号进行比较分析，当病症出现异常时，系统会立即自动报警，并打印病情报告和更新病历。系统根据医生的要求随时打印病人的病情报告，系统还定期自动更新病历。

二、 需求分析

根据分析系统主要实现以下功能：

1、要求病症监视器随时接收每个病人的生理信号(脉搏、体温、血压、心电图等)，定时记录病人情况以形成病情报告。

2、病症监视器可以将采集到的病症信号(组合)，格式化后实时的传送到中央监护系统。

3、中央监护系统将病人的病症信号与标准的病症信号库里的病症信号的正常值进行比较，当病症出现异常时系统自动报警。

4、当病症信号异常时，系统自动更新病历并打印病情报告。

5、值班护士可以查看病情报告并进行打印。

6、医生可以查看病情报告，要求打印病情报告，也可以查看或要求打印病历。

7、系统定期自动更新病历。

三、 用UML的静态建模机制定义描述系统的静态结构

(一) 建立系统的用例图

通过分析可以识别出本系统的四个角色：值班护士，医生，病人，标准病症信号库。其描述面板如下：

角色：病人 角色职责： 提供病症信号

角色职责识别：

负责生成、实时提供 各种病症信号。

角色：医生 角色职责：

对病人负责，负责处理病情的变化

角色职责识别：

(1)需要系统支持以完成其日常工作

(2)对系统运行结果感兴趣

角色：值班护士 角色职责：

负责监视病人的病情变化

角色职责识别：

(1)使用系统主要功能 (2)对系统运行结果感兴趣 角色：标准病症信号库 角色职责：

负责向系统提供病症信号的正常值

角色职责识别：

(1) 负责保持系统正常运行 (2) 与系统交互

通过分析可以初步识别出系统的用例为：中央监护，病症监护，提供标准病症信号，病历管理，病情报告管理。顶层用例图如下：

(二)识别系统的类

通过名词识别法和系统实体识别法等方法可以识别出系统的十二个类。类图(含数据模型)如下：

(三)用配置图描述系统的体系结构

用配置图可以进一步描述系统的网络结构。配置图如下：

四、 用UML的动态建模机制定义描述系统结构元素的动态特性及行为

(一)用状态图描述系统结构元素的动态特性及行为 状态图如下：

(二)用序列图和协作图描述病人病情异常时系统的情况 序列图如下：

生成协作图如下：

(三)用活动图描述系统在监护病人时的状态变化 活动图如下：

五、 作出系统的详细业务流图及数据流图 业务流图如下：

数据流图如下：

源程序和文档

见附件。

心得体会

通过本次课程设计，我对于UML有了更深刻的了解，能更熟练的使用UML在Rational Rose中进行建模，同时也对软件工程及面向对象等方面的知识有了一个温习和巩固，对今后的学习起着积极的作用。在实验中碰到的几个困惑，或请教老师同学，或自己查阅资料都得到了解决，许多以前不甚理解的地方也豁然开朗，收获很大。

第四篇：《面向对象技术与UML课程设计》实验指导书

实验一 系统的用例模型

实验名称：系统的用例模型

实验类型: 设计性实验 学

时：一天

一、实验目的

1.熟悉用例图的基本功能和使用方法。

2.锻炼结合给定题目，进行有效需求分析的能力。 3.掌握如何使用建模工具绘制用例图的方法。

二、实验器材

1.计算机一台。

2.Rational Rose 工具软件。

三、实验内容

在理解用例图的基本功能和使用方法的基础上，结合具体问题，完成对系统的需求建模，得到用例模型后，应针对每个用例进行业务分析，说明其具体的业务流程。用Rational Rose工具软件绘制系统的用例图。

四、实验步骤

1.结合实际给定题目，完成系统的需求建模。

2.针对每个用例进行业务分析。以图书管理系统中“删除读者信息”用例为例来说明实验具体步骤。

(1)分析：在图书管理系统中,管理员首先登录系统,系统验证通过后,管理方可向系统查询数据,在查询后,系统会给出提示,有没有找到相关的数据,管理员根据系统查询的返回结果,进行下一步的操作,就是删除读者,在删除的过程中,系统会对查询得到的结果判断该记录是否可以删除,若可以删除,则给删除提示,若不能删除,也给相关的提示信息。

(2)根据分析结果，书写业务流程，一般包含以下信息：

①管理员在录入界面，输入待删除的读者名;

②“业务逻辑”组件在数据库中，查找待删除的读者名; ③如果不存在，则显示出错信息，返回步骤①，如果存在则继续; ④“业务逻辑”组件判断“待删除的读者”是否可以删除; ⑤如果不可以，则显示出错信息，返回步骤⑧，如果可以则继续; ⑥在数据库中，删除相关信息; ⑦显示删除成功信息; ⑧结束。

3.根据分析结果，绘制用例图。以图书管理系统中“删除读者信息”用例为例说明具体绘图步骤: (1)在用例图上双击main,出现如图1.1所示,为绘制用例图做好准备。

图1.1 (2)在图中的工具栏选取Actor图标，在右边的图中添加一个Actor，并输入名称:administrator,如图1.2所示。

(3)在左边的工具栏中，选取用例的图标，在右边的图中画出一个用例，并输入用例的名称：login 。

图1.2 (4)按照步骤(3)，绘制出如图1.4和图1.5的两个用例。

图1.3

图1.4

图1.5 (5)在绘出了用例后，接下来的是绘制参与者与用例实现，如图1.6所示。

图1.6

(6)根据步骤(5)，同时完成如图1.7和图1.8。此时，删除读者用例图就到此完成。其系统查询读者信息等其他的功能会在时序图和活动图中描绘。

(7)根据分析情况，进一步添加或细化用例图。

图1.7

图1.8

五、实验报告要求

1. 说明系统的需求建模结果，对主要用例整理用例图。 2. 小结实验心得体会。

实验二 系统的类模型

实验名称：系统的类模型

实验类型: 设计性实验 学

时：一天

一、实验目的

1.理解类的基本概念。

2.掌握如何从需求分析中抽象出类的方法。 3.掌握在Rational Rose中绘制类的操作方法。

二、实验器材

1.计算机一台。

2.Rational Rose 工具软件。

三、实验内容

完成实验一后，对给定题目的系统的需求的初步分析，得出系统的用例图，通过对用例的业务流程的分析，我们可以初步了解系统的业务处理流程。本实验需要对系统进行静态建模，这就需要从系统的用例图去寻找和发现类。用Rational Rose工具软件绘制系统的类图。

四、实验步骤

1.分析：由前面试验对需求的分析抽象出类。 2.绘制类图的步骤：

(1)打开前面初步构建的UML模型文件; (2)打开Rose中的逻辑视图(Logical View)，选择分析模型(analysis model)目录。并在其下创建一个子目录并命名为：“图书馆业务功能”。

(3)用鼠标右击“图书馆业务功能”在弹出来的菜单中选择“New→Class diagram”项，创建类图，如图2.1所示。

(4)双击新建的类图，并点右边控件集中选中的类的图标，并用鼠标在图中分别拖出一个类图，并命名为Book，如图2.2所示。

图2.1

图2.2 (5)接下来的一步为设置类的属性，在新的类中双击该类，在打开属性面板中，可以看到在此可以设置类的属性和方法等其他的信息，图2.3所示;后撞击Attributes这个栏目，此栏目为设置类的属性的选项，在图中间的单击右键，可以看到有一个“Insert”的选项，选中这个选项，图2.4所示，后在出现的对话框中输入相关信息如图2.5所示;如书本的ISBN号，在Type这个方框内输入此属性的类型值，同时可以看到一栏可以设置此属性的访问权限，一般这些属性都设置Private这个权限，如图2.6所示。这个类的其他属性也可以按照以上的做法设置，最后得到的结果是图2.7所示。

图2.3 图2.4

图2.5 图2.6 (6)设置好类的属性，现在来设置类的方法(也是操作)，双击类后在弹出的菜单上选operations这个选项，可以看到图2.8所示，在图中的空白地方，单击右键，在弹出的菜单中选insert这个选项，也就只有这个选项可用，见图2.9，接着输入方法名，同时可以设置该方法的返回类型，也可以在Documentations的方框内填写一些相关的方法说明，如图2.12所示，设置好该方法的访问权限，见图2.13。类的其他方法也可以按上面来设置好，最后，得到该类的其他方法见类2.14。

图2.7 图2.8

图2.9

图2.11

图2.10

图2.12

图2.13 图2.14 (7)至此，类的方法和属性都设置好了，如图2.15所示。

图2.15 (8)按照上面的步骤设置好所有类的属性和方法。

(9)为各个类添加关系，由关联、泛化、依赖等关系来静态描述业务。

五、实验报告要求

1.整理实验结果。 2.小结实验心得体会。

实验三 系统的状态建模

实验名称：系统的状态建模

实验类型: 设计性实验 学

时：一天

一、实验目的

1.熟悉状态图的基本功能和使用方法。 2.掌握如何使用建模工具绘制状态图方法。

二、实验器材

1.计算机一台。

2.Rational Rose 工具软件。

三、实验内容

完成实验一后，对给定题目的系统的需求的初步分析，得出系统的用例图，通过对用例的业务流程的分析，我们可以初步了解系统的业务处理流程，但对业务处理过程的处理状态间转换了解仍不够，这不利于设计人员对系统业务的进一步理解，而状态图能从对象的动态行为的角度去描述系统的业务活动。因此，在本实验主要完成用例的状态图。

四、实验步骤

1.业务分析：由前面实验对用例的描述和分析得到业务动态行为的状态分析。以用例“还书”为例，还书业务的动态行为是由：空闲(idle)、图书查找(finding)、还书(reversion)、失败(Failure)、归还成功(Success)5种状态及激活相互转换的事件。

2.绘制状态图。

还书的状态图，还书的主要业务都是由管理员来完成，首先管理员必须先登录系统，并通过验证后，便可以进行下一步的操作，查找该书的相关信息，如存在，则进行还书操作，如不存在该信息，则给出提示信息;

绘图步骤：

(1)在用例图中的还书(revesion)用例，单击右键，如图3.1所示，新建一个状态图，命名为revesion状态图，图3.2所示。

图3.1

图3.2 (2)双击“receivesion”状态图，展开后，在左边的工具栏上选取一个实心圆点，此结点为开始结点，图3.3所示;当还书的时候，操作者先要询问系统的状态，如果系统忙，操作者则必需等待，因此，得到系统的两种状态，如图3.5所示。

图3.3

图3.4

图3.5 (3)操作者在询问系统和状态后，得到的图3.6所示两种状态，如果系统忙，操作者必需要等待、结束，如图3.7和图3.8所示，重返步骤(1)。

图3.6

图3.7

图3.8 (4)如系统空闲，则进行对还书的信息进行查询操作，图3.9所示;查询也有两种结果，一是查询得到该书的相关信息，二查询不到该书的相关信息;则此时有两种状态，需要建立两种状态，如图3.10所示。

图3.9

图3.10 (5)最后，操作者进行了操作后，系统会给出操作的结果给操作者;操作成功或失败，都会有提示信息给出。整个的还书的过程便完成;图3.11所示。

(7)根据分析设计情况，进一步添加或细化状态图。

图3.11

五、实验报告要求

1.整理实验结果。 2.小结实验心得体会。

实验四 活动图

实验名称：活动图

实验类型: 设计性实验 学

时：一天

一、实验目的

1.熟悉活动图的基本功能和使用方法。 2.掌握如何使用建模工具绘制活动图方法。

二、实验器材

1.计算机一台。

2.Rational Rose 工具软件。

三、实验内容

完成实验一后，对给定题目的系统的需求的初步分析，得出系统的用例图，通过对用例的业务流程的分析，我们可以初步了解系统的业务处理流程。本实验在前面基础上绘制活动图，说明用例具体的业务流程。

四、实验步骤

(1)通过对用例的分析，得到用例执行的具体步骤。以用例“删除读者信息”为例，经过分析，一般按照以下步骤进行：

①管理员在录入界面，输入待删除的读者名;

②“业务逻辑”组件在数据库中，查找待删除的读者名;

③如果不存在，则显示出错信息，返回步骤(1)，如果存在则继续; ④“业务逻辑”组件判断“待删除的读者”是否可以删除; ⑤如果不可以，则显示出错信息，返回步骤(8)，如果可以则继续; ⑥在数据库中，删除相关信息; ⑦显示删除成功信息; ⑧结束。

(2)绘制活动图，以用例“删除读者信息为例”绘图步骤如下：

①在用例图中，找到删除的用例，如图4.1所示，在删除用例上单击右键，在弹出的快捷菜单中选“New”，Rose工具也会弹出一个菜单，选”Activity Diagram”，选中后单击，便可以新建好一个活动图。如图4.2所示。

图 4.1

图4.2 ②新建好活动图后，双击删除的活动图，得到如图4.3所示，然后把在左边的工具栏内点击“Swinlane“，在右边的图添加一个泳道，如图4.4所示，并命名为administrator.按照此步骤，再添加另一个泳道，并命名为SystemTool，得到图4.5。

图4.3 ③接着在左边的工具上选取开始点，并在administrator的泳道上添加，如图4.6所示;添加完开始结点后，再来为此活动图添加活动，图4.7所示，在左边的工具栏上选中Activity这个图标，在administrator这边的泳道上添加一个活动，命名为登录(login)，再在开始结点和活动登录(login)之间添加活动关系，如图4.8所示。

图4.4

图4.5

图4.6

图4.7

图4.8

④完成步骤②后，登录输入需要对输入的信息进行验证，则在图中添加一个验证框，如图4.9所示：添加验证框后，验证的内容，如果通过，则允许管理员进行查询操作，如图4.10所示;如不能通过，则结束，如图4.11所示。

图4.9

图4.10

图4.11

⑤验证后，下一步的操作是查询需要删除的记录，添加一个活动，命名为delete，如图4.12和图4.13所示。

图4.12

图4.13 ⑥最后，在删除后，系统会返回操作结果给操作者，图4.14所示;删除成功或删除失败系统都会有信息返回给操作者。

五、实验报告要求

1. 整理实验结果。 2. 小结实验心得体会。

实验五 顺序图

实验名称：顺序图

实验类型: 设计性实验 学

时：一天

一、实验目的

1.理解顺序图的基本概念。

2.掌握在Rational Rose中绘制交互图的操作方法。

二、实验器材

1.计算机一台。

2.Rational Rose 工具软件。

三、实验内容

通过对教学内容的学习，我们完成了系统的需求分析，并从业务对象中抽象出了类。现在需要对前面所给出的用例进行实现，而用例的实现主要由顺序图来指定和描述系统的动态特性。本实验主要在前面实验基础上对用例进行动态建模。

四、实验步骤

1.通过前面实验，分析系统中存在的主要交互操作。

2.为每一个交互操作绘制顺序图。以“增加图书”为例说明绘图步骤：

(1)在Rose软件的左边栏目上的Logicl View单击右键，新建一个时序图，顺序图可以用时序来表示，如图5.1;图中的直线箭头是发送消息;虚线箭头是返回消息;曲折线是对象自己给自己发送消息并调用。

(2)接下来的是添加类，系统中的类是其他的方法的边界，在上面做好的类找到可以直接拖拉来图中，见图5.2 和图5.3所示。

图5.1

图5.2

图5.3 (3)添加类后，便可以添加方法了，开始是必需是外面的实体向系统发送消息，如图5.4所示，是管理员登录时向系统发送的消息;

图5.4 (5)可以按上一步的方法来完成其他的方法，如viladate(验证),返回验证结果，当用户收到结果后，可以正常登录后便能进行增加图书见图5.5到图5.9。最后得到的时序图如图5.10所示。

图5.5 : administrator1: login : ActionFormSystem2: login3: validate

图5.6 : administrator1: login : ActionFormSystem2: login3: validate4: result5: result

图5.7 : administrator1: login : ActionFormSystem2: login3: validate4: result5: result6: add7: add

图5.8 : administrator1: login : ActionFormSystem2: login3: validate4: result5: result6: add7: add8: addbook

图5.9

: administrator1: login : ActionFormSystem2: login3: validate4: result5: result6: add7: add8: addbook9: addruselt10: addresult

图5.10

五、实验报告要求

1.整理实验结果。 2.小结实验心得体会。

第五篇：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