UML系统设计学生信息管理系统文档格式.doc

上传人:wj 文档编号:3959567 上传时间:2023-05-02 格式:DOC 页数:22 大小:199KB
下载 相关 举报
UML系统设计学生信息管理系统文档格式.doc_第1页
第1页 / 共22页
UML系统设计学生信息管理系统文档格式.doc_第2页
第2页 / 共22页
UML系统设计学生信息管理系统文档格式.doc_第3页
第3页 / 共22页
UML系统设计学生信息管理系统文档格式.doc_第4页
第4页 / 共22页
UML系统设计学生信息管理系统文档格式.doc_第5页
第5页 / 共22页
UML系统设计学生信息管理系统文档格式.doc_第6页
第6页 / 共22页
UML系统设计学生信息管理系统文档格式.doc_第7页
第7页 / 共22页
UML系统设计学生信息管理系统文档格式.doc_第8页
第8页 / 共22页
UML系统设计学生信息管理系统文档格式.doc_第9页
第9页 / 共22页
UML系统设计学生信息管理系统文档格式.doc_第10页
第10页 / 共22页
UML系统设计学生信息管理系统文档格式.doc_第11页
第11页 / 共22页
UML系统设计学生信息管理系统文档格式.doc_第12页
第12页 / 共22页
UML系统设计学生信息管理系统文档格式.doc_第13页
第13页 / 共22页
UML系统设计学生信息管理系统文档格式.doc_第14页
第14页 / 共22页
UML系统设计学生信息管理系统文档格式.doc_第15页
第15页 / 共22页
UML系统设计学生信息管理系统文档格式.doc_第16页
第16页 / 共22页
UML系统设计学生信息管理系统文档格式.doc_第17页
第17页 / 共22页
UML系统设计学生信息管理系统文档格式.doc_第18页
第18页 / 共22页
UML系统设计学生信息管理系统文档格式.doc_第19页
第19页 / 共22页
UML系统设计学生信息管理系统文档格式.doc_第20页
第20页 / 共22页
亲,该文档总共22页,到这儿已超出免费预览范围,如果喜欢就下载吧!
下载资源
资源描述

UML系统设计学生信息管理系统文档格式.doc

《UML系统设计学生信息管理系统文档格式.doc》由会员分享,可在线阅读,更多相关《UML系统设计学生信息管理系统文档格式.doc(22页珍藏版)》请在冰点文库上搜索。

UML系统设计学生信息管理系统文档格式.doc

学生管理工作是一个系统工程,贯穿于学生在校学习期间的整个过程。

本课程设计从我校学生管理工作实际需求出发,设计了一个高校学生信息管理系统,该系统包含了五大功能模块:

学籍管理模块、成绩管理模块、奖惩管理模块、党员、干部管理模块、毕业管理模块。

本系统采用统一建模语言UML、建模工具StarUML进行系统建模。

提出了适合高校学生信息管理系统软件的建模过程,建立了包括用例图、类图、顺序图、状态图和活动图、部署图的系统静态结构模型、动态行为模型,进行了数据库概念设计和关键表单的设计。

本课程设计的高校学生信息管理系统是采用UML技术,以网络为服务平台,使分析和设计变得直观、清晰,降低了系统的开发风险,有效地控制整个系统的开发过程,维护系统的完整性,本系统将能高效、规范地管理大量纷繁复杂的学生信息,与其它管理部门的信息系统紧密结合,轻松、条理、准确的完成学生从入学到就业的整个管理工作,有效地减轻学生工作管理人员的工作负担,提高工作效率。

1.2本文的主要内容及结构

本文主要有五个部分:

第一部分是引言,简要介绍了学生信息管理系统的研究背景,基于UML建模的意义。

第二部分主要对统一建模语言(UML)做了一个较为全面的概述.

第三部分讲述了学生信息管理系统的系统需求及UML在系统需求分析中的应用。

第四部分详细分析了学生信息管理系统的静态建模、动态建模的过程,借助StarUML工具绘制了用例图、类图、顺序图、状态图、活动图。

第五部分是学生信息管理系统的设计、主要包括数据库设计。

2.基于UML的系统建模

模型是现实系统的简化。

建模是对现实系统进行适当过滤,用适当的表现规则描绘

出简洁的模型。

通过模型,人们可以了解所研究事物的本质,从而在形式上便于人们的分析.

和处理。

系统建模主要由建模语言、建模过程及建模工具3要素组成。

本章主要介绍基于UML

的系统建模第一个个要素:

建模语言UML。

2.1统一建模语言UML

UML图组成

UML用图形符号描述模型,UML中包括9种图,分别是用例图、类图、对象图、顺

序图、协作图、状态图、活动图、构件图和部署图。

(l)用例图,用于描述一组用例、参与者及它们之间的连接关系。

一个用例描述了一组动作序列,每一个序列表示系统的外部设施与系统本身的交互。

(2)类图,用于描述一组类、接口、协作以及它们之间的静态关系。

在面向对象系统的建模中,类图是最为常用的图,它用来阐明系统的静态结构。

(3)对象图,对象图是类图的一个实例,用来描述特定运行时刻一组

对象之间的关系,使用的符号与类图几乎一样。

对象图和类图两者之间的区别是:

对象图用

于显示类的多个对象实例,而不是实际的类。

(4)顺序图,用来描述对象消息发送的先后次序,阐明对象之间

的交互过程以及在系统执行过程中的某一具体将会发生什么事件。

(5)协作图,和序列图一样,协作图也表达对象间的交互过

程,强调收发消息的对象的组织结构,显示多个对象及它们之间的关系,主要用来对单调的、

顺序的控制流建模。

协作图和序列图合称为交互图。

在实际建模时,选择使用顺序图还是协

作图通常由工作的主要目标来决定。

如果时间或顺序是需要重点强调的方面,那么选择顺序

图,如果上下文是需要重点强调的方面,那么选择协作图。

(6)状态图,状态图实际上是一种由状态、变迁、事件和活动组成的

图,状态图描述类的对象的所有可能的状态以及事件发生时状态的转移条件。

通常,状态图

是对类图的补充。

在UML中,状态图可用来对一个对象按事件排序的行为建模。

(7)活动图,活动图本质上是一种流程图,用于显示一系列顺序的

活动。

它描述从活动到活动的控制流,描述满足用例要求所要进行的活动以及活动间的约束

关系。

(8)构件图,.构件图描述代码部件的物理结构及各部件之间的

依赖关系。

一个部件可能是一个资源代码部件、一个二进制部件或一个可执行部件。

构件图

中也可以包括包或子系统,它们者用于将模型元素组织成较大的组块。

(9)部署图。

部署图定义系统中软硬件的物理体系结构。

它可以

显示实际的计算机和设备(用节点表示)以及它们之间的连接关系,也可显示连接的类型及

部件之间的依赖性。

从应用的角度看,统一建模语言UML的主要内容也可以归纳为静态建模机制和动态建

模机制两大类,因此UML图也分为静态图和动态图。

其中,静态图包括用例图、类图、对

象图、构件图和配置图,动态图包括状态图、顺序图、协作图、活动图,在UML的九种图

中,类图、顺序图和状态图是UML的核心子集。

3.学生信息管理系统需求分析

3.1系统需求分析

3.1.1业务流程分析

通过对计算机科学与信息学院学生信息管理工作的调查与分析,主要存在学籍管理、成绩管理、奖惩管理、学生党员干部管理、毕业管理等业务环节,对应的管理部门有教务处、学生处、招生就业处、教学系部等部门。

主要业务流程分析如下:

(1)学籍管理

学籍管理是对取得学习资格的学生,从入学注册,成绩考核与记载,升、留级、转专业与转学、休学、停学、复学、退学,奖励与处分,毕业等方面,实施管理。

我院的工作流程是新生首先到系上报到,教务处注册,填写学生的基本信息情况表,由系学生工作人员进行信息录入,当所有信息录入完毕并汇总在学生档案中,就完成了新生登记工作。

(2)成绩管理

每学期期末由教师将学生期末成绩单交到各系上,由系秘书以班级为单位将各门课程的

成绩进行录入、核对,打印成绩单后交教务处统一处理。

此时学生可查询成绩,但是若某个

学生的成绩出现错误而需要修改,则需要按特定的流程进行。

首先由任课教师将修改理由上

交教务处,然后由教务处登记修改内容及时间后,方可修改成绩,成绩管理为学生奖惩管理

提供依据。

(3)奖惩管理

主要有奖学金评定、评优和违纪处分三类业务。

奖学金评定的流程是班主任将学生综合

成绩进行汇总(各科成绩的平均分x70%+操行成绩x30%),再根据学生处制定的奖学金评

定标准对每班学生评出奖学金等级,结果进行公示,无异议后送交学生处进行评审;

评优过

程则是首先由参加评优的个人或者集体提交评优申请,由所属部门出具推荐意见,学院接收

到申请材料和推荐材料后根据评定条件、额度等择优提出初评名单,经过评定部门审核后予

以确认:

学生违纪处分的基本流程则是各系将学生违纪情况上报学生处,学生处根据相关规

定进行处理,通知学生本人。

奖惩管理工作中奖励结果一开始就需要公示,对奖学金或评优

结果有异议可以向所属部门进行反映,然后进行复查。

(4)学生党员、干部管理

在高校学生党员培养发展的一般流程为首先由学生递交入党申请书,党支部初步确定培养发展对象,择优送入业余党校学习,然后经系党支部考察、上级党组织审核后确定预备党员,经过一年的预备期后,由系党支部讨论,上级党组织审核转为正式党员。

学生干部的培养流程则是学生首先提交申请,学生会工作人会根据学生在校期间的表现决定候选人,由学生和学生工作管理人员投票决定学生干部的任命,然后根据学生干部的学习工作情况进行考核,确认学生干部。

当学生党员出现转学、退学等情况时,该名学生的组织关系的调转,或者某名学生干部没有连任而被其他同学代替时则学生干部信息发生相应变化。

(5)毕业管理

由教务处提供学生学籍基本信息、综合成绩信息和学生处提供的学生奖惩情况来鉴定

学生能否毕业,另外招生就业处进行学生就业信息进行统计和分析。

上述流程分析可见学生信息管理工作从入学到毕业,管理周期长,管理部门分散,我院

现行的传统管理模式需要耗费大量的人力、物力和时间,容易出现材料不齐全、信息不一致

的情况,手工操作效率低,重复劳动多,工作量大,准确性低,出错率高,难以保证现代教

育管理方式的需要。

如贫困生管理工作手续比较复杂、繁琐,我院学生助学贷款办理与管理

却处于手工操作,信息沟通及其不便,在贷款信息统计、分析、上报等方面都存在很大的难

度,学生离校后,还无法获取学生最新信息,还款工作无法得到很好的监管等。

3.1.2功能模块分析

根据我院的学生管理工作的具体要求和项目设计的功能目标,学生信息管理系统有五大

功能模块:

学籍管理模块、成绩管理模块、奖惩管理模块、党员、干部管

理模块、毕业管理模块。

(1)学籍管理模块主要进行学生注册报到的登记、统计及查询,学生基木档案信息的维

护、查询、和打印,学籍变动处理。

(2)成绩管理模块主要进行的成绩录入、修改、查询以及成绩分析统计。

(3)奖惩管理模块主要可进行奖惩申请、评审等工作,对奖惩信息进行统计分析和查询。

(4)党员、干部管理模块有党员信息管理和干部信息管理两个模块,党员管理模块主要

记录入党申请递交情况、发展过程记载、党员信息查询。

干部模块完成对学生干部的任免、

考核记录及干部名单查询等功能。

(5)毕业管理模块主要是毕业鉴定管理和就业信息管理。

包括对学生的毕业资格审定、

毕业后工作情况登记,生成学生就业情况分析和就业信息查询等功能。

3.1.3问题域分析

角色识别

角色是与所建系统交互的人与物,角色描述系统范围外的一切。

角色分析的目的是抽象

出系统不同的参与者,找出系统最终服务对象的服务方式。

经分析,学生信息管理系统的角色有:

学生、教师、系秘书、教务管理人员、系学生工

作人员、学生处管理人员、招生就业工作人员、系统管理员。

学生:

可提出相关事项的申请,查询相关信息。

教师:

可进行相关信息查询,如在规定的时间内可提出修改成绩请求。

系秘书:

主要根据教师上交的各科成绩进行录入、核对和打印成绩单,呈交教务管理人

员审查。

系学生工作人员:

主要录入学生基本信息并根据学生提出的申请给出相应的初步意见,

交相关部门管理人员审核。

教务管理人员:

对学生基本档案进行维护、查询、统计、打印,对学籍变动进行审核处

理,对成绩信息进行审核、修改、查询。

学生处管理人员:

根据系学生工作人员意见进行审核,给出审核意见。

招生就业处管理员:

学生就业情况录入、修改、查询,进行学生就业情况分析统计。

系统管理员:

设定系统定义的基础参数或开关,设置各操作员使用系统的权限,备份系

统数据库,恢复系统数据库,系统安全维护。

3.2系统用例分析

用例是系统提供的功能块。

换句话说,用例演示了人们如何使用系统。

通过用例观察系

统,能够将系统实现与系统目标分开,有助于了解最重要的部分,满足用户的要求和期望。

通过用例,客户可以看到系统提供的功能。

用例具有以下的特征:

(l)用例总由角色初始化。

用例所代表的功能必须由角色激活,而后才能执行。

(2)用例为角色提供值。

用例必须为角色撰供实在的值,虽然这个值不总是重要的,

但是能被角色识别。

(3)用例具有完全性。

用例是一个完整的描述,虽然编程实现时一个用例可以被分解为多个小用例,每个小用例之间相互调用执行,一个小用例可以先执行完毕,但是该小用例执行结束并不能说这个用例结束,也就是说,不管用例内部的小用例是如何工作通信的,只有最终产生了返回给角色的最终值,才能说用例执行完毕。

从用例的特征看出,建立用例模型的目的就是抽象出系统提供给使用者的各种功能。

系统需求初始阶段,建立系统高层用例图是必要的。

学生信息管理系统有以下几类用例:

录入信息、修改信息、查询信息、分析统计、打印

信息、申请项目、审核项目、审批项目、管理权限、维护系统。

这些用例构成了该系统的功能需求。

图3-1显示了基于这些信息的高层用例图。

图3-1学生信息系统高层用例图

4.基于UML的学生信息管理系统建模

4.1静态结构模型

系统需求建模后,我们将开始面向对象系统分析,其任务是运用面向对象方法,对问题

域和系统结构进行分析和理解,找出描述问题域以及系统结构所需的类和对象,定义这些对

象的属性和操作,以及它们之间的静态和动态关系,最终产生一个用户需要的分析模型和详

细说明。

而分析模型和用例模型最大的不同就是分析模型使用开发人员的语言进行描述,并

且反映系统的内部视图。

具体来说,建立系统静态结构模型阶段的活动主要是:

发现对象,为对象分类,确定类

的属性和操作,确定类之间的关系,系统的静态结构模型主要用类图和对象图来描述。

4.1.1用例图

描绘出顶层的用例图之后,对系统的整体要求和目标有了一个轮廓,此时的用例是比较

粗糙的。

本文采用了自顶向下的方法细化用例,先勾勒出系统服务的抽象模型,然后细化得

出其细节。

具体步骤如下:

(l)从用户需求阶段获取的所有用例中选择一个用例。

(2)场景分析:

根据参与者的目标确定顺利完成目标的基本交互序列,即先确定用例的主要场景,然后考虑其异常情况和其他可选项,确定次要场景。

当得到用例的所有场景后,转入下一步。

(3)用例分解:

用例是场景的集合,场景中的每一步都可以看成一个小的子用例。

(4)用例判定:

把上面获取的子用例进行分析,如果可以归为参与者的一次简单行为

就可以作为一个精细化用例。

遵循上面的步骤,完成了用例细化工作,这里给出部分用例图。

学籍管理子用例

学籍管理子用例如图4-1所示,包括教务管理人员进行注册管理、基本档案管理和学籍变动管理,具体包括注册报到的登记、统计、查询和打印,基本档案的修改、杳询和打印,

学籍变动的审批、登记、查询和打印。

系学生工作人员录入和查询学生基本档案信息,对学

生提出学籍变动申请给出初步审核意见,学生可提出学籍变动的申请和查询相关信息。

图4-1学籍管理子用例图

成绩管理子用例

成绩管理子用例如图4-2所示,包括系部秘书可进行成绩录入、成绩查询、成绩统计分析、成绩打印,任课教师可进行成绩查询、成级打印、成绩统计分析,教务管理人员可进行成绩修改、成绩查询、成绩分析统计、成绩打印;

学生可进行成绩查询。

图4-2成绩管理子用例图

勤工助学管理子用例

勤工助学管理子用例如图4-3所示,包括学生处工作人员公布勤工助学信息,审批勤工助学名单,进行岗位管理,学生申请勤工助学岗位,查询勤工助学信息相关信息,系学生

工作人员审核学生是否满足勤工助学资格,管理酬金。

图4-3勤工助学管理子用例图

系统管理子用例

系统管理子用例如图4所示,系统管理员进行权限管理、系统管理和口令管理,具体

包括授予权限、收回权限、添加用户、删除用户、数据备份、数据更新、数据恢复。

图4-4系统管理子用例图

4.1.2类图

在用例图的基础上,可以根据用例图来识别类。

如果某个输入可以作为与之关联的角色的属性存在,那么就可以不必转换为类,否则就

可以考虑识别为类。

对于用例输出的情况,情况要复杂些。

我们需要确定该输出的责任实体,

如果该实体本身可以包容这个输出,那就无需将输出作为实体,否则将其识别为实体,进而

将它们识别为类。

在面向对象软件工程方法中,将类分为三种:

实体类、边界类和控制类。

1.2.1实体类

实体类用于描述必须存储的信息,同时描述相关的行为。

它们通常是持久的,并能在

一个延续的时期内存在。

它们的主要目的是表示和管理系统内的信息。

实体类通常表示为

一种逻辑的数据结构。

本节以成绩管理子系统为例进行建模,其余类似。

成绩管理子系统实体类,如表4-1所示:

实体类名称称

实体类属性

学生

学号、姓名、性别、班级、系别、专业

教职工

职工号、姓名、性别、出生年月、职务、部门

课程基本信息

课程号、课程名、课程性质、学分

成绩基本信息

学号、课程号、学期代码、任课教师、

平时成绩、期末成绩、总评成绩、补考成绩、重修成绩

用户登录

用户名、密码、权限、终止日期

表4-1实体类

从教职工实体类中可以派生出系统实际需要的实体类,其类图如图4-5所示:

图4-5父类和子类图

4.2动态行为模型

系统的动态行为模型由交互图、状态图和活动图表达。

在系统的分析和设计中应当对主

要的用例和对象类绘制这些图形,以便分析系统的行为,印证和修改系统的静态结构,满足

用户的需求,达到系统的目标。

本节用顺序图描述了用例的主要场景,用活动图描述了对象

的过程。

4.2.1顺序图

在UML中,顺序图是一种交互关系,强调交互发生的时间顺序。

它由活动者(actor)、

对象、消息、生命线和控制焦点组成。

用垂直虚线来表示生命线,水平方向上用一个带有垂直虚线的矩形框表示不同的对象,对象

间的通信通过对象的生命线间的消息来表示。

消息的箭头指明消息的类型。

下面是系统的部

分顺序图。

系秘书录入成绩顺序图如图4一所示:

首先系秘书登陆系统进行身份验证,通过验证后

进入相应的成绩录入窗口,这时可进行成绩的录入、修改和删除操作,确定无误后提交录入

信息,成绩信息写入数据库,最后退出成绩录入系统。

图4-6录入成绩顺序图

4.2.2状态图

状态图用来描述一个特定对象、子系统或者整个系统在其生命周期内的所有可能的状态

及其引起状态转移的事件,是对类图的一种补充。

状态是一种存在状况,它通常具有一定的

时间稳定性,所有对象都具有状态,状态是对象执行了一系列活动的结果。

状态图中定义的

状态有:

初态、终态、中间状态、复合状态。

其中,初态是状态图的起始点,而终态则是状

态图的终点。

一个状态图只能有一个初态,而终态则可以有多个。

在建模时,没有必要对所有的对象描述状态变化,只需要将有多个状态且行为受外界环

境的影响并且发生改变的对象画出状态图,以指导系统的具体实现。

(1)查询子状态图

在请求查询状态时,输入合理的查询条件,进入进行查询状态,进行查找后,进入返回查询结果状态,若再次查询,又回到请求查询状态;

输入不合理的查询条件,回到请求状态,

如图4-7所示:

图4-7查询子状态图

(2)用户登录子状态图

系统首先处于等待用户输入账号和密码状态,当用户将输入的数据传送到系统后进入检

测用户信息状态,当用户输入合法将进入对应的用户界面,输入不合法,则进入检查输入次

数状态,若输入次数小于三次可返回到输入账号和密码状态,否则结束登录,如图4-8所示:

图4-8用户登录子状态图

4.2.3活动图

活动图的核心是活动状态,它表示工作流过程中命令的执行或活动的进行。

与等待发生

的一般等待状态不同,活动状态用于等待计算处理工作的完成。

当活动完成后,执行流程转

入到活动图中的下一个活动状态。

用活动图为工作流建模时,一般应遵循以下步骤:

(1)识别该工作流的目标;

(2)利用一个开始状态和一个终止状态分别描述该工作流的前置状态和后置状态;

(3)定义和识别出实现该工作流的目标所需的所有活动和状态,并按逻辑顺序放置在活

动图中;

(4)定义并画出活动图创建或修改的所有对象,并用对象流将这些对象和活动连接起来;

(5)用变迁将活动图上的所有元素连接起来;

(6)在需要将某个工作流划分为可选流的地方连接起来;

(7)查看活动图是否有并行的工作流。

若有,用同步表示分岔和汇合。

学生查询成绩的活动图:

学生进入系统后,根据系统提示输入用户名和密码,系统检查输入信息是否正确,若

不正确,要求用户重新输入用户名和密码,若正确,系统要求学生选择查询类型,学生选择

查询类型,输入关键字,系统进行查询,显示查询结果,询问学生是否继续查询,若不查询,

退出查询系统,若再次查询就让学生继续选择查询类型。

图4-9查询成绩活动图

5.数据库设计

数据库是按照数据结构来组织、存储和管理数据的仓库,是用于查询的大量数据的存

储区域。

使用数据库可以带来许多好处:

如减少了数据的冗余度,从而大大地节省了数据的

存储空间,实现数据资源的充分共享等等。

此外,数据库技术还为用户提供了非常简便的使

用手段,使用户易于编写有关数据库应用程序。

特别是近年来推出的计算机关系数据库管理

系统,操作直观,使用灵活,编程方便,功能强大,环境适应广泛,数据处理能力极强。

5.1数据库设计过程

数据库是数据库应用程序的中重要组成部分。

设计结构合理、功能齐全的数据库有助于

提高数据库应用程序的性能。

数据库的设计过程如下:

(l)根据用户需求,确定数据库要保存的数据信息。

对用户需求进行分析是数据设计的

第一个阶段,不断地调查与研究用户需求,了解相关业务运作流程和系统需求,是设计概念

模型的基础。

(2)设计数据的概念模型。

概念模型是按用户的观点来对数据建模,概念模型是用于进

行信息世界建模的工具。

(3)逻辑结构设计,逻辑结构是把概念结构转化为数据库管理系统所支持的数据模型的

过程。

1.1系统数据库设计原则

在设计数据库系统时,应当重点考虑以下几个因素:

(1)数据库必须层次分明,布局合理。

(2)数据库必须高度结构化,保证数据的结构化,规范化和标准化,这是建立数据库

和进行信息交换的基础。

数据结构的设计应该遵循国家标准和行业标准,尤其要重视编码的

应用。

(3)在设计数据库的时候,一方面要尽可能地减小冗余度,减小存储空间的占用,降

低数据一致性问题发生的可能性,另一方面,还要考虑适当的冗余,

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

当前位置:首页 > PPT模板 > 商务科技

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

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