下载文档原格式
某大学教务管理系统UML模型随着高校校园网的建设和Internet技术的引进，基于校园网和Internet的应用系统的开发正在蓬勃发展。
教务管理师高校教学管理的一向重要工作，现代化的高校教务管理需要现代化的信息管理系统支持。
新世纪背景下，高校教育体制进行了大规模的改革，招生人数逐年增加，教学计划不断更新。
在高校日常管理中，教务管理无疑是核心工作，重中之重。
其管理模式的科学化与规化，管理手段的信息化与自动化对于学校的总体发展产生深远的影响，由于管理容过多，繁琐，处理的过程也非常复杂，并且随着学校人员的增加，教务管理系统的信息量大幅上升，因此往往很难及时准确地掌握教务信息的运作状态这使得高校教务管理的工作量大幅度增加，另外，随着教育改革的不断深化，教学管理模式也在发生变化，例如实施学分制、学生自主选课等。
这一切都有赖于计算机网络技术和数据库技术的支持，在这样的形势下建立和完善一个集成化的教务管理系统势在必行。
目前，国高校都开发了自己基于校园网的教务管理系统。
由于其教务管理模式不尽相同，不同学校的实际教务管理情况各有自己的特点，因而各高校需要针对自己的教务管理模式和特点建立自己的教务管理系统。
本设计是基于某高校的教务管理模式开发的基于校园网的教务管理系统。
这样一个系统不仅可以降低工作量、提高办公效率，而且使分散的教务信息得到集中处理，对减轻教务工作负担、提高教务管理水平、实现教务管理的现代化具有重要意义。
1.建立系统用例模型1.1确定系统模型的参与者仔细分析教务管理系统问题描述。
在UML中，角色代表位于系统之外和系统进行交互的一类对象，本系统中创建主要的角色有以下三类：（1）教务员：教务员在教学管理系统中对全体学生进行用户登录、学籍管理、选课管理、教学管理和成绩管理，并且对教师进行登录管理、教学管理和成绩管理。
教务处工作人员处理日常的系统维护，例如维护和及时更新学生，教师信息以及安排选课等。
（2）教师：教师根据教务系统的选课安排进行教学，将学生的考试成绩录入此系统。
大学教务管理系统——U M L模型(总11页)本页仅作为文档封面，使用时可以删除This document is for reference only-rar21year.March某大学教务管理系统UML模型随着高校校园网的建设和Internet技术的引进，基于校园网和Internet的应用系统的开发正在蓬勃发展。
教务管理师高校教学管理的一向重要工作，现代化的高校教务管理需要现代化的信息管理系统支持。
新世纪背景下，高校教育体制进行了大规模的改革，招生人数逐年增加，教学计划不断更新。
在高校日常管理中，教务管理无疑是核心工作，重中之重。
其管理模式的科学化与规范化，管理手段的信息化与自动化对于学校的总体发展产生深远的影响，由于管理内容过多，繁琐，处理的过程也非常复杂，并且随着学校人员的增加，教务管理系统的信息量大幅上升，因此往往很难及时准确地掌握教务信息的运作状态这使得高校教务管理的工作量大幅度增加，另外，随着教育改革的不断深化，教学管理模式也在发生变化，例如实施学分制、学生自主选课等。
这一切都有赖于计算机网络技术和数据库技术的支持，在这样的形势下建立和完善一个集成化的教务管理系统势在必行。
目前，国内高校都开发了自己基于校园网的教务管理系统。
由于其教务管理模式不尽相同，不同学校的实际教务管理情况各有自己的特点，因而各高校需要针对自己的教务管理模式和特点建立自己的教务管理系统。
本设计是基于某高校的教务管理模式开发的基于校园网的教务管理系统。
这样一个系统不仅可以降低工作量、提高办公效率，而且使分散的教务信息得到集中处理，对减轻教务工作负担、提高教务管理水平、实现教务管理的现代化具有重要意义。
1.建立系统用例模型1.1确定系统模型的参与者仔细分析教务管理系统问题描述。
在UML中，角色代表位于系统之外和系统进行交互的一类对象，本系统中创建主要的角色有以下三类：（1）教务员：教务员在教学管理系统中对全体学生进行用户登录、学籍管理、选课管理、教学管理和成绩管理，并且对教师进行登录管理、教学管理和成绩管理。
UML学籍管理系统系统分为三个模块：学籍异动模块（李茹娜、刘宝同）成绩管理模块（赵亚欣、王少昌）毕业生管理模块（廉志超、胡静宜）一、学籍异动业务报告学籍异动是指学生学籍上的非程序化变动，主要包括休学、复学、退学、转专业、转学（转入及转出）、保留入学资格、提前毕业、延期毕业、留级、降级、旁听等，是学籍管理领域的常用术语。
1.学籍异动功能模块图：2.学籍异动活动图3.学籍异动用例图4.详细说明（1）新生放弃入学资格、保留入学资格、恢复入学资格角色和职责：学生：填写申请表、申请退费、缴学费学院辅导员：对于学生提出的申请签署意见二级学院院长：签署意见教务处：教务处的相关管理人员进行审批、书面通知各个部门，进行学籍通报财务处：处理学生的退费、缴费情况对应的流程图如下：对流程图的说明：1、学生填写申请表，并附带相关证明（新生报到入学一个月内受理）2、学生因病提出申请需校医务室提供复核意见，离校学生至各部门办理清退手续3、学生所在学院辅导员、二级学院院长签署意见4、教务处管理员审批（恢复入学资格不需要校领导批示）5、符合退费条件的退学学生凭学杂费结算表至财务处办理退费手续。
6、教务处书面通知学生处、所在二级学院、招生办、财务处、保卫处、医务室、教材管理；材料归档；每学期初和学期末各出一次学籍通报。
相关表格：《退学审批表》、《办理学校手续流转单》、《保留入学资格审批表》、《回复入学资格审批表》、《办理回校手续流转单》、《学生离校学杂费结算表》（2）休学、退学、复学角色和职责：学生：填写申请表、办理清退手续、缴费学院辅导员：对于学生提出的申请签署意见二级学院院长：签署意见教务处：教务处的相关管理人员进行审批、书面通知各个部门，进行学籍通报财务处：处理学生的退费、缴费情况对应的流程图：流程图说明：1、学生填写申请表，离校手续流转单及学杂费结算表，并附带相关证明2、学生因病提出申请需校医务室提供复核意见，离校学生至各部门办理清退手续3、学生所在学院辅导员、二级学院院长签署意见4、教务处管理员审批5、符合退费条件的退学学生凭学杂费结算表至财务处办理退费手续。
第1章系统需求学生学籍管理系统的域[1]描述如下：在学生学籍管理系统中，要为每个学生建立一个帐户，并给学生发放帐户(帐户可以提供帐户号、帐户初始密码)，帐户中存储学生的个人信息。
持有帐户的学生可以登陆系统，能查看和修改本人的个人信息、可查看但是不能修改选课信息、个人成绩。
在登陆时，需要输入自己的账号和密码，系统验证学生是否有效(在系统中存在帐户)，若有效，则登陆系统，否则重新输入，超过三次，则不允许再次输入，学生还可以修改自己的密码。
教务人员可以增加新的学生及他们的信息，也可以录入学生的成绩信息。
教务人员也有自己的个人帐户，权限比学生高，可以浏览学生信息，也可以编辑、添加、删除、学生信息。
对上述学生学籍管理系统的域描述进行分析，可以获得如下功能性需求：➢学生持有帐户 (帐户号和密码)。
➢学生可以登陆系统。
➢学生可以查看系统消息内的信息。
➢学生可以查看和修改个人信息，查看个人成绩信息和选课情况。
➢在学期结束时，学生可以选课。
➢教务人员持有账户（帐户号和密码）。
➢教务人员可以登录系统。
➢教务人员可以注册新的学生帐户。
➢教务人员可以修改学生的帐户信息。
➢教务人员可以删除已存在的学生帐户。
➢教务人员可以在系统中添加学生信息。
➢教务人员可以编辑学生信息。
➢教务人员可以删除学生信息。
第2章需求分析采用用例驱动的分析方法分析需求的主要任务是识别出系统中的参与者和用例，并建立用例模型。
2.1 识别参与者通过对系统需求的分析，可以确定系统中有三个参与者：StudentActor(学生)、AdminerActor（教务人员）。
参与者的描述如下：(1)Student描述：学生可以登录，查看系统信息、个人信息，提出意见，修改个人信息，还可以查看学习成绩，选课和取消选课。
示例：持有帐户的任何学生。
(2)Adminer描述：教务人员可以维护系统，可以创建、修改、删除学生的信息，可以添加、编辑、删除学生信息，即维护目录。
示例：教务管理员。
学籍管理系统建模
1．实验目的
了解一个简单的软件项目的UML建模过程和主要建模元素。
2．实验内容与要求
根据学籍管理系统的主要需求，用Rose工具软件完成对学籍管理系统的建模。
3．实验工具和方法
需要在Windows下安装ROSE工具软件。
4．实验步骤/操作指导
在实验5-1的基础上，根据学籍管理系统的主要需求完成以下四个步骤的内容。
（1）分析并得出系统的主要参与者与主要用况，并画出系统的用况图。
为所有的用况撰写脚本，将脚本放于单独的word文档中，并将文档与相应的用况相连接。
1）确定系统的使用者
通过对上面问题陈述的分析，我们可以发现系统的使用者主要有Student和Professor，同时还需要Registrar来维护这个系统。
此外，由于需要打印Student列表，故需要参与者Billing System；由于需要自动维护课程目录的改变，故需要参与者Course Catalog。
因此应该在用况视图中添加如图5-15所示的参与者。
图5-15 参与者
2）确定系统的用况
通过对上面问题陈述的分析，我们可以知道参与者Student主要要做view report cards和register for courses两件工作，而参与者Professor主要要做Select Courses to Teach和Submit Grades两件工作。
参与者Registrar要维护信息，即要做Maintain Professor Information和Maintain Student Information两件工作，此外Registrar还要控制注册何时结束，即要做Close Registration的工作。
由于安全性的原因，要使用系统还需要首先做Login的工作。
因此，应在用况视图中添加如图5-16所示用况。
图5-16 用况列表
3）用况图
通过上面的分析我们确定了系统中的参与者，用况以及它们之间的关系，根据这些关系，可以画出系统用况视图中的Main用况图，如图5-17所示：
图5-17 用况图
（2）实现关键用例。
做出相应的顺序图和协作图，对于每一个协作，说明其静态结构和动态结构。
为了说明协作的动态结构，我们可以画出其顺序图与协作图。
对于Login协作而言，由于只有一个边
界类LoginForm与系统的使用者交互，而任何系统的使用者都必须登陆，故可画出其顺序图和协作图，如图5-18和图5-19所示。
图5-18 Login顺序图
图5-19 Login协作图
上面我们通过构造Login协作实现了Login用况，这里再给出register for courses用况的顺序图和协作图，如图5-20所示。
图5-20 register for courses顺序图
图5-21 register for courses协作图
（3）做出系统的关键抽象，并设计相应的类和类图。
1）发现系统中的类
在设计时，可以从问题陈述中提炼出关键的概念，并将其抽象成相应的类。
由上面的问题陈述可知，主要有Student和Professor使用系统，Student应该有Schedule，系统关键处理的是Course，而应该
由CourseOffering来提供相应的Course。
在系统之外还有遗留下来的CourseCatalog系统。
因此可以如下图所示抽象出这些关键概念，以及与之相关的一些概念。
同时还可以绘制这些关键抽象的类图，如图5-22所示。
图5-22 关键抽象的类图
2）确定关键类的属性
以CourseOffering类的属性为例，由于实体类CourseOffering的属性指明了所提供课程的关键性质，故单独对其画出类图CourseOffering (attributes)，如图5-23所示。
图5-23 CourseOffering类的属性
3）类图
针对每个关键类给出类图。
以CourseOffering为例，由于实体类Schedule与实体类CourseOffering 存在着主修与选修两种关联，而对于不同的关联存在不同的特征信息与处理，故对于这两个关联分别设置关联类ScheduleOfferingInfo与PrimaryScheduleOfferingInfob，用关联类的属性刻画关联的特征信息，而将关联的处理映射为关联类的操作。
这里应特别注意的是对于不同的关联，CourseOffering扮演的角色以及多重性都不同。
根据上面的分析，画出CourseOffering关联类图，如图5-24所示。
图5-24 CourseOffering类图
在分析过程中，我们已经知道了实体类Schedule与实体类CourseOffering之间的主修与选修两种关联关系，对于不同的关联关系设置了关联类并画出了类图。
现在，我们只需要对于分析中得出的类图作进一步完善，加入实体类Schedule的详细设计信息后，画出类图Schedule，如图5-25所示。
图5-25 Schedule类图
对于实体类Professor而言，由于它要给出所提供的课程，因此它与CourseOfferingList类有关联，且Professor在此关联中扮演instructor角色。
故可画出类图Professor，如图5-26所示。
图5-26 Professor类图
对于实体类Student而言，由于它要被分成Fulltime和Parttime两类，因此建立类Classification，并通过实体类Student对于类Classification的聚合来表现出Student所具有的分类特征。
此外还须建立类Classification的子类FulltimeClassification和ParttimeClassification，它们的构造型均为entity，故用它们具体表现不同类Student所具有的不同的特征属性。
除了分类之外，由于学生要选课并最终得到自己的课表，因此类Student也要聚合实体类Schedule
以代表当前学生的课程表信息。
根据上面对于实体类Student的分析，可以画出类图Student，如图5-27所示。
图5-27 Student类图
（4）实施建模分析并得出系统的节点，设计系统的实施图。
1）设计节点
通过对上面问题陈述的分析，我们可以知道Student与Professor通过PC使用本系统，同时应该有一个服务器RegistrationServer维护系统信息并控制课程的注册，还有遗留下来的课程目录系统CourseCatalog System和列表打印系统BillingSystem。
同时这些节点都进行相应的处理工作，故应该全部为处理节点。
这里应特别注意的是CourseCatalog System和BillingSystem由于是遗留系统，其构造型应该为legacy。
故应该给系统的实施视图中添加如图5-28所示的处理节点。
图5-28 实施视图
2）设计实施图
通过上面的分析我们已经确定了系统的处理节点。
在这些节点中，PC机和遗留下来的CourseCatalog System和BillingSystem都不能作为系统的中心，故应该让RegistrationServer居中协调，其它的节点通过校园网络与RegistrationServer进行通讯。
这里应特别注意的是由于是通过校园网络进行通讯，故连接的构造型应该为Campus LAN。
根据上面的分析，可以画出系统的实施图，如图5-29所示。
图5-29 系统实施图
5．实验结果（实验报告要求）
分析学籍管理系统的要求，根据实验操作指导进行练习，将练习结果保存为UML模型文件提交。
