研究生软件工程课程模板.docVIP

软件工程课程设计报告 软件工程课程设计 题 目 研究生培养管理系统（仅供参考） 专 业 (全称，宋体三号，居中) 班 级 (宋体三号，居中) 姓 名 (组长，宋体三号，居中) (组员列表，宋体三号，居中) 指导教师 (宋体三号，居中) 二〇一四 年 三 月 一 日 参考摘自：李龙澍，郑诚，等编著，软件工程课程设计，北京：机械工业出版社，2010年3月 第1章 系统背景 略 第2章 项目计划 略 第3章 可行性分析 略 第4章 面向对象分析 4.1研究生培养管理系统需求 系统需求通常由用户给出，书写的内容包括：问题范围、功能需求、性能需求、接口需求、应用环境等。需求描述应该说明“做什么”，而不是“怎么做”。书写需求时，要尽力做到语法正确，慎重选择名词、动词、形容词和同义词。绝大多数需求都是二义性的、不完整的甚至是矛盾的。面向对象分析就是深入理解问题域和用户的真实需求，简历问题域的精确模型。下面给出研究生培养管理系统的需求。 系统开发的目的是实现学位申请人基本数据远程提交及院系、研究生部答辩资格审查网络化，以提高工作效率。功能需求如下： 1）学位申请人 提交学位申请人基本信息、课程成绩、学位论文信息； 提交论文评阅专家及答辩委员会个人资料； 查询论文评阅专家及答辩委员会资格审核结果； 提交论文评阅结果和论文答辩结果； 查询学位论文评阅结果和论文答辩结果； 打印学位论文答辩相关的所有表格。 学位申请人必须在学位论文完成后，通过该系统提交网上答辩申请，办理答辩手续，填写并提交相关信息，打印答辩相关表格，在所有申请工作完成后，最后向校学术委员会申请学位。 2）研究生导师 在学生提交个人信息、评阅专家信息、答辩专家信息以及论文信息后，导师在网上依次审核学位论文信息，审核评阅专家和答辩委员会资格，填写论文学术评语； 管理与维护指导教师本人的电子档案等相关功能。 3）院管理员 审核学位申请人课程成绩，审核评阅专家和答辩委员会资格； 本院研究生指导教师的电子档案的管理与维护； 本院信息数据的导出与备份。 4）校管理员（系统管理员） 校级学位论文抽查送审，提交论文送审结果，最终审核学位申请，决定是否授予学位； 全校研究生指导教师的电子档案管理与维护等相关功能； 系统运行参数的设置； 系统基本信息的配置； 数据代码表维护； 数据备份与维护等相关功能。 5）学科点负责人 审核论文评阅专家和答辩委员会资格，审核学位申请人答辩情况，给出是否授予学位的意见。学生填写评阅专家和答辩委员信息完成后，学科点负责人审核专家资格，包括评阅专家资格审查和答辩委员资格审查。 学位申请人申请学位的流程图采用活动图表示，如图4-1所示。 图4-1 申请学位的流程图 4.2功能模型 4.2.1 用例及用例图 用例是对一个活动者使用系统的一项功能时所进行的交互过程的一个文字描述序列。用例从使用系统的角度描述系统中的信息，而不考虑系统内部对该功能的具体实现方式。用例可以促进与用户的沟通，理解正确的需求，同时也可以用来划分系统与外部实体的界限，是系统设计的起点，是类、对象、操作的来源。参与者是指系统以外的需要使用系统或与系统进行交互的东西，包括人、设备、外部系统等。用例图用于显示一组用例、参与者以及它们之间的关系。 寻找用例可以采用以下启发式规则：从参与者的角度看，1）主要任务是什么；2）需要从系统获取的信息，或需要修改系统的信息；3）需要把系统外部的变化通知系统；4）希望系统把异常情况的变化通知自己。 绘制用例图的步骤如下： 1）找出系统外部的参与者和外部系统，确定系统的边界和范围。 2）确定每一个参与者所期望的系统行为。 3）把这些系统行为命名为用例。 4）使用泛化、包含、扩展等关系处理系统行为的公共或变更部分。 5）编制每一个用例的脚本。 6）绘制用例图。 7）区分主事件流和异常情况的事件流，如果需要，可以把表示异常情况的事件流作为单独的用例处理。 8）细化用例图，解决用例间的重复与冲突问题。 上述顺序并不是固定的，主要依赖于分析人员的个人经验和领域知识。 4.2.2 脚本 脚本是用例的实例，相当于对象与类的关系。每个用例都有一系列的脚本，其中包括一个主要脚本以及多个次要脚本。主要脚本描述正常情况，次要脚本描述异常或可选择的情况。脚本通常采用自然语言编写。 4.2.3 案例过程 根据研究生管理系统需求，首先确定参与者：学位申请人、研究生导师、院管理员、校管理员和学科点负责人。这些参与者之间存在一定的泛化关系，如下图4-2所示。 图4-2 参与者