实验报告☑ 实践报告□
课程名称: 系统分析与设计
实验、实践名称: 学习成绩管理系统
实验、实践地点: 行勉楼C1
专业班级: 软件工程1803 学号: 2018005669
学生姓名: 李 敏
指导教师: 孟东霞
2020 年 10 月 31 日
一、实验目的
通过《系统分析与设计》实验,使学生在实际的案例中完成系统分析、设计的主要步骤,在实践中熟悉信息系统分析与设计的规范及信息系统开发的相关应用软件;加深对信息系统分析与设计课程的基础理论、基本知识的理解;树立正确的分析设计思想,提高系统分析、设计的实践能力及撰写书面文件的能力。
二、实验要求
要求学生以个人为单位自选题目,班内选题不重复;对所选项目进行调查,写出300字以上的系统描述;利用系统分析与设计的基本原理、方法进行系统分析、设计,使用UML语言构建该系统的分析、设计模型,并完成实验报告;实验报告以纸质版(A4)形式在课程结束后提交。
三、实验主要设备:笔记本计算机
四、实验内容
1 选题及项目背景
选题:学习成绩管理系统
项目背景:此次系统开发的对象是某高校。二十一世纪以来,管理信息系统是进行信息的采集,存储,加工,维护和使用的系统,它是随着管理科学和技术科学的发展而形成的,学生成绩管理系统是一个教育单位不可缺少的部分,它的内容对于学校的决策者和管理者来说都至关重要,学生成绩管理系统能够为用户提供充足的信息和快捷的查询手段,对学生来说可以轻松的查询自己在校的成绩以及信息等,但是一直以来学校都是靠传统人工的方式来管理学生成绩,这种管理方式存在着缺点,如:效率低,保密性差,另外时间一长,将产生大量的文件和数据,这对于查找,更新和维护带来了许多困难。
2 定义
能够极大地提高学生成绩查询的效率,从而更加有利于学生的管理和提高学生的主动性。
3 参考资料
《系统分析与设计》课本,百度
4 系统分析与设计
4.1需求分析
4.1.1识别参与者
学生、教师、系统管理员
4.1.2 对需求进行捕获与描述
在信息系统的开发生命周期中,系统分析师系统中最为重要的、也是最为困难的阶段。通过这一阶段所分析出的结果,不仅能够为接下来的开发工作提供一定的依据,同时也是衡量该系统优劣的一个重要依据。系统分析阶段的基本任务是,充分了解用户的需求,并将双方需求表达明确,为后续工作做好充分的准备工作。
系统需求分析:(1)系统应当功能分明,便于操作,能够较之前相比明显的减少工作量与人员数量,并做到使用户能较方便的进行数据处理。
(2)系统应保证稳定的安全性,确保数据和信息不会泄露。用户进入系统需有登录功能等安全机制,登录用户包括教务管理员、系统管理员、教师、学生,并保证多人使用不影响系统功能。
(3)系统必须设置好对用户的使用权限,防止错误不良现象发生。
(4)系统的数据应当具有准确性、安全性,并能完成数据共享等相应的需求。
用户需求分析:成绩系统的用户包括管理员、教务管理员、教师、学生。
在用户需求调查中,我结合自己的目标,参考了网上的文献资料,并咨询学校同学,将调查到的成绩管理工作流程按顺序排列如下:(1)系统管理员将用户,即学生、教师的基本信息录入到系统中,保证正确无误。
(2)系统管理员对教师、学生分别设置相应的权限,使得系统分工明确。
(3)各学院在学期期末成绩批阅完毕时,应有相应授课老师录入成绩,教师、学生都可以查看录入后的成绩。
功能需求分析:系统根据学校实际情况,划分出相应用户,并对其功能进行分析。
系统管理员:可对其他用户信息进行添加、修改等操作,并对其进行权限管理。
教师:即任课老师,负责成绩录入,并可进行成绩查询。
学生:可对本人成绩进行查询。
用例名称:成绩录入 执行者:教师
用例名称:成绩查询 执行者:学生
用例名称:修改成绩 执行者:教师
用例名称:数据管理 执行者:系统管理员
100.1 | 用例ID号及用例名 | Uc_100 成绩录入 |
100.2 | 用例概述 | 该用例描述一个学习成绩管理系统中,教师将学生们的成绩录入到系统中,并发布下去,可随时查询,在成绩录入错误的情况下,可以将其修改。 |
100.3 | 参与者: | 教师 |
101.4 | 前置条件(Pre-Conditions) | 教师登录 |
100.5 | 后置条件(Post-Conditions) | 教师将学生成绩录入系统。 |
100.6 | 事件流 | |
100.6.1 | 基本事件流 (Basic Flow) | 1)教师登录系统。 2)进入教师界面,进入该教师的学生班级界面。 3)教师将学生成绩录入。 4)录入成功 5)学生验证成绩。E-1 |
100.6.2 | 扩展事件流(Alternative Flows) | E-1(替代第5步): 如果学生成绩需要修改,经过老师验证,老师修改、保存。 |
4.1.3 用例图
通过已掌握的需求,初步了解系统所要完成的功能。下面给出用例图。
4.1.4 分析与讨论
1)建模用例图的步骤、方法?
1.确定系统的边界和范围:系统边界定义系统的界限
2.确定参与者:当系统边界确定之后,就要确定和系统直接交互的参与者,识别参与者对下一步识别用例是非常有帮助的。
3.发现用例:用例的来源是参与者对系统的期望,所以识别用例最好的方法是从用户的需求入手。
4.4.描述用例及确定用例关系:描述用例,说明其事件流;确定用例关系。
5.建立用例图、层次化用例图:对于一个复杂的大型系统,可以将系统分解为若干子系统。子系统还可以划分下属子系统,形成一个系统层次结构。
2)如何识别系统的参与者?应该如何划分用例,应注意哪些问题?
参与者是与系统交互的实体,包括需要和系统交换信息的一切实体。参与者不是系统的一部分,他们处于系统的外部。参与者可能是人、计算机硬件或设备或外部系统。
首先,按照需求将软件功能进行划分,然后据此按每个功能或者相关功能,采用等价类划分、边界值等方法来设计用例。其中要注意有些功能模块并不是孤立的,而是彼此相关的,对于交叉功能,都从各自功能出发设计用例,而相互交叉影响的部分丝毫没有用例涉及。
3)心得
在画用例图的时候,仔细把书上关于用例图的部分都看了一遍,但是在画图的时候还是不太确定用例和用例之间该用哪种关系描述。经过思考和参考其他资料里作者的思路,最终确定了以上的用例图。
4.2 建立对象模型
4.2.1 候选类的数据字典
学生填写
学生 | |||
字段名 | 数据类型 | 默认值 | 允许非空 |
name | Char(8) | 无 | 是 |
student number | Char(8) | 无 | 否 |
gender | Char(2) | “男” | 是 |
major | Char(12) | 无 | 是 |
class | Char(10) | 无 | 是 |
department | Char(12) | 无 | 是 |
教师 | |||
字段名 | 数据类型 | 默认值 | 允许非空 |
number | Char(8) | 无 | 否 |
name | Char(8) | “男” | 是 |
gender | Char(2) | 无 | 是 |
major | Char(8) | 无 | 是 |
系统管理员 | |||
字段名 | 数据类型 | 默认值 | 允许非空 |
number | Char(8) | 无 | 否 |
name | Char(8) | 无 | 是 |
gender | Char(2) | “男” | 是 |
“学生”类
•属性
学号(student number):Char
姓名(name):Char
性别(gender):Char
专业(major):Char
班级(class): Char
系别(department):Char
•操作
查看个人信息viewPersoninformation()
选择课程selectCourses()
获取考试信息getTestinformation()
参加考试joinTest()
获取课程信息getCourseinformation()
查看考试成绩searchTestgrade()
“教师”类
•属性
编号(number):Char
姓名(name):Char
性别(gender):Char
系别(major):Char
•操作
获取课程信息getCourseinformation()
获取授课地点getClassroom()
获取个人信息viewPersoninformation()
“系统管理员”类
•属性
编号(number):Char
姓名(name):Char
性别(gender):Char
•操作
获取教师信息getTeacherinformation()
获取学生信息getStudentinformation()
管理教师信息manageTeacherinformation()
4.2.3绘制类图
4.2.4包图
对于大型复杂系统,常需要把大量的模型元素用包组织起来,以方便处理。对所选系统的类进行分组,以便更清晰地了解系 统的结构。
4.2.5分析与讨论
1)建模类图的步骤、方法?
(1)研究分析问题领域确定系统需求。
(2)确定类,明确类的含义和职责、确定属性和操作。
(3)确定类之间的关系。
2)识别类有哪些方法,你是如何识别类的 ?
1.名词识别法:这种方法的关键是识别系统问题域中的实体。对系统进行描述,描述应该使用问题域中的概念和命名,从系统描述中标识名词及名词短语,其中的名词往往可以标识为对象,复数名词往往可以标识为类。
2.从用例中识别类:用例图实质上是一种系统描述的形式,自然可以根据用例描述来标识类。针对各个用例,可以提出如下的问题辅助识别:
用例描述中出现了哪些实体?
用例的完成需要哪些合作?
用例执行过程中产生并存储哪些信息?
用例要求与之关联的每个角色的输入与输出是什么?
3)解释关联的多重性?如何确定类的属性、操作、类之间的关联关系、组织类之间的继承?
系统的动态行为模型由交互图、状态机图和活动图表达。在系统的分析与设计中应当对主要的用例和对象类绘制这些图形,以便分析系统的行为,印证和修改系统的静态结构,满足用户的需求,达到系统的目标。
4.3 系统动态分析
系统的动态行为模型由交互图(顺序图和协同图)、状态机图和活动图表达。在系统的分析和设计中应当对主要的Use Case和对象类绘制这些图形,以便分析系统的行为,印证和修改系统的静态结构,满足用户的需求,达到系统的目标。
4.3.1顺序图
4.3.2 通信图
4.3.3活动图
活动图的主要作用是表示系统的业务工作流和并发处理过程。针对自选系统主要的业务工作流绘制活动图。
绘制活动图需要确定参与活动的对象、动作状态、动作流,以及对象流。
4.3.4状态图
状态机图表现一个对象(类)的生命史。对于一些实现重要行为动作的对象应当绘制状态机图。绘制状态机图需要确定一个对象的生命期可能出现的全部状态,哪些事件将引起状态的转移,将会发生哪些动作。
4.3.5 分析与讨论
比较顺序图与通信图、 活动图与状态图的应用。
在UML系统开发过程中,系统的动态模型主要包括对象交互模型和对象的状态模型。对象交互模型是由顺序图和通信图进行描述,对象的状态模型择优活动图和状态图进行描述。
相同:描述图符基本-样;可以描述- -个系统或对象在生存期间的状态或行为;可以用条件分支图描述-个系统或对象的行为控制流可以描述-一个系统或对 象在多进程操作中的并发行为。
不同:触发一一个系统或对象的状态发生转移的机制不同;描述多个对象共同完成- -个操作的机制不同。
顺序图和通信图:都属于交互图,用于描述对象间的动态关系,并且二者之间可以相互转化。顺序图强调消息的时间顺序,通信图强调参与交互对象的组织。
4.4系统设计
掌握系统的架构设计、资源设计及设计模式的应用。
4.4.1构建系统体系结构的初始逻辑设计包图。
4.4.2构建系统的物理模型
构建系统体系结构的物理设计构件图及部署图。
构件图:系统实现的源代码、二进制码、执行码可以按照模块化的思想,用构件分别组织起来,明确系统各部分的功能职责和软件结构。
部署图
4.5对象模型设计
掌握设计类的识别方法;掌握类的职责分配方法,并精化类的属性和操作;能够确定类的接口、优化类间的关系并将设计类图分组成包。
4.5.1构建设计类图
4.5.2构建类包图