管理系统uml课程设计

2025-01-29 版权声明 我要投稿

管理系统uml课程设计(共8篇)

管理系统uml课程设计 篇1

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

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

1、需求分析

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

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

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

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

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

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

(4)系统设置模块

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

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

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

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

 仓库库存的进货与退货;

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

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

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

 供应商设置  仓库设置

3、工作内容及要求

 进一步细化需求分析的内容,识别出系统的参与者,并完成用例图; 无锡职业技术学院实践环节材料撰写用纸

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

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

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

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

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

4、创建SRS文档:

 引言

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

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

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

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

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

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

 界面需求

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

 此系统可以在网络上进行运行。    无锡职业技术学院实践环节材料撰写用纸

用例图如下:

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

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

图1 操作员用例图

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

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

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

图2 管理员用例图

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

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

图3 供应商用例图

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

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

 确定初始类图  提取类的属性  提取类的操作 无锡职业技术学院实践环节材料撰写用纸

 类之间的关系

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

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

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

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

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

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

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

图4 人员信息包类图

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

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

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

图5 接口信息包类图

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

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

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

图6 系统事务信息包类图

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

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

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

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

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

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

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

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

图7 仓库系统的活动图

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

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

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

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

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

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

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

B.商品管理协作图

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

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

图9 商品管理协作图 无锡职业技术学院实践环节材料撰写用纸

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

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

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

②序列关系图

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

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

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

商品盘点信息

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

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

图11 仓库盘点过程序列图

B.商品管理序列图

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

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

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

图12 商品管理序列图

C.仓库历史记录序列图

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

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

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

图13 仓库历史记录序列图 无锡职业技术学院实践环节材料撰写用纸

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

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

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

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

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

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

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

图14 组件关系图

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

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

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

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

管理系统uml课程设计 篇2

1 工作过程为导向的课程开发

作者近几年在《UML》课程的讲授和探索过程中发现, 无论是知识结构导向的课程教学, 还是案例导向的课程教学都不太合适。而以工作过程为导向的教学设计和方法, 恰如其分的描述了软件开发流程和《UML》课程相关知识。

2《UML》课程分析

UML相关知识:

UML (Unified Modeling language) 适用于面向对象的统一建模语言, 是描述UP (Unified Process) 和RUP (Rational Unified Process) 分析和设计结果的重要工具。与软件开发过程中使用的C、Java等编程语言一样, 由若干基本建模组件和建模规则等组成:

(1) 若干基本建模组件, 如参与者 (Actor) 、用例 (Use Case) 、类 (Class) 等, 是构成模型最基本的单位, 不可再分; (2) 9个图, 如用例图、类图、顺序图等, 由基本组件构成; (3) 5个视图, 如用例视图、设计视图等, 由若干图构成, 它描述的是系统的架构, 展现的是每个人在不同的时间以不同的方式观察系统。

3 工作过程为导向的《UML》课程设计

在《UML》课程开设之前, 学生已经学习了C、Java等程序设计语言课程, 已经基本具备了程序开发能力, 但非常缺乏基本的项目分析和设计能力。所以, 《UML》课程 (包含RUP) 的开设对学生职业能力的培养、熟悉工作流程, 让学生提前适应未来的专业岗位至关重要。

3.1 工作过程为导向的《UML》课程分析

高职高专计算机应用和软件技术类毕业生在未来的工作岗位上主要从事代码编写和软件测试等工作, 但软件开发要求非常强的团队协作、较好阅读文档、熟悉软件开发流程等能力, 而RUP (包含UML) 体现了软件项目的开发流程, 其分析设计的结果是相关项目文档。

(1) 项目先启阶段, 主要工作任务为业务分析、建模和需求捕获等, UML应用为系统业务模型 (业务用例模型, 分析类图模型等) , 系统主用例模型、主类图模型, 部分交互图、状态机模型等。

(2) 项目精化阶段, 主要工作任务为需求捕获、分析设计、实施等, UML应用为系统用例图模型、类图模型、交互图模型、状态机模型等。

(3) 项目构建阶段, 主要工作任务为需求捕获、设计、实施、测试等, UML应用为系统完整用例图模型、完整类图模型、组件图模型、部署图模型、UML双向工程等。

(4) 项目产品化阶段, 主要工作任务为实施、测试、部署、核心支持工作等, UML应用为系统用例图模型、完整类图模型、组件图模型、部署图模型等。

3.2 工作过程为导向的《UML》课程设计

根据软件开发流程的, 结合《UML》课程内容, 本文设计一个以工作过程为导向的《UML》教学过程。在该教学过程中, 采用了“三二一”教学方法, 其中, “三”指的是, 课程教学过程采用了三个项目, 项目1用来完成课程知识的讲授;项目2让学生用来完成练习, 理解所学的知识;项目3让学生完成项目实训, 理解并掌握所学知识。教学过程中, 三个项目交替进行。“二”指的是, 一个教学点从难到易讲解两遍, 不仅符合知识学习的重复性, 也符合学生学情。“一”指的是, 让学生完成一个简单的软件开发文档, 从而让学生掌握基本的文档分析和设计方法, 掌握面向对象软件开发文档中UML建模知识的应用。项目为导向的学习型工作任务分解如下。

(1) 项目1学习型工作任务分解

1-1软件工程、UML概述;

1-2用例图的分析与设计;

1-3类图的分析与设计;

1-4交互图的分析与设计;

1-5状态机图的分析与设计;

1-6组件图、部署图的分析与设计;

1-7 RUP统一过程。

(2) 项目2学习型工作任务分解

2-1用例图分析与设计上机练习;

2-2类图实训分析与设计上机练习;

2-3交互图分析与设计上机练习;

2-4状态机图分析与设计上机练习。

(3) 项目3学习型工作任务分解

3-1用例图分析与设计实训;

3-2类图分析与设计实训;

3-3交互图分析与设计实训;

3-4状态机图分析与设计实训;

3-5组件图、部署图分析与设计实训;

3-6 RUP文档实训。

3.3《UML》课程学习型工作任务分解

学习型工作任务1-1中, 主要介绍软件工程的概念, RUP的概念, UML的概念和UML的相关内容。

学习型工作任务1-2、2-1和3-1针对用例图分析与设计, 分解过程和讲解内容如下:

第一次讲解:1-2, 用例图的概念, 参与者和用例的发掘, 参与者与用例间的关联关系, RUP的先启阶段等;2-1, 通过练习理解简单的用例图分析与设计;3-1, 通过实训掌握简单的用例图分析与设计。

第二次讲解:1-2, 用例图中的Include、Extend和泛化关系等;2-1, 通过练习理解复杂的用例图分析与设计;3-1, 通过实训掌握复杂的用例图分析与设计。

学习型工作任务1-3、2-2和3-2针对类图的分析与设计, 分解过程和讲解内容如下。

第一次讲解:1-3, 类图的概念, 类和接口的概念, 实现关系, 泛化关系 (子类与父类) 等, RUP精化阶段;2-2, 通过练习理解简单的类图分析与设计;3-2, 通过实训掌握简单的类图分析与设计。

第二次讲解:1-3, 类图中类的规范, 泛化、关联关系, 关联关系的多重性, UML双向工程等;2-2, 通过练习理解复杂的类图分析与设计;3-2, 通过实训掌握复杂的类图分析与设计。

学习型工作任务1-4、2-3和3-3针对交互图分析与设计, 分解过程和讲解内容如下。

第一次讲解:1-4, 交互图的概念, 交互图与用例文档的干系, 消息的概念和分类, 顺序图, RUP构建阶段;2-3, 通过练习理解简单的顺序图分析与设计;3-3, 通过实训掌握简单的顺序图分析与设计。

第二次讲解:1-4, 如何使用顺序图发现类的方法, 协作图, 顺序图与协作图的关系;2-3, 通过练习理解复杂的交互图分析与设计;3-3, 过实训掌握复杂的交互图分析与设计。

学习型工作任务1-5、2-4和3-4针对状态机图分析与设计, 分解过程和讲解内容如下。

第一次讲解:1-5, 状态机图的概念, 状态机, 状态, 状态间的转移, 事件, 状态图, RUP产品化阶段;2-4, 通过练习理解简单的状态机图分析与设计;3-4, 通过实训掌握简单的状态机图分析与设

第二次讲解:1-4, 状态的规范, 转移的规范, 活动, 活动图;2-3, 通过练习理解复杂的状态机图分析与设计;3-3, 通过实训掌握复杂的交互图分析与设计。

学习型工作任务1-6、3-5中, 讲解并组件图和部署图的相关知识, 并通过练习和实训, 掌握组件图与部署图的分析和设计方法等。

学习型工作任务3-6中, 完成一个简单的RUP文档, 通过该任务, 是学生掌握简单的RUP文档分析和设计方法, 理解RUP文档中所包含的UML模型等。

结语

首先介绍了《UML》课程的特点, 接着对《UML》课程内容和软件开发流程进行类分析, 重点论述了工作过程为导向的《UML》课程设计。在作者近几年的教学过程中不断探索与总结中发现, 以工作过程为导向的教学方法非常适合《UML》课程教学。但由于本校教学学时的限制, 没有涉及到UML建模中的业务分析与业务建模, 在以后的教学过程中, 会逐渐完善这部分的教学内容。

摘要:以工作过程为导向的课程开发是高职教学课程改革的热点和难点。结合近几年在《UML》教学过程中的探讨和实践, 论述了软件技术专业《UML》课程的开发过程及内容。

管理系统uml课程设计 篇3

关键词:UM;系统建模;实验室管理

中图分类号:TP311.52 文献标识码:A文章编号:1007-9599 (2010) 13-0000-02

The Design of Management System for Laboratories on UML

Ma Wei

Changchun engineering college,130012

Abstract:UML is an object-oriented modeling language, the standard in system development is widely used. Based on laboratory management system software development needs,describes the system function requirement analysis modeling process.

Keywords:UML;system modeling;laboratory management

随着近年来高校教育改革和发展,为了进一步提高各高校管理的水平,不得不考虑如何提高工作的效率。实验室管理系统是网络教学的重要组成部分,主要实现实验室信息管理,发送报告、管理学习内容、预约实验室课程等功能。本文基于UML作为分析设计描述语言,分析设计了一个实验室管理系统。

一、UML建模机制

UML(Unified Modeling Language的缩写)统一建模语言,它是用来对软件密集系统进行可视化建模的一种语言。UML作为一种对软件系统进行规约、构造、可视化和文档化的语言,它融合Booch方法、OMT方法的核心概念而形成的一个公共的、同意的、有广泛实用性的建模语言。它也是为面向对象开发系统的产品进行说明、可视化、和编制文档的一种标准语言。

二、需求分析

开发者要充分了解客户的需要才能够设计出比较完善的系统,如果不能很好的理解客户需求,在设计上就会返工,下面就是经过双方调研后的到的需求說明。

(一)系统管理模块:该模块下又包括了用户管理、数据库备份、数据库还原等个子模块。由于该模块是对整个系统中权限的管理,所以该模块只有超级管理员可以操作,在这里超级用户可以添加其他用户并授予不用级别的管理权限。

(二)教师管理模块:该模块下又包括了实验授课计划表和审批、调串课三个子模块,该模块是教师登录后可管理的模块,所以该模块是对教师组登录后才可见的。教师在实验授课计划表中填写好所做实验的地点、时间、项目、班级、学生数等具体情况,用来为系统的自动排课提供信息,然而只有通过审批的计划表才可以参加排课。

(三)实验室管理功能:包括实验室信息、实验室统计、课程管理、实验室统计、设备管理、公告、日志管理、实验室预约管理七个子模块,辅助实验员与教师根据实验教学计划安排实验任务以及对实施情况进行监督管理。

(四)学生管理模块:学生在登录系统后可以进行实验室开放课程预选,并且可以查看课表。

三、用例视图的建立

用例视图描述的是系统的参与者与系统进行交互的功能,是参与者所能观察和使用到的系统功能的模型图。用例视图通常用例图表示,一个用例图就是系统中的一个功能模块,它表示参与者与系统之间进行的一次交互作用,也把参与者与系统中的用例的联系给标识出来,并确定什么样的参与者执行的哪个用例。系统的参与者可以使人,也可以使外部系统或子系统等。以本系统的“实验员”功能为例的用例图,如图1所示。

四、系统的静态模型的建立

UML建模分析与设计中静态模型是依据系统结构从静态观点描述系统的视图,它定义系统中的对象和类及类之间的关系和类的内部结构,即类的属性和操作。系统的静态模型主要包括静态视图(类图、对象图、包图)、用例视图(用例图)、实现视图(构件图、配置图)。

实验室管理系统中的“课程管理”用例的类图如图2 所示。

在“课程管理”用力中,有“课程类别(Course)”、“开放课程类(CouserOffering)”、“班级类(Class)”、“学生类(Student)”、“教师类(Teacher)”、“课程表(CourseOfferingform)”等。

五、系统的动态模型的建立

系统的静态模型建立以后,开始进行系统的动态建模。动态模型包括行为视图(状态图、活动图)、交互视图(顺序图、协作图)。顺序图将交互关系表示为一个二维图。纵向是时间轴,横向代表协作中独立对象的类元角色。类元角色用生命线表示。当对象存在时,角色用一条虚线表示,当对象的过程处于激活状态时,生命线是一个双道线。消息从一个对象的生命线到另外一个对象生命线的箭头表示。箭头以时间顺序在图中从上到下排列

六、结束语

基于ASP的实验室设备管理系统,是结合高校的实际情况所设计的一个基于数字化校园信息平台的实验室设备管理系统,它实现了高校实验室设备的网络化管理。在进行系统需求分析这个重要阶段时选择UML进行系统建模,可以让用户更好的参与进来,加强信息的交流,既加快了开发人员对问题的理解,又让设计流程变得清晰化。这说明UML这种系统建模提高了系统开发的成功性,促进了系统的实用性、规范性。

参考文献:

[1]时陪芳,张永胜.基于UML的上考试系统的设计[J].计算机系统应用,2005,(10)

管理系统uml课程设计 篇4

摘要:本文对面向对象的概念、UML产生的背景及其基本内容进行了阐述,在对图书馆图书管理系统进行功能描述和需求分析的基础上,结合软件工程和面向对象需求分析,设计了基于UML的用例图、包图和顺序图,状态图等语言机制的图书馆图书管理系统模型。关键词: UML;建模语言;面向对象;需求分析;图书管理系统 1关于面向对象

面向对象是一种的程序设计方法,或者说它是一种程序设计类型,其基本思想是使用对象,类,继承,封装,消息等基本概念来进行程序设计。它是从现实世界中客观存在的事物(即对象)出发来构造软件系统,并在系统构造中尽可能运用人类的自然思维方式,强调直接以问题域(现实世界)中的事物为中心来思考问题,认识问题,并根据这些事物的本质特点,把它们抽象地表示为系统中的对象,作为系统的基本构成单位(而不是用一些与现实世界中的事物相关比较远,并且没有对应关系的其它概念来构造系统)。这可以使系统直接地映射问题域,保持问题域中事物及其相互关系的本来面貌。它可以有不同层次的理解:

(1)从世界观的角度可以认为:面向对象的基本哲学是认为世界是由各种各样具有自己的运动规律和内部状态的对象所组成的;不同对象之间的相互作用和通讯构成了完整的现实世界。因此,人们应当按照现实世界这个本来面貌来理解世界,直接通过对象及其相互关系来反映世界。这样建立起来的系统才能符合现实世界的本来面目。

(2)从方法学的角度可以认为:面向对象的方法是面向对象的世界观在开发方法中的直接运用。它强调系统的结构应该直接与现实世界的结构相对应,应该围绕现实世界中的对象来构造系统,而不是围绕功能来构造系统。

(3)从程序设计的角度来看,面向对象的程序设计语言必须有描述对象及其相互之间关系的语言成分。这些程序设计语言可以归纳为以下几类:系统中一切皆为对象;对象是属性及其操作的封装体;对象可按其性质划分为类,对象成为类的实例;实例关系和继承关系是对象之间的静态关系;消息传递是对象之间动态联系的唯一形式,也是计算的唯一形式;方法是消息的序列。

面向对象的方法学包括了以下核心概念:

对象(object):即指现实世界中各种各样的实体。它可以指具体的事物也可以指抽象的事物。

类(class):类是具有相似内部状态和运动规律的实体的集合(或统称、抽象)。类的概念来自于人们认识自然、认识社会的过程。

消息(Message): 消息是指对象间相互联系和相互作用的方式。一个消息主要由5部分组成:发送消息的对象、接收消息的对象、消息传递办法、消息内容(参数)、反馈。

封装:对象间的相互联系和相互作用过程主要通过消息机制得以实现。对象之间并不需要过多的了解对方内部的具体状态或运动规律。面向对象的类是封装良好的模块,类定义将其说明(用户可见的外部接口)与实现(用户不可见的内部实现)显式地分开,其内部实现按其具体定义的作用域提供保护。类是封装的最基本单位。封装防止了程序相互依赖性而带来的变动影响。在类中定义的接收对方消息的方法称为类的接口。

继承:类之间的继承关系是现实世界中遗传关系的直接模拟,它表示类之间的内在联系,以及对属性和操作的共享,即子类可以沿用父类的某些特征。

重载:重载是指类的同名方法在给其传递不同的参数是可以有不同的运动规律。在对象间相互作用时,即使接收消息对象采用相同的接收办法,但消息内容的详细程度不同,接收消息对象内部的运动规律也可能不同。关于UML UML(Unified Modeling Language)是在Booch方法、OOSE方法和OMT方法的基础上演化而来的基于面向对象技术的标准建模语言。它统一了面向对象建模的基本概念、术语和图示符号,描述了建模过程中所必须遵循的基本步骤,提供了一整套描述软件系统模型的概念和图形表示法,可从不同的视角为系统建模。统一建模语言UML是一种语义丰富、通用、可视化的建模语言和事实上的国际工业标准,易于理解和交流。UML提供的丰富的视图从多个视角描述系统的不同侧面,可以有效运用于软件的建模、分析与设计。标准建模语言UML的定义包括UML语义和UML表示法两个部分。UML语义通过其元模型来严格地定义。UML表示法定义UML符号的表示法,为开发者或开发工具使用这些图形符号和文本语法来建模提供标准。这些图形符号和文字所表达的是应用级的模型,在语义上它是UML元模型的实例。UML的主要内容通常用用例图、类图、对象图、状态图、活动图、构件图、配置图、顺序图、协作图和包图等l0种图来描述,它们从不同的角度和层次为系统建模提供支持,完全可以 描述系统的方方面面。

与传统的软件建模方法相比, UML 有如下一些特点:(1)UML 是一个可视化建模语言, 是一种图形化的面向对象的设计工具语言,而不是可视化程序设计语言,但用UML描述的模型可与各种编程语言直接相连,把UML 模型映射成编程语言。在不同程序中使用同样的UML 图表类型, 因为UML 具有任意程序的独立性,定义一个标准程序不是一个UML 的目标。

(2)UML 是一种可用于详细描述的语言,其所建立的模型是精确、无歧义和完整的。同时UML是一种文档化的语言,对其各建模元素可进行详细说明,并能生成所建模型的文档。标准建模语言UML支持面向对象的分析与设计,定义良好、易于表达、功能强大。它的最大用途是利用图形来描述真实世界各个对象的符合表示,让所有系统设计者在构建系统需求分析、对象模型化定义到对象设计的整个开发过程完全标准化。3 本课题的研究意义

一个图书馆的图书资料库在正常运转中总是面对大量的读者信息、书籍信息以及两者相互作用产生的借书信息、还书信息。图书馆作为一个信息资源的集散地,图书和用户借阅资料繁多,包含着很多的信息数据。以前对信息管理的主要方式是基于文本、表格等纸介质的手工处理,对于图书借阅情况(如借书天数、超过限定借书时间的天数)的统计和核实等往往采用人工检查,对借阅者的借阅权限以及借阅天数等采用人工计算、手抄进行,数据信息处理工作量大,容易出错和丢失。因此,建立一个智能化、系统化、信息化的图书资料库是十分重要的。使用计算机软件对图书进行管理,是计算机应用的一部分。充分利用计算机的功能,实现对读者管理、书籍管理等自动化控制,将会使图书资料库的工作强度大大减弱,可以实现图书检索迅速、可靠性高、存储量大、寿命长、成本低,能最大限度地提高图书管理的效率,也是图书管理信息化、正规化管理的必然趋势。4 基于UML的图书管理系统的需求分析与设计过程

图书管理系统的开发和应用主要通过两个步骤来实现:首先是基于系统功能的需求分析,其次是系统模型的设计和实现。

4.1需求分析

需求分析是软件工程过程的一个重要阶段,其中一个主要任务是确定系统的功能需求,采用面向对象方法,基于UML的可视化系统需求分析,因为有用户的积极参与,既可以加快设计者对于问题的理解,又能够在系统描述方面减少语义差异,保证分析的正确性。需求分析的目标就是建立需求模型,即从功能需求出发建立用例模型, UML的用例视图从用户的需求中提取,以盒图的方式描述待开发的系统的功能需求。每个用例都指定了客户的需求即他们需要系统干什么。用例图为设计活动不仅记 录需求而且还提供了一种挖掘的信息, 它记录了需求到设计结果之间的映射关系,能够确保设计结果具有明确的根据或者说具有可维护性,基于UML的软件开发过程是以用例驱动的。

首先我们进行角色识别,角色识别的任务是找出所有可能与系统发生交互行为的外部实体、对象、系统。它们的行为不受系统控制,但是可以提供输入给系统。对于一所大学的图书管理系统,基本的功能是完成图书的借阅和相关信息的管理,服务的对象有本科生,研究生,教师,及其他学校的学生,还有社会人员,这些人可归结为一类即读者。而为帮助读者顺利完成借还书的可以是工作人员,可以是自动借还书机,他们可以归结为一类即图书管理人员。因此对于一个图书管理系统主要有两类角色,读者、图书管理员。

其次,在主要角色的基础上,可以识别出与角色相应的用例,从而得到系统的用例模型。与读者相关的过程包括:借书、还书、预定、图书信息检索、借阅查询(如查询本人借书记录、还书期限、是否超期)、个人相关信息查询及修改(如学号、姓名、性别、年级、专业、家庭住址、联系电话、出生日期、民族、政治面貌、身份证号等)。与图书管理员相关的过程包括:办理借书、办理还书、解除预定、图书订购、读者信息管理(增加/删除读者、修改读者权限及密码、借阅超期罚款)、图书信息管理(增加/删除数目、图书类别等相关信息的修改、流通情况)。系统管理(系统的登陆、退出、日志维护、系统更新)。以上分析中,与读者,图书管理员相关的过程构成了本系统的基本用例。

4.2 系统的整体结构

综上所述一个图书管理系统的整体结构可以分为三大模块:图书管理模块、读者管理模块、系统管理模块。

(1)图书管理模块包括与图书相关的一些过程,主要有图书的借出、图书的归还、预定、图书信息检索、图书订购、图书相关信息管理。

(2)读者管理模块主要包括与读者有联系相关的过程,主要有增加/删除读者、修改读者权限及密码、借阅信息查询、个人信息查询及修该、借阅超期和丢失罚款。

(3)系统管理模块包括系统的登陆、退出、系统维护、系统更新。综上我们画出系统的整体结构,如图一所示:

图书管理系统图书管理读者管理图一 图书管理系统的整体结构

系统管理 4.3 图书管理系统的用例图

从以上分析中我们不难得出系统的基本用例图,如图二所示:

借书/还书预定/解除预定图书检索图书信息管理图书订购借阅信息查询个人信息查询/修改读者信息管理 读者借阅超期罚款 图书管理员系统管理图二 系统的基本用例图

图书管理和图书管理是图书管理系统的重要组成部分,为此我们按照前文所述将图书管理模块和读者模块以及系统管理模块详细精化得出如下的用例图,如图

三、图

四、图五所示:

按年代查询图书借入借出管理出版社查询图书购入作者查询图书查询书名查询图书管理模糊查询图书管理员图书信息管理类别查询信息删除信息添加

图三 图书管理模块的用例图

信息修改增加/删除读者修改权限个人信息查询/修改图书管理员读者管理读者借阅信息查询读者办理挂失图四 读者管理用例图

超期/丢失罚款

登陆/退出软件更新系统管理系统更新 管理员系统维护硬件更新日志维护 图五 系统管理模块的用例图

4.4 图书管理系统的行为图

我们再进行动态建模分析。对于图书管理系统借书还书是两个重要的过程,我们先来分析一下借书、还书的一般过程,并由借书的一般过程画出其顺序图、协作图以及活动图。

(1)借书的过程:读者刷卡进入图书馆,或者先查询图书及个人借阅信息,或者直接去挑选图书,选择好图书后进入借书程序,管理员先检查读者的借书证件,查验能否借阅,比如:证件是否无效或书籍是否已经借满等,即检验其借书的合法性和有效性,如果是非法用户或借书数量范围外,则该读者不能借阅图书。如果满足借阅要求,则再获取所借书的标题以进行库内搜索,获取书目查询此书的数量,看是否还有此书,如果没有则阻止其他借书者可能进行的预订活动,将此书借出,根据书号将此书的借阅标志位取反以表示此书已借出,并将此书的书目减1。并为此读者记录借阅日期,以及归还日期,在归还日期内未能归还和续借的,并为其记录超借天数及罚款数额。

(2)还书过程:在返还图书的过程中,管理员首先获取读者的借阅信息和被归还的书籍的信息,如书标题信息,数量等,并一一审核每本书的归还日期是否超过应归还日期。在完成阶段,将此书的书号登记并设计标志位为已归还,以便读者网上预订和继续借阅,同时将此类图书的数量加1,如果读者超期或丢失所借书籍,则要进行赔偿处理。

所以我们不难画出借书一般过程的顺序图,如图六所示:

图书管理员读者信息图书信息修改图书借出刷卡进入并选书核对读者信息 图书扫描并消磁修改读者借阅信息图六 借书一般过程的顺序图

有顺序图可得到协作图,如图七所示。仔细分析借书过程的细节,可以画出如图八所示的活动图,它表示了复杂算法的过程,尤其是过程中的判断、并发和同步。

刷卡进入 读者挑选图书图书管理员 核对信息图书信息修改图书扫描 消磁读者借阅信息 修改读者信息图书借出

图七 借书一般过程的协作图

读者 管理系统N禁止入内刷卡是否为本馆服务对象Y输入卡号/密码选择图书N卡号密码正确?Y个人信息查询/修改Y借阅信息查询图书检索刷条形码显示读者相关信息能否借阅N确定借书NY刷图书条码更改改读者及图书的借阅信息退出是否借阅完毕YN图八 借书过程活动图

以上我们用多种语言机制分析了读者的主要相关事件流,下面我们绘制图书管理员使用系统的状态图分析图书管理员的主要事件流。从以上分析可知,图书管理员相关的过程包括:办理借书、办理还书、解除预定、图书订购、读者信息管理(增加/删除读者、修改读者权限及密码、借阅超期罚款)、图书信息管理(增加/删除数目、图书类别等相关信息的修改、流通情况)。由此我们可绘制如图九所示的图书管理员使用系统的状态图:

登陆关闭办理借书修改图书信息办理还书增加数目图书预留取消增加加读者解除预定删除读者查询数目存储信息修改读者权限查询读者信息图九图书管理员使用系统的状态图

4.5 图书管理系统的静态图

定义并描述了各个类后,我们可以根据实际情况引入包来管理类,本图书馆管理系统可以划分为四个包:用户管理:对系统用户进行管理,为用户提供信息服务接口,便于对系统进行操作。借阅管理包括借书处理,还书处理和罚款处理等。读者管理包括对读者图书等信息进行维护,主要有读者信息的增删,对图书更新资料进行维护。系统服务:包括系统登录检查,安全维护等。系统的包图如图十所示:

用户管理借阅管理读者及图书管理系统服务 图十 系统包图 4.6 图书管理系统的实现

经过系统分析和设计后,就可以根据设计模型在具体的环境中实现系统,生成系统的源代码、可执行程序和相应的软件文档,建立一个可执行系统。进而需要对系统进行测试和排错,保证系统符合预定的要求,获得一个无错的系统实现。测试结果将确认所完成的系统可以真正使用。参考文献

[1] 齐治昌.谭庆平.宁洪.软件工程.北京:高等教育出版社 [2] 张海藩.软件工程.北京:人民邮电出版社

[3] 董翔.基于UML的图书管理系统的开发和应用.科技情报开发与经济2008年第l8卷第l2期 [4] 吴开华.邢养晓.罗德撤

.数字图书馆元数据研究[J].中国图书馆学报,2002,(3).

[5] 刘治国.构建基于B/S结构的图书管理系统[J].信息技术,2005(3):72—73. [6] 管斌.袁国忠 译.用例驱动的UML对象建模应用-范例分析.北京:人民邮电出版社 结束语

UML建模--银行管理系统 篇5

建模

课程设计报告

专业:

学号:

姓名:

任课教师:

一、系统概述

银行是与人们生活密切相关的一个机构,银行可以提供存款、取款、转账等业务。在银行设立账户的人或机构被称为银行的客户(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的网络购物系统的分析 篇6

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

关键词:对象管理组织统一建模语言 [Abstract]: [key words]:

1.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虽然是一种面向对象的软件系统设计的标准描述语言,但是在其状态图中用状态和迁移表示对象行为关联时用到了大量的不易于理解的注释字符,因此,系统的UML模型既不是可以执行的也是不和用编程语言开发的可执行程序相协调。

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

3.1网络购物系统的需求分析:

1:普通用户可以登陆系统,成为登陆后用户。

2:普通用户只具有搜索产品、查看产品分类、查看产品项目、查看产品等几个基本权限。

3:除提供一般权限外,本系统还可为登陆后用户提供编辑帐号、购物车、定单、结算的功能和服务。

4:登陆后用户可修改购物数量。3.2 用例图的分析:确定执行者 1谁使用系统的主要功能?

2谁需要从系统获得对日常工作的支持和服务?

3需要谁维护管理系统的日常运行?

4公司的哪个部门使用系统?

5系统需要与其它哪些系统交互?

6谁需要使用系统产生的结果? 针对网上购物系统的前台系统,通过回答以上问题,可以得到执行者有两类,普通用户和登录后的用户。确定用例:

2系统需要哪些输入/输出?这些输入/输出从何而来?到哪里去?

4执行者是否需要对系统中的信息进行读、创建、修改、删除或存储? 绘制用例图如下,见图(1):

3.3类图的分析:画类图和理解类图时都应采用三个层次的观点。这些观点也适用于其它模型。三个层次的观点不是UML的组成部分,但对建造模型或评价模型都非常有用,且都可应用于UML.(1)概念层描述应用域中的概念,是对现实世界的直接描述,与实现它们的类有关但与实现方案和实现语言无关。(2)说明层描述软件的接口,而不是软件的实现。一个类型描述一个接口,但可能有多种实现。(3)实现层从实现的角度定义类及其实现,揭示了软件实现体的构成情况。

针对当前系统1产品类(Product)的主要操作:设置和获取每个属性值的方法。2产品类别类(Category)的主要操作:设置和获取每个属性值的方法。3产品项目类(Item)的主要操作:设置和获取每个属性值的方法

4订单类(Order)的主要操作:设置和获取每个属性值的方法、初始化订单(initOrder)、增加产品项目(addLineItem)等。

5购物车类(Cart)的主要操作:设置和获取每个属性值的方法、增加产品项目(addItem)、删除产品项目(removeItemById)等。

6购物车项目类(CartItem)的主要操作:设置和获取每个属性值的方法、统计金额(calculateTotal)等。

下面是系统的类图,见图(2):

4.系统的顺序图分析:顺序图可描述几个对象间的动态协作关系,它非常直观的展示了对象之间传递消息的时间顺序。反映了系统执行过程中某个特定时刻所发生的事情。在系统分析时,可对主要对象类绘制顺序图,以便分析系统的行为,验证和修改系统的静态结构,满足用户的需求,达到系统的目标。根据以上图(1)、图(2)的分析,可得网上购物系统如下,见图(3):

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

管理系统uml课程设计 篇7

1 统一建模语言(UML)简介

统一建模语言(UML是Unified Modeling Language的缩写)是用来对软件密集系统进行可视化建模的一种语言[1]。它是面向对象开发系统的产品进行说明、可视化、和编制文档的一种标准语言。UML是在开发阶段,说明,可视化,构建和书写一个面向对象软件密集系统的制品的开放方法,同时展现了一系列最佳工程实践,这些最佳实践在对大规模,复杂系统进行建模方面,特别是在软件架构层次已经被验证有效。UML可以贯穿软件开发周期中的每一个阶段,被OMG采纳作为业界的标准。它最适于数据建模,业务建模,对象建模,组件建模。作为一种模型语言,它使开发人员专注于建立产品的模型和结构,而不是选用什么程序语言和算法实现。当模型建立之后,模型可以被UML工具转化成指定的程序语言代码。

作为一种建模语言,UML的定义包括UML语义和UML表示法两个部分:

1)UML语义描述基于UML的精确元模型定义。元模型为UML的所有元素在语法和语义上提供了简单、一致、通用的定义性说明,使开发者能在语义上取得一致,消除了因人而异的最佳表达方法所造成的影响。此外UML还支持对元模型的扩展定义。

2)UML表示法定义UML符号的表示法,为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准。这些图形符号和文字所表达的是应用级的模型,在语义上它是UML元模型的实例。

标准建模语言UML的重要内容可以由下列五类图(共9种图形)[2]来定义:

第一类是用例图,从用户角度描述系统功能,并指出各功能的操作者。

第二类是静态图(Static diagram),包括类图、对象图和包图。其中类图描述系统中类的静态结构。不仅定义系统中的类,表示类之间的联系如关联、依赖、聚合等,也包括类的内部结构(类的属性和操作)。类图描述的是一种静态关系,在系统的整个生命周期都是有效的。对象图是类图的实例,几乎使用与类图完全相同的标识。他们的不同点在于对象图显示类的多个对象实例,而不是实际的类。一个对象图是类图的一个实例。由于对象存在生命周期,因此对象图只能在系统某一时间段存在。包图由包或类组成,表示包与包之间的关系。包图用于描述系统的分层结构。

第三类是行为图(Behavior diagram),描述系统的动态模型和组成对象间的交互关系。其中状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件。通常,状态图是对类图的补充。在实用上并不需要为所有的类画状态图,仅为那些有多个状态其行为受外界环境的影响并且发生改变的类画状态图。而活动图描述满足用例要求所要进行的活动以及活动间的约束关系,有利于识别并行活动。

第四类是交互图(Interactive diagram),描述对象间的交互关系。其中顺序图显示对象之间的动态合作关系,它强调对象之间消息发送的顺序,同时显示对象之间的交互;合作图描述对象间的协作关系,合作图跟顺序图相似,显示对象间的动态合作关系。除显示信息交换外,合作图还显示对象以及它们之间的关系。如果强调时间和顺序,则使用顺序图;如果强调上下级关系,则选择合作图。这两种图合称为交互图。

第五类是实现图(Implementation diagram)。其中构件图描述代码部件的物理结构及各部件之间的依赖关系。一个部件可能是一个资源代码部件、一个二进制部件或一个可执行部件。它包含逻辑类或实现类的有关信息。部件图有助于分析和理解部件之间的相互影响程度。

2 系统需求概述

本文介绍的一个小型的项目信息管理系统,是为了对企业内部正在进行中的项目和已完成的项目进行查询,从而达到了解项目进度,进一步控制项目的进度的目的。为了降低企业在通信和软件部署方面的成本选用了基于网络的客户机/服务器的3层体系结构。该系统的业务逻辑部分主要由两个功能模块组成:合同信息管理模块,项目信息管理模块。

合同信息管理模块,主要负责收集合同的信息,包括与企业签订合同的公司和单位、合同签订日期、简单摘要、合同状态和合同金额等的信息,还包括采购和销售合同的信息管理,采购合同是供应商同本企业之间的契约。计划部成员可以根据业务需要来建立、查询、修改、追踪、审核本企业所要外购商品或服务的数量、价值和流向。销售合同的管理、处理逻辑和采购合同类似。

项目信息管理模块是主要业务操作模块。它包括以下内容:

项目和任务的信息(任务和项目是多对一的关系)的管理。

任务的计划和进度信息管理。

项目或任务的计划和进度的查询信息管理。

项目或任务的计划和进度的查询报表信息管理。

此外,作为一个完整的信息系统,还需要提供有效的系统管理工具,比如,用户管理、权限管理、配置管理等。

3 用例图的使用———对系统需求的建模

用例建模[3]是UML建模的一部分,它也是UML里最基础的部分。用例建模的最主要功能就是用来表达系统的功能性需求或行为。依我的理解用例建模可分为用例图和用例描述。用例图由参与者(Actor)、用例(Use Case)、系统边界、箭头组成,用画图的方法来完成。用例描述用来详细描述用例图中每个用例,用文本文档来完成。

用例图中的参与者不是特指人,是指系统以外的,在使用系统或与系统交互中所扮演的角色。因此参与者可以是人,可以是事物,也可以是时间或其他系统等等。还有一点要注意的是,参与者不是指人或事物本身,而是表示人或事物当时所扮演的角色。比如小明是图书馆的管理员,他参与图书馆管理系统的交互,这时他既可以作为管理员这个角色参与管理,也可以作为借书者向图书馆借书,在这里小明扮演了两个角色,是两个不同的参与者。参与者在画图中用简笔人物画来表示,人物下面附上参与者的名称。

用例是对包括变量在内的一组动作序列的描述,系统执行这些动作,并产生传递特定参与者的价值的可观察结果。这是UML对用例的正式定义,对我们初学者可能有点难懂。我们可以这样去理解,用例是参与者想要系统做的事情。对于对用例的命名,我们可以给用例取一个简单、描述性的名称,一般为带有动作性的词。用例在画图中用椭圆来表示,椭圆下面附上用例的名称。

系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分,边界外表示系统外部。系统边界在画图中方框来表示,同时附上系统的名称,参与者画在边界的外面,用例画在边界里面。因为系统边界的作用有时候不是很明显,所以我个人理解,在画图时可省略。箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。箭头尾部用来表示启动交互的一方,箭头头部用来表示被启动的一方,其中用例总是要由参与者来启动。

当一个系统需求被提出后,系统内部各个功能之间的关系就基本被确定了。用例图的使用是的在设计工作的一开始设计人员就可以方便地来根据需求对系统进行建模。

此外,作为一个完整的信息系统,还需要提供有效的系统管理工具,比如,用户管理、权限管理、配置管理等。

图3为系统用例图的一部分,图中列出了9个用例,其中为“系统管理”、“一般信息管理”、“项目信息管理”和“合同信息管理”等4个用例代表的就是上文提到的几个主要的功能模块。它们都是抽象用例,因为它们在逻辑上都是系统中一系列功能(行为)的总称,而不是指具体的功能(行为)。另外罗列的“用户管理”、“权限管理”、“模块管理”以及“输入输出”和“数据备份”等5个用例都是系统管理的子用例,因为它们的行为在逻辑上都属于系统管理的范畴。从“权限管理”用例到“用户管理”用例以及“模块管理”用例之间各有一条带箭头的虚线,表示“权限管理”用例对这两个用例有着依赖的关系。因为权限管理功能中要判断某特定用户是否有权限使用某特定模块,所以必须从有关的用例中知道涉及到的用户和模块的信息。从“项目信息管理”等用例到“输入输出”用例和“权限管理”用例之间也有着带箭头的虚线,这表示“项目信息管理”用例对“输入输出”用例以及“权限管理”用例存在着包含式的依赖关系,或者说是功能上的依赖。这是因为“项目信息管理”的各子用例需要使用“权限管理”用例的功能来判断该用户的权限,并且还可能要通过“输入输出”用例中提供的功能写入数据库或日志系统。图三列举了4个执行者。其中标注为“数据库”和“日志系统”代表的是外部的系统,而标注为“系统用户”和“系统管理员”的代表该系统的用户。因为“系统管理员”本来就是特殊的系统用户,所以“系统用户”和“系统管理员”之间有一条泛化的连线。

用例图形象地表达了需求报告中关于系统功能的定义。它的使用,使得设计者在系统设计的最初阶段将主要精力集中在系统的功能上,而不是系统的具体实现上。

4 类图的使用———对实体间的关系的建模分析

该信息系统各种操作、业务可以把它分解为若干个类。一个系统通常需要生成几个类图。有些显示类机器关系的子集,有些显示类的子集,包括属性和操作。类之间可以建立集中关系:关联、依赖性、累积和一般化。图4是该信息系统的中的类图的一个实例,它描述的是该系统中的一个重要的组成部分,项目、任务、任务计划和任务进度之间的关系。

图4中共有项目列表、项目、任务列表、任务、计划列表、计划、进度列表和进度等8个类。其中每个类列表为保存相应的类的实例,它们和各个类之间的关系为累积的关系,在实线上还标注了“<>”构造型。表示列表类和它存储的类之间是包含的累积关系。项目类和任务类是改信息系统的主要部分,其中项目类包括“sn”、“content”、“name”、“tasks”等属性,以及“Create”、“Destroy”等操作;任务类中的属性大致与项目类中一致,唯一不同的是去掉了“tasks”,增加了“plans”和“process”两个属性。项目类对任务类之间的关系是一对多的关联关系,也就是说,一个项目中可以包括若干个任务。任务类和进度类以及计划类之间也是这样的一对多的关联。任务类中按月产生进度和计划,由操作“addProcess”和“addPlan”来完成。这些类和类之间的关系使用可视化的手段形象地表现了出来,使之容易理解,也简化了将来可能需要的修改和维护工作。UML的工具(Rational Rose)还提供了自动代码生成功能,在设计阶段结束以后可以将代码转化成相应的编程语言代码框架。

5 顺序图的使用———业务流程的时序建模

序列图描述对象之间动态的交互关系,着重体现了对象间消息传递的时间顺序,显示了它们在序列中与不同的对象间调用关系,同时可以在级别上显示不同对象间的不同调用关系。图5是信息管理系统的时序图。该时序图以管理员的身份登陆,作为管理员具有从基本数据输入到打印的权限。由图5可以看出,该案例中涉及7个对象:用户、登陆、项目、任务、任务计划、任务进度、报表生成器。管理员开始完成登陆操作,系统的权限管理模块负责用户的授权和安全操作。登陆以后可以用导航条的方式选择要进行操作的项目或者新建项目。然后对任务信息进行录入或者产生信任务。接着可以按月产生任务进度和任务计划,对任务进度和任务计划进行填写。系统可以分别对任务计划和任务进度进行统计,最后在此基础上由报表生成器生成报表工作。

6 结论

统一建模语言UML作为面向对象建模领域的事实上的工业标准,在软件系统的设计过程中有着其他现有工具不可比拟的优越性。在这次项目管理信息系统的设计过程中,它被应用在了描述系统模块结构、静态类结构和系统行为等各个方面,对以后的系统实现过程起到了很好的指导作用。通过支持UML的工具提供的自动代码生成工具,可以将用UML设计的部分成果直接转化成编程语言的代码框架,大大降低实现此编码过程中的工作量。

摘要:在介绍统一建模语言(UML)的基础上着重分析了它在一个实际的项目信息管理系统的设计过程中的应用,概述适用于项目信息管理系统的统一建模语言的建模机制、建模过程和具体内容。证明了使用统一建模语言(UML)在程序的设计过程中即清晰建立了程序的框架,也对程序代码的快速生成有很大的帮助。

关键词:统一建模语言,项目信息管理系统,建模,UML图

参考文献

[1]Rational Software Corp.Unified Modeling Language UML Semantics[Z].

[2]张龙祥.UML与系统分析设计[M].北京:人民邮电出版社,2001.

软件设计中的对象UML技术分析 篇8

摘 要:随着计算机技术的发展,软件工程技术已经进入了一个新的阶段,人们开始使用面向对象的技术,同时UML融合了多种面向对象建模方法以及多种软件工程方法,成为软件系统设计建模的主要工具,该文从软件工程和UML概念出发,以UML在软件工程的应用为基础,重点对软件工程与UML技术进行了阐述和分析。

关键词:软件工程:UML建模;架构实现

20世纪90年代中期,软件工程领域取得重要进展和成就的重要标志之一是统一建模语言UML(Unified Modeling Language)的诞生。UML作为一个通用的、标准的建模语言,融合了面向对象开发方法的主要概念和技术。UML提供了一系列标准化图形符号,所建立的模型清晰完整,便于理解;它所提供的丰富视图从多个视角描述系统的不同侧面,可以有效地运用于从需求分析到系统实现的软件建模,并有助于用户及软件开发人员间的交流和协商。UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言。它溶入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计,还支持从需求分析开始的软件开发的全过程。

1、UML在软件工程中的作用

UML的用例试图可以表示客户的需求,对外部的角色以及它们所需要的系统功能建模是通过用例建模来完成的。它们之间的关系建模被用于角色和用例。每个用例都指定了客户的需求,需求分析不仅要对软件系统进行而且对商业过程也要进行。考虑要解决的问题是分析阶段要做的工作,其描述可用UML的逻辑视图和动态视图来进行。系统的静态结构由类图进行描述,系统的动态特征由协作图、状态图、序列图、活动图和状态图进行描述。在分析阶段,不定义软件系统的解决方案的细节,只为问题领域的类建模。把分析阶段的结果扩展成技术解决方案是设计阶段主要的工作,提供技术基础结构用户接口,数据库操作等是采用加入新的类完成的。在这个技术基础结构中,分析阶段的领域问题类被嵌入在其中,构造阶段的详细的规格说明是设计阶段的结果。把设计阶段的类转换成某种面向对象程序设计语言的代码,这是构造阶段的工作。在对UML表述的分析和设计模型进行转换时,最好不要直接把模型转化成代码。在早期阶段,模型是理解系统并对系统进行结构化的手段。单元测试、集成测试、系统测试和接受测试为系统测试的几个不同级别。不同的测试采用不同的UML图作为工作的基础。使用类图和类的规格说明是单元测试,典型地使用组件图和协作图的是集成测试,而系统测试实现用例图来确认系统的行为符合这些图中的定义。在系统测试阶段,UML模型还可以作为测试阶段的依据。软件工程是从结构化程序设计到面向对象程序设计转变的一个过渡。

2、UML的系统建模步骤

2.1系统的需求分析阶段

建立系统需求模型,根据用户初始需求,在用户的参与下,写出问题陈述;定义执行者在用户的参与下定义系统的执行者,利用UML中的角色、用例、关系、注释等表达法,建立系统的用例模型;利用逻辑视图建立系统的静态、动态模型。静态模型是根据用例图建立类图,这里的类图主要关注应用域中实体的概念及结构,此类的表示只给出类名即可,这是类的简单表示。动态模型包括顺序图(协作图)、状态图、活动图,但它们的侧重点各自有所不同。顺序图描述对象之间动态行为的交互关系,着重体现对象之间消息传递的时间顺序;状态图主要描述系统的动态行为和控制结构;活动图既可以描述操作的行为,也可以描述用例和对象内部的工作过程。设计者要根据系统的实际情况来分析,建立一个或多个动态模型来描述系统的动态行为。

2.2系统的设计实现阶段

根据实际问题和建立动态模型,详细分析类,得到类在系统中的基本属性和行为,完善类框图;识别类之间的关系,即识别类结构关系,如类的扩展、组成、泛化等关系;确立类之间存在的协作关系,即类图中各个类之间的交互关系,如传递信息、修改、添加、启动等关系;创建组件并选择某种面向对象编程语言作为开发的工具,将类(或接口)分配给组件。组件可看作是包与类对应的最终子系统模块,逻辑上与包、类对应,实际上是一个文件,可以是源代码组件、二进制组件(库文件)、可执行组件(1exe或1com文件)。建立组件图,描述系统组件间的结构关系,并按对应关系进行连接;建立部署图,用来描述和定义系统中硬件的物理拓扑结构以及在此结构上执行的软件。

3、系统的详细设计分析

3.1 类图设计

类图是描述类、接口、协作以及它们之间的关系的图,用来显示系统中各个类的静态结构。一个类图根据系统中类以及各个类之间的关系描述系统的静态视图。本文以CRM 系统中的售后管理模块类为例说明类图的设计过程。售后管理模块中的类包括:服务信息、售后服务信息、服务跟踪信息、售后处理信息、售后服务图片信息、常见问题信息、产品缺陷信息、咨询信息。

3.2 顺序图设计

顺序图描述对象之间的动态交互关系,描述对象之间传递消息和时间顺序,它用来表示用例中的行为顺序。顺序图描述了类图中类和类之间的关系,时序图中包括4 个元素:对象、生命线、激活和消息。

3.3 组件配置图

组件是定义了良好接口的物理实现单元,是系统中可替换的物理部件。组件图描述了软件的各种组件和它们之间的依赖关系。配置图显示运行系统的物理硬件,以及如何将软件配置到硬件上。配置图描述了系统资源的配置情况以及软件到这些资源上的映射。

4、结束语

从上面的讨论得出的结论是:UML 是功能强大的建模工具。本文通过UML用例图、类图、顺序图、组件图、配置图建立了系统的静态模型和动态模型。UML 可视化建模使得系统的结构更容易理解,降低了系统开发的难度,提高了系统开发效率。下一步主要的工作是研究UML 模型如何精确地描述,以及UML的类图与顺序图自动转换成代码。

参考文献:

[1]唐翠娥.UML建模技术综述[J].电子世界.2013

上一篇:难忘的圣诞节600字作文下一篇:和平鸽的诉说小学作文