使用UML图描述学生信息管理需求,计算机信息管理论文

使用UML图描述学生信息管理需求,计算机信息管理论文本篇论文目录导航：【题目】【第一章】【第二章】【3.13.2】使用UML图描绘叙述学生信息管理需求【3.3-3.6】【第四章】【5.1-5.7】【5.85.9】【第六章】【总结/以下为参考文献】第三章系统分析。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活动图描绘叙述需要知足用例所要求，必须进行的活动和不同活动间的约束关系，能够方便地辨别哪些活动是并行的活动。管理员对学生信息进行管理的活动图，从图中可具体表现出管理