UML课设简易OA办公自动化系统Word格式.docx

上传人:b****3 文档编号:8180482 上传时间:2023-05-10 格式:DOCX 页数:13 大小:155.44KB
下载 相关 举报
UML课设简易OA办公自动化系统Word格式.docx_第1页
第1页 / 共13页
UML课设简易OA办公自动化系统Word格式.docx_第2页
第2页 / 共13页
UML课设简易OA办公自动化系统Word格式.docx_第3页
第3页 / 共13页
UML课设简易OA办公自动化系统Word格式.docx_第4页
第4页 / 共13页
UML课设简易OA办公自动化系统Word格式.docx_第5页
第5页 / 共13页
UML课设简易OA办公自动化系统Word格式.docx_第6页
第6页 / 共13页
UML课设简易OA办公自动化系统Word格式.docx_第7页
第7页 / 共13页
UML课设简易OA办公自动化系统Word格式.docx_第8页
第8页 / 共13页
UML课设简易OA办公自动化系统Word格式.docx_第9页
第9页 / 共13页
UML课设简易OA办公自动化系统Word格式.docx_第10页
第10页 / 共13页
UML课设简易OA办公自动化系统Word格式.docx_第11页
第11页 / 共13页
UML课设简易OA办公自动化系统Word格式.docx_第12页
第12页 / 共13页
UML课设简易OA办公自动化系统Word格式.docx_第13页
第13页 / 共13页
亲,该文档总共13页,全部预览完了,如果喜欢就下载吧!
下载资源
资源描述

UML课设简易OA办公自动化系统Word格式.docx

《UML课设简易OA办公自动化系统Word格式.docx》由会员分享,可在线阅读,更多相关《UML课设简易OA办公自动化系统Word格式.docx(13页珍藏版)》请在冰点文库上搜索。

UML课设简易OA办公自动化系统Word格式.docx

我们将开发一个适合我公司使用的OA系统,开发他的目的是为了讨论开发低成本OA系统的技术可行性。

系统基本需求:

1)用户管理:

至少有3类用户级别(一般员工、管理层和系统管理员),各类用户的权限不同,登录后的界面也有所不同:

每个用户可以管理自己的账户,管理员可以删除、增加、屏蔽、解除屏蔽一个普通用户等。

2)部门管理:

系统里各部门的基本信息管理(对普通用户不可见),管理员可以增加、删除、编辑、修改任何一个部门的信息:

可以把一个员工从一个部门里删除,把一个员工从一个部门移到另一个部门等功能。

3)车辆管理:

查看单位车辆的使用情况,申请使用某个车辆。

4)会客管理:

查看指定时刻某员工的会客记录,提醒员工未来某一时刻的会客需求。

5)会议室管理:

能查看会议室的所有使用记录,申请使用会议室。

6)费用报销

4设计内容

4.1用例图设计

用例图是开发过程的起点,并驱动建模全过程。

在设计系统用例图之前,首先要识别出系统的参与者和用例。

参与者是系统分析员与用户交流的起点,也是项目获得后续产品的关键。

通常情况下,参与者是指使用系统功能的人,但也可以是其他外部系统,包括软件系统和硬件设备。

可以通过向用户询问一些问题来识别系统参与者。

例如:

“谁使用系统主要功能?

谁改变系统数据?

”等。

根据上述对系统的描述中可知,在系统顶层上可以识别出以下9个参与者:

用户、一般员工、管理层、系统管理员、部门管理员、车辆管理员、会客管理员、会议室管理员和费用报销员。

参与者是事件的主体,系统的所有需求都源于要满足的事件以及用来满足需求的用例。

参与者根据各自的职责完成相应的动作。

本系统的系统层用例图如图4-1所示。

图4-1简易OA系统的总用例图

在用例图中,一个用例是用一个命名的椭圆表示的,但如果没有对这个用例的具体说明,那么还是不清楚该用例到底会完成什么功能。

没有描述的用例就像一本书的目录,我们只知道该目录标题,但并不知道该目录的具体内容是什么。

事实上,用例的描述才是用例的主要部分,是后续的交互图分析和类图分析必不可少的部分。

一般来说,用例采用自然语言描述参与者与系统进行交互时双方的行为,不追求形式化的语言表达。

由于本系统的用例很多,有好多相似的用例,我只对部分重要用例进行描述:

1、对管理账户用例的描述

用例名称:

管理账户

标号:

U1-2

参与者:

用户

描述:

用户管理自己账户

前置条件:

登录系统

主事件流:

(1)用户登录系统

(2)系统显示用户页面

(3)用户管理自己账户

后置条件:

用户可以管理自己的账户

2、对增加普通用户用例的描述

增加普通用户

U4-2

系统管理员

系统管理员根据用户信息增加一个普通用户

登录

(1)系统管理员登录系统

(2)系统管理员进入增加普通用户界面

(3)系统显示增加用户信息界面

(4)系统管理员填写必要的用户信息

(5)系统管理员提交,普通用户被添加

普通用户被添加

3、对删除部门信息用例的描述

删除部门信息

U5-2

部门管理员

部门管理员删除部门信息

登录,查看部门信息

(1)部门管理员登录系统,并查看部门信息

(2)系统显示部门信息

(3)部门管理员删除信息

(4)部门管理员保存,部门信息被删除

其他事件流:

A1、部门管理员没有保存之前,都可以返回,部门信息没有被删除

部门信息被删除

4、对移出员工用例的描述

移出员工

U5-6

部门管理员移出员工,并删除该员工信息

登录,查看员工信息

(1)部门管理员登录系统,并查看员工信息

(2)系统显示员工信息

(3)部门管理员选定要移出员工信息,并删除

(4)部门管理员保存,移出员工信息从本部门删除

移出员工的信息从本部门删除

5、对查看会议室使用记录用例的描述

查看会议室使用记录

U6-1

会议室管理员

会议室管理员查看会议室的使用情况

(1)会议室管理员登录系统,并查看会议室的使用情况

(2)系统显示会客室的使用记录

会客室管理员可以根据会议室的使用情况,来做其他操作

6、对提醒员工会客需求用例的描述

提醒员工会客需求

U7-2

会客管理员

有客人时,会客管理员提示员工会客需求

登录,查看客人需求

(1)会客管理员登录系统,并查看客人信息

(2)系统显示客人信息

(3)会客管理员根据信息查看客人需求

(4)系统显示客人需求

(5)会客管理员把会客需求发个员工

(6)系统提醒员工查看会客需求

员工根据客人需求来接待客人

7、对报销费用用例的描述

报销费用

U8-2

费用报销员

可以根据一些凭据来报销费用

登录,查看报销范围

(1)报销管理员登录系统,进入报销界面

(2)员工把报销凭据交给报销管理员

(3)报销管理员查看报销范围

(4)系统显示报销范围

(5)报销管理员比对报销凭据是否有效

(6)报销管理员报计算销费金额,并给员工

(7)报销管理员向系统添加一条报销记录

(8)系统返回添加记录成功

A1、报销凭据无效,报销管理员不给予报销

报销管理员报销费用,并向系统添加一条新纪录

8、对申请使用车辆用例的描述

申请使用车辆

U9-2

车辆管理员

向车辆管理员申请使用车辆

登录,查看车辆使用情况

(1)车辆管理员登录系统

(2)员工向车辆管理员申请使用车辆

(3)车辆管理员查看车辆使用信息

(4)系统显示车辆信息

(5)车辆管理员根据车辆使用记录给员工分配车辆,并向系统添加一条记录

(6)系统显示添加成功

员工申请成功,系统增加一条新纪录

4.2类图设计

类图是显示了模型的静态结构,特别是模型中存在的类、类的内部结构以及它们与其它类的关系等。

类图不显示暂时性信息。

类图由许多(静态)说明性的模型元素(例如类、包和它们之间的关系,这些元素和它们的内容互相连接)组成。

类图可以组织在(并且属于)包中,显示特定包中的相关内容。

类图用于描述系统的结构化设计。

要建立类图,不仅要识别出类,还要识别出类与类之间的关系。

显示的关系可以从用例中找到,而隐式的关系在用例中没有明确的说明,这就需要项目分析员去细心发现。

在本系统中相关的类较多,其中员工类有员工号、员工名、职称、部门、电话等重要属性。

本系统中还涉及到的类有:

部门类、会议室类、会议室使用记录、客户类、客户需求类、报销凭据类、费用报销记录类、车辆类、车辆使用记录类、登录类、账户类等等。

在这里不给出每个类的属性,在类图的设计中会给出类的主要属性,绘制的类图如图4-2所示。

图4-2简易OA系统的详细的类图

4.3顺序图设计

顺序图也称时序图。

Rumbaugh对顺序图的定义是:

顺序图是显示对象之间交互的图,这些对象是按时间顺序排序的。

特别地,顺序图中显示的是参与交互图中的对象及对象之间消息交互的顺序。

图4-3是用户登录的顺序图设计,登录的参与者是用户,用户进入登录界面以后,输入正确的用户账户名和口令,即可登录到系统中。

登录的过程具体可细化为:

(1)用户启动系统

(2)系统显示“登录”窗口

(3)用户输入账户名和口令,执行“登录”操作

(4)系统检查账户名在系统中是否注册,以及键入的密码与用户账户名是否符合。

若正确,进入系统主窗口

图4-3用户登录系统的顺序图

如图4-4是报销管理员费用报销的顺序图,报销的参与者是报销管理员。

如果员工有报销费用的需求,报销管理员根据报销凭据来进行报销,费用报销的过程可细化为:

(1)报销管理员进入报销界面

(2)员工提交报销凭据

(3)报销管理员根据报销范围来验证报销凭据是否有效

(4)如果有效,报销管理员计算报销金额给员工

(5)报销管理员向系统添加一条新的费用报销记录

(6)系统显示添加结果

图4-4报销管理员费用报销的顺序图

4.4协作图设计

协作图强调发送和接受消息的对象之间的结构组织的交互图,显示对象、对象之间的链接以及对象之间的消息,还可以显示当前模型中的简单类实例和类实体实例。

协作图是用于描述系统的行为是如何由系统的成分协作实现的图,协作图中包括的建模元素有对象、消息、链等。

如图4-5是用户登录的协作图。

图4-5用户登录的协作图

4.5活动图设计

活动表示的是某流程中的任务的执行,它可以表示某算法工程中的语句的执行。

在活动图中需要注意区分动作状态和活动状态这两个概念。

活动状态是原子的,不能被分解,没有内部转移,没有内部活动,动作状态的工作所占用的时间是可以忽略的。

动作状态的目的是执行进入动作,然后转向另一个状态。

活动状态是可分解的,不是原子的,其工作的完成需要一定的时间。

可以把动作状态看作活动状态的特例。

活动图对表示并发行为很有用,其应用非常广泛。

一般活动图可以对系统的工作流程建模,即对系统的业务过程建模,也可以对具体的操作建模,用于描述计算过程的细节。

在结构化分析和设计中,开发人员往往用流程图来描述一个算法。

在UML中你没有流程图的概念,从某种意义上说,活动图的功能已包含了流程图。

图4-6是对系统管理员的活动进行分析而得到的活动图。

图4-6系统管理员的活动图

在进行用例分析是,可以用活动图来描述具体的工作流程。

由于这个工作流程涉及两个用例,所以采用脚本或是顺序图很难描述,而采用活动图则可以很好地解决这个问题。

图4-7则是对报销管理员的进行分析得到的活动图则对这个工作流程的具体描述的一个例子。

图4-7报销管理员的活动图

4.6状态图设计

状态图和活动图对系统的动态行为建模,两者很相似,但也有区别。

状态图描述的是对象的状态及状态之间的转移。

图4-8则是会议室的状态图。

图4-8会议室的状态图

5总结与展望

通过此次课程设计,将我本学期所学的《面向对象分析技术UML教程》知识得到巩固和应用,在设计的过程中我遇到了很到问题,不过在老师和同学们的帮助和自己的思考下还是很好的完成了。

这此课程设计还让我懂得了写程序不能闭门造车,要努力拓宽知识面,开阔视野,拓展思维。

它还让我学会了在网上查阅那些无限的资源。

参考文献

[1]王少峰编著.面向对象技术UML教程.北京:

清华大学出版社

[2]范晓平编著.UML建模实例详解[M].北京:

[3]XX:

[4]XX文库:

成绩评定

成绩教师签字

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 党团工作 > 入党转正申请

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2