第三章 系统分析。
3.1 需求分析。
在软件工程中，需求分析和需求获取是密切相关的两个过程，通过需求获取阶段的工作，软件开发人员从用户处收集到大量的需求信息，不过这些需求信息并不完全都是需求，因为这些需求信息中包含了一些与软件系统无关或关系不大的信息，以及可能发生冲突或重叠的需求信息等。软件需求分析的基本任务就是分析和综合已经收集得到的需求信息，分析的工作，目的在于透过现象看本质，发现不同需求信息之间的内在联系和隐藏在信息内部、有可能在编程过程中随时产生的潜在的矛盾，而综合的工作，目的在于排除那些并非本质的信息，找出解决潜在矛盾的办法，建立起系统的逻辑模型。具体地讲，需求分析的最基本的任务就是提炼、分析和审查已经收集得到需求信息，找出真正并且具体的信息，以确保所有项目相关人员都能明白其含义，方便接下来工作的进行。此外，在分析过程中，通过建立软件系统的逻辑模型，发现或找出需求信息中存在的冲突、遗漏、错误或含糊问题等[19].
从问题的求解过程来分析，软件需求分为四个抽象的层次，分别是基于原始问题的描述、基于用户的需求、基于系统的需求和基于软件设计的描述。基于原始问题的描述是对要解决的问题的描述，它是软件需求的基础。基于用户的需求是使用自然语言和图表来描述系统需要实现的功能以及操作的约束。基于系统的需求是使用详细的术语描述系统需要实现的功能以及操作的约束，它与基于用户的需求区别在于描述更加专业化。基于软件设计的描述是在基于系统的需求的基础上加入更详细的内容构成的，它作为软件详细设计和实现的基础，是对软件设计活动的概要描述[20].
本系统结合学校在管理学生信息时的实际要求，以及对学生信息进行管理时的实际流程，需要实现以下功能。
一、管理员端的功能需求。
1.管理员信息管理。
（1）可以设置管理员的密码。
管理员的账号与密码唯一，并且账号名称只能通过修改底层数据库修改，无法直接通过学生信息管理系统修改，保证学生信息管理系统只能由一人操作，以确保学生信息管理系统的安全性。
2.学籍信息管理（1）可以增加学生信息。
当新生入学时，管理员负责添加学生信息。
学生毕业或因某些问题肄业后学校可以为此类学生的信息保存五年，超期自动删除。
学生信息包括学号、密码、姓名、性别、班级、入校时间、出生日期、政治面貌、民族、家长、联系方式、家庭所在地等相关信息。其中前四项不能为空值，其他几项默认值为空。
学生的密码为学生登录学生信息系统时使用，默认与学号一致，在添加学生信息后便自动生成。
学号按流水序号处理，为系统自动生成。
出生日期（若有）格式为 YYYY-MM-DD.
入校时间（若有）格式为 YYYY-09-01,入校时间 YYYY 后两位须与班级六位数名称的前两位及年级四位数名称的后两位均相同。
（2）可以修改学生信息。
管理员必须持有各学院开具的介绍信才能够为学生修改信息。并在学生信息"备注"一栏注明修改时间与原内容。
修改时给予"是否确定修改？"的询问提示。
（3）可以删除学生信息。
当学生毕业或因某种问题离校后五年后的所有信息会被自动删除。
管理员删除学生信息时给予"是否确定删除？"询问提示。
（4）可以查询、打印学生信息。
查询方式包括查询指定的学生信息、查询全体的学生信息、模糊查询等多种查询方式。
3.课程信息管理。
（1）可以管理年级信息。
年级定义为学生入学时的年份，每名学生只有一个年级，年级不随学期变化而变化，与一般意义上的大一、大二等年级等不同。
每个年级都应有一个其对应的流水序号。
（2）可以设置班级信息。
班级与学生、年级相关，每名学生只能加入一个班级，每个年级可包含若干个班级，但每个班级只能隶属于一个年级。
班级名称的构成为年级号后两位+学院代号（两位）+流水序号（两位），共六位，学院代号为学校自行定义，不出现在本学生信息管理系统中。
每个班级都应有一个其对应的流水序号，与班级名称中构成的流水序号不同。班级名称构成中的流水序号为在年级号后两位与学院代号均相同时对班级进行的编号，而每个班级在六位号俱全的情况下再统一进行编号作为班级的序号。
（3）可以设置学期信息。
学期用于定义不同学期、不同年级开设不同的课程，与课程、年级、成绩相关。
学期名称的构成为年份+年+春/秋，年份为本学期所位于的年份，位于上半年则为春、位于下半年则为秋。虽然年级也用年份表示，但年级年份的含义与学期年份的含义不同。
每个学期都应有一个其对应的流水序号。
对年级、班级、学期进行修改和删除时给出"是否确定修改？"或"是否确定删除？"的询问提示。
（4）可以管理课程信息。
课程分为三类：专业课、公共课、选修课。专业课与公共课为必修课，但专业课只能由特定班级特定学期的学生来上，公共课与选修课全校皆可上。
相同课程名称的课程只能存在。
每个课程都应有一个其对应的流水序号。
对课程进行修改和删除时给出"是否确定修改？"或"是否确定删除？"的询问提示。
（5）可以按年级设置开设课程。
专业课必须由特定班级的学生在特定学期来上，公共课学生必须在特定学期来上，选修课每学期皆开设，全校学生可自由安排时间去听课。
专业课与公共课由各学院安排课表，学生不允许窜课，如需跳级听课需要向学院教务处提出申请，由教务处进行办理。
每名学生的每次所选的选修课只能听一次，不允许重复听。
修改和删除开设课表时时给出"是否确定修改？"或"是否确定删除？"的询问提示。
4.成绩信息管理。
（1）可以登记学生各科成绩。
成绩范围为大于等于 0,小于等于 100,超出或低于允许范围均做报错处理。
学生只有上过某门课才有该门课的成绩，没上过某门课不允许登记该门课的成绩。
（2）可以管理学生各科成绩。
修改学生信息必须在教务处的组织下统一进行，个人不得进行修改。
若某学生的某门课程未及格（低于 60 分），学生重修后将新的成绩覆盖原成绩，并在"备注"一栏注明"重修，原成绩为 XX."等字样。选修课不允许重修。
对成绩进行修改和删除时给出"是否确定修改？"或"是否确定删除？"的询问提示。
（3）可以查询、打印学生成绩表。
查询可以按特定学生查询、全体学生查询、模糊查询等多种成绩查询方法。
二、学生端的功能需求。
1.可以设置学生用户的密码。
这里不设置学生注册界面，学生入学管理员就将学生的基本信息写入数据库，用户名为学生姓名，初始密码为学生的学号。
学生端的用户名无法更改。
若学生毕业或因某种问题离校后管理员在管理员端删除该学生信息，则该学生无法使用此系统的学生端。
2.可以查询个人的相关信息。
（1）可以查询个人信息。
学生只能查询自己的个人信息。
学生若要办理留级、改名等信息更改，需持相关学院介绍信，去教务处修改自己的信息，不能自行通过学生端办理。
（2）可以查询个人成绩。
学生只能查询自己的个人成绩。
3.2 使用 UML 图描述需求。
3.2.1 用例图的建立。
由参与者、用例以及它们之间的相互关系所构成的描述系统中可以实现哪些功能的动态视图称作 UML 用例图，其中参与者和用例之间的对应关系又可以被称作通信关联，它表示参与者可以使用系统中存在的哪几项用例。UML 用例图显示了系统中的用户都是谁和以及用户希望系统能够实现的功能有哪些，有利于提出需求的用户和软件开发相关人员之间进行沟通和协商[21].
通过参与者和用例来对系统需求分析进行描述，参与者可以是一个人、一个硬件、另一个软件应用，甚至是其它和系统交互用于实现某些功能的实体，而为了确保系统用例的正确性，在用例图中必须表达出参与者与用例间的关系[22].通过需求，可以得知本系统系统有两个参与者：学生和系统管理员。
描述的是本系统的 UML 用例图，该图由参与者、参与者所驱动的各种用例以及用例之间的关联组合而成。
3.2.2 时序图的建立。
UML 时序图描述的是系统大颗粒的行为，是对结构模型和框架模型的补充说明。
描述的是学生信息查询用例的时序图，管理员通过查询界面查询学生信息，学生信息查询界面是一个边界对象，这类对象紧挨着系统的边界，直接与系统外部的管理员进行交互。查询操作可以看作是一个控制对象，这类对象控制一组对象之间对信息进行共享。
学生在学生端查询自己的相关信息的流程也可以参考该时序图来实现。
对学期、年级、课程类别等增加、删除、修改、查询的时序图与对学生信息的增加、删除、修改、查询的时序图相仿，不再另行画图。
描述的是管理员修改密码的时序图，首先管理员应按提示输入旧密码与两次新密码，系统首先核对两个新密码是否相同，然后核对旧密码与数据库中原有密码是否相同，如果这两项全部符合，则把新密码写入数据库，然后通知系统管理员密码修改成功。学生在学生端修改自己密码的活动同样可以参考该图。
3.2.3 状态图的建立。
UML 状态图描述一个对象所有可能出现的状态以及当某一事件发生时该状态的变换条件是什么。
描述的是学生信息（包括成绩）的状态图，从图上可以看出学生信息在什么情况下才能被处理。
3.2.4 活动图的建立。
UML 活动图描述需要满足用例所要求，必须进行的活动和不同活动间的约束关系，可以方便地识别哪些活动是并行的活动。
管理员对学生信息进行管理的活动图，从图中可体现管理员对学生信息进行增加、删除、修改、查询的一系列过程。
对学期、年级、课程类别等增加、删除、修改、查询的活动图与对学生信息的增加、删除、修改、查询的活动图相仿，不再另行画图。
3.2.5 组件图的建立。
UML 组件图是用来可视化这些物理组件以及它们之间的关系。
3.2.6 部署图的建立。
UML 部署图描述该系统将会如何部署在硬件环境里、该系统不同的组件将会在什么地方物理地运行，以及组件之间将会如何互相通信。
