基于Web的作业审阅系统的设计与实现 - 教师功能模块 - 毕业设计论文

2 需求分析与总体设计

2.1 需求分析

软件需求分析就是把软件计划期间建立的软件可行性分析求精和细化，分析各种可能的解法，并且分配给各个软件元素。需求分析是软件定义阶段中的最后一步，是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。

软件需求分析的任务是：深入描述软件的功能和性能，确定软件设计的约束和软件同其他系统元素的接口细节，定义软件的其他有效性需求，借助于当前系统的逻辑模型导出目标系统逻辑模型，解决目标系统“做什么”的问题。

用户对本系统提出的需求大多是原始的、笼统的，有时是抽象的、过于细节化的，因此需要综合分析用户对系统提出的需求（功能、性能、数据等方面），然后按照从抽象到具体的方式构造出系统的逻辑模型，表达软件系统的目标需求，并以多方位的视图形式作为本阶段工作的结果，为下一阶段的软件设计提供设计基础。

基本课题的需求，在需求分析中采用了UML的需求分析大致分为以下步骤： 第一步：利用用例及用例图表示需求。从业务需求描述出发获取系统用户的工作流程；确定系统用户与用例、用例与用例图之间的关系，生成用例图。

第二步：利用包图表示目标软件系统的总体框架结构。

基于课题的背景，本课题针对的系统需求有如下方面：用户可以获取信息，这包括用户可以布置的作业，可以查看作业；可以对不同用户进行管理，用户可以提交作业，不同用户之间进行交流。用例图分别为：教师用例图如图2-1所示、学生用例图如图2-2所示和管理员用例图如图2-3所示。

布置作业<><><>查看作业<>短消息审阅作业教师

图2-1 教师用例图

短消息<><><>提交作业查看作业学生

图2-2学生用例图

管理所有用户信息<><>管理所有学生作业<><><>管理班级管理员管理课程管理所有用户

图2-3 管理员用例图

根据系统的需求分析可以得出系统的包图。如图2-4所示。

作业审阅系统管理员教师学生

图2-4 系统包图

2.2 用例建模

在一个系统中，用例视图被认为是UML中起着支配作用的视图。用例视图描述的是系统外部可见的行为，因此，在软件开发开始于考虑所提出的系统需求的情况下。用例视图提供了一种强制力量，驱动和约束着后续的开发。

用例视图展示的是系统功能的结构化视图，这个视图定义了若干参与者和这些参与者可以参与的用例。参与者模型化了用户与系统进行交互时可能充当的角色，用例则描述了用户使用系统能够完成的一项特定的任务。

系统行为是当系统响应外部事件时所做的事情。在UML中，从外表上可见并预测的系统行为在用例中捕获，一个用例用来执行一个业务功能，该功能对参与者来说是外表上可见的。 2.2.1 识别者与参与者

采用用例驱动的分析方法分析需求的主要任务是识别出系统用户和用例，并建立用例模型。基于.NET的作业审阅系统有教师、学生、管理员三种类型的参与者。

参与者描述如下：

? 教师是基本的系统用户，具有短消息、布置作业、查看作业和审阅作业。 ? 学生也是基本的系统用户，具有短消息、提交作业和查看作业等权限。 ? 管理员是最高的系统用户，管理所有用户消息、所有学生作业、人员、班级和课程。 2.2.2 识别用例

通过对需求的进一步分析，可以确定系统中有如下用例存在：

? 布置作业：描述了教师布置作业的功能，教师可以给学生布置作业。 ? 查看作业：描述了教师及学生查看作业的功能，教师及学生可以查看学生提交的作业。

? 审阅作业：对学生提交的作业进行评改、打分、写评语；并且可以修改成绩。

? 短消息：若学生有问题可以通过编写短消息将问题发送给教师，教师也可以通过短消息解决学生的问题。

? 提交作业：描述了学生提交作业的功能，学生可以提交已完成的作业。 ? 管理所有用户消息：查看所有用户消息和删除所有用户消息。 ? 管理所有学生作业：查看所有学生的作业情况和教师审阅的情况。

? 管理人员：修改所有用户的信息。 ? 管理班级：添加、删除、修改班级。 ? 管理课程：添加、删除、修改课程。

2.3 系统用例图

识别出参与者和用例后，需要分析参与者和用例之间的关系，并建立系统用例图。如图2-5所示。